Typesenseとは｜Algolia代替のOSS検索エンジンを日本語設定・Docker構築・料金比較で判断

Typesenseは、入力のたびに候補を返す検索窓を作るためのオープンソースの全文検索エンジンです。C++で書かれ、インデックスをRAMに置いて応答を速くする設計で、公式は「Algoliaのオープンソース代替」「Elasticsearchより扱いやすい代替」と位置づけています。この記事では30.2系（2026年11月時点の最新安定版）を前提に、Dockerでの起動から検索APIの呼び出しまでのコマンド、日本語を検索させるときのlocale設定と内部の挙動、本番構成の見積もり、Algoliaとの費用比較までを順に扱います。

まとめ：Typesenseを選ぶ条件と日本語検索で先に確かめる3つの設定

Typesenseが向くのは、数百万件規模までの商品・記事・社内データに「打ち間違えても当たる検索」を付けたい案件です。インデックス全体をメモリに載せるため、データ量に比例してRAM費用が増えます。ログ検索のように件数が伸び続ける用途には向きません。

判断を一つに絞るなら、locale「ja」を指定したときに漢字とカタカナがひらがなへ変換されてから分割される点を、導入前に自社の検索語で確かめてください。同じ読みの語が区別しにくくなる性質があり、法令や医療のように同音語の取り違えが許されない文書では、辞書を細かく制御できる別製品のほうが安全です。

Typesenseの構成：C++製インメモリ検索エンジンとGPL-3.0の範囲

Typesenseは自分で登録したデータだけを検索するサーバーで、Webをクロールする検索エンジンとは別物です。アプリの裏側に置き、REST APIで呼び出します。

Algolia代替を狙った設計とインデックス全体をRAMに置く方式

公式ドキュメントの概要ページは、Typesenseを入力中に即座に結果を返す体験のための、タイプミスに強いエンジンと説明しています。速さの源はインデックスをRAMに保持する設計で、ディスクには複製を置きます。GitHubのREADMEによると、起動直後のサーバーは約30MB、Hacker Newsの100万件のタイトルを入れた状態で165MB、2,800万件の書籍データで約14GBです。

転置インデックスで語から文書を引く仕組みそのものは他の全文検索エンジンと共通で、概念の整理は全文検索エンジンとは？仕組みと主要OSS比較、DB内蔵検索との使い分けに譲ります。

GPL-3.0のサーバー本体とApacheライセンスのクライアントの線引き

リポジトリのライセンスはGPL-3.0で、主言語はC++です（2026年11月1日時点でstar数は約2.7万）。READMEのFAQは、GPLが適用されるのはサーバー本体で、各言語のクライアントライブラリはApacheライセンスだと説明しています。

自社アプリからHTTPでサーバーを呼ぶだけの構成と、サーバー本体を改変して製品に同梱して配布する構成では、検討すべき条件が変わります。後者を計画しているなら、設計に入る前に法務の確認を挟んでください。

Dockerで30.2系を起動しコレクション作成とJSONL投入を試す手順

curlとDockerが入った端末を前提に、APIキーは環境変数で渡します。

docker runの1行で30.2系を起動しAPIキーとデータ保存先を渡す

公式のインストールガイドが示す起動例は次のとおりです。--data-dirで指定した場所にディスク側の複製が保存されるので、ホストのディレクトリをマウントしておけばコンテナを作り直しても索引は残ります。

export TYPESENSE_API_KEY=xyz
mkdir "$(pwd)"/typesense-data

docker run -p 8108:8108 \
  -v"$(pwd)"/typesense-data:/data typesense/typesense:30.2 \
  --data-dir /data \
  --api-key=$TYPESENSE_API_KEY \
  --enable-cors

curl http://localhost:8108/health

最後のヘルスチェックが{"ok":true}を返せば起動完了です。イメージのタグはGitHubのリリースページで確認できます。v30.2の公開日は2026年4月19日で、同じ日にv29.1も出ています。

スキーマ定義でlocaleとfacetを指定してコレクションを作る手順

Typesenseでは、文書の入れ物をコレクションと呼び、フィールドの型をスキーマで宣言します。日本語の本文を持つフィールドに付ける設定は"locale": "ja"です。絞り込みに使うカテゴリにはfacetを、並び順の基準にする数値にはdefault_sorting_fieldを指定します。

