JiraのIssueをAIで分類：Jira AutomationとJevで作業項目に自動ラベルを付ける

Jira Cloudでは現在、issueを作業項目（work item）、プロジェクトをスペース（space）と呼びます。オートメーションのドキュメントは新しい名称を使いますが、スマートバリューは今もissueで始まります。サービスデスク、受付フォーム、同僚からの直接起票など、多くの人から依頼を受けるチームは、同じ最初の手順に時間を使っています。新しい作業項目を読み、どの種類の作業かを決めることです。分類はこの手順を自動化し、短い固定リスト（例：bug、feature_request、question、other）からラベルを1つ付けて、ボードのフィルター、キュー、次のルールが拾えるようにします。このカテゴリは、同じくらい重要なもう1つの質問「本文は今誰かがブロックされていると言っているか」と分けておきます。ラベルにせず独立したはい/いいえの質問として尋ね、コメントや通知に使います。どれだけ当たるかを測るまでは優先度の変更には使いません。最初はラベルから始めます。付けるのが安く外すのも簡単だからです。作業タイプ、担当者、ステータスの変更はワークフローやレポートに影響し、自動で誤ると代償が大きくなります。IssueがJiraではなくGitHubにあるなら、GitHub Issueの自動ラベル付けガイドがGitHub Actionsで同じ考え方を解説しています。

コンポーネントは6つです。1）トリガー：Work item created。分類したい作業タイプだけにJQLで絞れます。2）アクション：Re-fetch work item data。作成時に入力されたフィールドを、リクエストを組む前に読み込みます。Jiraは実行中に{{issue}}のデータを自動では更新しません。3）アクション：Send web requestでhttps://jevmodel.app/api/v1/systemoneへ。メソッドはPOST、Content-Type: application/jsonヘッダー、Authorizationヘッダー（Bearerと、メール認証済みアカウントでJevModel Console → API keysから作ったキー。Hiddenにチェックすると保存後に値が伏せられます）を設定し、ボディはCustom dataにします。「Delay execution of subsequent rule actions until we’ve received a response for this web request」にチェックを入れ、APIがエラーステータスを返してもフォールバック分岐を動かしたいなら「Continue running the rule even if the request response is not successful」にもチェックします。4）高度な比較条件のIf/elseブロック：{{webResponse.body.code}}が0に等しい。5）if分岐では、Edit work itemの追加フィールドJSONでLabelsを編集し、ai-に選ばれたラベルを付けて追加します。はい/いいえの回答に条件をもう1つ付ければコメントも追加できます。6）else分岐ではneeds-triageラベルを追加します。Jiraのラベルには空白を使えないので、ラベルIDはfeature_requestのような形にしておきます。

失敗するルールの大半は4つの問題で説明できます。応答値が空になる：Atlassianのナレッジベースは、応答待ちオプションにチェックがない、リクエストを送ったifブロックの外で応答を読んでいる、応答のContent-Typeがapplication/jsonでない、を主な原因に挙げています。JevModelはJSONを返すので、確認すべきは前の2つです。JSONが壊れる：引用符を含む要約や改行を含む説明をそのまま貼ると無効なJSONになるため、各値をasJsonStringで包みます。特殊文字をエスケープし引用符も付けてくれます。説明が空の場合があるなら、「説明が空でない」条件を付けるか要約だけを送ります。リクエストのサイズ：JevModelのリクエスト全体（stateとquestions）は8,000文字以内なので、説明にabbreviateを使います（例では5,000文字）。重複実行：JevModelには冪等キーがないため、Work item updatedのルールだと編集のたびに新しい課金リクエストが送られ、人がラベルを直した後にさらにラベルが重なることもあります。作成時だけ起動させます。運用面でも2点が同じくらい重要です。Atlassianは、ルールを編集できる人はSend web requestアクションを再設定してデータを別の場所に送れると注意しているので、ルールの編集者を絞ります。ルールやアクションを複製・エクスポート・インポートするとHiddenのヘッダー値は失われるので、その後にキーを入力し直します。送るのは要約と説明だけで、報告者の名前やメールは送りません。

Jiraのオートメーションには「Use Rovo agent」アクションもあり、エージェントに応答を生成させ、それをコメントなどテキスト出力のアクションに渡します。下表はドキュメントに基づく各経路の形の比較で、精度の比較ではなく、どの行もベンチマークではありません。

