MCPを既存システムに接続する方法

MCPとは何か：既存システム接続で何が変わるのか

MCPは、AI（チャットやエージェント）と社内外のツール・データをつなぐための「共通のつなぎ方（プロトコル）」です。イメージとしては、AIに対して“社内の道具箱”を安全に開け渡すための統一コンセントのようなもの。これまで「AIは賢いが社内の情報に触れない」「触れさせるには個別開発が必要」という壁がありましたが、MCPを使うと“接続方法を標準化”できます。

既存システム側の観点では、「会計」「販売管理」「受発注」「在庫」「勤怠」「グループウェア」「FAQ」「ファイルサーバ」「SaaS（Google Workspace、Microsoft 365、Salesforce、kintone等）」などに点在する情報を、AIが“必要なときに必要な範囲で”参照・操作できるようになります。たとえば「今月の売上見込みと未回収一覧をまとめて」「この問い合わせはどの手順書のどこ？」といった質問に、AIが裏側のシステムに問い合わせて回答を組み立てます。

一方で、情シスや管理者が気にするポイントは「勝手にデータが流出しないか」「監査・権限・ログは大丈夫か」「既存システム改修が大きくならないか」です。ここで重要なのは、MCPは“何でもAIに渡す”仕組みではなく、渡して良い操作・データだけを明示して制御できる接続方法だという点です。接続の作り方を誤るとリスクが出ますが、設計の勘所を押さえれば、既存システムを壊さずに段階導入できます。

この記事では、専門知識が深くない方でも意思決定できるように、MCPを既存システムへ接続する全体像（方式・手順・よくある落とし穴・運用）を、業務シーンに沿って解説します。

接続方式の選び方：3つの現実解（API／RPA／データ連携）

MCPで「既存システムに接続する」といっても、現場では接続の入口が3系統に分かれます。結論から言うと、最初から“完璧な統合”を狙うより、業務インパクトが大きく、リスクが低い方式から順に進めるのが成功しやすいです。

API連携（推奨：中長期の本命）

既存システムがAPI（REST等）を提供している、または追加できる場合は、MCPサーバ側からAPIを呼び出す形が最も堅牢です。権限管理（誰が何をできるか）や監査ログ、通信暗号化、エラー時の制御がやりやすく、将来の拡張にも向きます。SaaSはAPIが充実していることが多く、ERPや基幹は社内ゲートウェイ経由でAPI化する選択肢もあります。

RPA・画面操作（短期で成果を出す）

APIがなく、改修も難しいレガシーシステムでは、RPAや画面操作の自動化で“AIが指示→ツールが画面で操作”という構成が現実的です。ただし画面変更に弱い、処理が遅い、監査設計が難しいなど課題もあるため、MCPで扱う操作は「参照中心」「低頻度」「重要だが定型」から始めるのが安全です。

データ連携（DWH/CSV/ETL：参照用途に強い）

「問い合わせ対応」「検索」「集計」「レポート作成」など“読む”業務が中心なら、まずデータを集約してAIが参照しやすい形にするのが近道です。日次でDWHに集める、SharePoint/DriveにCSVを置く、ETLで整形するなど。リアルタイム性は落ちますが、既存システムへの負荷が低く、権限やマスキングも設計しやすいのが利点です。

この3方式は排他的ではありません。たとえば「日次の集計はDWH」「個別顧客の最新状況はAPI」「どうしてもAPIがない操作だけRPA」というように組み合わせます。MCPは“AI側の接続の作法を揃える”発想なので、入口が混在しても、AIから見た使い方を統一できます。

導入前に決めること：接続範囲・権限・監査（ここで失敗が決まる）

MCP接続は技術だけでなく、運用設計の良し悪しが成果とリスクを左右します。特に「詳しくないが予算はある」組織で起きがちなのが、PoCで動いたものをそのまま本番に持ち込み、後から権限・監査で止まるパターンです。最初に以下を明確にしてください。

