AIは長文のガイドラインを読んでも守れない？Handbook.mdから見えた「AI制御」の限界

AIエージェントの挙動を制御するために「Handbook.md」のような長大なポリシー文書を作成しても、結局のところAIはそれらを完全には守れないということが明らかになりました。AIにとって、膨大なルールを遵守し続けることは、技術的な観点からもまだ大きな課題であると言えます。

Claudeを実際に使ってみた経験と合致するね。指示に従わせるのはかなり優秀なんだけど、それも10分くらい。その後は前に伝えたことを無視し始めるんだよ。

CLAUDE.mdファイルにかなり明確かつ強力な指示（例えば、長ったらしいコメントを書くなとか、既存の機能を活用しろとか）を書いてるんだけど、実際のタスクをこなす時には驚くほど速攻でスルーされる。でも、タスク中のプロンプトで同じことを伝えると、ずっとうまくやってくれるんだよね。

結局のところ、CLAUDE.mdに指示を詰め込みすぎるのを控えようとしてる。うまくいくシナリオもあるんだけど、別の状況だと完全に無視してめちゃくちゃにされるから。

これはロングコンテキストモデルが抱える問題だね。シンプルかつ露骨に言えば、「コンテキストに1Mトークン使えます」っていう謳い文句を鵜呑みにして、本当にそうすべきだなんて思わない方がいいってこと。

モデルの極端な量子化やコンテキストのKVキャッシュ、それにユーザーに提供されるひどいサンプラーのせい（というか、最近はサンプラーのつまみ自体をなくすものがほとんどだけど）で、この問題は絶対になくならないよ。

魔法みたいに解決したいなら、ローカル推論に限るね。自分のコントロール下に置いて、無理やり変な使い方を強要されなくなれば、LLMのよくある欠陥は全部消え去るよ。

数ヶ月前にこの挙動に気づいたな。当時は確かSonnet 4.6を使ってたんだけど。コードベースのコメントには厳しいルールを課しててね（全部個人のプロジェクトだけど）、そうやってコメントを制限するのはトークン数を減らしたいからなんだ。

使ってたモデルのバージョンが上がるどこかのタイミングで、Claudeがチケットや他のタスクへの参照を含む巨大なコメントを挿入し始めたんだよ。CLAUDE.mdに特定の指示を出しているにもかかわらずね。

それ以来、自動車組立ラインの現場監督になったような気分で、ひどいコードを書くタスクを細分化して管理するようになった。メインのセッションはCLAUDE.mdのような知識を使って構築しつつ、サブエージェントが「コメントなし/低減」のような指示を確実に守らせたり、最終製品に反映させたりするようにしてる。

数年前に「Lost in the Middle: How Language Models Use Long Contexts」という論文（https://arxiv.org/abs/2307.03172 ）があったね。

経験上、これは今でも当てはまるよ。人間が持つワーキングメモリの限界と似ているという、「Engineering for Bounded Cognition（制限ある認知のためのエンジニアリング）」に関する僕の観察の核心の一つだった。

長いポリシー文書は人間のエージェントにとっても問題だよ。特別な訓練なしで180ページの社員ハンドブックや火災安全規定、OSHAの安全規則、FCC規制、米国の法典なんて誰も覚えられないからね。

もしリスクが高い場合、例えば「無知のまま進めると刑務所行きになる」といった状況なら、たとえポリシー上はギリギリ許可されていても、人は何もしない方を選ぶ。逆にリスクが低ければ、人は最小の抵抗で済むようにポリシーを完全に無視するよ。

このベンチマークで良いスコアを出せるモデルがあれば、超人的な能力があると言ってもいいだろうね。人間だって、長いポリシー文書をいきなり渡されてそれに従えと言われてもかなり苦手だし。

モデルを擬人化しすぎるべきじゃないけど、失敗の核心的な理由の多くが人間と似ていても驚きはしないな。ワーキングメモリは限られたリソースだし、一度に集中できることは限られているし、推論の深さにも限界がある。それに、現実のポリシーの多くは、書かれた通りに実装されることを想定していないし、エッジケースの仕様も不十分だしね。

