Keycloakのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Keycloakのシステム開発は、Keycloakを置いてログイン画面を表示するだけではなく、対象アプリの認証方式、ユーザー情報、権限、可用性、運用責任までを一つの認証基盤として設計することが成功の近道です。特に既存アプリが複数ある場合は、アプリ改修とユーザー移行の難易度が総工数を左右します。

本記事では、Keycloakのシステムを要件整理、製品・構成選定、設計開発、テスト、稼働、定着の6フェーズで進める方法を解説します。OIDCとSAMLの判断基準、PoCの範囲、HAや監査ログの考え方、2026年時点の費用相場、見積書で確認すべき項目まで、発注前のチェックリストとして使える形に整理しています。

▼全体ガイドの記事
・Keycloakのシステム開発の完全ガイド

Keycloakのシステムの全体像

Keycloakは、Webアプリ、スマートフォンアプリ、API、社内業務システムに対して、認証と認可をまとめて提供するOSSのIAM・IdPです。利用者がアプリへ直接パスワードを入力するのではなく、アプリをKeycloakのクライアントとして登録し、認証後に発行されたトークンをアプリが検証する構成が基本になります。これにより、ログイン画面やパスワードリセットを各アプリで個別に作る負担を抑え、SSOと権限の一元管理を実現しやすくなります。

Keycloakが担当する範囲は、ログインの正しさを確認する認証と、認証済みの利用者が何をできるかを決める認可です。OpenID Connect（OIDC）やOAuth 2.0はWebアプリ・スマートフォンアプリ・APIの連携に向き、SAMLは既存の業務SaaSや企業間連携で採用されている場合に検討します。LDAPやActive Directoryをユーザーの情報源として連携することもできますが、属性名、退職者の無効化、部署変更の反映タイミングまで設計しなければ、ログインできても権限が古いまま残るリスクがあります。

ユーザー、グループ、ロール、クライアント、レルム、認証フローを管理できるため、多数のアプリを一元化する土台になります。一方で、Keycloakは業務アプリの権限設計や個人情報の取り扱いを自動で正しくしてくれる製品ではありません。業務上の役割をロールへ落とし込み、どのアプリがどのクレームを信頼するかを決める作業は、発注側と開発側が共同で担います。

本番のKeycloakは、ロードバランサーやリバースプロキシの背後に複数台のサーバーを配置し、PostgreSQLなどの外部RDB、バックアップ、監視、秘密情報管理、ログ基盤と組み合わせることが一般的です。利用者が増えたときに見るべき数字は、登録ユーザー数だけではありません。ピーク時の同時ログイン数、トークン発行頻度、ログイン集中の時間帯、アプリからの検証リクエスト数、障害時の復旧目標を確認して構成を決めます。

2026年時点のKeycloak公式の対応構成では、OpenJDK 17・21・25や、PostgreSQL 14〜18などが案内されています。また、OpenShiftは対応範囲として示される一方、EKSやAKSなどOpenShift以外のKubernetesは、環境固有の問題についてベストエフォート扱いです（出典: Keycloak公式「Supported Configurations」、2026年確認）。採用予定のクラウドやKubernetesが、必要なサポート範囲に入るかを契約前に確認してください。

Keycloakのシステム開発はどのように進めますか？

Keycloakのシステム開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進めると、機能と運用の抜け漏れを抑えられます。最初から全社の全アプリを切り替えるのではなく、代表的なWebアプリとAPIを使ったPoCで難所を見つけ、段階的に対象を広げる進め方が現実的です。

まず、利用者、対象アプリ、現在のログイン方式、ユーザー情報の保管場所、権限表、外部IdP、SaaS、API、ピーク時の認証数を棚卸しします。アプリごとに「OIDCへ移行できるか」「SAMLが必要か」「ログアウトをどこまで連動させるか」「トークンの有効期限を何分にするか」を確認し、一覧表にしてください。

同時に、認証基盤が停止した場合の業務影響、目標復旧時間、監査ログの保存期間、MFAやパスキーの適用範囲、管理者権限の人数、サポート時間を決めます。個人情報保護委員会のガイドラインは、個人データを扱う従業者が正当なアクセス権を持つ者であることを識別結果に基づいて認証することや、外部からの不正アクセスを防止する仕組みを適切に運用することを示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。Keycloakの導入だけを法令対応と見なさず、業務権限・ログ分析・インシデント対応まで要件に含めます。

選定では、Keycloakを自社クラウドやオンプレミスで運用するコミュニティ版、既存のOpenShiftやRHELと商用サポートを組み合わせるRed Hat build of Keycloak、Keycloakに詳しいSI会社へ構築・保守を委託する方式、IDaaSとKeycloakを役割分担するハイブリッド方式を比較します。OSSのライセンス費用が小さくても、脆弱性対応、夜間障害、アップグレード、クラウド費用を誰が担うかで総額は変わります。

