MCPとは？AIとカレンダー・CRM・社内データをつなぐ仕組みとセキュリティ対策

導入

• 今：AIが回答を作るだけでなく、カレンダー登録やCRM更新などの外部操作を担い始めています。
• 影響を受ける人：SaaS導入担当、情シス、DX推進、業務自動化の担当者です。
• **必要な行動：MCPの仕組みだけでなく、接続先・権限・承認・監査ログをセットで設計することが求められます。

本稿では、2026年8月31日時点で公開されているMCP仕様のうち、Model Context Protocol Specification 2026-07-28を参照して説明します。

MCPとは、AIアプリケーションが外部のデータや機能を発見し、構造化された方法で利用するためのプロトコル**です。

たとえば利用者がAIに、次のように依頼するとします。

「来週、営業担当2名と顧客が参加できる30分の候補を3つ出して。承認後に予定を作成して」

このときAIは、MCPを通じてカレンダーの空き時間を取得し、候補を整理し、利用者の承認後に予定作成の機能を呼び出せます。

MCPはAPIそのものを置き換えるものではありません。多くの場合、MCPサーバーは背後で既存SaaSのAPIを利用します。

つまり、役割は次のように整理できます。

• API：システムのデータや機能を操作する入口
• MCP：AIがその入口を見つけ、理解し、利用するための共通ルール
• **AI：依頼内容を解釈し、必要なデータや操作を選ぶ主体

重要なのは、最小権限**です。

たとえばカレンダー連携であれば、次のように権限を細かく設計します。

上記の権限名は設計例です。MCPに共通する標準Scope名ではありません。

MCP導入時のセキュリティチェックリスト

• 利用を許可するMCPサーバーを台帳で管理している
• 個人が導入した未承認MCPサーバーを本番データへ接続できない
• PoC環境と本番環境で、認証情報・ネットワーク・データを分離している
• OAuthの権限は業務に必要な範囲へ限定している
• アクセストークンをURLやチャット本文に含めない運用にしている
• AIが実行する更新・送信・削除操作に承認画面を設けている
• 実行者、利用ツール、対象データ、実行結果を監査ログに残している
• MCPサーバーの提供元、更新履歴、脆弱性対応方針を確認している
• 利用終了時にトークン、サービスアカウント、接続設定を失効できる
• 会話履歴やログに含まれる個人情報・機密情報の保存期間を確認している

現場にとって、こうした確認は負担に感じられるはずです。しかし、権限設計を後回しにした状態で対象システムを増やすと、後からの棚卸しコストはさらに大きくなります。最初の接続範囲を小さくすることが、結果として導入を進めやすくします。

実務での使い方

ここでは、MCPを業務で使う代表的な3パターンを紹介します。

パターン1：営業の日程調整を支援する

営業担当がAIに、次のように依頼します。

「A社の担当者と弊社営業2名が参加できる30分枠を3つ提示して。外部顧客向けの予定なので、社内会議は候補から除いてほしい」

想定フローは次のとおりです。

1. AIがカレンダーの空き状況を確認する
2. 参加者の予定、タイムゾーン、バッファ時間を考慮する
3. AIが候補日時を利用者へ提示する
4. 利用者が候補を選び、予定作成を承認する
5. カレンダーに予定を作成し、必要に応じて会議URLを発行する
6. 予約確定後、WebhookでCRMやチャットへ通知する

この場合、MCPはAIと日程調整機能をつなぐ役割を担います。Webhookは「予約確定」という出来事を他システムへ知らせる役割です。

日程調整とCRM登録を連携させる設計については、連携活用の記事一覧も参照すると、MCP以外の自動化手段との違いを整理しやすくなります。

パターン2：CRM情報をもとに商談準備する

AIがCRMの顧客情報、過去の商談記録、問い合わせ履歴を参照し、商談前の要点を整理する使い方です。

利用者は、次のように依頼できます。

「B社との前回商談以降の動きを要約し、次回確認すべき未解決事項を3点に整理して」

このパターンは、CRMを直接更新するよりもリスクを抑えやすく、MCP導入の最初のユースケースとして検討しやすいでしょう。

ただし、AIの要約をそのまま事実とみなさないことが重要です。回答にはCRMレコードへの参照元や更新日時を添え、利用者が確認できるようにします。

パターン3：社内規程や契約情報を検索する

法務、人事、総務などでは、社内規程や過去の契約情報を横断して探す負担が発生します。

たとえば、次のような問い合わせです。

「取引先との秘密保持契約で、過去に知的財産権の帰属を修正した事例を探して」

AIが検索を支援することで、担当者は候補文書への到達を早められます。ただし、AIの回答を法務判断そのものに置き換えるべきではありません。

検索対象の文書、閲覧できる利用者、表示できる抜粋量を制御し、原本確認へ戻れる導線を用意することが実務的です。

よくある失敗と対処

未承認のMCPサーバーを利用してしまう

開発者向けコミュニティや公開リポジトリには、多様なMCPサーバーがあります。便利な一方で、提供元や実装内容を十分に確認しないまま接続すると、認証情報や業務データを意図しない先へ渡すおそれがあります。

このような未承認サーバーは、一般に「Shadow MCP Server」と呼ばれるリスクの一つです。

対処

