社内システムのSSO対応改修｜Entra ID・Google Workspaceでログインを一本化する3つの方式と確認項目【2026年10月】

Microsoft 365 や Google Workspace でシングルサインオン（以下SSO。会社のIDひとつで複数のシステムに入れる仕組み）を始めたものの、自社開発や他社に作ってもらった業務システムだけが別のID・パスワードのまま残っている会社があります。この記事は、そうした会社の情シス兼任者・管理部門長に向けて書いています。

ソースコードがあって自社で直せるWebシステムなら、システム側を会社のIDに対応させる改修が第一候補です。ログイン画面を付け替える作業そのものは大きくないこともあります。手間がかかるのは周辺の作業で、具体的には既存アカウントと会社のIDの対応付け、権限の渡し方、退職者の止め方、SSOが止まったときの入口、試験です。ソースを直せない場合は「前段に認証の仕組みを置く」「代行入力」の2方式が残りますが、どちらも退職者が入れる経路を別に塞ぐ作業が必要です。使っているのがSaaSだけなら開発は要らず、IdP（会社のIDを管理するサービス。Entra ID や Google Workspace）の標準連携で足ります。

AI革命株式会社の既存システムの改修は100万円〜（税別）です。ライセンス費などの外部利用料は別にかかります。

この改修が必要な場合、開発を頼まなくてよい場合

最初に、そもそも開発会社に頼む話なのかを分けます。発注の判断は、製品選びより先に「どのシステムを、誰が直せるか」から始まります。

SaaSだけの環境で外部に頼む場合は、設定作業の委託になります。ある事業者の公開記事では、SaaSのSSO初期設定を外部に頼む目安を「SaaS1つあたり3〜10万円」としています（BTNコンサルティング、2026-10-14確認。SaaSの設定作業の目安で、自社開発システムの改修費用ではありません）。IDaaS製品の例では、GMOトラスト・ログインの「SSOプロ」が1ユーザー月300円（税抜・12か月契約・30名以上。料金ページ、2026-10-14確認）です。開発を頼む前に、こうした選択肢で足りないかを確かめてください。

古いシステムを直すか作り直すかで迷っている場合は、システムの改修とリプレイスの比較で判断の材料を整理しています。

まず確かめる「システム側を直せるか」

方式を選ぶ前に、次の6点を確かめます。社内で答えが出ない項目は「不明」のままで構いません。不明な項目が多いほど、改修の前に調査が必要になります。

ソースが手元になく元の開発会社とも連絡が取れないときは、開発会社を変えてシステムを引き継ぐときの調査の頼み方を先に読むと、何を揃えればよいかが分かります。

3つの方式の違いと、合う状況・合わない状況

出典: OpenID Foundation 公式

既存の社内システムをSSOにつなぐ方式は、大きく3つです。Microsoft は、アプリが対応していれば OpenID Connect（OIDC）、OIDCを使わない既存アプリはできるだけ SAML、HTMLのログイン画面があるアプリはパスワードベース（代行入力）、ヘッダー認証のアプリはヘッダーベース、という順で選ぶよう案内しています（Microsoft Learn「SSO の展開を計画する」、2026-10-14確認）。OIDCとSAMLはどちらも「IdPがログインを確かめ、結果をシステムに渡す」ための決まりごとで、新しく作るならOIDC、既存の部品がSAMLに対応しているならSAML、という程度の違いと考えて構いません。

ライセンスの区分は Microsoft Learn「Microsoft Entra ライセンス」とユーザーとグループの割り当て、代行入力の拡張機能はパスワードベースSSOの構成で確認しました（いずれも2026-10-14確認）。

②前段方式の注意点：直接の通り道を塞ぐ

前段方式（Entra のアプリケーションプロキシとヘッダーベースSSO）は、システムを直さずに済むのが利点です。一方で Microsoft は、ヘッダーで利用者名を受け取るアプリへのアクセスを、許可された経路からの通信だけに制限するよう注意しています（ヘッダーベース SSO の構成、2026-10-14確認）。入口を通らずにシステムへ直接届く通り道が残っていると、利用者名を偽った通信で入られるおそれがあるためです。制限の方法として、同じページはシステムのサーバーのファイアウォールやIP制限を挙げています。

もう1つの注意は、アプリケーションプロキシが社外から社内のシステムを使うための仕組みだという点です。同じページで Microsoft は、システムと同じネットワーク内からの通信にはこの仕組みを推奨しておらず、社内での一般的な利用には別製品の Microsoft Entra Private Access を案内しています。社員のほとんどが社内LANから使うシステムなら、②より①の改修を先に検討します。

