AIの障壁を越える：OpenAIがLLMsをメインストリームの成功へ導くまで

AIの障壁を乗り越える：OpenAIのLLMがメインストリームの成功へ導くまで

なぜLLMOpsもMLOpsと同じ運命をたどるのか

私はML開発者ツール（MLOpsと広く分類される）が単独のビジネスとしての実用性について疑問を持ってきましたが、ほとんどの場合、私の見解が証明されました。主要な設計の欠如により、断片化された「マイクロ市場」が生まれ、非常に少ない価値が確保されました。これは、オープンソースの代替品およびクラウドベンダーが彼らのMLツールを無料で提供しているためです（インフラ層で収益を得るため）。では、なぜLLMがこれらの問題を打破し、ブレイクアウト的なメディアの注目を浴び、実際に普及したのでしょうか？また、MLOpsプレイブックを使ってLLMに復活を図ろうとするすべてのスタートアップに何が起こるのでしょうか？

この記事では、「革新の拡散」理論と「渓谷を渡る」概念を使って、OpenAIやAnthropicのようなLLMプロバイダーへの私の前向きな期待、およびMLOpsをLLMOpsとして復活させようとする試みへの私の慎重な意見を説明します。

革新の受け入れと渓谷

エベレット・ロジャースの「革新の拡散」によると、革新的な製品は異なる特徴を持つ採用者グループによって段階的に採用されます。リスクを取ることに意欲があり、失敗に対する高い許容度を持つイノベーターが新しい製品を最初に試します。変化を嫌う人たち（ラガード）は最後に採用します。有名なベルカーブ型のグラフは、各カテゴリの採用者の割合を示し、累積採用のグラフは革新の市場シェアの時間とともになじみのある「S曲線」のパターンに似ています。

基本的な考え方は、各グループが前のグループの信号や行動に影響を受け、新製品を採用する際に社会的な証拠に頼るということです。これは良く理解され、経験的に文書化された現象であり、ウィンドウACからiPhoneまで何にでも観察されます。

• 「Devtoolsを使ったRデータパッケージの作成と公開の詳細ガイド」
• 予めトレーニングされた基礎モデルは、分子機械学習の未来ですか？前例のないデータセットとGraphium機械学習ライブラリを紹介します
• 「Pythonデコレータ：包括的なガイド」

「渓谷」は、ジェフリー・A・ムーアの「渓谷を渡る」によって普及された概念で、ロジャースの理論を基にしています。ムーアは、初期市場と主流市場の違いが大きすぎて、ほとんどの製品がその「渓谷」を渡る試みで失敗すると主張しています。これは、テックスタートアップで一般的な失敗モードです。

ロジャースは「革新の拡散は「社会的なプロセス」であり、「隣接する採用者カテゴリ間に鮮明な切れ目や不連続性はない」と渓谷の概念を批判しましたが、明らかに多くの製品はイノベーターグループを超えることができないため、主流市場には到達しません。

ムーアは渓谷を渡る方法についていくつかの提案をしていますが、そのうちのいくつかには一部しか同意しません。彼の指摘の1つは、彼自身の言葉で言えば、彼の本は主に「市場開発の問題」として渓谷を扱い、「それを渡るためのマーケティング戦略と戦術」に焦点を当てているということです。彼は「全体的な製品管理」という考え方もカバーしていますが、セオドア・レヴィットの「The Marketing Imagination」の読解に基づいており、この概念は「マーケティングメッセージと製品の真実との間のギャップを「サービスと付帯品」と共に埋めることに限定されています。彼は実際の製品の進化には触れていません。実際、革新（コア製品）は一定のものとして扱われています。

ソフトウェアの特定の属性（特に開発者ツール）を考慮に入れると、「進化」と「スキップ」という2つの戦略を提案し、それらの適用がLLMの急速な上昇を後押ししたという仮説を立てます。

ギャップを回避するための2つの製品中心の方法

時間の経過とともに開発者ツールを進化（単純化）させる

製品が一定であり、メッセージング、配布、価格設定などの「全体製品」の他の側面が異なる採用グループにアピールするために変化する制約は、主に物理的製品によるものです。ウィジェットを生産・販売するビジネスを行っている場合、サプライチェーンを変更したり、工場を再設計することは容易なことではありません。しかし、これは純粋なソフトウェアの製品である場合はまったく異なる話です。ソフトウェア製品を進化させないことはほとんど常に失敗への道を歩むことを意味します。

