OCI Search with OpenSearch実践Vol1 課金構造とRAG基盤

1. この記事について — なぜOCI Search with OpenSearchか

1-1. 本記事のゴール

本記事は、OCI Search with OpenSearchを対象に、料金体系の正確な理解からクラスター構築、検索実践、そしてRAG(検索拡張生成)基盤への発展までを一気通貫で扱います。読み終えた時点で、最小構成クラスターをサービス料$0で構築・運用でき、AWS OpenSearch Serviceとの課金構造の違いを説明できる状態を目指します。あわせて、GenAI Vol1で扱った埋め込みベクトルをOpenSearchのk-NNインデックスへ格納し、RAG基盤の設計に発展させる道筋も示します。

本記事で扱う範囲は、クラスターの作成・基本的な検索操作・ベクトル検索基盤としての設計整理までです。個々のQuery DSLの網羅的な解説、クラスターのパフォーマンスチューニング、本番運用でのスケーリング設計といった深掘りは範囲外とし、まずOCI固有の課金構造と構成の勘所を押さえることを優先します。

読了後には、次の状態に到達していることを目指します。

• サービス料が発生する条件(データノード3台目から)を、公式の価格表に基づいて他者に説明できる
• Leader・Data・Dashboardの最小構成クラスターを、サービス料$0のまま自分で作成できる
• AWS OpenSearch Service/Serverlessとの課金モデル・マネージド範囲の違いを整理できる
• GenAI Vol1の埋め込みベクトルをOpenSearchのk-NNインデックスへ格納する設計の全体像を説明できる

1-2. 読者像

想定する読者は、次のいずれかに該当する方です。

• AWS OpenSearch Service/Serverlessの運用経験があり、OCI版の課金構造・マネージド範囲の違いを知りたいAWSエンジニア
• 検索基盤やベクトル検索を使ったRAG構築を検討しており、OCI上での実装方法を探している方
• OCI Generative AIサービス(Vol1)を既に試しており、埋め込みベクトルの保存先としてOpenSearchを検討している方
• 自社のログ・検索基盤をOpenSearch互換のマネージドサービスへ移行する際、OCI版の設計上の制約を事前に把握しておきたい方
• Terraform等のIaCでOCIインフラを管理しており、OpenSearchクラスターもコード化を見据えて事前に構成要素を把握しておきたい方

Elasticsearch/OpenSearchの基本的な用語(インデックス・ドキュメント・シャードなど)は既知の前提で進めます。個々のQuery DSLの文法やクラスターチューニングの詳細までは扱わず、OCI固有の課金・構成・運用の勘所に絞って解説します。

ハンズオンを実際に試す場合は、OCIテナンシへのアクセス権限(対象コンパートメントでのOpenSearchクラスター作成権限を含むIAMポリシー)と、クラスターを配置するVCNの準備(既存VCNの利用または新規作成)が前提になります。詳細な権限設計は§3で扱います。

1-3. OCI Search with OpenSearchとは

OCI Search with OpenSearchは、オープンソースの検索・分析エンジンであるOpenSearchを、OCI上でフルマネージドに提供するサービスです。クラスターの作成・ノードの追加・OpenSearch Dashboardsの提供までをOCI側が管理し、利用者はインデックス設計やクエリの実装に集中できます。全文検索・ログ分析・オブザーバビリティ用途に加え、2.19以降にバンドルされたk-NN・ML Commons・Neural Searchの各プラグインにより、ベクトル検索・RAG基盤としての利用も可能になっています。

Amazon OpenSearch Serviceと同様、クラスターは複数のノードから構成されますが、OCI版はLeader・Data・Dashboard・Search・Coordinator・MLという6種類のノード種別を個別に選択して組み合わせる設計になっている点が特徴です。用途に応じて必要なノード種別だけを追加できる柔軟性がある一方、後述の通り最小メモリ要件がノード種別ごとに決まっているため、構成の自由度と最小実費のバランスを理解したうえで設計する必要があります。

代表的なユースケースとしては、アプリケーションログ・インフラログの集約分析、アプリケーション内検索(商品検索・ドキュメント検索など)、そして本記事の§5で扱うベクトル検索によるRAG基盤の3つが挙げられます。いずれも、AWS OpenSearch Serviceで同様のユースケースを扱った経験があれば、設計の考え方自体はそのまま応用できます。

1-4. なぜ今これを書くか — 課金構造の正確な理解がボトルネックになりやすい

OCI Search with OpenSearchの料金体系は、一見すると「インフラ実費+サービス料」という単純な2階建てに見えますが、サービス料が発生する条件(何台目のデータノードから発生するか、その単位はクラスター単位かテナンシ単位か)を正確に把握していないと、想定外の課金や、逆に過度な出し惜しみによる構成劣化を招きます。本記事では、可観測性発展編で確立した「価格表を直接読む」という方法論をそのまま適用し、サービス料の免除条件を一次情報をもとに確認したうえで、AWS OpenSearch Serviceの課金モデルとの対比を整理します。

