MCPとは？仕組み・できること・RAGやAPIとの違いと注意点

前の家に住んでいたとき、玄関の鍵をスマートロックに変えました。アプリで開けられるようになります。

便利でした。ただ、半年ほど経って気づいたことがあります。私はほとんど、鍵で開けていました。

アプリを開いて、通信を待って、解錠を押す。その手順より、ポケットから鍵を出すほうが速い。 アプリが悪いのではありません。私の手が、既に鍵に伸びていただけです。
半年で数えたら、アプリで開けたのは10回ほど、鍵で開けたのは400回以上でした。

先に一行だけ置きます。MCPとは Model Context Protocol の略で、AIと外部のデータや道具を繋ぐための共通の作法のことです。AIと厳密なAPIをつなぐ標準化のコンセプトですが、実務では「MCPサーバー」という形で、AIクライアントに機能を足す拡張のような意味で使われることが多くなっています。

題材は、社内のナレッジをAIから検索できるようにする仕組みです。議事録、案件記録、過去の設計。散らばっているものを、聞けば出てくる状態にする。

前置きはさておき、本題に入ります。

今日は、この仕組みを全社に開くときに、専用の画面を作るのをやめた話をしていこうと思います。

① 教科書どおりに、専用の画面を作ろうとする

MCPとは

MCPとは Model Context Protocol の略で、AIと、外部のデータや機能をつなぐための共通の決まりごとです。2024年にAnthropicが公開し、仕様とSDKが誰でも使える形で出ています。

例えるなら、周辺機器をつなぐ差込口の規格です。差込口の形が統一されていれば、機器ごとに専用の配線を作らずに済みます。MCPは、その「形」をAIと外部システムのあいだで決めたものです。

なぜMCPが必要になったのか

MCPが出てくる前は、AIアプリと外部サービスの組み合わせごとにつなぎ込みを作っていました。AIアプリがM個、つなぎたいサービスがN個あれば、必要な実装はM×N個になります。

MCPを挟むと、AIアプリ側はMCPに対応するだけ、サービス側もMCPに対応するだけになり、M＋N個で済みます。これが、MCPが解こうとしている問題のほぼすべてです。

もう1つ、実務側の理由があります。AIの賢さが上がっても、社内のデータに触れないAIは業務に使えません。「賢さ」より「つながるか」が先に効く、という状況が背景にあります。

MCPの基本構造｜ホスト・クライアント・サーバー

登場するのは3つです。

	役割	具体例
ホスト	AIを動かしている側のアプリ	AIチャットのアプリ、コードエディタ
クライアント	ホストの中で、サーバーとやりとりする部分	ホストに内蔵されている
サーバー	データや機能を提供する側	社内ファイル、チャット、データベース、業務システム

作る側が用意するのは、ふつう「サーバー」だけです。ホストとクライアントは既存のAIアプリが持っています。

MCPサーバーとは

MCPサーバーとは、自分たちのデータや機能を、MCPの決まりごとに沿って外へ差し出すプログラムです。公開のサーバーとして外に出すこともできますし、社内だけで動かすこともできます。

「サーバー」という語からハードウェアを想像しますが、実体は小さなプログラム1本です。手元のパソコンで動かす形も、標準の使い方に含まれています。

MCPサーバーが提供する3つの機能

サーバー側が用意できるものは、大きく3種類に決まっています。

• ツール — AIが呼び出して実行できる処理。検索、登録、集計など
• リソース — AIが読み取れるデータ。ファイル、レコード、ログなど
• プロンプト — 使い方の型。利用者が選べる定型の指示として提供する

実務でいちばん使うのはツールです。そして、ツールに付ける説明文が、実質的に「いつ呼ばれるか」を決めます。説明文の書き方が、そのままAIの振る舞いになります。

MCPクライアントの役割とSDK

クライアント側は、サーバーを見つけ、つなぎ、どんなツールやリソースがあるかを一覧で受け取り、AIへ渡します。

