LLMの知識の限界とスキル/ルールの境界線——プロンプトで補えるものと補えないもの

• 想定読者： AIコーディングツール（Claude Code、Cursor等）を活用するエンジニア
• 前提知識： LLMの基本的な仕組み、プロンプトエンジニアリングの基礎
• 所要時間： 12分

概要

Claude CodeやCursorなどのAIコーディングツールでは、CLAUDE.mdやスキルファイルでルールを定義し、AIの振る舞いを制御できる。しかし、「ルールを増やせばAIは何でもできるようになるのか？」という疑問が生じる。

結論を先に述べる：

1. 制約を増やすと、指示遵守率が下がる ——これは複数の研究で実証されている
2. 最も効果的なのは「既知の概念は名前で呼び、固有部分だけ詳細に書く」アプローチ
3. 新しい概念はルールで教え込むのではなく、ドキュメントを直接提供する

本記事では、これらの主張を2024-2025年の研究データに基づいて説明する。

研究が示す事実：制約を増やすと指示遵守率が下がる

ベンチマークが明らかにした限界

複数の研究が、LLMの指示遵守能力の限界を定量的に示している。

ComplexBench（2024年） は、1,150の指示と5,306のスコアリング質問を用いて、LLMの複合的な制約への対応能力を評価した¹。結果は明確だった：

制約の構造	GPT-4のスコア
単純な構成（And）	0.881
連鎖構成（Chain）	0.766
選択構成（Selection）	0.765
入れ子構造（3層以上）	0.626

制約が複雑になるほど、スコアが明確に低下している。 さらに、長さ制約については最強モデルでも0.532の精度しか達成できず、多層の入れ子構造ではGPT-4でも14.9%の精度に落ち込んだ。

18モデルベンチマークの重要な発見

AI Museが実施した18モデルのベンチマーク²は、より実践的な文脈で同様の問題を確認した。10の制約を持つ創作タスク（子供向け物語の作成）で、 完璧なスコアを達成したモデルはゼロ だった。

制約違反のパターン：

制約の種類	違反率
禁止語の使用	94%
名前の使用回数制限	89%
決まり文句の禁止	67%
文字数の範囲	39%

最高スコアはGPT-4 o1の7/10。つまり、 最先端モデルでも10の制約のうち3つは守れなかった 。

指示遵守の難しさ

これらの研究結果は、「ルールを書けば守ってくれる」という期待が楽観的すぎることを示している。最先端モデルでも複合的な制約への対応には明確な限界があり、制約の数や複雑さが増すほど遵守率は低下する。

なぜ制約を増やすと指示遵守率が下がるのか

コンテキスト腐敗（Context Rot）

Chromaの研究チームは「Context Rot」と呼ばれる現象を報告している³。

ここで重要なのは「何が劣化するか」である。

劣化の種類	許容度	実務への影響
処理速度の低下	許容しやすい	待ち時間が増えるだけ
トークン消費の増加	許容しやすい	コストは増えるが予測可能
指示遵守率の低下	許容しにくい	「お願いしたことをやってくれない」
出力品質の低下	許容しにくい	レビュー負荷が増大

研究が示す「パフォーマンス低下」の本質は、速度やコストの問題ではなく、 指示遵守率の低下 である。

• 入力が長くなるとパフォーマンスが低下する
• 「中間で迷子」問題 ：先頭と末尾の指示は守りやすいが、中間のルールは忘れられやすい⁴
• 複雑なタスクほど劣化が激しい

理解と実行のギャップ

さらに厄介な問題がある。LLMはルールを 言語化（説明）できる にもかかわらず、 実際のタスクで適用することに失敗する ケースがある⁵。

これは「計算的スプリットブレイン症候群」と呼ばれ、指示の理解と行動の実行が機能的に分離していることを示している。つまり、「ルールを書けば守ってくれる」とは限らない。

効果的なアプローチ：既知の概念は名前で呼ぶ

CLAUDE.md最適化の研究結果

Arizeの研究チームは、CLAUDE.mdの最適化による効果を定量的に測定した⁶：

