Media > AI活用ユースケース > 総務 > 自治体の税務課・保険年金課が出す納付・手続きのお知らせを、用語集をそろえて多言語に訳し、原文の改定に合わせて訳文の差分を更新する

自治体の税務課・保険年金課が出す納付・手続きのお知らせを、用語集をそろえて多言語に訳し、原文の改定に合わせて訳文の差分を更新する

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

税と国民健康保険・国民年金のお知らせの原文が改定されたとき、変わった段落だけを用語集に沿って訳し直し、多言語版を更新します。担当は全文の発注をやめ、変わった箇所の訳と照合の結果を確かめて母語話者の確認に回します。

サマリー
生成AI
Azure OpenAI Service/Claude/Gemini
連携・自動化
Power Automate
対象業界
自治体
対象部門
総務
対象業務
台帳・マスタ管理/書類作成
主な課題
属人化している/書類作成に時間がかかる/確認ミスが多い
AIで行う処理
翻訳
主な効果
品質標準化/対応スピード向上/工数削減
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
条件付き
現在工数
120h/月
AI導入後
40h/月
想定削減
67%
年間削減
960h
モデル条件による試算値です。実在企業の実績ではありません。

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

導入前(Before)
  1. 担当課が原文を改定し、多言語の文書を取りまとめる係に連絡する
  2. 係が前の版の訳文を探し、原文のどこが変わったかを前の版と見比べる
  3. 外部の翻訳事業者に、原文の全文を言語ごとに発注する
  4. 届いた訳文を、前の版の訳文と見比べ、用語が変わっていないかを確かめる
  5. 金額・日付・電話番号・窓口の名前が原文と合っているかを1つずつ確かめる
  6. 読める職員か国際交流協会に意味を確かめてもらい、ホームページに掲載し、印刷用の原稿にする
導入後(After)
  1. 人担当課が改定した原文を、原文のフォルダに保存する
  2. 自動中継の処理が、原文を段落ごとに分け、前の版と比べて変わった段落・足された段落・消えた段落を出す
  3. 自動変わった段落について、金額・日付・電話番号・窓口の名前を記号に置き換え、用語集から関係する用語を引く
  4. 自動Azure OpenAI が、言語ごとに変わった段落だけを訳し、使った用語、新しい用語、日本語への逆訳を返す
  5. 自動中継の処理が、記号が全部残っているか、用語集の訳が使われているかを照合し、記号を元に戻す
  6. 人係が、照合の結果と逆訳を見て、意味のずれと新しい用語を確かめる
  7. 人母語話者の校閲者が、変わった段落の訳と新しい用語の訳を確かめる
  8. 人係が承認し、新しい版として保存して、掲載と印刷用の原稿に回す
各工程の詳しい説明を読む
  1. 担当課が原文を改定し、多言語の文書を取りまとめる係に連絡する
  2. 係が前の版の訳文を探し、原文のどこが変わったかを前の版と見比べる
  3. 外部の翻訳事業者に、原文の全文を言語ごとに発注する
  4. 届いた訳文を、前の版の訳文と見比べ、用語が変わっていないかを確かめる
  5. 金額・日付・電話番号・窓口の名前が原文と合っているかを1つずつ確かめる
  6. 読める職員か国際交流協会に意味を確かめてもらい、ホームページに掲載し、印刷用の原稿にする

(a)数行の改定で全文を発注している。 前の訳文のどこを直せばよいかを係が判断できないため、全文を出し直しています。届くたびに、変わっていない段落まで訳が変わってきます。

(b)用語の訳が揃わない。 同じ「納期限」が、文書と発注の時期によって違う英語になっています。住民から「この2つの期限は違うものか」と窓口で聞かれます。

(c)数字の確かめに時間がかかる。 日付の書き方は言語ごとに違い、和暦を西暦にした訳もあれば、そのままの訳もあります。係は読めない言語の中から数字を探して原文と照らしています。 ネパール語の数字の表記のように、見慣れない書き方で数字が書かれていると、探すこと自体が難しくなります。

(d)担当者しか分からない。 前の版の訳文がどこにあるか、どの事業者にどの言語を出しているかは、係の担当者の記憶とメールの中にあります。

