AIエージェントに過去の失敗を覚えさせている人へ。その反省文は、直す相手を間違えていませんか。
タスクが失敗した。そこで「この計画は使わない」と記憶に残す。次のタスクでは、その記憶を読んで別の計画を選ぶ。
実行時の引数だけが間違っていたなら、これで捨てられるのは正しい計画です。
2026年9月2日、厦門大学・浙江大学・Alibabaの研究者らがCHIMEの論文を公開しました。扱うのは、エージェントが経験を記憶するときの原因の取り違えです。最終結果から直接反省を保存する方法に対し、計画と実行のどちらに学ぶべき点があるかを先に判定します。
結論から言うと
成功・失敗の記録と、次に使う教訓は、分けて作る必要があります。
CHIMEは計画用と実行用の記憶を分けます。開発元の公開説明も、原因を割り当ててから記憶することを中心に据えています。
あなたのエージェントに持ち帰れるのは、メモリ保存の直前に置く確認です。
「何に失敗したか」に加えて、「計画は条件を満たしていたか」「実行は計画に従ったか」を残す。この二つがなければ、読みやすい反省文は作れても、何を修正すべきかは決まりません。
計画の誤りと実行の忠実さを分けて考えるためのAI生成イラスト。実際の実験風景ではありません。
計画どおりに動いたのに、失敗した
論文付録Cの配送タスクの分析に、違いがはっきり出ています。実行側は予定に従っていましたが、計画側が厳密な「指定時刻より前」という条件に、同時刻も含めてしまいました。この失敗から更新するのは計画用の記憶で、実行用は触りません。
実行担当に「もっと正確に計画を守れ」と教えても、直りません。
問題のある予定を、さらに正確に守るだけだからです。
このケースを実装の言葉に置き換えると、確認する対象は少なくとも三つあります。
| 確認対象 | 確かめたいこと |
|---|---|
| 依頼の条件 | 「より前」なのか、「以下」なのか |
| 実行前の計画 | その条件を満たす予定になっていたか |
| 実際の操作 | 予定どおりの時刻や引数を使ったか |
最後の操作だけを残しても、誤った引数を実行担当が作ったのか、計画から受け取ったのかを区別できません。逆に、計画だけを残しても、実行時に何が変わったかは追えません。
修正先を決めるには、結果に至る途中の境界を残す必要があります。
記憶を分けると、次に変わる判断も分かれる
「計画」と「実行」を別の保存先にする意味は、整理整頓だけではありません。次のタスクで、その情報を渡すタイミングを変えられます。
計画を作る段階で必要なのは、依存関係や制約についての知識です。操作を実行する段階では、対象の識別子や引数の扱いが問題になります。
以下は、この違いを自分の業務に当てはめるための整理例です。
| 保存したい教訓 | 次に使う場所 | 変える判断 |
|---|---|---|
| 前工程の確定後に後工程を予約する | 計画作成時 | 作業の順序 |
| 上限に到達する前に余裕を確保する | 計画作成時 | 予定の組み方 |
| 表示名ではなく一意なIDで対象を指定する | ツール実行時 | 引数の組み立て |
| ツールの返却値から完了状態を確認する | ツール実行後 | 次へ進む条件 |
この四つを一つの反省文に混ぜると、どの担当に何を変えてほしいのかが曖昧になります。特に、計画を作り終えた後で順序の教訓を渡しても、計画を再検討する経路がなければ間に合いません。
保存先の分離と、読み出すタイミングの分離はセットです。
CHIMEの処理順序も、この境界に沿っています。
依頼 → 計画用の記憶を取得 → 計画を生成
→ 依頼と計画から実行用の記憶を取得 → 実行
→ 計画・実行履歴・結果・参照した記憶を診断 → 記憶を更新
帰属は、計画、実行、その両方、どちらでもない、の四つです。重みを更新しないLLMが判定し、証拠不足や外部要因では「どちらでもない」も選べます。
ここは実装上も大事です。選択肢が「計画」か「実行」だけなら、ログ不足や外部サービスの障害まで、どちらかの教訓に押し込むことになります。
さらに、帰属が決まっても無条件には保存しません。同じ更新処理では、確信度と具体性を確認し、既存記憶への統合、新規追加、破棄を選びます。
保存しないという分岐があれば、原因の分からない一回を、次のすべてのタスクに適用する規則へ昇格させずに済みます。
メモリ保存の前に、二つの判定を分離する
ここからは論文の実装ではなく、自分のエージェントに組み込むための最小例です。前述の時刻制約を、外部APIなしで確認できる形にします。時刻とレコードは説明用です。
見るのは、計画が制約を守るかと、実行が計画に一致するか。それぞれを別の値にします。
from datetime import datetime
def inspect_deadline(trace):
deadline = datetime.fromisoformat(trace["deadline"])
planned = datetime.fromisoformat(trace["planned_at"])
executed = datetime.fromisoformat(trace["executed_at"])
if any(t.utcoffset() is None for t in (deadline, planned, executed)):
raise ValueError("タイムゾーン付きの時刻が必要です")
return {
"plan_satisfies_constraint": planned < deadline,
"execution_matches_plan": executed == planned,
"observed_satisfies_constraint": executed < deadline,
}
trace = {
"deadline": "2026-10-01T18:00:00+09:00",
"planned_at": "2026-10-01T18:00:00+09:00",
"executed_at": "2026-10-01T18:00:00+09:00",
}
print(inspect_deadline(trace))
{'plan_satisfies_constraint': False, 'execution_matches_plan': True, 'observed_satisfies_constraint': False}
決定的なのは、最初が False でも二つ目は True になることです。失敗という一語にまとめると、この違いが消えます。
このコードは原因を自動確定しません。時刻条件を検査し、後段の診断に渡す材料を作ります。日時の解釈と比較にはPythonの標準のdatetimeを使い、タイムゾーンのない入力は受け付けません。業務ではさらに、記録時刻と実際の完了時刻の違い、時計の精度、許容される遅延を定義する必要があります。
たとえば予定を17時50分、実行を18時00分に変えれば、計画の条件は通り、計画との一致は落ちます。今度は実行側の調査が必要です。ただし、外部APIの遅延なのか、呼び出し忘れなのかは、この三つの時刻だけでは決まりません。
一方、悪い予定を実行担当が修正して17時50分に終えたなら、結果は成功します。それでも、元の計画が条件違反だったことは消えません。
成功したから計画を丸ごと再利用してよい、という判断にも同じ穴があります。
上のコードと、この三つの経路はローカルで実行確認しています。CHIME本体の再現実験ではありません。
原因判定を外すと、何が変わったか
CHIMEの比較実験では、Qwen3.5-Flashを使った4ベンチマークの評価平均が34.87%、帰属判定を外した条件では32.43%でした。評価中の記憶は固定し、タスク順を変えた3回の平均です。これは著者らの報告で、ここでは再現していません。
差は2.44パーセントポイントです。
この比較が、実装を考えるときの手掛かりになります。メモリを有効にした状態で、「経験をどこに帰属させるか」を外した条件を比べているからです。
自分のシステムでも、最初から巨大な記憶基盤を作る必要はありません。まず失敗ログを読み、同じ結果ラベルの中に、別々の修正が必要なケースが混じっているかを確認できます。
実際に混じっているなら、検索対象を増やす前に、保存前の判定を変える理由があります。
ただし、LLMが書いた原因説明を、検証済みの事実として扱うのは避けたいところです。先ほどの例なら、自然言語の「締切を守れなかった」という説明に加えて、比較演算の結果が残ります。再実行可能な条件はコードで確かめ、観測できていない原因は未確定として残す。その組み合わせのほうが、後から修正できます。
反省文だけを残すと、後で直せなくなる
ここから導ける実務上の提案は、教訓の文章と一緒に、出どころを保存することです。これはCHIMEの保存形式の転載ではなく、運用向けの追加案です。
{
"lesson_id": "deadline-rule-01",
"stage": "planning",
"claim": "厳密な締切では、等号を含めずに予定を検査する",
"evidence_trace_id": "delivery-example-01",
"applies_when": "完了条件が指定時刻より前である",
"status": "candidate"
}
evidence_trace_id は元の実行記録へ戻るための参照です。applies_when は、次のタスクでこの教訓が本当に使えるかを確かめる条件です。candidate は、生成された教訓をまだ有効な運用ルールにしていない状態を表します。
「期限を守ること」という一行だけなら、後で誤りに気づいても、どの実行から生まれ、どの条件を想定していたかが分かりません。出典となる記録があれば、計画の欠陥という判定自体を訂正できます。
保存する情報が変わると、確認すべきテストも変わります。
- 制約に違反した計画を、そのまま実行したケース。
- 正しい計画から実行が逸脱したケース。
- 問題のある計画を、実行担当が修正して成功したケース。
- 外部要因や記録不足で、原因を決められないケース。
この四つに、同じ教訓を保存していないかを見る。タスクの成功率だけを見るより、メモリ更新の不具合を具体的に探せます。
次のタスクへ渡す前に、修正先を決める
一件の失敗から作った規則が、次のタスクにも影響します。原因を取り違えた規則を次の計画に渡せば、正しかった判断まで変更させてしまいます。
だから、反省の文章量を増やす前に、失敗した一件を開いてください。
計画と実際の操作が別々に残っているか。条件違反はどの段階で入ったか。証拠が足りなければ、記憶を更新せずに止められるか。
CHIMEを読む価値は、経験を保存する直前に、その問いを置いた点にあります。
次のエージェントに渡したいのは、失敗の印象ではなく、どの判断をどう変えるかです。
参考資料
CHIME: Credit-Aware Hierarchical Memory Evolution for Long-Horizon Agentic Planning（2026年9月2日公開）
https://arxiv.org/abs/2609.02074
CHIME 本文・比較実験・ケース分析（v1）
https://arxiv.org/html/2609.02074v1
Marco DeepResearch — CHIMEの公開案内
https://github.com/ATH-MaaS/Marco-DeepResearch
Python datetime — Aware and Naive Objects
https://docs.python.org/3/library/datetime.html#aware-and-naive-objects