OpenClawでClaude Codeサブスクを使う仕組みとAPIキー推奨の理由

OpenClawはAnthropic以外のモデルにも対応するサードパーティ製のエージェントゲートウェイで、Claudeへの接続にAPIキー認証とClaude CLI認証の2経路を用意しています。後者はClaude Codeのサブスクリプションログインをそのまま再利用する経路です。Anthropicのサポート記事も、Claude Agent SDKやclaude -p、サードパーティアプリ経由の利用がサブスクリプションの利用枠から差し引かれると書いています。この経路は未文書化の抜け道ではありません。

ただし、課金がどちらに流れるかは「どの認証情報が優先されたか」で決まります。個人の実験ならサブスクで足りても、共有の自動化ではAPIキーが推奨されています。

どの認証情報が使われているかを先に確かめる

OpenClawのネイティブ再利用は、同じホストでclaudeがログイン済みであることが前提です。OpenClawの公式ドキュメントは、次のコマンドでログイン状態の確認と更新を行う手順を案内しています。

claude auth status --text
claude auth login
claude update

claude auth statusは、ログイン中なら終了コード0、未ログインなら1で終わります。既定はJSON出力で、--textを付けると人間向けの表示になります。認証情報の種類ごとに出力がどう変わるかを、空のホームディレクトリに差し替えた環境(Claude Code v2.1.287で確認)で試すと次のとおりです。ダミーの値を環境変数に入れただけで、実際のログインやAPI呼び出しはしていません。

# 何も設定していない状態
claude auth status --text
# => Not logged in. Run claude auth login to authenticate.
 
# ANTHROPIC_API_KEY を設定した状態(ダミー値)
ANTHROPIC_API_KEY=sk-ant-dummy claude auth status --text
# => API key: ANTHROPIC_API_KEY
 
# CLAUDE_CODE_OAUTH_TOKEN を設定した状態(ダミー値)
CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-dummy claude auth status --text
# => Auth token: CLAUDE_CODE_OAUTH_TOKEN

JSON出力でも違いが出ます。APIキーのときは"authMethod": "api_key"と"apiKeySource": "ANTHROPIC_API_KEY"でした。setup-tokenのときは"authMethod": "oauth_token"です。authMethodはclaude.ai・oauth_token・api_keyなどの値を取り、サブスクリプションのログインはclaude.aiにあたります。OpenClawを動かすホストで「サブスクのつもりがAPIキーだった」を見分けるには、このauthMethodが最も手早い手がかりです。

claude auth loginには、サブスクリプションの代わりにAnthropic Consoleでサインインし、API利用の従量課金にする--consoleの選択肢もあります。課金先の違いがそのままフラグ名に出ています。

OpenClawに保存した認証が複数ある場合、新規セッションは保存済みの認証をアカウント順で選びます。openclaw models auth paste-token --provider anthropicで保存したトークンも対象です。一度セッションが確立すると、別のアカウントを選び直すか保存済みプロファイルを削除するまで、そのアカウントのまま続きます。

claude auth status --textが示すのはClaude側の現在のログインで、OpenClawが選ぶアカウントとは別の話です。Claude Code側で複数アカウントを使い分けるときは、アカウントごとにCLAUDE_CONFIG_DIRで設定ディレクトリを分けます。

OpenClawはネイティブ再利用のオンボーディング時に、トークンを読み取ることも保存することもありません。ログインとトークンの更新はClaude Code自身が握り、OpenClaw側は秘密情報を含まない経路の目印だけを扱います。

ANTHROPIC_API_KEYが残っていると何が起きるか

「サブスクのつもりが従量課金になっていた」の原因のひとつは、他のツール用に設定したANTHROPIC_API_KEYがGatewayを動かす環境に残っていることです。ところが、この挙動の説明は公式ページ同士で書き方が違います。

2つは矛盾しているというより、サポート記事が結果だけを短く書き、ドキュメントが条件を書いている関係です。OpenClawの同梱バックエンドはclaude -pで起動するため、上の-pの条件に当たります。Gatewayを動かすユーザーの環境にANTHROPIC_API_KEYがあり、それがclaude -pに引き継がれれば、キーが使われて従量課金側に流れます。

認証ドキュメントによると、複数の認証情報があるときの優先順位は次の順です。

1. クラウドプロバイダーの認証情報(CLAUDE_CODE_USE_BEDROCKなど)
2. ANTHROPIC_AUTH_TOKEN
3. ANTHROPIC_API_KEY
4. apiKeyHelperスクリプトの出力
5. CLAUDE_CODE_OAUTH_TOKEN(setup-tokenの出力)
6. Anthropicプロファイル・フェデレーション認証
7. /loginで得たサブスクリプションのOAuth認証

サブスクリプションのログインは最下位です。ANTHROPIC_API_KEYが残っていると、サブスクの/loginより前に使われる位置にあります。逆に、setup-tokenのCLAUDE_CODE_OAUTH_TOKENはANTHROPIC_API_KEYより後ろなので、-pで両方を設定すると勝つのはAPIキー側です。

サブスクリプションの利用枠はどこまで共有されるか

ネイティブ再利用もsetup-tokenも、消費するのは同じサブスクリプションの利用枠です。Claude Agent SDK、claude -pコマンド、Agent SDK経由のサードパーティアプリの利用は、いずれもサブスクリプションの利用限度から差し引かれます。

