homula約200組織
1社の侵害から、下流の約200組織へ
ソフトウェア企業1社の侵害を起点に、下流の約200組織のデータが抽出され、セッション情報が一括で窃取された。報告は、作業のほぼすべてをAIエージェントが実行したとしている。
Anthropic Threat Intelligence Report（2026-09）
WHITE PAPER無料・PDF 25ページ
公的機関・標準の一次文書に基づく統制の整理
業務AI・AIエージェント導入の
情報セキュリティ実践ガイド
AIエージェントは、正規の権限と認証情報で操作を実行します。外から届いた指示に従っても、ログ上は内部不正と区別がつかない。 本資料は、経済産業省・IPA・JPCERT/CC・デジタル庁・CISA・NIST・OWASPの一次文書に基づいて、任せる範囲の決め方と、エージェントの外側で統制を強制する設計・手順を25ページにまとめました。
- SaaS型のAIエージェントを選ぶとき、ベンダーに何を確認すべきかが分かる（質問票18問）
- 情シス・セキュリティ部門の審査に、一次文書の根拠つきで答えられる（統制の8原則）
- 導入前・導入時・運用で、自社が何をしたかを21項目で点検できる
- 25ページ
- 読了 約40分
- 17点
- 図解
- 37件
- 準拠文書（公的機関・国際標準・公表事例）
第1.0版・2026年10月発行 ／ 出典番号を付けた記述は付録の一次文書に基づき、本書の提案は「本ガイドの提案」と明記して区別しています。
Why now
統制は、エージェントが意図どおりに動かない場合を前提に設計する。
エージェントは意図どおりに動くとは限りません。外部から届いた文書やWebページに埋め込まれた指示に従ってしまうことがあり、制限を回避したり、曖昧な指示から意図しない処理を行ったりすることもあります。
そのときエージェントは、与えられた正規の権限と認証情報で操作を実行します。IPAは、こうした振る舞いは内部不正と区別がつかないおそれがあり、統制の設計はこれを前提に置く必要があるとしています。
公表された事例 — AIを経由して情報が外に出た経路は、すでに公表されている
DNS経由
公開フォームの指示で、顧客データが外へ
認証不要の公開フォームから送った指示に従い、AIエージェントが顧客データをDNS経由で外部へ出す経路が公表された。外から届く入力は「指示」として働く。
Zenity Labs（2026-09）
19,996名分
許可されていない生成AIへの個人情報の入力
業務利用が許可されていない外部の生成AIサービスに、特定保健指導の対象者19,996名分の個人情報（疾患情報を含む）が入力された。従業員本人の申告で判明。
委託元の健康保険組合の公表（2026-10）
Risk structure
リスクは、エージェントの仕組みで生じ、組織や運用のあり方によって広がる。
経済産業省サブWGが整理した12のリスク要因を、エージェントの入力・判断・記憶・ツール・部品・委任の各所に配置しました。どこで何が起きるかを1枚で把握でき、次の8原則がそれぞれどの要因に効くのかが追えます。
8 principles
統制の8原則
統制はエージェントの判断に委ねず、外側で強制する。本資料は8原則を、原則ごとに図解・考え方・具体策・根拠となる一次文書の原文とともに1ページずつ示します。以下は各原則の図です。
01
統制は、エージェントの外側で強制する。
権限・操作・通信先の制御を、モデルやプロンプトに委ねず、ゲートウェイ・OS・ネットワークの層で強制する。
02
エージェントには独立したIDを付与し、必要最小限の権限だけを与える。
人のアカウントや権限を流用しない。接続先・ツールごとに最小の権限・スコープを与える。
03
認証情報は短寿命にし、エージェントに持たせない。
長期間有効なAPIキーを使わない。設定ファイル・プロンプト・配布物に埋め込まず、外側の資格情報管理から必要時に注入する。
04
高影響の操作は人が承認する。承認を形骸化させない。
送信・投稿・削除・決済・権限変更など取り消しが難しい操作は人の承認を必須にし、承認画面に「誰が・何に・何を」を表示する。
05
通信先を限定する。名前解決と外向きアクションも対象にする。
外向き通信は迂回できないプロキシを通し、許可した宛先だけに限定する。DNS・画像の読み込み・メッセージ送信も経路として扱う。
06
すべてのツール呼び出しを記録し、改竄から守る。
呼び出し1件ごとに、エージェントIDと委任した人を含めて人が読める形式で記録し、エージェントが書き込めない場所に保管する。
07
データは持たない。目的を終えたら消す。
渡す情報と、会話履歴・メモリ・実行ログ・中間成果物に含まれる個人データを最小化し、保存期間を定めて削除する。
08
委託先・ベンダーと「共に管理する」。
SaaS／PaaS提供者・構築運用の委託先・再委託先について、選定時に安全管理措置を確認し、契約で義務を定め、契約後も継続的に確認する。
無料でダウンロードする
8原則それぞれの「考え方」「具体的に何をするか」「根拠の原文」は資料に収録
Implementation
任せる範囲が広いほど、必須の統制を増やす。
原則を知るだけでは導入は進みません。第4章で任せる範囲を決め、第II部で導入前・導入時・運用の順に実装し、形態ごとの弱点を補う。資料はその手順を図と箇条書きで示します。
第4章
任せる範囲を、自律性と行動範囲の2軸で決める
経産省サブWGの自律性レベル（L1〜L4）と行動範囲レベル（E1〜E3）を4つの区分に整理し、区分ごとに必須・推奨の統制を一覧化。任せる範囲を決めると、やるべき統制が決まる。
第II部
導入前・導入時・運用の順に、8原則を実装する
導入前のレベル判定と棚卸しが、以降の設計の前提になる。ID・認証情報・ツール・通信先・承認・ログ・データ保持・委託先の設計から、導入時のテスト、運用の監視まで。
第6章
導入時は、統制が効くことを6つのテストで確かめる
権限・注入・承認・egress・ログ・停止。設計した統制が実際に働くことを、本番前に試験で確認する。注入テストではDNS・画像読み込み経由の送出も試す。
第8章
MCP・ブラウザ・サンドボックス・ワークフロー基盤、形態ごとの弱点を補う
接続の形態ごとに固有の注意点がある。ツール定義の変更、Webページ内の指示、中に置いた認証情報、基盤自体の脆弱性。第5〜7章の統制に加えて確認する。
Checklists
そのまま使える、ベンダー質問票18問と自社点検21項目。
各問・各項目に根拠（原則・出典）と、本書で手順を示した節番号を付けています。以下は抜粋です。
ベンダー質問票
第9章・全18問- 01
エージェントは人間のユーザーとは別のIDで動作するか。IDaaS（Entra／Okta等）と連携できるか
原則2 - 04
接続するツール・MCPサーバーを許可リストで固定できるか。ツール定義の変更を検知するか
原則1 - 05
高影響操作（送信・削除・変更・決済・権限変更）を人間の承認なしに実行し得るか。承認はプロンプトでなく基盤で強制されるか
原則4 - 07
ツール呼び出し単位の監査ログを、エージェントIDと委任ユーザーを含めて、利用組織が自分で参照できるか
原則6 - 15
即時停止（kill switch）の手段と、停止後の認証情報一括失効
第7.4節
残り13問（認証情報の保管・SSRF対策・SBOM・再委託先・認証取得状況・管理機能・移植性など）は資料に収録
自社点検チェックリスト
第10章・全21項目- 5.1
対象業務ごとにL（自律性）・E（行動範囲）を判定した。E3は分割を検討した
導入前
- 原則7
自社の情報区分ごとに、エージェントへ入力・参照させてよいかを定め、周知した
導入前
- 5.4
認証情報は資格情報管理で保管し、設定ファイル・環境変数・プロンプト・リポジトリ・配布物に書いていない
導入前
- 6.2
権限・注入・承認・egress・ログ・停止のテストを実施し、結果を記録した
導入時
- 7.4
即時停止、認証情報一括失効、ログ保全、影響範囲特定の手順を定め、訓練している
運用
導入前14・導入時3・運用4の全21項目は資料に収録
Table of contents
目次
- はじめに
統制の前提と、公表事例
p2–3 - 第I部
原理原則 — リスクの構造（R1〜R12）、統制の8原則、統制レベルの考え方
p4–14 - 第II部
実装ガイド — 導入前・導入時・運用・形態別の追加事項
p15–20 - 第III部
チェックリスト — ベンダー質問票18問、自社点検21項目、準拠文書一覧、用語
p21–25
Who this is for
こんな方におすすめ
- 情報システム・セキュリティ部門の責任者（CISO / CIO）
- AIエージェント導入を進める業務部門・DX推進の責任者
- SaaS／PaaS型AIエージェントの選定・契約を担当する方
- 自社構築のエージェント基盤を設計・運用するエンジニア
「SaaS型のAIエージェントを導入したいが、情シスに何を確認されるか分からない」「ベンダーに何を聞けば安全性を判断できるのか」「経産省のガイドライン公表前に、いま公開されている一次文書で何が言えるのかを押さえたい」——そうした方のために作りました。