古いグループを削除したい、名前を変えたい、ID プロバイダーのグループに置き換えたい、という場面があります。その前に、Jira がまだどこでそのグループを使っているかを知る必要があります。グループは、共有の権限スキーム、1 つのスペースのスペース ロール、フィルターのクエリ、自動化ルールの中にあることがあり、名前からはどこにあるかわかりません。old-contractors という名前のグループが共有スキームでまだアクセス権を与えていることもあれば、jira-users-temp がどこにも使われていないこともあります。

画面の名前は、アトラシアンの日本語のサポート ドキュメントに合わせています。日本語のドキュメントに名前がない画面は、英語の名前を添えています。このページは英語版の翻訳です。

Jira には「このグループはどこで使われているか」を 1 か所で見る画面がない

アトラシアン自身のヘルプ記事は、Jira Cloud の画面では、グループが権限スキームで使われているかどうかを表示できないと述べ、回避策として REST API のスクリプトを示しています。さらに、グローバル権限、フィルターの共有とサブスクリプション、ダッシュボードの権限もグループを参照すると付け加えています。グループの使用状況を見る画面を求める公開リクエスト JRACLOUD-71967 には 1,000 を超える票が集まっていますが、状態はまだ Gathering Interest です。

つまり、正直な答えは、1 か所ずつ手作業で確認することです。このページでは、確認する場所、Jira での確認方法、Jira が見せてくれないものを挙げます。

出典: How to find group usage in permission schemes for Jira Cloud via REST API and Python（英語）、JRACLOUD-71967（英語）、2026 年 10 月 13 日に確認。

始める前に

  • まず製品アクセスを確認します。 そのグループがそもそも誰かに Jira を与えているかどうかは、Jira ではなくアトラシアンの管理で設定されています。Jira へのアクセス権を与えるグループを確認する方法をご覧ください。
  • 以下のスキーム、ワークフロー、フィルター、ダッシュボードの管理ページには、グローバル権限 [Jira の管理] が必要です。
  • スペースの種類を把握します。 企業管理対象スペースはスキームを共有します。チーム管理対象スペースは権限スキームを使わず、それぞれが自分の [アクセス] ページでアクセスを設定します。
  • 確認しながら記録します。 場所、見つけたもの、日付です。最後にテンプレートがあります。

チェックリスト

最後の列は、各確認にかかる手間を示しています。「1 ページ」は、Jira がサイト全体を一度に表示するという意味です。「1 つずつ」は、スキーム、スペース、項目を 1 つずつ開くという意味です。

確認する場所Jira での場所見るポイントJira での確認の仕方
製品アクセスアトラシアンの管理 > [アプリ] > [Atlassian アプリ] > [アプリの管理]グループがアプリのロールを持っている、または既定のグループであるアプリごとに 1 ページ
グローバル権限[設定] > [システム] > [グローバル権限]いずれかの権限の下にあるグループ1 ページ
権限スキーム[設定] > [作業項目] > [権限スキーム]グループまたはグループ カスタム フィールド値への付与。グループが所属するロールスキームごとに 1 つずつ
スペース ロール（企業管理対象）各スペースの [スペース設定] > [ユーザー]（英語の画面では People）ロールの中のグループスペースごとに 1 つずつ
チーム管理対象スペース各スペースの [スペース設定] > [アクセス]ロールを持つグループスペースごとに 1 つずつ
作業項目セキュリティ[設定] > [作業項目] > [作業項目セキュリティ スキーム]グループまたはグループ ピッカー フィールドに与えられたセキュリティ レベルスキームごとに 1 つずつ
通知スキーム[設定] > [作業項目] > [通知スキーム]受信者としてのグループまたはグループ ピッカー フィールドスキームごとに 1 つずつ
ワークフロー[設定] > [作業項目] > [ワークフロー]。チーム管理対象: [スペース設定] > [作業タイプ]作業項目を移動できる人をそのグループに制限するトランジションのルールトランジションごとに 1 つずつ
フィルターの共有[フィルター] でグループで検索。管理者: [設定] > [システム] > [フィルター]グループと共有されているフィルター1 回の検索。自分が見られるフィルターだけ
フィルターのクエリ（JQL）画面なし: REST APIフィルターの JQL の中の membersOf("group name")REST API のみ
ダッシュボード[設定] > [システム] > [共有項目] > [ダッシュボード]ダッシュボードの共有の中のグループ1 ページ、各行を読む
ボード管理者ボード > [ボードの設定] > [管理者]ボード管理者としてのグループボードごとに 1 つずつ
リクエスト タイプ（Jira Service Management）[スペース設定] > [リクエスト管理] > [リクエスト タイプ] > [制限]制限付きのリクエスト タイプを使えるグループリクエスト タイプごとに 1 つずつ
自動化ルール[設定] > [システム] > [グローバル自動化]。[スペース設定] > [自動化]グループを確認するユーザー条件。ルールを管理できるグループルールごとに 1 つずつ

