JiraとGitHubを連携する方法｜GitHub for Atlassianの設定・スマートコミット・自動化【2026年10月】

JiraとGitHubを連携すると、ブランチ・コミット・プルリクエスト（PR）・ビルド・デプロイが、Jiraの作業項目（旧称：課題）に自動でひも付きます。連携に使うのはAtlassianが無料で提供する公式アプリで、名前は旧称の「GitHub for Jira」から「GitHub for Atlassian」に変わっています。この記事では、2026年10月時点の公式ドキュメントに沿って、アプリの導入、作業項目キーの書き方、スマートコミット、Jiraの自動化によるステータス遷移、GitHub Actionsのデプロイ表示、GitHub Enterprise ServerとJira Data Centerでの扱い、表示されないときの切り分けまでを順に説明します。

まとめ：JiraとGitHub連携の要点

• 使うアプリ：Jira CloudでGitHubの開発情報を表示する標準用途なら、公式の「GitHub for Atlassian」（無料）を第一候補にします。旧DVCSコネクターはJira Cloudでは2024年3月31日でサポートが終わっています。
• 必要な権限：Jiraのサイト管理者と、GitHub組織のオーナーの2人分です。
• ひも付け：ブランチ名・コミットメッセージ・PRタイトルに作業項目キー（例 DEV-123）を書きます。書かなければ何も表示されません。
• ステータスの自動遷移：コミットにコマンドを書くスマートコミットより、Jiraの自動化（ブランチ作成・PR作成・PRマージのトリガー）で組むほうが、開発者ごとの設定ミスに左右されません。
• 効かないとき：GitHubの「Keep my email addresses private」、遷移名の不一致、必須フィールドを確認します。過去の開発情報が表示されない場合は、別途バックフィル範囲（6か月）を確認します。

JiraとGitHub連携でJiraに表示される開発情報

作業項目キーを含むブランチ・コミット・PRがpushされると、Atlassianの公式ドキュメントによれば、次の場所に開発情報が出ます。

• 作業項目の開発パネル：ブランチ、PR、コミット、ビルド、デプロイの件数と状態
• ボードのカード：ブランチやPRがあることを示すアイコン
• コードタブ・開発ページ：直近30日にひも付いたPRの一覧
• リリース・デプロイ：バージョン単位のPR・ビルド・デプロイと、デプロイのタイムライン
• JQL：「完了なのにPRが開いたまま」の作業項目を検索できる

開発パネルを見るには、スペース権限「View Development Tools」が必要です。逆方向のリンクとして、GitHubのIssueやPRのコメントに [DEV-123] と角かっこ付きでキーを書くと、Jiraの作業項目へのリンクに変わります。要件から実装・テストまでを追跡する設計全体は、ITのトレーサビリティとは？要件から設計・実装・テストを紐付ける実装手順で扱っています。

GitHub for Atlassianの導入手順

Jira・GitHub接続に必要な権限と役割分担

公式の接続手順が求める権限は、Jiraサイトのサイト管理者と、GitHub組織の組織オーナーの2つです。1人が両方を持っていない組織では、Jira管理者がアプリを入れ、GitHubの組織オーナーが組織を接続する分担になります。オーナーでない人には「Connect」ボタンが出ず、代わりに「Send them a link and ask them to connect」でオーナーに承認用のリンクを送ります。

アプリのインストールとGitHub組織の接続

1. Jiraで アプリ → その他のアプリを探す を開き、「GitHub for Atlassian」を検索して Get app → Get it now を選びます。
2. インストール後に Get started → Continue を選び、接続先に GitHub Cloud を選んでGitHubにサインインします。
3. 接続したい組織の Connect を選びます。組織が一覧に無ければ、先にGitHub側でその組織にJiraアプリをインストールします。
4. リポジトリを All repositories か Only select repositories で選びます。
5. 「Show GitHub data in Rovo」のチェックで、GitHubのデータをRovoの検索・チャット・エージェントに見せるかを決めます。外したままでも連携自体は使えます。
6. アプリ → アプリを管理 → GitHub for Atlassian で、組織が一覧に出ていれば接続完了です。

