Claude CodeをGitHub Actionsで動かす｜権限とレビュー境界

最小構成の役割は、PRの差分をClaudeに読ませ、結果を人へ返すところまでです。実装変更、commit、PR作成、mergeは含めません。誤った出力が出ても「何を読めたか」「何を書けたか」「誰が採用したか」を切り分けられます。ここでいう読み取り中心とは、リポジトリ内容を変更しないという意味であり、認証に使う`id-token: write`まで省くという意味ではありません。

2026-08-21時点のAnthropic公式PRレビュー例は、`pull_request`の`opened`、`synchronize`、`ready_for_review`、`reopened`を対象にし、jobの`permissions`を`contents: read`、`pull-requests: read`、`issues: read`、`id-token: write`としています。導入時の骨格は次の範囲です。 ```yaml on: pull_request: types: [opened, synchronize, ready_for_review, reopened] jobs: review: permissions: contents: read pull-requests: read issues: read id-token: write ``` これは完全なworkflowの転記ではなく、対象イベントとjob権限をレビューするための最小抜粋です。automation modeの結果は既定でworkflow run logへ出せるため、最初からPRへの書き込みを許す必要はありません。

「レビュー結果をPRへ直接置いたほうが早いのでは」と考えたくなります。しかし、結果の置き場所を変える設定は書き込み能力の追加です。まずlog上の結果を人が読み、誤検知や見落としを判断できる運用を確立する。その後にだけコメント権限を検討する順序なら、レビュー自動化とリポジトリ変更を混同しません。

2026-08-21時点で、Claude Code GitHub Actionは`prompt`を省略するとIssueまたはPR上のトリガーフレーズを待つinteractive modeになり、`prompt`を指定するとGitHubイベントに応じて走るautomation modeになります。前者は依頼者の操作が入口、後者はイベント自体が入口です。どちらを採るか曖昧なまま権限だけを見ると、想定外のIssueやPRから実行される範囲を見落とします。

IssueとPRイベントでは、既定で起動者にリポジトリへのwrite accessが求められ、bot actorは全イベントで既定拒否されます。write accessのない特定ユーザーを`allowed_non_write_users`で許可するには独自の`github_token`が必要です。Anthropicは、この設定が主要なアクセス制御を迂回するため、権限を極小化すべきものとしています。イベント、起動者、toolを一組として狭めます。

最小例ではautomation modeのPRレビューだけに役割を固定し、前節の4イベントを明示します。Issueからの対話起動、bot起動、write accessのないユーザーの例外許可は同時に開放しません。必要になった入口だけを別途評価すれば、「誰が何を契機に実行できるのか」という問いにworkflow単位で答えられます。

`permissions`をreadにしたから、Action全体も読み取り専用だと言い切れるでしょうか。確認すべき境界は、workflowの`GITHUB_TOKEN`、Claude GitHub Appのインストール権限、Anthropic認証secretの3つです。一方を絞っても他方の権限は自動的に縮みません。

2026-08-21時点のGitHub公式仕様では、Actionはworkflowで明示的に渡されていなくても`github.token` contextから`GITHUB_TOKEN`へアクセスできます。したがって、workflowまたはjob単位の`permissions`で必要最小限を明示します。「tokenをinputへ書いていない」はアクセス不能の証明になりません。読み取りレビューでは、先のread権限を基準に、追加する権限の目的を一つずつ説明できる状態にします。

一方、`github_token`を省略したClaude Code GitHub ActionはClaude GitHub Appで認証されます。2026-08-21時点のAnthropic公式Appは、Contents、Issues、Pull requestsを含む複数権限のread/writeを一括で要求し、部分承認はできません。Actionに必要な範囲へ絞る要件がある場合、AnthropicはContents、Issues、Pull requests権限を持つcustom GitHub Appを案内しています。workflowのjob権限だけでなく、インストールしたAppがリポジトリ全体で持つ権限も棚卸しの対象です。

認証情報はさらに別です。Claude APIなら`ANTHROPIC_API_KEY`、Claude subscriptionなら`CLAUDE_CODE_OAUTH_TOKEN`をGitHub Secretsへ保存し、対応するAction inputへ渡します。workflowへ直接commitしません。GitHub公式仕様では、secretはworkflowへ明示的に含めた場合だけ読み取られ、environment secretはrequired reviewersの承認までjobからのアクセスを止められます。ログの自動redactionも、変換された値まで完全に隠す保証ではありません。権限、secretの受け渡し、ログ出力を別々に確認します。

