ルールエンジンの先へ: CLI による Jira の自動化

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

Jira 自動化の 2 つの形

Jira の自動化と言うとき、多くの人が思い浮かべるのはひとつだけです。組み込みのルールエンジンである Automation for Jira で、ビジュアルエディターからトリガー、条件、アクションを組み立てるものです。このエンジンは本当によくできていて、日々の作業の大半にとっては正解です。ただし、それは全体の半分にすぎません。

もうひとつのモデルが、スクリプトによる自動化です。Jira の外側で動き、自分のターミナル、cron ジョブ、CI パイプラインから REST API と Agile API を呼び出します。この記事はレシピ集ではなく、判断のためのガイドです。要点はこうです。Jira の内部で何かが変わった瞬間に反応しなければならないイベント駆動のロジックにはルールエンジンを使い、まとまった件数の処理、複数のツールにまたがる処理、定期実行、バージョン管理に置きたい処理には CLI やスクリプトを使います。成熟したチームの多くは両方を運用しています。

先へ進む前に、ツールについて一言。atlassian-cli は、コミュニティによる独立したオープンソースプロジェクトです。Atlassian が提供する公式 CLI（acli）ではなく、Atlassian と提携・関連しておらず、Atlassian による承認、推奨、後援、保守のいずれも受けていません。ベンダーによる一次サポートが必要であれば公式の acli を、Jira、Confluence、Bitbucket、JSM を横断する単一の無料 Rust バイナリが欲しい場合は atlassian-cli を使ってください。どちらもルールエンジンではありません。いずれも同じ公開 API を外側から呼び出します。

ルールエンジンが強い場面

ルールエンジンの中心的な強みは、Jira の中にあってイベントにリアルタイムで反応できることです。課題が作成、遷移、コメント、編集されたとき、ルールは同じリクエストサイクルの中で応答できます。外側から実行するものは、この速さには追いつけません。ポーリングの待ち時間がなく、イベントそのものがトリガーだからです。

次のようなロジックで真価を発揮します。

• フィールドとステータスの反応的な変更: 新しいバグをオンコール担当者に自動で割り当てる、優先度が Highest になったら期限を設定する、最初のサブタスクが始まった瞬間に親課題を「In Progress」へ移動する。
• 課題をまたぐリンクのルール: すべてのサブタスクが完了したら親課題をクローズする、特定の遷移で課題を別のプロジェクトへ複製する。
• ローコードで扱えること: プロジェクト管理者が、API トークンもスクリプトもデプロイパイプラインも触らずにルールを作成・編集できる。

ワークフローの持ち主が開発者ではなく、ロジックが「このプロジェクト内で X が起きたら Y をする」という形であれば、ルールエンジンがほぼ常に正しく、最も安上がりな道具です。ビジュアルエディターで十分にできることを、わざわざスクリプト化しないでください。

ルールエンジンが壁にぶつかる場面

単一のイベントへの反応を得意にしているのと同じ設計が、それ以外の仕事では扱いにくさにつながります。繰り返し現れる限界が 3 つあります。

イベント駆動であるため、バックフィルがつらい。 ルールは何かが変わったときに発火します。既存の 1 万件の課題に一度きりの変更を適用したい場合、自然なトリガーが存在しません。ルールを発火させるためだけに課題を一括編集して疑似的なトリガーを作る、という壊れやすく理解しにくい方法に行き着きがちです。

実行回数は計測され、上限がある。 自動化はプランごとの実行上限のもとで動き、重いルールは枠を一気に消費します。大規模な過去データの一括処理は、まさにその上限にぶつかる種類の作業です。

ロジックが設定の中にあり、バージョン管理されない。 ルールはプロジェクト内の構成情報です。git のファイルのように差分を取ったり、変更をコードレビューしたり、簡単に切り戻したりはできません。インフラをコードとして扱うチームにとって、この不透明さは実際のコストです。多数のプロジェクトを横断して「そもそもどんな自動化があるのか」を UI で棚卸しするのは骨が折れます。

これはルールエンジンが悪いという話ではありません。バッチ処理、バージョン管理されたロジック、そして Jira の外へ手を伸ばす処理には、ルールエンジンの形が合わないということです。

CLI による自動化が加えるもの

