MCPで社内ツールをAIにつなぐ前に決めるべきこと｜権限・承認・監査ログの実務設計

2026.05.31AIエージェント

1. MCP導入は「つなぐ前」が重要

MCP（Model Context Protocol）は、AIエージェントと外部ツールをつなぐための共通インターフェースとして注目されています。社内のCRM、SFA、ドキュメント管理、GitHub、チケット管理、会計システムなどをAIに扱わせると、調査、下書き、更新、レポート作成まで一気に自動化できる可能性があります。

一方で、MCPは「AIに社内ツールを使わせる仕組み」でもあります。接続した瞬間に、AIは読み取り、検索、更新、送信、削除といった操作に近づきます。便利さだけを見て接続すると、権限過多、誤操作、情報漏洩、監査不能な自動化につながりかねません。

結論から言うと、MCPで社内ツールをAIにつなぐ前に決めるべきことは、ツールの種類ではなく、誰が、どの条件で、どの操作を、どこまでAIに許可するかです。ここを決めてからMCPサーバーを設計することで、PoCから本番運用へ進みやすくなります。

2. MCPで増えるリスク

AIエージェントは、通常のAPIクライアントと違い、自然言語の指示、外部文書、ツール説明、過去の会話などをもとに判断します。そのため、MCPでツールを追加すると、従来のAPI連携とは違うリスクが生まれます。

ツール説明が攻撃面になる

MCPでは、AIがツールの説明を読み、どのツールを呼ぶかを判断します。つまり、ツール名、説明文、引数の説明もAIの判断材料になります。ここに不適切な指示や曖昧な説明が入ると、AIが本来意図しないツールを選んだり、危険な操作を実行したりする可能性があります。

ツール説明はドキュメントではなく、AIの行動に影響する設定情報としてレビューする必要があります。

権限がAI側に集まりやすい

人間が使うSaaSでは、画面上でできる操作が自然に制限されています。しかしMCP経由でAIにAPIを渡すと、「一覧取得」「詳細取得」「更新」「削除」「送信」などをまとめて公開してしまいがちです。

特に、最初のPoCで管理者トークンを使うと、動作確認は簡単になりますが、本番化時に危険な設計が残りやすくなります。

ログが不足すると事故を説明できない

AIが社内ツールを呼んだ場合、あとから必要になるのは「最終回答」だけではありません。誰の依頼で、どのツールを、どの引数で、どのデータに対して呼び、結果として何が変わったのかを追える必要があります。

監査ログがないMCP連携は、便利でも本番運用には向きません。

3. 社内ツール接続前に決める5項目

MCPサーバーを作り始める前に、最低限以下の5項目を決めておくと安全です。

1. AIに許可する操作範囲

まず、操作を以下のように分けます。

操作レベル	例	推奨方針
読み取り	顧客情報の検索、チケット一覧取得	PoCで扱いやすい
下書き	メール文案、更新案、返信案の作成	人間確認を前提にする
更新	CRMの項目更新、チケットステータス変更	承認制から始める
送信	メール送信、Slack投稿、外部通知	原則、人間承認を必須にする
削除	ファイル削除、レコード削除	初期段階では公開しない

最初は「読み取り」と「下書き」までに絞るのが現実的です。更新・送信・削除は、ログと承認フローが整ってから段階的に許可します。

2. 誰の権限で実行するか

MCPサーバーが社内システムへアクセスするとき、最初に決めるべきなのは「AIがどのアカウントとして振る舞うのか」です。ここを曖昧にしたままPoCを始めると、動作確認のしやすさを優先して、管理者権限のAPIキーや共有アカウントを使ってしまいがちです。短期的には便利ですが、そのまま本番に近づくほど、誰の判断でどのデータに触れたのかが追いにくくなります。

本番運用では、できるだけユーザー本人の権限に紐づける設計が望ましいです。営業担当者が依頼したなら営業担当者が見られる範囲だけ、情報システム部門の担当者が依頼したならその職務に必要な範囲だけ、という形にしておけば、既存の権限管理をAIにも自然に引き継げます。

もちろん、すべての社内システムが本人権限の委譲に対応しているわけではありません。その場合でも、ひとつの強いサービスアカウントにまとめるのではなく、用途別に分けるべきです。たとえば、問い合わせ調査用は読み取り専用、チケット更新用は特定項目だけ更新可、外部送信用は承認後にのみ実行可、といった形です。AIに与える権限は「便利な最大権限」ではなく、「その業務に必要な最小権限」から設計するのが基本です。

3. 人間承認を挟む条件

AIがすべてを自動実行できる状態は、一見すると理想的に見えます。依頼すればメールを送り、CRMを更新し、チケットを閉じ、必要な通知まで出してくれる。業務自動化としては魅力的です。しかし、企業利用では「速く実行できること」と「任せてよいこと」は分けて考える必要があります。

特に外部に影響が出る操作、金銭や契約に関わる操作、データを消す操作は、AIが自信を持っていても人間が一度確認すべきです。AIの判断は、入力された文脈や取得できた情報に強く依存します。前提が一つ抜けているだけで、もっともらしいが誤った操作案を出すことがあります。

初期段階で承認を挟むべき代表例は次の通りです。

外部へのメール送信
SlackやTeamsなどへの投稿
顧客情報や契約情報の更新
金額、請求、発注、在庫に関わる変更
ファイル削除や権限変更
個人情報を含むデータのエクスポート

承認画面で大切なのは、単に「実行してよいですか」と聞くことではありません。AIが何をしようとしているのか、対象データは何か、変更前後で何が変わるのか、外部に送られる情報は何かを、人間が短時間で判断できる形にすることです。承認とは、AIの作業を止めるための儀式ではなく、責任ある業務判断を挟むためのUIです。

4. MCPサーバーを誰が管理するか

MCPサーバーは、AIエージェントにとっての業務ツール窓口です。つまり、MCPサーバーを増やすことは、AIが触れる業務システムの入口を増やすことでもあります。各チームが便利だからという理由で自由に作り、自由に公開してしまうと、社内には「誰が管理しているのかわからないAI連携」が増えていきます。

これは単なる整理整頓の問題ではありません。MCPサーバーには、ツール説明、認証情報、社内APIへの接続、ログ出力、権限判定といった重要な責務が集まります。もし古いMCPサーバーが放置され、誰も使っていないと思われていたAPIキーが残っていたら、それは攻撃面にもなります。ツール説明が変更されたのにレビューされていなければ、AIの挙動が想定とずれることもあります。

本番利用では、MCPサーバーの登録、更新、廃止、権限変更を管理する責任者を決めます。さらに、コードレビュー、依存ライブラリの更新、秘密情報の保管、脆弱性対応も運用範囲に含めるべきです。MCPサーバーは「一度作って終わり」の連携部品ではなく、社内システムと同じように運用管理されるべき基盤です。