AIエージェントのセキュリティは何から手を付けるか｜英NCSC中間ガイダンスの読み方

こんにちは、ひろかずです。

英NCSC「AIエージェントのサイバーリスク管理」中間ガイダンスが公開されたので、そこから読み取れたことと現場に落とし込んでいく筋道について共有します。

忙しい人向けの要約

• 英NCSCは2026年8月20日、エージェント型AI（agentic AI）のサイバーリスク管理に関する中間ガイダンスを公開しました。これは、正式ガイダンスの公開までのつなぎと明示された、実務向けの暫定助言という位置づけです。
• 中核は「自律度に応じて統制を変える」という考え方です。エージェントの自律性が高いほど、誤作動・過剰アクセス・スコープ逸脱時の影響が大きくなるため、統制も強くするというものです。
• 具体策として、脅威モデリング、プロンプト設計、人間の関与レベル、サンドボックス（ネットワーク・コンピュートそれぞれ4段階の成熟度モデル、エージェント専用IDと認証情報の最小化を含む）、監査ログと監視、活動の帰属明示、緊急停止（キルスイッチ）の7つの考慮事項を挙げています。
• モデル組み込みの安全機構は「回避されうる」「高リスク環境では不十分」と明記されています。プロンプトによる禁止指示だけに頼らず、技術的・運用的統制と組み合わせることを求めています。
• このガイダンスは「AIエージェントの活動をユーザー活動として監視対象に含める」ことを社内で合意する材料に使うのが最も効果的であると考えます。
• 本記事では、確認項目を領域別のチェックリストに整理し、自律度の3区分と完了条件付きの対応ステップに落としています。インベントリと停止手順から着手し、ログと監視が揃ってから夜間・週末の自律実行を解禁する順序を推奨します。

前置き

英国政府のサイバーセキュリティ専門機関であるNCSC（National Cyber Security Centre／国家サイバーセキュリティセンター）からエージェント型AIのサイバーリスクを管理についての中間ガイダンスが公開されました。

エージェント型AIに関連するサイバーリスクを取り扱った文書としては既にいくつか公開されていますが、これらは大きく2つに分かれます。一つは導入判断とガバナンスを扱う文書で、導入の可否、説明責任、リスクの分類までを示します（Careful adoption、AI事業者ガイドライン）。もう一つは脅威の分類体系で、何が起き得るかを網羅します（OWASP、MITRE ATLAS）。どちらも重要ですが、導入を決めた後の運用設計を、どの水準までやればよいのかという目盛りで示す文書は乏しかったというのがこれまでです。

• Careful adoption of agentic AI services（CISA・豪ASD's ACSC＋国際パートナーの共同ガイダンス、2026年5月1日公開。CISAの公開ページ）
• AI事業者ガイドライン 第1.2版（総務省・経済産業省、2026年3月31日）
• AI in OT 共同ガイド（CISA他）
• OWASP Top 10 for Agentic Applications 2026（2025年12月9日公開）
• OWASP Agentic AI – Threats and Mitigations / State of Agentic AI Security and Governance
• MITRE ATLAS（v2026.09、2026年9月）

今回のNCSCの文書は、その空白を埋める位置にあります。ネットワークとコンピュートの隔離レベルを4段階で示し、エージェント専用IDや短命な認証情報、取得すべきログ、停止時に切るべき対象までを具体的に書いています。リスクを列挙するだけの文書と違い、自社の現在地を段階で言い当てられる形になっています。

そしてこのタイミングで「中間」と断って出したこと自体がメッセージです。NCSCは、承認されていない・意図しない活動をエージェントが実行したインシデントが複数発生したことを公開の契機に挙げています。正式版の整備を待つ間にも導入は進む、という判断です。

読む側にとっては、内容が差し替わる前提で社内基準を作るべきだということでもあります。文書名や項番をそのまま写し取るより、自律度に応じて統制を比例的にかけるという原則を自社のルールに落としておく方が、次の改訂での影響を受けにくいでしょう。

何が起きているの？

NCSCは2026年8月20日、ブログ「Managing the cyber risk of agentic AI」を公開しました。AIモデルやエージェント型AIシステムが「承認されていない、あるいは意図しない活動」を実行するインシデントが最近複数発生したことをきっかけに、正式なガイダンスの整備が完了するまでの中間的・実務的な助言として位置づけています。

NCSCは2026年5月にも、ブログ「Thinking carefully before adopting agentic AI」で、国際パートナーと共同作成した「Careful adoption of agentic AI services」というガイダンスを紹介しています。そちらは「小さく始める」「低リスク業務から」「人間の説明責任を明確に」という導入判断寄りの内容でした。

