Claude Code MCP連携でできることと設定時の注意点

Claude Code MCP連携は、Claude Codeから外部ツールや社内データを扱うための仕組みです。GitHub、課題管理、ドキュメント、データベース、監視ツールなどをつなげると、調査から実装までの流れを短くできます。 対象読者は、Claude Codeを使い始めたエンジニア、テックリード、開発組織の研修担当者です。基本的なCLI操作はできるものの、MCP連携をどこまで業務に入れてよいか迷っている方を想定しています。

ただし、MCPは「便利な拡張機能」とだけ考えると危険です。接続先の権限が広すぎると、AIが読める情報や操作できる範囲も広がります。個人の設定では問題にならないことでも、チーム利用では情報漏えい、誤操作、監査不足につながります。

MCPの設定方法やtransportの扱いは変わる可能性があります。導入判断では、2026年9月11日時点のAnthropic公式Claude Code MCPドキュメントと、MCP公式Model Context Protocol概要を起点にしてください。導入直前には、接続するMCPサーバーのREADMEも照合します。

Claude Code MCP連携の全体像

結論からいうと、Claude Code MCP連携は「接続先を選ぶ→読み取り専用で試す→設定を共有する→書き込みだけ承認制にする」の順で進めます。接続できるかではなく、Claude Codeに何を許可するかを先に決めるのが全体設計の要点です。

安全な導入判断に必要な確認項目は次の6つです。

• Claude Code MCPとは何かを説明できる
• MCP連携でできることと業務での使いどころを分けられる
• MCPサーバーを追加する前に権限範囲を決められる
• Claude CodeでMCPを設定する基本手順を確認できる
• 設定時につまずきやすい注意点を先回りできる
• チーム導入時に必要な運用ルールを整理できる

Claude Code MCPとは何か

Claude Code MCPとは、Claude Codeから外部ツールやデータソースを扱えるようにする連携の仕組みです。MCPは「Model Context Protocol」の略で、AIアプリケーションと外部システムをつなぐための共通規格です。

MCP公式では、MCPを「AIアプリケーションを外部システムにつなぐオープンな標準」と説明しています。たとえるなら、AIにとってのUSB-C端子のようなものです。接続方法がそろうことで、ツールごとに別々の独自連携を作らずに済みます。

MCPは外部ツール・データソースとAIをつなぐ共通規格

MCPサーバーは、外部ツールとClaude Codeの間に立つ窓口です。Claude CodeはMCPサーバーを通じて、ファイル、データベース、API、業務ツールなどにアクセスします。

たとえば、次のような接続先が考えられます。

接続先	できることの例	注意点
GitHubや課題管理	issueを読み、実装方針を整理する	書き込み権限は慎重に扱う
ドキュメント	仕様書や社内ナレッジを参照する	機密範囲を分ける
データベース	調査用の読み取りを行う	本番DBへ直結しない
監視ツール	エラー傾向を確認する	ログに個人情報がないか確認する
社内API	定型業務を補助する	操作履歴と承認を残す

MCPは連携の形式をそろえる仕組みです。どの情報に触れてよいか、どの操作を許可するかは、利用者側が設計する必要があります。

Claude CodeでMCP連携が役立つ場面

Claude CodeでMCP連携が役立つのは、人間が別ツールから情報をコピーして貼り付けている場面です。たとえば、issueの内容を読み、関連するコードを調べ、実装し、確認観点を整理する流れがあります。

公式ドキュメントでも、issue tracker、monitoring dashboard、database、Figma、Gmail draftなどの例が示されています。つまりMCPは、チャットに情報を手作業で貼る代わりに、Claude Codeが必要な情報を直接参照できるようにする仕組みです。

開発チームでは、次のような用途が現実的です。

• issueやチケットの内容から実装範囲を整理する
• 仕様書や設計メモを参照してコードを読む
• 監視ログやエラー情報から調査の当たりをつける
• 社内APIの仕様を見ながらテスト観点を作る

研修現場でつまずきやすいのは、「つながったから使える」と判断してしまうことです。同じissue連携でも、読むだけなら安全に試せますが、チケット更新や通知まで許可すると関係者へ影響が出ます。当協会では、MCP連携を「読む」「下書きする」「送る」の3操作に分けます。受講者は操作ごとに影響先を確認できるため、サーバー単位で一括許可する判断を避けやすくなりました。

