MCPサーバーとは｜できることと導入手順

「MCPサーバーを立てましょう」「このツールはMCPサーバーを提供しています」といった説明を目にしても、結局それは何で、自社では何を用意すればいいのかが分かりにくい。情報システム担当の方からよく届く質問です。

本記事は、MCPという言葉の意味を説明する記事ではありません。実際にどのサーバーを選び、どう接続し、どこまで権限を渡し、どう管理し続けるかという、導入担当者が手を動かす部分に絞って整理します。

あわせて、多くの企業がつまずく「自社専用のサーバーを作るべきか」という判断についても、判断基準の形で提示します。

結論｜MCPサーバーとは何か

先に結論から書きます。

ひとことで言うと

MCPサーバーとは、特定のデータやツールを、AIから呼び出せる形で提供している小さなプログラムです。GitHubのMCPサーバーならGitHubの情報を、社内データベース用のMCPサーバーなら社内データベースの情報を、AI側から扱えるようにします。

AI側のアプリ（Claude、Claude Code、各種エディタなど）が「クライアント」、データやツールを差し出す側が「サーバー」です。この2つが決まった形式で会話することで、接続先ごとの作り込みをせずに済みます。

MCP（Model Context Protocol）そのものの考え方、なぜこの標準が必要になったのか、クライアントとの関係についてはMCPとは｜AIと自社データをつなぐ仕組みを解説で扱っています。概念から確認したい方はそちらを先にお読みください。

導入担当者にとっての実態

実務では、MCPサーバーは「設定ファイルに1行足すと使えるようになる接続口」として現れます。多くの場合、自分でプログラムを書く必要はありません。

Anthropicの発表時点で、Google Drive、Slack、GitHub、Git、Postgres、Puppeteerといった事前構築済みのサーバーが公開されていました（出典：Anthropic「Introducing the Model Context Protocol」）。現在はこれよりはるかに多くのサービスが対応しています。

担当者が実際に決めること

つまり、導入担当者の仕事は「サーバーを作ること」ではなく、次の3点を決めることです。

• どのサーバーをつなぐか（接続先の選定）
• どこまでの権限を渡すか（読み取りのみか、書き込みも許すか）
• 誰が追加・変更できるか（管理の所在）

この3点を決めずに現場任せにすると、把握できない接続が増えていきます。順番に見ていきます。

MCPサーバーでできること

サーバーが提供する機能は、大きく3種類に分かれます。

ツール（操作の実行）

もっとも使われるのがこれです。「検索する」「作成する」「更新する」といった操作を、AIから呼び出せる形で提供します。

たとえば課題管理システムのサーバーなら「課題を検索する」「課題を作成する」「コメントを追加する」といった操作が並びます。AIは会話の流れの中で、必要なものを選んで実行します。

リソース（データの参照）

ファイルの中身、データベースのレコード、設定情報など、読み取り対象としてのデータを提供します。操作を伴わないため、リスクは相対的に低い部類です。

プロンプト（定型の依頼文）

サーバー側が用意したあらかじめ形の決まった依頼文を、利用者が呼び出せるようにする仕組みです。「この形式でレビューして」「この観点で要約して」といった型を配布する用途に使われます。

実際の業務での見え方

これらが組み合わさると、業務側からはこう見えます。

• 「先月の受注データから、単価が下がっている取引先を出して」と頼むと、AIが基幹システムに問い合わせて答える
• 「この仕様書の内容で課題を3件登録して」と頼むと、課題管理システムに直接登録される
• 「共有フォルダの見積書から、有効期限が今月中のものを一覧化して」が数十秒で終わる

いずれも人が画面を開いて探す作業を代わりにやらせているという点で共通しています。逆に言えば、人が探す作業が少ない業務では効果が出ません。

どんなサーバーがあるか

公開されているサーバーは膨大です。すべてを把握する必要はないので、分類で押さえます。

1｜業務SaaS系

普段使っているクラウドサービスが自社で公式サーバーを提供しているパターンです。課題管理、CRM、決済、監視、ドキュメント共有など、主要なサービスの多くが対応しています。

