Jiraチケッティングシステムとは:2026年における実際の仕組み

2つの製品、1つの検索キーワード

私はインテグレーションを作るのが仕事だが、Jiraは、APIとマーケティングサイトの内容が最も食い違っている製品だ。誰かに「あなたのJiraチケッティングシステムに接続してほしい」と頼まれたとき、私が最初に聞くのは常に「どちらのJiraか」ということだ。その答え次第で、認証スコープもオブジェクトモデルも、そして請求額も変わってくるからだ。

素のJira(2024年5月にJira Work Managementと統合される前は、Jira Softwareと呼ばれていた)は、作業トラッカーであり、ボード、バックログ、ワークフローを備えているが、顧客という概念はまったく存在しない。

Jira Service Managementは、その同じエンジンの上に構築されたサービスデスクだ。素のJiraにはない8つのITSM作業タイプ(Incident、Problem、Service requestなど)に加え、ポータル、キュー、SLAを提供する。ただし2026年時点では、もはや単独では販売されていない。Atlassianはこれを、Customer Service Management、Assets、Rovoとともに「Service Collection」としてバンドルしており、ライセンスページによれば「これらのアプリは個別に購入することはできません」とのことだ。

2025年以降に書かれたAtlassianのドキュメントを読む前に、もう一つ知っておくべきことがある。用語が変わったのだ。issueは今やwork itemになり、issue typeはwork typeに、projectはspaceになった。ただし、古いURLは今でも解決するし、APIフィールドは今もissuetypeのままであり、見つかるフォーラムスレッドはすべて古い言葉を使っている。私自身も今でもissueと言ってしまうことがある。ここで重要なのは、たどり着くドキュメントが、あなたのインテグレーションコードにあるフィールド名と一致しないという点だけだ。

チケットが実際どのようにモデル化されるか

Jiraには、実のところチケットというオブジェクトは存在しない。あるのは作業アイテムであり、それが作業タイプを持っている。Atlassian自身の説明では、作業タイプは「作業のさまざまなカテゴリを区別する」ことで進捗を追跡できるようにするものだとされている。これはプロジェクト管理の文脈の文章であり、サポートについての文章ではない。このオブジェクトはこれはどんな種類の作業かを中心に設計されており、誰が回答を待っているかを中心には設計されていない。

デフォルトで実際に用意されているのは、次の通りだ。

最初の2行に何が欠けているかに注目してほしい。Question(質問)もRequest(リクエスト)もIncident(インシデント)も、どこにもない。素のJiraでサポート業務を回しているチームは、結局、届いたすべての顧客メールを汎用的なTaskとして、あるいはもっとひどい場合はBugとして記録することになる。それでも「機能する」と言えなくはない。スプレッドシートも「機能する」のと同じ意味において。

リクエストタイプはラッパーであり、別のオブジェクトではない

これは腹落ちさせておく価値のある仕組みだ。なぜなら、私がこれまで立ち会ってきた「JSMを使うべきか?」という議論のほとんどは、誰かがこれを図に描いた瞬間に決着がつくからだ。

Atlassianは明快にこう述べている。「Jira Service Managementのすべてのリクエストタイプは、作業タイプに紐づいています」。リクエストタイプが名称、ポータルフォーム、作業カテゴリを持ち、作業タイプがワークフローとフィールドを持つ。カーディナリティは、複数のリクエストタイプ→1つの作業タイプ→1つのワークフローという関係になる。これは、各作業タイプが単一の特定のワークフローにマッピングされるためだ。

つまり、顧客向けの10個のフォームがすべて、たった1つの作業タイプ、ひいては1つのワークフローに集約されることもある。あなたのプロセスが本当に根本では同じであれば、これは便利な機能だ。しかし、そうでない場合には罠になる。プロセスを分割するには新しい作業タイプ、ワークフロースキームへの新しい行、そしてそれを行うJira管理者が必要になるからだ。

そして、素のJiraでサポート業務を運用している人にとって、この議論に決着をつけるはずの一文がこれだ。

"If you create a work item without a request type, your requests won't have access to all Jira Service Management features. Work items with a work type only can be found in Queues."

