OCI Generative AI実践Vol1 大阪リージョンでモデル呼び出し

1. なぜOCI Generative AIサービスか — AWS Bedrockとの対比で読み解く

1-1. 本記事のゴール

本記事は、「OCI Generative AIサービス実践」シリーズの第1弾として、AWSのAmazon Bedrockを運用してきたエンジニアを主な読者に想定し、OCI Generative AIサービスをAWS実務者の視点から理解し、実際にモデル呼び出し・Generative AI Agents(RAG)・埋め込みまでを実践することを目的としています。

本記事を読み終えると、次の状態になることを目指しています。

• OCI Generative AIサービスが、Amazon Bedrockとどのような点で似ており、どのような点で異なるプラットフォームなのかを、AWS実務者の言葉で説明できる
• OCI Generative AIサービスが日本国内では大阪リージョン限定でGA提供されているという制約(東京非対応)を理解し、リージョン選択を誤らずに設計できる
• Always Free枠が存在しないon-demand従量課金のサービスであることを理解した上で、大阪リージョンでモデル呼び出し・Agents(RAG)・埋め込みを実際に動かせる

なお、本記事(Vol1)では、大阪リージョンにおけるサービス提供状況の把握(§2)、コンソール・CLIを使ったモデル呼び出しの実践(§3)に加えて、埋め込みモデルを使ったベクトル表現の生成(§4)、Generative AI Agents(RAG)を使ったナレッジベース構築とエージェント実践(§5)までを扱います。

本記事の対象範囲を明確にするため、扱わない内容もあらかじめ整理しておきます。

• Dedicated AIクラスターによるファインチューニングやカスタムモデルのホスティング(on-demand利用に絞って解説します)
• Terraform等のIaCによるGenerative AIリソースのプロビジョニング
• Generative AI Agentsの本格的なナレッジベース構築(データソース接続・チャンキング戦略等の詳細)

1-2. 読者像

本記事は、AWSでAmazon Bedrockの運用経験をお持ちの方で、OCIのGenerative AIサービスには初めて触れる方を主な読者として想定しています。

「Generative AI」という名前の類似から、BedrockとOCI Generative AIを同じ設計思想のサービスだろうと想像して読み進めると、後述するリージョン提供状況や料金体系の違いでつまずきがちです。特に次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCI Generative AIは、Bedrockのようにマネージドで複数モデルを呼び出せるプラットフォームなのか、それとも全く別の設計思想なのか
• 東京リージョンでOCIを使っているが、Generative AIサービスもそのまま使えるのか
• OCIには手厚いAlways Free枠があると聞いたが、Generative AIも無料で試せるのか
• 「Agents」という言葉をOCIの文脈で見かけたが、Bedrock Agentsと同じものなのか

なお、本記事は「OCI入門シリーズ」Vol1で扱ったテナンシ・コンパートメント・リージョンの基礎、および「OCI入門シリーズ」で解説したAlways Free枠の考え方を前提知識として活用しますが、未読の方でも読み進められるよう、本記事に必要な範囲は本文中で補足します。

OCIアカウント自体をまだ持っていない方は、先にOCI入門シリーズVol1を参照し、テナンシのサインアップとホームリージョンの選択を済ませておくことをお勧めします。

1-3. OCI Generative AIサービスとは — AWS Bedrockとの違い

OCI Generative AIサービスは、Oracleがフルマネージドで提供する生成AIプラットフォームであり、Cohere・Meta・OpenAI・Googleなど複数ベンダーの大規模言語モデルを、単一のAPI・SDK・コンソール(Playground)から呼び出せるサービスです。この「複数ベンダーのモデルを単一のインターフェースで呼び出す」という基本設計は、Amazon Bedrockと発想が近く、AWS実務者にとってはBedrockの対応サービスとして理解しやすい構造になっています。

一方で、AWS実務者がまず注意すべき違いは、サービスの提供範囲そのものです。Amazon Bedrockは東京リージョン(ap-northeast-1)を含む多数のAWSリージョンで利用できますが、OCI Generative AIは2026年7月25日時点で商用(OC1)提供対象が11リージョンに限られており、日本国内では大阪(Japan Central・ap-osaka-1)のみが対象で、東京(ap-tokyo-1)は提供対象に含まれていません。この点は、OCIの他の主要サービス(コンピュートやデータベース等)の多くが東京・大阪の両リージョンで使える現状と対照的であり、Bedrockの感覚のまま「OCIのホームリージョンを東京にしているから、Generative AIもそのまま使える」と考えると、実際にはコンソールの該当メニューにアクセスできず、つまずくことになります。

なお、料金体系についてはBedrockもOCI Generative AIも従量課金制である点は共通していますが、OCI Generative AIにはAlways Free枠が存在しない点は、本シリーズの他のOCIデータベースサービス(Autonomous Database・MySQL HeatWave)とは異なる重要な違いです。この点は§2で詳しく扱います。

1-4. 本記事の差別化軸

OCI Generative AIを扱う入門記事の多くは、東京リージョンを前提に手順を紹介しようとして提供状況の壁に突き当たるか、逆にモデル呼び出しの概要紹介のみで終わりがちです。本記事は、次の3つの軸で差別化を図ります。

