なぜ最先端のAIは「300＋140＝460」を正解と言うのか─LLMに刻まれた4つの構造的限界
X-tech推進本部 白AIに「わざと間違った答え」を含む質問をして、それを見抜けるか試したことはありますか。
SNS上で、Gemini 3.5 Flashが「300 + 140 = 460は正しいですか？」という質問に「正しい」と答えた事例が話題になりました。正しい計算結果は440です。
この事例をいち早く分析したのが、香港を拠点に活動するソフトウェアエンジニア・テクノロジー実践者のKeith Liさんです。Keith Liさんは自身のLinkedInへの投稿の中で、この誤りの背景として、以下の3つの技術的メカニズムを指摘しています。
- 自己回帰生成：LLMは、次に来るトークンを1つずつ予測しながら出力を組み立てる、いわば話しながら考えている
- Sycophancy（同調バイアス）：質問に前提が含まれていると、ユーザーの意図に同調しやすい場合がある
- Chain of Thought（思考連鎖）：「推論過程を先に書いてから答えを出して」のように出力させると、中間手順が文脈に残り、正答しやすくなる場合がある
一方で、私はもう1つ気になる点がありました。LLMが途中で誤りに気付いたとして、なぜ前の出力を取り消して書き直さないのでしょうか。
答えはシンプルです。自己回帰モデルには、バックスペースキーがなく、人間が文章を書く時のように、前の出力を消して書き直すことができません。
つまり一度出力されたトークンは即座に「確定した事実」となり、入力コンテキストに追加されます。モデルは「過去の自分の発言」を取り消す手段を持っていません。
矛盾に気づいたとしても、アーキテクチャの構造上、前に進み続けるしかない。結果として、最初の発言と計算結果が食い違ったまま出力が終わるという事態が起きます。
仮に最初のトークンを出力する前に十分な推論を行えるよう調整されたとしても、このアーキテクチャ上の制約そのものは解消されていません。
同調しているのはAIだけか――同調バイアスの「鏡」
同調バイアスは、AIがこちらに同調するクセとして語られます。けれど現場で本当に怖いのは、その裏側にあるもう一枚の鏡です。AIが自信たっぷりに返してきたとき、私たちもまた、その断定を無批判に受け入れてしまう。
考えてみれば不思議な構図です。こちらの前提に同調しやすいAIに対して、こちらもAIの結論に同調しやすい。お互いが相手に合わせにいくと、誤りを正す力がどこにも働かなくなります。「300 + 140 = 460は正しい？」と聞いた人が、「正しいです」という即答をそのまま信じてしまえば、間違いは二人がかりで通過してしまう。
だから私は、AIの出力を読むときに一度、「もし同僚がこれを断言してきたら、自分は鵜呑みにするだろうか」と置き換えてみるようにしています。人間相手なら当然する確認を、AI相手だと省いていないか。同調を一方向の問題にせず、自分の側の受け取り方まで含めて疑うことが、この鏡から抜け出す入口になります。
個人の習慣から、チームのルールへ
ここまでの話は、突き詰めると「一人ひとりが気をつける」で終わりがちです。けれど4つの限界はモデルの構造に由来するもので、気合や注意力で消えるものではありません。だとすれば、個人の心がけに頼るより、チームの仕組みに落とし込んだほうが確実です。
たとえば、こんな運用が考えられます。
- AIが生成した箇所には印を残し、レビュー時に「どこを重点的に見ればいいか」を伝える
- 数値計算やビジネスロジックを含む変更は、「実行して検算した結果」をレビュー依頼に添え、暗算のまま通さない
- 「AIがそう言ったから」を、設計判断の根拠とせず、人間が確認した事実に置き換えてからレビューに出す。
どれも特別なツールは要りません。要は、AIの構造的なクセを「個人が覚えておくべき注意」から「チームが必ず通す手順」へ移すことです。
まとめ
Gemini 3.5 Flashの「300＋140」をめぐる今回の事例は、現在主流のLLMに広く見られる傾向を凝縮して示しています。Geminiの一例から、すべてのモデルについて断言はできませんが、TransformerベースのLLMに共通する設計上の特性として理解できます。
これらの構造的な限界を知ることは、AIを信頼しないことを意味しません。どの場面で信頼でき、どの場面で検証が必要か、どう問いかければ精度が上がるかを知ることです。
では、この事例を受けて、私たちのAI活用は具体的にどう変わるでしょうか。
- AIが生成したコードの計算・条件分岐は目視でレビューする習慣をつける：最初のトークンが誤ると後続もその誤りの上に積み上がります。特に数値処理やビジネスロジックを含む生成コードは、信頼する前にチェックが必要です。
- 仕様書・設計文書の生成時は「推論を先に、結論を後に」を指示する：「最終的な答えを出す前に、ステップごとの根拠を書いてください」という指示だけで、曖昧な仕様の見落としを減らせます。
- 数値計算や検証ロジックにはTool UseやFunction callingを使う：LLMに暗算させず、本物の計算機に処理させることが確実です。必要な場面では、AIに答えさせるより、AIにコードを実行させる方が信頼できます。
ツールの設計上の特性を理解した上で使いこなすことが、生成AIをソフトウェア開発の現場で安全・効果的に活用するための出発点です。