これはAtlassian自身のドキュメントであり、リクエストタイプのない作業アイテムを、基本的に劣化したチケットとして描写している。つまり、ポータルフォームなし、リクエストタイプによるキューの振り分けなし、作業カテゴリ機能なし、というわけだ。

ここにはもう一つ、結合に関する落とし穴がある。私がこれまで見てきたすべてのJSMインスタンスを悩ませてきたものだ。ドキュメントには明確に「作業アイテムの作業タイプを変更した場合、それに合わせてリクエストタイプも更新する必要があります」と書かれている。たとえばエージェントがService requestをIncidentに再分類したとき、ラッパーの方はオブジェクトについていかない。本来なら誰かが手作業で修正するはずだが、実際には誰もやらない。

リクエスターに見える画面

ポータルこそが、そもそもJSMを購入する正直な理由だ。顧客はヘルプセンターにたどり着き、平易な言葉で書かれたリクエストタイプを選び、フォームに記入する。

これらの命名に関するAtlassian自身のアドバイスは良いものだが、同時に広く無視されてもいる。Deploy SSH keyではなくGet accessを使うこと、そして「細かくなりすぎないように、リクエストタイプを具体的なリクエストへと分解する」ことだ。選択肢が多すぎると、ポータルが使い物にならなくなるからだ。私がこれまで見てきた過剰設計のサービスデスクは、どれも40個のリクエストタイプと、誰も使わない検索ボックスを1つ持っていた。

エージェントに見える画面

同じチケットでも、まったく異なる画面になる。エージェントビューには作業タイプ、ステータス、担当者、リクエストタイプ、関連付けられたアセット、自動化ルールの実行履歴が表示され、左側のレールにはQueues、Incidents、Problems、Changesが並ぶ。

ワークフローと、3カテゴリという天井

Jiraのワークフローは、実質「ステータスと遷移の集合」でしかない。それが実際のサポートプロセスのように振る舞うかどうかを決める仕組みは、3つある。

遷移は一方向だ。 ドキュメントはこの点について率直だ。「作業アイテムを行き来させるには、2つの別々の遷移が必要です」。実際のサポートキューで最もよく起きる出来事である再オープン(reopen)は、実は別個のオブジェクトであり、管理者がDoneからIn progressへと手作業で描かなければならない。デフォルトでは、想定する方向には単純に存在していないのだ。

組み込みのワークフローは読み取り専用だ。 コピーしてそのコピーを編集することはできるが、これはつまり、最初のカスタマイズを行った瞬間に、デフォルトから永久に分岐してしまうということだ。

そして、実際にレポートを制約するのがこれだ。すべてのステータスは、正確に3つのカテゴリのいずれかに属さなければならない。 To do、In progress、Doneで、それぞれグレー、青、緑で表示される。Atlassianははっきりとこう述べている。「これはカスタマイズできません」。

少し立ち止まって考えてみてほしい。サポートチケットは、その生涯のほとんどを待機して過ごす。顧客を待ち、ベンダーを待ち、どこかのサードパーティチームを待つ。Jiraには待機カテゴリがないため、「顧客の返答待ち」というステータスは、未着手の作業、進行中の作業、完了した作業のいずれかのふりをするしかない。どれを選んでも、すべてのボード、すべてのリスト、すべてのレポートが、その色分けとグループ分けを引き継ぐ。あなたのサイクルタイムの数字は、その嘘をそのまま受け継ぐことになる。

対照的に、Zendeskは6つのステータスを備え、その中にはOn-holdも含まれる。Freshdeskは4つのステータスを備え、明確なResolved対Closedの区分がある。Jiraはそもそもそういう形には作られておらず、どれだけワークフローを描いても、その根底にあるカテゴリの天井が変わることはない。

もう一つ、意外と驚かれる点がある。ステータス名の変更はグローバルに反映される。「ステータス名を変更すると、そのステータスを使用しているすべてのワークフロー(およびすべてのスペース)で名前が更新されます」。レポートはステータス名をキーにしているため、あるチームのボードの整理整頓が、静かに別のチームのダッシュボードを壊してしまうことがある。