(e)消した段落が他の言語に残る。 制度の改正で原文から1段落を消したとき、発注が新しい言語の分だけになると、古い言語の版に廃止した制度の案内が残ります。 日本語の版と各言語の版で、案内している内容が違う状態です。

  1. 【人】 担当課が改定した原文を、原文のフォルダに保存する
  2. 【自動】 中継の処理が、原文を段落ごとに分け、前の版と比べて変わった段落・足された段落・消えた段落を出す
  3. 【自動】 変わった段落について、金額・日付・電話番号・窓口の名前を記号に置き換え、用語集から関係する用語を引く
  4. 【自動】 Azure OpenAI が、言語ごとに変わった段落だけを訳し、使った用語、新しい用語、日本語への逆訳を返す
  5. 【自動】 中継の処理が、記号が全部残っているか、用語集の訳が使われているかを照合し、記号を元に戻す
  6. 【人】 係が、照合の結果と逆訳を見て、意味のずれと新しい用語を確かめる
  7. 【人】 母語話者の校閲者が、変わった段落の訳と新しい用語の訳を確かめる
  8. 【人】 係が承認し、新しい版として保存して、掲載と印刷用の原稿に回す

消えた段落も、2番目で同じように扱います。 原文から消した段落は、4言語の版からも同時に消えます。日本語の版と各言語の版が、いつも同じ段落の並びになります。

7番目を省かないことが、この設計の前提です。 逆訳で大きな意味のずれは拾えますが、その言語で自然に読めるか、失礼な言い回しになっていないかは、母語話者にしか分かりません。 確認に回すのを変わった段落だけにすることで、校閲者の負担を小さくします。

2番目で段落ごとに比べるのは、確かめる場所を絞るためです。 全文を訳し直すと、変わっていない段落まで言い回しが変わり、校閲者は全文を読み直すことになります。

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

構成図
【入力】担当課が改定した原文(Word)
   ▼【トリガー】原文のフォルダへの保存
中継の処理(Azure Functions)
   ├── 段落に分け、前の版と比べて差分を出す
   ├── 金額・日付・電話番号・窓口の名前を記号に置き換える
   ├── 用語集から関係する用語を引く
   ▼
Azure OpenAI(Microsoft Foundry。構造化出力)
   │  変わった段落だけを言語ごとに訳す/使った用語/新しい用語/逆訳
   ▼
中継の処理 ── 記号と用語の照合、記号を元に戻す、新しい版の下書き
   ▼
【人】係が照合と逆訳を確かめる → 母語話者の校閲 → 承認
   ▼
新しい版として保存 → ホームページ・印刷用の原稿
役割想定する製品代替候補
生成AIAzure OpenAI(Microsoft Foundry)Claude API、Gemini API
連携Azure Functions(中継の処理。差分、置き換え、照合、版の作成)Power Automate
保管Microsoft SharePoint(原文・訳文・用語集の版の管理)庁内のファイルサーバー
校閲母語話者の校閲者(委託または国際交流協会)―

版の表は、1行が「お知らせ・段落の番号・版・言語」の組で、原文と訳文と承認の記録を持ちます。 表計算の形でも足りますが、行は月に数百ずつ増えるので、検索しやすい置き場所にします。

訳文は段落ごとに版で持ちます。 1つのお知らせについて、原文の段落と4言語の訳文を、段落の番号と版の番号で結び付けた表にします。変わっていない段落の訳は、承認済みの訳をそのまま使います。

生成AIは、Azure OpenAI の構造化出力で呼びます。 Microsoft Learn では、構造化出力を使うとモデルは推論 API 呼び出しの一部として指定した JSON スキーマの定義に従うとされ、有効な JSON は保証するがスキーマへの厳密な準拠はできなかった以前の JSON モードとは違うと説明されています。Chat Completions API では response_format に、Responses API では text.format にスキーマを書きます。段落ごとの訳と、使った用語、新しい用語、逆訳を、決まった形で受け取るために使います。

渡すのは、お知らせの文例だけです。 氏名や税額の入った個人宛ての通知は、帳票のシステムが訳文の文例に差し込んで作ります。この構成が扱う文書には、住民の個人情報は入りません。

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

