ClaudeDesktopのMCP設定でWindows運用と料金をまるごと理解！始め方から活用法まで徹底ガイド

Claude DesktopのMCPを会社支給のWindowsに入れた途端、jsonが反映されない、httpのMCPサーバーに接続できない、filesystemの権限をどこまで許可していいか判断できないまま時間だけが溶けていませんか。多くの記事は「MCPとは」「claude_desktop_config.jsonの書き方」といった表面の設定で終わり、Windows特有の制約や社内ポリシー、無料枠と料金、MCPサーバー乱立による運用破綻までは触れていません。結果として、「とりあえず動くが、本番では怖くて使えないClaude Desktop MCP」が量産されています。
本記事では、Claude Desktop MCPの概念整理から、Windowsでの設定ステップ、filesystemやhttpのMCPサーバー追加、jsonエラーや接続トラブルの突破口、さらにプラン選びと社内ルール設計までを一気通貫で扱います。最初に入れるべきおすすめ構成と、入れすぎてはいけないラインを情シス目線で示し、「どこまで権限を与えれば安全に業務を任せられるか」を具体的に判断できるようにします。この記事を読み進める数十分が、その後の設定やトラブル対応に費やす数日分の工数と、不要な課金を確実に削ります。

Claude Desktop MCPとは何か｜できることとやってはいけないことを最初に整理

「手元のPCが、そのまま社内専用のAIクラウドになる」仕組みがMCPです。
Desktopアプリが本体のモデルと日常のツールの間に立ち、ローカルファイルや社内サーバー、httpで公開された各種サービスに安全にアクセスさせる橋渡し役を担います。

押さえたいポイントは次の3つです。

• できること：ファイル参照、Gitリポジトリ操作、社内APIへの接続、スクリプト実行などを会話から自動化

• やるべきでないこと：PC全ドライブへのフルアクセス付与、認証付きAPIを雑なトークンで共用、権限管理なしのMCPサーバー乱立

• 前提：すべてはclaude_desktop_configのjsonとMCPサーバーの設計次第で「神ツール」にも「情報漏えい爆弾」にもなります

私の視点で言いますと、情シスが関与しないままfilesystemをルート直下に開けてしまうケースが、現場トラブルの典型です。

MCPサーバーとClaudeDesktopの関係を図解イメージで押さえる

文字で図解すると、構造は次のようになります。

• ユーザー

  ↓（プロンプト）

• Desktopアプリ

  ↓（MCPプロトコル）

• MCPサーバー（filesystem http Git など）

  ↓

• 実際のリソース（フォルダ データベース 外部API）

下記の対応表を見ておくとイメージしやすくなります。

役割	具体例	管理すべきポイント
クライアント	Desktopアプリ	セッション管理 起動/終了
MCPサーバー	filesystem http GitHub連携	command args env permissions
リソース	Windowsフォルダ 社内API	アクセス範囲 認証情報

ポイントは、Desktopアプリはあくまで窓口であり、実際の危険度は「どのMCPサーバーに何を任せるか」で決まることです。

filesystemやhttpのMCPで何が変わるか、具体的なタスク例

現場でまず検討されるのがfilesystemとhttpの2種類です。役割をタスクベースで整理すると、次のようになります。

MCP種別	向いているタスク	注意点
filesystem	議事録要約 コードレビュー ログ解析	フォルダ境界のpermissions設計
http	社内業務システム連携 チケット起票 API問い合わせ	認証情報とポート制御

実務でよくある使い方としては、Windowsの特定プロジェクトフォルダだけfilesystemで公開し、受発注システムやCRMはhttp経由のMCPサーバーでつなぐ形が安全です。これにより、AIがローカルのExcelを参照しつつ、クラウド側の最新データも同じセッションで扱えるようになります。

何でもつなげるは誤解？権限とセッション管理の限界ライン

MCPは拡張性が高い反面、「何でもつなげる」と思った瞬間に危険ゾーンへ入ります。特に注意したいのは次の3点です。

• 権限の粒度

  filesystemでCドライブ全体を見せるのは論外です。プロジェクト単位、部署単位でフォルダを分け、jsonのpermissionsで明示的に制御する発想が必須です。

• セッションの寿命

  長時間開きっぱなしのセッションは、席を離れたタイミングで第三者操作のリスクが高まります。会社PCではスクリーンロックと合わせて、Desktopアプリの自動切断時間も運用ルールに入れるべきです。

• MCPサーバーの数

  Git http filesystem Dockerコンテナなどを欲張って追加すると、「どのツールがどのサーバー経由なのか」が把握できなくなります。最初は3本までに絞り、プロジェクトごとに追加・削除を管理する方が、トラブル時の切り分けが圧倒的に楽になります。

MCPは、技術的にはWindowsでもMacでも強力に動きますが、真価が出るのは「どこまでアクセスさせるか」を冷静に線引きした時です。欲張らず、最小構成から堅実に広げていくことが、結果として一番速い近道になります。

