Claude Code用に独自MCPサーバーを作る前に考えること

Claude Codeで「社内システムとつなぎたい」「独自のAPIを叩かせたい」と思ったとき、すぐに独自MCPサーバーの実装に入るのは早計です。本記事は、コードを書き始める前に「そもそも自作すべきか」を判断するための観点を整理します。

結論：独自MCPは「他の手段で足りないとき」の最後の選択肢

MCP（Model Context Protocol）は、Claudeに外部ツールの「ツール・リソース・プロンプト」という拡張点を与える標準仕様です。仕組みの基礎は「Claude CodeとMCPサーバーの基本」にまとめています。

独自MCPサーバーは強力ですが、作ると保守対象が1つ増えます。書き始める前に、次の順で「作らずに済む道」を潰します。

1. 既存のMCPサーバーで足りないか：公式・サードパーティに同等品がないか
2. CLIツールで足りないか：Bashから叩けるCLIなら、MCPより軽い
3. スクリプト＋@参照で足りないか：単発の処理なら自作MCPは過剰
4. どれも当てはまらない：このときだけ独自MCPを検討する

公式ドキュメントのMCPも、まず既存サーバーの利用を前提に書かれています。自作は「標準化された接続を、繰り返し・複数人で使う」ときに初めて見合います。

「作らない」で済む3つの代替

独自MCPを検討する前に、次の3つで足りないかを必ず確認します。

特に見落とされやすいのがCLIです。MCPサーバーは接続するとツール定義がコンテキストに常駐し、サブエージェントにも継承されてコンテキストを圧迫します。一方、CLIは必要なときだけBashで呼ぶため軽量です。この差は「Claude Codeに必要な情報だけ渡すコンテキスト設計」で扱った「CLIはMCPより軽い」という原則そのものです。

用途別に既存サーバーがないかは「Claude Codeで使いたいMCPサーバー候補と選び方」を先に確認してください。

独自MCPが見合うケース・見合わないケース

代替を潰したうえで、自作が見合うかを判断します。

見合うケース

• 社内専用のシステムで、公開された既存MCPサーバーが存在しない
• 同じ接続を複数人・複数プロジェクトで繰り返し使う
• CLIでは表現しにくい「リソース」や「プロンプト」を提供したい
• アクセス制御やデータ整形を、接続層で一元管理したい

見合わないケース

• 自分1人が、数回だけ使う
• 既存のCLIやAPIをラップするだけ（それならCLIを直接使う）
• 「とりあえず便利そうだから」という動機しかない
• 保守する人が決まっていない

判断の軸は「繰り返し使うか」「複数人で使うか」「標準化された接続点が要るか」です。1つもイエスがなければ、自作は割に合いません。

設計前に決めておく5項目

自作すると決めたら、コードの前に設計を固めます。最低限、次の5つを書き出します。

1. 公開するツールの粒度：1ツール1責務。「何でもやる」巨大ツールを作らない
2. 入力と出力のスキーマ：引数と返り値の型を明確に。曖昧だとClaudeが誤用する
3. トランスポート：ローカル限定ならstdio、リモート共有なら推奨されるStreamable HTTP
4. 認証：APIキーやトークンの渡し方。環境変数展開を使い、直書きしない
5. スコープ：個人用はlocal、チーム共有は.mcp.jsonのproject

ツールの数を増やしすぎると、それだけコンテキストを消費します。「本当に必要なツールだけ」を最初に絞るのが、設計段階で最も重要な判断です。

認証とセキュリティの注意点

独自MCPサーバーは、外部システムへの認証情報を扱うことが多く、セキュリティ設計を後回しにできません。

• APIキーは環境変数展開で渡す：.mcp.jsonに${VAR}で書き、キー本体はコミットしない
• 最小権限のトークンを使う：読み取りで足りるなら書き込み権限を持たせない
• 取得コンテンツ由来のプロンプトインジェクションに備える：MCPが外部から取ってきた文字列を、そのまま指示として扱わせない
• bypassPermissionsを常用しない：MCPツールの実行も承認の対象に保つ

秘密情報の具体的な扱いは「Claude Codeに秘密情報を渡さないための実践ルール」、MCP全体のセキュリティ観点は「Claude Codeを使うときのセキュリティチェックリスト」に詳しくあります。自作MCPは「自分が書いたコードが認証情報を扱う」ため、既存サーバーを使う以上に注意が必要です。

動作確認の進め方

実装したら、Claude Codeに組み込む前に単体で動くかを確認します。MCPサーバーを登録するコマンドは次の形です（オプションはサーバー名の前、起動コマンドは--の後）。

登録後、認識されているかは一覧で確認します。

接続できないときは、トランスポートの指定、起動コマンドのパス、環境変数の渡し漏れを順に疑います。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がコンテキストを圧迫する仕組みと対策