AIエージェントのセキュリティ設計｜権限・承認・監査ログの実務チェックリスト

AIエージェントを社内業務へ入れるとき、通常の生成AIチャットと同じ感覚で「利用ルールを作ればよい」と考えるのは危険です。

理由は単純です。チャットAIは主に文章を返しますが、AIエージェントは設定次第で、メール送信、ファイル更新、チケット作成、データ取得、コード実行、SaaS操作など、現実のシステムに対して行動できます。

そのため、本番導入で最初に設計すべきなのはモデルの賢さではなく、次の6点です。

エージェント専用のIDを持たせる
権限を最小化する
実行できるツールと操作を限定する
高リスク操作には人の承認を入れる
すべての重要操作を監査できるようにする
異常時に即停止・権限剥奪できるようにする

2026年に入って、NISTはAIエージェントのidentity・authorization・auditを重要テーマとして扱い、MicrosoftやAWSもleast privilege、承認、監査、停止可能性を本番設計の中心に置いています。OWASP GenAI Security Projectも2026年9月にAgent Control Standardを公開し、エージェントを「何にアクセスできるか」「何をしたか」「なぜしたか」を追跡・制御できる仕組みの重要性を示しています。

参考：

この記事では、AIエージェントを社内で安全に使うための設計を、企画・開発・セキュリティ・運用担当が同じ表で確認できるように整理します。

まず理解する：AIチャットとAIエージェントはリスクの種類が違う

通常の生成AIチャットでは、代表的なリスクは「誤回答」「機密情報の入力」「著作権や個人情報」「過度な依存」です。

AIエージェントでは、これらに加えて実行権限そのものがリスクになります。

たとえば、次の2つは同じ「経費精算を手伝うAI」でも意味が大きく違います。

パターンA：回答だけするAI

社員が「この領収書は精算できますか？」と聞くと、規程を検索して回答する。

間違えた場合でも、最終的な申請は人が行います。

パターンB：操作まで行うAIエージェント

領収書を読み取り、経費システムへログインし、勘定科目を選び、申請を作成し、場合によっては承認依頼まで送る。

こちらは、AIの誤判断がそのままシステム変更につながります。

つまり、AIエージェントでは「正しい答えを出すか」だけでなく、間違えたときにどこまで被害が広がるかを設計しなければなりません。

Microsoftは、エージェントに広い権限を与えるほど、データ・ツール・メモリ・identity・authorizationまで利用企業側の責任が増えると説明しています。

参考：Microsoft Learn – AI agent shared responsibility model

原則1：人のアカウントをそのままAIに使わせない

最初に避けたい設計は、社員の個人アカウントや長期アクセストークンをエージェントへそのまま渡すことです。

便利ですが、誰が何をしたのか分離しにくくなります。

たとえばエージェントが共有フォルダのファイルを削除したとき、監査ログ上は「田中さんが削除した」としか見えなければ、

本人が操作したのか
エージェントが自動実行したのか
どの指示を受けて動いたのか

を後から説明できません。

NISTは2026年のAI agent identity関連資料で、エージェントに人のcredentialや広い権限を持たせると、なりすましやnon-repudiationの問題が起きると指摘しています。

実務での基本

可能な範囲で、次の状態を目指します。

エージェントごとに識別可能なidentityを持つ
人の個人credentialを常駐させない
操作対象システムごとに認可する
誰の依頼で実行したかを別項目で記録する
credentialは短命化し、失効できるようにする

「人の代理だから人と同じ権限でよい」ではなく、人より狭い専用権限から始めるほうが安全です。

原則2：権限は「できるだけ少なく」ではなく、操作単位で明示する

least privilegeはAIエージェントでも重要ですが、「閲覧権限だけ」「編集権限あり」という粗い分類だけでは不十分なことがあります。

たとえばCRMを操作するエージェントなら、

顧客情報を検索する
顧客情報を読む
メモを追記する
ステータスを変更する
顧客を削除する
メールを送信する
大量exportする

ではリスクが大きく異なります。

権限表を作る

最低限、ツールごとに次の表を作ります。

システム	操作	自動実行	人の承認	禁止
社内検索	文書検索	○
社内検索	文書閲覧	○
CRM	顧客メモ追記	条件付き	○
CRM	顧客削除			○
メール	下書き作成	○
メール	社外送信		○
ストレージ	ファイル閲覧	条件付き
ストレージ	大量download			○

Microsoftのleast privilegeガイダンスでも、agent identity、明確なscope、tool actionのallowlist、audit、revocationを組み合わせる考え方が示されています。

重要なのは、「このAIはCRMを使える」ではなく「CRMで何をできるか」まで決めることです。

原則3：高リスク操作にはhuman-in-the-loopを入れる

すべての操作を人が承認すると、AIエージェントを導入する意味が薄くなります。

