画面のAIは仮設でいい──Software for Agents時代を生き残るSaaSの2トラック戦略

1. 結論：画面のAIを作ってよい。ただし、捨てられるように作る

SaaSにAI Agentを内蔵すべきか。それとも、人間向けGUIの時代はいずれ終わると見切り、APIやMCPへ全振りすべきか。

この二択で考えると、どちらを選んでも危ない。

APIだけを先に完成させても、現在の顧客が価値を理解できず、売上が立つ前に資金が尽きるかもしれない。逆に、画面の端へ立派なAIチャットを付けることだけに投資すると、数年後に利用者の「メインAgent」が同じ仕事を外から行い、そのUIが重いレガシーになる。

ぽちょ研究所が提案するのは、2トラック戦略である。

• Track 1——今を生きる： SaaS画面内に、価値が見えやすいAIアシスタントを置く。営業のフック、導入の安心、短期の売上を作る。
• Track 2——未来に勝つ： 同じ業務能力を、セマンティックなAPI、MCP、厳格な権限、監査、冪等性、ロールバックから呼べるAgent Native基盤にする。

重要なのは、二つの機能を別々に作らないことだ。画面内AIも、将来のメインAgentも、同じドメインサービスと同じ権限モデルを使う。画面は交換可能なアダプター、APIと業務データは長く残る資産と位置づける。

つまり「今作るUIは仮設である」と認める。ただし仮設は無駄ではない。橋を完成させる前の迂回路のように、今日の顧客を未来へ運び、開発費を回収し、実利用データを集める役目がある。早すぎる正解で資金ショートせず、遅すぎる最適化で取り残されないための設計である。

2. Software for HumansからSoftware for Agentsへ：シフトはすでに始まっている

2026年8月時点で、「AIが複数サービスを横断し、調査、データ処理、ファイル作成、画面操作まで行う」ことは研究室のデモではない。

OpenAIはChatGPT agentに、視覚ブラウザー、テキストブラウザー、ターミナル、直接APIを組み合わせた。カレンダーはAPIで効率よく読み、人間向けにしか作られていないサイトでは画面を操作する、という使い分けである。^[1] 2026年6月、同社はCodexの週間利用者が500万人を超え、非開発職が約20%を占めると公表した。コードを書いて仕事を片づける体験は、開発者だけの特殊技能から外へ広がっている。^[2]

AWSはさらに直接的だ。2026年5月に一般提供したAWS MCP Serverにより、MCP対応エージェントは既存IAMの範囲でAWSを操作できる。AWS Security Blogによれば、対象は15,000超のAPIで、AI経由の呼び出しと人間の直接操作を区別するコンテキストキーも用意される。^[3][4]

Anthropicが始めたMCPも、一社専用の接続方式ではなくなった。2025年末にLinux Foundation傘下のAgentic AI Foundationへ寄贈され、OpenAI、Google、Microsoft、AWSなどが中立的な基盤を支える側に入った。公式Python・TypeScript SDKは月間9,700万回超ダウンロードされていた。^[5]

この流れが意味するのは、SaaSの消滅ではなく、利用者の変化である。これまでのAPI利用者は主に開発者と別のソフトウェアだった。これからは、利用者の代理として動くエージェントが主要なAPI消費者になる。

GUIしか持たないサービスも、GoogleのComputer Useのような画面操作モデルから利用できる。2026年8月26日時点で、Googleはブラウザー、モバイル、デスクトップ環境への対応を案内している。だが同時に、プレビューにはエラーやセキュリティ脆弱性があり得るため、重要な仕事では監督し、取り返しのつかない操作を避けるよう警告している。^[6]

画面操作は「最後の互換層」として強い。しかし、座標のずれ、表示変更、待ち時間、誤クリックに弱い。APIは対象ごとの設計が必要でも、速く、構造が明確で、権限と監査を適用しやすい。メインAgent時代に選ばれるSaaSは、画面を上手にクリックさせる製品ではなく、正規の機械向け入口を持つ製品である。

3. それでも今、画面内AIを作る理由：技術の時計と顧客の時計は違う

将来像が正しくても、顧客が今日それを買うとは限らない。

