プロンプトやツールを自ら改変する自己進化型LLMエージェントについて、2026年8月末にarXivへ…

プロンプトやツールを自ら書き換えて能力を伸ばす「自己進化型」のLLMエージェントが研究の最前線に現れている。だが2026年8月末にarXivへ投稿された査読前の複数の論文によれば、自己書き換えは「戻せない変更」を残すリスクを伴い、防御側の仕組みもまた静的なままでは機能不全に陥る可能性が指摘されている。本記事では、進化と制御の両面を扱った3本の論文から、エージェント設計の次の論点を整理する。

自己進化がもたらす「回復不能」な変異の問題

LLMエージェントは、システムプロンプトやツール定義、実行ハーネスまでを実行時に自分で変更する方向へ進んでいる。能力向上には有効だが、一度成功した自己改変が、別の状態では安全に取り消せない——こうした「回復可能性」の問題を体系化したのが、2026年8月28日にarXivへ投稿された(査読前)EvoUndoである。

この研究は600件の未見タスクで自己進化を実験し、能力を実際に向上させた変異197件が回復可能性の検証に失敗したと報告している。つまり、うまく動いた自己書き換えの3分の1近くが、「元に戻す」操作を保証できない状態を残していたことになる。従来の反復的な修復プロンプトではこの自然発生した失敗を1件も回復できず、状態を正確に指定する「グラウンディング」と、復元言語の表現力を拡張することで、初めて回復率が9割を超えたという。

注目すべきは結論の方向性だ。論文は、信頼できる自己進化には検証・状態特定・復元言語の設計を共同設計する必要があり、プロンプトの繰り返しでは不十分だと主張している。エージェントフレームワークの設計者が「進化機能」を足すだけでなく、その取り消し機構までを一緒に設計すべき、という示唆と読める。

攻撃側も進化する:静的防御の限界

自己進化の議論は防御側にも及ぶ。同じく8月26日にarXivへ投稿された(査読前)別の論文は、ジェイルブレイク攻撃への対策が静的である限り、いたちごっこに終わると指摘する。多くの防御は配置時に安全挙動が固定され、新種の攻撃手法に対して経験を蓄積できない。

この論文が提案するのは、攻撃が成功するたびにその失敗を「手法レベルのルール」として抽象化し、外部のルールメモリに蓄えて再利用する、テスト時自己進化型のマルチエージェント防御だ。有害なトピックではなく攻撃の構造(ロールプレイ、難読化、多段階の迂回など)でルール化するため、1つのルールが同種の攻撃族全体に一般化されるという。仕組みは外部メモリとプロンプトのみで動作し、モデルのパラメータ更新を必要としないため、ブラックボックスのAPIモデルにも適用できるとされる。

実験では、複数のブラックボックス攻撃族に対して攻撃成功率を大幅に下げつつ、良性の利用を損なわず、適応的な複合攻撃に対しても頑健だったと報告されている。ただしこれは著者ら(シンガポール国立大学の研究グループ)の実験に基づく主張であり、査読を経た段階ではない点には注意が必要だ。

命令の仲裁そのものが攻撃面になる

進化や防御といった機能面とは別に、より根源的な脆弱性を指摘する研究もある。8月28日投稿の(査読前)論文「Recognition Without Enforcement」は、LLMエージェントがシステムプロンプト・ユーザー・メモリ・ツール由来の複数の命令を仲裁する際、その仲裁が信頼境界を強制しているとは仮定できない、と論じる。

著者らは「認識と強制のギャップ」と呼ぶ現象を特定した。ソースの書式特徴(ロールテンプレート上の位置、チャネルのメタデータ、整形の手がかり)はモデル内部で線形に読み取れる一方で、その情報が実際の拒否や実行の制御に結びついているとは限らない。つまりモデルは「どこからの命令か」を認識できていても、それを権限の強制に使えていないケースがあるというのだ。

システムプロンプトインジェクション対策が「見分けられること」と「守れること」を混同してきた可能性を示す指摘であり、エージェントに外部ツールやメモリを持たせるフレームワークでは、仲裁機構そのものを検証対象にするべきだという方向性を裏付ける。

フレームワーク設計の次の論点は「可逆性」と「経験の蓄積」

3本の論文は、それぞれ異なる層に問題を設定している。EvoUndoは自己改変の可逆性を、ジェイルブレイク防御の研究は防御経験の蓄積を、命令仲裁の研究は信頼境界の強制を扱う。共通するのは、静的に固定された設計では、動的に変化するエージェントの挙動に追従できないという視点だ。

実務への含意は2つに絞れる。第一に、エージェントに自己書き換えを持たせる場合は、変更の記録と検証済みの復元手段を同時に実装すべきである。EvoUndoの実験が示すように、反復プロンプトによる場当たり的な修復は機能しない可能性が高い。第二に、防御は配置時に完成するものではなく、失敗を構造化された知識として蓄え続ける仕組みに移行する必要がある。ルールメモリのような外部化された経験は、パラメータ更新できない環境でも動作する現実的な選択肢だ。

読者に一つ問いたい——自社のエージェント実装で「戻す」手段を設計に組み込んでいるだろうか。自己進化はもはや研究テーマではなく、実装に先立って決めるべき要件になりつつある。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

+