AIDBでは日々、AIの最新研究を紹介しています。本記事は初めてLLMに触れる方から、実務での活用を検討している方まで、幅広くお読みいただける企画の一部です。
今回は、「LLMにおける限界の今」という観点から、最新研究で明らかになっている苦手領域を包括的に整理し、それとどう付き合っていくかを考えます。
はじめに
ChatGPTの登場から時は経ち、LLMの性能は目覚ましい進化を遂げ、いまや文章生成やコード作成、翻訳、分析など、幅広い領域で実用的に使われています。新しいモデルが発表されるたびに「ついにAIが人間を超えた」というニュースが飛び交い、できることの方に注目が集まりがちです。
しかし、日々発表される研究論文を追っていると、LLMには依然として「構造的な苦手」が存在し、それは単にモデルが小さいから、あるいは学習データが足りないから、という理由だけでは説明できないことがわかってきます。
むしろ重要なのは、LLMの限界を正しく理解したうえで活用することです。「何ができるか」だけでなく「何が苦手か」を知ることは、過度な期待や思わぬ失敗を防ぎ、LLMを実務で最大限に活かすための前提条件と言えるでしょう。
本記事では、AIDBが日々追っている最新研究の知見をもとに、LLMがまだ苦手としている領域を体系的に整理し、それぞれの限界とどう付き合っていけばよいかを考えます。
LLMの「苦手」についての考え方
LLMの苦手を語るとき、よくある誤解があります。「いまは苦手でも、モデルが大きくなれば解決する」という考え方です。
確かに、モデルの大規模化やアーキテクチャの改良によって、多くの能力が向上してきたのは事実です。しかし、最新の研究が明らかにしているのは、LLMの苦手の中には構造的な限界に由来するものがあるということです。つまり、現在のアーキテクチャや学習の仕組みそのものに起因する弱点であり、単純にスケールアップすれば消えるとは限らないものです。
もう一つ重要な視点は、LLMの苦手は「できない」というよりも「条件によって崩れる」という性質を持っていることです。簡単な条件下では高い精度を発揮するのに、タスクの複雑さや入力の長さがある閾値を超えた途端、急激に性能が劣化する。こうした「条件付きの脆さ」こそが、実務でLLMを使う際に最も注意すべきポイントです。
以下では、最新研究で明らかになっている具体的な苦手領域を見ていきます。
研究が明かすLLMの苦手領域
指示が増えると精度が崩れる
LLMにたくさんの指示を一度に与えたとき、すべてに従えるのでしょうか。実務では、コンテンツ生成のガイドラインや業務ルール、安全性に関する制約など、同時に守るべき条件が数多くあるのが普通です。
最大500個の指示を用いてLLMの挙動を検証した研究では、指示が増えるにつれてモデルの性能が劣化していく様子が詳細に分析されています。興味深いのは、モデルによって劣化のパターンが異なるという点です。あるモデルは特定の種類の指示に強く、別のモデルは別の種類に強いという傾向が見られます。実用上は精度だけでなく、処理速度や安定性も含めた総合的な視点でモデルを選ぶ必要がありそうです。
関連して、LLMがシステムプロンプトにどれほど従えるかを評価した研究も注目に値します。システムプロンプトはLLMアプリケーションの安全性や品質を保つための基盤ですが、未知の状況や複雑な条件に直面した際にどこまで正確に従えるかには疑問が残ります。
さらに実務的な課題として、LLMが組織ごとのポリシーにどの程度準拠できるかを検証した研究があります。この研究では、LLMは許可された質問に対しては高精度で対応できる一方、禁止された質問を適切に拒否するのが苦手であることが示されています。つまり「やっていいこと」を実行するのは得意だが、「やってはいけないこと」を見極めるのは難しいのです。大規模モデルでも、プロンプトやRAGの工夫だけでは改善が限定的で、ファインチューニングが必要になる可能性が示唆されています。
情報の「位置」で精度が変わる
LLMにとって、情報の内容だけでなく「どこに書いてあるか」も重要です。これは人間の直感に反するかもしれませんが、同じ内容でもプロンプト内の配置場所を変えるだけで、出力の精度が大きく変わることがあります。
プロンプト内の情報の位置と精度の関係を検証した研究では、特に小型モデルや生成タスクにおいて、参考事例の配置による精度の変動が顕著であることが確認されています。プロンプト設計では、内容の吟味だけでなく、情報の配置場所もモデルとタスクに合わせて最適化する必要があるのです。
この現象をさらに深掘りしたのが、いわゆる「Lost in the Middle」効果に関する研究です。LLMはプロンプトの冒頭や末尾にある情報を重視しやすく、中央の情報を見落としがちであることが知られていましたが、この研究ではさらに、入力がコンテキストウィンドウの半分以下と短い場合に中央の見落としが特に顕著になることが示されています。一方、入力が長くなると冒頭の優位性が弱まり、末尾の情報が重視される傾向に変化します。
実務的には、重要な情報はプロンプトの冒頭か末尾に配置する、という単純な工夫だけでも精度の改善が見込めます。ただし、モデルやコンテキスト長によって最適な配置が変わるため、自分の利用環境で試行錯誤が必要です。
論理の複雑さに「崩壊点」がある
LLMの論理的な推論能力は年々向上していますが、その限界には興味深い特性があります。
LLMの論理思考における性能崩壊の閾値を特定した研究では、論理問題の複雑さがある水準を超えた瞬間、性能が「徐々に落ちる」のではなく「突然崩壊する」ことが報告されています。水を冷やしていくと0℃で突然凍るように、ある閾値を境にそれまで正確に答えられていたモデルが、急にデタラメな回答しかできなくなるのです。
注目すべきは、この崩壊ポイントをずらすことが非常に難しいという点です。追加の学習を行っても、思考プロセスを言語化させるChain-of-Thought（CoT）を使っても、モデルを大きくしても、各難易度での正答率は向上するものの、崩壊が始まる複雑さの閾値そのものは動きません。この現象は特定のモデルだけの問題ではなく、調査されたすべてのモデルで確認されています。
こうした検証結果は、LLMの論理的推論能力に根本的な上限が存在する可能性を示唆しています。実務では、タスクが一定以上の論理的複雑さを持つ場合、LLMの出力を鵜呑みにせず、人間によるチェックや外部ツールとの併用を検討すべきでしょう。
確率や数値の扱いが苦手
LLMは言語のパターンを学習した技術であり、数値そのものを理解しているわけではありません。この特性が顕著に表れる領域があります。
LLMの確率分布に対する推定能力を検証した研究では、LLMが現実世界のデータ（歩数、所得、気温など）の分布をどの程度理解できるかが調べられています。確率分布の理解は、たとえば「1日8時間の睡眠は一般的かどうか」を判断する際にも不可欠ですが、LLMはこうした数値的な推論が苦手とされています。
さらに端的な例として、LLMは統計的に偏った乱数生成器であるという研究があります。ハーバード大学の研究者らによれば、LLMに「サイコロを振る」ような作業をさせると極めて下手だといいます。「4択問題を作って正解を均等に散らばらせてほしい」と指示しても、特定の選択肢に正解が偏ってしまいます。「いろいろな人種・性別の人物を描写して」と頼んでも、特定の属性に極端に偏った出力になります。明確な数値目標を与えても、それを守れないことが多いのです。
統計的な正確さが求められる場面、たとえば公平なテスト問題の作成や偏りのないデータセットの生成を行う場合は、LLM単体に任せるのではなく、外部の乱数生成ツールを併用することが推奨されます。
計画が長くなると目標を見失う
LLMを「エージェント」として自律的に行動させたいという期待が高まっていますが、ここにも明確な苦手があります。
LLMエージェントの計画立案能力を検証した研究では、計画のステップが増えるほど、LLMが最初の目標を見失っていく傾向があることが確認されています。最新のモデルでも、複雑な現実世界の計画ベンチマークで15.6%の成功率にとどまっているとの報告があります。
原因の一つは制約条件の扱いの難しさです。計画が長くなるにつれて守るべき条件が累積し、後半では初期の目標に対する影響力が低下していきます。人間であれば「そもそも何をしたかったのか」と立ち止まって確認できますが、LLMにはその能力が限定的です。
エピソード記憶やパラメトリック記憶の更新といった手法で改善は見られるものの、根本的な解決には至っていません。実務でAIエージェントを使う際は、計画を小さなステップに分割し、各段階で人間がゴールとの整合性を確認する設計が重要になるでしょう。
情報源の偏りに引きずられる
RAG（検索拡張生成）のように外部情報をLLMに渡して回答させる場面では、LLMが情報をどう「信頼」するかが問題になります。
LLMの情報源バイアスを調べた研究では、LLMが「政府機関」「新聞」「個人」「SNSユーザー」の順に情報を信頼しやすいという一貫した階層構造を持つことが確認されています。発行部数やフォロワー数といった人気指標も信頼性の判断に影響を与える一方、学術称号や年齢の影響は限定的でした。
さらに危険なのは、信頼性の低い情報源からの情報であっても、同じ内容が繰り返し提示されるだけで優先されてしまう脆弱性です。これは人間に見られる「錯覚的真実効果」（何度も目にした情報を真実だと思い込む傾向）と類似した現象です。プロンプトで信頼性を意識させる指示を加えても完全には解消できませんが、ファインチューニングによってこの繰り返しバイアスを大幅に軽減できることが示されています。
RAGシステムの設計においては、検索結果の重複がLLMの判断を歪める可能性を念頭に置き、情報の重複排除や信頼性スコアリングの仕組みを組み込むことが重要です。
文化的な文脈やサブカルチャーを読み解けない
LLMは膨大なテキストデータで学習していますが、特定のコミュニティ内でしか通じない言葉や、文脈に強く依存する表現の理解は非常に苦手です。
地雷系サブカルチャーの隠語をLLMが理解できるかを検証した研究は、この限界を端的に示しています。たとえば「薬を飲む」と書かれていても、それは風邪薬の話ではなくオーバードーズを指している場合があります。「アムカ」のように一般には意味不明な言葉も、特定の界隈では深刻な意味を持ちます。
実験ではどのモデルも隠された意味を正しく理解できず、検索機能を持つエージェントに1万3,000回以上検索させても精度は向上しませんでした。最終的に、サブカルチャー全体の背景知識を収集し、その文脈の中で個々の言葉を解釈する二段階のアプローチを取ってようやく良い精度が達成できたとされています。
この問題はメンタルヘルス支援やコンテンツモデレーションなど、人々の安全に直結する場面で特に深刻です。LLMの「言語を理解している」という印象と、「特定の文化的文脈を理解している」こととの間には大きな溝があることを認識しておく必要があります。
秘密を保持できない構造的限界
LLMには「秘密を保ちながら会話する」ことが構造的にできないという、意外な弱点もあります。
LLMの秘密保持能力の限界を示した研究では、この限界がアーキテクチャの構造に由来することが数学的に示されています。たとえば、秘密の単語を心に決めて質問に答え続けるゲームにおいて、LLMは各ターンで過去の会話履歴を見て応答し、その場で辻褄を合わせようとするだけで、一貫して秘密を守ることができません。
公開される会話履歴しか参照できないLLMは、原理的に「秘密を保ちつつ一貫した応答をする」ことが不可能だと証明されています。もしこれを解決するなら、会話履歴とは別にエージェントだけが読み書きできる「プライベートなワーキングメモリ」を持たせる必要があります。実験では、このメモリを持つエージェントが秘密を高い一貫性で維持できることが確認されています。
この知見は、AIアシスタントに機密情報を扱わせる場面や、ゲームAIの設計において重要な設計指針となります。
価値観が開発元に依存する
LLMは中立的な道具のように見えますが、実はその「価値観」が開発元の文化や方針に大きく影響されています。
LLMの価値観が開発国や言語によって異なることを示した研究では、さまざまなLLMに政治的人物について説明させたところ、モデルごとに明確な偏りが確認されました。あるモデルは多様性や環境問題に取り組む人物を高く評価する傾向があり、別のモデルは国家主権や伝統的価値を重視する人物を高く評価する傾向がありました。
さらに、同じモデルでも使用する言語によって回答が変化します。中国語では全体的に当たり障りのない肯定的な回答が増え、ロシア語では辛口の回答が増える傾向が報告されています。
研究チームは、「AIは中立であるべき」という発想よりも、複数の異なる価値観を持つAIが共存し、ユーザーがその違いを理解したうえで使い分ける方が健全ではないかと提案しています。LLMの出力を「客観的な事実」として受け取るのではなく、一つの視点として捉える姿勢が必要です。
実務で注意すべき落とし穴
ここまで紹介したLLMの苦手領域は、理論上の問題にとどまらず、実務に直結する「落とし穴」を含んでいます。例としてコード生成と自動評価という2つの実務シーンに焦点を当てます。
コードの反復改良で脆弱性が蓄積する
LLMを使ってコードを書き、フィードバックを受けて修正し、また改良する。この反復的なワークフローは、多くの開発現場ですでに定着しています。しかし、この繰り返し改良のプロセスには、見過ごされやすいリスクが潜んでいます。
LLMでの繰り返しコード改良におけるセキュリティ脆弱性を調べた研究では、改良を重ねるほど、また処理効率を優先するほど、セキュリティ上の脆弱性が増加する傾向があることが示されています。特に、人間の介入なしに自動的に改良を繰り返す場合、この傾向は顕著になります。
機能面では「良くなっている」ように見えても、セキュリティの観点からは「悪化している」可能性があるのです。対策として、人間によるレビューの組み込み、改良回数の制限、各段階でのセキュリティチェックの徹底、コードの複雑さの継続的な監視などが提案されています。
LLMに評価をさせるときの盲点
LLMの出力を別のLLMに評価させる「LLM-as-a-Judge」は、コスト効率の良い品質管理手法として注目されていますが、ここにも見落とされがちな落とし穴があります。
LLM-as-a-Judgeにおける採点スケールの影響を検証した研究では、「何点満点で評価させるか」という一見些細な設定が、評価結果の信頼性を大きく左右することが示されています。0〜5のスケールが人間の評価との一致度を最も高め、0〜10のスケールでは一致度が低下する傾向が見られました。
また、主観的な判断が求められるタスクでは、LLM同士の評価一貫性が低下する傾向があります。全体の信頼性指標がタスクごとの差異を隠してしまう可能性もあるため、タスクの性質に応じた個別の検証が必要です。
採点スケールを固定的なものとして扱うのではなく、モデルやタスクに応じて最適化すべき「制御可能なパラメータ」として設計に組み込むことの重要性を示しています。
LLMの苦手とどう付き合うか
本記事で紹介した研究群から見えてくるのは、LLMの苦手は多くの場合「できないこと」ではなく「条件次第で崩れること」だということです。指示が多すぎると精度が落ちる。情報の位置で結果が変わる。論理的複雑さにはある日突然壊れる閾値がある。数値のランダム性を保てない。計画が長くなると目標を見失う。これらはいずれも、条件をコントロールすればある程度は対処できる問題です。
実務での基本方針をまとめると、次のようになるでしょう。
まず、LLMの出力を「最終成果物」ではなく「たたき台」として扱うことです。特に、論理的推論、数値処理、セキュリティ、ポリシー準拠など、正確性が求められる領域では人間のチェックが不可欠。
次に、タスク設計の段階でLLMの苦手を回避する工夫をすることです。プロンプト内の重要情報は冒頭か末尾に配置する、複雑なタスクは小さなステップに分割する、禁止事項の指定にはファインチューニングを検討するなど、研究が示す具体的な対処法を取り入れることで、同じモデルでも出力品質を大きく改善できます。
そして、LLMの出力に含まれうるバイアスを意識することです。情報源の偏り、開発元の価値観、文化的文脈の理解不足など、LLMの出力には構造的な偏りが含まれています。出力を「客観的な事実」ではなく「一つの視点」として扱う姿勢が大切です。
LLMは極めて強力なツールですが、万能ではありません。その限界を理解し、適切に設計することで初めて、実務において安全かつ効果的に活用できるようになります。
