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

Keycloakのシステム開発は、要件整理から始めて方式選定を行い、設計・開発に進みます。その後は、テスト、段階稼働、運用定着の順に進めます。この順に進めることで、機能と運用の抜け漏れを抑えやすくなります。

全体像、開発の進め方、費用相場と見積もりの取り方を、順に見ていきます。全体像はKeycloakのシステム開発の完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Keycloakのシステムの全体像

Keycloakは、Web・スマートフォンアプリ、API、社内システムに認証と認可を提供するOSSのIAM・IdPです。

アプリはKeycloakのクライアントとして登録し、認証後に発行されたトークンをアプリ側で検証します。この仕組みにより、ログイン画面やパスワードリセットを各アプリで個別に作る負担を抑えられ、SSOと権限をまとめて管理できます。また、利用者がアプリへ直接パスワードを入力しない構成が基本です。

認証・認可・ユーザー管理の基盤への集約

認証はログインの正しさを確かめ、認可は認証済みの利用者にできることを定めます。そのうえで、連携先に合う方式とユーザー情報源を選んでおきます。

• OIDC・OAuth 2.0：Web・スマートフォンアプリやAPI向けの方式。
• SAML：既存の業務SaaSや企業間連携で採用されている場合に検討する方式。
• LDAP・Active Directory：ユーザー情報の供給元として連携できます。
• 管理対象：ユーザー、グループ、ロール、クライアント、レルム、認証フロー。

ユーザー情報の属性名、退職者の無効化、部署変更の反映時期まで設計しておかないと、古い権限が残るおそれがあります。

業務アプリの権限や個人情報の扱いは、発注側と開発側で決める部分です。Keycloakが自動で正しくするわけではないため、業務上の役割をロールとして定め、各アプリが信頼するクレームも両者で決めておきます。

Keycloak本体と周辺システムの範囲

本番環境の設計では、登録ユーザー数だけでなく、利用負荷と復旧目標も見たうえで、周辺基盤と合わせて考えます。

• 実行基盤：ロードバランサー、リバースプロキシ、複数台サーバー。
• 運用基盤：外部RDB、バックアップ、監視、秘密情報管理、ログ基盤。
• 負荷・復旧条件：同時ログイン数、トークン頻度、集中時間帯、検証要求数、復旧目標。
• 対応構成：OpenJDK 17・21・25、PostgreSQL 14〜18、OpenShiftなど。

OpenShiftは対応範囲に入りますが、EKSやAKSなど他のKubernetesは、環境固有の問題がベストエフォート扱いになります（出典：Keycloak公式「Supported Configurations」、2026年確認）。

採用するクラウドやKubernetesが、必要なサポート範囲に入るかを、契約前に確認してください。

Keycloakのシステム開発の進め方

6段階は、要件整理、選定、設計開発、テスト、稼働、定着の順です。まず、代表的なWebアプリとAPIを使ったPoCで難所を見つけ、そのうえで対象を段階的に広げます。

フェーズ1：要件整理（対象範囲と責任分界）

要件整理では、対象範囲と運用条件を一覧にして、どこまでを発注側と開発側のどちらが受け持つかを決めます。

• 対象一覧：利用者、アプリ、ログイン方式、情報源、権限表、外部IdP、SaaS、API、ピーク認証数。
• 接続条件：OIDC移行可否、SAML要否、ログアウト連動範囲、トークン有効期限を何分にするか。
• 運用条件：停止時の業務影響、復旧時間、ログ保存期間、MFA・パスキー範囲、管理者人数、サポート時間。

個人情報保護委員会のガイドラインは、個人データを扱う従業者が正当なアクセス権を持つ者かどうかを、識別結果に基づいて認証することを示しています。また、外部からの不正アクセスを防ぐ仕組みを適切に運用することも示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

法令対応の要件には、業務権限、ログ分析、インシデント対応も含めます。Keycloakを導入しただけでは、これらは満たされないためです。

フェーズ2：製品と運用方式の比較・選定

運用場所とサポートの担い手を比べ、接続先の仕様と移行コストに合う方式を選びます。

• コミュニティ版：自社クラウドやオンプレミスで運用。
• Red Hat build of Keycloak：OpenShift・RHELと商用サポートを組み合わせる。
• SI会社への委託：構築・保守を外部に委ねる。
• IDaaS併用：IDaaSとKeycloakで役割を分担する。

OSSのライセンス費用が小さくても、総額は、脆弱性対応や夜間障害、アップグレード、クラウド費用を誰が担うかで変わります。

