【DB じゃない】FAISS とは｜営業出身の現役エンジニアが RAG の心臓部を解説

Q: FAISS は無料ですか？

はい、OSS（MIT ライセンス）なので、ライセンス料・利用料は無料です。ただし動かすサーバー・メモリ・GPU などのインフラコストや運用の手間はかかります。金額は規模・構成次第なので、クラウド料金は公式で確認してください。

Q: GPU がないと FAISS は使えませんか？

いいえ。faiss-cpu を使えば CPU だけで動きます。GPU（faiss-gpu）が効いてくるのは大規模データ・大量検索のときで、まず試す段階は CPU 版で十分です。

「RAG を作ってみよう」と思って調べ始めたら、ベクトル DB が要ると分かり、その先で FAISS・Chroma・Weaviate・Pinecone …と名前が乱立して、しかも公式ドキュメントは英語。最初の一歩で固まってしまう——これは、私が社内ドキュメント検索の仕組みを作り始めたころに、まさに通った道でした。

私は業務で FAISS・Chroma・Weaviate の 3 つを実際に使い分けてきました（Pinecone や pgvector は使ったことがないので、そこは公開情報からの整理として正直に書きます）。結論から言うと、小さく始めて自分の PC で動かしたいなら、まず FAISS が筋だと感じています。ただし「FAISS が必ず最適」ではなく、用途と規模次第です。この記事では、読み方から Python の最小サンプル、Chroma との使い分け、料金の誤解解きまで、未経験でも止まらず読める形で通します。

とりあえず最短で 1 回触ってみたい方は、セクション 5 の Python 最小サンプル（pip install faiss-cpu から検索まで）だけ写経すれば、FAISS の手触りが掴めます。

01 — 結論：FAISS は「意味が近いものを高速で探す、Meta 製の無料ライブラリ」

虫眼鏡がたくさんの点の中から、近い意味の点をまとめて見つけ出す様子を表したイラスト

📖 この章で使う用語

ベクトル：意味や特徴を「数字の並び」で表したもの。「身長・体重・年齢」を 3 つ組で表すように、文章の意味を数百〜数千個の数字で表します。

ベクトル検索：あるベクトルに「向き・位置が近い」ベクトルを高速で見つける検索。完全一致ではなく「意味が近い」で探せます。

ライブラリ：プログラムに組み込んで使う「部品の詰め合わせ」。それ単体でサーバーとして動く「製品」とは別物です。

OSS（オープンソースソフトウェア）：ソースコードが公開され、無料で使えるソフトのこと。

先に全体像を一行で置きます。FAISS は、大量のベクトルから「意味が近いもの」を高速で探すための、Meta 製の無料ライブラリです。RAG（検索した情報を AI の回答に足す仕組み）でいえば、「検索」の部分を担う道具にあたります。

ここで押さえておきたいのが、**FAISS は「データベース製品（DB）」ではなく「検索ライブラリ（部品）」**だという点です。よく「ベクトル DB」と紹介されますが、ここを最初に分けておくと、後の話がぐっと分かりやすくなります（詳しくはセクション 3 で）。

私の場合、小規模〜中規模の社内ドキュメント検索のような仕組みを最初に組むとき、まず FAISS から入ることが多いです。インストールが軽く、自分の PC ですぐ動いて、中で何が起きているかが見えやすいからです。「とりあえず意味で検索できる状態」を最短で作りたいときに、相性がいい道具だと感じています。

この章だけ読めば概要は掴めます。以降は、読み方、なぜベクトル検索が要るのか、Python の動かし方、Chroma との違い、と一段ずつ降りていきます。

02 — 読み方と正体：「ファイス」＝Facebook AI Similarity Search

📖 この章で使う用語

近似最近傍探索（ANN）：「完全に一番近いもの」を厳密に探す代わりに、「ほぼ一番近いもの」を高速に探す方法。少しの誤差と引き換えに速さを得ます。

読み方から先に。FAISS は「ファイス」と読みます。営業時代の私なら、まず「これ何て読むの?」で止まっていたと思うので、ここは最初に押さえておきます。

名前の由来は Facebook AI Similarity Search、つまり「Facebook（現 Meta）の AI による類似検索」です。Meta の基礎 AI 研究チーム（Fundamental AI Research）が開発・公開しているソフトで、ライセンスは MIT（自由に使える種類のライセンス）と公式に明記されています（出典：FAISS 公式 GitHub、取得：2026-06-03）。

