民泊・簡易宿所のハウスマニュアル多言語化と問い合わせ対応をClaude Codeで回す

夜11時、スマホが光りました。台湾から来たゲストです。「The lock box code doesn’t work」。鍵が開かない、という連絡でした。

僕はその日、別の予約の清掃に追われていて、英語のマニュアルを開く余裕がありませんでした。日本語のハウスマニュアルはあった。でも英語版は、半年前に翻訳ツールへ通したきり、玄関の暗証番号が古いまま放置されていたんです。結局、僕がスマホで一文ずつ英語を打ち、ゲストを30分待たせました。レビューには星4つと「response was a bit slow」のコメント。星ひとつぶんの損は、次の予約の機会損失につながります。

民泊・簡易宿所をやっていると、こういう「言葉の壁 × 時間の壁」が同時に来る瞬間が必ずあります。今日はその二つを、Claude Codeと生成AIで小さく削る話をします。魔法ではありません。地味に効く道具の話です。

この記事の要点

• ハウスマニュアルの多言語化は「翻訳」ではなく「元データを1つに保ち、各言語へ自動展開する」と考えると壊れにくい
• 問い合わせ返信は、よくある質問を型化してAIに下書きさせ、最終送信だけ人が判断するのが安全
• 暗証番号・住所・連絡先などの個人情報や鍵情報は、AIへ渡す前にプレースホルダ化して切り離す
• 翻訳と返信下書きを仕組み化すると、1物件あたり月3〜5時間、対応の初動が30分→5分に縮む試算
• 最後に「AIに任せる範囲」と「人が必ず判断する範囲」を線引きする

読者像と、いまの業務フロー

この記事が想定する読者は、1〜10室くらいを個人または数人で回している民泊・簡易宿所のホストです。専業の人もいれば、本業の片手間でやっている人もいる。共通するのは、清掃・予約管理・問い合わせを少人数で抱えていて、英語や中国語のネイティブではない、という点です。

いまの問い合わせ対応は、だいたいこんな流れになっていませんか。

1. AirbnbやBooking.comの受信箱に、英語や中国語でメッセージが届く
2. 内容をなんとなく読み取り、翻訳アプリに貼って意味を取る
3. 返信を日本語で考え、また翻訳アプリで相手の言語に直す
4. 訳が変でないか不安なまま、えいやで送信する
5. ハウスマニュアルに書いてある内容なのに、毎回ゼロから打ち直している

このループの何が問題か。同じ質問（チェックインの時間、ゴミの分別、最寄り駅からの道順）に、毎回手作業で答えている点です。マニュアルに書いてあるのに、言語が違うだけで「ない」のと同じになっている。ここがAIの出番です。

よくある手戻りと困りごと

民泊・簡易宿所の現場で、僕が実際に踏んだ手戻りを並べます。

• 暗証番号を変えたのに英語版だけ古い。日本語マニュアルだけ直して、多言語版の更新を忘れる。これが鍵トラブルの最多原因でした。
• 翻訳の調子が物件ごとにバラバラ。ある物件は丁寧語、別の物件はぶっきらぼう。複数物件を持つと統一感が消えます。
• 同じ質問に毎回フルで返信。「ゴミは何曜日？」に、毎回3行打つ。1日5件来れば、それだけで20分。
• 機械翻訳の事故。「布団を畳んでください」が「Please fold the futon mattress and throw it away」みたいなニュアンスになり、ゲストが混乱した、という笑えない話もありました。

困りごとの根っこは「翻訳を毎回その場でやっている」ことです。元になる文章が一箇所に整理されていないから、更新も品質も安定しない。

AIに任せる範囲と、人が必ず判断する範囲

先に線引きをしておきます。ここを曖昧にすると、AIは親切心で勝手に住所を書き換えたり、勝手に割引を約束したりします。

工程	AIに任せてよい	人が必ず判断する
マニュアル翻訳	各言語への下訳、言い回しの統一	暗証番号・住所・緊急連絡先の正しさ
問い合わせ返信	定型質問の下書き作成	送信ボタン、料金・延長・返金の約束
トーン調整	丁寧さの統一、誤字脱字	物件ごとのハウスルールの最終確認
FAQ整備	質問の分類、抜け漏れの指摘	法令・消防・近隣ルールに関わる記述

原則はシンプルです。「お金」と「鍵」と「法律」に触れる判断は、最後まで人がやる。それ以外の、文章を整える・言語を増やす・下書きを作る作業は、どんどんAIに渡していい。

Use case 1：ハウスマニュアルを1つの元データから多言語展開する

いちばん効くのがこれです。発想を変えます。「日本語マニュアルを翻訳する」のではなく、「項目ごとに区切った元データを1つ持ち、そこから各言語を吐き出す」。

まず、マニュアルを項目に分解します。チェックイン、Wi-Fi、ゴミ、設備の使い方、緊急連絡先、退室手順。この単位で日本語を1つだけ正として持ちます。暗証番号や住所のような変わりやすい・秘密にすべき値は、本文に直接書かず {{door_code}} のような印（プレースホルダ）にしておきます。

