【2026年版】観光協会DMOの5言語対応をClaude Codeで効率化

はじめに:なぜ「観光協会の多言語対応」がここまで重い仕事になってしまったのか

正直に書くと、観光協会・DMOの多言語対応の現場を一度でも手伝ったことがある人なら、「翻訳費用が高い」よりも「翻訳が終わらない」「終わってもメンテできない」という疲弊感のほうが先に来るのを知っているはずだ。私(著者・佐藤)も、地方の観光連携プロジェクトに研修・伴走の立場で関わる中で、「英訳が3ヶ月前に止まっている」「中国語(簡体)はあるけど繁体字は2年前のまま」「韓国語はSNSだけ、Webにはない」「タイ語は印刷物にだけある」という状態を、自治体側・DMO側・宿泊事業者側のどこでも見てきた。

原因を本気で分解すると、翻訳そのもののコストよりも、次の4つが効いている。

1. 素材が断片化している — Web、SNS、印刷物、観光案内所の口頭対応、宿泊施設データ、それぞれの担当が違い、フォーマットも違い、原文も「最新版」が一意に決まらない。
2. 固有名詞・伝統文化の訳語が揺れる — 同じ祭りが英語表記で3パターンある。寺社名のローマ字表記が記事ごとに違う。料理名の説明が媒体ごとに違う。
3. 季節更新が間に合わない — 桜・紅葉・雪・夏祭り・冬イベントの差し替えが、Web・SNS・印刷物で時期がずれる。
4. 媒体ごとの「ふさわしい表現」が暗黙知 — Webは中立的に、Instagramはエモく短く、Facebookは現地在住の家族層向け、TripAdvisor回答は丁寧に。これが言語化されていない。

つまり、ここで必要なのは「もう一段すごい翻訳エンジン」ではなく、「素材・辞書・季節・媒体の4軸を構造化して、5言語版を並列で生成・更新できる仕組み」だ。これはまさにClaude Codeのようなコマンドラインで動くAIコーディング・運用エージェントが本領を発揮する領域に当てはまる。

本記事では、観光協会・DMO・自治体観光課を想定した実装シナリオとして、リポジトリ構成、固有名詞辞書、5言語マトリクス、季節別カレンダー、媒体別テーブル、問い合わせ対応の下書き生成までを、Claude Codeでそのまま動かせる形で整理する。なお、本記事で示す実績数値・地域名・施設名はすべて想定例であり、特定の観光協会・DMOの固有実績ではない。実装は必ず該当地域のネイティブ担当者・有資格翻訳者の最終確認を経て公開すること。

全体設計:多言語インバウンド運用を「リポジトリ」として捉え直す

最初にやるべきことは、観光協会の多言語対応素材を、Webサイトの管理画面やSNS各社のダッシュボードの中ではなく、Gitで管理できる単一のリポジトリに集約することだ。「公開先はWordPressや各SNSだが、原本(ソースオブトゥルース)はリポジトリにある」という形に変える。

想定するリポジトリ構成は次のとおり。

tourism-dmo-multilingual/
├── CLAUDE.md                       # Claude Codeへの常駐指示書
├── glossary/
│   ├── tourism-glossary.yaml       # 固有名詞・伝統文化・料理の対訳辞書
│   ├── style-guide-ja.md
│   ├── style-guide-en.md
│   ├── style-guide-zh-Hans.md
│   ├── style-guide-zh-Hant.md
│   ├── style-guide-ko.md
│   └── style-guide-th.md
├── calendar/
│   ├── seasonal-events.yaml        # 季節・月別イベント差分
│   └── update-windows.yaml         # 言語別の更新タイミング
├── content/
│   ├── attractions/                # 観光スポット (原文MD + 言語別MD)
│   ├── itineraries/                # モデルコース
│   ├── faqs/                       # よくある質問
│   └── seasonal/                   # 季節コンテンツ
├── lodging/
│   ├── facilities.csv              # 宿泊施設マスタ
│   └── attributes-schema.yaml      # 属性スキーマ(Wi-Fi/ハラル対応 等)
├── social/
│   ├── channels.yaml               # SNS媒体別の表現ルール
│   └── drafts/                     # 投稿下書き
├── inquiry/
│   ├── templates/                  # 問い合わせ返信テンプレ
│   └── log.csv                     # 対応ログ
└── scripts/
    ├── translate.sh
    ├── audit-glossary.sh
    └── season-roll.sh

ポイントは、Claude Codeが起動すると CLAUDE.md を自動で読み込み、その指示に従ってリポジトリ全体を一貫して扱えるようになることだ。WordPressやSNSは「最終的な公開先」であって、原本はリポジトリ側に置く。これにより、翻訳バージョン管理、差分レビュー、季節更新、媒体別表現の使い分けが、すべてgit diffで追跡できるようになる。

CLAUDE.md(常駐指示書)の例

以下は、観光協会・DMOの多言語運用リポジトリに置く想定の CLAUDE.md サンプルだ。Claude Codeは起動時にこの内容を読み込み、毎回のプロンプトに「前提として」適用する。

# CLAUDE.md - 多言語観光コンテンツ運用ルール

## 役割
あなたは観光協会・DMOの多言語コンテンツ運用を支援するアシスタントです。
最終的な翻訳の品質保証は人間のネイティブ翻訳者・地域住民が行います。
あなたは「下書き生成・整合チェック・差分提示」を担当します。

## 対象言語(5言語)
- en : 英語(English) - 主要客層: 北米・豪州・欧州英語圏
- zh-Hans : 中国語簡体字 - 主要客層: 中国本土
- zh-Hant : 中国語繁体字 - 主要客層: 台湾・香港
- ko : 韓国語 - 主要客層: 韓国
- th : タイ語 - 主要客層: タイ

## 必ず参照するファイル
- glossary/tourism-glossary.yaml : 固有名詞対訳辞書(最優先・絶対参照)
- glossary/style-guide-{lang}.md : 言語別文体ガイド
- calendar/seasonal-events.yaml : 季節差分の根拠
- social/channels.yaml : 媒体別表現ルール

## 動作原則
1. 固有名詞は必ずglossaryを参照。辞書にない名詞は新規追加候補としてリストアップし、勝手に訳さない。
2. 翻訳結果には必ず「未確認の固有名詞」「曖昧な表現」「文化的補足が必要な箇所」を末尾に列挙する。
3. ファイル更新は git diff で見える形にする(原文と訳文を別ファイルで管理)。
4. 公開承認の判断はしない。あくまでドラフトとレビュー支援。
5. 季節イベントは calendar/seasonal-events.yaml の "active_window" 期間外の言及は警告する。

## トーン(全言語共通)
- 中立的・事実ベース・観光客に安全と楽しみ方を伝える
- 営業的・誇張的な形容詞は控える("amazing" "stunning" の連発NG)
- 文化的に誤解を招く表現はあえて避ける(宗教施設のドレスコードなど)

## 出力フォーマット
翻訳タスクのときは以下のセクションを必ず付ける:
1. 訳文本体
2. glossary照合結果(使用した語・新規候補)
3. レビュー要確認ポイント(箇条書き)
4. 提案: 関連する季節コンテンツ・SNS文案