Jira グループが使われうる場所を、Jira での確認の仕方で分けた図。サイト全体で 1 ページ: グローバル権限、共有ダッシュボード。スキームごと: 権限スキーム、作業項目セキュリティ スキーム、通知スキーム。スペースや項目ごと: スペース ロール、チーム管理対象スペースのアクセス、ワークフロー、ボード管理者、リクエスト タイプの制限、自動化ルール。画面なし: 保存済みフィルターのクエリの中のグループ名で、REST API でしか見つけられない。Jira の外: アトラシアンの管理の製品アクセスと、ID プロバイダーのグループ メンバーシップ。図は英語です。

各確認について、Jira が一度にどれだけ見せてくれるか。Jira の中でサイト全体を 1 ページで見られるのは、グローバル権限と共有ダッシュボードだけです。図は英語です。

グローバル権限

Jira は、すべてのグローバル権限を 1 つのページに表示します。

  1. [設定] を選び、次に [システム] を選びます。
  2. サイドバーで [グローバル権限] を選びます。

各権限に、その権限を持つグループが一覧表示されます。[Jira の管理]、[ユーザーまたはグループの参照]、[ダッシュボードとフィルターの共有]、[グループ フィルター サブスクリプションの管理]、[一括変更の実行]、[チーム管理対象スペースを作成する] を特に注意して見てください。新しいサイトでは、既定のグループ jira-admins-<site> が Jira 管理者の権限を与えます。そのため、整理の対象ではなく、管理者の設定の一部として扱ってください。

出典: Jira でグローバル権限の表示、付与、取り消しを行う、グローバル権限とその制御対象について、What are default groups in Atlassian?（英語）、2026 年 10 月 13 日に確認。

権限スキーム: 直接、ロールを通じて、フィールドを通じて

  1. [設定] を選び、次に [作業項目] を選びます。
  2. [作業項目の属性] で [権限スキーム] を選びます。一覧の下の方にあります。
  3. 各スキームを名前から開くか、[権限] を選びます。
  4. すべての権限を読み、グループが現れる場所を記録します。

1 つの権限スキームを多くのスペースが共有していることがあり、変更はそのすべてに適用されます。グループが見つかった各スキームについて、それを使っているスペースを記録してください。スペースでは、[スペース設定] > [権限] で、使っているスキームがわかります。

グループが権限に届く経路は 3 つあり、スキームのページにグループ名が表示されるのは 1 つ目だけです:

  • 直接。 権限がグループに付与されていて、グループ名が表示されています。
  • スペース ロールを通じて。 権限が Developers などのロールに付与されていて、いくつかのスペースでグループがそのロールのメンバーになっています。スキームにはロールしか表示されません。グループは、各スペースのロールのメンバーで見つけます（次のセクション）。
  • グループ ピッカー フィールドを通じて。 権限がグループ カスタム フィールド値に付与されています。つまり、作業項目のグループ ピッカー フィールドで選ばれたグループにいる全員です。グループ名はスキームにはまったく入っておらず、作業項目に保存されています。

アプリ アクセスの付与もあります。アプリにアクセスできる全員です。これはグループを名指ししませんが、Jira へのアクセス権を与えるすべてのグループにその権限を与えます。