McKinseyの2025年世界調査では、組織の23%がどこかでAIエージェントを拡大導入し、39%が実験を始めていた。しかし、個別の業務機能で拡大導入している割合は、どの機能でも10%以下だった。AI利用は広がっても、業務全体を自律エージェントへ渡す段階はまだ少数派である。^[7]

日本では距離がさらにある。IPAの「DX動向2025」は、生成AIを導入済みまたは導入予定の企業が米国・ドイツでは8割、国内では5割強と整理する。部署の業務プロセスに組み込んでいる割合は米独で4割弱、日本で1割程度。従業員100人以下の日本企業では、導入・試験利用が12.1%にとどまった。^[8]

この数字から「日本は必ず世界より何年遅れる」と固定値を出すことはできない。業界、規模、規制、顧客層で速度が違うからだ。ただし、事業計画上は1〜5年の過渡期があり得ると置き、短すぎても長すぎても生き残れる設計にする価値がある。

現在の顧客にとって、画面の端にAIボタンやチャット欄があることは分かりやすい。「この製品はAI対応だ」と営業資料で見せられ、既存の画面と権限の中で試せる。成果と操作履歴を目視でき、全面的に自律エージェントへ移るより心理的なハードルが低い。

ここで画面内AIを「顧客が遅れているから与える飾り」と考えると失敗する。役割は、未来技術のデモではなく、既存業務からエージェント利用へ移るための訓練輪である。

良いTrack 1は、万能チャットではない。「未処理の請求を説明して仕訳案を出す」「空き時間を比較して候補を作る」「異常なメトリクスを集めて原因候補を並べる」のように、価値が測れる一つの仕事を終わらせる。人間は同じ画面で根拠と差分を見て承認する。

早すぎる正解は、ビジネスでは不正解になり得る。未来の最終形だけを売っても、現在の多数派には使う場面が見えない。一方、画面内AIで売上と学習を得ながら、裏側をAgent Nativeにしておけば、過渡期は損失ではなく移行原資になる。

4. 2トラック戦略の設計：仮設UIと恒久APIを同じ業務能力につなぐ

2トラックは「UIチームとAPIチームを別々に走らせる」という意味ではない。二重実装を避けるため、製品を三層に分ける。

Track 1——今を生きる画面内AI

Track 1の目的は、短期売上だけではない。どの指示が多いか、どこでユーザーが修正するか、何を怖がって承認しないか、どの成果なら料金を払うかを観測する。これは将来のツール設計に使える実データになる。

ただし、UIに業務ロジックを埋め込んではならない。チャット欄から直接データベースを更新したり、画面専用のプロンプトだけで例外処理したりすると、その入口を捨てた瞬間に能力も失う。画面内AIは、共通のドメインサービスを呼ぶ薄いクライアントにする。

Track 2——未来に勝つAgent Native基盤

Track 2では「APIがある」より、「エージェントが安全に完遂できる」ことを目標にする。

• 意味が一意に読めるスキーマ、説明、例、機械可読な仕様
• 成功、再試行可能、恒久的失敗を区別できる型付きエラー
• 二重実行を防ぐ冪等性キーと、長時間処理の状態照会
• 人間、サービス、エージェントを区別する認証と最小権限
• 読み取り、提案、実行、破壊的操作を分けるスコープ
• 誰が何をなぜ行ったか追える監査ログ
• プレビュー、差分、承認、取り消し、補償トランザクション
• コスト、レート制限、データ鮮度、タイムアウトの明示

Postmanが世界の開発者、アーキテクト、経営層5,700人超を対象にした2025年調査では、89%がAIを使う一方、エージェントを意識してAPIを設計しているのは24%だった。MCPを知っている人は70%でも、日常利用は10%。51%はエージェントによる無許可・過剰なAPIアクセスを最大のセキュリティ懸念に挙げた。^[9]

MCPはAPIの代替ではない。APIやデータをエージェントが発見し、説明を読み、ツールとして呼ぶための共通入口である。内部の業務契約が曖昧なままMCPで包んでも、曖昧さを配布するだけだ。

5. GUIは消えない：操作盤から「確認・共有・例外処理の面」へ変わる