1. AWSエンジニア向けのBedrock対比レンズ: §1-3で見た通り、OCI Generative AIを「Bedrockの延長線上にある類似サービス」として捉えるのではなく、リージョン提供状況・料金体系・Agents機能といった具体的な差分を軸に、OCI固有の別プラットフォームとして理解します。
2. モデル呼び出し・Agents(RAG)・埋め込みの一気通貫実践: 入門記事にありがちな概要紹介の再説にとどめず、大阪リージョンでの実際のモデル呼び出し(§3)を実践します。
3. 大阪リージョンでの実践という現実解: 東京非対応の制約を隠すのではなく「落とし穴」として明示した上で、大阪リージョンに切り替えて確実に動く手順を提示します。この現実解の提示自体が、他の入門記事にはない一次情報としての価値になります。

1-5. 落とし穴 — 東京リージョンでは使えない、大阪リージョンのみGA提供

AWS実務者が最初につまずきやすいのは、この東京非対応という制約です。OCI Generative AIサービスを使い始める際は、まずこの点を意識しておく必要があります。OCI公式のリージョン一覧ドキュメントでは、商用(OC1)向けGenerative AI提供リージョンとして、米国(Ashburn/Chicago/Phoenix)・ブラジル(Sao Paulo)・欧州(Frankfurt/London)・中東(Riyadh/Abu Dhabi/Dubai)・インド(Hyderabad)・そして日本の大阪(Osaka)の11リージョンが明記されており(取得日: 2026年7月25日)、東京は一覧に含まれていません。

これは「大阪だけがまだ提供されていない」のではなく、逆に「大阪だけが日本国内で提供されている」という点を正確に理解しておく必要があります。テナンシのホームリージョンを東京に設定している場合、Generative AIサービスを利用するには、コンソールのリージョンセレクターで明示的に大阪リージョンへ切り替える必要があります。この切り替えの要否は、OCIの他の主要サービスではあまり意識する場面がないため、見落としやすいポイントです。

なお、ホームリージョンを東京のまま維持し、大阪リージョンはGenerative AIサービスの利用時にのみ都度切り替えるという運用でも問題ありません。ホームリージョンの変更自体は不要です。

1-6. 用語整理 — 「Generative AI」と「Generative AI Agents」は別サービス

OCIのドキュメントを読み進めていると、「Generative AI」と「Generative AI Agents」という似た名前の2つのサービスが登場し、混同しやすいポイントになっています。本記事および本シリーズでは、混乱を避けるため次のように整理します。

• (a) Generative AIサービス: 本記事のメインテーマです。Cohere・Meta・OpenAI・Googleの大規模言語モデルをon-demandで呼び出す、チャット・テキスト生成・埋め込みのための基盤サービスです。
• (b) Generative AI Agents: (a)のモデルを土台に、企業データを検索対象としたRAG(Retrieval-Augmented Generation)を組み込んだ、フルマネージドのエージェントサービスです。AWSでいえばBedrock Agents/Knowledge Basesに近い位置づけの機能です。

この2つは、コンソールのメニュー階層でも別項目として並んでおり、IAMポリシーの粒度も別々に管理されています。本記事では、単に「Generative AI」と書く場合は(a)の基盤サービス全体を、「Generative AI Agents」または「Agents(RAG)」と書く場合は(b)のRAG機能を指すものとして区別します。

1-7. シリーズでの位置づけ — OCI入門シリーズからの接続

本記事は、「OCI入門シリーズ」で扱ったテナンシ・コンパートメント・リージョンの基礎、および先行する「OCI Autonomous Database実践」「OCI MySQL HeatWave実践」の各シリーズとは異なる、生成AI領域に踏み込んだ実践シリーズの第1弾という位置づけです。

先行する2シリーズは、いずれもAlways Free枠を軸として「無料の範囲でどこまで実践できるか」を扱ってきました。一方、本シリーズはAlways Free枠が存在しないサービスを対象とする点で、これまでのOCI実践シリーズと前提が異なります。この違いを意識しないまま読み進めると、「無料で試せるはず」という誤った期待を持ったまま進めてしまいます。そのため本記事では、§2で料金体系を先に整理した上で、§3のハンズオンに進む構成としています。

OCIアカウントの基礎(テナンシ・コンパートメント・IAM)については、「OCI入門シリーズ」で扱った内容がそのまま前提知識として使えます。未読の方は、先に該当シリーズを参照しておくことをお勧めします。

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

§2で詳細を扱う前に、本記事全体の前提となる3つのポイントを整理しておきます。

1. リージョンは大阪(ap-osaka-1)で統一します。コンソールの操作・CLIコマンドの--region指定・後述するIAMポリシーの適用範囲は、すべて大阪リージョンを前提とします。
2. 料金はAlways Free枠のない従量課金です。§2で示すように、モデルの呼び出し回数・文字数に応じて課金される仕組みのため、検証時も無料枠に頼らず課金額を意識した設計が必要です。
3. モデルのラインアップは変動が速い領域です。§2で紹介するモデルは2026年7月25日時点の公式ドキュメントに基づく一次情報ですが、本記事を読んでいる時点で提供モデルが変わっている可能性があるため、実際の利用前には必ず公式ドキュメントで最新状況を確認してください。