Claude Desktop MCP設定の準備チェックリスト｜Windowsでの事前確認

「jsonを書き換えたのにツールが出ない」「会社PCだけ動かない」──多くの現場でつまずくのは、実は設定そのものより“事前準備の抜け”です。ここを押さえておくと、あとが一気にラクになります。

インストールと起動前に確認したい端末環境と管理ポリシー

最初に確認すべきなのは技術より会社ルールです。情シス兼エンジニアの方ほど、ここを先に固めると後でセキュリティ部門に差し戻されません。

主な確認ポイントは次の4つです。

• アプリのインストール権限があるか（管理者権限・ソフトウェア制限）

• ローカルで常駐するCLIやサーバープロセスの起動が許可されているか

• 社内ネットワークから外部httpエンドポイントへの接続ポリシー（プロキシ・FW）

• ローカルファイルへのAIアクセス範囲（社内規程で禁止フォルダがないか）

私の視点で言いますと、「技術的にできる」より「監査で説明できるか」を基準にしておくと、後でMCPサーバーの追加もしやすくなります。

最低限そろえたい端末環境をまとめると、次のイメージです。

項目	内容	チェック観点
OS	Windows 10/11 または macOS 最新系	会社標準と一致しているか
ネットワーク	社内LAN＋必要な外部ポート	http接続の制限有無
セキュリティ	ウイルス対策・EDR	不審プロセス扱いされないか
権限	ローカル実行権限	CLI・Docker・sshが使えるか

claude_desktop_configのjsonを触る前に決めるべき3つのこと

多くのトラブルは、「configを書きながら考える」ことで発生します。編集前に、次の3点だけ紙に書き出しておくと失敗が激減します。

1. どのタスクを任せるかを1〜2個に絞る
   例：

   • プロジェクトフォルダ内のコードリーディング
   • 特定Gitリポジトリの差分レビュー
     この時点でfilesystemの対象フォルダやGit連携の必要有無が決まります。

2. 許可するファイル範囲とpermissionsルール

   • Cドライブ全体はNG
   • 社内ファイルサーバーは一部サブフォルダのみ
   • 個人情報や給与データを含むパスは最初から除外
     情シス目線では、「AIが見てもよいパス一覧」を先に決めておくことが重要です。

3. 誰がjsonを編集し、誰がレビューするか

   • 情シス担当が編集し、責任者がconfigをレビュー
   • 開発メンバーはMCP追加を申請制にする
     ここを曖昧にすると、「いつの間にかMCPサーバーが乱立して誰も把握していない」状態になりがちです。

この3つが固まっていれば、claude_desktop_configのjson編集は作業化されたタスクになり、属人化を防げます。

MCPサーバーのインストール方式（CLI・Docker・httpエンドポイント）の選び方

どの方式を選ぶかで、運用コストとトラブルの種類が大きく変わります。よくあるパターンを現場目線で整理します。

方式	向いている場面	メリット	注意点
CLI直実行	個人PC・小規模チーム	導入が早い／学習コスト低い	パス設定・複数バージョン管理が面倒
Dockerコンテナ	情シス主導の共通環境	再現性が高い／ロールバックしやすい	Docker利用可否とリソース確保が前提
リモートhttpサーバー	社内共有MCP・外部サービス連携	クライアントPCの負荷が軽い	ポート・認証・ログ管理の設計が必須

選び方の目安は次の通りです。

• まずはCLIで1本だけ立てて、挙動とログをつかむ

• チームで共通ツールにしたくなったらDockerで標準イメージ化

• 社内ファイルサーバーやクラウドAPIを複数部署で共用したくなったらhttpエンドポイント方式を検討

特に会社PCでは、Dockerや常時稼働サーバーに対する監査の目線が厳しくなりやすいです。最初から背伸びをせず、「まずはローカルCLIで成功体験→運用負荷が見えたらDocker・リモートに移行」というステップを踏む方が、情シスと現場の両方が納得しやすい流れになります。

この準備段階をきちんと通しておくと、後続のWindows固有の設定やトラブルシュートも、単なる「起動しない謎現象」ではなく、原因を特定しやすい“読めるトラブル”に変わっていきます。

Windowsでのclaude_desktop_config json設定ステップ完全解説

「とりあえず動かしたいのに、jsonとWindowsだけが牙をむく」──多くの現場で見てきたつまずきを、ここで一気に片付けます。

Windowsでのclaude_desktop_config jsonの場所と、複数ファイル問題の回避法

Windows版Desktopアプリは、設定ファイルの場所を外すと一生認識されません。代表的なのは次のパターンです。

• ユーザーごとのAppData配下にあるファイルを編集していない

• 古いバージョン由来のconfigが別フォルダに残り、どれが本物か分からない

現場での安全な確認手順は次のとおりです。

