皆さんこんにちは、Cang He です。
CodexGuide が一昨日公開されてから、バックエンドが大変なことになっています。
一番多い質問はこれです：中国で Codex を使うにはどうすればいいの？Plus に登録しなくても使える？
正直なところ、この悩みはよくわかります。
Plus に登録するにはそれなりのハードルがあるし、支払い方法を調べるのも本当に面倒です。
そこで、僕は2日間かけてネットで見つけられるあらゆる方法を試し、多くの失敗を経験した上で、最終的に最も信頼性の高い3つのアクセス方法をまとめました。
今日はそのすべてを皆さんと共有します。手順通りに進めてください。
このチュートリアルは CodexGuide でも公開されているので、いつでも参照できます。
こんなに頑張って作ったんだから、スターをポチッとお願いします。笑。
まず大前提：Codex を最も安定して使う方法は、やはり公式の GPT アカウントでログインすることです。
サードパーティの API に接続するのは上級者向けの操作で、config.toml、API Key、Base URL が何かを理解している必要があります。
もしわからなくても大丈夫。以下の手順に従ってください。
3つの方式の選び方
自分に合った方式を見つけるための表をご用意しました。
方式 | こんな人におすすめ | メリット | 注意点 |
|---|---|---|---|
手動設定 | 原理を理解したい方 | 透過的で制御可能、トラブルシューティングが容易 |
|
Codex++ | GUI で管理したいデスクトップアプリ利用者 | 管理インターフェースあり、ワンクリック設定 | サードパーティ製ツール。Codex 更新後にアップデートが必要な場合あり |
CCX + CC Switch | 複数のプロバイダーを持ち、プロトコル変換が必要な方 | ゲートウェイルーティング + ワンクリックプロバイダー切り替え | 構成要素が多い。ポートとプロキシチェーンを理解する必要あり |
正直、初心者の方は方式2だけ見ておけば大丈夫です。一番手間いらずです。
もし Codex を学び始めたばかりなら、サードパーティの API をいじる前に、以前の Codex 初心者向けチュートリアルを見ることをおすすめします。
方式1：手動設定
この方法には欠点があります：Codex アプリのプラグイン機能が使えません。
プラグインを使いたい場合は、方式2に直接進んでください。
手動設定の核心は、1つのファイルを変更することです：
変更する前に、バックアップを取りましょう。良い習慣です：
2つのログイン方法
方法 | 考え方 | 適したシナリオ |
|---|---|---|
GPT ログイン | 公式ログイン状態を維持し、リクエスト転送アドレスのみ変更 | 公式アカウント機能を維持しつつリレーを使いたい場合 |
API Key ログイン | 環境変数で Key を使用し、直接サードパーティにリクエスト | OpenAI API Key または自作の互換サービスを使用する場合 |
アドバイス：一度に多くのことを変更しないでください。まず1つのプロバイダーのみ追加し、動作確認ができてから複数設定に挑戦しましょう。
GPT ログイン状態の例
つまり、Codex がまず GPT アカウントにログインしている必要があります。
ステップ1：設定ファイルを変更する
~/.codex/config.toml を開き、以下の設定を追加します。
注意：フィールドと値は、実際のサービスに合わせて記入してください：
よくある落とし穴：
model_providerは[model_providers.xxx]のxxxと完全に一致させる必要があります。1文字の違いも許されません。base_urlは/v1までとし、/v1/responses全体を含めないでください。wire_api = "responses"は Responses API 形式でリクエストすることを意味します。変更しないでください。requires_openai_auth = falseは公式ログイン状態を使用しないことを意味します。
ステップ2：環境変数を設定する
ターミナルを開き、以下を入力します：
ステップ3：ターミナルから Codex アプリを起動する
ここに注意点があります：Mac ユーザーはターミナルから起動する必要があります。アイコンを直接クリックするとモデルが読み込まれない可能性があります。
起動前に Codex アプリを完全に終了し、ターミナルで以下を入力します：
ステップ4：効果を確認する
Codex アプリを開くと、モデルが正常に切り替わっていることが確認できます：
なんと、動いてますね。
API Key ログインの例
API Key 方式を使用する場合、1つの原則を覚えておいてください：秘密鍵は環境変数に入れ、設定ファイルにハードコードしないこと。
対応する config.toml の設定：
注意点：上流が Chat Completions しかサポートしておらず、Responses API をサポートしていない場合、設定を変更するだけでは機能しません。CCX のようなゲートウェイを使用してプロトコル変換を行う必要があります。これについては方式3で説明します。
認証ファイルを変更する
~/.codex/auth.json を開き、OPENAI_API_KEY をモデルプロバイダーの Key に変更します：
設定成功の確認方法
設定後は焦らず、まず確認しましょう：
- Codex を完全に終了し、再度開きます。
- 読み取り専用のタスク（現在のディレクトリ構造の要約など）を実行させます。
- エラーが出た場合、最初に
model_provider名、base_url、環境変数を確認します。 - 認証エラーの場合は、まずバックアップ設定に戻しましょう。慌てる必要はありません。
方式2：Codex++
手動設定が面倒だと感じたら、Codex++ を試してみてください。
これはグラフィカルな管理ツールで、リレー設定をワンクリックで処理してくれます。手動で toml ファイルを書く必要はありません。
さらに、方式1ではできないプラグイン機能もサポートしています。
こんな人に適しています：
- 主に Codex デスクトップアプリを使用する方。
- 設定ファイルを手動で書きたくない方。
- いつでも公式モードに戻したい方。
インストール手順
- Codex++ Releases を開き、インストールパッケージをダウンロードします。
「Codex++ 管理ツール」と「Codex++ アプリ」の2つのインストールパッケージがあります。両方をインストールします。
- インストール後、「Codex++ 管理ツール」を開きます。
初めて開いたときにこのエラーポップアップが表示されても、慌てないでください：
「システム設定」-「プライバシーとセキュリティ」に移動し、「このまま開く」をクリックします：
開くと、管理インターフェースが表示されます：
Codex++ アプリも同様にインストールします。管理ツールの検出がすべて緑色になっていれば正常です：
GPT ログイン状態が検出されていることを確認します。
- リレー設定を追加します。
「プロバイダー設定」-「プロバイダーを追加」を選択し、Base URL と Key を入力します。
注意：アクセス方法は「Pure API」を選択します：
モデルリストは上流から自動取得できます。リレーサーバーを設定している場合、ここでは多くのモデルから選択できます：
要するに、このツールは設定をより便利に記述するためのもので、手動でファイルを編集する手間を省いてくれます：
保存後に接続テストを行います。問題がなければ、そのまま使用できます：
- Codex++ のエントリポイントから Codex を起動します。
注意：元の Codex ではなく、Codex++ から起動します：
再起動後、Codex がカスタムモデルプロバイダーを使用していることが確認でき、選択できるモデルの数が急に増えています：
プラグインも直接使用できます。これが完全な体験です：
正直、この方式が今まで使った中で一番スムーズです。強くおすすめします。
ロールバックしたい場合は？
- 管理ツールで API モードをクリアし、公式設定に戻します。
- Codex の更新後、Codex++ が動作しなくなった場合は、アダプテーションの更新を待ちましょう。元のバージョンの使用には影響しません。
方式3：CCX + CC Switch
この方式はパワーユーザー向けで、「ゲートウェイ」と「切り替えツール」を分離します：
- CCX：API プロキシゲートウェイ。プロトコル変換とルーティングを担当。Claude、OpenAI、Codex、Gemini など、様々なエントリポイントをサポート。
- CC Switch：デスクトップ管理ツール。異なるプロバイダー設定をワンクリックで切り替え。
どのような場合にこの方式を使うか？複数の国産モデル API、複数のリレーサービス、複数の Key を持っている場合、または上流が Chat Completions のみをサポートしており、Responses API への変換が必要な場合です。
ステップ1：CCX をデプロイする
Docker を使用して1つのコマンドで実行：
起動後、ブラウザで開くと確認できます。
ステップ2：上流チャンネルを追加する
CCX 管理インターフェースでチャンネルを追加します：
- 上流サービスタイプを選択します。
- API Key と Base URL を入力します。
- モデルマッピングとルーティングルールを設定します。
- 内蔵のテスト機能で接続を確認します。
ここで重要なポイント：Codex は Responses API エントリポイントを必要とします。上流が Chat Completions しか持っていない場合、CCX がプロトコル変換を実行します。これが CCX を使う核心的な理由です。
ステップ3：CC Switch をインストールする
コマンドラインでのインストール：
初期化：
初期化時に、CCX アドレスをリレーエントリポイントとして入力します。
ステップ4：設定を切り替えて起動する
1行のコマンドでプロバイダーを切り替えます：
その後、Codex を再起動して反映させます。
切り替え後、~/.codex/config.toml を開いて確認することをおすすめします：
model_providerは選択したものになっていますか？base_urlは CCX を指していますか？- 誤って Key を公開リポジトリに書き込んでいませんか？（これは非常に重要です）
よくある落とし穴のまとめ
最後に、トラブルシューティング表です。問題が発生したらまずこれを確認してください：
現象 | 最初に確認すること |
|---|---|
切り替え後に反映されない | Codex を完全に再起動したか、 |
認証エラー | API Key が有効か、環境変数が現在のシェルに継承されているか |
インターフェースパスエラー |
|
国産モデルが応答しない | 上流が Responses API をサポートしているか。サポートしていない場合、CCX で変換する必要がある |
プラグイン設定が消えた | 切り替えツールが設定を上書きした可能性。事前にバックアップを取ったか？ |
正直なところ、3つの方式すべてを実行したことがありますが、日常的に最も使っているのは方式2の Codex++ です。本当に手間いらずです。
もし複数の Key と複数のプロバイダーを持つパワーユーザーなら、方式3がより適しています。
よし、今日の共有は以上です。
このチュートリアルが役に立ったなら、いいねで教えてください。今後も Codex の実用的な使い方をどんどん更新していきます。
質問があれば、コメント欄に直接どうぞ。見たものにはすべて返信します。