新規のWeb・モバイルアプリやAPIでは、OIDCを優先します。一方で、既存SaaSや企業間接続がSAML前提なら、SAMLを残します。その判断は、接続先の仕様と移行コストで行います。

発注先には、Keycloakのメジャー・マイナーバージョンやDB・LDAP連携の実績を確かめてもらいます。加えて、カスタムSPI・テーマの更新方針とCVEへの初動時間も確認します。

フェーズ3：認証・認可・インフラの設計と開発

基本設計では、レルムとテナントの分け方とクライアントの命名規則を決めます。ロール、グループ、スコープの決め方も、この段階で定めます。

トークンのクレームやセッションの有効期限、リダイレクトURIを決めます。さらに、メール送信やテーマ、管理者権限の扱いも、この段階で定めます。

• テナント分離：BtoBではレルム方式と組織・グループ・アプリ側テナントID方式を比較。
• インフラ：Keycloak、外部RDB、ロードバランサー、WAF、秘密情報、監視、バックアップ、ログ基盤。
• 高可用性：複数インスタンス・AZ、DB冗長化、ヘルスチェック、切り戻し、障害時の管理者アクセス。
• アプリ検証：標準OIDC・SAMLライブラリで署名、nonce、PKCE、state、audienceを検証。

フェーズ4：機能・連携・セキュリティのテスト

テストでは、管理画面の動作だけでなく、機能・連携・セキュリティとユーザー移行まで検証します。

• 正常系：初回ログイン、SSO・ログアウト、パスワード変更、MFA、パスキー、セッション更新、アプリ間遷移。
• 異常系：期限切れ・署名不一致・audience誤り、未登録URI、無効ユーザー、権限外API、LDAP停止、メール失敗。
• セキュリティ：権限昇格、CORS、CSRF、ブルートフォース、リプレイ、管理者保護、個人情報ログ、秘密鍵保管。
• ユーザー移行：重複、メールの大文字小文字、ハッシュ、退職者・休眠者、初回再設定。

移行は、実データに近い件数で検証します。テストケースと合否基準を先に合意しておくと、直前の追加費用を抑えやすくなります。

フェーズ5：段階稼働と切り戻しの確認

本番移行は段階的に進めます。その際、認証の状況とユーザー移行の進み具合を、あわせて管理します。

• 段階稼働：重要度の低いアプリや一部利用者から始め、想定との差を見て中核へ拡大。
• 監視：成功率、認証遅延、トークン数、エラー、セッション、CPU・メモリ、DB接続数。
• 切り戻し：全社一斉でも旧ログインへ戻す条件と手順を事前にリハーサル。
• 移行方式：パスワード移行が難しければ初回更新を求めるか、旧IdPを一時的にIdentity Brokering。
• 二重登録防止：一意キー、メール変更、問い合わせ窓口、失敗時の再実行方法。

フェーズ6：運用と利用定着の仕組みづくり

Keycloakを稼働させた後も、運用が定着するよう体制を整えておく必要があります。

• 役割分担：Keycloak管理者、アプリ担当、情シス、セキュリティ担当、ヘルプデスク。
• 運用手順：ユーザー登録・削除、権限変更、管理者追加、秘密鍵のローテーション、バックアップ復元。
• 保守・障害対応：脆弱性情報の確認、パッチ適用、障害連絡。
• 権限更新：退職者の無効化や異動時の更新は、LDAP・人事システムとの連動か手動承認かでリスクが変化。

2026年のKeycloak 26.xでは、パスキー、FAPI 2.0、DPoPがリリースノートに掲載されています。OpenTelemetryの強化やSCIM APIのプレビューも記載されています（出典：Keycloak公式「Release Notes」、2026年確認）。

新機能は、supportedかpreviewかを確かめます。プレビュー機能を使う場合は、代替手段と撤退条件を用意しておきます。

月次レビューでは、ログイン成功率、問い合わせ、脆弱性対応を点検します。加えて、未使用のクライアントと過剰な権限も見直します。

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

Keycloakには一律のライセンス価格表がありません。そのため、要件定義、アプリ改修、ユーザー移行、テストの費用と、クラウド、RDB、監視、保守の費用を合算して考えます。

コミュニティ版でも、認証基盤を止めないための人件費と運用費は残ります。次に示すのは、2025〜2026年の国内受託開発相場と一般的な構成要素による概算で、個別案件の確定価格ではありません。

