# AIエージェントは「ルールを増やしすぎても」壊れる —— 指示を足す前に考えたいコンテキスト設計 > AIエージェントの失敗に対してルールを足し続けると、逆に重要な指示が埋もれ、競合やActivation Failureを増やすことがあります。常時ルールを小さくし、必要なSkillだけRoutingする設計を整理します。 - Canonical: https://c-a-p-engineer.github.io/ai-agent-rule-overload/ - Published: 2026-09-03T07:38:00.000Z - Modified: 2026-09-03T07:38:00.000Z - Categories: AI - Tags: AI, LLM, AIエージェント, プロンプトエンジニアリング AIエージェントに失敗させると、ついやりたくなる対応があります。 「次からこのケースでは必ず○○すること」 そしてルールを1行追加する。 最初の数回は、これでうまくいきます。 ところが運用を続けていると、別の失敗が起きます。 そこでまたルールを追加する。 さらに別の失敗が起きて、また追加する。 気が付くと、AIには大量のルール、例外、注意事項、禁止事項、ツール利用条件が渡されるようになります。 私も個人用のAIエージェントを育てる中で、この方向へかなり進みました。 しかし途中から、違和感が出てきました。 **ルールを増やしているのに、むしろ重要なルールが守られにくくなることがある。** この記事では、この問題を「AIが賢い・賢くない」という話ではなく、エージェントを構成するHarnessとコンテキスト設計の問題として整理します。 ## 結論 AIエージェントの信頼性を上げるために必要なのは、ルールを無制限に増やすことではありません。 重要なのは、 - 常に必要なRootルールを小さく保つ - タスクを分類する - 今回必要なSkill・ルールだけを読み込む - 最後に成果物を検証する という構造です。 つまり、 ```text すべてのルールを常時読む ``` ではなく、 ```text 必要なルールへ到達できる仕組みを作る ``` 方が重要です。 私はこれを、単なるプロンプト改善ではなく**Routingの問題**として考えるようになりました。 ## なぜルールは増えていくのか ルールが増える理由は分かりやすいです。 AIが失敗したとき、人間から見れば原因と対策が見えます。 例えば、 - 最新情報を確認せずに回答した - GitHubのmasterを確認せずに古い情報で作業した - 画像生成前に参照画像を読まなかった - 公開してはいけないものを公開しそうになった - 完了していないのに「完了」と報告した といった失敗が起きたとします。 すると、次のようなルールを追加したくなります。 ```text 作業前に必ずmasterを確認すること。 ``` ```text 画像生成では必ず参照画像を取得すること。 ``` ```text 実行していないことを完了と報告してはいけない。 ``` どれも単体では正しい対策です。 問題は、**正しいルールを追加すること自体が、全体として正しい設計になるとは限らない**ことです。 ## コンテキストは「入る量」と「使える量」が同じではない 最近のLLMは非常に長いコンテキストを扱えます。 しかし、長い文章を入力できることと、その中のすべての情報を同じ精度で利用できることは別です。 2023年の論文Lost in the Middle: How Language Models Use Long Contextsでは、長いコンテキスト内で重要情報の位置が変わるだけでも性能が大きく変化し、特に中央付近の情報を安定して使えない場合があることが報告されています。 これは「長文を入れると必ず失敗する」という意味ではありません。 ただし、 ```text コンテキストウィンドウに入っている = 必要なとき必ず使われる ``` ではない、という点は重要です。 Anthropicも2025年のEffective context engineering for AI agentsで、コンテキストを有限の資源として扱い、高シグナルな情報を必要十分な量に絞る考え方を説明しています。 特に興味深いのが、あらゆる例外ケースを長大なルール一覧としてプロンプトへ詰め込む方法を推奨していない点です。 つまり、LLMのコンテキストが巨大になっても、設計側には依然として「何を今渡すか」という仕事が残ります。 ## ルールが増えると、何が起こるのか 私が実際にAIエージェントを運用していて問題だと感じたのは、単純なトークン数だけではありません。 ### 1. 関係ないルールまで毎回評価させることになる 例えば、ブログ記事を書くタスクなのに、 - 画像生成時の参照画像ルール - 医療相談時の安全ルール - GitHubの自己更新ルール - 漫画のコマ割りルール - PDF生成時の検証ルール まで全部コンテキストへ入っていたとします。 それらは今回の仕事には不要です。 しかしAI側から見ると、入力された以上、 ```text これは今回関係するか？ これは適用対象か？ 他のルールと競合しないか？ ``` を判断する対象になります。 ルールは「読むだけなら無料」ではありません。 **不要な判断面を増やします。** ### 2. 似たルールが増え、どれがRootか分かりにくくなる 失敗のたびに局所的なルールを追加していると、同じ意味のルールが少し違う言葉で増えていきます。 例えば、 ```text 推測で完了報告しない ``` ```text 実行結果を確認してから完了とする ``` ```text 未確認のものを成功扱いしない ``` は、かなり近い意味です。 これらを個別ルールとして積み上げ続けると、「本当に守りたい原則」が見えにくくなります。 本来必要なのは、より上位の一つの原則かもしれません。 ```text 完了判定はEvidenceに基づく ``` 枝を増やしすぎると、Rootが埋まります。 ### 3. ルール同士の競合が増える ルールが10個なら、人間でも全体像を把握できます。 100個、200個になると、意図せず矛盾する可能性が上がります。 例えば、 ```text 分からなければ必ず質問する ``` と、 ```text 作業を止めず、合理的に推測して最後まで進める ``` が同時に存在したら、どちらを優先するか決めなければなりません。 ルールそのものが正しくても、**優先順位が設計されていなければ実行可能な仕様にはなりません。** ## Activation Failureは「ルール不足」だけで起きるわけではない 以前、私はAIエージェントは『ルール不足』だけでなく『あるのに使われない』でも壊れるという記事を書きました。 そこで扱ったのが、必要なSkillやルールが既に存在するのに、適切な場面で発火しない**Activation Failure**です。 当時は主に、 ```text 能力はある ↓ でも必要な場面で選ばれない ↓ 失敗する ``` という問題として整理しました。 しかし運用を続けると、その逆側も見えてきました。 ```text 失敗する ↓ ルールを追加する ↓ 候補ルールが増える ↓ どれを発火させるべきかの判断が難しくなる ↓ 重要なルールが使われない ``` つまり、**Activation Failureへの対策としてルールを増やし続けると、それ自体が新しいActivation Failureを作る可能性がある**わけです。 これは少し皮肉です。 ## 「全部読む」から「必要なものへRoutingする」へ そこで現在は、ルールを次のような層に分けて考えるようになりました。 ```text [Root] 安全・権限・根本原則 ↓ [Router] 今回のタスクを分類する ↓ [Skill] 必要な専門ルールだけ読む ↓ [Execution] 作業する ↓ [Verification] 成果物と完了条件を確認する ``` ### Root 常に必要なものだけ置きます。 例えば、 - 実行していないことを完了と報告しない - 権限や安全境界を越えない - 現在のユーザー指示を優先する - 必要な専門ルールへRoutingする といった、タスクの種類が変わっても意味が変わらない原則です。 ### Router 次に、今回の仕事が何なのかを判定します。 ```text 画像生成なのか コード変更なのか 調査なのか 記事執筆なのか GitHub操作なのか ``` ここで初めて必要なSkillを選びます。 ### Skill 専門的なルールは、その仕事をするときだけ読みます。 例えば、漫画を作らないのに漫画のコマ割りルールを読む必要はありません。 医療相談でなければ、医療用の詳細な確認フローを毎回読み込ませる必要もありません。 この形にすると、ルールを削除しなくても**常時コンテキストから外す**ことができます。 ## 失敗対策を「ルール追加」だけにしない もう一つ重要なのが、失敗したときの改善手段を増やすことです。 AIが失敗したからといって、毎回プロンプトへ文章を追加する必要はありません。 対策は少なくとも次のように分けられます。 ### ルールにする 人間の判断が必要で、複数タスクに共通する原則。 例: ```text 実行結果を確認せず完了扱いしない ``` ### Skillへ移す 特定の作業だけで必要な知識や手順。 例: ```text GitHub Pagesの記事を追加するときのfront matter確認 ``` ### Repository側へ置く そのプロジェクトでしか意味を持たないルール。 例: ```text 記事はsrc/content/articles/へ置く ``` これはAI全体の人格ルールではなく、対象Repositoryの作業規則です。 ### 機械的に検証する AIに覚えさせるより、プログラムで止めた方が確実なもの。 例: ```text legacySlugの重複 必須front matter不足 ビルドエラー ``` こうしたものはCIやvalidatorへ寄せた方が強いです。 ### テストケースにする 過去の失敗を「文章として覚えさせる」のではなく、同じ失敗を再現するテストとして残す方法もあります。 この方が、ルール本文を巨大化させずに再発防止できます。 ## ルールを追加する前に確認する5つ 最近は、新しいルールを追加したくなったとき、次を確認するようにしています。 1. **これは本当に全タスクで必要か** 2. **特定SkillやRepositoryだけの話ではないか** 3. **既存ルールと意味が重複していないか** 4. **文章ではなくテストやvalidatorで防げないか** 5. **このルールを追加すると、新しい判断分岐を増やさないか** 特に5つ目が重要です。 ルールは情報量だけでなく、**分岐を増やします。** ```text if AならX if BならY ただしCならZ Dの場合だけ例外 ``` が増えるほど、Harness全体は複雑になります。 ソフトウェアで条件分岐を増やし続ければ保守しづらくなるのと同じです。 AIエージェントのルールにも、ある種の**複雑性予算**があると考えた方が扱いやすいです。 ## ルールを減らすことが目的ではない ここまで読むと、「プロンプトは短いほど良い」と言っているように見えるかもしれません。 そうではありません。 必要な条件まで削れば、当然AIは失敗します。 重要なのは文字数ではなく、 ```text 今このタスクを成功させるために必要な情報が、 十分に入っていて、不要な情報が支配していないか ``` です。 長いルールでも必要なら読むべきです。 逆に、たった1行でも無関係なHard Gateを常時追加すれば、Harnessは少しずつ複雑になります。 **最小化ではなく、必要十分化。** この感覚が近いと思います。 ## まとめ AIエージェントが失敗すると、ルールを追加したくなります。 その対策自体は間違いではありません。 ただし、 ```text 失敗した = 新しい常時ルールを追加する ``` を繰り返すと、いずれHarnessそのものが複雑になります。 そして、 - 不要なルールまで毎回評価する - Rootと局所ルールの区別が曖昧になる - 似たルールが重複する - ルール同士が競合する - 必要なルールが適切にActivationされない という別の問題が生まれます。 私が今重視しているのは、完璧な巨大ルールブックを作ることではありません。 ```text 必要なときに、必要なルールへ到達できること ``` です。 AIエージェントの成長は、ルールの総量ではなく、**Root・Routing・Skill・Verificationをどう分離するか**で考えた方が、長期運用しやすいのではないかと思っています。 ## 参考 - Lost in the Middle: How Language Models Use Long Contexts - Anthropic: Effective context engineering for AI agents - AIエージェントは『ルール不足』だけでなく『あるのに使われない』でも壊れる —— Activation Failureという問題