1. アプリを完全終了（タスクトレイ右クリック→終了、タスクマネージャーでプロセスも確認）
2. AppData配下を検索し、「claude_desktop_config.json」が複数ないかチェック
3. 日付が新しいものだけ残し、古い試行錯誤ファイルは名前を明確にリネームして退避

ポイントは「1ユーザー1ファイル」を徹底することです。複数残ったままだと、どれを読んでいるのか誰も説明できなくなります。

MCPサーバーを追加するjsonサンプルと、commandとargsとenv設計の落とし穴

よくある事故は、「サンプルをコピペしたのに起動しない」ケースです。原因の多くは command と args と env の組み合わせミスです。

最低限押さえたい設計ルールを整理します。

• command

  • Windowsではフルパス指定を基本にします（node.exe や python.exe がPATHに無い端末が多いため）

• args

  • 実行するスクリプトやサブコマンドをここで列挙
  • 半角カンマの付け忘れや末尾の不要カンマでjsonエラーになりがちです

• env

  • APIキーやポート番号を環境変数として渡す領域
  • 情シス管理下では、ここに機密情報を直書きしないルールを決めておくと監査で揉めにくくなります

おすすめは、小さなMCPサーバー1本だけを定義した「最小構成のjson」をまず通し、そこから段階的に追記するやり方です。一気に3本以上追加すると、どの行で壊れたのか特定するのに半日溶ける現場を何度も見ています。

CLIとhttpサーバーのどちらでつなぐか？動作と負荷の違いを実務目線で比較

CLI方式とhttpサーバー方式は、「手元完結」か「ネットワーク越し」かで性格がはっきり分かれます。

方式	特徴	向いている場面
CLI	ローカルでプロセス起動、ネットワーク不要	個人PCでの検証、filesystem連携
httpサーバー	ポート経由で接続、複数ユーザー共有可能	社内サーバー上の共通MCP、Gitやクラウド連携

情シス視点では、httpサーバー方式にした瞬間「ポート管理」「アクセスログ」「認証方式」の3点セットが監査対象になります。逆に、会社PCでまず通したいならCLI方式から始め、安定した後にリモートMCPサーバーへ移行する流れが現実的です。

変更が反映されない・ツールが出ない時のセッションと終了手順

「jsonを書き換えたのに、Desktop側にツールが表示されない」という相談は非常に多いです。実は、原因の半分はアプリの終了手順とセッション更新にあります。

チェックする順番を決めておくと、毎回迷わず切り分けできます。

1. Desktopアプリを完全終了
   • タスクトレイだけでなく、タスクマネージャーで関連プロセスが残っていないか確認
2. MCPサーバー側のプロセスも再起動
   • CLIならコマンドプロンプトやPowerShellごと閉じて再実行
   • httpならポートが競合していないか確認
3. アプリ再起動後、新規チャットセッションを開始
   • 既存セッションではツール一覧が古いままのことがあります
4. ツール一覧から目的のMCPが表示されるか確認

私の視点で言いますと、「終了しきれていないDesktop」と「前の設定を握ったままのセッション」が、Windows環境での2大トラップです。ここを儀式のように毎回なぞるだけで、「動かないから今日は諦める」という無駄な日をほぼゼロにできます。

MCPサーバーのおすすめ構成｜最初は3本までが安全な目安

「何をどこまでつなぐか」で、この先の生産性もセキュリティもほぼ決まります。現場で見るトラブルの多くは「最初の3本」を間違えたことから始まっています。

まずは、情シス視点で無理なく運用できる最小構成を押さえてから、段階的に広げるイメージを持つのが安全です。

フェーズ	主役MCP	主な用途	情シスが見るポイント
第1段階	filesystem	ローカル資料の参照・要約	フォルダ範囲と権限管理
第2段階	Git系	コードレビュー・diff作成	リポジトリ単位のアクセス
第3段階	リモート/Docker	社内システム連携	ネットワークと監査ログ

filesystem MCPの安全な使い方と、フォルダ権限の決め方

filesystemは便利さと危険性が紙一重です。最初にやるべきことは「どこまで見せるか」を決めることで、「何をさせるか」より優先度が高いと感じています。

安全に始めるための判断軸は次の3つです。

• プロジェクト単位のフォルダだけを許可する

• 社外秘レベルのデータが混ざる場所は絶対に直下指定しない

• 読み取り専用からスタートし、書き込みは限定タスクだけに絞る

具体的には、次のような切り分けがよく機能します。

種類	許可するパスの例	備考
個人作業用	ユーザープロジェクト配下	検証・ドラフト用
チーム共有	読み取り専用の共有フォルダ	要バックアップ
禁止領域	デスクトップ全体・ホーム直下	監査で問題になりやすい

私の視点で言いますと、「とりあえずCドライブ丸ごと」は、後から必ずセキュリティ部門に止められる典型パターンです。最初は1プロジェクト配下に絞り、そのフォルダ構成を標準テンプレート化しておくと、監査もしやすくなります。