この3点は、いずれもBedrockの運用経験だけでは自明に分からない、OCI Generative AI固有の前提です。特に1点目(リージョン)と2点目(料金)は、実際にコンソールを開く前の設計段階でつまずきやすいポイントであるため、§2で改めて一次情報とともに詳しく確認します。

この3点を踏まえた上で、次章では大阪リージョンにおける具体的な提供状況・モデルラインアップ・料金体系を確認していきます。

→ Amazon Bedrock本番運用ガイド(Flows・Evaluations・Nova)を読む

それでは、大阪リージョンで具体的にどのようなモデル・料金体系・Agents機能が提供されているのか、§2で詳しく見ていきましょう。

2. 大阪リージョンでの提供状況と料金体系

本章では、大阪リージョンでOCI Generative AIサービスを利用する際に押さえておくべき提供状況・モデルラインアップ・料金体系を、公式ドキュメント(取得日: 2026年7月25日)に基づいて整理します。特に料金体系については、Always Free枠を前提にした他のOCI実践シリーズとは異なり、最初から従量課金であるという前提を正しく理解しておくことが重要です。

以降の各節では、まず提供リージョンの範囲(§2-1)を確認し、続いて大阪リージョンで実際に呼び出せるモデルのラインアップ(§2-2)・モデル回転の速さに関する注意と自分で確認する方法(§2-3〜§2-4)を整理します。そのうえで、料金体系とdedicated課金の落とし穴(§2-5〜§2-6)・Generative AI Agents(RAG)の提供状況(§2-7)・xAI Grokモデルの非対応(§2-8)を確認し、最後に大阪リージョンでできること/できないことの一覧(§2-9)としてまとめます。

2-1. 提供リージョン — 商用11リージョン、日本国内は大阪のみ

OCI公式のリージョン一覧ドキュメントには、商用(OC1)向けにOCI Generative AIサービスが提供されているリージョンとして、次の11リージョンが明記されています(取得日: 2026年7月25日)。

この一覧の通り、日本国内では大阪(Japan Central・ap-osaka-1)のみがGenerative AIサービスの提供対象で、東京(ap-tokyo-1)は含まれていません。大阪リージョンへのサービス提供開始は、公式リリースノートに2024年11月26日と明記されています。

なお、この提供リージョンの限定は、Always Free枠に見られる「テナンシのホームリージョンでのみ作成可能」という制約とは性質が異なる点に注意してください。Always Free枠のデータベースサービス(Autonomous Database・MySQL HeatWave等)は、ホームリージョンであればどこでも無料枠を作成できますが、Generative AIサービスの場合はそもそもサービス自体がリージョン単位で提供されているかどうかが問題であり、有償で使う場合であっても大阪以外の国内リージョンでは利用できません。

2-2. 大阪リージョンのon-demandモデルラインアップ

大阪リージョンで実際に呼び出せるモデルは、OCI公式のモデル別地域対応ドキュメント(取得日: 2026年7月25日)で確認できます。on-demand(従量課金でそのまま呼び出せる)モデルと、dedicated AIクラスターの契約が必要なモデルとが明確に区別されている点に注意してください。

埋め込みモデルについても、on-demandで呼び出せるモデルとdedicated限定のモデルが分かれています。

本記事の§3では、この中からon-demandで呼び出せるチャットモデルを使ってハンズオンを行います。dedicated限定のモデルは、Dedicated AIクラスターの作成が必要で、料金体系もon-demandとは異なるため、本記事の対象範囲外とします。

2-3. モデル回転の速さと非推奨/退役モデルへの注意

OCI Generative AIのモデルラインアップは、回転が非常に速い領域です。OCI公式のモデル一覧ドキュメント(pretrained-models)を確認すると、Cohere Command R(08-2024)・Cohere Command R+(08-2024)は「Deprecated(非推奨)」、Meta Llama 3.1 70Bは「Retired(退役)」という区分で扱われています。一方で、前節のモデル別地域対応ドキュメントの大阪リージョンの表では、これらのモデルは依然としてon-demandの提供対象として掲載されていました(いずれも取得日: 2026年7月25日)。

この2つのドキュメント間の違いは、矛盾というより「グローバルなライフサイクルステータス」と「リージョン単位の実際のエンドポイント提供状況」が別々に管理されていることを示していると考えられます。非推奨・退役の扱いになったモデルであっても、リージョンごとの提供終了タイミングにはずれが生じうるため、実際にAPIを呼び出す前には、モデル別地域対応ドキュメントで大阪リージョンの最新の提供状況を確認することを強く推奨します。

2-4. 最新のモデル一覧を自分で確認する方法

前節で見た通り、公式ドキュメント上のモデルラインアップやライフサイクルステータスは変動が速く、本記事の表もいずれ古くなります。記事の表を鵜呑みにせず、実際に大阪リージョンで有効なモデル一覧をCLIから確認する方法を押さえておくと安心です。

OCI CLIには、コンパートメント単位でモデル一覧を取得するmodel-collection list-modelsコマンドが用意されています。

