---
title: Jira Cloud移行：ID・グループ統合と権限引継ぎ
tags: 
author: [Fumiya Okazaki](https://image.docswell.com/user/FumiyaOkazaki)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JQYW46L7P.jpg?width=480
description: Jira Cloud移行の時に気を付けるポイントとして個人的に考えていたことを備忘したガイドです。
published: September 07, 26
canonical: https://image.docswell.com/s/FumiyaOkazaki/Z3JY1D-2026-09-07-012736
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JQYW46L7P.jpg)

Jira Cloud 移行ナレッジ
Server/DCからCloudへの移行
ID・グループ統合と権限引継ぎガイド
認証キーの変換・グループ乱立回避・段階的移行を成功させる実践設計
岡崎 文哉
LOG Sprout合同会社


# Page. 2

![Page Image](https://bcdn.docswell.com/page/K74WKQ45E1.jpg)

LOG Sprout合同会社のご紹介
Mission
「想いを形に、未来を紡ぐ。」
人の多様な経験からなる小さな気づきを記録（LOG）し、積み
上げ、芽開く（Sprout）。
単なるツール移行で終わらせず、現場の限界を超える「質の高
い伴走」で組織の成長を牽引します。
© LOG Sprout G.K. All rights reserved.
会社概要
商号: LOG Sprout合同会社
ミッション: チーム伴走型ITイノベーションの推進
事業内容:
アジャイル開発・Jira活用定着コンサルティング
ITインフラ・ツール運用の伴走型業務改善支援、その他
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LJ1YXP42EG.jpg)

Cloud移行時に直面する「アカウント＆権限」の壁
Server/DC版のデータをそのまま移行しようとすると、アーキテクチャの違いによりトラブルが頻発します。
旧環境のデータ/権限を
そのまま一括移行
➔
キー不一致・重複発生
アカウント紐付け失敗
➔
グループ競合・多重化
権限設定の破綻・無秩序化
💡 本資料の位置付けと公式ガイドの参照について
本内容はAtlassianの移行案内から、特に現場で発生しがちな「ID・認証・権限」の課題をピックアップして特筆しています。
全体の最新手引きについては Atlassian 公式サイトの Jira Cloud 移行ガイド も併せてご参照ください。
© LOG Sprout G.K. All rights reserved.
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GJWGN2X272.jpg)

認証キーの違い：User ID から メールアドレスへ
旧 Server / DC 版の識別キー
User ID （例: john_doe）
LDAP / Active Directory の `sAMAccountName` 等に依存
メールアドレスが空白・ダミー値でもシステムは稼働可能
だった
ドメイン名を含まない一意の文字列で識別管理
© LOG Sprout G.K. All rights reserved.
Jira Cloud 版の識別キー
メールアドレス （例: john@acme.com）
Atlassian account の仕様により
メールアドレスが一意の鍵
移行ツール（JCMA）は「メールアドレス」をマッチング
キーとして移行
アドレスが不正だと、別ユーザーとして新規作成されるか
移行失敗
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4EZL3D6473.jpg)

メールアドレス不整合の3大トラブルと事前対策
1. メールアドレスの「空白」
2. 同一アドレスの「重複」
3. 「未所有外部ドメイン」
対策: AD/IdP側で
ダミー無効化アドレスを一括補完
対策: ユーザー単位の
一意な個人アドレスへ修正
対策: 社外用ドメイン払い出しまたは
招待フロー統一
旧環境で退職者やシステムアカウントの
メールアドレスが空欄になっている。
© LOG Sprout G.K. All rights reserved.
複数の旧User IDで同じ共通メーリングリ
スト宛先が登録されている。
社外パートナーの個人アドレス
（`gmail.com` 等）が
直登録されている。
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/Y76WX12G7V.jpg)

グループ管理構造の違い：インスタンス単位 から 組織単位へ
Cloud版は「組織（Organization）」で集中管理
Server/DC版ではJiraインスタンスごとにグループが完結していま
したが、Cloud版では上位の「Atlassian Organization（組織）」
全体でグループを共有します。
他製品や他サイト間でもグループを使い回せるメリットがある反
面、命名規則の重複や衝突が起きます。
© LOG Sprout G.K. All rights reserved.
既定グループ名の不一致（競合）
区分
アクセス権
管理単位
連携技術
Server / DC 版
`jira-users`
インスタンス個別
LDAP 直結
Cloud 版
`jira-software-users-`
Organization 全体
SAML / SCIM (IdP)
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/G75MX42X74.jpg)

