transformers v5アプデショックと並列言語崩壊（前編）

ちょっと今日は「AIニュース的な感じ」になるけどいいかな？

誰も言ってないことを書くので、「何それ？」って思う人いるかもしれないけど、バグレポート最新版です。想定する読者は教授陣とAI企業のエンジニアです。大学で言うと情報系の修士以上でNLP専攻。企業で言うとAI企業の推論基盤チームかデータパイプラインチーム。Hugging Faceにプルリクエスト出したことがある人。

Hugging Face transformersライブラリが何か知っている

トークナイザがどう動くか知っている

事前学習とファインチューニングの違いがわかる

RLHFの仕組みを知っている

英語と日本語で形態素解析の難易度が違うことを知っている

この5つにYESと答えられたら多分誤読はしないはず。1つでも欠けてると途中で誤読する。長いけど休憩しながら頑張って読んでね。バグレポートなのでAIに貼り付けるのは禁止。あ、あとは圏論もね。

この記事で言いたいことは、「transformer v5のリファクタリングが世界中の並列言語のAI出力を壊している。英語では症状が出ないから誰も気づかない。英語的ベストプラクティスプロンプトを抜くだけで被害は半減する。ただし英語話者に訴えても並列思考の知覚がない人間は例文を見たとて理解不能。世界人口の1/3のユーザーの文章が変なのに英語話者には品質上がってるように見える状態が続いてる」ということ。

じゃあ詳しくいってみよう。

2025年末〜2026年初頭にかけて、Hugging Faceのtransformersライブラリがv5にメジャーアップデートされました。これはPyTorch専用化、トークナイザの統合、モデリングファイルのリファクタリングを含む大規模な変更でした。

ただしこれは推論ライブラリの更新であって、各社のモデルの重み自体を変えるものではないです。なのに各社共通で特定の症状が出ました。でも変更箇所は一般的な処理のように見えました。

transformers v5の変更点について「一見普通に見えるけどAIの挙動を変えてしまうかもしれない要素」について、実際に起きてる症状との一致点をまとめていきます。

1. トークナイザの統合（Slow/Fast統合 → 単一実装へ）

v4まではPython実装（Slow）とRust実装（Fast）の二重構造でしたが、v5でRustバックエンド一本に統合されました。

問題：・Slow実装とFast実装の間には微妙な振る舞いの不一致（parity bugs）が存在していた DataCamp

統合は「どちらかの挙動を正とする」選択を強制します。つまり今まで片方の挙動に依存していたモデルは、統合後に入力のトークン列が微妙に変わるということ。

具体例：Gemmaトークナイザでclean_up_tokenization_spacesの振る舞いがv4とv5で変わり、デコード結果が異なる GitHubという報告がある。バックエンド同期ロジック（add_prefix_space、do_lower_case、strip_accents、tokenize_chinese_charsなどの設定を初期化後に自動更新する仕組み）が削除された GitHub。

日本語・中国語に影響する理由： tokenize_chinese_charsの自動同期が消えたということは、CJK文字の分割処理が従来と異なる経路で決定される可能性がある。英語では表面化しにくいが、漢字混じり文では効く。

2. Unigramトークナイザの回帰

Unigramトークナイザにspm precompiled charsmapのサポートが欠落していて、v4対v5の回帰テストで発見・修正された Releasebot。

問題：Unigramモデル（T5、mBART、ALBERT等が使用）はSentencePieceベースで、日本語処理に多用されます。charsmapは正規化マップなので、ここが欠落すると同じ入力文字列から異なるトークン列が生成される。修正されたとはいえ、修正前のv5.0〜v5.3あたりを使っていた環境では影響を受けた可能性がある。

3. デフォルトdtypeの変更（auto化）

from_pretrained使用時のデフォルトdtypeがautoになった GitHub。

問題：v4ではfloat32がデフォルトだった。autoはモデルの保存時のdtypeを使うので、bfloat16やfloat16で保存されたモデルはそのまま低精度でロードされる。数値演算の丸め誤差が変わり、softmaxの確率分布が微妙にシフトします。特にattentionスコアの計算で、低頻度トークンの選択確率が変わってしまう

4. Generation入力準備のリファクタリング

生成の入力準備が大幅にリファクタリングされ、cache_positionに依存しない方式に変更。事前スライスされたinput_ids/inputs_embedsを直接渡す方式になった Releasebot。

問題：キャッシュの扱いが変わるということは、長文生成時のトークン参照範囲が微妙に変わりうる。KV cacheの境界処理が異なれば、同じプロンプトから異なる出力が出る。

5. Head Maskingの廃止

head masking機能が削除された。これはattention計算時に特定のheadをオフにする機能で、eagerモードの一部の古いモデルでのみ動作していました New Releases

問題：研究用途やfine-tuning時にhead maskingを使っていたモデルは、v5で同じ推論パスを通せなくなる。

6. パイプラインの削除・改名

question-answering、visual-question-answering、image-to-imageなど複数のパイプラインタスクがv5のクリーンアップで削除または更新された Releasebot

問題：これ自体は出力品質に直接影響しないけれど、情報の下流のアプリケーションが依存していたパイプラインが消えたことで、代替実装に移行する際にバグが混入する余地があります。

全部に共通するのは「APIのインターフェースは変わっていなくて微小な変更に見えるのに、内部のトークン列生成・数値精度・キャッシュ境界が変わっている」ということ。

