本文へスキップ
SaaS Shift
日本語English
Productivity

グローバルプロジェクトをJiraで管理する方法｜PMOが実践する基本設計

著者
SaaS Shift 編集部
公開
最終更新
読了時間
約13分

この記事の要約

チャットや個人の頭に散らばるプロジェクト情報を、誰でも追える状態へ。Jiraを課題のContextの中心として設計するPMOの考え方と、属性・JQL・Dashboard・Automationの実務設計を整理します。

グローバルプロジェクトをJiraで管理するときの結論

グローバルPJで効くのは、Jiraの機能を増やすことではありません。追跡すべき課題の状態とDiscussionを、合意した場所（多くはJira）へ戻し、誰でも「何が・誰が・いつまでに・何待ちか」を追える状態をつくることです。優秀な人が集まれば平常時は回ります。管理の価値が表れるのは、遅延・障害・人員変更・Dependencyの破綻が起きたときです。

この記事でわかること:

  • 「PMが知っている」と「プロジェクトが管理されている」の違い
  • Microsoft Teamsなどのチャットに散らばる情報を、課題のContextとしてJiraへ戻す考え方
  • 属性 → JQL / Filter → Dashboard → Automation のつながり
  • フィールド増やしすぎを避け、StatusとLinksで状態を表現する実務設計

仕様・プラン・用語は変わりやすいので、最終判断はAtlassian公式もあわせて確認してください（本稿は2026年9月時点）。

Jiraのwork item（作業項目）work item

Jiraで追跡する仕事の単位です。Story、Bug、Taskなどのwork typeとして表現されます。Jira Cloudでは従来のissueからwork itemへの用語移行が進んでいます（What is a work item?）。

なぜグローバルPJではJira設計が重要になるのか

国内の少人数チームでも、進捗の見えにくさは起きます。グローバルではコストが上がります。

説明用の仮想構成です（特定の実在プロジェクトではありません）。作業は次のチームをまたいで進みます。

  1. Tokyo PMO
  2. US Product
  3. India Engineering
  4. Europe Security / Japan Business

ここで起きやすいこと:

  • タイムゾーン差で、全員が同じ会議に出られない
  • Teams / メール / DM / 個人メモに会話が散る
  • 「誰の返答待ちか」が会話参加者以外に見えない
  • Dependencyが国・チームをまたぎ、一つの遅延が連鎖する
  • PMだけが全体像を知り、他メンバーは自分のチケットしか見ない

平常時は、経験のあるメンバーが頭の中で全体像を補完できます。 正直何事もなければそれでいいと思うんです。ただ、PJには予測不能な出来事（しかもよくない方の）がつきもの。 何かが起こった時に、しっかり管理できていないと小さなズレが大きなズレに、そしてゆくゆくはトラブルにつながっていきます。

ExcelのWBS中心で管理していた頃によく起きるのも同じ系統の問題です。表上はタスクが並んでいても、構造や依存関係が見えにくく、遅延が出たときに「どこまで影響するか」の特定に時間がかかる。影響が芋づる式に後から見つかる。人員が交代したときは、全体像を理解してもらうのにまた時間がかかる。Jira設計の目的は、こうした「探すコスト」を平時から下げることにあります。

「PMが知っている」と「プロジェクトが管理されている」は違う

優秀なエンジニアや経験者は、細かなタスクまで頭で把握できます。何も起きなければ、それでも進みます。

しかし、問題なく進んでいる状態と管理された状態は同じではありません。

次が起きたとき、情報の置き場が試されます。

  • 担当者が突然休む / チームを離れる
  • 仕様変更やリリース障害
  • 他チームの遅延
  • 過去の意思決定の確認
  • 3ヶ月前の変更が現在の障害に関係している

情報が個人の頭やTeamsのスレッドにしかないと、「誰が何を知っているか」を探すところから始まります。Jiraを見れば、何が・いつ・誰が・何に影響するか・これまで何が行われたかを追えるチームは、対応の出発点が違います。

可視化はPMのための監視ではありません。各メンバーが、自分への影響・他チームへの影響・Dependency・次のActionを判断しやすくするための仕組みです。

平常時ではなく、問題が起きたときに管理の質が出る

プロジェクト管理の仕組みは、何も起きていないときには価値が見えにくいものです。価値が表れるのは、障害・遅延・人員変更・Scope変更・Dependencyの破綻・Escalationが起きたときです。

