はじめに：　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分離を明示