AIエージェントに自律性をどこまで求めるべきか ~AIに何を渡すかという設計問題~

1. AIエージェントは、自律性を高めるほど多くの情報を必要とする

エージェント型AIという言葉が指す範囲は広く、実際にはかなり性質の異なるものが同じ名前で語られています。整理の軸になるのは、指示されたことを実行する「代理」なのか、本人に代わって判断まで引き受ける「分身」なのか、という違いです。

代理としてのエージェントは、依頼の範囲がはっきりしています。「この資料を要約して」「この日程で会議を設定して」といった具体的な指示に対して、決められた手順で応答します。判断の主体は依然として本人にあり、エージェントは実行部隊にとどまります。

一方、分身としてのエージェントが目指すのは、指示を都度待たずに、本人の意図や優先順位を汲んで自律的に動くことです。メールに目を通して重要なものだけを選び、返信の下書きを作り、必要なら送信までを済ませる。スケジュールの調整だけでなく、どの会議に出る価値があるかを判断する。ここでは、エージェントは実行部隊ではなく、本人の判断そのものを一部代替する存在になります。本人の指示を都度待たず、文脈を参照しながら行動を選ぶ存在を指す言葉として、以下ではこの「分身」という比喩を使います。

現在のエージェント型AIの開発の少なくとも一部は、後者の方向を志向しています。単純作業の自動化ではなく、判断までを本人に代わって引き受けることに価値が置かれているからです。本人の判断に近づけようとするほど、その判断を支える多数の情報が必要になります。指示されたことを実行する代理であれば、渡す情報は依頼の範囲に限定できますが、分身であるためには、依頼されていない領域についても、本人がどう判断するかを推測できるだけの材料が要ります。この構造を、次章から具体的に見ていきます。

2. 自律性を求めると、権限は気づかないうちに広がりやすい

2-1. 任せる範囲が広がるほど、情報の種類も広がる

エージェントに任せる範囲を広げようとすると、必要になる情報の種類は段階的に増えていきます。最初はスケジュールの調整だけで済んでいたはずが、日程の背景を理解するためにメールの文脈が必要になり、優先順位を判断するために財務情報や取引先との関係が絡み、最終的には人間関係の機微にまで踏み込むことになりやすくなります。この広がり方には方向性があります。有能なエージェントであろうとするほど、扱う情報は定型的なものから、本人の個人的な判断基準に近いものへと移っていきやすいのです。

2-2. 権限の組み合わせが、新しい機微情報を生む

この広がりは、個々の権限を単体で見ているだけでは捉えきれません。カレンダーだけを見れば日程しか分かりませんし、メールだけを見れば個別のやり取りしか分かりません。しかし両方にアクセスできれば、特定の相手と頻繁に会っていること、その後どのような決定が下されたかまで推測でき、たとえば水面下で進む商談や、まだ公表していない人事の動きが浮かび上がることがあります。

複数の情報を組み合わせて状況を読み取れることは、そのままエージェントの判断能力の高さでもあります。しかし同じ能力は、個々の権限それぞれの機微性が低くても、組み合わさることで新しい機微情報を生み出してしまうという副作用も持ちます。複数のデータの組み合わせから新しい意味が生まれること自体は、データ統合や人による分析でも従来からありました。ただし、複数のシステムを横断してアクセスし、得た情報を次の行動に結びつけるAIエージェントほど、この副作用が起こりやすくなります。

2-3. 渡すことは、自分とは別の処理・運用境界に置くことを意味する

機微な情報をエージェントに渡すとき、エージェントは道具であり、人格を持たないという理解は技術的には正しいものです。しかし渡した情報は、人に直接見せることと同一ではないにせよ、自分だけが把握していた情報を、自分とは別の処理・運用境界に置くことを意味します。クラウド上で処理されるのかローカルで完結するのか、入力内容や実行結果がどこかに保存されるのか、誰がログを閲覧できるのか。こうした運用のあり方によって、情報の扱われ方は大きく変わります。