また、OCI Search with OpenSearchは、Leader・Dataの各ノードが最小20GBのメモリを要求するという、他のOCIマネージドサービスと比べてインフラ実費の敷居がやや高いサービスでもあります。「最小構成なら少額で検証できる」という思い込みのまま構築すると想定より重い請求につながりかねないため、§2で最小構成の実費規模を先に押さえたうえでハンズオンに進む構成としています。

サービス料の境界線を誤解した場合の影響も無視できません。たとえば検証用途で気軽にデータノードを3台・4台と増やしてしまうと、3台目以降の1台ごとに$0.25/時間のサービス料が積み上がります。24時間稼働させたまま放置すれば、月単位では決して小さくない金額になります。逆に「サービス料が怖いから」とデータノード数を必要以上に絞ると、検索性能や可用性を犠牲にしてしまいます。境界線(3台目から発生・最初の2台は無料)を正確に知っておくことが、コストと性能のバランスを取るための出発点になります。

1-5. 用語整理

本記事で扱うOCI Search with OpenSearchは、OpenSearch(Elasticsearchからフォークしたオープンソースの検索・分析エンジン)をOCI上でマネージドサービスとして提供するものです。AWSでの対応サービスはAmazon OpenSearch Service(旧Amazon Elasticsearch Service)およびAmazon OpenSearch Serverlessにあたります。クラスターは、Leader(旧称Master)・Data・Dashboard・Search・Coordinator・MLという6種類のノードから構成され、用途に応じて必要なノード種別のみを組み合わせます。

各ノードの役割を簡単に整理すると、Leaderはクラスター全体の状態管理、Dataはインデックスデータの保持と検索処理の実行、Dashboardは可視化UIの提供、Searchは検索専用の読み取り処理の分離、Coordinatorはリクエストの振り分け、MLはML Commonsプラグインによるモデル実行を担います。最小構成ではLeader・Data・Dashboardの3種類があれば動作し、Search・Coordinator・MLは負荷や用途に応じて後から追加するオプション扱いです。詳細な最小メモリ要件は§2-2で表にまとめます。

なお「OCI Search」という名称は、キーワード検索専用の別サービス(全文検索インデックスをオブジェクトに付与するタグ検索的な機能)と混同されがちですが、本記事で扱うのはOpenSearchエンジンをそのままマネージドで提供する「Search with OpenSearch」です。名称に惑わされず、Console上のサービス名「Search with OpenSearch」で識別してください。

AWS OpenSearch Serviceの用語に慣れている読者向けに、代表的な概念の対応関係を整理します。

コマンド体系・REST APIは標準のOpenSearchに準拠しているため、AWS側で書いたQuery DSLやインデックス定義は、OCI側でもほぼそのまま利用できます。相違点は主に、クラスターの構成単位(ノード種別の分け方)と課金モデルにあります。

1-6. シリーズでの位置づけ

本記事は「OCI Search with OpenSearch実践」シリーズのVol1として、単体で完結する内容です。ただし、GenAI Vol1(埋め込み・RAG)、Cache実践Vol1(Valkey・valkey-search)という既刊2本と、RAG基盤設計という文脈で結線しています。OCIのRAG関連サービスを俯瞰したい場合は、GenAI Vol1→本記事→Cache実践Vol1の順に読むと、マネージドRAG(GenAI Agents)・自前構成RAG(OpenSearch k-NN)・キャッシュ層でのベクトル検索(valkey-search)という3つの選択肢を一通り把握できます。

Vol2以降では、本記事で扱いきれなかった検索性能チューニングやハイブリッド検索の実装詳細を扱う可能性がありますが、本記事執筆時点では確定していません。まずはVol1として、課金構造の理解とハンズオンの土台を固めることを優先します。

シリーズ名は「OCI Search with OpenSearch実践」で統一し、Vol番号を追って積み上げていく方針です。既刊のOCI入門シリーズ・各サービス実践シリーズと同様、単体記事として読んでも理解できる自己完結性を維持しつつ、関連記事へのリンクで文脈を補強する構成としています。

既刊2本との関係を整理すると、次のようになります。

1-7. 差別化軸

検索・OpenSearch関連の解説記事は世の中に数多くありますが、OCI版に限定し、かつ課金構造とAWSとの対比を正面から扱ったものはまだ少ない状況です。本記事は、次の4軸で既存の解説記事と差別化します。

1. 課金構造の正確な整理: インフラ実費パススルーとサービス料(3データノード目から発生・最初の2台は免除)という構造を一次情報をもとに正面から扱います
2. AWS OpenSearch Service/Serverless対比: マネージド範囲・課金モデル・バージョン追随を実務者視点で対比します
3. RAG基盤への発展: GenAI Vol1の埋め込み→OpenSearch k-NN→RAG構成というOCI内完結のE2E設計を示します
4. クラスター設計の体系化: ノード種別6種・最小メモリ・既定制限・バージョン戦略を整理します