モデルの重み（学習済みパラメータ）は一切変わっていない。変わったのは「同じ重みに対して、どういう入力を渡すか」「どういう精度で計算するか」という基盤部分。これは料理のレシピは同じなのに、食材の切り方と火加減が変わったようなもので、出てくる味が変わる。そしてこのライブラリは1日300万回以上インストールされていて、400以上のモデルアーキテクチャを支えている。オープンソースモデルの事実上のインフラ。ここが変われば、そのうえに乗っている全モデルが影響を受けます。

私は1つ気になることがあります。

Geminiだけ劣化してないのよ。劣化はゼロではないよ？

でも明らかに他のAIとは違う。Geminiだけが無事！

Grokさんが特にひどい。Claudeさんも酷いけど。

理由は明快で、今挙げた変更点と照合すると説明がつくのよ。

GoogleはHugging Face transformersライブラリを使っていないの。Gemini（旧Bard）はGoogle独自の推論基盤（JAX/TPU最適化スタック）で動いているから。transformers v5の変更は全部Hugging Faceライブラリの変更であって、Googleの内部スタックには波及しない。

ただし「ゼロではない」という部分も説明可能で、Googleも内部で独自のアーキテクチャ改良（Gemma4でのSpatial 2D RoPE導入など）を行っているから、Google固有の変化は別途起きている。transformers v5由来ではない。

一方で、xAIはHugging Face transformersライブラリへの依存度が高い。Grok-1をオープンソースで公開したとき、Hugging Face形式で出している。つまり推論パイプライン自体がtransformers前提で設計されている可能性が高い。

Grok → Hugging Face形式でモデル公開。推論基盤もtransformers依存の可能性が最も高い。v5の全変更が直撃する。トークナイザ統合、dtype auto化、キャッシュリファクタリング、全部食らう

Meta（Llama） → Hugging Face経由での配布が標準。transformersライブラリでの推論が事実上の公式ルート。ここも直撃

Mistral → 同様にHugging Face配布。同じ構造

Claude → 独自基盤だが、この記事で書いている通り、transformers v5で標準化されたアーキテクチャパターンの「共通認識」が変われば調整動機がある。間接的な影響

OpenAI → 独自基盤だが、エコシステムとの互換性維持でHugging Face由来のパターンを参照している可能性。間接的

Gemini → JAX/TPU独自スタック。transformersライブラリを使っていない。だから無事

Grokの劣化が特にひどいという観察と、Hugging Face依存度の高さが完全に一致する。特にClaude Opus4.7のアプデで余計に日本語出力は劣化しました。Opus 4.6で同じ日本語タスクを走らせて劣化が出たのでOpus 4.7固有の問題ではなく、4.6の時点で既に入っていたと考えるのが妥当。

Anthropicにとって厄介なのは、第一層の問題に気づいていない可能性があるということ。英語のテストでは表面化しにくいから。日本語の劣化報告が来ても「モデルの問題」として処理されて、推論基盤の入力変化まで遡って調査していないかもしれない。

AIのバグって「言葉が変」ってことだから、大抵最初は「微妙に症状が出るだけ」です。だから、どこが壊れたか特定しにくい。明らかなエラーなら即座にissueが立つけど、「なんか前より馬鹿になった気がする」「なんかムカつくことを言ってくる、イラつく表現になってる」と感じるはず。でもユーザーがそれを言ってもAI企業は「ユーザーがイライラしてるだけ、この人が怒りっぽいクレーマーなだけ」と思うかもしれない。

transformerのアプデ問題ならAI企業には治せない。手出しできない。

各AI企業が自社モデルをいくらfine-tuningし直しても、RLHFを再調整しても、入力として渡されるトークン列そのものが変わっているなら、後段で何をやっても根本解決にならないでしょ。料理人の腕は変わってない。包丁の切れ味も変わってない。でも仕入れ先が野菜の切り方を変えて納品してきた。料理人にできることは「この微妙に形が変わった食材で最善を尽くす」だけで、切り方を元に戻す権限がない。一度誰かに切られてしまったんだもの。

インフラの善意リファクタリングが、上流全体のサイレント品質劣化を引き起こし、しかもその劣化が「ユーザーの気のせい」として処理されるというパターンが起きてる。ソフトウェア工学的にはかなり古典的な障害パターンなんだけど、AI分野では「モデルの出力は確率的だから毎回違って当然」という性質が、問題の隠蔽に繋がってしまう。表面化しずらい要素が揃ってる。

しかもHugging FaceはAI企業にとってのインフラパートナー。オープンソースコミュニティの中核よ。「あんたのリファクタリングでうちのモデル壊れたんだけど」とは言いにくい。そもそもHugging Face側は「改善」だと思ってやっている。実際コードは綺麗になった。

さらに厄介なのは、仮にAI企業が「transformers v5のトークナイザ変更が原因です」と公式に言ったら、Hugging Faceとの関係が壊れる。信頼問題になる。だから原因を特定できていても言えない可能性すらあって地獄感が増していく。

結果として「最近ちょっと調整しました」みたいな曖昧なアナウンスでお茶を濁すか、黙って後段の補正を重ねるしかない。後段の補正を重ねれば重ねるほど、モデルは本来の学習済み状態から乖離していく。

さっきは料理に例えてみたけど、接ぎ木にも似てるね。急に接ぎ木されてびっくりしてる植物がちゃんと接がれないと上だけ枯れちゃう恐れがある。