Step1

処理の起点を決める

担当課が、改定した原文を原文のフォルダに保存したときに動きます。 保存のたびに動かすと、書きかけの原文まで訳されるので、ファイル名の末尾に「確定」と付けたものだけを対象にします。担当課は原文を確定したら、名前を付け替えて保存します。

新しいお知らせは、同じフォルダに新規で置けば動きます。 前の版が無いので全部の段落が「足された段落」になり、全文が訳されます。このときだけは、校閲者が全文を読みます。

4月と6月、7月は原文の改定が集中します。 当初の課税と国民健康保険税の通知の時期だからです。動きはフォルダへの保存ごとなので、集中しても係がまとめて発注する作業はありません。 校閲者への依頼の件数だけが増えるので、時期の前に校閲者と量を相談しておきます。

Step2

入力データを集める

データ中身取得元
改定した原文お知らせの全文(段落と見出し)原文のフォルダ
前の版の原文と訳文段落ごとの原文と、4言語の承認済みの訳版の管理の表
用語集税と保険の用語と、言語ごとに市が決めた訳、使ってはいけない訳用語集の表
固定の表記の一覧窓口の名前、施設の名前、制度の正式名称と言語ごとの表記用語集の表の別の欄
文体の取り決め言語ごとの呼びかけ方、敬語の度合い、日付の書き方言語ごとの取り決め

質を決めるのは、用語集です。 最初の用語集は、いまある訳文から用語を拾い、言語ごとに一番多く使われている訳を候補にして、母語話者に1つに決めてもらいます。 300語程度から始め、新しい用語が出るたびに足します。

「使ってはいけない訳」の欄を持たせます。 例えば「督促」を、取り立てを強く思わせる語で訳すと、住民を必要以上に不安にさせます。避ける訳を明記しておくと、照合でその訳が出ていないかを機械で確かめられます。

日付の書き方は、言語ごとに決めて取り決めに書きます。 原文の和暦をどう扱うかは、訳す人によって変わりやすいところです。本記事では、記号を戻すときにプログラムが西暦の日付を言語ごとの書き方で入れることにします。AIには日付を書かせません。

Step3

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

原文のフォルダは SharePoint に置き、中継の処理が保存を検知してファイルを受け取ります。Word の文書から段落と見出しを取り出し、段落ごとに番号を付けます。

取るものどこから何に使うか
原文の段落原文の Word の文書差分を取る。訳す材料
前の版の段落と訳版の管理の表差分の比較の相手。変わらない段落の訳
関係する用語用語集の表段落に出てくる用語だけを引いて渡す
固定の表記用語集の表窓口と施設の名前を言語ごとの表記で戻す

用語集は、段落に出てくる用語だけを渡します。 300語を毎回全部渡すと、関係の無い用語に引きずられた訳が出ます。段落の中の語を用語集の見出しと突き合わせ、当たったものだけを渡します。

見出しと箇条書きの番号は、訳さずに構造として持ちます。 「1.」「(1)」「ア」のような番号は記号と同じ扱いにし、訳文でも原文と同じ位置に同じ番号が来るようにします。番号がずれると、窓口で「2番の書類」と言われたときに言語によって違う書類を指してしまいます。

段落の差分は、文字の一致で取ります。 句読点や全角と半角の違いだけの変更は「変わっていない」とみなす正規化をしてから比べ、意味の変わらない改定で訳を作り直さないようにします。

Step4

AIへ渡す前に整形する

  1. 段落への分割 … 見出し・段落・箇条書きの項目を1つずつの単位にし、番号を付けます
  2. 差分の判定 … 前の版と比べて、変わった・足された・消えた・変わらないの4つに分けます。正規化したうえで比べます
  3. 記号への置き換え … 金額、日付、期限、電話番号、メールアドレス、窓口の名前、施設の名前を、{AMOUNT_1} {DATE_1} {PHONE_1} {OFFICE_1} のような記号に置き換えます
  4. 用語の引き当て … 段落の中の用語を用語集と突き合わせ、当たった用語と言語ごとの訳を一覧にします
  5. 前後の段落の添付 … 変わった段落の前後1段落を、承認済みの訳とともに「参考」として添えます