これら4軸のいずれも、公式ドキュメント・価格表を一次情報として確認したうえで整理しており、独自の推測や未確認の数値は含めていません。

1-8. 本記事で押さえるべき前提を先取りする

本文を読む前に、後続の章で扱う3つの前提を先取りして示します。

• 課金の境界線: サービス料が発生するのはデータノードが3台以上の場合のみで、Leader・Dashboard等の他ノード種別には発生しません。2台までの構成であれば、インフラ実費のみでサービス料は一切かかりません(§2-3で詳述)
• 最小構成の重さ: Leader・Dataはいずれも最小20GBのメモリが必要で、他のOCIマネージドサービスの最小構成より実費が重くなりがちです。「最小構成=低コスト」という単純な図式が必ずしも成り立たない点は、事前に押さえておく価値があります(§2-2・§2-4で詳述)
• バージョン追随の速さ: OpenSearch 3.6.0(Current)まで対応済みで、アップグレードは一度に1メジャーバージョンのみ進められるインライン方式です。ロールバックはできないため、本番適用前に検証環境での動作確認が推奨されます(§2-1で詳述)

これら3点を押さえたうえで§2に進むと、料金体系の理解がスムーズになります。

→ OCI Generative AIサービス実践Vol1(埋め込み・RAGの前提知識)を読む

続く§2では、サービス料の免除条件を一次情報で確認しながら、料金体系全体を整理します。

2. サービス仕様と料金 — 実費パススルー+サービス料免除構造を先に知る

2-1. 提供リージョンとバージョン対応

OCI Search with OpenSearchは、公式ドキュメントで「Oracle Cloud Infrastructureの全ての商用リージョンで利用可能」と明記されており、東京・大阪の両リージョンでGA提供されています。GenAI Vol1のように「東京は非対応で大阪限定」という制約はなく、日本国内2リージョンのどちらでも利用できる点は、GenAI Vol1との明確な違いです。

対応バージョンは、執筆時点(2026年8月)でOpenSearch 3.6.0(2026年6月1日GA・Current)が最新です。3.2.0(2025年8月19日GA・Current)を含め、2.11.0・2.15.0・2.18.0・2.19.1・3.2.0・3.6.0が並行してサポート対象になっています。1.0系(1.2.4)は2026年1月廃止予定のDeprecatedフェーズ、2.0系はOpenSearch 4.0のGA時点で終了予定のMaintenanceフェーズにあり、2.x系を使い続けている場合は3.x系への移行を早めに検討する価値があります。アップグレードは一度に1メジャーバージョンのみ進められるインライン方式です。可観測性発展編で確立した方法論と同様、GAから間もない機能はdocs本体を正として都度最新化する規律で臨みます。

OpenSearchはオープンソースプロジェクトとして活発にリリースが続いており、OCI側もそれに追随する形で数ヶ月おきに新しいメジャー・マイナーバージョンのサポートを追加しています。裏を返せば、本記事に記載したバージョン情報は執筆時点のスナップショットであり、実際にクラスターを作成する際は、コンソールのバージョン選択画面またはOCI CLIのoci opensearch cluster list-versionsコマンドで、その時点の最新対応バージョンを確認することを推奨します。

近年のバージョンアップでは、ベクトル検索の改善やAI駆動型検索機能の強化が続いています。3.6.0のリリースノートでは、ベクトル検索の改善やエージェント関連機能への言及があり、§5で扱うk-NN・ML Commonsを使ったRAG基盤の実装可能性は、バージョンが進むごとに広がっている状況です。最新のAI/ML関連機能の詳細は、アップグレード前に該当バージョンのリリースノートを確認することをお勧めします。

2-2. ノード種別6種と最小メモリ

クラスターは、用途に応じて最大6種類のノードを組み合わせて構成します。それぞれの最小メモリ・OCPU要件は以下の通りです。

ノード種別ごとに用途が明確に分離されている設計は、AWS OpenSearch Serviceのインスタンスタイプ選択(汎用的な1種類のインスタンスに複数の役割を持たせる場合が多い)とは異なるアプローチであり、OCI版ならではの特徴と言えます。

Leader・Data・Dashboardは「1台以上」が前提となる基本構成で、Search・Coordinator・MLは任意追加のノードです。ここで重要なのは、Leader・Dataともに最小20GBのメモリが必要な点です。他のOCIサービス(たとえばOCI Cacheの最小構成2GB)と比べると、OpenSearchクラスターは最小構成でもインフラ実費がそれなりに発生する設計です。

各ノード種別は、OCPUとメモリの比率を一定の範囲内で自由に選べるフレキシブルシェイプの考え方に近く、最大で1024GB・32 OCPU(Searchノードは最大126 OCPU)まで拡張できます。検証段階では各ノード種別の最小値に寄せ、本番運用で負荷に応じてスケールアップしていく設計が現実的です。

