Codex Mobile で具体的な開発タスクを進める

Codex Mobile から開発を進めるときは、実装を一度に任せず、調査、計画、実装、検証、レビューのゲートに分けます。ここでは「プロフィールページに RSS リンクを追加する」という小さな変更を例にします。

完了条件を決める

依頼前に、作業が終わったと判断する条件を定義します。

- 既存デザインを変えずに RSS リンクを追加する
- 既存のリンクコンポーネントを再利用する
- 日本語版と英語版がある場合は両方を更新する
- 関連するテストまたは検証コマンドが成功する
- 本番デプロイ、依存関係更新、無関係な整形は行わない

Phase 1: 変更せずに調査する

プロフィールページへ RSS リンクを追加したいです。
まだ変更せず、次を調査してください。
1. 対象ページとリンク部品
2. 既存の外部リンクの実装パターン
3. 日英同期の必要性
4. 最小の検証コマンド
5. 想定リスク
根拠として読んだファイルを列挙してください。

調査結果では、対象ファイルが依頼の範囲に収まっているかを確認します。Codex が UI 全体の改修や新しい依存関係を提案した場合は、既存パターンで実現できない理由を質問します。

確認: 対象ファイル、既存パターン、検証方法を説明でき、まだ差分が作られていなければ次へ進みます。

Phase 2: 実装計画を固定する

調査結果に基づき、変更ファイルごとの実装計画を作ってください。
既存 UI とルーティングは維持し、新しい依存関係は追加しません。
実装はまだ開始しないでください。

スマートフォンでは、計画を次の観点で確認します。

• 変更ファイル数が必要最小限か
• 既存コンポーネントを再利用しているか
• 日英の変更が対になっているか
• 検証が変更内容に対応しているか
• ビルドやデプロイが勝手に含まれていないか

Phase 3: 小さな差分を実装する

計画を承認します。RSS リンク追加だけを実装してください。
既存の未コミット変更は保持し、無関係なファイルを変更しないでください。
実装後は、変更ファイル一覧と要点を報告して停止してください。

実装後、最初に変更ファイル一覧を確認します。想定外のロックファイル、設定、生成物があれば理由を尋ねます。

確認: 差分が計画したファイルだけに収まり、削除や大規模な書き換えがなければ検証へ進みます。

Phase 4: 対象を限定して検証する

リポジトリで定義されている安全な検証コマンドから、今回の変更に必要な最小セットを実行してください。
本番ビルド、デプロイ、外部への書き込みが必要なら実行せず、理由を報告してください。

結果は成功だけでなく、実行しなかった検証も確認します。

実行済み:
- content validation: passed
- link check: passed

未実行:
- production build: explicit approval required

Phase 5: 差分をレビューする

最終差分をレビューし、次を報告してください。
- 要件を満たす根拠
- 変更ファイルごとの要約
- テスト結果
- 未検証事項
- セキュリティ、アクセシビリティ、i18n の残存リスク
コミット、プッシュ、PR 作成は行わないでください。

長い差分は、ファイル単位で表示させます。重要な条件式やリンク先は省略せず確認します。

途中で方向を変える

調査や実装の途中でも、追加制約を短く伝えられます。

方針を変更します。ヘッダーではなくプロフィール本文へ追加してください。
既に作ったヘッダー変更は取り除き、それ以外の既存変更には触れないでください。

「元に戻して」だけでは、ユーザーの既存変更まで失う可能性があります。対象と保持する変更を明示します。

失敗時の進め方

状況	指示例
テスト失敗	「失敗を再現し、今回の差分が原因か調査。修正前に原因を報告」
権限不足	「必要な権限と目的を説明し、承認待ちで停止」
要件が曖昧	「選択肢、利点、欠点を提示し、実装せず質問」
想定外の既存変更	「既存変更を保持し、今回の差分と分離して報告」
ホスト切断	ホストを再接続し、同じスレッドの状態と git status を再確認

まとめ

Codex Mobile での実務開発は、画面の小ささを工程分割で補います。調査、計画、実装、検証、レビューを別の判断点にすると、外出先でも変更範囲と品質を管理できます。

次は 個人ブログを毎日更新する で、記事作成を最初から最後まで実践します。