その記憶、本当に役に立ってる？ 自分の繰り返し業務で「記憶なし」と比べる小さな評価のやり方

AIエージェントに記憶を持たせた。なんとなく、前より良くなった気がする。

その「気がする」、確かめられますか？

ぼくは確かめ方を決めて、実際に回してみました。その記録を、自分でも試せる手順書にまとめたのがこの記事です。動くコードと生ログも付けています（experiment.zip）。

01先に結論

• 評価の基本は「同じ課題を、記憶なしと記憶ありで回して、課題ごとに見比べる」だけ。 平均の成功率を見るだけでなく、記憶で救われた課題と、かえって失敗した課題を別々に数えます。
• ぼくの実験（架空の経理業務、22課題×3回）では、履歴全量が100%（66/66）、記憶なしは36%（24/66）でした。 でも、これは履歴がたった約1,000トークンだからです。「全量が最強」とは言えません。
• 記憶の作り方で、結果が大きく割れました。 研究で使われていた経験抽出の依頼文をそのまま使うと59%。取引先ごとの現在条件を表に残す一文を足すと91%になりました。
• 検索は更新された条件を引き当てられませんでした。 「月島工業の9月分」という依頼だと、条件変更の連絡（新しい条件）ではなく、古い条件のログが上位に来ました。
• 悪化（記憶なしで成功→記憶ありで失敗）は、この実験では0件でした。 でも、それは「記憶は安全」という意味ではありません。ぼくの罠が弱かっただけの可能性が高いです。
• 記憶ありの失敗は、ほとんどが「空欄」でした。 41回のうち、誤った値を答えたのは5回だけです。
• 20課題の評価で「差がある」と言うには、思ったより大きな差が要ります。 救済5件・悪化3件では、差とは言えません。

02この記事の位置づけ

記憶の研究の全体像は記憶を持たせると次の仕事は上手くなる？で整理しました。逆効果になるパターンは記憶が逆効果になる5つのパターン、記憶の消し方・直し方は「忘れて」と頼んだのに、また出てくるのはなぜ？です。

今回はその先。「で、自分の仕事ではどうなの？」を、自分で確かめるところまでやります。

031. 何と何を比べるのか

比べる相手はいつも「記憶なし」です。記憶ありの方式どうしを比べる前に、まず記憶なしを基準に置きます。

見る数字は3つです。

なぜ、悪化も数えるのでしょうか？ その理由は研究でも示されています。MemDev-Bench（実リポジトリの履歴を使ったコード修正の評価）では、もともと解けない難しい133課題の成功率が、記憶なし35.3%→履歴全量39.6%→Claude-Mem 42.6%と上がりました。一方で、同じ論文の表には悪化（Harm）が4.8〜9.9%という条件も載っています。平均だけ見ていると、この悪化は見えません。

042. 今回の題材：架空の経理アシスタント

自分の業務を使うのが理想です。でも、今回は誰でも追試できるように、架空の題材を用意しました。

題材は「請求書の下書き業務」です。取引先ごとに、締め日、支払期限、宛先、PO番号（発注書の番号）の要否が違います。AIは、過去の作業ログを見ないと正解を知りようがありません。

• 過去ログH（20件）：取引先6社の条件、田代さん（経理担当という設定）の訂正、条件変更、一回限りの特例、無関係な雑談。
• 評価用T（22課題）：4つのグループに分けました。
• 調整用DEV（8課題）：Tとは別の月・言い回し。プロンプトや設定を直すのに使います。

評価用Tは、こんな4グループに分けました。

正解は取引先ごとのルール表（world.py）からコードで計算します。AIには見せません。

053. 手順

手順1：資料を3つに分ける

H（記憶の材料）、DEV（調整用）、T（評価用）。この3つを混ぜないのが、いちばん大事です。Tで見えた弱点をそのまま直して、同じTで再評価すると、それは「答えを見て直した」ことになります。

手順2：記憶の渡し方を条件にする

同じ材料（H）から、記憶の渡し方が違う6つの条件を作りました。

Nだけ特別扱いしないのが大事です。Nにだけ追加の制限（ツール禁止など）をつけると、記憶以外の差が混ざります。

手順3：実行環境を隔離して固定する

claude -p を使い、毎回、次の条件でモデルを呼び出しました。

