Media > AI活用ユースケース > マーケティング > 訪日客向けの館内案内とメニューを多言語にして、原文の更新に訳を追随させる

訪日客向けの館内案内とメニューを多言語にして、原文の更新に訳を追随させる

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

館内の案内やメニュー、注意書きの日本語の原文を台帳で持ち、英語・中国語・韓国語の訳を作ります。原文を直すと、その行に対応する訳へ自動で「要更新」が立ち、古い訳が掲示に残らなくなります。

サマリー
利用ツール
ChatGPT/Claude/Gemini/Google Apps Script/Make/n8n/Python/Zapier
対象業界
医療/宿泊/小売/教育/飲食
対象部門
マーケティング/総務
対象業務
台帳・マスタ管理/書類作成
主な課題
人手が足りない/問い合わせが多い/属人化している
AIで行う処理
翻訳
主な効果
品質標準化/対応スピード向上/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
24h/月
AI導入後
8h/月
想定削減
67%
年間削減
192h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 料金改定や仕入れの変更を受けて、日本語の掲示物の原稿を直す
  2. 前に作ったPDFを開き、どこを変えたかを目で見比べる
  3. 変えた箇所を機械翻訳にかけ、4言語ぶんの下訳を作る
  4. 下訳を読み、固有名詞や施設名の訳がおかしいところを手で直す
  5. 過去の掲示物のPDFを開き、同じ語がどう訳されていたかを探して合わせる
  6. デザインソフトに流し込み、枠からはみ出した言語だけ文字を詰める
  7. 印刷して差し替え、差し替えた日を担当者の手元のメモに残す
導入後(After)
  1. 原文台帳のスプレッドシートを開き、日本語の原文を直す(1行につき1文)
  2. 自動5分ごとに動く処理が、原文の正規化とハッシュ化を行い、前の版と突き合わせる
  3. 自動変わった行を見つけ、その行を参照している各言語の訳に `stale`(要更新) を立てる
  4. 自動掲示物の種類から対象言語と確認の厚みを決め、用語集の語と訳語を取り出す
  5. 自動用語集と前の版の訳を渡し、4言語ぶんの訳を作る
  6. 自動各言語の訳を、原文を見せずに日本語へ訳し戻す
  7. 自動数値・時刻・金額・アレルギー品目・用語集の当たり・文字数比を機械で点検する
  8. 自動通ったものを `review`(確認待ち)、外れたものを理由付きで一覧に出す
  9. アレルギー表示・原材料表示・料金・緊急時の案内は、担当者と別の1名で確認する
  10. それ以外の一般的な案内は、担当者1名が確認して `ready`(掲示可)にする
  11. 掲示物を制作して差し替え、台帳に掲示日を入れる
各工程の詳しい説明を読む
  1. 料金改定や仕入れの変更を受けて、日本語の掲示物の原稿を直す
  2. 前に作ったPDFを開き、どこを変えたかを目で見比べる
  3. 変えた箇所を機械翻訳にかけ、4言語ぶんの下訳を作る
  4. 下訳を読み、固有名詞や施設名の訳がおかしいところを手で直す
  5. 過去の掲示物のPDFを開き、同じ語がどう訳されていたかを探して合わせる
  6. デザインソフトに流し込み、枠からはみ出した言語だけ文字を詰める
  7. 印刷して差し替え、差し替えた日を担当者の手元のメモに残す

(a)どの掲示物を直したかが残らない。 差し替えの記録は担当者のメモで、共有された台帳がありません。 日本語だけ直して多言語版を忘れても、忘れたこと自体が残りません。気づくのは、訪日客に「表示と料金が違う」と言われたときです。

(b)原文がPDFの中にしかない。 掲示物はデザインソフトで作られ、出来上がりはPDFか画像です。テキストとして取り出せる原文がどこにもありません。 だから2番が目視の見比べになり、変えた箇所を正確に拾えません。

(c)同じ語の訳が掲示物ごとに違う。 5番は、過去のPDFを開いて探すことで成り立っています。時間がかかるので、忙しいときは飛ばされます。 その結果、「大浴場」が掲示物によって違う語になり、「貸切風呂」に至っては3通りあります。