人間の場合、通常はRLHFに相当することをやってる。シミュレーションケースを使った「訓練」と、実務中のフィードバックの両方でね。新人にいきなり124ページのポリシー文書を渡して、最初のタスクで正しく適用しろとか、最初の1ヶ月で確実にやり遂げろなんて絶対に言わないだろう？

「エージェント型AI」が、トレーニング後の合成データセットを使った大規模な強化学習によって、完全に人工的に強制された能力だってことを多くの人は理解していないね。

LLMが特定のハンドブックに従うように後学習されていなければ、そもそも機能しない。ラボが合成エージェント用データセットを作る価値があると判断したユースケースでトレーニングされていなければ、思ったようには動かないよ。

LLMがエージェント的なタスクでコーディングに秀でているのは理由があって、それは開発者たちの働き方そのものだからだよ。彼らはその流れを深く理解していて、それに合わせてトレーニングできるからね。

本当の道は、自分のエージェント的なユースケースに合わせて簡単にモデルをファインチューニングできるようになることだと思うけど、それには大企業が自社の働き方に関する巨大なデータセットをまとめる必要があるだろうし、最初の犠牲者になりたいとは思わないだろうな。

長いコンテキストという点では、RoPEエンコーディングの拡張を考えると、初期トークンからの正確なアテンション抽出は不可能だね。あるいはKimiやDeepSeekのようにそれを使っていないモデルでも、初期のコンテキストは高度に圧縮されていて正確な情報を失っている。

AIとその仕組みについてもっと時間をかけて学べば、デフォルトのやり方は、キャッシュされた巨大なシステムプロンプトと一緒にタスクをワンショットで投げて、ユーザープロンプトは動的なデータにする、そしてそれをそのタスクができる一番安いモデルに指定することだと気づくはずだよ。

もしどうしてもそうできない問題でない限り、まずはステップ・バイ・ステップでしっかり定義したワンショットプロンプトのグラフを作るべき。それで解決できない場合に初めてエージェントを使い始めるのがいい。

結果が良くてコスト効率もいいのに、明らかにAIに全任せするより手間がかかるからみんなやりたがらないんだよね。

この記事は、大規模な仕様ベースの開発フローには潜在的な問題がいくつかあることも示唆していると思う。最近は具体的に言語化できていないんだけど。

特に、エージェントの実装が仕様から乖離していくという問題がね。

これは現実の問題だね。AIが書いたルールを何度も破ることにすごく腹が立って、Claudeに過去の履歴ログをクロールさせたんだ。そしたら分かったよ。ルールを破るたびに、次にルールを破る確率が上がってるんだ。

これって逆転したFew-Shotみたいな感じだね。本来Few-ShotはAIが見習うべき良い例であるはずなのに。ルールを破るたびにこちらが修正しても、AIは破り続ける。その修正プロセス自体が、違反する確率を高めてしまってるんだ。

プロンプトに書くのとCLAUDE.mdに書くのと、何も書かないのとで違いがあるのか知りたくて、以前短いテストをしてみた。新しいセッションを開いて、ルールを適用して別のトピックでテストしたんだ。結果は、クリーンなセッションなら、ルールがプロンプトにあろうがCLAUDE.mdにあろうが、モデル（Opus 4.8、5、Fable）は全部うまく従うんだよ。普段の会話でルールを破りまくるOpus 4.8でさえ、最初はうまくいくんだ。

ルールを破るのはロングコンテキストのせいじゃないかと疑ってる。でも長い会話の実験をシミュレートするのは難しくて、いいテスト方法が見つかってないんだ。だから、この論文を見た時は、ここ数日抱えていた疑問に完全に答えてくれた気分だったよ。

それに、論文の中で気になったことがあってさ。時々モデルはルールに従ってチェックを実行して、ちゃんと違反を見つけているにもかかわらず、出力する文章では元の間違った結果を主張し続けるんだよね。

今の僕のアプローチはここにいるみんなと同じで、別のフックやポストチェックを使って修正させてる。生成中にモデル自身に修正させようとすると、文章や生成のメイン部分が、自分が見つけたはずのルールのエラーを拒否したりするからさ。

もし著者がこれを読んでいたら聞きたいんだけど、なぜ「Design Principles」みたいな部分をAIモデルに書かせたの？書き方がひどいし、明らかにそれって分かるよ。