Issue-Driven AI Development」(イシュー駆動AI開発) - Claude CodeとGitHub Issuesで効率的に開発する方法

Last updated at 2025-10-01Posted at 2025-10-01

Issue-Driven AI Development の実践ガイド

🚀 すぐに試したい方へ: テンプレートリポジトリをフォークして始められます!

💡 スクラッチから開発したいかたへ: Claude Codeでスクラッチから開発する実践ガイド

はじめに
Claude Codeとは
基本的なワークフロー
テンプレートリポジトリ
GitHub側の事前設定
安全運用のための3つの基本原則
Issue Templateの設計
コミット規約
プロジェクト構成の推奨
ai_docs/の重要性と運用
タスクが不明瞭な場合の対処法
実運用のためのガードレール
注意点
まとめ

はじめに

Claude Codeは、ターミナルから直接Claudeにコーディングタスクを委譲できる強力なツールです。本記事では、GitHub IssuesとClaude Codeを組み合わせて、効率的な開発ワークフローを構築する方法を紹介します。

大規模なコード移行、リファクタリング、コードメンテナンスなど、様々な開発タスクで威力を発揮します。言語を問わず活用できる汎用的なアプローチです。

Claude Codeとは

Claude Codeは、Anthropicが提供するコマンドラインツールで、開発者がターミナルから直接Claudeにコーディングタスクを委譲できます。詳細は公式ドキュメントをご確認ください。

基本的なワークフロー

GitHub Issueにタスクとプロンプトを記載
Claude CodeでIssueを読み込ませる
Claudeが自動でブランチ作成、コード修正、コミットを実行
Draft PRを作成
CIが自動実行され品質をチェック
作業ログをIssueに記録
レビュー後にマージ

このワークフローにより、タスクの可視化と作業の自動化を両立できます。

テンプレートリポジトリ

本記事で紹介するワークフローを実装したテンプレートリポジトリを公開しています:

📦 claude-code-workflow-template

含まれるもの:

✅ 5種類のIssue Templates(移行/バグ修正/開発/調査/提案)
✅ GitHub Actions設定(CI/自動ラベリング/Project連携)
✅ ai_docs/テンプレート(architecture, coding_standards, glossaryなど)
✅ セットアップガイドとベストプラクティス集
✅ 実例とサンプルプロジェクト

使い方:

「Use this template」でリポジトリ作成
docs/setup-guide.mdに従って初期設定
サンプルIssueで動作確認
プロジェクトに合わせてカスタマイズ

💡 このテンプレート自体も、Issue-Driven AI Developmentで構築されました!構築過程はIssue #1で確認できます。

クイックスタート

方法1: テンプレートリポジトリを使う(推奨・最短5分)

