Codexが使えなくなっても、開発全体まで止める必要はない。
先週、Codexの週間利用枠に到達した。最後の2日ほど、思うように使えなくなった。
すると、開発もほとんど止まった。
ここで気づいた。問題はCodexを使いすぎたことだけではない。
Codexが止まると、開発全体が止まる仕組みになっていた。
止まったのは一台のAIだった。それなのに、判断も記録も次の仕事も同じ場所へ集めていたため、制作ライン全体が暗くなった。ここで初めて、問題はAIの停止ではなく、一台に依存した仕事のつなぎ方だと気づいた。
そこで、ChatGPT Classicを司令室にする。GitHubを外部記憶にする。Codexは実装担当にする。開発体制を、この3つの役割に分けて作り直した。
Codex停止を「開発停止」から「実装の一時停止」へ変える
以前の流れは単純だった。
作りたいことを思いつく。Codexに相談する。Codexと仕様を考える。そのまま実装する。判断も記録も、同じ会話の中にあった。
動いている間は速い。ただしCodexが使えなくなると、考えていたことも次の作業も取り出しにくくなる。
以前は、こうだった。
Codex停止 = 開発停止
これを、次の形へ変える。
Codex停止 = 実装工程の一時停止
実装が止まっても、問題整理はできる。仕様を決められる。優先順位をつけられる。Issueを作り、次の仕事を準備できる。
AIの利用枠と、プロジェクト全体の進行を切り離す。
これが今回作り直したかった仕組みの中心だ。
自分、ChatGPT Classic、GitHub、Codexの役割を分ける
新しい役割分担は、難しくしなかった。
自分
目的を決める。違和感を伝える。最後に判断する。
ChatGPT Classic
問題を整理する。仕様を考える。優先順位を決める。Codexへ渡す仕事を設計する。
GitHub
現在地、決定、失敗、修正結果、次にやることを残す。
Codex
コードを調査する。実装する。修正する。テストする。
流れにすると、こうなる。
自分 → ChatGPT Classic → GitHub → Codex → GitHub → ChatGPT Classic
重要なのは、Codexを開発全体の中心から外したことだ。
Codexは強力だ。ただし今後は「開発そのもの」ではなく、実装を担当するリソースの一つとして扱う。
3Dのトリケラトプスが重いとき、いきなり実装しない
たとえば、3Dのトリケラトプスを歩かせたら処理が重くなったとする。リアルさは残したい。
以前なら、そのままCodexに「軽くして」と頼んでいたかもしれない。
新しい流れでは、先にChatGPT Classicと問題を分ける。
- 完全な3D移動は必要か
- 横スクロールなら、移動計算は2Dでよいのではないか
- 見た目だけ3Dにできないか
- リアルさを残す場所はどこか
- 新しい物理エンジンを入れずに済むか
ここで、次の方針を決める。
見た目は3D、ゲームロジックは2Dにする。
さらにGitHubへ、実装条件を残す。
- X方向を中心に移動する
- 不要な奥行き計算を削る
- 歩行アニメーションには3Dを使う
- 見た目のリアルさは維持する
- 新しい物理エンジンは追加しない
ここまで決まってからCodexへ渡す。
Codexは「何を作るべきか」から考えなくてよい。決まった修正をコードにすることへ集中できる。
これは利用量の節約にもつながる。ただし目的は節約ではない。判断と実装を分け、仕事を途中で引き継げるようにすることだ。
Codexが使えない日は、実装待ちの仕事を作る
木曜日に週間利用枠へ到達し、Codexが使えなくなったとする。
以前なら、そこで開発が止まっていた。
新しい体制では、ChatGPT Classicとの会話を続ける。
- 次にどこを直すか
- UIの何が使いにくいか
- 仕様をどう変えるか
- どの修正を先にするか
- 既存実装の何を残すか
考えた結果はGitHubへ残す。
たとえば、次のようなIssueを準備する。
- Issue #31 日付ピッカー修正
- Issue #32 曜日表示修正
- Issue #33 スマホUI修正
- Issue #34 CTA修正
- Issue #35 レイアウト崩れ修正
止まっているのは実装だけだ。
止めないために必要なのは、無理に実装を動かすことではない。暗くなった実装工程を迂回し、仕様、判断、Issue、確認条件を明るい側へ運ぶ。Codexが戻るまでに、次の仕事は実装できる形へ整っていく。
設計、判断、仕様決定、問題整理、優先順位付け、タスク化は進められる。
Codexが戻ったら「さて、何を作ろう」から始めなくていい。GitHubに並んだ仕事を、上から処理できる。
GitHubをコード置き場ではなくAIの外部記憶にする
この仕組みでは、GitHubの役割が変わる。
コードを保存するだけではない。人間とAIが、次の作業へ戻るための記憶を置く。
最初に用意したのは、次の3つだ。
AGENTS.mdに常設ルールを書く
AIが毎回守るルールを書く。
たとえば、作業前に読む文書。勝手に実行してはいけない操作。変更対象の固定方法。テストと記録の残し方だ。
長い知識を全部入れるのではなく、必要な場所へ案内する地図として使う。
HANDOFF.mdに現在地を書く
ここには、今の状態だけを書く。
- どこまで終わったか
- 何を確認したか
- 何が未確認か
- 次に何をするか
- 何をしてはいけないか
会話の全文は要らない。次のAIが迷わず再開できる情報だけでよい。
IssueとPRに正式な仕事を残す
Issueには、目的、対象、禁止事項、完了条件を書く。
PRには、変更内容、確認結果、残った問題を書く。
判断と実装結果をGitHubへ戻すことで、会話が途切れても知識が残る。
Codexが使えなくても消えない。別のAIへ変わっても消えない。数週間後に自分が忘れても、GitHubを読めば戻れる。
最小構成でも本当に再開できるか試した
文書を作っただけでは、引き継げるとは言えない。
そこで、既存の大量の作業ファイルがないclean環境を用意した。GitHubからリポジトリを取得し、記録だけを読んで再開できるか試した。
確認したのは次の4点だ。
- どのリポジトリが正本か
- 何を勝手に実行してはいけないか
- 現在どこまで終わっているか
- 次に何をすべきか
結果はPASSだった。
以前の会話も、元の作業環境もない。残した記録だけを別の実装担当が読み、同じ制作ラインを再び動かした。この瞬間、GitHubが単なる保管場所ではなく、AIを交換しても仕事をつなぐ外部記憶になった。
元の会話や、作業中のCodexを知らなくても、GitHubから現在地を復元できた。
これで初めて「AIが止まっても、プロジェクトは止まらない」に近づいた。
今日から試すなら3つだけ作ればいい
最初から複雑な自動化は要らない。
まずは次の3つで十分だ。
AGENTS.md
HANDOFF.md
GitHub Issue / PRIssueには、次の6項目を置く。
目的:
対象:
禁止:
完了条件:
証拠:
次の一手:作業が終わったら、実装結果をPRへ書く。現在地と次の一手をHANDOFF.mdへ戻す。
この小さな循環を一度動かす。専用ツールや大きな自動化を考えるのは、そのあとでいい。
AIを一人の万能な人として扱わない
以前はCodexをメインにして、ChatGPTで勝ち筋を決めるという使い方をしていた。
今回の失敗で、その考えをもう一段進める必要があるとわかった。
ChatGPT ClassicはPM。Codexはエンジニア。GitHubはプロジェクト管理と外部記憶。そして自分がプロダクトオーナーだ。
エンジニアが一時的に動けなくなっても、会社全体まで止まる必要はない。
次の仕様を考えられる。仕事を整理できる。優先順位を決められる。エンジニアが戻ったら、準備した仕事を渡せる。
今回作ったのは、Codexを効率よく使う方法ではない。
ChatGPT Classicを入口にして、GitHubを外部記憶として使い、Codexが使えなくなっても開発全体を止めない仕組みだ。
AIを止めないことはできない。利用枠も、障害も、モデル変更も起きる。
だから、AIが止まることと、仕事が止まることを分けておく。
そこまで作って、ようやくAIと長く開発できる。
