OpenAI Codex製品責任者：コードは人間が書かなくなるが、より多くの構築者が生まれる

すべての投稿を見る

2026年2月22日公開

OpenAI Codex 製品責任者：コードはもはや人間によって書かれるものではないが、私たちはより多くのビルダー（Builder）を持つことになる

Alexander Embiricos は OpenAI Codex の製品責任者である。OpenAI 入社前は Dropbox でプロダクトマネージャーを務め、その後協働ツール「Multi」（旧称 Remotion）を創業し、ペアプログラミング分野で5年間起業家として活動した。2024年に OpenAI に買収された彼は、AI プログラミングツールが「補助的な補完」から「全権委任」へと変化する過程を目撃してきた。Codex は 2025年8月以来20倍に成長し、2026年2月の1週間に macOS 独立アプリ、GPT-5.3 モデル、スーパーボウル広告を相次いで発表するとともに、無料ユーザーへの提供も開始した。

今回のインタビューでは、AI コーディングの現状とエンジニアの未来、なぜ人間が AGI（汎用人工知能）における真のボトルネックなのか、OpenAI 内部での Codex の活用方法、オープンスタンダードと競争戦略、そして SaaS 業界とエージェント市場の終着点といった核心的なトピックをカバーしている。

出典：20VC with Harry Stebbings、2026年2月21日

オリジナル動画：https://www.youtube.com/watch?v=S1rQngjpUdI

OpenAI 内部の多くの人々はもはや IDE（統合開発環境）を開かず、コードの大部分は AI によって書かれている。その転換点は GPT-5.2 Codex で訪れた。

AI は毎日人間を数万次支援すべきだが、現状では重度ユーザーでも数十回しか利用していない。ボトルネックはモデル自体ではなく、人間と機械のインタラクションにある。

「すべてのエージェント（Agent）は本質的にコーディングエージェントである」。なぜなら、コードこそがエージェントがコンピュータを操作するための最良の方法だからだ。

OpenAI は自社の役割を「Codex の成功」ではなく「知能の配布」と捉えている。モデルを訓練し、競合他社にも提供することだ。

汎用型エージェントは垂直特化型エージェントに勝り、将来的には少数のエージェントプロバイダーが大部分の価値を独占する可能性がある。

【1】コーディングは消滅しないが、その意味は変化する

イーロン・マスクは、コーディングが最初に大規模自動化される職業の一つだと述べている。最前線にいるあなたはこの見解に同意するか？

Embiricos は LLM（大規模言語モデル）がコーディング分野で確かに強力であることは認めるが、「自動化」という言葉は重すぎるという。彼はいくつかの歴史的な例を挙げた。私たちがアセンブリ言語から高級言語へ移行した際、誰も「コーディングが自動化された」とは言わなかった。むしろ、より多くのコードを書けるようになった結果、コードに対する需要が爆発的に増大し、ソフトウェアエンジニアの必要性が高まったのだ。

彼はまた「コンピューター（computer）」という言葉の起源にも言及した。ブレッチリー・パーク（第二次世界大戦中の英国暗号解読センター）では、多数の人々がパンチカードの作成や集計計算を担当していた。最初の電子表計算ソフトも同様のシナリオから生まれた：オフィスで机がグリッド状に並び、各人が一部を計算し、ワークシートを次の人に渡すという作業だった。これらの具体的なタスクはすべて自動化されたが、そのたびに産出物に対する需要が爆発的に増加した。

【注：Embiricos による「computer」の語源に関する記述は完全には正確ではない。「computer」という呼称はブレッチリー・パーク以前に人間職として存在しており、17世紀まで遡る。後に NASA の女性数学者計算員も computers と呼ばれた。】

「今日でもまだソフトウェアエンジニアは必要です。デザイナーも必要です。私は PM ですが、PM は必要だと思いますか？私は不要だと思います。」

