情シスとAI推進がつまずく OpenAI旧Apps・Marketplace・Plugins整理で例外申請が止まらない理由
OpenAI管理機能が増えても、部門ごとの例外申請や重複許可が再発する背景
旧Plugins時代の接続管理や、現在のChatGPTワークスペースにおけるGPTs・Actions・権限設定の管理を強めれば、運用はすっきりする。そう考える企業は多いはずです。ですが実際には、OpenAIの管理機能が増えた後でも、旧Apps・Marketplace・Pluginsをまたぐ整理を始めたあとに、むしろ部門ごとの例外申請や重複許可が増える場面が見られます。
本記事では、旧Plugins時代の管理と、現在のChatGPTワークスペースにおけるGPTs・Actions・権限設定の管理を分けて考えます。両者をまとめて扱うと、統制単位がずれやすいためです。
この記事では、なぜ管理強化が逆に複雑化を招くのかを、OpenAI管理者、情報システム部門長、IAM責任者、内部統制担当者にも分かりやすいよう、情シスとAI推進の視点から整理します。ポイントは、ツール数の多さではありません。分類基準、責任分界、承認フローがずれたまま管理を始めると、申請業務が常態化しやすいのです。
制度変更や管理機能の確認では、OpenAIの公式アップデートを起点にするのが有効です。たとえば、OpenAI公式のGPTs紹介は、少なくともGPTsとGPT Storeという呼称を確認する参考になります。
https://openai.com/index/introducing-gpts/
管理を強めたのに、なぜ例外申請だけが増えるのか
結論から言うと、管理対象が整理されたように見えても、現場の利用実態はその分類どおりに動かないからです。情シスは「どの仕組みに属するか」で見ますが、現場は「仕事が進むか」で使い分けます。
この視点差が、例外申請の温床になります。
たとえば、ある部門では社内承認済みの機能だけで足りる想定でも、実務では外部連携や既存ワークフローとの接続が必要です。すると、制度上は整理済みでも、運用上は未整理のケースが次々に出ます。
結果として、例外申請が「特別対応」ではなく、日常業務になってしまいます。
OpenAIのビジネス向け管理機能やワークスペース設計の考え方は、現行の管理者向け情報を見ると理解しやすいです。利用者と管理者で見えている単位が異なることが、運用摩擦の背景にあります。
https://help.openai.com/en/articles/8801848
旧Apps・Marketplace・Pluginsと現行のGPTs／GPT Store／Actionsが混線しやすい3つの理由
1つ目は、名称や提供形態が変わっても、現場から見ると「使いたい機能の入口」に見えることです。管理側は旧Apps・Marketplace・Pluginsと現行機能を切り分けたくても、利用者は連続した体験として認識します。
そのため、制度上の境界がそのまま運用境界にはなりません。
2つ目は、導入時期ごとに承認ルールが違うことです。以前は許容されていた接続や利用方法が、管理開始後には再審査対象になる場合があります。
すると、過去の利用資産が「グレーな既存運用」として残り、整理が終わっても申請が繰り返されます。
3つ目は、責任者が機能単位・データ単位・契約単位で分かれやすいことです。情シス、セキュリティ、法務、事業部の判断軸がそろわないと、同じ案件でも承認の入口が毎回変わります。
これが、部門ごとの例外申請や重複許可の再発を止めにくくする大きな要因です。
管理と統制の考え方は、SaaS管理全般でも共通しています。たとえばNISTのAIリスク管理フレームワークは、技術だけでなく運用責任の分担を見るうえで参考になります。
複雑化の本体はツール数ではなく、分類基準と責任分界の設計不整合にある
ここで重要なのは、問題を「機能や接続先が多いから」と単純化しないことです。本当に運用を重くしているのは、何を誰がどの基準で承認するのかが固定されていない点です。
ツール数を減らしても、この設計が曖昧なら例外は減りません。
たとえば「社外送信があるか」で審査する部門と、「顧客情報を扱うか」で審査する部門では、同じ利用申請でも結論がぶれます。さらに、AI推進チームは活用速度を重視し、情シスは統制可能性を重視します。
このズレを埋めないまま制度だけ先に作ると、承認フローが細るのではなく枝分かれします。
初級の整理として言い換えると、これは「本棚の問題」ではなく「ラベルの貼り方の問題」です。本を減らしても、分類ルールと管理者がばらばらなら探しやすくはなりません。
AIニュースとして見ると地味ですが、実務ではこの設計差が最も大きな負担になります。
OpenAIの利用ポリシーや管理条件を確認するには、公式ポリシーも参照価値があります。運用判断を現場の感覚だけに委ねないためです。
https://openai.com/en-GB/policies/usage-policies/
一度整理しても、例外申請が戻る再発パターン
典型例は、全社標準を決めた直後に、営業・開発・管理部門それぞれから別方向の要望が出るケースです。営業は顧客対応速度を理由に追加機能を求め、開発は検証用の自由度を求め、管理部門は監査証跡を求めます。
標準化したはずなのに、導入初期の1か月ほどで例外枠が増えることがあります。
もう1つは、既存運用の棚卸しが「契約」中心で終わっているケースです。契約上は整理できても、実際の利用フローや担当者依存の運用が残っていると、現場はすぐに迂回策を探します。
その結果、「禁止したのに別ルートで使われる」「許可済みなのに再申請が必要になる」といった二重管理が発生します。
実際、SaaSガバナンスの失敗例では、可視化不足に加えて、例外処理の設計不足が一因になりやすいです。承認ルールと利用実態のズレを埋める設計がないと、管理を強めても運用は安定しません。
部門運用を壊さない承認フローは、例外前提で設計する
対策の出発点は、例外をゼロにすることではありません。どの条件なら簡易承認に落とせるか、どの条件なら部門判断で閉じられるかを先に決めることです。
つまり、通常フローより先に「例外の交通整理」を設計します。
実務では、少なくとも3層に分けると運用しやすくなります。
- 第1層は全社共通で即時判断できるもの
- 第2層は部門責任者が判断するもの
- 第3層は法務やセキュリティを含む個別審査
この線引きがあるだけで、「とりあえず情シスに聞く」が減ります。
加えて、申請フォームの項目も見直すべきです。製品名ではなく、外部送信の有無、扱うデータの種類、利用目的、代替手段の有無を聞く形にすると、旧Apps・Marketplace・PluginsとGPTs・Actionsの名称差に引きずられにくくなります。
分類を製品軸からリスク軸へ寄せることが、再発防止に効きます。
運用設計のヒントとしては、Microsoftの生成AI管理やCopilotガバナンスの資料も比較対象になります。AI機能そのものより、権限・データ・監査の管理単位をどう切るかが重要だからです。
統制を効かせながら現場を止めないために、3区分の例外再発防止表から始める
OpenAIの旧Apps・Marketplace・Pluginsをまたぐ管理で苦しくなる企業は、管理を始めたこと自体が失敗なのではありません。失敗しやすいのは、分類基準、責任分界、承認フローがそろわないまま統制だけを強めた場合です。
例外申請が止まらないのは、現場がわがままだからではありません。制度の設計単位と利用の実態単位がずれているサインです。
ここを見直せば、申請は減らせますし、統制と活用を両立しやすくなります。
まずは、旧Apps、Plugins、Marketplaceの3区分で、例外申請理由、承認履歴、廃止条件を棚卸しした例外再発防止表を作成してみてください。誰が、どの条件で、いつまで例外を認めるのかを見える化するだけでも、情シスに集中する相談や重複許可はかなり整理されます。
AIニュースとして見ると地味でも、実務ではここが一番効く改善点です。