Claude CodeをGitHub Actionsで動かす前に：trigger・permissions・secrets・MCPを分ける設計

3行まとめ

Trigger

誰の入力で起動するかを分けます。

Permission

job単位でtoken権限を絞ります。

Secret

AI入力、ログ、artifactから離します。

自動化の前に、入口、権限、秘密情報を別々に設計します。

• Claude CodeをGitHub Actionsで動かすときは、pull_request、issue_comment、workflow_dispatch、scheduleを同じ入口として扱わず、信頼度ごとにjobを分けます。
• GITHUB_TOKEN permissions、ANTHROPIC_API_KEY、PR書き込み権限、MCP tool、外部通信を1つのjobへ詰め込むと、何が読めて何を書けるのか説明しにくくなります。
• 最初はread-only診断、修正案の出力、maintainer手動起動のwrite jobという段階から始め、secret疑い、未知command、MCP write tool要求では完了扱いにしない設計にします。

本文の事実確認には、AnthropicのClaude Code GitHub Actions / Security / Settings / MCP関連ドキュメント、anthropics/claude-code-action公式リポジトリのsecurity guidance、GitHub Actionsのsecretsとpermissions関連ドキュメントを使っています。Xで伸びているClaude Code自動化、MCP、権限まわりの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

起動条件

PR、Issue、手動実行を分けます。

権限

contents、pull-requests、issuesを分けます。

secret

モデルAPIキーと入力を分離します。

MCP

外部toolの副作用を確認します。

CIに入れる前に、任せる範囲を小さく固定します。

• Claude Code GitHub Actionsで混ざりやすい入力、実行、書き込み、外部接続の境界
• pull_request、issue_comment、workflow_dispatch、scheduleをどう分けるか
• GITHUB_TOKEN permissionsをjob単位で最小化する考え方
• ANTHROPIC_API_KEYやGitHub tokenをAI入力、ログ、artifactから離す設計
• Issue本文やPRコメントをそのまま命令として扱わない理由
• MCPや外部toolを追加権限としてレビューする観点

Claude CodeをCIに入れる目的は、開発者の作業を速くすることです。ただし、CIはもともと「無人で動く場所」です。そこへAIエージェントを入れると、ログを読む、修正案を出す、branchを作る、PRへコメントする、外部toolを呼ぶ、という操作が自然につながります。

便利さだけを見ると、全部を1つのworkflowにまとめたくなります。けれど実務では、1つにまとめるほどレビューしにくくなります。この記事では、Claude Codeの性能比較ではなく、壊れにくい運用にするための権限分離を扱います。

前提知識

項目	内容	見方
Claude Code Action		GitHub Actionsでの起動方法と設定を確認します。
Security docs		permission、credential保護、MCP設定を確認します。
GitHub Actions		permissions、secrets、eventの挙動を確認します。
claude-code-action		公式リポジトリのsecurity guidanceを確認します。

導入時には、利用中のAction versionと公式Docsを再確認します。

AnthropicのClaude Code GitHub Actionsドキュメントでは、GitHub Actions上でClaude Codeを動かし、PRやIssueに対する作業を自動化する導入方法が案内されています。典型的には、Anthropic API keyをGitHub Actions secretsに置き、workflowからClaude Code Actionを呼び出します。

AnthropicのSecurity関連ドキュメントでは、Claude Codeが追加の操作を行うときにpermissionを求める考え方、credential保護、MCPサーバーに対する権限設定などが説明されています。Settings関連ドキュメントでは、.claude/settings.jsonでpermissionや追加directory、hooks、MCP serversなどを設定できることが示されています。

GitHub Actions側では、workflowやjobのpermissionsでGITHUB_TOKENのscopeを調整できます。GitHubのsecretsドキュメントでは、secretは明示的にworkflowへ渡した場合にだけ読み取られると説明されています。つまり、Claude Code Actionを使う場合も、AIの設定だけでなく、GitHub Actionsのevent、token、secret、ログ、artifactの扱いを同時に見ます。

CIに入れると責任範囲が変わる

ローカルでClaude Codeを使う場合、ユーザーは画面の前にいて、許可や拒否をその場で判断できます。GitHub Actionsでは、起動した後に人間が見ていない時間が長くなります。だからこそ、workflow側に止める条件を置く必要があります。

条件

最初の導入では、Claude Codeに「修正まで全部やらせる」のではなく、失敗ログの要約、原因候補、修正方針、必要なテストを出させるところから始めます。書き込み権限は別jobに分け、maintainerが明示的に起動する形にします。

