- MCPという言葉をよく聞くようになったけれど、結局何なのか説明できない
- MCPサーバーを導入すると何ができて、どう変わるのか、メリットがいまひとつピンとこない
- 自社でMCPサーバーを導入すべきか判断する材料が欲しい
- MCPサーバーを導入する場合、どんな観点を持つといいのかわからない
このような疑問や期待をお持ちではありませんか？
MCP（Model Context Protocol）とは、AIが社内データや外部ツールと安全に連携するための共通規格です。
この記事は非エンジニアの方に向けて、MCPの基本から、API連携やコネクタとの違い、実際のところ何ができるのか？導入の前と後で何が変わるのか？という基本知識。
情報システム部門の方に向けて、自社に必要かを見極めるチェックリスト、Claude Codeでの設定手順、セキュリティで押さえておきたい点も合わせてご紹介しています。
読み終えたころには、MCPについて聞かれても自分の言葉で説明ができる状態になり、
自社でMCPサーバーを用意すべきかの判断軸や進め方まで、イメージが見えてくるかと思いますので、是非ご参考にしていただけたら幸いです！
1. MCPとは？
これまでAIと社内システムをつなぐには、サービスごとに専用の処理を書く必要がありました。
つなぐ相手が1つや2つなら、それでも回りますが、AIに任せたい対象は年々増えていくと考えられ、そのたびに実装が増え、保守する対象も増えていき、この積み重ねが開発側の負担になっていました。
MCPは、その「つなぎ方」を一本のルールに決めてしまう規格で、一度実装すれば、別のAIツールからも同じ仕組みがそのまま使えます。
この規格に沿ってデータを渡したり処理を実行したりする側のプログラムを、MCPサーバーと呼びます。
公開は2024年11月。2025年12月にはLinux Foundation傘下に新設されたAgentic AI Foundation（AAIF）へ寄贈され、いまは特定の企業に紐づかないオープン標準として運営されています。Claude、ChatGPT、Geminiと主要なプラットフォームが対応を進めているのも、この流れの延長にあります。
2. MCPとAPI連携の違いと比較
これまでのAPI連携と何がどう違うの？と思われた方に向けて解説します。
APIは、あるサービスの機能やデータを外部のプログラムから呼び出すための窓口です。
ですが、呼び出し方も認証の作法もサービスごとに違います。
つなぐ相手が増えるたびに専用の実装が必要になるのは、この差異があるからです。
API連携（個別実装）での接続イメージ
MCPは、そのAPIをAIから扱えるようにするときの渡し方・見せ方を共通化した規格です。
なので、APIを置き換えるものではない、ということを覚えておきましょう。
APIの上に共通の作法を1枚かぶせるもの、と捉えると位置づけがはっきりします。
MCPサーバーの仕組みを簡単に表した概念図
では実際の運用で何が変わるのか？
差が出るのは、主に以下の3点です。
- 実装と保守の手間
- 複数のAIツールでの使い回し
- 権限管理のまとめやすさ
下の表は実装・運用面を軸にしたAPI連携とMCPの比較です。
主に窓口を作る側の負担がどう変わるかの話になりますが、使う側にとっても、なぜ1つ作れば他のツールでも使えるのかという疑問の答えになります。
| 比較軸 | API連携（個別実装） | MCP |
|---|---|---|
| 実装の手間 | 連携先サービスごとに個別実装が必要 | 共通規格に沿って一度実装すれば流用できる |
| 再利用性 | 他のAIツールでは流用できないことが多い | 複数のAIツールで共通利用できる |
| 認証・権限管理 | サービスごとに個別実装・個別管理 | MCPサーバー側で権限管理を一元化しやすい |
| 対応ツールの汎用性 | 特定の組み合わせに最適化されがち | 標準規格のため汎用性が高い |
| 更新・保守コスト | 仕様変更のたびに連携ごとに個別対応 | プロトコル準拠のため更新コストを抑えやすい |
ツールごとに複雑な連携プログラムを記述する手間を、規格側が担ってくれます。おおむねそのようなイメージで捉えておけば問題ありません。
3. MCPを使うと何ができるのか？
まずは使う側の視点で解説します。
自分でMCPサーバーを作らなくても、すでに公開されているMCPサーバーやコネクタを使えば、この章の内容は今日から試せます。
MCPを使うと、社内データベース、ローカルのファイル、GitHubやNotionといった外部ツールへ、AIを決まった作法で接続できるようになります。
公開されているMCPサーバーやコネクタでできること
- GitHub、Notion、Slackといった業務ツールの最新情報をAIに読ませて、分析や要約を任せられる。
- 同じ窓口をClaude Code、Codex、Cursorなど複数のツールに登録して、どれからでも同じデータを見に行く。
- GitHubの課題チケット、いわゆるIssueの作成やブラウザ操作を、AIチャットから直接実行させる。
- 参照させるフォルダを限定する、読み取り専用のアカウントでつなぐ、といった大まかな範囲の絞り込み。
自分のPCにあるファイルを読ませるだけなら、AIツール単体でも足ります。公開されている窓口を挟むと、その先の業務ツールや権限を絞った環境にまで手が届くようになります。
MCPサーバーを構築：公開されていない外部システムや自社データベースにつなぐとできること
- 自社の基幹システムや独自のデータベースを、AIから参照できるようになる。
- APIがある外部のCRMやMAツールを、AIから参照できるようになる。
- チーム全員が同じ窓口を使い、誰がどのデータを見られるかを窓口側で一元管理できる。
- 社内システムへの書き込み、たとえば申請の登録や在庫の更新まで任せられる。
- このテーブルのこの列だけ、この部署のデータだけ、という単位で制御するような設計ができる。
- 窓口経由の操作履歴を残し、いつ誰が何を実行したかを後から追える状態にする。
MCPサーバーを構築して実現できる利用シーンの事例
社内データベースへの接続をMCPサーバーとして一度整備してしまえば、Claude Code、Codex、Cursorと担当者の使うツールが違っても、同じように参照できます。
以下は、MCPサーバーとして整備した後の活用法の一例です。
複数のAIチャット環境からでも、AIのエディタから出ずに、社内データベースの情報をもとにした抽出と分析まで終わります。
MCPを活用した主な利用シーン
ツールごとに連携を作り込む作業がなくなり、4ステップほど踏んでいたデータの抽出と分析が、開発中の画面から出ずに終わります。GitHubのコードレビューや課題チケットの起票も、同じ窓口から任せられます。
会話するだけだったAIが、社内のデータやツールを操作して作業まで終わらせるようになる。
しかもその接続は一度作れば組織に残る。MCPの効きどころは、この2つです。
機密データが一切外に出ないわけではないので、どこまで渡すかの線引きは別で決める必要があります。この点は8章で扱います。
4. MCPサーバーの仕組み
ここから先は、MCPサーバーを用意する側の話になります。
公開されている窓口を使うだけなら3章までで足りますが、自社の環境につなぐ窓口を情報システム部門で持つ場合は、この章が前提になります。
最初に押さえておきたいのは、実装の細部よりも設計の勘所です。
- 登場人物
- 窓口が公開する中身
- 置き場所
この3つが決まれば、あとは作り方の話になります。
MCPサーバーとは？仕組みを3者の関係で理解する
MCPの全体像は「ホスト」「クライアント」「サーバー」の3者で整理できます。前の2つは利用者側の環境、最後の1つが情報システム部門で用意する対象です。
- ホスト：AIを利用するアプリケーション本体
Claude CodeやClaude Desktopがこれにあたります - クライアント：ホストとMCPサーバーの間で通信を仲介する接続係
ホストの内部で、MCPサーバー1つにつき1つ自動的に用意されます - MCPサーバー：実際にデータ提供やツール実行を行う窓口
つなぎたいシステムの数だけ用意します
MCPの仕組みの概念図
会社の受付に近い構図です。AIアプリという来訪者が、受付を通して各部署の窓口に用件を伝える。窓口の側は、来訪者が誰であれ同じ作法で受け付けます。ここが規格を使う意味です。
窓口が公開する中身は3種類
MCPサーバーが外に見せられるものは、次の3つに分かれます。どれをどこまで公開するかを決める作業が、そのまま権限設計になります。
- ツール：AIが実行できる処理。データの検索、レコードの更新、外部API呼び出しなど
- リソース：AIが参照できるデータ。ドキュメント、データベースの内容など
- プロンプト：あらかじめ用意しておく定型の指示テンプレート
参照だけを許すのか、更新まで許すのか。テーブル単位で切るのか、列や行の条件まで絞るのか。この判断を窓口の側で持てるところが、利用者のツール設定に任せる場合との違いになります。
置き場所は、ローカルに置くか、共有サーバーに置くか
MCPサーバーは動かす場所を選べます。実装の話に見えて、運用と統制の設計に直結します。
- ローカルに置く：担当者のPCや開発環境の中で動かす形です。標準入出力で通信するため、社内ネットワークの構成に手を入れずに検証できます。まず試す段階、特定の担当者だけが使う段階に向きます
- 共有サーバーに置く：サーバー上で動かし、複数の人が同じ窓口を使う形です。HTTPで通信し、接続時にOAuthなどの認証を挟めます。誰が何を使えるかを1か所で管理でき、利用履歴もまとめて残せます
検証はローカル、部署や全社で使う段階で共有サーバーへ。この順に育てるのが現実的です。共有側に移した時点で、認証、権限、ログの3点が情報システム部門の管理対象になります。
AIが窓口を使うまでの流れ
窓口を用意してからAIが動き出すまでは、以下の流れになります。
- 接続する：AIアプリが窓口につながり、お互いに何ができるかを確認する
- 一覧を受け取る：窓口が「できることの一覧」を返す。それぞれに名前、説明、必要な情報が添えられている
- 選んで依頼する：AIが目的に合うものを選び、必要な情報を添えて実行を依頼する
- 結果を受け取る：窓口が実行し、結果を返す。AIはそれを次の作業の材料にする
ここが設計上いちばん重要な点です。
AIは窓口の使い方を事前に教え込まれていなくても、渡された一覧を読んでその場で使えます。
つまり窓口に機能を追加すれば、利用者側のツールを改修しなくてもその機能が使えるようになります。運用の負担が下がる理由はここにあります。
同時に、一覧に載せた機能はAIが自分で選んで実行できるということでもあります。載せるかどうかの判断を軽く扱えない理由も同じところにあります。この点は8章で扱います。
5. MCPサーバーの構築手順（Claude Codeを使っている環境の例）
Claude Codeを標準の開発環境にしている組織を想定して、自社の窓口を用意して配るまでの流れをまとめます。検証から全社展開まで、段階を分けて進めるのが前提です。
MCPサーバーの構築手順の例
手順1：公開する範囲を決める
つなぐ相手のシステムを決めたら、そこから何を見せて何を実行させるかを先に確定させます。参照のみか更新まで含めるか、どのテーブルやエンドポイントを対象にするか、誰が使うのか。ここが曖昧なまま実装に入ると、あとから権限を絞り直す作業が発生します。
手順2：既存の公開サーバーで代替できないか確認する
自社のシステムでも、標準的なデータベース製品やSaaSであれば、公開されているMCPサーバーがすでに存在する場合があります。まず既存のものを試し、権限の絞り方や項目の見え方が要件に合わなければ自社実装に進む。この順のほうが手戻りが減ります。
手順3：MCPサーバーを実装する
実装には公式のSDKが用意されています。ローカルで動かす前提なら標準入出力、共有サーバーに置く前提ならHTTPで通信する形を選びます。開発中の動作確認には、公式のMCP Inspectorのような検証ツールが使えます。
手順4：手元で動作確認する
できあがった窓口を、まず担当者の環境だけに登録して確かめます。Claude Codeなら「claude mcp add」コマンドで登録し、「claude mcp list」で接続状態を確認します。接続済みなのか、認証が必要なのか、失敗しているのかが表示されます。Claude Codeの中からは「/mcp」でも状態を見られます。
手順5：チームに配る
配布の要になるのが登録先の範囲、いわゆるスコープです。Claude Codeには3種類あります。
| スコープ | 読み込まれる範囲 | 共有 | 情報システム部門から見た使いどころ |
|---|---|---|---|
| ローカル（既定） | 登録したプロジェクトのみ | 自分だけ | 検証、個人の実験 |
| プロジェクト | そのプロジェクトのみ | 設定ファイル（.mcp.json）をバージョン管理で共有 | チーム全員に同じ窓口を配る |
| ユーザー | 本人のすべてのプロジェクト | 自分だけ | 常用ツールを担当者ごとに持たせる |
チームに同じ窓口を使わせるなら、プロジェクトスコープで設定ファイルをリポジトリに置きます。
認証情報を直接書き込まずに済むよう、設定ファイル内で環境変数を参照する書き方も用意されています。なお、リポジトリから読み込まれた窓口は、対話的な利用時に承認を求める設計になっています。使わせたくない窓口を明示的に無効化する設定もあります。
手順6：組織全体に展開する
部署をまたぐ規模になると、管理者が組織向けの構成として配布する形が使えます。誰にどの窓口を有効にするかを利用者任せにせず、管理側で揃えられます。あわせて、利用状況の確認方法と、窓口を止めるときの手順も先に決めておきます。
進め方について、検証から全社展開まで一気に進めないほうが安全です。
ローカルで数人が使う状態を2〜3週間続けると、必要な権限の範囲と、逆に不要だった機能が見えてきますので、その状態で共有サーバーへ移すと、権限設計をやり直す回数が減りますのでお勧めです。
6. MCPサーバーの導入で運用管理はどう変わるか?
情報システム部門の日々の作業に絞って、導入前と導入後を並べます。
効果が出るのは連携を作る場面よりも、むしろ増えたあとの管理の場面です。
| 運用の場面 | 導入前（個別のAPI連携） | 導入後（MCPサーバー） |
|---|---|---|
| 新しいシステムをAIにつなぐ | つなぐ相手とAIツールの組み合わせごとに連携を作り込む | 窓口を1つ作れば、対応するAIツールから共通で使える |
| AIツールを増やす、乗り換える | 連携をツールごとに作り直す | 既存の窓口をそのまま登録して使う |
| 権限の管理 | 連携先ごとに設定が散らばる | 窓口単位で、公開する機能とデータの範囲を管理する |
| 認証情報の管理 | 連携処理ごとに保管場所と更新手順が分かれる | 窓口側に集約し、環境変数や秘密情報の管理機構に預ける |
| 利用状況の把握 | どの連携が使われているか追いにくい | 窓口経由の操作履歴として記録を残せる |
| 退職や異動のときの棚卸し | 各担当者の環境に入った連携設定を個別に確認する | 共有サーバー側でアクセス権を止める |
| 監査や社内説明 | 連携ごとに仕様と権限を説明する | 窓口の一覧と、公開している機能の一覧で説明できる |
現場から見た変化を一言にすると、管理対象が「連携の数」から「窓口の数」に変わるという話です。連携が10本あっても、つなぐ相手が3システムなら窓口は3つ。棚卸しの単位が減ります。
7. 自社にMCPサーバーが必要か判断するチェックリスト
MCPサーバーが必要か判断チェック
MCPサーバーの構築は、どの組織にも今すぐ必要な投資ではありません。次の項目と自社の状況を照らしてみてください。
- ✅ 自社の基幹システム、独自データベース、コネクタ未対応の外部SaaSなどにAIを繋ぎたい
- ✅ 参照させる範囲を、テーブルや項目の単位で自社ルールに沿って絞る必要がある
- ✅ 複数の部署や担当者が、同じデータソースを同じ手順で使う見込みがある
- ✅ AIツールを複数使っている、または今後入れ替わる可能性が高い
- ✅ AIからのアクセス権限と操作履歴を、部門として一元管理したい
- ✅ 各担当者が個別にAI連携を作り始めており、把握できていない状態になりつつある
- ✅ API連携の保守や仕様変更対応の工数が、担当者の負荷として見えてきている
2〜3個以上当てはまるなら、窓口を1つ用意する検討に入る段階と考えてみると良いでしょう。
当てはまらない場合は、3章で触れた公開されているMCPサーバーやコネクタで足りる可能性が高いです。
8. MCPサーバーのセキュリティの注意点
MCPサーバーは、AIに社内システムへのアクセス権限を渡す仕組みです。
構築と運用で押さえておきたいのは次の6点です。
- 公開する機能を必要な範囲に絞る
参照だけで足りるなら更新の機能は載せません。窓口に載っていない操作はAIから実行できないため、ここが最初の防御線になります - 接続先の権限も併せて絞る
窓口が使うデータベースのアカウントを読み取り専用にする、参照できるスキーマを限定する。窓口側の設定と接続先の権限は二重で効かせます - 認証情報をコードに書かない
APIキーやトークンは環境変数や秘密情報の管理機構に預けます。設定ファイルをリポジトリで共有する場合は、そこに実際の値が入らない書き方にします - 提供元が不明なMCPサーバーを社内環境に入れない
公開されているものを使う場合も、提供元と更新状況を確認します。利用者が各自で追加できる状態のままにせず、部門として可否を判断する運用にします - プロンプトインジェクションを想定する
外部から読み込んだデータの中に「〜を実行して」といった不正な指示が混ざり、AIがそれに従うリスクです。取り消しの効かない操作は窓口に載せない、実行前に確認を挟むなど、設計側で歯止めをかけます - 操作履歴を残して追える状態にする
いつ、誰の依頼で、どの操作が実行されたか。監査で聞かれる項目を最初から記録に含めておきます
どれも新しい話ではありません。AIに権限を渡すときは、人に権限を渡すときと同じ手順を踏む。既存の権限管理の運用に載せられるかどうかが、判断の分かれ目になります。
9. よくある質問（FAQ）
Q. MCPサーバーとは何をするものですか？
A. AIからの要求を受け取り、ツールの実行やデータの提供を行う窓口役のプログラムです。
つなぎたいシステムの数だけ用意します。担当者のPC内でも、共有サーバー上でも動かせます。
Q. MCPサーバーの構築には何が必要ですか？
A. つなぐ相手のシステムにAPIなどの入口があること、公開する範囲を決めること、実装と運用を担う体制の3つです。
実装自体は公式のSDKを使えるため、ゼロから通信のしくみを作る必要はありません。
Q. 自社で作らずに済むケースはありますか？
A. つなぎたい相手に公開されているMCPサーバーやコネクタがあり、そこで権限の絞り方も要件を満たすなら、自社構築は不要です。
一覧に無い相手につなぐ場合や、参照範囲を自社ルールで細かく制御したい場合が構築の検討ラインになります。
Q. 既存のAPI連携は作り直しになりますか？
A. いいえ。MCPはAPIを置き換える規格ではありません。既存のAPIの上に、AIから扱うための共通の作法をかぶせる位置づけです。
既存の連携をそのまま残しつつ、AIから使う部分だけ窓口を用意する形も取れます。
Q. ローカルと共有サーバー、どちらから始めるべきですか？
A. 検証はローカルから始めるのが安全です。担当者のPC内で動かす形なら、ネットワーク構成に手を入れずに試せます。
部署や全社で使う段階になったら共有サーバーへ移し、認証、権限、ログの管理を情報システム部門側に寄せます。
Q. チーム全員に同じ窓口を使わせる方法は？
A. Claude Codeなら、プロジェクトスコープで設定ファイルをリポジトリに置く形が基本です。組織規模で配る場合は、管理者が組織向けの構成として配布する方法もあります。
Q. AIに渡したデータは外に出ますか？
A. 生データ全体を渡さず必要な部分だけを渡す設計はできます。ただしAIに渡した内容と、そこから作られた回答はクラウド側のモデルに送られます。
機密データが一切外に出ないわけではないため、何をどこまで渡すかの線引きは窓口の設計時に決めてください。
Q. セキュリティで最初に決めるべきことは？
A. 窓口に載せる機能の範囲です。載っていない操作はAIから実行できないため、公開範囲を絞ることがそのまま最初の対策になります。
そのうえで、接続先アカウントの権限、認証情報の保管方法、操作履歴の記録を決めます。
Q. 導入効果はどこに出ますか？
A. 連携を作る場面よりも、増えたあとの管理の場面に出ます。管理対象が連携の数から窓口の数に変わるため、権限の棚卸しや監査対応の単位が減ります。
まとめ
この記事では、MCPの基本とAPI連携との違いから、どんなことがMCPでできるのかの基礎知識と、情報システムの担当者向けに自社でMCPサーバーを構築する場合の仕組み、手順、運用管理の変化、判断基準、セキュリティまでを解説しました。
統合されたデータアクセスにより、AI活用がスムーズになるMCPのイメージ
自社の状況が7章のチェックリストに当てはまるなら、まずは1システム分の窓口をローカルで試すところから始めてみるのが良いかと思います。
使う担当者の声を要件に反映させながら共有サーバーへ移すと、権限設計のやり直しを抑えられます。もし、MCPサーバーを構築したAI活用の構想があるのに、システム担当者のリソース不足や設計への不安などがあり、なかなか前に進められない課題などがございましたら、お気軽にFLINTERSまでご相談ください。ご依頼の有無に関わらず一歩でも前進するようご対応させていただきます。