oci generative-ai model-collection list-models \
  --compartment-id <あなたのコンパートメントOCID> \
  --capability CHAT \
  --region ap-osaka-1

--capabilityオプションにはCHAT・TEXT_EMBEDDINGS・TEXT_RERANK・FINE_TUNE等が指定でき、目的のケイパビリティを持つモデルだけに絞り込めます。§3のハンズオンを始める前に、このコマンドで大阪リージョンの最新モデル一覧を確認しておくことをお勧めします。

2-5. 料金体系 — Always Free枠は存在しない、on-demand従量課金

本記事の前提として最も重要な点ですが、OCI Generative AIサービスにはAlways Free枠が存在しません。OCI公式のAlways Freeリソース一覧ドキュメントを確認しても、Autonomous AI Database・NoSQL Database・MySQL HeatWave・APMといったサービスは掲載されている一方、Generative AIサービス自体は掲載されていません(取得日: 2026年7月25日)。「OCI Autonomous Database実践」「OCI MySQL HeatWave実践」の各シリーズで扱ってきた「無料枠の範囲で実演する」という軸は、本シリーズには使えないという前提で読み進めてください。

課金の仕組みについては、公式ドキュメント(Paying for On-Demand Inferencing)に次のように明記されています。

1 character is calculated as 1 transaction.

つまり、1文字が1トランザクションとして計算され、料金は10,000トランザクション(10,000文字)あたりの単価を基準に算出されます。チャットモデルと埋め込みモデルとでは、課金対象となる文字数の数え方が異なる点にも注意が必要です。

具体的なモデルごとの単価(10,000トランザクションあたりの価格)は、OCI公式の価格表ページで随時更新されています。本記事では、モデルラインアップと同様に価格自体の回転も速い領域であることを踏まえ、特定の金額をそのまま転記することはせず、必ず利用時点の公式価格表を確認する運用を推奨します。検証を始める前には、想定するプロンプト・レスポンスの文字数から概算コストを試算し、想定外の課金が発生しないことを確認してから実行することをお勧めします。

2-6. 落とし穴 — Dedicated AIクラスターは744ユニット時間の最低利用commitment

§2-2で、モデルには「on-demand」と「dedicated限定」の2種類があることを確認しました。この区別は、料金体系の観点からも極めて重要です。公式ドキュメント(Paying for Dedicated AI Clusters)には、次のように明記されています。

If you’re hosting foundational models or fine-tuning them on dedicated AI clusters, you’re charged by the unit hour rather than by transaction.

つまり、on-demandモデルが「呼び出した文字数」に応じた従量課金であるのに対し、dedicated AIクラスターは「ユニット時間」による課金であり、しかもホスティング用クラスターには744ユニット時間という最低利用commitmentが設定されています。公式ドキュメントの例では、3ユニットのクラスターを5日間(360ユニット時間)しか稼働させなかった場合でも、744ユニット時間分の最低利用料金が請求されると明記されています。

この違いは、AWSのBedrockにおけるon-demand推論とProvisioned Throughputの関係に近い構図です。Bedrockにも、Provisioned Throughputを契約すると時間単位の最低利用料金が発生します。ただしOCI Generative AIの場合は、モデルによってはdedicated限定でしかそもそも呼び出せないという制約が加わる点で異なります。§2-2の表で「dedicated限定」と分類されているモデル(Cohere Command R 16K・Meta Llama 3.2 11B Vision・Meta Llama 3.1 405B等)を検証目的で試す場合は、この744ユニット時間の最低利用commitmentが発生する前提でコストを試算してください。本記事の§3では、この落とし穴を避けるため、on-demandモデルのみを対象にハンズオンを行います。

2-7. Generative AI Agents(RAG)の大阪提供状況

Generative AI Agents(企業データを検索対象としたRAGを組み込んだエージェントサービス)についても、公式リリースノートに大阪リージョンでの提供開始日が2025年3月28日と明記されており、大阪リージョンでは提供済みです。これは、本記事のモデル呼び出し(Generative AI本体)がGA提供された2024年11月26日から約4か月後にあたります。

したがって、本記事執筆時点(2026年7月25日)では、大阪リージョンにおいてGenerative AI本体・Generative AI Agentsの両方が利用可能な状態にあり、RAGを組み込んだエージェント構成についても大阪リージョン内で完結して構築できます。Generative AI Agentsの具体的な構築手順(データソース接続・ナレッジベース作成等)は、本記事の§5で扱います。

Generative AI Agentsのサービス概要ページには、次のように明記されています。

a fully managed service that combines the power of large language models (LLMs) with AI technologies to create intelligent virtual agents that can provide personalized, context-aware, and highly engaging customer experiences.

Bedrock Agents/Knowledge Basesと比較する上で押さえておきたいのは、Generative AI Agentsが単なるRAG(ナレッジベース検索)だけでなく、複数のツールをオーケストレーションする設計になっている点です。公式ドキュメントでは、次の5種類のツールが挙げられています。

この設計は、AWSでいえばBedrock Knowledge Bases(RAG)とBedrock Agentsのアクショングループ(Function Calling相当)を1つのサービスへ統合したようなイメージで、RAG専用ではなく汎用的なエージェント基盤として設計されている点がAWS実務者にとって理解しやすいポイントです。また、プロンプトインジェクション(PI)やPII(個人識別情報)に対するガードレール機能も標準で組み込まれています。

