自分でMCPサーバーを作る:Claudeを社内ツールに安全につなぐ(権限とデバッグ込み)

30秒サマリー

「MCPサーバーを構築する際の鉄則：外部からのリクエストを信頼しない門番として設計すること。権限はサーバーコードに書く。『Claudeにデータを削除しないでください』はリクエストであって、制限ではない。」

なぜ自分でサーバーを書く必要があるのか

多くの一般的なサービス（クラウドストレージ、プロジェクト管理、メッセージング）はすでに公式またはコミュニティのMCPサーバーが存在し、自分で書かなくても接続できる。自作が必要になるのは、既製オプションのない社内専用システム——自社のデータベース、内部API、プライベートツール——に接続する場合だ。

原則：標準化された外部サービスには既製品を優先する。速く、実績もある。既存のオプションがニーズに合わない場合のみ自作する価値がある。

メカニズム：トランスポートの選択

stdioとSSE/HTTPの違い

シンプルな判断基準：サーバーがClaudeと同じマシン上で動く場合（ローカルデスクトップアプリなど）はstdioを使う。サーバーが別の場所にあってネットワーク経由で接続する場合（クラウドにデプロイしてチームで共有するなど）はSSE/HTTPを使う。

判断の軸は「誰がどこから使うか」だ。個人のローカル開発とテストならstdioが最もシンプルで、ネットワークや認証の問題がない。チーム全体に提供したり、リモートのClaudeからアクセスさせたりするにはHTTPが必要で、その場合は認証も忘れずに。一度オンラインになると、アクセスできる人なら誰でもサーバーを呼び出せるため、権限と本人確認がより重要になる。

権限管理：サーバーに書く、プロンプトに書かない

読み取り専用は最初の層であって、十分ではない。さらに考慮すべき点：

1. データスコープ：読み取り専用であっても、クエリ可能な範囲を限定する。データベース全体を開放するのではなく、特定の部門のデータのみなど。
2. 入力バリデーション：Claudeが持ってくるパラメータが正しいと仮定しない。外部入力と同様にチェックとフィルタリングを行う。
3. 監査ログ：誰がいつどのツールを呼び出し何をクエリしたかを記録する。問題が発生したときに調査できるようにするため。

これらの層を重ねる核心的な考え方は同じだ：サーバーはリクエストが間違っているかもしれない、あるいは悪意があるかもしれないと前提にする。デフォルトで信頼しない。

MCPサーバーがチェーンの中でどこに位置するか

Chainは：Claude → あなたのMCPサーバー → 社内システム、そして同じ経路で戻る。ClaudeはデータベースにはアクセスせずClaudeに「query_customerツールをこのパラメータで使って」と伝えるだけだ。サーバーはそれを受け取り、まずリクエストを許可すべきか検証し、通過すれば社内システムをクエリし、Claudeが読める形式にフォーマットして返す。

この設計の利点：機密情報（データベースパスワード、APIキー）はサーバー内にのみ存在し、Claudeには渡されない。 ClaudeはあなたがDefineしたツールを通じてのみアクセスし、基盤レイヤーには直接届かない。

サーバーの3つの基本部品

1. ツール定義：どんなツールが存在し、各ツールがどんなパラメータを取り、何を返すかをClaudeに伝える。Claudeに開くメニューであり、メニューにないものは注文できない。
2. 実行ロジック：Claudeがツールを選んだとき、実際にデータベースをクエリしたりAPIを呼び出したりするコード。
3. トランスポート：ローカルならstdio、リモートならSSE/HTTP。Claudeがサーバーとどうやってやりとりするかを決定する。

ツール説明の書き方

ツール説明はサーバーが使いやすいかどうかを左右する隠れた鍵で、よく過小評価される。Claudeはツール説明を頼りに「いつ使うか、どんなパラメータを渡すか」を判断する。曖昧に書けば推測し、推測が外れれば「おかしなパラメータで呼ばれた」問題が発生する。

良いツール説明の3つのポイント：

1. ツールの目的と適した状況を明確に述べる——Claudeがいつ選ぶかわかるように。
2. 各パラメータに注釈をつける——何のためか、どんな形式か、必須か任意か。
3. パラメータに制約（日付フォーマット、値の範囲）があれば説明に直接書く。

実用的な原則：社内システムを見ることができない人向けに書くAPIドキュメントとしてツール説明を扱う。読者はあなたの言葉からのみツールを理解できる——明確に書けば書くほど、Claudeは正確に使う。

デバッグ：問題が起きたとき

よくある3つのMCPデバッグ問題：

1. 「Claudeがツールを認識できない」：通常、ツール定義が正しく登録されていないか、トランスポートが接続されていないことが原因。
2. 「ツールは呼ばれるが、おかしなパラメータで来る」：通常、ツール説明が不明確でClaudeが推測したことが原因。
3. 「Claudeが返ってきた内容を誤読する」：通常、戻り値フォーマットが乱雑なことが原因。

実際には、まずサーバー側ですべてのリクエストとレスポンスをログに記録する。10件中9件の問題はログを読むだけで特定できる。

まとめ

• MCPサーバー = ClaudeとあなたのツールをつなぐTranslatorと門番。機密情報はサーバーにのみ存在し、Claudeには渡されない
• チェーン：Claude → サーバー（権限チェック）→ 社内システム、そして戻る
• 3つの基本部品：ツール定義（メニュー）、実行ロジック（実際のクエリ）、トランスポート（stdioまたはHTTP）
• 権限はサーバーコードに書く。「Claudeにお願いする」ではリクエストにすぎず制限ではない
• デバッグはまずログを読む：認識できない・おかしなパラメータ・誤読——10件中9件はリクエスト/レスポンスのログで特定できる