Codex（GPT-5.4）レビュー駆動の計画策定

4つの実装計画を書き、それぞれCodex（GPT-5.4）にぶつけて致命的指摘だけを拾い、修正して再投入する、というサイクルを合計14回まわした。最初に出てきた指摘は符号の不整合や仕様の移管漏れなど、実装に入ってから発覚したら半日は吹き飛ぶものばかりだった。計画段階でこれらを潰せたことが、この日の最大の収穫になる。

レビューの仕組み

Codex CLIの exec コマンドにマークダウンファイルを渡し、「瑣末な点へのクソリプはしないで。致命的な点だけ指摘して」と指示する。2回目以降は resume --last をつけて前回の文脈を保持したまま再レビューする。

# 初回
codex exec -m gpt-5.4 "このプランをレビューして。瑣末な点へのクソリプはしないで。致命的な点だけ指摘して: memo/2026-04-14/plan.md"

# 修正後の再レビュー
codex exec resume --last -m gpt-5.4 "プランを更新したからレビューして。瑣末な点へのクソリプはしないで。致命的な点だけ指摘して: memo/2026-04-14/plan.md"

この「致命的な点だけ」という縛りが肝になる。縛りを外すとCodexはインデントの揃えや用語の統一を延々と並べてきて、肝心の設計不備が指摘の山に埋もれる。

CF_205 株主資本応用: 5回のレビューサイクル

4つの計画のなかで最も往復を重ねた。圧縮積立金や自己株式など符号が反転する科目が複数あり、1箇所でも符号を取り違えるとCFWS全体の数字が崩れる。

レビューの推移

符号問題の具体例

自己株式（contra-equity）はBS上で純資産のマイナスとして計上される。他の純資産科目は「増加=貸方=正」だが、自己株式だけ「増加=借方=負」になる。この符号反転を中間テーブルの集約段階で処理するか、CFWS配分段階で処理するかが曖昧だった。

Codexの指摘で「中間テーブル集約時に*-1を適用し、CFWS側では符号変換しない」という単一ソースの方針が決まった。計画段階で決めていなければ、実装時に集約と配分の両方で*-1を入れてしまい、符号が相殺されて正しく見えるが実際は二重反転、というバグを埋め込むところだった。

CF_202 リファクタリング: 4回のレビューサイクル

3600行の単一Pythonスクリプトを論点別モジュールに分割する計画。Codexの指摘で当初の計画にはなかった3つの方針が加わった。

Codex指摘で追加された方針

1. registry化

元のスクリプトでは各論点の処理が巨大なif-elif連鎖で分岐していた。Codexは「論点を追加するたびにif文が伸びる構造は壊れやすい」と指摘し、各論点モジュールを辞書に登録するregistry方式を提案した。

# registry方式のイメージ
TOPIC_REGISTRY = {
    "201_bonds": bonds_module,
    "202_fixed_assets": fixed_assets_module,
    "205_equity": equity_module,
}

2. テストファースト

分割前に既存の出力をスナップショットとして保存し、分割後の出力と差分比較する手順が計画に入った。3600行を触って「壊していない」と言い切れる根拠がないまま進めば、どこかで回帰バグを踏む。指摘を受けてスナップショット比較を計画に組み込んだ。

3. compute関数とrow_defsの単一ソース化

各論点モジュール内でcompute関数（計算ロジック）とrow_defs（行定義）が別々のファイルに散らばる設計を書いていたが、Codexは「row_defsが唯一の真実となり、compute関数はrow_defsから行の並びを読む」構造を推した。この方針を採用したことで、行の追加・削除がrow_defsの1箇所で完結するようになった。

CFドキュメント統合: 2回のレビュー

5つに分散していたCF関連ドキュメントを3つに統合する計画。2回目のレビューで指摘が消えた。

v13フォーマット移管漏れ

初回レビューでCodexが突いたのは、統合先のドキュメントにv13フォーマット仕様の記述が欠けている点だった。旧ドキュメントの1つにだけv13固有の列定義や色コードの仕様があり、統合作業で落としかけていた。人間が5ファイルを逐一照合して漏れを探すのは目が滑る。Codexはマークダウンを丸ごと飲み込んで「この仕様が統合先に見当たらない」と返してくる。

圧縮積立金のCFWS配分: 3回のレビュー

圧縮積立金の積立・取崩がCFWSのどの区分に配分されるかを定義する計画。営業CF調整と投資CF調整の境界線が定まらず、3回の往復を経て配分ルールが1つに収束した。

read-onlyサンドボックスの罠

Codex CLIはデフォルトでread-onlyサンドボックス内で動く。レビュー中にCodexが「ファイルの中身をgrepで確認したい」とツールを使おうとするが、サンドボックスがブロックする場面が何度かあった。

特に日本語を含むコマンド（grep "圧縮積立金" ...）を投げるとエンコーディングの壁に当たり、Codexが同じコマンドを微妙に変えながら数回空振りする。対策として、レビュー対象のマークダウンに必要な情報をすべて埋め込んでおく（外部ファイル参照を減らす）ことで、Codexがファイルを読みに行く必要を減らした。

1日で14回レビューを回して見えたこと

「致命的な点だけ」の指示が効く

フィルタなしだとCodexは10件以上の指摘を並べてくる。大半は命名規則やコメントの書き方で、設計を壊すものではない。「致命的な点だけ」と絞ると、1回あたり2〜4件まで指摘が削ぎ落とされ、修正すべき箇所がすぐ見える。

初回に致命的指摘が集中する

4つの計画を通して、初回レビューの指摘数が最も多い。2回目以降は修正で新たに露出した問題か、初回で見落とされていた深い層の問題が出る。3回以上回して初めて出てくる指摘は、複数の修正が組み合わさって初めて見える類のものだった。

resume --lastの文脈維持が必須

resume --lastを使わずに2回目のレビューを投入すると、Codexは1回目と同じ指摘を繰り返す。前回の指摘と修正の文脈を引き継ぐことで、「前回の指摘Aは修正されている。新たにBが問題」という積み上げ型のレビューが成立する。

計画段階で潰せるバグは計画段階で潰す

符号の二重反転、フォーマット仕様の移管漏れ、行定義の散在。どれも実装中に発覚すれば、原因を追いかけて半日が消える。計画のマークダウンを書くのに30分、Codexレビューの往復に1時間。合計1.5時間で、実装時の手戻り数時間分を先に潰している。