③代行入力の注意点：システム側のパスワードが残る

代行入力は、Entra ID が利用者の代わりにIDとパスワードを入力する仕組みです。資格情報は暗号化して保存されますが、システム側のアカウントとパスワードはそのまま残ります。会社のIDを止めても、パスワードを知っている退職者はシステムのログイン画面から直接入れます。代行入力を選ぶ場合、管理者がパスワードを設定して本人に知らせない運用と、定期的な変更が欠かせません。情報処理学会 第79回全国大会（2017年）の発表でも、代行入力の仕組みは内部に生のパスワードを持つ必要があるためリスクが高いと整理されています（田崎ほか「パスワードを保持しない代行入力システムによる SSO の実現」、2026-10-14確認）。

Google Workspace をIdPにする場合

Google Workspace では、管理コンソールの「カスタム SAML アプリ」で社内システムを登録するか（Google Workspace 管理者ヘルプ）、システム側で Google のOIDC（Googleアカウントでログイン）に対応させる（Google for Developers「OpenID Connect」）のが基本です（いずれも2026-10-14確認）。どちらも①の「システム側の改修」にあたります。カスタムSAMLアプリの設定は特権管理者が行い、設定の反映には最長24時間ほどかかると案内されています。カスタムSAMLアプリを使えるエディションは、確認した公式ページに記載がなかったため、契約中のエディションで管理コンソールに項目があるかを確かめてください。

なお、Google Workspace の「カスタム OIDC プロファイル」（2025年11月18日に一般提供。Google Workspace Updates、2026-10-14確認）は、外部のIdPで Google にログインするための機能で、社内システムを Google のIDでログインさせる用途とは向きが逆です。

前段方式・代行入力をこの記事で公式に確かめたのは Entra ID の機能です。Google Workspace だけの環境でこの2方式を考える場合は、使う予定のIDaaS製品の仕様で確認してください。

既存アカウントと会社のIDの対応付け

改修で時間がかかりやすいのが、システムにいる既存のアカウントを、IdP側の誰に結びつけるかの棚卸しです。

メールアドレスで結びつけたままにしない

「同じメールアドレスの人を同じ人とみなす」のは一見簡単ですが、OIDCの仕様では、利用者を一意に特定できると保証されるのは「発行元（iss）」と「利用者番号（sub）」の組だけで、メールアドレスや表示名を一意の識別子に使ってはならないとしています（OpenID Connect Core 1.0 5.7、2026-10-14確認）。Entra ID も、メールアドレスや preferred_username は変わることがあるため権限の判断やユーザーデータの保存に使わず、変わらない番号（oid）を使うよう案内しています（ID トークンの要求のリファレンス）。Google も、メールアドレスではなく sub を使うよう書いています（Google for Developers「OpenID Connect」）。

実務では、最初の対応付けの候補探しにはメールアドレスを使い、確認できたらIdP側の変わらない番号をシステムのユーザー表に保存する、という2段階にします。こうしておけば、結婚による改姓やドメイン変更でメールアドレスが変わっても、別人扱いになったり、他人のアカウントに入れたりしません。

対応付け表の記入例（説明用・架空データ）

以下は架空の会社の受注管理システムで棚卸しをした場合の例です。実在の人物・案件ではありません。

この表で「判定」が「一致」以外の行は、移行の前に人が決める必要がある項目です。こうした行が多いほど、改修の前の棚卸しに時間がかかります。

権限（ロール）をIdPで渡すか、システム側で持つか

SSOにすると「誰が入れるか」はIdPで決められます。残るのは「入った人が何をできるか」をどこで決めるかです。

公式で確かめた、設計に影響する制約は次のとおりです（すべて2026-10-14確認）。

• Entra ID でアプリにグループ単位で割り当てるには P1 または P2 が必要で、入れ子のグループ（グループの中のグループ）には割り当てが引き継がれません（ユーザーとグループの割り当て）。無料版では利用者を1人ずつ割り当てます
• Entra ID では、ひとりの利用者が所属するグループがSAMLで150、OIDC等のトークンで200を超えると、グループ情報がログイン結果に載らなくなり、別途取りに行く作りが必要になります（ID トークンの要求のリファレンス）
• Entra ID の「アプリロール」はアプリの登録に属するため、テナントに固有のグループよりもアプリと一緒に扱いやすく、セキュリティグループをアプリロールに割り当てることもできます（アプリロールを追加する）
• Google Workspace のカスタムSAMLアプリで渡せるグループは最大75です（Google Workspace 管理者ヘルプ）

