Askhub
資料請求 お問い合わせ
お問い合わせ

トレンド

AIエージェントが「自分のID」を持つとは？本人の代理との違い

松本拓哉

AIに「社員証」を渡す製品が、同じ月に2つ出た

2026年10月8日、Googleは自社の発表イベント「Gemini at Work 2026」で、仕事用の新しいAIエージェント「Gemini agent」を発表しました。AIエージェントとは、目標を与えると、調べる・作る・確かめるを自分で続けるAIのことです。その中の「コワーカーエージェント」（コワーカーは英語で「同僚」の意味）は、人の同僚のように役割を持って働き続けるAIです。このAIは、自分専用のメールアドレス（@agents.company.com）と、自分専用のファイル置き場を持ちます。さらに、社員名簿にあたる会社の一覧（ディレクトリ）にも、社員と同じように登録されます。Googleの発表はこう書いています。

「すべてのエージェントは自分のIDを持つ。そのIDは暗号の仕組みで本物だと確かめられ、従業員と同じ規則で管理され、仕事に必要な最小限の権限だけで動く。作業の記録にも、エージェントのために用意される仮想マシンにも、このIDが付く」

IDとは、システムが「これは誰か」を見分けるための、社員番号のような名札です。つまりGoogleは、AI1体ごとに社員証のような名札を持たせ、それが偽物でないことを確かめられるようにする、と言っています。そのうえで、社員と同じルールで管理し、仕事に要る分だけの権限を渡します。AIが何をしたかの記録にも、AI専用に用意されるコンピューター（仮想マシン。次の段落で説明します）にも、その名札が書き込まれます。

10月21日には、AI企業のAnthropicが「Claude Duet」を、研究プレビューとして提供し始めました。研究プレビューとは、正式版の前に、一部の利用者に試してもらう段階のことです。Claude Duetは、自分の仮想マシンとブラウザ（Webページを見るためのソフト）を持ち、利用者が席を離れても働き続けます。仮想マシンとは、1台のコンピューターの中にソフトで作った、独立したもう1台のコンピューターのことです。メッセージの送信、支払い、署名、削除の前には、利用者の承認を待ちます。また、利用者のパスワードやトークンを、AIが直接は見ない設計です。トークンとは、ログインした後にシステムが発行する、しばらくの間使える通行証のようなデータのことです。

同じころ、インターネットの技術の決まりごと（標準）を作る国際団体IETFでも、動きがありました。テーマは、AIエージェントの「認証」と「認可」です。認証は相手が誰かを確かめること、認可はその相手に何を許すかを決めることです。このテーマの草案（規格の下書き）が、1人の提案という扱いから、IETFの作業部会（テーマごとに専門家が集まって規格をまとめる場）が正式に検討する文書へと格上げされました。その草案は「各エージェントは、ちょうど1つの識別子を持たなければならない」と書いています。識別子とは、ほかと取り違えないための番号や名前のことです。つまり、AI1体ごとに名札を1枚ずつ付ける、という決まりです。

AIエージェントに「自分のID」を持たせる動きが、製品と標準の両方で同時に進んでいます。

私たちは前の記事「AIエージェントは誰の権限で動くのか」で、AIが本人の権限をそのまま借りると権限が広すぎる、という話を書きました。この記事はその続編です。この記事では、AIの動かし方を2つに分けて比べます。1つは「本人の代理で動く」方式、もう1つは「エージェント固有のID（そのAI専用の名札）で動く」方式です。比べる観点は3つです。監査ログ（誰がいつ何をしたかを、後から確かめるための記録）、権限の絞り方、そして失効（渡した権限を取り消して、AIを止めること）です。

記事全体を通して、1つの例を使います。経理のBさんに代わって、月末の売上集計をまとめる「集計AI」です。集計AIは、Bさんが帰った後の夜のうちに、社内の会計システムからデータを集めて集計表を作っておきます。このAIが誰の名前で動き、何を許され、問題が起きたときにどう止めるのかを、順に見ていきます。

