宿泊プランの紹介文を掲載する前に、料金条件・キャンセル規定の書き漏れと表記ゆれ、誇大な表現を点検して直し案を出す

処理の起点を決める

掲載先ごとの紹介文を点検用のシートに貼り、「点検待ち」の印を付けたことを起点にします。 最小構成では人が ChatGPT に貼るので、実際の起点は予約販売担当の手作業です。それでも印を付けるのは、点検をせずに掲載したものを一覧で見つけるためです。

点検にかけるのは次の3つのときです。

2行目が、いちばん抜けやすいきっかけです。 条件を改めたのは支配人と予約課で、紹介文を書いた人は知りません。正本の行に「最終更新日」の列を持たせ、点検結果のシートの点検日より新しい行を式で目立たせます。 条件が変わったのに点検していないプランが、それで見えます。

1日1回まとめて点検する形にはしません。 紹介文を書き上げたその場で点検すれば、書いた本人の記憶が新しいうちに直せます。

入力データを集める

質を決めるのは、いちばん上の正本です。 正本の「キャンセル規定」の列が「規定どおり」としか書かれていなければ、AIは紹介文の取消料が正しいかを見比べられません。 何日前から何％、という形で列に書かれている必要があります。

確認が要る表現の一覧は、禁止語の一覧ではありません。 「日本一」「最高級」「今だけ」「通常価格より」のような、書くなら根拠が要る語の例です。一覧にある語が紹介文にあれば、AIは違反かどうかを決めずに「根拠の確認」として拾います。一覧に無い語でも、同じ種類の表現なら拾わせます。

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

正本の1行は、点検用のシートの式で取り出します。 点検用のシートでプランIDを入れると、管理表からその行を引き、列の名前と値を「料金の単位：1名」「入湯税：別途150円」のように1行ずつ並べた文章にします。

式でまとめた貼り付け用の文章は、たとえば次の形になります。

【正本】プランID：P-2610-03／プラン名：秋の味覚会席プラン
料金の単位：1名／税とサービス料：税込・サービス料込
入湯税：別途150円／含まれる食事：夕食（会席）・朝食（和定食）
特典：（正本に記載なし）／対象期間：2026-10-01〜2026-11-30
除外日：2026-11-02、2026-11-22／人数の条件：2名以上
キャンセル規定：7日前20％、前日30％、当日80％、不泊100％
最終更新日：2026-09-24
【掲載先】予約サイトA（欄：見出し／本文／注意事項）
【紹介文】……

式でまとめる理由は2つあります。 1つは、第5章の3番目のとおり、人が書き写すと漏れるからです。もう1つは、正本の列が空欄のときに、空欄であることを文章に残せるからです。空欄の列は「入湯税：（正本に記載なし）」と出るようにしておきます。何も出さないと、AIはその項目が存在しないものとして扱います。

紹介文は、掲載先の欄ごとに分けて貼ります。 予約サイトによっては、キャンセル規定を本文ではなく専用の欄に入れます。本文だけを貼ると、専用の欄に書いたキャンセル規定が「書き漏れ」と出ます。 欄の名前を付けて並べ、どの欄に何が書かれていればよいかを掲載先ごとの一覧で添えます。

AIへ渡す前に整形する

1. 正本の最終更新日の確認 … 点検用のシートに表示し、紹介文を書いた日より新しければ「正本が変わっています」と出します
2. 正本の空欄の表示 … 空欄の列は「（正本に記載なし）」と文章に残します
3. 紹介文の欄の整理 … 掲載先ごとに、見出し・本文・注意事項などの欄の名前を付けて貼ります
4. 貼り付けのときの崩れの除去 … 管理画面からコピーした紹介文に入る余分な改行や記号を、式で落とします
5. 字数の確認 … 掲載先ごとの字数の目安を超えていないかは、AIに数えさせず、シートの式で数えます
6. 1件ずつにする … 3か所の紹介文を1回にまとめて貼りません。掲載先ごとに1回ずつ点検します

