IAM（Identity and Access Management）は、誰が、どのシステムに、どの権限でアクセスできるかを管理する仕組みである。AIエージェントがAPI、ファイル、チケット、CRMなどを操作する時代には、人間ユーザーだけでなく、エージェント自身と実行セッションも認証・認可の対象として扱う必要がある。
エージェント時代のIAMとは
エージェント時代のIAMとは、人間、アプリケーション、AIエージェント、外部ツールを別々の実行主体として識別し、最小権限で業務を委任するための認証・認可設計である。NIST SP 800-63-4はデジタルID、認証、フェデレーションを扱う指針であり、NIST SP 800-207はゼロトラストにおいてアクセス要求ごとに主体、資産、環境を評価する考え方を示している。[1][2]
従来のIAMでは「社員がログインしたか」「サービスアカウントがAPIを呼んだか」を分けて考えることが多かった。AIエージェントでは、その中間に「社員から委任されたエージェントが、特定の目的で、特定のツールを実行する」という新しい層が入る。
| 主体 | 例 | IAMで管理すること |
|---|---|---|
| 人間ユーザー | 社員、委託先、管理者 | 本人確認、MFA、所属ロール、承認権限 |
| ワークロード | バッチ、API、CI/CD、RPA | サービスID、短期トークン、実行環境、秘密情報の分離 |
| AIエージェント | 営業支援エージェント、経理確認エージェント、開発支援エージェント | エージェントID、委任元ユーザー、許可ツール、実行目的、承認ゲート |
AIエージェントで増えるIAMの概念
AIエージェントは自然言語の指示を受け、外部システムを操作する。OWASP Agentic AIは、ツール乱用、過度な自律性、権限昇格、エージェントなりすまし、連鎖障害などをエージェント固有の脅威として整理している。[7] そのため、IAMでは次の概念を明示する必要がある。
エージェントID
エージェントIDは、AIエージェントそのものを識別するIDである。人間のユーザーIDや汎用サービスアカウントを共有させず、エージェントごとに「どの業務を担当する主体か」を分ける。
例として、営業支援エージェント、経理確認エージェント、セキュリティ一次対応エージェントは別IDにする。同じモデルを使っていても、業務目的とアクセス先が異なるためである。
委任元ユーザー
委任元ユーザーは、エージェントに作業を依頼した人間である。エージェントの行動を「誰が依頼したか」と切り離すと、監査時に責任範囲が追えなくなる。
良いログは user_id、agent_id、session_id、tool_id、purpose、approval_id を同時に残す。単に「service-account が実行した」とだけ記録するログでは、AIエージェント時代の監査には不足しやすい。
実行セッションID
実行セッションIDは、1回の依頼、計画、ツール実行のまとまりを追跡するIDである。AIエージェントは複数のツールを連続実行するため、個々のAPI呼び出しだけでなく、どの依頼から派生した操作かを束ねて記録する。
ツールスコープ
ツールスコープは、エージェントが使えるツールと操作を限定する範囲である。MCPの認可仕様はOAuth 2.1を基盤として扱い、MCPセキュリティベストプラクティスはユーザー同意、データプライバシー、ツール安全性を主要な論点として扱っている。[5][6]
ツールスコープは「CRMを読む」「提案書ドラフトを作る」「メール送信は承認後だけ」のように、業務行為単位で切る。単に「営業ツール全部」や「Google Workspace全部」のように広げると、間接プロンプトインジェクションや誤操作時の影響が大きくなる。
人間・ワークロード・エージェントを分ける
エージェント時代のIAMでは、人間ID、ワークロードID、エージェントIDを混ぜないことが基本である。AWS IAMのベストプラクティスは、人間ユーザーにはIDプロバイダーとのフェデレーション、ワークロードには一時的な認証情報とIAMロールの利用を推奨している。[3] Google CloudのWorkload Identity Federationも、外部ワークロードに長期キーを持たせず、外部IDを短期的なクラウド認証情報へ交換する考え方を示している。[4]
AIエージェントでも同じ考え方を使う。エージェントに人間のパスワードや長期APIキーを渡さず、短時間だけ有効なトークンを発行する。トークンには、エージェントID、委任元ユーザー、実行目的、利用できるAPI、対象データ分類を含める。
人間ユーザー
-> SSO / MFA / 所属ロール
-> エージェントへ作業を委任
-> 短期トークンを発行
-> エージェントが許可済みツールだけを実行
-> 監査ログに user_id + agent_id + session_id を記録この分離により、人間の退職、部署異動、権限変更が起きても、エージェント側の権限を独立して見直せる。
企業ロール別の認可設計例
AIエージェントのロール設計では、職種名をそのまま権限にしない。業務行為、対象データ、実行環境、承認要否に分解する。以下はこの記事で使う設計例であり、各社の実際の権限はデータ分類と業務フローに合わせて調整する。
| ロール | エージェントの主な用途 | 許可する操作 | 承認が必要な操作 | 禁止する操作 |
|---|---|---|---|---|
| 営業 | 提案書作成、顧客情報の要約 | 担当顧客のCRM読み取り、承認済みテンプレート参照 | 外部メール送信、大量エクスポート | 全社顧客データの一括取得、価格条件の自動確定 |
| カスタマーサポート | 問い合わせ分類、返信案作成 | チケット読み取り、FAQ参照、返信ドラフト作成 | 返金、契約変更、個人情報を含む返信送信 | 顧客認証状態の変更、全履歴の一括出力 |
| 経理 | 請求書照合、支払候補の整理 | 請求書・発注書の読み取り、差分検出 | 支払承認、銀行振込、仕訳確定 | 承認者の変更、支払先口座の自動変更 |
| 人事 | 社内規程検索、入社手続き補助 | 公開済み規程の検索、手続きチェックリスト作成 | 評価情報・給与情報の閲覧、雇用条件通知 | 評価確定、給与変更、懲戒判断 |
| 開発 | コードレビュー支援、Issue整理 | 対象リポジトリ読み取り、ブランチ作成、テスト実行 | mainブランチへのマージ、本番デプロイ | 本番シークレット閲覧、IAMポリシー変更 |
| セキュリティ | アラート一次分類、証跡収集 | ログ読み取り、チケット作成、既知IOC照合 | 端末隔離、アカウント停止、外部通報 | 監査ログ削除、検知ルールの無承認変更 |
ロール別の基本方針は、読み取り・ドラフト・提案をエージェントに任せ、削除・送信・支払・権限変更・本番反映を承認付きにすることである。OWASP LLM Top 10 2025は、過度な自律性と機密情報漏えいをLLMアプリケーションの主要リスクとして扱っているため、エージェントには「できること」だけでなく「できないこと」を明示する。[8]
RBAC、ABAC、JITを組み合わせる
AIエージェントのIAMでは、RBACだけでは粒度が粗くなりやすい。実務では、RBAC、ABAC、JITを組み合わせる。
| 方式 | 意味 | AIエージェントでの使い方 |
|---|---|---|
| RBAC | 役割ベースのアクセス制御 | 営業、経理、開発、セキュリティなどの基本ロールを決める |
| ABAC | 属性ベースのアクセス制御 | 部署、担当顧客、データ分類、環境、時間帯、リスクスコアで絞る |
| JIT | 必要な時だけ一時的に昇格する権限 | 例外的な調査や本番作業だけ、承認後に短時間許可する |
たとえば営業支援エージェントには role=sales だけでなく、customer_owner=user.department、data_classification<=internal、action=read_or_draft、environment=production_readonly のような条件を付ける。これにより、同じ営業ロールでも担当外顧客や高機密データへアクセスしにくくなる。
ベストプラクティス
エージェント時代のIAMで守るべき実務原則は、次のとおりである。
1. エージェントに共有管理者アカウントを使わせない
AIエージェントには専用IDを付与する。人間の管理者アカウント、共有サービスアカウント、長期APIキーを渡すと、委任元、実行目的、権限範囲を追えなくなる。
2. 実行前に権限を決め、実行後に監査できる形で残す
エージェントが計画を立ててから、必要なツールだけを許可する。実行後は、プロンプト、参照データ、ツール呼び出し、承認者、出力先をセッション単位で記録する。
3. 不可逆な操作にはHuman-in-the-loopを置く
削除、送信、支払、契約変更、権限変更、本番反映は、人間の承認を挟む。承認画面では、エージェントの要約だけでなく、実行するAPI、対象リソース、差分、取り消し可否を表示する。
4. 外部入力とツール定義を信頼しない
AIエージェントは、Webページ、メール、PDF、チケット、ツール説明文を読み込む。これらは命令ではなくデータとして扱う。MCPを使う場合も、ツール説明文やサーバー接続先を信頼境界として扱い、未検証のMCPサーバーに広い権限を渡さない。[6]
5. データ分類を認可条件に入れる
権限はシステム単位ではなくデータ分類単位で絞る。public、internal、confidential、restricted のような分類を使い、エージェントが読み取れる分類と出力できる分類を分ける。
実装チェックリスト
ID設計
- 人間ID、ワークロードID、エージェントIDを分離している
- エージェントIDに業務目的と所有チームが紐づいている
- 長期APIキーではなく短期トークンを使っている
認可設計
- RBACで基本ロールを定義している
- ABACで部署、担当範囲、データ分類、環境を条件にしている
- JITで例外的な昇格権限を短時間に限定している
- 不可逆操作に承認ゲートを置いている
監査設計
-
user_id、agent_id、session_id、tool_idを同じログに残している - ツール実行前の計画と実行後の結果を対応づけている
- 承認者、承認時刻、対象リソース、差分を記録している
- 監査ログをエージェント自身が削除・改ざんできない
まとめ
- エージェント時代のIAMでは、人間だけでなくAIエージェントと実行セッションをID管理の対象にする
- 共有管理者アカウントや長期APIキーをエージェントに渡さず、専用IDと短期トークンを使う
- 企業ロール別の認可は、読み取り・ドラフト・提案と、送信・支払・削除・本番反映を分離する
- RBAC、ABAC、JIT、Human-in-the-loop、監査ログを組み合わせることで、AIエージェントの利便性と統制を両立しやすくなる
本記事は一般的な情報整理であり、法的助言ではありません。実務判断は専門家に確認してください。
よくある質問
Q: AIエージェントには人間ユーザーと同じ権限を与えてよいですか？
A: 原則として避けるべきです。エージェントは人間よりも速く複数のツールを連続実行できるため、同じ権限でも影響範囲が広がりやすくなります。人間のロールを上限にしつつ、エージェントには業務目的、対象データ、操作種類、承認要否でさらに絞った権限を付与します。
Q: サービスアカウントとエージェントIDは何が違いますか？
A: サービスアカウントは通常、アプリケーションやバッチなどのワークロードを識別するIDです。エージェントIDは、AIエージェントという意思決定・ツール選択を行う実行主体を識別します。実装上はクラウドIAMのサービスアカウントやワークロードIDを使う場合でも、監査上はどのエージェントがどの人間から委任されて動いたかを分けて記録します。
Q: 小規模チームでもABACやJITは必要ですか？
A: 最初から複雑なポリシーエンジンを導入する必要はありません。ただし、最低限として「本番」「顧客データ」「外部送信」「削除」「権限変更」だけは属性として分け、必要な時だけ承認付きで許可する設計にしておくと、後から統制を拡張しやすくなります。
参考文献
- NIST, Digital Identity Guidelines (SP 800-63-4), 2025年7月
- NIST, Zero Trust Architecture (SP 800-207), 2020年8月
- AWS, Security best practices in IAM
- Google Cloud, Workload Identity Federation
- Model Context Protocol, Authorization
- Model Context Protocol, Security Best Practices
- OWASP, Agentic AI - Threats and Mitigations, 2025年2月17日
- OWASP, OWASP Top 10 for LLM Applications 2025, 2024年11月17日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。