Amazon OpenSearch Serviceとは？料金体系・構築手順・運用のポイントまで徹底解説

Amazon OpenSearch Serviceは、AWSが提供するフルマネージド型の検索・分析サービスです。本記事では「サービスの概要」「料金体系と無料利用枠」「ドメインの構築手順」「日本語検索の精度向上」「運用のポイント」を、これから導入を検討する開発者・インフラ担当者の目線で整理します。とくに気になりやすい料金とコスト最適化を中心に、実務で迷わない判断材料を提供します。

まとめ：Amazon OpenSearch Serviceの要点

先に結論を整理します。Amazon OpenSearch Serviceは、オープンソースの全文検索・分析エンジン「OpenSearch」をAWS上でフルマネージドに利用できるサービスです。サーバーの構築・運用をAWSに任せられるため、全文検索やログ分析を短期間で立ち上げられます。

• 料金は3つの軸で決まります。インスタンスの稼働時間、ストレージ容量、データ転送量です。長期運用ならリザーブドインスタンス、間欠的な利用ならServerless（OCU課金）が候補になります。
• 無料利用枠があり、t2.small.searchまたはt3.small.searchインスタンス（単一AZ）を月750時間まで、加えてEBSストレージを月10GBまで試せます。まず小さく検証してから本番設計に進めます。
• 構築は4ステップです。AWSアカウント準備→ドメイン作成→インデックス作成→データ投入と検索。マネジメントコンソール・CLI・APIのいずれからも操作できます。
• 日本語検索はKuromojiやSudachiなどの形態素解析プラグインを使うことで精度が大きく向上します。

以降では、これらを料金→構築→日本語検索→ユースケース→運用の順に掘り下げます。

Amazon OpenSearch Serviceとは：OpenSearch・Elasticsearchとの関係

Amazon OpenSearch Serviceは、AWS上に保存・取り込んだデータに対して高速な全文検索やリアルタイムの分析を行うためのマネージドサービスです。検索エンジン本体である「OpenSearch」と、可視化ツール「OpenSearch Dashboards」を、クラスターの構築・パッチ適用・スケーリングといった運用込みで提供します。

OpenSearch自体は、Elasticsearchをベースに開発されたオープンソースの全文検索・分析エンジンです。Elastic社がライセンスを変更した経緯を受け、AWSが当時のオープンソース版（Elasticsearch 7.10系）をフォークして立ち上げました。ライセンスはApache 2.0で、誰でも自由に利用できます。サービス名も、もともとの「Amazon Elasticsearch Service」から2021年9月に「Amazon OpenSearch Service」へと改称されています。OpenSearchエンジン側の概要やバージョンの全体像は、OpenSearch 3.0の全体像を理解するための概要と背景もあわせて参照してください。

提供形態は大きく2つあります。インスタンスを指定して常時稼働させる「マネージドクラスター（ドメイン）」と、リソースを自動でスケールさせる「OpenSearch Serverless」です。後者はキャパシティ設計や運用の手間を抑えられる一方、課金単位が異なるため、ワークロードの性質に応じて選び分けます。

Amazon OpenSearch Serviceの料金体系とコスト最適化

マネージドクラスター（ドメイン）の料金は、基本的に次の3つの軸で決まります。料金は変動するため、実際の金額は必ず公式の料金ページとAWS Pricing Calculatorで確認してください。

• インスタンス時間：検索やインデックス処理を担うインスタンスの種類と稼働時間に応じた課金です。
• ストレージ：データ保存に使うEBSボリュームの容量に応じた課金です。ストレージタイプ（gp3など）でも単価が変わります。
• データ転送：ドメインとの間で発生する通信量に応じた課金です。

課金モデル：オンデマンド・リザーブドインスタンス・Serverless

支払い方法は用途に合わせて選べます。要件が固まっていない検証段階ではオンデマンド、稼働が安定した長期運用ではリザーブドインスタンス、間欠的なワークロードではServerlessが向きます。

リザーブドインスタンスは、オンデマンドと機能は同じまま請求に割引が適用される仕組みで、1年または3年の期間と、前払い方式（全額前払い・一部前払い・前払いなし）を選択します。安定稼働するクラスターほど削減効果が見込めます。Serverlessは、処理能力をOCU（OpenSearch Compute Units）という単位で計測し、コンピューティングとストレージを個別に課金します。OCUはインデックス用と検索用に分かれ、トラフィックに応じて自動で増減するため、キャパシティ設計やスケーリングの手間を抑えられます。一方で、最小構成でも一定のOCUが常時確保されるぶんの課金が発生するため、ごく軽量で常時稼働させる用途ではマネージドクラスターのほうが割安になることもあります。突発的・間欠的なワークロードや、容量管理を任せて運用を簡素化したい場合にServerlessが向きます。