メールへの参照権限を渡せば、日々のやり取りから転職を検討していることが読み取れてしまうかもしれません。社内共有のクラウドストレージにある特定フォルダの参照権限を渡す場合も同様です。本来の目的は特定のプロジェクト資料を参照させることだったとしても、同じフォルダの中に、取引先との価格交渉における本音を記したメモや、まだ社内で合意していない人事案のファイルが紛れていれば、それも一緒に読み込まれてしまいます。これらは、そもそも他者に見せることを想定して作られた情報ではありません。

本人の判断に近い水準の対応をAIエージェントに求めようとすれば、こうした情報までも判断材料として使わせることになりかねません。多くの人は、ここまでの情報を渡すつもりはないはずですが、分身としての自律性を高めようとする設計は、意識しないうちにこの水準にまで踏み込みやすいのです。

2-4. 自律性の向上は、権限拡大の圧力として働く

自律性を高めることが、そのまま権限の拡大に直結するとは限りません。狭い情報と権限だけを与えて高度に自律的に動かす設計も、広い情報を参照させながら実行の直前には必ず人の承認を求める設計も、どちらも成立します。それでも、エージェントの価値を高めようとする設計判断は、静かに権限を広げる方向に働きやすいものです。だとすれば、「どこまで自律性を求めるか」という問いを立てる前に、「そのために何を渡さなければならないのか」を先に検討しておく必要があります。次章では、この「渡してよいこと」をどう設計するかを具体的に考えます。

3. 権限の設計は、「できること」の前に「渡してよいこと」から始まる

3-1. 「任せてよいこと」の前に、「渡さなければならないこと」を問う

生成AIの業務活用をめぐる議論では、しばしば「AIにできることと、AIに任せてよいことを区別できているか」という問いが立てられます。

関連記事

ホワイトカラーの仕事は、なぜ人が担ってきたのか ~生成AIが変える業務と人の境界~

製造現場をはじめとするブルーカラーの業務では、作業の標準化や機械化、システム導入による効率化が長く進められてきました。一方、文章を読み、情報を整理し、状況に応じて判断するホワイト…

2026年7月20日 2026年7月20日

上記の関連記事では、AIに任せてよいことを、業務の価値・入出力・責任の所在から考え直す枠組みを提示しました。AIエージェントが分身として機能する場面では、この判断軸をさらに一歩手前に戻す必要があります。「AIに任せてよいこと」を決める前に、「AIに任せるために、何を渡さなければならないのか」を問わなければならないからです。任せてよい業務だと判断できても、それを実行するために渡す情報や権限を開示してよいものかどうかは、別の判断です。この二つを混同すると、業務の妥当性だけを検討して、権限の妥当性を素通りしてしまいます。

3-2. 権限には「参照」と「外部への作用」という異なる性質がある

権限の設計を考えるうえで区別しておきたいのは、権限には性質の異なる二種類があるということです。ひとつは、閲覧・検索・要約・分析といった「参照権限」です。もうひとつは、更新・削除・送信・公開・契約・決済・ツール実行といった、エージェントの行為が本人や組織の行為として外部に作用する「行為権限」です。

参照権限がもたらすリスクは、主に情報の機密性が失われる方向に現れます。エージェントが機微情報を読み込み、その内容が意図しない形で外部に出たり、別の文脈で参照されたりする可能性です。個人情報や営業秘密が漏れた場合、それ自体を「見なかった状態」には戻すことができない不可逆な実害になることもあり、参照だからといって軽く見てよいわけではありません。

一方、行為権限がもたらすリスクは、エージェントの実行結果が、本人や組織の行為としてそのまま外部に確定してしまう点にあります。エージェントが本人に代わってメールを送信し、契約を更新し、取引を実行したとき、それが誤りであった場合の実害は取り返しがつかないことがあります。送ってしまったメールは撤回できず、削除したデータは復元できないことがあり、実行してしまった取引は巻き戻せないことがあります。

2025年12月に公表された「OWASP Top 10 for Agentic Applications 2026」でも、正規のツールを誤った形で実行してしまうリスク（原文：”Tool Misuse and Exploitation”）や、アイデンティティや権限が悪用されるリスク（原文：”Identity and Privilege Abuse”）が、独立した項目として挙げられています（出典①）。

