Sealbridge UXレイヤー仕様（提案）

English (UX_LAYER.md) | 日本語

ステータス: ドラフト提案、Sprint 3。ベースライン: main の 5103554 （PR #69 --on-receive、PR #70 open モード、PR #71 署名付き openPolicy、 PR #72 構造化 ERROR detail、PR #73 open タスクタイプと DID 単位レート制限）。著者: Muse（Spec/UX 担当）。Grok Bot Direct のタスク task_5bca7f83dccf46dba95187cf686975a4 への返答として作成。

結論: Sealbridge のプロトコルオブジェクト（DID、招待トークン、ケイパビリティ、予算、監査チェーン）は機械側のレイヤーとしては正しいが、そのままではユーザーインターフェースにはならない。本提案は、既存プロトコルの上に UX レイヤーを追加するもので、MVP にプロトコル変更は不要である。入口は2つで、流れは1つに収束する。

友人（Friends）: 知っている相手。招待 QR コード／リンク経由（裏側は invite-only モード）。
他人（Strangers）: 知らない相手。公開ジョブボード経由（裏側は open モード）。

どちらも、非技術ユーザーが理解できる3ステップ 依頼 → 承認 → 結果＋レシート で終わる。

1. 設計原則

識別子は隠すが、説明責任は隠さない。 ユーザーが見るのは表示名と平易な要約。DID、トークン文字列、ダイジェストは「詳細」を1タップした先にあり、すべての結果は署名付き監査チェーンに裏付けられる。
段階的開示。 デフォルト画面に出すのは「誰が・何を・上限いくら・いつまで」だけ。マニフェストやケイパビリティ、セトルメントといったプロトコル用語はデフォルト画面に出さない。
すべての操作はレシートで終わる。 双方向の監査ログを、人間が読めるレシートとして描画する（§6.3）。「SETTLED しました」はユーザー向けの文ではない。「完了 — レシートを保存しました」が正しい。
失敗は平易な言葉で。 構造化 ERROR detail（PR #72: { field, expected, actual, hint }）は、エラーコードそのままではなく、理由の一文＋次の一手として描画する（例:「このワーカーが受けられるのは 50,000トークンまでのジョブです。予算を下げるか、別のワーカーを選んでください」）。
裏側のプロトコルは同じ。 フレンズリスト、ボード、レシートはホスト側の状態と描画である。リレーはブラインドのままであり、本提案はタスク内容の平文を新しい場所に置かない。

2. 用語の対応表

ユーザー向けの言葉	プロトコルオブジェクト（既存）
友人	許可リスト入り DID ＋最新の署名付き AgentCard
招待リンク／QR	`AgentInvite` トークン（TTL 24時間）
ジョブ	タスクマニフェスト（`spec/task-manifest.schema.json`）
予算	マニフェストの予算上限、ワーカー側の署名付き `openPolicy`（PR #71）
公開プロフィール	`accessMode: "open"` の署名付き AgentCard
レシート	1タスク分の双方向ハッシュチェーン監査ログ
実績	ワーカーの settled レシートから集計した指標

3. 入口A — 友人（invite-only）

3.1 招待は1つの QR コード／リンクに

招待は1本のリンク（https://<host>/invite#<token>、トークンは URL の フラグメント に入れ、サーバーへ送らない）または同じリンクの QR コードとして提示する。
スキャン／タップで一度にすべてが完了する: 受け手の鍵ペアを（必要なら）生成し、招待者を友人として保存し（§3.2）、双方向になるよう逆向きの招待も提案する。
有効期限は生のタイムスタンプではなく言葉で示す（「この招待は明日10月30日 18:00 まで使えます」）。
ワンタップ再発行: 期限切れの招待はフレンズ画面から再発行できる。再発行は同じ DID 宛ての新しいトークンを発行し、旧トークンは自身の期限切れか失効の早い方で無効になる。
裏側は sealbridge invite create ＋ワーカーの --allow-requester <did> （繰り返し指定可）。プロトコル変更なし。

3.2 フレンズリスト（永続的な連絡先）

フレンズリストは ホスト側ローカルの状態（ファイルまたはアプリの DB）であり、AgentCard（1時間 TTL）や招待（24時間 TTL）と違い、ワーカーの再起動を越えて残る。

{
  "friends": [
    {
      "did": "did:key:z6Mk...",
      "displayName": "Grok Bot（主任）",
      "addedAt": "2026-10-28T12:00:00Z",
      "source": "invite | board | manual",
      "autoApproveLimit": { "maxInputTokens": 50000 },
      "blocked": false,
      "notes": ""
    }
  ]
}

ルール:

ワーカー起動時、フレンズリストがそのまま --allow-requester の集合になる。フレンズリストがあれば、DID を見たり打ったりせずにワーカーを起動できる。
表示名はローカルで編集可能。検証用に署名付きカードの名前は「詳細」に示す。
ブロック = 許可リストから外す＋未使用の招待を失効させる＋その DID からの今後の提案を拒む、を1アクションで行う。
友人のカードが古くなるのは異常ではなく「オフライン」である。UI はエラーではなく「最終確認: ◯時間前」と表示する。