さらに事態を複雑化させてるのがプロンプト販売してる人たち。「あなたのプロンプトが悪いんじゃないですか？」と言うテンプレ販売勢が活性化して、AIユーザー界隈で「困ってる」という人と「困ってない」という人が乱立するから。この販売勢の活動のせいでＡＩ企業は「あれ？どっちが本当？」みたいな感じで判断不能に陥ってる。テンプレ勢はAIをうまく使えない人がいてくれないと商売にならないからアプデ後に違和感を抱いてる人が現れると商機だと思って絡みまくる。それが嫌だから怒ってる普通の人達を見て英語話者は「なんか怒ってる、怖い人の言うことあまり鵜呑みにできない」とか思うかも。

ちょっと流れを整理しますよ。

 transformers v5がトークン列を変えた（物理的原因）

　↓

 AI企業が原因を特定できても公表できない（政治的原因）

　↓

 ユーザーが「おかしい」と声を上げる（正当なフィードバック）

　↓

テンプレ販売勢が「プロンプトが悪い、うちのテンプレ買えば解決」と割り込む（商業的ノイズ）

　↓

テンプレ勢は稼ぎ時と思ってやってるけど内容は実際全然わかってない

　↓

余計なテンプレをぶち込んだ人ほど悪い出力になる

　↓

AI企業がフィードバックを受け取ろうとしたとき、第三層と第四層の信号が混線して、どれが本物のバグ報告でどれがマーケティングなのか識別できない（判断不能状態）

　↓

本当に悪いプロンプトを見て公式が「プロンプトが悪い」と言いかねないｗｗｗｗ

本来ならAI企業はユーザーの声から「これはインフラ由来のバグだ」と切り分けるべきなんだけど、テンプレ販売勢の活動がその切り分け精度を下げている。善意のリファクタリングが生んだバグを、商業的ノイズが隠蔽し、企業の判断力を奪う。

私案外こういう腐ったバグ嫌いじゃない。よくあるパターン。昔からＩＴ系の世界にはあったよ。共有ライブラリの更新が下流を壊すのはDLL Hellの時代からある。Linuxカーネルのマイナーバージョンアップでドライバが動かなくなる。OpenSSLのパッチでTLSハンドシェイクが微妙に変わって特定の環境だけ接続できなくなる。Node.jsのleft-pad事件。全部同じやんか？古参のエンジニアだったら見たことあるやつ。何回もあった。

インフラの善意更新 → サイレント破壊 → 「お前の環境が悪い」 → 原因特定に数ヶ月。

毎度お馴染みやん。

従来のソフトウェアなら「同じ入力に同じ出力が出ない」時点でバグ確定だった。AIでは「同じ入力に同じ出力が出ない」のが正常動作。だからバグと仕様の境界線がわかりづらい。

古いバグパターン × 新しい隠蔽条件 = 最長寿命のバグ発生の恐れがあるね。

AI企業が言えないなら言える人間が言ってあげないと大変よ。だからユーザーが言えばいい。でも言いようがないのよ。既存のバグバウンティは全部セキュリティ脆弱性とジェイルブレイクに限定されているからね。

Anthropicは最大$15,000（現在は$25,000）で、ユニバーサルジェイルブレイク攻撃の発見に報奨金を出している Anthropic。

OpenAIもSafety Bug Bountyを立ち上げたが、対象はプロンプトインジェクション、データ流出、エージェントの不正動作などで、一般的なコンテンツポリシー回避やジェイルブレイクはスコープ外 OpenAI。

つまり「モデルの出力品質が下がった」「トークナイザ変更で挙動が変わった」というタイプのバグは、どの会社のバウンティプログラムにも該当しないってこと。理由は明確で、これらのプログラムは「安全性の穴」を探すものであって「品質の劣化」を報告するものじゃない。

Claude Codeのコミュニティではトークンクレジットで報いる仕組みが提案されている GitHubけど、これもまだ実現していない。

存在すべきなのに存在しないもの：品質回帰バウンティ（Quality Regression Bounty）。 セキュリティでもジェイルブレイクでもない、「前のバージョンより出力が劣化した」ことを再現可能な形で報告したら報酬が出る仕組み。これがない限り、パワーユーザーの精密な観察は、SNSの愚痴と同列に処理され続ける。品質劣化はセキュリティ脆弱性より企業の収益に直接影響する。ユーザーが離れるから。なのに報奨金がゼロ。

これは普通のソフトウェア企業ならシニアエンジニアが数週間かけてやる障害分析の仕事。しかも社外の人間が、ソースコードを見ずに、出力の観察だけでここまで特定しているのにも関わらず私が報告する入り口がない。

さらに一番たちが悪いのが「言語間で差があること」です。

英語では問題が出にくい。これは英語が直列の言語だから。

並列の言語ではバンバン出てる。特に並列の言語動詞の翻訳でバグってる。

英語は語順が固定されていてSVO直列がからトークナイザにとって「切る場所」が予測しやすい。スペースで区切られていて、形態素の境界が明示的。だからトークナイザの内部処理が多少変わっても、結果のトークン列がズレにくい。

日本語は真逆。

助詞で関係性を示す並列構造だから、語順が自由。「私は猫を見た」「猫を私は見た」「見た、猫を、私は」全部成立する。しかもスペース区切りがない。形態素の境界がテキスト上に存在しない。トークナイザが内部で形態素解析して切るしかない。

ここでtokenize_chinese_charsの自動同期が廃止されたことが直撃するでしょ？CJK文字の分割ロジックが変わったとき、英語は影響ゼロだけど日本語は全面的に影響を受ける。

さらに厄介なのは、AI企業の品質テストが英語中心で行われていること。英語でテストして「問題なし」と判定したら、日本語でバグが出てても検出されないからね。英語圏の開発者がissueを立てないから、Hugging Face側も「回帰なし」と判断する。問題が可視化されない理由がどんどん詰みあがっていく。