ほとんどのソフトウェアスタートアップが今日始まる方法に基づいて、進化する必要性は明らかであるはずです。特にAI領域では、開発者ツールは特定の分野の専門家の強力で献身的なユーザーベースの中で生まれ、育まれます。これらの早期ユーザーは通常イノベーターであり、それゆえに一般的な市場を代表していません。創業者が全時間とエネルギーをこのセグメントに費やし、彼らのフィードバックに基づいて製品を微調整することは非常に容易です。残念ながら、商業的成功はほとんどその最初のグループで見つかりません。イノベーターは非常に洗練されており、しばしばビルドすることを優先し、買わないことを好む傾向があります。購入するとしても、十分な市場を代表するものではありません。

この問題への1つの解決策は、製品を時間の経過とともに異なるターゲットユーザー向けに進化させることです。よく設計された開発者ツールでは、これは新しい抽象化の層を導入することと/またはより広く使用される言語をサポートすることを意味します。以前の雇用主の例を使用すると、Sparkの持続的な成功は（少なくとも私の意見では）製品のサーフェスが連続的に単純化されることで広範なユーザー層（Early Majorityと言えるかもしれません）を引き寄せるという事実に部分的によるものです。SparkはRDD（Resilient Distributed Datasets）とScalaを主要なプログラミング言語としてスタートしました。そして、PySparkによるPythonの言語サポートを拡大しました（より広範なソフトウェアエンジニアに開放）、さらにDataFrameやSparkSQLのようなより簡単なAPIを導入しました（SQLアナリストへの開放）。最近では、SparkはPandas互換のAPIを追加しました（データサイエンティストへの開放）、そして「英語SDK」を使用したLLMsを導入しました（英語を知っている人なら誰でも使えるように開放）。もしSparkがこの方法で進化していなかったら、Scalaで複雑なMapReduceプログラムを書く方法を知っている専門家のイノベーターセグメントにとどまっていたでしょう。

この戦略はいくぶん明らかですが、多くの技術製品（特に開発ツール）はこれを正しく行いません。彼らは時にはいくつかのツマミを取り除いて「簡単に」製品をしても、透過性のない新しい抽象化の層を導入することに失敗します。

ギャップを完全にスキップする

開発者ツールではあまり一般的ではないもう1つのアプローチは、ギャップを完全にスキップすることです。考え方は見かけによらず単純です。早期市場での成功が自動的にメインストリーム市場での成功につながらないのであれば、なぜ直接早期多数派をターゲットにしないのでしょうか。

前述の通り、これはハードウェアにおいてより重要です。製品の改良が遅く、よりコストがかかり、その結果、コア製品が簡単に進化できないためです。iPhoneはそのような製品の素晴らしい例です。イノベーターからは頻繁に批判されますが（最近の例ではiPhone 15とその「失望的な」USB-Cポート）、早期多数派はこれらの技術的な詳細に関心を持ちませんでしたが、急速な成功を修得しました。実際、Appleは繰り返しメッセージ戦略でこの戦略を教えることがあります。おそらく最も有名な例は、「ポケットに1,000曲」キャンペーンで、これは技術仕様に関心のあるイノベーターではなく、早期多数派をターゲットにしていました。

多くのテックスタートアップにとって、これは不自然に思えるかもしれません（特に開発者ツールに焦点を当てている場合）それは、革新者や早期採用者との早期の成功を達成するのがあまりにも簡単すぎるからです。AI開発者ツールは、通常、先進的なAI研究者やMLエンジニアによって構築され、彼ら自身のために作られるため、実質的には早期市場から始まります。「GitHubスター」によって「製品のマーケット適合性」を証明するという実践は、この点を強化するだけです。

オープンソースプロジェクトを商品化するための一般的な失敗戦略

「オープンソースプロジェクトがスタートアップに変わる」という例を見てきたので、一般的な失敗パターンについていくつかのレベルの「パターン認識」を持っています。これらのスタートアップは、「GitHubスター」やPyPIのダウンロード数によって示されるような成長する採用を経験したときに、早期の成功（および資金調達）を得ます。しかし、彼らはしばしば同じパスを辿り、前回の会社が成功した理由が実際には理解できないため、「以前やったことがある」経験豊富な創業者がいる場合でも（彼らの前回の会社が成功した理由が実際には理解できないため）です。