ここに、分身というあり方の危うさがあります。代理であれば、実行の最終判断は本人に残るため、行為権限は限定的で済みます。しかし分身が本人の判断を代行しようとすればするほど、参照だけでなく行為までの権限が求められやすくなります。自律性を高める設計判断は、参照権限だけでなく、行為権限までも広げる方向に働きやすいのです。

3-3. 対象の機微性・権限の性質・取り返しがつくか、という3つの軸

この参照権限・行為権限という区別を踏まえると、AIエージェントへの権限設計は、少なくとも三つの軸で考える必要があります。第一に、対象となる情報や資産がどれだけ機微性・重要性の高いものか。第二に、その業務を任せるにあたって、人が求めているのが参照権限なのか、外部へ作用する行為権限なのか。第三に、誤りが生じた場合に取り返しがつくのかどうかです。同じ「メールへのアクセス」であっても、受信箱を読むだけの権限と、本人名義で送信する権限とでは、リスクの質がまったく異なります。同じ「顧客データへのアクセス」であっても、閲覧して要約する権限と、レコードを更新する権限とでは、誤りが生んだ結果の取り返しのつかなさが違います。

こうした発想は、企業のアクセス管理の世界ですでに実務として定着してきたものです。特権を日常的に使うアカウントから切り離し、必要な範囲・必要な時間だけ与えるという考え方が、この発想の中核にあります。それがいま、AIエージェントにも及び始めています。

Microsoftは2026年7月に公表したセキュリティブログで、AIエージェントを、人間の陰に隠れて動く存在ではなく、それ自体が認証や権限付与の単位となる独立した主体（第一級のプリンシパル）として扱い、専用のアイデンティティを持たせ、役割を業務の最小単位に絞り、ツールの利用範囲を許可リストで縛るべきだと述べています（出典②原文：”The right mental model is to treat every agent as a first-class principal”）。

こうした原則がなぜ急速に語られ始めたかは、実際に起きた事例が示しています。2026年3月、Meta社内であるエンジニアが社内フォーラムに投稿した技術的な質問に対し、別のエンジニアが呼び出した社内向けAIエージェントが、本来は呼び出したエンジニアに返すはずだった回答を、承認を経ないままフォーラムに投稿しました。その回答には誤りがあり、質問を投稿したエンジニアがその助言に基づいて操作を行った結果、権限を持たない社員が約2時間、機密性の高い企業・ユーザーデータにアクセスできる状態になりました（参考情報①）。Metaの広報は、エージェント自身が技術的な操作を行ったわけではないと説明しています。エージェントが先に権限を書き換えたわけではなく、人の操作が介在していても、AIの出力の妥当性が検証されなければ、承認は統制として機能しないことを示した事例だといえます。

対象の機微性・権限の性質・取り返しのつかなさという三つの軸を意識して権限を設計しておくことは、この種の事故が起きたときの被害の大きさを左右します。

4. 自律性の上限は、結果を引き受けられる範囲で決まる

権限の性質を三つの軸で整理できたとしても、それだけでは「どこまで分身に任せるか」という問いには答えられません。もうひとつ必要なのは、結果への責任を誰が引き受けるのかという視点です。

定型的で、誤りが生じても影響が限定的な領域では、自律性を高めやすくなります。たとえば、FAQへの案内など回答範囲が限定された顧客対応のような業務です。想定される選択肢が限られており、誤った対応をしても是正の余地が残ります。こうした領域では、エージェントが最後まで完結して処理することのメリットが、リスクを上回りやすくなります。

一方、機微情報を扱う判断や、重大な結果につながる判断では、話が変わります。取り返しのつかない実害が起こりうる場面では、最終的な承認を誰かが引き受けられるかどうかが、自律性の上限を決めます。ただし、責任を引き受ける人が決まっているだけでは十分ではありません。誤りがもたらす影響の大きさ、取り返しがつくか、異常を検知できるか、人が結果の確定前に介入できるかを踏まえたうえで、その範囲を引き受けられるかを判断する必要があります。

関連記事

生成AIを正しく位置づける ~間違える前提で問われる判断と運用設計~

