アンドリュー・アンブロシーノが語る、CodexとChatGPTが統合される理由と、AIがプロダクト開発をひっくり返した理由

一方でアンブロシーノは、この変化から極端な結論を導き出すことには警鐘を鳴らす。PRDは死んでいないし、デザインプロセスが単純に消えたわけでもなく、職種をなくすのは誤りだと主張する。また、Codexが開発者向けツールから、あらゆる職種のOpenAI社員が使うものへとどう成長したのか、そしてそれがなぜCodexとChatGPTの統合につながったのかも説明している。

規模感を示すため、レニーは冒頭で次の数字を挙げている。Codexの利用は1月から6倍に伸び、週間アクティブユーザーは500万人を超え、エンジニアだけでなくほぼすべてのOpenAI社員が毎週使っている。アンブロシーノは、Codexを「これまでに存在した中で最高のデスクトップアプリ」にするという目標を公言している。人がブラウザのタブを反射的に開くように、次のタスクのためにアプリを開くことをためらわせないほど、品質の水準を高くしなければならないのだと説明する。

アンブロシーノによれば、いまプロダクトチームを率いるうえで最も難しいのは、プロセスが逆転してしまったことだという。OpenAIのものであれ他社のものであれ、現在のモデルを使えば、ゼロから始めた人でも望む機能を何でも立ち上げられると考えている。OpenAIでは全員が事実上無制限にトークンを使え、アンブロシーノいわく社員は非常に主体的でアイデアも豊富なので、誰もがあらゆるものを作っている。

従来のプロダクトプロセスは逆の発想で動いていた。ウォーターフォールから脱した後でさえ、プロセスは実装が高コストであることを前提としていた。デザインやプロトタイプは本物のコードより安上がりだったので、チームはドキュメント、リサーチ、プロトタイプを通じて、あらゆるリスクを事前に潰していた。その前提はもはや成り立たない。アンブロシーノの推測では、チームがどうしても必要としているある機能について、おそらく「90の互いに連携していない」取り組みがそれを実装し、試しているという。

アンブロシーノは、人々が根本的に違う仕事をしているわけではなく、スキルセットや職種が消えたわけでもないと強調する。変わったのは仕事の順序だ。実装が安くなると、コストがかかるのはキュレーションになる。90の試みのそれぞれの良い点は何か。どれを別のものに組み込むべきか。そのアイデアをどう位置づけるべきか。別の機能に属させるべきか。トグルのセグメントはいくつにすべきか。

レニーはこの変化を「かつては皆ドキュメントを書いていたが、今はプロトタイプを作る」とまとめる。アンブロシーノはこれに異を唱える。多くのプロダクトリーダーが「PRDは死んだ、これからはプロトタイプだ」と宣言するのを見てきたが、それを信じていないという。

その理由は、実装が安くなると、両方向に誘惑が生まれるからだ。エンジニア以外の人、とくにこれまでコードを書く時間も関心もなかった人は、いきなりプロトタイプに飛びついて「言いたいことを見せるよ」と言いたくなる。一方エンジニアは、アンブロシーノの見るところ、「読む価値のない」ドキュメントを大量に生み出したくなる。ドキュメントが悪いというわけではない。実装が潤沢なときこそ、伝えたいことに合った形式を選ばなければならない、というのが要点だ。曖昧な領域でプロダクトの方向性を明確にしたいなら、ドキュメントが最適かもしれない。あるインタラクションパターンを人々の手に渡して徹底的に試したいなら、プロトタイプのほうが良い。

レニーはこれを、以前のゲストが紹介した「プライマル・マーク」という概念に結びつける。アーティストが最初に描く一筆が、その後のすべてを形作るという考え方だ。早すぎるプロトタイプは、全員を間違ったアイデアに縛りつけかねない。アンブロシーノは同意したうえで、もう一つの問題を挙げる。かつての世界では、媒体そのものが、アイデアがプロセスのどの段階にあるかを示していた。本番アプリのように見えるものは後期段階のはずであり、つまり前提のリスクは潰され、デザインのレビューを経て、実際のビジネス目標に資するものだった。そうしたシグナルが存在したのは、構築のためのリソースがリスクを潰した後にしか与えられなかったからだ。いまやその結びつきは断たれている。探索段階のものが、リサーチの方向性やユーザーの望み、ビジネスの必要性について誤ったモデルを持ちながら、本番レベルに見えてしまうことがある。だからチームは、どんな形をとっていようと、それがどの段階にあるのかを明示しなければならない。

