ハクソク

世界を動かす技術を、日本語で。

Codexの研究プレビュー

374日前原文(openai.com)

概要

  • Codexは クラウド型ソフトウェアエンジニアリングエージェント で、複数タスクを並行処理可能
  • ChatGPT Pro、Team、Enterprise ユーザーが本日から利用でき、Plus/Eduにも順次展開予定
  • codex-1（OpenAI o3ベース）による 人間らしいコード生成 と安全性・透明性の強化
  • セキュアなクラウド環境で リポジトリ操作・テスト・レビュー を自動化
  • 今後は より柔軟なAIエージェント連携 や開発ツール統合を強化予定

Codex：クラウド型ソフトウェアエンジニアリングエージェントの研究プレビュー

Codexの概要と主な特徴

  • Codexは クラウドベースのAIエージェント で、同時に多数のコーディングタスクを処理することが可能
  • 利用開始： ChatGPT Pro、Team、Enterprise ユーザーが本日からアクセス可能、 Plus/Edu にも近日対応予定
  • 各タスクは 独立したクラウドサンドボックス環境 で実行され、リポジトリが事前ロードされる設計
  • Codexの主な機能：
    • 新機能の実装、コードベースの質問応答、バグ修正、プルリクエストの提案などを自動化すること
    • 各タスクごとに 分離された環境 でファイルの読み書きやコマンド（テスト、リンター、型チェッカー等）の実行を行うこと
  • タスクの完了までの時間は 1〜30分程度 で、リアルタイム進捗監視が可能
  • 完了後は 証拠としてターミナルログやテスト出力 を添付し、変更内容の追跡・検証を容易にすること

Codexの技術基盤と運用方法

  • Codexは codex-1 （OpenAI o3ベース、ソフトウェアエンジニアリング最適化済み）で動作
  • 強化学習を用いて 実際のコーディングタスク で訓練され、人間のコーディングスタイルやPR（プルリク）指向を再現すること
  • ChatGPTのサイドバー からタスク指示や質問が可能
  • AGENTS.mdファイルにより、 プロジェクト特有のルールやテスト方法 をCodexに指示することが可能
  • 開発環境やテスト体制、ドキュメントが整備されたリポジトリ で最良のパフォーマンスを発揮すること

安全性・信頼性への配慮

  • Codexは セキュリティと透明性 を重視して設計
  • 生成コードの 手動レビュー・検証 を推奨し、テスト失敗や不明点は明示的にユーザーへ通知すること
  • 悪意あるソフトウェア開発の防止 に特化した訓練とポリシー強化を実施
  • エージェントは 完全に隔離されたクラウドコンテナ 内で動作し、インターネットアクセス不可
    • 外部Webサイト・API・他サービスへのアクセスは遮断すること

先行利用事例と効果

  • OpenAI社内では リファクタリング・テスト作成・バグ修正 等の反復作業や新機能の足場作りに活用
  • Cisco ：エンジニアリングチームのアイデア実現・フィードバック提供
  • Temporal ：新機能開発・デバッグ・テスト自動化・大規模リファクタリングの促進
  • Superhuman ：テストカバレッジ向上・統合失敗修正・PMによる軽微なコード変更
  • Kodiak ：デバッグツール作成・テストカバレッジ向上・自動運転技術開発の加速
  • 複数エージェントによる並列タスク割り当て や多様なプロンプトの実験を推奨すること

Codex CLIのアップデート

  • Codex CLIは ローカル端末で動作する軽量オープンソースエージェント
  • 本日より codex-1の小型版（o4-miniベース） がCLIのデフォルトモデルとして利用可能
    • 低遅延のコードQ&A・編集に最適化し、APIでもcodex-mini-latestとして提供
  • ChatGPTアカウント連携 でAPIキー設定が簡素化、Plus/Proユーザーには 無料APIクレジット を期間限定で付与
  • CLIからのタスク割り当てや今後のツール連携強化を計画すること

利用可能性・価格・制限事項

  • Codexは 数週間は追加料金なしで広く提供、その後は 利用制限・柔軟な従量課金 へ移行予定
  • codex-mini-latest モデルはAPI経由で利用可能（入力100万トークン/$1.50、出力100万トークン/$6、プロンプトキャッシュ75%割引）
  • 現状の制限：
    • フロントエンド作業用の画像入力や、タスク中のエージェントへの指示変更は未対応
    • リモートエージェントへの委任は対話的編集より時間がかかるため慣れが必要
  • 今後は 非同期コラボレーションや複数エージェント連携 の進化を予定