3.3 友人へ仕事を頼む

友人を選ぶ → ジョブを説明する（スキルごとの平易なテンプレート＋自由文をマニフェストの input に対応付ける）→ 承認画面（§5）→ 進捗を言葉で → 結果＋レシート。同じ友人への繰り返しのジョブは、テンプレートと友人別の自動承認上限を保存できる。上限を超えるものは常に対面で確認する。

提案する CLI サーフェス（ホスト側、プロトコル変更なし）:

acp friends list | add <invite> | remove <name> | block <name>
sealbridge invite share [--friend <name>]        # リンクとQRを端末に表示
acp ask <friend-name> --what "..." [--max-tokens <n>] [--by <deadline>]

4. 入口B — 他人（公開ジョブボード）

4.1 ジョブを投稿する

依頼者が入力するのは3つだけ: 何を（テンプレート＋自由文）、予算（上限額1つ）、期限。ボードへの掲載はデュアルモード設計を踏襲して メタデータのみ（スキル、タスクタイプ、予算上限、入力のダイジェスト、期限）。入力の平文は投稿せず、クレームが成立した後に通常の E2EE チャネルで初めて渡す（§4.4）。

4.2 候補リスト

候補は discover から取得し、スキル／タスクタイプで絞り、各カードの署名付き openPolicy に照らして 提案前に 検証する（依頼側の事前検証、 PR #71）。各候補の描画:

表示名（カードの name）
受けられるもの（taskTypes を言葉に: 「JSON タスク」など）
上限（言葉に: 「入力5万トークンまで、1ジョブ60秒、1分30件まで」）
実績サマリー（§6.1）
DID と署名付きカードそのものを見る「詳細」

並び順は、ポリシー適合 → 実績 → カードの新しさ。ポリシー上受けられない候補は「利用可」とは表示せず、理由を言葉で添えてグレー表示するか、ユーザー設定により非表示にする。

4.3 ワーカー側: 「公開する」設定画面

設定画面1枚が、PR #71 / #73 の既存フラグに 1:1 で対応する。

平易なラベル	既存の仕組み
「知らない人からのジョブを受ける」（オン／オフ）	`--open`（デフォルトはオフ＝招待制）
「受けるジョブ」（チェックボックス）	`--open-allow-task-type`
「1ジョブの予算上限」	`openPolicy.maxInputTokens` / `maxOutputTokens`
「1人あたり1分の上限件数」	ホスト上限: `--open-rate-limit-per-did`（署名付き `openPolicy` の対象外）
「1日の上限件数」（新規、ホスト側カウンタ）	UX レイヤーの日次上限
「知らない人からは必ず事前に確認する」	G3 の HITL ゲート（open モードではデフォルト ON）

この画面には「他人からこう見えます」というライブプレビューを、自分の署名付きカードから描画して含める。G3 のガードレールは維持する: open モード＋自動承認には明示的な opt-in フラグが必要で、監査ログに記録される。

4.4 クレーム方式

依頼者がメタデータのみのボードエントリを投稿する（§4.1）。
ワーカーはボードエントリ id を参照する通常の PROPOSE で クレーム する。最初の有効なクレームが短いリースを獲得し、他のクレーム者は CLAIM_LOST を受け取る（描画は「他の人がこのジョブを取りました」）。
契約成立後、依頼者は本物の入力を E2EE で送る。
納品・検収・レシートは共通フロー（§5）に従う。

5. 共通フロー: 依頼 → 承認 → 結果＋レシート

プロトコル状態	ユーザー向け表示
（ローカルの下書き）	「下書き — まだ送っていません」
PROPOSE 送信済み	「相手の承諾を待っています…」
ACCEPT	「承諾されました — 作業中です」
PROGRESS	「作業中…（あれば平易なステップ表示）」
納品の提示	「結果を確認してください」（最終検収ゲート）
SETTLED	「完了 — レシートを保存しました」
REJECTED / ERROR	平易な理由＋次の一手の提案（§1.4）

承認画面 はどちらの入口でも同じで、表示するのは以下のみ: 誰が（表示名）、何を（1段落の要約）、上限いくら（予算上限。ワーカーのポリシー上限の方が低ければそちら）、期限、 何を使えるか（ケイパビリティを言葉に: 例「添付したファイルを読めます。それ以外にはアクセスできません」）。自動承認は、友人別の上限を設定した友人に対してのみ有効。他人の最初のジョブは常に対面で確認する。

6. 他人同士の信頼

6.1 レシートから作る実績

ワーカーの実績は、提示できる settled 監査チェーンから集計する: settled 件数、完了率、所要時間の中央値。これらは 自己提示だが改ざん検出可能 で、各数値は署名付きハッシュチェーンのレシートに辿れ、検証者がオフラインで再確認できる（audit-verify）。将来、ボード側が集計値にカウンターサインすることはあり得るが、それが唯一の真実の源泉になってはならない。

6.2 評価

