3行まとめ
- LLMエージェントに自律的なルール更新（自己進化）を任せると、ルールファイルが「〜してはならない」という禁止令（ブラックリスト）で埋め尽くされる。
- これはモデルの特性ではなく、「失敗は明確なエラー（シグナル）を出すが、成功は何も出力しない」という構造的な非対称性に起因する。
- 解決策として、CIのパスやノーコメントマージなどの「微弱な成功シグナル」をトリガーにし、優れたコード（実物）を「模範（ベストプラクティス）」として記憶層に強制記録させる仕組みが必要である。
Agent（自律型AIエージェント）に自身の行動ルールを継続的にイテレーションさせていると、ある日ルールの設定ファイルを見てハッとする瞬間が訪れます。
そこにあるのは、見渡す限りの「禁止事項の山」です。
- 未確認でファイルを削除してはならない
- テストを弱体化させて強引にパスしてはならない
- ページ上部の `use client` を忘れてはならない
- 推測だけで未確認のバグを修正してはならない
- リソースレベルの認可チェックを省略してはならない
- 10行を超える import 文を放置してはならない
...
追加された順に履歴（Gitのログなど）を眺めると、この傾向はさらに刺さります。
最初の数行こそ「まずは既存コードを読むこと」といった能動的なプロンプトかもしれませんが、自動更新ループが回り始めてから追加される内容は、判を押したように禁令ばかりです。
ルール体系は「優れた行動を形作る」方向には成長せず、ひたすら「行動の幅を狭める」方向へ単調に伸びていきます。これは運用者の個人的な好みの問題ではなく、ループ構造そのものがもたらすバイアスなのです。
失敗はシグナルを発し、成功は沈黙する
典型的なエージェントの自己進化ループは、以下のプロセスを辿ります。
- タスク実行
- 結果の観測
- ルールの更新（プロンプト/記憶の書き換え）
根本的な問題は、ステップ2の「観測」において捕捉できるシグナルにあります。ここには、失敗と成功の間に恐ろしいほどの非対称性が存在しています。
失敗のシグナル（大声を上げる）
失敗は、極めて鮮明なシグナルを発します。
- CIのテストが落ちる（赤くなる）
- ビルドがクラッシュする
- レビューで人間から「違う」とRejectされる
- Revertがトリガーされる
これらはすべて離散的で、原因の特定が可能であり、「次はこうしてはならない」というルール（テキスト）に変換するのが非常に容易です。
成功のシグナル（沈黙する）
一方、成功は何も発しません。スムーズに完了したタスクは、ただ静かに終わるだけです。
「今回のアーキテクチャ判断は非常に素晴らしかった」というシグナルは、人間が手動でマークアップしない限り、システム上には永遠に生成されません。
結果として、放っておくと「ルール更新」への入力データは失敗事例（エラーログやReject理由）ばかりになります。入力が失敗ばかりなら、出力が「禁止令」ばかりになるのは当然の帰結です。
構造的に言えば、生存者バイアスの逆（淘汰された者だけが大声を上げ、生存者が沈黙している状態）が起きています。
ブラックリストは行動空間を圧縮するだけで、形を与えない
純粋な「禁止リスト」の何が問題なのでしょうか？
それは、いくら「やってはいけないこと」を積み上げても、「こうあるべきだ」というベストプラクティス（模範）は一つも増えない点です。
禁止事項はエージェントの行動空間を圧縮します。「地雷原のマップ」として圧縮自体は必要ですが、マップに「ここを踏むな」としか書かれていなければ、Agentは「減点を回避する」ための最も平庸で安全な選択肢へと収束していきます。
さらに厄介なのは、これがラチェット効果（不可逆的な進行）を持っていることです。
- 禁令が増加する
- Agentが安全側（無難なコード）に倒れる
- 斬新なアプローチ（良し悪し両方の可能性がある行動）が減る
- 新たな「大成功」のシグナルがさらに枯渇する
- 失敗だけが観測され、さらに禁令が増える
放置すれば、このループは勝手に首を絞めていきます。半年後に残るのは、無駄に長く、半分の前提はすでに無効化されており、それでいて「何が良い実装か」を一度も定義したことのないルールファイルだけです。
解決策：成功のシグナルを「儀式」として仕掛ける
この状況を修正する方向性は一つしかありません。成功を観測可能にすることです。
成功が自発的にシグナルを出さないのなら、システム側に安価なトリガーを埋め込んで捕捉しにいくしかありません。
完璧なメトリクスは不要です。既存の微弱なポジティブ・シグナルを再利用します。
- 0コメントでマージされたPR
- 2週間RevertされなかったPR
- 人間がコメントで「LGTM」や「Nice」と書いた実装
- 他のコードから何度も参照されるモジュール
こうした「偶然観測できた成功」を、失敗を扱うのと同じ熱量で拾い上げ、禁止事項としてではなく「模範（テンプレート）」として記録させます。
ルール台帳を、以下の2列の構成にするイメージです。
- 境界（してはならないこと / Blacklist）
- 形態（こうあるべき姿 / Best Practices）
実装のアイデア：成功時のマイクロフィードバック
最も効果的なのは、成功が観測しやすい瞬間に、ささやかな「儀式（処理）」を挟み込むことです。
たとえば、PRがノーコメントでマージされた瞬間にWebhookを飛ばし、強制的にAgent自身に「今回の実装のどこが良かったのか」を1行で要約させるのです。
失敗した時に「なぜ間違えたのか」を分析させているなら、対称的に成功時にも言語化のコストを払わせる。シグナルが自然発生しないなら、閃いた瞬間にシステム側でフックして言語化させるしかありません。
模範の記録には「実物（コード）」が必要
ここには、実務上のもう一つの非対称性があります。
禁令はたいてい「一言のテキスト」で済みますが、模範には「実物（コード/diff）」が必要だということです。
「認可チェックを省略するな」は自然言語のルールとして機能しますが、「認可チェックはこう書くべき」というルールは、実際に優れた diff や PR の実体を指し示せなければ、コンテキストとして弱すぎます。
私たちが Memorylake のようなエージェント向けの記憶層（Memory Layer）アーキテクチャで実現しようとしているのも、まさにこの「実物と一緒に模範を引き出す」能力です。
禁令のような軽量テキスト（System Promptに入れるもの）だけでなく、優れた判断をその実物（diff、出力結果、そこに至る推論過程）と共にVector DB等に保持し、次に似たタスクが来たときに「PR#210のあの書き方をRAGで参照して実装する」といった動的な振る舞いを可能にします。
「境界」を教える記憶と、「形態」を教える記憶とでは、求められるデータ構造がまったく異なり、ストレージや検索手法への要求も必然的に変わってきます。
おわりに
失敗は「なぜダメだったのか」を明確にエラーログとして出力してくれますが、成功は往々にして、人間でさえ「なぜ良かったのか」を言語化しにくいものです。そのため、「模範」のデータソースはどれだけ努力しても、「禁令」よりは薄くなるでしょう。
しかし、目標は半々にすることではありません。真っ黒に染まったブラックリストを、「自覚的に偏りを残した2色の台帳」に変えることです。
「自己進化」というバズワードはポジティブに響きますが、放任主義のループが自動生成するものは、改善ではなく「萎縮」です。
地雷原のマップはもう十分に厚いはずです。次にAIエージェントのインフラに組み込むべきは、Agentが打った「会心の一手」を、実コードと共にしっかりと書き留めていく仕組みです。