EMNLP 2025が示す多言語NLPの現実と実運用の課題

はじめに

近年、AIによる自然言語処理（NLP）は急速に進化し、翻訳、検索、チャットボット、音声アシスタントなど、私たちの日常やビジネスの現場に深く浸透しています。

一方で、「実際の人間の言葉をどこまで正確に理解できているのか」という根本的な課題が、改めて注目されています。

こうした背景の中で注目されているのがEMNLP 2025です。

EMNLP（Empirical Methods in Natural Language Processing）は、自然言語処理分野における世界有数の国際学会であり、最新の研究成果や技術トレンドが発表される場として、研究者・企業の双方から高い関心を集めています。

EMNLP 2025では、これまで主流だった「標準言語中心」の研究から一歩踏み込み、方言、地域バリアント、コードスイッチングといった、現実世界の言語使用を正面から扱う研究が中心テーマとして浮上しています。これは、言語的多様性が「周辺的な話題」から「中核的な課題」へと移行しつつあることを示しています。

この流れは、実際のユーザーが日常的に使う表現や文脈を前提にデータを設計する、人間中心（human-centric）データを重視してきたAppenの長年の取り組みとも一致しています。

本記事では、EMNLP 2025で示された研究動向を手がかりに、多言語NLPにおける方言・言語バリアント・コードスイッチングの課題と、その実運用への落とし込み方を整理します。

NLP（自然言語処理）とは？

自然言語処理（NLP：Natural Language Processing）とは、人間が日常的に使用する言語を、コンピュータが理解・処理・生成できるようにする技術分野を指します。

たとえば、SiriやAlexaのような音声アシスタントが人間の言葉を理解して応答したり、翻訳ツールが異なる言語間で意味を変換したりする際にも、この技術が活用されています。

代表的な自然言語処理（NLP）の活用例には、以下のようなものがあります。

• 機械翻訳
• チャットボット・AIアシスタント
• 感情分析・意図分類
• 検索エンジン
• 音声認識・音声対話システム

これらの多くは、「どのような意味を持つのか」「どの言語で書かれているのか」「どのような意図が含まれているのか」を判断することで成り立っています。

多言語NLPとは？

多言語NLPとは、複数の言語を対象とした自然言語処理技術を指します。

英語だけでなく、日本語、アラビア語、スペイン語、中国語、ヒンディー語など、異なる言語体系・文字体系を横断的に扱うことが求められます。

多言語NLPは、以下のようなユースケースで不可欠です。

• グローバル向けプロダクト・サービス
• 多言語カスタマーサポート
• 国・地域を横断する検索・推薦システム
• 多言語SNS・メッセージングアプリ

しかし、多言語NLPの多くは、これまで「標準語」を前提に設計・評価されてきました。ここに、大きな課題が存在します。

特に実運用では、同一言語内の方言差や、言語が混在する入力への対応が、多言語NLPの成否を大きく左右します。この点が、後述する「方言ギャップ」やコードスイッチングの問題につながっています。

多言語AIに残る「方言ギャップ」とは？

多言語AIは、標準言語においては高い性能を示すようになっています。

しかし、地域方言や非公式な言語バリエーションに対しては、性能が急激に低下する傾向があります。

この問題は「方言ギャップ（Dialect Gap）」と呼ばれます。

実運用の現場では、この方言ギャップが次のような形で顕在化します。

• ローカルな慣用句や表現をLLMが正しく理解できない
• 方言特有のスラングや侮辱表現をトキシシティフィルターが検出できない
• 方言間の皮肉やニュアンスを感情分析モデルが誤読する
• ユーザーが発話途中で言語を切り替えた瞬間に、言語識別（LID）が破綻する

つまり、標準語ベースで評価されたモデルは、現実世界では脆弱になりやすいのです。

なぜ今「方言ファースト」が重要なのか

近年、多言語NLPの性能は大きく向上しましたが、その評価や設計は依然として標準言語中心で行われることが多く、実際の言語使用との乖離が指摘されています。

こうした状況を背景に、「方言ファースト」という考え方が、研究と実運用の両面で注目されています。

「方言ファースト」とは、方言やコードスイッチングを例外として後処理するのではなく、最初から設計・評価の前提に据える考え方です。

定量化され始めた方言に対する性能劣化

近年の研究では、高リソース言語であっても、方言ごとに精度低下が発生していることが体系的に測定されています。

標準ベンチマークで「十分に良い」性能を示していても、実際のユーザー体験においては不十分であるケースが明らかになりつつあります。

コードスイッチングは例外ではなく日常である

多くの言語コミュニティでは、1文や1発話の中で複数言語を混在させることが一般的です。