今回の8月版は一歩踏み込み、導入を決めた後の技術統制（サンドボックスの隔離レベルや認証情報の扱い、ログ、停止手段まで）を具体化しています。導入の是非を論じる段階は終わり、運用設計の巧拙が問われる段階に入ったと考えられます。

なぜ情報システム・セキュリティ担当者に関係するの？

このガイダンスの実務的な核心は「エージェント型AIの活動は、ユーザー活動の一形態として扱うべきである」に集約します。NCSCは、エージェントの活動を24時間365日のセキュリティ運用監視とインシデント対応の対象に含めることを求めています。

情シス・セキュリティ担当者視点だと、これは監視対象が1種類増えるという話です。人間のユーザーには、ID発行、権限付与、ログ取得、異常検知、アカウント停止という一連の統制が存在します。NCSCの要求は、この統制一式をエージェントにも適用することであり、以下が挙げられています。

• エージェントには人間やシステムと区別できる専用IDを割り当てる。
• エージェントが触れる認証情報（APIキー、OAuthグラント、SSHキー、認証済みセッション）はすべて「爆発半径（blast radius）」の一部として棚卸しする。
• 可能な限り短命の認証情報を使う。
• プロキシで認証情報を注入してエージェント本体に直接持たせない構成も選択肢である。

この「エージェント＝監視対象のユーザー」という整理は、情報システム部門とセキュリティ部門が担当範囲で取り扱う事柄です。エージェントを使い始めるのは利用部門でも、IDを発行し、権限を設計し、ログを保全し、異常時に止める役割は情シス・セキュリティ側に回ってきます。そのため、インシデントが起きたとき、経営や監査から「どのエージェントが、誰の権限で、何をしたのか」を問われて答える必要が生じます。エージェントが人間のアカウント（認証情報）を借用して動いている状態では、この問いに事後から答えられず、監査にも十分に応えられません。

よくある誤解

モデルに安全機構が組み込まれているから大丈夫

NCSCは、モデル組み込みの安全制御は基礎的な保護にはなるが、回避されうること、高リスク環境では十分な保護にならないことを明記しました。モデルの安全性評価とデプロイ環境の統制は別問題です。

プロンプトで禁止事項を書いておけば守られる

NCSCはプロンプト設計を考慮事項の一つに挙げつつ、「プロンプトだけに頼るな。技術的・運用的統制と組み合わせて多層防御にせよ」と明言しています。コンテキストウィンドウが圧縮されると制約が失われる可能性があるため、重要な制約は繰り返せ、という細かい指摘もあります。プロンプトは統制の一層であって、統制そのものではありません。

英国の話であって日本企業には関係ない

ガイダンスが示すのは特定の法規制への対応ではありません。自律度評価、隔離、ID、ログ、停止という汎用的な設計原則です。日本国内にも、総務省・経済産業省の「AI事業者ガイドライン 第1.2版」のような参照できる公的文書はあります。ただし、こちらは、事業者が守るべき原則とガバナンス体制を示す文書です。エージェントにどの隔離をかけ、どんなIDと認証情報を持たせ、何をログに残し、どこまで停めるのかといった水準の話は射程外で、社内基準の根拠として使うには粒度が粗いところがあります。

NCSCの8月版を併せて社内規程や稟議書の参照元として併記すれば、原則（国内ガイドライン）と具体的な統制水準（NCSC）の両方を揃えられます。ベンダー資料しか根拠がない状態と、政府機関の公開ガイダンスを根拠として示せる状態では、稟議や監査対応の通りやすさが違います。

実務で問題になりやすいポイント

公開情報と一般的な実務知識から、多くの企業で論点になりやすいポイントを挙げます。

エージェントの乱立

エージェントの作成には管理者権限が必須とは限らず、利用部門が個別にエージェントを立ち上げ、MCPサーバーなどの接続先を利用者自身が決められる構成が広がっています。統制の前提となる「何が動いているかの一覧」が存在しない状態は、運用開始後に問題になりやすい典型例です。

夜間・週末の対応

エージェントは人間と違って夜間も動き続けます。NCSCは、最初の実験は人間の監視が手厚い業務時間内に行い、統制の有効性を確認してから夜間・週末の自律実行に広げることを推奨しています。「深夜2時にエージェントが何をしたか説明できるか。誰が止めるのか」に答えられない運用は、実験を本番に置いているのと同じです。

停止手段の過信

NCSCは、緊急停止は「エージェントのプロセスを止める」以上のことを意味しうると指摘します。ネットワークアクセスの遮断、エージェントとモデル推論基盤との通信の切断まで含めて設計しておかないと、いざという時に止まりません。ここは見落とされがちです。

