docs/release-notes/v3.18.0-ja.md
本リリースでは、まったく新しい 2 つのことができるようになります。xAI の Grok CLI（Grok Build）を CC Switch で管理する——8 番目の管理対象アプリとして、プロバイダーのワンクリック切り替え、MCP / Skills 同期、プロキシテイクオーバー、使用量統計をすべて利用できます。そして Grok を Claude Code、Claude Desktop、Codex へ接続する——xAI Grok アカウントで直接サインインする方法（デバイスコード認証、API key 不要、Grok サブスクリプションで動作。Codex 側には厳格ゲートウェイ互換レイヤーがあり codex 0.142+ でも動きます）と、xAI API key で接続する方法（Codex にはネイティブ Responses 直結プリセット、Claude Code はローカルルーティング経由）の両方に対応します。修正も重要です。v3.17.0 で混入した Codex 使用量の二重計上を修正し、アップグレード後にデータを自動再構築してダッシュボードの数字を実態に戻します。codex 0.144.5+ がモデルカタログ起因で起動できない問題も修正。Windows でのプロバイダー切り替え時にコンソールウィンドウが一瞬表示されたり UI が固まったりする問題も解消しました。診断ログは「起動のたびに消去」から、再起動をまたいで保持・サイズローテーション・全面的な秘密情報除去へ移行し、UI クラッシュも真っ白な画面ではなくディスクに記録が残ります。
api.x.ai へネイティブ直結する「xAI (Grok)」プリセットがあり、Claude Code は本リリースの新ガイドに沿ってローカルルーティングで接続できます。既定モデルはいずれも grok-4.5 です。本リリースの新機能は、主にプロバイダープリセット、「設定 → OAuth 認証センター」、使用量ダッシュボードにあります。以下のドキュメントもあわせてご覧ください：
/v1/messages ルートに対して Anthropic Messages を話し、ローカルプロキシが各リクエストを上流の Responses プロトコルへ変換します——ゲートウェイの API key、xAI のようなネイティブ Responses endpoint、ChatGPT サブスクリプションの Codex サービスのいずれにも使えます。/v1/messages のみを提供する Claude 系ゲートウェイへ Codex を接続します。[!WARNING]
唯一の公式チャネル（必ずお読みください）
CC Switch は完全に無料・オープンソースのデスクトップアプリで、ユーザーから料金を徴収することはありません。本ソフトウェアは下記の公式チャネルからのみ入手してください：
チャネル 唯一の公式 公式サイト ccswitch.io ソースコード github.com/farion1231/cc-switch ダウンロード GitHub Releases 作者 @farion1231 偽サイト通報 GitHub Issues 料金請求・チャージ・認証情報の提供を求める「CC Switch」サイトやクライアントはすべて偽物です。 支払いを誘導された場合は直ちに操作を中止し、GitHub Issues からご報告ください。
CC Switch v3.18.0 の 2 本柱はどちらも xAI Grok を中心に据えています。1 つ目は Grok Build の管理対象アプリ入りです。xAI の Grok CLI（live 設定 ~/.grok/config.toml）が、Claude Code、Claude Desktop、Codex、Gemini CLI、OpenCode、OpenClaw、Hermes に並ぶ 8 番目の管理対象アプリになりました——プロバイダーの追加 / インポート / ワンクリック切り替え、MCP・Skills の双方向同期、ディープリンクインポート、独立したプリセットリスト、専用ルート名前空間つきのプロキシテイクオーバー。併設の「Grok 公式」エントリは公式ログイン状態の検出とインポートに対応し、CC Switch が公式認証情報に触れることはありません。2 つ目は xAI Grok アカウントの OAuth サインインです。デバイスコード認証が API key を置き換え、ローカルプロキシがリクエストごとにアクセストークンを注入します。Claude Code / Claude Desktop 側では Anthropic Messages → xAI Responses の変換を行い、Codex 側は管理下 OAuth プリセットと専用互換レイヤーを備えます——codex 0.142+ が発する ChatGPT バックエンド固有の形（namespace ツール宣言や非公開フィールド）を決定的に平坦化・除去し、厳格に解析する xAI ゲートウェイが 422 を返さなくなります。API key ユーザーには、変換を一切通さない「xAI (Grok)」ネイティブ Responses 直結プリセットも用意しました。
正確性の面では、v3.17.0 の Codex 使用量二重計上を集中的に修正しました。fork / サブエージェントログ冒頭にある親スレッド履歴のリプレイを新規使用量として取り込まなくなり（パーサーは明示的な親識別子とトークン署名の照合のみを信頼）、アップグレード後に一度だけ使用量を自動再構築（schema v16）、使用量ページには手動再構築ボタンを追加。プロキシ側の使用量記録は冪等になり（同じレスポンスのリプレイが重複行を積み上げない）、大量セッションのインポート中に使用量ページが固まる問題も解消しました。Codex 変換レイヤーにはさらに 4 つの修正——tool schema の object 型への正規化、reasoning のターンをまたぐ前方アタッチ、ストリーミング並列ツール呼び出しの ID と順序の保持、codex 0.144.5+ が要求するカタログフィールドの補完。診断まわりも成熟し、ログは再起動をまたいで保持・サイズローテーション・全出口で秘密情報除去、UI クラッシュはエラーバウンダリで捕捉してディスクへ記録します。ほかにも Kimi K3 のプリセットと価格、OpenClaw プリセット価格の修正、SudoCode.us の復活、トレイの初回言語がシステムロケールに従う改善などを含みます。
リリース日: 2026-07-21
Stats: 52 commits | 217 files changed | +21,452 / -6,285 lines
xAI の Grok CLI（Grok Build、live 設定 ~/.grok/config.toml）が CC Switch の第一級市民になりました。プロバイダーの追加 / インポート / ワンクリック切り替え（切り替え後は「Grok Build を再起動して適用」のトースト表示）、アプリ表示と設定ディレクトリ上書きの設定、セッション管理と使用量ダッシュボード対応、初回起動時のプロンプト自動インポート、ccswitch:// ディープリンクによるプロバイダーインポート、そしてローカルプロキシテイクオーバー——専用の /grokbuild/v1/responses ルート名前空間、独立した failover キュー、アプリ別プロキシ設定を持ちます。転送は Codex の Responses 経路を再利用しますが、Codex のプロバイダー名前空間や circuit breaker の状態を共有することはありません。
MCP サーバーは Grok の [mcp_servers] テーブルと双方向同期し、方言の差異も吸収します。Grok は command / url からトランスポートを推定し headers フィールドを使うため、エクスポート時は明示的な type を取り除き http_headers を headers にリネームし、インポート時は逆方向に推定して戻します。Skills にも Grok Build の有効化フラグが付きました。
プリセットはあえて Codex のリストを流用していません（初期の実装では中国向け直結プロバイダーや Codex の既定モデルが Grok のフォームに混入していました）。Grok Build 専用に整理したリストとして、実際に Grok モデルを扱うアグリゲーターと中継サービスのみを収録し、既定モデルは grok-4.5（名前空間型ルーターでは x-ai/grok-4.5）に正規化しています。ツールパネルでの Grok インストールは xAI 公式インストーラー（x.ai/cli/install.sh / install.ps1）を優先し、npm パッケージ @xai-official/grok をフォールバックにします。ネイティブと確認されたインストールは grok update で自己更新し、npm インストールは npm 経由の更新を維持——自己更新はネイティブ検出が確定した場合にのみ動くため、別種のインストールを壊すことはありません。4 言語の UI 文言も同期済みです。（#5453）
新しい「Grok 公式」プロバイダーエントリは、Grok CLI 内蔵の xAI OAuth ログインに対応します。選択すると接続フィールドが隠れ、空の ~/.grok/config.toml を書き込みます。CC Switch が公式認証情報を保存したり触れたりすることはありません。live 設定の読み取り・バックアップ・公式状態の書き込みは構文レベルのみの TOML 検証に変更され、公式ログイン状態（空の設定）が正常に往復します。Grok が公式ログイン状態のときに「live 設定からインポート」すると、エラーではなく「Grok 公式を現在のプロバイダーに設定しました」となり、Codex と同じ挙動になります。公式状態の検出は意図的に手動インポートコマンドだけに配線されています——起動時の自動インポートは公式状態の設定を引き続き拒否するため、削除した「Grok 公式」エントリが次回起動時に復活することはありません。公式ログイン設定へのプロキシテイクオーバーは自動的にスキップされ、手動操作でも明確に拒否されます。既存の「公式プロバイダーはプロキシしない」方針と一貫しています。
Claude Code と Claude Desktop に「xAI (Grok)」プリセットが加わり、API key の代わりに OAuth デバイスコードログインを使います。リクエストはローカルプロキシを通り、Anthropic Messages → xAI Responses API の変換とリクエストごとのアクセストークン注入が行われます。既定モデルは全 tier で grok-4.5 です（Claude Desktop プリセットは claude-* 形式のロール ID を上流の grok-4.5 にマッピングし、Desktop のサードパーティモデル検証を通過させます）。
「設定 → OAuth 認証センター」に xAI セクションが追加されました。デバイスコードログイン（コピー可能なユーザーコード、確認リンク、待機 / キャンセル / 再試行）、複数アカウントと既定アカウントの選択、アカウント別の削除、再認証バッジ——refresh token が失効したアカウントは消えるのではなく「期限切れ」として表示され続け、認証状態は 15 秒ごとに再取得されるため、サーバー側の失効も自然に表面化します。
連携の境界は固定されています。フォームの endpoint / 形式フィールドをどう変えても上流は常に https://api.x.ai/v1/responses（Responses 形式）。OAuth endpoint は OIDC discovery で解決しますが https の auth.x.ai のみに厳格検証。refresh token は ~/.cc-switch/xai_oauth_auth.json（Unix ではパーミッション 0600、access token はメモリのみ）。OAuth のエラーボディはエラーメッセージにもログにも決して入りません。grok-4.5 の価格（100 万 token あたり入力 $2 / 出力 $6 / キャッシュ読み取り $0.50）も登録され、使用量が $0 と記録されなくなります。既存データベースは次回起動時に自動で行を取り込みます。4 言語対応。利用前に「リスク通知」のクライアント識別情報の開示をお読みください。
OAuth を使わず、従量課金の xAI API key しかない場合でも、Claude Code へ接続できます。xAI の API endpoint は標準の Responses プロトコルなので、通常の Responses プロバイダーとして追加してください——カスタムプロバイダーに https://api.x.ai/v1 と API key を設定し、上流形式に Responses を選ぶと、ローカルルーティングが Anthropic Messages ↔ Responses を変換します。Claude Code で Codex 系プロバイダーを使うガイドと同じ手順です。Codex 側には既製の API key プリセットがあります（次節参照）。
Codex には xAI へ直結する 2 つの道があります——Grok サブスクリプションなら管理下 OAuth、API key ならネイティブ直結です：
type:"namespace" ツール宣言は xAI の厳格パーサーで即 422。ほかに prompt_cache_retention、safety_identifier、external_web_access、additional_tools キャリア、grok-4.5 が対応しないサンプリングパラメータ）。そのため OAuth ルートはネイティブパススルーの上に互換レイヤーを重ねます。namespace ツールはトップレベルの function ツールへ平坦化（Chat 経路と同じ sha256 切り詰め命名）し、レスポンス側ではストリーミング・非ストリーミングの両方で namespace 形へ復元、未対応フィールドは除去——すべて決定的なフィールド削除 / 構造変換であり、意味的な書き換えは一切ないため、プロンプトキャッシュの前方一致は安定を保ちます。このレイヤーは xAI OAuth プロバイダー型だけにゲートされ、他のプロバイダーのトラフィックには触れません。api.x.ai/v1 のネイティブ Responses に直結し、500K コンテキストの grok-4.5 カタログエントリを内蔵します。このプリセットには上記の xAI 専用互換変換は適用されません——codex 0.142+ の API key ユーザーは依然 xAI の厳格パーサーに当たる可能性があり、完全互換の道は OAuth プリセットです。xAI OAuth のトークンエラーは再試行不能に分類されるため、failover が会話を別の Grok アカウントへ静かに移すことはありません。
React のエラーバウンダリが UI 全体（データベース復旧画面を含む）を包むようになりました。レンダラーがクラッシュすると、真っ白なウィンドウの代わりに「インターフェースでエラーが発生しました」カードと再読み込みボタンが表示され、グローバルの error / unhandledrejection ハンドラーがレンダラーのエラーをディスクへ永続化します——以前は JS クラッシュの証拠がディスクに一切残りませんでした。フロントエンドが書き出すログはすべて二層の秘密情報除去を通ります。構造化シリアライザーが機微なプロパティ名（tokens / apiKeys / credentials の変種を正規化して照合し、ネストされたオブジェクトを含む値全体を隠す）と値の形（トークン接頭辞、PEM ヘッダー、高エントロピーな不透明文字列）で除去し、次に唯一のテキスト出口の順序付き正規表現チェーンが URL クエリ値と認証情報、認証ヘッダーとスキーム、名前付きシークレットコンテナ（二重エンコードされた JSON も対象）をカバーします。文字列として届いた JSON は再パースして構造的に除去し、過大な構造化入力は切り詰めではなく全体を破棄します——切り詰められた JSON 文字列は弱いテキスト正規表現にフォールバックして漏えいの恐れがあるためです。設定のトグル名も実態に合わせて変更しました。「アプリ診断ログ」（cc-switch.log）と、プロキシの「リクエスト使用量を記録」（統計データベースであり、もともとテキストログではありません）です。4 言語同期。
使用量ダッシュボードのメンテナンスに「Codex 使用量を再構築」が加わりました。データベースをバックアップした後、codex_session ソースの明細行、対応する _codex_session 日次集計、Codex 同期カーソルだけを消去し、修正済みパーサーで全 rollout ファイルを最初から再インポートします——下記の二重計上バグで膨張したデータベースの復旧経路であり、親ログが復元された保留 fork ファイルの再試行経路でもあります。手動再構築は事前バックアップを書き込めない場合にハードフェイルします（自動移行版は警告のみ。アップグレード後にバックアップディレクトリ書き込み不能で起動がブロックされる方が悪い結果だからです）。バックアップ → リセット → 再インポートの全工程はセッション同期ロックを保持し、60 秒間隔のバックグラウンド同期が消去と交錯できません。完了時にはちょうど 1 回のフロントエンド更新通知を必ず送ります——再インポートが 0 行やエラーで終わった場合も含めて——のでダッシュボードがリセット前の数字のまま止まることはありません。カーソルの掃除はパスの形（sessions / archived_sessions セグメント配下の rollout-{uuid} ファイル名）だけで照合するため、旧 CODEX_HOME 配下に記録されたカーソルも掃除できます。4 言語同期。
セッション同期の結果に filesScanned、deferredFiles、suspectedDuplicates が加わりました。deferredFiles は、親ログの欠落や親マーカーの矛盾がある fork rollout をカーソルを書かずに保留し、後の同期や手動再構築で再試行するものです——推測でインポートしません。suspectedDuplicates は、挿入後に各行を同一フィンガープリントの既存行と照合（idx_request_logs_dedup_lookup_expr 式インデックス経由）し、ヒットごとに警告を記録します。二重計上バグが将来再発しても、総量を静かに膨らませるのではなく、ログの中で自ら名乗り出ます。
Codex / Hermes / OpenClaw / OpenCode の Kimi オープンプラットフォームプリセットに Kimi K3（1M コンテキストウィンドウ）を追加しました。K2.7 Code の後ろに追加したため、既存の既定モデルの挙動は変わりません。内蔵価格テーブルには kimi-k3（公式表示価格：100 万 token あたり入力 $3 / 出力 $15 / キャッシュ読み取り $0.30）と裸の k3 エイリアスを追加——Kimi For Coding サブスクリプションはモデルを短縮 id k3 で報告するため、これがないとどの価格行にも一致しません（既存の hunyuan-hy3 / hy3 ペアと同じ前例です）。既存データベースは次回起動時に両行を自動で取り込み、ユーザーが編集した価格には触れません。
たまたま「SudoCode」という名前を共有する無関係な 2 社が、別々のプリセットになりました。スポンサーは「SudoCode.chat」に改名し、以前その場で置き換えられていた「SudoCode.us」が元の endpoint・モデル・アイコンとともに復帰。Hermes の slug も区別され、追記型の ~/.hermes/config.yaml の中で両者が共存できます。新しい Grok Build プリセットリストを含めると、SudoCode.chat は 7 アプリ、SudoCode.us は全 8 アプリに収録されています。
cc-switch.log は起動のたびに消去されなくなりました——クラッシュを説明できたはずのログが、アプリを開き直したときには消えていたのです。代わりに 20 MB でローテーションし、アーカイブを 4 つ保持します（上限約 100 MB。以前は単一ファイルが 1 GB まで膨張し得ました）。これまで無制限だった crash.log は 5 MB ローテーション・アーカイブ 2 つになり、チェック / ローテーション / 追記の一連の処理を 1 つのロックで包んで、並行 panic がアーカイブを失わないようにしました。
ログの永続化は、秘密情報の平文がそのまま露出リスクになることを意味します（ユーザーはこれらのファイルを公開 issue に添付します）。そこで同じ変更で、バックエンドのすべてのログ出口を洗浄しました。上流 URL は userinfo / query / fragment を取り除いた形でのみ記録（置換できる既知のシークレットがない場合は origin のみ。パスに認証情報が埋まっている可能性があるため）。リクエストとレスポンスのボディは一切記録せず、バイト数、短いハッシュ、または安全な分類（sse / html / json-like / binary-or-encoded など）に置き換え——変換デバッグに必要なシグナルは残り、中身は残りません。レスポンスヘッダーは許可リスト方式（リスト外は名前のみ記録）。現在使用中のシークレット値（API key、access token)は、それを含むあらゆる記録 URL から置換されます。MCP カスタムフィールドの値は省略。ログプラグインの登録は早められ（アップデーターや起動時の障害が診断可能に）、永続化されたログレベルはデータベースが開き次第適用され、障害時は Info へ安全側に倒れます。「診断ログを有効化」スイッチはフロントエンド発のログ書き込みも制御するようになりました。アップグレード前の古いログファイルは遡って洗浄されません——「アップグレード時の注意」を参照してください。
プリセット選択の既定順序が 4 層になりました。公式が最初、次に主要パートナー、その後にスポンサープリセット（README のスポンサー表と同じ順序。プリセットファイルも物理的に並べ替えて揃えました）、最後に残りすべてをファイル順ではなく表示名のアルファベット順で並べます。複数の層に該当するエントリは最も早い層にだけ現れ、重複表示はありません。
RunAPI、ClaudeCN、ZetaAPI、APINebula プリセットの key 申請リンクを、各社の現在の登録 / 紹介ページに更新しました（ClaudeCN はドメインも移転：claudecn.top → claudecn.ai）。紹介タグはこれらのリンクと README に限定され、公式サイトリンクと API endpoint には手を付けていません。
v3.17.0 の使用量膨張を修正します。Codex タスクの fork やコピーモードでのサブエージェント生成で、親会話の token 履歴が新規使用量として再計上されていました——1 日の使用量が数十億 token 跳ね上がる、親子でバイト単位に同一の行が並ぶ、空の fork が消費していない使用量を背負う、といった報告がありました。fork / サブエージェントの rollout ファイルは冒頭で親スレッドの履歴をリプレイします。旧パーサーは引き継ぎ境界をヒューリスティックに探していました（最初の thread_settings_applied イベント、オブジェクト形の subagent ソースマーカー）。親自身の設定変更がリプレイに現れると境界が早すぎる位置に落ち、現行の文字列形ソースマーカーはまったく認識されず、リプレイされた親履歴が丸ごとインポートされていました。新パーサーは明示的な親識別子だけを信頼します——子の session_meta の forked_from_id または source.subagent.thread_spawn.parent_thread_id。両者が矛盾する場合はファイルを保留します。スレッドの識別は rollout ファイル名の UUID に固定し、親 rollout 自身の fork 前 token カウント系列を読み込み、トークン署名の照合で子のリプレイ済みプレフィックスを取り除きます。リプレイイベントは累積ベースラインの復元にのみ使われ、行として挿入されることはありません。リプレイ履歴を持たないサブエージェントログは実使用量として計上されるようになり、実際のサブエージェント消費がリプレイ疑いとしてスキップされる逆方向の計上漏れも同時に修正しました。（#5335、#5433、#5381）
終端の使用量イベントにメッセージ id がない場合（ローカルプロキシ経由の Codex /responses トラフィックでは通常）、重複排除キーはランダム UUID にフォールバックしていました——同じ上流レスポンスの再試行 / リプレイのたびに新しいキーが作られ、INSERT OR REPLACE が毎回新しい行を積み上げます。ある報告者のデータベースには同じ使用量の組み合わせが 2,078 回入っていました。パーサーはキーをレスポンスのエンベロープ自体から取るようになりました——Codex response.completed イベントの response.id（response.created の id は破棄）、Chat Completions の chatcmpl id、Gemini の responseId——スコープは session:{app_type}:{provider_id}:{id}。failover で同じレスポンスが別プロバイダーに再生された場合もプロバイダーごとに 1 回ずつ課金され、プロバイダー間で衝突しません（Claude は裸の session:{id} 形を維持し、プロキシ行はセッションログのインポートと収束し続けます）。エンベロープ id がまったくない場合のフォールバックは、ランダム UUID ではなくレスポンスの使用量セマンティクスに対する決定的 SHA-256 です——同一のリプレイが同じキーに衝突しなければ重複排除は成立しません。最終的なデータベース書き込みも、無条件の REPLACE から重複排除ウィンドウ内の「存在しなければ挿入」に変わりました。（#5496）
大きなインポートの実行中に使用量ページを開くと、UI 全体が固まることがありました。行を挿入するたびに更新通知が飛び、通知のたびにフロントエンドが約 10 個の使用量クエリをすべて再実行し、それらのクエリが、数十 MB の rollout ファイルを 1 行ずつ解析中のインポーターと唯一のデータベース接続を奪い合う——重複で膨張したデータベースでは三者が互いに増幅し合っていました。セッション同期は 1 パス完了ごとに 1 回だけ通知するようになり、すべてのセッションインポーターはシングルフライトロックの後ろで直列化され（手動の「今すぐ同期」は実行中のパスと競争せず、後ろに並びます）、ブロッキングな解析処理は専用のブロッキングスレッドへ移されて UI コマンドを駆動する非同期ランタイムを飢えさせなくなり、60 秒間隔のバックグラウンド実行は取りこぼし分をまとめて実行せずスキップします。
codex ≥ 0.144.5 は外部モデルカタログを厳格に解析し、エントリに supports_reasoning_summaries がないとファイル全体を拒否します——Codex CLI もデスクトップアプリも起動できず、生成カタログを削除しても、プロバイダーを保存するたびに同じ形で再生成されるため解決しませんでした。根本原因は、CC Switch がカタログのテンプレートをマシン共有の models_cache.json から複製していることです。そのフィールド構成は最後に書き込んだ codex プロセス次第で、共存する旧版 codex が新パーサー必須のフィールドを持たない形でキャッシュを書き換え続けていました。生成カタログは、同梱の静的テンプレートからパーサー必須フィールドを補完するようになりました。補完は欠けている場合のみで（動的な値が常に優先）、「欠落 = パーサー既定値」のセマンティクスを保つべきオプションの能力フィールドは意図的に補完しません。
Windows でプロバイダーを切り替えたりテイクオーバーを切り替えたりすると、コンソールウィンドウが一瞬表示され、UI が最大約 2 秒固まっていました。原因は 3 つ、修正も 3 つです。codex debug models --bundled プローブは cmd.exe 経由で codex.cmd を起動しますが、GUI サブシステムのアプリではこれが独自のコンソールを生成します——子プロセスは CREATE_NO_WINDOW で作成するようにしました。モデルカタログのテンプレートは切り替えのたびに再生成されていました——初回の成功ロード後にプロセス全体でキャッシュし（失敗は再試行可能のままなので、初回プローブの失敗がキャッシュを汚しません）、Codex CLI の起動はアプリ実行ごとに最大 1 回になりました。switch_provider はメインスレッド上の同期コマンドでした——非同期化して実処理をブロッキングスレッドに移し、アプリ別の切り替えロックによる直列化は維持しています。フリーズ修正は全プラットフォームに効き、コンソール表示の修正は Windows 固有です。
Codex の組み込みツール（codex_app__automation_update など）は parameters: null（または type: null）を宣言しますが、DeepSeek のような厳格な OpenAI 互換上流はリクエスト全体を 400 で拒否し、プロキシ経由のツール利用セッションが死んでいました。Responses→Chat ブリッジはすべてのツールの parameters を type:"object" schema に正規化します。null または欠落（ネスト形の欠落を含む）は {"type":"object","properties":{}} に、object 以外の type（type: null を含む）はその場で "object" に修正、トップレベルの oneOf union schema にはルートの type:"object" を追加して分岐はそのまま保持します。同じ object 型の保証を Codex→Anthropic ツール経路の input_schema にも拡張しました。既存の properties / required を捨てることはありません。（#4706、#5315、#4705・#4783 を修正）
推論モデル（kimi-k2-thinking など）をプロキシの Responses→Chat ブリッジで使うと、マルチターン履歴が思考を壊していました。各ターンの reasoning 項目が前のアシスタントメッセージの末尾に貼り付けられ、直後のアシスタントターンに reasoning_content がなくなる——モデルが会話の途中で目に見えて壊れていました。Responses のセマンティクスでは reasoning は属するメッセージの前に置かれます。ブリッジは reasoning を、その後に続くアシスタントメッセージまたはツール呼び出しへ前方アタッチするようになりました。本物の末尾 reasoning だけが、確定した末尾（入力の終端、またはユーザーメッセージのようなターン境界——以前はここで静かに破棄されていました）で後方アタッチされ、既に埋め込まれた reasoning があれば追記します。保留中の reasoning は境界で必ず消費されるため、ユーザーターンを越えて後のアシスタントメッセージへ漏れることはありません。（#5508）
Chat→Responses ストリーミングブリッジの 2 つのバグが、チャンクをまたいで識別子が分割される上流からの並列ツール呼び出しを壊していました。空の id を持つ継続デルタが本物の call_id を上書きし（Codex クライアントは call_id:"" を見てツール結果を呼び出しに対応付けられません）、ツール呼び出しは個別に準備でき次第送出されていたため、名前が先に届いた後方インデックスが前方インデックスを追い越し、並列呼び出しの順序が入れ替わっていました。空の id は無視されるようになり、送出は連続インデックスゲートを通って Chat の index 順で厳密に解放され、まだ識別されていない前方インデックスを待ちます。ストリーム途中で偽の call id を合成することはありません（ストリーム終端の最終手段としてのみ。そこでも名前のない呼び出しは防御的にスキップし、疎なインデックスはそのまま送出します）。（#5310）
「ルーティング必要」バッジと切り替え時の警告は、プロバイダーの API 形式から導出されていました。管理下 OAuth プロバイダー（Copilot、Codex OAuth、xAI）にとってこれは誤ったシグナルです——認証情報は上流形式に関係なくプロキシが注入するため、ネイティブ形式の管理下プロバイダーは警告を受けず、テイクオーバーなしで静かに失敗していました。ルーティングの要否は単一の共有述語で決まるようになりました。公式プロバイダーは決してルーティングを必要とせず、管理下 OAuth プロバイダーは常に必要とし、形式ベースのルールは残りのケースにのみ適用されます。切り替え時のゲートもアプリごとに正しい準備状態を確認します。ほとんどのアプリはアプリ別テイクオーバー状態（旧ゲートはグローバルなプロキシ実行フラグだけを見ており、「プロキシは動いているが当該アプリはテイクオーバーされていない」を見逃していました）、Claude Desktop は引き続きプロキシプロセス自体を監視します——バックエンドのテイクオーバー状態に Claude Desktop のフィールドがないため、一律のアプリ別ゲートでは Desktop が永遠に警告を出し続けます。Claude Desktop のプロバイダーフォームは、xAI だけでなくすべての管理下 OAuth 型でプロキシモードを強制し、モデルマッピングトグルをロックします。4 言語同期。
アンカー付き npm の更新・修復コマンドは npm を絶対パスで呼び出しますが、npm のランチャーは #!/usr/bin/env node shebang で PATH から node を解決します——GUI 起動のアプリはシステム PATH しか継承せず、バージョンマネージャーのディレクトリを含まないため、nvm / fnm / mise でインストールしたツールの更新は静かに失敗していました。すべてのアンカー付き npm 呼び出しは、npm 自身の隣にある bin ディレクトリを PATH の先頭に追加するようになり、npm とその shebang が同じ Node インストールを解決します。Codex の自己修復（アンインストール + 再インストール）経路もカバーしています。
既定の Skill リポジトリは、起動のたびに「欠けている既定を補充」する処理で再シードされ、削除した既定リポジトリが次回起動時に静かに戻っていました。シードはデータベースごとに 1 回だけになり、設定フラグで記録されます。アップグレード時に既にリポジトリを持つデータベースは再シードなしでフラグが立つため、既存の選択には触れません。（#5356）
設定でまだ言語を選んでいない場合、トレイメニューは簡体字中国語に固定されていました——英語 / 日本語 / 繁体字中国語のシステムでは、メイン UI は正しく OS ロケールに従うのにトレイだけが食い違い、ユーザーが一度言語を切り替えるまで続いていました。トレイはフロントエンドと同じ優先順位で OS ロケールから初回言語を導出するようになりました（zh-TW / zh-HK / zh-Hant → 繁体字中国語を含む）。明示的に選んだ言語が常に優先され、ロケールを読めない場合は従来どおり中国語へフォールバックします。（#4355）
「live 設定からインポート」が失敗するたびに空のエラートーストが出ていました。Tauri の invoke はバックエンドのエラー文字列で reject するのに、ハンドラーがその上の .message を読んでいたためです。バックエンドの実際のメッセージを表示するようになり（ローカライズされた汎用フォールバック付き）、失敗時にもプロバイダーリストを更新するため、エラー前にコミットされた副作用がすぐ見えます。
OpenClaw プリセットの 15 エントリが、誤った単位や未換算の通貨でコスト値を持っていました——cost フィールドは 100 万 token あたりの USD ですが、たとえば glm-5.1 は 0.001/0.001（約 1000 分の 1 に過小評価され、使用量のコストがほぼ 0 と表示）、deepseek-v4-pro は未換算の人民元値（過大評価）でした。全エントリを $/M の公式表示価格に修正。サブスクリプションプランや無料 tier の endpoint も意図的に表示価格を示し、プランユーザーが自分の使用量の標準価値を見られるようにしています。今後プリセットから作成するプロバイダーには修正値が入り、作成済みのプロバイダーは作成時の設定を保持します。
proxyReasonAnthropicMessages がどの言語ファイルにも存在しなかったため）。プロバイダーフォームの key 状態読み込みラベルも 4 月からハードコードの既定値のみでした。両方とも zh / en / ja / zh-TW に揃いました。「Codex クライアントで Claude モデルを使う」「Claude Code クライアントで Responses プロバイダーを使う」の両方向が、2 つの新ガイドで揃いました：
/v1/messages ゲートウェイへ Codex を接続します。v3.17.0 のリリースノートからもリンクされています。/v1/messages ルートへ Anthropic Messages を話し、プロキシが各リクエストを上流の Responses プロトコルへ変換します。SubRouter が 4 言語 README のスポンサー表に加わりました。ピン留めの Kimi スポンサー文言は K3 に更新され、バナーは Moonshot CDN から配信されます。RunAPI の特典文言も更新し、スポンサー行の順序をアプリ内プリセット順に揃えました。
v3.17.0 からのアップグレードでは、3 つの schema 移行（v13 → v16）が連続実行されます。v14 は Grok Build を受け入れるために proxy_config テーブルを再構築（既存のアプリ別プロキシ設定はすべて引き継ぎ、grokbuild 行を追加）。v15 は MCP サーバーテーブルと Skills テーブルに Grok Build 有効化列を追加。v16 は一回限りの Codex 使用量自動再構築をトリガーします——データベースをまず backups/ 配下へバックアップし、codex_session データとカーソルをリセットし、その後通常の起動時同期が修正済みパーサーですべてを再インポートします。一般的なデータ量なら数秒。実測で最も重いデータセット（rollout ファイル 1,801 個 / 1.5 GB）は約 65 秒でした。以後の起動は従来どおり増分です。旧バージョンへ戻す可能性がある場合は、先に ~/.cc-switch/cc-switch.db を自分でバックアップしてください。
初回起動時の注意：履歴の修復は段階的に完了します——再構築は起動時同期と共にバックグラウンドで進み、その間、使用量ダッシュボードの Codex 履歴の数字はいったんゼロになり、その後少しずつ埋め戻されます。これは想定どおりの動作で、データ損失ではありません。再構築後の合計は通常、アップグレード前より小さくなります。二重計上で膨らんでいた分が絞り出され、残ったものが実際の使用量です。
本リリースから診断ログは起動時に消去されず、再起動をまたいで保持されます（ローテーション済みランタイムログ最大約 100 MB、クラッシュログ約 15 MB）。旧バージョンが書き込んだログファイルは遡って洗浄されず、API key、トークン、認証情報付き URL を含む可能性があります——公開の場で共有する前に、アップグレード前のログを確認してください。
Grok Build のインストール・再インストールは xAI 公式インストーラーを優先し、インストール時に x.ai/cli/install.sh（Windows では install.ps1）を外部取得します。npm はフォールバックです。既存の npm インストールは引き続き npm 経由で更新されます。
新しい価格行（grok-4.5、kimi-k3、k3）は次回起動時に「存在しなければ挿入」で自動追加されます。ユーザーが編集した価格行が上書きされることはありません。
本リリースの xAI Grok OAuth 連携は、公式 Grok CLI 用に登録された公開 OAuth クライアント識別情報とスコープを再利用します（client_id b1a00492-073a-47ea-816f-4c329264a828、scope に grok-cli:access を含む）。CC Switch 自身が登録したアプリケーション識別情報ではありません。xAI がこの利用方法を認めない可能性があり、アカウントの制限や停止につながる恐れがあります——自己責任でご利用ください。この機能は完全にオプトインです。xAI プロバイダーを追加しなければ、何も変わりません。初回ログイン時に ~/.cc-switch/xai_oauth_auth.json を作成し（refresh token のみ保存、Unix ではパーミッション 0600、access token はメモリのみ）、設定済みのアウトバウンドプロキシ経由で auth.x.ai と api.x.ai へ接続します。ローカルのコールバックポートはありません。
Codex OAuth リバースプロキシ：ChatGPT サブスクリプションの Codex OAuth をリバースプロキシ経由で使用すると、OpenAI の利用規約に違反する可能性があります。詳細は v3.13.0 release notes を参照してください。
サードパーティプロバイダーのルーティング：CC Switch ローカルプロキシで Codex、Claude Desktop、Grok Build のリクエストを変換してサードパーティプロバイダーへ転送する場合、課金・コンプライアンス・データ保持に関する制約はプロバイダーごとに異なります。利用前に対象プロバイダーの利用規約を確認してください。
上記機能を有効化したユーザーは、関連するリスクを自ら負うものとします。CC Switch は、これらの機能の利用によって発生したアカウント制限、警告、サービス停止について責任を負いません。
v3.18.0 で機能と修正を届けてくださった以下のコントリビューターに感謝します：
Codex 使用量の異常、新しい codex の起動失敗、ツール呼び出しの問題を報告してくださったすべてのユーザーにも感謝します。本リリースの最も重要な修正は、こうした実際の利用場面からの再現情報をもとにしています。
Releases から、お使いのシステムに対応するビルドをダウンロードしてください。
| システム | 最低バージョン | アーキテクチャ |
|---|---|---|
| Windows | Windows 10 以降 | x64 / ARM64 |
| macOS | macOS 12 (Monterey) 以降 | Intel (x64) / Apple Silicon (arm64) |
| Linux | 下表を参照 | x64 / ARM64 |
| ファイル | 説明 |
|---|---|
CC-Switch-v3.18.0-Windows.msi | 推奨 - 自動更新対応の MSI インストーラー |
CC-Switch-v3.18.0-Windows-Portable.zip | ポータブル版、展開してそのまま実行できます |
Windows ARM64 デバイスでは、ファイル名に arm64 が含まれる対応する成果物を選択してください。
| ファイル | 説明 |
|---|---|
CC-Switch-v3.18.0-macOS.dmg | 推奨 - DMG インストーラー、Applications へドラッグ |
CC-Switch-v3.18.0-macOS.zip | 展開して Applications へドラッグ、Universal Binary |
CC-Switch-v3.18.0-macOS.tar.gz | Homebrew インストールと自動更新用 |
Homebrew インストール：
brew install --cask cc-switch
更新：
brew upgrade --cask cc-switch
Linux アセットは x86_64 と ARM64（aarch64）の両方を提供します。ファイル名のアーキテクチャ識別子を、マシンの uname -m 出力に合わせて選択してください：
CC-Switch-v3.18.0-Linux-x86_64.AppImage / .deb / .rpmCC-Switch-v3.18.0-Linux-arm64.AppImage / .deb / .rpm| ディストリビューション | 推奨形式 | インストール方法 |
|---|---|---|
| Ubuntu / Debian / Linux Mint / Pop!_OS | .deb | sudo dpkg -i CC-Switch-*.deb または sudo apt install ./CC-Switch-*.deb |
| Fedora / RHEL / CentOS / Rocky Linux | .rpm | sudo rpm -i CC-Switch-*.rpm または sudo dnf install ./CC-Switch-*.rpm |
| openSUSE | .rpm | sudo zypper install ./CC-Switch-*.rpm |
| Arch Linux / Manjaro | .AppImage | 実行権限を付与して直接実行、または AUR を利用 |
| その他 / 不明な場合 | .AppImage | chmod +x CC-Switch-*.AppImage && ./CC-Switch-*.AppImage |