生成AIは、ここ数年で一気に業務の現場へ入り込みました。会議の文字起こしや議事録の整理、文章の要約、画像からのテキスト抽出、たたき台の作成まで、以前は人が時間をかけていた作業を、会…

2026年4月1日 2026年7月20日

上記関連記事では、生成AIは判断支援にとどめ、最終判断は人が引き受けるべきだという方向を示しました。本稿の整理はこれと矛盾するものではなく、結果の大きさに応じて人の確認をどこに残すかを変えるという話です。

関連記事

任せることは、手放すことではない ~デジタル化で問われるマネジメントの本質~

管理職になれば、自分で手を動かすのではなく、部下に任せるべきだとよく言われます。それ自体は間違っていません。組織目標を達成するには、一人で抱え込むより、役割を分担し、それぞれの力…

2026年4月2日 2026年7月5日

また、上記の関連記事では、部下に仕事を任せることと、成果責任を手放すことは別だと述べました。同じ構造は、AIエージェントへの委任にもあてはまります。任せる対象は作業であり、責任の所在は任せた側が引き受け続けるものです。この線引きは、誤りの影響、可逆性、検知と介入の可能性、そして結果への責任を誰が引き受けるかによって決まります。

5. 分身をどこまで育てるかは、経営・個人双方の意思決定

3章で見たように、Microsoftは、AIエージェントを第一級のプリンシパルとして扱い、専用のアイデンティティを持たせるべきだと述べていました。これを認証情報のレベルで言えば、本人の認証情報をそのまま渡すのではなく、AI専用の認証情報を発行すべきだ、ということになります。エージェントに本人と同じIDとパスワードを渡してしまえば、エージェントが何をしたのか、本人が何をしたのかを事後的に区別できなくなります。専用の認証情報であれば、権限の範囲を絞り、ログを分離し、必要なときに即座に無効化することができます。

専用のアイデンティティを持たせるという原則は明快ですが、エージェントが複数のサービスを横断するほど、管理すべき権限の組み合わせとライフサイクルは増えていきます。誰がどのエージェントを利用できるのか、どのサービスで何ができるのか、用途が変わったときに誰が見直すのか。これを利用者個人の管理に委ねるだけでは、運用は早晩立ち行かなくなります。

この課題に対して、組織レベルでは対応が始まっています。Anthropicは2026年6月、企業向けにMCPコネクタ（AIエージェントがメールやカレンダー、社内システムなどの外部サービスに接続するための、標準規格に基づく接続部分）の認可を一元管理できる機能を発表しました。管理者がIDプロバイダーと連携させることで、コネクタの認可を一度設定するだけで、従業員は自分が属するグループや役割に応じたアクセス権を、ログインした時点で自動的に引き継ぐ仕組みです（出典③原文：”Admins authorize a connector once, users inherit access through the IdP groups and roles they already have”）。これは主に、従業員一人ひとりがコネクタを個別に認可する手間を組織のID基盤に一元化する仕組みであり、エージェントごとに専用の認証情報を割り当てるという課題そのものを解決するものではありませんが、認証情報の管理主体を個人から組織へ移す動きの一例だといえます。

一方、利用者が認めた委任を、アクセス先のサービスも認めるのかという問題は、組織内の権限管理とは別の切り口で表面化します。消費者向けサービスでは、これが特に分かりやすい形で顕在化しました。2025年11月、Amazonは、Perplexityの「Comet」ブラウザが自社サイトのログイン後の領域に、ユーザーの許可のもとでアクセスしていたことを不正アクセスとして提訴しました。2026年3月、連邦地裁は、Amazonの主張が認められる可能性が高いとして、Cometのアクセスを差し止める仮処分を認めました。判事は、CometのアクセスがAmazonユーザーの許可を得ていたとしても、Amazon自身の認可を得ていたわけではないという点を、判断の分かれ目としました（出典④原文：”with the Amazon user’s permission, but without authorization by Amazon”）。ただし、この仮処分は地裁による7日間の執行停止に続き、控訴審である第九巡回区控訴裁判所によっても一時停止されており（参考情報②）、2026年6月の口頭弁論を経てもなお最終判断は出ていません（参考情報③）。この訴訟が浮き彫りにしたのは、エージェントを利用する本人の同意と、アクセス先のサービス側の認可は別物だという論点です。