根拠のない「○倍速くなる」といった表現はしません。実務として言えるのは、探し始めのコストが大きく違うということです。影響範囲の洗い出しが、記憶とチャット検索頼みか、チケットとLinksから辿れるか。人員交代時に、口頭説明だけで全体像を渡すか、チケットとコメント履歴で補えるか。差が出るのは、だいたいこういう局面です。

誰でも理解できる、を評価基準にする

成功を「PMが管理しやすくなった」だけで測らない。理想は次です。

  • エンジニア → 自分への影響が分かる
  • Business → Releaseへの影響が分かる
  • PM → Project Healthが分かる
  • PMO → Cross-team Dependencyが分かる
  • Leadership → Escalationが必要な問題が分かる

情報の民主化、と言ってもよい考え方です。運用では「そのチケットを開けば最低限のContextがある」状態を、チームの共通ルールにします。

チャットにプロジェクト情報を散らばらせない

コミュニケーション自体をJiraに全部入れる必要はありません。大原則は次です。

プロジェクトとして追跡する必要がある情報は、チームで合意した場所へ戻す。

Microsoft Teams上でこう話すことはよくあります。

「APIの仕様変更が必要そう」 「USチームに確認しておきます」 「来週まで待ちましょう」

スレッドだけに残ると、会話に参加していない人には次が見えません。

  • 課題が存在すること
  • 誰が対応しているか
  • いつまでに必要か
  • 現在どうなっているか
  • 何がこの回答を待っているか

Jiraへ課題として残すことで、見えない課題を減らします。

Before / After

Before（Teams）

「APIの仕様どうなりました？」 「USに聞いてます」 「先週聞いたと思います」 「誰が確認してましたっけ？」 「○○さん今日は休みです」

→ 状況が分からない

After（Jira）

  • Summary: API specification clarification
  • Assignee: 今ボールを持つ人（標準フィールド）。US承認待ちならUS側の担当者
  • Status: Review（この例ではWorkflow上のStatus。USが承認先なら Review、作業中なら In Progress など。標準の固定Status名ではない）
  • Due date: 2026-09-18（標準）
  • Priority: Highest / High など（標準）
  • Linked work items: Checkout implementation を blocks（標準のリンク機能）
  • Updated: 最終更新日（標準）
  • Comments: USへの質問・回答・影響確認・Decision

→ チケットを開けば、誰でも一定程度状況を理解できる

「Waiting for US」「Region = US」のような専用フィールドは必須ではありません。リージョン用のLabelやCustom Fieldで切り分けるより、Statusで状態を表し、Assigneeで今動く人を表すほうが更新が続きやすい、という運用もあります。

Jiraを「課題に関するコミュニケーションの中心」にする

一般的な「Jira = タスク管理」「チャット = Discussion」という単純な役割分担だけでは足りません。

重視したいのは、次です。

課題に関連するコミュニケーションは、可能な限りそのJiraチケットへ集約する。

API仕様のチケットがあるなら、質問・回答・追加確認・調査結果・Blocker・他チーム依頼・意思決定・経緯・Status変更理由など、その課題を理解するために必要なDiscussionは、可能な限りチケット上に残します。

なぜTeamsだけでは不十分か

リアルタイムには便利です。一方でプロジェクト管理では次が起きやすいです。

  • チャネル / スレッド / チャットに分散する
  • 後から参加した人が経緯を追いにくい
  • どのDiscussionがどの課題に紐づくか分かりにくい
  • 数週間後の検索コストが高い
  • Status / Owner / Deadline / DependencyとDiscussionが分離する

グローバルでは、その場にいた人だけが理解できるコミュニケーションへの依存を減らす必要があります。

Teamsを禁止する意味ではない

向く場面もあります。緊急連絡、短い確認、チケット化前の相談、雑談、即時性の高い連絡などです。

ただし、会話の中で「これは追跡が必要」と判断した時点でJiraへ移します。

  1. Teams：「APIのレスポンス仕様が変わっているようです」
  2. 「CHECKOUT-123 を作ったので、ここからはこちらで確認しましょう」
  3. Jira上で US Product へ確認 → 回答 → India Engineering が影響確認
  4. Link追加 → 仕様確定 → Status更新