実際に優れたテイストとはどういうものかと問われ、アンブロシーノはLinearのプロダクト責任者による最近のツイートを引き合いに出す（誰の発言かについては確信がなかった）。そのツイートは、人々はテイストの美的な側面を過大視していると主張し、明らかに優れたテイストを持ちながらカーゴショーツを履いている人物の例としてポール・グレアムを挙げていた。

アンブロシーノにとって、テイストには以下のすべてが含まれる。

• 美学。 たとえば、あるインタラクションのアニメーションが「実際に伝えようとしていることに対してキビキビしすぎている」ために、その意味と合っていないことに気づくこと。本人は、おそらくこの点にこだわりすぎていると認めている。
• システム思考。 その部品がより大きなシステムにどう収まるか。
• 方向性。 プロダクトがどこへ向かっていて、その部品がどのテーマに属するか。
• 見せ方。 成果をどう位置づけ、どう伝えるか。

アンブロシーノは、本当のテイストの問題はもっと広いものだと考えている。何でも作れるとしたら、これは何であるべきか、目標は何か、そしてそこへどうたどり着くのか。何に取り組むべきか、それをどう見せるか、どの媒体を使うかを見極めることが、あらゆる分野で最も重要なスキルになりつつあるというのが彼らの見方だ。

レニーは、AIの出力が優れたデザインであることはまれで、「Claudeデザイン」や「Codexデザイン」は大抵一目で見分けがつくと指摘する。アンブロシーノは、自分はリサーチ部門の人間ではなく「怒られる」かもしれないと断ったうえで、実務的な理由と、より難しい理由を挙げる。

実務的な理由は次のとおりだ。第一に、デザインはコードより評価が難しい。コードはコンパイルできるか、やるべきことをしているかで確認できる。良いデザインとは何かをモデルに教えるループを作るには、フィードバックの仕組みの一部として人間のテイストが必要になり、それはより手間がかかり負担も大きい。第二に、研究所は歴史的に、AI研究を加速させる能力に投資してきた。コーディングモデルの初期には、正しいコードを書けることが研究のスピードアップにつながるのは明らかだった。デザインについて同じ主張をするのは難しい。アンブロシーノは、こうした実務的な障害は解消され、モデルは「かなりデザインが上手く」なると見込んでいる。

より難しい問題は、もっと捉えどころがない。一つは文化と新規性だ。アンブロシーノは、おそらく昨年のことだが、新しいウェブサイトがどれもLinearのサイトを真似しているように見えた時期を振り返る。モデルがLinearのようなサイトを生成すれば、一度は感心されただろうが、毎回Linearのサイトを出力するモデルは本当の課題を解決していない。ソフトウェアエンジニアリングでは、モデルに既知のパターンに頼ってほしいくらいだ。だがデザインでは、ランダムさと新規性が重要になる。

もう一つは、デザインとコードのあいだにある抽象化のレイヤーだ。初期のCodexアプリのコードの多くを書き、監督してきたアンブロシーノは、コードベースの中に存在するデザイン上の判断について説明する。ある隅にあるこの要素は、別の場所にあるあの要素とX、Y、Zを共有すべきだ、といったものだ。彼らが挙げる例は企業のリブランディングだ。表面的なやり方は、263個のコンポーネントを一つずつ更新することだ。本質的なやり方は、見た目は違っても、どちらも同じインタラクションパターンを伝えるリストであるもの同士が共有する意味を理解することだ。そのレイヤーは、現在の技術ではまだ手が届かないように感じるという。

レニーは、Codexアプリそのものが新しいパラダイムだったと付け加える。ターミナルでもIDEでもなく、コードを書き、そのコードを見せてくれるチャットインターフェースだ。こうしたものを発明することこそ、人間の創造性がまだ意味を持つ領域ではないか、とレニーは示唆する。アンブロシーノは「今のところは」と同意する。

