AIエージェントを社内導入する前に、権限、データ持ち出し、ツール実行、ログ、承認、停止手順をどう決めるか。情シス・CSIRT向けに実務ルールを整理する。
AIエージェントは「便利なチャット」ではなく権限を持つ実行者になる
社内で生成AIを使う段階が、文章の下書きや要約から、メール送信、チケット作成、コード修正、SaaS操作、ログ調査まで広がっている。ここで重要なのは、AIエージェントを単なるチャット画面として扱わないことだ。ツール実行権限や社内データへの接続を持った瞬間、AIエージェントは「人の代わりに判断して動く実行者」になる。
人間の担当者なら、入社手続き、権限申請、操作ログ、上長承認、退職時のアカウント停止がある。AIエージェントにも同じような統制が必要になる。誰の権限で動くのか、どのデータを読めるのか、どの操作は人間承認を挟むのか、失敗したときに誰が止めるのかを決めないまま導入すると、便利な自動化がそのまま新しい攻撃面になる。
この記事では、情シス、CSIRT、開発組織、DX推進チームが、AIエージェントを社内で使い始める前に決めるべき利用ルールを整理する。攻撃手順ではなく、防御・運用・監査のための設計に絞って扱う。
- 社内利用するAIエージェントの権限、ログ、データ保護、承認フローを扱う。
- モデル性能の比較やプロンプトテクニックではなく、実務運用の安全設計に焦点を置く。
- 実行可能な攻撃コードや悪用手順は扱わない。
まず用途を3段階に分ける
AIエージェントのリスクは、モデル名だけでは決まらない。同じ生成AIでも、読むだけ、下書きするだけ、外部システムを操作する、では必要な統制がまったく違う。最初に用途を3段階に分けると、議論が整理しやすい。
| 段階 | 例 | 主なリスク | 最低限の統制 |
|---|---|---|---|
| 読むだけ | 社内文書検索、FAQ回答、ログ要約 | 機密情報の持ち出し、誤要約 | データ分類、アクセス制御、回答ログ |
| 下書きする | メール文案、チケット案、調査メモ | 誤情報、過剰な断定、個人情報混入 | 人間レビュー、出典表示、保存ルール |
| 実行する | SaaS操作、コード変更、チケット更新、通知送信 | 誤操作、権限濫用、連鎖的な自動実行 | 最小権限、承認ゲート、監査ログ、緊急停止 |
最も危ないのは、「最初は読むだけ」のつもりだったものが、いつの間にかSaaS連携や自動実行まで持つことだ。PoCの便利さをそのまま本番利用へ持ち込むと、誰がどの権限を付与したのか分からない状態になりやすい。
SaaS権限棚卸しの進め方 でも扱った通り、外部アプリやAPIトークンは正規の認可経路で動く。AIエージェントも同じだ。侵入されていなくても、過剰な権限を与えた正規エージェントが、誤った操作や不適切なデータ参照を行う可能性がある。
利用ルールで最初に決める5項目
社内ルールを作るときに、いきなり細かい禁止事項から入ると運用されない。まずは、次の5項目を明文化する。
| 項目 | 決めること | 決めないと起きること |
|---|---|---|
| データ分類 | 入力してよい情報、禁止情報、要承認情報 | 顧客情報、契約、未公開情報が不用意に投入される |
| 権限範囲 | 読み取り、作成、更新、削除、外部送信の可否 | 人間より広い権限でエージェントが動く |
| ツール実行 | どの操作を自動化し、どこで人間承認を挟むか | 誤送信、誤削除、誤設定がそのまま実行される |
| ログ・監査 | 入力、参照データ、ツール呼び出し、出力をどこまで残すか | 事故後に何が起きたか説明できない |
| 停止手順 | 誰が、どの条件で、どの権限を止めるか | 異常時にエージェントの継続アクセスを止められない |
ここでのポイントは、禁止リストだけで終わらせないことだ。「機密情報を入れないでください」と書くだけでは、現場は判断できない。顧客名、メールアドレス、契約金額、障害ログ、ソースコード、脆弱性情報、監査資料など、実際の業務データを分類しておく必要がある。
AIエージェントは、法務、広報、開発、営業、カスタマーサポート、人事の業務データに触れる。ルールは情シスだけで作らず、データオーナーと業務責任者が判断に参加する形にする。
権限設計は「人のアカウントを借りない」から始める
AIエージェントに個人アカウントのブラウザセッションや個人トークンを使わせる設計は避けたい。誰の操作なのか分からなくなり、退職・異動・インシデント時に権限停止が難しくなるからだ。
実務では、少なくとも次の原則を置く。
| 原則 | 実装の考え方 |
|---|---|
| 専用IDを使う | エージェントごとにサービスアカウントや専用アプリ登録を用意する |
| 最小権限にする | 読み取りだけで足りる用途に更新・削除権限を付けない |
| 環境を分ける | 本番、検証、個人検証で接続先と権限を分ける |
| 期限を付ける | PoC権限、外部連携、例外利用には終了日を設定する |
| 所有者を置く | エージェントの業務責任者、技術責任者、停止判断者を決める |
最小権限の原則 は人間だけの話ではない。AIエージェントは、与えられたツールと権限の範囲で行動する。メールを読む必要がないエージェントにメール読取権限を渡さない。チケットを作るだけなら削除権限を渡さない。GitHubを読むだけならpush権限を渡さない。
また、権限は「モデル」ではなく「ツール」に付く。チャット画面では安全に見えても、裏側でSlack、Google Drive、GitHub、Notion、Jira、Microsoft 365へ接続していれば、実際のリスクは接続先の権限で決まる。認証と認可の違い を分けて理解しておくと、AIエージェント設計でも判断しやすい。
データ保護は入力・参照・出力・保存で分ける
AI利用ルールで曖昧になりやすいのが、データの扱いだ。「機密情報を入れない」と書いても、AIエージェントは検索、要約、RAG、ファイル添付、ツール実行ログ、会話履歴など複数の経路でデータに触れる。
データ保護は、入力、参照、出力、保存で分けて考える。
| 場面 | 確認すること |
|---|---|
| 入力 | ユーザーがプロンプトへ貼り付けてよい情報、禁止情報、匿名化条件 |
| 参照 | RAGやコネクタが読めるリポジトリ、フォルダ、チャンネル、チケット |
| 出力 | 社外送信、顧客向け文面、コード変更、設定変更に人間確認を挟むか |
| 保存 | 会話履歴、ツール呼び出し、添付ファイル、評価ログをどこに保存するか |
たとえば、社内FAQ用のエージェントが人事フォルダまで読めるなら、ユーザーは意図せず人事情報を引き出せるかもしれない。ログ分析用のエージェントが本番障害ログを外部サービスへ送るなら、個人情報や認証情報が混ざる可能性がある。
CISAなどが公開しているAIデータセキュリティのガイダンスでも、AIシステムの開発・テスト・運用を通じて、データの機密性、完全性、信頼性を守る考え方が重視されている。AIエージェントの導入では、「何をモデルへ送るか」だけでなく、「どのデータを自動で取りに行けるか」まで見る必要がある。
人間承認を挟む操作を先に決める
AIエージェントの良さは、手順をまたいで作業できることにある。一方で、メール送信、権限変更、コード反映、チケットクローズ、顧客通知のような操作は、間違えると影響が大きい。すべてを禁止すると使われないが、すべてを自動化すると事故が起きる。
まず、承認なしでよい操作、人間承認が必要な操作、禁止する操作を分ける。
| 区分 | 例 |
|---|---|
| 承認なしでよい | 読み取り、要約、下書き、候補提示、既存チケットへの非公開メモ追加 |
| 承認が必要 | 顧客向け送信、GitHubへのpush、権限変更、外部共有、インシデント報告 |
| 原則禁止 | 本番データ削除、監査ログ削除、認証設定変更、秘密情報の表示・転送 |
承認ゲートは、UI上の「実行してよいですか？」だけでは足りない。どのユーザーが、どの入力に基づいて、どのツールを、どの対象に対して実行しようとしているのかを確認できる必要がある。操作内容が曖昧な承認ボタンは、実質的には承認にならない。
これは ゼロトラストアーキテクチャ と同じ発想だ。一度ログインしたからすべて許可ではなく、操作ごとにリスクを見て判断する。AIエージェントにも、継続的な認可判断が必要になる。
ログは「会話ログ」だけでは足りない
AIエージェントで事故が起きたとき、会話ログだけでは調査できないことがある。重要なのは、入力、参照データ、モデル応答、ツール呼び出し、外部送信、承認者、実行結果をつなげて追えることだ。
最低限、次の情報を残せる設計にしたい。
| ログ項目 | 調査で使う理由 |
|---|---|
| 実行者 | 誰がエージェントを起動したかを確認する |
| 入力概要 | どの依頼から処理が始まったかを確認する |
| 参照データ | どの文書、チケット、ファイル、リポジトリを読んだかを見る |
| ツール呼び出し | どのSaaS/APIへ、何を実行したかを追う |
| 承認情報 | 誰がどの操作を承認したかを確認する |
| 出力先 | メール、Slack、チケット、GitHubなどの送信先を確認する |
| 停止・失敗 | エラー、拒否、ポリシー違反、緊急停止の履歴を見る |
ログを残すときは、ログ自体の機密性にも注意する。プロンプト全文や添付ファイルをそのまま保存すると、監査ログが新しい機密情報の保管場所になる。必要な粒度で要約し、機密情報をマスクし、アクセス権を絞る。
インフォスティーラーとAI時代の認証情報危機 でも触れたように、現代の侵害対応ではトークンやセッションの失効まで見る必要がある。AIエージェントのログも、どのトークンや連携アプリが使われたかを追える形にしておくと、事故時の切り分けが速くなる。
導入初月の実務チェックリスト
最初から全社ルールを完璧に作る必要はない。まずは高リスク用途を避け、限定された業務で検証し、次の項目を満たしてから範囲を広げる。
| 週 | やること | 完了条件 |
|---|---|---|
| 1週目 | 利用用途、対象データ、接続SaaS、所有者を棚卸しする | エージェントごとに用途・責任者・接続先が説明できる |
| 2週目 | 入力禁止情報、参照可能データ、ツール権限を決める | 禁止事項ではなく、許可される範囲が明文化されている |
| 3週目 | 承認ゲート、ログ、停止手順を実装・確認する | 誤操作時に追跡し、止められる状態になっている |
| 4週目 | 利用レビュー、例外整理、教育資料を更新する | 継続利用・停止・追加検証の判断が残っている |
この初月レビューでは、成果だけでなく「危ない使われ方」を見る。ユーザーが顧客情報を貼り付けていないか、個人のAPIトークンを接続していないか、承認なしで外部送信していないか、ログが残っているかを確認する。
実務チェックに落とし込むなら、SaaS権限棚卸しチェックリスト と GitHub secret leak対応チェックリスト を合わせて使うとよい。AIエージェントの接続先には、SaaS権限とシークレット管理の両方が関わる。
よくある失敗：PoC権限の放置、個人トークン、ログ未整備
AIエージェント導入で起きやすい失敗は、技術的な難しさよりも運用の抜けにある。
1つ目は、PoC権限の放置だ。検証のために広い権限を付けたまま、本番に近い業務で使い続ける。検証が終わったら、権限を見直す日付を必ず設定する。
2つ目は、個人トークンの利用だ。担当者のGitHub、Slack、Google Drive、クラウドAPIトークンをAIエージェントへ接続すると、操作主体が曖昧になる。退職・異動・漏えい時にも止めにくい。
3つ目は、ログ未整備だ。便利に動いたことだけを見て、どのデータを読み、どのツールを呼び、どの出力を送ったかが残らない。事故時に説明できないシステムは、業務利用の範囲を広げるべきではない。
4つ目は、禁止だけで運用することだ。「顧客情報を入れない」「重要操作は禁止」と書くだけでは、現場の判断は揃わない。許可されるデータ、許可される操作、承認が必要な操作を具体的に定義する。
AIエージェント導入の初期成功は、作業時間削減だけで測らない。誰の権限で、どのデータに触れ、どの操作を行い、問題が起きたら止められるかを説明できる状態になっているかを見る。
参考情報
AIエージェントの統制は、技術、ガバナンス、データ保護が重なる領域だ。細部は利用する製品や契約によって変わるため、公式ドキュメントと自社の情報管理規程を合わせて確認したい。
- NIST AI Risk Management Framework
- OWASP GenAI Security Project: Agentic AI Threats and Mitigations
- OWASP GenAI Security Project: Top 10 for Agentic Applications
- CISA: AI Data Security Best Practices
まとめ：AIエージェントは導入前に「権限」と「停止」を決める
AIエージェントは、文章生成ツールではなく、社内データと業務システムに接続する実行者として扱う必要がある。導入前に決めるべきことは、モデル名やプロンプトよりも、データ分類、権限範囲、承認ゲート、ログ、停止手順だ。
まずは用途を「読むだけ」「下書きする」「実行する」に分ける。実行する用途では、専用ID、最小権限、人間承認、監査ログ、緊急停止を必須にする。PoCで広い権限を渡した場合は、終了日と見直し日を設定する。
次に読むなら、権限設計の基礎として 最小権限の原則 と 認証と認可の違い を確認し、運用チェックとして SaaS権限棚卸しチェックリスト へ進むとよい。AIエージェントを安全に使う第一歩は、便利さより先に「どこまで任せるか」を決めることだ。
