🌐 English

構造的制約は全モデル共通

NOTE

Part 1 の 8 問題は、Claude という製品の欠陥ではない。
Transformer 系のモデルと、その訓練プロセスに由来する。
クラウド LLM を使う環境であれば、程度の差はあれ同じ制約が現れる。

なぜ共通なのか

8 つの問題は、個別実装のバグとして説明するより、次の二層で説明する方が正確である。

• Transformer の構造 — 自己注意、位置エンコーディング、次トークン予測
• 訓練の目的関数と RLHF — 「次を予測する」「好まれる応答を出す」ことへの報酬

特定の製品を離れても、この二層を共有するモデルでは同じ種類の失敗が起きる。程度と現れ方はモデルによって違う。同じ失敗が、同じ大きさで起きるとは限らない。

問題	主に由来するもの	製品非依存の含意
Context Rot	自己注意の計算量と注意の希薄化	入力を短く保つ
Lost in the Middle	位置エンコーディングに伴う注意の偏り	重要情報を中間に置かない
Priority Saturation	一度に条件付けできる指示量の限界	常駐の指示を増やしすぎない
Hallucination	次トークン予測	事実の検証をモデルの外に置く
Sycophancy	RLHF で同意が好まれやすいこと	生成と検証を分ける。「よいか」と聞かない
Knowledge Boundary	「知らない」への報酬が弱いこと	外部の一次情報に接地する
Prompt Sensitivity	トークン列の統計的パターンへの依存	変動させたくない軸を明示する
Instruction Decay	上記が時間軸で重なること	会話を短く区切る。決定をファイルに残す

Sycophancy は、RLHF を経たモデルで特に顕著である。ベースモデルでは現れ方が違うことがある。Prompt Sensitivity の観測値は評価方法にも依存する。制約が「ない」のではなく、測り方で大きさが変わる。

対策のうち、製品に依存しないもの

Claude Code の各機能は代表例である。機能名を移す必要はない。移すのは考え方である。

1. 常駐コンテキストは最小限に — 毎回渡す指示は短くする
2. 条件付きで読む — 対象があるときだけルールを載せる
3. 独立した Context で検証する — 生成した会話の延長で追認させない
4. 機械的検証は Context の外に置く — テスト、lint、CI は LLM に依存しない
5. セッションは短く保つ — タスクの区切りで履歴を捨てるか、要約する

専用のコマンドがなくても、この 5 つは実行できる。手順は ツール支援がない環境での実践 に書く。確認した製品上の置き場所は Cursor / Cline / Copilot 対応表 に書く。

---

前へ: Part 11: 他LLMへの応用

次へ: ツール支援がない環境での実践