このように CLAUDE.md を書いておくと、毎回「これは観光協会の多言語運用ですよ」「辞書を見てね」「ネイティブ確認の前提ですよ」と説明する必要がなくなり、いきなり claude コマンドを起動して具体的なタスクを投げられる。

固有名詞辞書(tourism-glossary.yaml)を最初に作る

多言語対応で最も「効く」のは、実は翻訳エンジンの選定でも、プロンプトの巧拙でもなく、固有名詞辞書を最初に作って育てることだ。観光協会・DMOの場合、固有名詞は次の5カテゴリに分かれる。

1. 地名(市町村・地区・通り・ランドマーク)
2. 寺社・教会・遺跡などの宗教文化施設
3. 祭り・伝統行事・芸能
4. 郷土料理・酒・地場食材
5. 自然(山・川・湖・温泉・名所)

これをYAMLで一元管理すると、Claude Codeがあらゆる翻訳タスクで横串で参照できる。例として、東北地方の架空のエリアを想定した辞書ファイルの一部を以下に示す(想定例)。

# glossary/tourism-glossary.yaml
version: "2026-05"
last_reviewer: "観光協会 多言語委員会 (想定)"

places:
  - id: yamaba-town
    ja: "山場町"
    romaji: "Yamaba"
    en: "Yamaba Town"
    zh-Hans: "山场町"
    zh-Hant: "山場町"
    ko: "야마바초"
    th: "เมืองยามาบะ"
    description_ja: "架空のモデル町(本記事の想定例)"
    notes:
      - "中国語簡体字では『町』を『町』のまま残すか『镇』に置換するかを地域委員会で判断"
      - "韓国語ローマ字転写は文化観光部の表記法に準拠"

  - id: kanade-shrine
    ja: "奏神社"
    romaji: "Kanade Jinja"
    en: "Kanade Shrine"
    zh-Hans: "奏神社"
    zh-Hant: "奏神社"
    ko: "가나데 신사"
    th: "ศาลเจ้าคานาเดะ"
    visitor_notes:
      en: "Photography is permitted in the outer precinct only."
      ko: "외경 내에서만 사진 촬영이 허용됩니다."
      th: "อนุญาตให้ถ่ายภาพเฉพาะบริเวณรอบนอกของศาลเจ้า"

festivals:
  - id: snow-lantern-festival
    ja: "雪灯ろう祭り"
    en: "Snow Lantern Festival"
    zh-Hans: "雪灯笼节"
    zh-Hant: "雪燈籠祭"
    ko: "눈 등롱 축제"
    th: "เทศกาลโคมไฟหิมะ"
    season: winter
    active_window: "2027-02-05 / 2027-02-12"
    cultural_note_en: "Lanterns are made by local volunteers; please do not touch."

cuisine:
  - id: river-fish-grill
    ja: "川魚の塩焼き"
    en: "Salt-grilled river fish"
    zh-Hans: "盐烤河鱼"
    zh-Hant: "鹽烤河魚"
    ko: "민물고기 소금구이"
    th: "ปลาน้ำจืดย่างเกลือ"
    allergen_notes: ["fish"]
    halal: false

この辞書ができていると、Claude Codeに「この観光ブログ記事を5言語に翻訳して」と頼むだけで、固有名詞は辞書通りに一貫して訳され、辞書にない名詞は末尾に「未登録候補」としてリストアップされる、という運用ができるようになる。「祭りの英訳が記事ごとに違う問題」が、構造的に消えていく。

コピペ可能プロンプト1:多言語マトリクス同時生成

では具体的に、観光スポット紹介ページの日本語原稿を5言語に同時展開するプロンプトを示す。content/attractions/kanade-shrine/ja.md を原稿として、Claude Codeに次のように指示する。

content/attractions/kanade-shrine/ja.md を読み、
glossary/tourism-glossary.yaml と
glossary/style-guide-{en,zh-Hans,zh-Hant,ko,th}.md を参照して、
en.md / zh-Hans.md / zh-Hant.md / ko.md / th.md の5ファイルを生成してください。

要件:
1. 各ファイルの冒頭にYAMLフロントマターを付ける(slug, lang, source_revision, glossary_version)
2. 固有名詞はglossaryを最優先。辞書にない名詞があれば本文中ではローマ字+原語併記とし、ファイル末尾に "## Glossary candidates" として箇条書きで報告
3. 文化的補足(撮影可否・参拝マナー・服装・写真撮影時のドローン制限など)は各言語の文体ガイドに従って加筆
4. 各言語版の長さは原文の0.9〜1.3倍以内に収める
5. 仕上げに5言語横並びの "review-matrix.md" を生成し、各セクションの対訳を表形式で並べてレビューしやすくする
6. 翻訳の最終公開可否はネイティブ翻訳者・地域住民の確認が必要である旨を、各ファイルのフロントマターに "needs_native_review: true" として明示

この一回のプロンプトで、5言語版ドラフトと、レビュー用横並びマトリクスまでが git diff で見える形で生成される。あとは多言語委員会・ネイティブレビュワーが review-matrix.md を見ながら言語ごとに修正コメントを入れていけばよい。実運用では「ドラフト生成 → 各言語担当ネイティブの最終確認 → 公開」という3層の検品レビューを必ず通す前提で設計する。

コピペ可能プロンプト2:固有名詞辞書の整合監査

辞書ができても、運用しているうちに「辞書に登録した訳語と、過去記事内の訳語が食い違っている」状態が必ず発生する。これを定期監査する仕組みも、Claude Codeで組める。

glossary/tourism-glossary.yaml に登録されている固有名詞について、
content/ 配下の全ファイル(*.md)を走査し、
各言語(en, zh-Hans, zh-Hant, ko, th)ごとに「辞書と異なる訳語が使われている箇所」を
ファイルパス・行番号付きで列挙してください。

出力フォーマット:
| glossary id | 言語 | 期待訳 | 実際の表記 | ファイル | 行 |

加えて、辞書には未登録だが本文中で2回以上出現している固有名詞候補を、
出現頻度の多い順に最大30件、"## New glossary candidates" として末尾に列挙してください。

これを月1回などの定期ジョブとして回すと、辞書と本文の乖離が早期に検出できる。新しい固有名詞候補も自動でリストアップされるので、多言語委員会はそのリストをレビューして辞書に追加していくだけで、辞書がじわじわ太っていく。

季節別カレンダーで「いつ何を差し替えるか」を可視化する

観光協会の多言語対応は、桜・紅葉・雪・夏祭りなど季節差分が大きい。これをドメイン側に持たせ、Claude Codeに参照させる。例として calendar/seasonal-events.yaml を以下のように定義する(想定例)。

# calendar/seasonal-events.yaml
seasons:
  spring:
    name_ja: "春"
    months: [3, 4, 5]
    hero_topics: ["cherry-blossom", "spring-festivals", "wild-vegetables"]
    photo_assets_dir: "assets/seasonal/spring"
    publish_window:
      en: "feb-15 / may-31"
      zh-Hans: "feb-01 / may-31"
      zh-Hant: "feb-01 / may-31"
      ko: "feb-20 / may-31"
      th: "feb-20 / may-31"

  summer:
    months: [6, 7, 8]
    hero_topics: ["summer-festivals", "river-activities", "yukata-rental"]
    publish_window:
      en: "may-15 / aug-31"
      zh-Hans: "may-15 / aug-31"

  autumn:
    months: [9, 10, 11]
    hero_topics: ["autumn-leaves", "harvest-foods", "moon-viewing"]

  winter:
    months: [12, 1, 2]
    hero_topics: ["snow-lantern-festival", "hot-springs", "ski-resorts"]
    cultural_notes:
      th: "タイ国内ではスキー文化が一般的でないため、装備レンタル・初心者レッスンを必ず併記"