• 業務ゴール：「問い合わせ一次回答を30%削減」「月次レポート作成を2日→半日」など測れる形にする
• 接続範囲：最初は“読む（参照）”中心。書き込み（更新・登録）は段階導入
• 利用者範囲：全社公開か、部門限定か。権限の分け方（役職・部門・担当）
• データ分類：機密・個人情報・取引先情報・社外秘の定義と、AIに渡す可否
• 監査ログ：「誰が」「いつ」「何を」「どのデータに」アクセスしたか残す
• 安全策：マスキング、行レベル権限、レート制限、危険操作のブロック、承認フロー

ポイントは、AIに“万能の権限”を与えないことです。MCPで提供する機能（ツール）は、業務上必要な最小限に絞り、たとえば「顧客マスタ更新」ではなく「顧客情報の参照」「住所変更の申請作成」までに留める、といった形が現実的です。便利さと安全性を両立するには、操作を小さく分解して制御するのがコツです。

また、情シス観点ではネットワーク分離（社内のみ到達可能、VPN、ゼロトラスト）や、認証（SSO、MFA、サービスアカウント）も早期に押さえるべきです。ここが曖昧だと、後で「結局社内からしか使えない」「監査に通らない」となり、プロジェクトが停滞します。

実装の全体像：MCPサーバを“社内ゲートウェイ”として置く

専門用語を極力減らして、構成を一言でいうと「AIからの依頼を受けて、社内システムへの安全な窓口になるのがMCPサーバ」です。AI（クライアント）はMCPサーバが提供する“道具（ツール）”を呼び出し、MCPサーバが裏でAPIやDB、SaaSにアクセスして結果を返します。

典型的な構成は次の通りです。

• AI（チャット/エージェント）：ユーザーの指示を理解し、必要なツールを選ぶ
• MCPサーバ：ツール定義、権限、入力チェック、監査ログ、接続先の呼び出しを担当
• 接続先：基幹/CRM/グループウェア/ファイル/DB/外部SaaS

なぜMCPサーバを挟むのか。理由は2つです。1つは、既存システム側の認証情報（APIキーやサービスアカウント）をAIに直接渡さないため。もう1つは、どの操作を許可するか、どのデータを返すかをMCPサーバ側で統制できるためです。AIは賢いが“ルールの実行者”ではないので、ルールはシステム側に持たせます。

配置場所も重要です。社内ネットワークに置く（オンプレや閉域クラウド）／クラウドに置きつつ社内へは安全な経路でつなぐ（VPN、Private Link等）など、社内ポリシーに合わせます。小さく始めるなら、まずは検証環境にMCPサーバを立て、接続先は「FAQ」「手順書」「日次CSV」など低リスクから着手するのが定石です。

さらに現実的な論点として、回答品質は“つなげば上がる”わけではありません。データが散らかっている、マスタが不整合、権限が曖昧だと、AIは間違った材料で答えます。よってMCP接続は、AI導入というより情報整備と業務設計のプロジェクトでもあります。

接続手順：PoCから本番までの進め方（非エンジニア向けチェックリスト）

ここでは、情シスや管理者が社内で説明・稟議しやすいように、導入を6ステップで整理します。各ステップで「決めること」「成果物」を意識すると、ベンダー任せでも失敗しにくくなります。

ユースケースを1〜2個に絞る

最初は「問い合わせ対応（社内規程/手順書検索）」「見積作成に必要な過去事例検索」「売上・在庫の定型レポート作成」など、効果が見えやすいものがおすすめです。ここでの成果物は、入力（質問）と出力（回答・帳票）の例、関係部門、想定頻度です。“何ができれば成功か”を数値で合意しておきます。

データ棚卸しとアクセス設計

どのシステムのどの情報を使うかを列挙し、機密区分と権限を定めます。例えば「顧客名はOKだが個人の電話番号はマスキング」「単価は営業管理職のみ」など。併せて、データの持ち方（API／DWH／ファイル）を決めます。

MCPサーバで“ツール”を定義する

ツールとは「AIが呼び出せる機能のメニュー」です。非エンジニア的には「ボタン化した業務操作」と捉えると分かりやすいです。例：

