LLMエージェントに「ルール」だけでは足りない理由──130KBの規律ファイルから見えた設計の本質

生成AIをコーディング作業に活用する際、多くの開発者が最初に取り組むのが「ルールファイルの作成」です。`CLAUDE.md`、`.cursorrules`、`AGENTS.md`、あるいはシステムプロンプト——名称は様々ですが、共通しているのは「やっていいこと」「やってはいけないこと」を自然言語で列挙するアプローチです。

実際の運用現場では、このルールファイルが肥大化する傾向にあります。ある開発者のプライベートリポジトリでは、規律ファイルが累計130KBを超えているといいます。「`sed -i`を使うな（差分レビューを通せ）」「リダイレクトでファイルを直接書き換えるな」といった具体的な禁止事項が延々と続く状態です。

しかし、ここで重要な問いが浮かび上がります。**なぜテキストでルールを書くだけでは不十分なのか？**

1. コンテキストウィンドウの圧迫

130KBのルールファイルは、トークン換算で約3万〜4万トークンに相当します。これはClaude 3.5 Sonnetの200Kコンテキストウィンドウの15〜20%を占める計算です。実際のコード、過去の会話履歴、参照ドキュメントなど、本来AIが活用すべき情報のスペースを大きく圧迫します。

さらに深刻なのは、**ルールが増えれば増えるほど、個々のルールの「重み」が相対的に低下する**点です。LLMは注意機構(Attention)によって情報を処理しますが、大量のルールが並列に存在すると、重要度の判断が困難になります。

2. 自然言語の曖昧性による解釈のブレ

「差分レビューを通せ」というルールは人間には明確ですが、LLMにとっては解釈の余地があります。「緊急の修正時は例外か？」「テストファイルも対象か？」「レビュー待ちの間に別の作業を進めていいか？」——こうした暗黙の前提条件まで全て明文化しようとすると、ルールは指数関数的に増大します。

実際、ルールを追加する行為自体が**「例外への対処」の連鎖**であることが多いのです。「Aをするな」→「でもBの場合は？」→「BはOKだがCの時は...」という無限ループに陥ります。

3. 実行可能性の検証不足

テキストで書かれたルールは、**実行前に違反を検出できません**。LLMがコマンドを生成し、実行して初めて「ルール違反だった」と判明するケースが頻発します。これは事後的な修正コストを生み、開発速度を著しく低下させます。

従来のアクセス制御との本質的な違い

この問題構造は、従来のソフトウェア開発における権限管理とは根本的に異なります。UNIXの`chmod`やクラウドのIAMポリシーは、**実行前に権限をチェックし、違反を未然に防ぐ**設計です。一方、LLMエージェントのテキストルールは「お願いベース」に過ぎず、強制力を持ちません。

ChatGPTのCode Interpreterや、GitHub Copilotとの比較も示唆的です。これらのツールは、実行環境自体を制限することでルールを「構造的に強制」しています。Code Interpreterはサンドボックス環境で動作し、物理的に特定の操作を不可能にします。これはテキストルールの「説得」ではなく、「物理的制約」による制御です。

真に必要なのは「設計パターン」の転換

テキストルールが肥大化する根本原因は、**ルールを「記述」ではなく「実装」すべきだから**です。具体的には以下のアプローチが有効です。

**1. ツールAPI設計による制約の組み込み**

LLMに渡す関数・ツールのインターフェース自体を制限します。「ファイルを直接書き換える関数」を提供せず、「差分を生成する関数」と「レビュー後に適用する関数」に分割すれば、ルールを書かずとも違反は発生しません。

**2. 実行前バリデーションレイヤー**

LLMが生成したコマンドやコードを、実行前に検証する中間層を設けます。これはASTパーサーやlinterのような静的解析ツールを活用し、「sed -iが含まれていたら即座に拒否」といった機械的チェックを行います。

**3. 階層化されたプロンプト設計**

全ルールを1つのファイルに詰め込むのではなく、**タスクの種類に応じて動的にルールをロード**します。「ファイル編集タスク」「テスト実行タスク」「デプロイタスク」で異なるルールセットを用意し、必要な時だけコンテキストに注入します。これによりトークン効率が劇的に改善します。

注意すべきトレードオフ

ただし、構造的制約の導入には開発コストがかかります。ツールAPIの設計には時間がかかり、バリデーションレイヤーの保守も継続的な負担です。小規模プロジェクトや実験段階では、テキストルールの方が迅速に回せる場合もあります。

重要なのは、**「ルールが増え始めたら設計を見直すサイン」**と認識することです。10個程度のルールなら問題ありませんが、50個、100個と増えていくなら、それは本質的な設計課題が存在する証拠です。

1. 現在のルールファイルを分類する

まず既存のルールを「禁止事項」「推奨事項」「コンテキスト情報」の3つに分類してください。禁止事項はツールAPI設計で対処、推奨事項は少数の原則に集約、コンテキスト情報は別ファイルに分離します。これだけで30〜40%のトークン削減が可能です。

2. 「ルール違反検出スクリプト」を作る

LLMの出力を実行する前に、シンプルなgrepやregexで禁止パターンをチェックするスクリプトを追加しましょう。たった10行のシェルスクリプトでも、「sed -i」や「rm -rf」といった危険コマンドを確実に止められます。

#!/bin/bash
if echo "$LLM_OUTPUT" | grep -E '(sed -i|rm -rf|> [^|])'; then
  echo "Error: Prohibited command detected"
  exit 1
fi

3. タスク別プロンプトテンプレートを用意する

全てのルールを毎回読み込ませるのではなく、「コードレビュー用」「新機能実装用」「バグ修正用」といったテンプレートを作成します。Cursor AIやClaude Code Editorでは、`.cursorrules`の代わりにタスク別の設定ファイルを動的に切り替える運用が効果的です。

---

この情報は @AOS Architect さんの投稿を参考にしています。