「興味と自律性は、AGI 時代における人類の最も中核的で、最も重要な資質です。」
整理 & 編纂：深潮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 の「思考スピード」
仕様書と意思決定プロセスについて
職業の境界が曖昧になり、デザイナーが進化する
プロダクト設計哲学：モデルを「見えなくする」
計画哲学：『中期の気まずさ』を拒否する
『インテリジェント・エージェントの委任』がもたらすUIの変革
職能の階段の消失と『人材スタックの崩壊』
採用基準：履歴書より作品
**司会者 Peter：今日は Alex と Romain を迎えて、すごくわくわくしています。彼らは OpenAI の Codex チームのメンバーです。Codex の新機能をどう構築するのか、Codex がどんな能力を持っているのか、そして Codex チームがどうやって休まずプロダクトをリリースしているのかをデモしてくれます。みなさん、ワンショット（one-shot）プロンプトで、実際にどんなものが作れるのかを素早く見せてもらいたいと思いませんか？
Romain：
もちろん。画面共有をします。実は、私が見せられることはたくさんありますが、たぶん素早く一つだけ——たとえば、ここに私がずっと作っている iOS アプリがあります。このアプリに新機能を追加したいなら、私は単に口頭でこう言うだけです。「ねえ、NASA の月への帰還ミッションに向けて、新しい画面を追加してくれる？」それから GPT-5.4 にそのプロンプトを投げると、モデルはその特定の APP の新しい画面を作ってくれます。
それに加えて、Codex Spark モデルもあって、数秒のうちに何でも構想して反復できます。Spark モデルが素早い応答を返す違いを見せます。左が GPT-5.4、右が Codex Spark。さらに平均すると毎秒だいたい 1200 のデータです。速すぎて狂ってます。だから、たとえばゲームみたいな何かを作りたいときは——この会話を始める前に、実際に私は Codex アプリに行って、クイックプロンプトで Animal Crossing っぽい小さな 2D ゲームを作りました。
自分の考えがクリアになったとき、Codex を使う別の機能として、私はすごく気に入っています。Codex を開いて、会話を画面の上部に浮かせるんです。そうすれば、もし本当にこのゲームを作っているなら、反復を続けて、もっと多くのアイデアを生み出せます。Peter、あなたなら、このゲームで何を変えたいですか？
**Peter：**たぶん、もう少し装飾を足して、家や木みたいなものを増やして、もっと生き生きさせる感じですかね？
じゃあ、そのタスクを送ります。すると基本的に数秒で Codex Spark が編集してくれて、変更がリアルタイムで見えるようになります。以上です。新しい木が現れるのを見ました。
だからこそ私は Codex にすごくワクワクしているんです。あなたは本当に、GPT-5.4 みたいな最先端モデルを“手に入れる”ことができます。つまり、分析や数百万行のコードの移行のような、非常に複雑なタスクも任せられる。ただし、インスピレーションが湧いて、しかも考えがはっきりしているときには、クイックモードに切り替えたり、Codex Spark に切り替えたりできる。すると、この狂った思考スピードで、あらゆるものを構築できるんです。
**司会者 Peter：本当に気になっているんですが、チームの中で実際にどのように Codex を使ってプロダクトを作っているんでしょう。Alex、あなたたちは仕様を書くんですか？それとも GPT に仕様を書かせるんですか？それらを動かすためにどのモデルを使っているんですか？
Alex：
私たちが Codex チームで書く仕様書は非常に非常に少ないと思います。実際、私は大部分の仕事は、実際に最も近い人が可能な限り多くの意思決定をするようにすることだと思っています。だから、問題が最終的に“1 人の脳に収めるのが難しいタイプの問題”になったときだけ仕様を書きます。ちなみに言うと、今は 1 人が脳の中に入れられる情報はたくさんあります。彼らはたくさんのことができるからです——ほとんどのコーディング作業を委任できるので、1 人がいまは多くのことをできる。でも、それが最終的に複数人の調整が必要になるようなことになったり、あるいは、私たちが下さなければならない非常に厄介な意思決定が必要になったりするなら、そのときには仕様を書くのかもしれません。ただ、こうした状況で書くドキュメントは、かなりかなり短いものになります。私たちが言うのは、たとえば 10 個の要点みたいなものをまとめて、それで終わりです。
**司会者 Peter：**わかりました。これがどう機能しているか、実際に見せてくれますか？たとえば、Codex にいくつかの要点を渡して、まず実際の要件を書かせる、みたいな感じで？
もちろんできます。ただ、最初に、もう少し簡単な例を見せたいと思います。たとえば、私たちが iOS アプリを開発していて、すでにいくつかのタスクは完了しているとします。いま、そのプロジェクトに新しい機能のアイデアはあるけれど、具体的にどの方向に進めばいいのかがまだ分からない。このとき Codex の強みは、次にやることを計画するのを助けてくれるところです。たとえば、私は Shift+Tab キーを押して「プランモード」 (Plan Mode) に入って、「私たちは何を作るべき？」と入力します。すると Codex が自動的に、最初の計画案を作ってくれます。既存のコードベースを分析して、プロジェクトの現在の状態を理解し、いくつかの潜在的なアイデアを提案してくれる。そこに、私も自分の考えを加えて、モデルがより完成度の高い計画を生成するよう導くこともできます。
このプロセスで、Codex は現在のコードやファイルに基づいて提案を出してくることに気づきます。たとえば、「以前に触れた機能をさらに仕上げるべき？それとも信頼性ダッシュボードを最適化すべき？」みたいな質問をしてくるかもしれません。もし信頼性ダッシュボードを最適化すると決めたら、さらに「最適化のターゲットユーザーは誰？ 」といったことを考えるよう導いてくれます。この全体は、ブレインストーミングの相棒と一緒に作業しているような感じです。
私はよく、このやり方で発想を生み出すのに使います。たとえば、ある程度簡単な変更なら、私は直接プロンプトを入力して、Codex にコードを生成させます。
一方で、もう少し中程度に複雑な変更の場合は、具体的な計画を生成させたり、実装の進め方を推論してもらったりします。そして、もし自分の中にぼんやりしたアイデアしかないときは、私は通常 Codex を開いて、どう解決すべきか考えさせます。たとえ頭の中に明確な機能要件がなくても、Codex は質問や探索を通じて考えを整理してくれます。
ただ正直に言うと、状況によっては、Codex が作った案をそのまま使わないこともあります。特に変更が複雑なとき。私は Codex の「プランモード」で探索して、クリアな思考を組み立てて、それをエンジニアチームに共有します。最終的には、生成された計画そのものより、その思考プロセスのほうが重要だと感じています。
ところで、チームのデザイナーが今書いているコード量が、6 か月前のエンジニアよりも多いという話をしましたが、これは以前は考えられないことでした。主な理由は、ツールの進歩です。デザイナーがより深く開発に参加できるようになった。ですが、私はチームから「去年出した PR（コードマージリクエスト）が少なすぎるよ」って冗談で突っ込まれることもよくあります。多くの変更は小さい調整で済むとはいえ、私は確かにもっとやるべきだと思っています。
今は、**私たちの重点は「コードを生成できるかどうか」ではありません。**エージェント (Agent) が大半のコーディングタスクをこなせるようになっているからです。**本当に重要なのは：私たちが何を作るのか、そしてどうやってプロダクトの品質を高めるのか。**それが理由で、非常に複雑な特性については、プロダクトマネージャー (PM) にそのシステムの実装と運用保守を任せるより、堅実な責任者を見つけて管理させるほうが私は好みます。
**司会者 Peter：**Codex のアプリは使うと非常に直感的でシンプルです。外の一部の専門プロダクトと比べると、Codex は学習曲線がかなり低いと思います。ほかの専門プロダクトは機能が強力でも、学ぶのにかなり時間がかかります。私は、もし Twitter で関連情報をフォローしていなかったら、そもそもそれらをどう使えばいいのか分からなかったかもしれない、とすら思います。
ただ、Codex に感心したのは、シンプルで使いやすいだけでなく、skills（スキル）や automations（自動化）といった多くの高度な機能も提供している点です。みなさんのチームの中では、そうした機能を頻繁に使いますか？**
はい、かなり使っています。実際、skills は Codex アプリの中でもっとも面白い機能の 1 つだと思っています。たとえば今、もしデザイナーと一緒に Figma を使っているなら、Figma の skill を開くだけで、Figma のファイルから React コンポーネントや変数などの詳細を直接取り出せます。そのうえで Codex が、自動的に対応するコードを生成します。もう 1 つの例として、もしアプリケーションを開発していて、それを共有したりデプロイしたりしたいなら Vercel、Cloudflare、Render などに対して、skills 経由で簡単な指示を出すだけで、Codex がそれらのタスクを自動で実行してくれます。
最近、友人と話していたとき、彼はプロダクトを改善するアイデアがたくさんあると言いました。そこで彼は Codex にこう言ったんです。「これらのタスクを全部 Linear に書き込んで、追跡できるようにして。」そして彼は Linear の skill を使いました。続いて彼は Codex に「俺は寝る。さっき話した全部のタスクを続けて完了としてマークしといて。」と言いました。すると翌朝、彼が起きたときには、タスクが本当に全部完了していたんです。
先ほど触れてくれたアプリのシンプルさについて、どう設計しているかを少し共有したいと思います。この領域では、開発者は日常の作業を簡単にするために、みずから自動化ツールを作ることに熱中しがちです。私たちは、プロダクトの重要な特徴は“高度に設定可能であること”だと考えています。Codex にとっては、それはまるでオープンソースのツールボックスのようなもので、ユーザーが中に深く入り込んで、自分のニーズに合わせてカスタマイズできます。
新機能をリリースするたびに、たいてい Twitter で「この機能、問題あるんじゃない？」みたいな文句を言うユーザーがいます（たとえまだ正式リリース前でも）。問題の原因は通常、彼らが自分でコードを修正したり、fork してしまったりしていることです。でも私にとっては、それはむしろプロダクトが成功している証拠です。最前線のユーザーが私たちと一緒に未来を探っていて、それがプロダクトを前に進めてくれているからです。
ただ、私たちも気づいています。こうしたヘビーユーザー向けのプロダクトを作るだけでは十分ではありません。そうしないと、最終的にプロダクトが複雑で分かりにくくなります。私たちはバランスを見つける必要があります。上級ユーザーのニーズは満たしつつ、普通のユーザーにとってはシンプルで直感的であること。だからコア機能の設計には慎重で、それらがユーザーとモデルの間の障害にならないようにし、モデルをより賢くして自動でより多くのタスクをこなせるようにします。
そしてそのうえで、できる限り可配置（可設定）な形でプロダクトを上級ユーザー向けにパッケージして、彼ら自身に探索と利用を任せる方法を考えます。例えば、今すでにユーザーが sub-agents（サブエージェント）を実装しています。これらの機能は私たちが先に設計して用意したものではなく、ユーザーが自分で発見して実験したものです。そうした機能の使われ方を観察することで、私たちは多くのことを学びました。
そして次に考えます。**これらの機能を、他のユーザーにとっても“超シンプル”にするにはどうすればいいのか？**Codex app はその良い例です。去年 12 月に GPT-5.2 Codex がリリースされた頃、モデルの能力が徐々に安定し始めましたが、同時にある“臨界点”を越えたんです。ユーザーが、より長い時間・より複雑なタスクをモデルに委任できるようになり、そしてモデルが一度にそれらを完了できるようになりました。
私たちは、すでに一部のユーザーが tmuxing（端末内で複数の並行タスクを動かすこと）を使い始めているのに気づきました。これは、端末内でウィンドウを分割して、同時に複数のタスクを走らせるやり方です。SNS 上で、面白い例をいくつも見ました。たとえば Peter Steinberger の写真で、彼の画面には端末ウィンドウが 18 個あり、3 台のディスプレイにまたがっていて、まるで「クリエイティブなオープン・クロー（爪）」みたいに見える。私たちは、ユーザーが Codex を非常に高度なやり方で使っているのを見て、すごくワクワクしました。
同時に、私たちは CLI のような基本プロダクトでもタスク委任の機能を最適化し続けて、うまく動くようにしていました。ただ、同時に気づいたことがあります。たぶん、この方式で働くのはトップ 1% のエンジニアだけです。だから私たちは考えました。この機能をどうすればもっと直感的に見せられるのか、と。だからこそ Codex app を開発したんです。
あなたが初めて Codex app を開くと、シンプルなチャットウィンドウのように見えます。すぐに使い始められて、正常に動きます。でも時間が経つにつれて、サイドバーや複数タスクを動かす能力、タスク間の切り替えを簡単にできる機能など、より多くの機能が徐々に見えてきます。あなたは自分が超効率的になった感覚を持つでしょう。それから、skills タブにも気づいて、さらに多くの機能を探索できます。私たちは、ユーザーが Codex app を使うとき、ゲームをするような感覚で、次々と新しい可能性を発見できる体験にしてほしいと思っています。
完全に同意です。しかも、これは最初から私たちが持っていたビジョンでもあります。**コーディングは『インテリジェントなエージェント委任』(agentic delegation) の形で行われる。**私たちが Codex を開発し始めたのはほぼ 1 年前ですが、その時点からこの未来についてずっと考えていました。エンジニアは複数のタスクを同時に扱え、モデルは複雑な細部の実行を担当するようになる、と私たちは信じていました。
ただ正直、当時のモデル能力はそのレベルにまだ達していませんでした。私たちは GPT-5.2 Codex のリリースと、その後の“臨界点”を待つ必要があった。モデルが数時間、あるいは数日レベルで、非常に徹底的で信頼性高く動けることが必要だった。そうしたときに、私たちはふと気づいたんです。従来のターミナルの UI では、この働き方に合わなくなってしまった、と。端末で複数のタブを開いて、それらを数時間走らせるというのは、やっぱり非常に奇妙なインタラクションに感じるはずです。だから、新しい UI が必要で、そのタイミングがちょうど完璧でした。
Codex の歩みを振り返ると、重要な“vibe shift”（トレンドの転換点）が 2 回あります。**1 つ目は去年の 8 月。**私たちは Codex Cloud の製品を出しました。とても良いアイデアで、ユーザーはそのときかなりワクワクしていましたが、当時はまだ少し早かったのかもしれません。そこで 8 月には、非常に優れたインタラクティブコーディングモデルである GPT-5 をリリースし、モデルが今扱える問題を解決することにフォーカスすることにしました。そのため Codex CLI と IDE プラグインを出しました。ユーザー数は数か月で 20〜30 倍に急増して、これは本当に素晴らしかった。
**2 つ目の転換点は、去年 12 月から今年 1 月の間です。**そこでようやく、最初のビジョンが実現しました——タスクをモデルに委任すること。モデルの能力が新しい段階に達し、より複雑なタスクを独立してやり遂げられるようになって、まったく新しいフェーズに入ったことを意味していました。
**司会者 Peter：Codex app はどうやって開発されたんでしょう？1 年前には、たとえば「ある時期に Codex app を出す」といった年次ロードマップを作っていましたか？それとも、より市場のニーズを見ながら観察して、いくつかのアイデアを素早くプロトタイプしていく感じでしたか？
実は、どちらも違います。リサーチャーの Andre から聞いた、とても良いアドバイスがあったんです。OpenAI では、短期目標も長期目標も計画するけれど、中期計画はしません。中期計画は複雑すぎるからです。
短期計画は通常、今から最大でも 8 週間の目標のことで、8 週間が私たちが設定できる最長の時間幅です。この時間枠の中では、具体的な目標を定めて、チームを結集して全力でやり切ります。これが OpenAI の強み——明確な目標の周りにチームを組織化するのがすごく上手いんです。
一方で、**長期のビジョンも作ります。**たとえば、1 年後の未来を見据えて、そのときモデルがより賢くなっていると想像する、といった具合です。あるいは、未来のモデルは私たちのコンピュータ資源を借りる必要がなくなり、一度に 1 つのことしかできない制約からも解放されて、独立して働けるようになるかもしれない、と考えます。私たちは、無限個のモデルがあり、それらがタスクを独立して完了し、自分でコードを検証し、さらには自分でデプロイやモニタリングまでできる——そして私たちはそれらに手でプロンプトを入れなくてもよい、という世界を持ちたいんです。
しかし、中期計画は気まずくなります。たいていは詳細なプロダクトロードマップの形で現れますが、私たちは基本的にそういうものはありません。私たちは、長期ビジョンと結びつけて、目標を達成するために前進させてくれる具体的なタスクに集中することが多いです。
Codex app の例でいうと、当時の戦略目標は、ユーザーを特定のワークスペース (workspace) から解放することでした。従来の開発ツール（たとえば VS Code）は、たいてい特定のワークスペースに紐づいています。たとえば、あるコードベースの特定のチェックアウト地点やフォルダです。git worktree を使っても、同時に開けるのはせいぜい 1 つの作業ディレクトリで、CLI も同様の制約があります。
でも私たちのビジョンは、**ユーザーがクラウド上のインテリジェントなエージェント (agent) と協働でき、そしてその agent が独立して働けること。**ユーザーが複数の agent と同時に対話でき、さらに 1 つの agent がユーザーのために複数の agent の仕事を調整する——その体験は自然で直感的であるべきだと考えました。
また、最初からクラウドに完全に依存すると、開発者にとって不便だと感じられる可能性があるとも理解していました。環境の設定が必要になり、モデルがタスクを実行するときに手動の介入や調整が必要になると面倒だからです。**だから私たちは、ローカル化された体験を開発することにしました。**それは、ローカルのフォルダともシームレスに協働でき、同時にクラウド上のインテリジェントなエージェントとも接続が保たれるようなものです。
このアプリの開発を始めたとき、私たちはそうした“ビジョン思考”のアイデアをたくさん持っていました。けれど、それらはかなり抽象的な考えでした。並行してエンジニアはさまざまなプロトタイプを作っていました。「私たちにアプリが必要だ」と彼らが言うようになると、いろいろなバージョンを試し始める。実際には、**ハッカソン（ハッカーウィーク）**も開催しました。複数人のエンジニアが、それぞれ独立して異なるバージョンのアプリを開発しました。あなたも参加したかもしれませんが、覚えていません。
このプロジェクトが本格的に動き出したとき、私たちが唯一はっきり書いておく必要があったのは**：なぜ私たちはアプリを開発することが良いアイデアだと考えたのか。**このアプリのための具体的なプロダクト仕様は決めていません。実際の開発作業を通じて、徐々にプロダクトの方向性が明確になっていきました。 **
ただ当時、このプロジェクトにはいくつかの議論もありました——本当にアプリを作る必要があるのか？IDE プラグインは非常に人気が出ていて、プラグインの品質を高めることに集中したほうがいいのでは？CLI も可能性がある。なら、アプリを作ることの意味は何なのか？私たちはどの方向に進むべきなのか？——これが、プロジェクトが始まる時点で直面していた問いの一部です。
はい、幸運だったのは、当時すでに成熟した IDE プラグインのソリューションがあり、それを深く最適化していたことです。ユーザーは VS Code、Cursor、Windsurf、そして他の IDE でもそれらのプラグインを使えます。IDE プラグインのコードベースから得た経験が大量にあり、それが Codex app 開発のための非常に堅実な起点になりました。
その通りです。実際、Codex app と IDE プラグインは、基盤となる層でかなりの量のコードを共有しています。どちらも、同じコアの Codex harness に接続しています。これは Rust で書かれたオープンソースのフレームワークで、CLI もそれを使っています。私たちは意図的にレイヤー設計を採用して、異なるツール間でコード共有と機能拡張ができるようにしています。
**司会者 Peter：**Codex app を作ると決めるまでのプロセスについては……振り返ると、それはすごく当然の判断に見えます。端末のターミナルを大量に開くより Codex app のほうがはるかに直感的だからです。でも当時、私たちがそれを選んだ主な理由は、Codex app が初心者にとってよりフレンドリーで、さらに複数のインテリジェントなエージェントの協働を管理するのに最適な UI だったからです。
私たちのチームの考え方は、AGI（汎用人工知能）のビジョンに強く影響されていると思います。ずっと考えていました——未来の働き方はどんなものになるのか？
別の言い方をすると、私たちはちゃんと理解していました。ユーザーが自然に複数のインテリジェントエージェントへタスクを委任できるUI が必要だということ。将来のモデルがその能力を持つことも分かっていました——実際にユーザーが、エージェントをまたいでタスクを委任しようとしているのをすでに見ていました。そうした協働が自然に見えて、さらにクラウドにシームレスに拡張できる UI が必要だったんです。
私たちは、その UI が人間工学に合っていて、複数のインテリジェントエージェントと協働することが直感的で自然な体験に感じられるようにしたい。複雑な操作やコツを必要とするものではなく。
はい。そしてこのアプリの対象は初心者だけではありません。実際、最も経験豊富で、最前線で働くエンジニアでさえ——OpenAI 内のトップクラスのエンジニアである Peter や OpenClaw、Greg Brockman など——彼らはもう Codex app を主要な開発ツールとして使い始めています。これはインテリジェントなエージェント委任 (agentic delegation) のビジョンが、徐々に現実になっていることを示しています。
そうです。私たちが Peter について言及したのは、彼が OpenAI に最近加わったばかりだからです。私たちはそれにすごくワクワクしました。去年 10 月に、サンフランシスコの Fort Mason で彼と散歩しながら、新しい UI を開発するというアイデアを話したとき、私はこう言いました。「タスク委任（delegation）をもっと自然にする新しい UI が欲しいんだ。」すると彼は「そんなものは絶対に使わないよ」と言っていたんです。
ところが先週末、彼がツイートしていました。「実はこのアプリ、けっこう使いやすい。今は気に入ってる。」
**司会者 Peter：**Alex、あなたは以前しばらく Codex チームの唯一のプロダクトマネージャー (PM) だったんですよね？今 Codex チームは何人くらいですか？50〜100 人くらいの規模ですか？
だいたい、そのくらいです。私たちが 5 月の時点では 8 人くらいだったと思いますが、正確な数字は覚えていません。でもそれ以降、チームは非常に急速に成長して、今はだいたい 50〜100 人くらいの範囲です。
**司会者 Peter：**それでは普段、どう時間を配分していますか？日常業務はどんな感じですか？あるいは典型的な 1 日ってそもそもないんですか？
最近、私もこの問いを考えています。答えるのが難しいと感じるからです。私は自分の仕事のスタイルが**段階的（フェーズ型）**だということに気づきました。これはもちろん私個人のやり方なので、全員に当てはまるわけではないです。
たとえば Codex app をリリースしたときは、私は完全に実行モードでした。当時は、プロダクトの品質に全力を注いでいました。細部の抜け漏れがないか、些細なことまでちゃんと固めるか。そのモードでは、かなりの時間 Codex ツールを使っていました。
フィードバックを取りに Codex を使います。たとえば Slack での議論内容やユーザーのフィードバックを把握するためです。Codex にそれらを要約させて、それを Linear に記録します。それ以外にも Codex を使ってコードの品質を分析し、実際に小さなコード修正をそのまま行います。小さな問題を Codex で直接処理するほうが、ほかの人にタスクを調整して優先順位をつけてもらうより速い場合があるんです。特に、アプリを 2 週間以内に出すことが目標のときはなおさらです。
もちろん、この過程では人間らしい仕事もたくさんあります。たとえばチームを鼓舞して士気を上げたり、やる気を出させたり。そして、私たちが開発しているプロダクトに対して批判的にも見続ける。実は、自分が実行モードなのかどうかは、Twitter をどれくらい使っているかで判断できることに気づきました。なぜか分かりませんが、人とコミュニケーションする必要があるときは Twitter をよく使います。
そして、もうひとつ別のモードもあります。たとえば今、頭の中が非常にクリアです。**私たちは新しい段階に到達した。**今は GPT-5.4 のようなとても強力なモデルがあって、パフォーマンスが非常に優れている。そしてアプリ体験も予想を超えており、Windows を含めてすべてのプラットフォームをカバーしています。だから今こそ、本当にクラウドに戻って、そこにもっと力を注ぐタイミングだと思っています。
このような段階に入ると、私は次に何をすべきか、現状がどうなっているかを考える時間が増えます。これは調整（コーディネーション）モードです。このモードでは Codex に費やす時間は減り、コードを書くよりも、Codex を使ったコミュニケーションが中心になります。少なくとも私はこの 2 つのワークモードがあると思います。もちろん他にもあるかもしれません。
**司会者 Peter：**どれくらいのクロスファンクショナルなすり合わせが必要ですか？
社内でそれほど多くのクロスファンクショナルなすり合わせはほとんど必要ありません。意図的に“海賊船”みたいなチームだと思うようにしているんです。Codex チームの中でも今は私と、最近加わった新しいプロダクトマネージャーが 2 人だけです。何人かリーダーはいますが、最近まで基本的に皆が私に直接レポートしている状態でした。それでも、私たちはわりと曖昧な形で一緒にプロジェクトを前に進めているので、チーム内のすり合わせは多くありません。
ただ、今だんだん明確になってきているのは、Codex を作るうえで大事な部分が coding agent の開発だということです。そしてチーム全員が、coding agent はコードを書く以外にも非常に役立つと理解しつつあります。
たとえば、ユーザーが Codex app を使う目的はコードを書くことだけではないことを見つけました。彼らはソフトウェア開発ライフサイクル全体のさまざまなタスクをそれでこなしています。そして今では OpenAI のほとんどの従業員が Codex app を使っています。技術者でない人でも、私がよくこのアプリを使っているのを目にします。
そういう気づきがあるので、私たちは「Codex を開発者だけに役立つものにしてはいけない」ということを考える必要があります。すると、より多くのクロスファンクショナルなすり合わせが必要になります。なぜなら OpenAI には ChatGPT もあり、多くのユーザーがそれを使っているからです。だから私たちは、これらのプロダクトをどうよりうまく組み合わせるかを、非常に慎重に考える必要がある。
私の見方では、開発者エクスペリエンスチームは今、Codex チームの延長みたいなものになっています。私たちの時間の大半は Codex に使っています。主にいくつか理由があります。
まず、これはとてもワクワクするプロダクトで、開発者が Codex を使うのを本当に楽しんでいます。私たちはそれをさらに良くしたい。 Alex が言ったように、私たちの仕事はフェーズに分かれています。Codex チームと一緒に、プロダクトリリースの準備作業にも取り組みます。たとえばリリースに必要な素材の準備や、開発者が Codex を最大限に活用できるように教えること。リリース後は、さらに開発者が Codex をさまざまな状況でどう活用できるかを探索できるよう導きます。
もうひとつ、とても面白いのは、OpenAI 全体のプラットフォームを見ると、今日すでに何百万もの開発者が私たちの API を使い、画像から音声までといった各種モダリティのアプリケーションを構築していることです。
今いちばん良い開発の仕方は、Codex を入口点にすることになりつつあります。もし 1 年前に戻る、あるいは去年の夏に GPT-5 を出したばかりの頃に戻ると、私たちはたくさんのガイドを書いて、GPT-5 用の prompt の書き方を教える必要がありました。GPT-5 は推論能力がとても強いモデルで、GPT-4 とは大きく違います。ですが今は、こうしたユースケースの中でも、開発者が Codex と skills を使ってタスクをこなせるようにしています。
たとえば、統合システムを更新する必要がある場合には、Codex とそのスキル機能を使うのがおすすめです。その結果、Codex がほとんど完全にタスクを手伝ってくれる。だから私たちのチームは、クロスファンクショナルな協働にも非常に力を入れていて、Codex を OpenAI の開発者プラットフォーム全体の基盤だと見なしています。
私たち Codex チームの働き方の中で、すごく面白い特徴があると思っています。私にとっていちばん良い部分は、コミュニティとのインタラクションです。オンラインでも、リアルイベントでも、とにかくコミュニティとのつながりを大切にしています。
プロダクトのリリース時には、私たちの仕事はリリース指向——いつ、何を出すかを明確にすることにかなり寄っています。同時に、**フィードバック指向でもある——コミュニティがフィードバックをくれたら、私たちは迅速に行動して問題を修正し、彼らとコミュニケーションする。**だから私たちのチームは常に非常にオンラインで動いている状態を保っています。これはとても重要だと思います。
たとえば Codex app を出したときは、Dom と彼のチームと非常に密に協力しました。彼らが大規模な alpha テストを組織して、多数のユーザーを招待して、一緒にプロダクトを開発してくれました。彼らのフィードバックのおかげで、私たちはアプリだけでなく、skills やドキュメントなどの関連リソースも改善できた。
これこそが、私たち Codex チームの独自の強みだと思います。私たちはオープンソースなので、私たちがやっていることはすべて高い透明性を保っています。そしてコミュニティも、そのやり方に大きなサポートとフィードバックを返してくれています。
**司会者 Peter：**では Peter（OpenClaw の創業者）について話しましょう。私は OpenClaw の初期ユーザーです。みなさんはどうやって Peter をチームに統合したんでしょう？この個人エージェント (personal agent) のビジョンは、彼が今やっていることと関係があるのか？また、どう計画しているのか？
2 つの側面があります。まず、**Peter は Codex のヘビーユーザーです。**実際、OpenClaw のかなりの部分は Codex によって構築されています。彼は自分の使った体験を通じて、チームに大量のフィードバックをくれました。そのフィードバックは私たちが Codex を改善するうえで非常に役立ちました。これが彼の“副業”であったとしても、彼は本当に没頭していて、私たちはそこにすごくワクワクしています。
次に、細かいことは今は詳しくは言えませんが、彼は次世代の個人エージェント (personal agent) を作るのを手伝っていて、それを ChatGPT に直接統合しているところだと言えます。
Peter の仕事で最も魅了されるのは、みんなが OpenClaw を使っているとき、たぶん将来の可能性をなんとなく感じ取っているかもしれない。でも、私を驚かせたのは、Peter がとてもずっと前から、そのビジョンを見抜いていたことです。
2025 年全体を振り返ると、去年彼が 40 個以上のオープンソースプロジェクトを開発していましたが、それらはすべて 1 つのコアビジョンに基づいています。**コマンドラインインターフェースを通じて、彼のカレンダー、ツイート、Gmail などの個人ツールにアクセスする。**これらのプロジェクトによって、彼は実際に skills とコマンドラインツールのビジョンを現実に変えました。そして私たちが今日使っているプログラミングのインテリジェントエージェント（coding agent）も、そのビジョンに基づいて構築されているんです。
今後、このインテリジェントエージェントはプログラミングツールにとどまらず、あらゆる種類の個人エージェント (personal agent) になっていきます。だから、この過程で Peter はとても貴重なフィードバックをくれる。すでに多くの今やオープンソースのエコシステムの中核になっているツールを開発してきているからです。
司会者 Peter：
ピーターのような人が、こんなに素晴らしいオープンソースコミュニティを築けるのは、本当に尊敬します。彼のツールはとても使いやすくて、私はもう他のアプリを開きたくないです。小さなロボットとチャットするだけでいい。
それは何のシステムに接続しているんですか？全部のものに接続しているんですか？
そうです。いろいろなサービスに接続しています。たとえば銀行情報、YouTube アカウント、音声アシスタント、カレンダー、そして Google のサービスにアクセスできます。ベッドの上にいると、妻が「誰と話してるの？」って聞いてきます。私は「OpenClaw のロボットと話してるんだよ」と答えます。
ただ、今はいろんな“ご投機者”が最大 5000 ドルも払うと、他人が OpenClaw をセットアップできるよう手伝うサービスを提供しています。なので、もしみなさんがそれをもっと大衆化して、もっと始めやすくできたら、それは大きなブレークスルーになります。みなさんは確かに正しい方向に進んでいます。
**司会者 Peter：**あなたたちが以前「今は多くのチームで PM がそんなに要らない」みたいなことを言っていましたよね？
私は、これらのツールでいちばん驚くのは、PM が必要か不要か、という問題だけではないという点です。**ほとんどすべての従来の職業的な昇進の“階段”が、曖昧になってきています。**以前は役割分担がはっきりしていました。デザイナーは設計、エンジニアは開発、PM はマネジメント、そしておそらく“黄金比”みたいな特定の比率がある……みたいな感じでした。
でも今は、たとえばあなたがエンジニアなら、生産性が明確に上がる。デザイナーなら、これらのツールを使って超能力を手に入れて、より技術的になります。PM なら以前は戦略ドキュメントを書くくらいだったのに、今は直接プロトタイプできます。だからといって、何十億人ものユーザーに対して責任を負う必要がある、というわけではありません。しかし実際に何かを作ることはできるし、チームに対して自分のビジョンを示すこともできます。
だから、私をいちばん魅了するのは、いま職業の階梯の間の境界があいまいになっていることです。私たちは誰もが実は“構築者（builder）”で、みんなで協力して構築を完成させます。
私はどこかネットで「スタートアップに PM がいて、エンジニアが 20 人くらい未満なら危険信号かもしれない」みたいなことを言った記憶があります。あなたが言った通りで、**こうしたすべての役割が徐々に融合してきています。**デザイナーはもっとエンジニアリング寄りのことができるようになり、エンジニアはデザインに手を伸ばせるし、PM も構築に参加できる。でもエンジニアは通常コードを書くことに集中する必要があるので、昔はタスクの選別や他の PM 的なプロジェクトマネジメント部分は扱いませんでした。
でも今は、それがとても簡単になりました。たとえば Codex のような agent に、フィードバックや優先順位の分析を任せられる。そうすればエンジニアは、自分の仕事にもっと集中する時間を確保できます。いまは、誰もが他の人の仕事もできるようになってきていると思います。
Scott Belsky が提案したアイデアに、**“人材スタックの坍縮（collapse the talent stack）”**というものがあります。私はこの見方が好きで、本当にそれが起きていると思います。部屋に必要な人が少なければ少ないほど物事は進みやすくなり、意思決定もより明確になります。
**では問題は：PM はまだ何ができるの？**私は多くの PM が実際に転職を考えるべきだと思います。たとえばもしあなたが PM で、ずっとエンジニアになりたいと思っているけど、管理するほうが得意でエンジニアリング能力が高くないなら、今はエンジニアリングマネージャー (engineering manager) になるのが良いかもしれません。インテリジェントエージェントがあることで、あなたにとってより明確な役割になる可能性がある。別の例として、PM の一部はデザイナーになるほうが向いているかもしれません。実装に近い仕事です。
最終的には個人の興味次第だと思います。私にとっては、興味と自律性は AGI 時代における人類の最も中核的で最も重要な資質だからです。だから、あなたがコードを書くことにより強い関心があって、これまで PM の仕事を誰かがやる必要があったからこの役割にいた、というだけなら、今は完全にエンジニアに転向して、エンジニアリングの観点から同じことを続けることができます。デザインの領域でも同じです。
ただ、もし本当に関心があるのがユーザーとの対話だという場合——それが、実際の構築作業から離れることになったとしても。たとえばユーザーのニーズを理解したり、市場のトレンドを読み解いたりするようなことです——十分に大きいチームであれば、PM にはまだ活躍の余地があります。
もう 1 点付け加えると、**私はどんな問題領域にも人間が責任を持つ必要があると思っていますが、その“人”が必ず PM である必要はないとも思います。**それはかなりプロダクトの性質次第です。
私たちはここでとても幸運です。私たちは Codex のために働いている。つまり開発者向けのツールであり、私たち自身が最良のユーザーなんです。そしてオープンソースだから、コミュニティと直接やり取りして共同開発もできます。
でも、もし 10 年前に戻ってみると——たとえば私が Stripe で働いていたとき、会社は 250 人だったのに PM が 1 人もいなかったし、AI ツールすらありませんでした。なぜ？Stripe は API 製品で、私たちは全員エンジニアであり、「優れた API とは何か」を直感的に理解できていたからです。あのとき私たちが構築していたのは、私たちの夢の API——たった数行のコードで実現できるような、エレガントな解決策でした。
でももしあなたが別の領域にいるなら、たとえばユーザーのニーズがエンジニアの直感とあまり一致しない場合、顧客と会話し、彼らのニーズを理解するために、より多くの PM が必要になります。**特に、あなたが提供する業界や領域がエンジニアの直感と完全には一致しないとき、PM の役割はさらに重要になります。**ただ、Codex チームでは私たちは非常に幸運です。私たちが作っているのは、私たち自身も使いたいと思うツールだからです。
そういう環境では、**PM の役割は単にラベルでしかなくなり得る。つまりユーザーにいちばん関心があり、ユーザーのニーズを最も気にしている人、**それがたまたま非常にユーザーに近いエンジニアであってもいい。だから、こうした職能ラベルは、徐々に従来の意味を失ってきています。少し混乱はありますが、それは悪いことではないと思います。
私も自分のチームでも同様の発見をしています。最も良いエンジニアは、私に「次は何を作るべきですか？」とは聞きません。彼らが主体的にユーザーと話し、必要なものを自分で明らかにして、それから私と相談する。そうすることで、みんなの目標がかなり一致するんです。
それが、まさに私たち Codex チームの仕事の仕方です。今日 Codex app で使われている多くの機能は、実際にはエンジニアたちがボトムアップで提案した、素晴らしいアイデアから来ています。彼ら自身がそれを必要としていたからです。
ただ、私が特に一緒に仕事をしやすいのは、あるタイプのエンジニアです。**彼らはユーザーと話すのが好きで、どんな機能を作るべきかを考えるのが好き。**そういう人たちは、システムを組む面でも非常に優れていて、速いし、能力も高いし、思考もクリアです。でも一方で、ユーザーとのやり取りにまったく興味がなくて、ただシステム構築に集中したいだけのエンジニアもいる。そういう人にも大きな成長の余地があると思います。
繰り返しますが、これが私の AI 時代の見方です——**私たちは、より“自分らしく”できる。**AI とチームが、あなたがやりたくないことを肩代わりしてくれるので、あなたの興味や強みに集中できるようになります。
私もそう思います。“ビルダー（builder）”というタグはとても重要だと感じます。多くの PM はリーダーになりたいと思っているけれど、従来の職能の昇進の階段だと、VP などの役職になった瞬間に、逆に構築する時間がなくなってしまいます。毎日プロダクトレビューの中でフィードバックをするだけで、実際に開発する時間がない。そういう PM は多くないように思いますし、そうはなりたくない。私はユーザーに近いところにずっといて、本当にプロダクトをリリースしたい。
完全に同意です。私は実際、PM はリーダー役だとは思っていません。むしろ“穴埋めの役割”として捉えています。ときには、その役割がある程度のリーダーシップを要求されることはあります。けれど、それでもリーダーシップの役割は、誰か 1 人の天才的なソリューションに頼ることではなく、チームが合意に達するのを助けることが中心です。
確かなことが 1 つあります。OpenAI では、最も優秀な PM は具体的な細部まで深く入り込みます。そして高いリーダー職として OpenAI に加わるのはかなり難しいことだとも思います。ここでは文化として細部への注意が依然として強く重視されているからです。だから最善のやり方は、最初から細部に深く入ることです。
**司会者 Peter：**Codex チームを採用するとき、候補者が Codex のヘビーユーザーであること以外に、どんな資質を重視しますか？
前に言いましたが、私は**候補者の“自律性 (agency)”**をとても重視しています。私たちは、積極的に動ける人を探しています。これは最重要な資質の 1 つだと思います。
OpenAI、特に Codex チームの文化は、「入社したら、12 個の段階的に難しくなるタスクを順番にやるんだよ」といったタイプではありません。私たちのスタイルはもっとこうです。「ようこそ！さあ、探索を始めて。」
だから私たちは、自走できる人を探しがちです。行動力があり、自分なりの考えがあり、自分が何をやりたいのかを理解していて、既存のアイデアに挑むことを恐れない人。正直言って、いくつかの既存アイデアはそもそも間違っているかもしれない。最初はたまたまの判断で決めてしまっただけかもしれないからです。
私が理想とする同僚は、追加の責任を進んで引き受けられる人、しかも未知の領域を任されてもいいと思える人です。そういう資質を特に重視します。具体的なスキルに関しては、私たちは通常、技術力が高く、エンジニアリングに関連する候補者を優先します。
同意します。私の開発者エクスペリエンス (DevX) チームでも、私は通常高い自律性を持つ人を探しています。技術的に非常に強くて、特に Codex みたいなツールを使うときに非常にうまくやれる必要がある。それに加えて、開発者やビルダー (builders) と一緒に働き、知識を共有することに強い情熱を持っている人を特に重視しています。
たとえば今週、Thomas が私のチームに加わると発表したところです。彼はオープンソースの Codex monitor を開発した人です。彼はとても創造的で、Codex のヘビーユーザーでもあり、そして Codex を使ってツールをどう作っているか、その経験を熱心に共有してくれます。
私たちがそういう人材を必要としているのは、何百万もの開発者を Codex が示す明るい未来へ導くために取り組んでいるからです。私は、agentic coding（エージェントによるコーディング）が、ソフトウェア開発、アプリ、プロダクト構築に対する従来の考え方を根本から変えている最中だと信じています。私たちの目標は、世界中の人にこの可能性を見せて、開発者がこのツールを活用して自分の創意を実現する方法を学べるようにすること。私が探しているのはまさにそういう資質です。
補足すると、私の見立てでは DevX チームの理想的な候補者は、シンプルに言えば**「とても優秀なエンジニアで、しかもソーシャルメディアとコミュニティとのやり取りが得意」**と表現できます。
その通りですね。ただもう 1 つ補足したいのは、候補者にはコミュニティに対する強い責任感が必要だということです。そして世界各地でソーシャルメディアの使われ方が違う点も考慮する必要があります。たとえば、ある地域では開発者は Twitter ではなく LinkedIn や別のプラットフォームをより好むかもしれない。だから定義を広げる必要があります。候補者は、世界規模でソーシャルメディアでうまく活動できる必要がある。私たちが特に重視するのは、コミュニティと関わるのが好きで、教えることや知識の共有に熱心な人です。
実は、自律性は面接の前から見えてきます。たとえば、オンラインで作品を公開しているか？自分の side projects はあるのか？
誰かが DM で「チームに入りたい」と言ってきたとき、私の最初の反応は「リンクある？」です。リンクがあれば、ほぼ必ず開いて確認します。私は、その人が本当に何かを構築しているのかを知りたくて、作品をチェックするんです。
もちろん、応募している背景を説明したカバーレターを添える人もいて、その上で履歴書を添付してくることもあります。でも私は、彼らの考え方や実際に構築しているもののほうが見たい。最近ふと気づいた面白いことがあります。私は本当に、彼らがどこの大学に行っていたのかを知らない。
**司会者 Peter：**誰が気にするんですか？誰が気にするんですか？本当にうれしいです。いまは、こうした愚かな学歴がそれほど重要ではなくなった時代に生きているから。あなたが実際に何を構築しているか、それを見せてもらえれば十分なんです。
990.58K 人気度
19.66K 人気度
26.34K 人気度
76.22K 人気度
515K 人気度
OpenAI Codex プロダクト責任者が語る：規範やロードマップがない中で、私たちはどうやってプロダクトを作り出したのか？
「興味と自律性は、AGI 時代における人類の最も中核的で、最も重要な資質です。」
整理 & 編纂：深潮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 の「思考スピード」
仕様書と意思決定プロセスについて
職業の境界が曖昧になり、デザイナーが進化する
プロダクト設計哲学：モデルを「見えなくする」
計画哲学：『中期の気まずさ』を拒否する
『インテリジェント・エージェントの委任』がもたらすUIの変革
職能の階段の消失と『人材スタックの崩壊』
採用基準：履歴書より作品
現場デモ：Codex Spark で数秒以内にゲームを構築
**司会者 Peter：今日は Alex と Romain を迎えて、すごくわくわくしています。彼らは OpenAI の Codex チームのメンバーです。Codex の新機能をどう構築するのか、Codex がどんな能力を持っているのか、そして Codex チームがどうやって休まずプロダクトをリリースしているのかをデモしてくれます。みなさん、ワンショット（one-shot）プロンプトで、実際にどんなものが作れるのかを素早く見せてもらいたいと思いませんか？
Romain：
もちろん。画面共有をします。実は、私が見せられることはたくさんありますが、たぶん素早く一つだけ——たとえば、ここに私がずっと作っている iOS アプリがあります。このアプリに新機能を追加したいなら、私は単に口頭でこう言うだけです。「ねえ、NASA の月への帰還ミッションに向けて、新しい画面を追加してくれる？」それから GPT-5.4 にそのプロンプトを投げると、モデルはその特定の APP の新しい画面を作ってくれます。
それに加えて、Codex Spark モデルもあって、数秒のうちに何でも構想して反復できます。Spark モデルが素早い応答を返す違いを見せます。左が GPT-5.4、右が Codex Spark。さらに平均すると毎秒だいたい 1200 のデータです。速すぎて狂ってます。だから、たとえばゲームみたいな何かを作りたいときは——この会話を始める前に、実際に私は Codex アプリに行って、クイックプロンプトで Animal Crossing っぽい小さな 2D ゲームを作りました。
自分の考えがクリアになったとき、Codex を使う別の機能として、私はすごく気に入っています。Codex を開いて、会話を画面の上部に浮かせるんです。そうすれば、もし本当にこのゲームを作っているなら、反復を続けて、もっと多くのアイデアを生み出せます。Peter、あなたなら、このゲームで何を変えたいですか？
**Peter：**たぶん、もう少し装飾を足して、家や木みたいなものを増やして、もっと生き生きさせる感じですかね？
Romain：
じゃあ、そのタスクを送ります。すると基本的に数秒で Codex Spark が編集してくれて、変更がリアルタイムで見えるようになります。以上です。新しい木が現れるのを見ました。
だからこそ私は Codex にすごくワクワクしているんです。あなたは本当に、GPT-5.4 みたいな最先端モデルを“手に入れる”ことができます。つまり、分析や数百万行のコードの移行のような、非常に複雑なタスクも任せられる。ただし、インスピレーションが湧いて、しかも考えがはっきりしているときには、クイックモードに切り替えたり、Codex Spark に切り替えたりできる。すると、この狂った思考スピードで、あらゆるものを構築できるんです。
プロダクト仕様については、私たちは約 10 個の要点を書く程度で、それ以上はありません
**司会者 Peter：本当に気になっているんですが、チームの中で実際にどのように Codex を使ってプロダクトを作っているんでしょう。Alex、あなたたちは仕様を書くんですか？それとも GPT に仕様を書かせるんですか？それらを動かすためにどのモデルを使っているんですか？
Alex：
私たちが Codex チームで書く仕様書は非常に非常に少ないと思います。実際、私は大部分の仕事は、実際に最も近い人が可能な限り多くの意思決定をするようにすることだと思っています。だから、問題が最終的に“1 人の脳に収めるのが難しいタイプの問題”になったときだけ仕様を書きます。ちなみに言うと、今は 1 人が脳の中に入れられる情報はたくさんあります。彼らはたくさんのことができるからです——ほとんどのコーディング作業を委任できるので、1 人がいまは多くのことをできる。でも、それが最終的に複数人の調整が必要になるようなことになったり、あるいは、私たちが下さなければならない非常に厄介な意思決定が必要になったりするなら、そのときには仕様を書くのかもしれません。ただ、こうした状況で書くドキュメントは、かなりかなり短いものになります。私たちが言うのは、たとえば 10 個の要点みたいなものをまとめて、それで終わりです。
**司会者 Peter：**わかりました。これがどう機能しているか、実際に見せてくれますか？たとえば、Codex にいくつかの要点を渡して、まず実際の要件を書かせる、みたいな感じで？
Romain：
もちろんできます。ただ、最初に、もう少し簡単な例を見せたいと思います。たとえば、私たちが iOS アプリを開発していて、すでにいくつかのタスクは完了しているとします。いま、そのプロジェクトに新しい機能のアイデアはあるけれど、具体的にどの方向に進めばいいのかがまだ分からない。このとき Codex の強みは、次にやることを計画するのを助けてくれるところです。たとえば、私は Shift+Tab キーを押して「プランモード」 (Plan Mode) に入って、「私たちは何を作るべき？」と入力します。すると Codex が自動的に、最初の計画案を作ってくれます。既存のコードベースを分析して、プロジェクトの現在の状態を理解し、いくつかの潜在的なアイデアを提案してくれる。そこに、私も自分の考えを加えて、モデルがより完成度の高い計画を生成するよう導くこともできます。
このプロセスで、Codex は現在のコードやファイルに基づいて提案を出してくることに気づきます。たとえば、「以前に触れた機能をさらに仕上げるべき？それとも信頼性ダッシュボードを最適化すべき？」みたいな質問をしてくるかもしれません。もし信頼性ダッシュボードを最適化すると決めたら、さらに「最適化のターゲットユーザーは誰？ 」といったことを考えるよう導いてくれます。この全体は、ブレインストーミングの相棒と一緒に作業しているような感じです。
私はよく、このやり方で発想を生み出すのに使います。たとえば、ある程度簡単な変更なら、私は直接プロンプトを入力して、Codex にコードを生成させます。
Alex：
一方で、もう少し中程度に複雑な変更の場合は、具体的な計画を生成させたり、実装の進め方を推論してもらったりします。そして、もし自分の中にぼんやりしたアイデアしかないときは、私は通常 Codex を開いて、どう解決すべきか考えさせます。たとえ頭の中に明確な機能要件がなくても、Codex は質問や探索を通じて考えを整理してくれます。
ただ正直に言うと、状況によっては、Codex が作った案をそのまま使わないこともあります。特に変更が複雑なとき。私は Codex の「プランモード」で探索して、クリアな思考を組み立てて、それをエンジニアチームに共有します。最終的には、生成された計画そのものより、その思考プロセスのほうが重要だと感じています。
ところで、チームのデザイナーが今書いているコード量が、6 か月前のエンジニアよりも多いという話をしましたが、これは以前は考えられないことでした。主な理由は、ツールの進歩です。デザイナーがより深く開発に参加できるようになった。ですが、私はチームから「去年出した PR（コードマージリクエスト）が少なすぎるよ」って冗談で突っ込まれることもよくあります。多くの変更は小さい調整で済むとはいえ、私は確かにもっとやるべきだと思っています。
今は、**私たちの重点は「コードを生成できるかどうか」ではありません。**エージェント (Agent) が大半のコーディングタスクをこなせるようになっているからです。**本当に重要なのは：私たちが何を作るのか、そしてどうやってプロダクトの品質を高めるのか。**それが理由で、非常に複雑な特性については、プロダクトマネージャー (PM) にそのシステムの実装と運用保守を任せるより、堅実な責任者を見つけて管理させるほうが私は好みます。
デザイナーが書くコードは、6 か月前のエンジニアよりも多い
**司会者 Peter：**Codex のアプリは使うと非常に直感的でシンプルです。外の一部の専門プロダクトと比べると、Codex は学習曲線がかなり低いと思います。ほかの専門プロダクトは機能が強力でも、学ぶのにかなり時間がかかります。私は、もし Twitter で関連情報をフォローしていなかったら、そもそもそれらをどう使えばいいのか分からなかったかもしれない、とすら思います。
ただ、Codex に感心したのは、シンプルで使いやすいだけでなく、skills（スキル）や automations（自動化）といった多くの高度な機能も提供している点です。みなさんのチームの中では、そうした機能を頻繁に使いますか？**
Romain：
はい、かなり使っています。実際、skills は Codex アプリの中でもっとも面白い機能の 1 つだと思っています。たとえば今、もしデザイナーと一緒に Figma を使っているなら、Figma の skill を開くだけで、Figma のファイルから React コンポーネントや変数などの詳細を直接取り出せます。そのうえで Codex が、自動的に対応するコードを生成します。もう 1 つの例として、もしアプリケーションを開発していて、それを共有したりデプロイしたりしたいなら Vercel、Cloudflare、Render などに対して、skills 経由で簡単な指示を出すだけで、Codex がそれらのタスクを自動で実行してくれます。
最近、友人と話していたとき、彼はプロダクトを改善するアイデアがたくさんあると言いました。そこで彼は Codex にこう言ったんです。「これらのタスクを全部 Linear に書き込んで、追跡できるようにして。」そして彼は Linear の skill を使いました。続いて彼は Codex に「俺は寝る。さっき話した全部のタスクを続けて完了としてマークしといて。」と言いました。すると翌朝、彼が起きたときには、タスクが本当に全部完了していたんです。
Alex：
先ほど触れてくれたアプリのシンプルさについて、どう設計しているかを少し共有したいと思います。この領域では、開発者は日常の作業を簡単にするために、みずから自動化ツールを作ることに熱中しがちです。私たちは、プロダクトの重要な特徴は“高度に設定可能であること”だと考えています。Codex にとっては、それはまるでオープンソースのツールボックスのようなもので、ユーザーが中に深く入り込んで、自分のニーズに合わせてカスタマイズできます。
新機能をリリースするたびに、たいてい Twitter で「この機能、問題あるんじゃない？」みたいな文句を言うユーザーがいます（たとえまだ正式リリース前でも）。問題の原因は通常、彼らが自分でコードを修正したり、fork してしまったりしていることです。でも私にとっては、それはむしろプロダクトが成功している証拠です。最前線のユーザーが私たちと一緒に未来を探っていて、それがプロダクトを前に進めてくれているからです。
ただ、私たちも気づいています。こうしたヘビーユーザー向けのプロダクトを作るだけでは十分ではありません。そうしないと、最終的にプロダクトが複雑で分かりにくくなります。私たちはバランスを見つける必要があります。上級ユーザーのニーズは満たしつつ、普通のユーザーにとってはシンプルで直感的であること。だからコア機能の設計には慎重で、それらがユーザーとモデルの間の障害にならないようにし、モデルをより賢くして自動でより多くのタスクをこなせるようにします。
Romain：
そしてそのうえで、できる限り可配置（可設定）な形でプロダクトを上級ユーザー向けにパッケージして、彼ら自身に探索と利用を任せる方法を考えます。例えば、今すでにユーザーが sub-agents（サブエージェント）を実装しています。これらの機能は私たちが先に設計して用意したものではなく、ユーザーが自分で発見して実験したものです。そうした機能の使われ方を観察することで、私たちは多くのことを学びました。
そして次に考えます。**これらの機能を、他のユーザーにとっても“超シンプル”にするにはどうすればいいのか？**Codex app はその良い例です。去年 12 月に GPT-5.2 Codex がリリースされた頃、モデルの能力が徐々に安定し始めましたが、同時にある“臨界点”を越えたんです。ユーザーが、より長い時間・より複雑なタスクをモデルに委任できるようになり、そしてモデルが一度にそれらを完了できるようになりました。
私たちは、すでに一部のユーザーが tmuxing（端末内で複数の並行タスクを動かすこと）を使い始めているのに気づきました。これは、端末内でウィンドウを分割して、同時に複数のタスクを走らせるやり方です。SNS 上で、面白い例をいくつも見ました。たとえば Peter Steinberger の写真で、彼の画面には端末ウィンドウが 18 個あり、3 台のディスプレイにまたがっていて、まるで「クリエイティブなオープン・クロー（爪）」みたいに見える。私たちは、ユーザーが Codex を非常に高度なやり方で使っているのを見て、すごくワクワクしました。
同時に、私たちは CLI のような基本プロダクトでもタスク委任の機能を最適化し続けて、うまく動くようにしていました。ただ、同時に気づいたことがあります。たぶん、この方式で働くのはトップ 1% のエンジニアだけです。だから私たちは考えました。この機能をどうすればもっと直感的に見せられるのか、と。だからこそ Codex app を開発したんです。
あなたが初めて Codex app を開くと、シンプルなチャットウィンドウのように見えます。すぐに使い始められて、正常に動きます。でも時間が経つにつれて、サイドバーや複数タスクを動かす能力、タスク間の切り替えを簡単にできる機能など、より多くの機能が徐々に見えてきます。あなたは自分が超効率的になった感覚を持つでしょう。それから、skills タブにも気づいて、さらに多くの機能を探索できます。私たちは、ユーザーが Codex app を使うとき、ゲームをするような感覚で、次々と新しい可能性を発見できる体験にしてほしいと思っています。
Romain：
完全に同意です。しかも、これは最初から私たちが持っていたビジョンでもあります。**コーディングは『インテリジェントなエージェント委任』(agentic delegation) の形で行われる。**私たちが Codex を開発し始めたのはほぼ 1 年前ですが、その時点からこの未来についてずっと考えていました。エンジニアは複数のタスクを同時に扱え、モデルは複雑な細部の実行を担当するようになる、と私たちは信じていました。
ただ正直、当時のモデル能力はそのレベルにまだ達していませんでした。私たちは GPT-5.2 Codex のリリースと、その後の“臨界点”を待つ必要があった。モデルが数時間、あるいは数日レベルで、非常に徹底的で信頼性高く動けることが必要だった。そうしたときに、私たちはふと気づいたんです。従来のターミナルの UI では、この働き方に合わなくなってしまった、と。端末で複数のタブを開いて、それらを数時間走らせるというのは、やっぱり非常に奇妙なインタラクションに感じるはずです。だから、新しい UI が必要で、そのタイミングがちょうど完璧でした。
Alex：
Codex の歩みを振り返ると、重要な“vibe shift”（トレンドの転換点）が 2 回あります。**1 つ目は去年の 8 月。**私たちは Codex Cloud の製品を出しました。とても良いアイデアで、ユーザーはそのときかなりワクワクしていましたが、当時はまだ少し早かったのかもしれません。そこで 8 月には、非常に優れたインタラクティブコーディングモデルである GPT-5 をリリースし、モデルが今扱える問題を解決することにフォーカスすることにしました。そのため Codex CLI と IDE プラグインを出しました。ユーザー数は数か月で 20〜30 倍に急増して、これは本当に素晴らしかった。
**2 つ目の転換点は、去年 12 月から今年 1 月の間です。**そこでようやく、最初のビジョンが実現しました——タスクをモデルに委任すること。モデルの能力が新しい段階に達し、より複雑なタスクを独立してやり遂げられるようになって、まったく新しいフェーズに入ったことを意味していました。
私たちの計画は短期と長期で分け、中期計画はしない
**司会者 Peter：Codex app はどうやって開発されたんでしょう？1 年前には、たとえば「ある時期に Codex app を出す」といった年次ロードマップを作っていましたか？それとも、より市場のニーズを見ながら観察して、いくつかのアイデアを素早くプロトタイプしていく感じでしたか？
Alex：
実は、どちらも違います。リサーチャーの Andre から聞いた、とても良いアドバイスがあったんです。OpenAI では、短期目標も長期目標も計画するけれど、中期計画はしません。中期計画は複雑すぎるからです。
短期計画は通常、今から最大でも 8 週間の目標のことで、8 週間が私たちが設定できる最長の時間幅です。この時間枠の中では、具体的な目標を定めて、チームを結集して全力でやり切ります。これが OpenAI の強み——明確な目標の周りにチームを組織化するのがすごく上手いんです。
一方で、**長期のビジョンも作ります。**たとえば、1 年後の未来を見据えて、そのときモデルがより賢くなっていると想像する、といった具合です。あるいは、未来のモデルは私たちのコンピュータ資源を借りる必要がなくなり、一度に 1 つのことしかできない制約からも解放されて、独立して働けるようになるかもしれない、と考えます。私たちは、無限個のモデルがあり、それらがタスクを独立して完了し、自分でコードを検証し、さらには自分でデプロイやモニタリングまでできる——そして私たちはそれらに手でプロンプトを入れなくてもよい、という世界を持ちたいんです。
しかし、中期計画は気まずくなります。たいていは詳細なプロダクトロードマップの形で現れますが、私たちは基本的にそういうものはありません。私たちは、長期ビジョンと結びつけて、目標を達成するために前進させてくれる具体的なタスクに集中することが多いです。
Codex app の例でいうと、当時の戦略目標は、ユーザーを特定のワークスペース (workspace) から解放することでした。従来の開発ツール（たとえば VS Code）は、たいてい特定のワークスペースに紐づいています。たとえば、あるコードベースの特定のチェックアウト地点やフォルダです。git worktree を使っても、同時に開けるのはせいぜい 1 つの作業ディレクトリで、CLI も同様の制約があります。
でも私たちのビジョンは、**ユーザーがクラウド上のインテリジェントなエージェント (agent) と協働でき、そしてその agent が独立して働けること。**ユーザーが複数の agent と同時に対話でき、さらに 1 つの agent がユーザーのために複数の agent の仕事を調整する——その体験は自然で直感的であるべきだと考えました。
また、最初からクラウドに完全に依存すると、開発者にとって不便だと感じられる可能性があるとも理解していました。環境の設定が必要になり、モデルがタスクを実行するときに手動の介入や調整が必要になると面倒だからです。**だから私たちは、ローカル化された体験を開発することにしました。**それは、ローカルのフォルダともシームレスに協働でき、同時にクラウド上のインテリジェントなエージェントとも接続が保たれるようなものです。
このアプリの開発を始めたとき、私たちはそうした“ビジョン思考”のアイデアをたくさん持っていました。けれど、それらはかなり抽象的な考えでした。並行してエンジニアはさまざまなプロトタイプを作っていました。「私たちにアプリが必要だ」と彼らが言うようになると、いろいろなバージョンを試し始める。実際には、**ハッカソン（ハッカーウィーク）**も開催しました。複数人のエンジニアが、それぞれ独立して異なるバージョンのアプリを開発しました。あなたも参加したかもしれませんが、覚えていません。
このプロジェクトが本格的に動き出したとき、私たちが唯一はっきり書いておく必要があったのは**：なぜ私たちはアプリを開発することが良いアイデアだと考えたのか。**このアプリのための具体的なプロダクト仕様は決めていません。実際の開発作業を通じて、徐々にプロダクトの方向性が明確になっていきました。 **
ただ当時、このプロジェクトにはいくつかの議論もありました——本当にアプリを作る必要があるのか？IDE プラグインは非常に人気が出ていて、プラグインの品質を高めることに集中したほうがいいのでは？CLI も可能性がある。なら、アプリを作ることの意味は何なのか？私たちはどの方向に進むべきなのか？——これが、プロジェクトが始まる時点で直面していた問いの一部です。
Romain：
はい、幸運だったのは、当時すでに成熟した IDE プラグインのソリューションがあり、それを深く最適化していたことです。ユーザーは VS Code、Cursor、Windsurf、そして他の IDE でもそれらのプラグインを使えます。IDE プラグインのコードベースから得た経験が大量にあり、それが Codex app 開発のための非常に堅実な起点になりました。
Alex：
その通りです。実際、Codex app と IDE プラグインは、基盤となる層でかなりの量のコードを共有しています。どちらも、同じコアの Codex harness に接続しています。これは Rust で書かれたオープンソースのフレームワークで、CLI もそれを使っています。私たちは意図的にレイヤー設計を採用して、異なるツール間でコード共有と機能拡張ができるようにしています。
**司会者 Peter：**Codex app を作ると決めるまでのプロセスについては……振り返ると、それはすごく当然の判断に見えます。端末のターミナルを大量に開くより Codex app のほうがはるかに直感的だからです。でも当時、私たちがそれを選んだ主な理由は、Codex app が初心者にとってよりフレンドリーで、さらに複数のインテリジェントなエージェントの協働を管理するのに最適な UI だったからです。
Alex：
私たちのチームの考え方は、AGI（汎用人工知能）のビジョンに強く影響されていると思います。ずっと考えていました——未来の働き方はどんなものになるのか？
別の言い方をすると、私たちはちゃんと理解していました。ユーザーが自然に複数のインテリジェントエージェントへタスクを委任できるUI が必要だということ。将来のモデルがその能力を持つことも分かっていました——実際にユーザーが、エージェントをまたいでタスクを委任しようとしているのをすでに見ていました。そうした協働が自然に見えて、さらにクラウドにシームレスに拡張できる UI が必要だったんです。
私たちは、その UI が人間工学に合っていて、複数のインテリジェントエージェントと協働することが直感的で自然な体験に感じられるようにしたい。複雑な操作やコツを必要とするものではなく。
Romain：
はい。そしてこのアプリの対象は初心者だけではありません。実際、最も経験豊富で、最前線で働くエンジニアでさえ——OpenAI 内のトップクラスのエンジニアである Peter や OpenClaw、Greg Brockman など——彼らはもう Codex app を主要な開発ツールとして使い始めています。これはインテリジェントなエージェント委任 (agentic delegation) のビジョンが、徐々に現実になっていることを示しています。
Alex：
そうです。私たちが Peter について言及したのは、彼が OpenAI に最近加わったばかりだからです。私たちはそれにすごくワクワクしました。去年 10 月に、サンフランシスコの Fort Mason で彼と散歩しながら、新しい UI を開発するというアイデアを話したとき、私はこう言いました。「タスク委任（delegation）をもっと自然にする新しい UI が欲しいんだ。」すると彼は「そんなものは絶対に使わないよ」と言っていたんです。
ところが先週末、彼がツイートしていました。「実はこのアプリ、けっこう使いやすい。今は気に入ってる。」
Alex が Codex のプロダクトマネージャー (PM) として日常でやっていること
**司会者 Peter：**Alex、あなたは以前しばらく Codex チームの唯一のプロダクトマネージャー (PM) だったんですよね？今 Codex チームは何人くらいですか？50〜100 人くらいの規模ですか？
Alex：
だいたい、そのくらいです。私たちが 5 月の時点では 8 人くらいだったと思いますが、正確な数字は覚えていません。でもそれ以降、チームは非常に急速に成長して、今はだいたい 50〜100 人くらいの範囲です。
**司会者 Peter：**それでは普段、どう時間を配分していますか？日常業務はどんな感じですか？あるいは典型的な 1 日ってそもそもないんですか？
Alex：
最近、私もこの問いを考えています。答えるのが難しいと感じるからです。私は自分の仕事のスタイルが**段階的（フェーズ型）**だということに気づきました。これはもちろん私個人のやり方なので、全員に当てはまるわけではないです。
たとえば Codex app をリリースしたときは、私は完全に実行モードでした。当時は、プロダクトの品質に全力を注いでいました。細部の抜け漏れがないか、些細なことまでちゃんと固めるか。そのモードでは、かなりの時間 Codex ツールを使っていました。
フィードバックを取りに Codex を使います。たとえば Slack での議論内容やユーザーのフィードバックを把握するためです。Codex にそれらを要約させて、それを Linear に記録します。それ以外にも Codex を使ってコードの品質を分析し、実際に小さなコード修正をそのまま行います。小さな問題を Codex で直接処理するほうが、ほかの人にタスクを調整して優先順位をつけてもらうより速い場合があるんです。特に、アプリを 2 週間以内に出すことが目標のときはなおさらです。
もちろん、この過程では人間らしい仕事もたくさんあります。たとえばチームを鼓舞して士気を上げたり、やる気を出させたり。そして、私たちが開発しているプロダクトに対して批判的にも見続ける。実は、自分が実行モードなのかどうかは、Twitter をどれくらい使っているかで判断できることに気づきました。なぜか分かりませんが、人とコミュニケーションする必要があるときは Twitter をよく使います。
そして、もうひとつ別のモードもあります。たとえば今、頭の中が非常にクリアです。**私たちは新しい段階に到達した。**今は GPT-5.4 のようなとても強力なモデルがあって、パフォーマンスが非常に優れている。そしてアプリ体験も予想を超えており、Windows を含めてすべてのプラットフォームをカバーしています。だから今こそ、本当にクラウドに戻って、そこにもっと力を注ぐタイミングだと思っています。
このような段階に入ると、私は次に何をすべきか、現状がどうなっているかを考える時間が増えます。これは調整（コーディネーション）モードです。このモードでは Codex に費やす時間は減り、コードを書くよりも、Codex を使ったコミュニケーションが中心になります。少なくとも私はこの 2 つのワークモードがあると思います。もちろん他にもあるかもしれません。
**司会者 Peter：**どれくらいのクロスファンクショナルなすり合わせが必要ですか？
Alex：
社内でそれほど多くのクロスファンクショナルなすり合わせはほとんど必要ありません。意図的に“海賊船”みたいなチームだと思うようにしているんです。Codex チームの中でも今は私と、最近加わった新しいプロダクトマネージャーが 2 人だけです。何人かリーダーはいますが、最近まで基本的に皆が私に直接レポートしている状態でした。それでも、私たちはわりと曖昧な形で一緒にプロジェクトを前に進めているので、チーム内のすり合わせは多くありません。
ただ、今だんだん明確になってきているのは、Codex を作るうえで大事な部分が coding agent の開発だということです。そしてチーム全員が、coding agent はコードを書く以外にも非常に役立つと理解しつつあります。
たとえば、ユーザーが Codex app を使う目的はコードを書くことだけではないことを見つけました。彼らはソフトウェア開発ライフサイクル全体のさまざまなタスクをそれでこなしています。そして今では OpenAI のほとんどの従業員が Codex app を使っています。技術者でない人でも、私がよくこのアプリを使っているのを目にします。
そういう気づきがあるので、私たちは「Codex を開発者だけに役立つものにしてはいけない」ということを考える必要があります。すると、より多くのクロスファンクショナルなすり合わせが必要になります。なぜなら OpenAI には ChatGPT もあり、多くのユーザーがそれを使っているからです。だから私たちは、これらのプロダクトをどうよりうまく組み合わせるかを、非常に慎重に考える必要がある。
Romain：
私の見方では、開発者エクスペリエンスチームは今、Codex チームの延長みたいなものになっています。私たちの時間の大半は Codex に使っています。主にいくつか理由があります。
まず、これはとてもワクワクするプロダクトで、開発者が Codex を使うのを本当に楽しんでいます。私たちはそれをさらに良くしたい。 Alex が言ったように、私たちの仕事はフェーズに分かれています。Codex チームと一緒に、プロダクトリリースの準備作業にも取り組みます。たとえばリリースに必要な素材の準備や、開発者が Codex を最大限に活用できるように教えること。リリース後は、さらに開発者が Codex をさまざまな状況でどう活用できるかを探索できるよう導きます。
もうひとつ、とても面白いのは、OpenAI 全体のプラットフォームを見ると、今日すでに何百万もの開発者が私たちの API を使い、画像から音声までといった各種モダリティのアプリケーションを構築していることです。
今いちばん良い開発の仕方は、Codex を入口点にすることになりつつあります。もし 1 年前に戻る、あるいは去年の夏に GPT-5 を出したばかりの頃に戻ると、私たちはたくさんのガイドを書いて、GPT-5 用の prompt の書き方を教える必要がありました。GPT-5 は推論能力がとても強いモデルで、GPT-4 とは大きく違います。ですが今は、こうしたユースケースの中でも、開発者が Codex と skills を使ってタスクをこなせるようにしています。
たとえば、統合システムを更新する必要がある場合には、Codex とそのスキル機能を使うのがおすすめです。その結果、Codex がほとんど完全にタスクを手伝ってくれる。だから私たちのチームは、クロスファンクショナルな協働にも非常に力を入れていて、Codex を OpenAI の開発者プラットフォーム全体の基盤だと見なしています。
Alex：
私たち Codex チームの働き方の中で、すごく面白い特徴があると思っています。私にとっていちばん良い部分は、コミュニティとのインタラクションです。オンラインでも、リアルイベントでも、とにかくコミュニティとのつながりを大切にしています。
プロダクトのリリース時には、私たちの仕事はリリース指向——いつ、何を出すかを明確にすることにかなり寄っています。同時に、**フィードバック指向でもある——コミュニティがフィードバックをくれたら、私たちは迅速に行動して問題を修正し、彼らとコミュニケーションする。**だから私たちのチームは常に非常にオンラインで動いている状態を保っています。これはとても重要だと思います。
たとえば Codex app を出したときは、Dom と彼のチームと非常に密に協力しました。彼らが大規模な alpha テストを組織して、多数のユーザーを招待して、一緒にプロダクトを開発してくれました。彼らのフィードバックのおかげで、私たちはアプリだけでなく、skills やドキュメントなどの関連リソースも改善できた。
これこそが、私たち Codex チームの独自の強みだと思います。私たちはオープンソースなので、私たちがやっていることはすべて高い透明性を保っています。そしてコミュニティも、そのやり方に大きなサポートとフィードバックを返してくれています。
**司会者 Peter：**では Peter（OpenClaw の創業者）について話しましょう。私は OpenClaw の初期ユーザーです。みなさんはどうやって Peter をチームに統合したんでしょう？この個人エージェント (personal agent) のビジョンは、彼が今やっていることと関係があるのか？また、どう計画しているのか？
Alex：
2 つの側面があります。まず、**Peter は Codex のヘビーユーザーです。**実際、OpenClaw のかなりの部分は Codex によって構築されています。彼は自分の使った体験を通じて、チームに大量のフィードバックをくれました。そのフィードバックは私たちが Codex を改善するうえで非常に役立ちました。これが彼の“副業”であったとしても、彼は本当に没頭していて、私たちはそこにすごくワクワクしています。
次に、細かいことは今は詳しくは言えませんが、彼は次世代の個人エージェント (personal agent) を作るのを手伝っていて、それを ChatGPT に直接統合しているところだと言えます。
Romain：
Peter の仕事で最も魅了されるのは、みんなが OpenClaw を使っているとき、たぶん将来の可能性をなんとなく感じ取っているかもしれない。でも、私を驚かせたのは、Peter がとてもずっと前から、そのビジョンを見抜いていたことです。
2025 年全体を振り返ると、去年彼が 40 個以上のオープンソースプロジェクトを開発していましたが、それらはすべて 1 つのコアビジョンに基づいています。**コマンドラインインターフェースを通じて、彼のカレンダー、ツイート、Gmail などの個人ツールにアクセスする。**これらのプロジェクトによって、彼は実際に skills とコマンドラインツールのビジョンを現実に変えました。そして私たちが今日使っているプログラミングのインテリジェントエージェント（coding agent）も、そのビジョンに基づいて構築されているんです。
今後、このインテリジェントエージェントはプログラミングツールにとどまらず、あらゆる種類の個人エージェント (personal agent) になっていきます。だから、この過程で Peter はとても貴重なフィードバックをくれる。すでに多くの今やオープンソースのエコシステムの中核になっているツールを開発してきているからです。
司会者 Peter：
ピーターのような人が、こんなに素晴らしいオープンソースコミュニティを築けるのは、本当に尊敬します。彼のツールはとても使いやすくて、私はもう他のアプリを開きたくないです。小さなロボットとチャットするだけでいい。
Alex：
それは何のシステムに接続しているんですか？全部のものに接続しているんですか？
司会者 Peter：
そうです。いろいろなサービスに接続しています。たとえば銀行情報、YouTube アカウント、音声アシスタント、カレンダー、そして Google のサービスにアクセスできます。ベッドの上にいると、妻が「誰と話してるの？」って聞いてきます。私は「OpenClaw のロボットと話してるんだよ」と答えます。
ただ、今はいろんな“ご投機者”が最大 5000 ドルも払うと、他人が OpenClaw をセットアップできるよう手伝うサービスを提供しています。なので、もしみなさんがそれをもっと大衆化して、もっと始めやすくできたら、それは大きなブレークスルーになります。みなさんは確かに正しい方向に進んでいます。
従来の職業的な昇進の階段はもう適用できない
**司会者 Peter：**あなたたちが以前「今は多くのチームで PM がそんなに要らない」みたいなことを言っていましたよね？
Romain：
私は、これらのツールでいちばん驚くのは、PM が必要か不要か、という問題だけではないという点です。**ほとんどすべての従来の職業的な昇進の“階段”が、曖昧になってきています。**以前は役割分担がはっきりしていました。デザイナーは設計、エンジニアは開発、PM はマネジメント、そしておそらく“黄金比”みたいな特定の比率がある……みたいな感じでした。
でも今は、たとえばあなたがエンジニアなら、生産性が明確に上がる。デザイナーなら、これらのツールを使って超能力を手に入れて、より技術的になります。PM なら以前は戦略ドキュメントを書くくらいだったのに、今は直接プロトタイプできます。だからといって、何十億人ものユーザーに対して責任を負う必要がある、というわけではありません。しかし実際に何かを作ることはできるし、チームに対して自分のビジョンを示すこともできます。
だから、私をいちばん魅了するのは、いま職業の階梯の間の境界があいまいになっていることです。私たちは誰もが実は“構築者（builder）”で、みんなで協力して構築を完成させます。
Alex：
私はどこかネットで「スタートアップに PM がいて、エンジニアが 20 人くらい未満なら危険信号かもしれない」みたいなことを言った記憶があります。あなたが言った通りで、**こうしたすべての役割が徐々に融合してきています。**デザイナーはもっとエンジニアリング寄りのことができるようになり、エンジニアはデザインに手を伸ばせるし、PM も構築に参加できる。でもエンジニアは通常コードを書くことに集中する必要があるので、昔はタスクの選別や他の PM 的なプロジェクトマネジメント部分は扱いませんでした。
でも今は、それがとても簡単になりました。たとえば Codex のような agent に、フィードバックや優先順位の分析を任せられる。そうすればエンジニアは、自分の仕事にもっと集中する時間を確保できます。いまは、誰もが他の人の仕事もできるようになってきていると思います。
Scott Belsky が提案したアイデアに、**“人材スタックの坍縮（collapse the talent stack）”**というものがあります。私はこの見方が好きで、本当にそれが起きていると思います。部屋に必要な人が少なければ少ないほど物事は進みやすくなり、意思決定もより明確になります。
**では問題は：PM はまだ何ができるの？**私は多くの PM が実際に転職を考えるべきだと思います。たとえばもしあなたが PM で、ずっとエンジニアになりたいと思っているけど、管理するほうが得意でエンジニアリング能力が高くないなら、今はエンジニアリングマネージャー (engineering manager) になるのが良いかもしれません。インテリジェントエージェントがあることで、あなたにとってより明確な役割になる可能性がある。別の例として、PM の一部はデザイナーになるほうが向いているかもしれません。実装に近い仕事です。
最終的には個人の興味次第だと思います。私にとっては、興味と自律性は AGI 時代における人類の最も中核的で最も重要な資質だからです。だから、あなたがコードを書くことにより強い関心があって、これまで PM の仕事を誰かがやる必要があったからこの役割にいた、というだけなら、今は完全にエンジニアに転向して、エンジニアリングの観点から同じことを続けることができます。デザインの領域でも同じです。
ただ、もし本当に関心があるのがユーザーとの対話だという場合——それが、実際の構築作業から離れることになったとしても。たとえばユーザーのニーズを理解したり、市場のトレンドを読み解いたりするようなことです——十分に大きいチームであれば、PM にはまだ活躍の余地があります。
Romain：
もう 1 点付け加えると、**私はどんな問題領域にも人間が責任を持つ必要があると思っていますが、その“人”が必ず PM である必要はないとも思います。**それはかなりプロダクトの性質次第です。
私たちはここでとても幸運です。私たちは Codex のために働いている。つまり開発者向けのツールであり、私たち自身が最良のユーザーなんです。そしてオープンソースだから、コミュニティと直接やり取りして共同開発もできます。
でも、もし 10 年前に戻ってみると——たとえば私が Stripe で働いていたとき、会社は 250 人だったのに PM が 1 人もいなかったし、AI ツールすらありませんでした。なぜ？Stripe は API 製品で、私たちは全員エンジニアであり、「優れた API とは何か」を直感的に理解できていたからです。あのとき私たちが構築していたのは、私たちの夢の API——たった数行のコードで実現できるような、エレガントな解決策でした。
でももしあなたが別の領域にいるなら、たとえばユーザーのニーズがエンジニアの直感とあまり一致しない場合、顧客と会話し、彼らのニーズを理解するために、より多くの PM が必要になります。**特に、あなたが提供する業界や領域がエンジニアの直感と完全には一致しないとき、PM の役割はさらに重要になります。**ただ、Codex チームでは私たちは非常に幸運です。私たちが作っているのは、私たち自身も使いたいと思うツールだからです。
Alex：
そういう環境では、**PM の役割は単にラベルでしかなくなり得る。つまりユーザーにいちばん関心があり、ユーザーのニーズを最も気にしている人、**それがたまたま非常にユーザーに近いエンジニアであってもいい。だから、こうした職能ラベルは、徐々に従来の意味を失ってきています。少し混乱はありますが、それは悪いことではないと思います。
司会者 Peter：
私も自分のチームでも同様の発見をしています。最も良いエンジニアは、私に「次は何を作るべきですか？」とは聞きません。彼らが主体的にユーザーと話し、必要なものを自分で明らかにして、それから私と相談する。そうすることで、みんなの目標がかなり一致するんです。
Romain：
それが、まさに私たち Codex チームの仕事の仕方です。今日 Codex app で使われている多くの機能は、実際にはエンジニアたちがボトムアップで提案した、素晴らしいアイデアから来ています。彼ら自身がそれを必要としていたからです。
Alex：
ただ、私が特に一緒に仕事をしやすいのは、あるタイプのエンジニアです。**彼らはユーザーと話すのが好きで、どんな機能を作るべきかを考えるのが好き。**そういう人たちは、システムを組む面でも非常に優れていて、速いし、能力も高いし、思考もクリアです。でも一方で、ユーザーとのやり取りにまったく興味がなくて、ただシステム構築に集中したいだけのエンジニアもいる。そういう人にも大きな成長の余地があると思います。
繰り返しますが、これが私の AI 時代の見方です——**私たちは、より“自分らしく”できる。**AI とチームが、あなたがやりたくないことを肩代わりしてくれるので、あなたの興味や強みに集中できるようになります。
司会者 Peter：
私もそう思います。“ビルダー（builder）”というタグはとても重要だと感じます。多くの PM はリーダーになりたいと思っているけれど、従来の職能の昇進の階段だと、VP などの役職になった瞬間に、逆に構築する時間がなくなってしまいます。毎日プロダクトレビューの中でフィードバックをするだけで、実際に開発する時間がない。そういう PM は多くないように思いますし、そうはなりたくない。私はユーザーに近いところにずっといて、本当にプロダクトをリリースしたい。
Alex：
完全に同意です。私は実際、PM はリーダー役だとは思っていません。むしろ“穴埋めの役割”として捉えています。ときには、その役割がある程度のリーダーシップを要求されることはあります。けれど、それでもリーダーシップの役割は、誰か 1 人の天才的なソリューションに頼ることではなく、チームが合意に達するのを助けることが中心です。
確かなことが 1 つあります。OpenAI では、最も優秀な PM は具体的な細部まで深く入り込みます。そして高いリーダー職として OpenAI に加わるのはかなり難しいことだとも思います。ここでは文化として細部への注意が依然として強く重視されているからです。だから最善のやり方は、最初から細部に深く入ることです。
Codex チームの採用で重視することは何？（答えはあなたの履歴書ではない）
**司会者 Peter：**Codex チームを採用するとき、候補者が Codex のヘビーユーザーであること以外に、どんな資質を重視しますか？
Alex：
前に言いましたが、私は**候補者の“自律性 (agency)”**をとても重視しています。私たちは、積極的に動ける人を探しています。これは最重要な資質の 1 つだと思います。
OpenAI、特に Codex チームの文化は、「入社したら、12 個の段階的に難しくなるタスクを順番にやるんだよ」といったタイプではありません。私たちのスタイルはもっとこうです。「ようこそ！さあ、探索を始めて。」
だから私たちは、自走できる人を探しがちです。行動力があり、自分なりの考えがあり、自分が何をやりたいのかを理解していて、既存のアイデアに挑むことを恐れない人。正直言って、いくつかの既存アイデアはそもそも間違っているかもしれない。最初はたまたまの判断で決めてしまっただけかもしれないからです。
私が理想とする同僚は、追加の責任を進んで引き受けられる人、しかも未知の領域を任されてもいいと思える人です。そういう資質を特に重視します。具体的なスキルに関しては、私たちは通常、技術力が高く、エンジニアリングに関連する候補者を優先します。
Romain：
同意します。私の開発者エクスペリエンス (DevX) チームでも、私は通常高い自律性を持つ人を探しています。技術的に非常に強くて、特に Codex みたいなツールを使うときに非常にうまくやれる必要がある。それに加えて、開発者やビルダー (builders) と一緒に働き、知識を共有することに強い情熱を持っている人を特に重視しています。
たとえば今週、Thomas が私のチームに加わると発表したところです。彼はオープンソースの Codex monitor を開発した人です。彼はとても創造的で、Codex のヘビーユーザーでもあり、そして Codex を使ってツールをどう作っているか、その経験を熱心に共有してくれます。
私たちがそういう人材を必要としているのは、何百万もの開発者を Codex が示す明るい未来へ導くために取り組んでいるからです。私は、agentic coding（エージェントによるコーディング）が、ソフトウェア開発、アプリ、プロダクト構築に対する従来の考え方を根本から変えている最中だと信じています。私たちの目標は、世界中の人にこの可能性を見せて、開発者がこのツールを活用して自分の創意を実現する方法を学べるようにすること。私が探しているのはまさにそういう資質です。
Alex：
補足すると、私の見立てでは DevX チームの理想的な候補者は、シンプルに言えば**「とても優秀なエンジニアで、しかもソーシャルメディアとコミュニティとのやり取りが得意」**と表現できます。
Romain：
その通りですね。ただもう 1 つ補足したいのは、候補者にはコミュニティに対する強い責任感が必要だということです。そして世界各地でソーシャルメディアの使われ方が違う点も考慮する必要があります。たとえば、ある地域では開発者は Twitter ではなく LinkedIn や別のプラットフォームをより好むかもしれない。だから定義を広げる必要があります。候補者は、世界規模でソーシャルメディアでうまく活動できる必要がある。私たちが特に重視するのは、コミュニティと関わるのが好きで、教えることや知識の共有に熱心な人です。
司会者 Peter：
実は、自律性は面接の前から見えてきます。たとえば、オンラインで作品を公開しているか？自分の side projects はあるのか？
Alex：
誰かが DM で「チームに入りたい」と言ってきたとき、私の最初の反応は「リンクある？」です。リンクがあれば、ほぼ必ず開いて確認します。私は、その人が本当に何かを構築しているのかを知りたくて、作品をチェックするんです。
もちろん、応募している背景を説明したカバーレターを添える人もいて、その上で履歴書を添付してくることもあります。でも私は、彼らの考え方や実際に構築しているもののほうが見たい。最近ふと気づいた面白いことがあります。私は本当に、彼らがどこの大学に行っていたのかを知らない。
**司会者 Peter：**誰が気にするんですか？誰が気にするんですか？本当にうれしいです。いまは、こうした愚かな学歴がそれほど重要ではなくなった時代に生きているから。あなたが実際に何を構築しているか、それを見せてもらえれば十分なんです。