営業担当者が AI agent に頼む。「この顧客の最近の注文を調べて、その結果でサポートチケットを起票して」。人にとってはわかりやすい依頼だが、裏側のシステムにとってはいくつか大事な情報が欠けている。これを認可したのは誰か、実際に作業しているのはどの agent か、どこまでやってよいのか。

この依頼を終えるには、agent は少なくとも顧客データベースとチケットシステムという二つのシステムを通る。どこでも token、つまり「この操作をする権限がある」ことを示す電子的な通行証を提示する。ここでチームはよく二つの近道のどちらかを選ぶ。agent にみんなで共有するサービスアカウントで作業させるか、利用者がログイン時に受け取った token をそのまま下流へ渡していくかだ。どちらの近道でも処理は動く。そしてどちらも、問題が起きたとき誰が何を認可したのかをわからなくする。

より手堅いやり方はこうだ。agent が次のシステムへ進むたびに、そのシステム専用で、今回の作業に必要な権限だけを持つ新しい token に替える。

二つの近道それぞれの問題

共有サービスアカウントでは、利用者が消える。 すべての操作が一つの agent アカウントにひもづけば、顧客データベースの記録には「agent がこのデータを照会した」としか残らない。どの営業担当者が頼んだのか。その人はもともとこの顧客を見る権限があったのか。記録には何もない。agent のアカウントはたいていどの利用者より広い権限を持つので、誰もが agent を通じて、本来見られないものを見られることになる。

同じ token を渡していくと、受取人を間違える。 どの token にも、発行時にどのシステム向けのものかが書かれている。この項目を audience（受け取り先の指定）という。利用者がログイン時に受け取る token の audience は、最初のシステムだ。agent がそれをチケットシステムにそのまま渡せば、他人の名前が書かれた通行証で入館するのと同じになる。AWS は 2026 年 7 月の技術記事で、こうすると下流のどのツールも悪用されうる代理人になりかねないと指摘している。受け取る token が、もともと自分あてに発行されたものではないからだ。Microsoft もこの種の流れを説明する文書の警告欄で、中間のサービスに発行された token を、指定された受け取り先以外に送ってはならないと明記している。

立ち寄る先ごとに鍵を替える：利用者に代わって交換する

この「利用者に代わって次のシステムで用事を済ませる」流れは、一般に on-behalf-of、略して OBO と呼ばれる。中心となる動きは交換だ。agent は利用者の token を持って認可サーバー（token を発行するシステム）に行き、新しい token を申請する。新しい token は指定された次のシステム専用で、権限も利用者がもともと許されていた範囲を超えられない。

新しい token は二つの役割を覚えておく必要がある。この交換を定めたインターネット標準 RFC 8693 は、両者を分けている。subject は代理される人で、この例では営業担当者だ。actor は実際に作業する側、つまり agent である。AWS の記事の実装では、下流のツールを呼び出す前に毎回 token を交換し、新しい token に利用者の身元を残し、実行した agent を記録し、受け取り先を一つに限定し、権限も下流に必要な分だけにしている。

こうすると、顧客データベースの記録は「agent が特定の営業担当者に代わり、読み取り専用の権限でこのデータを照会した」になる。下流のシステムが一つ増えるたびに、もう一度交換する。顧客データベース用の token を、続けてチケットの起票に使うことはできない。

広告

まず作業の性質を見分ける

agent の作業がすべて OBO を使うべきだとは限らない。受け渡しの経路を描く前に、その作業がどの種類かを判断する。

  • 特定の利用者を本当に代理していて、認可の仕組みと下流の両方が交換に対応している： OBO を使い、段階ごとに新しい token に替え、subject と actor を残す。
  • どの利用者も代理していない。たとえば毎日決まった時刻に公開データを整理するジョブ： agent 自身の身元を使い、権限はその裏方の作業だけに絞る。OBO に当てはめるために利用者を作り上げてはいけない。
  • 利用者を代理しているが、下流が交換に対応していない： 元の token を渡してはいけない。中間の層で止め、権限をより絞ったバックエンドの機能に代行させるか、人に下流のシステムで確認してもらう。
  • 新しい token がどのシステム向けか言えない、または今回の操作に必要以上の権限を求めている： そのまま拒否する。これらの項目を agent に推測させてはいけない。

交換が通っても、その操作が正しいとは限らない

token の交換に成功したということは、「この agent はこの利用者を代理してこのシステムに行ってよい」というだけで、今回の操作が正しいことまでは意味しない。注文の照会なら事前に承認したルールで自動的に通してよいが、データの削除、返金、権限の変更のような影響の大きい書き込みは、交換に成功しても、実行前に責任者が、誰が認可したのか、何をするのか、影響はどれほどか、どう元に戻すのかを確認する必要がある。認可の確認を agent のプロンプトに書くだけでもいけない。バックエンドのシステムが強制する必要がある。AI サポートにアカウントを変更させる前に、本人確認は会話ではなくシステムで行うも参考にしてほしい。

交換の仕組みそのものにも守るべきものがある。AWS の記事は、交換に使う agent の資格情報が鎖全体で最も機密性の高い鍵だと注意している。漏れれば、どの利用者の token でも申請できてしまう。ログにも token をまるごと残さず、subject、audience、actor といった項目だけを記録するべきだ。

実際に動いている経路を一本描く

すでにシステムをまたいで操作している agent を一つ選び、いちばんよく通る経路だけを描く。各段階を同じ一行の形式で書く。

代理される利用者 → 実行する agent → token の発行元 → 受け取るシステム → 許される操作 → 拒否される条件

描き終えたら二つ問う。共有アカウントしか見えない段階はないか。同じ token を二つの異なるシステムが受け取っていないか。どちらかの答えが「ある」なら、agent にさらに仕事を任せる前に、まずその段階を絞る。agent がまだ自分の身元を持っていないなら、ERP の AI agent には自分の ID が要る。そうすればログで人がやったか AI がやったかを見分けられるから始めてほしい。

AI 整理カード

AI agent がシステムをまたいで作業するとき、どの段階でも身元の受け渡しがはっきりしているか確かめたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/ai-agent-on-behalf-of-token-handoff-map/
記事の見方はこうだ。agent が利用者に代わって複数のシステムを呼び出すとき、共有アカウントは使わず、同じ token を次々に渡すこともしない。段階ごとにその先専用で、今回の作業に足りる権限だけの新しい token に替え、「誰を代理しているか」と「誰が実行しているか」を残す。

まず私に 3 つ質問してほしい：
1. この agent がいちばんよく通る経路は、どのシステムをどの順に通り、それぞれで何をするか；
2. 各段階で agent はどの身元で呼び出しているか。利用者の token か、交換した新しい token か、共有サービスアカウントか；
3. この経路に、書き込み、削除、支払い、権限変更をする操作はあるか。

私の回答をもとに、次を出力してほしい：
- 段階ごとに一行：代理される利用者／実行する agent／受け取るシステム／許される操作／拒否条件。確認できない項目は「要確認」とする；
- 共有アカウントを使っている段階、または同じ token を異なるシステムが受け取っている段階；
- 各段階の状態：確認済み／要確認／遮断すべき；
- 交換に成功しても、人の確認を経てから実行すべき影響の大きい操作。
システムの設定を推測しないこと。情報が足りなければ、まず私に質問してほしい。
広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料