五年後にはエンジニアが増えるのか減るのか？エンビロコスはより多くの“ビルダー”がいると語る一方で、一つの傾向を指摘しています。それは人材のスタックが圧縮されているという点です。数年前まではフロントエンドとバックエンドは別々の職種でしたが、現在では少なくとも Codex チーム内において、エンジニアはますますフルスタック化しています。

PM に関するこの自嘲的な見解について、彼は PM の役割の本質を「明示的に未定義のもの」と説明します。その目的はチームやビジネスのあらゆるニーズに適応することです。しかし、これらの機能は製品を考えるエンジニアリーダーやデザイナーが担うことも可能です。つまり PM は有用ですが、チームが大きくなる前までは、それほど多く必要ではないということです。

【2】AI のボトルネックは人間のタイピング速度であり、モデルそのものではない

「人間のタイピング速度と検証作業が AGI における重要なボトルネックである」とおっしゃいましたが、詳しく説明いただけますか？

エンビロコスは直接答えず、逆に質問を投げかけました。まずハリーに AI を1日に何回使っているかを尋ね、答えは30回以上でした。次に、もし無料で無制限に使えた場合、AI は1日に何回あなたを助けてくれるかと問いました。答えは無限です。

「私は AI が1日に数万人もの回数で私たちを支援すべきだと考えています。」

彼は OpenAI 内部では、エンジニアたちがすでに「Codex を常時起動しており、会議中にタスクを実行していないと時間を無駄にしたと感じる」状態に至っていると語ります。しかし、これらのエージェント（Agent）を管理し、常に稼働させ続けること自体が膨大な作業となります。

また、彼自身のように毎日これに取り組んでいる人でさえも、「AI がどのように役立つかをすべて考え出すにはあまりにも怠惰である」と述べ、結果として1日の利用回数は一般人と大差ないといいます。彼は AI で新しいことをしたとき（例えば今回のポッドキャストの準備など）、少し誇らしさを感じることもあるそうです。

では理想的な未来とはどのようなものか？プロンプトの書き方を学ぶ必要も、AI がどこで役立つかを自ら発見する必要もなく、AI が自動的に文脈に接続し、適切なタイミングで介入するものです。

ハリーはさらに追及します。「それなら、これらのプロンプトや人間の動作を製品化（productize）してボトルネックを取り除くことが、貴社の仕事なのでしょうか？」

エンビロコスは「そうだが、すぐにできるわけではない」と答えました。そして3段階のロードマップを示しました。

第一段階では、LLM が恰好に得意とするソフトウェアエンジニアリングとコーディングの分野でエージェントをまず確立することです。

第二段階では、エージェントがより広範に有用になるためにはコンピュータを操作できなければならないことに気づき、コードこそがエージェントがコンピュータを操作する最良の方法であると認識します。

「すべてのエージェントは本質的にコーディングエージェントです。なぜならコードはエージェントがコンピュータを使用するための最良の手段だからです。」

第三段階では、何が有効かを観察した上で、高度に製品化された機能を実装します。彼は「今後数ヶ月のうちにこの3つの段階を急速に完了させる」と語りました。

彼は特に Claude Code が最初にリリースされた際に行った正しい取り組みについて言及しました。それはターミナル内で超シンプルなツールを提供し、ユーザー自身がさまざまな使用場面を探求できるようにした点です。OpenAI もまた、特定の業界向けのカスタマイズ製品よりも、このようなオープンなツールの優先開発をすべきだと考えています。

ハリーは矛盾を指摘しました。もし垂直製品ではなくオープンツールを作るなら、責任をユーザーに押し付けることにならないでしょうか？これはまさに「人間がボトルネックである」という原点に戻ることになります。エンビロコスはこれが確かにボトルネックであると認め、そのため3段階の設計は段階的に参入障壁を下げるものだと説明しました。