3番目を軽く見ないでください。 記号に置き換えておけば、訳文の中に数字が残っているかどうか、記号が全部戻ったかどうかを機械で確かめられます。 置き換えずに訳させると、「6月30日」が「30 June」「June 30」「30/6」と言語の中で揺れ、確かめる手段がありません。

5番目は、文のつながりのためです。 変わった1段落だけを渡すと、前の段落で「あなた」と呼びかけていたのに、この段落だけ「住民の皆さま」になる、ということが起きます。前後の承認済みの訳を見せ、言い回しを合わせさせます。 参考の段落は訳し直させません。

記号を戻すときの書き方は、言語ごとの表で決めておきます。

記号戻し方例(ベトナム語の場合の考え方)
{DATE_n}西暦の年月日を、取り決めの順序で入れる。曜日は入れない日・月・年の順に数字で書く
{AMOUNT_n}数字に3桁区切りを付け、通貨の表記を添える原文の「円」を取り決めの表記にする
{PHONE_n}原文のとおり、ハイフンを残す国番号は付けない
{OFFICE_n}固定の表記の一覧から、その言語の名前を入れ、日本語の名前を括弧で添える窓口で日本語の表示と見比べられるようにする

窓口の名前に日本語を添えるのは、住民が庁舎で案内の表示と見比べるためです。 訳した名前だけでは、どの窓口に行けばよいかが分かりません。どの記号をどう戻すかを表で持てば、言語を増やしても戻す処理は変わりません。

Step5

AIに処理させる

場面させること
訳す変わった段落と足された段落を、指定の言語に訳す。記号はそのまま残す
用語渡した用語の訳を必ず使い、使った用語を一覧で返す
新しい用語用語集に無い税・保険の用語を見つけたら、訳を作らず「新しい用語」として返す
逆訳自分の訳を日本語に訳し戻し、係が意味を確かめられるようにする
文体言語ごとの取り決めと、前後の段落の言い回しに合わせる
させないこと理由
記号の中身の推測・書き換え金額・日付・窓口はプログラムが戻す。AIに数字を書かせない
用語集に無い用語の訳の作成訳が揃わない原因になる。母語話者が決めて用語集に足す
原文に無い説明の追加「分かりやすくするため」の補足が、制度の説明の誤りになる
変わっていない段落の訳し直し承認済みの訳が変わり、校閲の範囲が広がる
制度の内容の要約・省略減免や猶予の条件を短くすると、条件が落ちる

3行目がいちばん起きやすい失敗です。 原文の「納期限までに納付してください」を訳すとき、AIは親切心から「遅れると延滞金がかかります」と足したくなります。その段落に延滞金の説明が無いなら、足された一文は市が出していない説明です。 原文に無い文は書かせず、逆訳で足された文が無いかを係が確かめます。

新しい用語を訳させないのは、訳を1つに保つためです。 AIが作った訳をその場で使うと、次の改定では別の訳を作ります。用語集に入るまでは、その段落は「新しい用語あり」として係の確認に回し、校閲者が訳を決めます。

Step6

指示内容を固定する

あなたは市の税務課・保険年金課のお知らせを、{language}に訳す担当です。
渡された「訳す段落」だけを訳してください。推測で補わないでください。

【守る用語】
渡した用語集の訳を必ず使ってください。別の訳語を使わないでください。
「使ってはいけない訳」にある語を使わないでください。

【記号】
{AMOUNT_1} {DATE_1} {PHONE_1} {OFFICE_1} のような記号は、
訳文の中にそのまま残してください。記号の中身を推測して書かないでください。
数字を自分で書かないでください。

【新しい用語】
税・保険・年金の制度の用語で、用語集に無いものがあれば、
訳を作らずに new_terms に原文の語を入れ、訳文の中では原文の語を
[]で囲んで残してください。

