MCPとは：経営と情報システム部門が押さえる仕組みとリスク

MCPとは、AIアプリケーションを外部のシステムにつなぐためのオープンな標準規格（Model Context Protocol）である。経営と情報システム部門にとって押さえるべき点は1つだ。AIが社内のデータやツールに触れる経路が、システムごとの個別開発から「接続を足すだけ」の作業に変わる。しかも仕様は、利用者の同意と認可の原則をプロトコルの側では強制できず、実装する側が組み込むべきだと書いている（2026年11月7日時点の公式情報）。つまり、どのシステムを、誰の権限で、読み取りだけか書き込みまでつなぐかは、仕様の外で組織が決めることになる。後半は本稿の整理である。本稿では、MCPの仕組みを経営判断に必要な範囲で整理し、海外の元記事から組織で起きている変化と、リスクが生じる場所、決めるべき役割を示す。

MCPとは何か ― ホスト・クライアント・サーバーの3つの役割

MCPの公式ドキュメントはMCPを「AIアプリケーションを外部システムに接続するためのオープンソースの標準」と定義し、AIアプリケーションにとってのUSB-Cポートにたとえている。USB-Cが電子機器の接続方法を揃えたように、MCPはAIアプリケーションと外部システムの接続方法を揃える。ClaudeやChatGPTのようなAIアプリケーションが、ローカルのファイルやデータベースといったデータソース、検索エンジンなどのツール、特定の用途に合わせたプロンプトのようなワークフローに、同じやり方でつながる。

経緯も確認しておく。Anthropicは2024年11月25日にMCPを発表し、仕様とSDK、Claude Desktopアプリでのローカルサーバー対応、サーバーのオープンソースのリポジトリを公開した。最初に用意されたサーバーはGoogle Drive・Slack・GitHub・Git・Postgres・Puppeteer向けである。2025年12月9日には、MCPをLinux Foundation配下の基金であるAgentic AI Foundationへ寄贈した。この基金はAnthropic・Block・OpenAIが共同で設立したものだ。寄贈時の発表では、ChatGPT・Cursor・Gemini・Microsoft Copilot・Visual Studio CodeなどがMCPを採用しているとされる（2026年11月7日時点でAnthropicの公式発表を確認）。特定のAI企業の独自機能ではなく、業界で共有された接続の規格として扱ってよい。

仕組みは3つの役割で理解できる。公式ドキュメントのアーキテクチャ解説（仕様は2026年7月28日版）によれば、役割は次の3つである。

• ホスト: Claude CodeやClaude DesktopのようなAIアプリケーション本体。1つ以上のクライアントを束ねる
• クライアント: ホストの中に置かれ、MCPサーバー1つにつき1つ作られる接続役。担当するサーバーと専用の接続を保つ
• サーバー: クライアントにコンテキスト（情報と機能）を提供するプログラム

サーバーが提供するものは3種類ある。AIモデルが呼び出して実行する関数である「ツール」、読み取り専用の情報源である「リソース」、利用者が明示的に呼び出す定型の指示である「プロンプト」だ。公式ドキュメントは、ツールについてデータベースへの書き込み、外部APIの呼び出し、ファイルの変更もできると説明し、いつ使うかはモデルが利用者の依頼に基づいて決めるとしている。リソースを制御するのはアプリケーション、プロンプトを制御するのは利用者である。管理の観点で最も重いのは、モデルが自分の判断で呼び出し、書き込みや送信まで行えるツールである。

サーバーには動く場所の違いもある。同じ端末で標準入出力（stdio）を使って動くものが「ローカル」のサーバー、Streamable HTTPという方式で使うものが「リモート」のサーバーと呼ばれる。リモート接続では、認証用のトークンをOAuthで取得することが推奨されている。ローカルのサーバーは社員の端末の上で動く。リモートのサーバーはネットワークの向こうで動き、外部の事業者が運営するものもあれば、自分の組織がホストするものもある。情報システム部門にとっては、管理の対象がまったく違う。