規模別の初期費用の幅（100万円台〜5,000万円超）

次の金額は、設計からテストまでを含む開発費の目安で、Keycloak本体の価格ではありません。

• PoC：1〜2アプリのOIDC接続と基本ロール。100万〜300万円、1〜2か月程度。
• 社内SSO：3〜10アプリ、LDAP・AD、MFA、監査ログ、バックアップ。300万〜800万円、2〜4か月程度。
• BtoB顧客基盤：多テナント、既存ユーザー移行、SAML・OIDC混在、API、HA。800万〜2,000万円、4〜8か月程度。
• 金融・公共など：初期費用2,000万〜5,000万円以上、期間6〜12か月以上となる可能性があります。

金融・公共などでは、複数AZやDR、厳格な監査を求めるケースがあります。FAPIや24時間運用、複数環境まで求められることもあります。

上記の金額は、NotebookLMリサーチノート「Keycloakのシステム」（2026年）に基づく概算です。ただし、アプリ数、連携方式、移行件数、SLAによっては、上限を超える場合もあります。

初期費用の内訳（要件・アプリ改修・移行・テスト）

見積書は作業範囲ごとに分けてもらい、費用の内訳を確認します。

• 要件・環境：要件整理、基本設計、環境構築。
• 認証設計：認証フロー、ロール設計。
• 連携：アプリごとのOIDC・SAML改修、LDAP・外部IdP接続。
• 移行・確認：ユーザー移行、テスト。
• 引き渡し：ドキュメント、教育。

アプリが10本ある場合は、Keycloakの設定そのものより、各アプリのログイン、ログアウト、権限判定、エラー処理、結合テストに工数がかかることがあります。

人月単価の一般的な参考値は、PMが90万〜150万円、SEが65万〜110万円、PGが50万〜90万円、テスターが45万〜80万円程度です（出典：NotebookLMリサーチノートおよび同ノートが参照した業務システム一般のQ&A、2026年）。

これは職種別の一般的な推定で、Keycloakの専門性や金融・公共の要件、24時間対応、既存アプリの品質によって変わります。単価は、各工程の人月や成果物と照らし合わせて確認してください。

月額費用の内訳（クラウド・監視・保守・脆弱性対応）

クラウドや保守を含む月額は、PoC、社内SSO、HA・24時間運用の構成によって異なります。

• 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の見積もりを取る際のチェックポイント

「認証基盤一式」という金額だけで比べると、作業の中身の違いを見落としやすくなります。そこで、対象アプリ、ユーザー移行、非機能要件、運用時間、納品物の条件を揃え、作業範囲と除外範囲を比べます。

初期構築費、アプリ改修費、クラウド実費は、分けて提示してもらいます。移行費とテスト費、月額保守は、別々の行として示してもらいます。

要件一覧と連携対象表の事前提示

RFPでは、利用条件と運用条件を具体的に書き、見積もりの前提を揃えます。

• 利用・接続：アプリ名、利用者区分、ユーザー数、ログイン方式、SSO・ログアウト、MFA・パスキー。
• 認証・データ：LDAP・AD・外部IdP、SAML接続先、API方式、権限、監査ログ、個人情報。
• 負荷：ピーク時同時ログイン数、1分あたりのログイン数、トークン更新数。
• 環境・運用：開発・ステージング・本番、クラウド制約、稼働率、RTO・RPO、バックアップ期間、リリース・サポート時間。

未確定の項目は、ベンダーの仮定と確認方法、確定後の増減条件を、見積書に残してもらいます。

自社案件に近い設計・運用力

ベンダーの力量は、技術力、類似案件、納品物、保守体制の4点を、自社の要件に照らして確かめます。

• 技術経験：Keycloakの連携・構築、認証方式、基盤・運用、自動化、ユーザー移行。
• 類似案件：構成、アプリ数、利用者規模、移行方式、障害対応体制。
• 納品物：設計書、設定・クライアント・ロール台帳、テスト仕様、運用手順、IaC・CI/CDソース。
• 保守：問い合わせ時間、一次切り分け、CVE評価、パッチ、更新、復元訓練。

具体的には、OIDCやSAMLの設計を確かめます。さらに、Java、コンテナ、Kubernetesの経験を見ます。PostgreSQLやWAF・監視の経験も確かめます。加えて、CI/CDとIaCの経験、LDAP・ADやユーザー移行の経験も対象に含めます。

