---
id: 9
title: AI ネイティブなブロックチェーンに本当に必要なもの：拡張、ハイブリッド実行、計算の境界
slug: ai-native-blockchain
date: 2026/08/17
summary: 「AI ネイティブ」が検証可能であるために何を意味すべきか。任意の命令拡張やプリコンパイル拡張、ハイブリッド実行パス、分散コンピュートのスケジューリング、そして楽観的並列決済レイヤーやトラステッドコンピューティングとの明確な役割分担を整理し、エンジニアリング上の目標とメインネットの約束をどう切り分けるかを論じます。
keywords: AIネイティブ・ブロックチェーン,ハイブリッド実行,命令拡張,分散コンピュート,Bitroot
heroImage: /images/community-bg.png
---

「AI ネイティブ」は機能リストとして書くのは簡単です。オペコードをいくつか追加し、GPU ネットワークを用意し、ZK のステッカーを貼るだけです。より良い問いは、オンチェーンの状態機械がネイティブに担うべき AI 関連の責務は何か、何をオフチェーンに留めるべきか、そしてなぜ決済スループットが依然として前提条件なのか、という点です。本稿はビジョンを形容する言葉ではなく、能力の境界を描きます。

## 何に対してネイティブなのか

浅い統合は通常こうです。コントラクトがオラクルや中央集権 API を通じてモデルの結果を取得し、それを状態に書き込みます。レイテンシ、信頼の前提、コンポーザビリティはすべてオラクル側にあり、チェーンはどのモデルが動いたか、入力がすり替えられていないかをほとんど制約できません。

より「ネイティブ」な道筋には、通常少なくとも三つの要素が含まれます。

1. **コントラクトから表現できる AI 関連のプリミティブ**（拡張、プリコンパイル、標準インターフェース）。毎回プライベートなブリッジを再発明するのではありません。
2. **ハイブリッド実行**：軽くて検証可能なステップはチェーン上またはその近くで実行し、重い学習や大規模推論はコンピュートネットワークで行い、証明やチャレンジ期間を通じて決済へ戻します。
3. **決済との明確な分担**：並列 EVM はコントラクトの状態遷移の幅を広げますが、数千億パラメータの学習をブロック実行に詰め込むものではありません。

スタックの全体像については[分散型 AI スタック](/ja/blog/aibitrootweb3ai)、信頼ギャップについては [Web3 と AI の融合](/ja/blog/web3-ai-convergence)を参照してください。

## 命令拡張かプリコンパイル拡張か：互換性を最優先

VM がテンソルや深層学習のプリミティブを公開するなら、妥当な制約は次のとおりです。

- **スーパーセットであり、フォークではない**：標準の EVM バイトコードパスが引き続き使えるようにし、チェーンが「AI をテーマにしている」という理由で既存の DeFi／NFT コントラクトが壊れないようにします。拡張は別のオペコード空間やプリコンパイル空間を占めます。
- **ハードウェア高速化に対応づける**：プリミティブは SIMD／GPU のパスに載るべきであり、インタプリタ内での遅い純ソフトウェアの「ネイティブ」シミュレーションにすべきではありません。
- **再現可能なツールチェーン**：モデル変換、量子化（例：INT8／FP16）、SDK、プロファイラが同じ結果を再現できなければなりません。そうでなければ「ネイティブ」はホワイトペーパーの中にしか存在しません。

公開資料では、特定のモデルとハードウェアの下で推論スループットを数倍にしつつ精度の犠牲は控えめである、といったエンジニアリング上の観察が引用されることがよくあります。これは普遍的な SLA ではありません。互換性の境界そのものについては [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)で扱っています。

任意の大規模モデルがバリデータ集合全体で完全なフォワードパスを実行し、正規の状態に取り込まれると示唆する主張には注意してください。それは非決定性、ハードウェアの異質性、帯域コストをそのままコンセンサスのセキュリティ前提に流し込むことになります。

## ハイブリッド実行：複雑さで振り分ける

すべての AI 計算がオンチェーンに属するわけではありません。より安定した振り分けの考え方は次のとおりです。

| ワークロードの形 | より妥当な経路 | オンチェーンに残るもの |
|----------------|--------------------|---------------------|
| 小さく反復可能な制約チェック | オンチェーンまたはプリコンパイル | 状態変化そのもの |
| 中規模の推論／ファインチューニングの断片 | オフチェーン＋軽量な受け入れ | ジョブハッシュ、受け入れ、支払い |
| 大規模学習 | コンピュートネットワーク＋強力な受け入れ（サンプリング／ZK／TEE） | ジョブと証明のコミットメント、支払い |

ノード選定は、評判、ステーク、検証可能ランダム関数（VRF）を組み合わせて操作を減らすことができます。重要なジョブでは、複数当事者による独立実行と多数決の合意を用いることもあります。これらは脅威モデルに強度が依存する設計上の選択肢であり、機能トグルの数に依存するものではありません。

ハイブリッド実行は、[分散 GPU とエッジコンピュート](/ja/blog/gpuai)と[トラステッドコンピューティング・フレームワーク](/ja/blog/trusted-computing-framework)では別の切り口で同じ問題を扱っています。ライフサイクルと証明の前提という違いです。

## 分散コンピュートネットワーク：神話ではなく計算資源を組み立てる

データ並列、モデル並列、パイプライン並列は成熟した分散学習の語彙であり、ビザンチン勾配フィルタリング、チェックポイント、フェイルオーバーはエンジニアリングの常識です。それらがチェーンの語りに入るときは、境界を守る必要があります。

