LASSIC Media らしくメディア
OpenAMの移行先の選び方｜開発終了の経緯と判断のポイント
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- OpenAMの名前での開発は元の開発元では2016年の版が最後で、いまは国内の事業者やコミュニティの版が使われています。
- OSSTech版ではOpenAM 9・11・13に修正が出ないため、まず自社の版とOSを確かめることが出発点です。
- Keycloakは標準の連携方式とLDAPに対応し、代理認証に頼るアプリが無ければ移行先の候補になります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
OpenAMは開発が終わったと聞いたが、いまの版はいつまで使えるのか。後継の候補が多くて違いが分からない——。社内のシングルサインオンをOpenAMで組んできた会社では、こうした迷いが起こりがちです。OpenAMは、複数のシステムへのログインを1か所にまとめるオープンソースの認証基盤です。
移行先には、OpenAMの系譜を使い続ける道も、Keycloakのような別の製品に移る道もあります。ただし万能な答えはなく、何をどうつないでいるかで向き不向きが分かれます。本記事では、情報システムの担当者に向けて、開発終了の経緯、移行先の違い、Keycloakが向く場面、移行の進め方、そして外部に頼むときに確認したい点を整理します。
目次
OpenAMの開発終了とは
「OpenAMの開発終了」は、1つの出来事を指す言葉ではありません。OpenAMは提供元が何度か変わってきた製品で、どの系譜の話かによって意味が違います。Ping Identityの資料によると、元はSun Microsystemsの製品で、2010年にOracleがSunを買収して開発が止まったあと、ForgeRockが引き継いでOpenAMと名付けました。*1
- OpenAMの名前で出た最後の版は、2016年の13.0.0と13.5.0です*1
- 2017年からはAccess Managementの名前で版を重ね、ForgeRockは2023年にPing Identityの一員になりました*1
- 2024年以降はPingAMの名前で新しい版が出ています*1
- 国内ではOSSTech（オープンソース・ソリューション・テクノロジ）が自社版のOpenAMを提供し、修正の版を出し続けています*2
つまり、OpenAMの名前での開発は元の開発元ではすでに終わっています。OSSTechの2026年7月のお知らせでは、脆弱性（セキュリティ上の弱点）の修正をOpenAM 14向けに出す一方、OpenAM 9・11・13と、サポートが終わったOSの上で動かしているOpenAM 14には修正を出さないとしています。*2 対象のOSのメンテナンス期間が終わっているためです。
動かす土台にも期限があります。OpenAM 14が使っていたOpenJDK 11（Javaの実行環境）は、Red Hat Enterprise Linux同梱のものが2024年10月にサポート終了の予定だったため、OpenJDK 21で動く版が用意されました。*3 自社のOpenAMが「どこの何番の版を、どのOSとJavaで動かしているか」を確かめることが出発点です。
移行先の選択肢の違い
自社でサーバーを持つ前提なら、OpenAMからの移り先は大きく4つに分かれます。同じ系譜を使い続ける道が3つ、別の製品に移る道が1つです。どれが合うかは、つないでいるシステムの数と種類、社内の運用体制で変わります。
| 選択肢 | どういうものか | 考えておきたいこと |
|---|---|---|
| OSSTechのOpenAM 14へ上げる | 国内の事業者が提供するOpenAM。代理認証やOpenLDAPとの連携の機能を持つ*4 | 製品の版上げに加え、OSとJavaの実行環境の更新もそろえる |
| コミュニティ版のOpenAM | Open Identity PlatformがGitHubで公開するOpenAM。ライセンスはCDDL*5 | 更新の適用や問い合わせの窓口をどう確保するかを決める |
| PingAM | ForgeRockのAccess Managementを引き継ぐ製品*1 | 提供条件と移行の手順を提供元に確かめる |
| Keycloak | OpenAMとは別のオープンソースの認証基盤。ライセンスはApache-2.0*7 | 設定の考え方が違うため、連携をつなぎ直す作業が要る |
表は事実の違いを並べたもので、優劣の評価ではありません。版上げを選ぶ場合も、修正が出る版とOSの組み合わせを保ち続けられるかまで見て決めます。サーバーを持たずにクラウドの認証サービス（IDaaS）へ移す道もあり、その考え方は認証基盤・IDaaS連携開発の外注で扱っています。
Keycloakへの移行が向いている場面
Keycloakは、アプリにログインの機能を付けるためのオープンソースの認証基盤です。2023年4月10日に、クラウド向けのオープンソースを育てる団体であるCNCFのプロジェクトとして、Incubating（育成段階）の位置づけで受け入れられました。*8 公式サイトでは、主な機能を次のように説明しています。*6
- SSO（シングルサインオン）：一度ログインすれば別のアプリに入り直さずに済み、ログアウトも1回で全部のアプリに及ぶ
- 標準の連携方式：OpenID Connect、OAuth 2.0、SAML 2.0に対応する
- 既存の利用者情報とつなぐ：LDAPやActive Directoryのサーバーに接続できる
- 外部の認証との連携：ほかのOpenID ConnectやSAML 2.0の認証基盤でログインさせられる
SAMLやOpenID Connectでクラウドサービスとつなぎ、利用者をLDAPで管理している構成なら、Keycloakの機能と重なる部分が多く、移行先の候補に挙げやすいと言えます。一方、OpenAMの代理認証（標準の連携方式に対応しない古いアプリへのログインを肩代わりする機能）*4 に頼っているアプリがある場合は、移行先で同じつなぎ方ができるかを先に確かめます。構築の進め方はKeycloakでSSO認証基盤を外注構築で詳しく扱っています。
移行の進め方
認証基盤の移行は、社内のほぼすべてのシステムのログインに関わります。一度に全部を切り替えず、アプリを1つずつ移すと、問題が起きたときの影響を小さく抑えられます。
- ステップ1：いまのOpenAMにつないでいるアプリと、つなぎ方（SAML・OpenID Connect・代理認証など）を一覧にする
- ステップ2：利用者情報の置き場所、多要素認証やパスワードの決まりを確かめ、移行先を決める
- ステップ3：新しい認証基盤を立て、影響の小さいアプリから順に切り替えて動きを確かめる
- ステップ4：全部のアプリを移し終えたら、OpenAMを止めて、残った設定や鍵を片づける
つまずきやすいのはステップ1です。長く使ってきたOpenAMには、経緯が分からなくなった連携が残っていることがあります。切り替え後に「あのシステムに入れない」と気づかないよう、設定の一覧とアクセスの記録の両方から洗い出します。利用者情報をLDAPに置いている場合は、そのLDAPにつなぐのか、利用者情報ごと移すのかもここで決めます。
外部に頼むときに確認しておきたい点
認証基盤の移行を外部に頼む場合、作業の量よりも、切り替えの順番と止められない時間帯の扱いで結果に差が出ます。見積もりの前に次の点を確かめます。
- 調査の範囲：OpenAMにつないでいるアプリの洗い出しを、設定とアクセスの記録の両方から行うか
- 移行先の決め方：OpenAMの版上げとKeycloakなど別の製品への移行を、同じ基準で比べたうえで提案するか
- 切り替えの手順：アプリごとの切り替えの順番、元に戻すときの手順、利用者への案内を誰が作るか
- 検証の方法：多要素認証やパスワードの決まりが移行前と同じように働くことを、どう確かめるか
- 運用後の見直し：新しい版や脆弱性の修正が出たときに、誰がいつ適用するか
特に最後の点は欠かせません。移行先がKeycloakでもOpenAMの新しい版でも、版の更新が止まれば数年後に同じ悩みに戻ります。導入の時点で更新の担当と頻度を決め、運用の手順書に書いておきます。
まとめ：OpenAM移行で確かめたい3つの点
OpenAMの開発終了を受けて移行先を選ぶうえで、確かめておきたい点は3つに整理できます。第一に、自社のOpenAMがどこから入手した何番の版で、修正がまだ出ているかを確かめること。第二に、つないでいるアプリとつなぎ方を洗い出し、版上げと別の製品への移行を同じ基準で比べること。第三に、移行先でも修正の適用を誰が受け持つかを決めておくことです。この3点を踏まえておけば、「移行したのに数年後にまた同じ問題で悩む」という事態を避けやすくなります。移行先や切り替え方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
OpenAMを使い続けること自体に問題はありますか
修正が出ている版を、サポートの続いているOSの上で動かしているなら、すぐに使えなくなるわけではありません。*2 ただし、修正が出ない版を動かしている場合は、見つかった脆弱性がそのまま残ります。まずは版とOSの組み合わせを確かめるところから始めます。
移行にはどのくらいの期間がかかりますか
期間は、つないでいるアプリの数とつなぎ方の種類で大きく変わります。アプリを1つずつ切り替える場合は、新旧の認証基盤を並べて動かす期間も見込みます。先にアプリの一覧を作っておくと見積もりが早く進みます。
移行のとき利用者に何か作業をしてもらう必要はありますか
移行の方式によっては、ログイン画面が変わったり、多要素認証の登録をやり直してもらったりする場面が出てきます。どのアプリがいつ変わるかを前もって案内しておくと、問い合わせの集中を避けやすくなります。
OpenAMからの移行のご相談
OpenAMで組んだ認証基盤の棚卸しから、移行先の選定、Keycloakなどへの切り替えと運用まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：Ping Identity「PingAM Documentation：History」（https://docs.pingidentity.com/pingam/8/deployment-planning/openam-history.html）。出典：OpenSSOからOpenAM、Access Management、PingAMへの経緯と、各年の版（2016年のOpenAM 13.0.0・13.5.0など）の記述を参照（2026年10月確認）
- *2 参考：オープンソース・ソリューション・テクノロジ株式会社（OSSTech）「OpenAM のセキュリティ脆弱性について [am2026-3-2]」（https://www.osstech.co.jp/support/am2026-3-2/）。出典：2026年7月29日のサポートニュース。OpenAM 14向けの修正の提供と、OpenAM 9・11・13およびサポート終了OS上のOpenAM 14に修正を提供しない旨の記述を参照（2026年10月確認）
- *3 参考：OSSTech「OpenJDK 11 のサポート終了に伴う OpenAM 14 のアップデートについて [am2024-3-1]」（https://www.osstech.co.jp/support/am2024-3-1/）。出典：OpenJDK 11のサポート終了予定（2024年10月）とOpenJDK 21で動作するOpenAM 14の提供の記述を参照（2026年10月確認）
- *4 参考：OSSTech「OSSTech OpenAM」製品紹介（https://www.osstech.co.jp/product/openam/）。出典：代理認証、OpenLDAPとの親和性などの機能説明を参照（2026年10月確認）
- *5 参考：OpenIdentityPlatform/OpenAM（GitHub）（https://github.com/OpenIdentityPlatform/OpenAM）。出典：リポジトリの説明とライセンス（CDDL）を参照（2026年10月確認）
- *6 参考：Keycloak 公式サイト（https://www.keycloak.org/）。出典：シングルサインオン、OpenID Connect・OAuth 2.0・SAML 2.0への対応、LDAP・Active Directoryとの接続、外部の認証基盤との連携の記述を参照（2026年10月確認）
- *7 参考：keycloak/keycloak（GitHub）（https://github.com/keycloak/keycloak）。出典：ライセンス（Apache-2.0）を参照（2026年10月確認）
- *8 参考：Cloud Native Computing Foundation（CNCF）「Keycloak」（https://www.cncf.io/projects/keycloak/）。出典：2023年4月10日にIncubatingの段階で受け入れられた旨の記述を参照（2026年10月確認）
