
私たちのAIは存在しないホテルを予約した——そして数字はそうなると告げていた
私たちの旅行アシスタントが存在しないホテルを予約確定するのを初めて目にしたとき、デモ会場では実際に拍手が起きました。
あるテスターが、コスタリカにある1泊200ドル以下の高級エコロッジを探すよう依頼しました。モデルは「Tabacon Springs Eco-Lodge」を返してきました——美しい説明文、もっともらしい1泊料金、そして予約確認画面。読むと素晴らしい出来です。しかしそれは、Tabacon と Nayara Springs という実在する2つの施設が、1つの架空の場所に溶け合ったものでした。Tabacon Springs Eco-Lodge など存在しません。もしその画面の向こう側に家族がいたら、彼らはコスタリカまで飛び、自分たちのことなど一度も聞いたことのないフロントに到着していたでしょう。
その瞬間こそが、エージェンティックAIによる旅行予約が見た目以上に難しい理由のすべてであり、私たちがそれを正しく作れるようになる前に何を間違えていたのかを説明したい理由でもあります。手短に言えば——旅行の世界では、流暢な回答と正しい回答は別物であり、両者の隔たりは、反復すれば消せるバグではありません。それは、決定論的な仕事を確率論的なモデルにやらせることの構造的な性質なのです。
空室状況を当て推量する人間の旅行代理店員はクビになります。当て推量するAIは、その口調を褒められます——顧客が空港に立ち尽くすまでは。
取締役会は「AI戦略」を求めました。市場は彼らにパニックに陥る理由を与えました。
状況を説明しておきましょう。もしあなたが旅行管理会社やOTAでプロダクトを率いているなら、まさに今それを生きているからです。
2026年2月から4月にかけて、旅行業界の主要な流通レイヤーはことごとくエージェンティック予約を出荷または発表しました。Sabre、PayPal、Mindtrip は2月12日、業界初のエンドツーエンドのエージェンティック体験を発表しました——フライトは2026年第2四半期に一般提供、420社以上の航空会社と200万軒のホテルにまたがる Sabre の Mosaic API 上で動き、その上に Mindtrip の650万ポイントのナレッジベースが載ります。その前日には、Marriott のCEOが、Google の AI モードが OTA チャネルを完全に飛ばして Marriott を直接予約すると認めました。Amadeus は、Accenture とともに構築した Cytric Easy というジェネレーティブアシスタントを Microsoft Teams の中に組み込みました。Navan は、あらゆる旧来型TMCを鈍く見せるような数字を報告し続けています。
そこでCFOが部屋に入ってきて、なぜ「Navan のようなAIのことをやっていないのか」と尋ねます。そして、私が優秀なチームが陥るのを見てきた罠がここにあります——彼らはその問いを、チャットボットを素早く出荷せよと受け取ってしまうのです。しかし本当の問い——唯一重要な問い——は、Air Canada のように痛い目を見ずに、どうやってこれをやるかというものなのです。
私が話す買い手たちは、エージェンティック予約をやるかどうかを問うてはいません。その議論はもう終わっています。彼らが問うているのは、単一プラットフォームの在庫に会社を賭けることなく、そして自信満々に間違える機械が、自分たちが個人的に責任を負わされる法的責任を生み出すことなく、どうやってこれをやるか、なのです。
その法的責任にはすでに名前があり、あなたの法務チームはそれを知っている
なぜ旅行業界の顧問弁護士が神経を尖らせているのかを理解したいなら、必要なのはたった1つの事例だけです。
2024年2月14日、ブリティッシュコロンビア州の民事紛争解決審判所は、Air Canada のチャットボットが同社の実際の運賃規則と矛盾する遡及的な忌引運賃ポリシーをでっち上げたことを受け、Air Canada に対し Jake Moffatt に812.02ドルを支払うよう命じました。Air Canada の抗弁は、そのチャットボットは事実上、自らの発言について責任を負う独立した法的主体である、というものでした。審判所はこれを平易な言葉で退けました——企業は、その言葉が静的なウェブページから来ようとモデルから来ようと、自社の表面上にあるすべてに責任を負う、と。
812ドルは端数の誤差です。しかし判例はそうではありません。それ以降に書かれた旅行テック関連の法務メモはすべて Moffatt を引用しており、より最近の判決は、デプロイする側をまったく助けないかたちで逆方向に切り込みました——2026年1月、杭州の裁判所は、あるユーザーがチャットボットの約束を強制執行しようとした事案で、LLM のベンダーの責任を狭めました。両者を合わせて読むと、この2つの事案は同じ居心地の悪い方向を指し示しています——注意義務は、モデル提供者ではなく旅行ブランドの側に降りかかる、と。責任を OpenAI に外注することはできないのです。
そしてそれは金銭だけの問題ではありません。2025年には、観光客たちがAIプランナーが丸ごとでっち上げた「フマンタイの聖なる峡谷」を求めて、ペルー・アンデスの標高4,000メートルまで登山しました。マレーシアのあるカップルは、存在しない「Kuak Skyride」に乗るために400キロメートルを運転しました。住民33人のタスマニアの村は、一度も持ったことのない温泉についての問い合わせをさばき始めました。旅行リスク管理の規格である ISO 31030 は、旅行者の安全をデプロイする側の義務と定めています——それらの事案こそ、まさにこの規格が防ぐために存在するものです。今や観光客のおよそ4分の1が旅行計画にAIを使っている中、その被害範囲がもはや理論上のものでなくなってから、しばらく経つのです。
私が間違っていたこと——これはプロンプトの問題だと思っていた

