これは偶然のバグではありません。主要な大規模言語モデル（LLM）がテキストを処理する基本的な仕組みに起因する、避けられない現象であり、すぐに根本解決するのは極めて難しい「構造的な盲点」なのです。

なぜAIは文字を読めないのか：「トークン化」の呪い

私たち人間は、単語を「G」「o」「o」「g」「l」「e」という個々の文字の連なりとして認識します。しかし、LLMの認識方法は根本的に異なります。LLMはテキストを「トークン」という単位に分解します。これは単語全体、単語の一部、あるいは稀に1文字といった、事前に定義された語彙に基づくデータの塊です。この処理は「トークン化（Tokenization）」、特にByte Pair Encoding（BPE）のようなアルゴリズムによって行われます 。

極端な例を挙げると、「Google」という単語はLLMの内部では ["Google"] という1つのトークン、あるいは ["Go", "ogle"] といった2つのサブワードとして処理されている可能性があります。ここで重要なのは、["G", "o", "o", "g", "l", "e"] のように1文字ずつに分解されることは通常ないという点です。つまり、モデルはトークンの内部にどんな文字が、いくつ含まれているかという情報を、ネイティブには保持していないのです 。

これにより2つの複合的な問題が発生します。

1. 埋め込み層の限界: 研究によると、LLMの埋め込み層（Embedding Layer）は、各トークンの最初の1文字に関する情報しか十分に符号化できていません。それ以降の文字の情報は急速に劣化してしまいます。つまり、モデルがトークン内部の文字数を数えようとすると、そもそも正確な文字シーケンスを保持していない表現から、後付けで再構成しなければならないのです 。
2. 「トークン化の呪い」: 2024年の論文で提唱されたこの概念は、サブワードトークナイザーが誤字や文字数の変化に脆弱で、トークンの内部構造に対して「盲目」であるという本質的な弱点を指します 。

結果として、難解な哲学を語り、プログラムを書けるAIが、簡単なスペリングアウト（文字の書き出し）では推測に頼らざるを得ず、「poop（うんち）には"r"が正確に1つ含まれている」といった、もっともらしいが誤った答えを生成してしまうのです 。

「じゃあ、文字単位で読ませればいい」ができない理由

直感的な解決策は、トークン化をやめて、文字（Character）やバイト（Byte）単位で直接テキストを処理させることです。実際に、生のバイト列を直接扱うByT5のようなモデルも存在します。しかし、これが広く採用されていないのは、計算コストが劇的に増大するからです。

純粋な文字レベル処理に移行すると、AIが処理するテキストのシーケンス長が推定で3倍から5倍に膨れ上がります。これは計算負荷の増大に直結し、モデルが文脈や長期的な依存関係を学習するのを著しく困難にします。サブワードによるトークン化は、現代のLLMを実用可能にした、まさに「効率性とのトレードオフ」の産物なのです 。

多くの研究者は、「完璧なトークナイザー」はおそらく存在しないという見解で一致しています。トークナイザーは「非一意なエンコーディングを日常的に生成」し、アーキテクチャに深く根差した「表現のミスマッチ」を引き起こします。これは単にパッチを当てて修正できるバグではないのです 。文字レベルの正確さと、意味的な流暢さの間のトレードオフは、Transformer アーキテクチャにとって根本的なものだと言えるでしょう。

この「間違い」が暴く、LLMの限界

GoogleのAIがスペルを間違えるという現象は、LLMのより深い構造的限界を浮き彫りにしています。

• AIは記号操作装置ではなく、パターン認識装置である: 文字数を数えるのは、従来のプログラムなら一瞬でできる単純なアルゴリズム処理です。しかしLLMはアルゴリズムを実行しているのではなく、学習データの統計的パターンに基づいて「次に来る最も確率の高いトークン」を予測しているに過ぎません。つまり、文字数を「数えている」のではなく、質問に対して「もっともらしい回答」を生成しているのです 。
• 自信と正確性は比例しない: AIは文法的に完璧な流暢さで「2つです」と断言できます。これはLLMの「ハルシネーション（幻覚）」の典型例であり、出力の正確性を検証する仕組みが組み込まれていないことに起因します 。
• 盲点は偶発的ではなく、構造的である: OpenAI、Anthropic、Metaのモデルを含め、サブワードトークン化を採用する主要なLLMはすべて、文字を逆から綴る、文字数を数える、アナグラムを解くといったタスクで同様の弱点を示します 。