MarketplaceのGitHub for Atlassianのページでは、2026年10月28日時点で無料・インストール数137,963、対応はJira Cloudです。アプリは読み取り専用のメタデータ権限に加え、PR・コンテンツ・Issueへの書き込み権限を求めます。公式FAQは、書き込み権限をコメント内のキーのリンク化とJiraからのブランチ作成に使い、コードはJiraに保存しないと説明しています。

あとから作ったリポジトリとIP許可リスト

接続時に「Only select repositories」を選んだ場合、新しく作ったリポジトリは自動では追加されません。GitHubの組織設定の Repository access で対象に加えます。「All repositories」なら新規リポジトリも自動で対象になります。

GitHub組織でIP許可リストを使っていると、正しいIPを登録していても一部のAPI呼び出しが弾かれる既知の問題があります。公式手順は、既知のAPI拒否問題にはIPアドレスの個別登録を案内しています。IPアドレスを自動登録する別の設定は、組織設定の Organization security で「Enable IP allow list configuration for installed GitHub apps」を有効にする方法です。手動で登録する場合は、AtlassianのIPをCIDRの範囲ではなく1件ずつ登録しないと動きません。

作業項目キーでブランチ・コミット・PRをひも付ける方法

キーを書く3か所とJiraからのブランチ作成

作業項目キー（旧称：課題キー）は「スペースのキー＋番号」で、ボードのカード下部か作業項目画面の上部に表示されています。書く場所はブランチ名、コミットメッセージ、PRタイトルの3か所です。次のコマンドは既存のGitリポジトリ内で実行し、コミット前に変更したファイルを git add でステージしてください。

# ブランチ名にキーを入れる
git switch -c DEV-123-add-login

# コミットメッセージにキーを入れる
git commit -m "DEV-123 ログイン画面を実装"

# PRはタイトルにキーを入れる（例：DEV-123 ログイン画面）

付け忘れを防ぐ確実な方法は、Jiraの作業項目の開発パネルから Create branch でブランチを作ることです。最初からキー入りの名前になります。公式ドキュメントによると、この画面に出るリポジトリはGitHubでWriteかAdmin権限を持つものだけで、この権限チェックは既定で有効です。チーム全体でキーを必須にする運用ルールはチケット駆動開発（TiDD）とは？No Ticket, No Commitのルールとツール設定、ブランチ命名規則をGitHub側で強制する方法はGit運用のベストプラクティス｜ブランチ戦略・命名規則・コミット規約とGitHubでの強制方法で扱っています。

過去のコミットの取り込み（バックフィル6か月）

接続した時点で、Jiraは過去のデータを自動で取り込みます（バックフィル）。公式の説明での対象は次のとおりです。

• 期間は過去6か月です。
• PRは、タイトル・説明・ソースブランチ名のどれかにキーがあれば取り込まれます。
• コミットは、デフォルト以外のブランチについて最新50件までです。削除済みブランチのコミットは含まれません。

「1年前のコミットが出ない」のは仕様です。Jira管理者が アプリ → アプリを管理 → GitHub for Atlassian の組織設定から Continue backfill を選び、開始日を指定すれば6か月より前も取り込めます。バックフィルの完了を待たなくても、新しいブランチやコミットはすぐに表示されます。1つのGitHub組織に接続するJiraサイトは1つだけにします。複数のサイトにつなぐと同期がずれます。

スマートコミットでコメント・工数・ステータスを操作する方法

スマートコミットの構文と3種類のコマンド

スマートコミットの公式リファレンスの基本構文は <キー> #<コマンド> <引数> で、キーとコマンドの間の文字は無視されます。コマンドは3種類です。

#time の数値は小数でも書けます。後ろに続けた文字列は作業ログのコメントになるので、#comment を重ねる必要はありません。複数の作業項目をまとめて操作するときは、キーを空白かカンマで区切って並べます。

DEV-123 DEV-124 #time 2h #comment ログイン周りをまとめて修正 #done

遷移コマンドは、ワークフロー上の遷移名のうち最初の空白までを見ます。「Start Progress」と「Start Review」のように頭が同じ遷移があると #start はどちらか決まらないので、#start-review のようにハイフンでつないで書きます。

スマートコミットが効かない6つの原因