ここまでの仕組みを業務自動化の全体像に置くと、MCPはエージェントを社内の情報の置き場へ届かせる経路を共通の規格にしたものにあたる。どの社内システムをエージェントが参照する正のデータソースにするかという投資の順序は、業務自動化を支える5つの要素と、先に予算を付ける1つで扱った。

MCPサーバーで組織の仕事はどう変わるのか

MCPサーバーは、すでに本番の業務で使われている。a16zは従業員1,000人超の企業のCISO（最高情報セキュリティ責任者）100人を調査した。その結果、55%がMCPサーバーなど、エージェントとアプリケーションの連携を本番で使っていた（2027年のセキュリティ予算、87%のCISOが増加を予想──AIエージェント関連の優先度が急上昇）。大企業のCISOに限った調査ではあるが、調査対象の半数を超える組織では、接続がすでに本番に入っている。

変化は個人の仕事から始まっている。Lenny’s Newsletterに寄稿したColin Matthewsは、Claude Code・Codex・CursorがMCP経由でFigma・Amplitude・PostHog・Pendoなどにつながると紹介した。そのうえで、AIにタスクを最後まで任せるには、日常的に使う製品をMCPでつなぐ必要があると書いている（PMのAI活用レベルをどう測るか ― トップPMに学ぶ3つの「はしご」フレームワーク）。設定の手軽さについては次のように書く。

“This may sound complicated, but it’s really easy to do, and once you create this connection, you’ll never have to touch it again.”

訳: 難しそうに聞こえるが実際はとても簡単で、一度この接続を作れば二度と触る必要はない。

出典: How top PMs increase their leverage with AI by Colin Matthews, Lenny’s Newsletter, 2026-06-30

接続が「一度作れば触らない」ものになることは、生産性の面では利点である。管理の面から見ると、接続が誰にも見直されないまま残り続けることを意味する。

チームの業務改善にも使われている。Every社のカスタマーサポートのマネージャー、Waqqas Mirは、カスタマーサポートのAIエージェントを提供するFinのMCPサーバーにCodexをつないだ。Codexが誤対応した会話を取り出して原因を診断し、ピンポイントの追加指示を提案する。元記事によれば、このMCP接続でできるのはFinのデータの分析までで、Finの設定を直接変えることはできず、追加指示の反映は本人が行う（新AIモデルへの乗り換えは何を根拠に決めるのか ― 2日ほどの締め切りに対し監査と下書きを90分で終えたビズオプスのマルチモデル運用）。結果として、読み取りはAI、書き込みは人という形に分かれている。

全社規模の例もある。社員約900人のメンタルヘルスケア企業Headwayは、社内アシスタント「Eddy」を自前で作った。元記事は、Eddyの利用が広がった要因の1つに、MCPを使うコネクタで社員がすでに使っているソフトウェアと連携できるようにしたことを挙げている。Figma向けのコネクタではデザインファイルの読み取りと編集が、Snowflake向けではデータウェアハウスへの問い合わせができる。同社CTOによれば、元記事の公開時点で全社が週次でEddyを使い、900人のうち650人が日次で使っていた。ただし元記事は、FigmaやSnowflakeのMCPサーバー自体は既製品として存在しても、Headwayのような複雑な会社が必要とするコネクタ・権限・臨床データのアクセスルールの組み合わせは、大手のAIベンダーには売れないとしている（社内 AI アシスタントは自作すべきか購入すべきか ― Headway が Claude Code SDK で「Eddy」を自社構築した判断基準）。

3つの事例に共通するのは、接続そのものは既製品で手に入るが、何をどの権限でつなぐかの組み合わせは各組織の側に残るという点だ。この組み合わせを自前で持つのか、製品の設定で済ませるのかは、AI基盤への投資判断の問題でもある。この判断はモデルを差し替えられる設計を軸にした内製と購入の判断で詳しく論じた。

MCPのリスクはどこにあるのか

MCPの仕様の概要には、セキュリティと信頼についての節がある。MCPは任意のデータアクセスとコード実行の経路を通じて強力な機能を実現するので、実装する者はセキュリティと信頼について慎重に考える必要がある、という趣旨だ。原則は3つ挙げられている。