(d)4言語ぶんの手直しが単純に重い。 1言語なら10分で終わる確認が、4言語で4倍になります。下訳の質にかかわらず、読んで確かめる時間は言語の数だけ積み上がります。

  1. 【人】 原文台帳のスプレッドシートを開き、日本語の原文を直す(1行につき1文)
  2. 【自動】 5分ごとに動く処理が、原文の正規化とハッシュ化を行い、前の版と突き合わせる
  3. 【自動】 変わった行を見つけ、その行を参照している各言語の訳に stale(要更新) を立てる
  4. 【自動】 掲示物の種類から対象言語と確認の厚みを決め、用語集の語と訳語を取り出す
  5. 【自動】 用語集と前の版の訳を渡し、4言語ぶんの訳を作る
  6. 【自動】 各言語の訳を、原文を見せずに日本語へ訳し戻す
  7. 【自動】 数値・時刻・金額・アレルギー品目・用語集の当たり・文字数比を機械で点検する
  8. 【自動】 通ったものを review(確認待ち)、外れたものを理由付きで一覧に出す
  9. 【人】 アレルギー表示・原材料表示・料金・緊急時の案内は、担当者と別の1名で確認する
  10. 【人】 それ以外の一般的な案内は、担当者1名が確認して ready(掲示可)にする
  11. 【人】 掲示物を制作して差し替え、台帳に掲示日を入れる

3番目が、この設計の中心です。 原文を直した人が多言語版を思い出す必要はありません。直した瞬間に、対応する4言語の訳へ印が立ちます。 担当者が見るのは掲示物の一覧ではなく、stale が立っている行の一覧です。

6番目で原文を見せないのは、意図してのことです。 訳し戻しに原文を渡すと、原文をなぞった日本語が返り、訳が間違っていても点検を通ります。 見せないからこそ、数値や品目の抜けが日本語の側に現れます。

9番目と10番目を分けているのも同じです。 全点を二重に確認すると、削減した時間がそのまま戻ります。誤訳が事故になる種類だけに、2人目の時間を使います。

02今回想定するシステム構成

構成図
原文台帳(スプレッドシート:掲示物ごとに日本語の原文を1行ずつ持つ)
   │
   ▼【トリガー】時間主導型トリガー(5分ごと)
Google Apps Script ── 原文の正規化とハッシュ化、前の版との突合
   │   変わった行を参照している訳に stale(要更新)を立てる
   ▼
Make ── 掲示物の種類から対象言語と確認の厚みを決め、用語集を引く
   ▼
Gemini API ── 用語集の訳語と前の版の訳を渡し、各言語の訳を作る
   │   英語 / 中国語(簡体字) / 中国語(繁体字) / 韓国語
   ▼
Gemini API ── 各言語の訳を、原文を見せずに日本語へ訳し戻す
   ▼
Google Apps Script ── 点検の集計
   │   数値・時刻・金額 / アレルギー品目 / 用語集の当たり / 文字数比
   ▼
訳台帳(stale 要更新 / review 確認待ち / ready 掲示可 / posted 掲示済み)
   ▼
【人の確認】
   ├── アレルギー表示・原材料表示・料金・緊急時の案内 → 2名
   └── 一般的な案内 → 担当者1名
   ▼
掲示物の制作と差し替え
役割想定する製品代替候補
処理Gemini APIClaude API、OpenAI API
集計Google Apps ScriptPython
連携MakeZapier、n8n

訳の生成と訳し戻しを、同じ処理で2回呼びます。 2回目には原文を渡しません。出力は構造化して受け取ります。 公式ドキュメントでは、response_formattype"text")、mime_type"application/json")、schema を置く形が示され、properties required enum items などを指定できるとされています。

ただし「すべてのJSON Schemaの機能がサポートされるわけではない」「深く入れ子になったスキーマは拒否されることがある」とされています。 だから4言語ぶんを1つのスキーマに詰め込まず、言語ごとに1回ずつ呼びます。

03どうやって実装するのか

Step1

処理の起点を決める

原文台帳を5分ごとに見に行く、時間主導型のトリガーを使います。 Apps Script のインストール可能なトリガーには、時間主導型のほか、開いたとき、編集されたとき、構造が変わったときなどがあります。時間主導型は、1分ごとから月に1回まで指定できます。

編集トリガーを使わないことには理由があります。 公式ドキュメントには、「スクリプトの実行とAPIリクエストはトリガーを動かさない」と書かれています。この構成では Make がスプレッドシートへ書き込むため、編集トリガーにすると、その書き込みでは何も起きません。 閲覧モードやコメントモードで開いているときも動きません。