【注：Claude Code は Anthropic が 2025 年 2 月にリリースしたコマンドライン AI プログラミングツールで、開発者コミュニティの間ですぐに人気となりました。また、彼は Claude の製品化が優れている点にも言及しています。例えば「Claude for Legal」や「Claude in Excel」などは Anthropic が展開する垂直分野向けアプリケーションであり、特定の業界のユーザーがプロンプトを書かなくても AI を利用できるようにしたものです。】

【3】まずはツールを、その後に自動化——企業における AI 導入の道筋を巡る議論

企業での AI 導入におけるデータセキュリティや権限設定の問題は難しいですが、実施エンジニアは不要なのでしょうか？

エンビロコスは、ゼロから一へと完全なワークフロー自動化システムを導入する場合、セキュリティコンプライアンスと各種データシステムをつなぐために実施エンジニアが必要であることは認めました。しかし彼の核心的な見解は、「トップダウンでの導入では、その企業における AI の可能性を深刻に過小評価する結果になりがちだ」という点です。

彼は比喩を用いて説明しました。あなたがカスタマーサポートの担当者だと想像してください。AI があなたの仕事の大部分を自動化しているのに、あなたは ChatGPT を一度も使ったことがない場合、あなたにとって AI に対する直感は全くなく、自動化に対して無力感しか感じないでしょう。しかし、もし同時に日常業務で ChatGPT を利用していれば、AI の能力を理解し、よりコントロール感を持てるようになります。

ではデータセキュリティの問題はどうなるのでしょうか？彼は、各ツールや各ワークフローは最終的に特定の従業員のブラウザまたはローカルファイルシステムに収束すると指摘しました。だからこそ OpenAI は Atlas ブラウザを構築しているのです。

【注：ChatGPT Atlas は OpenAI が 2025 年 10 月にリリースしたブラウザで、Chromium をベースに構築され、ChatGPT の機能が内蔵されています。ユーザーが閲覧中のウェブページの内容を理解でき、Agent モードによりブラウザ内で直接タスクを実行することも可能です。】

自社製のブラウザを構築しエンドツーエンドで制御することで、OpenAI は企業向けに安全な Agent によるブラウジング体験を提供できます。これにより、実施エンジニアがつながっていないシステムにも Agent がアクセスできるようになります。

「私にとって AI との最もエキサイティングな未来とは、誰もが自分自身をスーパーマンのように感じ、AI によって力を与えられていると感じる世界です。」

【4】ペアプログラミングから委任へ——OpenAI 内部における働き方の変革

OpenAI 内部では、コードのどの程度が Codex によって生成されているのでしょうか？

エンビロコスは具体的な割合は示しませんでしたが、自分が知る多くの人がもはやエディターを開かなくなったと述べています。

「コードそのものは、もう人間によって書かれていません。」

「コードの大部分は AI によって書かれており、現在ではおそらくほとんどの人が IDE（統合開発環境）さえ開いていないでしょう。」

この変化は段階的なものではなく、飛躍的なものです。転換点は2025年12月のGPT-5.2 Codexで訪れました。このモデルは、長時間の稼働、エンドツーエンドでのタスク処理、コンテキストの管理、そして指示への従順性において劇的な向上を遂げました。

【注：GPT-5.2 Codex は2025年12月にリリースされました。その後、2026年2月5日にOpenAIはGPT-5.3 Codexを発表し、「これまでで最も強力なエージェントコーディングモデル」と称しています。前世代よりも25%高速であり、自身を訓練およびデプロイするために使用された最初のモデルでもあります。】

GPT-5.2以前は、AIによるコーディング支援は主にタブ補完やペアプログラミングに限定されており、ユーザーはパソコンの前に座り、キーボードに手を置いたまま作業を行う必要がありました。しかしGPT-5.2以降、働き方は「エージェントと計画を議論し、仕様（spec）を確認した上で、『let it cook』（任せておけば勝手に進んでくれる状態）にする」というものへと変化しました。