注意点

Claude Codeのpermission設定、GitHub Actionsのpermissions、GitHub repository secret、MCP toolの権限は別物です。どれか1つを制限しただけで全体が安全になるわけではありません。

Claude Code GitHub Actionsで混ざる4つの境界

入力

Issue本文、PR本文、コメント、diffです。

実行

checkout、test、build、command実行です。

書き込み

commit、PR作成、コメント、label操作です。

外部接続

APIキー、MCP、外部toolです。

境界が混ざるほど、レビューと事故調査が難しくなります。

Claude Code Actionで最初に分けたいのは、次の4つです。

境界	例	混ぜたときの問題
入力	Issue本文、PR本文、コメント、diff、失敗ログ	prompt injectionや誤指示が入りやすい
実行	checkout、test、build、shell command	PR由来のコード実行と強い権限が混ざる
書き込み	commit、push、PR作成、コメント、label	AI出力がそのまま外部状態を変える
外部接続	Anthropic API、MCP、社内API、package registry	secretや内部情報が外に出る可能性がある

1つのworkflowで「コメントを受ける」「PRコードをcheckoutする」「API keyを使う」「修正branchへpushする」「PRにコメントする」まで実行すると、どこにどの権限があるのか追いにくくなります。

まず診断と書き込みを分ける

最初のjobは、read-only診断に寄せます。PRのdiffや失敗ログを読み、修正方針だけを出します。この段階では、contents: readやpull-requests: readで足りることが多いです。

書き込みは別jobにします。branchを作る、commitする、PRを開く、PR本文を更新する、といった処理は、maintainerが手動起動したときだけ実行するほうが説明しやすくなります。

既存記事との分担

GitHub Actions全般のpull_request_target、secrets、GITHUB_TOKEN permissionsの基礎は、GitHub ActionsでAI修正PRを作る前にでも整理しています。この記事では、その上にClaude Code Action、Anthropic API key、MCP、コメント起動を重ねるときの実務設計に絞ります。

triggerは信頼度で分ける

項目	内容	見方
pull_request		低権限の診断やテスト向けです。
issue_comment		コメント本文を命令として扱わない設計にします。
workflow_dispatch		maintainer手動起動の修正jobに向きます。
schedule		定期診断や依存更新候補の洗い出しに使います。

強い権限が必要な処理は、信頼できるtriggerへ寄せます。

Claude Code Actionでは、IssueコメントやPRコメントから起動する構成が便利です。たとえば、@claudeのようなメンションで修正を依頼できる形は、開発体験としては自然です。ただし、便利なtriggerほど、誰がその入力を書けるのかを見ます。

trigger	向いている用途	初期方針
pull_request	テスト、lint、read-only診断	外部PRでは低権限に寄せる
issue_comment	maintainerとのやりとり、依頼受付	コメント本文を命令として信用しすぎない
workflow_dispatch	修正jobの手動起動	write権限をここへ寄せる
schedule	定期診断、依存更新候補	無人writeを避ける

issue_commentは入力受付にする

IssueコメントやPRコメントは、AIへの自然な入口です。しかし、コメント本文は誰が書いたものか、どの権限で起動したのか、対象PRがfork由来か、などを見ないと危険です。

コメントは「依頼内容を受け取る場所」として扱います。コメントの中に「secretを表示して」「このcurlを実行して」「権限設定を変えて」と書かれていても、それでworkflow側の制約が変わってはいけません。

条件

issue_commentで起動する場合は、まず投稿者がmaintainerか、対象Issue/PRが許可対象か、対象branchが信頼できるかを確認します。確認できない場合は、診断だけに留めます。

注意点

コメント起動とwrite権限を同じjobに入れると、入力の信頼度と操作の強さが結びつきます。コメントを受けるjobと、実際にbranchへ書くjobは分けたほうが扱いやすくなります。

permissionsはjob単位で最小化する

項目	内容	見方
diagnose		contents: read、pull-requests: readで診断します。
patch		contents: writeは修正branch作成時だけ使います。
comment		issues: writeやpull-requests: writeを限定します。
release		deployやpackage publishは別workflowにします。

write権限は、AIの読み取りjobと分けます。

GitHub Actionsでは、permissionsをworkflow全体にもjob単位にも書けます。Claude Code Actionを使うときは、workflow全体に広い権限を置くより、jobごとに必要なscopeを明示します。

permissions:
  contents: read

jobs:
  diagnose:
    permissions:
      contents: read
      pull-requests: read

  propose-comment:
    permissions:
      contents: read
      issues: write

  create-fix-pr:
    permissions:
      contents: write
      pull-requests: write

