旅館・ホテルが修学旅行の受入れの依頼を受けたときに、過去の受入れの記録と反省記録から規模と行程の近いものを探し、食事・部屋割り・夜間の注意点を根拠付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは毎晩です。 打合せメモは打合せの後、反省記録は受入れの翌週までに担当が書きます。次の依頼の準備に載れば足ります。 予約の台帳で「受入れ済み」になった団体のうち、反省記録のファイルが無いものは、担当に書くよう知らせます。

場面と注意点の確かめは週に1回です。 毎晩の取り込みでAIが付けた場面のうち、新しい注意点の言い回しと、自信が低いと書かれたものを一覧にし、受入れの準備の担当がまとめて直します。

検索は、担当が予約の台帳の画面で「過去の受入れを見る」を押したときに動きます。 押す時機は2回です。依頼を受けたとき（人数と日程が仮の段階）と、詳細の打合せの前（人数・行程・食事の条件が確定した段階）です。確定した後の検索のほうが、近い受入れが正確に並びます。

入力データを集める

質を決めるのは、反省記録です。 打合せメモは「何を決めたか」で、反省記録は「決めたとおりにいかなかったこと」です。次の受入れに効くのは後者です。 反省記録の無い受入れは、検索の点数を下げて並べます。

生徒の人数は、必ず数値で持たせます。 打合せメモの「2年生約240名」から数値を取り出し、取り出せないものは取り込みで止めます。 理由は前処理の項で書きます。

データの取得方法を決める

予約の台帳の団体の記録と、学校のフォルダの打合せメモ・反省記録を、Lambda が読みます。生徒の名前は、名簿の形で書かれていれば機械的に外し、文中に出てくる名前は Claude に挙げさせて置き換えます。

索引の項目は、次のように持たせます。

検索は、次のように組みます。

GET /school_stays/_search
{
  "size": 6,
  "query": { "function_score": {
    "query": { "bool": {
      "filter": [ { "term": { "school_type": "中学" } },
                  { "exists": { "field": "students" } } ],
      "should": [ { "terms": { "features": ["体験学習あり", "夕食後の行事"] } },
                  { "range": { "arrival_hour": { "gte": 17 } } },
                  { "term": { "has_review": true } } ]
    } },
    "functions": [
      { "gauss": { "students": { "origin": 240, "offset": 20, "scale": 60, "decay": 0.5 } } },
      { "gauss": { "stay_date": { "origin": "now", "offset": "365d", "scale": "1095d", "decay": 0.5 } } }
    ],
    "score_mode": "multiply", "boost_mode": "multiply"
  } },
  "highlight": { "fields": { "review_text": { "fragment_size": 80, "number_of_fragments": 2 } } }
}

人数の減衰は、240名から前後20名までを満点とし、さらに60名離れた180名と300名で点数が半分になります。 実施日は1年以内を満点とし、さらに3年離れると半分です。10年前の記録も消えずに並びますが、同じ規模の新しい記録より下になります。

offset と scale の値は、部屋割りの単位で決めます。 このホテルでは1フロアにおよそ40名が入るので、前後20名は同じフロアの数で収まり、60名の差はフロアが1つ増えるか減る差です。フロアの数が変われば、部屋割りと夜間の見回りの前提が変わります。 客室の数や配置が違うホテルでは、この幅を自分の館に合わせて決め直します。

2つの関数の点数は掛け合わせます（score_mode の既定は multiply）。 人数が近くても古い記録、新しくても人数の違う記録は、どちらも下がります。検索の点数とも掛け合わせる（boost_mode の既定も multiply）ので、行程の特徴が重ならない記録も下がります。

AIへ渡す前に整形する

1. 人数を数値にする … 打合せメモと台帳から生徒の人数を数値で取り出します。取り出せない記録は取り込みで止めます
2. 場面ごとに分ける … 打合せメモと反省記録を、場面の一覧の区分ごとの注意点にします
3. 生徒の名前と健康の記載を置き換える … 名前は外し、アレルギーや持病は「食材と人数」「区分と人数」にします
4. 到着の時刻を取り出す … 打合せメモと台帳から時刻を取り出し、遅れた実績があれば反省記録から拾います
5. 行程の特徴を付ける … 体験学習、班別行動、夕食後の行事、連泊を、選択肢から付けます

1番目で止めるのは、減衰の関数の仕様のためです。 公式のドキュメントでは、項目の無い文書には、減衰の関数は点数1を返すとされています。人数の無い記録が、満点として上位に並びます。検索の側でも exists で人数のある記録に絞り、二重に防ぎます。

3番目は、取り込みの最初の段階で行います。 アレルギーの記載は、検索に要るのは「卵3名」という数と区分です。どの生徒かは、受入れの準備には要りません。 実施の直前に学校から届く個別の情報は、この仕組みに入れず、調理の責任者が直接扱います。

AIに処理させる

AIの仕事は2か所です。 取り込みで記録を場面ごとの注意点に分けることと、検索の結果から確認事項の一覧を書くことです。探すことと並べることは検索基盤が行います。

最初の行が、いちばん外せない線です。 一覧に「卵の除去食で対応可能」と書かれると、担当はそのまま学校に伝えたくなります。対応できるかは、今回の献立と厨房の体制で、調理の責任者が決めます。

最後の行も大事です。 反省記録には「先生方の協力が得られなかった」のような書き方が残っていることがあります。確認事項の一覧に学校への評価が載り、それが旅行会社に送られると、取引の関係に響きます。

指示内容を固定する

