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ヘッダーに送られたことです。

同じ時期にBedrockの403は別の原因でも出ており、changelogを見て「直った」と思い込むと切り分けを誤ります。本記事は、v1.0.90の症状・原因・当時の対処と、似たBedrock 403との見分け方を扱います。

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

2026年4月8日、anthropics/claude-code-actionのv1floatingタグが新しいコミットへ移りました。内部で使うClaude CodeとAgent SDKがバンプされた更新です。この更新以降、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認証情報を取得している

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

Claude Codeの公式ドキュメントのクラウドプロバイダー向けトラブルシューティングは、認証エラーを「通常はOIDCの設定ミス」とし、id-token: write権限・信頼設定のリポジトリ条件・シークレット名の3点を見るよう案内しています。今回の失敗はこの3点が正しくても起きました。configure-aws-credentialsが通っているのにClaude Codeの起動段階で403になるなら、設定ではなくバージョンを疑う順序になります。

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

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

v1.0.90のリリースノートにこのリグレッションへの言及はありません。issueでも、リリースノートが触れていない同梱のClaude Code / Agent SDKのバンプが原因らしいと書かれています。ランナーのログには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タグを使っていて、その時間帯以降に初めて失敗が始まっているなら、この不具合に該当していた可能性が高いといえます。

当時の対処と今できること

issueは同じ4月8日のうちにクローズされ、現在@v1を使っていれば通常この症状には当たりません。当時の対処は次の流れでした。

ピン留めしたワークフローの該当行は次のようになります。

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

ローカルやセルフホストランナーで直接Claude Codeを更新するときのコマンドはこちらです。

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

v2.1.289のclaude update --helpは、説明がCheck for updates and install if availableの1行で、オプションは-h, --helpだけです。バージョンを指定して更新するフラグはないため、特定バージョンへ固定したいときは上のnpmの書き方でバージョン番号を付けます。

同じBedrockの403でも原因が3種類ある

2026年4月のchangelogには、Bedrockの403を直したエントリが複数あります。エラー文言が似ていても、条件と修正版が違います。

2.1.96のchangelogだけを読んで「Bedrockの認証問題は直った」と判断すると、claude-code-actionのOIDC構成では失敗が続きます。issue #1193は、Bedrock APIキーもスキップフラグも使わない構成での失敗だからです。

claude-code-actionのv1.0.91とv1.0.94のリリースノートはpinされたbunバイナリとPATH設定の話です。v1.0.92とv1.0.93には変更点の記載自体がなく、どれもこの修正には触れていません。2.1.97の修正が実質的な恒久対応だったと考えられます。

GitHub Actionsは未設定のinputに空文字列を渡します。issue #1193の構成でもAWS_BEARER_TOKEN_BEDROCKなどが空文字列になっていた可能性があり、changelogの記載がその状況を名指ししています。

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

anthropics/claude-code-action@v1のようなfloatingタグは、パッチバージョンが上がるたびに自動で追随します。今回はそのバンプに同梱されたClaude Code / Agent SDKの更新でBedrock連携のワークフローが軒並み壊れ、アクション自身のリリースノートにも変更内容が書かれていませんでした。

本番運用のワークフローで再現性を優先するなら、具体的なパッチバージョンへ明示的にピン留めし、更新は動作確認をしたうえで手動で上げる運用が選択肢になります。floatingタグのままだと、同梱ランタイムの変更を検知する手段が、実際にワークフローが失敗するまで無い状態になります。

まとめ

Bedrockの403は、エラー文の欠け方で型を見分けられます。Credential・Signature・SignedHeadersが無いという文言なら本記事の型で、Authorization header is missingならAWS_BEARER_TOKEN_BEDROCK系の別の不具合です。型が決まれば、見るべき修正版も2.1.97か2.1.96かと決まります。

認証エラー全般の切り分けはAWS authentication failedの原因と対処、IAM権限の設計はClaude Code Bedrock IAM設定とクロスリージョン推論プロファイルの組み方で扱っています。GitHub Enterprise Server環境固有の既知issueはsetup-bunがGHESで壊れたv1.0.42の不具合にあります。