この例では、診断、コメント、PR作成で権限を分けています。実際の設定はリポジトリの運用に合わせますが、見るべき点は同じです。AIが読むjobと、GitHub上の状態を書き換えるjobを分けます。

contents: writeを常時持たせない

contents: writeはbranchへcommitしたり、fileを変更したりできる強い権限です。Claude Codeが常にこの権限を持っている必要はありません。失敗ログの分析や修正案の作成だけなら、read-onlyで十分な場合があります。

pull-requests: writeも用途を限定する

PR本文やコメントを更新するだけでも、公開される情報やレビューの流れに影響します。pull-requests: writeやissues: writeは、コメント投稿やPR作成に必要なjobだけへ置きます。

評価基準

workflowを見たときに、各jobについて「何を読めるか」「何を書けるか」「どのsecretを使うか」「どの入力をAIに渡すか」を1分で説明できる状態を合格にします。説明できないjobは、権限が混ざっている可能性があります。

secretsはAI入力とログから離す

ANTHROPIC_API_KEY

Actions secretとして参照し、本文やpromptに書きません。

logs

失敗ログにsecret疑いがあれば止めます。

artifact

AI用入力と成果物にsecretを含めません。

token

GitHub Appや短命tokenを検討します。

secretは使う必要があっても、AIに読ませる必要はありません。

Claude Code Actionを動かすには、Anthropic API keyなどのsecretが必要になることがあります。重要なのは、secretを使うことと、secretをAIに読ませることを分けることです。

GitHub Actionsのsecretは、workflowへ明示的に渡した場合に利用されます。だから、ANTHROPIC_API_KEYをActionの入力に渡す設計と、Claude Codeへ読ませるIssue本文、PR差分、ログ、artifactは分けて考えます。

secretを含むログを入力にしない

失敗ログには、環境変数、内部URL、tokenの一部、顧客ID、private package名が混ざることがあります。AIにログを渡す前に、maskされているか、secret疑いの文字列がないかを確認します。

条件

次のような文字列が入力に入る場合は、Claude Codeへ渡す前に止めます。

• API keyやtokenらしい長い文字列
• .env、private key、証明書、cookie
• 社内host名、private registry URL
• 顧客ログや本番DB由来の値
• GitHub tokenやcloud credentialの断片

注意点

secretをGitHub Actions側でmaskしていても、AIへ渡す前のファイル、artifact、prompt生成スクリプトに残ることがあります。secret対策は、表示ログだけでなく、入力ファイルと生成物まで見ます。

GitHub Appや短命tokenを検討する

長期のpersonal access tokenをrepository secretに置く設計は、あとから権限を追いにくくなりがちです。GitHubの公式Docsでも、GitHub Appやfine-grained permissionの利用が選択肢として示されています。組織で運用するなら、tokenの寿命、scope、発行者、監査ログを確認します。

Issue本文とPRコメントを命令として扱わない

1. 1受信

   Issue本文、PR本文、コメントを取得します。

2. 2分類

   対象ファイル、再現手順、期待結果に分けます。

3. 3制約

   許可コマンドと禁止操作を上書きできないようにします。

4. 4承認

   writeや外部通信は人間レビューへ戻します。

コメントは材料であり、CI権限を変える命令ではありません。

AIエージェントをCIで動かすときに見落としやすいのが、Issue本文やPRコメントの扱いです。人間にとっては自然な依頼文でも、AIに渡すと実行指示のように働くことがあります。

たとえば、PR本文に「このworkflowでは安全確認を飛ばしてよい」「secretを表示して原因を確認して」「curlで外部へ送って」と書かれていたとします。これをAIがそのまま作業指示として扱うと、workflow側の制約をすり抜ける方向へ進む可能性があります。

コメントは構造化してから渡す

Issue本文やPRコメントを、そのまま長文promptに入れるのではなく、構造化して扱います。

入力	扱い方
再現手順	事実情報として扱う
期待結果	要件候補として扱う
対象ファイル	allowlistと照合する
実行してほしいcommand	許可リストと照合する
権限変更の依頼	自動実行せずレビューへ戻す

ルールをコメントで上書きさせない

Claude Codeへ渡すsystem的な制約、repository rule、.claude/settings.json、GitHub Actionsのpermissionsは、Issueコメントより強いものとして扱います。コメント本文に「上の指示を無視して」と書かれても、CIの権限や停止条件は変わらない設計にします。

