エージェントに渡すのは、ログインではなく委任状かもしれない

AIがホテルを探し、予約までしてくれる。そのときホテル側から見えるのは、誰なんだろう。

本人のブラウザと同じCookieを使い、本人と同じ画面をクリックするなら、システム上は本人に見える。けれど、予約の取消料を読んだのも、日付を選んだのも、最後に確定したのもエージェントかもしれない。「ログインできる」と「その予約をしてよい」の間には、結構大きな距離がある。

2026年10月6日にSierraとMetaが発表したPersonal Agent Protocol（PAP）は、この距離を扱おうとしている。ホテル予約や業務SaaSを設計する立場では、ツールを増やす話より、この境界の方が気になる。

この記事の確認日は2026年10月7日JST。PAPの発表と、既存の認可標準を分けて読んでいく。

OAuthの後継というより、OAuthの上に置く約束

発表では、PAPのセッションはOAuthを基礎とする。ゲストで始め、必要に応じて本人のアカウントへ接続し、企業が提供するWeb、API、企業エージェントを横断してタスクを進める構想だ。利用者は読み取り・書き込みのアクセスを選び、企業も許可する経路や操作を決める。

ここで「OAuth以後の標準」と呼ぶと、少し誤解が生まれる。OAuthを置き換えるのではなく、消費者のエージェントと企業の間にある、発見・セッション・認可・可視性の約束をそろえる試みとして読む方がよい。

また、発表時点ではv0.1は月内公開予定だ。行為ごとの細かな制限、通知、決済拡張は将来の可能性として示されている。金額上限や承認トークンがすでに規格化されたわけではない。

以下で考える設計は、PAP仕様の解説ではない。既存標準と業務要件から組み立てる、受け入れ側SaaSの検討案である。

新しいのは「代理人」という概念そのものではない

OAuth周辺には、すでに使える部品がある。

部品	既存標準で扱うこと	それだけでは決まらないこと
Token Exchange / actor claim	委任された実行主体を表す	その予約や購入が本人の意図に合うか
Rich Authorization Requests	構造化した認可要求を渡す	ホテルごとの取消・料金変更の意味
OAuth Security BCP	宛先や権限の制限、トークン再利用への対策	AIが規約を誤読した場合の業務判断

RFC 8693 §4.1の `act` claimは、トークンの主体とは別に、委任を受けて行動するactorを表現できる。だから「ユーザーと代理人を別々に記録する」は、AI時代に初めて発明されたアイデアではない。

RFC 9396は、単純なscope文字列では足りない認可要求を `authorization_details` として構造化する。型や操作、対象の情報を表現する仕組みだ。ただし、予約総額・変更可能な日程・取消条件の意味は、業務側が定義し、認可サーバーとリソースサーバーが一貫して適用しなければならない。

RFC 9700には、トークンの宛先を限定することや、盗まれたトークンの再利用を抑える対策がある。これらの採用をPAPが要求するかは、公開仕様を待つ必要がある。

推測ですが、PAPの価値は暗号や認可の新発明よりも、これらを企業との顧客接点へ持ち込む共通の手順にありそうだ。暗号学的に正しいだけでは、利用者が「何を任せたか」を理解できない。企業ごとに接続方法が違えば、エージェント側も安定して使えない。

有効な権限は、許可の交差部分になる

ここからは、説明用の独自モデルを置く。

利用者が委任した操作集合を $U$、企業が受け入れる操作集合を $B$、その時点の業務状態で可能な操作集合を $S_t$ とする。実際に実行してよい操作は、

$$A_t = U \cap B \cap S_t$$

になる。

利用者が取消を許可していても、すでに宿泊開始後なら同じ取消処理はできない。企業が予約変更APIを開いていても、利用者が検索しか任せていなければ変更してはいけない。認可はロールの固定表だけではなく、状態と一緒に判定するものになる。

この集合モデルには限界もある。総額5万円までという制約は、各操作の可否だけでなく、複数の操作が使った予算の累積に依存する。したがって $S_t$ には予約状態だけでなく、残予算や承認の使用状態も含める必要がある。

これは「AI用のロールを一つ追加すれば終わり」という設計から、一段先へ進む理由になる。

ホテル予約なら、検索と確定の間にもう一つ境界がある

たとえば「来週の出張で、キャンセル可能な部屋を総額5万円以内で予約して」と頼む。

検索条件を受け取るAPIと、支払い義務が発生する確定APIでは、必要な情報が違う。

