宿泊税の月ごとの申告のために、予約と精算のデータから1人1泊の宿泊料金と税額を集計し、課税免除や料金の扱いの確認が要る宿泊を判定して経理に回す

処理の起点を決める

集計は、毎月3日の7時台に動く時間主導型のトリガーを起点にします。 公式のページでは、時間主導型のトリガーの時刻は少しずれることがあり、9時に設定すると9時から10時のあいだで選ばれ、その時刻が保たれるとされています。経理課の始業までに一覧ができていれば足ります。

3日にするのは、月末のチェックアウトの精算がそろうのを待つためです。 月末日に泊まった客の精算は翌月1日に入ります。経理課は2日にCSVを置き、置き終えたらフォルダに「置いた」の印のファイルを作ります。 スクリプトは最初にこの印を見て、無ければ集計をせずに経理課へ知らせます。

対象は「宿泊日」で決めます。 手引では、月をまたぐ連泊は宿泊行為のあった月ごとに分けて申告するとされています。CSVはチェックアウトの日で書き出されることが多いので、前の月と前々月のチェックアウトの分をあわせて読み、宿泊日が前の月の行だけを集計します。 前の月の末日に泊まって翌月にチェックアウトした客は、翌月のCSVに入るので、3日の集計とは別に、翌月の10日にその分だけを追加で拾う手動の実行を用意します。

再集計はメニューから行います。 フロントが確認の結果を書き込んだら、経理課が「前月を再集計」を実行します。再集計ではAIを呼ばず、規則の計算だけをやり直します。

入力データを集める

質を決めるのは、プランの表と経路の表です。 食事代に相当する額がプランごとに決まっていれば、食事込みのプランも規則で計算できます。予約サイトのポイントを「経営者自らのサービス以外」とする扱いも、経路の表に書いておけば、規則がそのまま割引前の料金を使います。 AIの出番は、表で決まらない予約だけに絞られます。

税率の表に適用開始日を持たせるのは、改定をまたぐためです。 手引では、宿泊税は宿泊日ごとに算定し、改定日の前から泊まり始めた客でも、改定日以後の宿泊分には新しい税率を当てるとされています。

宿泊者の名前は使いません。 必要なのは人数と金額とプラン名、備考だけです。CSVを書き出すときに、氏名・電話番号・メールアドレスの列を外す設定にします。

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

処理は、次の順で行います。

1. 精算データを宿泊日ごとの行に分ける（宿泊日、人数、その日の室料）
2. プランの表で食事代を除き、サービス料を足して、その日の宿泊料金を出す
3. 経路の表で、値引を「割引後で計算」か「割引前で計算」かに振り分ける
4. 宿泊料金をその日の人数で割り、1人1泊の金額を出す
5. 税率の表で区分を引き、税額 ＝ 区分の額 × 人数 を出す
6. 規則で検出する
   R1 食事込みのプランなのに、プランの表に食事代の額が無い
   R2 値引の行があり、経路の表で扱いが決まらない
   R3 予約経路が団体、または備考に「修学旅行」「学校」「園」の語がある
   R4 1人1泊の金額が区分の境目の±3％以内
   R5 宿泊料金が0円、または泊数が0（デイユース・無料招待・不泊の疑い）
   R6 エキストラベッド・ベビーベッドの行がある
7. R1〜R6 の予約のプラン名・備考・支払の内訳を Claude API に渡す
8. 施設ごとに、宿泊数と税額を区分別に集計し、確認の一覧とあわせて書く

5番目の計算は、手引の計算例と同じ形です。 たとえば1室1泊50,000円のツインに2人で泊まれば、50,000÷2＝25,000円で、1人1,000円の区分に入り、宿泊税は2,000円です。

R6 を拾うのは、手引の計算例で扱いが分かれるからです。 エキストラベッドの追加料金は特定の宿泊者に帰属しないので総額に足し、ベビーベッド代は乳児に帰属するので乳児を別に扱うとされています。どちらの行かは、精算データの品目名だけでは決まらないことがあります。

AIへ渡す前に整形する

