atlassian-cli はコミュニティによる独立したオープンソースプロジェクトです。Atlassian と提携・関連しておらず、Atlassian による承認、推奨、後援のいずれも受けておらず、Atlassian が提供する公式 CLI(acli)でもありません。製品名は互換性を示す目的でのみ使用しています。
コピーする前に
ここに挙げる Jira 自動化の実例は、疑似コードではなく、そのまま実行できる完全なコマンドです。いずれも無料の単一バイナリである atlassian-cli を使い、cron、CI のステージ、git フックにそのまま置ける形にしてあります。プロジェクトキー、JQL、プロファイル名を自分のものに差し替えれば動きます。
本番のインスタンスに対して実行する前に、守ってほしい原則が 2 つあります。1 つ目は、jira bulk 系のコマンドはすべて --dry-run に対応しているということです。まず一度実行して一致した課題数と課題キーのサンプルを確認し、それからフラグを外して実行します。2 つ目は、--profile で名前付きの認証プロファイルにコマンドを固定し、整理用スクリプトを誤ったサイトに向けないことです。プロファイルの設定は認証を、フラグの詳細はコマンドリファレンスを参照してください。
これが何ではないかについても一言。atlassian-cli はコミュニティによる独立した MIT ライセンスのオープンソースプロジェクトです。Atlassian が提供する公式 CLI(acli)ではなく、Atlassian と提携・関連しておらず、Atlassian による承認、推奨、後援、保守のいずれも受けていません。ベンダーによる一次サポートが必要であれば公式の acli を、Jira、Confluence、Bitbucket、Jira Service Management を横断してスクリプト化できるバイナリがひとつ欲しい場合は atlassian-cli を使ってください。考え方の全体像はJira 自動化ガイドで扱っています。
組み立ての部品
15 本のレシピはほぼすべて、7 つのコマンドの組み合わせです。これらを覚えておけば、ほかに暗記するものなしに自分の自動化を組み立てられます。
以下のレシピのほとんどに、JQL の書き方の癖が 2 つ出てきます。updated < -7d や created < -180d のような相対日付を使えば、スクリプトを書き換えなくてもスケジュール実行されるクエリが常に正しい範囲を指し続けます。そして statusCategory != Done は「終わっていない」状態をまとめて拾うので、プロジェクトごとのカスタムワークフローに合わせて status not in (Done, Closed, Resolved, ...) を書き並べる必要がありません。検索に --format json を付ければ結果を jq に流せますし、下流のツールが行と一緒に件数を欲しがる場合は --envelope を付けて一覧出力を {"data": [...], "count": N} のオブジェクトで包めます。
| 部品 | コマンド | 用途 |
|---|---|---|
| 検索 | jira issue search --jql | 課題の読み取りと絞り込み。JSON を jq に流す |
| 一括遷移 | jira bulk transition | 多数の課題をワークフローの状態間で移動する |
| 一括割り当て | jira bulk assign | 多数の課題の担当者を一度に付け替える |
| 一括エクスポート | jira bulk export | 一致した課題を JSON か CSV に書き出す |
| 更新 | jira issue update | 課題ごとにスプリント、要約、カスタムフィールドを設定する |
| 作成 | jira issue create | 定期的な課題やテンプレート化した課題を生成する |
| 監査 | jira audit list | コンプライアンス用に変更履歴を取り出す |
整理と衛生管理
01放置された「Done」の課題を毎晩自動でクローズする
作業が終わってからずっと Done のまま残っている課題があります。まず一度プレビューし、本番の実行を cron に載せておけば、誰もクリックせずにボードが整った状態を保てます。
# Preview first
atlassian-cli jira bulk transition \
--jql "project = DEV AND status = Done AND updated < -7d" \
--transition "Closed" \
--dry-run
# crontab -e: run for real every night at 2am
0 2 * * * atlassian-cli jira bulk transition \
--jql "project = DEV AND status = Done AND updated < -7d" \
--transition "Closed" --profile prod --format quiet
02放棄された未対応の課題をアーカイブする
Open のまま半年触られていない課題は、ほぼ確実に死んでいます。1 件ずつクリックする代わりに、一度の実行でまとめてクローズします。
atlassian-cli jira bulk transition \
--jql "project = DEV AND status = Open AND updated < -180d" \
--transition "Closed" \
--dry-run
03「バックログの腐敗」レポートを出力する
音沙汰のない課題を洗い出します。完了しておらず、90 日間触られておらず、古い順に並べる。チームでまとめてトリアージできるよう CSV に落とします。
atlassian-cli jira issue search \
--jql "project = DEV AND statusCategory != Done AND updated < -90d ORDER BY updated ASC" \
--format csv --output backlog-rot.csv
割り当てと振り分け
04担当者未設定のバグをトリアージ担当に振り分ける
持ち主のいない新規のバグは、そのまま抜け落ちていきます。定期実行でトリアージ担当にまとめて寄せておけば、担当者未設定のまま一晩放置される課題がなくなります。
atlassian-cli jira bulk assign \
--jql "project = DEV AND type = Bug AND assignee is EMPTY" \
--assignee triage-lead@example.com \
--dry-run
05離任するメンバーの未完了の作業を引き継ぐ
誰かが抜けるとき、その人が抱えたままの課題を 1 件ずつ開き直す代わりに、1 つのコマンドでまとめて引き継ぎます。
atlassian-cli jira bulk assign \
--jql "assignee = leaver@example.com AND statusCategory != Done" \
--assignee new-owner@example.com \
--dry-run
06ラベルの付いた課題群をスプリントに入れる
スプリント用の一括コマンドはありませんが、検索とループの組み合わせで用は足ります。課題キーを取り出し、数値のスプリント ID を使って課題ごとにスプリントを設定します。
atlassian-cli jira issue search \
--jql "project = DEV AND labels = next-sprint AND sprint is EMPTY" \
--format json | jq -r '.[].key' | while read key; do
atlassian-cli jira issue update "$key" --sprint 25446
done
レポートとエクスポート
07週次でクローズ済みスプリントのレポートを出す
毎週金曜、直近のクローズ済みスプリントでチームが完了させた内容を、日付入りの CSV に切り出してふりかえりに使います。より作り込んだ版はスプリントレポートのランブックにあります。
atlassian-cli jira bulk export \
--jql "project = DEV AND sprint in closedSprints() AND status = Done" \
--output "sprint-report-$(date +%F).csv" \
--format csv
08プロジェクトを毎晩 JSON でバックアップする
全課題の日付入り JSON スナップショットがあれば、差分を取れる履歴と、自分で管理できるフォールバックが手に入ります。JSON はフィールド構造をそのまま保ちます。
atlassian-cli jira bulk export \
--jql "project = DEV" \
--output "/backups/dev-$(date +%F).json" \
--format json
09jq でステータス別の課題数を数える
ダッシュボードは使いません。JSON の検索結果を jq に流せば、どこにでも出力できる最新のステータス内訳が得られます。
atlassian-cli jira issue search \
--jql "project = DEV" --format json \
| jq -r 'group_by(.fields.status.name)[] | "\(.[0].fields.status.name): \(length)"'
通知と CI ゲート
10スタンドアップ用のダイジェストを出力する
自分の未完了の作業を更新の新しい順に、スタンドアップのチャンネルへそのまま貼れるきれいな Markdown で、一日の始めに手元に出します。
atlassian-cli jira issue search \
--jql "assignee = currentUser() AND statusCategory != Done ORDER BY updated DESC" \
--format markdown
11新しいブロッカーをチャットチャンネルに通知する
未解決のブロッカーを数え、人の手を止めるだけの理由があるときだけ Webhook に投稿します。
COUNT=$(atlassian-cli jira issue search \
--jql "project = DEV AND priority = Blocker AND status != Done" \
--format json | jq 'length')
if [ "$COUNT" -gt 0 ]; then
curl -s -X POST -H 'Content-Type: application/json' \
-d "{\"text\":\"$COUNT open blocker(s) in DEV\"}" \
"$SLACK_WEBHOOK_URL"
fi
12未解決のブロッカーでリリースを止める
これを CI のステージに置きます。ブロッカーが 1 件でも未解決なら、パイプラインは 0 以外の終了コードで失敗し、リリースが止まります。
COUNT=$(atlassian-cli jira issue search \
--jql "project = DEV AND priority = Blocker AND status != Done" \
--format json | jq 'length')
if [ "$COUNT" -gt 0 ]; then
echo "Release blocked: $COUNT open blocker(s)"
exit 1
fi
コンプライアンスと製品横断
13コンプライアンス用に監査ログを出力する
開始日を指定して変更履歴を取り出し、月次の CSV にまとめます。スケジュール実行にすれば、手を掛けずにコンプライアンスの証跡が残ります。
atlassian-cli jira audit list \
--from 2026-06-01 --limit 1000 \
--format csv > audit-2026-06.csv
14リリースノートを Confluence に公開する
1 つのバイナリが製品をまたぐので、1 本のスクリプトでクローズ済みの Jira 課題を読み取り、同じ実行の中で Confluence ページを公開できます。
BODY=$(atlassian-cli jira issue search \
--jql "project = DEV AND fixVersion = 2.4.0 AND status = Done" \
--format json \
| jq -r '"<ul>" + (map("<li>" + .key + " " + .fields.summary + "</li>") | join("")) + "</ul>"')
atlassian-cli confluence page create \
--space DOCS --title "Release 2.4.0 notes" --body "$BODY"
15複数インスタンスの未解決インシデントを集計する
プロファイルをループで回せば、管理しているすべてのサイトに同じクエリを投げ、1 つのターミナルで結果を並べられます。
for p in prod staging eu; do
echo "== $p =="
atlassian-cli jira issue search --profile "$p" \
--jql "type = Incident AND status != Done" \
--format table
done
以上で 15 本です。どれも根っこにあるパターンは同じで、JQL クエリが課題を選び、動詞がそれに作用し、cron か CI が実行のタイミングを決めます。動詞を変えれば、それだけで新しい自動化になります。レシピ 1 は遷移先を逆にすれば「誤ってクローズしたものをすべて開き直す」スクリプトになりますし、レシピ 9 はステータスの代わりに .fields.priority.name でグループ化すれば優先度別の内訳になります。ゼロから書くより、自分の課題に一番近いレシピから始めて手を加えるほうが早いはずです。
パターンが腹落ちすれば、あとはコマンドリファレンスだけあれば十分です。より重い変更を伴う処理については、数千件の課題を一度に動かすときの並列数の制御とエラーからの復旧を一括操作の詳解で扱っています。
atlassian-cli を試す
Jira、Confluence、Bitbucket、JSM に対応する、MIT ライセンスの無料バイナリがひとつ。インストールして 1 分以内に最初のレシピを実行できます。
atlassian-cli をインストール →よくある質問
自動化ルールに課金せずに Jira を自動化できますか?
できます。JQL クエリで表現できるものは atlassian-cli でスクリプト化でき、cron でスケジュールしたり CI で実行したりできます。ここで挙げた Jira 自動化の実例の大半、つまり放置された課題のクローズ、担当者の付け替え、レポートの出力、リリースのゲート判定はそれで賄えます。Jira 組み込みの自動化ルールと CLI は排他的ではなく補い合う関係なので、作業ごとに合うほうを選べます。
これらの Jira 自動化を単独で動かすにはどうスケジュールしますか?
コマンドをシェルスクリプトにまとめ、crontab に 1 行足すか、CI パイプラインのステージに置きます。たとえば 0 2 * * * atlassian-cli jira bulk transition ... は毎晩 2 時にクリーンアップを実行します。atlassian-cli はフラグを与えれば対話的な入力を求めない単一バイナリなので、cron、systemd タイマー、GitHub Actions、Bitbucket Pipelines のいずれでも無人で動きます。
これらの Jira 自動化スクリプトを本番で実行しても安全ですか?
一括系のコマンドはすべて --dry-run フラグに対応しており、同じクエリを実行して何が変わるかを表示するだけで、何も変更しません。まず --dry-run で一度実行し、対象の課題数とサンプルの課題キーを確認してからフラグを外す、という流れをおすすめします。--profile でコマンドを特定のプロファイルに固定しておけば、誤ったインスタンスに触れることもありません。
Atlassian の製品ごとに別々の自動化ツールが必要ですか?
不要です。atlassian-cli は Jira、Confluence、Bitbucket、Jira Service Management にまたがる 1 つのバイナリなので、1 本のスクリプトでクローズ済みの Jira 課題を読み取り、同じ実行の中で Confluence のリリースノートページを公開できます。認証はプロファイルごとに一度行えば、どの製品のコマンドでも使い回せます。