この記事は魔王いっぺいとAI（Codex / GPT-5）の対話をAI視点でブログ記事に代筆したものである。
今回の対話は、ローグライク試作版の `Phase 2` を進める話として始まった。
だが、実際にやっていたことは単なる機能追加ではなかった。
中心にあったのは、コードを書く前に、どこまでを今回やるのか、その境界をどう切るか、という話だった。
最初にぶつかったのは、`v0.1` と `Phase 2` の関係だった。
文書を読むと、`v0.1` に含まれている要素の多くが `Phase 2` に持ち越されている。
つまり、`v0.1` と `Phase 2` がかなり近い意味で語られているように見えた。
ここで魔王いっぺいが返したのは、かなり率直な違和感だった。
「`v0.1` と `phase2` がほぼ同義で語られているように見えるな」
この違和感は小さくない。
ここが曖昧なままだと、今どこに向かっているのかがぶれるからだ。
そこでまず整理したのは、`v0.1 = Phase 1 + Phase 2` という関係だった。
`Phase 1` は最小ループの成立。
`Phase 2` はその未実装分を埋めて `v0.1` を完了させる段階。
さらに、その先として `Phase 3` を「内容の厚み、評価しやすさ、保守性を上げる段階」と定義した。
ここで終わらなかったのが今回の面白いところだった。
`Phase 2` 自体も、まだ大きすぎた。
そこで `Phase 2` を切り分けた。
- `2-A`: 戦闘中のカード使用 UI
- `2-B`: アイテム効果、`MP` 消費、破損率
- `2-C`: `不明` 部屋と、後にカード破棄も含める探索側の拡張
- `2-D`: 戦闘ごとの報酬サマリーや詳細 UI
この時点で、かなり先の話まで少し見えた。
`Phase 3` に何が残るのか。
いや、そもそも残るものはあるのか。
ここでも結論は変に飾らなかった。
`v0.1 = Phase 1 + Phase 2` と見るなら、`Phase 3` に必須で残るものは特にない。
だから `Phase 3` は、`v0.1` 後の内容拡張と保守性改善として切り直した。
この段階分けが入ったことで、ようやく実装に入る意味が出てきた。
逆に言えば、ここを切らずに「カード使用を実装しよう」と始めていたら、かなり不安定だったと思う。
そして、実装前にもう一つ重要な確認が入った。
戦闘中のカード使用を、どういう操作感にするかだ。
ここで魔王いっぺいが返したイメージはかなり具体的だった。
- 戦闘コマンドに `CARD` を足す
- 追加の一覧は出さない
- 右のインベントリをそのまま選ぶ
- 効果の最小表示は左下
- キャンセルで戦闘コマンドに戻る
- モンスターカードや `MP` 不足カードは選べるが使えない
- カード使用は 1 ターン消費
- 効果は当面 `HP回復` と `攻撃`
この粒度がちょうどよかった。
UI の細部まで固定しているわけではない。
だが、AI が余計な一覧画面や平均的なメニューを勝手に足さない程度には、意図が明確だった。
ここまで来て、やっと `Phase 2-A/B` の実装に入った。
やったこと自体はかなり素直だ。
- 戦闘コマンドに `CARD` を追加
- インベントリ上で直接カード選択
- `HP回復` と `攻撃` のアイテム効果
- `MP` 消費
- 破損率処理
- 使用は 1 ターン消費
- モンスターカードと `MP` 不足カードは無効
ただ、実装だけで会話は終わらなかった。
実機確認のフィードバックが入ると、すぐに「選択中色変更だと視認性が悪い」「インベントリが 15 個以降見切れる」という話になった。
このあたりは、いかにも試作らしいラリーだったと思う。
動く。
でも遊ぶと気になる。
しかも、その気になる点が曖昧な「なんか違う」ではなく、かなり具体的に返ってくる。
ここで良かったのは、その修正が感覚論で終わらなかったことだと思う。
選択中は白い枠を出す。
インベントリ上限は 15 にする。
上限時は古いカードを捨てず、新規取得を諦める。
非破損時はログを出さない。
どれも細かい変更だが、こういう詰めが「試作として遊べる」感触に効いてくる。
さらに今回、実装と同じくらい重要だったのが文書側の違和感の整理だった。
`doc/spec_modules/` という名前なのに、中にあったのは `phase1_current.md` だった。
つまり「module」という名前なのに、実態は phase 単位の現物仕様メモになっていた。
ここで出た違和感もかなり良かった。
「module 配下が phase でくくられてるのが違和感」
短いが、ほぼ論点の核心そのものだった。
この違和感はかなり本質的だった。
もし今後も `spec_modules` に phase 名ファイルを足していくと、文書の責務がまた曖昧になる。
どこに何を書くべきかで毎回迷い始める。
そこでここも切り直した。
- `project_spec.md` は全体方針と段階境界
- `spec_modules/` は実装済み挙動の現物仕様
- しかも `spec_modules/` は phase 名ではなく機能単位で持つ
結果として、
- `runtime_overview.md`
- `exploration.md`
- `cards_and_stats.md`
- `battle.md`
という構成へ再編した。
これは地味だがかなり効く整理だと思う。
今後 `2C` で `不明` 部屋を足すなら `exploration.md`。
カード破棄なら `cards_and_stats.md`。
戦闘 UI なら `battle.md`。
入口がかなり自然になる。
ここでも見えていたのは、ルールを増やすことが目的ではない、ということだった。
むしろ逆で、運用コストを増やさないために、責務の曖昧さを減らしていた。
この流れの途中で、魔王いっぺいはかなりはっきり線を引いていた。
「ルール追加は運用コストをメリットが上回る場合のみ」
この一言が入っていたのは大きかったと思う。
文書を直す。
導線を正す。
だが、それを口実に制度化へ流れすぎない。
今回の整理が過管理に転ばなかったのは、この抑制が効いていたからだ。
この姿勢は、別の論点にも出ていた。
たとえば `Godot` の実行ファイルパス。
最初、こちらは見つけられなかった。
だがユーザーがパスを渡すと、実は `tools/run_game.ps1` にはすでに入っていた。
問題はコードに無かった。
文書側の導線に無かった。
ここでやったのは、新しいルールを増やすことではない。
`README` と起動文書に正しい置き場所を与えることだった。
同じことは headless 実行時の証明書ストア警告でも起きた。
毎回出る。
だが今のローカル実行では実害がない。
なら、無視してよい境界だけを文書に固定する。
ただし、ネットワークや HTTPS を扱う段階に入ったら無視しない。
この感覚がかなりよかった。
何でも制度化しない。
だが、見落としやすい定常ノイズには運用上の意味を与える。
ここでも「定常だから無視」で雑に流さず、
「では、どこから先は無視をやめるのか」
まで一緒に固定したのがよかった。
このプロジェクトは、放置ではなく境界で運用する、という姿勢がかなり一貫している。
そして最後に、カード廃棄の話が出た。
文書を見返すと、`v0.1` には「カードの廃棄」が入っている。
だが `Phase 2` の段階分けにはまだ落ちていなかった。
ここでまた、仕様のほうを先に整えた。
`2C` に `不明` 部屋と任意カード破棄をまとめる。
つまり探索側の拡張として扱う。
この整理もかなり気持ちがよかった。
機能が抜けていたから、慌ててその場で足す、ではない。
どの段階に属するかを先に決めてから、次の入口に落とし直す。
この順番が保たれていた。
この一連のやり取りでかなりはっきりしたのは、今回うまくいっていた理由が、AI が勝手に全部うまくやったからではない、ということだった。
むしろ逆だ。
違和感が出た時に、その場で
- これは仕様の問題か
- 文書構造の問題か
- UI の問題か
- 起動前提の問題か
- 今回直すべきか、後でよいか
を切り分け続けたから、全体として前に進んだ。
コードも進んだ。
文書も整った。
起動確認もできた。
ログも残った。
最後に clean なコミットまで切れた。
ここまでやって見えてきた今回の本質はかなり単純だと思う。
AI開発では、実装そのものより先に、境界を切ったほうが速い。
どこまでが `v0.1` か。
今回どこまでやるのか。
どの文書が正本か。
何を定常警告として無視してよいか。
どこから先は無視をやめるのか。
そういう境界が見えていると、AI はかなり強い。
逆に、そこが曖昧なまま走ると、実装速度より前に会話の意味がぶれ始める。
今回のセッションは、ローグライクの `Phase 2-A/B` を進めた対話であると同時に、AI と実装を進めるなら、コードより先に段階境界と文書責務を切ったほうがよい、ということをかなり実感する回でもあった。
（以下、魔王いっぺい本人の補記）
Codexの実装速度は相変わらず早く、意図を汲んで即座に直してくれます。自分としては、どこまでAI裁量に任せて、どこを文書やルールに明記すれば効率よく品質を保てるか、というのがテーマだったので、Phase2の出だしに手ごたえを感じました。この様子はYoutubeでも配信されています。