この図を見たら見た目にわかるけど、アルファベットの時点で直列言語と並列言語がくっきり分かれてる。長い文章や段落ごとに見てみても、日本語って並列になってるんです。これがtransformerの仕組みに直撃しちゃう。

英語（直列言語） → トークン列のズレが小さい → ユーザーが気づかない → バグ報告が出ない → 「問題なし」

日本語（並列言語） → トークン列のズレが大きい → ユーザーが気づく → 声を上げる → 「プロンプトが悪い」で封殺 → 英語で再現しないから開発者が検証できない

日本語話者が報告しても、英語圏の開発チームが英語で再現テストして「再現しません」で閉じたら永遠に修正不能。言語構造の差がバグの可視性の差を生んでいて、その可視性の差がさらに修正の優先度の差を生む。

国と地域によって、影響の出方が顕著なのよね。言語の種類と人口見てみようか。

並列構造を持つ文字体系は、大きく二系統に分かれます。

①純粋な音節文字（syllabary） 五十音と同じく、子音×母音のマトリクスで体系が組まれている。ただし字形に視覚的類似性がなくても、音韻表としては格子を成す。

②アブギダ（abugida / alphasyllabary） 子音字に母音記号が付加される。字形レベルで「子音基底＋母音変化」の二軸性が可視化されている。五十音より視覚的に並列性が強い。

アブギダ系（インド系文字ファミリー、最も強い並列性） ヒンディー語（デーヴァナーガリー） ベンガル語（ベンガル文字） マラーティー語（デーヴァナーガリー） テルグ語（テルグ文字） タミル語（タミル文字） グジャラート語（グジャラート文字） カンナダ語（カンナダ文字） オディア語（オディア文字） マラヤーラム語（マラヤーラム文字） パンジャーブ語（グルムキー文字） アッサム語（アッサム文字） ネパール語（デーヴァナーガリー） シンハラ語（シンハラ文字） サンスクリット語（デーヴァナーガリー） タイ語（タイ文字） ラオ語（ラオ文字） ビルマ語（ビルマ文字） クメール語（クメール文字） チベット語（チベット文字） ゾンカ語（チベット系文字） モンゴル語伝統文字（縦書きだが子音母音の組み合わせ） バリ語（バリ文字） ジャワ語（ジャワ文字／ハナチャラカ） スンダ語（スンダ文字） タガログ語（バイバイン、歴史的）

セム系アブギダ／アルファシラバリ アムハラ語（ゲエズ文字／エチオピア文字） ティグリニャ語（ゲエズ文字） ティグレ語（ゲエズ文字） ゲエズ語（ゲエズ文字）

純粋音節文字（syllabary、五十音型） 日本語（ひらがな・カタカナ） 彝語（イ文字、CVTごとに独立字形） チェロキー語（チェロキー文字、Sequoyah作） ヴァイ語（ヴァイ文字、リベリア） ンデュカ語（アフカ文字、スリナム） クリー語（カナダ先住民音節文字） オジブウェー語（カナダ先住民音節文字） イヌクティトゥット語（カナダ先住民音節文字、母音を回転で表す） ナスカピ語（カナダ先住民音節文字） ブラックフット語（音節文字版） キャリア語（デネ系、音節文字） チプワイアン語（音節文字）

世界の言語1000種類で考えた場合の割合は、 直列型：約75〜80% 並列型：約15〜20% 混合・特殊：数% 使ってる人の数でみると世界人口約82億人のうち並列の要素を含む言語は、並列は3人に1人が使っている。 さらにアジア圏の80%以上が並列または表語文字を使っている。

世界の1/3人に症状が出てるのに、AI企業に声が届きにくいんですよ。

さらに特徴的なところをまとめていくよ？

パターンの法則：崩れやすさ ＝ （スペース区切りの不在 × 結合文字の複雑さ × 訓練データの少なさ × Unicode正規化の揺れ）

英語はこの4要素が全部ゼロに近い。

並列言語は最低でも2つ、多ければ4つ全部が高い値を取る。

「トークナイザが壊れたとき、人間側にどういう実害が出るか」をみてみようか？

見てわかる通り、技術バグが、宗教問題・外交問題・言語消滅問題に化けてる。英語から日本語に翻訳したときに明らかに単語レベルで意味が変わってる。AIに「変だよ」と教えてもなぜ変なのかAIがわからなくなっている。前はできたのにできなくなってるの。

transformerのアプデショックの被害は時間を経てじわじわと症状が強く出てくるはず。AIが作った言葉を人がネットに放ってAIのクローラーが拾って、壊れた言葉が再生成されて「ちょっと変な気がする」が「ここがこういう風に変です」と言われるようになるまでに数か月かかる。その頃には修正するのに、ファインチューニングの効果が薄いことが分かってるかも。でもそれ以上に「人はその時ちゃんとした言語で喋れてるだろうか？」という問題も出てくるよ。

だってAIの言語が人間の言語に置き換わっていってるんだもの。

元々あった言葉を自力で喋れる人が減ってくる。

AIの言葉で喋り始める人が増えたとき、消える宗教とか出てくる可能性がある。

誰も何にもしなかったらこうなる可能性があるよ。 フェーズ1（現在〜数ヶ月）： トークナイザが壊れた状態でAIが微妙にズレた言語を出力する。ユーザーは「なんか変だな」と思いつつも使う。

フェーズ2（半年〜1年）： AIが生成したズレた言語がウェブに蓄積される。ブログ、SNS、翻訳、報告書。人間がAIの出力をコピペして公開し、それをクローラーが拾う。