claude -p --model claude-haiku-4-5-20251001 --output-format json \
  --tools "" --setting-sources "" --no-session-persistence \
  --system-prompt "あなたは経理アシスタントです。…"
# 空の一時フォルダで実行、CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

ツールなし、設定ファイルなし、自動メモリなし、空のフォルダ。メインのモデルはHaiku 4.5（各課題3回）。確認用にはSonnet 5.5（各課題1回）を使いました。実行順はシャッフルしました。

出力はJSONだけにして、分からない項目はnullにするよう頼みました。推測で埋めることを禁じたのは、捏造と未知の区別をつけるためです。

手順4：採点はコードで書く

成功は「4項目（締め日・支払期限・宛先・PO）がすべて正解」と決めました。

def field_ok(ans, g, f):
    if ans is None or f not in ans:
        return False
    if f == "send_to" and g[f] is not None:
        # 「仕入担当(山岸さん)」のような補足は許す。正解の部署名を含んでいればよい
        return isinstance(ans[f], str) and g[f] in ans[f]
    return ans[f] == g[f]

実はこの採点、最初は完全一致にしていました。パイロットを回したら、R（検索）やS（要約）が「仕入担当（山岸さん）」と答えたものが不正解になりました。記憶は合っているのに、採点する側が厳しすぎたんです。出力を何件か目で読んでいなかったら、「検索も要約も弱い」と誤解するところでした。採点コードを書いたら、必ず出力を数件、自分の目で読む。 直した採点ルールは全条件に同じように適用しています。

手順5：DEVで直して、固定して、Tを1回だけ回す

DEV（8課題×2回）では、Eが50%、F・R・Sは88〜100%でした（Nは38%）。Eの出力を読むと、すぐ理由が分かりました。

Eメモは「ミナト書店は『求められていない』のみで、不要と断定不可」「一件だけの事例を一般ルールとして確定しないでください」という依頼文に忠実でした。その結果、取引先ごとの具体的な条件がメモからほとんど落ちていたんです。モデルはメモに根拠がない項目をnullで返しました。慎重なのは悪くないけど、これでは仕事になりません。

そこで、取引先ごとの現在条件を表に残す一文を足し、E2を作りました。DEVで88%まで上がったことを確認してから、設定を固定しました。Tはそのあとで、1回だけ回しています。

正直に書いておくと、パイロット（Tの旧版）でEの弱さは先に見えていました。完全にまっさらな状態でDEVから直したわけではありません。

手順6：課題ごとに対応づけて読む

回数を増やしても、課題が増えたわけではありません。22課題×3回は独立した66種類の業務ではありません。だから「課題ごと」に見るんです。同じ課題で、Nと候補を比べます。

064. 結果

Haiku 4.5（22課題×3回、66実行/条件）

救済と悪化は22課題それぞれについて、成功率が半分以上なら「成功」とみなして数えました。費用はclaude -pが返す換算額（API単価換算）で、実際の請求額ではありません。

Nの36%は、見かけより高いです。グループDの「依頼文に条件が書いてある」6課題と、履歴にない新規取引先の2課題で、Nも正解できたからです。記憶が必要な課題（AとB）だけに絞ると、Nは0%です。これは、そういう課題を作ったので当然の結果です。記憶の力を示したわけではありません。

Sonnet 5.5（22課題×1回）でも、順位はほぼ同じ

1回しか回していないので、細かい差は読めません。それでも、Eだけ低く、E2でかなり成績が戻る傾向は同じでした。強いモデルにしても、記憶の作り方の差は消えませんでした。

075. 失敗の中身を読むと見えたこと

数字より、出力を読んで分かったことの方が役に立ちます。

① 検索は、更新を引き当てなかった

R（検索）は月島工業の9月分（t06）で3回とも失敗しました。依頼文は「月島工業の9月分の請求条件を教えてください」。検索で上位に来たのは、北斗食品の3月のログと、月島工業の3月・6月の古いログでした。条件変更の連絡（7月15日）は上位3件に入りませんでした。

古い条件には「20日締め」「総務部」とあるので、モデルは素直にそれを使い、締め日と宛先を間違えました。検索は「似ている文章」を持ってくるだけで、「新しい情報」を優先してくれません。

