グループから外しても Jira へのアクセス権が残った理由

マネージャーから、元アナリストの Jira へのアクセス権をなくしてほしいと頼まれます。あなたはその人を Jira ユーザーのグループから外します。翌朝、マネージャーから「まだ Jira を開けるようです」と言われます。外したこと自体は間違いではなく、不完全だっただけです。Atlassian Cloud の Jira へのアクセス権は層になっていて、1 つのグループが唯一の経路であることはまれです。

状況は 2 つあり、確認する内容が違います:

• アクセス権が最初からなくなっていない: 別の経路がまだ Jira を与えています。
• アクセス権が戻ってきた: 外した後に、何かが再び追加しました。

3 つ目の可能性もあります。そもそも Jira のアプリ アクセスの問題ではない場合です。

アトラシアンの管理画面では、これを現在アプリ アクセスと呼んでいます。古いページや多くの管理者はまだ「製品アクセス」と言いますが、同じものです。画面の名前は、アトラシアンの日本語のサポート ドキュメントに合わせています。このページは英語版の翻訳です。

まず: 本当に Jira のアプリ アクセスの問題か

「まだ Jira が見える」には 3 つの意味があります。ほかに何かを外す前に、どれなのかを確かめてください。

できること	何が原因か	確認する場所
Jira を開いて作業できる	アプリ アクセスが残っている	この記事
Jira は開けるが、見えてはいけないスペース（旧プロジェクト）や作業項目が見える	Jira の中の権限で、アプリ アクセスではない	Jira の権限ヘルパー: [設定] > [システム] > [管理ヘルパー] > [権限ヘルパー]（Jira 管理者）
Jira は開けないが、まだメールが届く、または古いリンクを開ける	変更前に送られた通知やリンク	実際に何が見えていて、いつのことかを本人に尋ねる

Jira は使い続けてよいが 1 つのスペースだけ見えないようにしたい場合、さらにグループを外すのは誤った対処です。代わりにスペースの権限を確認してください。

出典: Jira 管理ヘルパーを使用する、2026 年 10 月 13 日に確認。

これで切り分けられる 1 つの確認: [アプリ] タブを今と後で

そのユーザーのプロファイルを開きます:

• 一元化されたユーザー管理: アトラシアンの管理 > [ディレクトリ] > [ユーザー] > ユーザーを選択 > [アプリ] タブ。
• 元のユーザー管理: アトラシアンの管理 > サイトを選択 > [ユーザー] > ユーザーを選択 > [アプリ] タブ。

そして 2 つの時点を比べます:

• グループから外した直後も Jira が表示されている。アクセス権は最初からなくなっていません。別の経路が有効です。次のセクションに進んでください。
• Jira が消えた後、数時間後や数日後に再び表示された。アクセス権が戻ってきました。「アクセス権が戻ってきた理由」に進んでください。
• Jira は表示されていないが、本人はまだ入れると言う。「[アプリ] タブにはないのに本人は入れる場合」に進んでください。

出典: ユーザーのアプリ アクセス権を削除する、2026 年 10 月 13 日に確認。

どちらの分岐かによって、次に確認するものが決まります。図は英語です。

アクセス権が最初からなくなっていない理由

1. 別のグループも Jira を与えている

最も多い理由です。アプリへのアクセス権はグループが与え、ユーザーは多くのグループに所属しています。finance-reporting や all-staff という名前のグループでも、名前からはわからなくても Jira を与えていることがあります。アトラシアンもはっきり述べています。同じアプリを与える別のグループに所属しているユーザーは、アクセス権を持ち続けます。

確認方法:

1. Jira を与えるグループをすべて一覧にします。一元化: [アプリ] > [Atlassian アプリ] > Jira の [アプリの管理]。元のユーザー管理: [アプリによるアクセス] で Jira を探します。
2. 各グループを開き（[ディレクトリ] > [グループ] > グループを選択）、メンバーのタブでそのユーザーを探します。
3. 名前を信用しないでください。グループが与えるアプリは、そのグループの [アプリ] タブで確認できます。

詳しくは How to check which groups give Jira access（英語）をご覧ください。

2. まだ Jira の既定のグループにいる

どのアプリ ロールにも、少なくとも 1 つの既定のグループがあります。アプリや新しいロールへのアクセス権を付与すると、アトラシアンはそのユーザーを自動で既定のグループに追加します。プロファイルから「直接」Jira を与えた場合も同じで、その付与によってユーザーは既定のグループに入っています。

アトラシアンは、初めてサイトを使うユーザーや、Jira や Confluence でメンションされたユーザーが、自動で既定のグループに追加されることがあるとも述べています。これは予期しないライセンスの消費につながることがあると注意しています。

