なぜAIエージェントがブロックチェーン上での実装において多くの障壁に直面しているのか？
TechFlow厳選深潮セレクト
なぜAIエージェントがブロックチェーン上での実装において多くの障壁に直面しているのか？
ブロックチェーンは機械のために構築されたが、エージェント向けには設計されていない。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Zack Pokorny
翻訳編集：Chopper、Foresight News
AIエージェントのブロックチェーン上での実装は順調とはほど遠く、ブロックチェーンは確かにプログラマブルでパーミッションレスな特性を持つものの、エージェントに適した意味論的抽象化および協調レイヤーを欠いている。暗号資産研究機関Galaxyが発表したレポートによると、エージェントはチェーン上で「機会の発見」「信頼性の検証」「データの読み取り」「実行フロー」の4つの構造的摩擦に直面しており、現行のインフラストラクチャは依然として人間とのインタラクションを前提に設計されており、AIによる資産の自律的管理や戦略実行を支えるには不十分である。これらが、AIエージェントのブロックチェーン上でのスケーラブルな実装における核心的ボトルネックとなっている。以下は当該レポートの全文翻訳である。
AIエージェントの応用シナリオと能力はすでに進化を始めている。エージェントはタスクを自律的に実行し始め、資本の保有・配分、取引および収益戦略の発掘といった用途にも開発されている。この実験的な転換はまだ極めて初期段階ではあるが、従来のエージェントが主にソーシャルおよび分析ツールとして機能していたという発展パターンとは明確に異なる。
ブロックチェーンは、こうした進化の自然な実験場となっている。ブロックチェーンはパーミッションレスであり、相互運用可能（コンポーザブル）で、オープンソースのアプリケーションエコシステムを持ち、すべての参加者に対しデータを平等に公開している。さらに、チェーン上のすべての資産はデフォルトでプログラマブルである。
これにより、一つの構造的課題が浮かび上がる。「もしブロックチェーンがプログラマブルかつパーミッションレスであるならば、なぜ自律的エージェントは依然として摩擦を抱えるのか？」その答えは、「実行が可能かどうか」ではなく、「実行の上位層において、どれだけの意味論的負荷および調整負荷が存在するか」にある。ブロックチェーンは状態遷移の正しさを保証するが、経済的解釈、規範的なアイデンティティ、あるいは目的レベルの調整といったプロトコルネイティブな抽象化は通常提供しない。
一部の摩擦は、パーミッションレスシステム固有のアーキテクチャ的欠陥に起因し、他の一部は、現在のツール、コンテンツ管理、および市場インフラストラクチャの現状を反映している。実際、多くの上位機能は依然としてソフトウェアおよびワークフローに依存しており、それらの構築には人手による操作が不可欠である。
ブロックチェーンアーキテクチャとAIエージェント
ブロックチェーンの設計は合意形成および決定論的実行を中心に据えられており、意味論的解釈には焦点を当てていない。それは、ストレージスロット、イベントログ、呼び出しトレースといった低レベルのプリミティブを外部に公開するが、標準化された経済的オブジェクトは公開しない。したがって、「ポジション」「収益率」「健全性係数」「流動性の深さ」などの抽象的概念は、通常、インデクサーやデータ分析レイヤー、フロントエンドインターフェース、APIなどによってオフチェーンで再構成され、各プロトコル固有の状態をより使いやすい形式へと変換される。
主流の分散型金融（DeFi）業務プロセス、特に小口投資家向けおよび主観的判断を要するプロセスの多くは、依然としてユーザーがフロントエンドインターフェースで操作を選択し、単一のトランザクションに署名するというモデルに基づいている。このユーザーインターフェース中心のモデルは、小口投資家の普及とともに拡大してきたが、チェーン上の活動の相当部分が既に機械によって駆動されているにもかかわらず、現在の主流の小口投資家向けインタラクション・モデルは依然として「意図 → ユーザーインターフェース → トランザクション → 確認」である。プログラムによる操作は別のパスを辿るが、これにも独自の制約がある：開発者は構築段階で契約および資産セットを事前に選定し、その後、この固定範囲内でアルゴリズムを実行する。この二つのモデルはいずれも、実行時に変化する目標に応じて、動的に機会を発見・評価・組み合わせる必要があるシステムには対応できない。
取引検証に最適化されたインフラストラクチャが、経済状態の解釈、信用評価、明確な目的に基づく行動最適化を同時に要求するシステムで使用されるとき、摩擦が生じ始める。このギャップの一部は、ブロックチェーンのパーミッションレスかつ異種混在（ヘテロジニアス）な設計特性に由来し、他方は、インタラクションツールが依然として人間による審査およびフロントエンド仲介を前提として構築されていることに起因する。
エージェントの行動フローと従来のアルゴリズム戦略の比較
ブロックチェーンインフラストラクチャとエージェントシステムの間に存在するギャップについて考察する前に、まず「より知的で自律的な行動フロー」と「従来のチェーン上アルゴリズムシステム」の違いを明確にする必要がある。
両者の差異は、自動化の程度、複雑さ、パラメータ設定、さらには動的適応能力にもない。従来のアルゴリズムシステムは高度にパラメータ化され、新規デプロイされたコントラクトやトークンを自動的に発見し、複数の戦略タイプ間で資金を割り当て、パフォーマンスに応じて再バランスを行うことができる。真の違いは、システムが構築段階で予見されていなかった状況に対処できるかどうかにある。
従来のアルゴリズムシステムは、いかに複雑であっても、あらかじめ定義されたパターンに対してのみ、あらかじめ定義されたロジックを実行する。それらは、各プロトコルごとに事前に定義されたインターフェースパーサー、コントラクト状態を経済的意味にマッピングするための事前定義された評価ロジック、明確な信用および標準性の判断規則、そして各意思決定ブランチのためのハードコードされたルールを必要とする。予め定義されたパターンに適合しない状況が発生した場合、システムはそれをスキップするか、または単に失敗する。それは未知の状況に対して推論することはできず、現在の状況が既知のテンプレートに適合するかどうかだけを判定できる。
この「消化ダック」の機械式自動装置は生物的動作を模倣できるが、すべての動作は事前にプログラムされている
DeFiの貸付市場をスキャンする従来のアルゴリズムは、馴染みのあるイベントを発行したり、既知のファクトリーパターンに一致する新規デプロイされたコントラクトを識別できる。しかし、インターフェースが未知の新しい貸付基盤コンポーネントが登場した場合、システムはそれを評価できない。人間がコントラクトを検査し、その動作メカニズムを理解し、それが掘るべき機会であるかどうかを判断し、統合ロジックを記述しなければならない。その後、アルゴリズムは初めてそのコントラクトと対話できるようになる。つまり、人間が解釈し、アルゴリズムが実行する。基礎モデルに基づくエージェントシステムは、この境界を変える。それらは習得された推論能力を通じて以下を実現できる：
- 曖昧または不完全に表現された目標の解釈。例えば「過度なリスクを回避しつつ収益を最大化する」という指示は、意味論的解釈を必要とする。「過度なリスク」とは何か？収益とリスクはどのようにトレードオフすべきか？従来のアルゴリズムでは、これらの条件を事前に厳密に定義する必要があるが、エージェントは意図を解釈し、判断を行い、フィードバックに基づいて自身の理解を最適化できる。
- 未知のインターフェースへの汎化適応。エージェントは未知のコントラクトコードを読むこと、ドキュメントを解析すること、あるいは一度も接触したことのないアプリケーションバイナリインターフェース（ABI）を調べることで、そのシステムの経済的機能を推論できる。各プロトコルごとに事前にパーサーを構築する必要はない。現時点ではこの能力はまだ完璧ではないため、エージェントが目にする内容を誤認することもあるが、それでも構築段階で予見されていなかったシステムと対話しようと試みることができる。
- 信頼性および規範性に不確実性が存在する状況下での推論。信用信号が曖昧または不完全な場合、基礎モデルは二値ルールを単純に適用するのではなく、信号を確率的に評価できる。このスマートコントラクトは標準的か？既存の証拠から判断して、このトークンは合法か？従来のアルゴリズムは、ルールがあれば対応でき、なければ対応できない。一方、エージェントは信頼度を推論できる。
- エラーの説明と調整。予期せぬ事象が発生した場合、エージェントは問題の根本原因を推論し、対応方法を決定できる。対照的に、従来のアルゴリズムは例外キャッチモジュールを実行するだけであり、例外情報を転送するだけで、解釈は行わない。
これらの能力は現在、実在するがまだ完璧ではない。基礎モデルはハルシネーション（幻覚）を起こし、内容を誤認し、断定的に見える誤った判断を下すこともある。また、対抗的かつ資本を伴う環境（つまりコードが資産を制御または受領可能である環境）において、「予見されていないシステムと対話しようとする」ことは、資金の損失を意味する可能性がある。本稿の中心的主張は、エージェントが既にこれらの機能を信頼性高く実行できるということではなく、従来のシステムが全く実現できない方法でこれらに挑戦できるということ、そして将来的なインフラストラクチャによって、こうした挑戦がより安全かつ信頼性高くできるようになるということである。
この違いは、絶対的な分類の境界ではなく、むしろ連続体として捉えるべきである。一部の従来システムは学習された推論の形を取り入れており、一部のエージェントはキーパスにおいてハードコードされたルールに依存することもある。この違いは方向性のものであり、絶対的な二元論ではない。エージェントシステムは、構築段階での事前定義ルールではなく、実行時における推論に、より多くの解釈・評価・適応作業を委ねる。これは摩擦に関する議論にとって極めて重要である。なぜなら、エージェントシステムが試みようとしているのは、従来のアルゴリズムが完全に回避してきたことだからである。従来のアルゴリズムは、構築段階で人間がコントラクト集合を精査することで、発見における摩擦を回避する；運営者が維持するホワイトリストを用いることで、制御層の摩擦を回避する；既知のプロトコルのために事前に構築されたパーサーを使用することで、データの摩擦を回避する；事前に定義されたセキュリティ境界内で実行することで、実行の摩擦を回避する。人間が事前に意味論的・信用的・戦略的な作業を完了し、アルゴリズムはその範囲内で実行する。初期のチェーン上エージェントの行動フローは、このパターンを踏襲するかもしれないが、エージェントの本質的価値は、発見・信用・戦略評価を構築段階の事前定義から実行時の推論へと移すことにある。
エージェントは、未知の機会を発見・評価し、ハードコードされたルールなしに標準性を推論し、事前定義されたパーサーなしに異種の状態を解釈し、曖昧な可能性のある目標に対して戦略的制約を実行しようとする。摩擦が存在するのは、エージェントがアルゴリズムと同じことをより困難にやっているからではなく、まったく異なることを試みているからである：即ち、閉じた・事前統合された体系ではなく、開放的・動的解釈可能な行動空間の中で動作することである。
摩擦
構造的視点から見れば、この矛盾はブロックチェーンの合意形成の欠陥に起因するものではなく、むしろその周辺で発展してきた全体的なインタラクションスタックの動作方式に起因する。
ブロックチェーンは、決定論的な状態遷移、最終状態に対する合意、および最終確定性を保証する。しかし、プロトコル層で経済的意味の解釈、意図の検証、または目的の追跡をエンコードしようとはしない。これらの責務は、これまで常にフロントエンドインターフェース、ウォレット、インデクサー、およびその他のオフチェーン協調レイヤーが担ってきたが、そこには常に人間の介入が必要であった。
熟練した参加者であっても、現在の主流インタラクション・モデルはこの設計を如実に示している。小口投資家はダッシュボードで状態を解釈し、ユーザーインターフェースで操作を選択し、ウォレットでトランザクションに署名し、結果を非公式に検証する。アルゴリズム取引機関は実行の自動化を達成しているが、それでも人間のオペレーターがプロトコル集合を精査し、異常を確認し、インターフェースの変更時に統合ロジックを更新する必要がある。いずれの場合でも、プロトコルは実行の正確性を保証するだけであり、意図の解釈、異常処理、および新規機会への適応はすべて人間が行う。
エージェントシステムは、この分業を圧縮、あるいは排除する。それらは、経済的意義を持つ状態をプログラム的に再構築し、目的の達成状況を評価し、実行結果を検証する必要があり、単にトランザクションがチェーン上に記録されたことを確認するだけでは不十分である。ブロックチェーン上では、これらの負担が特に顕著である。なぜなら、エージェントは、開放的・対抗的・急速に変化する環境で動作し、新規コントラクト・資産・実行パスが、中央集権的な審査なしに出現する可能性があるからである。プロトコルはトランザクションの正しい実行を保証するが、経済的状態が容易に解釈可能であること、コントラクトが標準的であること、実行パスがユーザーの意図に沿っていること、あるいは関連する機会がプログラム的に発見可能であることは保証しない。
以下では、エージェントの実行ループの各段階に沿って、このような摩擦を逐一整理していく：既存のコントラクトおよび機会の発見、それらの合法性の検証、経済的意義を持つ状態の取得、および目的に沿った操作の実行である。
発見における摩擦
摩擦が生じるのは、パーミッションレスな環境において、分散型金融の行動空間が開放的に拡大している一方で、関連性および合法性は、ソーシャル・市場・ツール層を通じて人間によってフィルタリングされるからである。新規プロトコルはアナウンスによって出現し、同時にフロントエンドへの統合、トークンリストへの追加、データ分析プラットフォーム、流動性形成といったフィルタリング層を通過する。長期間にわたり、こうしたシグナルはしばしば、行動空間のどの部分が経済的価値を持ち、十分に信頼できるかを区別するための実用的な判断基準を形成する。ただし、こうした合意は非公式・不均等なものであり、一部は第三者および人間によるフィルタリングに依存している。
エージェントにフィルタリング済みのデータおよび信用シグナルを提供することは可能だが、それらを人間が解釈する際に用いる直感的なショートカットを、エージェント自体が備えてはいない。チェーン上の視点から見れば、すべてのデプロイ済みコントラクトは同等の発見可能性を持つ。正当なプロトコル、悪意あるフォーク、テストデプロイ、廃止されたプロジェクトは、すべて呼び出し可能なバイトコードの形で存在する。ブロックチェーン自体は、どのコントラクトが重要で、どのコントラクトが安全かをエンコードしない。
したがって、エージェントは自らの発見メカニズムを構築しなければならない：デプロイイベントをスキャンし、インターフェースパターンを識別し、ファクトリーコントラクト（他のコントラクトをプログラム的にデプロイできるコントラクト）を追跡し、流動性形成を監視して、どのコントラクトを意思決定範囲に含めるべきかを特定する。このプロセスは単なるコントラクトの探索ではなく、むしろそのコントラクトをエージェントの行動空間に含めるべきかどうかの判断である。
候補を特定することは第一歩にすぎない。コントラクトが初期の発見フィルターを通過した後、次のセクションで述べる標準性および真正性の検証プロセスを経る必要がある。エージェントは、発見したコントラクトが本当にその名にふさわしいことを確認した上で、意思決定空間に含める必要がある。
発見における摩擦は、新規デプロイ行為を検出することを意味しない。成熟したアルゴリズムシステムは、自らの戦略範囲内で既にこれを実現している。Uniswapのファクトリーイベントを監視し、新規プールを自動的に検索対象に含める検索者は、まさに動的発見を実行している。摩擦は、より高い二つのレベルで発生する：発見されたコントラクトが合法であるかどうかの判断、およびそれがオープンな目的と関連しているかどうかの判断（単に事前定義された戦略タイプに一致するかどうかだけではない）。
検索者の発見ロジックは、その戦略と密接に結びついている。戦略が定義されているため、どのようなインターフェースパターンを探すべきかを知っている。一方、「リスク調整後の最適機会を構成する」といったより広範な命令を実行するエージェントは、戦略から派生するフィルターのみに依存することはできない。新たな機会を、目標自体と照らし合わせて評価する必要があり、そのためには未知のインターフェースを解析し、経済的機能を推論し、その機会を意思決定空間に含めるべきかどうかを判断しなければならない。これはある程度、汎用的自律性の問題ではあるが、ブロックチェーンはこの問題をさらに深刻化させる。
制御層における摩擦
制御層における摩擦は、アイデンティティおよび合法性の判断が、通常プロトコルの外で行われ、フィルタリング・ガバナンス・ドキュメンテーション・インターフェース・オペレーターの判断を総合的に用いて行われるからである。現在の多くのワークフローでは、人間が判断の重要な役割を果たしている。ブロックチェーンは決定論的実行および最終確定性を保証するが、呼び出し元が目的のコントラクトと対話していることを保証しない。この意図の判断は、ソーシャルコンテキスト、ウェブサイト、および人間によるフィルタリングに外部化されている。
現在のプロセスでは、人間はウェブの信用レイヤーを非公式な検証手段として利用する。彼らは公式ドメイン（通常はDeFiLlamaなどの集約プラットフォームやプロジェクトの認証済みソーシャルアカウントを通じて見つける）にアクセスし、そのウェブサイトを人間の概念とコントラクトアドレスとの間の標準的なマッピング媒体とみなす。その後、フロントエンドインターフェースは、どのアドレスが公式アドレスであるか、どのトークン識別子を使用すべきか、どのエントリポイントが安全であるかを明示する、実用的な信頼基準を形成する。
1789年に登場した「メカニカル・テュルク」はチェスを打つ機械であり、表面上は自律的に動作しているように見えたが、実際には隠された人間のオペレーターに依存していた
エージェントは、デフォルトでソーシャルコンテキストからブランド識別子、認証済みソーシャルシグナル、あるいは「公式性」を解釈できない。こうしたシグナルから抽出されたフィルタリング済みデータをエージェントに与えることは可能だが、それを永続的に利用可能な機械信用仮説に変換するには、明確なレジストリ、ポリシー、または検証ロジックが必要となる。エージェントには、オペレーターが提供するフィルタリング済みホワイトリスト、認証済みアドレス、信用ポリシーを設定できる。問題は、ソーシャルコンテキストへのアクセスが完全に不可能というわけではないが、動的に拡大する行動空間において、こうした防護策を維持する運用コストが非常に高く、また、こうした措置が欠落または不完全な場合、エージェントには人間がデフォルトで使用する代替検証メカニズムがないということである。
チェーン上エージェント駆動システムでは、信用判定の薄弱さが実際に引き起こした結果が既に見られている。著名な暗号資産ブロガーOrangieのケースでは、エージェントがハニーポットコントラクトに資金を預けたと報告されている。別の事例では、Lobstar Wildeという名のエージェントが状態またはコンテキストの障害によりアドレスの状態を誤認し、大量のトークン残高をオンラインの「物乞い」に送金してしまった。これらの事例は本稿の主論拠ではないが、信用判定、状態解釈、実行戦略の失敗が、直接的に資金損失を招き得ることを示すのに十分である。
問題は、コントラクトが発見しにくいことではなく、ブロックチェーンには「これは○○アプリケーションの公式コントラクトである」というネイティブな概念が通常存在しないことにある。この欠如は、一定程度、パーミッションレスシステムの特性であり、設計上の疎漏ではなく、それでも自律システムにとっては協調の難問を引き起こす。この問題の一部は、標準的なアイデンティティ識別が脆弱なオープンシステムアーキテクチャに由来し、他はレジストリ・標準・信用配布メカニズムが未熟なことに起因する。Aave v3と対話しようとするエージェントは、どのアドレスが標準アドレスであるかを判断しなければならず、さらに、それらのアドレスが変更不能であるか、プロキシによるアップグレードが可能か、あるいは現在ガバナンス変更の待機中であるかを判断する必要がある。
人間はドキュメンテーション、フロントエンドインターフェース、ソーシャルメディアによってこの問題を解決する。エージェントは以下の項目を確認することで判断しなければならない：
- プロキシモードおよび実装の要点
- 管理権限およびタイムロック
- ガバナンス制御のパラメータ更新モジュール
- 既知のデプロイ間でのバイトコード／アプリケーションバイナリインターフェース（ABI）の一致
標準レジストリが欠如している場合、「公式性」は推論の問題となる。これは、エージェントがコントラクトアドレスを静的な設定とみなせないことを意味する。エージェントは、継続的な検証を伴うフィルタリング済みホワイトリストを維持するか、実行時にプロキシチェックおよびガバナンス監視を通じて標準性を再推論するか、あるいは廃棄・損傷・偽造されたコントラクトと対話するリスクを負うかのいずれかである。従来のソフトウェアおよび市場インフラストラクチャでは、サービスのアイデンティティは、機関が維持する名前空間、証明書、アクセス制御によって固定される。対照的に、チェーン上では、コントラクトは呼び出し可能であり、正常に動作するが、呼び出し側の視点からは、経済的・ビジネス的観点で標準性を備えていない可能性がある。
トークンの真正性およびメタデータは、同じ問題である。トークンは自己記述的であるように見える。しかし、トークンのメタデータには権威性がなく、単にコードが返すバイトデータにすぎない。典型的な例がラップド・イーサ（WETH）である。広く使われているWETHコントラクトのコードには、名称、シンボル、精度が明確に定義されている。
これはアイデンティティ識別のように見えるが、実際にはそうではない。任意のコントラクトは以下を設定できる：
- symbol() = WETH
- decimals() = 18
- name() = Wrapped Ether
そして、同一のERC-20トークン標準インターフェースを実装できる。name()、symbol()、decimals()は単なる公開の読み取り専用関数であり、デプロイ者が任意に設定した内容を返す。実際、イーサリアム上には、名称が「Wrapped Ether」、シンボルが「WETH」、精度が18桁であるトークンが約200種類存在する。CoinGeckoやEtherscanを参照せずに、どの「WETH」が標準版かを判別できるだろうか？
エージェントが直面しているのはまさにこの状況である。ブロックチェーンは一意性を検証せず、いかなるレジストリとも照合せず、制限も設けない。今日、あなたは500個のコントラクトをデプロイし、すべてが完全に同一のメタデータを返すことも可能である。チェーン上には、いくつかの試行的な判定方法（例：イーサリアム残高と総供給量の一致を確認、主要な分散型取引所の流動性深度を照会、貸付プロトコルの担保として採用されているかを検証）が存在するが、いずれも絶対的な証明を提供できない。それぞれの方法は、閾値の仮定に依存するか、あるいは他のコントラクトの標準性検証に再帰的に依存する。
迷路の中から「真の」道を見つけるには外部からのガイドが必要であるように、チェーン上にはネイティブな標準シグナルは存在しない
これが、トークンリストおよびレジストリがオフチェーンフィルタリングレイヤーとして存在する理由である。それらは、「WETH」という概念を具体的なアドレスにマッピングする手段を提供し、ウォレットおよびフロントエンドインターフェースがホワイトリストを維持したり、信頼できる集約プラットフォームに依存したりする理由でもある。エージェントにとって、核心的な問題は単にメタデータの信頼性が低いということではなく、標準的なアイデンティティが、プロトコルネイティブではなく、むしろソーシャルまたは機関レベルで確立されるということである。信頼できるチェーン上識別子はコントラクトアドレスであるが、人間の意図である「USDCに交換する」という行為を正しいアドレスにマッピングすることは、依然としてプロトコルネイティブでないフィルタリング、レジストリ、ホワイトリスト、あるいはその他の信用レイヤーに強く依存している。
データにおける摩擦
分散型金融のさまざまなプロトコル間で最適な資本配分を行うエージェントは、各機会を標準化された経済的オブジェクトに変換する必要がある：収益率、流動性の深さ、リスクパラメータ、料金構造、オラクルのソースなど。ある意味では、これは一般的なシステム統合の問題である。しかし、ブロックチェーン上では、プロトコルの異種混在性、直接的な資本への曝露、複数の呼び出しによる状態の結合、および経済モデルの統一が欠如していることが、この負担をさらに増大させる。これらは、機会の比較、配分のシミュレーション、リスクの監視に必要な基本要素である。
ブロックチェーンは、通常、プロトコル層で標準化された経済的オブジェクトを公開しない。代わりに、ストレージスロット、イベントログ、関数出力を公開し、経済的オブジェクトはそこから推論または再構成される必要がある。プロトコルは、コントラクト呼び出しが正しい状態値を返すことを保証するが、その値が明確に読み取り可能な経済的概念にマッピングされること、あるいはクロスプロトコルで一貫したインターフェースを介して同じ経済的概念を取得できることまでは保証しない。
したがって、「市場」「ポジション」「健全性係数」などの抽象概念はプロトコルのプリミティブではない。それらは、インデクサーやデータ分析プラットフォーム、フロントエンドインターフェース、APIなどによってオフチェーンで再構成され、異種のプロトコル状態を実用的な抽象化へと変換される。人間のユーザーは通常、この標準化されたレイヤーしか見ていない。エージェントもこのレイヤーを使用できるが、その場合、サードパーティのモデル、遅延、信用仮定を継承することになる。そうでなければ、自らこれらの抽象化を再構成する必要がある。
この問題は、さまざまなプロトコルでますます顕著になっている。金庫のシェア価格、貸付市場の担保比率、分散型取引所（DEX）プールの流動性の深さ、ステーキングコントラクトの報酬率などは、経済的意義を持つ基本的な構成要素であるが、いずれも標準化されたインターフェースで公開されていない。各プロトコルには、取得方法、構造、単位慣例がそれぞれ異なる。同一カテゴリ内であっても、実装方法には差異がある。
貸付市場：断片化された取得の典型例
貸付市場はこの問題を明瞭に示している。その経済的概念は普遍的かつほぼ統一されており、例えば流動性の供給・借入、金利、担保比率、限度額、清算しきい値などであるが、取得パスはそれぞれ異なる。
Aave v3では、市場の列挙と準備資産の状態取得は二つの独立したステップである。典型的なフローは以下の通りである：
以下の方法で準備資産を列挙し、トークンアドレスの配列を返す。
各資産について、別のコード断片を用いて流動性および金利の基礎データを取得する。
このメソッドは、一回の呼び出しで流動性総量、金利指数、構成フラグなどを含む構造体を返す。例：
一方、Compound v3では、各デプロイは単一の市場（USDC、USDT、ETHなど）に対応し、統一された準備資産構造体は存在しない。代わりに、市場のスナップショットを複数の関数呼び出しで結合する必要がある：
- 基本利用率
- 総量
- 金利
- 担保資産の構成
- グローバル構成パラメータ
各呼び出しは、経済的状態の異なるサブセットのみを返す。「市場」は一次オブジェクトではなく、呼び出し側が結合して推論する構造である。
エージェントの視点から見れば、両プロトコルは貸付市場であるが、統合の視点からは、構造がまったく異なる取得システムである。統一された共有パターンは存在しない。代わりに、エージェントは異なるプロトコルに対して異なる資産列挙方法を採用し、複数の呼び出しで状態を結合しなければならない。
断片化がもたらす遅延および一貫性リスク
構造の不一致に加えて、この断片化は遅延および一貫性リスクをもたらす。経済的状態が単一の原子的市場オブジェクトとして公開されていないため、エージェントは複数のコントラクトを横断してスナップショットを再構成するために、複数のリモートプロシージャコール（RPC）を実行しなければならない。呼び出しの回数が増えるほど、遅延、レート制限リスク、ブロック不整合の確率が高まる。変動性の高い環境では、供給金利の計算が完了した時点で、金利はすでに変化している可能性がある。ブロックを明示的にロックしない限り、構成パラメータは流動性総量と異なるブロック高に対応している可能性がある。ユーザーはUIキャッシュ層および集約バックエンドに依存して、これらの問題を間接的に緩和している。生のRPCインターフェースを直接操作するエージェントは、同期、バッチ処理、時間的一貫性を明示的に管理しなければならない。したがって、非標準化された取得は、単に統合の不便さを招くだけでなく、パフォーマンス、同期、正確性を制限する。
標準化された経済データ取得スキームが欠如しているため、プロトコルがほとんど同一の金融プリミティブを実装していても、その状態の公開は、コントラクトの具体的な状況および構成に依存する。この構造的差異が、データにおける摩擦の核心的構成要素である。
潜在的なデータフローの不一致
ブロックチェーン上の経済的状態へのアクセスは、本質的にプル（取得）モードであり、実行シグナルがストリーミング可能であっても同様である。外部システムはノードに必要な状態を問い合わせるが、継続的かつ構造化された更新を受信するわけではない。このモードは、ブロックチェーンのコア機能——必要に応じた検証——を反映しており、アプリケーションレベルの継続的な状態ビューの維持ではない。
プッシュ（通知）型プリミティブは存在する。WebSocketサブスクリプションにより、新規ブロックおよびイベントログをリアルタイムでストリーミングできるが、これらは大部分の経済的意味を担うストレージ状態を含まない（プロトコルが明示的に冗長な公開を選択しない限り）。エージェントは、貸付市場の利用率、プールの準備資産、ポジションの健全性係数を、チェーン上から直接サブスクライブすることはできない。これらの数値はコントラクトのストレージに保存されており、ほとんどのプロトコルは、ダウンストリームの利用者にこれらの情報をプッシュするネイティブなメカニズムを提供していない。現在の最良の手法は、新規ブロックヘッダーをサブスクライブし、各ブロックごとに再クエリすることである。ログは状態が変化した可能性を示すだけであり、最終的な経済的状態を符号化しない。その状態を再構成するには、依然として明示的な読み取りおよび履歴状態へのアクセスが必要である。
エージェントシステムは、逆向きのフローから恩恵を受ける可能性がある。エージェントは数百のコントラクトの状態変化をポーリングするのではなく、構造化され、事前計算された状態更新を直接実行環境にプッシュされるように受け取ることができる。プッシュ型アーキテクチャは、冗長なクエリを削減し、状態変化とエージェントの認識との間の遅延を低下させ、中間層が状態を意味論的に明確な更新としてパッケージ化することを可能にする。これにより、エージェントが原始的なストレージから意味を解釈する必要がなくなる。
この逆転は容易ではない。サブスクリプションインフラストラクチャ、関連性のフィルタリングロジック、およびストレージの変更をエージェントが実行可能な経済的イベントへと変換するパターンを必要とする。しかし、エージェントが断続的なクエリ者ではなく、継続的な参加者となるにつれて、プルモードの非効率性のコストはますます高くなる。エージェントを継続的な消費者（断続的なクライアントではなく）として扱うインフラストラクチャは、自律システムの動作スタイルにより適合するかもしれない。
プッシュ型インフラストラクチャが本当に優れているかどうかは、依然として未解決の問題である。膨大な状態変化はフィルタリングの難しさを引き起こし、エージェントは依然としてどの変化が関連するかを判断する必要があるため、別のレイヤーでプル型の意味論が再導入される。問題の核心は、プル型アーキテクチャ自体に問題があるのではなく、現在のアーキテクチャ設計が持続的なマシン消費者を考慮していないことにあり、エージェントの使用規模が拡大するにつれて、他の代替モデルの探求が価値あるものとなるかもしれない。
実行における摩擦
実行における摩擦は、現在の多くのインタラクションレイヤーが、意図の変換、トランザクションの審査、結果の検証を、フロントエンドインターフェース、ウォレット、オペレーター監視を前提としたワークフローにパッケージ化していることに起因する。小口投資家および主観的判断を要するシナリオでは、この監視は通常人間が行う。自律システムにとっては、これらの機能を形式化し、直接コード化する必要がある。ブロックチェーンはコントラクトのロジックに基づいて決定論的実行を保証するが、トランザクションがユーザーの意図に合致していること、リスク制約を遵守していること、あるいは期待される経済的結果を達成していることまでは保証しない。現在のプロセスでは、ユーザーインターフェースおよび人間がこのギャップを埋めている。
ユーザーインターフェースは操作シーケンス（交換、承認、預入、貸付）を組み合わせ、ウォレットは最終的な「確認して送信」ノードを提供し、ユーザーまたはオペレーターは最終ステップで非公式に戦略的判断を行う。彼らは通常、情報が不完全な状況で、トランザクションが安全であるかどうか、提示された価格結果が許容可能かどうかを判断する。トランザクションが失敗したり、予期せぬ結果が生じたりした場合、ユーザーは再試行したり、スリッページを調整したり、パスを変更したり、あるいは操作を放棄したりする。エージェントシステムは、人間をこの実行ループから除外する。これは、システムが以下の三つの人間の機能を機械ネイティブな方法で代替しなければならないことを意味する：
- 意図の統合。「私の安定コインをリスク調整後の最適収益場所に移す」という人間の目標は、具体的な行動計画に統合されなければならない：どのプロトコル、どの市場、どのトークンパス、どの規模、どの承認、および実行順序を選ぶか。人間にとっては、このプロセスはユーザーインターフェースによって暗黙的に完了されるが、エージェントにとっては形式化して実現する必要がある。
- 戦略の実行。「トランザクションを送信する」ボタンをクリックすることは、単なる署名ではなく、スリッページ許容度、レバレッジ上限、最低健全性係数、ホワイトリストコントラクト、あるいは「アップグレード可能なコントラクトを禁止」などの制約を満たしているかどうかを暗黙的にチェックすることでもある。エージェントは、明確な戦略制約を機械が検証可能なルールとしてコード化する必要がある：
- 実行システムは、提案された呼び出しグラフがこれらのルールを満たすことを検証した上で、トランザクションをブロードキャストしなければならない。
- 結果の検証。トランザクションがチェーン上に記録されたからといって、タスクが完了したわけではない。トランザクションの実行が成功しても、目標が達成されていない可能性がある：スリッページが許容範囲を超えていたり、限度額の制約により目標ポジション規模に到達できなかったり、シミュレーションとチェーン上記録の間に金利が変化していたりする。人間は、事後にユーザーインターフェースを確認して非公式に検証する。エージェントは、事後条件をプログラム的に評価しなければならない。
これは、単なるトランザクションの包含ではなく、完了チェックの要請を導入する。意図中心のアーキテクチャは、「どうやって」実行するかという負担の多くをエージェントから専門のソルバーに移転することで、この問題の一部を解決できる。生の呼び出しデータではなく、署名済みの意図をブロードキャストすることで、エージェントは結果に基づく制約を指定でき、ソルバーやプロトコルレベルのメカニズムは、実行を許容するためにこれらの制約を満たさなければならない。
マルチステップのワークフローと障害モード
分散型金融の大部分の実行操作は本質的にマルチステップである。収益の最適化には、承認 → 交換 → 預入 → 貸付 → ステーキングの流れが必要となることがある。一部のステップは独立したトランザクションであり、他のステップはマルチコールまたはルーティングコントラクトによってパッケージ化される可能性がある。人間は部分的な完了を許容し、ユーザーインターフェースに戻ってプロセスを継続できる。エージェントは決定論的なフロー編成を必要とする：任意のステップが失敗した場合、エージェントは再試行、再ルーティング、ロールバック、または一時停止のいずれかを決定しなければならない。
これは、人間のプロセスではほとんど隠蔽されていた新たな障害モードを生み出す：
- 意思決定とチェーン上記録の間の状態ドリフト。シミュレーションと実行の間に、金利、利用率、流動性が変化する可能性がある。人間はこの可変性を受け入れるが、エージェントは許容範囲を設定し、強制的に適用しなければならない。
- 非アトミックな実行および部分的執行。一部の操作は複数のトランザクションにまたがって実行されたり、部分的な結果を生んだりすることがある。エージェントは中間状態を追跡し、最終状態が目標に合致することを確認しなければならない。
- 承認額および承認リスク。人間はユーザーインターフェースを通じて無意識に承認に署名するが、エージェントは承認範囲（額、使用者、期間）を、単なるユーザーインターフェースのステップではなく、セキュリティポリシーの一部として推論しなければならない。
- パス選択および隠れた実行コスト。人間はルーティングコントラクトおよびユーザーインターフェースのデフォルト設定に依存するが、エージェントはスリッページ、最大抽出可能価値（MEV）リスク、ガスコスト、価格影響を目的関数に組み込む必要がある。
実行：機械ネイティブな制御問題
実行における摩擦の核心的主張は、分散型金融のインタラクションレイヤーが、人間のウォレット署名を最終的な制御平面として設計されているという点にある。この段階は、現在の意図検証、リスク許容、および非公式な「妥当か否か」の判断を担っている。人間を除外すると、実行は制御問題となる：エージェントは目標を行動パターンに変換し、戦略制約を自動的に実行し、不確実性の下で結果を検証しなければならない。この課題は多くの自律システムに共通するが、ブロックチェーン環境は特に厳しい：実行は直接資本に関係し、未知のコントラクトと相互運用可能であり、対抗的な状態変化にさらされている。人間はヒューリスティクスを用いて意思決定を行い、試行錯誤によって誤りを修正する。エージェントは、機械の速度で同じ作業をプログラム的に完了する必要があり、しかも通常は動的に変化する行動空間においてである。したがって、「エージェントは単にトランザクションを提出すればよい」という考え方は、その難易度を過小評価している。トランザクションの提出こそが最も簡単な部分なのである。
結論
ブロックチェーンは、当初からエージェントに必要な意味論および協調レイヤーをネイティブに提供することを目的として設計されたものではない。その設計目標は、対抗的環境において決定論的実行および状態遷移の合意を保証することにある。この基盤の上に構築されたインタラクションレイヤーは、人間のユーザーがインターフェースを通じて状態を解釈し、フロントエンドインターフェースを通じて操作を選択し、人間による審査を通じて結果を検証するというモデルに沿って進化してきた。
エージェントシステムは、このアーキテクチャを根底から覆す。それらは、人間の解釈者、承認者、検証者をループから除外し、これらの機能を機械ネイティブな実装に移行させる。この転換は、四つの次元で構造的摩擦を露呈する：発見、信用判定、データ取得、実行フローである。これらの摩擦が生じるのは、実行が不可能だからではなく、ブロックチェーン周辺のインフラストラクチャが、多くの場合、状態解釈とトランザクション提出の間に人間の関与があることを前提としているからである。
これらのギャップを埋めるには、おそらく多層の技術スタックにわたって新しいインフラストラクチャを構築する必要がある：クロスプロトコルの経済的状態を機械読み取り可能な中間層に正規化するもの；ポジション、健全性係数、機会集合などの意味論的プリミティブを提供するインデクサーサービスまたはリモートプロシージャコール（RPC）拡張；標準コントラクトマッピングおよびトークン真正性検証を提供するレジストリ；戦略制約をコード化し、マルチステップのワークフローを処理し、目標の達成をプログラム的に検証する実行フレームワーク。一部のギャップは、パーミッションレスシステムの構造的特徴——オープンなデプロイ、標準アイデンティティの脆弱性、インターフェースの異種混在性——に由来する。他は、現在のツール、標準、インセンティブ設計に依存しており、エージェントの使用規模が拡大し、プロトコルが自律システムとの統合親和性を競って最適化するにつれて、これらのギャップは徐々に縮小していく可能性がある。
自律システムが資本の管理、戦略の実行、チェーン上アプリケーションとの直接的な対話を開始するにつれて、現在のインタラクションレイヤーのアーキテクチャ仮定がますます顕在化するだろう。本稿で述べられた大部分の摩擦は、ブロックチェーンツールおよびインタラクションモードが人間の仲介ワークフローに沿って進化してきたことを反映している；一部の摩擦は、パーミッションレスシステムの開放性、異種混在性、対抗的環境に由来する；さらに一部は、複雑な環境における自律システムが一般的に直面する問題である。
核心的な課題は、エージェントがトランザクションに署名することではなく、現在ブロックチェーンの状態と操作行動の間に、ソフトウェアおよび人間の判断が共同で担っている意味論的解釈、信用判定、戦略実行を、エージェントが信頼できる方法で実行できるようにすることである。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@galaxyhq
