BtoBプラットフォームのCIAM設計論｜顧客企業ごとのSSO連携（SAML/OIDC）と委任管理の実践

中堅・中小企業であれば「サービスごとにIDとパスワードを発行する」運用でも受け入れられる場合がありますが、セキュリティ統制の厳しい大手企業ではそうはいきません。

大手企業ではJ-SOX法、ISMS、ゼロトラストアーキテクチャの推進により、「社外サービスに独立したパスワードを持たせること」自体が原則禁止されているケースが増えています。認証を自社の一元的なID基盤（IdP）に集約することで、パスワードの使い回しや漏洩リスクを根本から防ぎます。

人事異動や退職が発生した際、外部サービスごとに手動でアカウントを停止していては必ず削除漏れ（元社員による不正ログイン）が生じます。 顧客企業のIdPとSSO連携されていれば、顧客の人事システムやEntra ID側でアカウントを無効化するだけで、貴社のプラットフォームへのアクセス権もリアルタイムに遮断されます。

顧客企業は自社のIdP側で「会社支給PC以外からのアクセス禁止」「社外ネットワーク時は生体認証必須」といった独自の条件付きアクセスを設定しています。貴社のサービスがSSO連携に対応していれば、顧客は自社のセキュリティルールをそのまま適用して安全に利用できます。

エンタープライズ市場において、SSO連携は「あれば嬉しい付加価値」ではなく、「なければ検討の土俵にすら乗れない必須機能（ディールブレイカー）」なのです。

「顧客ごとのSSO連携が必要なら、社内で都度開発すればいいのでは？」と考えるかもしれませんが、認証基盤を一から自作・維持するのはコストとリスクの両面で割に合いません。

• 各社IdPの「仕様の揺らぎ」への個別対応
  SAML 2.0やOIDCは共通規格ですが、Microsoft 365、Google Workspace、Oktaなど、顧客が利用するIdPごとに証明書の扱いや属性マッピングの仕様が異なり、顧客ごとの個別改修が多発します。
• 証明書更新・障害対応の運用負債
  暗号化証明書の定期更新ミスでログイン障害が起きれば、顧客企業の全業務が停止する重大インシデントに直結します。24時間365日の監視と保守を自社で抱え続けるのは大きな負担です。
• 本来の開発リソースの圧迫
  認証という「ビジネスの差別化にならないインフラ部分」にエンジニアの工数を奪われ、コア機能の開発がストップしてしまいます。

BtoB CIAMにおいては、自力で作り込むのではなく「実績のある認証ゲートウェイを活用し、最短・ノーコードで安全に繋ぐ」のが現代のスタンダードです。

BtoBプラットフォームで複数の顧客企業にSSOを提供する場合、「ログインしようとしているユーザーが、どの企業のIdPにリダイレクトされるべきか」を識別するルーティング機構が必要です。

主なアプローチには以下の3つがあります。

• 挙動
  ユーザーがログイン画面でメールアドレス（例: taro.yamada@customer-a.co.jp）を入力すると、システムがドメイン（@customer-a.co.jp）を自動判定し、A社のMicrosoft 365ログイン画面へリダイレクトする。
• メリット
  ユーザーは専用URLを覚える必要がなく、単一のログイン画面から迷わず自社IdPへ誘導できる。

• 挙動
  customer-a.your-saas.com や your-saas.com/login/customer-a のような企業専用URLを用意し、そこへアクセスしたユーザーを直接A社のIdPへリダイレクトする。
• メリット
  サービス側でドメイン判定の処理を挟む必要がなく、設計がシンプル。

SAML連携で初回ログインが成功した際、IdPから送信された属性情報（名前、メールアドレス、部署等）を基に、プラットフォーム側にユーザーアカウントを自動作成する仕組みです。事前のユーザー一括インポート作業が不要になり、導入初日から全社展開が可能になります。

SSOと並び、BtoBプラットフォームの運用コストを左右するのが「委任管理（Delegated Administration）」です。

