※本記事は、Y Combinatorが配信するポッドキャスト「Lightcone Podcast」の内容を基に作成されています。本エピソードには、Ollama(YC W21)の共同創業者兼CEOであるJeffrey Morgan氏がゲストとして登場しています。OllamaはAIモデルをローカルおよびクラウド上で実行するためのツールであり、900万人の開発者およびFortune500企業の85%に利用されています。同社のトークン流通データを扱う立場にあるMorgan氏は、実際にどのAIモデルが使われているか、そしてその状況がどのように変化しているかについて、独自の視点を持っています。
ポッドキャストの詳細情報は https://www.youtube.com/watch?v=rY0wnfFHYbs でご覧いただけます。本記事では、ポッドキャストの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのポッドキャストをお聴きいただくことをお勧めいたします。また、Y Combinatorおよび「Lightcone Podcast」の公式チャンネル、ならびにOllama(@ollama)の公式アカウントもご参照ください。
1. イントロダクションとオープンモデルシフトの全体像
1-1. ゲスト紹介
Host: 本日はLightconeにお越しいただきありがとうございます。今回お迎えしたのは、オープンソースのAIモデルをローカルおよびクラウド上で最も手軽に実行できるツールを提供するOllamaの共同創業者兼CEO、Jeffrey Morganさんです。Ollamaは900万人の開発者に利用されており、GitHub上で17万8000個のスターを獲得し、さらにFortune500企業の85%で使われています。つまりJeffreyさんは、AIの最先端がどこにあるのか、どのモデルがベンチマークで高い評価を得ているのか、そして開発者が実際に何をダウンロードし、使い続けているのかについて、誰よりも詳しい立場にいる人物だと思っています。Jeffreyさん、ようこそお越しくださいました。
Jeffrey Morgan: お招きいただきありがとうございます。
1-2. シフトを牽引する要因
Host: 早速伺いたいのですが、今の最先端の状況はどうなっているとお考えですか。実際に何が起きているのか教えてください。
Jeffrey Morgan: 私たちが見ている最大の変化は、特にエンタープライズにおけるオープンモデルへのシフトです。これは米国と中国、両方の系統のモデルが混在した動きであり、主にコーディングエージェント、そしてOpenClawやHermesのような、より協働的な働き方を実現するAIアシスタントによって推進されています。
1-3. Olama Cloudのトークン流通傾向
Host: あなた方は非常に多くのトークンの流れの中に位置しているので、実際にどのモデルが使われているのか、そしてそれがどのように変化しているのかについて、非常に良いデータをお持ちだと思います。具体的にどのような傾向が見えているのでしょうか。
Jeffrey Morgan: 私たちはもともと、MacBookをはじめとするNvidia、AMD、Intelなどのハードウェア上でオープンモデルを動かすための手段として事業を始めました。そして今年の初めにOllama Cloudをローンチしました。そこで見えてきているのは、現時点では主に中国原産のモデルが使われているということです。ただし、それらは世界中のさまざまな企業からアクセスされています。特に米国とドイツは、オープンモデルのトークンが多くアクセスされている大きな発信源になっています。
1-4. コストかカスタマイズか
Host: これはすべてコストの問題なのでしょうか。企業がオープンモデルに移行してくるのは、単純にコストを下げたいからなのか、それとも他に理由があるのでしょうか。
Jeffrey Morgan: コストは、オープンモデルが解決できる最大のペインポイントであることは間違いありません。ただ、どの企業も、AIをより良くコントロールし、自社の事業に合わせてカスタマイズしたいというビジョンを持っています。それこそが企業にとっての本当の北極星なのです。コストは短期的に解決できる問題ですが、それが解決されることによって、企業は次の段階として、自社の独自のユースケースに合わせてモデルをカスタマイズしていくことができるようになります。
1-5. AT&Tの事例
Host: 実際にこれを行っている大企業の名前を挙げることはできますか。
Jeffrey Morgan: 昨日The Informationに非常に良い記事が出ていたのですが、AT&Tはすでにトークン消費量の40%をオープンモデルへ移行しているそうです。現時点ではこれは主に米国とヨーロッパ系のモデルを通じて行われていますが、同時に中国系のモデルも評価しているとのことです。
Host: 具体的にはどのようなワークフローで使われているのでしょうか。
Jeffrey Morgan: 主にコーディングエージェントです。開発者一人あたり、あるいはユーザー一人あたりのトークン使用量の極端な成長を見てみると、そのほとんどはコーディングエージェントに由来しています。そして今年の3月から4月にかけてOpenClawが急速に立ち上がり、その後Hermesエージェントプロジェクトも同様に立ち上がりました。これによって、開発者以外の人々、たとえば財務、サポート、マーケティング、セールスといった分野の人々も、長期間にわたる大量の作業を自動化できるようになったのです。
1-6. トークン使用量の爆発的成長
Host: OpenClawの立ち上がりについて、非常に興味深い指数関数的なグラフを見せていただきましたね。
Jeffrey Morgan: そうです。これは今年の初め頃における、Ollama Cloud上での開発者一人あたりの週間トークン使用量を示したグラフです。
Host: これは一人あたりの数値なんですね。全体の集計値だとばかり思っていました。
Jeffrey Morgan: [笑]その通りです。これは個々の開発者単位のものです。一人が週にどれだけのトークンを使っているか、ということを示しています。ここには大きな変曲点が二つあります。一つ目は年初の急上昇で、これはコーディングエージェントによって引き起こされたものです。Kimi、GLM系のモデル、MiniMaxがローンチされたのを見ました。ついにコーディングエージェントを動かせるだけの性能を持つオープンモデルが登場したのです。そして4月には、OpenClawの登場によって驚異的な成長が見られました。これによって、開発者だけでなく世界中の誰もが、難しい問題をオープンモデルに与えて、それを完了させるまで任せることができるようになりました。これは当然、モデルがどのツールを使うべきか、どのデータを取得すべきかを考える過程で、非常に大量のトークンを消費します。あわせて、コンテキストウィンドウも12万8000トークンから100万トークン以上へと拡大しました。これらすべての要素が、この爆発的な成長を可能にしたのです。この4月のOpenClawによる増加分だけで見ると、これらのコーディング系ユースケースが本格化する以前におよそ1500万トークン程度だった水準から、おおよそ5倍に成長したという規模感になります。
Host: それはOpenClawによる4月の増加分としては、規模感としてだいたい合っていると思います。
Jeffrey Morgan: 全体で見ると、当然ながら10倍から20倍、あるいはそれ以上になっています。クラウド全体を通して見ると、年初から150倍という成長を記録しました。ここで興味深いのは、オープンモデルに対するこの巨大な需要の急増です。2024年から2025年にかけては、大規模モデルとして提供されるオープンモデルは、ほとんどがカスタムモデルとして提供されていました。つまり、DeepSeekやKimiのような既製のモデルを取得し、それを自社のユースケースに合わせてファインチューニングするというやり方です。例えばCursorが有名に行ったように、そこから大規模に提供していくという方式でした。しかし、そのまま箱から出してすぐに使えるオープンモデルが提供されるようになったのは、実は今年初めから本当に始まったことなのです。
2. モデル開発サイクル・安全性・デイゼローンチの舞台裏
2-1. ファインチューニングのサイクル論
Host: このポッドキャストを始めた頃からずっと感じていることなのですが、こうした話にはサイクルがあるように思います。2024年の初め頃は、自分専用のカスタムモデルをファインチューニングすることに大きな関心が集まっていました。しかしそれはやがて下火になり、どうせ次のモデルリリースに踏みつぶされてしまう無駄な努力だ、というような空気になっていきました。それが今また戻ってきているように見えます。あなたはその全体を最前列で見てきたわけですが、私たちはまた同じサイクルを繰り返しているのでしょうか、それとも今回は本当に定着するのでしょうか。
Jeffrey Morgan: モデルのリリースの頻度そのものが加速し続けていると思います。これは、その頻度に追いつき続けることをますます難しくしています。
Host: つまり、最新のクローズドなフロンティアモデルの方が、これまで以上に速いペースでリリースされているということですね。
Jeffrey Morgan: オープンソース側でも、リリースはどんどん速くなっています。この夏だけでも、DeepSeek Flashモデルは既に3回のイテレーションを経ています。これは以前であれば、もっと6か月サイクルに近いものでした。
Host: つまり、クローズドモデルとオープンモデルの間のギャップが縮まりつつあるということですね。
Jeffrey Morgan: 縮まってきています。そしてそれによって、カスタムモデルを訓練することはむしろ難しくなっていると思います。一方で、ツール側は良くなってきているので、モデルをファインチューニングしたいチームがそれに追いつき続けられるようにはなっています。
2-2. AI安全性・セキュリティの論点
Host: 私たちは今、フロンティアラボにおいてAIの安全性がますます大きな課題になっている局面にも入っています。フロンティア側は、アラインメントや制御の問題を解決するためにスピードを落とすかもしれません。その間にも、オープンソースやオープンウェイトのモデルは成長を続け、性能を上げ続けているわけですよね。
Jeffrey Morgan: そうですね。私たちはGLM5.3モデルの発表とそのリリースを見ましたが、サイバーセキュリティの観点からその能力は非常に印象的でした。これは、スタートアップであれ既存企業であれ、セキュリティおよびガバナンスの領域に飛び込んで支援するための大きな機会を生み出しています。先ほど触れたAT&Tの記事を見ても分かるように、オープンモデル導入の最大のブロッカーは、大きく言えばセキュリティと安全性の問題にあります。ただ、私たちが顧客と話している経験から言えば、それがヨーロッパであれ米国であれ、安全性の問題を解決できるのであれば、中国原産のモデルラボを採用することは完全に選択肢に入ってきます。そしてこれはビジネスにとって非常に刺激的なことです。
Host: 今、興味深い局面にありますね。Hugging Faceは、フロンティア側から来たハッキングを検知するために、実際にオープンウェイトモデルを使わなければならなかったという出来事もありました。
Jeffrey Morgan: よくいただく質問の一つに、オープンモデルがクローズドなフロンティアモデルに対して圧倒的に優位に立てる用途はどこか、というものがあります。その代表例の一つがセキュリティテストです。自社のソフトウェアが本当に安全かどうかを確認する用途ですね。
Host: そうですね。Claudeにあなたのプロダクトへのペネトレーションテストをやらせようとしても、基本的には拒否されてしまいます。
Jeffrey Morgan: おっしゃる通りです。大抵の場合はそうなります。一方で、Hugging Face上には、いわゆる検閲を解除された、いわゆる「obliterated」なセキュリティ研究者向けのモデルが実際に存在しており、それを使えばそうした作業を行うことができます。
Host: それは本当ですね。攻撃を仕掛けるという目的のために、より積極的にカスタムトレーニングされたモデルも存在します。
Jeffrey Morgan: ただ、箱から出してそのまま使えるモデルであっても、安全性に関する訓練は組み込まれています。それらのモデルは、あなたがそれを良い目的、つまり正当な用途のために行っているのか、それとも悪意のある目的のために行っているのかを、以前よりも多少うまく理解できるようになってきています。
2-3. デイゼローンチの舞台裏
Host: あなた方は主要なモデル開発者にとって重要な配信チャネルなので、モデル開発者は一般公開の前にあなた方に連絡を取り、ローンチのタイミングを調整することが多いのではないかと思います。そのため、これから何が起きるのかを事前に垂れ見ることができる立場にいますよね。新しいモデルがリリースされたときの急激な成長スパイクも経験しているはずです。これを大規模に運用するというのは、実際どのような感じなのか教えてもらえますか。
Jeffrey Morgan: もちろんです。先ほども申し上げたように、モデルはますます速いペースでリリースされるようになっています。そこで私たちは、成功する「デイゼロ」のモデルローンチとはどのようなものかというプレイブックを作り上げてきました。正しく行うべきことはたくさんあります。まず、そのモデルが自分たちの好みの推論エンジンでサポートされていることを確認する必要があります。これは一般的に、速度が十分か、精度が十分か、リファレンス実装と仕様が一致しているかを確認するための、複数週間にわたるプロセスになります。次に、開発者やユーザーがそのモデルを活用するための適切なユースケースやハーネスを見つける必要があります。一般的に、こうしたモデルには新しい能力が搭載されています。実際、今日の朝にはDeepSeekが最初のマルチモーダルモデルを発表しました。それまでは比較的小さなOCRモデルしか持っていませんでしたが、これによって多くの新しいユースケースが解き放たれます。同時に、Deep Seekのハーネス自体も最近リリースされ、この新しい能力をサポートできるように変更されました。したがって、二段目のステップは、このモデルを実際に効果的に動かせるようにハーネス側を整えることになります。ただ、モデルごとに事情はまったく異なります。それぞれ異なる課題やアーキテクチャの変更、ツール呼び出しの仕組みを持っており、そのすべてを正しく整えるのは本当に難しい作業です。最終的に最も重要なのは、リリース前に最終製品に対してベンチマークを実行し、そのラボの研究チームが規定した仕様どおりに動作していることを確認することだと思います。
Host: つまり皆さんが担っている重要な役割の一つは、新しいモデルや新しいツール呼び出しのそれぞれについて、ハーネスを使うための最良の方法に関する、非常に明確な標準を作り出すことなのですね。それをすべての異なるモデルにわたって一貫させるというのは、かなり難しいことだと思います。
Jeffrey Morgan: そうですね。私たちが実際にパッケージとしてまとめようとしているものは、大きく三つあると思います。一つ目はハーネスです。既製のハーネスであったり、そのモデルを使うためのSDKであったり、このモデル専用に設計された既存のハーネスであったりします。今は本当に素晴らしいオープンソースのハーネスが数多く存在していて、たとえばcodexのハーネスもオープンソースになっていますし、OpenCodeも素晴らしい例の一つで、Ollamaユーザーの間で最も人気のあるハーネスの一つです。一段目としてそこを正しく整える必要がありますが、次にそれをモデルと一緒にパッケージ化し、利用可能であること、信頼性があること、そしてクラウド上であれば十分なキャパシティがあることを確認しなければなりません。というのも、デイゼロは当然、最大の成長を記録する日になる傾向があるからです。そして重要なのが、ハードウェアとプロバイダーです。ここには多くの協業の機会があります。推論プロバイダーがモデルを最適化する場合もあれば、Nvidiaのようなパートナーと組む場合、あるいはApple Siliconのスタックと組んで、モデルが実際に非常に速く動作するようにする場合もあります。というのも、モデルの性能が高くても動作が非常に遅ければ、それは良い体験にはならないからです。この三つの要素をひとつのパッケージとしてまとめるわけですが、モデルへのアクセスが数週間前から得られるのであれば幸運な方です。実際には、この作業の多くはモデルがリリースされる直前の24時間の間に一気に行われることになり、基本的には毎回「ファイアドリル」のような状態になります。
Host: つまり、かつてのオペレーティングシステムの世界のように、すべてのドライバー、すべてのハードウェアと非常に密接に統合し、さらにアプリケーションレベルでもすべてのアプリがしっかり調整されるようにする必要があるということですね。あなた方がそのすべてをつなぐ「糊」の役割を果たしているわけですね。
Jeffrey Morgan: OSというアナロジーは一般的には使い古された比喩だとは思いますが、これは良い例えだと思います。ハードウェアとプロバイダー、推論レイヤーのためのドライバーがある一方で、アプリケーションランタイムもあり、ハーネスが機能することを確認する必要もあります。それらすべてを糊付けするのは、組み合わせの数として非常に大きな問題です。だからこそ、それをうまくやるのは本当に難しいのです。ただ、時間をかけることで、それを素早く開発し、テストし、リリースできるようにするための仕組みを作り上げていくことができます。そして、どのハーネスとどのモデルの組み合わせにも対応できる、共通のランタイムのようなものを持つことができるようになります。これこそが、私たちが開発者に対して実際に担っている役割だと思っています。
3. モデルスタックの再構成とチームの技術的背景
3-1. Olamaチームの技術的背景
Host: あなた方は本当に骨太なエンジニアで、Apple Siliconの起源からDGXに至るまで、あらゆるレイヤーをチューニングしていますよね。そのような深い技術力のあるチームを、どうやって築いてきたのでしょうか。
Jeffrey Morgan: 私たちのチームの多くは、実はAI研究者としての背景を持っているわけではありません。VMwareやDocker、あるいは他のネットワーキング企業から来た人間が中心です。ですから、古典的なコンピュートの問題が、推論の世界において形を変えて再び現れているという感覚があります。そして基本的に、私たちはそこに時間をかけて注力するようにしています。ただ、最終的にはすべてが、開発者体験に行き着くと思っています。開発者がAPIを呼び出して、トークンが返ってくるとき、実際に何が起きているのか。今、そのレイヤーではますます多くのことが起きています。そこを正しく実現するには、スタックのすべてのレイヤーがうまく協調して動く必要があります。オープンモデルにとっての課題の一つは、フロンティアモデルラボが実現しているようなスピードで、それが実現できていないことだと思います。フロンティアラボには、Jensenが言うところの古典的な「5層のケーキ」、つまりアプリ、モデル、インフラと推論、チップ、そしてエネルギーという構成が、開発者向けにデイゼロの時点で既に整っています。私たちが実現しようとしているのは、まさにそれをオープンモデルのために再現することです。もちろん、私たちがスタックのすべてのレイヤーを自分たちでやるわけではありませんが、それをオーケストレーションする手助けはできます。
3-2. モデルスタックのレイヤー再編論
Host: レイヤーを積み重ねるということですね。オープンモデルの世界では、5層以上のレイヤーがあるのかもしれませんね。モデルのレイヤー自体にも、実はかなり多くの要素が含まれていますよね。
Jeffrey Morgan: そうですね。モデルのウェイトそのものだけでなく、それぞれのモデルが独自に得意とするオーケストレーションのコンポーネントも数多く存在します。開発者向けのAPIレイヤーもありますし、モデルとアプリケーションレイヤーの間には、今日のいわゆる「5層ケーキ」のスタックの中に隠れている、実に多くの構築の機会が存在しています。
Host: それは興味深いですね。そうした隠れたレイヤーの一部が、いずれアンバンドルされて、独立した企業やプロバイダーになっていく可能性はあると思いますか。
Jeffrey Morgan: 間違いなくあると思います。Anthropicのプラットフォームチームのメンバーによる非常に良い講演を聞いたことがありますが、彼らは大きく三つのことについて話していました。一つ目は知識です。自社のデータやコンテキストをどうモデルに接続するか、という問題です。二つ目はコーディネーションです。たとえば、クラウドアプリやCodexにリクエストを送ると、そこから多数のサブエージェントが立ち上がり、その一部はクラウド上で、一部はローカルで動作します。そこにはコーディネーションの問題があります。そして最後に実行の問題があります。私たちはこれをよくサンドボックスという言葉で語りますが、こうしたエージェントはますますクラウドへ移行しつつあり、そこには解決すべき巨大なコンピュートの問題があります。過去のクラウドビジネスの歴史を振り返ると、オープンソースの世界では、それぞれの問題に対して「ベスト・オブ・ブリード」の企業が存在するようになってきました。かつての世代のクラウドプロダクトを振り返ると、HerokuやGoogle App Engineのようなものは、すべてが一つにバンドルされていました。しかし、開発者たちが最終的に好んだのは、それぞれの問題に対して最良の単一プロダクトを選ぶという形だったのです。
Host: これはまさに、バンドル化とアンバンドル化がすべてを支配しているという法則ですね。フロンティアモデルラボは、完全に管理されたエージェントやコンテキスト、メモリレイヤーを含む、彼らの城壁の中に開発者を閉じ込めたいと考えています。一方で、その他の小さな技術者たちや、あらゆるファウンダー、オープンソースの開発者たちは、そこに閉じ込められたくないので、別のものを作ろうとしている。最終的にどちらが勝つのかは興味深いところですね。おそらく両方が混ざり合うことになるのでしょう。
Jeffrey Morgan: 私もそう思います。今、オープンモデルのトークンは非常に豊富に生成されるようになっていて、それらのトークンを提供できるオープンモデルプロバイダーも何十社と存在しています。今、新たに希少になっているのは、トークンの上に何を構築するかという部分です。つまり、エージェントをどのようにAからBへオーケストレーションするか、という問題です。ここには、新しいシステムやエンジニアリング上の課題が数多く存在していて、それらは個々の開発者にとって解決するのが非常に難しい問題です。とても、彼ら一人でそのすべてのレイヤーを構築することはできません。
Host: ただ興味深いのは、コーディングエージェント自体がどんどん良くなってきていて、事実上、今がこれまでで最も性能の低いモデルだということでもあります。かつてこの分野に堀があった大きな理由は、適切にテストされ、ユーザーの要求を本当に満たすようなソフトウェアを、きちんと保守し続けることが非常に難しかったからです。もしその前提が崩れたらどうなるでしょうか。今、私たちはまさに、あるMarkdownファイルとちょっとしたTypeScriptを走らせるだけのcronで十分になってしまうかもしれない、という局面にいるように思います。もはやロックインは存在しないかもしれません。ある日はOpenAIのメモリシステムを使い、次の日には自分自身のメモリシステムと常に同期させるエージェントを使う、というようなことが、MCPを介して問題なく実現できてしまうかもしれません。ランタイムのテストも十分にあり、ロックインが存在しない世界です。
3-3. ハーネス統合とロックインの消失
Jeffrey Morgan: そうですね。今日私たちが「ハーネス」として認識している機能の多くは、いずれモデル自体の中に取り込まれていくと思います。ただ、モデルのコアループやフックの多くをモデル自体に押し込んでいく一方で、逆に外に出てくる部分も存在します。メモリはその良い例です。私たちが使っている基本的な判断基準は、それがストレージを伴うようなステートフルな問題であれば、それは最終的にモデルレイヤーには入り込めない、というものです。モデルは訓練されたものであり、ご存知のとおり今では訓練は月次で行われるようになっていますが、それでも最新のデータには追いついていません。ですから、データを保存するということ自体は、モデルレイヤーに落とし込まれることは決してないだろうと思う、非常に大きな問題領域なのです。
Host: 認証情報の管理のようなものも同様ですか。
Jeffrey Morgan: セキュリティ認証情報や安全性に関するものも同じです。オープンモデルには、クローズドなモデルプロバイダーが箱から出してすぐに提供してくれるような安全性のツール群がすべて揃っているわけではありません。しかし、それは特に企業がこれらを導入する上で非常に重要な要素になります。
4. 企業内でのオープン/クローズドモデルの使い分けとローカル・クラウドの関係
4-1. 企業内の予算バランス論
Host: ここでちょっとセンシティブな質問をしたいのですが、エンタープライズにおける将来の姿、フロンティアのクローズドモデルとオープンソースモデルのバランスの行き着く先について伺いたいです。特に支出の面でですが、最初のうちは、みんなが予算のすべてをAnthropicやOpenAIに割り当てているだけのような状況でした。今の私の感覚では、確かにオープンソースは明らかに成長していますが、同時にAnthropicへの支出も伸びていて、両方が一緒に成長しているように見えます。これはこのまま続くのでしょうか、それとも、たとえば予算の半分がクローズドなフロンティアモデルに、残り半分がオープンソースに、というような何らかのステディステートに落ち着くのでしょうか。
Jeffrey Morgan: 私たちの見立てでは、企業内におけるトークンの超多数派はオープンモデルになると思っています。ざっくり言えば80%から90%くらいです。ただ、それは予算の89%がオープンモデルに使われるということを意味しません。実際、オープンモデルのコミュニティが素晴らしくやっていることの一つは、コストを下げてより手に入りやすくすることです。ですから、コストとしてはオープンモデルに対して10%から20%程度しか支払わないかもしれませんが、トークンとしては大部分がオープンモデルを経由して流れることになるでしょう。これによって、トークンが豊富にあることを背景に、さらに多くのユースケースが可能になります。チームのトークンアクセスを取り上げることを考えるのではなく、むしろどんどんアクセスを増やしていくことになります。最も難しいタスクについては、最良の研究者が集まっているフロンティアラボのために残されると思います。そしてその中間には、オープンモデルとクローズドモデルが組み合わさって動くような、たくさんの問題領域が存在することになるでしょう。
Host: これは面白い考え方ですね。モデルがどんどん強力になっていくにつれて、理想的には、いつオープンモデルに処理を任せるべきかを、自分の最も賢いモデルに判断させて委任したくなるはずです。ただ、モデルを所有しているラボ側は、そのようなことをユーザーが望んでいるとは想定していないように思います。
Jeffrey Morgan: この点について、私はすべてのラボが実は一つの点で一致していると思っています。それは、どうすれば顧客にサービスを提供できるか、という点です。そして最終的には、それを決めるのは顧客だと思います。ルーターがあって、スケジューリングやより難しいオーケストレーションの一部がフロンティアモデルを通じて行われるのであれば、それはそれで構いません。ただ、多くのライン単位の作業はオープンモデルを通じて行うことができますし、この二つの協業には大きな可能性があります。Sakana AIやOpenRouterなど、この二つを組み合わせて非常に良い結果を出しているプロジェクトを数多く見てきました。
Host: これは人間の組織とそれほど違わないですね。たとえば法律事務所を考えると、パートナーがいて、アソシエイトが大勢いて、パートナーがアソシエイトに仕事を割り振っていく。まさに同じ構造ですね。
Jeffrey Morgan: 私たちはクラウドコンピューティングでも同じことを見てきました。それは実際にはプロプライエタリなソフトウェアとオープンなソフトウェアの混合でした。一部はクラウドプロバイダー自身が提供していたものです。たとえばAWSは、彼ら独自のスケールアウト型データベースであるDynamoDBを持っていました。しかし多くの顧客は、それをPostgreSQLと組み合わせて使っていました。結局のところ、顧客は両方を組み合わせて使うことになる、というのが私たちの見ているものです。
Host: これはとても一般的なパターンだと思います。Apple Siliconがより優れている理由も同じ設計思想によるものです。画像処理と音声処理のように、異なる種類のワークロードのために特化したアクセラレーターを用意する。これはPC時代にさかのぼれば、単体のオーディオカードとグラフィックカードが分かれていたのと同じ発想ですね。
4-2. ローカル対クラウドの使い分け
Host: Apple Siliconの話が出たところで、ローカルモデルについても話しましょう。あなた方は、クラウドでホストされたモデルと、ラップトップ上でローカルにホストされたモデル、両方のビジネスを大規模に手がけているという、かなり独特な立場にいます。その二つの世界で何が起きていて、これから何が起こると考えていますか。
Jeffrey Morgan: これは非常に刺激的だと思っています。クローズドかオープンかという問いと似ていて、私たちの見立てでは混合になっていくと思いますし、実際に顧客からもそのように聞いています。より簡単なタスクについては、レイテンシがより低く、そしてトークン単価も当然より低いローカルで実行できます。ハードウェアは最終的には先行して購入するものですから、それをクラウドモデルと組み合わせて使うことになります。この次世代のハードウェア、これはすでに数年前から手に入るようになっているものですが、興奮させられるのは、200億から400億パラメータの範囲のモデルを動かすのに、それらがどれほど優れているかという点です。時には1280億パラメータまで動かせることもあります。
Host: Qwen3の38Bモデルは、今ではコーディングにおいてOpus 4.6と同等の性能があるとのことですが、それは本当ですか。
Jeffrey Morgan: ベンチマークではそう示されています。
Host: それは非常にすごいことですね。最低メモリ構成のMacBookではなく、その一段上のメモリ構成のMacBookでそれを動かせるということですから、まさに驚異的です。
Host: 実際にユーザーがそのように使っているのを見ていますか。どのモデルを使っているかという観点から、実際にローカルモデルとクラウドでホストされたモデルを、実務でどのように使い分けているのが見えていますか。
Jeffrey Morgan: ローカルで動かすモデルについては、米国系と中国系のモデルがかなりしっかりと混ざり合って使われています。もともとのLlamaのモデル群はもちろん素晴らしい選択肢ですが、DeepMindのGemmaモデルも同様に、ローカル用途として非常に良い選択肢です。ただ、実際のユースケースに落とし込むと、コーディングエージェントについては、大規模なクラウドモデルの方が概して効果的です。これは非常に難しい問題を解いているからで、コードを書き、テストを書くというのは本当に難しい作業です。それに対して、文書処理系のワークフローのユースケースは、エンドツーエンドで見たときにそこまで難しいタスクではないため、ローカルで非常によく機能します。ですから私たちは、より簡単で単純なタスクはローカルで実行され、それに加えてルーターが判断して、大きなクラウドモデルに送る必要があるタスクを振り分けるという、ハイブリッドな実行モデルが形成されているのを見ています。そして、これが顧客にとって意味することは、オープンモデルに移行することで、コストをさらに下げられるということです。それはクラウドで動かす方が安いからというだけではなく、どのみち自社のビジネスのために購入しているハードウェア上で、実質的に無料でそれらを動かせるようになるからです。今クラウドのコーディングエージェントモデルとして最も多く消費されているのは、圧倒的に中国系のモデルです。一方でローカルモデルについては、米国、ヨーロッパ、そして中国原産のモデルが、かなりしっかりと混ざり合った状態になっています。
Host: この二つのグラフを比較すると、本当に驚かされます。ローカルモデルでは米国系と中国系のモデルがほぼ横並びで、まさに互角です。ところがクラウドでホストされたモデルになると、まるで米国系がx軸から消えてしまったかのように、ほぼ100%が中国系モデルになっています。基本的に、私たちにはもっと大規模モデルを作る米国のラボが必要だ、ということをこのグラフは示しているのでしょうか。
Jeffrey Morgan: 実質的にはそういうことだと思います。ただ、Nemotron Ultraモデルのローンチによって、その最初の波が来ているのを私たちは見ています。これは非常に刺激的なことです。Nvidiaという会社が非常に興味深いのは、彼らの堀は、新しいソフトウェア事業を立ち上げることや、トークンを販売することにはない、という点です。彼らはむしろ、オープンソースを数多くリリースし、エコシステムを支援することに強い関心を持っているように見えます。そしてそれを行うことによって、彼らはハードウェアの側で優位性を保ち続けることができているのだと思います。
5. 次世代ハードウェアとコスト効率の進化
5-1. 次世代ハードウェアの動向
Host: Nvidiaという会社は、そうしたオープンモデルのエコシステムを支えるハードウェアの部分で、本当に面白い立ち位置にいますよね。GB300を搭載したDGX Stationのような新しいコンピューターの話も出ていましたが。
Jeffrey Morgan: そうですね。最終的にNvidiaが本当に素晴らしいのは、ハードウェアだけでなく、モデルそのものも含めて、オープンモデルを取り巻くエコシステム全体を支えていることです。これはGTCの場でのことでしたが、私たちはElonをはじめとする数名の人々とともに、DGX Sparkを最初に受け取った人間の一人になりました。これはデスクの上に置いて使うもので、200億から1200億パラメータの範囲のモデルを動かすために、128GBの統合メモリを提供してくれます。ただ、これはあくまでこれから広がっていく新しいハードウェアの範囲の始まりに過ぎません。
Host: これを何台か買って連結すれば、実際に400Bクラスのモデルを動かせるということでしょうか。
Jeffrey Morgan: 完全に可能です。非常に高速なネットワークリンクを備えているので、デスクの上に、まるで小型のデータセンターラックのように積み重ねることができます。
Host: Mac miniで同じようなことをしている人たちがいますよね。
Jeffrey Morgan: そうです。ただ今回のこれは、その本格的な量産版と言えるものです。AppleとNvidiaの両方から、これらのモデルのために作られた、そしてそれらを効果的に動かすための次世代ハードウェアへの、非常に大きな飛躍が見えているのが、今の興奮させられる点だと思います。
Host: では、これがApple Studioでもうまくいくようなワークロードでもあるけれども、本当に力を求めるならDGX Sparkを選ぶべき、というような話になるのでしょうか。
Jeffrey Morgan: 私たちの検証結果からすると、両方とも非常に競争力があります。ですから、どちらを選ぶかは、実際に何を手に入れられるか、そしてどのような技術スタックを求めているかによる部分が大きいと思います。AppleについてはMLXプロジェクトを通じて、非常に成熟した技術スタックが存在していて、Mac Studioはもちろん、より小型のMacでもLLMを動かすために素晴らしい仕事がなされています。もちろんDGX Sparkのスタックも同様に、本当に驚異的です。私たちはNvidiaのパートナーとして、これに強い期待を持っています。
Host: これは、パーソナルデスクトップにとっての一種のルネサンスになりそうですね。
Jeffrey Morgan: 私もそう思います。Ollamaのこれまでの歩みを振り返ると、面白いことに、私たちはローカルから始まりました。今、コーディングエージェントの需要は明らかにクラウド側にありますが、私たちの見立てでは、これはまた戻ってローカルになっていくと思います。ハードウェアが追いついてくるからです。デスクの上にGB300があって、最速のコーディングループを求めるとき、それはテストを実行するのと同じ速さ、あるいはコードエディタで変更を加えるのと同じ速さになるはずです。私たちは皆、GitHub Copilotが登場した頃、100ミリ秒程度の数ミリ秒の間にオートコンプリートが表示される体験を覚えていると思います。その体験は、いずれデスクトップの上に戻ってくるでしょう。ローカルから始まり、クラウドへ移行し、それがまたローカルに戻ってくるという歩みであり、最終的にはその両方を組み合わせて使うことになると考えています。
5-2. GPU調達の実情
Host: Olama Cloudを動かすためには、大量のGPUが必要になりますよね。GPU市場では今どのようなことが起きているのでしょうか。
Jeffrey Morgan: 私たちが見ているのは、価格が非常に速いスピードで変動しているということと、供給と需要のボラティリティが非常に高いということです。そのため、たとえばスタートアップの立場からすると、こうした最新モデルを動かすために必要なB200やB300といったGPUへのアクセスを確保するのは非常に難しいことです。幸いなことに、それを基盤にサービスを構築してくれている、優れた推論プロバイダー群が存在しています。私たちはこの領域で非常に大きな需要の高まりを見ています。
Host: 必要なGPUをすべて確保できていますか。成長のペースがGPUの確保できる量によって制限されている、という状態が続いているのでしょうか。今の状況を教えてください。
Jeffrey Morgan: 私たちは幸運にも、複数のプロバイダーと連携し、GPUをまとめて確保する体制を組んでおり、それによって需要に対応し続けることができています。ただ、それには大変な労力が必要で、どのモデルをどこで動かすか、どれくらいの速度にするべきか、どのリージョンに置くか、顧客にとってのレイテンシがどうなるかといったことを、常に考え続けなければなりません。そのスタック全体には、解決すべき難しい問題がたくさんあります。OpenRouterやOllama、OpenCodeプロジェクトのようなサービスが本当に素晴らしいのは、エンドユーザーである開発者が、B200やB300の価格交渉をしたり、24か月先の需要予測を考えたりする必要なく、こうしたGPUへのアクセスを、ただサインアップするだけで手に入れられるようになっている点です。
5-3. Flashモデルの台頭
Host: 仮にあなたがスタートアップの創業者で、まだ多くの資金を調達していないとしたら、そしてできるだけ多くのトークンを、できるだけ安く使いたいと思っているとしたら、限られた予算で大きな成果を出すために、どのようなアドバイスをしますか。
Jeffrey Morgan: DeepSeek Flashのような、トークン単価が非常に低い新しいクラスのモデルが良い例です。同様のモデルはこれからもっと増えていくと思います。これは1タスク当たりのコストが低いという点でも重要な指標であり、そのクラスのモデルが、私の考えでは「無制限のトークン」という発想に最初に到達するものになると思います。私たちはみな、ChatGPTの体験を覚えていると思いますが、あの頃はどれだけのトークンを使っているかをそれほど気にする必要はなく、ただ毎日使うだけでした。あれは、いわば無制限に使える体験でした。
Host: そうしたワークホースモデルが、いわば地味な作業のすべてを担うようになるということですね。
Jeffrey Morgan: その通りです。最終的にはそこに戻っていくと思いますが、そこに到達するには、モデルやアーキテクチャの側で、大量トークン使用向けにカスタムトレーニングするための、かなりの作業が必要になります。今年の初め頃を振り返ると、私たちはオープンモデルが知能のフロンティアに到達することを本当に望んでいました。実際にそのギャップは縮まり、フロンティアのクローズドモデルとオープンモデルの間の遅れは、おそらく3か月未満になっています。ただ、次に解決すべき問題は、極端な効率性です。たとえば、GPT-Lunaモデルが顧客にとって非常に価格効果の高いものになったことは、大きな追い風になりました。私たちが話をした多くの顧客が、こうした価格設定によって、チーム内での広範な普及が可能になったと話してくれました。オープンモデルにおいても、同じことが起きていくと思いますし、実際に既に起きています。DeepSeek Flashモデルがその流れをリードしていると思います。Olama Cloud上のモデル別の分析に戻ると、成長率が最も高い領域は明らかにDeepSeekのモデルであり、これは主にDeepSeek Flashの普及によって支えられています。この新しいクラスのFlashモデルは、タスクの80%に対して十分な性能を持ちながら、非常に高速で、非常に安価であるという特徴を持っています。この新しいクラスのモデルが、これまで解けなかった一部のユースケースを可能にしていくと思います。
Host: つまり、それらが地味な作業をすべてこなす、いわばワークホースモデルになるということですね。
Jeffrey Morgan: その通りです。何回リクエストを送ったか、何トークン使ったかといったことをあまり考えなくてもよくなり、むしろ、できるだけ多く消費しようという気持ちになります。それが、最も難しいというわけではないけれど、それなりに難易度のある問題を解決できるからです。先ほど話したコーディネーションのレイヤーに立ち戻ると、こうしたFlashモデルを協調させて異なるタスクを担わせることでも、大きなモデル一つに匹敵するような良い結果を生み出すことができます。こうした安価なモデルを持つことで、単にアクセスしやすくなるだけでなく、より高速に動作させることができ、より大量に利用することができ、さらにそれらを連鎖させることで、その上にオーケストレーションによって新しい問題を解決できるようになります。これは、新しいスタートアップにとっても、既存の推論プロバイダーにとっても、そして今日ワークフローの問題を解決している大企業にとっても、非常に刺激的な領域です。最終的に、こうしたモデルを連鎖させられるようになることは非常に有用であり、その裏側にあるコストについて考える必要はなくなっていくでしょう。
6. 「ゴッドモデル」対専門分散モデルの議論と地政学
6-1. 単一モデル対複数専門モデル
Host: 私たちがこのポッドキャストでAGIについて語り始めた頃、多くのAI研究者が、最終的には一つの巨大な「ゴッドモデル」がすべてをやることになる、という議論をしていたのを覚えています。しかし、これまでのところ、必ずしもそうはなっていないように思います。もちろん、本当にNSAをハッキングしなければならないような場面では、Mythosのようなものが必要になるのかもしれませんが、大多数のユースケースにおいては、あなたが話しているように、オーケストレーションであったり、より小さなモデルであったりが中心になっています。タスクを分割していくことで、実際には再現性が高まり、より信頼できるものになり、実際に実現可能なコストで動くようになる。つまり、「ゴッドモデル」なのか、それとも多数の専門特化型、あるいはもっと単純なモデル群なのか、という問いに対して、今のところは後者の方向に進んでいるように見えます。
Jeffrey Morgan: そうですね。多くの顧客のユースケースにおいては、あるレベルまで到達すれば、そのモデルは十分に良いということになり、顧客はその知能レベルをそのまま使い続けることができると思います。もちろんモデルは今後もっと速くなり、アーキテクチャも改善され、新しい能力も追加されていくでしょうが、それでも彼らは「ゴッドモデル」に手を伸ばす必要はないと思います。ただ、最も強力なモデルによってしか実現できないユースケースも存在していて、それは今後も続いていきますし、時にはそれが恐ろしいと感じられるようなこともあると思います。ただ、オープンモデルがいわゆる「ゴッドモデル」の一つになるかどうかについては、可能性はあると思っています。Zoo AIやGLMからは、実際にいくつかのタスクにおいてフロンティア級の性能を示す、非常に刺激的な進展が見られています。私たち全員が、Kimiモデルがウェブ開発において最良のモデルになった、という驚きを見てきました。あれは市場全体に新しい衝撃を与えました。それはもはやギャップの問題ではなく、正面からの競争の問題になっているということであり、それが物事をより刺激的にしていると思っています。
6-2. 地政学とモデルの出自
Host: これはちょっとセンシティブな質問なのですが、この点についての地政学的な側面について、あなたはどうお考えですか。
Jeffrey Morgan: この地政学的な側面の議論の多くは、まずそのモデルがどこの国のものか、というところから始まると思います。しかし、顧客やユーザーと時間を過ごせば過ごすほど、実際に重要になってくるのは、そのモデルがどのように実行されているか、どこで実行されているか、それが安全な環境で実行されているかどうか、といったことのほうだと感じます。ただ、もちろん米国の顧客が米国で訓練されたモデルを使えるということも非常に重要です。私たちが話をする顧客には大きく二つのタイプがあります。一つは、モデルがどこの出身であるかをそれほど気にせず、どこで実行されているかを重視するタイプです。しかし、そのそれぞれに対して、モデルがどこから来たのかを非常に気にするという顧客も存在しています。これは単なるセキュリティの問題というだけでなく、モデルがどのように話すか、という部分にも関わってきます。私たちはみな、モデルとやり取りをして会話をするわけですが、多くのモデルが、より機械的な口調になったり、より親しみやすい口調になったりと、様々な変遷を経ています。そうした部分も、実は非常に重要になってきます。ただ、最も優先度の高いポイントは、明らかに、そのモデルのデータがどこから来ているのかを、エンドツーエンドで理解できるようにすることだと思います。これはNemotronモデル群のように、そのモデルが何によって作られたのかを実際に検証できるという点で優れています。というのも、もしミッションクリティカルなタスクにモデルを投入するのであれば、実際にオープンモデルはミッションクリティカルなタスクのために使われていますが、フィンランドで発電所の異常な変動を検知するためにLlamaが使われている、という話がオンラインに投稿されていたのを見たことがあります。灯りを消さないようにするためです。そうしたクリティカルなタスクにおいては、モデルの出自が本当に重要になってきます。
Host: 米国内でホストされていたとしても、それが中国製のモデルであった場合、それがいわば仕掛けを施されていて問題を引き起こすようなものではないと、どうやって確認するのでしょうか。
Jeffrey Morgan: そうですね、いわゆる「マンチュリアン・キャンディデート」の問題ですね。
Host: そうです。実際にそうした既知の事例はあるのでしょうか。まさにその「マンチュリアン・キャンディデート」のようなケースが。
Jeffrey Morgan: 私が思いつく限りでは、そうした事例はないと思います。聞いたことがありません。もし本当にあったなら、私の耳にも入っていたはずだと思うのですが。ただ、報道記事のあまり目立たない部分に書かれていることとして、私たちが知っている大手企業、いわゆるFortune500に入るような企業のITおよびセキュリティチームが、実はこの問題に対して既にかなり手慣れているという事実があります。というのも、オープンソースソフトウェアという観点で見れば、平均的なアプリケーションには数千個の依存関係があります。これは決して新しい問題ではなく、たった一つの依存関係が、アプリケーション全体における重大なセキュリティ問題の原因になり得るということは、以前から起きていたことです。
Host: サプライチェーン攻撃、いわゆる依存関係の汚染というのは、本当に恐ろしいことですよね。
Jeffrey Morgan: それは実際に存在する問題であり、何十年も前からある問題であって、その意味では新しいものではありません。ただ、モデルの内部を直接掘り下げて確認することができないという点で、少し不透明になっているのは確かです。
Host: それは決定論的なものではないということですね。
Jeffrey Morgan: 決定論的ではないと言えますが、それでも、もしモデルを適切な安全性チェックによってきちんと精査するのであれば、少なくとも私たちが顧客から聞いている限りでは、それは解決可能な問題だとされています。
7. Olamaの創業ストーリーとピボットの歴史
7-1. 起源とピボット
Host: Olamaの起源について話してもらえますか。あなた方はDockerのエコシステムを通じてここまで来たわけですが、多くの視聴者は、あなたが今いるような、これからもずっと続いていくように見える、非常に強固なブランドの堀を持つポジションに憧れていると思います。まさに石油の大きな油田の上にたまたま立っていた、というような状況ですよね。掘り当てようとしている人たちのために、その物語を聞かせてもらえますか。あなたは実際に2021年、Jaredと一緒に仕事をしていたのですよね。
Jeffrey Morgan: そうですね。私と共同創業者は、以前Dockerに在籍していたときにDocker Desktopを作っていました。そこで、優れた開発者体験とは何かということについて、本当に深く理解する機会を得ました。ただ正直に言うと、Olamaという会社としての最初の数年間は、私たちが築き上げてきた「開発者にとって素晴らしい体験を設計する」という筋肉を、どの問題に対して使うべきかを探し続ける期間でした。
Host: あなた方は最初、まったく違うアイデアでYCに応募したんですよね。
Jeffrey Morgan: その通りです。
Host: 2021年冬のYCに応募したときのタグラインは覚えていますか。
Jeffrey Morgan: あまりはっきりと定義されていなかったと思います。私たちは、コンテナとKubernetesのための、本当に優れたデスクトップ体験を作ろうということに立ち返ったのだと思います。
Host: 私はあなた方が申請書に何と書いたか覚えていますよ。「Kubernetes向けのKitematic」あるいは「Kubernetes向けのDocker Desktop」というものでした。
Jeffrey Morgan: そうです。それは実質的にはDocker Desktopそのものでした。彼らには素晴らしいKubernetesがありましたから。二回目の創業者としての課題の一つは、私とMichaelがお互いによく話していることですが、私たちはあらゆる意味でアイデアを過度に考え込みすぎてしまう傾向があったということです。2021年にYCを経験してから、Olamaが2023年7月にローンチされるまで、シリーズAを調達した後でさえ、その2年から3年の間は、開発者を本当に喜ばせられる顧客課題を探し求める旅だったと思います。ある意味では、2023年までいくつもの異なるアイデアを試し、ピボットを続けたことは、むしろ良いことだったとも思っています。というのも、まさにその2023年に、Mama Llamaが登場し、オープンモデルの流れが始まったからです。
Host: それが「Olama」という名前の由来なのですね。
Jeffrey Morgan: 必ずしもそうとは限りません。「Llama」という言葉は、一般的にはオープンモデルそのものを指す言葉として使われていると思います。r/LocalLlamaというsubredditを思い浮かべる人も多いと思いますが、私たちが名前を検討していたときは、必ずしも既存の特定のモデルから取ったわけではありませんでした。
Host: LLMという言葉と、動物のラマを組み合わせたということですね。
Jeffrey Morgan: そうです。そして、そのキャラクター性を持たせることが重要だと考えました。名前にふさわしいキャラクター、顔を持たせられるようなものです。モデルの動物マスコットというのは時々ありますよね。DockerにもGitHubのクジラのキャラクターがありました。
Host: 彼はまだ、Olamaのイベントに本物のラマを連れてくるようにという私のアドバイスを聞いてくれていません。
Jeffrey Morgan: [笑]
Host: シリーズAのピッチについても伺いたいです。Benchmarkから資金を調達したのは素晴らしい投資家からだと思いますが、今私たちがいるこの未来は、2023年当時にはまだ本当には立ち上がっていませんでした。当時、ピッチや構想はどのようなものだったのでしょうか。
Jeffrey Morgan: 私たちは2022年にBenchmarkと組みました。ですから、時期としてはデリー(ChatGPT以前)の時代でした。ピッチの内容としては、私たちは優れた開発者体験を作ろうとしていること、このセキュリティの問題を解決しようとしていることに、かなりの重みを置いていたと思います。そして、私たちはBenchmarkのパートナーであるPeterのことを、以前のDocker時代から知っていました。彼はDockerのシリーズAの投資家でもあったからです。ですから、多くの部分は、人そのものと、私たちが何を成し遂げようとしているのかという部分に重みが置かれていました。Kubernetes向けのSSOを解決するということ自体は、正直に言えば私たちの本当の情熱の対象ではありませんでした。私たちは、その時点での特定の問題そのものではなく、私たちが本当に立っている姿勢や目指すものを見てくれるパートナーに出会えたことは、本当に幸運だったと思います。
Host: つまり、あなたがYCに参加したのは、いわばそのピボットの前の段階だったということですね。
Jeffrey Morgan: そうです。実は、Olama Cloudにおけるモデルファミリー別のトークングラフをちょうど見ていたのですが、このグラフだけを見ると、Olamaの物語は2026年の2月から始まって、そこから爆発的に伸びているように見えます。これは本当に面白いことです。というのも、実際には2021年までさかのぼる話だからです。何年もの間、いわば荒野で迷いながら、ある程度うまくいっているようで実はそうでもない、というような状態で働き続けるというのは、どういう感覚だったのでしょうか。それはあなたと共同創業者の心理、そしてチームや従業員にどのような影響を与えましたか。
Jeffrey Morgan: それは間違いなく恐ろしい経験でした。いくつか理由があります。一つは、開発者や顧客のために問題を解決しようとしていて、何度も何度も電話で話をしていても、それが完全にはうまくかみ合わない、という状態のときです。それは、自分たちが見出しに載っているかどうか、自分たちが作っているプロジェクトが本当に立ち上がっているかどうか、という話ではなく、本当に誰かのために問題を解決できているのかどうか、という話でした。荒野で迷っているとき、顧客というものは一般的には良い北極星になりますが、その北極星そのものが見えないというのは、もっと恐ろしいことです。というのも、解決したい問題そのものは分かっていても、どの問題なのかがまだ分かっていない、ということがよくあるからです。Michaelと私は、以前に一つの会社を立ち上げ、それが早い段階でDockerに買収されたという経験からこの会社を始めました。それは創業チームだけの話で、私たちの北極星は、開発者にとって、彼らが本当に難しいと感じているものに対して、素晴らしい体験を作ろうということでした。しかし、その問題を見つけ出すまでの2年間というのは、本当に恐ろしいものでした。当時、私たちのチームには10人以上のメンバーがいて、それによってこの状況はさらに難しいものになりました。私たちが違うアイデアを試している間、ずっと私たちのそばにいてくれたチームには本当に感謝しています。そして、あまり公には語られていないことですが、実はKubernetes向けのセキュリティから、デスクトップ上の開発者向けセキュリティへというピボットもありました。これはこれまで一度も話したことのないピボットです。そして、そのフォームファクターを、LLMが登場したときに転用しました。それは一つの跳躍ではありましたが、私たちは開発者がどのような問題を、どのような感覚を持って求めているのかを、ある程度分かっていました。ただ、LLMがそれを本当に明確にしてくれたのです。実際にLlamaのモデルを動かそうとしてみて、それが本当に大変だったときに、はっきりと悟りました。「これは問題だ」と。そして、それを実際に動かせたときの感覚は、非常に印象的で、まさにゼロからイチが生まれる瞬間のようなものでした。
Host: そのピボットの物語について、もう少し詳しく伺いたいです。Olamaの物語には実はいくつものピボットがあったと思いますが、おそらく最も重要だったのは、ローカルでホストされるLLMを手がけるというピボットだったと思います。それはどのように起きたのでしょうか。裏でこっそりアイデアを試していたのですか。そして、そのアイデアを見つけたとき、それが正しい選択だということは会社の全員にとってすぐに明らかだったのでしょうか、それとも大きな議論があって、実際に立ち上がるまではそれが明確ではなかったのでしょうか。
Jeffrey Morgan: 私たちは一緒に部屋に座っていました。トロントにいたことを覚えています。当時私たちのチームはトロントとパロアルトに分かれていて、今は主にパロアルトにいますが、そのとき私たちは、もしすべてを一度リセットして、今この瞬間からゼロから始めるとしたら何をするか、ということを話し合いました。私たちはユーザーと話をする中で、そしてオープンソースのLLMを自分たち自身で試してみる中で、二つの大きな問題を見出していました。一つは、どんなモデルにもアクセスできるようなゲートウェイを構築し、それを本当にシームレスにホストできないか、という問題でした。当時、私たちはこれを、LLM向けのSegmentのようなものだと考えていました。
Host: それは良い考え方ですね。今では、これがまだ始まりにすぎない、大きなルーターというアイデアになってきていますよね。
Jeffrey Morgan: そうです。そしてもう一つの問題は、私たちがVMwareやDockerの出身者ばかりのチームだったということです。私たちは物事を実際に動かす方法を知っていました。そこで、オープンモデルを実際に動かす手助けをしよう、ということになりました。
Host: システムの部分ですね。
Jeffrey Morgan: そうです、システムです。私たちはチーム自身を本当によく内省しました。もっと早くやっておくべきだったと思っていますが、というのも、セキュリティというのは開発者向けのツールとはまったく異なるチームであり、まったく異なる販売の仕方が必要だからです。そしてそれを行うことによって、私たちは「とにかくこれを試してみよう」という方向に自然と傾いていきました。私たちは自分たちに2週間という期限を設け、その期間内にLlamaの最初のバージョンをローンチしようと決めました。そしてまさにその2週間が終わるタイミングでLlama 2が登場し、私たちは「よし、ローンチしよう」と決めました。私たちには、まさに「行動へのバイアス」がありました。振り返ってみると、その2週間の中で、アイデアからローンチまで、そしてそれまでの何よりも多くのユーザーを獲得するところまで、すべてが起きたのです。それ以前は、率直に言って、顧客について、プロダクトについて、考えすぎるばかりで、何も世に出せていない2年間でした。
Host: 私が最初にそれについて知ったのは、実はRedditでした。あなた方だとは気づいていませんでした。あのロゴを見ていて、ただローカルモデルを動かすことに興味があっただけだったのですが、確かr/LocalLLMのようなsubredditで、みんながOlamaについて熱狂的に語っていたのを見た記憶があります。
Jeffrey Morgan: 「あ、これはYCの会社だ」と思ったんですよね。
Host: そうです。後になって気づいたんです。あなた方は当時、別の会社名で登録されていたので。私たちの社内システムには載っていなかったんです。[笑]
Jeffrey Morgan: そうですね。Jaredに会って「実は、あのセキュリティ関連の話があったんだけど、今こういうものを作ったんだ」と話したのを覚えています。
Host: あなたがJaredと話していたときに、私が階段でたまたますれ違ったんですよね。あなたがTシャツか何かのグッズを着ていて、私は「まるでロックスターに会っているような感覚だ」と思いました。
Jeffrey Morgan: このタイミングを狙ってやるのは本当に難しかったと思いますが、もっと早くその跳躍をしておけばよかったと思っています。実は、YCの期間中にそれをやるのが一番良いタイミングだったと思うのですが。
Host: それは不可能だった、まだ存在していなかったから、ということですね。
Jeffrey Morgan: その通りです。Llamaはまだローンチしていませんでしたから。
7-2. 急成長フェーズの実感
Host: あなた方は、GitHubプロジェクトとして最も早く10万スターに到達したものの一つでもありましたよね。どれくらいの速さだったか覚えていますか。かなり速かったですよね。
Jeffrey Morgan: 正確な速さは覚えていませんが、DockerやKubernetesよりもずっと速かったのは確かです。あなたが言うように、物事が実際に機能し始めて、立ち上がっていく感覚があって、創業者としては自分でもその理由をうまく説明できないまま、ただ驚いてしまうような状態でした。これがプロダクト・マーケット・フィットを説明する最良の方法だと思います。そして、プロダクト・マーケット・フィットにもいくつかの段階があります。私たちが実際にOlama Cloudで収益化を始めたのは今年の初めからにすぎませんが、人々がこのプロダクトに本当に惚れ込んでいく様子を見るというのは、まさにゼロからイチが生まれる瞬間であり、YCの期間中にそれを経験できていればよかったと思う一方で、ある意味それは不可能だったとも思っています。
Host: これは本当に驚くべきことだと思います。Redditで自宅にリグを組んで楽しんでいるような「変わり者」たちに興味を持たれていた状態から、2年ほどでFortune500企業の85%に使われるようになったわけですから。
Jeffrey Morgan: [笑]
Host: それはまるで、PCが普及するのに10年かかったホームブリューコンピュータークラブから広範な普及までの過程を、18か月か12か月くらいに圧縮したスピードランのようですね。
Jeffrey Morgan: そうですね。そしてそれこそが、私たちを最も驚かせたことの一つです。オープンモデルの最初のユーザーは、本当に単なる愛好家、ただ触って楽しんでいる人たちでした。「まさかこんなことができるなんて」という驚きだけがありました。しかし、非常に速く二つのことが起こりました。一つは、それらが無料で始められるということ、そしてどこでも動かせるということです。これはFortune500のITや開発チームにとって、信じられないほど助けになるものでした。というのも、彼らは使うために許可を求める必要がなかったからです。ですから、愛好家にとって良かったものが、非常に速くビジネス内の開発者にとっても良いものへと転じていきました。たとえば、MongoDBのような、開発者向けとして始まったデータベースが、非常に速くエンタープライズへも進出していったのと似た現象を、私たちも目にしています。ただ、LLMはステートレスであるがゆえに、その移行が非常に容易になったのだと思います。クラウドへ移行すると、その先にはより多くの検討事項が生まれます。経済性の問題がありますし、当然セキュリティの問題もあります。モデルはどこで動いているのか、という問題です。しかし、愛好家とIT開発者の両方が愛したオープンモデルの美しさは、まさに「ただ始められる」という点にあったのです。許可は必要ありませんでした。
8. マネタイズ・YCコミュニティ・組織づくりの教訓
8-1. マネタイズへの道のり
Host: マネタイズの角度についても話したいのですが、これも興味深いテーマです。2023年にLlama 2が登場して、突然多くのユーザーを獲得し、GitHubスターも10万に達して、明らかに何かを見出したことは分かりました。しかし、収益はまだゼロで、そこからどうやって収益を生み出していくのか、明確な道筋も見えていませんでした。実際に事業モデルを見出すまでには2年かかったわけですが、これは面白いことに、Dockerがちょうど同じ立場にいたのと同じ状況ですよね。その2年間、どのようにこの問題を考えていたのでしょうか。心配になりましたか。チームの中で、事業モデルはどうなるのか、という声は上がっていましたか。どうやって、これらの「Reddit上の変わり者たち」から実際にお金を生み出す方法を考え出したのでしょうか。
Jeffrey Morgan: 私たちが見ていたオープンモデルのマネタイズの方法は、大きく二つありました。会社にとっても、開発者にとっても、そして顧客にとっても良い形で収益化できる方法という意味です。一つはプライバシー重視のAIプロダクトで、実際にOlamaはそのオープンソース版の中で、まさにそこから本当のスタートを切りました。ただ、私たちは常に、あるモメンタムが来る瞬間があると感じていました。というのも、Llamaのモデルが登場したとき、それらはツールコーリングにすぐには対応できていなかったからです。ですから、まだフロンティアモデルのために取っておかれていたユースケースというものが存在していました。そして、これはあまり考えすぎるとよくないのですが、当時オープンモデルには、クローズドモデルが持っていたようなプロダクトレベルのプロダクト・マーケット・フィットはまだ存在していなかったと感じていました。ある意味、哲学的には、その瞬間が来たときに、私たちはそこにいて、その機会を捉えたいと考えていました。それが実際に起きたのは今年、コーディングエージェントがオープンモデルとともに動くようになったときだと思います。というのも、AI消費の最大のボリュームが、ついにオープンモデルによってサービス提供できるようになったタイミングと重なったからです。その道の途中では、プライベートかつセキュアな形で収益化する機会も数多くありました。Fortune500の多くはすでにLlamaを採用していました。しかし、私たちは自分たちに、顧客にとって最も重要な問題は何かを問い続けました。ローカルという部分は、その物語の重要な一部ではあるものの、それが物語のすべてだと感じたことは一度もありませんでした。本当の問題は、最も難しい問題のためにどうやってオープンモデルにアクセスするか、ということでした。ですから、ある意味で、私たちは待っていたのです。市場が成熟するまで、少し待つ必要があると分かっていました。同時に、待つことのリスクも認識していました。もし気をつけていなければ、収益化を優先しない企業文化が定着してしまう可能性があります。私たちはこの点について、Docker時代の経験から多くを学んでいました。マネタイズについて考えない、それが優先事項にならない、というのは、私たちがチームとして、これまでの戦いの傷跡から既に理解していたことでした。ただ、もう一つ本当に重要な要素は、顧客と常に連絡を取り続けることです。オープンソースプロジェクトが急成長したときの最大のリスクの一つは、自分たちのユーザーベースや顧客ベースを、インターネット上の単なる「かたまり」のように扱ってしまうことです。それは顧客について考える上で非常にリスクの高い方法です。なぜなら、本来であれば顧客に会い、彼らのニーズを理解する必要があるからです。彼らが何をしているのか、6か月後に何をしたいと思っているのか、彼らのストーリーは何なのか。この点については、過去数年間、もう少しやっておけばよかったと思っていますし、今はまさにそれを大量にやっているところです。
8-2. YC参加の意思決定とコミュニティの価値
Host: あなたがYCを経験したとき、あなた方は二回目の創業者でした。何がYCへの参加を決めさせたのか気になっています。
Jeffrey Morgan: 実は、この点については私たちの中でずいぶん議論を重ねました。本来はそんなに悩む必要はなかったはずで、当然YCをやるべきだと最初から言えばよかったのですが。とはいえ、会社を始めるというのは、基本的には本当に孤独な経験です。素晴らしい共同創業者がいたとしてもです。Michaelは私の最初の会社の共同創業者でもあり、ウォーターロー大学時代の学生寮のルームメイトでもありました。それでも孤独であることに変わりはありませんでした。だからこそ、たとえパンデミックの最中であったとしても、Jaredや、他の5組ほどの創業者グループと毎週話をすることで、孤独感がかなり和らいだのは、本当に重要な部分だったと思います。そして、実際にこちら(シリコンバレー)に移ってきたときには、そこにいたネットワークはもう本当に信じられないものでした。開かれたモデルの上で、あるいはどんな種類のAIであっても、それを構築している創業者たちと出会えるということ。私たちは、ウォーターロー大学出身で、コロナ以前にYCを経験していた多くの創業者を知っていたので、それがどういうものかはある程度分かっていました。彼らは、本当に大事なのは実際に集まって交流することだと言っていましたし、私たちもそれが起きるだろうと分かっていました。ですから、それが決断を後押しした、いわば当然の選択にした大きな理由だったと思います。ただそれ以上に、繰り返さなくてもいい過ちが数多くあるとも思っています。YCコミュニティの好きな点は、創業者同士がそうした過ちについて、いかに率直に話し合うかということです。私は今でも、Dockerの創業者と連絡を取り合っていますが、彼は今、私たちの会社の投資家でもあります。私たちは、前の世代の企業で見てきたいくつかの課題について、率直に話し合うことができます。それは必ずしも繰り返さなくてもいい過ちであったり、あるいは逆にうまくいったことであったりして、それらを未来に持ち込むことができるのです。
Host: そうですね。繰り返さずに済んだ過ちの一つが、時には会社を潰しかねないほどの過ちだったということも、あり得ますね。
Jeffrey Morgan: そうかもしれません。私たちのチームには、うまくいった企業から来たメンバーが多くいます。Dockerも今、驚異的な成長を遂げています。私たちのメンバーの中には、VMwareの初期からいた者もいますし、常に良い時期も悪い時期もあるものです。ただ、そうした経験の集まりを持った人々がテーブルを囲んでいること、そして何がうまくいったのかを知っているということ、それが実際にはより重要だと思っています。そのような「筋肉の記憶」を持てることは大きな部分を占めます。18歳や19歳の若者たちとよく一緒に過ごし、仕事をする機会があるのですが、彼らはよく「何をすればいいのか」と聞いてきます。そこで最近気づいたことの一つは、もし本当に多くの人々に届く素晴らしい技術を出荷したチームで働いたことがない、あるいは明確なプロダクト・マーケット・フィットを経験したことがないのであれば、たとえそれが1か月であっても、3か月であっても、一度その経験をしてみるべきだということです。その3か月の中で学ぶことは、それを経験しないよりもずっと多いはずです。というのも、それを経験することで、「良いもの」とはどういうものかが分かるようになるからです。それがなくても、不可能というわけではありません。YCにいる人たちも、実際にそれを見出すことができています。ただ、それはずっと難しくなります。何かが実際に最初から最後まで機能するのを見たことがあるかどうか、それこそがバグデータベースがどう見えるべきか、どうリリースするべきか、どの品質が必要か、お互いにどのような基準を求め合うべきか、という違いに大きく関わってきます。それを見たことがあるということは、成功する可能性を大きく高めてくれるのです。だからこそ、すでに多くのそうした経験を見てきた共同創業チームから始めるということが、非常に強力なことになるのは理にかなっています。
Jeffrey Morgan: そうですね。特にAIによって非常に大きな力を手にしているこの状況では、それがあなたに一連の価値観を提供してくれると思います。私はいくらでも手助けはできますが、それがあなたに責任を持たせてくれるわけではありません。ソフトウェアがどのように動くのか、そして例えば2年前のバージョンが実際に世の中で動いているものがあるはずですが、誰かがそれに惚れ込んで2年間も使い続けたとき、そのソフトウェアはまだきちんと動作しているのか。うまくいけば最新版に更新してもらえるでしょうし、あるいはクラウドサービスであればそれも解決できるかもしれません。しかし、そうした「筋肉の記憶」を築くことは重要で、私たちはそれを、VMwareやNSXなどの出身の、より経験豊富なエンジニアから多く持っています。一方で、AIの世界において、前の世代のDevOpsやインフラの世界で学んだ教訓のうち、もはや通用しなくなっているものも数多くあると思っています。
8-3. インフラ時代の知見とAI時代への適用
Host: それは面白いですね。それについて教えてください。何が今は通用しなくなっているのでしょうか。
Jeffrey Morgan: 私が典型的な例として使っているのは、「プラットフォーム・アズ・ア・サービス」という世代の企業群です。その文脈でいうと、Herokuのようなものが良い例です。
Host: Dockerも、もともとはそこから始まりましたよね。
Jeffrey Morgan: その通り、Dockerもプラットフォーム・アズ・ア・サービスとして始まりました。そして、もし何かの上に乗っているレイヤーであれば、スタートアップとして脆弱な立場にいる、という考え方が当時はありました。しかし、それはAIの世界では全く当てはまりません。実際には、スタックを上に上っていくことのほうが、時にはより良いことすらあります。というのも、それによって顧客に近づくことができるからです。インフラの世界においても、それは同じことが言えます。それは、Llamaを構築する上で私たちが実際に打ち破らなければならなかった、いわば筋肉の一つでした。もう一つは、LLMは決して完璧ではないということです。システムの世界では、すべてが設計通りに、きちんとテストされ、検証されて動くことを望みます。しかし、LLMというものは、その性質上、そうではありません。
Host: それは、バグではなく機能だということですね。
Jeffrey Morgan: その通りです。まさに機能です。
Host: 少し非決定論的であることを望むべきなのでしょうね、おそらく。
Jeffrey Morgan: そしてチームづくりの観点からも、AIがあることによって、10年前ほど人員を厚く配置する必要のない問題領域が出てきています。カスタマーサポートのパイプラインがどのようなものか考えてみてください。クラウドサービスを提供するというのはどういうことか。今、AIのある世界では、誰もコードのすべての仕組みを正確に理解していない状態でサービスを構築する、というのが実際に当たり前になっています。ですから、私たちのチームの一部が、2000年代のインフラ1.0から2010年代のクラウド、そして今のAIの領域へと移ってきた中で、新しく学ぶべき教訓がたくさんあります。多くのルールが崩れつつあります。
Host: あなた方は、エコシステムの両側に対して、非常に大きな貢献をしているのだと思います。エンドユーザーの側からすれば、非常にクリーンなものをただ受け取るだけで済んでいます。特にトークンがきれいに出てきて、APIが理にかなっていて、論理的で合理的です。しかし、その裏側では、レイヤーがなければ、たとえば、こういうパラメータをこう入れると推論プロバイダーの側で奇妙なエラーが出るとか、JSONを期待しているのにそれが文書化されていない、というようなことが実際にあります。それはまさに地雷の埋まったフィールドのようなもので、エージェントはある程度それを乗り越えることができますが、それでも、エージェントがそれを解決するまでに何時間も壁に頭を打ち続けるようなことになります。その間、ユーザーからすれば「これはひどい体験だ」と感じてしまうわけです。ですから、あなた方はおそらく、その裏側で推論プロバイダーの根本的なバグを修正する手助けもしているのではないでしょうか。
Jeffrey Morgan: その通りです。それは私たちの仕事の一部でもあります。そして、オープンモデルの世界における大きな機会の一つは、断片化されたモデルと推論技術、クラウドサービス、そしてハーネスの世界を取り上げて、それを本当に機能させることそのものが、非常に価値のある問題だということです。というのも、エンドの開発者からすれば、彼らはただソフトウェアを作りたいだけであり、彼らの次の会社、次のアプリケーションを作りたいだけなのです。そして、私たちがそこに関わってくると思いますが、それだけでなく、多くの優れたサービスもそこに関わってきます。OpenRouterは、幅広いモデル選択という観点から、その良い例だと思います。開発者は数百社のプロバイダーにサインアップする必要はなく、一つの場所に行けば済み、一つの場所で支払いができます。また、OpenCodeで見てきたように、一つのハーネスがどのモデルとも統合できるというのは、次のモデルを試して自分たちのユースケースにより適しているかどうかを確認したい開発者にとって、非常に強力な体験だと思います。ですから、このキュレーションという作業、そして今のようにモデルとプロバイダーが豊富にある状況においては、それらをまとめて実際に機能するものにする、という部分に新しい希少性が生まれているのです。
9. キュレーションという価値とクロージング
9-1. 「キュレーション」の意義
Host: あなた方は、まさにこのエコシステムの両側に対して、非常に大きな貢献をされているのだと思います。エンドユーザーの側からすれば、トークンがきれいに出てきて、APIが理にかなっていて、論理的で合理的な、非常にクリーンなものをただ受け取るだけで済んでいます。しかし、その裏側にレイヤーが存在しなければ、たとえばあるパラメータの入れ方によって推論プロバイダー側で奇妙なエラーが出たり、JSON形式を期待しているのにそれが文書化されていなかったりといった、地雷の埋まったフィールドのような状況に直面します。エージェントである程度は乗り越えられるとしても、それを解決するまでに何時間も壁に頭を打ち続けるようなことになり、その間ユーザーは「これはひどい体験だ」と感じてしまいます。ですから、あなた方はおそらく、その裏側で推論プロバイダーの根本的なバグを修正する手助けもしているのではないでしょうか。
Jeffrey Morgan: その通りです。それは私たちの仕事の一部でもあります。オープンモデルの世界における大きな機会の一つは、断片化されたモデルと推論技術、クラウドサービス、そしてハーネスの世界を取り上げて、それを本当に機能させることそのものが、非常に価値のある問題だという点にあります。エンドの開発者からすれば、彼らはただ自分のソフトウェアを作りたいだけであり、次の会社や次のアプリケーションを作りたいだけなのです。私たちはそこに関わっていますが、それだけでなく、多くの優れたサービスもそこに関わっています。OpenRouterは、幅広いモデル選択という観点からその良い例です。開発者は数百社のプロバイダーにサインアップする必要はなく、一つの場所に行けば済み、一つの場所で支払いができます。また、OpenCodeのように、一つのハーネスがどのモデルとも統合できるというのは、次のモデルを試して自分たちのユースケースにより適しているかを確認したい開発者にとって、非常に強力な体験です。つまり、このキュレーションという作業、そして今のようにモデルとプロバイダーが豊富にある状況においては、それらをまとめて実際に機能するものにするという部分に、新しい希少性が生まれているのです。トークンそのものの希少性から、トークンの上に何を築くか、つまりオーケストレーションとキュレーションの希少性へと、問題の重心が移り変わってきたというのが、この対話全体を通じて語られてきた大きな流れだと言えます。
9-2. クロージング
Host: 今日は本当にありがとうございました。時間になりましたので、これで終わりにしたいと思います。
Jeffrey Morgan: お招きいただき、ありがとうございました。