Codexを実務でどう使うべきか？OpenAI公式Q&Aから見えたAI開発の現実的な運用方法

AI開発は「コードを書かせる」段階から変わりつつある

これまでの生成AIによる開発は、

• コードを書いてもらう
• エラーの原因を聞く
• 関数を作ってもらう

といった使い方が中心でした。

しかし、CodexのようなAIエージェントでは、その範囲が大きく広がっています。

たとえば、

1. 既存コードを調査する
2. 問題点を整理する
3. 実装計画を立てる
4. 複数ファイルを変更する
5. テストする
6. エラーがあれば修正する
7. レビューする

といった一連の流れまでAIが担当できるようになっています。

つまり、

ということです。

この変化に合わせて、AIの使い方も変える必要があります。

Reasoning Effortは常に高くすればよいわけではない

Codexでは、AIがどの程度深く考えるかをReasoning Effortで調整できます。

代表的には、

• Low
• Medium
• High
• xhigh

といった段階があります。

一見すると、

「品質を上げるなら常にxhighにすればよい」

と思えます。

しかし、OpenAI側の説明では、そのような使い方は推奨されていません。

基本的な考え方は、

というものです。

Low

向いているのは、内容がほぼ決まっている作業です。

たとえば、

• CSSの簡単な変更
• ファイル名の変更
• 指定されたコードの置換
• 明確な手順通りの修正

などです。

深い判断を必要としないため、高い推論能力を使う必要はありません。

Medium

一般的な開発作業では、まずMediumが候補になります。

たとえば、

• 通常の機能追加
• 調査
• 軽いデバッグ
• 実装計画
• コード修正

などです。

High

複雑な判断が必要になるとHighが有効になります。

たとえば、

• 複数ファイルにまたがる変更
• 原因が分からない不具合
• 依存関係の調査
• アーキテクチャの比較
• テストを含めた実装

などです。

xhigh

xhighは、常用する設定というより、

に向いています。

たとえば、

• 大規模なコード変更
• 複雑な移行作業
• 多数の依存関係を扱う作業
• 長時間の自律実行
• リリース前の厳密なレビュー

などです。

したがって、

と段階的に上げる考え方が合理的です。

「複雑な作業」とは何か

では、どのような作業を「複雑」と考えればよいのでしょうか。

OpenAIのQ&Aでは、いくつかの判断基準が示されています。

手順が多い

単純にコードを書くだけではなく、

調査 → 判断 → 実装 → テスト → 修正

と複数の工程が必要になるものです。

依存関係がある

一つの変更が別の機能へ影響する場合です。

前の判断を間違えると、その後の作業もすべて間違う可能性があります。

条件が多い

たとえば、

• セキュリティ
• 既存仕様
• パフォーマンス
• コスト
• 後方互換性

などを同時に満たす必要がある場合です。

複数の情報を扱う

コードだけではなく、

• ドキュメント
• データベース
• API
• ログ
• 画像

などをまとめて判断する必要がある作業です。

検証が必要

答えを出して終わりではなく、

「本当に正しいか」

まで確認する必要がある作業も複雑度が高くなります。

Plan Modeでもエフォートを固定する必要はない

計画を立てるPlan Modeでも、最初から最後までHighやxhighを使う必要はありません。

ここも重要なポイントです。

たとえば、最初の確認段階で、

「対象ファイルはどれですか」

「この仕様で合っていますか」

といった単純なやり取りをしているだけなら、Lowでも十分です。

一方、

• 未知のコードベースを調査する
• 複数の設計案を比較する
• 大きな変更範囲を決める

といった場面では、MediumやHighを使う価値があります。

つまり、

という使い分けができます。

これはコスト削減にも直結します。

AIに本番環境を触らせること自体が問題なのではない

AIに本番環境を操作させることに抵抗を感じる人は多いと思います。

しかし、OpenAIのQ&Aで興味深いのは、

という点です。

実際、OpenAIのFDE（Forward Deployed Engineer）は顧客の本番システムへ変更を行うケースがあると説明されています。

重要なのは、

「AIを信用するか、信用しないか」

ではありません。

です。

本番環境では権限を分ける

AIに本番作業を任せる場合、最初からすべての権限を渡す必要はありません。

たとえば、

読み取り

AIに許可する。

• ログを見る
• コードを調査する
• DBの状態を確認する

書き込み

人間の承認を必要とする。

• DBを書き換える
• ファイルを変更する
• デプロイする
• DNSを変更する

という設計ができます。

この方法なら、

AIには十分な調査能力を持たせながら、危険な操作だけ人間が止められます。

AIを安全に使うには「失敗できる仕組み」を作る

非常に重要なのがこの考え方です。

AIを使う場合、

ことだけを考えてはいけません。

むしろ、

ことが重要です。

