別プロジェクトの決定の混入を検出して分離した — 複数システムを横断するAIとRAGの落とし穴

はじめに

個人で、複数のシステムを並行で開発している。総合配信プラットフォーム、その決済に使う自作の銀行、それに横断的なメモや教訓を貯める知識ベースだ。これらを跨いで作業するAIエージェントに、**共有の記憶（RAG）**を持たせている。RAG＝過去の判断・失敗・教訓をベクトル検索（＝「意味が近いもの」を引く検索）で呼び出す仕組みで、これがあるとエージェントは「毎回初対面の他人」ではなく「私を知る相棒」として動く。

これは強力だ。だが並行開発で横断させると、静かな落とし穴があった。片方のプロジェクト固有の決定が、共有記憶を経由して、もう片方の設計書に混入した——しかも、そのプロジェクト自身が決めたことであるかのように。この記事は、その混入をどう検出し、記憶をどう分離して塞いだかの記録だ。エージェントを”編成”として配備する全体像は総合配信プラットフォームと銀行を、並行で作るに書いた。

共有記憶は、なぜ強くて、なぜ危ないか

横断するエージェントに共有記憶を持たせる利点は、プロジェクトをまたいで学びを引けることだ。だが同じ仕組みが、プロジェクト固有の決定まで境界を越えて運んでしまう。知識ベースは「意味が近いもの」を引く。似た論点は別プロジェクトにも存在するから、こちらでは決めていないことが「意味が近い」だけで引かれる。

横断エージェント ──▶ 共有RAGを検索：「顧客向けフロントのMVP方針」
                          │  意味が近い記憶を引く
        ┌─────────────────┴─────────────────┐
   配信PFの固有決定                     銀行側で作業中
   「画面は作り込まず縦固定・             │
    レスポンシブは後回し」───(混入)──────▶ 銀行の設計書に、
                                          あたかも銀行の決定として書かれる ×

検索が返すのは「意味が近い」記憶であって、「どのプロジェクトの決定か」は付いてこない。だから引いた側は、出典を見ないと取り違える。

# 横断エージェントが共有記憶を引いたとき（出典を見ないと危ない）
query : 「顧客向けフロントのMVP方針」
 └─ hit : 「画面は作り込まず縦固定・レスポンシブは後回し」  ［出典: 配信PF］
          ↑ 意味は近い。だが銀行では、こんな決定はしていない

（MVP＝最小限で価値を出す最初の版。作り込みを絞り、まず動くものを出す方針のことだ。）

実際に、混入した

配信プラットフォーム側には、「MVPでは画面を作り込まず、モバイルは縦固定・Web は同寸固定、レスポンシブ対応は後のフェーズに回す」という、そのプロジェクト固有のMVP方針があった。狭い固定幅のレイアウトは、この方針の帰結だ。

ところが、銀行システム側の顧客向け画面を作っているとき、同じ狭い固定幅が実装され、しかもそれが銀行システム自身の設計書に「MVPの作り込み方針」として書き込まれていた。銀行側は、そんな決定をしていない。

【混入】銀行の設計書に、配信PF由来の「作り込み方針」が“銀行の決定”として記載される ×
【あるべき】その決定は配信PF固有 → 銀行の設計書から除き、銀行自身の方針に戻す ✓

気づいたきっかけは、レビューで出た「これは別プロジェクトの決定では？」という指摘だった。エージェントは「顧客向けフロントのMVP」という似た論点で記憶を引き、出典のプロジェクトを区別しないまま、こちらの設計書に定着させていた。

なぜ起きるのか

知識ベースの検索が測るのは「意味の近さ」だけだ。その記憶がどのプロジェクトの決定か、こちらの設計書に実在する決定か——という所属の情報は、意味の近さには入っていない。言い換えると、「意味が近い」は「このプロジェクトの決定である」ではない。

（同じ「意味が近い＝混ぜてよい、ではない」という罠を、製品側のベクトル検索——別カテゴリの作品が推薦に紛れる話——でも踏んだ。そちらはベクトル検索は「意味が近い」を勝手に混ぜてくるに書いた。）

どう塞ぐか

対策は、記憶に何を置くかの役割分離と、採用前の裏取りだ。まず、共有記憶に置くのは越境してよい”知恵”だけにし、プロジェクト固有の”事実”はコードや設計書の側に置く。

# 記憶に何を置くかの分離（運用規律）
共有RAG      … 転移可能な知恵（設計原則・失敗の教訓・技術知見）  ← 越境してよい
コード/設計書 … プロジェクト固有の事実（設定値・ID・そのプロジェクトの決定）  ← 越境させない

その上で、記憶が示した決定は、採用する前にこちらの設計書で裏取りする。着手前ゲートに、この一段を通す。

# 着手前ゲート（抜粋）— 記憶より設計書を上に置く
・記憶が「こう決まっている」と示しても、こちらの設計書に実在するか確認してから採用
・メモ/記憶が設計書と矛盾したら、設計書が優先
・引いた記憶は、出典のプロジェクトを見る（似た論点ほど別プロジェクトの混入を疑う）

図と規律を並べると、防御の要点は一つに集約される——知恵は越境してよいが、決定は越境させない。

「意味が近い」は「このプロジェクトの決定」ではない

複数システムを横断するエージェントに共有記憶を持たせて分かったのは、記憶の強さと危うさは表裏だ、ということだ。知恵は越境させ、決定は越境させない。共有記憶には転移可能な知恵だけを置き、固有の決定は設計書・コードに置く。そして記憶が示す決定は、こちらの設計書に実在するかを裏取りしてから採用し、引いた記憶の出典プロジェクトを見る。似た論点ほど、別プロジェクトの決定の混入を疑う。

横断するエージェント＋共有記憶は、「私を知る相棒」を作る強力な仕組みだ。だが同じ仕組みが、意味の近い別プロジェクトの決定を運んでくる。この分離と裏取りが、横断運用を安全にする鍵だった。エージェントの編成そのものは総合配信プラットフォームと銀行を、並行で作るに、失敗を指示のゲートに畳む話は「技術的に正しい」を「完成品」に引き上げるに書いた。