承認済みの機能が完成するまでには、要件文書、Jira の課題階層、リポジトリという三つの仕組みをまたぐ場合があります。Claude Code は文書作成や実装を支援できますが、それらの対応関係には人による承認と直接の確認が必要です。このガイドでは、開発者やチーム責任者が実際の機能を進める手順を扱います。対象には、承認済みの全ストーリー、元のテスト、権限に基づく Jira の更新、レビューを経たプロジェクト指針の判断が含まれます。

これは公式文書に基づく手順です。BIG CHANGE は Jira プロジェクトへのアクセス、Claude Code の実行、リポジトリの変更、機能の提供時間の測定を行っていません。具体的な課題タイプ、フィールド、状態遷移、コマンド、費用は、利用するプロジェクトとアカウントで確認してください。

大きな変化

  • 変わったこと： 承認された要件から、実際の Jira の親課題と全ストーリー、レビュー済みコード、元の検証、許可された課題更新まで、機能を追跡できます。
  • 重要な理由： 課題の対応表、テスト記録、Jira から直接読み戻した情報によって、承認済み作業のどこが完了し、どのストーリーが未完了かを確認できます。
  • 注意点： プロジェクト固有のフィールドや状態遷移、結果が不明な書き込み、失敗した検証は人による解決が必要です。Claude Code の指針だけでは作業権限は得られません。

始める前に

責任者が承認した概要、編集権限のあるリポジトリ、実行可能な元の受け入れ検証がそろう機能を選びます。その実作業には、選択した Jira Cloud プロジェクトでエピック相当の親課題一つ、承認済みの全ストーリー、少なくとも一つのストーリー配下の有意義なサブタスクが必要でなければなりません。実際のサブタスクがなければ、このガイドの一連の成果は未達です。形式だけの課題を追加すると計画を偽ることになります。依頼者、承認権限者、元情報の改訂、使用可能なデータ、開始時の Git コミット、隔離または復旧方法、コードのレビューと Jira の状態変更を許可された人を記録します。

インストール済み環境のClaude Code のバージョン、認証、権限を確認します。リポジトリの CLAUDE.md はプロジェクト指針であり、編集、コマンド実行、データ送信の許可ではないことを確認します。Claude に渡してよい要件とコード、実行可能なコマンド、この機能の利用上限を決めます。Claude Code の利用は契約の利用枠を消費したり、提供元の料金を発生させたりする場合があります。Anthropic の費用ガイドだけでは実際の請求額を事前に確定できません。

Jira では、該当する課題タイプの閲覧・作成と、その後に許可された利用者としてコメントや状態遷移を行う権限を得ます。非公開のスクリプトでは、Atlassian が説明するメールアドレスと API トークンの方式を利用できます。連携機能には OAuth が必要な場合があります。認証情報は非公開のシークレット保管先に置き、プロンプト、課題の本文、CLAUDE.md、ログ、バージョン管理に含めないでください。要件を Jira に送る前に、課題の公開範囲を合意します。

進行中は七種類の非公開記録を残します。docs/feature-prd.md、ticket-plan.json、追記専用の課題書き込みログ、ticket-map.json、ストーリーごとの実装記録、Jira 更新ログ、振り返りの判断です。これらは自分の機能の記録であり、BIG CHANGE が提供または実行したファイルではありません。

1. 正確な内容の PRD を承認する

実際に承認された機能概要を Claude Code に渡し、docs/feature-prd.mdの作成前に未解決の疑問を洗い出すよう依頼します。文書には、依頼者と承認責任者、入力の改訂、問題と想定利用者、対象範囲と除外事項、番号付き要件 ID、受け入れ検証とその証拠元、非機能上の制約、Jira プロジェクト、未解決事項が必要です。責任者が草案と元の概要を照合し、特定の内容改訂とハッシュを承認します。課題作成やコード編集より先に、重要な疑問を解決してください。

ハッシュは後続の記録が参照する情報を正確に特定します。PRD が変わったら、影響する課題計画と検証を再レビューします。実装の失敗を理由に受け入れ基準を合格扱いになるよう書き換えてはいけません。

