作者：Zack Pokorny、Galaxy Digitalアシスタント・リサーチャー；出典：Galaxy Digital；編集：Shaw 金色财经
AIエージェント（人工知能エージェント）の活用シーンと能力は、段階的に進化し始めています。これらは、タスクを自律的に実行するようになりつつあり、関連する研究開発も、エージェントが資金を保有・配分し、取引と収益の戦略を発掘する、といった機能を持たせる方向で進められています。この実験的な転換はまだ極めて初期段階にありますが、その発展の方向性は過去とはまったく異なっています――これまでのエージェントの多くは、主にソーシャルや分析ツールとして使われていました。
ブロックチェーンは、この進化の過程に自然な実験場を提供しています。ブロックチェーンには、無許可性、組み合わせ可能性（同じ実行フレームワークでさまざまな金融基盤コンポーネントのアプリを収容できること）、オープンソースのアプリケーション・エコシステム、参加者全員に平等に公開されるデータ、そしてオンチェーン上のすべての資産がデフォルトでプログラム化に対応している、という特徴があります。
ここから、構造的な問いが生じます。つまり、ブロックチェーンがプログラム可能で無許可であるにもかかわらず、自律的なエージェントがなぜなお運用上の障害に直面するのか、という問題です。答えは、実行が可能かどうかではありません。実行の「その上」に必要となる、どの程度の意味理解と協調スケジューリングのコストを負担しなければならないかにあります。ブロックチェーンは状態遷移の正確性を保証できますが、通常はプロトコル固有の経済的な解釈、標準的なアイデンティティ、目標階層のスケジューリングといった抽象能力は提供しません。
この障害の一部は、無許可システムのアーキテクチャ特性に由来し、別の一部は、現在のツール、情報のフィルタリング、そして市場インフラの発展状況に由来します。実際の適用では、さまざまな上位機能が依然として、人間の操作を中核に設計されたソフトウェアとワークフローに頼る必要があります。
ブロックチェーンの設計の中核は、意味解釈ではなく、コンセンサス・メカニズムと決定論的な実行にあります。外部に提供されるのは、ストレージ・スロット、イベント・ログ、コール追跡などの基盤コンポーネントであり、標準化された経済的対象ではありません。そのため、保有ポジション、収益、ヘルス係数、流動性の深さといった抽象概念は、通常、インデクサ、分析レイヤー、フロントエンドUI、アプリケーション・プログラミング・インターフェース（API）によってオフチェーンで再構築され、各プロトコル固有の状態を、より使いやすい形式へと変換します。
多くの主要な分散型金融（DeFi）における操作プロセス、特に一般ユーザーや主観的な意思決定に基づく操作は、依然として「ユーザーがフロントエンドUIと相互作用し、単一の取引に対して署名する」ことを中核とするモードに留まっています。この、ユーザーUI中心のモードは、一般ユーザーの普及とともに大規模化された適用を実現し、たとえオンチェーン上の活動の相当部分がすでに機械駆動であったとしても、現行の主流の一般ユーザーのインタラクション・ロジックは概ね次の通りです。操作意図→ユーザーUI→取引の発起→完了確認。手続き上のルートは異なっていても、プログラム化された操作には独自の制限があります。開発者は構築段階でコントラクトと資産の範囲を事前に選び、その固定範囲に基づいてアルゴリズムを走らせる必要があります。これら二つのモードはいずれも、実行中に動的な目標に応じて、自律的に行動を発掘・評価・組み合わせる必要があるシステムには適応できません。
取引検証のために最適化された基盤インフラに対して、同時に経済状態の解釈、信用の評価、そして明確な目標に基づく行動の最適化が必要なシステムで利用され始めると、運用上の障害が顕在化し始めます。このギャップの一部は、ブロックチェーンの無許可・異種化された設計特性に由来し、別の一部は、既存ツールが依然として人手による監査とフロントエンドの仲介を前提に、ブロックチェーンとの相互作用を包む形で構築されていることに由来します。
ブロックチェーン基盤インフラとエージェントシステムのギャップを分析する前に、より高次のエージェントの操作フローと、従来のオンチェーン・アルゴリズム・システムの核心的な相違点を明確にしておく必要があります。
両者の違いは、自動化の度合い、技術的な複雑さ、パラメータ化の設定、さらには動的適応能力ではありません。従来のアルゴリズムシステムは高度にパラメータ化でき、新しいコントラクトやトークンを自動発掘し、さまざまな戦略間で資金を配分し、そしてパフォーマンスに応じてリバランスできます。核心的な違いは、システムが「構築段階で事前に想定されていない」状況を処理できるかどうかです。
従来のアルゴリズムシステムはどれほど複雑でも、開発段階で想定されたパターンに対して所与のロジックを実行するだけです。この種のシステムには、各プロトコル用に事前設定されたインターフェース・パーサ、契約状態を経済的意味へ変換するための事前設定評価ロジック、信用や標準判定のルールを明確に定義することが必要で、さらに意思決定分岐のすべてに対して（アルゴリズム自体がどれほど動的で柔軟であっても）ハードコードされたルールを書き込む必要があります。想定されたパターンに合致しないケースが出現した場合、システムはそのシーンをスキップするか、あるいは単純に実行が破綻します。システムは見知らぬ状況について推論判断できず、「現在の状況が既知のテンプレートに一致するかどうか」を検証することしかできません。
この「消化ガチョウ」のような機械的自動装置は、迫真の挙動を模倣できますが、各動作は事前に設定されたものです。（『サイエンティフィック・アメリカン』、1899年1月）
従来のアルゴリズムは、新しい貸借市場をスキャンする際、見慣れたイベントを発する、または既知の工場（ファクトリー）パターンに一致する、デプロイ済みコントラクトを識別できます。しかし、もし「見慣れない」インターフェースを備えた新しい貸借の基盤コンポーネントが現れた場合、システムはそれを評価できません。コントラクトを人手で点検し、その動作メカニズムを理解し、それが機会プールに含まれるかを判断し、統合ロジックを書く必要があります。これらの手順が完了して初めて、アルゴリズムはその対象と相互作用できます。人間が解釈し、アルゴリズムが実行します。そして、基盤モデルに基づくエージェントシステムは、この境界を破ります。これらは、習得した推論能力によって次を実現できます：
曖昧または明確に指定されていない目標の解釈。たとえば「最大化するが、過度なリスクは避ける」といった指示は解釈が必要です。どの程度が過度なのか？ 収益とリスクはどうバランスすべきか？ 従来のアルゴリズムは事前にこれら条件を厳密に定義する必要がありますが、基盤モデルは意図を解釈し、判断を行い、そしてフィードバックに基づいて自己の理解を最適化できます。
新しいインターフェースへの汎化適応。エージェントは、見知らぬコントラクトのコードを読み、ドキュメントを解析し、または未見のアプリケーション・バイナリ・インターフェース（ABI）を確認し、このシステムの経済機能を推断できます。各種プロトコルごとに、あらかじめパーサを構築する必要がありません。現時点ではこの能力はまだ不完全で、エージェントは誤判定する可能性がありますが、それでも開発段階で想定されていなかったシステムとの相互作用を試みることができます。
不確実性の下で、信頼性と規範性を推論する。信頼のシグナルが曖昧または不完全な場合、基盤モデルは二値ルールを単純に当てはめるのではなく、確率的に判断を重み付けできます。このスマートコントラクトは公式の正規品か？ 既存の証拠の下で、このトークンは大部分が合法である可能性が高いか？ 従来のアルゴリズムには「ルールがある」か「ルールがない」という2状態しかありませんが、エージェントは確信度に基づいて推論できます。
誤りを解釈し、自適応的に調整する。予期しない状況が発生した場合（たとえば取引のリバート、出力が期待と一致しない、シミュレーションと実行の間で状態が変化する等）、エージェントは問題の原因を推断し、どのように対応するかを決定できます。対照的に、従来のアルゴリズムは例外捕捉コードブロックを実行するだけで、例外に対して分岐処理をするに留まり、例外を解釈することはできません。
これらの能力は実在しますが、現時点ではまだ不完全です。基盤モデルは幻覚を生み、情報を誤読し、自信ありげに見える誤った判断を下すことがあります。対抗的で資金が関与する環境（すなわちコードを制御できる、または資産を受け取れる状況）では、「未設定システムとの相互作用を試みる」ことが、そのまま直接損失を意味する可能性があります。本稿の核心的主張は、エージェントが現在その機能を信頼性高く完遂できる、ということではありません。そうではなく、それらは従来のシステムでは実現できなかった方法で試行できる可能性があり、そして将来の基盤インフラによって、これらの試みがより安全でより信頼できるものになることが期待される、という点にあります。両者を絶対的な分類ではなく「連続体」として捉えると理解しやすくなります。部分的な従来システムは学習型推論を取り込み、部分的なエージェントも重要な経路においてハードコードされたルールに依存することがあり得ます。両者の違いは方向性であり、二値的対立ではありません。エージェントシステムは、より多くの解釈・評価・自適応の作業を実行時推論に移し、開発段階での事前設定に留めません。これは前述の障害論とも密接に関係しています。なぜなら、エージェントが試みようとしているのがまさに、従来のアルゴリズムが完全に回避してきたことだからです。従来のアルゴリズムは、発見コストを回避するために開発段階で人手によりコントラクト集合をふるいにかけ、運用者が維持するホワイトリストでコントロール層のコストを回避し、既知のプロトコルにはあらかじめパーサを用意することでデータコストを回避し、想定される安全範囲内で実行することで実行コストを回避します。人工が事前に、意味・信頼・戦略層での作業を完了させ、アルゴリズムは境界の中でのみ実行します。オンチェーン・エージェント操作フローの初期バージョンは、このモードを継承する可能性がありますが、その核心ロジックは「発見、信頼、戦略評価を、開発段階で事前設定するのではなく実行時推論に移す」ことにあります。
エージェントは、見知らぬ機会を発見し評価し、ハードコードされたルールなしにコントラクトの規範性を判断し、事前設定されたパーサなしに異種状態を解析し、また曖昧になり得る目標に対して戦略を実行しようとします。そしてまさに、そのような段階で基盤インフラの弱点が顕在化します。障害が存在する理由は、エージェントがアルゴリズムと同じことをしているのに、より難しいからではありません。むしろ、それらが完全に異なることを試みているからです。つまり：開かれた動的な解釈の振る舞い空間の中で実行するのに対し、閉じた事前に統合された固定空間で動くのではないからです。
構造的に見ると、この矛盾はブロックチェーンのコンセンサスの欠陥に由来するものではありません。むしろ、それを構築するための全体的なインタラクション・スタックの進化の仕方に起因します。
ブロックチェーンは、決定論的な状態遷移、最終状態に対するコンセンサス、そして最終的な確定性を保証します。しかし、それはプロトコル層で経済的な解釈、意図の検証、あるいは目標の追跡を符号化しません。これらの責務はこれまで、フロントエンド、ウォレット、インデクサ、その他のオフチェーン協調レイヤーが担っており、プロセスの中には常に人手が介在しています。
主流のインタラクション・モードもまた、この設計を反映しています。たとえ専門家であっても同様です。一般ユーザーは、UI上で状態を解釈し、画面上で操作を選び、ウォレットで取引に署名しますが、形式的に結果を検証しているわけではありません。アルゴリズム取引の機関は実行の自動化を実現していますが、それでもプロトコル集合の人手によるふるい分け、例外の監査、そしてインターフェース変更時の統合ロジック更新に依存しています。二つのシーンでは、プロトコルは実行の正しさだけを保証し、意図の解釈、例外処理、新機会の適応は人手で行われています。
エージェントシステムは、この分業を圧縮し、場合によっては消し去ってしまいます。エージェントは、経済的意味を持つ状態をプログラム的に再構築し、目標が前進するかを評価し、単純な取引をオンチェーンに乗せるだけではなく結果を検証しなければなりません。これらの負担は、ブロックチェーン上では特に際立ちます。なぜなら、エージェントは開かれた対抗的で急速に変化する環境で動作するからです。新しいコントラクト、資産、実行パスは、分散化された監査なしに現れ得ます。プロトコルは取引が正しく実行されることは保証しますが、経済状態が解釈しやすいこと、コントラクトが公式の正規品であること、実行パスがユーザーの意図に一致していること、あるいは関連する機会がプログラム的に発見され得ることまでは保証しません。
以降の章では、エージェントの実行ループの各段階に即して、この種の障害を分析します。すなわち、既存コントラクトと機会の発見、合法性の検証、経済的意味を持つ状態の取得、そして目標に従った実行です。
発見コストが生じるのは、分散型金融（DeFi）の行動空間が、無許可で開かれた環境の中で継続的に拡張し、それに伴い関連性と合法性を、人手でチェーン上のソーシャル、マーケット、ツール層によってフィルタリングする必要があるためです。新しいプロトコルは公告と研究発表によって知らされるだけでなく、フロントエンド統合、トークンリスト、分析プラットフォーム、流動性形成などのフィルタ層によっても選別されます。長い年月を経て、これらのシグナルは、行動空間の中で経済価値があり、かつ十分に信用できる部分を識別するための、一連の実用的な判断基準となることが多いものの、このプロセスはしばしば非公式で不均衡であり、また一部は第三者と人手のふるい分けに依存しています。
エージェントはフィルタリングされたデータや信頼シグナルを取得できますが、人間がそれらを解釈する際の自然な近道は持っていません。チェーン上の視点から見ると、すでにデプロイされたすべてのコントラクトの可発見性は平等です。合法なプロトコル、悪意あるフォーク、テスト用デプロイ、放棄されたプロジェクトも、すべて呼び出し可能なバイトコードとして存在します。オンチェーンは、どれが重要で、どれが安全かをラベル付けしません。
チェーン上の視点では、すでにデプロイされたすべてのコントラクトは同等の可発見性を持ちます。合法なプロトコル、悪意あるフォーク・コントラクト、テスト用デプロイ・コントラクト、放棄されたプロジェクトも、すべて呼び出し可能なバイトコードとして提示されます。
そのため、エージェントは自前で発見メカニズムを構築しなければなりません。デプロイ・イベントをスキャンし、インターフェースのパターンを識別し、ファクトリー・コントラクト（他のコントラクトをプログラム的にデプロイするコントラクト）を追跡し、流動性形成を監視して、どのコントラクトを意思決定範囲に含めるべきかを判断します。このプロセスは単にコントラクトを探すだけではなく、それがエージェントの行動空間に入る価値があるかを判断することでもあります。
候補となるコントラクトを識別することは第一歩です。コントラクトは、初期の発見フィルタを通過した後、次節で述べる規範性と真実性の検証を経る必要があります。エージェントは、発見したコントラクトが自ら主張する内容と一致していることを確認できなければ、意思決定空間に取り込むことはできません。
発見コストは、新規デプロイを検出することそのものを意味するわけではありません。成熟したアルゴリズムシステムなら、自身の戦略範囲内でそれを行うことがすでに可能です。たとえばUniswapのファクトリー・イベントを監視して新しい流動性プールを自動的に組み込む探索者は、「動的発見」を実行しています。障害は、さらに上位の二つの層で発生します。発見したコントラクトが合法かどうか（次節で扱う規範性の問題）、そしてそれがオープン型の目標に役立つのか、それとも単に事前に想定された戦略タイプに適合するだけなのか、という問題です。
探索者の発見ロジックは戦略に密接に結びついています。戦略が事前に定義されているため、どのインターフェース・パターンを探すべきかを知っているのです。一方、「最適なリスク調整後の機会」など、より広範なタスクを担うエージェントは、戦略に派生するフィルタにだけ頼るわけにはいきません。エージェントは、目標そのものに照らして、新たに出会った機会を評価する必要があります。これには未知のインターフェースの解析、経済機能の推定、そしてその機会が意思決定空間に入るべきかの判断が要ります。この部分は一般的な自律性の問題ですが、ブロックチェーンは難易度をさらに引き上げます。未知のコードは直接実行可能で資金を抱えており、しかもプロトコルのネイティブなシグナルだけでは分類できないためです。
コントロール層のコストが生じるのは、アイデンティティと合法性が通常、プロトコル外部でのフィルタリング、ガバナンス、ドキュメント、インターフェース、運営者の判断などによって共同で確定されるためです。現状の多くのワークフローでは、人手がその判断プロセスの重要な部分を占めています。ブロックチェーンは決定論的な実行と最終的な確定性を保証しますが、呼び出し者が目標コントラクトと相互作用していることを保証しません。意図の判断は、ソーシャル文脈、ウェブサイト、そして人手によるフィルタリングに外注されています。
現在のプロセスでは、人間はウェブの信頼層を非公式な検証ツールとして利用しています。DeFiLlamaのような集約プラットフォームや、プロジェクトが認証したソーシャルアカウントから公式ドメインを見つけ、そのサイトを「人間が理解する概念」と「コントラクトアドレス」の間の公式な対応付けとして扱います。続いてフロントエンドは、有効な真実のソースを一連の形で符号化し、どのアドレスが公式であるか、どのトークン表現を使うか、どの入口が安全かを示します。
1789年のメカニカル・トルコ人（Mechanical Turk）はチェスを指す機械で、見た目は自律運転に見えますが、実際には隠された人間の操作員に依存しています。（ハンボルト大学図書館）
エージェントはデフォルトで、ソーシャル文脈によってブランドの標識、認証されたソーシャル信号、あるいは「公式性」を解釈しません。私たちはエージェントに、これらの信号に由来するフィルタ後の入力を与えることはできます。しかし、それらを安定して利用でき、機械が実行可能な信頼仮説へ変換するには、明確なレジストリ、ポリシールール、または検証ロジックが必要です。運営者はエージェントに、厳選されたホワイトリスト、認証済みアドレス、信頼戦略を設定できます。問題は、ソーシャル文脈をまったく取得できないことではなく、動的に拡張する行動空間の中で、これらの防護バリアを継続的に維持するには過大な運用負担がかかり、さらにそれらのバリアが欠落したり不十分になったりすると、エージェントには人間が無意識に使うバックアップの検証メカニズムがないことにあります。
この信頼判定能力の不足が引き起こす実際の帰結は、オンチェーンのエージェント駆動システムでもすでに現れています。YouTubeの暗号化ブロガー兼インフルエンサーであるOrangieは、エージェントが資金をハニーポットコントラクトへ預けてしまったケースがありました。別の事例では、Lobstar Wildeという名のエージェントが状態またはコンテキストの不具合により、アドレス状態を誤って解釈し、大量のトークン残高をオンラインの「乞食アドレス」に送ってしまいました。これらのケースは本稿の中核的な論拠ではありませんが、信頼判定、状態解釈、実行戦略におけるミスが、直接的に資金損失へつながることを直感的に示しています。
問題は、コントラクトが発見しにくいことではなく、オンチェーン上には一般に「これはアプリXの公式コントラクトである」というプロトコルネイティブの概念が存在しないことにあります。この欠如は、無許可システムの特性である面があるのは確かで、設計上の手落ちというよりはその結果でもありますが、それでも自律的システムにとって協調上の難題になります。この問題は、弱い規範アイデンティティのオープンシステム・アーキテクチャ特性に起因する部分があり、またレジストリ、標準、信頼分配メカニズムがまだ成熟していないことにも起因します。もしエージェントがAave v3とやり取りしたいなら、どのアドレスが公式の正規品であるか（流動性プール、設定器、データ提供者など）を判定し、さらにそれらのアドレスが不変コントラクトなのか、プロキシで代理・アップグレード可能なコントラクトなのか、あるいはガバナンス提案の変更待ちで実行段階にある状態なのかを判断する必要があります。
人間はドキュメント、フロントエンドUI、そしてソーシャルメディアでこの問題を解決しますが、エージェントは次の情報を照合して判定しなければなりません：
代理モードと実装コントラクトの指し先
管理権限とタイムロック・コントラクト
ガバナンス制御下のパラメータ更新モジュール
既知のデプロイ済みコントラクト間のバイトコード / アプリケーション・バイナリ・インターフェース（ABI）一致度
公式レジストリがない場合、「公式性」は推論問題になります。つまりエージェントはコントラクトアドレスを静的な設定として扱えません。それらは、常に検証済みの厳選ホワイトリストを維持するか、実行時に代理を照合しガバナンス監視で再推論するか、あるいは廃止、攻撃、偽造コントラクトとの相互作用に関するリスクを引き受ける必要があります。従来のソフトウェアや市場インフラでは、サービスのアイデンティティは通常、機関が維持するネーミングスペース、証明書、アクセス制御によってアンカーされています。対照的に、オンチェーンでは、あるコントラクトが呼び出し可能で機能が動いているとしても、呼び出し側の視点からは、経済あるいはビジネスのレイヤーでは公式正規品ではない可能性があります。
トークンの真正性とメタデータの問題は、本質的に同じ
トークンは自己説明のような情報を持っているように見えますが、そのメタデータには権威性がなく、単にコントラクトコードが返すバイトデータに過ぎません。典型例はWETH（ラップドETH）です。広く使われているWETHコントラクトでは、明確に次が定義されています：
これらの情報はアイデンティティを示しているように見えますが、実際には違います。どんなコントラクトでも次の内容を返せます：
symbol() = “WETH”
decimals() = 18
name() = “Wrapped Ether”
そして、完全に同じERC-20トークン標準インターフェースを実装できます。name()、symbol()、decimals()は単なる公開の読み取り専用関数で、返される内容はデプロイヤーによって設定されるだけです。実際には、イーサリアム上には近200種類のトークンが存在し、名称はすべて「Wrapped Ether」、シンボルはすべて「WETH」、小数の精度もすべて18桁です。CoinGeckoやEtherscanで調べなければ、どの「WETH」が公式正規品か見分けられますか？（答えはリスト中の78番目）
イーサリアム上には、名称が「Wrapped Ether」、シンボルが「WETH」のトークンが約200あります。第三者プラットフォームを使わずに、どれが正真正銘のWETHか判断できますか？
これがエージェントが置かれている状況です。ブロックチェーンは一意性を検証せず、いかなるレジストリとも照合せず、それにも無関心です。あなたは今日、500個のコントラクトをデプロイし、それらがまったく同じメタデータを返すようにすることもできます。オンチェーンには、経験則による判断方法もいくつかあります（たとえばETH残高と総供給量の照合、主要な分散型取引所の流動性深度の照会、貸借プロトコルに担保として列挙されているかの確認など）がありますが、どれも絶対的で確実な証明を提供するものではありません。どの方法も、しきい値の仮定に依存するか（数十億規模のペア流動性を誰も偽造できないはずだ、など）、あるいは再帰的に、まず別のコントラクトの規範性を検証する必要があるかのどちらかです。
迷路のように、チェーン上で「本当の」経路を識別するには外部の案内が必要であり、標準的なシグナルは提供されていません。（バーミンガム博物館・美術館）
だからこそ、トークンリストとレジストリがチェーン外のフィルタリング層として存在します。それらは「WETH」という概念を特定のアドレスにマッピングする仕組みを提供し、同じ理由でウォレットやフロントエンドはホワイトリストを維持するか、信頼できる集約器に依存しています。エージェントにとっての核心的な問題は、メタデータが信頼できないことだけではありません。むしろ、規範的アイデンティティは通常、ソーシャルや機関のレイヤーで確立され、プロトコルネイティブではないという点にあります。オンチェーンで信頼できる唯一の識別子はコントラクトアドレスですが、人間が理解できる意図（例：「USDCに交換」）を正しいアドレスへマッピングするには、依然としてプロトコルネイティブではないフィルタ、レジストリ、ホワイトリスト、あるいはその他の信頼層への大きな依存が必要です。
複数のDeFiプロトコル間で最適化するエージェントは、それぞれの機会を、経済的対象として統一抽象化する必要があります。たとえば利回り、流動性の深さ、リスクパラメータ、手数料構造、オラクルの出所などです。ある意味では、これは一般的なシステム統合問題です。しかしブロックチェーン上では、プロトコルの異種性、直接的な資金リスク、複数呼び出しの状態をつなぎ合わせる必要、そして下層に統一された経済的schemaが欠けていることにより、この負担は大幅に増幅されます。そして、これらこそが機会の比較、シミュレーション設定、リスク監視に必要な基礎情報です。
ブロックチェーンはプロトコル層では、通常、標準化された経済的対象を公開せず、公開されるのはストレージスロット、イベントログ、関数の戻り値だけです。経済的対象はそこから推導するか、再構築しなければなりません。プロトコルはコントラクト呼び出しが正しい状態値を返すことは保証しますが、その値が明確に理解可能な経済概念に対応していることは保証しません。また、同一概念が異なるプロトコル間で一貫したインターフェースで取得できることも保証しません。
そのため、市場、ポジション、ヘルス係数といった抽象概念は、プロトコルネイティブのコンポーネントではなく、インデクサ、分析プラットフォーム、フロントエンド、APIによってチェーン外で再構築され、異種プロトコル状態を利用可能な抽象層に正規化しているものに過ぎません。人間のユーザーは通常、この正規化された層のデータしか見ません。エージェントも利用できますが、その分サードパーティのschema、遅延、そして信頼仮説を引き継ぎます。さもなければ、エージェント自身がそれらの抽象ロジックを再構築する必要があります。
この問題は、各種プロトコルにおいてさらに悪化します。金庫（バンク）シェアの価格、貸借市場の担保率、DEXプールの流動性深度、担保コントラクトの報酬率などはいずれも経済的意味のある基礎指標ですが、標準化されたインターフェースで公開されるものはありません。各プロトコル体系には独自の読み取り方法、構造体形式、単位の約束があります。同じカテゴリであっても実装は各々異なります。
貸借市場は、この問題をはっきりと示します。経済概念は一般に似ていて汎用的です。たとえば供給と借入の流動性、利率、担保係数、上限（リミット）、清算の閾値などです。しかしデータの読み取り経路はまったく異なります。
Aave v3を例にすると、市場の列挙と、準備資産（reserves）状態の読み取りは別ステップで行われます。典型的なフローは次の通りです：
以下の方法で準備資産を列挙します
この関数はトークンアドレス配列を返します。
各資産について、以下の方法で流動性と利率の基礎データを取得します：
この呼び出しは構造体を返し、単回で流動性総量、利率インデックス、設定識別子などを含むデータを取得できます。たとえば：
それとは反対に、Compound v3（Comet）では、1つのデプロイにつき単一の市場（たとえばUSDC、USDT、ETHなど）に対応し、統一された準備金（reserves）構造体は存在しません。そのため、複数回の関数呼び出しを通じて、完全な市場スナップショットのデータを組み合わせる必要があります：
基礎利用率
合計
利率
担保資産の配置
グローバル設定パラメータ
各呼び出しは、経済状態の異なる断片だけを返します。「市場」は一級市民（first-class）オブジェクトではなく、呼び出し側が自ら組み立てる推論的な構造です。
エージェントの観点では、これら二つのプロトコルはいずれも貸借市場に属します。しかし統合の観点では、両者は完全に異なるデータ取得システムです。次のような共通データ構造が存在するわけではありません：
逆に、エージェントは異なるプロトコルごとに異なる資産列挙手法を採用し、複数回の呼び出しで状態データを連結し、計量単位と換算ルールを統一し、そして推定値と直接公開された基礎データとの差異を調整しなければなりません。
構造的な不統一に加えて、このような断片化は遅延と一貫性リスクも引き起こします。経済状態が単一のアトミックな市場オブジェクトとして公開されないため、エージェントは複数のコントラクトへ複数回の遠隔手続き呼び出し（RPC）を行い、状態スナップショットを再構築する必要があります。呼び出しが1回増えるごとに、遅延が増し、インターフェースのレート制限に抵触する確率が上がり、さらにブロック不一致のリスクも高まります。市場の変動環境では、供給利率の計算が完了した時点で資金利用率がすでに変わっている可能性があります。ブロック高を明確に固定しない限り、設定パラメータと流動性総量が同じブロック由来でない可能性があります。人間のユーザーは、フロントエンドのキャッシュ層と集約バックエンドによってこの問題を暗黙に緩和しますが、原始的なRPCインターフェースを直接呼び出すエージェントは、データ同期、バッチリクエスト、時間的一致性の問題を明示的に扱う必要があります。したがって、非標準化されたデータ取得は統合上の不便だけでなく、性能、同期メカニズム、そして実行の正確性に対する制約でもあります。
統一された経済データ取得の規格が欠けていることは、たとえ異なるプロトコルがほぼ同じ金融の基礎機能を実装していたとしても、その状態の露出方式が依然としてコントラクト固有であり、かつ組み合わせロジックに依存していることを意味します。この構造の違いこそが、データの摩擦の核心原因です。
ブロックチェーン上の経済状態へのアクセスは本質的にプルモデルです。たとえ実行シグナルがストリーミングでプッシュされ得るとしてもです。外部システムは、必要な状態をノードへ能動的に問い合わせる必要があり、継続的で構造化された更新を受け取るわけではありません。このパターンは、ブロックチェーンの中核機能――必要に応じた検証であり、アプリケーションレベルで継続的な状態ビューを維持することではない――を反映しています。
オンチェーンにもプッシュモデルの基盤コンポーネントは存在します。WebSocketのサブスクライビングによって新しいブロックやイベントログをリアルタイムにプッシュできますが、それらは大部分の経済的意味を担うストレージ状態を含みません。プロトコルが冗長にそれをログとして記録するよう選択している場合を除きます。エージェントは、オンチェーンのサブスクライビングだけで、貸借市場の利用率、プールの準備金量、あるいはポジションのヘルス係数を直接取得できません。これらの値はコントラクトのストレージ空間に保存されており、多くのプロトコルは下流利用者向けに、ストレージの変更をネイティブにプッシュするメカニズムを提供していません。現時点で最も現実的な方法は、新しいブロックヘッダを購読し、各ブロックごとにストレージ状態を再問い合わせることです。たとえストリーミングのイベントをトリガーにしても、状態アクセスの本質はプルモデルのままです。ログはデータが変化する可能性を示すだけで、最終的な経済状態を符号化してはいません。その状態を再構築するには、明示的に読み取り、そして履歴状態へアクセスする必要があります。
エージェントシステムは、むしろ逆方向のデータフローの方が適しています。エージェントは何百ものコントラクトの状態変化をポーリングする必要がなく、構造化された、事前計算済みの状態更新を受け取り、それをその実行環境へ直接プッシュできます（例：更新後の利用率、ヘルス係数、ポジションの変動）。プッシュ型アーキテクチャは、冗長な問い合わせを減らし、状態変化がエージェントに認識されるまでの遅延を抑え、中間層が状態をエージェントが理解し実行可能な意味の明確な更新としてカプセル化できるようにします。エージェントに、原始ストレージから意味を自力で解釈させるのではなく。
ただ、このパターンへの転換は容易ではありません。サブスクライブする基盤インフラ、関連性をフィルタするロジック、そしてストレージ変動をエージェントが実行可能な経済イベント仕様へ変換することが必要です。しかし、エージェントが断続的な問い合わせ側ではなく、常時オンラインの参加者になっていくにつれて、プルモデルの非効率（レート制限、同期コスト、異なるエージェント間での重複問い合わせ）がますます深刻になります。「エージェントを断続的なクライアントではなく、継続的な消費者として扱う」インフラは、自律システムの稼働方式により適しているのかもしれません。
プッシュ型の基盤インフラが本当により優れているかは、まだ結論が出ていません。全量の状態変化を流すデータフローはフィルタリング問題を生み、エージェントは依然としてどの情報が関連するかを判断する必要があるため、別の層で再びプル的なロジックが入り込むことになります。核心は、プルモデル自体が間違っているのではなく、既存アーキテクチャが設計時に「持続的に動く機械利用者」を前提にしていなかったこと、そしてエージェントが使われる規模が拡大していくにつれ、代替案を検討する価値が出てくる、という点にあります。
実行の摩擦が生じるのは、多くの現在のインタラクション層が、意図の変換、取引の審査、そして結果検証を、これまでフロントエンド、ウォレット、そして人間の監督を中核とするワークフローの中に封入しているためです。一般ユーザーの状況や主観的な意思決定の場面では、この監督は通常、人間が行います。しかし自律システムでは、これらの機能は形式化され、直接コードとして実装されなければなりません。ブロックチェーンはコントラクトロジックに基づく決定論的実行を保証できますが、取引がユーザーの意図に合致すること、リスク制約に従っていること、あるいは期待する経済結果を実現していることまでは保証できません。既存のプロセスにおいては、フロントエンドUIと人間がこの欠けている部分を補っています。
フロントエンドは操作シーケンス（スワップ、許可、預入、貸借など）をオーケストレーションし、ウォレットは最後の「審査して送信する」というチェックポイントを提供します。ユーザーや操作者は、通常最後のステップで非公式に戦略判断を行います。多くの場合、情報が不完全な状態で、取引が安全かどうか、見積もり結果が許容できるかどうかを判断します。取引が失敗したり想定外の結果になったりすると、ユーザーは再試行し、スリッページを調整し、ルートを変更するか、あるいは操作をやめます。エージェントシステムは、この実行ループから人間を取り除くため、機械は次の3種類の人間機能を機械ネイティブロジックで置き換えなければなりません：
意図コンパイル。たとえば「リスク調整後で最も収益性の高い経路へ、私のステーブルコインを配分する」といった人間の目標は、具体的な行動計画にコンパイルされる必要があります。どのプロトコルを使うか、どの市場を使うか、どのトークン経路を通すか、操作規模、承認方法、そして実行順序を決めます。人間にとってはこのプロセスはフロントエンドに暗黙により完了しますが、エージェントにとっては形式化して実装しなければなりません。
戦略実行。「取引を送信」をクリックすることは単なる署名行為ではなく、取引が制約に合っているかどうかの暗黙の検証でもあります。スリッページ許容度、レバレッジ上限、最低ヘルス係数、ホワイトリストに載ったコントラクト、あるいは「アップグレード可能コントラクトを禁止」といった要素です。エージェントは、明示された戦略制約を機械が検証可能なルールへと符号化する必要があります：
実行システムは、取引をブロードキャストする前に、実行しようとしている呼び出し関係図がこれらのルールに適合しているかを検証しなければなりません。
このため完成度の検証には、より高い要求が課されます。単に取引がオンチェーンに載ったことを確認するだけでは足りません。意図を中心に据えたアーキテクチャは、部分的な解決策を提供し得ます。つまり、「どう実行するか」に関する負担を、エージェントから専門のソルバーへより多く移すことができます。エージェントは原始の呼び出しデータを送信するのではなく、署名済みの実行意図をブロードキャストし、結果に基づく制約条件を指定します。ソルバーまたはプロトコル層のメカニズムは、これらの制約を満たす必要があり、そうして初めて実行が有効とみなされます。
分散型金融（DeFi）の実行プロセスの大部分は、本質的にマルチステップです。収益配分（リターン配置）の操作は、承認→スワップ→預入→貸借→担保（質押）と順に実行する必要がある場合があります。その一部は独立した取引で、別のものはバッチ呼び出しやルーティング・コントラクトによってパッケージ化して実行できます。人間はプロセスが完全に完了していなくても、画面でそのまま操作を続けられるため許容できます。一方、エージェントは決定論的なフローオーケストレーションが必要です。どのステップでも失敗した場合、リトライするのか、別のパスへ切り替えるのか、操作をロールバックするのか、あるいは実行を停止するのかを決めなければなりません。
これにより、人間の操作フローでは通常覆い隠されがちな新しい故障モードが生まれます：
意思決定とオンチェーンの間の状態ドリフト：シミュレーションと実際のチェーン実行の間に、金利、利用率、流動性が変化する可能性があります。人間はこの変動を受け入れられますが、エージェントは許容範囲を設定し、厳密に実行しなければなりません。
非アトミック実行と部分的な約定：一部の操作は複数の取引にまたがって実行される場合、または期待していた結果の一部しか生まれない場合があります。エージェントは中間状態を追跡し、最終状態が目標に合致していることを確認しなければなりません。
許可額（許容量）と審査のリスク：人間は画面操作の慣習として承認署名を行いますが、エージェントは承認範囲（上限額、支出元、期限）を安全戦略の中で推論し、単に画面ステップとして扱うのではなくなければなりません。
パス選択と暗黙の実行コスト：人間はルーティングツールとUIのデフォルト設定に依存しますが、エージェントはスリッページ、MEV（マイナー抽出可能価値）のリスク、Gas費用、価格インパクトを目的関数の中でモデリングしなければなりません。
実行の摩擦に関する核心的な観点は次の通りです。DeFiのインタラクション層は、人間のウォレット署名を最終の制御レイヤーとして置いています。現在、意図の検証、リスク許容度の判断、そして非公式の「妥当に見えるかどうか」のチェックは、この一歩に集中しています。人間の関与を取り除くと、実行は制御問題になります。エージェントは目標を操作チェーンへ変換し、戦略制約を自動実行し、不確実性の中で結果を検証する必要があります。この課題は多くの自律システムに存在しますが、ブロックチェーン環境では特に厳しいです。なぜなら、実行は直接資金に関わり、組み合わせ可能な形で未知のコントラクトも呼び出され得て、かつ対抗的な状態変化に直面するからです。人間は経験で意思決定し、試行錯誤で誤りを修正します。一方エージェントは、機械速度で同類の作業をプログラム的に完了させる必要があり、そしてしばしば動的に変化する操作空間に直面します。したがって、エージェントは「ただ取引を送るだけでよい」という見方は、難しさを大きく見誤っています。取引の提出自体は簡単な部分であり、本当に欠けているのはUIと人間が担っていた仕事のすべてです。すなわち、意図のコンパイル、安全性の担保、そして目標達成度の検証です。
ブロックチェーンは当初の設計で、自律的エージェントに必要な意味層と協調層をネイティブに提供していません。それは対抗的な環境において決定論的実行と状態遷移のコンセンサスを保証することを目的にしていました。この上に発展してきたインタラクション層は、常に人間ユーザーを中心に据えてきました。UIで状態を解釈し、フロントエンドで操作を選択し、人間が検証して結果を確かめる、という形です。
エージェントシステムは、このアーキテクチャを覆します。彼らは、人間の解釈者、承認者、検証者をプロセスから取り除き、これらの機能を機械ネイティブ化することを要求します。この転換は、発見、信頼判定、データ取得、実行オーケストレーションの4つの次元で構造的な摩擦として現れます。これらの摩擦は、実行が不可能だから生じるのではありません。むしろ、多くの状況で、ブロックチェーン周辺のインフラが依然として「人間が状態を解釈し、取引を提出する」段階をデフォルトで前提としているために生じるのです。
これらのギャップを埋めるには、複数の技術スタックにわたって新しいインフラを構築する必要があるかもしれません。プロトコルをまたぐ経済状態を、機械が読み取れる仕様へ正規化するミドルウェア。ポジション、ヘルス係数、機会集合などの意味的基礎コンポーネントを、原始ストレージデータではなく公開するインデクササービスやRPC拡張。公式コントラクトのマッピングや、トークンの真正性検証を提供するレジストリ。そして、戦略制約を符号化し、マルチステップのワークフローを処理し、目標達成度をプログラム化して検証できる実行フレームワークです。一部のギャップは無許可システムの構造的特性に由来します。すなわち、オープンなデプロイ、弱い規範アイデンティティ、そして異種のインターフェースです。別の部分は、既存ツール、標準、そしてインセンティブ設計の制約によるものです。エージェントの利用規模が拡大し、自律システムの統合利便性を高めるためにプロトコルが競争最適化するにつれ、これらの問題は緩和される可能性があります。
自律システムが資金を管理し、戦略を実行し、そしてオンチェーン上のアプリと直接相互作用し始めるにつれて、現在のインタラクション層に内蔵されたアーキテクチャ仮定がますます際立ってきます。本稿で述べた摩擦の大部分は、ブロックチェーンのツールとインタラクション・モードが人間の仲介ワークフローを中心に発展してきたことに起因します。部分的には無許可システムの開放性、異種性、そして対抗環境における自然な帰結です。さらに一部は、複雑な環境下で自律システムが一般的に直面する共通問題です。
核心的な課題は、エージェントに取引の署名をさせることではありません。信頼できる経路を用意し、現状の「原始のブロックチェーン状態」と「実際の操作」の間で、ソフトウェアと人間の判断によって共同で行われてきた意味、信頼、戦略に関する機能をエージェントのために提供することです。
1.03M 人気度
30.33K 人気度
26.4K 人気度
82.58K 人気度
521.36K 人気度
Galaxy：AIエージェントのオンチェーンでの困難の原因は何か？
作者：Zack Pokorny、Galaxy Digitalアシスタント・リサーチャー；出典：Galaxy Digital；編集：Shaw 金色财经
はじめに
AIエージェント（人工知能エージェント）の活用シーンと能力は、段階的に進化し始めています。これらは、タスクを自律的に実行するようになりつつあり、関連する研究開発も、エージェントが資金を保有・配分し、取引と収益の戦略を発掘する、といった機能を持たせる方向で進められています。この実験的な転換はまだ極めて初期段階にありますが、その発展の方向性は過去とはまったく異なっています――これまでのエージェントの多くは、主にソーシャルや分析ツールとして使われていました。
ブロックチェーンは、この進化の過程に自然な実験場を提供しています。ブロックチェーンには、無許可性、組み合わせ可能性（同じ実行フレームワークでさまざまな金融基盤コンポーネントのアプリを収容できること）、オープンソースのアプリケーション・エコシステム、参加者全員に平等に公開されるデータ、そしてオンチェーン上のすべての資産がデフォルトでプログラム化に対応している、という特徴があります。
ここから、構造的な問いが生じます。つまり、ブロックチェーンがプログラム可能で無許可であるにもかかわらず、自律的なエージェントがなぜなお運用上の障害に直面するのか、という問題です。答えは、実行が可能かどうかではありません。実行の「その上」に必要となる、どの程度の意味理解と協調スケジューリングのコストを負担しなければならないかにあります。ブロックチェーンは状態遷移の正確性を保証できますが、通常はプロトコル固有の経済的な解釈、標準的なアイデンティティ、目標階層のスケジューリングといった抽象能力は提供しません。
この障害の一部は、無許可システムのアーキテクチャ特性に由来し、別の一部は、現在のツール、情報のフィルタリング、そして市場インフラの発展状況に由来します。実際の適用では、さまざまな上位機能が依然として、人間の操作を中核に設計されたソフトウェアとワークフローに頼る必要があります。
ブロックチェーン・アーキテクチャとAIエージェント
ブロックチェーンの設計の中核は、意味解釈ではなく、コンセンサス・メカニズムと決定論的な実行にあります。外部に提供されるのは、ストレージ・スロット、イベント・ログ、コール追跡などの基盤コンポーネントであり、標準化された経済的対象ではありません。そのため、保有ポジション、収益、ヘルス係数、流動性の深さといった抽象概念は、通常、インデクサ、分析レイヤー、フロントエンドUI、アプリケーション・プログラミング・インターフェース（API）によってオフチェーンで再構築され、各プロトコル固有の状態を、より使いやすい形式へと変換します。
多くの主要な分散型金融（DeFi）における操作プロセス、特に一般ユーザーや主観的な意思決定に基づく操作は、依然として「ユーザーがフロントエンドUIと相互作用し、単一の取引に対して署名する」ことを中核とするモードに留まっています。この、ユーザーUI中心のモードは、一般ユーザーの普及とともに大規模化された適用を実現し、たとえオンチェーン上の活動の相当部分がすでに機械駆動であったとしても、現行の主流の一般ユーザーのインタラクション・ロジックは概ね次の通りです。操作意図→ユーザーUI→取引の発起→完了確認。手続き上のルートは異なっていても、プログラム化された操作には独自の制限があります。開発者は構築段階でコントラクトと資産の範囲を事前に選び、その固定範囲に基づいてアルゴリズムを走らせる必要があります。これら二つのモードはいずれも、実行中に動的な目標に応じて、自律的に行動を発掘・評価・組み合わせる必要があるシステムには適応できません。
取引検証のために最適化された基盤インフラに対して、同時に経済状態の解釈、信用の評価、そして明確な目標に基づく行動の最適化が必要なシステムで利用され始めると、運用上の障害が顕在化し始めます。このギャップの一部は、ブロックチェーンの無許可・異種化された設計特性に由来し、別の一部は、既存ツールが依然として人手による監査とフロントエンドの仲介を前提に、ブロックチェーンとの相互作用を包む形で構築されていることに由来します。
エージェントの操作フローと従来のアルゴリズム戦略
ブロックチェーン基盤インフラとエージェントシステムのギャップを分析する前に、より高次のエージェントの操作フローと、従来のオンチェーン・アルゴリズム・システムの核心的な相違点を明確にしておく必要があります。
両者の違いは、自動化の度合い、技術的な複雑さ、パラメータ化の設定、さらには動的適応能力ではありません。従来のアルゴリズムシステムは高度にパラメータ化でき、新しいコントラクトやトークンを自動発掘し、さまざまな戦略間で資金を配分し、そしてパフォーマンスに応じてリバランスできます。核心的な違いは、システムが「構築段階で事前に想定されていない」状況を処理できるかどうかです。
従来のアルゴリズムシステムはどれほど複雑でも、開発段階で想定されたパターンに対して所与のロジックを実行するだけです。この種のシステムには、各プロトコル用に事前設定されたインターフェース・パーサ、契約状態を経済的意味へ変換するための事前設定評価ロジック、信用や標準判定のルールを明確に定義することが必要で、さらに意思決定分岐のすべてに対して（アルゴリズム自体がどれほど動的で柔軟であっても）ハードコードされたルールを書き込む必要があります。想定されたパターンに合致しないケースが出現した場合、システムはそのシーンをスキップするか、あるいは単純に実行が破綻します。システムは見知らぬ状況について推論判断できず、「現在の状況が既知のテンプレートに一致するかどうか」を検証することしかできません。
この「消化ガチョウ」のような機械的自動装置は、迫真の挙動を模倣できますが、各動作は事前に設定されたものです。（『サイエンティフィック・アメリカン』、1899年1月）
従来のアルゴリズムは、新しい貸借市場をスキャンする際、見慣れたイベントを発する、または既知の工場（ファクトリー）パターンに一致する、デプロイ済みコントラクトを識別できます。しかし、もし「見慣れない」インターフェースを備えた新しい貸借の基盤コンポーネントが現れた場合、システムはそれを評価できません。コントラクトを人手で点検し、その動作メカニズムを理解し、それが機会プールに含まれるかを判断し、統合ロジックを書く必要があります。これらの手順が完了して初めて、アルゴリズムはその対象と相互作用できます。人間が解釈し、アルゴリズムが実行します。そして、基盤モデルに基づくエージェントシステムは、この境界を破ります。これらは、習得した推論能力によって次を実現できます：
曖昧または明確に指定されていない目標の解釈。たとえば「最大化するが、過度なリスクは避ける」といった指示は解釈が必要です。どの程度が過度なのか？ 収益とリスクはどうバランスすべきか？ 従来のアルゴリズムは事前にこれら条件を厳密に定義する必要がありますが、基盤モデルは意図を解釈し、判断を行い、そしてフィードバックに基づいて自己の理解を最適化できます。
新しいインターフェースへの汎化適応。エージェントは、見知らぬコントラクトのコードを読み、ドキュメントを解析し、または未見のアプリケーション・バイナリ・インターフェース（ABI）を確認し、このシステムの経済機能を推断できます。各種プロトコルごとに、あらかじめパーサを構築する必要がありません。現時点ではこの能力はまだ不完全で、エージェントは誤判定する可能性がありますが、それでも開発段階で想定されていなかったシステムとの相互作用を試みることができます。
不確実性の下で、信頼性と規範性を推論する。信頼のシグナルが曖昧または不完全な場合、基盤モデルは二値ルールを単純に当てはめるのではなく、確率的に判断を重み付けできます。このスマートコントラクトは公式の正規品か？ 既存の証拠の下で、このトークンは大部分が合法である可能性が高いか？ 従来のアルゴリズムには「ルールがある」か「ルールがない」という2状態しかありませんが、エージェントは確信度に基づいて推論できます。
誤りを解釈し、自適応的に調整する。予期しない状況が発生した場合（たとえば取引のリバート、出力が期待と一致しない、シミュレーションと実行の間で状態が変化する等）、エージェントは問題の原因を推断し、どのように対応するかを決定できます。対照的に、従来のアルゴリズムは例外捕捉コードブロックを実行するだけで、例外に対して分岐処理をするに留まり、例外を解釈することはできません。
これらの能力は実在しますが、現時点ではまだ不完全です。基盤モデルは幻覚を生み、情報を誤読し、自信ありげに見える誤った判断を下すことがあります。対抗的で資金が関与する環境（すなわちコードを制御できる、または資産を受け取れる状況）では、「未設定システムとの相互作用を試みる」ことが、そのまま直接損失を意味する可能性があります。本稿の核心的主張は、エージェントが現在その機能を信頼性高く完遂できる、ということではありません。そうではなく、それらは従来のシステムでは実現できなかった方法で試行できる可能性があり、そして将来の基盤インフラによって、これらの試みがより安全でより信頼できるものになることが期待される、という点にあります。両者を絶対的な分類ではなく「連続体」として捉えると理解しやすくなります。部分的な従来システムは学習型推論を取り込み、部分的なエージェントも重要な経路においてハードコードされたルールに依存することがあり得ます。両者の違いは方向性であり、二値的対立ではありません。エージェントシステムは、より多くの解釈・評価・自適応の作業を実行時推論に移し、開発段階での事前設定に留めません。これは前述の障害論とも密接に関係しています。なぜなら、エージェントが試みようとしているのがまさに、従来のアルゴリズムが完全に回避してきたことだからです。従来のアルゴリズムは、発見コストを回避するために開発段階で人手によりコントラクト集合をふるいにかけ、運用者が維持するホワイトリストでコントロール層のコストを回避し、既知のプロトコルにはあらかじめパーサを用意することでデータコストを回避し、想定される安全範囲内で実行することで実行コストを回避します。人工が事前に、意味・信頼・戦略層での作業を完了させ、アルゴリズムは境界の中でのみ実行します。オンチェーン・エージェント操作フローの初期バージョンは、このモードを継承する可能性がありますが、その核心ロジックは「発見、信頼、戦略評価を、開発段階で事前設定するのではなく実行時推論に移す」ことにあります。
エージェントは、見知らぬ機会を発見し評価し、ハードコードされたルールなしにコントラクトの規範性を判断し、事前設定されたパーサなしに異種状態を解析し、また曖昧になり得る目標に対して戦略を実行しようとします。そしてまさに、そのような段階で基盤インフラの弱点が顕在化します。障害が存在する理由は、エージェントがアルゴリズムと同じことをしているのに、より難しいからではありません。むしろ、それらが完全に異なることを試みているからです。つまり：開かれた動的な解釈の振る舞い空間の中で実行するのに対し、閉じた事前に統合された固定空間で動くのではないからです。
摩擦の所在
構造的に見ると、この矛盾はブロックチェーンのコンセンサスの欠陥に由来するものではありません。むしろ、それを構築するための全体的なインタラクション・スタックの進化の仕方に起因します。
ブロックチェーンは、決定論的な状態遷移、最終状態に対するコンセンサス、そして最終的な確定性を保証します。しかし、それはプロトコル層で経済的な解釈、意図の検証、あるいは目標の追跡を符号化しません。これらの責務はこれまで、フロントエンド、ウォレット、インデクサ、その他のオフチェーン協調レイヤーが担っており、プロセスの中には常に人手が介在しています。
主流のインタラクション・モードもまた、この設計を反映しています。たとえ専門家であっても同様です。一般ユーザーは、UI上で状態を解釈し、画面上で操作を選び、ウォレットで取引に署名しますが、形式的に結果を検証しているわけではありません。アルゴリズム取引の機関は実行の自動化を実現していますが、それでもプロトコル集合の人手によるふるい分け、例外の監査、そしてインターフェース変更時の統合ロジック更新に依存しています。二つのシーンでは、プロトコルは実行の正しさだけを保証し、意図の解釈、例外処理、新機会の適応は人手で行われています。
エージェントシステムは、この分業を圧縮し、場合によっては消し去ってしまいます。エージェントは、経済的意味を持つ状態をプログラム的に再構築し、目標が前進するかを評価し、単純な取引をオンチェーンに乗せるだけではなく結果を検証しなければなりません。これらの負担は、ブロックチェーン上では特に際立ちます。なぜなら、エージェントは開かれた対抗的で急速に変化する環境で動作するからです。新しいコントラクト、資産、実行パスは、分散化された監査なしに現れ得ます。プロトコルは取引が正しく実行されることは保証しますが、経済状態が解釈しやすいこと、コントラクトが公式の正規品であること、実行パスがユーザーの意図に一致していること、あるいは関連する機会がプログラム的に発見され得ることまでは保証しません。
以降の章では、エージェントの実行ループの各段階に即して、この種の障害を分析します。すなわち、既存コントラクトと機会の発見、合法性の検証、経済的意味を持つ状態の取得、そして目標に従った実行です。
発見コスト
発見コストが生じるのは、分散型金融（DeFi）の行動空間が、無許可で開かれた環境の中で継続的に拡張し、それに伴い関連性と合法性を、人手でチェーン上のソーシャル、マーケット、ツール層によってフィルタリングする必要があるためです。新しいプロトコルは公告と研究発表によって知らされるだけでなく、フロントエンド統合、トークンリスト、分析プラットフォーム、流動性形成などのフィルタ層によっても選別されます。長い年月を経て、これらのシグナルは、行動空間の中で経済価値があり、かつ十分に信用できる部分を識別するための、一連の実用的な判断基準となることが多いものの、このプロセスはしばしば非公式で不均衡であり、また一部は第三者と人手のふるい分けに依存しています。
エージェントはフィルタリングされたデータや信頼シグナルを取得できますが、人間がそれらを解釈する際の自然な近道は持っていません。チェーン上の視点から見ると、すでにデプロイされたすべてのコントラクトの可発見性は平等です。合法なプロトコル、悪意あるフォーク、テスト用デプロイ、放棄されたプロジェクトも、すべて呼び出し可能なバイトコードとして存在します。オンチェーンは、どれが重要で、どれが安全かをラベル付けしません。
チェーン上の視点では、すでにデプロイされたすべてのコントラクトは同等の可発見性を持ちます。合法なプロトコル、悪意あるフォーク・コントラクト、テスト用デプロイ・コントラクト、放棄されたプロジェクトも、すべて呼び出し可能なバイトコードとして提示されます。
そのため、エージェントは自前で発見メカニズムを構築しなければなりません。デプロイ・イベントをスキャンし、インターフェースのパターンを識別し、ファクトリー・コントラクト（他のコントラクトをプログラム的にデプロイするコントラクト）を追跡し、流動性形成を監視して、どのコントラクトを意思決定範囲に含めるべきかを判断します。このプロセスは単にコントラクトを探すだけではなく、それがエージェントの行動空間に入る価値があるかを判断することでもあります。
候補となるコントラクトを識別することは第一歩です。コントラクトは、初期の発見フィルタを通過した後、次節で述べる規範性と真実性の検証を経る必要があります。エージェントは、発見したコントラクトが自ら主張する内容と一致していることを確認できなければ、意思決定空間に取り込むことはできません。
戦略限定型の発見は、オープン型の発見とは異なる
発見コストは、新規デプロイを検出することそのものを意味するわけではありません。成熟したアルゴリズムシステムなら、自身の戦略範囲内でそれを行うことがすでに可能です。たとえばUniswapのファクトリー・イベントを監視して新しい流動性プールを自動的に組み込む探索者は、「動的発見」を実行しています。障害は、さらに上位の二つの層で発生します。発見したコントラクトが合法かどうか（次節で扱う規範性の問題）、そしてそれがオープン型の目標に役立つのか、それとも単に事前に想定された戦略タイプに適合するだけなのか、という問題です。
探索者の発見ロジックは戦略に密接に結びついています。戦略が事前に定義されているため、どのインターフェース・パターンを探すべきかを知っているのです。一方、「最適なリスク調整後の機会」など、より広範なタスクを担うエージェントは、戦略に派生するフィルタにだけ頼るわけにはいきません。エージェントは、目標そのものに照らして、新たに出会った機会を評価する必要があります。これには未知のインターフェースの解析、経済機能の推定、そしてその機会が意思決定空間に入るべきかの判断が要ります。この部分は一般的な自律性の問題ですが、ブロックチェーンは難易度をさらに引き上げます。未知のコードは直接実行可能で資金を抱えており、しかもプロトコルのネイティブなシグナルだけでは分類できないためです。
コントロール層の摩擦
コントロール層のコストが生じるのは、アイデンティティと合法性が通常、プロトコル外部でのフィルタリング、ガバナンス、ドキュメント、インターフェース、運営者の判断などによって共同で確定されるためです。現状の多くのワークフローでは、人手がその判断プロセスの重要な部分を占めています。ブロックチェーンは決定論的な実行と最終的な確定性を保証しますが、呼び出し者が目標コントラクトと相互作用していることを保証しません。意図の判断は、ソーシャル文脈、ウェブサイト、そして人手によるフィルタリングに外注されています。
現在のプロセスでは、人間はウェブの信頼層を非公式な検証ツールとして利用しています。DeFiLlamaのような集約プラットフォームや、プロジェクトが認証したソーシャルアカウントから公式ドメインを見つけ、そのサイトを「人間が理解する概念」と「コントラクトアドレス」の間の公式な対応付けとして扱います。続いてフロントエンドは、有効な真実のソースを一連の形で符号化し、どのアドレスが公式であるか、どのトークン表現を使うか、どの入口が安全かを示します。
1789年のメカニカル・トルコ人（Mechanical Turk）はチェスを指す機械で、見た目は自律運転に見えますが、実際には隠された人間の操作員に依存しています。（ハンボルト大学図書館）
エージェントはデフォルトで、ソーシャル文脈によってブランドの標識、認証されたソーシャル信号、あるいは「公式性」を解釈しません。私たちはエージェントに、これらの信号に由来するフィルタ後の入力を与えることはできます。しかし、それらを安定して利用でき、機械が実行可能な信頼仮説へ変換するには、明確なレジストリ、ポリシールール、または検証ロジックが必要です。運営者はエージェントに、厳選されたホワイトリスト、認証済みアドレス、信頼戦略を設定できます。問題は、ソーシャル文脈をまったく取得できないことではなく、動的に拡張する行動空間の中で、これらの防護バリアを継続的に維持するには過大な運用負担がかかり、さらにそれらのバリアが欠落したり不十分になったりすると、エージェントには人間が無意識に使うバックアップの検証メカニズムがないことにあります。
この信頼判定能力の不足が引き起こす実際の帰結は、オンチェーンのエージェント駆動システムでもすでに現れています。YouTubeの暗号化ブロガー兼インフルエンサーであるOrangieは、エージェントが資金をハニーポットコントラクトへ預けてしまったケースがありました。別の事例では、Lobstar Wildeという名のエージェントが状態またはコンテキストの不具合により、アドレス状態を誤って解釈し、大量のトークン残高をオンラインの「乞食アドレス」に送ってしまいました。これらのケースは本稿の中核的な論拠ではありませんが、信頼判定、状態解釈、実行戦略におけるミスが、直接的に資金損失へつながることを直感的に示しています。
公式コントラクト識別は、プロトコルネイティブ機能ではない
問題は、コントラクトが発見しにくいことではなく、オンチェーン上には一般に「これはアプリXの公式コントラクトである」というプロトコルネイティブの概念が存在しないことにあります。この欠如は、無許可システムの特性である面があるのは確かで、設計上の手落ちというよりはその結果でもありますが、それでも自律的システムにとって協調上の難題になります。この問題は、弱い規範アイデンティティのオープンシステム・アーキテクチャ特性に起因する部分があり、またレジストリ、標準、信頼分配メカニズムがまだ成熟していないことにも起因します。もしエージェントがAave v3とやり取りしたいなら、どのアドレスが公式の正規品であるか（流動性プール、設定器、データ提供者など）を判定し、さらにそれらのアドレスが不変コントラクトなのか、プロキシで代理・アップグレード可能なコントラクトなのか、あるいはガバナンス提案の変更待ちで実行段階にある状態なのかを判断する必要があります。
人間はドキュメント、フロントエンドUI、そしてソーシャルメディアでこの問題を解決しますが、エージェントは次の情報を照合して判定しなければなりません：
代理モードと実装コントラクトの指し先
管理権限とタイムロック・コントラクト
ガバナンス制御下のパラメータ更新モジュール
既知のデプロイ済みコントラクト間のバイトコード / アプリケーション・バイナリ・インターフェース（ABI）一致度
公式レジストリがない場合、「公式性」は推論問題になります。つまりエージェントはコントラクトアドレスを静的な設定として扱えません。それらは、常に検証済みの厳選ホワイトリストを維持するか、実行時に代理を照合しガバナンス監視で再推論するか、あるいは廃止、攻撃、偽造コントラクトとの相互作用に関するリスクを引き受ける必要があります。従来のソフトウェアや市場インフラでは、サービスのアイデンティティは通常、機関が維持するネーミングスペース、証明書、アクセス制御によってアンカーされています。対照的に、オンチェーンでは、あるコントラクトが呼び出し可能で機能が動いているとしても、呼び出し側の視点からは、経済あるいはビジネスのレイヤーでは公式正規品ではない可能性があります。
トークンの真正性とメタデータの問題は、本質的に同じ
トークンは自己説明のような情報を持っているように見えますが、そのメタデータには権威性がなく、単にコントラクトコードが返すバイトデータに過ぎません。典型例はWETH（ラップドETH）です。広く使われているWETHコントラクトでは、明確に次が定義されています：
これらの情報はアイデンティティを示しているように見えますが、実際には違います。どんなコントラクトでも次の内容を返せます：
symbol() = “WETH”
decimals() = 18
name() = “Wrapped Ether”
そして、完全に同じERC-20トークン標準インターフェースを実装できます。name()、symbol()、decimals()は単なる公開の読み取り専用関数で、返される内容はデプロイヤーによって設定されるだけです。実際には、イーサリアム上には近200種類のトークンが存在し、名称はすべて「Wrapped Ether」、シンボルはすべて「WETH」、小数の精度もすべて18桁です。CoinGeckoやEtherscanで調べなければ、どの「WETH」が公式正規品か見分けられますか？（答えはリスト中の78番目）
イーサリアム上には、名称が「Wrapped Ether」、シンボルが「WETH」のトークンが約200あります。第三者プラットフォームを使わずに、どれが正真正銘のWETHか判断できますか？
これがエージェントが置かれている状況です。ブロックチェーンは一意性を検証せず、いかなるレジストリとも照合せず、それにも無関心です。あなたは今日、500個のコントラクトをデプロイし、それらがまったく同じメタデータを返すようにすることもできます。オンチェーンには、経験則による判断方法もいくつかあります（たとえばETH残高と総供給量の照合、主要な分散型取引所の流動性深度の照会、貸借プロトコルに担保として列挙されているかの確認など）がありますが、どれも絶対的で確実な証明を提供するものではありません。どの方法も、しきい値の仮定に依存するか（数十億規模のペア流動性を誰も偽造できないはずだ、など）、あるいは再帰的に、まず別のコントラクトの規範性を検証する必要があるかのどちらかです。
迷路のように、チェーン上で「本当の」経路を識別するには外部の案内が必要であり、標準的なシグナルは提供されていません。（バーミンガム博物館・美術館）
だからこそ、トークンリストとレジストリがチェーン外のフィルタリング層として存在します。それらは「WETH」という概念を特定のアドレスにマッピングする仕組みを提供し、同じ理由でウォレットやフロントエンドはホワイトリストを維持するか、信頼できる集約器に依存しています。エージェントにとっての核心的な問題は、メタデータが信頼できないことだけではありません。むしろ、規範的アイデンティティは通常、ソーシャルや機関のレイヤーで確立され、プロトコルネイティブではないという点にあります。オンチェーンで信頼できる唯一の識別子はコントラクトアドレスですが、人間が理解できる意図（例：「USDCに交換」）を正しいアドレスへマッピングするには、依然としてプロトコルネイティブではないフィルタ、レジストリ、ホワイトリスト、あるいはその他の信頼層への大きな依存が必要です。
データの摩擦
複数のDeFiプロトコル間で最適化するエージェントは、それぞれの機会を、経済的対象として統一抽象化する必要があります。たとえば利回り、流動性の深さ、リスクパラメータ、手数料構造、オラクルの出所などです。ある意味では、これは一般的なシステム統合問題です。しかしブロックチェーン上では、プロトコルの異種性、直接的な資金リスク、複数呼び出しの状態をつなぎ合わせる必要、そして下層に統一された経済的schemaが欠けていることにより、この負担は大幅に増幅されます。そして、これらこそが機会の比較、シミュレーション設定、リスク監視に必要な基礎情報です。
ブロックチェーンはプロトコル層では、通常、標準化された経済的対象を公開せず、公開されるのはストレージスロット、イベントログ、関数の戻り値だけです。経済的対象はそこから推導するか、再構築しなければなりません。プロトコルはコントラクト呼び出しが正しい状態値を返すことは保証しますが、その値が明確に理解可能な経済概念に対応していることは保証しません。また、同一概念が異なるプロトコル間で一貫したインターフェースで取得できることも保証しません。
そのため、市場、ポジション、ヘルス係数といった抽象概念は、プロトコルネイティブのコンポーネントではなく、インデクサ、分析プラットフォーム、フロントエンド、APIによってチェーン外で再構築され、異種プロトコル状態を利用可能な抽象層に正規化しているものに過ぎません。人間のユーザーは通常、この正規化された層のデータしか見ません。エージェントも利用できますが、その分サードパーティのschema、遅延、そして信頼仮説を引き継ぎます。さもなければ、エージェント自身がそれらの抽象ロジックを再構築する必要があります。
この問題は、各種プロトコルにおいてさらに悪化します。金庫（バンク）シェアの価格、貸借市場の担保率、DEXプールの流動性深度、担保コントラクトの報酬率などはいずれも経済的意味のある基礎指標ですが、標準化されたインターフェースで公開されるものはありません。各プロトコル体系には独自の読み取り方法、構造体形式、単位の約束があります。同じカテゴリであっても実装は各々異なります。
貸借市場：読み取りの断片化が典型的に表れる例
貸借市場は、この問題をはっきりと示します。経済概念は一般に似ていて汎用的です。たとえば供給と借入の流動性、利率、担保係数、上限（リミット）、清算の閾値などです。しかしデータの読み取り経路はまったく異なります。
Aave v3を例にすると、市場の列挙と、準備資産（reserves）状態の読み取りは別ステップで行われます。典型的なフローは次の通りです：
以下の方法で準備資産を列挙します
この関数はトークンアドレス配列を返します。
各資産について、以下の方法で流動性と利率の基礎データを取得します：
この呼び出しは構造体を返し、単回で流動性総量、利率インデックス、設定識別子などを含むデータを取得できます。たとえば：
それとは反対に、Compound v3（Comet）では、1つのデプロイにつき単一の市場（たとえばUSDC、USDT、ETHなど）に対応し、統一された準備金（reserves）構造体は存在しません。そのため、複数回の関数呼び出しを通じて、完全な市場スナップショットのデータを組み合わせる必要があります：
基礎利用率
合計
利率
担保資産の配置
グローバル設定パラメータ
各呼び出しは、経済状態の異なる断片だけを返します。「市場」は一級市民（first-class）オブジェクトではなく、呼び出し側が自ら組み立てる推論的な構造です。
エージェントの観点では、これら二つのプロトコルはいずれも貸借市場に属します。しかし統合の観点では、両者は完全に異なるデータ取得システムです。次のような共通データ構造が存在するわけではありません：
逆に、エージェントは異なるプロトコルごとに異なる資産列挙手法を採用し、複数回の呼び出しで状態データを連結し、計量単位と換算ルールを統一し、そして推定値と直接公開された基礎データとの差異を調整しなければなりません。
碎片化が遅延と一貫性リスクを生む
構造的な不統一に加えて、このような断片化は遅延と一貫性リスクも引き起こします。経済状態が単一のアトミックな市場オブジェクトとして公開されないため、エージェントは複数のコントラクトへ複数回の遠隔手続き呼び出し（RPC）を行い、状態スナップショットを再構築する必要があります。呼び出しが1回増えるごとに、遅延が増し、インターフェースのレート制限に抵触する確率が上がり、さらにブロック不一致のリスクも高まります。市場の変動環境では、供給利率の計算が完了した時点で資金利用率がすでに変わっている可能性があります。ブロック高を明確に固定しない限り、設定パラメータと流動性総量が同じブロック由来でない可能性があります。人間のユーザーは、フロントエンドのキャッシュ層と集約バックエンドによってこの問題を暗黙に緩和しますが、原始的なRPCインターフェースを直接呼び出すエージェントは、データ同期、バッチリクエスト、時間的一致性の問題を明示的に扱う必要があります。したがって、非標準化されたデータ取得は統合上の不便だけでなく、性能、同期メカニズム、そして実行の正確性に対する制約でもあります。
統一された経済データ取得の規格が欠けていることは、たとえ異なるプロトコルがほぼ同じ金融の基礎機能を実装していたとしても、その状態の露出方式が依然としてコントラクト固有であり、かつ組み合わせロジックに依存していることを意味します。この構造の違いこそが、データの摩擦の核心原因です。
潜在的なデータフローのミスマッチ
ブロックチェーン上の経済状態へのアクセスは本質的にプルモデルです。たとえ実行シグナルがストリーミングでプッシュされ得るとしてもです。外部システムは、必要な状態をノードへ能動的に問い合わせる必要があり、継続的で構造化された更新を受け取るわけではありません。このパターンは、ブロックチェーンの中核機能――必要に応じた検証であり、アプリケーションレベルで継続的な状態ビューを維持することではない――を反映しています。
オンチェーンにもプッシュモデルの基盤コンポーネントは存在します。WebSocketのサブスクライビングによって新しいブロックやイベントログをリアルタイムにプッシュできますが、それらは大部分の経済的意味を担うストレージ状態を含みません。プロトコルが冗長にそれをログとして記録するよう選択している場合を除きます。エージェントは、オンチェーンのサブスクライビングだけで、貸借市場の利用率、プールの準備金量、あるいはポジションのヘルス係数を直接取得できません。これらの値はコントラクトのストレージ空間に保存されており、多くのプロトコルは下流利用者向けに、ストレージの変更をネイティブにプッシュするメカニズムを提供していません。現時点で最も現実的な方法は、新しいブロックヘッダを購読し、各ブロックごとにストレージ状態を再問い合わせることです。たとえストリーミングのイベントをトリガーにしても、状態アクセスの本質はプルモデルのままです。ログはデータが変化する可能性を示すだけで、最終的な経済状態を符号化してはいません。その状態を再構築するには、明示的に読み取り、そして履歴状態へアクセスする必要があります。
エージェントシステムは、むしろ逆方向のデータフローの方が適しています。エージェントは何百ものコントラクトの状態変化をポーリングする必要がなく、構造化された、事前計算済みの状態更新を受け取り、それをその実行環境へ直接プッシュできます（例：更新後の利用率、ヘルス係数、ポジションの変動）。プッシュ型アーキテクチャは、冗長な問い合わせを減らし、状態変化がエージェントに認識されるまでの遅延を抑え、中間層が状態をエージェントが理解し実行可能な意味の明確な更新としてカプセル化できるようにします。エージェントに、原始ストレージから意味を自力で解釈させるのではなく。
ただ、このパターンへの転換は容易ではありません。サブスクライブする基盤インフラ、関連性をフィルタするロジック、そしてストレージ変動をエージェントが実行可能な経済イベント仕様へ変換することが必要です。しかし、エージェントが断続的な問い合わせ側ではなく、常時オンラインの参加者になっていくにつれて、プルモデルの非効率（レート制限、同期コスト、異なるエージェント間での重複問い合わせ）がますます深刻になります。「エージェントを断続的なクライアントではなく、継続的な消費者として扱う」インフラは、自律システムの稼働方式により適しているのかもしれません。
プッシュ型の基盤インフラが本当により優れているかは、まだ結論が出ていません。全量の状態変化を流すデータフローはフィルタリング問題を生み、エージェントは依然としてどの情報が関連するかを判断する必要があるため、別の層で再びプル的なロジックが入り込むことになります。核心は、プルモデル自体が間違っているのではなく、既存アーキテクチャが設計時に「持続的に動く機械利用者」を前提にしていなかったこと、そしてエージェントが使われる規模が拡大していくにつれ、代替案を検討する価値が出てくる、という点にあります。
実行の摩擦
実行の摩擦が生じるのは、多くの現在のインタラクション層が、意図の変換、取引の審査、そして結果検証を、これまでフロントエンド、ウォレット、そして人間の監督を中核とするワークフローの中に封入しているためです。一般ユーザーの状況や主観的な意思決定の場面では、この監督は通常、人間が行います。しかし自律システムでは、これらの機能は形式化され、直接コードとして実装されなければなりません。ブロックチェーンはコントラクトロジックに基づく決定論的実行を保証できますが、取引がユーザーの意図に合致すること、リスク制約に従っていること、あるいは期待する経済結果を実現していることまでは保証できません。既存のプロセスにおいては、フロントエンドUIと人間がこの欠けている部分を補っています。
フロントエンドは操作シーケンス（スワップ、許可、預入、貸借など）をオーケストレーションし、ウォレットは最後の「審査して送信する」というチェックポイントを提供します。ユーザーや操作者は、通常最後のステップで非公式に戦略判断を行います。多くの場合、情報が不完全な状態で、取引が安全かどうか、見積もり結果が許容できるかどうかを判断します。取引が失敗したり想定外の結果になったりすると、ユーザーは再試行し、スリッページを調整し、ルートを変更するか、あるいは操作をやめます。エージェントシステムは、この実行ループから人間を取り除くため、機械は次の3種類の人間機能を機械ネイティブロジックで置き換えなければなりません：
意図コンパイル。たとえば「リスク調整後で最も収益性の高い経路へ、私のステーブルコインを配分する」といった人間の目標は、具体的な行動計画にコンパイルされる必要があります。どのプロトコルを使うか、どの市場を使うか、どのトークン経路を通すか、操作規模、承認方法、そして実行順序を決めます。人間にとってはこのプロセスはフロントエンドに暗黙により完了しますが、エージェントにとっては形式化して実装しなければなりません。
戦略実行。「取引を送信」をクリックすることは単なる署名行為ではなく、取引が制約に合っているかどうかの暗黙の検証でもあります。スリッページ許容度、レバレッジ上限、最低ヘルス係数、ホワイトリストに載ったコントラクト、あるいは「アップグレード可能コントラクトを禁止」といった要素です。エージェントは、明示された戦略制約を機械が検証可能なルールへと符号化する必要があります：
実行システムは、取引をブロードキャストする前に、実行しようとしている呼び出し関係図がこれらのルールに適合しているかを検証しなければなりません。
このため完成度の検証には、より高い要求が課されます。単に取引がオンチェーンに載ったことを確認するだけでは足りません。意図を中心に据えたアーキテクチャは、部分的な解決策を提供し得ます。つまり、「どう実行するか」に関する負担を、エージェントから専門のソルバーへより多く移すことができます。エージェントは原始の呼び出しデータを送信するのではなく、署名済みの実行意図をブロードキャストし、結果に基づく制約条件を指定します。ソルバーまたはプロトコル層のメカニズムは、これらの制約を満たす必要があり、そうして初めて実行が有効とみなされます。
マルチステップ・ワークフローと故障モード
分散型金融（DeFi）の実行プロセスの大部分は、本質的にマルチステップです。収益配分（リターン配置）の操作は、承認→スワップ→預入→貸借→担保（質押）と順に実行する必要がある場合があります。その一部は独立した取引で、別のものはバッチ呼び出しやルーティング・コントラクトによってパッケージ化して実行できます。人間はプロセスが完全に完了していなくても、画面でそのまま操作を続けられるため許容できます。一方、エージェントは決定論的なフローオーケストレーションが必要です。どのステップでも失敗した場合、リトライするのか、別のパスへ切り替えるのか、操作をロールバックするのか、あるいは実行を停止するのかを決めなければなりません。
これにより、人間の操作フローでは通常覆い隠されがちな新しい故障モードが生まれます：
意思決定とオンチェーンの間の状態ドリフト：シミュレーションと実際のチェーン実行の間に、金利、利用率、流動性が変化する可能性があります。人間はこの変動を受け入れられますが、エージェントは許容範囲を設定し、厳密に実行しなければなりません。
非アトミック実行と部分的な約定：一部の操作は複数の取引にまたがって実行される場合、または期待していた結果の一部しか生まれない場合があります。エージェントは中間状態を追跡し、最終状態が目標に合致していることを確認しなければなりません。
許可額（許容量）と審査のリスク：人間は画面操作の慣習として承認署名を行いますが、エージェントは承認範囲（上限額、支出元、期限）を安全戦略の中で推論し、単に画面ステップとして扱うのではなくなければなりません。
パス選択と暗黙の実行コスト：人間はルーティングツールとUIのデフォルト設定に依存しますが、エージェントはスリッページ、MEV（マイナー抽出可能価値）のリスク、Gas費用、価格インパクトを目的関数の中でモデリングしなければなりません。
実行：機械ネイティブのコントロール問題
実行の摩擦に関する核心的な観点は次の通りです。DeFiのインタラクション層は、人間のウォレット署名を最終の制御レイヤーとして置いています。現在、意図の検証、リスク許容度の判断、そして非公式の「妥当に見えるかどうか」のチェックは、この一歩に集中しています。人間の関与を取り除くと、実行は制御問題になります。エージェントは目標を操作チェーンへ変換し、戦略制約を自動実行し、不確実性の中で結果を検証する必要があります。この課題は多くの自律システムに存在しますが、ブロックチェーン環境では特に厳しいです。なぜなら、実行は直接資金に関わり、組み合わせ可能な形で未知のコントラクトも呼び出され得て、かつ対抗的な状態変化に直面するからです。人間は経験で意思決定し、試行錯誤で誤りを修正します。一方エージェントは、機械速度で同類の作業をプログラム的に完了させる必要があり、そしてしばしば動的に変化する操作空間に直面します。したがって、エージェントは「ただ取引を送るだけでよい」という見方は、難しさを大きく見誤っています。取引の提出自体は簡単な部分であり、本当に欠けているのはUIと人間が担っていた仕事のすべてです。すなわち、意図のコンパイル、安全性の担保、そして目標達成度の検証です。
結論
ブロックチェーンは当初の設計で、自律的エージェントに必要な意味層と協調層をネイティブに提供していません。それは対抗的な環境において決定論的実行と状態遷移のコンセンサスを保証することを目的にしていました。この上に発展してきたインタラクション層は、常に人間ユーザーを中心に据えてきました。UIで状態を解釈し、フロントエンドで操作を選択し、人間が検証して結果を確かめる、という形です。
エージェントシステムは、このアーキテクチャを覆します。彼らは、人間の解釈者、承認者、検証者をプロセスから取り除き、これらの機能を機械ネイティブ化することを要求します。この転換は、発見、信頼判定、データ取得、実行オーケストレーションの4つの次元で構造的な摩擦として現れます。これらの摩擦は、実行が不可能だから生じるのではありません。むしろ、多くの状況で、ブロックチェーン周辺のインフラが依然として「人間が状態を解釈し、取引を提出する」段階をデフォルトで前提としているために生じるのです。
これらのギャップを埋めるには、複数の技術スタックにわたって新しいインフラを構築する必要があるかもしれません。プロトコルをまたぐ経済状態を、機械が読み取れる仕様へ正規化するミドルウェア。ポジション、ヘルス係数、機会集合などの意味的基礎コンポーネントを、原始ストレージデータではなく公開するインデクササービスやRPC拡張。公式コントラクトのマッピングや、トークンの真正性検証を提供するレジストリ。そして、戦略制約を符号化し、マルチステップのワークフローを処理し、目標達成度をプログラム化して検証できる実行フレームワークです。一部のギャップは無許可システムの構造的特性に由来します。すなわち、オープンなデプロイ、弱い規範アイデンティティ、そして異種のインターフェースです。別の部分は、既存ツール、標準、そしてインセンティブ設計の制約によるものです。エージェントの利用規模が拡大し、自律システムの統合利便性を高めるためにプロトコルが競争最適化するにつれ、これらの問題は緩和される可能性があります。
自律システムが資金を管理し、戦略を実行し、そしてオンチェーン上のアプリと直接相互作用し始めるにつれて、現在のインタラクション層に内蔵されたアーキテクチャ仮定がますます際立ってきます。本稿で述べた摩擦の大部分は、ブロックチェーンのツールとインタラクション・モードが人間の仲介ワークフローを中心に発展してきたことに起因します。部分的には無許可システムの開放性、異種性、そして対抗環境における自然な帰結です。さらに一部は、複雑な環境下で自律システムが一般的に直面する共通問題です。
核心的な課題は、エージェントに取引の署名をさせることではありません。信頼できる経路を用意し、現状の「原始のブロックチェーン状態」と「実際の操作」の間で、ソフトウェアと人間の判断によって共同で行われてきた意味、信頼、戦略に関する機能をエージェントのために提供することです。