メインAgentが普及しても、人間が画面を見る必要は残る。

ぽちょ研究所では、AWS Management Consoleを開く頻度が以前より減った。複数画面から構成とメトリクスを集めるより、APIで取得し、エージェントに統合レポートを書かせた方が速い。ただし、構築後の状態、時系列グラフの異常な落ち込み、複数系列のずれは最後に目で確かめる。

これは二つの仕事を分けると理解しやすい。

1. 状態を変える： 作成、設定、移動、集計、調整、送信。エージェントへ移りやすい。
2. 状態を理解する： 俯瞰、比較、異常発見、合意、最終確認。視覚が強い。

Google Calendarでは、Geminiが参加者の空き時間から候補を提案し、都合が悪ければ代替時間を示せる。^[10] それでも週表示を見て「水曜だけ詰まりすぎている」と瞬間的に理解する価値は残る。壁の紙カレンダーが画面になったように、AIが予定を調整しても、時間の形を見る欲求は消えない。

FXの急落と回復、サービスのレイテンシ、会議資料の流れも同じである。数値や説明だけでなく、「ナイアガラの滝」のような形を見た方が速い場面がある。

2026年8月25日にAWSが発表したOpenSearch Service MCP Appsは、この変化を製品にした。エージェントの文章要約と、実データから決定的に生成したトレース、サービス構成、ログパターンの対話型表示を、AIクライアント内に同時に返す。^[11] 個別ダッシュボードを巡る代わりに、必要なGUIが会話へ移住する。

GoogleのA2UIも、エージェントが入力フォームや承認ダッシュボードをその場で構成し、Web、Flutter、ネイティブ側が許可済み部品で安全に描画する方向を示す。^[12]

未来の「一つのAgent」は、巨大なチャット欄とは限らない。入口は一つでも、必要なときにカレンダー、グラフ、スライド、フォームを呼び出す。SaaSの固定GUIは減っても、視覚的なインターフェースそのものは残る。

6. APIを使う側の経験が資産になる：マネーフォワードが示したこと

AIは、正しい情報が揃えば分類、比較、要約、仮説作成を速く行う。情報が欠けると、もっともらしい推測で穴を埋め、ハルシネーションを起こす。したがって、Agent Native製品の競争力はモデルだけでなく、正本データ、更新時刻、同意、権限、履歴をどれだけ整えられるかで決まる。

マネーフォワード MEは、AIエージェント以前からこの土台を作ってきた。銀行、証券、カード、電子マネー、ポイントなど別々の情報を取得し、一人の家計と資産の文脈にまとめる。

同社は2020年、連携していた銀行125行を含む対象金融機関すべてとAPI契約を締結したと発表した。背景のアカウントアグリゲーションは、APIまたはスクレイピングで口座情報を取得する仕組みである。^[13] 2025年には利用者数が1,730万人を超え、複数口座から選んだ情報を二人で共有する「シェアボード」も始めた。^[14]

ここで特定企業の将来を断言する必要はない。注目すべきは、10年以上前から、接続交渉、データの癖、更新失敗、名寄せ、同意、セキュリティを経験してきた点である。

APIを使う側の痛みを知る人は、「エージェントから安全に使うには、このエラー、この権限、この取り消し方法が必要だ」と要求できる。MCPの文法だけを知る人より、情報が現場でどう欠け、ずれ、止まるかを知る人が強い。API開発者と統合設計者が日の目を浴びる理由は、ここにある。

7. 2026、2027、2028、2030：予測ではなく、投資配分のためのシナリオ

新技術の普及は一直線ではない。ぽちょ研究所のイノベーション普及理論の記事で整理した通り、有名な2.5%や13.5%は固定的な実測値ではない。それでも、先行者から多数派へ移るには、相対的な利点、既存業務との相性、分かりやすさ、試しやすさ、成果の見えやすさが必要になる。

以下は公表済み事実ではなく、2026年8月の技術と導入データから置く投資シナリオである。

年を当てることが目的ではない。2027年に急加速しても、2030年まで緩やかでも、同じ業務能力を複数の入口から呼べる構造なら投資は無駄にならない。逆に「画面内AIが何年売れるか」を当てなければ回収できない設計は、賭けが大きすぎる。