OIDCとSAMLの選択は、最新かどうかだけで決めません。新規のWebアプリやモバイル、APIはOIDCを優先し、既存SaaSや企業間接続がSAML前提ならSAMLを残すなど、接続先の仕様と移行コストで判断します。発注先には、対応するKeycloakのメジャー・マイナーバージョン、既存DBやLDAPの連携実績、カスタムSPIやテーマのアップグレード方針、CVEへの初動時間を確認してください。

基本設計では、レルムとテナントの分け方、クライアントの命名規則、ロール・グループ・スコープ、トークンに含めるクレーム、セッションの有効期限、リダイレクトURI、メール送信、テーマ、管理者権限を決めます。BtoBで企業単位のデータ分離が必要な場合は、レルムを分けるのか、組織・グループ・アプリ側のテナントIDで分けるのかを、運用とデータ分離の両面から比較します。

インフラは、Keycloak、外部RDB、ロードバランサー、WAF、秘密情報管理、監視、バックアップ、ログ基盤を含めて設計します。高可用性が必要なら、複数インスタンス、複数AZ、データベースの冗長化、ヘルスチェック、切り戻し方法、障害時の管理者アクセスを決めます。アプリ側は独自の認証処理を増やさず、標準のOIDC・SAMLライブラリで署名検証、nonce、PKCE、state、トークンのaudience検証を実装することが重要です。

テストは、Keycloakの管理画面が動くことだけで完了にしません。正常系では初回ログイン、SSO、ログアウト、パスワード変更、MFA、パスキー、セッション更新、複数アプリ間の遷移を確認します。異常系では期限切れトークン、署名不一致、誤ったaudience、登録外のリダイレクトURI、無効ユーザー、権限のないAPI呼び出し、LDAP停止、メール送信失敗を再現します。

セキュリティテストでは、権限昇格、CORS、CSRF、ブルートフォース、リプレイ、管理者アカウントの保護、ログへの個人情報出力、秘密鍵の保管場所を確認します。移行を伴う場合は、アカウント重複、メールアドレスの大文字小文字、既存パスワードのハッシュ方式、退職者や休眠ユーザー、初回ログイン時のパスワード再設定を実データに近い件数で検証します。テストケースと合否基準を先に合意すると、リリース直前の追加費用を抑えられます。

本番稼働は、重要度の低いアプリや社内の一部利用者から始める段階リリースが安全です。最初の対象でログイン成功率、認証遅延、トークン発行数、エラーコード、セッション数、CPU・メモリ、DB接続数を監視し、想定との差を確認してから中核アプリへ広げます。全社一斉切り替えを選ぶ場合でも、旧ログインへ戻す条件と戻す手順を事前にリハーサルしてください。

ユーザー移行は、全員を一度にコピーする方式だけが答えではありません。既存パスワードの安全な移行が難しい場合は、ユーザー情報を先に同期して初回ログインでパスワード更新を求める方式、または旧IdPを一時的にIdentity Brokeringする方式も選択肢です。移行期間中の二重登録を防ぐため、ユーザーの一意キー、メール変更の扱い、問い合わせ窓口、失敗時の再実行方法を決めます。

稼働後は、Keycloakの管理者だけでなく、アプリ担当、情シス、セキュリティ担当、ヘルプデスクの役割を明確にします。ユーザー登録・削除、権限変更、管理者追加、秘密鍵のローテーション、バックアップ復元、脆弱性情報の確認、パッチ適用、障害連絡の手順を運用手順書に落とし込みます。特に退職者の無効化や異動時の権限更新は、LDAPや人事システムと連動するのか、手動承認にするのかでリスクが変わります。

2026年のKeycloak 26.xでは、パスキー、FAPI 2.0、DPoP、OpenTelemetryの強化、SCIM APIのプレビューなどがリリースノートに掲載されています（出典: Keycloak公式「Release Notes」、2026年確認）。新機能をすぐ本番採用するのではなく、supportedかpreviewかを確認し、プレビュー機能を採用する場合は代替手段と撤退条件を決めます。月次の運用レビューで、ログイン成功率、問い合わせ件数、脆弱性対応状況、未使用クライアント、過剰な権限を点検すると、認証基盤が形骸化しにくくなります。

Keycloakの費用相場とコストの内訳

Keycloakには公開された一律のライセンス価格表がなく、費用は「Keycloak本体」ではなく、要件定義、アプリ改修、ユーザー移行、クラウド、RDB、監視、テスト、保守を合算して考えます。コミュニティ版でソフトウェア費用を抑えられても、認証基盤を止めないための人件費と運用費は残ります。以下は2025〜2026年の国内受託開発相場と、Keycloakの一般的な構成要素から置いた概算レンジであり、個別案件の確定価格ではありません。

