【GitHubActions × Claude】完全自立開発サイクルを実現する

karrinn

著者

2025年11月25日 • 0 コメント

Claudeを使っているけど、「そもそも何をすべきか考えるのが面倒」や「もっと自動的に開発を進めてほしい」と思ったことはありませんか？
この記事では、GitHub Actions と Claude Code Action を組み合わせて、Issue発行から実装・レビュー・マージまでを完全自動化する方法を解説します。

KEY TAKEAWAYS

この記事でわかること

完全自立開発サイクルの全体像と仕組み
GitHub Actions + Claude Code Action の具体的な設定方法
AIへの指示のコツと文章量の最適化テクニック
セキュリティとポリシー違反を避けるための注意点

あなたはこんなことで困っていませんか？

Claudeを使い始めた開発者が、よく抱える悩みをまとめました。

悩み1: 何をすべきかわからない

「作りたいものはあるけど、何から始めればいいの？」
「タスクの分解が難しくて、AIに上手く指示できない」
「毎回プロンプトを考えるのが面倒...」

悩み2: もっと自動化したい

「AIにもっと自動的に開発を進めてほしい」
「手動で指示を出すのが億劫になってきた」
「レビューやマージも自動化できないの？」

悩み3: 寝てる間に進めてほしい

「自分が寝ている間にAIが開発を進めてくれたら...」
「定期的に自動でタスクを進めてほしい」
「朝起きたらPRが上がってたら最高」

この記事で実現できること

最初に「何を作りたいか」を伝えるだけで、マイルストーン・Issue・ラベルが自動作成される
定期的にIssueが自動発行され、Claudeが勝手に実装を開始する
PRレビュー・マージ・改善提案まで、開発サイクル全体が自動化される
プロジェクトマネジメントの理解が深まる（後述）

隠れた魅力: プロジェクトマネジメントの理解が深まる

この自動化の仕組みを構築する過程で、開発プロジェクトのマネジメントに対する理解が自然と深まります。

なぜなら、AIに自動で開発を進めさせるには「タスクの分解方法」「優先度の判断基準」「完了条件の定義」「レビューの観点」など、 プロジェクトマネジメントの核心部分を明文化してAIに教える必要があるからです。

言ってみれば、AIにプロジェクトマネジメントを教育するようなもの。普段なんとなくやっていたことを言語化・構造化することで、自分自身のマネジメントスキルも向上します。

Before / After: 従来の開発 vs 自動化開発

具体的に何がどう変わるのか、従来の手動開発と自動化後の開発フローを比較してみましょう。

Before: 従来の開発フロー

毎朝のルーティン: Issueを確認し、優先度を判断し、何から始めるか決める
手動でブランチ作成: ブランチ名を考え、チェックアウト、PR作成...
レビュー待ち: PRを作成したら、誰かがレビューしてくれるのを待つ
マージ後の確認: 手動でテスト、問題があれば手動で Issue 作成

開発者の時間: 1日8時間がルーティンワークに消費

After: 自動化開発フロー

自動Issue作成: バグ・改善提案がマージ後に自動生成される
自動実装: 優先度の高いIssueをClaudeが自動で選んで実装開始
自動レビュー: PRが作成されると、Claudeが自動でレビュー・マージ判定
24時間稼働: 寝ている間も、休日も、開発サイクルが回り続ける

開発者の時間: 創造的な仕事に集中できる

補足: 完全自動化の意味

「完全自動化」といっても、人間の監視が不要になるわけではありません。定期的にPRやIssueを確認し、方向性がずれていないか、品質に問題がないかチェックすることは必須です。自動化の目的は「人間を置き換える」ことではなく、「人間がより価値の高い仕事に集中できるようにする」ことです。

実は「部分導入」がおすすめ

この記事では「完全自動化」を紹介しますが...

実際には、すべてを自動化するのではなく、困っている部分だけを選んで導入する方がおすすめです。

ありとあらゆる意思決定や実装をAIに任せてしまうと、気がついたら自分の思い描いていたものから外れていってしまったり、自身の実装方針やプロジェクト管理方法に合わなくなってしまうことがあります。

完全自動化の落とし穴

意思決定の過程が見えなくなり、プロジェクトの方向性がブレる
自分の実装スタイルやコーディング規約から乖離していく
AIが生成したドキュメントや仕様が形骸化し、実装と乖離する
「気づいたら何が動いているかわからない」状態になりがち

部分導入のメリット

本当に困っている部分だけを自動化し、効率化できる
重要な意思決定は人間が行い、実装の詳細だけをAIに任せる
自分のワークフローに合った形でカスタマイズできる
段階的に導入でき、問題があれば軌道修正しやすい

部分導入の具体例

完全自動化ではなく、以下のような「ピンポイント自動化」から始めるのがおすすめです。

PR作成時にドキュメントを自動生成
実装が完了したら、PRの内容に応じてドキュメントを既定のディレクトリに配置・更新させる
マージ後のリファクタリング提案
マージされたコードを分析して、改善余地がある箇所を Issue として提案させる
定型的なテストコードの生成
新規に追加された関数やクラスに対して、基本的なテストケースを自動生成させる
Issue のタスク分解のみを自動化
大きなタスクをatomicなIssueに分解させるだけで、実装は自分で行う