2-8. xAI Grokモデルは大阪リージョン非対応

OCI Generative AIの提供モデル一覧には、xAIのGrokシリーズ(Grok 4.3・Grok 4.20等)も含まれていますが、モデル別地域対応ドキュメントを確認すると、大阪リージョンではxAI Grokシリーズのモデルはいずれも提供対象に含まれていません(取得日: 2026年7月25日)。

xAI Grokシリーズは、公式ブログ等で新モデル追加のアナウンスが目立つため、最新モデルとして紹介されている記事を読むとつい試したくなりますが、大阪リージョンで検証する場合はGrokシリーズを選択肢から外し、本記事で紹介したCohere・Meta・OpenAI・Googleの各モデルから選ぶ必要があります。

2-9. まとめ — 大阪リージョンでできること/できないこと

本章で確認した内容を、大阪リージョンでの実践に絞って一覧化します。

← OCI入門 Vol1(テナンシ・コンパートメント・リージョン)を読む

それでは、この前提を踏まえた上で、§3では実際に大阪リージョンでモデルを呼び出すハンズオンに進みます。

3. 大阪リージョンでのモデル呼び出しハンズオン

本章では、§2で確認した前提を踏まえ、大阪リージョンでon-demandモデルを実際に呼び出す手順を、コンソールのPlaygroundとCLIの両方で実践します。いずれも架空の画面要素やAPIパラメータを記載せず、公式ドキュメントで明記された手順・コマンド構文に基づいて解説します。

3-1. 前提条件とIAMポリシー

ハンズオンを始める前に、次の前提条件を確認してください。

Generative AIリソース全体へのアクセスを許可するIAMポリシーは、公式ドキュメント(IAM Policies for Generative AI)に次のように明記されています。

allow group <your-group-name> to manage generative-ai-family
in compartment <your-compartment-name>

generative-ai-familyは、Generative AIに関連するリソースをまとめて扱う集約リソースタイプです。公式ドキュメントには、テナンシ全体への権限付与(in tenancy)も可能だが、管理者やサンドボックス環境での利用に限定して付与することが推奨されている旨が明記されています。本記事のハンズオンのように検証目的で利用する場合は、専用のコンパートメントを用意し、そのコンパートメント単位でポリシーを付与することをお勧めします。

なお、Generative AI Agentsを利用する場合は、上記とは別に専用のIAM権限(QuickStart Permissions for Building Agents)が必要になります。本記事の§3ではモデル呼び出し(Generative AI本体)のみを扱うため、Agents用のポリシーは対象外とします。

3-2. コンソールPlaygroundでのチャット呼び出し

まず、コードを書かずに試せるコンソールのPlaygroundから始めます。公式ドキュメント(Chat in OCI Generative AI)に明記された手順は次の通りです。

1. コンソールのナビゲーションバーで、Generative AIが提供されているリージョン(本記事では大阪・Japan Central)を選択します。
2. ナビゲーションメニューを開き、「Analytics & AI」を選択します。「AI Services」配下の「Generative AI」を選択します。
3. 操作権限を持つコンパートメントを選択します。
4. 「Playground」を選択します。
5. 「Chat」を選択します。
6. モデルリストから、§2-2で確認したon-demandモデル(例: cohere.command-aやmeta.llama-3.3-70b-instruct)を選択します。「View model details」からモデル詳細を確認して選択できます。
7. プロンプトを入力するか、「Example」リストからサンプルを選択して会話を開始します。
8. 必要に応じてパラメータ(temperature等、モデルごとに異なるためモデル詳細のパラメータ定義を参照)を設定します。
9. 「Submit」を選択します。
10. 続けて会話する場合は、新しいプロンプトを入力して再度「Submit」を選択します。

Playgroundでの呼び出しも§2-5で確認した通りon-demand課金の対象であり、Always Free枠は適用されません。動作確認のつもりで何度もSubmitを繰り返すと、その都度課金が発生する点に注意してください。

3-3. CLIでのon-demandチャット呼び出し

自動化・スクリプト化を前提とする場合は、OCI CLIのgenerative-ai-inferenceコマンド群を使います。公式のCLIコマンドリファレンスに基づく構文は次の通りです。

まず、大阪リージョンで現在有効なon-demandモデルを確認します(§2-4で紹介したコマンドと同じです)。

oci generative-ai model-collection list-models \
  --compartment-id <あなたのコンパートメントOCID> \
  --capability CHAT \
  --region ap-osaka-1

チャットリクエストのJSONひな形は、--generate-param-json-inputオプションで自動生成できます。手打ちでJSONを組み立てず、この自動生成を使うことで、モデルAPIのスキーマ変更によるエラーを避けられます。

oci generative-ai-inference chat-result chat-generic-chat-request \
  --generate-param-json-input chat-request > chat-request.json

生成されたchat-request.jsonのmessages配列に、role(USER等)とcontent(プロンプト本文)を設定した上で、次のコマンドでon-demandモデルを呼び出します。chat-on-demand-serving-modeサブコマンドを使うと、サービングモードの指定を--serving-mode-model-id一つで完結できます。

