プラグインのロール別アクセス管理とは、役割ごとに使えるプラグインを分ける管理機能のことです。
ChatGPT Enterpriseでプラグインを使う事務所が最初に決めるのは、誰に何を使わせるかという線引きです。この記事では、2026年10月に公表された管理機能の更新内容を整理し、士業事務所が職員の役割ごとにプラグインの利用範囲を設計する7つの手順を示します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、ベンダーの仕様はOpenAIの公式ヘルプで確認しています。仕様は更新されるため、導入時は最新のヘルプで再確認してください。
OpenAIの公式ヘルプのリリースノートには、2026年10月1日にAdmin consoleでプラグインとマーケットプレイスを管理できるようになったこと、同年10月8日にRBACが有効なワークスペースでロール別にプラグインのアクセスを管理できるようになったことが記載されています(出典: OpenAI ヘルプ ChatGPT Enterprise and Edu リリースノート)。
2026年10月の更新で何が変わったか
リリースノートによると、10月1日の更新で、Enterpriseのワークスペースオーナーと管理者は、Admin consoleでプラグインとマーケットプレイスを管理できます。Admin consoleのPluginsページでプラグインを、Marketplacesページでワークスペースのプラグインマーケットプレイスを管理します。アプリはこれまでどおりWorkspace settingsの配下に残り、既存の権限とアプリのアクセス制御も引き続き適用されます(出典: OpenAI ヘルプ ChatGPT Enterprise and Edu リリースノート)。
10月8日の更新では、RBACが有効なワークスペースに限り、オーナーと管理者がロール別にプラグインのアクセスを管理できます。ワークスペースの既定値はAvailable、Install、Disabledのいずれかを選べ、カスタムロールはその設定を使うか、ワークスペースの設定を継承します。プラグインのアクセスと、関連する必須アプリの権限は、まとめて確認して保存する仕組みです。既存のアプリ操作の設定、承認要件、提供元の認可も引き続き適用されます(出典: 同上)。
ここで押さえたいのは、権限の変更は新しい機能が増えたというより、管理の置き場所と粒度が変わったという点です。事務所の運用は、管理者の画面が変わることで見直しの機会を迎えます。RBACが有効でないワークスペースでは、ロール別の設定は使えません。契約プランや管理設定の前提は、事務所ごとに要確認です。
士業事務所の役割を権限の単位に置き換える
士業事務所の職員は、役割がはっきり分かれています。たとえば少人数の税理士事務所なら、所長税理士、有資格者のスタッフ、記帳を担う事務スタッフ、外部委託のパートという構成が考えられます。ロール別の管理は、この役割の違いをそのまま権限に写す作業です。
最初の手順は、事務所の役割を棚卸しすることです。肩書きではなく、扱う情報の種類で分けます。顧問先の財務データを扱う人、従業員の個人情報や賃金を扱う人、書面の最終確認をする人、情報を扱わない広報担当、というように整理します。
権限設計の7手順
手順1 役割ごとに扱う情報を書き出す
役割の表を作らずに、段落で整理します。所長は全顧問先の情報を扱います。有資格者のスタッフは担当顧問先の情報を扱います。事務スタッフは入力や整理の作業の範囲に限られます。この整理が、ロール別設定の根拠になります。
手順2 プラグインを業務への関わりで分類する
使いたいプラグインを、外部に情報を送るもの、事務所内の文書だけを扱うもの、情報を読むだけのものに分けます。外部に情報を送るプラグインは、守秘義務との関係が最も重くなります。Admin consoleのPluginsページで、導入済みと候補のプラグインを一覧にして確認します。
手順3 ワークスペースの既定値を最も狭くする
リリースノートが示す既定値の選択肢は、Available、Install、Disabledです(出典: OpenAI ヘルプ ChatGPT Enterprise and Edu リリースノート)。各選択肢の細かな挙動は、管理画面の説明で確認してください。考え方としては、既定をDisabledのような狭い側に置き、必要なロールにだけ広げる運用が、設計の見通しを保ちます。広い既定から狭める運用は、例外が積み重なり、全体像が追えなくなります。
手順4 カスタムロールを少数に保つ
ロールを細かく作りすぎると、管理者の負担が増えます。小規模な事務所では、所長、有資格者、事務スタッフ、外部委託の四つ程度から始め、運用して不足が出たら増やします。ロールの数は、管理者がひとりで把握できる範囲を目安にします。
手順5 必須アプリの権限を一緒に確認する
プラグインのアクセスと、関連する必須アプリの権限は、まとめて確認して保存する仕組みです(出典: 同上)。プラグインを許可すると、裏でどのアプリへの権限が必要になるのかを、保存の前に確認します。許可した覚えのない範囲が含まれていないか、画面で目視します。
手順6 試験運用の対象を絞る
全職員に一斉に展開せず、まず有資格者ひとりと事務スタッフひとりで試します。ここで見るのは、プラグインの動作ではなく、権限が意図どおりに働いているかです。使えるはずのないロールで使えてしまわないか、逆に必要な人が使えないか、確認します。
手順7 定期的に見直す記録を残す
設定を変えた日、変えた人、理由を台帳に残します。担当者が退職したときのアカウント整理や、契約プランの変更時の再確認も、見直しの機会です。ここでは次のプロンプトが、設定内容の点検メモを整える補助になります。
以下は、ある事務所のプラグイン利用権限の設計メモです。ロールごとに、許可するプラグイン、許可する理由、取り扱う情報の種類を整理してください。メモに書かれていない項目は推測せず「要確認」と書いてください。評価や提案は不要です。
【メモ】
(ここに匿名化した設計メモを貼り付ける。顧問先の実名は入れない)
もう一つは、更新内容を事務所内で共有するための要約用です。
以下は、ベンダーの管理機能の更新に関するリリースノートの抜粋です。管理者が確認すべき設定項目と、事務所の運用ルールの見直しが必要になり得る箇所を、箇条書きではなく短い段落で整理してください。原文にない仕様は書かないでください。
【抜粋】
(ここにリリースノートの該当部分を貼り付ける)
どちらも出力は下書きです。設定を実際に変更する前に、有資格者または事務所の管理責任者が最終確認を行います。
想定事務所で考える ロール設計の具体例
ここでは、架空の税理士事務所を想定して、設計の考え方を段落で示します。所長税理士、担当の有資格者、記帳を担う事務スタッフ、週に数日だけ入る外部委託のパートがいる事務所です。顧問先の多くは中小企業で、月次の記帳と決算、年末調整を扱っています。
所長のロールは、プラグインの追加の承認者を兼ねます。ただし、承認者が自分のロールの権限を広く設定しやすい点は、設計上の弱点です。承認の記録を残し、他の職員が見られる状態にしておくと、設定の偏りに気づきやすくなります。
有資格者のロールは、担当顧問先の資料の整理や、書面の下書き作成を支援するプラグインに限って許可する形が考えられます。書面の最終確認は有資格者の業務であり、プラグインの出力はその前段の下書きという位置づけを、規程の文言にも反映します。
事務スタッフのロールは、記帳や証憑の整理に関わる範囲に絞ります。外部にデータを送る性質のプラグインは、まず許可せず、必要が生じた時点で申請の手順に乗せます。外部委託のパートのロールは、さらに狭く、事務所内の文書だけを扱う範囲から始めます。パートの契約書に秘密保持の条項があるかも、同時に確認しておきます。
設定後に確認する観点
設定を保存した後は、設計と実際の動きが合っているかを確認します。見る観点は三つあります。第一に、許可したロールだけがプラグインを使えているか。第二に、許可していないロールの画面で、プラグインが表示されたり導入できたりしていないか。第三に、プラグインを使った操作の承認要件が、既存のアプリ操作の設定どおりに働いているか。リリースノートは、既存のアプリ操作の設定と承認要件が引き続き適用されると記しています(出典: OpenAI ヘルプ ChatGPT Enterprise and Edu リリースノート)。
確認の結果は、日付とともに台帳に残します。台帳には、確認した人、確認した画面、気づいた差異、対応の内容を書きます。次回の見直しのときに、前回との差分を追えるようにするためです。管理画面の表示や文言は更新されることがあるため、台帳には画面の名称も書いておくと、後から読み返したときに迷いません。
守秘義務・規程上の論点
権限設計の根底にあるのは、各士業法が定める秘密保持の規定です。弁護士法第23条は秘密保持の権利及び義務を、税理士法第38条は正当な理由がなく業務に関して知り得た秘密を洩らし、又は窃用してはならないことを、行政書士法第12条は正当な理由がなく業務上取り扱った事項について知り得た秘密を漏らしてはならないことを、司法書士法第24条は正当な事由がある場合でなければ業務上取り扱った事件について知ることのできた秘密を他に漏らしてはならないことを、社会保険労務士法第21条は秘密を守る義務を、それぞれ定めています。いずれもe-Gov法令検索の原文で確認した条文です。
プラグインが外部サービスと接続する場合、事務所の情報がどこへ送られるかが論点になります。本記事は、特定の利用が各条文にどう関わるかの当てはめを行いません。当てはめは有資格者の判断事項であり、個別の事情で変わります。
事務所規程に落とす際の運用例として、次のような項目が考えられます。許可するプラグインの一覧と許可の承認者、プラグインを追加する際の申請の手順、顧問先の情報を扱うロールの範囲、設定変更の記録の保管、退職や異動時の権限の見直しです。顧問先への説明の要否は、契約書の文言と扱う情報の内容に照らして、事務所で決めておきます。
加えて、ベンダーのデータの取り扱いは、プラグインごとに提供元が異なる場合があります。リリースノートも、提供元の認可が引き続き適用されると記しています(出典: OpenAI ヘルプ ChatGPT Enterprise and Edu リリースノート)。つまり、OpenAIの管理画面で許可しただけでは、提供元側の取り扱いは分かりません。各プラグイン提供元の規約とデータ利用の説明は、個別に確認する対象です。
規程に落とすときは、ツール名を本文に固定しすぎないほうが、更新に耐えます。本文には許可するプラグインは別紙の一覧によると書き、一覧の側を更新する形にすると、プラグインの入れ替えのたびに規程を改定する手間を避けられます。一覧の更新の頻度と承認者だけを、本文で定めておきます。この形は運用例の一つであり、事務所の規模や契約形態に応じて調整してください。一覧を所長が年に数回見直す、という程度の軽い運用でも、記録がない状態よりは状況を追えます。一覧には、プラグイン名、提供元、許可するロール、許可した日、見直しの予定日を並べておくと、棚卸しの際に使いやすくなります。
失敗例と回避策
一つ目は、全員に全プラグインを許可したまま運用が始まる例です。便利さを優先して広く開けると、誰がどの情報をどこへ送れる状態なのか、事務所が把握できなくなります。回避策は、手順3のとおり既定を狭くして、必要な範囲を足すことです。
二つ目は、ロールを作ったものの、実際の人の割り当てが古いままになる例です。退職者や異動者のロールが残り、不要な権限が続きます。回避策は、人事の変更と権限の見直しを同じ手続きに束ねることです。
三つ目は、管理者がひとりに集中し、その人が不在の間に設定が止まる例です。回避策は、管理者をふたり置き、設定変更の記録を共有することです。ただし、管理者の数が増えるほど、管理者自身の権限の扱いが論点になります。
費用・工数・体制
プラグインやRBACを使えるプランと料金は、契約形態によって異なります。本記事では料金の数値を示しません。見積もりと利用可能な機能は、OpenAIまたは販売窓口へ確認することになります(要確認)。
工数の中心は、手順1の役割の棚卸しです。ここは設定画面を開く前に、事務所の側で時間を取って行う作業です。体制としては、所長か管理責任者が方針を決め、実際の設定は事務所のIT担当または外部の支援者が行い、結果を所長が確認する流れが考えられます。
今後の展望と編集部の考察
プラグインとマーケットプレイスの管理がAdmin consoleにまとまったことで、事務所は、利用できる拡張機能を事務所の単位で選別しやすくなりました。今後の論点は、プラグイン提供元の数が増えたとき、事務所がどの基準で承認するかです。
承認の基準は、機能の便利さではなく、扱う情報の種類と提供元のデータの取り扱いの説明が確認できるかを軸に置くのが、士業の事務所にとって現実的な設計だと考えられます。これは編集部の考察であり、特定の事務所への助言ではありません。
よくある質問
RBACが有効でないワークスペースでもロール別の設定はできますか
リリースノートは、RBACが有効なワークスペースでロール別にプラグインのアクセスを管理できると記しています。有効でない場合の扱いは、管理画面または販売窓口で要確認です。
既定値のAvailable、Install、Disabledはどう違いますか
リリースノートは3つの選択肢を示していますが、個々の挙動の詳細は本文に書かれていません。管理画面の説明を確認してから設定してください。
設定すれば顧問先への説明は不要になりますか
説明の要否は、契約書の文言と扱う情報の内容で変わります。権限設定の有無とは別の論点であり、本記事は当てはめを行いません。有資格者が判断してください。
小規模な事務所でもロールを分けたほうがよいですか
役割が複数ある事務所では、分けると管理の見通しが良くなります。所長ひとりの事務所では、ロールよりも、許可するプラグインの絞り込みが中心になります。
プラグインの提供元のデータの扱いはどこで分かりますか
各提供元の規約やデータ利用の説明で確認します。OpenAIの管理画面の設定だけでは、提供元側の扱いは分かりません。
参考文献
- OpenAI ヘルプ ChatGPT Enterprise and Edu リリースノート
- e-Gov法令検索 弁護士法
- e-Gov法令検索 税理士法
- e-Gov法令検索 行政書士法
- e-Gov法令検索 司法書士法
- e-Gov法令検索 社会保険労務士法
関連記事: AIエージェントの権限管理 最小権限の運用、事務所のAI権限を階層別に決めるルール
※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/
本記事の作成体制について
本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。
本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。
記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。