>
>
公開日
2026年7月9日、Googleは「Google Workspace Updates」ブログにて、Google Workspaceのインバウンド SCIM APIが一般提供(GA)を開始したことを発表しました。外部のID管理システムを使ってGoogle Workspaceアカウントを運用している情シス担当者にとっては、入退社・異動に伴うアカウント管理の負荷を軽減できる可能性がある発表です。
本記事では、インバウンドSCIM とは何か、導入メリット、4つの罠、既存同期手段との違いを情シス目線で解説します。
SCIMの基本仕様から確認したい場合は、SCIMの仕組みとSaaS連携の基礎もあわせて参照してください。
Google Workspace インバウンドSCIMとは
SCIM(System for Cross-domain Identity Management)は、IDプロバイダー(IdP)とサービス間でユーザー・グループ情報を同期するための標準プロトコルです。これまでもSlackやAsanaなど多くのSaaSがSCIMに対応していましたが、Google Workspace自体は「SCIMを受け取る側」としての公式対応が長らく限定的でした。
今回のインバウンドSCIM対応により、Google WorkspaceはSCIMのサービス提供者(Service Provider)として機能するようになります。つまり、Okta・Microsoft Entra ID・HRシステムなど、SCIM 2.0に対応した外部のIdPやHRISから、Google Workspace側のユーザー・グループ情報をリアルタイムで自動的に作成・更新・無効化できるようになります。
外部IdP側で権限変更が行われると、Google Workspaceだけでなく、Gemini Enterpriseのような下流の連携アプリへのアクセス権も同時に更新される点が特徴です。
情シスにとっての導入メリット
インバウンドSCIM最大のメリットは、入退社対応の工数削減と、退職者アクセスの即時停止を両立できる点です。
手動プロビジョニングでは、アカウント発行から属性設定、グループ追加、退職時の停止確認まで15〜30分かかる運用も珍しくありません。仮に年間50件の入退社・異動があれば、アカウント作業だけで25〜50時間を奪われる計算になります。SCIMではIdP側の変更がAPI処理に置き換わるため、手動作業に比べて95%以上の工数削減を見込める構成も現実的です。
入社初日の生産性も改善します。アカウント未作成、共有ドライブ未参加、メーリングリスト未追加といった待機時間を減らし、人事データが確定したタイミングでGoogle Workspaceへ反映できます。
社内でのAI活用が進むにつれ、退職者アカウントの残存リスクは以前より深刻化しています。Gemini Enterpriseのような社内AIは、ドキュメントやメール、共有ドライブの情報に横断的にアクセスするため、退職者の権限が数時間残るだけでも情報参照リスクが残ります。IBM「Cost of a Data Breach Report 2024」では、データ侵害の世界平均コストは488万米ドルと報告されています。AI時代のID管理では、退職処理と同時にアクセスを止めるリアルタイム・デプロビジョニングが前提になります。
ライセンス面でも効果があります。棚卸しで不要アカウントが10〜15%見つかる前提で試算すると、100ユーザー契約の組織では10〜15ライセンス分の費用が毎月余分に発生している可能性があります。SCIMで退職・休職・異動を自動反映すれば、孤立アカウントの放置を抑えられます。
提供プランと展開時期で押さえるべき点
Google WorkspaceのインバウンドSCIMは、Business Starterを含む対象プランで利用でき、Google側のSCIM専用高額オプションを前提にしない設計です。
Google Workspace Updatesの2026年7月9日発表では、Rapid ReleaseとScheduled Releaseの両方で最大15日間の段階的ロールアウトが案内されました。管理コンソールに表示されない場合は、設定ミスだけでなく展開待ちの可能性があります。
区分 | 対象として案内されているプラン | 情シスの確認ポイント |
|---|---|---|
Business | Starter、Standard、Plus | 小規模でも対象。Google Cloud組織リソースの有無を先に確認する |
Enterprise | Starter、Standard、Plus | 大規模なIdP連携、監査、グループ同期の標準化に向く |
Cloud Identity | 対象として案内 | Workspace本体と併用するID基盤として検討できる |
SaaS業界では、SCIM連携を最上位プランだけに限定して追加費用を求める慣行がSCIM Taxと呼ばれてきました。Googleがエントリープランを含めて受け口を提供したことは、Okta、Auth0、Entra IDなど接続元を自由に選びたい企業にとって意味があります。ただし、接続元IdPやHRIS側ではSCIMが上位プラン機能の場合があります。Google側の提供条件とIdP側の課金条件は分けて確認します。
導入前に情シスが確認しておきたい4つの注意点
インバウンドSCIMは便利な一方で、前提条件と運用制約を見落とすと本番移行でつまずきます。
1. Google Cloud組織リソースが必須
見落としがちなのは、Google Workspace管理コンソールだけでは設定が完結しない点です。インバウンドSCIMの利用にはGoogle Cloudの組織リソースが必要です。GCPを使っていない中小企業やスタートアップでは、Cloud Console側の初期構成、管理者権限、組織ポリシーの確認が初めて発生します。
2. 管理者アカウントはSCIM同期の対象外
インバウンドSCIM用のサービスアカウントは、特権管理者などの管理者アカウントを自動管理する権限を持ちません。退職した管理者の無効化、権限剥奪、代替管理者の設定は、別の承認フローとして残す必要があります。
3. 同期されたグループはデフォルトでロックされる
新しいSCIM接続では、同期グループをロックする設定がデフォルトで有効になります。これはIdPを正とする整合性維持に有効ですが、Google管理コンソールからグループを編集していた現場では「急に変更できない」という問い合わせにつながります。運用開始前に、グループ変更はIdP側で行うと周知します。
4. API接続トークンのローテーションが必要
SCIMのBearerトークンは、ユーザー作成や無効化に関わる強い権限を持ちます。発行者、保管場所、利用者、失効手順、ローテーション周期を決めずに本番運用してはいけません。パスワード管理ツール、変更記録、退職者チェックを組み合わせ、90日または180日ごとの定期ローテーションを運用ルールに入れます。
よくある誤解・失敗パターンと対策
Google Workspace SCIM 連携で失敗する主因は、SSOとの混同と既存同期基盤との二重管理です。
SSOを入れればSCIMは不要という誤解
SSOは、誰がログインしようとしているかを確認する認証の仕組みです。一方、SCIMは誰のアカウントを作るか、どの属性にするか、退職時にいつ無効化するかを扱うライフサイクル管理です。JITプロビジョニングで初回ログイン時にアカウントを作成できる場合でも、退職時のリアルタイム削除やグループ更新まではSSOだけでは完結しません。
GCDSと並行稼働させる同期競合
Google Cloud Directory Syncを動かしたまま別のIdPからインバウンドSCIMを有効化すると、同期元が二つになります。数時間ごとのGCDS同期とリアルタイムSCIMが衝突し、ユーザー属性の上書き、グループ重複、意図しない停止が起きます。
移行時は、対象OUとグループを切り分け、検証期間を決め、GCDS側の該当同期タスクを停止してからSCIMへ移します。やってはいけないのは、全社ユーザーを初回から一括同期することです。まずはテストOUや非重要グループで、入社、異動、退職の3パターンを再現します。
▲ SSO（認証）とSCIM（プロビジョニング）の役割の違い
既存の同期手段との違い
クラウドIdPを中心に運用する組織はインバウンドSCIM、オンプレミスAD中心の組織はGCDSまたはDirectory Syncを検討するのが基本です。
Google Workspaceには、これまでもDirectory SyncやGoogle Cloud Directory Syncがありました。違いは、同期元、接続方式、同期速度、ライセンス、適合組織です。
比較軸 | Directory Sync | GCDS | インバウンドSCIM |
|---|---|---|---|
主な同期元 | 外部ディレクトリ | オンプレミスLDAP、Active Directory | Okta、Auth0、Microsoft Entra ID、HRISなどSCIM 2.0対応システム |
接続方式 | Google側の同期機能 | 専用クライアントを社内環境に導入 | クラウドAPI連携 |
同期速度 | 設定に依存 | 定期バッチ型 | リアルタイムに近いイベント連携 |
ライセンス・費用 | Google Workspaceの対象機能内 | Google側の追加費用よりもサーバー運用負荷が論点 | Google側は対象プラン内。IdP側のSCIM提供条件を確認 |
向く組織 | Google標準機能で同期したい組織 | 既存ADを中心に運用する組織 | クラウドIdPとSaaS管理を標準化したい組織 |
規模別の判断も明確です。50名未満で入退社が年数件なら、手動管理と定期棚卸しで足りる場合があります。50〜300名で月数件の入退社・異動があるなら、SCIMの効果が出始めます。300名超では、人事システム、IdP、Google Workspace、SaaS管理ツールをつなぐ前提で設計しないと、棚卸しと監査対応が重くなります。
対応製品と導入イメージ
2026年時点のGoogle Workspace インバウンドSCIMは、主要IdPやHRISを起点にしたIDライフサイクル自動化へ組み込みやすい状態です。
OktaとAuth0は、2026年7月にエンタープライズ接続向けのインバウンドSCIMグループ同期を一般提供したと案内しています。Google Workspace側の受け取り機能と組み合わせることで、ユーザーだけでなくグループを含むリアルタイム同期の設計がしやすくなりました。
国内では、Googleプレミアパートナーの株式会社G-genとシスコシステムズが、Duo IAMとGoogle Workspaceの相互連携を検証しています。Google WorkspaceをIDレシーバーとして動作させるSCIMプロビジョニングを試行した点は、国内情シスが導入前検証を設計する際の参考になります。
製品・企業 | 位置づけ | 確認すべき内容 |
|---|---|---|
Okta / Auth0 | クラウドIdP、顧客ID管理 | SCIM 2.0のユーザー・グループ同期、対象プラン、属性マッピング |
Microsoft Entra ID | 企業向けIdP | GalleryアプリまたはSCIMプロビジョニング設定、同期範囲 |
Cisco Duo IAM | 多要素認証・ID管理 | SCIMプロビジョニング対応状況、対象プラン、Google Workspace側の受け口 |
Workday、BambooHR | HRIS | 人事マスターからIdP経由でGoogle Workspaceへ流す属性と入退社イベント |
実運用では、HRISを正とし、人事イベントをIdPへ連携し、IdPからGoogle WorkspaceへSCIM同期する流れが標準形になります。属性名、社員番号、メールアドレス、退職日、所属グループの対応表を先に作ると、移行時の手戻りを減らせます。
導入を検討する際のチェックリスト
インバウンドSCIMの導入は、準備、設計、検証、移行、運用の5段階で管理すると失敗を減らせます。
フェーズ | いつ | 誰が | 実施事項 |
|---|---|---|---|
準備 | 導入2〜4週間前 | 情シス、IdP管理者 | 対象プラン、Google Cloud組織リソース、SCIM対応IdP、管理者権限を確認 |
設計 | 導入1〜2週間前 | 情シス、人事、部門管理者 | 正とする人事属性、OU、グループ、管理者アカウントの手動管理フローを決める |
検証 | 本番前 | 情シス | 少数ユーザーで作成、更新、無効化、グループロック、トークン失効時の挙動を確認 |
移行 | 本番切替日 | 情シス、IdP管理者 | GCDSなど既存同期の対象範囲を停止し、二重管理を避ける |
運用 | 本番後 | 情シス、監査担当 | 同期エラー、孤立アカウント、トークンローテーション、管理者棚卸しを定期確認 |
検証では、正常系だけでなく失敗系も確認します。メールアドレス変更、姓変更、休職、復職、退職日取り消し、IdP側グループ削除、トークン失効をテスト項目に入れます。これらを本番前に確認しておくと、初回同期後の問い合わせを減らせます。
▲ インバウンドSCIM導入を安全に進めるための5段階のロードマップ
よくある質問
Google Workspace インバウンドSCIMの疑問は、SSOとの違い、費用、GCDS移行、管理者アカウントの扱いに集中します。
Q：Google Workspace インバウンドSCIMとは何ですか？
A：外部IdPやHRISからGoogle Workspaceへユーザー・グループ情報を同期するSCIM 2.0ベースの機能です。入社時の作成、異動時の属性更新、退職時の無効化を自動化できます。
Q：Business Starterでも追加費用は本当に不要ですか？
A：Google側のインバウンドSCIM機能はBusiness Starterを含む対象プランで案内されています。ただし、接続元のIdPやHRISでSCIM機能が上位プラン扱いになる場合があるため、IdP側の料金条件は別途確認が必要です。
Q：GCDSからの移行手順はどう考えればよいですか？
A：まずGCDSで同期しているOU、グループ、属性を棚卸しし、SCIMへ移す範囲を決めます。検証後、該当するGCDS同期タスクを停止してからSCIMを本番化し、二重同期を避けます。
Q：SSOを設定済みでもSCIMは必要ですか？
A：必要になるケースが多いです。SSOはログイン認証、SCIMはアカウントの作成・更新・削除を担うため、退職者の即時停止やグループ同期にはSCIMが適しています。
Q：管理者アカウントも自動で無効化されますか？
A：管理者アカウントはSCIM同期の対象外として扱う必要があります。特権管理者の退職や異動は、別の承認フローで手動対応する運用を残します。
まとめ
Google Workspace インバウンドSCIMは、単なる新機能ではなく、入退社・異動・退職者アクセス停止を標準化するためのID管理基盤です。まず着手すべき一歩は、現在の同期元、GCDSの有無、Google Cloud組織リソース、管理者アカウントの手動フローを棚卸しすることです。50〜300名以上で入退社対応が定例化している組織は、テストOUを使った小さな検証から始めるのが安全です。
✅ 現在の同期元（GCDS・Directory Sync・手動）と運用フローを棚卸しする
✅ Google Cloud組織リソースの有無を管理コンソールで確認する
✅ 接続元IdP・HRIS側のSCIM提供プランと費用条件を確認する
✅ 管理者アカウントの手動管理フローを別途設計する
✅ テストOUで入社・異動・退職の3パターンを検証してから本番移行する
✅ APIトークンのローテーション周期と保管ルールを運用手順書に明記する
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