筆者の経験から

最近筆者もバイブコーディングとまではいかないものの、AIに書かせることで詳細の定義やドキュメント化が漏れてしまうことがよくあります。実装スピードは上がったものの、後から「あれ、この機能ってどういう仕様だったっけ？」となることも。 完全自動化は魅力的ですが、自分のプロジェクトで本当に困っている部分だけを選んで導入する方が、長期的には健全です。

この記事では「完全自動化」の仕組みを紹介します

上記を踏まえた上で、この記事では技術的な可能性を示すために「完全自動化」の仕組みを解説します。読者のみなさんは、この中から自分のプロジェクトに合った部分だけを選んで実装してください。すべてを導入する必要はありません。

この記事で出てくる専門用語

まずは基本用語を押さえておきましょう。すでに知っている方は読み飛ばしてOKです。

TERM 01

GitHub Actions

GitHubが提供するCI/CD（継続的インテグレーション/デリバリー）サービス。コードのプッシュや定期実行をトリガーに、自動でワークフローを実行できます。

TERM 02

Claude Code Action

Anthropic公式のGitHub Action。PRやIssueで@claudeとメンションすると、Claudeがコード分析・実装・レビューを自動実行します。

TERM 03

cron（クーロン）

UNIX系OSで使われるジョブスケジューラ。0 9 * * *のような形式で、「毎日9時に実行」といった定期実行を設定できます。

TERM 04

GitHub Secrets

APIキーやトークンなどの機密情報を安全に保管する仕組み。ワークフローから参照できますが、ログには出力されません。

TERM 05

マイルストーン

プロジェクトの節目となる目標。複数のIssueをグループ化して、進捗を管理できます。「v1.0リリース」「基盤構築フェーズ」などに使います。

TERM 06

atomic Issue

これ以上分割できない最小単位のIssue。「1クラス/1メソッド」程度の粒度で、AIが迷わず実装できるサイズに分解します。

TERM 07

PAT (Personal Access Token)

GitHubのユーザー認証トークン。Fine-grained token（きめ細かいアクセス許可）を使用し、必要最小限の権限のみを付与することが推奨されます。

TERM 08

allowed_tools

Claude Code Actionで許可するツールのリスト。gh（GitHub CLI）、git、pythonなどを指定し、セキュリティを確保します。

TERM 09

Draft PR

作業中であることを示すPull Request。gh pr create --draftで作成し、実装完了後にgh pr readyでレビュー待ち状態に変更します。

TERM 10

workflow_dispatch

GitHub Actionsの手動実行トリガー。ActionsタブやREST APIから任意のタイミングでワークフローを起動できます。デバッグに便利です。

TERM 11

Incoming Webhook

外部サービスからSlackへメッセージを送信する仕組み。GitHub ActionsからSlack通知を送る際に使用します。Slack App管理画面で設定します。

TERM 12

permissions（権限ブロック）

GitHub Actionsワークフローに付与する権限の宣言。contents: write、issues: writeなど、最小権限の原則に従って設定します。

GitHub Actions 公式ドキュメント | PAT 管理

完全自立開発サイクルの全体像

まずは全体像を把握しましょう。以下の図は、GitHub Actions と Claude Code Action を組み合わせた自動化の仕組みを示しています。

自動化の流れ

4つのステップで開発サイクルが自動的に回ります。

定期実行: GitHub Actions が cron で起動
Issue作成: テンプレートから自動でIssue発行
@claude: コメントでClaudeをメンション
自動実行: Claudeがタスクを実行

実行されるタスク

様々なタスクを定期的に自動実行できます。

Issue作成: バグ報告・改善提案の自動生成
Issue分解: 大型タスクをatomicに分割
実装: 優先度順にコード実装
レビュー・マージ: PRの自動レビューとマージ判定

ワークフロー間の連携サイクル

各ワークフローは独立して動作しますが、全体として一つの開発サイクルを形成します。以下の図は、24時間自動で回り続けるサイクルを示しています。

Issue作成フェーズ

claude-issue-creatorが定期的に実行され、マージ済みPRを分析。バグの可能性や改善提案を自動でIssue化します。

実行タイミング: 12:00, 18:00 JST

分解・整理フェーズ

claude-issue-decomposerが大きなIssueを分解し、 claude-organizerがラベルや優先度を整理します。

実行タイミング: 10:00, 16:00 JST（分解）/ 0:00 JST（整理）

実装・レビューフェーズ

claude-implementerが実装、claude-reviewerがレビュー・マージ。この成果がまた分析対象となり、サイクルが回ります。

実行タイミング: 1日3〜4回

仕組みを理解する：3つの構成要素

この自動化は、定期実行ワークフロー・タスクテンプレート・Claude Code Actionの3つで構成されています。

構成要素1: 定期実行ワークフロー

