"SaaS is Dead" は本当か！？生成AI時代の医療 Vertical SaaS のリアル

by KAKEHASHI

Slide 1

Slide 1 text

©KAKEHASHI inc. "SaaS is Dead" は本当か！？生成AI時代の医療 Vertical SaaS のリアル 2025/06/18 株式会社カケハシ高梨慎人

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© KAKEHASHI Inc. All Rights Reserved. 今日話すこと ● 前半　エージェント時代のVertical SaaSのプロダクト戦略 ○ SaaS と AIエージェントとの関係性と市場動向。それを受けてカケハシのような Vertical SaaS のプロダクト戦略の一例をご紹介します ● 後半　戦略実行におけるカケハシのプラクティス紹介 ○ 生成AIプロダクト開発において多々発生する新しい論点に対する備え ○ 開発体制に関する試みと課題 ○ AIワークフロー構築プロセスにおけるプラクティス ○ などをご紹介します

Slide 5

Slide 5 text

©KAKEHASHI inc. 【前半】エージェント時代の Vertical SaaSのプロダクト戦略 5

Slide 6

Slide 6 text

©KAKEHASHI inc. SaaS is Dead 6

Slide 7

Slide 7 text

© KAKEHASHI Inc. All Rights Reserved. “ AIの影響はSaaS業界の真の終焉ではなく、むしろ再生、さらにはチャンスをもたらすものだと私は考えています。先進的な SaaS企業はすでにAI機能を自社のサービスに統合し、時代遅れになるのではなく、価値提案を強化しています。重要なのは、迅速に適応し、AIを活用して、よりインテリジェントで効率的、そしてパーソナライズされたソフトウェアソリューションを生み出すことです。出典) Is SaaS dead? Not quite, but it’s evolving rapidly を翻訳 https://www.cio.com/article/3627921/is-saas-dead-not-quite-but-its-evolving-rapidly.html SaaS is Dead … ? “ 複数のSaaSアプリケーションを理解する“エージェント層”を作るわけです。これまでSaaSアプリケーションはビジネスロジックとCRUD（Create/Read/Update/Delete）の塊でしたが、そのCRUD部分をアプリの外側でオーケストレーションする形になるのが大きな変化だと思います。出典) 「SaaSは死んだのか？」サティア・ナデラが語るAI時代のクラウドビジネス https://note.com/daka1/n/n6ba507aa0b1b

Slide 8

Slide 8 text

Slide 9

Slide 9 text

©KAKEHASHI inc. AIエージェント 9

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

©KAKEHASHI inc. あなたにとってのエージェントとは？ 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© KAKEHASHI Inc. All Rights Reserved. ● SaaS がマルチベンダで提供 ● 複数の SaaS を統合することに価値 ● エージェントの受託開発などもこの領域 ● 例） Cursor, Devin etc SaaS + AI Core Player S a a S A AIエージェント層 S a a S B S a a S C S a a S D SaaS ＋ Single Agent (AI Function) エージェントA S a a S A AIエージェント層 S a a S B S a a S C S a a S D Agent Supplier Agentic SaaS Platformer ● SaaS 自体が非常に独自性が強い or 支配的ポジション ● AI で自身の利便性向上 ● 更に、様々なエージェントから利用されることで競合優位を維持 ● 例） Figma, Notion etc ● Vertical SaaS（強い参入障壁）　＋　マルチプロダクト ● AIエージェントにもドメイン固有要件が求められる ● 例）医療SaaS+エージェント、金融SaaS+エージェント etc エージェントB MCP S a a S A S a a S B

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© KAKEHASHI Inc. All Rights Reserved. ● エージェントとSaaSをワンストップで提供することができればエコシステムがより強化され支配的ポジションを取れる ● SaaS側のAPIのエコシステムの価値は一定残存 ● （現時点では）SaaS側がMCPを公開するメリットが薄い　＝　エージェントとSaaS がセットで提供されることが重要 S a a S A AIエージェント層 S a a S B S a a S C S a a S D Agentic SaaS Platformer ● AI エージェント自体にも Domain Specific な要件が求められ参入障壁が高い ○ 例）業法対応、業種別のガイドラインへの適応、AI倫理・AI活用リスクへの対応、エージェントの振る舞いに対する免責

Slide 19

Slide 19 text

© KAKEHASHI Inc. All Rights Reserved. カケハシが考える薬局AIエージェントと求められる要件オーケストレーター AI ワークフロー（医療書類作成） AI ワークフロー (薬事設計) AI ワークフロー（医療コミュニティ） AI ワークフロー（患者フォロー） and so on ... T o o l C a ll LLM Hub SaaS SaaS SaaS LLM LLM LLM ● シンプルなワークフロー ● 説明可能性、安全性、コントロール性 ● 相互認証 ● 個人情報の取り扱い ● DPA ● データ保存 Region の制約 ● 性能、コストの制約 ● セキュア通信 ● Hard Law（個人情報保護法、業法） ● Soft Law（3省2ガイドライン）

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© KAKEHASHI Inc. All Rights Reserved. https://www.itmedia.co.jp/news/articles/2505/29/news092.h tml https://blogs.windows.com/japan/2025/03/17/a-deeper-look-at-mic rosoft-dragon-copilot-transforming-clinical-workflow-with-ai/ https://www.publickey1.jp/blog/25/windowsmcpaiwi ndows.html https://www.youtube.com/watch?v=H7zBHYDAuFY

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© KAKEHASHI Inc. All Rights Reserved. S a a S A AIエージェント層 S a a S B S a a S C S a a S D Microsoft Dragon Copilot Vertex AI Search for Healthcare 脅威 Agentic Web/OS こうなると、、、 ● SaaS は本当にDBラッパーに成り下がる ● 競合との差別化もしにくく、該当の業種のプロダクト自体が均質化　＝　相対的に価値が下がっていく