Search・Coordinator・MLの各ノードは、いずれも0台から追加できるオプション構成です。Searchノードはデータノード数の20〜40%程度を目安に追加すると、検索専用の読み取り処理をDataノードから分離でき、書き込み処理への影響を抑えられます。Coordinatorはリクエストの振り分け専任、MLはML Commonsプラグインによるモデル実行専任のノードで、いずれも大規模運用や高度なML機能を使う段階になってから追加を検討すれば十分です。ハンズオン(§3)では、これら3種類は追加せず、Leader・Data・Dashboardの最小構成のみで進めます。

3種類のオプションノードのうち、本記事のRAGユースケース(§5)と特に関係が深いのはMLノードです。ML Commonsプラグインの実行専用ノードを分離できるため、埋め込み生成やモデル推論の負荷を検索処理から切り離して設計できます。本記事のVol1では最小構成での検証にとどめますが、RAG基盤を本格的に運用する段階では、MLノードの追加を検討する価値があります。

2-3. 料金体系 — インフラ実費パススルーとサービス料の2階建て

課金体系を理解するうえでまず押さえるべきは、OCI Search with OpenSearchが「インフラ実費」と「サービス料」という性質の異なる2つの費用要素を組み合わせて請求される点です。この2階建て構造そのものは、他のOCIマネージドサービス(たとえばOCI Cacheのメモリ課金や、GenAI Vol1のon-demand従量課金)とは異なる、本サービス固有の設計です。

OCI Search with OpenSearchの課金は、次の2つの要素で構成されます。

1. インフラ実費パススルー: クラスターが消費するコンピュート・メモリ・ブロックボリューム・オブジェクトストレージの実費を、上乗せなしでそのまま請求する方式です
2. サービス料: データノード1台あたり$0.25/時間(SKU: B93709)。ただし、クラスターあたり最初の2台のデータノードはサービス料が免除され、3台目以降のデータノードにのみ課金されます

たとえばデータノードが3台の場合、サービス料が発生するのは3台目の1台分のみで、$0.25/クラスター時間の請求となります。データノードが1〜2台であれば、サービス料は一切発生しません。Leader・Dashboード・Search・Coordinator・MLの各ノードはサービス料の算定対象外で、インフラ実費のみが発生します。

この設計は、検証・小規模運用ではコストを抑えつつ、本番規模でスケールする際には応分の負担を求めるという、段階的な料金体系になっています。運用初期はデータノード2台で始め、検索負荷やデータ量の増加に応じて3台目以降を追加していく、という段階的なスケール戦略が、コスト予見性の観点でも合理的です。

この段階的な料金体系は、スタートアップやPoC(概念実証)段階のプロジェクトにとって特に相性が良い設計です。初期投資を抑えつつ検証を進め、本番移行が確定した段階でノード数を増やしていく、という進め方がそのままコスト構造に反映されます。

2-4. 最小構成のインフラ実費試算

サービス料$0を維持したまま検証可能な最小構成は、Leader 1台(20GB)+Data 2台(20GB×2)+Dashboard 1台(8GB)の合計4ノード・68GBです。他のTier記事で扱った最小構成(数GB規模)と比べるとメモリ要求が大きく、インフラ実費も相応に発生します。正確な実費は、作成時にコンソール上で選択したシェイプ(OCPU/メモリの比率)とリージョンの実費レートに応じて変動するため、本記事では「Leader・Data・Dashboardの3種類で計68GBのメモリを確保する構成である」という設計値の提示にとどめ、断定的な金額は記載しません。検証前に、選択したシェイプでのコンピュート・ブロックボリュームの実費レートをコンソールまたは価格見積りツールで確認することを推奨します。

Dashboardノードの最小メモリがLeader・Dataより小さい8GBに設定されているのは、Dashboardノードが検索処理そのものではなく、UI(可視化・クエリ実行画面)の提供に特化しているためと考えられます。インフラ実費を抑えたい場合、Dashboardノードのメモリを最小の8GBに固定し、Leader・Dataの方は検索負荷を見ながら調整するという配分が現実的です。この配分方針は、AWS OpenSearch Serviceでダッシュボード専用の軽量インスタンスを選ぶ考え方とも近く、AWS運用経験者であれば違和感なく適用できるはずです。

なお、インフラ実費にはコンピュート・メモリに加えて、ブロックボリューム(インデックスデータの永続化用ストレージ)の実費も含まれます。ブロックボリュームの容量は、投入するデータ量に応じて別途設計が必要です。本記事のハンズオンでは検証用の少量データを扱う想定のため、詳細なストレージ容量設計には立ち入りません。

参考までに、Leader 1台+Data 2台+Dashboard 1台という最小構成の合計メモリ68GBは、一般的なノートPC数台分に相当する規模です。検証目的とはいえ、決して「お試し感覚」で放置してよい規模ではないという点は、あらためて強調しておきます。

2-5. AWS OpenSearch Service/Serverlessとの対比

