GitHub Actions

Claude Code GitHub Actions（claude-code-action）は、リポジトリのワークフローの中で Claude Code を動かす GitHub Action です。PR や Issue のコメントで @claude と書くと、Claude がコードを分析し、変更を実装し、コミットを push します。あらゆる GitHub のイベントで自動実行するプロンプトを渡すこともでき、Issue を PR に変える・コメントからバグを直す・定期作業を自動化する、といった使い方ができます。

• 設定は、リポジトリのワークフローファイル（.github/workflows/）で行う
• 動き方は2つ：prompt がなければ @claude に応える対話モード、prompt があれば言及を待たない自動化モード
• 認証は、API キー・サブスクリプションの OAuth トークン・ワークロード ID フェデレーションのどれかを使う。Bedrock・Agent Platform・Foundry 経由にもできる
• GitHub Enterprise Server でも、手動のワークフロー設定で使える

セットアップ#

2つの方法があります。どちらもリポジトリの管理者権限が要ります。

• クイックセットアップ：Claude Code から /install-github-app を実行する。GitHub App のインストール、認証用のシークレットの追加、ワークフローの PR の準備まで Claude Code が行う
• 手動セットアップ：アプリのインストール、シークレットの追加、ワークフローファイルのコピーを自分で行う。ローカルで Claude Code を動かさないとき、コマンドが失敗したとき、ワークフローファイルを完全に自分で制御したいときに使う

クイックセットアップ#

/install-github-app が動くのは github.com のリポジトリだけです。git のリモートが gitlab.com や bitbucket.org なら、通知を出してセットアップを始めずに終了します（GitLab は GitLab CI/CD を使う）。始める前に、GitHub CLI を入れ、gh auth login で認証しておきます。入っていなければ Claude Code が警告します。

接続したいリポジトリで claude を開き、/install-github-app を実行して、案内に従います。Claude Code は Claude GitHub App を入れ、ワークフロー用の認証シークレットを設定します。

• Claude Code がすでに API キーを持っていれば、それを再利用する。リポジトリにすでに ANTHROPIC_API_KEY のシークレットがあれば、そのまま残すかを聞く
• そうでなければ、Claude のサブスクリプションで長期のトークンを作るか、API キーを貼り付けるかを選ぶ

資格情報は、リポジトリのシークレットとして保存されます。名前は、API キーなら ANTHROPIC_API_KEY、サブスクリプションのトークンなら CLAUDE_CODE_OAUTH_TOKEN です。そのあと Claude Code は、選んだワークフローファイル（そのシークレットを使う設定済み）をブランチに push し、ブラウザで GitHub を開いて PR を作る準備をします。その PR を作ってマージすれば、そのリポジトリで @claude が動きます。

• 途中でやめるには Esc を押す。進行中の手順は終わり、あとの手順は始まらない。終わりのメッセージに、push したブランチや保存したシークレットなど、すでにリポジトリで起きたことが並ぶ
• レビューのワークフローを選ぶと、Claude は各レビューを PR 自体に投稿する（見つけた問題ごとのインラインコメント、問題がなければ1つの要約コメント）。ドラフトなど一部の PR は飛ばす。v2.1.229 より前は、レビューはワークフローの実行ログにだけ書かれた
• 以前のバージョンが生成したレビューのワークフローを更新するには：/install-github-app をもう一度実行し、すでに claude.yml があるときは「Update workflow file with latest version」を選ぶ（新しいブランチに最新のコピーを push し、最初のインストールと同じように PR を開く）。または、チェックイン済みのファイルに、レビューのワークフローの例の --comment と claude_args の行を自分で足す（ほかの編集を保てる）
• GitHub App のインストール後、GitHub Actions の設定を続けるかを聞かれる。「Skip for now」を選ぶと、GitHub App のインストールだけで止まる。あとでもう一度 /install-github-app を実行して、ワークフローとシークレットの手順を終える

手動セットアップ#

1. Claude GitHub App をリポジトリへインストールする。この Action は、アプリの3つの権限に頼る：Contents（読み書き。リポジトリのファイルを変更するため）、Issues（読み書き。Issue に応えるため）、Pull requests（読み書き。PR の作成と変更の push のため）。インストール時には、ほかの Claude の機能が使う権限も付与する（下の「GitHub App の権限」）
2. 認証の方法に応じて、次のシークレットのどちらかをリポジトリに足す
   • ANTHROPIC_API_KEY：Claude Console の Claude API キー
   • CLAUDE_CODE_OAUTH_TOKEN：Claude のサブスクリプションで認証する OAuth トークン（Pro・Max・Team・Enterprise のプランで使える）。ローカルで claude setup-token を実行して作る
   • ワークフローファイルでは、シークレットを対応する入力に渡す：API キーなら anthropic_api_key、OAuth トークンなら claude_code_oauth_token
