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の新規契約なしに動かせます。この連携が置き換えるのはAPI認証の部分だけです。APIキーで始める導入はClaude CodeをGitHub Actionsに組み込むにあります。

設定は4か所に分かれる

先に必要なものは3つあります。

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

Amazon Bedrockでクロスリージョン推論プロファイル(us.プレフィックスの付いたモデルID)を使う場合は、そのリージョングループの全リージョンでアクセス権が必要です。

コミットとコメントの名義をどのGitHubアイデンティティにするか

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

カスタムGitHub Appを作る場合はwebhookを無効にして登録し、Contents・Issues・Pull requestsを読み書き権限で付与します。秘密鍵(.pem)をダウンロードしてApp IDを控え、対象リポジトリにインストールします。

公式Appを選ぶなら、ワークフローから「GitHub App tokenを生成するステップ」とgithub_tokenの行を削ります。GITHUB_TOKENを選ぶなら、生成ステップを削ってgithub_token: ${{ secrets.GITHUB_TOKEN }}に書き換えます。

クラウド側で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
• aws-marketplaceのサブスクリプション操作2つ(ViewSubscriptionsとSubscribe)

GetInferenceProfileを外しても動きますが、モデルごとに1回余計な往復が発生します。アプリケーション推論プロファイルのARNを基盤モデルに解決できないと、Claude Codeが別のリクエスト形式で再試行するためです。

この記事の連携では、ロールのARNが後でシークレットAWS_ROLE_TO_ASSUMEの値になります。

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の3つがシークレットの値です。

信頼条件のsubjectは、リポジトリの作成時期で形式が変わる

3プロバイダーの信頼条件はどれも、GitHubのOIDCトークンのsub(subject)クレームを照合します。Claude Codeのドキュメントの例はrepo:your-org/your-repo:*です。この形式は、GitHubのドキュメントでは以前の形式(previous format)と呼ばれています。

GitHubのOIDCドキュメントによると、2026年7月15日より後に作ったリポジトリと、オプトインしたリポジトリは「不変subject」に切り替わります。この日付以降のリポジトリ名の変更や移管も対象です。書式は次のとおりです。

名前の後ろに、オーナーIDとリポジトリIDが@で付きます。2026年7月15日より前に作ったリポジトリは、オプトインしない限り旧形式のままです。GitHub Enterprise Serverは不変subjectの対象外です。

形式が違えば信頼条件の文字列も変わるので、リポジトリの作成時期と設定を見てから条件を書きます。イベントごとにも違いがあります。pull_requestイベントでは:pull_requestが付き、環境を使うジョブでは:environment:名前が付きます。ブランチ名が入るのは、環境を使わず、pull_requestでもない場合です。

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

クラウド側で得た値を、リポジトリシークレットに追加します。

ワークフローファイルのpermissionsにはid-token: writeを必ず含めます。これがないとGitHubがOIDCトークンを発行しません。あわせてcontents / pull-requests / issuesのwriteも付けます。

プロバイダーごとに違うのは、認証ステップと、anthropics/claude-code-actionに渡す入力です。Amazon Bedrockの場合はこうなります。

- 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'

aws-regionの値はAWS_REGIONとして後続のステップに引き継がれるので、Bedrock側にリージョンを別途書く必要はありません。

Google Cloud's Agent Platformならgoogle-github-actions/auth@v2(ステップIDauth)で認証し、use_vertex: "true"と次のenv:を加えます。プロジェクトIDはauthステップの出力から読むので、直書きしません。

- 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ならazure/login@v2で認証し、use_foundry: "true"と次のenv:を加えます。

- 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

ANTHROPIC_FOUNDRY_RESOURCEにはFoundryリソース名をそのまま指定します。Claude CodeがこのリソースからエンドポイントURLを組み立てるため、URLを別途指定する必要はありません。モデル名は、Foundryリソースにデプロイ済みのClaudeモデルと一致させます。

