開発ノート：OAuth2.0/OpenID Connectを活用した社内SSO導入の舞台裏

SSO導入プロジェクトの背景と目的

当社では複数の業務システムが個別の認証を持ち、運用コストが増大していました。社内SEチームはユーザーから「パスワード忘れ」で年間約2,000件の問い合わせを受けていました。それに伴うサポート費用が相場の1.5倍ほど膨らみ、「費用対効果」の低さが課題でした。CTOの山口氏はログイン統合による運用効率化を提案し、システム刷新を決断しました。マイルストーンはPoCで可用性検証、本番環境移行、運用フェーズの三段階に設定。初期「予算」はPoC含め1,200万円、本番移行で追加1,800万円の計3,000万円を想定。連携対象はERP、勤怠管理、購買システム、人事ポータルなど5つのレガシーアプリです。発注フェーズでは要件定義書に「OAuth2.0」「OpenID Connect」「多要素認証」を明記。運用部門と経営層を巻き込み、KPIとして「ログイン障害件数」「サポート問い合わせ削減率」を設定。これにより社内全体で「発注」タイミングから共通認識が得られました。システム統合の先行事例を調査し、成功・失敗要因を洗い出すことでリスクを可視化。要件定義では「シングルサインオン」と「ユーザープロビジョニング」の要素を二軸で整理。最終的に、OAuth2.0ベースの認可サーバーとOpenID Connect対応のIDプロバイダー採用を決定。システム開発会社には「認証・認可分野の実績」を「選び方」ポイントとして提示しました。PoCでは100アカウントを対象に認証フローを検証し、ユーザー認証成功率99.9％を達成。認証ログの監査機能は運用コストを下げる仕組みとして高く評価されました。この背景には、統合認証でパスワードリセット工数削減を実現したいという狙いがあります。これにより、ユーザー利便性の向上とサポート部門の負荷軽減が同時達成できる見込みです。プロジェクトキックオフから要件確定までに要した期間は約1カ月でした。次章では、開発会社選定の具体的なプロセスを解説します。

開発会社選定とベンダー比較ポイント

開発会社を選ぶ際は、まず認証技術の専門性を重視しました。候補としてA社、B社、C社の三社をピックアップ。

• A社は大手SIerで予算規模の大きな案件実績が豊富です。
• B社はIdentity as a Service（IDaaS）携実績が多く、小規模PoCにも柔軟対応可能。
• C社はOSSの認証フレームワークに強みがあり、コストパフォーマンスに優れています。

各社の見積書では、要件定義～設計費用を約¥800万～¥1,200万と提示。本開発フェーズの工数は1,500時間程度が相場で、単価は¥10,000前後。

• B社はPoCを低価格で請け負い、採用候補として次点評価となりました。
• C社はOSSカスタマイズを前提にした提案で、総費用を¥2,500万程度に抑えられる見込み。
• A社は実績が豊富な反面、初期「費用」が¥3,200万とやや高価でした。

「選び方」の最終基準は、PoC中のコミュニケーション品質と技術共有体制でした。

B社とC社の両社にPoCを発注し、最終的にC社を採用。C社はOSSベースの認証サーバー構築が得意で、IDフェデレーション機能も豊富でした。予算調整では、PoC成果を基に本番開発予算を¥1,800万に設定。発注契約ではマイルストーンに応じた検収と支払い条件を厳密に定義しました。これにより開発中の追加「費用」請求リスクを抑制できました。

次はアーキテクチャ設計の概要を説明します。

アーキテクチャ設計：OAuth2.0とOpenID Connectの構成

