2026.09.01 / Agent Memories

小さなチームで効くAI記憶の判断ログ｜続きから動ける運用設計

三人のチームで一番消えやすいのは、会議の結論ではありません。「なぜ今回はその案を選んだのか」という判断の筋道です。納期を優先したのか、顧客への影響を小さくしたのか、費用上限を守ったのか。理由が残っていないと、翌週のAIは却下済みの提案を新案のように出し、人はまた一から説明することになります。

判断ログは議事録の短縮版ではなく、次の選択を速くする記憶です。小さなチームほど、専任の記録係を置かずに続けられる形へ絞る必要があります。ここでは、採用・保留・却下を混ぜず、条件が変わった時だけ見直せる実務設計を組み立てます。

結論だけのメモが再利用できない理由

「A案で進める」とだけ書かれた記録には、有効範囲がありません。別の商品、別の予算、別の公開先でもA案が正しいように見えてしまいます。AIは空白を好意的に補完するため、過去の結論を広げすぎることがあります。そこで結論の隣に、比較対象、優先した条件、避けた損失、失効条件を置きます。

たとえば「初回は手動確認を残す。理由は顧客通知の重複を避けるため。重複防止の仕組みが実画面で確認できたら再検討」と書けば、次回は同じ議論を繰り返さず、失効条件を満たしたかだけを調べられます。判断の価値は文章量ではなく、再判断の入口が明確かどうかで決まります。

一件の判断を六つの欄に分ける

小さなチーム向けには、案件名、状態、決定内容、根拠、適用範囲、見直し条件の六欄で十分です。状態は「採用」「保留」「却下」を固定語にし、保留には不足情報、却下には再提案できる条件を添えます。決定者と決定日は根拠欄へ押し込まず、誰に確認すべきかが一目で分かる位置へ置きます。

• 案件名は検索しやすい名詞で付け、会議名だけにしない
• 適用範囲には対象商品、媒体、期間、金額などを記す
• 見直し条件は「いつか」ではなく、数値や出来事で表す
• 未承認の会話を正式決定へ自動昇格させない

この形なら、AIへの指示も「採用だけ読んで」ではなく、「現在も有効で、対象範囲が一致する採用判断だけ使って」と具体化できます。

採用・保留・却下を別の資産として扱う

却下案は失敗物ではありません。却下理由が残れば、同じ案の言い換えが戻ってくるのを防げます。一方、保留は判断不能のまま放置する箱ではなく、次に集める証拠を指定する待機列です。三つの状態を一つの時系列メモに混ぜると、最後に書かれた文だけが現在方針として検索されやすくなります。

状態が変わった時は古い行を消すのではなく、「2026年8月、条件Xの成立により保留から採用へ」とつなぎます。W3CのPROV-Oは、情報の由来をEntity・Activity・Agentなどの関係で表せる語彙を示しています。小規模運用で完全なオントロジーを実装する必要はありませんが、「どの判断が、どの確認作業と決定者から生まれたか」を結ぶ考え方は有効です。

AIが読む正本と日々のメモを分離する

チャットや日報をすべて長期記憶へ入れると、決定前の案まで同じ強さで検索されます。日々の検討は作業ログへ、確定した判断はCurrentや判断台帳へ移し、作業ログから正本への参照を残します。OpenClawのMemory overviewも、長期の要点を置くMEMORY.mdと、詳細な日次ノートを役割分担する構成を説明しています。

重要なのは、ファイルを分けただけで安心しないことです。正本にはOwner、更新日時、対象範囲を持たせ、旧版には置き換え先を示します。正本候補が二つ見つかった場合は更新日の新しい方を勝手に採用せず、競合として人へ返します。正しい判断ログは、AIの自信を増やすのではなく、迷うべき場所を明確にします。

週15分のレビューで効く記憶に育てる

毎週すべてを読み直す必要はありません。期限が来た判断、参照回数が多い判断、同じ提案が再登場した判断だけを抽出します。レビューでは文章の美しさより、範囲の欠落、相反する現行判断、失効条件の成立を探します。古くなった判断は削除一択ではなく、履歴へ移し、現行検索から外します。

効果測定にはログ件数を使いません。「同じ説明を何回繰り返したか」「却下済み案が再提案されたか」「新担当が決定者へたどり着くまで何分かかったか」を見ます。詳しいレビュー方法はAI記憶の棚卸しルーティン、正本の考え方はAIに正本を教える方法にもつながります。

リスク管理の枠組みへ判断ログを接続する

NIST AI RMFは、AIリスクを扱うための自発的な枠組みです。本記事が根拠として参照する版は2023年公開のAI RMF 1.0であり、NISTは現在その1.0を改訂中と案内しています。したがって将来版の要求事項を先取りしたとは扱わず、公開中の1.0と自社の決定記録を明示的に区別します。

実務では、判断ログを「責任逃れの証拠」にせず、リスクを誰が把握し、どの条件で受容・低減・停止したかを追える道具にします。重大な変更には観測項目と戻し方を添え、軽微な判断には六欄だけを使う。リスクの大きさに応じて記録密度を変えることで、小さなチームでも継続できます。

具体例として、新しい生成ツールの採用を考えます。「速いので採用」ではなく、無料枠内の試作だけ許可、顧客データは入力しない、公開は人が確認、費用が発生する段階で再承認、と範囲を記します。翌月に料金体系が変われば採用結論を使い回さず、費用条件だけを再審査できます。反対に画質の比較結果が変わっていなければ、その検証を最初からやり直す必要はありません。

決定者が不在の時も、ログから承認を推測してはいけません。期限内に代行できる役割、保留中に進められるlocal作業、公開や購入の停止線をあらかじめ書きます。これにより一人の不在で全工程を止めず、権限が必要な一手だけを安全に待てます。代行判断を行った場合は、元のOwnerが戻った時の確認期限も記録します。未確認のまま恒久方針には昇格させません。

よくある質問

チャット履歴があれば判断ログは不要ですか？

不要にはなりません。チャットには検討中の案、冗談、未承認の返答も混ざります。判断ログは確定状態と適用範囲を抽出した正本です。履歴は根拠を詳しくたどる時の補助として残し、日常のAIには現行判断を先に読ませます。違いは記憶とチャット履歴の整理でも確認できます。

却下理由はどこまで詳しく書けばよいですか？

同じ提案を次回ふるい落とせる粒度が目安です。「良くない」ではなく、「月額費用が上限を超える」「公開後の取消ができない」のように条件で書きます。人格評価や感情的な表現は残さず、再提案を許すなら解除条件も記載します。

ログが増えすぎたら削除してよいですか？

現行検索から外すことと、証跡を消すことを分けます。失効済みは履歴へ移し、現行台帳には最新判断と置き換え先だけを残します。法令、契約、監査上の保存期間がある情報は独自判断で消さず、組織の保持方針へ従ってください。

明日から始める最小単位

まず直近の重要判断を一件だけ選び、六欄へ書き直します。その後、別の担当者かAIに「この判断が使える条件と、使ってはいけない条件」を答えさせます。答えが割れた箇所だけ補えば、最初から完璧な台帳を設計する必要はありません。判断ログは過去を保存する箱ではなく、次の会話を短くし、必要な時だけ人へ戻すための操縦面です。