AIが「同じミスを繰り返す」アーキテクチャ的要因：検索と学習の混同を解く

AIコーディングアシスタントがセッションをまたいで同じミスを繰り返す現象は、多くのチームで「プロンプトの指示が不足している」として扱われがちである。しかし、根本的な原因はメモリ層の設計にある。記憶の保存は学習とは異なり、修正を書き込んでも古い誤った記憶が検索対象から除外されるわけではない（DEVの解説記事）。つまり、正解データを追加しても、誤ったエントリがインデックスに残り続け、クエリ時に両方が検索結果として混在する。

この問題の本質は、RAG（Retrieval-Augmented Generation）パイプラインにおける「検索」の性質にある。ベクトル検索は類似度に基づいて上位N件を返すが、類似度スコアが同一範囲に収まる正解と誤答を区別する仕組みが標準では存在しない。コンテキスト窓に矛盾した情報が同時に収まると、LLMはどちらを優先すべきか判断に迷い、結果として誤ったパターンの再発が固定化される。

解決には、単なる記憶の蓄積ではなく、フィードバックによる関連性の再評価や忘却メカニズムをアーキテクチャレベルで設計する必要がある。具体的には、ユーザーの修正意図を検索結果のランキングに反映する「動的な重み調整」を行うことで、誤った情報の検索順位を下げ、正解が優先的にコンテキストに載る状態を作ることが求められる。

flowchart TD
    A["クエリ送信"] --> B["ベクトル検索"]
    B --> C{"フィードバック適用済み？"}
    C -->|"否（従来）"| D["正解と古い誤情報が混在"]
    D --> E["LLMが矛盾したコンテキストで生成"]
    C -->|"是（改善後）"| F["関連性調整済み結果"]
    F --> G["LLMが一貫したコンテキストで生成"]

フィードバック機能の実装状況：主要AIメモリツールの比較分析

「ユーザーの修正意図をどうシステム内部の状態遷移に反映させるか」という点で、主要なAIメモリツールには明確な設計差がある。以下、公開ドキュメントに基づいて各ツールの実装状況を整理する。

Cogneeは、add_feedbackメソッドでフィードバックを受け取り、improve()を実行することで将来の検索結果に影響を与える、という明確なAPIを提供している（DEVの解説記事）。開発者が「いつ・何を・どう」改善するかを意図的に制御できる点が特徴である。

Mnemoverseは、-1.0から+1.0の浮動小数点数で結果フィードバックを受け取り、将来の検索順序を調整する（Mnemoverseの公式ドキュメント）。連続値による粒度の細かな評価が可能な点は、二値型のフィードバックとは設計思想が異なる。

一方、Mem0はPOST /v1/feedback/エンドポイントでPOSITIVEやNEGATIVEなどの値を受け取るが、ランキングへの具体的な影響については明記されていない（DEVの解説記事）。Zepの公開ドキュメントには、検索結果に対する否定的な判断を入力する機能自体が記載されていない。

ツールフィードバック入力形式検索結果への影響の明記
Cogneeadd_feedback + improve()あり（将来の検索に影響）
Mnemoverse-1.0〜+1.0の浮動小数点あり（検索順序を調整）
Mem0POSITIVE / NEGATIVE（POST）明記なし
Zep公開ドキュメントに記載なし不明

この表から読み取れるのは、「フィードバックを受け取るAPIが存在する」ことと「そのフィードバックが検索結果に実際に反映される」ことは別の設計判断である、という点である。導入前に後者の確認を怠ると、フィードバックを送信しても検索結果が変わらず、固定ミスが解消されない状態に陥る。

Mnemoverseの設計思想：ヒッビアンの連想とRescorla-Wagnerモデル

Mnemoverseが採用する記憶更新の理論的基盤は、ヒッビアンの連想理論とRescorla-Wagnerモデルの組み合わせである（Mnemoverse公式サイト）。ヒッビアンの連想は「同時に活性化された概念同士が相互に強化される」という原理であり、コードベースの文脈では、特定の関数呼び出しとエラーパターンが繰り返し共起するほど、その結合が強化されることを意味する。

