社内システムを、
AIの手が届く場所に。

確認日：2026年7月／仕様は更新が早いため一次情報の確認を推奨

MCP（Model Context Protocol）は、AIと外部のツールやデータを繋ぐための共通規格です。「AIから使えるようにするための、標準的なつなぎ方」と考えてください。

なぜ規格が必要なのかというと、これまでは「このAIとこのツールを繋ぐ」たびに専用の実装が必要だったからです。共通規格があれば、一度MCPに対応させたツールは、対応しているAIから使えるようになります。USBのような立ち位置です。

実務で何ができるようになるかというと、たとえばこうなります。

• 社内データベースに問い合わせる：「先月の受注のうち、納期遅延が発生した案件を出して」と自然文で聞ける。
• チケット管理システムを操作する：課題の一覧を取得し、状況を整理させる。
• 社内の独自システムを扱う：標準のコネクタ一覧にない、自社だけのシステムに繋げる。

「Google DriveやSlackと接続する」でも似たようなことができました。どう違うのか整理します。

• コネクタ：画面から数クリックで接続できる。対応しているサービスが決まっている。設定が簡単で、非エンジニアでも扱える。
• MCP：設定ファイルを書く必要がある。対応するサーバーがあれば何にでも繋げる。動作を細かく制御でき、自社システムにも対応できる。

判断は単純です。**標準のコネクタで足りるならコネクタを使ってください。**設定が簡単で、運用の負担も小さいからです。MCPを選ぶのは次の場合です。

• 繋ぎたいサービスがコネクタの一覧にない。
• 社内の独自システムや基幹システムに繋ぎたい。
• Claude Codeから開発中のシステムを直接操作させたい。
• どの操作を許可するかを細かく制御したい。

コネクタ側の詳細はGoogle DriveやSlackと接続するにまとめています。まずそちらで足りないかを確認してから、MCPの検討に進んでください。

構成によって細部は変わりますが、流れは共通しています。

ここが実務で最も事故が起きやすい箇所です。

MCPサーバーが社内システムに接続するには、当然ながら認証情報（APIキーやトークン）が必要になります。この扱いを間違えると、リポジトリに認証情報をコミットしてしまうという典型的な事故が起きます。

• 設定ファイルに認証情報を直接書かない：環境変数や、各ツールが用意している安全な保管の仕組みを使ってください。
• 共有する設定ファイルと、個人の認証情報を分ける：「どのサーバーに繋ぐか」はチームで共有してよい情報ですが、「その認証情報」は個人ごとです。ここを混ぜないでください。
• 権限は必要最小限にする：接続用に発行するAPIキーは、用途に必要な権限だけを持たせます。管理者権限のキーを使い回さないこと。
• キーの棚卸しを定期的に行う：使わなくなった接続のキーは失効させます。退職者が発行したキーが生きたまま、という状態が起きがちです。

MCPは便利さと引き換えに、AIが実際にシステムを操作する状態を作ります。導入前に4つ確認してください。

いきなり基幹システムに繋ぐのは筋が悪い進め方です。順番があります。

• 1. 既製のMCPサーバーで効果を確認する：公開されているものを1つ選び、読み取り専用で試します。ここで「本当に業務が楽になるか」を判断します。
• 2. 影響の小さい社内システムで試す：止まっても業務が止まらないシステムから。テスト環境があれば、まずそこで。
• 3. 効果が確認できたものだけ本番に広げる：全部繋ぐ必要はありません。実際に使われている接続だけを残します。
• 4. 運用ルールを決めてから展開する：認証情報の管理、権限の範囲、棚卸しの頻度。これを決めずに広げると、あとから収拾がつかなくなります。