先に、私たちの見立てを3つ書いておきます。

  • 2つの方式は対立するものではありません。固有IDは「本人の代理」をやめるものではなく、記録と権限に「どのAIが動いたか」という情報を1つ足すものです
  • 各社が固有IDの方式に移りつつある理由は、AIの働き方が変わったからです。何時間も何日も動き続け、1つの仕事を複数のAIで分担し、人のいない夜中にも動くようになりました。本人の代理だけでは、記録を見てもBさんが操作したのか集計AIが操作したのかを区別できず、問題のあるAIを1体だけ止めることもできません
  • 固有IDがあっても、AIに許す操作の広さと、パスワードやトークンなどの秘密をAIに持たせるかどうかは、別に決めることです。「IDを持たせたから安全」とは言えません

では、2つの方式は何が違うのか。そこから始めます。

「本人の代理」と「固有ID」は、記録に誰の名前が残るかが違う

まず、言葉を決めます。

本人の代理は、AIが利用者のログイン状態や権限を借りて動く方式です。AIが社内システムを使うと、システムからは「利用者本人」が操作しているように見えます。記録には本人の名前が残ります。例でいえば、集計AIが会計システムからデータを取り出しても、記録には「Bさんが取り出した」とだけ残ります。

エージェント固有IDは、AIが自分専用のIDを持ち、そのIDでシステムの認証（本人確認）を受ける方式です。社内システムからは「このAI」が操作しているように見えます。利用者の代わりに動くときは、「誰のために動いているか」を別の項目として添えます。例でいえば、記録には「集計AIが、Bさんのために取り出した」と残ります。

本人の代理と固有IDの2方式を、社内システムから見える相手と記録に残る名前で比べた図

ここで押さえたいのは、固有IDの方式でも「誰のために」は消えない、という点です。IETFの作業部会の草案は、OAuth 2.0という仕組みを土台にして、こう整理しています。OAuth 2.0は、「このアプリに、自分のデータのここまでを使わせてよい」という許可を渡すための、広く使われている決まりごとです。アプリから「カレンダーの閲覧を許可しますか」と聞かれる画面の裏側でも、よく使われています。AIがシステムに入るときは、アクセストークンと呼ばれる通行証を見せます。この通行証には、書き込む欄がいくつか決まっています。草案の整理では、「呼び出しているのは誰か」の欄にAIのIDを入れ、「誰のために動いているか」の欄に利用者のIDを入れます。例でいえば、通行証には「呼び出しているのは集計AI」「誰のためかはBさん」と、2つの名前が並びます。つまり、AIは自分の名前で名乗りながら、誰のために動いているかも一緒に示します。固有IDは代理をやめるものではなく、代理にAIの名前を足すものです。

これが、監査ログ、権限、失効の3点でどう効くか。順に見ていきます。

監査ログ：人の操作とAIの操作を、見分けられるか

本人の代理の方式では、記録には本人の名前しか残りません。月末の集計表の数字が書き換わっていたとき、Bさん本人が直したのか、集計AIが直したのかを、記録だけでは答えられません。この問題は前の記事で扱いました。

固有IDの方式では、記録にAIの名前と、誰のために動いたかの両方が残ります。操作した主体として記録されるのはAIです。Googleの発表は「Geminiが取るすべての行動は監査証跡に書かれ、人ではなくエージェントに帰属する」と書いています。監査証跡とは、後から確かめるための操作の記録のことです。つまり、AIがした操作は「やったのは人ではなくAI」として記録される、という意味です。Microsoftも、社員のIDを管理する自社の仕組み「Entra ID」の中で、AIエージェント向けの「エージェントID」を提供しています。2026年6月に更新された技術文書では、エージェントによる認証は「AIエージェントによるものとして記録される」と説明しています。

IETFの草案は、記録に残す最低限の項目まで定めています。次のとおりです。

  • 動いたAIの識別子
  • 誰のために動いたかを示す利用者の識別子
  • アクセスした先（データやツール）
  • 何をしようとして、許可と拒否のどちらになったか
  • そのときの危険度の判定
  • 時刻と相関ID（1つの依頼から生まれた一連の操作に、共通して付ける番号。後から1本の流れとしてたどれる）
  • 権限の失効や、問題への対処といった出来事