サンプルのグループ legacy-oncall-emea が 3 つの経路で権限に届く図。直接: 権限スキーム「Shared support scheme」がグループに Browse spaces を付与していて、SUP と OPS の 2 つのスペースがそのスキームを使っている。ロールを通じて: グループはスペース OPS の Developers ロールのメンバーで、スキームは Developers に Edit work items を付与している。フィールドを通じて: 作業項目のグループ ピッカー フィールド「Escalation group」でグループが選ばれていて、作業項目が更新されると通知スキームがグループ カスタム フィールド値にメールを送る。図は英語です。

1 つのグループ、3 つの経路。スキームのページにグループ名が表示されるのは直接の経路だけです。サンプル データ、架空のグループとスペースです。図は英語です。

スキームが多い場合、アトラシアンのヘルプ記事に、グループが直接付与されているスキームを一覧にする REST API と Python の例があります。アトラシアンは、このスクリプトをサポートも保守もしないと注記しています。

出典: スキームで権限の付与または取り消しを行う、Jira の権限スキームとは、スペースで使用する権限スキームを変更する、How to find group usage in permission schemes（英語）、2026 年 10 月 13 日に確認。

スペース ロールとチーム管理対象スペース

企業管理対象スペース。 ロールのメンバーはスペースごとに設定されます。各スペースで [スペース設定] > [ユーザー]（英語の画面では People）を開き、いずれかのロールにグループがないか探します。1 つのグループのロールをすべてのスペースにわたって一覧にするページは、アトラシアンのドキュメントには書かれていません。そのため、この確認はスペースごとに行います。

ロールのメンバーシップが何をするかを理解するには、ロール自体が使われている場所を見ます:

  1. [設定] を選び、次に [システム] を選びます。
  2. [セキュリティ] で [スペース ロール] を選びます。
  3. ロールの [利用状況を表示] を選びます。

そのロールを使っている権限スキーム、通知スキーム、作業項目セキュリティ レベル、ワークフロー条件が一覧表示されます。

チーム管理対象スペース。 権限スキームを使いません。各チーム管理対象スペースで [スペース設定] > [アクセス] を開きます。そこでは、ユーザーやグループに Viewer、Member、Administrator などのロールを与えられます。スペースのアクセス レベル（オープン、制限付き、非公開）も記録してください。

ロールからグループを外すと、変わるのは 1 つのスペースです。グループを削除したり名前を変えたりすると、すべてのスペースに一度に影響します。グループが見つかった場所が 1 つのスペースの 1 つのロールだけなら、そのロールから外すだけで済むかもしれません。

出典: スペース ロールの利用状況を表示する、Restrict space access to certain groups or users（英語）、チーム管理対象スペースにユーザーを追加する、チーム管理対象スペース権限、2026 年 10 月 13 日に確認。

作業項目セキュリティ スキームと通知スキーム

作業項目セキュリティ。 [設定] > [作業項目] を選び、[作業項目の属性] の [作業項目セキュリティ スキーム] を選びます。各スキームで、すべてのセキュリティ レベルを確認します。レベルは、グループ、グループ カスタム フィールド値、スペース ロールなどに付与できます。レベルを与えられていない人は、そのレベルが設定された作業項目を見られません。そのため、ここでグループを外すと、そのメンバーから作業項目が見えなくなることがあります。

通知。 [設定] > [作業項目] > [通知スキーム] を選びます。各スキームを開くと、そのページにすべてのイベントと通知を受ける人が一覧表示されます。グループ、グループ カスタム フィールド値、グループを含むスペース ロールを探します。ここでの変更は、誰がメールを受け取るかに影響し、誰がアクセスできるかには影響しません。

出典: 作業項目セキュリティ スキームでユーザーにセキュリティ レベルへのアクセスを許可する、作業項目セキュリティ スキームとは、通知スキームの設定、2026 年 10 月 13 日に確認。

ワークフロー

ワークフローは、グループにいない人が作業項目を移動できないようにすることができます。

  • 企業管理対象: [設定] > [作業項目] > [ワークフロー] を選びます。各ワークフローを [その他のアクション]（•••）> [編集] で開きます。
  • チーム管理対象: [スペース設定] > [作業タイプ] を開き、作業タイプを選んで [ワークフローを編集] を選びます。

各トランジション（2 つのステータスの間の矢印）を選び、その [ルール] を読みます。グループに設定された [作業項目を移動できるユーザーを制限する] を探します。古いワークフロー エディターでは、同じものが User Is In Group、User Is In Any Group、User Is In Group Custom Field の条件と呼ばれていました。

