複数 AI ツール Cloud Identity 一元管理の設計判断

ChatGPT Enterprise・Claude・Gemini など複数の AI ツールを同時に運用する企業が増え、SSO（シングルサインオン）やユーザー管理がツールごとに分散する状況が広がっている。この記事では、Google Workspace の IdP（Identity Provider）機能である Cloud Identity（クラウド ID）を軸に、複数 AI ツールの統合管理設計をどう進めるかの判断基準を整理する。

この記事を読んだほうが良い人

• ChatGPT Enterprise・Claude・Gemini のうち 2 つ以上を社内に導入している 100 名規模企業の情シス担当者
• ツールごとに SSO 設定やアカウント管理が分散し、退職者対応の手順が増えてきた方
• 複数 AI ツールの統合ガバナンス設計をこれから整備したい方

「ツールごとバラバラ管理」が情シスに生む 3 つの負荷

ChatGPT Enterprise、Claude、Gemini がそれぞれ独立して導入されると、管理の構造は次のような形になる。

• ツールごとに別々の管理画面でアカウントを作成する
• SSO もツールごとに個別に設定する
• 退職者が発生するたびに全ツールの管理画面を個別に回る

ツールが 1 本なら許容できる運用負荷だが、3 本を超えたあたりから課題が乗算的に積み上がる。情シスが直面する問題を整理すると、大きく 3 つになる。

• 退職者対応の抜け漏れリスク: ツールごとに異なる管理画面を個別に操作するため、ひとつ見落とすと退職済みユーザーが AI ツールにアクセスし続けるリスクが残る
• 監査ログの分散: 誰がいつ何を生成したかの記録が各ツールに散在し、横断的な把握に手間がかかる
• 新ツール追加のたびにゼロリセット: ポリシー設計・管理者権限付与・退職フローの整備を毎回やり直す必要がある

この 3 点を構造的に解消するのが、Cloud Identity を IdP の中心に据えた SSO 統合の設計思想だ。

Cloud Identity を IdP にする統合設計の考え方

Cloud Identity は Google が提供する IdP サービスで、Google Workspace に含まれているほか、単独製品（Free / Premium）としても利用できる。SAML 2.0（Security Assertion Markup Language）ベースのカスタムアプリ統合を管理コンソールのアプリ設定から構成できる。「Cloud Identity が認証の中心に立つ」設計にするのが統合の核心だ。

SSO を設定すると、Google アカウントの有効/無効がそのまま各 AI ツールへのログイン可否を決める。管理コンソールでアカウントを停止すれば、SAML SSO 経由で接続しているツール全体へのログインが即時ブロックされる。

さらに対応ツールでは SCIM（System for Cross-domain Identity Management）によるプロビジョニング同期も設定できる。SCIM まで設定すると、Cloud Identity 側でユーザーを停止したタイミングでツール側のアカウントも自動的に無効化・削除されるため、情シスが各ツールの管理画面を個別に操作する手間がなくなる。

ChatGPT Enterprise・Claude・Gemini の SSO と SCIM 対応状況

現時点（2026年6月）での各ツールの SSO / SCIM / 監査ログ対応状況をまとめると、以下の通りになる。

Gemini for Google Workspace は Google Workspace の一部として Cloud Identity と最初から統合されているため、別途 SSO を設定する必要がない。管理コンソールの設定を確認・調整するだけで、他ツールと同等の管理体制に入れる。

ChatGPT Enterprise と Claude Enterprise の SCIM は、いずれも Enterprise プランでのみ利用できる点に注意が必要だ。ChatGPT Business や Claude Team など下位プランでは SSO は利用できても SCIM は対象外になる。導入予定のプランとセキュリティ要件を照合してから統合設計を進めること。

どのツールから着手するか：統合優先度の判断フロー

3 ツールをいきなり同時に統合しようとすると実装負荷が高くなる。段階的に進めるのが現実的だ。