3. examples/claude.yml を、リポジトリの .github/workflows/ にコピーする。このファイルは例ではなく、動くワークフローで、コミットされたままだと、Issue や PR で誰かが @claude と言及するたびに Claude が応え、ANTHROPIC_API_KEY のシークレットで認証する。代わりに CLAUDE_CODE_OAUTH_TOKEN を足したなら、anthropic_api_key の行を claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} に変える

組織に展開する#

クイックセットアップも手動も、1回に1つのリポジトリを設定します。組織全体に展開するには：

• Claude GitHub App を組織レベルで1回インストールし、すべてのリポジトリか選んだ一覧を指定する
• 認証のシークレットを組織レベルの Actions シークレットとして保存し、各リポジトリが自分のコピーを持たなくて済むようにする
• この Action を動かしたい各リポジトリにワークフローファイルを足すか、ジョブを1回再利用可能なワークフローとして定義し、各リポジトリから呼ぶ

リポジトリをまたいで共有するシークレットには、OAuth トークンでなく Claude Console の API キーで認証してください。OAuth トークンは、claude setup-token を実行した人のサブスクリプションに結びつくためです。長期のシークレットをそもそも保存したくなければ、ワークロード ID フェデレーションで認証します。この Action が、ワークフローの GitHub OpenID Connect（OIDC）トークンを、Claude Console のサービスアカウントを通した Claude API のアクセスと交換します。次の入力を設定します。

• anthropic_federation_rule_id：フェデレーションルールの ID（fdrl_...）
• anthropic_organization_id：Anthropic の組織 ID
• anthropic_service_account_id：サービスアカウントの ID（svac_...）。Console で作るフェデレーションルールがすでにサービスアカウントを指すので、任意
• anthropic_workspace_id：ワークスペースの ID（wrkspc_...）。フェデレーションルールが1つのワークスペースを対象にするなら任意

ワークフローには id-token: write の権限を与えます。フェデレーションの交換にこの Action が必要とするためで、自分の github_token を渡す場合でも要ります。Console 側の設定は、Claude Code Action のセットアップガイドを見てください。データの扱いと保持については、セキュリティとデータの扱いを見てください。

アンインストール#

セットアップのうち、自分の導入に当てはまる部分を元に戻します。

クラウドプロバイダーを設定したなら、AWS_ROLE_TO_ASSUME・GCP_*・AZURE_* のようなプロバイダーのシークレットも削除し、カスタムの GitHub App を、その APP_ID と APP_PRIVATE_KEY のシークレットといっしょにアンインストールします。

GitHub App の権限#

Claude GitHub App は、この Action・コードレビュー・クラウドセッションのPR の自動修正など、GitHub と連携するすべての Claude の機能で共有されます。GitHub App は、全機能を含む1つの権限の集合を持つので、この Action が使わない権限も含まれます。インストール時に、次の権限を付与します。

権限の集合は、それを使う機能より先に変わることもあります。アプリが、以前は持っていなかった権限を求めると、GitHub がアカウントのオーナー（組織へのインストールなら組織のオーナー）に承認を求め、承認されるまで、インストールは古い権限のままです。たとえば Actions のアクセスが読み取りから読み書きに変わると、アプリは実行の表示とログの閲覧だけでなく、ワークフローを再実行できるようになるので、GitHub がオーナーに変更の承認を求めます。

アプリをインストールすると、全権限の集合を受け入れます。GitHub は一部だけの受け入れを許しません。組織がこの Action の使う権限だけを求めるなら、代わりに、Contents・Issues・Pull requests だけを持つカスタムの GitHub App を、セットアップガイドに従って作ります。カスタムのアプリが対象にするのはこの Action だけで、コードレビューと Web の自動修正は、引き続き公式のアプリが要ります。

対話モードと自動化モード#

Action は、ワークフローの設定から動き方を判断します。

誰が実行を起動できるか#

どちらのモードでも、Claude が始まる前に、トリガーした主体への2つの確認が走り、どちらかが拒否すると実行は失敗します。

