LLM（大規模言語モデル）を使ったエージェントに「来週、家族で新宿近くの5つ星ホテルを予算内で探して」と頼んでも、そのままでは答えが返ってきません。LLMの知識は学習した時点で止まっており、今日のホテル料金や空室状況は知らないためです。
外部の最新データとLLMを繋ぐ仕組みとして、MCP（Model Context Protocol、AnthropicがLLMと外部ツール・データを接続するために策定したプロトコル）を使う設計が広がっています。旅行系のAIアシスタントを開発していて、ホテル検索や航空券連携をどう実装するか検討している方に向けて、MCPサーバーの選び方を整理しました。
どんな場面でこの判断が必要になるか
AIエージェントに「実データを検索・比較・推薦」までやらせたい場面では、必ず外部APIとの接続方法を選ぶ必要があります。
選択肢は大きく3つです。ホテル会社の独自APIを直接叩く方法、汎用のREST APIをラップする方法、そしてMCP対応のサーバーに接続する方法です。
どれを選ぶかで、エージェント側の実装量とメンテナンスコストが大きく変わります。特に個人開発者や小規模チームでは、この選定を誤ると後から作り直しになりかねません。
判断軸1: プロトコルの種類
最初に確認すべきは、そのサービスがネイティブMCP（独自RPCやカスタムラッパーではなく、MCP仕様に準拠した実装）を提供しているかどうかです。
MCPには通信方式がいくつかありますが、現行の実装で推奨されているのはstreamable-httpです。これはHTTP上でストリーミング応答を扱える方式で、以前使われていたsse（Server-Sent Events、サーバーからの一方向配信）や、単純なpolling http（定期的に問い合わせる方式）よりも低遅延で応答を返せます。
独自RPC（Remote Procedure Call、独自形式の関数呼び出しプロトコル）でラップされたAPIは、一見便利に見えても、LLMのツール呼び出し標準に乗らないため、エージェント側で個別の変換コードを書く必要が出てきます。接続前に、提供元のドキュメントやGitHubリポジトリでmcpServers設定例が載っているか、typeフィールドにstreamable-httpと明記されているかを確認してください。
判断軸2: 個人開発者がアクセスできるか
2つ目の軸は、法人契約や月間取引量の証明なしに使い始められるかどうかです。
旅行系のAPIは伝統的に、旅行代理店向けのB2B契約が前提になっているケースが少なくありません。企業ライセンスや売上分配契約が必須の場合、検証段階で採用するハードルが一気に上がります。
無料のAPIキー発行だけで動作確認ができるサービスであれば、プロトタイプ段階での検証コストを最小限に抑えられます。まずは公式サイトでサインアップ導線を探し、「Get API key」のようなセルフサービス型の申し込みがあるかを見てください。
判断軸3: データソースの一貫性
3つ目は、複数のドメイン（ホテル・航空券・レンタカーなど）を扱うエージェントを作る場合に効いてくる軸です。
ホテルのデータをA社から、航空券のデータをB社から取得する構成だと、料金の通貨単位や更新タイミングがずれることがあります。その結果、「3日間の東京旅行で総予算4000ドル」のような横断的な予算配分の提案が、エージェント内部で矛盾を起こしやすくなります。
同一プロバイダーが複数の旅行データを提供している場合、少なくとも料金体系や在庫更新の粒度は揃っている可能性が高く、比較ロジックをシンプルに保てます。単一ドメインのアシスタントを作るなら、この軸の優先度は下げて構いません。
選択肢の比較
| 方式 | 実装の手間 | 個人開発者の利用しやすさ | 向いているケース |
|---|---|---|---|
| 独自RPC / カスタムAPI | 大きい（個別実装が必要） | 契約次第で低いこともある | 既存システムとの統合が最優先の場合 |
| MCP対応（sse/polling） | 中程度 | 中程度 | レガシーなMCPサーバーしか選べない場合 |
| MCP対応（streamable-http） | 小さい（標準ツール呼び出しで完結） | APIキーのみで検証しやすい | 新規にエージェントを設計する場合 |
実装面では、search-hotels（場所・星評価・タグで検索）、hotel-detail（部屋タイプと料金をリアルタイム取得）、hotel-tags（有効なタグ辞書を取得）のように、ツールが役割ごとに分割されている設計が扱いやすいです。エージェントに検索前にhotel-tagsを呼ばせておくことで、タグ名を推測させずに済み、検索の失敗率を下げられます。
ケース別の推奨
次のような条件に当てはまる場合は、streamable-http方式のMCPサーバーを優先して選ぶのが妥当です。
- 個人または小規模チームでプロトタイプを検証したい
- LLMエージェントのツール呼び出し機能（function calling）をすでに使っている
- ホテルと航空券など複数ドメインを1つのエージェントでまとめて扱いたい
- 自然言語の入力から数秒以内に実データを返す応答性が必要
逆に、既存の社内システムに深く統合されたAPIがすでにあり、法人契約や独自認証基盤との連携が前提になっている場合は、無理にMCPへ乗り換える必要はありません。移行コストが検証価値を上回ることがあります。
あえて見送るべき条件
以下のような状況では、MCP採用を急がない方が無難です。
- 扱うデータドメインが1つだけで、既存APIが安定稼働している
- 月間リクエスト数が極端に多く、レート制限やSLA（サービス品質保証）を個別交渉する必要がある
- エージェント側がまだfunction callingやツール呼び出しに対応していない
- セキュリティ要件でAPIキーの外部サーバーへの送信自体が禁止されている
これらに該当する場合は、まず既存の統合方式を維持しつつ、MCP対応は次のフェーズの検討事項として棚上げするのが現実的です。
導入前に確認すること
MCPサーバーを選ぶ際は、通信方式がstreamable-httpかどうか、個人開発者でもAPIキーを取得できるか、扱いたい複数ドメインのデータが同一提供元でまかなえるかの3点をまず確認してください。
実際に試す際は、mcpServers設定にエンドポイントURLと認証ヘッダーを記述し、search-hotelsのような検索系ツールから呼び出しを始めると、応答速度と精度の感触がつかみやすくなります。
自然言語入力から実データ取得までのエンドツーエンドの遅延も、検証段階で必ず計測しておく価値があります。数秒単位の遅延がユーザー体験にどう響くかは、実際にログを取ってみないと分かりません。