OpenAI による Codex の使用方法

Codex は、セキュリティ、プロダクトエンジニアリング、フロントエンド、API、インフラストラクチャ、パフォーマンスエンジニアリングなど、OpenAI の数多くの技術チームで日常的に活用されています。チームはこれを活用して、複雑なシステムの理解や大規模なコードベースのリファクタリングから、新機能のリリースや厳しい期限の中でのインシデント対応まで、さまざまなエンジニアリングタスクを加速しています。

OpenAI のエンジニアへのインタビューと社内利用データをもとに、Codex がチームの業務をより迅速に進め、仕事の質を高め、大規模な複雑さを管理するのにどのように役立っているかを示すユースケースとベストプラクティスをまとめました。

Codex は、オンボーディング、デバッグ、またはインシデント調査の際に、コードベース内の不慣れな領域でもすばやく理解できるよう、チームを支援します。

チームではよく Codex を使って、機能のコアロジックを特定し、サービスやモジュール間の関係を整理し、システム内のデータフローを追跡しています。また、アーキテクチャパターンや不足しているドキュメントを明らかにするのにも役立ちます。Codex を使わなければ、それらを手作業で作成するには多大な労力が必要になります。

インシデント対応時、Codex はコンポーネント間の相互作用を可視化し、障害状態がシステム全体にどのように波及するかを追跡することで、エンジニアが新しい領域を迅速に把握できるよう支援します。

Codex は、複数のファイルやパッケージにまたがる変更を行う際に一般的に使用されます。たとえば、エンジニアが API を更新する場合や、パターンの実装方法を変更する場合、新しい依存関係へ移行する場合でも、Codex を使えば変更の一貫した適用が簡単になります。

これは、数十個のファイルにわたって同じ更新を行う必要がある場合や、正規表現や検索置換では容易に捉えられない構造や依存関係を把握することが更新に必要な場合に、特に役立ちます。

また、コードクリーンアップにも活用されていて、肥大化したモジュールを分割したり、旧式のパターンをモダンなものに置き換えたり、テストしやすいようなコードを準備したりするために用いられています。

Codexは、パフォーマンス上のボトルネックを特定し、対処するために使用されます。

チューニングや信頼性向上のための作業では、エンジニアが Codex にプロンプトを送り、非効率なループ、冗長な処理、高コストなクエリなど、低速またはメモリ負荷の高いコードパスを分析させます。そして、最適化された代替案を提案することで、効率性と信頼性の向上が実現されることがよくあります。

Codex は、現在も利用されているリスクの高いパターンや非推奨のパターンを特定することで、コードの健全性を保つのにも役立ちます。当社のチームは、長期的な技術的負債を減らし、リグレッションを未然に防ぐためにこれを活用しています。

Codex はエンジニアがテストをより迅速に作成できるよう支援します。特に、カバレッジが不足している、または完全に欠落している箇所でその効果を発揮します。

エンジニアは、バグ修正やリファクタリングを行う際、エッジケースや発生しやすい障害パスをカバーするテストを提案するよう Codex に指示することがよくあります。新しいコードに対して、関数シグネチャと周辺ロジックに基づき、ユニットテストまたは統合テストを生成することができます。

Codex は、初期テストで見落とされがちな空の入力、最大長、通常は見られないが有効な状態などの境界条件を特定する際に、特に役立ちます。

Codex は、開発サイクルの開始や終了を加速することで、チームの作業をより迅速に進めます。

新しい機能に着手する際、エンジニアはこれを使って定型コードを自動生成します。フォルダー、モジュール、API スタブを作成することで、各要素を一つひとつ手作業で配線することなく、実行可能なコードをすばやく立ち上げます。

プロジェクトがリリース間近になると、Codex は、バグのトリアージ、実装の最後の詰めの補完、ロールアウトスクリプト、テレメトリーフック、構成ファイルの生成といった、小さいながらも重要なタスクを処理することで、厳しい納期を守るのに役立ちます。

