Jira Service ManagementにAIを追加する方法

Jira Service ManagementにAIを追加する2つの方法

私はeeselで統合機能を構築しているため、他の人のサービスデスクの中で多くの時間を過ごしています。誰かがJira Service ManagementにAIを追加する方法を尋ねるとき、たいていその意図は「あと3人採用しなくてもチケットが自動的に解決してほしい」というものです。もっともな話です。そこに至る道は正確に2つしかなく、マーケティングページはそれらをぼかして一緒くたにしがちです。

方法1、ネイティブAI。 Atlassianはサービスデスク向けのAIを、プラットフォーム全体のAIレイヤーであるRovoと、顧客向けのVirtual Service Agentに組み込んでいます。これはAtlassianのテナント内に存在し、Confluenceと過去のチケットを読み取り、サードパーティとの接続を必要としません。落とし穴はプランの制限と追加課金であり、これについては後ほど詳しく説明します。

方法2、層状のエージェント。 目的特化型のAIサポートエージェントを、APIを通じてJSMに接続します。それはサービスデスクの中に本物のエージェントとして加わり、同じソース（さらにSlackやNotionなども）から学習し、リクエストをエンドツーエンドで処理します。どのJSMプランを使っていても動作し、実際に解決した分だけ料金を支払います。

どちらが自動的に「優れている」というわけではありません。すでにAtlassianに深く根ざしていて、適切なティアに加入しているなら、ネイティブAIが最も摩擦の少ない選択肢です。層状のエージェントは、セットアップの速さ、ツール横断のナレッジ、コスト管理の面で優れています。このガイドの残りの部分では両方を解説するので、納得したうえで選べるようになります。

Jira Service Management自体のAIが実際に提供するもの

ネイティブの選択肢について率直に話します。名称がわかりにくく、Atlassianはこの1年で2回も体制を組み替えているからです。

有効化できるAIはRovoです。Rovo Search、Rovo Chat（Atlassianの言葉を借りれば「究極のAIチームメイト」）、そしてRovo Agentsがあり、いずれもConfluence、Jira、Slack、連携済みのSaaSからコンテキストを引き出すAtlassian Teamwork Graphの上に成り立っています。サービスデスクにおける主役は、定型的なリクエストを解決するRovo Service agentと、ポータルやチャットでチケットを転嫁する対話型チャットボットである従来のVirtual Service Agentです。

以下は、ITデスク向けに設定されたRovo Service agentの様子で、シナリオ、ナレッジソース、ツールが並んでいます。

そしてこちらは、実際のリクエストを処理している様子で、ソフトウェアアクセスのチケットを承認ステップを含む解決プランに沿って進めています。

実力は確かです。Rovoは、新入社員のオンボーディングプランを生成してステップごとに実行するといった、人手を介さないワークフローを構築・実行できます。

とはいえ、混乱は本物です。Atlassian自身のコミュニティフォーラムでは、管理者たちがそもそもどのAIを使うべきかを尋ねています。フローベースのVirtual Agentと、より新しい生成AIベースのRovoエージェントは異なる業務向けに最適化されており、きれいに互いを置き換えるものではないからです。明確な一つの「AIボタン」を期待してこれを有効化すると、どの部分が何をするのかを理解するのにしばらく時間がかかるでしょう。

プランの制限とコストメーター

ここでチームがつまずくのをよく見ます。ネイティブAIはサブスクリプションの上に乗る単一の項目ではありません。エージェント単位の座席料金の上に重なる、一連のメーターなのです。

• Rovo（検索、チャット、エージェント）はStandardプラン以上で解放されます。Freeでは使えません。
• Virtual Service Agent（転嫁用チャットボット）はPremiumとEnterprise限定です。料金ページによると、Premiumはエージェント1人あたり月額約**$51.42**です。
• VSAには月1,000件のアシスト会話が含まれており、それを超えると1件あたり$0.30が課金されます。
• Rovo Customer Service（外部向けチケット用）は解決1件あたり$1で課金されます。
• Rovo自体はクレジットで計測されます。Standardではユーザー1人あたり月25クレジット、Premiumでは70、Enterpriseでは150で、オプトインすれば追加利用も可能です。

つまり、AIが実際に大量のリクエストを転嫁し始めた瞬間、「1エージェントあたり」という表示価格は実際の請求額を過小に見せることになります。これはレビュアーの声とも一致しています。G2（988件のレビューで5点中4.3点）とCapterra（770件のレビューで5点中4.5点）で支配的な意見は、AIの品質についてではなく、コストと複雑さについてです。

