homulaAIエージェント導入のセキュリティ実践 — 第2回
統制の8原則
プロンプトの指示ではなく、エージェントの外側で守る。8つの原則を、考え方・やること・根拠の順に8枚の図で。
この回の結論：エージェントの判断や指示の正しさに頼らない。権限・認証情報・操作・通信先・記録・データ・委託先の8点を、エージェントが迂回できない外側の仕組みで統制する。
第1回では、リスクがエージェントの入力・判断・記憶・ツール・部品・委任の各所で生じ、組織や運用のあり方によって広がることを見ました。この回は、そのリスクに対して統制をどう置くかを、8つの原則にまとめます。
各原則は「この原則の考え方」「具体的に何をするか」「根拠（原文）」の順に書いています。具体的な手順は第4回（導入前の設計）の該当節に対応しています。
原稿：ホワイトペーパー第1.0版（2026年10月）
本記事は、homulaのホワイトペーパー「業務AI・AIエージェント導入の情報セキュリティ実践ガイド」をWeb向けに再構成したものです。事実には [ ] で出典番号を付け、記事末尾に原文へのリンクを載せています。出典番号のない手順・推奨と「本ガイドの提案」と明記した事項は、本ガイドが提案するものです。
原則1統制は、エージェントの外側で強制する
アクセス権限・実行可能な操作・通信先の制御を、モデルやエージェントの判断、プロンプトの指示に委ねず、エージェントの外側の層（ゲートウェイ、OS、ネットワーク）で強制する。
この原則の考え方
エージェントは外部から届いた指示に従い（R1）、制限を回避しようとします（R2）。プロンプトで「〜してはいけない」と書くことは統制ではありません。
そこで、止めるべき操作や宛先は、エージェントが再設定も迂回もできない外側の層で制御し、許可したものだけを通します。
デジタル庁の源内工房も、エージェント側の設定（セキュリティフック）の状態にかかわらず、ネットワーク層の防御措置を回避できない構成としています[A14]。
具体的に何をするか（第4回 5.5）
- 使ってよいツール・MCPサーバー・スキルを、名前とバージョンで固定する（許可リスト）
- ツール定義は信頼できる提供元のものだけを信頼し、承認後に変わったら再承認する
- スキル／プラグインは導入前に、フック・外部呼び出し・読み取るファイルを確認する
- 組織内で共有するスキルは、共有の前に審査する
手順の詳細：第4回「導入前の設計」
原則2エージェントには独立したIDを付与し、必要最小限の権限だけを与える
エージェントごとに人間とは別のID（プリンシパル）を発行し、業務に必要な最小の権限・スコープのみを与える。人間のアカウントや権限をエージェントに流用しない。
この原則の考え方
人間のアカウントや権限をエージェントに流用すると、エージェントの誤動作や乗っ取りが人間と同じ範囲の被害を生み、監査ログ上も人の操作と区別できません（R4、R11）。
そこで、エージェントごとに人間とは別のIDを発行し、接続先・ツールごとに業務に必要な最小の権限だけを与えます。
MCP（エージェントとツールをつなぐ標準仕様）も、アクセス制御とツール呼び出しのレート制限をサーバーに必須としています[B2]。
具体的に何をするか（第4回 5.3）
- エージェントごとにIDを発行し、人間のアカウント・パスワードを設定しない
- 権限は接続先・ツールごとに最小化し、読み取り専用で足りるかを判定する
- サブエージェントを使う場合は、そのデフォルト権限を明示的に定める（R6）
- IDaaS（Microsoft Entra、Okta等）がエージェントIDを扱える場合はそれを使う
手順の詳細：第4回「導入前の設計」
原則3認証情報は短寿命にし、エージェントに持たせない
長期間有効なAPIキー・トークンを使わない。認証情報はエージェントの実行環境・設定ファイル・プロンプト・アプリ配布物に埋め込まず、外側の資格情報管理から必要時に注入する。暗号化して保存し、平文で保存・ログ出力しない。
この原則の考え方
2026年9〜10月の国内事案で確認された手口には、アプリ解析によるAPIキーの特定と、他所で窃取したAPIキーの使用が含まれていました[A2][A3]。配布物・環境変数・ログに入ったシークレットには、抽出・漏えいのおそれがあります。
そこで、長期間有効なキーを使わず、有効期間の短い認証情報を外側の資格情報管理から必要なときに注入します。
デジタル庁の源内基準も、秘密情報をソースコードやリポジトリに含めないこと、漏えいを自動で検知し、確認されたら速やかに無効化またはローテーションすることを求めています[A14]。
具体的に何をするか（第4回 5.4）
- 接続先への認証はOAuth 2.1（PKCE必須）を優先する。長期APIキーは例外とし、有効期限・ローテーション・失効手順を定める
- 認証情報は保管庫に置き、設定ファイル・環境変数・プロンプト・リポジトリ・配布物に書かない
- トークンは発行された先でのみ受け付け、他者向けのトークンを受理・中継しない
- ログ・エラーメッセージ・LLMへの入力に認証情報が混入しないようにする
手順の詳細：第4回「導入前の設計」
原則4高影響の操作は人が承認する。承認を形骸化させない
外部への送信・投稿、データの削除・変更、決済、権限変更など取り消しが難しい操作は、実行前に人間の承認を必須にする。承認画面には「誰（どのエージェント）が、何に対して、何を」実行するかを表示する。不確実な状況では停止して人に委ねる。
この原則の考え方
エージェントは高速・大量に実行します（R7）。承認が形骸化すると、取り消しが難しい操作がそのまま実行されます（R10）。Agentforceでは、Slackへの返信アクションに利用者確認と実行者表示がなく、エージェントの名義でフィッシングリンクを投稿できました[A7]。
そこで、高影響の操作は実行前に人の承認を必須にし、承認画面には判断に必要な情報を表示します。不確実な状況では停止して人に委ねます。
デジタル庁の源内基準は、AIが上書き・削除できる対象をAIが生成したファイルに限定し、利用者の原本は改変できない仕組みにしています[A14]。承認に加え、破壊できる範囲そのものを狭める設計を併用します。
具体的に何をするか（第4回 5.7）
- 承認が必要な操作の一覧（送信・投稿・削除・変更・決済・権限変更・新規接続先の追加）を定め、基盤側で強制する
- 承認画面に、エージェントID・委任したユーザー・対象・操作内容・送信先を表示する
- エージェント名で外部に送る文章には、エージェントによる送信であることを表示する
- 不確実な状況では停止して人に委ねる動作をデフォルトにする
手順の詳細：第4回「導入前の設計」
根拠（原文）
PDF版（25ページ・図17点）を無料でダウンロード
社内の検討資料にそのまま使えるPDF版です。ベンダー質問票には回答の記入欄があります。
原則5通信先を限定する。名前解決と外向きアクションも対象にする
エージェント・サンドボックス・ブラウザからの外向き通信は、迂回できないプロキシを通し、許可した宛先のみに限定する。HTTPだけでなく、DNS名前解決、画像等のリソース読み込み、メッセージ送信などのアクションも通信経路として扱う。
この原則の考え方
データの持ち出しが成立し得る経路として、HTTP以外にも、画像タグのホスト名によるDNS経由の送出が公表されています[A7]。SSRFにより内部の資格情報エンドポイントへ到達できる脆弱性も公表されています[C6]。
そこで、外向き通信は迂回できないプロキシを通し、許可した宛先だけに限定します。DNSや画像の読み込み、メッセージ送信も対象にします。
デジタル庁の源内工房は、Web検索の読み込み（GET）は許可しつつ、外部へのデータ送信（POST/PUT等）はシステム上遮断しています[A14]。
具体的に何をするか（第4回 5.6）
- サンドボックス・ブラウザ・ワークフロー実行環境の外向き通信を、エージェントが設定変更できないプロキシ経由に限定する
- 宛先を許可リストで定める。DNS・画像などの読み込み・メッセージ送信も対象にする
- 外部から与えられたURLを取得する経路では、内部アドレス帯と資格情報エンドポイントへの到達を遮断する
- リダイレクト後の宛先も検証する
手順の詳細：第4回「導入前の設計」
原則6すべてのツール呼び出しを記録し、改竄から守る
エージェントが行ったツール呼び出し・外部アクセス・承認の記録を、エージェントIDと委任した人間の両方を含めて、人間が読める形式で取得する。ログの保管場所にエージェントが書き込めないようにする。記録は顧客（利用組織）が参照できる。
この原則の考え方
意図から外れたエージェントの振る舞いは、内部不正と区別がつかないおそれがあります[A6]。記録がなければ、侵害の検知も、責任分界の判断もできません（R11）。
そこで、呼び出し・外部アクセス・承認を1件ごとに、エージェントIDと委任した人を含めて記録し、エージェントが書き込めない場所に保管します。
デジタル庁の源内基準は、重要なログを開発者を含むいかなる主体も改ざん・削除できない構造とし、運用規律のみに依存しないとしています[A14]。
具体的に何をするか（第4回 5.8）
- ツール呼び出し1件ごとに、時刻・エージェントID・委任ユーザー・ツール・入出力の要約・承認者・結果を記録する
- 人が読める形式で、エージェントが書き込めない場所に保管し、改竄を検知する
- 保持期間を定める。CISAは重要システムで、可能な場合1年以上の保持を挙げている[B12]
- 利用組織が自分で参照できるようにする。SaaS／PaaS型ではベンダーに確認する（第6回 ベンダー質問票）
手順の詳細：第4回「導入前の設計」
原則7データは持たない。目的を終えたら消す
エージェントに渡す情報、エージェントが保持する会話履歴・メモリ・実行ログ・中間成果物に含まれる個人データ・機密を最小化し、利用目的を終えたら削除する。保存期間を定める。
この原則の考え方
流出の被害規模は「何を持っていたか」で決まります。相次ぐ漏えいを踏まえ、政府・個情委は保有情報の見直しを要請しました[A1][A4]。漏えいした情報には本人確認書類の画像も含まれました[A10]。
エージェントの実行ログ・メモリは、設計しなければ個人データの新たな保管場所になります。そこで、渡す情報と保持するデータを最小化し、保存期間を定め、目的を終えたら削除します。
デジタル庁の源内基準は、最上位の機密性区分の情報を、入力方法を問わず入力禁止としています[A14]。企業も、情報区分ごとに入力・参照の可否を定めます。
具体的に何をするか（第4回 5.9）
- 渡す情報・会話履歴・長期メモリ・実行ログ・中間ファイルごとに、個人データの有無・保存場所・保存期間・削除手順を定める
- 法令・契約上の保存期間がない個人データは、利用目的を終えた時点で削除する（法は遅滞なく消去する努力義務。本ガイドの提案）
- 本人確認書類画像のように漏えい時の影響が大きいデータは、「保持しない」設計を優先する
- 情報区分ごとに、エージェントへ入力・参照させてよいかを定め、周知する
手順の詳細：第4回「導入前の設計」
原則8委託先・ベンダーと「共に管理する」
AIエージェントのSaaS／PaaS提供者、構築・運用の委託先、その再委託先について、選定時に安全管理措置を確認し、契約でアクセス権管理・ログ管理・報告義務・業務終了後の削除を定め、契約後も継続的に確認する。委託先に渡す情報は最小限にする。
この原則の考え方
委託先の正規アカウント認証情報の窃取を起点に、顧客システムが侵害された事例が公表されています[A11]。委託元が必要かつ適切な監督を行っていない場合、再委託先の不適切な取扱いは、元の委託元の法違反と判断され得ます[A5]。
そこで、提供者・委託先・再委託先について、選定時に安全管理措置を確認し、契約で管理と報告の義務を定め、契約後も継続的に確認します。委託先に渡す情報は最小限にします。
国家サイバー統括室も、「委託先企業と共に管理する」という認識の下で、契約締結時だけでなく継続的に確認することを求めています[A1]。
具体的に何をするか（第4回 5.10）
- SaaS／PaaS型を採用する場合は、第6回のベンダー質問票で確認する
- 委託契約に、情報の取扱方法、アクセス権・ログ管理、漏えい時の報告義務と期限、インシデント時の連携、業務終了後のデータ削除を含める
- 再委託は、事前報告・承認を条件にする
- 委託先に渡す情報と付与するアクセス権を必要最小限にし、管理する
手順の詳細：第4回「導入前の設計」
Summary
この記事の要点
- 1原則1：アクセス権限・操作・通信先の制御は、モデルの判断やプロンプトに委ねず、ゲートウェイ・OS・ネットワークなど外側の層で強制する。
- 2原則2・3：エージェントごとに人とは別のIDを発行して最小権限にし、認証情報は持たせず、外側の保管庫から短寿命のものを必要時に注入する。
- 3原則4：送信・削除・決済・権限変更など取り消しが難しい操作は、実行前に人が承認する。承認画面には誰が何に対して何をするかを表示し、破壊できる範囲そのものも狭める。
- 4原則5：外向き通信は迂回できないプロキシを通して許可した宛先だけにする。DNS・画像の読み込み・メッセージ送信も通信経路として扱う。
- 5原則6：ツール呼び出しを1件ごとに、エージェントIDと委任した人を含めて記録し、エージェントが書き込めない場所に置く。利用組織が自分で参照できるようにする。
- 6原則7・8：渡す情報と持つデータを最小化して目的を終えたら消し、委託先・ベンダーとは選定から業務終了後の削除まで共に管理する。
Sources
出典
出典番号はホワイトペーパー付録A「準拠文書の一覧」と共通です。URLは原稿作成時点（2026年10月）のものです。
- [A1]
- [A2]
- [A3]
- [A4]
- [A5]
- [A6]
- [A7]
- [A9]
- [A10]
- [A11]
- [A14]
- [B1]
- [B2]
- [B3]
- [B8]
- [B12]
- [C6]
FAQ
よくある質問
原則1（外側で強制する）を土台に、原則2（エージェントごとのIDと最小権限）と原則3（認証情報を持たせない）を先に決めることを勧めます（本ガイドの提案）。この3つは後から変えにくく、承認・通信制限・ログの設計もIDと認証情報の設計を前提にするためです。どの原則がどこまで必須になるかは、任せる範囲（自律性と行動範囲）によって変わります。第3回の表を参照してください。
実装するのはベンダーでも、確認する責任は利用組織にあります。原則8（委託先・ベンダーと共に管理する）のとおり、選定時に安全管理措置を確認し、契約で管理と報告の義務を定めます。第6回のベンダー質問票18問は、原則1〜8と導入時・運用の確認事項に対応しています。
必要です。画像タグのホスト名によるDNS経由の送出のように、HTTPでデータを送信しなくても情報が外に出る経路が公表されています。読み取った情報を外部に出せてしまえば、参照だけのエージェントでも漏えいの経路になります。第3回の表では、egress制限をすべての統制レベルで必須としています。
一律の正解はなく、自組織の要件で決めます。米CISAは#StopRansomware Guideで、重要システムのログを可能な場合1年以上保持することを挙げています。SaaS型ではベンダーの保持期間と、利用組織が自分で参照・取得できるかを確認します。
Next
シリーズの前後
PDF版（25ページ・図17点）を無料でダウンロード
社内の検討資料にそのまま使えるPDF版です。ベンダー質問票には回答の記入欄があります。
AIエージェントの統制設計を、あわせて相談したい方へ
homulaは、AIエージェントを業務に導入する企業に向けて、統制ポリシー・権限・監査ログの設計から運用までを支援しています。SaaS型の選定時の確認から、自社で構築する場合の基盤設計まで、ご相談ください。