# OpenClawの401認証エラーを直す：invalid bearer tokenとmissing authentication headerの切り分け

> 401が出たら、まずGatewayに接続できないのか、接続後のモデル呼び出しが拒否されたのかを確認します。invalid bearer tokenは選択中の認証方式を、missing authentication headerは送信先と認証情報の解決を調べます。別のagentだけ失敗する場合は、共有認証情報を隠す局所設定も確認します。

- URL: https://blog.laozhang.ai/ja/posts/openclaw-401-authentication-error
- Published: 2026-04-07
- Updated: 2026-10-04
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about)
- Category: AIトラブルシューティング
- Tags: OpenClaw, 401エラー, 認証エラー, Anthropic, トークン

---
OpenClawの401認証エラーは、**拒否した相手を確認してから、該当する認証情報だけを修正する**と切り分けやすくなります。ダッシュボードに接続できない場合はGatewayの接続認証、チャットを送った後に`provider returned HTTP 401`が出る場合はモデル提供元の認証を調べます。Gatewayのトークンを交換しても、モデル提供元のAPIキーは更新されません。

`invalid bearer token`なら選択中のトークンやアカウントを確認し、`missing authentication header`なら送信先、認証情報の参照先、実行中の環境を確認します。main agentは動くのに別のagentだけ失敗する場合、全agentにキーを入れ直す必要はありません。現在のOpenClawは共有認証情報を読み取れますが、同じIDのagentローカル設定があると、そちらが優先されます。[認証情報の保存仕様](https://docs.openclaw.ai/concepts/oauth#storage-where-tokens-live)

## 最初に、どこで401が出ているかを確認する

以下の表で、今の症状に合う確認先を選んでください。「トークン」という言葉だけで、すべてを同じ認証として扱わないことが大切です。

| 症状・エラー | 確認する対象 | 最初の操作 |
| --- | --- | --- |
| Control UIに接続できず、`AUTH_TOKEN_MISSING`や`AUTH_TOKEN_MISMATCH`が出る | クライアントとGatewayの接続認証 | 接続先URLと`error.details.code`を確認する |
| モデル呼び出しで`invalid bearer token`が出る | 選択中の提供元、アカウント、APIまたはClaude CLI | 対象agentの`models status`と、失敗した会話の`/model status`を確認する |
| `401 Missing Authentication header`が出る | モデルへの送信先と認証情報の解決 | provider設定、認証方式、Gatewayサービスの環境を確認する |
| 特定agentだけ`No credentials found`になる | 共有プロファイルとagentローカルの上書き | `models status --agent`と`models auth list --agent`で対象を絞る |
| WhatsAppなど、チャンネル接続の段階で401が出る | そのチャンネルの接続認証 | チャンネルのログと接続状態を確認する |

チャンネルの401が出ているのにAnthropicのキーを再発行したり、モデルの401に対してGateway認証を無効にしたりすると、原因とは別の設定を変えてしまいます。チャンネルの問題は[公式のチャンネル別トラブルシューティング](https://docs.openclaw.ai/channels/troubleshooting)、Gateway接続の問題は次節へ進んでください。

モデルの問題なら、**Gatewayが動くマシンで、Gatewayと同じOSユーザー・同じ状態ディレクトリを使って**、まず次を確認します。`<agentId>`は失敗したagentのIDに置き換えます。

```bash
openclaw --version
openclaw gateway status
openclaw doctor
openclaw models status --agent <agentId>
openclaw models auth list --agent <agentId>
```

`models auth list`は保存済みプロファイルのIDや状態を確認するコマンドで、キーやトークンの本文を表示しません。問題が起きた会話では、別途`/model status`を入力してください。CLIの`--agent`が調べるのは設定されたagentであり、その会話だけのモデル・プロファイル上書きまで調べるわけではありません。[公式CLIリファレンス](https://docs.openclaw.ai/cli/models)

## Gatewayのトークン・デバイス認証が拒否される場合

Gateway接続のエラーは、`error.details.code`に沿って直します。共有トークン、デバイスのトークン、承認済み権限は別のものです。

| コード | 対処 |
| --- | --- |
| `AUTH_TOKEN_MISSING` | 必要な共有トークンをクライアントに設定する |
| `AUTH_TOKEN_MISMATCH` | Gatewayとクライアントが使う共有トークンを照合する。`canRetryWithDeviceToken=true`の場合は許可されたデバイストークンでの再試行を確認する |
| `AUTH_DEVICE_TOKEN_MISMATCH` | 古い・失効したデバイストークンを、devices CLIで再承認または更新する |
| `AUTH_SCOPE_MISMATCH` | 要求している権限を確認し、再ペアリングまたは権限の承認を行う |
| `PAIRING_REQUIRED` | 未承認の接続要求を確認して承認する |

共有トークンが必要な場合、Gatewayホストの対話型ターミナルで次を実行し、表示された値を正しいクライアントに設定します。出力は秘密情報なので、その場で扱い、スクリーンショットや問い合わせ文に貼らないでください。

```bash
openclaw gateway auth-token --show
```

`PAIRING_REQUIRED`では、接続したいデバイスと要求された権限を確認してから承認します。`<requestId>`には一覧に出た該当要求のIDを入れます。

```bash
openclaw devices list
openclaw devices approve <requestId>
```

`AUTH_SCOPE_MISMATCH`は、デバイスのトークンが認識されても権限が足りない状態です。共有トークンを再発行し続けるより、要求された権限と承認内容を直してください。修正後、同じクライアントで接続できることが成功条件です。その後のモデル呼び出しは別途確認します。[現在の公式エラーコード表](https://docs.openclaw.ai/gateway/troubleshooting/agent-replies-and-control-ui#auth-detail-codes-quick-map)

## `invalid bearer token`は、選択中の認証方式を確認する

`invalid bearer token`は、送信された認証情報が受け付けられなかったことを示す手掛かりです。ただし、この文字列だけでは失効、誤ったアカウント、別プロファイルの選択など、原因を一つに絞れません。エラーを出した提供元と、その会話の実行方式を先に確認します。

![トークン拒否、ヘッダー欠落、agentの認証不足を分けて考える図](https://blog.laozhang.ai/posts/ja/openclaw-401-authentication-error/img/triage-map.webp)

この図は切り分けの考え方を示す旧図です。実際に使うコマンドと共有認証情報の扱いは、以下の現行手順を確認してください。

### Anthropic APIを使っている場合

API接続を選択しているなら、Anthropic ConsoleのAPIキーを使います。現在の[Anthropic向け公式案内](https://docs.openclaw.ai/providers/anthropic#troubleshooting)は、トークンが失効・取り消しされた場合の新しい構成にはAPIキーを勧めています。既存のsetup-token認証がすべて廃止された、という意味ではありません。

対象agentにAPIキーを設定する場合は、次の対話型コマンドで入力できます。既存キーを使うか再発行するかは、提供元での有効性や取り消し状況を確認して決めます。

```bash
openclaw models auth paste-api-key --provider anthropic --agent <agentId>
openclaw models status --agent <agentId>
```

保存完了と、実行中Gatewayへの適用は同じではありません。コマンドが再起動を求めた場合や自動再読み込みが無効な場合は、`openclaw gateway restart`で反映し、同じ会話のモデル・アカウント選択を確認します。複数agentを使う環境では、変更コマンドにも対象agentを明示してください。[認証変更と適用の仕様](https://docs.openclaw.ai/cli/models)

環境変数からキーを読み込む構成では、ターミナルに`ANTHROPIC_API_KEY`が設定されていても、systemdやlaunchdのGatewayサービスに届いているとは限りません。公式案内ではGatewayホストの`~/.openclaw/.env`など、サービスが読み込む環境へ設定し、再起動後に確認します。キーを保存したマシン、サービスの実行ユーザー、参照する状態ディレクトリを揃えてください。[GatewayホストでのAPIキー設定](https://docs.openclaw.ai/gateway/authentication)

### Claude CLIを使っている場合

Claude CLIで実行しているなら、Claude Code自身のログインを確認します。手元の別マシンでログインし直しても、サーバー上のGatewayが利用するログインは直りません。Gatewayホストの同じユーザーで次を実行します。

```bash
claude --version
claude auth status --text
```

未ログイン、期限切れ、更新失敗などが確認できた場合は、同じユーザーでログインし直し、Gatewayを再起動します。

```bash
claude auth login
openclaw gateway restart
```

OpenClawはネイティブClaude CLIのログイントークンを読み取り、保存、更新する仕組みではありません。インストール済みの`claude`プロセスが認証を管理します。OAuthトークンを取り出してOpenClawのデータベースにコピーする必要はありません。Gatewayが`claude`をPATHから実行できること、`CLAUDE_CONFIG_DIR`が意図したログインを指していることも確認します。[Claude CLIの公式手順](https://docs.openclaw.ai/providers/anthropic#claude-cli)

`please run /login · API Error: 401 invalid bearer token`と表示された場合も、どのプロセスから出たメッセージかを確認してください。Claude CLIのログインが失敗しているなら、そのホスト上での再ログインが必要です。別のトークンプロファイルを選んでいる会話では、CLIにログインしただけでは選択済みプロファイルが切り替わらないことがあります。

また、モデル名が`anthropic/...`であることや「Claude CLI」を選ぶことだけでは、月額プランの枠を使っているとは判断できません。APIキーのアカウントを明示的に選択したClaude CLI実行はAPI課金になります。復旧時に想定外の認証方式へ切り替わらないよう、実行方式と選択アカウントを両方確認してください。[実行方式と課金の区別](https://docs.openclaw.ai/providers/anthropic#choose-a-model-route)

## `missing authentication header`なら、キー再発行の前に送信経路を調べる

`401 Missing Authentication header`は、受信側が必要な認証ヘッダーを受け取れなかったという手掛かりです。APIキーが失効したと即断せず、**失敗した要求の送信先と、認証情報がどう選ばれるか**を確認してください。

1. 会話の`/model status`で、実際のprovider・モデル・アカウント・実行方式を確認します。
2. 対象agentの`models status`と`models auth list`で、利用可能な認証情報や選択対象を確認します。
3. カスタム接続なら、`models.providers.<id>`の`baseUrl`、`api`、モデルIDと、認証プロファイルのproviderが意図した接続先に対応しているか確認します。
4. Gatewayサービスが読む環境、SecretRefの参照先、agentローカルの上書き、`auth.order`による除外を確認します。

エンドポイントの設定と認証情報は役割が違います。`baseUrl`やAPI形式を変更しても、必要なキーが自動で設定されるわけではありません。逆に、保存済みキーが見えるだけでは、その要求に使われたことも証明できません。[提供元設定と認証の区別](https://docs.openclaw.ai/gateway/authentication)

独自の中継サーバーを挟んでいる場合は、中継時に認証ヘッダーが落ちていないかも確認対象です。ただし、キーを含む生のヘッダーをログや公開issueに残さず、ヘッダーの有無を秘密値なしで確認してください。

設定と認証情報が揃っているのに同じエラーが続く場合は、バージョン固有の不具合も検討します。OpenRouterでは、[issue #51056](https://github.com/openclaw/openclaw/issues/51056)にOpenClaw `2026.3.13`・Linuxでの報告、[issue #97934](https://github.com/openclaw/openclaw/issues/97934)に`2026.6.10`・macOSでの報告があります。後者の報告者は`2026.6.1`への戻しで復旧したと述べています。

これは特定環境での過去の報告です。両issueがClosedであることも含め、現在の版が同じ不具合を持つ、またはすべての環境で解決済み、とは断定できません。古い版への一律ダウングレード手順として使わず、自分の版、provider、モデル、更新前後の違いを残して調査してください。

## main agentは動くのに、別のagentだけ失敗する場合

現在の保存方式では、**agentにローカルプロファイルがなければ共有認証情報を読み取ります**。新しいagentごとに同じキーを必ず登録する、という説明は現在の仕様には合いません。

既定の状態ディレクトリでは、保存先は次のように分かれます。

| 保存先 | 役割 |
| --- | --- |
| `~/.openclaw/state/openclaw.sqlite` | 共有認証情報 |
| `~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite` | agentローカルの認証情報、選択順、直近の成功状態、クールダウンなど |

`OPENCLAW_STATE_DIR`を変更している場合、基点のディレクトリも変わります。共有読み取りは、認証情報を各agentのデータベースへ複製する動作ではありません。共有OAuthプロファイルの更新は共有の保存先に書き戻されます。[現在の保存仕様](https://docs.openclaw.ai/concepts/oauth#storage-where-tokens-live)

例えば、共有の`anthropic:default`を更新してmain agentが復旧しても、別のagentが同じIDの古いローカルプロファイルを持っていると、そちらを選んで失敗することがあります。まず対象agentを指定し、利用できるプロファイルと選択順を調べます。以下の`anthropic`は、実際に失敗しているproviderに置き換えます。

```bash
openclaw models status --agent <agentId> --json
openclaw models auth list --provider anthropic --agent <agentId>
openclaw models auth order get --provider anthropic --agent <agentId>
```

同じIDのローカル設定、選択順から除外された共有プロファイル、会話で固定された別アカウントを区別します。利用可能な認証情報が本当に存在しないなら、Gatewayホストの共有設定またはそのagent向けの認証を設定します。別アカウントで独立運用したいagentには、そのアカウントのログインを用意します。[Anthropicのagent別認証エラーへの対処](https://docs.openclaw.ai/providers/anthropic#troubleshooting)

秘密情報をSQLiteで直接編集したり、正常なagentのOAuthトークンをコピーしたりしないでください。再認証後も古い局所設定が残る、特にアップデート後のケースは次の移行確認へ進みます。

## アップデート後の401と古いJSON認証ファイル

更新後に401が出たら、まず版と実行ファイル、Gatewayの状態、doctorの指摘を確認します。以下は確認用で、認証データを書き換える`--fix`はまだ付けません。

```bash
which openclaw
openclaw --version
openclaw update status --json
openclaw gateway status --deep
openclaw doctor
```

現在、`auth-profiles.json`、`auth-state.json`、agent内の旧`auth.json`は移行元であり、実行時の認証保存先ではありません。旧JSONを編集してキーを入れ直す方法は使わないでください。移行が必要な場合は`AUTH_PROFILE_MIGRATION_REQUIRED`が出て、該当するproviderの認証解決が止まることがあります。[JSONからSQLiteへの移行仕様](https://docs.openclaw.ai/concepts/oauth#storage-where-tokens-live)

doctorが移行や古いOAuthの局所設定を指摘した場合、設定と認証状態の復元可能なバックアップを確保し、変更の影響を確認してから実行します。

```bash
openclaw doctor --fix
openclaw gateway restart
openclaw models status --agent <agentId>
```

`doctor --fix`は認証情報などを変更する修復コマンドです。対応する旧JSONの検証済み値を取り込み、元ファイルを時刻付きで退避します。更新後、再認証してもモデルの401が続くケースでは、古いagent別OAuth設定を除去して現在の共有プロファイルを参照させる処理も公式に案内されています。[アップデート後の公式トラブルシューティング](https://docs.openclaw.ai/gateway/troubleshooting/updates-and-rollbacks#after-an-update)

例外は、さらに古い共有ファイル`credentials/oauth.json`です。このインポーターは廃止されており、現在のdoctorはファイルをそのまま残し、取り込みには`2026.9.5`を経由する更新が必要だと報告します。このファイルがある場合は、doctorが示す移行経路に従ってください。「古いJSONなら何でも最新版の`--fix`で読み込める」とは限りません。

古い実行ファイルで新しい設定を操作すると、`meta.lastTouchedVersion`による保護が働く場合もあります。そのときはPATHとサービスが使う版を揃えます。ダウングレードが必要なら対応する更新前バックアップと互換性のある版を使い、保護用metadataの削除やSQLiteの手動改変で回避しないでください。[版の食い違いとロールバック](https://docs.openclaw.ai/gateway/troubleshooting/updates-and-rollbacks#split-brain-installs-and-newer-config-guard)

## 修正後は、同じagent・モデル・会話で確認する

![修正後に同じagent、認証方式、古い設定、クールダウンを確認する図](https://blog.laozhang.ai/posts/ja/openclaw-401-authentication-error/img/post-fix-checklist.webp)

復旧確認の基本は、失敗した条件を揃えることです。別のagentや別のモデルが成功しても、元の問題が直ったとは限りません。図のチェック項目を参考に、まず対象agentの状態と会話の`/model status`を確認し、短い要求を一度送って結果を見ます。モデルへの実要求には、選択したアカウントの料金や利用枠が適用されます。

静的な確認なら次を使います。

```bash
openclaw models status --agent <agentId> --json --check
```

終了コード`0`は、設定された経路に認証・実行方式の問題や期限切れ間近の選択済み認証情報が見つからなかった、という意味です。**モデル呼び出し成功の証明ではありません**。`1`は不足、失効、互換性の問題、実行方式が利用不能、確認不能など、`2`はそれらの問題はないものの選択済み認証情報が期限切れ間近の場合です。[状態表示の読み方](https://docs.openclaw.ai/cli/models#read-status-correctly)

CLIから実要求を試す必要がある場合は`--probe`を使えます。ただし現在のCLIは状態ディレクトリの排他的所有を必要とするため、稼働中Gatewayを止める時間を確保してください。`<agentId>`、`<providerId>`、`<profileId>`は確認対象の実際の値に置き換えます。

```bash
openclaw gateway stop
openclaw models status --agent <agentId> --probe \
  --probe-provider <providerId> \
  --probe-profile <profileId> \
  --probe-concurrency 1 \
  --probe-max-tokens 8
openclaw gateway start
```

probeはトークン消費やレート制限を伴う実要求で、`--probe-max-tokens`もベストエフォートの上限指定です。probeと後処理が完了してからGatewayを起動し直します。タイムアウトや中断で後処理の失敗が報告された場合は、解放完了を確認してから次の操作に進んでください。probeの成功後も、会話固有のモデル選択があるなら元の会話で確認します。[probeの動作と制約](https://docs.openclaw.ai/cli/models)

`No available auth profile (all in cooldown)`なら、`models status --json`の`auth.unusableProfiles`と理由を見ます。レート制限による待機は401による認証拒否と別です。Anthropicのクールダウンはモデル単位の場合があるため、キーを失効させる前に、待機対象と復帰条件を確認してください。[クールダウンの公式説明](https://docs.openclaw.ai/providers/anthropic#troubleshooting)

再認証や移行を終えても同じ401が残る場合は、版、OS、provider、モデル、agent ID、実行方式、発生時刻、秘密値を除いたエラーを揃えて問い合わせます。Gateway接続、認証情報の解決、モデル実行のどこまで成功したかも記録すると、キー交換を繰り返さずに次の調査へ進めます。

## よくある質問

### OpenClawの401は、APIキーを作り直せば直りますか？

必ずしも直りません。Gatewayの接続トークン、Claude CLIのログイン、モデル提供元のキーは別です。ヘッダー欠落やagentローカルの古い上書きでは、キー再発行より先に送信経路と選択中の認証情報を確認します。

### main agentで動くキーを、新しいagentにもコピーする必要がありますか？

現在の仕様では、利用可能な共有プロファイルがあれば新しいagentはそれを読み取れます。同じIDのローカルプロファイルがあると、そちらが優先されます。共有読み取りとコピーは別で、OAuthトークンの手動コピーは避けてください。[保存仕様](https://docs.openclaw.ai/concepts/oauth#storage-where-tokens-live)

### setup-tokenは、現在も使えますか？

公式の[認証ガイド](https://docs.openclaw.ai/gateway/authentication)には、現在もsetup-tokenの手順があります。一方、[Anthropicの認証エラーへの対処](https://docs.openclaw.ai/providers/anthropic#troubleshooting)は、トークン失効時の新しい構成にはAPIキーを勧めています。ネイティブClaude CLIのログインとは別の保存済み認証情報なので、どちらを使う会話なのかを確認してください。

### `models status --check`が成功したのに、401が出るのはなぜですか？

`--check`は設定・認証状態の確認で、モデルへの実要求を成功させるテストではないためです。また、設定されたagentの状態と会話固有の上書きが異なる場合もあります。同じ会話の`/model status`を確認し、費用や利用枠を理解したうえで短い実要求を試してください。[CLIの確認範囲](https://docs.openclaw.ai/cli/models)

### 古い`auth-profiles.json`を編集しても反映されないのはなぜですか？

現在の実行時保存先はSQLiteで、旧JSONは移行元だからです。まずdoctorの指摘を確認し、必要ならバックアップ後に`doctor --fix`で移行します。古い`credentials/oauth.json`には別の移行経路が必要です。[移行仕様](https://docs.openclaw.ai/concepts/oauth#storage-where-tokens-live)

この記事の手順は、2026年10月4日に確認した公式資料と、版・環境を限定した公開issueを基にしています。ここでOpenClaw実機の再現試験や有料モデルへの認証probeは実施していません。