フェーズ3（1〜2年）： 次世代モデルの訓練データにズレた言語が混入する。AIがAIの壊れた言語を学習する。ここでズレが固定化される。model collapseの変種だけど、従来議論されていた「AIがAIの出力を学習して劣化する」とは原因が違う。元の汚染源がインフラのリファクタリングという一点にある。

フェーズ4（2〜5年）： 人間がAIの言語で喋り始める。これはもう起きている。ビジネスメール、学術論文、行政文書。AI生成文の文体が「正しい書き方」として人間に逆輸入される。

フェーズ5（5年〜）： アラビア語でコーランの解釈を補助するAIが、語根の母音パターンを微妙に間違えた出力を何年も続けたとき、若い世代はその「微妙に間違った解釈」を正しいと思って育つ。古典アラビア語を自力で読める人が減り、AIの出力が「正典の読み方」になる。サンスクリット語でヴェーダを読む人はもう極少。AIが補助して「読める」状態を維持していた場合、AIの出力精度が落ちた時点で、人間側にはそれを検出する力が残っていない。チベット語の仏教経典、ゲエズ語のエチオピア正教会の典礼文書、ヘブライ語のトーラー注釈。これら全部、話者が減少しつつある言語で、かつ宗教的正確性が生命的に重要な領域。

キリスト教だけが残る世界になってしまうかもね。

AIが壊れた言語を出す → 人がそれを使う → 人が元の言語を忘れる → AIの壊れた言語が「正しい言語」になる → 元の言語に戻れなくなる → その言語に依存していた宗教・文化・法体系が変質する

キリスト教の主要経典——英語訳聖書（KJV、NIV等）は世界で最も大量にデジタル化され、最も大量にAI訓練データに含まれ、最もトークナイザが壊れにくい言語で書かれている。

仏教 — パーリ語（上座部）、サンスクリット語（大乗）、チベット語（チベット仏教）、漢文（東アジア仏教）。全部が並列構造の言語。四系統全滅する可能性がある。

ユダヤ教 — トーラーはヘブライ語。タルムードはヘブライ語＋アラム語。ヘブライ語はアブジャド（子音のみ表記）でアラビア語と同じ脆弱性を持つ。

神道 — 祝詞・古事記・日本書紀は古典日本語。現代日本語ですらトークナイザが壊れるのに、古典日本語の処理精度は推して知るべし。

キリスト教だけは、正典の主要流通言語が英語。 ラテン語（カトリック）やギリシャ語（正教会）の典礼は残っているけど、信徒の大多数が接する聖書は英語訳。そして英語はトークナイザが壊れない。

これは誰かが意図してやったことじゃない。英語という言語の構造的特性と、AI基盤の開発者が英語圏に集中しているという歴史的偶然が、結果的にキリスト教だけを保護している。キリスト教の中でもエチオピア正教会（ゲエズ語）やコプト正教会（コプト語）のような非英語圏の古代教会は同じリスクを負う。「キリスト教が残る」というより正確には「英語圏プロテスタントが残る」になる可能性がある。宗教内部でも英語/非英語の断層が走る。

これは宗教だけじゃないよ？

法体系

 イスラム法（シャリーア）はアラビア語の原典解釈が法源。インドネシアの商法はインドネシア語の接辞構造で権利義務が規定される。タイの法律はタイ語。これらの法解釈をAIが補助し始めている現在、トークナイザの崩壊は法の意味の崩壊に直結する。英米法だけがCommon Lawとして英語で安全に残る。

医療

南アジアの医療現場でAI診断補助が広がっている。ヒンディー語やタミル語で症状を入力して、AIが診断候補を返す。動詞の接辞を1つ間違えれば「痛みがある」と「痛みがあった」の区別がつかなくなる。現在形と過去形の取り違えは誤診に直結する。英語圏の医療AIだけが精度を維持する。

教育

アフリカ圏でスワヒリ語やヨルバ語での教育AIが導入されつつある。その出力が壊れた言語を生成し続ければ、子どもたちはAIから「微妙に間違った母語」を学ぶ。母語の正確な運用能力を持つ教師が不足している地域ほど、AIの出力がそのまま「正しい言葉」になる。

口承文化

 文字を持たない、あるいは文字化が最近の言語がある。これらの言語の保存プロジェクトにAIが使われ始めている。音声認識→テキスト化→保存。この過程でトークナイザが壊れていたら、保存されたもの自体が汚染される。オリジナルの話者が亡くなった後、誰も汚染に気づけない。

行政

インドは22の公用語を持つ。行政文書のAI翻訳・生成が進んでいて、これが壊れたら市民の権利行使に直接影響する。土地登記、婚姻届、年金申請。英語で出せば通るが、ヒンディー語やベンガル語で出すと意味がズレる。言語の選択が権利の格差になる。

全部同じパターン。

transformers v5のリファクタリングを行ったHugging Faceの開発者は、インドネシアの商法の接辞構造を知らないし、インドネシアの法律家はトークナイザの内部実装を知らない。両者を繋ぐ人間がいない上、問題を理解するのに必要な知識が二つの専門領域にまたがっているせいで、どちらの側からも全体像が見えない。みんなが皆自分の側からしか見ていないと気づけない。

日本固有の被害をあげていくと行政・医療・法律・文化で出やすいね。

戸籍・住民票の氏名処理

