OpenClawのinvalid beta flagエラー：拒否された機能を特定して直す
invalid beta flagが出たら、エラー本文のベータ名と実際の送信先を確認します。不要な明示ヘッダーならその値だけを修正し、自動追加や代理サーバーが原因なら追加元を直します。設定の検証後、同じモデルと接続先で応答が完了して初めて復旧を確認できます。
目次
OpenClawでinvalid beta flagが出たら、拒否されたベータ名、実際の提供元、その値を追加した場所を確認してから修正します。不要なベータ機能を明示ヘッダーで指定しているなら、その値を外すのが最短です。一方、必要な機能や認証に関係する値を一括削除すると、別の問題を作ることがあります。
Anthropicの直接APIでは、無効なベータ名や利用資格のないベータへの要求は、HTTP 400・invalid_request_errorとして拒否されます。ただし、OpenClawに表示された文字列だけでは、Anthropic本体、中継API、別のクラウドのどこが拒否したかは決まりません。Anthropicのベータヘッダー仕様
まずは失敗した要求の情報をそろえ、接続先を変えずに一つずつ修正してください。以下は2026年10月4日時点の公開仕様に基づく手順です。コマンド例は設定確認・変更の方法を示すもので、読者のアカウントでのモデル応答を確認した結果ではありません。
最初に確認するのは、400の本文と実際の送信先
エラーの直前・直後にあるログから、次を確認します。APIキー、Authorizationの値、会話本文を問い合わせ用の記録へ含める必要はありません。
| 確認する項目 | 切り分けに使う理由 |
|---|---|
HTTPステータス、エラーのtype、message | ベータ拒否か、別のリクエスト形式エラーかを区別する |
| 拒否されたベータの正確な名前 | 古い値、誤記、利用資格、送信先の非対応を調べる |
| 失敗したagent、会話で選択中のモデル | 既定モデルと実際に使ったモデルの違いを見つける |
provider ID、api、baseUrlのホスト | 直接API、互換API、中継、管理クラウドを区別する |
| OpenClawのバージョンと更新前後の差 | 現行仕様とインストール済みの動作が一致するか確認する |
Gatewayが動くホストの、同じOSユーザー・同じ設定環境で次を実行します。これらは状況と設定を確認するコマンドで、上流モデルへの成功要求を保証するものではありません。
openclaw --version
openclaw gateway status
openclaw config file
openclaw config get models.providers
openclaw config validateconfig fileで実際の設定ファイルを確認し、config getで提供元の構成を調べます。現在のCLIは秘密値を伏せた設定を表示しますが、組織名や独自ホスト名なども含め、共有前に出力を確認してください。config validateはGatewayを起動せず設定を検証します。設定CLIの仕様
400でも、anthropic_versionの不足やtools内の未対応フィールドが指摘されているなら、直す対象はそのフィールドです。invalid_request_errorという分類だけを見て、すべてをベータヘッダーの問題として扱わないでください。401へ変わった場合はOpenClawの認証エラーの切り分けへ進みます。
anthropic-betaを追加した場所を切り分ける
設定ファイルにanthropic-betaが見つからなくても、送信されていないとは限りません。OpenClawの提供元アダプターや、中継サーバーが追加することがあります。
| 値を追加している場所 | 調べる対象 | 修正する場所 |
|---|---|---|
| 明示した提供元ヘッダー | models.providers.<id>.headers | 不要なベータ値だけを修正する |
| OpenClawの自動追加 | モデル、認証方式、機能のパラメーター、インストール済みバージョン | 該当機能の設定や対応版を確認する |
| 中継API・リバースプロキシ | 中継前後でのベータ名の有無、プロキシ側の設定 | 追加・変換している中継側を修正する |
自分で設定したヘッダーが原因なら、まずその値を直します。 同じヘッダーに複数のベータを指定している場合、拒否された一つだけを外して、必要な値を残します。Anthropicはカンマ区切りや複数のヘッダーによる指定を受け付けるため、先頭の値だけを見て判断しないでください。複数ベータの指定方法
直接APIの自動追加が疑わしい場合は、ベータ名と有効にした機能を照合します。現在のOpenClawには、特定モデルをAPIキーで直接呼び出す場合の自動機能や、任意で有効にするサーバー側圧縮があります。すべての要求に同じ値を追加する仕様ではなく、OAuth、プロキシ、Bedrockなどとは適用範囲が異なります。Anthropic提供元の機能と適用条件
例えば、anthropicServerCompactionを有効にした対応モデルでは、compact-2026-01-12と圧縮用の本文が追加されます。この機能が不要なら機能設定を無効にする選択肢があります。必要なら、ベータヘッダーだけを落とすのではなく、モデルと接続先がその圧縮方式に対応するか確認します。ヘッダーと本文は一組として扱ってください。サーバー側圧縮の仕様
中継を使っている場合は、管理者に「どのベータ名が中継前にあり、中継後に追加されたか」を秘密値なしで確認します。ローカルの設定から値を消しても、中継側が再び追加するなら同じエラーが続きます。
不要な明示ヘッダーは、対象のproviderだけ修正する
明示ヘッダーにある値が不要で、送信先の公開仕様でも非対応と確認できた場合、設定のバックアップを取ってから該当providerを修正します。providerの名前、baseUrl、認証情報、モデルは同時に変更しません。
以下はprovider IDがclaude-proxyで、そのanthropic-betaヘッダー全体が不要な場合だけの例です。別のIDなら、角括弧内を実際のIDへ置き換えてください。
openclaw config get 'models.providers["claude-proxy"].headers'
openclaw config unset 'models.providers["claude-proxy"].headers["anthropic-beta"]'
openclaw config validatezshなどでは角括弧がシェルに解釈されるため、設定パスを引用符で囲みます。複数のベータのうち一部が必要なら、このunset例は使わず、config setまたは設定編集で必要な値だけを残してください。不要なのはベータヘッダーであって、APIキーやAuthorizationではありません。パス指定と変更コマンド
unsetが「対象なし」で終了しても、上流の不具合が解決したわけではありません。現在のCLIでは、指定した設定項目が存在しない場合は変更されず終了ステータス1となります。別の設定ファイルを参照していないか確認したうえで、自動追加と中継側へ調査を進めます。
保存後は、CLIが示す再読み込み・再起動の案内に従ってください。再起動が必要な場合は次を実行します。
openclaw gateway restart
openclaw gateway status読み取り専用・Nix管理の環境で書き込みが拒否される場合は、管理元の設定を直します。ファイル権限を緩めて無理に書き込む必要はありません。また、変更後の案内は必要な反映方法の説明であり、実行中Gatewayが新しい値を読み込んだことや、上流が受け付けたことの証明ではありません。書き込みと反映の注意点
互換API、Bedrock、Vertexは接続方式を保って直す
Claudeを使っていても、Anthropicの直接APIと同じヘッダーを送れるとは限りません。エラーを消すためだけに提供元を入れ替えると、認証、モデル、利用できる機能も変わります。
Anthropic互換APIでは、providerとホストの判定を確認する
現在のOpenClawは、api: "anthropic-messages"でも、正規のanthropic以外のproviderや、公開api.anthropic.com以外の独自baseUrlを非直接接続として扱い、暗黙のAnthropicベータヘッダーを抑制します。対応するプロキシ機能を使いたい場合は、明示的なmodels.providers.<id>.headers["anthropic-beta"]で指定できます。互換APIの送信ルール
互換APIへつないでいるのに拒否が続くなら、実際に読み込まれたprovider IDとホスト、残っている明示ヘッダー、プロキシ側の追加を順に確認します。この説明は現行文書の仕様です。古いインストール済みの版が同じ動作をするとは限らないため、版の差も記録してください。非直接接続へ変えるだけで、プロキシがすべてのClaude機能に対応するわけではありません。
AWSではBedrockとClaude Platform on AWSを区別する
AWS運営のAmazon Bedrockと、Anthropic運営のClaude Platform on AWSは別のAPIです。Anthropicの比較表では、BedrockのAPIに標準のanthropic-betaヘッダーは対応せず、Claude Platform on AWSでは機能ごとの制約付きで使えます。AWS上にあることだけでは、同じ扱いにはなりません。AWS上の二つの提供方式
OpenClawのBedrock接続はamazon-bedrockとAWSの認証・リージョンを使います。また、古いClaudeモデルのConverse例を、すべての現行モデルへ適用できるわけではありません。現在の文書はClaude Opus 5やFable 5についてMessages APIの接続も説明しています。選択中モデルの対応方式を維持し、直接Anthropic用のヘッダーをそのまま転送しない構成か確認してください。OpenClawのBedrock設定
Claude on Vertex AIをgoogle-vertexへ単純に置き換えない
Claude on Vertex AIは、Google Cloudの認証、URL内のモデル指定、本文のanthropic_version: "vertex-2023-10-16"など、専用の要求形式を使います。ベータ機能も選択したモデルと接続方式で確認する必要があり、「Vertexではすべてのベータが禁止」とは言い切れません。Claude on Vertex AIの要求形式
OpenClawのGoogle提供元の文書にあるgoogle-vertexはGeminiの接続を説明しています。Claudeのベータエラーを直すためにそこへ変更すると、同じClaude接続の修正になりません。Claude用の中継・アダプターを使っているなら、その実装が要求形式と対象機能をどう変換するか確認します。初回の提供元設定から見直す必要がある場合はOpenClawのLLM設定手順を参照してください。
context1m: falseで直るとは限らない
古い対処記事で見かけるcontext-1m-2025-08-07は、現在のAPI用の一般的な修復対象として扱えません。現行OpenClawの文書では、この退役したベータヘッダーは送られず、古いanthropicBeta設定に残る同じ値もヘッダー解決時に除かれます。現在の1Mコンテキスト仕様
同文書が挙げる1Mコンテキスト対応の正式提供モデルでは、params.context1mは何もしない設定です。falseへ変更すればベータ拒否が解決する、あるいは必ずコンテキストが小さくなる、という意味ではありません。Claude CLIには別のコンテキスト予算の扱いがあります。
ログが今も退役した名前を指しているなら、インストール済みバージョン、明示ヘッダー、中継による追加、実行中の別Gatewayを確認します。「現行文書は送らないと言っている」と「この要求に含まれていない」は別の確認です。長いコンテキストで429が出ている場合も、400の無効なベータ名とは区別して、利用資格・制限を調べてください。公式のGatewayトラブルシューティング
修正後は、設定・読み込み・応答完了を順に確認する
復旧を判断するには、三つの確認が必要です。
- 設定が有効であること。
config validateが通り、対象providerの設定が意図した内容になっていることを確認します。スキーマ上有効なパラメーターでも、送信先が受け付けるとは限りません。 - Gatewayが変更を読み込んでいること。 CLIの反映案内に従い、実行中のホスト・ユーザー・設定ファイルが確認したものと一致していることを確認します。
- 同じ接続で回答が完了すること。 失敗したagentとモデル、認証方式、中継の有無を保ち、機密情報のない短いメッセージを送って完了を確認します。利用料金が発生する接続なら、通常の課金対象となる確認です。必要なベータ機能がある場合は、その機能も最小限の入力で確認します。
短い回答だけ成功しても、必要な圧縮やツール機能を無効にしたなら、元の用途が復旧したとはいえません。別のモデルへの自動切り替えで回答した場合も、元のモデルのベータ拒否が直った証明にはなりません。応答したモデルと、同じエラーが再発していないことを確認してください。
doctorやGatewayの正常表示は、上流のベータ対応を証明しません。doctor --fixを一律に実行するより、拒否された値の追加元を特定する方が先です。複数のOpenClawインストールやバージョン保護の警告がある場合は、公式の診断に沿って実行元を整理し、保護を回避して変更を続けないでください。公式の復旧手順
ここで止めて問い合わせる条件は、拒否されたベータ名が分からない、必要な機能なのに提供元の対応・資格を確認できない、または自分では変更できない中継が値を追加している場合です。同じ400へ無変更で再試行する代わりに、日時、OpenClawの版、provider ID、モデルID、送信先のホスト、エラー本文、行った変更をまとめます。認証情報と会話本文は除き、提供元や中継の管理者へ渡してください。
よくある質問
APIキーを再発行すればinvalid beta flagは直りますか？
ベータ拒否だけを理由に再発行する必要はありません。無効な名前、利用資格、接続先の非対応を先に確認します。401や認証情報の失効も確認できた場合は、認証エラーの手順で別途修正してください。Anthropicの400の定義はベータヘッダー仕様で確認できます。
ベータヘッダーを全部削除してもよいですか？
不要な値だけを削除してください。明示したヘッダー全体が不要ならconfig unsetを使えますが、必要な機能、認証方式、本文との関係がある値まで一括で消すと別の失敗につながります。OpenClawが自動で追加する値なら、明示ヘッダーを削除しただけでは直らないこともあります。Anthropic提供元の適用条件
OpenClawを更新したのに同じエラーが出るのはなぜですか？
実行中Gatewayが更新したバイナリーや設定を使っているか確認してください。そのうえで、明示ヘッダーと中継側の追加を調べます。更新は提供元の利用資格やプロキシの対応を変更しません。エラー本文が示す同じベータ名を基準に、変更前後を比較します。Gatewayの診断手順
config validateが通ったら解決済みですか？
まだ解決済みとは判断できません。config validateは設定の整合性を調べ、Gatewayを起動しません。実行中Gatewayへの反映と、元のモデル・接続先で応答が完了することを別に確認します。設定検証の範囲
