こんにちは、株式会社TIMEWELLの濱本です。
半年前、SaaS企業の株価が雪崩を打って崩れました。市場関係者はこれを「SaaSpocalypse」と呼び、Fortune誌の報道によれば、わずか数週間で約4,000億ドルの時価総額が消えたとされています[1]。私はそのタイミングで「これからはAPIでもMCPでもCLIだ」という記事を書きました。結論そのものは、いまも1文字も変えるつもりはありません。ただ、当時「まだ未解決だ」と書いた部分が、この数か月でごっそり片づいていたのです。特にMCP（Model Context Protocol、AIと外部ツールをつなぐ共通規格）まわりの変化が速い。2025年11月に仕様が大幅に改訂され、その少し前の9月には公式レジストリまで動き出していました[2][3][5]。
半年も経つと、記事の一部は事実として古びます。ここでは当時の見立てを土台にしつつ、2026年7月時点の一次情報で全面的に書き直します。自社のAI活用が今どの段階にあるのかを手早く測っておきたい方は、AIリテラシー診断から入ると、この先の話が自分ごととして読めるはずです。
SaaSpocalypseの衝撃
2026年2月、SaaS企業の株価が軒並み急落しました。引き金は、当時の最新世代だったAnthropic社のClaudeやOpenAI社のCodexといったAIエージェントの実力が、市場の想像を超えて見えた瞬間だったと言われています。Fortune誌はこの現象を「SaaSpocalypse」と名付けました[1]。
まず、当時と現在の差をはっきりさせておきます。あの下落が起きた2026年2月時点で、Anthropicの最上位はClaude Opus 4.6でした。ところが2026年7月の今、系列はClaude Opus 4.7を経て、現行フラッグシップのClaude Opus 4.8（モデルID claude-opus-4-8、コンテキストは100万トークン）まで進みました。さらに一般提供の最上位としてClaude Fable 5、速度と知能のバランス型としてClaude Sonnet 5が並びます[8]。エージェントの地力は、SaaSpocalypseの引き金になった当時より、はっきり一段上がっています。UIを人が触る前提のソフトウェアにかかる圧力は、あれから緩むどころか強まったというのが正直な実感です。
この急落を予見していたような発言もありました。Microsoftのサティア・ナデラ氏が公の場で語ったとされる一言です。
今日のビジネスアプリケーションは、結局のところCRUDデータベースと少しのビジネスロジックにすぎない
初めて聞いたときは「さすがに言い過ぎでしょう」と感じました。けれど、エージェントが自分でAPIを叩き、ビジネスロジックを回していく様子を毎日見ていると、この言葉の芯が見えてきます。エージェントは美しい画面を求めません。マウスも動かさない。彼らが読むのは、JSONでやり取りされるAPIの応答です。人間のために磨き上げられたGUIは、その存在意義を根本から問われています。
「SaaS is Dead」という過激な言い回しの裏にあるのは、この構造変化です。では、AIエージェントの時代にソフトウェアはどう変わるのか。なぜ私が「APIでもMCPでもCLIだ」という結論に至ったのか。半年ぶんの最新動向を交えながら、順に見ていきます。
UIファーストの終焉
従来のSaaSは、人間がUIを操作する前提で設計されてきました。価値の中心は、いかに使いやすく、迷わず業務を終えられるかというUXにありました。流れも単純です。人がUIを操作し、SaaSがデータを処理し、結果を画面に返す。
2026年の現実は違います。SaaSの「利用者」がAIエージェントになり、人間は自然言語で指示を出すだけ。エージェントは画面を見ないし、ボタンの位置も知りません。彼らが理解するのはAPIの構造です。だからSaaSに求められる価値の重心は、UIの使いやすさから、APIの表現力と信頼性へと移りました。
この変化は、企業システムの進化として並べるとよく見えます。1990年代はSoR、つまり記録のシステムの時代でした。ERPやCRMが顧客データや取引記録を正確に管理していました。2010年代にはスマートフォンの普及でSoE、顧客接点のシステムが加わり、その後ビッグデータとAIでSoI、洞察のシステムが登場しました。そして今、エージェントの時代に求められているのはSoK、知識創造のシステムです。データを記録するだけでなく、そこから知識を生み、業務プロセスそのものを組み直す。ナデラ氏が「CRUDデータベースにすぎない」と言ったのは、SoRの段階で足踏みしているSaaSへの批判だったのだと思います。
MCPは半年で「未完成」から「標準」へ変わった
ここが、半年前の記事で一番古びた場所です。当時の私は、MCPを「2024年にAnthropicが提唱した規格」と紹介したうえで、設定の断片化、APIカバレッジの穴、トークンの浪費という三つの課題を「まだ未解決」として並べました。今読み返すと、その診断は2025年前半の温度感で止まっていました。
まず土台を整理します。MCPはJSON-RPC 2.0の上に立つプロトコルで、ホスト、クライアント、サーバーの三者で構成されます。サーバー側はResources、Prompts、Toolsを提供し、クライアント側はSampling、Roots、Elicitationという機能を持ちます。公式サイトは自らを「AIアプリのためのUSB-Cポート」と位置づけており、Claude、ChatGPT、Visual Studio Code、Cursorなど幅広いクライアントで扱えるようになっています[2][4]。ここまでは半年前と大枠は同じです。問題は、私が「穴」と呼んだ部分がどう埋まったか、です。
一つ目の「設定の断片化」。どのサーバーを信頼すればいいか判断しづらい、という課題です。これには公式の答えが出ました。2025年9月8日、MCPレジストリ（registry.modelcontextprotocol.io）がプレビュー公開されたのです[5]。サーバーの公開カタログ兼APIで、各サーバーはserver.jsonという形式で自己申告します。クライアント向けの「マーケットプレイス」として振る舞う公開サブレジストリと、社内向けの厳格な要件を満たすプライベートサブレジストリの両方を許容する設計です。初期開発には少なくとも9社、16名が関わったと公表されています[5]。発見と配布の標準化という、まさに私が「未解決」と書いた論点に、公式が正面から手を打ってきました。
二つ目の「APIカバレッジの穴」。自律ワークフローが途中で止まる、という不満です。これには2025年11月25日版の仕様（前版は2025年6月18日版）が答えを用意しました。実験的な機能として非同期tasksが追加され、長時間かかる耐久リクエストをポーリングで追跡し、後から結果を取りに行けるようになったのです（SEP-1686）[3]。処理の完了を画面の前で待つのではなく、投げて、あとで受け取る。エージェントの働き方に、ようやく仕様が寄り添ってきた感触があります。
三つ目、そして私が一番反省した点が「MCPは不完全なAPIラッパーにすぎない」という決めつけです。これは今や事実として誤りに近い。2025-11-25版では、Sampling内でツールを呼び出せるtoolsとtoolChoiceが加わり（SEP-1577）、ユーザーへ追加情報を求めるElicitationにURLモードが用意されました（SEP-1036）。Rootsと合わせれば、MCPはサーバーからクライアントへ問い返す双方向のやり取りができます。一方通行の薄いラッパーという像は、もう当てはまりません[3]。
見落とせないのがセキュリティと認可の前進です。旧記事はトークンの浪費にしか触れていませんでしたが、エージェント時代の本当の急所はそこではありません。2025-11-25版は、OpenID Connect Discoveryへの対応（PR #797）、WWW-Authenticateを使った段階的なスコープ同意（SEP-835）、OAuth Client ID Metadata Documents（SEP-991）を取り込み、Security Best Practicesのガイダンスも更新しました[3]。それでも、プロンプトインジェクション、悪意あるサーバーによるツールポイズニング、権限を借りたエージェントが本来やってはいけない操作を実行してしまう「混乱した代理人」問題は残ります。仕様が整うほど、こうしたリスクを前提に最小権限で組む設計力が問われます。私はここが2026年後半の主戦場だと見ています。
なお、旧記事で「GoogleとMicrosoftが共同開発し、Chromeに載った成熟技術」であるかのように紹介したWebMCPは、実態が違いました。正しくは、W3CのWeb Machine Learning Community Groupが2025年8月13日に初版を公開したドラフト提案です。ツール登録のAPIはdocument.modelContext.registerTool()で、MicrosoftとGoogleの技術者が主要な貢献者に名を連ねています[6][7]。ただし2026年時点でも主要ブラウザには標準搭載されておらず、あくまで検討段階の提案です。将来性はありますが、「もう使える技術」と読者に思わせる書き方は不正確でした。ここは率直に訂正します。
トークンの浪費については、今も本物の論点として残っています。ツール仕様を記した巨大なJSONスキーマが呼び出しのたびにモデルへ送られ、コンテキストとコストを圧迫する構図は変わりません。ただ、JSON Schema 2020-12を既定方言に据える整理（SEP-1613）や、ツール名の指針、アイコンのメタデータ化（SEP-973）、さらにWorking Groups化やSDKのティア制といったガバナンスの正式化（SEP-1302、SEP-1730）まで進んだことを見ると、MCPは「面白い実験」から「運用に耐える標準」へと軸足を移しつつあると感じます[3]。
CLIの逆襲
MCPが賑やかに進化する一方で、30年以上の歴史を持つCLI、つまりコマンドライン・インターフェースが、静かに、しかし確実に存在感を増しています。
象徴的なのが、ターミナルネイティブなAIエージェントの台頭です。2026年初頭の報道では、GitHubの公開コミットのうち無視できない割合がこうしたエージェント由来で、年内にその比率が大きく伸びるという予測も出ていました。これはあくまで当時の予測値なので数字の断定は避けますが、半年経った肌感覚として、CLIを母語とする開発スタイルは完全に主流へ入ったと言えます。背景には、先ほど触れたClaude Opus 4.8やFable 5といったモデルの底上げがあります。エージェントの計画力と実行力が上がるほど、CLIという素朴な道具の価値が逆に際立つ[8]。
なぜCLIがエージェントとこれほど噛み合うのか。理由は三つあります。
一つ目は普遍性です。一度PCに設定すれば、IDEでもターミナルでも同じように呼び出せます。AWS CLIやgcloud SDKのように、単一のバイナリでプラットフォームのほぼ全機能を覆います。MCPサーバーで起きがちな「このツールだけ別の設定ファイルが必要」という断片化が、そもそも起こりません。
二つ目は成熟度です。認証やエラーハンドリングという、コンピュータ同士の通信で厄介になる問題が、数十年かけて枯れています。多要素認証もシングルサインオンも、CLIの世界ではとうに当たり前の技術です。
三つ目はエージェントとの親和性です。エージェントは画面の文脈を読み解く必要がありません。--helpで返ってくる構造化されたテキストだけで、ツールの使い方を正確に把握し、そのままタスクに移れます。開発者コミュニティでは「MCPでできることの多くはCLIでよりうまくやれる」という声も根強く、私自身もかなり共感しています。意見が割れるテーマではありますが、少なくともエージェントが自律的に動く場面で、CLIほど摩擦の少ないインターフェースは今のところ見当たりません。
ここに、もう一つ地味だけれど大事な動きを添えておきます。エージェントに向けて機械可読なドキュメントを置く作法が広がってきました。たとえばサイトのルートにllms.txtを用意し、モデルが最初に読むべき情報の地図を渡す。人間向けのUIとは別に、エージェント向けの入り口を設計するという発想です。CLIファーストの思想と、根っこは同じところにあります。
三つのインターフェースは競合しない
ここまでAPI、MCP、CLIを追ってきました。「これからはAPIでもMCPでもCLIだ」という主張の芯は、この三つが奪い合う関係ではなく、別々のレイヤーで役割を分け合う補完関係にある、という一点です。
APIは、すべての土台になるレイヤーです。サービスが外部へ機能を差し出すための契約であり、プログラムがアクセスする正式な玄関口。ここが堅牢で表現力豊かでなければ、上に何を積んでも崩れます。
MCPは、AIモデルと多種多様なツール群のあいだに立つ翻訳者です。仕様がばらばらな無数のAPIを、モデルが理解できる統一形式へ変換し、接続を標準化します。かつては「どのサーバーを信じるか」が悩みでしたが、レジストリという地図が用意された今、この翻訳者はぐっと使いやすくなりました。
CLIは、エージェントにとって最も自然な対話相手です。計画を立て、実行し、結果を確かめるというエージェントの思考のリズムと、コマンドを一つずつ重ねる操作は、驚くほど相性がいい。
WebMCPは、この三つと並ぶというより、ユーザーがブラウザ越しにエージェントと協働する場面に特化した選択肢です。魅力はありますが、現時点ではドラフトで、ブラウザにも載っていない。過度な期待は禁物、という距離感が正確でしょう。
問われているのは「どれが一番強いか」という順位づけではありません。自社のサービスを、どれだけエージェントにとって扱いやすい形にできるか。エージェントがアクセスしやすく、操作しやすく、安全に権限を渡せる状態を用意できるかどうかが、これからのソフトウェアの生き死にを分けます。APIという土台の上に、MCPによる接続性とCLIによる操作性を重ねる。この三位一体の設計が、もはや欠かせない条件になりました。
エージェントフレンドリー設計、何から手をつけるか
構造変化そのものは腑に落ちたとして、では明日から何をするか。ここが記事で一番読者に持ち帰ってほしい部分です。
出発点は、自社APIの品質の見直しです。同じ操作を何度呼んでも壊れない冪等性、細かい粒度のエンドポイント、時間のかかる処理を投げっぱなしにできる非同期対応、そして誰が何をしたかを追える監査ログ。とくに非同期対応は、MCPの非同期tasksとまっすぐ噛み合う要件です。これらは「あれば良い」ではなく「なければ選ばれない」条件に変わりつつあります。
次にCLIの整備です。自社サービスにCLIがないなら、着手する価値は十分にあります。すでにある場合も、エージェントが使う前提で、ヘルプメッセージの充実、出力のJSON対応、認証フローの簡素化を進めてください。人が読んで気持ちいいCLIではなく、機械が迷わず読めるCLIを目指すのが2026年の作法です。
そしてMCP対応の検討です。自社の属するエコシステムでMCPが標準になりつつあるなら、対応は避けにくい。公式レジストリにserver.jsonで自らを登録して見つけてもらう、OAuthとOpenID Connectで認可を固め、スコープは最小に絞る、Elicitationのような双方向機能を活かして安全に確認を挟む。自前でサーバーを組むだけでなく、既存の実装を活用して費用対効果を測る視点も持ちたいところです。
SaaSを選ぶ側の方には、次のチェックリストを提案します。UIのデモだけで判断する時代は、もう終わりました。
| チェック項目 | 確認すること |
|---|---|
| API品質 | REST・GraphQL APIが公開されているか。冪等性は担保されているか |
| 非同期対応 | 長時間処理を投げて後から結果を取得できる設計か |
| CLIの有無 | 公式CLIが提供され、JSON出力やヘルプが充実しているか |
| MCP対応 | 公式レジストリに登録されたMCPサーバーがあるか。更新は続いているか |
| 認証と認可 | エージェント用アカウントを作れるか。スコープを最小に絞れるか |
| セキュリティ | ツールポイズニングや権限誤用への対策方針が示されているか |
| 双方向機能 | Elicitationのように、必要時に確認を返す仕組みがあるか |
| 可観測性 | 利用状況や監査ログをAPI経由で取得できるか |
三つのインターフェースのなかで、今後もっとも重みを増すのはCLIだと私は考えています。CLIはエージェントの母語にいちばん近い。APIが土台であること、MCPがエコシステムをつなぐことは間違いありません。それでも、エージェントが自律的にタスクを進めるうえで、最も摩擦が少なく、最も素直に扱える入り口は、現時点ではCLIだと言い切れます。半年前と違うのは、その隣でMCPが「未完成の実験」から「運用に耐える標準」へ育ったこと。だからこそ、三位一体という言い方が、以前よりずっと現実味を帯びてきました。
こうした構造変化への対応は、技術チームだけで完結する話ではありません。API設計の見直し、CLIツールの整備、MCP対応の優先度判断。どれも予算と人の配分を伴う経営判断そのものです。私たちTIMEWELLのWARPプログラムでは、AIエージェント時代のDX戦略づくりから、実際のAPI設計やシステムアーキテクチャの見直しまで、元大手のDX・データ戦略の専門家が伴走型で支援しています。「自社のサービスをエージェントフレンドリーにするには、まず何から手をつければいいのか」。その問いを一緒にほどきたい方は、WARPの個別相談からお声がけください。半年後にまたこの記事を書き直すとき、あなたの会社が「対応済み」の側にいることを願っています。
参考文献
[1] Fortune誌の報道による（2026年2月）。「SaaSpocalypse」の命名と、数週間で約4,000億ドルの時価総額が失われたとの報道。
[2] Model Context Protocol. Specification (latest). https://modelcontextprotocol.io/specification/latest
[3] Model Context Protocol. Key Changes (2025-11-25 changelog、前版は2025-06-18). https://modelcontextprotocol.io/specification/2025-11-25/changelog
[4] Model Context Protocol. 公式トップ（入門）. https://modelcontextprotocol.io
[5] Model Context Protocol Blog. Introducing the MCP Registry (preview, 2025-09-08). https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/
[6] W3C Web Machine Learning Community Group. WebMCP リポジトリ. https://github.com/webmachinelearning/webmcp
[7] W3C Web Machine Learning Community Group. WebMCP 仕様ドラフト（初版 2025-08-13）. https://webmachinelearning.github.io/webmcp/
[8] Anthropic. Claude models overview（現行モデル一覧、Claude Opus 4.8 / Fable 5 / Sonnet 5）. https://platform.claude.com/docs/en/about-claude/models/overview