今後の展望

  • 開発者が 自分の得意分野に注力し、残りをAIエージェントに委任 する未来を目指すこと
  • リアルタイム協働と非同期タスク委任 の融合が進む見込み
  • Codexエージェントは IDEや日常ツールとの統合 が進み、質問・提案・長時間タスクの委任が一元化されること
  • タスク途中でのガイダンスや進捗通知、より柔軟なワークフロー の導入を計画
  • ソフトウェアエンジニアリング分野でのAI生産性向上 と、その社会的影響の研究をパートナーと推進すること

付録・参考情報

  • codex-1の システムメッセージ を公開し、デフォルト動作やカスタムワークフローへの調整方法を明示すること
  • AGENTS.mdファイルに記載されたテストを自動実行すること等、カスタマイズ可能

本記事はOpenAI Codexのリサーチプレビューに関する公式発表の要点を日本語で整理・編集したものです。

Hackerたちの意見

以前、銀行で働いてたんだけど、法務チームがコンプライアンス関連の問題でアプリにちょっとした変更をお願いしてきたんだ。今は自分たちで直せるようになったみたいで、彼らもすごく誇りに思ってるだろうし、嬉しいと思うよ。

└

法務が何かに触れるときは、コードを実行してテストする能力とコードレビューが必要だと思うから、多分無理だね。

└

それは面白い新しいバグトラッカーになるね：会社の誰でもバグを報告したり、将来のリクエストを追加したりできるようになる。もしモデルが自動で解決できれば完璧だけど、そうでなければ誰かが引き継ぐかも。興味深いのは、どのコード変更が法的に問題ないか、会社が望む基準に合っているかってことだね。だから、非技術的なコード/問題レビューアーはすごく重要で普遍的な仕事になるだろうね。

└

法務チームがコード変更を推進してるなんてことは絶対ないよ。

Assembledのチームのエンジニアたちと一緒にCodexのアルファテストに参加してるんだけど、かなり印象的だよ。これまでCursorやClaude Codeみたいなローカルエージェントを使ってたから、あんまり期待してなかったんだけど、Codexは数カ所で光ってるね。並行タスク実行ができて、数十個の小さな編集（リファクタリング、テスト、ボイラープレート）を同時に実行できるのがすごくいい。CursorやClineではなかなかできないことだから、同時にたくさんのタスクを処理できるのは超便利。まるでステロイドを使ったジュニアエンジニアみたいで、ファイルや関数を指定して変更を伝えるだけで、大体のPRを自動で作ってくれる。プロダクション準備にはまだたくさんの作業が必要だけど、今や無限のジュニアエンジニアがそれぞれ違うことをやってる感じだよ。モデルの品質は良いけど、他のモデルと比べてそんなに優れてるとは言えないかな。Cursor + Gemini 2.5-proとの並行テストでは、名前やスタイル、ロジックは比較的区別がつかないから、品質は基準を満たしてるけど、まだ超えてはいないね。

└

プロダクション準備にはまだたくさんの作業が必要だけど、今や無限のジュニアエンジニアがそれぞれ違うことをやってる感じだよ。ジュニア開発者の問題は、完全に自立してないから、彼らを指導したりコードをレビューしたりするのに結構な時間を取られることだよね。もし彼らに簡単にアクセスできても、そのオーバーヘッドがすぐにボトルネックになっちゃうと思う。これらのバーチャル開発者をたくさん管理するのは大変だと思う？それとも結構自立してるのかな？

└

Cursorの利点は、フィードバックループが短くて、ライブで見ながらいつでも介入できるところだよね。Codexはそんなに優れたモデルで、ほとんどバックグラウンドエージェントの方向性を取る価値があるのかな？それだとフィードバックループが長くなるように見えるけど。

└

並行タスク実行ができて、数十個の小さな編集を同時に実行できるのがすごくいい。 > まるでステロイドを使ったジュニアエンジニアみたいで、ファイルや関数を指定して変更を伝えるだけで、大体のPRを自動で作ってくれる。プロダクション準備にはまだたくさんの作業が必要だけど、無限のジュニアエンジニアがそれぞれ違うことをやってる感じだよ。これのメリットは何なの？「AIがプログラマーを置き換える」っていう見出しのためのギミックみたいに聞こえるけど。実際、LLMは数秒でタスクを完了するし、時間がかかるのはタスクを指定して、それをレビューして修正する部分なんだよね。プロセスの最も速い部分を並行処理する意味は何なの？

