本動画は、OpenAIが開発するAIソフトウェアエンジニアツールCodexの最新機能と実用例を紹介するプレゼンテーションである。2024年8月以降、利用者が10倍に急増したCodexは、IDE、ターミナル、GitHub、Web、モバイルなど、あらゆる開発環境で動作する統合的なAIエージェントとして進化した。GPT-5 Codexモデルの導入により、コードスタイルの遵守や思考時間の最適化が実現され、まるで経験豊富なシニアエンジニアのように振る舞うようになった。OpenAIの技術スタッフの92%が日常的にCodexを使用し、利用者は週あたりのプルリクエスト数が70%増加している。デモンストレーションでは、iOSアプリのUI実装、大規模リファクタリング、自動コードレビューといった実際のワークフローが披露され、Codecがいかに開発速度と品質を同時に向上させるかが具体的に示されている。
OpenAI Codexの紹介
私はOpenAIでCodexを開発しています。Codexを使って、私たちはAIソフトウェアエンジニアを構築しています。個人的には、これを人間のチームメイトのようなものだと考えるのが好きです。コンピュータ上でペアプログラミングができます。タスクを委任することもできますし、これからご覧いただくように、明示的なプロンプトなしに仕事を任せることもできます。最近、大規模なバイブシフトが起きています。
これは8月から始まりました。当時はかなり良好な利用状況でしたが、それ以来、皆さんのおかげで10倍に成長しました。今日は、このバイブシフトを生み出した最近のアップデートのいくつかをまず共有したいと思います。それから、OpenAIのエンジニアを何人か呼んで、私たちが日常的にCodexをどのように使用しているかの例をお見せします。
何人かはCodexチームでここで開発しています。他の何人かは、OpenAIでCodexの熱心なユーザーです。まず、これらのアップデートについて話しましょう。Codexは今や、あなたが開発するあらゆる場所で動作します。IDE、ターミナル、GitHub、Web、モバイルのいずれであっても。どこにいても、その裏側にあるのは同じ強力なエージェントです。
Codexの主要な改善点
私たちが行った最初で最も重要な改善は、エージェントを完全に刷新したことです。エージェントは2つの要素の組み合わせだと考えています。裏側で動く推論モデルと、それが行動し、世界に変化をもたらし、あなたのために価値を創造できるようにするツールハーネスです。まず、モデルについて。
8月に、これまでで最高のエージェンティックモデルであるGPT-5を出荷しました。それは皆さんのフィードバックに耳を傾け、GPT-5 Codexを出荷することで改善するまでのことでした。これはCodex内での作業にさらに最適化されたモデルで、より賢く、コードスタイルをより良く守り、思考時間を調整することで改善されました。皆さんからのフィードバックで私のお気に入りの言葉の一つは、真のシニアエンジニアのように感じられるということでした。なぜなら、褒め言葉が非常に少なく、悪いアイデアには反論するからです。
次に、新しいモデルを最大限活用するためにハーネスを完全に書き直し、計画立案、MCP、自動コンパクションのサポートを追加しました。これにより、本当に長い会話やインタラクションができるようになり、その他多くの機能が追加されました。この時点で、CLIの使用が急増し始めました。しかし、さらにフィードバックがありました。モデルは本当に良かった。
エージェントは有用でしたが、CLIは初期段階のように感じられました。私たちはフィードバックを歓迎し、Codexを完全にリニューアルすることにしました。承認モードを簡素化し、より読みやすいUIを作成し、大量の磨き上げを追加しました。デフォルトでサンドボックスで動作するため、デフォルトで安全ですが、常にコントロールできます。これは進行中の作業で、先週金曜日に大きなアップデートを出荷しました。
今日、新しいリリースを出荷します。再び、皆さんからさらにフィードバックをいただきました。多くの方がエージェントと協力し、同時にコードを見たいと考えています。これが、IDEに直接ネイティブ拡張としてここに出荷した理由です。あなたのコードと並んで動作し、IDEをコントロールできます。この小さな協力者が得られます。
VS Codeで動作します。Cursorや他の人気のフォークでも動作します。これはすぐに人気が出ました。最初の週で10万人のユーザーがいました。この部屋にいる多くの方もそうだと確信しています。私たちのユーザーの多くは、IDE内で直接Codexを使用することを好んでいます。ここでの魔法の一部は、まったく同じエージェントであるということです。
CLIを動かしているのと同じオープンソースハーネスが、拡張機能の中に直接バンドルされています。同時に、Codex Cloudもアップグレードしていたので、並行してはるかに多くのタスクを実行できるようになりました。私たちにとって、これはまだ始まりに過ぎませんが、携帯電話を通じてCodexに指示できることは信じられないほどクールだと思います。
Cloudタスクは現在90%高速に実行されます。依存関係を自動的に設定し、スクリーンショットを撮ってあなたに送信することで作業を検証できます。エージェントに独自のコンピュータを与えることは、うまく機能するときは本当に魔法のように感じられます。そして、GitHubや今ではSlackのようなツールで、このようなエージェントと作業を始めることができます。これは一人のエンジニアの例です。
何人かの方はご存知かもしれませんが、彼が質問を持ち、別のエンジニアのSteveがすぐに飛びついてCodexに委任しました。ここでCodexはスレッドからコンテキスト全体を受け取り、作業を開始します。数分後、要約と共に解決策を投稿します。実際に問題全体を探索し、コードを書きました。
このすべての進歩は、コードをはるかに速く書けることを意味し、それはまた、レビューすべきコードが集合的に大量にあることを意味します。コードの検証とレビューは今や大きなボトルネックになりつつあります。これについてはしばらく考えてきました。OpenAIでの過去のコードレビューの実験は、有用である可能性を示しましたが、しばしばノイズが多いこともありました。
以前の試みは、ユーザーがシグナルの欠如について不満を言っていたため、オフにする必要がありました。そこで私たちは意図的にGPT-5 Codexを訓練して、超徹底的なコードレビューで優れたものにしました。依存関係をすべて調べ、小さなコンテナ内でコードを深く調べ、あなたの意図と実装で実際に起こることの契約を真に探索し、高品質な発見を持ち帰ります。
現在、多くのチームがデフォルトで有効にすることを決定し、毎回非常に高いシグナルの発見があるため、必須にしたいと考えています。Codexとペアリングしながらトリガーすることも、GitHubのすべてのPRで実行することで完全に自動化することもできます。さて、小さな成長中のチームにとって、忙しい数ヶ月でした。
私たちはCodexを構築するためにCodexを使用してきました。これなしでは本当にできなかったでしょう。さらに楽しかったのは、OpenAI全体が加速するのを見ることでした。今日、OpenAIの技術スタッフの92%、ほぼ全員が毎日Codexを使用しており、昨年7月頃の50%から増加しています。Codexを使用するエンジニアは、週あたり70%多くのPRを提出しています。そして、ほぼすべてのPRがCodexによってレビューされています。
問題を見つけたとき、人々は実際に興奮します。時間が節約されます。より自信を持って出荷できます。実際に機能を出荷した後にバグを見つけるほど悪いことはありません。チームとして統計を見ると、素晴らしい気分になります。しかし、さらに良いのは、昼食時に誰かが「ねえ、私はいつもCodexを使っているよ。これで私がやっているクールなことがあるんだ。聞きたい?」と言うことです。
そこで、何人かのチームメイトと昼食をとる味わいを皆さんにお届けしたいと思いました。彼らは私たちのチームの実際のワークフローを見せてくれます。毎日どのように使用しているか。ChatGPT iOSアプリのUIの反復について話すNachoをステージにお迎えしましょう。
UIの反復開発デモ
ありがとうございます。こんにちは、私の名前はNacho Stoです。OpenAIのコアiOSチームのメンバーです。今日は2つのことをします。ChatGPTアプリを構築する際に頻繁に使用するワークフローについてお話しし、これをどのように行うかを示すデモを共有したいと思います。デモから始めましょう。Tiboに天気アプリを作るよう頼まれました。
空のウィンドウだけのスタータープロジェクトがあります。また、ChatGPTにUIをどのように見せたいかのモックアップを作ってもらいました。そこで、Codexにそのデザインを実装するよう依頼します。素晴らしい。実行中に、Codexがこれをどのように実装するかの特別な点をお話ししましょう。ChatGPTコアチームで働くということは、インフラストラクチャのパフォーマンスに多くの時間を費やすことを意味しますが、ある程度のフロントエンド作業も行います。
最近、ChatGPTの新しいパーソナリティをより発見しやすくするために、パーソナライゼーション画面を簡素化する小さな機能に取り組みました。以前にこのようなことに遭遇したことがあると確信していますが、最後の10%の磨き上げ、たとえばこれらのヘッダーとフッターを揃えることが、実際には時間の90%を取っていました。
しかし、Codexはその10%を手伝うことができます。そして、あなたが他のことをしている間に取り組むことができます。おそらく、他のDev Dayの講演を見ているかもしれません。真の10倍エンジニアになりたければ、Codexを実行している他の9つのターミナルタブを持つこともできます。ジュニアエンジニアからプルリクエストを送られて、数秒以内に彼らが実際にテストしていないことがわかることがありますか。なぜなら、それが動作するはずがないからです。
6ヶ月前にChatGPTや他のエージェントを使用していたら、そのジュニアエンジニアと作業していました。しかし、Codexは違います。Tiboが言ったように、Codexは今やシニアエンジニアだと主張します。コードを書いて、動作すると仮定するだけではありません。それを検証します。私はTDD、テスト駆動開発の大ファンです。
Codexは本当にそのワークフローで繁栄すると思います。テストを実行し、コードを修正し、何度も何度もテストを再実行して合格するまで続けます。しかし、なぜユニットテストで止まるのでしょうか。Codexはマルチモーダルです。つまり、視覚的にも作業を検証できます。数週間前、画像を見ることができるという超能力をCodexに与えました。そこで、書くUIコードのスナップショットを生成することを教えました。
そして何よりも、実際には非常にシンプルです。まず、Swift UIプレビューを抽出するためにユニットテストを実行する非常にシンプルなメカファイルを作成しました。そして、それはCodexが書いた小さなPythonスクリプトを呼び出します。ちなみに、それらの画像を抽出してフォルダに入れるので、Codexが見つけることができます。次に、下のエージェントファイルで、そのスクリプトについてCodexに伝え、作業を検証するために使用するよう依頼しました。
私たちはこのワークフローを使用してChatGPT iOSおよびMacアプリを構築しています。しかし、たとえばStorybookやPlaywrightのようなツールを使用して、Webでも同じことができます。これが私のワークフローです。Codexにスクリーンショットを生成するツールを提供して、書くUIコードを検証できるようにします。チェックして、Codexがどうしているか見てみましょう。さて、スクロールバックすると、コードを読んだようで、既存のコードを再確認し、UIを実装し、良好であることを検証するためのプレビューデータを提供する計画から始まりました。
素晴らしい、そのコードをすべて書き、スナップショットテストを実行したようです。クール。そう、3分間としては悪くないと思います。それを実行しましょう。クール。明らかに非常にシンプルな例ですが、実際にはChatGPTアプリのような大規模なプロジェクトに多くの変更なしでスケールします。タスクに応じて何時間も実行でき、ピクセルパーフェクトになるまで何度も何度も反復します。
何時間も働くといえば、Felに引き継いで、これらの検証ループをより長期間実行し、より複雑な問題に対してスケールする方法を見せてもらいたいと思います。ありがとうございます。
大規模プロジェクトでの活用
ありがとう、Nacho。私はFelerです。ここOpenAIでは、最長セッションや最も多くのトークンを生成した記録を持っています。大きな機能や複雑なコード変更をワンショットで実行するためにCodexを使用できる男として知られています。GPT-5 Codexモデルが7時間以上生産的に動作するのを見てきました。それが私のプロンプトでした。またはマラソンセッションの過程で1億5000万トークン以上を処理しました。これはそのようなプロジェクトの1つです。これは複雑なリファクタリングであり、私の個人的なJSONパーサープロジェクトの主要な機能です。
このような大規模なプロジェクトでは、作業が完了するまで、すべてのテストが失敗しているように見える長い期間があります。特にそのコアな変更を行っているときは。これは、ストリーミングツール呼び出し用に構築されたJSONパーサー、AI時代のためのパーサーです。このPRは15,000行以上のコード変更があります。
そして、Codexからの何時間もの作業で作成されましたが、私からはわずか数分と一握りのプロンプトだけです。プロンプトからプルリクエストまでどのように進むかを見ていきましょう。わずか数回のプロンプトでこれを行います。まず、機能を実装する計画が欲しいとCodexに伝えます。次に、その計画をレビューして実行するよう伝えます。そして最後に、出荷します。
ここで、VS Codeでプロジェクトを開き、Codex拡張機能も開きます。実装したいかなり複雑な機能があり、それを私が読むためにドキュメントで準備しました。Codexに、この機能を実装する計画を書いてもらいたいと伝えます。最終状態を説明しましたが、重い作業をしてもらい、このライブラリをパーサーに統合する方法を調査してもらいたいです。
そこで、Codexに仕様を書くよう依頼します。そして、それを開始します。実際、ここで自動コンテキストをオフにします。少し余談ですが。これを何度かリハーサルしましたが、実際にgit履歴から完成した仕様を見つけて、プロセスの最後まで直接コピーしてカンニングしました。だから、本当にたくさんやってもらいます。例を与えました。調査をするよう伝えました。すでに持っているコードの例に従ってください。それでは、作業中に、計画またはexecとはどういう意味かをお見せしましょう。これが私のplans.mdファイルです。さて、すべてを読む必要がないように、ここですべてを省略しました。160行あります。しかし、実際にやっていることは、設計文書のための設計文書を書いているのです。
Codexは結局シニアエンジニアなので、独自の書類作成も依頼すべきです。そして、ほとんどのエンジニアが設計文書を書くように、この計画は生きた文書になるでしょう。大局を説明し、最新の状態に保つToDoリストと進捗状況を持つことになります。
なぜ私がexec planと言い続けるのか、なぜそう言っているのか。それは、モデルに固定する用語を与え、exec planという用語を使用するときにplans MDを使用してそれを設計し、反復してフォローアップすることを知ってもらいたいからです。それが特別なもの、ただの設計文書や実装仕様ではないことを知ってもらうために、ユニークな用語を与えるのは良いことです。
この仕様には、進捗状況、驚きと発見があります。何に取り組んできたかを追跡するための決定ログもあります。通常、エンジニアにこれほど多くを書くように依頼することはありません。おそらく彼らのプロジェクトが気に入らない場合にのみそうします。しかし、この場合、これはCodexが完成したプロジェクトに向けて舵取りするのに役立ちます。
この大規模な計画に取り組む際の記憶です。このDev Dayトークの後、plans.mdレシピをOpenAIクックブックにアップロードするので、皆さんのリポジトリで採用できます。では、このplans MDをどのように使用するかをどう知るのでしょうか。先ほど述べたように、agents.m MDを使用しました。agents.m MDに数行追加しました。
いくつかの指示だけです。複雑なことに取り組んでいるとき、これがexec planです。plans MDを参照してください。それに従っていることを確認してください。さて、ご覧のとおり、かなりの量の調査をしています。完成した仕様を見てみましょう。完成したセッションに切り替えたので、仕様が書かれています。ここでその計画を開いてみましょう。
これをレビューできます。フィードバックを与えることができます。さて、かなりの量の単語がありますが、やりたかったことです。そして計画があります。いくつかのスパイク、実装したい機能、そしてもちろんドキュメンテーションがあるようです。私には良さそうです。Codexに伝えます。さあ、実装しましょう。
今日はタイプできませんね。さあ、どうぞ。そして、それが実行されている間、Codexに目を光らせておくのが好きです。画面に何かスクロールし続けるものを保ちます。マネージャーは私がまだ働いていることを知っています。テストを見るのが好きです。そこで、これらのテストを開始します。非常に速く実行されます。
ちなみに、Codexがこれらすべてを書くのを手伝ってくれました。シンプルなプロパティテストやシンプルなユニットテストから、徹底的なプロパティテストまで。このクレートにはファジングさえあります。そして、これに目を光らせておきます。長すぎる間赤いままなら、介入して、Codex、もしかしたら撤退する必要があるかもしれません。その計画が少し軌道から外れているかもしれません、と言うかもしれません。さて、このプロジェクトで完成したものを見てみましょう。Codexがそのタスクを完了したところまで先に進みます。ちなみに、それは私の以前のセッションで1時間以上かかりました。だから、かなり先に進んでいます。そして、新しいテストを書いたようです。
すべて合格しています。素晴らしいですね。変更を見てみましょう。おお、すごい。そして、必要なことを実装するために、アップストリームライブラリをベンダー化し、フォークまたは更新したようです。繰り返しますが、これをすべて読み上げる時間は一日中ありません。だから、計画を再び開きます。
計画を開くと、進捗状況で確認できます。いくつかの大きな項目をチェックしました。いくつかのスパイクを完了しました。ドキュメンテーションとreadmeを更新しました。plans MDは、これらすべての計画が生きた文書でなければならないことを指定しています。したがって、これを経営者向けサマリーとして使用して、何を達成したかを知ることができます。
そうすれば、すべてのコードを自分で読む必要はありません。さて、完了したようで、テストは合格しています。それで、今日お見せしたのは、実装のアイデア、機能、プロンプトからわずか数ステップでPRに至ることができるということです。厳格な計画と徹底的なテストにより、モデルは長期間この機能に取り組むことができます。
では、何行のコードを書いたか見てみましょう。なるほど。わずか約1時間の作業で4,200行のコードです。信じられない。今すぐこれをマージすることもできますが、このコードに別の視点が本当に欲しいです。ありがたいことに、次にコードレビューについて話すDanielがいます。こんにちは。
コードレビューの自動化
さて、私の名前はDanielで、Codexチームのエンジニアです。今日はコードレビューについて話したいと思います。Tiboが述べたように、数ヶ月前にGitHubでコードレビューをローンチし、外部的にも特に内部的にも大ヒットしています。私たちはコードレビューが大好きです。すべてのPRで実行しており、見逃していたであろう多くのバグを見つけています。これらのバグの中には非常に複雑で、何を言っているのかを理解するために、コメントを何度も読み直す必要があるものもあります。
そこで、すべてのGitHub PRでコードレビューを有効にすることを強くお勧めします。これは私のCodexリポジトリのPRの例です。オープンソースです。機能をプッシュすると、すぐにCodexが私のコードのレビューを開始し、P1の問題を見つけました。素晴らしい。そこで、「ありがとう、Codex。修正してください」と言いました。そして、その変更を行うバックグラウンドタスクが開始されました。それがマージされたら、「さて、Codex、これで全部揃ったから、もう一度レビューして、問題がないか確認してください」と言いました。そして、別の問題を見つけました。そして、私は恥ずかしくなりました。
これで考えました。機能を作成し、バグをレビューし、バグがあれば修正し、再度レビューし、修正してレビュー、修正してレビューを繰り返して、理論的にはコードに問題がなくなるまで続けるワークフローがあったらどうだろうと。そこで、コードレビューをローカルにも導入することで、これを超簡単にすることにしました。
スラッシュコマンドでその方法をお見せします。これは私が毎日PRを提出する前にやっていることです。さて、小さな機能に取り組んでいます。3つの異なるコミットがあることがわかります。かなり小さなものです。そして、CLIを横で実行しています。
やるべきことは、スラッシュレビューと書いて、エンターを押すだけです。そうすると、ここにいくつかの異なるオプションがあることがわかります。最初のオプションは、PRのようにベースブランチに対してレビューすることです。これは、ベースブランチのすべてのコミットを取得し、mainと比較し、通常のPRと同じように、差分全体を見て、問題を見つけようとします。
他のオプションもあります。コミットされていない変更や特定のコミット、カスタムレビュー指示をレビューするようなものです。しかし、通常一日の終わりに多くの異なるコミットがあるとき、私は全体をレビューします。そこで、最初のオプションを選択します。
次に、ベースブランチを選択する必要があります。通常、mainが最初のものです。だから、もう一度エンターを押します。そして、コードレビューが始まります。では、なぜこれほど優れているのかという質問があります。なぜGPT-5 Codexはコードレビューにこれほど優れているのでしょうか。実際には、非常に技術的なバグを見つけることに特化して訓練したからです。そして、あらゆる種類の異なるファイルを調査するために非常に長い時間をかけます。
何かが間違っている可能性があるという仮説を持ったとき、テストやスクリプトを書いて実行し、PRをマージする前に修正しなければならない重要な問題を1つ、または最大でも2つ提供してくれます。差分を見ただけでワンショットで出てくる20や30の異なることを提供することはありません。
時間を無駄にしません。それで、実際にここにバグがあります。誰か推測した人は、ああ、いいですね。見つけてくれました。P0です。素晴らしい。そして、まさに正しいです。ここでコード内に文字列をハードコーディングするべきではありません。動的に取得する必要があります。だから、今やるべきことは、Codexに「修正してください」と伝えるだけです。通常、コメントさえ読みません。
それで、実行されます。CLIでのレビューの良いところは、実際に親から別のスレッドを生成することです。たとえば、この機能に取り組んでいて、この機能をこのようにやらなければならない、このように実装しなければならないというように、超偏っているとしましょう。レビュースレッドは別です。
新鮮な視点、新鮮なコンテキスト、新しいチャットがあります。同じ実装バイアスを持っていないので、これらのバグを見つけるのに役立ちます。それで、実行されて、変更を提供してくれます。実行中に、実際にすべてのPRでレビューを有効にする方法をお見せしたいと思います。chatgpt.com/codexに行って、GitHubを接続すると、コードレビューを有効にするというボタンがあります。これでコードレビュー設定に移動し、リポジトリレベルの設定を持つことができます。このリポジトリにコードレビューを取得したい、あのリポジトリには取得したくない、というように言えます。しかし、ここにトグルがあり、すべてのプルリクエストをレビューしてくださいと言うだけです。
本番環境にリグレッションを出荷しないようにしてください。戻りましょう。素晴らしい。変更を加えました。見てみましょう。正しそうです。そう、今はプロンプトディレクトリを動的に取得しています。これが完了したので、やりたいことは、スラッシュレビューを再度実行することです。スラッシュレビューを押します。エンター。エンター。素晴らしい。
これで別のレビュースレッドが開始されます。それが実行されたら、うまくいけば問題は見つからないでしょう。しかし、問題があれば、再度続けることができます。それが完了すると、サムズアップが得られます。コミットして、Gitにプッシュすると、PRで最後のサムズアップがCodexから得られ、マージされます。これが私が毎日やっていることです。
PRを作成する前の日常ワークフローでスラッシュレビューを使用しています。本当にありがとうございました。まとめのためにTiboに戻します。
まとめと今後の展望
さて、皆さん。以上です。今日のデモが、私たちがCodexでどのように速く、より自信を持って出荷しているか、そして私たちがどこへ向かっているのかについての垣間見を提供できたことを願っています。まだCodexを試していない方は、npmインストールするだけです。これでターミナルで直接Codexが使えるようになり、Codexとタイプするだけで、今日デモしたものの多くを使い始めることができます。今日お見せしたものはすべて本物で、すぐに使用できます。Codexチームで働いているGabriel Peeleが、CLIのV045が今まさに出たというメッセージを送ってくれました。
いくつかの増分的なアップデートとOAuth MCPのサポートもあり、これは非常にクールだと思います。だから、インストールしてください。これで最新バージョンが得られます。そして、Codexを構築している何人かの人々と一緒に過ごしたい場合は、ブースに来てください。私たちの何人かがそこにいますし、OpenAIでCodexのトップユーザーの何人かもいます。
また、Discordで参加できるQ&Aもあり、これはすぐに始まります。ぜひ声をかけてください。遠慮しないでください。そして、今日参加してくださってありがとうございました。
コメント