エージェントに選ばれるSaaSの条件 ── to Aの設計思想とMCP/CLI

しかし、その言葉が指しているのはSaaSというビジネスモデルの終焉ではありません。終わりを迎えつつあるのは、あくまで人間がポチポチと操作するためのUIの部分です。バックエンドに蓄積された業務プロセスやドメイン知識は、むしろAI時代においてこれまで以上にその価値を増していると感じています。

このような中でSaaS業界は、AIエージェント向けのインターフェース「to A（to Agent）」へと市場が傾いてきています。しかし、トレンドとしての概念を理解することと、実務においてエージェントが使いやすいプロダクトを「設計すること」の間には、依然として深い溝が存在します。

本ブログでは、一歩踏み込んだ設計思想の具体の部分を考察していきます。エージェント・ファーストなデータ構造の在り方から、MCPの採用、CLIの評価まで、次世代のto A像について考察していきます。

to Aとは ── 「SaaS is Dead」の再解釈

現在、多くのSaaSは「UIを操作して業務解決（報酬）を得る」モデルですが、ツールの乱立による認知負荷も存在しています。本来の目的は業務プロセスの解決であり、人間によるUI操作はそのための「手段」であり、時にはコストとなります。

昨今、AIのエージェント化が進み、フローは「UI→API→業務解決」から「AI→API→業務解決」へと変容してきていると感じている方も多いのではないでしょうか？ユーザーがClaudeやChatGPT、Cursorといった一元管理プラットフォームなどから指示を出し、AIが各SaaSのAPIを直接叩く形です。

このシフトにおいて、人間による操作を前提とした設計はボトルネックとなってきます。
AIエージェントに選ばれる道具として機能を提供できるか、つまりto Aへの対応が、SaaSプロダクトの生存を左右する戦略的分岐点となってきます。

to Aの設計思想

実装手段を問わず、to Aプロダクトが共通して持つべき設計の根幹は、大きく分けて以下の2つの軸に整理できます。

AIフレンドリーであること
安全であること

前者はエージェントが迷わず動くための構造化された指示書、後者は事故を防ぐためのガードレールに相当します。

① AIフレンドリーであること：セマンティックなAPI設計

LLMはAPIの名称や説明（description）を読み取り、現在のタスクに最適かを判断します。update_status のような曖昧な命名を避け、言語としての意味（Semantic）を明確にすることが、エージェントの判断精度に直結します。

以下は、AIが理解しやすいAPI定義の例です。OpenAPI（REST APIの仕様をYAML/JSON形式で記述するための業界標準）で書くと、descriptionフィールドにそのままエージェント向けの「使い方の説明」を仕込めます。

yaml

# AIが理解しやすいAPI定義（OpenAPI）
paths:
  /invoices/{id}/approve:
    post:
      summary: "請求書の承認"
      description: "指定されたIDの請求書を承認し、支払いを確定させます。実行には経理権限が必要です。"
      parameters:
        - name: "id"
          in: "path"
          description: "承認対象の請求書ID"
          required: true

ポイントは、summary と description を人間のための補足コメントではなくエージェントへの実行指示書として書き直すことです。権限要件や副作用、実行タイミングの注意点まで明示することで、エージェントは自律的に「このエンドポイントを今呼ぶべきか」を判断できるようになります。

② 安全であること：エージェントが「壊さない」ための設計

エージェントを業務に組み込む上で、安全性は機能性と同じくらい重要なテーマです。自律的に動くエージェントには、誤操作のリスクが常に伴います。本章では、AIに自律的な操作を任せながらも事故を防ぐ、2つの設計原則を紹介します。

権限スコープの制限：そもそもAIが触れる範囲を絞る
冪等性の担保：リトライしても安全な状態を保つ

権限スコープの制限

本番環境への直接干渉を避け、AI専用のスコープ制限を設ける設計が不可欠です。スコープの実装レイヤーは複数あり、一般的には次の3層を組み合わせます。

APIキー / OAuthスコープ：トークン発行時に「このトークンで何ができるか」を縛る
IAM / ロール：ユーザーやサービスアカウントに紐づく権限を制御する
アプリケーション層：APIエンドポイント側で「AIエージェント由来のリクエスト」を検知し、追加の検証を行う

下記のJSONは、このうち「AI専用のAPIキー発行時に紐づけるロール定義」のイメージです。require_approval のように、重要な処理にはAPIレベルで人間の承認を要求する（Human-in-the-loop）フラグを仕込んでおくと、自律性と安全性を両立しやすくなります。

json

// AI専用APIキーの権限スコープ定義例
{
  "role": "ai_agent_limited",
  "permissions": ["read:all", "write:invoices"],
  "require_approval": ["delete:all", "transfer:funds"],
  "environment": "sandbox"
}

冪等性の担保

AIの運用において、ネットワークエラーやLLMの判断ミスによるリトライは避けられません。同じ操作が何度呼ばれても、結果が一度しか実行されない冪等性の担保は、二重決済などの不整合を防ぐ砦です。

Idempotency-Key を標準実装し、AIのループをシステム側で安全に受け止める必要があります。

typescript

