OpenSearchとは？OCI Search with OpenSearchをざっくり解説

この記事は、これからOpenSearchに触れる方に向けて、検索の仕組みとOCI Search with OpenSearchの役割を整理したものです。
環境構築の細かな手順ではなく、何をする技術なのか、データベースとどう使い分けるのか、OCIのマネージドサービスでは何が管理範囲なのかを整理しています。

ざっくりまとめ

• OpenSearch：大量の文書を検索し、集計や可視化もできるオープンソースのソフトウェア群
• OCI Search with OpenSearch：OpenSearchクラスターの構築やパッチ適用、サイズ変更、バックアップなどをOracleが担うマネージドサービス
• データベースとの関係：データベースを丸ごと置き換えるものではなく、検索しやすい形にしたデータを持たせて併用することが多い
• 向いている用途：Webサイトや業務アプリの検索、ログ分析、ダッシュボード、ベクトル検索やセマンティック検索
• OCIでの注意点：クラスターとOpenSearch DashboardsにはVCN内のプライベートエンドポイントから接続する

OpenSearchとは

Webサイトで商品を探す場面を考えてみます。
「ワイヤレス マウス」と入力したとき、商品名が完全に一致しなくても、検索語を含む商品や条件に近い商品を関連度の高い順に表示したくなります。

このような検索を実現するソフトウェアが検索エンジンです。

OpenSearchは、全文検索、ログ分析、集計、可視化、ベクトル検索などを扱えるオープンソースのソフトウェア群です。
検索処理を担うOpenSearchと、検索結果や集計結果を画面で確認するOpenSearch Dashboardsで構成されています。
OpenSearch Projectの公式ドキュメントでは、全文検索、アプリケーション監視、ログ分析、ベクトル検索が主な用途として挙げられています。

OpenSearchそのものは、OCIに限定された製品ではありません。
DockerやKubernetes、自社のサーバー、各クラウドのマネージドサービスなど、複数の方法で利用できます。

「検索エンジン」と聞くと、Google検索やYahoo!検索のようなWeb検索サービスを思い浮かべるかもしれません。
これらがインターネット上のWebページを検索するサービスなのに対し、OpenSearchは、商品、社内文書、ログなど、自分たちが登録したデータを検索するためのソフトウェアです。

Elasticsearchとの関係

OpenSearch ProjectのFAQによると、OpenSearchはApache License 2.0で公開されていたElasticsearch 7.10.2とKibana 7.10.2をもとに始まったプロジェクトです。
そのため、APIや考え方に共通点があります。

ただし、現在のOpenSearchとElasticsearchは別々に開発されている製品です。
OpenSearchのクライアント互換性に関する説明では、OpenSearch 2.0以降とElasticsearchクライアントには完全な互換性がないとされています。
新しく実装する場合はOpenSearch向けのクライアントを使います。

データベースの検索と何が違うのか

リレーショナルデータベースでも、完全一致、前方一致、LIKE、製品固有の全文検索機能などを利用できます。
データ量や検索条件が小さければ、それらで十分な場合もあります。

一方、検索機能に次のような要件が増えると、検索エンジンを分ける利点が出てきます。

• 全文検索：長い文章を単語に分けて検索する
• 関連度：一致した文書を検索語との近さで並べる
• 表記の処理：大文字と小文字、活用形、同義語などを考慮する
• 絞り込みと集計：カテゴリ、価格帯、期間などを組み合わせて集計する
• 分散処理：データと検索処理を複数のサーバーへ分ける

多くのシステムでは、データベースを正本として残し、検索に必要な項目をOpenSearchへ送ります。
OpenSearchは、検索用に整えたデータのコピーを持つ構成です。

この構成では、データベースからOpenSearchへの同期方法と、更新の遅延をどこまで許容するかを決める必要があります。
OpenSearchを導入すると検索は作りやすくなりますが、データ同期の設計は新たに必要です。

なぜ文章を速く検索できるのか

OpenSearchは、登録された文章から転置インデックスを作ります。

転置インデックスは、本の巻末にある索引に近い仕組みです。
本を最初のページから読み直す代わりに、「OpenSearch」という単語が何ページにあるかを索引から探します。

例えば、次の二つの商品説明を登録したとします。

• 文書1：「軽量なワイヤレスマウス」
• 文書2：「静音ワイヤレスキーボード」

単純化すると、OpenSearchは次のような対応を内部に持ちます。

単語	文書
軽量	文書1
ワイヤレス	文書1、文書2
マウス	文書1
静音	文書2
キーボード	文書2