大規模SSOの経験があっても、顧客向けの多テナントや既存パスワード移行の経験がなければ、今回の難所を解けるとは限りません。

手作業で行った設定は、担当者が交代すると再現できません。そのため、納品物を確認します。

価格以外のリスク（移行・停止・アップグレード）

見積もりが安い場合は、除外作業と追加負担を項目ごとに確認します。

• 見積もりの除外：アプリ改修別料金、移行は調査のみ、HAなし、ログ分析なし、脆弱性対応なしの可能性。
• 前提の崩れ：標準OIDC未対応なら、画面・セッション・権限エラー・API認証の改修が増加。
• 独自開発：カスタムSPI・テーマは更新時の互換性確認や属人化がコスト。
• 契約条件：変更単価、追加テスト、障害責任、データ・秘密鍵返却、終了時の引き継ぎ。

カスタムSPIや独自テーマを使う場合は、提案書に、標準設定で足りない理由と代替案、将来の更新方法を明記してもらいます。

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

導入時は、無料かどうかだけでなく、自社で運用する範囲と既存環境との適合性も確認しましょう。

Keycloakは無料で使えますか？

コミュニティ版はライセンス費用を抑えられますが、システム全体が無料になるわけではありません。クラウドやRDB、監視、バックアップの費用に加えて、セキュリティ、アプリ改修、テスト、保守の費用も発生します。

既存のRed Hat基盤を使う場合は、Red Hat build of Keycloakのサブスクリプションやサポート条件を確かめ、自社運用の人件費と比べます。

OIDCとSAMLはどちらを選ぶべきですか？

新規のWeb・モバイルアプリやAPI連携では、OIDCを優先するのが基本です。接続先のSaaSや既存の企業間連携がSAML前提なら、SAMLを採用します。

OIDCかSAMLかを決める際は、接続先の仕様、ライブラリ、ログアウト要件、既存ユーザー移行への影響を比べます。ベンダーには、方式ごとの対象アプリ、テスト、追加費用を分けて提示してもらいます。

既存ユーザーのパスワードは移行できますか？

移行できるかどうかは、既存のパスワードハッシュ方式やソルト、ストレッチングで決まります。加えて、ユーザーの一意キーと、Keycloakで利用できる移行方法も関係します。

方式を移せない場合は、ユーザー情報を先に同期して初回ログイン時に再設定を求めるか、旧IdPを一時的に経由する方法を検討します。

匿名化した実データ相当のサンプルを使い、重複アカウント、無効ユーザー、メール変更、移行失敗時の再実行を検証します。そのうえで、本番移行を計画します。

Keycloakは高可用性にできますか？

複数インスタンス、ロードバランサー、外部RDB、バックアップ、監視、障害時の切り替えを組み合わせれば、高可用性を考慮できます。

ログイン停止は、冗長化しても必ず防げるとは限りません。そのため、DB・ネットワーク障害、証明書期限切れ、外部LDAP停止、設定ミスを想定しておきます。

RTO・RPO、ヘルスチェック、切り戻し、復元訓練まで含めて設計してください。

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

Keycloakの開発では、アプリ連携、ユーザー移行、権限を一つの計画にまとめます。可用性、監査、アップグレードも、同じ計画の中で扱います。要件整理で対象を洗い出し、PoCでOIDC・SAML・LDAP・APIの難所を確認します。

その後は、設計・開発、テスト、段階稼働、運用定着の順に進みます。こうすると、想定外の追加費用や切り替えの失敗を抑えやすくなります。

発注前に最低限そろえる情報

まず、対象アプリ数、利用者数、ピーク時の認証数、OIDC・SAML・LDAPの接続先を一覧にします。そのうえで、ユーザー移行、MFA、ロール・テナントを確認します。加えて、目標稼働率、RTO・RPO、監査ログ、運用時間も押さえます。

見積依頼では、初期費用と月額費用を分けて示してもらいます。アプリ改修、移行、クラウドの費用も、項目ごとに分けてもらいます。さらに、保守、バージョンアップ、障害対応の範囲と、成果物や除外範囲も指定します。

小規模PoCから始める本番計画への接続

まずは対象アプリを1〜2本に絞り、ログインやログアウト、権限エラー、トークン更新を確かめます。さらに、ユーザー移行、監視、障害復旧も検証します。

結果から、標準機能で足りる範囲とカスタム開発が要る範囲を分け、全体費用、期間、運用体制を再見積もりします。設計と運用を自社に合わせることで、SSOの利便性と基盤の安全性を両立できます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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