革新者へのアップセル：直感的に（あるいは単純に）、ほとんどのスタートアップは最初に「管理された」オープンソース製品のバージョンで革新者にアップセルを試みます。この戦略は通常うまくいかないのは、革新者は定義から非常に洗練されており、ビルドすることを好みます。一般的な3S戦略（管理されたOSS+安定性、拡張性、セキュリティ）は、彼らに対してチェックを書くことを正当化するために不十分です。なぜなら、彼らはすでに自分自身でサービスのビルドと実行方法を知っているからです。革新者はまた、「ベンダーロックイン」や独立性を失うことを恐れています。

製品と市場のミスマッチ：次に試みるのは、同じ「管理されたOSS」製品を早期大衆に販売することです。通常は失敗します。なぜなら、中心となる提供内容は依然として革新者向けに最適化された使いにくい製品です。3Sを追加するだけでは、早期大衆をアップスキルするためのインセンティブには十分ではありません（MLエンジニアを数百万人育成してMLOps市場を形成する計画）。それだけでは不十分でなければ、最後の破綻は、このゲームでは誰もAWSに勝てないことです（そのため、インフラストラクチャのオープンソースプロジェクトがますます非商用ライセンスに切り替える理由でもあります）。

“全体製品”：この戦略を「全体製品」と皮肉った名称で呼んでいます。なぜなら、この用語は基本的な製品のギャップを最適でない手段で埋めるために誤用されているからです。通常、この試みは、大市場向けに製品が使用しにくすぎることに気付いた後に行われます。そして一般的には「問題に人を割り当てる」という解決策が含まれます。これにより、スタートアップの収益構造には高いサービス部分が含まれることになります（投資家はこのような状況を好みません）また、過剰な配信組織も生まれます。公平を期すために言いますが、これには一定量必要です。特に企業セグメントや政府セグメントでは。ただし、ほとんどの場合、スタートアップはテックコンサルティング会社のように見え始めます。

デベロッパツールのためのハイブリッドアプローチ

私が提案している戦略は、洗練されたユーザーベース（革新者）との迅速なイテレーションを許容するハイブリッドアプローチですが、製品定義における早期市場と主流市場の基本的な違いを認識することを明示的に重視しています。

オープンソースによる革新者への早期成功を証明することは、早期大衆向けの商業的な生存性を見つけると矛盾しないものです。なぜなら、それらは異なる製品が必要であることを認識するからです。具体的には、次のように提案します：

1. オープンソースプロジェクトを使って革新者の人気を獲得します。
2. その人気を利用して資金を集めます。
3. 革新者グループを活用して、彼らがどのように下流の価値を創造しているか、そしてそれを誰のために創造しているかを探ります。
4. 主流市場向けの目標製品をその対象視点に合わせます。

これは、ソフトウェアのイノベーション拡散がiPhoneなどの消費者向けハードウェアと異なる点です：鍵となる洞察は、ソフトウェアの価値チェーンでは、革新者がしばしば早期大衆への中継役（中間者）であるということです。言い換えれば、革新者自体が価値チェーンの終わりではありません。彼らは製品/ビジネスチームが価値を創造するのに技術を活用します。これは時には「エクセレンスセンター」や中央集権化された「イノベーションチーム」として具現化されます。テックスタートアップの目標は、これらの革新者の後ろにある価値チェーンに座っている人々を知ることです。そこに主流市場の鍵があります。重要なのは、存在する場所で革新者を排除しようとするのではなく、彼らを組織内の「チャンピオン」にする必要があるということです。

テックスタートアップの目標は、イノベーターの後に価値チェーンにいる人々を知ることであり、そこにアーリーマジョリティの鍵が見つかります。

「スキップ」戦略の主な意味は、製品の定義段階でアーリーマジョリティに対応するための明確な決定を行うことです。この「進化」戦略とは異なり、「メインストリーム製品」は単に元の製品の簡易版ではなく、まったく異なる形態を取ることもあります。この異なる形態の2つの極端な例は次のとおりです:

1. 元のOSSプロジェクトよりも抽象度の高い、異なる形態のもの。完全ではありませんが、Databricksはこれの別の例です。イノベーターグループの外で最初の関心を引いた画期的な製品は、「管理されたSpark」だけでなく、データサイエンティストやエンジニア向けの管理されたノートブック製品でした（当時、それはかなり斬新でした）。Databricksは、Databricks SQLなどの製品でも同じ戦略を今日でも続けています。
2. 価値チェーン上位でより焦点を絞った製品。Stripeは、最初にオープンソースの支払い処理ライブラリで始まり、その後、ウェブサイト向けの完全な支払いフォームであるCheckoutやPOS（販売時点）チェックアウト端末で成功を収めました。