update_windows:
  - lang: en
    notice: "英語圏は半年前計画が多いため、夏祭りは2月から告知開始"
  - lang: ko
    notice: "韓国は連休直前1ヶ月の駆け込み検索が多いため、長期休暇に合わせて再告知"
  - lang: th
    notice: "タイは長期休暇のソンクラーン(4月)とロイクラトン(11月)前に集中して告知"

これをClaude Codeに渡すと、「来月から始まる季節コンテンツの言語別準備状況を一覧化して」「秋シーズン用に必要な多言語ドラフト一覧を作って」といった指示が可能になる。次のプロンプトはその例だ。

コピペ可能プロンプト3:季節ロールオーバーの計画立案

calendar/seasonal-events.yaml と content/seasonal/ 配下の現状を読み、
今日の日付から60日後までに必要な季節コンテンツの言語別準備状況を
"season-readiness.md" として出力してください。

含める項目:
1. 季節と該当月
2. hero_topics ごとに、5言語版の現在のステータス
   (✅ 公開済 / 🟡 ドラフトあり / ❌ 未着手)
3. publish_window と現在日からの逆算で、各言語の着手期限を計算
4. 既存の翻訳済記事のうち、glossary_version が古いものを抽出して再翻訳候補にする
5. 写真・動画アセットの不足分を photo_assets_dir からの差分で抽出
6. 担当者割当の提案テンプレ(英語担当 / 中文担当 / 韓国語担当 / タイ語担当)

最後に、優先度の高いタスクトップ10を実行可能な単位で並べた "next-actions.md" を生成してください。

これで、季節更新が「気づいたらSNSだけ済んでいてWebは去年のまま」という属人的な事故が、構造的に減らせる。

SNS媒体別の表現テーブルを設計する

観光協会のSNS発信は、媒体ごとに「ふさわしい表現」がまるで違う。これを暗黙知のままにしておくと、誰が運用しても同じトーンを出せず、引き継ぎコストが膨らむ。social/channels.yaml を以下のように整理する。

# social/channels.yaml
channels:
  instagram:
    primary_lang: [en, zh-Hant, ko, th]
    tone: "短く・感情・写真主体"
    max_chars: 2200
    hashtag_rules:
      - "ハッシュタグは英語+各言語の現地語を3〜5個まで"
      - "地域固有のハッシュタグは glossary id を元に統一"
    forbidden_phrases:
      - "amazing!! / stunning!!! などの感嘆符連発"
      - "誇張的な最上級表現の連発"

  facebook:
    primary_lang: [en, zh-Hans]
    tone: "中立・在住家族層向け・実用情報"
    max_chars: 63206
    style_notes:
      - "営業時間・アクセス・駐車場情報を必ず含める"
      - "現地在住の中国系コミュニティに届く言い回しを優先"

  x_twitter:
    primary_lang: [en, ko, th]
    tone: "短く・速報・リアルタイム"
    max_chars: 280
    style_notes:
      - "イベントのリアルタイム告知に強い"
      - "天候・運行情報・道路情報の発信に向く"

  weibo:
    primary_lang: [zh-Hans]
    tone: "現地中国本土向け・正規ハッシュタグ重視"
    max_chars: 2000
    style_notes:
      - "観光ビザ・決済手段(Alipay/WeChat Pay対応有無)を明記"

  line_official:
    primary_lang: [ja, zh-Hant, ko, th]
    tone: "登録済みファン向け・実用情報・クーポン"
    style_notes:
      - "リッチメニューと連動した季節キャンペーンに使う"

コピペ可能プロンプト4:1ネタから媒体別投稿一括生成

下記の日本語の元ネタを、social/channels.yaml と
glossary/tourism-glossary.yaml と
calendar/seasonal-events.yaml を参照して、
媒体別・言語別のSNS投稿ドラフトに展開してください。

元ネタ(日本語):
"""
12月10日から始まる雪灯ろう祭りは、地元の中学生と高齢者ボランティアが
2週間かけて手作りした300基の雪灯ろうが夜の参道を照らします。
点灯時間は17:00〜21:00、最終日は花火と地元郷土芸能の披露があります。
"""

要件:
1. 各媒体の primary_lang に従って言語別ドラフトを生成
2. ハッシュタグ・表記ルール・禁止句を遵守
3. 文化的補足(撮影禁止区域、ボランティアへの配慮、宗教的意味の有無)が必要な箇所はメモを残す
4. 写真・動画ディレクションの提案を1〜2行付ける
5. 出力は "social/drafts/{channel}-{lang}-{yyyymmdd}.md" のファイル群として生成
6. 各ドラフトのフロントマターに needs_native_review: true を必ず付ける

このプロンプト一発で、Instagram英語・Facebook簡体字・X韓国語・Weibo簡体字・LINE台湾繁体字…といった媒体×言語のマトリクスが、ドラフトとして揃う。あとはネイティブ担当者と広報担当が git diff で1個ずつ承認していく。

コピペ可能プロンプト5:問い合わせ対応の下書き生成

観光協会の問い合わせは、メール・SNS DM・電話書き起こし・観光案内所の口頭メモなど多様な経路で来る。これも構造化しておくと、Claude Codeで一次返信のドラフト化ができる。

inquiry/log.csv の最新10件の問い合わせを読み、
それぞれについて以下を生成してください。

1. 問い合わせの本質的な質問を1文で要約
2. 関連する glossary 項目を抽出(地名・施設名・料理名 など)
3. 一次返信ドラフトを問い合わせ言語と同じ言語で生成
4. 同時に日本語要約版を生成(事務局内共有用)
5. 公的機関の確認が必要な案件(医療・宗教施設・災害・運行情報)は
   "needs_official_check: true" としてフラグを立て、回答はテンプレに留める
6. 同種の問い合わせが過去3ヶ月で3件以上ある場合は、FAQ追加候補として提案
7. 出力は "inquiry/templates/draft-{inquiry_id}.md" に保存

返信トーン原則:
- 中立・丁寧・1次情報リンク優先
- 営業的勧誘を入れない
- 災害・医療・宗教関連は確定情報のみ
- 必ず "本回答は観光協会事務局による最終確認後に送付してください" の注記を付ける

これにより「観光案内所の電話メモが、SNS DMの返信に再利用されない」「同じ質問にスタッフごとに違う返答が出る」問題が、ナレッジ化されて消えていく。

5言語マトリクス:言語×媒体×季節の整理

ここまでの設計を整理すると、観光協会・DMOの多言語インバウンド対応は、次のような3次元のマトリクスとして捉えられる。Claude Codeはこの3次元の任意の断面を生成できる仕組みになる。