中身は C++ で書かれていて、Python から呼び出して使うのが定番です。公式の説明でも「C++ で書かれ、Python／numpy 向けの完全なラッパー（呼び出し口）が用意されている」とされています（出典：FAISS 公式 GitHub、取得：2026-06-03）。私も普段、業務では Python から FAISS を触っています。

おもしろいのは、名前そのものが機能を表していることです。「Similarity Search（類似検索）」——つまり「似ているものを探す」道具だと、名前の時点で言い切っている。難しそうな名前に見えて、やっていることは「意味が近いものを高速で探す」だけ、と最初に腹落ちしておくと、この後がラクになります。

なお、後の章で「ほぼ一番近いものを高速に探す」近似最近傍探索（ANN）という言葉が出てきます。FAISS が速さで勝負できるのは、この「少しの誤差を許して速くする」考え方を取り入れているからだ、とだけ今は覚えておけば十分です。

03 — 大事な誤解解き：FAISS は「DB」ではなく「検索ライブラリ」

データベースの円柱（×）と検索の虫眼鏡（✓）を対比し、FAISSは検索ライブラリだと示したイラスト

📖 この章で使う用語

データベース製品（DB）：データの保存・更新・検索・複数人アクセスなどを一括で面倒みる「製品」。MySQL などが代表例です。

永続化：プログラムを終了してもデータが消えないよう、ファイルやディスクに保存しておくこと。

メタデータ：本体データに付随する「タグ的な情報」（作成日・カテゴリ・ファイル名など）。

この記事でいちばん伝えたいのが、この章です。FAISS は、よく「ベクトル DB」と呼ばれますが、厳密にはデータベース製品ではありません。MySQL のような「保存も検索も複数人アクセスも全部面倒みる製品」ではなく、**メモリ上のベクトルに対して「近いものを探す計算」をするライブラリ（部品）**です。

ここを分けておかないと、後で痛い目に遭います。たとえば「データを入れたのに、プログラムを再起動したら消えていた」というつまずきは、FAISS を DB だと思い込んでいると起きやすい。FAISS 自体は、放っておくと保存（永続化）してくれません。

「ライブラリ」と「データベース製品」は何が違うのか

営業時代の感覚でたとえると、こうなります。**FAISS は「とても速い専用電卓」**です。数字（ベクトル）を渡せば「これと近いのはこれ」と一瞬で計算してくれる。けれど、その計算結果を帳簿に綴じておいたり、金庫に保管したり、他の社員と共有したりはしてくれません。

一方、**データベース製品は「電卓も帳簿も保管庫もアクセス権限も全部そろった経理システム」**です。計算だけでなく、保存・管理・共有まで一括で面倒をみてくれる。FAISS はそのうちの「計算」を、とびきり速くこなす一点特化の道具、というイメージです。

だから FAISS を使うときは、「保存（永続化）はどうするか」「タグのような付随情報（メタデータ）はどう持つか」「サーバーとしてどう常駐させるか」を、自分で別途用意する必要があります。ここが、後で出てくる Chroma との分かれ目になります。

それでも世間で「ベクトル DB」と呼ばれる理由

「じゃあなぜ世間ではベクトル DB と呼ぶの?」という疑問は当然です。これは、広い意味での「ベクトル DB」が、ベクトル検索を担う仕組み全般を指す言葉として使われているからだと考えると、すっきりします。

厳密な製品分類としては「ライブラリ」でも、「ベクトルを使って意味で検索する道具」というくくりでは、FAISS も Chroma も Pinecone も同じ仲間に見える。だから入門記事ではまとめて「ベクトル DB」と呼ばれがちです。間違いというより、ざっくりまとめた言い方、くらいに受け取っておくのがちょうどいいと思います。

04 — なぜベクトル検索が必要なのか（RAG の文脈で位置づけ）

資料→ベクトル検索→AIの回答という流れで、RAGの中でのベクトル検索の位置づけを表したイラスト

📖 この章で使う用語

埋め込み（embedding）：テキストを「意味を表す数値の並び（ベクトル）」に変換する操作・結果。意味が近い文は、数値としても近くなります。

キーワード検索：文字列の一致で探す検索。「同じ言葉」が入っていないとヒットしません。

LLM（大規模言語モデル）：ChatGPT や Claude の中身にあたる、文章を理解・生成する AI。詳しくは別記事（LLM とは）へ。