• 許可するMCPサーバーを台帳化する
• 提供元、ソース、更新履歴、サポート窓口を確認する
• 本番データへの接続前に検証環境で動作を確認する
• 組織管理下のMCPクライアントだけに接続先を制限する

ツールの説明文を信頼しすぎる

MCPのToolsには、AIが操作内容を理解するための説明文が含まれます。しかし、ツールの説明やメタデータが常に安全とは限りません。

悪意ある説明文や、外部データに埋め込まれた指示によって、AIが本来意図しない操作へ誘導される「ツールポイズニング」やプロンプトインジェクションが問題になります。

対処

• ツール名・説明文・実行可能な操作の変更を監視する
• 「削除」「送信」「権限変更」「外部公開」などは常に人間承認を求める
• 実行前に、対象・変更内容・影響範囲を画面に表示する
• AIの判断だけで高リスク操作を連続実行させない

権限を広く付与してしまう

導入時には「まず動かす」ことが優先され、広い権限を持つ管理者アカウントを接続してしまうことがあります。しかし、これは被害範囲を不必要に広げます。

対処

• 個人の管理者アカウントではなく、用途限定のサービスアカウントを検討する
• 読み取り専用から始める
• 作成・更新・削除は別権限にする
• 利用者の異動・退職時に権限とトークンを失効する
• 期限付きのトークンや再認証を活用する

監査ログが残らない

AIの回答だけが残り、「誰が、どのツールで、どのレコードを更新したか」が追えない状態では、問題発生時の調査が難しくなります。

対処

少なくとも以下を記録します。

• 利用者ID
• MCPクライアントとMCPサーバー
• 利用したツール名
• 実行時刻
• 対象レコードやファイルの識別子
• 実行前後の変更内容
• 承認者と承認時刻
• 実行結果・エラー内容

OWASP MCP Top 10は、MCPに関する脅威を整理する参考資料です。ただし、2026年8月時点ではベータ段階のリビングドキュメントとして扱われています。確定的な監査基準とみなすのではなく、自社のリスク評価の観点集として活用するのが適切です。

比較の観点

比較基準日：2026年8月31日

MCP、API、Webhook、A2Aは競合する技術ではなく、異なる役割を持つ仕組みです。どれか一つを選ぶというより、業務に応じて組み合わせます。

一言で表現すると、次のようになります。

• API：システムを動かす入口
• Webhook：出来事を知らせる通知
• MCP：AIが入口を安全に使うための共通ルール
• A2A：AIエージェント同士が仕事を依頼し合う共通ルール

たとえば日程調整では、MCP経由でAIがカレンダーAPIを呼び出し、予約確定後にWebhookでCRMへ通知する構成が考えられます。将来的に、営業支援エージェントが日程調整エージェントへ作業を委任する場合には、A2Aが関わる可能性があります。

MCP API 違いを検討するときは、機能の新しさではなく、「誰が判断し、どこで実行し、何を記録するか」を比較軸にするとよいでしょう。

さらに効率化するには

MCPの価値は、単発のAI連携にとどまりません。業務システムの境界を越えたときに、はじめて大きくなります。

ただし、接続先を増やすこと自体を目的にすると、権限と責任の所在が曖昧になりがちです。効率化の順序としては、次の段階が現実的です。

1. 検索・要約から始める
   CRMや社内文書を参照し、回答の品質と権限継承を確認します。

2. 人間承認付きの作成操作へ進む
   カレンダーの予定作成、CRMの下書き更新などを対象にします。

3. 定型業務をワークフロー化する
   日程調整後のCRM記録、担当割り当て、Slack通知などを標準化します。

4. 組織横断でガバナンスを統合する
   IdP、アクセス制御、監査ログ、接続先台帳を一元管理します。

MCPは、AIに「何でもできる権限」を渡すための仕組みではありません。人間の判断を取り戻しながら、定型作業を減らすための接続標準として捉えることが重要です。

これは技術選定の問題であると同時に、美意識の問題です。
便利だから接続するのではなく、利用者が自分の意思で確認し、組織が説明責任を持てる形で自動化する。その設計こそが、AIを業務の信頼に結び付ける新しい標準になるのではないでしょうか。

AIを活用した業務設計の考え方は、AI活用の記事一覧や生産性向上の記事一覧もあわせて確認すると、MCPを単独の技術ではなく業務改革の一部として捉えやすくなります。

まとめ

MCPは、AIとカレンダー、CRM、社内データ、各種SaaSをつなぐための共通プロトコルです。

導入時に押さえるべき点は、次のとおりです。

• MCPはAPIを置き換えるものではなく、AIがAPIやデータを利用するための接続層である
• Resourcesはデータ、Promptsは定型フロー、Toolsは外部操作を担う
• カレンダーやCRMの連携では、参照と更新・削除を分けて設計する
• OAuthでは最小権限を徹底し、トークンの用途と対象を限定する
• 高リスクなツール実行には、人間の承認を組み込む
• Shadow MCP Server、ツールポイズニング、監査ログ不足を主要なリスクとして管理する
• OWASP MCP Top 10は、発展途上の脅威整理として参照する

最初の一歩としては、カレンダーやCRMの「読み取り専用」ユースケースを一つ選び、接続先台帳、権限、承認、監査ログを確認することをおすすめします。

MCP導入は、AIに任せる範囲を増やす作業ではありません。組織として、どの判断を自動化し、どの責任を人が持ち続けるのかを定義する作業だと考えます。