OpenAI Codex 製品責任者が語る：規範もロードマップもなしで、我々はどのように製品を開発したのか？
TechFlow厳選深潮セレクト
OpenAI Codex 製品責任者が語る：規範もロードマップもなしで、我々はどのように製品を開発したのか？
「興味と自律性は、AGI時代における人類が最も核となる、そして最も重要な資質である。」
Web3業界の深掘り報道に専念し潮流を洞察編集・翻訳：TechFlow
ゲスト：Alex（Codex 製品責任者）、Romain（Codex 開発者体験担当）
司会：Peter Yang
ポッドキャスト元：Peter Yang
オリジナルタイトル：How OpenAI's Codex Team Builds with Codex (43 Min) | Alex & Romain
放送日：2026年4月5日
要点サマリー
AlexはCodexの製品責任者であり、Romainは開発者体験を担当しています。彼らの話から、Codexチームがどのように運営されているか、またCodexを用いて製品を構築し、従来の製品仕様書やロードマップなしで製品をリリースしているかについて、非常に貴重な洞察を得ることができました。Alexはさらに、プロダクトマネージャー（PM）の将来像や、採用において本当に重要となる要素についても独自の見解を述べています。
注目すべき主張の要約
リアルタイム構築とCodex Sparkの「思考速度」
- 「何かを構築したいと思ったとき……『クイックモード』、あるいはCodex Sparkに切り替えるだけで、あらゆるものを構築するための驚くべき思考速度を得られます。左側がGPT-5.4、右側がCodex Sparkで、平均すると1秒あたり約1200トークンの処理が可能です。これは本当に驚異的な速度です。」——Romain
仕様書と意思決定プロセスについて
- 「私たちCodexチームでは、仕様書をほとんど書いていません。むしろ、現場に最も近い人が可能な限り多くの意思決定を行うよう、多くの作業を割り当てています。そのため、問題が一人の頭では到底収まりきらないほど複雑になった場合にのみ、仕様書を作成します。」——Alex
職務境界の曖昧化とデザイナーの進化
- 「当チームのデザイナーは、今や6か月前のエンジニアよりも多くのコードを書いています。現在の焦点はもはや『コードを生成できるかどうか』ではなく、『何を実装するか』および『製品の品質をいかに保証するか』に移っています。そのため、非常に複雑な機能については、PMではなく、堅実な責任者を立ててシステムの実装・維持を任せることを好んでいます。」——Alex
製品設計哲学：モデルを「不可視」にすること
- 「コア機能の設計には極めて慎重を期しており、ユーザーとモデルの間に障壁を設けず、むしろモデルをより賢くして、より多くのタスクを自動的に完了させることを目指しています。」——Alex
- 「その上で、上級ユーザーが自ら探求・活用できるよう、可能な限りカスタマイズ可能な形で製品をパッケージ化することを考えています。例えば、すでにユーザーがsub-agents（サブエージェント）を実現しています。」——Romain
計画哲学：「中期の不自然さ」を拒否する
- 「OpenAIでは、短期または長期の計画しか立てません。中期計画は一切行いません。なぜなら、それが極めて複雑だからです。短期計画とは、現在から最大8週間先までの目標を指し、8週間が設定可能な最長期間です。また、長期のビジョンも策定します。例えば、1年後の未来を想定し、その頃のモデルがさらに賢くなっていることを想定します。しかし、中期計画は不自然に感じられ、通常は詳細な製品ロードマップの形をとりますが、私たちは基本的にこのようなものを持っていません。代わりに、長期ビジョンを基盤として、その実現を推進する具体的なタスクに集中しています。」——Alex
「インテリジェント・エージェント委任」がもたらすインターフェースの変革
- 「コーディングは『インテリジェント・エージェント委任（agentic delegation）』という形で行われるようになります。ターミナルで複数のタブを開き、数時間にわたって実行させるというインタラクションは、非常に奇妙なものに感じられるでしょう。そのため、まったく新しいインターフェースが必要となり、そのタイミングはまさに今なのです。」——Romain
キャリアステップの消滅と「人材スタックの収縮（collapse the talent stack）」
- 「これにより、ほぼすべての伝統的なキャリア昇進の道筋が曖昧になりつつあります。私たち全員が『ビルダー（builder）』であり、協力して構築しています。スタートアップ企業でPMが存在し、エンジニアが20名程度しかいない場合、それは危険信号かもしれません。AGI時代において、人類にとって最も核心的かつ重要な資質は、興味と主体性（autonomy）です。」——Romain / Alex
採用基準：履歴書より作品が重要
- 「誰かがDMで当チームへの参加を希望した際、私の第一反応は『リンクはあるか？』です。リンクがあれば必ずクリックし、実際に何かを構築しているかを確認します。私はその人の考えや、実際に構築したものを見たいのです。その人がどの大学を卒業したかも、まったく知りません。」——Alex
ライブデモ：Codex Sparkで数秒でゲームを構築
司会のPeter：本日は、OpenAIのCodexチームからAlexとRomainをお迎えでき、とてもワクワクしています。彼らはCodexの新機能の構築方法、Codexが持つ能力、そしてCodexチームが継続的に製品をリリースしていく方法を実演してくれます。まず、ワンショット（one-shot）プロンプトで実際にどんなものが構築できるか、素早くお見せいただけますか？
Romain：
もちろんです。画面共有をさせてください。紹介できるものはたくさんありますが、まずはこの私が開発中のiOSアプリをご覧ください。このアプリに新機能を追加したい場合、単に口頭で「NASAの月面帰還ミッション用に新しい画面を追加できますか？」と指示すれば、GPT-5.4にこのプロンプトを送信し、特定のアプリ向けに新しい画面を生成できます。
一方で、Codex Sparkというモデルもあり、これはあらゆるものについて数秒でアイデア出しや反復を可能にします。Sparkモデルの高速レスポンスの違いを、ご覧に入れましょう。左側がGPT-5.4、右側がCodex Sparkです。平均すると1秒あたり約1200トークンの処理が可能です。これは本当に驚異的な速度です。何かを構築したいとき、例えばゲーム——今回の対話が始まる直前に、私はCodexアプリにアクセスし、ワンショットのプロンプトで『アナログ・クロッシング』風の2Dミニゲームを実際に作成しました。
思考が明確なときは、Codexで特に好きな機能の一つが、Codexを開き、チャットを画面の上部にフローティング表示させることです。こうすることで、このゲームの開発中でも、継続的に反復を行い、新たなアイデアを生み出すことができます。Peterさん、このゲームに対してどのような変更を加えたいですか？
Peter：たとえば、もっと装飾、家や木などを追加して、より生き生きとした世界にしてはどうでしょうか？
Romain：
それではそのタスクを送信します。数秒以内にCodex Sparkが編集を行い、リアルタイムで変化が反映されます。ご覧の通り、新しい木々が既に出現しています。
だからこそ、私はCodexにこんなにもワクワクしているのです。GPT-5.4のような最先端モデルを使えば、数百万行のコードを分析・移行するといった非常に複雑なタスクもこなせます。しかし、ひらめきがあり、思考が明確なときは、クイックモード、あるいはCodex Sparkに切り替えることで、あらゆるものを構築できるような驚異的な思考速度を得られるのです。
仕様書は、10項目程度の要点のみ
司会のPeter：Codexチームが実際にCodexを使って製品を構築する様子を、とても興味深く聞いています。Alexさん、チーム内ではまだ仕様書を書いているのでしょうか？それともGPTに仕様書を書かせるのでしょうか？これらのタスクを動かすためにどのモデルを使っているのでしょうか？
Alex：
私たちCodexチームでは、仕様書をほとんど書いていません。むしろ多くの作業を、現場に最も近い人に意思決定させることに重点を置いています。そのため、問題が一人の頭では到底収まりきらないほど複雑になった場合にのみ、仕様書を作成します。ちなみに、今や一人で覚えられる情報量は非常に多くなっています。なぜなら、多くのコーディング作業を外部に委任できるようになったからです。つまり、今や一人でできることが大幅に増えているのです。しかし、それでも複数人による調整が必要になるケースや、極めて難しい意思決定を迫られる状況であれば、仕様書を作成することもあります。ただし、こうしたケースで書く文書は、極めて短いものになります。たとえば、「10項目程度の要点」という形式で、それだけです。
司会のPeter：わかりました。実際にそれがどう機能するか、お見せいただけますか？たとえば、Codexにいくつかの要点を与え、その後、実際の要件を生成させるなどです。
Romain：
もちろん可能です！ただ、まずはもっとシンプルな例をご覧に入れましょう。仮に、すでにいくつかの機能が実装済みのiOSアプリを開発しているとします。今、プロジェクトに新しい機能を追加したいと考えているものの、方向性がまだ明確ではありません。この時点でCodexの真価が発揮されます。たとえば、Shift+Tabキーを押して「プランモード（Plan Mode）」に入り、「我々は何を構築すべきか？」と入力するだけで、Codexが自動的に初期のプランを生成してくれます。Codexは既存のコードベースを分析し、プロジェクトの現在の状態を理解したうえで、潜在的なアイデアを提示します。同時に、自分の考えを加えて、より洗練されたプランを導き出すこともできます。
この過程では、Codexが現在のコードやファイルに基づいた提案をしてくれることに気づくでしょう。たとえば、「先ほど言及した機能をさらに完成させるべきか？それとも信頼性ダッシュボードを最適化すべきか？」といった問いかけをしてくれます。もし信頼性ダッシュボードの最適化を選択した場合、さらに「最適化の対象ユーザーは誰か？」といった問いを投げかけてくれ、ブレインストーミングパートナーのように思考を助けてくれます。
私はこうした方法を、アイデア創出を駆動する手段として頻繁に使っています。簡単な変更であれば、直接プロンプトを入力し、Codexにコードを生成させることもあります。
Alex：
中程度の複雑さの変更については、具体的なプランを生成させたり、実装方法を推論させたりすることがあります。また、漠然としたアイデアしかない場合は、単にCodexを開き、問題解決の方法を一緒に考えさせることもあります。明確な機能要件が頭に浮かばなくても、Codexは質問や探索を通じて、思考を整理する手助けをしてくれます。
ただ正直に言うと、特に複雑な変更の場合は、Codexが生成したソリューションをそのまま使うことはあまりありません。「プランモード」で探索を行い、明確な思考の枠組みを形成した後、それをエンジニアチームと共有します。最終的には、この思考プロセスそのものが、生成されたプラン以上に重要なのです。
ちなみに、私たちチームのデザイナーは、今や6か月前のエンジニアよりも多くのコードを書いています。これは以前には想像もつかなかったことです。ツールの進化によって、デザイナーが開発に深く関与できるようになったためです。ただ、去年自分が提出したPR（プルリクエスト）が少なすぎると、チームからからかわれることもしばしばあります。小さな修正ばかりだったとはいえ、自分でもっと積極的に貢献すべきだったと感じています。
現在、私たちの焦点はもはや「コードを生成できるかどうか」ではなく、エージェント（Agent）がすでにほとんどのコーディングタスクをこなせるようになった今、「何を実装するか」と「製品の品質をいかに保証するか」が真に重要です。そのため、非常に複雑な機能については、PMではなく、堅実な責任者を立ててシステムの実装・維持を任せることを好んでいます。
デザイナーが6か月前のエンジニアより多くのコードを書く
司会のPeter：Codexアプリケーションは、非常に直感的で使いやすいです。他の専門的な製品と比較すると、Codexの学習曲線ははるかに緩やかだと感じます。他の製品は機能が豊富ですが、習得に多くの時間を要します。Twitterで関連情報をフォローしていないと、そもそも使い方がわからなかったかもしれません。
しかしCodexが私を驚かせたのは、単に使いやすいだけでなく、skills（スキル）やautomations（自動化）といった高度な機能も多数備えている点です。チーム内では、こうした機能を日常的に使っていますか？
Romain：
はい、非常に頻繁に使っています。実際、skillsはCodexアプリケーションの中で最も面白い機能の一つだと考えています。たとえば、Figmaとデザイナーが共同作業している場合、Figmaのskillを開けば、FigmaファイルからすべてのReactコンポーネントや変数などの詳細を抽出し、Codexが自動的に対応するコードを生成します。また、アプリケーションを開発していて、それをVercel、Cloudflare、Renderなどにデプロイ・共有したい場合、skillsを通じて簡単な指示を与えるだけで、Codexが自動的にこれらのタスクを完了します。
最近、友人と話していた際、彼は製品を改善するアイデアをたくさん持っていたので、Codexに「これらのタスクをすべてLinearに登録して、追跡しやすくしてください」と指示しました。そしてLinearのskillを使いました。さらに、「もう寝るから、さっき話したすべてのタスクをあなたが完了させて、完了済みにマークしてください」と伝えました。翌朝起きたら、本当にすべてのタスクが完了していました。
Alex：
先ほどお話しになったアプリケーションの簡便性について、私たちがどのように設計を考えてきたかをお伝えしましょう。この分野では、開発者が日々の業務を簡略化するために、自分自身のために自動化ツールを構築することに熱心です。私たちにとって、製品の鍵となる特徴の一つは、それが極めてカスタマイズ可能であることです。Codexは、オープンソースのツールボックスのようなもので、ユーザーが自身のニーズに合わせて深くカスタマイズできるように設計されています。
新機能をリリースするたびに、Twitterでその機能（まだ正式リリースされていない場合も）について不具合を指摘するユーザーが現れます。その原因は、ユーザー自身がコードを変更したり、フォークしたりしたことに起因することが多いのですが、私にとっては、これはむしろ製品の成功を示す証拠です。なぜなら、こうした先進的なユーザーが、私たちと共に未来を探求し、製品の進化を推進しているからです。
しかし同時に、こうしたハイエンドユーザーだけを対象に製品を構築するのは十分ではないことも認識しています。そうしないと、製品は複雑で難解なものになってしまいます。私たちには、ハイエンドユーザーのニーズを満たしつつ、一般ユーザーにとってもシンプルで直感的な製品にするというバランスを取る必要があるのです。そのため、コア機能の設計には極めて慎重を期しており、ユーザーとモデルの間に障壁を設けず、むしろモデルをより賢くして、より多くのタスクを自動的に完了させることを目指しています。
Romain：
その上で、上級ユーザーが自ら探求・活用できるよう、可能な限りカスタマイズ可能な形で製品をパッケージ化することを考えています。たとえば、すでにユーザーがsub-agents（サブエージェント）を実現しています。こうした機能は、私たちが意図して設計したものではなく、ユーザーが自ら発見・実験したものです。ユーザーがこれらの機能をどのように活用しているかを観察することで、私たちは多くのことを学んでいます。
次に考えるべきは、「こうした機能を他のユーザーにも、いかに簡単に使えるようにするか？」です。Codexアプリは、その良い例です。昨年12月にGPT-5.2 Codexがリリースされた頃、モデルの能力が徐々に安定し、ある臨界点を越えました。ユーザーは、より長時間・より複雑なタスクをモデルに委任できるようになり、モデルは一度にそれらのタスクを完了できるようになりました。
私たちは、tmuxing（ターミナル内で並列タスクを実行するためのウィンドウ分割）を使用しているユーザーの存在に気づき始めました。ソーシャルメディアでは、ピーター・シュタインベルガー氏の写真が話題になりました。彼のスクリーンには18個のターミナルウィンドウが表示され、3つのモニターにまたがっており、まるで「創造的なオープンハンド（広げられた手）」のようでした。ユーザーがCodexをこうした高度な方法で使用しているのを見て、非常にワクワクしました。
同時に、CLIなどの基本製品におけるタスク委任機能を継続的に最適化し、それがきちんと動作するよう努めています。しかし、こうした方法で作業するのは、トップ1％のエンジニアだけである可能性も認識しています。そこで、こうした機能をより直感的に見えるようにするにはどうすればよいかを検討し、Codexアプリを開発しました。
Codexアプリを初めて開くと、それは単なるシンプルなチャットウィンドウのように見えます。すぐに使い始めることができ、正常に動作しますが、徐々にサイドバー、複数タスクの実行、タスク間の容易な切り替えといった機能に気づくでしょう。すると、自分が非常に効率的になっていると感じられるでしょう。さらに、「skills」タブに気づき、そこからさらに多くの機能を探求するかもしれません。私たちが目指すのは、ユーザーがCodexアプリを使っているときに、まるでゲームをプレイしているかのように、常に新しい可能性を発見し続けられる体験です。
Romain：
完全に同意します。そして、これは私たちが最初から抱いていたビジョンでもあります：コーディングは「インテリジェント・エージェント委任（agentic delegation）」という形で行われるようになります。実は、Codexの開発を始めた約1年前から、私たちはこの未来を常に考え続けてきました。エンジニアは複数のタスクを同時に処理できるようになり、モデルが複雑な詳細作業を担うようになると信じています。
ただ正直に言うと、当時のモデルの能力はまだそこまで達していませんでした。GPT-5.2 Codexのリリース、そしてその後の臨界点に到達するまで待つ必要がありました。その臨界点とは、モデルが数時間から数日にわたって非常に徹底的かつ信頼性高く動作できるようになった時点です。その瞬間、私たちは従来のターミナルインターフェースがこの作業スタイルに合わないことに気づきました。ターミナルで複数のタブを開き、数時間実行させるというインタラクションは、非常に奇妙なものに感じられるでしょう。そこで、まったく新しいインターフェースが必要になると気づいたのですが、そのタイミングはまさに今だったのです。
Alex：
Codexの発展を振り返ると、2つの重要な「vibe shift（トレンドの転換点）」がありました。1つ目は昨年8月で、Codex Cloud製品をリリースした時期です。これは非常に優れたアイデアで、ユーザーは大変興奮しましたが、当時はまだ少し早かったかもしれません。そこで、8月に非常に優れた対話型コーディングモデルであるGPT-5をリリースし、モデルが現在対応可能な課題に集中することを決めました。その結果、Codex CLIおよびIDEプラグインをリリースし、数か月でユーザー数が20〜30倍に急増しました。これは本当に素晴らしいことでした。
2つ目の転換点は、昨年12月から今年1月にかけてです。この時期、私たちはついに当初のビジョン——タスクをモデルに委任すること——を実現しました。モデルの能力が新たな高みに達し、より複雑なタスクを自律的に完了できるようになったことで、私たちは全く新しい段階へと進みました。
私たちの計画は短期と長期に分けられ、中期計画は一切行わない
司会のPeter：Codexアプリはどのように開発されたのか、とても興味があります。1年前に「○月にCodexアプリをリリースする」というような年間ロードマップを策定していたのでしょうか？それとも、市場のニーズを観察し、素早くプロトタイピングを行ったのでしょうか？
Alex：
実はどちらでもありません。私たちの研究員アンドレから聞いた非常に優れたアドバイスがあります：OpenAIでは、短期または長期の計画しか立てません。中期計画は一切行いません。なぜなら、それが極めて複雑だからです。
短期計画とは、今から最大8週間先までの目標を指します。8週間が設定可能な最長期間です。この時間枠内で、具体的な目標を設定し、チーム全体で全力を尽くして達成します。これはOpenAIの強みの一つであり、明確な目標を中心にチームを組織する点で非常に優れています。
一方で、長期のビジョンも策定します。たとえば、1年後の未来を想定し、その頃のモデルがさらに賢くなっていることを想定します。たとえば、将来的なモデルは、私たちのPCリソースを借りる必要もなく、一度に1つのタスクだけをこなす制約もなく、独立して動作できるようになるかもしれません。無限のモデルが存在し、タスクを自律的に完了し、コードを自己検証し、自己デプロイ・自己監視まで行えるようになることを願っています。私たちは、手動でプロンプトを入力する必要なく、それらがすべて自動で行われる未来を望んでいます。
しかし、中期計画は不自然に感じられます。それは通常、詳細な製品ロードマップの形をとりますが、私たちは基本的にこのようなものを持っていません。代わりに、長期ビジョンを基盤として、その実現を推進する具体的なタスクに集中しています。
たとえばCodexアプリの場合、当時の戦略目標の一つは、ユーザーを特定のワークスペース（作業空間）から解放することでした。従来の開発ツール（VS Codeなど）は、通常、特定のワークスペース、たとえば特定のコードベースのチェックアウトポイントやフォルダに紐づけられています。git worktreeを使っても、一度に開ける作業ディレクトリは1つだけですし、CLIも同様の制限があります。
しかし、私たちのビジョンはこうです：ユーザーがクラウド上のインテリジェント・エージェント（agent）と協働し、それらのエージェントが自律的に作業できるようにすること。ユーザーが複数のエージェントと同時にやり取りできること、さらには1つのエージェントがユーザーのために複数のエージェントを調整するような体験を、自然で直感的に提供したいのです。
同時に、クラウドに完全依存するだけでは、開発者にとって不便だと気づきました。環境設定が必要になるほか、モデルがタスクを実行中に手動での介入や調整が必要になる場合も煩雑になります。そのため、ローカルフォルダとシームレスに連携しながら、クラウド上のインテリジェント・エージェントとも接続できる、ローカライズされた体験を開発することを決めました。
アプリケーションの開発を開始したとき、私たちはこうした「ビジョン思考」の塊を持っていました。これらは抽象的なアイデアです。同時に、エンジニアたちはさまざまなプロトタイプを試していました。「アプリケーションが欲しい」と言い、さまざまなバージョンの開発を始めました。実際、複数のエンジニアがそれぞれ異なるバージョンのアプリケーションを開発した「ハッカーウィーク」も開催しました。おそらくあなたも参加されたと思いますが、記憶が定かではありません。
このプロジェクトが本格的に始動したとき、唯一明文化したのは「なぜアプリケーションを開発することが良いアイデアなのか？」という理由だけでした。アプリケーションのための具体的な製品仕様書は一切作成しませんでした。製品の方向性は、実際の開発作業を通じて徐々に明らかになっていったのです。
ただし、当時このプロジェクトには議論もありました——本当にアプリケーションを開発する必要があるのか？IDEプラグインはすでに非常に人気があり、プラグインの品質向上に注力すべきではないか？CLIにも大きな可能性があります。では、アプリケーションを開発する意義は何か？どの方向に進むべきか？これがプロジェクト開始時に直面した課題でした。
Romain：
はい、幸運にも、当時すでに非常に成熟したIDEプラグインソリューションを有しており、それを深く最適化していました。ユーザーはVS Code、Cursor、Windsurfなど、さまざまなIDEでこれらのプラグインを利用できます。IDEプラグインのコードベースから得た豊富な経験が、Codexアプリの開発に非常に堅実な出発点を提供してくれました。
Alex：
その通りです。実際、CodexアプリとIDEプラグインは、下層で大量のコードを共有しています。どちらも同じコアのCodex harness（ラストで書かれたオープンソースフレームワーク）に接続されており、CLIもこれを使っています。私たちは、異なるツール間でのコード共有と機能拡張を可能にするために、意図的にレイヤードデザインを採用しています。
司会のPeter：Codexアプリを開発することを決断した過程について……今となっては、ターミナルウィンドウをいくつも開くよりもはるかに直感的であるため、当然の選択に思えます。しかし当時の判断根拠は、Codexアプリが初心者にとってより親しみやすく、また複数のインテリジェント・エージェントの協働を管理するための最適なインターフェースであるということでした。
Alex：
私たちチームの思考は、AGI（汎用人工知能）のビジョンに強く影響を受けています。私たちは常にこう問いかけ続けています：将来の働き方はどのようなものになるのか？
むしろ逆に言うと、私たちはユーザーが複数のインテリジェント・エージェントにタスクを自然に委任できるインターフェースが必要であると明確に理解しています。将来的なモデルがこうした能力を持つことは、すでに分かっています——実際、ユーザーがすでに複数のエージェント間でタスクを委任しようとしているのを目にしています。そのため、こうした協働が自然に感じられるインターフェース、そしてクラウドへとシームレスに拡張可能なインターフェースが必要なのです。
私たちは、このインターフェースが人間工学的に設計され、複数のインテリジェント・エージェントと協働することが直感的・自然な体験になることを望んでいます。複雑な操作や特殊なスキルを必要としない、使いやすいものにしたいのです。
Romain：
はい、そしてこのアプリケーションの対象は初心者だけではありません。実際、OpenAI内部の最もベテランで経験豊かなエンジニア、たとえばピーター、OpenClaw、グレッグ・ブロックマンなども、今やCodexアプリを主要な開発ツールとして使っています。これは私たちのインテリジェント・エージェント委任（agentic delegation）のビジョンが、着実に現実になりつつあることを示しています。
Alex：
はい。ピーターの話をしたのは、彼が最近OpenAIに加入したからです。私たちにとって非常にワクワクする出来事でした。昨年10月、サンフランシスコのフォートメイソンで彼と散歩していた際、新しいインターフェースの開発について話しました。「タスク委任（delegation）をより自然にする新しいインターフェースが欲しい」と話すと、彼は「そんなものは絶対に使わない」と答えました。
しかし先週末、彼は「実はこのアプリケーションは結構使いやすい。今では気に入っています」というツイートを投稿しました。
AlexがCodexのプロダクトマネージャー（PM）として行っている日常業務とは
司会のPeter：Alexさんは、一時期Codexチームで唯一のプロダクトマネージャー（PM）だったんですよね？今、Codexチームの人数はどれくらいですか？50〜100人程度ですか？
Alex：
そのくらいです。正確な数字は覚えていませんが、5月頃には約8人だったと思います。その後、チームは非常に急速に成長し、現在は50〜100人の規模になっています。
司会のPeter：では、普段はどのように時間配分をしているのでしょうか？あなたの日常業務はどのようなものでしょうか？あるいは、典型的な1日なんて存在しないのでしょうか？
Alex：
私も最近このことを考えていたのですが、自分では説明しにくいと気づきました。私は自分の仕事スタイルが段階的であることに気づきました。これは私の個人的なスタイルであり、すべての人に当てはまるわけではありません。
たとえば、Codexアプリをリリースした時期は、私は完全に実行モード（execution mode）に入っていました。その時期、私のすべてのエネルギーは製品の品質に集中しており、細部に至るまで見落とさず、すべての小さなタスクを確実に遂行することに注力しました。このモードでは、Codexツールを多用しました。
私たちはCodexを使ってフィードバックを得ていました。Slackでの議論内容やユーザーからのフィードバックを把握するために、Codexに要約させ、それをLinearに記録しました。また、コード品質の分析や、小さなコード修正もCodexを使って直接行っていました。なぜなら、小さな問題をCodexで直接処理するほうが、他の人に依頼して優先順位を付けてもらうよりもずっと速いからです。特に、アプリケーションを2週間以内にリリースするという目標があった場合には、この方法が非常に有効でした。
この過程には、もちろん人間らしい活動も多く含まれていました。チームを鼓舞し、士気を高めること、そして私たちが開発している製品に対して批判的な姿勢を保つことなどです。実は、自分が実行モードに入っているかどうかは、Twitterをどれだけ使っているかで判断できるほどです。なぜかはわかりませんが、人とコミュニケーションを取りたいときには、自然とTwitterを使うようになります。
もう一つのモードとしては、今のような状況があります。私の頭の中には非常に明確な認識があります：私たちは新しい段階に到達しました。今やGPT-5.4のような非常に強力なモデルを有しており、その性能は非常に優れています。アプリケーション体験も予想を大きく上回っており、Windowsを含むすべてのプラットフォームに対応しています。そのため、今こそクラウドに真正に立ち戻り、そこにさらに多くの力を注ぐべき時だと感じています。
このような段階に入ったとき、私は次に何をするべきか、そして現在の状況を理解するために多くの時間を費やすようになります。これは調整モード（coordination mode）です。このモードでは、Codexを使う時間が減り、むしろCodexを使ってコミュニケーションを行うことが多くなります。つまり、少なくとも2つのモードがありますが、他にもあるかもしれません。
司会のPeter：あなた方は、どの程度のクロスファンクショナルな調整作業を行っているのでしょうか？
Alex：
チーム内では、クロスファンクショナルな調整作業はほとんど必要ありません。むしろ、私たち自身を一種の『海賊船』のようなチームと意識しています。Codexチーム内でも、現在は私と最近加わった2人の新しいPMだけがPMです。責任者はいますが、最近まではほぼ全員が私に直接報告していました。しかし、私たちはあいまいな形でプロジェクトを進めているため、チーム内の調整作業はほとんどありません。
ただし、最近ますます明確になってきたのは、Codexの構築において、このcoding agentの開発が重要な部分であるということです。また、coding agentはコードを書くだけでなく、他のタスクでも非常に有用であるという認識も高まっています。
たとえば、ユーザーがCodexアプリを使っているのは、コードを書くためだけではありません。彼らは、ソフトウェア開発ライフサイクル全体のさまざまなタスクにこれを活用しています。そして、現在のOpenAIの大多数の従業員がCodexアプリを使っています。技術者でない人であっても、私はよくこのアプリケーションを使っているのを見かけます。
こうした認識から、Codexを単に開発者向けに留めるのではなく、より広範なユーザーに役立つようにする必要があることに気づきました。そのため、より多くのクロスファンクショナルな調整が必要になります。なぜなら、OpenAIにはChatGPTという別の製品があり、多くのユーザーがそれを使っているからです。これらの製品をいかにうまく統合するかを、非常に慎重に検討する必要があります。
Romain：
私の視点からは、私たちの開発者体験（DevX）チームは、今やCodexチームの延長線上にあると言えるでしょう。私たちの大部分のエネルギーはCodexに注がれており、その理由はいくつかあります。
まず、これは非常にワクワクする製品であり、開発者たちがCodexを非常に気に入って使っているため、さらに良くしたいという思いがあります。Alexが述べたように、私たちの仕事スタイルもいくつかの段階に分けられており、Codexチームと一緒に製品リリースの準備作業に没頭します。たとえば、リリースに必要な資料の準備や、開発者がCodexを最大限に活用する方法を教えることです。リリース後には、開発者がさまざまなシナリオでCodexを活用する方法をガイドします。
もう一つ、私たちが非常にワクワクしているのは、OpenAIのプラットフォーム全体を見渡したときに、すでに何百万もの開発者が私たちのAPIを使い、画像や音声などさまざまなモダリティのアプリケーションを構築しているという事実です。
今や、最も優れた開発手法は、Codexをエントリーポイントとする方法になっています。1年前、あるいは昨年夏にGPT-5をリリースした頃を思い出してください。当時は、GPT-5向けのプロンプトを書く方法を教えるために、多くのガイドラインを書く必要がありました。GPT-5は推論能力が非常に高いモデルで、GPT-4とは大きく異なります。しかし今は、Codexとskillsを使って、こうしたユースケースでも開発者を支援しようと努力しています。
たとえば、統合システムを更新する必要がある場合、Codexとそのスキル機能を使うことを勧めます。結果として、Codexがほぼすべてのタスクを完璧にサポートしてくれます。そのため、私たちのチームはクロスファンクショナルなコラボレーションを非常に重視し、CodexをOpenAIの開発者プラットフォームの基盤と位置付けています。
Alex：
私たちCodexチームの働き方には、非常に興味深い特徴があります——私にとって最も素晴らしい部分は、コミュニティとのやり取りです。オンライン上でも、現実のイベントでも、コミュニティとのつながりを非常に重視しています。
製品リリース時には、私たちの仕事は非常にリリース志向（release-oriented）です——いつ何をリリースするかを明確にします。同時に、非常にフィードバック志向（feedback-oriented）でもあります——コミュニティからフィードバックをいただいた際には、迅速に行動し、問題を修正し、コミュニケーションを取るようにしています。そのため、私たちのチームは常にオンライン状態を保っており、これは非常に重要だと感じています。
たとえば、Codexアプリをリリースした際には、ドムとそのチームと非常に緊密に連携しました。彼らは大規模なアルファテストを組織し、多くのユーザーを招待して、共同で製品を開発しました。彼らのフィードバックにより、アプリケーションだけでなく、skillsやドキュメントなどの関連リソースも改善されました。
これが私たちCodexチームの独特な強みです：私たちがオープンソースであるため、自分たちが行っているすべてのことに非常に透明性を持ち、コミュニティもその姿勢を大変高く評価し、大きな支持とフィードバックを寄せてくれています。
司会のPeter：ピーター（OpenClawの創業者）についてお聞きしたいのですが、私はOpenClawの初期ユーザーです。あなた方は、ピーターをチームにどのように統合したのでしょうか？このパーソナル・エージェント（personal agent）のビジョンは、彼の現在の仕事と関係があるのでしょうか？どのように計画を立てたのでしょうか？
Alex：
2つの観点からお話しできます。まず、ピーターはCodexの非常にヘビーユーザーです。実際、OpenClawの多くはCodexを使って構築されています。彼は自身の利用体験を通じて、チームに多くのフィードバックを提供してくれており、それがCodexの改善に大きく貢献しました。これは彼の「副業」ではありましたが、非常に熱心に取り組んでくれたため、私たちにとっては非常にワクワクする出来事でした。
第二に、詳細は明かせませんが、彼は私たちが次世代のパーソナル・エージェント（personal agent）を構築し、それを直接ChatGPTに統合する作業を支援しています。
Romain：
ピーターの仕事で私が最も魅了されるのは、人々がOpenClawを使っているときに、すでに未来の可能性をぼんやりと見ているかもしれませんが、私が衝撃を受けたのは、ピーターがずっと前からそのビジョンを見据えていたことです。
2025年を振り返ると、彼は昨年40以上のオープンソースプロジェクトを開発しましたが、それらすべてが1つのコアビジョン——コマンドラインインターフェースを通じて、自分のカレンダーやツイート、Gmailなどのパーソナルツールにアクセスする——に沿って進められました。彼はこれらのプロジェクトを通じて、skillsとコマンドラインツールのビジョンを現実のものにしました。そして、私たちが今日使っているプログラミング・インテリジェント・エージェント（coding agent）は、まさにこのビジョンに基づいて構築されています。
将来、このインテリジェント・エージェントは、単なるプログラミングツールではなく、あらゆる種類のパーソナル・エージェント（personal agent）へと進化します。そのため、ピーターはこの過程で非常に貴重なフィードバックを提供してくれました。彼が開発したツールの多くは、今やオープンソースエコシステムの核となる部分になっています。
司会のPeter：
ピーターのような人が、これほど優れたオープンソースコミュニティを構築できるというのは、本当に尊敬に値します。彼のツールは非常に使いやすく、他のアプリケーションを開こうと思わなくなるほどです。私はただ自分の小さなロボットと話したいだけです。
Alex：
それをどのシステムに接続しましたか？すべてのサービスに接続しましたか？
司会のPeter：
はい、多くのサービスに接続しました。たとえば、銀行情報、YouTubeアカウント、音声アシスタント、カレンダー、Googleサービスなどにアクセスできます。ベッドで横になっていると、妻が「誰と話しているの？」と尋ねるので、「OpenClawのロボットと話している」と答えます。
ただし、今では「投機家」がOpenClawのセットアップを手伝うために、高額な5000ドルの費用を請求するようになっています。ですから、あなた方がこれをより一般の人々に広め、使いやすくすることができれば、それは大きなブレイクスルーになるでしょう。あなた方は確かに正しい方向に向かって進んでいます。
伝統的なキャリア昇進の道筋はもはや通用しない
司会のPeter：あなた方が「今やほとんどのチームでは、それほど多くのPMは必要ない」というようなことをおっしゃっていたのを覚えていますが？
Romain：
これらのツールが私に最も驚きを与えたのは、それが単にPMが必要かどうかという問題ではないということです。これは、ほぼすべての伝統的なキャリア昇進の道筋を曖昧にしているということです。以前は、デザイナーはデザインを、エンジニアは開発を、PMはマネジメントを担当し、ある種の「黄金比」のような明確な役割分担がありました。
しかし今や、エンジニアであれば生産性が劇的に向上しています。デザイナーであれば、これらのツールによって超人的な能力を得て、より技術的になります。PMであれば、以前は戦略文書を書くだけでしたが、今ではプロトタイピングも可能です。数十億人のユーザーを対象に機能を担当する必要はありませんが、これらのツールを使って実際に何かを構築し、自分のビジョンをチームに示すことができるのです。
そのため、私が最も魅了されるのは、すべてのキャリアステップの境界線が曖昧になりつつあるということです。私たち全員が「ビルダー（builder）」であり、共に構築しているのです。
Alex：
私はどこかのネット上で、「スタートアップ企業にPMがいるのに、エンジニアが20人程度しかいない場合、それは危険信号かもしれない」と言ったことがあると思います。おそらく、似たようなことを言ったのでしょう。
あなたがおっしゃった通り、今やこれらの役割は徐々に融合しつつあります。デザイナーはより多くのエンジニアリング作業を行い、エンジニアはデザインに関与し、PMも構築に参加できます。ただし、エンジニアはコードを書くことに集中する必要があるため、これまでタスクの振り分けやその他のPMのプロジェクトマネジメント業務には関与していませんでした。
しかし今や、こうした作業は非常に簡単になっています。Codexのようなエージェントに、フィードバックや優先順位の分析を任せれば、エンジニアは自分の本来の仕事に集中できるようになります。今や、誰もが他の人の仕事をこなせるようになっています。
スコット・ベルスキーが提唱した「人材スタックの収縮（collapse the talent stack）」という考え方が好きです。私はこの考え方がまさに今起こっていると感じています。部屋に必要な人数が少なければ少ないほど、物事はスムーズに進み、各意思決定もより明確になります。
そこで問題になるのは、「PMは今後何ができるのか？」ということです。多くのPMは、キャリアチェンジを検討すべきかもしれません。たとえば、PMとして働きながら、ずっとエンジニアになりたいと思っていたが、人をマネジメントするのが得意で、エンジニアリングの能力はそれほど高くないという場合、今ならエンジニアリングマネージャー（engineering manager）になるのが、より明確な役割かもしれません。インテリジェント・エージェントの存在により、それがより明確な選択肢になります。同様に、一部のPMはデザイナーになることを好むかもしれません。より実際の構築作業に近いところに身を置きたいという気持ちからです。
最終的には、個人の興味にかかっています。私にとって、興味と主体性（autonomy）は、AGI時代において人類が持つ最も核心的かつ重要な資質です。したがって、もしコードを書くことに興味があり、これまでPMという役割を担っていたのは、単に誰かがその仕事をする必要があったからという理由であったなら、今こそエンジニアへの転身を検討すべきです。デザインの分野も同様です。
しかし、もし本当にユーザーとのインタラクションに興味があるのなら、それが実際の構築作業から離れてしまうとしても、たとえばユーザーのニーズを理解しようとする、市場のトレンドを読み取ろうとするといった活動に興味があるのなら、チームが十分に大きい場合、PMとしての役割は依然として意味を持ちます。
Romain：
補足させていただきますと、私は依然として、各問題領域には必ず一人の人間が責任を持つべきだと考えています。しかし、その人がPMである必要はないと考えています。それは製品の性質によって大きく左右されます。
私たちは非常に幸運です。なぜなら、Codexという開発者向けのツールを開発しているからです。私たちは自分自身が最高のユーザーであり、オープンソースであるため、コミュニティと直接連携し、共同開発を行うことができるからです。
しかし、10年前に戻って、私がStripeで働いていた頃を思い出してください。当時、会社は250人規模でしたが、PMは一人もおらず、AIツールも何もありませんでした。なぜでしょうか？StripeはAPI製品であり、全員がエンジニアであり、優れたAPIとは何かを直感的に理解していたからです。私たちは、自分たちが夢見たAPI——わずか数行のコードで実現できるエレガントなソリューション——を構築していたのです。
しかし、エンジニアがユーザーのニーズを直感的に理解できないような分野では、顧客とのコミュニケーションやニーズの理解のために、より多くのPMが必要になるかもしれません。特に、エンジニアの直感と一致しない業界や分野でサービスを提供する場合、PMの役割はより重要になります。しかし、Codexチームでは非常に幸運であり、私たち自身が使いたいと思うツールを構築しているのです。
Alex：
このような環境では、PMという役割は、単にユーザーに最も関心を持ち、ユーザーのニーズを最も気にする人を指すラベルに過ぎないかもしれません。その人は、ユーザーに非常に近いエンジニアである可能性が十分にあります。したがって、これらの職業ラベルは、徐々に伝統的な意味を失いつつありますが、多少混乱しているからといって、それが悪いことだとは限りません。
司会のPeter：
私のチームでも同様の発見があります。最も優れたエンジニアは、「次に何を構築すべきか？」と私に尋ねることはなく、自らユーザーと話をして、何を開発すべきかを自分で理解し、その後で私と議論します。こうしたアプローチにより、チームの目標は非常に一致します。
Romain：
これはまさに私たちCodexチームの働き方です。今日Codexアプリで使われている多くの機能は、エンジニアがボトムアップで提案した素晴らしいアイデアであり、彼ら自身がそれらの機能を必要としていたからです。
Alex：
ここで付け加えたいのは、私が非常に喜んで協働するタイプのエンジニアがいます。彼らはユーザーとの交流を好み、何を構築すべきかを常に考えています。こうした人は、システム構築にも非常に優れており、スピードと能力、そして明晰さを兼ね備えています。しかし、ユーザーとのインタラクションにまったく興味がないエンジニアもおり、彼らはシステム構築に集中したいだけです。私はこうした人も、非常に大きな成長の余地があると考えています。
改めて言いますと、これが私がAI時代に抱く見解です——私たちは皆、より「自分らしく」いられるようになります。AIとチームが、私たちがやりたくないことを代わりにやってくれるため、自分自身の興味や強みに集中できるようになるのです。
司会のPeter：
私は確かに「ビルダー（builder）」というラベルが非常に重要だと感じます。多くのPMはリーダーになりたいと思っていますが、伝統的なキャリア昇進の道筋は、VPなどの役職に就くと、むしろ構築する時間がなくなってしまうというものです。毎日プロダクトレビューに出席し、フィードバックを出すだけの日々で、実際に開発する時間はなく、多くのPMはそうした生活を望んでいないと感じます。私は自分自身がユーザーに近いまま、実際に製品をリリースし続けたいと思っています。
Alex：
私は完全に同意します。私はPMをリーダーの役割とは考えておらず、むしろ『空白を埋める役割』だと考えています。時には、この役割が一定のリーダーシップを伴うこともあるでしょう。しかし、そのリーダーシップの役割は、天才的なソリューションを1人が提示することを期待するのではなく、むしろチームが合意に達するのを支援することにあるのです。
一点、私は確信しています：OpenAIで最も優れたPMは、具体的な詳細にまで深く入り込んでいます。そして、上級リーダー職としてOpenAIに加わることは、非常に挑戦的なことだと考えています。なぜなら、ここでの文化は依然として、細部への関心を重んじているからです。したがって、最良の方法は、最初から細部にまで深く入り込むことです。
Codexチームが採用時に重視するものとは？（答えは、あなたの履歴書ではありません）
司会のPeter：Codexチームへの採用において、候補者がCodexのヘビーユーザーであるという条件以外に、あなた方はどのような資質を重視していますか？
Alex：
先ほども触れましたが、私は候補者の『主体性（agency）』を非常に重視します。私たちが求めているのは、自ら行動を起こす人です。これは最も重要な資質の一つです。
OpenAI、特にCodexチームの文化は、「あなたが加わったら、12個の段階的に難易度が上がるタスクをリストアップしてあげる」というタイプではありません。私たちのスタイルはむしろ、「ようこそ！さあ、自分の探求を始めましょう」というものです。
そのため、私たちは自ら動く人——行動力があり、自分の考えを持ち、何をしたいかを自覚し、既存の考え方を疑うことさえ恐れない人を重視しています。正直に言うと、既存の考え方の多くはそもそも間違っている可能性があり、単なる偶然の判断だったかもしれません。
私が理想とするチームメイトは、自ら余分な責任を引き受け、未知の領域を担当することさえ厭わない人です。こうした資質は、私たちが特に重視しているものです。具体的なスキルについては、技術力が高く、エンジニアリング関連の背景を持つ候補者を優先します。
Romain：
私も完全に同意します。私の開発者体験（DevX）チームでは、『主体性（agency）』が高い人を主に探しています。彼らは技術的に非常に優れており、Codexのようなツールを扱うことに長けている必要があります。しかし、それだけでなく、開発者やビルダー（builders）と共に働き、知識を共有することに情熱を持つ人を特に重視しています。
たとえば、今週、トーマスが私のチームに加わることが発表されました。彼はオープンソースのCodex monitorを開発した人物です。彼は非常に創造的であり、Codexのヘビーユーザーでもあり、Codexを使ってツールを構築する方法を共有することを楽しみにしています。
私たちには、こうした人材が必要です。なぜなら、私たちは何百万もの開発者を、Codexが象徴する明るい未来へと導こうとしているからです。私は、インテリジェント・エージェントによるコーディング（agentic coding）が、ソフトウェア開発、アプリケーション、製品構築に対する従来の考え方を根本的に変えつつあると信じています。私たちの目標は、この可能性を世界に示し、開発者がこれらのツールを活用して自分のアイデアを実現する方法を学ぶのを支援することです。これが私が探している資質です。
Alex：
補足させていただきますと、私の見解では、DevXチームの理想的な候補者は、「非常に優れたエンジニアであり、同時にソーシャルメディアを通じてコミュニティとやり取りする能力も持つ人」と簡単に表現できます。
Romain：
その一部は正解です。しかし、補足させていただきますと、私たちが求めるのは、コミュニティに対して強い責任感を持つ人であり、さらに、世界中のさまざまな地域におけるソーシャルメディアの利用習慣も考慮する必要があります。たとえば、ある地域では、開発者がLinkedInや他のプラットフォームをTwitterよりも好むかもしれません。そのため、この定義を拡張する必要があります：候補者は、世界中のソーシャルメディアで良好なパフォーマンスを発揮できる必要があります。特に重視するのは、コミュニティとやり取りすることを楽しみ、教育や知識共有に情熱を持つ人です
司会のPeter：
実際、主体性は、面接以前に既に見抜くことができます。たとえば、オンラインで作品を公開しているか？独自のサイドプロジェクトを持っているか？
Alex：
誰かがDMで当チームへの参加を希望した際、私の第一反応は「リンクはあるか？」です。リンクがあれば、ほぼ必ずクリックします。私は彼らの作品を興味深くチェックし、実際に何かを構築しているかを確認します。
もちろん、申請書を添えて、なぜこの職に興味を持ったのかを説明したり、履歴書を添付したりする人もいますが、私はむしろ彼らの考えや実際に構築したものを見たいのです。先日、面白いことに気づきました——私は、彼らがどの大学を卒業したかをまったく知りません。
司会のPeter：誰がそんなことを気にするでしょうか？誰が気にするでしょうか？私は、こうした馬鹿げた学歴がもはやそれほど重要でない時代に生きていられることを、本当に嬉しく思います。実際に何を構築したかを見せてもらえれば、それで十分です。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
深潮TechFlow