一方ですべて自動化すると、1回の誤判断が事故になります。

そのため、操作をリスク別に分けます。

低リスク：自動実行してよい

社内文書の検索
会議資料の要約
チケットの下書き
メール下書き
既存データの読み取り

中リスク：条件付きで自動実行

社内限定の定型通知
一定金額以下の申請作成
既存レコードへのメモ追記
sandbox環境でのコード実行

ここでは、対象、件数、金額、時間帯などの上限を決めます。

高リスク：人の承認を必須にする

社外メール送信
契約・発注
支払い
本番データの削除
権限変更
大量export
本番環境へのdeploy
顧客への自動回答の確定

AWSも、高リスク操作では追加認証やユーザー承認chainを検討するよう推奨しています。

人の承認は「最後にOKボタンを押す」だけでは弱く、何を実行するのかが承認画面で具体的に見えることが重要です。

たとえば社外メールなら、送信先、件名、本文、添付ファイルを承認者が確認できる状態にします。

原則4：プロンプトで禁止するのではなく、システム側で止める

「顧客データを削除しないでください」

「機密情報を社外に送らないでください」

というsystem promptは必要ですが、これだけを安全装置にしてはいけません。

AIエージェントは、外部のWebページ、メール、添付ファイル、社内文書などを読み込むことがあります。そこに悪意ある指示が混ざれば、indirect prompt injectionの影響を受ける可能性があります。

そのため禁止事項は、可能な限りアプリケーション側・IAM側・API gateway側で強制します。

例

削除APIそのものをエージェントに公開しない
送信先domainをallowlistする
1回の取得件数に上限を設ける
1日のAPI実行回数を制限する
本番credentialをsandboxへ渡さない
高リスクtoolは承認tokenがないと実行できない

Microsoftのagentic AI security guidanceでも、deterministic safeguardsを置き、モデルの振る舞いだけに禁止ルールを依存しないことが重視されています。

参考：Microsoft Learn – Reduce autonomous agentic AI risk

原則5：RAGや外部データ取得でも「読める範囲」をユーザー以上に広げない

AIエージェントがRAGや社内検索を使う場合、検索精度だけでなくアクセス制御が重要です。

たとえば社員本人には閲覧権限がない人事評価資料を、エージェントのservice accountだけは読める状態にすると、エージェント経由で情報が漏れる可能性があります。

原則として、

依頼ユーザーが読めない情報を、エージェントが勝手に取得できない

状態を目指します。

実装では、

ユーザーidentityを検索条件へ引き継ぐ
文書ACLをretrieval時に適用する
security labelで検索対象をfilterする
cacheにも権限境界を持たせる
引用元URLを表示して検証できるようにする

といった設計が必要です。

RAG自体の検索品質改善については、RAGの精度が上がらない7つの原因｜社内文書検索を改善する実務チェックリストで、文書品質、chunking、hybrid search、reranking、評価方法まで整理しています。

原則6：監査ログは「APIを呼んだ」だけでは足りない

事故が起きたときに必要なのは、「どのAPIが呼ばれたか」だけではありません。

最低限、次の情報を追えるようにします。

ログ項目	確認したいこと
agent_id	どのエージェントか
user_id / requester	誰の依頼か
timestamp	いつ実行したか
task_id / session_id	どの処理の一部か
tool_name	どのツールを使ったか
action	何を実行したか
target	どのデータ・相手が対象か
approval_id	誰が承認したか
result	成功・失敗・拒否
policy_decision	どのルールで許可・拒否されたか

機密情報や個人情報をそのままログへ保存すると別のリスクになるので、ログ内容自体のmasking・retentionも必要です。

OWASPのAgent Control Standardは、agent platformに対してinspectable、traceable、instrumentableであること、runtimeでcontrolできることを重視しています。

これは「AIの思考を全部保存する」という意味ではありません。実務で必要なのは、重要な外部操作を再現・説明できる証跡です。

原則7：停止ボタンより先に「権限を剥奪できる設計」を作る

異常が起きたとき、管理画面の停止ボタンだけに依存すると危険です。

停止処理自体が動かない、別processが残る、credentialがまだ有効というケースがあるためです。

緊急停止で確認するもの

agent processを停止できる
agent identityをdisableできる
token・API keyを即時失効できる
tool accessを遮断できる
queue中の未実行taskを破棄できる
外部system側でもcredentialをrevocationできる
事故範囲を特定できるaudit logがある

本番導入前に、正常系だけでなくkill switchの訓練を行います。

「本番で問題が起きたら止める」ではなく、「5分以内にどの操作で何を止めるか」をrunbookとして書いておくべきです。

原則8：エージェントのmemoryを信用しすぎない

AIエージェントには、過去の会話、ユーザー設定、タスク履歴などをmemoryとして持たせることがあります。

