OCI Generative AIの新機能でAttributeError？必要なSDK・CLIバージョンを確認する

この記事はAI実用ラボがTipsで公開した無料記事のBlogger版です。

OCI Generative AIの新機能でAttributeError？必要なSDK・CLIバージョンを確認する

【中級者向け】OCI Python SDKまたはOCI CLIで既にGenerative AIサービスを使っている開発者・運用者向けの内容です。SDK/CLIの基本操作、IAM（Identity and Access Management、権限管理の仕組み）ポリシーの基礎知識を前提とします。

OCIの新機能を試そうとしてAttributeErrorが出たり、CLIでコマンドが見つからなかったりしたときは、SDK・CLIのバージョンを最初に確認しましょう。この記事では、モデルディスカバリーとルーティングプロファイルを例に、必要なバージョン、メソッドの有無、権限、モデルとリージョンの組み合わせを順番に切り分けます。バージョンの古さは原因の一つですが、エラー名だけで原因を決めつけないことも大切です。

先に要点：Python SDKから管理操作を使うならoci 2.187.0、CLIならoci-cli 3.94.0で追加された機能に対応しているか確認します。モデルディスカバリーはCLI/APIで利用し、Consoleにはありません。一方、ルーティングプロファイルの作成・管理はConsoleからも行えます。バージョン確認の後に、権限とモデルの提供リージョンを確かめてください。

この記事でできること

自分の環境のOCI SDK/CLIが新機能に対応しているかを確認する
バージョンが古いときに実際に何が起きるか（実機で再現したAttributeErrorの状態）を理解する
モデルディスカバリーで対象モデルを検索し、ルーティングプロファイルを作成・更新する具体的な手順を実行する
遭遇しうるエラーパターンと、現時点での制限事項を把握する

対象読者

OCI Python SDKまたはOCI CLIで、Generative AIサービス（Cohere・Meta Llama・Google Geminiなどのモデルをオンデマンドで呼び出せるOCIのマネージドサービス）を既に使っている人
`pip install oci`を一度実行しただけで、その後バージョンを上げずに使い続けている人（`requirements.txt`でバージョンを固定＝pinしている環境は特に該当しやすい）
IAMポリシー（コンパートメントごとの権限設定）を自分で編集できる人

対象バージョンと確認日

項目	値
モデルディスカバリー/ルーティングプロファイルのリリース日	2026-09-23（公式リリースノート）
必要なOCI Python SDKバージョン	2.187.0以降（2026-09-22公開）
必要なOCI CLIバージョン	3.94.0以降（2026-09-22公開）
旧版で比較したSDKバージョン	2.175.0（対象メソッドがないことを確認）
公式ドキュメント最終確認日	2026-09-27

背景：なぜ「発表を読んだのに動かない」が起きるのか

今回のケースで少し珍しいのは、機能の実装（SDK/CLIへのコード追加）が2026-09-22、公式リリースノートでの告知が2026-09-23と、**実装が発表より1日先行していた**ことです。GitHub上のSDK/CLI変更履歴（CHANGELOG.rst）にはどちらも「2.187.0 - 2026-09-22」「3.94.0 - 2026-09-22」の項目に、Generative AIのルーティングプロファイル・モデルディスカバリー対応が明記されています。PyPI（Pythonパッケージの配布サイト）の公開時刻を見ても、`oci`パッケージ2.187.0は2026-09-22 01:55:22 UTC、`oci-cli`パッケージ3.94.0は同日07:38:49 UTCに公開されており、リリースノートより前にパッケージ自体は誰でも取得できる状態になっていました。

初回セットアップでpip install ociを実行した後、更新せずに使い続けている環境では、新しい機能がまだ入っていない場合があります。requirements.txtなどでバージョンを固定している場合も、指定を見直すまで同じ版を使い続けます。公式サンプルを写しても、実際に起動したPythonが読み込むSDKにメソッドがなければ動きません。更新したはずなのに同じエラーが出るときは、別の仮想環境や別のPythonを使っていないかも確認してください。

ユウ
え、リリースノートを読んだその日に試したのに、もう新しいSDKが必要だったなんて気づきませんでした…