「他のAtlassian製品と比べると、必要なエージェントがどんどん増えていくにつれて、こちらの方がはるかに高額な部類に入ります。」

Alex M., IT Service Manager, Capterra

「私にとって最大の欠点は、管理面での複雑さです。Jira Service Managementは非常に柔軟性が高いものの、設定と維持にはしばしば想定以上の労力がかかります。単純な変更でも複数の設定手順が必要になることがあり、小規模なチームにとっては扱いにくいものになっています。」

Ravindra N., SDET-2, G2

すでにPremiumに加入していて、設定を行う人員も揃っているなら、ネイティブAIは妥当な出発点です。StandardやFreeを使っている場合や、予測可能なコストを求める場合は、層状のアプローチを真剣に検討する価値があります。ネイティブの選択肢についてより深く掘り下げた評価は、Jira Service Management AIは本当に価値があるのかという別記事にまとめています。

AIを追加する前に：前提条件

どちらの道を選んでも同じ下準備が必要であり、それを省くことがAI導入が期待外れに終わる最大の理由です。私たちは何年もの間、実際のサポートキューにAIエージェントを投入してきましたが、自信満々に聞こえるボットが実在の従業員に間違った回答をする場面を見てきました。だからこそ、以下の準備は省略できないのです。

• ナレッジベースを整える。 AIの回答は、それが読み取るConfluenceの記事、過去のリクエスト、リクエストタイプの質を超えることはありません。もしドキュメントが全額キャンセルしかカバーしておらず、人々が日割り返金についてばかり尋ねているなら、AIは推測するしかありません。まずギャップを見つけてください。
• 過去のリクエストのサンプルを抽出する。 最良の学習シグナルはヘルプセンターではなく、自社の解決済みチケットです。どのリクエストタイプがキューの大半を占めているかを把握し、そこにAIを向けられるようにしてください。
• 範囲を決める。 どのリクエストタイプから最初にAIに扱わせるべきでしょうか。パスワードリセット、VPNの問題、アクセス権リクエストは、AIがその価値を発揮する典型的なティア1のIT業務です。範囲を狭く始めてください。
• プランを確認する。 ネイティブAIの場合、StandardならRovo、PremiumならVSAが使えることを確認してください。層状のエージェントの場合、このステップは不要です。どのティアでも動作するからです。

層状のエージェントでJira Service ManagementにAIを追加する方法

これは私が最もよく知っている道なので、詳しく説明します。層状のエージェントの要点は、すでに運用しているJSMにそのまま接続できることであり、移行もプランのアップグレードも不要です。接続後に起きることの全体像は以下の通りです。

ステップ1：サービスデスクを接続する

統合を承認し、それを自社のJSMインスタンスに向けます。eeselの場合、これはOAuthで完結する接続であり、数分で終わります。6週間かかるプロフェッショナルサービスの契約ではありません。ポータルに後付けするチャットボットウィジェットも、別建ての受信箱も不要です。AIはサービスデスクの中に本物のエージェントとして加わります。

ステップ2：過去のデータから学習させる

接続が完了すると、エージェントは過去のリクエスト、ナレッジベースの記事、リクエストタイプを自動的に読み取ります。データのラベリングも、長時間のオンボーディングも不要です。ここが人々を驚かせる部分です。何年分もの解決済みチケットが、初日から使えるナレッジになるのです。そしてJSMに限定されないため、SlackのスレッドやGoogle Docs、Notionのページもソースとして追加でき、実際の答えはしばしばそこにこそあります。

ステップ3：実際のチケットに触れる前にシミュレーションする

これは私が絶対に省略しないステップであり、ほとんどのネイティブ導入では提供されていないものです。エージェントが実際のリクエストに1件でも返信する前に、過去のJSMチケットに対して実行し、どう対応していたかを確認します。テーマ別のカバレッジ（たとえばSSOログインエラーで35%、APIに関する質問で41%といった具合）、ギャップの一覧、解決率の予測が得られます。ギャップを埋め、ソースを追加し、確信が持てるまで再実行します。シミュレーションの段階で問題を捕まえているため、従業員が悪い回答を目にすることは一切ありません。

ステップ4：会話を通じて設定する

ルールエンジンを使う代わりに、新しいチームメイトに教えるようにエージェントに指示します。いつ介入すべきか、どのような文体で書くべきか、どのリクエストタイプを扱うか、いつエスカレーションすべきか。挙動を変えたいときは、望むことを普通の言葉で説明するだけです。

