claude-code-actionのBedrock認証が壊れたv1.0.90の不具合と対処法

anthropics/claude-code-action を @v1 のfloatingタグで使っているGitHub Actionsワークフローで、Amazon Bedrock経由の認証が突然403エラーで失敗する不具合が2026年4月8日に発生しました。原因はv1.0.90へのバンプで、AWS SigV4署名の代わりに素のbase64文字列がAuthorizationヘッダーに送られたためです。本記事ではこの既知issueの症状・原因・対処を扱います。同時期にはAWS_BEARER_TOKEN_BEDROCK構成を対象にした別のBedrock認証リグレッション(2.1.94由来)もありましたが、原因も対象範囲も本件とは別物です。

claude-code-actionのv1.0.90で何が起きたか

2026年4月8日04:43 UTC、anthropics/claude-code-actionのv1floatingタグがコミット26ddc358に更新され、内部で使うClaude Codeが2.1.96、Agent SDKが0.2.96にバンプされました。この更新以降、use_bedrock: "true"を指定しOIDC経由でAWS認証情報を取得しているワークフローが軒並み403エラーで失敗するようになりました。

Bedrock連携そのものの一般的なセットアップ手順(GitHubアプリの選び方、OIDC信頼関係の作り方、リポジトリシークレットの設定)はGitHub Actions Bedrock連携にまとめています。本記事はv1.0.90に限定した既知の不具合の記録です。

エラーメッセージと発生条件

報告されたエラーはこの内容です。

Failed to authenticate. API Error: 403 Authorization header requires 'Credential' parameter.
Authorization header requires 'Signature' parameter.
Authorization header requires 'SignedHeaders' parameter.
(Hashed with SHA-256 and encoded with Base64) Authorization=cQ4NvdQimYUQF6TWcmXs0EbxtO23QVJZkqGmqPqAElg=

発生条件は次の3点がそろったワークフローです。

• anthropics/claude-code-action@v1(floatingタグ)を使っている
• use_bedrock: "true"を指定している
• aws-actions/configure-aws-credentialsでOIDCからAWS認証情報を取得している

self-hosted runner(EKS上のものを含む)で報告があり、auto-triageやcode-reviewなど複数のワークフロー種別で同じ症状が確認されています。AWS認証情報を取得するconfigure-aws-credentialsのステップ自体は成功しており、そのあとClaude Codeを起動する段になって失敗する点が切り分けの手がかりになります。

原因 — Bedrock向けクライアントが選ばれなかった

エラートレースにはnew Anthropic({ apiKey, dangerouslyAllowBrowser: true })という初期化行が含まれており、use_bedrock: "true"が指定されているにもかかわらず、Bedrock専用クライアントではなく通常のAnthropicクライアントが使われていたことを示しています。通常のクライアントはAPIキーをそのままAuthorizationヘッダーに載せる方式のため、AWS SigV4形式の署名(AWS4-HMAC-SHA256 Credential=... Signature=... SignedHeaders=...)が組み立てられず、Bedrock側が403で弾いていました。

v1.0.90自体のリリースノートには「MCP_TIMEOUT / MCP_TOOL_TIMEOUT / MAX_MCP_OUTPUT_TOKENSをアクションのステップへ転送するfix」と「制御文字を含むPATH_TO_CLAUDE_CODE_EXECUTABLEを拒否するsecurity修正」の2件しか書かれておらず、このリグレッションの直接の言及はありません。バンプ先のClaude Code 2.1.96 / Agent SDK 0.2.96のどちらかにこの挙動が混入していたと見られます。issueのAdditional contextによれば、ランナーのログにはANTHROPIC_API_KEYが空欄として表示されますが、これはBedrockモードでは想定どおりの状態であり原因ではありません。空欄表示を見て通常のAPIキー設定の問題だと誤解し、切り分けが遠回りになりやすい点には注意が必要です。

自分のワークフローが対象だったか確認する

過去にこの症状に当たったかどうかは、次の2点で確認できます。

