Claudeは関西弁など方言をどこまで正確に書けるか

Claudeが関西弁などの方言をどこまで正確に書き、読めるかは、Anthropicの評価表からは読み取れません。表に載っている日本語は1行だけで、翻訳された知識問題で測った数字だからです。方言で使うなら、自分の用途に合わせた小さなテストを組んで精度を測る方法が現実的です。この記事では、評価表の数字の意味、テストの組み方、関西弁を安定して出力させるプロンプトの書き方を順に扱います。

多言語の評価表は日本語を1行でしか測っていない

多言語対応のドキュメントには、英語を100%としたときの各言語の相対スコアが載っています。英語を除く14言語がゼロショットの思考連鎖評価で比べられており、日本語の行は次の2つです。

表にあるのはSonnet 4.5とHaiku 4.5の2つで、Opus 5.5やSonnet 5.5の行はありません。

評価の元になったのはMMLU(大規模マルチタスク言語理解)の英語テストセットです。これをプロの翻訳者が14言語に訳したものを使っています。関西弁など方言の問題を含むとは、多言語対応のドキュメントに書かれていません。

つまり、96.8%は「翻訳された知識問題に日本語で答える力」の目安です。方言の作文が自然か、地域特有の語彙を読み違えないかは、別の物差しで測る必要があります。

ドキュメント自身も、表に載っていない言語について「自分のユースケースに関係する言語で試すように」と書いています。方言はまさにその「試す」側に回る領域です。

日本語全般の精度を公式データから読む方法はClaudeの日本語精度を公式データとベンチマークで読むに、言語別の相対スコアの並びはClaudeの多言語性能を言語別データで見るにあります。

方言の精度は「何を測るか」で結論が変わる

「関西弁をどこまで正確に書けるか」という問いは、実は複数の問いが重なっています。測る前に分けておかないと、結果の解釈が割れます。

さらに、方言の特徴は大きく2種類に分けて考えられます。1つは語尾や助動詞のパターンです。関西弁なら否定の「〜へん」や、文末の「〜ねん」のような、文法に近い規則性のある部分を指します。もう1つは地域特有の語彙です。「ほかす」(捨てる)のような語があり、「なおす」(片付ける)のように標準語と同じ音で別の意味を持つ語もあります。

この2種類は、崩れ方も別々に現れる可能性があるため、テスト文の段階で混ざらないように作ります。「語尾は合っているのに語彙を取り違えた」のか「語彙は合っているのに口調が不自然」なのかが、混ぜると見分けられなくなるからです。

関西弁と「消滅の危機にある方言」は同じ土俵で語れない

方言といっても、話者の数や使われる場面には大きな差があります。文化庁は、ユネスコが平成21年2月に発表した危機言語の地図(第3版)に載った日本国内の8言語を紹介しています。ユネスコは「言語」と「方言」を区別せず、すべて「言語」として扱っています。

文化庁の整理では、危機の度合いは次のとおりです。

• 極めて深刻: アイヌ語
• 重大な危機: 八重山語、与那国語
• 危険: 八丈語、奄美語、国頭語、沖縄語、宮古語

日本国内の一般的な呼び方では、アイヌ語を除く7つは「八重山方言」「与那国方言」「八丈方言」「奄美方言」「国頭方言」「沖縄方言」「宮古方言」にあたります。

関西弁はテレビやインターネットで接する機会の多い方言ですが、上の一覧に並ぶ方言は事情が違います。同じ「方言対応」でも、どの方言を対象にするかでテストの組み方が変わります。話者が身近にいる関西弁や博多弁なら判定を依頼できますが、話者の少ない方言は正解を用意すること自体が難しくなります。

その場合は、ネイティブの話者や地域の研究機関に監修してもらう前提で計画を立てることになります。モデルの出力だけを根拠に、方言の正誤を判定しない方が安全です。

自分で精度を測るテストの手順

評価設計のドキュメントは、評価を作るときの基準として、具体的で測定可能な成功基準を先に決めることを挙げています。「関西弁がうまく書ければよい」ではなく、数字で言える形にします。方言のテストなら、次の手順が組み立てやすい流れです。

同じドキュメントでも、評価データには実際の利用に近い入力と、例外的な入力(エッジケース)を含めるよう説明されています。方言の場合のエッジケースは、標準語と同音の別義語、地域内の言い方の違い、くだけた口調と丁寧語の混在などです。

テスト文の設計表

テスト文は、見たい論点ごとに行を分けると結果を読みやすくなります。次の表は、関西弁を例にした設計の一例です。

行は多すぎても少なすぎても読みにくくなるため、まず10〜20文程度から始め、迷いが出た論点だけ増やすやり方が扱いやすいでしょう。

測定を自動化するときの最小構成

文が増えたら、システムプロンプトを固定して同じ入力を機械的に流します。次の例は、多言語対応ドキュメントのシステムプロンプトの書き方に沿って、応答言語と口調を指定するリクエストです。

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 2048,
    "system": "日本語で、日常会話として自然な関西弁で答えてください。",
    "messages": [
      {"role": "user", "content": "明日の会議の資料がまだ作れていません。手伝ってほしいです。"}
    ]
  }' | jq -r '.content[] | select(.type=="text") | .text'