- 相互接続と VRAM の限界は、何かが「オンチェーン」だからといって消えるわけではありません。
- 稼働時間だけに支払われるインセンティブは、監査可能なコンピュート市場ではなくインフレマイニングへと流れていきます。
- 決済レイヤー（楽観的並列 EVM）は、ジョブの状態機械と支払いに対してスループットと最終性の期待を提供します。[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)と [Bitroot のポジショニング](/ja/blog/bitroot-positioning)を参照してください。

テストネットの確認遅延と TPS が表すのは決済基盤の性質であり、「学習速度」に読み替えられるものではありません。指標の読み方については[性能指標の用語集](/ja/blog/performance-metrics-glossary)を参照してください。

## トラステッドコンピューティングと権利：もう二つのネイティブ要素

完全性、機密性、複数当事者による共同計算は、ZK／TEE／MPC の組み合わせに依存します。「エンタープライズセキュリティ」というもう一つのスローガンでは済みません。実行可能なデータとモデルの収益には、オンチェーンのメタデータ、権限、支払いの状態機械が必要です。[AI 資産の権利](/ja/blog/ai-data-ownership)を参照してください。

## 推奨する提供順序

より安定した順序は、予測可能な決済 → 薄い受け入れを伴うジョブ／支払い → 脅威モデルに応じた TEE／ZK → 複雑な権利／市場、という流れです。開示は分けて行うべきです。決済のベンチマーク（コンフリクト率）、計算完了のレイテンシ（ハードウェア）、証明生成／検証の時間（回路／エンクレーブ）。一つの「AI チェーンの TPS」ポスターは全員を誤導します。ホットなワークロードについては[並列 EVM のワークロードとホットスポット](/ja/blog/parallel-evm-workload-hotspots)を参照してください。

イーサリアムのアプリを移行する場合、AI ネイティブだからといってツールチェーンを壊すことを既定にしてはなりません。拡張プリコンパイルが証明検証を高速化することはあっても、主経路は Hardhat／Foundry と監査の前提を維持すべきです。そうでなければ「ネイティブ」は「書き直し」になってしまいます。互換性については [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)、楽観的並列の仕組みについては[楽観的並列化の仕組み](/ja/blog/bitrootevm-)を参照してください。

## 「ネイティブ」が出荷できるかを決めるのはツールチェーン

再現可能な変換、量子化、シミュレーション、デバッグのツールがなければ、命令拡張はドラフト仕様のままです。ビルダーには、拡張に触れるトランザクションのローカルでの決定的リプレイ、ハイブリッドのルーティング判断に対するテストネット上での可視性、そして証明が欠けたときの明確な失敗（中央集権 API への無言のフォールバックではない）が必要です。ツールチェーンの成熟度は、オペコード一覧と併せて開示すべきです。

ネイティブ拡張は、既存の Solidity コントラクトのバイトコードの期待と監査の前提を壊してはなりません。新しいプリコンパイルのガス計量、エラーコード、アップグレードのガバナンスは仕様に含めるべきです。そうでなければ「AI ネイティブ」はハードフォークの驚きになります。互換性については [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)、決済の並列性については[楽観的並列化](/ja/blog/bitrootevm-)を参照してください。

## 非決定性と正規状態の間のレッドライン

AI ネイティブ拡張がハードウェア依存の浮動小数点を持ち込むと、正規状態が分岐します。仕様では、どのプリミティブがコンセンサス上重要なパスに置かれ得るか、どれがオフチェーンで実行してからコミットすべきか、量子化／丸めが必須かどうか、GPU を持たないノードがどう検証またはスキップするかを述べる必要があります。それがなければ、「ネイティブ」はハイエンドノードへの暗黙の信頼になります。

テストネットでは、アクセラレータなしでの検証、拡張トランザクションの決定的リプレイ、ハイブリッドの誤ルーティング時の可視的な失敗をカバーすべきです。スループット目標では、拡張ワークロードが含まれるかどうかを明記し、純粋な送金ベースラインとの混同を避けるべきです。指標については[性能指標の用語集](/ja/blog/performance-metrics-glossary)を参照してください。

提供可能な「AI ネイティブ」とは、仕様、ツールチェーン、ハイブリッドルーティングがそれぞれ独立に再現可能であることを意味します。提供できない場合、正直にプリコンパイル実験とコンピュート市場インターフェースへと格下げすることを意味します。どちらにも価値があり、絶対的な表現を共有すべきではありません。

## 段階的な提供は一つの巨大な定義に勝る

まずプリコンパイル実験、ジョブ決済コントラクト、スポットチェック付きの推論市場を出荷し、命令のカバレッジとより強力な証明は後から反復します。「完全な AI ISA＋グローバル学習ネット＋普遍的な権利」を一つのマイルストーンに縛ると、どれも独立には受け入れられなくなります。脅威モデルと性能条件を伴う段階的計画こそが、エンジニアリングとしての AI ネイティブの道です。

## まとめ

検証可能な AI ネイティブ・ブロックチェーンはこういう姿です。互換性の制約下で再現可能な拡張プリミティブ、コストに応じて振り分けられるハイブリッド実行、受け入れを備えたコンピュートネットワーク、そしてエージェントやジョブ機械にとって十分高速で予測可能な決済レイヤー。どれか一つが欠けると、「ネイティブ」はオラクルの糊に戻ってしまいます。これは投資助言ではありません。スループットとレイテンシの数値は、メインネットの敵対的条件下で独立に再現されるまでは、テストまたはエンジニアリング上の目標として扱ってください。

## 関連記事

- [分散型 AI スタック](/ja/blog/aibitrootweb3ai)
- [トラステッドコンピューティング・フレームワーク](/ja/blog/trusted-computing-framework)
- [分散 GPU とエッジコンピュート](/ja/blog/gpuai)