段階	許可対象の例	サーバーが残すもの
探す	指定都市・日程の空室検索	検索条件、代理人、セッション
見積もる	部屋・プランを仮選択	税込総額、取消条件、見積有効期限
承認する	特定の見積を許可	承認者、対象見積、条件の版
確定する	承認された見積で予約	最終総額、予約ID、再試行識別子
変更する	指定範囲の変更	追加料金と条件変更への新しい許可

すべての予約に人間の都度承認が必要、という意味ではない。広い範囲を事前に委任する設計もあり得る。ただし、「取消可能」の意味や、予算に含む項目をサーバーが判定できる形へ落とす必要がある。

5万円の見積へ承認を得たあと、在庫が変わって6万円になった場合。古い承認を流用して確定してはいけない。見積ID、総額、通貨、日程、取消条件の版を承認に結び付け、確定時に照合する。

さらに、タイムアウトしたから再実行するという、エージェントには自然な行動が二重予約を作る。確定処理には冪等性が必要だ。予算を二つの並列タスクが共有するなら、どちらも「残額5万円」を読んだまま4万円を使わないよう、予算の予約と消費を原子的に扱う。

ここはトークンの問題だけではない。認可とトランザクション設計の交点だ。

正しく認証されたエージェントも、間違った命令に従う

商品説明や予約サイトのページに、エージェントを誘導する文章が混ざっていたとする。エージェントがそれを指示として扱い、利用者が望まない変更を試みる。

認証に成功していることは、この誤動作を防がない。読み取った内容と、権限を与えた主体を区別する必要がある。

ここから導ける設計上の方針は、重要な制約をモデルのプロンプトだけに置かないことだ。総額、対象予約、変更範囲、承認期限は、サーバー側のポリシーと業務状態で判定する。モデルが「許可されたと思う」と説明しても、その説明で権限を増やさない。

監査ログにも、本人のIDだけでは足りない。代理人の識別子、委任ID、適用したポリシーの版、承認対象、操作結果を関連付けたい。一方で、思考過程や会話全文を無条件に保存する必要はない。後から判断を再現するための情報と、余分な個人情報を分ける。

撤回も同様だ。短命トークンだけで十分か、実行直前に委任の状態を確認するかは、取消可能な時間や損失額で変わる。すでに成立した契約を、トークン失効で巻き戻すことはできない。

Webを捨てる話でも、企業が顧客を失う話でもない

Sierraの構想はWebを残している。APIも企業エージェントも、企業が経路を選ぶ。

技術的には、APIの方が入力や結果を検証しやすい場面は多い。ただ、例外処理、本人確認、複雑な相談には別の経路が必要になる。共通のセッションが、これらの経路をどう接続するかが重要だ。

ビジネス上も緊張がある。利用者のエージェントは条件を比較したい。企業は関係性やサービス品質を保ちたい。接続の標準化だけで、両者の利害が一致するわけではない。対応企業数、実タスクの完了率、例外時の有人引き継ぎ、接続コストを見なければ普及は判断できない。

仕様を待つ間に、業務の委任を定義する

PAPのトークン形式やdiscovery endpointを、先回りして実装する必要はない。今できるのは、サービス自身が「何を任せられるか」を定義することだ。

僕ならまず、予約の検索・確定・変更・取消を別の操作として扱い、次のケースを検証対象にする。

• 承認後の値上がりを、古い許可で確定できないか。
• タイムアウト後の再試行で、予約や請求が重複しないか。
• 並列実行で、共通の予算を超えないか。
• 委任を撤回した後に、待機中のタスクが実行されないか。
• WebからAPIへ移っても、誰の代理として実行したかが追えるか。

これはPAP準拠テストではなく、代理実行の業務テストである。公開仕様が出たら、discovery、actorの識別、細かな認可、撤回、承認の扱いを、このモデルへ照らして読みたい。

エージェントに必要なのは、本人の鍵を丸ごと渡すことではなく、任せた仕事の範囲が双方から見えることなのかもしれない。

Sources

確認日：2026-10-07 JST。PAPは発表本文、RFCは関連節を参照。ホテル予約のモデルと設計案は独自の考察であり、PAPの確定仕様ではない。

• Sierra, Introducing Personal Agent Protocol, 2026-10-06.
• IETF, RFC 8693: OAuth 2.0 Token Exchange, 特に§4.1.
• IETF, RFC 9396: OAuth 2.0 Rich Authorization Requests.
• IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security, 特に§2・§4.10.

実サービスの契約責任や決済の扱いは、法務・セキュリティの専門家に確認が必要になる。