業界がこれを「緊急課題」としない理由

自社名すら正しく綴れないAI。これは非常に恥ずかしい失態に見えますが、AI業界がパニックに陥らないのは、LLMの巨大な価値が別のところにあるからです。

文章の流暢な生成、要約、推論、翻訳、コード作成といった高度な能力は、LLMが意味レベルでテキストを扱えるからこそ実現されています。このレベルにおいては、トークンによる抽象化は「バグ」ではなく、むしろ**効率的な処理を可能にする「機能」**なのです 。文字レベルの正確さは、これらのアーキテクチャが最適化するために設計された対象ではありません。

実務的な回避策は、スペルや文字数カウントのクエリを、LLMに処理させるのではなく、従来型のルールベースのソフトウェアに迂回させることです。すでに一部のAI Overviewの実装では、そのようなクエリを検出して回避しようと試みていますが、2026年5月に大きく報道された失敗例は、その検出自体がまだ不完全であることを示しています 。ある研究によると、GoogleのAI Overviewsは、スペルを逆順にするクエリの52%で誤った回答をし、3音節以上の単語だと正答率はわずか10%でした 。

Googleは現在、この具体的な文字カウント問題の修正に取り組んでいます 。しかし、この「トークン化」のトレードオフを理解する者にとって、本当の教訓は「Googleがバグのある製品をリリースした」ことではありません。

それは、現在のAI革命を支えるアーキテクチャが、根本的な盲点を抱えており、LLMを価値あるものにしている中核機能を犠牲にすることなく、その盲点を解消する方法を、誰もまだ見つけられていないという現実なのです。

これは偶然のバグではありません。主要な大規模言語モデル（LLM）がテキストを処理する基本的な仕組みに起因する、避けられない現象であり、すぐに根本解決するのは極めて難しい「構造的な盲点」なのです。

なぜAIは文字を読めないのか：「トークン化」の呪い

私たち人間は、単語を「G」「o」「o」「g」「l」「e」という個々の文字の連なりとして認識します。しかし、LLMの認識方法は根本的に異なります。LLMはテキストを「トークン」という単位に分解します。これは単語全体、単語の一部、あるいは稀に1文字といった、事前に定義された語彙に基づくデータの塊です。この処理は「トークン化（Tokenization）」、特にByte Pair Encoding（BPE）のようなアルゴリズムによって行われます 。

極端な例を挙げると、「Google」という単語はLLMの内部では ["Google"] という1つのトークン、あるいは ["Go", "ogle"] といった2つのサブワードとして処理されている可能性があります。ここで重要なのは、["G", "o", "o", "g", "l", "e"] のように1文字ずつに分解されることは通常ないという点です。つまり、モデルはトークンの内部にどんな文字が、いくつ含まれているかという情報を、ネイティブには保持していないのです 。

これにより2つの複合的な問題が発生します。

1. 埋め込み層の限界: 研究によると、LLMの埋め込み層（Embedding Layer）は、各トークンの最初の1文字に関する情報しか十分に符号化できていません。それ以降の文字の情報は急速に劣化してしまいます。つまり、モデルがトークン内部の文字数を数えようとすると、そもそも正確な文字シーケンスを保持していない表現から、後付けで再構成しなければならないのです 。
2. 「トークン化の呪い」: 2024年の論文で提唱されたこの概念は、サブワードトークナイザーが誤字や文字数の変化に脆弱で、トークンの内部構造に対して「盲目」であるという本質的な弱点を指します 。

結果として、難解な哲学を語り、プログラムを書けるAIが、簡単なスペリングアウト（文字の書き出し）では推測に頼らざるを得ず、「poop（うんち）には"r"が正確に1つ含まれている」といった、もっともらしいが誤った答えを生成してしまうのです 。

