「LLMの登場で、論点が『モデルをどう開発するか』から『アプリケーションをどう作るか』に移行した」
そう語るのは、生成AIに特化したスタートアップスタジオ「Algomatic」でCEOを務める大野峻典さんです。ChatGPTが世界中で使われはじめた2022年末、大野さんはすぐさま創業を決断。AI領域で研究と事業開発に取り組んできた経験から、「AIそのものを作る時代は終わり、LLMの登場によってAIを前提としたアプリケーションの時代が到来する」と確信しました。
設立時から「AI革命で人々を幸せにする」というミッションを掲げ、営業と採用、翻訳、そして大手企業の課題解決（AI Transformation、AX）という4つの領域を軸に、生成AIネイティブな事業を同時展開。現在、営業AIエージェント「アポドリ」、採用支援AIエージェント「リクルタAI」などのBtoB領域サービスだけでなく、ゲームの多言語展開を支援する翻訳サービス「AlgoGames 翻訳」や、大企業の業務変革などのAIエージェント事業を展開しています。従来のSaaSとは異なるAI事業の立ち上げ方、PMFの検証プロセス、そして差別化戦略とは何か。
freeeで新規SaaS立ち上げを経験し、日本CPO協会の常務執行理事も務めるZen&Company のCEO・宮田善孝さんを迎え、ALL STAR SAAS FUNDのシニアパートナー・湊雅之と共に、プロダクトマネージャーの観点からも大野さんの思考を深掘りします。
＼本コンテンツは、YouTubeでも配信中！／
生成AIの登場で「アプリケーションの時代」が来ると確信した
湊：そもそも生成AIが登場したとき、大野さんはどのような反応をされ、Algomaticの事業を立ち上げようと思われたのでしょうか。
大野：Algomaticは、ChatGPTが世界中で使われはじめた2022年末、生成AIのブレイクスルーが起点となっています。「既存事業があって、LLMが登場したから使って何かやろう」という発想ではなく、LLMありきで創業した会社なんです。
僕にとってLLMの登場は衝撃的でした。研究室にいたころから約10年間、AI技術を使って新しい事業を作る方法を模索してきました。しかし当時は、データを集めること自体が難しく、PoCや研究開発を受託する事業は成り立つものの、なかなかサービス化まで至りませんでした。AIのエンジン部分を作ることだけで精一杯で、事業として一定のサイズのバリューチェーンを抑えられる「AIアプリケーション」まで作りきることが極めて困難だったのです。
しかし、LLMが登場したことで状況は一変しました。圧倒的に優秀で汎用的に使えるモデルが登場したことで、論点が「モデルをどう開発するか」から「どんなアプリケーションを作るか」へ明確に移行するのを感じたんです。
従来であれば、膨大なデータを集めて何百万円、何千万円と投じなければ到達できなかったものが、LLMを使えば一瞬で形にすることができる。「AIアプリケーションの時代がついに来た」と直感しました。これまで「いつか実現するだろう」と妄想のように語られていた世界が、いよいよ当たり前にできるようになる。その確信が、Algomatic創業の原点でした。
「思考が介在するから自動化できなかった領域」を狙う
湊：生成AIが登場した当初、多くの人が可能性は感じながらも、事業立ち上げまでには時間がかかった印象があります。そのなかで大野さんは特に動きが早かったのではないでしょうか。アプリケーションを立ち上げようとしたとき、いわゆる「事業ネタ」をどうやって見つけてきたのですか。
大野：ChatGPTが登場しても、事業化が難しいと感じるフェーズは確かにありました。そもそも「チャット」として捉え続ける限り、事業化が難しいのです。この2年ほどで多くの方が実感されたと思いますが、本質は「チャット」ではなく、「AIエージェント」です。文字を生成できるということは、人間が文字で考えたり文字で伝達するように、「思考プロセスそのものを代替できる」可能性を意味します。
当時から、行動→結果→再思考→次の行動という一連のサイクルを回す「ReAct」フレームワークは研究上すでに存在しており、実装レベルでもさまざまな試行ができたのです。試してみると失敗も多いものの、人間らしい思考の痕跡が明確に見える。「このタスクならAIの方が優れている」という場面が確実に増えていくと感じました。
思考の代替が可能になるというのは、これまであり得なかったこと。多くの領域が未開拓です。この「手つかずの広さ」が事業化の決め手でした。
一方、「チャットで何を頑張るか」を考えすぎてしまうと、事業化はむしろ難しくなります。当時、多くの人が「チャットで何を頑張るか」にこだわりすぎてしまい、「チャンスがない」と判断したのではないかと思っています。「チャット」は一つのUIにすぎません。
ではどこにチャンスがあるのか。それは「人間の思考が介在するために、従来のITでは自動化できなかった領域」であり、それを探して取り組むこと。それこそLLMの本質的な変化です。
しかも、それは従来のITが担っていた領域とは異なります。従来のITが担っていた領域は、思考が介在しない領域でした。綺麗にデータが整形でき、綺麗なデータ形式が作れ、綺麗にロジックが定義できる。自分で定義できる領域が、ITによる自動化の対象でした。会計や在庫管理など、さまざまなルールが存在する領域ですね。
しかし意外にも、そこではないところにチャンスがあるんです。人間が労働集約的に解決せざるを得ない背景には、タスクが単純であっても、人間の思考が介在するから生じる難しさがある。僕はそういう領域での機会を探しました。
従来のSaaSと異なる、AIエージェントのPMF検証プロセス
湊：既存のSaaSやオンプレミスのソフトウェアが狙う領域と、実はAIが狙う領域とはまったく違う切り口だとも言えると。属人的で暗黙知化された業務を徹底的に狙われたという観点にもつながりますね。
宮田：PMFの定義をどう捉えているのか聞いてみたいです。SaaSの場合、ユーザーに導入支援を行い、コアとなるキーフィーチャーをしっかり使ってもらえているか、それに付随するデータがSaaSで正規化されているかを確認します。さらに踏み込むと、ユーザーがアクションを起こしているかまで確認できれば、完全にPMFした感覚があります。しかし、攻め方がまったく異なるAIエージェントのPMFでは、検証プロセスはどうなるのでしょうか。
大野：確かに検証プロセスは大きく異なります。気をつけなければならないと考えているのは「不確実性がどこにあるか」が変わる点です。
従来のSaaSでは、最初のコンセプト検証の段階で、あるイシューが「ソフトウェアで解けるかどうか」は、ほぼ自明でした。技術的にできることの線引きが明確で、僕たち開発者もユーザーも、ソフトウェアの能力の限界を高い解像度で理解できていたのです。そのため、PMFまでのプロセスで技術検証が大きな論点になることはあまりありませんでした。
しかし、LLMやAIエージェントはまったく異なります。AIエージェントを触ったことがある方なら理解しやすいと思いますが、各アクションの成功・失敗が確率的になるんです。さらに、その確率的なアクションが連鎖し、タスク全体としては失敗が起きやすい構造になっています。そのため、AI事業の検証では、「技術的にどこまで到達できるか」を、従来よりもはるかに早い段階で見極めなければなりません。
これまでは事業アイデアが生まれたら、すぐに顧客へ「このようなコンセプトで、ここまでの価値を提供できるとすれば、購入していただけますか」と話を持っていくことができました。もちろん早く動くに越したことはありませんが、今は違います。まず手元でモックを作り、どの程度の精度が出るかを試してみる必要があります。つまり、AIエージェントのPMFでは、これまで以上に技術限界の検証が前倒しで必要になるという点が、従来のSaaSとの決定的な違いだと考えています。
ドメインエキスパート自身を再現するには「免許を取る」レベルの解像度が必要
宮田：採用代行（RPO）のサービス開発に関するnoteで、有料職業紹介の免許を取得したという話を拝見しました。私もSaaSを作る際、会計事務所や人事担当者に話を聞きに行く取り組みは実施していました。しかし、自ら免許を取るという事例は聞いたことがありませんでした。どのような考えでそのようなチャレンジをされたのでしょうか。
大野：まさに僕のなかでパラダイムが大きく変わった部分です。これまで、たとえば人事向けのソフトウェアサービスを作る場合、人事担当者が使うツールを作ることがゴールでした。しかし、人間が行なっていた仕事をLLMを使って自動化する場合、タスクの性質が変わります。目指すべきは、人事担当者という職能そのものの再現。つまり、エキスパート人材をそのままAIで再現することがタスクになるのです。
従来でもユーザー理解は重要でしたが、AIエージェントでは求められる解像度がまったく異なります。世の中の業務には、タスク化できる部分より、言語化されていない“当たり前”の判断や文脈の共有のほうが圧倒的に多い。たとえば人事なら書類選考のマッチングのような明確なタスクもありますが、その周辺には、経験から導かれる細かな判断が無数に存在します。
それらを解像度高く把握するには、まず自分たちが当事者になるしかない。だから免許を取り、職業紹介そのものを自分たちでやってみたわけです。逆に言えば、<yellow-highlight-half-bold>ドメインエキスパートでなければ、そもそも良いAIサービスは作れません<yellow-highlight-half-bold>。だから、ドメインエキスパートをチームに入れることも重要ですし、自分たちがそれに近づくことも大切です。ドメインエキスパートが何を考え、どこに注意を払い、どんな基準で判断しているのか、実際にやってみなければ分からないことがたくさんあります。
採用にせよ営業にせよ、僕のなかでの事業開発で強く意識しているのは、まず「すべての仕事を自分たちで請け負ってやってみる」という姿勢です。その経験のなかから、どこが自動化できて、どこが自動化できないのかが初めて浮かび上がる。AIエージェント時代のプロダクトづくりでは、ここがこれまで以上に重要なポイントになったと感じています。
宮田：SaaSは各担当者が使うものだが、AIエージェントは担当者自体を代替するものである。この差は確かに明確ですよね。代替しようとすると、担当者自身が飲み込んでいた周辺情報をしっかり理解して判断できるようにならなければなりません。当然、ドメインがもう1段、もう2段深く重要になってくるわけですね。
SaaSの場合は「できること」も明確なので、リーンに進めているつもりでも、ある程度のプロダクトを作るためにしっかりチームを組成し、半年程度かけて一つのプロダクトを作る動き方が多いと思います。
その点、大野さんたちは、事業やプロダクトを作っていくうえでの体制面はどのような形で構築されていますか。もっとリーンに進めているのでしょうか？
大野：体制面では、それほど変わらないと感じています。
最初にプロダクトを作りはじめる段階ではミニマムです。事業の責任者、つまり起案者が1人で立ち上げて、PoCや手元での実験から入り、その後2〜3人のチームで動きはじめます。事業開発、エンジニア、場合によってはデザイナーが加わる程度ですね。
ただ、僕たちならではのやり方があります。たとえば営業代行に取り組む際は、関わるメンバー全員が営業代行の仕事そのものを経験します。なぜなら、AIエージェントに落とし込むべき「細部」が、想像以上に細かいからです。プロセスの改善点や課題は、現場で体験して初めて見えてくる。分業できるほど問題が整理されていない段階では、全員が当事者になることが最も効率的で、最も精度が高いと考えています。
全員が経験することで、AIエージェント開発の解像度が上がる
湊：エンジニアのチームも代行業務を体験するのでしょうか。それとも事業開発のメンバーだけでしょうか。
大野：エンジニアも含めてチームメンバー全員が経験します。
分かりやすいメリットの例として、AIでインサイドセールスの代行をする場合を考えてみます。実際の業務では、各社に提案文章を作成し、メールを担当者へ送付する。その際には「文章を作成する担当」と「クオリティを担保するリーダー」がいて、人間による目検のプロセスが必ず存在することを知るわけです。
エンジニアがこの業務プロセスを知らずに自動化しようとすると、「文章を作成し、送信ボタンまで自動化すれば完了」と考えてしまいがちです。しかし、業務を体験していれば、「生成するエージェント」と「レビューするエージェント」が必要だと自然に理解できますし、人間によるレビューが必要だとすれば、「人間がレビューしやすいUI設計」の重要性にも気づきます。AIエージェントが主体となって動きますが、人間にレビュー依頼を出し、結果を取得したら次に進む、という設計になる。
また、エンジニアリングのなかでも、あるアクションをどこまで自動化すべきか、逆にどこを敢えて人間に残すべきか、自動化するとPDCAが回りにくくなる部分の塩梅を、よく理解できるようになります。
他にも、「どのような文面であればアポイントが獲得できるのか」ということも、実際に自分で営業代行の業務を改善しようと試行錯誤するからこそ、重要な変数として浮かび上がります。定性分析に必要なログ、見え方、データを貯めておくべきだとわかるんです。
実際に僕たちがサービスを作る際、送信した提案の内容や、提案を作るうえでの思考プロセスを、サーバーのログだけで残すのではなく、事業開発の担当者やエンジニアも含めて全員が見やすいところに落として“見える化”しておくべきだと最初からわかるわけですね。
エンジニアでない人たちも技術側へ「越境」していく
湊：事業開発でも全員の実経験が重要視されるのは、まさにAIサービス特有の部分だと感じます。そのうえで、ソフトウェアエンジニアに求める素養も異なるのか、伺わせてください。
従来は「どう作るか」というHowの部分が重視され、ユーザー理解がなくても一定で何とかなった部分がありました。一方でAIサービスの場合、PdM的な素養とは言わないまでも、ユーザーの立場で課題を解決するという、ソフトスキルに近いものを持っている印象があります。エンジニアに求めるものは、どのような点でしょうか。
大野：そうですね、求めるものは確かに変わってきていると思います。もっとも、ラディカルにすべてが変わるわけではなく、従来通り開発にフォーカスする場面も当然あります。どちらかと言うと、エンジニアが越境しやすくなっている、という感覚が近いです。
つまり、エンジニアリングに閉じた課題は、特に初期フェーズにおいては少なくなっています。これまでと比べると増えているのは、ビジネスイシューに向き合うことでしょう。
湊：AIスタートアップの方々と話していても、そこが大きな変化だと感じます。流れとしては、AIエージェントでコード生成はできるようになってきて、ジュニアとシニアで見極め能力などに差はありますが、生産性は大きく上がっています。だからこそ、よりビジネスサイドへエンジニアの視座が移ってきている。新たなエンジニア像ともいえますね。
大野：おっしゃる通りです。ただ、逆の流れも起きています。
エンジニアはコードを書くことが多いとはいえ、PdMやBizDevもバイブコーディングをしますし、Difyのようなノーコードツールを使うのも一般的になってきました。彼らがChromeのエクステンションを書くことも頻繁にあります。つまり、非エンジニア側がエンジニアリングへ越境してきているんです。
経験がないと壁を感じますが、一度でもやってみると「意外にいける」と気づくんですよね。実際に、それほど壁はありませんから。「依頼するくらいなら自分で手を動かした方が早い」ということもよくあります。
僕たちが取り組んでいる事業は業務の自動化なので、ものによってはコードを書くよりも、ノーコードツールで作ったほうが早く、改善を回しやすいケースも多いです。
事業上のPDCAを考えると、「プロンプトを変えたらどうなるか」をみんな試したいわけです。これがコード内に埋まっていて、Gitを使ってコードをコミットしないと変えられない状態だと、非エンジニアにとってはやりづらい。プロンプトの変更は、場合によっては事業開発やプロダクトマネジメントを担当している人が自ら調整したくなることが多くあります。
プロンプトだけでなく、ワークフローをどう組めばよいか、レビューのプロセスをどこに挟めばよいかなど、さまざまなビジネスロジックをエンジニア以外が試行錯誤したい場面が多くあります。特に技術検証フェーズではそうです。そのようなときは、そもそもコードで書かない方がよい、という選択肢もあります。ノーコードツールを使うタイミングは多いのではないでしょうか。
結果として、エンジニアでない人がモックを作り、技術検証にも関わる「越境」が当たり前になる環境に変わってきていると感じています。
多様化するドメインエキスパートのキャリア
湊：今のお話も興味深いです。ある意味、どれだけ越境できるかがチームの力であり、AIプロダクトを育てるうえで、特にスピードの観点で勝ち筋になるのかもしれません。
もう一つ伺いたいのが、ドメインエキスパートの採用です。先ほどのお話では、チーム全員で経験してみるというススメがありましたが、そもそもドメインエキスパートを採用するという考え方もあるのでしょうか。
大野：あります。基本的には、ドメインエキスパートをチームに入れなければどうにもならないと考えています。採用領域であれば、さまざまな会社で人事責任者を務めていた方をチームのメンバーとして迎え入れていますし、営業であれば、営業の現場を長く経験してきた方に、営業開発として入ってもらっています。正直、ドメインエキスパートがいなければ、僕としては100パーセント成り立たないと感じます。
湊：そうですよね。
大野：素人とプロの差は、まさに暗黙知に表れます。誰でも営業ができるのであれば知見は不要ですが、実際にはそうではありません。上手い人は上手いし、成功の確率もまったく違う。まず知見がないとはじまらないんです。
また、プロダクトの販売においても同じです。AIプロダクトは、星取表的な「できる／できない」で語っても伝わらないところが多い。理論上、ChatGPTは何でもできるわけですが、それだけではユーザーに響きにくい。つまり、購入してもらうためには、ドメインエキスパートが納得できるストーリーが必要なのです。
人材エージェントが自信を持って企業へ人材を推薦するように、マーケット側の人たちに優れたAIエージェントを届けるためには、ペルソナに刺さるコミュニケーションや、「何が価値なのか」を伝える言葉選び、というかコンセプトの磨き込みが欠かせません。
それもドメインエキスパートの観点がないと、ほぼ不可能です。その領域で使われる言葉、響く訴求、納得してもらえる伝え方など、現場の文脈を熟知していなければ作れません。だから、良いものを作るためにも、そして良いものを作ったと正しく伝えるためにも、ドメインエキスパートは必要不可欠なのです。
そして今、ドメインエキスパートのキャリアも多様化しつつあると感じています。これまでは「人間に教えること」がキャリアの先にありました。ところが、現在は「自分の思考をトレースできるAIエージェントを育てる」という新しいキャリアパスも生まれつつあると感じています。
採用は「運ゲー」。良い人との出会いから事業領域を決める
宮田：これまで複数事業を展開してきたなかで、初手の採用やキーマンの獲得という観点でいくと、まずはドメインエキスパートから採用をはじめているのでしょうか。
大野：これは難しいテーマですよね。どのドメインにどこまでチャンスがあるかなんて、誰にもわかりませんから。正直なところ、そもそも採用については「あるべき論」が、僕にもまだわかりません。ただ一つ言えるのは、LLMには膨大なチャンスがあるということ。そして、採用というのは結構な「運ゲー」だということです。いくら努力をしても、本当に良い人と出会える機会は限られています。
だからこそ、どんなドメインであっても事業を立ち上げられるようなチームづくりを意識しています。僕たちの場合は、事業を作るまえに、まず事業責任者や責任を持つ役員クラスのキーマンを採用しています。採用、営業、エンタメ翻訳、業務変革など、複数の事業に取り組んでいますが、すべて「その領域を担えそうな人」がチームに加わってくれてから作りはじめているんです。
つまり、事業領域を先に決めて、1人目のドメインエキスパートを獲得しに行くのではなく、良い人が入ってきたタイミングで、その人と一緒に領域を探索しながら決めていく感じですね。物凄く良い人と出会ったらなんとしても仲間になっていただく。仲間になっていただいてから、その方の才能を120%活かすための事業や組織の形を考えてもいいと思っています。
技術の黎明期でドメインが明確に絞られている状況であれば、そうはしないと思いますが、今は可能性が無数に広がっている時代です。であれば、まずは0→1を担って事業を成長させていける能力を持った方が入ってきてから、その方が得意とする領域を一緒に形にしていくほうが自然です。
そのため最初の採用では、まずはドメインエキスパートというタグが強い人というより、0→1の事業立ち上げを経験してきた方を優先しています。そして、事業領域が徐々に定まってきた段階で、必要なドメインエキスパートの方もどんどんお誘いしていくという流れですね。
事業の撤退基準は「半年で売上500万円」と「LTV・CAC」
宮田：複数プロダクトがあると、事業の撤退基準やリソース配分も議論されますが、このあたりはどのような発想で挑まれていますか。
大野：社内では、事業や検証プロジェクトをはじめてから「半年で月次売上500万円」を一つの目安にしています。半年で500万円に到達していれば、市場のリアクションがあり、一定の可能性があると判断しています。逆に言えば、500万円に到達しなかった場合は、基本的に可能性が低いとみなしてます。
本当の意味で「際どい事業」を見極めるのは非常に難しいです。この事業が49点なのか51点なのか、正直よくわからない。一方で、初速が良い事業、トラクションがつく、90点以上の手応えがある事業は比較的判断しやすい。その初速の良さを見るうえで、半年で500万円というラインはわかりやすく、僕たちのなかで良い事業の芽があるとみなせると考えています。
もしかすると、切り捨ててしまった事業のなかに、後から見れば上手くいった可能性があるものもあるかもしれません。ただ、それを追いかけすぎると、いわゆるリビングデッドなプロジェクトばかり残ってしまう。なので、「90点以上と確信できないものは切る。飛び抜けていいもののみを残す」というスタンスを徹底しています。
また、事業を継続し続けるかどうかの判断軸としては、まずは、シンプルにLTV/CACが合うかどうかです。事業としてエコノミクスが成立すると思える限りは続けますが、そうでないものは深追いしません。
最初はとにかく初速です。LTVなどは十分にわからないので、少なくとも合算して月500万円程度の発注が取れているという状況をまずは目指します。それ以降は、ライフタイムや理論値を積み上げながら、LTV/CACが理論値込みで成立すると判断できた事業をグロースさせていく、という流れですね。
独立採算制で各事業を運営。リソースのアロケーションよりも全体のパイを増やす
宮田：片や150点のプロダクトがあって、片や80点でギリギリのプロダクトがある。そんなとき、及第点で両方続ける選択肢もあれば、調子が良いほうにリソースを寄せる判断もあると思います。リソース配分はどのように考えているのでしょうか？
大野：基本的には独立採算のほうが良いと考えています。
理由はいくつかあります。まず、事業ごとに経営陣を分けていること。多くの企業では、全体の経営陣がいて、複数の事業を同じ経営陣が見ると思いますが、Algomaticでは事業ごとに経営陣を分けているので、ほとんど兼任していません。横断的に関わっているのは僕と数名の横断チームのメンバーくらいなんです。
この状態で、それぞれのブレーンがそれぞれの裁量で事業を進めているときに、横断的なリソースのアロケーションが起きるとコントローラビリティを失いやすい。チームの裁量で動けなくなり、ゲームとしてもプレイしづらくなる。だから、よほどのことがない限り、あまり移動したくないと考えています。
次に、リソースが必要な場面でも、アロケーションが必ずしも解決策にならないという点。そもそも事業によって必要な人材が異なるからです。たとえば、営業AIエージェント「アポドリ」の場合、セールスでもカスタマーサクセスでも事業開発も、営業の実務に詳しい方が必要で、この事業だから必要になるんです。
そして、僕が一番重視しているのは「優秀な人がどれだけ集まっているか」が、そもそも会社としてのアセットになるということ。採用はコストも時間もかかるので、集まった人材はそのまま会社のアセットとしての価値が高い。基本的に各事業で必要なタイミングで採用しているので、社内のアロケーションだけでやりくりしても、結局は全体の力としての合計値は変わりません。
むしろ、採用したいタイミングというのは事業に勢いがある時期ですし、本人たちも“やりたいテーマ”を持っている。そのモメンタムに乗って、全体のパイを増やせれば増やせるほど圧倒的に得だと考えています。なので、なるべくアロケーションより先に、増やすことで解決する方向性です。
とはいえ、そうも言っていられないときもあって、エンジニアが数人単位で異動することはあります。けれど、ラディカルな配置転換はそれほど起きていません。起点となる人と起点となる課題があり、「この人が入ってくれれば一気にいける」という状況なら増やす。アロケーションは最終的に自分たちの塩梅でいつでもできるので、まずは好きな人を採用することにトライした方が、間違いなく得です。どうしてもそれが叶わない場合だけアロケーションを検討する、という順番ですね。
宮田：確かに伸びているからこそ、採用や人員計画が上振れるわけで、そのモメンタムをしっかり採用に活かしていくのは重要そうですね。2点目についても、SaaSですらやはりドメインを超えると、なかなかPdMやエンジニアのアロケーションは難しかったのですが、AIエージェントはさらにドメインが深いという話なので、アロケーションするのは難しそうだと実感値が湧きました。
AIプロダクトの差別化は「スピード」、中長期のMoatは「コンテクストデータ」
湊：AIプロダクトの差別化について聞かせてください。大野さんは他の起業家の方と違って、複数の異なる領域のAIに取り組んでいます。これは稀有な状態です。おそらく優れたメタ思考をお持ちなのではと思うのですが……AIプロダクトの差別化要因を挙げるとすれば何でしょうか？
大野：まず一つ言えるのは、今はとにかくスピードが最も重要だということです。差別化が論点になるのは、供給が非常に多くて需要が少ない市場で、誰かに打ち勝たなければいけない状況ですよね。
今の僕の実感として、プロダクトやサービスラインナップを競合と比較されて導入されないことはほぼありません。むしろ、需要のほうが大きく、僕たちの供給が遅いくらいです。今のビッグテックだって、最初から圧倒的なアセットがあったわけではありませんし、特別な差別化があったわけでもありませんよね。最初に駆け抜けた速度が大きかっただけなんですよね。
Moatについての考え方ですが、僕自身まだ「何なのだろうか」を考え続けているところです。現状の理解や整理で言うと、基本的には積み上げ型の障壁ですが、そもそもすべての障壁は完璧ではありません。けれど、壁をいくつも作っておけば他社の参入に時間がかかり、その時間でさらにまた次の壁を作ることができます。そうして、壁を作り続けていくことが本質なのだろうとも思っています。
<yellow-highlight-half-bold>まずはスピードで駆け抜ける。これが他のいろいろなパワーを持った人よりは大きい要素、初期の差別化要因になります<yellow-highlight-half-bold>。そして、その後に必要なのが実績と信頼です。
世の中の人たちがどれだけ僕らのサービスを使ってくださっていて、それを「良かった」と言っていただけているのか。これが100社規模になり、ロゴ付きで「最高でした」とコメントを寄せてくださる企業が揃ったら、後から入って追い越すのは、そのドメインではかなり難しい。
ブランドや認知よりも、僕としてはもっと分厚くて意味がある壁だと感じているのは、<yellow-highlight-half-bold>「サクセスして良いと言ってくれているお客さまが100社いる」「継続利用のエンタープライズ企業が100社いる」といった状態を作れるかどうか<yellow-highlight-half-bold>です。まずはここが最初のマイルストーンになります。スピードで駆け抜け、その実績をストックしていくイメージですね。
もっと先、たとえば「SNSを後から作るのは難しい、ネットワーク効果があるから」という意味合いにも似た、「積み上げるのに時間はかかるが、壁の力が強いもの」があります。この壁は永遠に崩せない、理論上無理だと思えるのは、スケールメリット系やネットワーク効果系ですね。
それで言うと、サービスにもよると思いますが、コンテクストデータは差別化要因になり得ると考えています。たとえば営業代行や採用代行をサービス化するとして、システムそのものは模倣できるはずです。結局、AIサービスや業務自動化サービスで本当に難しいのは、業務への深い理解と、そのインプットであると同時に、コンテクストを把握することなんです。逆に、1プレイヤーとして、基盤モデルを進化させるようなことには、僕としてはそれほど大きな旨みはないのではないかと思っています。
むしろパフォーマンスの差が出るのは、コンテクストデータがどこまで溜まっているか。そして、一度溜まったコンテクストデータは引越すのが面倒。使い続けてコンテクストをためて賢くしていくほうが、ユーザーにとっても得になりうる。Salesforceを使っている企業が、仮にHubSpotの方が半額だったとしても乗り換えにくいのと同じで、「データ移行が面倒」というだけで状況が固定化されるわけです。
コンテクストデータも、まさにそうなっていく気がします。たとえば 、Google MeetやNotionの自動文字起こし機能は、非常に綺麗なデータポイントですよね。僕たちの領域で言えば、意図していない会議でのログや、各業務で正解とされる指示やルールも広い意味でコンテクストです。濃淡はありますが、どれも重要なインプットです。これらが使えば使うほど溜まっていく設計にできれば、よほどのことがない限り、他社が乗り越えるのが難しくなる。Moatになり得ると感じています。
デジタル化されていないコンテクストデータを取りに行く
湊：仮にですが、コンテクストデータがデジタルに存在しない場合も、紙資料が多い日本ではあり得るのかと思います。このデータがあればもっと精度が良く、もっと価値が出るはず。そういった「データのプール」を作っていくプロダクトの発想は今後ありますか？
大野：大いにあります。まさにそこに取り組みたいと考えています。
世の中的にも、ミーティングの議事録のように、今までコンテクストとして残っていなかったものがデジタル化される流れがありますよね。「LimitlessAI」のような常時録音デバイスもその一例です。常時録音そのものは技術的には難しくありません。ただ録音すればよいだけです。
しかしLLMによって、乱雑な大量のデータに意味を持たせられるようになった。コンテクストから意味のある情報を抽出する能力が上がったことで、初めて乱雑な大量のデータに意味が出るようになりました。だからこそ「録音すること」そのものに価値が生まれました。毎日の振り返りをAIがしてくれる機能なども、実際に使ってみると意外と“エモい”とわかってくる。
こうした新たなコンテクストを取りに行く動きは大いにあり得ます。動画もこれから確実に残るようになるでしょう。Metaのスマートグラスのようにカメラを備えたデバイスもどんどん普及していく。もちろんプライバシーなどの壁はありますが、合理的に考えると、世界はあらゆるものが録音・録画される方向に進んでいく方が便利ですよね。そして、それができればできるほど強くなれる。コンシューマーに限らず、BtoBの領域にも波及するでしょう。
僕たちがすでに取り組みはじめているのは、工場向けのサービスです。従業員の方にウェアラブルデバイスを装着してもらい、作業を可視化し、作業手順書を自動作成するといった試みです。これもLLMが出てきたことで、大量の乱雑なコンテクストを整理し、意味のある情報に昇華できるようになりました。動画があれば、マルチモーダルで「意味」を抽出することが可能です。
実はここに大きなチャンスが広がっています。今はデジタル系のタスクはすでに大量のコンテクストが揃っており、その活用が中心です。しかし、この数年で、非デジタルのコンテクストをどうやって取りに行くかというアプリケーションが爆発的に増えていくだろうと感じています。僕たちも、そこに取り組んでいきたいと思っています。
新規事業では最新モデルを使い、コスト削減は後回し
湊：マルチLLMの活用戦略、背景や考え方について伺いたいと思います。結局、コストと品質とレイテンシーのバランスが大事になってくると感じますが、マルチLLMの活用戦略はどのようなものでしょうか。
大野：Algomaticでは、実はそれほど、コスト削減を目的としたマルチLLM化を積極的に進めようとは思っていないんです。コスト的な意味だと、規模がそこまで大きくないうちは、急ぎでは扱わず、一定規模がでてきてから考えればいいかというところで。ただ、体験としてマルチLLMでないと成り立たない領域はあります。たとえば、コーディングを一緒に実施してくれるCursorは、コーディングのサジェストが遅いと体験が一気に悪くなります。この領域はライトなモデル、ローカルで動ける軽量モデルもうまく組み合わせたほうが、レスポンスが速く、コードを書いたそばから勝手に続きを書き足してくれる、スピーディーな開発体験が作れます。
一方で、バッチ処理系のタスクは事情が異なります。「人間の代わりに営業活動を実施し、営業活動AIが勝手に進めておくので適宜レビューで呼び出します」という体験においては、レスポンスの速さはそれほど論点にはなりません。
僕たちのサービスはどちらかと言うと後者が多いので、圧縮できるコストはたくさんあるものの、そこまで積極的には取り組んでいません。規模が大きくなってから、もっと最適化しよう、でいいかなと。
実際、LLMのパフォーマンスはまだうなぎ登りです。精度は上がり、コストは下がり、まさに倍々ゲーム状態。毎年のようにコストがN分の1になりうる世界なので、今の時点でのコスト最適化は事業が小さいうちは投資対効果が悪いと感じています。
今すでに年間100億円をLLMのコストに投じている企業なら削減に取り組んでも良いかもしれませんが、新規事業におけるランニングコストはたかが知れています。どうせ来年になればさらに安く、さらに強いモデルが出てきます。今、最新のものを使っていないと感度としては弱くなってしまいます。
そう思うと、多少コストパフォーマンスが悪くても最新モデルを使い続けるほうが、感度も精度も落ちずに済むので良いと感じています。
一方、すでに大きな事業で使われている場合では、今すぐにでもコストを下げたいニーズも確実に存在します。大量の既存業務をLLMで効率化できると分かった以上、「後はいかに安く回すか」という再生産型のサービスも非常に多いです。その観点では、マルチLLM化によるコスト最適化は大きなテーマになっていくはずです。
周辺プロダクトとの連携は、コンテクストデータを自社に残す設計が重要
宮田：周辺プロダクトについても聞かせてください。AIエージェントにとっても周辺プロダクトは重要で、「ここからデータが欲しい」といったニーズがあると思います。
たとえば、コンテクストデータをどう取得してくるか、「アポドリ」とSalesforceをどう連携してくるか。その辺の、よりプロダクトのバリューチェーンを伸ばしていく、プロダクトの品質を上げていくうえで必要な周辺プロダクトの連携をどのようにお考えですか。
大野：プロダクトによりますが、「アポドリ」のようにコンテクスト情報が必要なサービスでは、周辺プロダクトとの連携が極めて重要です。実際、開発ロードマップのなかでも優先度高く取り組みたい領域です。絶対に連携したほうがパフォーマンスは確実に上がります。ただ難しいのは、真の「コア」となる部分は他のプレイヤーも外に出したくないという点です。
先ほども話したように、AIエージェント/LLMアプリケーションにおいてはコンテクストデータがMoatになる。となると、当然、自社にコンテクストデータを溜めたくなります。もしコンテクストデータが他社のプロダクトに依存していたら、良いサイクルを回せなくなってしまいます。だから各社とも、コアな情報が外部に溜まる構造は避けたいと考えていますし、連携に慎重になるのも自然です（笑）。
宮田：SaaSの立ち位置も、そうなると変わってきますよね。自社でクローズに取り組みたいところもあれば、発想としてオープンなSaaSもおそらくある。新事業を作るうえでも、コンテクストデータが取りやすいかどうか、周辺プロダクトから取得できるかというのは、判断基準の一つになったりするのですか。
大野：なり得ると思います。ただ一般論として、データが溜まって初めて価値が生まれるタイプのプロダクトは、サービスの0→1においてはほぼ成立しません。「0→1にはフックとロックがある」といわれますが、フックになりやすいのは「何もない状態でもすぐ価値が出るもの」です。たとえば「これを使えばアポが取れます」「良い候補者との面談がセットできます」といった、即効性のある価値はフックになりやすい。
一方で、それだけだとやはりロックしきれないというか価値が限定的になる......だから、途中でデータが溜まれば溜まるほど強くなる構造にシフトする必要があります。
最初からデータを溜めようと意識しすぎると勝ち目が薄い。もちろん道筋があるなら取り組めばよいですが、0→1はまずそこまで考えすぎず、フックをちゃんと作れること、みんなに使ってもらうことが最優先です。そのうえで、溜められるところから少しずつデータを積み上げていくしかない、と日々感じています。
湊：これこそもしかしたらSaaSとAIで結構違う部分だと思います。AIはかなりフック型だと思うんです。フックの強いところをどこに設定するか、そこからデータのMoatを築くという形です。
どちらかというとSaaSは「将来的にフックになります」という感じですかなと。「ライトサクセス・ディープサクセス」という話もありますが、使い続けていくとどんどん価値が増していく。ただお客さま側もAIのことを認知していくなかで、フックに対するニーズがより強くなっているような気もします。
そもそもSaaSのフックは時間軸が結構長かったので、ペネトレーションに日本は時間がかかっている理由なのかもしれないと、伺っていて思いました。
CEOとしては「採用に半分以上、事業の突破に残り半分」
湊：最後に、今と未来の両方を伺いたいです。複数事業に取り組んでいる珍しいCEOとして、大野さんがどのような時間の使い方をされているのか。今、メインで時間を使われているところはどのような部分が多いのでしょう。
大野：この2年でいうと、採用が半分以上です。残りが事業のことという感じですね。
湊：0→1を実施する人と1→10を実施する人は能力が違うと感じます。どちらに時間を使うことが多いのか。おそらく0→1の方が中心かもしれませんが。
大野：そうですね、ほぼ0→1です。0→1と1→10は強い人が違うので、僕も得意な方だけに集中するように意識しています。僕が考えたくなるのは完全に0→1の方です。
事業の0→1もそうですし、新しく認知広告を打つときに突破するための必要な人をかき集めたり、進め方そのものを経営陣と一緒に作りにいく。そういう「突破系」が得意なんです。1→10は、僕よりもコツコツできて、センスのある方に積極的に任せています。
湊：逆に、これからそれぞれ事業が大きくなる、ないしは数が増えてきたときに、大野さんが握っておきたい業務、言い換えると「絶対に時間を減らしたくない業務」は何でしょうか。
大野：事業がうまくいくかどうかは、「良い事業・良い市場を選べるか」と「良いチームで臨めるか」の2つに尽きると思っています。
そう考えると、僕にとって一番重要な変数は事業領域と人のアサインメントにあります。CxOや責任者の人選にコミットすることは絶対に外せません。だからこそ、採用がものすごく重要です。
普通だとあまり考えないような「誰がここのトップであるべきか」という視点。ここは僕が握るべき領域だと思っています。
また、こだわりで言うと、何にお金を使っているかというP/Lは非常に細かく見ます。たとえば、Figmaのアカウント数なども確認して、数百円単位のチェックもしていく。僕自身がこだわらなければ気持ち悪いというのもありますし、サブスクの細部まで見るようなことも、大切だと意識しています。一円にまで徹底的にこだわることを、会社のカルチャーにしています。
また、採用も独立採算で各事業で進めますが、正社員採用は全員、僕が最終面接をします。「この条件でOKなら採用しよう」と、最後は必ず僕もコミットする形にしています。
とはいえ、何をどのようなバランスで実施したら良いのかは、今も迷いながら生きているところでもあります。
湊：流動的に、嗅覚を頼りに動けるというのも、ある意味ではCEOのセンスが問われるところかもしれません。一方で、先ほどの採用とお金の流れを細かく追うところは、それこそ「投資」です。一番の投資は「人」だと思いますし、攻めと守りをしっかり実施しようとしている大野さんの考え方が伝わってきて興味深かったです。
大野：そうですね。頑張っていきたいです。理想論ではありますが、定常的なタスクを持たないようにして、なるべく「突破」が必要なところや、自分にしかやりようがないところへ思い切って突っ込んでいく。そんな動き方ができればと思っています。
大野峻典（X）
株式会社Algomatic 代表取締役CEO
東京大学工学部卒。松尾研究室（現：松尾・岩澤研究室）で機械学習を専攻、深層学習を用いた研究プロジェクトに従事。Indeedにて新規事業のソフトウェア開発・プロダクトマネジメント、機械学習基盤の開発を行う。2018年、機械学習・深層学習を用いたソリューション開発を行う株式会社Algoageを創業。2020年、DMMグループへM＆Aによりジョイン。2023年、生成AI特化のスタートアップスタジオ、株式会社Algomaticを創業。複数の生成AI事業を同時多発的に立ち上げ、営業・採用・翻訳などの領域でのAIエージェント開発から大企業の業務変革支援までを一気通貫で推進している。また、メディア出演などを通じて、最新の生成AIトレンドや企業の展望に関する知見を発信。深い技術理解に根ざした生成AIビジネスへの取り組みは、多方面から高い注目を集めている。
宮田善孝（X）
Zen and Company 代表取締役
日本CPO協会 常務執行理事
ソニー株式会社 Senior Advisor
京都大学法学部を卒業後、Booz and company（現PwC Strategy&）、及びAccenture Strategyにて、事業戦略、マーケティング戦略、新規事業立案など幅広い経営コンサルティング業務を経験。DeNA、SmartNewsにてBtoC向けの多種多様なコンテンツビジネスをデータ分析、プロダクトマネージャの両面から従事。その後、freeeにて新規SaaSの立ち上げを行い、執行役員 VPoPを歴任。現在、Zen and Companyを創業し、代表取締役に就任。シードからエンタープライズまでプロダクトに関するアドバイザリーを提供。ALL STAR SAAS FUNDのPM Advisor、およびソニー株式会社でSenior Advisorとして主に新規事業における多種多様なプロダクトをサポート。また、日本CPO協会立ち上げから理事として参画し、その後常務執行理事に就任。米国公認会計士。『ALL for SaaS』（翔泳社）刊行。
湊 雅之（X）
ALL STAR SAAS FUND シニアパートナー
2016年より複数の国内VC（STRIVE、Salesforce Ventures、DNX Ventures、ALL STAR SAAS FUND）で、40社以上のBtoBソフトウェア領域でのベンチャー投資と成長支援を担当。それ以前は、ボストン・コンサルティング・グループにて戦略コンサルティング、BASFにてエンタープライズ営業や新規事業開発などに従事。過去の支援先は、ココペリ（東証グロース市場IPO）、カウリス（東証グロース市場IPO）、Resily（M＆A）、コミューン、YESOD、エンペイ、アガサ、MyRefer等。
