本記事は元々 blog.logto.io に掲載されたものです。
SaaS 製品には長年の課題があります：顧客が “価値を実感する” までの時間が遅すぎるのです。「アハ体験」に到達する前に多くのユーザーが離脱してしまいます。
Logto のオンボーディングを何度も改善してきました。それなりに効果はありましたが、本質的なボトルネックは解消されませんでした。結局、ドキュメントを読んで、チュートリアルを流し見し、SDK をインストールし、設定を書き、コードを書き、最後に 10% のデバッグをして…やっと動く、という流れは変わりません。
そこで、私たちは異なるアプローチを試みました：Logto の IDE ネイティブなコントロールプレーンとしてリモート MCP サーバーを構築したのです。管理コンソールでクリック操作をする代わりに、アプリを開発する現場で会話しながら Logto を設定し、統合コードを生成できます。
1 つのプロンプトでゼロから統合が動くところまで進められます。エージェントはコード生成だけでなく、あなたのテナントに Logto アプリケーションを作成・設定も行います。しかもすべて IDE 内で完結します。(Logto MCP Server を試す)
この記事では、Logto MCP サーバーの開発経験と考え方について、下記の観点から共有します。
- MCP とエージェントスキルの比較：なぜ私たちは MCP を選んだのか
- MCP サーバー開発で遭遇した問題とその解決策
- MCP ツール設計方法と、みなさんが設計する際のポイント
- MCP の将来への期待
MCP とエージェントスキルの比較：なぜ MCP を選んだのか
AI が Logto へアクセスする方法を検討する際、私たちは MCP サーバーとエージェントスキルの 2 つの選択肢を比較しました。
MCP サーバーにはローカルとリモートの 2 つの形態があります。
ローカル MCP サーバーはユーザーのマシン上で稼働します。サービスのインストール、環境構築、認証情報や特殊なログインフローが必要です。利用・配布の観点ではスキルに非常に似ています。
リモート MCP サーバーはサーバーサイドでホスティングされます。ユーザーは URL で接続し、OAuth で認証します。このモデルは SaaS のサービス拡張に近いものです。
構造的に見ると、エージェントスキルは「ビジネスロジック＋下層の機能」の組み合わせです。その機能はツールや CLI、API 呼び出しなどで表現できます。MCP ツールはこの層を統一的に運べます。
つまり、重要なのは機能実装自体ではなく、「それをユーザーへどう届けるか」です。
-
エージェントスキル = 完全なローカルツールチェーン（スキルパッケージ＋ローカルランタイム＋API Key/プラットフォーム認証情報＋CLI ツール＋インストール／設定／アップグレード／保守の流れ）
本質的には、「ユーザー自身が各機能を動かす権利（能力）を渡す」モデルです。 -
リモート MCP サーバー = リモートサービスのエントリー(URL＋OAuth ログイン)
本質的には、「サービスとして能力を提供する」モデルです。
以下では、ユーザー体験・エコシステム到達度・配布と保守コストの観点から比較します。
ユーザー体験
エージェントスキルは多くの場合、プラットフォームの API や CLI へ依存します。ユーザーは最初に API Key 作成や CLI インストール・ログインが必要です。これら自体は難しくありませんが、参入障壁を上げます。
MCP サーバーは OAuth に対応。SaaS アカウントでログインするだけ。「Googleでサインイン」と似た体験です。
ユーザーにとって MCP サーバーの利用は簡単です：URL を入力→ログイン→接続。この体験を届けたいのです。
エコシステム到達度
MCP 公式サイト には、VS Code、Cursor、Windsurf などを含む 104 の AI アプリが MCP 対応を公表しています。
エージェントスキルは今もプラットフォーム依存です。多くのプラットフォームがスキル対応を始めたとしても、MCP サーバーを配信すれば誰でもすぐ使えます。スキル公開の場合、そのプラットフォームのユーザーしか使えません。
MCP は Agentic AI Foundation (AAIF) の標準プロトコルにもなっています。エコシステムは今後も拡大していきます。私たちにとって、これは長期的な投資価値のある分野です。
配布と保守コスト
エージェントスキルはプラットフォーム API や CLI へ依存するため、次のような課題がすぐ発生します：
- API が変更されたら？
- CLI が互換性を失ったら？
- スキルをどうやってアップデート／再配布するのか？
CLI 配布や認証情報の管理・複数プラットフォーム対応・アップグレード案内なども必要となり、ROI は非常に低いです。
MCP サーバーは遥かにシンプルです。ユーザーは URL で繋ぐだけ。常に最新バージョンを指します。私たちが MCP サーバーを更新すれば、次回接続時にすぐ反映。アップグレード作業が不要です。API 変更時も MCP サーバー内部で対応すれば大丈夫です。
多くの SaaS 製品はすでに堅牢なインフラ（API・認証基盤）を持っています。MCP サーバーは「API の AI インターフェース」として自然にフィットします。まるで管理コンソールがもう一つの UI であるかのように。
Logto にとって MCP サーバーの選択は、アーキテクチャとも自社の強みとも自然に合致します。
また、すべてのリクエストが 1 つの入り口に集約されるので、ログや監査も容易。権限も明確：「AI＝ユーザーが許可した操作しかできない」。このモデルは、エンタープライズやコンプライアンス面でも構造的に綺麗です。
MCP サーバー開発で直面した課題とその解決策
MCP も万能ではありません。多くの課題はエコシステムの成熟度に起因します。これは今後徐々に改善されていくでしょう。それまでは現実的なワークアラウンドで工夫しています。
MCP 機能サポートの断片化
MCP の仕様では多くの機能が規定されていますが、クライアントごとに対応状況が大きく異なります：
- Tools (ツール)：広くサポートされている
-
OAuth：VS Code では十分サポート、Cursor などは
mcp-remoteをブリッジとして利用 - その他（リソース, プロンプト, インストラクション）：サポートがまちまち
現状、ツール機能が最も信頼性の高い共通レイヤーです（MCP Community Page で各クライアントの対応状況を確認できます）。
私たちの戦略はシンプルです：ツールを軸に構築する。
LLM がツールの使い方を知らない
これはビジネスレイヤーの問題です。
エージェントスキルの場合、ビジネスロジックとコンテキストがパッケージ化されて LLM が使い方を知っています。MCP はツールの提供だけ。接続後、LLM は：
- どんな用途で使うのか
- 呼び出し順序
- ビジネス制約
これらを知りません。
MCP には Instructions という概念がありますが、すべてのクライアントが対応しているわけではありません。また、Instructions は接続時点で全ての内容を一括でコンテキストに入れるため、トークンの無駄遣いにつながります。
ツールの説明文にガイダンスを書く方法もありますが、次の問題が生じます：
- 説明文が複雑になる。マルチツールワークフローではロジックが絡み、保守困難になる。
- ツール数が増えると、説明文だけでコンテキストウィンドウを大量消費する。
私たちのワークアラウンド：getInstructions ツールの提供
発想はシンプルです。Instructions が上手く扱えないなら、それ自体をツール化すればよい。
LLM は必要な時だけ getInstructions を呼べます。
タスク A であれば getTaskAInstructions を呼び、MCP サーバーがタスク A の進め方とツール組み合わせ方を説明するプロンプトを返します。
複雑なビジネスロジックはインストラクションツール側に集約。他ツールはシンプルのままです。各ツールの説明文は個々の機能だけに集中できます。
この方式はエージェントスキル：オンデマンドでプロンプトをロードするやり方と似ていますし、Instructions に全てを詰め込むより遥かに効率的です。
LLM が秘密情報を漏えいする可能性
多くの SaaS 製品では一部の秘密情報（たとえばクライアントシークレット、API キー、Webhook シグニングキーなど）は絶対に漏らせません。漏れると他人があなたになりすましたり、資源へ直接アクセスされる危険があります。
LLM 利用時のリスクは「チャットが安全な通信路とは限らない」ことです。会話はログに残されたり、コピー・転送・デバッグログに保存されたりするかもしれません。「自分とモデルだけが閲覧できる」とは限りません。よって LLM に長寿命なシークレットを直接渡したり、コピー用途で出力させるのは非常に危険です。
従来の Web アプリ連携でも開発者はシークレットを作り、サーバーの環境変数や config に入れてから SDK 初期化等を完了します。
オンボーディングを簡単にしつつ秘密保持性を損なわないよう、私たちは 3 つの工夫をしています：
-
統合作業中は一時的なシークレットのみ利用
チャットベースの初期設定時には MCP サーバーから短命（一時間有効など）の一時シークレットのみ返します。統合が動くにはこれで十分ですし、多くの場合本番公開までに期限切れになります。本番公開時には開発者が独自に長寿命の本番シークレットを生成・交換します（チャット外で）。
-
セキュリティ境界を明示する
「本番シークレットはチャットで作らず、貼らず、保管もしない」ことを明確に警告します。また、エージェント/LLM がツール・間接参照で環境変数や設定ファイルを読む可能性もあるため、その点も開発者へリマインドします。本番シークレットは AI 連携のない環境だけに設置しましょう。
-
チャットで本番シークレットを扱わず、コンソール誘導
長寿命シークレットはチャットで生成・配布せず、コンソールの認証情報ページで作成・管理します。チャットではコンソールへのリンクだけを案内し、そこで作業してもらいます。
MCP ツール設計方法
私たちの試行錯誤
Logto には統合的な管理 API があります。最初はシンプルに「すべてのエンドポイントを MCP ツール化」すればよいと考えました。
しかしこれはすぐに失敗しました。
まず、コンテキスト爆発。Logto の API は多岐にわたります。単純マッピングでは説明文が膨大に膨らみトークンを圧迫します。
次に意味の希薄化。API は開発者向けの最小単位ですが、Logto MCP サーバーのユーザーはシステムを組む人ではなく、「単純にタスクを解決したい」だけです。どのエンドポイントがいくつ存在するかは気にしません。
例：Logto には sign-in-experience API（ブランディング、サインイン方法、サインアップ方法、セキュリティポリシー等）があります。
最初は「すべてのパラメータをどう LLM に教えるか」「どう呼び出しを組ませるか」に悩みました。
しかし、それは発想が逆です。ユーザーが求めているのは「ブランディングを変更したい」「ログイン方法の設定」なのです。
ツールは updateBranding、updateSignInMethod、updateSignUpMethod という単位でよい。API 組み立ては MCP サーバー内で吸収すれば十分です。
Logto MCP Server は「API ラッパー」ではなく「もう一つの管理コンソール」として設計すべきです。
MCP ツール設計指針
結論として：
- エンドユーザーが直接サービスを使う（＝コンソール的な用途）なら、ツールはビジネス志向で。
- 他者が基盤として組み込む用途（例：ファイルシステム MCP サーバーで
read_file,write_fileなど）、ツールはシンプルで原子的（atomic）なものに。
その他の原則：
- ツールのロジック・説明文は極力シンプルにし、コンテキスト消費を抑える。
- 複雑なワークフローは
getInstructionsツールでオンデマンドロード。説明文もできるだけ簡潔に。
MCP の今後への期待
MCP サーバーを構築しながら、エコシステム向上のために望むポイントも見えてきました。
スキルレベル能力デリバリー
時には MCP サーバーも、「ツールそのもの」だけでなく、それらをどう組み合わせてタスク化するか（＝エージェントスキルの機能）を届けたい時があります。
これは SaaS 領域では一般的です。GitHub MCP、Logto MCP、分析系 MCP サーバーなど、「ワークフロー志向」の方が多い。
getInstructions ツールはそのワークアラウンドですが、プロトコルレベルで対応してほしいです。
セッションレベルでの MCP 有効化/無効化
クライアントは複数の MCP サーバーへ同時接続しますが、すべてのセッションで全 MCP 機能が要るとは限りません。セッション単位での有効化/無効化ができればコンテキストの無駄遣いも減ります。
MCP ツール呼び出し時のコンテキスト分離
ツール呼び出しは大量のコンテキストを消費します。もし MCP 関連アクションをサブエージェントで処理し、主会話には要約した結果のみ返せるなら効率化できます。
結論
以上がリモート MCP サーバー構築の私たちの経験です。
もしこの分野に興味があれば、Logto MCP Server を試したり、Discord でコミュニティと現場の実装ノウハウを共有してください。
今後、アーキテクチャ設計や OAuth フロー詳細も記事として公開予定です。