6番目を軽く見ないでください。 3か所分を一度に渡すと、自社サイトの紹介文にある入湯税の記載を見て、予約サイトの紹介文にも書いてあるものとして扱うことがあります。 第3章の（a）の「1か所だけ漏れる」を拾うには、1か所ずつ見せるしかありません。

5番目も同じ理由です。 生成AIは文字数を正確に数えるのが得意ではありません。数えられるものは、式で数えます。

AIに処理させる

させるのは、紹介文と正本を項目ごとに見比べ、差を5つの区分に分けて拾い、直し案を付けることだけです。

右端の列の extra が、この構成でいちばん大事な扱いです。 紹介文に「ウェルカムドリンク付き」とあって正本に無いとき、紹介文が誤っているのか、正本に入れ忘れたのかは、AIには分かりません。 どちらかに決めて直すと、正しい記載を消すか、誤った記載を正本扱いにするかのどちらかになります。人に聞く、で止めます。

omission の価格表示は、税込かどうかを見ます。 国税庁のページでは、事業者が消費者にあらかじめ価格を表示する場合は消費税額を含めた価格の表示が求められ、「11,000円（税込）」「10,000円（税込価格11,000円）」のような表示が例として示されています。税抜の金額だけが書かれていれば、税込価格の書き漏れとして拾います。

2行目がいちばん起きやすい失敗です。 正本のキャンセル規定が空欄のまま紹介文にも無いと、AIは親切に「一般的な規定」を直し案に書きます。その直し案が採られた瞬間、施設が決めていない取消料が公開されます。 正本が空欄なら「正本に記載なし。条件を決めてください」と返させます。

指示内容を固定する

あなたは旅館の予約販売の担当です。宿泊プランの紹介文を掲載する前に、
プランの正本と見比べて点検してください。
正本に書かれていることだけを正しいものとして扱ってください。
一般的な旅館の慣習や、あなたの知識で補わないでください。

【点検の区分】
- omission …… 正本にあるのに紹介文に無い項目。税抜の金額だけで税込価格が無い価格表示も含む
- mismatch …… 紹介文と正本で値が違う項目
- extra ……… 紹介文にあるのに正本に無い条件・特典
- variant …… 表記ルールと違う書き方
- expression … 根拠の確認が要る表現（最上級・比較・価格の強調・期間の限定など）

【厳守事項】
- 正本が「（正本に記載なし）」の項目は、直し案を作らず
  「正本に記載なし。条件を決めてください」と書いてください。
- 料金の計算をしないでください。税込の計算、1名料金と1室料金の換算をしないでください。
- extra の行は直し案を作らず、「正本に足すか、紹介文から消すかを確認してください」と書いてください。
- expression の行は、違反かどうかを書かないでください。
  根拠として確かめるべきこと（何と比べて、いつ時点で、何の資料で）を書き、
  根拠が無い場合の言い換えの案を1つだけ書いてください。
- 確認が要る表現の一覧に無い語でも、同じ種類の表現なら拾ってください。
- 紹介文の該当箇所は、紹介文の文面をそのまま写してください。
- 掲載先の欄の一覧を見て、専用の欄に書かれている項目は書き漏れにしないでください。
- 言い回しの好みで直さないでください。条件・表記・表現の点検に絞ってください。
- 文字数を数えないでください。
- 指摘が無い区分は書かないでください。「問題なし」の行を作らないでください。

【出力】次の列の表だけを返してください。表の外に説明を書かないでください。
No｜区分｜紹介文の該当箇所｜正本の記載｜直し案｜確認の理由

【正本】{master_row}
【掲載先と欄の一覧】{channel_fields}
【紹介文】{listing_text}
【表記ルール】{style_rules}
【確認が要る表現の一覧】{expression_list}