そのうえで、Claude Codeに次のように頼みます。

あなたは民泊・簡易宿所のハウスマニュアル翻訳担当です。
以下の日本語マニュアルを、英語・繁体字中国語・韓国語に翻訳してください。

制約:
- {{ }} で囲まれた値は翻訳せず、そのまま残す
- ゲストへの敬意を保ちつつ、短く明確な文にする
- 各言語で表現のトーンを統一する
- 専門用語や和製英語は避け、海外ゲストが初見で分かる語にする
- 翻訳できない固有名詞は原語のまま残し、括弧で簡単な説明を足す

出力: 言語ごとに見出しを付け、項目の順番は元の日本語と揃える

---
（ここに項目分けした日本語マニュアルを貼る）

プレースホルダを使う理由は2つあります。1つは、暗証番号を変えたときに元データの1箇所を直すだけで全言語に反映できること。もう1つは、鍵情報をAIへの入力からも翻訳結果からも切り離せて、情報漏れの面で安全なことです。

実際の差し込みは、こんな短いスクリプトで自動化できます。Node.jsがあれば動きます。

import { readFile, writeFile } from "node:fs/promises";

// 鍵・住所などの秘密情報はコードの外（環境変数や別ファイル）で管理する
const secrets = {
  door_code: process.env.DOOR_CODE || "0000",
  wifi_pass: process.env.WIFI_PASS || "changeme",
  emergency_tel: process.env.EMERGENCY_TEL || "000-0000-0000",
};

function fillPlaceholders(template, values) {
  return template.replace(/\{\{(\w+)\}\}/g, (whole, key) => {
    if (key in values) return values[key];
    throw new Error(`未定義のプレースホルダ: ${key}（secretsに追加してください）`);
  });
}

// 翻訳済みテンプレート（プレースホルダ入り）を読み、最終版を書き出す
const langs = ["en", "zh", "ko"];
for (const lang of langs) {
  const template = await readFile(`manual.${lang}.txt`, "utf8");
  const filled = fillPlaceholders(template, secrets);
  await writeFile(`out.manual.${lang}.txt`, filled, "utf8");
  console.log(`${lang}: 完成 (${filled.length}文字)`);
}

このスクリプトのポイントは、未定義のプレースホルダが残っていたらエラーで止まる点です。{{door_code}} を埋め忘れたまま英語版を配る、という事故を機械が防いでくれます。暗証番号を変えたら DOOR_CODE を更新して1回流すだけ。全言語が同時に最新になります。

Use case 2：定型の問い合わせをAIに下書きさせる

次は問い合わせ返信です。海外ゲストからの質問は、実は8割が定型です。チェックイン時刻、駅からの行き方、Wi-Fi、ゴミ出し、チェックアウト手順。これを「質問の型 → 返信の下書き」までAIに任せます。

返信下書き用のプロンプト雛形がこれです。

あなたは民泊・簡易宿所のホストの返信アシスタントです。
ゲストからのメッセージに対し、丁寧で短い返信の下書きを作ってください。

ルール:
- ゲストの言語と同じ言語で返す
- ハウスマニュアル（後述）に答えがあれば、その内容だけを使う
- マニュアルにない・料金や延長に関わる内容は「ホスト確認が必要」と印を付け、本文には書かない
- 返信の最後に、署名や物件名はこちらで足すので空けておく

ハウスマニュアル抜粋:
（チェックイン、Wi-Fi、ゴミ、退室手順などを貼る）

ゲストのメッセージ:
（ここに受信メッセージを貼る）

大事なのは「マニュアルにない内容・お金の話は本文に書かせず、印を付けさせる」という制約です。これでAIが勝手に「延長は無料です」などと約束する事故を防げます。下書きを読んで、問題なければ送る。確認が要る箇所だけ自分で書き足す。この一手間で、初動が30分から5分になります。

定型化の精度を上げたいなら、まず自分の受信箱から「よくある質問トップ10」を抜き出してFAQにします。FAQ作り自体もAIに手伝わせられます。「過去の返信ログを貼るので、質問を10カテゴリに分類して、それぞれの標準回答案を作って」と頼むだけです。

Use case 3：物件横断でトーンと最新性をそろえる

複数物件を持つと、マニュアルの品質がバラつきます。そこで定期的に、全物件のマニュアルをまとめてAIにレビューさせます。

チェックリストとして、こう頼みます。

以下は複数物件のハウスマニュアルです。次の観点でレビューしてください。
1. 暗証番号・連絡先などのプレースホルダが {{ }} のまま残っていないか
2. 物件ごとに敬語のトーンがずれていないか
3. ゴミ分別や退室手順で、説明が抜けている項目はないか
4. 海外ゲストが誤解しそうな和製英語・あいまい表現はないか
問題箇所を物件名・項目・理由つきで一覧にしてください。修正は提案だけで、勝手に書き換えないこと。

「勝手に書き換えない」と明示するのがコツです。レビューは提案までにして、採用するかは人が決める。これで「気づいたら住所が別物件のものに差し替わっていた」みたいな事故が消えます。

導入前と後で何が変わるか