ラボ長
実はSDK/CLI自体は2026-09-22、リリースノートの告知は2026-09-23なんです。実装のほうが1日早く公開されていたので、告知だけ読んでもバージョンのズレには気づけないんですよ。

何が便利になるのか：従来のやり方との違い

項目	従来のやり方	モデルディスカバリー/ルーティングプロファイル
利用可能なモデルの確認	Consoleやドキュメントのモデル一覧ページを目視で確認	list-model-discoveryでcapability（対応する処理の種類）・提供モードなどを絞り込み、検索結果に提供終了予定日が含まれる場合は確認できる
リージョンをまたぐフェイルオーバー	アプリ側でリージョンごとのエンドポイントを自前実装	ルーティングプロファイルを作成し、Chat API/Responses APIから参照する（現時点ではオンデマンドモデルのみ対応）
モデルの提供終了（retirement）の把握	個別にドキュメントを確認	モデルディスカバリーの検索結果にretirement dateが含まれる場合がある

モデルディスカバリーはCLIまたはAPIで利用します。ルーティングプロファイルはConsole、CLI、APIから作成・管理できます。Consoleで使えないという制約を両機能に広げないよう、操作する対象を分けて考えてください。

必要なもの

OCIテナンシと、操作対象のコンパートメントOCID（Oracle Cloud Identifier、OCIリソースを一意に識別するID文字列）
実行する操作と対象コンパートメントに対応したIAM権限。ルーティングプロファイル用の権限を、モデル検索や推論の権限と混同しないこと
Python 3.x環境（SDKを使う場合）またはOCI CLI（コマンドラインで操作する場合）
使いたいモデルが、対象リージョンでオンデマンド提供されていることの事前確認（リージョンによって提供状況が異なる）

全体像：バージョン確認から利用開始までの流れ

大まかな流れは次の順番です。①自分の環境のSDK/CLIバージョンを確認する→②新機能に対応したバージョンでなければアップグレードする（このときBreaking Changesも必ず確認する）→③対象コンパートメントにIAM権限があるか確認する→④モデルディスカバリーで使いたいモデルとその提供リージョンを検索する→⑤検索結果をもとにルーティングプロファイルを作成する。この順番を飛ばしてルーティングプロファイルの作成だけ先に試すと、モデルが対象リージョンで使えるかの確認が抜け落ちたまま設定してしまうことがあります。

ここから先は、この5ステップをコマンド付きで実行し、実際に遭遇するAttributeErrorの再現結果、IAMポリシーの具体例、ルーティングプロファイルのJSON設定例、そしてエラーが起きたときの切り分け方まで一通り扱います。

具体的手順

1. 自分の環境のSDK/CLIバージョンを確認する

まずPython SDKのバージョンを確認します。

python3 -c "import oci; print(oci.__version__)"

旧版のoci 2.175.0で確認した出力例です。

2.175.0

必要なバージョンは2.187.0以降なので、この結果は「新機能未対応」を意味します。2.187.0以降が表示されればこのステップは完了です。

CLIを使う場合はoci --versionで確認します。対象の管理コマンドはoci-cli 3.94.0で追加されています。以下のCLI例は公式コマンドリファレンスに基づき、OCIDやモデル名を自分の対象に置き換える形で示します。

2. 新機能に対応したメソッドがあるかその場で確認する

バージョン番号だけでなく、実際に該当メソッドが存在するかも確認できます。

python3 -c "
from oci.generative_ai import GenerativeAiClient
methods = [m for m in dir(GenerativeAiClient) if 'model_discovery' in m.lower() or 'routing_profile' in m.lower()]
print(methods)
"

2.175.0環境での実行結果は次のとおりでした。

[]

空リストが返ってきたということは、`list_model_discovery`や`create_routing_profile`に相当するメソッドがクライアントクラスに存在しないことを意味します。この状態でこれらのメソッドを呼び出そうとすると`AttributeError`になります。2.187.0以降にアップグレードすると、このリストに該当メソッドが含まれるようになります。

3. アップグレード前にBreaking Changesを確認する