「一般的な慣習で補わない」を明記しないと、AIは旅館の常識で判断します。 「チェックインは15時」と紹介文にあって正本に無いとき、それが普通だからと extra にしません。正本に無ければ正本に無い、と拾わせます。

「問題なし」の行を作らせないのは、表の行数を指摘の数にそろえるためです。 問題なしの行が混ざると、点検結果のシートに貼ったときに指摘の件数を数えられません。

出力形式を固定する

最小構成では、決めた列の表で受け取ります。 表は点検結果のシートにそのまま貼れ、列が同じなので採否の列を横に足すだけで記録になります。

半自動化の段階では、同じ列を JSON で返させます。 OpenAI API の Structured Outputs は、指定した JSON スキーマに沿った応答を返す機能で、必須の項目が抜けることや、決めた値以外の区分が返ることを防げます。 使うには、すべての項目を required に並べ、additionalProperties を false にします。

{
  "plan_id": "",
  "channel": "",
  "findings": [
    { "no": 1,
      "category": "omission | mismatch | extra | variant | expression",
      "listing_excerpt": "",
      "master_value": "",
      "suggestion": "",
      "reason": "" }
  ]
}

1つ目の理由は、category を5つの値に固定できることです。 区分ごとに件数を数え、どの掲載先でどの区分が多いかを月ごとに比べられます。

2つ目は、応答を拒否されたときに分かることです。 Structured Outputs では、安全上の理由でモデルが応答を拒否すると、スキーマに沿った応答の代わりに refusal の項目が返ります。 点検用のシートでこの項目を見て、「点検できませんでした」と表示します。

システムへ連携する

掲載先へは書き込みません。 この構成が出すのは点検の結果と直し案までで、掲載先の管理画面への入力は今までどおり人が行います。 自動で書き込むと、誤った直し案がそのまま公開されます。

正本の管理表にも書き込みません。 extra で「正本に足す」と決めた場合も、正本を直すのは条件を決めた支配人と予約課です。

人が確認する

予約販売担当が、指摘の表を1行ずつ見て採否を決めます。

1. mismatch と omission を先に見る … 正本の値と直し案を見比べ、そのまま採れるかを決めます
2. extra を正本の担当に聞く … 正本に足すか、紹介文から消すかを支配人か予約課に確かめます
3. expression の根拠を確かめる … 根拠の資料があれば残し、無ければ言い換えの案を採ります
4. 指摘の無かった項目を流し見る … 正本の列を上から見て、AIが拾わなかった漏れがないかを確かめます
5. 採否を記録する … 点検結果のシートに、採った・採らなかった・保留を残します

3番目を省かないでください。 消費者庁のページでは、実際より著しく有利であると誤認される表示は、故意に偽った場合だけでなく、誤って表示してしまった場合でも規制の対象になるとされています。また、品質などを著しく優良と示す表示について、合理的な根拠を示す資料の提出を求められ、出せなければ不当な表示とみなされる仕組みがあります。「県内随一」と書くなら、その資料が手元にある必要があります。

4番目も省きません。 AIが拾わなかったことは、漏れが無いことの証明ではありません。正本の列を上から見るだけなら1分で済みます。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、正本の側の問題です。 正本がそろっていない施設では、この構成は最初に正本の穴を見つける道具になります。

記録を残す

• 点検した日、プランID、掲載先、点検に使った正本の最終更新日
• 貼り付け用の文章（正本の1行と紹介文）と、使った指示文の版
• 返ってきた指摘の表
• 指摘ごとの採否（採った・採らなかった・保留）と、決めた人
• expression で残した表現と、根拠にした資料の置き場所
• 掲載した日と、掲載した紹介文

4つ目を残すのは、指示文を直す材料にするためです。 同じ種類の指摘を毎回「採らない」としているなら、指示文か表記ルールの側を直します。

5つ目は、あとから説明を求められたときの備えです。 「県内随一」と書いた根拠を尋ねられたときに、どの資料を根拠に残したかをすぐ出せます。