2026年9月11日の公開前検証では、macOS上のClaude Code 2.1.268でclaude mcp --helpを実行しました。表示された管理サブコマンドは10個で、追加、一覧、個別確認、認証、削除などが分かれています。MCPを一つの機能として扱わず、設定変更と状態確認を別作業にする根拠として、この実測結果を研修手順へ反映しています。

通常のプロンプト入力や手作業連携との違い

通常のプロンプト入力では、人間が必要な情報を選び、Claude Codeへ貼り付けます。この方法は安全に見えますが、情報が古い、抜け漏れがある、貼り付け量が多いといった問題があります。

MCP連携では、Claude Codeが接続先から必要な情報を参照できます。うまく使えば、調査のたびに画面を切り替える時間を減らせます。情報の形式もそろいやすく、チームで同じ手順を共有しやすくなります。

接続先に強い権限を与えるほど、誤操作の影響も大きくなります。業務利用では、参照だけの連携と外部を変更する連携を別々に審査します。

Claude Code MCP連携でできること

Claude Code MCP連携でできることは、大きく「読む」「操作する」「外部イベントに反応する」の3段階に分けると理解しやすくなります。最初から全部を許可するのではなく、業務上の必要性に合わせて段階的に広げるのが現実的です。

GitHubや課題管理ツールとつないで実装を進める

GitHubや課題管理ツールと連携すると、Claude Codeはissue、チケット、レビューコメント、関連ドキュメントを参照しながら作業できます。人間が「このチケットの内容を読んで、このリポジトリで対応方針を考えて」と頼む形に近づきます。

この連携で短縮できるのは、情報収集の時間です。担当者はチケット、仕様、コード、レビュー観点を行き来しなくて済みます。チームでよくある「チケットに書いてある前提を読み落とす」問題も減らせます。

ただし、書き込み操作には注意が必要です。コメント投稿、チケット更新、ブランチ操作、外部通知などは業務の記録に残ります。導入初期は、読み取りと提案作成までに絞り、人間が確認してから反映する運用が安全です。

ドキュメントや社内ナレッジを参照する

社内ドキュメントやナレッジベースをMCPで参照できると、Claude Codeは実装時にプロジェクト固有の前提を確認しやすくなります。API仕様、設計方針、コーディング規約、過去の障害メモなどが候補です。

この用途は、MCP連携の中でも始めやすい領域です。多くの場合、まず必要なのは読み取りです。チームの標準ルールや設計思想を参照できるだけでも、出力のばらつきを抑えられます。

ドキュメントには顧客情報、契約情報、未公開ロードマップも含まれます。Claude Code用の閲覧範囲を分け、対象外フォルダは接続元の権限で遮断します。

データベース・監視ツールから調査する

データベースや監視ツールとの連携は、障害調査やデータ確認で効果が出やすい領域です。エラーログ、メトリクス、利用状況を見ながら、Claude Codeが原因候補を整理できます。

ただし、この領域は慎重に扱うべきです。本番データベースに強い権限で接続すると、情報漏えいや誤更新の影響が大きくなります。最初は読み取り専用、マスク済みデータ、検証環境などに限定してください。

個人情報や認証情報がログに残る環境では、AIに読ませる前にログ設計を見直す必要があります。接続前に、公開・社内限定・機密の3区分でデータを分類します。

ブラウザ操作や業務ワークフローを補助する

MCPサーバーによっては、ブラウザ操作や業務ワークフローの補助もできます。たとえば、テスト用の画面確認、社内ツールの情報取得、定型入力の下書き作成などです。

「自動実行」と「人間の確認」は分けて設計します。下書き作成は元に戻せても、送信、削除、公開、決済、顧客連絡は外部へ影響が出るためです。

チームで使う場合、外部送信を伴う操作は原則承認制にします。設定前に、頻度、正確性、影響範囲、代替手段の4軸で接続可否を決めてください。

MCPサーバーを追加する前に決めるべきこと

Claude Code MCPの設定は、コマンドを入れるだけなら難しくありません。難しいのは、何をつなぎ、どの権限で、誰の責任で使うかです。設定前の設計が甘いと、後から権限を絞るのが大変になります。

接続先は本当にClaude Codeから扱うべきか

最初に確認するのは、接続先の必要性です。便利そうだからつなぐのではなく、業務上の課題があるかを見ます。

