Personal Agent Protocolとは？Meta・Sierraが進めるAI代理操作の標準構想とMCP・A2Aの違い

当サイトではアフィリエイト広告を利用しています。

AIエージェントに「注文した商品の配送状況を調べて」「ホテルの予約を変更して」と頼む場面が出てきました。利用者の代わりにAIが企業のサービスへアクセスするとき、企業は誰の代理なのか、どの操作まで許可されているのかを判断する必要があります。

2026年10月6日、SierraとMetaは、個人のAIエージェントが企業サービスとやり取りするための公開標準「Personal Agent Protocol」の共同開発を発表しました。

この構想では、エージェントが企業のサービスを見つけ、ゲストとして問い合わせを始め、必要になったら本人の許可を得てアカウント情報を読み取ったり変更したりします。企業側はWebサイト、API、企業自身のAIエージェントの中から対応方法を選べます。

ただし、2026年10月8日時点では構想の発表段階です。初版のv0.1仕様は10月後半の公開予定で、共通仕様や参照実装が既に完成したわけではありません。

この記事では、発表済みの仕組み、OAuthを使う理由、MCP・A2Aとの違い、利用者と企業それぞれの権限、今後の実装に向けた確認点を説明します。

Personal Agent Protocolの現在地
なぜ個人AIと企業の間に新しい標準が必要なのか
ゲストからサインインへ進む流れ
「本人の許可」と「企業の許可」は別々
OAuthで何が変わるのか
Web・API・企業エージェントの3経路を想定
MCP・A2AとPersonal Agent Protocolの違い
PACTとの違いと今後の関係
参加企業は対応済みという意味ではない
開発者・企業が現時点で確認しておきたいこと
v0.1公開後に見るべき点
まとめ
公式情報・参照先

Personal Agent Protocolの現在地

項目	2026年10月8日時点の状況
名称	Personal Agent Protocol
目的	個人AIエージェントが利用者の代理で企業サービスを利用するときの共通ルール
発表日	2026年10月6日
中心となる企業	Sierra、Meta
共同開発に参加する企業	Genesys、Instinct、Rocket、Shopify、Stripe、Walmart
権限の考え方	利用者が読み取り・書き込みの許可を決め、企業が提供する操作範囲を決める
セッション	OAuthを基礎に、ゲスト利用からサインイン後までのやり取りをつなぐ構想
企業への接続経路	Webサイト、MCP・OpenAPIなどを使うAPI、企業側エージェント
仕様書	v0.1を2026年10月後半に公開予定
参照実装	今後公開する計画
一般利用	対応サービス・対応製品・提供開始時期は未確定

参加企業の名前が発表されたことと、それぞれのECサイトやアプリが既にこの規格へ対応したことは別です。現段階では、規格の方向性が示されたと理解するのが正確です。

なぜ個人AIと企業の間に新しい標準が必要なのか

現在、多くの個人AIエージェントは、人間向けのWeb画面を開き、ボタンを押し、フォームへ入力する方法で業務を進めています。画面操作で完結できないときは、企業のチャットやサポート窓口を使う場合もあります。

たとえば注文の配送状況を確認するだけなら、購入履歴を読めれば足ります。一方、配送先の変更や返品の申請では、本人のアカウントに対する変更権限が必要になります。

企業から見ると、次の区別が必要です。

誰が依頼したAIエージェントなのか
本人からどこまで操作を許されているのか
企業としてどの操作をエージェントへ提供するのか
ゲストで始まった問い合わせとサインイン後の処理をどう引き継ぐか

Personal Agent Protocolは、人間向けの画面操作だけに頼らず、誰の代理でどこまで許可されたAIなのかを企業側が確認できるようにする構想です。

利用者と企業は、それぞれ操作の許可範囲を決めます。利用者が「変更してよい」と指示しても、企業が提供していない操作まで可能になるわけではありません。

ゲストからサインインへ進む流れ

発表された利用の流れは、商品在庫の問い合わせを例にすると次のようになります。

