AIニュース：ChatGPT Enterprise『Group Managers』で何が起きたか
AIニュース：ChatGPT Enterprise「Group Managers」追加で何が変わったか
結論から言うと、OpenAIがChatGPT Enterprise向けに提供している「Group Managers」は、管理権限の一部を部門側へ渡しやすくする機能です。
ただし、中央管理から部門委譲へ進めたからといって、情シス運用がそのまま軽くなるとは限りません。むしろ注目すべきなのは、権限委譲が進むほど、部門別のモデル利用方針や例外運用の監査が増えやすい点です。
公式のHelp Centerでは、Group ManagersはChatGPT EnterpriseおよびEduで利用でき、OwnersやAdminsが既存のグループメンバーをGroup managerに指定し、一部の管理タスクを委譲できると案内されています。
この記事では、Group Managersで何が変わるのか、なぜ生成AIの管理が複雑になるのか、そしてChatGPT Enterpriseを現場で無理なく回すには何を設計すべきかを、情報システム部門長、IAM責任者、ChatGPT管理者、内部統制担当者向けに整理します。
「権限委譲で楽になる」は半分正しい
今回、多くの企業担当者が注目したのは、「中央管理だけでは回らない」という現実にOpenAIが機能で応え始めた点です。部署ごとに利用者数が増えると、全員分の設定や問い合わせを情シスだけで抱えるのは難しくなります。
そこで、部門管理者に一部の管理作業を任せる発想が出てきます。実際、OpenAIの説明でも、Group managerは特定グループに対する一部の管理タスクを担う位置づけです。
ただし、ここで見落としやすいのが「作業」と「責任」は同じではないことです。設定変更の手間は部門に分散できても、社内統制や監査対応の責任は本部側に残りがちです。
Workspace管理の考え方や役割の整理は、OpenAIのメンバー管理ガイドも確認しやすい入口です。
つまり、Group Managersは運用を分担する機能であって、ガバナンスを自動で簡単にする機能ではありません。このズレを理解しないまま導入すると、「申請は減ったのに確認事項は増えた」という事態が起きます。
Group Managersで移せる運用と移せない責任
ChatGPT Enterpriseのような法人向け生成AIでは、現場が求めるのはスピードです。新しいメンバー追加、グループごとの利用設定、部門単位の管理などは、現場責任者が直接動けると早くなります。
ここはGroup Managersの価値が出やすい部分です。OpenAIのHelp Centerでも、Group managerの指定はWorkspaceのロール自体を変えるものではなく、対象グループに対する委譲設定として扱われています。
一方で、移しにくいのは「その設定を許してよいのか」という判断です。たとえば、仮に部門別にモデル利用ポリシーを分ける運用をする場合、業務上の必要性、扱う情報の機密度、出力内容の検証責任まで見なければいけません。
セキュリティや統制面の確認先としては、OpenAIのTrust Portalも参考になります。
要するに、アカウント管理の一部は委譲できても、リスク評価や全社基準の説明責任までは簡単に委譲できません。情シスやガバナンス担当の負担が残る理由はここにあります。
負荷の本体は申請対応ではなく例外の正当化にある
多くの企業では、運用負荷の中心は単純な申請処理ではありません。本当に重いのは、「なぜこの部門だけ例外を認めたのか」を説明できる状態に保つことです。
これはAIニュースの表面だけ見ていると気づきにくい、実務上の核心です。
たとえば、一般的な生成AI運用の例として、全社標準では一部のモデルのみ許可しつつ、開発部門ではより高機能なモデルの利用を求める、法務は外部送信に厳しい制限をかけたい、営業はスピード重視で柔軟な利用を求める、といった差が出ます。
そのたびに、例外の理由、承認者、期間、見直し条件を残す必要があります。AIガバナンス全体を考えるうえでは、NISTのAI Risk Management Frameworkも参考になります。
例外が増えるほど、運用は「誰でも使える仕組み」から「条件付きで許可する仕組み」へ変わります。すると手間の中心は申請受付ではなく、例外の妥当性を継続的に証明することへ移っていきます。
営業・法務・開発でぶつかる部門別モデル許可ポリシー
具体例で考えると分かりやすいです。営業部門は提案書の下書きや要約を素早く作りたいので、使いやすさと応答速度を重視します。
開発部門はコード生成や技術検討で、より高機能なモデルを求めるかもしれません。法務部門は、誤回答や機密情報の扱いに特に慎重になります。
このとき、全社で同じモデル許可ルールを当てると、誰かには過剰で、誰かには不足になります。逆に、部門ごとに細かく最適化すると、今度は管理ルールが増えすぎます。
比較の視点としては、MicrosoftもCopilot関連ドキュメントで、企業向けAIでは機能だけでなく管理設計が重要になることを示しています。
つまり衝突の原因は、現場のわがままではなく業務要件の違いです。Group Managersはこの違いを現場に近い場所で処理しやすくしますが、その結果としてポリシー差分の管理が前面に出てきます。
権限委譲が進むほど監査項目が増える理由
権限を中央に集めている間は、確認先が少ないぶん監査は単純です。しかし権限委譲が進むと、「誰が」「どのグループに」「どの条件で」「いつ許可したか」を後から追える必要が高まります。
これが監査項目の増加につながります。
特に生成AIは、利用モデルの違いが出力品質だけでなく、利用ルールや業務プロセスにも影響します。そのため、アクセス権の監査だけでは足りず、モデル利用方針、例外承認、定期見直し、教育履歴まで見たくなります。
AIマネジメントの考え方としては、ISO/IEC 42001の情報も参考になります。
https://www.iso.org/standard/81230.html
ここで重要なのは、監査項目が増えること自体が悪いわけではない点です。問題は、増えた項目を人手の確認で回そうとすると、情シスが再び詰まることです。
AIニュースを読む際も、新機能の追加だけでなく、記録と見直しの設計まで見ておく必要があります。
ChatGPT Enterpriseを軽くしない運用を避ける3層設計
実務では、運用を3層で分けると整理しやすくなります。第1層は全社共通ルールです。
たとえば、禁止情報、共通の監査ログ要件、最低限の利用教育などは中央で固定します。OpenAIの利用ポリシーや安全性の考え方も、禁止事項や安全上の最低ラインの参照先になります。
https://openai.com/policies/usage-policies/
第2層は部門裁量の上限です。どの範囲まで部門管理者が設定変更できるかを先に決めます。ここが曖昧だと、委譲したはずなのに毎回本部確認が発生します。
第3層は例外承認フローです。例外はゼロにできない前提で、申請条件、承認者、期限、失効後の見直しを標準化します。
この3層があると、情シスは「全部を自分で処理する役割」から、「ルールの土台と監査しやすい仕組みを作る役割」へ移れます。
行動直前の段階にある担当者は、中央管理項目、部門委譲項目、例外承認項目の3区分で、設定変更者、監査確認者、証跡保存先を整理した委譲管理台帳を先に作ると、導入後の監査負荷を見積もりやすくなります。
Group Managersの価値は、機能単体より、この分業設計と一緒に導入したときに最も出やすいです。