OpenAI Codex の使い方
以下の記事が面白かったので、簡単にまとめました。
前回
1. Codex
「Codex」はクラウドベースのソフトウェアエンジニアリングエージェントです。「バグ修正」「コードレビュー」「リファクタリング」「ユーザーからのフィードバックに基づいたコード修正」などに利用できます。実世界のソフトウェア開発向けに最適化されたo3を搭載しています。
OpenAIでは、開発者が自ら主導権を握り、面倒な作業をエージェントに委任する未来を信じています。「Codex」が独自の環境で動作し、リポジトリでプルリクエストを作成していることから、この未来の兆しが見えています。
2. GitHubの接続
「Codex」エージェントにGitHubリポジトリへのアクセスを許可するには、GitHubアプリを組織にインストールしてください。必要な権限は、「リポジトリのクローン作成」と「プルリクエストのプッシュ」の2つです。アプリは、ユーザーの許可なしにリポジトリに書き込みを行うことはありません。
組織内の各ユーザーは、「Codex」を使用する前に GitHub アカウントで認証する必要があります。認証後、ChatGPTワークスペースレベルでGitHubリポジトリと環境へのアクセスが許可されます。つまり、チームメイトがリポジトリへのアクセスを許可した場合、ワークスペースを共有している限り、そのリポジトリで「Codex」タスクを実行できるようになります。
3. Codex のしくみ
プロンプトを指定すると、エージェントは独自の環境で作業を開始します。約8～10分後、エージェントは差分を返します。
プロンプトは「確認を求める」と「コード」のどちらでも実行できます。 「確認を求める」を選択すると、「Codex」はリポジトリの読み取り専用バージョンをクローンし、起動を高速化し、後続のタスクを提供します。一方、 「コード」では、エージェントが実行およびテストできる本格的な環境が作成されます。
(1) 「chatgpt.com/codex」にアクセスしてタスク送信。
(2) 「base image」基づいて新しいDockerコンテナを起動。
リポジトリを任意のbranchまたはshaにクローンし、指定されたworkdirからセットアップスクリプトを実行します。
(3) ネットワークアクセスを無効化。
エージェントはこれ以降、依存関係をインストールできなくなります。
(4) エージェントはターミナルコマンドをループで実行。
コードを記述し、テストを実行し、動作確認を試みます。エージェントは、AGENTS.mdファイルで定義されたlintコマンドまたはテストコマンドを遵守しようとします。エージェントは、指定されたターミナルまたはCLIツール以外の特別なツールにはアクセスできません。
(5) エージェントがタスクを完了すると、差分または一連のフォローアップタスクを表示。
プルリクエスト（PR）を開くか、フォローアップコメントで返信して追加の変更を依頼するかを選択できます。
4. Codex にタスク送信
リポジトリを接続したら、次の2つのモードのいずれかを使用してタスク送信します。
・Askモード (確認を求める)
ブレインストーミング、監査、アーキテクチャに関する質問に使用します。
・Codeモード (コード)
自動リファクタリング、テスト、修正を適用したい場合に使用します。
以下は、Codex を使い始めるためのタスク例です。
4-1. Askモードのタスク例
「Askモード」を使用すると、コードの変更なしでもアドバイスや洞察を得ることができます。
・リファクタリングの提案
「Codex」 は、「ファイル分割」「関数抽出」「ドキュメント強化」など、構造的な改善についてのブレインストーミングに役立ちます。
<hairiest file in my codebase> を見てください。
これを分割し、テストし、機能を分離するためのより良い方法を提案してください。
・Q&Aとアーキテクチャの理解
「Codex」は、コードベースに関する詳細な質問に答え、ダイアグラムを生成します。
クライアントエンドポイントからデータベースまでの完全なリクエストフローを文書化し、mermaidjs ダイアグラムを作成してください。
4-2. Codeモードのタスク例
「Codex」でコードを積極的に変更し、プルリクエストを準備する場合は、「Codeモード」を使用します。
・セキュリティ脆弱性
「Codex」は、複雑なロジックを監査し、セキュリティ上の欠陥を発見することに優れています。
<my package> にメモリ安全性の脆弱性があります。発見して修正してください。
・コードレビュー
プルリクエストのURLに.diffを追加し、プロンプトに含めます。「Codex」はコンテナ内にパッチを読み込みます。
私のコードをレビューして改善点を提案してください。diffは以下の通りです。
<diff>
・テストの追加
最初の変更を実装した後、ターゲットを絞ったテスト生成を実施します。
私のブランチから、以下のファイルのテストを追加してください。
<files>
・バグ修正
「Codex」が問題を特定して修正するには、通常、スタックトレースだけで十分です。
<my package> 内のバグを見つけて修正します。
・製品とUIの修正
「Codex」はブラウザをレンダリングすることはできませんが、軽微なUIの不具合を修正できます。
オンボーディングページのモーダルが中央に配置されていません。修正してください。
5. 高度な設定
「Codex」はすぐに使用できますが、カスタム環境を指定してエージェントに「依存関係のインストール」「コンパイル」「lint」「テスト」「サービスの起動」をプロジェクトのニーズに合わせて実行させることもできます。
5-1. 環境の作成
デフォルトでは、エージェントはユニバーサルイメージを実行するDockerコンテナ内で実行されます。主要な言語（Python、Go、Rust、Java、Ruby）がプリインストールされています。ベースとなるDockerfileを参照してください。
5-2. セットアップコマンドの追加
リポジトリが /workspace ディレクトリにクローンされた後、指定されたすべてのセットアップコマンドが実行されます。
エージェントから最良の結果を得るには、依存関係 (パブリックとプライベート)、lint フレームワーク、ユニットテストの実行に必要なものをすべてインストールしてください。セットアップコマンド (1行に複数のコマンド、または1行に1つのコマンド) を指定し、セットアップファイルをリポジトリに追加します。
5-3. AGENTS.md を作成
「AGENTS.md」を追加して、共通のコンテキストを提供します。これは、エージェントがリポジトリ内での動作を理解するために読み込む標準的な Markdownファイルです。「AGENTS.md」ネスト可能で、エージェントはデフォルトで、最もネストされたルートを参照します。お客様によっては、エージェントに .currsorrules または「CLAUDE.md」明示的に検索するように指示する場合もあります。組織全体の設定は、このファイルで共有することを推奨します。
一般的に含めたい内容は、次のとおりです。
・作業対象となるファイルとフォルダの概要
・貢献内容とスタイルガイドライン
・移行対象となるコードベースの構成要素
・変更の検証方法（lint の実行、テストなど）
「AGENTS.md」のファイル構成例は、次のとおりです。
# コントリビューターガイド
## 開発環境のヒント
- ls でスキャンする代わりに、 pnpm dlx turbo run where <プロジェクト名> を実行してパッケージへジャンプします。
- pnpm install --filter <プロジェクト名> を実行してパッケージをワークスペースに追加し、Vite、ESLint、TypeScript が参照できるようにします。
- pnpm create vite@latest <プロジェクト名> -- --template react-ts を使用して、TypeScript チェックが準備された新しい React + Vite パッケージを起動します。
- 各パッケージの package.json 内の name フィールドを確認し、正しい名前であることを確認します。最上位のものはスキップしてください。
## テスト手順
- .github/workflows フォルダにある CI プランを見つけます。
- pnpm turbo run test --filter <プロジェクト名> を実行して、そのパッケージに定義されているすべてのチェックを実行します。
- パッケージのルートから pnpm test を呼び出すだけで済みます。コミットはマージ前にすべてのテストに合格する必要があります。
- 1つのステップに集中するには、Vitestパターンを追加します: pnpm vitest run -t "<テスト名>"。
- テストスイート全体がグリーンになるまで、テストエラーまたは型エラーを修正します。
- ファイルを移動したり、インポートを変更したりした後は、pnpm lint --filter <プロジェクト名> を実行して、ESLintとTypeScriptのルールがパスしていることを確認します。
- たとえ誰からも指示がなかったとしても、変更したコードのテストを追加または更新します。
## PRの指示
タイトルの形式: [<プロジェクト名>] <タイトル>6. プロンプトのヒント
ChatGPTと同様に、「Codex」の効果はユーザーが与える指示によって決まります。以下のヒントを活用してください。
・grep 可能な名前を使用してください。
「Codex」は文字通り grep を呼び出すため、特定のファイル名、シンボル、または一意のパッケージ名を使用すると、適切な場所を素早く見つけることができます。内部的には、「Codex」関連パッケージには wham というプレフィックスを使用しています。
・作業場所を指定してください。
「Codex」は、単一のファイル、または最大で 100 個程度のファイルを含むパッケージを指定すると、最適なパフォーマンスを発揮します。漠然とした指示では、エージェントが推測するしかありません。
・完全なスタックトレースを貼り付けてください。
ファイルパスと行番号を含む正確なスタックトレースは、「Codex」がバグを即座に特定するのに役立ちます。
・複数のタスクを連続して実行してください。
各タスクは独立した環境で実行されるため、複数のタスクを同時にキューに入れても問題ありません。OpenAI の多くのエンジニアは、簡単な ToDo リストを作成し、複数のタスクを一度に実行することから一日を始めます。
・作業結果に合格/不合格を判定してください。
人間と同じように、「Codex」は変更を検証します。ターミナルにアクセスできるため、ユニットテストや lint で検証可能なものはより確実に実装されます。 (Codex はまだ UI テストをサポートしていません。)
・大きな変更を分割しましょう。
「Codex」に巨大なプルリクエストを送るのではなく、作業を小さく、焦点を絞ったタスクに分割しましょう。タスクを小さくすれば、エージェントが個別にテストしやすくなり、あなた自身もレビューしやすくなります。
・行き詰まったら、Codex に任せましょう。
行き詰まったら、ブランチを作成して問題を Codex に引き継ぎましょう。この戦略を使えば、複数の解決策を並行して検討できます。
・一日を始める前に、いくつかのタスクを開始しましょう。
通勤時間や朝のコーヒーを飲む前にタスクを開始し、戻ってきたときには最新の差分を確認してレビューに備えましょう。
次回
コメント