メタデータ・フィルタリングとは
メタデータ・フィルタリングとは、ベクトル検索やRAGの検索結果をメタデータ（作成日、カテゴリ、部門、言語等）で絞り込む手法
読み: メタデータフィルタリング
ベクトル検索やRAGの検索結果をメタデータ（作成日、カテゴリ、部門、言語等）で絞り込む手法。意味の類似性だけでは不十分な場合に、構造化された属性情報で検索精度を高める。ベクトルデータベースの多くがメタデータ・フィルタリングに対応している。
かんたんに言うと
AI検索の結果を「部門は営業部」「作成日は2025年以降」のような条件で絞り込む仕組み。意味が近い文書を100件見つけた後に、条件に合わない文書を除外する。ECサイトなら「価格帯」「ブランド」「在庫あり」で絞るのと同じ発想。
RAGにおける役割
RAGでは検索した文書をLLMに渡して回答を生成する。検索結果に古い文書や無関係な部門の文書が混じると、LLMの回答精度が下がる。メタデータ・フィルタリングで「最新版のみ」「該当部門のみ」に絞ることで、LLMに渡す文書の質を上げる。フィルタリングなしのRAGで精度が出ないとき、まず試すべき改善策の1つ。
Pre-filteringとPost-filtering
フィルタリングのタイミングは2種類ある。Pre-filteringはベクトル検索の前にメタデータで候補を絞る。Post-filteringはベクトル検索の後に結果をフィルタする。Pre-filteringは検索対象を減らすため高速だが、候補が少なくなりすぎると良い結果を取りこぼす。Post-filteringは精度が高いが、大量のベクトルを検索してからフィルタするため遅い。PineconeやWeaviateはPre-filtering、Milvusは両方に対応している。
メタデータ設計のポイント
フィルタリングの効果はメタデータの設計で決まる。文書の取り込み時に適切なメタデータを付与しなければフィルタリングできない。日付、カテゴリ、部門、言語、バージョンが基本。業務固有の属性（契約種別、製品ライン等）も追加すると精度が上がる。メタデータが増えすぎるとインデックスのサイズが膨らむため、実際に検索条件として使う属性だけを厳選する。
導入時の判断基準
ベクトル検索だけで精度が出ないとき、まずメタデータ・フィルタリングを追加する。リランキングやクエリ変換より実装が簡単で効果が出やすい。既存のベクトルデータベースがフィルタリングに対応しているか確認すれば、追加開発なしで使えることが多い。対応していなければ、アプリケーション側でPost-filteringを実装する。
当社の見解
当社はAI長期記憶システムを自社開発・運用している（2026年4月現在、1,655件の記憶データを蓄積）。この仕組みにより、AIが過去3ヶ月分の経営判断や設計方針を文脈ごと保持し、「前にも同じ話をしましたよね」という手戻りが激減した。セッションが切れても議論の続きから再開できるため、壁打ち相手としてのAIの価値が根本的に変わった。技術的にはCognee MCPサーバーによる記憶保存と、FastEmbed（ONNX Runtime）+ LanceDBによる非常駐型ベクトル検索（検索レイテンシ8ms、GPU不要）を採用。Hindsight（LongMemEval 91.4%精度）やomega-memoryなど複数の既製品を実環境で検証・棄却した上での選定であり、「個人PCでもエンタープライズでも負荷なく動く軽量さ」を最優先に設計している。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。