Host: いまAI業界では、エージェント同士がどう通信し合うかという規格が猛スピードで整いつつあります。でも、決定的な問いが意図的に置き去りにされているんです。

Listener: 置き去り？通信のルールが決まったのなら、あとは自由につなげばいいんじゃないですか？

Host: それが、「どのエージェントを自分のシステムの中に招き入れるべきか」という信頼の判断です。Googleや各社が主導するA2Aや、広く使われているMCPというプロトコルがありますが、どちらの仕様書も「誰を入れるべきか」は語らないと明言しているんですよ。

Listener: えっ、仕様書にそう書いてあるんですか？見落としとかじゃなくて？

Host: 意図的な引き渡しですね。たとえばMCPの仕様書には「認可は任意である」と書かれていて、ツールの振る舞いも「信頼されたサーバーから得たものでない限り、信頼できないものとみなすべき」とあります。つまり「信頼の担保はプロトコルの外で誰かがやってくれ」とボールを投げているわけです。

Listener: なるほど。電話回線は引いたけれど、かかってきた相手が詐欺師かどうかは回線側の仕事じゃない、みたいな話ですね。じゃあ、招き入れる側は何を確かめなきゃいけないんでしょう？

Host: 解くべき問いは四つあります。第一に「これは誰か」。第二に「いま、ここで、この人のために何をしてよいか」。第三に「行儀が悪かったとき、どんな罰則や結果が待っているか」。そして最後に「責任を負う法的な人間は誰か」です。

Listener: 後ろにいくほど重くなりますね。でも最初の「誰か」なんて、通信時のAPIキーや認証で分かるんじゃないですか？

Host: そこが落とし穴で、鍵による認証が証明するのは「前回と同じ相手から通信が来た」ということだけで、その背後にいる主体の正しさや、あなたの口座からお金を使っていい権限までは何も保証してくれないんです。

Listener: 確かに、鍵を持っていることと、信用して仕事を任せられるかは別問題ですね。となると、筆者は自分のシステムでどう対策しているんですか？

Host: ここではエージェントを単なる呼び出し元ではなく、事業者にしっかり「束縛」されたレコードとして扱っています。紐づいていない事業者の代理を名乗っても壁で完全に弾かれます。

Listener: 厳格に身元を固定しているんですね。じゃあ、行儀が悪かったときのガードレールも完璧に動いていると？

Host: ここがこのレポートの誠実なところで、現状の限界も率直に明かされています。たとえば、能力の食い違いを完全に拒否するコードはあるものの本番ではオフのフラグの後ろにあったり、ガードレールが付いているのも五十三のツールのうち特定の六つだけなんです。

Listener: 業界の最前線でも、そこまで完全に固め切るのは難しい段階なんですね。

Host: そうなんです。監査ログもまだインメモリだったり、資格情報も「エージェント自身」ではなく背後にいる「人間」の名前で発行されていたりします。だからこそ、身元と評判と検証をセットにした「エージェントのパスポート」のような仕組みが次に必要になってくるわけです。

Listener: プロトコルに文句を言っているわけではなくて、その上に乗る「入場審査」の仕組みを本気で作ろうとしているんだ。

Host: その通りです。エージェントに応答する技術はできました。でも本当に難しいのは、誰を招き入れるかを決めること。詳しいコードの現状や仕様の引用は、ぜひ元のレポートを読んでみてください。