Claude Opus 5.5やSonnet 5.5では、thinking(思考)が既定で有効です。応答の先頭が思考ブロックになる回があるため、content[0] ではなく、type が text のブロックだけを取り出しています。

入力文をファイルから読み込んでループで回し、出力を判定者に渡す表に貼り付ければ、人手の判定を最後の1段だけに絞れます。評価設計のドキュメントは、人手の採点を遅く高コストなので可能なら避けるとし、自動採点で問題数を増やす方を勧めています。方言の自然さは自動判定しにくいので、人手の判定は最後の1段に残します。読解タスクなら、正解の語義を列に持たせ、出力に含まれるかを機械的に照合する手もあります。

関西弁を安定して書かせるプロンプトの組み方

プロンプトの指針は、応答の口調を定めるには役割をシステムプロンプトに置くことと、例を添えることを挙げています。関西弁の出力にも、そのまま当てはめられます。

多言語対応のドキュメントには、言語指定はシステムプロンプトに書くと会話全体で安定する、とあります。流暢さを上げたいときは「ネイティブスピーカーのような慣用的な言い方で」と指示する方法も紹介されています。方言の場合は、この「慣用的な言い方」に当たる部分を、具体的に書きます。

システムプロンプトの例を示します。

あなたは大阪の食品メーカーの問い合わせ窓口の担当者です。
お客様には、日常会話として自然な関西弁で、丁寧さを保って答えてください。
漫才のような大げさな言い回しや、決まり文句の連発は避けてください。
 
<examples>
<example>
お客様: 賞味期限が過ぎてしもたんですが、食べても大丈夫ですか。
担当者: ご心配ですよね。期限を過ぎたものは、お召し上がりをお控えいただくようお願いしてます。
</example>
</examples>

例文は、ネイティブの話者に見てもらったものを使います。偏った例だけを並べると、意図しない癖まで出力に写ることがあるためです。

入力の書き方にも注意点があります。多言語対応のドキュメントは、テキストをローマ字やカナの転写ではなく、その言語の通常の表記で渡すと良い結果になるとしています。方言の読解テストでも、「ほかす」をローマ字にせず、普段の仮名表記で入れます。

また、ドキュメントは文化的・地域的な文脈への配慮も挙げています。方言は語彙だけでなく、どんな場面でどの程度くだけた言い方をするかまで含めて地域の文化なので、場面の指定は飾りではなく出力の質に関わる要素です。

利用者が画面で方言を選べるサービスなら、選択結果をシステムプロンプトに差し込む作り方も使えます。ドキュメントは、実行時に言語を選ばせるアプリでは、モデルの推測に任せずシステムプロンプトへ埋め込むよう説明しています。方言の選択肢にも同じ作りが当てはまります。

応答言語をシステムプロンプトで固定する書き方そのものは、Claudeの応答言語をシステムプロンプトで固定する方法で扱っています。方言の指定は、その言語固定の延長として入れる形になります。

用途ごとに見るべき点

方言の出力を業務で使うときは、用途によって見るべきリスクが変わります。

チャットボットや顧客対応では、地域語彙を含む短い定型文が確認したい箇所です。文脈の短い文では、同音の別義語や低頻度の語彙を読み違えても気づきにくくなります。運用前に想定される語彙を洗い出し、短文と長文の両方で個別にテストします。

コンテンツ制作では、読み手が違和感を持つかどうかが基準になります。方言を使う媒体では、正確さより自然さが問われるため、判定者を方言の話者にする手順がそのまま品質管理になります。

方言の読解では、書き手の意図の取り違えが実害になります。問い合わせ文の自動分類や感情分析に方言が混じる場合は、方言入りのテスト文を評価データに含めておくと、標準語だけの評価では見えない穴を見つけられます。

成功基準のたたき台には、評価設計のドキュメントが挙げる観点を借りられます。たとえば「口調と文体」は、出力が想定した読み手に合っているかを見る観点です。方言なら、お客様向けの文面で砕けすぎていないかが当てはまります。

「一貫性」は、似た入力に似た出力が返るかを見る観点です。同じ問い合わせ文を2回流して、方言の濃さが毎回大きく変わらないかを並べて見ます。判定が割れた文は、システムプロンプトか例文の側を直す手がかりになります。

専門用語や略語の読解を同じ要領で試す方法は、Claudeは金融・医療・IT業界の専門用語をどこまで正確に理解できるかにもあります。文脈の量で解釈がどう変わるかを見る点は、方言のテストと共通の考え方です。

よくある質問

方言の判定を別のClaudeに任せてもよいですか

評価設計のドキュメントには、LLMによる採点も選択肢として載っています。ただ、方言の自然さは話者の感覚に依存するため、最初は人間の判定者と並べて比べ、両者の判定が一致する範囲を確かめたうえで任せる進め方があります。

博多弁や東北弁でも同じ手順で測れますか

測れます。語尾系と語彙系を分け、話者を判定者にする点は共通です。変わるのは、地域語彙の正解を用意する難しさです。話者が少ない方言ほど正解の確保が重くなるため、その場合は監修者の確保を計画に入れます。

まとめ

評価表にある日本語のスコアは翻訳された知識問題を測ったものなので、方言での精度は用途ごとに自分で測る前提になります。語尾と語彙、書かせるのと読ませるのを分け、方言の話者に判定してもらう小さなテストから始めるのが現実的です。