└

これまでCursorやClaude Codeみたいなローカルエージェントを使ってたから、あんまり期待してなかったんだけど。もしよかったら、Claude Codeの強みと限界はCodexと比べてどうだった？Codexの際立った特徴として並行タスク実行を挙げてたけど、Claude Codeでは特に問題だったの？Claude Codeがあなたのチームにどのように機能したかについての他の洞察も価値があるよ。今のところClaude Codeには満足してるし、今月初めにOAIがリリースしたCodex CLIツールにはちょっと期待外れだったんだ。

└

並列タスク実行: 小さな編集（リファクタリング、テスト、ボイラープレート）を何十個もバッチ処理して、コンテキストを切り替えずに同時に実行できるんだ。これは最近のZedのアップデートの一部でもあるよ。私は通常、自分のClaude APIキーでZedを使ってる。

└

カーソルは今、並列タスクをサポートしてるんじゃない？個人的にはあまり使ってないけど、友達が使ってるよ。一人のバカの視点を聞きたいなら、モデルの質に超集中してほしい。今の障壁はツールじゃなくて、モデルが大量の作業に対して十分じゃないってこと。もっと重要なのは、彼らはまだジュニア開発者よりもインターンに近いってこと。簡単なタスクをやるにも、たくさんの指導や常にフィードバック、厳しい目が必要なんだ。o1プレビューやプロレベルの質で、すごく高くないモデルが見たいな。特にプログラミングの多くは文法の問題じゃなくて、根底にある概念を理解することだから、そこが弱いんだよね。今はツールがどうでもいいから、ほんとに良いモデルを、腎臓を売らなくても手に入れたい。

└

AIエージェントの会社のCTO（AIラボと協力してるところ）が、エージェントはちゃんと動くって言ってるよ。新しいことは何もないってさ。

└

面白いサイクルに入ってるみたいだね。何百万ものエンジニアがGitHubでオープンソースに貢献してる。その中で、頭のいい人たちがそのコードを使って、まさにそのエンジニアたちを置き換えるための強力なモデルを開発してる。実際、あるグループがGitHubに貢献すればするほど、そのグループを置き換えるのが企業にとって簡単になるんだ。特にフロントエンドエンジニアは今のところ一番影響を受けてるよ。これって、時間が経つにつれて人々がオープンソースに貢献するインセンティブが減るってことなのかな？追伸、今のトレンドは私たちソフトウェアエンジニアへの警鐘だと思う。私たちはすごくクリエイティブな仕事をしてると思ってたけど、実際には知識労働者の基本的な仕事、つまり知識を取り出して、基本的で予測可能なバリエーションを補完するのに多くの時間を使ってるんだ。残念ながら、今のAIはこのタイプの仕事を置き換えるのが本当に得意なんだよね。楽観的な見方をすれば、長期的にはもっと面白い仕事を発明したり広げたりできると思うけど、どれくらい待たなきゃいけないかは分からない。今の世代のソフトウェアエンジニアは、供給過多だけど需要が低い状況が続くかもしれないね。

└

プレゼンテーションでは、彼らが行う変更が最小限の侵襲であることが強調されていました。それは、クロードがよくやるようなビジョンクエストに行く可能性が低いってことのように聞こえました。あなたもそれを観察したことがありますか？

└

どんなジュニア開発者を雇ってるの？まだプロダクション準備にたくさんの作業が必要なんて。私はジュニア開発者と一緒に働いてるけど、彼らは指示を受けないとどこに向かっていいかわからないし、大きな機能の実装をガイドするのは無理だと思う。でも、簡単なコード変更は全然問題ないよ。LLMは便利で、コードアシスタントとして結構好きだけど、実際の作業をする面ではジュニア開発者にもほど遠いね。

ライブストリームで「microVM」って言ってたね。特にブラウザやインターネットアクセスがないのが注目ポイント。専門的なFirecrackerやUnikraftなどのマイクロカーネルを動かすのは、スピードもコストも全然違うから、スケールアップするのには理にかなってる。でも、「自分のコンピュータを持つエージェント」への移行には大きな技術的なスケーラビリティの壁があると思う。ChatGPTオペレーターはすでにブラウザを持ってるから、できるとは思うけど、需要は桁違いに違うだろうね。ModalやCloudflareみたいな、AI専用のフル機能コンピュータ環境を提供するインフラ企業にはチャンスがあると思う。フォークやスナップショット（中断・再開）、画面アクセス、人間の介入サポートなんかを含めて、かなり儲かると思うよ。ブラウザ使用とかはあるけど、全体の流れをまだキャッチアップしてないよね。