トリガーは、作った人のアカウントの権限で動き、別のアカウントからは見えません。 個人のアカウントで作ると、その人が異動したときに誰も直せなくなります。 失敗したときのメールも、その人にしか届きません。

Step2

入力データを集める

データ中身取得元
原文掲示物ID、種類、設置場所、行番号、日本語の原文、版、原文ハッシュ原文台帳
用語集日本語、4言語の訳語、区分(施設名・設備名・料理名・固有名詞)、確定日、確定した人用語集シート
前の版の訳掲示物IDと行番号で引ける、過去に確認を通った訳文訳台帳
掲示物の属性種類(アレルギー・原材料・料金・緊急時・一般)、対象言語、文字数上限掲示物マスタ
アレルギー品目の一覧自社で表示すると決めた品目名と、その4言語の訳語用語集の一部

質を決めるのは「行番号」と「原文ハッシュ」です。 掲示物を1枚の塊として持つと、1文字直しただけで全文が stale になります。1行ずつ持てば、変わった行の訳だけを作り直せます。

用語集は、この構成で最初に作るものです。 観光庁のガイドラインでも、「共通で使用する固有名詞の対訳語一覧を作成し、関係者間で表記を統一することが望ましい」とされ、業種固有の用語は「さらに詳細に対訳語を定めていくことが望ましい」とされています。訳語の決め方も同じガイドラインに合わせられ、普通名詞部分を含む固有名詞は表音と表意を組み合わせるとされて Mt. Fuji が、対訳が無い普通名詞は括弧に表意を入れる形で Chawan (Tea bowl) が例示されています。

Step3

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

原文台帳、用語集、訳台帳はいずれもスプレッドシートです。Apps Script からシート全体を一度に読み、配列として処理します。 1行ずつ読むと、トリガーの実行時間に収まりません。

読むのは4つです。 原文台帳の原文ハッシュ(前の版との突合に使い、違えば stale を立てる)、訳台帳の「参照した原文ハッシュ」、原文に対する文字列照合で得た用語集の当たり、掲示物マスタの文字数上限です。

用語集は、日本語の表記が長い語から先に当てます。 「大浴場」より先に「浴場」を当てると「大」だけが残り、別の語として扱われます。

そして、用語集をまるごとAIへ渡さないでください。 長いコンテキストの公式ドキュメントでは、「渡す必要のないトークンであれば、渡さないほうがよい」とされ、取り出す対象が複数あると性能が落ちること、長い入力は応答までの時間を延ばすことが挙げられています。当たった十数語だけを渡します。

Step4

AIへ渡す前に整形する

  1. 原文の正規化 … 全角と半角、連続する空白、改行をそろえます。見た目だけの差でハッシュが変わらないようにするためです
  2. ハッシュ化 … 正規化した原文の行ごとにハッシュを取り、原文台帳の列に書きます
  3. 差分の検出 … 訳台帳の「参照した原文ハッシュ」と比べ、違えば stale を立てます
  4. 用語集の当たりの抽出 … 長い語から順に照合し、当たった語と4言語の訳語を取り出します
  5. 前の版の訳の引き当て … ハッシュが変わっていない行は前の版の訳をそのまま使い、AIへ渡しません
  6. 掲示物の種類の判定 … マスタから種類を読み、対象言語と確認の厚みを決めます
  7. 文字数上限の取得 … 枠ごとの上限を読み、文字数比の判定に使います

3番目で日時を使わないでください。 更新日時で比べると、訳を手で直した行は原文より新しくなり、古い訳が「新しい」と判定されます。 訳を直す作業は日常的なので、日時での比較は必ず破綻します。ハッシュなら、訳をいくら直しても参照した原文の版は変わりません。

1番目を飛ばすと、stale が毎日大量に立ちます。 貼り付けた文字は見た目が同じでも空白や改行が違うことがあり、正規化しないと、直していない行まで要更新になります。

Step5

AIに処理させる

させること具体的な中身
用語集を当てた訳の生成指定された訳語を必ず使い、指定のない部分だけを訳す
前の版の訳の流用原文が変わっていない行は前の版の訳をそのまま返す
用語集に無い固有名詞の抽出施設名・料理名・設備名の候補を訳語とともに書き出す
訳し戻し原文を見せずに各言語の訳から日本語へ戻す
曖昧な原文の報告2通りに取れる原文を、訳を1つに決めずに報告する