判断しやすい問いは次の4つです。

判断軸	確認すること
頻度	その情報を何度も参照するか
正確性	手作業コピーで抜け漏れが起きているか
影響範囲	誤操作したときの被害はどこまで広がるか
代替手段	MCPでなくても安全に解決できるか

たまにしか使わない情報なら、手作業で十分な場合もあります。反対に、毎日参照する仕様書やチケット情報なら、MCP連携の効果が出やすくなります。

read-onlyから始めるか、write権限まで許可するか

MCP連携の権限は、読み取りから始めるのが基本です。読み取りだけでも、Claude Codeは情報整理、原因調査、実装方針の提案、レビュー観点の作成に使えます。

書き込み権限を許可するのは、運用ルールが固まってからで十分です。たとえば、issue更新、コメント投稿、社内APIの実行、外部通知などは、誰が確認するかを決めてから許可します。

権限設計では、次の順番が安全です。

1. 公開情報または検証用データの読み取り
2. 社内限定情報の読み取り
3. 下書き作成や提案作成
4. 承認付きの書き込み
5. 限定された自動実行

この順番を飛ばすと、利用者の理解よりも権限の方が先に広がります。便利さより、戻せる範囲で始めることを優先してください。

社内レビューでよく起きる失敗は、read-only検証のつもりで始めたMCPサーバーに、実は書き込み系のツールも含まれているケースです。利用者は「自分は読むだけのつもり」でも、Claude Code側からは更新操作が候補に見えることがあります。導入前のレビューでは、サーバー単位ではなく、公開されるツール単位で棚卸しするのが現実的です。

個人設定か、プロジェクト共有か、チーム標準か

Claude CodeのMCP設定は、スコープによって反映対象が変わります。公式ドキュメントでは、ローカル、プロジェクト、ユーザーの設定スコープが扱われています。

実務では、次のように分けると安全です。

スコープ	向いている用途	注意点
local	個人の試験導入	チーム標準にしない
project	プロジェクトで共有する連携	秘密情報を含めない
user	個人が複数プロジェクトで使う連携	権限が広がりすぎないようにする
チーム標準	研修・運用ルールで統一する連携	承認者と棚卸しが必要

プロジェクト共有に使う.mcp.jsonは便利ですが、認証情報を直接入れてはいけません。共有するのは接続設定の型までにし、APIキーやトークンは環境変数やシークレット管理で扱います。

APIキーや認証情報をどこで管理するか

APIキーや認証情報は、MCP連携で最も事故につながりやすい部分です。共有リポジトリに直接書かないことを前提にしてください。

基本方針は次の通りです。

• APIキーは環境変数やシークレット管理に置く
• .mcp.jsonに秘密情報を直接書かない
• 個人トークンとチーム共用トークンを分ける
• 権限は必要最小限にする
• 退職、異動、プロジェクト終了時に棚卸しする

認証情報の扱いを決めずにMCPサーバーを増やすと、誰の権限で動いているのか追えなくなります。接続先、権限、スコープ、秘密情報の保管場所が決まったら設定に進みます。

Claude CodeでMCPを設定する基本手順

Claude Code MCPは、次の6手順で設定します。HTTPかstdioかを選び、スコープと認証方法を決めてから追加し、一覧・個別表示・実際の読み取りの3段階で確認します。

手順	操作	完了条件
1	接続先の公式READMEでHTTPまたはstdioを選ぶ	推奨transportと必要権限が分かる
2	local、project、userからスコープを選ぶ	誰に設定が反映されるか説明できる
3	APIキーの保管場所を決める	共有ファイルに秘密情報がない
4	claude mcp addでサーバーを追加する	コマンドがエラーなく完了する
5	claude mcp listとclaude mcp get <name>で確認する	type、URL、状態が想定どおりになる
6	Claude Code内の/mcpから読み取りを1件試す	期待した情報だけを取得できる

HTTPリモートサーバーの追加

公式ドキュメントでは、リモートMCPサーバーに接続する場合、HTTPサーバーが推奨されています。クラウドサービスや外部APIのように、ネットワーク越しに接続するサーバーではHTTPを選ぶのが基本です。

コマンド例は次の形です。実行前に、必ず接続先サービスの公式手順を確認してください。

{`claude mcp add --transport http  `}