└

これをE2Bデスクトップデモで提供してるよ: https://surf.e2b.dev SDK: https://github.com/e2b-dev/desktop

└

Modalではこれが唯一の焦点ではないけど、大きな焦点だよ！[1] コードエージェントは今のLLMのキラーユースケースで、これが私たちのGPU推論やトレーニング能力を補完している。私は静かに、エージェントが決定論的で再現可能なデブボックス技術（例えば、Nix、ロックファイル、パッケージミラーリング）の leverage を高めると賭けているんだ。これが私たち人間のエンジニアにも大きな勝利になると思うよ。1. https://modal.com/use-cases/sandboxes

[私はSWE-benchの共同制作者の一人です] チームはすでに非常に強力なo3の結果をさらに改善することに成功したけど、数パーセントの改善しか見られないのが興味深いね。Verifiedで75%から85%に到達するのに、20%から75%に上がるのと同じくらい時間がかかるのかな。

└

完全に見当違いかもしれないけど、swe-benchでベンチマックスが進行中のように感じる。マルチswe-benchの結果を見てみて - https://multi-swe-bench.github.io/#/ swe polybench - https://amazon-science.github.io/SWE-PolyBench/ Kotlin bench - https://firebender.com/leaderboard

└

20%から75%に上がるのにどれくらいかかった？

プレビュー動画で、Katy Shiの「エンジニアリングの仕事が移ってきた反映だと思う。今はコードを書くよりもレビューに多くの時間を使っている」というコメントが良かった。Open AIのプレビュー動画: https://www.youtube.com/watch?v=hhdpnbfH6NU&t=878s 「AIネイティブ」やソフトウェア構築の未来を考えると、今のところ開発者はシミュレーションを見るよりもコードやテストを読むことに集中しているのが興味深い。ソフトウェア開発の新しい概念として、シミュレーションはより広範な結果を提供できるし、特にフロントエンドではコードやテストだけよりも評価がはるかに簡単だ。これは私が探求していることだから偏ってるかもしれないけど、Codexのローンチ資料を見て、すごく感じた。

└

シミュレーションを見るのではなく 自動テストスイートみたいなことを言ってるの？

└

これがグラファイトに関する私の全体的な主張だね。AIが生成するコードが増えるにつれて、レビューやテスト、統合の重要性が増してくる。AIコードレビュアーを作る手伝いをしている私でも、永遠に人間のスタンプが必要になるんだ。理由はいろいろあるけど、根本的には責任のためだよ。コンピュータは責任を持つことができないからね。

└

シミュレーションについて: Deeboはデバッグのためにこれをやってるよ: https://github.com/snagasuri/deebo-prototype

└

今はコードを書くよりもレビューに時間を使ってる。レビューは決して万能ではない。明らかなミスを見つけるための最善の努力みたいなもので、セカンドオピニオンみたいなものだ。厳密なテストがあって初めて、レビューが他のエンジニアや自分を信頼するのと同じくらいの自信を与えてくれる。一般的に、コードの出力のペースは自分にとってボトルネックになったことはない、むしろその逆（もっと時間があれば短い手紙を書くよ）。最も重要なのは、意味のある境界でテスト可能なコードを書くことが非常に難しくて繊細なアートフォームだってこと。できるだけ正しくやりたいと思うものだ。AIがそれをできるかどうかは言わないけど、それが一番難しい部分だ。自動化されたジュニアエンジニアの軍団でも、yoloプログラミングが引き起こす複雑さには勝てない。いつかコードの変異が、修正するよりも副作用として問題を引き起こすことになるだろう。

└

これはエンジニアリングの仕事が過去に移動したことの反映だと思う。今はコードを書くよりもレビューに多くの時間を使っている。これは常に真実だった。フロントエンドのコードは本当のコードじゃない。バックエンドのコードのほとんどは、データを変換したり移動させたりするだけだ。暗号、圧縮、数学などの「本当のコード」が必要な機能のためには、他の10万人の開発者が使っているライブラリを使う。

これって、実際にAIにタスクを全て任せるためのものなの？私がAIを使ってやるタスクは、少なくともちょっとした手助けが必要で、時には再プロンプトもしなきゃいけないから、並行してタスクを進める意味が分からないんだよね。スループットが増えるとも思えないし。他の人たちがもっといい経験をしてるのか気になるな。