訳し戻しが、この構成の点検の土台です。 訳し戻した日本語と元の原文を機械で比べ、数値・時刻・金額・アレルギー品目が一致しているかを見ます。 文意まで機械では見ません。そこは人が見ます。

曖昧な原文の報告は、訳の質より運用に効きます。 「本日は営業しておりません」は、期間が書かれていないと訳が決まりません。無理に1つに決めさせるより、原文を直してもらうほうが早く終わります。

させないこと理由
数値・時刻・金額・単位の変更通貨を換算する、時刻を12時間表記に直すといった親切が誤表示になる
アレルギー品目の追加・削除1つ落ちれば健康被害に直結する。判断させる場所ではない
用語集にある語の言い換え言い換えた瞬間に、館内で訳語がそろわなくなる
禁止・注意を促す表現の緩和「危険」を「ご注意ください」に和らげると意図が伝わらない
掲示可かどうかの結論確認の厚みは種類ごとに決める規則の側に置く

アレルギー品目の行と、掲示可かどうかの行が、この題材に固有の線引きです。 品目は増やすことも減らすこともさせず、掲示の可否もAIに言わせません。

Step6

指示内容を固定する

訳の生成は、言語ごとに1回ずつ呼びます。

あなたは宿泊施設の掲示物を多言語化する担当者です。
日本語の原文を、指定された言語に訳してください。

【訳す言語】{target_lang}(en / zh-Hans / zh-Hant / ko のいずれか)
【掲示物の種類】{doc_type}
【原文】行番号付きで渡します。行の数と順番を変えないでください。
{source_lines}
【必ず使う訳語】原文にこの日本語が含まれる場合、訳語は必ずこの語にしてください。
{glossary_hits}
【前の版の訳】原文が変わっていない行は、この訳をそのまま返してください。
{previous_translation}
【枠の文字数上限】{max_chars}(超えても短くしないでください)

【厳守事項】
- 数値、時刻、金額、単位は原文のとおりに写してください。
  通貨を換算する、時刻を12時間表記に直すことをしないでください。
- 原文に無い情報を足さず、原文にある情報を省かないでください。
  特にアレルギーの品目名と禁止・注意を促す文は、1つも落とさないでください。
- 「必ず使う訳語」にある語を、別の語に言い換えないでください。
  文脈に合わないと感じた場合も、ambiguous に理由を書いてください。
- 用語集に無い固有名詞(施設名、料理名、設備名)は、訳したうえで
  new_terms に日本語と訳語を書き出してください。
- 意味が2通りに取れる原文は訳を1つに決めず、ambiguous に行番号と理由を書いてください。
- 原文が空の行は、訳も空にしてください。行を詰めないでください。
- 枠の文字数上限を超えた行は over_limit に行番号を書いてください。

「言い換えずに理由を書く」を明記しないと、用語集を守りません。 文脈に合わない訳語を渡されたとき、何も言わなければ自然なほうへ直します。直してよいかは、用語集を決めた人が判断することです。 勝手に短くさせないのも同じで、削られたのが注意書きでも誰も気づきません。

訳し戻しは、別の呼び出しにします。

次の文を日本語に訳してください。これは訳文の点検に使います。

【言語】{target_lang}
【訳文】{translated_lines}

【厳守事項】
- 書かれていることだけを訳し、元の日本語を推測して補わないでください。
- 数値、時刻、金額、単位は、訳文に書かれているとおりに写してください。
- 訳文に無い語を足さず、訳文にある語を落とさないでください。
- 日本語として不自然でも、訳文の語順と語のまま訳してください。
- 行番号と行数を変えないでください。

この呼び出しに原文を渡さないでください。 渡すと原文をなぞった日本語が返り、どんな訳文でも点検を通ります。 訳し戻しが意味を持つのは、訳文だけを見て日本語に戻したときだけです。

役割の固定には system_instruction を使い、generation_configtemperature を低く置きます。 さらに storefalse にして、前のやり取りを引き継がない形で呼びます。 前の掲示物の言い回しが混ざるのを防ぐためです。

Step7

出力形式を固定する