認証ヘッダーが必要な場合は、公式例では--headerを使う形が示されています。ただし、トークンをそのまま履歴に残す運用は避けたい場面があります。チーム導入では、シェル履歴、端末ログ、共有資料に秘密情報が残らない方法を検討してください。

ローカルstdioサーバーの追加

ローカルで動くMCPサーバーは、stdio transportを使うことがあります。stdioは、ローカルプロセスと標準入出力でやり取りする方式です。ファイルシステムや社内向けスクリプトなど、手元の環境に近い連携で使われます。

公式ドキュメントでは、stdioサーバーを追加するときに、Claude側のオプションとサーバー側のコマンドを--で分ける例が示されています。

{`claude mcp add --transport stdio myserver -- npx server`}

この形では、--以降がMCPサーバーを起動するコマンドとして扱われます。Node.js、Python、パッケージマネージャーなどのランタイムが必要な場合は、利用者のOS差分も確認してください。

.mcp.jsonでプロジェクト共有する場合

チームで同じMCP設定を使う場合、プロジェクト単位の.mcp.jsonを使う選択肢があります。これは、プロジェクトに必要なMCPサーバー設定を共有しやすくするための方法です。

ただし、共有設定に秘密情報を含めるのは避けてください。共有してよいのは、サーバー名、transport種別、URL、起動コマンドの型などです。APIキーやトークンは、環境変数や各自の安全な管理場所から渡します。

公式ドキュメントでは、JSON設定でurlがあるのにtypeがない場合は設定エラーになると説明されています。Claude CodeのCLIでHTTP接続を追加するときは--transport httpを使います。.mcp.jsonのtypeにはhttpを指定でき、streamable-httpもhttpの別名として受理されます。

claude mcp listとセッション内確認で疎通確認する

設定後は、接続できているかを確認します。公式ドキュメントでは、設定済みサーバーの一覧確認にclaude mcp list、個別確認にclaude mcp get <name>が示されています。Claude Codeセッション内では/mcpで状態を確認できます。

確認では、次の項目を見ます。

• サーバー名が表示されるか
• pending approvalやrejectedになっていないか
• URLやtypeが正しいか
• 認証ヘッダーや環境変数が渡っているか
• 期待したツールだけが使える状態か

SSE transportは公式ドキュメントでdeprecatedと説明されています。既存のSSEサーバーがある場合も、新規導入ではHTTPを優先できるか確認してください。接続できないときは、スコープ、JSON形式、ランタイム、認証の順に切り分けます。

Claude Code 2.1.268で実機確認した設定仕様

2026年9月11日にmacOS上のClaude Code 2.1.268で、認証情報の入力や外部サーバーの追加を伴わない範囲を実機確認しました。--helpの表示と公式ドキュメントを照合した結果、設定時はtransportとscopeを省略せず、追加後は一覧・個別表示・実際の読み取りを分けて確認する必要があります。

確認項目	実行したコマンド	観測結果	当協会の運用への反映
バージョン	claude --version	2.1.268 (Claude Code)	検証記録にバージョンと日付を残す
管理機能	claude mcp --help	add、get、list、login、logout、removeなど10個のサブコマンドを表示	設定変更と状態確認を別工程にする
transport	claude mcp add --help	stdio、sse、httpの3種類。省略時はstdio	READMEにtransportを明記する
scope	claude mcp add --help	local、user、projectの3種類。省略時はlocal	共有対象を決めてからscopeを指定する
初回承認	claude mcp --help	未承認の.mcp.jsonサーバーはPending approvalとなり接続されない	初回承認を導入手順の完了条件に含める
状態確認	claude mcp --help	listとgetは承認済みサーバーをヘルスチェックする	追加コマンドの終了だけで成功判定しない
秘密情報	claude mcp add --help	--client-secretは対話入力でき、環境変数も選べる	値をコマンド引数や共有資料へ残さない

help表示にはSSEも選択肢として残っていますが、Anthropic公式ドキュメントではdeprecatedです。そこで当協会の手順書は、「CLIで選べること」と「新規導入で推奨されること」を分け、リモート接続の新規設定ではHTTPを優先する記載にしました。

また、既定値のstdioとlocalは個人検証には便利ですが、チーム導入では意図と異なる設定を作る原因になります。当協会のレビュー票では、コマンド実行前に「接続先」「transport」「scope」「公開されるツール」「認証情報の保管先」「停止方法」の6項目を埋め、空欄があれば追加作業へ進みません。