GitHub Actions の schedule イベントを使って、cronで定期的にワークフローを実行します。ポイントは、Issue を作成してから @claude でコメントするという2段階の処理です。

設定のポイント

このワークフローは毎日3回（9:00, 15:00, 21:00 JST）自動実行されます。

schedule: cron形式で定期実行
workflow_dispatch: 手動実行も可能に
gh issue create: Issue自動作成
gh issue comment: @claudeメンション

claude-implementer.yml

name: Claude Implementer
on:
schedule:
# 毎日 9:00, 15:00, 21:00 JST (UTC: 0:00, 6:00, 12:00)
- cron: '0 0,6,12 * * *'
workflow_dispatch:  # 手動実行も可能

jobs:
create-implementation-task:
runs-on: ubuntu-latest
permissions:
contents: read
issues: write
pull-requests: read
steps:
- uses: actions/checkout@v4
with:
    ref: develop

- name: Create Implementation Task Issue
env:
    GH_TOKEN: ${{ secrets.PAT_TOKEN }}
run: |
    TIMESTAMP=$(date +"%Y%m%d-%H%M")
    ISSUE_NUM=$(gh issue create \
    --title "IMPL-${TIMESTAMP}: 機能実装タスク" \
    --body-file .github/templates/implementation-task.md \
    --label "automation,implementation")

    # Claudeをメンションしてタスク開始
    gh issue comment $ISSUE_NUM \
    --body "@claude このIssueのタスクを実行してください"

構成要素2: タスクテンプレート

