“SaaS is Dead”は本当か!? 生成AI時代の医療VerticalSaaSのリアル

“SaaS is Dead”の文脈から読み解く、SaaSの未来

日本の医療が抱える課題と向き合うカケハシ

株式会社カケハシの高梨と申します。本日は「“SaaS is Dead”は本当か!? 生成AI時代の医療Vertical SaaSのリアル」と題して、お話しさせていただきます。私は薬局向けのDX SaaSビジネスを担当しているPharmacy-Ops Business Domainのプロダクトリードとして、九州からフルリモートで働いています。

カケハシはヘルステックスタートアップとして、調剤薬局DXを入り口に日本の医療が抱える課題に向き合うべく、複数の事業を展開しています。

本日は前半に「エージェント時代のVertical SaaSのプロダクト戦略」と題して、“SaaS is Dead”というキーワードを絡めながら、カケハシのプロダクト戦略の一例をご紹介します。
後半は「戦略実行におけるカケハシのプラクティス紹介」として、生成AIプロダクト開発を進める中で得たプラクティスをご紹介します。

“SaaS is Dead”から分析できる、三つの戦い方

“SaaS is Dead”について、米MicrosoftのCEOの発言を引用させてください。

複数のSaaSアプリケーションを理解する“エージェント層”を作るわけです。これまでSaaSアプリケーションはビジネスロジックとCRUD（Create/Read/Update/Delete）の塊でしたが、そのCRUD部分をアプリの外側でオーケストレーションする形になるのが大きな変化だと思います。
（引用：daka | Microsoft | AI、note、「SaaSは死んだのか？」サティア・ナデラが語るAI時代のクラウドビジネス、https://note.com/daka1/n/n6ba507aa0b1b​）

ここから推測できるのは、今まで個別のSaaSを使用していたところから、今後はオーケストレーションされて、AIエージェント層から使われるようになるということ。
SaaSは死んだわけではないものの進化が必要だと、重要なのは“適応戦略”だと言っているのだと思います。

またAIエージェントの定義には様々な説がありますが、 CB Insights の記事（The AI agent market map： https://www.cbinsights.com/research/ai-agent-market-map/ ）によると、AIエージェントとは「自立的」であることがひとつのキーワードだと書かれています。

もっと言うと、Reasoning（リーズニング）、External memory（エクスターナルメモリー）、Tool use（ツールユース）、Planning（プランニング）が含まれており、自分で考えて外部のツールを利用しながら自立的に動くものだと定義されています。
つまりは、SaaSはAIエージェント層のバックエンドとして扱われるようになり、ユーザーはAIに話しかけることで全ての機能を利用できるようになると考えられているのです。

“SaaS is Dead”の文脈でプロダクト戦略を再定義する際には、「あなたにとってのエージェントとは？」という問いが重要になってくると考えています。 CursorやChatGPTなど、AIエージェントになり得るものは複数存在していますし、最適なエージェントは各社のポジショニングによって異なるからです。

それを踏まえて、現在は「エージェント開発＝専用エージェント化の流れ」が来ています。そういった業界の動きを踏まえると、SaaSとそれを取り巻くプレイヤーの戦略は大きく三つに類型化されるでしょう。

左の「Agent Supplier」はSaaS事業者であるかどうかに関係なく、AIエージェント層自体を提供するプレイヤーを表しています。複数のSaaSを統合することに価値があり、CursorやDevinはこの領域に当てはまると思います。エージェントの受託開発もここですね。

真ん中の「SaaS＋AI Core Player」は、シングルエージェントもしくはAIファンクションを載せつつ、SaaSの機能をMCPで公開して複数のエージェントに幅広く利用してもらうスタイルです。従来のスタイルに近い形であり、独自性が強いもしくは支配的なポジションを獲得しているSaaSはこのような戦略を取るパターンもあると思います。

右の「Agentic SaaS Platformer」は、SaaSとAIエージェントをワンストップで提供するスタイルです。Vertival SaaSを展開している会社はこのような形を取ることが多いと考えています。なぜなら、Vertical SaaSは前提として参入障壁が高いため支配的ポジションを構築しやすく、AIエージェントにもドメイン固有の要件が求められるからです。カケハシもこのスタイルを目指しています。

医療SaaSが目指すべきAgentic SaaS Platformerとは？

ここからは、カケハシ（医療SaaS）の戦略について、具体的にお話ししていきます。
「Agentic SaaS Platformer」の有意性は、エージェントとSaaSをワンストップで提供することで、エコシステムが強化されて支配的なポジションが取れるという点にあります。