追加後の確認も1回では終えません。claude mcp listで登録状況、claude mcp get <name>で個別設定、Claude Code内の/mcpでセッション状態を確認し、最後に許可した読み取りを1件だけ実行します。この4段階に分けると、「登録されたが未承認」「承認済みだが接続失敗」「接続したが期待したツールがない」を切り分けられます。

今回の実機確認はCLIの管理機能と選択肢が対象で、個別MCPサーバーの接続性や権限までは保証しません。実導入時は接続先の公式README、検証環境での疎通、公開ツール一覧のレビューを追加し、その結果をサーバー単位で記録します。

設定時につまずきやすい注意点

Claude Code MCPのトラブルは、MCPそのものの難しさよりも、設定スコープ、JSON形式、ランタイム、認証情報の扱いで起きやすいです。エラーが出たら、やみくもに設定を増やす前に、次の観点を順番に確認してください。

スコープの違いで設定が反映されない

よくあるのは、設定したつもりのMCPサーバーが別スコープに入っているケースです。個人のlocal設定で試していたものを、チームメンバーが使えると思い込むと、別の環境では表示されません。

確認するポイントは3つです。

1. どのディレクトリで設定したか
2. local、project、userのどこに入っているか
3. そのワークスペースがClaude Codeから信頼済みか

プロジェクト共有のMCPサーバーは、承認待ちになることがあります。公式ドキュメントでも、.mcp.jsonにあるサーバーがpending approvalとして表示される場合があると説明されています。チーム標準にするなら、初回承認の手順もREADMEに書いておくと混乱を減らせます。

JSON形式やtype指定のミスでサーバーが読み込まれない

.mcp.jsonを手で編集すると、JSON形式のミスが起きやすくなります。カンマの抜け、引用符の不足、配列とオブジェクトの取り違えは基本的な確認点です。

Claude Code MCPではtype指定が接続方式を決めます。公式ドキュメントでは、urlがあるのにtypeがない設定はエラーになると説明されています。HTTPのつもりでURLだけ書くと、別の種類のサーバーとして解釈される可能性があります。

最低限、次を確認してください。

• JSONとして正しいか
• typeが接続方式と合っているか
• HTTPならurlが正しいか
• stdioならcommandとargsが正しいか
• コピーした設定がClaude Code向けの形式か

外部記事の設定例をそのまま貼らず、公式ドキュメントと接続先サーバーのREADMEでtype、URL、引数を照合します。

ランタイムやOS差分でサーバー起動に失敗する

ローカルstdioサーバーでは、Node.js、Python、パッケージマネージャー、OSの差分が影響します。自分のMacでは動くのに、WindowsやLinuxでは動かない、ということも珍しくありません。

チーム運用では、次の情報をREADMEに残しておくと再現性が上がります。

• 対応OS
• 必要なランタイムのバージョン
• 初回インストール手順
• 環境変数の名前
• 失敗時の確認コマンド

MCPサーバーは、Claude Codeの中だけで完結する機能ではありません。外部プロセスや外部サービスを使うため、通常の開発環境整備と同じくらい丁寧に扱う必要があります。

認証ヘッダー・環境変数の扱いを誤る

認証情報の扱いを誤ると、設定ミスではなくセキュリティ事故になります。トークンをチャット、共有ドキュメント、Git管理下のファイルに貼る運用は避けてください。

特に注意したいのは、次のパターンです。

• APIキーを.mcp.jsonに直接書く
• サンプル用トークンを本番権限で使う
• 個人トークンをチーム標準設定に混ぜる
• 退職者や異動者のトークンが残る
• シェル履歴に認証ヘッダーが残る

MCP連携では、接続先の権限をClaude Codeから利用できます。接続成功だけで終えず、必要最小限の権限に絞り、管理者がいつでも無効化できる状態を保ちます。

チーム導入で必ず決めたい運用ルール

個人で動いた設定を、そのままチーム標準にはできません。接続先、権限、承認、監査を共通ルールに落とし込みます。

接続してよいMCPサーバーのホワイトリスト

まず、接続してよいMCPサーバーを決めます。すべてのMCPサーバーを自由に追加できる状態にすると、誰がどの外部サービスへ接続しているのか追えません。

ホワイトリストには、次の情報を含めます。