退職・異動時の止め方と、SSOが止まったときの入口

出典: SCIM 公式サイト

「SSOにすれば退職者対策が終わる」わけではありません。どの操作で、どこまで止まるかを分けて確認します。

SCIMの同期間隔と無効化の伝え方は Microsoft Learn「SCIM エンドポイントを構築し、ユーザー プロビジョニングを構成する」で確認しました（2026-10-14確認）。SCIMを実装するかどうかは、利用者数と、退職者のアカウントがシステムに残ることをどこまで許せるかで決めます。システム側のログイン状態の有効期限を短くする、IdPで止めたことをシステムが次の操作時に確かめる、といった作りも選べます。OIDCでログアウトするときは、システム側のログイン状態も消す必要があると Microsoft は案内しています（Microsoft ID プラットフォームでの OIDC）。

SSOが止まったときの管理者用の入口

ローカルログインを全部閉じると、IdPの障害や設定ミスのときに、管理者もシステムに入れなくなります。Entra ID 自体については、Microsoft が緊急アクセス用アカウントを2つ以上用意し、条件付きアクセスのブロックから外し、少なくとも90日ごとに使えるかを確かめるよう推奨しています（緊急アクセス用アカウントを管理する、2026-10-14確認）。

社内システム側の入口について公式の推奨はないため、ここは設計の判断になります。考え方の例は次のとおりです。

• ローカルの管理者アカウントを1つだけ残し、それ以外のローカルログインは閉じる
• その入口は社内ネットワークや特定の端末からだけ使えるようにし、二要素の確認を付ける
• 使われたら関係者に通知が届くようにし、パスワードは封印して保管する
• 年に数回、実際に入れるかを確かめる日を決める

もう1つ見落としやすいのが、SAMLの署名証明書の期限です。Entra ID の既定では3年で、期限が切れるとログインできなくなるため、更新の手順と通知先を決めておくよう案内されています（SSO の展開を計画する）。

説明用の構成例：社員80名の受注管理システムを Entra ID につなぐ

出典: Microsoft Learn 公式

ここでは、作業の順番を示すために架空の例を置きます。当社の実績ではなく、期間や効果も示しません。

前提（架空）: 社員80名。Microsoft 365 Business Premium を契約済み（Entra ID P1 を含む）。受注管理システムは以前に他社が作ったWebシステムで、PHPで書かれており、ソースコードと改修の権利は自社にある。ログインはシステム独自のID・パスワード。営業・事務・管理職・システム管理者の4種類の権限がある。

ログインの付け替え（順番4）については、他社の技術ブログでも、PHP製の社内システムを Entra ID とOIDCでSSO化した例が「それほど難しい内容ではない」と紹介されています（EXTECH 技術ブログ）。時間がかかりやすいのは、表の2・3・5・6・7のような社内での確認と決定です。

受入試験で確かめる項目

発注前にこの表を用意しておくと、何をもって完成とするかを開発会社と合わせやすくなります。以下は試験の項目と合格条件の例で、実際に試験した結果ではありません。

権限まわりの試験は、利用者の種類が増えるほど行数が増えます。社外の顧客や会員にログインさせる仕組みは設計の考え方が別なので、顧客ポータル開発の記事を参照してください。スマホや社外から使うときの権限は業務システムのスマホ対応の記事で扱っています。

費用の考え方：改修費と外部利用料を分ける

SSO対応の費用は、開発会社に払う改修費と、IdPなどの外部利用料に分けて考えます。自社開発システムのSSO改修について、前提を揃えて比べられる公開相場は今回の調査では見つからなかったため、相場の断定はしません。

当社の価格（すべて税別）

改修の金額は、利用者の種類と権限の数、SCIMを実装するか、ローカルログインをどこまで閉じるか、古いバージョンを上げる作業が要るか、試験の行数で変わります。

改修費に含まれないもの（外部利用料）

仮定に基づく試算として、社員80名で Entra ID P1 を単体で買う場合、1,049円×80名×12か月＝1,007,040円で、年に約100.7万円相当です。すでに Business Premium や E3 を契約していれば、P1 の追加購入は不要です。グループ単位の割り当てや前段方式を使わないなら、無料版の範囲で始められる場合もあります。