確認方法: 上の手順 1 のアプリのグループ一覧で、既定のグループには印があります。一元化では [既定のグループ] 列にチェックマークが表示されます。元のユーザー管理では Default access group と表示されます。管理者が名前を変えられるため、既定のグループの名前はサイトによって異なります。

Jira Service Management では、既定のグループにいる全員がエージェント ライセンスを使います。Jira Service Management は Jira とは別のアプリなので、そのユーザーの [アプリ] タブで別に確認してください。

3. そのアプリの管理者ロールを持っている

そのユーザーがアプリの管理者である場合、アトラシアンは、アプリへのアクセス権を削除する前にその管理者ロールを削除するよう求めています。

確認方法: そのユーザーの [アプリ] タブで、Jira に表示されているロールを確認します。

4. 外した場所が違った

• 別のサイト: 元のユーザー管理では、削除はサイトごとです。そのユーザーは組織内の別のサイトへのアクセス権を持ち続けます。[ユーザー] ページの [サイト] フィルターで各サイトを確認してください。
• 別の組織: 同じ Atlassian アカウントで、パートナーや取引先の Jira を使うことができます。自社の組織で何をしても、そのアクセス権はなくなりません。ブラウザーのアドレスを尋ねてください。自社のサイトでなければ、自社が外せるアクセス権ではありません。

入れ子グループについて

Atlassian Cloud は入れ子グループをサポートしていません。社内のディレクトリでグループを入れ子にしている場合（たとえば「All staff」の中に「Finance」）、同期は直接のメンバーシップにフラット化するか、親グループのメンバーシップを落とします。どちらの場合も、アトラシアンで見えるメンバーシップは、ディレクトリの入れ子グループが原因になっていることがあります。ディレクトリ側で修正してください。

出典: ユーザーのアプリ アクセス権を削除する、What are default groups in Atlassian?（英語）、ユーザーにアプリへのアクセス権を付与する、ユーザーを削除するかアクセス権を一時停止する、入れ子グループの問題について理解する、2026 年 10 月 13 日に確認。

アクセス権が戻ってきた理由

1. ID プロバイダーがメンバーシップを再び同期した

Okta や Microsoft Entra ID などの ID プロバイダーからユーザー プロビジョニング（SCIM）を使っている場合、ユーザー、グループ、メンバーシップは ID プロバイダーから来ます。同期されたグループは、アトラシアンでは読み取り専用です。アトラシアンは、メンバーシップを ID プロバイダーで管理し、変更が確実に同期されるようにすることを勧めています。アトラシアンでだけ行った変更は、正となるデータの場所で行われていません。

確認方法: [ディレクトリ] > [グループ] でグループを開き、ID プロバイダーから同期されているかを確認します。同期されている場合は、ID プロバイダーの担当者にそのグループからユーザーを外してもらい、同期を待ってから、もう一度 [アプリ] タブを確認します。Google Workspace との同期を使っている場合も、考え方は同じです。

2. 本人が自分で戻ってきた

[アプリ] > App access settings（アプリ アクセスの設定）で、メール ドメインを承認できます。あるアプリで [必須] のチェックが入っていない場合、そのドメインの人は招待なしですぐにアプリに参加します。[任意のドメイン] の設定は、ほかのドメインに対して同じ動きをします。[招待リンク] を使うと、リンクを知っている人は誰でも最大 30 日間参加できます。こうして参加した人はライセンス ユーザーになります。

確認方法: Jira について、承認済みドメイン、[任意のドメイン] の設定、有効な招待リンクを確認します。

3. 既定のグループに自動で追加された

上の理由 2 をご覧ください。初めてのアクセスや Jira でのメンションによって、既定のグループに戻ることがあります。

4. 誰か、または何かが再び付与した

別の管理者、オンボーディングのリクエスト、アトラシアンの API（アクセス権の付与やロールの割り当ての API など）を使うスクリプトが、アクセス権を戻すことがあります。ほかの管理者に確認し、ユーザーをグループに追加する自動化をすべて確認してください。

出典: ユーザー プロビジョニングについて、ユーザーのアプリ アクセス権を削除する、Control how users get access to apps（英語）、アプリ アクセスの仕組み、2026 年 10 月 13 日に確認。

[アプリ] タブにはないのに本人は入れる場合

[アプリ] タブに Jira がなく、すべてのサイトを確認した場合、残るのは 3 つです:

• 別の Jira。本人が開いている正確なウェブ アドレスを尋ねてください。別のサイトや別の組織の可能性があります。
• 別のアプリ。Jira Service Management や別の Jira アプリを使っている可能性があります。それぞれに独自のアクセス権があります。
• 古いセッションやページ。すでに開いているブラウザーのタブがいつ変更に気づくかは、アトラシアンの管理者向けドキュメントに書かれていません。本人にサインアウトしてサインインし直し、ページを再読み込みしてもらってから、何が見えるかを教えてもらってください。