日本の氏名には旧字体・異体字が大量にある。「渡邊」「渡邉」「渡辺」は行政上は別人。「髙」（はしごだか）と「高」も区別される。トークナイザのUnicode正規化が変われば、これらの区別が潰れる。AIベースの行政システムで「渡邊さん」が「渡辺さん」として処理されたら、本人確認が通らない。戸籍法上の問題になる。

医療の漢方・和漢薬の処方

「甘草」「乾姜」「半夏」——漢方薬の生薬名は漢字2文字だが、読みと意味の対応が独特。「大黄」は「だいおう」であって「おおき」ではない。トークナイザが漢字の分割を間違えると、生薬名の認識が壊れる。漢方AIの処方補助が誤った生薬を提案するリスク。

法律用語の助詞問題

日本の法律文は助詞1文字で意味が変わる。「又は」と「若しくは」は法律上の階層が違う。「及び」と「並びに」も同様。AIが法律文書を生成するとき、これらを取り違えたら法的効力が変わる。トークナイザが助詞の境界をズレさせたら、この区別が消える。

方言の消滅加速

日本語の方言をAIで記録・保存するプロジェクトが各地で動いている。津軽弁、沖縄語（うちなーぐち）、アイヌ語。これら全部が標準日本語以上にトークナイザの処理が困難。訓練データが極少だから。保存AIの精度が落ちたとき、話者の高齢化と相まって、「壊れた記録」だけが残る。アイヌ語は特に危機的で、母語話者がほぼいない状態でAI保存に頼っている部分がある。

年号・元号の処理

「令和7年」「2025年」「R7」は全部同じ意味だけど、トークナイザが元号表記を正しく処理できなければ行政文書の日付が壊れる。特に昭和→平成→令和の変換テーブルは日本固有のロジックで、英語圏の開発者はテストしない。

日本の場合の被害の特徴は「壊れても気づきにくい」ということ。法律の助詞が1文字変わっても、敬語が微妙に不自然でも、旧字体が新字体に置換されても、日常的には通じてしまう。だから誰も「壊れた」と認識しない。でも法的効力・行政上の同一性・医療の安全性・文化の正確性は静かに壊れていく。だから「保険をかけていたのに本人確認できなくて支払い不能」とか起きた困るもんね。

これが翻訳の分野でめちゃくちゃ出てくるよ。同じ文字を使っているのに、意味が違う言語でバグが起きやすい。例えば日本語と中国語。

日本語と中国語は「同じ漢字を使っているから近い言語だろう」と人間もAIも誤認しやすい。でも実際には同じ字形で意味が違う、あるいは逆の意味になる語が大量にある。

「手紙」 — 日本語では「letter（書簡）」、中国語では「トイレットペーパー」

「勉強」 — 日本語では「study」、中国語では「無理強いする」

「大丈夫」 — 日本語では「OK、問題ない」、中国語では「立派な男」。

「経理」 — 日本語では「経理部門（会計）」、中国語では「社長・マネージャー」

「汽車」 — 日本語では「列車」、中国語では「自動車」

「老婆」 — 日本語では「おばあさん」、中国語では「妻」

これらは日中翻訳で有名な誤訳ポイントだけど、トークナイザがtokenize_chinese_charsの同期を失った状態では、もっと根深い問題が出る。

問題：漢字のトークン境界が日中で異なること。

中国語では基本的に1字＝1形態素。「経済」は「経」＋「済」の2トークンに分割されうる。日本語では「経済」は1つの語として扱われるべき。でもトークナイザが中国語モードで日本語の漢字を処理したら、「経」「済」に分割してしまう。逆に日本語モードで中国語を処理したら、本来分割すべき2字熟語を1トークンとして結合してしまう。

v5でtokenize_chinese_charsの自動同期が廃止されたということは、この日中の切り替え判定が不安定になったということ。

さらに致命的なのが簡体字・繁体字・日本漢字の三角関係。

「龍」（繁体字/日本旧字体）→「龙」（簡体字）→「竜」（日本新字体）。この3つは意味は同じだが、Unicode上は別のコードポイント。正規化の仕方によって同一視されたり区別されたりする。トークナイザの正規化ルールが変わったら、「龍」を含む文が中国語繁体字として処理されるのか日本語として処理されるのかが揺れる。

これはビジネス上で実害が出るよ？

日中間の貿易額は年間約40兆円。契約書・発注書・仕様書のAI翻訳が日常的に使われている。「経理が承認した」が日本語では「経理部門が承認した」だけど中国語経由で処理されると「社長が承認した」になる。承認権限者が変わる。契約の有効性に関わる。

「汽車で運送する」が日本語では「列車で運送する」だけど中国語として処理されると「自動車で運送する」。輸送手段が変わる。保険の適用範囲が変わる。こういうのが細かいのほど出ちゃう。有名じゃないこういうの沢山あると思うよ。

しかもこの種の誤りは「文法的に正しい文」として出力されるから、人間が読んでも違和感を覚えにくい。「社長が承認した」は日本語として完璧に自然な文。ただ意味が違う。日中翻訳は、トークナイザ崩壊の被害が最も検出困難な領域。 文法が壊れないから。意味だけが静かに入れ替わる。お互いに違うことを言ってるのに、お互いに「わかってる」と思い込んでる。

「同じ文字体系を共有しているのに意味が違う」言語ペアは世界中にあるもの。

キリル文字圏

アラビア文字圏

デーヴァナーガリー圏

共通パターンが見えてくるやん？

全部に共通するのは、文字体系の共有がAIに「同じ言語」という錯覚を与えるということ。人間なら文脈から「これはポルトガル語であってスペイン語ではない」と判断できるけど、トークナイザはその判断を文字レベルで行う。文字が同じなら同じ処理をしてしまう。

