このガイドでは、日常の管理業務に Admin プラグインを使う方法と、作業を始める前に準備することを説明します。主なユースケースごとに、必要な承認と情報をそろえて試せるプロンプトを紹介します。
1. Admin プラグインの用途
Admin プラグインを使うと、ChatGPT Work 内で設定、権限、各種の制御を直接管理できます。普段の言葉で目的を伝えると、プラグインが必要な情報を集めて現在の状態を読み取り、分かったことを説明したうえで、次に実行できる手順を案内します。
Admin プラグインでできること
- 自分で API リクエストを書かずに、管理業務の依頼を具体的な手順に整理できます。
- 判断を下したり変更を承認したりする前に、ワークスペースの現状を確認できます。
- プラグインは、回答の根拠となった利用許可済みのデータソースとフィールドを示し、確認できなかった点も明らかにします。
- 対応範囲内の変更を実行する前に、プラグインはユーザーが内容を確認するのを待ちます。変更後はレコードを再度読み取り、結果を検証します。
プラグインは内部で一部の管理 API と、使用が承認された接続済みデータソースを利用します。すべての管理システムを統合するものではなく、ユーザーの権限が広がることも、ChatGPT ですべての API 操作が使えるようになることもありません。プラグインが読み取りや変更を行える範囲は、引き続きデータの管理元システムが制御します。
管理 API の用途
管理 API は、ソフトウェアが決められた形式でデータの取得や対応する操作を要求するための仕組みです。組織は管理 API を使って、社内の業務プロセスや外部ツールを構築できます。代表的な例には、定期レポートの作成、多数のレコードに対する繰り返し処理、承認済みシステムとの連携があります。通常、こうしたワークフローには、エンジニアリング、セキュリティ、ガバナンスの各担当部門によるレビューが必要です。
このガイドを利用するために、API を使ったワークフローを構築する必要はありません。以降は Admin プラグインを中心に説明します。また、ChatGPT ワークスペースの管理と OpenAI API プラットフォームの管理は別々に行い、それぞれに権限と認証の要件があります。
認証情報の保護
接続やシークレットの保管には、組織が承認した仕組みだけを使用してください。実際の管理 API キーは、ChatGPT、Codex、ドキュメント、ソースファイルのいずれにも絶対に貼り付けないでください。
2. Admin プラグインを使う前の準備
対応範囲内の単発の作業を普段の言葉で依頼して進めたいときは、Admin プラグインを使用します。目的を説明し、対象を一意に識別できる固定 ID またはレポートでの使用が承認された背景情報を指定してください。プラグインが調査結果や変更予定の内容を示すので、それを確認してから続行するかどうかを判断できます。
プラグインが使用するのは、その作業で許可されたデータソース、認証情報、操作だけです。すべての管理システムが統合されるわけではなく、ユーザーの権限も広がりません。引き続き、管理元システムのデータが正本となります。
事前確認
- 対象のレコードがどの管理領域にあるかを確認します。
- 必要な情報をそろえ、承認を得ます。
- 読み取り専用の依頼から始めます。
- どのデータソースとフィールドを使用したか、何を確認できなかったかをプラグインに尋ねます。
- プラグインが対応している変更を行う場合は、計画を確認してから承認します。実行後は、レコードを再度読み取って結果を検証するよう依頼します。
ワークスペースでプラグインが利用でき、自分に必要な権限があることを確認してください。以下で紹介するロールとアクセス権のユースケースは、現行のドキュメントに記載された対応範囲に基づいています。プラグインでは、ロール、機能ごとの権限、ユーザーやグループへのロールの割り当てを確認できます。また、ユーザーが内容を確認した後で、既存のグループに既存のロールを割り当てることもできます。
プラグインでは、ロールの作成、ロールの権限の変更、特定のコネクタへのアクセス可否の確認はできません。
分析を行うには、使用が承認された接続済みデータソースにアクセスできる必要があります。投資対効果（ROI）の分析には、使用が承認された事業またはエンジニアリングの成果データも必要です。利用記録だけでは分析できません。
3. Admin プラグインの主なユースケース
ユースケースを選び、各プレースホルダーを承認済みの依頼に記載された値に置き換えて、手順に沿って進めてください。プラグインが対応している変更で、すでに承認を得ている場合を除き、読み取り専用の依頼から始めます。
GPT の一覧を作成し、移行条件を満たすものをまとめて移行して、所有者によるテストやアクセス確認を調整する手順は、カスタム GPT の一括移行を参照してください。
ワークスペースのロール一覧
プロンプト例
ワークスペース {workspace_id} のロールを、組み込みロールとカスタムロールに分けて一覧にしてください。ロールごとに、利用できる機能を説明し、そのロールが割り当てられているユーザーまたはグループを示してください。変更は加えないでください。手順
- 準備： ワークスペース ID と、この情報を閲覧する権限があることを確認します。
- 実行： 読み取り専用でロールの一覧を取得するよう依頼します。
- レビュー： ロールの種類、利用できる機能、割り当て先を確認します。
- 検証： 想定外の点があれば、変更を加えずに調査します。
個別のロールの確認
プロンプト例
ロール {role_id} を確認してください。権限を分かりやすい言葉で説明し、このロールが誰に割り当てられているかを示してください。想定よりも範囲が広いと思われる点があれば、指摘してください。ロールは編集しないでください。手順
- 準備： ロール ID とワークスペースを確認します。
- 実行： 読み取り専用でロールの確認を依頼します。
- レビュー： 権限と割り当て先が、そのロールの本来の用途に合っているかを確認します。
- 検証： ロールの所有者に確認したいことを書き留めます。プラグインではロールの作成や権限の編集はできません。
ユーザーまたはグループのアクセス権の把握
プロンプト例
ユーザー {user_id} またはグループ {group_id} のアクセス権を確認したいです。割り当てられているロールを示し、各ロールで何にアクセスできるかを説明してください。権限に重複や不足があれば指摘し、確認できない点は明示してください。手順
- 準備： ユーザーまたはグループの固定 ID を使用します。
- 実行： アクセス権についてプラグインに説明を求めます。
- レビュー： 割り当てられているロールと、各ロールで何にアクセスできるかを確認します。権限の重複や不足があれば記録します。
- 検証： プラグインから確認できない項目は、推測せず「不明」と記録します。
グループへの既存ロールの割り当て
プロンプト例
変更を加える前に、グループ {group_id} に現在割り当てられているロールを示し、ロール {role_id} を割り当てるとどの権限が加わるかを説明してください。記録されている承認者を確認し、私が明示的に承認するまで待ってください。割り当て後は、グループのロールを再度確認して結果を検証してください。手順
- 準備： グループ ID とロール ID を確認します。承認済みの依頼と、記録されている承認者を確認します。
- 実行： 現在のロールと変更点を示すようプラグインに依頼します。
- レビュー： 計画が承認済みの依頼内容と一致する場合にのみ、実行を承認します。
- 検証： 割り当て後にグループを再度確認し、承認どおりに既存のロールが追加されたことを確かめます。
コネクタ全般の利用権限の確認
プロンプト例
ユーザー {user_id} に割り当てられているロールで、コネクタ全般の利用が許可されているかを確認してください。回答の根拠となる権限を示すよう、プラグインに依頼してください。特定のコネクタへのアクセス可否をプラグインが確認できない場合は、その旨を明示するよう伝えてください。手順
- 準備： ユーザー ID と、そのユーザーのアクセス権を確認する権限が自分にあることを確かめます。
- 実行： コネクタ全般の利用権限の確認を依頼します。
- レビュー： 割り当てられているロールと、回答の根拠となった権限を確認します。
- 検証： この結果は、コネクタ全般の利用権限の確認にのみ使用します。特定のコネクタや接続先の項目にアクセスできることまでは証明できません。
承認済みの変更に関するトラブルシューティング
プロンプト例
承認済みの変更 {change_record_id} を確認してください。依頼で指定された結果とワークスペースの現状を比較してください。変更に失敗している場合は、まずワークスペースとロールを確認してください。その後、レコードの所有者を確認し、問題を説明して、次に取るべき最も安全な対応を提案してください。手順
- 準備： 承認済みの変更レコードと、意図した結果を確認します。
- 実行： 依頼内容とワークスペースの現状を比較するようプラグインに依頼します。
- レビュー： ワークスペースとロールを確認してから、レコードの所有者を確かめます。
- 検証： ワークスペースの現在の状態を基準に、次の対応を選びます。
コストとモデル構成の最適化
プロンプト例
対象期間 {date_range} のワークスペース {workspace_id} について、確認済みのトークン使用量とコストをユースケース別に集計してください。速度と品質について得られる情報を使って、モデルと推論モードを比較してください。コストが高い一方で、価値を裏付けるデータが乏しいワークフローがあれば指摘してください。支出を削減できる箇所や、生産性またはコストの面でより大きな成果が出ている業務に予算を振り向けられる箇所を提案してください。使用が承認された売上や品質の指標があれば含めてください。削減見込み額を試算し、トレードオフを説明してください。データで確認できたことは、仮定や不足している情報と区別してください。読み取り専用で実行してください。手順
- 準備： ワークスペースと対象期間を確認し、コストデータが期間全体をカバーしていることを確かめます。使用が承認された性能や成果に関するフィールドのうち、どれが利用できるかを確認します。
- 実行： コストとモデルの比較を依頼します。
- レビュー： データから分かることと、仮定、不足している情報、トレードオフを区別します。
- 検証： 実行に移す前に、見込まれる削減額を財務部門とワークフローの責任者に確認します。
利用状況と普及度の把握
プロンプト例
ワークスペース {workspace_id} の対象期間 {date_range} における利用状況を分析してください。タスクとトークン使用量をチーム別、業務機能別に示し、コストをユースケース別に集計してください。各チームが ChatGPT と Codex を使ってどのような業務を行っているかをまとめ、法務、マーケティング、営業の例を含めてください。把握できる範囲で、スキルとプラグインの利用状況を比較してください。ツール呼び出し、接続済みアプリ、複数のツールを使うワークフローについては、該当するフィールドが利用できる場合に限り報告してください。どのチームのどの業務でより高度なワークフローが使われているか、どこに活用を広げる余地がありそうかを示してください。上位 {5_or_10} 件のユースケースを順位順に示し、利用頻度の高い少数のユーザーが利用量の大半を占めているかどうかを確認してください。データに記録されていない活動は推測しないでください。手順
- 準備： ワークスペース、対象期間、チームの対応関係を確認します。ユーザー単位でのレポート作成が承認されていることを確かめます。
- 実行： 利用状況と普及度の分析を依頼します。
- レビュー： 依頼したフィールドのうち、どれが利用できるかを確認します。記録のない活動は推測せず、報告から除きます。
- 検証： 利用量が多いことだけでは、高度な活用、事業価値、個人の業績を証明できません。
事業価値と ROI の測定
プロンプト例
ワークスペース {workspace_id} の対象期間 {date_range} について、確認済みの利用状況とコストを、使用が承認された成果データと組み合わせてください。チーム別、ユースケース別に事業価値を推定してください。営業部門の生産性、売上、品質について、使用が承認された指標を含めてください。チーム間、モデル間で比較し、ワークフロー間、ユーザー層間でも比較してください。コストに対するリターンが大きい順に順位を付けてください。データソースと計算式を示し、仮定、分析上の限界、不足している情報を明示してください。ChatGPT がこれらの成果をもたらしたと断定しないでください。読み取り専用で実行してください。手順
- 準備： ワークスペースと対象期間を確かめてから、使用が承認された成果データを確認します。計算式とプライバシーに関するルールにも目を通します。
- 実行： ROI の分析を依頼します。
- レビュー： すべてのデータソースと仮定を確認します。分析上の限界や不足している情報を一つずつ記録します。
- 検証： 利用状況だけでは ROI や因果関係を証明できません。財務部門と事業責任者に結果を共有し、一緒に確認します。
Codex の ROI 評価
プロンプト例
ワークスペース {workspace_id} について、対象期間 {date_range} の確認済みの Codex 利用状況とコストを、使用が承認されたエンジニアリングの成果データと組み合わせてください。チーム別、リポジトリ別、ワークフロー別に ROI を推定してください。生産性とデリバリー速度を、コードの品質と開発コストと照らし合わせて比較してください。高い価値を示しているワークフローや、多くのリソースを消費しているワークフローを特定してください。モデル、推論モード、またはワークフローの変更を提案し、トレードオフと不確実な点を説明してください。分析結果は、得られたデータに見られる傾向として示してください。Codex が成果をもたらした証拠として扱わないでください。結果のみを報告し、変更は加えないでください。手順
- 準備： ワークスペースとレポートの対象期間を確認します。チームとリポジトリの対応関係、および使用が承認されたベースラインデータを確認します。
- 実行： Codex の ROI 分析を依頼します。
- レビュー： 観測された傾向と仮定を区別します。ユーザーとリポジトリのデータを保護します。
- 検証： 提案内容と、成果を評価する際のベースラインをエンジニアリング部門と確認します。
4. API を使ったワークフローが適している場合
組織によっては、API を使って独自の管理プロセスや外部ツールを構築しています。この方法は、定期的または継続的に行う作業に適しています。多数のレコードにまたがる処理や、承認済みの社内システムとの連携が必要な場合にも役立ちます。これは、Admin プラグインの案内に沿って作業を進める方法とは別のものです。
まず、対象となる管理業務を明確にし、必要な入力情報と権限、レビューのタイミング、期待する結果、結果の記録方法を決めます。組織でその業務を自動化する場合は、エンジニアリング、セキュリティ、ガバナンスの各担当部門と連携してください。認証情報は承認済みのシークレット保管システムに保存し、デプロイ前にワークフローをテストしてください。