たどれる例

サンプル データ: 架空の人物と架空のグループ名です。

Sam は経理チームを離れました。管理者は、このサンプル サイトの Jira の既定のグループである jira-software-users から Sam を外しました。翌日も Sam は Jira を開けました。

手順	場所	管理者が見つけたこと	意味
1	[ディレクトリ] > [ユーザー] > Sam > [アプリ]	外した直後も Jira が表示されている	最初からなくなっていない: 別の経路
2	[アプリ] > [Atlassian アプリ] > Jira > [アプリの管理]	Jira を与えるグループ: jira-software-users（既定）、finance-reporting、all-staff	確認する経路は 3 つ
3	finance-reporting > メンバー	Sam はメンバー	経路 2 が有効
4	all-staff > メンバー	Sam はメンバー。このグループは ID プロバイダーから同期されている	経路 3 が有効で、アトラシアンの外で管理されている
5	Sam の [アプリ] タブ > Jira > [アクセス権を削除]	Jira を与えるすべてのグループから Sam が外れる	アトラシアンで管理している経路は閉じた
6	ID プロバイダー	ID プロバイダーの担当者が all-staff から Sam を外す	同期で Sam が戻されるのを防ぐ
7	次の同期の後の Sam の [アプリ] タブ	Jira は表示されていない	経路は残っていない
8	Sam にサインアウトとサインインをしてもらい、サイトを開いてもらう	Sam はもう Jira に入れない	影響を受ける本人で確認済み

判断について 2 つの注意点:

• all-staff から Jira をそのまま外さないでください。そのグループの全員が Jira を失います。経路ごとに判断してください。この人がグループを抜けるべきか、グループが Jira を与えるのをやめるべきか、正当な例外か。
• 確認を続けてください。1 週間後に Jira が再び表示されたら、「戻ってきた」分岐です。承認済みドメインとほかの管理者を確認してください。

1 人のユーザーの Jira へのすべての経路、変更前と変更後。サンプル データ。図は英語です。

本当になくなったことを確認する

次のすべてが当てはまってから、チケットを閉じてください:

1. そのユーザーの [アプリ] タブに、関係するどのサイトでも Jira が表示されていない。
2. 既定のグループを含め、Jira のグループ一覧にあるどのグループにも所属していない。
3. ID プロバイダーが関係している場合、次の同期の後も [アプリ] タブに Jira が表示されていない。
4. 本人（または本人に代わって上長）が、自社のサイトのアドレスで Jira にサインインできなくなったことを確認した。
5. どの経路があったか、誰が各変更を承認したか、残した例外を記録した。

請求について: プランのユーザー数には、そのプランの少なくとも 1 つのアプリにアクセスできる全員が含まれます。つまり、どれか 1 つでも経路が残っている限り、その人は Jira で数えられます。月間プランでは、アトラシアンは請求期間中の最大ユーザー数で請求します。期間の途中で外すと、下がるのは次の請求で、今回の請求ではありません。

出典: プランのユーザー数を監視する、最大ユーザー数に基づく請求の仕組み、2026 年 10 月 13 日に確認。

よくある間違い

1. 名前に「jira」が入ったグループが唯一の経路だと思い込む。
2. Jira を与えるグループを一覧にせず、手当たり次第にグループを外す。
3. 直接の付与によって入った既定のグループを忘れる。
4. 同期されたグループをアトラシアンで編集して、変更が残らない理由がわからない。
5. [必須] のチェックなしで承認済みドメインを開いたままにし、本人が自分で戻れるようにしてしまう。
6. スペースの権限の問題をアプリ アクセスの問題として扱い、本人に必要なアクセス権を外してしまう。
7. 次の同期の前、または本人の確認の前にチケットを閉じる。

チェックリスト

• 外した直後に、そのユーザーの [アプリ] タブをもう一度確認する。
• Jira を与えるグループをすべて一覧にし、それぞれにそのユーザーがいるか確認する。
• 既定のグループと管理者ロールを確認する。
• 別のサイト（元のユーザー管理）を確認し、本人が開いているアドレスを確かめる。
• ID プロバイダーから同期されているグループを調べ、その変更は担当者に依頼する。
• 承認済みドメイン、[任意のドメイン] の設定、招待リンクを見直す。
• [アプリ] タブの [アクセス権を削除] で、アトラシアンが管理するすべてのグループから一度に外す。
• 次の同期の後にもう一度確認し、本人に確認する。
• 見つけた経路と、それぞれについて決めたことを記録する。