ChatGPTのクラウドCodexを使い倒してみた話 — サンドボックスの罠と実戦投入までの泥臭い道のり
最近ChatGPTにCodexなるものが実装されたらしい。Pro版を使ってる身としては触らない手はないと思って早速使ってみたんだが、これがまた癖が強いツールで、使いこなすまでに結構苦労した。同じような苦労をする人が減ればいいなと思って、実際に使って分かったことを書き殴っておく。
そもそもCodexって何なのか
ChatGPTの左サイドバーに突如現れた「Codex」というメニュー。クリックすると「Connect to GitHub」というボタンが出てくる。要はGitHubと連携してコードを自動で書いたり修正したりしてくれるエージェントらしい。Pro/Team/Enterpriseプランで使えて、Plusは順次解放予定とのこと。
最初は「へー、Copilotみたいなもんか」と思ってたんだが、使ってみると全然違う。Copilotが「コードを書く時の相棒」だとしたら、Codexは「勝手にPR作ってくれる部下」みたいな感じ。バグ修正とか機能追加とかテスト生成とか、タスクを投げると勝手にやってくれる。
事前準備で躓いたポイント
使い始める前にいくつか準備が必要だった。当たり前だけどGitHubアカウントは必須。で、連携したいリポジトリの管理権限も必要。最初これに気づかなくて、権限ないリポジトリを選んでエラーになって焦った。
あとMFA（二要素認証）も必須。セキュリティ的には当然なんだけど、普段使ってないアカウントだったから設定するのが面倒だった。ブラウザも最新版じゃないとダメらしい。Chrome使ってたから問題なかったけど。
意外と重要だったのがrequirements.txtとかpackage.jsonの整備。これがないとCodexが依存関係を理解できなくて、環境構築でコケる。あと外部APIを使ってる部分は全部モックに置き換える必要がある。理由は後で書くけど、サンドボックスの制限がキツい。
セットアップは意外と簡単
準備ができたら実際のセットアップ。ChatGPTの左ペインから「Codex」を選んで、「Connect to GitHub」をクリック。OAuthの画面が出てくるから、連携したいリポジトリを選ぶ。この時、複数選べるけど一度に使えるのは1つだけ。
リポジトリを選んだらブランチを選択して「Create Environment」を押す。ここで重要なのが、1リポジトリ1環境じゃないってこと。ブランチごとに環境を作れる。つまり、feature/hogeとfeature/fugaで別々の環境を作って並列作業ができる。これに気づいてから作業効率が爆上がりした。
AskモードとCodeモードの使い分け
Codexには2つのモードがある。AskとCode。最初この違いがよく分からなくて適当に使ってたけど、使い分けが重要だった。
Askモードはリポジトリを読むだけ。コードの設計について質問したり、エラーログの原因を調査したりするのに使う。一方でCodeモードはファイルの編集からコマンド実行、コミットまで全部やってくれる。
実際の作業では「まずAskでエラーの原因を探る→Codeで修正」という流れが一番効率的だった。いきなりCodeモードで「このバグ直して」って投げても、的外れな修正されることが多い。
サンドボックスの罠にハマった話
ここが一番ハマったポイント。Codexのサンドボックス環境、依存関係の解決が終わったら外部通信が完全に遮断される。最初これを知らなくて、外部APIを呼ぶテストが全部コケて頭を抱えた。
apt-getもcurlも使えない。外部APIの呼び出しも全部失敗する。リポジトリ外のファイルも読めない。セキュリティ的には当然なんだろうけど、実際に使うとなると結構キツい制限。
回避策として以下の方法を使った：
依存ライブラリはwheelファイルでリポジトリ内に置く。これが一番確実。pip wheelコマンドで作れる。容量は増えるけど仕方ない。
外部APIは全部pytest用のモックに置き換える。responsesライブラリとか使えばHTTPリクエストのモックは簡単に作れる。DBもpytest-mockでモック化。
環境構築用のsetup.shを作って、最小限の環境を構築する。CIの設定をそのまま使うと重すぎるから、Codex専用の軽量版を作った。
GitHubへの反映フロー
Codeモードでタスクが完了すると、Codexは環境内でコミットを作成する。でも直接pushはしない。「Open PR」ボタンを押すと、下書きのPRが作成される。
このPRはGitHub側で普通にレビューできる。CIも走るし、ブランチ保護の設定もそのまま適用される。レビューが終わったらMergeすればmainに反映される。
直接git pushしない設計は最初は面倒に感じたけど、使ってみると安全で良い。勝手にmainを壊される心配がない。自動化したい場合はCLI版を使えって話らしい。
実際のワークフロー
実際に使ってる流れはこんな感じ：
- GitHubのIssueをCodexに読ませて「このIssue対応して」とCodeモードで依頼
- 実行ログを眺めながら、疑問があればAskタブで質問
- テストが通ったら「Open PR」でPR作成
- GitHub側でレビューしてMerge
- 次のタスクがあれば新しい環境を作って並列実行
特に4番の並列実行が便利。人間だと1つずつしか作業できないけど、Codexなら複数のfeatureブランチで同時に作業させられる。
よくあるエラーと対処法
使ってて遭遇したエラーをいくつか：
依存パッケージが解決できない：前述の通りwheel同梱するか、pipに--no-indexオプションを付ける。最初はrequirements.txtに書けば勝手にインストールしてくれると思ってたけど、外部通信できないから無理だった。
PRが作成されない：GitHubのトークン権限が足りてないか、ブラウザのポップアップブロックに引っかかってることが多い。権限はrepoとwrite:packagesが必要。
タイムアウトする：タスクが大きすぎる。「このファイル全部リファクタリングして」みたいな曖昧な指示だと時間切れになる。具体的に「この関数を分割して」とか小さく切り分けるのがコツ。
CLI版との使い分け
実はCodexにはCLI版もある。クラウド版との違いをまとめるとこんな感じ：
クラウド版はブラウザで完結して安全性重視。外部通信できない代わりに、勝手に変なことされる心配がない。PushもPR経由だし、進捗もGUIで確認できる。
CLI版はローカルで実行できて完全自動化可能。外部通信の制限もないし、git pushも自由。ただし何でもできる分、変なことされるリスクもある。
大規模なリポジトリとか社内のGitHub Enterpriseを使ってる場合は、CLI版でcodex --full-autoして手動でpushする方が現実的かも。
今後の展望
OpenAIの発表によると、今後はIssueトラッカーとの統合とか、CLIからのタスク登録とか、GitLabやBitbucket対応とかが検討されてるらしい。個人的にはGitLab対応が嬉しい。仕事で使ってるリポジトリがGitLabだから。
あとエージェントのワークフローももっと柔軟になるらしい。今は単純なタスク実行だけど、複数のエージェントが協調して動くようになったら面白そう。
使ってみた感想
正直最初は「また微妙なツールが出たな」と思ってた。でも使い込んでみると、意外と実用的。特に以下のケースで威力を発揮する：
- 単純だけど面倒なバグ修正
- テストコードの追加
- ドキュメントの更新
- 依存関係のアップデート
逆に複雑な設計変更とか、外部サービスとの連携が多い機能追加とかは苦手。サンドボックスの制限もあるし、そもそも意図を正確に伝えるのが難しい。
でも「安全なサンドボックス × GitHub PR駆動」という設計は実務フローに溶け込みやすい。Ask/Codeモードを使い分けて、依存をローカル化する手間さえ惜しまなければ、環境構築からテスト実行、PR作成まで一気通貫でやってくれる。
CLI版との使い分けを理解すれば、Devinみたいな自律開発も現実的になってきた気がする。まだ発展途上のツールだけど、可能性は感じる。興味がある人は、まず小さなバグ修正から試してみるといい。意外とハマるかもしれない。
Discussion