PoCや検証環境で、1〜2アプリのOIDC接続と基本ロールを確認する場合は、初期費用100万〜300万円、期間1〜2か月程度が一つの目安です。3〜10アプリの社内SSOでLDAP・AD連携、MFA、監査ログ、バックアップまで含める場合は、300万〜800万円、2〜4か月程度が目安になります。これはKeycloak本体の値ではなく、設計、構築、アプリ連携、テストを含む概算です。

BtoBの顧客向け基盤で、多テナント、既存ユーザー移行、SAMLとOIDCの混在、API連携、HA構成を含めると、初期費用800万〜2,000万円、期間4〜8か月程度が目安です。金融・公共などで複数AZ、DR、厳格な監査、FAPI、24時間運用、複数環境まで求める場合は、2,000万〜5,000万円以上、6〜12か月以上となる可能性があります（出典: NotebookLMリサーチノート「Keycloakのシステム」、2026年）。アプリ数、連携方式、移行件数、SLAでレンジの上限を超えることもあります。

見積書では、要件整理・基本設計、Keycloak環境構築、認証フローやロール設計、アプリごとのOIDC・SAML改修、LDAPや外部IdP連携、ユーザー移行、テスト、ドキュメント、教育を分けて記載してもらいます。特にアプリが10本ある場合、Keycloakの設定よりも各アプリのログイン、ログアウト、権限判定、エラー処理、結合テストの工数が大きくなることがあります。

人月単価を使う場合は、PMが90万〜150万円、SEが65万〜110万円、PGが50万〜90万円、テスターが45万〜80万円程度という業務システム一般のレンジを参考にします。ただし、これは職種別の一般的な推定であり、Keycloak専門性、金融・公共の要件、24時間対応、既存アプリの品質で変わります（出典: NotebookLMリサーチノートおよび同ノートが参照した業務システム一般のQ&A、2026年）。単価だけでなく、各工程の人月と成果物を照合してください。

月額の目安は、PoCで数万円〜10万円、小規模社内SSOで5万〜20万円、BtoBやHA構成で20万〜80万円、大規模・24時間運用で50万〜200万円以上です。ここにはクラウドのコンピュート、RDB、ロードバランサー、WAF、ログ、バックアップ、監視、保守の一部を含めた想定がありますが、契約範囲によって大きく変わります。保守費用を初期開発費の年15〜25％程度で置く場合もありますが、これは概算の目安として扱います。

AWSを使う場合、RDS for PostgreSQLはインスタンス時間だけでなく、ストレージ、I/O、バックアップ、データ転送などで課金されます。Multi-AZでは別AZにスタンバイを配置し、同期レプリケーションによって書き込みI/Oが増えるとAWS公式が説明しています（出典: Amazon Web Services「Amazon RDS for PostgreSQL pricing」、2026年確認）。そのため、月額見積は「AWS一式」とまとめず、Single-AZ・Multi-AZ、ログ保存期間、バックアップ保持期間、想定I/Oを分けて再計算してください。

Keycloakの見積もりを取る際のチェックポイント

Keycloakの見積もりは、単に「認証基盤一式」と書かれた金額を比べると判断を誤ります。対象アプリ、ユーザー移行、非機能要件、運用時間、納品物を同じ条件で提示し、作業範囲と除外範囲を揃えてから比較することが大切です。少なくとも、初期構築費、アプリ改修費、クラウド実費、移行費、テスト費、月額保守を分けてください。

RFPには、アプリ名、利用者区分、ユーザー数、ピーク時同時ログイン数、ログイン方式、必要なSSO、ログアウト要件、MFA・パスキー、LDAP・AD・外部IdP、SAMLが必要な接続先、APIの認証方式、権限モデル、監査ログ、個人情報の種類を記載します。ユーザー数だけでなく、1分あたりのログイン数やトークン更新数を示すと、サイジングの前提が揃います。

さらに、開発・ステージング・本番の環境数、クラウドやオンプレミスの制約、目標稼働率、RTO・RPO、バックアップ期間、リリース可能時間、サポート時間を明記します。未確定の項目がある場合は、ベンダーに勝手な前提を置かせず、「仮定」「確認方法」「確定後の増減条件」として見積書に残してもらいます。

ベンダーには、Keycloakの構築経験だけでなく、OIDC・SAML設計、Java・コンテナ・Kubernetes、PostgreSQL、WAF、監視、CI/CD、IaC、LDAP・AD、ユーザー移行の実績を確認します。大規模SSOの経験があっても、顧客向け多テナントや既存パスワード移行の経験がなければ、今回の難所を解けるとは限りません。提案段階で、今回と似たアーキテクチャ、対象アプリ数、利用者規模、移行方式、障害対応の体制を聞いてください。