Rescorla-Wagnerモデルは、予測誤差に基づいて結合の重みを更新する学習則である。一般的な形式では、重みの変化量が「期待された結果」と「実際の結果」の差に比例する。Mnemoverseでは、ユーザーが-1.0から+1.0の範囲でフィードバックを与えると、関連する記憶ノードの重要度がこのモデルに従って調整される。例えば、あるコードパターンに対して-0.8のフィードバックが与えられると、そのパターンに関連する記憶ノードの重みが低下し、将来の検索でその情報が優先されにくくなる。

このアプローチの利点は、単なるキーワードマッチングを超えた「文脈に応じた適応」を可能にすることである。同じ関数名でも、異なるモジュールや異なる呼び出し文脈では重みが独立に調整されるため、大規模なコードベースで一貫性を維持しやすい。

ただし、重要な制約として、Mnemoverseのエンジン内部はクローズドであり、フィードバックが具体的にどのように動作するかは公開されていない（Mnemoverseの公式ドキュメント）。Rescorla-Wagnerモデルを用いると公式には述べているが、学習率パラメータや忘却係数などの具体的な値は確認できない。これは、動作が期待通りでない場合のデバッグが困難になるという実務上のリスクである。品質保証の観点では、LoCoMoやLongMemEvalなどの公開ベンチマークで評価されており、その数値はコミットされた実行アーティファクトに追跡可能であるという点（Mnemoverse公式サイト）が、ブラックボックス性をある程度補う根拠となる。

他のツールの限界：Mem0, Zep, Lettaのフィードバック機能の実態

Mnemoverseの設計思想を確認した上で、残りの主要ツールが「固定ミスの再発防止」に対してどのような機能を提供しているかを整理する。結論から言えば、いずれのツールもフィードバックの受け入れ自体は実装しているが、それが検索結果のランキングや記憶の重みにどう反映されるかという点で、公開情報が不十分である。

Mem0：受け入れは可能だが影響が不透明

Mem0はPOST /v1/feedback/エンドポイントでPOSITIVEやNEGATIVEなどの値を受け取る（DEVの解説記事）。つまり、ユーザーが「この提案は間違っていた」と判断した場合、その判断をシステムに伝える経路は存在する。しかし、このフィードバックが将来の検索結果の順序や関連性スコアに具体的にどのように影響を与えるのかについては、公開ドキュメントに明記されていない。

実務上の含意は明確である。フィードバックを送信しても、次回以降の検索で同じ誤った記憶がトップに表示される可能性を排除できない。つまり、「送信した＝修正された」ではなく、「送信した＝修正されたかもしれない」という状態であり、品質保証の観点では不十分である。

Zep：否定的判断の入力経路自体が不明

Zepの公開ドキュメントには、検索結果に対する否定的な判断を入力する機能は記載されていない（DEVの解説記事）。Mem0が「受け取れるが影響が不明」であるのに対し、Zepは「受け取れるかどうかも不明」という段階である。セッション管理やコンテキストの保持には優れた機能を持つが、「ミスの修正を記憶に反映する」という用途に対しては、現時点では設計上の前提を置くことができない。

Letta：フィードバックの対象が異なる

Lettaのフィードバック機能は、エージェントの実行ステップに対するものである（DEVの解説記事）。つまり、エージェントが「この関数を呼ぶべきだった」という実行レベルの判断に対するフィードバックであり、検索結果の順序変更や記憶ノードの重み付けには直接関連付けられていない。Lettaはエージェントの行動制御に焦点を当てた設計であり、メモリ層の検索品質を改善する目的には本来の用途とズレがある。

これらのツールは、短期的なセッション管理やコンテキストの保持には優れている。しかし、「一度修正したミスを二度と繰り返させない」という長期的な記憶の品質管理に対しては、明示的なメカニズムを提供していない。このギャップを埋めるのが、次のセクションで詳述するMnemoverseやCogneeのアプローチである。

実装パターン1：Mnemoverseを用いた動的記憶層の構築

