Claude CodeでMCPを入れ始めた瞬間から、あなたのチームのコードと社内データは静かにリスクにさらされています。多くの解説は「Claude Code MCP 設定の手順」や「MCP serverの追加方法」「.claude.json／.mcp.jsonの書き方」を丁寧に並べていますが、本当に成果と安全性を分けているのは、local・project・userスコープの設計とJSON構成、そして運用ルールです。ここを外したまま、GitHubやZapier、Serena、playwright、context7、Googleスプレッドシートを次々つなぐと、「とりあえず全部連携」が爆速で技術負債になります。
この記事では、WindowsやVSCode環境での設定ファイルの場所、CLIと拡張機能からのMCP追加・削除、よくあるエラーの潰し方といった実務の「手順」は当然押さえつつ、その上でどのMCPをどのスコープに置くかを、開発、検索、自動化の用途別に具体的な構成例として示します。さらに、中小企業や小さな開発チーム向けに、標準MCPテンプレと権限ルール、テスト設定が本番に流れ込む事故パターンまで分解します。
「Claude Code MCP 使い方」の一般論ではなく、明日からチーム全体の安全と生産性を底上げするための設計図が欲しい方だけ、この先を読み進めてください。
- Claude CodeでMCPを使いこなすと何が変わるのか？まずは全体像から押さえる
- MCP設定のキモはスコープとJSON構成にある localとprojectとuserの違いを一度で腹落ちさせる
- Claude CodeでのMCPサーバー追加と削除の実践ガイド CLIとVSCode拡張の両方をカバー
- 用途別のおすすめMCPサーバー構成 開発や検索や自動化で何を組み合わせるべきか
- 最初は快適なのに後から冷や汗をかくMCP設定の落とし穴と対処法
- 中小企業と小さな開発チームのための標準MCPテンプレ 現場で回る運用ルールの作り方
- エンジニアではないWeb担当やマーケがClaude CodeのMCPを使うならここだけは押さえたい
- Claude CodeとMCPを会社の武器に変えるために 4,000社支援から見えたAIツール運用のリアル
- この記事を書いた理由
Claude CodeでMCPを使いこなすと何が変わるのか？まずは全体像から押さえる
ローカルPCとGitHubと社内SaaS、その全部を1つの窓から安全に操れるかどうかで、チームの生産性はまるで別物になります。設定を「雑」に済ませるか、「設計」して入れるかで、後からの冷や汗の量も決まります。
Claude CodeとMCPの関係を他のAIコーディングツールと比較してみる
多くのAIコーディングツールは、エディタ内の補完やチャットに機能が閉じています。対してClaudeとMCPは、「AIが使える外部ツールを定義ファイルで拡張していく設計」になっている点が決定的に違います。
代表的な違いを整理すると、次のようなイメージになります。
| 観点 | よくあるAI補完ツール | ClaudeとMCPを組み合わせた環境 |
|---|---|---|
| ツール連携 | 用意された固定プラグインのみ | json設定でサーバーを追加・制御 |
| 権限管理 | エディタ単位でざっくり | local / project / userのスコープで細かく管理 |
| 情報源 | ソースコード中心 | GitHub issueやGoogle系サービス、Zapierなどまで拡張 |
| カスタム性 | UI設定が中心 | MCPサーバーを自作・選定して構成可能 |
私の視点で言いますと、「補完ツール」から「開発オペレーションの司令塔」に格上げできるかどうかの分岐点が、このMCP設計にあります。
MCPが担う外部ツールの入口とは
MCPは、Claudeから見た「外部ツールとデータへの正規ルート」です。CLIやVSCode拡張から設定するサーバー情報を、jsonファイルで管理し、そこに以下を定義していきます。
-
どのホストやURLにアクセスしてよいか
-
どのAPIキーやenvを使うか
-
どのツール名をどのプロジェクトで「見せるか・隠すか」
つまり、単なるプラグインのオンオフではなく、「AIにどこまで社内の資産を触らせるかをルール化するレイヤー」がMCPだと捉えると腹落ちしやすくなります。
ここをきちんと設計しておくと、たとえば次のような運用が可能になります。
-
開発プロジェクトではGitHubリポジトリとissue管理だけ許可
-
営業用プロジェクトではGoogleスプレッドシートとCRM系だけ許可
-
機密度の高い案件では、検索系MCPのみで書き込み系は一切禁止
同じAIでも、「入口の定義」が違うだけで、触れる情報の質とリスクがガラッと変わってきます。
とりあえず全部つなぐが危ない理由と最初に決めるべき3つの軸
現場で本当に多いトラブルが、「便利そうなMCPサーバーを片っ端から追加していった結果、誰が何にアクセスできているのか誰も説明できない状態になる」ケースです。VSCodeの拡張やCLIから簡単に追加できる反面、スコープと権限を意識せず積み増ししてしまうのが落とし穴です。
最初に必ず決めておくべき軸は、次の3つです。
-
1. スコープの軸（local / project / user）
個人の検証だけに閉じるのか、Git管理されるプロジェクトに載せるのか、ユーザー全体に常時有効にするのかを明確に切り分けます。テスト中のMCP設定をuserスコープで入れると、気づかないうちに全プロジェクトで本番データを書き換える危険があります。
-
2. データの機密度の軸
GitHubや社内wiki、営業リスト、顧客スプレッドシートなど、アクセス先の「機密レベル」をざっくり3段階程度で分類し、レベルごとに許可するMCPサーバーを決めます。営業リストにZapier経由で書き込み可能にするのか、読み取り専用に留めるのかで、リスクは桁違いです。
-
3. 役割の軸（開発・情報収集・自動化）
Serenaやplaywrightのようなテスト・ブラウザ操作系、context7やArXivのような情報検索系、Zapier連携のような自動化系を混ぜて配置すると、チームメンバーが「どのMCPを何の目的で入れているのか」を見失いがちです。役割ごとにグループ分けし、プロジェクト単位で採用するかを決めます。
この3軸を決めてから、jsonの構成やCLIコマンドでの追加・削除に進むと、後から設定ファイルを読み返したときに「なぜこのサーバーがここにいるのか」が説明しやすくなります。
雑に入れて便利さだけ先取りするか、最初に10分かけて設計して「安全な最強環境」に育てていくかで、数カ月後のトラブル対応コストがまるで違ってきます。
MCP設定のキモはスコープとJSON構成にある localとprojectとuserの違いを一度で腹落ちさせる
「どこに何を書いたか分からないJSON地獄」になった瞬間、AI環境は一気にブラックボックス化します。逆に言えば、スコープと設定ファイルの整理さえできれば、あとから人が見ても怖くない“安全な最強環境”になります。
Claude Codeの. claude. jsonと. mcp. jsonとホームディレクトリの設定ファイル、それぞれの役割
まずは「誰が読む設定なのか」を整理すると迷わなくなります。
| ファイル名 | どこに置くか | 役割 | 典型的な中身 |
|---|---|---|---|
| .claude.json | プロジェクトルート | そのプロジェクトでのAI設定全体 | モデル選択 プロンプトテンプレート MCP参照 |
| .mcp.json | 同じくプロジェクト配下やユーザーディレクトリ | MCPサーバー定義のカタログ | サーバー名 ホスト コマンド APIキー参照 |
| ホームディレクトリ配下の設定ファイル | ユーザープロファイル直下 | 端末ユーザー共通のデフォルト設定 | よく使うMCPやマーケットプレース設定 |
ポイントは.claude.jsonは「このプロジェクトのAIの顔つき」.mcp.jsonは「使える道具箱の一覧」という分け方で捉えることです。
道具箱自体はユーザー共通にも置けますが、どの道具を実際に使わせるかはプロジェクト側で制御した方が安全です。
localとprojectとuserのスコープをどう切り分けるか 業務フローから逆算する考え方
スコープは「誰の判断でどこまで触っていいか」の線引きです。業務フローから逆算して決めると事故が減ります。
| スコープ | 想定する使い方 | 権限レベルの目安 | 入れていいMCPサーバー例 |
|---|---|---|---|
| local | 個人が試す検証用 | もっとも自由 ただし自己責任 | 新しいAPI テスト用Playwright 自作サーバー |
| project | チームで共有するプロジェクト単位 | 中〜高 監査しやすい | GitHub issue管理 context7 検索系 |
| user | 端末ユーザー共通の常備品 | 中 影響範囲が広い | ローカルfilesystem 読み取り専用検索系 |
業務フローから見ると、次の切り分けが実務的です。
-
local
新しい外部サービスやgemini連携など、まだルールが固まっていないものを試す砂場。ログも自分だけが追える前提で割り切ります。
-
project
プロダクト開発やクライアント案件のように、「誰がどの権限で何を触ったか」を追いたい領域。GitHubやissue管理といった業務の“公式チャネル”に触るものはここに限定します。
-
user
どのプロジェクトでも使いたいが、誤操作で本番データを書き換えると痛いものは避けるべきゾーン。読み取り中心の検索ツールやWebドキュメント参照程度に絞ると、後からの棚卸しが楽になります。
私の視点で言いますと、現場では「便利だから」とuserスコープにZapierやスプレッドシート連携を入れた結果、別プロジェクトのテストが本番シートを書き換える、というヒヤリハットが起きがちです。書き込み系はlocalかprojectで明示的に管理することを強くおすすめします。
WindowsやVSCode環境で設定ファイルどこを迷子にしないための確認ステップ
特にWindowsとVSCodeの組み合わせでは、「同じ名前のJSONがどこにあるか」でつまずきやすいです。迷子にならないためのチェックリストを用意します。
-
プロジェクトルートを決める
- VSCodeで「フォルダーを開く」で選んだディレクトリ直下を基準にします。
- ここに置いた .claude.json がそのワークスペースのproject設定として読まれます。
-
設定ファイルの優先順位を理解する
- 同じキーがあった場合
userスコープ < projectスコープ < localスコープ
のように、より狭いスコープがオーバーライドするとイメージしておくと整理しやすくなります。
- 同じキーがあった場合
-
Windowsでのユーザーディレクトリを把握する
- 通常は
C:\Users\ユーザー名がベースです。 - この直下やAppData配下にある設定ファイルは、userスコープとして扱われます。
- Gitで共有したい設定は、ここではなくプロジェクト側のファイルに寄せておきます。
- 通常は
-
VSCode拡張側の設定も確認する
- 拡張機能の設定画面で、どのパスをconfigとして参照しているかを一度チェックします。
- 複数ワークスペースを開いている場合、どのウィンドウがどのproject設定を読んでいるかを意識しておくと混乱を防げます。
-
管理用に「設定の見取り図」を残す
- READMEやdocsディレクトリに、次のような簡易表を残すと、後から参加するメンバーが迷いません。
| 種別 | ファイル | 置き場所 | 管理者 | 備考 |
|---|---|---|---|---|
| project設定 | .claude.json | プロジェクトルート | テックリード | レビュー必須 |
| MCP定義 | .mcp.json | プロジェクト配下config | テックリード | 書き込み系のみ |
| user共通 | ユーザーディレクトリの設定ファイル | Cドライブ配下 | 各ユーザー | 読み取り系のみ |
このレベルまで整理しておくと、「誰がどの設定を変えていいのか」が明確になります。結果として、開発リーダーがMCP標準を握りつつ、チームメンバーは安心してlocalで試せる環境が作れます。
Claude CodeでのMCPサーバー追加と削除の実践ガイド CLIとVSCode拡張の両方をカバー
ローカルで爆速に動くのに、権限だけ地雷原。そんな状態を避けるための「安全な追加と確実な削除」の実務ガイドです。
コマンドラインからの追加と削除とよくあるエラー 構文やパスや権限の潰し方
CLI派のテックリード向けに、押さえるべきポイントを整理します。
代表的な操作は次の3つです。
-
設定ファイルのスコープ確認
-
MCPサーバー定義の追加・編集
-
不要になったサーバーの削除
追加時によくあるつまずきは、実は技術というより「凡ミス」です。
-
構文エラー(json)
カンマの付け忘れや配列の括弧抜けで、全設定が無効になります。編集後は必ず json 構文チェッカーや VSCode のエラー表示で確認してから保存します。
-
pathやホストの誤り
npxやnpmでインストールしたツールは、projectスコープなら相対パス、userスコープなら絶対パスかグローバルインストールを徹底します。Windowsではバックスラッシュ混在に要注意です。
-
権限不足
WindowsでProgram Files配下を実行パスにすると、権限不足で起動できないケースが多発します。ユーザーのホームディレクトリ配下にツールを置く方が安全です。
削除するときは、必ず「一覧 → 無効化 → 削除」の順で進めます。いきなり設定を消すと、「どのプロジェクトがそのMCP前提で動いていたか」が追えなくなり、チーム全体でセッションが壊れる原因になります。
VSCodeのClaude Code拡張機能からMCPを設定する時のチェックポイント
GUIから設定するメンバーが多いチームでは、VSCode拡張のルールを決めておかないと、知らないうちにuserスコープがカオスになります。
VSCodeで見ておくべきポイントは、次の3つです。
-
どのフォルダを開いているか
開いているフォルダ単位でprojectスコープが決まるため、「個人の実験用フォルダ」で接続したMCPが、そのままチームリポジトリに持ち込まれるパターンを防ぐ必要があります。
-
拡張設定での有効スコープ
user設定でMCPを追加すると、全プロジェクトから見えてしまいます。安全に始めるなら、まずはproject設定からだけ許可するポリシーが現場では扱いやすいです。
-
APIキーと環境変数の保存先
VSCodeのsettingsに直書きせず、環境変数や.envに寄せる運用に統一しておくと、GitHubへの誤コミットをかなり防げます。
簡単な比較イメージをまとめます。
| 観点 | CLI操作 | VSCode拡張 |
|---|---|---|
| 再現性 | 高い(設定ファイルをgit管理しやすい) | 低め(個人設定に寄りやすい) |
| 学習コスト | やや高い | 低い |
| チーム運用 | 標準化しやすい | ルールがないと権限がバラける |
私の視点で言いますと、チーム標準はCLIベースで決めておき、VSCode側は「閲覧と個人実験のみOK」という線引きをしておくと、中小規模の開発現場でもトラブルがぐっと減ります。
Serenaやplaywrightやcontext7など個別MCPサーバーを入れる前に確認すべき接続先とスコープ
便利なMCPほど、入れる前のチェックが命綱になります。代表的なサーバーで見るべき観点は共通しています。
-
Serena系(検索・リサーチ系)
接続先の検索エンジンやWebサイト範囲を確認します。営業リサーチに使うなら、ユーザー全体ではなくprojectスコープに閉じて、「この案件の調査でのみ使用」と割り切る方が安全です。
-
playwright系(ブラウザ自動操作)
実ブラウザでログイン・入力・送信まで可能なため、userスコープで解放すると、本番システムへの誤操作リスクが一気に跳ね上がります。テスト環境専用プロジェクトに限定し、APIキーやログイン情報も環境変数で完全に分離してください。
-
context7や学術系検索(ArXivやYouTube連携など)
参照だけならリスクは低めですが、「どこまでのURLを許可するか」を明示しておくと、メンバーが社内の機密資料URLをうっかり登録する事故を防げます。
接続先とスコープ設計をざっくり整理すると、次のイメージになります。
| MCP種類 | 推奨スコープ | 事前確認ポイント |
|---|---|---|
| 検索・リサーチ系(Serena, context7など) | project | どの案件・どの業務で使うか、検索範囲 |
| 自動操作系(playwright) | localまたは専用project | 対象環境(テスト/本番)、認証情報の分離 |
| 参照専用コンテンツ系(ArXiv, YouTube) | projectまたはuser | 参照してよい情報のレベル、業務との紐づけ |
テックリードがここをきちんと設計しておくと、「とりあえず全部つなげた結果、どこから何にアクセスしているか誰も説明できない」という状態を避けられます。結果として、AI活用のスピードとセキュリティの両立が現実的なラインに落ち着きます。
用途別のおすすめMCPサーバー構成 開発や検索や自動化で何を組み合わせるべきか
「どのMCPサーバーを入れるか」で、チームの生産性は3倍にも0.5倍にも振れます。やみくもに追加せず、用途ごとに“型”を決めてしまう方が安全で速い構成になります。
下の表は、現場で回しやすい構成パターンです。
| 用途 | 中心MCPサーバー例 | 推奨スコープ | ポイント |
|---|---|---|---|
| 開発・コードレビュー | GitHub系, issue管理ツール, playwright | project | リポジトリ単位で権限を固定 |
| 技術・市場リサーチ | context7, ArXiv, YouTube検索 | local | 端末内で閉じた安全な検索コンテキスト |
| 営業・レポート自動化 | Zapier, Googleスプレッドシート関連 | project | 本番データへの書き込みを制御 |
GitHubやissue管理ツールを接続してコードレビューとチケット整理を同時に回す構成
開発で一番“効く”のは、コードとタスクを同じセッションで扱える構成です。
-
GitHubリポジトリ参照用MCP
-
issue管理ツール連携 (GitHub IssuesやJira系)
-
playwrightなどE2Eテスト実行用MCP
を組み合わせ、projectスコープの設定ファイルにだけ登録するのが鉄則です。
おすすめの運用は次の流れです。
-
プルリクエストの差分をMCP経由で取得
-
関連issueを同じセッションで読み込み
-
playwrightのテストシナリオ生成と修正案をその場で生成
userスコープにGitHub権限を持たせてしまうと、別プロジェクトのリポジトリまで誤操作で触れるリスクが生まれます。リポジトリURLをprojectごとに固定し、「そのプロジェクト以外は見えない」状態を作ることが、セキュアなコードレビュー環境の最低ラインです。
context7やArXivやYouTubeなど情報検索系MCPでリサーチ専用の安全なコンテキストを作る
リサーチ用途で危ないのは、社内ファイルと外部Web検索を同じセッションで混ぜてしまうことです。検索履歴やプロンプトに機密情報が残った状態でWeb検索に流れると、思わぬ情報漏えいにつながります。
そのため、情報収集専用の「サンドボックス的コンテキスト」を用意します。
-
context7で技術記事やドキュメント検索
-
ArXivで論文ベースの一次情報を取得
-
YouTube検索MCPでチュートリアルやカンファレンス動画を要約
これらをlocalスコープの設定だけに入れ、社内Gitやストレージ連携MCPとは分離します。
ポイントは次の通りです。
-
「リサーチ用セッション」は社内リポジトリにアクセスしない
-
検索クエリに顧客名や具体的な売上数値を含めないルールをチームで共有
-
モデルに渡すコンテキストは、publicな情報だけに限定する
私の視点で言いますと、ここを曖昧にしたチームは、数カ月後に「いつの間にか顧客名入りのプロンプトが外部サービスのログに残っている」という冷や汗パターンに陥りがちです。
ZapierやGoogleスプレッドシート連携で営業リサーチやレポート作成やメール草案を自動化するパターン
営業やマーケ向けに一番インパクトが大きいのが、MCPとZapier連携、それにGoogleスプレッドシート周りの自動化です。ただし、便利さと事故リスクが紙一重なので、構成と権限設計が勝負所になります。
基本の型は次の通りです。
-
Zapier連携MCPで
- CRMやフォームサービスから見込み顧客リストを取得
- メール配信サービスやチャットツールへ送信キューを作成
-
GoogleスプレッドシートMCPで
- 営業リストやレポート用のシートを読み書き
- 週次・月次の集計表を自動生成
ここではprojectスコープで「この案件用スプレッドシートだけ」をホワイトリスト管理するのが必須です。
-
シートIDを設定ファイルに固定する
-
書き込み可能なシート名を制限する
-
本番シートとテストシートでMCP設定ファイルを分ける
という運用にしておくと、「テストプロンプトが本番シートを上書きする」事故をかなり抑えられます。
営業リサーチの自動化パターンとしては、次のようなワークフローが現場で使いやすい構成です。
-
Web検索系MCPで企業情報を取得
-
要約結果をスプレッドシートに行単位で追記
-
Zapier経由で、1件ごとにパーソナライズされたメール草案を下書きフォルダに保存
マーケ担当やWeb担当が触る領域ほど、「どこに書き込むか」「どこまで自動送信を許可するか」をテックリードが最初に決めておくと、安心して任せられる自動化基盤になります。
最初は快適なのに後から冷や汗をかくMCP設定の落とし穴と対処法
MCPの設定は、最初の数日は「なんて便利なんだ」で終わります。怖いのは、その便利さがそのまま事故の再現装置になることです。この章では、現場で実際に起きがちな3パターンに絞って整理します。
userスコープに何でも入れてしまいプロジェクトごとの権限がぐちゃぐちゃになるケース
最も多いのが、userスコープの設定ファイルにMCPサーバーを全部突っ込んでしまうパターンです。VSCodeでもCLIでも動くので「一瞬だけ」助かりますが、数週間後にはどのプロジェクトからどのツールにアクセスできるのか誰も説明できなくなります。
代表的な悪化ルートは次の通りです。
-
営業用のスプレッドシート連携MCPをuserスコープに定義
-
そのPCで開くすべてのリポジトリから、売上データへの読み書きが可能に
-
新人がテスト用リポジトリでプロンプト実験 → 本番シートに上書き保存
簡単な整理の目安を表にまとめます。
| スコープ | 入れてよいMCPサーバー | 原則NGなMCPサーバー |
|---|---|---|
| user | 個人メモ閲覧、ローカル検索程度 | 本番DB、顧客一覧、売上シート |
| project | そのリポジトリ専用のAPI連携 | 他プロジェクトと共有しない機密系 |
| local | 試験運用中、PoC用のMCP | そのまま本番で使う前提のもの |
「迷ったらprojectスコープ」を合言葉にすると、被害範囲を最小にしやすくなります。
テスト用のMCPサーバー設定がそのまま本番に流れ込みデータ改変や大量通知を起こす流れ
次に多いのが、「テスト環境だけのつもり」がそのままgitに乗って本番にも配布されるパターンです。私の視点で言いますと、これはSNS運用でもCRM連携でも、設定ミスの典型的な事故コースです。
よくある流れはこうです。
- 個人PCでlocalスコープにテスト用MCPを設定
- 便利なのでproject配下の設定ファイルにコピペ
- 設定ファイルごとgit push → 他メンバーの環境に展開
- 本番APIキーだけ差し替えて運用開始
- 古いテスト用エンドポイントやhookが残ったまま
- 意図しないタイミングでMCPが一括実行し、大量メール送信やスプレッドシートの一括上書きが発生
特にZapierやplaywright、スプレッドシート連携MCPは、「1回の呼び出しで大量の副作用」が起きます。本番用と検証用でMCPサーバー定義を分けることが重要です。
-
test: エンドポイントURLやAPIキーに「sandbox」「dev」を含める
-
prod: 本番用は別名のサーバーとして定義し、権限レビューを必須にする
この2系統を混ぜないだけで、事故確率は一気に下がります。
事故を未然に防ぐためのシンプルなルール集 スコープやAPIキーや機密データの取り扱い
現場で回るルールは、シンプルでないと続きません。中小企業や小規模チームなら、次の5つだけ決めておくと運用が安定します。
-
userスコープには「読み取り専用」しか入れない
- 書き込み系APIを使うMCPは必ずprojectかlocalに限定する
-
APIキーは環境変数で渡し、設定ファイルに直書きしない
- gitリポジトリにAPIキー付きのjsonが残ると、後で必ず炎上します
-
書き込み系MCPサーバーは、projectごとに一覧表を作る
- 「どのリポジトリから、どの外部サービスに書けるのか」を見える化
-
テスト用と本番用でサーバー名を変える
- 例: sheet-research-dev / sheet-research-prod
- 名前だけで用途が判別できるようにする
-
新しいMCP追加時は「最初はlocalスコープで試す」を徹底する
- 動きを把握してからprojectスコープに昇格させる流れにする
このレベルのルールでも、守り切れば「便利さはそのまま、冷や汗だけ消える」状態に近づきます。MCPはAIの頭脳に外部ツールを直結する仕組みです。だからこそ、最初のスコープ設計と権限ルールが、そのまま会社の安全ラインになります。
中小企業と小さな開発チームのための標準MCPテンプレ 現場で回る運用ルールの作り方
小さなチームほど、AI連携のルールが曖昧だと一晩で「誰も触れないカオス環境」が生まれます。ここでは、明日からそのまま社内標準にできるレベルで、実務寄りのMCPテンプレと運用ルールを整理します。
まずはlocalスコープだけで始める場合の最小構成例とその見直しタイミング
最初からprojectやuserに広げると、jsonファイルが増えすぎて管理できなくなります。最初の一歩はlocalスコープだけで個人検証に絞るのが安全です。
おすすめの最小構成は次の通りです。
-
開発系: filesystem MCP(ローカルコード参照用)
-
情報収集系: Web検索系1種類
-
ユーティリティ: GitHub読み取り専用(トークンも読み取り権限のみ)
この3つを、リポジトリ直下の設定ファイルに記述しておきます。
| 項目 | 方針 | 具体例 |
|---|---|---|
| スコープ | local固定 | .claude.jsonのみ編集 |
| 権限 | 読み取り中心 | filesystemはreadOnly true |
| 見直しタイミング | 1〜2スプリント運用後 | 「手作業でつらい領域」が見えた段階でprojectへ昇格 |
見直しのサインは「同じlocal設定を複数メンバーがコピペし始めた瞬間」です。この状態になったものだけをprojectスコープに格上げしていくと、無秩序な拡大を防げます。
projectスコープに載せるMCPサーバーを開発系や情報収集系や管理系に分けて整理する
projectスコープは「チームの共通道具箱」です。ここが雑に増えると、誰の責任でどのツールが動いているかが一気に不明瞭になります。実務では、カテゴリごとに棚を分ける感覚で整理するのが有効です。
| カテゴリ | 目的 | 代表的なMCP例 | 権限ポリシー |
|---|---|---|---|
| 開発系 | コード編集とレビュー | GitHub連携、issue管理、playwright系 | 書き込み権限はリーダーのみ |
| 情報収集系 | 調査とドキュメント生成 | context7、技術記事検索、YouTube要約 | すべて読み取りのみ |
| 管理系 | 営業・バックオフィス連携 | スプレッドシート、タスク管理、Zapier連携 | 書き込みは別プロジェクトで分離 |
ポイントは「管理系」を開発用リポジトリと分けることです。営業リスト更新やスプレッドシート書き込みなどは、誤操作のインパクトが大きいため、専用プロジェクトを1つ切ってそこでのみ有効にしておくと事故率が大きく下がります。
私の視点で言いますと、gitのブランチ戦略と同じで、projectごとに役割をはっきり切るほど、後から権限を追いかけるコストが激減します。
MCP追加や削除のフローを情シスやテックリードと現場メンバーでどう合意するか
技術的な設定よりも、誰がどうやってMCPを増減させるかのルールがない組織ほどトラブルが起きています。最低限、次の3ステップだけは紙に落としておくことをおすすめします。
-
提案
- メンバーが「用途」「必要なスコープ」「想定リスク」を1枚で整理
- GitHub issueやスプレッドシートでテンプレフォーム化
-
レビュー
- テックリードがjson設定案と権限(トークン範囲、書き込み有無)をチェック
- 情シスが社内ポリシー(個人情報、外部送信)との整合を確認
-
反映と周知
- project設定にマージする担当者を固定
- 変更履歴とMCP一覧をREADMEや社内Wikiに必ず追記
MCP追加・削除フローの簡易テンプレは次のイメージです。
| フェーズ | 担当 | 必須アウトプット |
|---|---|---|
| 提案 | 現場メンバー | 目的・スコープ・利用データの整理 |
| 承認 | テックリード/情シス | 設定json、APIキー範囲のレビュー |
| 実装 | 担当エンジニア | 設定反映、テスト結果の記録 |
| 周知 | プロジェクトオーナー | README更新、利用ガイド共有 |
削除も同じフローを使い、「誰かの個人ワークが止まらないか」「Zapierやスプレッドシート経由で自動実行されていないか」を必ず確認してから止めるようにします。特に中小企業では、一つの自動化に営業やバックオフィスの複数業務がぶら下がっていることが多く、止め方をミスると現場の信頼を一気に失いかねません。
このテンプレをチームで共有しておくだけで、MCPは「一部の詳しい人だけが触る謎機能」から、「誰でも安全に提案できる共通インフラ」に変わっていきます。
エンジニアではないWeb担当やマーケがClaude CodeのMCPを使うならここだけは押さえたい
「コードは書けないけれど、営業リスト作成とSEO記事の下ごしらえは毎日やっている」という方こそ、MCPを味方につけた瞬間に仕事の景色が一気に変わります。
逆に、設定を雑に始めると「勝手に顧客リストにメール送信されていた」「本番シートがぐちゃぐちゃ」になりかねません。
マーケ視点で安全かつ強力に使うための“3つのチェックポイント”を整理します。
営業リサーチやSEOコンテンツ制作に効くMCPサーバーの選び方
マーケ業務でまず押さえたいのは、検索系・要約系・自動化系の3レイヤーです。
| レイヤー | 目的 | 向いているMCP例 | 使い方のイメージ |
|---|---|---|---|
| 検索系 | 情報収集 | context7, ArXiv, YouTube検索系 | 営業リストの業界調査、競合分析のたたき台 |
| 要約系 | インプット整理 | Webページ読み取り用MCP | 長文記事やホワイトペーパーの要約 |
| 自動化系 | 手作業削減 | Zapier連携、スプレッドシート連携 | 毎週のレポート雛形作成、メール草案の下書き |
選び方のコツは次の3つです。
-
自社で絶対触られたくないデータを先に決める
顧客リスト、本番スプレッドシート、会計関連は「最初はつなげない」を原則にします。
-
プロジェクト単位でMCPを分ける
営業リサーチ用とSEOコンテンツ用を同じスコープに混在させないだけで、事故率が下がります。
-
GitHub連携など“履歴が残るもの”から先に試す
変更履歴が追えるツールから入ると、誤操作のリカバリーがしやすく安心です。
Googleスプレッドシートやメールと連動させる時にマーケ側が必ず確認すべき権限と送信先
スプレッドシート連携とメール送信は、マーケ現場で最も“気持ちよく事故る”ポイントです。最低限、次のチェックリストを通してから本番利用に進めてください。
権限チェックリスト
-
スプレッドシートは
- 最初は「閲覧専用」またはテスト用シートに限定
- 本番シートは「列単位」「シート単位」でアクセス範囲を分割
-
メール送信は
- 最初は「自分宛てのみ送信」モードで挙動を確認
- BCCの扱いと送信元アドレスを必ず明文化
よくある危険パターンと対策
| パターン | 何が起きるか | 事前対策 |
|---|---|---|
| 同じシートでテストと本番を実施 | テスト用のダミーデータが本番列を上書き | テスト用スプレッドシートを完全に分離 |
| MCPから直接顧客リストにメール送信 | テンプレート検証前に一斉配信 | 「下書きのみ作成」に固定し、人が最終送信 |
| userスコープで自宅PCと会社PCを共用 | 個人検証の設定がチーム案件に混入 | プロジェクトごとにprojectスコープを必ず定義 |
スプレッドシートやメールの連携は、「書き込み権限」と「送信権限」をいつ付与するかをチームで決めてから設定するのが安全です。
チーム内でAIに任せる領域と人が判断する領域を線引きするための会話例
設定そのものより、マーケとテックリードの“会話の質”で安全性が大きく変わります。私の視点で言いますと、次の3つの会話テンプレートを先に決めておくとトラブルが激減します。
1. 役割分担の会話
-
マーケ担当
「AIには営業リストの候補出しとSEO記事の骨組み作成までを任せたいです。最終の文面確定と送信は自分が責任を持ちます。」
-
テックリード
「では、MCPは検索と要約に限定し、スプレッドシート書き込みとメール送信は最初はオフにします。」
2. スコープ設計の会話
-
マーケ担当
「この案件はA社向けだけのリサーチですよね。ほかのクライアントには絶対混ざってほしくないです。」
-
テックリード
「A社案件専用のprojectスコープを作ります。userスコープには顧客固有のMCPサーバーは入れないルールでいきましょう。」
3. 本番切り替え前の会話
-
マーケ担当
「テストでは問題なさそうでした。来週から自動でレポート生成までやらせたいです。」
-
テックリード
「本番前に、APIキーとスプレッドシートの参照先を一度一緒に確認させてください。想定外のシートにアクセスしていないかをチェックします。」
この3つの会話をテンプレートとして社内ドキュメントに残しておくと、異動してきたメンバーや外部パートナーとも同じ基準で運用しやすくなります。
コードが書けなくても、権限とスコープの線引きさえ押さえれば、マーケ主導で安全かつ攻めたAI活用ができるようになります。
Claude CodeとMCPを会社の武器に変えるために 4,000社支援から見えたAIツール運用のリアル
ツールそのものよりも運用ルールとトラブル時の動き方で差がつく理由
同じ環境と設定ファイルを使っていても、生産性が2倍違うチームがあります。差をつけているのは、高機能なAIやMCPサーバーそのものではなく、「誰が・どのスコープで・どこまで許可するか」を決める運用ルールです。
現場で多いのは、テックリードがlocalで試した便利な設定を、そのままprojectにコピーし、気づけばuserスコープにも広がっているケースです。結果として、営業チームの端末からGitHubの全リポジトリにアクセスできていた、という「潜在的事故」が生まれます。
運用ルールとして最低限そろえたいのは、次の3点です。
-
スコープごとの役割定義
localは実験用、projectはチーム共有、userは個人の定常業務と明文化する
-
MCPサーバーごとのリスクラベル
読み取り専用か、書き込みありか、本番データかテストかをラベル管理する
-
トラブル時の停止フロー
誤動作時に「どの設定ファイルを無効化し、誰に連絡するか」を決めておく
とくに「止め方が決まっているかどうか」で、被害の大きさが大きく変わります。私の視点で言いますと、普段からMCPの一覧を棚卸ししておくチームほど、トラブル時の復旧が圧倒的に早い印象があります。
| 観点 | ツール導入だけのチーム | 運用ルールを持つチーム |
|---|---|---|
| スコープ設計 | 個人任せ | 権限と業務フローで設計 |
| 事故発生時 | 原因特定に時間がかかる | 停止手順と連絡先が整理済み |
| 効果測定 | なんとなく便利 | 業務ごとに指標を設定 |
SNS運用やWeb制作の現場でAIやMCPを組み込んだ時に起きがちな誤解とそれをほどく視点
SNS投稿やLP制作にAIを組み込むとき、マーケ側と技術側でよくズレるのが次の3つです。
-
「AIが触れるデータ」の範囲の誤解
-
「AIが出した案をどこまで自動採用してよいか」の誤解
-
「どのツールが本番アカウントに接続されているか」を誰も全体把握していない状態
このズレをほどくには、技術用語ではなく業務フロー単位の会話に落とし込むのが有効です。
-
「投稿案のドラフトまではAIが自動で作るが、投稿ボタンは人が押す」
-
「Googleスプレッドシートは読み取りのみ。書き込みは週1回、担当者が明示的に実行する」
-
「本番アカウントに接続してよいMCPサーバーは、このリストだけ」と合意しておく
誤解が起きやすいのは、接続しているサーバー名だけを共有して、「何ができる状態なのか」を共有していないときです。必ず機能ベースと権限ベースの両方で一覧化しておくと、非エンジニアもリスクをイメージしやすくなります。
-
機能ベースの例
- SNS投稿案生成
- 競合アカウントリサーチ
- レポートの自動ドラフト作成
-
権限ベースの例
- 読み取りのみ
- 書き込みありだがテスト環境限定
- 本番環境に書き込み可能
次の一歩に迷った時に見直したい自社の情報の流れとAIに触れさせて良い領域とダメな領域
MCPを増やしていくと、「もう何がどこにつながっているのか分からない」という相談が出てきます。この状態で連携を増やすと、便利さよりもリスクが先に膨らみます。そこで、次の一歩を決める前に自社の情報フローを棚卸しすることをおすすめします。
ポイントは3段階に分けることです。
-
情報の流れをざっくり書き出す
問い合わせがどこに入り、どのツールを通って、どの担当者が最終判断するかを図にする -
AIに触れさせてもよい領域をマーキングする
公開情報の収集、ドラフト作成、タグ付けなど、人の判断前提で使えるところを色分けする -
AIに触れさせてはいけない、または段階的に制限する領域を明確にする
生の顧客リスト、本番の決済情報、機密度の高い社内資料などを別管理にする
このとき役立つのが、スコープと権限をまとめたシンプルな表です。
| 区分 | 代表的な情報 | AI利用方針 | おすすめスコープ |
|---|---|---|---|
| 公開情報 | 自社サイト、オウンドメディア | 積極的に検索・要約に活用 | project |
| 準機密 | 社内共有のノウハウ資料 | 要約やドラフトのみ許可 | user |
| 高機密 | 顧客リスト、決済情報 | 原則AI経由で扱わない | 利用対象外 |
この表をチームで一度作っておくと、「このMCPサーバーはどこまでつないで良いか」を判断する基準が一気にクリアになります。結果として、AIとMCPが単なる流行のツールではなく、「事故を防ぎながら成果を底上げする会社の武器」に変わっていきます。
この記事を書いた理由
著者 – 伊藤 和則（nextlife事業部 責任者）
本記事は生成AIによる自動生成ではなく、業界歴15年の運営責任者の経験と現場知見に基づき制作しています。ご安心の上閲覧ください。
Claude CodeにMCPをつなぎ始めた瞬間から、コードと社内データのリスクは一気に広がります。4,000社以上のデジタル支援や、300社超のSNS運用体制を組んできた中で、便利さを優先して権限やスコープ設計を後回しにし、後から取り返しのつかない状態になったケースを何度も見てきました。
私自身、PCのログイン不可やツール側の設定ミスでインサイトが消えるトラブルを経験し、「とりあえず全部つなぐ」怖さを身をもって味わっています。特にMCPは、JSON一行の書き方やlocal・project・userの切り分けが甘いだけで、本番データの改変や大量通知につながりかねません。
中小企業や小さな開発チームには、専任情シスがいない現場も多く、AIと外部ツール連携の責任がWeb担当やマーケに集中します。そうした現場でも、WindowsやVSCodeの環境差に惑わされず、安全にMCPを設計・運用できる「最低限守るべき型」を届けたい。この記事は、そのために私が日々検証している設定ルールと、実際のトラブルから逆算したスコープ設計の考え方をまとめたものです。