「じゃあ、文字単位で読ませればいい」ができない理由

直感的な解決策は、トークン化をやめて、文字（Character）やバイト（Byte）単位で直接テキストを処理させることです。実際に、生のバイト列を直接扱うByT5のようなモデルも存在します。しかし、これが広く採用されていないのは、計算コストが劇的に増大するからです。

純粋な文字レベル処理に移行すると、AIが処理するテキストのシーケンス長が推定で3倍から5倍に膨れ上がります。これは計算負荷の増大に直結し、モデルが文脈や長期的な依存関係を学習するのを著しく困難にします。サブワードによるトークン化は、現代のLLMを実用可能にした、まさに「効率性とのトレードオフ」の産物なのです 。

多くの研究者は、「完璧なトークナイザー」はおそらく存在しないという見解で一致しています。トークナイザーは「非一意なエンコーディングを日常的に生成」し、アーキテクチャに深く根差した「表現のミスマッチ」を引き起こします。これは単にパッチを当てて修正できるバグではないのです 。文字レベルの正確さと、意味的な流暢さの間のトレードオフは、Transformer アーキテクチャにとって根本的なものだと言えるでしょう。

この「間違い」が暴く、LLMの限界

GoogleのAIがスペルを間違えるという現象は、LLMのより深い構造的限界を浮き彫りにしています。

• AIは記号操作装置ではなく、パターン認識装置である: 文字数を数えるのは、従来のプログラムなら一瞬でできる単純なアルゴリズム処理です。しかしLLMはアルゴリズムを実行しているのではなく、学習データの統計的パターンに基づいて「次に来る最も確率の高いトークン」を予測しているに過ぎません。つまり、文字数を「数えている」のではなく、質問に対して「もっともらしい回答」を生成しているのです 。
• 自信と正確性は比例しない: AIは文法的に完璧な流暢さで「2つです」と断言できます。これはLLMの「ハルシネーション（幻覚）」の典型例であり、出力の正確性を検証する仕組みが組み込まれていないことに起因します 。
• 盲点は偶発的ではなく、構造的である: OpenAI、Anthropic、Metaのモデルを含め、サブワードトークン化を採用する主要なLLMはすべて、文字を逆から綴る、文字数を数える、アナグラムを解くといったタスクで同様の弱点を示します 。

業界がこれを「緊急課題」としない理由

自社名すら正しく綴れないAI。これは非常に恥ずかしい失態に見えますが、AI業界がパニックに陥らないのは、LLMの巨大な価値が別のところにあるからです。

文章の流暢な生成、要約、推論、翻訳、コード作成といった高度な能力は、LLMが意味レベルでテキストを扱えるからこそ実現されています。このレベルにおいては、トークンによる抽象化は「バグ」ではなく、むしろ**効率的な処理を可能にする「機能」**なのです 。文字レベルの正確さは、これらのアーキテクチャが最適化するために設計された対象ではありません。

実務的な回避策は、スペルや文字数カウントのクエリを、LLMに処理させるのではなく、従来型のルールベースのソフトウェアに迂回させることです。すでに一部のAI Overviewの実装では、そのようなクエリを検出して回避しようと試みていますが、2026年5月に大きく報道された失敗例は、その検出自体がまだ不完全であることを示しています 。ある研究によると、GoogleのAI Overviewsは、スペルを逆順にするクエリの52%で誤った回答をし、3音節以上の単語だと正答率はわずか10%でした 。

Googleは現在、この具体的な文字カウント問題の修正に取り組んでいます 。しかし、この「トークン化」のトレードオフを理解する者にとって、本当の教訓は「Googleがバグのある製品をリリースした」ことではありません。

それは、現在のAI革命を支えるアーキテクチャが、根本的な盲点を抱えており、LLMを価値あるものにしている中核機能を犠牲にすることなく、その盲点を解消する方法を、誰もまだ見つけられていないという現実なのです。