1. 文字コードを確かめる … 備考の列に「�」が混ざっていれば、文字コードを取り違えています。集計をせずに経理課に知らせます
2. 個人を表す列を落とす … 氏名・電話・メールの列が残っていれば、読み込みの段で捨てます
3. 予約番号を記号に置き換えない … フロントが調べるのに要るので残します。AIに渡すのも予約番号までです
4. 数字は規則で計算したものを渡す … その日の宿泊料金、1人1泊の金額、仮の税額はスクリプトで出した値を渡し、AIに計算させません
5. 備考に番号を振る … 「B-0412」のように備考の文ごとに番号を付け、AIには根拠をこの番号で返させます

4番目は、第5章で書いたとおり、税額を式に置くためです。 AIに渡すと、「食事代はおよそ5,000円と考えられるので」と推定の金額で計算し直します。 推定で引いた食事代で申告すれば、根拠の無い申告になります。

AIに処理させる

させるのは、規則が拾った予約について、「規則どおりに計算してよいか、人が確かめる点があるか」を判定し、確かめる点の種類と根拠の文字列を返すことです。

区分は、経理課が決めた語彙から選ばせます。 上の5つに、寝具の追加（bedding_check）、大使館などの免除の可能性（diplomat_check）、確認の要らないもの（no_issue）を足した8つです。区分ごとにフロントへの問い合わせの文面を決めておけば、確認の一覧からそのまま聞けます。

3行目が、この構成でいちばん守るべきことです。 備考に「修学旅行」とあれば、AIは課税免除と書きたくなります。しかし免除の要件は、証明書を受け取っていることです。 AIには school_trip_check とだけ返させ、証明書の受領簿と突き合わせるのは規則、受け取っていなければフロントが学校に依頼します。

指示内容を固定する

あなたは京都市内の宿泊施設の経理担当として、宿泊税の申告の前に、
予約ごとの宿泊料金の扱いに確認が要る点があるかを判定する立場です。
税額は計算しません。課税免除に当たるかの結論も出しません。

【入力】
- 予約番号、施設、宿泊日、その日の人数、プラン名、予約経路
- その日の宿泊料金・1人1泊の金額・仮の税額（計算済み）
- 精算の明細（品目名と金額）、支払の内訳
- 予約の備考（note_id 付き）
- 規則で立った印（R1〜R6）

【してほしいこと】
1. 規則どおりに計算してよいか、人が確かめる点があるかを判定する
2. 確かめる点があれば、次の区分から1つ以上を選ぶ
   meal_amount_unknown / third_party_discount / school_trip_check /
   not_stay_check / extension_check / bedding_check /
   diplomat_check / no_issue
3. 各区分に、根拠にした note_id か明細の品目名を必ず付ける
4. school_trip_check のときは、備考に書かれた生徒・引率者・
   添乗員などの人数を、書かれているとおりに写す

【厳守事項】
- 食事代の額を推定しないでください。額が明細に無ければ
  meal_amount_unknown とだけ返してください。
- 金額を計算し直したり、丸めたりしないでください。
- 「課税免除に当たる」「課税対象外である」と書かないでください。
- 旅行業者の添乗員やカメラマンを引率者に含めないでください。
  備考で役割が分からない大人は role_unknown として人数だけ写してください。
- 根拠の note_id か品目名を付けられない区分は返さないでください。
- 宿泊者の個人についての記述を書かないでください。

【予約】{booking_json}
【経路の表】{channel_table}

「食事代の額を推定しない」を最初に置いているのは、第7章の前処理の4番目で書いた事故を止めるためです。 禁じないと、AIは親切に「一般的な夕食の相場から」と額を置きます。返し方として meal_amount_unknown を用意しておけば、推定する理由が無くなります。

role_unknown を用意しているのも同じ考えです。 備考に「大人8」とだけあると、AIは引率者と添乗員を推し量って分けます。分からないものは分からないと返せる欄があれば、推し量りは止まります。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "booking_no": "",
  "stay_date": "",
  "checks": [
    { "category": "meal_amount_unknown | third_party_discount | school_trip_check | not_stay_check | extension_check | bedding_check | diplomat_check | no_issue",
      "evidence": [""],
      "summary": "" }
  ],
  "group_counts": {
    "students": null, "chaperones": null, "tour_staff": null, "role_unknown": null
  }
}