レイヤー別に考えると、SaaS側のAPIのエコシステムの価値は一定残存すると思います。エージェントがMCPを介してSaaSを操作するといっても、その裏側ではAPIが動くことになるからです。また現時点ではSaaS側がMCPを公開するメリットがないため、エージェントとSaaSがセットで提供されることが重要だといえます。

AIエージェント自体にもドメインスペシフィックな要件が求められるため、ここを自社で開発できれば支配的ポジションを確立できると思います。

それを踏まえて、カケハシが考える薬局AIエージェントと求められる要件を簡易的にまとめました。

ユーザーと向き合うエージェント層はオーケストレーターとして複数のAIワークフローを束ねる比較的シンプルな構成です。エージェントと通信する部分は、医療ドメインならではの要件で相互認証が求められます。

ワークフローについては、シングルエージェントもしくはAIワークフローなど、さまざまな呼び方があると思いますが、いずれにしてもシンプルに構築することが大切だと考えています。医療でAIを活用するのはハイリスクユースケースであり、情報の透明性が非常に重要だからです。複雑に作り込んだり、自律的に全てをAIに任せてしまったりすると説明可能性を担保できなかったり、何か医療的に問題があった場合の免責リスクを抱えることになります。
シンプルかつコントロール性重視で構成しています。

LLMとの接続層は共通化したいため、LLM Hubを設けています。一つ補足すると、医療ユースケースで使えるLLMは限定的で、個人情報の取り扱いやDPA（データの利用契約）、データ保存のリージョンの制約を受けます。性能やコストの制約をクリアにした上で、どのようにしてエージェントを作っていくかを考えなくてはいけませんし、難易度の高い挑戦だとは思います。しかし、成功すれば、他者には真似できない競争力が生まれるはずです。

ただ、このような戦略を立てているのは、カケハシだけではありません。GoogleやMicrosoftなどのビッグ・テックに加えて、OpenAIなども同様の動きを見せています。これは非常に脅威ですし、AIエージェント層がビッグ・テックもしくは汎用的なWebOSレイヤーに取られる可能性もあります。

しかし、ピンチはチャンスです。
例えば、AIエージェント層が、ビッグ・テックもしくは汎用的なWebOSレイヤーに取られた場合、コモディティ化してSaaS側の価値は下がってしまうでしょう。カケハシでは、そうなる前にドメインスペシフィックなAIエージェントを構築して、Generic AI Agent層やAgentic Web/OSのバックエンドポジションを獲得したいと考えています。

Generic AI Agent層やAgentic Web/OSが薬局AIエージェント（KAKEHASHI PharmacyAI）を通して薬局業務を横断的に利用するといった形にできると、エージェントサプライヤーのような立ち位置を獲得できます。そう考えるとビジネス的にも非常に価値が大きいですし、カケハシではスピード感を持って薬局AIエージェントの開発に取り組んでいます。

今後は「新たなポジション」を獲得するための戦略が求められる

まとめます。

医療や金融、教育といった規制産業においては、エージェント自体に厳しい要件が求められるため、専用エージェント化を通して、ユースケースにしっかり対応できるようにすることが重要です。

SaaSのAPIエコシステムとエージェントをワンストップで提供できると支配的ポジションを獲得できますし、ドメインスペシフィックエージェントで先行できれば、エージェントサプライヤーとしての新たなポジションが構築できます。

新たな販売チャネルができることで、事業的にも拡大余地が生まれるため、投資する価値が非常に高いと言えるのではないかと考えています。

課題を乗り越えて得た、生成AIプロダクト開発におけるプラクティス

生成AIプロダクト開発でぶつかった課題の数々…

「戦略実行におけるカケハシのプラクティス紹介」についてもお話しします。

戦略実行フェーズでは、様々な現実的な課題が出てきます。

つまりは、重厚長大な計画を立てて、戦略に固着してしまうと市場変化に対応できなくなるのです。

また技術的パラダイムが数ヶ月レベルで変わっていく現代においては、どのような技術で開発をするのか決めるのも難しいですよね。
社内外ともにルールが未整備で、プロジェクト進行に伴い新しい論点が頻出するという問題もあります。コスト×性能×市場価値の最適化も考えなくてはいけませんし、これまでのMLプロジェクトとは異なるプラクティスが求められるのも難しいポイントだと思います。特に非Tech人材であるドメインエキスパートをシームレスに巻き込む協業体制も重要かなと。