ここでの落とし穴は、キックオフで一度アナウンスすれば定着する、と思い込むことです。スレッドの使い方と「追跡事項はJiraへ」を周知しても、その後も会議の中で繰り返し戻す働きかけが必要になることが多いです。会議の締めに「今日決まったActionとDecisionは、どのチケットに残したか」を確認するだけでも、散逸は減ります。

Meetingも同じです。複雑な議論は会議で構いません。終了後に、Decision / Action / Blocker / Dependency / Deadline変更 / Scope変更をJiraへ反映します。詳細議事録や設計はConfluenceに置き、Jiraからリンクします。

目指す習慣は、**「その課題について知りたければ、まずJiraを開く」**です。JiraはタスクDBではなく、課題のContextを蓄積するEntry Pointになります。

非同期管理が必要な理由

時差がある一日の例です。

  1. Tokyo 18:00 — USに質問し、Tokyo側は退勤
  2. （時差）USが回答する
  3. Indiaが作業を開始する

リアルタイム会議だけで回す設計は、このリズムに合いません。必要なのは次の組み合わせです。

  • Synchronous Communication（会議・通話）
  • Asynchronous Project Management（Jiraを中心にした状態共有）

チャットは「今そこにいる人」と話すのに向きます。Jiraは、今いない人・数時間後に働き始める人・数週間後に参加する人にContextを残すためにも使えます。Teamsで速く決めても、チケットに戻さなければ、次のシフトのチームには届きません。

Jiraを「タスク一覧」ではなくプロジェクトの状態として設計する

チケットが100件あっても、それだけでは管理とは言えません。各課題で追跡したいのは次です。

  • What / Who / When / Status
  • Blocker / Dependency / Impact / Next Action

Jiraは「やることを登録する場所」ではなく、プロジェクトの現在地を構造化して残す場所です。

属性が揃っていると、Status Reportの材料集めも変わります。チャットやメール、個人の記憶を読み直して状況を組み立てるのではなく、Due切れ・未更新・優先度の高い課題から論点を拾える。報告書そのものがゼロになるわけではありませんが、「何が論点か」を探す時間が減ります。

チケットにどんな属性を持たせるべきか

重要なのは入力そのものではなく、後から検索・集計できることです。

まず使う標準寄りフィールド（2026年9月時点）

フィールド役割の例
Status現在地。作業中なら In Progress、承認待ちなら Review など
Assignee今ボールを持つ人（承認先がUSならUS側へ付け替え）
PriorityHighest から順に見るための緊急度
Due date期限
Parent / Epic大きなまとまり
Linked work itemsDependency（blocks / is blocked by 等）
Description / CommentsWhat・Discussion・Decision
Fix Version / VersionsRelease単位（使う場合）
Flaggedblockedの視覚的印（使う場合。Flagged = Impedimentで検索可）

LabelsやComponents、TeamフィールドもJira上は利用できます。ただし「リージョンごとに切る」「待ち先をLabelで管理する」運用は、分類が増えるほどメンテが必要です。実務では、リージョン用の切り分けを増やさず、StatusとAssigneeで状態を表す方針もあります。

Custom Fieldは増やしすぎない

PMOは可視化したい情報が多いため、Custom Fieldを増やしたくなります。一度作り始めると項目が増えやすく、次のループに入ります。

  1. Fieldを追加する
  2. 入力項目が増える
  3. 更新が面倒になる
  4. メンバーが更新しなくなる
  5. 情報が古くなる
  6. Dashboardが信用されなくなる
  7. 結局チャットで確認する

原則は、取得できる情報ではなく、意思決定に必要な情報から逆算することです。標準フィールドとStatus / Linksで足りるなら、Custom Fieldは避けたほうが運用は続きやすいです。

Due dateも混同しやすいです。外部約束・内部目標・Dependency前提日を同じ欄に入れると、何が本当の遅延か分かりません。

JQL / Filterで「プロジェクトに質問する」

JQLは検索文法であると同時に、PM/PMOにとってはプロジェクトの状態への問いです。

以下は標準フィールド中心の例です。CHECKOUT は架空のSpace key（JQL上は project）に置き換えてください。

Due date切れ（未完了）

project = CHECKOUT AND duedate < now() AND statusCategory != Done
ORDER BY duedate ASC

数日動いていない未完了（例: 3日）

project = CHECKOUT AND statusCategory != Done AND updated <= -3d
ORDER BY updated ASC

