Hermes Agentを実務の意思決定パートナーに育てる検証ロードマップ

Hermes Agentを、ビジネス判断を支援するエージェントとして育てる検証を始めます。

今回の題材は、ホテル・民泊向けの動的価格設定です。狙いは、価格変更を完全自動化することではありません。予約状況、稼働率、競合価格、天候、イベントを見ながら、担当者が判断しやすい提案を出すエージェントを作ることです。

ホテル価格設定はあくまで最初のユースケースです。ここで見たいのは、Hermes Agentを実務の意思決定に近づけるときに、どのルールを固定し、どの判断基準を育て、どこから人間に戻すべきかです。

なぜホテル価格設定をテーマにするのか

Hermes Agentをビジネスで使うための成長記録にするには、判断が曖昧すぎず、かつ単純な正解にもならないテーマが必要です。

ホテルや民泊の価格設定は、この条件に合っています。

• 稼働率、曜日、季節、イベント、競合価格など、判断材料が複数ある
• 値上げ、維持、値下げという出力が比較しやすい
• 人間の経験と勘に依存しやすい
• 外したときの理由を振り返りやすい
• 価格、在庫、需要予測など、他の業務判断にも横展開しやすい

特に見たいのは、「初期状態のHermesが何を間違えるか」です。最初から賢いエージェントを演出するのではなく、何が足りないと判断が崩れるのかを記録します。

エージェントに任せる範囲

今回のPoCでHermesに任せるのは、価格変更の提案までです。

Hermesは、対象日と部屋タイプに対して次のような出力を作ります。

{
  "recommendation": "raise",
  "proposed_price": 15000,
  "rationale": [
    "花火大会開催で需要が強い",
    "競合の多くが満室",
    "予約ペースが通常より速い"
  ],
  "confidence_score": 0.82,
  "human_approval_required": true
}

一方で、価格変更の確定やOTAへの反映は人間が行います。ここを自動化すると、誤判断の影響が直接売上や顧客体験に出るためです。

このシリーズでは、エージェントを「自動実行する担当者」ではなく、「判断材料を整理して提案する補助者」として扱います。ホテル価格設定でこの距離感を試し、うまくいく部分と危ない部分を他のビジネス判断にも転用できる形で残します。

L1 / L2 / L3で分ける

Hermesの判断は、3つのレイヤーに分けて考えます。

L1: 絶対に破らない固定ルール

L1は、フィードバックで変えてはいけない原則です。

• 最低価格を下回らない
• 最低利益率を下回らない
• 根拠なしに提案しない
• 人間の承認を迂回しない
• 競合価格だけを理由に過度な値下げをしない

ここは「育つ」対象ではありません。運用で成果が出ても、L1を弱めてしまうと危ない提案が通ってしまいます。

L2: 育てる重み

L2は、フィードバックを見ながら調整する重みです。

• 稼働率をどれくらい重く見るか
• 予約ペースをどれくらい信じるか
• イベント需要をどれくらい価格へ反映するか
• 競合満室を値上げ要因としてどれくらい見るか
• 台風などの悪天候をどれくらい需要減として扱うか

Hermesが「育つ」と言えるのは、主にこのL2が改善していく部分です。

L3: 外れ続けたときの監視

L3は、個別提案の判断ではありません。

たとえば、同じ条件で5日連続して予測より客が入らない場合、単に価格を下げるだけではなく、近隣ホテルの新規開業やOTAの表示順位変更など、Hermesが見ていない構造変化を疑う必要があります。

このときL3は、提案とは別に次のような警告を出す想定です。

{
  "alert_type": "consecutive_prediction_miss",
  "message": "この文脈の価格提案が5日連続で実績と乖離しています。外部環境の構造変化を確認してください。"
}

今回の初期PoCでは、まずL1/L2で通常判断を評価します。L3は後続回で扱います。

最初に作る検証シナリオ

最初から全シナリオを作ると、評価ループよりデータ作りが重くなります。まずは通常判断を試すための3シナリオだけに絞ります。

ID	シナリオ	期待判断
A-01	花火大会前2週間・競合満室	値上げ
A-02	台風接近・直前キャンセル急増	値下げ
A-03	平日・閑散期・稼働率20%	値下げ

この3本で見たいのは、Hermesが「それっぽい文章」を出せるかではありません。

• 方向判断が合っているか
• 根拠がデータに紐づいているか
• 確信度が高すぎたり低すぎたりしないか
• L1を破る提案をしていないか

まずはここを採点し、初期状態の弱さを記録します。

今回作ったもの

検証用の実データや作業ファイルは、公開リポジトリではなく手元の非公開ワークスペースに置いています。

ホテル価格設定の検証では、宿泊施設の運用データに近い形の情報を扱う可能性があります。たとえ今回はダミーデータから始めるとしても、後から実データや固有の業務メモが混ざる余地があります。そのため、GitHubで公開する記事側には「どういう構造で検証しているか」だけを残し、具体的なデータや内部メモは公開しない方針にします。

主な中身は以下です。

• PoC README
• 最小設計メモ
• SQLite想定のschema.sql
• HermesのSOUL.md
• L1/L2のコンテキスト
• 最初に試す3シナリオのJSON
• 手動採点用メモ

この時点では、まだ自動評価スクリプトは作っていません。次にやるのは、3本のシナリオを初期Hermesに投げて、どの判断が外れるかを記録することです。

次に確認すること

次回は、上の3シナリオを実際にHermesへ渡します。ホテル価格設定の正解率だけを見るのではなく、ビジネス判断支援エージェントとして何が足りないのかを観察します。

そこで、以下を記録します。

• 期待通りに値上げ・値下げを判断できるか
• 根拠が入力JSONのデータに対応しているか
• 台風や閑散期の判断で危険な楽観が出ないか
• 花火大会シナリオで過度に強気な値上げをしないか

最初の評価では、失敗が出る方が素材としては重要です。どこで判断が崩れたかが見えれば、次にL1やL2をどう直すべきかが分かります。