└

悪いAIだと無意味だけど、良いAIだと強力だよ。私の経験では、codex-1はかなり良かった。

└

動画の中の例示ケースはかなり説得力があって、スコープも小さいね。「ここにオンコールに報告されたエラーがある。修正してみて」(失敗しても役に立つかもしれない) 他のことをしているときに気づいたこの小さな部分をリファクタリングしてみて。おそらく他ではやられないような小さなスコープのものだね。実際のコードベースでLLMにフル機能を求めることはないけど、これらの例は彼らがエンドツーエンドで達成できる範囲内のように思える。

└

第三者のAPI（Exa.ai）を使ってて、Pythonスクリプトを適当に組み合わせて作ったんだ。リモートエージェントを走らせて、これらのタスクを同時にやってる（augment.new、関係ないけど、早期アクセス持ってる）。エージェント1：テストを書く、全てのテストが通るか確認する。エージェント2：PythonスクリプトをFastAPIに変換する。エージェント3：FastAPIのエンドポイントに基づいてフロントエンドを作る。PRが来たら、コードをチェックして動くか確認してからメインにマージする。3つのPRは全て問題なく動いたよ（フロントエンドはあんまり見栄え良くなかったけど）。

もし私がバカみたいだったらごめんね、でもプロ版に月200ドル払ってるのに、Try Codexをクリックするたびに「チームプラン」の料金ページに飛ばされるんだよね。これってまだ展開中なの？チームプランは必要ないよね？何年もOpenAIの製品を使ってきたけど、試してみたいのに何が間違ってるのか全然分からない。

└

まだ展開中だよ。

└

私も同じで、2分前に表示されたよ。まだ展開中みたいだね。

└

これって、毎回のメジャーリリースでやってるよね。なんでなのか全然理解できない。

このスレッドを読んでいると、みんながかなり混乱していて、ソースコードがどうやって共有され、構築され、複数のエディターと一緒にマージされるのかというシンプルなプロセスを理解していない（もしくは最初から理解していなかった）ことが明らかだね。

「内部インフラで実行できなかった23のSWE-Bench検証サンプルは除外されました。」これってどういう意味？もう少し詳しく説明すべきじゃない？もしベンチマークで未完了として除外されるタスクが二桁の数だけなら、それはスコアに反映されるべきだよね。

自分に何が起こってるのかわからないけど、Codexを使ってうまく動かすのに数時間無駄にしちゃった。これが失敗し続けるワークフローだ：- コードを書いてくれる。最初は良さそうに見える - GitHubにプッシュする - GitHubの自動テストで問題があるって表示される - Codexに戻って修正を頼む - また良さそうに見える。で、次はどうすればいいの？もう一度GitHubにプッシュを頼むと、最初のプルリクエストの内容が含まれてないプルリクエストができちゃうことが多いんだ。前のプルリクエストの上に重なるんじゃなくて、メインの上に重なるプルリクエストになっちゃう。gpt-4.1-miniを呼び出すようなものを書いてくれって頼んだら、openai.ChatCompletion.createを使ったりして（！？）。結局、Codexのミスを直すためにClaudeを使ってる自分がいる。

└

[フラグ付き]

└

PRをプッシュする前に、ローカルでテストを実行する必要があると思う。実際、Codexが変更を提案する前に、これを生成プロセスの一部にする必要があると思う。

└

Devinとの間にこの問題がある。これらがどのように機能するかについての自分の限られた知識からすると、タスクを全体的に見るにはコンテキストが多すぎると思う。もしOpenAIとDevinが同じパターンに陥っているなら、ここには解決すべき根本的な問題がある良い兆候だ。

└

CodexのためにProにアップグレードしたけど、本当に感心してない。確かに、Rustを使ってるからそれが問題かもしれない（自分のスキルの問題もあるかも）。常に苦労していることの一つは、彼らが使っているコンテナがインターネットから何かを取得するのに問題があることだ：エラー：パッケージyawl-core v0.1.0 (/workspace/yawl/core)の依存関係としてanyhowを取得できなかった。原因：config.jsonのダウンロードに失敗した。原因：https://index.crates.io/config.jsonからのダウンロードに失敗した。原因：[7] サーバーに接続できなかった（30 65ミリ秒後にプロキシポート8080に接続できなかった）。時間が経つにつれてこれが改善されることを願ってるけど、今月以降は更新しないつもり。