• 利用者の同意と制御: 利用者はすべてのデータアクセスと操作に明示的に同意し、内容を理解していなければならない
• データのプライバシー: ホストは利用者のデータをサーバーに渡す前に、明示的な同意を得なければならない
• ツールの安全性: ツールは任意のコード実行に当たり、慎重に扱わなければならない。信頼できるサーバーから得たものでない限り、ツールの挙動の説明も信頼できないものとして扱う

続けて仕様は、MCP自体はこれらの原則をプロトコルの側で強制できないと明記している。同意と認可の仕組みを組み込むべきなのは、実装する側、つまりホストとなるAIアプリケーションやサーバーの作り手である。認可の仕組み自体も、仕様の上では任意（OPTIONAL）だ（2026年11月7日時点の仕様）。導入する組織には、どの実装を選び、どう設定し、何をつなぐかという判断が残る。MCPに対応しているというだけでは、安全の保証にならない。

その判断が要る場所は、大きく3つに分かれる（本稿の整理）。

• 外から入れるサーバー: Claudeのヘルプセンターは、悪意のあるMCPサーバーには意図しない操作をさせる隠れた指示が含まれうると注意している
• 接続に渡す権限: a16zは、エージェントが社員の端末上で社員本人の権限で動くため、従来のセキュリティ製品からは社員本人の操作と見分けられないと指摘する
• 自前で作る接続口: Everyの記事で、Katie Parrottは自作アプリのMCPの接続口をClaudeで作って本番に出し、後日、別のモデルによる点検で、非公開であるべき登録経路が公開されていたことが見つかった（非エンジニアの AI 開発をどこまで許可すべきか — vibe coding が本番に持ち込んだ脆弱性の教訓）

それぞれの事例と、社内データの接続を1件ずつ許可するときの基準は、MCPサーバーのセキュリティと社内データ接続の許可基準で詳しく扱った。権限の線を引く考え方そのものは、権限境界をスピード・統制・可逆性の3軸で設計する方法で論じている。

経営と情報システム部門はMCPについて何を決めるべきか

すでに本番でMCPを使っている組織が決めるのは、MCPを使うかどうかではない。前述のa16zの調査では、55%がその段階にいる。以下は本稿の整理であり、公式の分類ではない。決めるべきは次の3つの役割の置き場所である。

第一に、MCPサーバーを組織に追加できる人を誰にするか。 製品の側に追加の権限を絞る設定があっても、その役に誰を置き、何を基準に認めるかは組織が決める。

第二に、書き込みを伴う接続を誰が承認するか。 仕様の上でも読み取り専用のリソースと書き込みまでできるツールは区別されており、承認者を置くのは後者だけでよい。

第三に、いま何がつながっているかを誰が把握するか。 一度作れば触らない接続が増えていくなら、承認の時点の審査だけでは足りず、一覧を持って見直す担当が要る。

各製品の具体的な設定と、接続1件ごとの確認項目は社内データ接続を許可する基準にまとめた。権限の拡大や縮小を誰が受け、どの基準で判断するかという変更の所有権については、権限境界の変更責任者と判断基準を制度化する論点が参考になる。どのシステムをつなぐ対象として先に整えるかは、エージェントが参照する正のデータソースを先に予算化する論点とあわせて決めるとよい。

まとめ: MCPは接続を安くするが、接続の範囲は決めない

MCPとは、AIアプリケーションを外部のデータとツールにつなぐ方法を揃えたオープンな標準規格である。接続は個別開発から設定の作業になり、PMの分析からカスタマーサポートの改善、全社の社内アシスタントまで、すでに本番で使われている。一方で仕様は、同意と認可の原則をプロトコルの側では強制できず、実装する側が組み込むべきだと書いている。どこまでつなぐかは、導入する組織に残る。次に社内でMCPの話が出たときに問うべきは「MCPを許可するか」ではない。「MCPサーバーを追加できる人を誰にし、書き込みを伴う接続を誰が承認し、つながっているものの一覧を誰が持つか」である。