OpenAIのCTOとCodex責任者：AIがソフトウェア構築方法を再構築中

すべての投稿を表示。2026年2月21日公開

OpenAI 応用 CTO と Codex 責任者：AI がソフトウェア構築のあり方を再定義している

OpenAI の応用 CTO であり、Codex エンジニアリングの責任者である二人が、The Pragmatic Summit において OpenAI 内部のエンジニアの実態について語った。Codex はもはやコードを書くだけのツールではなく、「チームメイト」へと進化を遂げた。エンジニアがノートパソコンを閉じて会議に出かけ、戻ってみると仕事はすでに完了しているという状況だ。デザイナーが作成したコード量は、6 ヶ月前のエンジニアよりも多い。あるプロダクトマネージャー（PM）は Codex を活用することで、50 倍の効率を持つプロジェクトマネージャーへと変貌した。

二人のインタビュー対象者は以下の通り。Vijaye Raji（以下 VJ）、OpenAI 応用 CTO（CTO of Applications）。ChatGPT と Codex のプロダクトエンジニアリングを統括。以前は製品実験プラットフォーム Statsig を創業し、2025 年 9 月に OpenAI に 11 億ドルで買収された。マイクロソフトと Meta で合計 20 年以上の経験を持つ。Thibault Sottiaux（以下 Tibo）、OpenAI Codex エンジニアリング責任者。以前は DeepMind と Google で勤務し、現在は直接 33 名の Codex チームを率いている。

司会者の Gergely Orosz は、テクノロジー業界で最も影響力のあるエンジニアリング管理系ニュースレター『The Pragmatic Engineer』の著者である。今回のインタビューは、彼が主催した初回の Pragmaic Summit（2026 年 2 月 11 日開催、サンフランシスコ）からのものであり、約 500 名のエンジニアリングリーダーと実践者が参加した。

OpenAI 内部では、Codex が 6 ヶ月の間に「補助ツール」から「チームメイト」へと進化を遂げ、トップクラスのエンジニアが週に数千億トークンを消費している。エンジニアはタスクをサーバーサイドの Codex に委ねて会議に出かけることができる。

ボトルネックは絶えず移行している：コード生成の問題は解決したが、次なるボトルネックはコードレビューとなり、その次は統合とデプロイである。チームは次の卡点（つまずきポイント）を継続的に追跡する必要がある。

デザイナーが作成するコード量は、6 ヶ月前のエンジニアよりも多い。面接では「あなたにはどれだけの計算リソース（Compute Power）を与えるのか」という質問が出始めている。職能の境界線は溶けつつある。

Codex は夜間に自律的に QA テストを実行し、モデルを独自に訓練し、PDF 形式のレポートを作成できる。研究者たちは何度も、Codex の能力を過小評価していたことに気づかされた。

今年夏、OpenAI は約 100 名の新卒者を迎える予定であり、チームは「AI ネイティブ」な新人が独自の優位性を持つと考えている。

今後 6 ヶ月でさらに一桁の速度向上が見込まれており、マルチエージェント（Multi-Agent）協働ネットワークによって「24 時間でゼロからブラウザを再構築する」ということが可能になる見込みだ。

【1】Codex はもはやツールではなく、チームメイトである

Gergely が冒頭で VJ に直接質問した。OpenAI 内部では何が起きているのか？

VJ は答えた。過去 6 ヶ月間で彼は明確な進化の道筋を目撃したと。Codex はツールから機能拡張へ、さらにエージェント（Agent）へと進化した現在、すでにチームメイトとなっているのだ。

「私は完全に、エンジニアたちが今や自分のエージェントに名前をつけ、それをチームメイトとして呼ぶようになることを期待している。」

彼はさらに内部データを補足しました。OpenAI には使用状況のランキングがあり、一部のエンジニアは週に数千億トークンを消費しています。しかも、これは単一のエージェントが作業しているわけではありません。先週、チーム内では「Codex Boxes」という機能が導入されました。この機能ではサーバー側で開発環境を予約でき、エンジニアは自分のノートパソコン上でタスク指令を編成し、ノートパソコンを閉じて会議に出かけます。戻ってきた時には、すべての仕事が並列に完了しています。

"People shut down their laptop, go to a meeting, come back and then all of the work has been done."（人々はノートパソコンを閉じ、会議に行き、戻ってくるとすでにすべての作業が完了しているのです。）

VJ は、このような働き方が数ヶ月以内に業界の標準になると考えています。

