SaaS MCP対応の進め方。2本の本番運用で固まった型5ステップ

SaaSのMCP対応とは: SaaSのMCP対応とは、自社の既存REST APIの上に、ClaudeやCursorなどのAIクライアントから直接操作できるMCPサーバーの層を追加することです。当社は自社SaaS 2本（8ツール構成のCMSとメールAPI）で実装・本番運用し、APIを作り直さずに対応できることを確認しています。

こんにちは、AIサイト制作とAI開発の会社「Web春」をやっているマサトです。自社SaaSとしてCMSとメールAPIを開発・運営しています。

「顧客からMCP対応を求められている」「役員会でAIエージェント対応を競合対比の課題に挙げられた」——そんな相談が、既存のSaaSや会員基盤を運営する企業から増えてきました。この記事は、当社が自社SaaSの2本——CMS（MCPツール8本）とメールAPI——を実際にMCP対応させ、本番で運用する中で固まった実装の型を書いたものです。読者は、既存のSaaS・業務システム・会員基盤をすでに運営している企業のCTO・プロダクト責任者を想定しています。これから新しくプロダクトを作る個人・小規模開発者は本記事の対象外です（個人開発者向けには教材を別商品として準備中です）。

先に結論です。SaaSのMCP対応は、既存のREST APIの上に薄いMCP層を足す構成が基本です。APIを作り直す必要はありませんし、MCPのために別システムを立てる必要もありません。工数の大半を占めるべきは実装そのものではなく、「ツールの粒度」「危険操作の止め方」「鍵と権限」という3つの設計です。

この記事の内容

MCP対応の基本構成（既存REST API＋薄いMCP層）
実装の型5ステップ（APIの整理からllms.txt公開まで）
ツール数を絞る理由（汎用MCPを試した実測の失敗）
誤送信をプロンプトではなく構造で防ぐ二段階設計
MCP対応すると何が起きるか（AIクライアントという新チャネル）

SaaSのMCP対応とは

SaaSのMCP対応とは、自社の既存REST APIの上に、ClaudeやCursorなどのAIクライアントから直接操作できるMCPサーバーの層を追加することです。MCP（Model Context Protocol）はAIが外部システムを操作するための共通規格なので、一度対応すれば特定のAIサービス専用の作り込みにはなりません。

MCPという規格そのものの解説と、当社が1本目（CMS）を作ったときの設計判断の一部始終は、MCPサーバーを自社CMSに実装した記事に書きました。本記事はその続編で、2本目のメールAPIまで作って再現性が確認できた「SaaS側の方法論」に絞ります。

SaaS MCP対応の実装の型5ステップ

SaaSをMCP対応させる実装の型5ステップ。既存REST APIの整理、ツールの粒度設計、危険操作の二段階化、鍵と権限の設計、ドキュメントとllms.txtの公開の順で進める。 — 既存APIを作り直さず、上に薄いMCP層を足していく順番です

5ステップの中身を順に説明します。なお、ツール定義の書き方などコードレベルの手順はMCPサーバーの作り方の記事に分けました。本記事は判断と設計に絞ります。

①既存REST APIの整理——正はあくまでAPI

MCPサーバーは、それ自体がビジネスロジックを持ちません。MCPはAPIの翻訳層であり、正はあくまでREST APIです。だからMCP対応の最初の仕事は、MCPのコードを書くことではなく、既存APIを「AIに渡せる状態」に整理することです。認証方式が統一されているか、エラーが構造化されて返るか、操作の単位が揃っているか。

当社のCMSでは、ブラウザのエディタ・REST API・MCPのどこから書いても、同じ検証・履歴・監査ログを通る作りにしました。入口ごとに挙動が違うと「エディタでは弾かれるのにAPIからは通る」という穴になるからです。既存の外部向けAPIが無いSaaSの場合は、先にAPIから作ります。順番は飛ばせません。

②ツールの粒度設計——多すぎるツールはコンテキストを食い潰す

MCP対応で一番「設計らしい」仕事です。結論はシンプルで、ツール数を絞り、1ツールが返す情報を小さく保つ。

