この記事の音声は準備中です。
音声の一覧・再生リストへ常駐エージェントのライフサイクル管理
この記事の目的
数週間〜数か月動き続けるエージェント(常駐アシスタント・監視エージェント・継続タスク)の緩やかな劣化と世代交代を運用できるようになります。短時間のタスクでは表面化しない、長期運用に固有の劣化(記憶の肥大・指示の矛盾・環境とのずれ・品質ドリフト)を検知し、メンテナンス・引き継ぎ・退役まで設計できる状態がゴールです。
対象読者
- 立ち上げっぱなしで長期間動かすエージェントを運用する、または運用予定のエンジニア・SRE
- 「最初は良かったのに、動かし続けるうちに挙動が怪しくなる」を経験しているチーム
前提知識
- 非同期・長時間タスクの設計(耐久実行) — 実行の永続化・中断再開(本記事はその上のライフサイクル運用)
- 長期記憶の実装 — 記憶の保存・忘却(劣化の一因)
本文
概要: 分担と「ライフサイクル全体」
| 対象 | 正本 | 本記事 |
|---|---|---|
| 実行の永続化・中断再開・冪等性同じ操作を複数回実行しても副作用の結果が 1 回と変わらない性質です。事前の実行済み確認だけでは並行実行や記録前クラッシュを防げず、受け側の原子的な重複排除などの実装条件が必要です。、エージェントの API 設計 | 非同期・長時間タスクの設計(耐久実行) | — |
| 記憶の保存・想起・忘却 | 長期記憶の実装 | — |
| コンテキストの圧縮・仕切り直し | コンテキストの圧縮と隔離 | — |
| 常駐個体の長期運用・世代交代・退役 | 本記事 | 劣化の類型・定期メンテ・引き継ぎ・個体差 |
耐久実行実行の各ステップの結果を永続ログに記録し、障害後は完了済みステップをスキップして途中から再開できる実行モデル。LLM 呼び出しなどの非決定的な処理を「結果が記録される単位」に隔離するのが要点。(非同期・長時間タスクの設計(耐久実行))が「1 つのタスクを中断・再開しても壊さない」設計なのに対し、本記事は「長く動き続ける個体そのものを、劣化させずに運用・世代交代させる」ライフサイクルを扱います。1 回のセッションの劣化(長い対話でのコンテキスト肥大)は コーディングエージェントのコスト最適化 等が触れますが、本記事は週・月単位で動き続ける常駐個体の運用に絞ります。
長期運用で起きる劣化の類型
長期運用では、以下の問題を継続して監視します。ここでの「個体」はプロセス・設定・外部記憶・タスク状態をまとめた運用上の単位です。長く起動しているだけでモデルの重みが劣化する、という意味ではありません。
| 劣化 | 内容 |
|---|---|
| 敵対的な記憶汚染 | 非信頼の資料・ツール結果の命令や偽の決定が記憶へ入り、後の実行権限の根拠になる |
| 記憶・コンテキストの肥大と汚染 | 履歴・記憶が増え続け、古い決定・無関係な脱線が判断を狂わせる |
| 蓄積した設定・指示の矛盾 | 継ぎ足した指示・ルールが矛盾を抱える(「呪文の地層」の実行時版) |
| 外部環境とのずれ | ツール・API・知識源が変わり、個体の前提と現実がずれる |
| 品質の緩やかなドリフト | どこかで壊れたわけではないのに、少しずつ挙動・品質が想定から外れる |
これらは緩やかな変化として現れる場合も、API 変更や誤った記憶の取り込みをきっかけに急に現れる場合もあります。失敗イベントの監視と、SLI の推移(AI 品質の SLO 設計)を組み合わせます。以下のライフサイクルは本記事の運用設計例であり、週・月単位で品質が必ず下がるという実証則ではありません。
定期メンテナンスの設計
保存状態と外部環境の変化に備え、定期的な手入れとイベント起点の見直しを設計に組み込みます。
- 記憶の棚卸し: 溜まった記憶・履歴を定期的に見直し、古い決定・無効になった情報を整理します(長期記憶の実装の忘却の運用)。決定事項も出所・承認・検証結果を確認して残します。非信頼の記憶は再検証してから引き継ぎ、命令や権限として採用しません。試行錯誤の生ログは保持要件に従って整理します
- 仕切り直し(コンテキストのリセット): 汚染が進んだら、外部化した状態(計画・決定・成果物への参照)から新しいコンテキストを作り直します(コンテキストの圧縮と隔離の仕切り直し)。平時から状態を外部化しておくことが、これを可能にします
- ヘルスチェック: 「個体が健全か」を定期的に確かめます。SLI の推移(品質・成功率・エスカレーション率)を監視し、緩やかな下降を早期に捉えます(可観測性とトレーシング・AI 品質の SLO 設計)
- 設定・指示の整理: 継ぎ足した指示の矛盾を定期的に棚卸しします(プロンプト資産の管理と同じ規律。プロンプト資産の管理とバージョニング)
世代交代: 新しい個体への引き継ぎ
劣化した個体は、手入れで戻らなければ新しい個体に世代交代します。人の引き継ぎと同じ設計が要ります。
- 何を移し、何を捨てるか: 出所・承認・検証結果を確認した決定事項・知識・進行中タスクだけを引き継ぎ、汚染した履歴・無効な設定は捨てます。「全部コピー」は劣化ごと引き継ぐことになります
- 並行比較で検証する: 新個体の判定を、保存した入力の再生や副作用を無効にしたシャドー実行で旧個体と比較します。注文・送信・更新を新旧の両方から実行しません。切り替え時はタスクの実行権を排他的に移し、処理済み記録と業務の冪等キーを引き継ぎます(バージョニングとモデル更新追従・耐久実行)
- 引き継ぎ材料を平時から用意する: 世代交代を可能にするのは、外部化した状態(決定ログ・記憶ストア・タスクリスト)です。個体の頭の中だけに情報があると、引き継げません
個体差の管理
見落とされがちですが、同じ設定でも履歴によって挙動が分かれます。
- 常駐個体は、動いてきた履歴・蓄積した記憶が個体ごとに違うため、「同じプロンプト・同じモデルの個体 A と B が違う振る舞いをする」が起きます
- 複数の常駐個体を運用するなら、この個体差を前提にします。1 個体で観測した挙動が他個体でも同じとは限りません
- 再現性が要る場面では、個体の状態(記憶・設定)もバージョン管理・スナップショットの対象にします
退役の設計
常駐個体には終わりも設計します。
- 役目を終えた・劣化が進んだ個体は、状態を保全(または安全に破棄)して退役させます。動かしっぱなしの個体は、コスト・セキュリティ・劣化のリスクを溜め続けます
- 退役時に、記憶ストア・永続化した状態の削除・保持を決めます(データガバナンスデータの所有責任・品質・利用条件・更新を組織で管理する仕組み。RAG や社内知識を使う Agent では、知識源の品質・鮮度・権限が回答を制約するため、カタログ・品質基準・AI 利用可否を整備する。モデル・検索・推論等の品質管理とも組み合わせる。・会話データの管理基盤の保持と削除)
- 「いつ退役させるか」の基準(SLI がこの水準を割ったら世代交代・退役)を、立ち上げ時に決めておきます
実務での注意点
アンチパターン
- 常駐個体を立ち上げっぱなしで放置する → 記憶肥大・指示矛盾・環境ずれで緩やかに劣化する → 定期メンテナンス(棚卸し・仕切り直し・ヘルスチェック)を組み込む
- 劣化を急な故障としてしか監視しない → 緩やかな品質ドリフトを見逃す → SLI の推移で下降を早期に捉える
- 世代交代で全状態をコピーする → 汚染した履歴・無効な設定ごと引き継ぐ → 決定・知識は移し、汚染・無効は捨てる
- 新個体をいきなり切り替える → 品質低下に気づかず本番が劣化する → 副作用を無効にしたシャドー実行で比較し、実行権を排他的に切り替える
- 状態を個体の中だけに持つ → 世代交代も仕切り直しもできない → 決定・記憶・タスクを平時から外部化する
- 退役を設計しない → 不要な個体がコスト・リスクを溜め続ける → 退役基準と状態の削除・保持を最初に決める
チェックリスト
- 敵対的な記憶汚染を監視し、非信頼の出所の記憶は再検証してから引き継ぐ
- 長期劣化の類型(記憶肥大・指示矛盾・環境ずれ・品質ドリフト)を監視対象にしている
- SLI の推移で緩やかな品質下降を検知している
- 記憶の棚卸し・仕切り直し・ヘルスチェックの定期メンテナンスがある
- 決定・記憶・タスクを外部化し、仕切り直し・引き継ぎを可能にしている
- 世代交代で何を移し何を捨てるかの基準がある
- 新旧比較では副作用を二重実行せず、切り替え時の実行権と処理済み状態を引き継いでいる
- 複数個体を運用する場合、個体差(同設定でも挙動が分かれる)を前提にしている
- 退役基準と、退役時の状態の削除・保持を決めている
関連トピック
-
高度な攻撃パターン — 敵対的な記憶汚染と再検証
-
非同期・長時間タスクの設計(耐久実行) — 実行の永続化・中断再開(本記事の土台)
-
長期記憶の実装 — 記憶の保存・忘却(棚卸しの対象)
-
コンテキストの圧縮と隔離 — 汚染時の仕切り直しの手法
-
AI 品質の SLO 設計 — 緩やかな品質ドリフトを SLI で検知する
-
バージョニングとモデル更新追従 — 世代交代の並行稼働・切り替えの機構
-
プロンプト資産の管理とバージョニング — 蓄積した設定・指示の矛盾を整理する規律
-
会話データの管理基盤 — 退役時の状態・記憶の保持と削除
参考資料
- Anthropic — Effective harnesses for long-running agents — 複数のコンテキストにまたがる実行で、進捗ファイル・履歴・テストから状態を引き継ぐ実験。週・月単位の常駐個体の劣化率を測った研究ではありません(アクセス日: 2026-09-10)
- AWS Builders’ Library — Making retries safe with idempotent APIs — 副作用の重複防止。本記事では個体切り替え時の業務キーの引き継ぎにも適用しています(アクセス日: 2026-09-10)
TODO・未確認事項
なし