Serverlessの最大の特徴は自動スケールで、負荷の変動が大きく読めないワークロードに向いています。一方、OCI Search with OpenSearchとAWS OpenSearch Serviceは、ともにノード数・インスタンス数を利用者側で設計する準マネージド型であり、負荷が安定しているワークロードや、コストの予見性を重視する場合に向いています。本記事のハンズオンは、この準マネージド型の構成を前提に進めます。

AWS側の金額は執筆時点の一般的な米国リージョンの目安値であり、東京リージョン(ap-northeast-1)個別の単価は変動するため、実際の比較にはAWS Pricing Calculatorでの最新値確認を推奨します。両者に共通するのは、小規模構成であれば無償に近い形で検証できる余地がある一方、本番規模ではノード数・インスタンス数に比例してコストが線形に増える点です。OCI側の優位点は、最初の2データノードまでサービス料が発生しない設計により、小〜中規模構成でのコスト予見性が高いことにあります。

コミットメント割引の有無にも違いがあります。AWS OpenSearch Serviceには、リザーブドインスタンスやSavings Plansといった長期コミットメント型の割引制度が用意されており、本番運用で確定的な負荷が見込める場合はコスト最適化の余地があります。一方、OCI Search with OpenSearchについては、本記事執筆時点でこうした専用のコミットメント割引の存在は確認できていません。OCI側でコストを抑えたい場合は、コミットメント割引ではなく、データノード2台までのサービス料免除という構造そのものを設計の起点にするアプローチが現実的です。

2-6. Always Freeの対象外であることに注意

OCI Search with OpenSearchは、Always Free枠の対象サービス一覧には掲載されていません。ただし、可観測性発展編で確立した教訓の通り、「Always Free一覧に掲載がない」ことは「無料枠が一切ない」ことを意味しません。本サービスの場合、Always Freeという形の無料枠はありませんが、前述の「最初の2データノードのサービス料免除」という別形態の費用抑制構造が存在します。価格表本体を確認せずに一覧表の掲載有無だけで判断しないよう注意してください。

2-7. サービス料試算の具体例 — データノード数別の月額

§2-3で整理した境界線を踏まえ、サービス料($0.25/データノード/時間)を1ヶ月(730時間換算)でデータノード数別に試算すると、次のようになります。実際の請求額は稼働時間に比例するため、検証期間が短ければ、この試算額よりも小さくなります。

この試算はサービス料のみで、インフラ実費(コンピュート・メモリ・ブロックボリューム)は別途加算される点に注意してください。データノードを1台増やすごとに、サービス料自体は台数に比例して線形に増える一方、最初の2台は常に無料という設計になっているため、小規模な検証環境では実質的にサービス料の心配をする必要がありません。

年単位で見ると、データノード5台構成の場合、サービス料だけで年間約$6,570(3台×$0.25×24時間×365日)の規模になります。本番規模でデータノードを増やす計画がある場合は、インフラ実費とあわせてサービス料も年間コストの試算に必ず含めてください。

2-8. バージョンアップグレード運用の注意点

OCI Search with OpenSearchのアップグレードは、一度に1メジャーバージョンのみ進められるインライン方式です。2.x系内(2.11.0→2.15.0→2.18.0→2.19.1のようなマイナー更新)はインラインで追随できますが、2.x系から3.x系へはメジャーバージョンを跨ぐため、間の3.xメジャーバージョンを順番に経由する必要があります。運用中のクラスターでバージョンを大きく上げたい場合は、複数回のアップグレード作業が必要になる点を計画段階で見込んでおく必要があります。

また、アップグレード後のロールバックはできないため、本番クラスターへ適用する前に、検証環境相当のクラスターで動作確認を行うことが推奨されます。特に、利用しているプラグイン(k-NN・ML Commons・Neural Searchなど)やクライアントライブラリが、アップグレード後のバージョンに対応しているかを事前に確認しておくと安全です。

複数バージョンを飛び越えてアップグレードする計画を立てる際は、各メジャーバージョン間の互換性の変更点(非推奨APIの削除・デフォルト設定の変更など)を、経由するバージョンごとにリリースノートで確認しておくと、想定外の破壊的変更に気付きやすくなります。

2-9. 料金の実務確認方法

本記事で示した金額(サービス料$0.25/hr・SKU B93709)は執筆時点(2026年8月)の価格表に基づく値です。OCIの価格は改定されることがあるため、実際に構築する際は、OCIコンソールのコスト見積りツールまたは公式の価格表(Price List)で最新の単価を確認することを推奨します。可観測性発展編で確立した「一覧表の掲載有無だけで判断せず、価格表本体を直接確認する」という方法論を、ここでも徹底しています。

2-10. コスト管理の実務Tips — Budgetsでの予算アラート

