ビットコイン（L1）に本格的なBCGが少ない最大の理由は、
①レイヤー1の設計（スループット・手数料・遅延）
②プログラマビリティ（ゲーム向けの状態管理やスマートコントラクトが貧弱）
③周辺エコシステム（ツールやウォレット、流動性）の不足
にあります。
これらは“意図的なトレードオフ”でもあります。ビットコインはお金の最小限機能を最優先した結果、L1で複雑なアプリを回す余地が小さい。
一方、Ordinals / Runes / Taproot Assets、Stacks / Rootstock（RSK）、Lightning、RGB、BitVMといった“拡張レイヤー”は急速に整備されつつあり、「ビットコイン圏のゲーム」は“周辺（L2/サイドチェーン/プロトコル）”で台頭してきつつあります。」
理由①：L1の“サイズ・スピード・コスト”が、ゲームには厳しい
ビットコインは10分に1ブロック、ブロック容量も限られ、L1のスループットは概ね3〜7 Tx/秒と見積もられます。これは、秒間で大量のゲーム内イベント（ミント・合成・売買・ステート更新）を捌く必要があるBCGには物理的に狭い器です。さらに、ネットワークが混雑すると手数料が高騰し、ゲームに必要な頻繁・小額のトランザクションが一気に“赤字化”します。L1の制約はよく知られており、「スケールをL1で追うほど分散性・セキュリティが揺らぐ」という“ブロックチェーンの三角測量”も、コア開発側は意識して保守運用しています。
理由②：スマートコントラクトの“作り”がゲーム向きではない
ビットコインのScriptは意図的に単純で、グローバルな“アカウント状態”を直接持たない UTXO モデルです。UTXOは「一度使ったら消える箱」を積み替える設計なので、継続的に状態を書き換え続ける“ゲームの変数（HP・経験値・インベントリ等）”を一次元に管理するのがとても難しい。対してイーサリアム/EVMはアカウントモデルで、コントラクトが“世界の状態”を直接保持でき、ゲームに必要な在庫・スコア・マップ状態などを素直に表現できます。結果として、EVM/Move系にBCGが集中してきました。
理由③：BCGの“必需品”をまとめて満たすスタックが、L1には無い
本格BCGは「高速・低手数料の実行環境」「標準化されたNFT/FT規格」「開発ツール（Unity/Unreal SDK、インデクサ、オラクル）」「ウォレットとマーケットのUX」がセットで必要です。ビットコインL1は資産保存に特化してきたため、ゲーム向けの“全部入り”が求められると、エコシステム側（ウォレット/マーケット/開発ツール）が先に悲鳴を上げます。この“足りないものは周辺で補う”という流れが、次の章のL2/サイドチェーン/新プロトコルの台頭へとつながりました。
「それでもBTCでやる方法」は？
あまり向いていないとはいえ、それでもそれをやる方法は存在します。
1) 画像/NFT・FTの最小実装：Ordinals / Runes / Taproot Assets
Ordinals はサトシにデータを「刻む」発想でNFTライクな資産を表現、Runes は効率的なFT（代替可能トークン）の発行規格です。Taproot Assets は“BTC上での資産発行（FT/NFT/ステーブル）”を目指すプロトコルで、特にLightning連携による高速転送が期待されています。どれもL1の制約を壊さず“資産の表現力”を拡張する方向ですが、ゲームロジック（戦闘判定・経済バランス）までL1で回すのは依然として困難。“アイテムの所有証明だけBTCに置き、ロジックは外”という分業が現実解です。
2) “L2/サイドチェーン”でスマコンを使う：Stacks / Rootstock（RSK） ほか
Stacks は“Bitcoinをファイナリティの錨”にしてスマートコントラクト層を別途持つ方式を採用（sBTCなどPeg強化も進行）。Rootstock（RSK） はEVM互換のサイドチェーンで、PoWペグ＋マージマイニングによりBTCと結びつけ、EVMの開発体験でDApp/ゲームを動かせます。現実にはブリッジ/ペグの信頼モデルやL2の独自ファイナリティをどう評価するかが論点ですが、「BTC経済圏でEVMゲームを動かす」という実務的ニーズには最短距離です。
3) “速い決済”を活かす：Lightning＋周辺アプリ
Lightning Network は即時かつ低コストのビットコイン送金を実現する支払いネットワークです。投げ銭・入出金・小額課金など“ゲーム外周り”に強く、ゲーム内ロジックやNFTの永続状態には向きません（チャンネル決済は最終状態だけL1に反映するため）。とはいえ「ゲームの収益化（課金・報酬）をBTCで行う」路線なら強力です。
4) “計算は外・検証はBTC”という新潮流：BitVM / RGB
BitVM は任意計算を“詐欺証明”で検証し、Turing 完全な契約をコンセンサス変更なしで表現できる理論枠組み。RGB はクライアントサイド検証でプライバシー/スケーラブルなスマコンを志向。どちらも**「ゲームの計算はオフチェーン、結果だけBTCで検証」の方向で、L1の保守性を壊さず表現力を上げる試みです。実装の成熟や開発ツールの整備はまだ道半ばですが、“BTCらしい”ゲーム基盤として注目されています。
「EVM/MoveにBCGが集中する」実務的な理由
- 開発体験：Solidity/Move の状態管理・イベント・テスト/デプロイはゲームが必要とする“継続ステート”に向いており、SDK/インデクサ/アナリティクスも充実。
- ツールと人材：Unity/UnrealのWeb3プラグイン、ウォレットのガス抽象・SNSログイン、マーケットプレイスAPIなどが揃い、小規模チームでもMVP→本番へ乗せやすい。
- ネットワーク効果：EVM互換ならNFT規格・ウォレット・オラクルをそのまま利用でき、ユーザー/流動性を最短で引き込める。
この3点の総合点で、現時点のBCGはEVM/Move系が“主戦場”であり続けています。ビットコイン圏にゲームを持ち込む動機は「BTCユーザー（資産）へのアクセス」「最終的な価値保存はBTC」といった戦略面にあり、“ゲームの内臓”（高速ロジック）は外に置く設計が現実的です。
それでも“BTC原理主義”が活きるゲーム設計
ビットコインの思想（保守的なルール・最小限の変更・検証可能性重視）に寄り添うなら、ゲームの要素を「記録」と「所有」に絞ってL1へ置く設計が噛み合います。たとえば「最終スコアと報酬分配だけはL1に永続化」「アイテムNFTはOrdinals/Taproot Assetsで管理し、クラフト計算は外」「課金はLightning」という分業です。BCGの“フルオンチェーン体験”はEVM/Move側で実装する。これが2025年時点で最も整合的な“BTC×ゲーム”のアーキテクチャに見えます。
反論
Q. 「BTCにもスマコンある。やる気の問題では？」
A. 可能性は拡大中ですが、L1は意図的に非Turing完全、UTXOでグローバルステートが持ちにくい。BitVM/RGBのような“外で計算・中で検証”の道が現実解で、EVMと同じ体験をL1一本で再現するのは設計思想と相反します。
Q. 「“Bitcoin L2”って名乗る新チェーンも増えた」
A. 実態は多様です。Stacksは独自の最終性・PoXで“BTC錨付け”、RSKはサイドチェーン（PoWペグ）でEVM互換。“L2”の呼称でもブリッジ/ペグの信頼モデルは別物なので、資産の往復リスク（Peg-out遅延・監視者の権限）を必ず確認すべきです。
Q. 「Lightningで全部やればいい？」
A. Lightning は支払いに最適ですが、オンチェーンの永続状態管理やNFTの標準化は得意ではありません。「入出金・投げ銭・大会賞金の即時配布」といった“金の流れ”で活かすのが実務的です。
まとめ
「なぜビットコイン上にBCGが（ほとんど）無いのか？」への答えは、“無い”のではなく“L1一本では難しい”からです。スループット・手数料・10分確定・Script/UTXOというL1の設計は価値の保存には最適でも、状態を激しく書き換えるゲームの実行には不向き。だからこそ、資産の表現（Ordinals/Runes/Taproot Assets）、スマコン環境（Stacks/RSKなど）、高速決済（Lightning）、外部計算の検証（BitVM/RGB）という“周辺”が急成長しているわけです。
2025年の現実解は、「ロジックは外・最終価値はBTC」。ビットコインは“ゲーム機”というより“金庫”であり、その上にL2/プロトコルという増築が進んでいます。BCGがビットコイン圏で本格開花するかは、この増築（道具箱）がどこまで整うか次第です。今後1〜2年は、その答えが出るフェーズに入ります。
参考（読み進めたい方へ）
99Bitcoins, Zerocap, stacks.co, cryptoeq.io, dev.rootstock.io, Lyn Alden, River, BitVM, boostylabs.com
コメント