移行時に発生する「グループ多重化・権限破綻」
旧グループのまま移行した際のアクシデント
旧環境の `jira-users` や社内共有グループをそのまま移行すると、
Cloud側の自動生成グループ（`jira-software-users-`）と二重登録
状態が発生します。
結果: 誰がライセンスを消費しているのか把握不能になり、異動・
退職時の権限剥奪漏れやライセンスコスト激増につながります。
© LOG Sprout G.K. All rights reserved.
単一のグループを複数用途で使い回さない
「ログイン権限」「管理者権限」「プロジェクトの閲覧権限」を
すべて1つのグループで兼務させている状態を解消しなければ、
Cloud移行後の権限統制は不可能です。
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/9J29XV4QER.jpg)

【解決策】グループ用途の3分離原則とライセンス要件
1. 製品アクセス用
ライセンス消費の制御
例: `jira-software-users`
SCIMプロビジョニング連携
プロジェクト権限に使用しない
2. グローバル権限用
全体の作成・管理権限
例: `jira-project-creators`
雇用形態属性（正社員等）と連動
特定管理者・責任者のみ付与
3. PJロール用
PJ内での配役・役割
例: `all-fulltime-employees`
PJロールに付与するIdPグループ
現場リードが柔軟に指定
📌 重要：Atlassian Guard std（旧Atlassian Access）のライセンス要件
IdP（Okta/Entra ID等）とSCIMプロビジョニング連携を行うには、Atlassian Guard Standard エディション以上 が必須です。
※ Cloud契約が Enterpriseプラン や Teamwork Collection の場合は Guard が標準付帯されます。それ以外のプラン（Standard/Premium）の場合は、個
別契約が必要かどうかのライセンス判断が事前に必要となります。
© LOG Sprout G.K. All rights reserved.
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/DEY483MYJM.jpg)

Active Directory を同一ソースとした並行連携アーキテクチャ
【単一マスター構成】同一 AD を起源とするデュアル同期アーキテクチャ
同一データソース
➔
LDAP
Atlassian専用OU
（グループ・メール精査済）
➔
同期Agent
Active Directory
【従来ルート】現行環境への同期
現行稼働維持
Jira Server / DC 版
【追加ルート①】クラウドIdP
IdP (Okta / Entra ID)
➔
SCIM
【追加ルート②】Cloud環境
Jira Cloud 版
※ IdP ➔ Jira Cloud への SCIMプロビジョニングには Atlassian Guard std が使用されます。
デュアル同期による最大のメリット：メンバー差分の即時追従
業務都合により移行期間中に人事異動・メンバー追加が毎日発生する環境であっても、Active Directoryを単一マスターとして両環境へ並行で直接
同期させます。
事前にSCIMでCloud側へ正しいアカウント・グループ基盤（受皿）を自動生成しておくことで、新旧環境間の乖離を最小限に抑えた安全な移行が
実現します。
© LOG Sprout G.K. All rights reserved.
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/VJNYQVWR78.jpg)

移行スケジュールの原則 と 大規模環境での「ウェーブ方式」
⚠️【大前提】移行は「極力短期間」でやり切る
💡【現実解】大規模環境での「ウェーブ方式」
クラウド仕様更新への追従:
JCMA（移行ツール）やCloud側仕様は頻繁にアップデートされるた
め、期間が長引くほど「事前リハーサルで未発生だった不具合」へ遭
遇するリスクが急増します。
二重管理コストの削減:
新旧環境の並行期間を短縮し、情シスの運用の負担を最小化します。
依存関係の薄い単位で分割切り替え:
独立性の高いPJ単位等に移行対象を切り分け（ウェーブ化）、影響範
囲を局所化します。
メンテナンス時間枠内で完結:
各ウェーブの移行を夜間・週末の短時間で完了させ、翌営業日からス
ムーズにCloud利用を開始します。
原則として、移行プロジェクトは長期化させず短期間で一気に切り
替えることが推奨されます。
© LOG Sprout G.K. All rights reserved.
PJ数やデータ量が膨大な環境では、一括移行だとメンテナンス時間
（夜間・週末）内に完了できません。
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YE9PD6XZJ3.jpg)

まとめ：ID・グループ移行 成功のための3つの鉄則
アカウントクレンジングとグループ用途分離で安全なCloud移行を実現
1. 移行前にメールアドレス（認証キー）の不整合を完全クレンジングする
（AD/IdP側で一意なメールアドレスを付与し、空白・重複・外部ドメイン問題を事前に解消する）
2. グループ用途を分離し、Atlassian Guard要件（SCIM）を事前確認する
（3分離原則を適用し、SCIMに必要なGuardライセンスの有無・個別の必要性を評価する）
3. デュアル同期で乖離を防ぎ、大規模環境では短時間ウェーブ方式で切り替える
（短期間移行を原則としつつ、事前にIdP経由でユーザー・グループのアカウント基盤（受皿）をCloud側に自動生成し、夜間・週末のメンテナ
ンス枠内でPJ切替を完遂する）
© LOG Sprout G.K. All rights reserved.
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/GE8D3Z9YED.jpg)

ご清聴ありがとうございました。
© LOG Sprout G.K. All rights reserved.
12