MCP（Model Context Protocol）を非エンジニア向けに解説。AIエージェントが社内DB・SaaS・ファイルサーバに安全につながる仕組み、広がるエコシステム、自社システムをエージェントから使えるようにする際の設計とセキュリティ観点を、情シス・アーキテクトの視点で整理します。
生成AIやAIエージェントの話題では、しばしばモデルそのものの賢さに注目が集まります。しかし、実際に社内で役立つ仕組みを組もうとすると、多くの情シス・アーキテクトが同じ壁に突き当たります。それは「モデルが賢いかどうか」ではなく、「そのモデルに、社内の正しいデータと安全な操作を、どうやって渡すか」という接続の問題です。AIエージェントは、社内のどこに何があるかを最初から知っているわけではありません。誰かが、在庫データベース、勤怠システム、ファイルサーバ、各種SaaS、ナレッジ基盤といった情報源への「つなぎ込み」を用意して初めて、業務に踏み込んだ受け答えや作業ができるようになります。
従来、この「つなぎ込み」は個別に作り込むのが一般的でした。あるエージェント製品と自社の基幹システムをつなぐために専用の連携コードを書き、別のエージェントを試すときにはまた別の連携を書く。エージェントの種類とシステムの種類が増えるほど、必要な連携の数は掛け算で膨らんでいきます。仮にエージェント側の候補が数種類、つなぎたい社内システムが十数個あれば、その組み合わせだけで相当な数の作り込みが発生し得ます。しかも、それぞれが独自の認証方式・データ形式・エラー処理を抱えるため、保守の負担も分散し、担当者が変わると解読が難しくなりがちです。
この状況は、AIエージェントを本格的に使おうとする組織にとって見過ごせないコストです。せっかくモデルが進化しても、接続層が個別最適の積み重ねになっていると、ツールの入れ替えや拡張のたびに大きな改修が必要になり、身動きが取りにくくなると考えられます。
MCP（Model Context Protocol）は、この「つなぎ方がバラバラである」という課題に対して、共通の作法（プロトコル）を1つ用意しよう、という発想で生まれた接続規格です。エージェント側は「MCPという共通の窓口」に話しかければよく、社内システム側は「MCPという共通の窓口」を1つ用意すればよい。両者が同じ作法に従うことで、個別の作り込みを都度用意する必要が薄れ、連携の組み合わせ爆発を抑えられる可能性が高いと考えられます。この記事では、MCPが具体的に何をする仕組みなのか、どんなエコシステムが広がりつつあるのか、そして自社システムをエージェントから安全に使えるようにするうえで押さえるべき設計・セキュリティの観点を、非エンジニアの意思決定層にも追えるように整理していきます。
なお、AIエージェントと既存の社内システムをどうつなぐかという全体設計については、AIエージェントと社内システムの連携設計もあわせてご覧いただくと、本記事の位置づけが掴みやすくなると考えます。
MCPを一言で表すなら、「AIエージェントと外部システムをつなぐための、共通の差込口（インターフェース）の取り決め」です。エンジニアでない方に向けては、電源のコンセントやUSB端子のたとえが分かりやすいかもしれません。かつて電子機器の充電端子が製品ごとにバラバラで、機器が変わるたびに専用ケーブルを探す必要があったのに対し、共通規格が普及すれば1本のケーブルで多くの機器をつなげます。MCPは、AIエージェントと社内システムの間に、この「共通端子」に相当するものを設けようとする取り組みだと捉えると、全体像を掴みやすくなると考えます。
MCPの構図は、大きく3つの役割で理解できます。1つ目は「ホスト」で、これはAIエージェントを動かしているアプリケーション本体（対話ツールやコーディング支援ツール、社内AIエージェント基盤など）を指します。2つ目は「クライアント」で、ホストの中に組み込まれ、MCPの作法で外部と通信する窓口の役割を担います。3つ目が「サーバ」で、これは社内DBやSaaS、ファイルサーバといった情報源・操作対象の側に置かれ、「このデータを読めます」「この操作ができます」という能力を、MCPの共通の形で外に差し出します。
重要なのは、ここで言う「サーバ」は必ずしも大がかりなものではなく、既存システムの前に立つ薄い仲介役として位置づけられる点です。基幹システムそのものを作り替えるのではなく、その前に「エージェントから使える共通の窓口」を1枚かぶせるイメージに近いと考えられます。
MCPのサーバがエージェントに提供するものは、おおむね次の3つに整理できます。1つは「ツール（Tools）」で、これは実際に何かを実行する操作を指します。たとえば「在庫数を照会する」「伝票を検索する」といったアクションです。2つ目は「リソース（Resources）」で、これは読み取り対象となるデータやファイルを指します。社内文書やレコードなどが該当します。3つ目は「プロンプト（Prompts）」で、これはよく使う指示の型をあらかじめ用意しておく仕組みです。
エージェントは、サーバに「あなたは何ができますか」と問い合わせ、返ってきた能力の一覧を見て、ユーザーの依頼を達成するために適切な操作やデータ取得を選びます。この「能力を自己申告し、エージェントが選んで使う」という流れが標準化されている点が、MCPの実務上の価値だと考えます。
「社内データをAIに参照させる」という文脈では、RAG（検索拡張生成）という手法がよく知られています。RAGは、社内文書を検索して関連箇所をモデルに渡し、それを踏まえて回答させる仕組みで、主に「読んで答える」用途に強みがあります。仕組みの詳細は社内文書をAIに答えさせる仕組み（RAG）とはで解説していますが、MCPはRAGと排他的なものではありません。むしろ、RAGで使う検索基盤もMCPサーバの1つとして差し出せますし、MCPは「読む」だけでなく「操作する（書き込む・実行する）」まで含めた、より広い接続の作法だと捉えると整理しやすいと考えます。従来型のAPI連携との関係で言えば、MCPは既存APIを置き換えるものではなく、既存APIの前に「エージェントにとって扱いやすい共通の入口」を用意する層だと考えるのが実態に近いと考えられます。
では、MCPを通じてAIエージェントが社内システムにつながるとき、内部では何が起きているのでしょうか。技術の細部に立ち入りすぎず、意思決定に必要な粒度で流れを追ってみます。
たとえば現場の担当者が、社内AIエージェント基盤に「A商品の現在の在庫と、直近の入荷予定を教えて」と尋ねたとします。エージェントはまず、接続されているMCPサーバ群に「どんな能力があるか」を確認します。在庫システムのMCPサーバが「在庫照会」「入荷予定照会」といったツールを差し出していれば、エージェントはそれらを選び、必要なパラメータ（商品コードなど）を組み立てて呼び出します。サーバは受け取った要求を、自身が仲介している在庫システムに対して実行し、結果をMCPの共通の形で返します。エージェントはその結果を自然な文章にまとめて、担当者に返答します。
この一連で注目したいのは、エージェントが社内システムの内部構造を直接知っている必要がない、という点です。エージェントはあくまで「サーバが差し出す能力」を通してしか社内システムに触れられません。裏を返せば、サーバ側が差し出す能力の範囲を絞ることで、エージェントにできることを設計として制御できる、ということでもあります。
MCPのように接続層を標準化する構成の利点は、エージェント側と社内システム側を疎結合に保ちやすいことです。エージェント製品を別のものに乗り換えても、社内システム側のMCPサーバがそのまま使えるなら、社内側の作り直しは最小限で済む可能性が高いと考えられます。逆に、社内システムを更新しても、MCPサーバが差し出す能力の形（インターフェース）を保っていれば、エージェント側は影響を受けにくくなります。特定の製品に深く依存した作り込みは、その製品の仕様変更や乗り換えのたびに大きな改修を招きがちですが、標準化された窓口を挟むことで、その揺れを吸収しやすくなると考えます。
MCPサーバは、利用者の手元の環境で動かす形と、社内ネットワーク上のサーバとして動かす形の双方が想定されます。手元で動かす場合は、ローカルのファイルや個人の作業環境にアクセスする用途に向きます。社内サーバとして動かす場合は、複数のメンバーが共有する社内システムやデータ基盤への窓口として使うことが考えられます。どちらの形を取るにせよ、「エージェントがどこから、どの権限で、何にアクセスするのか」を明示的に設計することが、後述するセキュリティ上の要点になります。組織全体でチャットツールから使う構成については、SlackやTeamsにAIエージェントを組み込むもあわせてご覧いただくと、実装イメージが具体化すると考えます。
MCPが注目される理由の1つは、特定の一社に閉じた仕組みではなく、オープンな規格として公開され、複数の主要なAIツールや基盤が対応を進めている点にあります。標準化の取り組みは、対応するツールとサーバが増えるほど価値が高まる性質を持ちます。つないだ先が多いほど、共通の作法で扱える範囲が広がるためです。
自社システムのためにMCPサーバを1つ用意すれば、MCPに対応したさまざまなエージェントから、原則として同じ窓口を通して使ってもらえる可能性があります。これは、エージェントごとに個別の連携を作り直す従来の負担を、大きく軽くしうる構図です。同様に、広く使われているSaaSやデータ基盤の側でMCP対応が進めば、利用企業は自前で連携を作り込まなくても、標準の窓口を通してエージェントからつなげるようになっていくと考えられます。ただし、対応状況やサーバの品質・保守体制はサービスごとに差があるため、採用にあたっては提供元の情報と実際の挙動を確認することが前提になると考えます。
MCPをめぐる状況は動きが速く、対応ツールの範囲や仕様の細部、各サービスの料金体系は変わり得ます。本記事では概念と設計観点の整理に重点を置いていますが、具体的なツール名や機能・料金の最新の内容については、各提供元の公式情報を確認することをおすすめします。特定製品の絶対的な優位を断定するのではなく、自社の要件（既存システムの構成、セキュリティ要件、運用体制）に照らして評価する姿勢が、遠回りに見えて堅実だと考えます。
エージェントからつなぐ先として、ERPや基幹システムを思い浮かべる方も多いかもしれません。ただ、基幹システムにデータが十分に整理されて蓄積されていない段階でエージェント連携を急ぐと、期待した答えが得られにくいことがあります。この論点はERPを入れる前にで掘り下げていますが、MCPはあくまで「つなぐ作法」であって、つないだ先のデータの質そのものを高めてくれるわけではない、という点は押さえておく必要があると考えます。標準化された接続は強力な土台になりますが、土台の上に乗せるデータと業務設計が伴って初めて価値が出る、と捉えるのが実態に近いと考えられます。
ここからは、実際に自社システムをエージェントから使えるようにする際に、情シス・アーキテクトが押さえるべき設計とセキュリティの観点を整理します。MCPは接続を標準化しますが、「何をどこまで許すか」の判断は依然として各組織の設計に委ねられます。むしろ、エージェントが自律的に操作を選ぶからこそ、渡す権限の設計はより慎重に行う必要があると考えます。
最初の原則は、最小権限です。エージェントに与える能力は、その用途に必要な最小限にとどめるべきだと考えます。具体的には、まず読み取り専用の照会から始め、実運用で挙動と有用性を確かめてから、書き込みや実行を伴う操作へ段階的に広げる進め方が現実的です。MCPサーバが差し出すツールの粒度を、あえて「できることを絞った専用の操作」として設計することで、エージェントが想定外の広い操作に踏み込む余地を減らせます。汎用的で強力な操作を1つ渡すより、目的別に絞った操作を複数用意するほうが、統制の観点では扱いやすいと考えられます。
エージェントが社内システムにつながるということは、そのアクセスに「誰の権限で行っているのか」が伴います。MCPサーバの手前で認証を行い、エージェント（あるいはそれを使うユーザー）が持つ権限の範囲を超えたデータや操作に触れられないよう、認可を効かせることが要点です。人間のユーザーがもともとアクセスできない情報に、エージェント経由なら触れられてしまう、という状態は避ける必要があります。既存システムのアクセス制御を尊重し、エージェント連携がそれを迂回する抜け道にならないよう設計することが重要だと考えます。
書き込みや外部送信、削除といった影響の大きい操作については、エージェントが自動で完結させるのではなく、人間の承認を挟む「承認ゲート」を設けることが有効だと考えます。どこに承認点を置くかの考え方は、AIエージェントに任せる範囲と人の確認ポイントの設計として、別途整理する価値がある論点です。あわせて、いつ・誰の権限で・どのツールを・どんな引数で呼び出し・何が返ったかを記録する監査ログを、最初から設計に織り込むことをおすすめします。ログは、問題が起きたときの追跡だけでなく、エージェントの挙動を継続的に見直し、権限設計を調整していくための材料にもなります。
エージェントは、外部から取り込んだデータの中に紛れ込んだ「指示のような文字列」に引きずられてしまう場合があります。いわゆるプロンプトインジェクションと呼ばれるリスクで、たとえば読み込んだ文書やWebページにAIへの命令文が仕込まれていると、意図しない操作を誘発されかねません。MCPで外部データを扱う際は、取り込む内容を信頼できるものに絞る、あるいは取り込んだデータをそのまま操作の根拠にしない設計を検討することが、実務上の防御になると考えます。接続範囲を広げるほどこの種のリスク面も広がるため、範囲の拡大と統制の強化は歩調を合わせて進めるのが望ましいと考えられます。
MCPは有望な標準ですが、期待だけで走り出すと足をすくわれる場面もあります。現時点で意識しておきたい落とし穴を、実務の観点から挙げます。
これらは、いずれも「小さく始めて、確かめながら広げる」という原則に立ち返れば避けやすい落とし穴だと考えます。標準規格の魅力に引かれて一気に接続範囲を広げるより、1つの用途で確実に価値と安全を確かめてから次へ進むほうが、結果的に早いことが多いと考えられます。
最後に、自社でMCPを活かしてAIエージェントと社内システムをつなぐ際の、現実的な進め方を整理します。あくまで一般的な目安であり、最適な順序は組織の状況によって異なるため、自社の条件に合わせて調整いただくことが前提です。
まずは、効果が見えやすく、失敗しても影響が限定的な用途を1つ選びます。たとえば、社内ナレッジ基盤や特定システムの照会を、読み取り専用でエージェントから使えるようにするところから始めるのが手堅いと考えます。この段階で、認証・認可・監査ログの基本形を設計に組み込み、以降の拡張でも使い回せる土台を作っておくと、後の負担が軽くなると考えられます。
読み取りで有用性と安全性を確認できたら、書き込みや実行を伴う操作へ慎重に広げます。影響の大きい操作には人間の承認を挟み、監査ログで挙動を継続的に確認します。ここで大切なのは、接続範囲の拡大とセキュリティ統制の強化を同時に進めることです。片方だけが先行すると、使いにくいか、危ういか、どちらかに傾きやすいと考えます。
1つの用途で型ができたら、同じ設計思想を他のシステムや部門へ広げていきます。MCPという標準の窓口を挟むことで、エージェント側・システム側を疎結合に保ちやすく、横展開の際の作り直しを抑えられる可能性が高いと考えられます。ツールやデータ基盤の選定、内製と外注の切り分けといった論点は、AIエージェントと社内システムの連携設計とあわせて検討いただくと、全体像を見失いにくくなると考えます。
ここまで設計と観点を述べてきましたが、最終的に効果や適合を決めるのは、自社の実際のデータと業務での検証です。私たちNsightは、産業用画像検査やVLM/AIの開発に加え、AI研修や社内AIエージェント基盤の内製化支援に取り組んでおり、その中には元キーエンス画像処理事業部で現場の要件と向き合ってきた監修者の知見も含まれます。現場では、カタログ上のスペックと実運用の手触りがしばしば食い違います。だからこそ、机上の比較だけで結論を急がず、小さな範囲で現物・現場での検証を通じて、何が本当に効くのかを一緒に確かめていく進め方を重視しています。MCPという標準は、その検証を支える良い土台になりうると考えます。まずは自社の1つの用途で、安全に確かめてみることをおすすめします。
接続の技術的な細部までは不要ですが、意思決定に関わる方は「AIエージェントと社内システムをつなぐ共通の作法」という概念は押さえておく価値があると考えます。連携をどうつなぐかは、コストや保守負担、セキュリティに直結する経営的な論点でもあるためです。細かな実装は技術担当に委ねつつ、どの範囲まで許すか、どこに承認を置くかといった方針は、情シスや管理部門も交えて決めるのが望ましいと考えられます。
必ずしもそうではないと考えられます。MCPは既存システムの前に「エージェントから使える共通の窓口」を薄くかぶせる発想に近く、基幹システムそのものを作り直す前提のものではありません。既存のAPIやデータ基盤を活かしつつ、その手前に標準の入口を用意するイメージです。ただし、参照させたいデータが未整備な場合は、接続の前にデータの整理が必要になることがあります。
接続範囲を広げれば、その分だけ考慮すべきリスク面も広がります。ただ、最小権限で始め、認証・認可を接続層で効かせ、危険操作に承認ゲートを設け、監査ログを残すといった設計を最初から織り込めば、統制を保ちながら活用することは十分可能だと考えます。人間がアクセスできない情報にエージェント経由で触れられる、といった抜け道を作らないことが要点です。
RAGとMCPは排他的なものではありません。RAGは主に「社内文書を検索して読んで答える」用途に強く、MCPは読むことに加えて「操作する」まで含めた、より広い接続の作法です。RAGで使う検索基盤をMCPサーバの1つとして差し出すこともできます。読んで答えるだけでなく、社内システムに対する照会や操作までエージェントに広げたい場合は、MCPの考え方が役立つ可能性が高いと考えます。
影響が限定的で効果の見えやすい用途を1つ選び、読み取り専用の照会から始めるのが手堅いと考えます。たとえば社内ナレッジ基盤や特定システムの照会をエージェントから使えるようにし、その段階で認証・監査の基本形を設計に組み込んでおくと、後の拡張が楽になると考えられます。最適な出発点は組織ごとに異なるため、自社データでの検証を前提に進めることをおすすめします。
MCPを含めた接続方式の選定や、最小権限・監査を織り込んだ設計は、自社のデータと業務で確かめて初めて最適解が見えてきます。元キーエンス画像処理事業部出身の知見を持つチームが、小さな用途からの検証をご一緒します。
AIエージェント連携について相談する