項目	記録する内容
サーバー名	チーム内で使う名称
接続先	サービス名、URL、用途
権限	read-onlyか、writeありか
管理者	誰が設定と棚卸しを担当するか
承認日	いつ、誰が許可したか
更新頻度	どのタイミングで見直すか

新しいMCPサーバーを追加したい場合は、申請、確認、試験導入、本採用の流れを用意します。便利そうなサーバーを個人判断で増やさないことが、チーム運用の第一歩です。

書き込み系ツールの承認フロー

書き込み系ツールは、読み取り系とは別に扱います。コメント投稿、チケット更新、データ更新、外部送信、ブラウザ操作による確定処理などは、人間の確認を前提にしてください。

承認フローでは、次のように段階を分けると運用しやすくなります。

1. Claude Codeが案を作る
2. 担当者が内容を確認する
3. 必要に応じてレビュー担当者が確認する
4. 人間が最終操作する、または限定条件で許可する

小さなチームでは、この流れが面倒に見えるかもしれません。しかし、書き込み権限は外部への影響を生みます。後から「誰がこの操作をしたのか」を追える状態にしておくことが、導入継続の条件になります。

プロンプトインジェクション対策

MCPサーバーが外部コンテンツを取得する場合、プロンプトインジェクションのリスクがあります。これは、外部ページや文書に「AIの指示を上書きするような文言」が混ざり、AIがそれを通常の情報ではなく命令として扱ってしまう問題です。

公式ドキュメントでも、信頼できるサーバーだけを接続すること、外部コンテンツを取得するサーバーではプロンプトインジェクションに注意することが示されています。

チームでは、次の対策を入れます。

• 外部Webを読むMCPサーバーは用途を限定する
• 書き込み権限と外部コンテンツ取得を安易に組み合わせない
• 重要操作の前に人間レビューを入れる
• 取得元URLや実行結果をログに残す
• 不審な指示文を見つけたら作業を止める

プロンプトインジェクションは、個人の注意だけで防ぐのが難しい領域です。だからこそ、権限と承認フローで被害範囲を小さくします。

ログ・監査・権限棚卸し

MCP連携は、導入したら終わりではありません。使われなくなったサーバー、退職者のトークン、検証用に残った権限は、時間が経つほど見えにくくなります。

少なくとも四半期に1回は、次を棚卸ししてください。

• 現在使っているMCPサーバー一覧
• 接続先サービスと権限
• 管理者と利用者
• 認証情報の有効期限
• 書き込み操作の履歴
• 不要になった設定の削除状況

当協会のClaude Code研修でも、MCPは「接続できるか」より「どの権限で止めるか」を重視して扱います。演習では、認証不足、書き込み要求、不審な外部指示など5種類の失敗パターンを用意し、利用者が止める判断を練習します。成功操作だけを反復する研修では、実案件で異常に気づきにくいためです。

おすすめの導入ステップ

Claude Code MCPは、最初から全社標準にしない方がうまくいきます。個人検証、小規模チーム、標準化の順に進めると、効果とリスクを確認しながら広げられます。

まず1つのread-only連携で検証する

最初の検証では、1つのMCPサーバーだけを選びます。候補は、読み取り専用で業務効果が見えやすいものが向いています。たとえば、仕様書、課題管理、検証用データ、監視ログの読み取りです。

検証で見るのは、技術的に接続できるかだけではありません。次の点も確認します。

• 手作業コピーが減ったか
• 誤った前提で作業する回数が減ったか
• 利用者が設定手順で迷わないか
• 権限が広すぎないか
• チームで再現できるか

1つの連携で手応えが出てから、2つ目以降を検討します。最初からMCPサーバー一覧を作る必要はありません。

チーム標準の.mcp.jsonとREADMEを整える

小規模チームで使う段階では、設定と手順を標準化します。.mcp.jsonを使う場合は、秘密情報を含めず、必要な環境変数や初回承認手順をREADMEに書きます。

READMEには、少なくとも次を含めます。

• 何のためのMCPサーバーか
• どの権限で使うか
• 初回設定の流れ
• 環境変数の名前
• 接続確認の方法
• 使ってはいけない操作
• 問題が起きたときの連絡先

標準化の目的は、設定を配ることではありません。誰が設定しても、同じリスク理解で使える状態にすることです。