Mnemoverseは、Claude Code、Cursor、VS Code、ChatGPTなど6つのクライアント統合をAPIキーまたはOAuthでサポートしている（Mnemoverse公式サイト）。導入時にカスタムインテグレーションを開発する必要が少なく、既存のIDE環境にそのまま組み込める点が実務上の利点である。

コスト面では、無料プランが1日1,000クエリまで無制限で利用でき、クレジットカードは不要である（Mnemoverse公式サイト）。小規模チームでのPoCや、本番導入前の動作確認には十分である。1日1,000クエリという上限は、1人あたり1日数十回のコーディングセッションを想定すると、5〜10人規模のチームで1ヶ月程度の実証実験が可能という計算になる。

実装のポイントは、ユーザーがコードを修正した瞬間にフィードバックをMnemoverseへ送信するフローを構築することである。Mnemoverseは-1.0から+1.0の浮動小数点数で結果フィードバックを受け取り、将来の検索順序を調整する（Mnemoverseの公式ドキュメント）。つまり、修正の「度合い」を連続値として表現できるため、軽微な修正と根本的な設計変更を区別して記憶に反映できる。

具体的には、IDEの差分（diff）を検出するフックにフィードバック送信処理を組み合わせる。ユーザーがAIの提案をそのまま採用した場合に+1.0、部分的に修正した場合に0.0〜0.5の間の値、完全に書き換えた場合に-1.0を送信する。この閾値の設計はチームのコーディング規約に合わせて調整する必要があるが、初期値として上記の範囲から始めるのが合理的である。

sequenceDiagram
    participant IDE as IDE（Cursor等）
    participant Hook as 差分検出フック
    participant API as Mnemoverse API
    participant Mem as 記憶層
    participant Next as 次回セッション
    IDE->>Hook: ユーザーがコードを修正
    Hook->>API: POST フィードバック（-1.0〜+1.0）
    API->>Mem: 記憶ノードの重み更新
    Note over Mem: Rescorla-Wagnerモデルによる
重要度再計算
    Next->>API: 検索クエリ送信
    API->>Mem: 重み調整後の検索
    Mem-->>API: 修正済みの情報優先
    API-->>Next: 検索結果返却

このシーケンスの重要点は、フィードバック送信と記憶更新が同期的に行われることである。非同期にすると、ユーザーが次のセッションを開始した時点でまだ重み更新が完了していない可能性があり、固定ミスが再発する。実装時は、APIのレスポンスを確認してから次のアクションに進むよう制御する。

実装パターン2：Cogneeを用いた明示的な改善ループの実装

Cogneeはフィードバックを受け取り、内部の記憶を更新する仕組みを提供している（DEVの解説記事参照）。Mnemoverseとの決定的な違いは、フィードバックの「蓄積」と「適用」が独立した操作として設計されている点にある。これにより、開発者はいつ改善を適用するかを明示的に制御できる。

この設計の利点は、バッチ処理との親和性が高い点にある。例えば、チームが1週間分のフィードバックを蓄積してから、金曜日の定時でまとめて実行する、という運用が可能になる。リアルタイムに反映するMnemoverseのアプローチと比べると、個別のフィードバックの反映が遅くなるが、その分、ノイズのフィルタリングやフィードバックの検証を挟む余裕が生まれる。

実装のフローは以下の通りである。ユーザーがAIの提案を修正した場合、その修正内容（差分）と修正理由（任意のテキスト）を送信する。次に、一定期間が経過したか、あるいはフィードバック数が閾値を超えた時点で改善処理を呼び出す。このとき、Cogneeは蓄積されたフィードバックを解析し、関連する記憶ノードの重みを調整する。

