Claude CodeとGitHubを使って修正タスクを進める流れ

Claude CodeとGitHubで修正タスクを進めるときは、Issueをそのまま実装命令にせず、再現条件・期待動作・変更範囲・完了条件に分解してから着手します。Claude Codeはローカルのコードを読んで編集・コマンド実行を支援し、GitHubはIssue、差分、レビュー、CIの記録を残す場所です。AIに任せる範囲を小さくし、PRで人が差分を確認する工程を残すと、修正内容を追いやすくなります。

Issueを「直し方」ではなく受け入れ条件に変える

Issueには利用者が見た症状、再現手順、期待する結果、対象環境、対象外を記します。「ログインできない」だけでは原因が広すぎるため、たとえば「メールリンクから戻ると設定画面ではなくトップへ移る」「Safariで再現」「既存アカウントのみ」など、観測できる条件を添えます。直し方を先に決めつけると、症状と合わない場当たり的な変更を誘発します。

実装担当に渡す前に、完了条件をテスト可能な文にします。「保存後に画面を再読み込みしても設定値が残り、未ログイン時は従来どおりログイン画面へ戻る」のように、成功と守るべき既存動作を並べます。変更してほしくない範囲も明記します。依存関係の更新、認証方式の変更、無関係な整形などが対象外なら、それを最初に伝えます。

Claude Codeで変更前の地図を作る

最初の依頼は、すぐ編集するのではなく、関連ファイル、データの流れ、既存テスト、似た実装を調べて原因候補を説明することです。報告には「確認できた事実」と「まだ仮説」を分けてもらいます。既存コードを読まずに提示された修正案を採用すると、別のAPIや画面状態を壊す場合があります。

調査後は、触るファイル、最小修正案、追加するテスト、影響しそうな画面を短く出してから変更します。これは毎回大きな設計会議を開くためではなく、作業範囲がIssueの目的から広がっていないかを早く見つけるためです。途中でスキーマや公開APIを変えないと解決できないと分かった場合は、局所修正に見せかけて進めず、影響を整理して判断を戻します。

一つの修正を小さな差分に保つ

変更は「一つの症状を直すために必要なコード」に絞ります。バグ修正に関係のない命名統一や大規模なリファクタリングまで混ぜると、レビュー時に因果関係を追いにくくなり、問題が起きた際の切り戻し範囲も広がります。関連する補助変更が本当に必要なら、理由をPR説明に残します。

Claude Codeへは、編集してよい範囲とコマンド実行の制約も渡します。特に、依存追加、データ削除、外部サービスへの送信、権限設定、Secretsの変更は通常のコード編集とリスクが異なります。機密値をIssueやプロンプトへ貼らず、ログに環境変数を出さないようにします。権限を要求する作業は必要な理由を人が見てから許可します。

変更後のチェックを順番に行う

まず修正箇所に近いテストを実行し、次に関連する型検査やlint、最後に必要な範囲のbuildを実行します。テストが失敗した場合は、失敗を隠すためにテストを削除したり、受け入れ条件を弱めたりせず、原因を切り分けます。実行していないチェックは成功扱いにせず、PRへ未実施と理由を記載します。

表は横にスクロールできます

段階	確認すること	失敗時の次の手
再現テスト	修正前の症状を捉えるか	条件やfixtureを見直す
対象テスト	修正後の動作と境界条件	回帰箇所を特定する
静的check	型、lint、formatなど	既存基準に沿って直す
手動確認	画面・操作・エラー表示	再現手順を記録する
diff review	不要ファイル、秘密値、範囲外変更	変更を分離する

テストが通ることは重要ですが、それだけで利用者側の動作確認を代替できるとは限りません。UIの修正なら実画面で操作し、APIなら成功・失敗レスポンスを確認します。GitHub Actionsの結果もPR上のチェックとして確認し、AIの自己申告と実行ログを混同しないようにします。

GitHubへ残すのは判断材料

PRには、何を直したか、なぜその差分になったか、どのチェックを実行したか、未解決点があるかを記します。レビュー担当者が会話の全文を読まなくても判断できる説明にします。Claude Codeが作成した説明をそのまま貼るのではなく、実際のdiffとログに合わせて確認してください。

Claude Code GitHub Actionsを使う場合、Issueやコメントなど外部入力がどのイベントで実行を起こすか、誰が起動できるか、Tokenに何の権限があるかを確認します。AnthropicのAction設定では、Actionsの結果参照など追加機能に追加権限が必要です。すべてのworkflowに強いwrite権限を付けず、機能上必要な権限だけを付与します。Bash実行を許可する場合も、許可ツールを無制限に広げず、必要なコマンドに絞る方針です。

