AI Agent に必要なのは、ウォレットだけではない

最近、a16z crypto に掲載された Christian Crowley ら6名の著者による "The missing infrastructure for AI agents: 5 ways blockchains can help"^[1] を読んだ。そこでは、AI Agent のアイデンティティ、ガバナンス、支払い、信頼、ユーザーコントロールが一緒に論じられている。とりわけ、問題を「Agent が支払えるようにする」という一点に縮めてはならない、という考えに強く同意する。

この記事には、とりわけ率直な二つの文があり、それが私がこの記事に応答したい理由でもある。

“The bottleneck for the agent economy is now identity, not intelligence.” （訳：Agent 経済のボトルネックは、いまや知能ではなくアイデンティティである。）

“Scale without verification is a liability that builds over time.” （訳：検証のないスケールは、時間とともに積み上がる負債である。）

私はこの二つの判断におおむね同意する。Agent がチャット画面の中の助手にとどまらず、人や組織を代表してサービスを呼び出し、支払いを行い、成果を届け始めるとき、従来のインターネットには確かに足りない基盤がある。ただ、私はもう一歩手前に焦点を移したい。AI Agent に必要なのは、ウォレットだけではない。

ArcBlock は長く、分散型アイデンティティ、Blockchain、アプリケーション基盤に取り組んできた。

支払いは最も分かりやすい場面だ。Agent が API を呼び出し、データを購入し、サービスの処理を完了し、自動的に支払う。これはもちろん重要である。しかし支払いの前に、システムはさらに基礎的な問いに答えられるべきだ。Agent は誰なのか、誰を代表しているのか、誰が権限を与えたのか、その権限はどこまで及ぶのか、異常が起きた後、何が起きたかを誰が照合できるのか。これらに答えられなければ、ウォレットは単にプログラムに渡された一つの鍵にすぎない。

五つの論点には同意する。ただし、実際には一つの責任の連鎖だ

Crowley ら6名の著者は、アイデンティティ、ガバナンス、機械間支払い、検証可能な信頼、ユーザーコントロールを分けて論じている。それは有用な整理だ。私にとっては、実際に動く Agent システムでは、これらは五つの独立した製品カテゴリーというより、連続した責任の連鎖であることが多い。

まず Agent にはアイデンティティが必要だ。そうでなければ、周囲はそれが誰なのか分からない。アイデンティティがあって初めて、誰がそれを認可できるかを論じられる。認可に範囲があれば、いくら使えるのか、どのサービスを呼び出せるのか、チームを代表して特定の結果を発行できるのかが分かる。操作の後には、記録を検証、照合、追跡できるようになる。最後にようやく、ユーザーは自分が Agent を使っているのか、それとも不透明なプラットフォームに自分を預けているのかを判断できる。

ArcBlock には、この点につながる自然な連続性がある。私たちは長く DID、Decentralized Identifier を採用してきた。これは、あるプラットフォームの一時的なアカウントに依存せず、継続して使え、検証できるアイデンティティ識別子と捉えればよい。重要なのは、すべての対象に暗号学的なラベルを一つ増やすことではない。人、デバイス、そして将来の Agent が、こうしたアイデンティティを持てるようにすることだ。DID Connect はアイデンティティ、ログイン、署名のインタラクションに関する基盤であり、DID Spaces はユーザーのデータ空間だ。どちらも、今日の Agent のために急ごしらえした概念ではない。アイデンティティ、認可、データが、ある一つのプラットフォームや一回のアプリケーションインストールに当然のように従属すべきではない、という問題に取り組んできたものだ。

だから私は、「Blockchain は Agent に支払いをさせられるのか」という問いがあまり好きではない。そこでは、最も見せやすい一歩が、最も難しい一歩であるかのように扱われてしまう。本当に難しいのは、委任だ。

少額のホットウォレットは損失を抑えられるが、認可を説明できない

今日の機械間支払いプロトコル、たとえば x402 は、現実的な問題を一つ解決している。サービス要求と支払いを同じ自動処理フローの中で完了できることだ。少額残高、バーチャルカード、制限付きのウォレットにも価値がある。ここでいうホットウォレットとは、オンラインのプログラムに接続されたウォレットまたはアカウントである。少なくとも、最悪の場合の損失を小さくできる。

だが、それらは自動的には答えてくれない。この Agent はなぜこの支払いを行えるのか。誰から委任されたのか。どのサービスに対して使うことを許されているのか。予算、期間、回数、取り消し条件はどこにあるのか。チームが異常な消費を見つけたとき、どの認可、どの Agent、どの呼び出しに問題があったかを、証拠に沿ってたどれるのか。

