スシロー

Posted on Jun 17

【2026】Algolia 代替の全文検索SaaS比較：料金・移行コストで選ぶ

#saas #devops #tutorial #webdev

結論（おすすめ1つ）

Typesense Cloud に乗り換えるべきだ。

理由は3つある。まず Algolia と最も近い JSON API 設計を持つため、既存コードの改修量が最小で済む。次に OSS 版と Cloud 版で同一の動作保証があり、ローカル開発→本番への経路が単純だ。最後に、Algolia が課金対象とするオペレーション数ではなく、リソース消費ベースの料金体系を採用しており、検索頻度が高いほど相対コストが抑えられる。

比較表（料金/無料枠/移行コスト/対応言語）

サービス	無料枠	移行コスト	日本語対応	セルフホスト
Algolia	公式の料金ページで要確認	基準	トークナイザー設定要	不可
Typesense Cloud	公式の料金ページで要確認	低（API 構造が近似）	kuromoji 不要・内蔵トークナイザー	OSS 版可
Meilisearch Cloud	公式の料金ページで要確認	中（API 設計が異なる）	内蔵トークナイザーで対応	OSS 版可
OpenSearch Serverless	公式の料金ページで要確認	高（DSL が複雑）	プラグイン追加必要	可（AWS EC2等）
Elasticsearch Cloud	公式の料金ページで要確認	高（DSL が複雑）	analysis-kuromoji 必須	可

移行コストの判断基準：既存の Algolia SDK 呼び出し箇所を grep した際の修正行数を想定している。Typesense は公式が Algolia 互換レイヤー @typesense/typesense-instantsearch-adapter を提供しており、フロントエンドの改修がほぼゼロで済むケースが多い。

移行手順

1. Typesense をローカルで起動（Docker）

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

2. 依存パッケージを差し替える

# Algolia SDK を削除し Typesense SDK を追加
npm uninstall algoliasearch
npm install typesense @typesense/typesense-instantsearch-adapter

3. コレクション（= Algolia の Index）を定義する

import Typesense from 'typesense';

const client = new Typesense.Client({
  nodes: [{ host: 'localhost', port: 8108, protocol: 'http' }],
  apiKey: process.env.TYPESENSE_API_KEY!,
  connectionTimeoutSeconds: 2,
});

await client.collections().create({
  name: 'articles',
  fields: [
    { name: 'title',   type: 'string' },
    { name: 'body',    type: 'string' },
    { name: 'tags',    type: 'string[]', facet: true },
    { name: 'created', type: 'int64' },
  ],
  default_sorting_field: 'created',
});

4. Algolia からデータをエクスポートして投入する

# Algolia CLI でオブジェクトを JSONL に書き出す
algolia objects browse YOUR_INDEX_NAME > export.jsonl

# Typesense の一括インポートエンドポイントに流し込む
curl -X POST "http://localhost:8108/collections/articles/documents/import?action=create" \
  -H "X-TYPESENSE-API-KEY: YOUR_LOCAL_API_KEY" \
  -H "Content-Type: text/plain" \
  --data-binary @export.jsonl

5. フロントエンドのアダプターを差し替える

import TypesenseInstantSearchAdapter from '@typesense/typesense-instantsearch-adapter';

const adapter = new TypesenseInstantSearchAdapter({
  server: {
    apiKey: process.env.NEXT_PUBLIC_TYPESENSE_SEARCH_KEY!,
    nodes: [{ host: 'your-cluster.typesense.net', port: 443, protocol: 'https' }],
  },
  additionalSearchParameters: { query_by: 'title,body' },
});

// 既存の InstantSearch コンポーネントはそのまま使用可能
const searchClient = adapter.searchClient;

本番切り替え前に typesense-exporter と Algolia の browse を使ったダブルライト期間（1〜2週間）を設けて、件数の一致を確認してから DNS / 環境変数を切り替えることを強く勧める。

向き不向き

Typesense が向くケース

スタートアップ〜中規模 SaaS：ドキュメント数が数百万件以内で、Algolia 互換 API の恩恵を最大限に受けたい場合
OSS ファーストのチーム：本番は Cloud、ローカルは Docker という開発環境を統一したい場合
検索 UX を細かくカスタマイズしたい：ファセット・ランキングルール・シノニムを JSON で宣言的に管理したい場合
日本語コンテンツ：追加プラグインなしで日本語トークナイズが動作する（CJK 対応が内蔵）

Typesense を避けるべきケース

億単位のドキュメントを扱う大規模サービス：この規模は Elasticsearch / OpenSearch のシャーディング機能が実績面で上回る
全文検索以外の複合クエリが主体：集計・地理検索・ベクトル検索を高度に組み合わせるなら OpenSearch の方が表現力が高い
既存インフラが AWS に完全集約されている：OpenSearch Serverless との統合コスト（IAM・VPC・CloudWatch）が Typesense 移行コストを下回る場合がある

Meilisearch を選ぶ理由があるとすれば

Typesense より API が学習コスト低めで、セルフホスト前提の小規模プロジェクト（個人ブログ、社内ドキュメント検索など）には Meilisearch も競合する。ただし Algolia からの移行という文脈では、互換レイヤーの完成度で Typesense が一歩リードしている。

DEV Community