oci generative-ai-inference chat-result chat-on-demand-serving-mode \
  --chat-request file://chat-request.json \
  --compartment-id <あなたのコンパートメントOCID> \
  --serving-mode-model-id <モデルのOCID> \
  --region ap-osaka-1

ここで重要なのは、--region ap-osaka-1を明示的に指定することです。CLIプロファイルのデフォルトリージョンが東京や他のリージョンに設定されている場合、この指定を省略すると、Generative AIサービスが提供されていないリージョンに対してリクエストが送られ、エラーになります。スクリプト化する際は、環境変数や設定ファイルのデフォルトに頼らず、コマンドごとに--region ap-osaka-1を明示することをお勧めします。

3-4. 実行結果の確認とコスト管理

呼び出しに成功すると、レスポンスのJSONにモデルの生成テキストが含まれます。§2-5で確認した通り、この呼び出し1回ごとに、プロンプトとレスポンスの合計文字数に応じた課金が発生しています。検証を繰り返す際は、OCIコンソールのコスト管理(Cost Analysis)画面で、Generative AIサービスの利用状況を定期的に確認することをお勧めします。

本記事では、モデル呼び出しの基本的な流れを確認しました。続く§4・§5では、埋め込みモデルを使ったベクトル表現の生成と、Generative AI Agents(RAG)を使ったナレッジベース構築・エージェント実践を見ていきます。

4. 埋め込み(Embeddings)の実践 — Cohere Embed 4でベクトル表現を生成する

本章では、§2-2で確認した大阪リージョンのon-demand埋め込みモデルのうち、最新モデルであるCohere Embed 4(cohere.embed-v4.0)を使って、実際にテキストの埋め込み(ベクトル表現)を生成する手順を実践します。

4-1. 埋め込みとは — RDS/Auroraにはない「ベクトル表現生成」という機能

AWS実務者にとって、埋め込み(Embeddings)という機能は、Amazon Bedrockが提供するTitan Embeddings等のモデルで馴染みがあるかもしれません。一方で、AWSのRDSやAuroraといったデータベースサービス自体には、テキストを埋め込みベクトルへ変換する機能は組み込まれておらず、埋め込み生成はBedrock(別基盤のマネージドAIサービス)側の役割です。OCIでも構図は同様で、Autonomous DatabaseやMySQL HeatWave自体が埋め込みを生成するわけではなく、埋め込み生成はGenerative AIサービス(本記事のテーマ)側の役割であり、生成したベクトルをデータベース側(Oracle AI Database 26aiのAI Vector Search機能等)に格納・検索するという役割分担になっています。

埋め込みとは、テキスト(や画像)を、意味的な近さを数値的な距離として表現できる多次元のベクトルに変換する処理です。生成したベクトルは、類似文書検索・レコメンデーション・RAG(§5で扱うAgents機能の内部でも利用されています)といった用途で使われます。

4-2. Cohere Embed 4の仕様

大阪リージョンでon-demand提供されている埋め込みモデルは、§2-2で確認した通りCohere Embed 4・Cohere Embed English 3・Cohere Embed Multilingual 3の3系統です。本節では、最新かつ最も柔軟な仕様を持つCohere Embed 4(cohere.embed-v4.0)を対象とします。公式ドキュメント(取得日: 2026年7月25日)によれば、次の仕様を持ちます。

Amazon BedrockのTitan Embeddingsと比較すると、Matryoshka embeddings方式による出力次元数の選択(256〜1536)や、テキストと画像を組み合わせられるマルチモーダル対応は、Cohere Embed 4に特徴的な機能です。一方で、コンソールのPlayground経由では出力次元数が1536固定になる点は、APIでカスタム次元数を使う予定がある場合に見落としやすい制約です。

4-3. コンソールPlaygroundでの埋め込み生成

まず、コードを書かずに試せるコンソールのPlaygroundから埋め込みを生成します。公式ドキュメント(Create Text Embeddings in Generative AI・取得日: 2026年7月25日)に基づく手順は次の通りです。

1. コンソールのナビゲーションバーで大阪リージョン(Japan Central)を選択します。
2. ナビゲーションメニューから「Analytics & AI」→「AI Services」配下の「Generative AI」を選択します。
3. 操作権限を持つコンパートメントを選択します。
4. 「Playground」を選択し、「Embedding」を選びます。
5. モデルリストからcohere.embed-v4.0を選択します(または「View model details」から選択)。
6. テキストを入力します。1文ずつ入力して「Add sentence」で追加するか、.txtファイル(改行区切り)を「Upload file」でアップロードします。
7. 512トークンを超える入力がある場合に備え、「Truncate」でStartまたはEndを選択します。
8. 「Run」を選択して埋め込みを生成します。
9. 生成結果は2次元投影された可視化グラフとして表示されます。実際のベクトル値を確認するには「Export embeddings to JSON」を選択し、JSONファイルとしてダウンロードします。
10. 「View code」から、Python等のSDKコード片をそのままコピーできます。

