2026.10.17 / Agent Memories

プロダクト改善で効くAI記憶の出典管理｜続きから動ける運用設計

「検索を改善してほしい」という要望が三件あったとしても、三人が同じ不便を感じているとは限りません。ある人は古い回答が出ること、別の人は見つからないこと、もう一人は待ち時間を問題にしています。AIに要望を要約させるだけでは、この違いが消え、後から優先順位の根拠を説明できなくなります。

ここではプロダクト改善に使う記憶の出典を、要望の受付から改善後の評価までつなぐ方法を考えます。一般的な参考文献の整理ではなく、どの観測がどの仮説を支え、どの変更につながったかを追うことに範囲を絞ります。

要望の言葉と困った場面を別々に残す

最初に保存したいのは、解決策の名前ではなく利用状況です。問い合わせ番号、利用した画面、実行した操作、期待した結果、実際の結果を分けます。「絞り込みを追加して」という文言は提案欄へ置き、困り方の欄には「顧客名を入れても別案件の資料が先に出る」と書きます。

原文を残す必要がある場合も、氏名や顧客の事情を広く検索できる改善メモへコピーしません。閲覧を制限した受付記録への参照と、匿名化した要点を分ければ、開発担当が内容を把握するために個人情報まで受け取らずに済みます。

件数を数える前に一件の単位を決める

同じ人がメール、フォーム、チャットから連絡すると、記録上は三件でも困っている人は一人です。受付経路の数と利用者の数を混ぜないよう、重複の疑いを記す欄を用意します。統合するときも原記録の番号を消さず、集計対象から外した理由を残します。

社内の推測も顧客の発言とは区別します。「売上に影響しているはず」は仮説であり、売上減少を観測した証拠ではありません。商談失注との関係を確かめていないなら、影響未確認と書いた方が判断の土台は強くなります。

改善仮説には支える証拠と反対の証拠を付ける

たとえば「更新日の表示を追加すれば古い資料の選択が減る」という仮説には、旧資料を誤選択した事例を結びます。一方で、更新日が見えていても選び間違えた事例があれば反証として添えます。都合のよい報告だけを検索対象にすると、AIは同じ施策を繰り返し勧めやすくなります。

証拠の種類には、利用者の申告、操作ログ、担当者の再現、外部仕様を使えます。ただし強さを一律に決める必要はありません。申告から体験のつらさは分かっても原因は確定せず、ログから操作順は分かっても動機は読み取れない、と支えられる範囲を説明します。

採用判断から変更内容への橋をかける

改善案を選んだら、決定日、選んだ人、対象機能、採用理由、今回は扱わない要望を一枚にまとめます。判断の材料が更新された場合は、元の記録へ無言で上書きせず、再判断した日と条件を追加します。過去の意思決定を現在の仕様として誤用しないためです。

変更の識別子を仮説へ結び、リリース後の問い合わせを同じ仮説へ戻せるようにします。要望、判断、変更、評価が別々の場所にあっても参照がつながっていれば、AIに履歴全量を読み込ませる必要はありません。

効果の評価で時期と対象者をそろえる

問い合わせが減っただけでは成功とは言えません。利用者そのものが減った可能性や、問い合わせ窓口を変更した影響もあります。変更前後で対象人数、機能の利用回数、受付経路を併記し、比較できない条件があればそのまま示します。

架空の検証例として、旧資料の誤選択を一週間の利用回数で割って比較するとします。これは測定設計の例で、改善率を保証する数値ではありません。件数が少ない段階では、割合だけでなく個々の再現結果と残った困り方も読む方が実態をつかめます。

資料が消えたときは結論も見直す

受付記録が保持期限を迎えて消える場合、参照先の不存在を新しい事実で埋めないようにします。集計が再検証できなくなったこと、残せる匿名化情報、再調査の必要性を明記します。消えた原文をAIがもっともらしく再構成しても、元の証拠の代わりにはなりません。

運用の点検は一つの改善案件から始められます。受付番号から採用理由へ到達できるか、採用理由から変更を特定できるか、変更後の観測が元の仮説を評価しているかを確認します。ひとつでも切れていれば、記事のような長い説明を増やす前に参照を直します。

出典管理についての質問

AIの要約をそのまま証拠にしてよいですか？

要約は探すための入口です。意味が変わっていないか原記録と照合し、原文への参照と要約した時点を残します。確認できなければ未照合の要約として扱います。

すべての要望を実装する必要がありますか？

ありません。対象外とした理由や再検討する条件も重要な改善記憶です。見送った要望を削ってしまうと、同じ話が出るたび判断がやり直しになります。

出典があるなら改善の成功は保証されますか？

出典は判断を検証しやすくするもので、因果関係を保証しません。機能の採否は費用、利用者への影響、組織の責任範囲を含めて人が決めます。

根拠として使った資料と適用範囲

OpenClawの公式Memory文書では、記憶をワークスペース内のMarkdownファイルへ保存し、長期的な事実・決定と日次の作業記録を区別しています。これは同製品の説明であり、すべてのAIサービスの保存方式を示すものではありません。

W3C PROV-OはEntity・Activity・Agentと、生成・利用・派生・帰属などの関係を表す語彙です。記録の来歴を考える参考にはなりますが、情報の正しさや実行権限を自動で保証する規格ではありません。NIST AI RMF 1.0のGovern・Map・Measure・Manageはリスク整理の枠組みで、現在は改訂作業も案内されています。本稿の具体的な運用例は編集部の提案であり、各文書の必須手順や製品機能とは区別してください。