Google WorkspaceのInbound SCIM APIが一般提供された。SCIM 2.0対応のIdP、HRIS、独自アプリから、ユーザーとグループをリアルタイムに作成、更新、状態変更できる。人員変更や権限変更がWorkspaceと下流サービスへ早く反映される一方、既存のDirectory APIや別の同期製品と並行運用すると競合が起きる。

何が変わったか

Google WorkspaceがSCIM Service Providerとして動作し、外部ディレクトリから増分同期を受け付ける。管理コンソールから接続を作成するとGoogle管理のサービスアカウントが用意され、ユーザー管理とグループ管理に必要な権限が設定される。機能はドメイン単位で有効・無効化できる。

変更前後の差

従来はDirectory APIを使った独自連携や別の同期方式を構築する必要があった。Inbound SCIMでは標準プロトコルでリアルタイム変更を送れる。同期されたグループは外部ソースとの競合を避けるためロックされる運用があり、手動編集中心の管理とは責任分界が変わる。

誰に影響するか

人員変更をIdPや人事システムから自動化する管理者が対象である。Workspaceデータだけでなく、Gemini Enterpriseなど下流アプリのアクセスもディレクトリ状態へ連動させる組織では、状態反映速度がセキュリティへ直結する。

期限

強制移行期限はない。2026年7月9日から段階展開されている。既存同期を直ちに停止せず、対象OUやテストユーザーを限定して移行する。

必要な対応

現在のユーザー・グループ正本を決め、SCIMと既存同期が同じ属性を更新しないようにする。認証情報の管理責任、更新、無効化を定義し、管理コンソールとGoogle Cloudコンソールの管理対象を混同しない。

実装・移行手順

  1. IdP、HRIS、Directory API連携を棚卸しする
  2. 属性マッピングと正本システムを決める
  3. テスト用の接続と認証情報を作成する
  4. 少数のユーザーとグループで作成・更新・状態変更を試す
  5. グループロックと手動変更の挙動を確認する
  6. 監査ログと失敗通知を接続する
  7. 段階的に対象を拡大する
  8. 競合する旧同期を停止する

失敗しやすい点

既存同期を残したまま同じ属性を更新する、認証情報を長期間固定する、管理者アカウントも通常ユーザーと同じ手順で状態変更する、グループの所有者を定めない、といった問題が起きやすい。削除と状態変更の意味も事前に合わせる必要がある。

リスク

誤った属性マッピングによる広範な状態変更、同期遅延、管理対象外アカウント、グループ権限の消失、認証情報の漏えい、監査ログ不足がある。リアルタイム化は誤変更も即時反映するため、承認と復旧手順が必要である。

評価方法

作成・変更・状態反映の時間、失敗率、手動修正件数、管理対象外アカウント数、グループ差分、アカウント状態の反映時間を測る。IdP停止時と不正な属性入力時の挙動も試験する。

ロールバック

SCIM接続を停止し、直前のディレクトリエクスポートから差分を復元できるようにする。旧同期をすぐ削除せず、読み取り専用の比較期間を設ける。ただし二重書き込みへ戻さない。

編集部分析

Inbound SCIMの価値は管理作業の削減より、利用者や権限の変更を生成AIサービスまで一貫して反映できる点にある。導入の成否はプロトコル対応ではなく、どのシステムを正本とするかの決定で決まる。

実務チェックリスト

  • ディレクトリの正本を決めた
  • 既存同期との競合を確認した
  • 認証情報の管理と更新を定義した
  • 状態変更と復旧を試験した
  • グループロックを確認した
  • 監査ログを保存した

一次情報