なお、埋め込みの出力次元数については、公式ドキュメント間で記述にずれがあります。Cohere Embed 4のモデル仕様ページでは「コンソールは1536固定」と明記されている一方、Playgroundの操作手順ページには「1024次元ベクトル」という汎用的な記述が残っています(いずれも取得日2026年7月25日)。実際にエクスポートしたJSONファイルを開き、配列の要素数を数えることで、実際の出力次元数を確認するのが確実です。

4-4. CLIでのテキスト埋め込み生成

自動化・スクリプト化を前提とする場合は、generative-ai-inference embed-text-result embed-textコマンドを使います。公式CLIリファレンス(取得日: 2026年7月25日)に基づく構文は次の通りです。

oci generative-ai-inference embed-text-result embed-text \
  --compartment-id <あなたのコンパートメントOCID> \
  --serving-mode '{"servingType": "ON_DEMAND", "modelId": "cohere.embed-v4.0"}' \
  --inputs '["大阪リージョンで埋め込みを生成する", "OCI Generative AIの実践"]' \
  --read-timeout 240 \
  --region ap-osaka-1

--inputsには埋め込み対象のテキストを配列で指定します。§3のチャット呼び出しと同様、--region ap-osaka-1を明示することが重要です。出力次元数をデフォルトの1536から変更したい場合は、APIリクエストのoutputDimensionsパラメータ(256/512/1024/1536のいずれか)を指定します。具体的な指定方法はCLIリファレンスのembed-textコマンド詳細を参照してください。

4-5. 落とし穴 — コンソールとAPIでの次元数の違い、画像入力はAPI限定

生成した埋め込みベクトルは、それ単体では活用できず、ベクトル検索エンジンやベクトルデータベース(Oracle AI Database 26aiのAI Vector Search、あるいはOCI OpenSearch等)に格納して初めて類似検索やRAGの土台になります。次章では、この埋め込みの仕組みを内部で活用しているGenerative AI Agents(RAG)を使い、ナレッジベースの構築からエージェントでのクエリ実行までを実践します。

5. Agents(RAG)の実践 — ナレッジベース作成からエージェント問い合わせまで

本章では、§2-7で提供状況を確認したGenerative AI Agentsを使い、大阪リージョンでナレッジベースを作成し、RAGツールを持つエージェントを構築して、実際に問い合わせるまでの一連の流れを実践します。

5-1. 全体の流れとBedrock Knowledge Bases/Agentsとの対応

Generative AI Agentsを使ったRAG構成は、大きく次の4ステップで構築します。

1. データソース(OCI Object Storage等)を用意する
2. ナレッジベースを作成し、データソースを紐付けてデータを取り込む(ingestion)
3. エージェントを作成し、ナレッジベースを参照するRAGツールを追加、エンドポイントを設定する
4. エンドポイントに対してチャット形式で問い合わせる

AWSのBedrockでいえば、手順2にあたるのがKnowledge Bases(データソース接続+ベクトル化)で、手順3にあたるのがAgents(Action Groups相当のツール設定)です。ただしOCI Generative AI Agentsでは、ナレッジベースの作成とエージェントの作成が独立したリソースとして分かれており、1つのナレッジベースを複数のエージェントから参照する構成も可能です。

5-2. IAM権限の追加設定 — genai-agent-familyとobject-family

§3-1で確認したモデル呼び出し用のIAMポリシー(generative-ai-family)とは別に、Generative AI Agentsを利用するには専用のリソースタイプgenai-agent-familyに対する権限が必要です。公式ドキュメント(Getting Access to Generative AI Agents・取得日: 2026年7月25日)には、次のポリシーが例示されています。

allow group <genai-agent-administrators> to manage genai-agent-family in compartment <your-compartment-name>

genai-agent-familyは、エージェント本体・ナレッジベース・データソース・データ取り込みジョブ・エンドポイント・セッション・ツールをまとめた集約リソースタイプです。

さらに、本節で使うOCI Object Storageのバケットをデータソースにする場合、Object Storageへのアクセス権限が別途必要になります。特にバケットとエージェントが異なるコンパートメントにある場合は見落としやすいため注意してください。

allow group <your-group-name> to manage object-family in compartment <compartment-with-bucket>

5-3. ナレッジベースの作成 — Object Storageをデータソースにする

公式ドキュメント(Creating a Knowledge Base in Generative AI Agents・取得日: 2026年7月25日)に基づき、Object Storageをデータソースとするナレッジベースを作成する手順は次の通りです。

1. あらかじめOCI Object Storageにバケットを作成し、ナレッジベースにしたいドキュメント(PDFやテキストファイル等)をアップロードしておきます。
2. コンソールで大阪リージョンを選択し、「Analytics & AI」→「Generative AI Agents」→「Knowledge bases」を開き、「Create knowledge base」を選択します。
3. ナレッジベースの名前(英字またはアンダースコアで始まる1〜255文字)・コンパートメント・説明(任意)を入力します。
4. データストアタイプとして「Object Storage」を選択します。
5. 「Specify data source」でデータソースの名前を入力し、手順1で用意したバケットを選択します。「Select all in bucket」で全件を対象にするか、特定のファイル・フォルダのみを選択します。
6. ナレッジベースは1つにつきデータソースを1つのみ設定できる点に注意してください。
7. 「Automatically start ingestion job for above data sources」を有効にすると、作成と同時にデータ取り込みジョブが開始されます。
8. 「Create」を選択します。ナレッジベースの作成には数分程度かかります。