• 書き込み権限：Issue と PR のイベントでは、トリガーしたユーザーにリポジトリの書き込み権限が必要。書き込み権限のない特定のユーザーを許すには、allowed_non_write_users を設定し、自分の github_token の入力を渡す。schedule のように、ユーザーが起こさないイベントは、この確認を飛ばす
• 人間の主体：すべてのイベントで、この Action は、allowed_bots に載せていない bot の主体を拒否する（bot が Claude をループで起動するのを防ぐ）。この確認は、GitHub がリポジトリのユーザー（たいてい、ワークフローの cron スケジュールを最後に変えた人）に帰属させる、スケジュールの実行にも適用される。そのユーザーが bot なら、allowed_bots に載せる

使用例#

examples ディレクトリに、さまざまな場面向けの、すぐ使えるワークフローがあります。このページの例は API キーの認証を示します。Claude のサブスクリプションで認証するなら、例の anthropic_api_key の行を claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} に置き換えます。

@claude の言及に応える#

次のワークフローは、対話モードで動かし、Issue や PR のコメントで誰かが @claude と言及するたびに Claude が応えます。

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
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

定型文でない部分は次のとおりです。

• id-token: write：この Action の既定の GitHub App 認証に必要
• actions: read：Claude が PR の CI の結果を読めるようにする
• actions/checkout：Claude が作業するリポジトリのローカルコピーを与える
• if：@claude に触れないコメントで、ランナーが始まらないようにする。Action も、応える前にトリガーのフレーズを自分で確認する

ワークフローを置いたら、Issue や PR のコメントに、依頼つきで @claude と書きます。

@claude implement this feature based on the issue description
@claude how should I implement user authentication for this endpoint?
@claude fix the TypeError in the user dashboard component

Claude は同じ Issue や PR のコメントで返信し、作業しながら更新します。

スキルを動かす#

prompt の入力は、プレーンテキストのほかに、スキルの呼び出しも受け付けます。

• リポジトリの .claude/skills/ にあるスキル：スキルのファイルがランナーにあるよう、anthropics/claude-code-action の手順の前に actions/checkout を動かし、/skill-name を prompt に渡す
• プラグインに入れたスキル：plugin_marketplaces と plugins の入力でプラグインをインストールし、名前空間つきの /plugin-name:skill-name を prompt に渡す。plugins の入力は plugin-name@marketplace-name を取り、マーケットプレイス名は、リポジトリの URL ではなく、マーケットプレイス自身のマニフェストに書かれた名前

次のワークフローは、code-review プラグインを入れ、PR が開かれた・更新された・再度開かれた・レビュー可能にされたときに、そのスキルを動かします。クイックセットアップのレビューのワークフローと同じプラグインを動かします。プロンプト・モデル・トリガーを自分で制御したいときに、このようなワークフローを使います。ワークフローファイルを保守せずに自動レビューを受けるなら、コードレビューと ultrareviewを見てください。公開リポジトリでは、GitHub がフォークからの PR で起動した実行にシークレットを渡さないので、レビューは、同じリポジトリのブランチからの PR でだけ動きます。

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

レビューの行き先を決めるのは2行です。

• --comment：Claude が、PR 自体にレビューを投稿する（見つけた問題ごとのインラインコメント、問題がなければ1つの要約コメント）。付けないと、Claude は何も投稿せず、実行ログで結果を読む
• claude_args：スキル自身の allowed-tools の frontmatter が同じツールを名指ししていても、この行は残す。インラインコメントを投稿する MCP サーバーを、claude_args の --allowedTools が名指ししたときにだけ、この Action が起動するため

Claude は、ドラフトとクローズ済みの PR、レビューが要らないと判断した PR（自動生成や些細なもの）、すでに Claude のコメントがある PR を飛ばします。

スケジュールで動かす#

prompt の入力があれば、この Action は、cron のスケジュールを含むあらゆる GitHub のイベントで、自動化モードで動きます。プレーンテキストのプロンプトでは、claude_args の --allowedTools か、settings の入力の permissions.allow ルールで、プロンプトが要るツールを与えるまで、Claude はシェルにも GitHub API にもアクセスできません。代わりにスキルを呼び出すなら、Claude は、その allowed-tools の frontmatter が与えるツールを使えます。GitHub は、スケジュールされたワークフローを既定のブランチからだけ動かし、公開リポジトリでは、リポジトリの活動がないまま60日が過ぎるとスケジュールを無効にします。

