Skip to Content
Docs04. 評価日本語品質の評価
中級evaluationjapanese更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

日本語品質の評価

この記事の目的

英語中心の評価では見えない日本語固有の品質(敬語・文体・表記)を測る評価を設計できるようになります。「意味は合っているが日本語として不自然」「敬語が崩れている」「文体が揺れる」といった、英語ベースの評価をすり抜ける品質問題を捕まえられる状態がゴールです。

対象読者

  • 日本語で応対する Agent の品質を評価したいが、英語系の評価指標では不十分と感じているエンジニア
  • 「意味の正しさ」は測れているが、日本語としての自然さ・適切さを評価に組み込みたい人

前提知識

  • Agent 評価の基礎 — 何をどう測るか(本記事は日本語固有の観点の追加)
  • LLM-as-a-Judge — 開放的な出力の採点(本記事は日本語採点の注意点)

本文

概要: 分担と「日本語固有」の射程

対象正本本記事
何を測るか(評価対象・採点・データセット)Agent 評価の基礎—
判定器(judge)の設計と検証LLM-as-a-Judge—
属性・グループの公平性公平性・バイアスの評価—
日本語固有の品質軸と評価設計本記事敬語・文体・表記・judge の日本語能力・自動チェック

本記事は「日本語として適切か」の評価を扱います。翻訳品質そのもの(原文への忠実さ)は別領域で、日本語の産出品質に絞ります。英語のタスクで設計した評価を流用する場合も、日本語の待遇表現・表記などが評価条件に含まれるか確認します。

日本語固有の品質軸

英語評価には現れない、日本語特有の品質軸があります。

軸見るもの崩れの例
敬語・待遇表現相手・場面に合った敬語か不適切な二重敬語、尊敬語と謙譲語の取り違え、場面に合わないタメ口
文体一貫性「です・ます」と「である」が混ざっていないか1 つの回答内で敬体と常体が揺れる
表記ゆれ・全半角用語・記号の表記が統一されているか「サーバ/サーバー」混在、全角半角の不統一
固有名詞・読み人名・地名・製品名の表記と読みが正しいか誤変換、読みの誤り
不自然な直訳調場面に合った自然な表現か不要に繰り返す可能表現、意味を曖昧にする受動態。表現単体を一律に禁止しない

これらは意味の正確さだけでは判定しにくい軸です。用途の文体規定と、日本語の用法上の誤りを区別して評価条件にします。例えば 文化審議会「敬語の指針」 は、二重敬語のうち「お伺いする」等が慣習として定着していることも示しています。二重敬語や敬体・常体の混在を単純に全件不正解とせず、慣用表現・引用・見出しなどの例外を定義します。

評価データの作り方

日本語品質の評価データは、日本語の実タスクから作ります。

  • 実際の日本語入力から採取する: 英語データセットの機械翻訳ではなく、実際に日本語で来る依頼・応対ログから作ります(翻訳データは日本語として不自然な入力になりがちです)
  • 崩れやすいケースを含める: 敬語が要る場面、長文で文体が揺れやすいケース、固有名詞の多いケースなど、日本語品質が崩れやすい入力を意図的に集めます
  • 期待値は「満たすべき条件」で: 「引用を除く本文は敬体」「相手・行為者に合った敬語」「指定表記に従う」など、適用範囲と例外を含む条件で書きます(Agent 評価の基礎)。この条件表は自社用途向けの評価設計であり、敬語の指針自体が LLM の採点基準を定めているわけではありません

judge の日本語能力を検証する

日本語の品質を LLM に採点させる(日本語 judge)場合、その judge が日本語の品質を正しく判定できるかを検証する必要があります。

  • 生成能力の順位で judge を決めない: 対象の敬語・文体・表記を判定できるか、日本語の人手ラベルで確認します。被評価モデルより大きいモデルでも、誤答を通す・適切な表現を落とす可能性があります。必要なのは対象の採点基準で検証された判定能力です
  • 人手ラベルとの一致を測る: 日本語ネイティブが付けた品質ラベルと judge の判定の一致率を測り、judge を検証してから使います(LLM-as-a-Judgeの judge 検証)。この検証を日本語で行うことが肝心です
  • 盲点の共有に注意: judge と被評価モデルが同系なら、同じ日本語の癖(同じ不自然さ)を「自然」と判定しかねません。可能なら別系統を使います

自動チェックと judge の分担

日本語品質のすべてを judge に回す必要はありません。機械的に測れるものはコードで測ります。

  • 自動チェックが向くもの: 指定用語・全半角・禁止表記など、適用範囲を機械的に定義できる条件です。文体判定は引用・見出しの除外や誤検知の確認が必要なため、曖昧な候補は人または検証済み judge に回します(Agent 評価の基礎のコード採点)
  • judge が要るもの: 敬語の適切さ、直訳調の不自然さ、文脈に照らした自然さ。ルール化しにくい開放的な品質は judge に回します
  • 分担の原則: コードで測れる表記・形式は自動チェックに、判断の要る自然さ・適切さは検証済みの日本語 judge に、と分けます。全部を judge に回すのはコストの無駄で、逆に全部を機械ルールにするのは自然さを測れません

公開日本語ベンチマークの読み方

日本語の能力・品質を測る公開ベンチマークもありますが、エージェントベンチマークの全体像と同じ規律で読みます。

  • 公開ベンチのスコアは当たりを付けるのに使い、自社タスクの品質は自前の日本語評価セットで測ります。ベンチの入力・採点基準が自社タスクを代表するとは限らないためです
  • 具体的なベンチマーク名・リーダーボードの顔ぶれは変化が速いため、本文では帯・傾向にとどめ、選定時に最新を確認します(下記 TODO)

実務での注意点

アンチパターン

  • 英語で設計した評価をそのまま日本語に流用する → 敬語・文体・表記の崩れが素通りする → 日本語固有の品質軸を明示的に立てる
  • 英語データの機械翻訳を評価入力にする → 日本語として不自然な入力になり、実態を測れない → 実際の日本語入力・ログから評価データを作る
  • 日本語能力の低いモデルを judge にする → 敬語の崩れ・不自然さを見抜けず甘く採点する → judge の日本語能力を人手ラベルとの一致で検証する
  • 日本語品質をすべて judge に回す → 表記・形式まで judge に投げてコストを浪費する → 機械的に測れる表記・文体は自動チェックに分ける
  • 公開日本語ベンチのスコアで自タスクの品質を推定する → 分布が違い順位も入れ替わる → 自前の日本語評価セットで測る

チェックリスト

  • 日本語固有の品質軸(敬語・文体一貫性・表記・固有名詞・直訳調)を評価に立てた
  • 評価データを英語の機械翻訳でなく実際の日本語入力から作った
  • 崩れやすいケース(敬語・長文・固有名詞)を評価に含めた
  • 日本語 judge の能力を、日本語の人手ラベルとの一致で検証した
  • 表記・全半角・敬体/常体などを自動チェックで測っている
  • 判断の要る自然さ・適切さだけを検証済み judge に回している
  • 公開日本語ベンチではなく自前の評価セットを品質判断の正にしている

関連トピック

参考資料

TODO・未確認事項

公平性・バイアスの評価セクション概要