claude-code-workflow-template にアクセス
「Use this template」→「Create a new repository」をクリック
リポジトリをクローン
ai_docs/*.templateファイルをプロジェクトに合わせてカスタマイズ
最初のIssueを作成して試してみる!

詳細はセットアップガイドを参照してください。

方法2: 既存リポジトリに追加

既存のプロジェクトに導入する場合は、以下の手順で進めます。

GitHub側の事前設定

本格的に運用する前に、GitHub側で以下の設定を行っておくことを推奨します。

1. Issue Templateの配置

リポジトリのルートディレクトリに.github/ISSUE_TEMPLATE/ディレクトリを作成し、テンプレートファイルを配置します:

mkdir -p .github/ISSUE_TEMPLATE

2. Labelsの作成

以下のラベルを事前に作成しておくと、タスク管理がスムーズになります:

ラベル名	色	説明
`claude-code`	`#0E8A16`	Claude Codeで処理するタスク
`migration`	`#FBCA04`	コード移行タスク
`bug`	`#D73A4A`	バグ修正
`development`	`#1D76DB`	新機能開発
`investigation`	`#A2EEEF`	調査タスク
`rfc`	`#D4C5F9`	提案・方式検討
`in-progress`	`#C5DEF5`	作業中
`needs-review`	`#FEF2C0`	レビュー待ち
`ai-docs`	`#7057FF`	AI向けドキュメント関連

GitHub UIから: Issues → Labels → New label で作成できます。

3. GitHub Projectsの設定(オプション)

GitHub Projectsを使ってタスクを可視化する場合:

Projectsタブから新しいProjectを作成
ビューを「Board」形式に設定
以下のカラムを作成:
- 📋 ToDo: 未着手タスク
- 🔄 In Progress: 作業中(Claude Codeが処理中)
- 👀 Needs Review: レビュー待ち
- ✅ Done: 完了
Issueのステータスフィールドとカラムを連携

4. Branch Protection Rulesの設定(推奨)

Claude Codeが直接mainブランチに変更を加えないよう、保護ルールを設定:

Settings → Branches → Add branch protection rule
Branch name pattern: main (または master)
以下をチェック:
- ✅ Require a pull request before merging
- ✅ Require approvals (最低1人)
- ✅ Require status checks to pass before merging

これにより、Claude Codeの変更は必ずPR経由でレビューされます。

5. `.gitignore`の確認

Claude Codeが生成する一時ファイルや、AI用のローカルドキュメントを除外:

# Claude Code関連
.claude/
*.claude-tmp

# AI用のローカルメモ(チームで共有しない場合)
ai_docs/local/

6. CODEOWNERS設定(オプション)

重要なディレクトリへの変更には特定のレビュアーを自動アサイン:

.github/CODEOWNERSファイルを作成:

# 決済関連は必ずシニアエンジニアがレビュー
/src/payment/ @senior-engineer

# AI用ドキュメントはチームリーダーが承認
/ai_docs/ @team-leader

7. 初期ドキュメントの配置

ai_docs/ディレクトリに基本的なドキュメントを配置:

mkdir -p ai_docs/{analysis,suggestions,fixes}
touch ai_docs/architecture.md
touch ai_docs/coding_standards.md
touch ai_docs/glossary.md
touch ai_docs/README.md

ai_docs/README.mdの例:

# AI Docs

このディレクトリは、Claude Codeがタスクを実行する際に参照するドキュメントを格納します。

## ディレクトリ構成

- `architecture.md`: システムアーキテクチャの概要
- `coding_standards.md`: プロジェクトのコーディング規約
- `glossary.md`: 用語集・略語集
- `migration_guide.md`: バージョン移行時のガイドライン
- `analysis/`: 調査レポート
- `suggestions/`: Claudeからの技術的提案
- `fixes/`: バグ修正の詳細記録

## 更新ルール

- 新しい知見があれば積極的にドキュメント化
- Issue番号を含むファイル名で管理(`123-feature-name.md`)
- 定期的に古い情報を見直し

これで、Claude Codeを使った開発をスムーズに始められます!

安全運用のための3つの基本原則

Claude Codeを安全に運用するため、以下の3つの原則を全てのテンプレートに適用します。

1. 出力契約(Claude必読)

Claude Codeの出力形式を統一し、作業の透明性を確保:

## 📑 出力契約(Claude必読)
- すべてMarkdownで出力
- 各ステップ終了時に「作業ログ」節を追記(差分要約・ファイル数・既知リスク)
- エラー/不明点は「質問」節で列挙し停止(自己判断で進めない)

効果: 作業の可視化、問題の早期発見、レビュアーの負担軽減

2. スコープ境界

誤って重要なファイルを変更するのを防止:

## 📂 スコープ境界
**許可パス**:
- `src/legacy/**`
- `templates/**/*.tmpl`

**禁止パス**:
- `src/payment/**`
- `migrations/**`
- `infra/**`

※ 上記以外に変更が必要な場合はこのIssueで要承認

効果: 意図しない変更の防止、セキュリティリスクの低減

3. 安全弁

作業のリスクを段階的に管理:

## 🛡️ 安全弁
- すべて**Draft PR**で作成すること
- 10ファイル/500行を超える変更は分割コミット(理由をログに記載)
- 重大変更はまず`--dry-run`レポートを提出 → 承認後に実施

効果: レビュー前のマージを防止、変更粒度の適正化、高リスク変更の事前確認

Issue Templateの設計

GitHub Issueのテンプレート機能を使うことで、Claude Codeに最適化されたプロンプトを標準化できます。

📦 以下で紹介する全てのテンプレートは、テンプレートリポジトリから入手できます。

Template 1: コード移行・アップグレード用

.github/ISSUE_TEMPLATE/migration_task.mdとして保存:

---
name: Code Migration Task
about: コード移行・バージョンアップグレードタスク
title: '[MIGRATE] ディレクトリ名 - 簡潔な説明'
labels: migration, claude-code
assignees: ''
---

## 🎯 目的
<!-- 例: Python 2→3化、React 16→18へのアップグレード、レガシーコードのモダン化 -->


## 📂 対象
**ディレクトリ/ファイル**:
<!-- 例: `src/legacy/payment/` -->


**移行元→移行先**:
<!-- 例: Python 2.7 → Python 3.11、jQuery → React -->


**対象ファイル拡張子**:
<!-- 例: `.py`, `.js`, `.ts` など、対象とする拡張子を列挙 -->


## 📑 出力契約(Claude必読)
- すべてMarkdownで出力
- 各ステップ終了時に「作業ログ」節を追記(差分要約・ファイル数・既知リスク)
- エラー/不明点は「質問」節で列挙し停止(自己判断で進めない)

## 📂 スコープ境界
**許可パス**:
<!-- 例: `src/legacy/**`, `templates/**/*.tmpl` -->


**禁止パス**:
<!-- 例: `src/payment/**`, `migrations/**`, `infra/**` -->


※ 上記以外に変更が必要な場合はこのIssueで要承認

## 🛡️ 安全弁
- すべて**Draft PR**で作成すること
- 10ファイル/500行を超える変更は分割コミット(理由をログに記載)
- 重大変更はまず`--dry-run`レポートを提出 → 承認後に実施

## 📋 Claude Code用タスク定義

### 環境準備
1. このイシューからリモートブランチを作成
2. ブランチ名: `migrate/[issue-number]-[directory-name]`
3. このイシューとブランチを紐づけ
4. イシューステータスを「In Progress」に変更

### 実装タスク
5. 対象ディレクトリ配下のコード移行を実施
6. 上記で指定した拡張子のファイルを対象とする
7. 潜在的なバグ・非推奨機能の検出と修正
8. 変更は段階的にコミット(コミット規約に従う)

### 完了処理
9. 移行に関する技術的な推奨事項があれば`ai_docs/suggestions/[issue-number]-*.md`に記録
10. 作業ログをこのイシューに記録(変更ファイル数、主な変更内容、発見した問題点)
11. **Draft** プルリクエストを作成

## 🧾 コミット規約
[本文のコミット規約](#コミット規約)を参照

## ⚠️ 制約・注意事項
- [ ] 移行が主目的。過度なリファクタリングは避ける
- [ ] 既存の動作を壊さない
- [ ] `ai_docs/`の関連ドキュメントを参照
- [ ] 不明点は作業前にコメントで確認

## 📚 参考資料
<!-- 移行ガイド、社内ドキュメントへのリンクなど -->
- 

## ✅ 完了条件
- [ ] **CI(lint/test/build)が全てグリーン**
- [ ] 対象ディレクトリのコードが移行完了
- [ ] 既存機能が正常動作
- [ ] 主要リスク・除外項目をPR説明に明記
- [ ] 作業ログ記録済み
- [ ] Draft PRレビュー依頼済み

Template 2: バグ修正用

.github/ISSUE_TEMPLATE/bug_fix.mdとして保存:

---
name: Bug Fix Task
about: Claude Codeでバグを修正するタスク
title: '[BUG] 簡潔な問題の説明'
labels: bug, claude-code
assignees: ''
---

## 🐛 問題の説明
<!-- バグの内容を具体的に -->


## 📂 影響範囲
**ファイル/ディレクトリ**:


**再現手順**:
1. 
2. 
3. 

## 📑 出力契約(Claude必読)
- すべてMarkdownで出力
- 修正理由・影響範囲を明記
- テストケース追加の有無を報告
- エラー時は停止して質問

## 📂 スコープ境界
**許可パス**:
<!-- バグ修正に必要な最小限のパス -->


**禁止パス**:
<!-- 影響範囲外のパス -->


## 🛡️ 安全弁
- **Draft PR**で作成
- 重大なバグの場合は`--dry-run`で影響確認

## 📋 Claude Code用タスク定義

### 環境準備
1. このイシューからブランチ`fix/[issue-number]-[bug-name]`を作成
2. イシューステータスを「In Progress」に変更

### 調査・修正
3. 関連コードの分析と根本原因の特定
4. バグ修正の実装
5. 同様の問題が他にないか確認
6. 修正内容を`ai_docs/fixes/[issue-number]-*.md`に記録

### 完了処理
7. 作業ログをイシューに記録
8. **Draft** PRを作成

## 🧾 コミット規約
[本文のコミット規約](#コミット規約)を参照

## ⚠️ 注意事項
- [ ] 修正により他の機能に影響がないか確認
- [ ] テストケース追加を検討

## ✅ 完了条件
- [ ] **CI(lint/test)がグリーン**
- [ ] バグが修正され動作確認済み
- [ ] 作業ログ記録済み
- [ ] Draft PRレビュー依頼済み

Template 3: 汎用開発タスク用

.github/ISSUE_TEMPLATE/development_task.mdとして保存:

---
name: Development Task
about: Claude Codeで実装する汎用的な開発タスク
title: '[DEV] 機能名'
labels: development, claude-code
assignees: ''
---

## 🎯 目的・背景


## 📑 出力契約(Claude必読)
- 実装の設計判断を記録
- 未解決の技術的負債を明示
- エラー/不明点は質問節で停止

## 📂 スコープ境界
**許可パス**:
<!-- 開発対象のパス -->


**禁止パス**:
<!-- 変更してはいけないパス -->


## 🛡️ 安全弁
- **Draft PR**で作成
- 10ファイル/500行超える場合は分割コミット

## 📋 Claude Code用タスク定義

### 準備
1. ブランチ`feature/[issue-number]-[feature-name]`を作成
2. イシューステータスを「In Progress」に変更

### 実装
3. [具体的なタスクを記載]
4. 
5. 

### ドキュメント・完了処理
6. 必要に応じて`ai_docs/`にドキュメント作成
7. 作業ログをイシューに記録
8. **Draft** PRを作成

## 🧾 コミット規約
[本文のコミット規約](#コミット規約)を参照

## ⚠️ 制約・注意事項
- 

## ✅ 完了条件
- [ ] **CI(lint/test/build)がグリーン**
- [ ] 実装完了
- [ ] 動作確認済み
- [ ] ドキュメント更新済み
- [ ] 作業ログ記録済み
- [ ] Draft PRレビュー依頼済み

Template 4: 調査タスク用

.github/ISSUE_TEMPLATE/investigation_task.mdとして保存:

---
name: Investigation Task
about: コードの調査・分析・計画立案タスク
title: '[INVESTIGATE] 調査対象'
labels: investigation, claude-code
assignees: ''
---

## 🔍 調査目的
<!-- 何を明らかにしたいか -->


## 📂 調査対象
**ディレクトリ/ファイル**:


**技術/ライブラリ**:


## 📑 出力契約(Claude必読)
- レポートは必ずMarkdown形式
- 不明点は「不明」と明記(推測しない)
- 次のIssue候補を3件以上提案

## 📋 Claude Code用タスク定義

1. 構成・依存関係の把握
2. 非推奨/セキュリティ/パフォーマンス観点の洗い出し
3. 影響度×難易度マトリクスの作成
4. 推奨アプローチ案(ステップ/所要時間/リスク)を提示
5. 調査レポートを`ai_docs/analysis/[issue-number]-report.md`に作成
6. このIssueに1ページ要約(箇条書き)をコメント

## 📄 レポート形式

レポートには以下のセクションを含める:

**サマリー**
- 調査対象
- 主な発見

**詳細分析**
- コード構造(ファイル構成、主要なクラス/関数)
- 技術スタック(使用技術・ライブラリ、バージョン情報)
- 問題点・改善点(影響度・対応難易度・推奨対応を含む)
- 依存関係(内部依存・外部依存)

**推奨アクション**
- 優先度順に列挙

**次のステップ**
- 作成すべきIssueの提案

## ✅ 完了条件
- [ ] 調査レポート作成完了
- [ ] Issueに要約コメント追加
- [ ] 次のアクション案が明確(実装Issueを3件以上提案)

Template 5: 提案・方式検討用

.github/ISSUE_TEMPLATE/spike_rfc.mdとして保存:

---
name: Spike / RFC
about: 方式検討・プロトタイプ・技術的意思決定
title: '[RFC] テーマ'
labels: rfc, claude-code
assignees: ''
---

## 🎯 背景・課題
<!-- なぜこの検討が必要か -->


## 🧩 選択肢

### 案1: [タイトル]
**Pros**:
- 

**Cons**:
- 

**リスク**:
- 

### 案2: [タイトル]
**Pros**:
- 

**Cons**:
- 

**リスク**:
- 

## 🧪 スパイク計画
<!-- 小規模検証の内容 -->
1. 検証環境の準備
2. プロトタイプ実装
3. パフォーマンス測定
4. 結果の分析

## 📑 出力契約(Claude必読)
- 推奨理由は具体的に記述
- リスクを必ず明記
- 判断に必要な情報が不足している場合は質問

## 📋 Claude Code用タスク定義

1. 各選択肢の技術調査
2. 簡易プロトタイプ実装(必要に応じて)
3. 比較分析レポートを`ai_docs/analysis/[issue-number]-rfc.md`に作成
4. このIssueに推奨案をコメント

## 📄 成果物内容

レポートには以下を含める:
- 各選択肢の詳細比較
- 採用推奨案と理由
- 却下案と理由
- 追加検証が必要な項目

## ✅ 完了条件
- [ ] RFC文書作成完了
- [ ] レビュー合意(最小1名)
- [ ] 次アクションのIssue発行(採用案を実装するIssue)

コミット規約

全てのテンプレートで統一されたコミット規約を使用します。Conventional Commits形式を採用し、自動化ツールとの連携やリリースノート生成を容易にします。

基本形式

<type>(<scope>): <subject> (#issue-number)

type の種類

type	説明	例
`feat`	新機能追加	`feat(auth): add two-factor authentication (#123)`
`fix`	バグ修正	`fix(payment): prevent null pointer in handler (#456)`
`refactor`	リファクタリング	`refactor(legacy): replace mysql_* with PDO (#789)`
`chore`	ビルド・設定変更	`chore(deps): update dependencies (#100)`
`docs`	ドキュメント変更	`docs(api): update endpoint documentation (#200)`
`test`	テスト追加・修正	`test(auth): add login test cases (#300)`
`style`	コードスタイル修正	`style(format): apply prettier formatting (#400)`
`perf`	パフォーマンス改善	`perf(query): optimize database queries (#500)`

scope の指定

変更対象のモジュール・コンポーネント名を指定:

auth, payment, user, api, legacy, admin など

subject の書き方

動詞で始める(add, fix, update, remove など)
現在形を使用
文末にピリオド不要
50文字以内を目安に簡潔に

コミット粒度

1コミット = 1意図を守ります:

✅ 良い例:

refactor(auth): replace session_start with modern handler (#123)
refactor(auth): add error handling for session operations (#123)
test(auth): add session handler test cases (#123)

❌ 悪い例:

fix: various updates to auth module (#123)

大規模変更の分割

10ファイル/500行を超える変更は分割コミット:

refactor(legacy): migrate database layer (part 1/3) (#123)
refactor(legacy): migrate business logic (part 2/3) (#123)
refactor(legacy): update tests and docs (part 3/3) (#123)

理由は作業ログに記載します。

プロジェクト構成の推奨

Claude Codeを効果的に使うためのディレクトリ構成:

project/
├── .github/
│   ├── ISSUE_TEMPLATE/
│   │   ├── migration_task.md
│   │   ├── bug_fix.md
│   │   ├── development_task.md
│   │   ├── investigation_task.md
│   │   └── spike_rfc.md
│   └── workflows/
│       ├── ci.yml
│       └── claude-code-support.yml
├── ai_docs/                    # Claude用のドキュメント(重要!)
│   ├── README.md              # このディレクトリの使い方
│   ├── architecture.md        # システムアーキテクチャ
│   ├── coding_standards.md   # コーディング規約
│   ├── glossary.md           # 用語集・略語集
│   ├── migration_guide.md    # 移行ガイド(プロジェクト固有)
│   ├── analysis/             # 調査レポート
│   │   └── 001-*.md
│   ├── suggestions/          # Claudeからの提案
│   │   └── 123-*.md
│   └── fixes/                # バグ修正の記録
│       └── 456-*.md
└── src/
    └── ...

ai_docs/の重要性と運用

ai_docs/ディレクトリは、Claude Codeの作業品質を左右する最重要な要素です。人間のチームメンバーにプロジェクトのWikiを共有するのと同じように、Claudeにもプロジェクトの文脈を理解させる必要があります。

なぜai_docs/が重要なのか

プロジェクト固有の文脈を提供 - 業務用語、ドメイン知識、設計思想をClaude Codeが理解
作業の精度が劇的に向上 - コーディング規約に沿ったコード生成、アーキテクチャを壊さない変更
知識の蓄積 - Claude Codeからの提案や発見を記録し、チーム全体のナレッジベースとして機能
作業時間の短縮 - Issue毎に背景説明を書く必要がなく、「ai_docs/を参照」だけで十分なコンテキストを提供

必須ドキュメント

最低限、以下のドキュメントを用意することを強く推奨します:

1. `architecture.md` - システム構成

# システムアーキテクチャ

## 全体構成
- フロントエンド: React 18 + TypeScript
- バックエンド: Node.js + Express
- データベース: PostgreSQL 14

## ディレクトリ構造
- `src/frontend/`: React コンポーネント
- `src/backend/api/`: REST APIエンドポイント
- `src/backend/services/`: ビジネスロジック

## 設計原則
- Clean Architectureを採用
- ビジネスロジックとフレームワークを分離

## 重要な制約
- 決済処理は必ずトランザクション内で実行
- 個人情報は暗号化して保存

2. `coding_standards.md` - コーディング規約

# コーディング規約

## 命名規則
- 変数/関数: camelCase (`getUserData`)
- クラス/コンポーネント: PascalCase (`UserProfile`)
- 定数: UPPER_SNAKE_CASE (`API_BASE_URL`)

## TypeScript規約
- `any`型の使用は原則禁止
- null/undefinedの扱いは明示的に

## 禁止事項
- console.logのコミット禁止(本番環境用ロガーを使用)
- グローバル変数の使用

3. `glossary.md` - 用語集

# 用語集・略語集

## ドメイン用語
- **会員**: システムに登録したユーザー
- **ポイント**: 購入時に付与される仮想通貨(1ポイント=1円)

## プロジェクト固有の略語
- **UGC**: User Generated Content
- **KYC**: Know Your Customer(本人確認)

運用のコツ

具体例を多用する

❌ 悪い例: 適切な命名をすること
✅ 良い例: 
- ユーザー取得関数: `getUser()` ではなく `fetchUserById()`
- boolean変数: `flag` ではなく `isActive`, `hasPermission`

「なぜ」を記録する

## セッション処理の注意事項
既存システムとの互換性のため、セッションIDの生成方法は変更しないこと。
理由: 旧システムと新システムでセッションを共有する必要があるため。

禁止事項を明示

## やってはいけないこと
- ❌ 直接DBを変更する生SQLの実行
- ❌ 個人情報をログに出力
- ❌ ハードコードされた設定値

Issue Templateとの連携

## ⚠️ 制約・注意事項
- [ ] `ai_docs/coding_standards.md`のルールに従う
- [ ] `ai_docs/migration_guide.md`の手順を参照

このように、Issue内で明示的に参照させることで、Claude Codeが適切なドキュメントを読み込みます。

よくある質問

Q: ai_docs/はリポジトリにコミットすべき?
A: はい、必ずコミットしてください。チーム全体とClaude Code両方が参照します。

Q: 機密情報が含まれる場合は?
A: .gitignoreで除外するか、privateリポジトリを使用してください。

Q: どれくらい詳細に書くべき?
A: 新しいメンバーがオンボーディングで読むレベルの詳細度が目安です。

タスクが不明瞭な場合の対処法

Claude Codeに具体的な指示を出せない場合、以下のアプローチが有効です。

アプローチ1: 調査タスクから始める

まずはClaude Codeに「調査」を依頼し、その結果を元に具体的なタスクを定義します。

Investigation Task テンプレートを使用して、現状分析→計画立案→具体的なタスク化の流れで進めます。

アプローチ2: 段階的タスク定義

大まかな方向性だけ指示し、Claude Codeに詳細を判断させます。

## 🎯 目的
パフォーマンス改善

## 📋 Claude Code用タスク定義

1. プロファイリングツールを使ってボトルネックを特定
2. 特定されたボトルネックについて改善案を`ai_docs/suggestions/performance-improvements.md`に記載
3. 改善案の中で、影響範囲が小さく効果が高いものから着手

アプローチ3: 対話型タスク定義

Issue上でClaude Codeと対話しながらタスクを明確化します。

## 📋 Claude Code用タスク定義

### ステップ1: 現状分析
1. このIssueにコメントで以下を報告:
   - コードの現状(複雑度、重複、テストカバレッジなど)
   - 改善すべき優先順位トップ5

### ステップ2: 承認待ち
2. 報告を受けて、人間が優先順位を決定

### ステップ3: 実装
3. 承認されたタスクを実行

ベストプラクティス

不明瞭なタスクは分割する: 「調査」→「計画」→「実装」のように段階的に進める
Claude Codeに質問させる: 不明点があれば作業前にIssueで質問するよう指示
小さく始める: まずは1ファイルで試行し、問題なければ展開

実運用のためのガードレール

前述の3つの基本原則に加え、以下の自動化を導入すると運用が安定します。

GitHub Actionsの最小セット

.github/workflows/claude-code-support.yml:

name: Claude Code Support
on:
  pull_request:
    types: [opened, ready_for_review]
  issues:
    types: [opened, labeled]

jobs:
  label-pr:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - name: Add labels to PR
        uses: actions-ecosystem/action-add-labels@v1
        with:
          labels: |
            claude-code
            needs-review
      
      - name: Link to Issue
        uses: actions/github-script@v7
        with:
          script: |
            const issue_number = context.payload.pull_request.body.match(/#(\d+)/)?.[1];
            if (issue_number) {
              await github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: parseInt(issue_number),
                body: `✅ PR created: #${context.payload.pull_request.number}`
              });
            }

  move-to-project:
    if: github.event_name == 'issues' && contains(github.event.issue.labels.*.name, 'claude-code')
    runs-on: ubuntu-latest
    steps:
      - name: Add to GitHub Projects
        uses: actions/add-to-project@v0.5.0
        with:
          project-url: https://github.com/users/YOUR_USERNAME/projects/YOUR_PROJECT_NUMBER
          github-token: ${{ secrets.GH_PAT }}

CI設定の例

.github/workflows/ci.yml:

name: CI
on: 
  pull_request:
  push:
    branches: [main, develop]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup
        run: |
          # プロジェクトのセットアップコマンド
          npm ci
      
      - name: Lint
        run: npm run lint
      
      - name: Test
        run: npm test
      
      - name: Security Check
        run: npm audit

効果

Issue/PR作成時の手動作業削減
GitHub Projectsへの自動追加
品質チェックの自動実行

注意点

セキュリティ

機密情報をIssueに記載しない
APIキーや認証情報は環境変数で管理
Claude Codeに渡すコンテキストを制限

レビュー

Claude Codeが生成したコードは必ず人間がレビューしましょう:

自動テストの実行
コードレビューの実施
動作確認

スコープ管理

Claudeに過度に広範なタスクを与えると、意図しない変更が発生する可能性があります。制約を明確に指定しましょう。

まとめ

Claude CodeとGitHub Issuesを組み合わせることで:

✅ タスクが可視化され、チーム全体で共有可能
✅ プロンプトが再利用可能で、品質が安定
✅ 作業履歴がIssueに記録され、トレーサビリティが向上
✅ 大規模なコード移行・メンテナンスが効率化
✅ 出力契約/スコープ境界/安全弁で事故率が大幅に低減
✅ CIとの統合で品質が自動保証

今すぐ始める

テンプレートを使う: claude-code-workflow-templateをフォーク
カスタマイズ: ai_docs/をプロジェクトに合わせて編集
実践: 最初のIssueを作成してClaude Codeに指示

あなたのプロジェクトに最適化されたワークフローを構築してみてください!

フィードバック歓迎

このテンプレートリポジトリは改善を続けています。Issue、PR、スターでのフィードバックをお待ちしています!

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up