管理者への負担を一文でまとめると、こうなる。「顧客の返答待ち」ステータスを追加したり、チームが求めていた再オープンの遷移を描いたりするには、スペース管理者権限が必要であり、その変更はそのワークフローを共有しているすべてのスペースに反映される。これはサポートリーダーが切り替えられるものではなく、Jira管理者へのチケット案件なのだ。

キュー、SLA、インテーク:ヘルプデスクたらしめる要素

この4つの要素こそ、Jira Service Managementで実際にお金を払っている対象だ。それぞれが有能である一方、それぞれに、だいたい3カ月目あたりで初めて見えてくる制限がある。ここでは、その両面を紹介する。

キューは保存されたフィルターであり、送り先ではない

キューとは基本的に、スペース内の作業アイテムに対するフィルターであり、受信したリクエストが条件によって振り分けられ、1つの絞り込まれたエージェントビューになる。作成する際は、ドロップダウンからタイプ、ステータス、ラベルを選ぶか、Advancedの中で生のJQLに直接入力する。

落とし穴は、そのドキュメントの一文に集約されている。「新しいキューを作成するには、スペース管理者である必要があります」。 自分専用のビューが欲しいエージェントは、チケットのビューを手に入れるためだけにチケットを申請しなければならない。Atlassianの新しいRovoショートカットはJQLを代わりに書いてくれるが、それでも同じ管理者権限が必要で、キューを削除することもできない。つまり、なくなるのはJQLを書く手間であって、承認のステップではない。

覚えておく価値のある数字が2つある。1つのスペースにつき、作業カテゴリごとに300個のキューを作成できるが、これに到達する人はまずいないだろう。また、キューの件数表示は999件を超えると実態を反映しなくなり、バッジには単に999+と表示されるだけになる。本当にバックログを抱えているチームにとって、そのサイドバーの数字は基本的に装飾でしかない。キュー内検索もコメントやワークログを読み取れず、それこそまさに「これは前にも見たことがあるか?」という問いの答えが眠っている場所なのだが。

SLAは強力だが、編集には容赦がない

SLAは基本的に目標(ゴール)のコンテナであり、1つのSLAにつき最大90個の目標を追加できる。目標はJQLスコープ、時間目標、カレンダーを組み合わせたものであり、カレンダーにはタイムゾーン、稼働日、1日ごとの時間帯、祝日が含まれ、変更しない限りデフォルトは09:00〜17:00だ。

SLAを作成する前に、付箋にメモしておく価値のあることが3つある。

• 名前は変更できない。 Atlassian自身の言葉を借りれば、「作成したSLAの名前は、後から変更することができません」。
• 新しいSLAは遡って適用される。関連するすべての作業アイテムに対して、オープンとクローズの両方を問わずだ。SLAを有効にすると、未来だけでなく、過去の履歴まで書き換わる。
• 稼働中のSLAを編集すると破壊的な影響が出る。 ドキュメントにははっきりとこう書かれている。「SLAを編集すると、進行中のサイクルの一部がクローズしたり、再開したり、消失したりすることがあります」。その後始末専用のナレッジベースページまで用意されているほどだ。

もう一つ、こんな小さな注意書きもある。ReporterとAssigneeに同じ人物を割り当てるのは避けること。そうすると、SLAが不正確に動作する可能性があるからだ。

メールインテークはアドレス単位でルーティングされ、内容単位ではない

サービススペースには専用のクラウドメールアドレスが付属しており、そこに送られたものは何でも作業アイテムになる。そして送信者はライセンスを必要としない。それらのアイテムを作成したり、コメントしたり、遷移させたりするにもだ。これがまさに、無料リクエスターモデルが実際に機能している姿だ。

ルーティングはアドレス単位で行われ、静的に設定される。1つのメールアドレスは1つのリクエストタイプにマッピングされる、それだけであり、それ以上賢いことは何もない。メールハンドラーには、内容ベースのトリアージはどこにも存在しない。1つのサービスプロジェクトにつき10個のアドレスが使えるので、10個の受信箱イコール10個のカテゴリということになり、それより細かくしたければ自分で自動化を書く必要がある。