レニーは、Claudeのデザインリードであるジェニー・ウェンがこのポッドキャストで「デザインプロセスは死んだ」と論じたことを持ち出す。アンブロシーノは、おそらく多くの点で意見が一致するだろうと言い、AI以前から形式的なデザインプロセスは好きではなかったと語る。スタートアップを経営し、デザイナーを採用していた頃に、「ケーススタディ工場」についての皮肉の効いた記事を読んだことを覚えているという。その記事は、デザイナーが成果よりもプロセスを重んじるよう訓練されていることを批判していた。リサーチ、発散、収束を経たものは、誰も気に入らず使われなくても、必ず良いものだという思い込みがあるというのだ。

アンブロシーノは、このプロセスは常に、実装が高コストで一度しか作れないため、先に問題と解決策の空間を徹底的に検討し尽くさなければならないという前提に立っていたと指摘する。FigmaやOrigamiのようなツールによって、チームはインタラクティブなプロトタイプを前倒しで作り、より早く知見を得られるようになった。それは本物の進歩だった。たとえ、プロトタイプを求めた経営陣がそれが動くものだと思い込む、というミームになったとしてもだ。いまや実装のすべてを、その初期段階に前倒しできる。その結果、ずれが生じている。人々は完全に磨き上げられたプロトタイプを見て「これ、もうリリースできる？」と聞く。実際にはそれはまだ初期段階の探索なのに、誰もそう言わないのだ。

だからアンブロシーノは、「デザインプロセスは死んだ」というのは正しくもあり、間違ってもいると言う。デザイナーは以前より多くのツールを手にしている。アイデアを実際のプロダクトに入れて、A/Bテストすることもできる。OpenAIを含む多くの企業が、いまやプロダクトの「ベビー」版を持っており、アンブロシーノはそれを「ベビーCodex」と呼ぶ。本番アプリのインタラクションを近似した、大幅に簡素化されたコードベースで、そのぶん素早くバイブコーディングできる。サイドバーがこう動いたらどうか、グループチャット付きのペインが開いたらどうか、といった具合だ。旧来のプロセスで日々使っていた特定のツールに執着しているなら、それは死んだのであり、うまくやっていけないだろうとアンブロシーノは言う。しかし、プロセスという全体の枠組み、つまり自分がその中のどこにいるかを把握し、それを明示することは、これまで以上に重要になっている。

デザインは自分の配下にあるのかと問われ、アンブロシーノは「週による」と冗談を言う。チームは一緒に席を並べ、緊密に働いている。Codex組織では、社内の他部門や経済全体と比べても職種の融合が進んでいるという。その理由として彼らは、Codexがエンジニア向けの技術的なプロダクトであることを挙げる。デザイナーは「エンジニアの言葉を話し」、プロダクトマネージャーはコードを書き、Codexのプロダクトリードであるアレクサンダー・エンビリコスはコンピュータサイエンスの修士号を持っている。アンブロシーノは、自分は持っていないと付け加える。

アンブロシーノによれば、各人を定義するのは職種間の垣根ではなく、むしろその人が仕事をしている領域の「平均」だという。デザイナーもコーディングやプロダクトの仕事を数多くこなすが、平均すると、その点の分布はデザインに集中している。プロセスはドッグフーディングによっても形作られている。チームは、たとえ最適なツールでなくても、できる限りアプリの中で作業しようとする。そうすることで、それが最適なツールになるようにするためだ。プロダクトの不足を肌で感じるために、あえて自分たちのプロセスを改善しないことも多い。アンブロシーノはこれを「非常に居心地の悪い状況」と呼ぶ。

レニーは、「メンバー・オブ・テクニカル・スタッフ」という肩書きは、誰もが単に「作り手」になる未来を示しているのかと尋ねる。アンブロシーノは、この肩書きの伝統は研究を中心とする企業に由来し、おそらくOpenAI以前から存在していると指摘する（ゼロックスの名を挙げる）。そのうえで、ある懸念を口にする。職種をなくすことは、各分野が既知のベストプラクティスを持つ専門領域であるという考え方そのものをなくしかねない。プロダクト職を廃止した企業の話を聞いたことがあり、それを「ひどい考え」だと言う。そうしたケースでは、本物のベストプラクティスと本物のプロセス、そして本物の失敗の歴史を持つ分野が、「ああ、自分もコードを書いたし」という考えから放棄されてしまう。

