「高台に避難してください」は届いているのか？ 防災情報を「やさしい日本語」にLLMで変換して公的ガイドラインで機械採点してみた

はじめに

在留外国人は2025年末で412万5,395人、初めて400万人を超えました¹。一方で、災害時の防災無線や自治体サイトは今も「直ちに身の安全を確保してください」という日本語で書かれています。この文、日本語を勉強中の人に届くでしょうか。

私はデータ分析を仕事にしているエンジニアです。「やさしい日本語」への書き換えは自治体の現場では人手が足りず追いついていない、という話を知り、これはLLMの出番では？と思って検証しました。この記事では、さくらのAI Engineの5モデルに実在の防災文面8本を「やさしい日本語」へ変換させ、公的ガイドライン由来の10項目チェックで機械採点した結果を書きます。

対象読者: LLMの日本語運用・評価設計に興味があるエンジニア、自治体・防災×ITに関わる人

忙しい人向けの結論です。

発見	内容
最優秀は gemma-4-31B	ガイドライン準拠率88%。79%の試行で自発的に分かち書きまでした
国産 llm-jp は「取説」が違った	systemプロンプトだと準拠率31%（指示を無視して防災マニュアルを自作）。同じ指示文をuserメッセージに移すと82%に跳ねた
思考型モデルは防災に向かない	Kimi-K2.6とQwen3.6は応答中央値が14〜16秒。速報用途では厳しい
全モデル共通の弱点	「漢字は1文に4字まで」だけは最高でも42%しか守れない

参考文献

まず一次情報から読みたい人向けに、この記事の土台を先に置いておきます。

「やさしい日本語」とは何か、なぜ防災で必要か

「やさしい日本語」は、日本語に不慣れな人にも伝わるように語彙と文法を制限した日本語です。起点は1995年の阪神・淡路大震災でした。このとき外国人の死者率・負傷者率は日本人の約2倍にのぼり（原典は都市防災研究所の1995年調査。出入国在留管理庁・文化庁のガイドラインにも「日本人の死傷者は約1%、外国人の死傷者は2%以上」として掲載されています²）、「英語よりも前に、簡単な日本語で伝えるべきだ」という研究が弘前大学の社会言語学研究室を中心に進みました。

「外国人には英語でしょ」と思っていませんか？　私も最初そう思っていました。実際には、在住外国人が情報発信に希望する言語は「やさしい日本語」が76%で英語の68%を上回ります（東京都の2018年ヒアリング調査、n=100³）。国籍が多様化した結果、英語一本より「簡単な日本語」のほうが多くの人に届くという逆転が起きています。

そして2024年の能登半島地震では、被災した奥能登6市町に約1,600人の外国人が暮らしていたにもかかわらず、「避難所で多言語表示を見たと答えた人はひとりもいなかった」という支援者の報告があります⁴。ガイドラインも書き換え例集も整備されているのに、災害の現場で運用が追いつかない。ここが自動化で埋めたい隙間です。

検証の設計

やったことの全体像です。

題材にした防災文面

気象庁の特別警報の呼びかけ文、神戸市の防災行政無線の放送文例、政府広報オンラインの避難指示文例から、実在の8本を使いました⁵。たとえばこれです。

これまでに経験したことのないような大雨となっています。命の危険が迫っているため直ちに身の安全を確保しなければならない状況です。特別警報が発表されてから避難するのでは手遅れとなります。

（気象庁が2026年8月に千葉県へ大雨特別警報を発表した際の呼びかけ文）

モデルと条件

さくらのAI Engineで使える5モデルを対象に、各文面×3試行で変換させました。

• llm-jp-3.1-8x13b-instruct4（国産）
• gpt-oss-120b
• Kimi-K2.6（preview）
• Qwen3.6-35B-A3B（preview）
• gemma-4-31B-it（preview）

後述する理由で、llm-jpだけ「systemプロンプトで指示」「userメッセージに指示を埋め込み」の2条件を走らせたため、合計6条件×8文面×3試行＝144リクエストです。チャット補完の無償枠（執筆時点で月3,000リクエスト）の5%ほどで収まりました。

採点方法

出入国在留管理庁・文化庁のガイドラインと、弘前大学の増補版ガイドラインにある定量基準を、機械チェックできる10項目に落とし込みました。