• 異なるリポジトリでのテスト： +5.19%の精度向上
• 同一リポジトリ内でのテスト： +10.87%の精度向上

この研究から得られた重要な知見は、 効果的なルールはコードベースの具体的なパターン、慣例、および潜在的な落とし穴に焦点を当てるべき ということである。

「名前で呼ぶ」アプローチ

LLMがすでに知っている概念は、 名前で指示するだけで十分 である。プロジェクト固有の部分だけを詳細に書くことで、コンテキストを節約し、指示遵守率を維持できる。

❌ 悪い例（冗長）：
「ドメイン駆動設計の原則に従ってください。
ドメイン駆動設計とは、ビジネスドメインを中心に
ソフトウェアを設計する手法で、
エンティティ、バリューオブジェクト、アグリゲート、
リポジトリ、サービスなどの概念を用います。
エンティティは一意の識別子を持ち...（長い説明）」

✅ 良い例（効率的）：
「DDDに従う。
このプロジェクト固有のルール：
- Userアグリゲートのルートは UserEntity
- リポジトリは /src/infrastructure/repositories に配置
- ドメインイベントは Kafka に発行」

なぜこれが効果的か

アプローチ	コンテキスト消費	指示遵守率
概念を1から説明	大	低下しやすい
名前だけ指定	小	高い
名前＋固有ルール	中	高い

「LLMがすでに知っていること」を再度説明するのは、コンテキストの無駄遣いであり、かつ指示の希薄化を招く。

LLMが知っている概念の具体例

カテゴリ	例	指示の書き方
古典的パターン	MVC、レイヤードアーキテクチャ	名前だけで十分
確立された設計原則	SOLID、DRY、KISS	名前だけで十分
成熟したアーキテクチャ	DDD、CQRS、Clean Architecture	名前＋固有の適用ルール
比較的新しいアプローチ	Vertical Slice Architecture	名前＋詳細な補足

重要な注意点：DDDやClean Architectureのような「概念」は知っていても、 特定のプロジェクトでの「正しい適用方法」 は別問題である。だからこそ、概念は名前で呼び、固有の適用ルールだけを詳細に書くのが効果的。

新しい概念への対処

ルールで教え込むのは逆効果

LLMの知識は学習データの時点で止まっている⁷。2025年に登場したライブラリ、破壊的変更後のAPI、最新のベストプラクティスについて、LLMは「知らない」可能性がある。

スキルファイルに詳しい説明を書けば教えられるのでは？ という考えは自然だが、前述の通り、 説明を増やすと指示遵守率が下がる 。これは逆効果になりうる。

効果的な対処法

1. ドキュメントを直接コンテキストに含める

# 効果的なアプローチ
「新しいAPIのドキュメントを読み込んで、それに基づいて実装してください」

# 効果的でないアプローチ
「このAPIはv3で大幅に変更されました。新しい使い方は...」
（スキルに長い説明を書く）

前者は、LLMの「理解能力」を活用して新しい情報を処理させる。後者は、スキルを肥大化させ、他のルールの遵守率を下げるリスクがある。

2. 検証レイヤーを設ける

LLMが新しい概念を正しく適用できたかどうかは、 出力を検証するまでわからない 。

flowchart TB
    A["LLMに新しいAPIの使用を依頼"]
    B["コード生成"]
    C["自動テスト実行"]
    D{テスト結果}
    E["成功：採用"]
    F["失敗：フィードバックして再生成"]

    A --> B --> C --> D
    D -->|Pass| E
    D -->|Fail| F
    F --> B

AI Museのベンチマークでも、 「人間によるレビューは必須」 と結論づけている²。最先端モデルでも10の制約のうち3つは守れないのだから、検証なしで本番投入するのは危険である。

3. WebSearch/RAGの活用

Claude CodeのWebSearch機能や、RAGシステムを活用することで、LLMが学習していない最新情報にアクセスできる。

実践的なルール設計

AI Museベンチマークからの教訓

AI Museのベンチマークでは、システムプロンプトの書き方を3段階で改善した結果、平均スコアが大幅に向上した²：

バージョン	平均スコア
S-0（初期）	2.4
S-1（完全な仕様を1ブロックに）	6.0
S-2（最適化）	6.3