【厳守事項】
- 原文に無い説明・注意書き・例を足さないでください。
- 原文の条件(期限、対象者、必要な書類)を省略しないでください。
- 参考として渡した前後の段落は訳し直さず、言い回しを合わせるためだけに使ってください。
- 呼びかけと敬語の度合いは、言語ごとの取り決めに合わせてください。
- back_translation には、あなたの訳を日本語に訳し戻した文を書いてください。
  原文を写さないでください。

【言語ごとの取り決め】{style_rules}
【用語集(この段落に関係するもの)】{glossary}
【参考:前後の段落と承認済みの訳】{context}
【訳す段落】{segments}

「原文を写さないでください」を書かないと、逆訳の欄に原文をそのまま入れてきます。 逆訳は、係が読めない言語の訳の意味を確かめるための欄で、原文が入っていると、ずれがあっても気づけません。 逆訳と原文が一字一句同じものは、中継の処理で印を付けます。

新しい用語を[]で残させるのは、訳文が途中で止まらないようにするためです。 訳を作らせない代わりに原文の語を残させると、係と校閲者がどこに新しい用語があるかを訳文の中で見つけられます。 承認の前に、[]が残っていないことを機械で確かめます。

Step7

出力形式を固定する

次の形のJSONで受け取ります。

{
  "document_id": "nouzei-kouza-furikae",
  "language": "vi",
  "segments": [
    { "segment_id": "P-04",
      "translation": "",
      "placeholders": ["{DATE_1}", "{OFFICE_1}"],
      "terms_used": [ { "ja": "納期限", "target": "" } ],
      "new_terms": [""],
      "back_translation": "" }
  ]
}

1つ目の理由は、段落の番号で版の表に戻せることです。 segment_id は前処理で付けた番号で、返ってきた訳をそのまま版の表の該当の段落に入れられます。 番号の無い段落や、渡していない番号が返ってきたら落とします。

2つ目は、照合を機械でできることです。 placeholders と terms_used を必須の配列にしておくと、訳文の中の記号と用語を、AIの申告と実際の文字の両方で突き合わせられます。 Microsoft Learn では、構造化出力ではすべてのフィールドを必須にする必要があり、オブジェクトには常に additionalProperties: false を設定するとされています。

3つ目は、スキーマで縛れない検査を先に決めておけることです。 文字列の pattern や配列の minItems などはサポートされていません。language のように値の決まった項目は列挙型で縛れます。

項目中継の処理での検査
translation の記号渡した記号が全部、1回ずつ残っているか
translation の数字記号の外に数字が書かれていないか
terms_used用語集の訳が訳文の中に実際にあるか。使ってはいけない訳が無いか
new_terms空でなければ、その段落を「新しい用語あり」として係に回す
back_translation原文と一字一句同じでないか
Step8

システムへ連携する

つなぎ先方式内容
原文のフォルダ(SharePoint)保存の検知「確定」の付いた原文を受け取る
版の管理の表・用語集(SharePoint)読み取りと、承認後の書き込み前の版の段落と訳、用語、固定の表記
Azure Functions中継の処理差分、置き換え、照合、記号を戻す、新しい版の下書き
Azure OpenAIChat Completions API(構造化出力)段落の翻訳、使った用語、新しい用語、逆訳
校閲者確認用の表をメールで送る変わった段落の原文・訳・逆訳を並べた表

版の表への書き込みは、係の承認のあとだけです。 中継の処理が作るのは新しい版の「下書き」で、承認されるまで、ホームページと印刷用の原稿は前の版のままです。

ホームページへの掲載は、承認された版から作った原稿を係が管理画面に貼る運用にします。 管理画面に自動で書き込む連携は作りません。公開の操作を人に残すことで、校閲を経ていない版が出る経路を1つ減らします。

校閲者へは、変わった段落だけを並べた表を送ります。 原文、前の版の訳、新しい訳、逆訳、新しい用語を1行に並べ、校閲者は「このままでよい」「直す」のどちらかと直した訳を書いて返します。

Step9

人が確認する

  1. 照合の印を先に見る … 記号の不足、記号の外の数字、使ってはいけない訳、逆訳が原文と同じもの。印の付いた段落から開きます
  2. 逆訳で意味のずれを確かめる … 逆訳と原文を並べ、条件・期限・対象者が落ちていないか、足された文が無いかを見ます
  3. 新しい用語を校閲者に回す … 訳の候補を付けず、原文の語と使われている文脈を送ります
  4. 母語話者の校閲を受ける … 変わった段落の訳と新しい用語の訳を確かめてもらいます
  5. 承認して版を上げる … 校閲の結果を入れて承認し、新しい用語は用語集に足します