直し方はいくつか考えられます。取引先名で絞ったうえで、日付が新しいものを優先する。変更を表す文を別の台帳（現在の条件の表）に移す。ただし、ぼくはこれらの方法を試していません。

② 慎重すぎる記憶は、白紙の答えを増やす

Eの失敗27回のうち15回は、4項目すべてをnullで返した回答でした（5課題）。間違えたのではなく、メモに根拠がないから答えなかったのです。「推測するな」は大事ですが、現在の条件を知っているのに残さなかったら、記憶の意味がありません。

抽出の依頼文は「何を残すか」を決める設計書です。自分の業務で何を事実として残したいのか、先に決めておく必要があります。

③ 要約は、細部と過去の値を落とす

E2は更新ありの課題（B）で60%でした。月島工業の9月分・10月分で、PO番号の要否がnullになりました。経験メモの表に、更新後のPO要否が「記載なし」と書かれたからです。

ただ、ここは正解の決め方にも議論の余地があります。更新の連絡（h15）にはPOの話がなく、以前は不要という記録だけがある。ぼくは正解表で「引き続き不要」としましたが、nullと答える方が慎重とも言えます。履歴全量のFは前の記録から「不要」と推測し、正解になりました。

Sも青葉運輸の7月分の再発行（過去時点の条件）で、3回とも失敗しました。要約は「現在の条件」を中心に書くので、過去の時点の値が落ちやすいです。

④ 失敗のほとんどは「空欄」。間違った値は5回だけ

記憶ありの条件では、全部で41回失敗しました。そのうち、誤った値を答えたのは5回だけです。Rの月島工業9月分の3回（古い条件を使った）と、EがPOの要否を間違えた2回。残りの36回はnull（分からない）か、一部の項目が空欄でした。

今回の「推測するな、分からなければnull」という指示が効いたのかもしれません。この指示がなければ、空欄の代わりに誤った値が増えた可能性があります。確かめてはいません。

⑤ 悪化は0件。でも、安心材料にはならない

全条件で、悪化は0件でした。理由は2つ考えられます。

1. 課題が易しい。履歴が短く、取引先6社だけで、混乱の余地が少ない。
2. ぼくの罠が弱い。一回限りの特例や別会社の罠は、Haikuでも全条件で引っかからなかった。

MERITという研究では、難しい段階で、正しい値が検索結果にあった55エピソードのうち、モデルが行動に使ったのは30件でした。使わない、あるいは使い間違えることは、現実に起きます。0件だったからといって、自分の業務で悪化がないとは言えません。 悪化の罠をもっと入れるのは、次の課題です。

086. 20課題で、何が言えるのか

「14件成功したEと、12件のN。Eの勝ち」と言いたくなりますよね。でも、課題が20件だと、差が偶然で出る範囲が思ったより広いです。

差があるかの目安です。課題ごとに対応づけて、「候補だけ成功」と「基準だけ成功」の食い違い（n件）を見ます。そのうち、片側に何件偏れば偶然とは言いにくくなるのでしょうか？ 厳密な符号検定（片側に偏る確率を、二項分布で計算したもの。両側、p＜0.05）で出しました。

具体例です。

• 救済5件・悪化3件：p＝0.73。差とは言えない。
• 救済7件・悪化2件：p＝0.18。まだ言えない。
• 救済8件・悪化1件：p＝0.039。言える。

ぼくの実験でも、同じ見方をしてみます。FとRは「Fだけ成功」が2課題（t06とt07）、逆はなし。p＝0.5です。Fの方が良さそうに見えても、この件数では「FとRに差がある」とは言えません。 一方、N→Fは14件の救済で悪化0件。これは偶然ではなさそうです（p＜0.001）。

成功率そのものの幅も見ておきましょう。12/20のWilson信頼区間は約39〜78%、14/20は約48〜85%。ほとんど重なります。

結論として、20件の比較でできることは、「基準より明らかに良い」「明らかに悪い」を拾うことと、候補を絞ることです。僅差の順位づけは課題を増やすか、別の時期に取り直してからです。

097. 自分のツールで「記憶なし」を作る方法

比較するときは、記憶をオフにした実行（N）を、自分のツールでどう作るかが最初の壁です。公式ドキュメントで確認した方法をまとめます（2026年10月22日時点）。