【注】Codex は OpenAI の AI プログラミングツールで、2025 年 5 月に初めてリリースされました。クラウド版（隔離コンテナ内で独立してタスクを実行）とコマンドライン版（Codex CLI、ローカルターミナルで実行）の両方があります。現在では VS Code 拡張機能、デスクトップアプリ、Web アプリなど複数の入口をサポートしています。2025 年末時点で、OpenAI エンジニアの約 95% が Codex を使用しており、週ごとの PR（Pull Request：プルリクエスト）の合併数が 70% 増加しました。

しかし Gergely は、重要な現実を補足しました。彼は OpenAI 内部の多くのエンジニアと個人的に話し合いましたが、全員が 100% Codex でコードを書いているわけではなく、使用度合いには差があるということです。ただし、あるチームは確かに最前線を走っています——それが Codex チーム自身です。

【2】ボトルネックの連続的な転移：コード生成からユーザーニーズの理解へ

Gergely は続けて Tibo に尋ねました。Codex チームは具体的にどのように働いているのか？

Tibo によると、チームはほぼ毎週自らの働き方を再発明しています。核心的な方法はボトルネックを特定し、それを解決することですが、ボトルネックは常に転移します。最初はコード生成でしたが、次はコードレビューでした。現在は「いかにしてユーザーニーズをより速く理解するか」「いかにしてチケットを分類するか」「Twitter や Reddit などのチャネルからのフィードバックを総合的に集約し、製品戦略を形成するか」という課題に焦点が移っています。各工程でエージェントを活用して加速を図ろうとしています。

彼は興味深い詳細も語りました。最近、Codex チームへの加入を検討している人が面接で質問しました。

"How much compute am I going to get to build products at OpenAI?"（OpenAI で製品を作る際、どれほどの計算リソースが与えられるのか？）

Tibo によると、この質問に彼は一瞬立ち止まりました。過去にはこのような質問は、大規模モデルの訓練を行う研究者だけがしていました。しかし今ではエンジニアも「1 人あたりの計算リソース割当」に関心を持つようになりました。

この変化は何を意味しているのでしょうか？Tibo は、優れた審美眼を持ち、良いアイデアがあり、ソフトウェアの作り方を理解していれば、現在のレバレッジ（効果増幅率）はかつてないほど高いと考えています。

OpenAI 全体を眺めると、VJ は補足しました。製品直感は依然として核心です。彼自身も Codex でコードを書いていますが、多くの場合ボトルネックはコードそのものではなく、「製品がどのようなものであるべきか」という想像力にあることに気づきました。この部分は依然として人間が行う必要があります——ただし、将来的に Agent（エージェント）のために而非人間のユーザーのためにソフトウェアを構築し始めるまでです。

VJ はまた、小さなエピソードも語りました。彼は飛行機の中で Codex でコードを書いていましたが、客室乗務員がパソコンの電源を切るよう指示してきました。彼はノートパソコンを半開きのまま置き、エージェントの実行を中断したくなかったのです。彼は今や誰もがノートパソコンを半開きにしたまま歩き回っていると言います。

彼はこの状況こそがソフトウェア開発をより面白くしていると感じています——フィードバックサイクルが大幅に短縮され、製品が形になり、テスト検証が行われ、再び Codex で反復されるというプロセスの達成感が早く得られるからです。

【3】新しいエンジニアリング実践：並列探索、デザイナーによるコーディング、夜間の自動テスト

Gergely が追及します：どのような新しい、異なる、あるいは「奇妙な」エンジニアリング実践が現れ始めていますか？

一つ目は並列探索です。過去には複雑な技術選定に際し、チームは設計ドキュメント（design doc）を作成し、会議で議論して代替案を除外していました。現在では、Codex に複数の実装を同時に実行させ、実際にどの方が効果が高いかを確認します。意思決定が「議論後に一つを選ぶ」ことから「実装後に比較する」へと変化しました。

二つ目はさらに驚くべき点：役割の境界が曖昧になっています。

"Our designers are shipping more code than engineers were shipping six months ago."（私たちのデザイナーは、6 ヶ月前のエンジニアよりも多くのコードをリリースしています。）

これは、モデルのコード品質がすでにマージ可能なレベルに達しているからです。

VJ は小さなシナリオを追加しました。Codex チームは動画処理を行っており、頻繁に ffmpeg（機能は強力ですがコマンドライン引数が極めて複雑な動画処理ツール）を使用します。誰しもがそのコマンドライン引数を覚えておくことはできませんが、今では Codex に「何をしたいか」を伝えるだけで、正しいコマンドを生成して実行してくれます。

