Hermes Agent が12回自己改善した。ただし間違った目標に向かって ── self-improving loop 実験記録

Hermes Agent のスキルファイルを AI 自身が 12 サイクル書き換える self-improving loop（AI が自分自身の動作ルールを評価・改善し続けるループ）を実施した。外部評価者を組み込んで CLIP 0.86 を達成したが、seed の基準属性が誤っており Cycle 1〜10 は wrong target への最適化だった。Cycle 11 で属性を修正すると CLIP 0.8901（全サイクル最高）を記録した。

AI がループを回し続けているとき、「最適化している先が正しいゴールか」は気づきにくい。

本記事では 12 サイクルの self-improving loop 実験から、評価者設計・コンテキスト設計・seed 品質という 3 つの支配要因を実験データで示す。

10 サイクル分の最適化を、seed 修正 1 回が上回った。

TL;DR

• Hermes Agent の skill ファイルをエージェント自身が反復書き換えする実験を 12 サイクル実施した
• 得られた発見は4つ。最も痛かったのが技術的なものではなかった ── セットアップ担当の AI が参照画像を確認せずに書いた属性が間違っており、Cycle 1〜10 は全て誤った目標に向かって最適化し続けていた

どんな実験をしたのか？

Hermes Agent はスキルファイル（Markdown）を読み込んで動作する。このスキルを エージェント自身の評価とフィードバックで書き換え続ける ループを設計した。