僕の1物件での体感を、ざっくり数字にします。あくまで概算で、物件や稼働率で前後します。

項目	導入前	導入後
多言語マニュアル更新	言語ごとに手作業、半日	元データ1箇所を直して再生成、15分
問い合わせの初動	翻訳しながら30分	下書き確認＋送信で5分
暗証番号変更時の反映	全言語を手で直す、漏れがち	スクリプト1回、漏れゼロ
月あたりの対応時間	ー	物件あたり3〜5時間の削減目安

時給換算で考えると、月3〜5時間が浮けば、1物件でも数千円ぶんの時間が戻ります。複数物件なら効果はそのまま掛け算です。導入のコスト側は、AI利用料が月数百円〜、初期の型作りに半日。元が取れる速さで言えば、かなり早い部類だと感じています。

Claude Codeそのものの始め方が曖昧な人は、先にClaude Code はじめての導入ガイドを読んでおくと、このあとのプロンプトが動かしやすくなります。コードに不慣れでも進めたいなら非エンジニアのためのClaude Codeが入口として向いています。

セキュリティと個人情報の注意点

ここは民泊・簡易宿所だからこそ、特に気をつけてほしい点です。

• 暗証番号・鍵情報をAIへの入力に直接書かない。プレースホルダ化して、実値はスクリプト側（環境変数や手元の別ファイル）で差し込む。AIのチャット履歴に鍵情報を残さないのが基本です。
• ゲストの氏名・パスポート・予約番号を不用意に貼らない。問い合わせ内容を貼るときは、本文の用件だけにして個人を特定できる情報は削る。
• 返信の最終送信は人が押す。AIの下書きをそのまま自動送信にすると、誤情報や不適切な約束がそのまま届きます。
• 無料の翻訳サービスにマニュアル全文を流し続けない。どこに何が保存されるか不明なサービスへ、住所込みの全文を投げ続けるのは避けます。

民泊は「現実の住所と鍵」が絡む商売です。デジタルの便利さと、物理の安全は別管理にする。この線引きだけは崩さないでください。プロンプトでルールを徹底させる考え方はCLAUDE.md ベストプラクティスが参考になります。総務省の住宅宿泊事業法（民泊制度）ポータルも、運用ルールの一次情報として一度目を通しておくと安心です。

よくある質問

Q. 機械翻訳との違いは何ですか。 A. 単語の置き換えではなく、「短く・誤解なく・トーンをそろえて」と条件を付けて文章として整えられる点です。さらにプレースホルダで鍵情報を切り離せるので、更新の手間と漏えいリスクが同時に下がります。

Q. プログラミングは必須ですか。 A. 翻訳と返信下書きだけならコードなしで、プロンプトを貼るだけで回せます。差し込みスクリプトは「あると楽」な補助で、コピペで動く範囲です。手応えが出てから足せば十分です。

Q. 何語まで対応できますか。 A. 元データが整っていれば、英語・中国語・韓国語あたりは実用レベルです。ただし出力は必ず一度、自分の目か、その言語が分かる知人に確認してもらってから配ってください。

Q. ゲストへの返信を全自動にしてよいですか。 A. やめたほうがいいです。料金・延長・返金・近隣トラブルは、人が判断すべき領域です。下書きまでをAI、送信ボタンは人、の分担が事故を防ぎます。

Q. 複数物件でも使えますか。 A. 使えます。物件ごとに元データを分けて持ち、レビュー用プロンプトで横断チェックすれば、トーンと最新性をそろえられます。プロンプトの精度を上げたいならプロンプト設計の応用も合わせてどうぞ。

次の一歩

個人で学びながら試したいホストは、まず無料PDF・教材ページで型を手に入れて、自分の1物件で小さく回してみてください。複数物件や運営代行で、チームとして業務改善まで設計したい場合は研修・導入相談が合います。読者の段階に合わせて、どちらか一方から始めれば十分です。

実際に試した結果

冒頭の「夜11時の鍵トラブル」のあと、僕は自分の物件で実際にこの仕組みを組みました。確かめたのは3点です。

1つ目は、プレースホルダ方式が本当に事故を減らすか。暗証番号を変えてスクリプトを1回流したら、英語・中国語・韓国語の3版が同時に最新になりました。手で直していた頃の「英語版だけ古い」が物理的に起きなくなった。これがいちばん効きました。

2つ目は、返信下書きの精度。過去の問い合わせ20件をAIに下書きさせ、自分の手書きと比べました。定型質問の17件は、ほぼ手直しなしで送れる品質。残り3件は料金や延長がらみで、これは予定どおり「ホスト確認」の印が付いていて、人が書く前提どおりに動きました。

3つ目は時間。チェックイン前夜の問い合わせ対応が、平均で30分前後から5分前後に縮みました。星4だったレビューが、次のゲストでは返信の速さに触れた星5に戻ったときは、正直うれしかったです。

派手な自動化ではありません。鍵とお金の判断は手元に残したまま、翻訳と下書きだけを機械に寄せる。この小さな線引きが、民泊・簡易宿所の現場では効くというのが、いまの実感です。