「それはあなたの担当ではない」という境界がなくなることは歓迎するものの、誰もが幅においても深さにおいても、あらゆることに取り組めるわけではないと彼らは主張する。だからこそマネージャーはいなくならない。また、エンジニアはしばしば、エンジニアリングはスキルだが他の職種は「ただ雰囲気でやっているだけ」だと思い込む過ちを犯しがちだとも言う。彼らの例えでは、Excelを使えるからといって、財務チームで働けるわけではない。

彼らの見方で変わりつつあるのは、職種を移ったり、ある職種のベストプラクティスを学んだりすることが容易になり、成果を出せるかどうかが特定のツールの習熟と結びつかなくなってきたことだ。アセンブリにも、TypeScriptの構文を暗記することにも興味がなかったため、自分はソフトウェアエンジニアになるべきではないと長い間感じていたという。そうしたツールに基づく門番的な排除こそが崩れつつある。それ以上のことについては、人々は誇張しすぎだと考えている。

Codexチームの規模を問われ、アンブロシーノはいつもの答えを返す。「10人から数千人のあいだのどこか」。これは本気だ。モデル研究、コンピュータ操作やブラウザ操作、モデルのパーソナリティ、フロントエンドのインフラなど、OpenAIのあらゆるものがこのプロダクトに注ぎ込まれている。とはいえ、数千人から好き勝手なPRを受け付けているわけではない。デスクトップチームには2桁のエンジニアがおり、デザイナーはその約半数、プロダクト担当は数人だ。共通する特性は主体性とテイストだ。多くは元創業者か、大企業で「創業者的な」仕事をしてきた人たちだ。OpenAIはチームが大きくなることを許容しており、メンバーの大半はICだ。

アンブロシーノとエンビリコスは、プロダクトマネージャーについて「ゾーンディフェンス」という例えを使う。2人のプロダクト担当があまりに近い領域で働いているとしたら、それは大抵悪い兆候だ。PMたちは力学モデルに基づくレイアウトのように散らばり、隙間を探す。あらゆる場所で混沌とアイデアが生まれ、1年がかりのトップダウン計画がもはや機能しない中では、テイストを持つ人がアイデアを着想からプロダクトのあるべき姿まで導く必要があり、そのためには領域全体をカバーしなければならない。また彼らはプロダクト志向のエンジニアを採用したいと考えている。押し寄せる大量のコードについて、プロダクトとしての一貫性を確かめるためにチーム全体でレビューする必要がないようにするためだ。

レニーは、いま最も価値のある人材とは、主体性とテイストを兼ね備え、アイデアを最初から最後まで導ける人だと表現する。アンブロシーノは同意し、それをICとマネジメントの関係に結びつける。マネジメントがなくなるわけではないが、いまや誰もが両方の役割を担っている。ICはもはやコードを一文字ずつ打ち込むのではない。エージェントと作業の流れを管理しているのであり、マネージャーはそれをより粗い粒度で行っている。自分の専門分野に精通していることに加えて、アンブロシーノが求めるのは、トークンが無制限で「スロップばかり作っているわけにはいかない」状況の中で、シグナルとノイズを見分けるテイストだ。

アンブロシーノは、計画のことで常に人々を苛立たせていると言い、チームは何も革命的なことはしていないと語る。期間が短いほど、計画は詳細になる。9か月先の計画も立てるが、その計画はぼんやりしたままだ。いま精度を加えても、それは見せかけの精度にすぎないからだ。リサーチではなく応用プロダクト側の立場から言えば、11月に立てた計画は12月までは持ったかもしれないが、「実際に起きたことではない」と彼らは指摘する。

計画に本当に必要なのは、どのモデル能力がどのくらいの時期に登場しそうかという見通しだ。前の会社で、チームがモデルの上に機能を作り始めたとき、通常のプロダクトプロセスは破綻した。代わりに、次の1〜2年でやりたいかもしれないことをすべて書き出し、そのすべてをプロトタイプにし、今すぐ使えるものを決め、残りは寝かせておき、モデルが飛躍するたびに各項目を試し直す、というやり方になった。機能がうまくいくかどうかは、機能の形ではなく、モデルが十分に賢いかどうかで決まった。

アンブロシーノが挙げる最もわかりやすい例はCodexアプリそのものだ。2月にリリースされたまったく同じアプリが、もし11月に完成していたら「完全に失敗していた」と「非常に強く確信している」という。彼らの見方では、その間の違いはモデルだけだった。まったく同じ形のプロダクトが、数か月の違いで完全に異なる結果になっていただろう。