無料利用枠と料金シミュレーションの考え方

AWS無料利用枠では、エントリーレベルのt2.small.searchまたはt3.small.searchインスタンス（単一AZ）を月750時間まで、オプションのEBSストレージを月10GBまで無料で利用できます（新規アカウントの最初の12か月が対象）。また、各ドメインの自動スナップショットは14日間ぶん無料で保存されます。

概算する際は、「（インスタンス単価×台数×稼働時間）－無料枠」と「（ストレージ単価×総容量）－無料枠」を足し合わせる形で見積もります。たとえば小規模なテスト環境を複数台・常時稼働させると、無料枠を超えたぶんが課金対象になります。単価はリージョンやインスタンスタイプで異なり改定もあるため、必ず公式の料金ページで最新値を確認してください。

イメージをつかむために、概算例を示します（2026年6月時点・東京リージョンの一例。単価は改定されるため、実額は必ず公式の料金ページとPricing Calculatorで確認してください）。t3.small.searchを3台、各15GBのgp2ストレージで常時稼働させた場合、月の稼働時間は730時間×3台＝2,190時間です。ここから無料枠の750時間を引いた1,440時間がインスタンス課金の対象になり、ストレージは15GB×3台＝45GBから無料枠10GBを引いた35GBが課金対象です。仮にインスタンス単価を1時間あたり約0.056ドル、gp2ストレージ単価を1GBあたり約0.162ドルと置くと、概算は「1,440×0.056＋35×0.162」で月およそ86ドルとなります。あくまで条件を固定した一例で、実額はリージョン・構成・最新単価によって変わります。

注意点：OpenSearch Serviceのインスタンスは「停止」できず、起動している限り課金が続きます。検証で作成したドメインは使い終わったら削除し、想定外の課金を避けましょう。また、デプロイ構成によっては最小インスタンスの選択肢が変わることがあるため、無料枠を狙う場合は構成画面で対象インスタンスを選べるか確認します。

コストを抑える主なポイント

• ストレージ階層を使い分ける：アクセス頻度の低いログなどはUltraWarmやコールドストレージへ移すと、ホットストレージより大幅にコストを下げられます。状態遷移はISM（インデックス状態管理）で自動化できます。
• 新しい世代のリソースを選ぶ：最新世代インスタンスやgp3 EBSを選ぶと、同等以下のコストで性能を確保しやすくなります。
• ワークロードに合わせて選定する：検索中心ならメモリ最適化、インデックス処理中心ならコンピューティング最適化が目安です。Auto-Tuneで設定の一部を自動調整させることもできます。

Amazon OpenSearch Serviceの構築手順

導入は次の流れで進めます。いずれの手順もマネジメントコンソール、AWS CLI、APIから実行できます。

• 1. AWSアカウントとIAMの準備：リージョンを選び、IAMで必要な利用者だけがドメインにアクセスできるよう権限を設計します。
• 2. ドメインの作成：ドメイン名、インスタンスタイプ、ストレージ容量を指定します。可用性が必要な場合はマルチAZ、社内ネットワークに閉じる場合はVPCアクセスを選びます。保存時・転送時の暗号化と、きめ細かなアクセス制御（IAM＋Securityプラグイン）もここで設定します。
• 3. インデックスの作成：データの格納先となるインデックスを定義し、フィールドごとに型（マッピング）を設定します。検索精度とパフォーマンスはこの設計に大きく左右されます。
• 4. データ投入と検索：大量データはBulk APIでまとめて投入すると効率的です。検索は GET _search にクエリを送って実行し、match・range・boolなどを組み合わせて条件を表現します。

シャード数やレプリカ数は後からの拡張や可用性に影響するため、扱うデータ量を見積もったうえで決めるのが安全です。OpenSearchエンジン本体の最新バージョンで追加された機能を把握しておきたい場合は、OpenSearch 3.3で追加された主要な新機能とその概要を徹底解説 – 見逃せない最新アップデート情報も参考になります。

日本語検索の精度を高める（Kuromoji・Sudachi）

日本語は単語の区切りにスペースを使わないため、そのまま全文検索すると意図しない部分一致が増え、精度が落ちます。これを解決するのが形態素解析です。文章を意味のある単語単位に分割してインデックス化することで、検索クエリとの一致を正確に判定できます。

OpenSearchでは、プラグインを導入して日本語アナライザーを設定します。広く使われるのはKuromojiで、たとえばインデックス作成時に次のようなアナライザーを定義し、検索対象のフィールドに割り当てます（設定例）。

