OpenAIのPlugins管理開始、情シスはなぜ先に“重複許可の棚卸し”をすべきなのか
OpenAIのPlugins管理開始で先に見るべきは、解禁機能ではなく旧Apps・Plugins・Marketplaceの許可重複です
OpenAIのApps、Plugins、Marketplace、connectors、administrator-managed appsなど、名称の異なる管理対象は複数あります。この記事では、これらを便宜上「アプリ連携」とまとめて扱います。
2026年10月1日のOpenAI管理機能更新を受けて、多くの企業で最初に気になるのは「どの便利機能を解禁するか」でしょう。ですが、情シスが先にやるべきことは別です。
旧Apps・Plugins・Marketplaceまわりで重なっている許可設定を棚卸ししないまま解禁すると、使える・使えないの判定が揺れ、統制が崩れます。
OpenAIのChatGPT Enterprise/Edu向け更新情報や関連ヘルプを見ると、アプリやコネクタに関する管理導線が複数の案内にまたがっており、管理対象の名称も一様ではありません。こうした導線の並存を前提に、どこで許可重複や監査漏れが起きるのかを先に整理する必要があります。
https://help.openai.com/en/articles/10128477-chatgpt-enterprise-and-edu-release-notes
この記事では、OpenAIの管理変更で何が起きるのか、なぜ旧Apps・Plugins・Marketplaceの許可重複整理が先なのか、そして情報システム部門長・OpenAI管理者・IAM責任者・内部監査担当者が最初に確認すべきポイントを実務的に整理します。
OpenAI公式の更新情報を合わせて確認すると、全体像をつかみやすくなります。
同じ連携を止めたはずなのに使えてしまう、旧Apps・Plugins・Marketplace並存期の二重管理
たとえば、情シスが「この外部サービス連携はまだ未許可」と判断し、ある管理経路では停止したとします。ところが、別の管理経路で許可が残っており、さらに利用者向けの追加導線から一部ユーザーが使えてしまう。現場では、まさにこのような「止めたはずなのに使える」が起こり得ます。
問題は、利用者が悪いのではなく、管理の入口が複数あることです。利用者から見れば「同じような連携機能」でも、管理者から見ると旧Apps、Plugins、Marketplaceで許可の持ち方が違う場合があります。このズレが、問い合わせ対応を一気に難しくします。
OpenAIのヘルプには、administrator-managed apps などの管理に関する案内があります。新しい管理画面や導線が追加されても、既存設定との関係を確認しながら運用する前提で見たほうが安全です。
https://help.openai.com/en/articles/10847137-administrator-managed-apps-with-sync-in-chatgpt
今回の管理変更で変わるのは、便利さよりも許可経路の見え方と比較の難しさです
今回の変化は、単に機能が増える話ではありません。管理者にとって重要なのは、「どこで何を許可しているのか」が以前より見えにくくなる可能性があることです。
便利機能の追加は利用者には前向きですが、情シスには許可経路の再確認が必要になります。解禁そのものより、どの設定が実際の利用可否に効いているのかを先に整理しないと、運用で混乱が広がります。
特に生成AIの運用では、1つの機能が複数の名前や提供単位で見えることがあります。これが権限設計を複雑にします。
たとえば、ある機能が旧Appsとして見えるのか、Pluginsとして見えるのか、Marketplace上の導線として見えるのかで、社内の説明資料や申請フローまで変わることがあります。
生成AIの統制全体を考えるなら、NISTのAI Risk Management Frameworkも参考になります。NISTはAIの利用において、機能そのものよりもリスク管理、役割、責任の明確化を重視しており、この視点はOpenAIの許可設計を考える際にも相性がよいです。
旧Apps・Plugins・Marketplaceは、名前ではなく許可単位と担当の違いで比較する
ここで重要なのは、名前の違いではなく、許可の単位がどこにあるかです。この記事では便宜上、名称の異なる管理対象を、既定許可、例外申請、棚卸し担当という観点で比較して整理します。
つまり、同じ外部連携でも「掲載されている場所」と「実際に許可される場所」が一致しないことがあるのです。ここを混同すると、情シスは一覧上では禁止したつもりでも、別経路の設定が残ります。
OpenAIのヘルプはconnectorsの管理に関する説明をしており、外部連携の利用可否が管理設定と結びつくことは確認できます。詳細な依存関係は個別の仕様確認が必要ですが、見た目以上に管理対象が分かれる可能性は意識しておくべきです。
外部SaaS連携の管理がなぜ難しいかは、Microsoftの管理ドキュメントを見ると感覚をつかみやすいです。製品は異なりますが、アプリ承認・接続許可・利用導線が分かれると、重複管理が起きやすい点は共通しています。
先にとりあえず解禁すると、監査・問い合わせ・設定変更が同時に重くなります
便利そうだから先に解禁する。これは現場ではよくある判断です。ただ、OpenAIのように機能追加が速いサービスでは、この判断があとで大きな運用負債になります。
理由は、監査・問い合わせ・設定変更の3つで差し返しが増えやすいからです。
まず監査では、「誰が、どの画面で、何を許可したのか」の説明が求められます。次に問い合わせでは、「Aさんは使えるのにBさんは使えない」といった差分が発生します。
さらに設定変更では、1か所を直しても別経路で権限が生きている可能性があり、影響調査に時間がかかります。ここで苦しくなるのは、機能の多さそのものではなく、許可構造の不一致です。
SaaSガバナンスの領域でも、こうした問題は以前から論点になってきました。Cloud Security Allianceでも、SaaS利用の統制や姿勢管理に関する情報を公開しており、接続経路と管理責任のズレが運用負荷を増やす構図は共通しています。
棚卸しは全件調査から始めず、3区分で許可統合表を作る
棚卸しは、細かい全件調査から始める必要はありません。最初は旧Apps・Plugins・Marketplaceの3区分で、既定許可、例外申請、棚卸し担当を並べたアプリ許可統合表を作るほうが実務的です。
- 同じ機能が旧Apps・Plugins・Marketplaceのどの経路で許可されているか
- 各区分で重複設定があるか
- その例外を誰が承認し、誰が棚卸し担当なのか
この順で見ると、単なる設定一覧ではなく、運用責任の所在まで確認できます。特に例外承認は重要です。
過去の実証実験や部門要望で一時的に開けた設定が、そのまま残っていることは珍しくありません。こうした残存設定は、監査時にも問い合わせ時にも説明コストを増やします。
権限や責任の整理という観点では、NIST AI RMF 1.0の考え方も参考になります。組織内で役割と責任の線引きを明確にすることが、AI運用では基礎になると整理されています。
社内台帳の作り方に迷う場合は、CIS Controlsの考え方も役立ちます。資産の可視化と権限管理を分けて整理すると、AIツールでも棚卸しがしやすくなります。
CIS
解禁前に決めるべき最小ルールは、正本の管理経路を1つにし、3区分の許可統合表を持つことです
結論として、情シスが最初に決めるべきなのは「何を解禁するか」ではなく、「どの経路の許可を正とみなすか」です。正本となる管理経路を決めておけば、例外申請も監査説明も一気に楽になります。
完璧な統制を目指すより、まずは判断基準を1本化することが現実的です。ここが曖昧なまま機能解禁を進めると、後で設定差分の説明に追われます。
おすすめは、解禁前に最小ルールを3つだけ定めることです。
- 許可の正本画面を決める
- 同一機能の重複許可を禁止する
- 例外は期限付きで記録する
この3つだけでも、運用負荷はかなり下がります。OpenAIの管理機能が広がるほど、設定を増やすことより、判断基準を減らすことのほうが効いてきます。
次の行動としては、旧Apps・Plugins・Marketplaceの3区分で、既定許可、例外申請、棚卸し担当を1枚で比較できるアプリ許可統合表を作成してください。行動直前の段階では、この1枚が許可重複の発見と監査漏れ防止の起点になります。
OpenAIのAIニュースは今後も変化が速いはずです。だからこそ、便利機能の追加に追われる前に、許可構造を整理しておく価値があります。
派手な作業ではありませんが、ここを先にやる企業ほど、後から運用が軽くなります。地味ですが、情シスの腕の見せどころです。