ステップ 1: Gemini を起点に「Cloud Identity で今何が制御できているか」を棚卸しする

Gemini for Google Workspace は Cloud Identity にすでに統合済みのため、現時点でアカウント管理がどこまで機能しているかを確認するところから始める。アカウント停止フローやグループ管理が正しく動いていれば、それが他ツールへの SSO 設定の基準線になる。

ステップ 2: 利用ユーザー数が多いほうを優先して SSO を接続する

ChatGPT Enterprise と Claude のどちらを先に統合するかは、「退職者が発生したときにどちらのアカウント停止漏れがよりリスクになるか」で決める。日常的に多くの社員が使っているツールを先に SAML SSO で接続する。SSO さえ繋げば、退職者対応は Cloud Identity 一箇所の停止操作で済むようになる。

ステップ 3: SCIM の投資対効果を試算してから判断する

SCIM は Enterprise プランへのアップグレードが前提になる場合が多い。退職者が月 1〜2 名程度なら SSO だけでも十分に運用できる。月 5 名以上の入退社が継続的に発生するなら、SCIM による自動化は費用回収の見込みが立ちやすい。入退社の年間件数とプランのコスト差を照合して判断すること。

退職者対応はどう変わるか：統合前後の比較

統合前（バラバラ管理）

退職者が発生するたびに、情シスは ChatGPT Enterprise の管理画面・Claude の組織管理画面・GWS 管理コンソールを個別に開き、それぞれでアカウントを無効化・削除する手順を踏む。対象ツールが増えるほど確認リストも増え、手順書の更新コストも比例して上がっていく。

統合後（Cloud Identity を IdP として接続済み）

GWS 管理コンソールで対象アカウントを停止する。SAML SSO で接続した AI ツールへのログインは即時ブロックされ、SCIM を設定済みのツールはアカウントも自動削除される。確認項目は「Cloud Identity 側の停止処理が完了しているか」の 1 点に集約される。

なお、OAuth で個人 Google アカウントと AI ツールを連携しているケース（例：個人 Gmail で Claude に接続している）は SAML SSO の対象外だ。このパターンは別途 OAuth アクセス制御のポリシーで対応する必要がある。

統合後も残る 3 つの課題

Cloud Identity による SSO 統合は強力だが、解決しない問題もある。設計スコープを決める前に、以下の制約を把握しておく必要がある。

• API キーは SSO の対象外: ChatGPT や Claude を API キーで直接呼び出す開発者・業務システムがある場合、アカウント停止は API キーの有効性に影響しない。API キー管理は別ポリシーが必要になる
• 個人 OAuth 接続は別管理: 従業員が個人アカウントでツールと OAuth 連携している場合、Cloud Identity でのアカウント停止だけでは対処できない。ブラウザ拡張の制御や OAuth スコープの監査など、別の管理レイヤーも検討する
• 監査ログはまだ分散: SAML SSO を統合しても、各ツールの操作ログは各ツールの管理画面に残る。「誰が何を生成したか」を横断的に追うには、ログ集約基盤との連携を別途設計する必要がある

「Cloud Identity 統合で解決すること」と「別途対応が必要なこと」を明示しておくと、社内の合意形成や導入スコープの設定がスムーズになる。

統合管理は「ツールの問題」ではなく「設計の問題」

Cloud Identity による統合管理は、個別ツールの設定よりも「どの認証フローをどこで制御するか」という設計の問題だ。ツール 1 本ずつに対処する reactive な管理から、IdP を軸にした proactive な設計に移行することで、今後新しい AI ツールが追加されたときも「まず Cloud Identity と SSO を接続する」という共通の着地点が生まれる。

100 名規模の企業であれば、退職者対応の効率化だけでなく、監査証跡の整備やポリシー適用の一貫性確保という観点でも、Cloud Identity を軸にした統合設計の投資対効果は見込める。まず Gemini を起点に今の状態を棚卸しすることが、最初の一歩になる。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。