OTA（Online Travel Agent）やTMC（Travel Management Company）でプロダクト開発に関わっている方なら、自動予約システムの実行エラーに直面した経験があるかもしれません。
旅行サイトやホテル予約システムの自動化は、システム開発の現場において非常に難易度の高い課題です。
多くのプロジェクトでは、SeleniumやPuppeteerなどのツールを使ってXPathやCSSセレクタをメンテナンスしています。しかし、旅行サイトはABテストでUIが頻繁に変わり、季節ごとにキャンペーンのポップアップが表示され、在庫も常に変動します。
これらの変化にルールベースで対応するのは、変化し続ける迷宮の地図を手書きで毎日更新するようなものです。そのアプローチには、運用コストの観点からも限界があります。
そこで今注目すべきなのが、LLM（大規模言語モデル）を搭載し、ブラウザを操作する新しい技術、Web Agents（ブラウザ操作AI）です。
今回は、従来の自動化ツールがなぜ旅行予約で失敗しがちなのか、そしてWeb Agentsを使えばどうやってその壁を突破できるのか、その設計思想と実装のポイントを論理的に解説します。
AIはあくまで課題解決の手段です。単なる最新ツールの紹介ではなく、「動かない自動化」から脱却し、ビジネス価値を生み出す実用的なエージェントを構築するためのロジックを体系的に見ていきましょう。
なぜ旅行予約の自動化は「ルールベース」では失敗するのか
まず、根本的な課題を整理しましょう。チームが構築したスクレイピングボットやRPAシナリオが壊れやすいのは、エンジニアの技術力不足ではなく、採用しているアプローチと対象の性質がミスマッチを起こしているからです。
動的なDOM構造と頻繁なUI変更の壁
従来の自動化ツールの多くは、WebページのHTML構造（DOM）に依存しています。「IDがsubmit-btnの要素をクリックする」といった命令を記述することになります。
しかし、現代のWebサイト、特にReactやVue.jsなどで構築された旅行サイトは、DOM構造が非常に動的です。クラス名がcss-1a2b3cのようにハッシュ化されて毎回変わったり、要素のネスト構造が非同期読み込みのタイミングで変化したりします。
さらに厄介なのが「Shadow DOM」やiframeの多用です。これらは従来のセレクタではアクセスしづらい「壁」となります。その結果、サイト側のエンジニアが少しデザインを調整しただけで、自動化スクリプトは対象を見失い、エラーを吐いて停止してしまいます。
これを防ぐために「より堅牢なXPathを書く」という対症療法に陥りがちですが、それは根本的な解決にはなりません。
在庫切れ・価格変動という「不確実性」への対応
技術的なUIの問題以上にプロジェクトを悩ませるのが、旅行商品特有の性質です。
RPAは基本的に「一本道」のシナリオを得意とします。「検索して、一番上のホテルを選んで、予約する」という手順です。しかし、実際の運用では以下のような事象が頻発します。
- 検索結果をクリックしたら「ただいま満室になりました」と表示される。
- 予約確認画面で「料金が変更されました」とアラートが出る。
- 突然「朝食をつけますか？」というモーダルが出る。
ルールベースのスクラクプトでこれら全ての例外を網羅しようとすると、if-elseの分岐が極めて複雑になり、メンテナンスが困難になります。例外処理だけでコードの大部分を占め、技術的負債が膨らむ原因となります。
RPAの限界とAIエージェント（Web Agents）の登場
そこで解決策として浮上するのが、Web Agentsという概念です。
これは、あらかじめ決められた手順を愚直に実行するのではなく、「画面を見て（Vision）、状況を理解し（LLM）、次に何をするべきか判断する（Planning）」という自律的なプロセスを実行します。
例えば、予期せぬポップアップが出た時、RPAならエラーで停止しますが、Web Agentsは「これは広告だ。閉じるボタンは右上にある」と判断して操作を継続できます。DOMのIDが変わっていても、「『予約する』と書いてある赤いボタン」という視覚情報や意味論的な情報でターゲットを特定可能です。
この「柔軟性」こそが、不確実性の高い旅行予約という領域で真に求められていたアプローチです。
成功率99%を目指すWeb Agents設計の3つの基本原則
「AIを使えばすべて解決する」と考えるのは危険です。LLMは強力な手段ですが、不適切な操作はビジネス上のリスクに直結します。実運用における安定性とROIを確保するためには、明確な設計原則が不可欠です。
原則1：ステートレスな視覚的理解（DOMではなく見た目で判断）
最も重要なのは、「HTMLよりも、スクリーンショットやレンダリング結果を信じる」というスタンスです。
ChatGPTやClaudeの最新モデルをはじめとするマルチモーダルLLMは、画像の理解力が飛躍的に向上しています。これを利用し、Webページを人間が見ているのと同じ「画像」としてAIに認識させることが、動的なUI攻略の鍵となります。
具体的には、DOMツリーをすべてテキストで渡すのではなく、アクセシビリティツリー（簡略化された構造）とスクリーンショットを組み合わせて渡します。これにより、「IDは変わっているが、人間には同じボタンに見える」要素を、AIが視覚情報に基づいて柔軟に操作できるようになります。
原則2：自己修復的なナビゲーション（エラーからの自律復帰）
エージェントには「失敗する権利」と「やり直す能力」を与える設計が必要です。
従来のRPAは一度つまずくとそこで処理が終了していました。しかし、Web Agentsには「再考（Reflection）」のループを組み込みます。最新のエージェント設計では、計画（Plan）と実行（Execute）を分離し、エラー発生時にAI自身が原因を分析するフローが推奨されています。
例えば、日付選択でエラーが出たとします。エージェントは画面上の「無効な日付形式です」という赤い文字を読み取り、「入力形式が間違っていたようだ。次はYYYY/MM/DDではなくYYYY-MM-DDで試してみよう」と論理的に判断して再実行します。この自己修復ループ（Self-Correction）こそが、夜間のバッチ処理などを安定して継続するための要となります。
原則3：Human-in-the-loop（最終確認の人間介在）
どれほどAIが進化しても、クレジットカード決済や確定ボタンの押下といったクリティカルな操作を完全に無人で行うのはリスクが高いと考えられます。
特にB2Bの出張手配などでは、間違った予約は直接的な金銭的損失に繋がります。そのため、「検索・選定・入力まではAIが担当し、最後の『確定』ボタンを押す前に人間に通知する」というフローを基本とすべきです。
最近のAIエージェント開発ツール（Claude Codeなど）でも、重要な変更前にユーザーの承認を求める「検証ループ」がベストプラクティスとされています。Web Agentsにおいても、AIが準備を整えて待機し、人間が最終判断を下す協働モデルが、安全性と業務効率のバランスにおいて最適解と言えるでしょう。
ベストプラクティス①：曖昧な検索条件を「実行可能な操作」に変換する
ここからは、より実践的な実装のポイントに入っていきます。
旅行予約の最初のハードルは、ユーザーの要望が曖昧な点です。「来月の週末で、東京のホテル、予算は安く」といった自然言語の指示を、どうやって具体的なWeb操作に落とし込むかが問われます。
自然言語の要望を検索フィルタにマッピングする技術
まず、プロンプトエンジニアリングを用いて、自然言語の要望を「構造化データ（JSON）」に変換するフェーズを設けます。
ブラウザを直接操作させる前に、論理的な思考のステップを挟むことが重要です。
// ユーザー要望：「来月の週末、東京、禁煙、朝食付き」
// ↓ LLMによる変換
{
"location": "Tokyo",
"check_in_candidates": ["2024-06-01", "2024-06-08", "2024-06-15"],
"filters": {
"smoking": "non_smoking",
"meal": "breakfast_included"
}
}
このようにパラメータ化することで、エージェントは「何を探すべきか」を明確に定義できます。このJSONを元に、サイト上の「検索条件フィルタ」を正確に操作させます。
「安い順」「評価が高い順」の定性的な判断ロジック
「いい感じのホテル」という主観的な条件は、システムが処理できる定量的なソート条件に翻訳する必要があります。
ここでエージェントに「ペルソナ」を与えることが有効に機能します。「あなたは出張経費を抑えたい企業の担当者です。価格の安さを優先しつつ、清潔感（評価3.5以上）は確保してください」といったシステムプロンプトを設定します。
これにより、検索結果一覧画面で「価格の安い順」にソートし、上から順に「評価スコア」を目視（OCR）して、条件に合致するものをクリックするという、人間に近い動作が可能になります。
日付・エリア選択のハルシネーション対策
カレンダーUIの操作は、LLMが苦手とする部分の一つです。「来週の金曜日」が具体的に何日なのかを計算ミスするケースが散見されます。
実践的な対策として、現在日時（Today's Date）をシステムプロンプトに明記します。そして、Pythonなどのコード実行環境（Code Interpreter的な機能）をエージェントに持たせ、日付計算はLLMの言語能力に頼るのではなく、Pythonのdatetimeライブラリに行わせるのが確実です。
「言語モデルに計算をさせるな、コードを書かせろ」は、Web Agentsを安定稼働させるための重要なセオリーです。
ベストプラクティス②：複雑な予約フローにおけるコンテキスト維持
検索が完了しても、課題は残ります。一覧画面から詳細画面へ、そしてプラン選択、オプション選択、個人情報入力と、旅行サイトの画面遷移は非常に複雑です。
セッション維持と多段階遷移の管理
Web Agentsにとっての大きな課題は「忘却」です。ページ遷移を繰り返すうちに、最初の「予算2万円以下」という重要な制約を忘れてしまうことがあります。
これを防ぐために、「グローバルコンテキスト」と「ローカルコンテキスト」を明確に分けて管理するアーキテクチャを採用します。
- グローバルコンテキスト: ユーザーの要望、予算、必須条件（常にプロンプトに保持する）
- ローカルコンテキスト: 現在の画面で見えている情報、直前の操作結果
LangChainなどのフレームワークを使用する場合、現在はlangchain-coreを中心としたモジュール構成において、より高度なメモリ管理が可能になっています。単に過去の操作履歴（History）をすべて保持するのではなく、会話の要約や重要なステート（状態）のみを抽出して引き継ぐ設計が不可欠です。
また、セキュリティの観点も忘れてはいけません。最新のフレームワーク動向では、データの読み込み処理（シリアライズ/デシリアライズ）における脆弱性対策が強化されています。開発時には必ず公式ドキュメントで推奨される最新のセキュリティパッチが適用されたバージョンを使用し、信頼できないデータの処理には十分な検証を行ってください。
オプション選択（朝食・禁煙等）の動的ハンドリング
詳細画面では、チェックボックスやラジオボタンが大量に並びます。「禁煙ルーム」を選んだはずが、プランによっては「喫煙（消臭対応）」しか空いていない場合もあります。
ここでAIに適切な判断をさせるためのロジックとして、「優先順位リスト」を持たせます。
- 完全禁煙
- 禁煙フロア
- 消臭対応
このように妥協の順位を事前に定義しておき、画面上のテキストを読み取って、最適な選択肢をクリックさせます。LLMであれば「この選択肢は『禁煙』の意味に近いか？」を意味論的に判定できるため、柔軟なハンドリングがスムーズに実装できます。
個人情報入力時のセキュリティとPII保護
ここで、プロジェクトマネージャーとして特に注意を払うべきセキュリティについて触れておきます。
Web Agentsにクレジットカード番号やパスポート番号などのPII（個人識別情報）を直接プロンプトに埋め込んで渡すのは厳禁です。LLMのプロバイダ（OpenAIなど）に機密データが送信される重大なリスクがあります。
セキュアな実装としては、「ローカル変数参照」を活用します。AIには「クレジットカード入力欄には、変数{{CREDIT_CARD_NUM}}を入力せよ」という指示だけを与え、実際のブラウザ操作（typeコマンドなど）を実行する際に、ローカル環境のセキュアなストレージから値を注入します。
AIは「変数を入力した」ことだけを知っており、中身の数字は知りません。この設計により、クラウドAIを利用しつつも高い安全性を担保できます。
ベストプラクティス③：在庫切れ・エラー発生時の自律的回避策
最後に、旅行予約特有の「在庫切れ」という例外事象への対応です。
「空室なし」検知時の代替プラン提案ロジック
予約ボタンを押した瞬間に「申し訳ありません、満室です」と表示されることは日常茶飯事です。AIにも人間と同じように柔軟に対応させる必要があります。
ここで重要になるのが「終了条件（Success Criteria）の再定義」です。
単に「予約完了画面が出たら成功」とするのではなく、「予約完了画面が出るか、もしくは全候補が満室だと確認できたら終了」と論理的に定義し直します。
エラーメッセージをVisionで検知したら、エージェントは以下のフローを実行するように指示します。
- エラー内容を理解する（「満室」なのか「システムエラー」なのか）
- 「満室」なら、ブラウザバックする
- 検索結果一覧に戻り、除外リストに今のホテルを追加する
- 2番目の候補を選択する
この「除外リスト（Negative Feedback）」を動的に更新しながらループを回すことで、AIは自律的に候補を試し、予約可能なホテルを見つけ出します。
予期せぬポップアップ（広告・クーポン）の処理
旅行サイトは、ユーザーを引き留めるためのポップアップが非常に多い傾向があります。「今なら割引！」といった表示です。
これらはDOM構造上、メインコンテンツの上に表示され、必要な操作をブロックしてしまいます。
Web Agentsには、各ステップの初めに「妨害要素の排除（Clean Up）」というサブタスクを実行させます。画面を見て、メインの操作対象（予約ボタンなど）が隠れている場合、「×ボタン」や「閉じる」といったテキストを持つ要素を優先的にクリックして排除するプロセスを組み込んでおくことで、全体の安定性が大きく向上します。
タイムアウト時の再試行戦略（Exponential Backoff）
サイト自体が重くて開かないこともあります。この場合、単純にリクエストを連打するのではなく、Exponential Backoff（指数関数的バックオフ）を用いて待機時間を延ばしながらリトライさせます。
これはネットワークエンジニアリングの基本ですが、Web Agentsの実装にも必ず適用すべきです。「5秒待つ→ダメなら10秒待つ→ダメなら20秒待つ」という規律を持たせることで、対象サーバーへの負荷を抑えつつ、一時的な障害を乗り越えることができます。
導入に向けた技術選定とリスク評価
実際にプロジェクトとして推進する場合、どのような技術を選定し、コストをどう評価すべきでしょうか。
OSS（Browser Use等）vs 商用APIの比較
現在、Web Agentsを実装するためのライブラリとして「LangChain」や「Browser Use」といったOSSが広く利用されています。これらはPlaywrightやPuppeteerをLLMから制御するラッパーとして機能します。
- OSS (Browser Use, LangChain): カスタマイズ性が高く、自社環境で動かせるためデータ管理が容易です。ただし、プロンプトのチューニングやエラーハンドリングの実装は自力で行う必要があります。
- 商用サービス (MultiOnなど): 導入のハードルが低く精度も期待できますが、内部ロジックがブラックボックスになりがちで、スケール時のランニングコストが高騰するリスクがあります。
プロジェクトのROIを最大化する観点から、開発力のあるチームであれば、「Browser Use + ChatGPT (or Claudeの最新モデル)」の組み合わせで自社構築するのが、コストパフォーマンスと柔軟性のバランスが最も良いと考えられます。
実行コスト（トークン消費量）の試算と最適化
Web Agentsは、画面のHTMLやスクリーンショットを何度もLLMに送信するため、トークン消費量が大きくなる傾向があります。1回の予約フローで数百円のコストが発生することもあります。
コスト削減のテクニックとして非常に有効なのが「DOMの圧縮」です。
不要な<div>タグやスタイル属性、スクリプトタグを削除し、操作に必要な要素（ボタン、リンク、入力欄）だけを残した軽量なHTMLをLLMに渡します。また、スクリーンショットも認識に必要な最低限の解像度に落として送信します。
実務の現場では、これらの最適化により、精度を維持したままトークンコストを大幅に削減できた事例も多数存在します。
サイト利用規約と法的コンプライアンスの遵守
最後に、プロジェクトマネージャーとして必ず押さえておくべき法的な側面です。
Webスクレイピングや自動操作は、対象サイトの利用規約（Terms of Service）で明確に禁止されている場合があります。特に高頻度なアクセスはDoS攻撃とみなされる重大なリスクを伴います。
robots.txtの確認: クローラーのアクセス許可範囲を事前に確認します。- アクセス頻度の制限: 人間が操作する程度の速度（数秒の間隔）に意図的に落とし、サーバーに負荷をかけないよう配慮します。
- User-Agentの明示: ボットであることを隠さず、連絡先を含めた適切なUser-Agentを設定します。
技術的に可能だからといって、何でも実行していいわけではありません。特に他社のプラットフォームを利用してビジネスを展開する場合、法務部門との密な連携は必須です。場合によっては、正式なAPI利用契約を結ぶ方が、長期的には安全かつ確実な投資となることもあります。
まとめ
旅行予約の自動化は、従来のRPAからWeb Agentsの時代へと確実に移行しつつあります。
- DOMに依存せず、視覚（Vision）で状況を判断する
- 曖昧な指示を構造化し、実行可能なタスクに論理的に落とし込む
- エラーや在庫切れから自律的に復帰する自己修復ループを作る
この3点を押さえた実用的なエージェントを設計できれば、チームはメンテナンス作業から解放され、より付加価値の高い開発にリソースを集中できるようになります。
Web Agentsはまだ発展途上の技術であり、エコシステムも常に変化しています。しかし、その変化に柔軟に対応できる自律性こそが、この技術の最大の強みであり、ビジネスにブレイクスルーをもたらす鍵となるでしょう。
コメント