Personal Agent Protocol解説|MetaとSierraが設計したAIエージェント認証標準
「AmazonはMuseを締め出した。なぜそんなことが起きるのか。誰もエージェントの共通ルールを決めていないからだ」。2026年9月22日のHacker Newsスレッドにはこうした声が上がった(news.ycombinator.com)。Sierra共同創業者のBret Taylorも同様の言葉を残している。「標準ができるまでは、混乱が続くだけだ」(Kind of chaos until such a standard exists)と。
2026年9月20日、AmazonはMetaのAIショッピングエージェント「Muse」を自社サイトから締め出した(RetailGazette、2026年9月22日)。理由は「エージェントが自己申告せずにサイトを動き回っている」「認証情報の扱いが不透明」という2点だ。Meta側はパスワードや支払い情報にはアクセスしていないと反論したが、2026年10月時点でAmazonとの関係は解消されていない(Adweek報道)。
その16日後の10月6日、Sierra(AIエージェント開発会社)共同創業者のBret TaylorとClay BavorはMetaと連名でブログ記事を公開した(letsdatascience.com、2026年10月7日)。Personal Agent Protocol(PAP)——AIエージェントがビジネスにアクセスする際の認証・権限を定義するオープン標準だ。Walmart、Shopify、Stripe、Rocket、Genesys、Instinctが初期パートナーとして名を連ねた。
- AIエージェントをビジネスに導入しようとしているエンジニア・PM
- MCP・A2AなどAIプロトコル動向を追っている開発者・アーキテクト
- AIエージェントとECサイトの統合を検討しているECビジネス担当者
- エージェント時代のセキュリティ・認証設計に関心のある人
なぜ今、この標準が必要になったか
Amazon vs Meta Muse:アクセス権の無法地帯が露呈した
Muse事件の本質は「AIエージェントには身元証明がない」という問題だ。
人間がAmazonにログインするとき、Amazonはそのユーザーが誰で、何を買ったことがあり、どんな設定をしているかを把握している。ところがAIエージェントが同じサイトを操作するとき、そのエージェントが「誰のために動いているか」「どこまで許可されているか」を確認する仕組みが存在しなかった。
Metaはユーザーの許可を取ってMuseを動かしていたと主張する。だがAmazonからみれば、自社のrobots.txtやCookieポリシーを経由せずに動く「正体不明のボット」でしかない(Shellypalmer.com、2026年9月21日)。
Shopifyがいち早くMetaのMuseと提携したのは対照的だ。Shopifyは自社のShop PayをMuseに統合することで「認証済みエージェント」として受け入れた(Adweek、2026年9月20日)。同じエージェントでも、「対話のルール」があるかどうかで扱いが180度変わる。
OAuthが生まれた頃と同じ問題
Bret Taylorはブログで「Googleでログインする」機能の誕生を引き合いに出した。2007年から2010年にかけて、サードパーティアプリがユーザーのパスワードを直接要求するのが当たり前だった時代があった。OAuth 2.0はその問題を解決するために生まれた(RFC 6749として2012年に策定)。
PAPが解決しようとしている問題は構造的に同じだ。ユーザーが「このエージェントに自分の代わりに買い物させてよい」と許可したことを、ビジネス側が検証できる仕組みが必要なのだ(aicoder.com、2026年10月7日)。
Personal Agent Protocolの仕組み
3つのアクセスルート
PAPでビジネスにアクセスするエージェントは、3つのルートのいずれかを使う(pymnts.com、2026年10月8日)。
| ルート | 概要 | 向いているケース |
|---|---|---|
| Webサイト経由 | エージェントがブラウザと同様に通常のページを操作 | 既存サイトをそのまま活用したい場合 |
| API経由(MCP/OpenAPI) | ビジネスが公開するAPIをエージェントが呼び出す | 構造化データのやり取りが多い場合 |
| ビジネス側エージェント経由 | ビジネスが持つエージェントと直接対話 | 複雑なマルチエージェント連携が必要な場合 |
3段階の権限レベル
認証後の権限はOAuthの仕組みを拡張した形で3段階に設計されている。
- ゲストアクセス — 読み取り専用。カタログ閲覧や価格確認など
- 読み取りアクセス — ユーザーのアカウント情報(購入履歴、設定)を参照可能
- 書き込みアクセス — 注文・予約・フォーム送信など、実際の操作が可能
ビジネス側が「このエージェントにはゲストアクセスのみ許可」といった制御を行い、ユーザーも「私のエージェントには注文権限まで渡してよい」と設定できる構造だ(beri.net分析記事)。
MCPとの関係:競合か補完か
「PAPとMCPは何が違うのか」は、PAP発表直後にHacker Newsでも議論になった。
結論からいえば補完関係だ。立ち位置が異なる。
- MCP(Model Context Protocol) — AIエージェントとツール・データソースを接続する「縦」の接続プロトコル。「エージェントがどのツールを使えるか」を定義する。
- PAP(Personal Agent Protocol) — エージェントがビジネスに接触する際の「身元確認と権限」を定義する「横」のレイヤー。「そのエージェントは誰のものか、何をしてよいか」を決める。
実際にPAPの設計では、「API経由ルート」においてMCPを通じたデータ接続を明示的にサポートしている(letsdatascience.com)。MCPの上にPAPが乗るイメージだ。
AnthropicのMCPが2024年11月に公開されてから、A2AとAAIFへの統合という流れを経て、AIエージェントのプロトコルスタックは徐々に整備されつつある。PAPはそのスタックに「認証・権限」レイヤーを加える試みと位置づけられる。
光と影:PAPが直面する現実
光の部分:共通基盤が生まれれば全員が得をする
Forkcastは「PAPが業界標準になれば、エージェント開発者はビジネスごとに個別の連携を実装する必要がなくなる」と指摘する(forkast.news)。開発コストの削減は明確なメリットだ。
Walmart、Shopify、Stripeという決済・EC大手の参加は、少なくとも「エコノミー系」の大手は対話のテーブルに着いたことを示す。Taylorは「OpenAIとAnthropicが加わることを期待している」と発言しており、参加拡大の余地はある(pymnts.com)。
影の部分:Amazonがいない、仕様もまだない
最大の問題はAmazonが参加していないことだ。AmazonはECの最大手であり、Muse事件でPAP誕生のきっかけを作った当事者でもある。Amazonが参加しなければ、最も重要なECプラットフォームでは結局「エージェントvs.robots.txt」という力比べが続く。
OpenAI・Anthropic・Googleも現時点では不参加だ(fourweekmba.com)。主要AIプロバイダが揃わない状態での「業界標準化」は難しい。
仕様のv0.1はまだ公開されていない。2026年10月末の公開が予告されているが、実際に開発者が実装できる状態になるのはもう少し先になりそうだ。「Walmart加盟まえに仕様ができていない標準」というのは前例がなくはないが、スタートとしては異例のスピードでもある。
競合・関連プロトコルとの位置づけ
実はPAP以外にも、AIエージェントの商取引に関するプロトコルが複数存在する。
| プロトコル | 主導 | レイヤー | 現状 |
|---|---|---|---|
| PAP | Sierra+Meta | 認証・アクセス権 | v0.1仕様策定中 |
| MCP | Anthropic→AAIF | ツール・データ接続 | 業界標準として普及中 |
| A2A | Google→AAIF | エージェント間通信 | 150社超が採用 |
| ACP | OpenAI+Stripe | 決済チェックアウト | Apache 2.0でOSS公開済 |
| AP2 | 決済認証・署名 | FIDO Allianceへ移管済 | |
| TAP | Visa | 決済認可 | 開発中 |
PAPの特徴は「決済の前の認証・許可」にフォーカスしている点だ。ACPやAP2が「どうやって支払うか」を扱うのに対し、PAPは「そのエージェントはこのサイトに入っていいのか、何をしていいのか」を定義する。入口の鍵と、レジでの支払い方法は別の問題だ(beri.net)。
注目すべきはStripeがPAPとACP(OpenAI主導の決済プロトコル)の両方に参加している点だ。ShopifyもPAPとGoogle主導のUCP双方を採用している。主要企業が複数の標準に「保険」をかけており、真の業界統一標準には至っていないことを示している。
日本への影響
国内でAIエージェントを活用するエンジニア・PM視点で考えると、短期的な影響は限定的だ。v0.1仕様が出ていない現時点では「実装する」という状況ではない。
ただし、楽天・Yahoo!ショッピング・Amazon.co.jpなど日本の主要ECプラットフォームが今後どう対応するかは注目に値する。Meta Museのような日本語対応AIショッピングエージェントが出てきたとき、日本のECサイトも同じ「エージェントを受け入れるか締め出すか」という判断を迫られる。
「PAP準拠のエージェントは受け入れる、非準拠は締め出す」という流れが定着すれば、エージェント対応の可否がEC競争力に直結する時代が来る。AIエージェント自動化の実践ガイドでも触れているが、認証・権限の標準化はエージェント普及の重要な前提条件の一つといえる。
- MCP → 自社AIエージェントに外部ツール・API・データソースを接続するとき
- PAP → 自社の構築したAIエージェントが外部ビジネスサイトにアクセスするとき、またはビジネスとして外部エージェントを受け入れる仕組みを作るとき
- v0.1仕様は2026年10月末公開予定。現時点では動向ウォッチが最優先
AIエージェントのプロトコル・標準化動向を継続フォローするなら、A2AとMCPの関係解説とAIエージェント比較2026年版も参照のこと。
関連記事
- A2AがAAIFに加入|MCPと同じ屋根の下でエージェントプロトコル戦争に終止符
- AIエージェント業務自動化の完全ガイド2026
- AIコーディングエージェント比較2026年版
- MCP Agent Plugin標準の現在地
本記事の情報は2026年10月10日時点のものです。PAPのv0.1仕様は未公開であり、最新情報はSierraおよびMetaの公式ブログでご確認ください。