【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 回触ってみたい方は、Python 最小サンプル（pip install faiss-cpu から検索まで）だけ写経すれば、FAISS の手触りが掴めます。

FAISS とは｜Meta 製の無料ライブラリ・読み方・DB ではなく検索部品

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

📖 この章で使う用語

ベクトル：意味や特徴を「数字の並び」で表したもの。文章の意味を数百〜数千個の数字で表します。

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

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

OSS：ソースコードが公開され、無料で使えるソフト。

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

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

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

先に一行で。FAISS は、大量のベクトルから「意味が近いもの」を高速で探すための、Meta 製の無料ライブラリです。RAG（検索した情報を AI の回答に足す仕組み）でいえば、「検索」の部分を担う道具にあたります。小規模〜中規模の社内ドキュメント検索を最初に組むとき、私はまず FAISS から入ります。インストールが軽く、PC ですぐ動いて、中で何が起きているかが見えやすいからです。

読み方は「ファイス」＝Facebook AI Similarity Search

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

中身は C++ で書かれ、Python から呼び出して使うのが定番です。公式でも「C++ で書かれ、Python／numpy 向けの完全なラッパーが用意されている」とされています。名前そのものが機能を表しているのが要点で、「Similarity Search（類似検索）」＝「似ているものを探す」道具だと言い切っている。FAISS が速さで勝負できるのは、後の章で出てくる近似最近傍探索（ANN）、つまり「少しの誤差を許して速くする」考え方を取り入れているからです。

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

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

この記事でいちばん伝えたいのがここです。FAISS は、よく「ベクトル DB」と呼ばれますが、厳密にはデータベース製品ではありません。MySQL のような「保存も検索も複数人アクセスも全部面倒みる製品」ではなく、メモリ上のベクトルに対して「近いものを探す計算」をするライブラリ（部品）です。ここを分けておかないと、「データを入れたのに再起動したら消えていた」というつまずきが起きやすい。FAISS 自体は、放っておくと永続化してくれません。

営業時代の感覚でたとえると、FAISS は「とても速い専用電卓」です。数字（ベクトル）を渡せば「これと近いのはこれ」と一瞬で計算してくれるが、その結果を帳簿に綴じたり金庫に保管したり共有したりはしない。一方、データベース製品は「電卓も帳簿も保管庫もアクセス権限も全部そろった経理システム」で、保存・管理・共有まで一括で面倒をみる。だから FAISS を使うときは「永続化」「メタデータ」「サーバー常駐」を自分で別途用意する必要があり、ここが後の Chroma との分かれ目になります。

それでも世間で「ベクトル DB」と呼ばれるのは、広い意味での「ベクトル DB」が、ベクトル検索を担う仕組み全般を指す言葉として使われているからです。製品分類としては「ライブラリ」でも、「ベクトルで意味検索する道具」のくくりでは FAISS も Chroma も Pinecone も同じ仲間に見える。間違いというより、ざっくりまとめた言い方と受け取るのがちょうどいいです。

なぜベクトル検索が必要なのか｜RAG の中での位置づけ・キーワード検索との違い

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

📖 この章で使う用語

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

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

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

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

なぜ普通の検索ではダメなのか。本屋でたとえると分かりやすいです。キーワード検索は、本文に「同じ言葉」が入っている本を棚から探す感覚で、「営業効率化」で探すとその言葉が入った本しか出てこず、「言い方が違うけれど同じ意味」の本は取りこぼします。一方、ベクトル検索は、司書さんに「こういう内容の本、似たのありますか?」と聞く感覚で、言葉が一致しなくても中身の意味が近いものを出してくれる。

業務で社内ドキュメント検索を作るときも、ここが要でした。「経費の精算どうやる?」「立替金の処理方法」「レシートの清算手順」——全部、意味は同じ。キーワード一致では拾いきれないこの揺れを意味で吸収するのがベクトル検索で、その計算エンジンの 1 つが FAISS です。

Python 最小サンプル｜インデックス作成 → 検索を写経で動かす

📖 この章で使う用語

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

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

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

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

手を動かす章です。やることは (1) ベクトルを用意 → (2) インデックス（検索の入れ物）を作る → (3) add で詰める → (4) search で探す、の 4 ステップ。公式の入門例をもとに最小化したコードがこちらです（出典：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 が文章を埋め込みで変換したベクトルになります。

最初に IndexFlatL2 を選んだのは、これが全データと総当たりで距離を測る、いちばん正直なインデックスだからです。速さでは後述の近似インデックスに劣りますが、「正しく動いているか」を確認するにはまずこれが一番。私の業務でも、まず IndexFlatL2 で「ちゃんと近いものが返る」のを確認してから、データが増えた段階で速さ重視のインデックスに置き換えます。いきなり凝ったインデックスから入ると、結果がおかしいときに「設定が悪いのか、データが悪いのか」を切り分けられなくなります。

search が返すのは 2 つです。indices（番号） は近い順に並んだデータの番号（add で入れた順の何番目か）、distances（距離） はその近さで、数字が小さいほど「近い＝似ている」。「ズレが小さい＝そっくり」と思えば腑に落ちます。この 2 つが取れれば、「番号 → 元の文章」を自分で対応づけて、AI に渡す文書を選べます。

使い分けと内部構造｜Chroma/Weaviate との比較・index 種別・GPU の要否

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

📖 この章で使う用語

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

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

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

Flat / IVF / HNSW / PQ：FAISS のインデックス方式。順に「全探索」「グループ分け」「グラフ探索」「圧縮」。

CPU / GPU、faiss-cpu / faiss-gpu：GPU は大量の単純計算を同時にこなす装置。faiss-cpu は CPU だけで動く手軽版、faiss-gpu は大規模版です。

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

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

