変更レポート (差分エクスポート)
ほとんどのエクスポートは 「いま、どうなっているか」 に答えます。変更レポートが答えるのは、進捗会議で実際に問われる 「前回から何が動いたか」 です。
Standard で、JQL・ボード・スプリント・リリース・バックログのエクスポートに利用できます。真価を発揮するのはスケジュールエクスポートで、月曜の朝に「今週動いたこと」として受信箱に届く週次レポートです。
これは何ではないか
Jira の変更履歴をそのまま書き出すものではありません。それは既に変更履歴コンポーネントが課題単位で行っています。
変更レポートは エクスポート対象の集合 の単位で動作します。
- どの課題が 現れたか、
- どの課題が 結果から外れたか、
- どの課題が 動いたか — ステータス、担当者、優先度、期限、および追加した任意のフィールド、
- 新しいコメントと作業ログ。
「結果から外れた」は削除を意味しません
このレポートについて理解すべき最も重要な点です。
課題が 結果から外れた に現れた場合、それはエクスポートの結果集合に含まれなくなったという意味です。削除されたわけではありません。別のプロジェクトへ移動された、担当が変わった、ラベルが変わった、あるいは単に編集されてフィルターに一致しなくなった、ということもあります。
外れた課題の一覧には、エクスポートされたドキュメント内に必ずこの注記が付きます。すべての言語・すべての形式で表示され、コンパクト化によって削除されることはありません。ラベルが変わっただけの作業を「削除された」と報告してしまえば、その誤解は高くつきます。
同じ理由で、外れた課題は キーのみ で一覧されます。Exportelier はそれらの複製を保持しておらず、現在の状態を取得しても、なぜ外れたのかは分かりません。
設定方法
- デザイナーでテンプレートを開きます。
- 変更レポート を有効にし、基準点を選びます。
- 3 つのコンポーネントを配置します。
- 変更サマリー — カウンター、基準行、注記。
- 差分課題リスト — 追加 または 結果から外れた に設定した 1 つのリスト。両方必要なら 2 つ配置します。
- 変更テーブル — 変更されたフィールドごとに 1 行。
- 保存し、他のテンプレートと同じように使用します。
基準点
| 基準 | 意味 | 適した用途 |
|---|---|---|
| 前回のエクスポート | このテンプレートがこの範囲を最後にエクスポートした時点 | 随時実行するレポート |
| 前回のスケジュール実行 | このスケジュールが最後に成功した実行 | 週次・月次レポート |
| 固定日付 | 入力した日付 | 「リリースブランチを切って以降のすべて」 |
追跡されるフィールド
ステータス、担当者、優先度、期限は常に追跡されます。ストーリーポイント、スプリント、カスタムフィールドなどはテンプレート設定で追加できます。新しいコメントと作業ログも変更として数えられますが、読み手にとって雑音であれば無効にできます。
初回の実行
テンプレートと範囲の組み合わせで最初のレポートには比較対象がありません。失敗させる代わりに、現在の集合の 完全なレポート を生成し、その旨を明記します。
これはこのテンプレートとこの範囲における最初の変更レポートのため、現在の集合全体を一覧しています。次回以降は変更点のみを表示します。
2 回目の実行からは本来の差分になります。
具体例
あるチームが毎週月曜 08:00 に project = EX AND sprint in openSprints() に対してスケジュールエクスポートを実行しています。3 つのコンポーネントすべてを使い、基準は 前回のスケジュール実行 です。
8 月 3 日 (月) — 初回。 過去の実行がないため、レポートはスプリントの 14 件すべてを一覧し、初回の注記を付けます。これが基準線です。
その週のあいだ。 EX-104 が作成されスプリントに入ります。EX-77 は別プロジェ クトへ移り、フィルターから外れます。EX-42 は 5 日間で To Do → In Progress → Review → In Progress → Review → Done と遷移します。EX-51 は Ada から Grace へ担当が変わり、コメントが 2 件付きます。残り 10 件は変化しません。
8 月 10 日 (月) — 2 回目。 レポートは次のように始まります。
2026 年 8 月 3 日以降の変更
追加: 1 · 結果から外れた: 1 · 変更: 2 · 変化なし: 10
続いて変更テーブルです。
キー フィールド 変更前 変更後 変更回数 EX-42 ステータス To Do Done 5 EX-51 担当者 Ada Grace 1
EX-42 の行に注目してください。この課題はステータスが 5 回変わりましたが、1 行 で、どこから始まりどこで終わったか、何段階を経たかを示しています。1 つの課題に 5 行を割けば、本当に注意が必要な 2 件が埋もれてしまいます。
読むのに要する時間はおよそ 15 秒です。14 件の説明をスクロールして違いを探すのとは比べものになりません。
履歴を再構成できない場合
Jira はすべてのフィールドについて変更エントリーを記録するわけではなく、非常に長い履歴は取得時に切り詰められます。利用できる履歴がレポート期間全体を覆えない場合、その課題はサマリーで 再構成不可 として報告されます。黙って「変化なし」に数えることはしません。
サブタスクやより深い階層は独自の変更履歴を持たないため、同じ扱いになります。合計には引き続き数えられます。差分は常にエクスポートされた課題のフラットな集合を対象とするため、数値の辻褄は合います。
Exportelier が保存するもの
何が追加され何が外れたかを伝えるために、前回のエクスポートに含まれていた課題を記憶する必要があります。保存するのは 課題キーのみ です。
要約も、フィールド値も、説明も、コメントも保存しません。変更テーブルの変更前後の値は、レポート生成時に Jira 自身の変更履歴から読み取られ、保持されることはありません。保存されたキー一覧は 180 日で失効します。
これは意図的な設計判断です。フィールド値を保持すればレポートの実装は容易になりますが、Exportelier が Jira コンテンツの second copy となり、データ保護上の意味合いをすべて背負うことになります。
制限
- 単一課題のエクスポートでは利用できません。変更履歴コンポーネントを使用してください。
- 課題ごとに 1 ファイルの ZIP アーカイブでは利用できません。集合全体についてのレポートを収める単一のドキュメントが存在しないためです。
- テンプレートと範囲ごとに最大 2,000 件の課題キーを記憶します。それを超えると、追加・外れた件数が不完全な可能性があることをレポートが明記します。
- 変更テーブルは 1 レポートあたり 500 行が上限です。上限に達した場合はドキュメントにその旨が記載されます。