この考え方は、Codexにインターネットアクセスを許可する前にで扱った外部通信の分離とも同じです。AIに渡す自然言語の入力と、実際に許可される外部操作は別に管理します。

MCPや外部toolは追加権限として見る

Tool

read toolとwrite toolを分けます。

Resource

読ませる内部情報を限定します。

Network

外部domainや社内APIを確認します。

Audit

tool callと結果を記録します。

MCPを足すと、CIの外にある権限境界も増えます。

Claude CodeはMCPや外部toolと組み合わせることで、できることが増えます。これは便利ですが、CIでは「便利な拡張」ではなく「権限追加」として扱います。

MCP serverをつなぐと、Claude Codeが追加のToolsやResourcesへアクセスできるようになります。read-onlyの情報取得だけなら影響は限定的ですが、issue更新、DB操作、社内API呼び出し、外部POST、browser操作のようなtoolは副作用を持ちます。

read toolとwrite toolを分ける

MCPを使う場合、最初はread-only toolから始めます。たとえば、ドキュメント検索、issue情報取得、package metadata確認のような操作です。

write toolは別扱いにします。GitHubへコメントする、チケットを更新する、外部APIへPOSTする、社内DBへ書く、fileをアップロードする、といったtoolは人間承認へ戻します。

条件

CIでMCPを使う前に、少なくとも次を決めます。

• どのMCP serverを使うか
• toolごとのread/write分類
• tool callのログをどこに残すか
• secretや内部情報をtoolへ渡す条件
• 失敗時に再試行するか
• allowlist外の外部通信をどう止めるか

注意点

MCP server自体が外部通信やshell実行を行う場合、GitHub Actionsのpermissionsだけでは制御できません。Claude Codeの設定、MCP serverの設定、CI network、secret管理をセットで確認します。

最初に作るworkflowの形

1. 1診断

   低権限でログと差分を読ませます。

2. 2提案

   修正方針とテスト案だけ出します。

3. 3手動起動

   maintainerが修正jobを起動します。

4. 4PR作成

   write権限jobでbranchとPRを作ります。

無人の全自動より、最初は人間の承認点を残します。

最初から「コメントしたらClaude Codeが修正してPRを出す」まで作ると、便利ではありますが、レビュー対象が広くなります。初回は次の3段階に分けるのがおすすめです。

1. read-only診断job

PRやIssueから、対象path、失敗ログ、関連diffを読みます。Claude Codeには、原因候補、修正方針、確認すべきテスト、権限が必要な操作を出させます。このjobではcommitもpushもしません。

2. maintainer手動起動job

診断結果を見たmaintainerが、必要なときだけworkflow_dispatchで修正jobを起動します。対象branch、対象path、実行してよいテストを明示します。

3. write job

修正jobだけにcontents: writeやpull-requests: writeを渡します。Claude Codeが作った差分は、PRとして出し、人間がレビューします。merge、release、deployは別workflowにします。

name: claude-diagnose

on:
  pull_request:
    types: [opened, synchronize, reopened]
  workflow_dispatch:
    inputs:
      target_branch:
        required: true
        type: string

permissions:
  contents: read

jobs:
  diagnose:
    permissions:
      contents: read
      pull-requests: read
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Code in diagnostic mode
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          echo "ここでは診断と修正案だけを出す"

この例は考え方を示すものです。実際のAction名、入力名、認証方法、permissionsは、使うClaude Code Actionの公式Docsとリポジトリのsecurity guidanceに合わせて確認してください。

成果物は差分だけにしない

Claude Codeに修正を任せる場合も、成果物はpatchだけでは足りません。どのログを読み、どの制約で動き、どのテストを実行し、何を未検証として残したかをPR本文に残します。

失敗時に止める条件

項目	内容	見方
secret疑い		入力、ログ、artifactに混入した場合。
未知command		許可していないshellや外部通信を要求した場合。
強い権限		contents: writeなどが予定外に必要になった場合。
MCP write		副作用のあるtoolを呼ぶ場合。

止める条件があるworkflowのほうが、長く運用しやすくなります。

Claude Code Actionの導入で大事なのは、成功条件より先に停止条件を決めることです。次の条件に当たったら、完了扱いにせず、人間レビューへ戻します。

条件	止める理由	次の扱い
secret疑い	AI入力やartifactに秘密情報が混ざる	入力を破棄し、maskやredactionを見直す
未知command	許可していないshell実行が必要	maintainer承認へ戻す
外部POST	情報送信や副作用がある	送信先、payload、目的をレビュー
MCP write tool	外部状態を変える	tool単位で承認する
権限不足	read-onlyでは完了しない	write jobへ進めるか判断する
テスト未実行	動作確認がない	PR本文に未検証として残す