これが彼らがCodex Appを開発した理由です。これは「ペアリングではなく委任」のために特別に設計されたインターフェースです。このアプリには、複数のエージェントを管理するツールや変更のレビュー機能、そして目立つ位置に配置されたSkills（オープンスタンダードに基づくエージェント能力拡張）が備わっていますが、意図的にテキスト編集機能は含まれていません。

【注：Codex App は2026年2月2日にmacOS版としてリリースされ、複数のエージェントによる並行作業をサポートしています。同じ週、OpenAIはスーパーボウルで広告を放映し（スローガン：「You can just build things」）、無料ユーザーおよびGoプランユーザーに対して一時的にCodex機能を開放しました。】

コードレビューについてEmbiricos氏は、計画段階でのレビュー（plan review）が以前にも増して重要になっていると述べています。CodexにはPlan Modeという機能が備わっており、エージェントはまず読み取り専用モードでコードベースを調査し、詳細な提案を作成した上で、実行に移す前にユーザーの同意を得る必要があります。これはまるで新入社員が作業を開始する前にチームにRFC（Request for Comments：征求意见稿）を提出するようなものです。

コードそのもののレビューについては、OpenAIのほぼすべてのコードがリポジトリへプッシュされる際にCodexによって自動的にレビューされるとのことです。Codexは低誤検出率を持つレビューヤーとして特別に訓練されており、その指摘のほとんどが価値あるものであるため、ユーザーはそのフィードバックを信頼できます。また彼は、誰かが他のモデルが生成したコードをCodexでレビューさせたところ、「むしろCodexを使って直接コードを書くべきだ」と気づいたというエピソードも紹介しています。

【5】オープンスタンダード——「Claudeを除くすべての企業がagents.mdを採用」

ユーザーは異なるコーディングツール間を容易に切り替えることができますが、これに対する粘着性（リテンション）についてはどうお考えですか？

Embiricos氏は、むしろ意図的にユーザーが簡単に切り替えられるようにしていると答えました。Codexのコアとなるハーンセス（実行フレームワーク）はオープンソースです。昨年Codexが初登場した際、彼らはagents.mdという規約を確立しました。これはあらゆるエージェントが読み取ることができる設定ファイルですが、あえてcodex.mdとは呼んでいません。先週、彼らはSkills（エージェントの能力拡張スクリプト）をagents/ディレクトリに格納するようさらに推進しました。

「全員が追随しました——あの常習犯を除いて。」彼は名指しはしませんでしたが、明らかにAnthropicのClaude Codeを指しています。同社は独自のCLAUDE.mdを使用しているからです。

【注：agents.md はクロスツール AI エージェント設定の標準規格です。OpenAI が agents.md（複数形）を、Amp/Sourcegraph が agent.md（単数形）をそれぞれ推出しました。その後、Quinn Slack がソーシャルメディア上で命名の統一を提案し、業界標準化が促進されました。2025 年末までに 6 万を超えるオープンソースプロジェクトで採用され、GitHub Copilot もサポートを発表しています。この規格は Linux 財団傘下の Agentic AI Foundation（エージェント型 AI 財団）によって管理されています。Claude Code は独自の CLAUDE.md 形式を使用します。】

しかし、彼はそのような容易に切り替え可能な状態は一時的なものであるとも指摘しました。現在のコーディングタスクは「エピソード式（episodic）」です：汎用的なエージェントファイルがあり、あらゆるエージェントがそれを読み取ることができます。エージェントがコードを記述し、パッチ（修正プログラム）を作成して git に投入します。タスクの両端はベンダーに依存しない中立の状態にあります。

一旦エージェントが外部システムと連携し始めると、例えば Sentry（エラー監視サービス）と対話したり Google Docs を操作したりする場合、粘着性は大幅に増加します。企業がエージェントに対してこれらのシステムへのアクセス権限を信頼させつつ、安全なサンドボックスと制御措置を確保することは、二度としたくない決断です。

Embiricos 氏は、まさにこの予測に基づいて Codex を構築したのだと話しました。Codex は最も保守的なサンドボックスメカニズムを採用し、OS レベルの制御によってエージェントが何を実行できるかを制限しています。