// 冪等性を担保するAPI実装の簡潔なイメージ
app.post('/api/orders', async (req, res) => {
  const key = req.headers['idempotency-key'];
  // 既に処理済みのキーであれば、保存されている前回の結果を返す
  const existing = await db.orders.findUnique({ where: { key } });
  if (existing) return res.status(200).json(existing);

  // 新規処理を実行
  const order = await db.orders.create({ data: { ...req.body, key } });
  return res.status(201).json(order);
});

エージェントは人間と違い、タイムアウトや一時的なエラーに対して機械的にリトライを繰り返します。冪等性の設計が甘いと、その「機械的なリトライ」がそのまま業務上の事故に直結します。

to Aを実現するインターフェースの種類 ── MCP vs CLI

ここまで設計思想の話をしてきましたが、to Aを実装する際に最終的に問われるのは「エージェントとSaaSをどう繋ぐか」というインターフェース選定です。

重要な前提として、to AのコアはあくまでAPIです。MCPもCLIも、それ自体が業務ロジックを持つわけではなく、APIをエージェント向けにラップする方法の違いに過ぎません。問われているのは、そのラッパーの形をどう選ぶかです。

ここでは現在有力な2つの選択肢、MCP（Model Context Protocol）とCLIを比較します。

MCPがもたらす「標準化」の恩恵と、運用上の検討事項

エージェントとSaaSを繋ぐ一つ目の手段は、MCPによる標準化です。JSON-RPCを介した「共通言語」により、エージェントは接続した瞬間に機能を理解し、APIドキュメントを読み込ませる手間を省けます。型定義が厳格で、既存のエコシステム（Claude、Cursorなど）との即時接続に優れるため、安定性とセキュリティを重視するエンタープライズ領域では有力な選択肢です。

MCPには大きくローカルMCPサーバーとリモートMCPサーバーの2つの形態があり、近年は後者が主流になりつつあります。AtlassianやNotion、Stripe、Azure DevOpsといった主要SaaSは既にリモートMCPサーバーをホスト提供しており、ユーザーはOAuth認証でログインするだけで利用開始できます。導入のハードルは劇的に下がりました。

一方で、SaaSプロバイダ側にはいくつかの検討事項があります。MCPサーバーを実装・運用する責務を自社で負うこと、リモート提供の場合は継続的なホスティングコストが発生すること、そしてMCPサーバーが提供するツール定義やスキーマ自体が、利用者側のAIエージェントのコンテキストウィンドウ（＝LLMに一度に渡せるトークンの上限枠）を一定量消費することです。MCPは接続時にツール一覧や引数の型情報をエージェントに渡すため、その分だけエージェントの作業領域が圧迫され、結果的にユーザー側のトークンコストや応答品質に影響します。「MCP対応する」という意思決定は、to A戦略の中でも比較的重い投資になります

CLIという「シンプルさ」がAIの推論を引き出す

一方で、高度な推論能力を持つ現代のLLMにとって、MCPは時に過保護になりつつあります。そこで再評価されているのが、CLIをツールとして直接エージェントに渡す手法です。

UNIX哲学に基づいた grep や jq をパイプで繋ぎ、標準出力を直接受け取るCLIは、AIにとって最も「試行錯誤」がしやすいインターフェースです。--json 出力や充実した --help さえあれば、AIは自律的にコマンドを組み合わせ、現場の状況に合わせたアドリブの操作を最適化していきます。

bash

# AIが自律的にCLIをパイプで繋ぐイメージ
# 「直近の顧客5件のメールアドレスを取得する」
$ stripe customers list --json --limit 5 | jq '.data[] | {id, email}'

# 必要な情報はすべて --help から自己発見できる
$ stripe customers list --help
Usage: stripe customers list [options]
  --limit <n>     A limit on the number of objects to be returned
  --json          Output results in JSON format
  ...

エージェントは --help を読んで使い方を学び、--json で機械可読な出力を受け取り、jq でフィルタする ── この一連の動作はLLMにとって極めて自然です。SaaSプロバイダ側も、既存のCLIに --json フラグと丁寧な --help を整備するだけで済むため、MCPサーバーの構築・運用と比べて初期投資を大幅に抑えられます。

「Push型の定義」から「Pull型の探索」への転換

この対立の本質は、AIを「APIを叩くクライアント」と見るか、「OSを操作するユーザー」と見るかの思想の違いにあります。

MCPはサーバー側が見せられるデータを事前に定義して提供するPush型ですが、CLIはエージェントが必要な情報を自ら cat や grep で探しに行くPull型です。WasmやFirecrackerといった軽量サンドボックス技術により、AIに汚してもいい実行環境を瞬時に提供できるようになった今、構造化された不自由さよりも、非構造化な自由度を推論能力で乗りこなす方が、開発速度と柔軟性において勝るケースが増えています。

もちろんこれはどちらかが絶対的に優れているという話ではなく、プロダクトの性質と顧客層によって最適解は変わります。エンタープライズ向けで監査性・セキュリティが最優先ならMCP、開発者向けで柔軟性・速度を重視するならCLI、というのが現時点での大まかな目安だと考えられます