Red Hat build of Keycloak（RHBK）は、オープンソースのKeycloakをRed Hatが製品として配布し、保守期間とサポート窓口を付けたものです。認証機能そのものはOSS版と同じ系統なので、選ぶ理由は機能ではなく「版をどれだけ長く据え置けるか」「誰に問い合わせられるか」「費用をどこで数えるか」の3つが判断の軸です。この記事では、2026年10月時点のRed Hat公式とKeycloak公式の一次情報をもとに、OSS版との違い、単体では買えないライセンスの仕組み、Red Hat Single Sign-On（RH-SSO）からの移行で詰まる箇所、RHBKを選ぶ条件と見送る場面を整理します。Keycloakそのものの機能や他製品との比較はKeycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断で扱っています。
まとめ：Red Hat build of Keycloakは「版の据え置き期間と問い合わせ窓口」を買う選択
- 中身はKeycloak：ライセンスはOSS版と同じApache License 2.0の系統で、RHBKにしか無い認証機能を買うわけではありません。
- 違いは保守の時間軸：OSS版の脆弱性修正は原則として最新のmajor.minorにしか入りません。RHBKは各マイナー版に約12か月のパッチが出て、常に2系列以上が保守されます。
- 単体では買えない：Red Hat Runtimes、Red Hat Application Foundations、OpenShift Container Platformなどのバンドルに含まれ、利用分はそのバンドルのコア数に算入されます。
- 選ぶ条件：OpenShiftやRuntimesを既に契約している、アップグレードを年1〜2回に抑えたい、監査や顧客契約でベンダー保守が求められる、のいずれかに当てはまるならRHBKです。
- 見送る条件：Red Hat契約が無くKeycloakのためだけにバンドルを買う、EKSやGKEで動かしサポート条件を契約前に確認できない、新機能を早く使いたい場合はOSS版と自社または委託先の保守で回します。
判断の分かれ目は機能比較表ではなく、自社が「OSS版の新しいマイナー版へ数か月ごとに上げ続けられるか」です。上げ続けられないのに本番の認証基盤をOSS版で持つと、脆弱性修正を受け取れない版で運用することになります。
Red Hat build of Keycloakとは：RH-SSOの後継製品
RHBKは、Red Hatが自社サポートの対象として配布するKeycloakです。Red Hatの製品ページでは「オープンソースのKeycloakプロジェクトに基づくクラウドネイティブなID・アクセス管理ソリューション」と説明されています。
2023年11月15日に一般提供開始、RH-SSOの今後のリリースを置き換え
Red Hatは2023年11月15日にRHBKの一般提供を発表しました。サブスクリプション要件の公式記事によると、RHBKは既存のRH-SSOに代わる製品で、RH-SSOはバージョン7.6の保守サポート終了をもって製品寿命を終えます。製品ページにも「RH-SSOの今後計画されているリリースを置き換える」「RH-SSOからRHBKへ今すぐ移行できる」と書かれています。
つまりRH-SSO 7.6を使っている組織にとって、RHBKは「検討してもよい選択肢」ではなく、Red Hatのサポートを受け続けるための移行先です。
版番号はKeycloakと同じ体系、2026年10月の最新系列は26.6
RHBKの版番号はKeycloak本体と同じ体系で付きます。サポート構成の公式記事（2026年10月14日更新）が対象に挙げるのは26.6.x、26.4.x、26.2.x、26.0.x、24.0.x、22.0.xの6系列です。製品ページのセキュリティ情報には、26.6.6と26.4.15の更新がCritical（重大）として並んでいます。
一方、OSS版はKeycloak公式のダウンロードページで26.8.1が最新です（2026年10月23日確認）。RHBKはOSS版の偶数マイナー版を約半年ごとに製品化するため、OSS版より1〜2マイナー版遅れて進みます。この遅れは欠点ではなく、Red Hatが検証を済ませた版だけを出すという設計の結果です。
OSS版KeycloakとRHBKの違い：保守期間とサポート範囲で比較
両者の差は、認証機能ではなく保守と検証の範囲にあります。2026年10月時点の公式情報で比べると次のとおりです。
| 比較項目 | OSS版Keycloak | Red Hat build of Keycloak |
|---|---|---|
| ライセンス | Apache License 2.0 | OSSに基づく製品 |
| 入手方法 | 無償ダウンロード | 対象バンドルの契約者 |
| 最新版（2026年10月） | 26.8.1 | 26.6系 |
| 脆弱性修正の対象 | 現行のmajor.minor | 各マイナー版を約12か月 |
| 同時に保守される系列 | 実質1系列 | 常に2系列以上 |
| プレビュー機能 | 既定無効・本番非推奨 | 重大度3と4のみ受付 |
| 動作環境の認定 | なし | OS・JDK・DB・OCPを認定 |
| 問い合わせ先 | メーリングリスト・Slack | Red Hatのサポート窓口 |
表のうち費用と運用に効くのは「脆弱性修正の対象」と「同時に保守される系列」の2行です。残りの行は、この2行の違いから派生する性格のものと考えて差し支えありません。
脆弱性修正の届き方：OSS版は最新major.minorだけ、RHBKは約12か月
KeycloakのSECURITY.mdは、脆弱性は現行のmajor.minorリリースで修正し、重大度の低いものや堅牢化は次のmajor.minorリリースで対応すると定めています。そのうえで、頻繁なアップグレードが難しい場合は特定バージョンを長期サポートするRHBKを使うよう案内しています。OSS版で古い系列を使い続けると、修正を受け取る経路がありません。
RHBKのライフサイクル方針では、マイナー版は約6か月ごとに出て、各マイナー版は2つ後のマイナー版が出るまで、おおむね12か月パッチが提供されます。メジャー版の保守期間は26.xで最低2年、27.x以降は3年です。新しいメジャー版が出たあとも、旧メジャー版は最低6か月メンテナンスが続きます。
年に1〜2回しか認証基盤を更新できない組織では、この差がそのまま「修正を受け取れる期間」の差になります。
プレビュー機能の扱い：本番でサポートを頼れるのは正式機能だけ
Keycloakの機能の有効化ガイドは、プレビュー機能を既定で無効とし、本番での利用を推奨していません。2026年10月時点の一覧にはtoken-exchange:v1やclient-admin-api:v2など9件が並び、将来の版で変更や削除がありうると明記されています。
RHBKでも、プレビュー機能はRed HatのTechnology Previewの扱いです。Technology Previewのサポート範囲では、サポートケースを開けるのは重大度3または4に限られ、安定性も保証されません。RHBKを契約しても、プレビュー機能で起きた障害を本番障害として急ぎで扱ってもらえるわけではない点は、設計段階で押さえておく必要があります。
動作環境の認定：RHEL・OpenJDK・DBの版の組み合わせが決まっている
サポート構成の公式記事によると、RHBK 26.6.xはRHEL 10・9・8とWindows Server 2022・2019で、Red Hat OpenJDKまたはEclipse Temurinの25・21・17を使う構成が対象です。データベースはPostgreSQL 14〜18、MySQL 8.4、MariaDB 11.8・11.4・10.11・10.6、SQL Server 2022・2019、Oracle 23aiと19c、Aurora PostgreSQL 15〜17などが並びます。RHEL以外のLinuxディストリビューションは認定対象外と書かれています。
OSS版はこうした認定を持たず、組み合わせの検証は利用者の仕事です。DB接続やバックアップの設計はKeycloakのデータベース設定と使い方で手順を扱っていますが、RHBKで運用するなら、そこで選ぶDBと版を最初からサポート対象の一覧に合わせておくと、障害時に「対象外構成」として扱われる事態を避けられます。
EKS・AKS・GKEで動かす場合はサポート条件が別扱いで事前確認が必要
同じ記事は、EKS・AKS・GKEなどOpenShift以外のKubernetes環境をRed Hatの試験対象外とし、サポートは別のナレッジ記事で定めるとしています。その記事の回答部分は契約者限定で、公開範囲からは条件を読めません（2026年10月23日確認）。
EKSやGKEでRHBKを動かす計画なら、契約前に営業窓口でサポート条件と必要なサブスクリプションを書面で確認してください。確認が取れないまま契約すると、「サポート付きのつもりで買ったのに、障害時に対象外と言われる」構成になります。
RHBKのライセンスと費用の仕組み：単体販売なし、コア数で数える
RHBKの費用を見積もるときに最初に戸惑うのが、製品単体の価格表が見当たらないことです。理由は、Red Hat build of Keycloakを単体で販売せず、対象バンドルのサブスクリプションに利用資格を付けるというライセンスの仕組みにあります。
Apache License 2.0のまま、費用はサブスクリプション側にかかる
KeycloakのGitHubリポジトリはApache License 2.0で公開されています。RHBKもこのOSSに基づく製品であり、Red Hatが売っているのはソフトウェアの使用許諾ではなく、検証済みの配布物・パッチ・サポートをまとめたサブスクリプションです。
コンテナイメージも、OSS版とRHBKでは配布元が別です。RHBKのイメージはRed Hat Ecosystem Catalogのrhbk/keycloak-rhel9として、RHEL 9ベースで提供されています。OSS版のイメージをそのまま使っている構成では、RHBKに切り替えると取得元の認証設定とイメージ名の変更が発生します。
RHBKの利用資格は対象バンドル契約に付属：OKEは対象外で単体購入不可
サブスクリプション要件の公式記事によると、RHBKの利用資格はRed Hat Runtimes、Red Hat Application Foundations、OpenShift Container Platformの各サブスクリプションと、これらを含むバンドルに付いてきます。マネージド版のROSA、ARO、OpenShift Dedicatedで動かす場合も対象です。
反対に、OpenShift Kubernetes Engine（OKE）には含まれません。また「バンドルの外で、独立した製品としては購入できない」と明記されています。AzureでOpenShiftを使っている、あるいは検討中なら、Azure Red Hat OpenShift（ARO）とはで整理した契約形態の中にRHBKの利用資格が含まれるかを、まず確認するのが近道です。
コア数への算入：RH-SSOから変わった数え方で見積りが増える
同じ記事は、RHBKの利用分はそれを含むバンドルのコア数に算入されると定めており、これをRH-SSOからの変更点として挙げています。認証基盤を冗長化してノードを増やすほど、バンドル側で消費するコア数も増える仕組みです。
公式の製品ページとサブスクリプション要件の記事には、単価の記載がありません（2026年10月23日確認）。見積りを取るときは、Keycloakを動かすノードのコア数と冗長構成の台数を先に決め、既存契約の残りコア数で収まるかを販売代理店に確認します。複数拠点での冗長化（Multi-Site）にはRed Hat Data Gridも必要になるため、その分も含めた確認が、見積りの後からの増額を避けるために必要です。ID基盤全体の費用の積み上げ方はID管理システムの費用・料金で、ライセンス・連携の改修・運用の3つに分けて整理しています。
RH-SSO 7.6からRHBKへの移行：設定変更と連携アプリ改修
RH-SSO利用者にとってRHBKは移行先ですが、同じKeycloak系統でも中身の作りは大きく変わっています。
Quarkus版への切り替えで/authの既定パスと設定方法が変わる
Keycloak本体はバージョン17から、既定の配布形態がQuarkusベースになりました。Keycloak公式のQuarkus版への移行ガイドは、主な変更として既定のコンテキストパスから/authが外れたこと、設定方法が大きく変わったこと、Quarkusはアプリケーションサーバーではなくアプリケーションを作るためのフレームワークであることを挙げています。
実務で影響が大きいのは/authです。RH-SSO時代のURLをそのまま登録している連携アプリ、リバースプロキシの転送設定、監視のヘルスチェックは、パスを合わせ直さないとログインが通らなくなります。移行計画では、Keycloak本体の移行作業と同じくらい、連携先の設定変更の洗い出しに工数を割いてください。
クライアントアダプターの非提供で移行時に連携アプリ側の改修が必要
サポート構成の公式記事には、RHBK 22.0以降、一部のクライアントアダプターは非推奨となりリリースされていないと書かれています。RH-SSO時代にアプリへアダプターを組み込んでいた場合、RHBKへ移るタイミングでアプリ側をOpenID Connectの標準ライブラリなどに置き換える改修が発生します。
この改修はKeycloakサーバーの移行とは別の、連携アプリごとの開発作業です。連携アプリが10本あれば10本分の改修と試験が要るため、移行の見積りはサーバー台数ではなく連携アプリの本数で組むのが現実的です。
OSS版とRHBKの選び分け：保守と契約から判断する採用・見送り条件
ここまでの一次情報を踏まえ、どちらを選ぶかを条件で言い切ります。
RHBKを選ぶ条件：OpenShift契約あり・年1〜2回の更新・ベンダー保守必須
次のいずれかに当てはまるならRHBKを選びます。
- OpenShift Container PlatformやRuntimesを既に契約していて、残りのコア数でKeycloakのノードを収められる
- 認証基盤のアップグレードを年1〜2回に抑えたく、その間も脆弱性修正を受け取りたい
- 監査や顧客との契約で、本番の認証基盤にベンダーの保守契約があることを求められている
1は追加費用がほぼかからず、2と3は保守の時間軸そのものが要件になっている状態です。特に2は、OSS版のSECURITY.mdが長期サポートの代替としてRHBKを名指ししている場面そのものと言えます。
RHBKを見送る場面：契約なし・EKSやGKEで運用・新機能を早く使う
Red Hatの契約が無い組織が、Keycloakのためだけにバンドルを新規契約するのは過剰です。単体で買えない以上、使わないミドルウェアの分まで費用を払うことになります。EKSやGKEで動かす計画で、契約前にサポート条件を書面で確認できない場合も見送ります。サポートを買ったつもりで対象外構成になる危険があるためです。
OSS版の新しいマイナー版で入った機能を早く使いたい場合も、RHBKは向きません。RHBKはOSS版より1〜2マイナー版遅れて進み、プレビュー機能には本番並みのサポートが付かないからです。ログイン画面の作り込みよりも導入の手軽さを重視するなら、OSSのKeycloak以外にFusionAuthとはで比べた別製品を候補に入れる手もあります。
OSS版で運用するなら月次でマイナー版に追従する体制を先に用意
OSS版を選ぶ場合の前提は、新しいマイナー版へ数か月以内に上げ続けられることです。最低限、検証環境で新版のリリースノートと移行ガイドを確認し、連携アプリのログインを試験してから本番を上げる流れを、月1回程度で回せる担当者を置きます。この体制を置けないなら、OSS版はライセンス費ゼロでも、修正の届かない版を本番に残すことになります。
社内で追従の体制を持てない場合は、構築と保守を外部に任せることも選択肢の一つです。一創の認証基盤・ID管理システム開発では、Keycloakを使った認証基盤の構築から、既存の業務システムとのSSO連携、RH-SSOからの移行に伴う連携アプリの改修まで相談を受けています。RHBKを契約するか、OSS版と委託保守で回すかの比較も、連携アプリの本数と更新頻度を伺ったうえで整理できます。
よくある質問
Red Hat build of KeycloakとOSS版Keycloakの違いについて、検討段階でよく出る質問にまとめて答えます。
Red Hat build of KeycloakとKeycloakの機能は違いますか？
認証機能は同じKeycloakの系統で、RHBKにしか無い認証機能を買う製品ではありません。違うのは、Red Hatが検証した版だけを約6か月ごとに出すこと、各マイナー版に約12か月のパッチが出ること、サポート窓口とOS・JDK・DBの認定があることです。そのため、ある時点ではOSS版にだけ入っている新機能があります。2026年10月時点ではOSS版が26.8.1、RHBKの最新系列は26.6です。
Keycloakは商用利用しても無料ですか？
OSS版はApache License 2.0で、ライセンス費用なしで商用利用できます。ただし構築・冗長化・パッチ適用にかかる作業と費用は自社の負担です。RHBKはRed Hat RuntimesやOpenShift Container Platformなどのサブスクリプションに含まれる形でのみ提供され、利用分はそのバンドルのコア数に算入されます。機能の概要や他のIDaaSとの費用構造の違いはKeycloakとはで比較しています。
Red Hat build of Keycloakだけを単体で購入できますか？
できません。Red Hatのサブスクリプション要件の記事に、バンドルの外で独立した製品として購入することはできないと明記されています。利用資格はRed Hat Runtimes、Red Hat Application Foundations、OpenShift Container Platformと、それらを含むバンドルに付きます。ROSAやAROなどのマネージドOpenShiftも対象ですが、OpenShift Kubernetes Engineは対象外です。
RH-SSOのサポートはいつまでですか？
Red Hatの公式記事では、RH-SSOはバージョン7.6の保守サポート終了をもって製品寿命を終え、RHBKがその後継になると説明されています。RH-SSOの新しいリリースは今後出ません。移行では、Keycloak 17以降のQuarkus版で既定パスから/authが外れたことと、22.0以降に一部のクライアントアダプターが提供されていないことが、連携アプリの改修につながります。
Red Hat build of KeycloakはEKSやAKSでもサポートされますか？
RHBKのサポート構成の記事では、EKS・AKS・GKEなどOpenShift以外のKubernetes環境はRed Hatの試験対象外とされ、扱いは別のナレッジ記事で定められています。その記事の回答は契約者限定で、公開範囲からは条件が読めません。これらの環境で動かす計画なら、契約前に販売代理店かRed Hatの営業窓口で、サポート条件と必要なサブスクリプションを書面で確認してください。
関連記事
- 認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説：Keycloakを含む認証基盤の全体像と選定の考え方
- IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説：自前で持たずクラウドに任せる場合の比較先
- OpenShift GitOpsとは：Operatorのインストール手順とupstream Argo CDとの違い：同じくRed Hat製品とupstream版の違いを扱った記事