【6】「私たちの仕事は Codex の成功ではなく、知能の普及です」

ユーザーを Codex に留めさせ、Cursor や Claude Code へ流出させないためにはどうすればよいのでしょうか？

Harry は Hamilton Helmer 氏の『七つの力』のフレームワークを用いて競争優位性の構築について問いかけました。Embiricos 氏は OpenAI の使命は「安全に AGI（汎用人工知能）の恩恵を人類全体に届けること」であり、Codex チームの本質的な仕事は Codex そのものの成功ではなく、「知能の普及（インテリジェンス・ディストリビューション）」であると述べました。

「私たちはこれらのモデルを訓練するために莫大な努力を注ぎ込み、その後、それらのモデルを競合他社に提供しています。」

Harry は率直にこう言いました。「私のようなベンチャーキャピタリストにとっては理解しがたいことです。」

Embiricos 氏はこれは長期的なゲームであると説明しました。競合他社が強くなればなるほど、OpenAI も学習できます。たとえ競合他社がクローズドソース（暗に Anthropic を指す）であっても、その製品設計や創意工夫からインスピレーションを得ることができます。彼は例として、その朝まだ Twitter で Warp（ターミナルツール）の新機能をリツイートしたことを挙げました。そこには「エージェントがクラウドとローカルで同時に動作する」という素晴らしいアイデアが含まれていました。業界全体は「避けられないほど同じ結論に達している」のです。

では、Codex の真の強みとは何でしょうか？彼はいくつか挙げました：ChatGPT の圧倒的な配布優位性、自社製モデルが自社のハーンネス（実行環境）内で発揮する能力優位性（誰よりも先に新モデルを入手できる）、そしてモデルと製品の協調最適化です。

企業レベルで見ると、最も重要なのは計算上の優位性と最良のモデルであり、そのためには収益を生むビジネスを構築する必要があります。興味深いことに、Codex といった製品チームが逆にモデルの改善を加速させています。

製品レベルでは、個人ユーザーに好まれる製品を作ることが何よりも重要です。

また、企業側からの教訓も認めました。「私たちが来たので、自由に使いなさい」というだけでは不十分で、大量の教育、設定サポート、そして開発者体験責任者との連携が必要です。

Embiricos 氏は「非常に重要だ」と述べています。彼らが Cerebras と提携したのはまさに遅延問題を解決するためです。彼は提携に関する新しい発表がまもなくあることを示唆しています。

【注：2026 年 2 月 12 日、OpenAI は GPT-5.3-Codex-Spark をリリースしました。これは Cerebras との協力による最初の成果です。Spark は GPT-5.3 Codex の軽量版で、Cerebras の Wafer Scale Engine 3 チップ上で動作し、推論速度は 1 秒あたり 1000 トークンを超え、ほぼ即時のコーディングインタラクションの実現を目指しています。】

しかし、彼は推論が独占されることはないと考えています。競争圧力が多様なソリューションを生み出すでしょう。GPT-5.3 Codex そのものが前世代モデルよりもはるかに効率的です。また、API レベルでの最適化も行い、モデルの推論速度を 40% 向上させ、Codex のユーザー側では 25% の高速化を実現しました。

Harry は Jason Lemkin（SaaStr 創設者）の判断を引用しました。「AI 計算資源は新たな営業とマーケティングである」という言葉です。これは、過去には企業が顧客獲得のために販売チームを雇い広告を出費していたが、未来では AI 計算資源（inference、つまりモデルを実行する計算コスト）を購入し、ユーザーがすぐに製品価値を体験できるようにすることで自発的に変換されることを意味します。本質的には PLG（Product-Led Growth、製品主導成長）の AI バージョンであり、販売チームは不要になる可能性があります。