8. 実務の判断基準：今のAI機能を、未来の資産へ変えられるか

最後に、SaaS事業者が企画を判断するための質問を置く。

Track 1へ投資する価値が高い場合

• 顧客が既存画面を日常的に使い、そこでAIの根拠と差分を確認したい。
• 具体的な一業務を短縮でき、利用回数、時間、承認率、売上で価値を測れる。
• AI機能が導入の心理的ハードルを下げ、営業やアップセルに効く。
• 画面から共通ドメインサービスを呼び、UI専用ロジックを増やさずに作れる。

Track 2を急ぐべき兆候

• 顧客がCSV、API、RPA、独自エージェントで既にデータを外へ出している。
• 同じ操作を画面、モバイル、バッチ、連携先で何度も実装している。
• 監査、権限、再試行、取り消しがUIの内部に閉じている。
• 外部エージェントから「何ができるか」を機械可読に説明できない。
• 製品の価値が画面より、蓄積データ、専門ルール、正確な実行にある。

最も危険なのは、画面内AIを作ることではない。画面内AIでしか使えない業務能力を作ることである。

SaaSは、おそらく消えない。人間がすべての画面を巡回し、情報を集め、同じ操作を繰り返す時代は終わり始める。GUIは操作の主役から、確認、共有、例外処理の面へ移る。SaaSは人間向けソフトウェアであると同時に、エージェントが使う道具、データ保持層、業務ルールの提供者になる。

だから今は、画面のAIを売ってよい。ただし、その成功が画面の寿命に依存しないようにする。仮設UIで今日のキャッシュを作り、恒久APIで明日の選択肢を買う。 それが、Software for Agentsへの過渡期を生き残る現実的な戦略である。

参考文献・出典

1. [1]OpenAI「Introducing ChatGPT agent」。視覚ブラウザー、テキストブラウザー、ターミナル、直接APIを使い分ける構成を説明。 ↩
2. [2]OpenAI「Codex for every role, tool, and workflow」。2026年6月時点の週間利用者数と非開発職の構成を参照。 ↩
3. [3]AWS News Blog「The AWS MCP Server is now generally available」。2026年5月6日、AWSサービスへ認証済みで接続する管理MCP Serverの一般提供。 ↩
4. [4]AWS Security Blog「Understanding IAM for Managed AWS MCP Servers」。15,000超のAWS API、既存IAM、AI経由呼び出しを区別する仕組みを説明。 ↩
5. [5]Anthropic「Donating the Model Context Protocol and establishing the Agentic AI Foundation」。MCPの中立運営と公式SDKの利用規模を参照。 ↩
6. [6]Google AI for Developers「Computer Use」。2026年8月26日更新。対応環境とプレビュー上の安全上の注意を参照。 ↩
7. [7]McKinsey「The state of AI in 2025: Agents, innovation, and transformation」。AIエージェントの実験・拡大導入状況を参照。 ↩
8. [8]IPA「DX動向2025説明会」資料。日米独の生成AI導入と業務プロセスへの組み込み割合を参照。 ↩
9. [9]Postman「2025 State of the API Report」。5,700人超の回答を基に、AI利用、エージェント向けAPI設計、MCP利用、セキュリティ懸念を報告。 ↩
10. [10]Google Workspace Blog「Google Workspace with Gemini helps you move work forward in meetings」。CalendarとGmailでの予定調整機能を参照。 ↩
11. [11]AWS Machine Learning Blog「Agentic observability with Amazon OpenSearch Service MCP Apps」。2026年8月25日、要約と対話型可視化を同時に返す仕組みを発表。 ↩
12. [12]Google Developers Blog「Introducing A2UI」。エージェントから安全な宣言型UIを渡す仕様。 ↩
13. [13]マネーフォワード「改正銀行法に対応し、当社サービスと連携するすべての金融機関と契約締結」。2020年9月末時点のAPI契約とアカウントアグリゲーションの説明。 ↩
14. [14]マネーフォワード「『マネーフォワード ME』、新機能『シェアボード』を提供開始」。利用者数と複数金融サービスの共有機能を参照。 ↩