検証中にデータノードを増やしすぎてサービス料が発生し続けたり、Leader・Data・Dashboardの実費が想定より膨らんだりする事態を防ぐには、OCIのBudgets機能を使った予算アラートの設定が有効です。コンパートメント単位で月次予算としきい値(たとえば予算の50%・80%・100%)を設定しておくと、閾値超過時にメール通知を受け取れます。OpenSearchクラスター専用のコンパートメントを切り出しておけば、他のワークロードのコストと混ざらず、クラスター単体のコスト推移を追いやすくなります。

2-11. 検証環境でのクリーンアップ運用

検証目的でクラスターを作成した場合、確認作業が終わったら速やかにクラスターを削除することが、インフラ実費・サービス料の両方を抑えるうえで重要です。クラスターは作成後、明示的に削除するまで稼働し続け、稼働時間に応じてインフラ実費が発生し続けます。検証セッションの終わりに削除する運用ルールをあらかじめ決めておくと、消し忘れによる想定外の請求を防げます。この点は§6の落とし穴チェックリストでも改めて触れます。

2-12. 料金体系のよくある誤解 Q&A

料金体系の理解を確実にするため、よくある誤解をQ&A形式で整理します。

Q. サービス料はテナンシ全体でデータノードを合計して判定されますか?
A. いいえ。免除される「最初の2台」はクラスター単位で判定されます。テナンシ内に複数クラスターがある場合、各クラスターでそれぞれ2台まで無料です。

Q. Leaderノードを3台に増やすとサービス料が発生しますか?
A. いいえ。サービス料の算定対象はDataノードのみです。Leader・Dashboard・Search・Coordinator・MLの各ノードは、台数にかかわらずサービス料は発生しません。

Q. Always Free枠で無料利用できますか?
A. いいえ。OCI Search with OpenSearchはAlways Free対象外です。ただし、データノード2台までのサービス料免除という別形態の費用抑制構造があります(§2-6)。

Q. サービス料はリージョンによって異なりますか?
A. 本記事執筆時点で、東京・大阪リージョン間でのサービス料の単価差は確認できていません。実際に構築する際は、コンソールの見積り画面で対象リージョンの単価を確認してください。

Q. Dashboardノードを追加すると、そのぶんサービス料が増えますか?
A. いいえ。サービス料の算定対象はDataノードのみのため、Dashboardノードを何台追加してもサービス料には影響しません(発生するのはインフラ実費のみです)。

Q. クラスターを停止すればサービス料・インフラ実費は止まりますか?
A. 本記事執筆時点で、クラスターの「一時停止」に相当する機能の有無は確認できていません。コストを止めたい場合は、クラスターを削除する運用が確実です(§2-11・§6)。

2-13. インフラ実費の内訳 — コンピュート・メモリ・ブロックボリューム・オブジェクトストレージ

インフラ実費パススルーの対象は、コンピュート・メモリ・ブロックボリューム・オブジェクトストレージの4種類です。コンピュート・メモリ・ブロックボリュームは、各ノードのシェイプとストレージ容量に応じて決まる実費で、想像しやすい構成要素です。オブジェクトストレージについては、OpenSearchクラスターの一般的な用途(インデックスのスナップショット・バックアップ用途など)で使用されるものと考えられますが、本記事執筆時点で公式ドキュメントから具体的な利用シーンの詳細までは確認できていません。実際の請求内訳は、コンソールのコスト分析画面でサービス単位に確認することを推奨します。

2-14. サービス料SKUの継続的な確認

本記事で参照したサービス料のSKU(B93709・$0.25/データノード/時間)は、cetools(価格表取得ツール)で2026年8月10日時点に取得した値です。OCIの価格改定はSKU単位で発表されることが多く、GenAI Vol1・Cache記事で確立した方法論と同様、実際の構築前には最新のSKU情報を都度確認することを推奨します。特に、長期運用を前提としたクラスターでは、四半期に一度程度、価格表の変更有無をチェックしておくと安心です。早期に値上げへ気付けるという効果もあります。

2-15. RAGユースケースでの構成イメージ

§5で扱うRAG基盤としての利用を見据えると、検証段階ではLeader 1台+Data 2台+Dashboard 1台の最小構成で十分です。埋め込みベクトルの投入量が増え、検索負荷が上がってきた段階で、Dataノードの追加(3台目以降はサービス料が発生)やSearchノードの追加(読み取り処理の分離)を検討する、という段階的な拡張が現実的な進め方です。本番規模のRAG基盤を設計する際は、埋め込みベクトルの次元数・ドキュメント件数から必要なインデックスサイズを見積もり、それに応じたブロックボリューム容量とノード数を設計する必要がありますが、本記事のスコープはVol1のハンズオンレベルにとどめ、本番規模のキャパシティプランニングは扱いません。

2-16. 料金設計でよくある失敗パターン

最後に、料金設計の観点で陥りやすい失敗パターンを3つ整理します。

1つ目は、検証段階でデータノードを気軽に3台・4台と増やしてしまい、意図せずサービス料が発生するパターンです。負荷試験や冗長性確認のために台数を増やす際は、増やした台数がサービス料の発生ラインを超えていないか、その都度意識する必要があります。

