GitHub Actions Bedrock連携 — Claude CodeをVertex/Foundryにも対応

GitHub Actions Bedrock連携とは

Claude Code GitHub Actionsは既定でClaude APIを直接呼び出しますが、anthropics/claude-code-actionの1つの入力を変えるだけで、呼び出し先を自社のクラウドアカウント経由に切り替えられます。Amazon Bedrock・Google Cloud's Agent Platform(旧Vertex AI)・Microsoft Foundryの3つが対応先です。認証はGitHubが発行するOIDC(OpenID Connect)トークンをクラウド側が信頼する形で行うため、リポジトリに長期有効なクラウド認証情報を保存する必要がありません。

すでに組織がいずれかのクラウドでClaudeモデルへのアクセス権を持っているなら、Claude APIの新規契約なしにGitHub Actionsを動かせます。逆に言えば、この連携はAPI認証そのものを置き換えるものです。単純なAPIキー認証でのGitHub Actions導入は別記事のClaude CodeをGitHub Actionsに組み込むで扱っています。

始める前に確認すること

必要な権限とアクセス権は3つあります。

• ワークフローを動かすリポジトリの管理者権限(GitHub Appのインストールとシークレット追加のため)
• クラウド側でID関連リソースを作る権限(AWSならIAMロールとOIDCプロバイダー、Google CloudならWorkload Identity Federationとサービスアカウント、AzureならMicrosoft Entraアプリケーション)
• 選んだプロバイダーでのClaudeモデルへのアクセス権

Amazon Bedrockでクロスリージョン推論プロファイル(us.プレフィックスの付いたモデルID)を使う場合は、そのリージョングループの全リージョンでアクセス権が必要です。1リージョンだけ許可漏れがあると、そのリージョンへのルーティング時にだけ失敗します。

GitHubアプリを選ぶ

Claude Code GitHub Actionsはコミットのプッシュやコメント投稿をGitHub上の何らかのアイデンティティで行います。クラウドプロバイダー経由では、このアイデンティティを自分で選びます。

カスタムGitHub Appを作る場合はwebhookを無効にして登録し、Contents・Issues・Pull requestsの3つを読み書き権限で付与します。秘密鍵をダウンロードしてApp IDを控え、対象リポジトリにインストールしたら、鍵とIDをのちの手順でリポジトリシークレットに追加します。

クラウド側でOIDC信頼関係を設定する

3プロバイダーとも「GitHubが発行するOIDCトークンをクラウド側が信頼する」設計は共通ですが、作るリソースの種類が異なります。

Amazon Bedrock

AWSアカウントに、プロバイダーURLhttps://token.actions.githubusercontent.com・オーディエンスsts.amazonaws.comのGitHub OIDC IDプロバイダーを追加します。そのプロバイダーをWeb IDとして信頼するIAMロールを作り、bedrock:InvokeModel・bedrock:InvokeModelWithResponseStream・bedrock:ListInferenceProfiles・bedrock:GetInferenceProfileと、2つのaws-marketplaceサブスクリプションアクションを許可するポリシーを付与します。ロールの信頼ポリシーはrepo:your-org/your-repo:*のような条件でリポジトリ単位に絞り込めます。ロールのARNを控えておきます。

Google Cloud's Agent Platform(旧Vertex AI)

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

自社リポジトリを信頼するfederated credentialを持つMicrosoft Entraアプリケーションを登録します(アプリケーションの代わりにユーザー割り当てマネージドIDでも同じクライアントIDの扱いになります)。Foundryリソースに対してAzure AI Userロールを割り当てます。アプリケーションのクライアントID・テナントID・サブスクリプションIDを控えます。

リポジトリシークレットとワークフローファイルを用意する

控えた値をリポジトリシークレットに追加します。

ワークフローファイルにはpermissionsにid-token: writeを必ず含めます。これがないとGitHubがOIDCトークンを発行しません。Amazon Bedrockの場合のwith:ブロックはこうなります。

- 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's Agent Platformならgoogle-github-actions/auth@v2で認証し、anthropics/claude-code-action@v1のwith:にuse_vertex: "true"と次のenv:を加えます。

env:
  ANTHROPIC_VERTEX_PROJECT_ID: ${{ steps.auth.outputs.project_id }}
  CLOUD_ML_REGION: us-east5