curl "http://localhost:8108/collections" \
  -X POST \
  -H "Content-Type: application/json" \
  -H "X-TYPESENSE-API-KEY: ${TYPESENSE_API_KEY}" \
  -d '{
    "name": "products",
    "fields": [
      {"name": "title", "type": "string", "locale": "ja"},
      {"name": "category", "type": "string", "facet": true},
      {"name": "price", "type": "int32"},
      {"name": "popularity", "type": "int32"}
    ],
    "default_sorting_field": "popularity"
  }'

collections APIのリファレンスによると、facetの既定はfalse、sortは数値型だけ既定でtrueです。検索にも絞り込みにも使わないフィールドは"index": falseにすると、RAMの消費を抑えられます。

JSONLの一括投入とupsert・emplaceを使い分ける判断基準

既存データの投入は、1行1文書のJSONLファイルをimportエンドポイントへ送ります。documents APIのリファレンスでは、actionにcreate・upsert・update・emplaceの4種があり、サーバーは既定で40件ずつ取り込みます。

cat > products.jsonl <<'EOF'
{"id": "1", "title": "ワイヤレスキーボード 日本語配列", "category": "周辺機器", "price": 6980, "popularity": 120}
{"id": "2", "title": "USB-C 充電ケーブル 2m", "category": "ケーブル", "price": 1280, "popularity": 340}
EOF

curl "http://localhost:8108/collections/products/documents/import?action=upsert" \
  -X POST \
  -H "X-TYPESENSE-API-KEY: ${TYPESENSE_API_KEY}" \
  -T products.jsonl

業務DBから定期的に同期するならupsertを既定にします。同じidの文書を丸ごと置き換えるので、DB側の値と索引の値が食い違いにくいからです。在庫数だけを頻繁に更新するような部分更新ではupdateかemplaceを使い、送るフィールドを絞ります。

日本語検索の設定：locale「ja」の指定とかな変換による分割の挙動

Typesenseはlocaleの指定で日本語用の分割に切り替わり、その中身はソースコードで確認できます。

locale未指定の英語向け分割で漢字かな混じり文が1語になる問題

localeの既定はenで、この場合は空白と記号で語を区切ります。日本語の文は空白を含まないため、「ワイヤレスキーボード日本語配列」のような文字列が丸ごと1語として索引され、「キーボード」で検索しても当たりません。

なお、collections APIの表ではlocaleの例が「jp for Japanese」と書かれています。一方でロケール別の検索ガイドの言語コード表は日本語をjaとしています。v30.2のtokenizer.cppも文字列jaで日本語処理へ分岐しているため、指定はjaにしてください。

ja指定でKAKASIがかな変換してから語を切る実装と同音語の注意

tokenizer.cppを読むと、localeがjaのときは文字列をまずJapaneseLocalizerへ通し、そのあとICUの単語境界判定で語を切っています。japanese_localizer.cppは、漢字かな変換ライブラリのKAKASIを-JH -KH -sの引数で初期化しています。漢字とカタカナをひらがなへ変換し、分かち書きを入れる指定です。

この設計の利点は、表記の違いを吸収しやすいことです。「キーボード」と「きーぼーど」のような表記の違いは、同じひらがなに寄るため一致しやすくなります。代わりに、「機械」と「機会」のように読みが同じ語は索引上で区別しにくくなる可能性があります。KAKASIの読みが文脈とずれる固有名詞も出るため、本番データの代表的な検索語を50〜100語ほど用意し、期待した文書が上位に来るかを導入前に照合してください。

形態素解析の結果を渡すpre_segmented_queryと自前分割の判断

ロケール別ガイドは、CJKの言語では機械学習ベースの分割器のほうが正確な場合があるとし、検索語を事前に分割して渡すpre_segmented_queryを紹介しています。索引側も空白区切りの分割済み文字列で投入すれば、Typesenseのかな変換を通さず、自前の形態素解析器の結果で照合できます。

自前分割へ切り替えるのは、同音語の誤ヒットが照合で目立った場合に限るのが妥当です。分割器の辞書を更新するたびに全件の再投入が要り、同期処理の保守が増えるからです。辞書の細かな制御が要件の中心にあるなら、Elasticsearchの日本語全文検索｜kuromojiのanalyzer構成と辞書追加、N-gram併用の判断で扱っている構成のほうが素直に組めます。

タイポ許容と前方一致の既定値、検索APIのパラメータ調整の勘所