• 「FAQ検索」：キーワードと部門を渡すと該当手順書を返す
• 「売上集計」：期間と部署を渡すと集計表を返す
• 「案件状況参照」：案件IDを渡すと進捗と担当を返す

ここで大事なのは、自由入力で何でも実行させず、入力項目・形式・上限を決めることです。たとえば期間は最大90日、取得件数は最大200件、など。これだけで事故確率が下がります。

認証・権限・ログを組み込む

SSO（Microsoft/Google等）でユーザーを特定し、MCPサーバ側で「このユーザーはこのツールを使える」「この部署データだけ返す」といった判定を行います。また、監査ログとして「実行したツール」「入力」「返した件数」「エラー」等を保存します。本番で止まりやすいのはここなので、PoC段階でも最低限入れておくとスムーズです。

品質検証（正しさ・漏えい・業務適合）

AIの回答は、正解率だけでなく「根拠の提示」「誤回答時の動き」「機密が混ざらないか」を確認します。典型的なテストは、権限が違うユーザーで同じ質問をして結果が変わるか、個人情報が出ないか、です。さらに「分からないときは分からないと言う」「担当部署にエスカレーションする」など業務フローも決めます。

本番移行と運用（変更管理）

本番では、ツール追加・変更の手順（申請、レビュー、リリース）を用意します。既存システムの項目変更やAPI仕様変更があると影響が出るため、情シスの変更管理に組み込みます。問い合わせ窓口も決め、ログを見て改善サイクル（どの質問が多いか、どこで詰まるか）を回します。

よくある失敗と回避策：現場で起きる“つながらない・使われない”問題

MCPを既存システムに接続しても、プロジェクトが期待通りに進まないケースがあります。原因は技術不足というより、前提の置き方にあります。代表例と対策をまとめます。

• 「全部つなげば賢くなる」と思ってしまう：最初は参照系に限定し、業務価値が高い順に接続を増やす
• 権限設計が後回し：PoCでもSSOと最小権限、ログ保存を入れて“本番想定”で検証する
• データが汚く、AIが迷う：マスタ統一、用語辞書、手順書の更新ルール整備が先
• 既存システムに負荷がかかる：キャッシュ、レート制限、夜間バッチ、DWH参照へ切替を検討
• 回答が監査で説明できない：根拠（参照元）を返す設計、ログで追跡できる設計にする
• 現場が使わない：チャットに“聞けることリスト”を置く、業務フローに組み込む、KPIを持つ

特に「書き込み系（登録・更新）」を急ぐと、事故の影響が大きくなります。例えば「取引先の振込先変更」「発注確定」「支払処理」などは、AIが関与する場合でも“提案まで”に留め、最終確定は人が承認する二段階にするのが一般的です。AIは自動化の対象というより、業務を前に進める補助者として設計すると、現場も受け入れやすくなります。

また、コスト面では「MCPサーバの構築」だけでなく、データ整備、運用設計、テスト、教育、監査対応が効いてきます。予算がある組織ほど、ツール導入だけに見積が寄りがちなので、“運用まで含めた総コスト”を最初に押さえることが重要です。

まとめ

MCPを既存システムに接続する肝は、「AIを賢くする」こと以上に、AIが触れてよい業務操作とデータを安全に定義することです。接続方式はAPI・RPA・データ連携の3系統があり、最初は参照中心の低リスク領域から始め、権限・ログ・変更管理をPoC段階から織り込むと失敗しにくくなります。

また、MCPサーバを社内ゲートウェイとして置くことで、認証情報の秘匿、入力の検証、レート制限、監査ログなどを一箇所で統制できます。結果として、社内のFAQや手順書検索から、売上・在庫・案件状況などの定型照会、さらには申請作成やレポート自動化へと段階的に広げられます。

「どこから着手すべきか」「自社の既存システムだとどの方式が現実的か」「監査や権限をどう設計するか」まで含めて整理すると、MCP接続は“PoC止まり”にならず、現場で使われる仕組みに育ちます。