中小企業がまず検討すべきはこの層です。提供元が公式に運用しているため、素性がはっきりしており、認証も正規の手順で行われます。

2｜開発・インフラ系

ソースコード管理、データベース、ブラウザ操作、クラウド基盤の管理など、技術者向けのサーバー群です。開発部門がある企業では利用価値が高い一方、権限設計を誤ると影響範囲が大きい領域でもあります。

3｜ローカル系

自分のパソコン上のファイルを読む、ローカルのコマンドを実行するといった、手元で動くサーバーです。手軽ですが、後述するとおりセキュリティ上の注意点がもっとも多い種類です。

4｜自作・社内専用

自社の基幹システムや独自データベースに接続するために、自分たちで作るサーバーです。判断基準は後述します。

探し方

公開サーバーを探す場所としては、MCPの公式レジストリがあります。2025年9月8日にプレビューとして公開されたもので、逆引きDNS形式の名前空間認証によって公開者が名乗ったとおりの提供元であることを担保する設計が採られています（出典：Model Context Protocol Blog「Introducing the MCP Registry」）。

ただし、レジストリに載っていることは「自社が使ってよい」という意味ではありません。次の選び方に進みます。

MCPサーバーの選び方

候補が多すぎて選べない、という相談が非常に多い部分です。次の順で絞ってください。

基準1｜提供元が公式かどうか

同じサービス向けに、公式サーバーと第三者が作ったサーバーが並んでいることがあります。原則として公式を選んでください。

第三者製は、認証情報の扱い方が分からない、更新が止まる、提供元が突然変わるといったリスクを抱えます。業務データを扱う以上、素性の確認できないものを選ぶ理由はありません。

基準2｜読み取り専用で使えるか

導入初期は読み取り機能だけを使うのが鉄則です。書き込み・削除の機能しか提供していないサーバー、あるいは権限を分けられないサーバーは、最初の1本には向きません。

基準3｜認証方式が正規か

接続時に、そのサービスの正規のログイン画面が出て、許可する範囲が明示されるかを確認してください。設定ファイルにパスワードを直書きさせるタイプは避けます。

基準4｜業務上の頻度があるか

もっとも見落とされる基準です。「つなげるからつなぐ」は失敗します。

選ぶべきは、週1回以上、人が手で情報を取りに行っている接続先です。月1回程度の作業を自動化しても、設定や検証の手間のほうが上回ります。

選定チェック表

確認項目	望ましい状態	避けたい状態
提供元	サービス提供元の公式	提供者不明の第三者製
権限	読み取りのみに絞れる	全権限が一括で付与される
認証	正規のログイン画面を経由	設定ファイルに認証情報を直書き
接続方式	提供元が運用するリモート接続	出所不明のプログラムを手元で実行
業務頻度	週1回以上の手作業がある	使う場面が思いつかない
データ	個人情報を含まない範囲から開始	いきなり顧客名簿を対象にする

接続の流れと設定手順

ここからは、実際の接続作業です。開発現場で使われているClaude Codeを例に、公式ドキュメントの記載にもとづいて手順を示します（出典：Claude Code公式ドキュメント「Connect Claude Code to tools via MCP」）。

接続方式は3種類

まず、サーバーとの通信方式を選びます。公式ドキュメントでは主に次の3つが説明されています。

方式	どんなときに使うか
HTTP	提供元が運用するリモートサーバーにつなぐ。もっとも一般的
SSE	同じくリモート接続。サービス側がこの形式で提供している場合
stdio	手元のパソコン上でサーバーのプログラムを起動してつなぐ

中小企業がまず使うのはHTTPです。提供元が運用しているものにつなぐだけなので、手元で何かを実行する必要がありません。

設定の適用範囲は3種類

次に、その設定を「どこまで有効にするか」を決めます。ここが管理上もっとも重要です。

範囲	有効になる場所	チームで共有
local（既定）	その案件だけ・自分だけ	されない
project	その案件のメンバー全員	設定ファイルを通じて共有
user	自分の全案件	されない