これは Agent が登場してから初めて生じた問題ではない。分散型アプリケーションを作っていた頃から、私たちは同じような矛盾に向き合ってきた。自動化された取引のたびに、ユーザーへウォレットを取り出して署名するよう求めることはできない。同時に、ユーザーの主たる秘密鍵をオンラインサービスに長期間置き、プログラムがすべてを勝手に決めるようにすることもできない。前者は自動化できず、後者では意味のあるセキュリティ境界があるとは言いにくい。

そのため私たちが長く考えてきたのは、「どうすればプログラムがユーザーに代わって資金を持てるか」ではない。アイデンティティ、委任の範囲、上限、ルール、責任の連鎖を、どう分けて表現するかだ。DID はアイデンティティと検証関係を提供できる。委任またはケイパビリティモデル、すなわち一つの資格情報で具体的に何ができ、何ができないかを定めるルールは、範囲と制約を定義する。Verifiable Credentials、すなわち VC は、署名付きで独立して検証できる証拠の媒体として使える。こうすれば、Agent が自らの制限付き資格情報を使う必要があるとしても、ユーザーの主たる秘密鍵を常時稼働するオンラインサービスに預けずに済む。

これでリスクが魔法のように消えるとは思わない。問題は単に、「あるプログラムが一つの鍵を持つ」ことから、「誰が、どの条件で、どの制限付きの鍵を渡したのか」へ移るだけだ。後者なら、少なくとも議論、検査、撤回ができる。

台帳の価値は、支払いの後にこそ見え始めることが多い

PaymentKit は、ArcBlock がすでに持つ支払い抽象化レイヤーだ。支払いはもともと新しい問題ではない。Agent によって重要性が増すのは、一回の支払いがさらに多くの問いを引き出すからだ。

一つのチームが複数の AI サービスを同時に使っている場面を想像してみてほしい。異なる Agent が外部ツールを呼び出し、従業員も API key を使い、請求書はまた別のシステムから届く。ある日、金額がおかしいと気づいても、目に入るのは通常、互いに独立したいくつかの記録だけだ。サービス提供者の請求書、クレジットカードの明細、内部ログ。サービス側の課金に問題があったのか、ある key が悪用されたのか、従業員が権限を超えたのか、内部システムが認可を正しく渡さなかったのか。どれが原因なのかを明らかにするのは、しばしば難しい。

だからといって、すべてのログを public chain に書くべきだとは思わない。必要でもなければ、合理的でもない。私たちの考えに近いのは、記録を信頼境界に応じて層に分けることだ。

レシート、請求書、サービス提供、第三者サービスの呼び出し、さらに誰が認可し、誰が使い、どう消費したかといった情報は、VC のような検証可能なデータ形式で表現し、場面に応じた適切な台帳層に保存できる。ここでいう ARC は Agentic Realm Computer の略称であり、ArcBlock が構築している、人と Agent のためのランタイムおよび計算アーキテクチャだ。これは ARC が段階的に担っていくことを私たちが目指す方向であり、完全なチェーン側接続、オンチェーン決済、多層フローが今日すべて提供済みだという意味ではない。

こうした記録も、あるサービスが正しく提供されたことを自動的に証明するわけではないし、人の責任を自動的に肩代わりするわけでもない。その役割はもっと素朴だ。Agent の世界が複雑になり、人が一件ずつ見張れなくなったときに、少なくとも重要な操作には、適切な当事者が検証できる証拠を残すことだ。

チェーンは証拠境界であるべきで、すべての操作の目的地ではない

a16z の記事は、自動化された実行が安くなるにつれて、検証が高くつくようになると述べている。私は同意する。いわゆる human in the loop、つまり人が一件ずつ介入して再確認する方法では、何千もの Agent が行う一つ一つの呼び出しを監査できない。

ただし、ここでの Blockchain の価値を、「信頼を生み出すもの」と言うべきではない。Blockchain は、持続する証拠、共有台帳、実行可能な制約を提供できる。正しさ、サービス品質、紛争処理、最終的な責任は、なおシステム設計と人が担う必要がある。この二つを混同すると、かえって議論を軽くしてしまう。

だから、すべての Agent がオンチェーンになる必要はない。ある Agent がローカルで下書きを整理するだけなら、たいていは最も単純なツールが最良のツールだ。しかし、ユーザーや組織を代表してシステム横断で行動し、資金、権限、検証可能な成果、多者間の照合に関わるなら、アイデンティティ、委任、記録が一社のプラットフォームのバックエンドだけに残されるべきではない。

これが、あの記事から読み取ったうえで、私が付け加えたい一点だ。支払いは入口にすぎない。Agent にとってより根本的な基盤は、検証可能な委任の連鎖である。それによって、私たちははっきり答えられるようになる。誰が行動しているのか、誰が認可したのか、何をできるのか、問題が起きた後にどう照合できるのか。

参考