コマンドラインから自動化を動かすと、これらの制約がすべて反転します。ロジックは自分が所有するスクリプトの中にあるので、コミットでき、差分を取れ、レビューできるテキストになります。Jira の外側で動くため、同じ流れの中で他のシステムとやり取りでき、1 万件の課題のバッチもいつもどおりの作業として扱えます。

重要な性質は次のとおりです。

• バッチが前提。 ひとつのコマンドが JQL クエリを受け取り、結果セット全体に対して処理します。プレビューの手順と並列数の制御も組み込まれています。
• 組み合わせられる。 JSON 出力はそのまま jq やスプレッドシート、別のツールに流せます。自動化は閉じた庭ではなく、シェルのパイプラインです。
• 定期実行でき、再現できる。 同じスクリプトが、手元のノート PC でも cron ジョブでも CI のステージでも動きます。隠れた状態はなく、読んだとおりのものが実行されます。
• バージョン管理でき、レビューできる。 ファイルであるため、自動化の変更も他のコードと同じプルリクエストとレビューを通ります。

重要なのは、CLI がルールエンジンと応答速度で競うものではないという点です。単一のイベントにミリ秒で反応しようとはしていません。ルールエンジンがもともと想定していない仕事のためのものです。

ルールエンジンと CLI スクリプトの比較

トレードオフをひと目で確認できるようにまとめます。「どちらが優れているか」ではなく「どちらの形が仕事に合うか」として読んでください。

CLI 自動化の実際

2 つめのモデルを具体的にするために、実際の atlassian-cli コマンドで構成要素を示します。これはコピーして貼るための手順書ではなく、説明のための基本部品です。実際の作例は、下の関連記事にまとめています。

まずは、すでにある自動化の棚卸しです。CLI で既存のルールと Webhook を一覧表示できるので、何をスクリプト化するか決める前に、反応的なロジックを把握できます。

# See the rules and webhooks that already run inside Jira
atlassian-cli jira automation list
atlassian-cli jira webhooks list

次に、ルールエンジンが苦手とするバッチ処理です。一括コマンドはすべて、変更を加える前に --dry-run でプレビューできるため、影響範囲を必ず先に確認できます。

# Backfill a status change across a large historical set
atlassian-cli jira bulk transition \
  --jql "project = DEV AND status = 'In Review' AND updated < -90d" \
  --transition "Done" \
  --dry-run

続いて、定期実行のレポートです。出力が機械可読なので、自動化は jq へのパイプラインにすぎません。

# Count open bugs by priority for a weekly digest
atlassian-cli jira issue search \
  --jql "project = DEV AND type = Bug AND statusCategory != Done" \
  --format json | jq 'group_by(.fields.priority.name)
    | map({priority: .[0].fields.priority.name, count: length})'

そして CI のゲートです。終了コードだけがシグナルになるよう、quiet 形式を使います。

# Fail a pipeline stage if credentials are not valid
atlassian-cli auth test --profile prod --format quiet && echo "Jira reachable"

最後に、ルールエンジンからは直接得られないコンプライアンスの観点です。誰が何を変えたかの記録をエクスポートできます。audit と --envelope のフラグで、データを後工程で扱いやすい形にします。

# Pull the audit log for review, wrapped for easy parsing
atlassian-cli jira audit list --from 2026-01-01 --limit 200 \
  --format json --envelope

これらはすべて、コミットできるファイルの中に置けます。確認プロンプトとエラー処理を備えた、より堅牢なバッチ処理の例はスプリントレポートのランブックにあります。フラグの一覧はコマンドリファレンスをご覧ください。

両方を組み合わせて使う

最良の構成は、どちらかを選びません。それぞれのツールの性質に沿って役割を分けます。おおまかな指針は次のとおりです。

こう整理すると、CLI はルールエンジンの競合ではありません。ルールエンジンが得意とする製品内の即時の反応はそのままに、ルールエンジンが担うようには作られていないバッチ、定期実行、監査可能な作業を受け持つ層です。一連の流れをより詳しく知りたい場合は、Jira CLI 完全ガイドと Jira CLI リファレンスでコマンド全体を確認できます。バッチ側を深く掘り下げた記事は Jira の一括操作です。

よくある質問

関連リソース