Embiricos 氏はこれにあまり同意していません。彼は「誰もが製品を構築できる世界では、市場での選択肢はさらに増えるだけで、顧客との良好な関係を維持し、彼らが本当に何を必要としているかを理解することは、以前よりも難しくなる」と述べています。営業とマーケティングが解決する正是この問題であり、代替されることはありません。

主な指標は週次アクティブユーザー（WAU）であり、収益ではありません。Harry は「Codex が実際に IDE を置き換えるのであれば、日次アクティブユーザーを見るべきではないか」と追及しました。Embiricos 氏はその場でこの批判を認め、「おっしゃる通りです。私たちは日次アクティブユーザーに焦点を移すべきかもしれません」と答えました。

彼の目標は、ユーザーの第一反応が「何かあればまず Agent に聞く」ことに変化することです。Google が情報に対して果たす役割や ChatGPT が知識に対して果たす役割と同様に、次の段階は「あらゆるタスクではまず Agent を探す」ことです。

昨年発表されたクラウドベースの Agent のアイデアは素晴らしかったものの、Agent 専用のクラウドコンピューターを与え、並列処理で複数のタスクを処理できる仕組みでしたが、「正直に言って、後からリリースされたバージョンの方が効果的でした」。2025 年 8 月の GPT-5 以降、彼らはインタラクティブなコーディングへと転換し、最も競争の激しい市場に進出しました。その結果、ユーザー数は 20 倍に増加しました。2025 年 12 月に GPT-5.2 Codex がリリースされ、再び転換点となりました。「12 月以来、さらに 2 倍になりました」。

そして 2026 年 2 月には集中的な爆発的成長が見られました。GPT-5.3 Codex がモデルの知能における優位性を確固たるものにし、Codex App のリリース（初週でダウンロード数 100 万超）がユーザー体験の弱点を解消し、スーパーボウルでの広告がブランド認知を広げ、無料ユーザーへの開放がカバー範囲を拡大しました。

「私たちの最大の批判者さえも転向しました」。

彼はまた、競合他社を皮肉るのを忘れませんでした。あるモデルは私たちより約 20 分早くリリースされましたが、「少し毒舌かもしれませんが、そのモデルはわずか 20 分の SOTA（state of the art、最先进水平）に過ぎませんでした」。

【注：2026 年 2 月 5 日に GPT-5.3 Codex がリリースされた際、Anthropic はほぼ同時に Claude Opus 4.6 を発表しました。2 月 8 日のスーパーボウル期間中、OpenAI と Anthropic はそれぞれ広告を放送し、OpenAI のスローガンは「You Can Just Build Things」でしたが、Anthropic は ChatGPT に広告が埋め込まれていると皮肉りました。両社はソーシャルメディア上で公然と対立しました。】

最も実現したいことは二つあります。第一に、クラウド製品への回帰です。以前、クラウドからローカルインタラクションへ移行したのはタイミングが悪かったためで、ユーザーがまだツールに慣れていない段階でいきなりワークフロー自動化を行っても、それは空中楼閣を築くようなものです。しかし現在ではユーザー基盤が確立されたので、クラウドとローカルの製品を密接に統合すべき時です。

第二は、コードレビューや品質管理といった「過小評価されているボトルネック」の解決により多くの精力を注ぐことです。コード生成はすでに「ほぼ取るに足らないもの」となりましたが、コードの質が優れているか、方向性が正しいかをどう判断するかこそが真の難題です。目標は、エージェント（Agent）に完全な反復能力を持たせることで、ユーザーフィードバックの収集と自己改善を行い、もはや人間のレビューを必要としないようにすることです。

【8】チャットは万能の入口だが、専門的な GUI との組み合わせが必要

チャットが AI の永続的なインターフェースとなるでしょうか？

Harry は a16z パートナーのアニシュ・アキャリヤ（Anish Akarya）の反対意見を引用しました。チャットインターフェースはサム・アルトマンやイーロン・マスクといった高効率な人々のために設計された産物ですが、地球上の大多数の人々は実際にはブラウザ型の、クリックして発見できるグラフィカルユーザーインターフェース（GUI）を望んでいるのです。