ここから一つのパターンが生まれる。まだ機能しないものを作り、モデルが追いつくまで保持しておくことだ。アンブロシーノはチームがこれを頻繁に行っていると言うが、ここでもやはり、それがどの段階にあるかを明確にしなければならない。多くの人には、コードを書いたらそれはリリースされるもの、という習慣がまだ残っている。そうではなく、動くコードはいまや将来のモデルに対してテストできる成果物なのだと彼らは言う。

彼らの例はブラウザベースのエージェント機能だ。OpenAIはChatGPTでOperatorを提供し、次にAtlasブラウザの中でエージェントモードを提供し、そしていまCodexにアプリ内ブラウザを搭載している。アンブロシーノは、Operator、Atlas、Codex、ChatGPTを貫く「根本的には同じ機能」という一本の糸を見ている。異なる知能レベルで再リリースすると、結果はまったく変わる。だから彼らは、まだうまく動かないというだけで機能が悪いと結論づけないよう、人々に働きかけている。

逆の失敗は過剰な野心で、アンブロシーノはとくにリサーチ部門と結びつけて考えている。「突き詰めれば、モデルはこれをこなせる」という発想だ。彼らの例は、最初のCodexのリリースであるウェブ版のCodexだ。モデルにタスクを渡すと、モデルはどこかへ行き、完成した成果物を持って戻ってくる。形態はそれほど過激ではなかったが、モデルがタスクを十分にうまくこなせなかった。その後、Claude Codeが完全にローカルのツールとしてリリースされた。クラウドにはつながっておらず、ユーザーに質問し、人生のすべてを任せられるふりもしなかった。アンブロシーノによれば、それがモデルの現状に合っていたため、はるかにうまくいった。「私たちはその時点ではAGIに傾倒しすぎていた」と彼らは言う。かつては市場でのポジショニングが、プロダクトの形と伝え方を教えてくれた。いまは、同じものを形を変えずに6回リリースして、ようやくうまくいく、ということもありうる。

チームを野心的な方向に押し進めることについて、アンブロシーノは、プロダクトが存在するようになると、人は自然と細かな不満点を見つけて最適化するものであり、Twitterのユーザーもそれを指摘して手伝ってくれると言う。その仕事は重要だが、だからこそOpenAIはボトムアップの探索の文化も維持している。CodexアプリがいくつかのChatGPTの面を破壊したように、Codexアプリも将来の何らかの取り組みによって破壊されるだろうと彼らは考えている。一つのチームが、破壊的な仕事と品質の維持の両方を常にこなせるとは限らないので、プロセスはその両方を許容するものでなければならない。

フロンティアはどこにあるのかと問われ、アンブロシーノは「ループなんてもう先週の話」と冗談を言う。昨年の基準で言えば、プロダクトのコードは100%AIが書いているので、意味のある問いは、そのコードが監督下で書かれているか、監督なしで書かれているかだ。彼らは、ゴールポストが動き続けることを進歩の証として歓迎している。

チームは、自律的に開発されるソフトウェアや、夜間にコードベースのガベージコレクションを行う処理のような「ハーネスエンジニアリング」を探求してきた。彼らによれば、すべてのモデルに共通する問題は、複雑さを増やしがちなことだ。「どの会社のリサーチ部門でも、聞いていたら、どうかモデルをコードの削除が上手くなるようにしてほしい」。開発が自動操縦で進むとき、それはコードベースの側でも人間の側でも深刻な障害になる。どの機能要望を作るべきか、どれを無視すべきか、どれをまとめて位置づけし直すべきか、そして正しい抽象化をどう作るかを、どうモデルに教えるのか。どれも改善しつつあるが、Twitter、Slack、メールに耳を傾けて「アプリを改善する」ループを組むところまでは、まだ来ていないとアンブロシーノは言う。そこを目指してはいるという。いつかモデルに、市場で勝て、あるいは10億ドル稼げと指示するだけでよくなるのかと問われると、「絶対にない」とも「必ずそうなる」とも言わない立場だと答える。