Microsoft Foundryならazure/login@v2で認証し、use_foundry: "true"と次のenv:を加えます。

env:
  ANTHROPIC_FOUNDRY_RESOURCE: your-resource-name

ANTHROPIC_FOUNDRY_RESOURCEにはFoundryリソース名をそのまま指定します。Claude CodeがこのリソースからエンドポイントURLを組み立てるため、URLを別途指定する必要はありません。共通なのは「トリガー・カスタムGitHub Appのトークン生成」までで、Vertex(Google Cloud's Agent Platform)とFoundryはこのプロバイダー固有のenv:が別途必要です。認証ステップとClaude Code GitHub Actionsのステップの間に他の処理を挟まないようにします。

ワークフローファイルを保存したら、対象リポジトリのissueかPRで@claudeをメンションしたコメントを投稿して動作確認します。リポジトリのActionsタブでワークフローの実行が開始したことを確認し、しばらく待つと同じissueかPRにClaude Codeからの返信コメントが付きます。

--max-turnsをclaude_argsに足せば、どのプロバイダーでも実行時間とコストの上限を設定できます。

どのプロバイダーを選ぶか

3つとも仕組みは同じ(OIDCトークンをクラウドが検証し短命の認証情報を発行する)なので、選択基準は「どのクラウドで既にモデルアクセス権とガバナンス体制があるか」だけで決まります。

よくあるつまずき

• 認証エラーの大半はOIDC設定ミス。id-token: write権限の付け忘れ、信頼ポリシーのリポジトリ条件がリポジトリ名と完全一致していない、ワークフロー内のシークレット名と実際に追加したシークレット名の食い違いの3つを順に確認します
• Bedrockのモデルアクセスはリージョン単位。クロスリージョン推論プロファイルを使うなら、そのリージョングループの全リージョンでアクセス権を確認します
• トリガーとCIの挙動はClaude APIを直接呼ぶ場合と同じです。ワークフローが起動しない・応答が返らないといった問題は、クラウド認証とは別の原因であることが大半です

GitHub Enterprise Serverでの注意点

GitHub Enterprise Server(GHES)上のリポジトリでもGitHub Actions自体は動きますが、/install-github-appコマンドはgithub.com専用です。GHESではGitHub Enterprise ServerでClaude Codeを使うの管理者セットアップでWebセッションとコードレビューを有効化したうえで、GitHub Actionsのワークフローファイルはこのページの手順に沿って手動で作成します。

まとめ

Claude Code GitHub ActionsをBedrock・Google Cloud's Agent Platform・Microsoft Foundry経由で動かす設定は、GitHubアイデンティティの選択・クラウド側のOIDC信頼関係・リポジトリシークレット・ワークフローファイルの4点で共通の型を持ちます。すでにいずれかのクラウドでモデルアクセス権を持つ組織にとっては、Claude API単体契約を増やさずにGitHub Actions連携を始められる選択肢です。Bedrock単体のセットアップはClaude Code Bedrockセットアップ、Google Cloud's Agent Platform単体はClaude Code Vertex AIセットアップで個別に扱っています。

よくある質問

3つのプロバイダーを同時に使い分けることはできますか

できます。with:ブロックの入力(use_bedrock / use_vertex / use_foundry)はワークフローファイル単位で指定するため、リポジトリごと・ワークフローごとに異なるプロバイダーを設定できます。同一ワークフロー内で条件分岐して切り替える場合は、シークレット名が重複しないよう管理します。

公式Claude GitHub Appを使う場合、ワークフローの何を変えればいいですか

「GitHub App tokenを生成するステップ」とgithub_tokenの行を削除するだけです。認証ステップやクラウドプロバイダーの入力(use_bedrock等)はそのまま使えます。

GITHUB_TOKENを使うと何が制限されますか

このトークンで作成したコミットやコメントは、他のGitHub Actionsワークフローの起動条件(on: push等)を満たしません。Claude Codeが作ったPRに対して別のCIワークフローを自動起動したい場合は、公式アプリかカスタムアプリを使います。

モデルIDはどう指定しますか

Bedrockはクロスリージョン推論プロファイルのプレフィックス(us.等)付きのモデルIDを、Google Cloud's Agent PlatformとMicrosoft Foundryはそれぞれのモデル名をclaude_argsの--modelに指定します。Foundryはリソースにデプロイしたモデル名と一致させる必要があります。