認可サーバーにはKeycloakの商用サポート版を採用しました。KeycloakはOAuth2.0とOIDCに完全準拠し、ユーザープロビジョニング機能も備えています。フロントエンドアプリはIDトークン取得後、アクセストークンをGraphQL APIへ送信します。バックエンドはアクセストークンを検証し、RBACで権限を付与します。トークンはJWT形式で、公開鍵による検証を行い安全性を担保。トークン有効期限は短めの15分とし、リフレッシュトークンで更新します。リフレッシュトークンはHTTPSのSecure Cookieに格納し、XSS攻撃を防止。レガシーシステムにはサイドカー方式でプロキシ認証を実装しました。この方式により既存アプリ改修を最小限に抑えられました。IDフェデレーションはSAML v2.0にも対応し、パートナー企業との連携を視野に入れています。システム間でのユーザー属性連携はSCIM 2.0を用いて自動同期を実現。アーキテクチャ設計にはAPI Gatewayを挟み、認可処理を一元化しました。API Gatewayはコスト相場感からAWS API Gatewayを選定。AWS WAFと連携し、不正リクエストをブロックする設計を組み込みました。トークン検証や認可処理は「発注」前にPoCでスループットを測定済みです。設計段階で認証ログの出力要件を定義し、監査要件に備えました。この構成でシステム全体の認証性能が約200ms以内に収束しました。次章では統合フェーズの技術課題と対応策を解説します。

レガシーシステム統合の技術的課題と対応策

統合対象の一部システムはOAuth非対応で、認証手段がCookieベースでした。これらにはKeycloakのIdentity Broker機能を利用し、CookieをOIDCトークンにマッピング。ブラウザのSameSite設定やSecure属性により、セッション維持の安定性を確保しました。別ドメイン環境ではCORS設定が複雑になり、プリフライトリクエストの最適化を実施。プリフライトヘッダー数を最小化し、不要ヘッダーを排除することで遅延を50％削減。古いJavaベースシステムでは、トークン検証ライブラリの互換性課題が発生。専用のトークン検証プロキシを立て、REST API経由で検証を委譲する方式で解決。プロキシにはNode.js製ミドルウェアを採用し、費用を抑制しました。SCIM連携時には属性マッピングの微調整が多発し、追加工数を20時間ほど要しました。追加「費用」は¥200,000程度でしたが、事前の要件定義で見込んでいたため予算内。LDAPディレクトリとの同期は双方向で要件が曖昧になり、細かな擦り合わせが必要でした。仕様変更を防ぐため、仕様書に「バージョン」「日付」を明記し、見直しガバナンスを強化。最終的にスムーズな統合を実現し、シングルサインオン化が完了しました。

次はテスト・本番ロールアウトにおける教訓を共有します。

テスト戦略と品質保証

シングルサインオン（SSO）導入では、認証基盤の信頼性がシステム全体の可用性に直結するため、テスト戦略をきちんと組む必要があります。まずユニットテストでは、OAuth2.0フローの各ステップごとに検証を行い、Authorization Code取得、アクセストークン／IDトークン生成、リフレッシュトークン更新のロジックを網羅しました。次に統合テストでは、Keycloakマスタ環境をスタッブ化せずにステージング環境へデプロイし、実際のユーザー登録～認証～APIアクセスまでをエンドツーエンドでテスト。レガシーシステムとのサイドカープロキシ連携やSCIM同期の試験を並行実施し、テストカバレッジを90％以上に高めました。さらに負荷テストでは、Artilleryを使って5,000同時認証リクエストをシミュレーションし、ピーク時のレスポンス時間を200ms以下に抑えた点を確認。最後にセキュリティテストとして、OWASP ZAPでの脆弱性スキャンとJWT改ざん耐性テストを実施し、すべての重大度高リスク項目を修正することで、安心して本番環境へ移行できる品質レベルを担保しました。

本番環境へのローンチとリリース計画