優先度の高いものから

project = CHECKOUT AND statusCategory != Done
ORDER BY priority DESC, duedate ASC

Review中（承認待ちのStatus運用がある場合）

project = CHECKOUT AND status = Review AND statusCategory != Done
ORDER BY priority DESC

Release単位（Fix Version利用時）

project = CHECKOUT AND fixVersion = "Checkout Go-Live"
AND statusCategory != Done

「USチーム待ち」をRegion LabelやCustom Fieldなしで見るなら、Statusが Review でAssigneeがUS側、という見え方になります。標準の「Waiting for US」フィールドはありません。自社でCustom Fieldを追加している場合だけ、そのField名でFilterしてください。

保存したFilterは、DashboardやAutomationの土台になります。

Dashboardでチーム全体を可視化する

Dashboardは、PMが報告資料を作るためだけのものではありません。メンバー自身が「何が詰まっているか」「今誰のActionが必要か」を見るための画面です。

Filter Resultsなどのgadgetに、保存済みFilterを載せる構成が一般的です。

まず載せたいもの（実務で使いやすい例）

  • Due Date切れ
  • 数日以上更新されていないもの（Stale）
  • PriorityがHighest / Highのもの（優先度順）
  • Review中（承認待ち）
  • Unassigned（任意）

リージョン別ガジェット（Japan / US / India…）は、LabelやComponent運用がある場合の選択肢です。リージョン切りをしない方針なら、無理に作る必要はありません。Status・Priority・Due・更新日で十分にHealthは見えます。

週次会議のアジェンダ順をDashboard順にすると、閲覧と更新が続きやすいです。

Dependencyを見えるようにする

グローバルPJでは、単独チームの進捗よりチーム間Dependencyがリスクになります。

架空の流れです。

  1. Japan Business — Requirement
  2. US Product — Design
  3. India Engineering — Development
  4. Japan Business — UAT

「Task Aが遅れている」だけでなく、遅れると何が影響を受けるかを追います。ExcelのWBSだけでは、この伝播が見えにくいことが多いです。

TimelineとLinksを中心に見る

実務で扱いやすいのは、次の組み合わせです。

  1. Timelineで期間と並びを俯瞰する（単一space内の計画ビュー。2026年9月時点で各プランから利用可能な基本ロードマップ側）
  2. Linked work itemsで依存を明示する
    チケット画面のLinksから、関係に合うリンクタイプを選びます。例:
    • blocks / is blocked by … 先行が終わらないと後続が進まない
    • relates to … 関連はあるが硬い依存ではない
    • clones / is cloned by … 複製関係
    • duplicates / is duplicated by … 重複
  3. 複数space・複数チームを横断して高度に計画したい場合は Plans（Premium / Enterprise）（What are plans in Jira Premium?）

例えば、API仕様チケット（CHECKOUT-123）が実装チケット（CHECKOUT-221）を blocks しているなら、仕様が止まっている時点で実装側への影響が見えます。Timeline上の並びと、Linksの関係の両方を見るのがポイントです。

Blockerの表現も唯一解はありません。StatusをReviewのままにする、Flagを立てる、コメントに解除条件を書く。本質は「何に止まっていて、誰のActionで解除されるか」です（Flagを使う場合: Flag a work item）。

Automationで「PMの頭の中の管理」を減らす

大規模になるほど、PMが頭で覚える管理には限界があります。

「数日動いていない」「Dueが近い」「このEpic配下にタスクが増えた」

Automationの目的は人を監視することではありません。人間の記憶に依存したプロジェクト管理を減らすことです。抜け漏れ防止、認知負荷の低減、時差があるチームへの非同期フォロー、運用の一貫性につながります。

利用量はプランによって上限があります（How is my usage calculated?）。ルールは必要最小限から始めます。

まず効きやすい例

1. 数日動いていないチケットの通知（Stale）

  • Trigger: Scheduled（毎日）+ JQL（例: 未完了かつ updated <= -3d）
  • Action: Assigneeへ通知、またはコメント

2. Epic配下にタスクが追加されたときの自動ラベル付与

  • Trigger: work item作成（またはParentが設定された）
  • Condition: 特定Epicの子である
  • Action: あらかじめ決めたLabelを付与

ここでLabelを使う目的は、リージョン分類ではなく、Epic単位のまとまりを後からFilterしやすくすることです。手作業の貼り忘れを減らす用途に閉じると、Label乱立を防ぎやすいです。

