Claude Code×GitHub(gh CLI・API・Actions)【2026】Issueから実装・PR・CI修正までAIエージェントに任せる
Claude Codeに gh コマンドを使わせると、「Issueを読んで実装し、PRを作り、CIが落ちたらログを読んで直す」という開発のループをまるごと任せられます。ただし、便利さと引き換えに「AIがmainを書き換える」「強制pushで履歴が消える」といった事故の余地も生まれます。本記事では、任せる範囲(ユースケース)と、任せてはいけない範囲(安全設計)をセットで、gh CLI・GitHub API・GitHub Actions(claude-code-action)の実例とともに解説します。
- ローカルのClaude Codeは gh CLI 経由でGitHubを操作させるのが最短。Issue読解→実装→PR作成、
gh run view --log-failedでのCI修正が得意 - チームでは claude-code-action を入れると、IssueやPRで
@claudeとメンションするだけでGitHub上で動く - 安全設計の核は「AIは直接mainに入れない」。最小権限のトークン+permissionsのdeny+ブランチ保護(サーバー側)の三重で止め、マージは人が行う
Claude Code×GitHubで何ができるか(5つのユースケース)
Claude Codeはターミナルで動くコーディングエージェントです。ファイルを読み書きし、コマンドを実行できるので、GitHub公式のCLIである gh がインストール・認証済みなら、人がターミナルで行うGitHub操作はほぼすべて代行できます。現場で効果が大きいのは次の5つです。
| ユースケース | Claude Codeが使う主なコマンド | 人が担う部分 |
|---|---|---|
| ① Issueを読んで実装しPR作成 | gh issue view、git switch -c、テスト実行、gh pr create | Issueの意図・受け入れ条件を書く/差分のレビューとマージ |
| ② CI失敗ログを読んで修正 | gh pr checks、gh run view --log-failed | 「テストを消して通す」ような修正でないかの確認 |
| ③ PRレビューの一次チェック | gh pr diff、gh pr view --json files | 設計判断・仕様の妥当性など、最終レビュー |
| ④ 古いIssueの棚卸し | gh issue list --search "updated:<…" + --json | クローズするかどうかの判断 |
| ⑤ リリースノート下書き | gh pr list --state merged、git log、gh release create --draft | 文面の確認と公開(publish) |
ポイントは、どのユースケースも「読む・まとめる・下書きする」はAI、「決める・取り込む・公開する」は人という線引きになっていることです。コードを書く作業そのものより、Issueやログといった大量のテキストを読んで要点をつかむ作業でAIの効果が大きいのが、GitHub連携の特徴です。


