オープンWebの大部分は一握りの言語で書かれており、1つの国から動くクローラーが見ているのはさらに狭い範囲です。つまり、現地の訪問者には現地のテキストを表示するはずのサイトの、英語版やデフォルト版です。複数の市場向けにモデルを学習・ファインチューニングするなら、本当に多言語で地域に根ざしたデータを集めること自体が独立した課題であり、AI・ML向けデータ収集が難しくなるのはまさにこの部分です。
このガイドでは、言語ごとのカバー範囲の計画、現地ソースの見つけ方、現地の読者が見ている版の取得方法、そして集めたテキストの言語判定・フィルタリング・バランス調整を解説します。クロールからコーパスまでの全体的な流れは、オープンWebから大規模な学習データセットを構築する方法のガイドをご覧ください。
言語と地域ごとにカバー範囲を計画する
クローラーではなく、表から始めましょう。対象言語ごとに次を書き出します。
- 重要な地域。 スペイン、メキシコ、アルゼンチンのスペイン語は、語彙、つづり、話題が異なります。ブラジルとポルトガルのポルトガル語はさらに違います。どの変種が必要かを決めます。
- 目標量。 言語・変種ごとに、トークン数または文書数で決めます。
- カバーすべき分野。 ニュース、フォーラム、行政、商取引、参考資料、技術文書などです。
- 文字体系。 セルビア語のキリル文字とラテン文字のように、複数の文字で書かれる言語があります。両方を残すかどうかを決めます。
この表がテストになります。収集が終わるたびに、得られたものを言語ごとにこの表と照らし合わせます。
現地のソースを見つける
一般的なクロールは小さな言語を十分に拾えないため、言語ごとにシードリストを作ります。
- 国別ドメイン。
.pl、.vn、.co.keなどは、地域コンテンツの有力な手がかりです。 - グローバルサイトの言語別版。 ページのヘッダーやサイトマップにある
hreflangタグには、そのページのすべての言語版が列挙されています。hreflangでページのすべての言語版を見つける方法のガイドで抽出方法を紹介しています。 - 現地のディレクトリ、ニュースアグリゲーター、行政ポータル。 同じ言語の多くのサイトへリンクしています。
- 現地語での検索結果。 その地域から取得すると、グローバルなクロールではまず届かないサイトが見つかります。
シードごとに出典とオプトアウトの状況を記録しましょう。取得時にrobots.txtとAI向けのオプトアウトを尊重し、その記録をデータと一緒に保管します。
現地の読者が見ている版を取得する
多くのサイトは、訪問者の所在地によって配信内容を決めます。言語、通貨、地域ニュース、地域版、同意画面などです。データセンターにあるクローラーはどの国でもデフォルト版、多くの場合は英語版を受け取り、それを現地のコンテンツとして記録してしまいます。
現地版を集めるには、各リクエストが現地の読者からのものに見える必要があります。
- 対象国のIP。 理想は家庭用回線です。レジデンシャルプロキシを経由したリクエストは、選んだ国や都市のレジデンシャルIPから届くため、サイトは実際の訪問者と同じようにルーティングし、ローカライズします。
- 整合した
Accept-Languageヘッダー。 たとえばポーランドのポーランド語読者ならpl-PL,pl;q=0.9です。 - 一貫したシグナル。 ヘッドレスブラウザのタイムゾーンとロケールはIPと一致させます。不一致はサイトがデフォルト版に戻る原因の1つです。プロキシの所在地、タイムゾーン、ロケールを合わせる方法の記事で確認項目を解説しています。
収集の早い段階で、各地域のサンプルを目で確認しましょう。「ベトナム語」の束が英語ページだらけなら取得層に問題があり、後のフィルターでは直せません。
すべての文書の言語を判定する
lang 属性やドメインだけを信用してはいけません。抽出したテキストに言語判定モデルをかけます。
- fastTextのlid.176モデルは176言語に対応し、すべての文書に使えるほど高速です。
- GlotLIDのような広範なモデルははるかに多くの言語をカバーし、リソースの少ない言語に強みがあります。
文書単位だけでなく段落単位でも判定しましょう。多くのページは言語が混在しています。英語のナビゲーションメニューを持つ現地の記事や、ユーザーが言語を切り替えるフォーラムのスレッドなどです。必要な言語の段落を残し、後でしきい値を厳しくできるように信頼度スコアも記録します。判定が最も失敗しやすいのは短いテキストなので、ラベルを信用する前に最小の長さを決めておきます。
全体ではなく言語ごとにフィルタリングする
英語に合わせて調整した品質フィルターは、他の言語を損ないます。ストップワードの数、平均単語長、句読点の比率といったヒューリスティクスは、単語の間にスペースを入れないタイ語や、非常に長い単語を持つフィンランド語では挙動が変わります。ネイティブスピーカーが確認したサンプルをもとに、言語ごとにしきい値を設定しましょう。
多言語データでは2つの問題が大きくなります。
- 機械翻訳されたコンテンツ。 多くのサイトが英語ページの自動翻訳を公開しています。量は増えますが、モデルに翻訳の誤りを学ばせてしまいます。既知の英語ページのほぼ翻訳であるページに印を付け、すべてを自動翻訳しているサイトは丸ごと慎重に扱います。
- エンコーディングの誤り。 誤ってデコードされたテキストは文字化けを生み、実在するけれど奇妙な言語のように見えます。Unicodeに正規化し、壊れたエンコーディングは修復または除外し、同じ単語が2通りで保存されないようUnicodeの正規化形式もそろえます。
重複除去は各言語内と言語間の両方で行います。同じ定型文、法的表記、テンプレートがサイトのすべての版に現れるためです。
配合のバランスを取る
生のWebデータは少数の言語が大半を占めます。素の比率で学習すると、小さな言語はほとんど学ばれません。均等な比率で学習すると、小さな言語が何度も繰り返され、モデルが丸暗記してしまいます。
一般的な中間策が温度サンプリングです。各言語を、そのサイズを1未満の指数でべき乗した値に比例してサンプリングします。mT5とXLM-Rの論文では指数0.3が使われました。どの値を選ぶにせよ、サンプリング前後の言語別トークン数とともに記録し、配合を再現・説明できるようにしましょう。何を記録すべきかは、AI学習パイプラインにおけるデータの来歴のガイドで解説しています。
まとめ
多言語データは、英語データに翻訳の工程を足したものではありません。言語と変種ごとにカバー範囲を計画し、現地のソースを見つけ、各地域を現地の読者が見るとおりに取得し、段落ごとに言語を判定し、言語別のしきい値でフィルタリングし、意図を持って配合のバランスを取りましょう。「ポーランド語」のデータが本当にポーランド語かどうかは収集層で決まるので、まず取得を正しくすることが先決です。