0:00 0:00
記事
Claude Code用に独自MCPサーバーを作る前に考えること
Claude Code向けに独自のMCPサーバーを自作すべきか判断するための観点を整理します。既存サーバーやCLIで足りないかの確認、ツール設計、認証、運用と保守コスト、コンテキスト圧迫のリスクまでを公式仕様に沿ってまとめた、独自MCPの是非を判断したい上級者向けの実務ガイドです。
Claude Codeで「社内システムとつなぎたい」「独自のAPIを叩かせたい」と思ったとき、すぐに独自MCPサーバーの実装に入るのは早計です。本記事は、コードを書き始める前に「そもそも自作すべきか」を判断するための観点を整理します。
結論：独自MCPは「他の手段で足りないとき」の最後の選択肢
MCP（Model Context Protocol）は、Claudeに外部ツールの「ツール・リソース・プロンプト」という拡張点を与える標準仕様です。仕組みの基礎は「Claude CodeとMCPサーバーの基本」にまとめています。
独自MCPサーバーは強力ですが、作ると保守対象が1つ増えます。書き始める前に、次の順で「作らずに済む道」を潰します。
- 既存のMCPサーバーで足りないか：公式・サードパーティに同等品がないか
- CLIツールで足りないか：
Bashから叩けるCLIなら、MCPより軽い - スクリプト＋
@参照で足りないか：単発の処理なら自作MCPは過剰 - どれも当てはまらない：このときだけ独自MCPを検討する
公式ドキュメントのMCPも、まず既存サーバーの利用を前提に書かれています。自作は「標準化された接続を、繰り返し・複数人で使う」ときに初めて見合います。
「作らない」で済む3つの代替
独自MCPを検討する前に、次の3つで足りないかを必ず確認します。
| 代替手段 | 向いている状況 | MCPより優れる点 |
|---|---|---|
| 既存MCPサーバー | GitHub、Sentry、DBなど一般的な対象 | 実装・保守が不要 |
| CLIツール＋Bash | コマンドで完結する操作 | コンテキストが軽い。定義をロードしない |
スクリプト＋@参照 | 単発・低頻度の処理 | 仕組みが単純で壊れにくい |
特に見落とされやすいのがCLIです。MCPサーバーは接続するとツール定義がコンテキストに常駐し、サブエージェントにも継承されてコンテキストを圧迫します。一方、CLIは必要なときだけBashで呼ぶため軽量です。この差は「Claude Codeに必要な情報だけ渡すコンテキスト設計」で扱った「CLIはMCPより軽い」という原則そのものです。
用途別に既存サーバーがないかは「Claude Codeで使いたいMCPサーバー候補と選び方」を先に確認してください。
独自MCPが見合うケース・見合わないケース
代替を潰したうえで、自作が見合うかを判断します。
見合うケース
- 社内専用のシステムで、公開された既存MCPサーバーが存在しない
- 同じ接続を複数人・複数プロジェクトで繰り返し使う
- CLIでは表現しにくい「リソース」や「プロンプト」を提供したい
- アクセス制御やデータ整形を、接続層で一元管理したい
見合わないケース
- 自分1人が、数回だけ使う
- 既存のCLIやAPIをラップするだけ（それならCLIを直接使う）
- 「とりあえず便利そうだから」という動機しかない
- 保守する人が決まっていない
判断の軸は「繰り返し使うか」「複数人で使うか」「標準化された接続点が要るか」です。1つもイエスがなければ、自作は割に合いません。
設計前に決めておく5項目
自作すると決めたら、コードの前に設計を固めます。最低限、次の5つを書き出します。
- 公開するツールの粒度：1ツール1責務。「何でもやる」巨大ツールを作らない
- 入力と出力のスキーマ：引数と返り値の型を明確に。曖昧だとClaudeが誤用する
- トランスポート：ローカル限定なら
stdio、リモート共有なら推奨されるStreamable HTTP - 認証：APIキーやトークンの渡し方。環境変数展開を使い、直書きしない
- スコープ：個人用は
local、チーム共有は.mcp.jsonのproject
ツールの数を増やしすぎると、それだけコンテキストを消費します。「本当に必要なツールだけ」を最初に絞るのが、設計段階で最も重要な判断です。
認証とセキュリティの注意点
独自MCPサーバーは、外部システムへの認証情報を扱うことが多く、セキュリティ設計を後回しにできません。
- APIキーは環境変数展開で渡す：
.mcp.jsonに${VAR}で書き、キー本体はコミットしない - 最小権限のトークンを使う：読み取りで足りるなら書き込み権限を持たせない
- 取得コンテンツ由来のプロンプトインジェクションに備える：MCPが外部から取ってきた文字列を、そのまま指示として扱わせない
bypassPermissionsを常用しない：MCPツールの実行も承認の対象に保つ
秘密情報の具体的な扱いは「Claude Codeに秘密情報を渡さないための実践ルール」、MCP全体のセキュリティ観点は「Claude Codeを使うときのセキュリティチェックリスト」に詳しくあります。自作MCPは「自分が書いたコードが認証情報を扱う」ため、既存サーバーを使う以上に注意が必要です。
動作確認の進め方
実装したら、Claude Codeに組み込む前に単体で動くかを確認します。MCPサーバーを登録するコマンドは次の形です（オプションはサーバー名の前、起動コマンドは--の後）。
claude mcp add my-server --scope local -- node ./mcp-server/index.js 登録後、認識されているかは一覧で確認します。
claude mcp list 接続できないときは、トランスポートの指定、起動コマンドのパス、環境変数の渡し漏れを順に疑います。MCP関連のエラーの逆引きは「Claude Codeのよくあるエラー一覧と原因別の直し方」にもまとめています。
保守コストを見積もる
独自MCPサーバーは「作って終わり」ではありません。次のコストが継続的に発生します。
- 外部システムのAPI変更への追従
- MCP仕様やClaude Code側の更新への対応
- 認証トークンの更新・ローテーション
- 障害時の切り分け（Claude Code側か、MCP側か、外部システム側か）
このコストを払う人が決まっていないなら、自作は見送ったほうが安全です。「動いているが誰も保守していないMCPサーバー」は、いずれ壊れて、しかも壊れたことに気づきにくい状態になります。実装記事に進む前に、本記事の判断で「本当に作るべきか」を一度立ち止まって確認してください。
チェックリスト
- 既存のMCPサーバーで代替できないか確認した
- CLIツール＋Bashで足りないか確認した
- 「繰り返し使う／複数人で使う」のどちらかに当てはまる
- 公開するツールを最小限に絞った（1ツール1責務）
- 入力・出力スキーマを設計段階で明確にした
- APIキーは環境変数展開で渡し、最小権限にした
- トランスポートとスコープを用途に合わせて選んだ
- 保守する人とコストの見積もりが決まっている
次に読むおすすめ記事：
- 「Claude CodeとMCPサーバーの基本：できることと導入前の注意点」：MCPの仕組み・トランスポート・スコープの基礎
- 「Claude Codeで使いたいMCPサーバー候補と選び方」：自作の前に確認したい既存サーバー一覧
- 「Claude Codeに必要な情報だけ渡すコンテキスト設計」：MCPがコンテキストを圧迫する仕組みと対策
