2026年3月2日から、Atlassian Cloud のAPIレート制限が大きく刷新されました。「リクエスト数」での制限から「ポイント」での制限へ — 一見すると地味な変更に思えますが、実はこれまで「やってはいけない」とされていた API 利用パターンが、設計次第で十分実現可能になるという、大きな転換点です。

本記事では、Atlassian Gold Partner として多くのJira統合案件を支援してきた INNOOV の視点から、新仕様の本質と、皆さまの既存システムへの影響をわかりやすく解説します。

「Jiraから業務データを Power BI や Excel に連携している」「夜間に全件取得するバッチを動かしている」 — これらのいずれかに該当するなら、本記事は他人事ではありません。

実は、2026年3月以降の新仕様は 既存統合の見直しが必要なケースと、逆に過去に諦めていた設計が可能になるケース の両方を生み出しています。「とりあえず動いているから」という理由で放置すると、ある日突然 429 Too Many Requests エラーが多発し、ダッシュボードが止まる、ということになりかねません。

本記事を読み終えた頃には、以下が判断できるようになっているはずです。

2026年2月以前のAtlassian APIレート制限は、ハッキリ言って 「ブラックボックス」 でした。

公式ドキュメントには「制限は継続的に最適化のため進化している」と書かれており、具体的な数値が公開されていませんでした。エンタープライズ用途で大規模統合を構築するエンジニアたちは、こんな悩みを抱えていました。

結果として、「動いているシステムには触らない」「夜間のごく短時間だけ実行する」といった、防衛的で保守的な設計を強いられていました。

2026年3月の新仕様では、全てが数値として公開され、事前計算が可能になりました。

これは「制限が緩くなった」のではなく、「制限が読めるようになった」 という変化です。読めるということは、設計できるということ。これまで「危険だから」と避けてきたパターンが、適切な設計のもとで現実的な選択肢になります。

具体的な変化を表で整理すると以下のようになります。

新APIレート制限は、3つの独立したシステムが同時に動いています。1つでも超えれば 429 が返るため、片方だけ最適化しても解決しません。

作業量に応じてポイントを消費 する仕組みです。各APIリクエストには基本コスト1ポイントが乗り、そこに 返ってくるオブジェクトの種類と数 に応じてポイントが加算されます。

オブジェクトの種類別の単価は以下のとおりです。

例えば、Issue を 100件まとめて取得 すると以下のようになります。

1pt (基本) + 100pt (Issue × 100件) = 101pt

書込操作は何件処理しても 1ポイント固定 という点が興味深いところです。Issue を50件まとめて作成しても、1件ずつ50回作成しても、消費ポイントは同じ50ptです。

ポイントクォータには2つのTierがあります。

Tier 1 (Global Pool): 既定の設定です。全テナント共有で 65,000 pt/時 が割り当てられます。大半のアプリはここで十分機能します。

Tier 2 (Per-Tenant Pool): 高負荷アプリ向けの申請制プールです。テナント毎に専用枠が割り当てられ、ユーザー数に応じてスケールします。

Tier 2 は Atlassian の審査を経て昇格しますが、通常のSI案件では Tier 1 で十分なケースがほとんどです。

1秒あたりのリクエスト数 に対する制限で、エンドポイント毎に独立しています。トークンバケット方式で実装されており、短期的なスパイクをある程度許容しつつ、持続的な高負荷を防ぎます。

既定値は以下のとおりです。

ただし、一部のエンドポイントには個別の上限が設定されています。例えば GET /api/3/issue/{key} は 150 req/秒と高めに、逆に GET /servicedeskapi/.../customer は 5 req/秒と極めて低く設定 されています。後者のような特殊なエンドポイントを使う場合は注意が必要です。

単一のIssueに対する連続書込を防ぐ仕組みで、同じIssueに対して 2秒間に20回、または 30秒間に100回まで という制限があります。

Jira Automation のルールが暴走して同じIssueを何度も更新するようなケースで発動します。通常のETL処理ではあまり意識する必要はありませんが、ワークフローを設計する際は頭の片隅に置いておきましょう。

新仕様で 最も誤解しやすい論点 がここです。新ポイント制は すべてのAPI利用に適用されるわけではありません。

つまり、多くの企業で運用されている「Python + API token」のETLスクリプトは、新ポイント制の対象外 です。バースト制限(秒単位)のみを意識すれば良いので、実質的な影響は限定的です。

一方、Marketplaceアプリを開発している場合や、将来 OAuth/Forge への移行を検討している場合 は、新仕様の全レイヤーが適用されます。設計段階で慎重な検討が必要です。

理論はわかった。では実際、1万件のJiraチケットを取得するのに、どれくらいの時間がかかる のでしょうか。

INNOOVが実プロジェクトで計測した結果を共有します。