社外ユーザーが数千・数万人に達したとき、自社サポートがアカウントの追加・変更・削除を代行していては確実に組織が破綻します。

【委任管理（代理管理）の階層構造】
[ プラットフォーム全体管理者（自社）]
   │  └─ システム全体の監視、テナントの開設、課金管理
   │
   ├─► [ 顧客A社 テナント管理領域 ]
   │      └─ A社 管理者（総務・情報システム部）
   │            ├─ 自社社員のアカウント招待・発行
   │            ├─ 所属部署・アクセスロール（閲覧/承認/編集）の割り当て
   │            └─ 退職者の即時停止・棚卸し
   │
   └─► [ 顧客B社 テナント管理領域 ]
          └─ B社 管理者
                └─ 自社メンバーの自律的管理

1. 完全なテナント分離
   顧客企業の管理者は、当然ながら「自社に所属するユーザー」のデータしか閲覧・編集できません。他社のテナント情報が混ざらないよう、認可レイヤーで厳格にマルチテナント境界を維持します。
2. きめ細かなロールベースアクセス制御（RBAC）
   「受発注の承認ができる人」「請求書の閲覧のみできる人」「自社内のユーザー管理ができる人」など、組織階層に応じた権限（ロール）を顧客側で自由に割り当てられる設計にします。
3. 顧客企業単位の監査ログ提供
   「自社の誰が、いつどのデータを操作したか」を顧客企業のセキュリティ管理者がいつでもCSV出力・確認できるようにすることで、エンタープライズ企業の監査要件を満たします。
4. 招待ベースのセルフオンボーディング
   顧客管理者がメールアドレスを入力して招待リンクを発行し、招待されたエンドユーザー自身が初回ログインやパスキー登録を完了できる仕組みを用意します。

サイオステクノロジーのクラウド型IDaaS「Gluegent Gate（グルージェントゲート）」は、自社の従業員管理だけでなく、BtoBプラットフォームや取引先ポータルの認証・認可基盤としても強力なパフォーマンスを発揮します。

自社サービスとGluegent Gateの間を一度SAMLまたはOIDCで接続しておけば、各顧客企業が利用しているMicrosoft 365（Entra ID）、Google Workspace、各種SAML対応IdPとのフェデレーション接続をGluegent Gate側で柔軟に集約・中継します。プラットフォーム側の個別開発工数を最小化できます。

取引先すべてが大手企業でSSO基盤を持っているとは限りません。 Gluegent Gateを活用すれば、「大手A社はSAMLによるSSO連携」「中小のB社・C社はGluegent Gate発行のID/パスワード＋FIDO2パスキー認証＋端末制限」といった、相手企業のIT環境に応じたハイブリッドな認証ポリシーを同一プラットフォーム上で共存させることができます。

取引先企業ごとに「この企業は固定IPアドレスからのアクセスのみ許可」「この企業は指定の端末証明書を持つPCのみ許可」といった条件付きアクセスを柔軟に割り当て可能です。

すべてのアクセスログ・管理者操作ログが改ざん不可能な形で長期保管されるため、SCS評価制度（サプライチェーンセキュリティ基準）やISMSの監査時にも、プラットフォーム全体の安全性を客観的証拠として提示できます。

BtoBプラットフォームにおいて、セキュリティやID管理はもはや「情シスのための裏方機能」ではありません。

• 大手企業の求めるセキュリティ要件をクリアし、競合他社を排除して商談を勝ち獲るための「営業機能」
• 取引先が増えてもサポート工数を増やさずに利益率を高めるための「スケーラビリティの基盤」

これらを実現するのが、顧客ごとのSSO連携と委任管理を中核とした「BtoB CIAM」の設計です。

自社開発の工数を抑えつつ、エンタープライズ品質の認証基盤を最短で立ち上げたいプラットフォーム事業者様・情シス部門様は、ぜひ外部IdP連携の実績豊富なGluegent Gateの活用をご検討ください。