projectを選ぶと、案件のフォルダに.mcp.jsonという設定ファイルが作られ、これをバージョン管理に含めることでチーム全員が同じ接続を使えるようになります。

ただし、公式ドキュメントには安全上の理由から、この共有設定に含まれるサーバーを使う前に承認を求めると明記されています。誰かが勝手に追加した接続が、無断で全員に有効化されることはありません。

実際の追加コマンド

リモートサーバーを追加する場合の基本形は次のとおりです。

• claude mcp add –transport http （名前） （URL）｜リモートサーバーを追加する
• claude mcp add –transport http （名前） –scope project （URL）｜チーム共有として追加する
• claude mcp list｜登録済みの一覧と接続状態を確認する
• claude mcp get （名前）｜特定のサーバーの詳細を確認する
• claude mcp remove （名前）｜登録を削除する

一覧表示では、サーバーごとに接続状態が表示されます。正常なら接続済み、認証が必要なら認証待ち、失敗していればその旨が表示される仕様です。

認証を通す

多くのサービスはログインが必要です。Claude Codeではclaude mcp login （名前）で、そのサーバーの認証手続きを開始できます。認証情報を消す場合はclaude mcp logout （名前）です。

ここで重要なのは、設定ファイルにパスワードやトークンを直接書かないことです。公式ドキュメントでは、設定内で環境変数を参照する書き方が案内されています。設定ファイルをバージョン管理に含める場合、認証情報が一緒に配布されてしまう事故を防げます。

接続後の確認

つないだら、次を必ず確認してください。

1. 一覧表示で接続状態が正常になっているか
2. そのサーバーがどんな操作を提供しているか（意図しない書き込み機能が含まれていないか）
3. 読み取り操作を1つ実行し、想定どおりの範囲だけが見えているか
4. 見えてはいけないデータが見えていないか

4番目が抜けがちです。「つながった」と「範囲が正しい」は別の話です。

権限の絞り方

MCP導入の成否は、ほぼこの一点にかかっています。

原則1｜最初は読み取りのみ

書き込み・更新・削除の権限は、最初は渡さないでください。AIが誤った操作をした場合、読み取りなら何も起きませんが、書き込みなら実データが変わります。

読み取り専用で1か月運用し、実際にどんな使われ方をしているかのログを見てから拡張を判断します。

原則2｜権限は必要最小限に

MCP公式のセキュリティ文書では、権限設計の失敗として「ワイルドカードや包括的な権限（すべて、全権限といった指定）を使うこと」が明確に挙げられています。広い権限を持つ認証情報が漏れた場合、被害範囲がそのまま広がるためです（出典：Model Context Protocol「Security Best Practices」）。

同文書では、最初は低リスクの参照系だけを許可し、必要になった時点で段階的に権限を引き上げる進め方が推奨されています。実務でもこの順序を守ってください。

原則3｜アカウントを分ける

接続に使うアカウントは、担当者個人のアカウントを流用しないのが安全です。AI接続専用のアカウントを作り、そこに必要な範囲だけの権限を付与します。

こうしておくと、問題が起きたときにそのアカウントを止めるだけで接続を遮断できます。個人アカウントを流用していると、止めた瞬間にその人の業務も止まります。

原則4｜危険な操作は人の承認を挟む

Claude Codeの公式ドキュメントでは、サーバー側の設定によって特定の操作について毎回ユーザーの承認を必須にする指定ができると説明されています。自動承認の設定にしていても、その操作だけは必ず人に確認が回ります。

自社でサーバーを作る場合、影響の大きい操作にはこの指定を付けてください。既存サーバーを使う場合は、そもそも危険な操作を含むサーバーを避けるのが現実的です。

権限設計の早見表

段階	渡す権限	期間の目安
第1段階	特定フォルダ・特定テーブルの読み取りのみ	1か月
第2段階	読み取り範囲を拡大（個人情報は除外のまま）	1〜2か月
第3段階	下書き作成など、影響が戻せる書き込み	効果が確認できてから
第4段階	確定処理を伴う書き込み（承認必須の設定を併用）	原則として保留

サーバー固有のセキュリティ