ここからは、こういった課題に対するカケハシの取り組み事例と得られた学びを三つ共有します。

ケース1：やってみないとわからないことが多すぎる

カケハシでは、この8ヶ月でプロダクトを四つ作って三つ捨てました。

タイムラインでまとめると下図の通りです。

まずは、24年9月に医療書類自動生成の単独プロダクトをリリースしました。これは展示会向けに作ったもので、カケハシとしては初めて開発した生成AIプロダクトです。この開発を通して、プロンプティングのノウハウを蓄積できたほか、精度評価の課題を把握できました。また医療用語認識制度の課題に直面したことで、ヒューマンインザループの重要性を認識できました。

3ヶ月後には服薬指導AIとAI薬剤師を開発したのですが、これらはすぐに捨てました。というのも、当時はAIエージェントといえば自立型AIが正義だとされていたため「複雑なAIワークフローで完全自立的に動くもの」と「LLMの能力を生かした自立型AI」を作ったのですが、どちらも人の手に余るものになってしまったのです。

ただ、これによって「シンプルに構築しないとコントロールが効かなくなる」と学びましたし、エージェント × AIワークフロー構築における適切な開発粒度に関するノウハウが得られました。あとは「どこまでをAIに任せるのか」という、顧客向けのAIプロダクトのポリシーを整備することができました。

三つのプロダクト開発から得られたノウハウを生かして、25年5月には薬局AIのβ版を製品に搭載しました。ここでは医療AIにおいて求められるLLMプラットフォームの要件についても整理できましたし、単一タスクに特化したシンプルなAIワークフローを意識するとともに、ドメインエキスパートを開発プロセスにシームレスに巻き込んでいく実践的なプロセスも構築できました。その点については後ほど改めてお話しします。

このように、何かするたびに新しい論点、新しい課題にぶち当たりましたし、都度立ち止まって課題を解決して次に進んでいかなくてはいけませんでした。プラクティスやルールが整備されているのを待っていたら一生始まらないでしょうし、フロンティアを切り開く覚悟でやることが重要です。

また、その際にはクロスファンクショナルなプロジェクト体制を構築することが成功の鍵となります。

そして、それをうまく繋ぎ合わせるためには、推進力が必要です。カケハシの場合、私のようなプロダクトマネージャー兼プロダクトリードが、全てのステークホルダーをつなぎ合わせる役割を担っていました。

上図に書いているような人たちと高頻度にコミュニケーションを取り、巻き込んでいく。そういった強烈な推進者が、必ず一人は必要です。そういった人がいなければ、AIプロダクトの開発は進んでいかない、ということを強くお伝えしたいです。

ケース2：生成AI開発チームはStream-alignedでありPlatformerである

上図はカケハシのプロダクトのソリューションアーキテクチャです。左側はAIが組み込まれるプロダクトサイドですね。

従来のMLプロジェクトは エージェントアプリケーション（バックエンドのMLの部分）がマイクロサービスのような形で提供されるケースが多かったと思うのですが、今回の生成AIプロダクトでは、生成AIプロダクト開発チームが生成AIの出力とそれを活用するプロダクト体験まで一気通貫で担う形にしています。

これはTeam Topologiesでいう、Stream-alignedの役割だと思います。

なぜこのようにしているかというと、予想外の出力が多いことを考えると、UXに合わせて最適化しないとプロダクトとして作り込めないからです。

一方で、再利用性を高めるために、できるところは共通プラットフォームとして作っています。再利用性を高めるだけではなく、AIガバナンスの強化やガードレール機構を加味すると、共通プラットフォームが望ましいでしょう。
これはTeam Topologiesでいう Platformer であり、一つのプロダクトの開発に異なる役割が共存することとなります。

つまり、どうしてもフルスタックかつハイレベルな開発体制が求められてしまいます。実際のところ、私が所属しているチームにはシニアエンジニアしかいませんし、エース級のエンジニアが揃っています。
ただ、このまま体制をスケールしようとしても難しいため、生成AI開発チームが各プロダクトチームにガッツリ入り込んで、各チームのメンバーと一緒に生成AIプロダクトを作るようにしています。シニアエンジニアが各チームに生成AIプロダクト開発のノウハウを伝道し、それを繰り返すことで生成AI開発に強い人材をアメーバ的に増やそうという作戦です。

ケース3：AIワークフロー作りの難しさ withドメインエキスパート