ドキュメント全体の中で最も破壊的な一文はこれで、あるチームがこれのせいでまるまる2週間分のチケットを失うのを目の当たりにしたこともある。「メールアドレスに紐づいたリクエストタイプに追加の必須フィールドが追加されると、作業アイテムは作成されなくなります」。 誰かがポータルフォームのたった1つのフィールドを必須にしただけで、メールインテークは静かに完全停止する。エラーもバウンスも、何も出ない。

他にも知っておく価値のある細かい点がいくつかある。未読メールの取得は毎分行われる、25MBを超えるものは一切取得されない(カスタムチャンネルの場合、送信者へのバウンスもなく、未読のまま放置される)、メッセージは32,767文字で切り捨てられる、そして自動返信、一括メール、配信ステータス通知はキューに入れられるのではなく破棄される。

自動化には従量制の上限があり、その枠は小さい

Jira Service Managementは3つの自動化エンジンを並行して稼働させている。テンプレートに付属し使用量にカウントされないシステムフロー、初期設定の自動クローズルールが今も残っている古いレガシー自動化、そしてトリガーがフルセット揃った最新のJira Cloud自動化だ。ルーティングを構築する価値があるのはSLA threshold breachedで、これは違反の前後の設定可能な間隔で発火する。

予算面で、これがかなり厳しくなる。

実行回数はリセットされるのは毎月1日で、未使用分は一切繰り越されない。実行は少なくとも1つのアクションを行った場合にのみカウントされ、いくつアクションを行おうと1回としてカウントされる。上限に達すると、「翌月1日に使用量がリセットされるまで、フローは実行に失敗します」。

月5,000回という枠は、サービスデスク全体で1日あたり約165件の自動化アクションに相当する。 自動割り当て、自動返信、エスカレーション、SLA違反の通知は、すべてこの同じ枠から消費される。チケット量に対処する計画が「自動化すればいい」なのであれば、Standardプランの方が先に尽きてしまうだろう。

実際にかかる費用

Atlassianの料金ページはどちらも計算機を表示するが、どちらもデフォルトの設定は、あなたのチームよりはるかに大きなチームを想定している。これこそ、Jiraの料金について私が伝えられる、正直、最も役立つ一点だ。

JSMの料金ページはデフォルトで75エージェントで読み込まれ、1エージェントあたり20ドルと51.42ドルと表示する。しかしこれらの数字は、累進レートを混ぜ合わせたものだ。小規模チーム向けの実際の定価は、Atlassianのライセンス表によれば、Standardが25ドル、Premiumが57.30ドルだ。Jiraの料金ページも同じ手法を300ユーザーで使っており、7.91ドルと14.54ドルと表示しているが、1〜100の帯では実際には9.05ドルと18.30ドルだ。つまり小規模チームは、Standardの見出し価格よりおよそ14%、Premiumの見出し価格よりおよそ26%多く支払うことになる。

Jira Service Management、月額の定価

年間契約は、エージェントごとではなく、帯ごとに定額で請求される。Standardは1〜3エージェントで年750ドル、6〜10エージェントで2,500ドル、51〜100エージェントで19,700ドル。Premiumは同じ帯でそれぞれ1,700ドル、5,750ドル、51,000ドルだ。

素のJira、月額の定価

1〜10ユーザーの年間契約はStandardが900ドル、Premiumが1,850ドルの定額だ。これは1ユーザーあたり月額7.50ドルに相当するが、それは10席すべてを埋めた場合の話であり、4席しか使わなければ実質18.75ドルになる。

ここからは、自分の数字を実際に入れてみてほしい。決断はまさにこの計算の中にあるからだ。

デフォルトの5エージェント・60リクエスターの場合、JSMは月125ドルで済むのに対し、素のJiraは588ドルになる。ここでの話のすべては、リクエスターに尽きる。チーム外の人がチケットを起票したりフォローしたりする必要が出た瞬間、エージェント課金モデルが圧勝する。それも僅差ではまったくない。

AI利用料は3つの別々のメーターに分かれている

ここが財務チームを最も戸惑わせる部分だ。3つのメーターのどれも、同じ単位を共有していないからだ。