2. プロジェクトの Jira 階層とフィールドを調べる

許可を得た読み取り専用の Jira REST API v3 リクエストで、GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypesをページごとに取得します。予定する課題タイプごとに、GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}をページごとに取得し、作成時の必須フィールドと許容値を調べます。Atlassian は広範囲を対象とする GET /issue/createmeta 操作を非推奨としています。詳細は課題 API リファレンスを参照してください。

このプロジェクトに実在するエピック相当の親、ストーリー階層の子課題、対応するサブタスクを確認します。Atlassian は標準の階層と設定方法を説明していますが、タイプ名と ID は共通ではありません。各子階層でプロジェクトの Parent フィールドがどう働くか、作成時にどのカスタムフィールドや公開範囲設定が必要かを調べます。承認済みの構造を表せなければ、不足するタイプ、フィールド、権限を記録して作成を保留します。一般的な課題リンクは親子関係にはなりません。

3. 書き込み前に課題計画全体をレビューする

すべての PRD 要件と受け入れ検証を ticket-plan.json に対応付けます。その planVersion、PRD ハッシュ、Jira サイトとプロジェクトキー、ローカル実行 ID、計画の承認者と時刻を記録します。各予定課題には、一意のローカル ID、予定する親のローカル ID、調査済み課題タイプ ID、プロジェクトの必須フィールド、要約、説明、要件と受け入れ基準の ID、責任者、許可された公開範囲を記録します。ストーリーとサブタスクの数は承認された作業で決まります。各サブタスクは本来のストーリー配下で実質的な作業を担う必要があります。

Jira REST v3 は、Atlassian Document Format (ADF) という構造化 JSON 文書を、複数行の課題説明やコメントに使います。承認済み内容から文書を用意し、各リクエストを組み立てる前にサイトが返すフィールドメタデータを確認します。課題 APIの文書は作成操作を説明しますが、未知のプロジェクト向けの完成済みフィールドオブジェクトは提供できません。どの POST よりも前に、人が全体構造、全要件の網羅、親子関係、正確な書き込み先を承認してください。

4. 親から作成し、各課題を読み戻す

承認済みの親を POST /rest/api/3/issue で作成し、次にストーリー、その後に実際の各サブタスクを作成します。毎回のリクエスト前に、実行 ID、課題のローカル ID、該当する場合は確認済み親キー、送信先、正確な承認済みリクエストのハッシュ、UTC の試行時刻、pending 状態を非公開ログに追記します。トークンは含めません。HTTP 201 を受けたら、Jira が返した課題 ID とキーを記録し、続いて直接 GET /rest/api/3/issue/{issueIdOrKey} を呼び出します。プロジェクト、タイプ、要約、説明または PRD 参照、親を承認済み計画と比較します。読み戻し後にだけ、その行を confirmed にします。親を確認できてから子を作成できます。

タイムアウトや応答消失が起きたら、unknown にします。プロジェクト、時刻、承認済み要約、計画参照で Jira を調べ、候補を直接開き、許可された責任者に同一性の解決を依頼します。Atlassian は書き込み後の検索に遅延があり得ると注意しています。検索結果がなくても、作成失敗の証拠にはなりません。実行 ID とログは照合に役立ちますが、サーバーによる重複作成の拒否を保証しません。結果不明の POST をむやみに再送しないでください。

完成した課題構造を直接読み取り、ticket-map.json に各ローカル ID、実際の Jira ID とキー、正式な課題 URL、プロジェクト、タイプ、親キー、PRD と受け入れ基準の ID、読み戻し時刻、ログ参照を記録します。すべての承認済み課題と基準を PRD と照合します。欠落や親の誤りがあれば追加の書き込みを止め、プロジェクトのレビュー済み修正手順を使います。

5. 全承認済みストーリーを実装し、独立レビューを行う

