OCI Data Science実践｜ノートブックからモデルデプロイMLOps E2E

1. 概要 — なぜOCI Data Scienceか

OCIには、機械学習・AIに関連するサービスが複数存在します。混同しやすいため、本記事の冒頭でまず全体地図を示します。1つ目は、MySQL HeatWaveのAutoML機能に代表される「in-database ML」で、SQLのCALL文を使ってデータベースエンジン内で完結する分析です。2つ目は、Generative AI実践Vol1で扱った「マネージドLLM API」で、Cohereなどの事前学習済みモデルをAPI経由で呼び出す形態です。そして3つ目が、本記事で扱う「OCI Data Science」です。これは、Jupyterノートブックを使って独自のモデルを学習し、モデルカタログに登録した上でHTTPエンドポイントとしてデプロイするという、AWSのSageMakerに相当する独立したMLOpsプラットフォームです。

AWS実務者にとって最も理解しやすい対応関係は、SageMaker Studioとの対比です。SageMakerのノートブックインスタンス(またはStudio Notebooks)に相当するのがOCIの「ノートブックセッション」、SageMakerのモデルレジストリに相当するのが「モデルカタログ」、SageMakerのエンドポイントに相当するのが「モデルデプロイ」です。さらにSageMaker Pipelinesに相当する「Pipelines」、SageMaker Processing/Training Jobに相当する「Jobs」も用意されており、概念上の対応はかなり素直です。ただし、課金体系や最小構成の作法には違いがあり、この点は§5で詳しく扱います。

この対応関係を、表として整理すると次のようになります。

このように主要概念はほぼ1対1で対応しており、SageMakerの経験があれば学習コストは低く抑えられます。ただし、この表の各行には見た目以上の実務差分が存在するため、代表的なものを補足しておきます。

まず「Studioドメイン/プロジェクト」対「プロジェクト」の対応です。SageMaker Studioのドメインは、IAMロールやVPC設定、ユーザープロファイルといったガバナンス要素を束ねる比較的重量級の概念ですが、OCIの「プロジェクト」はもっと軽量で、単なる作業コンテナに近い位置づけです。権限やネットワーク設定はプロジェクト自体には紐づかず、コンパートメント単位のIAMポリシーと、ノートブックセッション/モデルデプロイ個々のネットワーキング設定で決まります。そのため、SageMaker Studioのドメイン作成のような重い初期設定は不要で、プロジェクトはほぼ「フォルダを作る」感覚で気軽に作成・削除できます。

次に「ノートブックインスタンス/Studio Notebooks」対「ノートブックセッション」です。SageMakerのクラシックなノートブックインスタンスは、インスタンスタイプごとに独立したEC2ライクなリソースとして起動しますが、OCIのノートブックセッションはVMシェイプ(OCPU数・メモリ量)とBlock Storageを個別に指定して起動する構成です。SageMaker Studio Notebooksのように、1つの実行環境(App)に複数のカーネルをぶら下げる構成とは異なり、OCIでは1つのノートブックセッションが1つのJupyterLab環境に対応します。課金面では、SageMakerのノートブックインスタンスが「起動している間は常に課金」される点は共通ですが、OCIでは非アクティブ化とBlock Storage保持の関係(§6で詳述)がやや独特です。

「モデルレジストリ」対「モデルカタログ」の差分としては、SageMakerのモデルレジストリがモデルパッケージグループによるバージョン管理・承認ワークフロー(Approved/Rejected/PendingManualApproval等のステータス)を標準搭載しているのに対し、OCIのモデルカタログはよりシンプルなアーティファクト保管庫という性格が強く、承認ワークフローに相当する機能は標準では持ちません。厳密な承認プロセスをモデルカタログの前段に置きたい場合は、OCI DevOpsのパイプラインやカスタムの運用フローで補う設計になります。

最後に「エンドポイント」対「モデルデプロイ」ですが、SageMakerのリアルタイムエンドポイントがマルチモデルエンドポイントやサーバーレス推論(Serverless Inference)といった複数の提供形態を選べるのに対し、OCIのモデルデプロイは基本的に単一モデル・専用インスタンスでのホスティングが中心です(§2-1で触れたOpenAI互換エンドポイント対応は、この提供形態自体を変えるものではなく、リクエスト/レスポンスの互換性を高めるものです)。マルチモデル配下でのコスト最適化を重視する場合は、SageMakerのマルチモデルエンドポイントに相当する仕組みがOCI側にはまだ薄い、という点は移行検討時に押さえておくべき差分です。

こうした概念対応を踏まえると、SageMakerからOCI Data Scienceへの移行を検討する際の判断軸も見えてきます。単純な「ノートブックで学習してエンドポイントを立てる」という基本ワークフローであれば、概念の1対1対応がそのまま活きるため移行コストは低めです。一方で、モデルレジストリの承認ワークフローやマルチモデルエンドポイントといった、SageMaker側の高度な運用機能に強く依存している構成の場合は、OCI側で同等の機能を自前で組み立てる追加設計が必要になります。既にOCIの他サービス(Autonomous DatabaseやHeatWave等)を利用しておりマルチクラウドの運用コストを下げたい場合や、逆にAWS側の高度なMLOps機能をフル活用したい場合かで、判断は分かれるでしょう。

1-1. SageMakerからの移行判断チェック

移行の要否を検討する際の判断軸を、表として整理します。

具体的な移行シナリオとして、次の3パターンを想定しておくと判断がしやすくなります。

1. シナリオA: 新規PoCをそのままOCIで再現したい — 単純な学習→デプロイのワークフローで、SageMakerの高度な機能に依存していない場合です。本記事冒頭の概念対応表がほぼそのまま活用でき、移行コストは低いと想定されます。
2. シナリオB: モデルレジストリの承認ワークフローに依存している — SageMakerのモデルパッケージグループとステータス管理を運用の前提にしている場合です。OCI側は標準機能では承認ワークフローを持たないため、OCI DevOpsパイプライン等での代替設計が必要になります。
3. シナリオC: マルチモデルエンドポイントでコスト最適化している — 1つのエンドポイント上で多数の軽量モデルを切り替えて提供し、インスタンスコストを抑えている場合です。OCIのモデルデプロイは単一モデル・専用インスタンスが基本であるため、同等の構成をそのまま持ち込むことは難しく、複数の小規模モデルデプロイに分割するか、Jobsベースのバッチ推論に設計を見直す検討が必要です。

いずれのシナリオでも、まずは本記事のような最小構成のE2Eハンズオンで基本ワークフローの操作感を掴んでから、自社の既存SageMaker構成のどの部分が「単純な移植で済むか」「追加設計が必要か」を切り分けていくのが現実的な進め方です。

1-2. OCIのAI 3路線における本記事の位置づけ

§1冒頭で触れたOCIのAI 3路線について、想定読者や操作言語といった軸で違いを整理すると、次のようになります。

この3路線が並立している背景には、「データベース内で完結する分析」「既存モデルを手軽に呼び出す」「独自モデルを本格的に運用する」という、要求される専門性も課金モデルも異なる3つのユースケースを、それぞれ最適化されたサービスとして提供するというOCIの設計思想があります。1つの巨大なサービスで全てを賄うのではなく、SQLだけで完結したいDBA向けの入口としてHeatWave AutoMLを、既存LLMを手軽に呼びたいアプリ開発者向けの入口としてGenerative AIサービスを、そして本格的なMLOpsを必要とするMLエンジニア向けの入口として本記事のData Scienceを用意する、というように入口を分けることで、それぞれの読者が最小の学習コストで目的のサービスへたどり着けるようになっています。本記事を読み終えた後、HeatWave AutoML実践やGenerative AI実践Vol1にも目を通していただくと、OCIのAI関連サービス全体の地図がより立体的に見えてくるはずです(3路線の詳細な比較表は§7にまとめています)。

