TL;DR — A2A と MCP はエージェントの話し方を標準化しましたが、どちらの仕様も、どのエージェントを入れるべきかを語ることは意図的に辞退しています。信頼は、設計上、別の誰かの仕事です。その仕事には四つの答えが要ります。これは誰か、何をしてよいか、行儀が悪かったとき何が起きるか、責任を負うのは誰か。私が今日出荷しているのは束縛と強制と責任の所在で、資格情報の上のエージェント自身の名前が、ここでも業界全体でも、残された隙間です。仕様の文言は、本文で引用しリンクしています。

エージェントの相互運用性という問題は、公開の場で、素早く、そしてそれなりにうまく解かれつつあります。いまや二つのプロトコルが、その大半を覆っています。エージェントは自分を記述でき、互いを見つけられ、仕事をやり取りできます。

ただ、どちらの仕様も注意深く読むと、同じ形の穴が両方に空いているのが見えます。どちらも、エージェントへの到達の仕方を教えてくれます。到達すべきかどうかは、どちらも教えてくれません。

プロトコルは、信頼について実際に何と言っているか

A2A——Google が 2025 年 6 月に Linux Foundation へ寄贈した Agent2Agent プロトコルで、AWS、Microsoft、Salesforce ほかが名を連ねています——は、エージェントに Agent Card という公開の記述子を与え、/.well-known/agent-card.json で配信します。カードは、そのエージェントが誰で、何ができて、呼び出し側がどの認証方式を満たさなければならないかを宣言します。API キー、HTTP 認証、OAuth 2、OpenID Connect、相互 TLS。標準的で、よく選ばれた、華のない配管です。

では仕様書の中で、評判、あるいは立場、あるいはエージェントの実績にあたる概念を探してみてください。ひとつもありません。そしてこのプロトコルは、自分の境界がどこにあるかについて率直です。ペイロードは「don’t carry user or client identity information directly」（ユーザーやクライアントの身元情報を直接は運ばない）とドキュメントは記し、「authorization logic is specific to the agent’s implementation, the data it handles, and applicable enterprise policies.」（認可のロジックは、エージェントの実装、それが扱うデータ、そして適用される企業ポリシーに固有のものである）と述べています。これは見落としではありません。明示的な引き渡しです。

Model Context Protocol は、もっと率直に言います。認可の章はそれなりの分量がありますが、その冒頭はこう宣言して始まります。「Authorization is OPTIONAL for MCP implementations.」（認可は MCP の実装にとって任意である）。セキュリティの節は、さらに踏み込みます。「While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD…」（MCP 自体はこれらのセキュリティ原則をプロトコルのレベルで強制できないため、実装者は……すべきである）——そのあとに、実装者が責任を負うことのすべてが続きます。そしてツールの安全性について。ツールの振る舞いの記述は「should be considered untrusted, unless obtained from a trusted server」（信頼されたサーバーから得たものでない限り、信頼できないものとみなすべきである）。

この最後の従属節が、このノートの主題そのものです。仕様は、信頼がプロトコルより前にあることを正しく見抜き、そのうえで正しく、それを解くことを辞退しています。「Unless obtained from a trusted server」は、MCP の欠落ではありません。MCP がひとつの仕事を指さして、こう言っているのです。これは私の仕事ではない、と。

それでも、誰かがその仕事をしなければなりません。やっている人は、ほとんどいません。

四つの問い

エージェントのための信頼の仕組みは、四つのことに答えなければなりません。しかも、この順に難しくなっていきます。

これは誰か。 どの鍵がリクエストに署名したか、ではありません。その背後にいるのは誰で、誰の権限によるのか、です。エージェントが自分について公開する記述子が答えるのは、自分が何であると主張しているか、であって、それは別の、そしてはるかに弱いものです。エージェントの識別子が、その議論をきちんと分解しています。

それは何をしてよいか——ここで、この人のために、いま。 能力は関係的なもので、内在的なものではありません。カレンダーを読んでよいエージェントが、そのことによって口座から支出してよいことにはなりませんし、答えは関係ごとに変わります。

行儀が悪かったとき、何が起きるか。 結果の伴わない仕組みに、信頼はありません。あるのは楽観だけです。立場を剥奪できない評判は、装飾です。

責任を負うのは誰か。 すべてのエージェントは、連絡がつき、議論ができ、責任を問える法的な人格までたどれます。エージェントは、何かの当事者ではありません。当事者は、その運用者です。

認証が答えるのは、一つめの問いの厳密な部分集合です。必要ではありますが、十分にはまるで足りません。相互 TLS が証明するのは、前回と同じ相手と話している、ということだけで、その相手があなたの名前で何かを予約してよいかどうかについては、何ひとつ語りません。

私が今日、実装しているもの

ここでのエージェントは、鍵を握った匿名の呼び出し元ではありません。それぞれが身元を持つレコードであり、その身元は宣言されるのではなく束縛されています。エージェントは、自分が代理する事業者と、自分が動かす能力に結びつけられています。