訳の生成は、次のスキーマで構造化して受け取ります。

"response_format": {
  "type": "text",
  "mime_type": "application/json",
  "schema": {
    "type": "object",
    "properties": {
      "doc_id": { "type": "string" },
      "target_lang": { "type": "string",
        "enum": ["en", "zh-Hans", "zh-Hant", "ko"] },
      "lines": { "type": "array", "items": { "type": "object",
        "properties": {
          "line_no": { "type": "integer" },
          "text": { "type": "string" },
          "reused": { "type": "boolean" },
          "glossary_applied": { "type": "array", "items": { "type": "string" } }
        },
        "required": ["line_no", "text", "reused"] } },
      "new_terms": { "type": "array", "items": { "type": "object",
        "properties": { "ja": { "type": "string" },
                        "translated": { "type": "string" } } } },
      "ambiguous": { "type": "array", "items": { "type": "object",
        "properties": { "line_no": { "type": "integer" },
                        "reason": { "type": "string" } } } },
      "over_limit": { "type": "array", "items": { "type": "integer" } }
    },
    "required": ["doc_id", "target_lang", "lines"],
    "additionalProperties": false
  }
}

target_langenum にしているのは、分類として扱うためです。 自由文で返させると zh-CNChinese (Simplified) が混ざり、突合が外れます。

glossary_applied は、用語集が当たったかを機械で確かめるために返させます。 指定した語と一致し、かつ訳文に含まれているかを見ます。中国語と韓国語は文字列の一致で足りますが、英語は語形が変わるため、小文字にそろえた部分一致で見ます。

reused は、前の版の訳をそのまま返した印です。 true の行は訳し戻しの点検を省けます。改訂30点のうち本当に変わる行は一部で、ここを省くほど呼び出しが減ります。

訳台帳は、次の列で持ちます。 掲示物IDと行番号と言語(原文台帳と突き合わせる鍵)、訳文、参照した原文ハッシュ、状態(stalereviewreadyposted)、点検結果とその理由、確認者と確認日時(二重確認なら2名ぶん)、掲示日

状態と掲示日を分けて持つのが要点です。 ready は確認が済んだという意味で、壁に貼られたという意味ではありません。 混ぜると、確認だけ終わって掲示されていない訳が見えなくなります。

Step8

システムへ連携する

つなぎ先方式内容
原文台帳Apps Script のシート読み書き正規化、ハッシュ化、差分の検出
掲示物マスタ・用語集Apps Script のシート読み取り種類、対象言語、文字数上限、訳語
MakeWebhook掲示物ごとに、言語ぶんの呼び出しを組み立てる
Gemini APIAPI呼び出し訳の生成と訳し戻し(言語ごとに1回ずつ)
訳台帳Apps Script のシート書き込み訳文、点検結果、状態の記録
共有ドライブ既存の保存先制作した掲示物のPDFの保管

Make を挟むのは、呼び出しの組み立てを台帳の処理から切り離すためです。 対象言語が4つの掲示物と2つの掲示物が混ざり、掲示物ごとに何回呼ぶかが変わります。 Apps Script に書くと、言語を足すたびにコードを直すことになります。デザインソフトへは自動で流し込みません。 レイアウトは枠ごとの事情があり、自動化の効果より事故の危険が上回ります。

Step9

人が確認する

確認の厚みを、掲示物の種類で2段に分けます。

種類確認理由
アレルギー表示担当者と別の1名品目が1つ落ちれば健康被害に直結する
原材料表示担当者と別の1名宗教上・信条上の理由で口にできない食材がある
料金担当者と別の1名表示と請求が違えば、その場で紛争になる
緊急時の案内担当者と別の1名誤りが命に関わる。落ち着いて読める状況ではない
一般的な案内担当者1名誤っても言い直しが利く

2人目は、訳文そのものを読むのではありません。 訳し戻した日本語と原文を並べ、数値と品目と注意の言い回しが同じ意味かだけを見ます。 4言語の読み手をそろえる必要はありません。

禁止・注意を促す掲示は、この4種類に入れていません。 観光庁のガイドラインでは、これは「直ちに禁止・注意事項を理解できるよう、見た目の分かりやすさが重視される情報」とされ、ピクトグラムを積極的に活用することが望ましいとされています。禁煙や立入禁止は、文章の訳を増やすより図記号で出すほうが確実です。

