MCP を社内で使いたいが、どこまでつないでよくて、どう認証し、どう監査すれば事故らないのか分からない。そう感じている人向けの記事です。
ローカルで 1 人が GitHub や Sentry をつなぐだけなら、MCP はかなり簡単です。問題は、これをチームや会社に広げた瞬間に起きます。誰がどのツールを使えるのか、退職者の権限をどう止めるのか、バックグラウンドジョブに人間のトークンを持たせていないか、未承認サーバーを勝手に追加できないか。このあたりを曖昧にしたまま増やすと、MCP は便利な統合層ではなく、監査不能な抜け道になります。
この記事では、MCP の企業運用で最低限そろえるべき論点を、認証、監査、配布統制の3軸で整理します。個人利用の入門ではなく、組織で配る前提の設計ガイドとして読んでください。複数エージェントや常駐ワーカーまで含めた設計に広げる場合は、マルチエージェントオーケストレーション 4パターン解説 も補助線になります。AI コーディング全体の社内ルールやレビュー境界を先に固めたい場合は、AIコーディングツールの社内ガイドライン とセットで読むのがおすすめです。
まず結論: Enterprise では「つなぐ」より先に「誰の権限で動くか」を決める
MCP 導入で先に議論されがちなのは、どのサーバーをつなぐかです。GitHub、Slack、Sentry、Notion、社内DB、ブラウザ操作。ですが実務では、その前に決めるべきことがあります。
- そのツール呼び出しは人間の代理なのか
- バックグラウンドジョブなのか
- 会社の SSO と連携した中央管理対象なのか
この切り分けを飛ばして「とりあえず OAuth でつながったから OK」にすると、あとで運用が壊れます。
典型的な失敗は次の3つです。
- 個人の OAuth トークンをそのまま自動化ジョブに流用する
- stdio サーバーを
npxで自由に増やせる状態にする - 監査ログがアプリ側と IdP 側に分散し、後から誰が何をしたか追えない
MCP の導入設計は、AI エージェントの話というより 権限設計の話 です。組織全体の利用ルールを先に整理したい場合は、AIの組織利用ガイドも合わせて読んでください。そのうえで、開発現場に配る具体的な禁止事項や承認フローまで必要なら、AIコーディングツールの社内ガイドライン を併読した方が早いです。組織レベルの方針と、開発チームに配る実務テンプレを分けておくと運用が崩れにくくなります。
認証方式は3種類に分けて考える
MCP を企業で運用するとき、認証を1つの箱で考えない方がいいです。少なくとも次の3種類に分けると整理しやすくなります。
1. 人間が対話しながら使うなら OAuth
開発者や業務担当者が Claude Code や対応クライアントから MCP サーバーを使う場合、基本はユーザー単位の OAuth が起点です。
この方式が向いているのは、次のようなケースです。
- GitHub の issue や PR を自分の権限で読む
- Sentry や Notion を自分のアカウントで参照する
- 作業のたびに、どの SaaS に接続するかを明示したい
このとき重要なのは、MCP サーバーの認証成功 = 運用安全 ではないことです。ユーザー権限がそのまま AI エージェントに渡るので、権限過多の SaaS アカウントを使っていれば、そのまま過大権限になります。
つまり Enterprise で最初にやるべきことは、MCP 導入そのものよりも、連携先 SaaS の権限棚卸しです。
2. CI や定期実行は Client Credentials に分ける
人間がいないバックグラウンド処理まで同じ認証で回すのは危険です。
MCP の公式拡張では、機械対機械向けに OAuth Client Credentials が定義されています。これは次のような用途向けです。
- CI/CD から MCP ツールを呼ぶ
- 定期ジョブがレポート収集や同期処理を行う
- 常駐ワーカーがイベント駆動で社内ツールを叩く
ここでの実務上の判断基準は明快です。人が承認すべき操作を、機械アカウントに寄せないことです。
たとえば、日次の監視集計や read-only なデータ取得は機械アカウントに向いています。一方で、PR のマージ、課金設定の変更、本番データの削除のような操作は、M2M に寄せず人間承認を残した方がいいです。
3. 社内標準として配るなら Enterprise-Managed Authorization
会社全体に標準配布するなら、最終的には IdP 連携と中央統制が要ります。MCP の拡張には Enterprise-Managed Authorization もあり、中央の認証基盤とポリシーで制御する前提が見えています。
実務では、ここを「将来やればいい」と後回しにしない方がいいです。理由は単純で、社員数が増えてから個人 OAuth ベースの運用を巻き取るのはかなり痛いからです。
最初から以下を前提にすると、後戻りが減ります。
- 誰がどの MCP サーバーに接続できるかをグループで管理する
- 退職・異動時に IdP 側で権限を止められるようにする
- ローカル設定ではなく、中央配布ファイルかポリシーで接続先を絞る
サーバー種別ごとに信頼境界を分ける
MCP は「何でもつなげる」が強みですが、Enterprise ではそこが危険にもなります。特に、remote HTTP と local stdio を同列に扱わないことが大事です。
Remote HTTP を標準にする
クラウドサービスや社内共通基盤とつなぐなら、原則は remote HTTP を標準にした方が運用しやすいです。
理由は3つあります。
- 認証を OAuth や社内プロキシで集約しやすい
- 接続先 URL を allowlist で管理しやすい
- 監査ログをサーバー側で集約しやすい
逆に stdio は、実行コマンドそのものが攻撃面になります。npx や任意の Python スクリプトを自由に起動できる状態では、「MCP サーバー追加」がそのまま未承認コード実行になります。
Local stdio は例外扱いにする
stdio を全面禁止にする必要はありません。ただし、使うなら条件を絞るべきです。
- 管理端末だけで使う
- 実行コマンドを固定する
- 配布元とバージョン管理を決める
- secrets を個人ファイルに散らさない
Claude Code には managed-mcp.json による固定配布や、allowlist / denylist による制限があります。Enterprise で自由追加を許すなら、少なくとも serverCommand と serverUrl の制限は入れておいた方がいいです。ここを文書だけで曖昧にせず、実際の運用ルールに落とすときは AIコーディングツールの社内ガイドライン の「許可操作」「MCP / 外部連携」「監査」章と対応づけると、情シスと開発側の認識がずれにくくなります。
この話はセキュリティだけでなく、運用品質の均一化にも効きます。チームごとに別々の MCP サーバーを勝手に足し始めると、再現性もトラブルシュート性も落ちます。
監査で見るべきは「誰が何を呼んだか」より「どの権限束で何が起きたか」
MCP の監査でありがちな誤解は、「ツール呼び出しログだけ取れば十分」という考え方です。実際には、それだけでは足りません。
最低限必要なのは次の4点です。
- どのユーザーまたはサービス主体が呼んだか
- どの MCP サーバー、どのツール、どの接続先を使ったか
- その時の認証方式は何か
- 成功時だけでなく拒否・失敗も残っているか
特に重要なのは 拒否ログ です。allowlist で弾かれた、OAuth に失敗した、scope が足りなかった、未承認 URL だった。こうした失敗は事故の前兆です。
また、プロンプトインジェクション対策の観点でも、外部コンテンツを読む系サーバーは別枠で見た方がいいです。Claude Code の公式ドキュメントでも、信頼していないサーバーや未検証コンテンツを取ってくるサーバーには注意が必要だとされています。
AI コーディング全体の安全運用については、バイブコーディングの脆弱性チェックリストとパッケージハルシネーション攻撃の解説が前提知識として役立ちます。
配布統制は「全部禁止」か「全部自由」ではなく、3段階で考える
実務では、MCP 配布統制を次の3段階で考えると分かりやすいです。
レベル1. 固定配布
IT または基盤チームが managed-mcp.json で固定セットを配る方式です。もっとも安全で、教育コストも低いです。
向いているのは:
- 全社導入の初期段階
- 規制産業
- 社内の AI 利用ルールがまだ固まり切っていない時期
レベル2. 許可制セルフサービス
allowlist / denylist を敷いた上で、一部の追加を現場に任せる方式です。
向いているのは:
- 開発チームごとに必要なツールが違う
- 中央チームだけでは導入速度が追いつかない
- ただし無制限追加は避けたい
レベル3. 完全自由
個人判断で何でも追加できる方式です。個人検証なら便利ですが、Enterprise の標準運用としては基本おすすめしません。
理由は、事故率だけでなく、棚卸し不能になるからです。どのチームがどの MCP サーバーに依存しているか分からない状態では、障害時も監査時も詰みます。
導入順序は「便利そうなツール」ではなく「監査しやすい用途」から
私なら、MCP の社内導入は次の順番で進めます。
- read-only な SaaS 参照系から始める
- 機械アカウントが必要な自動化は分離する
- 書き込み系ツールは承認フロー付きで限定公開する
- 最後に自由追加の余地を検討する
最初から DB 書き込み、Slack 送信、デプロイ操作まで一気に広げると、便利さは出ますが、運用ルールが追いつきません。
特に AI エージェント文脈では、「できることが多いほど良い」は危険です。Harness 側の制御設計が先です。この考え方は、Harness Engineering の解説ともつながっています。
Enterprise 運用で最低限持つべきチェックリスト
導入前に、最低限これだけは確認した方がいいです。
- 人向け OAuth と機械アカウントを分離しているか
- 各サーバーの最小権限 scope が決まっているか
- allowlist / denylist で未承認サーバーを止めているか
- stdio の実行コマンドを固定・棚卸しできているか
- 失敗ログと拒否ログを含めて監査できるか
- 退職・異動時に IdP または中央設定で止められるか
- 外部コンテンツ取得系サーバーを高リスク扱いしているか
これを満たしていないなら、MCP サーバーの数を増やすより、まず運用台帳と配布ルールを整備した方がいいです。
まとめ
MCP の Enterprise 運用で本当に問われるのは、接続数ではありません。認証主体の分離、配布統制、監査可能性です。
個人利用では「つながるかどうか」が主な論点ですが、組織利用では「誰の権限で、どの境界を越え、あとから説明できるか」が主論点になります。
MCP は強いです。ただし、強いからこそ、運用設計が弱い組織ほど事故ります。
最初にやるべきことは、派手なデモではありません。人向け OAuth、機械アカウント、中央統制の3つを分け、remote HTTP を標準にし、allowlist と監査を先に置くことです。そこまでやって初めて、MCP は「AI を便利にする統合層」ではなく、企業で回せるインターフェースになります。