逆訳は、意味のずれを拾う道具で、訳の良し悪しを決める道具ではありません。 逆訳が原文と同じ意味でも、その言語では不自然な訳はあります。係が逆訳で見るのは、条件・期限・対象者が落ちていないか、足された文が無いかの2点に絞ります。 自然さは校閲者に任せます。

1件20分を目安にします。 照合の印と逆訳を見て、校閲者に回し、戻ってきた結果を入れて承認する時間です。校閲者が読む時間は、市の職員の工数には入れていませんが、全文から変わった段落だけになる分、委託の費用も小さくなります。

Step10

例外に対処する

起きること対応
記号が欠けている、2回出ているその段落を作り直す。2回目も同じなら係の確認に回す
記号の外に数字があるその段落に印を付けて係に回す
使ってはいけない訳が出たその段落を作り直す。指示の「使ってはいけない訳」を確かめる
新しい用語がある「新しい用語あり」として係と校閲者に回す。承認まで公開しない
原文の段落の分け方が大きく変わった(全面改定)差分を取らず、全文を新規として訳し、校閲者が全文を読む
表や図の中の文字自動では訳さない。係が手で原稿を作る
消えた段落がある訳文の版からも同じ段落を消す。消し忘れると、廃止した制度の案内が他の言語にだけ残る
原文に誤字がある訳さずに担当課に戻す。直った原文で作り直す
校閲者が期限までに返せない前の版を公開したままにする。日付が変わる改定は、日本語版に「各言語版は準備中」と添える
Azure OpenAI の呼び出しに失敗した原文のフォルダに残し、次の保存か手動の再実行で作り直す

全面改定の行が、運用の初めにいちばん判断に迷うところです。 段落の半分以上が変わったら全面改定として扱う、のように機械で決められる線を先に引いておきます。 差分で訳した段落と新規で訳した段落が混ざると、文書の中で言い回しが揃いません。

Step11

記録を残す

  • お知らせごとの、原文の版と言語ごとの訳文の版、承認した日と承認者
  • 段落ごとの、前の版の訳と新しい訳、AIが返したJSON
  • 校閲者が直した段落と、直す前と後の訳
  • 照合で付けた印の件数と種類(記号の不足、数字、使ってはいけない訳、逆訳の写し)
  • 用語集に足した用語と、足した日、決めた校閲者
  • 言語ごとの、新しい用語の発生件数と、校閲で直された段落の割合

3つ目は、用語集と指示を直す材料になります。 校閲者が同じ言い回しを何度も直しているなら、それは用語集に入れるべき言い回しか、言語ごとの取り決めに足すべき書き方です。 直した理由を一言残してもらうと、取り決めを直すのが早くなります。

04実装レベルの3段階

最小構成:変わった段落を手で置き換えて生成AIの画面に貼り、訳させる / 段落ごとの訳と逆訳
半自動化:上記+中継の処理で段落の差分、記号への置き換え、用語の引き当て、Azure OpenAI の呼び出しを行う / 差分の判定と訳の下書き
本格構成:上記+フォルダへの保存を起点にした自動の起動、記号と用語の照合、版の管理の表、校閲者への確認表 / 原文の確定から、照合済みの訳と校閲の依頼が出るまで

最小構成は、確かめるための段階です。 置き換えと差分の判定を手で行うので、月120件はさばけません。 半自動化で、訳の下書きまでは自動になります。 ただし照合が無いため、記号と用語の確かめを係が目で行うことになり、③の時間がまだ残ります。 照合と版の管理まで入るのは本格構成で、本記事の想定は本格構成です。 段階を飛ばさないでください。 半自動化を2〜3か月回すと、どの用語で新しい用語が出やすいか、校閲者がどの言い回しを直すかが分かります。それを用語集と取り決めに入れてから照合を作ると、照合で付く印の数が減り、係が見る段落が絞られます。

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

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

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

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