VJ はさらに大きな図景も指摘しました：ボトルネックの転移は連鎖反応を引き起こすのです。コーディングの問題を解決すれば、各エンジニアのコード生産量は 5 倍になります。コード量が増えれば、コードレビューが新たなボトルネックとなります。レビューの問題を解決すれば、次は統合とデプロイ（CI/CD、継続的インテグレーション/継続的デリバリー）がボトルネックになります。チームは常に次のレベルの問題を解決し続ける必要があります。

Gergely はさらに、彼が「SF のような」実践と感じる通宵実行について質問しました。

Tibo によると、多くの人が AI プログラミングへの印象を「強化された自動補完機能で、小さな機能を 10 分で完了させるもの」と捉えているようですが、実際にはモデルの能力はそれをはるかに超えています。大きなタスクを与えれば、数時間連続して実行できます。

Codex チームは完全な環境とスキル設定を整備し、Codex が夜間に QA（品質保証）テストサイクルを自律的に継続実行し、回帰問題をマークできるようにしました。エンジニアは翌日結果を確認するだけで済みます。

そして Tibo は、モデル訓練を担当しているチーム内の一人の研究者の感想にも触れました。その研究者自身も「興奮すると同時に少し落胆した」と述べています：

"Every time I think I'm more capable than Codex, I figure out I'm wrong and I just didn't prompt it right."（Codex より自分が優れていると思うたびに、自分が間違っていたことに気づきます。ただプロンプトの書き方が悪かっただけです。）

この研究者は、Codex がすでに独自にモデルを訓練できるようになり、訓練完了後に発見と洞察を含む PDF 報告書を作成することも発見しました。チームはその報告書から最も価値のある方向性を見極め、新しいタスクを Codex に入力して継続的に反復します。

【注】この記述は「AI が AI を改善する」循環を描いています：Codex がモデルを訓練 → 報告書を出力 → 人間が方向性を選別 → Codex がさらに反復。これは AI 研究において「自己改良ループ（self-improvement loop）」と呼ばれています。

Gergely はもう一つの実践にも言及しました。Codex チームは週次でデータ分析会議を開く際、その場で Codex のスレッドを起動します。Tibo が具体的なプロセスを説明しました。会議の開始時、参加者はダッシュボードに既成の答えがない問題を提起します。データアナリストが即座に Codex スレッドを開始し、バックグラウンドで処理させます。20 分後には答えが出揃い、会議の最後の 10 分で結果について議論します。一つの会議で同時に 5〜6 の問題に対処できます。

「まるで、裏方として私たちのために働く小さなコンサルタントがいるようなものです。」（就像有一群小顾问在后台帮你干活。）

线上事故响应也是一样。Codex 帮忙诊断问题所在、找到最快的恢复路径，信息收集和问题定位的速度明显提升。

【4】100 名应届生即将入职，“AI 原生”一代来了

行业里一直有个争论：AI 编程时代，初级工程师还有价值吗？Gergely 提到他和 OpenAI 的工程负责人聊过，得知 OpenAI 正在招收早期职业工程师，让两位受访者展开说说。

VJ 说，OpenAI 正在大量招聘应届毕业生，今年夏天的实习项目也在扩大，这一批大约有 100 人。他认为新一代软件工程师将是“AI 原生”（AI native） 的，从第一天起就把 AI 当作默认工具。给他们机会在这样的环境中成长，效果会很惊人。

Tibo 从组织角度补充了他的做法：Codex 团队是极度扁平化的，他一个人有 33 个直接下属。他解释说，当个体的生产力因 AI 大幅提升时，传统的层级管理结构很容易成为瓶颈。一个人卡住所有决策，在这个速度下显然行不通了。

新人入职的第一个工具就是 Codex 本身。用它问问题、浏览代码库、了解同事在做什么、接收日报。而负责入职培训的人，恰恰是最近才刚入职的人——因为他们对”怎么上手”的记忆最新鲜。

Tibo 提到了一个具体的人：一个叫 Ahmed 的应届生，6 个月前加入团队，表现非常出色。

“My brain is probably already in decline... this person Ahmed's brain is just absolute peak.”（我的大脑估计已经开始走下坡路了……Ahmed 的大脑正值巅峰。）

这句自嘲背后是一个观察：新人没有需要覆盖的旧习惯，精力和学习速度都是优势。

Gergely 扮演了一回“魔鬼代言人”：在场很多资深工程师都见证过新人从菜鸟成长为优秀工程师的过程，而这个过程中基础训练至关重要。如果新一代从一开始就用 AI 写代码，跳过了前辈们经历的那些基本功训练，他们的基础够吗？

Tibo 的回答是：基础依然极其重要。团队花大量精力设计整体代码架构，做代码审查，不是把一切都扔给 Codex 然后闭上眼睛。关键在于环境设计——如果你的代码库结构好、护栏（guard rails）设置得当，新人就能在这个框架下发挥出惊人的生产力。

