
はじめに
ChatGPTやClaudeを業務で使い始めると、管理者の間で必ず話題になるのが「外部ツール連携をどこまで許可するか」です。
Google DriveやSlack、GitHubとAIを接続すれば、業務はかなり効率化できます。その一方で、接続先を誰が追加できるのか、AIにどこまで操作させるのか、いざというときに管理者が止められるのか、といった統制面の課題も出てきます。
特に判断が難しいのが、CodexやClaude Codeのように利用者の端末で動くエージェント(以下、ローカルエージェント)です。端末上での実行をどこまで認め、認めた場合に何を制限できるのか。ここを整理しないまま利用を解禁するのは危険です。
ところが、公式ドキュメントは製品ごとに分かれていて、両者を並べて比較した情報はほとんど見当たりません。用語も管理画面の構成も異なるため、比べるだけでも手間がかかります。そこで本記事では、ChatGPT BusinessとClaude Teamの管理機能を横断的に比較し、管理者が制御できる範囲とその限界、運用上のポイントを整理しました。
結論 Web版のApp/コネクタ管理に限れば、ChatGPT BusinessとClaude Teamのどちらも管理画面から十分に統制できます。 差が出るのは、CodexやClaude Codeを業務端末で使う場合です。 ポイントは「管理者が決めた設定を、どれだけ手間をかけずに端末へ配布できるか」です。なお、利用者に設定を変更させない強制力については、どちらの製品も単体では保証できません。
要点を表にまとめると、次のとおりです。
| 比較の観点 | ChatGPT Business | Claude Team |
|---|---|---|
| Web版のApp/コネクタ管理 | ○ 管理画面で統制できる | ○ 管理画面で統制できる |
| 端末への設定配布 | △ 手動配置が前提 | ○ サーバーから配布できる |
| 配布した設定の強制力 | △ 製品単体では保証されない | △ 製品単体では保証されない |
両者の差が出るのは「端末への設定配布」だけで、「配布した設定の強制力」はどちらも条件付きです。
本記事では、Web版の管理画面で禁止できることと、端末上で強制できることは別物という視点で、両者の制御の仕組みを比べていきます。
片方の製品しか使っていない場合でも、もう一方と比べておく意味はあります。他社の製品にできて自社で使っている製品にできないことが分かれば、その差を運用ルールで補うのか、そもそも許可しないのかを前もって判断できるからです。
対象読者と扱う範囲
- ChatGPT BusinessまたはClaude Teamの管理者として、どこまで制御できるのかを把握したい方
- 社内向けに生成AIの利用ルールを設計する情報システム部門・セキュリティ担当の方
- CodexやClaude Codeを業務端末で使わせる前提で、制御の勘所を知りたい方
なお、どちらの製品を採用すべきか、価格やモデル性能の比較、ChatGPT・Claudeの基本機能の解説は扱いません。
前提と用語
- 対象プランはChatGPT BusinessとClaude Teamです。比較のため上位プラン(ChatGPT Enterprise / Claude Enterprise)にも触れます。
- 外部サービスへの接続機能は、公式名称に合わせてChatGPT側を「App」、Claude側を「コネクタ」と表記します。
- 記載内容は2026年9月時点の各社公開ドキュメントに基づきます。この領域は数か月単位で仕様が変わるため、導入判断では本文中の公式ドキュメントで最新の記載をご確認ください。
本文で繰り返し出てくる用語だけ、先に揃えておきます。
| 用語 | 意味 |
|---|---|
| App/コネクタ | 外部サービスとの接続(ChatGPTでは「App」、Claudeでは「コネクタ」) |
| Skill | AIに与える手順・知識 |
| Plugin | SkillやAppなどをまとめて扱う配布単位 |
| MCP | AIと外部ツールをつなぐ共通仕様(Model Context Protocol)。サーバー経由のリモート接続にも、利用者端末で動くローカル接続にも使われる |
| ローカルエージェント | CodexやClaude Codeのように、利用者の端末上で動き、ファイル操作やコマンド実行を行うAI |
| Computer Use | AIが画面の内容を認識し、マウス・キーボード操作でデスクトップアプリやブラウザを直接操作する機能 |