MLOpsが進化に失敗し、LLMsがギャップを飛び越えた理由

MLOpsが早期市場で行き詰まった

Sparkの進化について共有したような似たようなストーリーは、MLについては語れません。MLOpsスタックは数年前とほとんど同じですし、市場ではますます多くのエンジニアがそれを使用するようになることを望んでいます。

ここにたどり着く過程について言及することなく、私の意見を簡単にまとめましょう:

• MLOps市場は、「主導的な設計」に収束しておらず、その結果、「MLOpsプラットフォーム」は明白または微妙な点で異なっています。
• システムレベルでは、MLOps市場はより単純な「形態」や抽象化のレベルを生み出しておらず、依然として非常に複雑であり、（データエンジニア、データサイエンティスト、MLエンジニアなど）いくつかの専門的な役割が必要です。これらの役割は、最も先進的な技術企業でのみ一般的です。
• このテクノロジーを消費できると考えられるオーディエンスであるイノベーターやアーリーアダプターは、ベンダーに支払いする代わりにオープンソースツールを使用することを好みます。
• ベンダーに支払いをする意向のあるオーディエンスは、通常、主要なクラウドサービスプロバイダーが提供しているものにデフォルトで移行します。クラウドプロバイダーは「MLプラットフォーム」レイヤーを無料で提供し、ストレージとコンピューティングの収益化に満足しています。
• クラウドベンダーはMLOpsを明示的に収益化していないため、この市場の価値捕捉は最小限にとどまっています。

要約すると、MLOpsはギャップに陥り、再び現れる兆しはありません。

LLMsのアーリーマジョリティへの魅力

そこで、LLMsが登場します。OpenAIは報道によると、年間売上高で13億ドルを超え、その成長は速いペースで続くと予想されています。これに対して、MLOpsのスタートアップの売り上げを合計してもほとんど及びません。クラウドプロバイダーの多くは、コンピューティングとストレージに対してのみ料金を請求しているため、「ML」の収益は実際にはカウントされません（大量の価格でクラウドインフラを提供するビジネスに入りたいかどうかは別です）。

そこで疑問になるのは、なぜLLMsが非常に早くメインストリームで成功を収めたのかということです。私は、彼らが非常に異なる2つのセグメントでギャップを成功裏に飛び越えたと主張します。

開発者セグメントでのギャップの飛び越え

従来の「識別的」なMLモデルは、売上リードの品質を予測したり、製品のリストをランク付けしたりするなど、非常に特定のタスクに向けて訓練されます。これらのタスクごとに、複数の専門家が一緒になってデータパイプラインを作成し、ラベルを収集し、いわゆる「特徴」を改善し、モデルを訓練して微調整し、評価し、展開し、パフォーマンスをモニターし、定期的に再訓練する必要があります。これを繰り返す必要性と必要な専門知識の量のため、この奇跡はわずかな選ばれた人々だけによって実現可能でした。

「生成的」言語モデルは、幅広いユースケースで「ただ動作する」のに対して、「応用AI」の分野における人材不足を一夜にして解決しました。APIを呼び出すことができる人なら誰でも、自分の製品や問題にAIを適用することができます。同じLLMは詩を生成したり、コードを書いたり、自然言語の質問をSQLクエリに変換したり、さまざまな標準テストをパスすることができます。これは「箱から出してすぐに」（ゼロショット）または問題を解決したいと思う例をモデルにいくつか示すだけで（フューショット）、テキストに限定されず、さまざまな形態に適用できます。

これこそが渡りに船の定義そのものです。

これがなぜLLMOpsが歴史を繰り返す運命にあるのかもしれません。ハンマーがあれば、どんなものでも釘に見えるからです。必然的に、自分自身のLLMをトレーニングして微調整する必要があるという考えに基づいた小規模産業が生まれましたが、それはLLMが最初から成功している理由の真意を見失っています。データのパイプラインを書き、モデルをトレーニングし、微調整し、展開するなど、複雑さを元に戻すことは、買う代わりに構築することを好むイノベーターのマイクロマーケットに再び入ることを意味します。

私が言っているのは、誰もが自分自身のLLMを微調整して展開するべきではないということではありません。非常に特定の状況（数少ない）では、そうすることが合理的です。しかし、それらの状況のほとんどすべてで、イノベーターと早期採用者のグループに属していることに気付くでしょう。そして、それらのグループは単にオープンソースのツールを使用してベネフィットのためにベンダーに料金を支払わないだけです。