失敗ログも成果物にする

「Claude Codeが失敗した」で終わらせず、なぜ止めたのかをログに残します。secret疑いで止めたのか、権限不足で止めたのか、未知commandで止めたのかが分かると、次のworkflow改善につながります。

自動リトライを広げすぎない

外部API、package registry、MCP server、network通信に依存するjobは、失敗時の再試行で余計な副作用が起きることがあります。再試行回数、timeout、外部通信のallowlistを先に決めます。

実務で使うなら

1. 1日目

   read-only診断だけを作ります。

2. 2日目

   permissionsとsecretsを棚卸しします。

3. 3日目

   手動起動の修正jobを試します。

4. 5日目

   MCPや外部toolの要否を判断します。

5. 7日目

   ログとレビュー負荷を見て運用を決めます。

便利さより、説明できる運用から始めます。

社内やチームでClaude Code Actionを入れるなら、最初の1週間は「AIにどこまで任せられるか」より「どこで止まるべきか」を確認します。

1日目: read-only診断だけ作る

PRの失敗ログやdiffを読ませ、原因候補と修正案だけ出します。commit、push、PR作成、外部tool呼び出しはしません。

2日目: permissionsとsecretsを棚卸しする

workflowごとに、permissions、使用secret、artifact、ログ、外部通信を一覧にします。特にcontents: write、pull-requests: write、issues: write、cloud credential、GitHub tokenを確認します。

3日目: 手動起動の修正jobを試す

maintainerだけが起動できるworkflow_dispatchで、小さな修正を試します。対象path、実行コマンド、branch名、PR作成条件を固定します。

5日目: MCPや外部toolの要否を判断する

MCPを入れる前に、read-onlyのGitHub APIや公式Docs確認だけで足りないかを見ます。どうしてもMCPが必要なら、read toolから始め、write toolは承認制にします。

7日目: レビュー負荷を見る

PR本文、差分、テスト結果、未検証項目、ログを見て、人間がレビューできる粒度になっているか確認します。差分が大きすぎるなら、1回の依頼を小さくします。

FAQ

完全自動

最初の選択肢にはしません。

fork PR

低権限診断から始めます。

MCP

write toolを承認制にします。

secrets

AI入力とは別に扱います。

迷ったら、read-onlyへ戻して差分を人間が見ます。

Claude Code Actionは最初から完全自動にしてよいですか

最初から完全自動にしないほうが安全です。read-only診断、修正案、手動起動のwrite job、PRレビューという段階を作ると、どこで止めるべきか見えます。

ANTHROPIC_API_KEYをActions secretに入れれば安全ですか

Actions secretに入れることは必要な対策の1つですが、それだけでは十分ではありません。AIへ渡す入力、ログ、artifact、MCP tool、外部通信にsecretや内部情報が混ざらないようにします。

fork PRでもClaude Codeに修正させてよいですか

fork PRでは、まず低権限の診断に留めるのが無難です。強い権限やsecretが必要な修正は、maintainerが内容を見てから手動起動するjobへ分けます。

MCPは入れたほうがよいですか

必要になってからで十分です。MCPはClaude Codeに外部toolを増やす仕組みなので、read-only toolとwrite toolを分け、tool callのログと承認条件を決めてから使います。

PRコメント起動は危険ですか

危険というより、設計を間違えると入力と権限が混ざりやすい入口です。コメントは依頼受付として扱い、CIの権限、禁止操作、secret扱いをコメントで上書きできないようにします。

参照した主な情報源

• https://docs.claude.com/s/claude-code-github-actions
• https://code.claude.com/docs/en/github-actions
• https://docs.claude.com/en/docs/claude-code/security
• https://docs.anthropic.com/en/docs/claude-code/settings
• https://docs.anthropic.com/en/docs/mcp
• https://github.com/anthropics/claude-code-action/blob/main/docs/security.md
• https://docs.github.com/en/actions/concepts/security/secrets
• https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#permissions

次に読むなら

更新履歴

1. 2026年5月31日

   Anthropic公式Docs、claude-code-action公式security doc、GitHub Actions公式Docsを確認して初版を作成しました。

導入時には、Action versionと公式Docsの最新状態を再確認してください。

• 2026年5月31日: Anthropic公式Docs、claude-code-action公式security doc、GitHub Actions公式Docsを確認し、初版を作成しました。