言語	主要客層	Web	Instagram	Facebook	X	Weibo/小紅書	LINE	季節最重要
en(英語)	北米・豪州・欧州	◎中立・詳細	○写真主体	○家族層	○速報	—	—	春・秋・冬
zh-Hans(簡体)	中国本土	○ビザ・決済	—	○在住家族	—	◎正規SNS	—	春・秋・冬
zh-Hant(繁体)	台湾・香港	◎詳細	◎エモい写真	○	○	—	◎ファン化	四季
ko(韓国)	韓国	○実用	◎短文・写真	○	◎速報・連休前	—	◎ファン化	冬・連休
th(タイ)	タイ	○雪体験案内	○写真	○家族層	○速報	—	◎ファン化	冬・桜・紅葉

このマトリクスを CLAUDE.md もしくは別ファイル matrix.md として置き、Claude Codeに「この断面で何が足りない?」と問い合わせるだけで、抜けが洗い出せる。たとえば「タイ語×Instagram×夏のドラフト一覧」「英語×Web×冬のglossary更新候補」など、3次元の任意の断面を即座にクエリできるようになる。

宿泊施設データ整備:CSV→多言語属性票への変換

多言語インバウンド対応で軽視されがちなのが、宿泊施設データの整備だ。観光協会・DMOが管轄する宿泊施設リスト(lodging/facilities.csv)を、観光客が言語ごとに「Wi-Fiは?」「ハラル対応は?」「電源プラグは?」と探せる属性データに整備する。

# lodging/attributes-schema.yaml
attributes:
  - id: wifi-free
    ja: "客室Wi-Fi無料"
    en: "Free in-room Wi-Fi"
    zh-Hans: "客房免费Wi-Fi"
    zh-Hant: "客房免費Wi-Fi"
    ko: "객실 무료 Wi-Fi"
    th: "Wi-Fi ฟรีในห้องพัก"

  - id: halal-friendly
    ja: "ハラル対応相談可"
    en: "Halal-friendly options on request"
    zh-Hans: "可应要求提供清真餐选项"
    zh-Hant: "可應要求提供清真餐選項"
    ko: "요청 시 할랄 메뉴 제공 가능"
    th: "มีตัวเลือกอาหารฮาลาลตามคำขอ"

  - id: vegetarian-friendly
    ja: "ベジタリアン対応相談可"
    en: "Vegetarian options on request"

  - id: cash-only
    ja: "現金のみ"
    en: "Cash only"

  - id: ip65-shower
    ja: "車椅子対応シャワー"
    en: "Wheelchair-accessible shower"

  - id: bath-tattoo-allowed
    ja: "タトゥー入浴可"
    en: "Tattoos welcome in baths"
    zh-Hant: "可帶刺青入浴"
    ko: "타투 입욕 가능"
    th: "อนุญาตให้คนมีรอยสักลงอ่างน้ำพุร้อนได้"

このスキーマを使い、施設マスタを5言語の属性票に展開するプロンプトは以下のとおり。

lodging/facilities.csv と lodging/attributes-schema.yaml を読み、
各施設について 5言語の属性票HTMLを生成してください。

要件:
1. 出力は lodging/sheets/{facility_id}-{lang}.html
2. 表は属性ID / 属性名(該当言語) / 提供有無 / 補足 の4列
3. ハラル・タトゥー・現金のみ・段差有無など、文化的に重要な属性は先頭に並べる
4. データに記載がない属性は "未確認" として表示し、施設への確認が必要であることを明示
5. 各ファイルのフッターに glossary_version と source_csv_revision を埋め込む
6. 同時に施設ごとの "needs_update.md" を生成し、未確認属性のリストアップ

これで「ハラル対応がどの宿で可能か」「タトゥー入浴可がどこか」を5言語のサイトで均質に出せるようになる。これは多くのDMOで実は最大のボトルネックだった「属性データが日本語版にしかない」状態を構造的に解消するアプローチだ。

【要注意】よくある失敗パターン4つ

❌ 失敗1: 翻訳エンジンの精度比較ばかりに時間を使う

多言語対応プロジェクトで最も多い失敗が、最初の数週間を「DeepLとClaudeとGPTの比較ベンチマーク」に費やしてしまうことだ。実際の運用負荷は翻訳エンジンの差ではなく、辞書・季節・媒体ルールの整備とネイティブレビューの体制で決まる。

⭕ 正解: 翻訳エンジン比較は最大1週間で打ち切り、辞書・カレンダー・媒体ルールの初期整備に2〜3週間を確保する。Claude Codeはどの翻訳エンジンを内部で使うにせよ「下書きを構造化して並べてくれるオーケストレーター」として価値が出る。

❌ 失敗2: ネイティブレビューを「あとで一気に」にする

ドラフトを大量生成しても、レビュー担当(ネイティブ翻訳者・地域住民)が月末に一気にまとめて見る運用にすると、修正が積み上がって公開が止まる。さらに修正したくても「もう古い」状態になっていることが多い。

⭕ 正解: 1日5本までなど、レビュー担当の処理能力に合わせて生成本数の上限を決める。Claude Codeに「今日生成するのは上限5本まで。残りは草案に留める」と毎日伝えるか、scripts/limit.shでキュー制御する。

❌ 失敗3: 固有名詞辞書を「完成してから運用開始」にする

「辞書がまだ100語しかないので運用開始は来月から」と判断すると、運用は永遠に始まらない。辞書は運用しながら太らせるものだ。

⭕ 正解: 最初に30〜50語だけ登録して運用開始。「辞書未登録名詞リスト」をClaude Codeに毎週末出力させ、多言語委員会が週1で追加する。3ヶ月で実用ラインの300〜500語に届く想定で設計する。

❌ 失敗4: 中国語の簡体字・繁体字を「同じ言語」として扱う

これは観光協会・DMOで頻発する。中国語担当者が1人しかおらず、結果として簡体字版を機械変換しただけの繁体字版が公開されてしまう。台湾・香港のユーザーから見ると、語彙選択・言い回しが「中国本土の翻訳をそのまま当てた」と一目で分かり、距離感が生まれる。

⭕ 正解: tourism-glossary.yaml に簡体字・繁体字を別フィールドとして必ず分けて記録する。Claude Codeのプロンプトでも zh-Hans と zh-Hant を別言語として扱い、台湾在住の確認者・香港在住の確認者を別々に確保する。

運用に組み込む:週次・月次・季節別のリズム

ここまでの仕組みを「いつ動かすか」を決めておくと、属人化を防げる。観光協会・DMOの想定運用リズムは次のとおりだ。

頻度	タスク	使うClaude Codeプロンプト
毎日	SNS下書き生成・問い合わせ一次返信ドラフト	プロンプト4 / プロンプト5
週次	未登録固有名詞の抽出・辞書追加候補	プロンプト2 + 委員会レビュー
月次	媒体別投稿ログのレビュー・glossary整合監査	プロンプト2 + 媒体別ダッシュボード生成
季節前(60日前)	季節ロールオーバー計画	プロンプト3
年次	5言語版マトリクス全件のglossary_version更新	プロンプト1 + プロンプト2の全件再走

このリズムを CLAUDE.md の中段に書いておくと、Claude Code側からも「今日は月初なので glossary整合監査を走らせますか?」のような提案が自然に出る形になる。これが「運用に組み込む」ことの実態だ。

セキュリティ・運用上の注意点