• **Rovoクレジット**はシートにバンドルされており、Standard、Premium、Enterpriseでそれぞれ1ユーザーあたり月25、70、150クレジットだ。これでチケットに回答させるつもりなら、月25クレジットはかなり心もとない枠であり、Service Collection Rovoの超過分の単価はどこにも公開されていない。
• **バーチャルサービスエージェント**はPremiumとEnterprise限定で、月1,000件のアシスト会話が含まれ、それを超えるとアシスト会話1件につき0.30ドルかかる。ここでの定義はよく読んでほしい。アシスト会話とは、実際に何かを解決したかどうかに関わらず、インテントにマッチしたものとしてカウントされる。ボットがマッチさせた後、人間にエスカレーションした会話にも課金される。
• Rovo Customer Serviceは、Standard、Premium、Enterpriseのすべてで解決1件につき1ドルだ。

そして、静かに月額プランを膨らませる課金の仕組みがもう一つある。Maximum Quantity Billingの下では、請求額はそのサイクル中のどこかの時点で割り当てられた最大シート数に基づいて決まり、サイクルの途中でシートを減らしてもその期間の請求額は減らない。季節的なピークに合わせてエージェントを増やせば、そのピーク分の料金を支払うことになる。

実際にJiraでチケットを回すとどう感じるか

ドキュメントを引用し続けることもできるが、もっと有用なシグナルは、実際に1年間そこで暮らした人たちが何を言っているかだ。r/jira、r/sysadmin、G2、Capterraにわたるパターンは驚くほど一貫していて、それは「Jiraはダメだ」という話ではない。むしろ「Jiraはヘルプデスクの衣装をまとった開発ツールであり、それがうまくいくかどうかは、どれだけ設定に投資する覚悟があるか次第だ」という話に近い。

まずは最も公正な肯定的意見から。それが正直なところの実態だからだ。

"I come from using JIRA Service Management and now use ServiceNow in a different agency.

JIRA was set up properly, suited to the agency; and therefore it was awesome.. however I hear of many businesses where it's not setup properly or configured to the business requirements and work methods."

u/its_tricky83, r/sysadmin, Reddit

あの条件節が多くを物語っている。そして、その構造的な理由は何度も繰り返し登場する。

"JSM was built on top of Jira Software and inherits capabilities that aren't tailored for Service Management."

u/Hefty-Possibility625, r/jira, Reddit

この不満の最も鋭いバージョンは、自分がJiraの大ファンだと最初に断る人物から出てきたものであり、だからこそ説得力がある。3つ目の項目に注目してほしい。それはまさに、3ステータスカテゴリ問題が日常業務で表面化している例だからだ。

"Jira Service Management misses some basic features of a ticketing system.

You can't combine tickets, you have to mark as a duplicate. […]

Changing status between "waiting for customer" and "waiting for support"? Not inherently there. Needs an automation rule."

u/llDemonll, r/sysadmin, Reddit

もう一つはルーティングだ。キューはJQLフィルターであって送り先ではないため、ネイティブな「これをサードラインキューへ送る」といったアクションは実質存在しない。

"What I really don't get - and that is my biggest gripe with JSM - is that there doesn't seem to be any routing strategy out of the box. Our customers can enter their request into prepared "boxes" (Request Types). But our agents, who are highly specialised team members, are supposed to look at every ticket and magically know this one is for them? How's that supposed to work?

We get about 2.000 tickets per month!"

u/Jandalf81, r/jira, Reddit

そしてここに、SMB向けの導入を検討している管理者による、非常に具体的な料金のデータポイントがある。上の表と並べて読む価値がある。

"Jira Service Management charges $57 per agent (Premium) plus $5 for SSO (Atlassian Guard). This would add up to $1488 per year. At the moment, this (financially) seems like the most attractive option."

u/Important_Ad_3602, r/sysadmin, Reddit

その人物は1日後に戻ってきて、実際に設定作業の見積もりを出した後、価格ではなく手間の方について考え直していた。この2つの投稿の流れそのものが、このカテゴリ全体を縮図のように表している。

ポータルにもそれ専用の不満がある。その原因は、まさに先ほど述べたリクエストタイプと作業タイプの混同だ。あるAtlassianコミュニティの投稿は、こう的確に表現している。「Jira Service Management(JSM)を初めて導入したとき、私たちのポータルは雑然として、分かりにくく、ユーザーにとって圧倒的な存在でした。根本原因は何か? Request TypesとIssue Typesの違いに関する誤解でした」。その1つの区別を最初にきちんと理解しておくことは、後から買うどんなプラグインよりもはるかに価値がある。