Gitやクラウドサービス連携のMCPサーバーはどこから始めるべきか

2本目、3本目として相性が良いのがGit連携とシンプルなクラウドサービス連携です。狙いは「ローカルに置きたくないものはリポジトリやSaaS側で完結させる」運用に寄せることです。

おすすめの優先順は次の通りです。

• Git連携MCP

  • 用途: diff作成、コードレビュー、ブランチ方針の相談
  • メリット: リポジトリ単位でアクセス制御しやすく、履歴も残る

• ドキュメント系クラウドサービス

  • 用途: マニュアル検索、議事録の要約、テンプレート作成
  • メリット: アクセス権は既存の社内ルールを流用できる

• タスク管理・チケット系サービス

  • 用途: チケット要約、コメント案生成、ステータス確認
  • メリット: 作業ログと紐づくため、後からの説明責任を果たしやすい

ポイントは、「すでにアクセス権管理が整っているサービスから順に」つなぐことです。新しい権限設計をゼロから起こすMCPは、後回しにした方が情シスの負荷が下がります。

DockerやリモートMCPサーバーはいつ検討するのが現実的か

DockerやリモートMCPサーバーは、最初から手を出すと燃えつきやすい領域です。導入タイミングの目安を整理すると、判断がぶれにくくなります。

検討タイミング	状況	ねらい
第1フェーズの卒業時	filesystemとGitで明確な成果が出た	開発・本番環境を分離したい
チーム利用が広がった時	複数PCで同じMCPを共有したい	設定の一元管理
セキュリティ要件が厳しくなった時	ゼロトラストや分離ネットワーク対応が必要	アクセス経路の明確化

DockerやリモートMCPを選ぶ判断軸は次の通りです。

• Docker型

  • 再現性重視、検証環境を素早く作り直したい
  • 開発チームがすでにコンテナ運用に慣れている

• リモートサーバー型

  • 社内ネットワーク内に集約したい
  • 監査ログやAPIゲートウェイで細かく制御したい

「全部をコンテナ化する」のではなく、「外に出したくないものだけを閉じたネットワークのMCPサーバーに寄せる」発想が中小企業では現実的です。まずは1サービス分だけをリモート化し、運用と監査のフローを固めてから、他のMCPに横展開していく構成が、現場では一番トラブルが少ないパターンになっています。

Claude Desktop MCPのトラブルシューティング｜jsonエラーと接続問題の突破法

「昨日まで動いていたのに、今日は一切応答しない」
現場でよく聞くこの状態は、多くが設定と権限のごく小さなミスから始まります。ここでは、情シス兼エンジニアの方が短時間で原因を絞り込めるよう、現場順番で整理します。

起動しない・落ちる時に真っ先に確認したいjsonのConfigとログファイル

起動トラブルは、ほぼconfigのjsonとログで片が付きます。優先順位を決めて見ると一気に楽になります。

確認の順番

1. configの場所と複数ファイルの有無
2. jsonの構文エラー
3. MCPセクションの記述ミス
4. アプリ側のログ

特にWindowsでは、ユーザーごとに設定ファイルが分かれている環境が多く、同僚が別の場所にconfigを作っていて上書きされているケースが目立ちます。

チェック項目	具体的に見るポイント
json構文	末尾カンマ、全角スペース、ダブルクォート漏れ
MCP定義	commandパス、argsの配列、envのタイポ
ログ	起動直後のエラー行、permission denied の有無

起動しなくなったときの保険として、編集前のconfigを必ずバックアップしておき、最悪は「MCP定義を全部削って素の状態で起動確認」が鉄板です。

MCPサーバーが動いているのにツールが実行されない時のチェック順序

「サーバープロセスは見えているのに、デスクトップアプリ側にツールが出ない」という問い合わせは、セッションとポートの詰まりが原因になりがちです。

おすすめの確認順序は次の通りです。

• サーバープロセスが同一ユーザー権限で動いているか

• http接続の場合、ポートが他プロセスと競合していないか

• セッションをまたいで古い定義を参照していないか

特に、MCPサーバーをCLIで自動起動する設定にしている場合、古いバージョンのserver実行ファイルがパス上に残り、別物を実行していることがあります。ツール一覧の表示が想定と違うと感じたら、サーバーのパスとバージョンを必ずセットで確認したいところです。

Windows特有のパスと権限やセキュリティソフトが原因になるケース

Windows会社PCでは、技術的な正しさより「端末管理ポリシー」と「セキュリティソフト」が実行を止めているケースが非常に多いです。

代表的なのは次のパターンです。

• Program Files以下への配置で、標準ユーザーに実行権限がない

• OneDrive配下のフォルダをfilesystemサーバーに渡し、同期中にアクセスエラー

• セキュリティソフトがローカルhttpサーバーを怪しい通信とみなして遮断

