--- title: "シングルサインオンの事例：業務SaaS・行政・大学・会員サイトの公開例と自社システムの構成" url: "https://www.issoh.co.jp/column/details/18690/" published: 2026-10-21 updated: 2026-10-21 categories: ["セキュリティ"] publisher: "株式会社一創" --- # シングルサインオンの事例：業務SaaS・行政・大学・会員サイトの公開例と自社システムの構成 シングルサインオン（SSO）の事例を探すと、社名の出ない「A社の場合」というモデルケースばかりが見つかります。この記事では、J:COMのOkta導入、デジタル庁のGビズID、大学の学認、LINEログインといった公開情報で確かめられる事例を、「誰のIDで何に入るか」の4つの型に分けて紹介します。身近なシングルサインオンの例から業務システムの導入事例までを同じ物差しで並べ、自社で開発したシステムをSSOに対応させるときの構成例と、事例を真似て失敗する条件も整理しました。 ## まとめ：SSOの事例は誰のIDで何に入るかの4型で読み、自社システムは改修量で構成を選ぶ 公開されているシングルサインオンの事例は、社員が業務SaaSに入る型、事業者が行政手続に入る型、大学の構成員が学外サービスに入る型、一般の会員が外部のIDで会員サイトに入る型の4つに分かれます。型が違えばIDを発行する側（IdP）の持ち主も、選ぶ製品も変わります。他社の事例を参考にするときは、まず自社がどの型に当たるかを決めてください。 自社開発システムをSSOに対応させる方法は、アプリをSAMLやOpenID Connect（OIDC）に対応させる改修、手前にプロキシを置いてヘッダーでIDを渡す構成、SCIMでアカウントの作成と停止まで自動化する構成の3つです。改修できるならアプリ側の対応を選びます。ソースが手元に無い旧システムだけをヘッダー方式で包み、その場合は旧システムへの直接アクセスを必ず塞ぎます。 ## シングルサインオンの公開事例を4つの導入パターンで整理した一覧と読み方 シングルサインオンの仕組みそのものは[シングルサインオン（SSO）とは？4つの実現方式とIDトークン検証・IdP選定を実装手順で解説](https://www.issoh.co.jp/tech/details/15821/)で扱っています。ここでは仕組みの説明を省き、事例を比べるための整理に絞ります。 ### 社員・事業者・学生・会員の4型で比べるIdPの持ち主と連携先の違い この記事で取り上げる事例を、ログインする人とIDの持ち主で並べると次の表になります。 | 型 | ログインする人 | IdPの持ち主 | 公開事例 | | ---------- | ------- | ----------- | ------------------ | | 社内SSO | 社員 | 自社 | J:COM、Salesforce連携 | | 行政の共通ID | 事業者 | デジタル庁 | GビズID | | 学術フェデレーション | 教職員・学生 | 各大学 | 学認 | | 会員のID連携 | 一般の会員 | LINE等の外部事業者 | LINEログイン | 社内SSOだけがIdPを自社で持ちます。残りの3型は、IDを持つ組織とサービスを提供する組織が別で、事前の取り決め（参加規約や利用規約）が前提になります。 ### 事例を読むときに確かめる認証方式とアカウント連携の範囲という2つの観点 事例の記述で見るべき点は2つです。1つ目は認証方式で、SAML 2.0かOIDCか、それとも代理入力やヘッダー方式かを確かめます。方式によって自社システム側の改修量が大きく変わるためです。 2つ目は、ログインの共通化だけで止まっているのか、アカウントの作成・停止まで連携しているのかという範囲です。退職者のアカウントを一括で止められるかどうかはここで決まります。導入効果を「パスワードが1つになった」とだけ書いている事例は、アカウント連携まで踏み込んでいない可能性があります。 ## 業務SaaSと基幹システムをまとめたシングルサインオンの企業事例と設定内容 ### J:COMが基幹システム刷新に合わせてOktaへ認証を集約した事例の要点 社名入りで公開されている国内事例として、[J:COMの基幹システム群の認証をOktaで統合した事例](https://www.okta.com/ja-jp/resources/videos/jcom/)があります。Oktaの公式ページによると、J:COMの情報システム部門は基幹システムの刷新に合わせ、システムごとに分かれていたID管理と認証の機能をOkta Workforce Identity Cloudへ統合しました。 課題は、ユーザーが多数のパスワードを管理しなければならない状態でした。統合後は一度のログインで複数のシステムに入れるようになり、効果として認証関連の開発時間の短縮、コストの削減、運用の効率化が挙げられています。具体的な数値は公開されていません。 この事例で注目すべき点は、SSOの導入を基幹システムの刷新と同じタイミングで行ったことです。各システムが個別に認証機能を作らずに済むため、効果の中心がパスワード削減より「開発時間の短縮」に置かれています。 ### Microsoft Entra IDとSalesforceのSAML連携の公式設定作業 業務SaaSとの連携は、IdP側が製品ごとの手順を公開しています。[Microsoft Entra ID でのシングル サインオン用の Salesforce の構成](https://learn.microsoft.com/ja-jp/entra/identity/saas-apps/salesforce-tutorial)（2026年10月時点の版）では、作業が次の順に並んでいます。 1. Entra管理センターのギャラリーからSalesforceを追加し、方式にSAMLを選ぶ 2. 識別子・応答URL・サインオンURLを入力し、フェデレーション メタデータXMLをダウンロードする 3. Salesforce側でSAMLを有効にし、メタデータファイルから設定を作成する 4. テストユーザーでサインインを確認する 5. ロールアウト後、ローカル資格情報でのアクセスを無効にする 同じページには、SalesforceがSP Initiated SSO、Just-In-Timeのユーザー作成、自動プロビジョニングに対応していると書かれています。業務SaaS側がSAMLと自動プロビジョニングに対応していれば、作業は設定画面への入力だけで完結する形です。見落としやすいのは最後の手順で、ローカル資格情報を残すと多要素認証を回避する入口が残ります。 ## 行政手続と大学で運用されている組織をまたぐシングルサインオンの事例 ### GビズIDが1つのIDで補助金申請や社会保険手続にログインさせる仕組み 事業者向けの共通IDとして、デジタル庁は[GビズID](https://www.digital.go.jp/policies/gbizid)を運用しています。公式ページ（2026年4月28日更新）では「1つのID・パスワードで、複数の行政サービスにログインできます」と説明され、利用できる手続は各省庁と地方自治体へ順次広がっています。 連携先は[GビズIDの行政サービス一覧](https://gbiz-id.go.jp/top/service%5Flist/service%5Flist.html)で公開されており、補助金申請のJグランツ、電子申請のe-Gov、Gビズポータルなどが並びます。アカウントは法人代表者・個人事業主向けのプライム、プライムが従業員に発行するメンバー、審査なしで作れるエントリーの3種類です。 この設計は社内SSOの参考になります。代表者が審査を経たIDを持ち、従業員分はその代表者が発行するという親子構造は、取引先や代理店に自社システムのIDを配るときにもそのまま使えます。 ### 学認（GakuNin）で大学のIDのまま学外のサービスへ入る学術認証フェデレーション 大学の事例では、国立情報学研究所（NII）と全国の大学等が連携して構築する[学術認証フェデレーション「学認（GakuNin）」](https://www.gakunin.jp/)が代表例です。各大学がIdPを運用し、参加するサービス（SP）は利用者のIDを自前で発行せず、各大学のIDでのログインを受け付けます。 学認は本番用の運用フェデレーションと検証用のテストフェデレーションの2つを提供しています。サービスを接続する前に検証用の環境で動作を確かめる手順は、企業同士でSSOをつなぐ場合にも同じ形で必要になります。 ## 会員サイトと顧客向けサービスでのシングルサインオンの例とID連携の実装 ### LINEログインで会員登録を省くID連携の認可リクエストと必須パラメータ 一般の会員向けで身近な例が、外部のIDで会員サイトに登録・ログインさせるID連携です。[LINE Developersの「ウェブアプリにLINEログインを組み込む」](https://developers.line.biz/ja/docs/line-login/integrate-line-login/)によると、LINEログインv2.1はOIDCに対応し、IDトークンでユーザー情報を受け取れます。ログインボタンからは次の認可URLへ移動させます。 ``` https://access.line.me/oauth2/v2.1/authorize?response_type=code &client_id=<チャネルID> &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback &state=<ログインごとに生成した乱数> &scope=profile%20openid &nonce=<リプレイ対策の乱数> ``` response\_type・client\_id・redirect\_uri・state・scopeが必須で、stateはログインセッションごとにランダムに生成するよう公式に明記されています。戻ってきた認可コードの有効期間は10分で、1回しか使えません。stateが一致することを確かめてからトークンを取得する順序を守ってください。IDトークンの検証手順は[OIDC（OpenID Connect）とは？IDトークンの検証手順とOAuth 2.0との違い](https://www.issoh.co.jp/tech/details/6532/)で解説しています。 ### 社員向けSSOと会員向けID連携で分かれる製品選定と既存会員の紐付け 会員向けのID連携は、社員向けSSOと同じ製品で組めるとは限りません。社員向けは数百〜数千のIDを管理部門が統制する前提で、会員向けは数万〜数百万のIDを本人が登録・退会する前提だからです。製品の向き不向きは[Auth0とOktaの違い：顧客IDと従業員IDで分かれる選定基準](https://www.issoh.co.jp/tech/details/17298/)で比べています。 既存の会員サイトにID連携を後から足すときは、既にメールアドレスとパスワードで登録している会員と、LINEなどのIDをどう紐付けるかを先に決めます。メールアドレスの一致だけで自動的に紐付けると、他人のアドレスで外部IDを作った人に既存会員のアカウントを渡してしまう危険があるためです。紐付けは、既存のパスワードでログインした状態でのみ行う設計にします。 ## 自社開発システムをシングルサインオンに対応させた3つの構成例と改修範囲 ここからは、事例の型を自社開発システムに当てはめる構成例です。製品ごとの対応状況と選び方は[シングルサインオン比較：SSO製品・IDaaSの選び方と料金、自社システム組込みの判断](https://www.issoh.co.jp/column/details/18686/)にまとめています。 ### アプリ自体をSAMLのSPやOIDCのRPとして改修する構成と向く条件 ソースコードを持っていて改修できるシステムは、アプリ自体をSAMLのサービスプロバイダー（SP）か、OIDCのリライングパーティ（RP）にします。ログイン画面をIdPへのリダイレクトに置き換え、戻ってきたアサーションやIDトークンを検証して、自社のユーザーテーブルと紐付けます。 新規開発やWebフレームワークが現役のシステムでは、OIDCを第一候補にします。取引先のIdPがSAMLしか出せない場合は、AWSのCognitoのように両方を受けられる中継を挟む方法もあり、その設定は[Cognito SAML連携の手順：Entra IDでSSOを組む設定と属性マッピング](https://www.issoh.co.jp/tech/details/18512/)で扱っています。SAMLの仕組みは[SAMLとは？認証フロー・IdP/SPの仕組み](https://www.issoh.co.jp/tech/details/13299/)を参照してください。 ### 改修できない旧システムの前にプロキシを置きヘッダーでIDを渡す構成 ソースが無い、または改修の予算が出ない旧システムは、手前に認証用のプロキシを置く構成を取ります。Microsoft Entra IDには[アプリケーション プロキシのヘッダーベースSSO](https://learn.microsoft.com/ja-jp/entra/identity/app-proxy/application-proxy-configure-single-sign-on-with-headers)があり、公式ドキュメントは「追加のソフトウェアやアプリへの変更はありません」と説明しています。IdPで認証したユーザーの属性を、HTTPヘッダーに入れて旧システムへ渡す仕組みです。 OSSで組むなら[oauth2-proxy](https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview/)（ドキュメントは2026年10月時点で7.15.x系）が使えます。pass\_user\_headersは既定で有効で、X-Forwarded-UserやX-Forwarded-Emailが上流へ渡ります。起動例は次の形です。 ``` oauth2-proxy \ --provider=oidc \ --oidc-issuer-url=https://login.microsoftonline.com/<テナントID>/v2.0 \ --client-id=<アプリのクライアントID> \ --client-secret=<クライアントシークレット> \ --cookie-secret=<32バイトの乱数> \ --email-domain=example.co.jp \ --upstream=http://127.0.0.1:8080/ \ --pass-user-headers=true ``` 旧システム側は、ヘッダーのユーザー名で自分のユーザーテーブルを引く処理だけを足します。ログイン画面の改修が要らない代わりに、ヘッダーを信用できることが前提です。この前提の守り方は後の章で扱います。 ### SCIMでアカウントの作成と停止まで自動化する構成を加える判断基準 3つ目は、ログインの共通化に加えて、IdPからアカウントの作成・変更・停止を送る構成です。標準仕様のSCIMに対応したAPIを自社システムに実装すると、人事異動や退職の反映をIdP側の操作だけで終えられます。実装の中身は[SCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装](https://www.issoh.co.jp/tech/details/15876/)で解説しています。 判断の基準は、退職者のアカウントを当日中に止める必要があるかどうかです。社外からアクセスできるシステムや個人情報を扱うシステムなら、SCIMまで実装します。社内ネットワークからしか届かず、月1回の棚卸しで足りるシステムなら、ログインの共通化だけで止めて構いません。 ## 事例をそのまま真似ると失敗する構成とSSO導入を見送るべき判断の条件 ### ヘッダー方式で旧システムへの直接アクセスを塞がずなりすましを許す失敗 ヘッダー方式で最も多い失敗は、プロキシを経由しない経路を残すことです。旧システムが社内ネットワークから直接届く状態のままだと、X-Forwarded-Userに他人のユーザー名を書いたリクエストを送るだけでログインできてしまいます。Microsoftの公式ドキュメントも、ヘッダーベース認証のアプリへのアクセスはコネクタなど許可した経路からのトラフィックに制限する必要があると明記しています。 ファイアウォールやIP制限で旧システムへの通信をプロキシからだけに絞れないなら、ヘッダー方式は採用しません。その場合はアプリ側の改修に予算を回すべきです。 ### 連携先が少なく運用担当がいない組織は事例があっても導入を見送る 大企業や行政の事例を見て導入を決めると、規模の違いで失敗します。連携先が2〜3システムで、IdPの障害時に対応できる担当者もいない組織では、IdPが止まったときに全システムへ入れなくなる影響のほうが大きくなるためです。こうした組織は、パスワード管理ツールと多要素認証で済ませ、SSOは見送ります。リスクの大きさと打ち消し方は[シングルサインオンのデメリット：単一障害点とID漏えいの被害拡大、費用と打ち消し方](https://www.issoh.co.jp/column/details/18688/)で整理しています。 逆に、自社開発システムと業務SaaSが5つ以上あり、取引先や会員にもIDを配っている場合は、構成の選び方で改修費が大きく変わります。アプリ改修・ヘッダー方式・SCIMのどれをどのシステムに当てるかの設計から相談したい場合は、[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)で既存システムの棚卸しから対応しています。 ## シングルサインオンの事例でよくある質問：身近な例・中小企業・自社システム シングルサインオンの事例を調べる方から多い質問をまとめました。 ### シングルサインオンの身近な例にはどのようなものがありますか？ 個人で触れる例は、LINEやGoogleのアカウントでショッピングサイトや会員サイトに登録・ログインする仕組みです。これはOIDCを使ったID連携で、会員サイトは外部事業者が発行したIDトークンを受け取って本人を確認しています。仕事では、Microsoft 365にサインインした状態でSalesforceなどの業務SaaSに入れる仕組みが代表例です。事業者として行政手続を行う場合は、GビズIDで補助金申請やe-Govにログインする仕組みも身近なシングルサインオンにあたります。 ### 中小企業でもシングルサインオンの導入事例はありますか？ 社名入りで公開されている事例は大企業が中心ですが、中小企業でもGビズIDのような外部の共通IDはすでに使われています。自社でIdPを持つかどうかの目安は、ログインするシステムの数と運用担当の有無です。連携先が2〜3システムで担当者もいない場合は、パスワード管理ツールと多要素認証で足ります。業務SaaSが5つを超え、入退社のたびにアカウント作業が発生しているなら、Microsoft 365付帯のEntra IDなど既に契約している製品から始めるのが現実的です。 ### 自社で開発した古いシステムもシングルサインオンに対応できますか？ 対応できます。ソースを改修できるならアプリをSAMLのSPかOIDCのRPにし、改修できないなら手前に認証プロキシを置いてヘッダーでユーザー名を渡します。ヘッダー方式はログイン画面を変えずに済みますが、旧システムへの直接アクセスをファイアウォール等で塞ぐことが条件です。塞げない環境では、なりすましを防げないためヘッダー方式を採用せず、アプリ側の改修を選んでください。 ### シングルサインオンとソーシャルログインは何が違いますか？ どちらも一度の認証で複数のサービスに入る点は同じで、違いはIDを発行する側と使う人です。社内のシングルサインオンは自社がIdPを持ち、社員のIDを管理部門が作成・停止します。ソーシャルログインはLINEやGoogleなど外部事業者がIdPで、IDを持ち込むのは会員本人です。そのため会員向けでは、既存会員との紐付けや退会時のデータの扱いを自社で設計する必要があります。 ### シングルサインオンの導入事例で効果はどのように測られていますか？ 公開事例で挙がる効果は、パスワード管理の負担軽減、認証機能の開発時間の短縮、アカウント管理の運用効率化の3種類が中心です。J:COMの事例もこの3点を挙げていますが、削減時間などの数値は公開されていません。自社で効果を測るなら、導入前にパスワード再設定の問い合わせ件数と、入退社1件あたりのアカウント作業時間を記録しておき、導入後と比べる方法が確実です。 ## 関連記事 - [IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16401/)：事例で使われているIdPをクラウドで利用する選択肢の解説です。 - [認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説](https://www.issoh.co.jp/column/details/13631/)：SSOを含む認証全体の位置づけを確認できます。 - [SAML NameIDFormatとメタデータの不一致でSSOが失敗する原因の切り分け](https://www.issoh.co.jp/tech/details/17589/)：SAMLで連携した後につながらないときの確認手順です。 --- 出典: [シングルサインオンの事例：業務SaaS・行政・大学・会員サイトの公開例と自社システムの構成]()（株式会社一創）