次のワークフローは、毎日 09:00 UTC に、ワークフローの実行ログにレポートを作ります。claude_args の行が CLI の引数を渡し、モデルを選んで、2つの GitHub MCP ツールを許可します。Claude は、そのツールで GitHub API からコミットと Issue を読むので、チェックアウトの手順は省けます。

name: Daily Report
on:
  schedule:
    - cron: "0 9 * * *"
jobs:
  report:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read
      id-token: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Generate a summary of yesterday's commits and open issues"
          claude_args: |
            --model claude-opus-5-5
            --allowedTools "mcp__github__list_commits,mcp__github__list_issues"

アクションの入力#

anthropics/claude-code-action の手順の with: に書くキーです。次の表は、公式のドキュメント（この Action の使い方とクラウドプロバイダーの手順）で挙げられている入力をすべて載せます。公式のドキュメントは、これが最もよく使う入力で、全体の一覧は Claude Code Action の設定リファレンス（docs/usage.md の inputs）にあるとしています。

CLI の引数を渡す#

claude_args は、あらゆる Claude Code の CLI の引数を受け付けます。

claude_args: "--max-turns 5 --model claude-sonnet-5 --mcp-config /path/to/config.json"

ベストプラクティス#

• プロジェクトの標準を CLAUDE.md に書く：リポジトリのルートに CLAUDE.md を作り、コードスタイル・レビューの基準・プロジェクト固有の規則・好みのパターンを書く。Claude は PR を作るときや依頼に応えるときにこれに従う。詳しくは CLAUDE.md とメモリを見てください
• 資格情報を守る：API キーや OAuth トークンを、リポジトリに直接コミットしないでください。常に GitHub のシークレットに保存し、ワークフローで anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} のように参照します。ワークフローに必要な権限だけを与え、マージの前に Claude の変更をレビューします。権限と認証を含む包括的なセキュリティの案内は、Claude Code Action のセキュリティのドキュメントを見てください

コストを管理する#

各実行は、2種類の資源を消費します。

• GitHub Actions の分：この Action は GitHub ホストのランナーで動き、GitHub Actions の分を消費する。料金と分の上限は GitHub の課金のドキュメントを見る
• API トークン：各やり取りで、プロンプトと応答の長さ・作業の複雑さ・コードベースの大きさに応じてトークンを消費する。OAuth トークンで認証するなら、実行は API の課金でなく Claude のサブスクリプションを使う

Claude により明確な文脈を与え、各実行が行える作業の量に上限を付けると、どちらのコストも下げられます。

• 具体的な @claude の依頼を書く（Claude が終えるのに要るターンが減る）
• Issue のテンプレートで、先に文脈を与える
• CLAUDE.md を簡潔に保つ（Claude は毎回の実行で読む）
• claude_args の --max-turns で、反復を制限する
• ワークフローレベルのタイムアウトを設定して、暴走するジョブを避ける
• GitHub の concurrency の制御で、並列の実行を制限する

組織全体の使用量の追跡は、利用状況の計測を、使用量の測り方と課金はコストを抑えるを見てください。

クラウドプロバイダーで使う#

既定では、この Action は、API キーか OAuth トークンで Claude API を直接呼びます。推論を自分のクラウドアカウント経由にするには、プロバイダーの入力を設定し、OIDC のトークンを信頼するようクラウドを設定します。ワークフローがそのトークンで認証するので、長期のクラウドの資格情報をリポジトリに保存しません。

三つとも、Claude API キーの代わりに OIDC のアイデンティティフェデレーションで認証します。プロバイダーごとのモデルとリージョンは、Bedrock・Vertex AI・Foundryを見てください。

前提#

• Action が動くリポジトリの管理者権限（GitHub App のインストールとシークレットの追加のため）
• クラウドアカウントでアイデンティティのリソースを作る権限：AWS では IAM ロールと OIDC のアイデンティティプロバイダー、Google Cloud では Workload Identity Federation のリソースとサービスアカウント、Azure では Microsoft Entra のアプリケーション
• プロバイダーでの Claude モデルへのアクセス：Amazon Bedrock は Claude モデルへのアクセスの付与（us. のようなクロスリージョンの推論プロファイルは、そのリージョングループのすべてのリージョンで付与が要る）、Google Cloud の Agent Platform は Agent Platform API を有効にしたプロジェクトと Claude モデルへのアクセス、Microsoft Foundry は Claude のデプロイを持つ Foundry のリソース