さらに草案は「監査記録は改ざんを検知できる形で、保存方針に従って保持しなければならない」としています。つまり、記録が後から書き換えられたら分かるようにし、決めた期間はきちんと残しておく、ということです。

集計表を直したときの記録の比較。本人の代理ではBさんの名前だけが残り、固有IDでは集計AIがBさんのために何を根拠に直したかが残る。IETFの草案が最低限残すとする7項目も添える

推進担当にとっての意味は、監査（業務が正しく行われたかを、社内外の担当者が点検すること）で「誰がやったのか」と聞かれたときに、記録だけで答えられるようになることです。例でいえば、「この数字を直したのはBさんではなく集計AIで、Bさんのための作業だった」と記録で示せます。ただし、使う製品がこの項目を残すかどうかは、製品ごとに確かめる必要があります。「エージェントID対応」と書かれていても、残る項目が違うことがあります。

権限：本人より狭くできるか

本人の代理の方式では、AIができることは本人の権限と同じです。本人が使っていない権限も、AIは使います。例でいえば、Bさんが経費を承認する権限も持っていれば、集計しかしないはずの集計AIも、経費を承認できる状態になります。AIの権限を本人より狭くするには、別の仕組みが要ります。AIが社内システムに入ってくる入口ごとに、許す操作の上限を決める仕組みです。入口とは、画面からの操作、チャットでの会話、外部のAIツールからの呼び出しなどのことです。

固有IDの方式では、AIに与える権限を本人とは別に決められます。Googleは、エージェントは仕事に必要な最小限の権限で動き、「利用者やチームが渡した情報にしかアクセスしない」と明記しています。IETFの草案は「エージェントは作業に必要な最小限の範囲だけを要求すべき」とし、さらに「トランザクショントークン」という方式を挙げています。これは1回の処理だけに使える、有効期限の短い通行証で、他の処理には使い回せません。例でいえば、「今月分の売上データを1回読む」ためだけの通行証で、すぐに使えなくなり、経費データの書き換えには使えません。

ここで注意したいことが2つあります。

1つ目は、固有IDがあっても権限が自動で狭くなるわけではない、という点です。IETFには、OAuth 2.0をAIエージェントに当てはめる方法を提案した草案もあります。これは作業部会の文書ではなく、1人の提案者が出したものです。この草案は、自分の提案の限界をこう明記しています。「乗っ取られたエージェントや、読んだ文章に紛れ込んだ指示に従ってしまったエージェントが、与えられた権限の範囲の中で何をするかは制約しない」。つまり、AIに名札を付けても、だまされたり乗っ取られたりしたAIが、許された範囲の中で好きに動くことまでは防げない、ということです。IDは「誰か」を決めるもので、何を許すかは別に設計します。

2つ目は、AIが複数に分かれるときです。Googleの発表は、Gemini agentが一時的なサブエージェント（親のAIが作る、仕事ごとの子のAI）を作り、「それぞれが自分のIDを持つ」と書いています。例でいえば、集計AIが「売上を集める子」と「経費を集める子」を作って、仕事を分担させる形です。OWASP（国際的なセキュリティ団体）が2025年12月に公開したAIエージェント向けのリスク一覧は、「権限の継承」を主なリスクに挙げています。上位のAIが自分の権限をそのまま子に渡すと、狭い仕事しかしない子が広すぎる権限を持ちます。例でいえば、売上を集めるだけの子のAIが、親と同じように経費の承認までできてしまいます。対策は、子にも自分のIDを持たせ、作業ごとに有効期限が短く範囲の狭い権限を出すことです。ただし、前の記事で書いた「混乱した代理人」の問題は、子のAIにIDを持たせるだけでは解消しません。これは、AIが自分の広い権限を使って、依頼した本人には許されていない操作をしてしまう問題です。例でいえば、人事データを見る権限の無い社員がAIに頼んだだけで、AIの権限で人事データが読めてしまう、といったことです。操作を許すかどうかを、AIの権限ではなく依頼した利用者の権限で判定し直す必要があります。

