--- id: 6 title: 分散型 AI スタック：Web3 と AI が協働できるかを実行レイヤーが決める理由 slug: aibitrootweb3ai date: 2026/07/28 summary: Web3 と AI の融合は、物語を重ねるだけでは済みません。本稿では AI エージェントのオンチェーンでの振る舞い、コンピュートのスケジューリング、結果の検証可能性をたどり、分散型 AI スタックにおいて実行レイヤーがしばしば最初のボトルネックになる理由と、Bitroot の関連能力がどう組み合わさるのかを説明します。 keywords: 分散型AIスタック,Web3,AIエージェント,実行レイヤー,Bitroot heroImage: /cms-media/file/1The%20Future%20of%20Decentralized%20AI%20Stack.jpg --- Web3 と AI を同じスライドに載せるのは簡単ですが、同じチェーンで動かすのは困難です。AI が求めるのはスループット、低レイテンシ、オーケストレーション可能なコンピュートであり、Web3 が求めるのは検証可能性、操作耐性、明確な責任追跡です。これらの目標は自然には両立しません。本稿はスローガンを省き、「分散型 AI スタック」をレイヤーに分解し、なぜ実行がしばしば最初に詰まるレイヤーなのかを示します。 ## AI に欠けているのはモデルではなく、信頼できる実行環境 主流の学習と推論はいまだに少数のクラウドに集中しています。問題はベンダーロックインだけではありません。呼び出し側は、どのモデルバージョンが動いたか、どの入力が使われたか、出力が改ざんされていないかを、独立に確認できることはほとんどありません。チャットアプリなら許容できるかもしれませんが、リバランスし、決済し、コントラクトを起動するエージェントにとって、ブラックボックスはシステミックリスクです。 Web3 は検証可能性を提供すべきですが、ほとんどのパブリックチェーンの実行レイヤーは依然として「人間がときどきトランザクションをクリックする」ことを前提としています。エージェントは相互依存するトランザクションをバースト的に発行するかもしれません。見積もり、注文分割、プロトコル横断呼び出し、事後照合などです。確認が遅く、コンフリクト処理が粗く、手数料が変動すると、エージェントはまれな決済を伴うオフチェーンオーケストレーションに劣化するか、輻輳下で失敗します。単一スレッド EVM がなぜ苦しいのかについては[単一スレッド EVM のボトルネック](/ja/blog/evm-single-thread-bottleneck)を参照してください。 ## スタックとして見る：五つのレイヤー、それぞれ一つの役割 「フルスタックの物語」ではなくスタックとして見ると、分散型 AI にはおおむね五つの分離された能力が必要です。 1. **決済とコントラクト実行**：状態のコンフリクトに誰が勝ち、それがどう収束するか。高速で予測可能な最終性がなければ、上層のエージェントオーケストレーションは無意味です。 2. **コンピュートのスケジューリング**：学習／推論を異種の GPU やエッジノードに振り分け、ジョブのメタデータと完了証明を記録します。「すべてのブロック内で 100B モデルを学習させる」ふりをするのではありません。 3. **検証可能なコンピュート**：ZK、TEE、MPC により第三者が計算内容を抜き取り検査できるようにします。[トラステッドコンピューティング・フレームワーク](/ja/blog/trusted-computing-framework)を参照してください。 4. **データとモデルの権利**：貢献者、モデルバージョン、収益分配にはホワイトペーパーの約束ではなく実行可能なルールが必要です。[AI 資産の権利](/ja/blog/ai-data-ownership)を参照してください。 5. **アプリとエージェント**：戦略、リスク管理、人間の介在。重い計算はオフチェーンまたは専用ネットワークに置き、決済と重要な状態変化はオンチェーンに残します。 Bitroot の物語上の重心は主にレイヤー 1（楽観的並列 EVM）と、レイヤー 2〜3 への接続部にあります。チェーンが順序づけと決済を担い、コンピュートネットワークが重い負荷を運び、トラステッドコンピューティングが抜き取り検査とプライバシーの境界を担います。ポジショニングについては [Bitroot のポジショニング](/ja/blog/bitroot-positioning)、コンピュートのインターフェースについては[分散 GPU とエッジコンピュート](/ja/blog/gpuai)、「AI ネイティブ」の能力一覧については [AI ネイティブ・ブロックチェーン](/ja/blog/ai-native-blockchain)を参照してください。 ## なぜ実行レイヤーが特に決定的なのか 人はしばしば「ガスが高い」とか「ネイティブの AI オペコードがない」ことを責めます。しかしより一般的な失敗モードは、コンセンサスがすでにトランザクションを順序づけたのに、実行が追いつかない、あるいはホットなコントラクトで直列的な振る舞いに崩れることです。エージェントにとってそれは次を意味します。 - **予測不能なレイテンシ**：同じ戦略が輻輳の違いで挙動を変え、リスク管理が破綻します。 - **コンポーザビリティの税**：複数プロトコルにまたがるアトミックなフローはコンフリクトと再実行を増やします。ホットスポットがスループットを押し潰します。[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)を参照してください。 - **検証コストの上昇**：ノードが並列結果を効率的にリプレイできなければ、分散型の検証は紙の上だけのものになります。 したがって、並列実行、コンセンサス／実行の分離、明示的なコンフリクト検出は「TPS ポスターのため」ではなく、自動化された主体に計画可能な決済基盤を与えるためのものです。全体像については[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)、[Pipeline BFT と実行の分離](/ja/blog/bitroot-pipeline-bft)、[楽観的並列化](/ja/blog/bitrootevm-)を参照してください。 テストネット条件下で、Bitroot の資料はシャードあたり数千〜数万 TPS、確認はおおむね秒レベル（ときにサブ秒）というエンジニアリング目標と結果を示してきました。数値はハードウェア、負荷、コンフリクト率に依存します。安定したメインネット性能でも、いかなる利回りの約束でもありません。指標の読み方については[性能指標の用語集](/ja/blog/performance-metrics-glossary)を参照してください。 ## 注意すべきナラティブの罠 - **オンチェーン学習の神話**：完全な事前学習はほぼ常にオフチェーンまたは専用ネットワークで行われます。チェーンに合うのはジョブ、支払い、検証ダイジェストです。 - **利回りとしてのコンピュートマイニング**：分散 GPU ネットワークはアイドル率を下げられますが、それは安定したリターンではありません。 - **エンジニアリングではなくスローガンとしての互換性**：本当の EVM 互換性はバイトコードとツールチェーンで決まります。[EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)を参照してください。 - **信頼ギャップを覆い隠す「融合」**：棚卸しは [Web3 と AI の融合](/ja/blog/web3-ai-convergence)にあります。 ## どのレイヤーから作るべきか リソースが限られるなら、まず自動化された負荷の下での予測可能な決済、次に薄い受け入れを伴うジョブ／支払い、次に脅威モデルに応じた TEE／ZK、最後に複雑な権利と市場、という順序を好むべきです。不安定な決済の上に載せたモデルモールは、主に紛争を増幅します。トレードオフについては[分散化と性能のトレードオフ](/ja/blog/decentralization-performance-tradeoff)、読者別の入口については[誰が並列 EVM を読むべきか](/ja/blog/who-should-read-parallel-evm)を参照してください。 ## 失敗はレイヤーをどう伝播するか スタックは分離によって助けになりますが、失敗はインターフェースを越えて伝わります。コンピュートの受け入れが曖昧なら、決済は忠実に誤った相手へ支払います。権利が欠けていれば、エージェントアプリはプラットフォームの規約を真実として扱います。実行のコンフリクト崩壊は、完璧な戦略オーケストレーションさえ手数料とレイテンシで壊します。五つのレイヤーを描くのはモジュール名のためではなく、各インターフェースについて入力、受け入れ、失敗時に状態がどこで止まるかを規定するためです。 ビルダーにとって妥当な統合順序は、まず並列 EVM 上でジョブ／支払いの状態機械を安定させ、次にコンピュートのスケジューリングと証明を接続し、その後に初めてエンドユーザー向けエージェントの UX を磨くというものです。チャットボットから始めてチェーンへ逆算するやり方は、ほぼ必ず確認遅延と検証不能な出力を作り直すことになります。互換性の制約については [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)を参照してください。 ## プロジェクト資料を読むときの評価チェックリスト 「分散型 AI」の主張に対しては、少なくとも次を確認してください。決済がピーク TPS だけでなくコンフリクト率とリプレイコストを報告しているか。コンピュートが GPU 数だけでなく受け入れとチャレンジを説明しているか。権利が画像ミントだけでなく取り消しと支払いの状態機械を含むか。トラステッドコンピューティングが名詞の山ではなく敵対者モデルを述べているか。 Bitroot 関連の資料も同じチェックリストで読んでください。決済には並列 EVM と Pipeline BFT、オフチェーンの重い処理と抜き取り検査にはコンピュートとトラステッドコンピューティング、ルールの実行には権利。一つの文で「AI L1 は準備完了」と主張するものは、チェックリストの項目に分解して戻すべきです。ポジショニングについては [Bitroot のポジショニング](/ja/blog/bitroot-positioning)を参照してください。 スタックマップの役割はカテゴリーエラーの削減です。決済で学習を解こうとしたり、コンピュートで最終性を解こうとしたり、権利 NFT で受け入れを解こうとしたりしないこと。カテゴリーが明確になれば、Web3×AI には議論可能なインターフェースが生まれます。 ## 仕組み解説記事との読む順序 決済基盤については、単一スレッドのボトルネックとスケーリングマップ → 並列実行の三つの路線と OCC 入門 → 本スタックマップ → 並列 EVM 概要とポジショニング、という順序がよいでしょう。AI プロダクトについては、スタックマップの後に信頼ギャップ、トラステッドコンピューティング、コンピュートネットワーク、権利を読みます。どちらの経路も同じ事実を指します。予測可能な実行レイヤーがなければ、上層の物語は安定的に提供できません。 ## まとめ 分散型 AI スタックが機能するのは、知能が検証可能な境界の内側にあり、同時に決済が十分高速で予測可能である場合だけです。実行は、エージェントが最初にストレステストをかける区間です。以降の記事では並列アーキテクチャ、トラステッドコンピューティング、権利を掘り下げます。本稿は「Web3＋AI」がすべての問題を一つの言葉に背負わなくて済むように、レイヤーの地図を描くだけにとどめます。 ## 関連記事 - [Web3 と AI の融合](/ja/blog/web3-ai-convergence) - [Bitroot 並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm) - [AI ネイティブ・ブロックチェーンに必要なもの](/ja/blog/ai-native-blockchain)