必要に応じて足す例

Due接近

  • Trigger: Scheduled + JQL（例: duedate = startOfDay("+3d") AND statusCategory != Done）
  • Action: Assigneeへ通知
    ※ Due date経過を直接トリガーする専用Triggerはないため、Scheduled + JQLが一般的です（Due date based rule）。

Dependency解除

  • Trigger: Issue transitioned → Done
  • Branch: Linked work items（blocks している後続）
  • Action: 後続のAssigneeへ通知

通知を増やしすぎると無視されます。最初は「未更新通知」と「Epic配下の自動整理」など、運用負荷が低いものからで十分なことが多いです。

Jira・Confluence・Teams・Meetingの役割分担

「情報をJiraに集約する」は、「すべてをJiraに書く」ではありません。

役割分担の例（運用合意用）
場所主な役割戻すもの
Jira課題の状態・Action・Owner・Deadline・Dependency・課題Discussion追跡すべき課題と、そのContext
Confluence仕様・Decisionの詳細・背景・長いドキュメント会議の詳細議事録、設計書
Microsoft Teams即時確認・緊急・チケット化前の相談追跡が必要になった瞬間にJiraへ移す
Meeting複雑な議論・調整・対立解消決定・Action・期限変更をJira（詳細はConfluence）へ

Chatで発生した追跡事項はJiraへ。Meetingで決まった残すべき意思決定は適切な正本へ。この「戻す」習慣がないと、どれだけフィールドを整えてもDashboardは古くなります。Slackを使う組織でも考え方は同じです。ツール名より、課題の正本をどこに置くかが本質です。

架空グローバルPJで見る具体例

以下は架空事例です。

日本企業のグローバルECプラットフォーム刷新

  • 目的: 新Checkout Platformを日本市場へ導入
  • 期間: 6ヶ月
  • 参加: Japan Business / Tokyo PMO / US Product / India Engineering / Europe Security
  • Space key例: CHECKOUT

Epic例

  • CHECKOUT-1 Requirements
  • CHECKOUT-10 Checkout UX / API Design
  • CHECKOUT-20 Payment Integration
  • CHECKOUT-30 Security Review
  • CHECKOUT-40 UAT & Cutover

1チケットの見え方（例）

CHECKOUT-123 API specification clarification

  • Assignee: US側の承認担当（ボールを持つ人）
  • Status: Review
  • Due date: 後続実装に間に合わせる期限
  • Priority: Highest
  • Linked: CHECKOUT-221（実装）を blocks
  • Comments: Teamsから移した質問、US回答、Indiaの影響確認、最終Decision

リージョン用Labelや「Waiting On」Custom Fieldは使わない想定です。誰待ちかは Status + Assignee で読みます。

Timeline / Links / Dashboard / Automationのつながり

  1. TimelineでEpicと主要タスクの期間を置く
  2. 依存はLinksで明示する（例: 要件 blocks 設計、設計 blocks 実装）
  3. Dashboardで Due切れ / 未更新 / Highest を見る
  4. Automationで未更新通知と、Epic配下タスクへの自動Labelを回す

この一本の線が、Status Reportの材料集めや「進捗どうですか？」の削減につながります。

Jira運用でよくある失敗

  1. Statusが多すぎる — 工程表をStatusにした結果、更新されない。In Progress / Review / Done など、Actionが変わる状態に抑える
  2. Custom Fieldが多すぎる — 一度作り始めると増殖しやすい。標準フィールドで足りるか先に確認する
  3. リージョン用Labelで切りすぎる — 分類のための分類になりやすい。待ち先はStatusとAssigneeでも表現できる
  4. Assigneeが常にPM/PMO — ボールの所在が消える。PM/PMOしかできないタスク以外は、すぐにAssigneeを振る
  5. Due dateの意味が混在 — 約束と内部目標を混ぜない
  6. Teamsで決まり最新状況がJiraにない — 初回アナウンスだけで終わらせず、会議で実際に画面を使いながら進めることで、更新と周知を徹底する
  7. チケットが何日も更新されない — Filter + Automation を活用し、検知する
  8. JiraとExcelの二重管理 — 依存が見えないWBSへ戻ると、遅延時の影響調査が再び重くなる
  9. Dashboardを誰も見ない — 習慣化を促すだけでなく、Due切れ・未更新・Highestなど、会議で実際に使うFilterだけ載せる
  10. Automationがうるさい / 目的化する — 監視ではなく、記憶依存を減らすために使う