FAISS が「RAG のどこに座るか」を、地図で示します。結論を先に言うと、FAISS は RAG の「検索」担当です。

RAG のおおまかな流れは、(1) 文書を埋め込み（embedding）で数値に変える → (2) FAISS で「質問に意味が近い文書」を探す → (3) 見つかった文書を LLM に渡して回答させる、という 3 工程です。このうち真ん中の「探す」を FAISS が担います。RAG 全体の組み立てやデータの流れは別記事に譲るので、ここでは「FAISS が担う役割」だけに絞ります（RAG とはで全体像を解説しています）。

キーワード検索とベクトル検索の違い

なぜ普通の検索ではダメなのか。ここは本屋でたとえると分かりやすいです。

キーワード検索は、タイトルや本文に「同じ言葉」が入っている本を棚から探す感覚です。「営業効率化」で探すと、その言葉が入った本しか出てきません。便利ですが、「言い方が違うけれど同じ意味」の本は取りこぼします。

一方、ベクトル検索は、本屋の司書さんに「こういう内容の本、似たのありますか?」と聞く感覚です。言葉が一字一句一致していなくても、「中身の意味が近いもの」を出してくれる。これが、AI に正しい情報を渡すうえで効いてきます。

私が業務で社内ドキュメント検索のような仕組みを作るときも、ここが要でした。社内の質問は、人によって言い回しがバラバラです。「経費の精算どうやる?」「立替金の処理方法」「レシートの清算手順」——全部、意味は同じです。キーワード一致だけだと拾いきれないこの揺れを、意味で吸収してくれるのがベクトル検索で、その計算エンジンの 1 つが FAISS、という位置づけです。

05 — Python で動かす最小サンプル：インデックス作成 → 検索

📖 この章で使う用語

IndexFlatL2：FAISS のいちばん基本的なインデックス（検索の入れ物）。全ベクトルと総当たりで距離を計算します。

NumPy（ナンパイ）：Python で数値計算・配列を扱う定番ライブラリ。FAISS にはこの配列の形でデータを渡します。

float32：32 ビットの小数の型。FAISS はこの型でベクトルを受け取ります（指定しないとエラーになりがちです）。

k（近傍数）：検索で「上位何件を取るか」の件数。

ここは手を動かす章です。やることは 4 ステップ、(1) ベクトルを用意する → (2) インデックス（検索の入れ物）を作る → (3) add で詰める → (4) search で探す、これだけです。

まずは写経できる最小サンプル

公式の入門例をもとに、最小の形にしたコードがこちらです（出典：FAISS 公式 GitHub「Getting started」、取得：2026-06-03）。

# まずはインストール。CPU 版で十分です（GPU 版は後述）
pip install faiss-cpu numpy

# faiss_min.py — FAISS の最小サンプル：作る → 入れる → 探す
import faiss
import numpy as np

d = 64                       # ベクトルの次元数（数字の個数）
nb = 10000                   # 検索される側のデータ数

# (1) ベクトルを用意（本来は埋め込みモデルで作る。ここではランダムで代用）
data = np.random.random((nb, d)).astype("float32")   # 必ず float32

# (2) インデックスを作る（L2＝ユークリッド距離で測る、最も基本のもの）
index = faiss.IndexFlatL2(d)

# (3) データを詰める
index.add(data)

# (4) 検索する（query に近い上位 k 件を探す）
query = np.random.random((1, d)).astype("float32")   # 探したいベクトル 1 件
k = 5
distances, indices = index.search(query, k)

print("近い順のデータ番号:", indices)
print("その距離:", distances)

ポイントは「埋め込みモデルでテキストを数値に変える部分」を、ここではあえてランダムで代用していることです。実際の RAG では、この data が文章を埋め込みで変換したベクトルになります。その作り方は別記事に譲り、ここでは「FAISS の動かし方」だけに集中します。

IndexFlatL2 から始める理由

最初に IndexFlatL2 を選んでいるのには理由があります。これは全データと総当たりで距離を測る、いちばん正直なインデックスです。速さでは後述の近似インデックスに劣りますが、「正しく動いているか」を確認するには、まずこれが一番です。