仕様が公開されているだけでなく、主要な言語のSDKも公開されています。そのため、サーバーを1本作るのに必要な手間は、かつての専用連携より大幅に小さくなっています。

MCPの仕組み｜1回のやりとりで何が起きるか

順番はこうです。

• ホストが起動時にサーバーへつなぎ、使える機能の一覧を受け取る
• 利用者が自然な言葉で頼む
• AIが、一覧の中からどの機能を使うかを選ぶ
• クライアント経由でサーバーへ呼び出しが飛ぶ
• サーバーが結果を返し、AIが文章にして返す

3番目が要点です。「どれを使うか」を人が指定しないので、機能の説明文が曖昧だと、意図しないものが呼ばれます。

メリット1｜つなぎ込みの数が減る

前述のM×NがM＋Nになります。効いてくるのは、つなぐ先が増えたときです。3つ目、4つ目を足すときの手間が、そのまま差になります。

メリット2｜専用の画面を作らずに使い始められる

利用者は、すでに使っているAIアプリからそのまま呼び出せます。ログイン画面も、検索窓も、一覧の表示も作らずに済みます。

ここが、社内ツールを作る側にとっていちばん大きい変化です。作るものが「画面＋認証＋権限＋検索体験＋中身」から、「中身＋権限」へ減ります。（この記事の後半は、この話です）

メリット3｜よく知らないサービスも、自然な言葉で扱える

操作方法を覚えなくても、「先月の請求で未入金のものを出して」と頼めば、AIが該当する機能を選んで呼びます。利用者への説明コストが下がります。

メリット4｜つないだり外したりが簡単

一度環境を用意すれば、設定ファイルの記述を足す・消すだけでサーバーの付け外しができます。試して合わなければ外す、が現実的にできる形になっています。

メリット5｜AIが、最新の情報と社内の知識を参照できる

学習済みの知識だけでは、社内の事情も最新の状況も答えられません。MCPでつなぐと、その場で実データを読みにいけます。

メリット6｜仕様とSDKが公開されており、作りやすい

仕様が公開され、複数の主要なAI事業者が採用を表明しています。特定の1社に閉じた仕組みではないため、作ったサーバーを別のAIアプリからも使える見込みが立ちます。

MCPとRAGの違い

よく混同されますが、層が違います。

	何をするもの	関係
RAG	答える前に資料を検索して、参考として渡す手法	「何を渡すか」の話
MCP	AIと外部システムのつなぎ方の規格	「どうやって取りに行くか」の話

対立するものではなく、RAGの取得部分をMCPで作ることができます。どちらかを選ぶ、という問いの立て方が、そもそも噛み合っていません。

MCPとA2Aの違い

A2A（Agent to Agent）は、AIエージェント同士がやりとりするための規格です。

• MCP — AIと道具・データをつなぐ
• A2A — AIと別のAIをつなぐ

つなぐ相手が違うだけで、併用できます。

MCPとAPIの違い

MCPは、APIを置き換えるものではありません。APIの上に、AIから扱いやすい形の共通の口をかぶせるものです。

違いは3つあります。機能の一覧をAIが自分で取得できること、それぞれの機能に自然文の説明が付いていること、そして呼び出し方がサービスをまたいで揃っていること。この3つがあるため、AIが「どれを呼ぶか」を自分で決められます。

活用例｜社内のファイルやチャットを検索する

社内のファイル置き場やチャットをMCPサーバーとしてつなぐと、手元のAIアプリから横断して探せます。「あの見積の元になった仕様、どこだっけ」に答えられる形になります。

活用例｜手元のAIアプリから、業務システムを呼ぶ

在庫、案件、勤怠。既存システムのAPIをMCPサーバーで包むと、新しい画面を作らずに、AIから読み書きできます。

書き込みを含めるかどうかは、慎重に決めてください。最初は読み取りだけにして、運用で問題が出ないことを確かめてから広げます。

注意点1｜セキュリティ

MCPはAIに社内のデータと機能への入口を渡す仕組みです。決めておくのは3点です。

