AIがJiraに入ってくる3つの道

3つの道、同じbacklog

2026年の今、AIそのものはもう珍しくありません。足りていないのは、どこに向けて使うべきかという判断です。

Jiraを中心に仕事をしているチームなら、すでにその流れを感じているはずです。AtlassianはRovoをプラットフォームの中に直接組み込みました。OpenAIとAnthropicは、ChatGPTやClaudeがbacklogを読めるようにするコネクタを公開しました。さらに、JustのようなForgeネイティブの新しいアプリ群も現れ、AIをissueパネルの中に直接置くようになりました。そこではJiraのチケットが、入力でもあり、結果の着地点でもあります。

3つの道。backlogは同じ。けれど体験は大きく違います。

つい「どれが一番いいのか」と考えたくなります。でも、たいていそれは本質的な問いではありません。もっと正直な問いはこうです。自分たちのチームの働き方に、本当に合っているのはどれか。

あるチームでは、重視されるのは統制された広い到達範囲です。別のチームでは、最先端モデルを自由に選べることが大事です。そしてまた別のチームでは、issueを離れずに複数のプロバイダを活かせる、Jira内のひとつの整理された流れこそが必要です。

ルート1: Rovo

RovoはAtlassian自身のAIレイヤーで、Jira Cloud、Confluence、Jira Service Managementに織り込まれています。人、プロジェクト、コンテンツの関係をAtlassianエコシステム全体でつなぐTeamwork Graphを土台にしており、Search、Chat、Agentsの3つを柱に展開されています。

• 強み: 届く範囲の広さ。 Rovo Searchは既存の権限を守りながら、Jira、Confluence、さらに多くのサードパーティ製アプリを横断して情報を引けます。知識があちこちに散っているチームには、とても相性がいいです。
• 強み: 導入判断がいちばん通しやすい。 プロバイダのキー管理も、モデル選定も、token予算の管理もいりません。統制はAtlassianの既存の権限と監査の枠内に収まります。料金の考え方も以前より分かりやすくなっていて、2026年時点ではRovoは個別の追加製品というよりAtlassian Cloudプランの一部として位置づけられ、利用可否や利用量はプランと割り当てにひもづいています。
• トレードオフ: 自由度は低く、issue単位では深く入りにくい。 モデルは選べず、AIは仕事の中に入り込むというより、仕事の横に置かれます。issueパネルの中で構造化された計画の流れを動かす存在ではありません。

Rovoが向いているのは、複数の製品にまたがる情報探索が中心課題で、設定不要の統制された利用を最優先したい場合です。

ルート2: コネクタ

コネクタは逆の発想です。AIをAtlassianの中に閉じ込めるのではなく、JiraのデータをAIがすでに存在している場所へ持っていきます。たとえばChatGPT、Claude Desktop、Cursor、あるいはModel Context Protocol（MCP）に対応した任意のクライアントです。

• 強み: モデル選択の自由。 使えるのは外部クライアントが提供しているものです。今なら Claude Opus 4.6、GPT-5.4、Gemini 3.0 Pro、そして明日登場する新しいモデルも含まれます。
• 強み: 使い慣れた作業環境のまま進められる。 そのため、すでにClaudeやChatGPTやCursorの中で仕事をしている上級ユーザーにとっては魅力的です。最先端のモデルを使いたいけれど、新しい画面には移りたくない人に合います。今のこの橋渡しは、MCP経由で行われることが増えています。クライアントがAtlassianやサードパーティのMCPサーバーにつながり、Jiraの道具を見つけ、そのまま会話の中で使います。
• トレードオフ: 結局、統合のつなぎ役を人が担う。 誰かが都度情報を足し続けない限り文脈は浅いままですし、Jiraへの書き戻しはできても、きれいに構造化されていることは多くありません。しかも会話は基本的にひとつのクライアントの中だけに閉じます。認証も少し面倒で、Atlassian公式のMCPサーバーはOAuthを使うため、体験をなめらかにする目的でサードパーティの管理型コネクタを足すチームも少なくありません。