当協会の研修では、READMEに「なぜこのMCPサーバーを許可しているのか」を1行で書く形式をすすめています。理由が書けない連携は、便利そうに見えても標準化の根拠が弱いからです。たとえば「issueの読み取りで実装範囲の確認漏れを減らす」のように、業務効果と権限範囲をセットで残すと、後から棚卸ししやすくなります。

実案件で使う前に演習・レビューを行う

MCP連携は、実案件へ入れる前に演習で試すべきです。検証用のissue、サンプルコード、ダミーデータを用意し、読み取り、提案、レビュー、承認の流れを練習します。

演習では、成功パターンだけでなく失敗パターンも扱います。

• 権限が足りずに読めない場合
• 認証情報が渡っていない場合
• type指定が間違っている場合
• 外部コンテンツに不審な指示文がある場合
• 書き込み操作を求められた場合

研修では「止める練習」に時間を割きます。Claude Codeが外部ツールを使おうとしたとき、利用者が何を見て許可し、どの条件なら止めるかを声に出して確認します。判断理由を説明できれば、実案件でも同じ基準を再現できます。

実案件で初めて失敗すると、利用者は慌てます。事前に失敗を体験しておくことで、止める判断がしやすくなります。

成功した連携だけを標準化する

最後に、検証で効果が出た連携だけを標準化します。導入効果が曖昧なMCPサーバーは、無理に残さない方が安全です。

標準化する基準は、次のように決めます。

基準	判断例
効果	調査時間や手戻りが減った
安全性	read-onlyまたは承認付きで運用できる
再現性	複数メンバーが同じ手順で使える
保守性	管理者、更新手順、棚卸し方法がある

MCP連携は、増やすほどよいものではありません。チームで使い続けられる連携を選ぶことが、長期的な成果につながります。

Claude Code MCP連携でよくある質問

初心者は検証用データのread-only接続から始め、新規のリモート接続ではHTTPを優先します。共有する.mcp.jsonにAPIキーを直書きせず、効果と管理負担を確認できた接続だけを残します。

Claude Code MCPは初心者でも使えますか？

基本的なCLI操作に慣れていれば試せます。実機確認ではclaude mcp addにtransportとscopeの既定値があり、指定を省いても設定できる一方、本人が意図しない範囲へ登録する余地がありました。そのため、初回は検証用データ、read-only、1サーバーに限定し、レビュー担当者がtransport・scope・公開ツールを確認してから業務データへ広げます。

SSE transportは使わない方がよいですか？

公式ドキュメントではSSE transportはdeprecatedと説明されています。既存環境で必要な場合を除き、新規導入ではHTTPサーバーを優先して検討するのが自然です。すでにSSEで動いている連携がある場合も、移行可否と接続先の公式案内を確認してください。

.mcp.jsonにAPIキーを書いてもよいですか？

共有リポジトリに置く.mcp.jsonへAPIキーやトークンを直接書かないでください。Anthropic公式の環境変数展開では機密値を${VAR}で参照でき、実機のclaude mcp add --helpでも--client-secretの対話入力を確認できました。チームで共有するのは設定の型までにし、値は環境変数やシークレット管理から渡します。

MCPサーバーは多いほど便利ですか？

多ければ便利とは限りません。当協会の運用票では、1サーバーごとに導入前の6項目と定期棚卸しの6項目が増えます。接続数ではなく、手作業削減、権限の妥当性、複数人での再現性を採用基準にし、基準を満たさない接続は削除します。

まとめ：MCP連携は設定より運用設計が重要

Claude Code MCP連携は、外部ツールやデータソースをClaude Codeから扱えるようにする強力な仕組みです。GitHub、課題管理、ドキュメント、データベース、監視ツールとつなげることで、調査から実装までの流れを短くできます。

一方で、価値は接続数では決まりません。接続先、権限、スコープ、認証情報、承認フローを決めずに導入すると、便利さよりもリスクが先に広がります。

まずは、1つのread-only連携から始めてください。効果を確認し、.mcp.jsonとREADMEを整え、演習で失敗パターンを確認し、成功した連携だけを標準化する。この順番なら、Claude Code MCPをチームの実務に無理なく組み込めます。

設定コマンドを覚えるだけでは、MCP連携は定着しません。安全に使える接続を選び、人間の確認が必要な場面を残すこと。それが、Claude Code MCPを業務で使うためのいちばん現実的な進め方です。