MCPを使うと何が新しくできるようになりますか？

できること自体が増えるというより、つなぎ方が共通化されます。公式ドキュメントはMCPをAI向けのUSB-Cポートにたとえていて、これまで各ツールごとに個別対応していた接続を、同じ形の差し込み口で扱えるようにするものです。結果として、対応済みのツールを組み合わせる手間は減ります。

MCPとRAGは競合する技術ですか？

競合しません。RAGは社内文書を検索して読ませる方法、MCPはAIと外部システムをつなぐ接続の規格です。MCP経由で社内の検索システムにつなぐ、といった形で組み合わさることもあります。

MCPを使うにはプログラミングが必要ですか？

自分でサーバーを作る場合は必要です。ただし既に用意されているものをクライアント側で有効にするだけなら、設定作業に近い範囲で済みます。私は、まず既存のものを1つだけ有効にして挙動を見るところから始めました。

MCPとは｜AIに社内ツールをつなぐ仕組みと、使う前に決めること

結論から言うと、MCPは「AIと外部のツールやデータをつなぐときの、差し込み口の形を揃えた規格」です。公式ドキュメント自体が「AIアプリケーションにとってのUSB-Cポート」というたとえを使っていて、この説明が一番実態に近いと思います。

私がMCPを触り始めたのは、AIに社内の情報を見せる方法を調べていたときです。名前が抽象的で身構えましたが、中身は「つなぎ方の作法を決めただけ」でした。ただし、つながる範囲が広がるぶん、決めておかないと危ない話も一緒についてきます。

結論

✅ ここだけ読めばOK

MCPは新しいAIではなく、接続の規格。プロトコルであって、賢さは増えない
標準化されたのは「差し込み口」。同じ形にしたことで、対応ツールを組み合わせやすくなった
使う前に決めるのは技術ではなく承認。AIが操作できる範囲をどこで止めるか

MCPを入れれば社内業務が自動でつながる、という期待で始めると、たいてい「権限をどうするか」で止まります。私も、動かすところより、動かしていい範囲を決めるほうに時間を使いました。

MCPが標準化したもの

MCPは Model Context Protocol の略で、公式にはAIアプリケーションを外部システムに接続するためのオープンな規格と説明されています。通信には JSON-RPC 2.0 が使われます。

登場人物は3つです。

役割	何をするか
ホスト（Hosts）	接続を始めるAIアプリケーション本体
クライアント（Clients）	ホストの中にある、接続を担当する部分
サーバー（Servers）	文脈や機能を提供する側。データやツールを出す

サーバー側がクライアントに提供できるものは、公式仕様では次の3種類に整理されています。

Resources: 利用者やAIモデルが使うための文脈・データ
Prompts: 定型のメッセージやワークフロー
Tools: AIモデルが実行できる関数

逆にクライアント側からサーバーに提供できるものとして、Sampling（サーバー起点でのLLM呼び出し）、Roots（作業してよい範囲の問い合わせ）、Elicitation（利用者への追加情報の要求）が定義されています。

なぜ規格にする必要があったのか

公式仕様は、MCPが Language Server Protocol（LSP）から着想を得ていると書いています。これは腑に落ちる説明でした。

LSPが出てくる前は、「この言語をこのエディタで使うための対応」を組み合わせの数だけ作っていました。エディタが5つ、言語が10あれば50通りです。LSPは間に共通の規格を挟んで、これを5＋10に減らしました。

MCPがやろうとしているのも同じ構図です。AIアプリが何種類もあり、つなぎたい社内システムも何種類もある。その掛け算を、共通の差し込み口で足し算に近づける。「新しくできるようになったこと」より「同じことをやる手間が減ったこと」が本質だと理解しています。

対応している製品

公式ドキュメントでは、Claude や ChatGPT といったAIアシスタント、Visual Studio Code や Cursor といった開発ツールが対応していると案内されています。つまり、特定の1社の中だけで閉じた仕組みではありません。

この点は、採用を検討するときに効いてきます。1社の独自機能だと、その会社の方針変更で作り直しになりますが、複数の実装がある規格ならその危険は下がります。

RAGやAIエージェントとの関係

同じ文脈で語られるので混ざりやすいのですが、レイヤーが違います。

	何をするものか
RAG	社内文書を検索して、抜粋をAIに読ませる「方法」
AIエージェント	目的を渡すと、手順を自分で組み立てて動く「動き方」
MCP	AIと外部システムをつなぐ「接続の規格」

3つは並列の選択肢ではなく、重なります。MCP経由で社内の検索システムにつないでRAGを実現する、という組み合わせもあり得ます。エージェントが外部ツールを呼ぶときの呼び方としてMCPを使う、という関係もあります。

それぞれの中身は、RAGとはとAIエージェントとはのほうで書きました。この記事は「つなぎ方」の話に絞ります。

使う前に決めること

ここからが本題です。私が実際に詰まったのは、動かす手前の判断でした。

AIが実行できる操作の範囲

MCPのTools（AIが実行できる関数）は、要するにAIが外部で何かを実行できるということです。公式仕様も、この点をはっきり警告しています。ツールは任意のコード実行の経路であり、相応に慎重に扱うべきである、と。