承認済みストーリーを依存関係の順で進めます。各ストーリーの Jira キー、開始時の Git コミットとブランチまたはワークツリー、元の受け入れコマンド、許可されたパスとコマンドを記録します。Claude Code に Plan mode を使い、ストーリーの基準をリポジトリに対応付けるよう依頼します。開発者が計画を確認し、限定範囲の編集を許可します。ストーリーごとの境界は変更をレビューしやすくするためであり、残りの承認済みストーリーを機能から除くためではありません。

編集後は、正確な差分、元の検証コマンドと全出力・終了ステータス、関連する対象別テスト、要件 ID ごとの判定を保存します。実際のコードとログを確認してください。計画文書、生成ファイル、Claude の「テストに合格した」という説明だけでは、変更が動作する証明になりません。検証失敗、予想外の機密情報、依存関係の変更、外部への書き込み、広範なリファクタリングがあれば、そのストーリーを保留します。承認範囲内で修正し、元の検証を再実行します。別のコードレビュアーが、できたコミットを受け入れるか差分を保留するか判断します。すべてのストーリーについて判断を記録します。以前の、レビュー済み Claude Code 変更一件についてのガイドは、より狭いコードレビュー段階を扱います。ここでの PRD と Jira の完全な構造は、機能全体の境界を示します。

6. 許可された Jira 更新を確認する

レビュー済みの各ストーリーについて現在の Jira 状態を読み、GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields をリクエストします。その利用者に実際に許可された遷移、遷移先、必須フィールド、許容値を確認します。権限を持つ責任者が、プロジェクトで確定したフィールド値を使い、POST /rest/api/3/issue/{key}/transitions で選んだ遷移を送信できます。課題を再び直接読み、新しい状態を確認します。コード検証の合格だけでは、Done、マージ、デプロイは許可されません。

書き込み前の状態、予定遷移、操作主体、リクエスト、応答を Jira 更新ログに記録します。POST /rest/api/3/issue/{key}/comment から、事実に基づく ADF の証拠コメントを投稿します。受け入れたコミットまたは保留した差分、元の検証と対象別テスト、残る失敗、レビュアーの判断を含めます。作成したコメントの ID と本文を、Jira のコメント APIから読み戻します。どちらかの書き込み応答が不確実なら、次のリクエストを考える前に状態やコメントを直接調べます。遷移一覧が空、あるいは必須フィールドを使えない場合は、プロジェクト責任者と解決すべきワークフローや権限の不足です。ID を作り上げてはいけません。

7. CLAUDE.md を変更するか決める

実際の PRD、課題、差分、テスト、レビュー、Jira の記録を比較します。Claude に、観察された誤解や不足する検証に基づく短い振り返りを依頼します。人が指針の具体的な修正を選ぶか、変更しない判断を記録し、レビュアーと時刻を残します。承認された場合は、その CLAUDE.md の差分とハッシュだけを確認してコミットします。Anthropic のメモリーガイドはプロジェクト指針を説明しています。このレビューが将来の作業を自動的に許可するわけではありません。機密情報を追加したり、推測の教訓をプロジェクト規則にしたりしないでください。

完了条件と復旧

機能の完了には、承認済み PRD の改訂が直接確認したエピック・ストーリー・サブタスク構造と対応し、承認済みの各ストーリーについて開始状態、受け入れた差分、元の検証と対象別テストの証拠、独立レビューが必要です。許可された各 Jira 遷移と証拠コメントを直接読み戻し、人が振り返りを判断している必要もあります。不足があれば、残る正確な段階を記録します。最初の AI タスクを選ぶガイドは、より前のタスク選択と検証案までを扱い、この実装結果を証明するものではありません。

結果が不確実な Jira 作成は、人が同一性を照合するまで unknown のままにします。親が誤っていれば子の作成を止めます。テスト失敗時も元の基準は維持します。遷移不足や利用上限到達時は、日付付きの部分実施記録を責任者に残します。Claude と Jira に渡す要件・顧客データは承認された最小限にし、現在の費用と権限を確認し、人によるコードレビューの予算も確保します。本ガイドは条件付きの手順を説明するもので、BIG CHANGE による機能完成、Jira 書き込み、モデル実行、節約の実測、マージ、デプロイを報告していません。

出典と参考資料