Cycle N:
  1. skills/*.md（前 Cycle の改善ノート含む）を読み込む
  2. タスクを実行
  3. 外部評価者がスコア付けと問題点の抽出
  4. 次版制約を "## 改善ノート Cycle_N" として skill 末尾に追記

次の Cycle はこの追記をそのままシステムプロンプトとして受け取る。タスクは段階的に難化させた：Phase 0（X投稿文の生成）→ Phase 1a（評価者・生成者の交代）→ Phase 1b（AI キャラクター画像の生成、CLIP スコアで評価）。

発見 1: 生成と評価を同じモデルに任せると何が起きるか？

同じモデルが生成と評価を兼任すると、スコアが上がらない。

準備段階のテキスト生成タスク（5サイクル）でこの現象に気づいた。スコアが 6.0〜6.33 で頭打ちになり、何サイクル回しても動かなかった。モデルは自分が「良い」と判断する出力を生成し、自分が「良い」と評価する ── 同じバイアスが両方に乗るためだ。

メインの画像生成フェーズでも同じ構造が問題になった。外部評価者（Kimi K2.6）を導入するとスコアの分散は広がったが、頭打ちは解消しなかった。解消したのは 生成者も別モデル（Qwen3.6:27b）に切り替えた タイミングだった。

実用的な示唆: self-improving loop に外部評価者を組み込むだけでは不十分。「より賢い評価者の指摘に対応できる、別の生成者」が揃って初めて頭打ちを解消できる。

発見 2: エージェントが参照できないコンテキストはどう処理されるか？

エージェントが「見えていない」情報は「ない」情報として扱う。

Phase 1b の Cycle 4 で Kimi が不可解な分析を出した。

Cycle 4 での Kimi 分析の失敗:
1. 「Animagine XL 4.0 のプロンプト」と誤認（実際は Nano Banana Pro）
2. 基準属性から逸脱した「purple hair, yellow eyes」を提案
3. 「前日データなし」と書くが skill 内に Cycle 1-3 履歴がある

調べると、原因はドライバ実装の入力切り詰め（

skill_md[:1500]

コンテキスト設計は機能設計と同じ重さで扱うべきだ。

発見 3: CLIP スコアが上がれば画像は良くなっているか？

CLIP 0.86 を達成しても、欲しい画像にはなっていなかった。

Phase 1b では CLIP ViT-L/14 スコア（参照画像 n=10、合格ライン 0.80）を評価指標にした。評価基準となるキャラクター外見属性を「基準属性」と呼ぶ（参照画像セットから読み取った属性一覧）。

Cycle 3 で Nano Banana Pro（スタイル転写型 API）に切り替えると CLIP mean 0.8614 を達成した。しかし人間目視では「留め具の形状」「胸当ての細部」「後ろ髪の表現」の 3 要素が未達だった。これらは以降のサイクルでも改善されなかった。

Cycle 9 で Kimi 自身がこの限界を診断した。

"Nano Banana Pro は style/identity transfer 型で、pixel-level の細部の厳密復元を行わないモデル固有特性。3 細部の未再現は prompt 起因ではなく

backend の構造的限界。"

CLIP スコアは「画像全体が参照画像にどれだけ似ているか」を数値化する。人間が期待する「特定ディテールの再現」は別の指標が必要だ。指標が何を測っているかを理解してから使え、ということだ。

余談: HITL が「制約 1 行の追加」として機能した

3 細部が改善しないため、skill ファイルに以下の 1 行を追加した。

If Nano Banana Pro repeatedly fails to preserve pixel-level outfit details,
you may recommend switching to a structure-preserving backend such as
ComfyUI + ControlNet/IP-Adapter, and explain why.

これは「指示」ではなく「許可」の付与だ。次の Cycle で Kimi は自分の判断として backend switch を提案し、その rationale を skill に追記した。Human-in-the-Loop が「プロンプトの書き換え」ではなく「制約ファイルへの 1 行追加」として機能した点が面白かった。

発見 4（最重要）: seed が汚染されると何が起きるか？

Cycle 11 の着手前、デモ動画を確認していて気づいた。「目が緑のはずだけど？」

実験のセットアップを担当した AI アシスタント（Claude Code）が、参照画像を直接確認せず「記憶」でキャラクター属性を skill ファイルに書いていた。

red eyes

green cap

セットアップ時に Claude Code へ「参照画像を見て書け」と明示しなかった。Claude Code は記憶で書き、誰も検証しなかった。デモ動画を確認していて初めて気づいた。

loop は正しく動いていた。問題は目標だった。

Cycle 3 で CLIP 0.8614 を「合格」として喜んでいたが、それは「赤目・緑帽子のキャラ」を正確に生成した数値だった。self-improving loop のメカニズム自体は壊れていない ── 与えられた目標に向かって効率よく収束していた。ただその目標が参照画像と食い違っていた。Cycle 8 で skill に追加した制約も、wrong 属性の上に立っていた。

修正後の初サイクルで全 Cycle 最高スコア

基準属性を 13 項目（緑目・帽子なし等）に修正して Cycle 11 を実行した。

過去最高の Cycle 3（0.8614）を +0.029 で超えた。基準属性の修正というシンプルな変更が、10 サイクル分の最適化を上回る改善をもたらした。

制約の出所（どんな根拠で書かれたか）が agent の出力品質を決定する。あらゆる agentic loop で「最初の seed は何を根拠に書かれたか」を問い直すべきだ。

デモ動画

まとめ

self-improving loop は単純な構造で成立する。しかし「誰が評価するか」「コンテキストに何が入っているか」「seed の基準属性は正しいか」が品質を左右する。モデル能力よりも ループの設計と seed の品質 が支配的だった。

特に seed 汚染の発見は予想外だった。評価対象のエージェント（Kimi/Hermes）ではなく、ループを構築した別 AI（Claude Code）が参照画像を確認せずに属性を書いたことが根本原因だった。エージェントがどれだけ適切に最適化しても、seed が wrong であれば wrong target に向かい続ける。

リポジトリ: tokimwc/hermes-creative-loop

📚

関連記事—toki_mwc の Zenn 記事一覧で AI エージェント・ローカル LLM の実験記録を公開しています。

📝 評価モデルに Kimi K2.6、生成に Nano Banana Pro・Qwen3.6:27b を使用しました。執筆には Claude Code を補助利用しました。

GitHubで編集を提案