2つ目は、逆にサービス料を避けるためにデータノードを常に2台に固定してしまい、必要な検索性能・可用性を犠牲にするパターンです。サービス料は$0.25/データノード/時間という決して高額ではない単価であるため、性能要件が明確にある場合は、過度にノード数を絞るより、必要な台数を確保したうえでコストを許容する判断も合理的です。

3つ目は、AWS OpenSearch Serviceの感覚(インスタンスタイプ単位の課金)をそのままOCIに当てはめ、「ノードを増やす=単純に比例して課金が増える」と誤解するパターンです。OCIでは、Leader・Dashboard等はノード種別として課金構造が異なり(インフラ実費のみ)、Dataノードのみが特殊なサービス料ルールを持つため、AWSでの感覚をそのまま持ち込むと見積りを誤ります。

これら3つの失敗パターンに共通するのは、いずれも「サービス料はデータノードのみ、かつ3台目から発生する」という境界線を正確に把握していれば防げるという点です。§2全体を通じて、この境界線の理解を最優先で扱ってきた理由もここにあります。

これらの失敗パターンは、いずれもコンソールのコスト分析画面を定期的に確認する習慣があれば早期に気付けるものでもあります。クラスター作成直後だけでなく、検証期間中も定期的にコストの推移を確認することを、本記事全体を通じての実務的な推奨事項として付け加えておきます。

2-17. §2のまとめ

本章では、OCI Search with OpenSearchの料金体系を、インフラ実費パススルーとサービス料(データノード3台目から発生・最初の2台は免除)という2階建て構造として整理しました。あわせて、ノード種別6種の最小メモリ要件、AWS OpenSearch Service/Serverlessとの対比、Always Free対象外である一方でサービス料免除という別形態の費用抑制構造が存在することを確認しました。

具体的には、①東京・大阪両リージョンでGA提供され、OpenSearch 3.6.0まで対応していること(§2-1)、②Leader・Data・Dashboardの3種類が基本構成でLeader・Dataは最小20GBのメモリを要すること(§2-2)、③サービス料はデータノードのみに発生し最初の2台は免除されること(§2-3・§2-7)、④AWS OpenSearch Service/Serverlessとはマネージド範囲・課金モデル・コミットメント割引の有無が異なること(§2-5)、という4点が本章の要点です。この理解を前提に、続く§3では最小構成クラスターをサービス料$0のまま実際に作成します。

3. クラスター作成ハンズオン — 最小構成でサービス料$0

3-1. 前提条件

クラスターを作成するには、対象コンパートメントに対するOpenSearch関連リソースの作成権限(IAMポリシー)と、クラスターを配置するVCN(既存または新規作成)が必要です。VCNを新規作成する場合、既存のサブネットは割り当てられず、新規サブネットの作成が必須である点に注意してください。リージョナルサブネットの使用が推奨されています。

3-2. VCN/ネットワーク要件

クラスター作成時、プライベートエンドポイントはOCI Search with OpenSearch側で自動的に構成され、クラスター内外のネットワークトラフィックはクラスターが所属するVCN内に閉じます。VCN外からのアクセスが必要な場合は、別途ルーティングやパブリックサブネットの構成を利用者側で行う必要があります。ハンズオンの範囲では、検証用の閉じたVCN内で完結させる構成を前提とします。

3-3. 最小構成でのクラスター作成

コンソールのクラスター作成画面で、以下の設定で最小構成を組みます。

• Leaderノード: 1台、20GB/1 OCPU
• Dataノード: 2台、20GB/1 OCPU(3台目を追加するとサービス料が発生するため、検証段階では2台に留めます)
• Dashboardノード: 1台、8GB/1 OCPU
• セキュリティ: マスターユーザー名・パスワードを設定(Configure securityステップで必須)
• バージョン: 3.6.0(執筆時点の最新・Current)を選択

作成には数分〜十数分程度かかります。作成完了後、クラスターの詳細画面からプライベートエンドポイントのURLを確認します。

3-4. 接続確認

VCN内の踏み台インスタンス等から、クラスターのプライベートエンドポイントに対してTLS接続の疎通を確認します。OpenSearch Dashboardsへは、Dashboardノードのプライベートエンドポイントにブラウザまたはトンネル経由でアクセスし、設定したマスターユーザーでログインできることを確認します。ここまでの構成で、サービス料が発生していないことをコンソールのコスト分析(Cost Analysis)であわせて確認しておくと安心です。

続く§4では、作成したクラスターでインデックス作成から検索までを実践します。

4. 検索実践 — インデックスとDashboards

4-1. インデックスの作成

OpenSearchの標準REST API(PUT /{インデックス名})を使い、マッピング(フィールド定義)を指定してインデックスを作成します。OCI Search with OpenSearchは標準のOpenSearchエンジンをそのまま提供しているため、OCI固有の拡張構文は不要で、公式のOpenSearch APIリファレンス通りの操作がそのまま通用します。