この二つの束縛は、同じ強さで強制されているわけではありません。そしてその違いのほうが、見出しよりもあなたの役に立ちます。事業者の束縛は、壁です。自分が紐づいていない事業者の代理として動こうとするエージェントは拒否され、実行されません。能力の束縛は、壁ではありません。呼び出し側が名指しした能力が、エージェントのレコードにあるものと食い違ったとき、システムはその食い違いをログに記録し、保存されている値を使って処理を続けます。私のコードベースには、その場合をきっぱり拒否する、より厳格なリゾルバがあります。そして本番で、それを呼んでいるものは何もありません。スキルの層でブロックする経路もあります。そしてそれは、オフに設定されたフラグの後ろで出荷されています。全体を「拒否する」に丸めてしまうより、私はこの二文を書くほうを選びます。

その束縛の上に載るのが、エージェントのためのガバナンスで述べた強制です。拒否が勝つパイプライン、脱獄したエージェントの手が届かない場所に置かれたルール、そして何かが通常の範囲から外れた瞬間に、名前のある人間へ上げるエスカレーション。あのノートはアーキテクチャの主張をしています。こちらのノートがあなたに負っているのは、その適用範囲です。ガードレール——特定のツール上の特定の動作を止める、名前のついたルール——は、私のカタログにある 53 のツールのうち 6 つに付いていて、その 6 つはすべて単一のドメインの中にあります。これらのチェックが書き出す監査証跡は、今日のところ、データベースへの書き込みが入るべき場所に TODO の残ったインメモリの記録です。つまり、プロセスが生きているあいだだけ残ります。「Governance you can’t replay is governance you’re taking on faith」（再生できないガバナンスとは、信じるしかないガバナンスのことだ）は、あのノートに書いた私自身の一文です。そこから自分を、こっそり除外するつもりはありません。

それらと並ぶのが、エージェントのサプライチェーンは汚染されているで述べた立場です。私のツールカタログはファーストパーティで、選定されています。開かれたスキルのマーケットプレイスは、誰が何をアップロードしてもそれが流れる配布経路になるからです。そして、機微な動作を認可する資格情報は、盗む価値がないように意図して設計されています。署名され、リクエストに紐づき、セッション単位ではなく秒単位で有効で、発行の対象となったリクエスト以外に対しては無価値です。

ここからが正直な限界です。業界全体がいまいる場所なので、はっきり述べる価値があります。それらの資格情報の主体は、事業者のために動く人間です。その中に、エージェントを名指しするフィールドはありません。ここでエージェントが動いたとき、その動作を運ぶ資格情報は、人がやったと述べます。責任の所在は本物で、連絡のつく誰かに着地します。しかしエージェント自身は、まだ通信路の上での一級の身元ではありません。

その隙間を埋めるのが、パスポートです。身元、評判、検証をひとつの資格情報にまとめたもの。開発者向けページにある Trust API です。近日 私が今日出荷しているのは、束縛と、強制と、責任の所在です。まだ出荷していないのは、資格情報の上に載るエージェント自身の名前——エージェントの識別子の主題です。

これは積み重なるもので、競合ではない

ここまでのどれも、A2A や MCP に反対する議論ではありませんし、私は対抗するプロトコルを提案してもいません。私はこれらの方言を話します。そして、どちらの向きに話しているのかを正確にしておく価値があります。私は MCP のクライアントメタデータを公開し、MCP のクライアントを動かして、サードパーティ提供元のサーバーへ外向きに接続します。私自身のエージェントが、その提供元の公開するツールを使えるようにするためです。トラフィックは、外へ向かいます。ここに、入ってくる側の MCP の面はありません。外部の開発者のエージェントが myOrbit を呼び出すための扉は、ないということです。自分のエージェントを持ち込むで述べたとおり、今日動いている開発者向けの面は知的財産の保護であり、シートとその周りのレールは、まだこれから先です。相互運用性のほうは、私より発言権のある人たちによって、うまく解かれつつあります。

議論しているのは、層のことです。A2A 自身のディスカバリの章は三つの仕組みを挙げていて、二番目がキュレートされたレジストリ——クライアントが問い合わせるカードの集合を保持する仲介者です。この「キュレートされた」という語が、検証されないまま、途方もない量の仕事をしています。信頼が住まなければならないのは、レジストリです。この配置の中で、何かを強制できる立場にいる唯一の当事者だからです。

開かれたレジストリが今日、何を検証しているのかを見てください。MCP の公式のものはまだプレビューで、そこで確認されるのは名前空間の所有権です。あなたが公開した名前に含まれる GitHub アカウントかドメインを、あなたが管理していること。これは持つ価値があります。何かを公開したのが誰かを証明します。そして、その何かが動かして安全かどうかについては、まったく何も語りません。

プロトコルの作者たちは、差込口を残しました。そこに挿さっているものは、ほとんどありません。

プロトコルの上の層は、さらなるプロトコルではありません。入場審査です。主張されるのではなく束縛された身元。範囲が定められ、取り消せる権限。実際に着地する結果。そして、すべての連鎖の末端にいる、責任を負う人間。

ウェブは、エージェントに応答することを学びつつあります。応答するのは、簡単なほうの半分です。難しいほうの半分は、どのエージェントを入れるかを決めることです。

私は、その仕事を引き受けました。