Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

AI Engineering Summit
https://ai-engineering-summit.findy-tools.io/
での登壇資料です

Avatar for KAKEHASHI

KAKEHASHI

June 17, 2025
Tweet

More Decks by KAKEHASHI

Other Decks in Technology

Transcript

  1. © KAKEHASHI Inc. All Rights Reserved. 高梨 慎人 タカナシ マコト Pharmacy-Ops

    Business Domain プロダクトリード /プロダクトマネージャー 九州在住。趣味は自転車と釣り 自己紹介
  2. © KAKEHASHI Inc. All Rights Reserved. 今日話すこと • 前半 エージェント時代のVertical SaaSのプロダクト戦略

    ◦ SaaS と AIエージェントとの関係性と市場動向。それを受けてカケハシ のような Vertical SaaS のプロダクト戦略の一例をご紹介します • 後半 戦略実行におけるカケハシのプラクティス紹介 ◦ 生成AIプロダクト開発において多々発生する新しい論点に対する備え ◦ 開発体制に関する試みと課題 ◦ AIワークフロー構築プロセスにおけるプラクティス ◦ などをご紹介します
  3. © 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
  4. © KAKEHASHI Inc. All Rights Reserved. 出典) The AI agent

    market map https://www.cbinsights.com/research/ai-agent-market-map/
  5. © KAKEHASHI Inc. All Rights Reserved. SaaS A SaaS B

    SaaS C SaaS D 要はこういうこと AIエージェント層
  6. © KAKEHASHI Inc. All Rights Reserved. SaaS A SaaS B

    SaaS C SaaS D AIエージェント層 ← What is This? Cursor? ChatGPT? Claude? Windows? Other? 自社のポジショニングにより “あなたにとってのエージェント” は変わる
  7. © 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
  8. © 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活用リスクへの対応、エージェ ントの振る舞いに対する免責
  9. © 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ガイドライン)
  10. © 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
  11. © 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ラッパーに成り下がる • 競合との差別化もしにくく、該当の業種の プロダクト自体が均質化 = 相対的に価値 が下がっていく
  12. © 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
  13. © KAKEHASHI Inc. All Rights Reserved. 前半のまとめ • 規制産業においては、エージェント自体に厳しい要件が求められる =

    専用エージェントが必要 • SaaS の API エコシステムとエージェントをワンストップで提供 = 支配的ポジション • Domain Specific エージェントで先行できれば Agent Supplier とし ての新たなポジション構築 = 事業的にも拡大余地が大きい
  14. © KAKEHASHI Inc. All Rights Reserved. しかもたくさん 戦略・戦術固着 技術的不確実性 大きすぎる

    バッチサイズ 従来とは異なる コスト構造 未整備なルール 実験・評価の 難しさ
  15. © KAKEHASHI Inc. All Rights Reserved. つまり • 重厚長大な計画を立てて、その戦略に固着してしまうと市場変化に適応で きない(ピボット時のダメージがデカすぎる)

    • 技術的パラダイムが数ヶ月レベルで変わる • 未整備なルール。プロジェクト進行に伴い頻出する新しい論点 • コスト x 性能 x 市場価値 の最適化 • これまでのMLプロジェクトと異なるプラクティス。特にドメインエキス パートとのシームレスな協業体制は重要
  16. © KAKEHASHI Inc. All Rights Reserved. • ケース1 やってみないとわからないことが多すぎる •

    ケース2 生成AI開発チームは Stream-aligned であり Platformer である • ケース3 AIワークフロー作りの難しさ with ドメインエキスパート ケース 1 ケース 2 ケース 3
  17. © 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における医療用語認識 精度の課題 学び 学び 学び
  18. © KAKEHASHI Inc. All Rights Reserved. Dev User Biz ガバナンス

    部門 リスマネ 法務 事業企画 BizDev CS セールス 顧客 競合 Domain Expert GoTo Market 事業性 ガバナンス、 リスク管理 適法性、 個人情報保護 技術 品質評価、 ドメイン知識 競合優位、 PMF 販売戦略 Data Scientist プロダクトマネージャー /プロダクトリード デザイナー UX 精度 エンジニア
  19. © KAKEHASHI Inc. All Rights Reserved. ソリューションアーキテクチャ 従来の「ML部分だけを切り出して 任せる」という構造が機能しづらい →

    生成AIの出力と、それを活用するプ ロダクト体験まで一気通貫で責任を もつ → Team Topologies でいう Stream-aligned な役割が求め られる
  20. © KAKEHASHI Inc. All Rights Reserved. ソリューションアーキテクチャ 対して、生成AIサービスと接続する LLM Hub

    層は社内で再利用性を 高めたい  + AIガバナンスの強化やガードレール 機構などを加味すると共通PFが望 ましい → Team Topologies でいう Platformer な役割が求められる
  21. © KAKEHASHI Inc. All Rights Reserved. チャレンジと取り組み • フルスタックな技術体制をどうスケールできるかが鍵 •

    生成AI開発チームが様々なプロダクトチームと連携しながら、生成AIプロ ダクト開発のノウハウの伝道者となる • アメーバ的に広がって生成AI開発に強い人材を増やす
  22. © KAKEHASHI Inc. All Rights Reserved. AIワークフローの 初版作成 ワークフローの Try

    & Error と 精度目標の達成 正式なワークフ ローとして実装 LLMOps Data Scientist Engineer Domain Expert CoE Product Domain Expert
  23. © KAKEHASHI Inc. All Rights Reserved. AIワークフローの 初版作成 ワークフローの Try

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

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

    DSやEngに頼らずにアイデアをカジュア ルに試すことが可能 • 全社共通のデータ基盤 • Dify + notebook + データを活用し て実験評価用のワークフローを構築 • ダッシュボードなどで結果も共有可能 • databricks に統合されている • notebook からワークフローの入出力 をトレース • メトリクスを計算し Experiment ごとに 記録
  26. © KAKEHASHI Inc. All Rights Reserved. • 進めるたびに多様な観点で新しい論点が発生 ◦ → フロンティアを切り開く覚悟 + クロスファンクショナルな体制

    • Stream-aligned 兼 Platformer というフルスタックな技術体制でプロダクト価 値にコミットして開発 • ワークフロー開発においてDE(非Tech人材)含む各職種ごとの関心事を分離し、集中 できる体制と仕組みの構築が重要 後半のまとめ
  27. © KAKEHASHI Inc. All Rights Reserved. 今後の方向性、チャレンジ • Domain Specific

    AI Agent を構築し爆速で能力を拡張する!! • 生成AI開発プロダクト開発人材の発掘・育成!! • 生き残っていく技術(MCP, A2A, ADK etc…)を見極める!!