Jira、Confluence、Bitbucket を1つの CLI で操作

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

Jira、Confluence、Bitbucket に1つの CLI を使う理由

Jira、Confluence、Bitbucket に対応する単一の CLI が欲しいなら、答えは atlassian-cli です。1つのバイナリが、同じフラグと同じ設定ファイルで3製品と Jira Service Management のすべてと通信します。ツールを1つインストールし、サイトごとに一度認証すれば、各製品がサブコマンドになります。

多くのチームは、中途半端なスクリプトの寄せ集めを抱えることになります。Jira の REST API を叩く Python の断片、Confluence にページを送る別の curl のループ、Bitbucket 専用のトークンとラッパー。それぞれ認証もページネーションも出力の形も違うため、つなぎ合わせるには本題に入る前にアダプターのコードを書く羽目になります。

製品をまたぐ単一の CLI は、その手間をまとめて解消します。Jira、Confluence、Bitbucket、JSM のコマンドグループは、すべて atlassian-cli という1つのエントリーポイントの下にあります。--profile や --format といったグローバルフラグを共有し、同じ認証情報を読み、同じ JSON エンベロープを出力します。つまり、リリーススクリプトや監査ジョブ、夜間の cron が、変換用のつなぎコードなしに製品間でデータを移動できます。

1回のインストール、1つの設定、1つの認証プロファイル

この考え方はすべて1つの設定ファイルに支えられています。atlassian-cli は認証情報を ~/.atlassian-cli/config.yaml に、名前付きのプロファイル単位で保存します。サイトごとに一度ログインすれば、その1つのプロファイルで Jira、Confluence、JSM（いずれも Atlassian Cloud の API トークンを共有します）に加えて Bitbucket も認証できます。

# Authenticate once for a site, drives Jira, Confluence, and JSM
atlassian-cli auth login \
  --profile work \
  --base-url https://your-team.atlassian.net \
  --email you@company.com \
  --token "$ATLASSIAN_TOKEN" \
  --default

# Confirm which profiles exist and which is the default
atlassian-cli auth list
atlassian-cli auth status
atlassian-cli auth whoami --profile work

これ以降、各製品は同じバイナリのサブコマンドになります。2つ目のサイトや個人アカウントを対象にしたい場合は、どのコマンドでも --profile <name> を指定できます。

# Jira
atlassian-cli jira issue search --jql "project = DEV order by created desc" --limit 5

# Confluence
atlassian-cli confluence page list --space DEV --limit 25

# Bitbucket (bb is an alias for bitbucket)
atlassian-cli bitbucket --workspace myteam pr list api-service --state OPEN --limit 5

# Jira Service Management
atlassian-cli jsm request list --servicedesk-id 10 --limit 25

1つのプロファイルには、Atlassian の API トークン（Jira、Confluence、JSM 用）と Bitbucket のトークンの両方を保持できます。そのため --profile work を指定すれば、呼び出す製品に応じて適切な認証情報が解決されます。必要なときは個別に管理することもできます。atlassian-cli auth logout --profile old --bitbucket は Bitbucket のトークンだけを削除し、プロファイルの残りはそのまま残します。

あとからデフォルトのプロファイルを切り替えるには、対象のプロファイルで auth login --default を実行し直すか、設定ファイルの default_profile: を直接編集します。トークンの設定と複数サイトの構成については認証とプロファイルのガイドを、トークンの種類で迷っている場合はAPI トークンと PAT の比較をご覧ください。どちらをどこで使うべきかを説明しています。

Atlassian の acli との違い

atlassian-cli はコミュニティによる独立したオープンソースプロジェクトです。Atlassian と提携・関連しておらず、Atlassian による承認、推奨、後援、保守のいずれも受けていません。Atlassian が提供する公式 CLI（acli）でもありません。ベンダーによる一次サポートが必要であれば acli を、1つの設定ファイルと共通の出力形式で Jira、Confluence、Bitbucket、JSM をカバーする無料の単一 Rust バイナリが欲しい場合は atlassian-cli を選んでください。

このプロジェクトは MIT ライセンスで、自己完結した単一バイナリとして配布されます。ランタイムをインストールする必要も、複数のマシンで何かを同期させる必要もありません。CI と相性が良い実務上の理由はここにあります。バイナリを置き、プロファイルを指定し、実行するだけです。

1つのバイナリがカバーする範囲

考え方はこうです。実行ファイルは1つ、製品の名前空間は4つ、それぞれに固有の動詞があります。下の表のどの行も、同じインストールと同じ認証情報で動きます。

各名前空間はこれらの例よりずっと深く作られています。Jira には検索、作成、遷移、担当者の割り当て、スプリント、一括操作があります。Confluence はスペース、ページ、ブログ記事、フォルダー、添付ファイル、CQL 検索をカバーします。Bitbucket はリポジトリ、ブランチ、プルリクエスト、パイプライン、権限を扱います。全体の一覧はコマンドリファレンスにあり、よく使うものを手元に置くなら atlassian-cli チートシートが一番の近道です。

3製品をまたぐスクリプト