`pip install --upgrade oci`（CLIなら`pip install --upgrade oci-cli`）でアップグレードする前に、CHANGELOG.rstのBreaking（破壊的変更）セクションを確認してください。2.187.0には、Generative AIとは無関係な次の変更が同梱されています。

`oci.distributed_database_v26`パッケージ名のリネーム
Functionsサービスの`CreateFunctionDetails`などから`image`/`image_digest`フィールドが削除
DataSafeClientのactivate_target_databaseメソッドなどで、activate_target_database_details引数が必須の位置引数から任意のキーワード引数へ変更

これらはGenerative AIだけを使っている場合は直接の影響はありませんが、「新機能と無関係な変更が同じバージョンに同梱される」ことがある実例です。他のOCIサービスも同じSDKで呼び出している場合は、アップグレード前に必ずCHANGELOG全体に目を通してください。

4. IAM権限を用意する

ルーティングプロファイルには専用のリソースタイプ`generative-ai-routing-profile`があり、次のポリシー例文が公式ドキュメントに掲載されています。

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

より広い範囲をまとめて許可する場合は`generative-ai-family`を使い、ルーティングプロファイルだけに絞る場合は次のようにします。

allow group <your-user-group> to manage generative-ai-routing-profile
in compartment <your-compartment-name>

権限を細かく分けたい場合の対応表は次のとおりです。

Permission	APIオペレーション	Verb
GENERATIVE_AI_ROUTING_PROFILE_INSPECT	ListRoutingProfiles	inspect
GENERATIVE_AI_ROUTING_PROFILE_READ	GetRoutingProfile	read
GENERATIVE_AI_ROUTING_PROFILE_UPDATE	UpdateRoutingProfile	use
GENERATIVE_AI_ROUTING_PROFILE_MOVE	ChangeRoutingProfileCompartment	manage
GENERATIVE_AI_ROUTING_PROFILE_CREATE	CreateRoutingProfile	manage
GENERATIVE_AI_ROUTING_PROFILE_DELETE	DeleteRoutingProfile	manage

上の権限例と対応表はルーティングプロファイルの管理操作を対象にしています。モデルディスカバリーの権限を、この表だけから決めることはできません。解説ページが見つからないという理由でmanage generative-ai-familyを一律に付与せず、実行するAPI、対象コンパートメント、既存ポリシーを管理者と確認してください。権限の不足とSDKのメソッド不存在は別の問題として切り分けます。

ユウ
list-model-discoveryのオプションに--region-parameterconflictってありますけど、これ名前が変じゃないですか?

ラボ長
公式CLIリファレンスには、その名前でリージョンを絞るオプションが載っています。共通の--regionと混同せず、モデル検索の条件には--region-parameterconflictを使ってください。名前の付いた経緯を知らなくても、各オプションの説明を分けて読むと設定を間違えにくくなります。

5. モデルディスカバリーで対象モデルを検索する

CLIでの基本形は次のとおりです。--compartment-idは必須です。YOUR_COMPARTMENT_OCIDを自分のコンパートメントOCIDへ置き換えてから実行してください。以降の例でも同じ変数を使います。

export compartment_id='YOUR_COMPARTMENT_OCID'
oci generative-ai model-discovery-collection list-model-discovery --compartment-id "$compartment_id"

主な絞り込みオプションは次のとおりです。

オプション	指定できる値
`--capability`	CHAT, TEXT_EMBEDDINGS, TEXT_GENERATION, TEXT_RERANK, TEXT_SUMMARIZATION, TEXT_TO_IMAGE, IMAGE_TEXT_TO_TEXT ほか
`--model-access`	HOSTED, PROXY
`--serving-mode`	DEDICATED, ON_DEMAND
`--realm`	対象realm（OCIのリージョン群を束ねる区分）
`--is-deprecated` / `--is-on-demand-retired` / `--is-dedicated-retired`	true/false

モデルの提供リージョンを絞るオプション名は--region-parameterconflictです。共通オプションの--regionとは別の項目なので、同じものと思って置き換えないでください。必要な条件を一つずつ加え、条件を外したときと結果がどう変わるかを確認すると、指定の誤りとモデルの未提供を切り分けやすくなります。

6. ルーティングプロファイルを作成する