私の業務での入り方も、たいていこれです。まず IndexFlatL2 で「ちゃんと近いものが返ってくる」のを確認してから、データが増えてきた段階で、速さ重視のインデックスに置き換えます（セクション 7 で扱います）。いきなり凝ったインデックスから入ると、結果がおかしいときに「設定が悪いのか、データが悪いのか」が切り分けられなくなる。これは、営業の提案でも同じで、まず単純な型で当ててから磨く方が、結果的に早かったりします。

結果の読み方

search が返すのは 2 つです（出典：FAISS 公式 GitHub「Getting started」、取得：2026-06-03）。

indices（番号）：近い順に並んだ、データの番号。add で入れた順の何番目か、を表します。
distances（距離）：その近さ。**数字が小さいほど「近い＝似ている」**です。

「距離が小さいほど近い」は直感と逆に感じるかもしれませんが、「ズレが小さい＝そっくり」と思えば腑に落ちます。この 2 つが取れれば、「番号 → 元の文章」を自分の側で対応づけて、AI に渡す文書を選べます。

06 — FAISS を選ぶとき・選ばないとき：Chroma / Weaviate との使い分け

棚に並んだ3つの道具（高速エンジン・万能ツールボックス・サーバー）でFAISS/Chroma/Weaviateの使い分けを表したイラスト

📖 この章で使う用語

Chroma（クロマ）：永続化・メタデータ管理込みで手軽に使える OSS のベクトルストア。Python から扱いやすいのが特徴です。詳細は別記事へ。

Weaviate（ウィービエイト）：ベクトル検索に検索 API や構造化を組み合わせた、本格運用寄りの OSS。詳細は別記事へ。

マネージドサービス：サーバー運用を提供側に任せ、利用料を払って使うクラウドサービス（Pinecone など）。

ここは、私が 3 つを実際に使い分けてきた経験から書ける章です。先に結論を言うと、「どれが必ず正解」はありません。用途・規模・運用体制で選ぶもの、というのが正直な答えです。そのうえで、私の感覚での目安を整理します。

	FAISS	Chroma	Weaviate
正体	検索ライブラリ（部品）	ベクトルストア	ベクトル DB／検索基盤
永続化（保存）	自分で用意	込み	込み
メタデータ管理	自分で用意	込み	込み（構造化に強い）
サーバー常駐	しない（自分で組む）	しやすい	する前提（本格運用寄り）
学習コスト	低〜中（低レイヤ）	低（手軽）	中〜高
向く規模感	小〜中、PC で完結	小〜中、手軽に永続化	中〜大、本格運用

上記は私の業務での使用感に基づく目安です。各製品の機能は更新されるため、最新の対応状況は公式で確認してください。

FAISS が向く場面

私が FAISS を選ぶのは、「小さく・速く・自分で握りたい」ときです。インストールが軽く、PC の中だけで完結でき、中で何が起きているかが見えやすい。検索のロジックを自分でコントロールしたい場面では、低レイヤな分だけ自由がききます。プロトタイプを最短で立ち上げたいときの、最初の一手として頼りにしています。

Chroma が向く場面

逆に 「保存もタグ管理も込みで、手軽に始めたい」なら Chroma が候補です。FAISS だと自分で書く必要のある永続化やメタデータ管理が、最初から入っているので、その分ラクができます。私の場合、「永続化やメタデータが欲しくなってきたな」と感じたら Chroma を検討する、という順番で考えることが多いです。Chroma 単独の詳しい使い方は、別記事で扱う予定です。

Weaviate が向く場面

さらに 「本格運用・検索 API や構造化まで欲しい」なら Weaviate が選択肢に入ります。ベクトル検索だけでなく、データを構造化して扱う方向に強く、サーバーとして常駐させて運用する前提の作りです。その分、学習コストは上がるので、規模と体制が見合うかで判断します。Weaviate 単独の解説も、別記事で扱う予定です。

なお、Pinecone や pgvector は、私自身は業務で使ったことがありません。サーバー運用を任せられるマネージドサービス（Pinecone など）や、PostgreSQL という DB にベクトル検索機能を足す pgvector も有力な選択肢としてよく挙がりますが、ここは公開情報からの整理にとどめ、踏み込んだ断定は避けます。「使ったことのある 3 つについては実感で語り、未経験のものは正直にそう書く」——このスタンスで読んでいただければと思います。

07 — インデックスの種類を噛み砕く：Flat / IVF / HNSW / PQ

📖 この章で使う用語

Flat（全探索）：すべてのベクトルと総当たりで比較する方式。正確ですが、件数が増えると遅くなります。