特にfilesystemのpermissionsでCドライブ直下を丸ごと渡している構成は、情シス側から差し戻されやすい形です。最初からプロジェクト単位のフォルダに絞り、「業務で必要な範囲だけ」という説明ができる設計にしておくと、後になって止められにくくなります。

ClaudeMCPサーバーを削除や無効化したい時の安全な手順

一度追加したサーバーを雑に消すと、起動不能や「ツールが一部だけ残る」状態を招きます。私の視点で言いますと、削除は次の順番を守ると事故がほぼ起きません。

1. デスクトップアプリを完全終了
   • タスクトレイとタスクマネージャーでプロセスを両方確認
2. MCPサーバープロセスの停止
   • サービス登録している場合はサービス側から停止
3. configのMCP定義を削除
   • 1行ずつではなく、サーバー単位のブロックごとに削る
4. 再起動してツール一覧を確認
   • 不要なツールが残っていないかをプロンプトからもチェック

複数人で同じ端末を使う環境では、「誰がいつconfigを触ったのか」が分からなくなりがちです。削除や無効化の前後で、簡単でも変更履歴を残しておくと、後から原因を追う時間を大きく減らせます。トラブルをゼロにするのは難しいですが、詰みパターンを先回りして潰しておくことで、MCP連携を安心して本番業務に乗せられるようになります。

Claude Desktopの料金とプラン選び｜MCPの本格運用に必要な課金

「とりあえず動く」段階から、「任せて安心」の業務インフラに変えるかどうかは、プラン選びと課金ラインでほぼ決まります。情シス兼任の立場で予算を握る人ほど、ここを読み飛ばすと後で痛い目を見ます。

ClaudeFreeとProとDesktopの違いをMCP利用視点で整理

まずは、MCPを前提にしたときのざっくり比較です。

視点	Free	Pro	Desktopアプリ
利用時間・セッション	混雑時に制限されやすい	比較的安定	アカウント種別に依存
MCPツール実行	軽いタスク向き	長めのタスクも現実的	ローカル連携の窓口
業務適性	個人検証	個人実務・小規模チーム	ホスト役＋UI

現場で多いパターンは「Freeで検証→Proに切り替え→DesktopでMCPを常用」という流れです。
MCPサーバー経由でGitやfilesystemを触り出した瞬間から、「Freeの気まぐれ制限」がボトルネックになります。特に、長めのdiff確認や大量ファイル参照タスクはPro以上を前提に見積もった方が安全です。

ClaudeDesktopの無料枠とMCPサーバー運用で見落としがちなコスト

「アプリもMCPサーバーも無料なのでコストゼロ」という判断は危険です。お金以外のコストがじわじわ効いてきます。

代表的な見落としポイントは次の通りです。

• 情シス・担当者の設定作業時間

• jsonミスや接続エラー対応で失われる作業時間

• Windows会社PCでのポリシー調整（申請〜承認のリードタイム）

• filesystemの権限設計や監査ログの確認作業

簡単なチェックリストを置いておきます。

• 設定担当者の時給 × 初期セットアップ時間

• 毎月発生しそうなトラブル対応時間（保守）

• 社内調整に必要な打ち合わせ回数

• MCPサーバーを増やすたびの検証時間

私の視点で言いますと、Proの月額より「担当1人が半日つぶれるコスト」の方がよほど高くつくケースが多いです。逆に、この時間を圧縮できる設計になっていれば、課金は十分ペイします。

API料金やクラウドMCPサーバーのランニングコストをタスク別にイメージ

次に、APIやクラウドMCPサーバーを絡めた場合の“財布へのインパクト”をタスク別にざっくり整理します。

タスク種別	主な実行場所	コストの主役	イメージすべきポイント
コードレビュー・diff確認	Desktop＋ローカルMCP	人件費	セッション時間と失敗リトライ回数
ドキュメント自動生成	API経由	トークン料金	文字数と更新頻度
データ集計・BI連携	クラウドMCPサーバー	インフラ＋API	常時稼働か、バッチか
Git操作・Issue作成	MCPサーバー（Git連携）	人件費	自動化できるフロー数

運用イメージを持つコツは、「1回のプロンプトで何分拘束されるか」「そのタスクを月に何回回すか」をざっくり掛け合わせてみることです。

• 月に数回のスポット利用なら

  • Desktop＋Pro＋ローカルMCPで十分

• 毎日決まった時刻にレポート生成やデータ連携を回すなら

  • API＋クラウドMCPサーバーでバッチ運用を検討

• 複数メンバーが同じツール群を使うなら

  • サーバー側でMCPを一元管理して、Desktopは「窓口」として割り切る設計が有利

最終的には、「どのタスクを人がやるか」「どのタスクをMCPに任せるか」を線引きして、そこで初めてProやAPIの課金が“投資”に変わります。料金表よりも、自社のタスク表を先に書き出した人から、AI活用の元は取りやすくなります。

中小企業の業務へのMCP組み込み設計｜セキュリティと運用ルール

