Contents — 7 sections

RicochetTanksの実装を始めるとき、困ったことがあった。

元になるはずの、

  • MVP_SPEC
  • CODEX_TASK
  • AGENTS

が見つからなかった。

作業を止めることもできた。

ただ今回は「探すなり埋めて進める」という方針で、足りない部分を補完して開発を始めた。

ここで一番怖かったのは、

AIがその場で決めた値が、数時間後には「元から決まっていた仕様」に見えてしまうこと。

補完した値はかなり多い

M0の固定値には、

  • 弾速 12m/s
  • 弾半径 0.08m
  • 寿命 5秒
  • 反射上限 1
  • 発射間隔 1秒
  • 移動速度 3m/s
  • 旋回 75°/s
  • アリーナ 24m × 20m
  • 壁高 4m

などがあった。

これらは実装を進めるには必要。

でも、少なくとも当時見つかった元資料にはなかった。

だから、

「元仕様に12m/sと書いてあった」

とは扱わない。

「実装を前へ進めるために置いた暫定値」として残した。

要件の出所を分けた

実装中は、値や判断をざっくり3種類に分けた。

資料由来

既存Documentで確認できたもの。

ユーザー判断

途中で人間が明示的に決めたもの。

たとえば後のMapGenでは、アリーナを40m × 32mへする判断が記録されている。

補完

資料にも明示判断にも存在せず、作業継続のために仮置きしたもの。

この区別をRequirementsやreportへ残す。

AI開発で怖いのは「もっともらしい履歴」

LLMは足りない前提をかなり自然に補える。

コードも動く。

Documentもきれいに書ける。

その結果、

「なぜこの値なのか」

を後から見た人が、

「元の要求だったんだろう」

と誤解しやすい。

でも実際には、

  • その場の仮説
  • 一時的なデフォルト
  • Agentの推測

かもしれない。

動くことと、要求として正当なことは別。

記録しないと、仮説がいつの間にか制約になる

たとえば壁高4m。

最初は三人称視点でアリーナ全体が見えてしまう問題への対応として調整された。

これを理由なしでSpecへ固定すると、後から

「壁は4mでなければならない」

という制約に見える。

本当は、

「現時点の問題へ対する暫定解」

だったかもしれない。

だから値だけでなく、

その値がどこから来たか

を残す。

「不明」を消さない

Agentへ調査させると、空欄を埋めたくなる。

でも、見つからなかったものは「不明」のまま残した方がいいことがある。

RicochetTanksの素材整理でも、

  • 確認できた
  • 補完した
  • 人間が決めた
  • 未確認

を分けている。

不明が残っていれば、後から元資料が見つかったときに上書きできる。

全部埋めてしまうと、何を疑えばいいか分からなくなる。

Agentic developmentではSpecも生成物

コードだけAIに作らせるなら、レビュー対象はコードに見える。

でも長時間Agentへ任せると、

  • Requirements
  • Task
  • Test
  • Gate state
  • Report
  • README

までAgentが更新する。

つまりSpec自体も生成物になる。

だから、

生成されたSpecを「権威ある元情報」と自動的に扱わない

運用が必要になる。

いまの結論

元仕様が見つからない状態でも、PoCなら進められる。

ただし、

進められることと、何が決定済みかは別。

AIが埋めた空欄を、後から元要件へ昇格させない。

そのために最低でも、

  • Source
  • Human decision
  • Inference / provisional
  • Unknown

を分けて残す。

RicochetTanksでは、コードよりこの区別の方が後から効いた。