多くの人はいまだに「AIはプログラマーを置き換えるのか」と論争している。OpenAI内部からの答えはこうだ：AIはエンジニアを再層別化している。その差は徐々に広がるのではなく、ツールによって、プロセスによって、組織によって増幅され、最終的には挽回が難しい「複利」となる。
OpenAIでは、95％のエンジニアが毎日Codexを使っている。PRはまずAIの目を通り、それから人へと回る。コードレビューは1件あたり10〜15分から2〜3分に圧縮された。真にツールを受け入れた人々は、提出するPRの数が同僚より70％多く、その差はさらに広がり続けている。エンジニアの役割も変化している：ますます「テックリード＋ディスパッチャー」のようになり、10〜20の並列するCodexスレッドを同時に監視し、主な仕事は誘導、受入、フォローとなり、手でコードを書くのはむしろたまのこととなっている。
Sherwin WuはOpenAIのAPIおよび開発者プラットフォームのエンジニアリング責任者である。ほぼすべてのAIスタートアップがOpenAIのAPIを統合しているため、Sherwinはエコシステム全体で何が起きているか、そして将来の方向性について、極めてユニークで広い視点を持っている。
彼はポッドキャストでさらに一つの判断を示した：多くの企業が今日誇りとしているAIの「足場」――ベクトルデータベース、エージェントフレームワーク、複雑なプロセスオーケストレーション――は、単に過渡期の杖に過ぎないかもしれない。モデルの進化がそれらを飲み込むだろう。本当に勝ち残ったチームはすでに戦い方を変えている：モデルが到達する能力を事前に想定したワークフローを設計し、製品が現在80％しか使えなくてもリリースし、次世代モデルがアップグレードされた時に直接そのハードルを越える。
AIも全員を均等に引き上げることはない。高い主観的能動性を持つエンジニアを「不釣り合いな」高みに押し上げる：要件を分解でき、コンテキストを制御でき、複数のエージェントを調整でき、検証のクローズドループをしっかり作れる人は、かつての小さなチーム一人分の価値を生み出す。それに伴うのはいわゆる「一人ユニコーン」だけでなく、組織構造が書き換えを迫られるようなものだ：より小さなチーム、より速いイテレーション、より急な分化。
エンジニアリング以外では、Sherwinはビジネスプロセスオートメーションがさらに過小評価されている機会だと考えている：現実世界の仕事の大半は、繰り返し可能で、強い制約があり、標準的な作業プロセスで動いている。AIがこれらのプロセスに深く入り込むことで、効率だけでなく企業の運営方法そのものが変わる。
ここ2、3年の変化が早すぎて不安に感じるなら、それは正しい感覚だ。Sherwinの言葉はむしろ、私たちにこう警告している：これは実は長く続かない窓の時期なのだ。変化はいずれ緩やかになるが、この期間を逃すと、多くの人はこの「新しい層別化のルール」さえ学ぶ間もなく終わってしまうかもしれない。
このポッドキャストを翻訳した。
エージェント時代のエンジニアリングの層別化は、すでにOpenAIで現れている
司会者： Sherwin、ご出演ありがとうございます。今やAI進歩の「バロメーター」となっている問題から始めたい、特にエンジニアリング分野で。あなた自身はまだコードを書いていますか？もしそうなら、あなたとあなたのチームのコードのうち、どれくらいがAIによって書かれていますか？
Sherwin Wu： 今でも時々コードを書きます。正直言って、私のようなマネージャーにとっては、今はAIツールを使う方が手書きよりも簡単です。
私個人と、OpenAIの一部のエンジニアリングマネージャーにとって、私たちのコードは基本的にすべてCodexによって書かれたものです。よりマクロな視点で見ると、内部には非常に強く、非常に現実的なエネルギーがあります――みんながこれらのツールがどこまで進歩したか、Codexが私たちにとってどれだけ使いやすくなったかに感心しています。
「AIが書いたコードがどれだけあるか」を正確に測定するのは難しい、なぜなら圧倒的多数のコード――ほぼ100％に近いと言っていいでしょう――はほぼ最初にAIによって生成されるからです。
私たちが実際に追跡している指標は、ほとんどのエンジニアが毎日Codexを使っているということです。
95％のエンジニアが日常的にCodexを使っており、100％のPRが毎日Codexによってレビューされています。 つまり、最終的にマージされ、本番環境に入るコードはすべて、Codexが「目を通し」、PR段階で改善提案や潜在的な問題を指摘します。
しかし、これらの数字よりも私が興奮するのは、全体の雰囲気とエネルギーです。
もう一つ興味深い観察があります：Codexをもっと使うエンジニアは、明らかに多くのPRを開きます。 彼らが提出するPRの数は、Codexをあまり使わないエンジニアよりも70％多く、その差は広がっています。
PRを多く出す人々は、このツールをより効率的に使う方法を絶えず学んでおり、この70％の差は時間とともに広がり続けています。たぶん今は、私が最後に見た時よりこの数字は高くなっているでしょう。
司会者： 理解が正しいか確認したいのですが：OpenAIでは、その95％のエンジニアのコードは、基本的にAIがまず書き、それから彼らがレビューするということですか？
Sherwin Wu： はい、はい、その通りです。
司会者： クレイジーに聞こえるが、もうそれほどクレイジーではなくなっている、私たちは急速にこの状態に適応しつつある。もちろん、まだ少し時間がかかると思うけど。
Sherwin Wu： ええ、まだ適応中です。Codexへの信頼度が比較的低いエンジニアもいます。しかし、ほとんど毎日、誰かがそのやっていることに驚いたという話を聞きます。そして、モデルが「独立してどれだけのことをできるか」への信頼の閾値が、何度も引き上げられます。
Kevin Weil（私たちのサイエンス担当副社長）が好きな言葉があります。彼はよくこう言います：「これはモデルの生涯で最悪の瞬間だ」と。これはソフトウェア工学にも当てはまります：時間が経てば経つほど、人々は重要な仕事をモデルに任せることにますます積極的になり、モデル自体もただ強くなるだけです。
司会者： Kevin Weilは以前にもこの番組に出演し、その時もこの言葉を、しかも一度ならず繰り返していました。最近、OpenClaw（以前はClaudebot / Moltbot）の開発者Peterも、彼が仕事でCodexを大量に使っていると共有しました。彼によると、多くの場合、Codexが仕事を終えた後、彼は完全に信頼しており、直接masterブランチにマージしても結果は良いとさえ感じることがあるそうです。
Sherwin Wu： はい、彼は確かにCodexの非常に優れたユーザーです。彼は私たちのチームと非常に密接に連絡を取り、多くの良いフィードバックをくれているので、彼がそういう使い方をするのは全く驚きません。
司会者： この私たちがいる狂った瞬間、特にエンジニアにとって。私たちは「あなたがすべてのコードを手で書かなければならない」から「AIがあなたのすべてのコードを書く」へと移行した。私は他にどんな職業が、わずか数年でこれほど劇的で、完全に予想外の変化を経験したか想像できない。エンジニアの職業生活全体における「仕事内容」が、この2年間で完全に再形成された。では、今後1、2年で、ソフトウェアエンジニアという役割がどうなると想像する？この「仕事そのもの」は何になる？
Sherwin Wu： 正直、これを見るのは本当にクールです。この興奮の一部は、この職業が今後1、2年で、さらに非常に大きな変化を経験する可能性が高いということにあります。
しかし、今はまだ探っている段階です。多くのエンジニアにとって、これは非常に稀な窓の時期です――今後12〜24ヶ月で、私たちはほとんど手で標準を定義でき、「エンジニアがどうあるべきか」を定義できます。
現在、よく言われるトレンドの一つは：ICエンジニアが技術責任者になりつつあり、基本的にマネージャーのようだ。 彼らはエージェントの「艦隊」全体を管理しています。
私のチームの多くのエンジニアは、実際に10から20の並列スレッドを同時に引っ張っています。もちろん、10から20のCodexタスクが同時に走っているわけではありませんが、確かに大量の並行作業を処理しています：進捗を絶えず確認し、方向を調整し、エージェントやCodexにフィードバックを送る。彼らの仕事は、「コードを書く」ことから、ほとんど「管理」することに変わりました。
今後1、2年についての直感的なメタファーを与えるなら、私はよく大学時代に読んだプログラミング教科書――『Structure and Interpretation of Computer Programs』（SICP）を思い出します。この本はかつてMITで非常に人気があり、長年入門プログラミングの教科書として使われ、プログラマーの間でも一種の「カルト的な古典」です。Schemeを使ってプログラミングを教え、関数型の世界へと導き、読むと脳が開かれます。
しかし、本当に私の記憶に残っているのは、その冒頭にある「プログラミング」というものへの比喩です：ソフトウェア工学を一種の魔術として描いています。本では、ソフトウェアエンジニアは魔法使いのようであり、プログラミング言語は呪文のようだと説明しています――呪文を唱えると、それは解き放たれ、あなたに代わって仕事を成し遂げます。難しいのはそれを唱えられるかどうかではなく、どんな呪文を唱えるか、プログラムがあなたの望むように動くかです。SICPは1980年に書かれましたが、この比喩は今でも有効です。私はむしろ、それが今日の現実によって本当に「実現」されているとさえ感じます。
この観点から、vibe codingであれ将来のソフトウェア工学であれ、この進化の自然な延長線上にあるように思えます。プログラミング言語はそもそも呪文であり、呪文が進化し続け、私たちがコンピュータにしたいことをさせるのがますます簡単になっています。そしてこのAIの波は、おそらく次の駅です。それは「呪文」というものを極限まで押し進めます：あなたはほとんど直接CodexやCursorに何が欲しいかを伝えるだけで、それがあなたに代わって仕事をしてくれます。
私は特に「魔法使い」という比喩が好きです。なぜなら、現在の状態はますます『ファンタジア』の中の『魔法使いの弟子』のようになっているからです。魔法の帽子をかぶって魔法をかけ始めると、その力はとてつもなく強いが、前提は：自分が何をしているかをはっきり理解していることです。『魔法使いの弟子』では、ミッキーマウスがほうきに仕事をさせ、自分は寝てしまうと、ほうきがどんどん増え、洪水が制御不能になり、家が水浸しになります――これはほとんどvibe codingの極限形態です：願望があまりに早く実現し、制御不能もすぐに訪れます。
だから、エンジニアが20のCodexスレッドを同時に走らせているのを見るとき、私が考えるのは「気持ちいい」ことではなく、その背後には実際にスキル、経験、そして大量の判断力が必要だということです。完全に手放すこともできなければ、すべてが自動的に良くなるとふりをすることもできません。
しかし、そのレバレッジも確かに驚くほど高い。これらのツールを上手に使いこなせるベテランエンジニアは、今や過去には絶対に不可能だった仕事量をこなせます。これも魅力的な点です：私たちは本当に、自分が魔法使いのように魔法をかけているという具体的な感覚を持ち始め、ソフトウェアが私たちの代わりに走り、仕事をしてくれます。その「魔法感」は、かつてないほど現実に近づいています。
司会者： ここで2つの線でさらに追求したい。その一つは、最近ますます聞くフィードバックで、エージェントが期待通りに動かない時に、人は強いストレスを感じるということです。一度に大量のCodexエージェントを送り出して、それから絶えず監視しなければならない――「これが止まった」「あれが詰まった」、時間が無駄に浪費されているように感じる。あなた自身、そのような感覚はありますか？チームでもそういう状況を見ますか？
Sherwin： はい、あります、あります、そのような状況は常に起きています。正直言うと、私はむしろこれが今最も面白く、かつ重要なポイントだと思います。なぜなら、モデルは完璧ではなく、これらのツールも完璧ではなく、私たちは実際にまだ探っている段階です：CodexやこれらのAIエージェントとどのように協力すれば、本当に物事を成し遂げられるのか。この種の問題は内部でよく起こります。
私たちには、OpenAI内部で実験をしている非常に面白いチームがあります：彼らが保守しているのは100％ Codexによって書かれたコードベースです。通常であれば、AIにまず一版コードを書かせ、それから自分で一部を書き直し、チェックし、修正することがあるかもしれません。しかし、このチームは完全に「Codex化」されており、ほとんど徹底的にlean inしています。
注：Sherwin Wuが言及したこの実験は、OpenAIがブログで公開しています：https://openai.com/index/harness-engineering/。この記事は「手書きコードゼロ」のソフトウェア工学実験を記録しています：チームは5ヶ月で空のGitリポジトリからスタートし、実際に使える内部製品――デプロイ可能で、障害も起こし、修正され、数百人の内部ユーザー（毎日使うヘビーユーザーを含む）によって使われている製品を作りました。しかし、最初から最後まで人間による直接的なコード記述は一切ありませんでした：アプリケーションロジック、テスト、CI設定、ドキュメント、可観測性、内部ツール、すべてCodex（Codex CLI + GPT-5）によって生成されました。最終的にわずか3名のエンジニアの駆動で、約1500個のPRがマージされ、約100万行のコードが生成されました。彼らは全体の納品速度が伝統的な手書きの約1/10と推定しています。
そこで彼らはあなたが先ほど言ったような問題に遭遇します：例えば、ある機能を作りたいが、どうしてもエージェントに正しく作らせられない。通常この時、人間には「避難口」があります――「もういい、自分で袖をまくり上げよう」と言って、Codexを使わず、tab completeやCursorのようなツールを使って直接手書きに切り替えることができます。しかし、この実験チームにはこの出口がありません、これは実験デザインの一部です。
だから問題はこうなります：どうすればこのエージェントに仕事を正しくやらせられるのか？ 私たちが繰り返し見る現象の一つは――あなたも同様の感覚があるか分かりませんが、私たちの側では非常に明確です――多くの場合、コーディングエージェントがうまくいかないのは、「それができない」からではなく、コンテキストに問題があるからです。与えた情報が十分に明確でないか、エージェントがこの仕事を完成させるために必要な情報を全く得られていないかのどちらかです。
このことに気づくと、解決方法が変わります：もはや「プロンプトを調整する」のではなく、ドキュメントを補い、構造を補い、なんとかしてこの制限を回避し始めます。要するに、あなたの頭の中にある「暗黙知」「チームの共通認識」「デフォルトのやり方」を、なんとかしてコードベースにエンコードするのです――それはコードコメントかもしれないし、コード構造かもしれないし、あるいはいくつかのMarkdownドキュメント、skillsファイル、リポジトリ内の他の補助リソースかもしれません。目標は一つ：モデルがリポジトリ内でそのタスクを完了するために必要なすべての情報を読めるようにすることです。
このチームには他にも多くの収穫があり、それは話し合う価値があると思います。しかし、少なくとも一点はすでに明らかです：意図的に「AIを使わない退路」を取り除くことで、もし本当にエージェントを全面的に受け入れるなら、これらの問題は遅かれ早かれ解決しなければならない、ということを彼らに気づかせたのです。
エンジニアのPRへの注意力を100％から30％に下げる
司会者： 先ほど、AIを使う人がPRを狂ったように送り出し、PRの数が明らかに増えていると話しました。明らかに、コードレビューは今やさらに大きなチャレンジになるでしょう。あなたのチームは、code reviewもより速く、よりスケーラブルにする方法を何か模索していますか？みんなが「毎日そこに座ってPRをレビューする単純労働者」になるのではなく？
Sherwin Wu： はい。まず、今Codexが私たちの100％のPRをレビューします。
ここで特に面白いことが起きていると思います：私たちがまずモデルに任せるのは、往々にして最も煩わしく、最も退屈なソフトウェアエンジニアリングの部分です。そのため、今ではソフトウェアを書く方がむしろ面白いのです――私たちは本当に面白いことに、より多くの時間を費やせます。
私個人としては、以前はcode reviewが特に嫌いでした、本当に私の一番嫌いな仕事の一つでした。私が大学卒業後の最初の仕事はQuoraだったことを思い出します。当時、私はNewsfeedを担当していたので、Newsfeedのコードは基本的に私が「所有」し、私はNewsfeedの主要なレビュワーになりました。そのコードはシステム全体で最もコアな部分であり、ほぼすべての人が触れていました。
結果、毎朝ログインすると、20から30のcode reviewが目に入り、「ああ、これ全部通さなきゃ」と心が沈みました。私はよく先延ばしにし、保留中のPRが50個に増えることもありました。レビューの量が膨大だったのです。
Codexはcode reviewにおいて本当に強いです。私たちが観察している現象は：5.2（GPT-5.2のこの世代）は特にコードレビューが得意で、特に正しい方向に導けるときです。
だからここでは、PRの量は確かに増えていますが、CodexがまずすべてのPRに目を通すことで、code reviewが元の10〜15分のタスクから、多くの場合2〜3分で済むタスクになります。なぜなら、それは事前に多くの提案を「焼き込ん」でいるからです。
多くの場合、特に小さなPRでは、さらに誰かをレビューに呼ぶ必要さえないかもしれません。私たちはある程度Codexを信頼します。なぜなら、code reviewの核心的価値は「第二の目」があなたが馬鹿なことをしていないかを確認してくれることだからです――そして今やCodexはかなり賢い第二の目です。だから私たちはこの点で非常に積極的にlean inしています。
さらに、私たちの内部では現在CIプロセス、およびプッシュ後からデプロイまでのプロセスも、Codexによる自動化が大量に行われています。
多くのエンジニアが一番嫌がることを尋ねると、それは往々にしてコードを書くこと自体ではなく、きれいなコードを書き終えた後、それをどうやって本番環境に送り込むかです。たくさんのテストを走らせ、lint errorを処理し、code reviewを通さなければならない……これには多くのプロセス作業が含まれます。
これらのものはすべてCodexに任せるのに非常に適しています。だから私たちは内部でもこれらのステップを自動化するいくつかのツールを作りました。例えば、lintの自動処理：lint errorが発生した場合、Codexは通常簡単に修正でき、直接パッチを当て、CIプロセスを再起動できます。
私たちが全体的にやっていることは、エンジニアが費やす必要のある「手動操作」を可能な限り最小限に圧縮することです。副作用（実は利点）としては：みんながより多くのPRをマージし、より多くのコードをリリースできるようになります。
司会者： Codexがコードを書き、Codexが自分が書いたコードをレビューしている。あなたたちは他のモデルを使って、あなたたちのモデルの仕事をレビューすることを考えるのだろうか？これは一つの方向だろうか？それとも今のままで十分良く、他のものは必要ない？
Sherwin Wu： 「循環」のリスクが確かに存在する、と言うでしょう。『魔法使いの弟子』の比喩に戻ると、ほうきが制御不能になり、部屋中を走り回らないようにしなければなりません。
だから私たちは、「どのPRを完全にCodexにレビューさせられるか」という点では、実際には非常に慎重です。ほとんどの人はもちろん自分のPRを自分で一瞥します。人間のレビューが完全にゼロになるわけではありません。
より正確に言うと：ある人があるPRに対して持つ注意力を100％から30％に下げることです。そうすれば物事がよりスムーズに進みます。
「複数モデル」の問題については、私たちは内部で当然多くのモデルをテストするので、手元にはたくさんの異なるバージョンがあります。しかし、外部モデルは比較的使わない傾向があります――なぜなら「自分の犬の餌を食べる」ことが重要だと考えているからで、自分のモデルを使って実際の仕事をし、リアルなフィードバックを得たいのです。
もちろん、異なる視点を得るために内部の異なるバリエーションのモデルを使うこともでき、この方法も効果的だと分かっています。
司会者： OpenAIの現在の「AI + コード」の状況について、私の理解を確認させてください。確認したら、別の話題に切り替えたい。OpenAIのすべてのコードが、今、100％ Codexによって書かれているということですか？この表現は正しいですか？
Sherwin Wu： 「今日、本番環境で走っているすべてのコードがAIによって書かれた」とは直接言わないでしょう。この結論をそんなふうに下しません、なぜなら帰属をそれほど正確に行うのは難しいからです。
しかし、確かなことは：ほぼすべてのエンジニアが、すべてのタスクでCodexを非常に重く使っていることです。もし概算の比率を求められたら、私はこう言うでしょう：今、圧倒的多数のコードは、おそらく最初の作者がAIです。
AI時代、マネージャーのレバレッジは誰にかかっている？
司会者： 多くの議論がIC（個人貢献者）エンジニアの役割の変化についてですが、「マネージャー」の変化についての議論ははるかに少ない、特にエンジニアリングマネージャーという役割。AIの台頭後、あなたはマネージャーとして生活がどう変化しましたか？将来、マネージャーの役割はどうなると思いますか？
Sherwin Wu： その変化は確かにエンジニアほど大きくありません。少なくとも今のところ、「マネージャー専用のCodex」はありません。ただし、確かに私が行う「より管理寄りの」仕事の一部を処理するためにCodexを使います。変化はまだそれほど劇的ではない、と言うでしょうが、いくつかのトレンドが見えます。これらのトレンドを推し進めると、多くのことがどこに向かうか大体見えてきます。
ますます明確になる点の一つは：Codexはトップパフォーマーをはるかに効率的にするということです。これはAIのより広範な一般的法則でもあると思います：本当に深く受け入れようとする人、主観的能動性の強い人、あるいはこれらのツールを使いこなせる人々は、自分自身を「超加速」します。
今、私も明確に感じています：チームのトップパフォーマーはより多くの成果を上げるようになり、チームの生産性にはより大きな分化と幅が生まれます。
私がずっと持っている管理哲学は：私はほとんどの時間をトップパフォーマーに費やす――彼らが行き詰まらないように、彼らが満足しているように、彼らが効率的に進めていると感じ、自分の声が聞かれていると感じるようにする。
AI時代では、このことがより重要になると思います。なぜなら、トップパフォーマーはこれらのツールを使ってより速く、より強く走るからです。
例えば、先ほど言及したチーム：100％ Codexによって生成されたコードベースを保守しているチーム。彼らに自由にやらせ、何が起こるか見ることは、実際には非常に大きなリターンがあります。だから私が見る一つのトレンドは：マネージャーにとって、将来はより頻繁に、より多くの時間をトップパフォーマーに投入するようになるかもしれないということです。
もう一つのトレンドは：マネージャーが利用できるAIツールは、マネージャーのレバレッジを高くするでしょう。コードを書くレベルではなく、「組織知識を接続したChatGPT」のようなもの――それが研究を手伝い、組織のコンテキストを理解する手助けをしてくれます。現実的な例を挙げましょう：今、私たちはパフォーマンス評価を行っています。内部知識を接続したChatGPT――それがGitHub、Notionドキュメント、Google Docsにつながっているもの――を使って、ある人が過去12ヶ月に何をしたかについての完全な理解を迅速に形成させ、小さな「詳細調査レポート」を書かせることが簡単にできます。
私の直感では、このような世界では、マネージャーはより大きなチームを管理できるでしょう。エンジニアが今20〜30のCodexスレッドを管理しているように、これらのツールは「人を管理する」管理もより高いレバレッジにするでしょう。
現在のエンジニアリングチームでのいわゆるベストプラクティスは、通常、マネージャーが6〜8人を管理することです。しかし、将来は変わるかもしれません。
カスタマーサポートやオペレーションなどの非エンジニア分野では、すでに類似の現象が見られます：サポートチームの規模は過去は制限されていましたが、より多くの仕事をエージェントに任せられるようになると、より多くのことができるようになり、より多くの人を管理できるようになります。
テック企業のピープルマネジメントでも同様の変化が起こり得ると思います。私たちはすでにいくつかのチームを見ています：すでにかなりの人数を管理しているEMがいますが、彼らは依然としてうまく管理できています、なぜならツールがチームが何をしているか、組織のコンテキストをより高いレバレッジで理解し、それに基づいて運営することを可能にするからです。
司会者： ここでのあなたの提案がとても好きです：あなたはずっとトップパフォーマーにより多くの時間を費やし、彼らの障害を取り除き、彼らが満足していることを確認する傾向があります。Mark Andreessen（著名なVC創設者）も最近このポッドキャストに出演し、彼の言い方は：AIは良い人をより良くし、偉大な人を卓越させる。
Sherwin Wu：はい、はい。あなたが言っているポイントはまさに：将来、これはもっと多く、もっと極端に行う必要があるかもしれない――チームで最も強い人々により多くの時間を費やし、彼らに必要なすべてのリソースがあることを確認する。
私が今持っている良い例は：内部に、非常に「Codex化」された小さなグループのエンジニアがいて、彼らは「このモデルと対話する最良の実践は何か」を本当に真剣に研究しています。これは非常に高いレバレッジのことです。
マネージャーとして、私は直接こう言います：探求しに行ってください。どんなベストプラクティスをまとめても、それを組織全体に共有しなければなりません。私たちは様々な知識共有セッションを行い、ドキュメントやベストプラクティスをどこでも同期します。
このようなことはすべての人を一緒に引き上げます。これもまた、このトレンドのさらなる例だと思います：トップパフォーマーはより卓越する。
ソフトウェアと起業、新たな段階に入っている
司会者： 人々は感じます：これは大きなことで、AIが世界を変えている、「一人10億ドル企業」という概念が多くのものを変えている、それは大きな出来事になるだろうと。私たちがまだ本当に考慮に入れていない変化は何だと思いますか？つまり、将来はどう進むのか、私たちがまだ気づいていないが、実は重要な例は何かありますか？
Sherwin Wu： このAIの波の中で、私が最も好きな言い方の一つは、「一人10億ドル企業」です。Samが最初にこの概念を言った（少なくともそれを言葉にした最初の人）のを覚えています。それは本当に意味深いです：もし一人のレバレッジが十分に高くなれば、ある時点で、確かに「一人10億ドル企業」が出現する可能性があります。
それ自体はもちろんクールですが、私は人々がまだその二次、三次の影響を本当に考慮に入れていないと思います。
なぜなら、「一人10億ドル企業」が意味するところは：一人がこれらのツールを借りて、より強い主観的能動性、より高いレバレッジを持つことができ、会社がやらなければならないすべてのことを簡単にこなせ、最終的に10億ドルの価値のあるものを作り出せるということです。しかし、これはほんの一つの側面に過ぎません。それには他の意味もあります。
その二次影響の一つは：もし一人でも「一人10億ドル企業」になれるなら、それはつまり――起業そのものが全体としてはるかに容易になるということです。私は実際、これが巨大な「起業ブーム」を引き起こすと考えています、特にSMB（中小企業）スタイルの小規模起業ブームを：ほとんど誰でもどんなニーズに対してもソフトウェアを作れるようになります。
あなたはもうAI起業家の間でその兆しを少し見ることができます：ソフトウェアはより「垂直化」しつつあります。つまり、特定の業界/垂直領域向けのAIツールを作ることが非常に効果的なのです。なぜなら、その分野の実際のシナリオとユースケースを深く理解できるからです。
AIの進化をさらに先に推し進めると、この種の起業会社が100倍の数で出現しない理由は見当たりません。
だから私が想像する世界は：「一人10億ドル企業」を支えるために、これらの企業にサポートを提供するために、高度にカスタマイズされ、非常にニーズに合った「特注ソフトウェア」を作ることに特化した、何百もの小さな起業会社が出現するかもしれない。
これは私たちを非常に興味深い段階に連れて行くかもしれません：私たちは本当にB2B SaaSの黄金時代、さらにはより広義に、ソフトウェアと起業の黄金時代に入るかもしれません。なぜなら、ソフトウェアを書くのがますます簡単になり、会社を経営するのがますます簡単になるにつれて、最終的に見るのは、「一人ユニコーンが一つだけ」ではなく――おそらく「一人10億ドル企業」が一つあるが、同時に100の1億ドル企業があり、数万の1000万ドル企業があるかもしれないからです。
そして個人にとって、1000万ドルのビジネスは実際非常に良いものです――それは基本的に「一生安泰」を意味します。だから私たちはこの方向で爆発的な成長を見るかもしれない、と私は考えています。そして多くの人はまだこの点を本当に考慮に入れていません。
さらに次のレベル――三次影響と言えるでしょう―― もちろん、遠くに推し進めれば推し進めるほど不確実性は高まりますが、もし本当にこのような世界に向かうなら：至る所にこのような「ミニ会社」があり、作るソフトウェアはたった一、二人にしかサービスせず、会社も一、二人が所有し運営している。
すると、起業エコシステム全体が変わり、VCエコシステムも変わります。
私たちは、少数の超大規模プレイヤーだけがプラットフォームを提供し、そのプラットフォームが大量の小企業を支え、支える世界に入るかもしれません。
しかし同時に、本当に「ベンチャーキャピタルの尺度」に合うプロジェクト――投資を100倍、1000倍にできるプロジェクト――は、逆に減るかもしれません。なぜなら、1000万から5000万ドルの会社が大量に出現するからです：それらは個人にとっては非常に素晴らしいですが、VCにとっては必ずしも理想的なリターン構造ではありません。
これらの会社は、主観的能動性が極めて高い人々――AIを深く受け入れ、自分のためにビジネスを構築する人々――に非常に適しています。
司会者： 私たちが何次影響まで話し合ったのがとても気に入りました。今、四次影響を聞きたいです、Sherwin――冗談です。
Sherwin Wu： 本当に無理です、四次はあまりに「マクロすぎて」、そこまで考えられません。
司会者： これはまるで『インセプション』のようで、深く潜るごとに時間が遅くなり、物事がより複雑になります。しかし、「一人10億ドル企業」に戻ると、確かにこの問題をよく考えます。なぜなら私のやっていることは10億ドル企業になれず、VCの尺度にも合わず、特に高いレバレッジでもないからです。
しかし、現実の問題として考えるのは：私が毎日受け取るサポートチケットがあまりに多く、しばしば非常に不合理で、非常に細かいことです。「サポートコスト」というだけで、一人がどうやって10億ドルの規模を支えられるか想像するのが難しいです。だから私は「一人10億ドル企業」について慎重で、むしろ悲観的です。この観点を共有したい核心は：サポートコストは規模化するのが難しいということです。AIがいくらか助けてくれても、10億ドルの規模では、ACVが高く、顧客が少ない場合を除いて、サポートと様々な人間のコミュニケーションを処理するだけで拡大するのは難しいです。
私自身の経験では、多くのユーザーは実際には自分で問題を解決できますが、それでもサポートメールに小さな質問を送ります。これらのことを処理するのは規模化が非常に難しいです。だから、請負業者を大量に雇わない限り――それはまだ「一人会社」と言えるのか？――会社を10億ドルまで大きくすることは、少なくともサポート作業を処理する人もいない状態では、ほぼ不可能だと思います。AIも限界までしか助けられません。
Sherwin Wu： あなたが言うこの問題には同意します。ただ、「それがどう起こるか」についての私の見方は少し違います。
私はむしろ、Lenny、あなたのポッドキャストが将来10億ドル規模のビジネスになるかもしれない、と考えます。しかし、それはこういう方法で起こるのではないかもしれません：あなた一人がAIを派遣し、サポートチケットを一枚一枚処理し、問題を修正し、メールに返信する。
より起こり得るのは：あなたのニーズに非常に合ったソフトウェアを作ることに特化し、高度にカスタマイズされ、非常に垂直的な、たくさんの他の起業会社が出現するかもしれません。例えば、10社、20社の起業会社が、ポッドキャスト、ニュースレターといったビジネスのためのサポートソフトウェアに特化するかもしれません。それら自体が「一人会社」であり、必ずしも大きくする必要はありません。
なぜなら、この世界では、製品を作ることが非常に簡単になるからです。彼らは製品をとても適切に、とてもユニークに、本当にあなたにとって有用なものにでき、あなたはそれにお金を払うことを喜ぶでしょう――「高いレバレッジの一人会社」として、あなたがやりたくないことを外部委託するためにこれらのツールを買うのです。
司会者： 買いますよ、本当に買います。
Sherwin Wu： はい、ここには一つの鍵となる問題があります：何を社内で行い、何を外部委託するか。
起こり得るのは：ソフトウェアを書くこと、製品を作るコストが急速に崩壊するので、あなたはより多くのものを外部委託するようになるだろう、ということです。そうすると、あなたはむしろ会社の規模をより小さく保てます。
これが、私が起こり得ると考える世界です。もちろん、ここにはまだ高い不確実性がありますが、最終形態はやはりこうかもしれません：一人が駆動する、非常に高いレバレッジの会社が、本当に10億ドルの規模に達する機会があります。
司会者： 理解できます。私はPeter（OpenClawの人）のことも考えます、彼は今、様々なリクエスト、メール、DM、PRに完全に埋もれています。しかも彼はまだこれでお金を稼いでいません。彼の今の生活がどんなものか想像するのは本当に難しい――きっと非常にクレイジーでしょう。これは、あなたたちがChatGPTをリリースした後のあの数ヶ月のような狂気に似ているが、彼は一人で担っています。たぶん四次影響は：配信/到達がますます重要になることでしょう。なぜなら、あなたの注意力を奪い合うものが多すぎるからです。だから、オーディエンスやプラットフォームを持つ人がますます価値を持つようになる――それはなかなか面白い。
司会者： さて、あなたが先ほど言った管理の話題に戻りたい。あなたの洞察が本当に好きです：トップパフォーマーにより多くの時間を費やすことが、あなたにとって非常に効果的だと言いました。あなたが今率いているチームはプラットフォームを作っており、このプラットフォームは基本的にAI経済全体を駆動しています――ほぼすべてのAIスタートアップがあなたのAPIを使っています。明らかにあなたは非常にうまくやっています。では、これ以外に、あなたの核となる管理経験は何ですか？エンジニアリングチーム、そして人のマネージャーとして、あなたにとって特に重要で、あなたの成功の鍵を構成していると考えるものは何ですか？
Sherwin Wu： 私が学んだことの多くは、「OpenAI APIチーム専用」なのか、あるいは私たちのいくつかのエンタープライズ製品にしか適用できないのか、確信が持てません。
私の管理哲学は確かに変化していますが、全体的には、完全に刷新するのではなく、むしろ一貫性を保つ傾向があります。その原則の一つが、私が先ほど言ったもの：トップパフォーマーに大量の時間を費やすことです。より具体的に言うと、私は50％以上の時間をチームで最も強い人たち、例えば上位10％に費やし、彼らに力を与えるために最大限の努力をします。
この問題を理解するためによく使うメタファーは：ソフトウェアエンジニアを「外科医」と見なすことです。このメタファーは非常に古い本『The Mythical Man-Month』に由来します。この本は70年代頃に書かれ、実際に「未来を予測」しています。本の中では、ソフトウェア工学が一つのパターンに向かう可能性がある世界が描かれています――エンジニアは手術室でメインの外科医のようで、手術室には実際にメスを握るのは一人だけで、他の人は皆彼をサポートします：看護師、レジデント、フェロー……主刀が「メスを」と言えば誰かがメスを手渡し、主刀が「この器具を」と言えば誰かが装置を押してきます。みんながその一人をサポートしているのです。
『人月神話』はソフトウェア工学がこの方向に向かうと予測しました。私は現実が完全にそうだとは思いません――ソフトウェア工学はまだより協力的で、一人だけが働くわけではありません。
しかし、私はこの比喩がずっと好きで、管理スタイルにもずっとそれを適用しようと努めてきました。つまり：ソフトウェア工学は手術と同等ではないが、チームメンバーへの私のサポートの仕方を、彼らが「メインの外科医」のように感じられるようにしたい――彼らが最も重要な仕事を進めており、マネージャーとしての私の責任は、彼らが「サポートチーム」を持っていることを確認し、彼らが必要なものが常に利用可能であることを確認することです。実際のサポートチームが私一人だけだとしても、この効果を達成したいのです。
私がよく挙げる例は：角の向こうにある障害を事前に見て、組織プロセスから人を詰まらせないようにすることは、非常に価値があります。
そしてAI時代には、これがより重要です。なぜなら、エンジニアが一度に多くのPRを送り、継続的に高頻度で納品できるようになると、進捗と納品速度を本当に制限するのは、組織レベルの障害、プロセスレベルの障害になることが多いからです。
マネージャーとして「一歩先を見る」ことができ、彼らが必要とするリソースを事前に準備できれば――ちょうど主刀医がメスを必要とし、あなたがすでにメスを準備しているように――それが最も理想的な状態です。これが私の理解する管理方法、特にエンジニアリング管理です。この比喩は私について回り、基本的に私のキャリアを通して続いています。
司会者： この比喩がとても好きです。私はむしろ、AIもこれを助けられるかもしれないと考えます：あなたが「角を見る」のを。例えば予測：このエンジニアが次にどの決断で詰まるか、それを事前に解決しなければならない。
Sherwin Wu： 試したことはありませんが、今急に好奇心が湧きました：会社の内部知識に接続されたChatGPTに尋ねたら――例えばNotionドキュメントをスキャンし、Slackのどこで言及されているかを見て――「私のチームには今、どんなアクティブなブロッカーがありますか？彼らを助けるために何ができますか？」と直接尋ねるのは。この考え方は本当に前から思いつきませんでしたが、あなたの言う通り、あなたは私に洞察を与えてくれました。
司会者： さらに進んで、尋ねることもできる：今後数ヶ月、このエンジニア、このチームが何で詰まるか予測する？あなたは先ほど二次三次影響について話していたが、今、私はモデルに二次三次影響を行わせる：来月のブロッカーを予測し、事前に解決する。
Sherwin Wu： はい、はい。ここで本当に良いアイデアを掘り当てたかもしれません。
なぜこれほど多くのAI導入が、最終的に負のROIになるのか？
司会者： さて、あなたたちが行っているAPIとプラットフォームについて切り替えたい。あなたたちは多くの会社と取引があります：それらはあなたのAPIを接続し、あなたのプラットフォームを使い、あなたのツールを基に製品を作っています。あなたは以前私に、多くの会社のAI導入が実際にはROIが負であると観察したと言いました。これは多くの人がニュースを読み、自分でも漠然と信じている結論だと思いますが、あなたが本当に第一線でそれを見ていると言うのは興味深い。いったいどうなっているのか？彼らはどこで間違えたのか？現在のAI導入とROIの現実状況は何ですか？
Sherwin Wu： 明確にしておきます：私は「明示的に」そのような定量化可能なROIデータを見ているわけではありません――これは実際には測定が難しいです。しかし、私が観察したいくつかの会社の「AI導入」の仕方を見るだけで、多くの導入が最終的に負のROIになっても驚きません。同時に私は、テック界の外――例えば米国の多くの非技術職の人々の間で――非常に一般的な感情があることにも気づいています：AIは押し付けられている、というものです。この反発感自体が、「負のROI導入」の外部症状の一つかもしれません。
私が見る典型的な問題はだいたいいくつかあります。
まず、私はいつも古い問題に戻ります：シリコンバレーはしばしば自分たちがバブルの中に生きていることを忘れています。Twitterはバブルです――ごめんなさい、今はXですが――シリコンバレーはバブルで、ソフトウェアエンジニアリングもバブルです。世界のほとんどの人々、米国のほとんどの人々は、ソフトウェアエンジニアではありません。彼らはそれほど「AI化」されておらず、すべてのモデルリリースを追跡することもありません。多くの人は実際にこのテクノロジーの使い方も知らず、それがどう働くかの概念もあまり持っていません。
私たちがOpenAI内部で、Codexのベストプラクティスについてたくさん話すのを見てください。Codexを最も効率的に使う方法を専門に研究する人たちさえいます。Xで頻繁に投稿する人たちも、ほとんどAIツールの熱狂的パワーユーザーです：skills、agents.md、MCP……これらをとても上手に使っています。
しかし、多くの会社と話すと、特に実際にツールを日常業務に使うべき現場の従業員と話すと、彼らのニーズは非常に基本的で、彼らのこのテクノロジーへの理解も限られていることがわかります。彼らが尋ねる質問はとても単純で、「ツールを限界まで押し進める」には程遠いです。
これが、私が考えるより理想的なAI導入の仕方がどんなものか――そして私たちがOpenAI内部で大まかにどう運営しているか――にもつながります：「うまくいっている」会社は、往々にして二つのことを同時に備えています。
第一に、上からのbuy-inです。経営陣が明確に表明：私たちはAIファーストの会社になる。するとリソースが投入され、ツールが購入され、組織が明確なサポートを提供します。
しかし、第二に同様に重要：下からのadoptionとbuy-inがなければなりません。つまり、実際に仕事をする現場の従業員が、このテクノロジーに興奮し、学びたい、布教したい、ベストプラクティスをまとめたい、組織内で知識共有をしたいと思うことです。
私たちはOpenAI内部でも同様のプロセスを経験しました。OpenAIは常にAI中心でありたいと願ってきましたが、本当にこれを「飛躍」させたのは、Codexのようなツールが登場した後です――なぜなら従業員がついにそれを具体的な仕事に直接使えるようになったからです。
下からの推進が必要な理由は、一人ひとりの仕事が異なり、非常に具体的だからです。ソフトウェア工学は財務と等しくなく、オペレーションと等しくなく、マーケティングセールスと等しくありません。仕事のレベルに落とすと、「ラストワンマイル」の詳細が大量にあり、現場の人々が試し、磨き、ワークフローを変えなければなりません。
そして多くのAI導入が失敗するのは、まさに下からのadoptionが欠けているからです：それはより高層からの命令のように、過度にトップダウンで、実際の仕事のやり方と乖離しています。結果として、膨大な従業員全体を前に、彼らはこのテクノロジーを本当に理解せず、「私はそれを使うべきだ」とだけ知り、パフォーマンス評価にも「AIを使って生産性を向上させよ」と書かれていますが、具体的な使い方は誰も教えてくれません。
彼らは周りを見回すと、実際に使っている人もいません：学べる人がおらず、コピーできるパスもなく、そこで行き詰まります。
だから私がAIを推進したい会社に与えるアドバイスは：見つける――むしろ特に配置する――フルタイムの小さなチームを、内部のタイガーチームとして。このチームは能力を探求し、具体的なワークフローに落とし込み、継続的な知識共有を行い、組織内部に興奮を生み出し、より多くの人が試したくなるようにする責任があります。このメカニズムがなければ、AIは本当に「拾い上げて使う」ことが難しいです。
司会者： では、このタイガーチームには誰を入れますか？エンジニアが主導すべきですか？それともむしろクロスファンクショナルチームのようなものだと思いますか？
Sherwin Wu： この質問は興味深い。なぜなら現実は：多くの会社にはソフトウェアエンジニアがいないのです。だから私が見るより一般的なパターンは――タイガーチームのコアメンバーは、往々にして「ソフトウェアエンジニアリングに隣接する」ポジションから来る人々です：技術的だが、必ずしもエンジニアではない。
これらの人々はむしろ最初に興奮しやすいです。例えばサポートチームやオペレーション責任者：彼はコードを書きませんが、ツールをいじるのが特に好きで、Excelの達人、プロセスの達人かもしれません。この種の人々がAIツールに触れると、往々にして「目を輝かせる」――習得が早く、モチベーションが高く、使い方を積極的にまとめようとします。
だからこの種のタイガーチームの典型的なプロファイルは：技術隣接、コーディング隣接、全体的に技術能力が低くなく、試したい、学びたい、人を導きたい。通常、彼らを中心に小さなチームを組むことができます。
もちろん、エンジニアが参加すると非常に役立ちます。彼らは基盤メカニズムをより速く理解し、システム化した導入もより得意です。しかし、多くの会社にはこの条件がありません：エンジニアは希少資源で、募集も難しく高価です。だから多くの場合、実際にAIを推進するのは、これらの「エンジニアではないが技術的な」役割の人々なのです。
司会者： 私が聞いたところ、あなたが言うアンチパターンは：上から下へ。例えばCEOと経営陣が決定：私たちはAIファーストになる、私たちは全面的にAIを受け入れる。全員が評価される：AIツールを使ってどれだけ生産性を向上させたか。しかし、もし上から下へだけで、下から上へ「伝播と牽引」するチームを構築しなければ、それはうまくいきません。
Sherwin Wu： はい、まさにそうです。核心的なアドバイスは：最も興奮している人を見つけることです。彼らを組織のあちこちに分散させるより、むしろ集め、小さな「AI伝道チーム」を形成させる。彼らが使い方、導入方法を探求し、その使い方を組織全体に拡散させる。あなたが私をこう要約すると、私は突然気づきます：これは私自身の管理哲学にも合致します。つまり：AI導入における高パフォーマーを見つけ、彼らに力を与える――彼らにハッカソンを開かせ、彼らに共有会を開かせ、彼らに知識共有をさせ、内部に興奮の種をまく。
ベクトルデータベースからskillsへ：足場は次々に飲み込まれている
司会者： 展開してほしい「ホットな意見」がいくつかあります。あなたがよく言及するのを見たことがあります：AI分野では、「顧客と話し、顧客の言葉を聞く」ことは必ずしも正しい戦略ではなく、むしろあなたを道に迷わせることが多い、と。
Sherwin Wu： これがどれほど「ホット」かわかりません。私が言いたいのは「顧客と話すべきではない」ということではありません――もちろん話すべきで、非常に価値があります。
むしろ強調したいのは：AIという分野（特に私が過去3年API側で見てきた変化）のイテレーション速度があまりにも速いということです。モデルとエコシステム全体が絶えず自己破壊を繰り返し、特にツールチェーン、足場のこの層で。
今週、ちょうどXの記事で、Finolというスタートアップの創業者であるNicholasからの一言を見ました。彼は金融サービスシナリオでのAIエージェントの実戦経験をたくさん共有しています（彼は以前FinToolという会社でも同様の方向で働いたと思います）。彼の好きな言葉は：「モデルはあなたの足場を朝食として食べる」です。
2022年にChatGPTがリリースされた頃を振り返ると、モデルはまだ粗かった。そこで開発者ツールの世界に、モデルをあなたが望むように制約し、導くための「足場的プロダクト」が大量に出現しました：様々なエージェントフレームワーク、ベクトルデータベース……当時はベクトルデータベースが特に人気で、周辺には多くの付随ツールも生まれました。
しかし、ここ数年を見てみると、モデルはあまりにも速く、あまりにも強くなり、結果的にその足場の一部を本当に「食べて」しまいます。これは今でも成り立つと思います。Nicholasの記事が言及した「現在流行りの足場」は、skillsファイルに基づくコンテキスト管理です。あなたは完全に、未来のある時点で、このセットはもはや有用ではなくなる世界を想像できます。なぜなら、モデルがこれらのコンテキストを自分で管理できるからです。あるいはパラダイム全体が再び別の方向に切り替わり、このファイル形式のskillsは必要なくなります。
あなたはすでにこのようなことが起こるのを目撃しています：エージェントフレームワークは今ではあまり有用ではなくなりました。2023年、一時的に私たちはベクトルデータベースが組織知識をモデルに導入する「主経路」だと思っていました――すべてのコーパスを埋め込み、ベクトル検索を行い、さらに多くの最適化を行い、正しい時間に正しい情報を取得することを保証する必要がありました。
あの一連のことは、本質的に足場でした、なぜなら当時モデルはまだ十分に強くなかったからです。そしてモデルが強くなると、より良い方法は往々にして：多くのロジックを取り除き、モデル自体を信頼し、検索のための一連のツールを与えるだけです。
この検索は必ずしもベクトルデータベースである必要はなく、どんな形式の検索でも接続できます――例えば、skills、agents.mdのようなファイルシステム内のファイルさえ、それに導くことができます。
もちろん、ベクトルデータベースには依然としてその位置があり、多くの会社がまだ使っています。しかし、「ベクトルデータベースを中心に足場エコシステム全体を構築し、それを唯一の答えとする」という仮定は、大きく変化しました。
だから「顧客フィードバック」に戻ると：必ずしも常に顧客の言うことを聞く必要はありません、なぜならこの分野は変化が速すぎるからです。多くの顧客はある時点で実際には「局所最適」にいます。
もし顧客の言うことだけを聞くと、彼らはこう言うでしょう：もっと良いベクトルデータベースが欲しい、もっと良いエージェントフレームワークが欲しい……しかし、もしこの道だけを進むと、「局所最適」の製品を作ることになるかもしれません。そしてモデルの能力がさらに一段階上がった時、私たちは往々にして再発明、再考する必要があります：何が正しい抽象化、正しいツール、正しいフレームワークなのか。そしてもっと興味深く、さらに興奮させられ、同時に少しイライラさせるのは：これは移動標的だということです。
あなたが今日「正しい」と考えるツールとフレームワークの組み合わせは、未来にモデルがますます賢く、ますます強くなるにつれて、おそらくまだ進化し続け、大きく変わります。これがこの分野で製品を作ることの本質です。これもまた、興奮をかき立てる点です。しかしそれはまた意味します：あなたが顧客と話すとき、あなたは「彼らが今何を欲しているか」と「あなたがモデルがどこへ向かうと考え、今後1、2年でどう進化するか」の間でバランスを取る必要があるということです。
司会者： これはいわゆる「bitter lesson」に似ている：AI/ML分野の重要な教訓は――複雑なロジックを加えれば加えるほど、手作業の設計を加えれば加えるほど、それは規模化成長を制限する。むしろ可能な限りこれらのものを取り除き、計算させ、自分自身を強くさせるべきだ。
Sherwin Wu： はい、ここには確かに「bitter lessonをAI製品構築に適用する」バージョンが存在します。私たちはモデルの周りに多くのものを構築しようとしましたが、モデルの能力が向上すると、それらを直接食べてしまいます。正直言うと、OpenAIのAPIチームもある時点でこの過ちを犯しました：歩くべきでない遠回りをしたことがあります。しかしモデルは依然として強くなり、私たちも日常の中でこのbitter lessonを絶えず学ぶしかありません。
司会者： では、APIを使って製品、エージェントを構築している人々にとって、重要な取るべき教訓は何ですか？なぜなら、彼らはまだ現段階の能力を中心にいくつかのものを構築しなければならないからです。どんなアドバイスをしますか？
Sherwin Wu： 私が常に皆に与える全体的なアドバイス――今日になっても依然として成り立つ――は：モデルがこれから行く場所のために構築し、モデルが今日何ができるかだけのために構築してはいけない。
なぜなら目標は本質的に移動標的だからです。私は特にうまくやっているスタートアップを見たことがありますが、彼らは製品を「理想的な能力」の周りで設計します：この能力は現在、おそらく80％しか実現していません。だから彼らの製品は今もちろん「使える」が、いつもあと一息のようです。
しかし、モデルの能力がもう一段階進んだ瞬間、体験は突然「カチッ」とアンロックされます：元々足りなかった一息が補われ、製品全体が「辛うじて使える」から「非常に素晴らしい」に変わります。
例えば、ある重要な能力がo3の時代にはまだ安定していなかったが、5.1、5.2になると突然使えるようになる――彼らがこの利益を得られたのは、製品設計の時点で「モデルは必ず強くなる」を前提としてロードマップに書き込んだからです。最終的にあなたは、モデルの能力を静的と考え、現状にパッチを当てるやり方よりはるかに優れた体験を得ます。
だから私のアドバイスは簡単です：モデルの未来の方向に従って設計してください。少し待つ必要があるかもしれませんが、モデルが強くなる速度はあまりにも速く、多くの場合、あなたはそれほど長く待つ必要はありません。
司会者： この話題に沿って、今後6〜12ヶ月でAPIがどこへ向かうか共有できますか？プラットフォームはどこへ向かうか？モデルはどこへ向かうか？ここでの多くの内容は機密かもしれませんが、あなたが共有できるだけ共有してください――最も興奮していること、みんなが準備を始めるべきだと思うこと。
Sherwin Wu： 最も明白な方向の一つは：モデルが連続的、安定的にタスクを完了できる時間が長くなっています。
参考になると思うベンチマーク指標（彼が言及したmeter benchmark）があります。ソフトウェア工学タスクにおいて、モデルが安定的にどれくらい走り続けられるかを追跡するのに使います――例えば、50％の成功率でどれくらいの時間持続できるか、80％の成功率でどれくらいの時間達成できるか。
私の印象では、現在の最先端モデルは大体：50％の成功率では「数時間級」のタスクを完了できます。しかし、閾値を80％の成功率に上げると、まだ「1時間に近いが、まだ達していない」レベルかもしれません。このベンチマーク指標が最も目を覚まさせる点は：歴代のモデルを同じ時間線上に並べ、トレンドがどう一歩一歩前に進んでいるかを非常に直感的に見られることです。
私を興奮させるのは：今日多くの製品は、まだ「モデルが何分走れるか」を中心に最適化されています。たとえCodexのようなコーディングツールでも、あなたはそれがより対話的で、むしろ呼び出せばいつでも応える協力者のようなもの――それが最も得意とし、最も最適化されているのは、やはり10分程度のタスクです。
もちろん、Codexを限界まで押し進め、数時間級のタスクを実行させる人を見たこともありますが、それは依然として少数のケースであり、常態ではありません。
もしこのトレンドをさらに前に推し進めると、私は今後12〜18ヶ月で、モデルがより安定し、より連続的に「数時間タスク」を完了できるようになると考えます。さらにこのような段階が現れるかもしれません：あなたが約6時間レベルのタスクをそれに渡し、しばらく自分で走らせてから、結果と進捗を返すようにする。
一度このレベルに能力が達すると、それを中心に構築する製品の形態は完全に変わります。あなたはまだモデルにフィードバックを与える必要があるし、確かに一日中制約なく走らせたいとは思わないでしょう――そうしたい人もいるかもしれないが、ほとんどのシナリオではそうしません。そしてタスク時間が本当に長くなると、モデルがカバーできる作業範囲が一度に大幅に大きくなり、できることの「宇宙」もそれに伴って拡大します。これも私が最も興奮する点です。
もう一つ、今後12〜18ヶ月がクールになると私が思う方向は、マルチモーダルモデルの進歩です。より具体的に言うと、私は主にオーディオを指します。
現在、モデルはオーディオでもかなり良いですが、今後6〜12ヶ月で、さらに強くなると思います――特にネイティブマルチモーダルで、speech-to-speechのモデルです。同時にオーディオ側では、いくつかの新しいモデル構造、アーキテクチャの方向性も出現するかもしれません。そしてオーディオは企業と商業シナリオでは、依然として深刻に過小評価されている領域です：みんなコーディングについて話し、テキストについて話しますが、私たちは今オーディオで会話しています。世界の多くのビジネスは、「話す」ことで成り立っています。多くのサービスとオペレーションも、コミュニケーションで成り立っています。
だから私は今後12〜18ヶ月で、オーディオは非常に興奮をかき立てるものになり、より多くの「アンロックされた」能力を見るだろうと思います。
司会者： 素早くまとめると：あなたはエージェントとAIツールがますます長時間のタスクを実行できるようになる、このトレンドは持続的に強化されると考えている。そしてオーディオと音声がより重要になり、よりネイティブに、よりコアに、体験が良くなる。
司会者： あなたが先ほど言った「ホットな意見」に戻る。あなたがもう一つよく話すのを見た：あなたは「ビジネスプロセスオートメーション」という方向を非常に強く支持し、それがAI世界での巨大なチャンスだと考えている。これについて話す？
Sherwin Wu： はい、これは実際に私が前に言ったことに戻ります：私たちはシリコンバレーでバブルの中に生きています。私たちが慣れ親しんだ仕事の形態――ソフトウェアエンジニアリング、プロダクトマネジメント、製品を作ること――は、経済全体を支える大量の仕事の形態とはまったく違います。顧客と話すと、このことを強く感じることがよくあります：どんな非テック企業と話しても、彼らには膨大な「ビジネスプロセス」があることに気づくでしょう。
私は通常こう区別します：ソフトウェアエンジニアリングはより開放的な知識労働（open-ended knowledge work）に似ています。これがCodexのようなツールが強い理由でもあり、なぜならそれは探索が得意で、あなたが与えるのは開放的な問題だからです。
しかしソフトウェアエンジニアリングの本質は非常に開放的で、しかも「繰り返し可能」ではありません。あなたが一つの機能を作るのは、同じ機能を何度も何度も繰り返すためではありません。多くのテック関連のポジションはこの開放的な仕事に属します：データサイエンスも多少似ているし、一部の戦略的な財務作業も多少似ています。
しかし、ソフトウェアエンジニアリングから、あるいは「テック企業のコア」から離れれば離れるほど、多くの仕事が単なるビジネスプロセスであることに気づくでしょう：繰り返し可能なこと、繰り返し可能なオペレーション操作です。それは往々にしてある会社の管理者が長年かけて繰り返してきたやり方であり、通常は標準作業手順（SOP）があります。みんなSOPに従って進めたいと思い、そしてあまりそれから逸脱したくありません。
ソフトウェアエンジニアリングの「知恵」は往々にして革新、逸脱、探索にあります。しかし、世界の大量の仕事の本質は、まさにこれらのプロセスを実行することです。
例えば私がカスタマーサポートに電話すると、相手は一連のプロセスに従っています。私が公共事業会社に電話すると、彼らにも多くのプロセスとルールがあります：何ができて、何ができないか。だから私はこの大きなカテゴリーの機会を非常に強く支持します：AIを使ってビジネスプロセスオートメーションを行う。そして私はそれが過小評価されていると思います、なぜならシリコンバレーの日常の話題とあまりにも違うので、みんなあまり考えないからです。
しかし、考えてみてください：私たちはAI、私たちが持つ既存のツールとフレームワークを使って、これらの繰り返し可能で、決定性が強い（high determinism）ビジネスプロセスを自動化できるだろうか？より省力化し、よりスムーズにできるだろうか？鍵はまた：それは企業のデータ、企業の意思決定ロジック、および企業内部の様々なシステムに深く統合されなければなりません。この領域のチャンスは巨大で、やるべき仕事も非常に多いと思いますが、ただ私たちはあまり話しません、なぜならそれは私たちの「快適ゾーン」にないからです。
司会者： 私の理解が正しいか確認します：あなたはAIの「エンジニアリング以外」でのチャンスがより大きいと考えている――それは企業の生産性に影響を与え、繰り返し可能で自動化しやすい仕事に従事する大量の人々に影響を与え、さらには仕事の組織方法を変えることができる。なぜなら現実の多くの仕事はこのように成り立っているからだ。
Sherwin Wu： はい。私は多くの大企業の顧客とよく話します：AIは20年後に私の会社をどう変えるだろう？AI世界で会社はどう運営されるだろう？
ソフトウェアエンジニアリングはもちろん物語の一部ですが、ビジネスプロセスの側にもっと多くのものがあります。そして私はビジネスプロセスの側が、最終的にはより「根本的に異なる」様子を呈し、やるべき作業量も非常に大きいと思います。
絶対的な規模から言うと、それがソフトウェアエンジニアリングより大きいか小さいか確信が持てません――ソフトウェア自体も非常に大きく、カバー範囲も非常に広いです。しかし確かなのは：この領域は本当に大きく、そしてX/Twitterで見る議論の熱量をはるかに超えています。多くの人は全くそれについて話さないので、あなたはそれを過小評価します。
OpenAIに「潰されない」ためにはどうすればいい？
司会者： 方向を変えます。あなたたちはプラットフォーム、APIを作り、多くの人々がAPI上で製品を作っています。皆の頭の中の最大の疑問は常に：どうすればOpenAIに「潰されない」か？あなたたちは同じものを作り、私が築き上げた市場を破壊するだろうか？あなたたちの全体的な方針、全体的な哲学は何か？スタートアップはどう判断すべきか：どの方向はOpenAIが自ら参入する可能性が低いか？
Sherwin Wu： 私の全体的な答えは：市場があまりにも大きく、機会空間がとんでもなくでかい。スタートアップは本当にOpenAIや他の大規模モデル研究所が何をするかについて過度に悩む必要はありません。
私は多くのスタートアップを見てきました、うまくいかなかったものもあれば、うまくいったものもあります。私が見たすべての「消滅した」会社の中で、OpenAI、ある大規模研究所、Googleなどが「走ってきて潰した」ために失敗した会社は一つもありません。彼らが失敗した理由はもっと単純です：彼らが作ったものが本当に顧客を感動させず、顧客のニーズと共鳴しなかったのです。
逆に、飛躍した会社は、非常に競争の激しい分野でも立ち上がりました。例えばコーディング分野は十分に競争が激しいが、Cursorは今でも大きい――なぜなら彼らは皆が本当に好きなものを作ったからです。
だから私のアドバイスは：このことについてあまり心配しないでください。ユーザーが好きな製品を作ることに集中すれば、必ずその中に空間を見つけられます。
強調しすぎることはありません：今のAIの機会がどれほど大きいか。機会は、VCの「許容範囲」（overton window）さえ変えるほどです――VCは現在、同じトラックで「互いに競争する会社」に非常に多く、非常に積極的に投資しています。なぜなら空間が大きすぎ、機会が大きすぎ、ほとんど前例がないからです。
起業家の視点から見ると、これはむしろ最も力を与えられる環境です：一部の人々が非常に非常に好きなものを作るだけで、価値の大きなビジネスを作れます。だから私は繰り返し言います：「潰されるかどうか」を過度に考えないでください。
また、もう一つ重要なこともあります、少なくともOpenAIの観点から：私たちは常に非常に非常に重視していること、これもSamとGregがトップから絶えず強調していること――私たちは根本的に自分たちを「エコシステムプラットフォーム会社」と見なしています。APIは私たちの最初の製品です。私たちはこのエコシステムを育成し、継続的にサポートしなければならないと考えています、それを破壊するのではありません。
私たちが行う多くの決断を見ると、このロジックが常に貫かれています：私たちが一つのモデルをリリースするたび、ある製品でローンチするたび、それは最終的にAPIに入ります。たとえ今リリースしているCodexモデルがCodex harnessの最適化に偏っていたとしても、それらも最終的にAPIに入り、すべてのAPI顧客も使えるようになります。
私たちはこれらの能力を「隠して出さない」ことはしません。プラットフォームの中立性を保つことが非常に重要だと考えています：私たちは競合他社をブロックせず、皆が私たちのモデルにアクセスすることを許可します。私たちは最近「ChatGPTでログイン」のような製品もテストしており、このエコシステムをさらに大きくしたいと考えています――これは非常に重要です。全体的なロジックは：水が増えれば船も高くなる。私たちは今、航空母艦のように巨大な体量かもしれませんが、私たちは「潮位」全体を高めることが、すべての人にとって有益であり、私たち自身も恩恵を受けると考えています。
私たちのAPIの成長は、ある程度、私たちが常にこの方法で行動してきたからです。だから私は本当に、OpenAIをいつでもあなたを押しのけ、あなたを締め出す存在として考えるべきではない、と勧めます。あなたの注意はむしろ、本当に価値のあるものを作ることに向けるべきです。私たちはオープンなエコシステムを提供し続けることに取り組んでいます。
司会者： なぜこれはOpenAIにとって重要ですか？この「プラットフォームを作り、他の人にビジネスをさせる」という固執は、最初からあったビジョンですか？
Sherwin Wu： はい、これは最初からありました。それは私たちの憲章、私たちの使命にまで遡れます。
OpenAIの使命はずっと二つのことでした：第一に、AGIを構築すること。私たちはもちろんこれを行っています。第二に、その利益を全人類に拡散させる（spread the benefits to all of humanity）ことです。鍵は「全人類」にあります。ChatGPTはもちろんこれを行っており、私たちは世界に届けたいと思っています。しかし、私たちは早い段階で気づきました：OpenAI一社だけでは、世界の隅々に届けることは不可能です。世界は大きすぎ、隅々のニーズは深く、細かいです。
だから使命を達成するために、私たちはプラットフォームを作らなければなりません：他の人々が、私たち自身では決して直接作れないもの――例えばあなたが先ほど挙げた「ポッドキャストとニュースレターの主催者のためのカスタマーサポートボット」のような製品を、私たちは作りませんが、他の人がプラットフォーム上で作り出せるようにするためです。これがAPIの意義です。また、私たちはエコシステムから出現する様々なものを常に非常に喜んで見てきました。だから最初から、これは使命の一つの現れです。
司会者： それに、あなたたちがローンチ予定のChatGPT「アプリストア」（app store）についてはまだ触れていません。これはあなたの管轄内ですか？それとも別の組織/チームですか？
Sherwin Wu： それは別のチームで、よりChatGPT体系に属します。しかし私たちは彼らと非常に緊密に協力しています。彼らはapps SDKを作りましたが、それも私たちのチームと緊密に協力して作られたものです。しかし確かにChatGPTの傘下にあります。
しかし、それは同じロジックの例でもあります：ChatGPTは現在8億の週間アクティブユーザーを抱えています。これらのユーザーは繰り返し戻ってきて使います。ビジネスにとってこれは非常に強力な資産です。しかし、もし他の会社も参入させ、この入口を利用し、この人々向けに製品を構築できるようにすれば――それはさらに良くないでしょうか？最終的に私たちも、これがこのユーザーグループをさらに大きくするのに役立つと考えています。だからそれはやはり使命に戻ります：プラットフォームを作り、オープンであることは、しばしばより大きな成長をもたらします。
司会者： あなたが言った8億という数字……週間アクティブ8億ですか？今さっき頭が止まりました。
Sherwin Wu： 週間アクティブ8億です。
司会者： これはあまりに極端で、前例がない。私たちはこの規模の数字に麻痺していますが、それは本当に非常識です。
Sherwin Wu： はい、規模の観点からこれについて考えると、私も非常に衝撃を受けます。私はこう理解します：世界中の人口の10％にほぼ等しく、しかもまだ成長中です。まだ上昇中です。毎週、世界人口の10％がChatGPTを使いに来ます（正確には週間）。
司会者： あなたが先ほど言った点ももう一度強調したいです：OpenAIの使命はAIの利益を全人類に届けることです。これを嘲笑する人もいます、「これって有料化するんじゃないの」と。しかし現実は：誰でも無料のChatGPTを使えます。無料版の能力は、世界で最も強力なAIモデルと「天と地の差」ほどの距離はなく、それは厳しい閾値で遮られ、少数の人々だけが使えるものではありません。もしあなたが億万長者なら、AIから得られる増分は実際には限られています。そしてアフリカの村にいる人は、インターネットに接続できるなら、彼が得られるAI能力はそれほど劣っていません。これはOpenAIが常に非常に気にかけていることだと思います。
Sherwin Wu： はい、これがなぜ私たちが医療や教育を重視するのか――教育分野は非常に興味深いでしょう。
もう一つクレイジーなトレンドは：無料モデル自体もますます賢くなっていることです。2022年の無料モデルを振り返ると、当時はすでにまあまあでしたが、今日と比べると全く同じレベルではありません。今日あなたが得るのはGPT-5（ここで彼が言及した「2 GB 5」を意味的にGPT-5レベルの無料能力と解釈します）――だから私たちの言う「世界の底辺を引き上げる」（raising the floor）ということは、私たちの使命の一部です。
さらに、「億万長者」という観点から面白い対比があります：あなたが使うiPhoneは、Zuckerbergやあの億万長者たちが使うものと同じモデルかもしれない、と言う人もいます。そして今、ある程度それと似ています：あなたは月20ドルで「億万長者も使っているAI一式」を使えます。あなたは月200ドルでProにアップグレード――「億万長者も使っているPro」です。しかし彼らも日常的に常にProを使うわけではなく、多くの場合、Plusレベルで十分です。
だからこのような「民主化」、このような利益を世界中に拡散することは、私たちにとって非常に意義があり、多くの決断を駆動しています。
司会者： 最後の質問：API上で何か作りたい人々にとって――彼らは突然気づいたかもしれない「私もオープンソースモデルとAPIでクールなものが作れる」と――あなたたちのAPIとプラットフォームは実際に何を許可していますか？あなたたちがプラットフォーム上でエージェントを構築できることは知っています。全体としてどんな能力を提供しているか説明できますか？
Sherwin Wu： 根本的に言うと、APIが提供するのは、開発者エンドポイント（developer endpoints）のセットで、あなたが私たちのモデルからサンプリング（sample）できるようにするものです。
現在最も人気のあるエンドポイントはResponses APIです。これは「長時間実行するエージェント」の構築に最適化されたエンドポイントです――つまり、しばらくの間動作するエージェントです。
最も低レベルのプリミティブでは、基本的にあなたはモデルにテキストを渡し、モデルにしばらく働かせます。あなたはそれをポーリングして（poll）、何をしているか確認できます。そしてある時点でモデルの返答を受け取ります。これは私たちが開発者に提供する最低層のプリミティブであり、多くの人が最もよく使う構築方法です。これは非常に「無主張」（unopinionated）です：あなたはほとんど何でもできます。これは最も低レベルの構築ブロックです。この上で、私たちはますます多くの抽象化レイヤーを提供し始め、皆がこれらのものをより簡単に構築できるようにします。
さらに上の層では、私たちにはAgents SDKと呼ばれる非常に人気のあるものがあります。これはResponses APIや他のエンドポイントに基づいて、より伝統的な意味でのエージェントを構築できるようにします：例えば、AIがほぼ「無限ループ」のワークフローで継続的に実行されます。サブエージェントを持ち、タスクを委任できます。
これはフレームワーク/足場の一式を構築してくれます――もちろん、将来この足場もモデルに「食べられる」かどうか、私たちも観察し続けます。しかし現在のところ、確かにエージェントの構築をはるかに容易にします：ガードレールを与え、サブタスクを他のエージェントに分配し、エージェントswarm（蜂群式のエージェントシステム）を編成できます。Agents SDKがこれらを手助けします。
さらにその上で、私たちはより「メタレベル（meta level）」のツールもいくつか始めています。Agent Kitと呼ばれる製品と、いくつかのWidgetsがあります：本質的にUIコンポーネントのセットで、APIやAgents SDKの上で素早く美しいインターフェースを作れるようにします。なぜなら多くのエージェントはUIの観点から見ると非常に似ているからで、コンポーネントのセットを提供することで、製品化を大幅に加速できます。
さらに、評価関連の製品もあります、例えばEval API：もしモデルやあなたのエージェント、ワークフローが有効かテストしたいなら、私たちのeval製品を使って比較的定量化されたテストができます。
だから私はこれを層状のスタックと理解します：異なるレイヤーが、あなたが私たちのモデルを使って欲しいものを構築するのを助けます。抽象化レイヤーが高くなるにつれて、ますます「主張的」になります。あなたはスタック全体を使い、すぐにエージェントを作ることもできますし、一番下まで潜り、Responses APIだけを使って自分が望むすべてを構築することもできます。
ライトニングQ&A
司会者： Sherwin、刺激的なlightning roundに入る前に、何か補足することはありますか？リスナーに残したいことはありますか？まだ話していないが、役に立つと思うポイントはありますか？
Sherwin Wu： ただ一つ情報を残したい：今後2、3年は、テック界と起業界にとって長い間で最も面白い時期になるだろう、と思います。
私は皆さんに、それを当然だと考えないでほしいと勧めます。私は2014年に職場に入り、最初の2年はまあまあでしたが、その後約5、6年、テック界はそれほど「興奮」していなかったと思います。そして過去3年は、私のキャリアの中で最も興奮し、最もエネルギーに満ちた段階でした。
今後2、3年もこの状態が続くと思います。
だからそれを当然と考えないでください。いつかこの波は過ぎ去り、変化はより漸進的で、それほど劇的ではなくなります。
しかしこの期間に、私たちは多くのクールなものを探求し、多くの新しいものを発明し、世界を変え、私たちの働き方も変えるでしょう。これが皆さんに残したいことです。
司会者： この言葉がとても好きです、もう少し尋ねたい。あなたが「逃すな」と言うなら、具体的に何をすることを勧めますか？構築すること、受け入れること、学ぶこと、面白いことをしている会社に参加することですか？「この電車に乗り遅れたくない」と思う人たちにどんなアドバイスをしますか？
Sherwin Wu： 私はこう言うでしょう：それに関わりなさい（engage with it）。
基本的にあなたが言った通りです：それを受け入れなさい。その上にツールを構築することは、物語の一部です。しかし、たとえソフトウェアエンジニアでなくても、完全にそれを受け入れることができます：これらのツールを使いなさい。
多くの仕事が変わると思います。だからあなたはツールを使い、それが何ができ、何ができないかを理解し、その制限を理解し、そうすればモデルの進歩に伴って何ができるようになるかが見えてきます。
要するに：このテクノロジーに慣れ親しみ、後ろに反り返ってそれを通り過ぎさせないでください。
司会者： しかし逆に、多くのプレッシャーと不安があります：物事が多すぎて、どうやって追いつけばいい？今週はClawbotを学び、来週は別のものが出てくる……あなたは中心にいて、この「逃すことへの恐怖」にどうやって押しつぶされないのですか？どうやってペースを保ち、ニュースを追うのですか？
Sherwin Wu： 個人的には実際には悪い例です。なぜなら私は基本的に「常時オンライン」で：Xでは常時オンライン、会社のSlackでも常時オンラインなので、確かに多くの情報を吸収します。しかし、私ほど「中毒」ではない人たちを観察すると、重要なことが一つあると思います：ほとんどの情報は実際にはノイズです。
110％のものをすべて脳に通す必要はありません。正直に言って、一、二つのツールを選び、まず小さく始めるだけで、完全に十分です。
業界のペースがあまりにも速く、さらにXという製品自体のメカニズムが、非常にクレイジーなニュースペースを作り出し、非常に圧迫的で、非常に簡単に圧倒されます。
しかし、あなたは実際にこれらすべてをマスターする必要はありません。今起こっていることに参加するために。
Codexクライアントをインストールしてちょっと遊んでみるだけでも。ChatGPTをインストールし、内部の一、二つのデータソース――Notion、Slack、GitHub――に接続し、何ができ、何ができないか見てみるだけでも、私はすでに価値があると思います。
司会者： 自分自身に思い出させるために常に使うモットーはありますか？
Sherwin Wu： 自分に繰り返し言う言葉は：決して自分を憐れむな（never feel sorry for yourself）。
仕事と人生では多くのことが起こります。自分自身に陥らないように自分に言い聞かせること、そして常に自分には主観的能動性があり、自分自身を立ち上げられると信じること――これは私がよく自分に言い聞かせる必要があり、また他人にもよくこの言葉を言います。
参考リンク：
https://www.youtube.com/watch?v=B26CwKm5C1k
声明： この記事はAIフロントラインが整理したものであり、プラットフォームの見解を代表するものではなく、許可なく転載を禁じます。