「便利さと危なさが紙一重」なのが、中小企業のWindows端末でMCPを動かすときのリアルです。うまく設計できれば、情シス1人でもチーム全体の生産性が一段跳ねますが、設計を外すと監査で止まり、現場からもクレームが飛ぶ仕組みになります。

ここでは机上の理想論ではなく、会社PCで本当に回る「権限と運用ルール」の型をまとめます。

filesystem MCPと社内ファイルサーバー、どこまで見せてどこを遮断するか

filesystem MCPは、便利さと情報漏えいリスクのスライダーをどう固定するかの勝負です。最初に「AIに見せる世界」と「絶対に見せない世界」を線引きしておきます。

代表的な切り方は次の3パターンです。

レベル	許可するフォルダ例	主な用途	情シス目線のリスク
最小	作業用プロジェクト直下のみ	ドキュメント整形、コードレビュー	漏えい範囲をピンポイントで制御しやすい
中	部署共有フォルダ（開示前資料を除外）	チーム単位の定型タスク	権限設計を誤ると内部情報が一気に見える
高	ドライブ広範囲やユーザー直下	全社横断の検索・要約	監査・規程がない会社ではほぼアウト

中小企業では、必ず「最小」から始めて徐々に広げる運用をおすすめします。特に注意したいのが、社内ファイルサーバーと同期しているフォルダです。同期クライアントのルートを丸ごと許可すると、本人も把握していない機密がAIに見える状態になります。

運用上のコツは次の3つです。

• プロジェクトごとに「AI用作業ディレクトリ」を決め、そこだけをfilesystemで許可する

• 機密度が高いフォルダには、そもそもMCPを向けない前提でディレクトリ構成を組み直す

• 「このフォルダに入れた瞬間、AIからも見える」というルールをチームで明文化する

私の視点で言いますと、権限の議論を難しくしているのは技術ではなく、フォルダ構成のぐちゃぐちゃさです。ここを整理してからMCPをつなぐ方が、長期的には圧倒的に安全に回ります。

情シスや管理部門と合意しておきたいMCP利用ポリシーと監査のポイント

情シスと管理部門が不安になるのは、「誰が、どのAIから、どのデータに触れたのか」が見えなくなることです。ここを最初から設計に組み込んでおけば、止められにくい導入になります。

合意しておきたい最低ラインを整理すると次の通りです。

• 利用範囲の明文化

  • 対象部署、対象業務（議事録、マニュアル作成、コードレビューなど）
  • 禁止タスク（契約書の原案作成、未公開の決算情報の要約など）

• ログと証跡

  • Claude側の会話ログ保存設定
  • filesystem MCPが触れるパス一覧を情シスが確認できる状態にしておく
  • 重要ファイルはMCP経由で直接触らず、コピーをAI用ディレクトリに置く運用

• レビューの仕組み

  • AIが生成した成果物は、必ず人間が確認してから社外共有
  • 重要案件は「AI利用した」こと自体を記録に残す

監査でよく突かれるのが、「社員が勝手に設定していないか」「MCPサーバーがどこで動いているか」です。ここに対しては、次のようなルールを事前に作っておくと安心です。

• MCPサーバーの追加やjsonの編集は、情シスまたは担当者に限定

• 追加したMCPサーバーの一覧と用途を、簡易な台帳として管理（スプレッドシートで十分）

• 社外クラウドやリモートMCPを使う場合は、必ず事前申請制にする

MCPツールの権限やセッション管理をロール別に決める実務パターン

同じMCPでも、「誰が使うか」で許可してよい範囲は変わります。ロールごとにセッションの前提と権限を分けておくと、運用が一気に安定します。

ロール	主なタスク	MCP権限の目安	セッション運用
一般社員	文書作成、議事録、簡単な表整理	filesystemはプロジェクト単位のみ	セッションはタスクごとに区切り、機密を混ぜない
開発担当	コードレビュー、ログ解析	Gitやfilesystemの技術領域フォルダまで	開発プロジェクトごとにセッションを分離
情シス・管理者	設定、検証、トラブル対応	ほぼ全MCPサーバーにアクセス可	テスト用と本番用のセッションを明確に分割

現場で混乱を生むのは、「同じツールがロールによって別の顔をしている」ことです。たとえばfilesystem MCPなら、次のようなルール分けが有効です。

• 一般社員用の設定ファイルでは、アクセスパスを極小に固定

• 開発者用には、Git連携MCPとログ解析用のディレクトリを追加

• 管理者だけが、全設定を確認できるマスターファイルを保持

また、セッション管理をあいまいにすると、「前の案件で読み込んだ機密情報を、別案件の回答に混ぜる」リスクが急上昇します。最低限、次の運用だけはチームに徹底したいところです。

• 案件やクライアントが変わるタイミングで、必ず新規セッションを開始

• セッション名に案件名やプロジェクト名を入れて整理しやすくする