根拠は僕自身の実測です。外部SaaSの汎用MCP（Webflow MCP 1.0）を実案件で使おうとしたとき、接続するだけで大量の情報が読み込まれ、AIのコンテキストの大半を消費して、実用に届きませんでした（実測の経緯はWebflow MCPを試した記事に書いています）。ツール定義と返却データは、AIの「作業机」を直接占有します。机が資料で埋まったAIは、肝心の仕事ができません。

この失敗から学んで、当社のCMSは記事の作成・取得・更新・削除、カテゴリ、画像アップロードといった基本操作を8ツールに収めました。「APIのエンドポイント全部に1対1でツールを生やす」のは、いちばんやりがちで、いちばん実用性を下げる設計です。

③危険操作の二段階化——プロンプトではなく構造で防ぐ

MCP対応SaaSにおけるAI誤操作対策の比較。メールAPIでは送信系ツールを下書き作成までに限定し、実送信はconfirm_sendという別ツールでしか実行できない二段階設計を採用。プロンプトで注意を頼む方式は採用しない。 — 取り返しのつかない操作は、頼んで防ぐのではなく構造で割ります

メールAPI（haru Mail）で徹底した設計です。送信系のツールはすべて「下書き作成」までしかできず、実送信は confirm_send という別ツールでしか実行できません。AIが一発でメールを送れる経路が、そもそも存在しない作りです。

「送信前に必ず確認してね」とプロンプトで頼む方式は採用しませんでした。指示は会話が長くなれば薄れますし、使う人によって書き方も変わります。取り返しのつかない操作は、頼んで防ぐのではなく、構造として二段に割る。送信・公開・削除・課金——自社SaaSの中で「一発で走ったら事故になる操作」を洗い出し、確認ツールを1枚挟む。設計としては小さな一手ですが、AI連携の安全性はまるで変わります。

④鍵と権限——止めたら全部止まる設計

AIクライアントに渡すAPIキーは、設定ファイルに書かれて長く生き続けるぶん、人間のログインより雑に扱われがちです。当社の設計は3点です。

pk（公開キー）とsk（秘密キー）の分離。フロントに置けるものと、サーバー側でしか持ってはいけないものを、名前の時点で区別する
メンバーを停止すると、その人が発行した鍵も自動で失効。「退職者のアカウントは止めたのに、その人が作ったAPIキーからはまだ書ける」という穴を、運用ルールではなく仕組みで塞ぐ
全書き込み操作を監査ログに記録。いつ・どの鍵が・何をしたかを、後から必ず追える状態にしておく

AI連携の事故は「AIが暴走した」より「権限の広い鍵が生き残っていた」の形で起きます。鍵のライフサイクルを人に紐づけておくことが、MCP対応の見えない本体です。

⑤ドキュメントとllms.txt——読者はAI

MCP対応したSaaSのドキュメントの読者は、人間だけではありません。導入する側も、自社のAIエージェントに「使い方を読んで組み込んで」と指示する時代です。当社は人間向けの開発者ドキュメントに加えて、AIが要点を読み取れる llms.txt まで一般公開しました。実物はCMSの公開ドキュメントでそのまま見られます。

機械可読なドキュメントがあると、導入企業側のAIが仕様を読んで接続コードまで書けるようになります。ドキュメントの機械可読性が、そのまま導入のしやすさ＝導入率になる構造です。

MCP対応すると何が起きるか

最後に視点を1段上げます。MCP対応は単なる技術対応ではなく、チャネルの追加です。

MCP対応すると、自社プロダクトが「AIエージェント経由で使われる」ようになります。ユーザーは管理画面を開かず、手元のAIに「下書きを作って公開まで進めておいて」と言うだけになる。操作の主体が人間からAIに移ると、プロダクトが選ばれる基準も「画面の使いやすさ」から「AIから使いやすいか」へ広がります。

もうひとつ、AIクライアントは営業チャネルにもなります。見込み客のAIがllms.txtとドキュメントを読み、導入コードまで書けるなら、「トライアル登録→チュートリアル→定着」の摩擦が丸ごと消えます。競合がまだ管理画面しか持っていないうちにAPI＋MCP＋機械可読ドキュメントを揃えるのは、機能追加より効く差別化だと考えて、当社は自社SaaSの2本ともこの構成にしました。

