Jira 自動化ルール: 実例と CLI での置き換え

atlassian-cli はコミュニティによる独立したオープンソースプロジェクトです。Atlassian と提携・関連しておらず、Atlassian による承認、推奨、後援のいずれも受けておらず、Atlassian が提供する公式 CLI（acli）でもありません。製品名は互換性を示す目的でのみ使用しています。

Jira 自動化ルールを構成するもの

Jira の自動化ルールは、Jira Cloud の内部で動く「これが起きたら、あれをする」というノーコードのワークフローです。どのルールも 3 つの部品からできています。ルールを起動するトリガー、続行するかどうかを判断する 1 つ以上の条件、そして課題を変更する 1 つ以上のアクションです。この 3 つを理解すれば、これから読むどのルールも読み解けます。

この記事では部品を 1 つずつ取り上げ、それぞれのコマンドラインでの置き換えを示します。atlassian-cli を使えば、同じロジックを明示的でバージョン管理されたスクリプトとして再現できます。ルールをプルリクエストでレビューしたい、CI で実行したい、プロジェクトをまたいで共有したい、Jira の外側にある処理とつなぎたい、そんなときに役立ちます。

最初にはっきりさせておきたいことがあります。atlassian-cli はサーバー側の自動化ルールを作成も編集もしません。CLI にルールビルダーはありません。提供するのは各トリガー、条件、アクションの命令型の版と、すでに動いているルールを棚卸しするコマンドです。まず全体像を知りたい場合は Jira 自動化ガイドから、すぐ使えるレシピ集が欲しい場合は Jira 自動化の実例をご覧ください。この記事は部品ごとの対応表です。

トリガーと CLI での置き換え

トリガーとは、ルールを動かし始めるもののことです。Jira 標準では、スケジュールトリガー、課題作成トリガー、遷移トリガー、フィールド変更トリガー、手動トリガーなどが用意されています。コマンドラインでは、トリガーは 2 つの要素の組み合わせになります。スケジューラー（cron、CI のスケジュール、git フック）と、そのトリガーが発火したはずの課題を見つける jira issue search のクエリです。

スケジュールトリガーの対応は素直です。ルールが動く間隔と同じ間隔で、cron がクエリを実行するだけです。「課題の作成」のようなイベントトリガーは、期間を区切った JQL 句でポーリングしてイベントを近似します。こうすれば、前回の実行以降に現れた課題だけを拾えます。

ポーリングには正直に認めるべきトレードオフが 1 つあります。即時ではないことです。標準の「課題の作成」トリガーは課題が保存された瞬間に反応しますが、5 分間隔の cron は次の実行時に気づきます。数秒以内に起きなければならない処理は、トリガーを標準側に残してください。分や時間の単位で測れる処理、つまり大半の整理作業であれば、ポーリングで十分ですし、監査もはるかに簡単です。ポーリングの間隔と JQL の期間はそろえておき、ずれが生じないようにします。cron が 5 分ごとに動くなら、クエリも同じ 5 分のさかのぼりで区切ります。

# A "scheduled" trigger, rebuilt as a query you can cron.
# Finds the issues a rule would fire on this morning.
atlassian-cli jira issue search \
  --jql "project = DEV AND status = 'In Review' AND updated <= -3d" \
  --format json

# An "issue created" trigger, approximated by polling every 5 minutes.
atlassian-cli jira issue search \
  --jql "project = DEV AND type = Bug AND created >= -5m" \
  --format json

条件と CLI での置き換え

条件は関門です。トリガーが発火したあと、ルールを続けるかどうかを条件が決めます。Jira 標準には JQL 条件、フィールド条件、ユーザー条件、関連課題の条件があります。コマンドラインでは、条件を 2 か所のどちらかで表現します。JQL の中（サーバー側の関門）か、jq による JSON 出力への後段フィルター（クライアント側の関門）です。

サーバー側のほうが低コストで、たいていは意図も明確です。条件をそのままクエリに畳み込めば、Jira は条件を満たした課題だけを返します。フィールドを 1 つずつ確認しないと判断できないときや、JQL で表現できないロジックのときは、クライアント側のフィルターを使います。

# A condition, expressed two ways.

# 1. Inside the JQL, the server gates for you
atlassian-cli jira issue search \
  --jql "project = DEV AND priority = Highest AND assignee is EMPTY"

# 2. As a post-filter with jq, the client gates
atlassian-cli jira issue search --jql "project = DEV" --format json \
  | jq '[.[] | select(.fields.labels | index("needs-triage"))]'

ここでは --envelope フラグが便利です。一覧出力を {"data": [...], "count": N} で包むので、条件をいくつも連ねたときの下流での解析や件数の扱いが予測しやすくなります。

アクションと CLI での置き換え

アクションは中身、つまりルールが実際に加える変更です。ここが atlassian-cli と標準の自動化が最も素直に重なる部分で、ほとんどのアクションは Jira の課題操作の動詞と一対一で対応します。課題の動詞は search、get、create、update、transition、assign、delete です。jira bulk のグループは、遷移、割り当て、エクスポートを多数の課題に一度に適用します。