• 長期間開きっぱなしのセッションを定期的にクローズするルールを作る

このレベルまで権限とセッションを「ロール別の設計図」として決めておくと、MCPは単なる便利ツールから、「社内の仕事の流れを支える基盤」に化けます。中小企業でもここを押さえておけば、監査に耐えつつ、現場からも喜ばれる形で導入しやすくなります。

MCP導入で実際にあった詰みパターンと回避策｜現場トラブル事例

情シスやIT担当の現場で見ていると、「設定もjsonもそれなりに触れるのに、なぜかタスクが途中で止まる」「MCPサーバーを増やした瞬間からデスクトップアプリがカオスになる」という相談が一気に増えています。表面的な手順では見えない“詰みポイント”を、実際のトラブル構造に踏み込んで整理します。

最初は順調だったのに途中で止まる、よくあるタスクと発生箇所

止まり方にはパターンがあります。代表的なものを整理します。

• ドキュメント自動要約タスクが、特定のフォルダ配下だけ失敗する

• Gitリポジトリの差分確認までは動くのに、コミットログ参照で固まる

• http系MCPに接続後、数回のセッションまでは実行できるが、その後タイムアウトが続く

原因の多くは、セッションごとの権限とコンテキストの“想定外の上限”です。

症状	よくある原因	すぐ試す確認ポイント
一部フォルダだけ失敗	filesystem MCPのpermissionsがサブフォルダを含んでいない	jsonのpaths設定と実際のパスを突き合わせる
Git操作だけ途中停止	CLIサーバー側の環境変数不足	envでSSHキーやトークンが渡っているか確認
数回だけ成功しその後落ちる	httpサーバー側のセッションタイムアウトやレート制限	serverログとレスポンスコードの取得

「アプリが悪い」のではなく、MCPサーバー側の制限が静かに効いているケースが大半です。Windows環境ではウイルス対策ソフトがCLI実行を一時ブロックしている例もあり、ログを見ずに再インストールを繰り返すと、本質的な問題が一切解決しません。

MCPサーバーを増やしすぎて設定がカオスになった時の整理術

現場で一番“詰みやすい”のが、MCPサーバー乱立による設定スパゲッティです。典型的な悪化ルートは次の通りです。

• 最初にfilesystemを導入

• その後、Git、http、Docker経由のツールを次々追加

• claude_desktop_configのjsonにcommandとargsを継ぎ足し続ける

• どのツールがどのサーバーか誰も説明できない状態になる

この段階に来たら、「追加」ではなく棚卸しリファクタに一度振り切った方が早いです。

1. 現在登録されているMCPサーバーを一覧化
2. タスク単位（例: コードレビュー、議事録要約、社内FAQ）で、どのサーバーを使うかをマッピング
3. 役割が重複しているものを削除、または一方に統合
4. jsonを「目的別ブロック」でコメント整理（例: // filesystem for docs）

整理の観点	残すサーバー	削る候補
日次の定型業務で必須か	毎日使うfilesystemやGit連携	思いつきで試した検証用サーバー
権限の説明がしやすいか	フォルダやAPIスコープが明確	permissionsが広すぎて説明困難
保守担当が決まっているか	担当者名がいるもの	作った人が異動・退職済みのもの

「全部残す」は一番リスクが高い選択です。特にfilesystemとhttpの両方から同じデータにアクセスできる構成は、監査の観点で説明が難しくなるため、どちらかに寄せる判断が重要になります。

LINEやメールで飛んでくる現場からの相談パターンとプロが返す一言の違い

実務では、こんなメッセージが飛んできます。

• 「急にツールが出なくなりました。アプリの不具合でしょうか」

• 「昨日まで動いていたサーバーに接続できません」

• 「jsonを少し変えただけなのに、起動しなくなりました」

ここでのプロの返し方は、原因を即断しないことです。私の視点で言いますと、最初の一言は次の3つのどれかに絞ります。

• 「まず、いつ何を変えたかを10分だけ振り返ってもらえますか」

• 「Windowsを含めて、最後に再起動したのはいつか教えてください」

• 「configのバックアップはありますか。あれば、直前とdiffを取りましょう」

この一言で、「アプリのせい」にされがちなトラブルを、変更履歴とセッション単位の問題として再定義できます。特にjson構文ミスで起動不能になったケースでは、バックアップとdiffがあるかどうかで復旧時間が何倍も変わります。

相談チャネルがLINEやメールの場合、ログやconfigをそのまま貼りづらいため、テンプレートを用意しておくと混乱が激減します。

• 直前に行った操作（インストール、json編集、再起動の有無）

• どのタスクで、どのサーバーを使おうとしたか

• エラー表示のスクリーンショット、またはログファイルのパス

この3点を最初から送ってもらえるだけで、「とりあえず再インストール」という時間のムダを、かなりの確率で避けられます。デスクトップアプリのトラブルは“雰囲気”で語られがちですが、MCPの世界ではセッション、権限、config変更の三点セットで分解する癖が、詰みパターンを避ける最大の武器になります。