※ ChatGPT側では2026年7月9日にアプリディレクトリがPluginディレクトリへ統合され、PluginはSkill・App・Appテンプレートをまとめた配布単位として整理されています。詳細はPlugins in ChatGPT and Codex(OpenAI Help Center)を参照してください。
管理範囲は「Web」と「利用者端末」の2つ
管理者にとって、外部連携は「つなぐ/つながない」の二択ではありません。管理すべき対象は、大きく2つの領域に分かれます。

1つ目はWeb版の管理です。App/コネクタの利用可否、接続先を追加できる人、読み取り・書き込みといったアクションの範囲を決めれば、この領域は管理画面でほぼ完結します。
2つ目は利用者端末の管理です。CodexやClaude Codeを業務端末で使うと、管理の焦点は「AIがどのSaaSを見られるか」から「利用者の端末で何を実行させるか」に移ります。対象になるのは、ローカルファイル、コマンド実行、MCP、Skill、Computer Useなどです。この領域は生成AIの管理画面だけでは完結せず、設定ファイルとその配布方法が管理の中心になります。
この2つの領域を製品ごとに整理したのが次の図です。

Web版の外部連携:両者に大きな差はない
Web版の外部連携は、どちらの製品も基本的な流れはほぼ同じです。

注意したいのは、AIに接続しても利用者の権限が広がるわけではないことです。たとえばSlackを接続しても、利用者が本来閲覧できないチャンネルがAIから見えるようになることはありません。接続先サービス側のアクセス権限はそのまま有効です。
そのうえで、管理者が確認すべき点は次の3つです。
Web版で押さえる3点
- 誰が接続先を追加できるか — どちらの製品も、新しい接続を追加できるのは管理者だけです。MCPを使った独自の接続も同様です。Claude Teamでは、OwnerまたはPrimary Ownerが組織設定から追加し、その後に利用者が各自で認証します。
- どこまで操作させるか — どちらの製品にも、読み取りのみに制限する設定があります。たとえばClaude Teamでは、コネクタごとに組織全体のアクション範囲を指定でき、個人がこれを上書きすることはできません。どちらの製品でも範囲を決めるのは管理者で、利用者が自分で制限を緩めることはできません。ただしSkillは例外です。Claude Teamで組織に配布したSkillは全員に対して既定で有効になりますが、利用者が個別にオフにできます。
- 止めたい機能をすべて止められているか — Plugin、App/コネクタ、Skillは、どちらの製品でも別々の管理項目です。ChatGPTでは、Pluginの可用性とインストールはPluginの項目で、各Appのアクセスや権限はAppの項目で設定します。既定値もプランによって異なり、BusinessワークスペースではAppが既定で有効、Enterprise/Eduワークスペースでは既定で無効です。ClaudeでもSkillは組織設定の別画面で管理します。1つを止めても他は動き続けるので、ChatGPT BusinessならPlugin・App・Skillの3項目、Claude Teamならコネクタ・Skill・組織管理下のPluginをそれぞれ確認してください。
3つとも確認すべき観点は共通で、違うのは設定する場所と項目名くらいです。
設定の場所と公式ヘルプ
画面の表示名は変わることがあるため、実際の操作は各公式ヘルプで確認してください。
| 確認すること | ChatGPT Business | Claude Team |
|---|---|---|
| App/コネクタの有効化 | Workspace settings > Plugins(ワークスペースによってはAppsの管理ページも残っている)(Admin controls, security, and compliance for plugins and apps) | Organization settings > Connectors(Use connectors to extend Claude’s capabilities) |
| アクション範囲の制限 | Workspace settings > Plugins で対象のPluginを開き、同梱AppのActionsを設定(Admin controls, security, and compliance for plugins and apps) | Customize > Connectors で対象のコネクタを開き、Tool permissionsを設定(Use connectors to extend Claude’s capabilities) |
| 独自接続(リモートMCP) | Workspace settings > Apps > Create(開発者モードで作成し、Workspace settings > Apps から公開)(Developer mode and MCP apps in ChatGPT) | Organization settings > Connectors(Get started with custom connectors using remote MCP) |
| Pluginの管理 | Workspace settings > Plugins(Plugins in ChatGPT and Codex) | Organization settings > Plugins & skills(Manage plugins for your organization) |
| Skillの管理 | Workspace settings > Skills(Skills in ChatGPT) | Organization settings > Plugins & skills(Provision and manage skills for your organization) |
差が出るのは、次に説明する利用者端末の領域です。
利用者端末の管理:ここで差が出る
App/コネクタは管理画面で管理できますが、CodexやClaude Codeの挙動やローカルのSkillは、基本的に設定ファイルで管理します。設定キーの名前や優先順位は各社の公式リファレンスにまとまっているので、ポリシーを設計する前に一度目を通しておくと迷わずに済みます。
- ChatGPT(Codex):Configuration Reference(config.toml)、Managed configuration(requirements.toml)、Build skills
- Claude(Claude Code):Claude Code settings(settings.json / managed-settings.json)、Configure server-managed settings
ChatGPT Business + Codex
Codexをローカル環境で使う場合、ファイルの読み書きやコマンド実行、MCPの利用に加えて、Computer Useのようなデスクトップ操作も管理対象になることがあります。AIが操作できる範囲がファイルやコマンドから画面全体に広がるため、許可するなら、どこまでの操作を認めるかを他の項目とは分けて決めておく必要があります。
OpenAIはmanaged configuration(requirements.toml)という仕組みを提供しています。権限プロファイル、承認の挙動、ファイルシステムやネットワークへのアクセス、MCPサーバーの許可リスト、Hooks、コマンドルールなどを管理者側から強制できるものです。管理画面で登録した設定が、ChatGPTでサインインした利用者のCodexに配布される仕組みです。対象プランについて、公式ドキュメントのConfiguration Reference(requirements.toml)には「ChatGPT BusinessおよびEnterpriseの利用者は、クラウドから取得した管理設定(requirements)も適用できる」と記載されており、EnterpriseだけでなくBusinessも対象とされています。
注意:筆者の検証環境では、Businessで配布した設定が適用されませんでした。 Businessワークスペースの管理画面で管理設定を登録すること自体はできました。しかし、Codex CLI 0.157で確認したところ、登録した設定は端末側に適用されませんでした。Codexの内部では、ChatGPT Businessのアカウントはプラン種別(planType)がteamとして扱われます。ところが、Codex CLI 0.157のソースコードを見ると、管理設定を取得する対象プランの判定にteamが含まれておらず、この場合は取得処理そのものがスキップされます。これが原因だと考えています。ただし、これは筆者の検証とソースコードの確認にもとづく見解で、OpenAIによる公式な説明ではありません。今後のバージョンで改善される可能性があるため、利用する場合は検証端末で設定が実際に適用されるかを確認してください。
そのため本記事では、Businessについては引き続き、管理者が設定ファイルを用意し、利用者に配置してもらう運用を前提とします。プランごとの仕様は変わりやすい部分なので、導入前に最新のドキュメントと実際の動作を確認することをお勧めします。
Claude Team + Claude Code
Claude Codeでは、TeamとEnterpriseでserver-managed settingsを利用できます。管理画面で設定したポリシーを、Claude Codeが起動時にサーバーから取得する仕組みです。利用者に設定ファイルを配置してもらわなくても、組織のポリシーを全員に適用できます。
配布できる設定の例は次のとおりです。
- 特定コマンドの許可・拒否・確認(allow / deny / ask)
- 特定ファイルへのアクセス制限
- MCPの利用方針
- 権限バイパスモードの禁止
- Hooksや環境変数の設定

