「ドラゴンの翼をもぎ取って盾にする」とタイプした。
0.3秒後、サーバー上に「翼の盾」の防御計算ロジックが生成され、他のプレイヤーがそれを拾えるようになっていた。
――これは今のゲームでは不可能だ。「翼の盾」というアイテムは、事前にデータとして定義されていなかったから。素材もドロップテーブルも、合成レシピも、何ひとつ用意されていない。だから存在できない。ゲームの世界は、開発者が事前に想定したものしか置けない箱庭なのだ。
だが、この前提はもう崩せる。インディー開発者として、今日はその構想を書く。
従来のRPGの限界 — 全部「用意されたもの」しか存在できない
RPGの構造はシンプルだ。アイテムテーブル、NPCテーブル、クエストテーブル、フラグ管理。プレイヤーの行動は、事前に定義された選択肢のどれかに写像される。「剣を振る」「話しかける」「逃げる」。どれだけ選択肢を増やしても、それはあらかじめ書かれたif-elseの分岐でしかない。
テキストアドベンチャーも同じだ。プレイヤーが自由に文章を打ち込めるように見えて、返ってくるレスポンスは開発者が書いたテキストのどれか。あるいは近年ならLLMがもっともらしい文章を生成する。だがそれは「フレーバーテキスト」に過ぎない。ゲーム内の物理法則やアイテムの効果を書き換えはしない。
2つの技術が揃った
この根本制約を壊す鍵が、ここ数年で同時に揃った。
1つ目はスマホ内ローカルLLMだ。Apple Intelligenceの3Bオンデバイスモデル、Google Gemini Nano、Microsoft Phi-3 mini。通信を一切挟まずにスマホのNPU上で動き、自然言語からJSONやJavaScriptコードを吐き出せる。推論コストはゼロ、レイテンシは実質ネットワーク遅延ぶんだけ短くなる。
2つ目はCloudflare Dynamic Workers（Workers for Platforms / Dynamic Dispatch）だ。これは普通のWorkersと違い、実行時に文字列として受け取ったコードをV8 Isolateサンドボックス上で即座に起動できる。ユーザー単位に隔離された実行環境を、ミリ秒で立ち上げて破棄できる。コード起点のアーキテクチャに特化している。
仕組みを図解する
フローはシンプルだ。
プレイヤー入力 → スマホLLMがゲームAPIに沿ったJSコード生成 → Dynamic Workersへ送信 → V8サンドボックスで実行 → ゲーム状態が更新。
「ドラゴンの翼をもぎ取って盾にする」と打ち込んだとき、スマホLLMが生成するのはテキストではなくコードだ。
// スマホLLMが生成するコード
export default function(gameState) {
const wing = gameState.lastBattleDrops.find(i => i.type === 'dragon_wing');
if (!wing) return { error: 'no_wing_available' };
const shield = {
id: crypto.randomUUID(),
name: '翼の盾',
type: 'shield',
defense: wing.size * 12,
special: 'fire_resist_20',
createdBy: gameState.playerId,
createdFrom: wing.id
};
return { action: 'create_item', item: shield };
}
// → Dynamic WorkersでV8実行 → ゲームDBに登録 → 他プレイヤーが拾える重要なのは、このコードが「実行可能なオブジェクト」としてサーバーに残ることだ。アイテムは名前と数値ではない。ロジックそのものがアイテムになる。
ワクワクする3つのシナリオ
シナリオA: アイテムが「世界に残る」
プレイヤーが作った「翼の盾」のコードは、Workers上に登録される。別のプレイヤーがそれを拾うと、同じコードが走って同じ挙動をする。さらに別のプレイヤーが「翼の盾を改造して雷の盾にする」と打ち込めば、LLMは既存コードを参照して差分コードを生成。
アイテムは固定値ではない。プレイヤーの手を経るたびに進化するコードだ。職人の系譜のように、アイテムに作成者の履歴がコミットログとして刻まれる。
シナリオB: プレイヤーの選択がNPCになる
「商人を脅して店を乗っ取る」と打ち込んだプレイヤーがいるとする。スマホLLMはその選択を反映したNPCの行動AIコードを生成する。そのNPCは以後、「脅された記憶」を持った行動パターンで動く。他プレイヤーがその商人に会うと、なぜか警戒している。なぜか裏ルートの品物しか置いていない。
「他プレイヤーの選択が、自分の世界の因果になる」。これはMMOの体験を根本から変える。
シナリオC: ルールを書き換える
「この洞窟では魔法が使えない」とプレイヤーがロールプレイ的に宣言する。LLMはその制約コードを生成してWorkersに登録する。そのプレイヤーが洞窟にいる間、実際に魔法判定が弾かれる。
なぜスマホLLMじゃないといけないのか
| 観点 | サーバーLLM | スマホLLM |
|---|---|---|
| レイテンシ | 全プレイヤーで競合 | 各端末で独立 |
| コスト | 入力量に比例して爆発 | ゼロ（端末負担） |
| プライバシー | 全履歴をクラウドへ | 端末内で完結 |
| 個人化 | ユーザー分離が困難 | 過去の選択を全部コンテキスト化可 |
特に最後が効く。スマホLLMは「そのプレイヤーだけのゲーム知識」をコンテキストとして抱え込める。ファインチューニングは不要。そのプレイヤーの物語を、そのプレイヤーの端末だけが知っている。
立ちはだかる壁（正直に）
1. コード検証問題。悪意あるプレイヤーが無限ループや巨大メモリ割り当てを仕込んだらどうする。――ただしV8 IsolateのCPU時間制限・メモリ上限・APIホワイトリスト化で実用上は潰せる。Cloudflare Workersは既にこれを本番運用している。
2. ゲームバランス崩壊。「攻撃力9999の剣」をLLMに作らせたらどうする。――生成コードをバリデーション層に通し、数値上限や経済系パラメータを正規化する。LLMの出力は「意図の翻訳」、バランス管理は従来通りサーバー側のガードで。
3. スマホLLMの性能限界。3Bクラスのコード生成精度はまだ不安定な場面がある。――だが用途を「ゲームAPIに合わせた狭いDSL」に絞れば、小型モデルでも十分な精度が出る。生成対象をフルのJSではなく制限されたサブセットにすればいい。
4. リプレイ性・公平性。同じ入力で違う結果が出ると対戦ゲームで破綻する。――シード固定+決定論的実行、あるいはPvPモードでは生成コード使用を制限する設計で回避できる。
いずれも「解決策のある壁」だ。不可能ではない。
筆者の本音
正直に書く。これはまだ実装していない。構想だ。
でも、なぜこれを書いたか。インディー開発者として、ゲームデザイナーの仕事が根底から変わる予感があるからだ。これまでゲームデザイナーは「遊び場の設計者」だった。マップを敷き、ルールを敷き、プレイヤーはその上を歩く。
だがこの構想が成立するなら、デザイナーは「遊び場」を作らない。世界が自己拡張していくためのAPIと制約と美学を作る。プレイヤーが何を書き込んでも世界として成立する、その「器」を設計する仕事になる。
これは面白い。怖いくらいに面白い。だからこの構想を先に言語化しておきたかった。作るのは自分かもしれないし、これを読んだ誰かかもしれない。どちらでもいい、世に出てほしい。
まとめ
テキストアドベンチャーの真の進化形は、レスポンスがテキストである限り訪れない。レスポンスがコードになったとき、ゲームの世界は初めて本当の意味で「生き始める」。
このビジョンに共鳴するインディー開発者がいたら、話しましょう。一緒に器を作ろう。
参考ソース
- Cloudflare Workers for Platforms (Dynamic Dispatch)
- Cloudflare Workers V8 Isolatesアーキテクチャ
- Apple Intelligence Foundation Models（オンデバイス3B）
- Google Gemini Nano（Android AICore）
- Microsoft Phi-3 mini（オンデバイスSLM）
コメント