比較基準：stateはどこに保存され、ルールはどこで実行されるのか
「On-chain games vs Web2 games」は、on-chainゲームとWeb2ゲームのアーキテクチャ比較です。ルールがどこで実行され、ゲームのstate（進行状況、インベントリ、キャラクターのパラメータ）がどこに保存されるのかを見ます。
「NFT付きゲーム」とfully on-chainの重要な違いは、前者ではトークンがon-chainであっても、進行状況とルールはサーバー上に残る場合があることです。
- Web2 → アイテムと進行状況は開発者データベース内の記録です。アクセスはアカウントとサービスのルールで決まります。
- On-chain → ロジックや状態の一部がブロックチェーンに記録されます。資産は NFTになり、アクションはトランザクションになることがあります。
- Web3ハイブリッド → NFTはwalletに保存されることがありますが、ゲームプレイと進行状況は通常サーバー上で更新されます。
- Fully on-chain → ルールとstateはsmart contract内にあります。クライアントアプリは変わっても、実行ルールと契約上のstate（イベントとcontractの記録）はネットワーク上に残ります。
重要な結論： Web2のサーバーが停止すると、アクセスと進行状況は通常終了します。Web3ハイブリッドではNFTがwalletに残ることは多いものの、利用ルールと進行状況がサーバー側にあった場合、ゲーム内ユーティリティは消えます。
基準： 「真実の源」とは、資産への権利と最終的なstateを保存する層です。スタジオのサーバー/DBなのか、smart contractとネットワークデータなのかです。
更新内容： Web3ハイブリッドとfully on-chainの定義を明確化し、「真実の源」を確認する基準と「server off」シナリオの影響を追加しました。
4点で見る結論：Web2、ハイブリッド、fully on-chain
比較基準は、進行状況（state）がどこに保存され、誰がルールを検証するか（サーバーかsmart contractか）です。
- 重要なのはNFTの有無ではなく、 むしろ 進行状況の保存場所 と ルール実行の層です。
- Web2 → サーバーが唯一の真実の源であり、単一障害点でもあります。
- Web3ハイブリッド → トークンはwalletに残る場合がありますが、利用ルールはサーバーが定めることがよくあります。
- Fully on-chain → ルールとstateはcontract内にあり、クライアントはネットワークデータへのインターフェースです。
モデル比較：資産、進行状況、サーバー依存
層ごとの比較：真実の源、資産、進行状況、サーバー依存、サービス停止時の影響。
| パラメータ | Web2 | Web3ハイブリッド （部分的にon-chain） |
Fully on-chain |
|---|---|---|---|
| 真実の源 | スタジオのサーバー/DB | 一部の権利/資産に対するサーバー + ブロックチェーン | Smart contractとネットワークデータ |
| 資産 | ゲーム内の記録 | wallet内のNFT/トークン。ユーティリティはサーバーが決めることが多い | NFT/トークン + contract内の利用ルール |
| 進行状況（state） | サーバー側 | 通常はサーバー側 | On-chain（contract state） |
| 「サーバーを停止した」 | アクセスと進行状況は通常終了する | NFTは残る場合があるが、モード/ルール/進行状況は消えることがある | ルールとstateはネットワーク上に残り、インターフェースは変更できる |
| UX/速度 | 最大 | 中程度（wallet、署名） | 妥協（手数料、レイテンシ、アクセスインフラ） |
| 主なリスク | 中央集権性：スタジオがルールとアクセスを変更できる | トークンは存在するが、ユーティリティはサーバーに依存する | contractの安全性 + スケーリングとUX |
読むための用語：NFT、on-chain/off-chain、smart contract、state
比較に必要な最小限の概念です。何が資産なのか、stateはどこに保存されるのか、ルールはどこで実行されるのかを整理します。
- NFT は、デジタルオブジェクト（例：アイテム）の所有を確認する、ブロックチェーン上の一意のトークンです。
- Smart contract は、ルールを実行し、データを保存/更新するブロックチェーン上のコードです。
- On-chain は、アクションまたはデータがブロックチェーンネットワークに記録されることです。
- Off-chain は、アクションまたはデータがブロックチェーン外（サーバー、クライアント、閉じたDB）に保存されることです。
- Fully on-chain は、ゲームのロジックと状態がブロックチェーン上にあり、クライアントはcontractのデータとルールへのインターフェースであることです。
- 真実の源 は、最終状態を決める層です。誰が資産を所有しているか、どのレベルか、どのインベントリかを定義します。
モデルの境界：Web2ゲーム、Web3ハイブリッド、fully on-chain
実行基準による分け方です。「トークン化された資産」と「contract内のルールとstate」は別のモデルです。
Web2ゲーム： 状態（進行状況、インベントリ、キャラクターのパラメータ）は、中央集権型サーバー上に保存され更新されます。
On-chainゲーム： アクションおよび/または状態がブロックチェーンに記録され、smart contractのルールによって実行されます。
Web3ハイブリッド： 資産はトークン化（NFT/トークン）されますが、ロジックと進行状況の重要な部分はoff-chainに残ります。
Fully on-chain: ブロックチェーンを実行層として使います。ロジックとstateはcontractに配置され、インターフェースは複数あり得ます。
重要な論点： NFTがあるだけでは、ユーティリティの存続は保証されません。ユーティリティが残るのは、利用ルールおよび/または重要なstateがcontractに固定されている場合、またはcontract stateを読み、同じルールを実行する互換クライアントが存在する場合だけです。
資産への権利：「DB内」対「wallet内」
トークンの所有とゲーム内ユーティリティの存在は別の状態です。なぜなら、それらを定義する層が異なるからです。
Web2：開発者システム内の記録としての資産
アイテムはDB内の行として存在し、アクセスはサービス機能を使うアカウント権限として存在します。
- アカウントとプラットフォームのルールが、どのアイテムやモードを利用できるかを決めます。
- アカウント停止やサービス終了は、通常アイテムと進行状況へのアクセスを終了させます。
- 移転や取引は、多くの場合プロダクトのルールとスタジオのインフラによって制限されます。
結果： 資産はサーバー外の独立したオブジェクトではなく、DB内の記録のままです。
Web3：walletアドレス上のトークン（NFT/トークン）としての資産
所有者は鍵でトークンを管理しますが、ユーティリティはトークン利用ルールがどこで実行されるかによって決まります。
- トークンはゲームアカウントとは独立して残る場合があります。記録がネットワーク上にあるからです。
- トークンの利用ルールをサーバーが定めている場合、スタジオはトークン自体に触れずにユーティリティを停止できます。
- サービス終了後、互換クライアントやon-chainの利用ルールがなければ、トークン価格は下落する可能性があります。
結果： トークンはアドレス上に残り得ますが、サーバー側のルールと進行状況が止まると「ゲーム内の有用性」は消えます。
区別： 「wallet内のNFT」はトークン所有を意味します。「トークンがゲーム内権利を与える」かどうかは、利用ルールが記述され実行される層に依存します。
重要な考え方： サーバーがユーティリティを提供しなくなっても、NFT自体は残ることがあります。
進行状況と検証：サーバーstate vs contract state
重要な問いは、stateがどこで更新され、どの層が状態遷移を確認するかです。サーバーなのかsmart contractなのか。
サーバーstate： 進行状況はサービスのDBに保存され、「公式バージョン」はサーバーが決めます。
Contract state： 進行状況はsmart contractのデータとネットワークイベントに記録され、遷移はcontractロジックで検証されます。
| 比較対象 | サーバーstate | Contract state |
|---|---|---|
| 進行状況の保存場所 | サービスのデータベース | contractデータ + ネットワークイベント |
| 誰が遷移を確認するか | サーバーロジックとサービスルール | smart contractのロジック（許可されること、禁止されること） |
| 誰が最終バージョンを定めるか | 唯一の仲裁者としてのサーバー | 真実の源としてのネットワークとcontract |
| 管理者変更 | 可能（例：報酬付与の巻き戻し） | contractルールとトランザクションにより制限される |
| 結果の確認方法 | サービスとアカウントのデータによる | ネットワークデータ（contract stateとイベント）による |
| サービスが停止した場合 | 進行状況と「公式バージョン」はDBと一緒に消える可能性がある | Stateとイベントはネットワーク上に残り、インターフェースは変更できる |
例： シーズン結果（ランキングと報酬）がon-chainに記録されていれば、クライアントが変わってもネットワークデータで確認できます。シーズン結果がサーバーに保存されている場合、サービス停止時に「公式バージョン」は消えます。
妥協：on-chainの権利とon-chainの結果、off-chainのゲームプレイ
- On-chain: 所有権、希少な報酬、シーズン結果（サーバーから独立して確認する必要があるもの）。
- Off-chain: 速度とUXのための高頻度アクション（戦闘、移動、マッチメイキング）。
- 結果： on-chainはすべてのゲームプレイ操作ではなく、希少だが重要なイベントを固定します。
仕組み： contractに記録される権利と最終結果が多いほど、所有権とシーズン結果の確認におけるサーバー依存は小さくなります。
サービス停止シナリオ：各モデルで何が失われるか
サーバー停止が資産と進行状況に与える影響は、モデルごとに異なります。真実の源が異なるからです。
Web2: インフラ停止により、サーバーstateの更新とアカウントデータの提供が止まります。
結果： 進行状況とアイテムへのアクセスは通常サービスと一緒に終了します。
Web3ハイブリッド： NFTはネットワーク上の記録としてアドレスに残りますが、サーバー要素（進行状況、モード、利用ルール）は消える可能性があります。
結果： トークンは存在しますが、サーバー停止時にユーティリティは終了します。
Fully on-chain: ロジックとstateはcontract内にあるため、データは一社に依存せずネットワーク上に残ります。
制限： 便利なアクセスは、クライアントアプリとデータ読み取りインフラ（RPCとインデクサ）に依存します。
on-chainの制限：手数料、遅延、UX、contractリスク
On-chainは検証可能性を高めますが、手数料、遅延、鍵管理の要件を追加します。
- スループットと遅延： アクションの記録にはトランザクションと確認が必要です。
- 操作コスト： stateの保存と更新をon-chainで行うと高額になる場合があります。
- UXの壁： wallet、鍵、署名、アクセス復旧は別のリスク層です。
- アクセスインフラ： RPC、インデクサ、インターフェースはstateの読み取りやすさとアクセス可能性に影響します。
- contractの安全性： コードのミスや誤った権限は、stateと資産に不可逆的な影響をもたらします。
ゲームデザインへの影響： 頻繁なマイクロアクションはon-chainへ移されることはまれです。より多くの場合、on-chainは希少だが重要なイベント（権利、報酬、シーズン結果）を固定します。
ハイブリッドが人気な理由： ブロックチェーンは権利と経済的イベントに使い、高頻度のゲームプレイはoff-chainに残すことで、各アクションごとの手数料と遅延を避けます。
重要な妥協： on-chainの検証可能性は、手数料とUX上の摩擦で支払われます。
選択基準：on-chainが価値を生む場合、生まない場合
アーキテクチャで見るフィルターです。資産への権利と検証可能な結果が重要な場所、速度と滑らかなUXの方が重要な場所を見分けます。
On-chainが正当化されやすい場合
価値が資産所有、来歴、二次市場に結び付いている場合。
- 二次市場が重要なコレクションアイテムやカード。
- ネットワークイベントで検証できるルールを持つ、資源経済とクラフト。
- 資産への権利とシーズン結果の保存が重要な、長く続く世界。
Web2の方が合理的な場合
速度、最小限の摩擦、各アクションで手数料がないことの方が重要な場合。
- 遅延が重要なreal-timeジャンル（シューター、アクション）。
- walletや署名なしで大規模オンボーディングするカジュアルゲーム。
- アイテムがサービス外で価値を持たないプロジェクト。
例（アプローチの目安）
これは推奨でも品質評価でもありません。このセクションの目的は、市場が通常さまざまなアーキテクチャをどう呼ぶかを示すことです。
基準による確認： (1) 進行状況はアカウント内かcontract内か。(2) 公式サイトなしでstateを見られる代替クライアント/閲覧手段はあるか。(3) NFTのユーティリティはcontractで決まるのか、サーバー側のルールで決まるのか。
- トークン化された資産（多くはハイブリッド）→ アイテムやキャラクターはNFTだが、ゲームプレイと進行状況はoff-chainです。
- 経済型・コレクション型フォーマット → 資産へのon-chain権利と、その資産をめぐる市場ルールを固定することが多いです。
- Fully on-chain系 → ルールとstateをcontract内に保ち、クライアントをネットワークデータへのインターフェースとして扱おうとします。
確認基準： NFTの有無よりも、進行状況の保存場所とルール実行の層の方が重要です。
よくある3つの誤解
期待の誤りは通常、「トークン所有」と「動作しているユーティリティ」と「真実の源」が混同されることに関係します。
「NFTがあるならゲームは閉じられない」
トークンはネットワーク上に存在し続けることがありますが、サーバー側ゲームプレイとサーバー側進行状況は消える可能性があります。
- トークン所有は、サービスがゲーム内ルールを支え続ける義務を生みません。
- リスクは、進行状況の保存場所とトークン利用ルールの実行場所で決まります。
結果： 確認はNFTの有無ではなく、進行状況とルールから始めるべきです。
「On-chain = 完全に分散化」
On-chainは資産など一部にだけ使われ、進行状況やマッチのルールには使われないことがあります。
- On-chain資産はon-chain進行状況を意味しません。
- ハイブリッドモデルは、サーバーへの重要な依存を残す場合があります。
結果： 進行状況とルールの「真実の源」は、サーバーかcontractのどちらかに探す必要があります。
「Fully on-chainに制限はない」
Contract stateはネットワーク上に残りますが、手数料、遅延、読み取りインフラ経由のアクセスはUXに影響します。
- 手数料と確認は、on-chainアクションの頻度を制限します。
- クライアント、RPC、インデクサの利用可能性は、stateを読む便利さに影響します。
結果： on-chainアクションの数と、単一のフロントエンドなしでstateを閲覧できるかを評価することが重要です。
FAQ
on-chain gamingとは何ですか？
Web2ゲームとWeb3ゲームの違いを簡単に言うと何ですか？
ゲームが終了したらNFTはどうなりますか？
walletなしでWeb3ゲームを遊べますか？
サーバーなしで進行状況を保存できますか？
なぜfully on-chainゲームはまだ少ないのですか？
最終チェック：on-chain vs Web2を3つの特徴で見る
モデル評価は一つの問いに集約されます。進行状況とルールの「真実の源」はどこにあるのか。
- 進行状況： シーズン結果と重要な報酬はcontractに記録されるのか、それともサーバーDBに残るのか。
- ルール： state遷移はsmart contractで確認されるのか、サーバーロジックで確認されるのか。
- 停止リスク： サービスが消えたときに残るのは、ネットワークデータと、それにアクセスできる互換手段だけです。
進行状況とルールがサーバー上にあるなら、on-chain要素は資産として残っても、ゲームの「公式バージョン」は保存しません。