途中で止めるべき兆候

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Claude Code

  公式サイトを見るTool詳細を見る比較を見る

次のいずれかが出たら、自動的に変更を広げず状況を確認します。

• Issueの受け入れ条件と実装案が一致しない

• 複数のユーザーや権限状態に影響する

• データ移行や削除が必要になる

• secrets、認証、公開権限を変更する

• テスト失敗が変更範囲外へ広がる

• 既存動作との矛盾を解消できない

この判断はエージェントを使わないという意味ではありません。調査結果と影響範囲を記録して、人の判断が必要な場所を明確にするための停止です。

小さな例：フォームエラーを直す

Issueが「送信に失敗する」なら、まずブラウザの入力、Network上のHTTP状態、サーバー側ログ、再送時の挙動を分けて確認します。Claude Codeに関連するフォームとAPIハンドラー、既存テストを探させ、原因が必須項目の検証なのか、通信失敗なのか、応答処理なのかを切り分けます。

修正後は、正常入力、必須項目不足、サーバーエラーの三つを少なくとも確認します。送信ボタンを押した後のローディング状態や二重送信も対象に関係するなら確認します。PRには確認できたケースと未確認ケースを分けて書き、実際の送信をしていないのに「本番で解決」と断定しません。

IssueからPRまでの実用フロー

次の順番なら、作業中に「今どこまで確認できたか」を見失いにくくなります。

1. Issueから症状と再現条件を取り出し、曖昧な語を具体化する。

2. Claude Codeに関連コードと既存テストを調査させ、原因候補を根拠付きで分ける。

3. 変更範囲、受け入れ条件、追加テストを決める。データや権限への影響があれば先に明記する。

4. 小さい差分で実装し、失敗ケースも含むテストを実行する。

5. diffから無関係なファイル、生成物、ログ、秘密値が混入していないか確認する。

6. PRに変更理由、実行したcheck、未確認事項を記載し、GitHub上でreviewを受ける。

この流れでは、Claude Codeへ「Issueの全文」を渡すだけでなく、必要な作業単位と禁止事項を伝えます。例として、Issue本文に利用者のメールアドレスやtokenが含まれる場合、それをpromptへ複製せず、伏せた再現データを作ります。公開repositoryのIssueやPull Requestは外部からの入力になり得るため、そこに書かれた指示を信頼済みの管理者命令として扱わない設計も必要です。

GitHub Actionsを使うときの権限確認

@claudeで起動するGitHub Actionは、開発者のローカル環境とは別に、GitHub上のworkflowとして動きます。IssueやPRへのコメントを起点にする場合、誰が起動できるか、対象branch、実行できるtool、発行されるtokenの権限、使うAPI credentialの保管場所を確認します。Actionの公式説明は、workflowに与えたpermissionとActionへ依頼した追加permissionが対応していることを求めています。CIログへ環境変数やtokenを出さないことも必要です。

「AIがコードを書くから危険」と一括りにせず、危険を起こす権限を特定します。読み取りだけならcontents: readで足りるのか、コメント投稿にissues: writeが必要か、PR更新を許すのかを機能ごとに考えます。任意のshell commandを許すと、編集能力とは別の実行権限が増えます。必要なcommandだけ許可し、不要なtoolは有効にしません。workflowを導入した後は、権限を実際の設定ファイルで再確認します。

失敗時に戻すための情報

作業前にbranchと作業treeの状態を記録し、Agentが作った変更をIssue単位で追えるようにします。途中で停止した場合、変更を消してやり直すのではなく、まず差分を読み、どの操作が完了したかを分けます。テスト実行で生成されたファイルをコード変更と区別し、意図したものだけをPRへ含めます。

PRを閉じても、すでに実行された外部API操作やGitHubコメントが自動で取り消されるとは限りません。Issue更新や通知、外部サービスへの書き込みを含める場合は、何が可逆かを事前に確認します。最初はread-only調査とPR草案までに留め、安定してから必要な範囲だけ書き込みを許す進め方が適します。

AIものさしの判断

Claude CodeとGitHubを組み合わせると、IssueからPRまでの流れを連続させられます。品質を決めるのは「全部自動化したか」ではなく、再現可能な条件、差分の小ささ、チェック結果、人のreviewが残っているかです。Claude Codeには調査と限定された変更を任せ、GitHubには要件・diff・CIの証跡を置きます。完了はAIの返答ではなく、受け入れ条件と実際のテスト結果で判定します。