🌐 English
Part 1: LLMの構造的制約を知る
NOTE
LLM は万能ではない。Transformer 系モデルには、入力の長さや注意の配分に起因する構造的な制約がある。
本 Part はその制約を定義する。対象は製品の設定手順ではなく、制約そのものである。
なぜ構造的問題を知る必要があるのか
想定読者は、クラウド LLM を使う開発者である。目的は、制約の機序を理解し、自分の環境へ適用することである。
Claude Code の設定（CLAUDE.md、rules/、skills/、hooks など）は、LLM が抱える構造的問題への設計的な回答である。Claude Code を題材にするのは、現時点で詳細かつ正確に記述できる代表例だからである。
ここで学ぶ原則は、Cursor や Cline、あるいは素のプロンプト設計にも直接使える。同じ制約が現れる。同じ考え方で対処できる。
最終的な到達点は Part 11: 他LLMへの応用 である。本 Part で制約を定義し、Part 2 以降で代表例の対策を見る。Part 11 で製品に依存しない原則を抽出する。
Claude Code における具体策の例は次のとおりである。
- CLAUDE.md の200行制限 → Priority Saturation への対策
.claude/rules/の条件付き注入 → Lost in the Middle への対策- Hooks の機械的検証 → Hallucination への対策
「なぜそう設定するのか（Why）」を理解するには、まず「LLM がどんな問題を抱えているか」を知る必要がある。
8つの構造的問題
LLM には以下の8つの構造的問題がある。これらは「バグ」ではなく、Transformer アーキテクチャと訓練プロセスに起因する不可避な制約である。
コンテキスト関連（入力が増えるほど悪化する問題）
| 問題 | 一言で言うと | 詳細 |
|---|---|---|
| Context Rot | トークンが増えると出力品質が低下する | 200Kの容量があっても、50Kで既に劣化が始まる |
| Lost in the Middle | コンテキスト中間部の情報を無視する | 先頭と末尾に注意が集中し、中間部は30%以上の精度低下 |
| Priority Saturation | 指示が多いと全体の遵守率が低下する | 10個の同時指示でGPT-4oは15%、Claude Sonnetは44%の遵守率 |
出力関連（生成内容の信頼性の問題）
| 問題 | 一言で言うと | 詳細 |
|---|---|---|
| Hallucination | 事実に反する内容を生成する | 数学的に「ゼロにできない」ことが証明されている |
| Sycophancy | ユーザーに同意し正確性を犠牲にする | RLHFの副作用。全モデル平均58%の追従率 |
| Knowledge Boundary | 知識外の質問で「知らない」と言えない | 訓練目的関数に「知らない」への報酬がない |
入力感受性（プロンプトの書き方に依存する問題）
| 問題 | 一言で言うと | 詳細 |
|---|---|---|
| Prompt Sensitivity | 表現の違いで結果が大きく変動する | 同じ意味でも最大76精度ポイントの差 |
時間軸（会話が長くなるほど悪化する問題）
| 問題 | 一言で言うと | 詳細 |
|---|---|---|
| Instruction Decay | 長い会話でルールを忘れる | 上記7問題の複合結果。マルチターンで平均39%性能低下 |
問題間の関係
これらの問題は独立して存在するのではなく、相互に増幅し合う。以下の図は、8つの構造的問題がどのように連鎖・増幅するかを視覚化したものである。
3つの主要カスケード:
- 空間的劣化: Context Rot → Lost in the Middle → Priority Saturation（コンテキストが長くなるほど加速）
- 信頼性の崩壊: Knowledge Boundary → Hallucination ↔ Sycophancy（フィードバックループ）
- 時間的複合: 全7問題 → Instruction Decay（マルチターンで全てが合流）
構造的問題 × Claude Code 対策マップ
LLM には 8 つの構造的問題がある。下表の対策は Claude Code における代表例である。Part 2 以降で、各機能がこれらの問題にどう対応しているかを詳しく見る。製品に依存しない原則の抽出は Part 11 で行う。
| 構造的問題 | 概要 | 主な対策（Claude Code） | 対応ドキュメント |
|---|---|---|---|
| Context Rot | トークン増で出力品質が劣化 | /compact, /clear, コンテキスト予算管理 | Part 2, 3, 5, 6, 8 |
| Lost in the Middle | コンテキスト中間部の情報を無視 | /compact（50%閾値）, 条件付きルール, Agents | Part 2, 4, 5, 8 |
| Priority Saturation | 指示過多で全体の遵守率低下 | CLAUDE.md 200行制限, .claude/rules/, Skills | Part 3, 4, 5 |
| Hallucination | 事実に反する内容を生成（構造的に不可避） | Hooks（機械的検証）, テストコード, MCP | Part 6, 7 |
| Sycophancy | ユーザーに同意し正確性を犠牲に | Cross-model QA（Agents）, Hooks, 問い方設計 | Part 5, 7 |
| Knowledge Boundary | 知識外で「知らない」と言えない | MCP外部参照, バージョン明示, 専門Agents | Part 3, 5, 6 |
| Prompt Sensitivity | 表現の違いで結果が大きく変動 | CLAUDE.md の書き方, Skills description設計 | Part 3, 5 |
| Instruction Decay | 長会話でルール忘却（7問題の複合結果） | /compact, /clear, Hooks, セッション分割 | Part 7, 8 |
詳細版は 構造的問題 × Claude Code 対策マップ（付録） を参照。
この制約は Claude に限らない
8つの問題は、特定の製品の欠陥ではない。Transformer 系モデルと、その訓練プロセスに起因する。クラウド LLM を使う環境であれば、程度の差はあれ同じ制約が現れる。
他の環境での現れ方の例:
- チャットの履歴が長くなると、途中の合意が後の応答に反映されなくなる
- 長い仕様を一度に渡すと、中盤の要件が落ちる
- ルールを並べすぎると、どれも守られにくくなる
Claude Code の対策表は、その制約に対する具体策の代表例である。同じ粒度の機能が他ツールに揃っているとは限らない。横断して使えるのは、次の考え方である。入力を短く保つ。重要な指示を埋もれさせない。検証をモデルの外に置く。詳細は Part 11: 他LLMへの応用 にまとめる。