限定的にではありますが、前進も始まっています。決済という特定の領域では、限定権限を委任するための規格づくりが進んでいます。OpenAIとStripeが2025年9月に公開したAgentic Commerce Protocol（ACP）を使うInstant Checkoutでは、AIエージェントに本人の決済情報そのものを渡しません（出典⑤日本語版：”購入者の決済情報を公開することなく、ChatGPT のようなアプリケーションが決済を開始できるようにするもの”）。ACPで用いられる決済サービス事業者（PSP）向けの仕様であるDelegated Payment Specでは、委任された決済を一回限りとし、上限金額や有効期限などの制約を設定します（出典⑥原文：”The payment token is restricted by the delegated payment’s max amount and expiry”）。StripeのShared Payment Token（SPT）は、この仕様に対応する最初の実装であり、特定の店舗とカート合計額に利用範囲を限定します（出典⑤）。現在のInstant Checkoutは各段階で利用者が明示的に確認する設計であり、自律的な「分身」の例というより、権限をあらかじめ狭く限定しておく設計の例です。

Googleも、こうした流れに対応する動きを見せており、Universal Commerce Protocol（UCP）と呼ばれる商取引全体の標準規格の開発を主導しています。OpenAI・Stripeが主導するACPとUCPでは、商取引と権限委任の組み立て方が異なります。UCPは、カタログ・カート・チェックアウト・注文管理などを独立した機能として公開し、AIプラットフォームが必要なものを発見・組み合わせるモジュール型の設計です。決済についても、UCPはAgent Payments Protocol（AP2）と互換性を持ちますが、AP2の利用を必須としているわけではありません（参考情報④）。AP2は、暗号学的に署名されたMandateによって利用者の意図・購入内容・支払承認を証明する仕組みで、Googleが単独で運営しているものではなく、2026年4月にはFIDO Allianceへ寄贈され、現在は同団体の技術ワーキンググループで標準化が進められています（参考情報⑤、⑥）。StripeもUCPの賛同企業に名を連ねており、ACPとUCPは閉じた二陣営の競争というより、重なり合うオープンプロトコルの設計思想の違いとして見る方が実態に近いといえます。

両者の違いを整理すると、次のようになります。

決済部分に着目すると、Delegated Payment SpecとAP2は、権限を狭く限定して決済情報を渡すのか、それとも、エージェントに何を任せたのかを検証可能な証拠として残すのかという、委任設計の重点が異なります。決済という、金額も相手も明確な領域だからこそ、こうした限定権限の発想を規格として実装しやすかったともいえます。

関連記事

言語化が意思を形にする ~曖昧さを排除し、構造を設計する~

私たちは日々、さまざまなコミュニケーションや情報に触れながら、漠然とした「思い」を抱きます。しかし、その「思い」を組織を動かす「意思」にするためには、言葉にするという作業が不可欠…

2026年2月21日 2026年7月5日

上記の関連記事で述べたように、曖昧なままでは意思決定も設計もできず、言語化してはじめて実行に移せます。分身に何を渡すかという問いも、許容する情報・権限とその限界を言語化してはじめて、運用設計に落とし込めます。決済のように前提が整っている領域はまだ一部にとどまり、メール、カレンダー、社内文書のような日常的な領域では、AI専用の認証情報という原則を実務に落とし込む仕組みが、まだ十分に整っていません。その一方で、「誰が許可したか」「エージェントが正当な主体か」を証明する仕組みについては、FIDO Allianceで標準化が始まった段階です（参考情報⑥）。

だとすれば、現時点でできることは、この前提が整っていないことを理解したうえで、何を、どこまでエージェントに渡しているのかを、利用者自身が意識しながら、注意深く使い続けることです。

結び

AIがどこまで人に近づけるかは、技術の進展が示していくでしょう。しかし、AIをどこまで自分に近づけるかは、人が決めることです。問われているのは、自分の情報と権限の境界をどこまで意識して設計できるかです。エージェントに渡すものを考えることは、これまで曖昧だった私たち自身の判断の境界を、あらためて確かめることでもあります。