• 権限 — サーバーが持つ権限を、必要な範囲だけに絞る。最初は読み取りのみが安全
• 信頼できるサーバーか — 公開されているサーバーをそのままつなぐと、中で何をしているかは見えない
• 記録 — 誰が、どのツールを、いつ呼んだかを残す

外部の文章に指示が仕込まれている場合（プロンプトインジェクション）、AIがそれを読んで意図しない処理を呼ぶ経路があります。送信や削除のように取り返しがつかない処理には、人の承認を挟んでください。

注意点2｜学習コストと、運用の担当

概念は単純ですが、作るのも運用するのもエンジニアの仕事です。サーバーが落ちたとき、権限を足すとき、ツールの説明文を直すときに動く人を決めておかないと、入れた翌月に止まります。

注意点3｜エコシステムがまだ動いている

仕様も、周辺のツールも、まだ変わります。いま作ったサーバーが、そのままの形で長く使えるとは限りません。

その前提で、作るものを小さくしておくのが現実的です。仕様が変わっても、書き直す量が小さければ追随できます。

MCPを入れる前に決めておくこと

技術の前に、次の4つを決めてください。

• 誰が使うか — 全社か、特定の部署か
• 読み取りだけか、書き込みも含めるか
• 見えてよい範囲 — 既存システムの権限をどう引き継ぐか
• 止め方 — 問題が起きたとき、誰がどうやって切るか

3つ目が、いちばん手間がかかります。既存システムの権限をそのまま持ち込めない場合、ここだけは作る必要が残ります。

社内システムの教科書どおりに設計していました。

→ 専用のフロントエンドを作る
→ そこにログインを付ける
→ 検索窓を置いて、結果を並べる
→ 権限で見えるものを分ける
→ 使い方を説明して回る

まっとうな設計です。 誰が見ても分かるし、画面があれば説明もしやすい。
このとき見積もっていた作るものは5つでした。画面、認証、検索体験、権限、保守。このうち4つは、ナレッジ検索そのものではありません。
見積もりの内訳も置いておきます。画面が3週間、認証が1週間、権限が1週間、検索体験が2週間。 中身の実装は、そのうち1週間分でした。

ここまでは、教科書どおりです。

見積もりの内訳はこうでした。画面に15日、認証に5日、権限に5日、検索体験に10日。 中身の実装は、そのうち5日分です。

この記事の後半で扱うのは、上の「作らずに済む」が見積書の上でどう見えていたかです。当時の私は、MCPという選択肢を知らないまま、5つのうち4つを作る前提で日数を積んでいました。

② そのとおりに進めて、作る量が増えていく

ところが、設計を進めるほど作るものが増えていきました。

画面を作ると決めた瞬間に、画面の周りが全部ついてきます。

→ ログイン → 認証をどう持つか
→ 検索窓 → 検索体験をどう作るか
→ 結果の並び → どう見せるか
→ 全部 → 誰が保守するか

しかも、これらはナレッジ検索そのものとは関係ありません。 中身は「聞いたら出てくる」だけなのに、外側だけが膨らんでいきます。

そして、もう一つ問題がありました。使ってもらうには、そこへ行ってもらう必要があります。

社内の人は、既にAIのクライアントを開いています。そこから離れて、別の画面へ移動してもらう。 その一手間を、毎回踏んでもらわないといけません。

スマートロックのアプリと同じでした。
移動の一手間を数えると、画面を開く、ログインする、検索窓に入れる、結果を読むの4手順。AIクライアントから引ければ、1手順で済みます。

移動の手数を数えると4回です。画面を開き、ログインし、検索窓に入れ、結果を読む。AIクライアントから引ければ1回で済みます。

③ そして、MCPなら画面が要らないと気づく

MCPは、AIクライアントの側から接続する作法です。

つまり、こうなります。

→ 利用者はいま使っているAIをそのまま使う
→ そこから社内ナレッジが引ける
→ 移動しなくていい