コミット自体は成功して開発パネルにも出るのに、コマンドだけが効かないことがあります。公式リファレンスとGitHub for AtlassianのFAQに書かれている原因は次の6つです。

1. メールアドレスの不一致：コミットのメールアドレスが、権限を持つJiraユーザー1人のメールアドレスと完全に一致している必要があります。複数ユーザーに一致しても失敗します。
2. GitHubのメール非公開設定：GitHubの Settings → Emails で「Keep my email addresses private」が有効だと、webhookにメールアドレスが載らず、Jiraは不一致として扱います。チェックを外します。
3. 遷移名の不一致：利用可能なワークフローの遷移名が「Done」なら #done と書きます。ボードの列名や遷移先のステータス名だけではコマンドは決まりません。ワークフローに無い #closed や #complete は効きません。
4. 列の飛び越し：「未着手→完了」の直接遷移がないワークフローでは、現在の状態から利用可能な遷移を順に実行します。各コマンドには、そのワークフローで定義された遷移名を使います。
5. 必須フィールド：遷移画面にコメント以外の必須フィールドがあると、遷移は何も通知されずに失敗します。コメントが必須に設定されている場合は、逆に #comment を付けてはいけません。
6. 改行とタイムトラッキング：コマンドは1行で完結させます。2行目以降に書くなら行ごとにキーが必要です。#time はサイトでタイムトラッキングが有効でないと記録されません。

もう1つ、git push --force や git merge --squash で履歴を書き換えると、同じコマンドを含む「新しい」コミットとして再実行され、コメントや工数が二重に入ります。スマートコミットを書いたコミットは、後から書き換えない運用にします。

Jiraの自動化でステータスを自動遷移させる設定

ステータス遷移は、各開発者のメール設定とコマンドの書き方に頼るスマートコミットより、Jira側で一度設定する自動化のほうが確実です。Jira Cloudの自動化には、ソースコード管理ツールと連携しているときだけ使えるDevOpsトリガーがあります。GitHub連携でよく使う組み合わせは次の3つです。

1本目のルールは次の順で作ります。

1. スペースの設定から 自動化 を開き、新しいルール（現在の画面表記は「フロー」）を作成します。
2. トリガーに Branch created を選びます。
3. アクションに作業項目の遷移を追加し、遷移先に「進行中」を指定して保存・有効化します。
4. キー入りのブランチを1本作り、作業項目のステータスが変わったことと、ルールの監査ログに実行結果が残っていることを確認します。

ほかに Commit created、Pull request declined、Build／Deployment の成功・失敗・状態変化のトリガーもあります。Pull request declined はPR自体の却下を扱うトリガーです。レビューでの「Request changes」とは別なので、レビューの修正要求までこのルールで反映できるとは限りません。

注意点は2つあります。第一に、DevOpsトリガーはGitHub Enterprise Serverなどセルフホストのツールでは使えません。GHESを連携しても開発パネルは使えますが、このトリガーは動きません。第二に、自動化の上限は現在、組織全体で共有するステップ数になりました。トリガー・条件・アクション・分岐・ループがそれぞれ1ステップです。条件に合わず止まった実行（NO_MATCH）でもトリガーの1ステップは数えられます。Jiraの月間ステップ数はFreeが契約あたり150、Standardが1ユーザーあたり400、Premiumが750、Enterpriseが1,000で、超過分の課金は2026年12月3日に始まります。各ルールをトリガー1つと遷移アクション1つだけで作り、1件の作業項目で各ルールが1回ずつ動く場合は計6ステップです。組織の枠がJira Freeの150ステップだけで、ほかの実行がなければ月25件分に相当します。コミットのたびに動く Commit created は消費が膨らみやすいため、遷移の起点にはブランチとPRのトリガーを使います。自動化の画面構成やスペースの作り方はJiraの使い方｜スペース作成・エピックの使い分けと「使いにくい」の解消法【2026年10月】を参照してください。

GitHub Actionsのビルド・デプロイをJiraに表示する設定

公式手順では、GitHub Actionsのワークフロー実行はJiraに「ビルド」として表示されます。ビルドは、PRに含まれるいずれかのコミットメッセージにキーがあれば、その作業項目にひも付きます。PRを作らずにブランチをマージした場合は、そのブランチの最後のコミットメッセージしか見ません。次の例は既存ワークフローのトリガー部分で、PRのマージ先が main または feature で始まるブランチの場合に実行します。branches はソースブランチではなくマージ先を絞る指定です。