企業を発見する：個人AIエージェントが企業のWebサイトから提供サービスと接続先を確認する。
ゲストでセッションを始める：在庫や返品条件など、アカウントを使わない問い合わせを行う。
必要ならサインインする：注文履歴など本人の情報が必要になれば、利用者が企業のページでサインインするか、事前にエージェントへ設定した認証情報を利用する。
読み取り・書き込みを許可する：利用者がエージェントへ与える操作範囲を決める。
企業の許可する経路で処理する：Web、API、企業側エージェントのいずれかを使って依頼を進める。

この一連のセッションはOAuthを基礎にする計画です。たとえばゲストで返品条件を聞いた後、サインインして自分の注文について質問する場合でも、同じ訪問の文脈を引き継ぐ構想になっています。

なお、これは2026年10月6日の公式発表に記載された設計方針です。認証リクエストの具体的な形式、トークンの有効期限、細かなスコープ名などはv0.1仕様の公開を待つ必要があります。

「本人の許可」と「企業の許可」は別々

Personal Agent Protocolでは、権限の決定者が一人ではありません。

誰が決めるか	決める内容
利用者	自分のAIエージェントにアカウント情報を読む権限や変更する権限を渡すか
企業	エージェントにどの機能、Web画面、API、業務を提供するか
個人AIエージェント	許可された範囲で、どの手順・接続経路を使うか

たとえば利用者が「注文の配送先を変えて」と依頼しても、企業がAI経由で配送先変更を受け付けていなければ処理できません。逆に、企業側が変更APIを提供していても、本人が読み取り専用の許可しか与えていなければ変更してはいけません。

実行できるのは、利用者が委任した範囲と、企業が提供する操作範囲が重なる部分です。

利用者から委任された操作と企業側が認める操作を分けることで、AI経由の取引や問い合わせでも権限の境界を確認できる設計を目指しています。

OAuthで何が変わるのか

OAuth 2.0は、利用者が第三者のアプリへ、対象サービスの一部の操作権限を委任する仕組みです。ユーザー名やパスワードそのものを第三者へ渡す代わりに、許可範囲に対応するアクセストークンを使う考え方が基本になります。

Personal Agent Protocolは、この実績のある仕組みを個人AIと企業サービスの連携へ使う方針です。

OAuthが主に担うのはアクセス権限の委任です。AIエージェントの識別方法、本人確認、操作記録、企業ごとの業務ルールは、それぞれ設計が必要になります。

初期発表では、トークンの具体的な形式や有効期限、権限を取り消す操作画面などはまだ示されていません。これらは今後の仕様と各社の実装で確認する項目です。

Web・API・企業エージェントの3経路を想定

Personal Agent Protocolでは、企業への接続方法をWebサイトだけに限定しない設計が示されています。

経路	使い方のイメージ
企業のWebサイト	企業が現在提供しているページを使って手続きを進める
企業のAPI	MCPやOpenAPIなどの標準を使うインターフェースへ接続する
企業側のAIエージェント	保証請求や複雑な問い合わせなど、会話が必要な業務を企業のエージェントへ引き継ぐ

企業は利用者への提供方法や業務に合わせて経路を決めます。

接続経路が変わっても本人の委任とセッションを引き継ぎ、ゲストでの問い合わせからサインイン後の注文変更まで、一続きのやり取りとして扱える設計を目指しています。

ただし、実際にどの経路を公開するか、どのようなAPIを使うかは企業側が選びます。3経路すべての実装が必須だとする仕様は、現段階では示されていません。

MCP・A2AとPersonal Agent Protocolの違い

MCPとA2Aは、AIエージェントを外部システムへ接続するための主要なオープンプロトコルです。Personal Agent Protocolはそれらを置き換えるというより、個人の代理で企業サービスへアクセスする場面の権限とセッションを扱う構想です。

