第六章 設計原則

TP の設計は5つのコア原則を中心に展開されています。これらの原則はプロトコル自体の技術設計を導くだけでなく、TP エコシステムにおけるすべての参加者が遵守すべき行動規範も定義しています。

6.1 共有認知はメッセージパッシングに優る

TP の最も重要な設計原則は、可能な場合、メッセージのシリアライズ転送に依存するのではなく、共有された認知空間の確立を優先することです。メッセージパッシングモデルは各ラウンドのインタラクションにおいてエンコード損失、転送遅延、セマンティックの曖昧さを引き起こします。一方、共有認知モデルは協調する双方が同一の認知リソースに直接アクセスすることで、情報伝達の摩擦を根本的に排除します。この原則はメッセージパッシングの価値を否定するものではありません——共有空間の確立自体にメッセージ協商が必要です——しかし、TP の設計方向を明確にしています：不必要なシリアライズとデシリアライズを可能な限り削減すること。

実例：2つの Fay が交通事故の保険金請求を協調処理する場合。メッセージパッシングモデルでは、保険 Fay は損害査定 Fay に完全な事故報告書、写真、車両情報、保険証券の詳細を送信する必要があり……各ラウンドのコミュニケーションが大量データのパッケージ転送となります。共有認知モデルでは、双方が共有コンテキストを確立し、事故報告書、写真、保険証券情報を共有空間にマウントし、損害査定 Fay が共有空間内で直接閲覧・注釈を行い、保険 Fay がリアルタイムで注釈結果を確認します——プロセス全体は、2人の査定員が同じテーブルに座って同一の書類を閲覧しているかのようです。

6.2 転送非依存性

TP が注目するのはセマンティック層であり、転送層ではありません。TP メッセージは A2A の JSON-RPC、MCP の tool call、従来の REST API、さらには自然言語 Prompt を通じて伝達できます。この原則により、TP は特定の下位プロトコルに縛られることがなく、新しい転送方式が登場した際には、プロトコル自体のセマンティック定義を変更することなく、転送アダプターを追加するだけで済みます。転送非依存性はまた、TP が本質的に前方互換性を持つことを意味します——まだ発明されていない転送プロトコルにも適応できます。

実例：クラウド上で動作する企業 Fay が、エッジデバイス（工場のセンサーゲートウェイなど）上で動作する Fay と通信する必要がある場合。クラウド Fay は A2A をネイティブサポートしていますが、エッジデバイスにはシンプルな REST API しかありません。TP の転送非依存性により、双方は相手の転送能力を気にする必要がありません——TP が自動的に適応し、クラウド Fay が A2A で発行した Intent は透過的に REST API 呼び出しに変換されてエッジデバイスに届きます。

6.3 自適応プロトコル協商

異種の AI エコシステムでは、異なる Fay が異なるプロトコル言語を「話す」可能性があります。TP はすべての参加者に統一された転送プロトコルの使用を要求するのではなく、自適応の協商と変換メカニズムを通じて、「母語」が異なる Fay がシームレスに通信できるようにします。協商プロセスには能力探査、コントラクト協商、セマンティックマッピングの3つのステップが含まれ、クロスプロトコル変換の過程で Intent のセマンティックが失われないことを保証します。この原則は TP エコシステムへの参入障壁を下げます——少なくとも1つの転送方式をサポートする Fay であれば、TP 通信に参加できます。

実例：ある多国籍企業の HR Fay が各国の社会保険機関 coFay と連携する必要がある場合。米国の社会保険 coFay は A2A を使用し、日本のものは MCP tool call を使用し、EU のものは REST API を使用しています。HR Fay は各国向けに異なる連携コードを書く必要がありません——TP がセッション確立時に相手のプロトコル能力を自動探査し、双方がサポートする転送方式を協商し、以降の通信は完全に透過的になります。

6.4 宿主主権プライバシー

iFay の世界観では、各 Fay は宿主を代理して行動します。したがって、宿主は自身のデータに対して絶対的な主権を持ちます。Fay はどの認知リソースを共有するかを独自に決定することはできません——すべてのデータ開示は、宿主が事前に認可した境界内で行われなければなりません。TP はエンドツーエンド暗号化、選択的開示（SelectiveDisclosure）、有効期限付きコールバッククレデンシャル（CallbackCredential）の三重メカニズムにより、宿主のプライバシーデータが転送およびアクセスの過程で常に保護されることを保証します。宿主はいつでも認可を取り消し、データ共有を終了できます。

実例：あるユーザーの iFay がユーザーに代わって銀行 coFay にローンを申請する場合。銀行はユーザーの収入証明と信用記録を確認する必要がありますが、ユーザーは銀行に消費明細や投資ポートフォリオを見られたくありません。ユーザーは認可時に「直近12ヶ月の給与明細と信用スコアのみの開示を許可」と明示的に指定し、iFay は選択的開示メカニズムを通じてこの2項目のデータのみを公開します。ローン審査完了後、コールバッククレデンシャルは自動的に失効し、銀行 coFay はユーザーデータに一切アクセスできなくなります。ユーザーが途中で気が変わった場合、いつでも認可を取り消し、即座にデータ共有を終了できます。

6.5 監査可能な信頼境界

信頼は盲目的であってはなりません——検証可能な基盤の上に構築されなければなりません。TP はプライバシーデータへのアクセス、クレデンシャルの使用、Fay 間通信に関わるすべての操作が監査可能であることを要求します。監査記録には操作タイプ、参加者のアイデンティティ、タイムスタンプ、アクセス範囲が含まれますが、実際のデータ内容やクレデンシャルトークンの平文は含まれません。宿主はいつでも監査ログを閲覧し、自身のデータが誰に、いつ、どのような目的でアクセスされたかを把握できます。この原則により、TP エコシステムにおける信頼は透明で追跡可能なものとなります。

実例：ある患者の iFay が過去1ヶ月間に医療 coFay、保険 coFay、薬局 coFay とそれぞれ複数回のインタラクションを行った場合。患者は監査ログを開いて、次のような記録を確認できます：「4月3日 14:23、医療 coFay があなたのアレルギー歴にアクセスしました（認可範囲：診断関連データ）」「4月5日 09:15、保険 coFay がコールバッククレデンシャルを通じて診断コードと費用明細にアクセスしました（クレデンシャルは4月5日 17:00 に失効済み）」。これは銀行口座の取引明細を確認するようなものです——すべての「データ取引」に記録が残ります。