ここはサーバー側に踏み込む本記事の中心です。MCP公式のセキュリティ文書に記載されている攻撃手法のうち、導入企業側で対処できるものを選んで整理します。

手元で動かすサーバーの危険性

公式文書では、ローカルで動かすサーバーについてクライアントと同じ権限で動作するため、任意のコード実行につながりうると明記されています。設定に悪意ある起動コマンドが仕込まれる、サーバー本体に悪意ある処理が同梱される、といった経路が挙げられています。

実務上の対策は単純です。出所の分からないプログラムを手元で実行しない。この一点に尽きます。リモート接続で用が足りるなら、そちらを選んでください。

取り込んだデータに指示が混ざるリスク

MCPサーバー経由で取得したデータの中に、AIへの指示として解釈されうる文章が仕込まれている場合があります。外部から来る文章（問い合わせメール、Webページ、共有された文書など）を扱うサーバーで、特に注意が必要です。

対策は2つです。信頼できる接続先に限定することと、影響の大きい操作の前に人の確認を挟むこと。取得したデータは「情報」であって「命令」ではない、という前提を崩さない設計にします。

認証情報の使い回し

公式文書では、あるサービス向けに発行された認証情報を、別のサーバーがそのまま受け取って転送する構成が明確に禁止されるアンチパターンとして説明されています。監査ログ上の追跡が困難になり、盗まれた認証情報の中継役として悪用されうるためです。

利用側の実務としては、「1つのトークンを複数のサーバーで使い回さない」と読み替えてください。接続ごとに専用の認証情報を発行します。

接続先の一覧を持つ

もっとも現実的なリスクは、高度な攻撃ではなく「誰が何につないでいるか分からない」状態です。担当者が個人の判断で便利なサーバーを足していくと、半年後には把握不能になります。

接続先の台帳を作ってください。項目は次の6つで足ります。

• サーバー名と提供元
• 接続先のURLまたは実行コマンド
• 渡している権限の範囲
• 使用しているアカウント
• 追加した日と承認者
• 棚卸しの最終確認日

出力量にも上限がある

技術的な話ですが、運用に効いてきます。Claude Codeの公式ドキュメントによれば、サーバーからの出力が一定量を超えると警告が出て、既定の上限を超える分は扱われません。

実務上の意味は「巨大なテーブルを丸ごと読ませる使い方は想定されていない」ということです。抽出条件を絞ってから渡す設計にしてください。

社内ルールへの反映

技術的な対策と並行して、ルール側の整備が必要です。既存のAI利用ルールに、次の項目を追加してください。

• MCPサーバーの追加は誰が承認するか
• 使用してよいサーバーの条件（公式提供のみ、など）
• 読み取り専用から始めるという原則
• 接続先台帳の管理者と棚卸しの頻度

ルールの作り方そのものは社内AIルールの作り方にまとめています。

自社専用サーバーを作るべきか

「うちの基幹システム用にMCPサーバーを作りたい」という相談が増えています。判断基準を明確にします。

作る必要がないケース

次に当てはまるなら、作らないでください。

• 公式サーバーが既に存在する｜使っているSaaSが公式提供しているなら、自作する理由はありません
• 接続してみたいだけ｜業務上の反復作業が特定できていない段階で作ると、使われないまま保守だけが残ります
• データを取り出す手段が別にある｜定期的にファイルへ書き出せるなら、そのファイルを読ませるほうが早く安全です
• 保守できる人がいない｜作った人が退職したら止まる構成は、業務に組み込んではいけません

作る価値があるケース

逆に、次の条件が揃っているなら検討する価値があります。

• 社内固有のシステムに、週次以上の頻度で人が情報を取りに行っている
• 取りに行く情報の形が毎回ほぼ同じ（=決まった問い合わせに集約できる）
• そのシステムに、読み取り専用の接続手段がある（APIやビューなど）
• 保守を担当する人または委託先が決まっている

4つすべてを満たすことが条件です。特に4番目を空欄のまま進めた案件は、ほぼ確実に放置されます。

作る場合の最小構成

