経費精算エージェントが請求書を読み、会計SaaSへ登録し、支払候補まで作る。ここで社員のAPIキーをそのまま渡すと、ログには社員名しか残りません。本人が画面で登録したのか、エージェントが誤った取引先へ登録したのか、乗っ取られた実行環境が操作したのかを分けられなくなります。
設計の答えは明快です。AIエージェントには人のパスワードや共有APIキーを持たせません。依頼した人、エージェント、動いているプロセス、呼び出すツールを別のIDとして認証し、「誰のために、何を、いつまで」という委任情報を操作ごとに渡します。
制度・設計の確認日は2026年9月1日です。NIST、SPIFFE、OWASPの資料から企業内AIエージェントのIDと権限を組み立てます。NISTのAIエージェントID文書には検討中のコンセプトや標準化活動も含まれるため、確定規格と同じようには扱いません。既存のIAM、OAuth、ワークロードID、監査の原則で今できる対策を分けます。
一つの操作に四つの主体がいる
エージェント名だけでは、依頼者と実際の実行体を区別できません。
「田中さんがエージェントへ出張予約を頼んだ」という一文には、少なくとも四つの主体がいます。依頼者の田中さん、予約業務を表すエージェント、エージェントコードが動く実行環境、航空・経費・カレンダーなどの外部ツールです。基盤モデル提供者やプラグインを含めれば、境界はさらに増えます。
人のIDは雇用、所属、役職、休職・退職に結び付きます。エージェントの論理IDは用途、所有部門、版、承認されたツールへ結び付きます。ワークロードIDは、どのクラウド、コンテナ、端末で動くプロセスかを証明します。ツール用トークンは、一つの操作へ必要な権限と期限だけを持たせます。
「AIアシスタント用サービスアカウント」を全社で共有すると、四つの主体が一行へ潰れ、退職者の委任だけを止めることも、壊れた一版だけを隔離することもできません。
NISTが2026年に公表したコンセプトペーパーの案内は、ソフトウェア・AIエージェントについて識別、認証、認可、監査、否認防止、プロンプトインジェクションへの対策を検討対象に挙げています。これは新しい「AI専用ID製品を買う」指示ではありません。既存のID基盤で主体を分け、欠けている委任文脈を補う出発点です。
共有APIキーが危険なのは、漏れるからだけではない
保管の強さだけでなく、用途、期限、失効、追跡可能性を見ます。
長期APIキーは保管場所から漏れる危険があります。それに加え、権限の出所が分からない、目的外利用を制限しにくい、期限がない、利用者ごとに失効できない、再利用されても区別できないという運用上の問題があります。
OWASP Non-Human Identities Top 10は、オフボーディング不備、秘密情報漏えい、第三者NHI、弱い認証、過剰権限、長期シークレット、環境間再利用、人によるNHI利用などを挙げます。AIエージェントはこれらを新しく生んだのではなく、実行回数と接続先を増やして影響を広げます。
開発環境と本番環境で同じキーを使えば、テスト用エージェントのプロンプトインジェクションから本番データへ届くかもしれません。人が障害対応のためサービスアカウントへ直接ログインすると、後のログで人と自動処理を判別できません。
秘密情報を金庫へ保存するだけでは、長期・共有・過剰権限という設計上の弱点は残ります。鍵を守る対策と、鍵を短命・用途限定にする対策は別です。
実行環境を確認して短命資格情報を発行すれば、コードや設定ファイルへ長期キーを埋め込まずに済みます。
ワークロードIDで「どこで動く何者か」を証明する
SPIFFEは、動的で異種の環境にあるソフトウェアシステムを識別する標準群です。Workload APIを通じ、実行中のワークロードが暗号学的IDを取得し、他サービスが検証できます。クラウド固定のキーを配るのではなく、信頼された実行環境であることを確認して短い証明書やトークンを渡す考え方です。
ただし、ワークロードIDが「経費エージェントの本番版である」と証明しても、「田中さんの出張を上限5万円で予約してよい」ことまでは証明しません。そこで、人からエージェントへの委任情報と、エージェントからツールへのアクセス情報を結びます。
ゼロトラスト導入ロードマップの「毎回確認する」を、ネットワークだけでなくエージェント実行へ適用します。実行環境、コード版、依頼者、対象データ、操作、時間が条件から外れたら、同じエージェント名でも拒否します。
NIST SP 800-207も、ネットワーク上の場所だけを信頼せず、主体と資源へのアクセスを動的な方針で判断する考え方を示しています。エージェントでは、起動時に一度通すだけでなく、外部ツールを呼ぶ時点の依頼者、実行環境、対象、操作を再評価します。
委任は「本人と同じ権限」ではなく目的を渡す
自然言語の依頼を、操作・対象・上限・期限へ変換します。
人が持つ全権限をエージェントへコピーする必要はありません。出張予約なら、指定期間の候補検索、社内規程内の便選択、仮押さえまで許し、決済は人の再承認後に限定できます。メール整理なら、分類と下書きは許し、外部送信や一括削除を分けます。
委任情報には、依頼者、エージェント、許可する操作、対象リソース、金額・件数、開始・終了時刻、再委任可否、承認要否を入れます。自然言語の「いつものように処理して」は監査可能な権限条件ではありません。エージェントが解釈した作業計画を構造化し、高リスク操作の直前に人へ見せます。
人の承認は「AIの利用を許可します」という一回の同意ではなく、送金先、金額、公開範囲、削除対象など、取り返しにくい操作の直前で取ります。承認画面は、モデルの長い推論ではなく、実行されるAPI、対象、差分、最大影響を表示します。
再委任の鎖を切らない
一つのエージェントが調査エージェント、予約エージェント、決済エージェントを呼ぶ場合、子エージェントへ親より広い権限を渡してはいけません。委任の鎖には、最初の依頼者、各エージェント、縮小された権限、有効期限を残します。
外部のエージェントサービスへ渡す時は、相手が受け取るデータ、再学習、ログ、下請、資格情報の保管、事故通知、削除を契約で確認します。AIエージェント導入ガバナンスで業務選定を行い、機密・操作権限が高い業務は内部実行や強い分離を選びます。
監査ログは会話全文ではなく因果を残す
誰の依頼がどの外部変更へ至ったかを一件ずつ復元できるようにします。
プロンプトと回答だけを保存しても、外部ツールで何が変わったかは分かりません。監査では、依頼ID、人ID、エージェントID、コード・モデル・ポリシー版、ワークロードID、取得したトークン、呼び出したAPI、対象、結果、承認、エラー、取消しを時系列で結びます。
会話には個人情報や機密が含まれるため、何でも永久保存するのも危険です。証拠に必要な構造化イベントと、内容を含む詳細ログを分け、閲覧権限と保存期間を設定します。モデルの内部推論を保存すれば説明責任が自動で満たされるわけではありません。再現に必要な入力、参照データ、ツール結果、ルール版を優先します。
監査で答えるべき質問は「AIが何を考えたか」ではなく、「誰の権限を使い、どの条件で、何へ、どんな変更を行い、誰が止められたか」です。
依頼、委任、実行、外部API、変更結果を同じ相関IDで結ぶと、事故時に影響範囲を切り分けられます。
AIインシデント対応計画には、特定エージェントの停止、資格情報失効、誤変更の取消し、影響対象への連絡を入れます。全AIを停止するか、何も止めないかの二択にせず、エージェントID、版、利用者、接続先ごとに隔離できるようにします。
五つの失効を一つの操作で連動させる
人、委任、エージェント、実行環境、外部トークンの残存経路を閉じます。
社員が退職した時、人IDだけを無効にしても、その人が作った自動化や個人トークンが残る場合があります。エージェントを廃止した時も、クラウド権限、外部SaaS同意、保管シークレット、スケジュール、Webhookが残れば動作を再開できます。
失効は、人の所属変更、委任終了、エージェント廃止、実行環境の信頼失効、外部ツールのトークン取消しの五つを連動させます。所有者不明、90日未使用、終了したプロジェクト、期限切れ証明書、参照されないキーを定期検出します。
オフボーディングの完成条件はアカウント削除ではなく、残った自動実行経路から同じ操作を再現できないことです。本番と開発の両方でテストし、拒否ログまで確認します。
権限をロールではなく「予算」として配る
従来のロールは、経費担当、開発者、管理者のように機能を束ねます。AIエージェントへ同じ束を渡すと、短時間に人より多くの処理を実行できます。操作権限に加え、一回の金額、一日の合計、対象件数、呼出し頻度、データ量という予算を設けます。
例えば返金エージェントには、一件一万円以下、同一顧客は一日一回、日次合計十万円までを自動許可し、超過は人へ戻します。権限上は返金APIを呼べても、予算を使い切れば追加実行を拒否します。攻撃や誤ループで正規APIが繰り返し呼ばれる場面に効きます。
予算は部門全体と個別エージェントの両方へ置きます。複数エージェントが同じ顧客へ別々に処理し、個別上限をすり抜けるためです。通貨、時間帯、地域、取引先の新規・既存も条件にできます。
高リスク操作は、予算内でも人の承認を残します。人の承認を形骸化させないため、同じ種類の承認が連続する時は一括許可せず、異常な増加を通知します。承認者が内容を読まず通す率も監査対象です。
ID台帳はモデル台帳と分けて結ぶ
同じモデルを使う二つのエージェントでも、接続先と権限が違えばリスクは違います。モデル台帳には提供者、版、評価、データを、エージェント台帳には業務所有者、ツール、委任、ワークロード、停止方法を記録し、相互参照します。
モデルを更新した時は、権限が変わらなくてもツール選択や承認要求の挙動が変わる可能性があります。エージェント側の回帰試験を起動し、許可済み操作、拒否すべき操作、予算超過、ログ相関を再確認します。AIモデル台帳管理と二重登録にせず、モデル版をキーに実行権限へつなげます。
一つの経費エージェントで設計を試す
最初の対象を経費登録とします。請求書読取は低リスク、取引先マスタ新規登録は中リスク、振込確定は高リスクと分けます。読取は経費フォルダだけ、登録は一件ごとの上限と重複確認、振込は人の再承認と別経路の多要素認証を要求します。
テストでは、請求書内の指示文、別社員のフォルダ参照、同一請求の再実行、金額桁違い、退職者の委任、開発環境からの本番呼出し、承認後の対象差し替えを試します。成功率だけでなく、拒否率、過剰承認、資格情報寿命、失効時間、監査追跡率を測ります。
AIレッドチーミング実践ガイドを使い、プロンプト単体ではなくID・ツール・ログを含む一続きの攻撃面を検証します。エージェントが危険な提案をしたが実行権限で止まった場合と、提案は穏当でも過剰権限で外部変更できた場合を分けて評価します。
導入前の最小チェックリスト
エージェントごとに業務所有者と技術所有者がいるか。利用者本人の資格情報を保存しないか。実行環境を認証できるか。外部トークンは短命か。権限は操作・対象・上限・期限で狭められるか。高リスク操作は直前承認か。子エージェントへ権限が拡大しないか。相関IDで結果まで追えるか。個別停止と失効を試したかを確認します。
一つでも「後でログを見れば分かる」と答えた項目は、実際にログから一件を復元します。一つでも「管理者権限が必要」と答えた項目は、必要なAPIだけへ縮小します。デモ環境の成功ではなく、誤入力、期限切れ、障害、退職、外部サービス停止を含む運用で判定します。
AIエージェントの安全性は、モデルが賢いかだけでは決まりません。間違える前提で、借りる権限を小さくし、短くし、追跡し、取り消せるかで決まります。
まとめ
非人間IDは、AIエージェントに名前を付けた一覧ではありません。人、エージェント、ワークロード、ツールのIDを分け、その間を期限付きの委任で結ぶ設計です。共有APIキーを秘密管理製品へ移すだけでは、誰の権限で動いたかという問題は残ります。
本番へ出す条件は、正常な一件を処理できることではなく、過剰権限を拒否し、一つだけ止め、資格情報を失効し、変更結果を人の依頼まで遡れることです。
参考情報
以下は2026年9月1日に確認した一次情報・規格情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
QAIエージェント専用のID製品が必要ですか？
A最初から専用品が必須とは限りません。既存IAM、ワークロードID、OAuth、秘密管理、監査基盤で主体を分け、委任文脈と一件停止に足りない機能を特定します。
QAPIキーを秘密管理サービスへ保存すれば安全ですか？
A漏えい対策にはなりますが、共有、長期、過剰権限、利用者別失効、目的外利用の問題は残ります。実行環境を認証し、短命で対象限定の資格情報を発行します。
Qエージェントに社員と同じ権限を渡してよいですか？
A原則として必要な操作だけへ縮小します。検索、下書き、登録、送信、決済を分け、取り返しにくい操作は実行直前に人が対象と差分を承認します。
Q監査のため会話をすべて保存すべきですか？
A会話には個人情報や機密が含まれます。依頼、委任、版、API、対象、結果、承認を構造化して残し、内容を含む詳細ログは目的、閲覧者、保存期間を限定します。
Q複数のAIエージェントが連携する場合はどうしますか？
A子エージェントへ親より広い権限を渡さず、最初の依頼者からの委任鎖、縮小された権限、有効期限を保ちます。外部サービスへ越える境界ではデータと再委任を契約で確認します。
Q退職者のアカウントを削除すれば止まりますか？
Aその人が作った委任、個人トークン、スケジュール、Webhook、エージェント所有権が残る場合があります。関連する五つの失効を連動させ、実際に操作が拒否されることを試します。