AI活用について相談する

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

向いている
  1. 外国人住民が増え、税と国民健康保険・国民年金のお知らせを複数の言語で出している市区町村。翻訳を外部の事業者に都度発注していて、原文の一部が変わるたびに全文を発注し直している場合。言語ごとに税の用語の訳が揃っておらず、同じ「納期限」が文書ごとに違う訳になっている場合。庁内で Microsoft Azure の利用が認められている場合。
向いていない
  1. 多言語のお知らせが年に数本で、外部への発注で足りている場合。訳文を母語の話者が確かめる手段(委託の校閲者、国際交流協会など)を用意できない場合(機械の訳をそのまま出すことになる)。個人宛ての通知の本文(氏名や税額の入った帳票)をそのまま訳したい場合(本記事は文例の翻訳に限る)。なお、どの言語で出すか、訳文を公開してよいかの判断は担当課に残ります。

07最小構成で試す方法

  1. 昨年度に改定したお知らせから5本を選び、改定の前と後の原文と、それぞれの訳文を用意する
  2. 用語集の最初の版として、その5本に出てくる税・保険の用語を30語ほど拾い、いまの訳文で使われている訳を言語ごとに並べる
  3. 改定で変わった段落だけを、記号に置き換えたうえで、庁内で利用が認められた生成AIの画面に貼り、第7章の指示で1言語ずつ訳させる
  4. 出てきた訳と逆訳を、当時の発注で届いた訳文と並べる
  5. 母語話者に「どちらが自然か」「用語は合っているか」「足された文や落ちた条件はないか」を見てもらう
出てきた内容判断
変わった段落の訳が、用語集どおりで、前後の段落と言い回しが合う差分の取り方と版の管理の表を作る段階に進む
原文に無い説明が足される、条件が落ちる指示の書き方と逆訳の確認で直る。構成は有効
用語の訳を母語話者が1つに決められない用語集を先に作る。 AIの問題ではない

5本は、改定の小さいものと大きいものを混ぜてください。 1段落だけ変わったものと、制度の改正で数段落が足されたものでは、前後の段落を参考に渡す効き方が違います。

3行目が出ることは珍しくありません。 失敗ではなく、訳が揃わなかった理由が1つ分かったということです。 用語を決める会を校閲者と1回開くだけで、翻訳を誰がしても揃う土台ができます。

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

問題対策
原文に無い説明が足される指示で禁じ、逆訳で足された文が無いかを確かめる
減免や猶予の条件が省かれる「条件を省略しない」を指示に書き、逆訳で条件の数を原文と比べる
日付や金額が言語の中で揺れる記号に置き換えて訳させ、プログラムが戻す
用語集に無い用語にAIが訳を作る新しい用語は[]で残させ、校閲者が決めて用語集に足す
逆訳の欄に原文が入る逆訳と原文が同じものに印を付ける
変わっていない段落まで訳が変わる差分の段落だけを訳させ、前後の段落は参考として渡す
句読点の違いだけで訳し直しになる正規化してから差分を取る
用語集を全部渡して、関係の無い訳に引きずられる段落に出てくる用語だけを引いて渡す
全面改定を差分で訳して言い回しが揃わない段落の半分以上が変われば全文を新規として扱う
母語話者の確認を省いて公開する承認の前に校閲の結果を必須にする
消えた段落の訳が残る差分の「消えた」を、訳文の版にも同じく反映する
窓口の名前が訳だけになり、庁舎の表示と見比べられない固定の表記の一覧から、日本語の名前を括弧で添えて戻す

上の2行が、この構成の失敗のほとんどです。 どちらも「住民に分かりやすくしよう」とするAIの善意から出発しています。市が出す税と保険の文書は、原文どおりの条件を、原文どおりの範囲で伝えることがいちばん大事です。 足すことと省くことを、指示と逆訳の両方で止めます。

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