コードスイッチングを例外的なケースとして扱うと、モデルは脆くなり、UXも悪化します。一方で、これを前提条件として設計すれば、カバレッジと信頼性は大きく向上します。

人間の言語は本質的に文脈依存である

実際のユーザーは、レジスターを切り替え、語彙を借用し、音写を行い、相手やプラットフォームに応じて表現を柔軟に変化させます。

多言語NLPは、この現実的な文脈依存性を無視することができなくなっています。

これらの背景から、方言やコードスイッチングを後付けで対応するのではなく、最初から前提として設計する「方言ファースト」なアプローチが不可欠になっています。

最新研究が示す多言語NLPの現実

こうした課題意識は、EMNLP 2025で発表された複数の研究でも共通して確認されています。

Appen研究：文化的ニュアンス翻訳の課題

Appenの研究チームは、「Multilingual LLM Translation: Evaluating Cultural Nuance in Generative AI」という論文において、文化的ニュアンスを含む言語表現（イディオムや語呂合わせなど）の翻訳性能を検証しました。

このパイロット研究では、スペイン語やフランス語のような高リソース言語から、グジャラート語やイボ語といった地域言語まで、20以上の言語におけるLLM翻訳を分析しました。

その結果、文化的整合性の観点で評価した場合、翻訳品質に大きな差が存在することが明らかになりました。

現在、より多くの言語とモデルを対象としたフェーズ2が進行中であり、2026年初頭の公開が予定されています。

EMNLP 2025で注目された研究動向

EMNLP 2025では、多言語性能に焦点を当てた研究が数多く発表されました。

Xieらの研究

コードスイッチされたコーパスを用いて、多言語BERT系モデルをファインチューニングすることで、混合言語の分類タスクおよび系列ラベリングにおいて、測定可能な性能向上が確認されました。

この結果は、単に対応言語数を増やすよりも、実際に混在した入力を想定したデータ設計が、実運用に直結することを示しています。

参考文献：https://arxiv.org/abs/2503.07990

Hamedらの研究

アラビア語におけるコードスイッチングを包括的に分析し、以下の2つの構造的な課題を明らかにしました。

1. 方言バリエーションに対するリソース不足
2. 実世界での失敗を覆い隠してしまう評価上の盲点

これらの傾向は、インド語派、ロマンス語派、バンツー語派といった、他の大規模言語ファミリーにも一般化される可能性が示唆されています。

参考文献：https://arxiv.org/abs/2501.13419

Ojo、Kamel、Adelaniの研究

コードスイッチングおよびドメインシフト下における、言語識別（LID）および分類タスクのための新しいベンチマークを提案しました。

これらの研究は、

• 適切なアノテーターへのデータ振り分け
• 曖昧なスパンの検出
• スパンレベルで一貫したラベリング

といった運用上の要件が、混在した条件下でも信頼できるLIDに依存していることを示しています。

参考文献：https://arxiv.org/abs/2509.17768

Shethらの研究

80以上の言語をカバーするモデルであっても、激しいコードミキシングや急速なドメインシフトの下では性能が大きく低下することを示しました。

この結果から、

• 大規模な学習データの追加よりも
• 実ユーザー言語分布を反映したサンプリング戦略
• スパン認識を前提としたガイドライン
• 現実的な評価スイート

といったデータキュレーションと評価設計の重要性が強調されています。

参考文献：https://arxiv.org/abs/2510.07037

これらの結果は、翻訳や生成モデルの性能評価において、言語的正しさだけでなく、文化的・文脈的整合性を含めた評価設計が不可欠であることを示しています。

方言とコードスイッチングは「例外」ではない

これらの研究に共通している結論は明確です。

方言やコードスイッチングはエッジケースではなく、現実の言語分布そのものであるという点です。

これは、研究上の結論であると同時に、プロダクト設計や評価指標の前提を見直す必要性を示しています。

モデル性能を本当に加速させる要因は、モデルサイズではなく、包括的なデータと包括的な評価にあります。

EMNLP 2025で注目の今後の研究テーマ

EMNLP 2025では、現在の課題を踏まえ、以下のような研究テーマが今後さらに重要になると見られています。

低リソース学習と方言間転移

標準言語から地域方言へと知識を転移しつつ、方言固有の意味を失わない手法が注目されています。

例えば、標準アラビア語から湾岸方言やレバント方言への転移などが該当します。

方言差を吸収してしまうのではなく、差異を保ったまま学習させるために、マルチタスク学習や、方言変動に調整されたアダプターの活用が想定されています。

大規模コードスイッチデータセットの拡充

スパンレベルの言語タグを備えた、大規模なコードスイッチコーパスの登場が期待されています。

特に注目されているのは、以下をバランスよく含むデータ収集手法です。

• 発話内での言語切り替え
• 借用語
• 音写（翻字）表現