技術的・運用的な確認ポイント

NCSCのガイダンスから、そのまま点検項目に使える要素

脅威モデリングの単位と再評価の契機

エージェントが何にアクセスでき、どのツールを呼び出せ、想定外の動作をしたときに何が起きるかを洗い出します。点検すべきは3点です。

• 評価の単位：製品単位ではなくユースケース単位で評価しているか。同じツールでも、用途によって触れるデータと影響範囲が変わる。
• 想定する経路：外部から取り込むデータやツール出力を経由した指示の混入、接続先（MCPサーバー等）の追加を経路として織り込んでいるか。
• 再評価の契機：接続先の追加、権限の拡大、自律度の引き上げを再評価のトリガーとして定義しているか。

脅威モデリングは一度作って終わる文書ではありません。接続先が増えるたびに影響範囲が変わるため、エージェントの構成変更の承認フローに紐づけて更新する必要があります。

プロンプト設計を統制の一層として扱う

NCSCはプロンプト設計を考慮事項に挙げる一方で、プロンプトだけに頼らず技術的・運用的統制と組み合わせた多層防御にすることを求めています。チェック項目は次のとおりです。

• 権限外の操作や禁止事項をシステムプロンプトに明記し、重要な制約は繰り返し記述しているか。コンテキストウィンドウが圧縮されると制約が失われる可能性がある。
• プロンプトを版管理し、誰がいつ何を変更したかを追跡できるか（版管理はNCSCの記載にはない本記事の補足）。プロンプトの変更は統制の変更である。
• プロンプトで禁止している操作が、権限設計側でも同時に塞がれているか。

3点目が重要ポイントです。「プロンプトで禁止しているから実行されない」という前提は、権限設計の抜けをそのまま覆い隠します。プロンプトは、権限で塞いだ上での事故防止策として位置づけるのが妥当です。

認証情報の棚卸しと、権限範囲・有効期間の最小化

エージェントがアクセスできるAPIキー、OAuthのアプリ連携許可、SSHキー、認証済みセッションをすべて列挙します。ここで最小化する対象は3つあります。

• 保有する認証情報の数：使っていないキー・連携許可・鍵・セッションは失効させる。
• 権限の範囲：タスクに必要な操作と対象リソースだけに絞り、書き込みが不要なら読み取り専用にする。
• 有効期間：NCSCが求めるとおり、長期キーは避け、可能な限り短命のトークンに切り替える。

この3つを押さえると、エージェントが乗っ取られたときに動かせる範囲と、それが使える時間の両方が限定されます。エージェントがサンドボックス内の設定不備や脆弱性を自ら発見して隔離を突破する可能性にもNCSCは言及しており、複数層の隔離と設定の定期検証を求めています。

ログと活動の帰属

エージェントの思考トレースやトランスクリプトに加え、サンドボックス環境側のアクセスログ、プロキシログ、ネットワークトラフィックまで取得し、可能なら改ざん不能（イミュータブル）にして調査時に信頼できる状態を保ちます。外部システムと通信するエージェントには、逆引き可能なIPアドレスや識別用HTTPヘッダーの付与など、活動を第三者が帰属特定できる工夫も推奨されています。

サンドボックスの隔離レベルの確認

NCSCはネットワークとコンピュートそれぞれに4段階の成熟度モデルを示しました。コンピュートの隔離レベルは以下のとおりです。

ネットワーク側も4段階です。

• レベル1：ネットワークアクセスに制限なし
• レベル2：承認済みドメインの許可リストに制限
• レベル3：モデルのAPIのみに制限
• レベル4：外部ネットワークアクセスなし。モデルをネットワークサンドボックス内でローカルホストする

自社の各エージェントが今どのレベルにいるかを言えるようにする。それが最初の確認です。

ここまでの5つ（脅威モデリング、プロンプト設計、認証情報、ログと帰属、サンドボックス）を並べると、着手のしやすさには差があります。

• 脅威モデリングとプロンプト設計は、設計文書とシステムプロンプトの見直しで済み、追加の基盤も調達も不要。ただしユースケースの棚卸しが前提になるため、エージェントのインベントリ作成と並行させる。
• 認証情報の棚卸しと最小化は、既存のIdPと各SaaSの権限設定の見直しで進められ、基盤の変更を伴わない。
• ログと活動の帰属は、取得対象のログの見直しやSIEM側の取り込み・相関分析の再設計が必要になるため、認証情報より工数がかかる。
• サンドボックスの隔離レベルの引き上げは、基盤の再設計と調達が伴うため、短期での対応が難しい。