手順#

1. GitHub のアイデンティティを選ぶ。Action は、GitHub のアイデンティティを通してコミットを push し、コメントを投稿する。クラウドプロバイダーでは、自分で選ぶ
   • 公式の Claude GitHub App：リポジトリにインストールする（すでに入っていれば次へ）
   • カスタムの GitHub App：この Action が使う3つの権限（Contents・Issues・Pull requests の読み書き）だけにしたいときに、自分で作る。Webhook を無効にして新しい GitHub App を登録し、秘密鍵（.pem）を生成して、設定ページの App ID を控え、Action が動くリポジトリへアプリをインストールする
   • GitHub の自動の GITHUB_TOKEN：作るアプリもインストールするアプリもないが、GitHub は、これで作ったコミットでは CI のワークフローを起動しない
2. クラウドの認証を設定する。GitHub がワークフローに発行する OIDC のトークンを信頼するようクラウドを設定すると、ワークフローの実行ごとに、短期のクラウドの資格情報が得られる
   • Amazon Bedrock：GitHub の OIDC のアイデンティティプロバイダー（プロバイダー URL は https://token.actions.githubusercontent.com、オーディエンスは sts.amazonaws.com）を足す。そのプロバイダーを web identity として信頼する IAM ロールを作り、Bedrock のページの IAM の設定にある呼び出しのポリシー（bedrock:InvokeModel・bedrock:InvokeModelWithResponseStream・bedrock:ListInferenceProfiles・bedrock:GetInferenceProfile と、aws-marketplace の購読のアクション2つ）を付ける。ロールの信頼ポリシーを、repo:your-org/your-repo:* のような subject の条件で自分のリポジトリに限る。ロールの ARN を控える
   • Google Cloud の Agent Platform：IAM Credentials・Security Token Service（STS）・Agent Platform API（aiplatform.googleapis.com）の3つの API を有効にする。issuer が https://token.actions.githubusercontent.com の GitHub OIDC のプロバイダーを持つ Workload Identity Pool を作り、プールを自分のリポジトリに限る属性条件を足す。roles/aiplatform.user（Vertex AI User）の役割だけを持つ専用のサービスアカウントを作り、プールがそれになりすませるようにする。プロバイダーの完全なリソース名とサービスアカウントのメールアドレスを控える
   • Microsoft Foundry：Microsoft Entra のアプリケーションを登録し、自分のリポジトリへ GitHub が発行するトークンを信頼する federated identity credential を足す（アプリの代わりにユーザー割り当てのマネージド ID も使える）。Foundry のリソースに Azure AI User の役割を割り当てる。アプリケーションのクライアント ID・テナント ID・サブスクリプション ID を控える
3. リポジトリのシークレットを足す。プロバイダーのシークレットと、手順1でカスタムの GitHub App を作ったなら、アプリの2つのシークレットを足す

4. .github/workflows/claude.yml のようなワークフローファイルを作る。どの例も、@claude の言及に応え、カスタムのアプリで GitHub に認証し、クラウドプロバイダーが資格情報と交換する OIDC のトークンを GitHub が発行するのに必要な id-token: write の権限を含む。手順1で別のアイデンティティを選んだなら、公式の Claude GitHub App では、「Generate GitHub App token」の手順と github_token の行を削除し、GitHub の自動のトークンでは、トークン生成の手順を削除して、github_token の行を github_token: ${{ secrets.GITHUB_TOKEN }} に変える

各プロバイダーで、anthropics/claude-code-action の前にある手順と、その手順の入力が違います。ほかは共通です。次は Amazon Bedrock の例で、aws-region は自分の値に置き換えます（資格情報の手順が、ジョブの残りのために AWS_REGION として出力します）。

name: Claude PR Action
permissions:
  contents: write
  pull-requests: write
  issues: write
  id-token: write
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened]
jobs:
  claude-pr:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v6
      - name: Generate GitHub App token
        id: app-token
        uses: actions/create-github-app-token@v2
        with:
          app-id: ${{ secrets.APP_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}
      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: us-west-2
      - uses: anthropics/claude-code-action@v1
        with:
          github_token: ${{ steps.app-token.outputs.token }}
          use_bedrock: "true"
          claude_args: '--model us.anthropic.claude-sonnet-4-6'

Google Cloud の Agent Platform と Microsoft Foundry は、上の例の「Configure AWS Credentials」の手順と、anthropics/claude-code-action の手順を、次のように置き換えます。それ以外の部分は、上の例と同じです。

# Google Cloud の Agent Platform
      - name: Authenticate to Google Cloud
        id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
          service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}
      - uses: anthropics/claude-code-action@v1
        with:
          github_token: ${{ steps.app-token.outputs.token }}
          use_vertex: "true"
          claude_args: '--model claude-sonnet-5'
        env:
          ANTHROPIC_VERTEX_PROJECT_ID: ${{ steps.auth.outputs.project_id }}
          CLOUD_ML_REGION: us-east5

