AIエージェントに予測や判断のロジックを自動改善させる仕組みを検討しているなら、改善の履歴をどう扱うかは早めに決めておきたい設計判断です。モデルの重み（パラメータの数値）を更新するだけでなく、提案されたが採用されなかった戦略をどう記録するかで、後から原因調査できるかどうかが大きく変わります。
題材として、ロンドンのPM2.5（粒径2.5マイクロメートル以下の微小粒子状物質）濃度を予測する自己改善エージェント「AeroLoop」の設計が参考になります。このエージェントは予測を立てた後、実測値が届いた時点で自分の誤差を採点し、大規模言語モデル（LLM）に改善案を出させます。特徴的なのは、改善に失敗した提案を削除せず「v7-rejected」のようなバージョン名で保存し、ダッシュボード上に表示し続ける点です。
この設計は特殊なハックではなく、AI駆動開発で自動化パイプラインを組む際に誰もが直面する「ログと再現性」の問題そのものです。自分のプロジェクトでエージェントに戦略改善や自動チューニングをさせるなら、同じ判断を迫られます。以下では、履歴保持の設計をどう選ぶかを整理します。
どんな場面でこの判断が必要になるか
LLMにコード生成や設定変更の提案をさせ、評価結果に応じて自動採用する仕組みを作る場面で必ず浮上する論点です。
たとえば、CI/CDパイプラインにAIがテストカバレッジ改善のパッチを提案し、自動でA/Bテストして良ければマージするような構成を考えてみます。採用されなかったパッチをどう扱うかは、最初の設計段階で決めておかないと後から直しにくい部分です。
他にも、プロンプトを自動チューニングするエージェントや、インフラのコスト最適化パラメータを自動調整するエージェントなど、「提案→評価→採用/棄却」のループを回す構成全般に当てはまります。
判断軸
再現性の要求レベルが最初の軸です。なぜ今のパラメータになったのか、後から誰が見ても追跡できる必要があるかどうかで必要な記録粒度が変わります。
評価の客観性も重要です。AeroLoopでは、チューニングに一切使っていない時系列順のホールドアウトセット（学習や調整に使わず評価専用に取っておくデータ）でのみ採用判定をしています。この仕組みがないと、提案を却下したという記録自体の信頼性が揺らぎます。
ストレージとノイズのコストも無視できません。すべての失敗試行を保存し続けると、ダッシュボードやログが肥大化し、本当に重要な情報が埋もれるリスクがあります。
フォールバックの透明性も軸になります。LLMの応答が得られない、または不正な形式だった場合にどう振る舞うかを明示しておかないと、障害時にサイレントに動作が変わってしまいます。AeroLoopはLLMが使えない場合に決定的なヒューリスティック（経験則に基づく簡易ロジック）で代替案を出し、どちらの手段で生成された値かをレポートに明記する設計を採っています。
選択肢の比較
履歴保持の設計は大きく3パターンに分けられます。最新版だけを残す「上書き型」、成功のみ記録する「ベストオブ型」、成功も失敗も全履歴を残す「ゴースト保持型」です。
| 方式 | 再現性 | 運用コスト | 向いている場面 |
|---|---|---|---|
| 上書き型（最新のみ保持） | 低い | 最小 | 試行回数が少なく影響範囲が限定的な個人プロジェクト |
| ベストオブ型（成功のみ記録） | 中程度 | 中程度 | 本番運用で改善トレンドだけ追えればよい場合 |
| ゴースト保持型（全履歴＋棄却理由を記録） | 高い | 高め | 規制対応や障害調査が頻発するチーム、AIの意思決定を説明する必要がある場合 |
AeroLoopのデモでは、4地点×30時間分、合計120件の予測・実測ペアを使い、ホールドアウトMAE（平均絶対誤差）が3.94から2.99まで、約24.1%改善しています。この過程でv3・v5・v6は採用され、v7-rejectedは棄却されてゴーストとして保存されました。この一連の採用・棄却の記録があったからこそ、「バイアス項を4.5まで上げる提案は却下された」という事実が後から検証可能になっています。
興味深いのは、Prior Labs社の基盤モデルTabPFN（表形式データ向けに事前学習されたモデル）による一括提案と、LLMによる段階的な微調整が同じホールドアウトセットで競わされている点です。最初はTabPFNが優勢でしたが、後にLLMの段階的チューニングが僅差で上回りました。この比較自体も、履歴が保存されていなければ後から振り返れない情報です。
ケース別の推奨
AIに自動チューニングや戦略提案をさせる本番パイプラインを運用するなら、ゴースト保持型を選ぶのが無難です。採用・棄却の理由と評価に使ったデータの境界（どこまでがチューニング用で、どこからが評価専用か）をセットで記録しておくと、後から「なぜこの設定になったのか」を説明できます。
個人の検証プロジェクトやPoC（概念実証）段階なら、上書き型で十分なことが多いです。試行回数が少なく、失敗の経緯を後から説明する必要性も薄いためです。
社内向けの小規模な自動化ツールで、改善トレンドだけ共有したいなら、ベストオブ型が扱いやすいところです。失敗のゴーストまで共有すると、かえってチームの意思決定が遅くなる場合もあります。
あえて見送るべき条件
すべてのプロジェクトでゴースト保持型が最適というわけではありません。
評価用のホールドアウトデータを用意できない、あるいはチューニングと評価を明確に分離できない状況では、棄却の記録自体に意味がなくなります。まず評価設計を固めるのが先です。
また、提案と評価のサイクルを回す頻度が極端に高い場合（たとえば数秒おきに自動提案が走るような構成）は、全履歴保持がストレージと可読性の両面で破綻しやすくなります。この場合は一定期間ごとに古いゴーストを要約・集約する仕組みを別途検討する必要があります。
導入前に確認すること
自分のプロジェクトに履歴保持の設計を取り入れる前に、次の点を確認しておくと判断しやすくなります。
- 評価に使うホールドアウトデータを、チューニング用データと物理的に分離できているか
- LLMやモデルが使えない場合のフォールバックロジックと、その使用履歴を記録する仕組みがあるか
- 採用・棄却の判定基準（AeroLoopの場合はホールドアウトMAEの改善有無）を数値で定義できているか
- 保存する履歴の量が増えたときの閲覧性（ダッシュボードやログの検索性）を確保できているか
公開されているAeroLoopのリポジトリはOllama（ローカルでLLMを動かすツール）を使ってローカル環境で再現できる構成になっています。実際の採用・棄却ロジックのコード、特にホールドアウト評価の実装部分を読んでみると、自分のパイプラインに応用できる具体的な設計のヒントが見つかるはずです。