また、製品フィードバックをスターターコードに変換するためにも使用されます。よくある例として、エンジニアは、ユーザーのリクエストや仕様を貼り付けて、Codex に大まかな下書きを生成させ、後で見直して改良できるようにすることができます。

Codex は、予定が細分化されていて中断が多い場合でも、エンジニアが生産性を維持できるよう支援します。Codex は未完了の作業を記録したり、メモからプロトタイプを生成したり、後で見直せる予備タスクを生成するために使用されます。これにより、コンテキストを失うことなく作業の一時停止や再開が簡単にできるようになります。特に当番対応中や会議が多い場合に役立ちます。

Codex は、代替案を見つけたり、設計上の決定を検証したりするような、自由度の高い作業にも役立ちます。問題を解決するさまざまな方法をプロンプトしたり、未知のパターンを探ったり、前提を厳しく検証したりできます。これにより、トレードオフを明らかにし、設計の選択肢を広げ、実装上の選択をより明確にします。

関連するバグを特定するためにも使用されます。既知の問題や非推奨のメソッドがある場合、Codex はコード内の他の箇所にある類似のパターンを特定できるため、リグレッションの発見やクリーンアップ作業の実行が容易になります。

Codex は、構造や背景情報がはっきりしていて、ららに反復の余地がある場合に、最も効果を発揮します。OpenAI のチームが日々の業務で継続的に価値を引き出すために身につけようとしている習慣を、以下にいくつかご紹介します。

大規模な変更を行う場合は、まず質問モードを使用して Codex にプロンプトを作成させ、その後コードモードに切り替えた際のフォローアッププロンプトの入力としてその計画を使用します。この2段階のフローにより、Codex の信頼性を維持し、出力エラーを防ぐのに役立ちます。Codex は、あなたやチームメンバーが1時間ほどかかるような範囲が明確なタスクや、数百行のコードを必要とする作業で、最も効果を発揮します。モデルの性能が向上するにつれて、対応可能なタスクの規模も拡大すると予想されます。

スタートアップスクリプト、環境変数、インターネットアクセスを設定することで、Codex のエラー率を大幅に低減できます。タスクを実行する際は、Codex の環境設定で修正可能なビルドエラーを探してください。これには何度かの反復が必要になる場合がありますが、長期的には効率が大幅に向上します。

プロンプトが PRや Issue で変更を説明する際の書き方に近いほど、Codexはより適切に応答します。つまり、必要に応じてファイルパス、コンポーネント名、差分、ドキュメントの抜粋を含めるということです。「これを [モジュール X] で行われているのと同じ方法で実装してください」のようなパターンでプロンプトを与えると、結果が向上します。

付随的なアイデア、途中の作業、またはちょっとした修正を記録するためのタスクを素早く作成します。一度に完全な PR を作成しようと無理をする必要はありません。Codex は後で作業を再開するためのステージング領域として利用できます。

Codex がプロンプト全体にわたって、リポジトリ内でより効果的に動作できるように、AGENTS.md ファイルをメンテナンスしてください。これらのファイルには通常、命名規則、ビジネスロジック、既知の注意点、またはコードだけからは Codex が推測できない依存関係が含まれます。AGENTS.md ファイルの構成方法については、ドキュメントをご覧ください。

Best-of-N 機能を使うと、1つのタスクに対して複数の回答を同時に生成し、複数の解決策をすばやく比較検討して、最適なものを選択できます。より複雑なタスクでは、複数回の反復結果を確認し、異なる回答の一部を組み合わせることで、より良い結果を得ることができます。

Codex はまだ研究プレビュー段階ですが、すでに開発の進め方については確かな効果をもたらしており、開発を加速し、より良いコードを書き、これまで優先されることのなかった作業にも取り組めるようにしています。

当社では今後の可能性に大きな期待を寄せています。モデルの性能が向上し、Codex がワークフローにより深く統合されていく中で、Codex を活用したソフトウェア開発方法をさらに強力なものにしていこうと努めています。今後もその過程で得られた知見を共有していきます。