• 個人情報の取扱: 問い合わせメール・SNS DMをリポジトリに取り込む場合は、メールアドレス・電話番号・氏名を必ず仮名化したうえで inquiry/log.csv に保存する。Claude Codeに渡す前にスクリプトでマスキングしておく。
• 公開判断は人間: Claude Codeは公開ボタンを押さない設計にする。SNS API・WordPress API への投稿は、ネイティブレビューの承認チェック(YAMLフロントマターの needs_native_review: false)が立っていることをスクリプトで確認した上で実行する。
• 災害・医療・宗教情報: 一次情報リンクなしで断定する文を生成させない。CLAUDE.md に「断定不可カテゴリ」を明記する。
• 翻訳の最終責任: AIによるドラフトはあくまで草案。観光客が誤解した場合の責任主体は観光協会・DMOであることを、運用ルールとして明文化しておく。
• 監査ログ: Claude Codeのセッションログ・git履歴・SNS投稿履歴の3つを統合保管。多言語委員会の月次レビューで参照できる形にしておく。

導入コストと体制の現実的な目安(想定値)

本記事は特定観光協会の実績ではなく想定例だが、Claude Code導入を検討する観光協会・DMOにとってのオーダー感を以下に示す。実数値は地域規模・既存資産・対応言語数で大きく変動する。

フェーズ	期間目安	主要タスク
0. 現状棚卸し	2週間	既存翻訳資産・辞書候補・SNSアカウントの一覧化
1. リポジトリ初期化	2週間	CLAUDE.md・glossary・calendar・channels の初期版作成
2. ネイティブレビュー体制構築	3〜4週間	5言語のレビュー担当を確保(在住者・外部翻訳者ミックス)
3. パイロット(1テーマ・5言語)	4週間	1つのhero_topicで5言語版を回し切る
4. 全カテゴリ展開	3〜6ヶ月	季節別・媒体別に順次拡張
5. 運用安定化	継続	週次・月次・季節別リズムに乗せる

Claude Codeのツール費用そのものは小さいが、勝敗を分けるのは多言語委員会の体制と固有名詞辞書の運用の2点だ。技術導入よりも先に、この2つの体制設計を必ず終わらせること。

言語別の文体ガイドを「人格化」して定義する

多言語ドラフト生成の品質を決める隠れた要因が、glossary/style-guide-{lang}.md をどこまで具体的に書けるかだ。多くの観光協会では「英語は丁寧に」「韓国語は親しみやすく」程度の抽象指示しか持っていない。これだとClaude Codeが生成するトーンが毎回ぶれる。文体ガイドは「ペルソナ化された読者像と、好まれる表現・嫌われる表現の具体例集」として書くと、生成品質が桁違いに安定する。

例として、英語版の文体ガイドを次のように整備する(想定例)。

# glossary/style-guide-en.md

## Reader persona
- Primary: 35–55 years old, North American or Australian, repeat visitor to Japan,
  travels with spouse, plans 2–3 nights in regional Japan after Tokyo/Kyoto.
- Secondary: 25–35 years old, European, solo or couple, interested in
  off-the-beaten-path culture, sensitive to over-tourism.

## Tone
- Neutral, descriptive, respectful of local culture.
- Avoid superlative inflation ("amazing", "stunning", "must-see" not more than once
  per article, and never in the lead).
- Show, don't sell. Describe the experience instead of evaluating it.

## Preferred phrases
- "is known locally as ..."
- "you may notice that ..."
- "as is customary in the region, ..."

## Avoid
- "Best-kept secret" / "hidden gem" / "you must visit"
- "World-famous" unless verified by an official source
- Emoji in body copy (acceptable in social posts only)

## Cultural cautions
- For religious sites, mention etiquette explicitly (footwear, photography, dress).
- For onsen, mention tattoo policy if it differs from the regional norm.
- For festivals, describe volunteer roles to discourage interfering with operations.

## Length
- Web article body: 600–1,000 words for an attraction page; 1,400–2,000 for itinerary.
- Social caption: under 150 words for Instagram, under 60 for X.

## Local naming convention
- First mention: "Kanade Shrine (奏神社)" with both English and original.
- Subsequent mentions: "Kanade Shrine" only.
- Romaji uses Hepburn with macrons stripped (Tōkyō → Tokyo).

韓国語・タイ語・中国語の文体ガイドも同様の粒度で書くと、Claude Codeが生成する各言語ドラフトの「キャラクターのブレ」が一気に減る。観光協会の現場で意外と効くのは、「嫌われる表現」の具体例をリストアップしておくことだ。生成AIは肯定的指示より否定的指示のほうが拾いやすい傾向がある。

差分翻訳のワークフロー:日本語原稿を1パラグラフ直したとき、5言語版をどう追従させるか

多言語運用の中でもっとも頻発するのが、「日本語原稿を1パラグラフだけ修正したが、5言語版に反映するのを忘れていた」事故だ。これも仕組みで防ぐ。

各言語版ファイルのフロントマターに、原文のリビジョンハッシュを持たせておく。

---
slug: kanade-shrine
lang: en
source_revision: "ja@a8b2c9d"
glossary_version: "2026-05"
needs_native_review: false
last_native_review_at: "2026-04-22"
last_native_reviewer: "Reviewer A (anonymized)"
---

そして次のような差分追従プロンプトをClaude Codeに渡す。

content/attractions/ 配下を走査し、
各記事の言語別ファイルの source_revision と
最新のjaファイルのgit hashを比較してください。

更新が必要なファイルを次の3カテゴリに分類:

A. minor: 原文の数値・営業時間・電話番号のみ変更
   → 該当箇所のみ差し替えるパッチを生成
B. moderate: 原文の段落構成は変わらないが文言が更新
   → 該当パラグラフのみ再翻訳ドラフトを生成、要レビュー
C. major: 原文の構成が変わった
   → 全文再翻訳ドラフトを生成、要ネイティブレビュー再依頼

出力:
- "delta-report.md" にカテゴリ別の対象ファイル一覧
- A は scripts/apply-minor-patch.sh の入力JSON として書き出し
- B/C は branch を切って drafts/{slug}-{lang}-rev{n}.md として保存
- 全件について needs_native_review: true をフロントマターに付け直す

この仕組みがあれば、「日本語版の電話番号を直した瞬間に、5言語版の電話番号差し替えPRが自動で立つ」という状態にできる。観光協会の事務局スタッフは、PRを承認するだけで5言語に追従反映できる。これは年間にすると相当な手作業を消す。

パンフレット・印刷物との連動:InDesign流し込み素材としての多言語MD

観光協会・DMOはWeb・SNSだけでなく、紙のパンフレット・観光マップ・案内板も多言語で出している。多くの場合、印刷物は外部デザイン事務所への発注になるが、原稿テキストの生成・更新もClaude Codeで一元化できる。

リポジトリ側に content/print/ ディレクトリを切り、印刷物用の素材MDを置く。

content/print/
├── pamphlet-2027-spring/
│   ├── source.md           # 入稿用原稿(各言語の見出し・本文を1ファイルに)
│   ├── caption-list.csv    # 写真キャプション一覧(差し込み用)
│   └── proof-checklist.md  # 校正チェックリスト
└── map-2027/
    ├── icon-labels.yaml    # アイコン凡例(5言語)
    └── route-descriptions/