1-3. 移行検討時の実務ステップ

実際にSageMakerからOCI Data Scienceへの移行を検討する場合、次のようなステップで進めると、判断に必要な材料を漏れなく揃えられます。

1. 既存ワークフローの棚卸し: 現行のSageMaker構成で、ノートブック学習・モデルレジストリ・エンドポイント・Pipelinesのどこまでを使っているかを一覧化します。
2. 依存機能の特定: §1-1の判断軸表を使い、承認ワークフローやマルチモデルエンドポイントなど、OCI側で標準対応していない機能への依存度を確認します。
3. PoC範囲の決定: 依存度が低い部分(単純な学習→デプロイのワークフロー)から先にPoCの対象として切り出します。本記事の最小構成ハンズオン(§4)は、このPoCの出発点として利用できます。
4. 課金試算の実施: §5のCost Estimatorを使い、想定する利用規模(ノートブックセッションの稼働時間、モデルデプロイのインスタンス数等)での月額概算を試算します。
5. クリーンアップ運用の設計: §6で扱う「非アクティブ化≠課金全停止」の挙動を踏まえ、検証環境の自動クリーンアップ運用(スケジュールJobsでの定期削除等)をあらかじめ設計しておきます。
6. 段階的な本移行: PoCで問題がなければ、依存度の高い機能について代替設計(OCI DevOpsパイプラインでの承認フロー再現等)を個別に詰めた上で、段階的に本移行を進めます。

このステップを踏むことで、「まず動かしてみたら想定外の機能差にぶつかった」という手戻りを避けやすくなります。特に4番目の課金試算と5番目のクリーンアップ運用設計は、OCI特有の癖(§6で詳述)を理解してから着手することが重要です。

1-4. 必要になるスキルセットの目安

移行を担当するチームがすでに持っているスキルと、追加で必要になる知識の目安を整理しておきます。

表からも分かるとおり、モデル学習コード自体はフレームワーク非依存な部分が多く、ほぼそのまま流用できます。一方でインフラ操作・IAM設計・ネットワーキングは、概念は似ていても操作画面やコマンド体系が異なるため、本記事のようなハンズオンを通じて実際に手を動かしながら差分を埋めていくのが効率的です。特にIAMの動的グループは、AWSのIAMロールと似て非なる概念であるため、§3で扱う具体例を通じて感覚を掴んでおくことをお勧めします。

本記事のゴールは、この対応関係を踏まえた上で、実際にOCIコンソール(および一部CLI)を操作し、プロジェクト作成からノートブックセッションでの学習、モデルカタログへの登録、モデルデプロイ、推論呼び出し確認、そしてクリーンアップまでを一気通貫で体験することです。ノートブックセッションはAlways Free枠の対象外であり有償のCompute/Block Storageが前提となるため、最小構成での課金試算(§5)と、誤課金を防ぐためのクリーンアップ手順(§6)を特に丁寧に扱います。

なお、本記事はOCIのAI関連サービス3路線のうち3つ目にあたります。1つ目のin-database ML(HeatWave AutoML)はデータベースエンジン内で完結する分析、2つ目のマネージドLLM API(Generative AI実践Vol1)はOracleがホストする事前学習済みモデルの呼び出しでした。本記事のOCI Data Scienceは、この2つとは異なり「自分でモデルを学習し、自分でホスティング基盤を管理する」独立したMLOpsプラットフォームという位置づけです。既刊2本を読んでから本記事に進むと、OCIのAI関連サービス全体の地図がより立体的に理解できます(詳細な比較は§7で扱います)。

まだOCIのテナンシ・コンパートメント・リージョンといった基礎概念に触れたことがない方は、先に入門シリーズをご確認いただくと本記事の手順がスムーズです。特に、§3で扱うコンパートメント単位のIAMポリシー設計や、§4-0の事前準備で必要になるコンパートメント作成は、入門シリーズVol1の内容が前提知識となります。

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

それでは、まず2026年時点でOCI Data Scienceがどのような状況にあるのか、§2で現況を確認していきましょう。

本記事全体の構成を、あらかじめ一覧にしておきます。

この構成に沿って読み進めることで、概念理解(§2・§3)→実践(§4)→運用上の注意点(§5・§6)→全体像の整理(§7・§8)という流れで、OCI Data Scienceの基礎を一気通貫で押さえられます。

2. 2026年現況

OCI Data Scienceは活発に機能追加が続いているサービスです。本記事の執筆にあたり確認できた直近のリリース情報を、時系列で整理します。

それぞれの実務影響を、時系列とは逆に新しいものから順に見ていきます。

2-1. Schedulerランダム化オプション(2026-06-30)

Jobsのスケジュール実行機能(Scheduler)に、実行時刻をランダム化するオプションが追加されました。これは、多数のスケジュールジョブが同一時刻(例えば毎時0分)に集中して起動することで、裏側のCompute/ストレージ基盤に瞬間的な負荷が偏る「サンダリングハード(thundering herd)」現象を回避しやすくするための機能です。

実務影響としては、複数のチームが同じテナンシ内で多数の定期実行Jobs(日次バッチ推論や夜間再学習など)を運用している場合に恩恵が大きくなります。単一のJobだけを運用している検証環境では体感しにくい改善ですが、本格的な運用フェーズに入りJobsの本数が増えてきた際には、意識しておくとよいオプションです。本記事の最小構成ハンズオン(§4)ではJobsの実操作までは踏み込みませんが、§3で触れるとおりJobsは学習の自動化やバッチ推論への発展先として重要な機能であるため、この現況もあわせて押さえておいてください。

2-2. Data Science管理コンソールの刷新(2026-04-21)

Data Science関連リソース(プロジェクト・ノートブックセッション・モデルカタログ・モデルデプロイ)の管理コンソールが、刷新された新コンソールへ移行しました。プロジェクト・ノートブックセッション・モデルカタログ・モデルデプロイの各画面のナビゲーション構造が整理され、旧コンソールと比較してメニューの階層が浅くなっています。

実務影響としては、旧コンソールのスクリーンショットや手順書を参照しながら作業していたチームは、メニューの配置やラベルの表記が変わっている箇所に戸惑う可能性があります。本記事のコンソール手順・スクリーンショットは、いずれもこの新コンソールを前提に記述しています。旧コンソールをお使いの場合、メニュー階層は多少異なる場合がある点にご留意ください。機能そのものが大きく変わることは少なく、多くの場合はメニューの配置やラベルの表記が微調整される程度です。

2-3. AI Quick Actions v2.0.1更新(2026-02-25)

AI Quick Actionsがv2.0.1に更新され、Granite 4.0-h系モデルに対応しました。AI Quick Actionsとは何かについては次の2-3-1で詳しく扱います。この更新自体の実務影響としては、対応モデルのラインナップ拡充によってオープンウェイトLLMのセルフホスト選択肢が広がった点を押さえておくとよいでしょう。

2-3-1. AI Quick Actionsとは何か

AI Quick Actionsは、自分のテナンシの計算資源(GPU/CPUシェイプ)上にオープンウェイトのLLM(Granite系・Llama系など)をセルフホストでデプロイするための機能で、Data Science基盤の一部として提供されています。ノートブックセッションやモデルデプロイと同様にプロジェクト配下で管理され、コンソールからモデルを選択してワンクリックに近い操作でデプロイできる点が特徴です。