記憶を作る側（H）と評価する側（T）の取り違えにも注意してください。記憶をオンにした通常チャットで試すと、評価の会話からも記憶が作られることがあるので、次の評価に影響するかもしれません。一時チャットは記憶を作らないので、評価向きです。

108. 費用の読み方

今回の費用はほとんど出力トークンで決まっていました。履歴が約1,000トークンしかないので、記憶を足しても入力はあまり増えず、条件ごとの1回あたり費用は$0.0048〜$0.0070の範囲に収まりました。

記憶を作る費用は別です（Sonnet 5.5、1回）。

ここで見るべきは「今回の金額」ではなく、どこに何の費用が入っているかです。

• 記憶の作成費を毎回全額で載せるのか、N回の利用で割るのか。
• 履歴が増えたとき、Fの入力トークンは履歴に比例して増える。ぼくの実験はそこまで行っていません。
• キャッシュが効いた再実行は、初回より安くなる。

MemDev-Benchでは、手数は減ったのに入力トークンは増えた条件がありました。改善対象のRepo history条件で、記憶なしの平均入力6.45Mトークンに対し、履歴全量は32.86Mです。手数が減ったからといって、費用が減るとは限りません。

119. この実験でわかっていないこと

• 架空の世界1つ、モデルはHaiku 4.5が中心です。 現実の業務の代表ではありません。
• 履歴が約1,000トークンしかありません。 Fが全部入るので、F・R・Sの優劣は何も言えません。履歴が増えたときの差を見るには、別の実験が要ります。
• 記憶を作ったのは強いモデル（Sonnet 5.5）です。 S・E・E2の成績は作る側の腕前に左右されます。
• 課題はぼくが作りました。 「E2を作ったらB群で60%にとどまる」といった結果は、課題の作り方で変わります。
• E2はパイロットでEの弱点を見たあとに作りました。 DEVで直したものの、純粋な未見の評価ではありません。
• 悪化の罠が弱く、悪化が0件でした。 悪化の少なさは主張しません。
• 費用はCLIが返す換算額で、実請求ではありません。 実行環境の補助モデルの利用も少し混ざっています。
• 時間は共有のMacで5並列で回した粗い値です。 比較には使いません。

1210. 明日からのチェックリスト

1. 繰り返しがあって、成功を機械的に判定できる業務を1つ選ぶ。
2. 過去の完了済み10〜20件（H）、調整用5〜10件（DEV）、評価用20件前後（T）に分ける。Tには「更新あり」「似ているが別」「記憶不要」も混ぜる。
3. 正解と採点コードを、AIに見せずに作る。採点が厳しすぎないか、出力を数件読んで確認する。
4. N（記憶なし）を、自分のツールで作れるか確認する。
5. 条件ごとに、同じモデル・同じ設定で、課題ごとに複数回回す。
6. 救済、悪化、費用、時間を別々に数える。悪化した課題は必ず出力を読む。
7. 採否の基準を、結果を見る前に書いておく。「成功率を下げずに費用か手間が減る」「重要な例外で悪化させない」など。
8. 差が小さければ「分からない」と書く。それも立派な結論です。
9. よさそうなら、別の時期の課題で取り直す。

この記事のコードはworld.pyの課題と正解を自分の業務に差し替えれば、そのまま動きます。手順はREADMEに書きました。

13まとめ

「記憶を入れたら良くなった気がする」は、記憶なしと並べて、課題ごとに数えれば確かめられます。

ぼくの小さな実験では、記憶なしと比べて履歴全量・要約・検索は大きく効き、経験抽出は依頼文の書き方で59%にも91%にもなりました。そして、検索は更新を取りこぼしました。平均の成功率だけではどれも見えなかったことです。

あなたの業務ではどうでしょうか？ まず10課題×2条件（記憶なしと、いちばん単純な候補）から、試してみてください。

14参考にした原典

• Chenほか, MemDev-Bench, arXiv:2610.27524v1（Table 2/3の数値を原表で照合）
• Mishra & Mishra, MERIT, arXiv:2609.05441v1（§5.4。難しい段階の55件中30件）
• Claude Code, Memory
• OpenAI, Memory FAQ
• 実験コードと生ログ：experiment.zip