- MCP（Model Context Protocol）とは
- MCP（Model Context Protocol）とは、AIが外部のシステムやデータを直接操作するための共通規格のことです。APIをAIが理解できる「道具」の形に翻訳し、Claude・Cursorなどの対応クライアントからそのまま呼び出せるようにします。
こんにちは、Webflow専門家からAIサイト制作・AI開発へ主戦場を広げているマサトです。宮城県塩竈市でWeb制作会社「Web春」をやっています。
自社で運営しているサイト運用基盤のCMSに、REST APIとMCPサーバーを実装して、開発者向けドキュメントまで一般公開しました。この記事は、その設計判断をそのまま書き残したものです。「MCPサーバーってどう作るの？」「AIに自社システムを触らせて大丈夫なの？」という疑問に、実装した側から答えます。
この記事の内容
- 何を作ったのか（REST API・MCPサーバー8ツール・公開ドキュメント・llms.txt）
- APIだけでは足りず、MCPまで作った理由
- AIに鍵を渡すときに、設計で止めた3つのこと
- ドキュメントを「AIに読ませる前提」で書くということ
先に結論から書きます。
AI導入がうまくいかない原因の多くは、AIの性能ではなく、AIが自社のデータに触れないことです。接続口（API）とAIの手（MCP）さえ用意すれば、いま社内で使っているAIがそのまま実務を動かします。そして、そこで一番時間をかけるべきなのは実装ではなく「何を触らせないか」の設計です。
何を作ったのか
作ったのは、CMSの記事を外部から操作するための入口です。入口は2つあります。
- REST API — 記事の作成・取得・更新・削除、カテゴリ一覧、画像アップロード。Bearer認証のAPIキーで叩きます
- MCPサーバー — 同じ操作を、Claude CodeやClaude Desktop、CursorなどのAIクライアントから直接呼べる形にしたもの。ツールは8つです
この2つは、どちらもCMS本体とまったく同じ公開パイプラインを通ります。ブラウザのエディタで書いても、APIで送っても、AIに指示しても、検証・履歴・監査ログは同じ。ここを分けてしまうと「エディタでは弾かれるのにAPIからは通る」という穴ができるので、実装は共通化しました。
記事を published にした瞬間に、静的サイトのビルドとデプロイまで自動で走ります。Webhookを組んだりCIを設定したりする必要はありません。
APIだけでは足りず、MCPまで作った理由
「APIがあるならAIから使えるのでは」と思われるかもしれません。実際には、そこにもう一段の翻訳が要ります。
MCP（Model Context Protocol）は、AIが外部システムを操作するための共通規格です。APIが「システムの入口」だとすれば、MCPは「AIがその入口を使うための手」にあたります。
APIだけの状態でAIに使わせようとすると、エンドポイントの説明・認証の渡し方・レスポンスの読み方を毎回プロンプトで教えることになります。会話をまたぐと忘れますし、人によって書き方が違うので結果もぶれます。MCPにしておくと、ツールの一覧と引数の形をAI側が構造として理解するので、そのばらつきが消えます。
もうひとつ大きいのは、規格が共通であることです。特定のAIサービス専用に作り込むと、乗り換えのたびに作り直しになります。MCPは対応クライアントが増え続けているので、AIの側を替えても接続口はそのまま使えます。長く使う業務システムほど、ここは効いてきます。
AIに鍵を渡すときに、設計で止めた3つ
ここがこの実装で一番考えたところです。システムをAIにつなぐと、便利さと同時に「勝手に消される・勝手に公開される」というリスクが生まれます。そしてこれは、運用ルールでは守りきれません。「AIには丁寧に指示しましょう」で防げる事故ではないからです。
①既定値を安全側に置く
ステータスを明示しない作成は、必ず下書きになります。AIが会話の流れで勝手に公開することはありません。公開したいときだけ、明示的に指定してもらう。逆にしてしまうと、事故が起きたときに取り返しがつきません。
②鍵の効く範囲を、最初から絞る
APIキーは1サイト分の権限しか持ちません。他のサイトのデータにも、管理機能にも一切届かない。「とりあえず全部触れる鍵を渡して、使う側が気をつける」という設計にしないことが大事です。
③全操作を記録し、いつでも止められるようにする
いつ・どのキーが・どの記事に何をしたかは、すべて監査ログに残ります。鍵は停止すればその場で失効します。さらに誰が発行した鍵かも記録しているので、担当者が変わっても後から追えます。
この「誰の鍵か」は地味ですが重要で、鍵はアカウントと独立に生きてしまうと「ログインは止めたのに、外部APIからはまだ書ける」という状態が作れてしまいます。そうならないように、メンバーを止めたらその人が発行した鍵も自動で止まるようにしました。削除ではなく停止にしてあるので、誤爆しても戻せます。
外部にHTMLを作らせない、という判断
細かいところですが、設計判断としてはっきり効いているのがこれです。記事の本文はMarkdownだけを受け取り、HTMLへの変換はサーバー側で行います。
外部からHTMLをそのまま送り込める設計にすると、崩れたマークアップや想定外のタグが本番サイトに混ざります。AIが生成したものを直接流し込むならなおさらです。入口をMarkdownに絞っておけば、どこから来た記事でも、サイト側の見た目は一定に保てます。「AIに任せる」というのは、任せる範囲を決めることとセットです。
ドキュメントは、AIに読ませる前提で書く
今回いちばん時代が変わったと感じたのがここでした。開発者ドキュメントを作るとき、読者は人間だけではありません。
用意したのは3種類です。人が読むリファレンス（HTML）、AIに要点を渡す llms.txt、そして仕様の全文を1ファイルにまとめた llms-full.txt。最後のものは、導入する側のAIエージェントにそのまま読ませて実装させるためのファイルです。
これがあると、使う側は「ドキュメントを読んで理解してから書く」必要がありません。AIに全文を渡して「これを使って記事を投稿する仕組みを作って」と言えば動きます。ドキュメントの品質が、そのまま導入のしやすさになるという構造です。
この仕組みを、そのまま商品にします
ここまで書いてきたのは自社CMSの話ですが、必要な要素は業種を問いません。
- 外から読み書きできるAPI
- AIがそれを道具として使えるMCP
- AI自身が読めるドキュメント
- そして、何を触らせないかの設計
「AIを導入したのに、結局スクリーンショットを貼ってコピペしている」——この状態から抜けるために足りないのは、たいていこの4つです。Web春では、この一式をAPI・MCP開発としてお受けしています。すでにAPIがあればMCPを被せるだけで済みますし、無ければ接続口から作ります。
実物は公開ドキュメントでそのままご覧いただけます。提案資料の中の絵ではなく、いま動いているものです。
→API・MCP開発のサービス詳細
よくある質問
MCPとAPIは何が違うのですか？
APIは「システムの入口」、MCPは「AIがその入口を使うための手」です。APIだけでもプログラムからは操作できますが、AIに使わせるには認証の渡し方やレスポンスの読み方を毎回説明する必要があります。MCPにするとツールの一覧と引数の形をAI側が構造として理解するため、説明なしで安定して動きます。
AIに勝手にデータを消されたり公開されたりしませんか？
設計で止めます。ステータスを明示しない作成は必ず下書きになるようにし、鍵の効く範囲は1サイト分に絞り、全操作を監査ログに記録します。鍵は停止すればその場で失効し、誰が発行した鍵かも記録されます。運用ルールではなく既定値と権限範囲で守るのが原則です。
MCPサーバーは自社でも作れますか？
仕様は公開されているので、開発リソースがあれば作れます。ただし実装そのものより、どの操作を許可し何を触らせないかという権限設計のほうが難しく、事故が起きるのもそこです。既存システムにAPIが無い場合は、まず接続口の設計から始める必要があります。
既にAPIがある場合、MCPだけ追加できますか？
できます。既存APIの仕様が整理されていれば、その上にMCPサーバーを被せるだけで済みます。当社ではその構成を単体のプランとしてご用意しています。
llms.txtとは何ですか？
サイトやサービスの仕様をAIが読み取りやすい形でまとめたテキストファイルです。開発者ドキュメントに添えておくと、導入する側のAIエージェントがそのまま読み込んで実装できるため、「ドキュメントを読んで理解してから書く」工程が不要になります。