標準のアクションすべてに CLI の対応物があるわけではありません。ないものをでっち上げず、そう書いておくことが大切です。メールの送信、コメントの投稿、Slack への通知は、標準ルール（または CLI の前後に足すシェルの処理）に任せるのが最善です。CLI が力を発揮するのは状態を変えるアクション、つまり課題の移動、担当者の付け替え、フィールドの編集、フォローアップの課題の作成です。

# Action: transition an issue
atlassian-cli jira issue transition DEV-123 --transition "Done"

# Action: assign an issue
atlassian-cli jira issue assign DEV-123 --assignee triage@example.com

# Action: edit a field
atlassian-cli jira issue update DEV-123 --summary "[Triaged] Login fails on Safari"

# Action: create a follow-up issue
atlassian-cli jira issue create --project DEV --issue-type Task \
  --summary "Follow-up: add regression test"

ルール 1 本をコマンドラインで組み直す

ここでトリガー、条件、アクションを縫い合わせて 1 本のルールにします。よくある標準ルールを考えてみます。平日の朝ごとに、担当者が付かないまま「In Review」に 3 日間とどまっている課題を見つけ、埋もれないように「Needs Owner」へ移すというものです。これを 1 本のスクリプトにしたのが次の例で、確信が持てるまで何も変わらないようにドライランを付けてあります。

#!/bin/bash
# Native rule equivalent:
#   TRIGGER    every weekday at 09:00 (handled by cron below)
#   CONDITION  in "In Review" > 3 days, still unassigned
#   ACTION     move to "Needs Owner"
set -euo pipefail

JQL="project = DEV AND status = 'In Review' AND assignee is EMPTY AND updated <= -3d"

# Preview what the rule would touch, always dry-run first
atlassian-cli jira bulk transition \
  --jql "$JQL" \
  --transition "Needs Owner" \
  --dry-run

# Remove --dry-run to execute for real:
# atlassian-cli jira bulk transition --jql "$JQL" --transition "Needs Owner"

トリガーはスケジューラーの側にあります。cron のエントリを 1 行書けば、スケジュールルールと同じ「平日 09:00 ごと」の周期が得られますし、スクリプトの出力はあとから grep できるログに残ります。

# /etc/cron.d/jira-needs-owner, 09:00, Monday to Friday
0 9 * * 1-5  ops  /opt/scripts/needs-owner.sh >> /var/log/jira-rule.log 2>&1

組み直したルールを安全に保つ習慣が 2 つあります。1 つ目は冪等にすることです。JQL は誤った状態に残っている課題だけを選ぶので、スクリプトを 2 回続けて実行しても害はありません。2 回目は変更すべきものを見つけないからです。2 つ目は、初回の本番実行の前と、JQL を編集したあとには必ずドライランすることです。うっかり書いた句が、触るつもりのなかった課題まで巻き込むことを防げます。これは慎重に作られた標準ルールが使うのと同じ安全策で、違いはここではそれが読めるファイルの中にあることです。

ルール全体がファイルになったことで、UI 上のルールでは得られないものが手に入ります。すべての変更の git 履歴、リリース前のプルリクエストレビュー、そして同じスクリプトに Jira 以外の処理（ログを S3 にアップロードする、サマリーを投稿する、別のシステムで課題を起票する）を自由に足せることです。引数の解析や確認プロンプトまで備えた本番品質の版は、Jira 一括遷移のランブックにあります。

標準の自動化と CLI スクリプトの比較

ルールをコマンドラインで組み直すのが常に正解というわけではありません。2 つのやり方は補い合う関係にあり、多くのチームにとっての正直な答えは「両方使う」です。即時のイベント駆動の反応では標準の自動化に敵うものがなく、バージョン管理、可搬性、Jira の外へ手を伸ばす処理を重視するなら CLI スクリプトに軍配が上がります。

実務的な線引きはこうです。速く反応するルール（作成時の割り当て、遷移時のコメント）は標準側に残し、定期的で監査したい作業（毎晩の整理、週次レポート、プロジェクト横断の一掃）は、ほかのコードと同じようにレビューできるスケジュール実行の CLI スクリプトへ移します。

すでにあるルールを棚卸しする

ルールを組み直すつもりがなくても、可視性のために CLI を持っておく価値はあります。自動化ルールは静かに増えていくもので、忙しいプロジェクトに対して動いているルールを全部挙げられるチームはほとんどありません。次の読み取り専用のコマンドが、一覧と変更履歴を与えてくれます。

# List the automation rules configured on your instance
atlassian-cli jira automation list

# See what changed, and when
atlassian-cli jira audit list --from 2026-06-01 --limit 100

# Inventory webhooks, often the other half of external automation
atlassian-cli jira webhooks list

これらの出力を JSON にして保存しておけば、時系列で差分を取れるスナップショットになり、ルールのドリフト、身に覚えのない新しいルール、誰も告知しなかった変更を捕まえられます。

# Snapshot today's rules; commit it and diff on the next run
atlassian-cli jira automation list --format json > automation-snapshot.json

ここで挙げた例の裏にあるコマンドとフラグの一覧はコマンドリファレンスにあります。課題、プロジェクト、一括操作の残りのコマンドは Jira CLI ハブをご覧ください。

よくある質問

関連リソース