LLM の能力と限界の由来

この記事の目的

「なぜ流暢な文章は得意なのに桁の大きい計算を間違えるのか」「なぜツールを持たせると解決するのか」を構造から理解し、タスクを任せる前に能力の見積りを外さない判断ができるようになります。10 章(LLM 基礎)の総仕上げとして、生成・トークン・学習の理解をタスク設計の実務に接続します。

対象読者

「これは LLM にできるか」を企画・設計段階で見積もる立場のエンジニア・テックリード
デモの流暢さと本番の正確さのギャップに驚いた経験がある人

前提知識

LLM はどうやってテキストを生成するか — 次トークン予測という形式
LLM の学習パイプライン(事前学習から選好調整まで) — 能力と癖の作られ方
ツール使用 — 限界を補う中核機構(本記事はその「なぜ」)

本文

概要: 流暢さと正確さは別の能力

「こんなに流暢なら、これもできるだろう」という印象だけでは、LLM の能力を見積もれません。「自然に読める出力」と「要求を満たす正しい出力」は別に評価します。流暢さも正確さも、モデル・言語・入力・タスクに依存します。ツール・検証・設計で補う箇所を、実際の失敗から決めます。

得意と不得意の構造

以下は評価計画を作るための整理です。学習データの内訳が非公開のモデルでは、得手不得手の原因をデータ量だけで断定できません。「苦手」は不可能という意味でもなく、採用モデルと入力条件で再検証します。

傾向	タスクの例	由来
得意	要約・翻訳・言い換え・分類・トーン調整	「テキスト → テキスト」の変換パターンが学習データに大量にある
得意	コードの生成・説明・修正	学習データが豊富で、構文パターンが強く、実行・テストで検証もできる
苦手	桁の大きい計算・厳密な集計	計算はパターン補完ではなくアルゴリズムの実行が必要。トークン列の操作でそれを模倣している
苦手	文字数指定・特定文字の数え上げ	モデルはトークン単位で処理しており、文字を直接「見て」いない(トークナイザとトークン経済)
苦手	最新情報・ニッチな事実	学習データの期限と頻度に依存する(LLM の学習パイプライン)。穴はもっともらしく補完される(幻覚)
要検証	長い厳密な手順の遂行	文脈中に途中結果を書けても、検証が正しいとは保証されない。コード実行・既知値照合を加える

この表からの設計指針は、厳密さが必要な箇所に、生成とは独立した検証手段を用意することです。要約や翻訳にも意味の正確性が必要なので、「得意」の欄だけを理由に検証を省きません。

ツールによる補完: Agent 設計の理論的根拠

苦手の多くは、外部の道具で正確に解ける種類の問題です。

計算・集計 → コード実行・電卓ツール
最新情報・ニッチな知識 → 検索・RAG(RAG と Agent の関係・使い分け)
正確な操作・状態変更 → API 呼び出し(判断はモデル、実行は決定的なコード)

ツールを使うと、計算や照会を専用の処理へ移せます。ただし、ツール・引数・解釈の誤りは残るため、道具を持たせるだけで解決とはしません。例えば Toolformer は、計算機・検索などのツールを使う学習で対象評価の改善を報告していますが、任意の Agent の正確性を保証する結果ではありません。

世代差とスケーリングの読み方

モデルの能力は世代とともに動きます。見積りを陳腐化させないための読み方を 3 つ挙げます。

「できなかった」には日付を付ける: 能力の評価は世代で覆ります。「LLM には無理」ではなく「このモデルでは、この試し方では無理だった(いつ時点)」と記録し、新世代で再評価します(バージョニング・デプロイ・モデル更新追従)
推論に時間を使うモデルの登場: 応答前に長く考える(推論トークンを使う)ことで複雑な問題の正答率を上げるアプローチが、2026 年時点では広く使われています。難しい問題への正確さと、レイテンシ・コストのトレードオフとして扱います(モデル選定ガイド)
ベンチマークと実能力の乖離: 公開ベンチマークのスコアは、ハーネス依存・汚染・飽和により実力を過大にも過小にも見せます。世代差の把握は参考にしつつ、自社タスクでの実測を正とします(エージェントベンチマークの全体像)

能力見積りの実務

「できそうでできない」を企画段階で見抜くための、簡潔な手順です。

厳密さの要求を見積もる: 出力のどこに「1 文字・1 桁レベルの正しさ」が必要かを特定します。その部分は素の生成に任せず、ツール・検証・構造化で固めます
検証可能性で選ぶ: 結果の良し悪しを機械的・人間的に検証できるタスクから任せます(検証できないタスクは、失敗に気付けないタスクです)。ユースケース発見と要件定義の「向き不向き」判断と同じ軸です
少数の実ケースで実測する: 能力の議論を抽象論で続けず、代表的な実データ 10〜20 件で試します。デモ用のきれいな入力ではなく、実務の「面倒なケース」を含めることが重要です(Agent 評価の基礎)
失敗コストで最終判断する: 同じ正答率でも、失敗の損害が違えば判断は変わります。失敗時の検知・回復手段まで含めて「任せられるか」を決めます(モデル選定ガイド、Human-in-the-Loop 設計)

この理解が効く場面

企画・要件定義: 「AI で何ができるか」の議論を、流暢さの印象ではなく構造(厳密さ・検証可能性・ツール補完)で進められます
ツール設計: 「モデルにさせること」と「ツールにさせること」の分担を原理から引けます(ツール定義の設計)
モデル更新への追従: 能力評価に日付を付け、世代交代のたびに安価に再判定できます

実務での注意点

アンチパターン

流暢さから能力を外挿する(「こんなに自然に話せるなら計算もできるはず」) → 流暢さと厳密さは別の能力で、乖離が大きい → 厳密さが必要な箇所を特定し、ツール・検証で固める
苦手なタスクをプロンプトの工夫だけで克服しようとする → 構造由来の弱点(計算・文字数・最新情報)は指示では消えない → ツールによる補完へ設計を切り替える
一度の失敗で「LLM には無理」と結論を固定する → 能力は世代で覆り、試し方(ツール・プロンプト)でも変わる → 日付と条件付きで記録し、定期的に再評価する
ベンチマーク上位モデルなら自社タスクもできると考える → タスク分布・ハーネスが違えば序列は入れ替わる → 自社の実ケースで実測する

チェックリスト

タスクのうち「厳密さが必須の部分」を特定し、ツール・検証・構造化で固めた
結果を検証する手段(テスト・人のレビュー・突き合わせ)がある
実務の代表ケース(面倒なケースを含む)で実測してから判断した
「できなかった」記録に日付・モデル・試し方が付いている
失敗時の検知・回復まで含めて任せる範囲を決めた

参考資料

Toolformer: Language Models Can Teach Themselves to Use Tools — 計算機・検索などの API 利用と対象評価での改善(アクセス日: 2026-09-10)
DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning — 検証可能な課題で推論能力を改善した学習例。能力を固定的に扱わないための比較資料(アクセス日: 2026-09-10)

TODO・未確認事項

なし