エンビロコスの回答は「はい、ただし二層で捉える必要があります」でした。彼は SF 映画が優れた未来予測器であると指摘しました。SF における AI は通常非常にシンプルで、自由に話せる実体であるだけで、「コーディング AI」から「販売 AI」へと切り替える必要はありません。SF が優れた予測器である理由はまさに物語を語る点にあり、シンプルなものが正しいことが多いからです。

したがって第一層は、チャットまたは音声による汎用入口です。何でも話し、あらゆるグループチャットに追加して、自分自身でどうやって支援するかを見つけさせることができます。

しかし第二層も同様に重要です。専門家はすべてのことを別の「人」との対話を通じて完了させたいとは思いません。彼は比喩を用いました——行政アシスタントがいるが、仕事をするには彼と会話するしかなく、ファイルを直接見たり自分で編集したりできない状況を想像してください。それは非常に煩わしく、時には文書を開いて直接修正したいという衝動に駆られるものです。

したがって将来のモデルは、チャットを汎用入口とし、特定分野向けの機能性 GUI を組み合わせるものになります。彼自身はポッドキャストの準備にはチャットを使いますが、コードについては Codex App を開いて深く掘り下げる必要があります。マーケティング担当者は製品に関する質問にはチャットを使いますが、広告データを確認するには専用の分析インターフェースを使用します——製品に関する質問をするために Codex App をダウンロードすることはありません。

また、興味深い発見にも言及しました。Codex を構築する過程で、彼らはエージェントにとって最も使いやすいインターフェースが、人間にとっても最も使いやすいものであることに気づいたのです。例えば、テストフレームワークはデフォルトですべてのテスト結果を出力しますが、人間は数千行の中から失敗した一つを見つけるのは苦痛です。AI も同様に苦しみます。しかし、失敗したテストのみを出力すれば、人間にもエージェントにもより良いことになります。これは、エージェントと人間の間の引き継ぎポイントで同じインターフェース設計を共有できることを意味します。

【9】エージェント市場の終焉——少数の汎用エージェントが勝つ

この市場は最終的に二頭独占になるのか、それとも三分天下になるのでしょうか？

Harry は投資家の視点からこの質問をしました。エージェント市場の終局は、Uber と Lyft のように二社で分け合う（Codex が大きなシェアを握る）ものなのか、AWS、Azure、Google Cloud のように三つ巴のものになるのかです。

エンビロコスは、最終的に少数のプロバイダーが大部分の価値を独占すると考えています。その論理は以下の通りです：

過去一年を振り返ると、多くの人がエージェントは複数の分野で PMF（Product Market Fit、製品市場適合）を見つけると考えていましたが、実際にはコーディングエージェントだけが実際に軌道に乗りました。カスタマーサポートなどの他の分野はまだ初期段階です。しかしこれは一時的なことで、将来のエージェントは何でもできるようになるでしょう。

その頃になったら、会社の中で 12 個のエージェントを配置して従業員に自分で適切なものを選ばせるようなことはしたくないでしょう。なぜなら、彼らはどのエージェントに対しても「熟練」状態には達しないからです。不慣れであれば、自動化を自らのワークフローに積極的に取り入れようとはしません。しかし、エージェントが一つだけあれば、オンボーディング（入社研修）は「何かあればそれへ相談するもの」となり、人々は筋肉記憶を形成し、それが仕事の中心となります。チーム間では使用テクニックの共有や、新しい使い方を模索するためのハッカソンが開催され、組織全体がそれを軸に回るようになります。

これは彼が Dropbox で見たものと全く同じです。Slack が台頭する前、Dropbox のドキュメント共同編集機能は実はより効率的でした——動画の正確なタイムスタンプにコメントを残したり、ドキュメントの特定の段落に注釈をつけたりできるからです。しかし人々はこぞって Slack へ流れ込みました。誰もドキュメントにコメントを書こうとはせず、みんなが Slack で直接 @ メンションしたいだけなのです。効率は低下しますが、引力効果は強くなります。エージェント市場も同じ物語を繰り返すでしょう。

