「MCP対応」で、何が保証されるのか——AI連携を選ぶ側が確認したい三つのこと

AIサービスの説明に、「MCP対応」と書かれていることがあります。

ClaudeやChatGPTから外部サービスを使える。接続方法も共通化されている。そう聞くと、ひとまず安心してよいように感じます。

この説明には、はっきりした価値があります。サービスごとに別々の接続方法を一から用意するより、共通のやり取りがある方が、つなぐ側も使う側も楽になります。

ただ、導入を決める側には、その先の確認が残ります。

つながることと、自分の仕事で使えることは別です。

この記事では、MCPの仕様をすべて覚えなくても、導入前に確認できる三つの問いをお渡しします。

「MCP対応」の一語には、四つの段階が重なって見えます

MCPは「AIのUSB-C」のようなものだと説明されます。

つなぎ方が共通になる、という点では分かりやすい比喩です。ただ、同じ端子でつながっても、機械ごとの機能や性能まで同じにはなりません。

AI連携も、次の四段階に分けると見えやすくなります。

図1｜「MCP対応」で見える範囲と、別に確認する範囲

MCPが主に整えるのは、前半の「接続」と「機能の伝え方」です。

一言でいえば、MCPは意味や成果を共通化する規格ではなく、接続の共通土台と、使える機能の約束を揃える規格です。

そのため、「MCP対応」という表記だけで、四段階すべてが終わったと考えるのは早い。一方で、最終成果まで保証しないから価値がない、と見る必要もありません。

見る場所を分ければよいのだと思います。

一つ目——この組み合わせで、実際に何ができるのか

MCPには共通の土台がありますが、すべてのクライアントと接続先が、同じ機能を持つわけではありません。

たとえば、ある接続先は検索と閲覧に対応している。別の接続先は、下書きの作成や更新までできる。さらに別の接続先は、送信や削除も扱える。いずれも「MCP対応」と表示される可能性があります。

ですから、製品名や対応マークだけでなく、何ができるかを動詞で確認します。

• 読めるのか
• 探せるのか
• 下書きを作れるのか
• 書き換えられるのか
• 送れるのか
• 削除・公開までできるのか

生成AIをつなぐ場合は、使える設定項目も確認します。

たとえば、動画の長さと画面比率は指定できても、モデルの版、乱数の固定、参照画像の重みなど、自分に必要な設定が公開されていないことがあります。AIが賢くても、操作盤に出ていない項目は使えません。

導入前に確認したいのは、次の一文です。

今回使うクライアントと接続先の組み合わせで、必要な機能と設定項目は、実際に公開されているか。

二つ目——「処理が終わった」と「仕事として合格した」を、どう分けるのか

ツールの呼び出しが成功し、エラーが出なかったとしても、業務上の答えが正しいとは限りません。

たとえば、AIにこう頼んだとします。

先月の請求書を集めて、一覧にしてください。

ここでいう「先月」は、請求書の発行日でしょうか。メールを受け取った日でしょうか。支払日でしょうか。

取消済みの請求書を除くのか。メールと共有フォルダに同じ請求書があれば、重複を消すのか。見積書や領収書は対象外なのか。

接続も検索も一覧作成も、すべて正常に終わることがあります。それでも、日付の意味や除外条件が違えば、業務上は不合格です。

これは、止まる失敗ではありません。整った表の形で返ってくるため、見つけにくい失敗です。

そこで、実行前に合格条件を置きます。

• 対象期間を何の日付で判定するか
• 含めるものと除外するもの
• 重複の扱い
• 件数や金額を何と照合するか
• 最後に誰が確認するか

MCPが接続を整え、AIが作業を進めても、業務上の合格条件は、利用する側が持ちます。

二つ目の問いは、これです。

処理の成功と、仕事としての合格を、何によって判定するか。

三つ目——どの鍵を渡し、どこで人が止めるのか

MCPという通信方式を使う判断と、公式コネクタへ権限を渡す判断は、分けて考えます。

MCPは、どうつなぐかの話です。権限は、つないだ先に何を許すかの話です。

公式の配送業者を利用すると決めても、自宅のすべての部屋の鍵まで渡す必要はありません。玄関で済む仕事なら、玄関までで足ります。

AI連携も同じです。

メールを探す仕事に、送信権限まで必要でしょうか。文章を作る仕事なら、下書きで止められないでしょうか。共有フォルダを読むだけの仕事に、削除や公開の権限まで要るでしょうか。

ここでも、サービス名より動詞を見ます。

読む／書く／送る／変更する／削除する／公開する／支払う／権限を与える

後ろへ行くほど、元に戻しにくくなります。

読み取り専用で始める。下書きまでAIに任せる。送信・削除・公開は人が確認する。こうした線は、MCPの規格ではなく、導入する側が仕事に合わせて決めます。

三つ目の問いは、次です。

何を許可し、どの操作の前に人の確認を残すか。

導入前に、この三つだけは言葉にしておく

「MCP対応」という説明を受けたとき、私は次の三つを確認します。

この三つに答えられれば、MCPの仕様を細部まで暗記していなくても、少なくとも「対応しているから大丈夫」という一語だけで導入を決める状態からは抜けられます。

逆に、答えが曖昧なら、確認すべき場所が見えています。

技術担当者や提供会社へ、具体的に聞けます。

• 「この操作はできますか」
• 「その設定項目は公開されていますか」
• 「処理が成功しても内容が違う場合、どう検知しますか」
• 「送信や削除の前に、確認を入れられますか」

大きな賛成・反対ではなく、自分の仕事に必要な条件へ下ろして話せるようになります。

私が変えたのは、結論より問いでした

私は最初、「MCPは本当に良いものなのか」と考えていました。

公式仕様を読み、反論も含めて整理するなかで、この問いは大きすぎると分かりました。

MCPには、接続を共通化し、対応する機能をやり取りするための価値があります。一方で、具体的に何が使えるか、意味どおりに処理されたか、成果物が合格したか、安全な権限になっているかは、実際の組み合わせと運用で決まります。

だから、いまは次のように見ています。

MCP対応は、接続の共通ルールがあることを示します。必要な機能、仕事としての合格、渡す権限は、別に確認します。

MCPを一律に採用する必要も、一律に避ける必要もありません。

今回の仕事では何が必要か。どこまで共通化の利益があるか。どこから先を自分たちで引き受けるか。その順で見れば、自社の判断にできます。

つながることと、意図どおり動くことは別です。

けれど、その間にある三つの確認点が分かれば、ただ警戒するのではなく、使ってよい範囲を決めて仕事を前へ進められます。

確認した資料

本稿は、MCP公式仕様の2026年7月28日版を確認して書いています。仕様は更新されるため、実際の導入時には、利用するサービスの最新の公式説明もご確認ください。

• Model Context Protocol Specification 2026-07-28（新しいタブで開きます）
• Architecture（新しいタブで開きます）
• Tools（新しいタブで開きます）
• Authorization Security Considerations（新しいタブで開きます）