claude-code-actionでAJV検証エラーが起きたときの切り分け方

このTipsでできること

anthropics/claude-code-action@v1を使ったPRレビューが、実行開始から数十秒で失敗することがあります。ログにはSDK execution errorという文字列と、AJVというライブラリのコード断片が含まれます。このエラーは2026年1月以降、GitHub Issueで複数の開発者が報告してきましたが、原因は1つに固定されていません。この記事では報告された3つの状況を整理し、実際に効果があったと報告されている回避策を紹介します。

どんなエラーが出るか

失敗したランは、次のような短い結果と例外を残します。

{
  "type": "result",
  "subtype": "success",
  "is_error": true,
  "duration_ms": 261,
  "num_turns": 1,
  "total_cost_usd": 0,
  "permission_denials": []
}

SDK execution error: 14 |     depsCount: ${Q},
15 |     deps: ${$}}`};var Mj={keyword:"dependencies",type:"object",schemaType:"object", ...
error: Claude Code process exited with code 1
      at $ (.../node_modules/@anthropic-ai/claude-agent-sdk/sdk.mjs:19:7668)

duration_msは261ミリ秒、total_cost_usdは0です(単位はドル)。この2つの値から、モデルへのAPIリクエストが発生する前に処理が止まっていることが分かります。num_turns: 1は、SDKが最初のターンを試みた直後に例外を投げたことを示しています。

スタックトレースに出てくるkeyword:"dependencies"という文字列があります。これはAJV(JSON Schemaの定義に基づいてデータを検証するJavaScriptライブラリ)が持つ、dependenciesキーワードの検証コードです。claude-code-actionは内部で@anthropic-ai/claude-agent-sdkというnpmパッケージを使っており、このAJVはSDKにバンドルされた状態で動いています。参照先のファイルパスnode_modules/@anthropic-ai/claude-agent-sdk/sdk.mjsからも、SDK本体がminify済みのJavaScriptとして配布されていることが分かります。変数名が1〜2文字に圧縮された状態のまま例外メッセージに出るため、読みにくいログになります。

元の報告では、アップデート前(SDK 0.2.9)の成功したランは3分53秒かかっていましたが、アップデート後(SDK 0.2.15)の失敗したランはわずか26秒で終わっています。処理時間のこの落差自体が、実際のレビュー作業を何も行わずに早期終了していることを示す傍証です。同じPRの差分に対して、更新前は数分がかりで読み込んで応答していたのに、更新後は数十秒で例外を投げて終わるという対比は、原因がコードレビューの内容側にはないことを裏付けます。

原因は一つに固定できない — 報告された3つの状況

Issueのコメント欄を追うと、同じ見た目のクラッシュが異なる状況で発生していたことが分かります。

元の報告はubuntu-latestのランナー、claude-sonnet-4-5-20250929モデルで発生していますが、別の報告者はmacOS(arm)ランナーでも同じクラッシュに遭遇しています。特定のOSやモデルの組み合わせに限定された現象ではないため、切り分けの起点としては優先度が低い項目です。

3つの状況に共通しているのは、クラッシュのログ表示がほぼ同じに見える点です。しかし2番目の状況は、実際には認証エラーが真因でした。スタックにAJVのコード片が表示されるのは、例外が発生した行の周辺にあるminify済みコードがそのまま出力されているためで、AJVの検証処理そのものが失敗の引き金かどうかはIssue内でも確定していません。

一方で、別の開発者はclaude_code_oauth_tokenが公式ドキュメントに有効な入力として明記されている点を指摘しています。認証方式を変えるだけで直るなら、それ自体が入力ミスではなくバグではないかという疑問です。認証方式の切り替えが自分の環境でも同じように効くとは限りません。

Issueには、この現象を自社の環境では再現できていないという返信も記録されています。報告者はその後、workflow_dispatchだけで動く最小構成のワークフローを作り直しました。チェックアウトとclaude_code_oauth_tokenを渡すステップだけの構成でも、同じクラッシュが起きたと追加で示しています。複雑な独自設定が原因ではなく、ごく単純な構成でも再現する一方、開発元の環境では再現しなかったという食い違いがあります。環境固有の何らかの条件が引き金になっている可能性を示していますが、Secretsの値か組織の設定かまでは、Issue内でも特定されていません。

SDKのバージョンを戻すだけでは直らないことがある

最初に試したくなる対処は、SDKやアクションのバージョンを固定して以前の状態に戻すことです。しかし報告を見る限り、この方法は確実ではありません。

• SDKが^0.2.9を指定する古いアクションバージョン(v1.0.30)にピン留めしたが、別の例外が発生したという報告
• 直近の2つのリリースを順に試したが、LinuxとmacOS(arm)のどちらでも解消しなかったという報告
• SDK0.2.31を含む新しいリリースでも再発したという報告

バージョンの前後だけで切り分けるより、まず自分の環境で実際に何が起きているかをログのduration_msとtotal_cost_usdから確認するほうが近道です。

実際に効果があったと報告されている回避策

複数の対処が試された中で、Claude Code CLIの実行バイナリ自体を固定する方法が有効だったという報告が残っています。claude-code-actionが自動インストールするバイナリを使わず、path_to_claude_code_executableパラメータで自分がインストールした特定バージョンを指す方法です。この報告は2026年2月に投稿されたもので、当時使われたのは@anthropic-ai/claude-code@2.1.18でした。

- name: Install a pinned Claude Code version
  run: |
    sudo rm -f /usr/local/bin/claude
    npm install -g @anthropic-ai/claude-code@<動作確認済みのバージョン>
    CLAUDE_BIN=$(which claude)
    echo "CLAUDE_PATH=$CLAUDE_BIN" >> $GITHUB_ENV
 
- name: Run Claude Code Action
  uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.key }}
    path_to_claude_code_executable: ${{ env.CLAUDE_PATH }}

path_to_claude_code_executableは、アクションによる自動インストールをスキップし、指定した実行ファイルをそのまま使うためのオプションです。アクションが内部でバンドルするSDKのバージョンではなく、npmで個別にインストールしたClaude Code CLI自体のバージョンを固定する点が、SDKバージョンだけを戻す対処と違います。アクションパラメータ全体の一覧はGitHub ActionsのパラメータとCLI引数をClaude Codeで渡すにまとめています。

この方法にはトレードオフもあります。アクション側の自動バージョン管理を経由しなくなるため、claude-code-actionが将来のリリースでSDKや実行バイナリ側の不具合を直しても、ピン留めしたバージョンには反映されません。2026年2月の報告時に使われた2.1.18をそのままコピーすると、それ以降にリリースされた新機能や修正を受け取れなくなります。固定する番号は2.1.18を流用せず、自分の環境で動作確認が取れた比較的新しいバージョンを選び、ワークフローにそのバージョン番号を書いたコメントを添えて、数か月おきに新しいバージョンで動作確認する運用にしておくと、ピン留めしたまま放置される事態を避けやすくなります。

認証方式を切り替える前に確認しておきたいこと

claude_code_oauth_tokenとanthropic_api_keyはどちらもclaude-code-actionが受け付ける認証方式です。切り替えて解決したという報告がある一方、どちらの方式でも同じエラーに遭遇したという報告も残っています。切り替え自体を最初の対処にするより、まずどちらの認証方式を使っているかをwith:ブロックで確認し、実際にAPIへのリクエストが届いているかを見るほうが確実です。

APIキー自体が有効かどうかは、ワークフローを介さずローカルの端末で単体で確かめられます。Issueの中でも、ANTHROPIC_API_KEYを使ってapi.anthropic.com/v1/messagesへ直接curlする検証方法が使われています。

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-sonnet-4-20250514","max_tokens":100,"messages":[{"role":"user","content":"Hello, Claude!"}]}'

この報告では、無効なキーではauthentication_errorが返り、Consoleで発行し直した有効なキーに差し替えると正常な応答に変わりました。ワークフロー上のクラッシュがAJVのスタックトレースで覆い隠されていても、キー自体の有効性はこの単体確認で切り分けられます。ワークフロー内のSecretsに登録した値と、手元でcurlに使った値が本当に同じ文字列かどうかも、コピー漏れや改行混入がないかという観点で見ておくと取りこぼしがありません。

Claude Code CLI本体のログイン単位の認証エラー(OAuth token revoked等)とは発生の経路が異なるため、区別して考える必要があります。ローカルの再ログインで直る種類のトラブルは「OAuth token revoked」の対処にまとめています。導入自体の認証設定を見直す場合はClaude CodeをGitHub Actionsに組み込むを参照してください。

Issueの扱われ方

このIssueにはbug p1 area:installation provider:1pというラベルが付いています。p1は優先度の高いバグを示すラベルで、軽微な扱いではないことが分かります。ただしコメント欄を見る限り、原因は複数の要因が絡んでおり、1つの修正で全ての報告が解消するとは限らない状態です。

JSON Schemaまわりのエラーは--json-schemaフラグ経由でも別の形で発生することがあり、そちらの3段階チェックの仕組みはClaude Code --json-schemaエラーの直し方にまとめています。

まとめ

claude-code-actionの実行が数十秒で失敗し、ログにAJVのdependenciesキーワードに関するスタックトレースが出る場合、原因は1つに決め打ちできません。GitHub Issueの報告を追う限り、SDKバージョンの更新そのものが引き金になったケース、実際には認証エラーが真因だったケース、SDKを最新化しても再発したケースの3つが混在しています。

SDKバージョンを戻すだけの対処は効果が確実ではなく、Claude Code CLIの実行バイナリ自体をpath_to_claude_code_executableで固定する方法が有効だったと報告されています。ランナーの種類やモデル指定を変えても再現する報告があるため、切り分けの起点は認証とバージョンの組み合わせに絞るのが現実的です。