# Microsoft Foundry
      - name: Authenticate to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - uses: anthropics/claude-code-action@v1
        with:
          github_token: ${{ steps.app-token.outputs.token }}
          use_foundry: "true"
          claude_args: '--model claude-sonnet-5'
        env:
          ANTHROPIC_FOUNDRY_RESOURCE: your-resource-name

• Agent Platform：CLOUD_ML_REGION は自分の値に置き換える。プロジェクト ID は auth の手順の出力から読むので、ハードコードしなくてよい
• Foundry：your-resource-name を Foundry のリソース名に置き換える（Claude Code がそこからエンドポイントの URL を組み立てる）。azure/login の手順がワークフローの OIDC トークンでサインインし、Claude Code は Azure の既定の資格情報チェーンで資格情報を拾う。モデル ID は、Foundry のリソースの Claude のデプロイに合うものにする
• どのプロバイダーでも、claude_args に --max-turns を足すと、実行の長さとコストに上限を付けられる

5. 動作を確かめる：Issue や PR のコメントで @claude と言及し、リポジトリの Actions タブで実行を見る。Claude が同じ Issue や PR のコメントで返信する

クラウドプロバイダー経由での失敗は、たいてい次の2か所のどちらかで起きます。

• 認証エラー：たいてい OIDC の設定の誤り。ワークフローに id-token: write の権限があるか、信頼の設定のリポジトリ条件が自分のリポジトリと正確に合っているか、ワークフローのシークレット名が足したものと合っているかを確かめる
• トリガーと CI の問題：Action が Claude API を呼ぶときと同じように動く。下の「トラブルシューティング」と、Claude Code Action の FAQ を見る

GitHub Enterprise Server#

GitHub Enterprise Server（GHES）の対応は、Team と Enterprise のプランで使えます。組織が、github.com でなく、自分で運用する GitHub のインスタンスにあるリポジトリで、Claude Code を使えるようにする機能です。オーナーが GHES のインスタンスを接続すれば、開発者はリポジトリごとの設定なしで、クラウドセッションと自動のコードレビューを使えます。GHES に置いたプラグインのマーケットプレイスにも対応しますが、必要な資格情報は面（surface）で違います。github.com のリポジトリはクラウド（Web）で使うとコードレビューと ultrareviewを、自分の CI で Claude を動かすなら、このページの上の節を見てください。

GHES で動くもの#

管理者の設定#

オーナーが、GHES のインスタンスを Claude Code に1回接続します。そのあとは、組織の開発者が、追加の設定なしで GHES のリポジトリを使えます。Claude の組織の Owner か Primary Owner の役割と、GHES のインスタンスで GitHub App を作る権限が要ります。ガイド付きのセットアップは、GitHub App のマニフェストを生成し、1回のクリックでアプリを作れるよう GHES のインスタンスへリダイレクトします。環境がリダイレクトをブロックするなら、手動のセットアップを使います。

1. claude.ai/admin-settings/claude-code の GitHub Enterprise Server の節を開く
2. 「Connect」をクリックし、接続の表示名（20文字以内）と GHES のホスト名（github.example.com など）を入力する。GHES が自己署名か私設の認証局を使うなら、任意の欄に CA 証明書を貼る
3. 「Continue to GitHub Enterprise」をクリックする。ブラウザが、マニフェストを入力済みの GHES のインスタンスへリダイレクトされるので、設定を確認し、「Create GitHub App」をクリックする。GHES が Claude へ戻し、アプリの資格情報が自動で保存される
4. GHES のインスタンスの GitHub App のページから、Claude にアクセスさせたいリポジトリか組織にアプリをインストールする（一部から始めて、あとで足せる）
5. claude.ai/admin-settings/claude-code に戻り、GHES のリポジトリについて、コードレビュー・Claude Security・コントリビューションの指標を、github.com と同じ設定で有効にする