準備と認証:gh auth と fine-grained PAT で最小権限に
gh CLIのインストールとログイン
まず gh をインストールし、ログインします。対話式の gh auth login はブラウザ認証(OAuth)で手軽ですが、付与されるスコープが広めになりがちです。AIエージェントに使わせる前提なら、権限を絞ったトークンで認証する方が安全です。
# インストール(macOS の例。Linux/Windows は公式手順を参照)
brew install gh
# ① 手軽な方法:ブラウザでログイン
gh auth login
# ② 推奨:権限を絞った fine-grained PAT で認証(トークンは標準入力から渡す)
gh auth login --with-token < ~/.secrets/gh-agent-token.txt
# 認証状態とアカウント・スコープを確認
gh auth status環境変数 GH_TOKEN にトークンを入れても gh はそれを使います。CIやコンテナで使う場合はこちらが扱いやすいでしょう。ただしシェルの履歴やログにトークンを残さないよう、ファイルやシークレット管理から読み込む形にします。
fine-grained PAT の権限設計
GitHubの fine-grained personal access token(細粒度PAT)は、対象リポジトリを個別に選び、権限を項目ごとに「なし/読み取り/読み書き」で指定できます。AIに渡すトークンの推奨例は次のとおりです(項目名は執筆時点・2026年9月のもの。最新はGitHub公式ドキュメントで確認してください)。
| 権限項目 | 設定 | 理由 |
|---|---|---|
| Repository access | 対象リポジトリのみ選択 | 「全リポジトリ」は避ける。事故の範囲を1リポジトリに閉じ込める |
| Contents | Read and write | 作業ブランチへのpushに必要 |
| Pull requests | Read and write | PRの作成・コメントに必要 |
| Issues | Read and write(棚卸しだけなら Read) | Issueの読解・コメント |
| Actions | Read-only | CIの実行結果・ログの取得 |
| Workflows | 付与しない | .github/workflows/ の変更をpushできなくなる。AIがCI設定そのものを書き換えるのを防ぐ |
| Administration / Secrets | 付与しない | ブランチ保護の解除やシークレットの操作をさせない |
「Workflows」を外すのは地味ですが効果的です。CIの設定ファイルを書き換えられると、テストを飛ばす・シークレットを外に出すといった変更がCI経由で実行されうるからです。CI設定の変更が必要なときは、人が自分の権限で行います。有効期限も短め(例:30〜90日)にして、定期的に作り直す運用にしておきましょう。
.env に置く場合は、必ず .gitignore に入れ、さらにClaude Codeの permissions.deny で Read(./.env) を指定してAIの読み取り対象からも外します。gh 自体はOSのキーチェーンや自身の設定ファイルに認証情報を保存するので、通常はリポジトリ内に置く必要はありません。
プロジェクト構成
GitHub連携のためにアプリ本体の構成を変える必要はありません。追加するのは、Claude Codeへの指示書(CLAUDE.md)・権限設定・定型作業のスクリプト・Actionsのワークフローです。
my-app/
├── CLAUDE.md # ブランチ命名・テスト・コミット規約など
├── .claude/
│ ├── settings.json # permissions(allow/ask/deny)と hooks
│ ├── hooks/
│ │ └── guard-git.sh # main への push 等を実行前にブロック
│ └── skills/
│ └── release-notes/SKILL.md # リリースノート下書きの手順
├── scripts/
│ ├── ci_failed_log.sh # 直近の失敗ログを取得
│ └── stale_issues.sh # 古いIssueを JSON で書き出す
├── reports/ # 棚卸しレポート等の出力先(.gitignore 済み)
├── .github/
│ ├── CODEOWNERS # 重要ディレクトリのレビュー担当
│ └── workflows/
│ └── claude.yml # claude-code-action
└── src/ …「毎回同じ手順になる操作」は scripts/ にシェルスクリプトとして固めておくのがコツです。AIに毎回コマンドを組み立てさせるより、結果が安定し、permissionsで「このスクリプトだけ許可」と書けるからです。
取得・操作のスクリプト実例
CI失敗ログを取得する
CIが落ちたとき、人がやる作業は「Actionsの画面を開く→失敗したジョブを探す→ログを展開して読む」です。gh run view --log-failed を使うと、失敗したステップのログだけを取り出せます。
#!/usr/bin/env bash
# 使い方: scripts/ci_failed_log.sh [ブランチ名](省略時は現在のブランチ)
set -euo pipefail
BRANCH="${1:-$(git branch --show-current)}"
mkdir -p tmp
# 対象ブランチで直近に失敗した実行のIDを取得
RUN_ID=$(gh run list --branch "$BRANCH" --status failure --limit 1 \
--json databaseId --jq '.[0].databaseId')
if [ -z "$RUN_ID" ] || [ "$RUN_ID" = "null" ]; then
echo "失敗した実行はありません: $BRANCH"
exit 0
fi
# 失敗したステップのログだけを保存(長大なログ全体は読ませない)
gh run view "$RUN_ID" --log-failed > tmp/ci_failed.log
echo "saved: tmp/ci_failed.log (run $RUN_ID, $(wc -l < tmp/ci_failed.log) lines)"ログをファイルに落としてから読ませるのは、コンテキスト(AIが一度に読める量)を節約するためです。数万行のログをそのまま標準出力に流すと、肝心のエラー箇所以外で容量を使ってしまいます。ファイルにしておけば、Claude Codeは Grep で「Error」「FAIL」などを検索し、必要な箇所だけ読みにいきます。
古いIssueを棚卸し用に書き出す
#!/usr/bin/env bash
# 90日以上更新のないオープンIssueを JSON で書き出す(GNU date 前提。macOS は gdate 等)
set -euo pipefail
CUTOFF=$(date -d '90 days ago' +%Y-%m-%d)
mkdir -p reports
gh issue list --state open --limit 300 \
--search "updated:<${CUTOFF}" \
--json number,title,labels,assignees,updatedAt,url \
> reports/stale_issues.json
echo "$(jq length reports/stale_issues.json) issues (updated before ${CUTOFF})"このスクリプトは読み取りしかしません。Claude Codeにはこの結果を読ませて「すでに解決済みと思われるもの」「情報不足で進められないもの」「今も有効なもの」に分類させ、クローズ候補の一覧をMarkdownで提案させます。実際にクローズするかは人が判断します。
GitHub API を直接叩く:gh api
gh にサブコマンドがない操作は、gh api でREST APIやGraphQLを直接呼べます。認証は gh のものがそのまま使われ、{owner}・{repo} は現在のリポジトリに自動で置き換わります。
# PRのレビューコメント一覧(読み取り)
gh api repos/{owner}/{repo}/pulls/45/comments --jq '.[] | {path, line, body}'
# 直近のリリースとタグ(読み取り)
gh api repos/{owner}/{repo}/releases --jq '.[0:3] | .[] | {tag_name, published_at}'
# 注意:-f / -F でフィールドを付けると既定のメソッドが POST になる(書き込み)
gh api repos/{owner}/{repo}/releases/generate-notes -f tag_name=v1.4.0最後の例のように、gh api は引数次第で書き込みにもなる点に注意してください。後述のpermissionsでは gh api を「毎回確認(ask)」に置き、削除メソッドは拒否(deny)にしています。
CLAUDE.mdの例:ブランチ命名・テスト・コミット規約
CLAUDE.md はプロジェクト直下に置くと、Claude Codeが起動のたびに読み込む「このリポジトリのルールブック」です(/init で雛形を生成できます)。GitHub連携では、ブランチの切り方・テストの回し方・コミットとPRの書き方を明文化しておくと、AIの作業が人のチームの流儀にそろいます。
# 開発ルール(AIエージェント向け)
## ブランチ
- main に直接コミット・push しない。必ず作業ブランチを切る
- 命名: feat/<issue番号>-<短い英語>、fix/<issue番号>-<短い英語>、chore/<内容>
例: feat/123-csv-export, fix/140-login-redirect
- 強制push(--force / -f)はしない。履歴を書き換えない
## テスト(PRを出す前に必ず全部通す)
- 単体テスト: npm test
- 型チェック: npm run typecheck
- Lint: npm run lint
- 失敗したテストを削除・skip して通すのは禁止。直せない場合は PR 本文にそう書く
## コミット規約
- Conventional Commits: feat: / fix: / docs: / refactor: / test: / chore:
- 1コミット1目的。件名は日本語可・72文字以内
- 本文に関連 Issue を書く(例: Refs #123)
## PR
- gh pr create --draft で作成する(レビュー準備ができたら人が Ready にする)
- 本文に「変更内容」「テスト結果」「確認してほしい点」「Closes #番号」を書く
- マージはしない。gh pr merge は使わない
## CIが落ちたとき
- scripts/ci_failed_log.sh でログを取得し、原因の仮説を先に説明してから修正する
- .github/workflows/ は変更しない(変更が必要なら提案だけする)「テストを消して通すのは禁止」「直せないなら正直に書く」という一文は、実務上とても重要です。AIは与えられたゴール(CIを緑にする)に素直なので、ゴールの達成方法に制約を書いておかないと、望まない近道を選ぶことがあります。
.claude/settings.json の permissions 例
CLAUDE.mdは「お願い」ですが、.claude/settings.json の permissions はツール実行の許可・確認・拒否を強制する設定です。allow(確認なしで実行)、ask(毎回確認)、deny(実行不可)の3段階で、deny が最優先されます。
{
"permissions": {
"allow": [
"Bash(gh issue view:*)",
"Bash(gh issue list:*)",
"Bash(gh pr view:*)",
"Bash(gh pr diff:*)",
"Bash(gh pr checks:*)",
"Bash(gh pr list:*)",
"Bash(gh run list:*)",
"Bash(gh run view:*)",
"Bash(gh pr create:*)",
"Bash(scripts/ci_failed_log.sh:*)",
"Bash(scripts/stale_issues.sh:*)",
"Bash(git status)",
"Bash(git diff:*)",
"Bash(git log:*)",
"Bash(git switch -c:*)",
"Bash(git add:*)",
"Bash(git commit:*)",
"Bash(npm test:*)",
"Bash(npm run lint:*)",
"Bash(npm run typecheck:*)"
],
"ask": [
"Bash(git push:*)",
"Bash(gh api:*)",
"Bash(gh pr comment:*)",
"Bash(gh pr review:*)",
"Bash(gh issue comment:*)",
"Bash(gh issue close:*)",
"Bash(gh release create:*)"
],
"deny": [
"Bash(git push --force:*)",
"Bash(git push -f:*)",
"Bash(git push origin main:*)",
"Bash(git reset --hard:*)",
"Bash(gh pr merge:*)",
"Bash(gh repo delete:*)",
"Bash(gh api -X DELETE:*)",
"Bash(gh secret:*)",
"Read(./.env)",
"Read(./.env.*)"
]
}
}この設定の判断基準(トレードオフ)
- 読み取り系(view / list / diff / checks)は allow:失敗しても何も壊れず、ここで毎回確認が出ると作業が止まるだけで安全性は上がりません
gh pr createは allow:PRは「提案」であり、作られてもmainは変わりません。CLAUDE.mdで--draftを指定させておけば、レビュー依頼の通知が飛び交うこともありませんgit pushは ask:リモートに出る最初の操作なので、一度だけ目を通します。慣れてきたら、作業ブランチへのpushはallowに移し、後述のhookでmainだけ止める運用も合理的です- コメント・レビュー・クローズは ask:他の人に通知が届く「外向きの発言」だからです。AIの下書きをそのまま投稿してよいかは、人が決めます
- マージ・強制push・削除は deny:取り返しがつかない、または履歴が消える操作です
git push origin +main や git push --force-with-lease、別名(alias)経由のように、書き方を変えれば照合をすり抜ける余地があります。だからこそ、次のhooksで中身を検査し、最終的にはGitHub側のブランチ保護で止める多層構造にします。
hooksで「mainへのpush」を中身で止める
Claude Codeの hooks は、ツール実行の前後などのイベントでシェルコマンドを走らせる仕組みです。PreToolUse のフックが exit code 2 で終了すると、その実行はブロックされ、標準エラーに書いた理由がClaudeに返されます。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guard-git.sh" }
]
}
]
}
}#!/usr/bin/env bash
# 標準入力で渡される JSON から、実行しようとしているコマンドを取り出す
CMD=$(jq -r '.tool_input.command // ""')
# git push を含まなければ何もしない
echo "$CMD" | grep -Eq 'git[[:space:]]+push' || exit 0
# 強制push(--force, --force-with-lease, -f, +refspec)を拒否
if echo "$CMD" | grep -Eq '(--force|[[:space:]]-f([[:space:]]|$)|[[:space:]]\+[^[:space:]]+)'; then
echo "強制pushは禁止です。通常のpushで作業ブランチに出してください。" >&2
exit 2
fi
# main / master への push を拒否(明示指定・HEAD:main 形式の両方)
if echo "$CMD" | grep -Eq '(^|[[:space:]:])(main|master)([[:space:]]|$)'; then
echo "main への直接pushは禁止です。作業ブランチを切ってPRを作成してください。" >&2
exit 2
fi
# 引数なしの git push でも、現在のブランチが main なら拒否
if [ "$(git branch --show-current)" = "main" ]; then
echo "現在 main ブランチにいます。git switch -c で作業ブランチを作ってください。" >&2
exit 2
fi
exit 0ブロックの理由がClaudeに返るので、AIは「では作業ブランチを切ります」と自分で軌道修正します。止めるだけでなく、正しい手順を返すのがhookのメッセージを書くときのコツです。
Claude Codeとの対話例
例1:Issueを読んで実装し、PRを作る
> Issue #123 を読んで実装して。受け入れ条件を満たしたら draft PR まで作って。
不明点があれば実装前に質問して。このとき、Claude Codeはおおむね次の順で動きます。
結果として、PR本文には「変更内容」「追加したテスト」「確認してほしい点(例:CSVの文字コードをUTF-8 BOM付きにした判断)」「Closes #123」が入った状態で届きます。「確認してほしい点」をAIに書かせるのは、レビュアーが見るべき場所を先に知れるので効果的です。
例2:CIが落ちたPRを直す
> PR #145 の CI が落ちてる。失敗ログを読んで、原因の仮説を3つ以内で説明してから直して。
テストを消したり skip したりするのは禁止。Claude Codeは gh pr checks 145 で失敗したジョブを特定し、scripts/ci_failed_log.sh でログを取得します。たとえば「ローカルでは通るが、CIのタイムゾーンがUTCのため日付境界のテストが失敗している」といった仮説を先に示し、同意を得てから修正→ローカルでテスト→pushします。再実行後は gh pr checks 145 --watch で結果を待つこともできます。