IVF（転置ファイルインデックス）：あらかじめベクトルをグループ分けし、近いグループだけを探す方式。

HNSW（階層的なグラフ）：ベクトル同士を「つながり」でつなぎ、近いものをたどって素早く探すグラフ方式。

PQ（直積量子化）：ベクトルを圧縮して、少ないメモリで近似検索できるようにする方式。

FAISS には、検索を速くするための「インデックスの種類」がいくつもあります。難しそうに見えますが、本質は 「正確さ・速さ・メモリ（消費する記憶容量）のどれを優先するか」のトレードオフだけです。代表的な 4 つを、たとえで掴んでおきます。

Flat（全探索）— 正確さ最優先・小規模向け

セクション 5 で使った IndexFlatL2 がこれです。全データと総当たりで比べる、いちばん正直な方式。結果は厳密に正確ですが、件数が増えると比例して遅くなります。公式のガイドラインでも、件数が少ない場合や、厳密に正確な結果が要る場合は Flat が推奨されています（出典：FAISS 公式 wiki「Guidelines to choose an index」、取得：2026-06-03）。

IVF（転置ファイル）— グループ分けで速くする

IVF は、本屋のジャンル棚のイメージです。最初に本（ベクトル）をジャンル分けしておき、検索のときは「近いジャンルの棚」だけを見る。全部の棚を見ないので速くなります。そのぶん、まれに「別の棚にあった近い本」を取りこぼすことがある——これが「少しの誤差と引き換えに速さを得る」という話です。

HNSW（グラフ探索）— つながりをたどって速くする

HNSW は「知り合いの知り合いをたどる」イメージです。ベクトル同士を「近いもの同士」でつないでおき、検索では、その人脈をたどって目的地に素早く近づきます。公式ガイドラインでも、メモリに余裕があれば HNSW は「とても速くて正確」と位置づけられています（出典：FAISS 公式 wiki「Guidelines to choose an index」、取得：2026-06-03）。

PQ（量子化）— 圧縮してメモリを節約する

PQ は、ベクトルを「圧縮」してメモリを節約する方式です。写真を JPEG で軽くする感覚に近く、少しだけ精度を犠牲にする代わりに、たくさんのベクトルを少ないメモリに収められます。データが膨大でメモリが厳しいときに効いてきます。

業務での向き合い方

ここで正直に書いておくと、各方式の内部の数式や理論の細部までは、私は公開情報からの整理として把握している範囲です。業務でやっているのは、もっと泥臭くて、**「まず Flat で動かす → データが増えて遅くなってきたら IVF や HNSW に置き換える」**くらいの感覚で十分まわっています。最初から最適なインデックスを当てにいくより、動くものを作ってから測って替える方が、結果的にラクでした。深いパラメータ調整が要る規模になったら、そのとき公式ドキュメントと向き合えばいい、というスタンスです。

08 — GPU は要る？faiss-cpu と faiss-gpu の違い

📖 この章で使う用語

CPU / GPU：CPU は汎用の計算装置、GPU は大量の単純計算を同時に高速でこなす装置。大量のベクトル計算では GPU が効いてきます。

faiss-cpu / faiss-gpu：FAISS の 2 つのパッケージ。前者は CPU だけで動く手軽版、後者は GPU を使う大規模版です。

「GPU がないと使えないの?」という不安をよく聞きますが、結論、まず試す段階では faiss-cpu で十分です。

FAISS には CPU だけで動く faiss-cpu と、GPU を使う faiss-gpu の 2 つのパッケージがあります（出典：FAISS 公式 GitHub「INSTALL」、取得：2026-06-03）。公式でも、GPU 版は CPU 版の検索を高速化する「ほぼそのまま差し替えられる」位置づけと説明されていて、大量のデータ・大量の検索でその真価が出ます。

私の業務での感覚でも、小〜中規模で「とりあえず意味で検索したい」段階なら、CPU 版でまったく困りません。pip install faiss-cpu で入れて、セクション 5 のコードを動かす——ここまでは GPU の話を一切気にしなくて大丈夫です。

GPU 版が効いてくる大規模なチューニングについては、私自身が業務でそこまで詰めた運用をしているわけではないので、ここは公開情報からの整理にとどめます。「規模が本当に大きくなって、CPU だと遅くて困る」段階で、初めて GPU 版を検討すれば十分だと思います。最初から GPU を構えてつまずくより、CPU で 1 回動かす方を強くおすすめします。

