Jiraのチケットに@Cursorと書くだけでPRが届く — Atlassian公式連携が始まった

PMがJiraのチケットにコメントを書く。「@Cursor このバグ直して」。数分後、Jiraの画面にPRのリンクが表示される。

5月19日、AtlassianとCursorが公式連携を発表した。Jiraのワークアイテムから直接Cursorのクラウドエージェントを起動できるようになった。Microsoft Teams連携に続く、Cursorの「IDE外進出」の第2弾だ。

チケットを書く人と、コードを書くAIが直結した

これまでのJira × AIコーディングの組み合わせは、MCPサーバーを自分で設定する必要があった。Atlassian公式のMCPサーバーは存在していたが、あくまでCursor側からJiraを「参照する」方向。今回は逆だ。Jira側からCursorを「呼ぶ」。

やることはシンプルで、ワークアイテムに@Cursorと書くか、担当者としてCursorをアサインするだけ。Cursorのクラウドエージェントがチケットのタイトル・説明・コメント・チームのリポジトリ設定を読み取り、タスクを開始する。

バグ修正、機能追加、テスト更新、調査――チケットに書かれた内容をスコープとして、エージェントが自律的にコードを書く。完了したらJiraにステータスが反映され、PRのリンクが自動で紐づく。

Rovo連携で「コンテキストの渡し漏れ」が減る

地味だが大きいのがRovoとの連携だ。AtlassianのRovoは、Jira・Confluence・Compass等のデータを横断的に検索・要約するAI機能。Cursor in Jiraでは、RovoがAtlassianのTeamwork Graphからコンテキストを自動で補完し、エージェントに渡す。

たとえば「先月のスプリントで議論した仕様変更の方針」がConfluenceにあれば、PMがいちいちリンクを貼らなくても、Rovoがそのコンテキストを拾ってくる。エージェントに渡す情報が手動コピペではなく、組織の知識グラフから自動供給されるわけだ。

正直、MCPサーバーを手動で設定していた時代と比べると、この「情報を渡す手間の削減」が一番のアップグレードだと思う。

Jira Automationとの組み合わせが本命

もう1つ見逃せないのが、Jira Automationとの連携。特定の条件を満たすチケットを自動でCursorにアサインするルールを作れる。

たとえば「bugラベルが付いた優先度Lowのチケットは自動でCursorに振る」というルールを設定すれば、人間が手を動かす前にAIが修正に着手している状態を作れる。これはCursor Automations（Slack/GitHub/PagerDutyトリガー）とはまた別の経路で、プロジェクト管理ツール側からエージェントを起動する新しいパターンだ。

もしこれがうまく回れば、PMがバックログのトリアージをした時点で、小さなタスクはAIが勝手に片付けている世界になる。スプリントプランニングの前にPRが揃っているのは、控えめに言って異常だ。

料金と前提条件

利用には2つの前提がある。

• Cursor側: Cursor Businessプラン以上（管理者権限が必要）
• Atlassian側: Jira Commercial Cloudの有料プラン + Rovo有効化

Rovo自体は有料プランに含まれており、追加料金はかからない。クレジットの月間上限はプランによって異なる。Standardで25クレジット/席、Premiumで70、Enterpriseで150。現時点ではAtlassianは超過課金をしておらず、課金開始の90日前に通知すると明言している。

Rovo Dev（開発者向け機能）を使う場合は月$20/開発者で2,000クレジットが付く。ただし、Cursor in Jiraの基本機能にRovo Devが必須かどうかは明確にされていない。

微妙なところ

懸念点もある。

まず、「エージェントが作ったPR」のレビュー負荷。小さなバグ修正なら問題ないが、機能追加レベルのタスクをJiraから丸投げすると、レビュアーがコンテキストを理解するのに結局時間がかかる。PMがチケットに書いた文章と、エンジニアが読むPRの粒度は本質的に違う。

もう1つは、Rovo有効化の前提条件。日本企業でJira CloudのRovoをすでに有効にしているチームがどれだけあるかは疑問だ。Atlassian Intelligence自体の日本語対応も完全ではなく、Teamwork Graphの精度が日本語ドキュメントでどこまで出るかは未検証だ。

Teams連携と何が違うのか

5月11日にはCursorのMicrosoft Teams連携も発表されている。構造は似ているが、想定ユースケースが異なる。

Teamsは「会話の流れからタスクを生成する」カジュアルな起点。「このバグ見てくれない？」というチャットからエージェントが動く。一方Jiraは「構造化されたワークアイテムからエージェントを起動する」フォーマルな起点。プロジェクト管理のコンテキスト（優先度、エピック、スプリント）が最初からある。

チームの文化によって使い分けが分かれるだろう。Slack/Teams中心のチームならTeams連携、Jira中心のチームならJira連携。どちらも「Cursorを開かずにエージェントを動かす」という方向は同じだ。

PMの仕事が変わる、エンジニアの仕事も変わる

Cursor in Jiraの本質は、AIコーディングエージェントの起動権限がエンジニアからPMに移ったことにある。

これまでAIコーディングは「エンジニアがIDEの中で使うもの」だった。プロンプトを書く技術、コンテキストを渡す工夫、出力を検証するスキル――すべてエンジニアの責務だった。Jira連携はその前提を崩す。チケットを書く人が、そのままコードの生成を発注できる。

エンジニアの役割は「コードを書く人」から「AIが書いたコードをレビューしてマージする人」にシフトする。すでにその傾向はあったが、Jira連携はそれを組織のワークフローレベルで制度化した。

このシフトが「効率化」になるか「カオス」になるかは、チームのPRレビュー文化とチケットの書き方の質にかかっている。雑なチケットからは雑なPRが生まれる。それはAIでも人間でも同じだ。

Cursor Changelog（05-19-26）