4-2. ドキュメントの投入

POST /{インデックス名}/_docまたは_bulk APIを使い、JSON形式のドキュメントを投入します。大量データを投入する場合は、_bulk APIでのバッチ投入がREST呼び出し回数を抑えられます。

4-3. 検索クエリの実行

GET /{インデックス名}/_searchに対してMatch Query・Term Query・Bool Queryなどの標準的なOpenSearch Query DSLを送信し、検索結果を取得します。全文検索の基本動作を確認したうえで、次章以降のベクトル検索(k-NN)へと進みます。

4-4. OpenSearch Dashboardsでの可視化

OpenSearch Dashboardsのインデックスパターン機能を使うと、投入したドキュメントをGUI上で確認できます。Discover画面でクエリを試しながらデータの中身を確認し、Visualize機能でグラフ化できます。ハンズオンとしては、まずDiscover画面で投入したドキュメントが検索できることを確認するところまでを目安にしてください。

続く§5では、ベクトル検索とRAG基盤への発展を扱います。

5. ベクトル検索とRAG基盤への発展

5-1. バンドルされているベクトル検索・ML機能

OCI Search with OpenSearchは、OpenSearch 2.19以降、k-NNプラグイン(Faiss/Lucene双方のエンジンに対応し、コサイン類似度によるk-NN検索・半径検索が可能)、ML Commonsプラグイン(OpenAI・Bedrock・Cohere・SageMaker・カスタムHTTPエンドポイントへのコネクタによるサーバーサイド埋め込み生成に対応)、Neural Searchプラグイン(ベクトル検索とキーワード検索を組み合わせたハイブリッド検索)をバンドルしています。3.2以降は、これらAI/ML関連機能のさらなる強化が継続されています。

5-2. GenAI Vol1の埋め込みをk-NNインデックスへ格納する設計

OCI Generative AIサービス実践Vol1の§4では、Cohere Embed 4を使い、「埋め込みモデルを使ったベクトル表現の生成」を実践しました。この埋め込みベクトルの格納先として、本記事で構築したOpenSearchクラスターのk-NNインデックスを利用できます。具体的には、k-NNベクトル型のフィールドを持つインデックスを作成し、GenAI Vol1で生成した埋め込みベクトルをドキュメントの1フィールドとして投入することで、ベクトル類似検索が可能になります。

5-3. RAG基盤としての構成とGenAI Agentsとの使い分け

GenAI Vol1の§5では、OCI Generative AI Agentsを使ったマネージドRAG(ナレッジベース作成〜エージェント問い合わせ)を扱いました。GenAI Agentsは、データソースの取り込みからベクトル化・検索・生成までを一括で管理するフルマネージドな選択肢です。一方、本記事のOpenSearch k-NNを使う構成は、埋め込みモデルの選択・インデックス設計・検索ロジックを自分でコントロールしたい場合に向いています。両者は排他的でなく、細かい制御が必要な部分だけをOpenSearchで自前構成し、それ以外をGenAI Agentsに任せるという組み合わせも可能です。

5-4. Valkey(Cache記事)のvalkey-searchとの3択整理

OCI Cache(Valkey)実践Vol1で紹介したValkey 8.1のvalkey-search moduleも、ベクトル類似検索を提供する機能です。OCI上でベクトル検索基盤を選ぶ際は、次の3択を軸に検討するとよいでしょう。

valkey-searchはGAから1年に満たない新しい機能であるため、Cache記事同様、本記事でも機能の存在と用途の紹介にとどめます。

続く§6では、本記事全体の振り返りと落とし穴チェックリストを整理します。

6. まとめ・落とし穴チェックリスト

本章では、§1〜§5で解説してきた内容を振り返り、OCI Search with OpenSearchを扱う際に陥りやすい落とし穴を、チェックリスト形式で整理します。

§1では、AWS OpenSearch運用経験者・RAG構築検討者を読者像とし、GenAI Vol1・Cache記事との結線を確認しました。§2では、インフラ実費パススルーとサービス料(データノード3台目から発生・最初の2台は免除)という課金構造、ノード種別6種の最小メモリ要件、AWS OpenSearch Service/Serverlessとの対比を整理しました。§3では、サービス料$0のまま最小構成クラスターを実際に作成しました。§4では、標準のOpenSearch REST APIでインデックス作成・検索を実践しました。そして§5では、GenAI Vol1の埋め込みベクトルをOpenSearch k-NNインデックスへ格納し、RAG基盤へ発展させる設計を整理しました。

OCI Search with OpenSearchは、AWS OpenSearch Serviceの運用経験があればマネージド範囲やAPI体系は理解しやすい一方、サービス料の免除条件や最小構成のメモリ要件といった、OCI特有の課金・設計上の注意点を正確に押さえておくことが重要です。本記事の最小構成をベースに、GenAI Vol1の埋め込み資産と組み合わせたRAG基盤の構築へと発展させてみてください。