チェック項目	根拠
一文の平均が24拍以内	弘前大「一文は24拍程度」
最長文も30拍以内	弘前大「長くても30拍以内」
漢字は1文に4字以内（全文の最大値で判定）	弘前大「漢字は1文に3〜4字程度」
難語なし（説明付きは可）	両ガイドライン「難しい言葉を避ける。重要語は説明を付ければ可」
カタカナ語なし（テレビ等の定着語は除外）	入管庁「外来語はできる限り使わない」
二重否定なし	両ガイドライン
尊敬語・謙譲語なし	入管庁「丁寧語のみ」
受身・使役なし	入管庁「できる限り使わない」
曖昧・推測表現なし	弘前大「おそらく等を使わない」
「ましょう」なし	弘前大「勧誘の意味があるため指示には使わない」

「拍」はひらがな1文字ぶんの音の単位です（「余震」は「よしん」で3拍）。文字数だと漢字の分だけ短く見えてしまうので、形態素解析器fugashiでカナ読みを取って拍数を数えています。「警戒レベル4」の「4」のように読みが取れない数字は、桁ごとの読みの拍数で補っています。受身・使役の検出も、当初は「される・られる」の正規表現で書いていましたが、それだと「書かれる」「と思われる」のような五段動詞の受身を全部見逃すことに途中で気づき、UniDicの助動詞判定（れる・られる・せる・させる）に作り直しました。

scorer.py（抜粋）

def mora_count(text: str) -> int:
    total = 0
    for word in TAGGER(text):
        kana = word.feature.kana or word.surface
        total += sum(1 for ch in kana if ch not in SMALL_KANA and (
            "ァ" <= ch <= "ヴ" or "ぁ" <= ch <= "ゔ" or ch == "ー"))
    return total

難語チェックには防災文に頻出する36語（避難・発令・氾濫・身の安全など）のリストを使い、ガイドラインが「余震＜あとから来る地震＞のように説明を付ければ使ってよい」としているのに合わせて、直後に説明が付いている場合は違反に数えない実装にしました。

補助指標として、日本語教育の研究で使われる読みやすさ指標jReadability⁶も併記します。ただしこの指標には設計段階で気づいた弱点があって、「高台に避難してください。」が5.87、それをひらがなに開いた「たかいところににげてください。」が4.40と、漢語まみれの原文のほうが「易しい」判定になります。jReadabilityは文の長さや品詞構成から計算する指標で、「避難」という単語自体の難しさは見ていないためです。単一指標を鵜呑みにせず、語彙ベースのルールチェックと組み合わせる設計にしたのはこの発見がきっかけでした。

結果

総合準拠率

優勝はgemma-4-31Bの88%でした。しかも指示していないのに79%の試行で分かち書き（文節ごとに空白を入れる、やさしい日本語の推奨表記）まで自発的にやってきます。

とても 大きな 津波（つなみ）が 来ます。
すぐに 高い ところへ にげてください。

読み仮名まで付けています。正直、実務にそのまま置けるレベルで驚きました。

国産llm-jpに何が起きたか

グラフの最下段、llm-jp-3.1のsystemプロンプト条件は準拠率31%です。何が起きたかというと、変換をせずに防災マニュアルを書き始めるのです。「大津波警報。ただちに高台に避難してください。」を渡した結果がこれでした。

了解しました。大津波警報が発令されているため、直ちに高台へ避難する必要があります。以下の手順に従って行動してください。

1. 冷静になる: まず、落ち着いて状況を把握しましょう。……

津波が来ているのに5項目の心得を諭し始めます。「〜しましょう」も連発でガイドライン違反です。

ところが同じ指示文をsystemロールではなくuserメッセージの冒頭に移すと、準拠率は82%まで跳ねました。51ポイント差です。最初この差を見たとき「max_tokensも違うから交絡してるのでは」と疑い、生成条件（max_tokens・temperature）を完全に揃えて両条件を取り直しましたが、差はほぼそのまま残りました。おまけにuser指示条件は応答中央値0.62秒で全モデル最速、出力はひらがな中心という優等生ぶりです。国産モデルは日本語が下手なのではなく、指示をどのロールに置くかというプロンプト構成に極端に敏感なだけだった——「モデルごとに取扱説明書が違う」ことを一番わかりやすく教えてくれた実験でした。

