MCPを企業で使う前に決めること — 接続先・権限・監査

MCP（Model Context Protocol）は、AIエージェントに外部のツール・データ・サービスを繋ぐためのオープンな標準です。対応ツールが増え、エージェントの実用性を大きく押し上げています。一方で企業の管理者から見ると、MCPはエージェントの到達範囲を拡張する仕組みでもあります。MCPを社内で使い始める前に決めておくべきことを整理します。

MCPで何が変わるのか — 能力の拡張は、接続面の拡張

MCP以前のエージェントは、主に手元のファイルとコマンドの世界で働いていました。MCPはそこに「社内DBへの問い合わせ」「チケットシステムの操作」「外部サービスの実行」を足せます。

つまりMCPサーバーを1つ繋ぐたびに、エージェントができることが増えます。同時に、誘導されたときにできてしまうことも増えます。攻撃面の観点はネットワーク側の解説（姉妹サイトのツール実行型AIエージェントの攻撃面 — MCP時代）に詳しく、ここでは「何を決めておくか」という組織側の管理に絞ります。

決めること1: 接続先 — どのMCPサーバーを公認するか

最初に必要なのは、MCPサーバーの公認リストです。確認の観点は次のとおりです。

• 提供元 — 誰が作り、誰が保守しているか。更新は追えるか
• 触れる範囲 — そのサーバーはどのデータ・システムに到達するか
• データの行き先 — サーバー経由で情報が外部サービスへ送られるか（送られるなら規約確認の対象。「学習に使われない」は十分か）

注意したいのは、MCPサーバーは便利なので現場が勝手に足したくなることです。シャドーAIと同じ構造で「シャドーツール」が生まれます。禁止だけでは同じ結果になるため、申請すれば公認リストに載る正面の手続きを用意するのが現実的です（公認AI実行環境という考え方）。

決めること2: 権限 — 繋いだ先で何をさせてよいか

MCPサーバーには、読み取り中心のもの（検索・参照）と、実行・変更を伴うもの（チケット起票、デプロイ、データ更新）があります。後者は「エージェントが業務システムを操作する」ことを意味するため、扱いを分けるべきです。

• 読み取り系 — 比較的扱いやすい一方、触れるデータの範囲で配布先を決める（機密・個人情報に触れるものは限定する）
• 実行系 — 部屋・役割を限定して配る。破壊的な操作には人の確認を挟む

「どの部屋にどのMCPサーバーを配るか」という考え方は、ワークスペース境界と相性がよく、機密の部屋には外部到達のあるサーバーを配らない、といった設計ができます（権限管理の考え方・ワークスペース設計）。なおMCPツールの配布は、プロンプト・スキルを含むAIナレッジ管理の一部として設計すると一貫します（組織のAIナレッジを共有する）。

決めること3: 監査 — 誰が何を繋ぎ、何が起きたか

MCPの利用が広がった後で、いずれ聞かれるのは「全社でどのMCPサーバーが使われているのか」「エージェントはそれで何をしたのか」です。

• 構成の記録 — 誰の環境に、どのMCPサーバーが、いつから繋がっているか
• 利用の記録 — エージェントがツールをいつ・何のために実行したか

各自のPCに各自がMCPサーバーを設定する構成では、この2つを組織として一貫して把握するのは難しくなりがちです。実行環境を会社側に集約し、MCPサーバーの配布と記録を環境の機能にすると、構成と利用の両方が把握できる形に近づきます（実行環境の監査ログ）。

まとめ

• MCPはエージェントの能力と同時に到達範囲（接続面）を広げる。便利さと管理はセットで考える
• 先に決めるのは接続先（公認リストと正面の申請手続き）・権限（読み取り系と実行系の扱い分け）・監査（構成と利用の記録）
• 野良MCPサーバーはシャドーAIと同じ構造で生まれる。禁止より公認の仕組みを先に
• 部屋単位で「どのサーバーを配るか」を設計すると、機密との分離も実装できる

接続先・権限・監査の3つを実行環境の側に持たせたのがHoko（矛）です。公認した接続先と組織の知識をワークスペース単位で配り、その構成と利用を箱の側で管理します。AIエージェント実行アプライアンスとしての全体像は製品トップにまとめました。