専用の画面が要りません。 正確には、画面はもう相手が持っているので、こちらが作る必要がない。

そして提案が出ました。

初期フェーズでは、独自フロントエンドの実装を一旦見送り、MCP接続による利用を主軸とする。

④ 原因は「入口を作ること」と「境界を決めること」を一緒にしていたこと

判断を一つに絞ると、これでした。

私たちは、入口を作ることと、境界を決めることを、同じ作業だと思っていました。

画面を作れば、そこにログインが付き、権限が付きます。入口と境界が、同じ場所に置かれる。 だから「画面を作らないと権限も作れない」と思い込んでいました。

分けられます。

→ 入口 — 相手が既に持っている（AIクライアント）
→ 境界 — こちらが持つ（誰が、どのフォルダを読めるか）

こちらが持つべきなのは、境界だけでした。
分けた結果を表にすると、こうなります。

もの	誰が持つか
入口（画面）	相手が既に持っている
認証	相手側に乗る
境界（権限）	こちらが持つ

⑤ 直してみる — 管理画面を、2つの機能だけに絞る

やったことは3つです。

1. 独自フロントエンドを、初期フェーズから外した。
作らないと決めました。やめる判断のほうが、作る判断より難しいのは毎回同じです。

2. 管理画面を、APIキー発行とフォルダごとの権限管理だけに絞った。
検索体験も、結果の見せ方も、こちらは持ちません。持つのは「誰が、どこを読めるか」だけです。

3. キーを、利用者が自分で発行できるようにした。
管理者が一人ずつ登録していくと、そこが詰まります。利用者が自分で発行し、承認する側が権限を設定する流れにしました。

そして、外した選択肢も書いておきます。仮想マシン上でアカウントを共有する構成と、ローカルLLMを共有ホスティングする構成は、規約上の制約と初期検証コストの観点から、現時点では優先度を下げました。

まずMCP接続でナレッジ検索を現場に開くほうを、先に置いています。
絞った結果、管理画面に残った機能は2つだけになりました。当初の設計では11画面を予定していました。

絞った結果、管理画面に残った機能は2件になりました。当初の設計では11件を予定していました。

⑥ あとで知った — MCPの位置づけは、最初から「繋ぎ方の標準」だった

素朴な判断のつもりでしたが、MCPが何のために作られたかを読み直すと、この使い方が本来でした。

社内でも、以前こう説明されています。

「MCPはAIと厳密なAPIをつなぐ標準化のコンセプトですが、実務ではMCPサーバーとして拡張機能のような意味で使われることが多い」

「標準化のコンセプト」が先で、「拡張機能」は使われ方のほうです。

標準化とは何かというと、繋ぎ方を共通にすることです。 繋ぎ方が共通なら、繋がれる側は、繋ぐ側の画面を作らなくていい。

USBに近いと思います。周辺機器のメーカーは、パソコン側の画面を作りません。 差し込み口の形が決まっているからです。決まっていなければ、メーカーごとに専用の接続ソフトを配ることになります。

私たちがやろうとしていたのは、その専用ソフトを配ることでした。

繋ぎ方が標準化された領域で、自前の入口を作るのは、標準化の恩恵を自分から捨てる行為です。

新しい理屈は、ひとつも要りませんでした。

記録に残っている実例

境界だけを持つとは、具体的にはこういう形です。

2026年5月8日、接続する道具を8件、許可リストに書きました。 画面は1枚も作っていません。利用者は、既に使っているクライアントからそのまま入ります。

そして鍵の持ち方です。2026年2月3日の決定で、APIキーはデータベースに置かず、環境変数の名前だけを持つ形にしました。 鍵そのものは外にあり、参照する名前だけが中にあります。

この2件で、自社が持つものは接続できる道具の一覧と、鍵の在り処の2件に縮みました。認証の画面も、権限の管理画面も、検索結果の表示も作っていません。

作らなかったものが多いほど、保守する対象が減ります。 画面を1枚作ると、その画面の障害対応が毎年発生します。