GHES の GitHub App の権限#

マニフェストは、クラウドセッション・コードレビュー・Claude Security・プラグインのマーケットプレイス・コントリビューションの指標をまとめて満たす、次の権限と Webhook のイベントで GitHub App を設定します。

アプリは、pull_request・issue_comment・pull_request_review_comment・pull_request_review・check_run・status のイベントを購読します。GitHub がマニフェストを適用するのはアプリを作るときだけなので、以前のバージョンのマニフェストから作ったアプリは、作ったときの権限とイベントのままです。上の権限やイベントが足りなければ、GHES のインスタンスのアプリの設定で足します。GitHub が各インストールのオーナーに新しい権限の承認を求め、承認されるまで、インストールは古い権限のままです。

手動セットアップ#

ガイド付きのリダイレクトがネットワークの設定でブロックされるなら、「Connect」の代わりに「Add manually」をクリックします。GHES のインスタンスに、上の権限とイベントで GitHub App を作り、フォームに接続の詳細（表示名・GHES のホスト名と任意のポート・アプリの ID・クライアント ID・クライアントシークレット・Webhook のシークレット・秘密鍵）を入力します。任意のカスタム CA 証明書と、リードレプリカのホスト名も受け付けます。接続を保存すると、Claude がアプリの Webhook URL を生成します。「Add configuration」をクリックしたあと、接続の「More options」メニューから「Copy webhook URL」を選び、URL を GHES のインスタンスのアプリの Webhook の設定に貼ります。フォームに入れたのと同じ Webhook のシークレットを使います。

ネットワークの要件#

Anthropic がホストするセッションでは、Claude がリポジトリをクローンし、レビューのコメントを投稿できるよう、GHES のインスタンスが Anthropic のインフラから届く必要があります。GHES がファイアウォールの内側にあるなら、Anthropic の送信 IP アドレスを許可リストに入れます。セルフホスト環境のセッションは、ネットワークの内側からクローンします（ランナーが Anthropic の git プロキシを使うことを選んだ場合を除く）。リポジトリのピッカーのような、ホストされたセッション開始前の流れは、セッションが始まる前に Anthropic の側で動くので、セッションがセルフホスト環境で動く場合でも、GHES のインスタンスが Anthropic のインフラから届く必要があります。SCM コネクタは使えないので、内部からしかたどれない GHES のホストには届きません。

開発者の流れ#

オーナーが GHES のインスタンスを接続すれば、開発者側の設定は要りません。Claude Code は、作業ディレクトリの git のリモートから、GHES のホスト名を自動で検出します。いつもどおり GHES のインスタンスからクローンし（github.example.com とリポジトリのパスは自分のものに置き換える）、クラウドセッションを始めます。Claude は git のリモートから GHES のホストを検出し、組織が設定したインスタンス経由でセッションをルーティングします。

git clone git@github.example.com:platform/api-service.git
cd api-service
claude --cloud "Add retry logic to the payment webhook handler"

セッションは GHES からリポジトリをクローンし、変更をブランチへ push します。進み具合は claude.ai/code で見ます。差分のレビュー・自動修正・ルーティンを含むクラウドセッションの全体の流れは、クラウド（Web）で使うを見てください。claude --teleport で、クラウドセッションを手元のターミナルへ引き込めます。Teleport は、ブランチを取得してセッションの履歴を読み込む前に、同じ GHES のリポジトリのチェックアウトにいることを確かめます。

GHES のプラグインのマーケットプレイス#

組織全体に社内のツールを配るために、GHES のインスタンスにプラグインのマーケットプレイスを置けます。マーケットプレイスの構造は、github.com に置くものと同じですが、インストールの仕方は、マーケットプレイスを足す場所で変わり、必要な資格情報は面ごとに違います。

GHES に置いたマーケットプレイスは、owner/repo の省略形が常に github.com に解決されるので、完全な git URL で足します（HTTPS の URL を推奨）。

/plugin marketplace add https://github.example.com/platform/claude-plugins.git

SSH の URL も、マシンがすでに GHES のホストを信頼していれば使えます。Claude Code は git を非対話で動かし、マシンの known_hosts にないホストへの SSH 接続を拒否します。git の資格情報ヘルパーつきの HTTPS の URL なら、known_hosts の要件を避けられます。マーケットプレイスの作り方はプラグインを作って配るを見てください。

管理設定で GHES のマーケットプレイスを事前登録する#

