> For the complete documentation index, see [llms.txt](https://livlog-llc.gitbook.io/engineering-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://livlog-llc.gitbook.io/engineering-handbook/codexwoshitana/17-overview.md). # 17. Codex開発の基本方針 ## 目的 この章では、Codexを利用して安全かつ継続的に開発するための基本姿勢を定めます。 Codexは、調査、実装、テスト、文書化を高速化する協調相手です。開発者の代替でも、要件や設計を自動的に正しく決める存在でもありません。最終的な判断、確認、承認、リリース責任は人間が持ちます。 ## リブログの開発思想との関係 Codexを使う場合も、リブログの基本方針は変わりません。 * 小さく作る * まず動かす * 人間が動作と業務上の妥当性を確認する * 採用した振る舞いをテストで固定する * 使いながら改善する * AIを使うが、AI任せにしない 開発の基本サイクルは次のとおりです。 ``` 最小実装 → 動作・業務確認 → テスト追加 → リファクタリング ``` これはTDDを否定するものではありません。仕様が探索中の機能では進化型プロトタイピングを用い、正しいと確認した重要な振る舞いをテストで固定します。一方、不具合の再現条件や金額計算のように期待結果が明確な場合は、先にテストを書く方法を選びます。 ## Codexに渡す情報 Codexへの依頼には、少なくとも次の情報を含めます。 | 項目 | 内容 | | ---- | --------------------------- | | 前提 | 対象リポジトリ、技術構成、既存仕様、参照ファイル | | 目的 | 何を、誰のために、なぜ変更するのか | | 制約 | 変更可能な範囲、互換性、禁止事項、採用する実装パターン | | 完了条件 | 動作、テスト、文書、報告内容を含む確認可能な条件 | 「適切に実装してください」のような抽象的な依頼だけでは、Codexが不足情報を推測し、不要な変更を加える可能性があります。不明点は推測で埋めさせず、質問または未決事項として報告させます。 ## 人間が判断すること 人間は、次の事項を決定します。 * 機能の目的、優先順位、対象利用者 * 業務上正しい振る舞いと、今回は実現しない範囲 * アーキテクチャ、データモデル、公開APIの契約 * セキュリティ、個人情報、法務、運用上の許容範囲 * Codexが提示した選択肢の採否 * 差分の承認、マージ、デプロイ、ロールバック 特に、複数の正解があり得る設計判断を、Codexの最初の提案だけで確定してはいけません。 ## Codexに任せてよいこと 前提と変更範囲を明示したうえで、次の作業を依頼できます。 * リポジトリ内の関連ファイルや既存パターンの調査 * 要件、設計、タスク、テスト観点の整理と抜け漏れ確認 * 小さく限定された実装 * 既存パターンに沿ったテストの追加 * コマンド実行と結果の要約 * 実装差分に基づくドキュメント更新案 * 差分レビューとリスク候補の列挙 出力は候補または作業結果であり、人間による確認を省略する根拠にはなりません。 ## 小さな単位で進める 一度に「API、DB、画面、テスト、リファクタリングをすべて実装する」と依頼すると、差分が大きくなり、誤りの原因も追いにくくなります。変更は責務ごとに分け、各段階で確認します。 例えばJavaのREST APIでは、DTO、Validation、Service、Repository、Controller、テスト、文書を分けます。各依頼で、変更対象、実行する確認、完了後の報告内容を指定します。 ## 慎重に進める変更 次の変更は、通常の画面文言修正より影響が大きいため、要件、設計、テスト計画、人間の承認を厚くします。 * 金額、税、請求、ポイントなどの計算 * 認証、認可、権限判定 * 外部公開APIと後方互換性 * DBスキーマ変更、既存データ更新、削除処理 * 日付、時刻、タイムゾーン、締め処理 * 外部API、決済、通知などの連携 * Secrets、個人情報、機密情報を扱う処理 privateリポジトリであっても、APIキー、パスワード、トークンなどのSecretsはコミットしません。Codexへの指示、サンプル、ログ、テストデータにも実値を含めません。 ## 基本手順 1. 人間が目的と制約を決める 2. Codexに既存実装を調査させる 3. 人間が調査結果と設計案を確認する 4. 小さな単位で実装を依頼する 5. 人間が動作と業務上の妥当性を確認する 6. 重要な振る舞いをテストで固定する 7. 仕様を変えずにリファクタリングする 8. 文書と差分を確認し、人間が取り込む ## Codexに依頼すること * 関連ファイルと既存パターンを、根拠となるパスとともに報告する * 不明点、仮定、リスクを実装前に列挙する * 指定範囲だけを変更する * 実装後に変更ファイル、変更内容、実行した確認、残課題を報告する ## 人間が確認すること * 依頼内容が小さく、完了条件が確認可能か * Codexの前提や仮定が正しいか * 重要な判断をCodex任せにしていないか * 差分が目的に対して必要最小限か * テストだけでなく、実際の利用方法でも正しいか --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://livlog-llc.gitbook.io/engineering-handbook/codexwoshitana/17-overview.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.