SaaS is dead? ――AIはUIを殺すのか？ドメイン特化型UI・MCP・デザイナーの役割から多角的に考察する
Published on 2026年2月9日
アーキテクチャ1. はじめに -「SaaS不要論」への違和感
本記事は筆者個人の考察です。 「SaaS is dead」をめぐる議論にはさまざまな立場や見解があり、AIがUIを完全に代替するという主張にも一定の合理性があります。本記事はそれらを否定するものではなく、AIの技術的制約・MCPの可能性・UI/UXデザイナーの役割といった複数の観点から、UIがどのように変化していくのかを考察するものです。
最近、テック業界では「SaaS is dead」という言葉が飛び交っています。「AIがすべての作業を自動化すれば、ユーザーが個別のSaaSにログインして操作する必要はなくなり、UIそのものが不要になる」という論理です。
しかし、私はこの議論に対して明確な違和感を持っています。 結論から言えば、SaaSのUI/UX設計は死なず、むしろAIチャットの中に「溶け込み、埋め込まれる」形へと進化していくと考えています。
2. AIの限界 - なぜ「チャットだけ」では解決しないのか
AI（汎用LLM）は強力ですが、「AIがUIも含めてすべて都度生成すればいい」という主張には、見過ごせない3つの限界があります。
2-1. コンテキストとドメイン知識の欠如
AIは言語の扱いに長けていても、特定の企業や業界独自の「正しい業務ルール（ドメイン構造）」を完全には把握していません。ファインチューニングやRAGである程度補えるとしても、業務フローの中で蓄積された暗黙のルール――「この項目は必ずこの順序で入力しなければならない」「この金額を超えたら別の承認者が必要」といった粒度の知識を、汎用AIが網羅的に保持し続けることは現実的ではありません。
2-2. レスポンスの壁 - 都度生成の体験コスト
仮にAIがドメイン知識を持っていたとしても、課題を解釈し、適切なUIを都度生成するプロセスには必ず「待ち時間」が発生します。経費精算のフォーム1つ表示するのに数秒かかるなら、既存のSaaSで画面遷移したほうが速い。
SaaSが事前にUIコンポーネントを**「完成品」として保持している**からこそ、呼び出された瞬間にパッと表示できます。この即応性は、毎回ゼロから生成するアプローチでは原理的に勝てません。ユーザー体験において「待たされる」ことの心理的コストは、機能の優劣以上に大きな離脱要因になります。
2-3. 解決フローの品質保証 - 最も本質的な問題
これが最も重要な論点です。
SaaSのUI/UXは、単なる「見た目」ではありません。「このステップを踏めば確実にゴールに到達する」という検証済みの導線そのものです。入力バリデーション、必須項目の制御、承認フローの分岐――これらは何百回ものユーザーテストと実運用のフィードバックで磨かれてきたものです。
一方、AIが都度生成したUIには、この「品質保証」がありません。生成されたフォームに項目の抜け漏れがあるかもしれない。ステップの順序が業務ルール上間違っているかもしれない。そして最大の問題は、その正しさをユーザー自身が検証しなければならないという点です。
思い出してください。ユーザーは自身の課題を正確に理解していない場合が多いのです（後述の第3章で詳述します）。課題を正確に把握していない人に、解決フローの正しさを判断させる。これでは本末転倒です。
SaaSのUIコンポーネントが持つ本質的な価値を一言で表すなら、それは**「ドメインエキスパートが設計・検証済みの、再現性ある課題解決パス」**です。これはAIが毎回書き捨てる動的生成物とは、根本的に信頼性の次元が違います。テスト済みのライブラリを呼び出すのと、毎回その場でコードを書き捨てるのと、どちらをプロダクションに載せるか――エンジニアであれば答えは明白でしょう。
3. ユーザーの意図、SaaSの専門性、AIの翻訳
課題解決のプロセスは、AI・SaaS・ユーザーがそれぞれの役割を補完し合うことで成立します。
前提として、ユーザーは自身の課題を正確に理解していない場合が多いという事実があります。ユーザーは何かしらの不便を感じ、情報収集を行う中で「なんとなくの雰囲気」で課題を認識し、解決策を探します。この曖昧な状態を解決へ導くのが、以下の三位一体の構造です。
- ユーザー： 抽象的な「解決したい課題（Intent）」を決める 断片的な悩みや「こうしたい」という理想のベクトルをAIに提示します。
- AI： ユーザーの意図を解釈する「オーケストレーター」 ユーザーの曖昧な言葉を解釈し、「これはどのドメインの課題か」を特定します。そして、適切なSaaSを呼び出すためのハブとして機能します。
- SaaS： ドメイン知識による「解決のロジック」と「型」の提供 AIが特定したドメインに対し、「正しいデータ構造」と「解決までの最短ルート」を提供します。第2章で述べた通り、この「最短ルート」は都度生成では代替できない、検証と改善のサイクルを経た確実な導線です。
ユーザーが「何を実現したいか」を口にした瞬間、AIがハブとなり、背後にある最適なSaaSが自動的に選定される。ユーザーはSaaSを選んでいるのではなく、解決策を選んだ結果としてSaaSと繋がるのです。そしてそのとき表示されるUIは、AIがその場で考えたものではなく、SaaS側で磨き上げられた「確実に解決へ向かう型」なのです。
4. MCP（Model Context Protocol）が変える連携の形
この連携を支える技術的根拠が、MCP（Model Context Protocol）です。 AIがMCPを介してSaaSの機能を呼び出す際、単に「データ」をやり取りするだけではなく、「そのドメインにおいて今表示すべき最適なUI」をAIチャット内にレンダリングする形式が、最も現実的な未来像だと私は考えます。
連携のシーケンス図
ユーザー AIオーケストレーター MCP Connector SaaS（ドメイン知識保持者）
│ │ │ │
│ ①「事務作業を │ │ │
│ 効率化したい」 │ │ │
│ ──────────────────> │ │ │
│ │ │ │
│ 【意図を解釈】 │ │
│ これは経費精算の │ │
│ 課題だ │ │
│ │ │ │
│ │ ② 経費精算ツールの │ │
│ │ 呼び出し │ │
│ │ ───────────────────> │ │
│ │ │ │
│ │ │ ③ ドメイン知識と │
│ │ │ 現在の状況を確認 │
│ │ │ ──────────────────> │
│ │ │ │
│ │ │ ④ データ構造 + │
│ │ │ 検証済みUI │
│ │ │ <────────────────── │
│ │ │ │
│ ⑤「未申請が3件あり │ │ │
│ ます。この │ │ │
│ フォームで │ │ │
│ 確認して │ │ │
│ ください」 │ │ │
│ <────────────────── │ │ │
│ │ │ │
│ ※ チャット内にSaaS特化UIを埋め込み │
│ （都度生成ではなく事前設計済み） │
│ │ │ │
│ ⑥ 埋め込みUI上で │ │ │
│ 承認・確定 │ │ │
│ ──────────────────> │ │ │
│ │ │ │
│ │ ⑦ MCP経由で処理実行 │ │
│ │ ─────────────────────────────────────────> │
│ │ │ │
「SaaSの画面（目的地）」へ行くのではなく、「AIチャット（自分の居場所）」へSaaSの機能がパーツとしてやってくるのです。しかもそのパーツは、AIが即興で作ったものではなく、ドメインエキスパートが設計し、実運用で磨かれた「完成品」です。だからこそ速く、確実なのです。
5. 「どのSaaSをAIと繋ぐか」という新たな意思決定
ここまでの議論で、AIがオーケストレーターとしてSaaSを呼び出す未来像を描いてきました。しかし、その手前に見落としてはならないステップがあります。「どのSaaSをAIと連携させるか」を人間が決めるという意思決定です。
今も企業は「どのSaaSを導入するか」を判断しています。AI時代になったからといって、その意思決定が消えるわけではありません。変わるのは選定基準です。これまでは「UIが使いやすいか」「必要な機能が揃っているか」が中心だった評価軸に、「AIとの連携品質はどうか」「MCPに対応しているか」「UIコンポーネントをAIチャット内に埋め込める設計になっているか」といった新しい軸が加わります。
この事実を踏まえると、課題解決のエコシステムには三層の構造が見えてきます。
- 企業の意思決定者： どのSaaSをAIエコシステムに接続するかを事前に選定する。AIが参照できる「選択肢の範囲」を決める役割。
- AI（オーケストレーター）： 選定済みのSaaS群の中から、ユーザーの意図に最も適したものを呼び出す。あくまで与えられた範囲内で最適化する存在。
- エンドユーザー： 課題を正確に理解していないまま、AIに意図を伝えるだけで解決に辿り着く。
つまり、AIは万能の選定者ではなく、人間が設計したエコシステムの中で力を発揮する存在です。この構造は、本記事の「AIだけでは完結しない」という主張とも一貫しています。
そしてSaaSベンダーにとっても、「AIに自動的に選ばれる」ことを目指すのではなく、企業の意思決定者に「AIと繋ぐ価値がある」と判断されることが引き続き競争の核になります。その判断材料こそが、第2章で述べた「検証済みの導線」の品質であり、MCPへの対応品質であり、AIチャットに埋め込まれたときに確実に機能するUIコンポーネントの完成度なのです。
6. UI/UXデザイナーの役割は「ページ」から「コンポーネント」へ
この未来において、UI/UXデザインは不要になるどころか、より高度な設計が求められます。
ここで重要なのは、UI/UXデザイナー自身は特定のドメインに特化した専門家ではないという点です。経理の専門家でも、人事の専門家でも、物流の専門家でもない。では、なぜ彼らがSaaSにおいて不可欠なのか。
それは、本記事で繰り返し述べてきた**「ユーザーは自身の課題を正確に理解していない」という前提に立ち返れば明らかです。ユーザーが課題を理解していないからこそ、SaaSというサービスの提供形態では、UI/UXデザイナーが設計した体験を通じて、ユーザーが課題を意識せずとも**自然に解決へ向かう動線が敷かれています。ユーザーは「正しいステップを自分で考える」必要がなく、設計された流れに沿って操作するだけで、結果として課題解決のプロセスを完遂できる。これこそがUI/UXデザインの本質的な価値です。
つまり、UI/UXデザイナーの専門性は「特定のドメイン知識」ではなく、**「ドメインエキスパートの知見を、ユーザーが迷わず辿れる動線へと翻訳する技術」**にあります。ドメインの専門家が持つ「正しい解決手順」を、認知負荷を最小化した形でUIに落とし込む――この翻訳能力は、AIの都度生成では代替できません。
この前提のうえで、AIチャットに埋め込まれるコンポーネントの時代には、以下のような設計がさらに重要になります。
- 情報の高密度化: テキスト（LUI）だけでは認知負荷が高い複雑なデータ比較などを、一目で理解させるためのグラフィカルなUIパーツ（GUI）が必要。
- 責任と承認のUI: AIが勝手に判断できない「最終意思決定」の瞬間に、ミスを防ぐためのドメイン特化型フォームを提示する。
- 品質保証の担い手: 第2章で述べた「検証済みの導線」を設計・維持するのは、まさにUI/UXデザイナーの仕事です。AIが都度生成では担保できない「確実性」を、コンポーネント単位で設計し、テストし、改善し続ける。
デザイナーは「サイト全体の画面」を作る仕事から、**「AIに呼ばれた瞬間に、その文脈で最高の結果を出すためのUIコンポーネント」**を設計する仕事へとシフトしていくでしょう。
7. 結論：SaaSの再定義
「SaaS is dead」が意味するのは、ユーザーを特定のブラウザタブに閉じ込める「囲い込みモデル」の終焉です。
これからのSaaSは、**「AIの脳の一部となるドメイン知識」と、「AIチャットに埋め込まれる洗練されたUIパーツ」**を供給するインフラへと再定義されます。
AIという汎用的なインターフェースの中に、SaaS側で設計された「特定の課題を解決するためのUX」が埋め込まれる。それは都度生成される不確実なものではなく、ドメインの専門家が設計し、実運用で検証された確実な解決パスです。これこそが、私たちが向かっている最も合理的で心地よい課題解決の姿ではないでしょうか。
あとがき
「AIか、SaaSか」という対立構造ではなく、双方がMCPのようなプロトコルで結びつき、ユーザーの意図を最短距離で解決する。このエコシステムの進化に、今後も注目していきたいと思います。