extraKnownMarketplaces の設定は、手動の設定なしで開発者にマーケットプレイスを届けるよう、あらかじめ登録します。どの設定ファイル（リポジトリの .claude/settings.json を含む）からも動き、管理設定なら組織全体に届けられます。

{
  "extraKnownMarketplaces": {
    "internal-tools": {
      "source": {
        "source": "git",
        "url": "https://github.example.com/platform/claude-plugins.git"
      }
    }
  }
}

Claude Code は、これらのマーケットプレイスをローカルにインストールします。各項目を登録し、マシンにある git の資格情報でリポジトリをクローンします。この経路は claude.ai を通らないので、ユーザーごとの GitHub Enterprise の接続は要りません。うまく展開するには：

• 完全な git URL を使う（owner/repo の省略形は常に github.com に解決され、GHES のホストを参照できない）
• HTTPS の URL を優先する（SSH のクローンは、GHES のホスト鍵をまだ信頼していないマシンで失敗する。組織標準の git の資格情報ヘルパーつきの HTTPS の URL は、資格情報を設定したどのマシンでも動く）
• 各マシンが GHES のホストからクローンできることを確かめる（資格情報のないマシンでは、マーケットプレイスは登録されても、インストールされず、そのプラグインは資格情報の入力を促されずに「見つからない」と報告される）
• 設定が各マシンに届くことを確かめる（管理設定のファイルは、デバイス管理のシステムなどで配布したマシンでだけ有効になる）

管理設定で GHES のマーケットプレイスを許可する#

管理設定で、開発者が足せるマーケットプレイスを制限しているなら、hostPattern のソースの種類を使うと、リポジトリを1つずつ並べずに、GHES のインスタンスのすべてのマーケットプレイスを許可できます。この JSON を managed-settings.json かそれに相当する MDM のポリシーに足します。

{
  "strictKnownMarketplaces": [
    {
      "source": "hostPattern",
      "hostPattern": "^github\\.example\\.com$"
    }
  ]
}

スキーマ全体は、設定キー一覧の strictKnownMarketplaces と extraKnownMarketplaces を見てください。

GHES の制限#

• /install-github-app コマンド：代わりに claude.ai の管理者の設定の流れに従う。GHES で GitHub Actions のワークフローも使いたければ、例のワークフローを手動で合わせる
• GitHub MCP サーバー：代わりに、GHES のホスト向けに設定した gh CLI を使う。gh auth login --hostname github.example.com で認証すれば、Claude がセッションで gh コマンドを使える

GHES のトラブルシューティング#

トラブルシューティング#

Claude が @claude に応えない#

• GitHub App がリポジトリにインストールされているかを確かめる
• リポジトリでワークフローが有効かを確かめる
• API キーか OAuth トークンが、リポジトリのシークレットにあるかを確かめる
• コメントが、/claude や @claude-bot でなく、完全な語として @claude を含むかを確かめる
• コメントしたユーザーにリポジトリの書き込み権限があるかを確かめる（例外は「誰が実行を起動できるか」を見る）

Claude のコミットで CI が動かない#

• GitHub は、既定の GITHUB_TOKEN で作ったコミットではワークフローを起動しない。github_token: ${{ secrets.GITHUB_TOKEN }} を Action に渡しているなら、それを外して Claude GitHub App として認証させるか、代わりにカスタムのアプリのトークンを渡す
• CI のワークフローのトリガーに、Claude の push が生むイベント（push や pull_request など）が含まれているかを確かめる

認証エラー#

• ワークフローのデバッグの前に、API キーか OAuth トークンが有効かを、ローカルで claude で試して確かめる
• Bedrock・Agent Platform・Foundry は、上の「クラウドプロバイダーで使う」の失敗の見方を参照する

そのほかの対処は、Claude Code Action の FAQ を見てください。

beta からの移行#

ワークフローがまだ anthropics/claude-code-action@beta を参照しているなら、v1 へ更新します。

1. uses の行の @beta を @v1 に変える
2. mode の入力を削除する（Action がいまはモードを自動で判断するため。上の「対話モードと自動化モード」）
3. direct_prompt を prompt に置き換える
4. max_turns や model のような CLI のオプションを claude_args に移す。custom_instructions には同名のフラグがなく、--append-system-prompt になる

入力の全体の対応と前後の例は、移行ガイドを見てください。コマンドラインでの非対話の実行はヘッドレス実行（-p）を見てください。