この扱いには、発表された変更が一時停止された経緯があります。Agent SDK利用を通常枠から切り離す変更が2026年6月15日から始まる予定で案内されていましたが、Anthropicは6月15日付でこの変更を一時停止しました。サブスクリプションでログインしている限り、Agent SDKとclaude -pは今もサブスクリプションの利用限度から差し引かれます。

10月7日には、別の仕組みが加わりました。Max・Ultra・Teamのプランに、Claude Platform向けの月次APIクレジットが付くようになっています。金額はMax(旧Max 5x)が月$100、Ultra(旧Max 20x)が月$200です(Team Standardシートは1席あたり$20、Premiumシートは$100)。Claude APIやClaude Managed Agents、Claude Agent SDKに使えますが、対象は連携したConsole組織のAPIキーで動かした場合です。インタラクティブなClaude Codeや、Claude・Claude Code・Coworkの追加利用には使えません。Proは対象外です。

つまり、サブスクのログインで動かす経路は従来どおりサブスクの枠を使い、APIキーで動かす経路は従量課金かこの月次クレジットを使います。OpenClawが共有の自動化にAPIキーを勧めるのは、この切り分けに沿った案内です。

利用枠はターミナルの外にも共通です。Pro・Max・Ultraプランの枠は、VS CodeやJetBrains IDEなどの拡張機能でもClaudeのチャットでも共有され、ターミナルとIDEを併用しても消費先は1つです。

認証方式ごとの制約と適性

OpenClawで選べる3つの認証方式は、課金の紐付け先と同一ホスト要件、できないことが異なります。

claude setup-tokenとは何か

claude setup-tokenは、CIやスクリプトのようにブラウザーでログインできない環境のために、1年間有効なOAuthトークンを発行するコマンドです。Claudeサブスクリプション(Pro・Max・Ultra・Team・Enterprise)が必要で、OpenClawでもこのトークンを使えます。

OpenClawの公式ドキュメントによると、トークンはsk-ant-oat01-で始まります。発行手順や失効時の対処はClaude CodeでCI向け長期トークンを発行する方法にまとめています。

認証の優先順位ではANTHROPIC_API_KEYがCLAUDE_CODE_OAUTH_TOKENより先に使われるため、両方を設定したままにするとAPIキー側に課金されます。

APIキーが推奨される理由

OpenClawの公式ドキュメントは、共有の本番自動化にはClaude CLIではなくAPIキーを使うよう案内しています。理由は課金の透明性だけではありません。

1つ目は、認証が切れる前提で運用する必要があることです。OpenClawのトラブルシューティングには、401 errors / token suddenly invalidの項目があります。Anthropicのトークン認証は失効や取り消しがあるため、新規セットアップではAPIキーを使うよう書かれています。ネイティブ再利用でも、Claude CLIのOAuthセッションが期限切れで更新できなくなると止まります。この場合は、Gatewayを動かすユーザーとしてclaude auth status --textとclaude auth loginを実行します。その後openclaw gateway restartで再起動します。複数人が依存する自動化では、この復旧が人の手に依存すること自体が運用リスクになります。

2つ目は消費先の分離です。ネイティブ再利用もsetup-tokenも個人のサブスクリプション利用枠を使うため、共有の自動化を大量に走らせると、日常のClaude Code利用に回せる枠が減ります。自動化側の課金額に上限をかけたい場合はClaude Codeの--max-budget-usdでAPI課金額に上限を設けるが参考になります。

3つ目はコストの可視化です。ネイティブ再利用はClaude側が排他的にリフレッシュを管理しているため、OpenClawはその利用枠の消費量を取得するエンドポイントをポーリングしません。一方、ANTHROPIC_ADMIN_KEYまたはANTHROPIC_ADMIN_API_KEYを設定する方法があります。設定すると、OpenClawの管理UIのUsageに、直近30日分の日次支出、トークンとキャッシュの集計、モデル別コストが出ます。

この数字はAnthropicのUsage and Cost APIから取得した実際の課金額で、OpenClawがセッションから推定する見積りコストとは別物です。突き合わせれば、推定と請求のずれにも気づけます。プロバイダー設定にsk-ant-adminで始まる認証情報を保存しておけば、Admin APIキーとして自動的に検出されます。

Docker・組織ポリシーで使えなくなるケース

ネイティブ再利用には、ホスト条件のほかに実行環境と組織側の制約があります。

OpenClawをDockerで動かす場合は、コンテナのホームディレクトリを永続化してその中でclaudeにログインすれば、ネイティブ再利用は機能します。一方、Podmanなど一部のコンテナ環境は、セットアップ時も実行時もホストの~/.claudeをマウントしないため、この経路は使えません。OpenClawのドキュメントは、その場合にAPIキーを使うか、OpenClaw側でOAuthを管理する別プロバイダーを選ぶよう案内しています。

組織のポリシーでclaude.aiアカウントの/loginが無効化されている場合は、ネイティブ再利用の前提となるログインが成立しません。見分け方は組織がサブスクリプションアクセスを無効化 — Claude Codeのエラー対処で扱っています。

共有自動化の経路を選ぶ判断

個人の検証ホストで、同じ人が普段もClaude Codeを使うなら、ネイティブ再利用で足ります。複数人が依存する自動化は、認証切れの復旧を人手に頼らないAPIキーに寄せる方が運用は安定します。