結論：最初は一つの非本番repoで、PR作成前の人間確認を残す

先に答えると、Claude CodeとGitHubの連携は、Appを入れて@claudeを使えるようにするだけでは完了しません。2026年8月3日の公式文書では、Claude Code GitHub ActionsはIssueやPRのメンションからコード分析、変更、branch作成などを実行できます。便利な一方、GitHub AppはContents、Issues、Pull requestsの読み書き権限を求めます。対象repo、起動者、Secrets、workflow権限、レビュー、停止条件を先に絞ります。

読者の具体的な困りごとは、自動化を入れた後で、外部コメントから誰が起動できるか、どの秘密情報へ届くか、失敗した変更を誰が止めるか分からないことです。読了後は、連携方式と最小権限を選び、安全な試験workflowを作れます。次の行動は、候補repoについて「Claudeに許可する操作」と「必ず人が行う操作」を二列で書くことです。

連携で動く三つの要素

一つ目はClaude GitHub Appです。repoの内容、Issue、PRへアクセスし、短時間のrepo限定tokenで操作します。二つ目はGitHub Actions workflowで、どのイベントで実行し、どの権限、時間、同時実行数、モデル、ツールを使うかを定義します。三つ目はAnthropic API keyまたはOAuth tokenなどの認証で、GitHub Secretsへ保存します。

公式のquick setupはClaude Codeで/install-github-appを実行し、App、workflow、secretの設定を案内します。repo admin権限が必要で、直接Claude APIを使う場合の手順です。Amazon BedrockやGoogle Cloudの基盤を使う企業は、OIDC、IAMまたはWorkload Identity、独自GitHub Appなど別の前提を確認します。

手動設定ではClaude GitHub Appを対象repoへ入れ、ANTHROPIC_API_KEYをrepository secretへ追加し、公式例を基に.github/workflows/へworkflowを置きます。API keyやOAuth tokenをYAML、Issue、ログ、CLAUDE.mdへ直接書きません。設定後は本番repoへ広げず、専用の小さなIssueで動作を確認します。

導入前に決める6つの比較軸

  1. 対象：全repoではなく、試験する一つのrepoとbranchを決めます。
  2. 起動者：write権限を持つ誰が、どのイベントで起動できるかを決めます。
  3. 操作：閲覧、コメント、branch作成、commit、PR作成、mergeを分けます。
  4. 秘密：利用するSecrets、環境、クラウド権限を最小化します。
  5. 検証：test、lint、security review、変更範囲の合格条件を決めます。
  6. 停止：費用、時間、失敗、漏えい疑い時にworkflowを止める担当を置きます。

特にallowed_non_write_usersでwrite権限のない利用者を許す設定は、公式Security文書が重大なリスクと明記しています。公開repoでは、外部入力に隠れた指示が含まれる可能性があります。必要がなければ有効にせず、botの許可もワイルドカードではなく明示リストへします。

Claude Code GitHub Actionsを導入する8手順

  1. 非本番または影響の小さいrepoを一つ選び、ownerと停止担当を決めます。
  2. Issueからbranch作成までなど、最初に許可する一つの用途を定義します。
  3. repo adminがAppを対象repoだけへ導入し、要求権限を記録します。
  4. 認証情報をGitHub Secretsへ保存し、workflowへ値を直書きしません。
  5. workflowのpermissions:、trigger、timeout、concurrency、max turnsを絞ります。
  6. repo rootのCLAUDE.mdへ、test、変更禁止領域、レビュー基準を短く書きます。
  7. 安全なIssueで@claudeを試し、commit、ログ、費用、失敗時挙動を確認します。
  8. branch protectionと必須checksを通し、人間が差分確認してからPR作成・mergeします。

標準のメンション利用では、Claudeは変更を新しいbranchへcommitし、PR作成ページへのリンクを返します。人がリンクを開いてPRを作る設計は、意図せぬ変更を提案段階で確認できる重要な境界です。独自workflowで自動PRや自動mergeを追加する場合は、通常より広い権限として別の承認を行います。

workflowを安全にする具体策

triggerは必要なイベントだけにし、公開repoの任意コメントを無条件に処理しません。pull_request_targetやworkflow_runはbase repoのSecretsで動くため、信頼できないPR headをworkspace rootへcheckoutしてからClaudeを実行しないようにします。必要ならbase refをrootに置き、PR headを別directoryへcheckoutして参照範囲を明示します。

workflowの権限は、コメントだけならIssues、変更が必要ならContentsなど用途別に絞ります。show_full_outputは既定で無効です。これを有効にすると、tool出力、ファイル、API応答などがActions logへ出る可能性があり、公開repoでは特に危険です。debugが必要でも、非本番のprivate repo、秘密情報なし、短時間に限定します。

費用対策では、具体的な依頼、--max-turns、workflow timeout、concurrency制御を使います。GitHub Actions minutesとClaude API tokenの両方を計測し、失敗時の再試行回数を制限します。安定後も毎月、不要trigger、使われないSecrets、古いaction version、権限拡大を棚卸しします。

betaからv1へ移行する場合

公式文書ではv1.0にbreaking changesがあります。actionを@betaから@v1へ変えるだけでなく、modeの削除、direct_promptからpromptへの変更、modelやmax_turnsなどをclaude_argsへ移す必要があります。既存workflowの差分を確認し、同じ権限と停止条件が維持されているかをテストします。

actionのversionを@mainへ固定すると、予告なく挙動が変わる範囲が広がります。社内運用では採用version、更新日、変更点、rollback方法を台帳へ残し、更新PRも通常のcode review対象にします。

公開・本番前チェックリスト

対象repoを限定したか／起動者をwrite権限者へ絞ったか／App権限を記録したか／Secretsへ保存したか／YAMLへ値がないか／workflow permissionsを最小にしたか／外部PR headを危険な権限で実行しないか／CLAUDE.mdが短く検証可能か／testとbranch protectionがあるか／自動mergeを許可していないか／費用とtimeout上限があるか／停止担当がいるか、を確認します。

よくある質問

GitHub Copilotとの連携ですか？

この記事はClaude Code GitHub Actionsについてです。GitHub Copilotとは別製品で、契約、権限、workflowを別に確認します。

public repoでも使えますか？

利用できますが、外部入力、hidden prompt、ログ公開、bot、非write利用者の起動リスクが増えます。最小権限と入力者制限を強くします。

API keyなしで使えますか？

契約経路で異なります。直接APIではsecretが必要で、BedrockやGoogle CloudではOIDCやcloud権限など公式の別手順を使います。

関連ガイドと公式情報

端末導入はClaude Codeのインストール、ローカル権限はClaude Codeの権限設定、ログ設計はClaude Codeの監査ログ、費用上限はClaude Codeのコスト管理も参照してください。

導入条件とv1設定はAnthropic公式Claude Code GitHub Actions、Claude Code全体の権限と実行境界は公式Security、action固有のprompt injection・Secrets・full outputの注意はAnthropic公式action Security、action本体は公式GitHub repositoryで公開直前に確認してください。

Miraigentの無料診断では、repo、起動者、権限、Secrets、checks、承認、停止条件を一枚にし、便利さと安全境界を同時に設計します。