MCP vs API vs CLI 論争の中で、監視SaaSのMCP serverを設計した話
「MCP vs API vs CLI、結局どれ?」問題
2026年、AI エージェントに自分のサービスを操作させたいとき、開発者は必ずこの問題にぶつかる。
「MCP server を作るべきか、REST API を Function Calling で叩かせれば十分か、それとも CLI を使わせるか。」
実際にこの議論は過熱していて、「MCP is dead, long live the CLI」という記事が出たり、ベンチマークで CLI が MCP より10倍安くて信頼性も高いというデータが出たり、逆に「API をそのまま MCP にするな」というアンチパターンの指摘があったり。GitHub Copilot はツール数を40から13に減らし、Block は30以上あったツールを2つにまで削った。「少ないツールが正義」という空気もある。
正直、自分も迷った。監視 SaaS を作るにあたって、AI にデータを渡す方法を整理したらこうなった。
1. REST API を Function Calling で叩かせる。 API ドキュメントを読んで、エンドポイントごとにスキーマを書く必要がある。提供側のコストはゼロだが、使う側の接続コストが高い。
2. CLI を AI に操作させる。 手軽だが、テキスト出力をパースすることになる。稼働率やレスポンスタイムのような数値を正確に扱いたい場面では不安定さが残る。
3. MCP server を用意する。 ユーザーは設定に URL を追加するだけ。tools のディスカバリーも認証も標準フローで動く。構造化されたデータが返る。提供側は REST API があればその薄いラッパーで済む。
自分は監視 SaaS を作るにあたって MCP server を用意することにした。REST API は当然作るので、MCP server の追加コストは小さい。一方でユーザーの接続コストは大きく下がる。作る側のコストが低くて使う側の体験が良くなるなら、やらない理由がない。
この記事では、その MCP server をどう設計したかを書く。
どの tools を公開するか
設計で最初に考えたのは、何を MCP の tools として公開するか。Read 系と Write 系に分けて整理した。
Read 系(情報を返すだけ):
- モニターのステータス一覧(コンパクト形式 + 絵文字で一目で分かる)
- 手動チェックの実行と結果取得
- アクティブなインシデント一覧(ステータスでフィルタ可能)
- ステータスページ一覧
Write 系(状態を変える):
- モニターの新規作成・更新・削除
- インシデントの確認済みマーク・手動作成・解決・削除
Read 系だけでも十分に便利で、リスクも少ない。ただ「この URL 監視して」の一言でモニターが作れる体験は、MCP を入れる一番分かりやすいメリットだと思った。ダッシュボードを開いて URL を入力してチェック間隔を選んで通知先を設定して...が一言になる。Write 系も入れることにした。
削除も許可した。 当初は削除を禁止する設計を考えていたが、実際に使ってみると「このモニターもう要らない、消して」という操作は日常的に発生する。AI が誤って消すリスクよりも、毎回ダッシュボードに戻る手間のほうが大きいと判断した。ただしインシデントの削除は手動作成分のみに制限している。
3つの設計判断
1. 認証: APIキー + セッション
MCP spec では OAuth 2.1 が標準認証として定義されている。ただし MVP では実装コストを優先して、APIキー(mk_* 形式)による Bearer 認証を採用した。ユーザーは MCP クライアントの設定に APIキーを1行追加するだけで接続できる。
MCP server 側では認証後にセッションを KV に保持し(24時間 TTL)、以降のリクエストではセッション ID で認証を引き継ぐ。OAuth 2.1 対応は将来のロードマップに入れている。
2. スコープ: team 単位
マルチテナント SaaS なので、認証トークンをどのスコープに紐づけるかという問題がある。
team 単位にした。ほとんどのユースケースが「自分のチームの全モニターの状態」を聞くものだから。monitor 単位だと毎回どのモニターかを指定する必要があって面倒。引数で monitor_id を渡せば個別も見られるし、省略すればサマリーが返る設計にした。
3. レート制限: KV キャッシュ + プラン連動
AI エージェントは人間より高頻度で tools を呼ぶ可能性がある。Read 系は KV にキャッシュして同じデータを短時間に何度も取りに行かないようにする。Write 系はプランに応じたレート制限をかける。モニター作成は Free プランの上限チェックと組み合わせる。
「API のラッパー」では足りなかった
最初は MCP server を REST API の薄いラッパーとして作った。認証とスコープを変換して API を呼んで結果を返すだけ。実際これで動く。
ただし、そのまま使うと問題が出る。API のレスポンスは人間向けに設計されていて、AI には不要なフィールドが大量に含まれている。モニター一覧を返すと、config の詳細、作成日時、更新日時、全部入ってくる。AI が「今落ちてるサービスある?」と聞いただけなのに、数千トークンのレスポンスが返る。会話が長くなるほどこれが積み重なってコストが膨らむ。
「APIをそのままMCPサーバーにするな」 という記事でも指摘されている問題で、自分もまさにこれをやってしまっていた。
MCP server は API のラッパーだが、レスポンスは AI 向けに絞る必要がある。 ステータス確認なら名前・URL・状態・レスポンスタイムだけ返せばいい。一覧は件数制限をかける。ツール説明も API ドキュメントの転記ではなく、簡潔に書く。
構造としては API を叩いているので「ラッパー」に違いはないが、間にフィルタ層を挟む イメージが正しい。
こういう設計で Manako という監視 SaaS を作っています。
Discussion