例3:PRレビューの一次チェック
> PR #150 を一次レビューして。観点は ①バグの可能性 ②テスト不足 ③セキュリティ(認証・入力検証・秘密情報)
④CLAUDE.md の規約違反。結果は reviews/pr-150.md に書いて、GitHub には投稿しないで。gh pr view 150 --json title,body,files と gh pr diff 150 で内容を読み、指摘を重要度付きでファイルに書き出します。投稿しない指示にしているのは、AIの指摘には誤検知も混ざるからです。人が取捨選択してから投稿(またはaskで承認して gh pr review --comment)する方が、レビューの信頼性が保てます。
GitHub Actions:claude-code-action で @claude を動かす
ローカルのClaude Codeは「自分の手元で使う」道具ですが、Anthropicが公開している anthropics/claude-code-action を使うと、GitHubのIssueやPRのコメントで @claude とメンションするだけで、Actionsのランナー上でClaude Codeが動くようになります。チームの誰でも、ターミナルを開かずに依頼できるのが利点です。
セットアップ
いちばん簡単なのは、ローカルのClaude Codeで /install-github-app を実行する方法です。案内に沿って、GitHub Appのインストール、リポジトリのシークレット(APIキー)の登録、ワークフローファイルの追加を進められます(リポジトリの管理者権限が必要です)。手動で設定する場合は、リポジトリの Settings → Secrets and variables → Actions に ANTHROPIC_API_KEY を登録し、次のようなワークフローを置きます。
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
issues:
types: [opened, assigned]
jobs:
claude:
# @claude を含むコメント・Issueのときだけ起動(無駄な実行と課金を防ぐ)
if: |
contains(github.event.comment.body, '@claude') ||
contains(github.event.issue.body, '@claude')
runs-on: ubuntu-latest
timeout-minutes: 30
permissions:
contents: write
pull-requests: write
issues: write
id-token: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
# 追加の CLI 引数(ターン数の上限など)を渡せる
claude_args: "--max-turns 15"APIキーは必ずsecretsに入れ、YAMLに直書きしないでください。アクションの入力名や推奨設定(Amazon Bedrock・Google Cloud Vertex AI経由の認証など)はバージョンで変わるため、執筆時点(2026年9月)の概略として、導入時は公式のREADMEで確認してください。
どう使うか
- Issueで:「@claude このIssueを実装してPRを作って」→ ブランチを作って実装し、PR作成用のリンクやPRを返す
- PRのコメントで:「@claude CIの失敗を直して」「@claude この関数のエッジケースのテストを足して」→ そのPRのブランチにコミット
- レビューで:「@claude このPRをセキュリティの観点でレビューして」→ コメントで指摘を返す
- ローカルのClaude Code:対話しながら方針を詰める実装、手元の環境(DB・ブラウザ)での動作確認が必要な作業
- claude-code-action:小さな修正・テスト追加・CI修正など、Issueに書けば完結する作業。レビュー中の「ついで修正」
permissions を最小にする、といった対策を公式ドキュメントのセキュリティ項目で確認しましょう。
GitHub公式MCPサーバーを使う場合
GitHubは、AIツールからIssue・PR・Actionsなどを操作するための公式MCPサーバーを公開しています(執筆時点)。ローカルで動かす形式と、GitHubがホストするリモート形式があり、Claude Codeには claude mcp add で登録できます。登録方法・URL・認証方式は更新されることがあるため、GitHubの公式リポジトリの手順に従ってください。
# リモートのMCPサーバーを登録する一般形(URL・ヘッダーは公式手順のものを使う)
claude mcp add --transport http github <公式のMCPサーバーURL>
# チームで共有するなら --scope project(.mcp.json に保存される。トークンは書かない)
claude mcp add --scope project --transport http github <公式のMCPサーバーURL>
# Claude Code 内で接続状況を確認
/mcpgh CLIとMCPのどちらを使うかの判断基準は次のとおりです。
| 観点 | gh CLI | GitHub MCPサーバー |
|---|---|---|
| 導入の手間 | ghを入れて認証するだけ | MCP登録+認証設定 |
| 権限の絞り方 | permissionsでコマンド単位に allow/deny | MCPツール単位で許可、サーバー側で有効にするツール群を選べる(執筆時点) |
| 向いている環境 | シェルが使えるClaude Code | シェルのないAIクライアント、複数ツールで共通化したい場合 |
| 人が再現できるか | 同じコマンドを人も打てる。手順書にしやすい | ツール呼び出しの記録を見る必要がある |
当編集部では、Claude Codeで完結する作業はgh CLIを第一選択にしています。AIが実行したコマンドをそのまま人が再実行・検証でき、permissionsの書き方もシンプルだからです。
Skills・ヘッドレス定期実行
リリースノート下書きを Skill にする
毎回同じ手順の作業は、.claude/skills/<name>/SKILL.md にまとめておくと、Claude Codeが必要なときに読み込んで手順どおりに実行します。
---
name: release-notes
description: 前回のリリースタグ以降にマージされたPRからリリースノートの下書きを作る。リリース準備・リリースノート作成を頼まれたときに使う。
---
# リリースノート下書きの手順
1. 前回タグを取得: git describe --tags --abbrev=0
2. マージ済みPRを取得:
gh pr list --state merged --base main --limit 200 \
--search "merged:>=<前回タグの日付>" --json number,title,labels,author,url
3. ラベルで分類: 新機能(feature) / 改善(enhancement) / 不具合修正(bug) / その他
4. 利用者向けの言葉に書き換える(内部のリファクタリングは「その他」にまとめる)
5. 破壊的変更(breaking ラベル)は先頭に「⚠️ 移行が必要な変更」として書く
6. RELEASE_NOTES.md に保存し、次のコマンドを提案する(実行は人の確認後):
gh release create <新タグ> --draft --notes-file RELEASE_NOTES.md--draft で作れば、公開(publish)は人がGitHubの画面で内容を確認してから押す形になります。
週次のIssue棚卸しをヘッドレスで回す
Claude Codeは claude -p "プロンプト" で非対話(ヘッドレス)実行でき、--allowedTools で使えるツールを限定できます。これをGitHub Actionsのスケジュール実行と組み合わせると、毎週月曜に棚卸しレポートをIssueとして起票するといった運用が作れます。
claude -p "scripts/stale_issues.sh を実行し、reports/stale_issues.json を読んで、
クローズ候補・要追加情報・継続の3分類で reports/stale_issues.md にまとめて。
Issueのクローズやコメントはしないこと。" \
--allowedTools "Bash(scripts/stale_issues.sh:*),Read,Write" \
--output-format jsonActionsで回す場合は、on: schedule(cron)で起動するワークフローに claude-code-action を置き、prompt 入力で上記と同じ指示を渡す形が基本です(入力名は公式READMEで確認してください)。出力先を「Issueを1件起票する」に限定し、既存Issueのクローズ権限は与えないのが安全です。
安全設計:AIは直接mainに入れない
ここまでの設定を、「どこで止めるか」の観点で整理すると次の3層になります。
①②はAIの手元での対策なので、設定ミスや想定外のコマンドの書き方ですり抜ける可能性があります。③のGitHub側の設定は、誰がどんな方法でpushしても効くため、ここを必ず設定します。mainブランチに対して、リポジトリの Settings → Rules(ルールセット)またはブランチ保護ルールで、次を有効にします。
- マージ前にプルリクエストを必須にする(mainへの直接pushを禁止)
- 必須の承認数(例:1)と、新しいコミットがpushされたら古い承認を無効にする設定
- 必須ステータスチェック(テスト・Lint・型チェックのCIジョブ)
- 強制pushの禁止・ブランチ削除の禁止
- 重要ディレクトリには CODEOWNERS を設定し、そのオーナーのレビューを必須にする
一人開発・小規模チームでの落とし穴
GitHubではPRの作成者は自分のPRを承認できません。自分のトークンでClaude CodeにPRを作らせると、PRの作成者は「あなた」になるため、承認必須を1人にすると一人開発では詰まります。選択肢は次のとおりです。
| 構成 | メリット | デメリット |
|---|---|---|
| PR必須+必須チェック+強制push禁止(承認数0) | 設定が簡単。一人でも回る | レビューは自分の規律次第 |
| AI用に別アカウント(マシンユーザー)を用意 | AIのPRを自分が承認できる。履歴で区別できる | アカウント管理の手間。規約・料金面の確認が必要 |
| claude-code-action(GitHub App名義)でPR作成 | 自分が承認者になれる。チームでも自然 | Actionsの実行時間とAPI利用料がかかる |
どの構成でも、「マージのボタンを押すのは人」という一点は崩さないでください。他社の動きを見ても、GitHub自身が2025年に、Issueを割り当てるとAIがPRを作成する「Copilot coding agent」を発表した際、AIが作ったPRは人のレビュー・承認を経て取り込む前提の設計だと説明していました。コーディングエージェントの業界標準は「AIが提案し、人がレビューして取り込む」形に収れんしつつあります。