on:
  pull_request:
    branches:
      - main
      - feature**

デプロイの表示条件はもっと厳しく、アプリは deployment_status イベントしか受け取りません。GitHubのデプロイ作成API（または chrnorm/deployment-action）でデプロイを作り、そのあと少なくとも1回デプロイ状態を更新して初めてJiraに出ます。Jiraは環境名から本番・検証などを推測します。「prod」のように推測できる名前でない場合（日本語名など）は「未定義」と表示されるので、デフォルトブランチに .jira/config.yml を置いて対応付けます。

deployments:
  environmentMapping:
    development:
      - "dev*"
    staging:
      - "stg-*"
    production:
      - "prod-*"
      - "本番"

このファイルを置くと環境名の自動判定が止まるため、使っている環境名をすべて書きます。パターンは4つの環境それぞれに10個までです。ワークフローの書き方はGitHub Actionsでビルド・自動テストを設定する方法｜build.ymlの書き方と失敗の直し方で解説しています。

GitHub Enterprise Server・Jira Data Centerとの連携

GitHub Enterprise Server（Jira Cloud側から接続）

GHESの接続手順は、Cloudより前にファイアウォールの準備が要ります。公開URLを持つサーバーならAtlassianのIPアドレスを許可し、公開URLが無いなら、技術チームがロック付きの公開ゲートウェイを作ってURL・HTTPヘッダー名・APIキーをJiraに入力します。そのうえで接続先に GitHub Enterprise Server を選び、サーバー上にGitHubアプリを作ります（自動作成を推奨）。

公式FAQが挙げる、つながらない原因は次の4つです。

• AtlassianのIPアドレスが許可されていない
• GHESのSAML SSOを使っている（GitHub Enterprise CloudのSAML SSOは対応）
• リバースプロキシを経由している
• 自己署名証明書の問題

アプリの自動作成について、FAQはGHES 3.1以上が必要と説明しています。一方、接続手順のページには2.19以上という記述が残っているため、3.1以上で運用していれば両方の条件を満たします。ワークフローやデプロイが出ない場合は、GHES側でGitHub Actionsが有効かを確認します。GHES自体の要件とサポート期限はGitHub Enterprise Serverとは？オンプレGitHubの要件・料金・サポート期限とCloudとの違いにまとめています。

Jira Data Center（DVCSコネクターで接続）

GitHub for AtlassianはJira Cloud専用で、FAQに「Jira server is not supported」と明記されています。Jira Data Centerでは、本体に組み込まれたDVCSコネクターを使います。Data Center 11.3のドキュメントの手順は次のとおりです。

1. GitHubの Settings → Developer settings → OAuth apps で新しいOAuthアプリを登録します。名前は「Jira DVCS」、Homepage URLとAuthorization callback URLにはJiraのベースURLを入れます。
2. Jiraの 管理 → アプリケーション → DVCS accounts でHostにGitHubかGitHub Enterpriseを選び、TeamまたはUserのアカウント名を入力します。
3. OAuthアプリのClient IDとClient Secretを入力します。自動リンクとスマートコミットは既定でオンのまま追加します。

Data Centerでは、ブランチ作成などをきっかけにステータスを変える仕組みは「ワークフロートリガー」として設定します。Cloudの自動化（DevOpsトリガー）とは別機能です。

連携方式の選び方（公式アプリ・DVCS・サードパーティ）

Jira CloudでGitHubの開発情報を表示する用途では公式アプリを推奨します。Issueの双方向同期や複数Gitサービスの一元管理が必要な場合は、サードパーティ製品も比較します。Jira CloudのDVCSコネクターは2024年3月31日でサポートが終わっているので、まだ残っている場合は 設定 → Jiraアプリ → DVCS accounts の案内に従ってGitHub for Atlassianへ移行します。GitKrakenのGit Integration for Jiraは有料で、GitHub・GitLab・Azure DevOpsを1つのアプリで扱いたいときの選択肢です。

