PROJECT P0B
開発中

FIELD NOTES

NOTE 00 · THE PIPELINE

ひとりと、ひとつのリポジトリと、AI が入った制作パイプライン

PROJECT P0B がどう作られているか。技術スタックの決め方、AI が本当に役に立った工程、そして途中で経路を変えざるを得なかった場所について。

文 / LIU YICHENG約14分

以下は開発者個人の記録で、内部マイルストーン、技術判断、失敗の経緯を含みます。現在の状態を述べるものであり、最終形でも、リリースの約束でもありません。

まず、これが何ではないかを書いておく

これは「プロンプト一行で MMO を作った」という話ではない。

PROJECT P0B は個人プロジェクトだ。リポジトリには Godot クライアント、Nakama サーバー、 決定論的なアセットパイプライン、大量の Python 検証スクリプト、そして失礼なほど長い 承認と決定の記録が入っている。AI は多くの工程に深く関わっているが、 その関わり方は、たいていの人が想像するものとは違う。

いちばん正確な言い方はたぶんこうだ。 何をもって完了とするかを決めるのは私で、その基準まで作業を運ぶのが AI で、 本当にそこへ届いたかを証明するのは機械だ。

以下が、このパイプラインの実際の姿になる。

一、境界を先に決めてから、AI に手を動かさせる

最初の一行を書く前に、AI が勝手に動かしてはいけないものをいくつか凍結した。

  • エンジンを固定：Godot 4.7.stable.official.5b4e0cb0f、Forward+、GDScript。
  • サーバーを固定：Nakama 3.39.0 + PostgreSQL 16。サーバーロジックは TypeScript サンドボックス上（Node の fs と crypto は使えない。この制約は後の設計にかなり効いた）。
  • スタイル契約を固定：ワールドスタイルには SHA-256 付きの唯一の基準画像がある。 「もっと良い基準画像を作り直す」という提案は、それだけで別途の承認が要る。
  • 権威の境界を固定：オンライン権威は整数 XZ シミュレーション。地形セマンティックハッシュ c1e82575… はコンテンツバンドルに打ち込まれている。ビジュアルに属するもの——大気、 地形 v2、品質プロファイル、言語、ビジュアルバックエンド——は仕様上すべて表現レイヤーであり、 オンライン ID に入ることは決してない。

これは AI を縛るためではなく、失敗の位置を特定できるようにするためだ。 技術スタック、受け入れ基準、バージョン規則を固定しておくと、失敗の出どころは一箇所に絞れる。 そうでなければ、ずっと推測することになる。

その結果、リポジトリにはガバナンスの仕組みが育った。docs/APPROVALS.md に プロジェクトオーナーとしての承認（A-xxx）、docs/DECISIONS.md に対応する決定（D-xxx）。 依存関係の追加、ランタイム既定値の反転、リモートデプロイ、予算超過の有料生成—— これらには新しい承認記録が要る。AI が自分で決めることはできない。

二、AI が本当に強い領域

境界がはっきりしている範囲では、AI の成果物は驚くほど良い。特に強いのは次の四つだ。

スコープの明確な実装。 きちんと書かれた仕様と受け入れ条件を渡して、 プロトコルのシリアライズ、予測とリコンサイル、決定論的なベイクスクリプトを書かせる。 この種の作業は速くて安定している。P1-WP1 の 30 Hz 移動プロトコル、 クライアント予測と和解、TypeScript と GDScript 両側でのコンテンツハッシュベクタの一致は、 すべてこの形で仕上がった。

テストと証拠の整理。 ここは過小評価されている。このプロジェクトではほぼすべてのモジュールに 検証器が付いている。P0B の構造チェック 332 項目、P1-WP2 の生成/検証面は 229/229 オフラインテスト通過、サーバー側 npm run verify は 206 テスト中 204 通過、0 失敗、 2 は明示的な歴史的スキップ。これらを一行ずつ手で書いたわけではない。 自分自身を反証できるテストを AI に書かせることは、機能コードを書かせるより価値が高い。

散らかった成果物を追跡可能な記録に畳む作業。 正式なキャプチャのたびに証拠ディレクトリが 生まれる。スクリーンショット、ログ、性能サンプル、SHA-256 マニフェスト。 これを整えるのは徹底的に退屈で、AI は退屈しない。

画像作業。 コンセプト、参考画面、キャプチャの再レンダリング、ウェブ用ビジュアル。 このサイトで見えている画像はすべて、開発中のゲームプレイ映像から出発して再レンダリングしたものだ。 遠景レイヤーも同じやり方で作った。森の戦場と町はマップの端で「切れて」しまうので、 生成画像から純表現の遠景を一枚被せている（戦場は 1024x1024 の不透明テクスチャ、 町は 2048x768 の透過付き曲面）。コリジョン、ナビゲーション、権威状態は含まず、 ゲームプレイには一切影響しない。生成 ID、入力ハッシュ、出力ハッシュ、後処理コマンドは すべて image2_provenance_v1.json に落としてある。

三、AI が苦手だった領域