単にデータ量を増やすのではなく、実際の言語使用を反映したサンプリング設計が重視されています。

高負荷環境下における言語識別（LID）

DIVERS-CSのようなベンチマークは、言語識別（LID）を理想的な実験環境の外へ押し出すものです。

今後は、以下の条件下でも機能するモデルが求められています。

• 短いスパン
• 固有名詞の混在
• チャットやSNSに典型的な高速な言語切り替え

クリーンなデータではなく、雑多で不完全な入力を前提とした評価が進められています。

データセット設計とアノテーション基準の高度化

混合言語データに対して、より具体的なアノテーション基準が求められています。

焦点となっているのは、以下の点です。

• 言語切り替えポイントの明確なマーキング方法
• 借用語と真のコードスイッチの区別
• アノテーター間の不一致をどのように調停するか

これらは、評価の再現性と運用可能性に直結する要素です。

現実を反映した評価手法

今後の評価では、単一の集計スコアではなく、現実の使用状況を反映した指標が重視されます。

具体的には、

• 方言別の性能指標
• コードスイッチ耐性テスト
• ドメインシフト評価（メッセージング・検索・サポートなど）
• といった複数の観点からの評価が想定されています。

運用・QAプラクティス

運用面では、混合言語データを前提としたQAの実践が重要になります。

注目されているのは、以下のような取り組みです。

• 方言が検証されたコントリビューターの選定
• 混合言語入力を想定したゴールデンセットの設計
• テスト質問を継続的に回すフィードバックループ
• ユーザーが問題に気づく前に、方言ごとの性能劣化を検知する本番監視

これらは、方言やコードスイッチングを含む入力において、品質の低下を早期に発見し、運用上のリスクを抑えるための実務的なアプローチです。

Appenのアプローチ

こうした研究動向を、実際のプロダクト開発とデータ運用に落とし込むために、Appenでは以下のようなアプローチを取っています。

Appenの立場は明確で、モデルはその学習データと評価設計の形をそのまま引き継ぐという考え方です。

そのため、方言・言語バリアント・コードスイッチングに対応するには、モデル以前にデータ収集・アノテーション・品質管理の設計そのものを変える必要があります。

以下は、Appenが実運用で実践している具体的なアプローチです。

方言を前提としたコントリビューターリクルーティング（Dialect-aware recruiting）

Appenでは、単に「言語が話せるか」ではなく、どの方言・どの使用文脈に精通しているかを基準にコントリビューターを調達・検証します。

具体的には、以下のような観点でリクルーティングを行います。

• 地域ごとの言語バリアント（例：同一言語内の地域差）
• 都市部／農村部といった社会的レジスターの違い
• 利用プラットフォームに固有の言語慣習（例：ショート動画の字幕表現とカスタマーサポート文書の言語差）

これにより、「言語的には正しいが、現実の使用とはズレている」データが混入するリスクを抑え、実際のユーザー言語分布に近いデータ収集を可能にしています。

文化適応型・スパン認識を前提としたアノテーションガイドライン

Appenでは、アノテーションガイドラインを言語学者およびネイティブ話者と共同で設計します。特にコードスイッチングを含むデータでは、以下を明確に定義します。

• スパンレベルでの言語タグ付けルール
• 借用語（borrowed words）と真のコードスイッチの区別方針
• 曖昧なケースに対する判断基準
• 実際の自然言語使用を反映した具体例

これにより、アノテーターの解釈差を最小化し、再現性の高いラベリングを実現します。

レポートではなく「ゲート」としてのIRR運用

多くのプロジェクトでは、IRR（Inter-Rater Reliability）は結果報告の指標として扱われがちです。

一方、AppenではKrippendorff’s AlphaなどのIRR指標を、品質管理のためのゲートとして活用します。

具体的には、

• コントリビューターの適格性判断
• レビュアー間のキャリブレーション
• ラベル定義やガイドラインの改善判断

にIRRを用います。

不一致のパターンは単なる数値として処理されるのではなく、再トレーニングや定義修正の根拠として活用され、スケール前に問題を解消します。

プラットフォームに組み込まれた品質管理（Quality built into the platform）

タスクが方言的に多様化するにつれて、品質管理も動的である必要があります。

Appenでは、以下の仕組みをプラットフォームレベルで組み込んでいます。

• ゴールデンセットによる定期的な品質検証
• ローテーション型テスト質問による継続評価
• モデル支援ラベリング導入時のドリフト監視
• 必要に応じたブラインドレビュー用の再サンプリング

これにより、データ規模が拡大しても、方言対応品質を安定的に維持できます。

モデル・イン・ザ・ループによるデータ生成

