Jira Service ManagementにAIを追加する2つの方法
機能を比較する前に、これらは同じものの2つのブランドではなく、本質的に異なる形の意思決定であることをはっきりさせておくと理解しやすくなります。
- ルート1、純正のJSM AI。 AtlassianがService Collectionにすでに組み込んでいるAI、RovoとバーチャルサービスエージェントをONにします。新たにインストールするものはありませんが、機能とコストはAtlassianのプラン階層に紐づいています。
- ルート2、AIエージェント層。 JSMはそのままにしておき、専用のAIエージェントをAPI経由で接続します。リクエストとナレッジを読み取り、返信を作成・送信し、席単位ではなくリクエスト単位で課金されます。
この記事の残りの部分では、買い手が本当に必要とする詳細レベルで、それぞれのルートを順番に取り上げます。何をするのか、実際にいくらかかるのか、どこに適しているのかです。
ルート1：Jira Service Management純正のAIを有効にする
Atlassianは以前の「Virtual Service Agent」というブランドを、自社のAIプラットフォームであるRovoに統合し、現在のセルフサービスの説明はService Collection AIページに掲載されています。これは実際によく作り込まれたスタックであり、多くのチームにとって自然な最初の一手となります。すでに運用しているヘルプデスクにそのまま組み込まれているからです。
Atlassian自身のページによれば、このルートで得られるものは次のとおりです。
- バーチャルサービスエージェントは従業員や顧客のリクエストに自動で応答し、人間に届く前にチケットを振り分けます。ナレッジベースと過去のチケットを読み取り、対話形式で回答します。
- Rovoの検索・チャット・エージェントはAIチームメイトを追加し、Atlassianのデータ全体にわたって振り分け・作成・要約・発見を行います。
- AIOps機能、たとえばアラートのグループ化、AIによるインシデント作成、PIR生成は、インシデントと変更管理の面で役立ちます。
この裏側にあるデータはTeamwork Graphから来ており、Confluence、Jira、Slackなどからコンテキストを取得するほか、サードパーティのコネクタも利用します。すぐに否定しておくべき誤解の一つ：純正のJSM AIは「Google Docsを読めない」とよく言われますが、これは誤りです。Rovoのコネクタ一覧には、Google Drive、SharePoint、Slack、Zendeskなどが実際に含まれています。本当の制約は別のところにあり、それはコストと制限に関するものです。
ルート1の実際のコスト：3つの独立したメーター
これは購入者を驚かせる部分です。純正のJSM AIは1つの項目ではなく3つの項目であり、それぞれ異なる方法で計測されます。
| AIメーター | 必要なプラン | 課金単位 | 価格 |
|---|---|---|---|
| バーチャルサービスエージェント | PremiumとEnterprise | アシスト付き会話 | 月1,000件まで含む、それ以降は1件あたり0.30ドルから |
| Rovo Customer Service | Standard以上 | 解決件数 | 1件あたり1ドル、無料枠なし |
| Rovoクレジット | Standard以上 | ユーザーごとのクレジット | ユーザーあたり25 / 70 / 150（Std/Prem/Ent） |
この表の中で、単純な予測を最も狂わせるのは2つの詳細です。
1つ目は、バーチャルサービスエージェントはPremium機能だという点です。FreeとStandardでは単純に含まれていません。つまり現在Standardを使っているなら、対話型AIを追加するにはまずPremiumへアップグレードする必要があり、Premiumの公開されているリスト料金は小規模チームで1エージェントあたり月57.30ドルから始まります。このプランの引き上げこそが、このルートでのAIの本当のコストであり、会話単位の料金ではありません。
2つ目は、課金単位が「アシスト付き会話」であり、Atlassianはこれを解決件数よりも広く定義していることです。これはマッチした会話、つまり「バーチャルサービスエージェントが問題を解決したか、エスカレーションしたかにかかわらず、意図にマッチしたすべての会話」と、AIによって解決された会話の両方を数えます。後者では放棄された会話も解決とみなされます。つまり平たく言えば、AIがマッチさせて人間に引き渡したチケットも課金対象になり、単に離脱したユーザーも成功として数えられます。どちらも厳密には間違いではありませんが、「ボットが実際に解決したチケット分だけ支払う」という前提で予算を組むと、想定より不足します。
段階ごとの完全な内訳、エージェント席の段階的な料金を含む詳細は、私たちのJira Service Management価格ガイドと、専用のAtlassian IntelligenceとRovoの価格の解説記事で、ここより深く掘り下げています。
ルート1が本当に適している場面
純正AIは、特定のチームにとっては正しい最初の一手です。すでにJSM Premiumを使っていて、ナレッジがConfluenceにあり、1社・1つの請求書、そしてデフォルトでオンになっているAIを求めている場合です。AIOpsと変更リスクの機能はインシデントの多いチームにとって本当に強力で、Atlassianのエコシステムから決して離れないことには実際の価値があります。
摩擦が生じるのは、Standardを利用していてプランの引き上げを望まない場合、コストを厳密に予測したい場合、あるいは実際の人に回答する前に自分の過去のチケットでAIをテストしたい場合です。Atlassian自身のページは振り分け率や過去のリクエストに対するドライラン機能を公開していないため、このルートではオンにしてメーターを見守る傾向になります。それこそが、2番目のルートが埋めるために作られたギャップです。
ルート2：AIエージェント層を追加する
もう一方のルートはJSMをそのままにして、専用のAIエージェントを接続します。これはbest-ai-add-on-for-jiraというカテゴリーで、eeselのようなツールがここに位置します。プラットフォームの機能をオンにする代わりに、Atlassian Marketplaceからエージェントをインストールし、新入社員のようにサービスデスクに参加させます。
JSM内でエージェントが行うことは、人間のエージェントが行う作業と同じ種類のものです。リクエストを読み取り、返信を作成・送信し、内部メモを追加し、リクエストフィールドを更新し、優先度とSLAを設定し、チームへルーティングします。API経由で接続するため、PremiumだけでなくどのJSMプランでも動作します。
層を追加するルートの仕組み
このルートが信頼を得られる理由は、売り込みではなく導入プロセスにあります。スイッチを入れてうまくいくことを期待するようなことはしません。
- JSMを接続してインポートする。 エージェントは過去のリクエスト、ナレッジベースの記事、リクエストタイプを自動で読み取ります。手動の学習やラベリングは不要です。セットアップは30分以内で完了します。
- 実際のチケットでシミュレーションする。 これは純正AIが提供していない部分です。実際の過去のリクエストにエージェントを走らせ、チケットごとに強い部分と推測している部分を確認できます。本番のトラフィックに1セントも使う前に、解決率の予測が得られます。
- ギャップを見つけてコーチングする。 シミュレーションによって、まだドキュメントがカバーしていないトピックが明らかになるので、それを埋めてから再テストします。
- まずドラフトで本番稼働し、その後自律稼働に切り替える。 最初はエージェントが人間の承認用に返信を作成する形で始め、信頼できるようになったら簡単なリクエストタイプについて完全自律型に切り替えます。
この「まずシミュレーションする」というステップがあるからこそ、チームはひどい立ち上げ週間を経験せずに、Tier-1リクエストの73%といった強い初月の解決率に到達できます。AIの弱点を本番環境で発見することにはなりません。
初月で、eeselはTier-1リクエストの73%を解決しています。私たちのチームは7日間のトライアル中に導入し、すぐに成果を上げました。
Kim Simpson、Gridwise
ルート2のコスト
料金モデルはシンプルな部分です。eeselは処理したJSMリクエストごとに0.40ドルを課金し、1リクエストとはやり取りすべてを含む1つのタスクを指します。プラットフォーム料金なし、席単位の価格設定なし、実際には離脱だった「解決」への課金もありません。
ルート1との実務的な違いは予測可能性です。純正ルートでは、忙しい月に3つのメーターすべてが同時に跳ね上がることがあります。こちらでは、コストはリクエスト数×0.40ドルだけで、それ以上はありません。チームにエージェントを追加したり、プラン階層を上げたりしても変わりません。AIが実際に何を返すのかを検討しているチームにとって、単一で分かりやすいコスト単位は、「アシスト付き会話、加えて解決件数、加えてクレジット」よりも財務部門に説明しやすくなります。
もう一つ、目立たない利点があります。AIエージェント層はConfluenceやAtlassianのソースに限定されません。既存のマクロ、過去のチケット、スタック全体で接続されたドキュメントから学習できるため、ランブックがSlack、Google Docs、あるいはAtlassianのコネクタがインデックスしないWikiにある場合には重要です。
このアプリを2ヶ月間ビジネスで使用していますが、結果は素晴らしいものです。単純なAIで簡単に対応できるリクエストに押し流されることから、小規模なサービスデスクチームを本当に解放してくれます。
Oil Stores Support
ルート2に対して公平を保つと：これはスタックにもう一社ベンダーが加わるということであり、あなたの業務全体がAtlassianネイティブで、インシデント中心である場合は、純正Rovoの持つAIOpsの深さは本物であり、検討する価値があります。層を追加するルートが優れているのは固定コスト、安全な導入、ソースの広さであり、Atlassianのプラットフォームが行うすべてを置き換えることではありません。
どちらのルートを選ぶべきか
言葉を濁さず、実際に私がどう判断するかをまとめます。
| あなたが... | 傾くべき方向 |
|---|---|
| すでにJSM Premiumで、Confluence中心、1つの請求書にまとめたい | 純正Rovo（ルート1） |
| インシデント/AIOps中心で、Atlassianのエコシステムに深く根付いている | 純正Rovo（ルート1） |
| Standardを使っていて、AIのためにプランを引き上げたくない | AIエージェント層（ルート2） |
| リクエストごとの固定・予測可能なコストを求めている | AIエージェント層（ルート2） |
| 本番稼働前に過去のチケットでドライランを行いたい | AIエージェント層（ルート2） |
| Confluence以外からナレッジを取り込んでいる | AIエージェント層（ルート2） |
両者は互いに排他的でもありません。多くのチームは社内検索とインシデント対応には純正Rovoを使い、最もROIが明確な最前線の振り分けには専用エージェントを充てています。うまく運用されたAIチケッティングシステムなら両方をこなせます。ここで取り上げていないツールも含めてより広い視点を知りたければ、私たちのJira Service Management向け最適なAIのまとめ記事とJSMの代替案ガイドが次に読むべき記事で、Freshservice対Jira Service Managementは基盤となるプラットフォームをまだ選んでいる場合に役立ちます。
Jira Service Management向けにeeselを試す
ルート2に傾いているなら、eeselはまさにそのために作られています。Atlassian Marketplaceからインストールし、30分以内で過去のリクエストとナレッジベースから学習し、JSM内で実際のAIエージェントとして機能します。返信の作成と送信、インシデントの振り分け、フィールドの更新、チームへのルーティングまで行います。差別化要因は過去の実際のチケットでのシミュレーションで、本番稼働前に解決率を確認できることです。料金は固定で1リクエストあたり0.40ドル、新しいエージェント席は不要です。費用が発生する前に、無料トライアルでシミュレーションを実行できます。
ついに、コーチング可能で中小企業にも手が届くAIエージェントに出会えました。私たちの手順、ランブック、ポリシーを読み込んで記憶します。返信を編集する内蔵ツールは直感的で、再テストすると、コーチングの内容を正しく反映してくれます。
Andre Yeu、創業者、WhenHoundsFly