保存したら、対象リポジトリのissueかPRで@claudeをメンションしたコメントを投稿して動作を確かめます。リポジトリのActionsタブで実行が始まり、しばらくすると同じissueかPRにClaude Codeからの返信が付きます。--max-turnsをclaude_argsに足せば、どのプロバイダーでも実行時間とコストの上限を設けられます。

認証が通らないときの切り分け

認証エラーの大半はOIDC設定の食い違いです。次の順に見ます。

• id-token: write権限が付いているか
• 信頼ポリシーのリポジトリ条件が、実際のリポジトリのsubと一致しているか(上の不変subjectを含む)
• ワークフロー内のシークレット名と、追加したシークレット名が同じか

ワークフローが起動しない、応答が返らないといったトリガーやCIの問題は、Claude APIを直接呼ぶ場合と同じ挙動です。クラウド認証とは別に調べます。

anthropics/claude-code-actionのissueに出ている症状

claude-code-actionのリポジトリには、クラウド経由に特有の報告がいくつかあります。症状が一致したときの手がかりになります。

• OIDCは成功するのにBedrockの認証が失敗する: issue #1090(2026年3月報告)では、AWSの認証ステップが成功しAWS_ACCESS_KEY_IDなどの環境変数も見えているのに、API Error: Could not load credentials from any providersでClaude Codeが即座に失敗しています。トークン消費は0で、報告者はv1.0.74とv1.0.75のリリースの時期に合致したと書いています。v1.0.90でのBedrock認証の不具合はclaude-code-actionのBedrock認証が壊れたv1.0.90の不具合と対処法にあります
• au.プレフィックスのモデルIDが拒否される: issue #1403(2026年6月報告)は、オーストラリア域内に閉じたクロスリージョン推論プロファイル(au.anthropic.…)を、actionに同梱のSDKが拒否すると報告しています。データ所在地の要件でus.以外のプレフィックスを使う構成では、実行前に小さなワークフローで拒否されないかを試してください
• Foundryのリソースが見つからない: issue #816(2026年1月報告)では、ANTHROPIC_FOUNDRY_BASE_URLをhttps://my-resource.services.ai.azure.comに設定すると「resource not found」になり、末尾に/anthropicが必要だと指摘されています

最後の症状には、公式ページ同士の食い違いが絡みます。Claude CodeのドキュメントはANTHROPIC_FOUNDRY_RESOURCEにリソース名を渡す方式です。actionのリポジトリのdocs/cloud-providers.mdはANTHROPIC_FOUNDRY_BASE_URLを使う例で、末尾に/anthropicがありません。モデル名の例も、前者はclaude-sonnet-5やus.anthropic.claude-sonnet-4-6、後者はclaude-sonnet-4-5などの旧い名前です。この記事のワークフローは前者に合わせています。

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

OIDCを前提にできない環境の扱い

actionのリポジトリのドキュメントには、Bedrock・Vertex・FoundryがOIDC認証だけを使うと書かれています。

issue #577(2025年9月報告)は、ここに起因する壁を挙げています。インターネットに公開できない自己ホストのGitHub Enterprise Server(GHES)では、AWS側がOIDCエンドポイントに到達できないため、Bedrock経由で使えないという指摘です。アクセスキー対応の要望として起票されています。

GHESでは/install-github-appコマンドがgithub.com専用なので、ワークフローファイルは上記の手順で手動作成します。管理者側の準備はGitHub Enterprise ServerでClaude Codeを使うにあります。GHESは前述の不変subjectの対象外なので、信頼条件は旧形式で書きます。

まとめ

書き始める前に決めるのは、2つです。リポジトリが2026年7月15日より後の作成かGHESかで信頼条件のsubの書式が決まり、すでにモデルアクセス権と管理体制があるクラウドでプロバイダーが決まります。Bedrock単体のセットアップはClaude Code Bedrockセットアップ、Google Cloud's Agent Platform単体はClaude Code Vertex AIセットアップにあります。