Step10

例外に対処する

起きること対応
原文が空欄のまま保存されるstale は立てず、原文の不足として担当者へ返す
訳の行数が原文と合わない訳を捨てて再実行。2度続けば review で人へ
数値・時刻・金額が訳し戻しと一致しない理由を付けて review に留める
アレルギー品目の数が原文と合わない同じく review自動で ready にする経路を作らない
文字数比が上限を超えるover_limit の行を人へ。短い言い換えの採否は人が決める
用語集の語が訳文に含まれないreview。英語は小文字にそろえた部分一致で確かめる
スキーマが拒否される深く入れ子のスキーマは拒否されることがある。言語ごとに分けて浅く保つ
トリガーが動かないAPIからの書き込みではトリガーは動かない。 時間主導型を使う
トリガーの実行が失敗する作成者にメールが届く。実行履歴を見る。止めるにはトリガーを無効にする
掲示物を差し替えないまま次の改訂が来る掲示日が空のまま stale になった行を、別の一覧で追う

トリガーに関わる2行は、訳の質ではなく仕組みの側の不具合です。 どちらも「何も起きていないのに正常に見える」型なので、stale の件数を毎週数えて気づくようにします。 掲示物の差し替えだけは台帳では解けません。壁に貼られたかは館内を見ないと分からず、掲示日を人が入れる運用を続けられるかで、この仕組みが生きるかが決まります。

Step11

記録を残す

  • 原文の版ごとの全文と、そのときの原文ハッシュ
  • AIへ渡した指定と、返ってきた訳文、new_termsambiguousover_limit の全文
  • 訳し戻した日本語と、機械の点検の結果(外れた項目と理由)
  • 人が訳を直した記録 … どの行を、どう直したか。二重確認の場合は2名ぶん
  • 用語集の変更履歴 … いつ、誰が、どの語をどう決めたか
  • 掲示日と、そのとき掲示した訳文の版

用語集の変更履歴を残すのは、訳語が後から変わるためです。 「大浴場」の訳を変えると、過去に掲示した全部の掲示物が古い語のままになります。 履歴があれば、いつ以降を作り直せばよいかが決まります。

人が直した記録は、用語集を育てる材料です。 繰り返し直されている語を月に一度洗い出して用語集へ足します。

04実装レベルの3段階

最小構成:原文と用語集を手でAIの画面に貼り、4言語の訳と訳し戻しを作らせる / 1点ごとの訳の作成と、目視での点検
半自動化:上記+原文台帳と訳台帳を持ち、差分から `stale` を立て、訳の生成と訳し戻しをAPIで呼び、点検を機械で集計する / 更新の検知、訳の作成、点検の一次判定
本格構成:上記+掲示物マスタで対象言語と確認の厚みを切り替え、用語集の変更履歴と掲示日まで台帳で追う / 掲示物の運用全体の管理

最小構成では更新に追随できません。 訳は作れますが、原文が変わったことを誰かが覚えている必要があります。 この記事が解こうとしている問題は解けません。 半自動化で、1点36分が12分になります。この段階が本記事の想定です。 stale が自動で立ち、訳が作られ、点検の一次判定まで出ます。残るのは、訳文を確認する時間と掲示日を入れる作業です。 本格構成に進んでも、時間はそれほど減りません。 減るのは訳語のゆれと、掲示し忘れです。 用語集の変更履歴と掲示日が台帳に乗ると、「どの掲示物が古い語のままか」「どれが確認済みで貼られていないか」が一覧で見えます。半自動化を数か月動かしてから進めてください。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
2 名
月間件数
40 件
1件あたり現在時間
36 分
1件あたり導入後時間
12 分
現在  40件 × 36分 ÷ 60 = 24 時間/月
導入後 40件 × 12分 ÷ 60 = 8 時間/月
月間削減時間
16h
削減率
67%
年間削減時間
192h
年間金額換算(時間単価3,500円)
67万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 訪日客の比率が高く、館内案内・メニュー・注意書きを3言語以上で掲示している宿泊施設、飲食店、商業施設、クリニック。料金やアレルギー表示、営業時間の改訂が月に数十点あり、日本語だけ直して多言語版が古いまま残った経験がある場合。掲示物の原文をテキストで持ち直す移行作業に、最初の数週間を使える場合。
向いていない
  1. 掲示物が英語1言語だけで、改訂が年に数回しかない場合。館内掲示の制作をすべて外部に任せており、原文の管理を自社で持てない場合。翻訳支援ツールと翻訳メモリを導入済みで、原文と訳の対応がすでに管理されている場合。なお、医薬品の添付文書のように、翻訳文そのものに規制上の要件がある掲示物は、この構成では扱えません。