Generative AI実践Vol1で扱った「マネージドLLM API」(Oracleがホストする事前学習済みモデルをAPI経由で呼び出す形態)とは、課金モデルもインフラの持ち方も異なる別の基盤である点を、ここで改めて明確にしておきます。マネージドLLM APIは、Oracleが管理するインフラ上でホストされたモデルをAPI呼び出しの都度課金する形態であるのに対し、AI Quick Actionsは自分のテナンシのCompute資源(GPU/CPUシェイプ)を専有してモデルをホストするため、モデルデプロイと同様にインスタンスが「アクティブ」である間は継続的にCompute課金が発生します。つまり、課金の発生条件としてはマネージドLLM APIよりも本記事のモデルデプロイに近い性質を持っています。

本記事はAI Quick Actionsそのものを深掘りする記事ではありませんが、「OCIで自前のLLMホスティング基盤を持ちたい場合の選択肢の1つ」として、Data Science配下に存在することは知っておいて損はありません。主軸としては、AI Quick Actionsのようなオープンウェイトモデルのホスティングではなく、独自データで学習した古典的な機械学習モデル(scikit-learn等)のノートブック学習→デプロイという、Data Scienceの最も基本的なワークフローに焦点を当てます。AI Quick Actionsの詳細な操作手順は、機会があれば別記事で扱う予定です。

2-4. モデルデプロイのOpenAI互換エンドポイント(2025-11-12)

モデルデプロイがOpenAI互換のリクエスト/レスポンス形式をサポートするようになりました。これは主に、大規模言語モデルをモデルデプロイ経由でホストする際に、OpenAI SDKやOpenAI互換のクライアントライブラリからそのまま呼び出せるようにするための機能です。

実務影響としては、本記事で扱う古典的な機械学習モデル(scikit-learn等)のデプロイでは必須ではありませんが、将来的にLLM系のモデルをモデルデプロイでホストする際には、既存のOpenAI互換クライアント資産(LangChainやOpenAI SDKを使った既存のアプリケーションコード等)をそのまま流用できる点で有用です。前述のAI Quick Actionsと組み合わせて、セルフホストしたLLMをOpenAI互換の形式で呼び出す、という構成も選択肢に入ってきます。

2-5. JupyterLab刷新(2025-11-04)

ノートブックセッションのJupyterLabは2025-11-04に4.4.6系へ更新されており、UIの見た目やエディタの挙動が、直近までJupyterLab 3系に慣れていた方には多少異なって見える場合があります。実務影響としては、ノートブックの拡張機能(extension)の互換性への注意が必要になる点が挙げられます。JupyterLab 3系向けに開発された一部の拡張機能は、4系では動作しない場合があるため、独自の拡張機能を利用している場合は事前に互換性を確認しておくとよいでしょう。

2-6. シェイプ/conda環境の提供状況概観

ノートブックセッション・モデルデプロイで選択できるシェイプと、あらかじめ用意されているconda環境の提供状況を概観しておきます。

本記事の最小構成ハンズオン(§4)では、GPU系シェイプは利用せず、1 OCPUの汎用Flexシェイプと、あらかじめ提供されている汎用CPU向けconda環境を使用します。GPU系シェイプやカスタムconda環境が必要になるのは、より大規模なモデル(深層学習モデル等)を扱う場合であり、本記事で扱う古典的な機械学習モデル(scikit-learn等)であれば、提供済みのCPU向け環境で十分です。

2-7. 各リリースが与える影響の一覧

ここまで見てきた5件のリリースについて、影響を受ける利用シーンと対応要否を一覧に整理します。

本記事の最小構成ハンズオン(§4)自体は、いずれのリリースにも直接依存しない基本的なワークフローであるため、上記のいずれの対応も必須ではありません。ただし、本格的な運用を検討する段階では、この一覧を出発点にチェックしておくとよいでしょう。

2-8. AI Quick Actions・モデルデプロイ・マネージドLLM APIの比較

§2-3で触れたAI Quick Actionsと、本記事の主題であるモデルデプロイ、そしてGenerative AI実践Vol1のマネージドLLM APIは、いずれも「OCIでLLM/機械学習モデルを使う」という点では共通していますが、性質は大きく異なります。3つを比較した表を示します。

この比較からも分かるとおり、AI Quick Actionsはモデルを「学習」する機能ではなく、既に公開されているオープンウェイトモデルを「セルフホストでデプロイ」するための機能です。本記事で扱う「独自データでの学習からデプロイまで」というワークフローとは目的が異なるため、AI Quick Actionsの詳細な操作は本記事のスコープ外としています。

2-9. シェイプ選定の考え方

§2-6で触れたシェイプの選択肢について、ワークロードの種類に応じた選定の考え方を整理しておきます。

本記事のハンズオン(§4)で扱うのは「データの前処理・簡単な集計」と「古典的な機械学習モデルの学習」に相当するワークロードであるため、汎用Flexシェイプの最小構成(1 OCPU)で十分です。GPU系シェイプの選定基準については、深層学習モデルを扱う発展的な記事で改めて扱う予定です。

2-10. conda環境選定の考え方

conda環境についても、用途に応じた選定の考え方を整理しておきます。

本記事のハンズオン(§4)では、汎用CPU向けの提供済み環境をそのまま利用し、追加のインストール作業は行いません。scikit-learn等の一般的なライブラリがあらかじめ含まれているため、環境構築に時間を取られることなく、すぐに学習コードの実行に進めます。

2-11. ノートブックセッション利用時の実務Tips

ここまでの現況を踏まえ、ノートブックセッションを日常的に利用する上での実務上のポイントをまとめておきます。

• 拡張機能を独自導入している場合は、JupyterLab 4系での互換性を事前に確認する(§2-5参照)
• 旧コンソールの手順書・スクリーンショットは、新コンソール移行(§2-2)にあわせて更新しておく
• LLM系のモデルをモデルデプロイでホストする計画がある場合は、OpenAI互換エンドポイント対応(§2-4)を前提に設計する
• オープンウェイトLLMのセルフホストを検討する場合は、モデルデプロイではなくAI Quick Actions(§2-3・§2-8)を先に確認する
• GPU系シェイプが必要かどうかは、扱うモデルの種類(古典的MLか深層学習か)で判断する(§2-9参照)
• 定期実行Jobsの本数が増えてきたら、Schedulerのランダム化オプション(§2-1)の設定状況を確認する

2-12. 現況確認に関するよくある疑問

Q. リリースノートはどこで確認すればよいですか。

OCI Data Scienceのリリースノートは、OCIコンソールの「What’s New」ページ、またはOracleのドキュメントサイト内の「Release Notes」セクションで確認できます。本記事に記載した5件も、これらの公式情報源から本記事の執筆時点(2026-08-06)に確認した内容です。

Q. 本記事の手順を試す時点でコンソールの表示が記載と異なっていたら、どうすればよいですか。

前述のとおり、OCI Data Scienceはリリースサイクルが速いサービスであるため、メニューの配置やラベルの表記が本記事の記載と多少異なる可能性があります。機能そのものが大きく変わることは少ないため、慌てず同等の操作をするメニューを探していただければ、基本的な手順に大きな支障はないはずです。

Q. AI Quick Actionsは今後の記事で扱う予定はありますか。

本記事の執筆時点では、AI Quick Actionsの詳細な操作手順を扱う独立した記事は未定です。ただし§2-3・§2-8で触れたとおりOCI上に自前のLLMホスティング基盤を持ちたい場合の有力な選択肢であるため、機会があれば別記事にて深掘りを検討します。§8でも触れるとおり、本記事はあくまで独自モデルのMLOpsという基本ワークフローに焦点を当てています。

