homulaAIエージェント導入のセキュリティ実践 — 第4回
導入前の設計
任せる範囲を決め、接続先と情報を洗い出してから、権限・通り道・承認・記録・委託先を設計する。10の手順と3枚の図で。
この回の結論：導入前は、まず業務ごとに任せる範囲（自律性L×行動範囲E）を判定し、エージェントが触れる接続先と情報を洗い出す。そのうえで、権限と通り道（ID・認証情報・ツール・通信先）と、実行前後の対応（承認・ログ・データ保持・委託先）を設計し、エージェントの外側で制御する。
第4回と第5回は、導入前・導入時・運用の順に、第2回の8原則を実装する手順を示します。この回は導入前（企画・調達・設計）の10の手順です。各手順の見出しに、対応する原則へのリンクを付けています。
原稿：ホワイトペーパー第1.0版（2026年10月）
本記事は、homulaのホワイトペーパー「業務AI・AIエージェント導入の情報セキュリティ実践ガイド」をWeb向けに再構成したものです。事実には [ ] で出典番号を付け、記事末尾に原文へのリンクを載せています。出典番号のない手順・推奨と「本ガイドの提案」と明記した事項は、本ガイドが提案するものです。
1.任せる範囲を決め、接続先と情報資産を洗い出す
5.1対象業務のレベル判定
やること
- 業務ごとに、エージェントが行う操作を列挙し、E1／E2／E3に分類する。「参照だけ」のつもりでも、メール送信・チケット作成・ファイル保存が含まれればE2以上
- 人がどの工程で判断するかを定め、L1〜L4に分類する
- E3の業務は、対象・操作を限定してE2に分割できないか検討する
- 顧客の権利・金銭・雇用への影響と、誤りの回復可能性を評価する。高リスクと判定した業務は、承認・検証・記録を強化する
- コマンド実行や任意サイトへのアクセスができる高自由度の環境は、利用者の能力要件を定め、管理者が個別に許可する
レベルの定義と、レベルごとに必須となる統制は第3回を参照してください[A8]。デジタル庁の源内基準は、影響範囲や誤りの回復可能性に応じたリスクベースアプローチを採っています[A14]。
2.エージェントの権限と通り道を、設計の段階で絞る
3.実行前後の対応と、データ・委託先の扱いを設計時に決めておく
取り消しが難しい操作をどこで止めるか、何を記録するか、何をいつまで持つか、委託先に何を求めるかを、導入前に決めます。承認は基盤側で強制し、プロンプトの指示には頼りません。
5.7承認設計原則4
やること
- 承認が必要な操作（送信・投稿・削除・変更・決済・権限変更・新規接続先の追加）を一覧にし、基盤側で強制する
- 承認画面に、エージェントID・委任したユーザー・対象・操作内容・送信先を表示する
- エージェント名で外部に送る文章には、エージェントによる送信であることを表示する（R10）
- 不確実な状況では停止して人に委ねる動作をデフォルトにする[B1]
5.8ログ設計原則6
やること
- ツール呼び出し1件ごとに、時刻・エージェントID・委任ユーザー・ツール・接続先・入力・出力の要約・承認者・結果を記録する
- 人が読める形式で、エージェントが書き込めない場所に保管し、改竄を検知する
- 保持期間を定める。CISAは重要システムで、可能な場合1年以上の保持を挙げている[B12]
- 利用組織が自分で参照できること。SaaS／PaaS型ではベンダーに確認する
5.9データ保持の設計原則7
やること
- 渡す情報・会話履歴・長期メモリ・実行ログ・中間ファイルごとに、個人データの有無・保存場所・保存期間・削除手順を定める
- 個人情報保護法は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めている[A5]。本ガイドは、法令・契約上の保存期間がないものを利用目的の終了時点で削除する運用を提案する
- 本人確認書類画像のように漏えい時の影響が大きいデータは、「保持しない」設計を優先する
5.10ベンダー・委託先の確認原則8
やること
- SaaS／PaaS型を採用する場合は、第6回のベンダー質問票で確認する
- 委託契約に、情報の取扱方法、アクセス権・ログ管理、漏えい時の報告義務と期限、インシデント時の連携、業務終了後のデータ削除、再委託の事前報告・承認を含める[A1][A5]
- 委託先に渡す情報を必要最小限にし、付与するアクセス権を管理する[A1]
PDF版（25ページ・図17点）を無料でダウンロード
社内の検討資料にそのまま使えるPDF版です。ベンダー質問票には回答の記入欄があります。
Summary
この記事の要点
- 1導入前は、業務ごとにエージェントが行う操作を列挙してE1〜E3に、人が判断する工程を定めてL1〜L4に分類する。参照だけのつもりでも、送信・作成・保存が含まれればE2以上。
- 2エージェントが接続するSaaS・社内システム・API・MCPサーバー・ファイル共有を、内部API・管理用APIも含めて一覧化し、情報の区分を記す。
- 3IDはエージェントごとに発行して最小権限にし、認証情報はOAuth 2.1（PKCE必須）を優先して保管庫に置く。他者向けのトークンは受理・中継しない。
- 4ツール・MCPサーバー・スキルは名前とバージョンで固定した許可リストで管理し、外向き通信は迂回できないプロキシで許可した宛先だけにする。
- 5承認が必要な操作を一覧にして基盤側で強制し、ツール呼び出しを1件ごとに記録する。データは種類ごとに保存期間と削除手順を定め、委託先とは契約で管理と報告の義務を定める。
Sources
出典
出典番号はホワイトペーパー付録A「準拠文書の一覧」と共通です。URLは原稿作成時点（2026年10月）のものです。
- [A1]
- [A3]
- [A4]
- [A5]
- [A8]
- [A14]
- [B1]
- [B2]
- [B3b]
- [B12]
- [C2]
FAQ
よくある質問
必要です。業務の中にメール送信・チケット作成・ファイル保存が含まれていれば、それは状態の変更なのでE2以上になります。操作を一つずつ列挙して分類すると、想定より広い範囲を任せていたことに気づくことがあります。
OAuthは、パスワードを渡さずにアクセス権を委任する認可の仕組みです。PKCEは認可コードの横取りを防ぐ仕組みで、OAuth 2.1では必須です。長期間有効なAPIキーを設定ファイルに置く代わりに、スコープと有効期限のあるトークンを使うことで、漏えいしたときの影響を小さくできます。MCP仕様も認可にOAuth 2.1を採用しています。
スキル／プラグインは「ユーザーの権限で動くコード」として扱い、導入前にフック・外部呼び出し・読み取るファイルを確認します。デジタル庁の源内基準も、組織内で共有するスキルを共有の前に審査することを求めています。許可リストには名前とバージョン（可能ならハッシュ）で登録し、変更されたら再承認します。
完全には避けられないため、残ることを前提に設計します。渡す情報・会話履歴・長期メモリ・実行ログ・中間ファイルごとに、個人データの有無・保存場所・保存期間・削除手順を定めます。本人確認書類画像のように漏えい時の影響が大きいデータは、そもそも保持しない設計を優先します。
Next
シリーズの前後
PDF版（25ページ・図17点）を無料でダウンロード
社内の検討資料にそのまま使えるPDF版です。ベンダー質問票には回答の記入欄があります。
AIエージェントの統制設計を、あわせて相談したい方へ
homulaは、AIエージェントを業務に導入する企業に向けて、統制ポリシー・権限・監査ログの設計から運用までを支援しています。SaaS型の選定時の確認から、自社で構築する場合の基盤設計まで、ご相談ください。