重要な発見： 「すべてのルールを1つの連続したブロックとしてシステムプロンプトに統合する」ことが効果的だった。部分的または遅延した制約は一貫して無視された。

ルール設計のベストプラクティス

❌ 避けるべきこと：
- すべてのエッジケースを網羅したルール
- 例外規定の例外規定
- 曖昧な表現（「適切に」「必要に応じて」）
- 複数の場所に分散したルール

✅ 効果的なこと：
- 最も重要な5-10のルールに絞る
- 具体的な例示を添える
- 矛盾するルールを排除する
- すべてのルールを1つのブロックにまとめる

定期的な見直し

スキルやルールは、時間とともに陳腐化する。定期的に以下を確認すべきである：

• 矛盾するルールの発生 ：新しいルールが古いルールと競合していないか
• 不要になったルール ：プロジェクトの進化で意味をなさなくなったルールはないか
• ルールの肥大化 ：本当に必要なルールに絞られているか

まとめ

研究が示す事実：

• 制約を増やすと指示遵守率が下がる（ComplexBench: 0.881 → 0.626）
• 10の制約で完璧達成したモデルはゼロ（AI Muse）
• 最先端モデルでも複合的な制約への対応には明確な限界がある

効果的なアプローチ：

• 既知の概念は名前で呼ぶ ：LLMの既存知識を信頼して活用
• 固有のルールだけ詳細に書く ：コンテキストを節約
• ルールは少なく、1つのブロックにまとめる ：指示の希薄化を防ぐ

新しい概念への対処：

• スキルに長い説明を書くのは逆効果
• ドキュメントを直接コンテキストに含める
• 検証レイヤーを設けて出力を確認

最終的に、 LLMは「増幅ツール」であり、「万能ツール」ではない 。LLMがすでに知っている概念を活用し、プロジェクト固有の部分だけを補完する——この組み合わせが、現時点で最も精度の高いアプローチである。

関連記事

このテーマに関連する他の記事もご覧ください：

• LLMコード生成の技術的限界 - 幻覚や非効率性の技術的側面
• AIの「考えすぎ」問題 - 理解と実行のギャップ
• スキルを書かずにスキルを使う - スキルの効果的な活用方法
• メタプロンプティングとオーケストレーター - 高レベルでの指示の出し方

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

• FollowBench: A Multi-level Fine-grained Constraints Following Benchmark - ACL 2024. 【信頼性: 高（査読済み）】

• RECAST: Expanding the Boundaries of LLMs’ Complex Instruction Following - arXiv (2025). 【信頼性: 中〜高（プレプリント）】

• Best Practices for Claude Code - Anthropic (2025). 【信頼性: 高】

---

引用の正確性について： 本記事で引用した研究は、学術データベース（arXiv、ACL Anthology、EMNLP）、公式企業ブログ、信頼性の高い技術メディアを中心に構成しています。一部のプレプリントは査読前の論文であるため、信頼性レベルを明示しています。

1. Benchmarking Complex Instruction-Following with Multiple Constraints Composition - arXiv (2024). 【信頼性: 中〜高（プレプリント）】 ↩︎

2. System Prompts Versus User Prompts: Empirical Lessons from an 18-Model LLM Benchmark - AI Muse (2025). 【信頼性: 中】 ↩︎ ↩︎² ↩︎³

3. Context Rot: How Increasing Input Tokens Impacts LLM Performance - Chroma Research (2025). 【信頼性: 高】 ↩︎

4. Lost in the Middle: How Language Models Use Long Contexts - Liu et al. (2024). 【信頼性: 高（TACL査読済み）】 ↩︎

5. Comprehension Without Competence: Architectural Limits of LLMs - arXiv (2025). 【信頼性: 中〜高（プレプリント）】 ↩︎

6. CLAUDE.md: Best Practices Learned from Optimizing Claude Code with Prompt Learning - Arize (2025). 【信頼性: 中〜高】 ↩︎

7. Knowledge cutoff - Wikipedia - Wikipedia (2025). 【信頼性: 中〜高】 ↩︎