Console（ブラウザ）から作る場合の手順は次のとおりです。

Routing profilesの一覧ページを開く
「Create routing profile」をクリック
名前・コンパートメント・（任意）説明・（任意）タグを入力
Configuration欄でモデルを1つ選択
Target OCI regionsで、そのモデルが利用できるリージョンを1つ以上選択
「Create」をクリック

CLIでは次のコマンドになります。`--compartment-id`と`--display-name`が必須です。

oci generative-ai routing-profile create \
  --compartment-id "$compartment_id" \
  --display-name "my-routing-profile" \
  --model-routing-policy '{"allowedModels": ["MODEL_ID_FROM_DISCOVERY"]}' \
  --region-routing-policy '{"allowedRegions": ["REGION_ID_FOR_SELECTED_MODEL"]}'

MODEL_ID_FROM_DISCOVERYは、モデル検索で確認した対象モデルの識別子に置き換えてください。REGION_ID_FOR_SELECTED_MODELには、そのモデルを利用できるリージョンの正式な識別子を入れます。例は設定形式を示すためのもので、置換用の文字列のまま実行するものではありません。--model-routing-policyと--region-routing-policyはJSON文字列、またはfile://で指定したJSONファイルを受け取ります。SDKの対応表ではallowedModelsとallowedRegionsが実際のJSONキーです。いずれも配列で、順序は保持され、重複は認められません。リージョンポリシーを指定しない場合はローカルリージョンだけが許可されると定義されています。SDKの型が配列でも、今回の機能説明で選択する対象は対応するオンデマンドモデル1つです。複数モデルへの振り分けができると読み替えず、そのモデルが使える同一realm内のリージョンを選んでください。

このリリースでモデルルーティングプロファイルが対応するのは**オンデマンドモデルのみ**です。専用キャパシティ（dedicated）のモデルは対象外です。

7. ルーティングプロファイルを更新する

作成後に名前・説明・対象モデル・対象リージョンを変更する場合は、CLIのupdateサブコマンドを使います。YOUR_ROUTING_PROFILE_OCIDは作成したプロファイルのOCIDに置き換えます。以下は名前だけを変更する例です。

routing_profile_id='YOUR_ROUTING_PROFILE_OCID'
oci generative-ai routing-profile update \
  --routing-profile-id "$routing_profile_id" \
  --display-name "updated-routing-profile"

変更できるパラメータは`--display-name`、`--description`、`--model-routing-policy`、`--region-routing-policy`です。公式ドキュメントは、**モデルを変更した場合は、既存の対象リージョンがその新しいモデルでも利用可能かを改めて確認するように**明記しています。モデルによって提供リージョンが異なるため、モデルだけ変えてリージョンをそのままにすると、実際には使えないリージョンが残ってしまう可能性があります。

8. 推論リクエストへつなぐ前に確認すること

公式リリースノートは、Chat APIまたはResponses APIのリクエストでルーティングプロファイルを参照して使うと説明しています。また、公式のIAM説明には、ルーティングプロファイルのOCIDをモデルとして使う推論リクエストでは、推論操作の権限に加えてGENERATIVE_AI_ROUTING_PROFILE_READが必要と記されています。したがって、SDKにroutingProfileIdという名前の専用フィールドが見つからないだけで「まだ実装されていない」「今後の実装を待つ」と結論づけることはできません。

この記事のコマンド例は、モデルの検索とプロファイルの作成・更新・一覧確認までを扱います。アプリからの推論を接続するときは、利用するAPIや互換エンドポイントに対応した公式のリクエスト形式を確認してください。プロファイルの管理用クライアントと推論用クライアントを区別し、指定するモデル値、プロファイルの読み取り権限、推論そのものの権限を別々に確認します。管理操作が成功したことだけを、推論まで成功した証拠にしないのが確認の要点です。

動作確認

作成したルーティングプロファイルが有効になっているかは、一覧コマンドで確認します。

oci generative-ai routing-profile-collection list-routing-profiles \
  --compartment-id "$compartment_id" \
  --lifecycle-state ACTIVE

