Personal Agent Protocol(PAP):SierraとMetaがこれまでに公開したもの

Personal Agent Protocolとは何か

私はeeselで連携機能を作っています。ある標準がエージェントを企業に対して「authenticates with and acts on」する方法を示すと約束すれば、APIの契約書を読むように読みます。何が定義され、何が意思表明の一文にすぎないのか。Sierraの発表の大半は意思表明ですが、その意思は具体的です。

個人エージェントとは、Meta Muse、Instinct、OpenAI dotsのような、消費者のために働くアシスタントです。Sierraによれば、現在ほとんどは「use websites and apps the way people do」であり、それがうまくいかなければサポート窓口に電話するかウェブチャットを開きます。PAPはこれを、直接かつ認可された接続に置き換えることを目指しています。3つの立場が、それぞれ別のものを求めています。

• 消費者は、速さ、信頼性、安心を求めます。
• ブランドは、可視性と制御を求めます。個人エージェントが顧客のために動いていることを知り、何ができるかを決めたいのです。
• エージェント開発者は、参加企業と一貫した方法で連携することを求めます。

Sierraの投稿で名前が挙がっているパートナーは、MetaとSierraに加えて、Genesys、Instinct、Rocket、Shopify、Stripe、Walmartです。StripeのKevin Miller氏は、企業側の視点を率直に述べました。

"We're contributing to the Personal Agent Protocol to give businesses a standard way to recognize their customers' agents, efficiently interact with them, and shape their customer relationships."

Kevin Miller, Stripe

PAPのセッションはどう動くのか

Sierraの説明に沿って、流れを順に見ていきます。プロトコルはウェブサイトから始まり、個人エージェントはそこで企業が何を提供し、どう連絡すればよいかを知ることができます。次にエージェントは自分のユーザーのためにセッションを開き、そのセッションはゲストとして始められます。ゲストセッションなら、商品の在庫確認や返品ポリシーの質問には十分かもしれません。

タスクにアカウントへのアクセスが必要になると、顧客は企業のページでサインインするか、エージェントに設定済みの認証情報を使います。エージェントに読み取り専用の権限を与えるか書き込み権限を与えるかは、顧客が決めます。セッションは「Googleでログイン」の裏にあるのと同じ認可標準であるOAuthの上に作られ、チャネルをまたいで引き継がれます。サインイン前の質問とサインイン後の注文変更は、1回の訪問として扱われます。

その後、企業がどのドアを使うかを選びます。

サポートチームが注目すべきは3つ目のドアです。Sierra自身の投稿が、企業エージェントは「tasks that need conversation」を扱うと述べており、ヘルプデスクの企業エージェントはまさにそれです。デイビッド・シングルトン氏が投稿で挙げているMeta Business Agentは、企業側における同じ発想のMeta版です。私の見方では、PAPは玄関の標準であり、ドアの向こうにあるのは、これまでどおり自社のポリシーとAIカスタマーサービスのワークフローです。

もう1点、はっきり言っておくべきことがあります。Sierra、Genesys、Decagonはいずれも企業側のエージェントやコンタクトセンターのソフトウェアを販売しているため、「企業エージェント」のドアは彼ら自身の商売の領域でもあります。だからといって発想が間違いになるわけではありません。ただし「オープン」は「オープンな仕様」の意味で読み、最初のリファレンス実装を誰が書くかを確認すべきです。

実際に公開されたものと、約束だけのものは何か

多くの報道が飛ばした部分なので、日付順に追いました。以下はすべて発行元自身のページにリンクしています。

最後の行は2回読んでください。発表は「companies set parameters for what those agents can do」という原則を述べていますが、顧客や企業が特定のアクションを制限できるより細かい制御は、今後の作業として書かれています。つまり現時点のPAPが紙の上で与えるのは、ゲストとサインイン済みのセッション、読み取りと書き込みのアクセス、そしてドアの選択の3つです。アクション単位の制限は、説明されている最初のバージョンには含まれていません。

Sierraは、サポートチームにとって最も重要なギャップも認めています。fleming-1の投稿で、エージェントがプロトコルを使えば「the company knows it's an agent and who it's acting for」と述べたうえで、「Of course, some agents may not respect the protocol.」と付け加えています。だからSierraは2日後にfleming-1を出しました。発信者の音声がAIによって生成された兆候をリアルタイムで採点するモデルです。Sierraは、これは「tuned to be conservative by default, so real people don't inadvertently get flagged」であり、判定ではなく情報を提供するためのものだと述べています。

誰が参加し、誰が欠けているのか

パートナーの一覧は誰に聞くかで変わります。違いこそが要点なので、表にする価値があると思います。各情報源を直接確認しました。