当社が対応できるのは、他社が作ったシステムの調査・引継ぎ・改修と、認証・権限・社外利用者の分離を含む開発です。言語やフレームワークを理由にお断りすることはありません。ただし、Entra ID・Google Workspace・特定のIDaaS製品について、当社の受託実績や認定パートナーの資格を示すことはできません。また、改修によってセキュリティ認証の取得や法令への適合を保証するものではなく、第三者による侵入試験も含みません。

ソースの有無や直す権利が分からない段階では、「調査のみ」も「調査＋改修」もご相談いただけます。最初にソースコード・仕様書・環境情報の有無と利用権を確認します。受託開発の対応範囲と価格もあわせてご覧ください。改修全般の費用の内訳はシステム改修の費用で整理しています。

相談の前に揃えておくと早い情報

次の情報があると、30分の初回相談で、どの方式が候補になりそうかまで話を進めやすくなります（可否を確かめるには、ソースや環境を見る調査が別に要ることがあります）。すべて揃っていなくても構いません。

• SSOにつなぎたいシステムの名前と用途、使っている人数（部署ごとの概数）
• 会社のIDとして使っているもの（Entra ID / Google Workspace）と、Microsoft 365 などの契約プラン名
• ソースコードの有無、元の開発会社と保守契約の有無
• ブラウザで使うシステムか、端末に入れて使うソフトか
• 権限の種類（例: 営業・事務・管理職・管理者）と、社外の利用者がいるか
• 共有アカウントや退職者のアカウントが残っていそうか
• 困っていること（退職者の停止漏れ、パスワードの使い回しなど）

パスワード・本番の接続情報・実際の利用者一覧などの秘密情報は、相談の段階では送らないでください。

初回相談は無料・30分（オンライン）です。要件が決まっていなくても大丈夫です。今のシステムと困っている操作を伺い、自社でAIを使って進める部分と任せる部分を一緒に切り分けます。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。

今のシステムをSSOに対応できるか相談する

よくある質問

Entra ID と Google Workspace の両方を使っています。どちらにつなげばよいですか

社員全員が持っていて、退職時に必ず止める運用になっている方につなぐのが基本です。システムを両方に対応させることもできますが、1人の社員がIdPごとに別のアカウントとして現れるため、対応付けと停止の確認が二重になります。

多要素認証（スマホでの確認など）はシステム側で作る必要がありますか

SSOにした場合、多要素認証はIdP側で掛けられるため、システム側で作る必要はありません。Entra ID は無料版にも多要素認証が含まれます。場所や端末に応じて確認を変える「条件付きアクセス」は P1 以上が必要です（Microsoft Learn「Microsoft Entra ライセンス」、2026-10-14確認）。

元の開発会社に頼むべきか、別の会社に頼むべきか迷っています

元の開発会社に連絡がつき、保守契約もあるなら、まず元の会社に見積を取るのが自然です。ログイン処理の場所や過去の改修の経緯を知っているためです。連絡がつかない、見積が出ない、権利関係が分からない場合は、別の会社による調査から始めます。比べるときは、試験の項目と完成の条件を同じ表で示してもらうと違いが分かります。

改修している間も、今のID・パスワードでログインできますか

できるように進めます。試験環境でSSOを確かめてから本番に入れ、切替日を決めて案内します。切替後しばらくはローカルログインに戻せる状態を保ち、戻す判断を誰がするかも先に決めておくと安心です。

SSOにすれば、パスワード漏えいの心配はなくなりますか

システムごとのパスワードが減るので使い回しは防ぎやすくなりますが、心配がなくなるわけではありません。会社のIDが1つ漏れると、つないだシステムすべてに入られるおそれがあります。IdP側の多要素認証と、管理者用の入口の管理が前提になります。

端末に入れて使うソフトや、スマホアプリでもSSOにできますか

できる場合がありますが、Webシステムとはログイン画面の作り方が違うため、ソフトの作りを調べてから方式を決めます。ブラウザで使う部分とアプリの部分が混ざっているシステムも、調査で切り分けます。

社外の委託先やパートナーも同じシステムを使っています

IdPにゲストとして登録してSSOに入れるか、ローカルログインを例外として残し、使える範囲を絞るかを決めます。例外として残す場合は、そのアカウントの停止を誰がいつ確かめるかも決めておきます。

社内の業務システムだけがSSOから外れている状態は、どの方式を取れるかを確かめれば、改修の範囲と費用の枠が見えてきます。ソースの有無が分からない段階からでも構いません。

今のシステムをSSOに対応できるか相談する