規格	主な役割	代表的な相手
MCP（Model Context Protocol）	AIと外部のツール・データを接続する	API、DB、検索、社内ツール
A2A（Agent2Agent Protocol）	独立したAIエージェント同士が能力を見つけ、タスクを連携する	別会社や別システムのAIエージェント
Personal Agent Protocol	個人AIが企業サービスへ代理アクセスするための認証・委任・セッションの共通ルールを作る	利用者、個人AI、企業のWeb・API・企業エージェント

たとえば個人AIが旅行の予約を変更する場合、MCPは旅行サービスのAPIを使う接続手段になり得ます。A2Aは企業側のAIエージェントへ依頼を渡す通信手段になり得ます。

Personal Agent Protocolは、その前後で「誰の代理か」「どの権限を持っているか」「このセッションがどの顧客に結び付くか」を扱う部分を想定しています。

MCPやA2A自身にも認証・認可の仕組みはあります。Personal Agent Protocolが初めて権限管理を可能にする、という意味ではありません。個人の代理行動に特化した横断的なルールを加える、という位置づけです。

MCPとA2Aの基本的な違いは、こちらの記事でも説明しています。

MCPとA2Aの違いとは？AIエージェントの接続先と使い分けを解説

MCPとA2Aの違いを初心者向けに解説。MCPはAIとツール・データ、A2AはAIエージェント同士を接続する規格です。役割、使い分け、両方を組み合わせる構成まで整理します。

PACTとの違いと今後の関係

Personal Agent Protocolと同じ2026年10月6日、Decagonは「Personal Agent Consent & Trust Protocol（PACT）」を発表しました。こちらはInstinctと共同開発したもので、個人AIが企業側AIエージェントへ接続する際の識別と利用者の委任を扱います。

PACTはA2AとOAuth 2.0を基礎とし、次のような流れを具体的に説明しています。

接続先エージェントの情報を発見する
AIエージェントの身元と利用者の委任権限を別々に確かめる
利用者が企業側で認証し、許可する範囲を選ぶ
企業側のルールに従って操作し、実行内容の署名付き記録を扱う

DecagonはPACTをオープンソース化し、Personal Agent Protocolのワーキンググループへ参加する方針も表明しています。

ただし、PACTとPersonal Agent Protocolが同一仕様になったわけではありません。PACT側で説明されている署名付き委任トークンなどの詳細を、まだ未公開のPersonal Agent Protocol v0.1の確定仕様として扱うことはできません。

両者の統合範囲や採用方式は、今後の仕様公開で確認する必要があります。

参加企業は対応済みという意味ではない

Personal Agent Protocolの共同開発企業には、SierraとMetaのほか、Genesys、Instinct、Rocket、Shopify、Stripe、Walmartが名を連ねています。

小売、決済、カスタマーサポート、金融・住宅関連の企業が参加することで、注文や返品、アカウント変更、問い合わせなど異なる業務を視野に入れています。

しかし、2026年10月8日時点では、これらの企業がすべてPersonal Agent Protocolを本番サービスで受け付けているという公式情報は確認できません。

一般利用者が「いつからどのAIでWalmartへ注文変更できるか」「Shopifyの全加盟店が対応するか」「Stripeの決済がこの標準で完了するか」といった点も未確定です。

特に決済は、初期発表で将来の拡張候補として挙げられています。クレジットカード情報を共有せずに購入を完了する機能が、初版で既に使えるとは書けません。

開発者・企業が現時点で確認しておきたいこと

Personal Agent Protocolへすぐ対応するための確定したSDKやv0.1実装手順は、まだ公開されていません。一方で、将来の対応に向けて今から決めておける設計上の項目はあります。

確認すること	設計で必要になる判断
ゲストでできる範囲	在庫・FAQなど、アカウントがなくても公開できる情報
本人確認が必要な操作	購入履歴、予約情報、アカウント変更など
読み取りと書き込みの境界	閲覧と変更を別の許可として扱うか
企業側の操作制限	取消・返金・住所変更などをAIへ任せる範囲
実行記録	AI経由の操作を人の操作と区別して追跡する方法
失敗時の扱い	途中で権限が不足した場合や、処理が完了しなかった場合の戻し先