ここからは、私が誇りに思っていない部分です。
私たちの最初のビルドは、正直に言えば、見栄えのいいラッパーでした。有能なモデル、よく作り込まれたシステムプロンプト、ホテルカタログに対する検索、きれいなチャット画面。デモの出来は良く——良すぎたために、私はハルシネーションを、より良いプロンプトとより大きな検索インデックスで絞り出せるエッジケースだと信じ込みかけている自分に気づきました。そのころ、ある投資家が私に、要するに、GPT を使えばいい、考えすぎるな、と言いました。1か月ほど、私は半分それを信じていました。
Tabacon Springs の一件がその信念を打ち砕きましたが、実際に私の考えを変えたのは、腰を据えて、それまで避けてきた計算をやったことでした。
現実的なフライト予約は、およそ10個の連続したステップからなります——意図の解析、検索、絞り込み、価格算出、仮押さえ、ポリシー確認、搭乗者情報の収集、決済への引き渡し、PNR の確定、発券。仮に——寛大に見積もって——各ステップが90%の確率で正しい確率論的なモデル呼び出しだとしましょう。エンドツーエンドでは、成功率は0.9の10乗になります。およそ34%です。
積み重なる確率論的な失敗を、プロンプトで切り抜けることはできません。誤りはステップを増やしても小さくなりません。掛け合わさっていくのです。
そして私は、社内の議論に終止符を打つ数字を見つけました。OSU NLP グループの TravelPlanner ベンチマークは、人気の ReAct パターンを使った GPT-4 が、現実的な複数日にわたる旅程を完遂する割合を測定しました——その値は0.6%でした。60%ではありません。0.6です。1,000回の旅行のうち、成功したのはわずか6回です。
人々は同じベンチマークから「97%」という数字を持ち出して振りかざしますが、ここで私は正確を期したいのです。なぜなら、それを借用すれば私たちは不誠実か世間知らずのどちらかに見えてしまうからです——その97%は、コード駆動のソルバーが、静的で凍結されたナレッジベース——OpenFlights と Yelp のスナップショット——に対して走った結果であって、モデルが生きた、変化する在庫に対して予約したものではありません。それは本番の予約の数字ではなく、それをそう引用する者は誰であれ論文を読んでいないのです。フロー全体を LLM が動かす場合の誠実な数字は、あの小さいほうなのです。
それが転機でした。問題はプロンプトなどでは決してありませんでした。問題は、そもそも私たちが確率論的なモデルを制御フローの中に置いてしまったことだったのです。
存在しないホテルをAIに予約させないためには、どうすればいいのか?