ステップ5：ドラフトモードで稼働を開始し、簡単なものから任せていく

いきなり完全自動運転に切り替えないでください。まずは人間が承認または却下できるよう、エージェントに返信をドラフトさせるところから始め、実際のトラフィックで信頼を積み上げます。パスワードリセットやアクセス権リクエストをきれいに処理できていると分かったら、それらは自動送信させ、より難しいカテゴリはドラフトのままにしておきます。あとは確信度に基づくルーティングが処理してくれます。確信度が高い回答は送信され、確信度が低いものは当て推量ではなくレビュー用にドラフトされます。

この段階的な道のりこそが、Gridwiseが初月で73%のティア1解決率に到達した方法であり、Design.comが現在、1,000件を超えるナレッジ記事を背後に持つマルチエージェント構成でJSM内の月50,000件以上のリクエストを処理している方法でもあります。

代わりにネイティブAIを有効化する方法

ネイティブの道を選ぶ場合の要点は次の通りです。

1. プランを確認する。RovoにはStandard以上、Virtual Service AgentにはPremiumまたはEnterpriseが必要です。PremiumとEnterpriseではAIはデフォルトで有効になっています。
2. Atlassianの管理画面で、組織向けにRovoが有効化されていることを確認する（管理者は切り替え可能で、無効化するとRovo Chatとエージェントが使えなくなります）。
3. Rovoを自社のナレッジに向ける。関連するConfluenceのスペースや、Rovoコネクタ経由でサードパーティのソースを接続する。
4. ポータルとチャットチャネルで転嫁を行うようVirtual Service Agentを設定し、自動化したいリクエストタイプに対してRovo Service agentを構築または有効化する。
5. Rovoのクレジット使用量とVSAのアシスト会話数を監視する。どちらも座席とは別に計測されるためです。

層状のアプローチよりも動く部品が多くなりますが、Atlassianの中に完全に留まることにこだわるなら、これが筋の通った進め方です。実際の運用でどれほどの成果が出るかについては、Jira Service Management AIレビューでさらに深く掘り下げています。

Jira Service ManagementにAIを追加する際のよくある間違い

• テストせずにAIを放任してしまう。 最大の間違いです。新しいエージェントを実際のキューに向けて、うまくいくことをただ願うのはやめてください。まず過去のチケットに対してシミュレーションを行うか、少なくとも数週間はドラフトモードで運用してください。
• コストメーターを無視してしまう。 ネイティブAIでは、エージェント単位の価格は総額ではなく出発点にすぎません。契約する前に見込まれるアシスト会話数と解決件数を試算してください。そうしないと、実際の月額コストに驚かされることになります。
• 薄いナレッジベースを与えてしまう。 Confluenceが古いままだと、AIはそのギャップをすべて引き継いでしまいます。ボットを責める前にドキュメントを直してください。
• 初日から範囲を広げすぎてしまう。 パスワードリセットの自動化は手早い成功体験になります。しかし、初週から複数承認を要する複雑な変更リクエストまで自動化しようとすると、チームの信頼を失うことになります。数字がそれを裏付けるにつれて範囲を広げてください。
• 組み込みだからという理由でネイティブが唯一の選択肢だと思い込んでしまう。 StandardやFreeのチームの多くは、PremiumへのアップグレードなしにはAIを使えないと思い込んでいます。層状のエージェントなら、それを完全に回避できます。

Jira Service Management向けにeeselを試す

ティアをアップグレードすることも、4つ別々のメーターの予算を組むこともなく、サービスデスクにAIを導入したいなら、eeselがその答えになります。Jira Service Managementに30分足らずで接続し、トレーニングプロジェクトなしで過去のリクエストとナレッジベースから学習し、初期設定のままで85%以上のティア1解決率に達します。実際のリクエストに触れる前に、どのような成果を出すかを正確に確認できるシミュレーションモードも備えています。料金はチケット1件あたり$0.40の従量課金で座席料金はかからないため、コストはエージェントの人数ではなく、AIが実際に解決した量に連動します。

$50分の利用枠を使ってクレジットカードなしで無料で始めることもできますし、先にJSM統合の仕組みを確認することもできます。どちらを選ぶにせよ、決める前に自社の過去のチケットに対して実行してみてください。そのたった一つのテストが、このレビューを含むどんなレビューよりも多くのことを教えてくれます。