外国人の住民・利用者向けのお知らせを、やさしい日本語に書き換えて点検する

処理の起点を決める

受付台帳に元の文が貼られ、「書き換え」の欄に印が付いたことを起点にします。 貼った瞬間に動かさないのは、元の文の修正が続くことがあるからです。依頼元から「さっきの文、日付を直しました」と届くたびに書き換えが走ると、どれが最新か分からなくなります。

1日1回まとめて処理する形にもしません。 行事のお知らせは、依頼が来てから掲示までが数日しかないことがあります。担当者が印を付けたらすぐに動き、数分で点検結果まで台帳に戻る形にします。

同じ行で2回目以降に動かしたときは、前の結果を消さずに版を上げます。 元の文が直った理由が点検結果の source_issue だった場合、その経緯が残ります。

入力データを集める

質を決めるのは、下の2つです。 基準の一覧が無いと、AIは自分なりの「やさしさ」で書き換え、担当者ごと、お知らせごとに言い方がばらつきます。第3章の（b）が、AIに置き換わっただけになります。

言い換えない語の一覧は、とくに大事です。 「在留カード」「国民健康保険」「マイナンバーカード」は、窓口で提示を求められる書類や制度の名前です。言い換えてしまうと、住民は窓口でその語を聞いても、お知らせの話だと結び付けられません。 残したうえで、「在留カード（日本に住む外国人が持つカード）」のように短い説明を添えます。

基準の一覧は、たとえば次のように作ります。 番号を付けて、指摘には必ずその番号を書かせます。

この表の数字や語は例です。 実際の基準は、ガイドラインを読んだうえで、自組織の読み手に合わせて決めてください。

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

台帳のスクリプトが、印の付いた行の元の文と付帯情報、基準の一覧、言い換えない語の一覧を読み、3種類の呼び出しを順に行います。

③は同じ指示で2回呼びます。 1回目は元の文だけ、2回目は書き換えた案だけを渡します。互いの文を見せないことが、この呼び出しの要点です。

ふりがなは、漢字《かんじ》 のように、決まった書き方で返させます。 画面上ではふりがなとして表示し、機械の点検では 《》 の有無で数えます。書き方が決まっていないと、機械で数えられません。

AIへ渡す前に整形する

1. 表や箇条書きをほどく … 元の文の表は「項目：値」の行に直します。表のまま渡すと、どの値がどの項目のものかが崩れます
2. 全角と半角をそろえる … 数字と時刻の表記を半角にそろえます。突き合わせで「１０日」と「10日」を別物と判定させないためです
3. 元号と西暦の対応を付ける … 元の文に元号があれば、台帳の発行年から西暦を横に添えます
4. 問い合わせ先の電話番号を控える … 抜き出しとは別に、元の文から電話番号の並びを機械で拾っておきます
5. 長さを確かめる … 数ページに及ぶ要項は、見出しごとに分けて処理します
6. 個人名を外す … 担当者の氏名が書かれていれば、課の名前に置き換えてから渡します

4番目は、突き合わせの答え合わせに使います。 電話番号は1文字違っても意味が変わり、しかも書き換えで「お問い合わせは市民課へ」とだけ残されがちです。AIの抜き出しと別に、機械で拾った番号と照らします。

5番目は、応答が途中で切れるのを防ぐためです。 出力の上限に達した応答は、状態が incomplete として返るとドキュメントに書かれています。切れた結果を、そのまま点検結果として台帳に書かないでください。

AIに処理させる

させるのは、書き換えた案を作ること、数えられない基準について番号つきで指摘すること、文から要素を抜き出すことの3つです。

①の右端が大事です。 「申請は原則として本人が行ってください」の「原則として」が何を指すのか、元の文だけでは分からないことがあります。AIがそれらしく書き換えると、元の文に無い条件ができあがります。 分からない箇所は、分からないまま担当者に渡します。

③では、「条件」と「可否」を要素として拾わせます。 「ただし〜を除く」「〜の方に限り」は条件、「代理人でも申請できます」「当日の申し込みはできません」は可否です。書き換えでいちばん落ちやすく、落ちたときの影響がいちばん大きいのが、この2種類です。 二重否定を肯定に直す書き換えでは、可否が逆になる事故が起きます。

いちばん起きやすい失敗は、1行目です。 元の文の「10月10日（木）」が発行年の暦では金曜日だったとき、AIは気を利かせて「10月10日（金曜日）」と書き換えます。住民にとってはどちらが正しいか分からず、元の日本語版を見た人と、やさしい日本語版を見た人とで、来る日が分かれます。

指示内容を固定する

③要素の抜き出しの指示文です。 ①と②も同じ考え方で書きますが、突き合わせの質を決めるのはこの指示です。

あなたは市役所で、住民向けのお知らせから、
読み手の行動に関わる情報を漏れなく拾い出す係です。
渡された文章「だけ」を読んで、書かれている要素を一覧にしてください。

【拾う要素の種類】
- date ........ 日付（「10月10日」「毎月第2火曜日」など）
- weekday ..... 曜日（日付に添えて書かれているもの）
- time ........ 時刻・時間帯
- amount ...... 金額・料金・手数料
- place ....... 場所・会場・窓口
- item ........ 持ち物・提出する書類
- deadline .... 期限・締め切り（「必着」「消印有効」などの条件を含む）
- target ...... 対象者（年齢・住所・資格など）
- condition ... 条件・例外（「ただし」「〜に限り」「〜を除き」）
- permission .. できること・できないこと、必要・不要
- contact ..... 問い合わせ先（課の名前、電話番号）

