本記事は元々 blog.logto.io に掲載されたものです。

SaaS 製品には長年の課題があります：顧客が “価値を実感する” までの時間が遅すぎるのです。「アハ体験」に到達する前に多くのユーザーが離脱してしまいます。

Logto のオンボーディングを何度も改善してきました。それなりに効果はありましたが、本質的なボトルネックは解消されませんでした。結局、ドキュメントを読んで、チュートリアルを流し見し、SDK をインストールし、設定を書き、コードを書き、最後に 10% のデバッグをして…やっと動く、という流れは変わりません。

そこで、私たちは異なるアプローチを試みました：Logto の IDE ネイティブなコントロールプレーンとしてリモート MCP サーバーを構築したのです。管理コンソールでクリック操作をする代わりに、アプリを開発する現場で会話しながら Logto を設定し、統合コードを生成できます。

1 つのプロンプトでゼロから統合が動くところまで進められます。エージェントはコード生成だけでなく、あなたのテナントに Logto アプリケーションを作成・設定も行います。しかもすべて IDE 内で完結します。(Logto MCP Server を試す)

この記事では、Logto MCP サーバーの開発経験と考え方について、下記の観点から共有します。

MCP とエージェントスキルの比較：なぜ私たちは MCP を選んだのか
MCP サーバー開発で遭遇した問題とその解決策
MCP ツール設計方法と、みなさんが設計する際のポイント
MCP の将来への期待

Logto MCP サーバーの OAuth 実装は [mcp-auth](https://mcp-auth.dev) と Logto をベースにしています。MCP サーバーの OAuth に興味のある方は、このオープンソースプロジェクトを参考にしてください。

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 フロー詳細も記事として公開予定です。