「話しかけるだけで使えるSaaS」へ ── CLANE製品をMCPサーバー化して得た設計ノウハウ

CLANEでは、自社で開発・提供するプロダクト群を順次 MCP（Model Context Protocol）サーバー化 してきました。Form Auto Runner、AI Web Production Workspace、Spreadsheet Extension、Knowledge Automation Archive、そしてプロダクト基盤である CLANE One 自身まで、いずれも「Claude などのAIから直接話しかけて操作できる」状態を標準仕様として組み込んでいます。

この記事では、なぜMCP化に踏み切ったのか、どう設計したのか、そして実際に量産するなかでつまずいた点と対処を、これから自社プロダクトをMCP対応させたい方に向けて整理します。社内の認証情報や個別エンドポイントには触れず、再現できる「考え方」の部分をまとめました。

MCPとは何か、そして2026年の現在地

MCPは2024年11月にAnthropicがオープンソース化したプロトコルです。それからわずか1年半で、Anthropic・OpenAI・Google・Microsoft・AWS をはじめとする主要ベンダーがこぞって対応する、AIエージェント連携の事実上の標準になりました。「AIの世界のUSB-C」と呼ばれることもあります。

技術的には、JSON-RPC 2.0 を土台に、外部システムを次の3つのかたちでAIに公開します。

• Tools … AIに実行させる操作（検索・登録・更新など）
• Resources … AIに参照させるデータ
• Prompts … 定型のプロンプトテンプレート

従来は「AIアプリの数 × ツールの数」だけ個別の連携コードが必要で、しかもそれぞれが独自に認証やデータ取り扱いを実装していました。MCPはこの組み合わせ爆発を、共通の発見・呼び出し・認証の作法に置き換えます。一度サーバーを作れば、MCP対応のどのホスト（Claude のアプリ、Claude Code、各種エディタなど）からも同じように使えるのが最大の利点です。

接続方式（トランスポート）は2種類です。

• stdio（ローカル） … ホストが子プロセスとしてサーバーを起動し、標準入出力で通信する。設定不要で速いが、基本は1クライアント向け。手元の開発に向く。
• Streamable HTTP（リモート） … HTTPSのエンドポイントを公開し、複数クライアントが同時接続できる。本番のSaaSに公開するならこちら。

SaaSをプロダクトとして外部に提供するなら、選択肢は実質「リモートMCP（Streamable HTTP）」一択です。CLANEもすべてこの方式で公開しています。

なお、ここでいう「公開」とは、エンドポイントをインターネットから到達可能にするという意味です。接続そのものはOAuthで認可制であり、誰でも繋がるわけではありません。認可ポリシーはサーバー側で制御でき、たとえば社内ドメインの利用者や管理者に限定することもできます（CLANEのハブ的なMCPは、運営管理者・社内アカウントのみに接続を限定しています）。

2026年は「大改訂の年」

ひとつ重要な前提があります。MCPの仕様は速いペースで進化しており、2026年7月28日付で過去最大の改訂が行われ、すでにリリース候補（RC）が公開されています。この改訂ではセッションの概念が廃止され、プロトコル層がステートレスになります。これにより、これまで sticky session や共有セッションストアを必要としたリモートMCPサーバーが、ふつうのラウンドロビン型ロードバランサの背後で水平スケールできるようになります。あわせて、サーバーがUIを返す「MCP Apps」や長時間処理向けの「Tasks拡張」など、拡張の枠組みも整理されます。

ここで強調したいのは、MCP対応を始めるなら認証とバージョン管理を最初から設計に織り込むべきということです。仕様は破壊的変更を伴いながら進むので、プロトコルバージョンは固定し、移行の工数をあらかじめ見込んでおくのが現実解です。

CLANEのMCPアーキテクチャ

CLANE製品のMCP化で、私たちが核に据えた設計判断は次の4つです。

1. 認証は「共通アカウント基盤」を再利用する