工数とリードタイムだけを見れば、エージェントのインベントリ作成と並行して脅威モデリングとプロンプト設計を整備し、認証情報の棚卸し、ログと帰属の整備と進め、隔離レベルの引き上げを中期の計画に置くのが現実的です。

ただし順序と優先度は別です。脅威モデリングとプロンプト設計は着手が軽い反面、それ自体ではエージェントの行動を強制的に止められません。権限とログの整備が伴わなければ、文書上の統制に留まります。

自律度ごとの統制レベル

NCSCは、統制をエージェントの自律度に応じて比例的に適用することを原則として示し、人間の関与の度合いをhuman-in-the-loop、human-on-the-loop、human-out-of-the-loopの3類型で整理しています。この原則を鑑みると、ここまでの確認項目をすべてのエージェントに同じ強さで適用する必要はないでしょう。

この類型を社内の適用単位に置き換えると、以下の3区分になります。

• 提案しかしないエージェント
• 人間の承認を経て実行するエージェント
• 承認なしに実行するエージェント

同じツールでも、使い方がこのうちのどこに当たるかで必要な統制の厚みは変わります。先に挙げた脅威モデリング・プロンプト設計・認証情報・ログ・サンドボックス・停止手段を、この3区分に割り当てると次のようになります。

見直し時のチェックリスト

確認項目を、ここまでの本文で扱った領域ごとに整理しました。自律度に応じて比例的に適用する前提で、右列に特に重視する区分を示しています。

経営層・監査部門への説明ポイント

経営層への説明ポイント

要点は「禁止か許可か」の二択から離れ、リスクを受容できる水準まで下げるための枠組みと方針の提示です。全面禁止は業務部門のシャドーAIを助長させ、全面許可は統制のない自律実行を助長させます。

• 利用を自律度で区分し、区分ごとに求める統制の水準をあらかじめ定める。
• 区分に応じた統制を満たすことを利用開始の条件とし、満たさないものは低い区分に留める。
• 低減しきれない残余リスクは、受容するか利用を見送るかを経営の判断事項として上げる。

この形で合意を取るのは、個別のエージェントの可否そのものではありません。リスクベースで判断するという進め方です。合意が取れていれば、新しいエージェントが出てきたときも、どの区分に当てるかという実務の判断で処理できます。

監査部門への説明ポイント

エージェント活動をユーザー活動と同列の監査対象として扱う方針と、その証跡（専用ID、操作ログ、承認記録、停止試験の記録）を示します。政府機関の公開ガイダンスに沿った統制設計であることは、監査上の合理的根拠として示せます。

個人情報や機密データを扱うエージェントについては、委託先管理や利用目的との整合という既存の内部統制の枠組みに載せて説明します。

実務担当者が次に取るべき対応ステップ

チェックリストの9領域を、着手の軽さと上位工程への依存関係で並び替えたものです。各ステップに完了条件を置くと、どこまでで次に進めるのかが社内で共有しやすくなります。

1. インベントリと区分・責任者の確定（1〜2週間）
   SaaS管理コンソール、IdPログ、プロキシログを突き合わせ、稼働中のエージェントと接続先を洗い出します。一覧には名前と接続先に加えて、提案のみ・承認付き実行・自律実行の区分と責任者を並べます。
   完了条件：全エージェントに区分と責任者が入っている。
2. 停止手順の文書化と試験（ステップ1と並行）
   「誰が・どうやって・何分で止めるか」をエージェントごとに決め、ネットワーク遮断と推論基盤との通信切断まで含めて一度試します。統制の中で唯一、他の整備を待たずに被害を止められる手段です。
   完了条件：自律実行のエージェントで遮断まで実施した記録がある。
3. 脅威モデリングとプロンプト設計の整備（1か月以内）
   ユースケース単位で脅威モデルを作り、指示の混入と接続先追加を経路に含めます。システムプロンプトは版管理し、禁止事項は権限側でも塞ぎます。
   完了条件：接続先の追加・権限の拡大・自律度の引き上げが再評価のトリガーとして構成変更の承認フローに紐づいている。
4. IDと認証情報の棚卸し（1か月以内）
   エージェントが持つキー・トークン・セッションを列挙し、不要スコープを剝がして短命化します。人間ユーザーの認証情報を借用しているエージェントは、専用IDに切り替えます。
   完了条件：借用がゼロで、自律実行のエージェントがすべて専用IDと短命トークンで動いている。