上記は私の業務での使用感に基づく目安です。各製品の機能は更新されるため、最新の対応状況は公式で確認してください。Chroma・Weaviate 単独の詳しい使い方は別記事で扱う予定です。

私が FAISS を選ぶのは、インストールが軽く PC の中だけで完結でき、低レイヤな分だけ検索ロジックを自由にコントロールできるからです。「永続化やメタデータが欲しくなってきたな」と感じたら Chroma を検討し、構造化やサーバー常駐込みの本格運用が要るなら Weaviate を選ぶ、という順番で考えます。なお、Pinecone や pgvector は私自身は業務で使ったことがありません。有力な選択肢としてよく挙がりますが、使い込んでいないので踏み込んだ断定は避けます。

インデックスの種類：Flat / IVF / HNSW / PQ

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

方式	イメージ	特徴
Flat（全探索）	全部の本を一冊ずつ確認	厳密に正確だが、件数が増えると比例して遅くなる。少件数や厳密性が要るとき推奨
IVF（転置ファイル）	本屋のジャンル棚	近いジャンルの棚だけ見て速くする。まれに別の棚の近い本を取りこぼす
HNSW（グラフ探索）	知り合いの知り合いをたどる	人脈をたどって素早く近づく。メモリに余裕があれば「とても速くて正確」
PQ（量子化）	写真を JPEG で軽くする	圧縮して少ないメモリに収める。データ膨大でメモリが厳しいとき有効

最小サンプルで使った IndexFlatL2 が Flat です。公式ガイドラインでも、少件数や厳密な結果が要るときは Flat、メモリに余裕があれば HNSW が推奨されています（出典：FAISS 公式 wiki「Guidelines to choose an index」、取得：2026-06-03）。各方式の数式の細部は公式ドキュメントを読んで把握している範囲で、業務では「まず Flat で動かす → 遅くなってきたら IVF や HNSW に置き換える」くらいの感覚で十分まわっています。

GPU は要る？まず試す段階は faiss-cpu で十分

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

小〜中規模で「とりあえず意味で検索したい」段階なら CPU 版でまったく困りません。pip install faiss-cpu で入れて最小サンプルを動かすまでは、GPU の話を一切気にしなくて大丈夫です。GPU 版が効く大規模チューニングは私自身そこまで詰めた運用をしていないので公式の範囲にとどめますが、「CPU だと遅くて困る」段階で初めて検討すれば十分。最初から GPU を構えてつまずくより、CPU で 1 回動かす方を強くおすすめします。

料金とつまずき｜無料でも「タダ」でない理由・よくある失敗・非エンジニア向けイメージ

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

📖 この章で使う用語

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

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

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

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

ただし、「無料」と「タダで動き続ける」は別物です。FAISS 自体に料金はかからなくても、コストは「動かす土台」の側に乗る。FAISS は自分のサーバーやメモリの上で動くので、そのサーバー代・メモリ・（必要なら）GPU・運用の手間は自分で持つことになります。ざっくり言えば、FAISS は「初期費用ゼロで自由がきく代わりに運用を全部自分で持つ」、Pinecone のようなマネージドは「お金を払う代わりにサーバー運用を任せられる」というトレードオフです。具体的な金額は構成・規模・契約プランで大きく変わるので、実際のコストは利用するクラウドの公式料金ページで必ず確認してください。

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

実装初学者が定番でハマるところを、症状 → 原因 → 対処で 5 個まとめます。

(1) float32 にしていなくてエラー：add／search で型エラー。原因は NumPy 配列が float64 のまま。→ .astype("float32") を忘れずに付ける。
(2) 次元数が index とずれている：次元の不一致エラー。原因は IndexFlatL2(d) の d と入れるベクトルの長さが違う。→ 埋め込みモデルの次元と index の d を揃える（モデルを変えたら次元も変わる）。
(3) 永続化を忘れてプロセス終了で消える：再起動したらデータが空に。原因は FAISS を DB だと思い込み保存していない。→ DB ではなく検索ライブラリであることを思い出し、faiss.write_index で保存・faiss.read_index で読み戻す。いちばん実害が出やすい誤解です。
(4) 正規化していなくて「近さ」がおかしい：似ているはずが上位に来ない。原因はコサイン類似度で測りたいのにベクトルの長さを揃えていない。→ 必要に応じて正規化してから入れる。
(5) 巨大データを Flat に入れて遅い／メモリ不足：検索が重い、メモリ不足。原因は件数が多いのに全探索の Flat を使用。→ データが増えたら IVF や HNSW に置き換える。

非エンジニアが「意味で探す」をイメージするには

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

FAISS 自体はエンジニア向けの道具なので、ここでは FAISS が支えている「意味で探す」という考え方を仕事の場面でイメージしてみます。営業なら 「前に似た提案書を作った気がするけれど、どのお客様だったか思い出せない」——ファイル名でキーワード検索しても言葉が一致しないと出てこないが、中身の意味で探せれば一発で見つかります。事務職なら 「言い回しは違うが実は同じ内容の問い合わせ」をまとめたい場面が近い。「返品したい」「キャンセルしたいです」「注文を取り消せますか」は文字が違っても意味は同じで、「意味で近いものを集める」発想なら自然にまとまります。

この「意味で探す・意味でまとめる」を裏側で高速に計算しているエンジンの 1 つが 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・エージェントの処理の流れを組むフレームワーク
LangChain とは：FAISS をつなぐ Retrieval を含む、LLM アプリ部品の連結フレームワークを判断軸で整理
Claude Agent SDK とは（Claude Code の中身をアプリに組み込む）：検索結果を AI に渡すエージェントを Python/TS で組む側の入口
LM Studio 使い方：GUI でローカル LLM を動かす（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）