彼は ChatGPT がこれを行うことに天然の優位性を持っていると考えています。すでに多くの人のための汎用 AI エントリーポイントとなっているからです。

【10】データ護城河はどこにあるか：プログラミングデータは十分、知識労働データの希少性

プログラミングデータの護城河は誰の手元にあるのでしょうか？Anthropic はすでにすべてのデータを手にしているのでしょうか？

この質問は Harry が LinkedIn で募集した読者からのものです。Harry は質問者の所属企業を「伏地魔」に例え、「『名前も言えない会社』の優秀な投資家」と表現し、続けて「サム（Sam）に私を殺させたくはない」と付け加えました。おそらく Anthropic の投資家が問うているのでしょう：「你们的编码数据护城河到底在不在？」（你们的编码数据护城河到底在不在？）

Embiricos の回答は非常に直接的でした。プログラミングデータはすでに十分であるというのです。「非常に優れたコーディングモデルを構築するのに十分なデータがある」と彼は述べ、これがボトルネックではないと強調しました。

本当に興味深いデータギャップは知識労働の分野にあります。なぜでしょうか？

コーディングには天然のデータ宝庫があるからです。GitHub には膨大な量のオープンソースコードがあり、どのようにコードを書き、どのように変更し、どのようにレビューするかというプロセスすべてが追跡可能です。しかし知識労働は全く異なります。誰かがメールへの対応方法や会議の準備方法、意思決定のプロセスを完全に記録してネット上に公開することはありません。こうしたデータはインターネット上にはほぼ存在せず、さらに知識労働タスクの分布はコーディングよりもはるかに複雑です。コーディングタスクは比較的標準化されていますが、知識労働は千人千面です。

このようなデータを入手する道筋にはイノベーションが必要です。Embiricos は二つのアプローチを提案しました。一つ目は、人々に報酬を支払ってタスクをシミュレーションさせ、その完全な操作軌跡を訓練データとして記録する方法です。二つ目は、運営を終了したが多くのワークフローデータを蓄積しているスタートアップ企業を買収するというものです。彼が挙げた例は「Slack 類の製品」で、これらの製品には実際のチームコラボレーションや意思決定コミュニケーションの記録が大量に保存されています。

Harry は外部データ会社（Turing、Invisible など）との提携によって投資が増大するかどうかを尋ねました。Embiricos は、彼らが目指しているのはできるだけ早く推進することだと答えました。小規模なチームにとって自社でデータ採集团隊を構築するのは時間がかかりすぎるため、大規模なデータ収集は通常外部企業と協力して行うのだと説明しました。

【11】SaaS は死なないが、「仲介業者」型企業には麻烦がある

大型 SaaS 企業の収益持続性はゼロであり、SaaS は死んだという主張があります。あなたはどう考えますか？

エンビロコスは、重要な問題は「この SaaS 企業が実際に何を持っているのか」だと述べています。

第一に、人間との関係性を保有しているか——ユーザーが離れられないのは、その企業と慣れ親しんでいるからでしょうか。

第二に、重要な記録システム（system of record）を保有しているか——企業の核心データがそこに保存されているかどうかです。

これらいずれかを満たしていれば、消滅することはなく、むしろ AI 時代においてこれらの要素は以前よりも重要になる可能性があります。

しかし、SaaS 企業が単なる「グルー・レイヤー（接着層）」に過ぎず、ユーザーとデータの間に挟まって接続や運搬のみを行い、顧客関係も核心データも保有していない場合、それは非常に危険です。这类企業は本質的に「仲介業者」であり、AI エージェントが得意とするシステム間の連携やデータ転送こそが、まさにこれらの企業の核となる機能を代替するものです。

ハリーはさらに具体的な推論を行いました：Sale