大規模モデルにゲームへ入れられる 3D キャラクターを直接作らせる。この経路は通らなかった。

最初の発想は素朴だった。設定画はもうある。ならばモデルに設定画から三次元を推論させるのが 最短距離のはずだ。ところが問題はすぐに出た。構造が成立しない。手が読めない。 武器のシルエットが潰れる。正面図と上面図が同じ物体の二つの投影になっていない。

問題は「見栄えが足りない」ことではなく、生成物を検証できないことだった。 意味の曖昧なメッシュに向かって「ここが違う」とは言えない。「ここ」がどこか説明できないからだ。

そこで経路を変え、大きなタスクを、一段ずつ単独で合否判定できる狭い工程に分解した。

  1. 設定画とプロダクションシートでビジュアルの意図を固定する（正/側/背/上の一貫性を含む）；
  2. Meshy にベース形状を任せる（image-to-3D / multi-image-to-3D）；
  3. ローカルツールでメッシュと構造の修復、比率の補正、パーツ分割；
  4. リジッドパーツの装着とアニメーション適合；
  5. Godot へ取り込み、実機で検証；
  6. 私自身によるビジュアル承認。

肝は 6 段目だ。機械契約を全部通っていても、私が落とすことはある。この二つは別のものとして扱う。

この経路の詳細はキャラクターの記事に書いた。 最初の版を差し戻した具体的な理由も含めて。

四、踏んだ落とし穴をルールに変える

Goblin と ordinary Minotaur の忠実度回復は、Phase A、Phase B Wave-1、そして Wave2 の v2 から v6 まで続いた。格好のいい過程ではないが、このプロジェクトでいちばん気に入っている ドキュメントを生んだ。「落とし穴 → 無駄 → 以後の固定ルール」の表だ。

いくつか抜き出す。

  • テクスチャなしの Meshy GLB にコンセプト色を期待しない。 should_texture=false は 形状だけを担当する。色の権威は設定画のパレットと意味領域に別途束ねる。
  • 一つの候補は一つの仮説にだけ答える。 ランダムな振り直しで色・トポロジー・ポーズ・武器を 同時に試すのは禁止。どのルールが結果を変えたのか永遠に分からなくなる。
  • いちばん安い失敗をいちばん先に起こす。 入力投影の一貫性、向きのプローブ、 構成要素の存在チェックは、高価な正式キャプチャの前にすべて済ませる。 あるとき向きの yaw が間違っていて、完全な派生が終わるまで気づかなかった。 Goblin の両耳プローブがゼロになり、候補チェーン一本が丸ごと無効になった。
  • サンクコストはゲートを変えない。 「もう払ったんだから」はこの工程でいちばん高くつく一言だ。 品質基準に満たない候補は候補集合に入れない。
  • 武器は有料の形状経路に乗せない。 独立した武器シートがあるなら、武器は常に ローカルの決定論的構築に回す。Meshy は武器の輪郭や握りの姿勢を直すためには使わない。

これらは今では強制の伴走契約として、本体のワークフロー文書と一緒に効いている。

五、役割分担

ここまで書けば、それぞれの担当はもうはっきりしている。

| 役割 | 担当 | | --- | --- | | 私 | 技術スタック、設計境界、受け入れ基準、バージョン規則、ビジュアル承認、何をもって完了とするか | | LLM | スコープの明確な実装、テスト、スクリプト、証拠整理、ドキュメント | | Meshy | ベース形状——命名された形状欠陥に対してのみ、一度に一仮説 | | 画像生成 | コンセプト、参考画面、再レンダリング、表現レイヤーのテクスチャ、ウェブ素材 | | 自動化スクリプト | 決定論的ベイク、検証、封印、既存証拠の上書き拒否 |

一つ強調しておきたい。AI は制作パイプラインの一部であって、 アートと技術の判断の代替ではない。

AI は私が定義した基準まで物事を運べるが、基準そのものを私の代わりに定義することはできない。 候補を二十個作れるが、どれが正解かは教えてくれない。 すべてのテストを通るコードは書けるが、その「すべてのテスト」が正しい問いを立てているかどうかは、 やはり私の責任として残る。

六、いまの状態

  • Phase 0 は閉じた。ローカルの完全な縦切り（Hub → 遠征 → 精算 → Hub）は通り、手動受け入れも済んだ。
  • Phase 1 はオンライン部分。P1-WP1（権威移動ラボ）は封印され承認済み。 P1-WP2（オンラインソロ/協力戦闘）は承認済みだが P1-B の決定点で必ず止まる。 P1-WP3（ソーシャルタウン）は機械的には完了し、人の判断待ち。
  • 天候は表現レイヤーの機能。既定は今も warm_day。
  • Metal GPU の Phase 1 目標 <16.67 ms は未達だ。通過でも免除でもなく、延期されている。 この一行だけステータス文書で切り出してあるのは、これがいちばん曖昧にされやすい類のものだからだ。

ゲームはまだ開発中だ。この記録が書いているのは現在であって、終着点ではない。