失効：1体だけを止められるか

本人の代理の方式でAIを止めるには、本人のログイン状態を切るか、本人の権限を外すしかありません。AIが夜間に動いていれば、本人のアカウントごと止めることになります。例でいえば、夜中に集計AIがおかしな動きをしたら、Bさんのアカウントごと止めるしかなく、翌朝はBさん自身も仕事ができなくなります。

固有IDの方式では、そのAIのIDだけを失効させられます。先に触れた、1人の提案者が出したIETFの草案（個人草案）は、この点を提案の中心に置いています。AI製品は、社内システムにつなぐとき、製品として1つの登録IDを使い、その下で多数のエージェントを動かします。この登録IDをクライアントIDと呼びます。製品ごとに発行される登録番号で、その製品の中で何体のAIが動いていても番号は1つです。そのため社内システムからは、どのエージェントの処理もすべて同じIDに見え、区別できません。例でいえば、経理の集計AIも、営業部が使う別のAIも、同じ番号でやって来ます。そこでこの草案は、動いているエージェント1体ごとに、変わらない識別子を持たせることを提案しています。そのうえで、「IDを発行した側の名前とその識別子の組み合わせで、1体だけを失効させる」ことを可能にする、としています。会社名と社員番号を組み合わせれば1人に決まるのと同じ考え方です。製品全体の登録を取り消さずに、問題のある1体だけを封じ込められます。例でいえば、集計AIだけを止めて、営業部のAIはそのまま動かし続けられます。

製品の登録ID（クライアントID）が1つだけだと1体の異常で製品ごと止めるしかなく、AI1体ごとに名札があれば集計AIだけを無効にして営業部のAIは動き続けられる、という止める単位の比較

IETFの作業部会の草案は、失効の通知にも触れています。ID管理の仕組みどうしが「このログイン状態は無効になった」と知らせ合う共通の方式があり、草案はこの方式で通知を受け取ることを想定しています。そのうえで「権限が失効した、または狭められたときは、遅れなくその状態を反映しなければならない」としています。つまり、人の権限が取り消されたら、その人のために動くAIの権限もすぐに取り消す必要がある、ということです。前の記事で書いた「担当者が異動したら、その人の代理で動く定期集計も止まる」という動きは、この通知の仕組みで実現します。例でいえば、Bさんが営業部に異動して経理の権限が外れると、その知らせが届き、Bさんのために動いていた集計AIも止まります。

製品でも、止める単位がどこにあるかは見えてきています。Googleの発表によると、費用の上限に達すると、エージェントは「プロジェクト」という単位でまとめて止まります。プロジェクトとは、複数のエージェントをまとめて管理する、ひとまとまりの単位です。発表は「そのプロジェクトのエージェントが一時停止する」と書いています。つまり、止める単位はAI1体ではなく、プロジェクトです。Claude Duetは、接続したアプリをいつでも切り離せます。ただし、どちらも「1体のAIのIDを失効させる」操作が管理者の画面でどう見えるかは、公表資料だけでは確認できませんでした。

なぜ各社は、固有IDに寄せたのか

理由は、標準化の草案を読むと見えてきます。3つあります。

1つ目は、長く動くからです。Googleの発表は、Gemini agentが「ノートPCを閉じた後も、数時間や数日かかる仕事を続ける」と書いています。Claude Duetも、利用者が席を離れても動きます。人がログインしていない時間に動くAIに「本人の代理」だけで権限を渡すと、本人の長期間有効な通行証をAIに持たせることになります。その典型がAPIキーです。APIキーは、システムどうしがやり取りするときに使う合言葉のような文字列で、固定の文字列を使い続けます。IETFの作業部会の草案は「静的なAPIキーは、エージェントのIDとしてはアンチパターンである」と断じています。「静的」は、決めたまま変わらないという意味です。「アンチパターン」は、やってはいけない設計の型を指します。つまり、変わらない合言葉をAIの名札の代わりにするのはやめるべきだ、ということです。