作ると決めた場合も、いきなり多機能にしないでください。最初に用意する操作は1〜3個で十分です。

1. もっとも頻度の高い検索を1つだけ実装する
2. 読み取り専用のアカウントで接続する
3. 返す項目を絞る（個人情報の列は最初から返さない）
4. 1か月使い、実際に呼ばれた操作だけを残す

この順で進めると、使われない機能を作り込む無駄を避けられます。

仕様が動いている点への注意

MCPの仕様は継続的に更新されています。2026年7月28日版では、ステートレスなプロトコル設計への移行や認可まわりの強化が行われ、いくつかの機能に非推奨の扱いが入っています（出典：Model Context Protocol Blog「2026-07-28版」）。

公式サーバーを使う分には提供元が追随してくれますが、自作した場合は自社で追随する必要があります。これも保守負担として見込んでおいてください。

つないだ後の運用管理

導入で終わらせず、運用に落とし込むための項目です。

月1回の棚卸し

接続先台帳を見ながら、次を確認します。

• 使われていない接続はないか（使っていないなら消す）
• 権限が広がっていないか
• 接続用アカウントは有効か、退職者のものが残っていないか
• 提供元からの変更通知が来ていないか

ログを残す

いつ、誰が、どのサーバーに、どんな操作をさせたか。この記録がないと、問題が起きたときに範囲を特定できません。

専用の仕組みを作る必要はありません。接続先サービス側のアクセスログを残す設定にしておけば、多くの場合それで足ります。AI接続専用アカウントを分けておくと、ログ上でも区別しやすくなります。

効果の測り方

「便利になった」では継続判断ができません。導入前に、次の1つだけ測っておいてください。

対象の作業に、月何時間かかっているか。導入3か月後に同じ数字を測り、変化を見ます。変化がなければ、対象の選定が間違っていたということです。

広げるタイミング

次の接続先を足すのは、最初の1本で明確な時間削減が確認できてからにしてください。同時に複数つなぐと、どれが効いているのか分からなくなります。

できないこと・向かない場面

正直に書きます。ここを誤解したまま導入すると、確実に失望します。

AIが賢くなるわけではない

MCPは接続の取り決めであり、AIの判断精度を上げる仕組みではありません。事実でない内容を出す可能性は接続前と変わりません。数字を扱う業務では、検算工程を必ず残してください。

取得できないデータは扱えない

当たり前ですが見落とされます。紙の書類、スキャン画像だけの帳票、個人のパソコンにしかないファイルは、MCPサーバーの対象になりません。データが電子化されていることが前提です。

判断そのものは任せられない

「与信を判断する」「発注を確定する」といった、責任の伴う判断は自動化の対象外です。情報を集めて整理するところまでがMCPの守備範囲であり、最後の判断は人が行う前提で設計してください。

頻度の低い作業には向かない

月1回、年数回といった頻度の作業は、設定と検証の手間が上回ります。素直に手で行ったほうが早い領域です。

古い社内システムでは接続手段がない

外部から読み取る手段（APIなど）を持たない古い基幹システムでは、そもそもサーバーを作れません。この場合は定期的にファイルへ書き出す仕組みを先に作るほうが現実的です。

データで見る国内の状況

導入判断の背景として、国内の状況を確認します。

利用は進み、方針は追いついていない

総務省「令和7年版 情報通信白書」によれば、日本において業務で生成AIを使用していると回答した割合は55.2%でした。一方、企業としての活用方針については「積極的に活用する方針」と「活用を検討中」の合計が49.7%で、前年の42.7%から増加しています（出典：総務省「令和7年版 情報通信白書」）。

同白書では、日本企業の半数以上が利用方針を明確に定めていないと回答したことも示されており、中小企業では大企業と比べて方針策定が進んでいない傾向が報告されています。

懸念の上位はセキュリティ

生成AI活用における課題・懸念としては、「効果的な活用方法がわからない」が1位、「社内情報の漏えい等のセキュリティリスク」が2位として挙げられています。