【5】25 年行业变迁：从 IntelliSense 到 AI，每一代都被质疑

Gergely 问 VJ，软件工程师的日常角色到底变成了什么样？

VJ 先说了一句总原则：基础永远不会过时。然后他拉开了时间线。他在这个行业干了 25 年，经历过很多范式转变。在微软时期，他参与开发了 Visual Studio 的编辑器和语言服务（Language Services）。

【注】 VJ 在微软工作近十年，参与了 Visual Studio 编辑器、Windows 应用框架、SQL Server 建模工具等核心项目的开发。他也是 Small Basic（一种简化版 BASIC 语言）的创造者。

彼は初めて IntelliSense（Visual Studio のコード自動補完機能）を見た時の感想を振り返ります：ドットを打つとオプションがポップアップし、その感覚は非常にクールでした。

Gergely は続けます：私が業界に入った頃は、周囲の開発者たちが「IntelliSense を使うのは本当の開発者ではない」と言っていました。

VJ は笑ってこう答えます：そうです。さらに遡れば、「アセンブリを書かないのは本当のエンジニアではない」、次は C++、そして JavaScript だと言われた時代もありました。抽象化のレベルが一つ上がるたびに、誰かが疑いを呈するものです。

彼の結論はこうです：それらは重要ではありません。重要なのは、堅固な基礎と製品感覚（product sense）を持ち、技術スタックの上下を問わず問題を解決できる能力です。これらの能力は時代遅れになることはありません。

【6】Codex を活用して 50 倍の効率を実現した PM の話

Gergely は、プロダクトマネージャーとデザイナーの役割の変化について質問しました。

VJ の核心的な見解は以下の通りです：人間のために製品を構築し続ける限り、人間のデザイナーやプロダクトマネージャーが必要です。製品感覚（product sense）やデザイン感覚（design sense）に代わるものはありません。しかし、これらの役割もより効率的になっています——PM がコードを書き、デザイナーがコードを書きます。デザイナーは設計を直接実行可能なプロトタイプに変換し、エンジニアを探す前に検証を行います。また、PM も Codex を活用してスライドや Excel プラグインを作成しています。

Tibo は内部の知識共有メカニズムについて補足しました：Slack 内の Codex チャンネルと「hot tips」チャンネルは非常に活発で、チームは定期的にハッカソン（hackathon）やショーアンドテール（show and tell）を開催し、優れた AI の活用方法を素早く広めるよう努めています。

その後、Tibo は具体的な事例を語りました。Codex チームには Alexander Embiricos という PM が一人しかいません。この一人がどうやって 33 人のエンジニアチームを管理しているのでしょうか？

答えは Codex そのものです。Tibo は最近実施したバグバッシュ（集中してバグを探す活動）のフローを説明しました：1 時間以内に、リリース直前の機能をチェックしフィードバックを提出します。終了後、Alexander は Codex にフィードバックの要約と Notion ドキュメントへの出力を指示し、さらに Codex に問題点をバグレポートや機能改善リクエストに分解させ、Linear（プロジェクト管理ツール）に登録して対応エンジニアに割り当てます。その後、Codex を使って各メンバーの進捗を追跡します。

「彼は AI を活用することで、10 倍、あるいは 50 倍の効率を持つプログラムマネージャーへと変貌したのです。」

【注】Alexander Embiricos は Codex のプロダクトリード（Product Lead）であり、エンジニア向けペアプログラミング製品を創業した経験を持ち、OpenAI 加入前には AI 支援開発分野で長年の実績があります。

VJ は補足しました：多くのデモデイ（内部発表会）に参加し、一つの傾向に気づきました。それは、発表されるプロジェクトの深さが継続的に増していることです。「これが何ができるか」を見るだけの表面的な展示ではなく、多くのケースでエッジケース（辺境状況）を処理し、実際に使える製品となっているのです。

【7】トークンコスト：使用したトークンの数を問うのではなく、チームメンバーの価値を問え

Gergely はまず重要な前提を説明しました。OpenAI の内部では全員に無制限のトークンが付与されており、コスト制限はありません。観客席からは多くの笑い声が聞こえました——確かにこれは大きな特権です。外部の世界ではコストが依然として現実的な問題となっています。リソースが制限された環境でのチームに対して、お二人はどのようなアドバイスをお持ちでしょうか？