【厳守事項】
- 書かれていない要素は出さないでください。推測で補わないでください。
- value には、文章に書かれている言葉をそのまま写してください。
  言い換え・要約・訂正をしないでください。
- 日付と曜日が合っていないように見えても、直さずにそのまま写してください。
- normalized には、表記をそろえた形だけを入れてください。
  日付は「月-日」、時刻は「時:分」、金額は円の整数です。
  計算や推定で作った値は入れず、そろえられない場合は null にしてください。
- permission は、できる／できない、必要／不要のどちらかを polarity に入れてください。
  二重否定の文は、文字どおりに読んで判断し、判断に迷えば unclear にしてください。
- 1つの文に複数の要素があれば、すべて別々に出してください。
- evidence には、その要素を拾った文をそのまま写してください。
- この文章が元の文か書き換えた文かは考えないでください。

【文章】{text}
【発行年】{year}

「言い換え・要約・訂正をしない」を明記しないと、抜き出しの段階で意味が整えられます。 書き換えた案から抜くときに、元の文に近い言葉へ戻してしまうと、落ちた情報が一致として出てきます。

最後の1行も、意図して入れています。 元の文か書き換えた文かを知らせると、AIは片方を「正」として読みます。どちらの文も同じ目で読ませるために、役割を伏せます。 台帳の側では、どちらの呼び出しかを別の列で持っています。

①の書き換えの指示には、少なくとも次の3行を入れます。 「元の文の誤りに気づいても直さず、［要確認］ を付けてそのまま残してください」「元の文に無い情報を足さないでください」「言い換えない語の一覧にある語は、そのまま使い、かっこで短い説明を添えてください」。

出力形式を固定する

③の抜き出しは、構造化出力で次の形に固定します。

{
  "facts": [
    {
      "type": "date | weekday | time | amount | place | item | deadline | target | condition | permission | contact",
      "value": "",
      "normalized": "string または null",
      "polarity": "allowed | not_allowed | required | not_required | unclear | null",
      "evidence": ""
    }
  ],
  "unclear_parts": [ { "text": "", "reason": "" } ]
}

type と polarity は enum で選択肢を固定し、すべての項目を required、additionalProperties を false にします。normalized と polarity は、該当しないときに null を入れる形で、省略を許します。

突き合わせは台帳のスクリプトが行い、次の形で書き戻します。

source_issue は、元の文の側の問題です。 書き換えた案を直しても解決しないので、ほかの4つと分けて、依頼元に返す一覧に載せます。

②の基準の点検は、rule_id、evidence、suggestion を並べた形で受け取り、rule_id が基準の一覧に無い指摘は捨てます。 機械で数えた R01〜R03 の結果と同じ表に並べ、担当者は文ごとに、何番の基準に引っかかったかを一度に見られます。

システムへ連携する

ホームページへの自動掲載はしません。 この構成が出すのは、書き換えた案と点検結果までです。書き込み先を台帳だけにしておけば、誤った文が住民の目に触れる経路はありません。

基準の一覧は、呼び出しのたびに読み直します。プロンプトの中に基準を直接書き込むと、基準を変えたときに直し忘れます。

人が確認する

担当者は、書き換えた案をすべて全文読みます。 省くのは、頭から疑いながら読む手間だけです。

1. source_issue を先に見る … 元の文の問題です。依頼元の課に確認を頼み、返事を待つあいだに残りを進めます
2. dropped と changed を直す … 落ちた要素を戻し、変わった値を元の文で確かめます。条件と可否は必ず元の文と並べて読みます
3. 基準の指摘を見る … 番号ごとに直すか残すかを決めます。直さない判断をしたら、理由を台帳に一言書きます
4. 全文を通して読む … 一覧に出ていない読みにくさを探します
5. 依頼元の課に戻す … 書き換えた案と点検結果の一覧を一緒に送ります

2番目の条件と可否は、飛ばさないでください。 「当日の申し込みはできません」が「当日も申し込みができます」に変われば、窓口に人が並びます。

依頼元の課に点検結果を一緒に送るのは、確認を速くするためです。 依頼元は書き換えた案を1行ずつ元の文と比べる必要がなく、dropped と changed が直っているかを見れば済みます。

できれば月に数本、日本語を母語としない住民や職員に読んでもらってください。 基準を満たしていても伝わらない言い方は、この構成では見つかりません。

例外に対処する

上の2行は、まれでも手順を決めておきます。 どちらも、結果が壊れているのに台帳に何か書かれてしまうのがいちばん困ります。書き戻すのは、状態が完了のものだけにします。

記録を残す

• 元の文と、その版（依頼元が直した回数）
• 書き換えた案と、担当者が直した後の最終版
• 3種類の呼び出しの応答の全文
• 突き合わせの結果（result の一覧）と、機械で数えた R01〜R03 の結果
• そのとき使った基準の一覧と言い換えない語の一覧の版
• 担当者が直した箇所と、直さなかった指摘の理由
• source_issue を依頼元に伝えた日と、その返事

5つ目で一覧の版を残すのは、基準が変わるからです。 一文の長さの上限を変えれば、過去のお知らせの指摘の意味も変わります。当時の基準が残っていないと、「なぜこの文は通ったのか」に答えられません。

6つ目は、基準の見直しに使います。 毎月同じ番号の指摘が「直さない」で残るなら、その基準は現場に合っていません。