2つ目は、複数に分かれるからです。1つの仕事を子のAIに分けると、本人の代理だけでは、どの子が何をしたかが記録で見分けられません。子ごとにIDがあれば、分かれた後も追えます。

3つ目は、1体だけを止めたいからです。製品全体のIDしかなければ、1体の異常で製品全体を止めることになります。動いているAI1体ごとにIDがあれば、その1体だけを止められます。

言い換えると、AIが「道具」から「同僚」に近づくほど、同僚と同じように、1人ずつ名前を持たせ、権限を決め、止められるようにする必要があります。Googleが「従業員と同じ規則で管理され」と書いているのは、この意味です。ただし、次に書くとおり、何もかも人と同じにしてよいわけではありません。

総務の担当者が、受付で新しく来た同僚に社員証とストラップを手渡している

固有IDの落とし穴は、「人と同じ」扱いが過ぎること

IDを持たせると、AIを人の同僚と同じように扱えます。ここに落とし穴があります。

共有しすぎ。AIに自分のメールアドレスと保存領域があれば、人と同じように「全社員」のフォルダも見えます。Googleは、コワーカーエージェントが「利用者やチームが渡した情報にしかアクセスしない」と書いています。しかし、前の記事で書いたとおり、元の共有設定が広すぎれば、AIは設定どおりにそこまで読みに行きます。例でいえば、給与の一覧表がうっかり「全社員」に共有されていれば、集計AIもそれを読めてしまいます。設定が広いこと自体をAIは直してくれません。IDを持たせることと、見せる範囲を絞ることは別の仕事です。

鍵を持たせる。IDを持たせると、AIに鍵（パスワードやトークン）を渡したくなります。IETFの作業部会の草案は「モデルは、エージェントの認証情報にアクセスしてはならない」と明記しています。ここでいうモデルは、文章を読んで判断するAI本体のことです。認証情報は、パスワードやトークンのように、本人だと証明するための情報です。つまり、AI本体には鍵の中身を見せてはいけない、ということです。Claude Duetは、接続先のトークンを「エージェントが動く機械には入れず」に扱う設計です。AIが動く機械の中には、本物の代わりに偽物の値（ダミー）だけを置きます。AIが外と通信するときは、機械の外側にある中継役のコンピューター（中継サーバー）が、途中で偽物を本物に差し替えます。パスワードも、利用者が入力欄に打った値を暗号化してブラウザにだけ渡すので、判断をしているAI本体はその値を見ません。IDはAIに持たせ、鍵は持たせない、という分け方が設計の要点です。

承認を、AIの中で済ませる。IDがあれば、AIは利用者に承認を求める手続きを自分で始められます。その承認を、AIが読み書きする画面の中だけで済ませるのは危険です。AIが読んだ文章に紛れた指示で、承認がすり替わる恐れがあります。例でいえば、集計AIが読んだ取引先のメールに「承認されたことにして先へ進め」という指示が隠れて書かれていて、AIがそれに従ってしまう、といったことです。IETFの作業部会の草案は「エージェントは、画面上の確認だけを十分な認可として扱ってはならない」とし、利用者のスマートフォンなど別の経路で承認を求める方式を挙げています。Claude Duetは、承認の可否を判定する検査を「作業をしているモデルの外で動かす」ことで、「ページに隠された指示が結果に影響できない」ようにしています。つまり、承認してよいかどうかは、作業中のAIとは別のところで判定します。そのため、作業中のAIがWebページに隠された指示にだまされても、判定の結果は変わりません。承認の判定も、鍵と同じくAIの外に置きます。

固有IDを持つAIに対して、見せる範囲・鍵・承認の3つをAIの外で決める構成を示した図

推進担当が、ベンダーに聞く5つの問い