Claude Codeへの指示は次のとおり。

content/print/pamphlet-2027-spring/source.md を、
InDesignへの流し込み用に整形してください。

要件:
1. 各セクションのタグを {{section:title}} {{section:body}} {{section:caption}}
   のように統一して、InDesignのスクリプトで差し込めるようにする
2. 言語ごとにファイル分割 (ja.txt / en.txt / zh-Hans.txt / zh-Hant.txt / ko.txt / th.txt)
3. 全言語で同一の項目構造を保ち、欠けがあれば末尾に "MISSING:" として明示
4. 各言語の文字数を集計し、レイアウト枠に収まるかの見積を proof-checklist.md に追記
5. 写真キャプションは caption-list.csv の photo_id と紐づけて生成
6. 校正者(印刷物の最終確認担当)向けに、過去の校正履歴と今回の変更点を summary.md にまとめる

これでWeb版と印刷版の翻訳が同じ tourism-glossary.yaml を参照するようになり、「Webでは『奏神社』、パンフレットでは『Kanade-jinja Shrine』(冗長表記)」のような恥ずかしい不整合が消える。

観光案内所の対面対応への展開:口頭対応スクリプトと多言語FAQ印刷

観光案内所スタッフがインバウンド客に対面対応する場面でも、Claude Code由来のリポジトリが効く。よくある質問への口頭対応スクリプトを多言語化して、案内所のカウンターに置いておく形だ。

inquiry/templates/ 配下の頻出FAQ上位20件を抽出し、
観光案内所スタッフ向けの「指差し対応シート」を多言語で生成してください。

要件:
1. 1ページに1FAQ。日本語の質問、各言語のスタッフ向けひらがな読み、
   観光客に見せる現地語回答、補足アクションの4要素を含める
2. レイアウトはA4横、印刷想定
3. 災害・医療・宗教関連の質問は赤い注意マークを付け、必ず事務局確認に回すフローを明示
4. 言語別に5色のタブで色分け
5. 各シートのフッターに glossary_version とリビジョン日付
6. 同時に、案内所スタッフ向けの「3秒で開ける紙の目次」も生成

「Wi-Fiはどこで使えますか?」「ハラル対応の店はありますか?」「最寄り駅までのバスは?」のような頻出FAQが、5言語の指差しシートになって案内所カウンターに置かれている状態。これがあると、現場スタッフが「英語ができるスタッフが今いないので…」と詫びる必要がなくなり、観光客側のストレスも減る。

ガバナンスと著作権:生成AIで作った翻訳・写真説明文の扱い

多言語コンテンツをAIで大量生成する以上、ガバナンスを最初に決めておかないとあとで揉める。観光協会・DMOの想定運用では、最低限次の項目をリポジトリの GOVERNANCE.md として整備する。

• AI生成の明示: WebサイトのフッターやページごとのメタデータにAIアシスト生成である旨と最終ネイティブ確認日を表示する。媒体によっては不要だが、内部監査用にデータを残す。
• レビューの責任者: 各言語の最終承認者を明確化(例: 英語=多言語委員会のA氏、簡体字=委員会のB氏など)。承認ログはgit commit message に Reviewed-by: ... で残す。
• 著作権リスク: AI出力が他媒体の翻訳と類似していないか、リリース前にスポットチェック(同義語多すぎる場合は再生成)。
• 個人情報: 問い合わせデータをAIに渡す前に必ず匿名化スクリプトを通す。
• 事故時の手順: 誤訳・差別的表現が公開された場合、24時間以内にWebは差し替え、SNSは削除と訂正告知を出す手順を明文化。

これらは大袈裟に見えるかもしれないが、観光協会・DMOは公的セクターの一部として見られているため、誤訳1件が地域の信用問題になりやすい。最初にガバナンスを決めておく工数は、事故対応の数十分の一だ。

KPI設計:多言語運用の成果をどう測るか

多言語インバウンド運用の効果は、観光客数のような大きすぎる指標ではなく、運用そのものに直結する中間指標で測ると改善が回しやすい。Claude Code導入時に並走で設計しておくKPIの例(想定値)。

指標	計測方法	初期目安	1年後の目標感
多言語版公開遅延日数	日本語版公開日と各言語版公開日の差	30〜60日	3〜7日
glossary登録語数	tourism-glossary.yaml の語数	30〜50	300〜500
glossary整合違反件数	監査スクリプトの検出件数	初回100以上	10未満/月
季節更新の前倒し成功率	publish_window前に公開できた割合	30%	80%以上
SNS媒体別言語カバレッジ	媒体×言語マトリクスの埋まり率	30%	80%以上
問い合わせ一次返信時間	受信から下書きまでの時間	24時間以上	同日中
ネイティブレビュー処理本数	週次レビュー処理本数	5〜10	20〜30

「観光客数を増やす」「インバウンド消費額を伸ばす」のような外部成果指標は地政学・為替・コロナ・自然災害など多変数すぎてAI導入の寄与が見えづらい。一方で「多言語版公開の遅延」「辞書整合違反」「季節更新の前倒し率」のような運用品質指標は、Claude Code導入と直接因果がある。最初の1年はこの中間指標で投資対効果を語るのが現実的だ。

関連する他業界の参考事例

観光協会・DMOの多言語対応は、宿泊・自治体・飲食の業務効率化と地続きだ。以下の事例も合わせて読むと、似た構造の問題への解像度が上がる。

• 宿泊施設の口コミ返信業務をClaude Codeで効率化する — 多言語口コミへの返信トーンを統一しつつ、人力レビューを残す設計の参考になる。
• 自治体・基礎自治体でのClaude Code活用事例5選 — 観光課が所属する自治体組織全体での導入アプローチ。
• 飲食店の需要予測とシフト計画をClaude Codeで設計する — インバウンド観光と連動した飲食側の運用最適化。

地域連携:複数自治体・複数DMOで辞書を共有する設計

観光協会・DMO・自治体観光課のもう一つの隠れた課題が、隣接する自治体・DMOとの連携だ。広域観光ルートを組むと、隣の市町村が違う英語表記を使っていて統一感がない、という事態が頻発する。Claude Codeで作るリポジトリ運用は、この広域連携にも自然に拡張できる。

想定する構成は次のとおり。広域DMOが「親リポジトリ」として共通の固有名詞辞書を持ち、各市町村観光協会が「子リポジトリ」としてサブモジュールでそれを参照する。広域DMO側で語が登録されると、各市町村側のClaude Codeが自動でその訳語を採用するようになる。

regional-dmo-glossary/             # 親リポジトリ(広域DMOが管理)
├── glossary/
│   ├── regional-places.yaml       # 広域共通の地名・ルート名
│   ├── regional-cuisine.yaml      # 広域共通の郷土料理
│   └── regional-festivals.yaml    # 広域共通の伝統行事
├── style-guides/
└── governance/
    └── COMMITTEE.md               # 各市町村の代表者一覧と承認手順

tourism-yamaba-town/               # 子リポジトリ(山場町観光協会)
├── CLAUDE.md
├── external/
│   └── regional-glossary -> (submodule: regional-dmo-glossary/glossary/)
├── glossary/
│   └── local-only-glossary.yaml   # 山場町固有の名詞のみ
└── content/