アンブロシーノによれば、自身のCodexの使い方は、プロダクトの進化に沿って変わってきた。当初の目標は個人的なもので、Codexアプリを使ってCodexアプリを書けるくらい、アプリを良いものにすることだった。それが密なドッグフーディングのループを生んだ。できないことにぶつかり、それを直し、さらに多くのことをする。ローンチ後、人々はさまざまな種類の仕事に使い始め、アンブロシーノの仕事は採用とプロダクトディスカバリーへと移っていった。そこで、その仕事にもアプリを使い始めた。スプレッドシートのモデルを作ったり、ある領域での過去の取り組みについて社内でディープリサーチを走らせたり、全員が何に取り組んでいるかを追跡して、軌道を外れているものを修正したりしている。

5月頃の一連のリリースで、Codexにアプリ内ブラウザ、コンピュータ操作、アーティファクト作成が導入された。アンブロシーノはこれを「ほぼすべての人のためのCodex」リリースと呼び、初めてリリースを「バイブ調整」したと言う。やるべきことをすべて列挙したNotionドキュメントを用意し、プルリクエストやSlackチャンネルから最新情報を集めてステータストラッカーを更新する作業を自動化した。今では一般的なやり方だが、当時はリリース管理の最先端にいると感じていた。

今では、朝起きると、約3,000あるSlackチャンネルのうちどれに注意が必要かをまとめたデイリーブリーフが届いている。それに返信して、たとえば答えるべき質問を5つ挙げるよう頼むこともできる。セットアップはまだ手探りだ。どのチャンネルやトピックが重要か、注視すべきカテゴリー、そして文脈を記述したスケジュールタスクを作成した。最初の数回は軌道修正が必要で、指示を直接編集する代わりに、「このワークストリームの比重を下げて」とか「こういうことがあったのにブリーフに入っていなかった」といったことを伝えられた。アンブロシーノは、これがチャットボットの核心的な問題だと認める。自分はそれがプロダクトディスカバリーにあたるのでセットアップする時間があるが、OpenAIの外の人がそれを自力で解明しなければならないのはおかしい。レニーは、これによってCodexがOpenClawとよく似た動きをしていると指摘する。アンブロシーノは、たとえばアプリにSlackコネクタがなければ、アプリのほうから追加を提案してくれると言う。少なくとも、やり方をプロダクト自身に尋ねられるようにするのが最低限だからだ。ただし、それで十分だとは思っていないと付け加える。

レニーも一つ例を挙げる。彼はCodexで、迷惑な営業メールにラベルを付けるメールフィルタを作った。セットアップにはGoogle Cloudコンソールでの Pub/Sub の設定が必要で、レニーはそのインターフェースが苦痛だったので、Codexにやってもらうよう頼んだ。Codexは彼のコンピュータを操作し、クリックして設定を進めていった。アンブロシーノはモデルの態度をこうまとめる。「コネクタがなくても気にしないよ。とりあえずクリックし始めるから」。エージェントがいつコネクタを使い、いつアプリ内ブラウザ、Chrome拡張機能、コンピュータ操作を使うべきかは、多分に感覚で設計されているという。

彼らは、個人のワークフローがプロダクトにどうつながるかも語る。OpenAIでは誰もが異なる個人的な仕組みを作っており、共通のテーマが浮かび上がってくると、チームはそれを正式な機能にすることを検討する。メモリはその一例だ。OpenAIの内外を問わず、多くの人がエージェントのための「記憶の宮殿」としてObsidianのvaultやNotionのスペースを作っている。アンブロシーノは、人々がそんなことをする必要はなく、メモリ機能がそれを担うべきだと考えている。一方で、特定の人の仕事のやり方を反映していて、個人のものとして残すべきワークフローもある。どれをプリミティブにするかの判断は今も続いている。

レニーは、人々はChromeではなくCodexの中でSaaSアプリを使うようになるというダン・シッパーの予測を持ち出す。アンブロシーノによれば、シッパーは毎日Slackで要望を送ってくるという。彼らは、ブラウザ的な活動に対するOpenAIの試みを振り返る。Operator、ChatGPTのエージェントモード、Atlas、そして現在のアプリ内ブラウザ、さらにアプリとChromeをつなぐChrome拡張機能だ。

