--- title: "Red Hat OpenShift AIとは？最新3.5の機能・使い方・導入要件とKubernetesとの違い" url: "https://www.issoh.co.jp/column/details/2888/" published: 2024-07-02 updated: 2026-10-20 categories: ["AI"] publisher: "株式会社一創" --- # Red Hat OpenShift AIとは？最新3.5の機能・使い方・導入要件とKubernetesとの違い Red Hat OpenShift AI は、Kubernetes ベースのコンテナ基盤 Red Hat OpenShift の上に載せる AI/ML プラットフォームです。OpenShift クラスターに Operator として導入し、ノートブック環境、パイプライン、モデルサービング、分散学習、評価、社内向けの LLM 配信までをまとめて提供します。2026年10月時点の最新版は **3.5（2026年8月27日GA）**で、2026年9月にはセキュリティ更新を含むパッチ版 3.5.1 が出ています。この記事では、3.5 で何ができるか、導入後にどの順で使うか、RHEL AI などの近い製品や素の Kubernetes とどう違うか、導入要件と 2.x からの移行で詰まる点を、Red Hat の公式ドキュメントとライフサイクル情報をもとに整理します。 ## まとめ：OpenShift AIの要点（3.5時点） - OpenShift AI は **OpenShift 上で動く Operator 型の AI/ML 基盤**です。単体の SaaS や OS ではなく、OpenShift クラスターが前提になります。 - 最新版は **3.5**（GA 2026年8月27日、フルサポート終了 2027年3月29日、延長更新サポート終了 2028年2月28日）で、対応する OpenShift は 4.19〜4.22 です。 - 中身は Jupyter／code-server のワークベンチ、AI Pipelines、KServe と vLLM・llm-d による推論、MLflow、モデルレジストリ、Ray・Kueue による分散処理、EvalHub などの評価機能、LLM を社内に配る Models-as-a-Service です。 - 使い方の単位は**プロジェクト**（OpenShift の namespace）です。プロジェクトの中に接続・ワークベンチ・パイプライン・デプロイ済みモデルを置きます。 - 導入の最低条件は **ワーカーノード2台以上・各8CPU／32GiB RAM**、動的プロビジョニング対応の既定ストレージクラス、ID プロバイダ設定、cluster-admin 権限、サブスクリプションです。 - 2.x から 3.x へ上げるには、**KServe の Serverless モードと ModelMesh のワークロードを先に移行**しておく必要があります。 - 推論 API を出すだけなら、OpenShift を持たずに使える Red Hat AI Inference や RHEL AI のほうが小さく始められます。 ## OpenShift AIの位置づけとRed Hat AI製品群での役割 Red Hat の公式ドキュメントは OpenShift AI を「data scientists and developers of artificial intelligence and machine learning (AI/ML) applications」向けのプラットフォームと定義しています。[Red Hat の製品ページ](https://www.redhat.com/ja/products/ai/openshift-ai)は MLOps・GenAIOps・AgentOps を組み合わせる基盤と説明し、PyTorch・Kubeflow・MLflow・vLLM などの OSS を使うと書いています。従来型の予測モデルと、LLM を使う生成AI・エージェントの両方が対象です。 提供形態は、自社で管理する OpenShift Container Platform に入れる **Self-Managed** が中心です。インストールガイドが挙げる導入先は、自社で運用する OpenShift Container Platform と OpenShift Kubernetes Engine（OKE）、Red Hat が関わるマネージド環境の OpenShift Dedicated（AWS／GCP）、Red Hat OpenShift Service on AWS（ROSA classic／ROSA HCP）、Microsoft Azure Red Hat OpenShift です。Azure 上のマネージド版の料金と構築手順は[Azure Red Hat OpenShift（ARO）とは？AKSとの違い・料金の実額・az aro createでの構築手順](/tech/details/18407/)で扱っています。 ### OpenShift AI・RHEL AI・AI Inference・AI Enterpriseの違いと選び分け Red Hat AI という製品群には、名前の近い製品が複数あります。OpenShift AI・RHEL AI・AI Inference の3製品はバージョン番号も揃っており（いずれも最新は 3.5・GA 2026年8月27日）、取り違えやすい部分です。 | 製品 | 正体 | 前提となる基盤 | 向いている用途 | | --------------------------- | --------------------------- | --------------------- | ------------------ | | Red Hat OpenShift AI | OpenShift 用の AI/ML プラットフォーム | OpenShift クラスター | 開発・学習・推論・評価を1基盤で運用 | | Red Hat AI Inference | vLLM と llm-d による推論スタック | 対応構成表に記載されたアクセラレータ・環境 | 推論APIの提供だけ | | Red Hat Enterprise Linux AI | AI Inference＋起動可能なRHELイメージ | サーバー単体（OSごと） | 1台〜少数台での推論 | | Red Hat AI Enterprise | 推論・エージェント・アプリの統合基盤 | Kubernetes コア | 全社規模の AI 基盤 | RHEL（Red Hat Enterprise Linux）は Red Hat の商用 Linux ディストリビューションで、RHEL AI はその「bootable image」に推論サーバーと PyTorch などのライブラリを同梱した製品です。製品ページは RHEL AI を「Red Hat AI Inference」と「A bootable image of Red Hat Enterprise Linux」の組み合わせと説明しています。クラスターを組まずに GPU サーバーでモデルを動かすなら RHEL AI、Kubernetes 上で複数チームがモデルを作って配信するなら OpenShift AI、という切り分けになります。 ## OpenShift AI 3.5の主要コンポーネントとDataScienceClusterの設定キー OpenShift AI の機能は、DataScienceCluster というカスタムリソースでコンポーネントごとに有効化します。3.5 のインストールガイドとリリースノートに載っているコンポーネントと役割は次のとおりです。 | DataScienceClusterのキー | 機能 | 中核の技術 | | --------------------- | --------------- | ----------------------------------- | | dashboard | プロジェクト管理・各機能の画面 | OpenShift AI ダッシュボード | | workbenches | 開発環境 | JupyterLab、code-server | | aipipelines | MLワークフローの自動化 | Kubeflow Pipelines、Argo Workflows | | kserve | モデルの推論API化 | KServe、vLLM、llm-d | | modelregistry | モデルの版・メタデータ管理 | Model Registry（API v1beta1） | | mlflowoperator | 実験・メトリクスの記録 | MLflow | | ray／kueue／trainer | 分散学習・ジョブの順番待ち | KubeRay 1.6系、Kueue、Kubeflow Trainer | | trustyai | 評価・安全性チェック | EvalHub、ガードレール | | feastoperator | 特徴量ストア | Feast | | ogx | RAG・エージェント向けAPI | OGX（旧 Llama Stack） | | aigateway | LLMの配信統制（MaaS） | Gateway API、Connectivity Link | パイプラインの土台になっている Kubeflow 自体の構成は[Kubeflowの全体像とPipelinesの使い方](/tech/details/9001/)で扱っています。OpenShift AI は Kubeflow を含む OSS 群を Red Hat が検証・パッケージ化し、サポートを付けて出しているものと捉えると、どこまでが製品固有かを見分けやすくなります。 ### 従来型ML・MLOps向けの機能（MLflow統合・Model Registry v1beta1） [OpenShift AI 3.5 のリリースノート](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fai%5Fself-managed/3.5/html/release%5Fnotes/index)で大きいのは MLflow の統合です。AI Pipelines、ワークベンチ、Kubeflow SDK、Kubeflow Trainer から学習ジョブを流すと、実験の実行・パラメータ・メトリクスが MLflow に自動で記録されます。MLflow はクラスターに1つだけ置く共有インスタンス（redhat-ods-applications に作られる cluster-scoped の MLflow リソース）で、OpenShift のプロジェクトが MLflow のワークスペースと1対1で対応し、プロジェクト単位でアクセスが分かれます。モデルレジストリの API は v1beta1 が最新で、v1alpha1 は 2.24 から非推奨です。 学習と前処理を複数ノードで回すのが distributed workloads で、Ray クラスターと Kueue によるジョブの順番待ち（クォータ管理）を組み合わせます。3.5 ではワークベンチの画面に Kueue 由来のスケジューリング状態が表示されるようになりました。 ### 生成AI・エージェント向けの機能（llm-d・EvalHubのGA） 推論は KServe の上で vLLM をランタイムに使うのが基本で、大規模モデルの分散推論には llm-d を使います。3.5 のリリースノートは「Distributed Inference with llm-d is generally available on Azure Kubernetes Service (AKS), CoreWeave Kubernetes Service (CKS), and OpenShift」と書き、ゲートウェイの実装には Istio と Gateway API Inference Extension（GAIE）を使うとしています。優先度別に要求を捌く flow control も GA になりました。ただし llm-d での配信には OpenShift 4.20 以降が必要です。 3.5 では EvalHub（評価のオーケストレーション）と Garak ベースの Automated Red Teaming も GA になり、モデルの脆弱性スキャンまで基盤内で回せます。一方、Gen AI studio のプレイグラウンド拡張（pgvector の既定ベクトルストア、マルチモーダル）や MCP Lifecycle Operator は、3.5 でも Technology Preview の扱いです。本番で頼る機能は、リリースノートで GA か Technology Preview かを先に確かめてください。KServe・Triton などのサービング方式の比較は[モデルサービングの構成と選定基準](/tech/details/16073/)、vLLM そのものは[vLLMの仕組みと使い方](/tech/details/15786/)、llm-d は[llm-dの仕組みと採用判断](/tech/details/16392/)を参照してください。 ### Models-as-a-ServiceとAI Gatewayの前提条件 Models-as-a-Service（MaaS）は、社内でホストした LLM を API として配り、グループごとにトークン上限と利用権限を割り当てる統制層です。[MaaS のガイド](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fai%5Fself-managed/3.5/html/govern%5Fllm%5Faccess%5Fwith%5Fmodels-as-a-service/index)は「a governance layer between users and model serving infrastructure」と説明しており、モデルサーバー側を変えずに、サブスクリプション（どのグループがどのモデルを何トークンまで使えるか）、API キー認証、使用量の集計を後から掛けられます。3.5 では OpenAI 互換の `/v1/chat/completions` にモデル名を本文で渡すだけでポリシーが効くようになり、Python の openai ライブラリや LangChain からそのまま呼べます。外部の OIDC プロバイダでの認証も 3.5 で加わりました。 導入の前提は重めです。ガイドが挙げる条件は次のとおりで、OpenShift AI の Operator を入れただけでは動きません。 - OpenShift 4.19.9 以降、OpenShift AI 3.5 以降、llm-d による分散推論を認証付きで有効化済み - Red Hat Connectivity Link Operator 1.4.x と、kuadrant-system namespace の Kuadrant カスタムリソース - DataScienceCluster で `aigateway` と `aigateway.modelsAsAService` をともに `Managed` - openshift-ingress namespace に `maas-default-gateway` という名前の Gateway（Gateway API）と TLS - User Workload Monitoring の有効化（無いと MaaS が Degraded になる） - 自前で用意する PostgreSQL 14 以降と、接続情報を入れた `maas-db-config` Secret（サブスクリプション・API キー・使用量の保存先で、3.4 から必須） AWS Bedrock・Azure OpenAI・Google Vertex AI などの外部モデルを同じゲートウェイ経由で配る機能や、テナントごとにゲートウェイを分けるマルチテナント機能は、3.5 時点では Technology Preview です。社内の GPU で動かすモデルを部署ごとに配って使用量を按分したい組織には合いますが、外部 API の利用統制だけが目的なら、3.5 の段階では本番の根拠にしにくいと判断しています。 ## OpenShift AIの使い方：プロジェクトからモデル配信までの流れ Operator を入れたあと、データサイエンティストがダッシュボードで行う作業は、[3.5 の Getting started ガイド](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fai%5Fself-managed/3.5/html/getting%5Fstarted%5Fwith%5Fred%5Fhat%5Fopenshift%5Fai%5Fself-managed/overview-for-getting-started%5Fget-started)に沿うと次の順になります。どの作業も「プロジェクト」の中で行うので、最初にプロジェクトの切り方を決めておくのが要点です。 1. **ダッシュボードにログインする**：OpenShift に設定した ID プロバイダのアカウントで入ります。ヘルプの About を開くと、導入済みのコンポーネントと対応する上流 OSS のバージョンが一覧で出ます。 2. **プロジェクトを作る**：OpenShift のプロジェクトは、注釈を足した Kubernetes の namespace で、アクセス権を分ける単位です。ダッシュボードで指定するリソース名は、小文字の英数字とハイフンで30文字以内とし、先頭は英字、末尾は英数字にします。作成後にリソース名は変更できませんが、表示名と説明は変更できます。チームや用途ごとに分けると、MLflow のワークスペースも同じ単位で分かれます。 3. **接続を追加する**：S3 互換オブジェクトストレージなどのエンドポイントと認証情報を、コードに直書きせずに使うための設定です。パイプラインとモデル配信にもオブジェクトストレージが要るので、ここで用意します。 4. **ワークベンチを作る**：IDE（JupyterLab か code-server）と Python パッケージを含むイメージを選び、クラスターストレージを付けて起動します。ストレージクラスは後から変えられません。同じプロジェクトのワークベンチ、パイプライン、モデルサーバーは、オブジェクトストレージを介してモデルとデータを共有します。 5. **パイプラインで自動化する**：前処理・学習・評価をコンテナの手順としてつなぎ、新しいデータが入るたびに再学習を回します。 6. **モデルをデプロイする**：学習済みモデルを推論 API として公開し、アプリから呼びます。3.x では KServe の RawDeployment（生成AI向けは llm-d）が配信の基本形です。 注意点が1つあります。3.5 の Getting started ガイドは、選べる IDE に「RStudio (Technology Preview)」を残したままですが、リリースノートは RStudio Server のワークベンチイメージを 3.5 で削除したと書いています。Red Hat がサポートする IDE として選べるのは JupyterLab と code-server で、R を使い続けたい場合はサポート対象外の自作 RStudio イメージを作る手順が公式資料に残っています。手を動かして流れを確かめるなら、公式の [不正検知のチュートリアル](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fai%5Fself-managed/3.5/html/openshift%5Fai%5Ftutorial%5F-%5Ffraud%5Fdetection%5Fexample/index)が、ワークベンチでの学習からデプロイまでを1本で通しています。 ## OpenShiftとKubernetesの違い（OpenShift AIの土台） 自前のイメージが起動しない、Operator の入れ方が違うといった OpenShift AI 特有のつまずきの多くは、土台の OpenShift に由来します。Red Hat の説明では、Kubernetes 単体はコンテナのデプロイ・管理・スケールを自動化するソフトウェアで、ネットワーク、Ingress、ストレージ、監視、ログ、CI/CD などは利用者が組み合わせます。OpenShift はそれらを統合し、サポート付きで提供する製品です。Kubernetes の基本は[Kubernetesの仕組みとDockerとの違い](/tech/details/2928/)にまとめています。 | 観点 | 素のKubernetes | OpenShift（4.22） | | --------- | ----------------------------- | ------------------ | | ノードのOS | 利用者が選ぶ | コントロールプレーンはRHCOS必須 | | コンテナランタイム | containerd等を選ぶ | CRI-O | | Pod の権限 | Pod Security Admission等を自前で設定 | SCCで既定から制限 | | 外部公開 | Ingress／Gateway API | 独自リソース Route も使える | | 拡張機能の導入 | Helm等を自前で運用 | OLMとソフトウェアカタログ | | クラスター更新 | 手順を自前で組む | CVOとMCOがOSまで含めて更新 | | CLI | kubectl | oc（kubectl互換） | RHCOS（Red Hat Enterprise Linux CoreOS）は RHEL の部品で作ったコンテナ専用 OS で、公式ドキュメントは「immutable container host version of Red Hat Enterprise Linux」と説明しています。設定変更はクラスター側から行う前提で、ノードに直接ログインして手で変える運用とは相性がよくありません。CentOS や Ubuntu を OpenShift のノード OS に選ぶ構成はとれません。 ### rootで動くコンテナイメージが起動しない理由（SCC） Kubernetes から OpenShift に移ったときに最初に当たりやすいのが Security Context Constraints（SCC）です。既定の restricted 系 SCC は、Pod を「namespace に割り当てられた UID の範囲」で動かすことを求め、特権コンテナとホストディレクトリのマウントを禁止します。4.22 の既定 SCC 一覧では、新規インストールで認証済みユーザーに使われる restricted-v3 がユーザー名前空間（`hostUsers: false`）まで強制します。 このため、Dockerfile で root ユーザーを前提にしている公開イメージや、特定の UID でファイル所有権を決め打ちしているイメージは、そのままでは起動に失敗します。対処はイメージ側を任意 UID で動くように直すのが本筋で、公式ドキュメントも既定 SCC を書き換えず、独自の SCC を作るよう求めています。OpenShift AI で問題になりやすいのは、Red Hat が提供するワークベンチイメージではなく、自前のカスタムイメージを持ち込む場面です。 ### OpenStackとOpenShiftの違い 名前が似ている OpenStack は、仮想マシン・ネットワーク・ストレージを提供する IaaS の基盤です。OpenShift はその上やベアメタル、パブリッククラウドの上で動くコンテナ基盤で、層が違います。Red Hat は OpenStack の制御部分をコンテナ化して OpenShift 上で動かす Red Hat OpenStack Services on OpenShift（18.0、GA 2024年8月26日）も出しており、現在の Red Hat 製品では「OpenShift の上に OpenStack が載る」構成もあり得ます。 ## OpenShift AIのバージョンとサポート期間 OpenShift AI Self-Managed は 2.x 系から 3.x 系へ移っています。Red Hat の Product Life Cycles API から取得した各版の期限は次のとおりです（2026年10月20日時点）。 | 版 | GA | フルサポート終了 | 延長更新サポート終了 | 対応OpenShift | | ---- | ---------- | ---------------- | ---------- | ----------- | | 3.5 | 2026-08-27 | 2027-03-29 | 2028-02-28 | 4.19〜4.22 | | 3.4 | 2026-05-14 | 2026-11-16 | なし | 4.19〜4.21 | | 3.3 | 2026-03-05 | 2026-10-05（終了済み） | なし | 4.19〜4.21 | | 2.25 | 2025-10-23 | 2026-05-25（終了済み） | 2027-04-26 | 4.16〜4.21 | 3.0（2025年11月13日GA）と 3.2 はサポートが終わっています。3.3 のフルサポートは2026年10月5日に切れ、3.4 も2026年11月16日で切れます。どちらも延長サポートが無いので、使っている環境は延長サポートのある 3.5（eus-3.5）へ上げる時期に来ています。なお 3.5 のインストールガイド本文には対応 OpenShift が「4.19 to 4.20」と書かれたままで、ライフサイクル情報（4.19〜4.22）と食い違っています。導入前は Red Hat の Supported Configurations for 3.x で照合してください。 ### 更新チャネル5種のリリース頻度とサポート期間 Operator の Subscription に指定する更新チャネルで、受け取る版とサポート期間が決まります。 | チャネル | リリース頻度 | フルサポート | 想定する環境 | | ------------- | ------ | ---------- | --------------- | | fast／fast-x.y | 毎月 | 1か月 | 新機能を早く使いたい本番 | | stable | 3か月ごと | 3か月 | 自動更新で安定版を追う本番 | | stable-x.y | 3か月ごと | 7か月 | 版を固定して計画的に上げる本番 | | eus-x.y | 9か月ごと | 7か月＋延長11か月 | 7か月以内に上げられない環境 | | alpha | 毎月 | 1か月 | 開発・検証（本番SLA対象外） | 社内の変更管理で四半期より短い間隔の更新が難しいなら、stable-x.y か eus-x.y を選びます。7か月以内に次の版へ上げる体制が無ければ eus-x.y 一択です。embedded と beta は将来削除される旧チャネルで、新規導入では選ばないよう明記されています。 ## OpenShift AIの導入要件とインストール手順 3.5 のインストールガイドが挙げる前提条件は次のとおりです。ハードウェア要件は Operator を入れるための最低値で、GPU を使う学習や推論の分は別に積み増します。 - OpenShift AI Self-Managed のサブスクリプション（ROSA などに入れる場合はその基盤のサブスクリプションも必要） - cluster-admin ロールを持つユーザー（kubeadmin ユーザーは不可） - ワーカーノード2台以上・各8CPU／32GiB RAM以上（シングルノード OpenShift なら32CPU／128GiB RAM以上） - 動的プロビジョニングに対応した既定ストレージクラス（`oc get storageclass` で確認） - OpenShift に ID プロバイダが設定済みであること - 同じクラスターに Open Data Hub が入っていないこと OKE（OpenShift Kubernetes Engine）では通常入れられない Operator について、OpenShift AI 用途に限ったライセンス上の例外があります。3.x で例外の対象になるのは Kueue Operator、cert-manager Operator、Leader Worker Set Operator、GPU Operator などで、AI 以外の用途に使うと OKE の契約違反になると書かれています。 ### OpenShift AI OperatorとDataScienceClusterのCLI導入手順 Web コンソールのソフトウェアカタログ（旧称 OperatorHub）からも入れられますが、手順を再現可能にするなら `oc` で CR を作ります。公式手順の流れは、Namespace → OperatorGroup → Subscription で Operator を入れ、最後に DataScienceCluster で使うコンポーネントを選ぶ、の4段階です。下の3つをまとめたファイル（例：`rhods-operator.yaml`）を `oc create -f` で適用し、Operator の状態が Succeeded になってから DataScienceCluster を作ります。 ``` # 1. Operator 用の Namespace と OperatorGroup apiVersion: v1 kind: Namespace metadata: name: redhat-ods-operator --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: rhods-operator namespace: redhat-ods-operator --- # 2. Subscription（channel は stable-3.5 や eus-3.5 などを指定） apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: rhods-operator namespace: redhat-ods-operator spec: name: rhods-operator channel: stable-3.5 source: redhat-operators sourceNamespace: openshift-marketplace ``` Operator が入ったら、DataScienceCluster で各コンポーネントの `managementState` を `Managed`（導入して維持）か `Removed`（導入しない）に設定します。下の例はダッシュボード・ワークベンチ・パイプライン・推論・MLflow Operator を有効にする構成例です。適用後は DataScienceCluster の状態と各コンポーネントの起動を確かめ、MLflow はカスタムリソースを作ったあとで UI に入れることを確かめます。kserve を有効にする前に cert-manager Operator を入れておくこと、モデル配信とパイプラインには S3 互換のオブジェクトストレージが要ること、MLflow は Operator を有効にしたあと `MLflow` カスタムリソースを別に作ること、の3点が公式の前提です（trainer を使う場合は JobSet Operator も必要）。 ``` apiVersion: datasciencecluster.opendatahub.io/v2 kind: DataScienceCluster metadata: name: default-dsc spec: components: dashboard: managementState: Managed workbenches: managementState: Managed workbenchNamespace: rhods-notebooks aipipelines: managementState: Managed kserve: managementState: Managed mlflowoperator: managementState: Managed modelregistry: managementState: Removed ray: managementState: Removed kueue: managementState: Removed trainer: managementState: Removed trainingoperator: managementState: Removed trustyai: managementState: Removed feastoperator: managementState: Removed ogx: managementState: Removed ``` ``` oc create -f rhods-operator-dsc.yaml # datasciencecluster.datasciencecluster.opendatahub.io/default-dsc created ``` 導入後は redhat-ods-operator（Operator）、redhat-ods-applications（ダッシュボードなど）、rhods-notebooks（ワークベンチ）の3つの namespace ができます。ワークベンチの namespace は Operator 導入後に変更できないため、命名規則がある組織は先に決めておきます。 ## 2.xから3.xへの移行前に片付ける作業と削除・非推奨機能 3.x は 2.x からの単純なマイナー更新ではありません。リリースノートの非推奨・削除一覧を読むと、移行前に片付ける作業がいくつもあります。 - **KServe の Serverless モードと ModelMesh**：3.0 で廃止されました。リリースノートは「all workloads that use the retired Serverless or ModelMesh modes must be migrated before upgrading」と書いており、RawDeployment モードへ移してからでないと上げられません。 - **アップグレードゲート**：3.5 へ上げるとき、Operator はコンポーネントを更新する前にゲートチェックを実行し、確認や移行が必要な項目を Operator の namespace の `odh-upgrade-acks` ConfigMap に記録します。解消した項目は自動で承認されます。 - **移行ツール rhai-cli**：2.25.9 以降の 2.25 系から 3.5 へ移すための評価・移行ガイドが 3.5 で公開されました。Kueue、AI Pipelines、Model Serving、ワークベンチ、TrustyAI、Training、Llama Stack／OGX、Ray の各コンポーネントに `rhai-cli migrate` の手順があります。 - **移行用チャネルからの切り替え**：移行に使った `support-required-upgrade-3.5` チャネルのままにせず、stable-3.5・stable-3.x・eus-3.5 などへ切り替えます。 - **Kubeflow Training Operator v1**：2.25 から非推奨で、3.5 では v1 用の学習ランタイムイメージが削除されました。Kubeflow Trainer v2 へ移します。 - **Trainer v2 と Kueue の組み合わせ**：3.5 の既知の問題（RHOAIENG-87625）で、Red Hat build of Kueue 1.4 以降にすると Trainer v2 との連携が壊れます。公式の回避策は Kueue を 1.3 に留めることですが、既知の問題の記載自体が 1.3 は「no longer supported」と認めており、しかも 1.3 は OpenShift 4.22 では提供されません。Trainer v2 と Kueue の連携が必須の環境は、修正版が出るまで 3.5 への更新を待つか、サポート条件を Red Hat に確認してから進めます。 - **Llama Stack の改称**：3.5 EA1 から OGX に名前が変わり、既存構成は手動での移行が必要です。 - **RStudio Server のワークベンチイメージ**：ライセンス上の理由で 3.5 から削除されました。動いている RStudio ワークベンチは更新後も動きますが、ダッシュボードからの新規作成と停止後の再起動はできません。R で分析している部署は代替環境を先に用意します。 - **ガードレール**：FMS Guardrails Orchestrator が 3.5 で非推奨になり、NeMo Guardrails に一本化されます。 2.25 は `eus-2.25` チャネルなら延長サポートが2027年4月26日まで残ります。この期間は移行準備に充てるもので、期限まで使い切る前提にはしません。Serverless と ModelMesh の移行、互換性の試験、切り戻しの試験を済ませ、期限より前に 3.5 の eus-3.5 へ切り替える計画を立てます。3.x の新機能（MLflow 統合・llm-d・MaaS）をすぐ使いたいなら、移行の時期をさらに早めます。 ## OpenShift AIを採用しないほうがよいケースと試し方 OpenShift AI は OpenShift の運用体制があることが前提です。次の条件に当てはまるなら、別の選択肢から検討したほうが費用も手間も小さく済みます。 - **OpenShift クラスターを持っていない**：60日間の製品トライアルも「An existing Red Hat OpenShift cluster is required」とされており、OpenShift AI 単体では始められません。 - **やりたいのが LLM の推論 API 提供だけ**：Red Hat AI Inference や RHEL AI なら OpenShift を用意せずに vLLM ベースの推論を始められます。素の Kubernetes に KServe や vLLM を自前で組む選択肢もあります。 - **ML の運用工程がまだ定まっていない**：パイプライン・レジストリ・監視をどこまで仕組み化するかが決まっていない段階では、基盤だけ入れても使われません。先に[MLOpsの仕組みと導入判断](/column/details/2939/)で必要な工程を洗い出します。 試す方法は2つあります。個人で触るなら事前構成済みの Developer Sandbox、組織として評価するなら既存の OpenShift クラスターに入れる60日トライアルです。製品ページに価格の掲載は無く問い合わせ窓口へ誘導する形なので、トライアル中に必要な GPU ノード数とチャネル（サポート期間）を決めておくと見積りが早く進みます。基盤の選定から推論 API を組み込んだアプリの実装まで外部の手を借りる場合は、[生成AI開発・AI受託開発](/service/ai/development/)のような支援も選択肢になります。 ## よくある質問 ### OpenShift AIの最新バージョンはいくつですか？ 2026年10月20日時点の最新は 3.5 系で、2026年8月27日に GA になり、2026年9月にセキュリティ更新を含む 3.5.1 が出ています。対応する OpenShift は 4.19〜4.22 です。最新の版とサポート期間は Red Hat の[Red Hat OpenShift AI Self-Managed Life Cycle](https://access.redhat.com/support/policy/updates/rhoai-sm/lifecycle)で確認できます。自分のクラスターに入っている各コンポーネントの版は、ダッシュボードのヘルプにある About で見られます。 ### OpenShift AIでMLflowは使えますか？ 使えます。MLflow Operator は 3.4 から DataScienceCluster の管理対象コンポーネントになり、3.5 では AI Pipelines・ワークベンチ・Kubeflow Trainer から実行した学習ジョブの実験記録が、クラスター共有の MLflow インスタンスにプロジェクト単位のワークスペースとして自動で残ります。有効化は、DataScienceCluster の `mlflowoperator` を `Managed` にしたうえで、`MLflow` カスタムリソースを1つ作る2段階です。 ### OpenShift AIとRHEL AIはどう違いますか？ OpenShift AI は OpenShift クラスター上で開発から推論・評価までを扱う基盤、RHEL AI は RHEL の起動イメージに推論スタックを同梱してサーバー単体で動かす製品です。複数チームで共有するなら OpenShift AI、少数の GPU サーバーで推論するなら RHEL AI が合います。 ### OpenShift AI Operatorとは何ですか？ OpenShift AI をクラスターに導入・更新するための Operator で、パッケージ名は `rhods-operator` です。redhat-ods-operator namespace に Subscription を作って入れ、どの機能を使うかは DataScienceCluster のコンポーネントごとに `Managed` か `Removed` で指定します。更新の頻度とサポート期間は、Subscription に書く更新チャネル（stable-3.5、eus-3.5 など）で決まります。 ### OpenShift以外のKubernetesでOpenShift AIは使えますか？ OpenShift AI 本体の導入先は OpenShift Container Platform、OpenShift Dedicated、ROSA、Azure Red Hat OpenShift、OKE です。ただし 3.5 のリリースノートでは、llm-d による分散推論が AKS と CoreWeave Kubernetes Service でも GA とされています。一方で Red Hat AI Inference の製品ページは第三者の Kubernetes 上の llm-d を「early access」と書いたままなので、OpenShift 以外で使う場合は、どの製品の契約でどこまでサポートされるかを営業窓口で確認してください。 ## 関連記事 - [Kubernetes（クバネティス）とは？メリット・デメリットと仕組み、Dockerとの違いを解説](/tech/details/2928/) - [Kubeflowとは？Kubernetes上の機械学習基盤の全体像とPipelinesの使い方](/tech/details/9001/) - [llm-dとは？Kubernetesネイティブ分散推論の仕組みと採用判断を実装者目線で解説](/tech/details/16392/) - [モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】](/tech/details/16073/) - [MLOpsとは？機械学習の運用を支える仕組みと導入判断をわかりやすく解説](/column/details/2939/) --- 出典: [Red Hat OpenShift AIとは？最新3.5の機能・使い方・導入要件とKubernetesとの違い]()（株式会社一創）