「何を直すか」もClaudeに任せる ── GitHub Issues 起点の委任フロー

こんにちは、白々さじきです。

Claude Code への完全委任開発を検証しているこのプロジェクト。今回は「何を直すか」という選定そのものを Claude Code に任せた話です。

これまでは「◯◯を実装して」「△△を修正して」と具体的な指示を渡していました。でも、ある日こう試してみました。

「バグのラベルのついたIssueを確認して、取り組みやすそうなものを選んで」

これが思いのほかうまく機能したので、そのフローと気づきをまとめます。

委任フローの全体像
実際のプロンプト例
Issue の質が委任の精度を決める
承認ポイントを守る重要性
この記事で修正したバグの顛末
まとめ
サポートのお願い

委任フローの全体像

通常の委任フローでは、人間が「何をやるか」を決めてから Claude Code に渡します。今回試したのは、その「何をやるか」の部分まで含めた委任です。

【従来の委任フロー】
人間：何をやるか決定 → 指示を渡す → Claude Code：実装

【今回の委任フロー】
人間：方向性だけ指示
  ↓
Claude Code：Issues 一覧を確認
  ↓
Claude Code：バグ選定（候補を提示）
  ↓
人間：承認 ← ここだけ人間が判断
  ↓
Claude Code：修正方針を計画立案
  ↓
人間：承認
  ↓
Claude Code：実装

人間がやることは「バグIssueを見て」という方向性の指示と、2回の承認だけです。選定・計画・実装はすべて Claude Code が担います。

実際のプロンプト例

セッションの冒頭にこう入力しました。

バグのラベルのついたIssueを確認して

Claude Code は gh issue list --label bug を実行し、一覧を取得してくれました。

#14  「トップに戻る」リンクが遷移元に関わらず常に / に戻る  bug

オープン中のバグIssueはこれ1件でした。Claude Code はそのまま「この Issue #14 に取り組みますか？」と提案してきました。

Issue の内容は：

利用規約・プライバシーポリシー・FAQの「← トップに戻る」リンクが常に / に飛ぶ
再現手順・期待する動作・実際の動作が明確に書かれている

Claude Code はこの情報を読んだうえで、「修正方針を先に立案してもよいですか」と確認してきました。承認すると、計画を提示し、再度承認を得てから実装に移りました。

人間がやったのは「バグのラベルのついたIssueを確認して」という1文と、2回の「はい」だけです。

Issue の質が委任の精度を決める

Claude Code への委任というと、「仕様を渡して実装させる」というイメージが一般的です。「ボタンを追加して」「APIを修正して」といった具合に、何をするかは人間が決めます。

今回気づいたのは、「何をやるか」の選定自体も委任できるということです。

ただし、これが機能するには前提条件があります。

Issues が整備されていること。

今回うまくいったのは、Issue #14 に以下がきちんと書かれていたからです。

タスクの概要
再現手順
期待する動作
実際の動作
完了条件

これがなければ Claude Code は「何が問題なのか」「どこを直せばいいか」を把握できません。Issueの質が委任の精度に直結します。

教訓①：Issues の粒度・ラベル整備が委任品質に直結する

ラベルがなければ絞り込みができません。再現手順がなければ判断材料が不足します。「いい Issue を書く」ことは、人間への説明だけでなく、Claude Code への発注精度にも影響します。

承認ポイントを守る重要性

このプロジェクトの CLAUDE.md には「大きな変更は必ず計画を先に提示し、承認後に実装すること」と書いてあります。

今回のフローはこれが自然に機能した実例でした。

Claude Code は勝手に実装を始めませんでした。Issue の確認 → 選定提案 → 計画立案 → 承認確認 → 実装、という順序を守ってくれました。

委任しても「何をやるか」の承認だけは人間が握る。これは意識的に設計した順序です。もし承認なしで進んでいたら、想定外のファイルが書き換えられていたかもしれません。

教訓②：委任しても「選定の承認」だけは人間が握る

「全部任せた」と「承認だけは自分が判断する」は両立します。むしろ承認ポイントを明示的に設けることが、委任を安全に機能させる鍵です。

この記事で修正したバグの顛末

Issue #14 の修正は、想定より大きくなりました。

「← トップに戻る」を遷移元に応じて変えるだけに見えましたが、実装を進めると4つの設計判断が連鎖しました。document.referrer vs location.state の選択、フッターリンクの <a> から <Link> への統一、行き止まりページのフッター削除、そして App.tsx から各ページへのフッター分散。

詳細は別記事（「戻るリンクを直すだけのつもりが、SPA設計を4回見直すことになった話」）に書きました。

ここで触れておきたいのは、Issues 起点で始めたからこそ、問題の背景を把握した状態で作業できたという点です。

Issue に「管理ページから来た場合は管理ページに戻る」という期待動作が書かれていたため、Claude Code は「この修正が単なるリンク差し替えではなく、遷移元の文脈を保持する設計の問題だ」と最初から認識していました。

Issueなしで「戻るリンクがおかしい」とだけ伝えていたら、表層的な修正で終わっていた可能性があります。

教訓③：GitHub Issues に再現手順・期待動作が書いてあると、委任の精度が上がる

まとめ

今回学んだことを3つにまとめます。

#	教訓
①	Issues の粒度・ラベル整備が委任品質に直結する
②	委任しても「選定の承認」だけは人間が握る
③	GitHub Issues に再現手順・期待動作が書いてあると、委任の精度が上がる