Claude Codeが独自APIで400になる：Artifactスキーマとバージョンを確認

更新後にClaude Codeが毎ターン失敗し、エラーにArtifactツールの入力スキーマ内の不正な正規表現が示されている場合は、APIキーやモデルを変える前にクライアントのバージョンを確認します。公式リポジトリのユーザー報告 #92969では、2.1.265と2.1.266でUnicodeプロパティエスケープを含むスキーマのpatternが厳格なバリデーターに拒否される問題が報告されています。

これは特定の過去の互換性問題です。すべてのHTTP 400の原因でも、現行クライアント全体で未修正の問題でもありません。公式変更履歴では、他社エンドポイント向けの修正が2.1.268に記載されています。

先にエラーの内容を照合する

確認の手掛かりは、対象バージョンへの更新後に始まったこと、他社のAnthropic互換エンドポイントを使っていること、エラーがArtifactのスキーマや「not a regex」とされるpatternを指していることです。メッセージの表現はバリデーターによって異なります。

スキーマの拒否はモデルが回答する前に起こります。そのため、複雑なコーディング依頼を挨拶に変えても同じエラーが出る場合があります。モデル自体の故障を意味するわけではなく、リクエストに含まれるツール定義が拒否されている可能性があります。

この表は調査先を整理するもので、自動的に原因を確定するものではありません。機密情報を除いた完全なエラーを保存し、フィールドのパスを元の報告と照合します。一件の拒否を理由に無関係な保護設定を外したり、すべてのツールスキーマを書き換えたりしないでください。

実際に動いている版を調べる

まずコマンドの出力を確認します。

claude --version

端末、IDE、バックグラウンドワーカーを使う場合は各環境を確認します。別のインストールが動いていることがあります。通常の方法で更新し、該当クライアントやワーカーを再起動してから再度バージョンを確認してください。

2.1.268は修正を含む過去の版であり、新しいサポート対象版からダウングレードする推奨ではありません。組織でサポートする現行版を使います。意図的に影響のある版へ固定しているなら、その固定も診断対象として通常の更新手順に従います。

更新が必要なのは、リクエストを組み立てるクライアントです。手元の別端末だけを更新しても、別途デプロイされたワーカーは変わりません。失敗したリクエストと再テストを送ったプロセスを記録します。

影響を受けたクライアントを復旧する手順

まず失敗したリクエストの UTC 時刻、エラー全文、クライアントのバージョンを保存します。自動再試行するジョブなら通常の操作で一時停止してください。同じ拒否済みスキーマを送信し続けても原因の切り分けにはなりません。作業フォルダーと会話は残します。削除は証拠を失ううえ、公式に記載された修正方法でもありません。

macOS/Linux では、次のコマンドで実行ファイルの場所とインストール状態を調べられます。モデルへのリクエストは送りません。

command -v claude
claude --version
claude doctor

Windows PowerShell では場所の確認に Get-Command claude を使い、その後に同じ version と doctor コマンドを実行します。確認した場所が実際に失敗した環境と一致するか見てください。ターミナル側を更新しても IDE に古いプロセスが残る場合があります。リモート開発コンテナーにも別のインストールや固定バージョンがあり得ます。

そのインストールを管理する方法で更新します。公式セットアップガイドでは、対応する自己管理インストールに claude update を案内しています。Homebrew ならインストール済みの cask を、たとえば brew upgrade claude-code で更新します。組織管理の環境は承認済みの更新経路を使ってください。複数のパッケージマネージャーを続けて使うと、別のコピーだけが増え、問題のプロセスが変わらないことがあります。

更新後は対象クライアントを終了して開き直し、その環境でもう一度 claude --version を実行して記録します。次の要求が別のバイナリーから送られるなら、「更新完了」の表示だけでは不十分です。必要なのは 2.1.268 の修正を含むサポート対象版であり、その古い版に戻すことではありません。

長いタスクを再開する前に一件を再テストする

最初は提供者とモデルを変えず、影響のないタスクで元の拒否が残るか調べます。更新後に成功すれば、その構成では診断を支持する結果になりますが、提供者の全機能を保証するものではありません。

続いて対象のツール処理を試します。テキスト応答だけでは同じツールの流れを確認できません。クライアント版、ルート、実行時刻、機密情報を除いたエラー、リクエストIDを残します。現行版でも拒否される場合は、新しいエラーのフィールドを確認し、同じ過去の不具合と決めつけないでください。

本記事は上流のIssueとリリース記録に基づいています。Ofoxの本番環境で再現した、複数ゲートウェイで成功率を測った、という主張はしていません。