MCPサーバーの導入は、この2つに同時に効く可能性があります。接続先が明確になれば「何に使うか」が具体化し、権限を絞れば「どこまで見えるか」が管理可能になるためです。逆に、権限設計を飛ばすと2位の懸念をそのまま現実化させます。

モデルケース｜社内資料の集約（試算）

効果の目安を示します。以下は実在の企業ではなく、当社が想定する典型的な状況にもとづく試算です。

前提条件

• 従業員30名の専門商材の卸売業
• 対象は営業事務1名の作業
• 時給2,500円・月20営業日で換算
• 接続先は3つ（クラウドストレージ・受注管理・チャットの過去ログ）
• いずれも読み取り専用の権限で接続

導入前の状況

作業	頻度	1回あたり	月間
受注データと見積書の突き合わせ	毎日	30分	10.0時間
週次の実績レポート作成	週1回	90分	6.0時間
問い合わせ時の社内資料検索	週10件	15分	10.0時間
合計	—	—	26.0時間

実施したこと

1. 3つの接続先を選定し、読み取り専用の専用アカウントを作成
2. 個人情報を含むフォルダとテーブルは対象外に設定
3. まず1つ目（クラウドストレージ）だけを1か月試験運用
4. 問題がないことを確認し、残り2つを追加
5. 接続先台帳を作成し、月1回の棚卸しを設定

削減時間の試算

作業	導入前	導入後	削減
受注データと見積書の突き合わせ	10.0時間	3.3時間	6.7時間
週次の実績レポート作成	6.0時間	2.0時間	4.0時間
問い合わせ時の社内資料検索	10.0時間	3.3時間	6.7時間
検算・確認工程（新設）	—	2.0時間	2.0時間の増加
合計	26.0時間	10.6時間	15.4時間

月15.4時間の削減という試算になります。時給2,500円で換算すると月あたり約38,500円相当です。

試算の読み方

注意点を3つ書きます。

第一に、検算工程は削れません。AIが出した数字をそのまま使う運用は、遅かれ早かれ事故になります。この2.0時間は必要経費として見込んでください。

第二に、削減幅は「人が探しに行く頻度」に完全に比例します。上記のように毎日・週次の作業が積み上がっている場合に効果が出ます。月1回の作業しかない企業では、この数字にはなりません。

第三に、初月は削減されません。接続先の選定、権限の設定、試験運用に時間がかかります。効果が見え始めるのは2か月目以降です。

業種別の使いどころ

接続先の選び方を、業種ごとに具体化します。

卸売・小売

受注管理と在庫の突き合わせ、価格改定時の影響範囲の抽出が候補です。数字が別々のシステムに分かれている場合に効果が出やすい領域です。

製造業

図面や仕様書の検索、過去の不具合記録の参照が候補です。「似た案件が過去になかったか」を探す作業は、人がやると時間がかかり、かつ探し漏れが起きます。

建設・設備工事

現場ごとの写真・報告書・原価データが別々に管理されている場合、横断的な参照が候補になります。ただし紙が残っている工程は対象外である点に注意してください。

士業・コンサルティング

過去の案件記録、雛形文書の検索が候補です。守秘性が高い分野のため、接続先を1つに限定し、クライアント情報を含む領域は明示的に除外する設計が前提になります。

医療・介護

患者・利用者情報を含む領域への接続は推奨しません。シフト表、備品管理、社内規程といった非個人情報の領域に限定して始めてください。

広告・マーケティング業務

広告管理画面やSNSの数値を集約する用途は、MCPがもっとも効果を出しやすい領域の1つです。具体的な構成は広告・SNS・SEOをAIで自動化するとGoogle広告のMCP自動化にまとめています。

よくある質問（FAQ）

Q. MCPサーバーとは何ですか？

A. 特定のデータやツールを、AIから呼び出せる形で提供している小さなプログラムです。AI側のアプリがクライアント、データを差し出す側がサーバーにあたります。概念の全体像はMCPとはで扱っています。

Q. どんなサーバーがありますか？

A. 大きく4種類です。業務SaaSが公式提供するもの、開発・インフラ向けのもの、手元のパソコンで動くもの、自社で作るものです。中小企業がまず検討すべきは1つ目の業務SaaS系です。