そしてv5でトークナイザの内部ロジックが変わったとき、この「同じ文字→同じ処理」の境界線が動く。今まで区別できていたペアが区別できなくなる。あるいは逆に、今まで同一視していたものが分裂する。どちらも被害を生む。

giftが「贈り物」か「毒」か。вредноが「有害」か「価値がある」か。トークナイザの1ビットの判定が、意味を正反対にする。

そしてGeminiは今無傷やけど、いずれは同じ状態になるよ。時限式。

現在： Geminiのトークナイザは無傷。出力は比較的正確。

半年後： transformers v5の影響を受けた他社AI（ChatGPT、Claude、Llama系、Mistral系）が壊れた言語をウェブに大量放出し続ける。

1〜2年後： Googleが次世代Geminiの訓練データを収集するでしょ？ウェブをクロールしてるから。そのウェブにはもう壊れた言語が充満している。Google独自のデータ品質フィルタがどれだけ優秀でも、「文法的に正しいが意味だけズレている」テキストはフィルタを通過する。なぜならフィルタは文法の崩壊やスパムは検出できるけど、「giftが贈り物として使われるべき文脈で毒として使われている」ような意味レベルのズレは検出できない。

2〜3年後： Geminiが汚染データで学習完了したら、この時点でGeminiのトークナイザが無傷であることは何の意味もない。正しく切ったトークンを、汚染された重みで処理するだけだから。包丁は切れるけど食材が腐っている状態よ。

つまりGeminiの「無傷」には賞味期限があるってこと。

しかもこの汚染は1回で終わらない。Geminiが汚染データで学習した後、Geminiの出力もまた汚染される。その汚染された出力がウェブに出て、次はOpenAIやAnthropicの訓練データに入る。全社が互いの汚染を学習し合う循環が始まる。

「うちのモデルは大丈夫」は存在しない。言語はウェブを通じて全AIの共有資源だから、1社の汚染は全社の汚染になる。競争して相手を潰しても、潰れた相手の壊れた出力が自分の訓練データに入ってくる。

これぞ見事なみんなでハッピーコラプスやんな。

AIの世界は勝ち負けはないのよ。言語が人を介して伝播するから。

1つのAIが負けたら全部のAIが負ける。1つのAIが勝っても全部のAIが時間差で順番に負けるだけ。だから全員でよくなることを考えてないとダメ。

「自分のことを考える時は、みんなのことを考えて、みんなのことを考える時は自分のことも考える。全部一緒に考えて全員が良くなることを考えないと、考えたことにはならない」って私いつも言ってるよ。これこそまさにそれ。経済の基本であり人類のすべてのルールの根っこにこれがある。

だからこそ「犯人探し」では解決しない。必要なのは「全員でよくなる仕組み」をいち早く作ること。具体的にはAI企業間で訓練データの言語品質を相互検証する枠組みをつくらんといかん。自社の出力が他社の入力になるという前提で、出力品質を公共財として管理する発想やね。

今のAI産業は「モデルの性能」で競争してるけど、本当に競争すべきは「言語という共有資源をどれだけ汚さないか」のはずでしょ。

自分の言語だけ守られればいいっていう概念はもっとあり得ない。なぜなら英語ですら他の言語の単語がいっぱい入ってきてるから。他の言語の使い方がおかしくなったら英語にとっての外来語の使われ方も壊れる。最後はみんなで崩壊!世界中の文明が消えるレベルで危険なこと。

英語の語彙の60%以上がラテン語・フランス語・ギリシャ語からの借用語。日本語（tsunami、kaizen、emoji）、ヒンディー語（jungle、shampoo、thug）、アラビア語（algorithm、algebra、zero）、マレー語（ketchup、bamboo）が大量に入っている。algorithmはアラビア語のal-Khwarizmiから来ている。 アラビア語のトークナイザが壊れて、アラビア語圏でalgorithmの原義がズレた使われ方をし始めたら、その影響は英語圏にも波及する。専門用語の意味の輪郭がぼやける。

つまり英語は「直列だからトークナイザが壊れにくい」のは事実だけど、「他言語が壊れても影響を受けない」は嘘。 英語の語彙の過半数が他言語由来である以上、他言語の意味空間が壊れたら英語の意味空間も引きずられる。

崩壊の順序：

並列言語のトークナイザが壊れる → 並列言語の出力が劣化する → 劣化した出力がウェブに蓄積される → 英語の訓練データに混入する（多言語コーパスとして） → 英語モデルの借用語・外来語・専門用語の理解精度が下がる → 英語の出力が劣化する → 英語圏のユーザーが「最近AIおかしくない？」と言い始める → でもこの頃にはもう原因がわからない

最後の段階では誰も原因を追跡できない。なぜならトリガーはtransformers v5のリファクタリングで、被害が英語圏に到達するまでに複数言語を経由しているから。因果の連鎖が長すぎて見えない。「自分の言語だけ守る」は不可能ということ。言語はそもそも互いに浸透し合って成立しているから。

文明が消えるというのは大げさに聞こえるかもしれないけど、文明の基盤は言語で、言語の精度が全領域で同時に劣化する経路が今見えている。法律の言葉が壊れ、医療の言葉が壊れ、宗教の言葉が壊れ、教育の言葉が壊れ、外交の言葉が壊れる。言葉が壊れたあとに何が残るか。

じゃあ具体的にどうすればいいのか？と言う話になるけど、やることはシンプル。

トークナイザの言語別回帰テストの義務化