2-13. 本節のまとめ

本節で扱った内容を、あらためて箇条書きで振り返ります。

• OCI Data Scienceは2025年11月から2026年6月の約8ヶ月間で5件の注目リリースがあり、活発に機能追加が続いている
• モデルデプロイのOpenAI互換エンドポイント対応(§2-4)により、LLM系モデルのホスティング時に既存クライアント資産を流用しやすくなった
• 新コンソール移行(§2-2)により、旧コンソールの手順書を参照している場合はナビゲーション構造の差異に注意が必要
• AI Quick Actions(§2-3・§2-8)は、独自モデルを学習する本記事のワークフローとは異なる、オープンウェイトLLMのセルフホスト機能です
• シェイプ・conda環境(§2-6・§2-9・§2-10)は、本記事の最小構成ハンズオンでは汎用Flexシェイプ+提供済みCPU向け環境で十分です
• Schedulerのランダム化オプション(§2-1)は、定期実行Jobsの本数が増えてきた段階で意識するとよい

2-14. 現在の環境設定を確認する方法

本記事の記載と手元の環境で表示が異なると感じた場合、次の方法で現在の設定を確認できます。

自分の環境がどの状態にあるかを把握しておくと、本記事の手順と実際の画面表示にズレがあった場合でも、原因の切り分けがしやすくなります。

2-15. 参考情報源

本節で扱った現況情報の一次情報源として、次を参照しています。実施前には必ず最新の公式情報もあわせてご確認ください。

• OCIコンソールの「What’s New」ページ(コンソールログイン後、ナビゲーションメニューから確認可能)
• Oracleドキュメントサイトの「Data Science Release Notes」セクション(docs.oracle.com/iaas/data-science配下)
• Oracle公式の料金ページ(oracle.com/artificial-intelligence/data-science/pricing/、詳細は§5参照)

2-16. 5件のリリースを俯瞰した傾向

最後に、この5件のリリースを俯瞰すると、OCI Data Scienceの機能拡充の方向性が見えてきます。

• 運用の効率化: Schedulerのランダム化オプション(§2-1)は、規模が拡大した際の運用負荷を軽減する方向の改善です。
• 操作性の向上: 新コンソール移行(§2-2)とJupyterLab刷新(§2-5)は、いずれも日常的な操作の使い勝手を高める改善です。
• LLM関連機能の拡充: AI Quick Actionsの対応モデル拡大(§2-3)とモデルデプロイのOpenAI互換対応(§2-4)は、いずれも生成AI・LLM領域への投資が続いていることを示しています。

このうち本記事のハンズオン(§4)に直接関係するのは操作性の向上(新コンソール・JupyterLab)であり、運用効率化とLLM関連機能は、より発展的な運用フェーズで意識すべきポイントです。まずは§3でアーキテクチャの全体像を掴んでから、§4の最小構成ハンズオンで実際の操作感を確認していきましょう。

2-17. 本記事執筆時点でのバージョン情報まとめ

最後に、本記事の各手順(§4)を記述するにあたって前提とした、主要コンポーネントのバージョン・状態を一覧にまとめておきます。実施時点で差異がある場合は、この一覧を手がかりに何が変わったのかを切り分けてください。

これらの現況情報は、いずれも本記事の執筆時点(2026-08-06)で確認できた公式リリースノートに基づいています。

OCI Data Scienceは前述のとおりリリースサイクルが速いサービスであるため、実際にハンズオンを進める際は、コンソール上の表示やメニュー名がここでの記載と多少異なっていても、慌てず該当メニューを探していただければと思います。機能そのものが大きく変わることは少なく、多くの場合はメニューの配置やラベルの表記が微調整される程度です。

それでは、§3でOCI Data Scienceの主要リソースの関係を整理し、§4で実際にハンズオンを進めていきます。

3. アーキテクチャと主要概念

OCI Data Scienceの主要リソースは、以下のように整理できます。

• プロジェクト: Data Scienceの作業単位となるコンテナです。1つのコンパートメント配下に複数のプロジェクトを作成でき、ノートブックセッションやモデル、ジョブはいずれかのプロジェクトに属します。SageMakerには厳密に対応する概念はありませんが、あえて言えばSageMaker Studioのドメイン/プロジェクトに近い役割です。
• ノートブックセッション: JupyterLabベースの対話的な開発環境です。Compute(VMシェイプ)とBlock Storageを組み合わせて起動し、conda環境を通じてPython/機械学習ライブラリを利用します。
• モデルカタログ: 学習済みモデルのアーティファクト(重みファイルやメタデータ)をバージョン管理して保存する場所です。内部的にはObject Storageを使ってモデルを保管します。
• モデルデプロイ: モデルカタログに登録したモデルを、HTTPエンドポイントとして公開する機能です。ホスティング用のVM(シェイプ×レプリカ数)とロードバランサ帯域を割り当て、推論リクエストを受け付けます。
• Jobs: ノートブックセッションを常時起動しておかなくても、コードを単発またはスケジュール実行できる機能です。学習の自動化やバッチ推論に使います。
• Pipelines: 複数のJobsステップをDAG(有向非巡回グラフ)として連結し、前処理→学習→評価のような一連のワークフローをオーケストレーションする機能です。

これらのリソースはすべて、IAMポリシーによってアクセス制御されます。特にノートブックセッションやモデルデプロイからObject Storage・他のOCIサービスへアクセスする際は、Data Scienceの「動的グループ(dynamic group)」にリソースの権限を付与するポリシー設計が必要になります。動的グループは、特定のコンパートメント配下のノートブックセッション/モデルデプロイのリソースを、あたかもIAMのユーザーグループのように束ねて権限を付与できる仕組みです。典型的なポリシー文の骨子は次のようになります。

Allow dynamic-group ds-practice-dynamic-group to manage data-science-family in compartment id <compartment-ocid>
Allow dynamic-group ds-practice-dynamic-group to manage object-family in compartment id <compartment-ocid>

1行目がData Science自身のリソース(プロジェクト・ノートブックセッション・モデル・モデルデプロイ等)の管理権限、2行目がモデルカタログの実体であるObject Storageへのアクセス権限です。本記事のハンズオンでは、最小構成での動作確認を目的とするため、コンパートメント内のこの基本的な権限のみを想定して進めます。本番運用でモデルデプロイからカスタムのObject Storageバケットや他サービス(Streaming、Vault等)へアクセスさせる場合は、動的グループの一致条件とポリシーの追加設定が別途必要になる点を覚えておいてください。

3-1. 動的グループの一致条件記述例

動的グループを作成する際は、対象リソースを絞り込む「一致条件(matching rule)」を記述します。特定のコンパートメント配下のノートブックセッション・モデルデプロイのすべてをまとめて対象にする場合、一致条件は次のような形になります。

ALL {resource.type = 'datasciencenotebooksession', resource.compartment.id = '<compartment-ocid>'}

上記はノートブックセッションのみを対象とする条件です。モデルデプロイもあわせて対象にしたい場合は、resource.typeの異なる条件をANYでまとめます。

ANY {
  ALL {resource.type = 'datasciencenotebooksession', resource.compartment.id = '<compartment-ocid>'},
  ALL {resource.type = 'datasciencemodeldeployment', resource.compartment.id = '<compartment-ocid>'}
}