子リポジトリの CLAUDE.md には次のように書く。

## 辞書参照の優先順位
1. external/regional-glossary/ (広域DMO共通辞書) — 最優先
2. glossary/local-only-glossary.yaml — 広域辞書に無い山場町固有名詞

## 新規固有名詞の追加
- 隣接自治体でも使う名詞 → 広域DMOに追加申請のPRを起こす
- 山場町でのみ使う名詞 → local-only-glossary.yaml に直接追加
- 判別がつかない場合は事務局で議論し、迷ったら広域側に申請

これで「広域の幹線ルート名は全自治体で統一、地区限定の祭り名は各自治体で管理」という階層が技術的に実現できる。広域DMOの月次会議では、Claude Codeに「今月、各子リポジトリから上がってきた広域辞書追加候補をまとめて」と頼むだけで、議題が自動で揃う。

ハンズオン:1人観光協会(極小規模)の最小構成

すべての観光協会が十分な人員・予算を持っているわけではない。事務局2〜3名、多言語専任者なし、SNSは外部委託、印刷物は年1回、という極小規模の観光協会も多数ある。そのような組織でClaude Codeを導入するときは、フル構成ではなくミニマム構成から始めるべきだ。

ミニマム構成のリポジトリは以下のとおり。フル構成の tourism-dmo-multilingual/ から、最初の3ヶ月で本当に必要なものだけに絞っている。

tourism-mini/
├── CLAUDE.md
├── glossary/
│   └── tourism-glossary.yaml      # 30〜50語からスタート
├── content/
│   └── top-10-attractions/        # 最重要観光スポット10件のみ多言語化
├── faq/
│   └── top-20-questions.yaml      # 最頻出20質問のみ5言語化
└── social/
    └── monthly-calendar.md        # 月間SNS発信予定(言語別)

このミニマム構成でも、3ヶ月後には「トップ10観光スポット×5言語=50ページの整備された多言語コンテンツ」と「頻出20質問の5言語FAQ」が手に入る。フル構成は1年かけて段階的に拡張していけばよい。重要なのは「いきなり完璧な仕組みを作る」のではなく「最小単位で運用を始める」ことだ。

1人観光協会でClaude Codeを回す場合のリズム例は次のとおり。

曜日	所要時間	タスク
月曜朝	30分	先週の問い合わせを inquiry/log.csv に追記 → 一次返信ドラフト生成
水曜午後	1時間	今週のSNS下書き5言語×2媒体を生成 → 外部委託先に送付
金曜午後	30分	未登録固有名詞リスト確認 → 1〜3語追加
月初	1時間	来月の季節コンテンツ計画(season-readiness.md)を出力
季節前	2時間	季節ロールオーバー(プロンプト3)を実行 → 外部翻訳者にレビュー依頼

合計で週3〜4時間。これだけで5言語×複数媒体の最低運用が回せるようになる。属人化していた「英語ができるスタッフが急に休んだら止まる」状態よりも、はるかに健全だ。

外部翻訳会社・地域コミュニティとの役割分担

Claude Codeを導入すると、しばしば「翻訳会社・通訳ボランティアは不要になりますか?」と聞かれる。答えは明確にNoだ。むしろ役割が変わり、外部翻訳者・地域コミュニティの「最終確認・文化的検品」の価値が相対的に上がる。

• 外部翻訳会社: ドラフト生成からは解放され、ネイティブレビュー・公的文書翻訳・センシティブな案件(医療・宗教・災害)に集中。発注単価は維持、対応本数を増やすか、案件の深さを増やす方向に振る。
• 地域在住の外国人コミュニティ: 月次レビュワー・SNS文化チェック・FAQ更新の協働者として位置付ける。Claude Codeが作るドラフトに対し「この表現は現地ではこう感じる」というインサイトをコメントする形で参加。
• 留学生・大学観光学科: 季節イベント前のSNS下書きレビュー、Glossary候補語のキュレーションをインターンとして担当。
• JICA・大使館等の公的機関: 災害・医療など公的情報の最終確認・連携。

この役割分担を「観光協会 × Claude Code × 外部翻訳者 × 地域コミュニティ」の4者で運用ルール化したものを、GOVERNANCE.md に書き残しておく。これがあるかないかで、3年後の運用継続性が大きく変わる。

導入チェックリスト:着手前に整理しておく10項目

Claude Codeで多言語インバウンド運用を始める前に、観光協会・DMO・自治体観光課の事務局で必ず確認しておきたい10項目をまとめる。これが揃っていないと、技術導入だけ走って運用が破綻するパターンになりやすい。

1. 対応言語の優先順位を3言語以内に絞る — いきなり5言語フル展開は現実的でない。来訪国別の統計をもとに、まず2〜3言語に集中し、3ヶ月後に4言語目を追加する形が安全。
2. ネイティブレビュー担当を言語ごとに少なくとも1名確保 — 確保できない言語は運用開始しない。これは絶対条件として扱う。
3. 固有名詞の初期リストを30〜50語 — 最重要観光スポット・最重要祭り・最重要郷土料理から優先。地域住民の感覚を必ず入れる。
4. Gitリポジトリのホスティング先と権限管理 — GitHub Private・GitLab Self-hosted・Bitbucketなどから選択。事務局スタッフ全員にアカウントを付与し、最低限の操作研修を行う。
5. 個人情報の取り扱いポリシー — 問い合わせデータの匿名化スクリプト、保持期間、削除手順を整備。地域の個人情報保護条例とも整合させる。
6. SNSアカウントの認証情報管理 — Claude Code自身が直接SNSに投稿することはせず、担当者が承認後に投稿する設計を徹底。アクセストークンは .env 等にしまい、リポジトリにコミットしない。
7. 季節カレンダーの初期データ — 過去3年分の主要イベント・開催期間・告知タイミングを calendar/seasonal-events.yaml に流し込む。
8. 媒体ルールの言語化 — 「Instagramはこういう感じ」「Facebookはこういう感じ」が経験で分かっているなら、それを social/channels.yaml に文章化する。
9. 事故時の対応手順 — 誤訳・差別的表現・センシティブな歴史表記が公開された場合の差し替え手順を3行で書く。
10. 3ヶ月後の振り返り会 — 多言語委員会・外部翻訳者・地域コミュニティで定期的に振り返る場を、最初からカレンダー登録しておく。

このチェックリストは、研修・伴走支援の現場でも実際に使えるテンプレートとして配布できる。観光協会・DMOの理事会や運営委員会で承認を取るための資料としても、そのまま流用可能だ。

よくある質問(FAQ)

Q1: 翻訳をAIに任せて、観光客から「機械翻訳ですね」と指摘されたら信用を失いませんか?

A: ご懸念はもっともですが、本記事の設計は「AI翻訳を公開する」ものではなく「AIがドラフトを作り、ネイティブが最終確認したものを公開する」ものです。最終公開物は必ずネイティブレビューを通すため、機械翻訳特有の不自然さは出ない設計です。一方で、SNSの即時告知などレビューが間に合わない領域では、媒体上で「AIアシスト生成・現地在住者監修」のような注記を入れ、訂正があれば即座に対応するポリシーを取るのが現実的です。

Q2: Claude Codeはオフラインで動きますか? 観光案内所のPCがインターネットに繋がっていない場合は?