OpenAIのQ&Aでも、AI生成コードだから特別な検証方法を使うのではなく、従来のソフトウェア開発と同じ方法で確認することが示されています。

具体的には、

• Unit Test
• Integration Test
• E2E Test
• 静的解析
• 型チェック
• 人間によるレビュー

などです。

つまり、

「Codexが正しいと言ったから公開する」

のではなく、

「Codexが間違っていてもテストで検出できる」

状態を作る必要があります。

大規模な変更ほど一気にやらない

AIは大量のコードを高速で変更できます。

しかし、それがそのまま安全性につながるわけではありません。

大規模な変更では、

ことが重要です。

たとえば、

1. 一部分だけ変更
2. テスト
3. 問題がなければ次へ進む
4. 一部環境へ反映
5. エラーを監視
6. 徐々に対象を広げる

という方法です。

これはCanary Releaseや段階的ロールアウトと呼ばれる考え方です。

AIによって開発速度が上がるほど、このような安全設計の重要性はむしろ高くなります。

レガシーシステムの移行とAIは相性がよい

Codexの有力な用途の一つが、既存システムのモダナイゼーションです。

たとえば、

• 古い言語から新しい言語への移行
• 古いフレームワークの刷新
• テスト基盤の入れ替え
• 大量コードの書き換え

などです。

この場合も、一気に全面移行するのではなく、

ことが重要です。

具体的には、

1. 既存コードを調査
2. 依存関係を整理
3. 移行計画を作成
4. 機械的な変換をツールで処理
5. 複雑なロジックをAIが修正
6. 移行前後で同じ結果になるか検証

という流れが考えられます。

AIと既存の自動変換ツールを組み合わせることで、すべてをAIだけで処理する必要もありません。

AGENTS.mdは「プロジェクトのルール」を書く

Codexを継続的に利用する場合、AGENTS.mdも重要になります。

AGENTS.mdには、

• ディレクトリ構成
• コーディング規約
• 使用技術
• テスト方法
• 禁止操作
• 変更してはいけないファイル

など、

を書きます。

重要なのは、モデルごとに大量の指示を書き分けないことです。

モデル性能が向上すると、以前必要だった細かすぎる指示が逆に邪魔になることもあります。

したがって、

方が扱いやすくなります。

繰り返す作業はSkillsにする

CodexのSkillsも重要な仕組みです。

Skillsは簡単に言えば、

です。

たとえば、

「毎回PRを確認するときには、

1. CIを確認
2. エラーを分類
3. 修正可能なら修正
4. テスト
5. 再確認

という手順で行う」

といった作業手順をSkillとして定義できます。

人間向けに言えば、

に近いものです。

同じ説明を毎回AIへ行う必要がなくなるため、作業の再現性も高くなります。

PRは「AIが書ける量」ではなく「人が確認できる量」にする

AIは短時間で大量のコードを書けます。

しかし、人間側のレビュー能力は急には増えません。

そのため、

「AIが一度にどこまで変更できるか」

ではなく、

という基準で変更を分割する必要があります。

OpenAIでも、大きすぎる変更は意味のある単位へ分割する考え方が採用されています。

AIによる開発では、

可能性があります。

AI時代の開発で一番重要なのは「モデル選び」ではない

ここまでを見ると、重要なポイントが見えてきます。

AI開発というと、

「AstraとSolのどちらが賢いか」

「Highとxhighのどちらを使うべきか」

という話になりがちです。

もちろんモデル性能も重要です。

しかし、それ以上に重要なのが、

• 適切なモデルを選ぶ
• 必要なReasoning Effortを使う
• Planを作る
• AGENTS.mdでルールを定義する
• Skillsで作業を標準化する
• 自動テストを実行する
• 危険な操作には人間が介入する
• 小さくリリースする
• 問題を監視する

という一連の仕組みです。

つまり、

ということです。

まとめ

OpenAIのQ&Aから読み取れるAI開発の考え方を整理すると、次のようになります。

1. Reasoning Effortは常に最大にしない
2. 複雑な判断だけHighやxhighを使う
3. Plan Modeでも作業段階に応じてEffortを変える
4. AIに与える権限を制御する
5. AIの正しさではなくテストで品質を保証する
6. 大規模変更は小さく分割する
7. AGENTS.mdにはプロジェクトの基本ルールを書く
8. 繰り返し作業はSkillsとして標準化する
9. 人間が確認可能な単位で変更する
10. モデル単体ではなく開発システム全体で品質を担保する

AIによるソフトウェア開発は、

「人間の代わりにコードを書いてくれる便利なツール」

という段階から、

「開発工程そのものを一緒に担当するエージェント」

へ移りつつあります。

だからこそ、これから重要になるのはAIへどれだけ仕事を任せるかではありません。

この設計こそが、AIを実務で使いこなすための中心になっていくと考えられます。