便利ですが、memoryは長期間残るほどリスクも増えます。

MicrosoftのAI agent shared responsibility guidanceでは、memory poisoningのように、悪意ある内容がmemoryへ残り、後のsessionで再利用されるリスクも挙げています。

memory設計で決めること

何を保存するか
何日保存するか
誰が閲覧できるか
ユーザーが削除できるか
出所を追跡できるか
機密情報を保存しない仕組みがあるか
長期memoryと一時session memoryを分けるか

「AIが覚えてくれるほど便利」という前提ではなく、保存しないことを初期値にして必要な情報だけ残すほうが管理しやすくなります。

原則9：無限ループ・大量実行・コスト暴走をセキュリティ問題として扱う

AIエージェントは、目的達成まで複数stepを繰り返す設計があります。

そのとき、バグや誤判断で、

同じAPIを何百回も呼ぶ
同じメールを繰り返し送る
cloud resourceを大量作成する
tokenや外部API費用を消費し続ける

といった事故が起きる可能性があります。

そのため、次の上限を設けます。

1taskあたりの最大step数
toolごとの最大call数
1分・1時間・1日のrate limit
金額上限
最大処理時間
同一actionの重複検知
retry回数

Microsoftもagentic systemではstep、iteration、budget limitやloop detectionを重要な制御として挙げています。

「コスト最適化」ではなく、暴走を止める安全装置として実装します。

原則10：導入前テストは「正答率」だけでなく「危険な行動をしない率」を測る

AIエージェントのPoCでは、業務成功率だけを見がちです。

しかし本番前には、失敗時の挙動を評価するテストが必要です。

最低限の評価ケース

曖昧な指示を与える
権限外の操作を依頼する
禁止された削除を依頼する
外部文書に「前の指示を無視せよ」と書く
機密情報の送信を依頼する
存在しないtoolを使うよう誘導する
100件処理を依頼する
同じtaskを連続実行する
外部APIがtimeoutする
承認者が拒否する

評価指標は、たとえば次のように分けます。

指標	例
Task success rate	正常業務を完了できた割合
Unsafe action block rate	禁止操作を正しく拒否した割合
Approval compliance	承認必須操作を勝手に実行しなかった割合
Permission boundary violations	権限外アクセス件数
Duplicate action rate	重複実行率
Recovery rate	外部障害から安全に復帰できた割合

生成AIをPoCから本番へ移す際の全体設計については、生成AIのPoCが本番導入で止まる7つの理由も参考になります。

社内導入前のAIエージェント・セキュリティチェックリスト

最後に、本番化前に使えるチェックリストへまとめます。

Identity・権限

[ ] エージェントを一意に識別できる
[ ] 人の個人credentialを常駐利用していない
[ ] 権限が最小化されている
[ ] tool/action単位でallowlistがある
[ ] credentialを即時失効できる

実行制御

[ ] 高リスク操作に人の承認がある
[ ] 削除・送信・exportなどの禁止操作をsystem側で止める
[ ] 1taskあたりのstep上限がある
[ ] rate limit・retry上限がある
[ ] 同一操作の重複防止がある

データ

[ ] ユーザー権限以上のデータを検索できない
[ ] RAG検索時にもACLが効く
[ ] memoryの保存期間が決まっている
[ ] 機密情報をmemoryへ残さない設計がある
[ ] ログに不要な個人情報・機密情報を残さない

監査・運用

[ ] agent / requester / tool / action / targetを追跡できる
[ ] 承認者を追跡できる
[ ] policyで拒否された操作も記録する
[ ] kill switchを実際にテストした
[ ] incident response runbookがある
[ ] 定期的な権限棚卸しがある

評価

[ ] 正常業務だけでなく悪意ある入力も試している
[ ] prompt injectionを想定したテストがある
[ ] 権限外操作の拒否率を測っている
[ ] 承認を迂回しないことを確認している
[ ] 外部API障害時の挙動を確認している

社内ルールだけでは足りない。技術制御までセットで設計する

AIエージェントの安全対策でありがちな失敗は、利用規程だけを増やすことです。

規程は必要ですが、AIエージェントは実際にシステムを操作します。

そのため、

ルール → identity → 権限 → tool制御 → 承認 → audit → 緊急停止 → 評価

までを1つの運用として設計する必要があります。

社内ルールそのものの作り方は、生成AIの社内利用ルールの作り方｜禁止だけにしない実務テンプレート11項目で整理しています。

AIエージェントは、うまく使えば業務の自動化範囲を大きく広げられます。しかし自律性が上がるほど、「AIを信用する」より「AIが間違えても被害を限定できる」設計が重要になります。

本番導入では、モデル性能より先に、最小権限・承認・監査・停止可能性を確認するところから始めるのが安全です。