AI時代にPM/PMOの役割はどう変わるか

2026年9月時点で、Jira / Atlassian側にはコメント要約、自然言語検索、説明文の下書き、Slack / Microsoft Teamsテキストからのwork item化、Automationの自然言語作成支援などがあります（Explore AI features、Rovo in Jira）。ClaudeやChatGPTは、議事録からのAction抽出やStatus Report下書きにも使えます。

方向性は、情報収集・整理をAIに寄せ、人間のPM/PMOはDependency・Risk・Decision・Communicationに時間を使う、です。AIがPMOを代替する話ではありません。正本が弱いと、AIは古い矛盾した情報を速く要約するだけになります。

まとめ

優秀な人が集まれば、仕組みがなくてもプロジェクトは回るかもしれません。しかし管理の価値が最も表れるのは、何かが起きたときです。

情報を個人の頭やチャットだけに置かず、誰でもプロジェクトの状態を追えるようにする。JiraはPMがメンバーを管理するためではなく、チーム全体が同じ課題のContextを共有するために使う。人間が覚えておく必要のない管理はAutomationに任せる。

そうすることでPM/PMOは、「進捗を聞いて回る人」ではなく、Dependency・Risk・Decision・調整に集中しやすくなります。

Jiraは万能ではありません。フィールドを増やしすぎれば更新が止まります。初回の周知だけでは、チャットへの散逸も止まりません。それでも、グローバルで時差があるチームほど、「誰かに聞かないと分からない」状態を減らす設計の価値は大きくなります。

よくある質問

グローバルプロジェクトではJiraに何を登録するべき？
追跡が必要なAction、Owner、Status、Deadline、Dependency、Blocker、およびその課題の理解に必要なDiscussionとDecisionです。長い仕様書全文や雑談まで入れる必要はありません。また、入れ子になりすぎないようにタスク構造をどうするかは事前によく設計して下さい。
Microsoft TeamsとJiraはどう使い分ける？
即時の短い確認や緊急連絡はTeams、追跡が必要になった瞬間から課題のContextはJiraへ寄せます。単純に『チャット=議論、Jira=タスク』と切り分けるより、課題に紐づく議論はチケットへ集約する運用がグローバルでは効きます。初回アナウンスだけでなく、会議での継続的な戻しも必要です。
JiraのStatusは何個くらいがいい？
唯一の正解はありません。工程をすべてStatusにすると更新が止まりやすいです。作業中はIn Progress、承認待ちはReviewのように、チームがActionを変える状態に抑える考え方があります。
JiraのCustom Fieldは増やしてもいい？
増やせます。ただし一度作り始めると増殖しやすく、更新負荷も上がります。標準のStatus・Assignee・Due date・Linksで足りるかを先に確認し、Dashboardで毎週使う項目以外は必須にしない方が安全です。
Jira Automationで何を自動化するべき？
数日動いていないチケットの通知や、Epic配下にタスクが追加されたときの自動Labelなど、人間の記憶や手作業に依存しやすいものから始めるのが扱いやすいです。監視目的の通知乱発は避けます。
Jiraだけでプロジェクト管理はできる？
小規模なら近い状態も取れます。実務では仕様・長い意思決定はConfluence、即時連絡はTeams、複雑な調整は会議と組み合わせるのが一般的です。重要なのは『どこに何を戻すか』の合意です。

参考・一次情報

  1. What is a work item?（Atlassian Support） 2026-09参照
  2. Update a work item's details（Atlassian Support） 2026-09参照
  3. Flag a work item（Atlassian Support） 2026-09参照
  4. What are plans in Jira Premium?（Atlassian Support） 2026-09参照
  5. Master Planning with Jira Plans（Timeline / Dependencies）（Atlassian） 2026-09参照
  6. Jira Cloud automation（Atlassian Support） 2026-09参照
  7. Trigger an automation rule based on a due date field（Atlassian Support） 2026-09参照
  8. How is my usage calculated?（Automation）（Atlassian Support） 2026-09参照
  9. Explore AI features（Atlassian Support） 2026-09参照
  10. Rovo in Jira: AI features（Atlassian） 2026-09参照

タグ