特定のプロジェクトに属するリソースだけをさらに絞り込みたい場合は、resource.compartment.idに加えてresource.freeformTags等のタグ条件を組み合わせる方法もあります。本記事の最小構成ハンズオンでは、コンパートメント単位のシンプルな一致条件で十分ですが、複数プロジェクトを1つのコンパートメントで運用するようになった段階では、プロジェクト単位での絞り込みも検討するとよいでしょう。

3-2. ネットワーキングの選択基準

ネットワーキングについても触れておきます。ノートブックセッションとモデルデプロイは、それぞれ「既定のネットワーキング(Oracle管理のネットワーク)」と「カスタムネットワーキング(自分のVCN/サブネットを指定)」のいずれかを選択できます。既定のネットワーキングは、VCN設計を意識せずすぐに起動できる反面、外部ネットワークとの細かい通信制御はできません。一方カスタムネットワーキングでは、既存のVCN(OCI入門シリーズで作成したものなど)のプライベートサブネットを指定することで、他のOCIリソースとの接続やセキュリティリストによる制御が可能になります。

どちらを選ぶべきかの判断基準を、表として整理します。

本記事の最小構成ハンズオンでは、手早く動作確認することを優先し、既定のネットワーキングを利用する前提で進めます。本番環境でData Scienceを運用する場合は、既存のVCN設計(セキュリティリストやルートテーブルの方針)にあわせてカスタムネットワーキングを選択することが一般的です。

リージョンについては、公式ドキュメントに「Data Science is hosted in all regions where OCI is available.」と明記されており(2026-08-06確認)、東京(ap-tokyo-1)・大阪(ap-osaka-1)のいずれのリージョンでも利用可能です。ただし、後述のとおりAlways Free枠の対象外であるため、有償のCompute/Block Storageが前提となる点にはあらためて注意してください。

3-3. 各リソースのライフサイクル状態遷移

Data Scienceの主要リソースは、いずれも「作成→アクティブ→非アクティブ→削除」に類する状態遷移を辿ります。ただし、リソースの種類によって遷移可能な状態や、状態ごとに止まる課金要素は異なります。

この表からも分かるとおり、ノートブックセッションとモデルデプロイは「非アクティブ」という中間状態を持ちますが、その意味合いは大きく異なります。ノートブックセッションの非アクティブ化はComputeのみを止める部分的な操作であるのに対し、モデルデプロイの非アクティブ化は課金対象のリソース(ホスティングVM・ロードバランサ帯域)を全て止める操作です。この非対称性が、§6で扱う「非アクティブ化≠課金全停止」という落とし穴の根本的な原因になっています。

なお、本記事のハンズオン(§4)では、手順をシンプルに保つためJobsとPipelinesの実操作までは踏み込みません。Jobsは、ノートブックセッション上で動作確認したコードを、そのまま単発実行やスケジュール実行へ移行したい場合に使うイメージを持っておくとよいでしょう。たとえば「毎日決まった時刻に最新データで再学習する」といった運用を組みたくなった段階で、ノートブックセッションを常時起動しておくのではなくJobsへ移行する、というのが典型的な発展の流れです。Pipelinesは、そのJobsのステップを複数連結し、前処理→学習→評価→登録という一連の流れを1つのワークフローとして管理したい場合に検討する機能です。

§4では、この関係図をもとに、実際に最小構成でE2Eのハンズオンを進めます。

プロジェクト作成からクリーンアップまでの一連の流れを一度体験しておけば、その後Jobs・Pipelinesへ発展させる際も、どのリソースがどの役割を担っているかを迷わず把握できるはずです。

4. 最小構成E2Eハンズオン

本節では、以下の最小構成で、プロジェクト作成からモデルデプロイ・推論呼び出し・クリーンアップまでを一気通貫で実践します。

各手順には概算の課金試算を添えています。単価そのものの根拠は§5にまとめていますので、あわせてご確認ください。

4-0. 事前準備

ハンズオンを始める前に、以下が整っていることを確認してください。

• コンパートメント: 検証用のコンパートメントが作成済みであること(OCI入門シリーズVol1参照)。テナンシのルートコンパートメント直下で検証しても動作はしますが、後片付けのしやすさを考えると専用コンパートメントを切っておくことをお勧めします。
• IAMグループとポリシー: ご自身のユーザーが、対象コンパートションでData Science関連リソース(プロジェクト・ノートブックセッション・モデル・モデルデプロイ)を作成できるポリシーが付与されていること。
• 動的グループとポリシー: §3で触れた動的グループと、Data Science/Object Storageへのアクセスを許可するポリシーが設定済みであること。
• OCI CLI(任意): CLIでの操作も試したい場合は、ociコマンドがローカル環境にインストールされ、対象テナンシに対して認証設定済みであること。コンソール操作のみで進める場合はCLIのセットアップは不要です。

これらの準備が整っていれば、次の4-1から実際の操作に入ります。

4-1. プロジェクト作成

コンソールで「Analytics & AI」→「Data Science」→「Projects」を開き、対象のコンパートションを選択して「プロジェクトの作成」を実行します。名前と説明を入力するだけで作成が完了し、これ自体には課金は発生しません。

CLIの場合は次のように作成します。

oci data-science project create \
  --compartment-id <compartment-ocid> \
  --display-name "ds-practice-vol1" \
  --description "OCI Data Science実践Vol1用の検証プロジェクト"

4-2. ノートブックセッションの起動(最小シェイプ)

プロジェクト内から「ノートブック・セッション」の作成を選択します。シェイプは1 OCPU/16GBのFlexシェイプを選び、ブロックボリュームは最小構成の50GBを指定します。ネットワーキングは、テナンシに既存のVCN/サブネットがあればそれを指定しますが、新コンソールでは簡易な既定ネットワーキング設定が案内されるため、初回はその案内に従うのが最も手早い方法です(§3-2で触れたとおり、既定のネットワーキングで問題ありません)。

CLIで同等の操作をする場合の骨子は次のとおりです。

oci data-science notebook-session create \
  --compartment-id <compartment-ocid> \
  --project-id <project-ocid> \
  --display-name "ds-practice-vol1-notebook" \
  --notebook-session-configuration-details \
 '{"shape":"VM.Standard.E4.Flex","blockStorageSizeInGBs":50,"notebookSessionShapeConfigDetails":{"ocpus":1,"memoryInGBs":16}}'

作成には数分程度かかります。コンソール上でステータスが「アクティブ」に変わったら、「JupyterLabを開く」からノートブック環境にアクセスできます。

課金試算の目安: このステップから、ノートブックセッションが「アクティブ」である間、Compute(1 OCPU分)とBlock Storage(50GB分)の標準料金が発生し始めます(§5-1参照)。

4-3. 環境確認とADS SDKのバージョンチェック

ノートブックセッションが起動したら、JupyterLabのターミナルまたはノートブックセル上で、Oracle Accelerated Data Science(ADS)SDKのバージョンを確認します。ADS SDKはリリースサイクルが速いため、本記事では特定のバージョン番号を明記しません。以下のコマンドで、ご自身の環境にインストールされているバージョンを都度ご確認ください。

pip show oracle-ads

conda環境は、汎用の機械学習用環境(CPU向け)を選択すれば、scikit-learnなどの一般的なライブラリがあらかじめ含まれています。含まれていない場合は、ノートブックセッション内でpip installまたはconda installによって追加してください。

4-4. 簡易モデルの学習