見落とされやすいのが、GitHub IssueとJiraの作業項目の同期は公式アプリの範囲外だという点です。公式アプリが行うのは、ブランチ・コミット・PRをJiraに表示することと、コメント内の [DEV-123] をリンクに変えることなどです。ビルド・デプロイの表示、Jiraからのブランチ作成、スマートコミットにも対応しますが、GitHub Issueの起票・ステータス・担当者の同期は行いません。Issueと作業項目を両方で更新したいなら、Exalate、Unito（GitHub 2-Way Integration for Jira）、Getintなどの同期アプリを使います。ただし、二重管理を続ける前に「タスクはJira、コードの議論はPR」と役割を分けられないか検討してください。GitHub Issue側の運用はGitHub Issueとは？使い方・書き方と運用のベストプラクティス【2026年版】で扱っています。

開発プロセス全体の見直しやCI/CDの整備まで外部に頼む場合は、DevOps・CI/CD導入支援で相談できます。

連携したのに表示されないときの切り分け

開発パネルが空のときは、原因が見つかりやすい順に次を確認します。

1. キーの表記：対象の作業項目画面に表示されたキーを、そのまま記載しているか確認します。Jira Cloudのスペースキーには数字を含められるため、英大文字だけの形式に限定して判断しないでください。別スペースのキーを書いた場合は、意図した作業項目とは異なる関連付けになります。
2. 対象リポジトリ：「Only select repositories」で接続し、そのリポジトリを追加し忘れていないか。
3. 閲覧権限：見ている人にスペース権限「View Development Tools」があるか。
4. 期間と件数：接続前の分はバックフィルの範囲（6か月・50コミット）に入っているか。
5. ネットワーク：IP許可リストやGHESのファイアウォールで通信が止まっていないか。
6. 作者名やアイコンが出ない：GitHubとJiraのメールアドレスが一致していないと、パネルは出ても作者名とアイコンが表示されません。

よくある質問

JiraとGitHubの連携は無料ですか？

公式連携アプリGitHub for Atlassianの利用料は無料で、Marketplaceで無料提供されています。有料の同期アプリに加え、GitHub Actionsなど関連サービスの利用状況によっても費用が発生します。自動化のルールを多く動かすと、Jiraのプランごとのステップ数を消費します。

「GitHub for Jira」と「GitHub for Atlassian」は別のアプリですか？

同じアプリです。公式ドキュメントとMarketplaceの表示名がGitHub for Atlassianに変わり、Jira以外のAtlassian製品（Rovoなど）にも開発データを共有するコネクターになりました。公式の手順書にも、サイドバーの項目名として「GitHub for Jira」の表記がまだ残っています。

GitHub IssueとJiraの作業項目を同期できますか？

公式アプリではできません。公式アプリは開発情報の表示やスマートコミットに対応し、GitHubのコメントに [DEV-123] と書くとJiraへのリンクも作れますが、GitHub IssueとJiraの作業項目を双方向同期する機能ではありません。双方向の同期にはExalate・Unito・Getintなどの同期アプリが必要です。

Jira Data CenterでもGitHubと連携できますか？

できます。ただしGitHub for AtlassianはJira Cloud専用なので、Data Centerでは本体のDVCSコネクターに、GitHubで作ったOAuthアプリのClient IDとSecretを登録して接続します。

GitLabやBitbucketともJiraを連携できますか？

できます。GitHub for AtlassianはGitLabに対応していないため、GitLabは「GitLab for Jira Cloud」アプリを使います。Bitbucket CloudはAtlassian製品なので、Jira Cloudと直接接続できます。作業項目キーとスマートコミットの書き方は同じです。GitHubとGitLabの違いはGitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較で比べています。

関連記事

• Jiraの使い方｜スペース作成・エピックの使い分けと「使いにくい」の解消法【2026年10月】
• チケット駆動開発（TiDD）とは？No Ticket, No Commitのルールとツール設定
• GitHub Actionsでビルド・自動テストを設定する方法｜build.ymlの書き方と失敗の直し方
• GitHub Issueとは？使い方・書き方と運用のベストプラクティス【2026年版】
• Git運用のベストプラクティス｜ブランチ戦略・命名規則・コミット規約とGitHubでの強制方法