作成後は、取り込みジョブ(ingestion job)のステータスとログを確認してください。取り込みに失敗したファイルがある場合は、原因を解消した上でジョブを再実行できます。再実行時は、既に成功しているファイルは自動的にスキップされます。

5-4. エージェントの作成とRAGツールの追加

ナレッジベースの準備ができたら、公式ドキュメント(Creating an Agent in Generative AI Agents・取得日: 2026年7月25日)に基づき、エージェントを作成します。

1. 大阪リージョンで「Agents」リストページを開き、「Create agent」を選択します。
2. エージェントの名前・コンパートメント・説明(任意)・ウェルカムメッセージ(任意)を入力します。
3. ルーティングLLMのタイプを選択します(Default/Generative AIモデル/Generative AIエンドポイントのいずれか)。「Generative AIモデル」を選ぶ場合、§2-2で確認したon-demandモデルの中からモデルを指定します。
4. 必要に応じてハイパーパラメータを調整します。
5. 「Add a tool」から「RAG tool」を選択し、§5-3で作成したナレッジベースを紐付けます。
6. 「Set up an agent endpoint」で「Automatically create an endpoint for this agent」にチェックを入れます。あわせて、コンテンツモデレーション・プロンプトインジェクション(PI)対策・PII保護の要否(Disable/Block/Inform)を設定します。
7. 設定内容を確認し、「Create agent」を選択します。
8. 使用するモデルによってはライセンス条項(Llama 3ライセンス等)への同意画面が表示されるため、内容を確認しチェックボックスに同意した上で「Submit」します。

§2-7で確認した通り、Generative AI AgentsはRAG Toolのほかにも、SQL Tool・Custom Function Calling Tool・API Endpoint Calling Tool・Agent as a Toolを組み合わせられますが、本記事のハンズオンではRAG Toolのみを対象とします。

5-5. チャットでのクエリ実行

エージェントとエンドポイントの作成が完了したら、公式ドキュメント(Chatting with Agents in Generative AI Agents・取得日: 2026年7月25日)に基づき、コンソールから実際に問い合わせます。

1. 大阪リージョンで「Analytics & AI」→「Generative AI Agents」→「Chat」を開きます。
2. エージェントが格納されているコンパートメント(Agent compartment)を選択します。
3. エンドポイントが格納されているコンパートメント(Agent endpoint compartment)を選択します。
4. 問い合わせたいエージェントとエンドポイントを選択します。
5. メッセージを入力し、「Submit」を選択します。
6. 続けて会話する場合は次のプロンプトを入力して再度「Submit」、新しい会話を始める場合は「Reset Chat session」を選択します。
7. メタデータフィルタリングを設定済みの場合は、「Metadata filters」からtopic contains technicalのような条件を追加して検索範囲を絞り込めます。
8. トレースおよび引用(citations)がエンドポイントで有効化されている場合、回答の根拠となったナレッジベース内の該当箇所を確認できます。

引用(citations)機能は、RAGの回答がナレッジベースのどの文書のどの部分に基づいているかを確認できるため、回答の妥当性を検証する上で重要です。§3のモデル単体呼び出しでは得られない、Agents(RAG)ならではの利点といえます。

5-6. 落とし穴 — コンパートメント違いの権限、ライセンス同意、取り込み失敗

以上で、大阪リージョンにおけるモデル呼び出し(§3)・埋め込み(§4)・Agents(RAG)(本章)という3機能の一気通貫実践が完了しました。最後に§6で、本記事全体の要点を落とし穴チェックリストとして整理します。

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

本章では、§1〜§5で解説してきた内容を振り返り、大阪リージョンでOCI Generative AIサービスを扱う際に陥りやすい落とし穴を、チェックリスト形式で整理します。

§1では、OCI Generative AIサービスがAWS Bedrockと設計思想は近いものの、日本国内では大阪リージョン限定でGA提供されており東京では使えないという最大の制約を確認しました。§2では、大阪リージョンで実際に呼び出せるモデルラインアップ、Always Free枠が存在しないon-demand従量課金の料金体系、xAI Grokシリーズの大阪非対応という3点を整理しました。§3では、この前提を踏まえてコンソールPlaygroundとCLIの両方でモデル呼び出しを実践しました。§4では、Cohere Embed 4を使った埋め込み生成を、コンソールとCLIの両方で実践しました。そして§5では、Generative AI Agentsを使い、ナレッジベースの作成からエージェントの構築、実際のクエリ実行までのRAG構成を一気通貫で実践しました。

OCI Generative AIサービスは、Amazon Bedrockの運用経験があるAWSエンジニアであれば設計思想自体はスムーズに理解できる一方、日本国内では大阪リージョン限定という提供状況の制約が、他のOCIサービス以上に効いてくる領域です。モデル呼び出し・埋め込み・Agents(RAG)という3機能を一通り実践した本記事の内容をベースに、実際のユースケースに合わせてナレッジベースのデータソース設計やエージェントのツール構成を発展させてみてください。