製品ごとにログインの仕組みを作り直すと、ユーザーは製品の数だけアカウントを持つことになり、運用も分散します。CLANEでは認証基盤を1つに集約し、全製品がそこに乗る形にしています。ユーザーから見れば「一度ログインすれば、どのCLANE製品でも同じアカウントで使える」状態です。

リモートMCPサーバーの認証は、2025年6月の仕様以降 OAuth 2.1 が標準で、インターネットに公開するサーバーは PKCE（S256）必須です。MCPサーバーはOAuthの「リソースサーバー」として振る舞い、対応する認可サーバーの場所を .well-known 経由で広告します。実際にClaudeのコネクタに自社のMCPエンドポイントを登録すると、裏ではこのOAuthフローが走り、ユーザーはおなじみのログイン画面を踏むだけで接続が完了します。

2. トークンは公開鍵で検証し、秘密鍵は持たない

各製品のサーバーは、受け取ったJWTを JWKS（公開鍵）で検証するだけで認証を完結させています。認証基盤の管理者権限に相当する秘密鍵は、製品側には一切置きません。これにより「製品が増えても、漏れて困る鍵が増えない」状態を保てます。鍵が一箇所に集約されているので、ローテーションも基盤側で一度行えば全製品に波及します。

3. データは各製品の内側に閉じる

認証基盤に保存するのは「誰がログインしたか」だけです。製品が扱う実データは、その製品のサーバー内（VPS内のデータベース）に閉じ込めます。 認証とデータを分離しておくと、認証基盤が単一障害点・単一漏洩点になりにくく、製品ごとの責任範囲も明確になります。

4. 複数製品を1台に同居させ、量産する

新製品ごとに「サブドメイン → ローカルポート」を割り当て、リバースプロキシ（Apache）とTLSで公開する構成にしています。製品ごとにスラッグ（識別子）を一意に決め、MCPサーバー名やトークンの接頭辞に使うことで、同じインフラ上に複数製品をきれいに同居させられます。

この4点をスターターキットとして雛形化したのが、量産を支える最大の仕掛けです。認証・OAuth・MCPの土台は雛形側で完成済みなので、新しい製品を立ち上げるときに開発者がやるのは、原則として「APIとテーブルとMCPツールを足すだけ」になります。

つまずいたポイントと、そこで得たノウハウ

ここからが本題です。実際にMCP化を進めるなかで判断を迫られた点を、対処とセットで共有します。

ツールの「説明文」はそのままUXになる

MCPのツールは、AIがその説明文（description）を読んで「いつ・どう呼ぶか」を判断します。つまりツール名と説明文の設計が、そのまま使い勝手を左右するということです。曖昧な説明だとAIが見当違いのツールを呼び、的確に書けばAIが自然に正しく使ってくれます。私たちは、ツール名は動詞＋目的語で具体的に（search_items、update_status など）、説明文には「このツールを使うべき場面」と「使ってはいけない場面」を明記する、という方針に落ち着きました。

同時に、ツール説明はAIが読むテキストである以上、プロンプトインジェクションの経路にもなり得ます。説明文や返却データに外部由来の文字列を素通しで載せないよう注意が必要です。

書き込み系ツールは「テナント分離」と「確認」を必ず挟む

最も神経を使うのが、AIにデータを「書かせる」操作です。私たちのルールはシンプルです。

• テナント分離を強制する。ツールの処理は必ずログインユーザーのIDでスコープし、他人のデータを読ませない・書かせない。これはMCPツールに限らず、保護APIすべての大原則です。
• 不可逆な操作は確認を挟む。削除・送信などは、実行前にユーザーへ確認させ、サーバー側でも入力検証する。
• 鍵はサーバーから出さない。LLM呼び出しや外部API連携はサーバー側だけで行い、APIキーをフロントに渡さない。

仕様面でも、2025年以降は Resource Indicators（RFC 8707） の実装がクライアントに求められています。これは「あるサーバー向けに発行されたトークンを、別のサーバーで使い回される（confused deputy / トークンの誤用）」攻撃を防ぐためのものです。サーバー側も Protected Resource Metadata（RFC 9728） を公開し、未認証アクセスには素直に401を返して、クライアントが正しい認可サーバーを発見できるようにしておく ── この「401は正常応答」という設計が、接続トラブルの切り分けを楽にしてくれます。