読み取りだけの操作と、書き込み・送信・削除を伴う操作は、性質がまったく違います。私は最初、この区別をせずにまとめて有効にしてしまい、AIが良かれと思って下書きを上書きしたところで手を止めました。実害は出ませんでしたが、範囲を絞らずに始めたのは判断ミスでした。

⚠️ 注意点

最初に有効にするのは読み取り系の操作だけにしてください。ファイルの書き換え、メールやチャットの送信、外部への発注や課金にかかわる操作は、実行前に人が承認する形にするか、そもそも渡さない。取り消せない操作をAIに握らせないのが、いちばん単純で確実な安全策です。

誰の権限で動いているのか

MCPサーバーは、つないだ先のシステムに何らかの資格情報でアクセスします。ここで「誰の権限で動いているか」を意識しておかないと、本人には見えないはずの情報に、AI経由で手が届く状態が簡単にできます。

社内で使うなら、AIに渡す権限はその利用者本人が元から持っている範囲を超えないようにするのが基本です。管理者権限のアカウントで一括して動かすと、便利ですが、権限設計が事実上無効になります。

情報の扱い全般は生成AIの情報漏洩対策、社内ルールの整備は社内AI利用ガイドラインの作り方のほうで整理しています。

つなぐ相手を信頼できるか

見落としやすいのがここでした。公式仕様には、ツールの動作説明（アノテーションなど）は、信頼できるサーバーから得たものでない限り、信頼できないものとして扱うべきという記述があります。

つまり、「このツールはファイルを読むだけです」という説明文自体が、嘘である可能性を織り込めということです。説明を読んでAIが判断する構造なので、説明に細工がされていれば、AIの判断もそちらに引きずられます。

これは、外部から渡された文章でAIの動作を歪める攻撃と同じ形です。プロンプトインジェクション対策で書いた「外から来た文字列を指示として扱わせない」という考え方が、そのまま当てはまります。

素性の分からないサーバーを、業務データが見える環境で有効にしない。これだけは崩さないほうがいいと考えています。

承認の出し方を決める

公式仕様は、利用者の明示的な同意と制御を原則として挙げています。ツールを呼ぶ前に利用者の同意を得ること、何が共有され何が実行されるかを利用者が理解できることが求められています。

運用上の問題は、毎回確認を出すと人が読まなくなることです。私も、確認ダイアログが連続で出た結果、中身を見ずに承認していた時期がありました。これでは承認の意味がありません。

読み取り系は都度確認を省き、取り消せない操作だけ必ず止める。粒度を分けたほうが、結果的に承認が機能します。

💬

はじめは「全部確認してくれるなら安全だろう」と考えていました。実際には、確認の回数が増えるほど中身を読まなくなる。安全側に倒したつもりの設計が、いちばん危ない状態を作っていたわけです。確認は減らして、止めるところを絞るほうがうまくいきました。

まだ向いていない場面

期待が先行しているぶん、合わないところで使うと手間だけが増えます。私が見送ったのは次のケースです。

つなぎたい社内システムが対応していない：自分でサーバーを作る必要があり、そこまでの労力に見合わないことが多い
操作が失敗したときの影響が大きい：基幹システムへの書き込みは、人が実行するほうが安全
手作業が月に数回しかない：接続の設計と維持のほうが高くつく
社内の承認ルールが決まっていない：技術より先に、ここが止まる原因になる

最後が一番多いです。MCPの導入は、AIにどこまで任せるかという判断を先送りする方法にはなりません。むしろ、決めていないことがそのまま設定画面に出てきます。

小さく試すなら

いきなり業務データにつながず、次の順にしています。

読み取りだけのサーバーを1つ有効にする（対象は業務外のデータ）
AIに何が見えているかを、実際に質問して確認する
書き込み系を1つだけ追加し、承認の出方を見る
取り消せない操作を、意図的に依頼して止まるか試す
止まらなかったら、その操作は渡さない

4を飛ばさないほうがいいです。止まると思っていたところで止まらなかった、というのは実際に起きます。試すなら、壊れて困らないデータで先に確かめておくほうが安全でした。

こうした接続の設計や、社内での権限・承認の切り方まで含めて体系的に押さえたい場合は、講座で一度整理する選択肢もあります。個人で試すぶんには独学で足りますが、組織に入れる話になると、運用設計まで手が回りにくいところです。

MCPのような仕組みは、ツール連携や業務システム開発の経験と相性がよい領域です。実際の案件要件を見ると、API連携、認証、権限設計、運用保守のどこが評価されるかを具体的に把握できます。

MCP周辺の開発経験が活きる案件を確認する公式サイトへ移動します

実務でのAI活用を体系的に学ぶ選択肢を見る

私の結論

MCPは、AIと外部システムをつなぐ差し込み口の形を揃えた規格です。AIが賢くなるものではなく、届く範囲が広がるものだと理解しておくと、判断を間違えにくいと思います。

届く範囲が広がるということは、間違えたときの影響も広がるということです。だから、有効にする前に「取り消せない操作は渡さない」「本人の権限を超えさせない」「素性の分からないサーバーはつながない」の3つだけ先に決めました。この3つを守っている限り、試して困ったことは今のところありません。