シングルトン氏の一覧にはNiCEとDecagonがあってInstinctがなく、Sierraの一覧にはInstinctがあってNiCEとDecagonがありません。おそらく2日の間にワーキンググループが拡大したのでしょう。ドラフト段階の標準なら想定どおりです。4つの投稿のいずれにも名前がないのは、OpenAI、Anthropic、Amazon、Google、Zendesk、Salesforceです。コマースで最も重要なのはAmazonです。9月に自社の小売サイトからMetaのMuseをブロックしました。Xのあるコメンテーターは、そのコストを率直にこう述べました。

"Nobody asked the person whose agent stopped working."

Ryan Sarver, X

発表に対するXの反応はまちまちでした。Stripeの投稿への返信の1つは、業界で見てきた懐疑論の多くを代弁しています。

"like you read the PACT announcement and released this with no spec?"

Jeff Schneider, X

これは動機についての推測で、Sierraの投稿はそう言っていません。ただし日付は合っています。PACTのコードが公開されたのは10月6日、仕様のないままPAPが発表された日と同じです。

PAPとPACTはどう関係するのか

PACTは最も明確に定義された親戚なので、理解しておく価値があります。PACTはPersonal Agent Consent & Trustの略です。DecagonがInstinctと共同開発し、オープンなリポジトリには、仕様、TypeScriptスキーマ、リファレンスプロバイダー、デモ用の個人エージェント、適合性テストがすべてApache-2.0で含まれています。

動作は3つのステップです。

1. 発見と接続。 個人エージェントは企業のA2A Agent Cardを読み、エンドポイント、認証方法、orders:readやorders:cancelのような提供スコープを確認します。エージェントは各リクエストを短命のJWTで署名するため、プロバイダーはどのプラットフォームが呼び出しているかを検証できます。
2. 顧客の認証。 エージェントはOAuthのデバイス認可フローでスコープを要求し、顧客にログインリンクを見せます。顧客は企業に直接サインインして権限を承認します。エージェントがパスワードを見ることはありません。
3. 付与された範囲内での実行。 各リクエストにはエージェントのIDと顧客の委任の両方が含まれ、レスポンスには使われたスコープと実行されたアクションを記録した署名付きレシートが付きます。

PACTの設計で私が最も気に入っているのは、IDと権限の分離です。"Verify which agent is calling independently of what the customer has permitted it to do." Xのある返信者は、これが素のOAuthにとってなぜ重要かを指摘しました。

"OAuth tells the business which customer, not which agent process holds the token. A copied bearer token works until it expires, so keep those short."

Mike Moore, X

PACTはこれに、署名付きのエージェントJWTと短命の委任トークンで答えています。PAPの発表は、これをどう扱うかをまだ述べていません。v0.1の本文が重要である理由がまた1つ増えました。PACTを基にした製品、検出機能や航空会社の例については、以前のDecagon Personal Agent Gatewayの解説をご覧ください。その記事への訂正が1点あります。PACTの仕様は公開されていないと書きましたが、現在は公開されており、リポジトリは10月6日に公開されました。

PAPは他のプロトコルとどう比べられるのか

正直に言えば、これらのプロトコルは多くが異なる問いに答えており、読める文書があるものとないものがあるため、比較は偏っています。スクリーンショットを撮っておきたい表がこれです。

目を引く点が2つあります。第一に、PAPは誰もまだ完成させていない行、つまりすべてのチャネルにわたる、消費者のエージェントと企業の間の同意とスコープを狙っています。第二に、決済の行のどれもサポートとは一切やり取りしません。Visaのプロトコルはドメインと個別の操作に結び付いた署名を使い、Mastercardのスコアは取引がAIによって開始されたかどうかに関するものです。どちらも、顧客のエージェントが返金を求めていることをヘルプデスクには伝えません。Sierra自身の投稿は「payments extensions」を今後のPAPの作業として挙げており、プロトコル群がいずれ交わる場所を示しています。オンライン販売をしているなら、agentic commerce protocolとStripe版が、同じ話のチェックアウト側です。

どのプロトコルがあなたのケースをカバーするのか

気になる用途を選んでください。ウィジェットは、どの標準がそれに対応するか、どれだけ整っているか、そして私なら今何をするかを示します。

仕様が出る前に、サポートチームは何をすべきか

仕様のないプロトコルの早期採用者になるサポートチームはほとんどないでしょう。役に立つ作業はドアのこちら側にあり、最終的にPAPが標準になろうとPACTになろうと両方になろうと、同じ作業です。顧客サポート向けOpenAI dotsや顧客サポート向けInstinctが示すように、顧客のエージェントはすでにチャット、メール、電話でキューに届いています。私なら次の順で進めます。