モデルをより信頼できるものにしようとするのをやめ、信頼できなければならない部分からモデルを取り除こうとし始めた途端、アーキテクチャはほとんど自ずと設計されました。
私たちが落ち着いたルールはこうです——言語モデルは言語を扱い、それ以外は何もしない。旅行者が何を意味しているのかを抽出し、結果を平易な英語で要約して返します。GDS を呼び出しません。ポリシーを確認しません。決済に触れません。それらのどれもが、ハードコードされた決定論的なロジックです。オーケストレーションはステートマシンとして走らせます——LangGraph が私たちの通常の制御プレーンですが、それに固執しているわけではありません。もしクライアントが AWS Bedrock AgentCore や Vertex AI Agent Builder の上に立っているなら、代わりにそこで構築します。
フレームワークよりも重要な細部は、型付けされた状態です。私が見てきたほとんどの本番エージェントの導入は、同じ静かな死を迎えます——状態がステップ間で静かにずれていき、誰も気づかず、エージェントは自信満々に、壊れた世界像に基づいて行動するのです。厳格な Pydantic 型の状態スキーマ——すべてのフィールドが宣言され、各遷移で検証される——こそが、それを防ぐ地味な代物です。予約が複数のコミットにまたがらなければならないとき、saga パターンがロールバックを処理します——フライトがすでに発券された後にホテルが失敗した場合、グラフは、旅行者を予約が半分だけ済んだ状態で放置するのではなく、どう取り消して巻き戻すかを知っているのです。
私たちはそれを1つのプロダクトではなく、3つのケイパビリティとして構築しました。なぜなら、すべての買い手が丸ごと必要とするわけではないからです。まず、決定論的な予約エージェント——中核です。次に、サービスとしての検証、つまり、既存のどんな旅行AIチームでも「このホテルは実在するか、この価格は最新か、この PNR は本当に確定しているか?」と問い合わせるために呼び出せる、単独のAPIです——これは、あなたがすでに出荷したラッパーの前に立つガードレールであり、法務が運営委員会で Moffatt を持ち出したときに、すべてを引き剥がすよりもはるかに安価な答えです。そして、企業の出張ポリシーや OTA の運賃規則を、強制される制約へとコンパイルし、ISO 31030 の注意義務の責務を計装し、EU AI 法の透明性要件を担う、ポリシーおよびコンプライアンスのレイヤーです。この3つがどう組み合わさるのかは、この取り組みのソリューションページにまとめました。
ポリシーの強制はプロンプトではなくコードでなければなりません。プロンプトはモデルのバージョン間でずれます。ビジネスルールにそれは許されません。
誰も提案スライドには載せない数字
出荷する前にすべての旅行チームに1つだけ腹落ちさせられるとしたら、それはハルシネーションではないでしょう。検索の経済学こそがそれです。
GDS プロバイダーは予約ごとに課金しません。彼らはセグメント検索ごとに課金します。通常は3ドルから3.50ドルに加えておよそ10%のコミッションで、投機的なショッピングにペナルティを課す look-to-book 比率を強制します。Lufthansa Group は、2026年1月1日発効で、Amadeus・Sabre・Travelport をまたいで GDS 予約手数料を再び引き上げました。さて、モデルが徹底的にやろうと判断したがために、会話のターンごとに「親切にも」4回の探索的な検索を走らせるエージェントを思い浮かべてください。OTA の3〜5%の販売者マージンでは、そのエージェントは、実際には何も予約しないチャットボットで、四半期分の利益を焼き尽くしてしまうでしょう。
これは、私が同席してきたあらゆるエージェンティック旅行のデモで最も見過ごされている項目であり、まさにそれらのデモが本番との接触に耐えられない理由です。決定論的なエージェントは検索に上限を設けキャッシュします。なぜなら、検索がその手数料に見合うかどうかを決めるのは、モデルの気分ではなく、オーケストレーションレイヤーだからです。
そしてTMCにとって、その経済学は、CFOが実際に追い求めている数字に直結します。このビルドが動かす指標は、タッチレス予約率と、その背後にあるオフラインキューの処理時間です。ハルシネーションや対応不能な予約はすべて、人間のエージェントに差し戻されるチケットです——それこそ、部屋の中の誰かが「Navan のようなAIのことをやれ」と言うときに指し示されているコストなのです。
なぜ Amadeus API の上にただ構築するだけではダメなのか?
私が高い授業料を払って学ばざるを得なかった、いくつかの現実。そして、3か月目になって誰も驚かないよう、私は今では最初のディスカバリー・コールで持ち出すものです。
もしあなたが「Amadeus API の上にただ構築する」つもりのTMCなら、自分がどのキーを持っているか確認してください。Amadeus の Self-Service Production ティアは、Flight Create Orders エンドポイントを明確に除外します——それは、彼ら自身の枠組みで言えば、旅行代理店の認定を持たない企業向けに設計されているのです。実際に注文を発行するには Enterprise が必要です。私は、そのたった1行の項目がロードマップを四半期分リセットするのを見てきました。
次に、誰もが解決済みとして扱うが実はそうではない継ぎ目があります——NDC 対 GDS です。New Distribution Capability は最初のオファーと注文には優れていますが、予約後のサービス——変更、払い戻し、不規則運航時の再予約——は、元の販売が NDC であったとしても、依然として GDS のインフラの上で走ります。本番のエージェントには、両者のあいだの二者択一ではなく、両方のパイプが必要です。そして NDC 自体も1つのものではありません——Verteil や Duffel のようなアグリゲーターを介した Level 4 の注文管理は、ほとんどのラッパーが止まってしまう Level 3 のショッピングとは別の統合です。ギャップが現実になるのは IROPS です——たった1つの気象イベントが旅行者を機体まるごと足止めにし、その一人ひとりの再予約に500ドルから2,000ドルかかります。検索はできてもサービスができないエージェントは、おもちゃです。
そして、もしあなたの設計が、エージェントがホストシステムに振り分けるのではなく直接発券を行うものなら、あなたは今や認定の領域にいます——米国では ARC で、前提条件が満たされればおよそ25日かかり、あるいは完全な IATA 認定なら6か月から12か月かかることもあります。決済の罠もあります——チャット画面がカードデータを収集した瞬間、あなたはスタック全体を PCI のスコープに引き込んでしまいます。今日のエージェンティックコマースは、依然として実際の承認を人間の決済ステップに渡しており、VGS や Checkout.com のようなプロバイダーを介したトークン化によって、カードデータをあなたの環境の外に保っています。
こうしたことは基調講演には一切出てきません。そのすべてが、本番の障害報告書に出てくるのです。
「Sabre のを、あるいは Cytric を、あるいは Navan を、ただ買えばいいのでは?」
人々は絶えず私にこう尋ねますが、私の正直な答えは彼らを驚かせます——時には、そうすべきです。
もしあなたが、Sabre の在庫を Sabre のレール上で流通させることに満足しているレジャー系OTAなら、Sabre–PayPal–Mindtrip のスタックは妥当な買い物です——ただし、Sabre にロックされた供給と、企業ポリシーレイヤーや ISO 31030 の計装の欠如を受け入れた上での話です。もしあなたが、すでに Cytric と Concur を使っている Microsoft ネイティブの企業なら、Teams の中の Cytric Easy はおそらくあなたに合っており、私はそれを率直にお伝えします。もしあなたが、TMC を丸ごと引き剥がしてAIネイティブのプラットフォームを走らせたいのなら、Navan は本当にその数字を勝ち取っています——73%のタッチレス経費、ポリシー違反は35%から5%未満へと低下——そして私は、Navan であることにかけて彼らに勝てるふりをするつもりはありません。
私たちが当てはまるのは、より狭く、特定のケースです——あなたは既存の GDS 契約と TMC との関係を維持したいと考えており、その上に、ベンダー中立な形で、しかもエージェントを買った相手の販売代理店になることなく、インテリジェンスを付け加えたいのです。それがこのビルドです。そして、私にできない部分は、はっきり口に出して言います——私たちは IATA/ARC 認定の発券代理店ではないので、発券はあなたのホストを通します。私たちはあなたの GDS の商業契約を所有していません。そして、曖昧な企業の出張ポリシーを直すことはできません——もっとも、ディスカバリーでそれを引き締めるお手伝いはします。なぜなら、曖昧なポリシーは、コードがどれほど優れていても、曖昧なエージェントを作ってしまうからです。
窓を閉ざす期限
時計についてもう1つ。EU AI 法のデプロイする側に対する透明性の義務は、2026年8月2日に施行され、高リスク分類のガイダンスは2026年2月2日にさかのぼって出されました。もしあなたのエージェントが EU の消費者と話すなら、開示は任意ではなく、「後で追加する」は、いずれ発生するのを待っているコンプライアンス上の指摘事項です。私たちは、第50条の開示画面と、ログを取って説明する監査証跡を、最初から組み込んで構築します。なぜなら、ブラックボックスのラッパーに透明性を後付けするのは、最初からそれを念頭に設計するよりもはるかに苦痛だからです。
そしてここが、そのすべてを経て私がたどり着いた場所です。流暢さは今や無料です——市場のあらゆるラッパーは自信ありげに聞こえ、旅行者はそれを読んだだけでは、本物の予約確認とハルシネーションによる予約確認を見分けられません。旅行者がいずれ見分けられるのは、到着したときにフロントにその部屋があるかどうかです。その隔たり——真実に読める文章と、真実であるPNR とのあいだの隔たり——は、モデルが大きくなったからといって閉じるものではありません。それが閉じるのは、誰かがローンチ前に、「これは実在するか?」に答えるものにモデルを決して据えない、と決断したからです。それに答える決定論的なレイヤーは地味で、デモ映えもせず、そしてそれこそが仕事のすべてなのです。
Tabacon Springs Eco-Lodge は、いまだに実在の場所ではありません。重要な唯一の問いは、あなたの顧客がロビーに立ち尽くす前に、あなたのシステムがそれを知っているかどうかです。私たちが自分たちのシステムをどうやってそれを知るように作ったのかを見てみたいなら、完全な解説はこちらです。


