全文検索とは
全文検索とは、文書の全体をインデックス化し、任意のキーワードで高速に検索する技術
読み: ゼンブンケンサク
文書の全体をインデックス化し、任意のキーワードで高速に検索する技術。データベースのLIKE検索がテーブルを1行ずつ走査するのに対し、全文検索は転置インデックスを事前に構築することで大量の文書から数十ミリ秒で結果を返す。Elasticsearchが全文検索エンジンの代表格。
かんたんに言うと
本の巻末にある索引と同じ仕組み。「機械学習」という言葉が何ページに登場するかを事前にリスト化しておくことで、本全体を読まなくても該当ページをすぐに見つけられる。この索引をデジタル化して自動構築するのが全文検索エンジン。
転置インデックスの仕組み
全文検索の核となる技術が転置インデックス。文書を単語に分割し、各単語がどの文書に出現するかを記録する。「機械学習」→[文書3, 文書7, 文書42]のようなマッピングを事前に構築する。検索時はこのインデックスを引くだけなので、文書数が100万件でも1,000万件でも検索速度はほとんど変わらない。日本語の場合は形態素解析（MeCab等）で単語を分割する前処理が必要になる。
レキシカル検索との関係
全文検索はレキシカル検索の実装技術。レキシカル検索が「キーワードの一致で文書を探す」という概念であり、全文検索はその概念を転置インデックスで高速に実現する仕組み。BM25は全文検索エンジンが検索結果をランキングするためのスコアリングアルゴリズムで、Elasticsearchのデフォルトスコアリングに採用されている。
AI時代の全文検索
ベクトル検索の登場で全文検索の役割が変わった。意味ベースの検索はベクトル検索が担い、全文検索は固有名詞や型番の完全一致を担当する。両者を組み合わせたハイブリッド検索がRAG構成の標準になりつつある。Elasticsearchは8.0以降でベクトル検索に対応し、1つのエンジンで両方を処理できるようになった。全文検索が不要になるのではなく、ベクトル検索と補完し合う関係に変わっている。
導入時の判断基準
PostgreSQLの全文検索で十分な場合も多い。数十万件以下のテキストデータで、検索速度が1秒以内なら許容範囲という要件ならPostgreSQLのto_tsvector/to_tsqueryで対応できる。数百万件を超えるか、ファセット検索、同義語展開、ハイライト表示が必要ならElasticsearchを導入する。全文検索エンジンの運用にはインデックスの再構築、シャード管理、メモリ設計の知識が必要で、運用負荷は高い。
当社の見解
当社は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社員です。