外部からの大規模データ取得を避けるため、scikit-learnに同梱されている小規模なサンプルデータセット(例: irisデータセット相当の分類問題)を使い、シンプルな分類モデル(RandomForestClassifier等)を学習します。学習の骨子はごくシンプルで、データの読み込み・学習用と検証用への分割・モデルのfit・検証データでの精度確認という、一般的な機械学習の入門手順と変わりません。SageMakerのノートブックインスタンスでscikit-learnモデルを学習した経験がある方であれば、コード自体はほぼそのまま流用できます。

ノートブック上でのコードは、次のようにごくシンプルなものになります。

from sklearn.datasets import load_iris
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
import joblib

data = load_iris()
X_train, X_test, y_train, y_test = train_test_split(
 data.data, data.target, test_size=0.2, random_state=0
)

clf = RandomForestClassifier(n_estimators=50, random_state=0)
clf.fit(X_train, y_train)
print("accuracy:", clf.score(X_test, y_test))

joblib.dump(clf, "model.joblib")

学習自体はノートブックセッションのCompute上で完結するため、追加の課金要素はノートブックセッションの稼働時間のみです。学習が完了したモデルは、ノートブック上でjoblib等を使ってシリアライズし、モデルカタログへの登録に備えます。なお、より大規模な学習ジョブを繰り返し実行したい場合は、ノートブックセッションを常時起動しておくのではなく、§3で触れた「Jobs」機能を使って学習コードを単発実行する構成にすると、学習が終わった時点で課金対象のCompute稼働を止められるため、費用対効果の面で有利です。本記事の最小構成ハンズオンでは、手順をシンプルに保つためノートブックセッション内で学習まで完結させています。

4-5. モデルカタログへの登録

ADS SDKのGenericModel(または対象フレームワーク用のラッパークラス)を使うと、学習済みモデルとその推論用のスコアリングコードを、ノートブックセッションから直接モデルカタログへsave()できます。概念的なコードの骨子は次のとおりです(実際のクラス名・引数はADS SDKのバージョンにより異なる場合があるため、§4-3で確認したご自身の環境のドキュメント/docstringもあわせてご確認ください)。

from ads.model.generic_model import GenericModel

artifact_model = GenericModel(estimator=clf, artifact_dir="model_artifact")
artifact_model.prepare(
 inference_conda_env="generalml_p311_cpu_x86_64_v1",
 force_overwrite=True,
)
model_id = artifact_model.save(
 project_id="<project-ocid>",
 compartment_id="<compartment-ocid>",
 display_name="ds-practice-vol1-model",
)

コンソール側では、「Models」画面にアップロードされたモデルのバージョンとメタデータを確認できます。

課金試算の目安: モデルカタログへの登録以降は、モデルアーティファクトのObject Storage保管料金(GB/月単位)が発生します(§5-2参照)。今回の最小構成であれば、数十MB程度のアーティファクトサイズに収まるはずです。

4-6. モデルデプロイ(HTTPエンドポイント)

「Model Deployments」画面から、登録したモデルを選択してデプロイを作成します。ここでも最小構成を意識し、インスタンスシェイプは最小のFlexシェイプ、インスタンス数は1、ロードバランサの帯域幅は最小値を選択します。

CLIの場合の骨子は次のとおりです(実際にはモデルOCID・シェイプ・帯域等のパラメータを指定します)。

oci data-science model-deployment create \
  --compartment-id <compartment-ocid> \
  --project-id <project-ocid> \
  --display-name "ds-practice-vol1-deploy" \
  --model-deployment-configuration-details file://deploy-config.json

deploy-config.jsonには、最小構成を意識した以下のような内容を指定します。インスタンスシェイプは1 OCPU、インスタンス数(レプリカ数)は1、ロードバランサ帯域幅は最小値としています。

{
  "deploymentType": "SINGLE_MODEL",
  "modelConfigurationDetails": {
 "modelId": "<model-ocid>",
 "instanceConfiguration": {
"instanceShapeName": "VM.Standard.E4.Flex",
"modelDeploymentInstanceShapeConfigDetails": {
  "ocpus": 1,
  "memoryInGBs": 16
}
 },
 "scalingPolicy": {
"instanceCount": 1
 },
 "bandwidthMbps": 10
  }
}

デプロイが「アクティブ」状態になるまでは数分程度かかります。完了すると、HTTPエンドポイントのURLがコンソール上に払い出されます。

課金試算の目安: モデルデプロイが「アクティブ」である間、ホスティング用VM(シェイプ×レプリカ数分)とロードバランサ帯域の標準料金が発生し続けます(§5-3参照)。検証が終わったら速やかに削除するか、少なくとも非アクティブ化することをお勧めします。

4-7. 推論呼び出しの確認

払い出されたエンドポイントに対して、テスト用の入力データをJSON形式でPOSTし、推論結果が返ってくることを確認します。

curl -X POST \
  -H "Content-Type: application/json" \
  --data '{"input": [[5.1, 3.5, 1.4, 0.2]]}' \
  "<model-deployment-endpoint>/predict"

想定どおりの分類結果(クラスラベルや確率)が返ってくれば、ノートブックでの学習からHTTPエンドポイントでの推論提供までのE2Eが完了です。

4-8. クリーンアップ

最後に、作成したリソースを削除します。手順と課金停止範囲の詳細は§6でまとめて解説しますので、必ずあわせてご確認ください。

4-9. 手順ごとの課金試算まとめ

ここまでのハンズオン各ステップと、発生する課金要素の対応を一覧にまとめます。

具体的な単価の根拠は§5で、削除の順序と各段階での課金停止範囲は§6で、それぞれ詳しく解説します。

5. 料金試算

OCI Data Scienceの課金構造は、サービス自体に割増料金が乗るのではなく、裏側で使用するCompute・Block Storage・Object Storage・ロードバランサといった標準リソースの利用分だけが課金される「サーバーレス従量課金」です。この構造は公式ドキュメント(docs.oracle.com/iaas/data-science/using/overview.htm、2026-08-06確認)にも明記されています。まず全体像を一覧表で示し、その後リソース区分ごとに詳しく整理します。

5-1. ノートブックセッション(Compute + Block Storage)

ノートブックセッションが「アクティブ」な間は、選択したシェイプのCompute料金と、アタッチしたBlock Storage(最小50GB)の料金が標準レートで発生します。ノートブックセッションを「非アクティブ化」するとComputeの課金は止まりますが、Block Storageは保持されるため課金が継続します(★詳細は§6で扱う最重要の落とし穴です)。ノートブックセッションを完全に「削除」すると、Compute・Block Storageとも課金が止まります。

5-2. モデルカタログ(Object Storage)

モデルをモデルカタログへ保存すると、モデルアーティファクトの容量に応じたObject Storageの標準レート(GB/月)で課金されます。モデルを削除すれば、その時点で課金は止まります。

5-3. モデルデプロイ(ホスティングVM + ロードバランサ帯域)

モデルデプロイが「アクティブ」な間は、ホスティング用VM(シェイプ×レプリカ数)とロードバランサ帯域の標準料金が発生し続けます。「非アクティブ化」または「削除」によって、これらの課金は止まります。

5-4. Jobs・Pipelines

JobsとPipelinesは、それ自体に追加料金は発生せず、実行中に使用した基盤リソース(Compute・Block Storage)の分だけが、実行時間中のみ課金されます。ジョブの実行が終了(コードの終了)した時点で、メータリングも停止します。

5-5. 具体的な単価について