逆に「SaaSを提供する側」ではなく「AIエージェントを自社業務システムにつなぐ側」の設計は、AIエージェントと既存システムの連携の記事に書いています。

まとめ：MCP層は薄く、設計は厚く

SaaSのMCP対応の型を再掲します。

①既存REST APIの整理（正はAPI。無ければAPIから）
②ツールの粒度設計（数を絞り、返す情報を小さく）
③危険操作の二段階化（下書き＋確認ツールの構造で防ぐ）
④鍵と権限（pk/sk分離・停止で自動失効・監査ログ）
⑤ドキュメントとllms.txt（AIに読ませる前提で公開）

当社では自社2本での実装をそのまま商品化し、API・MCP開発として認証・レート制限・監査ログ・公開ドキュメントまで一式でお受けしています。料金はMCPスターター（読み取り専用）¥2,500,000、API＋MCPフルパック¥5,000,000、業務システム全体をつなぐフル統合は¥10,000,000〜（いずれも税別・個別見積）です。最初の一歩としておすすめしているのはスターター構成です。既存のREST APIに読み取り専用のMCP層を被せるだけなので、書き込み事故のリスクを構造ごと排除した状態で（目安4〜6週）、自社プロダクトが「AIから使われる」姿を役員と顧客に見せられます。「うちのSaaSの場合はどう進める？」という判定の段階でも、無料相談からどうぞ。

よくある質問

SaaSのMCP対応には、どれくらいの工数がかかりますか？

既存REST APIの整理状況でほぼ決まります。認証・エラー形式が整ったAPIが既にあれば、MCP層自体は薄く、5ステップのうち重いのはツールの粒度設計と鍵・権限の設計です。当社の受託では、既存APIに読み取り専用のMCP層を被せるMCPスターターが¥2,500,000（税別・目安4〜6週）、認証認可・監査ログ・公開ドキュメントまで含むAPI＋MCPフルパックが¥5,000,000（税別）です。

外部向けAPIがまだ無いSaaSでも、MCP対応できますか？

できますが、順番はAPIが先です。MCPサーバーはビジネスロジックを持たない翻訳層なので、正となるREST API（認証・エラー構造・監査ログ）を先に設計し、その上にMCP層を足します。API側を整えれば、AI以外の外部連携にもそのまま使えるため、無駄にはなりません。

AIに操作させて、誤送信や勝手な削除は防げますか？

防ぎ方は3点で、①危険操作の二段階化 ②鍵の権限分離 ③監査ログです。当社のメールAPIでは送信系ツールをすべて下書き作成までに限定し、実送信はconfirm_sendという別ツールでしか実行できません。AIが一発で送れる経路を構造として無くすのが原則で、プロンプトの注意書きには頼りません。

MCPサーバーのツール数は、いくつが目安ですか？

当社のCMSは作成・取得・更新・削除・カテゴリ・画像アップロードの基本操作を8ツールに収めました。基本の読み書きと確認系で1桁台に収まる粒度が僕の目安です。ツール定義と返却データはAIのコンテキストを直接消費するため、エンドポイント全部に1対1でツールを作ると実用性が落ちます。

実装にはどのSDKを使えばいいですか？

MCPの公式SDK（TypeScriptやPythonなど）が公開されているので、既存APIと同じ言語・スタックに合わせるのが基本です。MCPは共通規格なので、どのSDKで実装しても対応AIクライアントからは同じツールとして見えます。SDK選定より、ツールの粒度と権限の設計に時間を使うことをおすすめします。

自社にAI開発の人員がいません。MCP対応は外注できますか？

できます。当社では自社SaaS 2本の実装・本番運用で固まった型をそのまま使い、認証・レート制限・監査ログ・公開ドキュメント（llms.txt含む）までのAPI＋MCPフルパックを¥5,000,000（税別）でお受けしています。まず小さく始めたい場合は、読み取り専用のMCP層に絞ったMCPスターター¥2,500,000（税別）からの段階導入が可能です。既存APIがある場合はMCP層の追加から、無い場合はAPI設計から対応します。