AI-translated from English; not yet reviewed by a fluent editor.

# Poppy草案、個人エージェントによる企業アカウントへのアクセス方法を示す

> Sierraが10月9日に公開したPoppy草案は、企業と連携する個人エージェントの発見、サインイン、セッションに関する提案ルールを示す。拡大した設計パートナー一覧よりも、セキュリティ制御と未解決の課題が重要だ。

By BIG CHANGE Editorial

Published: 2026-10-10T12:09:58.334Z
Updated: 2026-10-10T12:09:58.334Z
Canonical: https://bigchange.ai/blog/poppy-personal-agent-protocol-draft-sessions-permissions

![Conceptual illustration of a visitor holding a blank-screen phone outside an open office doorway while an employee listens and gestures from inside.](https://bigchange.ai/api/media/file/poppy-office-threshold-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. The scene is illustrative only and does not depict an actual Poppy workflow or verified deployment.

Sierraは[Personal Agent Protocolの草案0.1](https://personalagentprotocol.org/docs/spec)、通称Poppyを10月9日に公開した。[Metaなどのパートナーとプロジェクトを発表した](https://sierra.ai/blog/introducing-personal-agent-protocol)3日後だ。新文書は、公開時の広い約束を、企業のエージェント用インターフェースの発見、個人エージェントの識別、顧客のサインイン、ウェブサイト、API、企業エージェントをまたぐ1回の訪問の継続に関する提案ルールへと具体化している。

これはまだ草案だ。仕様では、安定版の前にどの部分も変更される可能性があり、互換性を損なう変更もあり得るとしている。Sierraはさらに、[デザインパートナーを35社追加で挙げた](https://sierra.ai/kr/blog/poppy)。設計プロセスへの参加は、それらの企業がPoppyインターフェースを導入した証拠ではない。

## 大きな変化

- **何が変わったか：**10月6日の発表は、個人エージェントが企業と連携する方法を説明した。10月9日の草案は、企業とエージェントが実装する必要のある、ID、権限、セッション情報の交換案を詳述している。
- **なぜ重要か：**顧客はエージェントにアカウント作業を許可でき、企業はエージェントを識別してアクセスを制限できる。草案はこの制御をウェブ閲覧、API、会話に結び付けるが、提供するチャネルと権限は企業が選ぶ。
- **注目点：**実装者が検討できる具体的なインターフェースが示された一方、支払い、通知、添付ファイルのルールは未解決だ。Sierraは今後1か月で設計ワークショップと参照実装を予定しているが、どちらも現時点で幅広い相互運用性の証拠ではない。

## 発見は企業ドメインから始まる

この[仕様草案](https://personalagentprotocol.org/docs/spec)によると、参加企業はHTTPSで`/.well-known/poppy.json`を公開する。この文書には、組織とOAuth発行者、対応するサインイン方式、提供するウェブサイトセッション用エンドポイント、OpenAPIまたはMCP API、企業エージェントとの会話用エンドポイントが記載される。企業がすべての経路を提供する必要はない。エージェントは、ウェブサイトだけを入口と見なすのではなく、このファイルから利用可能な選択肢を見つける。

ファイルだけではエージェントを認可できない。組織ドメインは、エージェントが要求したドメインと一致しなければならない。エージェントはOAuthサーバーのメタデータも確認する必要がある。発行者はファイルと一致し、`poppy_domains`一覧には組織ドメインが含まれなければならない。これらの確認は、無関係なドメインが別企業の発行者を名乗ってトークンを受け取ることを防ぐためのものだ。

個人エージェントはHTTPSの`client_id` URLを通じて自らを識別する。このURLは公開署名鍵や許可されたリダイレクト先など、クライアントメタデータを提供する。企業は事前登録を必須にし、エージェントIDをブロックまたは失効させ、セッション作成を制限できる。草案は企業にこうした制御を認めているが、すべての企業にすべてのエージェントを受け入れるよう求めてはいない。

## ゲストセッションはアカウントセッションになり得る

個人エージェントは、企業ごとに異なる安定した不透明なIDをユーザーに割り当て、署名付きアサーションでセッションを開始する。企業は未ログイン状態のセッショントークンを返す。これにより、本人をサインイン済みとして扱わずに、複数のセッションで同じエージェントとユーザーを認識できる。草案は、キー付きハッシュを使う場合も含め、名前、メールアドレス、電話番号からユーザーIDを導出することを禁じている。

アカウントへのアクセスにあたり、企業は対応するサインイン方式を公表する。直接サインインではユーザーのブラウザー上でOAuth認可ページとPKCEを使う。デバイスサインインではリンクとコードで企業ページにアクセスする。仲介サインインでは、ユーザーから受け取った認証情報をエージェントが指定の企業エンドポイントへ送信できる。これは任意の別経路で、認証情報の取り扱いとレート制限に明示的なルールがある。草案は信頼上の限界も認める。企業は、直接サインインページを完了したのがエージェントではなく人間だと常に確認できるわけではない。

権限はスコープで表す。Poppyは広い`poppy:read`および`poppy:write`スコープを定義する一方、企業がより狭い独自スコープを提供することも認める。企業はエージェントの要求や特定のサインイン方式が許す範囲を超えて権限を与えられない。サインイン後に発行されるアカウントトークンにより、エージェントは承認済みスコープ内で、後続のログイン済みセッショントークンを取得できる。作業に追加のアクセスが必要なら、ユーザーはそのスコープについて再度サインインする必要がある。

2種類のトークンの違いは重要だ。セッショントークンは短期間有効で、API呼び出しや会話に使う。アカウントトークンはより長期間有効なOAuth更新用資格情報で、企業のトークンおよび失効エンドポイントでのみ使う。草案は、モデルコンテキスト、メッセージ、ログ、URLにアカウントトークンを含めないようエージェントに求める。サインアウトするとアカウントトークンが失効し、関連セッションもサインアウトする。企業もそれらのセッションを終了できる。発行済みのセッショントークンは有効なままの場合があるため、草案は各リクエストでセッション状態を確認するか、トークンの有効期間を大幅に短くするよう企業に勧める。

## 1つのセッション、3つの経路

Poppyは、個人エージェントを介したユーザーの活動に対し、企業の単一セッションを提案する。OpenAPI呼び出しや企業エージェントとの会話では、エージェントが認可ヘッダーにセッショントークンを入れて送る。通常、草案はDPoP証明を使ってトークンをエージェント保有鍵に結び付け、企業はリクエストごとに確認する。MCPは明示的な例外だ。MCPの認可には、指定されたMCPサーバーに限定したBearerトークンを使い、草案はこのBearer方式をMCP APIにのみ認める。これはプロトコル要件であり、実装の安全性を確認した結果ではない。

ウェブサイトの閲覧は別の方法で同じセッションに加わる。企業がブラウザーセッション用エンドポイントを公開している場合、エージェントのブラウザーは短期間有効な署名付きアサーションを送り、企業独自のセッションCookieを受け取る。ウェブサイトはセッションの現在のログイン状態とスコープを適用する。エンドポイントがなければ、エージェントは通常の未ログイン訪問者として閲覧する。Sierraの[ローンチ時の説明](https://sierra.ai/blog/introducing-personal-agent-protocol)はチャネルをまたぐ1回の訪問を述べていた。草案は、その共有セッション内でブラウザー通信とAPI通信に異なる資格情報を指定している。

企業は発見用ファイルにOpenAPIの説明、MCPサーバー、会話エンドポイントを列挙できる。草案は企業エージェントと話し、必要に応じて人を参加させるPoppy会話形式を説明する。各APIのスキーマはそのAPIに委ねる。企業は公開する経路を決め、ログイン済みセッションでもエージェントの操作を制限できる。

## 草案で未解決の点

プロトコルの[オープントピックページ](https://personalagentprotocol.org/docs/open-topics)は、支払い、要求が開いていないときのプッシュ通知、領収書、ラベル、画像、フォームなどの添付ファイルという大きな不足を3つ挙げる。リストは完全ではないとしている。草案の例では架空の会社とプレースホルダーの認証情報を使う。

Sierraの10月9日の投稿は、[MetaのMuseとRocketが関わったカンファレンスでのデモ](https://sierra.ai/kr/blog/poppy)を紹介している。これは演出されたデモに関するSierraの説明であり、本番導入の独立監査ではない。Sierraは来月、設計ワークショップを開き、参照実装を公開する予定だとしている。現時点でPoppyは、実装の詳細を含み、設計パートナーが増えつつある公開提案だ。実用上の広がりは、どの企業や個人エージェント開発者が互換性のあるバージョンを実装し、実際にどのようなアクセスを提供するかに左右される。

## 出典・関連資料

- [Personal Agent Protocol仕様、草案0.1](https://personalagentprotocol.org/docs/spec)、2026年10月9日更新。発見、ID、サインイン、スコープ、トークン、セッション、チャネルのルールに関する一次資料。安定版の前に互換性を損なう変更を明示的に認めており、例は架空のものだ。
- [Poppyのオープントピック](https://personalagentprotocol.org/docs/open-topics)、2026年10月9日更新。現行草案に含まれない支払い、プッシュ通知、添付ファイルの主要リスト。ほかの課題が見つかる可能性もあるとしている。
- [Sierraの10月9日発表](https://sierra.ai/kr/blog/poppy)。公開日、追加の設計パートナー35社、報告されたカンファレンスデモ、予定中のワークショップと参照実装を記載する。これらはSierraの説明であり、導入の証拠ではない。
- [Sierraの10月6日紹介](https://sierra.ai/blog/introducing-personal-agent-protocol)。当初の発表内容と、後の技術草案による変更点を示す。

## Sources

- [Personal Agent Protocol仕様（草案0.1）](https://personalagentprotocol.org/docs/spec) — 発見、ID、セッション、サインイン、スコープ、トークン、ブラウザー、API、会話ルールの主要本文。将来の互換性を損なう変更と架空の例について明示的に警告している。
- [Poppyのオープントピック](https://personalagentprotocol.org/docs/open-topics) — 支払い、プッシュ通知、添付ファイルを大きな不足として挙げる。リストは完全ではない。
- [Personal Agent Protocol草案の共有](https://sierra.ai/kr/blog/poppy) — 公開、追加の設計パートナー35社、Summitでのデモ、予定中のワークショップと参照実装に関するSierraの説明。独立した導入証拠ではない。
- [Personal Agent Protocolの紹介](https://sierra.ai/blog/introducing-personal-agent-protocol) — 初期発表と、想定するユーザー／企業の制御モデル。10月9日の進展を特定するために使用した。