ただし手放しでは褒められません。llm-jp（user指示）の出力には「すぐに たかくて あぶなくない ばしょに げしてください。」という脱字（「にげて」の「に」欠落）がありました。形式チェックはすり抜けるのに、災害時には致命的になりうる誤りです。これは後述の「限界」に直結します。

項目別に見る

ヒートマップにすると各モデルの苦手がはっきり出ます。全モデル共通で崩れるのは「漢字は1文に4字以内」で、最高のllm-jp（user指示）でも42%、他は21〜25%、原文に至っては0%です。漢字密度は「語彙を言い換える」だけでは下がらず、ひらがな書きに開く判断が要るので、いちばん人間の editorial な作業に近いのだと思います。次いで苦しいのが受身の排除（最高79%）で、Kimiの「水が来ると思われる場所」のような、一見自然だがガイドライン違反の受身が残ります。

一文の短さはどのモデルもほぼ完璧でした。原文の平均21.5拍に対し、変換後は16〜18拍台に収まっています。

jReadabilityでも、暴走したllm-jp（system）を除く5条件が原文の4.39より易しい方向（5前後、高いほど易しい）に動いており、ルールベース採点と学術指標の傾向がおおむね一致したのは設計として安心材料でした。

応答速度という盲点

思考型のKimi-K2.6とQwen3.6は品質こそ82〜85%と健闘しているものの、応答中央値が14〜16秒です。緊急速報の変換パイプラインに組むなら、この待ち時間は無視できません。品質・速度・分かち書きまで揃うgemma-4か、爆速のllm-jp（user指示）＋人間チェックの二択かな、というのが現時点の肌感です。

変換例の比較

「緊急放送、緊急放送。○○川が増水し氾濫するおそれが高まったため、○○地区の洪水浸水想定区域に警戒レベル4避難指示を発令しました。今すぐ避難してください。」をどう料理したか、上位2モデルを並べます。

モデル	出力
gemma-4-31B	大切なお知らせです。○○市からです。○○川の水が増えました。町に水が来るかもしれません。○○地区に住んでいる人は、今すぐ安全な場所へにげてください。
Kimi-K2.6	きんきゅうのお知らせです。○○市です。○○川の水がたくさんふえました。あふれる危険が高くなりました。○○地区で、水が来ると思われる場所の人は、今すぐ安全な場所に行ってください。

「氾濫するおそれ」を「水が来るかもしれません」に開くのは、ガイドラインの「推測表現は『かもしれません』を使う」という規定どおりで、ここまで拾えるのかと唸りました。

ハマったポイント

再現する人のために、詰まった順に書いておきます。

1つ目はQwen3.6で、message.content がNoneで返ってきて NoneType has no attribute 'strip' で落ちました。思考型モデルが考えている間に max_tokens を使い切ると、本文が空のまま finish_reason: length で返ってくるためです。max_tokensを4,000に上げて解決しましたが、contentがNullになりうる前提のハンドリングは思考型モデル時代の必須装備だと思います。

2つ目はその対応の巻き添えで、llm-jpだけHTTP 400が全滅しました。プロンプト長＋max_tokens 4,000がコンテキスト上限を超えていたのが原因です（このモデルは他より上限が小さい）。同じmax_tokensを全モデルに一律で撒くと、上限が小さいモデルだけ400で死ぬ。マルチモデル検証あるあるだと思います。最終的にmax_tokensはモデル別の辞書で持たせました。

3つ目はKimi-K2.6の尻切れです。初回はmax_tokens 2,000で回していたため、completion_tokens がちょうど2,000に張り付いた応答が数件混ざっていました。文末が「にげるの」で切れているデータをそのまま採点すると点が壊れるので、finish_reason が length の応答は保存せず再取得する実装に直しています。

4つ目は自分の採点器のバグで、これが一番効きました。「漢字は1文に4字以内」を最初は全文の平均値で判定していて、長い1文の漢字ラッシュが短文に薄められて合格扱いになっていたのです。文ごとの最大値で判定し直したら、全モデルの準拠率が5〜7ポイント下がりました。評価器を作る側が採点を甘くするバグを仕込むと、モデルが実力以上に良く見える。ベンチマーク自作の一番怖いところだと思います。

この検証の限界

正直に書いておきます。

