MCP（Model Context Protocol）を使って社内システムとAIをつなぐときに大切なのは、「つなげるかどうか」よりも「AIに何をさせてよいか」を先に決めることです。MCPは、AIのアプリケーションから外部のデータや機能を呼び出すための共通の接続方式で、一度社内システム側に接続口を用意すれば、複数のAIツールから同じ形で使えるようになります。便利な反面、接続口を作った瞬間に、AIから社内データを読んだり業務システムを操作したりできる経路が生まれます。どのデータを、誰の権限で、どこまで操作させるのか、その記録をどう残すのかを設計しないまま接続を広げると、情報漏えいや誤操作のリスクを抱えることになります。
この記事は、社内でAIの活用を進めている情報システム部門の担当者、業務システムの管理者、AIを使った業務改善を企画している事業責任者に向けて書いています。MCPの基本的な考え方、従来のAPI連携との違い、社内システムをつなぐときの導入手順、権限と監査の注意点を、判断の基準とチェックリストの形で説明します。
読み終えたときに、自社でMCPを使った接続を検討すべきかどうか、検討するならどのシステムのどの機能から始め、何を決めておくべきかを判断できることを目指しています。
MCPとは：AIと社内システムをつなぐ共通の接続方式
MCPは、AIのアプリケーション（チャット型のAIアシスタントや、AIエージェント、AIを組み込んだ開発ツールなど）と、外部のデータや機能をつなぐための取り決めです。用語としての詳しい説明はMCP（Model Context Protocol）のページにまとめています。
MCPでは、AIを使う側を「クライアント」、データや機能を提供する側を「サーバー」と呼びます。社内システムとつなぐ場合、社内システムの前にMCPサーバーを用意し、そこに「顧客情報を検索する」「在庫を確認する」「チケットを起票する」といった機能を並べます。AIのアプリケーションは、MCPサーバーに並んだ機能の一覧を読み取り、必要に応じて呼び出します。
従来のツール連携との違い
AIから外部の機能を呼び出す仕組みとしては、以前からFunction Calling（ツール呼び出し）がありました。Function Callingは、特定のAIアプリケーションの中で、呼び出せる機能を一つずつ定義して使う仕組みです。アプリケーションごとに同じような接続処理を作る必要がありました。
MCPは、この接続の部分を共通の形にしたものです。社内システム側にMCPサーバーを一つ作っておけば、MCPに対応したAIのアプリケーションであれば、どれからでも同じ機能を使えます。社内で複数のAIツールを使い分けている、あるいは今後ツールを入れ替える可能性がある場合に、接続の作り直しを減らせるのが利点です。
| 観点 | 個別のツール連携 | MCPによる接続 |
|---|---|---|
| 接続の作り方 | AIアプリごとに機能を定義する | 社内システム側に共通の接続口を作る |
| 複数のAIツールからの利用 | ツールごとに作り直しが必要 | 対応ツールなら同じ接続口を使える |
| 向いている場面 | 一つのアプリに組み込む専用の機能 | 社内の複数部署・複数ツールで共有する機能 |
| 権限と記録 | アプリごとに管理 | 接続口で一元的に管理しやすい |
| 注意点 | 作り直しの手間 | 接続口が広く使われる分、権限設計の影響が大きい |
ただし、MCPはあくまで接続の取り決めであり、社内システムにAPIがなければ、その部分は別に用意する必要があります。システム同士をつなぐ基本的な考え方はAPI連携とは何かで説明しています。
MCPで社内システムをつなぐと何ができるか
架空の一般例として、次のような使い方が考えられます。
- 営業担当がAIアシスタントに「来週訪問する取引先の最近の問い合わせと契約状況をまとめて」と頼むと、AIが顧客管理システムと問い合わせ管理システムから情報を集めてまとめる
- 社内の担当者がAIに「この不具合報告をチケットにして担当チームに割り当てて」と頼むと、AIがチケット管理システムに起票する
- 経理担当がAIに「今月の未入金の請求を一覧にして」と頼むと、AIが会計システムから該当データを読み取って表にする
- 開発者がAIの開発支援ツールから、社内の設計資料や過去の障害記録を参照する
いずれも、これまで人が複数の画面を開いて行っていた作業を、AIへの依頼一つで済ませられるようにするものです。一方で、どの例にも「AIが社内データを読む」か「AIが社内システムに書き込む」動作が含まれています。ここに権限と記録の設計が必要になる理由があります。
導入を検討すべきケースと、まだ早いケース
MCPを使った接続は、すべての会社にすぐ必要なものではありません。次の表で、自社の状況を確認してみてください。
| 状況 | MCPを検討する価値 |
|---|---|
| 社内で複数のAIツールが使われ、同じ社内データを参照させたい | 高い |
| 特定の業務向けにAIエージェントを開発し、社内システムを操作させたい | 高い |
| AIの利用が一部の担当者の試行にとどまっている | まだ早い。利用ルールの整備が先 |
| 社内システムにAPIがなく、データの所在も整理されていない | まだ早い。データとAPIの整備が先 |
| AIツールの利用ルールや情報の取り扱い方針が決まっていない | まだ早い。方針の策定が先 |
AIの利用ルールが整っていない段階で接続を広げると、社員が会社の把握していない形で社内データをAIに渡す状態が生まれます。これはシャドーAIと呼ばれる問題につながります。接続の技術よりも先に、どのAIツールを会社として使うか、どの情報をAIに渡してよいかの方針を決めておきます。
導入の手順
MCPで社内システムとAIをつなぐときは、次の順番で進めます。
- 目的と利用者を決める：どの部署の誰が、どんな業務でAIを使うのかを決めます。「社内のあらゆるデータにAIからアクセスできるようにする」のような広い目的ではなく、業務単位で決めます。
- つなぐシステムと機能を選ぶ：目的に必要なシステムと、その中の機能を選びます。最初は読み取りだけの機能に絞るのが安全です。
- 機能を業務の言葉で設計する：「データベースに問い合わせる」のような汎用的な機能ではなく、「取引先名から直近の問い合わせを取得する」のように目的を限った機能として定義します。
- 権限の方式を決める：AIが誰の権限でシステムにアクセスするのかを決めます。後の章で詳しく説明します。
- 記録の項目を決める：誰が、どのAIツールから、どの機能を、どんな値で呼び出したかを記録します。
- 限定した利用者で試す：一部の担当者で試験的に使い、使われ方と問題を確認します。
- 書き込みの機能を段階的に加える：読み取りで問題がないことを確認してから、書き込みの機能を、承認の仕組みと合わせて加えます。
- 利用者と機能を広げる：記録を見ながら、対象の部署や機能を広げます。
権限の注意点：誰の権限でアクセスするか
MCPで社内システムをつなぐときにもっとも重要なのが、権限の扱いです。
共通のアカウントで動かすリスク
MCPサーバーが社内システムに接続するとき、一つの共通アカウント（たとえば管理者に近い権限を持つシステム用アカウント）を使うと、作るのは簡単ですが大きな問題が生じます。本来その情報を見る権限がない社員でも、AIを通じて情報を引き出せてしまうからです。人事情報や経営資料、他部署の顧客情報などが、意図しない相手に見えてしまうおそれがあります。
利用者本人の権限で動かす
安全なのは、AIを使っている利用者本人の権限で社内システムにアクセスする方式です。利用者がAIツールでログインし、その認証情報をもとに、MCPサーバーが利用者の権限の範囲でだけ社内システムを操作します。こうした仕組みにはOAuthのような認可の仕組みが使われることが多く、社内の既存のID管理とどう組み合わせるかが設計のポイントになります。
利用者本人の権限で動かす方式は、作り込みの手間は増えますが、「AIを使っても、その人が普段見られる情報しか見られない」という分かりやすい原則を保てます。
機能の側でも絞る
利用者の権限に加えて、MCPサーバーに並べる機能そのものも絞ります。社内システムの全機能を公開するのではなく、目的に必要な機能だけを並べます。削除や一括更新のように影響の大きい操作は、MCPサーバーの機能として並べないか、並べる場合も人の承認を必須にします。
監査の注意点：何を記録し、どう見るか
AIを経由した操作は、誰が何をしたのかが見えにくくなりがちです。人が画面を操作した場合は操作者が明確ですが、AIを経由すると「AIがやった」としか記録されないことがあります。これを避けるため、MCPサーバーの側で次の項目を記録します。
- 依頼した利用者
- 使われたAIツール
- 呼び出された機能と渡された値
- 社内システムから返された結果の概要
- 書き込みの場合は、変更前と変更後の値、承認の有無
記録は、利用者やAIが書き換えられない場所に保存し、情報システム部門が定期的に確認できるようにします。特に、普段と違う量の読み取りや、深夜の大量の操作などは、自動で通知する仕組みを用意しておくと安心です。AIの操作記録と監視の設計については、AIエージェントの誤動作を防ぐ：権限制限と監視ログの設計で詳しく説明しています。
接続口の置き場所と運用体制
接続口をどこに置くか
MCPサーバーをどこで動かすかにも、いくつかの選択肢があります。代表的なのは、利用者のパソコンの中で動かす形と、社内やクラウドのサーバー上で動かして複数の利用者が共有する形です。
| 構成 | 向いている場面 | 注意点 |
|---|---|---|
| 利用者のパソコンで動かす | 個人の作業、開発者の検証、手元のファイルの参照 | 設定が利用者ごとにばらばらになりやすく、会社として把握しにくい |
| 社内・クラウドで共有して動かす | 部署や全社で同じ社内システムを使う | 認証・権限・記録の仕組みを接続口側にしっかり作る必要がある |
社内の業務システムにつなぐ場合は、共有して動かす形を基本にし、情報システム部門が管理するのが一般的な考え方です。接続口を一か所に集めることで、どのAIツールからどの機能が使われているかを把握でき、権限の変更や停止も一か所で行えます。利用者のパソコンで動かす形は、検証や個人の作業にとどめ、社内システムへの接続には使わないというルールを決めておくと、管理の抜け漏れを防げます。
誰が接続口を育てるか
MCPサーバーは、作って終わりではありません。社内システムの改修に合わせて機能を更新する、利用者からの要望を受けて新しい機能を加える、使われていない機能を整理する、といった保守の仕事が継続的に発生します。
導入の段階で、次の役割を誰が担うかを決めておきます。
- 接続口に並べる機能の追加・変更を判断する人
- 機能を実装し、社内システムの改修に合わせて保守する人
- 操作の記録を定期的に確認し、異常に対応する人
- 利用者からの問い合わせや要望を受け付ける窓口
これらの役割が決まっていないと、最初に作った機能が社内システムの改修で動かなくなったまま放置されたり、現場から要望が出ても誰も対応できなかったりします。現場で個別に作られた自動化の仕組みが管理されないまま残る問題と同じ構図で、自動化の仕組みを誰が保守するかで扱っている考え方がそのまま当てはまります。
導入前のチェックリスト
- 会社として使うAIツールと、AIに渡してよい情報の方針が決まっている
- 接続の目的と利用者が業務単位で決まっている
- つなぐシステムと機能が、目的に必要なものだけに絞られている
- 最初は読み取りの機能から始める計画になっている
- AIが利用者本人の権限の範囲でアクセスする設計になっている
- 削除や一括更新など影響の大きい操作は、公開しないか承認を必須にしている
- 依頼者・ツール・機能・値・結果を記録する仕組みがある
- 外部で公開されているMCPサーバーを使う場合、提供元と中身を確認している
- 接続を止める手段と、止める判断をする人が決まっている
よくある失敗とその避け方
汎用的な機能を一つだけ公開する
「データベースに任意の問い合わせを実行する」機能を公開すると、作るのは簡単ですが、AIが想定外のデータを読んだり書き換えたりできてしまいます。業務の言葉で目的を限った機能に分けることで避けられます。
出どころの分からない接続口を使う
インターネット上では、さまざまなサービス向けのMCPサーバーが公開されています。便利な反面、中身を確認しないまま社内のデータをつなぐと、データが意図しない場所に送られるおそれがあります。外部のものを使う場合は、提供元、処理の中身、データの送信先を確認し、社内の承認を経てから使います。
読み取りと書き込みを同時に解放する
最初から書き込みの機能まで公開すると、試験の段階で誤操作が起きたときの影響が大きくなります。読み取りで使われ方を確認してから、書き込みを段階的に加えます。
方針を決めずに現場で接続が広がる
各部署がそれぞれにAIツールと社内システムをつなぎ始めると、どこで何がつながっているのか誰も把握できなくなります。接続口を情報システム部門で一元的に管理し、新たな接続には申請と承認の手続きを設けます。
具体的な場面で考える：営業部門での段階的な導入
架空の一般例として、法人向けにサービスを提供している会社の営業部門で、AIアシスタントから顧客管理システムと問い合わせ管理システムを使えるようにする場面を考えます。
最初の段階では、「取引先名から契約状況を取得する」「取引先名から直近の問い合わせを取得する」という二つの読み取り機能だけを接続口に並べます。アクセスは営業担当本人の権限で行い、担当外の取引先の情報は、普段の画面と同じく見られないようにします。利用者は営業部の数名に限定し、一か月ほど、どんな依頼が多いか、期待と違う結果が返った場面はどこかを記録します。
記録を見ると、訪問前の情報整理には十分役立つ一方で、「商談メモを顧客管理システムに残したい」という要望が多く出てきたとします。そこで次の段階として、「商談メモの下書きを作成する」機能を加え、AIが作った下書きを営業担当が確認してから保存する形にします。既存の商談記録の上書きや削除は、接続口の機能としては並べません。
このように、読み取りから始めて、要望と記録をもとに書き込みを一つずつ、確認の手順と合わせて加えていくことで、利便性と安全性を両立させながら利用を広げられます。
よくある質問
Q. MCPを使えば、既存のシステムを改修せずにAIとつなげますか？
社内システムにAPIなど外部から使える仕組みがあれば、システム本体を大きく改修せずに、その前にMCPサーバーを置く形でつなげられることが多いです。APIがない場合は、データの書き出しや画面の操作などの別の手段を組み合わせる必要があり、安定性や保守性の面で検討が必要です。
Q. MCPに対応したAIツールはどう選べばよいですか？
MCPへの対応状況はツールや契約プランによって異なり、変わることもあります。対応の有無に加えて、社内の認証の仕組みと組み合わせられるか、データの取り扱いが自社の方針に合うか、管理者が接続先を制御できるかを確認して選びます。最新の仕様は各ツールの提供元で確認してください。
Q. MCPとAIエージェントはどう関係しますか？
AIエージェントは、目的に向かって自分で手順を考え、ツールを使って作業を進めるAIの仕組みです。MCPは、そのエージェントが使うツールを提供する接続方式の一つです。エージェントの開発の進め方はAIエージェント開発の進め方を参考にしてください。
Q. 小さな会社でもMCPを導入する意味はありますか？
使っているAIツールが一つで、つなぎたいシステムも限られているなら、まずはそのツールに用意された連携機能で十分なこともあります。複数のAIツールで同じ社内データを使いたい、自社の業務システムをAIから操作したい、といった要望が出てきた段階で検討すれば問題ありません。
Otsumuに相談できること
使っているAIツールに標準で用意された連携機能で、社内の文書やよく使うSaaSとつなぐ程度であれば、管理者の設定と利用ルールの整備で、社内でも十分に導入できます。この記事のチェックリストで方針と権限を確認し、読み取りの機能から試すところまでは、外部に頼らずに進められるはずです。
一方で、自社で開発した業務システムをAIから使えるようにしたい、利用者本人の権限で動かす仕組みを既存のID管理と組み合わせたい、操作の記録や承認の仕組みを含めて安全に運用したい、といった場合は、接続口の設計と開発が必要になります。どのシステムのどの機能から始めるべきか、社内で判断がつかない場合も、外部の視点が役立つことがあります。
Otsumuでは、AIから社内システムを使うための接続口の設計・開発から、権限と記録の仕組みづくり、AIエージェントへの組み込みまでを一貫して支援しています。目的から逆算してつなぐ機能を絞り、AIを活用した少人数の開発で小さく始めて広げる進め方を取ります。詳しくはAIエージェント開発やAPI連携開発のページをご覧ください。
自社のシステム構成でどこから始めるのがよいか、まずは状況を伺いながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01