単一の CLI の価値がもっともよく分かるのがここです。典型的なリリースは3製品すべてに関わります。Bitbucket でレビュー済みのプルリクエストをマージし、紐づく Jira の課題をクローズし、Confluence にリリースノートを公開する、という流れです。ツールが3つに分かれていれば、認証の設定が3つ、突き合わせるべき出力形式も3つになります。バイナリが1つなら、スクリプトも1つです。

#!/bin/bash
# Ship a release: merge the PR, close the Jira issue, publish release notes
set -euo pipefail

WORKSPACE="myteam"
REPO="api-service"
PR=123
ISSUE="DEV-742"
SPACE="DOCS"

# 1. Merge the reviewed pull request in Bitbucket
atlassian-cli bitbucket --workspace "$WORKSPACE" pr merge "$REPO" "$PR" \
  --strategy merge_commit

# 2. Move the linked Jira issue to Done
atlassian-cli jira issue transition "$ISSUE" --transition "Done"

# 3. Publish a release note as a Confluence blog post
atlassian-cli confluence blog create \
  --space "$SPACE" \
  --title "Release: api-service $(date +%Y-%m-%d)" \
  --body "<p>Merged PR #$PR, closed $ISSUE.</p>"

echo "Release shipped."

ツールが1つなので、ステップ間で変換する必要がありません。同じ --profile フラグでステージングのサイトを対象にでき、同じエラー処理で3つの呼び出しをまとめて包めます。これを Bitbucket Pipeline や GitHub Actions のジョブに置けば、手元のノート PC と同じように動きます。

逆方向も同じように書けます。たとえば、Jira から未解決のバグを取得し、どのリポジトリに古いプルリクエストが残っているかを確認し、ドキュメント用のスペースがまだ存在するかを確かめる週次の監査を考えてみます。

# Weekly cross-product audit
atlassian-cli jira issue search \
  --jql "project = DEV AND type = Bug AND status != Done" \
  --format json | jq 'length'

atlassian-cli bitbucket --workspace myteam pr list api-service \
  --state OPEN --format json | jq '.[].id'

atlassian-cli confluence search cql \
  "space = DOCS and type = page" --limit 1

すべての製品で共通の出力形式

単一の CLI のもう1つの利点は、出力の取り決めが1つで済むことです。どのコマンドも --format（または -f）を受け付け、選べる値も共通です。table、json、csv、yaml、quiet、markdown があります。一度覚えれば、Jira、Confluence、Bitbucket、JSM のどれでも同じように使えます。

# Human-readable table (default)
atlassian-cli jira issue search --jql "project = DEV"

# JSON for piping into jq, identical shape across products
atlassian-cli bitbucket --workspace myteam pr list api-service --format json | jq '.[].title'

# CSV for a spreadsheet
atlassian-cli jira issue search --jql "project = DEV" --format csv --output issues.csv

# Quiet, exit code only, useful for CI gating
atlassian-cli auth test --profile prod --format quiet && echo OK

一覧の出力では、--envelope を付けると JSON や YAML が {"data": [...], "count": N} で包まれます。どの製品が生成した結果でも、後続のスクリプトは同じ場所から件数と行を読み取れます。すべてのコマンドが同じ JSON の方言を話すなら、それらをつなぐ作業は統合プロジェクトではなく、2行のパイプで済みます。

このツールを初めて使うなら、まずatlassian-cli ガイドで全体の流れをつかみ、作業中はチートシートを開いておくとよいでしょう。

CI への組み込み

単一バイナリのありがたみがもっとも分かるのは自動化の場面です。3つのツールをインストールし、3組のシークレットを管理するのは実際の負担になります。パイプラインでは auth login を対話的には実行しません。トークンをシークレットから渡して非対話でログインし、その後のジョブをヘルスチェックで制御します。

# In CI: authenticate from a secret, then verify before doing work
atlassian-cli auth login \
  --profile ci \
  --base-url https://your-team.atlassian.net \
  --email "$ATLASSIAN_EMAIL" \
  --token "$ATLASSIAN_TOKEN" \
  --default

# Fail fast if credentials are wrong, exit code only, no noise
atlassian-cli auth test --profile ci --format quiet || exit 1

# Now any product command runs against the same profile
atlassian-cli jira issue transition "$ISSUE" --transition "In Review"

同じバイナリが Bitbucket Pipeline でも、GitHub Actions のジョブでも、素の cron でも動きます。用意すべきランタイムがないためインストール手順はダウンロード1回で済み、認証情報も製品ごとに別のフローを用意するのではなくトークン1つ（Bitbucket も使うなら2つ）で足ります。うまく動かないときは、どのコマンドにもグローバルな --debug フラグを付ければ、内部の HTTP リクエストとレスポンスがログに出ます。4xx が認証の問題なのか JQL クエリの誤りなのかは、たいていこれで判断できます。

この一貫性こそが、製品をまたぐ CLI の地味な強みです。3つのツールを覚える必要も、3種類のフラグの流儀を暗記する必要も、3つの出力形式を突き合わせる必要もありません。覚えるのは1組の動詞、1つの設定、1つの JSON エンベロープだけで、スプリントのクローズでも、Confluence スペースのバックアップでも、ワークスペース全体のプルリクエスト監査でも同じように通用します。

よくある質問

関連リソース