オンチェーンAIエージェントの3層構造と知覚レイヤーの落とし穴

ブロックチェーン上で動作するAIエージェントが「正しい判断をしているように見えて、実際には3ブロック前の状態に基づいて動いている」という問題がある。Ethereumでは3ブロックが約36秒に相当し、ArbitrumやBaseのような高速L2（Layer 2、メインチェーンの処理をオフロードして高速化する第2層ネットワーク）では1ブロックが1秒未満だ。この数値が示す意味は小さくない。

オンチェーンAIエージェントを構成する3つの層

オンチェーンAIエージェント（ブロックチェーン上のスマートコントラクトと連携して自律的に動作するAIシステム）は、単一の塊ではなく3つの層に分解できる。

1つ目は「知覚層（Perception Layer）」だ。メンプール（mempool、まだブロックに取り込まれていない保留中のトランザクションのプール）の監視、イベントログの購読、価格フィードの取得など、チェーンの現在状態を読み取る役割を担う。2つ目は「判断層（Decision Layer）」で、LLM（大規模言語モデル）が知覚層から受け取った構造化データを元に次のアクションを決定する。3つ目は「実行層（Execution Layer）」で、実際にトランザクションに署名してブロードキャストし、nonce管理やリバート処理を行う。

シード記事が指摘する核心は「障害のほとんどは実行層でも判断層でもなく、知覚層に起因する」という点だ。スマートコントラクトのバグでも、プロンプトの設計ミスでもない。エージェントに渡されるデータパイプラインの陳腐化が、静かにシステムを壊す。

ポーリングとストリーミングの本質的な違い

知覚層の実装として最も手軽なのは、eth_getLogs や eth_call を使った定期ポーリング（一定間隔でRPCノードに問い合わせを繰り返す方式）だ。しかしこのアプローチには構造的な限界がある。

// ポーリング方式の典型的な実装
const price = await provider.call({
  to: POOL_ADDRESS,
  data: getPriceCalldata(),
});
// この呼び出し時点で、すでに3〜5ブロック遅れている可能性がある

ポーリング間隔が2秒だとすると、Arbitrumのような高速L2では2〜5ブロック分の状態変化が見えていないことになる。DEX（分散型取引所）のアービトラージエージェントがこの状態で動くと、すでに他のボットに刈り取られた価格差を「まだある」と誤認して取引を実行する。スリッページ（想定価格と実際の約定価格のずれ）が許容範囲を超えたり、サンドイッチ攻撃（攻撃者がユーザーのトランザクションを前後に挟んで利益を抜く手法）にさらされたりするリスクが高まる。

これを解決するのがイベントストリーミングだ。WebSocketやServer-Sent Events（SSE）を使ってノードと持続的な接続を保ち、コントラクトがイベントをemitした瞬間にエージェントへ届ける方式は、ポーリングと比べて知覚の遅延を大幅に削減できる。Ethereumエコシステムでは The Graph や Alchemy Subgraphs、あるいは自前の event indexer を立ててストリームを購読する構成が実用的な選択肢になる。

LLM推論レイテンシと知覚鮮度のトレードオフ

判断層にLLMを置く場合、推論時間（300〜800ms程度）が知覚データの「賞味期限」を圧迫する。知覚層が状態を取得した時点からすでに500ms経過していれば、LLMが推論を終えて実行層へ命令を渡す頃には合計1秒以上が経過していることになる。

この問題はABIエンコーディングやウォレット署名フローとは別次元にある。LLMへ渡すデータを「生のhex文字列」ではなく「構造化・型付き済みのJSON」にすることで、推論前のパース処理を省き実質的なレイテンシを削ることができる。たとえばERC-20のTransferイベントであれば、raw logをデコードした上で {from, to, amount, blockNumber, timestamp} の形で渡す設計だ。生データをそのまま流すと、LLMの推論ステップの一部がデータ解釈に費やされ、判断の質も速度も下がる。

メンプールの可視性も重要な要素だ。清算監視（liquidation monitoring）や意図ベースのワークフロー（ユーザーの意図を受け取ってエージェントが最適なパスを探す仕組み）では、トランザクションがブロックに取り込まれた時点ではすでに対応が遅い。メンプールの段階でデータをエージェントに流すことで、ブロック確定前に判断を始められる。

フロントエンド・バックエンド開発者が得られる視点

オンチェーンエージェントは特殊に見えるが、知覚層の設計課題はリアルタイムWebアプリケーションが長年直面してきた問題と構造的に同じだ。

ポーリング vs. WebSocket/SSE のトレードオフ
データパイプラインの遅延がUI表示や意思決定に与える影響
構造化データとして渡すことで下流処理のコストを削る設計

ReactやNext.jsでリアルタイムダッシュボードを作る際にSWRのポーリングからWebSocketに切り替える判断と、オンチェーンエージェントの知覚層をポーリングからストリームに切り替える判断は、同じ原理に根ざしている。ブロックチェーン固有の概念（メンプール、nonce、リバート）は確かに存在するが、データの鮮度と処理レイテンシをどう設計するかという問いはドメインをまたいで共通する。

オンチェーンAIエージェントのアーキテクチャを評価する際には、LLMの賢さより先に「そのエージェントは何秒前の世界を見ているか」を確認するところから始めると、設計上の盲点が見えやすくなる。