障害の中には、彼らの言葉を借りれば非常に地味なものもある。アプリは当初Electron上でローンチされたが、Electronのアプリ内ブラウザは「ちょっとお粗末」だったので、ブラウザは開発中のフロントエンドのテスト専用という位置づけだった。その後チームは、Atlasを支えていたOWLスタックに移行し、複数タブとエンタープライズ級のセキュリティが実現して、ユーザーが自分のサイトにログインできるようになった。未解決の問いは、ブラウザが何であるべきかだ。Playwrightの遅延なしに高速に動く、エージェント専用のものであって、ユーザー自身はChromeを使い続けるのか。それとも、自分自身のブラウジングも含めて、すべてをこのアプリでこなすのか。後者の道はあまり踏み固められておらず、キーボードショートカットのような面倒な問題も生じる。VS Code、Chrome、Linearのどれに合わせるべきか、それとも新しいものにすべきか。レニーは、このアプリが、何も作ったことのない人と、OpenClawのピーター・スタインバーガーのようなパワーユーザーの両方に対応しなければならないと指摘する。アンブロシーノは、ピーターをターミナルから引き離せるとは「確信していない」が、挑戦は続けると言う。

アンブロシーノは統合の背景を語る。CodexはCLIとして始まった。デスクトップアプリは、確信を持ちつつも多少の不確かさを抱えながら、開発者ツールとして作られた。IDEではなく、チャットボット以上の「ちょうどいいサイズの画面」で、コードを見ることはできても編集はできない、というものだ。公開ローンチ前の1月と2月、社内のドッグフーディングで、エンジニアリングとリサーチのワークフローについて明確なプロダクトマーケットフィットが見られた。チームは品質の水準を上げることに注力した。

すると、マーケティング、広報、財務、法務など、ほぼあらゆる部門の人々がCodexアプリを使い始めた。アンブロシーノいわく、アプリは「こうした人々に対して積極的に敵対的」だったにもかかわらずだ。コードを見せ、rg を実行する承認を求めてきたのだから。OpenAIはこれに応えて、ChatGPTデスクトップアプリやAtlasブラウザなど、そうしたユーザー向けの他の画面にもCodexを汎用的なナレッジワークのツールとして組み込んだ。そこで「最も厄介な問題」が起きた。誰も、自分たちのために作られたはずのアプリに移ろうとせず、Codexアプリから離れなかったのだ。

アンブロシーノがここから得た教訓は、「開発者ツールか、汎用的なナレッジワークツールか」は二者択一ではないということだ。人の職種がその人の仕事の平均であるのと同じように、プロダクトはユーザーが何をしているかから多くを推測できる。Excelの作業をしている人はgitリポジトリの情報を求めていない。プロダクトはシンプルに始まり、必要に応じて複雑になっていけばいい。入り口をわかりやすくするモードを設けることもありうる。チームは、深く縦に掘り下げる仕事に適した形をすでに手にしていると考えており、OpenAIの財務、科学、法務の各チームと緊密に連携している。適切な拡張性のプリミティブと汎用的なモデルが揃っていれば、それで何でもできると彼らは主張する。課題は汎用化だ。

アンブロシーノによれば、誰かがその結果を「スーパーアプリ」と呼んだが、そう呼んでほしくなかったという。おかげで一日中その言葉を聞かされているからだ。彼らはそれを拠点（ホームベース）と表現する。さまざまな画面にまたがってやるべきことをすべて把握する場所であり、一部の仕事はアプリの中で行われ、一部はアプリが開く他のアプリの中で行われる。たとえば、Codexにはスプレッドシートエディタが組み込まれているが、OpenAIの数十億ドル規模の資金調達を支える財務モデリングには、おそらく十分ではない。そこでアプリはデスクトップ版Excelのアドインと直接やり取りし、作業が終わればExcelを閉じればいい。すべてがその中で行われなければならない枠を描くのではなく、必要なあらゆるツールを使って仕事を始め、終え、自動化する拠点を持つことが狙いだと彼らは言う。

このモデルについてアンブロシーノが最も気に入っている例は、OpenAIの社内ビデオグラファーであるブレントの話だ。ブレントは、このインタビューと同じ部屋で撮影されたCodexアプリのローンチ動画を編集しなければならなかった。ブレントはそのすべてをCodexで編集し、それが、人々はこれを使って何をしているのかとチームが問い始めた初期の瞬間の一つになった。