カケハシのように医療ドメインで事業を展開している場合、AIワークフローを作る際は、ドメインエキスパートが必要不可欠です。弊社では、薬剤師が非常に重要な役割を果たしています。

上図はカケハシのAIワークフロー作りのプロセスを図にしたものです。

まずはドメインエキスパートが初版を作り、精度目標を達成するために実験評価環境でTry&Error をして、それをエンジニアが正式なワークフローとして実装してサービングし、LLM Opsにつながると。

ここで特徴的なのが前半のプロセスです。正直なところ、初版はドメインエキスパートでなければ作れません。生成AIの出力がかなり非決定的であるため「どんな入力を与えたらどういう出力が出てくるか」というのは、素人だと想像できないのです。“筋のいい入力と出力の仮説”を立てるには、ドメインエキスパートの協力が必要です。

とはいえ、ドメインエキスパートは非Tech人材が多いため、次はデータサイエンティストが実験評価環境で評価をしていきます。
このとき、ヒューマン・イン・ザ・ループのようなアプローチを取ることが多いと思うのですが、1人のドメインエキスパートに依存するとバイアスがかかってしまいます。複数人で評価することが重要ですので、カケハシでは、Center of Excellenceのようなドメインエキスパートの集団に評価を依頼するようにしています。

ただ、非Tech人材に協力を依頼すればするほどコミュニケーションコストは高くなってしまいがちですし、カケハシでも実際にそういった課題がありました。そこで現在は、それぞれの関心事を分離して集中できる体制と仕組みを構築するために、下図のような機構で進めています。

なぜこのような機構を採用しているのかというと、Difyはノーコードでフローを作成できるため、エンジニアやデータサイエンティストに頼ることなくドメンエキスパート自身でアイデアをカジュアルに試すことができるからです。

ただDifyだけで実験評価用、およびプロダクションコードで再現性のあるフローを作ることは難しいため、DatabricksとMLflowを使っています。カケハシでは全社共通のデータ基盤としてdatabricksを使用していて、Dify＋notebook+データ基盤を活用すれば、プロダクションで再現性のある実験評価用のワークフローを構築できます。結果はダッシュボードで共有できるため、再現性と社内への展開性を高めることができています。

MLflowはDatabricksに統合されていて、シームレスに使えるのが良いですね。DatabricksのnotebookからコールしたメトリクスをExperimentごとに記録できますし、共通基盤上で動いているため簡単に全社に展開できます。

三つの事例を通して得た学び

後半のまとめです。

進めるたびに多様な観点で新しい論点が発生するため、PLやPdMといった責任者は、フロンティアを切り開く覚悟が必要です。またクロスファンクショナルな体制を作った上で、プロジェクトを推進してくれるような存在を用意できるかどうかが成功の鍵だといえます。

Stream-aligned兼Platfomerというフルスタックな技術体制でプロダクト価値にコミットして開発するために、最初は強力なエンジニアメンバーで進めるのが良いと思います。そのあとにチームをスケールさせるためには、戦略を持って取り組んでいった方がいいと思います。

ワークフロー開発においては、ドメンエキスパート（非Tech人材）を含む各職種ごとの関心事を分離して、集中できる体制と仕組みを構築する必要があります。ここはそれぞれの事業や組織に合わせた形で良いと思いますが、ソリューションを導入して生産性の高い仕組みを構築することがポイントです。

大型資金調達を達成し、次のフェーズに向かう

医療SaaSは要求水準が高く難易度の高い領域ではありますが、AIエージェント時代において、事業領域を一気に拡大できる一世一代の風が吹いています。

またカケハシは2025年6月にシリーズDで合計約140億円の大型の資金調達を達成し、PM、EM、エンジニアを60人以上採用することを目指しています。採用にアクセルを踏み込んでいる状態ですので、興味を持っていただけたなら、ぜひ一度お話しさせてください！

最後に、本日は技術についてあまり触れられませんでしたが、MCPやA2A、ADKなど、今後デファクトスタンダードになるであろう技術を見極めて、技術の乗せ替えも積極的に行っていきたいと考えています。テックブログもやっていますので、こちらもフォローして読んでいただけますと幸いです。

本日はご清聴ありがとうございました。

▶KAKEHASHI Tech Blog
https://kakehashi-dev.hatenablog.com/

当日は参加者からの質問にも答えていただきました。
詳細はアーカイブ動画にてご覧ください。
https://findy-tools.io/events/80d36f502e622d650359