到達が難しい方言や、頻度は低いが重要な言語パターンに対しては、モデル・イン・ザ・ループ（Model-in-the-loop）のアプローチを採用します。

具体的には、

• 小規模かつ厳密にレビューされたシードデータを作成
• モデルが失敗している例を優先的に抽出（例：激しいコードミキシング、急激な言語切り替え）
• アクティブラーニングループによる重点的データ収集

これにより、単なる量的拡張ではなく、モデル性能に直結するデータ拡充を実現します。

なぜこのアプローチが重要なのか

これらの取り組みにより、チームは以下の成果を得られます。

• 方言間でより安定したモデル性能
• 誤解や誤判定に起因するサポート問い合わせの削減
• 集計指標だけでは見えない劣化を防ぐ評価設計

つまり、包括的な多言語NLPを実現するための現実的な運用モデルが成立します。重要なのは、方言やコードスイッチ条件に整合したLLM評価ダッシュボードを用意し、集計指標だけによる過度な安心感を防ぐことです。

リリース前に確認すべきポイント

多言語NLP、とくに方言やコードスイッチングを含むシステムでは、「モデルを作る前」「リリースする前」の確認が、品質を大きく左右します。

以下は、リリース前に確認すべき実践的なチェックリストです。

カバレッジの監査（Audit coverage）

まず確認すべきは、ユーザーが実際にどのような言語・方言・レジスターを使っているかです。

• 想定している対象言語・方言は何か
• 実際の利用ログ（検索、チャット、音声入力）に現れている言語使用はどうか
• フォーマル／インフォーマル、書き言葉／話し言葉の比率はどうか

設計上の想定と、実際の利用状況をマッピングすることで、見落とされがちな方言や使用文脈のギャップを早期に発見できます。

適切なデータミックスの収集（Collect the right mix）

次に重要なのは、「何を、どの割合で集めるか」です。

各ターゲット言語について、以下の軸を意識してサンプリングを行います。

• 方言・地域バリアント
• レジスター（フォーマル／インフォーマル）
• チャネル（音声、チャット、SNS、サポート文書など）

また、テキストだけでなく、音声データを含むマルチモーダル構成を意識し、その中に十分な割合のコードスイッチ例を含めることが重要です。これにより、特定の言語形式に偏らない、実世界分布に近いデータセットを構築できます。

スパンレベル方針の定義（Set span-level policy）

コードスイッチングや混合言語データでは、「どこからどこまでを、何として扱うか」を明確にする必要があります。

具体的には、以下を事前に定義します。

• 言語スパンのタグ付けルール
• 音写（翻字）された語の扱い
• 借用語と真のコードスイッチの区別
• 複数解釈が可能な曖昧トークンの処理方針

このスパンレベル方針が曖昧なままでは、アノテーションの一貫性が失われ、モデル評価も信頼できなくなります。

IRR閾値の固定（Lock IRR thresholds）

IRR（Inter-Rater Reliability）は、後から確認する指標ではなく、事前に決める基準です。

• タスク種別ごとに目標とするKrippendorff’s Alphaを設定
• 小規模なパイロットバッチで事前検証
• 基準を満たさない場合は、ガイドラインや教育内容を修正

このプロセスをスケール前に行うことで、品質問題を後工程に持ち越さない運用が可能になります。

スライス別評価の実施（Evaluate by slice）

モデル評価では、全体スコアだけを見るのは危険です。

以下のような切り口で、必ずスライス別に評価を行います。

• 方言別性能
• コードスイッチ有無別性能
• チャネル別（音声／チャットなど）性能

これらを集計指標と並行して報告し、CI（継続的インテグレーション）上でスライス単位の性能劣化（回帰）を監視します。

本番監視と反復改善（Monitor & iterate）

リリース後も、品質管理は終わりません。

• 本番環境で発生した失敗事例を、方言・バリアント別に記録
• 誤解・誤判定が多いケースを特定
• それらをアクティブデータ収集や再アノテーションに反映

このフィードバックループを回すことで、モデルは実運用に即して継続的に改善されていきます。

今後の展望：次世代多言語NLPに向けて

EMNLP 2025は、方言、言語バリアント、コードスイッチングが次世代言語モデルを形作っていることを明確に示しています。

研究コミュニティは、これらを対象としたベンチマークや手法の整備を進めています。一方で、産業界には、それらを実運用に落とし込むためのパイプラインが求められています。

Appenが長年注力してきた、包括的なデータ、包括的な評価、方言対応のQAは、まさにこの動きに対応するものです。

もしロードマップに、アラビア語、ヒンディー・ウルドゥー語、スペイン語、スワヒリ語、中国語など、方言変動が豊かな市場が含まれている場合、データと評価基盤のアップグレードが、実世界での性能向上を実現する最短の方法になります。