比較時は、設計書、設定一覧、クライアント・ロール台帳、テスト仕様書、運用手順書、IaCやCI/CDのソースコードを納品するかを確認します。管理画面で手作業設定するだけの納品では、担当者が変わったときに再現できません。月額保守に含まれる問い合わせ時間、障害の一次切り分け、CVEの評価、パッチ適用、バージョンアップ、バックアップ復元訓練を項目別に確認します。

見積もりが安い場合は、何が含まれていないかを確認します。たとえば、Keycloakの構築だけでアプリ改修が別料金、ユーザー移行は調査のみ、HAは構築しない、監査ログは保存するだけで分析しない、脆弱性対応は対象外という可能性があります。特に「既存アプリは標準OIDCに対応済み」という前提が崩れると、ログイン画面、セッション管理、権限エラー、API認証の改修が増えます。

カスタムSPIや独自テーマを多用すると、要望には合わせやすくなりますが、バージョンアップ時の互換性確認と担当者の属人化がコストになります。標準設定で足りない理由、代替案、将来のアップグレード方法を提案書に書いてもらいます。契約では、設計変更時の単価、追加テストの扱い、障害時の責任分界、データや秘密鍵の返却、契約終了時の引き継ぎも確認してください。

Keycloakのシステム開発でよくある質問（FAQ）

ここでは、Keycloakの導入を検討する企業から特に質問されやすい点を、判断の基準とともに回答します。無料かどうかだけでなく、どの範囲を自社で運用するか、既存環境と要件が合うかを確認することが重要です。

コミュニティ版はソフトウェアのライセンス費用を抑えて利用できますが、システム全体が無料になるわけではありません。クラウドやRDB、監視、バックアップ、セキュリティ対応、アプリ改修、テスト、保守の費用が発生します。既存のRed Hat基盤を使う場合はRed Hat build of Keycloakのサブスクリプションやサポート条件を確認し、自社運用の人件費と比較してください。

新規のWebアプリ、モバイルアプリ、API連携ではOIDCを優先し、接続先のSaaSや既存の企業間連携がSAML前提ならSAMLを採用するという判断が基本です。どちらか一方に全てを統一するより、接続先の標準仕様、ライブラリ、ログアウト要件、既存ユーザー移行の影響を比較します。ベンダーには方式ごとの対象アプリ、テスト項目、追加費用を分けて提示してもらってください。

移行できるかは、既存システムが保持するパスワードハッシュの方式、ソルト、ストレッチング、ユーザーの一意キー、Keycloak側で利用できる移行方法によって決まります。方式をそのまま移せない場合は、ユーザー情報だけ先に同期し、初回ログイン時にパスワードを再設定してもらう方法や、旧IdPを一時的に経由する方法を検討します。実際のデータを匿名化したサンプルで、重複アカウント、無効ユーザー、メール変更、移行失敗時の再実行を検証してから本番移行を計画してください。

複数インスタンス、ロードバランサー、外部RDB、バックアップ、監視、障害時の切り替えを組み合わせれば、高可用性を考慮した構成にできます。ただし、冗長化しただけでログインが必ず止まらないわけではありません。データベース障害、ネットワーク障害、証明書期限切れ、外部LDAP停止、設定変更の誤りを想定し、RTO・RPO、ヘルスチェック、切り戻し、復元訓練まで含めて設計します。

Keycloakのシステム開発のまとめ

Keycloakのシステム開発で重要なのは、OSSの導入そのものではなく、アプリ連携、ユーザー移行、権限設計、可用性、監査、アップグレードを一つの計画にまとめることです。要件整理で対象アプリと利用者を棚卸しし、PoCでOIDC・SAML・LDAP・APIの難所を確認してから、設計開発、テスト、段階稼働、運用定着へ進めると、想定外の追加費用と切り替え失敗を抑えやすくなります。

発注前には、対象アプリ数、利用者数、ピーク時の認証数、OIDC・SAML・LDAPの接続先、ユーザー移行の有無、必要なMFA、ロールとテナントの考え方、目標稼働率、RTO・RPO、監査ログ、運用時間を整理します。見積依頼では、初期費用と月額費用、アプリ改修、移行、クラウド、保守、バージョンアップ、障害対応を分け、成果物と除外範囲も指定してください。

対象アプリを1〜2本に絞ったPoCでは、ログイン、ログアウト、権限エラー、トークン更新、ユーザー移行、監視、障害時の復旧を実際に確認します。PoCの結果から、標準機能で進める範囲とカスタム開発が必要な範囲を分け、全体の費用・期間・運用体制を再見積もりしてください。Keycloakのシステムは、設計と運用を含めて自社に合う形へ落とし込むことで、SSOの利便性と認証基盤の安全性を両立しやすくなります。

▼全体ガイドの記事
・Keycloakのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。