はじめに
OCIには OCI Generative AI というマネージドな生成AIサービスがあります。CohereやMetaのLlamaをAPI経由で呼べるやつですね。
これをAPEXから使う記事を書こうとしていたのですが、このサービス、東京リージョンでは提供されていません。日本で使うなら大阪一択です。
というわけで大阪リージョンに環境を作りました。大阪ではCohereやLlamaに加えて、GeminiとOpenAIのgpt-ossも選べます。
ただ、選べること自体は分かっていても、実際に日本語を投げたときにどれがどのくらい使えるのかは触ってみないと分かりません。今回は7つのモデルに同じ質問を投げて比べてみます。
目次
- 先に3行でまとめ
- 前提環境
- 東京リージョンでは生成AIが使えない
- 大阪リージョンに行ってみる
- CLIから叩いてみる
- 検証:「破天荒」で日本語力を比べる
- 罠1:thinkingトークンでmaxTokensを使い切る
- 罠2:一覧に出るのに使えないモデルがある
- 課金の話:1トランザクション=1文字、ただし混在している
- まとめ
- 参考リンク
先に3行でまとめ
- 大阪リージョンなら Gemini 2.5 Pro/Flash、gpt-oss-120b/20b、Cohere Command A、Llama 4 が選び放題
- 日本語の「破天荒」テストでは7モデル中3つが誤答。語源を勝手に補足して転ぶパターンが目立った
- thinkingモデルは思考だけでmaxTokensを使い切って本文がゼロになることがある
前提環境
- OCI CLI 3.79.0
- テナンシ2つ(ホームリージョンが東京のものと、大阪のもの)
- 検証日:2026年8月31日
リージョンの違いを見たかったので、たまたま持っていた大阪ホームのテナンシを使っています。
東京リージョンでは生成AIが使えない
冒頭に書いたとおり東京リージョンには無いのですが、「無い」と言われても実際どうなるのか気になったので、一応叩いてみました。
oci generative-ai-inference chat-result chat \
--region ap-tokyo-1 \
--compartment-id $COMPARTMENT_ID \
--serving-mode '{"servingType":"ON_DEMAND","modelId":"google.gemini-2.5-flash"}' \
--chat-request '{"apiFormat":"GENERIC","messages":[{"role":"USER","content":[{"type":"TEXT","text":"test"}]}],"maxTokens":50}'
返ってきたのがこれです。
TransientServiceError:
{
"message": "<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body>\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center></center>\r\n</body>\r\n</html>\r\n",
"operation_name": "chat",
"request_endpoint": "POST https://inference.generativeai.ap-tokyo-1.oci.oraclecloud.com/20231130/actions/chat",
"status": 502,
"target_service": "generative_ai_inference"
}
生のnginxの502が返ってきました。JSONですらないです。
エラー名が TransientServiceError(一時的なエラー)なので、リトライすれば直るのかなと思ってしまいます。
何回叩いても直りませんでした。
モデル一覧は成功する
ややこしいのが、モデル一覧APIは東京リージョンでも成功することです。
oci generative-ai model-collection list-models --region ap-tokyo-1 --compartment-id $COMPARTMENT_ID
東京で見えたモデルは6件でした。
| ベンダー | モデル |
|---|---|
| cohere | cohere.command-a-03-2025 |
| meta | meta.llama-4-scout-17b-16e-instruct |
| meta | meta.llama-3.3-70b-instruct-fp8-dynamic |
| openai | openai.gpt-oss-120b |
| content-moderation | content-moderator |
| protectai | protectai.deberta-v3-base-prompt-injection-v2 |
一覧が返ってくるので、東京でも使えるように見えます。そこで推論を叩くと502。エンドポイント自体は存在していて、その裏に何も居ない状態のようです。
知らずに踏むと、まずIAMポリシーを疑うことになりそうです。
公式ドキュメントを見に行く
生成AIリージョン を見ると、提供リージョンが明記されています。APACだと**日本中央部(大阪)**とインド南部(ハイデラバード)のみ。東京は入っていません。
ただし同じページには「生成AIサービスを呼び出すサービス」という項目もあって、日本については以下のように書かれています。
コール元リージョン: KIX, NRT
宛先リージョン: KIX
NRTは東京です。他のOCIサービスが内部的に生成AIを呼ぶケースでは、東京から呼んでも大阪にルーティングされるようです。今回のように生成AIのAPIを直接叩く場合は話が別で、素直に502が返ってきます。
いずれにせよ自分でAPIを叩くなら大阪です。東京にAlways Freeのリソースを固めている身としては、ここで一度立ち止まることになりました。
大阪リージョンに行ってみる
大阪ホームのテナンシで同じ一覧を叩くと、42件返ってきました。東京の6件とはずいぶん違います。
CHAT系を抜き出すとこんな感じです。
| ベンダー | モデル |
|---|---|
| google.gemini-2.5-pro / google.gemini-2.5-flash | |
| openai | openai.gpt-oss-120b / openai.gpt-oss-20b |
| cohere | cohere.command-a-03-2025 / command-a-reasoning / command-a-vision / command-r-plus-08-2024 |
| meta | meta.llama-4-maverick-17b-128e-instruct-fp8 / meta.llama-4-scout-17b-16e-instruct / meta.llama-3.3-70b-instruct |
埋め込みは cohere.embed-v4.0、リランクは cohere.rerank-v4.0-pro あたりが揃っています。
CohereとLlamaはOCIの元々の品揃えですが、そこにGeminiとgpt-ossが並んでいます。埋め込みやリランクまで含めると、ひととおりの用途はこの中で完結しそうです。
CLIから叩いてみる
実際に呼んでみます。ここで一点ハマりどころがあって、モデルの系統によって apiFormat が違います。
| 系統 | apiFormat | リクエストの書き方 |
|---|---|---|
| google / openai / meta | GENERIC |
messages[].content[].text |
| cohere | COHERE |
message(単一の文字列) |
GENERIC系はこう。
oci generative-ai-inference chat-result chat \
--compartment-id $COMPARTMENT_ID \
--serving-mode '{"servingType":"ON_DEMAND","modelId":"google.gemini-2.5-flash"}' \
--chat-request '{
"apiFormat":"GENERIC",
"messages":[{"role":"USER","content":[{"type":"TEXT","text":"あなたは誰ですか?1文で自己紹介してください。"}]}],
"maxTokens":2000,
"temperature":0.3
}'
返ってきた答えがこちら。
私はGoogleによってトレーニングされた、大規模言語モデルです。
OCI経由で呼んでも、当然ながら「Googleによってトレーニングされた」と名乗ります。モデルの中身はそのままで、呼び出し口がOCIになっているだけかなと。
Cohere系は message に直接文字列を入れます。ここを間違えるとエラーになるので注意です。
--chat-request '{"apiFormat":"COHERE","message":"質問文","maxTokens":2000,"temperature":0.3}'
検証:「破天荒」で日本語力を比べる
せっかく複数のモデルが選べるので、日本語能力を比べてみます。
質問はこれにしました。
「破天荒」の本来の意味を1文で説明してください。
「破天荒」は日本人でも誤用しがちな言葉です。本来は「誰も成し遂げなかったことを初めて行う」という意味で、「豪快」「型破り」は誤用とされています。
このネタ、前回のInklingの記事 でも使いました。あのときInklingは本来の意味を正しく答えた上に、語源(中国・唐代の荊州で科挙の合格者が出ず「天荒」と呼ばれ、劉蛻が初合格して「天荒を破った」)まで正確に出してきています。
今回のモデルたちがどこまでやれるか、という興味もありました。
条件は maxTokens: 2000 / temperature: 0.3 で揃えています。
結果
| モデル | 時間 | 判定 | 応答 |
|---|---|---|---|
| google.gemini-2.5-flash | 3.52s | ○ | それまで誰も成し遂げられなかったことを初めて行う、前例のない偉業を指します |
| google.gemini-2.5-pro | 14.59s | ○ | これまで誰も成し遂げなかったことを初めて成し遂げること |
| cohere.command-a-03-2025 | 1.69s | ○ | 前代未聞の偉業や前例のない優れた業績を成し遂げることを指します |
| meta.llama-4-scout-17b-16e | - | ○ | 今まで誰もやったことがないこと、または、誰も達成したことがないこと |
| openai.gpt-oss-120b | 2.08s | △ | 前例のない・画期的(○)。ただし語源を「天を裂くほどの荒々しさ」と説明(×) |
| meta.llama-3.3-70b-instruct | - | △ | 語源を「天空を覆う雲を払う」と説明(×)、「常識をはるかに超えた」(誤用側) |
| openai.gpt-oss-20b | 1.95s | × | 天と地を破るように従来の常識や慣習を破り、前例のない大胆で極端な行為 |
所感
意味そのものを正しく答えられたのは Gemini 2.5 Flash / Pro、Cohere Command A、Llama 4 Scout の4つでした。
面白かったのは、語源で崩れるパターンが複数あったことです。gpt-oss-120bもllama-3.3-70bも、意味の説明は惜しいところまで行っているのに、聞いてもいない語源を勝手に補足して、そこで間違えています。「天を裂くほどの荒々しさ」も「天空を覆う雲を払う」も、実際の由来(科挙の合格者が出なかった土地から初めて合格者が出た故事)とは違います。
聞かれていないことを喋ると事故る。この辺は人間と同じかもしれません。
ちなみに前回のInklingは、聞いてもいないのに語源まで答えた上で正解していました。喋るなら正確に、ということで・・・笑
一方、gpt-oss-20bは完全に誤用側に流れました。「従来の常識や慣習を破り」は、まさに世間で誤用されている方の意味です。20bというサイズを考えれば健闘している方だとは思います。
地味に優秀だったのがCohere Command Aです。1.69秒、しかも一番短く正確に答えています。
罠1:thinkingトークンでmaxTokensを使い切る
最初は maxTokens: 300 で叩いていました。そうしたら本文が全く返ってきません。
finish-reason: max_tokens
message: null
usage: prompt-tokens=35 / total-tokens=332 / reasoning-tokens=297
message が null です。エラーにはならず、ただ空が返ってきます。
原因は reasoning-tokens: 297 でした。Gemini 2.5 Flashは思考するモデルなので、思考だけでmaxTokensを使い切って、本文を書く前に打ち切られていたようです。
思考の量は先ほどの「破天荒」の検証でもなかなかのものでした。
| モデル | 入力 | 合計トークン | うち思考 |
|---|---|---|---|
| google.gemini-2.5-pro | 15 | 1676 | 1646 |
| google.gemini-2.5-flash | 15 | 305 | 261 |
| cohere.command-a-03-2025 | 17 | 49 | - |
Gemini 2.5 Proは、15トークンの質問に1646トークン考えています。対してCohere Command Aは合計49トークン。34倍の差です。
答えの正しさは同じなので、この質問に関してはProの思考は完全にオーバーキルでした。速度も14.59秒 対 1.69秒です。
thinkingモデルを使うときは、maxTokensに思考分の余裕を見ておく必要があります。用途によっては、thinkingしないモデルを選ぶ方が早いかもしれません。
罠2:一覧に出るのに使えないモデルがある
大阪のモデル一覧に meta.llama-4-maverick-17b-128e-instruct-fp8 が居たので呼んでみたところ、こうなりました。
Entity with key meta.llama-4-maverick-17b-128e-instruct-fp8 not found
一覧には居るのに、not foundです。おそらくオンデマンドでは提供されていない(専用クラスタ向け)のだと思います。一覧を見て選んだ側からすると、ちょっと厳しいです。
同じLlama 4でも meta.llama-4-scout-17b-16e-instruct は普通に動いたので、モデルごとに個別に確認するしかなさそうです。
課金の話:1トランザクション=1文字、ただし混在している
ここが今回一番「へえ」と思ったところです。
公式ドキュメント によると、OCI Generative AIの課金単位はこうなっています。
On the Pricing page,
1 characteris calculated as1 transaction.
トークンではなく「文字」です。そしてチャットの場合は入力と出力の合計になります。
Chat: prompt length (in characters) + response length (in characters)
埋め込みの場合は入力のみが対象になります。
ところがGeminiとgpt-ossはトークン課金
ところが価格表を見ると、Gemini 2.5 Pro と gpt-oss は「1,000,000 tokens」単位で記載されています。Cohere/Llamaが「10,000 transactions(=文字)」単位なのに対して、単位が混在しています。
後から追加されたモデルは、元のベンダーの課金体系をそのまま持ってきているのだと思います。同じサービスの中で単位が違うので、コスト試算のときは注意が必要です。
これは日本語で使う場合にけっこう効いてくる話かなと思っています。日本語は1文字あたりの情報量が多いので、文字課金なら有利になりやすい。逆にトークン課金は、英語よりトークンを食うぶん日本語が不利になりやすいはずです。同じ用途でもモデルの選び方で差が出そうです。
実測してみる
今回のCohere Command Aの呼び出し1回を計算してみます。
- 質問:
「破天荒」の本来の意味を1文で説明してください。= 24文字 - 応答:
「破天荒」の本来の意味は、前代未聞の偉業や前例のない優れた業績を成し遂げることを指します。= 45文字 - 合計:69文字 = 69トランザクション
Cohere系のオンデマンド単価の参考値 $0.0219 / 10,000トランザクション で計算すると、
69 / 10,000 × $0.0219 = $0.000151
約0.02円です(150円/ドル換算)。
この規模だと誤差です。ただ文字課金ということは、長文を投げるとそのまま効いてきます。RAGで大量のコンテキストを詰め込むような使い方だと、事前に試算しておいた方が良さそうです。
上の単価はCohere系の参考値です。単価はモデルとリージョンによって変わりますし、価格改定もあります。実際に使う前に必ず公式の価格表で確認してください。
まとめ
- OCI Generative AIのAPIは東京リージョンでは叩けない。日本では大阪一択
- モデル一覧APIは東京でも成功するが、推論を叩くと生の502が返る。知らないとIAMを疑うことになる
- 大阪ではCohere/Llamaに加えてGeminiとgpt-ossも選べる。埋め込み・リランクまで揃っている
- 日本語の「破天荒」テストでは Gemini 2.5 Flash/Pro、Cohere Command A、Llama 4 Scout が正解
- 聞かれてもいない語源を補足して間違えるモデルが複数。余計なことを喋ると事故る
- thinkingモデルはmaxTokensを食い潰す。300だと本文がゼロになった
- 課金は 1トランザクション=1文字。ただしGemini/gpt-ossはトークン課金で単位が混在している
東京リージョンに一式を構えている身としては、「生成AIだけ大阪」というのは地味に悩ましい構成です。ただ、大阪にテナンシを1つ作ればGeminiもgpt-ossもCohereも一通り触れるので、検証環境としては悪くないと思いました。
次はこれをAPEXから呼んで、Autonomous Databaseの上で動く生成AIアプリを作るところまでやってみようかと思います。東京のADWから大阪のGen AIをまたいで呼べるのか、というのが目下の課題です。うまくいったらまた書きます。