この構成で扱うデータ: 税と国民健康保険・国民年金のお知らせの文例、用語集、窓口と施設の名前です。個人宛ての通知の本文や、住民の氏名・税額は扱いません。

  1. 個人宛ての通知を渡さない … 帳票のシステムで氏名と税額を差し込んだあとの通知は、この構成に入れません。訳すのは文例だけで、差し込みは帳票のシステムが行います
  2. 公開前の改定の内容を扱う … 改定の原文は、公開の前の情報です。Azure OpenAI のリソースは庁内で利用が認められたものを使い、原文のフォルダと版の表への権限は係と担当課に限ります
  3. 機械の訳をそのまま公開しない … 母語話者の校閲を承認の条件にします。校閲を経ていない訳文が、ホームページに出る経路を作りません
  4. 訳文の位置づけを示す … 多言語版は日本語の原文の内容を伝えるためのもので、解釈に違いがあれば日本語の原文が優先する旨を、市の方針として各言語版に添えるかどうかを決めておきます
  5. 用語集を市の資産として管理する … 用語集は、翻訳の委託先が変わっても使い続ける市のものです。誰がいつどの訳に決めたかを残し、委託先の中にだけ置かないようにします
  6. 判断をAIに寄せない … どの言語で出すか、どの文書を多言語にするか、訳文を公開してよいかは担当課が決めます

誤りが起きた場合のリスクは、期限や金額や条件が違って伝わり、住民が納付や手続きの機会を失うことです。 減免や徴収猶予の案内は、期限を過ぎると申請できなくなるものがあり、訳の誤りが住民の負担に直結します。 記号の置き換えと照合で数字の誤りを、逆訳と校閲で意味の誤りを止めます。税と保険のお知らせでは、間違った訳は訳さないことより重い結果になります。

10まず何から始めるか

1週目:用語集の最初の版を作る

いまある4言語の訳文から、税・保険・年金の用語を30語ほど拾い、言語ごとに使われている訳を並べます。 母語話者の校閲者に、1つに決めてもらいます。

2週目:5本で試す

昨年度に改定したお知らせ5本の、変わった段落だけを訳させ、当時の訳文と並べて校閲者に見てもらいます。原文に無い説明が足されていないか、条件が落ちていないかを最優先で見ます。

3週目:段落と版の表を作る

よく使うお知らせ10本について、原文を段落に分け、段落ごとに承認済みの訳を並べた版の表を作ります。ここが差分の比較の相手になります。あわせて、言語ごとの呼びかけ方と日付の書き方の取り決めを、校閲者と1枚にまとめます。

4週目:中継の処理を作る

段落の差分、記号への置き換え、用語の引き当て、Azure OpenAI の構造化出力の呼び出し、照合を作り、係が原文を渡すと変わった段落の訳と照合の結果が返る形で使い始めます。

2か月目: フォルダへの保存を起点にした自動の起動と、校閲者への確認表を足します。3か月目以降: 対象のお知らせを全部の版の表に載せ、1件60分が何分になったかを実測します。原文の改定から4言語の版が出るまでの日数が縮み、同じ用語がどの文書でも同じ訳になった時点で、この構成は完成です。


11関連ユースケース

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

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

技術仕様確認日:2026-10-06/最終更新:2026-10-07
確認した内容情報源確認日
構造化出力で、モデルが指定した JSON スキーマの定義に従うこと。以前の JSON モードとの違い。Chat Completions API では response_format、Responses API では text.format にスキーマを書くこと。すべてのフィールドを必須にすること。additionalProperties: false が必要なこと。文字列の pattern、配列の minItems などがサポートされないこと。列挙型がサポートされることMicrosoft Learn: Azure OpenAI で構造化出力を使用する方法2026-10-06
総務省が「地域における多文化共生推進プラン」の改訂を令和2年9月10日に公表したこと総務省: 「地域における多文化共生推進プラン」の改訂2026-10-06
改訂のポイントに「ICTを積極的に活用し、行政・生活情報の多言語化を推進」が挙げられていること。改訂後の施策の柱の1つが「行政・生活情報の多言語化(ICTを活用)、相談体制の整備」であること総務省: 「地域における多文化共生推進プラン」改訂のポイント2026-10-06

どの言語で出すか、訳文を公開してよいかは、担当課が判断してください。 本記事は公開仕様で確認できた範囲だけを扱っています。

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

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

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

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