「ワイヤレス マウス」で検索すると、OpenSearchは転置インデックスを使って候補を絞り、それぞれの文書へ関連度のスコアを付けます。
標準の関連度計算にはBM25というアルゴリズムが使われます。

Analyzerが文章を単語に分ける

文章を検索できる形へ変換する処理をテキスト分析と呼び、その処理を組み立てる機能がAnalyzerです。

Analyzerは、文章を単語に分割し、必要に応じて小文字化や不要語の除去などを行います。
登録時と検索時に同じ考え方で文章を処理することで、検索語と文書内の単語を照合できます。

日本語は英語のように単語が空白で区切られていません。
OCI Search with OpenSearchは日本語解析用のKuromojiプラグインをサポートしているため、日本語の単語分割を検索設計に組み込めます。

最初に知っておきたい用語

OpenSearchでは、データの単位と分散処理の単位で用語が分かれています。

用語	役割	データベースに寄せた見方
Document	JSON形式で登録する1件のデータ	1行のレコードに近い
Field	Document内の項目	列に近い
Index	関連するDocumentの集まり	テーブルに近い
Mapping	Fieldの型や検索方法の定義	スキーマに近い
Cluster	複数のNodeをまとめたOpenSearch環境	データベースシステム全体に近い
Node	データの保持や検索を担うサーバー	サーバーインスタンス
Shard	Indexを分割した単位	分散配置するデータ片
Replica	Shardの複製	冗長化用のコピー

データベースの「インデックス」とOpenSearchの「Index」は、同じ言葉でも指す範囲が異なります。
OpenSearchのIndexはDocumentのまとまりであり、リレーショナルデータベースのテーブルに近い単位です。

ShardとReplica

一つのIndexが大きくなると、一台のNodeだけでデータを保持して検索することが難しくなります。
OpenSearchはIndexをShardへ分割し、複数のNodeに配置します。

ReplicaはPrimary Shardの複製です。
Primary Shardとは別のNodeに配置することで、Node障害時の冗長性を持たせ、検索処理を分担できます。

Shardは多いほどよいわけではありません。
Shard自体もCPUとメモリを消費するため、データ量、更新量、検索量に合わせて設計します。

OpenSearchへデータを入れて検索する流れ

OpenSearchはREST APIで操作できます。
OpenSearch DashboardsのDev Toolsでは、次のような形式でAPIを試せます。
次の例では、商品を格納するproducts Indexを作り、日本語の商品名を登録して検索します。

1. Indexを作る

