MCPとは？社内ナレッジ検索の画面を作るのをやめて、MCP接続にした話

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

社内の人は、既に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構築のページに整理しています。

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

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

以上です。