Practical Codex Seminar

Codexは
こう使え！

「AIに聞く」から一歩進んで、設計、実装、検証、ドキュメント化まで一緒に進めるための実践ガイド。

開発効率レビュー自動化チーム導入

想定時間: 45-60分For engineers, PMs, designers

Goal

今日のゴールは、Codexを「便利なチャット」ではなく「作業相棒」として使えるようになること

1依頼の粒度を変えて、成果物まで持っていく
2コードベースを読ませ、既存の流儀に合わせて実装させる
3テスト、レビュー、説明までまとめて任せる

話すこと: 「AIに聞く」の延長ではなく、同じ作業場にいるエンジニアへ依頼する感覚に切り替える、という入口を作る。

Mindset

Codexに強い依頼は、背景、ゴール、制約、確認方法が入っている

弱い依頼

「このバグ直して」

何が正しい挙動か、どこまで触ってよいか、どう確認するかが曖昧。

強い依頼

「購入履歴画面で日付フィルタが効かない。既存UIの見た目を維持し、関連テストを追加して、最後に確認コマンドも教えて」

話すこと: 完璧なプロンプトは不要。ただし「何を成功とするか」を渡すだけで結果が大きく変わる。

Workflow

実装: 小さな機能追加は「仕様 + 既存に合わせて」で頼む

例: 注文一覧に「未発送のみ」フィルタを追加して。既存のフィルタUIと状態管理のパターンを読んで合わせてください。関連するユニットテストかコンポーネントテストも追加し、最後に変更ファイルと確認コマンドをまとめて。

ポイント: 実装だけでなく「合わせる」「試す」「説明する」まで含める05

Use Case 2

調査: まず仮説を聞くより、コードベースから事実を集めさせる

依頼	Codexにやらせること	成果
仕様把握	関連ファイル、ルーティング、DB、APIを読む	変更すべき場所が見える
バグ調査	再現条件、ログ、差分、テスト失敗を追う	原因候補と修正案が出る
技術負債	重複、例外、依存関係、テスト不足を探す	着手順が作れる

話すこと: Codexは検索と読解が得意。人間の思い込みで場所を限定しすぎないのがコツ。

Use Case 3

レビュー: 「LGTM?」ではなく、リスク観点を指定する

挙動

境界値、例外、非同期、権限、状態遷移を見る。

保守性

責務分離、重複、命名、既存パターンとの差分を見る。

検証

テストの抜け、手動確認、ロールバック観点を見る。

例: このPRをレビューして。特に認可漏れ、N+1、既存API互換性、テスト不足を優先して、重大度順にファイル/行番号付きで指摘して。

Prompt Patterns

すぐ使える依頼テンプレート

A「まず関連箇所を読んで、変更方針を短く出してから実装して」
B「既存の設計に合わせ、不要なリファクタは避けて」
C「テストが落ちたら原因を調べ、通るところまで直して」
D「最後に変更点、確認結果、残リスクをまとめて」

Guardrails

任せてよいこと、任せっぱなしにしないこと

任せてよい

定型的な実装や修正
テスト追加、エラー調査
差分要約、移行手順、ドキュメント化
複数案の比較

人間が握る

プロダクト判断、顧客影響
セキュリティ、課金、権限の最終確認
大規模な設計変更の承認
本番反映のタイミング

話すこと: Codexを使うほど、人間の仕事は「全部手でやる」から「何を正しいとするかを決める」に寄っていく。

Team Adoption

チームで使うなら、依頼文と完了条件を共有資産にする

1よくある作業の依頼テンプレをREADMEやWikiに置く
2「最後に必ず出す報告フォーマット」を決める
3AIが触ってよい範囲、承認が必要な範囲を明文化する

話すこと: 個人の工夫で終わらせず、チームの作法にする。導入初期は小さな成功例を集めるのが効く。

Demo Agenda

当日のデモ構成

時間	内容	見せるポイント
5分	エラーを渡して原因調査	ログから関連コードへ辿る
10分	小機能の実装	既存UIに合わせて編集する
5分	テスト失敗の修正	検証まで自走させる
5分	レビュー依頼	リスク順に指摘を出す

話すこと: デモは成功シーンだけでなく、失敗から直す場面を見せると現実味が出る。

Closing

Codexを使うほど、仕事は「手を動かす量」から「正しい方向に進める力」へ移る

まずは次の1週間、ひとつのタスクを最初から最後までCodexと進めてみてください。調査、実装、テスト、説明まで任せると、使いどころが一気に見えてきます。

読ませる任せる確かめる共有する

Q&Aありがとうございました

Codexはこう使え！