ブレントは、Codexで動画編集ができるのかという好奇心から始めた。Codexには動画編集用のUIはない。CodexはブレントがPremiere Proを使っていることを理解し、プロジェクトの裏にあるファイルを変更することで一部の編集はできたが、すべてではなかった。そこでCodexは自分用のPremiere Pro拡張機能を作り、それをインストールし、その拡張機能に指示を送った。たとえば、Premiere内のマーカーを変更するよう依頼する、といった具合だ。アンブロシーノはこれを「かなりぶっ飛んでいる」と言う。

彼らにとってこれは、チームが同時に追求している正反対の2つのモデルのうちの1つを示している。1つ目のモデルでは、OpenAIがより良い動画エディタを作るのではなく、CodexとChatGPTが、コネクタやコンピュータ操作、あるいはこのような拡張機能さえ通じて、人々がすでに使っている専門ツールと連携する。2つ目のモデルは、ダン・シッパーのアイデアから来ているもので、ユーザーがCodexの中でウェブアプリを開き、Codexにそれを使ってより多くのことをさせる。レニーはこれを、もっと野心的になるべきもう一つの理由と受け止める。とにかく試してみて、モデルがやり方を見つけ出すかどうかを見ればいい。

収録後、番組のプロデューサーも、会話の間（ま）で映像を3つのセグメントに切り分けるといった簡単な作業にCodexを使って編集していると話した。アンブロシーノは、ほぼすべての新しい使い方はこうした話から始まると応じる。プロダクトはその仕事のために設計されているわけではないが、本質的にはコードを書ける白紙のチャットボットだ。何でもできるのだから、問題はそれが何の役に立つかだ。

「失敗コーナー」で、アンブロシーノは、キャリアの中で失敗していると感じていないのはおそらく今回が初めてだと語る。何年も、規制の厳しい分野で創業者として過ごし、それは絶え間ない苦闘のように感じられ、最終的には会社を「部品として」売却することになった。次のスタートアップでは、別の閉鎖的な業界向けにAIツールを作り、何度も挑戦したがうまくいかなかった。本人の数え方では、これ以前に「10年から15年のあいだのどこか」の期間、失敗し続けており、今うまくいっていることにまだ驚いているという。今でさえ、CodexとChatGPTを統合するプロジェクトでは数え切れないほどの小さな失敗があったと言う。チームがある形を提案してSlackに投稿すると、自分たちがいかに間違っているかについての2,000件のメッセージからなるスレッドが返ってくる。アンブロシーノは、その率直さこそが外向けのプロダクトが良いものになっている理由だと考えている。

ライトニングラウンドで、幼い子どもの親であるアンブロシーノは、The Gruffalo と The Big Orange Splot を薦める。後者では、同じ家が並ぶ通りに住む男が、自分の家にオレンジ色のペンキをこぼされ、家を完全に作り変えることにする。近所の人々は最初は反対するが、やがて一人また一人と自分の家を作り変えていく。レニーはこれを主体性についての本だと読み解く。アンブロシーノは、Codex以前の好きなソフトウェアプロダクトとしてLinearを挙げる。PM、デザイナー、エンジニアのうちどれが最も難しいかと問われると、順位をつけることを断る。デザイナー、PM、エンジニアのどれが「終わった」かという絶え間ない議論は大げさだと考えている。新たな流動性は、とくに主体性のある人にとっては新鮮だが、なくなるべきではないものもある。人は意味のある仕事を見つけ、それをどうやるかを考え出すべきだ。

最も率直なアドバイスは、正式な収録が終わった後に語られる。アンブロシーノは、どんなアドバイスをすればいいかわからないと言いつつ、一つ挙げるとすれば、自分の決まったプロセスに固執しないことだと言う。自分にしか出せない成果にこだわり、試すためにプロセスを変えること。Figmaのオートレイアウトを誰よりも理解していることは、AIもそれが上手くなっていくので、持続的な強みではないと彼らは指摘する。また、一つ注意書きも添える。これがすべての人にとってのあり方になると主張することには慎重だという。OpenAIの人々は次のことを見つけ出すことを自ら選んで集まっているが、ほとんどの人はアーリーアダプターにはならないし、常にすべてを学び直すのは本当に疲れる。アンブロシーノ自身は繰り返しが大嫌いで、毎日違うやり方で仕事をするのが大好きだ。だからこそ交渉ができない、と彼らは冗談を言う。他の仕事は何もしたくないのだから。