--lifecycle-stateにはACTIVE、CREATING、DELETED、DELETING、FAILED、UPDATINGを指定できます。まず一覧で対象の名前とOCIDが合っているかを確認し、状態を見ます。ACTIVEだけに絞って見つからない場合は、フィルタを外してCREATINGやFAILEDなど別の状態になっていないかを確認してください。ACTIVEは管理上の状態を確認する目安であり、推論リクエストの権限や対象モデルの利用まで自動的に保証するものではありません。

モデルディスカバリー側は、検索結果に対象モデルが含まれているかを確認します。`--capability CHAT`のように絞り込んだ上で、意図したモデルIDが結果に出てくるかを見てください。出てこない場合は、そのリージョン・realmでは該当モデルが提供されていない可能性があります。

応用・実践パターン

パターンA：検証環境とCI/共有環境でアップグレード方針を分ける

個人の検証環境では`pip install --upgrade oci`で都度最新化してよいですが、CI環境やチーム共有環境では`requirements.txt`にバージョンを明示的に固定していることが多く、そこが今回のようなバージョンギャップの温床になります。新機能を試す前提があるなら、`requirements.txt`の更新をコードレビューの一項目にし、「新しい公式リリースノートを読んだら、まず自分のrequirements.txtのバージョンを確認する」という手順を先に組み込んでおくと、同じ詰まり方を防げます。

パターンB：モデルディスカバリーを導入前チェックの自動化に使う

従来は新しいリージョンへ展開する前に、ドキュメントを目視でモデルの提供状況を確認する必要がありました。モデルディスカバリーはCLI/APIから呼べるため、デプロイ前チェックのスクリプトに組み込み、「対象モデルが対象リージョンでオンデマンド提供されているか」を自動確認するステップとして使えます。手動確認からコード化への移行は、この記事の「何が便利になるのか」で挙げた比較表の具体的な活用例にあたります。

パターンC：アップグレード時はBreaking Changesを毎回確認する運用にする

前述のとおり、2.187.0にはGenerative AIと無関係なBreaking Changesが同梱されていました。新機能ほしさにアップグレードしたら、既存のFunctionsやData Safe連携コードが壊れた、という事故を防ぐには、アップグレード作業のチェックリストに「CHANGELOGのBreaking節を読む」ことを組み込んでおくのが安全です。

パターンD：権限エラーは操作と対象を絞って確認する

権限エラーが出たら、まず失敗した操作がモデル検索、プロファイル管理、推論のどれかを記録します。次に対象コンパートメントと操作を実行したユーザーまたはグループを確認します。ルーティングプロファイルなら、一覧にはinspect、取得にはread、更新にはuse、作成や削除にはmanageという対応表と照合できます。推論時にはプロファイルの読み取り権限も必要です。解説が見つからないことを理由にサービス全体の管理権限へ広げるのではなく、不足する操作を特定して必要な範囲を管理者に依頼してください。

ユウ
AttributeErrorが出たら、とりあえずSDKのバージョンを疑えばいいですか?

ラボ長
まずバージョンとメソッドの有無を確認すると切り分けが早いです。旧版2.175.0では、今回の対象メソッドがdir()の結果に出ないことを確認しました。更新したのに変わらないときは、実際に起動したPythonと更新対象の環境が同じかも見てください。

エラー対処

症状	原因	対処
`AttributeError: 'GenerativeAiClient' object has no attribute 'list_model_discovery'`（または`create_routing_profile`）	旧版SDKなど、実行中のクライアントに対象メソッドがない	`python3 -c "import oci; print(oci.__version__)"`でバージョンを確認し、2.187.0以降へアップグレードする
CLIで`generative-ai model-discovery-collection`や`routing-profile`のコマンドグループ自体が見つからない	旧版CLIや、想定と異なるCLIを実行している可能性。対象管理コマンドの追加は3.94.0	`oci --version`を確認し、3.94.0以降へアップグレードする
ルーティングプロファイル作成時に対象モデルが選択肢に出ない、または検索結果に含まれない	対象モデルの提供リージョン・提供モード・realmなどが条件に合っていない可能性	モデルディスカバリーで対象モデル・対象リージョンの組み合わせを事前に検索し、提供されている組み合わせだけを選ぶ

