Codexでバグ修正を半分にする使い方

person using computer keyboard AI

「エラーは出てるけど原因がわからない」「直したつもりなのに別の場所が壊れる」…プログラムあるあるですよね。最近のOpenAIの事例では、楽天がCodex（コードを書いたり調査したりするAIエージェント）で障害対応をかなり短縮できたそうです。

この記事では、ライトユーザーでも真似しやすい形に落として、Codexで“再現→原因特定→修正→テスト”まで一気通貫で進める手順を紹介します。プロンプトもそのままコピペで使えます。

Codexって何？ChatGPTとどう違うの？

Codexは、ざっくり言うと「コードの現場作業に強いAI」です。ChatGPTでもコード相談はできますが、Codexはより「リポジトリ（プロジェクト一式）を前提に、修正案を出して、必要ならテストまで回す」という流れが得意です。

  • MTTR（平均復旧時間：障害から復旧までの平均時間）を縮めたいときに効きます
  • CI/CD（自動テストや自動デプロイの仕組み）のチェック観点づくりにも使えます
  • 「直したけど不安…」を減らすために、テスト追加まで頼めるのが便利です

無料で使える？料金は？

Codexの提供形態は時期やプランで変わることがあります。基本的にはOpenAIの有料プランや法人向けで触れるケースが多いので、まずは手元ではChatGPT（無料/有料）で手順を練習し、導入できる環境がある人はCodexを本番投入、という順番がおすすめです。

  • ChatGPT：無料枠あり（上位プランは月額課金）
  • Codex：利用可能プラン/環境は公式の案内を要確認

ポイント：この記事のプロンプトは、ChatGPTでもかなり再現できます（コードやログを貼れる範囲で）。

こんな人におすすめ

  • エラー文を読んでも「結局なにすれば？」となりがちな人
  • 修正のたびに手戻り（直したのに別の不具合が出る）を減らしたい人
  • テストを書くのが苦手で、いつも動作確認が雑になりがちな人
  • チームでのレビュー前に、まずAIに一次レビューしてほしい人

手順：Codex流「再現→原因→修正→テスト」テンプレ

ここからは、スクリーンショットで操作説明するイメージで、手順を細かめに書きます。ChatGPTでやる場合も同様に進めてOKです。

Step 1：まず“素材”を集める（ここが9割）

AIに渡す情報が少ないと、推測が増えて精度が落ちます。最低限、次を用意しましょう。

  • エラーが出た画面の操作手順（1,2,3…で書く）
  • エラーメッセージ全文（ログの該当箇所）
  • 関連しそうなファイル（例：controller/service、設定ファイル、該当関数）
  • 実行環境（OS、Node/Python/Javaのバージョン、依存ライブラリ）

ログは長いときほど、先頭〜末尾を切らずに渡すのがコツです（個人情報やAPIキーは必ず伏せてください）。

Step 2：再現と切り分けをAIに“手順化”させる

最初から「直して」と言うより、再現手順と原因候補の切り分けを出させると、後の修正がブレにくくなります。

あなたはシニアエンジニアです。以下の情報から、バグの再現手順を最短で作り、原因切り分けのチェックリストを出してください。

# 期待する出力
1) 最短の再現手順（手元で試せる具体手順）
2) 原因候補トップ5（可能性順）
3) 追加で必要な情報（不足している場合）

# 状況
- 何をしたら起きるか：
(ここに操作手順)

- エラー（ログ/スタックトレース）：
(ここに貼る)

- 関連コード：
(ここに貼る)

- 環境：
(例：Node 20 / Next.js 14 / macOS など)

この段階で「追加で必要な情報」が出たら、先にそれを埋めるのが近道です。

Step 3：修正案は“差分”で出させる（コピペ事故を防ぐ）

AIが丸ごと書き換えると、意図しない変更が混ざりがちです。なので、パッチ（差分）形式で要求します。

次の制約で修正案を提案してください。

# 制約
- 変更は必要最小限
- 既存の挙動を壊さない（後方互換）
- 修正は「差分（diff）」で提示
- 変更理由を1行で添える

# 目的
このエラーを解消し、同種の入力でも落ちないようにする

# エラーと関連コード
(ここに貼る)

出てきたdiffは、Gitを使っているならブランチを切って適用→手元で実行、が安全です。

Step 4：テストを“追加で”頼む（再発防止の肝）

ライトユーザーが一番サボりがちなのがここです。でも、AIがいるとテスト作成の心理的ハードルが一気に下がります。

さっきの修正に対して、再発防止のテストを追加してください。

# 条件
- 失敗していたケースを必ず含める
- 可能なら境界値（ギリギリの入力）も1つ追加
- テストフレームワークは既存に合わせる（不明なら推測せず質問して）
- テストコードもdiff形式で

# 参考
- 既存テストの場所： (例：tests/ や __tests__/)
- 既存テスト例： (貼れるなら貼る)

「テストフレームワークが不明」と言われたら、package.jsonやrequirements.txtなど、依存情報を貼ると解決が早いです。

Step 5：PRレビュー役として使う（人間のレビューが速くなる）

最後に、AIに「レビュー観点」を出させると、チームのPR（プルリク：変更提案）も通りやすくなります。

以下の変更diffをコードレビューしてください。

# 観点
- バグの再発可能性
- 例外処理（落ち方）
- セキュリティ（入力検証、情報漏えい）
- パフォーマンス
- 命名/読みやすさ

# 出力形式
- 指摘（重要度: High/Med/Low）
- 代替案（あれば）

# diff
(ここに貼る)

注意：AIに“勝手に実行”させない（プロンプトインジェクション対策）

最近は「AIエージェントにいろいろやらせる」流れが強い一方で、プロンプトインジェクション（指示の乗っ取り：Webページや文章に紛れた命令でAIが危険行動をすること）も問題になります。

安全に使うコツはシンプルです。

  • 秘密情報（APIキー、個人情報、社内URL）を貼らない
  • 「削除」「送信」「公開」系の操作は、必ず人間が最終確認
  • AIには「提案まで」、実行は「自分で」から始める

OpenAIもエージェント設計でこのあたりを重視していて、危険な操作を制限したり、機密データを守る設計が紹介されています。使う側としても、まずはガードレール（安全柵）前提でいきましょう。

よくあるつまずきQ&A（ライトユーザー向け）

Q. ログが長すぎて貼れません

A. まずは「最初のエラー行（例外名）」と「スタックトレースの最下部（呼び出し元）」だけ貼って、追加要求が来たら追記するのが現実的です。個人情報は必ず伏せましょう。

Q. AIの修正案が怖くてマージできません

A. その感覚は正しいです。差分を小さく、テストを追加、レビュー観点を出させるの3点セットでリスクを落とせます。

Q. そもそも自分は開発者じゃないです

A. それでもOKです。たとえば「WordPressの表示崩れ」や「簡単な自動化スクリプト」でも、同じ流れ（再現→原因→修正案→確認手順）がそのまま使えます。

まとめ：まずは“再現→切り分け”だけでも価値が出ます

Codexみたいなコーディングエージェントの強みは、「コードを書く」よりも調査と切り分けを速くして、手戻りを減らすところにあります。楽天の事例のように、障害対応や修正のスピードを上げたい人にはかなり刺さるはずです。

  • まずはStep 2（再現と切り分け）のプロンプトをコピペ
  • 次にStep 3（diffで修正）で変更を小さく
  • 余裕があればStep 4（テスト追加）までやる

この3つだけで、「AI使ってみたけど微妙だった…」から抜け出しやすくなります。今日の作業で、小さめのバグから試してみてください。

参考リンク

Photo by Zan Lazarevic on Unsplash