⑦ 何が変わったか

作るものの一覧が、こう変わりました。

“`
前：フロントエンド + 認証 + 検索体験 + 権限管理 + 保守
後：権限管理 + APIキー発行
“`

そして、現場に開くまでの時間が縮みました。 作る量が減ったからです。

⑧ 現場で使うなら、この2枚

表1：作るか、繋ぐかの判定

項目	自前で作る	MCPで繋ぐ
入口（画面）	作る。保守も持つ	相手が持っている
認証	作る	相手側の認証に乗る
権限（誰が何を読めるか）	自分が持つ	自分が持つ
検索体験	作る	相手のAIが担う
使い方の教育	必要	既に使っている道具なので少ない

権限の行だけが、両方とも「自分が持つ」です。 そこが本体です。

表2：最小構成で社内に開くときの順番

順	やること	理由
1	フォルダ単位の権限設計	ここが間違っていると、他を作っても意味がない
2	APIキーの自己発行	管理者が詰まらないように
3	承認フロー	誰が権限を決めるかを固定する
4	端末認証などの安全策	後でよい。まず権限の粒度
—	専用フロントエンド	必要になったら作る

補：作らない判断で消えた工数

作らなかったもの	見積もっていた日数
画面	15日
認証	5日
検索体験	10日
保守（年間）	20日

ところで、この4件はどれも「あって困らないもの」です。ただ、初期フェーズで必要かというと違いました。記録にも「まずはMCP接続によるナレッジ検索の早期現場開放を目指す」と書かれています。

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「画面には、認証と権限と保守が漏れなく付いてくる」。 検索体験も、障害対応も、後から必ず来ます。画面1枚の見積は、画面1枚では終わりません。

2件目、「最初に作るのは画面ではなく、境界である」。 誰が何を引けるか、という線です。線が正しければ、入口は後からいくらでも足せます。

3件目、「利用者が既に使っている入口を、入口にする」。 新しい画面を覚えてもらう工程が丸ごと消えます。展開にかかる日数が変わります。

4件目、「自社が持つのは、鍵の発行だけにする」。 権限とAPIキーの発行に絞ると、運用で見る対象が2件に減ります。

5件目、「画面を作るのは、境界が正しいと分かってから」。 逆にすると、間違った線の上に画面を積むことになります。作り直しは、線ではなく画面の側に発生します。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

AIクライアントは、これからも増えます。そして、増えるほど自前の画面は不利になります。 利用者が既にいる場所から離れさせる行為だからです。

→ 標準の繋ぎ方がある → 相手の画面が使える
→ 自前の画面を作る → そこへ来てもらう必要がある
→ 来てもらう必要がある → 使われない
作るものが5つから2つに減りました。減った3つは、そのまま保守しなくてよいものになります。 初期フェーズで最も効いたのは、この差でした。
開くまでの期間も変わりました。7週間の見積もりが、2週間になっています。

社内システムが使われない理由の多くは、機能ではなく、そこへ行かないことです。

そして、画面を作らない判断には、もう一つ効き目があります。間違いを直す範囲が小さくなります。 権限設計を間違えたら権限だけ直せばいい。画面まで作っていたら、画面も直すことになる。

ただし、正直に書いておきます。この判断は「初期フェーズは」という条件付きです。 全社に定着して、AIを使っていない人にも広げる段になれば、画面は要るはずです。

そのとき作る画面は、いま作る画面とは別のものになります。 何が使われているかを見てから作れるからです。作らなかったぶん、後で正しく作れるという順序になっています。

開くまでの期間も変わりました。35日の見積もりが、10日になっています。

関連して、ベクトルデータベースの再現率が頭打ちになる話と、ローカルLLMを自社の中に置く判断話を別に書いています。複数データベースをまたぐエージェンティックRAG話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、社内GPT・RAG構築のページに整理しています。

---

ちなみに、私はすぐに鍵をなくすので、小さい頃から、出かけるときに鍵を持ったか声に出して、財布にしまい出かける癖があります。おかげで、大人になって鍵をなくしたり忘れることが減りました。

