観光業の AI 活用入門：何を AI に任せ、何を人に残すか
補足
対象読者：自治体、DMO、宿泊事業者、観光施設、地域商社、観光 DX 担当者、観光システム開発者 想定読了時間：8〜10 分 前提知識：PMS、OTA、CRM、FAQ、需要予測、個人情報保護法の基礎 最終更新：2026-05-23
TL;DR
AI が効く 4 領域は、自動応答／需要予測／多言語／画像・動画解析。観光業では「問い合わせ量が多い」「判断基準が明確」「多言語化が必要」「画像・音声データが多い」業務から効果が出やすい。
LLM は文章生成・要約・翻訳に強い一方、ハルシネーション、誤情報、個人情報漏えいのリスクがある。宿泊者情報、健康・宗教・国籍・食事制限などを扱う場合は、入力データ、同意、保存先、学習利用設定を確認する。
導入は ROI が見えやすい順に、自動応答 → 多言語 → 需要予測 → 画像・動画解析が基本。需要予測は、6 ヶ月以上のデータで簡易監視、2〜3 年分のデータで季節性を含む予測検証に進むと扱いやすい。
AI エージェントは有望だが、予約変更・返金・価格変更などの実行系タスクは人の承認を残す。PoC では、AI に渡してよいデータ、渡してはいけないデータ、ベンダーに確認すべき項目を先に決める。
1. AI が効く 4 領域
自動応答（チャットボット・FAQ・OTA メッセージ）
需要予測（価格・在庫・人員配置）
多言語（メッセージ翻訳・音声ガイド・観光案内）
画像・動画解析（在庫品質チェック・防犯・客室メンテナンス・混雑把握）
観光業の AI 活用は、単に「人件費を減らす」話ではありません。地域観光では、季節変動、天候、イベント、交通、インバウンド比率、宿泊単価、地域内回遊など、複数の変数が同時に動きます。AI はこの複雑さを処理する補助線になります。
一方で、観光は体験産業です。最終的な安心感、謝罪、例外対応、地域らしさの表現は、人の判断と責任が残る領域です。
2. 各領域の現在の到達点
自動応答
自動応答は、最も ROI が見えやすい領域です。宿泊施設や観光施設では、以下のような定型問い合わせが多く発生します。
チェックイン・チェックアウト時刻
荷物預かり
駐車場
キャンセルポリシー
食事時間
アクセス
ペット同伴可否
子ども料金
周辺観光案内
OTA メッセージへの返信
FAQ が整備されていれば、定型問い合わせの一次回答や回答案生成は AI に任せやすくなります。ただし「80% 自動化」を目指す場合でも、残り 20% のエスカレーション設計が重要です。料金トラブル、クレーム、返金、オーバーブッキング、体調不良、災害時対応は人に渡すべきです。
最初の 30〜60 日は、AI が直接送信するのではなく、回答案を人が確認する運用から始めると安全です。FAQ の最終更新日、季節営業、交通運休、キャンセル規定の例外が反映されていないと、もっともらしい誤回答が発生します。
費用は、問い合わせ件数、入力文量、回答文量、ログ保存、ベクトル検索、翻訳、有人レビュー、既存 PMS / CRM 連携、サポート条件で大きく変動します。公開価格や月額だけで判断せず、初期構築、運用監視、FAQ 更新、エスカレーション対応を含めた総額で比較します。
まずやることは、直近 30 日の問い合わせを分類し、AI が回答してよい定型質問と、人へ渡す質問を分けることです。
需要予測
需要予測は、売上・人員配置・仕入れに直結します。宿泊業では、ADR、RevPAR、稼働率、予約リードタイム、キャンセル率、曜日、祝日、イベント、航空・鉄道動向、天候などを使います。
実務上は、6 ヶ月以上の自社データがあれば、予約ペース監視、繁忙日候補の抽出、異常検知などの簡易用途から始められます。季節性、曜日性、イベント影響、前年同月比較まで含めて予測精度を検証するには、2〜3 年程度のデータがあると扱いやすくなります。
中小施設ではデータ量が不足することがあります。その場合は、いきなり自動価格変更を行うのではなく、まずは以下のような補助用途から始めます。
来月の繁忙日候補を出す
清掃・フロント人員の過不足を予測する
仕入れ量の目安を出す
予約ペースの異常を検知する
価格変更の候補日だけを提示する
需要予測では、外部統計の扱いにも注意が必要です。観光庁の宿泊旅行統計調査は、2026 年 1 月調査分から施設タイプの層化基準が「従業者数」から「客室数」に変更されています。2025 年以前の数値と 2026 年以降の数値を比較する場合は、定義変更の影響を確認し、単純な前年同月比較だけで判断しないようにします。
需要予測 SaaS の費用は、施設数、連携する PMS・サイトコントローラー・BI、競合データの取得範囲、レポート粒度、価格変更の自動化範囲で大きく変わります。月額だけでなく、データ連携費、初期設定、運用支援、契約終了時のデータ返却条件を確認してください。
注意
需要予測 AI は「価格を上げる理由」を説明できることが重要です。自治体・DMO が地域事業者に導入する場合、ブラックボックスのスコアだけでは現場に定着しません。地域単位で AI を運用する場合、需要予測、在庫、予約、イベント、交通、地域回遊データを分断せず扱う設計が重要です。OYKOT が提唱する Destination OS（DOS）も、この考え方に基づく地域観光 OS 構想です。
多言語
多言語対応は、インバウンド比率が高い地域ほど優先度が上がります。LLM による翻訳は、OTA メッセージ、館内案内、観光 FAQ、音声ガイド原稿、SNS 投稿案などに使えます。
ただし、用途によって品質要件は異なります。日常的な問い合わせや下書きには使いやすい一方で、以下は機械翻訳だけで公開しない方が安全です。
災害・避難案内
医療・体調不良に関する案内
宗教・食事制限に関する案内
料金・キャンセル条件
法令・規約・免責事項
地域文化や歴史の説明
多言語対応では、ネイティブレビュー、用語集、禁止表現、地域固有名詞、災害時テンプレートを管理します。特に地名、祭礼、信仰、郷土料理、歴史人物は、直訳では意味が伝わらないことがあります。
多言語対応ツールや翻訳 API の費用は、対象言語、文字量、音声・動画、リアルタイム性、有人レビュー、用語集管理、災害時テンプレート運用の有無で変わります。料金・キャンセル条件・医療・災害案内は、機械翻訳だけで公開しない前提で見積もります。
まずやることは、翻訳対象を「即時返信してよい文」「人が確認する文」「機械翻訳禁止の文」に分けることです。
画像・動画解析
画像・動画解析は、客観基準がある業務で実用化が進んでいます。
客室清掃後のチェック
備品・アメニティの不足検知
駐車場・ロビー・観光施設の混雑把握
破損・汚損の記録
防犯カメラの異常検知
料理・客室写真の品質チェック
SNS 投稿用画像の分類
マルチモーダル AI は、テキスト、音声、画像、動画を組み合わせた処理に使われ始めています。観光業では、音声案内、動画からの混雑推定、客室写真の自動タグ付け、観光案内動画の字幕生成などが候補になります。ただし、モデル性能、利用規約、入力データの保存・学習利用、人物情報の扱いはサービスごとに確認が必要です。
一方で、顔、車両ナンバー、宿泊者の行動履歴が映る場合は、個人情報・プライバシーの問題が発生します。防犯目的、混雑分析目的、マーケティング目的では、利用目的、掲示、保存期間、第三者提供の有無を分けて設計する必要があります。
生成画像、写真、レビュー文、UGC を SNS や広告に使う場合は、著作権、肖像権、施設・人物の利用許諾も確認します。AI が生成した画像であっても、実在施設や人物に誤認される表現、地域文化を不正確に扱う表現は避けるべきです。
まずやることは、人物が映る画像・動画と、設備・混雑・品質確認だけに使う画像を分け、保存期間と閲覧権限を決めることです。
3. LLM 利用時の主要リスク
ハルシネーションと誤情報
LLM はもっともらしい文章を生成しますが、常に正しいとは限りません。観光業では、以下の誤回答が直接クレームになります。
存在しない交通手段を案内する
古い営業時間を案内する
休業日を誤る
料金やキャンセル条件を間違える
ビザ、免税、通関、医療、災害対応を断定する
施設が提供していないサービスを「利用可能」と答える
対策は、AI に自由回答させるのではなく、公式 FAQ、PMS、予約規約、館内ルール、地域観光データベースなどの根拠データに接続することです。回答には「根拠文書」「最終更新日」「人への引き継ぎ条件」を持たせます。
RAG を使う場合も、古い FAQ や重複文書が残っていると誤回答の原因になります。ナレッジ管理では、版管理、失効日、更新責任者、回答に使ってよい文書の範囲を決めます。
データ漏えい
外部 API にプロンプトを送る場合、そこに個人情報や機密情報が含まれていれば、外部サービスへ送信したことになります。特に宿泊業では、以下の情報に注意が必要です。
氏名、住所、電話番号、メールアドレス
パスポート情報
宿泊日、同行者、部屋番号
決済、請求、領収書情報
アレルギー、食事制限、健康状態
宗教上の配慮
苦情、事故、トラブル履歴
VIP、著名人、団体名
個人情報を含む問い合わせを AI に処理させる場合は、入力前にマスキングする、国内・契約済み環境に限定する、ログ保存期間を短くする、学習利用の有無を確認する、委託先管理を行う、といった対策が必要です。
より安全なのは、そもそも AI に送らない設計です。氏名、電話番号、予約番号、部屋番号、決済情報は、回答に不要であれば削除します。分析用途では、個人単位ではなく集計データを優先し、必要に応じて仮名加工情報や匿名加工情報として扱えるかを検討します。
注意
個人情報保護委員会は、生成 AI サービス利用時の個人情報の取扱いについて注意喚起を出しています。個人データを第三者に提供する場合の同意、利用目的の範囲、安全管理措置、外国にある第三者への提供などは、サービス仕様と契約条件で結論が変わります。宿泊者情報やセンシティブな情報を扱う場合は、所轄監督庁・専門家に最終確認してください。
主要 LLM プロバイダのデータポリシー観点
主要 LLM プロバイダの API 利用では、学習利用、ログ保持、第三者提供、データ所在地の扱いがサービス種別や設定により異なります。下記は 2026年5月時点の確認観点であり、実装前には各社の最新規約、DPA、管理画面設定、契約区分を確認してください。
OpenAI API：API に送信したデータは、明示的にオプトインしない限り、モデルの学習・改善には使われないと説明されています。標準では不正利用監視等のためのログ保持があり、対象顧客は Zero Data Retention などの保持制御を申請できる場合があります。
Anthropic API / Claude 商用利用：Anthropic API や Claude for Work などの商用製品では、顧客が明示的にモデル改善プログラム等へ参加しない限り、入力・出力を学習に使わないと説明されています。ただし個人向け Claude、Claude Code、第三者経由利用では条件が異なるため契約区分を確認します。
Google Gemini API：無料利用枠や Google AI Studio の扱いと、有効な Cloud Billing に紐づく有料サービスで扱いが異なります。無料サービスでは入力・出力が製品改善に使われ、人間のレビュー対象となる場合があります。有料サービスでは、プロンプトや応答を製品改善に使わないと説明されています。Cloud Billing を有効化した場合は、無料枠利用分も Paid Service 扱いになる場合があります。
確認先の例：
OpenAI Platform data controls: https://platform.openai.com/docs/guides/your-data
OpenAI API data controls: https://platform.openai.com/docs/guides/your-data
Anthropic Privacy Center: https://privacy.anthropic.com/en/articles/7996868-is-my-data-used-for-model-training
Google Gemini API Additional Terms: https://ai.google.dev/gemini-api/terms
個人情報保護委員会 生成 AI 注意喚起: https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
注意
各社のデータ利用・保存・学習設定は変更される可能性があります。実装前には、最新の利用規約、データ処理契約、管理画面の設定、リージョン、ログ保持、サブプロセッサ、DPA の有無を確認してください。補助金を使う場合は、対象経費、クラウド利用料、保守費、既存システム連携費の扱いについて最新の公募要領を要確認です。
4. AI に任せると失敗するタスク
AI に任せるべきではないのは、正解が曖昧で、責任が重く、相手の感情に配慮する必要がある場面です。
クレーム対応の最終判断（法的・金銭的責任が伴う）
料金トラブル・誤予約の最終説明
返金、補償、アップグレード、特別対応の決定
災害・事故・急病時の最終案内
宿泊拒否、迷惑行為、警察・消防連携の判断
センシティブな情報を含むやり取り（健康・宗教・政治・国籍・障害）
ホスピタリティの核心（個別配慮、サプライズ、対面の温度）
地域文化・歴史・信仰に関する断定的説明
AI は「一次回答」「候補生成」「要約」「翻訳」「記録整理」には向いています。一方で、最終判断、謝罪、例外対応、ブランド体験の設計は人が担うべきです。
災害、交通途絶、感染症、事故対応では、AI に断定させず、自治体、交通機関、消防、警察、観光協会などの最新公式情報へ誘導する運用にします。
5. AI エージェントの現在地と注意点
AI エージェントとは、単に回答するだけでなく、複数のツールを使い、自律的にタスクを進める AI のことです。観光業では、以下のような使い方が考えられます。
OTA メッセージを読み、FAQ から回答案を作る
PMS の空室状況を確認し、予約変更案を作る
顧客属性に応じて観光ルートを提案する
レビューを分類し、改善タスクを作る
SNS 投稿案、画像案、翻訳文をまとめて生成する
需要予測をもとに人員配置案を出す
ただし、2026 年時点では「完全自律で任せる」よりも、「AI が下書きし、人が承認する」設計が現実的です。特に、予約変更、返金、価格変更、在庫変更、個人情報の外部送信、顧客への自動送信は、人の確認を挟むべきです。
ヒント
AI エージェント導入時は、いきなり「予約業務を全部任せる」のではなく、まずは「回答案を作る」「社内メモを作る」「次に確認すべき項目を出す」など、実行権限を持たない補助タスクから始めると安全です。
6. 個人情報保護法 × AI の実務設計
観光・宿泊業で AI を使う場合、個人情報保護法との関係を避けて通れません。特に宿泊者情報は、旅行目的、同行者、国籍、食事制限、健康状態、宗教上の配慮など、センシティブな文脈を含みます。
要配慮個人情報に該当し得る健康・障害・医療情報、宗教・信条に関わる情報に加え、国籍、食事制限、同行者情報なども文脈によってセンシティブに扱います。たとえば食事制限は、単なる嗜好ではなく、宗教、健康状態、アレルギーを推知させる場合があります。
実務では、以下を分けて設計します。
利用目的：問い合わせ対応、予約管理、本人確認、マーケティング、需要予測、品質改善を混同しない
入力データ：AI に送る前に、氏名、電話番号、予約番号、部屋番号、決済情報をマスキングする
データ最小化：回答に不要な個人情報は AI に送らず、集計データや匿名化したデータを優先する
同意設計：顧客対応に AI を使うこと、外部サービスに送信される可能性、ログ保存の有無を明示する
保存期間：AI ログ、チャット履歴、音声、画像、動画の保存期間を決める
第三者提供・委託：外部 API、SaaS、BPO、開発会社との契約関係を整理する
共同利用：地域 DMO、自治体、宿泊事業者、観光施設でデータを共同利用する場合、共同利用する項目、利用目的、管理責任者、範囲を明示する
委託先監督：開発会社、AI ベンダー、BPO、翻訳会社、コールセンターに委託する場合、再委託、ログ閲覧、削除、事故報告の条件を確認する
越境移転：国外事業者・国外サーバーを使う場合の説明・同意・情報提供を確認する
匿名加工情報・仮名加工情報：統計分析や需要予測に使う場合、個人を識別できない形に加工できるか、元データとの照合を制限できるかを確認する
アクセス権限：フロント、清掃、予約、マーケティング、経営層で閲覧範囲を分ける
監査ログ：誰が、いつ、どのデータを AI に送ったかを追えるようにする
要配慮個人情報に該当し得る健康情報、宗教、障害、医療対応などは、通常の問い合わせとは分けて扱います。たとえば「アレルギー対応」は宿泊体験に不可欠ですが、AI にそのまま送るのではなく、必要最小限の項目に限定し、同意と利用目的を明確にする必要があります。
自治体・DMO が地域単位でデータを扱う場合は、単一施設の AI 導入よりも関係者が増えます。共同利用なのか、委託なのか、第三者提供なのかを曖昧にしたまま進めると、後からデータ連携が止まります。地域 OS 型の設計では、機能開発より先にデータの責任分界点を決めることが重要です。
7. 導入の順序（推奨）
自動応答：ROI が見えやすい。OTA メッセージ・FAQ・館内案内から開始
多言語：自動応答の延長として導入。インバウンド施設・観光案内所・DMO は優先度が高い
需要予測：6 ヶ月以上のデータで簡易監視を始め、2〜3 年分のデータで季節性を含む予測検証に進む
画像・動画解析：清掃チェック、備品確認、混雑把握など客観タスクから開始。顔認識や行動追跡は慎重に扱う
AI エージェント：回答案作成、社内メモ、レビュー分類などから始め、予約変更・返金・価格変更は人の承認を残す
導入の基本は、「失敗しても被害が小さい業務」から始めることです。顧客に直接送信する前に、まずは社内利用で精度を測ります。
ヒント
OYKOT が掲げる Destination OS（DOS）の文脈では、AI は単体ツールではなく、地域の観光データ、宿泊データ、イベント情報、交通情報、問い合わせログ、顧客体験データをつなぐ知能層として設計することが重要です。単体業務の効率化から始め、将来的に観光地経営、回遊促進、需要平準化へ広げる順序が現実的です。
8. コスト試算の考え方
AI 導入費用は、月額固定型、従量課金型、初期開発型、SaaS 型で大きく変わります。
自動応答：問い合わせ件数、有人確認、FAQ 更新、PMS / CRM 連携、ログ保存条件で変動
需要予測 SaaS：施設数、連携データ、競合データ、価格変更の自動化範囲、運用支援で変動
多言語対応：対象言語、文字量、音声・動画、有人レビュー、用語集管理で変動
API 課金型：入力トークン、出力トークン、画像、音声、動画、検索、ベクトル DB、ログ保存、監視機能に応じて変動
初期構築：FAQ 整備、PMS・OTA・CRM 連携、管理画面、権限設計、セキュリティレビューにより変動
運用費：回答品質レビュー、FAQ 更新、プロンプト改善、障害対応、法務確認、個人情報管理を含めて見積もる
費用は、施設数、対応言語数、既存システム連携、個人情報管理、有人レビュー、保守体制、SLA によって大きく変わります。検討時は、月額だけでなく初期構築、データ連携、品質レビュー、法務確認、契約終了時のデータ返却・削除条件まで含めて比較します。
API 課金型では、問い合わせ件数だけでなく、1 件あたりの文量、翻訳言語数、会話往復数、画像・音声の有無で費用が変わります。PoC では、想定件数の 1.5〜2 倍程度の利用量で上限アラートを設定しておくと安全です。
補助金を活用する場合、2026 年度は旧 IT 導入補助金に相当する制度として「デジタル化・AI 導入補助金 2026」が案内されています。通常枠では、ソフトウェア購入費、クラウド利用料、導入関連費などが対象になり得ます。ただし、申請枠、対象経費、補助率、登録済み IT ツール要件、クラウド利用料の対象期間は公募要領で確認してください。
観光分野では、観光庁の令和 8 年度「全国の観光地・観光産業における観光 DX 推進事業」も候補になり得ます。同事業では、地域コンテンツの販路拡大、マーケティング強化、レベニューマネジメント等に資するデジタルツール導入支援、DX 専門人材による伴走支援などが示されています。
補助制度を使う場合は、AI ツール本体だけでなく、FAQ 整備、データ連携、セキュリティレビュー、研修、運用設計、効果測定が対象に含まれるかを確認します。採択後に「ツール費だけは対象だが、運用改善や既存システム連携は対象外」と判明すると、実装範囲が狭くなります。
確認先の例：
デジタル化・AI 導入補助金 2026 通常枠: https://it-shien.smrj.go.jp/applicant/subsidy/normal/
中小企業庁 デジタル化・AI 導入補助金: https://www.chusho.meti.go.jp/shogyo/shogyo/hojyokin/it.html
観光庁 令和 8 年度 全国の観光地・観光産業における観光 DX 推進事業: https://www.mlit.go.jp/kankocho/kobo06_00047.html
観光庁 観光 DX の推進: https://www.mlit.go.jp/kankocho/seisaku_seido/kihonkeikaku/jizoku_kankochi/kanko-dx.html
観光庁 宿泊旅行統計調査: https://www.mlit.go.jp/kankocho/tokei_hakusyo/shukuhakutokei.html
注意
補助金・助成制度は年度、予算、申請枠、事務局、対象経費、採択要件が変わります。申請前には、所轄監督庁、最新公募要領、交付規程、FAQ、自治体の募集要項を必ず確認してください。
9. 評価の仕方
AI 導入は、導入前に KPI を決めておかないと評価できません。最低限、Before/After を 30 日以上で比較します。季節変動が大きい地域では、前年同月や同曜日との比較も必要です。
削減工数（人時）
一次回答率
人へのエスカレーション率
誤回答率
返信時間
予約転換率
直販比率
ADR
RevPAR
キャンセル率
CSAT
NPS
レビュースコア
クレーム件数
多言語問い合わせの解決率
補助指標として、以下も見ると運用改善につなげやすくなります。
FAQ の最終更新日と更新件数
AI が参照した根拠文書の表示率
人が修正した回答案の割合
個人情報を含む入力の検知件数
マスキング漏れ件数
上限予算アラートの発生件数
ベンダー障害・API エラー件数
回答できなかった問い合わせの分類
災害・交通・医療など高リスク質問のエスカレーション率
導入直後は、一時的に顧客体験が悪化することがあります。FAQ が古い、PMS 連携が不十分、AI が断定しすぎる、人への引き継ぎが遅い、といった原因が多いです。最初の 30〜60 日は、精度検証と運用改善の期間として扱います。
宿泊統計や地域統計を評価に使う場合は、統計定義の変更にも注意します。特に宿泊旅行統計調査は 2026 年 1 月調査分から層化基準が変わっているため、2025 年以前との比較では、AI 導入効果と統計設計変更の影響を分けて考えます。
10. 導入前チェックリスト
AI に送るデータに個人情報・要配慮個人情報が含まれるか
外部 API に送信する場合、学習利用、ログ保持、リージョン、サブプロセッサを確認したか
共同利用、第三者提供、委託、再委託のどれに当たるかを整理したか
匿名加工情報、仮名加工情報、集計データで代替できる範囲を確認したか
FAQ、規約、料金、営業時間、アクセス情報の最終更新日が明確か
AI が回答してよい範囲と、人に渡す条件が決まっているか
誤回答時の責任者と修正フローがあるか
顧客への表示文言、同意、プライバシーポリシーの整合性を確認したか
PMS、OTA、CRM、サイトコントローラーとの連携範囲を決めたか
API 利用量の上限、アラート、予算管理を設定したか
補助金を使う場合、最新の公募要領を確認したか
法令・個人情報・越境移転に関わる点を所轄監督庁または専門家に最終確認したか
PoC 設計テンプレート
対象業務：OTA メッセージ、FAQ、館内案内、多言語返信、需要予測などから 1 つに絞る
期間：最短 30 日、季節変動が大きい場合は 60〜90 日
対象データ：AI に送るデータ、送らないデータ、マスキングするデータを分ける
成功条件：削減工数、誤回答率、返信時間、エスカレーション率、CSAT などを事前に決める
人の確認：顧客送信前に確認する範囲、AI が自動送信してよい範囲を決める
停止条件：誤回答、個人情報漏えい、費用超過、クレーム増加時の停止基準を決める
AI に渡してよい / だめなデータ分類例
渡してよい：公開済み FAQ、館内案内、アクセス情報、観光施設の公開情報、匿名化した問い合わせ分類
条件付きで渡す：予約日、人数、部屋タイプ、食事希望、問い合わせ履歴、レビュー文
原則渡さない：氏名、電話番号、メールアドレス、住所、パスポート番号、予約番号、部屋番号、決済情報
特に慎重に扱う：健康状態、アレルギー、障害、宗教上の配慮、事故・苦情履歴、VIP・著名人情報
ベンダー質問例
入力データと出力データは、モデル学習に使われますか
ログはどの国・地域に保存され、何日保持されますか
Zero Data Retention やログ保持期間の短縮は可能ですか
サブプロセッサ、再委託先、国外移転の有無を開示できますか
顧客データを削除した場合、バックアップやログからも削除されますか
FAQ、会話ログ、ベクトル DB、プロンプト、評価データをエクスポートできますか
障害時、誤回答時、情報漏えい時の報告期限と責任分界点はどうなりますか
PMS、OTA、CRM、サイトコントローラー連携時の権限範囲を制限できますか
補助金申請に必要な見積書、機能説明、保守費内訳を出せますか
NG サイン
「個人情報は入れても大丈夫です」とだけ説明し、契約条件やログ保持を示さない
モデル学習利用の有無を明確に答えられない
サブプロセッサ、保存国、削除方法を開示できない
FAQ や会話ログをエクスポートできない
誤回答時の修正フローや監査ログがない
AI が参照した根拠文書を表示できない
予約変更、返金、価格変更を初期設定で自動実行する
補助金対象経費と対象外経費を分けた見積もりを出せない
災害、医療、法令、交通途絶に関する回答を断定的に生成する
関連：観光業のSNSマーケティング／観光ガイドのデジタル化／PMS とは（自動化との接続）