上記はいずれも課金の「構造」であり、具体的な時間単価・GB単価は、公式の料金ページ(oracle.com/artificial-intelligence/data-science/pricing/)から取得する必要があります。本記事の執筆にあたり同ページへのアクセスを試みましたが、自動化ツールからのアクセスが制限されており(2026-08-06確認)、確定した数値を本記事に転記できませんでした。単価はシェイプやリージョンによって変動する可能性もあるため、推測値を記載することは避け、実施前に必ず公式の料金ページ、またはOCI公式のCost Estimator(OCIコンソールの「価格の見積り」メニューから利用可能)で最新の単価をご確認いただくようお願いします。Cost Estimatorでは、シェイプ・OCPU数・ストレージ容量・リージョンを指定するだけで、月額の概算費用を試算できます。

最小構成(1 OCPUノートブックセッション + 50GB、短時間の検証利用、モデルデプロイも最小シェイプ・1レプリカ・最小帯域で検証後即削除)であれば、他のOCIコンピュートサービスの実践記事と同程度の少額課金の範囲に収まる想定ですが、正確な金額は必ずご自身の環境・単価で試算してください。特に、ノートブックセッションを検証後もアクティブなまま数日〜数週間放置してしまうと、たとえ1 OCPUの最小シェイプであっても累積の課金額は無視できない規模になります。§6のクリーンアップ手順を徹底し、検証が終わったリソースは速やかに削除する運用を習慣づけることをお勧めします。

5-6. Cost Estimatorでの試算手順

具体的な単価は本記事に記載できませんが、OCI公式のCost Estimatorを使えば、実施前にご自身で概算費用を確認できます。操作手順は次のとおりです。

1. OCIコンソール右上のメニューから「価格の見積り」(Cost Estimator)を開きます。
2. 「サービスの追加」から、対象リソース(Compute VMインスタンス、Block Volume、Object Storage、ロードバランサ等)をそれぞれ検索して追加します。
3. Computeを追加する画面で、リージョン(東京または大阪)・シェイプ(VM.Standard.E4.Flex等)・OCPU数・メモリ量を、本記事の最小構成に合わせて入力します。
4. Block Volumeを追加する画面で、ストレージ容量(50GB)を入力します。
5. モデルデプロイのホスティングVM分についても、同様にComputeの項目として追加し、シェイプとレプリカ数(1)を入力します。
6. ロードバランサの項目で、帯域幅(最小値)を入力します。
7. 画面下部に、月額の概算費用の合計が表示されます。稼働時間を「月の一部のみ」に調整できる場合は、検証で想定する稼働時間に合わせて調整します。

5-7. 最小構成試算のパラメータ入力例

Cost Estimatorに入力するパラメータの組み合わせ例を、構造のみ(数値単価を含まない形)で示します。

このパラメータの組み合わせをCost Estimatorへ入力すれば、ご自身のテナンシ・リージョンでの最新単価に基づいた月額概算費用が算出されます。稼働時間を短時間(検証時のみ)に絞ることで、より実態へ近づけた試算になります。

6. 落とし穴とクリーンアップ

6-1. 落とし穴

OCI Data Scienceを使う上で、特に注意しておきたい落とし穴を4点まとめます。

1. ★ノートブックセッションの「非アクティブ化」は課金の全停止ではありません。 非アクティブ化するとCompute課金は止まりますが、アタッチされたBlock Storageは保持されたままのため、Block Storageの課金は継続します。本当に課金を止めたい場合は、非アクティブ化ではなく「削除」まで行う必要があります。
2. Always Free枠の対象外です。 OCI入門シリーズで扱ったAlways Free枠のCompute・Autonomous Database等とは異なり、Data Scienceのノートブックセッションは有償のCompute/Block Storageが前提です。無料で試せるサービスだと思い込んで長時間放置すると、想定外の課金につながります。
3. モデルデプロイのロードバランサ帯域課金は、アクティブ中は継続します。 推論エンドポイントとしての利用が終わった検証用のデプロイを「アクティブ」のまま放置すると、ホスティングVMとロードバランサ帯域の両方の課金が続きます。
4. ADS SDKのバージョンは、記事公開時点の値を鵜呑みにしないでください。 ADS SDKはリリースサイクルが速く、本記事でも特定のバージョン番号は明記していません。実施時点でpip show oracle-adsにより、ご自身の環境のバージョンを確認する習慣をつけてください。

6-2. クリーンアップ

検証が終わったら、以下の順序でリソースを削除します。削除順序を守ることで、依存関係によるエラーを避けつつ、各段階でどこまで課金が止まるかを把握できます。

1. モデルデプロイの削除: 「Model Deployments」画面から対象のデプロイを削除します。これにより、ホスティングVMとロードバランサ帯域の課金が停止します。
2. モデルカタログの削除: 「Models」画面から登録したモデルを削除します。これにより、Object Storageの保管料金が停止します。
3. ノートブックセッションの削除: 「非アクティブ化」で止まらず、必ず「削除」まで実行してください。★ここでも、非アクティブ化のみではBlock Storageの課金が継続する点を再度強調します。 削除まで完了して初めて、Compute・Block Storageの両方の課金が止まります。
4. プロジェクトの削除: 上記のリソースがすべて削除されたことを確認した上で、プロジェクト自体を削除します。プロジェクトの器そのものには課金は発生しませんが、リソースの片付け漏れを防ぐため最後に確認することをお勧めします。

6-2-1. 削除時の依存関係エラー実例

上記の順序を守らずに削除を進めると、依存関係エラーで削除を拒否される場合があります。代表的な実例を挙げます。

• モデルカタログを先に削除しようとした場合: そのモデルを参照しているモデルデプロイが存在すると、「このモデルは1件以上のモデルデプロイから参照されているため削除できません」という主旨のエラーが表示されます。先にモデルデプロイを削除してから、モデルカタログの削除に進んでください。
• プロジェクトを先に削除しようとした場合: プロジェクト配下にノートブックセッション・モデル・モデルデプロイのいずれかが残っていると、「このプロジェクトには関連リソースが存在するため削除できません」という主旨のエラーが表示されます。配下のリソースをすべて削除してから、プロジェクトの削除に進んでください。
• ノートブックセッションの非アクティブ化中に削除を試みた場合: ステータスが「非アクティブ化中」等の遷移中の状態にあるリソースは、削除操作を受け付けない場合があります。ステータスが完全に確定するまで待ってから削除してください。

いずれのエラーも、本記事で案内している「モデルデプロイ→モデルカタログ→ノートブックセッション→プロジェクト」の順序を守っていれば発生しません。もしエラーに遭遇した場合は、エラーメッセージに表示される参照元リソースを確認し、そちらを先に削除してください。

6-2-2. コストエクスプローラでの課金停止確認手順

各ステップ完了後に、実際に課金が止まっていることをコストエクスプローラで確認する具体的な手順は次のとおりです。

1. OCIコンソールの「課金とコスト管理」から「コストエクスプローラ」を開きます。
2. フィルタ条件で、対象のコンパートメント(Data Science検証用のコンパートメント)を指定します。
3. さらにサービス区分で「Compute」「Block Storage」「Object Storage」「Load Balancer」を個別に絞り込み、それぞれのコスト推移グラフを確認します。
4. 削除操作を行った日以降のグラフで、該当サービスのコストが横ばい(新規発生なし)になっていることを確認します。なお、コストエクスプローラへのデータ反映には数時間程度のタイムラグを伴う場合があるため、削除直後にグラフへ反映されていなくても、翌日以降に改めて確認してください。
5. 想定外のコストが継続して発生している場合は、§6-2-1の依存関係エラーにより一部リソースの削除が失敗していないか、対象の画面(Model Deployments/Models/Notebook Sessions)を再確認します。

