AIを使った個人開発で大事なのは、すべてを丸投げすることではなく、作業の単位を分けることです。Codexのような開発支援ツールは、既存コードの読み取り、実装方針の整理、ファイル修正、テスト実行、README更新までを一つの流れで進めるときに力を発揮します。
まず既存コードを読ませる
新機能を作るとき、最初にやるべきことは実装ではなく把握です。どのファイルにルートがあるのか、DBマイグレーションはどこか、管理画面と公開画面は同じコンポーネントか、テストはどの範囲を見ているかを確認します。ここを飛ばすと、あとから似た機能が二重に増えたり、既存の運用を壊したりします。
依頼文に入れると安定するもの
- 目的: 何のために変更するのか
- 壊してはいけないもの: 既存機能、DB、公開URLなど
- 完了条件: どの画面、どのAPI、どのテストで確認するか
- 運用方針: 今だけ隠すのか、将来戻すのか
例えば、公開サイトだけAdSense向けに変えたいが、5ch関連の管理機能は残したい、という依頼では、削除ではなく機能フラグで隠す方が安全です。このような制約を最初に書くと、実装の方向がぶれにくくなります。
実装は小さく分ける
Codexに依頼するときは、公開フィルタ、管理画面、マイグレーション、固定ページ、SEO出力のように、変更領域を分けて考えると確認しやすいです。大きな変更でも、ひとつずつ通していけば戻しやすくなります。特にDB変更は、ローカルと本番の両方で適用されるため、テーブル削除のような破壊的な変更は避けます。
確認まで任せる
実装だけで終わらせず、型チェック、テスト、ローカル表示、必要なら本番のcurl確認まで行うと抜けが減ります。個人開発ではレビュー担当も自分なので、機械的に確認できる項目を増やすほど安心です。エラーが出たら、直した内容だけでなく原因もREADMEやdocsに残すと、次の作業で効いてきます。
変更したファイル、追加した環境変数、マイグレーション番号、実行したテスト、確認したURLを残します。未来の自分が作業を再開するとき、ここが一番助けになります。
Codexを使うときの注意点
AIは便利ですが、最終判断は人間が持つ必要があります。料金、規約、セキュリティ、著作権、公開可否の判断は自分で確認します。また、AIが提案した変更が既存の運用に合っているかを見ることも大切です。速く作れるからこそ、確認の手順を省かない方が結果的に早くなります。
チェックリスト
依頼前に用意するもの
- 目的と完了条件を書いたメモ
- 触ってほしくない機能やデータ
- 確認したいURLや操作手順
- 必要な環境変数の名前
- READMEへ残してほしい運用メモ
Codexは、単なるコード生成ではなく、個人開発の作業を前に進める相棒として使うと効果が出ます。読む、直す、確認する、記録する。この流れを作ると、一人でも継続しやすくなります。