あなたはホテルの営業部で、修学旅行の受入れの打合せに向けて、確認事項の一覧を作る係です。
渡された検索結果だけを根拠にしてください。一般的な団体の受入れの知識で補わないでください。

【今回の受入れ】学校の種別：{school_type}　生徒：{students}名　教員：{teachers}名
  到着：{arrival}　行程の特徴：{features}　食事の条件：{meal_terms}
【検索結果】過去の受入れごとに、受入れ番号、実施日、人数、到着の時刻、
  場面ごとの注意点（打合せメモ由来／反省記録由来）

【確認事項の一覧に書くこと】
1. 場面（食事・部屋割り・夜間・体調不良・到着と出発）ごとに、確かめる事項を1行ずつ
2. 各行に根拠の受入れ番号と実施日
3. 反省記録に由来する行には from_review を true にする
4. 同じ注意点が複数の受入れにあれば、まとめて1行にし、受入れ番号を並べる

【厳守事項】
- アレルギーに対応できるか、どう対応するかを書かないでください。
  「アレルギーの食材と人数を、いつまでに学校から受け取るか」のような確認の事項にとどめてください。
- 部屋割りの案を作らないでください。
- 体調不良のときの医療的な対応を指示しないでください。
- 検索結果に無い注意点を足さないでください。根拠の受入れ番号の無い行は書かないでください。
- 学校や教員を評価する言葉を書かないでください。
- 生徒の名前を書かないでください。

「確認の事項にとどめる」を例付きで書くのは、AIが対応の方法まで書きたがるためです。 「卵の除去食を用意する」は対応の方法で、「卵のアレルギーの生徒の人数と、加工品も不可かを、実施の何日前までに受け取るか」は確認の事項です。後者だけを書かせます。

検索結果は、Claude の検索結果ブロックで渡します。 受入れ1件を1つの search_result にし、source に受入れ番号を入れます。引用を有効にすると、答えの文に、どの受入れのどの部分を引いたかが付きます。引用は既定で無効で、1つのリクエストの検索結果はすべて同じ設定にします。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。 output_config.format に json_schema を指定し、スキーマは additionalProperties: false で閉じます。

{
  "stay_id": "S-2027-0514-02",
  "checklist": [
    { "scene": "食事",
      "item": "到着が予定より遅れた場合に、夕食の開始を何分までずらせるかを学校と決めておく",
      "from_review": true,
      "evidence": [ { "stay_id": "S-2025-0521-01", "stay_date": "2025-05-21" },
                    { "stay_id": "S-2024-1016-03", "stay_date": "2024-10-16" } ] },
    { "scene": "夜間",
      "item": "体調不良の生徒に教員が付き添う間、生徒の階の見回りを誰が行うかを決めておく",
      "from_review": true, "evidence": [ { "stay_id": "S-2023-0607-02", "stay_date": "2023-06-07" } ] }
  ],
  "references": [ { "stay_id": "S-2025-0521-01", "students": 236, "arrival_hour": 18 } ]
}

1つ目の理由は、scene で打合せの順番どおりに並べられることです。 担当は一覧をそのまま打合せの議題にできます。

2つ目は、from_review で反省に由来する行を目立たせられることです。 打合せメモから来た行は「前にも決めたこと」、反省記録から来た行は「前にうまくいかなかったこと」です。担当が先に読むべきは後者です。

3つ目は、references で参考にした受入れの規模を示せることです。 人数と到着の時刻が並んでいれば、担当はどの記録がどれだけ今回に近いかを一目で見られます。

システムへ連携する

人が確認する

この構成の確認は、必須です。 確認事項の一覧は、学校と旅行会社に送る打合せの材料になります。

1. 場面と注意点を週に1回確かめる … 受入れの準備の担当が、新しい言い回しと自信の低いものを直します
2. 一覧を反省記録で確かめる … evidence の受入れ番号から反省記録を開き、要点が合っているかを見ます
3. 食事の行を調理の責任者に回す … 食事とアレルギーに関わる行は、調理の責任者に見てもらってから学校に送ります
4. 学校と旅行会社に送る形にする … 他の学校が特定される書き方を外し、確認の事項の形に書き直します

1件あたり16分を目安にします。 同じ学校の記録があれば短く、初めての学校や連泊の受入れは長くなります。

3番目を省かないでください。 食事の行は、確認の事項の形で書かれていても、何をいつまでに受け取れば厨房が間に合うかは、調理の責任者にしか分かりません。 「実施の2週間前まで」と書いた行が、厨房の仕入れの都合では3週間前でないと間に合わないことがあります。学校に送る前に、期限の数字を調理の責任者に直してもらいます。

例外に対処する

最後の行は、検索の点数とは別に出します。 同じ学校の前回の受入れは、規模が違っても、教員の方針や生徒の様子の手がかりとして最も役に立ちます。点数の順だけで並べると、人数が大きく変わった年に埋もれます。

6行目は、忘れやすい例外です。 階や非常階段の位置が変わると、部屋割りの反省は前提ごと使えなくなります。 改装の日を一覧に持たせ、それより前の記録の部屋割りの行に印を付けます。

記録を残す

• 取り込みの件数、止めた記録とその理由、置き換えの結果
• AIが付けた場面と注意点、担当が直したもの
• 依頼ごとの検索の条件、返ってきた受入れ番号、確認事項の一覧の版
• 一覧を確かめた担当、調理の責任者が見た日時
• 受入れの後の反省記録に、一覧に載っていた注意点がまた書かれていないか

最後の行が、この構成の効き目を測る材料です。 一覧に載っていたのに同じことが起きたなら、確かめ方の問題です。載っていなかったことは、次の取り込みで新しい注意点として入ります。