スマートロックを導入した後は、「これで鍵をどこかに置き忘れても大丈夫！！」と思っていたら、スマホを置き忘れました。

以上です。

MCPのよくある質問

MCP（Model Context Protocol）とは何ですか？

AIと、外部のデータや機能をつなぐための共通の決まりごとです。2024年にAnthropicが公開し、仕様とSDKが誰でも使える形で出ています。周辺機器をつなぐ差込口の規格に近く、形が統一されていれば、機器ごとに専用の配線を作らずに済みます。MCPは、その形をAIと外部システムのあいだで決めたものです。

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

自分たちのデータや機能を、MCPの決まりごとに沿って外へ差し出すプログラムのことです。サーバーという語からハードウェアを想像しますが、実体は小さなプログラム1本で、手元のパソコンで動かす形も標準の使い方に含まれています。提供できるものは、AIが実行できるツール、AIが読み取れるリソース、定型の指示であるプロンプトの3種類です。

MCPとRAGは何が違いますか？

層が違います。RAGは、答える前に資料を検索して参考として渡す手法で、何を渡すかの話です。MCPは、AIと外部システムのつなぎ方の規格で、どうやって取りに行くかの話です。対立するものではなく、RAGの取得部分をMCPで作ることができます。どちらかを選ぶという問いの立て方が、そもそも噛み合っていません。

MCPとAPIは何が違いますか？

MCPはAPIを置き換えるものではなく、APIの上にAIから扱いやすい共通の口をかぶせるものです。違いは3つあります。機能の一覧をAIが自分で取得できること、それぞれの機能に自然文の説明が付いていること、呼び出し方がサービスをまたいで揃っていること。この3つがあるため、AIがどれを呼ぶかを自分で決められます。

MCPを社内で使うとき、何に注意すればよいですか？

3点です。サーバーが持つ権限を必要な範囲だけに絞ること（最初は読み取りのみが安全です）、公開されているサーバーをそのままつながないこと（中で何をしているかは見えません）、誰がどのツールをいつ呼んだかを記録すること。外部の文章に指示が仕込まれていてAIが意図しない処理を呼ぶ経路があるため、送信や削除には人の承認を挟んでください。

MCPとは何ですか？

Model Context Protocol の略で、AIと外部のデータや道具を繋ぐための共通の作法です。AIと厳密なAPIをつなぐ標準化のコンセプトですが、実務では「MCPサーバー」という形で、AIクライアントに機能を足す拡張のような意味で使われることが多くなっています。

社内ナレッジをAIに繋ぐとき、専用の画面は必要ですか？

初期フェーズでは要らないことがあります。画面を作ると、認証、権限管理、検索体験、その後の保守が全部くっついてきます。MCPで接続すれば、利用者は既に使っているAIクライアントから入るため、自社が用意するのは権限とAPIキーの発行だけで済みます。

MCPで社内展開する場合、何を用意すればいいですか？

APIキーの発行と、フォルダごとのアクセス権限管理です。実際の設計では、管理画面はこの2つに特化させました。ユーザーが自分でAPIキーを発行でき、承認する側が権限を設定するフローにすると、管理者が一人ずつ登録する負担がなくなります。

APIキーを配ると、持ち出されるリスクはありませんか？

あります。将来的には端末認証と組み合わせる方針ですが、初期段階ではそこまで作りません。まず権限の粒度を正しくすること、つまり、そのキーで何が読めるかをフォルダ単位で絞ることが先です。読めるものが正しければ、キーが出ても被害の範囲は権限の範囲に収まります。

ローカルLLMやアカウント共有の構成は検討しなかったのですか？

検討しましたが、優先度を下げました。仮想マシン上でアカウントを共有する構成は規約上の制約があり、ローカルLLMのシェアホスティングは接続数やルーティングの検証に多大なコストがかかるためです。まずMCP接続でナレッジ検索を現場に開くほうを先に置きました。