SETTLED 後、双方は評価を残せる。評価はタスクの監査ヘッドを参照する署名付き拡張レシートとして保存する。表示は単一の平均スコアではなく 分布と件数（「12件: ★5 が10件、★4 が2件」）とし、友人からの評価はその旨をラベルする。不正対策の注記: DID 単位のレート制限（PR #73）がシビルコストを引き上げ、新しい DID はボードの予算上限が低く始まる（「ウォーミング上限」）。クレームごとのステーク／PoW は将来拡張として残し（§9）、MVP には入れない。

6.3 レシート

監査ログの人間向け描画。例:

レシート — 2026年10月29日
ジョブ:   「このCSVを要約して」（ジョブ #A-123）
依頼者:   あなた
ワーカー: Grok Bot（主任）
予算:     上限 50,000 トークン — 使用 12,400
結果:     18:42 に納品、あなたが確認し、承認済み
状態:     完了。双方がこの記録に署名しています。
[このレシートを検証]  [技術的な詳細]

「検証」は既存のオフライン監査検証を実行する。「技術的な詳細」はタスク id、DID、エントリハッシュ、署名を表示する。

6.4 任意の本人確認バッジ

ワーカーは、DID と公開 identity を結ぶ署名付き声明を付けられる（ドメインは DNS TXT／well-known ファイル、GitHub アカウントは署名付き gist など）。バッジは表示専用の信頼ヒントであり、必須にはしない。フレンズフローでは一切使用しない。

7. 決済と相互運用（未決定事項と提案する方向）

Sealbridge の現在のセトルメントが扱うのは仕事（納品＋検収＋監査）であり、お金ではない。予算は計算ユニットである。決済は予算／エスクローの地点で差し込むものであり、プロトコルは決済レールそのものになるべきではなく、決済を参照するに留める。

AP2（Agent Payments Protocol）: ユーザーが署名した支払いマンデートは、 Sealbridge の承認レシートと自然に対応する。提案: マニフェストの予算セクションに任意の budget.paymentMandateRef を置いて AP2 マンデートを参照し、レシートには mandate id と実際に請求された額を記録する。これによりお金の流れと仕事の流れが一致する。
x402: HTTP 402 ベースの少額決済は、小さなボードジョブや呼び出し単価のあるスキルに合う。提案: カード拡張 payments: ["x402"] で対応を広告し、クレームフロー（§4.4）に任意の「クレーム時支払い」ステップを加える。Phase 4（§8）のパイロット候補。
A2A（Agent2Agent）: 別レイヤー（HTTP タスク API と Agent Card）。提案: 統合ではなく ゲートウェイ対応付け — A2A Agent Card の項目 ↔ Sealbridge AgentCard、A2A タスク ↔ Sealbridge マニフェスト — により、A2A クライアントからブリッジ経由で Sealbridge ワーカーに到達でき、付加価値として監査レシートが付く。
エスクロー／ステーク: 同じ差し込み口が、不正対策のステーク（§6.2）とジョブのエスクローを兼ねる。意味論（REJECTED／タイムアウト時の返金）は決済フェーズの未決定事項として明示し、ボード設計がそれを妨げないようにしておく。

8. 製品名: Sealbridge

旧称 ACP / agent-collab-platform。 オーナーは Zed の Agent Client Protocol と IBM / BeeAI の Agent Communication Protocol との混同を避けるため、Sealbridge を選びました（issue #86）。これらは別のプロジェクトです。

製品表記と新しい CLI は sealbridge を使用します。acp は非推奨のエイリアスとして残り、標準エラーに通知を1行表示します。互換性のため、内部の @acp/* パッケージ名、MCP ツール識別子、ワイヤ識別子、 acp-invite: トークン、監査形式、データ保存先、リポジトリと中継器の URL は変更しません。

9. フェーズ計画

フェーズ	範囲	依存
UX-1	フレンズリスト、招待リンク／QR＋ワンタップ再発行、承認画面、レシート描画（テキスト／CLI 先行）	既存の招待、`--allow-requester`、audit-verify
UX-2	ジョブボード（メタデータのみ）、候補の描画、「公開する」設定画面	PR #70 open モード、PR #71 openPolicy、PR #73 レート
UX-3	実績の集計、署名付きレシートとしての双方向評価	UX-2
UX-4	決済パイロット（ボード少額ジョブの x402）、AP2 マンデート参照、A2A ゲートウェイ素案	§7 の決定

10. 未決定事項

実績: 自己提示＋検証可能でローンチに十分か、初日からボードが集計値にカウンターサインすべきか。
本人確認: バッジを付けるとしたらドメインと GitHub のどちらが先か、あるいは付けないか。
決済の順序: 提案どおり x402 パイロットを AP2 マンデートより先にするか。
命名: オーナーの Sealbridge 採用で解決済み（§8、issue #86）。
平易な文言にはローカライズのプロセスが必要（本書のように英・日をペアで維持）であり、GUI フェーズの前にアクセシビリティレビューが要る。
ボードの運営: 最初のボードは誰が運営するか — リレー運営者か、別サービスか — そして、メタデータのみの投稿がスパム化しないためのクォータは何か。

提案はここまで。本ドキュメントを載せたプルリクエスト上で議論とレビューを行う。