コネクタが向いているのは、Jiraの文脈を強力な外部AIに渡したい場面で、利用者がチーム全体の流れよりもモデルの柔軟性を重視する場合です。

ルート3: Just

Justは3つ目の道を取ります。ForgeネイティブのJiraアプリとして、AI体験をissueパネルの中に直接埋め込みます。ただの横チャットではなく、洞察の生成、確認、計画、実行、そしてJiraフィールドへの反映までを含む、ひと続きの構造化された流れとして扱います。

• 強み: 流れの深さ。 AIは別のクライアントにいるのではなく、チケットの中にいます。issueがそのまま入力でもあり、結果の反映先でもあります。
• 強み: 複数プロバイダを組み合わせられるJiraネイティブな仕組み。 Justは単なる一問一答ではありません。分析、確認、計画、Web調査、画像作業、実行、Jiraへの反映という流れを順に進めます。各段階は有効化も省略もレビューもでき、issueに触る前に人が確認できます。しかも最初から複数プロバイダを前提に作られているので、ステップごとに違うモデルを割り当てられます。再利用できるプロジェクト文脈、見える形の実行、token消費、コスト、フィードバックの循環を、ひとつの仕組みにまとめられるのです。
• トレードオフ: 設定はやや増え、プラットフォーム制約も受ける。 Justには試し始めるためのキーが用意されていますが、長期的には自前のプロバイダキーで従量課金運用する前提です。つまり少し踏み込んだ設定が必要になります。チームの誰かが組織用のAPI keyを接続し、作成し、管理しなければなりません。その代わり、AI利用量に個人差が大きいチームには向いています。全員に同じ固定の席コストを押しつけなくて済むからです。この予算面の違いについては、見落とされがちなAI予算の話で詳しく触れています。なおForgeアプリである以上、Atlassianの実行環境の制約の中で動く点は変わりません。

Justが向いているのは、複数のAIプロバイダの強みをJiraの中でひとつの見通しのよい流れにまとめたいときです。そのために少し多めの設定を受け入れられるなら、得られる制御は大きいです。

本当の違い: AIはどこにいるのか

機能一覧をいったん横に置いて、それぞれを本質だけで見ると、違いは構造にあります。

Rovoは地下鉄です。街全体をカバーしています。JiraからConfluenceへ、さらにGoogle Driveへも、ひとつの路線網の中で移動できます。路線は決まっていて、運行管理は任せる形です。

コネクタは配車サービスのようなものです。車も運転手も自分で選び、行き先も自由です。ただし道案内は自分でしなければならず、移動は基本的に個人のものなので、チームのほかの人には全体像が見えません。

Justは専用シャトルです。走る区間はひとつ、つまりJira issueだけですが、途中に確認ポイントがあり、流れも見えます。しかもJiraを離れずに、途中で使うプロバイダを切り替えることもできます。チーム全員が、今どこまで進んでいて、何を運んでいて、いつ着くのかを把握できます。

ルートの比較まとめ

比較全体を要点だけに絞ると、違いはかなりはっきり見えてきます。

つまり、この判断はとてもシンプルです。統制された広い到達範囲を取るのか、個人のモデル自由度を取るのか、それとも複数プロバイダの良さをJira内でまとめられる構造化フローを取るのか、ということです。

どの道を選ぶか

万人にとって唯一正しい道はありません。6つのSaaS製品を横断して情報を探す必要があり、しかも追加の基盤負担を増やしたくないチームなら、まずRovoから始めるのが自然です。

自分のクライアントから Claude Opus 4.6、GPT-5.4、Gemini 3.0 Pro を使ってbacklogを考えたいエンジニアなら、コネクタの方が合うでしょう。

一方、異なる段階で異なるプロバイダを使え、しかもコスト、品質、出力がチーム全体に見える、レビュー可能なJiraワークフローを求めるプロダクトチームやデリバリーチームなら、Atlassian Marketplace の Justを見る価値があります。

多くのチームは、実際には複数の道を併用するはずです。これらは互いに排他的ではありません。大切なのは、先週いちばん派手だったAIデモではなく、自分たちの実際の働き方と、本当に摩擦が生まれている場所に合わせて、意図を持って選ぶことです。