本番リリースはフェーズ分けでリスクを低減しました。第1フェーズとして、社内管理者アカウント50名でのプライベートリリースを2週間実施し、ログイン失敗率やサポート問い合わせ件数をモニタリング。ここで得られた課題を反映し、TLS設定やCookie属性のチューニングを追加実装しました。第2フェーズでは全社向け一斉ロールアウトを週末に実施し、メンテナンスウィンドウ3時間を確保。DNS TTLを短く設定し、トラフィック分散を図りながら認証サーバーを切り替え、95％以上のユーザーがダウンタイムなしに移行完了を確認しました。リリース直後1週間はサポートチームをハイアラート体制にし、ログイン障害0件で安定稼働を達成。さらに、リリース後2週間は旧認証環境を並行稼働とし、万が一のロールバックパスを維持することで、予期せぬトラブルにも迅速対応できる体制を整えました。

運用・監視とサポート体制

本番稼働後は、運用・監視体制を24時間365日で整備しました。まず、認証サーバーの稼働状況をAWS CloudWatchで監視し、CPU使用率やメモリ、レスポンスタイムのアラート設定を行いました。KeycloakログはElasticsearch＋Kibanaにストリームし、異常なリクエスト増加や認証エラー率の上昇をダッシュボードでリアルタイムに可視化。サポートチームはSlack連携で通知を受け、初動対応目標1時間以内、完全解決8時間以内をSLAに明記。問い合わせ履歴はチケットシステムと連携し、よくある質問をナレッジベース化してFAQページに反映することで、サポート工数をリリース前比50％削減しました。さらに、月次レポートとして「サポート問い合わせ数」「再発解決率」「認証エラー値動向」をまとめ、経営層と共有。開発会社との保守契約では、アプリケーションバージョンアップ対応やKeycloakバージョンパッチ適用を月20時間分の保守費用内に含め、年間費用相場の80％程度に抑えられています。

ユーザートレーニングと社内浸透施策

SSO導入を定着させるには、ユーザー教育が不可欠です。導入前に管理者ユーザー向けハンズオン研修を1日実施し、Keycloak管理コンソールの操作やトークン設定方法をハンズオンで体験してもらいました。次に全社員向けオンラインマニュアルとショート動画を社内ポータルに公開し、ログイン方法とパスワードリセット手順を3分以内で理解できるコンテンツを用意。初月はヘルプデスクへの問い合わせが1日平均30件ありましたが、FAQ改善と動画ガイドの拡充により3ヶ月後には5件以下に激減しました。また、イントラネットに「SSO成功体験談」コーナーを設置し、ユーザーからのポジティブなコメントを共有して社内浸透を促進。これにより、導入後1ヶ月で95％のユーザーがSSOを問題なく利用できるようになり、旧システムへの往復ログインが事実上ゼロになりました。

ROI算出とコスト効果

初期開発費用3,000万円＋運用保守費用360万円/年に対し、得られたコスト効果を試算しました。まず問い合わせ削減効果では、年間2,000件のパスワードリセット問い合わせを解消し、オペレーション工数2,000件×30分×人件費¥3,000＝¥90,000,000相当を削減。また、認証サーバー統合により新規システム発注時の「発注」コストを約¥1,000,000低減。さらに、ユーザー生産性向上による業務効率化効果を年間¥10,000,000と見積もり、合計¥101,000,000の効果。ROIは（101−36）÷30×100＝217％、約0.46年（約5.5ヶ月）で投資回収可能と試算しました。このデータをダッシュボード化し、経営会議や更新契約の際にエビデンスとして活用しています。

今後の展望と追加発注計画

SSO基盤を安定化した次のフェーズとして、以下の拡張を計画中です。

• 多要素認証（MFA）強化

• ユーザー行動ログを活用した異常検知（UEBA）

• 3rdパーティ製IDプロバイダー連携（Azure AD、Google Workspaceなど）

• SCIMによる自動ユーザープロビジョニング強化

これらは追加PoCと要件精査を経て、予算¥1,200万円程度での発注を想定。開発会社選定では、既存ベンダーC社との継続契約と併せて、新たな専門技術を持つパートナーとの連携も検討しています。ぜひ