AIエージェントに教訓を蓄積させても、同じ失敗が減らないことがあります。自社の運用記録を機械的に数えたところ、蓄積した69件の学習のうち、必要な場面で呼び出される形をしていたのは3件でした。原因の所在と、記録の書式をどう変えるかを整理します。
蓄積量と失敗の減り方が比例しない
エージェントに作業させ、うまくいかなかったら学んだことをファイルに書き留める。次回からは同じ失敗をしない。この前提で運用設計をしている組織は少なくありません。
弊社も自社の業務基盤で同じことをしてきました。指示の訂正、判断の誤り、手順の抜け。そのつど一件一ファイルで書き溜め、索引を毎回エージェントに読ませる構成です。2026年8月14日時点で69件が溜まっていました。
そこで一度、量ではなく別のことを数えました。「この69件は、それが必要な場面で実際に効いているのか」です。
判定は単純にしました。各ファイルに「どの場面の直前で参照されるべきか」が書かれているか。書かれているなら、その場面で自動的に実行される仕組みへつながっているか。この2点だけを機械的に走査します。
69件のうち、参照されるべき場面を書いていたものが3件。そのうち有効な接続先を持っていたものが1件。残る2件は接続先の記述が不正な値でした。
66件は内容が間違っているわけではありません。読めば正しい。ただ、いつ読み返すのかを指定していませんでした。索引はセッションの開始時に一度読まれるだけで、実際に判断を誤る場面はその後に何度も訪れます。
記録の三類型と、止められない二つ
手続き的な学習の索引56行を、書かれ方で分類すると内訳が出ます。前段条件型が8件、禁止形が16件、事実メモ型が32件です。
禁止形は、その行動をしようとしている自覚があってはじめて機能します。ところが失敗は、まさに「これは禁止事項に当たる」と気づかない瞬間に起きます。事実メモ型に至っては、検索して読みに行かない限り出てきません。
つまり、56件のうち48件は正しい知識であって、必要な瞬間に自分を止める形にはなっていませんでした。
書き手の側で何が起きていたかというと、失敗の直後に「何が正しかったか」を書いています。そのとき書きたいのは正解であって、次にこれを思い出すべき瞬間の輪郭ではありません。振り返りの時点で自然に出てくる文体が、そのまま呼び出されない形になっていました。
想起の失敗ではなく、記述の失敗
ここで疑うべきは、モデル側の想起能力です。読ませているのに使わないのなら、長い文脈の中から関連情報を引き出す性能の問題ではないか、という筋があります。
この論点は研究側で測定されています。MemoryArena は、複数セッションにまたがって相互に依存するタスクでエージェントの記憶利用を評価する枠組みです。この研究が報告しているのは、LoCoMo のような既存の長文脈ベンチマークで良い成績を出すエージェントが、実際にタスクを進める設定では成績を落とすという結果でした。読んで答えられることと、その場面で行動を変えることは、別々に測る必要がある能力だという指摘です。
Agentic Context Engineering（ACE）は、蓄積した文脈の持ち方そのものを扱っています。この研究が名指しするのは brevity bias、つまり簡潔な要約へ圧縮する過程で領域固有の知見が落ちる現象と、反復的な書き直しによる context collapse です。処方は、項目単位で持ち、部分的な差分として更新することでした。
どちらも、蓄積した知識が使われない現象を扱っています。ただし両方とも、記録が「呼び出されうる形で書かれているか」という前段には踏み込んでいません。前提として、記録は既にそこにあるものとして扱われています。
自社の69件で起きていたのは、その前段でした。想起に失敗する以前に、想起されるべき瞬間が記述されていない。ここが分かると、対処は検索精度の改善ではなく、書式の変更になります。
Skill-Pro は、その分け方に近い区別を置いています。過去のやりとりそのものと、状況から行動へ直接対応づけられる手続きを分離し、後者だけを条件付きの実行可能なスキルへ変換する構成です。
書式で決め、機構へつなぐ
自社で採った対処は三層です。
第一層は、記述時に欄を必須化することです。 学習を書くとき、2つの欄を必ず埋めます。ひとつは「どの場面の直前で参照されるべきか」、もうひとつは「それをどの仕組みへつなぐか」。この2欄が埋まらないものは、そもそも手続きではないと判断し、知識として別の階層へ置きます。手続きの棚に知識が混ざることを止めるのが狙いです。
第二層は、場面の型から接続先を機械的に決めることです。 参照されるべき場面の型と、それを差し込める実行機構は一対一で対応します。対応表を先に決めておけば、配線のたびに考える必要がなくなります。
第三層は、呼び出しを計測することです。 フックとスキルの実行をログへ記録し、週次の点検で「直近30日間で一度も呼び出されていない学習」を一覧に出します。呼び出しがゼロのまま続く学習は、場面の書き方が間違っているか、そもそも手続きではありません。どちらであっても、書き直すか知識層へ移す対象になります。
書けたかどうかを数えている限り、この判定はできません。書いた件数は増え続け、効いているかは分からないままになります。
導入時のチェックリスト
自社の学習蓄積が同じ状態になっていないかは、次の順で確認できます。
- 蓄積した学習の総数を数える
- そのうち「どの場面の直前で参照されるべきか」を明記しているものの件数を数える
- 明記しているもののうち、自動実行される仕組みへつながっているものの件数を数える
- 3の数字が1や2に対して極端に小さいなら、問題は蓄積量ではなく記述の書式にある
- 既存分を一括で書き直さず、次に書く1件から新しい書式を適用する
- 呼び出しのログを取り始め、一定期間ゼロのものを定期的に洗い出す
5については補足があります。ACE が報告している context collapse は、全文の書き直しで起こる劣化です。蓄積済みの記録を一度に作り直すより、局所的な追記と修正で積み増すほうが安全側に倒れます。
未確認事項
本稿で示した69件・3件・1件という数字は、自社の一つの業務基盤における2026年8月14日時点の実測値です。組織や運用形態が変われば分布も変わります。
対処の効果については、まだ検証できていません。呼び出しログの記録を開始したのが2026年8月13日で、判定に足る期間が経過していないためです。「参照されるべき場面を明記してつないだ学習は、そうでない学習より実際に呼び出される割合が高いのか」は、4週間分のログが溜まった時点で確認する予定です。本稿は、原因の所在と対処の設計までを扱った段階の記録になります。