ルールはルールビルダーで組むため、例では各コンポーネントをテキストで示し、貼り付ける値を載せています。リクエストはJevModelのドキュメントどおりです。認証済みアカウントのBearerキーでPOST /api/v1/systemoneし、stateと名前付きの質問を送ります。ここではkindというChoiceとblockingというNoulです。成功した応答はcode 0でdata.answersを含みます。本サイトは常にOpenRouter経由でtypesafe/jev-1.13を呼ぶため、modelフィールドはありません。JevModelはJevを開発するTypeSafe AIとは独立しています。ai-の接頭辞で自動ラベルを見つけやすく、外しやすくします。Jiraのスマートバリューでは動的なキーで確率を引くのが難しいため、このルールはラベルを付けるだけにし、確率の確認はテストサンプルに任せます。ラベルごとのしきい値が必要なら、{{webResponse.body.data.answers.kind.probabilities.bug}}などにラベルごとの条件を1つずつ加えます。blockingの0.8は仮の値で推奨値ではありません。テスト中はLogアクションで{{webResponse.body}}を出力し、ルールの監査ログを読みます。

# Illustrative only. Jira Cloud automation rule, written out component by component.
# Trigger:  Work item created            (optional JQL: type in (Bug, Task, Story))
# Action:   Re-fetch work item data
# Action:   Send web request
#   Web request URL:  https://jevmodel.app/api/v1/systemone
#   HTTP method:      POST
#   Headers:          Content-Type = application/json
#                     Authorization = Bearer <your JevModel key>   [x] Hidden
#   Web request body: Custom data
#   [x] Delay execution of subsequent rule actions until we've received a response
#   [x] Continue running the rule even if the request response is not successful
{
  "state": {
    "summary": {{issue.summary.asJsonString}},
    "description": {{issue.description.abbreviate(5000).asJsonString}}
  },
  "questions": {
    "kind": {
      "type": "choice",
      "instructions": "Which kind of work item is this, based on its summary and description?",
      "criteria": {
        "bug": "Something that used to work is broken, slow, or shows an error.",
        "feature_request": "Asks for new behavior the product does not have yet.",
        "question": "Asks how to do something; nothing is broken.",
        "other": "Anything that fits none of the labels above."
      }
    },
    "blocking": {
      "type": "noul",
      "instructions": "Does the text say that users, customers, or a release are blocked right now?",
      "criteria": {
        "true": "Someone cannot continue their work until this is resolved.",
        "false": "Work can continue while this waits in the backlog."
      }
    }
  }
}
# If:  Advanced compare  {{webResponse.body.code}}  equals  0
#   Action: Edit work item → More options → Additional fields:
{ "update": { "labels": [ { "add": "ai-{{webResponse.body.data.answers.kind.choice}}" } ] } }
#   If:  Advanced compare  {{webResponse.body.data.answers.blocking.noul}}  greater than  0.8   (placeholder)
#     Action: Comment on work item: "Automatic check: this may be blocking someone. Please confirm."
# Else:
#   Action: Edit work item → Additional fields:
{ "update": { "labels": [ { "add": "needs-triage" } ] } }

解決済みの作業項目は、そのまま使えるラベル付きデータです。作業タイプ、コンポーネント、既存のラベルは人が設定したものだからです。前四半期に解決した作業項目などのJQLフィルターで数百件を書き出し、要約、説明、人手のカテゴリを残して、本文を同じChoiceの質問でJevModel Console → Batchにかけます。Batchは行ごとの回答を返しますが精度は計算しないので、表計算ソフトで人手の列と突き合わせます。ラベルごとの一致率、混同されやすいペア（報告者が操作ミスをバグとして書くと、bugとquestionがよく混ざります）、緊急でなかった作業項目でblockingがどれだけ真になるかを確認します。曖昧な定義を書き直し、同じサンプルで再実行します。そのうえでまず1つのスペースでルールを有効化し、1週間監査ログを読み、人がai-ラベルを外す頻度を数えます。古いカテゴリは時間に追われて付けられたことも忘れずに。モデルのせいにする前に、食い違いのいくつかを読んでください。担当者や優先度の変更はこの後に加え、取り消せる形にしておきます。

フィルター、ボード、後続のルールが頼れる、自分で管理するリストからのラベルが欲しく、JSONボディを持つルールを1つ保守できるなら、Send web request + Jevを選びます。人がコメントで読む要約や提案を生成するのが目的なら、Rovoエージェントアクションを。定義を試したい、またはJiraを一切変えずに既存分にラベルを付けたいなら、CSV書き出しとConsole → Batchを。依頼がZendeskのチケット、Slackのメッセージ、GitHubのIssueとして届くなら、それぞれ専用のガイドがあります。どれを選んでも確認すること：1）明確なotherを含むラベル定義を書く、2）緊急度は別のはい/いいえの質問にする、3）JevModelには冪等キーがないので作成時だけ起動する、4）要約と説明だけを送り、8,000文字の上限未満に短くする、5）ルールを編集できる人を絞り、キーはHiddenヘッダーに置く、6）まずai-ラベルとneeds-triageへのフォールバックで始め、解決済み作業項目で一致率を測ってからルールを広げる。JevModelはテキスト専用でオープンソースではありません。作業項目に添付されたスクリーンショット、ファイル、ログはこのルールでは分類されません。