PUT /products
{
  "settings": {
    "analysis": {
      "analyzer": {
        "ja_analyzer": {
          "type": "custom",
          "tokenizer": "kuromoji_tokenizer"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "analyzer": "ja_analyzer"
      },
      "category": {
        "type": "keyword"
      },
      "price": {
        "type": "integer"
      }
    }
  }
}

ja_analyzerは、KuromojiのTokenizerで日本語を単語に分けるAnalyzerです。
textは全文検索する文字列、keywordはカテゴリ名のように完全一致や集計に使う文字列です。
同じ文字列でも、使い方によってFieldの型を分けます。

2. Documentを登録する

PUT /products/_doc/1
{
  "name": "軽量なワイヤレスマウス",
  "category": "周辺機器",
  "price": 4800
}

3. 検索する

GET /products/_search
{
  "query": {
    "match": {
      "name": "ワイヤレス マウス"
    }
  }
}

OpenSearchは一致したDocumentと関連度スコアをJSONで返します。
アプリケーションは、その結果を検索一覧として画面に表示します。

（上の例はAPIの形を示すために簡略化しています。）

（実際には認証情報、エンドポイント、Index設計、エラー処理なども必要です。）

OCI Search with OpenSearchとは

OpenSearchを自分で運用する場合、サーバーの準備、OpenSearchのインストール、クラスター構成、パッチ適用、バックアップ、監視などを自分たちで担います。

OCI Search with OpenSearchは、OpenSearchクラスターをOracle Cloud Infrastructure上で利用するためのマネージドサービスです。
Oracleの公式ドキュメントでは、セキュリティ更新、アップグレード、サイズ変更、定期バックアップなどがマネージドサービスの対象として挙げられています。

（以降のOCI側の仕様は、2026年8月時点の公式ドキュメントをもとにしています。）

一方、マネージドサービスでも次の作業は利用者側に残ります。

• データ設計：どのデータをDocumentとして登録するか
• 検索設計：Mapping、Analyzer、検索条件、並び順をどうするか
• データ連携：データベースやログからOpenSearchへどう送るか
• アクセス設計：VCN、セキュリティルール、ユーザー、ロールをどう構成するか
• 容量設計：Node数、OCPU、メモリ、ストレージをどの程度用意するか

「OpenSearchの運用をすべて考えなくてよいサービス」ではなく、基盤運用の一部をOracleに任せられるサービスです。

OCI上の構成

OCI Search with OpenSearchでは、複数のNodeでClusterを構成します。
初心者が最初に押さえるNodeは次の三種類です。

Node	役割
Data Node	DocumentとShardを保持し、登録、検索、集計を処理する
Leader Node	Clusterの状態を管理し、Index作成などCluster全体の処理を調整する
OpenSearch Dashboard Node	OpenSearch Dashboardsの画面を提供する

OpenSearch一般のドキュメントでは、Cluster全体を管理する役割をCluster Managerと呼びます。
OCIの設定画面やドキュメントではLeader Nodeという名前で表されています。

大きなClusterや機械学習を使う構成では、Coordinator Node、Search Node、Machine Learning Nodeなども追加できます。
最初からすべてのNodeを使うのではなく、処理量と用途に応じて構成します。

VCN内のプライベートエンドポイントから接続する

OCI Search with OpenSearchは、OpenSearch APIとOpenSearch Dashboardsをプライベートエンドポイントで提供します。
通信はインターネットを経由せず、Clusterを作成したVCN内からアクセスします。

そのため、Clusterを作成しても、手元のPCからOpenSearch DashboardsのURLを直接開けるとは限りません。
同じVCN内のCompute Instanceから接続する、踏み台VM経由でポートフォワーディングする、外部公開が必要ならAPI Gatewayなどを組み合わせる、といった接続経路を用意します。

VCNのSecurity ListまたはNetwork Security Groupには、OpenSearch APIとOpenSearch Dashboardsへ到達するためのルールも必要です。
接続できない場合は、ユーザー名とパスワードだけではなく、名前解決、経路、ポート、セキュリティルールを順番に確認します。

OCI IAMとOpenSearchの権限を分けて考える

権限は、OCIリソースの管理とOpenSearch内のデータ操作に分けて考えると整理しやすくなります。

• OCI側の権限：誰がClusterを作成、変更、削除できるかをIAM Policyで制御する
• OpenSearch側の権限：誰がどのIndexやDocumentを検索、登録、更新できるかをOpenSearchのRole-Based Access Controlで制御する
• ネットワーク側の制御：どの通信元がプライベートエンドポイントへ到達できるかをVCNのルールで制御する

OCIコンソールでClusterを作成できる権限と、OpenSearch APIでDocumentを検索できる権限は同じものではありません。

バックアップとサイズ変更

OCI Search with OpenSearchは、Clusterのバックアップを自動で毎日作成し、14日間保持します。
変更前などに手動バックアップを作ることもできます。

NodeのOCPUやメモリを変える垂直方向のサイズ変更と、Nodeを追加する水平方向のサイズ変更にも対応しています。
水平方向のサイズ変更でNode数を減らすことはできず、Data Nodeのストレージも増加だけが可能です。
ただし、サイズ変更やパッチ適用中は検索機能が読み取り専用となり、書き込みが一時的に無効になる場合があります。

バックアップがあることと、必要な復旧時間を満たせることは別です。
本番利用では、復元手順と所要時間も確認します。

マネージドサービスでも利用料は発生する

OCI Search with OpenSearchは、検索リクエストがないときに自動でゼロ台になるサーバーレスサービスではありません。
Clusterを作成すると、NodeのOCPU、メモリ、ストレージなど、プロビジョニングした基盤の料金が発生します。

Oracleの料金ページによると、Data Nodeが二台までの構成ではプロビジョニングした基盤に対して課金され、三台以上の高可用性構成では管理料金も加わります。
実際の見積もりでは、選択するNode構成をOCI Cost Estimatorへ入力して確認します。

OCI Searchとは別のサービス

OCIにはSearchという別のサービスもあります。
こちらは、Tenancy内のOCIリソース、コンソールのページ、Oracleのドキュメントなどを探すための機能です。

アプリケーションの商品検索やログ分析に使うのはOCI Search with OpenSearchです。
OCI上で作成したCompute InstanceやBlock Volumeをコンソールから探すのはOCI Searchです。

サービス	探すもの
OCI Search with OpenSearch	アプリケーションの文書、商品、ログなど、利用者が登録したデータ
OCI Search	Tenancy内のOCIリソース、コンソールのページ、ドキュメントなど

OpenSearchが向いているケース

OpenSearchは、検索や集計をアプリケーションの主要機能として作る場合に向いています。

• サイト内検索：商品、記事、FAQ、社内文書などを全文検索する
• ログ分析：大量のログを期間や項目で絞り込み、異常の調査に使う
• 検索結果の調整：関連度、同義語、Fieldごとの重みを調整する
• 可視化：OpenSearch Dashboardsで検索結果や集計結果をグラフにする
• セマンティック検索：文章の意味をベクトルで表し、キーワードが完全一致しない文書も探す

OCI Search with OpenSearchは、OpenSearch 2.11以降でセマンティック検索をサポートしています。
モデルをClusterへ登録して埋め込みを生成する方法に加え、OCI Generative AIなどの推論先と接続する構成も選べます。

OpenSearchを急いで選ばなくてもよいケース

検索要件が小さければ、利用中のデータベースだけで構成した方が単純です。

• 検索条件が単純：IDの完全一致や少数項目の前方一致で足りる
• データ量が小さい：現在のデータベースで応答時間の要件を満たしている
• 即時整合性が必要：更新直後に必ず同じ内容を検索結果へ反映する必要がある
• トランザクションが中心：在庫の引き当てや決済のような整合性を伴う更新が中心である
• 運用対象を増やせない：データ同期、Index設計、Cluster監視を継続して担当できない

OpenSearchはトランザクションデータベースの代わりではありません。
検索用データを別に持つ効果が、データ同期とCluster運用の追加分を上回るかで判断します。

OCIで使い始めるときの流れ

環境構築へ進む場合は、次の順番で考えると作業を分けやすくなります。

1. 検索対象と検索条件を決める
2. 元データを保持するデータベースやObject Storageを決める
3. VCN、Subnet、IAM Policy、セキュリティルールを用意する
4. OCI Search with OpenSearchのClusterを作成する
5. MappingとAnalyzerを定義する
6. Documentを登録して検索APIを試す
7. アプリケーションからの同期、監視、バックアップ復元を確認する

OCIで選択できるOpenSearchのバージョンやプラグインは更新されます。
構築時には、コンソールに表示されるバージョンと公式のSupported Pluginsページを確認します。

よくある疑問

OpenSearch DashboardsがOpenSearch本体ですか

OpenSearch本体はデータの登録、検索、集計を行うエンジンです。
OpenSearch Dashboardsは、そのデータを検索、可視化、管理するためのWeb画面です。
アプリケーションはDashboardsを経由せず、OpenSearch APIを直接呼び出せます。

OpenSearchにJSONを入れれば自動でよい検索になりますか

JSONを登録すれば検索はできますが、業務に合う結果になるとは限りません。
Fieldの型、Analyzer、同義語、関連度、Shard数などを検索要件に合わせて調整します。

OCIのマネージドサービスなら運用は不要ですか

OracleがCluster基盤の管理を担いますが、データ連携、検索品質、アクセス権、容量、コストの管理は利用者側に残ります。
Cluster Metricsを監視し、実際のデータ量と検索量に合わせて構成を見直します。

RAGのベクトルデータベースとして使えますか

OpenSearchはベクトル検索とキーワード検索を組み合わせられるため、RAGの検索部分に利用できます。
ただし、文書分割、埋め込みモデル、検索方法、再ランキングなどは別途設計が必要です。

まとめ

OpenSearchは、JSON形式のDocumentをIndexへ登録し、転置インデックスやベクトルを使って検索、集計するソフトウェア群です。
データベースを置き換えるのではなく、検索しやすい形にしたデータを別に持たせて使う構成が一般的です。

OCI Search with OpenSearchを使うと、クラスターのセキュリティ更新、アップグレード、サイズ変更、バックアップなどをOracleに任せられます。
一方で、Mapping、Analyzer、データ同期、ネットワーク、権限、容量は利用者が設計します。

検索対象と期待する検索結果を小さなデータで確かめてからCluster構成を決めると、必要な機能と運用負荷を比べやすくなります。
OpenSearchとOCI Search with OpenSearchを検討する際の参考になれば嬉しいです。

参考

• OpenSearch and OpenSearch Dashboards（OpenSearch Project）
• Introduction to OpenSearch（OpenSearch Project）
• Text analysis（OpenSearch Project）
• OpenSearch language clients（OpenSearch Project）
• About Search with OpenSearch（Oracle）
• Connecting to a Search with OpenSearch Cluster（Oracle）
• Search with OpenSearch Automated Cluster Backups（Oracle）
• Search with OpenSearch Supported Plugins（Oracle）
• Semantic Search in Search with OpenSearch（Oracle）
• Resizing a Search with OpenSearch Cluster（Oracle）
• Search with OpenSearch Pricing（Oracle）
• Overview of Search（Oracle）