タイポ許容と前方一致は既定で有効です。日本語ではかな読みの長さで判定される点に注意します。

num_typos既定2とmin_len_1typo既定4が短い語へ与える影響

search APIのリファレンスによると、許容するタイプミスの数num_typosは既定2で、1字の誤りを許すのは4文字以上の語（min_len_1typo）、2字の誤りは7文字以上の語（min_len_2typo）です。前方一致のprefixも既定でtrueになっています。

日本語フィールドではひらがなへの変換後に判定されるため、漢字2文字の語でも読みが4文字なら1字違いの候補を拾います。商品名の検索では、取りこぼしを減らす方向に働く仕組みです。社員名や型番のように1字違いが別物になるデータでは、そのフィールドだけnum_typosを0にします。

filter_byとsort_byとfacet_byで絞り込みと並び替えを組む例

検索語の照合と、カテゴリや価格での絞り込みは、1回のリクエストにまとめて指定します。次の例は、価格1万円未満の文書に限定し、人気順に並べ、カテゴリごとの件数も同時に返します。

curl -G "http://localhost:8108/collections/products/documents/search" \
  -H "X-TYPESENSE-API-KEY: ${TYPESENSE_API_KEY}" \
  --data-urlencode "q=キーボード" \
  --data-urlencode "query_by=title" \
  --data-urlencode "filter_by=price:<10000" \
  --data-urlencode "sort_by=popularity:desc" \
  --data-urlencode "facet_by=category"

日本語の検索語はURLエンコードが要るため--data-urlencodeで送ります。応答のfacet_countsには、絞り込み画面に並べるカテゴリ別の件数が入ります。

本番運用の設計：RAM見積もり・3ノード構成・検索専用キーの発行

本番ではメモリ、冗長化、キーの3点を先に設計します。

データ量の2〜3倍を基準にしたRAM見積もりと最小2vCPUの条件

システム要件のページは、キーワード検索で索引するデータの2〜3倍のRAMが要ると案内しています。索引対象のフィールドが合計1GBなら、2〜3GBのメモリを見込む計算です。CPUは最低2 vCPUで、同時検索と索引更新の両方をこなす分だけ余裕を持たせます。

表示にしか使わない長文や画像URLは"index": falseで索引から外し、見積もりの分母を小さくします。

3ノードのRaftクラスタとnodesファイルの書式で組む冗長構成

本番では3ノードか5ノードの構成が強く推奨されています。合意形成にRaftを使う都合上、1台の障害に耐えるために必要なのは最低3台です。高可用性ガイドの書式に沿って、各ノードに同じ内容のファイルを置き、起動時に--nodesで渡します。

192.168.12.1:8107:8108,192.168.12.2:8107:8108,192.168.12.3:8107:8108

書式は「ノード間通信のアドレス:ノード間通信のポート:APIのポート」です。クライアント側は複数ノードを列挙して持ち、1台が落ちても次のノードへ再送させます。

検索専用キーとfilter_by埋め込みのスコープ付きキーでの権限分離

起動時に渡したキーは全権限を持つため、ブラウザへ出してはいけません。API Keysのリファレンスに沿って、検索だけを許すキーを別に発行します。

curl "http://localhost:8108/keys" \
  -X POST \
  -H "X-TYPESENSE-API-KEY: ${TYPESENSE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"description": "search-only products key", "actions": ["documents:search"], "collections": ["products"]}'

1つのコレクションに複数の顧客のデータを入れるSaaSでは、さらにスコープ付きキーを使います。検索専用キーを元にfilter_byと有効期限を埋め込んだキーをバックエンドでHMAC計算して生成するもので、Typesenseサーバーへの問い合わせは要りません。利用者がキーを書き換えて他社の行を引くことはできず、有効期限は親キーより短く設定します。

Algolia・Elasticsearchとの比較で決める採用条件と見送る場面

同じ軽量OSSのMeilisearchとの違いはMeilisearchとは？Rust製OSS全文検索エンジンの使い方・日本語設定・料金で整理しているため、ここではAlgoliaとElasticsearchとの線引きを扱います。

月100万リクエストで比べるAlgolia従量課金とTypesense Cloud