グループがなくなると、そのトランジションを使えるのは、ルールに残っている人だけになります。また、保存したワークフローの変更は、そのワークフローを使うすべてのスペースに適用されます。

出典: ユーザー グループに基づいてワークフローを制限する、ワークフロー エディターとは、チーム管理対象スペースで利用可能なワークフロー ルール、2026 年 10 月 13 日に確認。

フィルター、ダッシュボード、ボード

フィルターの共有。 フィルターはグループと共有できます。フィルターの一覧では、所有者、スペース、グループでフィルターを検索できます。見られるのは、自分がアクセスできるフィルターだけです。管理者は、[設定] > [システム] > [フィルター] で、共有フィルターを探し、所有者を変更し、削除できます。

フィルターのサブスクリプション。 フィルターの結果をグループにメールで送ることができます。アトラシアンは、グループを参照する場所の 1 つとしてサブスクリプションを挙げていますが、すべてのグループ サブスクリプションを一覧にするページはドキュメントに書かれていません。見つけたフィルターのサブスクリプションを確認してください。

フィルターのクエリの中のグループ名。 フィルターの JQL は、membersOf("Developers") のようにグループを名指しできます。アトラシアンは、画面上でフィルターを JQL で検索する方法はないと述べています。回避策は REST API です: GET /rest/api/3/filter/search?expand=owner,jql を実行し、結果からグループ名を探します。API が返すのは、自分が見られるフィルターだけです。Jira 管理者は overrideSharePermissions=true を追加すると、共有設定にかかわらずフィルターを含められます。

ダッシュボード。 [設定] > [システム] > [共有項目] > [ダッシュボード] を選びます。各ダッシュボードに、所有者と共有の一覧が表示されます。検索ボックスは入力したテキストとの一致を探すだけなので、グループは共有の列を 1 行ずつ読んで探してください。

ボード管理者。 企業管理対象ボードで [その他]（•••）> [ボードの設定] を選びます。[管理者] フィールドには、ユーザーまたはグループを入れられます。

出典: Unable to edit group name error in Jira Cloud（英語）、フィルターを管理する（管理者）、フィルターを管理する、Jira REST API: Filters（英語）、ダッシュボードを管理する、企業管理対象ボードを設定する、2026 年 10 月 13 日に確認。

Jira Service Management のリクエスト タイプ

リクエスト タイプは、特定のユーザー、グループ、カスタマー アカウント、カスタマー組織に制限できます。そのリストにいる人だけが使えます。

  1. サービス スペースで [スペース設定] > [リクエスト管理] > [リクエスト タイプ] を開きます。
  2. リクエスト タイプを選び、[制限] を選びます。

1 つのグループに制限されたリクエスト タイプをすべて一覧にする方法は、アトラシアンのドキュメントに書かれていません。そのため、制限付きのリクエスト タイプを 1 つずつ確認してください。もう 1 つ注意点があります。自動化とアプリは、アプリ ユーザーまたは atlassian-addons-admin グループがリストに入っていなければ、制限付きのリクエスト タイプを使えません。このグループを誤って外さないでください。

出典: リクエスト タイプの制限を追加または削除する、2026 年 10 月 13 日に確認。

自動化ルール

自動化では、グループは 2 か所に現れます:

  • ルールの中。 ユーザー条件は、ユーザーが存在しているか、指定したグループにいるかを確認します。
  • グローバル設定の中。 [設定] > [システム] > [グローバル自動化] で [その他のアクション]（•••）> Global configuration（グローバル設定）を開くと、スペースのルールを管理できるユーザーとグループを選べます。

グローバル ルールは [グローバル自動化] にあります。スペースのルールは、各スペースの [スペース設定] > [自動化] にあります。ルールをグループ名で検索する方法は、アトラシアンのドキュメントに書かれていません。そのため、人を確認する可能性のあるルールを 1 つずつ開いてください。

アトラシアンは、自動化ルールで使われているグループの名前を変えると、そのルールが動かなくなるとも注意しています。

出典: Jira Automation の条件、Permissions required to manage automation flows（英語）、Create and edit Jira automation flows（英語）、グループを編集する、2026 年 10 月 13 日に確認。

