はじめに： AIがあなたのシステムを操作できますか？
「SaaSの死」という議論が最近盛んになっている。IDC・Bain・Deloitte・Forresterといった大手調査機関も相次いでレポートを出し、MicrosoftのSatya Nadella CEOが「SaaSは死んだ」と発言したことも話題になった。
ただ、多くの記事では「AIエージェントが業務を代替するため、SaaSは不要になる」という概念の提示で終わっている。
本記事では、もう一歩踏み込んで、「AI時代に適したアークテクチャ」 について考えてみた。
1. AIエージェントはUI不要でAPIを操作する
人間はUIを通じてシステムを操作する。
ボタンをクリックし、フォームに入力し、画面遷移する。UIはそのための仕組みだ。
一方、AIエージェントは APIを通じてシステムを直接操作できる。
UIというレイヤー自体をスキップできるのだ。
人間の操作フロー
人間 → UI（画面）→ API → DB
AIエージェントの操作フロー
AIエージェント → API → DB
（UIをスキップ）
つまりAI時代において、UIは「人間が結果を確認するための画面」として残るだけで、
システムの本質的な価値はAPIにあると考えている。
この視点でフロントエンドの技術選択を見直してみると、なかなか面白い気づきがある。
2. フロントエンドの整理 ～UIとAPIを分離する価値～
MPA・SSR（Next.js App Router、Rails、Laravelなど）
サーバーがHTMLを生成して返すアーキテクチャ。UIとAPIが密結合しがちである。
AIエージェントがこの構造のシステムを操作しようとすると、HTMLを解析 → DOM要素を特定 → 操作、という迂回路が必要になる。
この発想は、RPAと類似している。
RPA
画面キャプチャ → ボタン座標を特定 → クリック実行
→ 画面デザイン変更に対応不可
Playwright MCPによるSSR操作
HTMLを解析 → セレクタを特定 → 操作実行
→ DOM構造変更で不安定
Claude Coworkを利用したり、Playwright MCPを利用してAI Agentsから操作したりできるが、ブラウザ起動コスト、レンダリング待ち、大量のトークン消費などの問題が山積みである。
フロントエンドにMPA/SSR/ISRを採用した場合でも、ビジネスロジックはAPIで分離して
AIが容易に操作できるようにすることが重要である。
SPA（React・Vue・Angularなど）
フロントエンドとバックエンドが APIで明確に分離 されたアーキテクチャ。
バックエンドのAPIさえあれば、フロントエンドを完全にスキップできる。AIエージェントはAPIを直接叩けばいい。フロントエンドは「人間の結果確認用UI」として独立して残る形になる。
SPA構造
フロント（人間用UI）
↕ API
バックエンド ← AIエージェントはここに直接アクセス
↕
DB
フロントとバックエンドが分離しているということは、フロントを操作する主体をAIに置き換えられる、ということでもある。
SSG（静的サイト生成）
コンテンツ配信には強いが、業務システムとしてはほぼ無関係なので割愛する。
3. SaaSをAPIで操作できますか
人間の利用を前提にすると、UIの利便性はSaaSの大きな価値の源泉だった。
しかし、AI Agentsによる利用を考えると、APIで全部の操作ができるかが重要になる。
SalesforceがHeadless 360を発表したのは、この流れを見越しているのではと感じた。
| SaaS | API完結度 | AI時代の評価 |
|---|---|---|
| Salesforce | ◎ | Metadata API・Tooling APIで全設定可能。Headless 360でMCP対応も明言 |
| AWS・Azure・GCP | ◎ | IaC・API完備。AIエージェントとの相性が一番良さそう。AWS/Azure/GCPはそれぞれ、Anthropic/OpenAI/Googleと連携しているため、ClaudeChatGPT/Geminiの最新モデルを利用可能 |
| GitHub・Vercel | ◎ | API・CLI完備 |
| ServiceNow | △ | APIは増えているが、GUI前提の設計が残る |
| SAP | × | ABAP・GUIベースが中心。APIは後付け感が強い |
| kintone | △ | アプリ設定APIはあるが限定的 |
GUI依存度が高いSaaSは、AIエージェントにとって「操作しにくいSaaS」となる。
このため、SaaS上に独自AIを構築して、ユーザを囲い込もうとする動きが高まると予想する。しかし、ClaudeCode等の最新AIとの競争が激しく、性能面で後れを取れば、乗り換えを招く恐れがある。
4. エンタープライズ設計の方針
AI時代には、API分離設計を選択することが重要だと考える。
フロントはSPA（React・Vue等）、バックエンドはREST API・GraphQL。
既存システムのバックエンドAPIに、ラッパーとしてMCPを被せれば、最小限の改修で、AIエージェントが操作できる構成に進化できる。
AIエージェント（Claude等）
↓
MCPラッパー
↓
REST API / GraphQL
↓
バックエンド・DB
既存SSRシステムの場合
人間のコンシューマが操作する場合は改修不要だが、
AI のアクセスを前提にする場合は、以下のような段階的な回収アプローチが必要・
- 短期：Playwright MCPで 暫定対応
- 中期：API分離へのリファクタリング を計画
- 長期：MCPラッパー化で AIエージェントのネイティブ対応
5 デジタル庁の先見性
民間ではこれからAIエージェントに最適化した設計論についての議論がスタートするが、
デジタル庁は数年前から、UI/UXとAPI分離の方針を掲げていた。
「フロントエンドはUI/UXに責任を持ち、バックエンドはデータ管理に責任を持つ。それぞれの役割を明確に分けて、フロントエンドとバックエンドはAPIで連携する。フロントエンドとバックエンドを疎結合化することで、開発やデプロイを独立して実施できる。」
— デジタル庁「ガバメントクラウドにおけるモダン化の意味と定義」
「フロントとバックエンドはAPIで連携する」を原則とした時点で、それはAIエージェントが操作しやすいアーキテクチャと完全に一致している。
デジタル庁の先見性にとても驚いた。
6. SIerのチャンス
短期的には、「AIエージェント対応リファクタリング」という新しい需要が生まれそう。
長期的には、ビジネスロジックをAI前提に改革し、基幹システムの再構築が必要と感じた。
特に、既存システムの細部を理解して、AIとつなげていく作業は、コンサルや内製開発の倍部コーディングではバグが出やすく、SIerの価値を発揮できる領域ではと思った。
既存システム（SSR・モノリス）
↓ API分離・MCPラッパー化
AIエージェントが操作できるシステムへ
7. まとめ
| ポイント | まとめ |
|---|---|
| AIはUI不要 | APIで直接操作できればUIは不要。UIは人間の確認用のみ |
| FE/BE分離が好相性 | AIエージェントがAPIを直接叩ける |
| SSR/MPAは相性悪い | PlaywrightMCP等で実装可能だが、不安定で重く高コスト |
| SaaS選定基準 | 「APIで全操作できるか」が重要。Salseforceは◎ |
| デジタル庁の先見性 | ガバメントクラウドのモダン化定義では、API分離を明示 |