この記事で扱うこと
AIエージェントをデモから本番運用に移すとき、「このアクション、誰がやったの？」 という質問に答えられなくなるケースが頻発します。
原因は単純で、エージェントに明確なアイデンティティ（ID） がなく、委任元のユーザーやワークフローと紐づいていないからです。
本記事では、以下の観点で実務的な設計パターンを整理します。
- エージェントにIDが必要な理由（監査・説明責任・信頼境界）
- 静的ロールでは不十分な理由（コンテキスト依存の権限）
- 委任された権限（Delegated Authority）のモデル化
- 実装パターン（サービスID、ポリシーエンジン、権限レイヤー、監査ログ）
- まだこのパターンが適さないケースと危険信号
エージェントは「匿名スクリプト」ではない
従来のエンタープライズアーキテクチャでは、アクターは「人間」「アプリケーション」「サービスアカウント」「スケジュールジョブ」のいずれかでした。
Agentic AI はここに**「推論し、ツールを選択し、複数ステップを自律的に実行するデジタルアクター」**という新しいカテゴリを追加します。
このエージェントを、単なるバックグラウンドの匿名スクリプトとして扱うと、本番で次の3つが不明瞭になります。
- 誰がアクションを実行したのか
- 誰の委任（マンデート） で動いたのか
- どのワークフローの文脈で発生したのか
たとえば、購買エージェントが発注依頼をERPにドラフトしたとき、そのログが汎用サービスアカウントのものだけだったらどうでしょう？
「あのユーザーが依頼したのか」「スケジュールジョブが動いたのか」「誰かが権限を悪用したのか」——区別がつきません。
エージェントがビジネス状態を変更し始めた瞬間、そのIDは人間やアプリケーションと同等に追跡可能でなければなりません。
静的ロールではエージェントの権限は足りない
「エージェントにロールを割り当てればOK」——これは古いミスの新しい形です。
エージェントの権限にはコンテキストが必要です。
- このアクションは、特定ユーザーの指示か、スケジュールか、イベントトリガーか？
- 読み取りか、ドラフトか、実行か、承認支援か？
- データは一般情報か、機密（給与・取引先銀行・契約・顧客データ）か？
同じエージェントでも、「請求書データを読む」「差異の説明をドラフトする」「解決策を推奨する」 は許可しても、「支払ブロックを解除する」 は許可しない——という粒度が必要です。
実装の基本は、権限をレイヤーで分けることです。
| レイヤー | 意味 | 例 |
|---|---|---|
| Read | 読み取り | 仕訳帳を読む |
| Recommend | 推奨 | 処理方法を提案 |
| Draft | ドラフト作成 | コメントを下書き |
| Execute | 実行（低リスク） | ステータス変更 |
| Approve | 承認 | 決裁権限（通常は人間） |
このレイヤーをポリシーエンジンで評価することで、「読み取りはOK、実行はNG」のような制御が可能になります。
委任された権限（Delegated Authority）のモデル化
エージェントのアクションの多くは、エージェント自身に帰属するものではありません。
「ユーザーの指示」「承認済みワークフロー」「自律イベントトリガー」 という委任元（Source of Mandate） があります。
この委任元は区別可能でなければなりません。
- 購買エージェントがバイヤーのために発注依頼をドラフトする
- 財務クローズエージェントがスケジュールで夜間チェックを実行する
- IT運用エージェントが監視イベントに応答する
監査証跡には、委任元の情報、エージェントID、有効期間、使用ツール、ポリシー準拠の有無を記録します。
委任には境界を設けます。
- 取消可能：インシデント時に即座に権限を剥奪できる
- 時間制限：特定の時間帯のみ有効
- スコープ制限：特定のデータソースやツールのみ
- 金額制限：標準発注は閾値まで、それ以上は人間の承認が必要
実装パターン：エンタープライズでやるべきこと
シンプルにまとめると、以下の4つを整備すれば、ほとんどのケースはカバーできます。
1. エージェントに個別のサービスIDを付与する
汎用サービスアカウントを共有しない。
エージェントごとに、以下の属性を管理します。
- エージェントID（一意）
- ビジネスオーナー
- テクニカルオーナー
- プロセスドメイン（購買、財務、カスタマーサポート…）
- 許可ツールリスト
- リスクティア（低/中/高）
- ライフサイクルステータス（開発/テスト/本番/停止）
2. ツール呼び出しをポリシーエンジンに通す
ランタイムのアクセス評価は、セッション開始時だけでなく、ツール呼び出しのたびに行います。
# 擬似コード：ポリシー評価のイメージ
def call_tool(agent_id, tool_name, input_data, mandate_source):
policy_result = policy_engine.evaluate(
agent=agent_id,
tool=tool_name,
action_type=classify_action(input_data), # read / draft / execute
mandate=mandate_source,
context=get_current_context()
)
if not policy_result.allowed:
raise PermissionDenied(policy_result.reason)
return tool.execute(input_data)
3. 権限レイヤーを実装する
前述の Read / Recommend / Draft / Execute / Approve を、APIやツールごとにマッピングします。
- 財務エージェント：Read（仕訳帳）、Recommend（処理方法）、Draft（コメント）→ OK
- 財務エージェント：Execute（支払ブロック解除）→ NG（人間にエスカレーション）
- 購買エージェント：Read（契約書）、Draft（発注依頼）→ OK
- 購買エージェント：Approve（発注承認）→ NG
4. 監査ログに「決定チェーン」を記録する
最終的なAPI呼び出しだけでなく、以下の情報を連結して記録します。
- 委任元（ユーザーID / ワークフローID / イベントID）
- エージェントID
- ポリシー評価結果（許可/拒否、理由）
- ツール呼び出し（入力、出力）
- 承認プロセス（必要な場合）
- 最終的な状態変更
これが再構築できない場合、そのエージェントは本番スケールに耐えられません。
このパターンがまだ適さないケース
以下の危険信号が複数ある場合、エージェントをスケールするとリスクが価値を上回ります。
- 汎用サービスアカウントを共有している
- 「とりあえず動かすために」権限を広く与えている
- Read / Draft / Execute の区別がない
- 委任元を明示的に記録していない
- ツール呼び出しがポリシーエンジンを経由していない
- 監査ログが最終出力しか記録していない
- インシデント時にエージェントの権限を即座に剥奪できない
- ビジネスオーナーがエージェントの使用ツールとデータを正確に把握していない
また、以下のような領域では、実行権限（Execute） をエージェントに与えるのはまだ時期尚早です。
- ロールバックが困難な重要トランザクション
- ポリシー定義がランタイムルールに落とし込めていない
- データが不安定（スキーマ変更が多い、品質が低い）
- プロセスオーナーシップが不明確
こうした場合は、Read / Recommend / Draft に限定し、ID管理とポリシー基盤を先に固めるほうが安全です。
まとめ：本番で問われる3つの質問
明日、監査部門やリスク委員会から次の質問が来たとき、あなたのチームは証拠を持って答えられますか？
- このアクションを実行したのは誰か？
- そのアクションは誰の委任に基づくのか？
- なぜシステムはそれを許可したのか？
答えがまだ明確でないなら、次に優先すべきは「より賢いモデル」ではありません。
アイデンティティ、権限委任、ポリシー評価、監査——AIエージェントを信頼できるデジタルアクターにするための基盤です。