スキーマでは category を enum で縛り、オブジェクトに additionalProperties: false を付けます。evidence に入った note_id や品目名が、渡した予約に本当にあるかは、受け取ったあとにスクリプトで確かめます。 無いものは落とし、経理課に知らせます。

理由の1つ目は、税額とAIの判定を別の層に置けることです。 税額は規則が宿泊日ごとの行に書き、AIの JSON には金額を返させません。申告書の数字は、規則の列と、人が確定した列からだけ作ります。

2つ目は、group_counts を証明書の受領簿と突き合わせられることです。 備考の生徒と引率者の数を、受領簿の人数と比べ、合わなければ確認の一覧に「人数の差」と出します。 証明書が無ければ、免除の数は0のまま集計します。

確認の一覧は、フロントが読めば何を確かめればよいか分かる形にします。

【10月分 宿泊税の確認（ホテル：確認12件・うち修学旅行3件）】
■ R-24-1187  10/14  2名  プラン「秋の京都 旅行会社企画」
  確認：食事代の額が明細にありません（meal_amount_unknown）
  仮の計算：1人1泊 19,500円 → 400円×2名（境目に近い）
■ R-24-1203  10/21〜22  生徒80・引率6・添乗1  〇〇中学校
  確認：修学旅行の証明書が受領簿にありません（school_trip_check）
  仮の計算：免除0名として集計中
※ 確認の結果を一覧の「確認結果」に書き込んでください。月の20日までにお願いします。

システムへ連携する

API キーはスクリプトのプロパティに置き、スクリプトの編集の権限は経理課の数名に絞ります。 公式の割り当てでは、1回の実行は6分まで、URL Fetch の呼び出しは Google Workspace のアカウントで1日10万回です。AIを呼ぶのは R1〜R6 の予約だけで、月600件のうち1〜2割、100件前後です。6分を超えそうなときは、終わった予約番号を記録して、続きのトリガーで残りを処理します。

予約管理システムと会計システムには書き込みません。 納入申告書は、経理課が集計のシートの数字を写して作ります。申告の数字を人が写す1手間を残すのは、確定していない予約が混ざったまま申告しないためです。

人が確認する

1. フロントが確認の一覧を見る … 食事代の内訳を旅行会社に聞く、証明書を学校に依頼する、デイユースか宿泊かを契約で確かめる
2. 確認結果を書き込む … 食事代の額、証明書の受領日と人数、課税対象かどうかを、一覧の決まった列に書きます
3. 経理課が再集計する … 規則が確認結果を使って計算し直し、仮の税額と確定の税額の差を出します
4. 経理課が申告書を作る … 確認の一覧に未記入が残っていないことを確かめてから、施設ごとの合計を納入申告書に写します

4番目の「未記入が残っていない」は、スクリプトが数えます。 未記入があるうちは、集計のシートの合計欄に「未確定あり」と出します。

目標は、600件をならして1件1分です。 規則だけで済む予約は合計の確認で流れ、確認の一覧の予約はフロントとのやり取りで数分かかります。確認の一覧が多い月は、プランの表に食事代の額が足りていない合図です。

例外に対処する

5行目を省かないでください。 月末日の宿泊を落とすと、その月の申告が少なく、翌月が多くなります。 施設の合計は年で見れば合いますが、月ごとの申告としては誤りです。

記録を残す

• 宿泊日ごとの計算の行（宿泊料金、1人1泊の金額、区分、税額、適用した税率の表の版）
• 仮の税額と確定の税額、その差と確認結果
• AIに渡した予約番号と、返った JSON の全文
• 証明書の受領簿との突き合わせの結果
• 施設ごとの月の集計と、納入申告書に写した数字

手引では、徴収原簿を7年間保存する必要があるとされ、必要事項が記載されていれば任意の様式でよいとされています。宿泊日ごとの計算の行に手引の記載事項がそろうように列を設計しておけば、集計のシートをそのまま徴収原簿として残せます。 どの列を記載事項に当てるかは、手引の様式と見比べて経理課が決めます。