Claude Code + GPT-5.6 Sol アカウント停止事件の解説：何が起きたのか、Boris Cherny の発言、そして LLM ゲートウェイを利用したより安全な方法
AI プログラミングツールを組み合わせて使った小さな実験が、2026 年 8 月で最も示唆に富む開発者とプラットフォームのトラブル事件の一つに発展した。その方法は一見シンプルだった：平文で Claude Code CLI →
Claude Code + GPT-5.6 Sol：ある開発者が停止された理由——Anthropicが実際に語ったこと
はじめに
AIコーディングツールを組み合わせた小さな実験が、2026年8月において最も示唆に富む開発者プラットフォーム論争のひとつとなった。
運用プランはシンプルに見えた：
Claude Code CLI
→ ローカルプロキシ
→ GPT-5.6 Sol
この構成はClaude Code自体を置き換えるものではなく、そのターミナルインターフェース、ツール、権限、エージェントワークフロー、セッション動作を維持しつつ、モデル推論をOpenAIのGPT-5.6 Solにルーティングするものだ。
OpenAI Codexの責任者 Thibault "Tibo" Sottiaux は7月に、この構成の簡易版を公開で共有していた。
彼の含みは冗談めいたものだった：この構成がブロックされた場合、彼はユーザーにCodexのリセットを借りがあると述べたのだ。
1ヶ月後、開発者 Alex Getman がほぼその構成通りに操作したと表明し、その後まもなくAnthropicによって「疑わしいシグナル」を理由にアカウントを停止された。
これにより直ちに現実的な疑問が生じた：
Anthropicは、Claude Codeをエージェントシェルとして非Claudeモデルと併用することを禁止しているのか？
Claude Codeの責任者 Boris Cherny は公に応答した。
彼は、Anthropicがシェルを他のモデルと併用したという理由だけでユーザーを禁止することはないと述べ、今回の停止はほぼ間違いなく別のアカウント分類子によって引き起こされたと指摘した。
これは明快な解決策のように聞こえる。
しかし、物事はそれほど単純ではない。
Anthropicの現在のドキュメントは、Claude Codeが互換性のあるLLMゲートウェイに接続できる一方で、Anthropicがこれらのゲートウェイを介してClaude Codeを非Claudeモデルにルーティングすることをサポートしていないと明記している。
これらの2つの発言は矛盾しない。
それらが意味するのは：
シェルで他のモデルを使用すること
≠ 自動的に禁止される理由
しかし
シェルで他のモデルを使用すること
≠ Anthropicがサポートする構成
この違いこそが、今回の出来事における最も重要な教訓である。
Tiboの5分間Claude Code + GPT構成
この話の発端は、開発者たちが異なるエージェントシェルでコーディングモデルのパフォーマンスを比較していたことに遡る。
モデルはAIコーディング製品の一部に過ぎない。
シェルはまた以下を決定する：
- モデルが呼び出せるツール。
- ファイルの読み取り・編集方法。
- 権限の動作方法。
- サブエージェントの作成方法。
- コンテキストの管理方法。
- ターミナルコマンドの実行方法。
- 長時間実行セッションの圧縮方法。
- 失敗時のリトライ方法。
これは、同じ基盤モデルが別のエージェント環境に置かれると、そのパフォーマンスが異なる可能性があることを意味する。
Sottiauxは、Claude Codeシェル内でGPT-5.6 Solを実験することを公に奨励した。
彼の高位レベルのプランは3つのステップから成る：
- CLIProxyAPIをインストールする。
- 必要なプロバイダーに接続する。
claudexエイリアスを定義し、代替モデル構成でClaude Codeを起動する。
Getmanによると、理由として示されたのは：
不審なシグナル
彼は異議申し立てを提出し、AnthropicとOpenAIに対して、この構成自体が禁止されているのかを公に問い合わせた。
これは重要な質問である。なぜなら、いくつかの可能な解釈が存在するからだ。
可能性1：モデルルーティング自体が禁止されている
Anthropicは、Claude Codeを別のモデルと一緒に使用することがポリシー違反であると見なす可能性がある。
可能性2：プロキシの挙動がアカウント不正利用のように見える
トラフィックパターンが、自動化操作、認証情報の不正使用、または他の不審なアカウント特性に類似している可能性がある。
可能性3：停止が構成と無関係
ほぼ同時期に、別のアカウントシグナルが分類器をトリガーした可能性がある。
可能性4：分類器が誤判定を起こした
システムが、本来正当な活動を誤って分類しただけの可能性がある。
Chernyの公開回答は、4番目の解釈を強く支持している。
Boris Cherny：「我々はユーザーがハーネスを他のモデルと一緒に使っただけでアカウントを停止することはない」
Claude Codeの責任者 Boris Cherny が直接回答した。
彼の声明は簡潔だった：
- Anthropicは、ユーザーがハーネスを他のモデルと一緒に使っただけでアカウントを停止することはない。
- 今回の停止は、ほぼ間違いなく別のアカウント分類器によってトリガーされた。
- チームが調査中。
2つ目はTiboが公開した投稿で、この出来事への返答として、事態は解決しすべて順調であると述べ、「ハーネス」の選択の自由が重要であり、どのモデルを選ぶかはユーザーが決めるべきだと強調し、今後数週間のバージョンアップデートへの期待も表明しており、同じく中英バイリンガル表記の内容が添付されている。
これはこの出来事に関連する最も明確な公開声明である。
これはGetmanが提起した狭義のポリシー問題に回答している：
Chernyの発言によれば、別のモデルを使用するコーディングハーネスを使用しただけでは、Anthropicのアカウント停止理由にはならない。
しかし、この声明はAnthropicのドキュメントと併せて読むべきである。
公式ドキュメントは依然として、Anthropicが非Claudeルーティングをサポートしないと述べている。
この2つの発言は、異なるレベルを説明している。
「停止理由にならない」は「公式サポート」を意味しない
開発者はしばしばプラットフォームのステータスを2つのカテゴリーに単純化する：
許可される
または
禁止される
実際の製品サポートはより細かい。
ある構成は以下のいずれかになり得る：
- 公式サポート。
- 技術的には可能だがサポート対象外。
- 推奨されない。
- ポリシーで禁止。
- 技術的にブロックされている。
Claude Code + 非Claudeゲートウェイのパターンは、現在最も近いのは：
技術的には可能
+
Claude Code責任者によれば停止理由にはならない
+
Anthropicドキュメントではサポート対象外
これはつまり、ユーザーはAnthropicサポートが以下のような問題のデバッグをしてくれると期待すべきではないということだ：
- ツールモードの非互換性。
- ストリーミングの差異。
- コンテキストウィンドウの不一致。
- サポートされていないベータヘッダー。
- ツール検索の失敗。
- プロンプト形式の変換。
- サブエージェントの挙動。
- Claude Codeアップグレード後の変更。
翻訳レイヤーを正常に動作させ続ける責任は、実質的にプロキシの所有者（Anthropicではなく）にある。
共有エイリアスでツール検索が無効化された理由
Sottiauxのエイリアスには、以下のような詳細がある：
ENABLE_TOOL_SEARCH=false
Anthropicの現在のドキュメントは、これがなぜ重要なのかを理解するのに役立つ。
Claude CodeのMCPツール検索が使用するモデルおよびプロトコル機能は、カスタムのANTHROPIC_BASE_URLまたは互換性のあるプロキシが正しく転送できない可能性がある。
Anthropicの現在のMCPドキュメントは、以下の場合にツール検索の挙動が異なる可能性があると述べている：
- カスタムの
ANTHROPIC_BASE_URLが使用されている。 ENABLE_TOOL_SEARCH=falseが設定されている。- モデルが必要なツール参照動作をサポートしていない。
- ゲートウェイが関連するベータ機能を転送していない。
これは、プロキシがClaude Codeハーネスの大部分の機能を保持できる一方で、エッジケースの挙動を変える可能性があることを示す良い例である。
インターフェースはまったく同じに見えるかもしれない。
しかし、プロトコルの経路は同じではない。
現在のClaude
Codeはカスタムモデルオプションをサポートしています
Claude Codeの現在のモデル設定ドキュメントには、カスタムモデルオプションとカスタムゲートウェイモデルIDのメカニズムも含まれています。
これは、ゲートウェイが内部名をモデルデプロイメントにマッピングする組織にとって有用です。
例えば、ゲートウェイは標準のAnthropicモデルIDの代わりに内部識別子を公開する場合があります。
Claude Codeは、標準のClaude名として検証することなく、設定されたカスタム値を受け入れることができます。
同様に、これはAnthropicがそのIDの背後にあるすべてのアップストリームモデルをサポートすることを示すものではありません。
それは単に、Claude Codeがゲートウェイがモデル命名を制御する環境で正常に動作できることを意味します。
なぜローカルホストプロキシがアカウントシグナルを引き起こす可能性があるのか
ゲットマン氏は、自身のプロキシが以下のみをリッスンしていたと強調しました：
127.0.0.1
つまり、プロキシ自体はパブリックインターネットサービスとして公開されていませんでした。
しかし、「ローカルホストのみ」は外部サービスが関与していないことを意味しません。
このワークフローには依然としてアウトバウンド接続が含まれています：
ローカルClaude Code
→ ローカルプロキシ
→ 外部モデルプロバイダー
アカウントセキュリティシステムは、プロキシポートが公開されているかどうかとは無関係に、多くのシグナルを観察できます。
オンラインサービスにおける潜在的なシグナルには以下が含まれる可能性があります：
- 認証変更。
- リクエストパターン。
- デバイス変更。
- セッション動作。
- 使用量の急増。
- ネットワークソース。
- 自動化動作。
- アカウント整合性指標。
Anthropicは、ゲットマン氏のアカウントをトリガーした具体的な分類器を公表していません。
チェルニー氏は、ほぼ確実に別のアカウント分類器によってトリガーされたと述べただけです。
したがって、ローカルホストプロキシ自体が禁止をトリガーすることが知られていると主張するのは正しくありません。
「不審なシグナル」が私たちに教えること、そして教えないこと
曖昧な禁止理由は、診断情報がほとんど提供されないため、苛立たしいものです。
それはユーザーにシステムが以下を検出したかどうかを伝えません：
- 利用ポリシーの問題。
- アカウントの乗っ取り。
- 身元の不一致。
- 自動化の悪用。
- 支払いの問題。
- 場所の異常。
- 誤検知のアカウント動作。
Anthropicのサポートドキュメントによると、アカウントは利用ポリシーの繰り返しの違反、サポートされていない場所でのアカウント作成、または利用規約への違反などにより禁止される可能性があります。
ユーザーが禁止が正しくないと考える場合、Anthropicは制限付きアカウントエクスペリエンスを通じて異議申し立ての手段を提供します。
公開されている従業員が特定のインシデントの調査を支援する場合でも、正式な異議申し立てプロセスが正しい経路です。
Anthropicアカウントの禁止に対して異議申し立てする方法
Anthropicの現在のヘルプセンターによると、自分のアカウントが誤って禁止または終了されたと考えるユーザーは以下を行うべきです：
claude.aiにアクセスします。- 禁止されたアカウントでログインします。
- 制限付きアカウント画面に表示される異議申し立てフォームを開きます。
- 要求されたアカウント情報と説明を提出します。
- セキュリティチームがケースを審査するのを待ちます。
同社は、高トラフィック期間中は応答時間が長くなる可能性があると述べています。
個人アカウントではなく組織が凍結された場合、Anthropicは制限付き画面に別の レビューをリクエスト オプションが表示される場合があると述べています。
異常なローカルプロキシ設定に関連する異議申し立ての場合、役立つ証拠には以下が含まれる可能性があります：
- 禁止の正確な日付と時刻。
- Claude Codeのバージョン。
- CLIが変更されたかどうか。
- プロキシ名とバージョン。
- リッスンアドレス。
- モデルプロバイダー。
- 関連する設定。
- 機密情報を漏らさないログ。
- 公開されている再現リンク（ある場合）。
何が起こったのかを証明しようとする際に、APIキー、OAuthトークン、Cookie、またはアカウント資格情報を公開しないでください。
ゲットマン氏は自身の実装を公開しました
禁止後、ゲットマン氏はその設定を記録したコードリポジトリを公開しました：
このリポジトリは、その目標をClaude Codeの背後で異なるモデルを実行することと説明しています。
ローカルのみのCLIProxy APIサーバーを通じて。
通常のclaudeコマンドを維持し、別のコマンド（例）を許可します：
claudex
代替ルート用に。
READMEには以下のような例が含まれています：
claudex
claudex --continue
claudex --effort low -p "explain this file"
現在、macOSまたはLinux（zshを使用）でのサポートを説明しており、WindowsはWSL経由で利用可能です。
このプロジェクトはコミュニティによってメンテナンスされており、AnthropicまたはOpenAIの製品ではありません。
Claude Desktopは別のケースです
Getmanのリポジトリはまた、重要な制限を文書化しています：
コマンドラインのみ
そこで説明されているプロキシ手法は、Claude Codeコマンドラインのワークフローを対象としています。
統合されたClaude Codeエクスペリエンスを起動する際、Claude Desktopアプリは独自のモデルとAPIエンドポイントを固定するため、同じプロジェクトレベルのルーティングパスは同じようには動作しないと述べています。
これは、「Claude Code」が複数のインターフェースに表示される可能性があることを改めて思い出させます。
ターミナルで機能する設定が、デスクトップ統合ワークフローでも同様に機能すると自動的に想定すべきではありません。
Tiboの応答：ツールの自由は重要
チェルニー氏の応答後、ソティオー氏はディスカッションスレッドに戻りました。
問題が解決したことを嬉しく思い、ツールの自由が重要だと主張しました。
彼の立場は、ユーザーが自分に最適なモデルを決定できるべきだというものです。
このやり取りは、両方のプラットフォーム責任者がこの特定の問題について実際にはあまり意見が分かれていなかったため、示唆に富んでいます。
チェルニー氏：
私たちは、他のツールで他のモデルを使用しているユーザーを禁止することはありません。
ソティオー氏：
ユーザーはツールに最適なモデルを選択できるべきです。
残りのギャップは製品サポートにあります。
Anthropicのドキュメントは、Claude Codeでの任意の非Claudeバックエンドのサポートを約束していません。
Tiboはその後、有料ChatGPT WorkとCodexの使用制限をリセットしました
ソティオー氏は以前、この設定が禁止された場合、ユーザーにリセットを借りがあると冗談を言っていました。
イベント後、彼は公にその約束を果たしました。
彼は、以下の製品の有料ユーザー使用制限をリセットしたと発表しました：
- ChatGPT Work
- Codex
このリセットは、このイベントに関連する一回限りのコミュニティジェスチャーでした。
これは以下のように解釈されるべきではありません：
- 永続的なプラン特典
- 契約上のサービスレベル契約
- 将来のリセットの保証
- Anthropicが提供する返金
- OpenAIがAnthropicアカウントを変更できる証拠
OpenAIは自社の使用制限を管理しています。
AnthropicはClaudeアカウントを管理しています。
ソティオー氏自身も、Anthropicで働いていないため、Anthropicの禁止問題を直接解決できないと指摘しました。
Sam Altmanが会話に参加
OpenAIのCEOであるSam Altmanは、後にこのイベントにおけるソティオー氏の役割について公にコメントしました。
WireがOpenAIのチームとAnthropicの祝賀イベントの規模を比較して尋ねた；th sottiaux氏は協力したいがAnthropicには所属しておらず、相手が同プラットフォームのツールを使って他のモデルに接続したことでアカウントを凍結するのか疑問視した；alex getman氏は指示通りに設定したところAnthropicにアカウントを凍結され、異議申し立てを行ったと述べた；最後にBoris Cherny氏がAnthropicが人材を募集中だと投稿した。
この一連のやり取りは、ある開発者が最初にアカウント凍結を受けた事件から、モデルとツールチェーンの移植性に関するより広範な議論へと発展した。
根本的な技術的問題は、ソーシャルメディアでの話題よりも長く続く可能性が高い。
開発者はますます組み合わせて使う傾向にある：
モデルA
+
ツールチェーンB
+
ツールC
+
サービスプロバイダーD
単一の垂直統合型テクノロジースタックを受け入れるのではなく。
なぜモデルとツールチェーンが互いに独立した競争レイヤーになりつつあるのか
プログラミングエージェントはモジュール化されつつある。
現代のプログラミングワークフローは複数のレイヤーに分けられる。
モデル
推論と生成のエンジン。
例えばGPT-5.6 SolやClaudeシリーズのモデル。
ツールチェーン
モデルをエージェントに変える実行環境。
例えばClaude CodeやCodex。
ツール
ファイル編集、シェル実行、ブラウザアクセス、MCP、検索などの機能。
ゲートウェイ
認証、ルーティング、ログ記録、モデルマッピング、プロトコル変換。
サービスプロバイダー
実際に推論を実行するサービス。
この階層化により、新たな比較の方法が生まれた。
開発者はこう問うかもしれない：
- どのモデルが最もコードをうまく書くか？
- どのツールチェーンの権限モデルが最適か？
- どのツールシステムが最速か？
- どのサービスプロバイダーが最も安いか？
- どのゲートウェイの可観測性が最も優れているか？
- どの組み合わせが最も信頼性が高いか？
その答えは、もはや単一のブランドに限定されないかもしれない。
同じモデル、異なるツールチェーン、異なる結果
Claude Code + GPT実験の目的は、同じモデルが異なるツールチェーン環境で異なる性能を発揮する可能性があるという観察にあった。
この違いには複数の合理的な説明がある。
ツールチェーンは以下を制御している：
- システムプロンプト。
- コンテキスト構築。
- ツールの説明。
- 検索動作。
- サブエージェントへの委任。
- リトライロジック。
- コンテキスト圧縮。
- 承認フロー。
- ファイル編集の方法。
したがって、効果的なシステムの性能は次のように表される：
モデル品質
×
ツールチェーン品質
×
ツール品質
×
コンテキスト品質
モデル名だけを比較するベンチマークは、開発者の実際の体験の大部分を見落とす可能性がある。
エージェントのモジュール化に伴い、サポート境界がより重要になる
モジュール化は開発者に自由をもたらす。
同時に、責任もより多くのコンポーネントに分散される。
Claude Codeがコミュニティプロキシを通じて非Claudeモデルに接続され、ツール呼び出しが失敗した場合、その欠陥の責任は誰にあるのか？
考えられる原因は以下の通り：
- Claude Codeがリクエスト形式を変更した。
- プロキシが特定のフィールドを誤って変換した。
- 上流モデルがそのツールスキーマをサポートしていない。
- ゲートウェイが特定のリクエストヘッダーを破棄した。
- モデルのコンテキスト制限が異なる。
- ストリーミング動作に差異がある。
- 特定のベータ版機能が欠落している。
Anthropicは合理的にこう言える：
Claude Code自体は、サポートされているClaudeパスではドキュメント通りに正常に動作する。
一方、プロキシのメンテナーはこう言うだろう：
コンバーターを更新する必要がある。
これが構成可能なインフラストラクチャのトレードオフである。
代替モデルを試すより安全な方法
Claude Codeスタイルのゲートウェイ設定で非Claudeモデルを使用してテストしたい場合、それは正式にサポートされたパスではなく実験として扱うべきである。
第一步：現在のClaude Codeゲートウェイドキュメントを読む
確認する項目：
- ゲートウェイの要件。
- サポートされるAPI形式。
- Base URLの設定。
- ツールとストリーミングの動作。
- モデル設定。
- 現在のサポート制限。
ドキュメントはソーシャルメディアの投稿より更新が遅いが、古いチュートリアルよりは速い。
第二步：独立したシェルコマンドを使用する
通常のClaudeパスは変更しない。
例えば：
claude
→ 公式Claudeルート
claudex
→ 実験的なローカルプロキシルート
これによりロールバックが容易になる。
第三步：意図的にゲートウェイを運用しない限り、プロキシはローカルのみで実行する
ローカル開発プロキシは以下にバインドできる：
127.0.0.1
全ネットワークインターフェースではなく。
認証とセキュリティレビューなしに、開発プロキシを公開してはならない。
第四步：Claude Codeバイナリを変更しない
ドキュメント化された環境変数と外部ゲートウェイを使用すれば、変更の検査と削除が容易になる。
第五步：自分自身の認可されたプロバイダー資格情報を使用する
アカウントセッションを共有したり、トークンを盗んだり、使用権限のない資格情報を使用してはならない。
第六步：使い捨てのテストプロジェクトから始める
以下から始めてはならない：
- 本番環境の鍵。
- 顧客のリポジトリ。
- デプロイ資格情報。
- 取り返しのつかないローカル状態。
まず、ファイル編集、ツール呼び出し、ストリーミング、コンテキスト処理が期待通りに動作するか検証する。
第七步：プロキシが変換できない機能を無効化するかテストする
ツール検索はその一例である。
その他のゲートウェイ固有の機能も調整が必要になる場合がある。
第八步：実際に使用しているモデルを記録する
プロキシにより、フロントエンドの表示とモデル名が一致しない可能性がある。
再現性のために以下を記録する：
フレームワーク
ゲートウェイ
上流プロバイダー
実際のモデル
推論設定
プロキシバージョン
Claude Codeバージョン
第九步：アカウントの健全性を監視する
サービスに以下の表示がある場合：
- 警告。
- 不審なログインメッセージ。
- セキュリティ保護通知。
- 認証失敗。
リトライを繰り返すのではなく、停止して調査すべきである。
第十步：実験を削除できる準備をする
Claude Codeのアップデートやプロバイダーの変更により、非公式の互換パスが壊れる可能性がある。
設定は元に戻せる状態を保つ。
現在のAnthropicドキュメントが本番環境のベースラインとして優れている
サポートされるClaude Codeデプロイを必要とする組織にとって、Anthropicのドキュメントには複数の公式パスが記載されている。
これには以下が含まれる：
- Anthropic API。
- Amazon Bedrock。
- Google CloudのAgent Platform。
- Microsoft Foundry。
- サポートされるClaudeトラフィックをルーティングするエンタープライズLLMゲートウェイ。
これらのパスは、リクエストを無関係なモデルプロバイダーに変換するよりも明確なサポート期待値を持つ。
ビジネス要件が単に「Claudeアクセスを自社のゲートウェイの背後に集約する」ことなら、サポートされるゲートウェイアーキテクチャを使用すべきである。
要件が「Claude Codeのフレームワークを他のベンダーのモデルと一緒に使う」ことなら、サポートされていない統合に足を踏み入れていることを理解する必要がある。ただしCherny氏は、それだけでは凍結の理由にはならないと述べている。
すでにClaude Codeプロキシを使用している場合の対処法
一度の公開された凍結事件でパニックになる必要はない。
公開された証拠は、Anthropicがプロキシユーザーを禁止する一般的なポリシーを制定したことを示していない。
ただし、その設定の構成をレビューする価値はある。
確認項目：
- 公式のClaude Code CLIを使用しているか？
- そのプロキシは信頼でき、継続的にメンテナンスされているか？
- 資格情報はどこに保存されているか？
- そのプロキシはプロンプトや機密情報を記録しているか？
- ネットワークポートをlocalhostの外部に公開しているか？
- 実際にコードを受信しているプロバイダーはどこか？
- その設定は雇用主のセキュリティポリシーに違反していないか？
- Claude Codeのどの機能が黙って無効化されているか？
- その環境を再現できるか？
- 完全かつきれいに削除できるか？
サードパーティのプロキシ自体がもたらすセキュリティリスクは、モデルルーティング戦略の問題よりも大きい可能性がある。
サードパーティのプロキシセキュリティは注目に値する
プロキシは非常に機密性の高い情報を見る可能性がある：
- ソースコード。
プロンプト。
ツール定義。
ファイルパス。
環境の詳細。
API認証情報。
プロキシ出力。
使用する前に、以下を確認してください：
- ソースコード。
- ライセンス。
- リリース履歴。
- メンテナー。
- ネットワーク動作。
- 機密情報の取り扱い。
- ログのデフォルト設定。
- 更新メカニズム。
人気のあるリポジトリだからといって、セキュリティ審査を受けているとは限らない。
Anthropic は、サードパーティのゲートウェイを承認、保守、監査していないことを明言している。
なぜこの出来事が Claude Code 自体よりも重要なのか
この出来事は、AI 開発者ツール分野におけるより広範な変化を浮き彫りにしている。
第一世代の AI プログラミングアシスタントは垂直統合型だった：
ベンダーのモデル
+
ベンダーのインターフェース
+
ベンダーのツール
一方、開発者の新たな好みはよりモジュール化されている：
好みのモデル
+
好みのフレームワーク
+
好みのツール
+
好みのプロバイダー
これにより、以下に関するより明確な標準への圧力が生まれている：
- モデルの移植性。
- ゲートウェイの互換性。
- ツールパターン。
- コンテキストメタデータ。
- 利用ポリシー。
- アイデンティティと課金。
- テレメトリ。
LLM ゲートウェイとオープンプロトコルの台頭により、このモジュール化された未来はより現実的になっている。
しかし、サポート範囲とポリシーの境界は、まだどこでも追いついていない。
この出来事が証明できることではない
この停止事件は、オンラインで多くの強い主張を生んだ。
その一部は、証拠が裏付けられる範囲を超えている。
Claude Code で GPT を使用しただけで Anthropic がユーザーを停止することを証明するものではない
Cherny 氏は、Anthropic がフレームワークを他のモデルに使用しただけでユーザーを停止することはないと明確に述べている。
プロキシが停止の正確な引き金であることを証明するものではない
タイミングは示唆的だが、Anthropic は具体的な分類器や完全なアカウント調査結果を公表していない。
Anthropic が Claude Code での GPT の使用を支持していることを意味するものではない
同社のドキュメントは、ゲートウェイを介して Claude 以外のモデルにルーティングすることはサポートされていないと明記している。
そのエイリアスが永続的に有効であることを意味するものではない
Claude Code の変数と内部動作は、いつでも変更される可能性がある。
OpenAI がすべてのプロキシパターンをサポートしていることを意味するものではない
Sottiaux 氏はこの特定の実験を共有したが、公開されたソーシャルメディアの投稿が、すべてのサードパーティプロキシ、プロバイダー、アカウント設定に対する汎用互換性の保証に相当するわけではない。
停止された場合に必ずリセットできることを意味するものではない
そのリセットはコミュニティのアクションであり、OpenAI の利用制限に影響を与えたもので、恒久的なポリシーではない。
実用的なポリシーマトリクス
現在の状況は次のようにまとめられる：
| 質問 | 2026年8月13日時点で最も裏付けのある回答 |
|---|
| Claude Code は LLM ゲートウェイに接続できるか？ | できる。Anthropic のドキュメントにゲートウェイサポートが記載されている |
| 互換ゲートウェイは技術的にカスタムモデル ID を公開できるか？ | できる |
| Anthropic は Claude Code の背後にある Claude 以外のモデルを公式にサポートしているか？ | していない |
| Anthropic はツールフレームワークで他のモデルを使用しただけでユーザーを停止するか？ | Boris Cherny 氏は停止しないと述べている |
| Alex Getman 氏のアカウントは停止されたか？ | はい、彼の公開報告によると |
| Anthropic はプロキシがポリシー違反の原因であると述べたか？ | 述べていない |
| Cherny 氏は何が原因だと言ったか？ | ほぼ間違いなく別のアカウント分類器 |
| CLIProxyAPI は Anthropic の製品か？ | 違う |
| プロキシパスが継続的に利用可能であることは保証されるか？ | 保証されない |
| 誤った停止に対する公式の異議申し立てチャネルはあるか？ | ある |
これは、この出来事を単に「Claude が GPT ユーザーを停止した」という話として見るよりもはるかに有用である。
よくある質問
Claude Code で GPT-5.6 Sol を使用できますか？
サードパーティの互換ゲートウェイは、技術的に Claude Code CLI を他のプロバイダーにルーティングでき、公開されたコミュニティ設定がこれを実証している（例：GPT-5.6 Sol の使用）。しかし、Anthropic のドキュメントは Claude Code を Claude 以外のモデルにルーティングすることをサポートしていないと述べており、そのためこれはサポートされていない実験的設定と見なすべきである。
Claude Code ツールフレームワークで他のモデルを使用したことで Anthropic に停止されることはありますか？
Claude Code の責任者である Boris Cherny 氏は、Anthropic が他のモデルでツールフレームワークを使用しただけでユーザーを停止することはないと公言している。しかし、これはアカウントが他のセキュリティ、ポリシー、アカウント完全性、または分類器の理由で停止されないことを保証するものではない。
なぜ Alex Getman 氏の Anthropic アカウントは停止されたのか？
Getman 氏は、ローカルホストのプロキシ設定をテストした直後に、アカウントが「疑わしいシグナル」により停止されたと述べている。Cherny 氏は、原因はほぼ間違いなく別のアカウント分類器であり、Anthropic が調査中であると述べている。Anthropic は詳細な分類器レポートを公開していない。
CLIProxyAPI は Anthropic または OpenAI から公式にサポートされていますか？
いいえ。CLIProxyAPI は独立したオープンソースプロジェクトである。Anthropic はサードパーティのゲートウェイを承認、保守、監査しないと明言しており、OpenAI も CLIProxyAPI を公式 Codex 製品ドキュメントに含めていない。
Claude Code は LLM ゲートウェイを公式にサポートしていますか？
はい。Anthropic のドキュメントには、認証、ルーティング、予算管理、使用状況追跡、エンタープライズ展開のための LLM ゲートウェイ設定が記載されている。同時に、同ドキュメントは Claude Code を Claude 以外のモデルにルーティングすることをサポートしていないとも述べている。
ANTHROPIC_BASE_URL は何に使用されますか？
Claude Code はカスタムベース URL を使用して、デフォルトのエンドポイントに直接送信する代わりに、設定されたゲートウェイを介してリクエストを送信できる。ゲートウェイの動作はツール検索、モデル検出、コンテキスト処理、その他の機能に影響を与える可能性があるため、オペレーターは現在の Claude Code ゲートウェイのドキュメントに従うべきである。
誤った Claude 停止に対してどう異議を申し立てるのですか？
Anthropic は、停止されたアカウントで claude.ai にログインし、制限付きアカウントのインターフェースに表示される異議申し立てフォームに記入するよう指示している。Safeguards チームがこのケースを審査できる。有用な技術的コンテキストを提供することはできるが、API キー、OAuth トークン、その他の機密情報を決して公開しないこと。
Tibo Sottiaux 氏はその後実際に Codex の制限をリセットしましたか？
はい。Sottiaux 氏は、その交流の後、有料 ChatGPT Work および Codex ユーザーの利用限度額をリセットしたと公言している。これは特定のコミュニティアクションであり、恒久的な権利や将来のリセットの約束ではない。
関連ツール
- Claude Code：ソフトウェア開発ワークフローのための Anthropic 公式コマンドラインエージェント。
- CLIProxyAPI：複数の AI モデルプロバイダーに互換インターフェースを提供する独立したオープンソースプロキシ。
- Alex Getman の claude-proxy：停止事件後に公開された公開のローカルホスト専用設定。
- Codex：OpenAI 公式のソフトウェアエンジニアリングエージェントおよび開発環境。
- LiteLLM：複数のモデルプロバイダーの API を正規化するためによく使用される独立した LLM ゲートウェイおよび互換レイヤー。
- [Model Context
Protocol](https://modelcontextprotocol.io/)：Claude Codeなどのエージェントアプリケーションがツールや外部システムに接続するために使用するオープンプロトコル。
関連リンク
- Tibo Sottiaux氏によるオリジナルのClaude Code + GPT投稿：7月12日の公開投稿で、3ステップのエージェントとエイリアス手法を紹介。
- Alex Getman氏の一時停止報告：開発者による公開説明で、一時停止の出来事とポリシー明確化の要請について述べている。
- Boris Cherny氏の応答：Claude Code責任者が、ユーザーがハーネスを他のモデルと併用してもAnthropicはアカウントを停止しないと表明。
- Anthropic：他のLLMゲートウェイ：ゲートウェイと非Claudeルーティングの非サポート状態を説明する公式Claude Codeドキュメント。
- Anthropic：Claude Codeモデル設定：モデルID、カスタムゲートウェイモデル、コンテキスト設定、関連する環境変数に関する最新ドキュメント。
- Anthropic：安全措置の警告と異議申し立て：アカウント停止が誤りだと考えるユーザー向けの公式異議申し立てガイド。
- OpenAIフォーラム：Codexはすべての人のために：OpenAI公式フォーラムページで、Thibault Sottiaux氏がCodexの責任者であることを確認。
- OpenAI GPT-5.6：GPT-5.6シリーズ（GPT-5.6 Solを含む）に関する公式情報。
まとめ
ある開発者がローカルプロキシを介してGPT-5.6 Solを未変更のClaude Code CLIにルーティングした直後にアカウント停止となったが、最も有力な公開説明は、Anthropicが単にユーザーがClaude Codeハーネスの背後に他のモデルを配置しただけでアカウントを停止するという主張を支持していない。Boris Cherny氏は、この停止はほぼ確実に別のアカウント分類子によって引き起こされたと述べている。
一方、Anthropic自身のドキュメントは、非Claudeモデルへのルーティングがサポートされていないことを明確に示している。Claude Codeは公式にゲートウェイをサポートしているが、Anthropicはゲートウェイが非Claudeバックエンドに接続された場合のサポート、互換性、トラブルシューティングを保証していない。
これにより、この出来事はポリシーと製品サポートの差異に関する有用なケーススタディとなる。ある技術が実装可能で、それ自体は禁止されていないとしても、ベンダーのサポート対象構成を超えている可能性がある。
最も安全な結論は次の通り：ツールの自由は許容されるかもしれないが、サードパーティプロキシを介してClaude Codeを他のモデルにルーティングする場合、互換性、セキュリティ、運用上のリスクは自己責任で負うことになる。