1. サポートAIが実行できるすべてのアクションを一覧にする。 それぞれを、読み取り、元に戻せる書き込み、金銭が動くもの、アカウント制御に分類します。ほとんどのチームはこれを書き出したことがなく、これがそのままスコープの一覧になります。
2. 金銭とアカウント変更に承認を付ける。 返金は、人が頼んでもエージェントが頼んでも返金です。Zendeskの高度なAIアクションとGorgiasのAIアクションのガイドで、標準機能でどこまで制御できるかが分かります。
3. エージェントからのトラフィックを数える。 エージェントが送ったように見える会話にタグを付け、検出製品を買う前にその割合を測ります。Sierra自身も、大量の問い合わせを扱う企業は「might start by measuring how often it happens」と述べています。
4. 出口を2つ持つエスカレーションを書く。 AIは人に引き継ぐだけでなく、顧客のエージェントに何が必要かも伝えるべきです。人側の対応はAIエスカレーション管理のガイドが扱っています。
5. APIへの入口を残す。 すでにAIカスタマーサービスAPIやヘルプデスクAPIを公開しているなら、それが2番目のドアです。宣伝する前に範囲を絞ってください。
6. 本番前に過去のチケットを再生する。 実際の返金やキャンセルのチケットをAIに流し、どこで崩れるかを確認します。顧客のエージェントは、どの顧客よりも早く弱点を見つけるでしょう。

6つ目には痛い経験があります。ある営業の通話で、サポートリーダーが、AIを信頼するために何が必要かをeeselに語りました。

"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

A CX lead at a DTC supplements brand on Gorgias and Shopify, about 7,000 tickets a month

この一文は、平易な言葉によるスコープの定義です。向こう側にいる個人エージェントへのテストとしても正しいものです。自社のAIが「これは自分の担当ではない」と言えないなら、5通りの聞き方をしてくるエージェントに安全に対応することはできません。

コマースのチームには、もう1つ仕事があります。パートナー一覧に入っているShopifyを使っているなら、Shopify AIカスタマーサービス戦略のガイドとShopifyカスタマーサポート向けMuseが、エージェントがすでにそれらのキューにどう届いているかを示しています。Meta側の話はカスタマーサポート向けMeta Museをご覧ください。

eeselはどこに位置するのか

限界については率直に述べます。eeselは個人エージェントを検出せず、PAP、PACT、A2Aのいずれも実装していません。顧客が付与したスコープを伴うエージェント間チャネルを構築しているベンダーが必要なら、SierraとDecagonの2社を見るべきで、Decagon vs Sierraの比較とSierraの代替のまとめがトレードオフを整理しています。v0.1が公開されたら、eeselができることと照らして読み、差分を今推測するのではなく、きちんと書きます。

eeselが行うのは、すでにお使いのヘルプデスク上の権限レイヤーです。AIヘルプデスクチームメイトは、新入社員のようにZendesk、Freshdesk、Gorgiasに加わります。実行できるすべてのアクションは、eeselのアクションに関するドキュメントにあるとおり、読み取りと書き込みにグループ分けされ、「自動」「承認が必要」「無効」のいずれかに設定されます。平易な言葉で言えば、「調べものは自分でやっていいが、返金の前には私に聞いて」ということです。

これは、プロトコルが形式化する読み取りと書き込みの区別と同じものを、自社のAIに向けたものです。PAPがアクション単位の制限付きで登場するなら、私はそれらをこの設定に対応づけるでしょう。またプロトコルはAPIとMCPを語っているので、もう1つ補足します。eeselのすべてのワークスペースはMCPサーバーでもあり、eesel CLIは同じチームメイトをターミナルから操作します。Claude Codeのようなコーディングエージェントは、eesel integrations <platform> actionsですべてのアクションと承認設定を確認でき、eesel approvalsで保留中のアクションを承認または却下できます。CLIはダッシュボードと同じ権限に従うため、「承認が必要」に設定された書き込みは、人が承認するまで保留されたままです。

人々は何と言っているか

PAPそのものへの世間の反応は、発表から3日ということもあり、まだ少なめです。エージェントがサポートに連絡することをめぐる、より広い議論のほうが活発です。Hacker Newsで見つけた最も有用なコメントは、顧客側の立場から出たものでした。

"The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given."

CamperBob2, Hacker News

これを、XでのSimon Taylor氏によるPAPの読み解きと並べてみてください。彼はPAPをブロックの代替と呼び、企業が「recognize it, give it read-only by default, and route anything that moves money to your own agent」できるようになると述べました。これは彼の解釈でSierraの文言ではありませんが、私が目指して作りたい形です。ブロックは顧客を追い返し、制限のない開かれたドアはもっと悪い。スコープがあるからこそ、双方が何かを得られます。

eeselを試す

顧客のエージェントが、あなたのキューに返金を求め始めようとしているなら、最初の仕事は自社のAIが何に「はい」と言ってよいかを決めることです。eeselのAIヘルプデスクチームメイトは、Zendesk、Freshdesk、Gorgiasに接続し、過去のチケットとヘルプセンターから学び、一線を守る様子を確認できるまで、返金とキャンセルを承認の背後に置きます。顧客に触れる前に、シミュレーションで過去のチケットに対して実行できます。

無料プランには100クレジットとすべての連携が含まれ、有料プランは500クレジットで月額299ドルからです。チケット1件またはチャット1件が1クレジットで、詳細はeeselの料金ページをご覧ください。ご自身のキューでeeselを試してみてください。