消費者セグメントでのクリープをスキップする

OpenAIは2つの非常に異なるセグメントで活動しています。上記で述べた開発者セグメントは、APIと専用の計算能力で対応しています。一方、ChatGPTとそのモバイルアプリは非常に「消費者」向けの製品です。ChatGPTは、100万人のユーザーに到達するのに非常に速かった製品の1つとして知られています（5日間で）。OpenAIの収益の数字は公式には公表されていませんが、ある推定では、モバイルアプリからの収益が1か月あたり300万ドルとされています。まるで初期市場をゆっくりと成長する製品のようには聞こえませんね。

専門用語の名前（GPTはGenerative Pretrained Transformerの略）にもかかわらず、ChatGPTは、そのフレンドリーで使いやすい形態のおかげで、早期採用者の市場に直接進出しました。ジャーナリストから教師や学生まで、誰でも無料でアクセスし、すぐに価値を体験することができました。もしOpenAIが単にエンジニアがREST APIを通じて呼び出すことのできるモデルをリリースしていたら、これほどまでにメインストリームでの採用が生まれることはありませんでした。

ほとんどの経営者は、2つの大きく異なるセグメントに焦点を分散させることは一般的には良いアイデアではないと言うでしょう。しかし、私はChatGPTが消費者に向けた広範な成功が、開発者セグメントでの需要を喚起する上で重要であったと主張します。開発者や企業のバイヤーも人間です。彼らはニュースを読み、トレンドを追い、消費者向け製品を試したりします。OpenAIは、意図的であろうとなかろうと、これにいくつかの恩恵を受けました。

• 最も明らかなのは、認知度とブランド認知はどのビジネスにとっても重要です。OpenAIとLLMsは、AI業界内では既によく知られていましたが、ChatGPTがサービスの広範な開発者セグメントのEarly Majorityに向けたブランド名になったのです。
• 「ギャップ」が存在する理由の1つは、Early Majorityが通常リスク回避をし、イノベーターからの信号を信頼しないことです。これを克服する方法の1つは、彼らに製品を簡単に体験させることです。ChatGPTは早期採用者の非技術的な意思決定者にとって完璧な「無料トライアル」体験を提供しました。
• OpenAIのように収益成長を実現する「一般的な」方法は、エンタープライズセールスチームを雇うことです。従来のSLG（Sales-Led-Growth）の動きは、製品の容易なアクセスを提供するという点で、体験するためのシームレスなアクセスなど、実証済みのPLG（プロダクトリード・グロース）の手法から大いに恩恵を受けています。エンタープライズバイヤーは、大規模な契約に踏み切る前に製品の価値を「見て体験することを期待するようになっています。

結論

私は、開発者向けのMLツールに関する前の投稿に自然な続編としてこの記事を始めました。LLMOpsのストーリーがMLOpsと同様に繰り返されていることに気付いたからです。しかし、LLMが渡り廊下をスキップした方法について書いていくうちに、その教訓がより広く応用できることに気付きました。

OpenAI、AnthropicなどのLLMプロバイダーの方々へ: これらの企業がこの戦略を偶然発見したのかどうかはわかりませんが、意図的に適用すると、製品開発とGTMの両方の改善に関する教訓が確かにあると思います。ただし、ハイパーグロースモードの場合は最適化にあまり時間や必要性がありません。

LLMOpsエコシステムの関係者の方へ: MLインフラストラクチャに関する私の以前の投稿を読んでいただき、この層での価値抽出はほとんどないと考えている理由がわかると思います。さらに、LLMの微調整が実際に意味を成すケースは非常に限られていると私は考えていますが、他の人々がすでにこれについて多くのことを書いています。

一般的なテックスタートアップの方々へ: OSSベースのスタートアップで巨額の資金調達ラウンドを見てきました。その仮説は、いずれにせよ「管理されたOSS + スケーラビリティ、安定性、セキュリティ」とか「オープンコアで、モノタイズは後で考えます」というものでした。私は「渡り廊下をスキップする」というアイデアがここでも価値があると考えており、創業者や投資家からのフィードバックを楽しみにしています！

この投稿で表明された意見は私自身のものであり、私の雇用主の意見ではありません。

Clemensは、過去8年以上にわたり、開発者や企業にAIを提供してきた起業家精神あふれるプロダクトリーダーです。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!