とはいえ公平を期すために言うと、JSMは988件のG2レビューで5点満点中4.3、Capterraでは4.5を獲得している。これは決して悪い製品ではない。特定の形を持った製品であり、最終的に満足しているチームは、その形が実際に自分たちに合っているチームなのだ。

正直に言って、セットアップの仕方

すでにJira Service Managementに決めているなら、混乱に陥らずに済む最短ルートを紹介する。

1. ソフトウェアスペースではなく、サービススペースを作成する。 これが、8つのITSM作業タイプ、キュー、ポータル、SLAを一度に手に入れる分岐点だ。逆のやり方をして、後からマーケットプレイスのアプリを付け足すのは、まさにインスタンスが汚くなる典型的なパターンだ。
2. リクエストタイプは40個ではなく、5個にとどめる。 顧客の言葉で命名し、あらゆるエッジケースをモデル化したい衝動を抑えよう。6個目はいつでも後から追加できる。
3. 何よりも先に、メールインテークとポータルを有効にする。 インテークこそが、単なるタスクリストとの違いを生み、実際にチケッティングシステムたらしめるものだ。
4. 初日に再オープンの遷移を描いておく。 デフォルトでは用意されておらず、それに気づく日は、顧客がクローズ済みのチケットに返信し、それが虚空へと消えてしまう日と同じ日になる。
5. 「待機」がどこに属するかを決める。 そして、3つのステータスカテゴリのどれにマッピングされるかを書き留めておこう。そうすれば、少なくともレポートは、ランダムに間違うのではなく、一貫して間違うようになる。
6. 気の利いたものを接続する前に、Confluenceを接続する。 最終的にこのキューにどんなAIを載せるにせよ、品質の天井を決めるのはモデルではなく、あなたのドキュメントの方だ。
7. それが終わってから初めて、自動化とAIに目を向ける。 ルール実行の上限には注意すること。Standardではサイト全体でプールされた月5,000回のルール実行が上限であり、自動割り当てとリマインダーを備えた忙しいキューは、これをあっという間に使い切ってしまう。

上のレポートは、注視する価値があるものであり、同時に罠でもある。Created対Resolvedは、あなたが追いついているかどうかを教えてくれる。しかし、そもそもその量が存在する必要があったのかどうかについては、何も教えてくれない。私が話をするチームの多くは、2年もの間、後者の数字の最適化に費やし、前者の数字には一度も手をつけていない。

あなたのJiraキューでeeselを試してみよう

というわけで、ここでの正直なおすすめに話が及ぶ。あなたのJiraチケッティングシステムがきちんとセットアップされていて、それでもなお増え続けているなら、解決策は別のダッシュボードでも、より速いエージェントでもない。人間が開く前に、繰り返し発生するチケットに答えてしまうことだ。

それこそ、eeselがJira内部で行っていることの本質だ。過去のチケットとConfluenceページを学習し、ファーストレスポンダーとしてキューに常駐し、自信のないものはすべて人間に引き継ぐ。InDebtedのHead of ITであるJason Loyola氏は、これを社内ITデスクで運用しており、その数字は公開されている。eeselは現在、受信した問題の15%を完全にデフレクトしており、解決済みチケットからナレッジが書き戻されるにつれ、目標は55%に設定されている。セットアップに関する彼の評価は、たった3語だった。「セットアップはとても簡単でした」。

ここで2つ、指摘しておきたいことがある。私自身も知っておきたいと思うことだからだ。これはヘルプデスクの上に乗るレイヤーであり、置き換えではない。そのため、まだ素のJiraとJSMのどちらにするか決めていないなら、まずそれを先に決めてほしい。そして、ドキュメントの問題を解決してくれるわけでもない。答えがどこにも書かれていなければ、どんなAIも無から生み出すことはできない。とはいえ料金はシート単位ではなくインタラクション単位なので、少なくとも採用するたびに値上がりすることはない。

無料で試して、既存のキューに向けるだけで、実際にどれだけ対応できたはずかを確認できる。