Claude Desktop MCPとの付き合い方｜IT現場からの教訓

「入れた瞬間に世界が変わる現場」と「入れた瞬間から火消しが始まる現場」、どちらにも共通しているのは技術力ではなく、運用設計の有無です。MCPは設定よりも“付き合い方”で差がつきます。

ツール導入支援の立場から見えるMCPを入れていい現場とまだ早い現場

導入支援をしていると、同じWindows会社PCでも「今すぐMCPを入れていい現場」と「まだ待つべき現場」がはっきり分かれます。

判定軸	入れていい現場	まだ早い現場
端末管理	ローカル権限の範囲が説明されている	誰が何を入れてよいか曖昧
ファイル運用	共有フォルダのルールが明文化されている	個人フォルダと共有が混在
情シス体制	最低1人は設定をレビューできる	各自が勝手にツール導入
トラブル対応	エラー時の連絡窓口が決まっている	「詳しい人に聞く」で終わり

filesystemサーバーを許可しても問題が起きにくいのは、そもそも「どのフォルダをAIに見せてよいか」が社内ですり合っている現場です。逆に、共有ドライブに機密と私物が混ざっている会社は、リモートMCPサーバー経由で必要なデータだけ渡す構成から始めた方が安全です。

村上雄介が中小企業支援で重視しているAIツールやMCPの現場で本当に使えるかの判定基準

私の視点で言いますと、MCPが「技術的に動くか」より「現場で回し切れるか」を見る時、次の3点を必ず確認します。

• 誰が設定ファイルを触るか

  claude_desktop_configのjsonを編集できる人と、実際に使う人が完全に分離していると、トラブル時に作業が止まりやすくなります。編集者と利用者が会話できる距離にいるかが重要です。

• 失敗した時にどこまで巻き戻せるか

  jsonの構文ミスでアプリが起動しない状態に備え、バックアップと復旧手順を紙や社内Wikiに残しておくかどうかで“詰みリスク”が変わります。

• 権限をどこで絞るかの方針

  filesystemで深く見せるのか、httpのMCPサーバー側でAPI permissionsを絞るのか、「制限の主戦場」を決めておかないと、後からあらゆる場所で二重三重の制御が発生します。

この3点が揃っていれば、多少MCPサーバーを増やしても設定スパゲッティになりにくく、情シス側も追跡しやすくなります。

ClaudeDesktopのMCPを導入する前に社内で共有しておきたいチェックリスト

導入相談でまず共有してもらうのが、次のチェックリストです。これを事前に埋めてから議論すると、トラブルの8割は最初から避けられます。

• 端末・ネットワーク

  • WindowsとmacOSそれぞれでインストール権限がある担当を決めたか
  • 社外クラウドやGitHubへの接続ポート制限を把握しているか

• ファイルと権限

  • filesystemでAIに見せてよいフォルダの一覧を作成したか
  • 社内ファイルサーバーと個人PCのどちらを優先対象にするか決めたか

• 運用・監査

  • MCPサーバーの追加・削除を申請制にするか、情シス承認制にするか決めたか
  • どのセッションでどのツールが使われたか、最低限のログ取得方法を決めたか

• コストと責任範囲

  • ProやAPIなどの課金はどの部署予算で持つか
  • 障害発生時に「誰がどこまで見るか」の責任範囲を明文化したか

このチェックリストを埋めながら話し合うと、「とりあえずMCPを入れて様子を見る」ではなく、「どの範囲から安全に試すか」という現実的なスタートラインが見えてきます。ここまで整えておくと、導入後も慌てることなく、AIに任せられるタスクを一つずつ増やしていけるはずです。

この記事を書いた理由

著者 – 村上 雄介（newcurrent編集部ライター）

Claude DesktopのMCPは、43社の支援先でも「入れてみたが、本番には出せない」という相談がここ1年で一気に増えました。会社支給のWindowsに入れた途端、jsonがどこを見ているか分からない、httpのMCPサーバーが社内プロキシで弾かれる、filesystemで意図しない共有フォルダまで触れてしまう。こうした相談は1社だけではなく、業種の違う複数の企業でほぼ同じ形で起きています。

私自身も検証用PCでclaude_desktop_configを複数置いてしまい、どの設定が有効なのか分からなくなって半日潰したことがあります。MCPサーバーを欲張って増やしすぎ、Windowsの権限設定とセキュリティソフトに阻まれて「とりあえず動くが怖くて任せられない」状態にもなりました。

この記事では、その遠回りを前提に「最初の3本の構成」「入れないほうがいいライン」「料金を含めて現場で本当に回る形」を具体的に描きました。ITが得意ではない担当者でも、情シスと同じテーブルでMCP導入を判断できる材料をそろえることが、このテーマを書いた一番の理由です。

※契約・消費者トラブルは 消費者庁 も参考になります。