意外なことに、3方式とも所要時間はほぼ同じ約60秒 です。理由は、実時間の支配要因が Jira サーバー側の応答時間(平均500ms - 1秒) であり、レート制限ではないからです。バースト制限の100/秒に対して、現実的には秒間10前後しか出ません。

では何が違うのか。3つの本質的な違いがあります。

1日に実行できる回数

他テナントとの競合

ここが Tier 1 OAuth の 隠れたリスク です。同じMarketplaceアプリの他テナントが大量取得すると、自テナントの枠まで圧迫されることがあります。Tier 2 ではこの問題は解消されます。

実装の手軽さ

API token が圧倒的にシンプルです。OAuth は認可フローや refresh token 管理が必要で、運用負荷が増えます。

社内ETLとして利用するなら API token が依然として最適解 です。シンプル、競合なし、新ポイント制の影響を受けない。一方、Marketplaceアプリ開発など複数テナントへの提供が前提なら、OAuth/Forge への移行と Tier 2 申請も視野に入れる必要があります。

新仕様下でPython等で実装する際に、最低限押さえるべきポイントを整理します。

429 が返ってきた時、AtlassianはレスポンスヘッダでRetry-Afterを返してくれます。これを無視してすぐリトライすると、再び429が返り、悪化 します。

if response.status_code == 429:

wait = int(response.headers.get('Retry-After', 5))

time.sleep(wait)

429が連続する場合は、待機時間を倍々に増やす(指数バックオフ)に加え、ランダムな揺らぎ(ジッター)を加えます。これにより複数のジョブが同時に再開して再衝突する 「サンダリングハード問題」 を防げます。

delay = min(delay * 2, 30)

time.sleep(delay * random.uniform(0.7, 1.3))

新仕様の大きな恩恵は、X-RateLimit-Remaining で 残量がリアルタイムで把握できる ことです。20%以下になったら速度を抑制するなど、適応的な制御が可能になります。

remaining = int(response.headers.get('X-RateLimit-Remaining', 65000))

if remaining < 13000: # 20%以下

time.sleep(60)

fields=*all で全フィールドを取得するのは無駄が多いです。必要なフィールドだけを指定 することで、応答サイズが激減し、処理時間も短縮されます。

params = {

'jql': 'updated >= -1d',

'fields': 'summary,status,assignee,priority,created,updated',

'maxResults': 100

}

ポイント消費自体は変わりませんが、転送量と処理時間は2-3倍改善するケースもあります。

逆に、絶対に避けるべき設計パターン も整理しておきます。

asyncio で数百リクエストを同時投入すると、最初の数件でバースト枠を使い切り、残りは全て 429 で失敗します。順次実行 + 短い間隔(100ms程度) が確実です。

429 で即エラー終了してETL全体が失敗するパターン。瞬間的なスパイクで全件処理が止まります。指数バックオフは必須 です。

差分取得を実装せずに毎時全件取りに行くパターン。Tier 1 枠を圧迫し、他統合への影響も出ます。updated >= -Xd で差分取得 を実装するだけで、API呼出は1/100になります。

X-RateLimit-Remaining などのヘッダ情報を記録していないと、突然の429時に原因不明で復旧に時間がかかります。全リクエストでヘッダ値をログ化 しておきましょう。

最後に、自社のJira統合が新仕様の影響を受けるかどうか、5つのチェック項目で診断してみてください。

頻度を計測してください。一時的なものか、パターンがあるか。ログに RateLimit-Reason ヘッダがあれば、原因の特定も可能です。

全件洗替方式なら 差分方式への移行検討 が必要です。バッチ実行時間が伸びてきていないか確認してください。

新ポイント制が適用されるようになります。現状のリクエスト量で Tier 1 (65,000pt/時)の枠内に収まるか、事前試算 が必要です。

Tier 1 共有プールでの運用となります。高負荷なら Tier 2 申請の準備 を進めましょう。Developer Console で現状を確認できます。

互いに干渉する可能性があります。統合間のスケジュール調整 や、API token の共有を見直す必要があるかもしれません。

1つでも該当する場合は、新仕様への対応設計を始めることをお勧めします。

INNOOV は Atlassian Gold Partner として、多くの企業のJira統合プロジェクトを支援してきました。新仕様への対応では、以下のサービスを提供しています。

「うちの環境は大丈夫だろうか」とご不安をお持ちでしたら、まずは 現状診断 からお気軽にご相談ください。

2026年3月のAtlassian APIレート制限の新仕様は、一見地味な変更に見えますが、Jira統合の設計戦略を根本から見直す絶好の機会 です。

新仕様を味方につけるか、リスクとして放置するかは、ここからの設計次第です。INNOOVは皆さまの統合がより安定し、より柔軟になるよう、これからもサポートしてまいります。

INNOOV株式会社

本記事は 2026年5月時点の情報に基づいて執筆されています。API仕様は今後も調整される可能性があるため、最新情報は必ず Atlassian公式ドキュメントでご確認ください。