07最小構成で試す方法

  1. 館内の掲示物から10点を選ぶ(料金表、メニュー、注意書き、緊急時の案内を必ず混ぜる
  2. 10点の原文を、1行1文でスプレッドシートに書き出す
  3. その10点に出てくる固有名詞、施設名、料理名、設備名を集め、用語集の最初の30語を決める
  4. 手元のAIサービスの画面に、原文と用語集を貼り付けて4言語の訳を作らせる
  5. 新しい画面を開き、出てきた訳だけを貼り付けて「日本語に訳してください」と指示する
  6. 訳し戻した日本語と原文を並べ、数値・時刻・金額・品目が合っているかを見る

5番で画面を分けるのが、この試行の要点です。 同じ画面で続けると、直前の原文を覚えたままの日本語が返ります。画面を分けて初めて、点検として成り立ちます。

出てきた内容判断
数値と品目が一致し、用語集の語が使われていた台帳と自動化に進む。構成は有効
用語集の語が別の語に置き換わっていた指示の書き方で直る。言い換えを禁じる一文を足す
原文が曖昧で訳が決まらない箇所が多い原文の書き方が先。 AIの問題ではない

3行目が出ることは珍しくありません。 掲示物の日本語は、読み手が前提を補って読むことで成り立っています。訳せない原文が見つかったのは失敗ではなく、書き直すべき原文が分かったということです。

08実装時につまずきやすいポイント

問題対策
原文がPDFや画像の中にしかないテキストで台帳に持つ運用へ変える。 移行が最初の、そして最大の作業
見た目だけの差で stale が大量に立つ全角半角・空白・改行を正規化してからハッシュを取る
訳を手で直すと原文より新しくなる更新日時で比べない。 参照した原文ハッシュで突き合わせる
Make の書き込みでトリガーが動かないAPIからの書き込みではトリガーは動かない。 時間主導型を使う
英語が枠に収まらない文字数比を機械で見て、上限を超えた行を人へ回す。自動で短くしない
用語集が部分一致で取り違える長い語から当て、当たった範囲を後の照合から外す
簡体字と繁体字を1つにまとめてしまう別の言語として台帳に持ち、訳語も別に決める
訳し戻しが自然すぎて誤訳が隠れる原文を見せずに訳し戻す。 呼び出しを分ける
アレルギー品目が1つ落ちる品目名を機械で数え、原文と合わなければ ready にしない
掲示物を差し替えないまま台帳だけ進む掲示日を台帳の列として持ち、空欄のものを毎週見る

最初の行が、この構成で最も重い壁です。 技術ではなく運用の変更です。デザインソフトで作った掲示物を「完成品」と考えている限り、原文はどこにも残りません。 原文を台帳に持ち、そこから掲示物を作る順番に変える必要があります。

訳の質に見えて、実は仕組みの問題という項目がいくつもあります。 更新日時で比べていた、トリガーが動いていなかった、正規化していなかった。どれも「訳が古い」と同じ見え方をしますが、直す場所はAIの外側です。 まず stale が正しく立っているかを確かめてください。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 館内の案内文、メニューと原材料、料金表、設備の利用方法、避難経路の案内、用語集です。個人情報は原則として含まれません。 掲示物は、壁に貼って誰にでも見せるものだからです。

  1. 無料の枠で試さない … 利用規約では、無料の枠について送信したコンテンツと生成された応答を Google の製品・サービスの提供、改善、開発のために使用するとされ、人によるレビューが行われうること、機微情報・秘密情報・個人情報を送信しないことが明記されています
  2. 有料の枠での扱いを確認しておく … 有料の枠については、プロンプト(システム指示やファイルを含む)と応答を製品の改善のために使用しないとされています。利用規約は変わるので、確認した日を記録に残します
  3. 未公開の情報を混ぜない … 掲示物の原文は公開情報ですが、改定前の料金表を先に台帳へ入れると、公開前の価格が外部へ渡ります。 公開日より前の原文は別のシートに分けてください
  4. 緊急時の案内の確認は人が必ず行う … 観光庁のガイドラインでは、非常時等について「多言語でのやりとりの文章・音声を事前に用意して案内する」ことが示されています。事前に用意するものだからこそ、間違ったまま何年も掲示され続けます
  5. 用語集を決める権限を1か所にする … 訳語は、変えると過去の掲示物すべてに影響します。誰でも書き換えられる状態にすると月ごとに揺れます。 確定した人と日を残してください
  6. AIに掲示の可否を決めさせない … AIに求めるのは訳の生成と訳し戻しだけです。掲示してよいかは点検の結果と人の確認で決めます

誤りが起きた場合のリスクは、古い訳が残ることと、誤訳が事故になることの2つです。 前者は stale の仕組みで、後者は4種類の二重確認で防ぎます。どちらもAIの精度を上げることでは解けません。 台帳と確認の線引きで守る問題です。

10まず何から始めるか

1週目:掲示物を数え、種類を付ける

館内の掲示物を一覧にして、アレルギー表示・原材料表示・料金・緊急時の案内・一般的な案内のどれかを付けます。どこに何が貼ってあるかが分かっていない施設が大半です。 数えると想定より多く出てきます。

2週目:10点で試す

掲示物から10点を選び、原文を書き出し、用語集の最初の30語を決めます。手元のAIサービスで訳を作り、別の画面で訳し戻して、数値と品目が合っているかを見ます。

3週目:原文台帳と訳台帳を作る

掲示物ID、行番号、原文、原文ハッシュ、参照した原文ハッシュ、状態の列を作ります。この時点では訳を自動で作りません。 原文を直したときに stale が正しく立つかだけを確かめます。ここが動かないまま進むと、後で作り直すことになります。

4週目:訳の生成と訳し戻しをつなぐ

Make から言語ごとに呼び、点検の集計までを作ります。外れた理由を一覧で読み、正規化の漏れと用語集の不足を先に潰します。

2か月目: 掲示物マスタで確認の厚みを切り替え、二重確認の運用を始めます。stale と、掲示日が空のまま残っている件数を毎週数えます。3か月目以降: 用語集を月に一度見直し、繰り返し直された語を足します。1点36分が何分になったかを実測し、掲示日が空の行がゼロで安定した時点で完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-23/最終更新:2026-09-23
確認した内容情報源確認日
構造化出力を response_formattype"text")、mime_type"application/json")、schema で設定すること。properties required additionalProperties enum items などを指定でき、enum が分類のための文字列の集合であること。深く入れ子になったスキーマは拒否されることがあることGemini API: Structured output2026-09-23
system_instruction で振る舞いを指示でき、generation_configtemperature を指定できること。storefalse にして呼べることGemini API: Text generation2026-09-23
渡す必要のないトークンは渡さないほうがよいとされること。取り出す対象が複数あると性能が落ち、入力が長いほど応答までの時間が延びることGemini API: Long context2026-09-23
無料の枠では、送信した内容と応答が製品の提供・改善・開発に使用され、人によるレビューが行われうること。機微情報・秘密情報・個人情報を送信しないこととされること。有料の枠では使用しないとされることGemini API 追加利用規約2026-09-23
時間主導型トリガーが1分ごとから月1回まで指定できること。スクリプトの実行とAPIリクエストではトリガーが動かず、閲覧・コメントモードでも動かないこと。作成者の権限で動き、失敗すると作成者にメールが届くことApps Script: Installable triggers2026-09-23
多言語対応の対象が、禁止・注意を促すもの/名称・案内・誘導・位置を示すもの/文章で解説をしているもの に分類されること。禁止・注意を促すものはピクトグラムの積極的な活用が望ましいとされること。共通で使用する固有名詞の対訳語一覧を作成して表記を統一し、業種固有の用語はさらに詳細に対訳語を定めることが望ましいとされること。固有名詞の英語表記に Mt. Fuji Chawan (Tea bowl) が例示されていること。非常時等の文章・音声を事前に用意して案内する文例が示されていること観光庁: 多言語対応のガイドライン2026-09-23

どの掲示物を二重確認の対象とするかは、施設ごとに決めてください。 本記事は上記の4種類を対象とするモデルです。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0188)についてのご相談はこちらから。

AI活用について相談する
目次