PUT japanese_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "ja_analyzer": {
          "type": "custom",
          "tokenizer": "kuromoji_tokenizer",
          "filter": ["kuromoji_baseform", "kuromoji_part_of_speech"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": { "type": "text", "analyzer": "ja_analyzer" }
    }
  }
}

# 動作確認：意図した単語単位に分割されるかを_analyzeで確かめる
GET japanese_index/_analyze
{
  "analyzer": "ja_analyzer",
  "text": "全文検索エンジンを構築する"
}

アナライザーは、上のように mappings でフィールド（この例ではtitle）に割り当てて初めて有効になります。設定後は _analyze API に文章を渡し、想定どおりの単語単位で分割されるかを確認してから本番運用に進むと安全です。より専門的な用語や表記ゆれに対応したい場合は、粒度を細かく制御できるSudachiを選ぶ方法もあります。読み仮名による表記ゆれ対策など、さらに踏み込んだ設定はkuromoji_readingformとは何か？OpenSearchでの役割と概要をわかりやすく解説で詳しく扱っています。検索時とインデックス時で同じアナライザーをそろえると、ミスマッチを防げます。

主なユースケース

Amazon OpenSearch Serviceは、用途の幅が広いのも特徴です。代表的な3つを紹介します。

• 全文検索：社内ドキュメントや商品データを登録し、サイト内検索やナレッジ検索を構築します。非構造化・半構造化データにも対応します。
• ログ分析・オブザーバビリティ：複数サービスのログをCloudWatch Logsなどから集約し、横断的に調査します。CloudWatch LogsとのゼロETL統合を使えば、データを別途エクスポートせずに分析できます。
• RAG（検索拡張生成）：ベクトル検索を活用し、生成AIの回答に社内データを反映させます。Amazon Bedrockと組み合わせる構成が一般的です。具体的な実装例はAmazon BedrockとAmazon Kendraを活用したRAGの実装方法を参照してください。

運用・スケーリングと可用性

本番運用では、安定稼働と監視の仕組みづくりが重要になります。スケーリングは自動と手動の両方に対応し、負荷の増減に合わせてインスタンス数やシャードを調整します。可用性を高めるには複数のアベイラビリティゾーンにノードを配置し、障害時に自動でフェイルオーバーする構成にします。

監視はCloudWatchと統合されており、CPU使用率・メモリ・ストレージ・クエリのレイテンシーなどを把握できます。閾値を超えた際のアラート設定や、定期的なスナップショット取得によるバックアップ体制も整えておくと安心です。シャードを過剰に分割するとオーバーヘッドが増えるため、データ量に見合った設計を心がけます。

よくある質問（FAQ）

OpenSearchとElasticsearchの違いは？

OpenSearchはElasticsearch 7.10系をフォークして生まれたオープンソース（Apache 2.0）の検索エンジンです。基本的な検索機能は共通する一方、開発主体やライセンス、最新機能の方向性が異なります。用途や必要な機能で比較して選びます。

Amazon OpenSearch Serviceと自前構築のOpenSearchはどう違う？

前者はAWSがクラスターの構築・パッチ適用・スケーリング・バックアップを担うフルマネージドサービスです。自前構築は自由度が高い反面、運用負荷とコスト管理を自分で持つ必要があります。

料金はどのくらい？無料で試せる？

料金はインスタンス時間・ストレージ・データ転送で決まります。無料利用枠でt2/t3.small.searchを月750時間、EBSを月10GBまで試せます。正確な金額は公式の料金ページとPricing Calculatorで確認してください。

マネージドクラスターとServerless、どちらを選ぶ？

稼働が安定し予測しやすいワークロードはマネージドクラスター（リザーブドインスタンスで割引）、トラフィックが間欠的でスケールを自動化したい場合はServerless（OCU課金）が向きます。

ブラウザの「OpenSearch」とは別物？

別物です。ブラウザの検索ボックスに使われる「OpenSearch記述仕様」と、本記事の検索・分析エンジン「OpenSearch」は名称が同じだけで用途は異なります。Amazon OpenSearch Serviceは後者を指します。より詳しくは、Logstashのgrokフィルターの記事で整理しています。

関連記事

• OpenSearch 3.0の全体像を理解するための概要と背景
• Elasticsearchとは何か：全文検索エンジンの概要と機能
• OpenSearch 3.3で追加された主要な新機能とその概要を徹底解説 – 見逃せない最新アップデート情報
• kuromoji_readingformとは何か？OpenSearchでの役割と概要をわかりやすく解説
• Amazon BedrockとAmazon Kendraを活用したRAGの実装方法