ただし、すべての設定が同じように適用されるわけではありません。シェルコマンドの設定やカスタム環境変数など一部のカテゴリは、端末側で承認されてから有効になります。
また、この仕組みは強制力を保証するものではありません。Anthropicはserver-managed settingsを、セキュリティ境界ではなく、クライアント側の制御と位置づけています。ポリシーを配布できても、利用者がそれを外せないとは限りません。利用者は管理者権限やsudoがなくても、環境変数の設定などで適用を回避できる場合があります。
両者の差をどう読むか
まとめると、両者の差は「配布のしやすさ」にあり、「強制力の強さ」にはありません。利用者に設定ファイルを配置してもらわなくてもポリシーを行き渡らせられるのは運用面で大きな利点で、ここがClaude Teamの実質的な強みです。
一方で、利用者が意図的に設定を外す場合まで防ぎたいなら、どちらの製品も設定の配布だけでは足りません。どちらの方式を採用する場合も、導入前に検証端末で実際にどう適用されるかを確認しておくことをおすすめします。
比較表
冒頭の表を、ここまでの内容をもとに詳しくしたのが次の表です。
表の凡例:○=管理できる/△=条件付き(2026年8月時点)
| 領域 | 管理観点 | ChatGPT Business | Claude Team |
|---|---|---|---|
| Web | App/コネクタの許可 | ○ | ○ |
| Web | 外部アクションの制限(読み取りのみなど) | ○ | ○ |
| Web | 組織管理下のPlugin/Skillの管理 | ○ | ○ |
| 利用者端末 | ローカルエージェントへの設定配布 | △(手動配置が前提。managed configurationはBusinessも対象と記載されているが、筆者の検証では適用されなかった) | ○(Teamからサーバー配布が可能。一部の項目は端末側の承認が必要) |
| 利用者端末 | 配布した設定の強制力(利用者が外せないか) | △(手動配置のため、利用者による変更を製品単体では防ぎにくい) | △(サーバー配布はクライアント側の制御のため、利用者による回避を防ぎきれない) |
なお、Skillの扱いには注意が必要です。組織管理下のPluginや、それに同梱されたSkillは管理画面で扱えますが、ローカル環境に置かれたSkillは設定ファイルで管理する対象です。すべてのSkillを中央で管理できるわけではありません。
この差がどれほど影響するかは、自社での使い方とIT運用の体制によって変わります。Web版だけを使うなら、App/コネクタの許可とアクションの制御を押さえておけば十分で、利用者端末側の差はほとんど関係ありません。CodexやClaude Codeを開発者に使わせるなら、MCP、ローカルファイル、コマンド実行、Skill、さらに製品が対応していればデスクトップ操作まで含めて、端末側のポリシーを設計する必要があります。
まとめ
今回の調査で一番苦労したのは、仕様そのものではなく用語と管理画面の構造でした。Claudeでは正式名称である「コネクタ」という言葉が、ChatGPTではAppの接続機能を指して使われています。同じものが違う名前で呼ばれ、違うものが同じ名前で呼ばれているわけです。
遠回りの原因は、両者の用語を1対1で対応づけようとしたことでした。ChatGPTではGoogle DriveをPluginから追加したので、Claudeでも同じようにPluginを探し、見つからずに困りました。実際には、Claudeではコネクタを追加するだけで済みます。ClaudeにもPluginはありますが、Skillやコネクタをまとめて配布するための機能なので、コネクタを1つ接続するだけなら使う必要はありません。同じ名前の機能が両方にあっても、目的によってたどる手順が違うということです。
管理画面の作りも、この混乱に拍車をかけます。ChatGPTではPluginとAppが別の項目として並んでいるのに、カスタムApp(リモートMCP)を追加するとPlugin側にも自動で追加されます。別の項目なのに連動しているため、自分がいまどの設定を触っているのか分からなくなりがちです。
結局のところ、一番の対策はドキュメントを読み込むことではなく、実際に管理画面を開いて、項目名と実際の適用範囲を照らし合わせることです。検証端末を1台用意して、実機でどう適用されるかまで確かめておく。この一手間をかけておけば、その後の運用ルールづくりがぐっと楽になります。
投稿者プロフィール

-
BS事業部の秋田です。
PythonやAWS、Linuxを中心にシステム開発やインフラ設計に携わっています。
日々の業務や学びの中で得た知見をQiitaなどで発信しており、現場で役立つ技術やノウハウをわかりやすく共有することを心がけています。