• ワークフローファイル(.github/workflows/*.yml)でanthropics/claude-code-actionの行を探し、@v1のようなfloatingタグを指定しているか、@v1.0.89のような具体的なパッチバージョンを指定しているかを確認する
• リポジトリのActionsタブで、2026年4月8日04:59 UTC以降に実行されたBedrock連携ワークフローの履歴を見て、それより前は成功していたのに突然403で失敗し始めていないかを確認する

floatingタグを使っていて、かつ上記の時間帯以降に初めて失敗が始まっているなら、この不具合に該当していた可能性が高いといえます。

今からできる確認と対処

この不具合は2026年4月8日のうちにissueが起票・クローズされており、原因はすでに修正済みです。現在@v1を使っていれば、通常はこの症状には当たりません。当時のワークフローで案内された対処は次の2つでした。

1. 暫定回避: anthropics/claude-code-action@v1.0.89のように直前のパッチバージョンへ明示的にピン留めする
2. 恒久対応: Claude Code本体を2.1.97以降に上げる

2番目は、@v1のようなfloatingタグを使っていれば、同梱のClaude Codeが更新されると自動的に追随します。ローカルやセルフホストランナーで直接Claude Codeを更新する場合のコマンドはこちらです。

claude update
# またはnpmでのインストールなら
npm i -g @anthropic-ai/claude-code@latest

暫定回避としてバージョンをピン留めする場合、ワークフローファイルの該当行は次のようになります。

- name: Run Claude
  uses: anthropics/claude-code-action@v1.0.89
  with:
    use_bedrock: "true"
    github_token: ${{ secrets.GITHUB_TOKEN }}

古いパッチにピン留めしたまま長期間放置すると、今度は別の修正が反映されなくなります。回避策として固定した場合は、2.1.97以降を含むバージョンへ戻す作業を後日のタスクとして残しておくのが安全です。

2.1.96の公式な修正内容とは別物

Claude Codeの公式changelogには、2.1.96のエントリとして次の記載があります。

Fixed Bedrock requests failing with 403 "Authorization header is missing" when using AWS_BEARER_TOKEN_BEDROCK or CLAUDE_CODE_SKIP_BEDROCK_AUTH (regression in 2.1.94)

これは2.1.94で混入した別のリグレッションで、AWS_BEARER_TOKEN_BEDROCK(Bedrock APIキーによる認証)やCLAUDE_CODE_SKIP_BEDROCK_AUTHを使う構成が対象です。詳細はAWS_BEARER_TOKEN_BEDROCKとはやClaude Code v2.1.96で扱っています。

今回のissue #1193はこの2.1.96の修正が対象にしていた症状とは条件が異なります。OIDC経由でAWS認証情報を取得し、SigV4署名によるIAMロール認証を使う構成での失敗であり、Bedrock APIキーもスキップフラグも関係していません。2.1.96のchangelogだけを読んで「Bedrockの認証問題は直った」と判断すると、claude-code-actionのOIDC構成では実際にはまだ失敗する状態が続いていた点に注意が必要です。claude-code-actionのv1.0.91〜v1.0.94のリリースノートにはこの修正への言及がありません。一方でClaude Code本体の2.1.97のchangelogには「Fixed Bedrock SigV4 authentication failing when AWS_BEARER_TOKEN_BEDROCK or ANTHROPIC_BEDROCK_BASE_URL are set to empty strings (as GitHub Actions does for unset inputs)」という記載があります。GitHub Actionsが未設定のinputに空文字列を渡す状況を明示的に扱っており、issue #1193のOIDC構成でもこれらの変数が空文字列になっていた可能性があるため、この記載が実質的な恒久修正だったと考えられます。

floatingタグを使う運用へのリスク

anthropics/claude-code-action@v1のようなfloatingタグは、パッチバージョンが上がるたびに自動で追随します。今回のケースでは、そのパッチバンプに同梱されたClaude Code / Agent SDKの更新が原因でBedrock認証全体が壊れ、しかもアクション自身のリリースノートにはその変更内容が書かれていませんでした。本番運用のワークフローで再現性と挙動の予測可能性を優先するなら、具体的なパッチバージョンへ明示的にピン留めし、更新は動作確認をしたうえで手動で上げる運用が選択肢になります。逆にfloatingタグのままにしておくと、今回のような同梱ランタイムの変更を検知する手段が、実際にワークフローが失敗するまで無い状態になります。

まとめ

claude-code-action v1.0.90へのバンプは、内部のClaude Code 2.1.96 / Agent SDK 0.2.96への更新を通じて、OIDC経由のBedrock認証をSigV4署名なしの状態にし、403エラーを引き起こしました。issueは、2.1.97での解消が案内されたコメントとともに同日中にクローズされました。現在@v1を使っていれば通常この症状には当たりませんが、古いパッチに手動でピン留めしたままのリポジトリが残っていないかは確認する価値があります。Bedrock連携の一般的なセットアップ手順はGitHub Actions Bedrock連携、認証エラー全般の切り分けはAWS authentication failedの原因と対処、IAM権限の設計はClaude Code Bedrock IAM設定とクロスリージョン推論プロファイルの組み方で扱っています。