各ステップの完了後は、コンソールの「課金とコスト管理」またはコストエクスプローラで、対象リソースの課金が実際に止まっていることを確認する習慣をつけておくと安心です。以下は、クリーンアップ実施前に確認しておきたいチェックリストです。

6-3. よくある疑問

Q. ノートブックセッションを「非アクティブ化」したのに、翌日もBlock Storageの課金が発生していました。故障でしょうか。

故障ではありません。§6-1・§6-2で繰り返し述べているとおり、非アクティブ化はCompute課金のみを止める操作であり、アタッチされたBlock Storageは意図的に保持される仕様です。これは、後で同じ環境を再開できるようにするための設計であり、完全に課金を止めたい場合は「削除」まで実行する必要があります。

Q. モデルデプロイを一時的に止めたいだけなら、削除ではなく非アクティブ化でよいですか。

はい。モデルデプロイの場合は、非アクティブ化によってホスティングVM・ロードバランサ帯域の両方の課金が止まります(ノートブックセッションのBlock Storageのような「一部だけ課金が継続する」挙動はありません)。ただし、非アクティブ化された状態でもモデルデプロイ自体のリソース定義は残るため、完全に片付けたい場合は最終的に削除することをお勧めします。

Q. Always Free枠のCompute(OCI入門シリーズVol4で扱ったAlways Freeシェイプ)を、ノートブックセッションのシェイプとして流用できませんか。

できません。ノートブックセッションで選択できるシェイプは、Data Scienceがサポートする対象シェイプ(Flexシェイプ等)に限定されており、Always Free専用のシェイプはノートブックセッションの選択肢には含まれません。§6-1で述べたとおり、Data ScienceはAlways Free枠の対象外であることを前提に、有償のCompute/Block Storageで検証する必要があります。

Q. クリーンアップの途中で作業を中断した場合、どこまで削除したか忘れてしまいそうです。

コンソールの「Model Deployments」「Models」「Notebook Sessions」「Projects」の各画面を順に開き、対象コンパートメント配下にリソースが残っていないかを確認すれば、どこまで削除が完了しているかを把握できます。§6-2のチェックリストを、作業の再開時にもあわせて確認することをお勧めします。

7. 既刊との棲み分け

冒頭§1で示したとおり、OCIのAI関連サービスは複数存在し、それぞれ守備範囲が異なります。ここでは、既刊2本との違いを明確にしておきます。

7-1. MySQL HeatWave実践との違い

MySQL HeatWave実践Vol1で扱ったAutoML機能は、SQLのCALL文(ML_TRAIN/ML_PREDICT_ROW等)を使って、MySQLデータベースエンジンの内部で完結する「in-database ML」です。DBA・データ分析者がSQLだけで機械学習を扱えることが強みで、同記事内でも「AWSでは機械学習に別途SageMaker等が必要だが、HeatWaveはAutoMLを標準搭載している」という位置づけが示されています。

対して本記事のOCI Data Scienceは、Jupyterノートブック上でPythonを使い、データベースエンジンとは独立したMLプラットフォーム上でモデルを学習・デプロイします。基盤(データベースエンジン内蔵か、専用サービスか)、言語(SQLか、Pythonか)、想定読者(DBA・分析者か、MLエンジニアか)という3つの軸で、明確に守備範囲が分かれています。

この表からも分かるとおり、「データベースに閉じた分析で十分か」「独立したモデルをAPIとして外部提供したいか」が、両者を使い分ける際の実務上の判断軸になります。

7-2. Generative AI実践Vol1との違い

Generative AI実践Vol1は、Cohereなどの事前学習済みモデルをAPI経由で呼び出す「マネージドLLM API」の実践です。同記事内では「Dedicated AIクラスターによるファインチューニングやカスタムモデルのホスティングは対象外」と明示的にスコープ外を宣言しており、独自モデルの学習やホスティングには踏み込んでいません。

本記事のOCI Data Scienceは、まさにその「独自モデルの学習からホスティングまで」を担う領域です。マネージドAPIで手軽に生成AIを使いたい場合はGenerative AI実践Vol1、独自データで学習したモデルを自前で運用したい場合は本記事、という形で相互に補完する関係です。

なお、§2で触れた「AI Quick Actions」(オープンウェイトLLMのセルフホスト)は、Generative AI実践Vol1のマネージドAPIとも、本記事の古典的MLモデルのMLOpsとも異なる第三の選択肢です。3つの記事・機能をあわせて理解しておくと、「OCIで生成AI・機械学習をやりたい」という要望に対して、用途に応じた最適な入口を提案できるようになります。

これで、OCIのAI関連サービスの全体像(in-database ML・マネージドLLM API・独自モデルのMLOps)が出揃いました。用途に応じて、この3つの記事を使い分けていただければと思います。

8. まとめ

本記事では、OCI Data ScienceをAWSのSageMakerと対比しながら、プロジェクト作成からノートブックセッションでの学習、モデルカタログへの登録、モデルデプロイ(HTTPエンドポイント)、推論呼び出し確認、そしてクリーンアップまでを最小構成のE2Eとして実践しました。

得られたスキルを振り返ると、次のとおりです。

• OCIのAI関連サービス全体における、Data Scienceの位置づけ(in-database ML・マネージドLLM APIとの違い)
• プロジェクト/ノートブックセッション/モデルカタログ/モデルデプロイ/Jobs/Pipelinesという主要リソースの役割と関係
• 最小構成(1 OCPU + Block Storage 50GB、最小シェイプのモデルデプロイ)での学習からデプロイまでのハンズオン
• 「非アクティブ化≠課金全停止」という誤課金を防ぐための正しいクリーンアップ手順

OCI Data Scienceは、Jobs・Pipelinesによるワークフロー自動化や、AI Quick Actionsによるオープンウェイトモデルのセルフホスティングなど、本記事で扱いきれなかった発展的な機能も備えています。まずは本記事の最小構成E2Eで全体の流れを体験し、そこから必要な機能を段階的に深掘りしていくことをお勧めします。

発展的なトピックへの導線を、あらためて整理しておきます。

• Jobs: ノートブックセッション上で動作確認した学習コードを、単発実行やスケジュール実行へ移行したい場合に検討します(§3-3・§4-4参照)。常時起動が不要になるため、費用対効果の面でも有利です。
• Pipelines: Jobsの複数ステップをDAGとして連結し、前処理→学習→評価→登録という一連のワークフローをオーケストレーションしたい場合に検討します(§3参照)。
• AI Quick Actions: 独自モデルの学習ではなく、オープンウェイトLLMを自前のテナンシでセルフホストしたい場合の選択肢です(§2-3・§2-8参照)。本記事のモデルデプロイとは異なる基盤である点に留意してください。

最後に、本記事全体を通じて繰り返し強調してきたポイントを、あらためて振り返っておきます。ノートブックセッションの「非アクティブ化」はComputeの課金のみを止める操作であり、Block Storageの課金は削除するまで継続するという点は、SageMakerなど他クラウドのノートブック環境の感覚のまま操作すると見落としやすい、OCI特有の挙動です。ハンズオンで手を動かした後は、§6のクリーンアップ手順とチェックリストに沿って、必ずリソースの削除まで完了させてから作業を終えるようにしてください。

AWSでSageMakerを使い慣れた方であれば、OCI Data Scienceの概念自体は決して難しくありません。プロジェクト・ノートブックセッション・モデルカタログ・モデルデプロイという4つの主要リソースの役割さえ押さえてしまえば、あとは実際に手を動かしながら、課金の発生条件とクリーンアップの作法を体得していくのが、最も確実な理解の近道です。本記事が、その最初の一歩の助けになれば幸いです。