flowchart TD
    A["ユーザーがコードを修正"] --> B["差分と修正理由を抽出"]
    B --> C["フィードバックを送信"]
    C --> D{"フィードバック数が
閾値を超えたか"}
    D -->|否| E["蓄積を継続"]
    E --> C
    D -->|是| F["改善処理を実行"]
    F --> G["記憶ノードの重み調整"]
    G --> H["次回以降の検索結果が改善"]

ここで設計判断が分かれるのは、改善処理のトリガー条件の設計である。タイムベース（例：毎週金曜）にするか、カウントベース（例：50件蓄積したら）にするか、あるいはその組み合わせにするか。タイムベースは運用が単純だが、フィードバックが少ない週には改善が滞る。カウントベースは改善の頻度が安定するが、ピーク時に大量のフィードバックが集中すると処理時間が長くなる可能性がある。チームのフィードバック発生頻度を1〜2週間観察してから、閾値を決定するのが実務的に安全である。

MnemoverseとCogneeの選択基準を整理すると、リアルタイム性の重視度が高い場合はMnemoverse、改善の検証と制御を重視する場合はCogneeが適している。次のセクションでは、この2つのアプローチのトレードオフをさらに掘り下げる。

設計判断：ブラックボックス型と透明性型のトレードオフ

前節で触れた2つのアプローチを、設計判断の観点から整理する。Mnemoverseはフィードバックを受け取り、ヒッビアンの連想とRescorla-Wagnerモデルに基づいて記憶の重要度を自動的に更新する(Mnemoverse公式ドキュメント)。一方、Cogneeはフィードバックを明示的に受け取り、改善処理を実行することで検索結果への影響を確定させる(DEVの解説記事)。

この差分が設計判断に与える影響は、大きく分けて3点ある。第一に、デバッグのしやすさ。Mnemoverseのエンジン内部はクローズドであり、フィードバックが具体的にどのように記憶の重みに反映されるかは公開されていない(Mnemoverse公式ドキュメント)。検索結果が期待と異なる場合、原因の切り分けが困難になる。Cogneeであれば改善処理実行前後の検索結果を比較することで、改善が効いているか直接確認できる。

第二に、導入コストと制御性のトレードオフ。MnemoverseはClaude Code、Cursor、VS Code、ChatGPTなど複数のクライアントをAPIキーまたはOAuthで統合しており(Mnemoverse公式サイト)、APIキーを設定するだけで動作が始まる。Cogneeは改善処理のトリガー条件（頻度・閾値）を自前で設計する必要があり、初期設定の手間が大きい。

第三に、スケーラビリティ。大規模なコードベースで数百のファイルにまたがるコンテキストを扱う場合、Mnemoverseの自動的な重要度調整は手動チューニングを不要にする。一方、小規模なプロジェクトでは、開発者が記憶の内容を把握しやすいCogneeの透明性が、意図しない行動の早期発見に有効である。

観点Mnemoverse（ブラックボックス型）Cognee（透明性型）
フィードバック入力形式数値による評価明示的な送信
内部動作の可視性クローズド・非公開改善前後を比較可能
導入の手間APIキー設定で即接続トリガー条件の設計が必要
制御性低（自動調整に委ねる）高（トリガーを自前で設計）
向いている場面大規模コードベース・即時反映小〜中規模・改善の検証重視

実務的な判断基準として、チームに「なぜこの検索結果になったのか」を説明する責任がある（例：コンプライアンス対応、コードレビューの根拠提示）場合は、透明性型のCogneeを優先すべきである。逆に、プロダクション環境での即時反映を重視し、アルゴリズムの内部をブラックボックスとして許容できる場合はMnemoverseが現実的である。

運用フロー：フィードバックの収集から記憶の更新までのワークフロー

メモリ層のフィードバック機構が機能するには、単にAPIを叩くだけでなく、チームの日常作業に自然に組み込まれる運用フローが必要である。ここでは、収集・集約・反映・検証の4段階でワークフローを設計する。

収集：IDE内での低コストなフィードバック入力

最も重要なのは、開発者が「わざわざ別の画面を開く」ことなくフィードバックを送信できることである。IDEプラグイン上で、AIが提案したコードに対して「修正した」旨を1クリックで記録できるUIを設ける。このとき、フィードバックの粒度は「正解/誤解」の二値で十分である。Cogneeの場合、このクリックをトリガーにフィードバックを送信し、蓄積された件数が閾値を超えたら改善処理を実行する。Mnemoverseの場合は、修正の度合いに応じて数値による評価を付与して送信する。

ここで注意すべきは、フィードバックの送信タイミングである。AIの提案をそのまま採用した場合（正解）にもフィードバックを送信すべきだが、実務上は「誤りを修正した場合」のみをトリガーにする設計が一般的である。正解のフィードバックを全て送信すると、ノイズ率が高まり、後述する過学習のリスクが増大する。

集約と反映：バッチ処理と即時処理の使い分け

フィードバックの反映方法は、ツールの特性に応じて使い分ける。MnemoverseはAPIを呼び出すたびに記憶の重みが即時に更新されるため、IDEからの送信をそのままリアルタイムに反映させる設計が自然である。Cogneeは改善処理を明示的に実行する必要があるため、一定の件数が蓄積された時点でバッチ処理として実行する設計が適する。

バッチ処理のスケジュールは、チームのフィードバック発生頻度を1〜2週間観察した上で決めるのが安全である。例えば、1日平均20件のフィードバックが発生するチームであれば、50件を閾値に設定し、約2.5日に1回改善処理が実行される頻度になる。この頻度が低すぎると改善の反映が遅れ、高すぎると処理時間が開発者の作業時間に重なる可能性がある。

検証：週次での検索結果の品質確認

記憶の更新が適切に行われているかを定量的に確認する仕組みを設ける。具体的には、過去に修正されたミスに関するクエリを週次で再実行し、検索結果の上位に正しい情報が含まれているかをチェックする。Cogneeであれば改善処理実行前後で同じクエリを発行して結果を比較できる。Mnemoverseの場合は、ベンチマーク結果の推移を参照する。

この検証結果が期待に届かない場合、フィードバックの粒度やトリガー条件を見直す。例えば、特定のファイル種別のみでミスが集中している場合は、そのファイル種別に対するフィードバックの重みを高める、といったチューニングを行う。

落とし穴：フィードバックのノイズと過学習への対策

フィードバック機構を運用し始めると、すぐに「記憶が逆に悪化した」という現象に遭遇する可能性がある。その原因の多くは、フィードバック自体の品質問題である。

ノイズの構造とフィルタリング

ノイズには2つの構造がある。第一に、開発者自身の誤操作による誤ったフィードバックである。AIの提案を修正したつもりが、実際には別の理由（仕様変更など）でコードを書き換えた場合、その修正は「AIの誤りを正した」ものではない。これをフィードバックとして送信すると、本来正しい記憶が過小評価される。

対策として、フィードバック送信時に「修正理由」のタグ付けを促す設計が有効である。タグの例としては「AIの提案が誤っていた」「仕様変更による修正」「スタイルの統一」などがあり、後者の2つはメモリ層への反映対象から除外する。このフィルタリングをIDEプラグインのUIレベルで行うことで、バックエンドへの不要な負荷を減らせる。

第二に、同一のミスに対して複数の開発者が矛盾したフィードバックを送信するケースである。A開発者が「このパターンは誤り」と評価した記憶を、B開発者が「このパターンは正しい」と評価した場合、記憶の重みが振動し、安定した検索結果が得られなくなる。MnemoverseのRescorla-Wagnerモデルは逐次的な更新を行うため、この振動が蓄積されやすい。対策としては、同一ノードに対するフィードバックの合意率を算出し、閾値未満の場合は更新を保留する機構を設ける。

過学習の防止と忘却メカニズム

過学習は、特定のミスに対するフィードバックが集中し、関連する記憶ノードの重みが極端に偏ることによって生じる。例えば、ある関数の命名規則に関するミスを10回連続でフィードバックすると、その命名規則に関連するすべての記憶ノードの重みが上昇し、本来無関係なコンテキストでもその命名規則が優先的に検索結果に現れるようになる。

対策として、フィードバックの影響範囲を制限する設計が有効である。具体的には、1回のフィードバックが影響する記憶ノードの数を上限設定し、関連性の高い上位N個のノードのみを更新する。Nの値はコードベースの規模に応じて調整するが、初期値としては5〜10程度から始めて、検索結果の品質を観察しながら調整するのが安全である。

また、時間軸での忘却も考慮する必要がある。プロジェクトのアーキテクチャが大幅に変更された場合、過去の記憶が現状と矛盾する。MnemoverseのRescorla-Wagnerモデルは時間経過による自然減衰を内蔵している可能性があるが、公開情報からはその挙動を確認できない。Cogneeの場合は、改善処理実行時に古い記憶の減衰を明示的に実装する必要がある。週次または月次で、一定期間アクセスされていない記憶ノードの重みを段階的に低下させる処理を、運用フローの検証フェーズに組み込むことを推奨する。

発展：カスタムメモリ層の設計と評価指標の設定

既存ツールで要件を満たせない場合、カスタムメモリ層の設計に踏み込む必要がある。判断基準は「フィードバックが検索結果に反映されるまでの遅延が許容範囲内か」「記憶の重み更新がデバッグ可能か」の2点である。前節で比較した各ツールが、いずれかの点でチームの要件と乖離する場合は、自前実装の検討に入るべきである。

カスタム実装を始める前に、評価指標を定義することが重要である。以下の3つの指標を設定し、実装前後で定量比較できるようにしておく。

  • ミス再発率：過去に修正された同一のミスが、以降のセッションで再び提案される頻度。ベースラインを測定した上で、改善の目標値を設定する。
  • 検索精度（Recall@K）：正しい記憶が上位K件に含まれる割合。Kは5または10に設定し、フィードバック適用前後で比較する。
  • フィードバック反映までのセッション数：ユーザーがフィードバックを送信してから、次回検索でその効果が観測されるまでのセッション数。

これらの指標を測定するためには、検索クエリと結果、フィードバックの送信時刻を構造化ログとして残すインストルメンテーションが前提となる。ログの粒度は、最低限「クエリID・検索結果の上位N件・フィードバック値・送信時刻」まで確保する。このログがなければ、後述するベンチマークとの比較もできない。

ベンチマークとして、LoCoMoやLongMemEvalといった公開ベンチマークを活用できる。Mnemoverseはこれらのベンチマークで評価されており、数値がコミットされた実行アーティファクトに追跡可能である（Mnemoverse）。自前の実装も同様のベンチマークで評価することで、標準的な性能を満たしているかを確認できる。特にミス再発率と検索精度の両方を同時に満たすかどうかが、実運用に移行できるかの閾値になる。

実装のベースとしては、オープンソースのメモリライブラリを拡張するアプローチが現実的である。ゼロから設計すると、ベクトル検索のインデックス管理や類似度計算など、周辺処理の実装コストが膨大になる。既存ライブラリの記憶保存・検索の仕組みを再利用し、フィードバック処理と重み更新のロジックを自前で実装する構成が、開発コストと制御性のバランスにおいて合理的である。

まとめ：アーキテクチャレベルでの「記憶の管理」がAI活用の鍵

AIコーディングアシスタントの固定ミスは、プロンプトの指示を強化するだけでは根本的に解決できない。記憶の保存は学習とは異なり、修正を書き込んでも古い誤った記憶が検索対象から除外されるわけではない場合がある。このアーキテクチャ上の制約を踏まえた上で、フィードバックによる記憶の再評価や忘却メカニズムを設計に組み込むことが、ミスの再発防止の核心である。

ツール選定においては、各ツールのフィードバック機能が「検索結果の順序や関連性に実際に影響を与えるか」を公開情報で確認することが第一歩である。Mnemoverseのように-1.0から+1.0の浮動小数点数で検索順序を調整する仕組みや、Cogneeのようにadd_feedbackとimprove()の明示的なAPIを提供する仕組みは、設計判断の材料として明確である。一方、Mem0やZepのように公開ドキュメントにその詳細が不足している場合は、PoCで実際の挙動を検証してから導入を判断する必要がある。

長期的なコード品質の維持には、単にツールを導入して終わりではなく、フィードバックの収集・記憶の更新・効果の検証を継続的に回す運用フローが不可欠である。本記事で比較した設計パターンを参考に、チームの規模や技術スタックに合ったアプローチを選択し、評価指標に基づいて改善を積み重ねることが、AIコーディングアシスタントの生産性を持続的に高める道である。

関連記事

参考

本記事は海外の技術トレンド「How can I prevent my AI coding assistant from repeating fixed mistakes across sessions?」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。

記事一覧に戻る