Algoliaの料金ページ（2026年11月1日時点）では、Growプランに月1万検索リクエストと10万レコードが含まれ、超過分は1,000リクエストあたり0.50ドルです。月100万リクエストなら、超過99万リクエストで約495ドルになると計算できます。上位のGrow Plusは1,000リクエストあたり1.75ドルです。

Typesense Cloudの料金計算ページはRAMを0.5GBから1,024GBまで選ぶ方式で、毎秒20リクエストを超えるなら4 vCPU以上を目安にしています。データは小さいのに検索回数が多いサイトほど、リソース課金のTypesenseが有利になる料金体系です。AWS上の検索サービスとAlgoliaの比較はCloudSearchとElasticsearch(OpenSearch)の違い｜AWS検索サービスの選び方と移行手順にまとめています。

Typesenseを採用しない場面：RAM超過・辞書運用・集計要件

次のどれかに当てはまる案件では、Typesenseを選びません。

• 索引対象が数十GBを超え、さらに増え続ける（ログやイベントの検索）
• 同音語の取り違えが許されず、ユーザー辞書で分割を管理したい（法令・医療・特許）
• 検索と同時に複雑な集計や分析をこなしたい

上の2つ目と3つ目はElasticsearchとは？転置インデックスとシャード設計・ライセンス系列で決める採用可否の領域です。逆に、件数が数十万件以下で検索窓が1つだけなら、外部サーバーを足さずにDB内蔵の全文検索で済むこともあります。業務DBとの同期、権限ごとのキー発行、Algoliaからの移行まで含めて検索機能を組み込む場合は、API開発・システム連携の範囲でご相談いただけます。

よくある質問

Typesenseの導入を検討する段階でよく出る質問をまとめました。

Typesenseは無料で使えますか？

サーバー本体はGPL-3.0のオープンソースで、自社環境で動かす限りライセンス料はかかりません。必要なのはサーバー費用で、データ量の2〜3倍のRAMと最低2 vCPUが目安です。マネージド版のTypesense Cloudは、RAM・vCPU・ノード数で料金が決まります。

Typesenseは日本語の全文検索に対応していますか？

対応しています。フィールドに"locale": "ja"を指定すると、漢字とカタカナをひらがなへ変換してから語を区切る処理に切り替わります。指定しないと英語向けの分割になり、日本語の文が1語として扱われて部分的な語で当たりません。同じ読みの語が区別しにくくなる性質があるため、導入前に実データの検索語で結果を確かめてください。

TypesenseとMeilisearchの違いは？

どちらも軽量なOSS検索エンジンですが、実装言語とライセンスが異なります。TypesenseはC++製でGPL-3.0、MeilisearchはRust製でCommunity EditionがMITです。日本語の扱いも違い、Typesenseはフィールドごとにlocaleを指定し、かな変換を経て分割します。クラスタ構成をRaftで組める点はTypesenseの特徴です。

Typesenseでベクトル検索はできますか？

できます。GitHubのリポジトリは「Algolia＋Pineconeのオープンソース代替」を掲げており、キーワード検索に加えて埋め込みベクトルによる検索も同じサーバーで扱えます。ベクトルを索引するとRAMの見積もりはキーワード検索とは別に増えるため、システム要件のページで対象の次元数と件数から計算し直してください。

AlgoliaからTypesenseへ移行できますか？

移行はできますが、APIの互換はないため、検索を呼ぶ側のコード書き換えが必要です。データはJSONLへ書き出してimportで投入できます。画面部品は公式のtypesense-instantsearch-adapterを介してAlgolia向けの検索画面部品を流用する方法があり、移行の手間は画面よりも、同期処理とAPIキー設計の作り直しに寄ります。

関連記事

• Meilisearchとは？Rust製OSS全文検索エンジンの使い方・日本語設定・料金【v1.55対応】：同じ軽量OSS検索エンジンの導入と日本語設定
• Elasticsearchとは？転置インデックスとシャード設計・ライセンス系列で決める採用可否：大規模データと集計を扱う場合の選択肢
• Elasticsearchの日本語全文検索｜kuromojiのanalyzer構成と辞書追加、N-gram併用の判断：辞書で日本語の分割を管理する構成
• 全文検索エンジンとは？仕組みと主要OSS比較、DB内蔵検索との使い分け【2026年10月】：製品を問わない全文検索の仕組み
• FTS5とは？SQLite全文検索の使い方と日本語対応・bm25【実行結果付き】：外部サーバーを足さないDB内蔵検索の例