テンプレートファイル（.github/templates/*.md）に、Claudeへの詳細な指示を記述します。「何をすべきか」「何をしてはいけないか」を明確に書くのがコツです。

テンプレートのポイント

AIが「分析だけして終わり」にならないよう、禁止事項を明記することが重要です。

実行フロー: 具体的な手順を番号付きで記載
禁止事項: やってはいけないことを明示
スクリプト: 判断ロジックをBashで記述
完了条件: 何をもって完了とするか

implementation-task.md

# 機能実装タスク

## 実行フロー
1. 優先度の高いIssueを1つ選ぶ
2. 実装用ブランチを作成
3. Draft PRを作成
4. 実装・テストを実行
5. Ready for Review に変更

## 禁止事項（必ず守ること）
- 分析・推奨・説明だけで終わらない
- コード実装しない、コミットしない
- 複数のIssueに手を出さない
- Draft PRのまま放置しない

## Issue選択スクリプト
```bash
# 優先度順に検索
gh issue list --label "priority:critical" --state open
gh issue list --label "bug,priority:high" --state open
gh issue list --label "priority:high" --state open
```

## 完了条件
- `gh pr ready` を必ず実行
- PR本文に `Closes #N` を記載

テンプレート設計のベストプラクティス

具体的な手順を番号付きで

AIが迷わず実行できるよう、1, 2, 3... と順序立てて記述します。曖昧な表現は避け、「〇〇を実行する」のように動詞で終わる形にします。

禁止事項は必須！

「分析だけ」「推奨文だけ」で終わらせないために、明確に禁止事項を書きます。「〜しない」「〜は禁止」のように断定的に記述します。

判断ロジックはスクリプトに

条件分岐が多いと、テンプレートが複雑になります。 BashやPythonスクリプトに判断ロジックを切り出し、AIには結果だけを渡します。

完了条件を明確に

何をもって「完了」とするかを明記します。「PRを作成する」「gh pr readyを実行する」など、検証可能な条件にします。

重要: テンプレートは100行以内に！

文章量が多すぎるとAIが混乱し、指示を守れないことが増えます。複雑なタスクは別ワークフローに分割し、各テンプレートは日本語で100行程度に収めてください。

構成要素3: Claude Code Action

@claude メンションをトリガーに、Claude Code Action が起動します。allowed_tools で使用可能なツールを制限し、セキュリティを確保します。

設定のポイント

issue_comment イベントで @claude を検知し、自動実行します。

anthropic-api-key: Secrets から取得
allowed_tools: 許可するツール一覧
model: 使用するClaudeモデル
timeout_minutes: タイムアウト設定

claude.yml

name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]

jobs:
claude:
if: contains(github.event.comment.body, '@claude')
runs-on: ubuntu-latest
permissions:
contents: write
issues: write
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
    fetch-depth: 0

- uses: anthropics/claude-code-action@v1
with:
    claude-code-oauth-token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
    allowed_tools: "gh,git,python,node,npm,docker,curl"
    model: "claude-sonnet-4-20250514"
    timeout_minutes: 60

Claude Code Action 公式リポジトリ

実践: 様々な自動化ワークフロー

実際に使われている様々な自動化ワークフローを紹介します。目的に応じて組み合わせることで、開発サイクル全体をカバーできます。

ワークフロー名	実行タイミング	主な処理内容
claude-issue-creator	毎日 12:00, 18:00 JST	マージ済みPRを分析し、バグ・改善提案Issueを自動作成
claude-issue-decomposer	毎日 10:00, 16:00 JST	大型Issueをatomic（最小単位）に分解
claude-implementer	毎日 9:00, 15:00, 21:00 JST	優先度の高いIssueを1つ選んで実装
claude-reviewer	毎日 10:00, 13:00, 16:00, 19:00 JST	PRのコードレビュー・マージ判定
claude-branch-cleaner	毎週月曜 01:00 JST	マージ済みブランチの整理・削除
claude-doc-checker	PRオープン時	PRのドキュメント整合性チェック

Issue分解の仕組み

大きなタスクは、AIが迷わず実装できる「atomic」な粒度に分解します。再帰的に分解することで、複雑な機能も着実に実装できます。

分解の判定基準

以下の基準で「atomic（これ以上分解不要）」かどうかを判定します。

粒度: 1クラス/1メソッド程度
明確さ: 実装手順が明確
見積もり: 1-2時間以内で完了
依存関係: 他のIssueに依存しない

ラベル体系
parent: 分解元
child: 分解先
atomic: 最小単位

issue-decomposition-task.md

# Issue分解タスク

## 判定基準
- 1クラス/1メソッド程度の粒度か？
- 実装手順が明確か？
- 見積もり時間が1-2時間以内か？

## 分解フロー
1. atomic/parentラベルがないIssueを1つ選択
2. 上記基準で判定

### 分解が必要な場合
- 親Issueに `parent` ラベルを付与
- 子Issueを複数作成（各々に@claudeメンション）
- 子Issueには `child` ラベルを付与

### 分解不要な場合
- `atomic` ラベルを付与して完了

## 禁止事項
- 分析だけで終わらない
- 複数Issueに手を出さない

分解の具体例: ユーザー認証機能

親Issue (parent)

#42: ユーザー認証機能の実装

ログイン、登録、パスワードリセット、セッション管理を含む認証システム全体

子Issues (child + atomic)

#43 ログインフォームコンポーネント

#44 パスワードバリデーション

#45 JWT トークン生成・検証

#46 セッション管理API

ステップバイステップ: 初期セットアップ手順

ここからは、実際に自動化を導入するための手順を詳しく解説します。順番に進めることで、完全自立開発サイクルを構築できます。

Step 1認証情報の準備

方法A: Claude Code CLI を使う（推奨）

Claude Code CLI で対象リポジトリを開く
/install-github-app コマンドを実行
CLAUDE_CODE_OAUTH_TOKEN と claude.yml が自動設定される

※ 自動生成される claude.yml は基本設定のみ。カスタマイズが必要。

GitHub Personal Access Token（PAT）

@claude メンションを行うために必要（ワークフロー起動権限のあるアカウントで作成）

GitHub Settings にアクセス
「Generate new token」→「Fine-grained token」を選択
権限: Contents, Issues, Pull requests (Read/Write)
生成されたトークンをコピー

ポイント: PATはワークフロー起動権限を持つアカウント（通常はリポジトリオーナー）で作成してください。このトークンで@claudeメンションのコメントを投稿します。

Step 2GitHub Secretsの設定

対象リポジトリの Settings → Secrets and variables → Actions を開く
「New repository secret」をクリック
Name: PAT_TOKEN、Value: Step1で取得したPATを入力
CLAUDE_CODE_OAUTH_TOKEN は /install-github-app で自動登録済みならスキップ

登録すべきSecrets

# 必須
PAT_TOKEN                  # @claudeメンション用（ワークフロー起動権限のあるアカウント）
CLAUDE_CODE_OAUTH_TOKEN    # Claude認証（/install-github-appで自動設定可）

# オプション（通知を使う場合）
SLACK_WEBHOOK_URL          # Slack Incoming Webhook URL

# オプション（AWS Bedrockを使う場合）
AWS_ACCESS_KEY_ID          # AWS認証
AWS_SECRET_ACCESS_KEY

Step 3ワークフローファイルの作成

.github/workflows/ ディレクトリに以下のファイルを作成します。まずは claude.yml だけ作成し、動作確認してから他のワークフローを追加することをおすすめします。

ファイル名	優先度	説明
`claude.yml`	必須	@claudeメンション対応（基本）
`claude-implementer.yml`	推奨	定期実装タスク
`claude-reviewer.yml`	推奨	PRレビュー・マージ
`claude-issue-decomposer.yml`	任意	Issue分解
`claude-issue-creator.yml`	任意	Issue自動作成

Step 4タスクテンプレートの作成

.github/templates/ ディレクトリにタスクテンプレートを作成します。ワークフローから --body-file で参照されます。

implementation-task.md

実装タスク用。優先度の高いIssueを選んで実装し、PRを作成する手順を記述。

issue-decomposition-task.md

Issue分解用。大きなIssueをatomicに分解する判定基準と手順を記述。

review-task.md

レビュー用。PRのコードレビュー観点とマージ判定基準を記述。

issue-creation-task.md

Issue作成用。マージ済みPRを分析してバグ・改善提案を作成する手順を記述。

Step 5ラベルのセットアップ

自動化で使用するラベルを事前に作成します。以下のスクリプトを実行するか、GitHub UIから手動で作成してください。

bash

# リポジトリのルートで実行
gh label create "automation" --color "1d76db" --description "自動化タスク" --force
gh label create "atomic" --color "c5def5" --description "最小単位Issue" --force
gh label create "parent" --color "d4c5f9" --description "親Issue" --force
gh label create "child" --color "bfdadc" --description "子Issue" --force
gh label create "priority:critical" --color "b60205" --description "最優先" --force
gh label create "priority:high" --color "d93f0b" --description "高優先度" --force
gh label create "priority:medium" --color "fbca04" --description "中優先度" --force

Step 6動作確認

Issueを1つ作成（タイトル: 「テスト: Hello World」など）
コメントで @claude こんにちは、テストです と入力
ActionsタブでClaudeワークフローが起動することを確認
Claudeからのレスポンスがコメントに投稿されることを確認

成功！これで基本的なセットアップは完了です。次は定期実行ワークフローを追加していきましょう。

セキュリティ: GitHub Secrets の設定

APIキーやトークンは絶対にワークフローファイルにハードコードしないでください。GitHub Secrets を使って安全に管理します。

ダメな例

yaml: 危険なコード

# 絶対にやらないで！
- uses: anthropics/claude-code-action@v1
with:
anthropic-api-key: "sk-ant-xxxxx"  # 漏洩リスク大
github-token: "ghp_xxxxx"  # 履歴に残る

正しい例

yaml: 安全なコード

# GitHub Secrets を使用（サブスク版）
- uses: anthropics/claude-code-action@v1
with:
claude-code-oauth-token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
github-token: ${{ secrets.PAT_TOKEN }}

GitHub Secrets の設定手順

01
リポジトリの Settings を開く
GitHub リポジトリページ → Settings → Secrets and variables → Actions
02
New repository secret をクリック
名前（例: PAT_TOKEN）と値を入力。CLAUDE_CODE_OAUTH_TOKEN は自動設定済み
03
ワークフローから参照
${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} の形式で参照できます

Secret名	用途	取得方法
`PAT_TOKEN`	@claudeメンション用。ワークフロー起動権限を持つアカウントから`@claude`メンションを行うために必要。 Issue/PR作成、コメント投稿、ブランチ操作などに使用。	GitHub Settings
`CLAUDE_CODE_OAUTH_TOKEN`	Claude Code Action認証用。Claude Code CLIで`/install-github-app`コマンドを実行すると、 `claude.yml`とこのトークンが自動でセットアップされる。	Claude Code CLI `/install-github-app`
`SLACK_WEBHOOK_URL`	通知用（任意）。Slackなどのチャットツールに通知を送る場合に設定。設定しなくても自動化は動作する。	Slack API

簡単セットアップ: Claude Code CLI を使う

Claude Code CLI の /install-github-app コマンドを使うと、以下が自動でセットアップされます：

CLAUDE_CODE_OAUTH_TOKEN がGitHub Secretsに自動登録
.github/workflows/claude.yml が自動生成

注意: 自動生成された claude.yml は基本設定のみです。本記事で解説している定期実行（cron）や allowed_tools のカスタマイズ、タスクテンプレートの参照などは手動で追加してください。

GitHub Secrets 公式ドキュメント

AIへの指示のコツ: 実践テクニック

AIに自動で仕事を任せる際の、実践的なテクニックを紹介します。これらは実際に運用してみて得られた経験則です。

テクニック1: 指示は100行以内に収める

指示の文章量が多すぎたり、やらせることが多すぎると、AIは混乱し、記載した内容を守れないことが増えます。 テンプレートは日本語で100行程度に収めることを心がけてください。（Claude Sonnet 4.5時点での経験則）

それ以上になるようなら、別のワークフローに分割するのがおすすめです。「Issue作成」「Issue分解」「実装」「レビュー」のように、タスクを分けて定義しましょう。

テクニック2: 分岐ロジックはスクリプトに逃がす

「○○の場合は△△、□□の場合は☆☆」のような条件分岐が多いと、テンプレートの文章量が肥大化します。

Pythonスクリプトを実行させる指示だけを書いて、分岐はスクリプト内でブラックボックス的に行うのが効果的です。スクリプトの出力（AIに読ませる部分）だけを限定させることで、AIの理解を助けます。

テクニック3: 禁止事項を明確に書く

AIは「分析して報告しました」「推奨事項をまとめました」で終わりがちです。 「分析だけで終わらない」「推奨文で終わらない」「コマンドを実行しない、は禁止」と明記しましょう。

また、「最低2つのIssueを必ず作成」のように、具体的な数値で完了条件を示すと確実性が上がります。

Pythonスクリプト活用例

優先度に基づくIssue選択ロジックをスクリプト化した例です。条件分岐をスクリプト内に隠蔽し、AIには結果だけを渡します。

メリット: テンプレートがシンプルになり、ロジックの変更も容易になります。

scripts/select_priority_issue.py

#!/usr/bin/env python3
import subprocess
import json

def get_issues(labels):
"""指定ラベルのIssueを取得"""
cmd = f'gh issue list --label "{labels}" --state open --json number,title'
result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
return json.loads(result.stdout) if result.stdout else []

# 優先度順に検索（ブラックボックス化）
priority_order = [
"priority:critical",
"bug,priority:high",
"priority:high",
"priority:medium"
]

for priority in priority_order:
issues = get_issues(priority)
if issues:
# AIに渡す出力を限定
print(f"選択されたIssue: #{issues[0]['number']}")
print(f"タイトル: {issues[0]['title']}")
break
else:
print("対象Issueがありません")

ポリシー違反とレート制限に注意

自動化を進める前に、Anthropicの利用規約とレート制限を理解しておきましょう。「やりすぎ」は禁物です。

これはダメ！ポリシー違反になりうる行為

24時間365日の継続実行: バックグラウンドでClaudeを「常時稼働」させることはポリシー違反の可能性があります
アカウント共有・再販: 複数人で1つのAPIキーを共有したり、Claude Codeへのアクセスを再販することは禁止されています
過度な自動化: 人間の監視なしに完全自動で大量のコードを生成・デプロイすることは避けましょう

レート制限について（2025年8月〜）

Anthropicは2025年8月から、Claude Codeの「パワーユーザー」を抑制するため、新しいレート制限を導入しました。

プラン	週あたりの目安
Pro ($20/月)	Sonnet 4: 40〜80時間
Max ($100/月)	Sonnet 4: 140〜280時間 / Opus 4: 15〜35時間
Max ($200/月)	Sonnet 4: 240〜480時間 / Opus 4: 24〜40時間

※ 使用量はコードベースのサイズやタスクの複雑さによって異なります。定期実行の頻度は、このレート制限を考慮して設定してください。

推奨される運用方法

1日3〜4回の定期実行: 9:00, 15:00, 21:00 JST など、適度な間隔を空ける
人間による監視: 完全放置ではなく、定期的にPRやIssueを確認する
段階的な導入: 最初は1つのワークフローから始め、徐々に拡張する

Claude API Rate Limits | Usage Policy

オプション: Slack通知を設定する

自動化タスクの完了や失敗をSlackに通知することで、開発状況をリアルタイムに把握できます。 Incoming Webhookを使った通知の設定方法を解説します。

Slack Incoming Webhook の設定手順

Slack Appを作成
Slack API にアクセスし、「Create New App」→「From scratch」を選択
Incoming Webhooksを有効化
左メニュー「Incoming Webhooks」→「Activate Incoming Webhooks」をONに
Webhook URLを取得
「Add New Webhook to Workspace」→通知先チャンネルを選択→表示されたURLをコピー
GitHub Secretsに登録
SLACK_WEBHOOK_URL として登録

通知ワークフローの追加

既存のワークフローに通知ステップを追加するか、専用の通知ワークフローを作成します。 curl を使ってWebhook URLにJSONをPOSTします。

成功時: タスク完了、Issue/PRリンク
失敗時: エラー内容、失敗したジョブ
定期レポート: 1日のサマリーなど

slack-notify ステップ

      - name: Notify Slack
if: always()  # 成功・失敗に関わらず実行
env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
run: |
    STATUS="${{ job.status }}"
    COLOR=$([ "$STATUS" = "success" ] && echo "good" || echo "danger")

    curl -X POST -H 'Content-type: application/json' \
    --data "{
        \"attachments\": [{
        \"color\": \"$COLOR\",
        \"title\": \"Claude 自動化タスク: $STATUS\",
        \"fields\": [
            {\"title\": \"Repository\", \"value\": \"${{ github.repository }}\", \"short\": true},
            {\"title\": \"Workflow\", \"value\": \"${{ github.workflow }}\", \"short\": true}
        ],
        \"footer\": \"GitHub Actions\"
        }]
    }" $SLACK_WEBHOOK_URL

通知内容のカスタマイズ例

Issue作成時

新規Issue番号、タイトル、優先度ラベル

PR Ready時

PR番号、関連Issue、変更ファイル数

マージ完了時

マージ先ブランチ、コミット数

トラブルシューティング

自動化を運用していると、様々な問題に遭遇することがあります。よくある問題とその解決方法をまとめました。

問題: ワークフローが起動しない

考えられる原因

ワークフローファイルの構文エラー
トリガー条件（on:）の設定ミス
パブリックリポジトリで60日間アクティビティなし
@claude のスペルミス

解決方法

Actions タブでエラーログを確認
workflow_dispatch で手動実行してテスト
YAMLの構文をオンラインバリデータで検証
リポジトリに何かコミットしてアクティビティを発生

問題: Claudeが分析・推奨だけで終わる

考えられる原因

テンプレートに禁止事項が書かれていない
指示が曖昧で、何をすべきか不明確
テンプレートの文章量が多すぎる
タイムアウトで途中終了

解決方法

「分析だけで終わらない」「推奨文で終わらない」を明記
具体的な完了条件を数値で示す
テンプレートを100行以内に簡潔化
timeout_minutes を増やす（最大120）

問題: 権限エラー（Permission denied）

考えられる原因

PAT_TOKEN の権限が不足
ワークフローの permissions 設定不足
ブランチ保護ルールに引っかかっている
Secretsが正しく設定されていない

解決方法

PATに必要な権限を追加（Contents, Issues, PRs）
permissions: ブロックを追加
ブランチ保護ルールを確認・調整
Secrets の名前と値を再確認

問題: スケジュール実行が遅延・スキップされる

考えられる原因

GitHub Actions の高負荷時間帯（毎時0分）
ランナーのキューイング遅延
リポジトリの非アクティブ化（60日ルール）

解決方法

cron を 15分/45分など混雑を避ける時間に設定
重要なタスクは workflow_dispatch も併用
定期的にリポジトリにコミットを作成

デバッグのコツ: Actions タブの実行ログを確認し、どのステップで失敗しているかを特定しましょう。echo や set -x で変数の値を出力すると原因特定が早くなります。

コスト: サブスクリプション内で完結

この手法はClaude Maxプラン（$200/月）のサブスクリプション内で完結させることを想定しています。 API従量課金ではないため、使用量を気にせず運用できます。

Claude サブスクリプション

プラン	月額	週あたり目安
Pro	$20	Sonnet 4: 40〜80時間
Max	$100	Sonnet 4: 140〜280時間
Max	$200	Sonnet 4: 240〜480時間

推奨: $200/月 Maxプラン。定期実行でも余裕をもって運用可能。

GitHub Actions（追加コスト）

プラン	無料枠	超過料金
Free	2,000分/月	-
Pro	3,000分/月	$0.008/分

目安: 1日数回の定期実行なら無料枠内で収まることが多い。

結論: 月額 $200 で完結

この自動化手法はClaude Max $200/月プランのサブスクリプション料金だけで運用可能です。 API従量課金のように「使いすぎて請求が跳ね上がる」心配がありません。

Claude Max

月額固定

$200/月

GitHub Actions

多くの場合

無料枠内

合計

予測可能なコスト

約 $200/月

※ API従量課金で運用する場合は別途コスト計算が必要です。

補足: ラベルの自動セットアップ

この自動化では、優先度や状態を表すラベルが重要な役割を果たします。初期セットアップ用のスクリプトを用意しておくと便利です。

推奨ラベル一覧

以下のラベルを事前に作成しておくことで、自動化がスムーズに動作します。

自動化: automation, implementation, review
粒度: atomic, parent, child
優先度: priority:critical/high/medium/low
種別: bug, enhancement

scripts/setup-labels.sh

#!/bin/bash
# ラベル一括作成スクリプト

# 自動化関連
gh label create "automation" --color "1d76db" --description "自動化タスク"
gh label create "implementation" --color "0e8a16" --description "実装タスク"
gh label create "review" --color "fbca04" --description "レビュータスク"

# Issue粒度管理
gh label create "atomic" --color "c5def5" --description "最小単位Issue"
gh label create "parent" --color "d4c5f9" --description "親Issue"
gh label create "child" --color "bfdadc" --description "子Issue"

# 優先度
gh label create "priority:critical" --color "b60205" --description "最優先"
gh label create "priority:high" --color "d93f0b" --description "高優先度"
gh label create "priority:medium" --color "fbca04" --description "中優先度"
gh label create "priority:low" --color "0e8a16" --description "低優先度"

echo "ラベルのセットアップが完了しました"

よくある質問 (FAQ)

2025年7月のアップデートで、Claude Code GitHub ActionsはMAX Subscriptionでも使えるようになりました。従量課金のAPI、AWS Bedrock、Google Vertex AIに加えて、月額サブスクリプションでも利用可能です。

GitHub Actions の schedule イベントは、高負荷時に遅延することがあります。特に毎時0分は混雑しやすいため、15分や45分など、少しずらした時間を指定することをおすすめします。また、パブリックリポジトリで60日間アクティビティがないと、スケジュールが自動無効化されるのでご注意ください。

Claude Code Action はセキュリティを考慮して設計されていますが、外部からの入力には注意が必要です。HTMLコメントや見えないマークダウンを悪用した攻撃の可能性があるため、外部コントリビュータからのPRは事前に内容を確認することをおすすめします。また、allowed_non_write_users パラメータの使用は、極度に制限されたワークフローのみで行ってください。

まずは claude.yml（@claudeメンション対応）だけを設定して、手動でIssueを作って @claude と呼び出してみてください。動作確認ができたら、claude-implementer.yml など定期実行ワークフローを1つずつ追加していくのがおすすめです。

はい、テンプレートに「ユニットテストを必ず作成すること」「テストがパスすることを確認してからPRを作成すること」と明記すれば、テストコードも一緒に生成されます。ただし、既存のテストフレームワーク（Jest, pytest, JUnitなど）がセットアップされていることが前提です。

はい、プライベートリポジトリでも使用できます。ただし、GitHub Actions の実行時間がプライベートリポジトリでは課金対象になる点に注意してください（Free プランでも2,000分/月まで無料）。また、セキュリティの観点から、APIキーやトークンの管理には十分注意してください。

使えますが、注意点があります。チーム全員が同じAPIキーを共有することはAnthropicのポリシー上避けるべきです。Organization レベルでSecretsを設定し、適切なアクセス制御を行ってください。また、Claudeが作成したPRは人間がレビューしてからマージするワークフローを推奨します。

GitHubのブランチ保護ルールを設定することで防げます。main/masterブランチに「Require pull request reviews before merging」を設定すれば、直接プッシュは禁止されます。Claudeには常にfeatureブランチを作成してPRを作る指示をテンプレートに書いてください。

はい、Claude Code Action は AWS Bedrock と Google Vertex AI にも対応しています。anthropic-provider パラメータで bedrock または vertex を指定し、対応する認証情報をSecretsに設定してください。企業でのセキュリティ要件が厳しい場合は、これらのクラウドプロバイダー経由での利用が推奨されます。

Claude Sonnet 4 / Opus 4 の品質は高く、一般的なタスクであれば人間のジュニア〜ミドルエンジニアと同等以上のコードを生成できます。ただし、複雑なビジネスロジックやドメイン固有の知識が必要な場合は、人間のレビューが必須です。Issue を atomic（最小単位）に分解することで、品質を安定させやすくなります。

Column: 「完全自立」の落とし穴

「完全自立開発」と言うと、人間が何もしなくても勝手にアプリが完成するように聞こえますが、現実はそう甘くありません。

AIは優秀ですが、「何を作るべきか」「なぜそれが必要か」という価値判断は人間にしかできません。自動化の本当の価値は、「考える時間を増やす」ことにあります。ルーティンワークをAIに任せることで、人間はより創造的な仕事に集中できるようになります。

定期的にIssueやPRを確認し、方向性がずれていないかチェックすることを忘れないでください。 人間とAIのハイブリッドな開発スタイルこそが、最も生産的なアプローチだと筆者は考えています。

まとめ: 今日から始める自動化

GitHub Actions と Claude Code Action を組み合わせることで、Issue発行から実装・レビュー・マージまでの開発サイクルを自動化できます。最初に「何を作りたいか」を伝えるだけで、AIが勝手に開発を進めてくれる仕組みを、ぜひ試してみてください。

今日からできるアクション

Claude Code CLI で /install-github-app を実行
PAT_TOKEN を GitHub Secrets に登録
Issueを作成して @claude とメンション
動作確認ができたら、定期実行ワークフローを追加

サンプルリポジトリを見る

【GitHubActions × Claude】完全自立開発サイクルを実現する

karrinn

目次

この記事でわかること

あなたはこんなことで困っていませんか？

悩み1: 何をすべきかわからない

悩み2: もっと自動化したい

悩み3: 寝てる間に進めてほしい

この記事で実現できること

隠れた魅力: プロジェクトマネジメントの理解が深まる

Before / After: 従来の開発 vs 自動化開発

Before: 従来の開発フロー

After: 自動化開発フロー

補足: 完全自動化の意味

実は「部分導入」がおすすめ

この記事では「完全自動化」を紹介しますが...

完全自動化の落とし穴

部分導入のメリット

部分導入の具体例

この記事で出てくる専門用語

GitHub Actions

Claude Code Action

cron（クーロン）

GitHub Secrets

マイルストーン

atomic Issue

PAT (Personal Access Token)

allowed_tools

Draft PR

workflow_dispatch

Incoming Webhook

permissions（権限ブロック）

完全自立開発サイクルの全体像

自動化の流れ

実行されるタスク

ワークフロー間の連携サイクル

Issue作成フェーズ

分解・整理フェーズ

実装・レビューフェーズ

仕組みを理解する：3つの構成要素

構成要素1: 定期実行ワークフロー

設定のポイント

構成要素2: タスクテンプレート

テンプレートのポイント

テンプレート設計のベストプラクティス

具体的な手順を番号付きで

禁止事項は必須！

判断ロジックはスクリプトに

完了条件を明確に

構成要素3: Claude Code Action

設定のポイント

実践: 様々な自動化ワークフロー

Issue分解の仕組み

分解の判定基準

分解の具体例: ユーザー認証機能

ステップバイステップ: 初期セットアップ手順

Step 1認証情報の準備

方法A: Claude Code CLI を使う（推奨）

GitHub Personal Access Token（PAT）

Step 2GitHub Secretsの設定

Step 3ワークフローファイルの作成

Step 4タスクテンプレートの作成

Step 5ラベルのセットアップ

Step 6動作確認

セキュリティ: GitHub Secrets の設定

ダメな例

正しい例

GitHub Secrets の設定手順

簡単セットアップ: Claude Code CLI を使う

AIへの指示のコツ: 実践テクニック

テクニック1: 指示は100行以内に収める

テクニック2: 分岐ロジックはスクリプトに逃がす

テクニック3: 禁止事項を明確に書く

Pythonスクリプト活用例

ポリシー違反とレート制限に注意

これはダメ！ポリシー違反になりうる行為

レート制限について（2025年8月〜）

推奨される運用方法

オプション: Slack通知を設定する

Slack Incoming Webhook の設定手順