自社事例:本サイトのPR運用
AIエージェント研究所は「AIが作業ブランチで変更→PR→人が確認してマージ」
本サイトはHTMLとCSSだけの静的サイトで、GitHubでGit管理し、Cloudflare Pagesで配信しています。運用の流れは次のとおりです。
- コミットの大半はAIエージェント(Claude Code)との共同作業です。コミットメッセージには
Co-Authored-By: Claudeが付き、履歴から「AIと一緒に行った変更」が分かります - 記事追加・デザイン変更・内部リンクのメンテナンス(週次)などは、AIが作業ブランチで変更→PRを作成→人が差分を確認してマージという流れで行っています
- 公開前の機械チェックとして、共通フッター(広告表記を含む)を全ページに流し込み、入らないページがあれば
exit 1で止まるbuild.jsと、景表法まわりの表記を検査するkeihyo-check.jsを用意しています
「AIに書かせる」ことより、「AIの変更をPRという単位でレビューでき、問題があれば機械で止まり、いつでも戻せる」ことを先に整えるのが、私たちがいちばん重視している点です。詳しい仕組みは【自社事例】AIエージェントでメディアサイトを運用する仕組みで公開しています。
よくある質問
gh CLIとGitHub公式MCPサーバー、どちらを使うべき?
ローカルでClaude Codeを使うなら、まずはgh CLIがおすすめです。Claude Codeはシェルコマンドを使いこなせるため追加設定がほぼ不要で、permissionsでコマンド単位に許可・拒否を書けます。MCPサーバーは、ツールとして構造化された操作を渡したい場合や、シェルを持たない環境・複数のAIツールから同じ仕組みを使いたい場合に向いています。
一人開発で「必須レビュー」を設定すると、自分のPRをマージできなくならない?
なります。GitHubではPRの作成者は自分のPRを承認できないため、自分のトークンでClaude CodeにPRを作らせ、承認必須を1人に設定すると詰まります。一人開発では「PR必須+必須ステータスチェック+強制push禁止」を土台にして自分で差分を確認するか、claude-code-actionのようにGitHub App名義でPRを作らせ、自分が承認者になる構成が現実的です。
claude-code-actionの利用料金はどうなる?
GitHub Actionsの実行時間(ランナー料金)と、Claude側の利用料(APIキーの従量課金など、認証方式による)がかかります。@claudeへのメンションが増えるほど両方が増えるため、トリガー条件を絞り、最大ターン数などの上限を設定しておくのが安全です。料金体系は変わるため、執筆時点(2026年9月)の情報として公式ドキュメントで必ず確認してください。
AIが作ったPRは、どこまで人が確認すべき?
少なくとも、差分全体・テスト結果・変更がIssueの意図に合っているかは人が確認します。特に認証・権限・課金・データ削除・CI設定(.github/workflows)に触れる変更は、行単位で読むべき領域です。CODEOWNERSで重要ディレクトリのレビュー担当を固定しておくと、見落としを防げます。
まとめ|「提案はAI、取り込みは人」を仕組みで固定する
Claude Codeとgh CLIを組み合わせると、Issueの読解から実装・PR作成、CI失敗ログの解析と修正、PRの一次レビュー、Issueの棚卸し、リリースノートの下書きまで、GitHub上の定型作業の多くをAIエージェントに任せられます。チームで使うならclaude-code-actionで @claude を呼べるようにすると、依頼のハードルがさらに下がります。
そのうえで重要なのは、最小権限のトークン、permissionsとhooks、そしてGitHub側のブランチ保護という三重の仕組みで、「AIは直接mainに入れない」を人の注意力ではなく設定で担保することです。まずは読み取り系のコマンドだけを許可した状態でCI失敗ログの解析から始め、慣れてきたらPR作成まで範囲を広げていくのがおすすめです。クラウド側のログ調査やデプロイまでつなげたい方は、相方の記事Claude Code×クラウドCLI(AWS・Cloudflare・Vercel)へどうぞ。
AIエージェント開発のスキルを、キャリアにつなげる
LLM APIでエージェントを実装できるエンジニアは、転職・独立どちらでも需要が高い領域です。
- AIで独立するには?未経験から案件を取る6ステップ【2026】:自動化・開発スキルを案件にする。フリーランスエージェントの選び方も
- 仕事用キーボード・マウスおすすめ3選【2026】:長時間のコーディング・プロンプト入力を快適に