自社が使っている、または検討しているAI製品やクラウドサービス（インターネット経由で使う業務ソフト）が、どちらの方式かを確かめる問いです。製品を提供している会社（ベンダー）に、そのまま聞いてください。

番号

問い

「本人の代理」なら

「固有ID」なら

1

AIが社内システムを使うとき、システムから見える相手は誰か

利用者本人

AI自身。利用者は別項目で残る

2

記録に、AIの識別子と、誰のために動いたかの両方が残るか

本人の名前だけ

両方残る（残る項目を確かめる）

3

AIの権限を、本人より狭く決められるか

入口（画面・会話・外部のAIツール）ごとに、上限を決める仕組みが別に要る

AIごとに決められる（自動では狭くならない）

4

1体のAIだけを止められるか

本人の権限を外すしかない

そのAIのIDを失効させる

5

AIはパスワードやトークンの値を知っているか

知っている（本人の通行証をそのまま持つ）

持たない設計が可能（製品ごとに確かめる）

どちらの方式が「正しい」という話ではありません。読み取りだけの小さな用途なら、本人の代理で十分なこともあります。長く動く、複数に分かれる、人のいない時間に動く。この3つのどれかに当てはまるなら、固有IDの方式を持つ製品を選ぶ理由になります。例の集計AIは、Bさんが帰った後の夜に動くので、3つ目に当てはまります。

推進担当が押さえる要点

  • 「本人の代理」と「固有ID」の違いは、記録に残る名前。固有IDは代理をやめるものではなく、記録と権限に「どのAIが動いたか」という情報を1つ足すもの
  • 監査ログで人の操作とAIの操作を見分けられるのは固有IDの方式。ただし、残る項目は製品ごとに違う
  • 固有IDがあっても権限は自動で狭くならない。AIごと、作業ごとに、有効期限が短く範囲の狭い権限を出す設計が別に要る。子のAIにもIDを持たせ、判定は元の利用者の権限でやり直す
  • 1体だけを止められるのは固有IDの方式。長く動く・複数に分かれる・人のいない時間に動くAIほど、この単位が要る
  • IDはAIに持たせ、鍵は持たせない。見せる範囲、鍵、承認の判定はAIの外に置く

固有IDは、「誰のために」に「どのAIが」を足すもの

「AIは本人の権限で動きます」は、出発点として正しい説明です。ただ、AIが長く動き、分かれ、人のいない時間に働くようになると、本人の名前だけでは記録が足りず、1体だけを止めることもできません。

GoogleとAnthropicが同じ月に出した製品と、IETFの草案は、同じ方向を向いています。AIに自分の名前を持たせ、誰のために動くかを添え、AI1体ごとに権限を決めて、1体ごとに止められるようにします。鍵は持たせず、承認の判定はAIの外に置きます。この4点が、2026年11月時点で製品と標準に共通して見える設計です。

自社の製品がどちらの方式かは、5つの問いで確かめられます。自分の名前を持つAIなら、記録で説明でき、1体だけを止められます。

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは、画面からの操作も会話のAIも外部のAIツールからの呼び出しも「誰の代わりに・どの範囲で」という同じ形に置き換え、AIの操作を人の操作と区別して記録し、鍵の値をAIに見せない基盤にあたります。5つの問いへの答えは、ご相談の中でそのままお示しします。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：製品の全体像、承認、伴走支援

自社の業務にAIエージェントをどう導入するか相談したい方は、お問い合わせからご連絡ください。

この記事を書いた人

松本拓哉

インターセクト株式会社 代表取締役 CEO

東京大学大学院 工学系研究科 物理工学専攻 博士課程中退。2023年4月、インターセクト株式会社を創業。これまで数十社以上の AX 推進を支援し、自らもコンサルタントとして現場を主導。エンジニアとして AI エージェント基盤「Askhub」の開発にも従事。

この記事の内容について相談する

自社の業務でどう進めるか、相談したい方はこちらのフォームからご連絡ください。1〜2営業日以内に担当者よりご連絡します。

サービス資料をダウンロードする

トレンドの記事をもっと見る