A: Claude Code本体はクラウドAPI経由で動作するためインターネット接続が必要です。一方で、本記事で示したリポジトリ(glossary・content・FAQ等)は単なるテキストファイルなので、観光案内所側にgit cloneしておけば、参照だけならオフラインで可能です。指差し対応シートのようにPDF化して印刷する運用も併用すると、インターネット障害時にも対応できます。

Q3: 中国本土からはGoogle/Twitter/Instagramがアクセスしにくいですが、多言語SNS発信は意味がありますか?

A: 中国本土向けはWeibo・小紅書(Xiaohongshu)・WeChat公式アカウントが主要チャンネルです。本記事の social/channels.yaml でWeiboは独立媒体として定義しており、本土向け中国語簡体字発信はそちらに集中させる設計です。Instagram中国語版は主に台湾・香港・北米在住の中華系コミュニティ向けという棲み分けを明示しておくと、運用が混乱しません。

Q4: 個人情報保護法(改正版)との関係で、観光客の問い合わせメールをAIに渡しても大丈夫ですか?

A: 観光客の氏名・メールアドレス・電話番号などの個人情報は、AIに渡す前にスクリプトで仮名化(置換)するのが推奨です。本記事の設計でも inquiry/log.csv に取り込む段階で匿名化を行う前提です。さらに、AIベンダーのデータ利用ポリシーを確認し、エンタープライズプランなど学習に使われない契約形態を選ぶこと、利用規約・プライバシーポリシーを観光協会のWebに明示することも併せて整備します。

Q5: 翻訳の品質を社内でどう評価しますか? ネイティブがいない場合は?

A: 完全に社内評価のみで品質保証することはおすすめしません。少なくとも各言語に1名以上、地域在住の外国人住民・留学生・外部翻訳者など、何らかの形でネイティブの目を入れる体制を整備してから運用開始してください。どうしても確保が難しい場合は、JNTOや観光庁、近隣の広域DMO、JICAなどの公的支援窓口を介して紹介を受けるルートがあります。

Q6: 既存のWebサイト(WordPress)との接続はどうしますか?

A: 多くの観光協会WebサイトはWordPressのWPMLやPolylangで多言語化されています。Claude Codeリポジトリ側で生成したマークダウンを、WP REST APIで投稿する仕組みを scripts/publish-to-wp.sh として組むのが標準パターンです。フロントマターの needs_native_review: false をスクリプトで確認し、承認済みのもののみ自動投稿する、というガードを必ず入れてください。

Q7: 補助金・助成金の対象になりますか?

A: 観光協会・DMOの多言語対応は、観光庁・経済産業省・地方創生関連の各種補助金の対象になる年度があります。ただし制度は年度ごとに変動するため、最新の公募要領を直接確認してください。本記事は補助金申請を保証するものではなく、技術設計の参考としてご活用ください。

Q8: スタッフがITに不慣れな場合、git・コマンドラインの学習負荷は?

A: 事務局スタッフ全員にコマンドライン操作を習得させる必要はありません。実運用では「リポジトリへのファイル追加・差分確認・承認」の3操作だけGUI(GitHub Desktop等)で行い、Claude Code実行は技術担当1名または外部伴走パートナーが担うのが現実的です。3操作だけなら半日研修で十分習得できます。事務局全員がエンジニアになる必要はなく、役割分担で十分機能します。

Q9: 1記事の更新がリポジトリ全体のリビルドを引き起こしませんか?

A: 本記事の設計はファイルベースなので、1記事の更新は該当ファイルとその5言語版のみに影響します。WordPress側の公開はファイル単位の REST API 投稿で行うため、サイト全体の再ビルドは不要です。静的サイトジェネレータを使う場合でも、増分ビルドに対応していれば数十秒で完了します。

まとめ:多言語インバウンド運用を「個人技」から「リポジトリ運用」へ

観光協会・DMO・自治体観光課の多言語インバウンド対応は、長年「優秀な多言語担当者個人の頑張り」に支えられてきた。だが担当者が異動・退職した瞬間に、辞書も季節カレンダーも媒体ルールもすべて消える。これが地域観光のもっとも構造的な脆弱性だ。

Claude Codeで取るべきアプローチは、翻訳を高速化することではなく、これまで属人化していた「辞書」「季節」「媒体ルール」「問い合わせナレッジ」「宿泊属性データ」を、すべて git管理可能なリポジトリ に外出ししたうえで、Claude Codeをそれらを横断するオーケストレーターとして使うことだ。最終公開可否は必ず人間のネイティブ確認を通す、というガードレールを最初から設計する。

本記事のテンプレートはすべてサンプル想定だが、リポジトリ構成・CLAUDE.md・5本のプロンプトはそのまま地域案件に転用できる。地域の多言語委員会・DMOディレクター・自治体観光課の3者で読み合わせ、自分たちの地域固有名詞・季節差分・SNS事情に合わせてカスタマイズすることを推奨する。

著者プロフィール

佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人以上。100社以上の企業向けAI研修・導入支援に従事し、地方自治体・観光協会・DMOのインバウンド業務改善にも研修・伴走の立場で関わる。著書『AIエージェント仕事術』(SBクリエイティブ)、SoftBank ビジネス+IT連載執筆。

CTA:次にやってほしい3アクション

1. 固有名詞30語の棚卸し — 自地域の地名・寺社・祭り・郷土料理・自然名所のうち、英訳が記事ごとに揺れている語を30個リストアップしてください。それが tourism-glossary.yaml の初期版になります。
2. 媒体×言語マトリクスの自己診断 — 本記事中の5言語×6媒体マトリクスを自地域に当てはめ、◎○—の3段階で現状を埋めてください。空欄が一目で見えれば、次に何を始めるかが決まります。
3. ネイティブレビュー体制の確保 — 翻訳ドラフトを最終確認できる5言語のレビュー担当者を、内部・外部のミックスで確保してください。Claude Code導入よりこちらが先です。

株式会社Uravationでは、観光協会・DMO・自治体観光課向けに、Claude Code導入を含むインバウンド多言語運用の設計・伴走支援を行っています。地域の多言語委員会立ち上げから、リポジトリ構成・辞書設計・ネイティブレビュー体制構築まで、3〜6ヶ月の伴走プロジェクトとして相談可能です。詳細はお問い合わせフォームより。

参考出典

• 観光庁「訪日外国人旅行者の受入環境整備に関する取組」(https://www.mlit.go.jp/kankocho/) — 多言語対応・案内表示・Wi-Fi等の受入環境整備の公的指針。
• 日本政府観光局(JNTO)「インバウンド・データ&トレンド」(https://www.jnto.go.jp/) — 国別来日動向・主要客層の最新統計。
• Anthropic公式「Claude Code documentation」(https://docs.anthropic.com/) — Claude Codeの仕様・CLAUDE.md運用パターンの一次情報。
• 観光庁「DMO形成・確立計画」(https://www.mlit.go.jp/kankocho/) — DMOの役割定義と多言語対応位置付け。

関連記事（自動）

• ▸ ホテル料金最適化をClaude Codeで｜OCC/ADR/RevPAR分析
• ▸ ホテルの口コミ返信をClaude Codeで整理｜多言語レビューと改善レポート