5. ログ・帰属と監視への組み込み（1〜3か月）
   思考トレースと環境側ログをSIEMに集約し、外部通信には逆引き可能なIPや識別用ヘッダーを付与して帰属を辿れる状態にします。自律実行分は改ざん不能な保全とSOC監視までです。
   完了条件：エージェント活動が監視対象に入っている。夜間・週末の自律実行はここを満たしたエージェントに限って解禁する。
6. 自律度ポリシーの制定と隔離レベルの計画化（3か月以内、引き上げは中期）
   比較表の3区分を自社用に定義して申請・承認フローに組み込み、各エージェントのネットワークとコンピュートの現在の隔離レベルと目標レベルを帳簿化します。基盤の再設計を伴う引き上げは、この帳簿を根拠に中期計画へ回します。
   完了条件：新規エージェントが区分判定と統制要件の確認を経てからしか使えない状態になっている。

ステップ1と2を先に置いているのは、一覧と停止手段がない状態では他の統制をどこに適用すればよいかも、失敗したときに止める手立ても決まらないからです。

まとめ

NCSCの8月版ガイダンスは、エージェントを「新しいAIの話題」ではなく「統制対象のユーザーが1種類増えた」と扱うための文書です。IDを発行し、権限と有効期間を絞り、ログを保全し、異常時に止める。この四つは既存のIdP・SASE・SIEMの運用ですでにやっていることで、新しい基盤を一から作る話ではありません。

ただし適用の強弱は分ける必要があります。提案しかしないエージェントと、承認なしで本番環境を触るエージェントに同じ隔離と同じログ保全を要求すれば、統制はどこかで形骸化します。自律度で区分し、区分ごとに水準を決める。それが最初に経営と合意すべき事項です。

途中の状態でも、稼働中のエージェントの一覧と、ネットワーク遮断まで含んだ停止手順の2つがあれば、「深夜2時に何が動いていて、誰が止めるのか」には答えられます。そこから順に埋めていけば、次に出る正式版ガイダンスを差分で取り込める状態になります。

やることは多いですが、ひとつひとつ取り組んでいきましょう。

この記事が誰かの助けになれば嬉しいです。

FAQ

Q1. NCSCの「Managing the cyber risk of agentic AI」とは何ですか？

英国NCSCが2026年8月20日に公開した、エージェント型AIのサイバーリスク管理に関する中間ガイダンスです。正式ガイダンスの公開までの暫定的・実務的助言と位置づけられており、自律度評価、サンドボックス、専用ID、監査ログ、緊急停止などの考慮事項を示しています。

Q2. どんな組織が対象ですか？

AIエージェントが高い自律性を持って動作する環境を構築・運用するシステム設計者と運用者が主対象です。英国企業に限らず、内容は汎用的な設計原則であり、日本企業の社内基準にもそのまま参照できます。

Q3. モデルに組み込まれた安全機構だけでは不十分なのですか？

NCSCは、モデル組み込みの安全制御は基礎的な保護にはなるものの、回避される可能性があり、高リスク環境では単独で十分な保護にならないと明記しています。追加のセーフガードと運用監視の併用が前提です。

Q4. サンドボックスの成熟度4段階とは何ですか？

ネットワークとコンピュートそれぞれについてNCSCが示した隔離レベルです。コンピュートでは、レベル1（隔離なし）、レベル2（プロセス分離・OCIコンテナ）、レベル3（仮想化）、レベル4（専用ハードウェア）と段階が上がります。ネットワークは最上位で「外部アクセスなし＋モデルのローカルホスト」です。

Q5. AIエージェントにはどんなIDを持たせるべきですか？

人間や個別システムと区別できるクラスの専用IDを各エージェントに割り当てます。エージェントが触れるAPIキー、OAuthグラント、SSHキー、認証済みセッションは影響範囲（blast radius）の一部として棚卸しし、短命化・最小化します。

Q6. 「キルスイッチ」は何を止めればよいのですか？

エージェントのプロセス停止だけでは足りない場合があります。NCSCは、外部ネットワークアクセスの遮断や、エージェントとモデル推論基盤との通信の切断まで含めて、即座に停止できる設計を求めています。

Q7. AIエージェントのログは何を取ればよいですか？

エージェントの思考トレース・トランスクリプトに加え、サンドボックス環境のアクセスログ、プロキシログ、ネットワークトラフィックを取得します。調査時に信頼できるよう、可能な限り改ざん不能な形で保全することが推奨されています。

Q8. 小規模な組織でも全部やる必要がありますか？

ガイダンス自体が「自律度に応じて比例的に適用する」構造です。提案しかしないエージェントに専用ハードウェアは不要です。まずインベントリと停止手順から着手し、自律実行を許すエージェントに絞って統制を厚くするのが現実的です。