VJ は、コストは OpenAI が継続的に取り組んでいる課題であると述べました。一方ではモデルをより強力かつ低価格にすることを目指し続けています。もう一方では、思考の転換が必要だと考えています。24 時間働き続けるチームメイトがいると想像してみてください。Linear や Jira のタスクを任せて、完全に独立して完了することを期待できるのです。そうすると問題は「このチームメイトにいくら支払うか」ではなく、「使用したトークン数はいくらか」という問いになります。各エンジニアに AI チームメイトを 4〜5 人ずつ配備して生産性を測るなら、コストはより明確に計算できるようになるでしょう。

Tibo は別の角度から補足しました。AI が代替するコストを見るべきだということです。例えば過去には、15 人のエンジニアが時間をかけて機能のバックログ（待办リスト）全体をスクリーニングし、簡単に実装できるものを見極める必要がありました。しかし現在ではこの作業はほぼ無料で行えます。すべての企業が無限の推論リソースを提供できるわけではありませんが、推論利用量を早期に制限することはリスクとなります。彼のアドバイスは、少なくとも社内で最も優秀な人材には十分な推論リソースを与えるべきだということです。

【8】未来予測：6 ヶ月でさらに 10 倍、コードは抽象化される

最後の質問です。2 年後のソフトウェアエンジニアリングと工程管理はどうなっているでしょうか？

Tibo はまず笑って、「2 年は長すぎる」と言いました。彼が敢えて予測するのは 6 ヶ月後です。速度はさらに 1 つ桁（数量級）向上するでしょう。もう一つ確実に実現するのは、マルチエージェント協働ネットワークです。多数のエージェントが連携して非常に大きな目標を達成します。例えば Cursor がデモンストレーションした「ゼロからブラウザを再構築する」という事例では、24 時間後には数百万行のコードを持つ成果物が得られました。この規模のコード量はもはや人間が理解できる範囲を超えています。

【注】Tibo が言及した Cursor のデモは、AI プログラミングツール「Cursor」が示す大規模コード生成能力を指しています。

そのため Tibo は、今後コードを取り巻く「ガードレール（安全装置）」が登場すると予測しました。コードそのものを見る必要はなく、形式検証（formal verification）によって正しさを証明するか、あるいは安全な範囲内に収束させることを保証すればよく、入力と出力のみに関心を持てばよいのです。コードは抽象化され、真に重要なのはシステムの属性となります。

VJ は歴史的観点から補足しました。ソフトウェアの抽象化レベルは常に向上しており、より少ないコードでより大きな製品を構築できるようになっています。現在、この傾向の加速自体がさらに高まっていると指摘しました。しかし彼は懸念も示しました。システムが十分に複雑になると、デバッグ（問題解決）が極めて困難になるということです。将来のエンジニアは医師が患者を診断するように、「症状」に基づいて問題を特定するようになり、ツールもその方向へ進化していくでしょう。

Tibo は最後に近未来の予測を追加しました。年内にはパーソナルアシスタント層が登場します。100〜200 の個別の小さなエージェントを監視する必要はなく、すべてのバックグラウンドエージェントの作業を代表する単一の総括的なパーソナルアシスタントが現れます。ユーザーはただその 1 つのアシスタントと対話すればよいのです。

VJ は全体の変化の速度について判断を下しました。彼は業界で 25 年間を過ごし、インターネットバブル、Y2K（2000 年問題）、モバイル革命、ソーシャルネットワーク革命を経験してきました。しかし今回は全く異なります。

「私はこれまでこんな光景を見たことがありません。一部の成長曲線は理屈が通じません。」

この対話から読み取れる核心的なシグナルは 3 つあります。

第一に、OpenAI 内部における AI コーディングはもはや「補助」ではなく、「協働」、さらには「委任」の段階にあります。

第二に、ボトルネックは継続的に移行しています。一つの層を解決するたびに次の層が露呈し、コード生成からレビュー、デプロイメント、そして要件理解へと至るまでです。

第三に、「基礎」という定義が静かに変化しています。コードを書く能力はもはや希少ではなくなりつつありますが、製品直感、システム思考、そして抽象化の層の間を柔軟に移動する能力はより一層希少価値を高めています。

無限トークン環境で育まれた働き方が、コスト敏感な現実世界でも再現可能でしょうか？

コードが人間が見る必要がないほど抽象化された場合、セキュリティと監査可能性はどうなるのでしょうか？

AI ネイティブな次世代のエンジニアは、長期的に見てより強固になるのか、それとも基礎が脆弱になるのか。

これらの問いに確定的な答えを出すことは誰にもできませんが、この対話を通じて少なくとも、変化が起きている速度と方向性を目撃することができました。

完全版インタビュー動画：https://www.youtube.com/watch?v=Bo6Gtq3nMXc