二段階で確認し、それぞれの合格条件を分ける

最初は同じ設定で短いテキスト応答を求めます。これはモデルを呼び出すため、利用枠の消費やプロバイダー料金が発生する可能性があります。次は診断用の例です。比較しやすいよう固定の英文を返させます。

Reply with exactly: connection check
Do not modify files or run commands.

期待するのは、元の Artifact スキーマ拒否ではなく通常のアシスタント応答です。指定文字列の一致は応答処理の確認であり、コーディング能力の評価ではありません。別のエラーが出たら分けて保存します。検証の次段階まで進んだ可能性はありますが、完全な復旧とは限りません。

次に、機密情報のない sample.txt を一時フォルダーに置き、編集せず最初の一行だけ読むよう依頼します。実際のファイルと回答を照合し、ツールの結果も確認してください。通常の設定に組み込み Artifact 定義が含まれるなら、その設定を維持します。無効にすると同じリクエスト構築の再試験になりません。

これらは実施を勧める確認であり、当方のアカウントで得た結果ではありません。スキーマ拒否がなくなり、必要なツールのやり取りも完了してから長い作業を再開します。接続確認だけのために実プロジェクトの編集やデプロイを依頼しないでください。

「Anthropic互換」だけでは十分でない理由

認証、メッセージ構造、ストリーミングが互換でも、受け付けるJSON Schema機能は異なる場合があります。報告された問題は、組み込みツール定義のpatternを検証器がどう扱うかという問題であり、モデルのコード推論能力とは別です。

生成された正規表現を不用意に修正したり、本番の検証を無効化したりしないでください。意図しない値を受け入れたり、別の互換性問題を隠したりする恐れがあります。まず上流のクライアント修正を適用し、残る問題は機密情報を除いた最小例で提供者に伝えます。

報告には拒否された構文を示す最小のスキーマ断片を使い、非公開プロジェクトのプロンプト全体は送らないでください。ソースコード、環境変数、会話履歴を渡さなくても検証器の調査に必要な情報を提示できます。

JSON の解析成功と正規表現の検証成功は別

JSON として正しくても、JSON Schema の pattern が特定のバリデーターと互換でない場合があります。次は説明用の簡略例で、上流のツール定義全体ではありません。

{"type":"string","pattern":"^[\\p{L}]+$"}

JSON パーサーが得るのは、バックスラッシュと p{L} を含む文字列です。それを正規表現として解釈する処理は別で、Unicode プロパティの扱いはエンジンとモードによって変わります。そのためローカルで JSON を解析できても、プロバイダーが pattern を受理する証明にはなりません。

.* への置換は同等の修正ではありません。受け付ける値の範囲まで変わります。ツール全体の削除もクライアントの機能を変えます。上流のクライアント修正が自分の設定に効くか確かめるだけなら、どちらも不要です。ゲートウェイ管理者はステージング用の例で検証失敗を再現し、正規表現エンジンと版を記録してください。一つの過去の要求のために本番全体のスキーマを緩めるべきではありません。

残った問題だけを最小構成で報告する

報告は、更新前後の版、エンドポイントの種類、モデル、拒否されたフィールドのパス、UTC 時刻、プロバイダーのリクエスト ID、短文テスト、読み取り専用ツールテストの結果を一画面程度にまとめます。スキーマ片は必要とされた場合に添付します。トークン、非公開プロンプト、リポジトリのパス、検証に不要なファイル内容は削除してください。

更新で Artifact エラーが消え、今度はツール結果が失敗するなら、記事末尾の tool-result または thinking-signature のガイドに進みます。同じ pattern が拒否されるなら、実際にバリデーターに届いたスキーマと、プロキシや worker に旧クライアントが残っていないかを確認してもらいます。現行版の最小再現でも失敗するなら証拠を残して上流に報告し、すべての 400 をこの回帰として扱わないでください。

復旧の完了条件は、意図したクライアントが修正済みの要求を意図した経路に送り、無害なツール作業に成功することです。すべてのモデルやプロバイダー機能を検証したという意味ではありません。

他の400エラーとは分ける

tool_result不足のガイドは中断や不正なツール交換を、thinking署名のガイドはメッセージ保持に関する別の問題を扱います。エラーの根拠が一致しない限り、Artifactの説明で置き換えないでください。

サポートへの報告はクライアント版、接続先の種類、拒否されたフィールド、正確なエラーから始めます。「Claude Codeが動かない」だけでは、修正済みのクライアント問題と現在の提供者側の問題を区別できません。