公開リポジトリではforkからPRが届きます。2026-08-21時点のGitHub仕様では、forkからの`pull_request`実行にsecretは渡されません。そのためAnthropicのAPIキーを使う公式レビュー例は、公開リポジトリについて、同一リポジトリ内のbranchから作られたPRだけで実行される条件を置いています。これは公開リポジトリのfork PRとsecretに由来する限定です。すべてのリポジトリで同一リポジトリ内PRが必須だ、と一般化してはいけません。

ではfork PRにもsecretを渡すため、`pull_request_target`へ変えればよいのでしょうか。GitHubはこのイベントを、base repositoryの`GITHUB_TOKEN`とrepositoryまたはorganization secretsへアクセスする高信頼イベントとして説明しています。既定ではbase側のコードを使うためforkコードを実行しませんが、PR headをcheckoutし、build、test、installなどを行えば、未信頼コードがsecretとtokenを持つ環境で動く「pwn request」になります。

結論は、secretが不要ならGitHubが推奨する`pull_request`を使うことです。`pull_request_target`が必要な処理でも、未信頼なPRコードをcheckoutして実行しません。fork PRをどこまでレビュー対象にするかは、イベント名の置換ではなく、secretを要する処理と未信頼コードの実行を同じjobへ置かない設計で決めます。

読み取りレビューが安定した後、結果をPRのインラインコメントへ出すなら、出力先とtool許可をそろえて変更します。2026-08-21時点のAnthropic公式例では、prompt側の`--comment`に加えて、`claude_args`の`--allowedTools`で`mcp__github_inline_comment__create_inline_comment`を許可する必要があります。Actionは`claude_args`にこのtool名がある場合にだけ、インラインコメント用MCP serverを起動します。`--comment`だけで十分という説明は設定不足です。

この追加は表示形式の変更に見えて、実際にはPRへの成果物作成を許す境界変更です。利用可能toolを包括的に広げず、インラインコメントに必要なtool名を明示し、GITHUB_TOKENまたはGitHub Appが持つ書き込み権限も追加前に確認します。同時に、コメントを最終判定として扱わず、指摘内容を人が確認する担当を残します。読み取り結果をlogで確認する段階と、PRへ書き込む段階を分けた意味がここで効きます。

Claudeの出力は最終承認ではありません。レビューコメント、提案コード、branchへのcommit、PR、mergeは、それぞれ影響が異なる成果物です。2026-08-21時点でAnthropicは、workflowへ必要な権限だけを与え、Claudeの変更をmerge前にレビューするよう明記しています。既定構成で変更を行う場合も、新規branchへcommitし、PR作成リンクを返して、ユーザー自身がPRを作る流れにより人間の監督を残します。

運用上は、レビューコメントを人が確認し、提案コードを検証し、PRを人が作成または承認し、merge権限を持つ人が最終判断します。AIがレビューしたからmergeできる、コードを生成したからPR作成も自動承認してよい、とはつなげません。成果物が変わる地点で責任者を明示します。

組織導入時の役割分担や展開順序はClaude Codeの企業導入で押さえる運用設計、個々の許可設定を整理するときはClaude Codeの権限設定と安全な運用も参照できます。今回のworkflowでは、その運用原則をイベント、token、secret、成果物という検査可能な設定へ落とし込みます。

導入時は一つのworkflowに機能を足すのではなく、まず「PR差分を読む」「結果をworkflow run logへ出す」「人が内容を確認する」の3点だけを成立させます。対象は`pull_request`の4イベント、リポジトリ権限はContents、Pull requests、Issuesのreadを基準とし、認証に必要な`id-token: write`を公式例どおり明示します。起動者の例外、bot起動、インラインコメント、コード変更は初期範囲の外です。

PRへコメントを書くなら必要な権限とinline comment MCP toolだけを追加します。コード変更は別workflowにし、新規branch、PR作成、人間のmergeレビューを保ちます。公開リポジトリのfork PRではsecretが渡らない条件を受け入れるか、secret不要の処理へ分け、`pull_request_target`で未信頼コードを実行して回避しません。

冒頭に残した条件への答えは明確です。read権限は出発点にすぎず、安全性は、誰がどのイベントで起動し、どの認証主体が何へアクセスし、secretをいつ渡し、どの成果物を誰が承認するかまで分けて初めて説明できます。Claude CodeをIssueやPRから動かす自動化は、実行できることの多さではなく、この境界をworkflow上で検証できる小ささから始めるべきです。