注意点・制限事項

モデルディスカバリーはCLI/APIで利用する。ルーティングプロファイルの作成・管理はConsoleからも行える。
ルーティングプロファイルは対応するオンデマンドモデル1つと、そのモデルが利用できる同一realm内の1つ以上のリージョンを対象にする。
SDKで専用フィールドが見つからないことだけを理由に、推論側の機能が未実装だと判断しない。利用するAPIの公式形式を確認する。
ルーティングプロファイルの権限表をモデル検索の権限にそのまま当てはめない。推論では推論操作の権限に加えてプロファイルの読み取りも必要になる。
CLI例の置換用文字列は、自分のコンパートメント・プロファイル・選択モデルに合わせる。管理操作と推論の動作確認を分ける。
モデルの提供リージョンは、実際に設定するときにモデル検索または公式の提供状況ページで確認する。

早見表

操作	必要なもの	備考
SDKバージョン確認	`python3 -c "import oci; print(oci.__version__)"`	2.187.0以降が必要
CLIバージョン確認	`oci --version`	今回の管理コマンドは3.94.0で追加
モデル検索	oci generative-ai model-discovery-collection list-model-discovery --compartment-id "$compartment_id"	`--capability`等で絞り込み可
ルーティングプロファイル作成	oci generative-ai routing-profile create --compartment-id "$compartment_id" --display-name "my-routing-profile"	`--model-routing-policy`/`--region-routing-policy`は任意
ルーティングプロファイル更新	oci generative-ai routing-profile update --routing-profile-id "$routing_profile_id"	モデル変更時は対象リージョンを再確認
ルーティングプロファイル一覧	oci generative-ai routing-profile-collection list-routing-profiles --compartment-id "$compartment_id"	`--lifecycle-state ACTIVE`等で絞り込み可
サービス全体の管理権限の例	manage generative-ai-family	広い管理権限。モデル検索のために一律付与する根拠にはしない
必要なIAM権限（ルーティングプロファイルのみ）	`manage generative-ai-routing-profile`	細分化した権限名は本文の表を参照

ユウ
結局、今日からまず何をすればいいですか?

ラボ長
まずはご自分の環境でimport oci; print(oci.__version__)を実行してみてください。2.187.0未満なら、CHANGELOGのBreaking Changesを確認してからアップグレードする、という順番が安全です。

まとめ

今回の管理操作はPython SDK 2.187.0／OCI CLI 3.94.0で追加された。使う経路のバージョンとメソッド・コマンドの有無を確かめる。
AttributeErrorは対象メソッドがない場合に起きる。旧版だけでなく、実際に起動しているPython環境も切り分ける。
Consoleにないのはモデルディスカバリー。ルーティングプロファイルはConsoleからも作成・管理できる。
ルーティングプロファイルは、対応するオンデマンドモデルと同一realm内の提供リージョンを選ぶ。
推論への接続では利用するAPIの形式と権限を確認する。専用フィールドがないことを未実装の証拠にしない。
アップグレード前にはCHANGELOGのBreaking節を読み、他のOCIサービスへの影響も確認する。

参考にした公式情報

OCIリリースノート「Model discovery」「Regional smart model router」（確認日2026-09-27）
OCI Generative AIドキュメント「Model discovery」「Routing profiles」「Create a routing profile」「Update a routing profile」（確認日2026-09-27）
OCI CLIコマンドリファレンス（model-discovery-collection、routing-profile、routing-profile-collection）（確認日2026-09-26）
OCI IAMポリシードキュメント「Routing profile permissions」（確認日2026-09-26）
oci-python-sdk / oci-cli 公式CHANGELOG.rst（GitHub、確認日2026-09-26）
PyPI公開情報（`oci`、`oci-cli`パッケージ、確認日2026-09-26）
oci-python-sdkソースコード（`generative_ai`・`generative_ai_inference`パッケージ、GitHub、確認日2026-09-26）
OCI Generative AI「Model endpoint regions」ドキュメント（確認日2026-09-26）

Tipsで元記事を見る

プライバシーポリシー｜ AI実用ラボについて｜お問い合わせ

AI実用ラボ

このブログを検索