09 — 料金：FAISS は無料（OSS）。ただし「タダ」ではない理由

📖 この章で使う用語

ライセンス料：ソフトを使う権利に対して払うお金。OSS の FAISS にはこれがありません。

従量課金：使った分だけ料金が発生する仕組み（マネージドサービスに多い）。FAISS 自体にはありません。

インフラコスト：サーバー・メモリ・GPU・運用の手間など、動かす土台にかかるコスト。

お金の話を整理します。FAISS は OSS のライブラリなので、ライセンス料・利用料は無料です。公式でも MIT ライセンスと明記されています（出典：FAISS 公式 GitHub、取得：2026-06-03）。Pinecone のようなマネージドサービスと違って、使った分だけ課金される従量課金もありません。

ただし、ここで気をつけたいのが、「無料」と「タダで動き続ける」は別物だということです。FAISS 自体に料金はかかりませんが、コストは「動かす土台」の側に乗ります。FAISS は自分のサーバーやメモリの上で動くので、そのサーバー代・メモリ・（必要なら）GPU、そして運用の手間は、自分で持つことになります。

これは、マネージドサービスとのトレードオフでもあります。ざっくり言えば、FAISS は「初期費用ゼロで自由がきく代わりに、運用を全部自分で持つ」。Pinecone のようなマネージドは「お金を払う代わりに、サーバー運用を任せられる」。どちらが得かは、規模と、運用にどれだけ手をかけられるかで変わります。

なお、サーバー代やクラウド料金の具体的な金額は、構成や規模、契約プランによって大きく変わります。ここで金額を断定することはできないので、実際のコストは利用するクラウドの公式料金ページで必ず確認してください。私自身、Pinecone の具体的な料金体系は業務で使い込んでいないため、そこも公開情報の範囲でとどめておきます。

10 — FAISS でよくある失敗・つまずき 5 個

📖 この章で使う用語

dtype（データ型）：データが「整数か小数か」などの種類。FAISS では float32 が必要です。

次元数：ベクトルを構成する数字の個数。index 作成時の次元と、入れるベクトルの次元は一致が必須です。

正規化：ベクトルの長さを揃える前処理。コサイン類似度（向きの近さ）で測りたいときに必要になることが多いです。

実装初学者が定番でハマるところを、症状 → 原因 → 対処の形で 5 個まとめます。私自身が通った道や、周りでよく見かけるつまずきを、特定できない形にして並べました。

(1) float32 にしていなくてエラー 症状：add や search で型のエラーが出る。原因：NumPy 配列が float32 になっていない（多いのは float64 のまま）。対処：.astype("float32") を忘れずに付ける。セクション 5 のコードでも必ず付けています。

(2) ベクトルの次元数が index とずれている 症状：追加や検索で次元の不一致エラー。原因：IndexFlatL2(d) の d と、入れるベクトルの長さが違う。対処：埋め込みモデルが出す次元数と、index の d を必ず揃える。モデルを変えたら次元も変わる点に注意。

(3) 永続化を忘れてプロセス終了で消える 症状：再起動したらデータが空に。原因：FAISS を DB だと思い込み、保存していない。対処：セクション 3 の「DB ではなく検索ライブラリ」を思い出し、faiss.write_index でファイルに保存し、faiss.read_index で読み戻す。この誤解が、いちばん実害が出やすいところです。

(4) 正規化していなくて「近さ」がおかしい 症状：似ているはずのものが上位に来ない。原因：コサイン類似度（向きの近さ）で測りたいのに、ベクトルの長さを揃えていない。対処：必要に応じてベクトルを正規化してから入れる。「距離で測るのか、向きで測るのか」を最初に決めておくと迷いません。

(5) いきなり巨大データを Flat に入れて遅い／メモリ不足 症状：検索が重い、メモリが足りない。原因：件数が多いのに全探索の Flat を使っている。対処：セクション 7 のとおり、データが増えたら IVF や HNSW に置き換える。まず Flat で動かすのは正解ですが、「増えたら替える」をセットで覚えておくと安心です。

11 — ベクトル検索を、エンジニアでない人がイメージで掴むには

人が似た形のものをグループごとに仕分けする様子で、ベクトル検索のイメージを表したイラスト

📖 この章で使う用語 （この章は新しい技術用語を増やしません。これまでの言葉を、仕事の場面に置き換えるだけです。）

