Claude Code MCPを検索しても、設定コマンドや便利なMCPサーバーの断片的な情報ばかりで、「自分のWindowsやVSCode環境で、どこにmcp.jsonを置き、どのスコープで何を動かすべきか」という核心は整理されていません。結果として、Claude mcp addでGitHubやPlaywright、Context7、Serenaなどを次々追加し、削除や確認方法があいまいなまま、誰も構成を説明できない状態になりがちです。
本記事では、Claude Code MCPとは何かを短時間で整理したうえで、mcpjsonやmanaged設定ファイルの具体的な配置パターン、local・project・userスコープの実務的な使い分け、Claude Code MCP serverの定番構成と使わない方がよい場面まで一気通貫で示します。さらに、追加と削除の運用ルール、MCPが出てこない時の確認手順、開発・営業・SEO・ナレッジ管理それぞれの業務フローへの組み込み方、チーム導入時の権限設計と社内ルールまで踏み込んで解説します。Claude Code MCPの「便利さ」と「危うさ」を同時に抑えたい方にとって、このガイドを読まずに手探りで進めることは、時間と信用の両方を失うリスクになります。
目次
Claude Code MCPとは何かを3分で整理する──AIとツール連携の「共通基盤」の正体
頭の中のアイデアを「PCごと動くチームメイト」に変える。その土台になっているのがClaude Code MCPです。コード補完用のAIを超えて、GitHubやPlaywright、SerenaやContext7といった外部サーバーを、安全にまとめて扱うための共通レイヤーが用意されたと思ってください。
ポイントは、VSCodeやWindows上の1つの設定で、複数のMCPサーバーを管理し、プロジェクト単位やユーザー単位の権限ルールをはっきり切り分けられることです。便利さとリスク管理を同時に設計できるため、「とりあえず全部つなぐ」カオス状態から抜け出せます。
Claude Code MCPの基本概念と役割
MCPは、AIと外部ツールの間の共通プロトコルと設定フォーマット（json）です。サーバー側は「AIから呼び出せるツールのカタログ」を公開し、クライアント側（Claude Code）はそれを読み取って実行します。
現場で押さえたい役割は次の3つです。
-
ツール連携を統一するインターフェース
-
スコープごとに権限とリスクをコントロールする仕組み
-
追加や削除をmcpコマンドや設定ファイルで一元管理する仕組み
特に、managed設定とmcp jsonを組み合わせることで、「このPC全体で必ず使うもの」「このプロジェクトだけで有効にするもの」をきれいに分けられます。
スキルやインテグレーションとの違いとMCPプロトコルの位置づけ
既存のSkillsや各種インテグレーションとの違いを整理すると、設計の迷いが一気になくなります。
| 項目 | Skills | 個別インテグレーション | MCP |
|---|---|---|---|
| 主な役割 | モデル内の汎用機能 | サービスごとの専用連携 | ツール連携の共通基盤 |
| 拡張性 | 制限あり | サービス依存 | サーバーを自前追加可能 |
| 管理単位 | モデル設定 | サービスごと | json設定とmcpコマンド |
| 権限設計 | 粗め | サービス任せ | スコープとプロンプトで細かく制御 |
私の視点で言いますと、Skillsは「AIの標準装備」、インテグレーションは「個別メーカー純正オプション」、MCPは「後から何でも積める共通ハブ」のイメージです。だからこそ、GitHubやbookmark、web検索サーバーを混在させても、設定とルールが1枚の設計図で説明できる状態を作りやすくなります。
Claude Code MCPが開発や業務フローに効いてくる具体的シーン
単に「便利な連携」ではなく、業務フローそのものを書き換える場面で真価が出ます。代表的なシーンを整理すると、どこから導入すべきか判断しやすくなります。
-
開発プロジェクト
- GitHub MCPでPRの差分とissueをAIに読ませ、テストログをPlaywright MCPで確認
- ログファイルをfilesystem経由で参照し、原因調査をセッション単位で完結
-
SEO・コンテンツ制作
- Context7やSerenaの検索結果をAIが要約し、自社サイトやPDF資料と突き合わせて方針を生成
- bookmark系MCPで「よく見る競合ページ一覧」を常にコンテキストに載せたうえで原稿作成
-
営業・リサーチ
- web検索系MCPとスプレッドシート連携で、リード企業の情報を自動取得し、提案資料のたたきを生成
- Zapier連携MCPからCRMのデータを取得し、商談メモやフォロー案をAIに下書きさせる
-
情報システム・AI推進
- userスコープでは軽いツールのみ、projectスコープではSerenaやContext7などトークン消費の大きいサーバーを限定
- managed設定で「社として許可するMCPサーバー一覧」と「禁止するホストパターン」を明文化して配布
こうした構成を最初から意識しておくと、MCPサーバーを増やしても「誰も全体像を説明できない状態」になりません。設定ファイルとルールをセットで設計することが、沼にハマらない近道になります。
まずはここから始めるClaude Code MCP設定の全体像とファイル構成が丸わかり
「とりあえず動く」状態から、「どの設定がどの権限で動いているか説明できる」状態に変わると、Claude Code MCPは一気に“仕事道具”になります。ここでは、現場で迷いがちな設定ファイルとスコープ、WindowsやVSCodeでの配置の勘所を一気に整理します。
Claude Code MCP設定ファイル（mcpjsonやmanaged設定）の種類と保存場所のギモンを解消
Claude Code MCPの設定は、大きく次の2レイヤーで押さえると混乱しません。
-
CLI側の設定
- 代表例: mcp.json、managed設定
- 役割: どのMCPサーバーをどの引数で起動するか、サーバー一覧の“台帳”
-
エディタ側の設定
- 代表例: VSCodeのsettingsによる有効・無効切り替え
- 役割: どのワークスペースでどのMCPを参照するかという“スイッチ”
CLI側の設定イメージは、次のようなjson構成を頭に入れておくと整理しやすくなります。
-
サーバーID（例: github、playwright、context7）
-
実行コマンド（node、npx、pythonなど）
-
arguments（ホストやポート、APIキーの参照など）
-
env（環境変数でAPIキーを渡す場合）
managed設定は、マーケットプレイス相当のエントリを元に、公式の定義をそのまま利用する仕組みです。jsonを自分で書くケースは、社内向けツールやカスタムサーバーを定義するときに限定し、それ以外はmanagedを優先しておくと構成ミスが一気に減ります。私の視点で言いますと、managedを“デフォルトの安全ライン”、mcp.jsonを“攻めのカスタム領域”と区別しておくと運用判断がスムーズになります。
スコープ（localとprojectとuser）ごとに押さえるべき権限と運用パターン
スコープは「誰の意思で、どこまで影響させるか」を決めるレバーです。ここを曖昧にすると、気づかないうちにチーム全体の権限が膨らみます。
下の比較表をベースに、どこに何を置くかを決めてください。
| スコープ | 保存場所のイメージ | 主な用途 | リスクと注意点 |
|---|---|---|---|
| local | 一時ディレクトリや試験用フォルダ直下 | 試行錯誤、検証中のMCPサーバー | 消えてもよい設定だけ。APIキー直書きは厳禁 |
| project | プロジェクトルート配下 | チームで共有するGitリポジトリ単位の構成 | 権限とルールをドキュメント化し、レビュー対象にする |
| user | ユーザープロファイル配下 | 個人の標準ツールセット | つい何でも追加しがちなので定期棚卸しが必要 |
運用パターンとしては、次の3ステップが安定します。
- localで追加 → CLIで挙動とトークン消費を検証
- 問題なければ projectに昇格 → Gitで設定ファイルを管理
- いつでも使いたい基盤系（GitHub連携など）は userに定着
特にweb検索系やSerena、Context7のような情報取得系サーバーは、projectスコープに閉じて「この案件ではこの範囲まで検索してよい」と明示しておいた方が、判断プロセスの透明性が保てます。
WindowsやVSCode環境でClaude Code MCPの設定場所を迷わないための実践テク
WindowsとVSCodeの組み合わせでは、「どの設定が今効いているのか」が見えづらくなりがちです。迷子にならないためのポイントは、場所を覚えるのではなく探索の手順をテンプレ化することです。
おすすめの確認フローは次の通りです。
- VSCodeのワークスペースを確認
- まず、開いているフォルダが「どのプロジェクト単位か」を意識する
- プロジェクトルートに設定ファイルがあるかチェック
- Git管理対象の設定（projectスコープ）が存在するかを確認
- ユーザー設定の優先度を把握
- VSCodeのsettingsとCLIのuserスコープが、project設定を上書きしていないかを見る
- ターミナルからCLIの有効サーバー一覧を確認
- Claude CodeのCLIでmcp一覧を確認し、「VSCodeで見えているMCP」と差分がないかを比較
特にWindows環境では、ユーザープロファイル直下とアプリのデータディレクトリが分散しやすく、「昨日まで動いていたのに今日は消えた」という現象が起こります。対策としては次の2点を徹底すると安定します。
-
設定ファイルのパスを必ずドキュメント化し、プロジェクトREADMEに明記する
-
VSCodeのワークスペース設定とCLIのスコープを1回ホワイトボードに書き出して、チームで合意を取る
このひと手間を挟むだけで、「あのMCPサーバー、誰が、どこで、有効にしたんだっけ？」という典型的な混乱パターンをかなり防げます。開発チームもマーケチームも、まずは設定の地図を共有してからMCPサーバーを追加していくのが、後戻りしない近道です。
失敗しないClaude Code MCPの追加や削除をマスター──コマンド・JSON・リアル運用の裏側
「とりあえずmcp addしてみたら、何がどこで動いているか誰も説明できない」
多くの現場で聞く悲鳴です。ここでは、追加と削除を安全に回しながら、後から振り返っても迷子にならない運用をまとめます。
Claude mcp addやremoveで賢く追加や削除を実践するためのリアルルール
CLIのaddとremoveは便利ですが、ルールなしで使うと権限カオスになります。現場で安定しているチームは、次の3点を徹底しています。
1. 追加前に決めること
-
どのスコープで入れるか
-
何の業務フローで使うか
-
誰が設定変更の責任者か
| 判断軸 | userスコープ | projectスコープ | localスコープ |
|---|---|---|---|
| 用途 | 個人実験 | チーム共有 | 検証用・一時利用 |
| 向くケース | 新MCPの試用 | プロジェクト標準構成 | トラブル切り分け |
| リスク | 設定の属人化 | 影響範囲が広い | 消し忘れ多発 |
addでserenaやcontext7など重めの検索系MCPを追加するときは、最初はuserスコープで試す→projectに昇格させるか判断という二段階が安全です。
2. removeの運用ルール
-
削除前に「誰のどのタスクで使われているか」を確認
-
削除したら、必ず設定ファイルとドキュメントの両方を更新
-
「1人でもまだ使っている人がいるかもしれないMCP」はlocalで無効化テストをしてから全体削除
私の視点で言いますと、GitHubやPlaywright系のMCPは、CI設定変更のタイミングと合わせてremoveするくらい慎重でもやりすぎではありません。
mcpjsonを直接編集したいときの構成ヒントや陥りがちな構文ミス集
CLIに慣れていても、最終的にはjsonを直接触る場面が出てきます。そこで事故を防ぐポイントを押さえておきます。
最低限押さえる構成のイメージ
-
servers配列
-
各serverのname、command、args、allowedHostsなど
-
managed系設定が上書きしていないかどうか
よくある構文ミスと対策をまとめます。
| ミスの種類 | 症状 | 予防策 |
|---|---|---|
| カンマの付け忘れ | 設定全体が読めない | 追記時は「上の行にカンマ」が基本 |
| true/falseを文字列にする | 意図しない挙動 | ブール値は小文字かつ裸で書く |
| URLのtypo | サーバーに接続できない | https部分はコピペ運用にする |
| スコープ混在 | どこで有効か不明 | userとprojectでキーを統一 |
特にmanaged設定が有効な環境では、手書きjsonよりも「どこから上書きされているか」を先に確認する習慣が効きます。VSCodeなら検索でmcp関連のsettingsを洗い出し、どのレイヤーで有効かを整理してから編集するのが安全です。
Claude Code MCPを確認するコマンドや「MCPが出てこない」時のトラブル解決法
「追加したはずのMCPが一覧に出てこない」「Playwrightのツールだけ見えない」といった問い合わせは、実はパターンが決まっています。トラブル時は、次のチェックリストを順番に見ると早く抜けられます。
1. コマンドで状態を確認する視点
-
有効なMCPサーバー一覧を確認
-
スコープごとの差分を把握
-
対象プロジェクトディレクトリで実行しているかを確認
2. MCPが出てこないときのチェックリスト
-
現在のプロジェクトパスが想定と合っているか
-
userスコープとprojectスコープで同名サーバーが二重定義されていないか
-
jsonにコメントを書き込んでいないか
-
Windows環境でパスに全角文字やスペースが含まれていないか
-
VSCodeを再起動してセッションキャッシュをクリアしたか
特にWindowsとVSCodeの組み合わせでは、パスの違いと設定ファイルの場所違いが原因で「入れたのに見えない」状態が起きやすくなります。addの直後に、必ず「どのスコープに、どのパスで、どのjsonが保存されたか」をメモしておくと、数週間後のトラブル対応スピードが段違いになります。
最終的に目指したいのは、MCPを増やすたびに環境が重くなる状態ではなく、「業務フローごとに最小限のサーバーだけが綺麗に並んだ構成」です。追加と削除、コマンドとjson編集、この3点を一貫したルールで回せるかどうかが、その分かれ目になります。
これだけ知っていればOK！定番Claude Code MCPサーバ一覧と業務別ベスト構成
「どのサーバを入れるか決めきれず、気付いたらごちゃごちゃ」になりがちな方は、ここで一度フラットに整理してみてください。最小構成で始めて、業務ごとに“必要な一手だけ足す”発想がポイントです。
開発者に人気のClaude Code MCP（GitHubやPlaywrightやFirebaseなど）の用途と気を付けたい点
開発向けサーバは、リポジトリ操作やテスト自動化で威力を発揮します。
主な用途と注意点をまとめると次の通りです。
| サーバ | 主な用途 | 気を付けたいポイント |
|---|---|---|
| GitHub | PRレビュー、diff確認、issue整理 | 誤操作でのpush権限は極力外す。read専用トークンを基本にする |
| Playwright | E2Eテスト生成、画面キャプチャ自動取得 | テスト実行の頻度を制御しないとCIと二重実行になりやすい |
| Firebase | FirestoreやAuthの参照・検証 | 本番と検証プロジェクトのキーを必ず分離する |
開発用途では、projectスコープに絞った設定にしておくと、個人の試験的サーバがチーム全体に混ざる事故を防ぎやすくなります。
情報検索・リサーチ系Claude Code MCP（Context7やSerenaやweb検索系）の活用タイミングやトークン節約のコツ
リサーチ系は「ゼロから調査を任せる」より、「方針が決まった後の掘り下げ」に向いています。
-
Context7
- ニュースやブログの横断検索に強く、技術動向や競合調査に使いやすい
-
Serena
- 複数ソースからの要約が得意で、市場調査や営業リストの一次整理に便利
-
一般的なweb検索系
- ロングテールキーワードのSEOリサーチや口コミ収集に向く
トークン節約のコツは、先に人間が検索クエリの粒度を決めることです。
-
「対象地域」「期間」「業種」をプロンプトで必ず指定
-
1回のセッションで“問いを3つまで”と決めておく
-
重要ページのURLは人間が絞り込み、MCPには要約と比較だけを任せる
こうすると、無駄なスクレイピングや長文要約を減らし、コストと時間の両方を抑えられます。
コンテンツ制作やSEO業務で重宝するClaude Code MCP（bookmark系やNotionやスプレッドシート連携など）の実践例
コンテンツ周りでは、「一次情報をどう集めるか」と「どこで保管するか」をサーバ構成に落とし込むと安定します。
| 業務 | ベスト構成例 | ポイント |
|---|---|---|
| SEO記事制作 | bookmark系 + web検索系 + スプレッドシート | 参考URLをbookmarkで固定し、根拠リンクを常に残す |
| 営業資料作成 | Notion + スプレッドシート | 成約事例やFAQをNotionに集約し、提案テンプレを自動生成 |
| ローカルSEO | web検索系 + スプレッドシート | クチコミや競合店舗情報を表形式で整理し、改善案を生成 |
bookmark系サーバは、「この記事は根拠として再利用したい」と思った瞬間に保存できるので、情報ソースのインデックス作成ツールとして扱うと威力が出ます。
Claude Code MCPpluginの公式と非公式を見抜くポイント
pluginやサーバを増やし過ぎて制御不能になるパターンは、現場で何度も見かけます。私の視点で言いますと、最初に次の3点だけはチェックリスト化しておくと安全です。
-
公開元ドメイン
- GitHubやnpmなど、運営元が明確か
-
権限範囲
- ファイルシステムや外部APIへのwrite権限を本当に必要としているか
-
更新頻度
- 最終更新日が古すぎないか、issueが放置されていないか
公式か非公式かだけで判断せず、「どのデータにアクセスできるのか」「最悪何が起きるか」まで想像してから導入することが重要です。チーム利用では、userスコープでの個人インストールを禁止し、project単位でレビューしてから追加する運用にすると、事故の芽をかなり減らせます。
Claude Code MCPが「便利すぎて油断できない」──業務フローやセキュリティで気をつけるべき落とし穴
便利さの裏側で、気づかないうちに社内ルールとセキュリティを壊しているケースが増えています。特に開発リーダーやマーケ責任者が、自分のPC上で試した設定をそのままチームに広げると、後から「誰も全体像を説明できない環境」になりやすいです。
私の視点で言いますと、技術的な設定よりも先に「スコープ設計」と「権限プロンプトの読み合わせ」をやっているチームほど、事故率が一気に下がります。
スコープ設定ミスでよくあるトラブル例と今すぐできる防止策
スコープを曖昧にしたまま運用すると、次のようなトラブルが起きやすくなります。
| パターン | ありがちな設定ミス | 表に出る症状 | 今すぐできる対策 |
|---|---|---|---|
| user汚染 | 個人PCにあらゆるMCPを追加 | プロジェクトごとに動作が変わる | userは「最低限の共通基盤」に限定 |
| project肥大化 | 1つのリポジトリに全部盛り | 設定ファイルが誰も触れない状態 | プロジェクトごとに用途を分割 |
| local放置 | 検証用localを削除し忘れ | 意図しないツールが呼ばれる | 検証用ディレクトリを定期的に棚卸し |
防止の考え方はシンプルです。
-
userスコープは「会社として許可したサーバー」のみ
-
projectスコープは「その案件に必要なサーバー」に絞る
-
localスコープは「検証用」で、期限を決めて削除する
特にWindowsやVSCodeで複数プロジェクトを行き来している場合、settingsやmcp jsonの保存場所を1枚の図にまとめ、チームで共有しておくと迷子になりにくくなります。
web検索系Claude Code MCPや自動実行系Claude Code MCPを導入するときの社内ルールの決め方
web検索系やPlaywrightなどの自動実行系は、うまく使えばリサーチやテストが一気に進みますが、同時に「勝手に情報を取りに行くロボット」を社内に入れるのと同じです。最低限、次のルールを決めてから導入した方が安全です。
-
使用目的を明文化する
- 例: SEOキーワード調査、競合のUI確認、営業リストの一次スクリーニングまで、など
-
触れてよいサイト・触れてはいけないサイトの範囲
- ログイン必須サービス、社内システム、取引先の管理画面は原則アクセス禁止
-
実行トリガーの制限
- 「人の明示的な指示があった時だけ実行」
- 定期実行タスクは別途レビューを通す
web検索系MCPサーバを多用するマーケチームでは、「AIが持ち帰ったURLやPDFは、必ず人間が1クリックで中身を確認する」というワンクッションルールを置くことで、誤情報の拡散や誤送信をかなり抑えられます。
権限プロンプトや機密情報の管理をあなどると起こるリアルなリスク
権限プロンプトは、実質的に「AIに渡す鍵束」です。ここを雑に書くと、次のようなリスクが現場で起きます。
-
機密リポジトリや社内Shareフォルダへのアクセスが、誰の意図か分からないまま広がる
-
営業リストや顧客データを含むスプレッドシートを、誤って外部MCPサーバに送信してしまう
-
権限の範囲があいまいなまま、別プロジェクトに設定がコピーされてしまう
避けるためのポイントは3つです。
-
権限プロンプトに「アクセスしてよいデータの種類」と「絶対に触ってはいけないデータの種類」を明記する
-
GitHubやスプレッドシート系のMCPは、権限の弱いサービスアカウントを用意し、個人アカウントと分離する
-
チームで年1回ではなく、四半期ごとに「どのMCPサーバが、どのスコープで、どの権限を持っているか」を棚卸しする
特にSEOや営業リサーチでContext7やSerenaのような検索系サーバを使う場合、調査対象のドメインやキーワードがそのまま社外に出る前提で設計しておくと、情報管理の線引きが格段にクリアになります。
実務シナリオで使えるClaude Code MCP構成テンプレート（開発・営業・SEO・ナレッジ管理）
「どのMCPサーバーを、どのスコープで、どう組み合わせるか」で生産性は2倍にも半減にもなります。ここでは、現場でそのまま流用できる構成テンプレートだけを厳選して整理します。
開発チーム必見！テスト自動化やログ検証をClaude Code MCPで回す構成例
開発用途では、projectスコープを「テスト専用サンドボックス」にする設計が安定します。典型構成は次の通りです。
| 役割 | 推奨MCPサーバー | スコープ | 主な用途 |
|---|---|---|---|
| リポジトリ操作 | GitHub MCP | project | PRレビュー、差分解析 |
| E2Eテスト | Playwright MCP | project | テスト実行、自動スクリーンショット取得 |
| ログ解析 | filesystem MCP | local | ログファイル読み取りと要約 |
| インフラ | AWS関連MCP | project | デプロイ設定の確認、パラメータチェック |
ポイントは、テスト実行と本番反映を分離するルールです。
-
GitHub MCPは「reviewラベルが付いたPRのみ参照可」とプロンプトで明示
-
Playwright MCPは「実行はstaging環境URLのみ」とhostPatternで制限
-
filesystem MCPはlogsディレクトリ以下だけをpath設定で許可
私の視点で言いますと、テスト系MCPをuserスコープに置いてしまい、個人PCのホームディレクトリ全体が参照可能になったケースが最もヒヤッとしました。テスト用こそprojectスコープ固定が安全です。
営業リサーチや商談準備をAI助手化するClaude Code MCPの絶妙な組み合わせ
営業では、「1案件1スレッド×共通MCP構成」で再現性を高めます。おすすめは次の3点セットです。
-
Context7やSerenaのようなweb検索・リサーチ系MCP
-
bookmark系MCPで競合サイトや自社LPを常に参照可能にする構成
-
スプレッドシート系MCPで見積り・提案テンプレと連携
実務フローの例です。
- リード企業名からContext7を使って公開情報を収集
- bookmarkMCPで自社の事例集やPDF資料を読み込ませ要約
- スプレッドシートMCPに提案骨子を自動生成し、営業が手で微修正
ここでのコツはトークン消費の上限と利用時間帯をルール化することです。「午前中のリサーチだけMCPを許可」「商談中はログを残すためにweb検索呼び出しを止める」といった運用を決めておくと、暴走や情報漏えいを防ぎつつ精度を上げられます。
SEO調査・コンテンツ制作の強い味方！Claude Code MCPで作る業務ワークフロー
SEOやコンテンツ制作は、MCPを「調査」「構成」「制作後チェック」の3フェーズに分けると一気に回しやすくなります。
-
調査
- web検索系MCPで上位ページ構成や見出しを一覧取得
- GitHub MCPで過去のコンテンツ生成スクリプトやテンプレートを参照
-
構成
- bookmark系MCPで自社のナレッジ記事や成功LPを参照
- Notionや社内Wiki系MCPでトンマナやNGワード集を常に表示
-
制作後チェック
- PDFやHTML読込MCPでドラフトを解析し、重複表現や抜け漏れをリストアップ
- スプレッドシートMCPにタイトル案やディスクリプション案を自動生成し、編集部で比較
ここで重要なのは、AI任せにしないチェック観点リストを事前に持つことです。
-
ファクトの出典は明示されているか
-
既存記事とのキーワードカニバリは起こしていないか
-
営業・サポート現場の「よくある質問」と整合しているか
このリストをprojectスコープのドキュメントMCPで常時参照させると、品質のブレが大きく減ります。
社内ナレッジ管理・FAQ対応にClaude Code MCPサーバを活かすルールの作り方
ナレッジ用途では、「何をMCPに載せないか」を最初に決めることが肝心です。全部をAIに食べさせる発想は、セキュリティ的にも運用的にも破綻しやすくなります。
おすすめは次の3層構造です。
-
公開前提のマニュアル・FAQ
- Notionや社内WikiMCPで全文検索を可能に
- 更新履歴をGitHub MCPで管理し、改訂差分だけをAIに読ませる
-
部門限定の業務手順
- team専用projectスコープでのみMCPを有効化
- 権限プロンプトで「この内容は社外共有禁止」と毎回明文化
-
絶対にAIに渡さないデータ
- 給与情報、個人情報、未発表の価格表などはファイルシステム側で物理的に分離
- AIとのやり取りに出して良い情報を一覧にした「ホワイトリスト表」を作成
| 層 | AIに読み込ませるか | 代表データ | 推奨スコープ |
|---|---|---|---|
| 公開前提 | はい | FAQ、マニュアル | project |
| 部門限定 | 条件付き | 手順書、トラブル対応ログ | project / team |
| 禁止 | いいえ | 個人情報、機密契約 | 物理分離 |
FAQ自動回答用のMCPを組む際は、「回答の前に必ず根拠URLを返す」ポリシーをプロンプトで固定すると、回答品質の検証がしやすくなり、誤回答の放置を防止できます。営業・開発・サポートのどのチームでも、まずはこのルール設計から着手するのがおすすめです。
「最初は順調だったのに…」Claude Code MCP導入現場でリアルにありがちな失敗パターン
最初は「すごい、仕事が一気に楽になりそうだ」と盛り上がるのに、3カ月後には「誰も全体を説明できないカオス環境」になっているケースをよく見かけます。ここでは現場で本当に起きているパターンだけを取り上げます。
Claude Code MCPサーバを増やしすぎて破綻！その理由と再設計のコツ
便利そうなMCPサーバをマーケットから片っ端から追加していくと、次のような状態に陥ります。
-
どのプロジェクトがどのサーバを前提にしているか誰も把握していない
-
context7やSerena、Playwright、GitHub連携が重なり、トークン消費が急増
-
不要な外部API権限を抱えたまま放置
再設計するときは、「棚卸し」と「役割分担」を同時に行うのが近道です。
| 見直し観点 | 今の状態を確認する質問 | 取るべきアクション |
|---|---|---|
| 機能の重複 | 同じ検索やスクレイピングをするサーバが複数ないか | 1つに統合し、推奨サーバを明示 |
| 権限 | GitHubやFirebaseなど書き込み権限をどこまで与えているか | 読み取り専用と更新系を分離 |
| スコープ | userとprojectどちらで定義しているか | チーム利用はproject設定に集約 |
私の視点で言いますと、再設計フェーズでは「何を追加するか」より「何をやめるか」を先に決めたチームほど、その後の運用が安定しています。
個人のuserスコープ設定がプロジェクト全体に影響した驚きの事例
MCPのスコープ設計を甘く見ると、user設定が静かに事故の種になります。よくある流れは次の通りです。
- 個人がWindowsのユーザーディレクトリにある設定ファイルに独自MCPを追加
- その環境で作ったサンプルコードやプロンプトをチームに共有
- 他メンバーの環境では同じMCPサーバが存在せず、再現できない
- 「同じ手順でやっているはずなのに結果が違う」と混乱
ポイントは、「プロジェクトで共有したいMCPは必ずprojectスコープに固定する」ことです。userスコープに置くものは、次のような個人用途に限定した方が安全です。
-
個人のリサーチ用web検索MCP
-
試験的に触っている非公式サーバ
-
ローカルfilesystemへのアクセス
| スコープ | 主な用途 | チーム運用での推奨度 |
|---|---|---|
| user | 個人の試験・一時的な検証 | 低い(共有しない前提) |
| project | チームで共有するMCP構成 | 最も高い |
| local | 一時的な検証やPoC | 中程度(用途を限定) |
「環境を揃える」という当たり前の話を、MCPのスコープ単位で設計し直すことが、再現性の高いAIワークフローの土台になります。
AI任せにした結果、コンテンツ品質が低下したチームが見落とした大切な視点
SEO記事や営業資料の作成をMCPとAIに寄せすぎた結果、短期的には量産できるものの、次のような症状が表面化するケースがあります。
-
context7やSerenaで拾った情報を、そのまま生成文に流し込んでいる
-
bookmark系やスプレッドシート連携から取得したデータを検証せずに掲載
-
チーム内で「人間がチェックする観点」が定義されていない
ここで欠けているのは、ツールではなく「編集者としての視点」です。具体的には、次の3点を明文化しておくとブレーキが利きます。
-
リサーチ系MCPで取得したデータは、必ず一次ソースURLを確認する
-
重要な指標や数値は、最低1回は人間が別ルートでクロスチェックする
-
AIが生成したドラフトに対して、「削る」「言い換える」権限を人間側が明確に持つ
| フロー | MCPの役割 | 人間の役割 |
|---|---|---|
| 情報収集 | web検索やContext7で候補を集める | 信頼できるソースかどうかを判定 |
| 叩き台作成 | AIが構成案やドラフトを生成 | トーンや事実関係を精査 |
| 最終化 | スタイル統一・フォーマット適用 | 責任者が内容に署名できるか確認 |
AIに「考えること」まで丸投げすると、気づかないうちにブランドや信用を削っていきます。MCPはあくまで調査と実行の加速装置であり、判断の主体は人間のまま維持する前提で設計しておくことが、長期的には最も大きなリスクヘッジになります。
チームでClaude Code MCPをとことん使いこなすための運用チェックリストと現場ルール例
「個人で触っているうちは快適だったのに、チーム導入した瞬間カオスになった」
このパターンを防ぐには、技術力より先にルール設計力が問われます。
Claude Code MCP導入前に押さえたい「スコープ・権限」と「やってはいけないこと」
まず、スコープ設計をあいまいにしたまま始めることが、ほぼ全てのトラブルの源泉です。よく使う3スコープを整理すると次のようになります。
| スコープ | 主な用途 | リスク | 最低限のルール |
|---|---|---|---|
| local | 実験・個人検証 | 誤削除・誰も把握していない設定 | 本番データへのアクセス禁止、期間限定で使用 |
| project | チーム開発・特定案件 | 影響範囲が読めない設定変更 | リポジトリ内の設定レビュー必須、PR経由で変更 |
| user | 個人の恒常的な環境 | プロジェクト方針との衝突 | 業務利用に関わるMCPは極力project側に寄せる |
導入前に、少なくとも次の3点はテキストで決めておくことをおすすめします。
-
調査系MCP(web検索、Context7、Serenaなど)は「projectスコープのみ許可」とし、userスコープでは業務利用しない
-
データベースやGitHub、社内ファイルシステムへのアクセスは「誰の権限で実行されるか」を明文化し、担当ごとに上限を決める
-
mcpを追加できるロール(例:テックリード)と、追加前に確認すべき項目(ホスト先、トークン消費、取り扱うデータ種別)をチェックリスト化する
やってはいけないのは、「便利そうだから」とマーケットプレイスから無差別にサーバーを追加することです。3カ月後に「このMCPは誰が何のために入れたのか」が誰も説明できなくなり、監査もガバナンスも崩れます。
私の視点で言いますと、特にweb検索系とbookmark系をuserスコープに入れっぱなしにした環境は、情報ソースの検証責任がグレーになり、意思決定プロセスの説明が難しくなりがちです。
ログや実行パターンをレビューするための運用フローや担当分担アイデア
チームで使いこなすには、「どのMCPが、どのようなプロンプトから、どの頻度で呼ばれているか」を定期的に振り返る仕組みが欠かせません。
おすすめの最小フローは次の通りです。
-
週1回の「MCP使用レビュー」ミーティングを30分だけ確保
-
ログ(もしくは履歴スクリーンショット)をもとに、呼び出し頻度トップ5のMCPを洗い出す
-
それぞれについて
- そもそも人間がやるべきタスクか
- 権限やスコープは妥当か
- トークン消費と成果が見合っているか
を3点チェック
-
ルール変更や設定修正が必要なものは、その場でissue登録かタスク化
担当分担は、次の組み合わせにすると回りやすくなります。
-
テックリード: 設定ファイル(jsonやmanaged settings)のレビューとマージ判断
-
業務責任者(例:SEOリーダー、営業マネージャー): 「やりすぎ自動化」や情報精度の観点から利用ラインを決める
-
情報システム/セキュリティ担当: 外部サービス連携、アクセス権限、ログ保全のルール策定
特に、Context7やSerenaといった強力な検索・リサーチ系サーバーは、ログレビューのたびに「AIが提案した情報ソースを人間がどの程度検証しているか」を確認しないと、知らないうちに判断を丸投げしてしまう傾向があります。
小さく試して着実に全社展開！Claude Code MCPで進める段階的ロールアウト戦略
いきなり全員にフル機能を開放するより、「検証パイロット → 業務テンプレ化 → 横展開」という3ステップに分けた方が、現場の混乱を最小限に抑えられます。
-
ステップ1: パイロットチームでの検証
- 対象は3〜5人程度の開発チームやSEOチーム
- 使うMCPサーバーを「3種類まで」に絞り、目的を限定(例:GitHubレビュー補助＋PlaywrightでのE2Eテスト補助＋Context7での競合調査)
- 2〜4週間運用し、「どのプロンプトで、どのMCPが最も役に立ったのか」をメモベースで蓄積
-
ステップ2: テンプレ化
- 成功パターンから「プロンプト例」「呼び出して良いMCP一覧」「禁止するユースケース」をテンプレートに落とす
- projectスコープの設定(jsonやmanaged設定)をリポジトリに格納し、PR経由で保守
-
ステップ3: 横展開
- 新しく参加するチームには、テンプレートとチェックリストを配布
- ロールアウト1カ月後に「トークン消費量」「作業時間削減」「品質指標(レビュー指摘数など)」を比較し、不要なMCPは削除
ロールアウト時のチェックリスト例を挙げます。
-
チームごとに「使ってよいMCPサーバー一覧」と「データ接続の有無」を表で明示しているか
-
スコープごとの禁止事項(特にuserスコープ)が文章で共有されているか
-
mcp addやremoveを行う人と、設定をレビューする人が分かれているか
-
ログや履歴をレビューする定例がカレンダーに登録されているか
このあたりを押さえておくと、「なんとなく便利だから使う」状態から、「業務フローとセットで設計されたAI環境」へ、一段上の使いこなしに進めます。
Claude Code MCPをWebマーケやSEO戦略に組み込むには──宇井和朗が強調する設計思考
リード獲得やローカルSEOへClaude Code MCPを活かすアイデア発想法
Web集客で差がつくのは「AIに何をやらせるか」ではなく、「どのタイミングで呼び出すか」です。マーケ施策を分解して、どこにMCPサーバを挿すかを決めると設計が一気にクリアになります。
代表的な流れを整理すると次のようになります。
| フェーズ | 人がやること | MCPに任せると効果的な処理 |
|---|---|---|
| 市場調査 | ターゲットの仮説づくり | Context7やSerenaで競合ページ・口コミの収集 |
| 企画 | 施策の優先順位決定 | 検索ボリュームや傾向の集計・可視化 |
| 実装 | 施策の最終判断 | Playwright連携でLP表示チェックや計測タグ確認 |
| 改善 | 成否の解釈と次の一手 | Search Consoleやスプレッドシートからデータ抽出 |
ポイントは、「意思決定」と「情報集約」を分離することです。例えばローカルSEOなら、店舗周辺の口コミ収集はContext7に任せ、どのキーワードでクチコミを増やすかの判断は人が行う、という切り分けが有効です。
アイデア出しで悩む場合は、次の3つの観点で発想すると設計がブレません。
-
どのデータソースを一元参照したいか（検索結果、口コミ、社内シートなど）
-
どの作業を毎週繰り返していて「手がしびれている」のか
-
どの指標を見ればリード獲得や来店数と直結していると説明できるか
この3つを書き出してから、対応するMCPサーバを選ぶと「とりあえず追加してみる」状態から一気に抜け出せます。
AI任せにしないための「人間側が押さえるべきポイント」と現場ルール設計
AI活用で失速するチームの多くは、人間側の役割定義がないままMCPだけ増やしたケースです。私の視点で言いますと、最低限次の3つのルールを紙に落としてから運用を始めるべきです。
-
検証ルール
- 検索系MCPが出したリストは、上位3件だけは必ず人が原文確認する
- 競合分析結果は、月1回はサンプルを人間が再調査して誤差を把握する
-
権限ルール
- userスコープで扱えるMCPと、projectスコープに限定するMCPを一覧化
- web検索系と自動実行系は「利用申請制」にし、用途をログに残す
-
ログレビュー
- 週1回、代表的なチャットセッションをピックアップして「どの判断を人が行ったか」をチェック
- 想定外の自動実行が増えていないかを確認
AIに任せるのは「集計」と「提案」までで、最終判断と責任の所在は常に人に残す、これを文字で明文化しておくと暴走リスクをかなり抑えられます。
中小企業や店舗ビジネスでClaude Code MCP導入判断をする際の着眼点と費用対効果
中小規模の現場では、「入れるかどうか」よりも「どこから小さく始めるか」を見極めた方が投資効果が出やすいです。判断材料は次の3軸で整理できます。
| 着眼点 | 確認するポイント | 費用対効果の考え方 |
|---|---|---|
| 作業時間 | 週何時間、調査・レポート作業にかかっているか | まずは月10時間削減を目標にする |
| 売上寄与 | リードや来店の起点となるチャネルはどこか | そのチャネルに直結するMCPから導入 |
| 再現性 | 属人化している分析や提案があるか | 手順をMCP経由のワークフローに固定化 |
導入ステップとしては、いきなり全社展開せず、次の順番が安全です。
- マーケ担当1～2名のPCで、projectスコープだけを使った検証環境を作る
- 1～2種類のMCPサーバに絞り、「1レポートあたりの作成時間」と「提案の質」を比較
- 効果が確認できたフローだけを、手順書とテンプレートに落としてチームに展開
費用は「ツール代」よりも人件費の削減と精度向上の両面で回収する設計が鍵です。例えば、これまで手作業で半日かかっていたエリア別キーワード調査がMCP経由で30分になり、かつ抜け漏れが減るなら、その差分はほぼ利益としてストレートに積み上がります。
経営側の視点では、「どのMCPサーバを何の目的で入れているか」を一覧にして説明できるかが勝負どころです。ここまで整理できれば、単なる流行りのAI導入ではなく、自社のマーケ戦略に直結した投資として胸を張って進められます。
この記事を書いた理由
著者 – 宇井 和朗（株式会社アシスト 代表）
本記事は生成AIによる自動生成ではなく、運営責任者として5年以上にわたり現場を率いてきた経験と実務に基づき制作しています。ご安心の上閲覧ください。
Claude Code MCPは、うまく設計できれば開発もSEOも一気に加速しますが、設定範囲や権限を曖昧なまま導入すると、一瞬で現場を混乱させます。実際、当社でもWindowsとVSCode環境でmcpjsonの配置を担当者ごとにばらばらにしてしまい、誰も「どのスコープで何が動いているか」を説明できない状態に陥りました。サーバを増やすほど便利になると信じて追加を繰り返した結果、営業資料と開発用ログが同じスコープで扱われ、アクセス権の整理に多くの時間を失いました。
また、WebマーケやSEOの現場支援をしていると、GitHubやPlaywright、情報検索系のMCPを勢いで入れたものの、削除や確認の手順が共有されておらず、トラブルが起きるたびに個人依存で対応しているケースを繰り返し見てきました。便利さだけを追いかけると、最終的に意思決定のスピードと安全性が落ちるという矛盾が生まれます。
この記事では、そうした遠回りをした経験を踏まえ、どこに何を置き、どのスコープで動かし、どのMCPサーバをあえて使わないかまでを一度で整理できるよう構成しました。設定ファイルの置き場所から、追加削除のルール、チームで運用するためのフローまでを具体的に示すことで、読者の方が自社の環境で迷わずClaude Code MCPを活用できるようにすることが、このガイドを書いた目的です。