先に結論
Cursor in Jira は、Jira を見ながら「この ticket を誰が触るか」を決める画面を、そのまま AI 実装の入口に変える更新です。
価値は分かりやすいです。issue を別の画面へ持ち出さなくても、assign か @Cursor で cloud agent を起動でき、終わると Jira に PR リンクまで返ってきます。
ただし、すぐに全チーム向けの話ではありません。前提はかなり明確です。
- Jira は Commercial Cloud が前提
- Rovo の有効化 が必要
- Cursor は Teams / Enterprise 限定
- GitHub か GitLab 接続 が必要
- Cloud Agent は usage-based pricing を有効にする必要がある
- HIPAA、FedRAMP、Government Cloud は非対応
要するに、導入判断の最初の論点は「便利そうか」ではなく、自社の Jira と Cursor の契約・権限条件で動くか です。
何が変わったのか
2026-05-19 の Cursor changelog で、Cursor は Jira integration を一般公開しました。
できることはシンプルです。Jira work item を Cursor に assign するか、コメントで @Cursor と書くと cloud agent が起動します。agent は ticket の title、description、comments と team の repository settings を読み、作業範囲を決めます。
終わると Jira 側に進捗更新と完了サマリーが出て、PR を作った場合はそのリンクも返ります。
ここが大きいです。今までは Jira が管理画面、実装は IDE や別の agent 画面、という分断が残りがちでした。Cursor in Jira は、その切れ目をかなり短くします。
Jira 起点の実装導線そのものを比べたいなら、GitHub Copilot for Jira とは？Jira起点のAI開発をどう回すか も合わせて見ると位置づけがはっきりします。
まず確認すべき導入条件
導入前に見るべき条件は5つです。
1. Jira Commercial Cloud と Rovo が前提
一番大きい制約はここです。公式 docs では、Cursor Jira integration は Jira Commercial Cloud with Rovo enabled を前提にしています。
Jira を使っていても、Data Center や Government Cloud を前提にしているなら、この時点で候補から外れます。
2. Cursor Teams / Enterprise でしか使えない
個人向けの軽い連携ではありません。Cursor 側の要件は Teams または Enterprise です。
つまり、単に開発者が個人で Cursor を使っているだけでは足りません。管理者権限を持つ team 単位の導入が前提になります。
3. Cursor admin と Jira admin の両方が要る
初期設定を進めるには、Cursor admin と Jira site admin の権限が必要です。
実務ではここが詰まりやすいです。開発チームだけで前に進めず、Jira 管理者や IT 管理側との調整が必要になります。
4. GitHub か GitLab 接続が必要
PR を返す導線まで使うなら、Cloud Agent 側で GitHub か GitLab を接続しておく必要があります。
あわせて default repository、model、base branch も決めておかないと、ticket を投げてもどこで作業するかが曖昧になります。
5. usage-based pricing を避けられない
Cloud Agent を動かす以上、usage-based pricing の有効化が必要です。
ここは導入障壁でもあります。IDE での補完やチャットだけを想定していたチームは、agent 実行を誰がどの予算で持つか まで決めないと運用に入りません。
assign と @Cursor はどう使い分けるべきか
両方とも起動方法ですが、向く場面は少し違います。
ticket の内容が固まっているなら assign
issue の説明が十分に書けているなら、assignee を Cursor に変えるだけで始められます。
担当者を AI に置き換える感覚に近いので、Jira の運用を崩しにくいです。定型の不具合修正や、受け口がはっきりした改善ではこちらが楽です。
追加指示を入れたいなら @Cursor
コメントで @Cursor を使うと、同じ場所で追加の指示を足せます。
docs では repo、branch、model をコメントに明示できます。たとえば「この release branch で直したい」「この repo に限定したい」といったケースでは、assign よりこちらの方が扱いやすいです。
つまり、ticket をそのまま実装に渡すなら assign、補助条件を付けて投げるなら @Cursor と考えると分かりやすいです。
認証方式は早めに決めたほうがいい
Cursor in Jira には 2 つの認証モードがあります。
- service account authentication
- user-level authentication
service account は、team の Cloud Agent 設定を使って共通の実行基盤で回す方式です。導入は早いですが、誰の設定で動いたかより、チーム設定の一貫性を優先する運用になります。
user-level authentication は、各ユーザーが自分の Cursor アカウントを接続して使う方式です。自分の running agents を追いやすくなりますが、各自の接続と設定確認が増えます。
小さく始めるなら service account の方が素直です。個人ごとの可視性や責任分界を重く見るなら user-level authentication が向きます。
repository routing が実運用ではかなり効く
複数 repo を抱えるチームでは、どの ticket をどの repo に送るかがすぐ問題になります。
Cursor はここを routing rules で補えます。キーワードと repository をひも付けておけば、work item や comment に含まれる語から repo を選びやすくなります。
たとえば frontend、mobile、api のような語で repo を振り分ける設計です。
この機能が効くのは、monorepo より multi-repo のチームです。Cursor の execution environment 側まで含めて見たいなら、Cursor cloud agent development environments vs Codex vs GitHub Copilot｜実行環境・監査・複数repo運用で選ぶ がつながります。
どのチームに向いているか
一番相性がいいのは、Jira を backlog と実行の両方の入口にしたい組織です。
特に向いているのは次のようなチームです。
- backlog は Jira で回している
- 実装の handoff を PM から開発へ短くしたい
- PR を GitHub か GitLab に返す流れを標準化したい
- agent ごとの repo 選択や branch 指定を ticket 側で管理したい
逆に、planning layer を主役にしたいなら Linear 系、Jira 内で複数 agent を orchestration したいなら Jira Agents 系の方が自然です。このあたりの位置関係は Linear Agent vs Jira Agents vs GitHub Copilot for Jira を比較 で整理しています。
見落としやすい制約
便利さの前に、次の制約は先に押さえたほうが安全です。
regulated 環境ではそのまま入れにくい
公式 docs では、Atlassian HIPAA、FedRAMP、Government Cloud は非対応です。
導入判断を進める前に、Jira 環境の区分を確認した方が早いです。ここが合わないと、設定や比較を詰めても前に進みません。
Privacy Mode の条件も確認が要る
Cloud Agents は Privacy Mode をサポートしますが、Legacy の Privacy Mode は非対応です。agent 実行には一時的なコード保存が必要とされています。
つまり、社内で「Cursor は privacy mode だから大丈夫」と一言で済ませず、どのモードを指しているかまで確認した方がいいです。
導入後も default settings が弱いと迷子になる
repo、model、base branch、routing rules が曖昧なままだと、Jira から起動できても毎回迷います。
この手の連携は、起動できるかより 起動後に迷わないか の方が運用差になりやすいです。
まずやるべきチェックリスト
導入判断を急ぐなら、最初にこの順で確認するのが早いです。
- Jira が Commercial Cloud で、Rovo を有効化できるか
- Cursor Teams / Enterprise を前提にできるか
- Cursor admin と Jira admin を同じ導入プロジェクトに乗せられるか
- GitHub か GitLab を Cloud Agent に接続できるか
- usage-based pricing、default repo、base branch、model を決められるか
- regulated 環境や privacy policy の条件に引っかからないか
これを通せるなら、Cursor in Jira は「ticket を見てから IDE を開く」までの往復をかなり減らせます。
まとめ
Cursor in Jira の本質は、Jira と AI coding agent の距離を縮めたことです。
assign か @Cursor だけで始められる導線は強いですし、PR まで返るので、開発マネージャーや platform team にも説明しやすい更新です。
一方で、導入条件は軽くありません。Commercial Cloud、Rovo、Teams / Enterprise、Git 接続、usage-based pricing、非対応環境まで含めて、最初にふるいにかける必要があります。
そこを満たせる組織なら、Cursor in Jira は単なる連携追加ではなく、ticket から PR までの時間を短くする実務機能 と見てよさそうです。