FAISS そのものは、コードを書くエンジニア向けの道具です。なので「営業の方が FAISS を直接触る」というユースケースは、ここでは無理に作りません。代わりに、FAISS が支えている「意味で探す」という考え方を、仕事の場面でイメージしてみます。

営業時代の私を例にすると、こういう場面でした。「前にどこかで似た提案書を作った気がするけれど、どのお客様だったか思い出せない」。ファイル名やタイトルでキーワード検索しても、言葉が一致しないと出てこない。けれど中身の意味で探せたら、「あ、この案件と似てる」と一発で見つかったはずです。

事務職の方なら、「言い回しは違うけれど、実は同じ内容の問い合わせ」をまとめたい場面が近いかもしれません。「返品したい」「キャンセルしたいです」「注文を取り消せますか」——文字は違っても、意味は同じ。これをキーワード一致で束ねるのは大変ですが、「意味で近いものを集める」発想なら自然にまとまります。

この「意味で探す・意味でまとめる」を、裏側で高速に計算しているエンジンの 1 つが FAISS です。自分で FAISS を触らなくても、最近の AI 検索や社内 AI が「言い方が違っても拾ってくれる」とき、こういう仕組みが裏で動いている——そう知っておくだけでも、AI ツールの選び方や、エンジニアとの会話の解像度が一段上がると思います。

よくある質問

Q1. FAISS の読み方は？

A.「ファイス」と読みます。Facebook AI Similarity Search の略で、Meta（旧 Facebook）が公開している無料のベクトル検索ライブラリです。「似ているものを探す」道具だと、名前そのものが表しています。

Q2. FAISS はデータベースですか？

A. 厳密には違います。MySQL のような「製品」ではなく、メモリ上のベクトルから近いものを探す「検索ライブラリ（部品）」です。保存（永続化）やメタデータ管理は、自分で用意するか、Chroma のようなツールに任せます。ここを分けておくと、つまずきがぐっと減ります。

Q3. FAISS は無料ですか？

A. はい、OSS（MIT ライセンス）なので、ライセンス料・利用料は無料です。ただし、動かすサーバー・メモリ・GPU などのインフラコストや運用の手間はかかります。金額は規模・構成次第なので、クラウド料金は公式で確認してください。

Q4. FAISS と Chroma はどちらを使えばいいですか？

A.「必ずこちら」という正解はありません。小さく速く・自分で握りたいなら FAISS、永続化やメタデータ込みで手軽に始めたいなら Chroma が目安です。用途・規模・運用体制で選びます（私の場合は、永続化が欲しくなった段階で Chroma を検討します）。

Q5. GPU がないと FAISS は使えませんか？

A. いいえ。faiss-cpu を使えば CPU だけで動きます。GPU（faiss-gpu）が効いてくるのは大規模データ・大量検索のときで、まず試す段階は CPU 版で十分です。

ここまでで、FAISS の正体（DB ではなく検索ライブラリ）、読み方、Python の動かし方、Chroma との使い分け、料金まで通しました。最後に段階感だけ置いておきます。まず FAISS で動かしてみる → 永続化やメタデータが欲しくなったら Chroma → 本格運用なら Weaviate、という順番で考えると、迷子になりにくいと思います。

RAG 全体の組み立てや、AI エージェントへの応用は、それぞれ別記事で扱っています。FAISS は、その大きな仕組みの中の「検索」という一点を、無料で・手元で・高速に支えてくれる道具——そう捉えていただければ十分です。

RAG とは：FAISS が担う「検索」を含む、RAG の全体像を解説
LLM とは：ChatGPT や Claude の中身、生成 AI の土台を整理
AIエージェント作り方：RAG を組み込んだエージェント構築の進め方
LangGraph とは：RAG・エージェントの処理の流れを組むフレームワーク
Chroma とは（公開予定）：永続化・メタデータ込みで手軽に始めるベクトルストア
Weaviate とは（公開予定）：本格運用・構造化に強いベクトル検索基盤

※本記事の内容に誤りを見つけられた場合は、お問い合わせフォームからご連絡ください。確認のうえ訂正します。

出典

facebookresearch/faiss（FAISS 公式 GitHub）（取得：2026-06-03）
FAISS 公式 wiki「Getting started」（取得：2026-06-03）
FAISS 公式 wiki「Guidelines to choose an index」（取得：2026-06-03）
FAISS 公式「INSTALL.md」（取得：2026-06-03）