グループの名前変更、削除、置き換えの前に

名前変更。 アトラシアンの管理で [ディレクトリ] > [グループ] を開き、グループを選んで、More actions > Edit group name（グループ名の編集）を選びます。アトラシアンは、グループ名の編集をベータ機能としています。Jira の一部の管理設定で使われているグループは、名前を変えられません。エラーには、たとえばフィルターの JQL など、名前変更を妨げている設定が表示されます。先にその設定を直してください。古い名前を使っている自動化ルールは、動かなくなります。

削除。 アトラシアンは、削除する前に、そのグループがどこかのアプリで権限を設定していないか確認するよう勧めています。メンバーがまだその権限を必要としているなら、グループを残します。必要でなければ、先にそれらの権限からグループを外します。そうすれば、後で同じ名前で作られた新しいグループがその権限を引き継ぐことはありません。さらに:

  • ロールの既定のグループは削除できません。
  • グループを削除しても、そのメンバーは組織から削除されません。

同期されたグループに置き換える。 ユーザー プロビジョニングに移行するとき、ID プロバイダーは、既存のグループと同じ名前のグループを送信できません。そのため、新しいグループには新しい名前を付け、見つけたすべての参照を 1 つずつそのグループに切り替える必要があります。同期されたグループを ID プロバイダーで削除すると、アトラシアンのディレクトリからも削除されます。そのため、誰かがそこで削除する前にも、同じ確認が必要です。

安全な順序は、各参照を置き換える、ユーザーが必要なものをまだ持っているか確認する、それから削除または名前変更する、です。

出典: グループを編集する、グループを削除する、Unable to edit group name error in Jira Cloud（英語）、ユーザー プロビジョニングについて、2026 年 10 月 13 日に確認。

確認したことを記録する

スクリーンショットは、ある画面がある時点でそう見えたことを示すだけです。どの場所を確認したかは示しません。次の管理者があなたに聞かなくても読める、短い記録を残してください。次をコピーして記入します:

グループ:                       legacy-oncall-emea
確認者、日付:                   （名前）、2026 年 10 月 13 日
同期かローカルか:               ローカル（アトラシアンの管理）
製品アクセス:                   アプリのロールなし、既定のグループではない
グローバル権限:                 なし
権限スキーム:                   "Shared support scheme": Browse spaces（スペース SUP、OPS）
スペース ロール:                OPS: Developers
チーム管理対象スペース:         見つからず
作業項目セキュリティ:           なし
通知スキーム:                   グループ名での指定なし。"Escalation group" フィールドが 1 スキームで使用
ワークフロー:                   なし
フィルターの共有:               グループと共有されたフィルター 1 件
フィルターの JQL（REST API）:   1 件のフィルターが membersOf("legacy-oncall-emea") を使用
ダッシュボード、ボード:         なし
リクエスト タイプ:              なし
自動化ルール:                   グループを確認するものはなし
未確認:                         作業項目に保存されたグループの値、Marketplace アプリ
計画:                           スキームとロールで置き換え、フィルターを更新し、その後削除
フォローアップの担当者:         （名前）

記録のサンプル、架空のグループとスペースです。

「未確認」の行は、見つかったことと同じくらい重要です。まだわかっていないことを、確認する人に伝えるからです。

手作業の確認では見えないもの

注意深く確認しても、抜けは残ります。それを記録に書いてください:

  • 作業項目に保存されたグループの値。 スキームがグループ ピッカー フィールドを使っている場合、グループは設定ではなく、作業項目のデータです。
  • 自分が見られないフィルター。 Jira 管理者が上の REST API のオプションを使う場合を除きます。
  • Marketplace アプリと、Confluence などほかの Atlassian アプリ。 それぞれ独自の設定を持ち、同じグループを使います。
  • 確認した後の変更。 記録に日付を入れ、予定した変更の実施が遅れた場合はもう一度確認してください。

グループやスペースの一覧が長いと、手作業ではすぐに時間がかかるようになります。そうなると、チームはアトラシアンの権限スキームの例のような REST API のスクリプトや、グループの使用状況を報告する Marketplace アプリを使います。何を使う場合も、上の場所のうちどれを実際に読んでいるかを確認し、残りは引き続き未確認として記録してください。