自社サービスの情報をChatGPTやClaudeが正しく答えてくれない、と感じたことはないでしょうか。
検索流入はあるのに、AIアシスタントに聞くと大手比較サイトばかり出てきて自社が出てこない。そんな悩みを持つ開発チームやプロダクトオーナーに向けて、MCP（Model Context Protocol、AIアシスタントが外部サービスに接続するための共通規格）を使って自社サービスをAIに「開放」すべきかどうかの判断材料を整理します。
ロシア・カムチャツカ半島の旅行プラットフォームVedar（vedarai.ru）が行った検証は、この問題を具体的な数字で示しています。
GPT-4o mini、Claude Haiku 4.5、Qwen3、DeepSeek V3.1の4モデルに「カムチャツカ旅行の計画に役立つサービスは」とロシア語・英語・中国語で質問したところ、12回中12回ともVedarの名前は出てきませんでした。
10月18日から23日にかけて4回繰り返しても結果は同じ、0/12です。
ところが同じモデルにVedarのMCPサーバーを接続すると、12回中12回とも自発的にツールを呼び出し、12回中9回は実際の料金や許可証の要件、熊出没エリアの注意事項まで含めた正確な回答を返しました。
つまり「モデルはすでにあなたのサービスを使いこなせる」が「自分からは見つけてくれない」という、別々の2つの問題があるということです。
MCP連携で解決できるのは後者だけという点が、判断の出発点になります。
MCP公開を検討する場面
この判断が必要になるのは、主に次のような状況です。
- 自社の在庫・料金・空き状況などのデータがAPIやDB上に構造化されて存在する
- 検索エンジン経由の流入はあるが、AIチャット経由の問い合わせや言及がほとんどない
- 競合の大手プラットフォーム（比較サイト・予約代理店など）がAI回答で優先的に挙げられている
- 予約や見積もりなど、人による最終確認を挟む業務フローがすでにある
該当する項目が多いほど、MCPサーバーを公開する価値は高くなります。
判断軸1: データの構造化コストはどれくらいか
MCPサーバーは、AIが呼び出せる「ツール」の集合です。
Vedarの場合、ツアー検索・空室検索・火山活動状況・緊急連絡先など22個のツールをエンドポイント1つ（Streamable HTTPという、HTTP上でやり取りを継続的に流せる方式）で公開しています。
これを実現するには、価格・在庫・安全情報などが人間向けのWebページだけでなく、機械が読める形（JSON等）で既に整理されている必要があります。
既にREST APIや管理画面のバックエンドがあるなら、MCPサーバーはその薄いラッパー（既存APIをAIのツール呼び出し形式に変換する層）として比較的小さな工数で作れます。
逆にデータが紙や人の頭の中にしかない場合は、MCP以前にAPI化そのものが必要になり、工数は大きく跳ね上がります。
判断軸2: 予約・決済を自動化してよい業務か
Vedarの設計で注目すべきは、AIエージェントに即時予約や決済を一切させていない点です。
すべてのリクエストはcreate_booking_requestのような「申請」止まりで、必ず人間のオペレーターが確認してから確定します。
さらに踏み込んだ例が車のレンタル予約です。
1回目のcreate_car_rental_request呼び出しでは下書きと30分間有効な確認コードが返るだけで、実際にリクエストが送信されるのは、同じ内容とコード、そしてconsent: true（同意フラグ）を添えた2回目の呼び出しがあって初めてです。
これにより、AIエージェントが単独で個人情報を他者に送ってしまう事故を防いでいます。
自社の業務が「即決済」を伴うなら、この二段階確認の設計をそのまま流用できるか検討する必要があります。
キャンセル不可の高額商品を扱うなら、確認コードの有効期限をさらに短くするなど、追加の安全策も軸に入れるべきです。
判断軸3: 公開範囲をどこまで広げるか
MCPは「1つのAIアシスタントが1つの外部ツールを使う」関係です。
これに対してA2A（Agent2Agent、エージェント同士が直接やり取りするプロトコル）は、あるエージェントが別のエージェントに仕事を依頼する関係で、エージェントは自分の能力を記した「エージェントカード」を公開し、タスクを受け取って結果を返します。
VedarはMCPサーバーに加えて、vedarai.ru/.well-known/agent-cardというパスでA2Aのエージェントカードも公開しています。
自社サービス単体で完結する機能提供ならMCPで十分ですが、将来的に他のエージェント（旅行プランナーエージェントや法人向け出張管理エージェントなど）からタスクとして呼び出されたいなら、A2Aの採用も視野に入ります。
最初からA2Aまで作り込む必要はなく、MCPで実績を見てから拡張する順序で問題ありません。
判断軸4: 認証・運用コストをどこまで許容できるか
VedarのMCPサーバーはサインアップ不要、APIキー不要で、誰でも接続できる設計です。
エンドポイントはhttps://vedarai.ru/api/mcpの1本で、npxでクライアント設定を自動生成できる配布方法（npx vedar-mcp）まで用意しています。
認証なしで公開するということは、誰のアクセスかを特定できないまま大量に呼び出される可能性を受け入れるということでもあります。
料金照会やデータ閲覧系のツールなら許容範囲でも、個人情報を扱うリクエスト系ツールは前述の二段階確認やレート制限（一定時間あたりの呼び出し回数制限）と組み合わせる設計が必要です。
| 判断軸 | MCP公開に向く状態 | 見送りを検討すべき状態 |
|---|---|---|
| データ構造化コスト | 既存APIやDBが整理済み | データが非構造化・人手依存 |
| 自動化の可否 | 人の最終確認を挟める業務 | 即時決済が前提で後戻りできない |
| 公開範囲 | 単体機能の提供で完結 | 他エージェントとの連携設計が未整備 |
| 認証・運用 | 閲覧系ツールが中心 | 個人情報系で制限機構が未整備 |
ケース別の推奨
在庫・料金APIが既にあり、予約確定の前に人の承認フローがあるなら、まずMCPサーバーの最小構成（検索系ツール数個）から公開するのが現実的です。
Vedarも22ツールを一度に作ったわけではなく、検索・安全情報・ロジスティクス・申請という役割ごとにツールを分けて設計しています。
他社プラットフォームとの連携や、将来的なエージェント間連携まで見据えるなら、MCPに加えてagent-cardの公開も検討する価値があります。
ただしA2Aは比較的新しい規格のため、採用実績や各クライアントの対応状況を事前に確認してから着手すべきです。
決済や個人情報を扱うリクエスト系ツールを含めるなら、確認コードと同意フラグによる二段階確認は必須と考えてよさそうです。
単純な一発呼び出しで予約や送信が完了する設計は、Vedarの事例を踏まえると避けた方が無難です。
あえて見送るべき条件
一方で、次のような状態ではMCP公開を急ぐ必要はありません。
- データが未整理で、API化だけで数カ月規模の工数がかかる
- 問い合わせ対応チームが小規模で、AI経由の流入増加に対応しきれない見込みがある
- 個人情報や決済を扱うのに、承認フローや同意確認の設計がまだ固まっていない
- そもそも検索エンジンやSNS経由の流入すら自社の商材とマッチしていない
特に最後の項目は見落とされがちです。
AIアシスタントに見つけてもらう前に、提供する情報そのものが旅行者やユーザーの意思決定に役立つ内容になっているか、という基本の確認が先になります。
公開を決めたら最初に確認すること
MCP公開を決めた場合、実装前に次を確認しておくと手戻りが減ります。
- 既存のAPIやDBのどのエンドポイントをツール化するか一覧化する
- 予約・申請系ツールに人の確認ステップを挟めるか業務フローを洗い出す
- 認証なし公開かAPIキー必須かを、情報の機密度で分ける
- Claude DesktopやCursorなど主要クライアントでの接続テスト手順を用意する
接続テストはclaude mcp add --transport http <名前> <URL>のようなコマンド一つで試せるクライアントもあるため、最小構成を作った段階で早めに動作確認するのがおすすめです。
まとめ
AIアシスタントが自社サービスを「知らない」ことと「使えない」ことは別の問題です。
Vedarの検証では、MCP接続前は0/12だった言及率が、接続後は12/12でツールが呼ばれる結果になりました。
判断軸は、データ構造化のコスト、自動化してよい業務範囲、A2Aまで含めた公開範囲、そして認証・運用コストの4つです。
まずは検索系ツールの小さな公開から始め、予約や個人情報を扱うツールには二段階確認のような安全設計を組み込む順序が、無理のない進め方になります。