Slide 24

Slide 24 text

© KAKEHASHI Inc. All Rights Reserved. S a a S A AIエージェント層 S a a S B S a a S C S a a S D Microsoft Dragon Copilot Vertex AI Search for Healthcare 脅威チャンス Agentic Web/OS S a a S A Domain Speciftc AI Agent 層 S a a S B S a a S C S a a S D Generic AI Agent 層 Agentic Web/OS KAKEHASHI Pharmacy AI

Slide 25

Slide 25 text

© KAKEHASHI Inc. All Rights Reserved. 前半のまとめ ● 規制産業においては、エージェント自体に厳しい要件が求められる = 専用エージェントが必要 ● SaaS の API エコシステムとエージェントをワンストップで提供＝支配的ポジション ● Domain Specific エージェントで先行できれば Agent Supplier としての新たなポジション構築 = 事業的にも拡大余地が大きい

Slide 26

Slide 26 text

©KAKEHASHI inc. 【後半】戦略実行におけるカケハシのプラクティス紹介 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© KAKEHASHI Inc. All Rights Reserved. つまり ● 重厚長大な計画を立てて、その戦略に固着してしまうと市場変化に適応できない（ピボット時のダメージがデカすぎる） ● 技術的パラダイムが数ヶ月レベルで変わる ● 未整備なルール。プロジェクト進行に伴い頻出する新しい論点 ● コスト x 性能 x 市場価値の最適化 ● これまでのMLプロジェクトと異なるプラクティス。特にドメインエキスパートとのシームレスな協業体制は重要

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© KAKEHASHI Inc. All Rights Reserved. ● 単一タスクに特化したシンプルなAIワークフロー ● ワークフロー構築プロセスの洗練 ● Tool Call や構造化出力のノウハウ蓄積 ● 医療AIにおけるLLM Platform 24年9月 24年12月 25年5月医療書類自動生成（単独プロダクト） ● 服薬指導AI ● AI薬剤師 ● 複雑なAIワークフロー vs 完全自立型AI（どちらも人の手に余る） ● エージェント x AIワークフロー構築における適切な開発粒度のノウハウ蓄積 ● AIプロダクトのポリシー整備薬局AI β （製品搭載） ● 初めての生成AIプロダクト開発 ● プロンプティングのノウハウ蓄積 ● 精度評価における課題の把握 ● STTにおける医療用語認識精度の課題学び学び学び

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© KAKEHASHI Inc. All Rights Reserved. Dev User Biz ガバナンス部門リスマネ法務事業企画 BizDev CS セールス顧客競合 Domain Expert GoTo Market 事業性ガバナンス、リスク管理適法性、個人情報保護技術品質評価、ドメイン知識競合優位、 PMF 販売戦略 Data Scientist プロダクトマネージャー /プロダクトリードデザイナー UX 精度エンジニア

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© KAKEHASHI Inc. All Rights Reserved. AIワークフローの初版作成ワークフローの Try & Error と精度目標の達成正式なワークフローとして実装 LLMOps Data Scientist Engineer Domain Expert CoE 実験・評価。探索的な Try & Error を DS&DE（非Tech人材）とともに高速に進めたい確定したワークフローを本番環境に適切な技術で実装することに集中したい実験・評価環境と一貫した機構、メトリクスで本番の LLMOps 環境を構築したい Product Domain Expert →それぞれの関心事を分離して、集中できる体制と仕組みの構築が必要

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© KAKEHASHI Inc. All Rights Reserved. ● ドメインエキスパートがノーコードでフローを作成 ● DSやEngに頼らずにアイデアをカジュアルに試すことが可能 ● 全社共通のデータ基盤 ● Dify +　notebook ＋データを活用して実験評価用のワークフローを構築 ● ダッシュボードなどで結果も共有可能 ● databricks に統合されている ● notebook からワークフローの入出力をトレース ● メトリクスを計算し Experiment ごとに記録

Slide 51

Slide 51 text

© KAKEHASHI Inc. All Rights Reserved. ● 進めるたびに多様な観点で新しい論点が発生 ○ →　フロンティアを切り開く覚悟　＋　クロスファンクショナルな体制 ● Stream-aligned 兼 Platformer というフルスタックな技術体制でプロダクト価値にコミットして開発 ● ワークフロー開発においてDE（非Tech人材）含む各職種ごとの関心事を分離し、集中できる体制と仕組みの構築が重要後半のまとめ