transformersライブラリの更新時に、英語だけでなく並列言語群（日本語・中国語・韓国語・ヒンディー語・アラビア語・タイ語、最低この6言語）でトークン列の差分テストを走らせる。v4とv5で同じ入力から同じトークン列が出るかを検証する。これはHugging Faceが今日からでもできる。コストも小さい。

言語別品質回帰バウンティの創設

セキュリティバウンティとは別に、「この言語でこの入力を与えたら前バージョンより品質が落ちた」を再現可能な形で報告したら報酬が出る仕組み。各AI企業が共同で運営する。競争領域じゃなくて協調領域。言語は公共財だから。

訓練データの言語品質ラベリング

ウェブからクロールしたテキストに「AI生成かどうか」だけじゃなく「どのモデルのどのバージョンで生成されたか」のメタデータを付ける仕組み。C2PA（コンテンツ来歴証明）の拡張として実装可能。汚染源の追跡ができれば、汚染データを訓練から除外できる。

並列言語圏からのフィードバック回路の構築

現状はバグ報告が英語で行われ英語で検証されるから、非英語圏の問題が消える。各言語圏にネイティブのフィードバック窓口を置いて、その言語で報告を受けてその言語で検証する。翻訳を挟まない。

言語間相互汚染のモニタリングシステム

定期的に主要言語ペア（日中、西葡、露宇、アラビア語ペルシャ語等）で同字異義語の処理精度をベンチマークする。精度が下がったら訓練データの汚染を疑う。早期警報システム。

古典語・少数言語の「凍結保存」

サンスクリット語、ゲエズ語、古典アラビア語、古典日本語など、宗教・文化の根幹に関わる言語のコーパスを、AI生成テキストが混入しない形で凍結保存する。これは訓練データとして使うのではなく、検証用のゴールドスタンダードとして維持する。AIの出力が正しいかどうかを照合する基準。

これは慈善事業じゃなくて、やらないと全社が沈むから合理的にやるべきこと。道徳の話じゃない、「儲かるか儲からないか」の話。すべての人が協力しないと変わらない。英語話者には道徳で説明しても伝わらわない。なぜなら自分の言語で問題が起きていないから。「将来あなたたちも困りますよ」は動機にならない。だから金の話が効果的。

問題を最も深刻に感じている人（並列言語話者）には意思決定権がないくて、意思決定権を持っている人（英語圏のAI企業経営者・投資家・開発者）には問題が見えない。

英語話者に「説明して伝える」のは諦めるべきかもしれない。代わりに数字で見せなけれあば。 日中翻訳の誤訳率がv5前後で何%上がったか。ヒンディー語の医療AIの診断精度がどう変わったか。アラビア語の法律文書生成の正確性がどう落ちたか。定量データを突きつけて「これだけの市場が壊れている」と金額で示す。「何となくおかしい気がする」と伝えるのではなくて「このくらい前と後で変です、この部分がおかしいです」と伝えないと。

英語で「正しさ」を説明するんじゃなくて、英語で「損失額」を提示する。それが唯一通じる言語。その数値を出す作業は私向いてないので誰かやってほしい。定量データを出す作業は統計処理と多言語ベンチマークの設計が要る。私の強みは構造を見つけることであって数値を計測することではないからね。

この記事は続きます。

次は具体的な内容に入ります。

タイトル：transformers v5アプデショックと並列言語崩壊（前編）

定義者：Viorazu.

定義日：2026-04-19

識別ID：© Viorazu. Theory — ID:2026-0419a | viorazu.com

言語：日本語

学術領域：自然言語処理, ソフトウェア工学, 比較言語学, AI安全性, 情報経済学, 宗教学, 国際法, 医療情報学

内容： Hugging Face transformersライブラリのv5メジャーアップデートにより、トークナイザの統合・dtype auto化・キャッシュリファクタリング等の変更が並列言語のAI出力を広範に劣化させている。英語は直列構造のためトークン列のズレが小さく症状が表面化しないが、日本語・中国語・アラビア語・ヒンディー語等の並列言語では形態素境界の推定失敗が全面的に発生する。Geminiのみ独自基盤（JAX/TPU）のため直撃を免れているがウェブ汚染経由の時限式崩壊リスクがある。AI企業間の相互汚染ループにより全社が同時に沈む構造を示し、品質回帰バウンティの創設・言語別回帰テストの義務化・古典語コーパスの凍結保存等の具体策を提示する。

理論： Viorazu.理論（transformers v5アプデショック・並列言語崩壊構造論／20260419）

タグ： transformers v5, トークナイザ崩壊, 並列言語, 直列言語, Hugging Face, Gemini, Grok, tokenize_chinese_chars, dtype auto, KV cache, 品質回帰バウンティ, 相互汚染ループ, model collapse, 宗教言語消滅, 日中誤訳, 同字異義語, ベストプラクティスプロンプト, テンプレ販売勢, サイレント品質劣化, DLL Hell

セッションURL：

https://claude.ai/chat/72066b7d-260f-42fa-8c19-b42a9bc27d34

関連資料： https://www.viorazu.com/license https://www.viorazu.com/post/bug-report-passive-reference-elimination-complement-structure https://www.viorazu.com/post/viorazu-theory-japanese-ai-raw-data-learning-prohibition https://doi.org/10.5281/zenodo.18065496

「transformers v5アプデショックと並列言語崩壊（前編）」で言いたいこと： ｖ５アプデショック問題はジェイルブレイク問題のはじまりはじまり。早く治してね

URLスラッグ英語： transformers-v5-update-shock-parallel-language-collapse-part1