「外部AIに操作させるMCP」と「製品内のAIチャット」は別物

ここは混同しやすいポイントです。MCPサーバーは、Claudeのような外部のAIホストに自社製品を操作させるための入口です。一方で、製品の画面の中に「データについて質問でき、操作も代行してくれるAIチャット」を組み込みたい場合は、MCPとは別に製品自身のチャットAPIを用意します。両者は役割が違い、併用できます。

私たちの製品内チャットは、まず読み取りエージェント（ドキュメントやデータを根拠に質問へ答える）から始め、慣れてから操作エージェント（チャット指示で登録・更新などを代行する）へ拡張する、という順序で育てています。CLANE One の管理画面自身も、この形で動いています。いきなり全部を操作可能にせず、安全な読み取りから段階的に広げるのが結果的に近道でした。

ステートレス化 ── CLANEは既に適合済み

前述の2026年7月28日の改訂で、セッションが廃止されステートレスになります。CLANEのMCPサーバーは、この改訂を待たず、すでに完全なステートレス設計です。 セッションを持たず、リクエストごとにトークンを再検証し、サーバー起点のSSE（GET接続）も提供しません。そのため、今回の大改訂にも設計を変えることなくそのまま適合します。

一般論としても、各リクエストを自己完結させる（トークン検証がセッション文脈に依存しない）方向に寄せておくと移行は容易です。エンタープライズ向けには、各サーバーにOAuth検証を個別実装するのではなく、前段にゲートウェイを置いてトークン検証・スコープ制御・監査ログを一元化するパターンが定着しつつあります。製品数が増えるほど、この一元化の価値は高まります。

MCP化がもたらした変化

MCP化を進めて一番大きかったのは、「製品を作る」という行為の定義が変わったことです。

これまで「プロダクトを作る」とは、画面を作り、APIを作ることでした。いまはそこに「AIから話しかけて使える状態にする」が加わります。ユーザーは管理画面を開かなくても、使い慣れたAIアシスタントから自然言語で操作できる。製品は「人が触るUI」と「AIが触るインターフェース（MCP）」の両方を持つのが当たり前になりつつあります。

そしてCLANEにとっては、認証・OAuth・MCPを雛形に作り込んだことで、新しいSaaSを「AI対応済み」の状態で立ち上げられるのが効いています。土台が共通なので、製品ごとに作るのは固有の価値（テーブルとAPIとツール）だけ。これが、複数プロダクトを並行して育てられている理由です。

まとめ

CLANE製品のMCPサーバー化で得た要点を整理します。

1. 公開するならリモートMCP（Streamable HTTP）＋ OAuth 2.1 / PKCE が前提。認証は最初から設計に織り込む。
2. 認証は共通基盤に集約し、トークンは公開鍵で検証、秘密鍵は製品に置かない。 データは製品の内側に閉じる。
3. ツールの説明文はUXそのもの。 書き込み系はテナント分離と確認を必ず挟む。
4. 外部AI向けのMCPと、製品内チャットは別物。 読み取りから段階的に育てる。
5. 仕様は速く進化する（2026年7月28日のステートレス大改訂）。 CLANEは既にステートレス設計のためそのまま適合。バージョン固定・自己完結型の設計・ゲートウェイ一元化を基本に据える。
6. 土台をスターターキットとして雛形化すれば、新製品を「AI対応済み」で量産できる。

「話しかけるだけで使えるSaaS」は、もう先進的な実験ではなく、これから作るプロダクトの標準仕様になっていきます。CLANEは引き続き、自社プロダクトと、お客様のプロダクトの両方で、この設計を実装の現場から磨いていきます。

参考

• Model Context Protocol 公式仕様: https://modelcontextprotocol.io/
• 2026-07-28 リリース候補（ステートレス化）の解説: https://blog.modelcontextprotocol.io/