• 採点しているのは「形式」だけです。llm-jpの脱字のように、情報の正確さ・欠落は今回の10項目では検出できません。ガイドライン自体も最終ステップに「日本語教師や外国人当事者によるチェック」を置いており、機械採点はその手前の一次フィルタと考えるべきです
• 各条件n=24（8文面×3試行）の小規模検証です。文面の選び方にも私の裁量が入っています
• 受身の検出は助動詞（れる・られる・せる・させる）の形態素判定ですが、受身・尊敬・可能・自発の用法までは区別していません。ガイドラインの趣旨（多義的で分かりにくい形を避ける）には沿うものの、厳密には過剰検出があり得ます
• llm-jpのsystem条件とuser条件は生成条件を揃えて比較しましたが、指示文の位置以外に「書き換え対象を示す1文」の有無という差も含みます。厳密には「ロール単独の効果」ではなく「プロンプト構成の差」です

それでも、採点基準と全コード・全変換結果を公開できる形にしたので、誰でも文面を差し替えて追試できます。

なぜ、さくらのAI Engineでやったのか

この検証、実は技術的な工夫より「段取りの省略」に一番助けられています。gemma・Kimi・Qwen・gpt-oss・llm-jpは開発元がバラバラで、普通に横断比較しようとするとプロバイダーごとの契約・認証・SDKの差異吸収から始まります。今回はOpenAI互換の同一エンドポイントに5モデルが同居しているので、リクエストの model の文字列を差し替えるだけで、6条件×144本の変換を1本のコードと1つのAPIキーで回せました。モデル間比較の実験は「条件を揃える」ことが命なので、呼び出し経路が最初から揃っているのは設計として大きな利点でした。

もうひとつは、国産のllm-jpをマネージドAPIとして呼べる場所が、私の知る限りほとんどないことです。この記事のいちばんの発見——指示の置き場所ひとつで準拠率が51ポイント変わる——は、llm-jpを比較対象に入れられたからこそ出てきたものでした。ローカルGPUを用意せずに国産モデルを海外オープンモデルと同じ土俵で測れたことが、この記事の背骨になっています。

まとめ

「国産モデルだから日本語が得意」という雑な期待は、systemプロンプト一発で崩れました。かわりに得たのは「モデルごとに取扱説明書が違うだけで、正しく渡せばどれも実用圏に入る」という手応えと、「漢字密度だけは全員苦手」という次の宿題です。

もうひとつ。自治体の防災文面や住民向け文書は、外部に出しにくい情報を含むことがあります。国内データセンターで完結するAPIでこの品質が出るなら、行政系の現場でも検討の土俵に載せやすいはずです（もちろん所在地だけで安心はできないので、実データを入れる前に利用規約・データ保持の扱い・組織の情報区分ルールの確認は必要です）。今回の検証本体は144リクエスト、試行錯誤の再取得を含めても月3,000リクエストの無償枠（執筆時点）の1割弱でした。興味が湧いた人は自分の街の防災ページで追試してみてください。結果が違ったらぜひ教えてほしいです。

次は含意判定を使った「情報が欠落していないか」の自動チェックを足して、形式＋内容の二段構えにするつもりです。

1. 出入国在留管理庁「令和7年末現在における在留外国人数について」 https://www.moj.go.jp/isa/publications/press/13_00062.html ↩

2. 出入国在留管理庁・文化庁「在留支援のためのやさしい日本語ガイドライン」p.4 https://www.moj.go.jp/isa/content/930006072.pdf ↩

3. 東京都国際交流委員会「東京都在住外国人向け情報伝達に関するヒアリング調査」(2018)。前掲ガイドラインp.3に掲載 ↩

4. 自治体国際化フォーラム2024年5月号 特集「災害時における外国人支援」（田村太郎） https://www.clair.or.jp/j/forum/forum/pdf_415/04_sp.pdf ↩

5. 気象庁報道発表(2026-08-13) https://www.jma.go.jp/jma/press/2608/13a/20260813_tokukei.html 、神戸市防災行政無線放送文例 https://www.city.kobe.lg.jp/documents/42621/housoubunrei.pdf 、政府広報オンライン https://www.gov-online.go.jp/article/201906/entry-7786.html ↩

6. jReadability（李在鎬・長谷部陽一郎による日本語読みやすさ指標） https://jreadability.net/ ↩