Q. 無料で使えますか？

A. サーバー自体は無償公開されているものが多くあります。ただし、接続先サービスの利用料と、AI側の利用料は別途かかります。また設定・検証にかかる社内の時間も費用として見込んでください。

Q. 自社専用サーバーは必要ですか？

A. 最初は不要です。公式サーバーが存在する接続先から始めてください。自作を検討するのは、社内固有システムに週次以上の頻度で人が情報を取りに行っており、かつ保守担当が決まっている場合に限ります。

Q. 設定は難しいですか？

A. リモートサーバーへの接続であれば、コマンド1行と認証手続きで完了します。難しいのは設定作業ではなく、どこまで権限を渡すかを決める部分です。技術ではなく判断の問題として扱ってください。

Q. 社内システムにつなげますか？

A. そのシステムに外部から読み取る手段があるかどうかで決まります。手段がない古いシステムでは接続できません。その場合は、定期的にファイルへ書き出す仕組みを先に用意するほうが現実的です。

Q. 権限はどこまで絞るべきですか？

A. 最初は特定のフォルダまたはテーブルの読み取りのみです。MCP公式のセキュリティ文書でも、包括的な権限指定は避け、必要になった時点で段階的に引き上げる進め方が推奨されています。

Q. 情報漏えいのリスクは？

A. 権限を絞れば、そもそも見えない範囲は漏れません。加えて、出所の分からないプログラムを手元で実行しないこと、認証情報を複数のサーバーで使い回さないことが実務上の要点です。

Q. 誰が接続を管理すべきですか？

A. 情報システム担当、いない場合は経営層が承認者になってください。現場が個別に追加できる状態にすると、半年で把握不能になります。接続先の台帳を1つ作り、月1回見直す体制が最低ラインです。

Q. 動かないときはどうしますか？

A. まず一覧表示で接続状態を確認してください。認証待ちであればログイン手続きを行い、接続失敗であればURL・認証情報・ネットワーク制限の順に確認します。設定値の前後に余分な空白が混ざっている事例も報告されています。

Q. 仕様変更の影響を受けますか？

A. 公式サーバーを使っている場合、追随は提供元が行います。自作した場合は自社で追随が必要です。仕様は継続的に更新されており、2026年7月28日版でも設計上の変更が入っています。

Q. 何から始めればよいですか？

A. 週1回以上、人が手で情報を取りに行っている接続先を1つだけ選び、読み取り専用でつないでください。個人情報を含まない領域から始めるのが原則です。1か月使ってから次を判断します。

Q. 効果が出ない場合は？

A. 対象の選定を見直してください。接続先を増やすのではなく、「人が探しに行く頻度が高い作業」に対象を変えます。それでも効果が出ないなら、その業務はMCPに向いていないと判断して差し支えありません。

まとめ

• MCPサーバーはデータやツールをAIから呼び出せる形で提供するプログラム
• 担当者の仕事は作ることではなく、接続先・権限・管理者を決めること
• 選ぶ基準は公式提供・読み取り専用・正規の認証・週1回以上の業務頻度
• 接続はリモート方式が基本。出所不明のプログラムを手元で実行しない
• 設定の適用範囲（自分だけ・チーム共有・全案件）を意識して選ぶ
• 権限は包括指定を避け、段階的に引き上げる
• 接続用アカウントは分ける。認証情報は使い回さない
• 自社専用サーバーは保守担当が決まっていなければ作らない
• 接続先台帳を作り、月1回の棚卸しを行う
• AIの精度は上がらない。検算工程は必ず残す

MCPサーバーの導入は、技術的には難しくありません。難しいのは「どこまで見せるか」を決めて、それを維持し続けることです。最初の1本を読み取り専用で慎重に始めれば、その後の判断はずっと楽になります。

無料相談はこちら（初回のご相談・お見積りは無料です）

概念から確認したい方はMCPとは、開発環境についてはClaude Codeとは、社内ルールの整備は社内AIルールの作り方、他業務も含めた全体像は業務効率化のアイデア20選をご覧ください。