AGIへの最大のボトルネックは算力やモデルアーキテクチャではなく、意外にも人間の弱点である打鍵速度、怠惰、そして想像力の欠如だ。従来のIDEは周縁化され、AIへの計画レビューと自動化されたコードレビューが新しい中核スキルとなる。SaaSは死んでいないが、関係性と記録が新たな堀となる
OpenAI Codexのプロダクト責任者アレクサンダー・エンビリコス（Alexander Embiricos）の最新インタビュー
OpenAI内部の開発プロセスは根本的な転換を迎え、エンビリコス氏はOpenAIのエンジニアがもはやエディタを開かなくなったことを明かした。作業スタイルはAIとのペアプログラミングから完全にタスクの委任（Delegation）へと移行している。また、OpenAIの一見矛盾するビジネス戦略——agents.mdなどのオープンスタンダードを確立し、最先進モデルを直接の競合他社に提供することで、インテリジェンスの配分に関するはるかに大きなゲームをプレイしていること——が初めて明かされた。
以下、このインタビューの中で興味深いポイントのいくつかです。
1. AIはプログラミングを自動化するか？「Computer」という単語の語源に関する回答
イーロン・マスク氏が「プログラミングは大規模に自動化される最初の職業の一つになるだろう」という論断に同意するか尋ねられたとき、エンビリコス氏は肯定的に答えたが、歴史的な注釈を加えた。
「完全に同意します。プログラミングは大規模言語モデルが優れたパフォーマンスを発揮する最初の分野の1つですが、プログラミングが自動化されるということは一体何を意味するのでしょうか？」
彼の观点を説明するために、彼はプログラミング言語の進化の初期段階に戻るという思考実験を聴衆に提案した。「例えば、アセンブリ言語の記述をやめ、より高級な言語に移行したとき、私たちはプログラミングが自動化されたと言いましたか？いいえ、言いませんでした」と彼は指摘する。「私たちははるかに多くのコードを書けるようになり、その結果、コードへの需要が逆に爆発的に増加し、より多くのソフトウェアエンジニアを必要とするようになりました。」
彼はさらに、Computerという単語の起源を遡った。ドイツの「エニグマ」暗号機を解読したブレッチリー・パーク（Bletchley Park）では、当初のComputerは計算を行う人間のグループを指し、彼らは手動でパンチカードを作成し、機械を操作し、表計算を行っていた。同様に、最初の表計算ソフトの設計インスピレーションも、オフィスに従業員が格子状に座り、各自が自分の計算を行い、その結果を次の人に渡すという光景から来ている。
「これらすべての具体的なタスクは自動化されました」とエンビリコス氏は総括する。「しかし、そのような自動化が起きるたびに、最終的なアウトプットへの需要は爆発的な増加を迎えました。結果として、具体的なタスクの内容が変わっていても、実際にはそのような作業を行うためにより多くの人間が必要になるのです。」
これに基づき、彼は直感に反する予測を下した。「5年後には、エンジニアの数は現在よりも多くなると思います。」
2. タレントスタックの圧縮：エンジニア、デザイナー、そして（もう必要ないかもしれない）PMの未来
エンビリコス氏は、将来の変化は単にエンジニアの数の増減だけでなく、役割の統合と定義にあると考えている。
「私たちは時々言葉の意味を変えます。就像Computerという言葉が今では機械を指すように」と彼は言う。「今私たちはソフトウェアエンジニアという言葉を持っていますが、私は将来、より多くの『構築者（Builders）』が現れると確信しています。」
<彼が観察している核心的なトレンドは「タレントスタックの圧縮（Compression of the Talent Stack）」である。「過去には、バックエンドエンジニアやフロントエンドエンジニアなど、役割が明確に分かれたポストがたくさんありました。しかし今では、少なくとも私たちのCodexチームでは、そのようなケースはかなり減り、誰もがよりフルスタックな作業を行うようになっています。」
この圧縮は、将来のエンジニアが、デザイン、プロダクト思考、コーディング能力を兼ね備えたスーパー個人であるかもしれないことを意味する。「エンジニアと言うとき、あなたは以前の任何时候よりも万能な人間を想像しているかもしれません」とエンビリコス氏は説明する。
そして、彼自身が置かれているPM（プロダクトマネージャー）の役割については、彼は冗談めかして悲観的な見方を示した。「私はPMという役割が実際には明確に『定義されていない』ものだと考えています。あなたの目標は、チームやビジネスのあらゆるニーズに適応することです」と彼は告白する。優秀なプロダクトマネージャーはチームが一歩下がって将来のリスクを予見し、チーム最高のチアリーダーになり、品質の番人になることができる。しかし、私が刚才説明したこれらすべてのことは、強力なエンジニアリングリーダーやプロダクトを理解しているデザイナーでも完全に行うことができる。
3. AGIへの真のボトルネック：人間の怠惰と想像力
会話はより宏大的なテーマ、AGIのボトルネックへと移った。エンビリコス氏はある観点を投げかけた。「AGIへの重要なボトルネックはモデルの算力やアーキテクチャではなく、人間の打鍵速度と検証作業です。」
これを証明するために、彼は簡単なその場でのインタラクションを行った。「今日はAI を何回くらい使いますか？」と彼は尋ねた。30回以上という回答を得ると、彼はすぐに追撃した。「では、それがあなたにとってゼロコストだとしたら、AIは毎日どれくらいあなたを助けてくれると思うでしょうか？」
答えは明白だ：ほぼ無限回だ。AIは24時間体制であらゆること上で実行できる。「OpenAIの内外のエンジニアから、『私は常にCodexを実行させていて、会議中にそれが動いていないなら、時間を無駄にしている』と聞きます」とエンビリコス氏は共有する。「これは非常にクールですが、これらのエージェントを管理するには多くの精力が必要です。」
これこそが問題の核心だ。「私自身でさえ、すべてのこと上でAIを使うべきだとわかっていますが、私はあまりにも怠惰で、多くのプロンプトを入力するのが面倒ですし、私の創造力も限られており、AIがどのように私を助けてくれるかすべてを思いつくことはできません」と彼は言う。「AIは毎日私たちを数千回助けてくれるべきですが、AGIから利益を得るために、そのツールの使い方を学ぶためにそんなに多くの精力を費やすことを、大多数の人に期待すべきではないでしょう。それは毫不费力であるべきです。」
彼は、理想的な未来は、完璧なプロンプトを考え出すために頭を悩ませることなくAIを使えることであり、AIは能動的にあなたのコンテキストに接続し、適切なタイミングで助けを提供すべきだと考えている。
4. 個人のエンパワーメント vs 企業レベルの自動化
エンビリコス氏は、AIの普及を実現するための最良の経路は、トップダウンの企業レベルの自動化ではなく、個人向けのツールを構築することであると強調した。この観点は、特にデータセキュリティ、権限管理、現場の実装エンジニアへの依存といった、企業導入の現実的な問題に関する議論を直ちに引き起こした。
「もしあなたがある包括的なワークフロー自動化システムを一気に実現しようとするなら、必然的にこれらすべてのセキュリティとコンプライアンスの障害に対処しなければなりません」と彼は認める。「すべてのデータシステムを接続するために現場の実装エンジニアが必要です。しかし、私の観察では、私たちがトップダウンでこれらのことを行うと、最終的にはAIがその会社を助ける潜在能力を過小評価することになります。」
彼はデュアルトラック（並行）の戦略を提唱した。「あなたは企業レベルの展開を並行して進めることができますが、同時に、AIを実際に第一線で働いている人々の手に渡さなければなりません。」彼は一つの例を使って説明した。「あなたがカスタマーサービス担当者であり、AIがあなたの仕事のかなりの部分を自動化しているが、あなたはChatGPTについて聞いたこともなければ、使用することも許可されていないと想像してください。この場合、あなたはこのものについて何の直感も持ちません。逆に、会社の自動化ツールを使用しながら、個人的にも仕事の中で常にChatGPTを使用していれば、あなたはその動作原理についてより深い理解を持ち、よりコントロールしていると感じ、自動化の方向を導くことができるようになります。完全に制御不能な異星人の物体に感じられるのとは対照的です。」
彼はさらに、すべての企業ソフトウェアは最終的に個人ユーザーの操作インターフェースに集まると指摘した。「とにかく、すべては最終的にはあなたのローカルコンピュータ上で実行されているエージェントが対話できるインターフェース、例えばあなたのブラウザやファイルシステムに落ち着きます。」そして彼は重要な情報を明かした。「これがOpenAIが独自のブラウザ『Atlas』を構築している理由です。エンドツーエンドで厳密に制御することで、現場の実装エンジニアが完全な展開を完了する前に、エージェント方式で様々なシステムにアクセスできる途径として、企業に安全でインテリジェントなブラウジング体験を提供できます。」
5. エージェント開発の3つの段階
では、この人間のボトルネックをどう乗り越えるのか？エンビリコス氏は3段階の発展経路を提案した。
第1段階：ソフトウェアエンジニアリングの習熟。「まず、エージェントをソフトウェアエンジニアリングとコーディングの分野で優秀にさせることです。なぜならLLMはこれにちょうど得意だからです。」これは現在進行中の段階であり、エージェントの強固な基盤を築く。
第2段階：探索者（Explorers）のエンパワーメント。「次に、エージェントをより汎用的にするためには、コンピュータを使用することがその核心能力であり、コーディングはエージェントがコンピュータを使用する最良の方法であることを認識する必要があります」と彼は説明する。これは、エンジニアのために作られた柔軟なツールを、探索と修正（hacking）を望むあらゆる非コーダーに開放することを意味する。「私たちはすでにCodexアプリを使って様々な非コーディングタスクを処理している人々を見ています。」この段階の核心は、特定のワークフローのために製品を過度にカプセル化するのではなく、オープンなツールを提供し、初期のユーザーが创造的にその用途を発見できるようにすることだ。
第3段階：シームレスな製品化。「最後に、どの使用法が有効かがわかったら、あなたが言うような高度に製品化された体験を構築できます。」この段階では、AI機能は特定のシナリオ向けにカプセル化され、導入するだけで使える製品となり、一般ユーザーは学習コストをかけることなく直接利益を得ることができる。
「私は、私たちが今後数ヶ月以内に、非常に速い速度でこの第1、第2、第3段階の旅を完了するだろうと考えています」と彼は予測した。
6. GPT-5.2 CodexがOpenAIのすべてをどう変えたか
エンビリコス氏は、GPT-5.2 Codexのリリースが触媒となったOpenAI内部のワークフロー劇的な変化を詳細に記述した。
「GPT-5.2 Codexの前に、私たちが使用していたAIプログラミング機能は主にTabの自動補完、またはモデルとの『ペアプログラミング』のようなものでした」と彼は回想する。「そのモードでは、依然としてコンピュータの前に座り、手をキーボード上に置く必要があり、AIは単に小さなタスクを処理してくれるだけでした。」
しかし、昨年12月のGPT-5.2 Codexから、すべてが変わった。「私たちは突然、完全に新しいモードに切り替えました：タスク全体を直接それに委任できるようになったのです。私はそれと一緒に計画を立て、それが実行する仕様を確認し、そうすれば私はそれを自分で料理（Cooking）させるのです。」
この作業スタイルの転換は破壊的だ。「これは全く異なる作業スタイルです。だから私たちは先週リリースしたCodexアプリを開発しましたが、それはタスクを委任するための人間工学により適したユーザー体験を生み出すためでした。」
彼は社内データを提示した。「私の知っているほとんどの人は基本的にもはやエディタを開きません。圧倒的多数のコードはAIによって書かれています。人間は今、モジュール間のインターフェースを定義したり、AIと協力して計画を立てたりするだけかもしれませんが、コードそのものは、もはや人間によって書かれていません。」
7. IDEの終焉？
エンジニアが自らコードを書かなくなれば、従来の統合開発環境（IDE）の地位も危うくなる。
「もしあなたがIDEについて非常に強力なエディタを指すなら、私たちはCodexアプリに編集機能を意図的に組み込みませんでした。なぜなら、その使用方法を非常に明確にしたかったからです」とエンビリコス氏は説明する。新しい作業の重心はコードを編集することではなく、管理とレビューにある。
彼はますます重要になっている2つのスキルを強調した。
計画レビュー（Plan Review）：「委任モードでは、あなたが何をしたいかという仕様や計画が、以前の任何时候よりも重要になります」と彼は紹介する。Codexには現在際立った「計画モード」があり、エージェントはまず詳細な実行計画を提案し、ユーザーに重要な決定を確認するために質問する。これは新人が作業に取り掛かる前にチームに設計書を提出するようなものだ。
自動コードレビュー（Automated Code Review）：AIが大量の低品質なコード（いわゆる「AI Slop」）を生成する可能性に対処するために、OpenAI内部ではCodexに自身が生成したコードをレビューさせるという慣習が形成されている。「Codexはこの分野で非常に良くやっていて、私たちは意図的にモデルがコードレビューに得意になるように訓練しており、それは非常に高い信号対雑音比（S/N比）のフィードバックを提供できます。」現在、OpenAIでは、提出されるほぼすべてのコードがCodexによって自動的にレビューされている。
「興味深い現象として」と彼は付け加えた。「人々は時々、Codexにもう一つのモデルが生成したコードをレビューさせることで、私たちのモデルの強さを体験します。それを見た後、彼らは通常、『よし、私は直接Codexを使ってコードを書くべきだ』と思います。」これはClaude codeを皮肉っている。
<8. オープンな堀の構築：agents.mdのパラドックスと公開競争
今日、AIツールが雨後の筍のように出現し、ユーザーが簡単に切り替えられる時代、製品の「堀」をどう構築するのか？エンビリコス氏は、OpenAIが直感に反する戦略、つまり能動的にオープンネスを受け入れていることを認めた。
彼の説明では、現在のコーディングタスクは主にクローズドまたは断片的であり、これはユーザーが異なるツール間で簡単に切り替えられることを意味する。しかし、本当の粘着性は将来から来るだろう。「エージェントがSentryやGoogleドキュメントなどの他のシステムと対話し始めると、それらはより粘着性の高いものになります。なぜなら、企業にあるエージェントを信頼してこれらのシステムに接続することを許可することは、粘着性のある決定だからです。」
それでもなお、OpenAIのコア戦略はオープンなままだ。「私たちのCodexコアフレームワークはオープンソースであり、私たちはユーザーが他のツールに切り替えやすくするために常に努力しています」と彼は例を挙げた。OpenAIはエージェントへの指示を保管するためのagents.mdというファイル規約を作成した。「私たちはそれをcodex.mdと呼びませんでした。すべてのエージェントがそれを使用できるように希望したからです。現在、一人の古い知り合い（Claudeのこと）を除いて、ほぼすべてのエージェントがそれを採用しています。」
この戦略は従来のベンチャーキャピタルの論理では理解しにくい。「これは私というベンチャーキャピタリストには理解しにくいです」と司会者が割って入った。
「完全に理解できます」とエンビリコス氏は応じた。「OpenAIは非常に興味深く、並外れた職場です。私たちの観点からすると、私たちの仕事は『インテリジェンスの配分（Distribution of Intelligence）』です。」
彼はこの敵に塩を送る行為の背後にある論理を説明した。「私たちはこれらのモデルを訓練するためにすべての精力を注ぎ、そしてモデルを競合他社に提供します。なぜなら、私たちは非常に長期的なゲームをプレイしており、競争が激しくなれば私たちもそこから学ぶことができ、それは実際には私たちの助けになるからです。」
それでもなお、彼は自信に満ちている。「私たちには巨大な配分優位性（ChatGPT）、モデル能力の優位性、そして新しいモデルに対する優先使用权があります。私たちは勝利を目指していますが、同時により長期的なゲームもプレイしています。」
9. 仕事の重力センター（Gravity Center）は誰か？
エンビリコス氏は、将来の市場の状況は百花繚乱ではなく、少数の巨人が支配するようになると考えている。彼はDropboxで働いていたときの自身の経験を使い、「重力センター」に関する深い物語を語った。
「私はDropboxで働いていましたが、Slackが台頭する前に、ユーザーはDropbox内で直接ドキュメントにコメントすべきか、それともSlackでドキュメントについて議論すべきかについて考えていました」と彼は回想する。最適な観点からは、動画の特定のタイムスタンプ上やドキュメントの特定の段落の横にコメントする方が明らかに効率的だ。しかし、私たちが見たのは、Slackが人々の交流の絶対的な『重力センター』になったことです。誰もドキュメントにコメントしたがらず、私はただSlackであなたにしただけです。たとえ効率が低くても、巨大な重力がすべてのインタラクションをSlackに引き寄せました。
彼は、AIエージェントの分野でも同じ物語が起きると予測している。「私はある会社が12種類の異なるエージェントを必要とし、従業員がどれと話すべきかを把握するようになるとは思いません。そうなれば、彼らは決して使用習慣を形成できません」と彼は断言する。「将来、あなたがあらゆることについて話すことができるスーパー助理（Super Assistant）が現れるでしょう。それは仕事の重力センターとなり、人々はそれを中心にベストプラクティスを共有し、ハッカソンを開催するようになります。最終的には、市場にはそのようなプラットフォームが数つだけ残ることになるでしょう。」
<10. 投資家へのアドバイス：SaaSは死んでいないが、関係性と記録が新たな堀
「SaaSは死に、モデルレイヤーがすべてを飲み込む」という論調に対し、エンビリコス氏は自身のフレームワークを提示した。
「私の問いは：そのSaaS会社はエンドユーザーと関係を構築しているか？ もし答えがイエスなら、私はそれは消滅しないと思います」と彼はさらに付け加えた。「あるいは、そのSaaS会社はある極めて重要な記録システム（Record System）を掌握しているか？ それならそれはおそらく消滅しないでしょう。」
彼は、これら2つの場合において、SaaS会社の価値は以前よりも重要になっていると考えている。しかし彼は警告も発した。「逆に、もしそのSaaS会社が単なる接着剤の層で、ユーザー関係も持っておらず、コアとなる記録システムも掌握していないなら、私はそれについてより心配するでしょう。」
<彼はまた、AI時代には創業者に対する要件も変化していると指摘した。「過去には、良い製品を作りさえすれば投資を得ることができ、顧客、市場、あるいは配分戦略を無視できる時期がありました。私はそれは異常な時期だったと思います。現在、良い製品を構築することは相対的に容易になりました。あなたは原点に戻り、配分について深く考え、深厚な領域知識を持ち、特定の顧客のために何を構築すべきかを知っている創業者に投資しなければなりません。」
11. クイックQ&A
過去12ヶ月で、あなたが最も変化した考えは何ですか？
「私は私たちがマルチモーダル（動画、音声）を通じてAIと対話すると思っていました。私は完全に間違っていました。私は、コードに基づいてエージェントにコンピュータを操作させることこそが、現在の正しい経路であると気づきました。これは私がAIを一般人にもたらす方法についての考えを完全に変えました。」
Codexで最も困難なプロダクト決定は何でしたか？
「最も苦痛な決定は、Codex Cloudの無制限使用を取り消すことでした。延ばせば延ばすほど回収が難しくなることはわかっていましたが、当時は他のより市場性のある製品に集中していました。最終的に合理的な使用制限を設定した後、反对するユーザーはごくわずかでしたが、彼らの否定的な声はソーシャルメディア上で広く拡散しました。私が学んだ惨痛な教訓は：何を無期限で無料にしすぎてはいけないということです。」
5年後から今日を見ると、エンジニアリングまたはプロダクトの分野でどのような実践がばかげているように見えるでしょうか？
「第一に、手動でコードを編集すること。第二に、おそらくより論争的ですが、手動でデプロイと監視を管理することです。私は多くのスタートアップが、まったく新しい、完全にAIが管理する技術スタックの上に誕生するだろうと思います。将来、あなたが起業する方法は、まずエージェントを雇い、それに構築させ、その後で共同創業者をこのエージェントと協力するプラットフォームに加えることかもしれません。」
エージェントのガードレールは誰が提供すべきですか？
「両方が提供するでしょう。私たちは例えばコーディングエージェントのOSレベルのサンドボックスを気にかけている唯一の会社であり、Windowsのために構築したソリューションをオープンソース化するなど、ガードレールを構築するために多大な努力を注いでいます。しかし、私たちが提供するソリューションは万能ではなく、必ずサードパーティが特定の企業の要件のためにカスタマイズされたガードレールを提供するでしょう。」
参考：https://www.youtube.com/watch?v=S1rQngjpUdI
--end--