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