mirror of
https://github.com/farion1231/cc-switch.git
synced 2026-07-24 12:44:18 +08:00
Jason
332 lines
59 KiB
Markdown
332 lines
59 KiB
Markdown
# CC Switch v3.18.0
|
||
|
||
> 本リリースでは、まったく新しい 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 クラッシュも真っ白な画面ではなくディスクに記録が残ります。
|
||
|
||
**[English →](v3.18.0-en.md) | [中文版 →](v3.18.0-zh.md)**
|
||
|
||
---
|
||
|
||
## ハイライト：本リリースでできること
|
||
|
||
- **Grok Build（xAI の Grok CLI）を管理**：Claude Code / Codex と同じように、Grok Build のプロバイダーを追加・インポート・ワンクリック切り替えできます。MCP サーバーと Skills は双方向同期、プロンプトは初回起動時に自動インポート、セッション管理と使用量ダッシュボードも完全対応。ローカルプロキシによるテイクオーバーで、独立したルーティング・failover・課金も利用できます。
|
||
- **Grok の接続はアカウントでも API Key でも**：サブスクリプションユーザーは「設定 → OAuth 認証センター」でデバイスコードによる xAI サインインを行い（複数アカウント対応）、Claude Code・Claude Desktop・Codex の 3 クライアントが API key なしで Grok サブスクリプションで動きます。従量課金ユーザーは xAI API key で接続——Codex には `api.x.ai` へネイティブ直結する「xAI (Grok)」プリセットがあり、Claude Code は本リリースの新ガイドに沿ってローカルルーティングで接続できます。既定モデルはいずれも `grok-4.5` です。
|
||
- **Codex の使用量を実態に戻す**：v3.17.0 の fork / サブエージェント二重計上をパーサーレベルで根治しました。アップグレード後の初回起動でデータベースをバックアップして Codex 使用量を自動再構築し、使用量ページには手動の「Codex 使用量を再構築」ボタンも追加。なお初回起動時の履歴修復は**段階的に**進みます——数字がいったん減り、バックグラウンドの再インポートに伴って徐々に埋め戻されるのは想定どおりの動作です（「アップグレード時の注意」参照）。
|
||
- **codex CLI を安心してアップグレード**：codex 0.144.5 の厳格なモデルカタログ解析による「起動できない」問題を修正。生成カタログはパーサー必須フィールドを自動補完します。
|
||
- **Windows でスムーズに切り替え**：プロバイダー切り替えやテイクオーバーの切り替えで黒いコンソールウィンドウが一瞬表示されることがなくなり、UI が約 2 秒固まる問題も解消しました（フリーズ修正は全プラットフォームに効きます）。
|
||
- **ログの調査と共有をより安心に**：診断ログは再起動をまたいで保持（20 MB × 4 ローテーション）され、すべての出口で一律に秘密情報を除去——URL 内の認証情報、リクエスト / レスポンスボディ、機微なヘッダーはディスクに残りません。UI クラッシュはエラーカードと再読み込みボタンで受け止め、詳細をディスクへ記録します。
|
||
- **マルチターンの reasoning と並列ツール呼び出しが壊れない**：Responses↔Chat ブリッジで、reasoning の誤った付け先、並列ツール呼び出しの ID 消失・順序入れ替わり、tool schema が null の場合にリクエスト全体が拒否される問題の 3 種類を修正しました。
|
||
- **Kimi K3 を使う**：Codex / Hermes / OpenClaw / OpenCode の Kimi オープンプラットフォームプリセットに K3（1M コンテキスト）を追加し、内蔵価格も登録。使用量が $0 と表示されなくなります。
|
||
|
||
---
|
||
|
||
## 利用ガイド
|
||
|
||
本リリースの新機能は、主にプロバイダープリセット、「設定 → OAuth 認証センター」、使用量ダッシュボードにあります。以下のドキュメントもあわせてご覧ください：
|
||
|
||
- **[xAI Grok アカウントサインイン（設定 → OAuth 認証センター）](../user-manual/ja/1-getting-started/1.5-settings.md)**：デバイスコードログインの流れ、複数アカウント管理、連携の境界について説明します。利用前に下記「リスク通知」のクライアント識別情報の開示を必ずお読みください。
|
||
- **[Claude Code で Codex 系プロバイダーを使う（ローカルルーティングガイド）](../guides/claude-codex-routing-guide-zh.md)**（現時点では中国語のみ）：本リリース追加のステップバイステップガイドです。Claude Code は常にローカルの `/v1/messages` ルートに対して Anthropic Messages を話し、ローカルプロキシが各リクエストを上流の Responses プロトコルへ変換します——ゲートウェイの API key、xAI のようなネイティブ Responses endpoint、ChatGPT サブスクリプションの Codex サービスのいずれにも使えます。
|
||
- **[Codex で Claude を使う（ローカルルーティングガイド）](../guides/codex-claude-routing-guide-ja.md)**：本リリース追加の 3 言語ガイド。v3.17.0 の「ネイティブ Anthropic Messages 上流」と組み合わせ、`/v1/messages` のみを提供する Claude 系ゲートウェイへ Codex を接続します。
|
||
- **[使用量統計](../user-manual/ja/4-proxy/4.4-usage.md)**：使用量ダッシュボードのデータソースと集計方法を確認できます。本リリースでは二重計上を修正し、「Codex 使用量を再構築」メンテナンス操作を追加しました。
|
||
|
||
---
|
||
|
||
> [!WARNING]
|
||
>
|
||
> ## 唯一の公式チャネル（必ずお読みください）
|
||
>
|
||
> CC Switch は**完全に無料・オープンソース**のデスクトップアプリで、**ユーザーから料金を徴収することはありません**。本ソフトウェアは下記の公式チャネルからのみ入手してください：
|
||
>
|
||
> | チャネル | 唯一の公式 |
|
||
> | ------------ | ------------------------------------------------------------------------------ |
|
||
> | 公式サイト | **[ccswitch.io](https://ccswitch.io)** |
|
||
> | ソースコード | **[github.com/farion1231/cc-switch](https://github.com/farion1231/cc-switch)** |
|
||
> | ダウンロード | **[GitHub Releases](https://github.com/farion1231/cc-switch/releases)** |
|
||
> | 作者 | **[@farion1231](https://github.com/farion1231)** |
|
||
> | 偽サイト通報 | **[GitHub Issues](https://github.com/farion1231/cc-switch/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
|
||
|
||
---
|
||
|
||
## 追加機能
|
||
|
||
### Grok Build：8 番目の管理対象アプリ
|
||
|
||
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](https://github.com/farion1231/cc-switch/pull/5453)）
|
||
|
||
### Grok 公式ログイン：検出・インポート・保護
|
||
|
||
新しい「Grok 公式」プロバイダーエントリは、Grok CLI 内蔵の xAI OAuth ログインに対応します。選択すると接続フィールドが隠れ、空の `~/.grok/config.toml` を書き込みます。CC Switch が公式認証情報を保存したり触れたりすることはありません。live 設定の読み取り・バックアップ・公式状態の書き込みは構文レベルのみの TOML 検証に変更され、公式ログイン状態（空の設定）が正常に往復します。Grok が公式ログイン状態のときに「live 設定からインポート」すると、エラーではなく「Grok 公式を現在のプロバイダーに設定しました」となり、Codex と同じ挙動になります。公式状態の検出は意図的に手動インポートコマンドだけに配線されています——起動時の自動インポートは公式状態の設定を引き続き拒否するため、削除した「Grok 公式」エントリが次回起動時に復活することはありません。公式ログイン設定へのプロキシテイクオーバーは自動的にスキップされ、手動操作でも明確に拒否されます。既存の「公式プロバイダーはプロキシしない」方針と一貫しています。
|
||
|
||
### xAI Grok アカウントでサインイン：Claude Code と Claude Desktop
|
||
|
||
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 系プロバイダーを使う](../guides/claude-codex-routing-guide-zh.md)ガイドと同じ手順です。Codex 側には既製の API key プリセットがあります（次節参照）。
|
||
|
||
### Codex から xAI へ直結：管理下 OAuth と API Key ネイティブの 2 プリセット
|
||
|
||
Codex には xAI へ直結する 2 つの道があります——Grok サブスクリプションなら管理下 OAuth、API key ならネイティブ直結です：
|
||
|
||
- **「xAI (Grok) OAuth」管理下プリセット**：Codex を Grok サブスクリプションで動かします。フォームは key / endpoint / 形式フィールドを隠してアカウント選択を表示し、「モデルを取得」はサインイン済みアカウントで実行。プロバイダーはネイティブ Responses に固定され、base URL とリクエストごとのトークンはプロキシが強制します——編集しても無視されるため、管理下ルートを別の宛先へ向けることはできません。codex 0.142+ は ChatGPT バックエンド固有のリクエスト形を発します（`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 プロバイダー型だけにゲートされ、他のプロバイダーのトラフィックには触れません。
|
||
- **「xAI (Grok)」API Key プリセット**：`api.x.ai/v1` のネイティブ Responses に直結し、500K コンテキストの `grok-4.5` カタログエントリを内蔵します。このプリセットには上記の xAI 専用互換変換は**適用されません**——codex 0.142+ の API key ユーザーは依然 xAI の厳格パーサーに当たる可能性があり、完全互換の道は OAuth プリセットです。
|
||
|
||
xAI OAuth のトークンエラーは再試行不能に分類されるため、failover が会話を別の Grok アカウントへ静かに移すことはありません。
|
||
|
||
### UI クラッシュの捕捉：エラーのディスク保存と再読み込み画面
|
||
|
||
React のエラーバウンダリが UI 全体（データベース復旧画面を含む）を包むようになりました。レンダラーがクラッシュすると、真っ白なウィンドウの代わりに「インターフェースでエラーが発生しました」カードと再読み込みボタンが表示され、グローバルの `error` / `unhandledrejection` ハンドラーがレンダラーのエラーをディスクへ永続化します——以前は JS クラッシュの証拠がディスクに一切残りませんでした。フロントエンドが書き出すログはすべて二層の秘密情報除去を通ります。構造化シリアライザーが機微なプロパティ名（`tokens` / `apiKeys` / `credentials` の変種を正規化して照合し、ネストされたオブジェクトを含む値全体を隠す）と値の形（トークン接頭辞、PEM ヘッダー、高エントロピーな不透明文字列）で除去し、次に唯一のテキスト出口の順序付き正規表現チェーンが URL クエリ値と認証情報、認証ヘッダーとスキーム、名前付きシークレットコンテナ（二重エンコードされた JSON も対象）をカバーします。文字列として届いた JSON は再パースして構造的に除去し、過大な構造化入力は切り詰めではなく全体を破棄します——切り詰められた JSON 文字列は弱いテキスト正規表現にフォールバックして漏えいの恐れがあるためです。設定のトグル名も実態に合わせて変更しました。「アプリ診断ログ」（cc-switch.log）と、プロキシの「リクエスト使用量を記録」（統計データベースであり、もともとテキストログではありません）です。4 言語同期。
|
||
|
||
### 「Codex 使用量を再構築」メンテナンス操作
|
||
|
||
使用量ダッシュボードのメンテナンスに「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` 式インデックス経由）し、ヒットごとに警告を記録します。二重計上バグが将来再発しても、総量を静かに膨らませるのではなく、ログの中で自ら名乗り出ます。
|
||
|
||
### Kimi K3 のプリセットと内蔵価格
|
||
|
||
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.us が SudoCode.chat と並んで復活
|
||
|
||
たまたま「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 のスポンサー表と同じ順序。プリセットファイルも物理的に並べ替えて揃えました）、最後に残りすべてをファイル順ではなく表示名のアルファベット順で並べます。複数の層に該当するエントリは最も早い層にだけ現れ、重複表示はありません。
|
||
|
||
### プリセットの「API Key を取得」リンクを更新
|
||
|
||
RunAPI、ClaudeCN、ZetaAPI、APINebula プリセットの key 申請リンクを、各社の現在の登録 / 紹介ページに更新しました（ClaudeCN はドメインも移転：claudecn.top → claudecn.ai）。紹介タグはこれらのリンクと README に限定され、公式サイトリンクと API endpoint には手を付けていません。
|
||
|
||
---
|
||
|
||
## 修正
|
||
|
||
### Codex fork / サブエージェントのリプレイ済み親履歴を新規使用量として計上しない（v3.17.0 の二重計上を根治）
|
||
|
||
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](https://github.com/farion1231/cc-switch/issues/5335)、[#5433](https://github.com/farion1231/cc-switch/issues/5433)、[#5381](https://github.com/farion1231/cc-switch/issues/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](https://github.com/farion1231/cc-switch/issues/5496)）
|
||
|
||
### 大量セッションインポート中に使用量ページが固まらない
|
||
|
||
大きなインポートの実行中に使用量ページを開くと、UI 全体が固まることがありました。行を挿入するたびに更新通知が飛び、通知のたびにフロントエンドが約 10 個の使用量クエリをすべて再実行し、それらのクエリが、数十 MB の rollout ファイルを 1 行ずつ解析中のインポーターと唯一のデータベース接続を奪い合う——重複で膨張したデータベースでは三者が互いに増幅し合っていました。セッション同期は 1 パス完了ごとに 1 回だけ通知するようになり、すべてのセッションインポーターはシングルフライトロックの後ろで直列化され（手動の「今すぐ同期」は実行中のパスと競争せず、後ろに並びます）、ブロッキングな解析処理は専用のブロッキングスレッドへ移されて UI コマンドを駆動する非同期ランタイムを飢えさせなくなり、60 秒間隔のバックグラウンド実行は取りこぼし分をまとめて実行せずスキップします。
|
||
|
||
### codex 0.144.5+ が CC Switch 生成のモデルカタログで起動不能にならない
|
||
|
||
codex ≥ 0.144.5 は外部モデルカタログを厳格に解析し、エントリに `supports_reasoning_summaries` がないとファイル全体を拒否します——Codex CLI もデスクトップアプリも起動できず、生成カタログを削除しても、プロバイダーを保存するたびに同じ形で再生成されるため解決しませんでした。根本原因は、CC Switch がカタログのテンプレートをマシン共有の `models_cache.json` から複製していることです。そのフィールド構成は最後に書き込んだ codex プロセス次第で、共存する旧版 codex が新パーサー必須のフィールドを持たない形でキャッシュを書き換え続けていました。生成カタログは、同梱の静的テンプレートからパーサー必須フィールドを補完するようになりました。補完は欠けている場合のみで（動的な値が常に優先）、「欠落 = パーサー既定値」のセマンティクスを保つべきオプションの能力フィールドは意図的に補完しません。
|
||
|
||
### Windows：プロバイダー切り替えでコンソールが一瞬表示されず、固まらない
|
||
|
||
Windows でプロバイダーを切り替えたりテイクオーバーを切り替えたりすると、コンソールウィンドウが一瞬表示され、UI が最大約 2 秒固まっていました。原因は 3 つ、修正も 3 つです。`codex debug models --bundled` プローブは `cmd.exe` 経由で `codex.cmd` を起動しますが、GUI サブシステムのアプリではこれが独自のコンソールを生成します——子プロセスは `CREATE_NO_WINDOW` で作成するようにしました。モデルカタログのテンプレートは切り替えのたびに再生成されていました——初回の成功ロード後にプロセス全体でキャッシュし（失敗は再試行可能のままなので、初回プローブの失敗がキャッシュを汚しません）、Codex CLI の起動はアプリ実行ごとに最大 1 回になりました。`switch_provider` はメインスレッド上の同期コマンドでした——非同期化して実処理をブロッキングスレッドに移し、アプリ別の切り替えロックによる直列化は維持しています。フリーズ修正は全プラットフォームに効き、コンソール表示の修正は Windows 固有です。
|
||
|
||
### tool schema が null / 欠落 / union 型でも厳格上流に拒否されない
|
||
|
||
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](https://github.com/farion1231/cc-switch/pull/4706)、[#5315](https://github.com/farion1231/cc-switch/pull/5315)、#4705・#4783 を修正）
|
||
|
||
### 推論モデルがマルチターンの Codex Chat 会話で思考を失わない
|
||
|
||
推論モデル（kimi-k2-thinking など）をプロキシの Responses→Chat ブリッジで使うと、マルチターン履歴が思考を壊していました。各ターンの `reasoning` 項目が**前の**アシスタントメッセージの末尾に貼り付けられ、直後のアシスタントターンに `reasoning_content` がなくなる——モデルが会話の途中で目に見えて壊れていました。Responses のセマンティクスでは reasoning は属するメッセージの**前**に置かれます。ブリッジは reasoning を、その後に続くアシスタントメッセージまたはツール呼び出しへ前方アタッチするようになりました。本物の末尾 reasoning だけが、確定した末尾（入力の終端、またはユーザーメッセージのようなターン境界——以前はここで静かに破棄されていました）で後方アタッチされ、既に埋め込まれた reasoning があれば追記します。保留中の reasoning は境界で必ず消費されるため、ユーザーターンを越えて後のアシスタントメッセージへ漏れることはありません。（[#5508](https://github.com/farion1231/cc-switch/pull/5508)）
|
||
|
||
### ストリーミング並列ツール呼び出しの ID と順序を保持
|
||
|
||
Chat→Responses ストリーミングブリッジの 2 つのバグが、チャンクをまたいで識別子が分割される上流からの並列ツール呼び出しを壊していました。空の `id` を持つ継続デルタが本物の `call_id` を上書きし（Codex クライアントは `call_id:""` を見てツール結果を呼び出しに対応付けられません）、ツール呼び出しは個別に準備でき次第送出されていたため、名前が先に届いた後方インデックスが前方インデックスを追い越し、並列呼び出しの順序が入れ替わっていました。空の id は無視されるようになり、送出は連続インデックスゲートを通って Chat の `index` 順で厳密に解放され、まだ識別されていない前方インデックスを待ちます。ストリーム途中で偽の call id を合成することはありません（ストリーム終端の最終手段としてのみ。そこでも名前のない呼び出しは防御的にスキップし、疎なインデックスはそのまま送出します）。（[#5310](https://github.com/farion1231/cc-switch/pull/5310)）
|
||
|
||
### 管理下 OAuth プロバイダーを確実に「ローカルルーティング必要」と表示
|
||
|
||
「ルーティング必要」バッジと切り替え時の警告は、プロバイダーの API 形式から導出されていました。管理下 OAuth プロバイダー（Copilot、Codex OAuth、xAI）にとってこれは誤ったシグナルです——認証情報は上流形式に関係なくプロキシが注入するため、ネイティブ形式の管理下プロバイダーは警告を受けず、テイクオーバーなしで静かに失敗していました。ルーティングの要否は単一の共有述語で決まるようになりました。公式プロバイダーは決してルーティングを必要とせず、管理下 OAuth プロバイダーは常に必要とし、形式ベースのルールは残りのケースにのみ適用されます。切り替え時のゲートもアプリごとに正しい準備状態を確認します。ほとんどのアプリはアプリ別テイクオーバー状態（旧ゲートはグローバルなプロキシ実行フラグだけを見ており、「プロキシは動いているが当該アプリはテイクオーバーされていない」を見逃していました）、Claude Desktop は引き続きプロキシプロセス自体を監視します——バックエンドのテイクオーバー状態に Claude Desktop のフィールドがないため、一律のアプリ別ゲートでは Desktop が永遠に警告を出し続けます。Claude Desktop のプロバイダーフォームは、xAI だけでなくすべての管理下 OAuth 型でプロキシモードを強制し、モデルマッピングトグルをロックします。4 言語同期。
|
||
|
||
### Node が nvm / fnm / mise にある場合でもツール更新が動く
|
||
|
||
アンカー付き npm の更新・修復コマンドは npm を絶対パスで呼び出しますが、npm のランチャーは `#!/usr/bin/env node` shebang で PATH から `node` を解決します——GUI 起動のアプリはシステム PATH しか継承せず、バージョンマネージャーのディレクトリを含まないため、nvm / fnm / mise でインストールしたツールの更新は静かに失敗していました。すべてのアンカー付き npm 呼び出しは、npm 自身の隣にある `bin` ディレクトリを PATH の先頭に追加するようになり、npm とその shebang が同じ Node インストールを解決します。Codex の自己修復（アンインストール + 再インストール）経路もカバーしています。
|
||
|
||
### 削除した既定 Skill リポジトリが復活しない
|
||
|
||
既定の Skill リポジトリは、起動のたびに「欠けている既定を補充」する処理で再シードされ、削除した既定リポジトリが次回起動時に静かに戻っていました。シードはデータベースごとに 1 回だけになり、設定フラグで記録されます。アップグレード時に既にリポジトリを持つデータベースは再シードなしでフラグが立つため、既存の選択には触れません。（[#5356](https://github.com/farion1231/cc-switch/pull/5356)）
|
||
|
||
### トレイの初回言語がシステムロケールに従う
|
||
|
||
設定でまだ言語を選んでいない場合、トレイメニューは簡体字中国語に固定されていました——英語 / 日本語 / 繁体字中国語のシステムでは、メイン UI は正しく OS ロケールに従うのにトレイだけが食い違い、ユーザーが一度言語を切り替えるまで続いていました。トレイはフロントエンドと同じ優先順位で OS ロケールから初回言語を導出するようになりました（`zh-TW` / `zh-HK` / `zh-Hant` → 繁体字中国語を含む）。明示的に選んだ言語が常に優先され、ロケールを読めない場合は従来どおり中国語へフォールバックします。（[#4355](https://github.com/farion1231/cc-switch/pull/4355)）
|
||
|
||
### インポート失敗時に実際のエラーを表示しリストを更新
|
||
|
||
「live 設定からインポート」が失敗するたびに空のエラートーストが出ていました。Tauri の `invoke` はバックエンドのエラー**文字列**で reject するのに、ハンドラーがその上の `.message` を読んでいたためです。バックエンドの実際のメッセージを表示するようになり（ローカライズされた汎用フォールバック付き）、失敗時にもプロバイダーリストを更新するため、エラー前にコミットされた副作用がすぐ見えます。
|
||
|
||
### OpenClaw プリセットのモデルコストを公式表示価格に修正
|
||
|
||
OpenClaw プリセットの 15 エントリが、誤った単位や未換算の通貨でコスト値を持っていました——`cost` フィールドは 100 万 token あたりの USD ですが、たとえば `glm-5.1` は `0.001/0.001`（約 1000 分の 1 に過小評価され、使用量のコストがほぼ 0 と表示）、`deepseek-v4-pro` は未換算の人民元値（過大評価）でした。全エントリを $/M の公式表示価格に修正。サブスクリプションプランや無料 tier の endpoint も意図的に表示価格を示し、プランユーザーが自分の使用量の標準価値を見られるようにしています。今後プリセットから作成するプロバイダーには修正値が入り、作成済みのプロバイダーは作成時の設定を保持します。
|
||
|
||
### UI の小さな修正
|
||
|
||
- **AiHubMix アイコン**：Codex アプリの AiHubMix プリセットだけがブランドアイコンのフィールドを欠き、汎用アイコンで表示されていました。他のアプリと揃いました。
|
||
- **欠落していた 2 つのロケールキーを補完**：Codex の「Anthropic Messages 形式のためルーティングが必要」トーストの理由部分が、ローカライズ済みの文の中で中国語のまま表示されていました（`proxyReasonAnthropicMessages` がどの言語ファイルにも存在しなかったため）。プロバイダーフォームの key 状態読み込みラベルも 4 月からハードコードの既定値のみでした。両方とも zh / en / ja / zh-TW に揃いました。
|
||
|
||
---
|
||
|
||
## ドキュメント
|
||
|
||
### Codex ↔ Claude 双方向ルーティングガイド
|
||
|
||
「Codex クライアントで Claude モデルを使う」「Claude Code クライアントで Responses プロバイダーを使う」の両方向が、2 つの新ガイドで揃いました：
|
||
|
||
- **[Codex で Claude を使う](../guides/codex-claude-routing-guide-ja.md)**（中 / 英 / 日 3 言語、スクリーンショット付き）：v3.17.0 のネイティブ Anthropic Messages 上流と組み合わせ、Claude 系の `/v1/messages` ゲートウェイへ Codex を接続します。v3.17.0 のリリースノートからもリンクされています。
|
||
- **[Claude Code で Codex 系プロバイダーを使う](../guides/claude-codex-routing-guide-zh.md)**（中国語、スクリーンショット付き）：Responses を話すプロバイダー（ゲートウェイの API key、または ChatGPT サブスクリプションの Codex サービス）で Claude Code を動かします——Claude Code は常にローカルの `/v1/messages` ルートへ Anthropic Messages を話し、プロキシが各リクエストを上流の Responses プロトコルへ変換します。
|
||
|
||
### README のスポンサー欄を更新
|
||
|
||
SubRouter が 4 言語 README のスポンサー表に加わりました。ピン留めの Kimi スポンサー文言は K3 に更新され、バナーは Moonshot CDN から配信されます。RunAPI の特典文言も更新し、スポンサー行の順序をアプリ内プリセット順に揃えました。
|
||
|
||
---
|
||
|
||
## アップグレード時の注意
|
||
|
||
### データベース自動移行と Codex 使用量の一回限りの再構築
|
||
|
||
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 履歴の数字はいったんゼロになり、その後少しずつ埋め戻されます。これは想定どおりの動作で、データ損失ではありません。再構築後の合計は通常、アップグレード前より**小さく**なります。二重計上で膨らんでいた分が絞り出され、残ったものが実際の使用量です。
|
||
|
||
### 再構築の境界
|
||
|
||
- 再構築は rollout JSONL ファイルから使用量を再計算するため、**ソースログが既に削除された履歴は復元できません**。
|
||
- 親 rollout が欠けている fork ファイルは、推測でインポートせず保留として報告されます。親ログを復元してから「Codex 使用量を再構築」を実行すると取り込めます。
|
||
- 過去のプロキシソースの重複行は恒久的に残ります——移行が再構築するのはセッションソースのデータだけで、過去のプロキシ膨張を掃除する処理は存在しません。冪等ロガーが保証するのは、今後新しい重複が生まれないことだけです。
|
||
|
||
### 古いログファイルは遡って洗浄されません
|
||
|
||
本リリースから診断ログは起動時に消去されず、再起動をまたいで保持されます（ローテーション済みランタイムログ最大約 100 MB、クラッシュログ約 15 MB）。**旧バージョンが書き込んだログファイルは遡って洗浄されず**、API key、トークン、認証情報付き URL を含む可能性があります——公開の場で共有する前に、アップグレード前のログを確認してください。
|
||
|
||
### Grok Build のインストールは公式インストーラースクリプトを使用
|
||
|
||
Grok Build のインストール・再インストールは xAI 公式インストーラーを優先し、インストール時に `x.ai/cli/install.sh`（Windows では `install.ps1`）を外部取得します。npm はフォールバックです。既存の npm インストールは引き続き npm 経由で更新されます。
|
||
|
||
### 内蔵価格の行を自動追加
|
||
|
||
新しい価格行（`grok-4.5`、`kimi-k3`、`k3`）は次回起動時に「存在しなければ挿入」で自動追加されます。ユーザーが編集した価格行が上書きされることはありません。
|
||
|
||
---
|
||
|
||
## リスク通知
|
||
|
||
### xAI Grok OAuth サインイン（本リリース新規——必ずお読みください）
|
||
|
||
本リリースの 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](v3.13.0-ja.md#️-リスクに関する注意事項) を参照してください。
|
||
|
||
**サードパーティプロバイダーのルーティング**：CC Switch ローカルプロキシで Codex、Claude Desktop、Grok Build のリクエストを変換してサードパーティプロバイダーへ転送する場合、課金・コンプライアンス・データ保持に関する制約はプロバイダーごとに異なります。利用前に対象プロバイダーの利用規約を確認してください。
|
||
|
||
上記機能を有効化したユーザーは、関連するリスクを自ら負うものとします。CC Switch は、これらの機能の利用によって発生したアカウント制限、警告、サービス停止について責任を負いません。
|
||
|
||
---
|
||
|
||
## 謝辞
|
||
|
||
v3.18.0 で機能と修正を届けてくださった以下のコントリビューターに感謝します：
|
||
|
||
- [#5453](https://github.com/farion1231/cc-switch/pull/5453)：Grok Build の第一級サポート（8 番目の管理対象アプリの中核実装）、@YUZHEthefool に感謝。
|
||
- [#5508](https://github.com/farion1231/cc-switch/pull/5508)：Responses→Chat ブリッジの reasoning 前方アタッチ、@ka79376046 に感謝。
|
||
- [#5310](https://github.com/farion1231/cc-switch/pull/5310)：ストリーミング並列ツール呼び出しの ID と順序の保持、@SaladDay に感謝。
|
||
- [#5315](https://github.com/farion1231/cc-switch/pull/5315)：Codex ツール parameters の object schema への正規化、@Komikawayi に感謝。
|
||
- [#4706](https://github.com/farion1231/cc-switch/pull/4706)：厳格な OpenAI 互換プロバイダー向けのツール型正規化、@Ryan2128 に感謝。
|
||
- [#5356](https://github.com/farion1231/cc-switch/pull/5356)：削除した既定 Skill リポジトリの復活防止、@allenxu09 に感謝。
|
||
- [#4355](https://github.com/farion1231/cc-switch/pull/4355)：トレイ初回言語のシステムロケール追従、@LaiYueTing に感謝。
|
||
- [#5138](https://github.com/farion1231/cc-switch/pull/5138)：バックエンド CI の Linux / Windows / macOS 3 プラットフォーム展開、@zayokami に感謝。
|
||
|
||
Codex 使用量の異常、新しい codex の起動失敗、ツール呼び出しの問題を報告してくださったすべてのユーザーにも感謝します。本リリースの最も重要な修正は、こうした実際の利用場面からの再現情報をもとにしています。
|
||
|
||
---
|
||
|
||
## ダウンロードとインストール
|
||
|
||
[Releases](https://github.com/farion1231/cc-switch/releases/latest) から、お使いのシステムに対応するビルドをダウンロードしてください。
|
||
|
||
### システム要件
|
||
|
||
| システム | 最低バージョン | アーキテクチャ |
|
||
| -------- | ------------------------ | ----------------------------------- |
|
||
| Windows | Windows 10 以降 | x64 / ARM64 |
|
||
| macOS | macOS 12 (Monterey) 以降 | Intel (x64) / Apple Silicon (arm64) |
|
||
| Linux | 下表を参照 | x64 / ARM64 |
|
||
|
||
### Windows
|
||
|
||
| ファイル | 説明 |
|
||
| ---------------------------------------- | -------------------------------------------- |
|
||
| `CC-Switch-v3.18.0-Windows.msi` | **推奨** - 自動更新対応の MSI インストーラー |
|
||
| `CC-Switch-v3.18.0-Windows-Portable.zip` | ポータブル版、展開してそのまま実行できます |
|
||
|
||
Windows ARM64 デバイスでは、ファイル名に `arm64` が含まれる対応する成果物を選択してください。
|
||
|
||
### macOS
|
||
|
||
| ファイル | 説明 |
|
||
| -------------------------------- | ------------------------------------------------------ |
|
||
| `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 インストール：
|
||
|
||
```bash
|
||
brew install --cask cc-switch
|
||
```
|
||
|
||
更新：
|
||
|
||
```bash
|
||
brew upgrade --cask cc-switch
|
||
```
|
||
|
||
### Linux
|
||
|
||
Linux アセットは **x86_64** と **ARM64**（`aarch64`）の両方を提供します。ファイル名のアーキテクチャ識別子を、マシンの `uname -m` 出力に合わせて選択してください：
|
||
|
||
- `CC-Switch-v3.18.0-Linux-x86_64.AppImage` / `.deb` / `.rpm`
|
||
- `CC-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` |
|