外部モデルをCodexに接続するのは複雑な作業です。このガイドでは、Kimi APIを実践例として使い、macOSとWindowsでのCodex API設定を一通り解説します。
Codexとは何ですか？
Codexは、リポジトリ作業やターミナル作業向けのOpenAIのコーディングAgentです。次のようなことができます。
コードを書く： 関数、テスト、スクリプト、焦点を絞った機能を作成します。
不慣れなコードベースを理解する： ファイルを検索し、呼び出しをたどり、構成要素を説明します。
コードをレビューする： 起こりうる欠陥、リスクのある前提、不足しているテスト、セキュリティ上の懸念を特定します。
デバッグして問題を修正する： エラーを再現し、変更案を提示し、チェックを実行します。
定型作業を自動化する： 承認のもとでファイルを更新し、文書化されたワークフローを実行します。
Codexをインストールしてサインインする
第1部：Codex CLIをインストールする
macOSではターミナルを、Windowsでは PowerShell を開きます。
お使いのOSに合わせて次のコマンドを実行します。
macOS：
curl -fsSL https://chatgpt.com/codex/install.sh | shWindows：
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"インストールが完了するまで待ってから、ターミナルまたはPowerShellを一度閉じて開き直します。
次を実行します。
codex「Sign in with ChatGPT」を選択し、ブラウザでのサインインを完了したら、ターミナルまたはPowerShellに戻ります。
パート2: Codex デスクトップアプリをインストールする
Codex デスクトップアプリの公式ページにアクセスします。
macOS または Windows 向けの ChatGPT デスクトップアプリをダウンロードします。
アプリをインストールして開き、ChatGPT アカウントでサインインします。
タスクを作成するか、プロジェクトを開き、作業モードとしてCodexを選択します。
Say hello in one sentence.と入力してメッセージを送信します。
内蔵AIモデルと外部LLM APIの比較
Codex をインストールした後は、内蔵のAIモデルを使用するか、対応する外部LLM APIに接続することができます。どちらが最適かは、どの程度の設定作業、柔軟性、アカウント管理を望むかによって変わります。
Codex 内蔵モデルを使用する
内蔵モデルは最もシンプルな体験を提供します。利用可能なモデルを選ぶだけで、別のサービスを稼働させたり、個別にAPIキーを設定したりすることなくコーディングを始められます。
利点:
追加の設定手順が不要で、すぐに使い始められます。
Codex のツールや機能と直接統合されている
管理すべきサービスや認証情報が少ない
制限事項:
選択できるのは自分のアカウントで利用可能なモデルのみです
他のプロバイダーのモデルを使いたい場合は柔軟性に欠けます
GPT の有料プランが必要で、利用コストは比較的高めです。
外部LLM APIを使用する
外部APIを使うと、より多くのモデルから選べるようになり、既存の別プロバイダーのアカウントを利用できます。ただし、モデルによっては追加の設定やローカルの互換ツールが必要で、それがないと Codex から利用できない場合があります。
利点:
他のプロバイダーのモデルを利用できる
さまざまなコーディングタスクに対してより柔軟に対応できる
外部APIアカウントと利用状況を別途管理できる
GPT の有料プランが不要です。コストを抑えたい場面に適しています。
制限事項:
APIキーと追加の設定が必要です
常時起動しておく必要のあるローカルルーターが必要になる場合があります
課金、互換性、プライバシー、トラブルシューティングは外部プロバイダーに依存します
最速でセットアップしたい場合は、まず内蔵モデルから始めてください。すでに外部APIアカウントを持っている、またはより多くのモデルから選びたい場合は、以下の手順に進んでください。ここでは、外部モデルを Codex に接続する実践例として Kimi API を使用します。
外部LLM APIをCodexに接続する方法：Kimiの例
macOSでのセットアップ
ステップ1：Terminal Aを開いてNode.jsとnpmを確認する
場所： Command+Spaceを押し、Terminalと入力してEnterを押します。この最初のウィンドウをTerminal Aとします。
実行：
node --version
npm --version期待される結果： 各コマンドがバージョンを表示します。Node.jsでv22.x.x、npmで10.x.xのような出力例が示されていますが、これは例であって最低要件ではありません。
コマンドが見つからない場合： ブラウザでhttps://nodejs.org/en/downloadを開き、LTS版macOS用の.pkgをダウンロードして、Finderでダウンロードフォルダを開き、パッケージをダブルクリックして、インストーラーのデフォルト設定を承諾します。Command+QでTerminalを閉じ、Terminal Aを開き直して、両方のバージョン確認コマンドを再実行してください。両方のコマンドがバージョンを返すまで先に進まないでください。
ステップ2：Kimi APIキーを作成する
Kimi APIプラットフォームを開きます。コンソールからAPIキーを作成し、パスワードマネージャーやシークレットマネージャーに保存してください。コンソールで完全なキーが一度しか表示されない場合は、ページを離れる前にコピーしておいてください。
ステップ3：Terminal AでMOONSHOT_API_KEYを設定する
場所： Terminal Aに戻ります。
実行：
export MOONSHOT_API_KEY="YOUR_KIMI_API_KEY"YOUR_KIMI_API_KEYの部分だけを実際のKimiキーに置き換えてください。引用符と変数名MOONSHOT_API_KEYはそのまま変更しないでください。
期待される結果： exportコマンドは何も出力しません。値が表示されずに設定されていることを確認します：
test -n "$MOONSHOT_API_KEY" && echo "Kimi key is set"TerminalにKimi key is setと表示されるはずです。
ステップ4：Terminal AからKimiを直接テストする
場所： MOONSHOT_API_KEYが設定されているTerminal Aをそのまま使用します。
実行：
curl --silent --show-error https://api.moonshot.ai/v1/chat/completions \
-H "Authorization: Bearer $MOONSHOT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","messages":[{"role":"user","content":"Say hello in one sentence."}],"stream":false}'期待される結果： JSONレスポンスが表示され、choices[0].message.contentに生成されたテキストが含まれます。
ステップ5：Terminal Bを開き、Terminal Aでルーターを起動する
場所： Terminal Aがアクティブな状態でCommand+Nを押し、2つ目のウィンドウを開きます。この新しいウィンドウをTerminal Bと呼びます。ルーターのコマンドを実行する前にTerminal Aに戻ってください。
Terminal Aで実行：
npx @codeproxy/cli --base-url https://api.moonshot.ai/v1 --model kimi-k2.7-code --apikey "$MOONSHOT_API_KEY"ベースURLやモデルを置き換えないでください。$MOONSHOT_API_KEYは変数参照のままにし、キーを貼り付けた2つ目のコピーにしないでください。
初回実行時に表示される可能性のあるプロンプト： npxがNeed to install ... Ok to proceed? (y)と表示することがあります。まずパッケージ名とリンク先のサードパーティのソースを確認してください。そのパッケージを承諾する場合のみyを入力してEnterを押してください。ここで特定のパッケージバージョンがテスト済みであると主張しているわけではありません。
期待される結果： プロセスが実行され続け、127.0.0.1:8787でリッスンしていると報告されます。Terminal Aは開いたままにしておいてください。
失敗した場合： npmがパッケージをダウンロードできない場合は、インターネット接続を確認し、node --versionとnpm --versionを再実行してください。ポート8787がすでに使用中の場合は、そのポートを使っている他のローカルプロセスを停止するか、そのターミナルに戻ってCtrl+Cを押してから、ルーターのコマンドを再実行してください。
ステップ6：Terminal Bからlocalhostをテストする
場所： Terminal Bをクリックします。
実行：
curl --no-buffer --show-error http://127.0.0.1:8787/v1/responses \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","input":"Say hello in one sentence.","stream":true}'期待される結果: ターミナルBには、Responses形式のストリーミングイベント、または1文の挨拶を含む出力が表示されます。イベントの正確な順序はルーターのリリースによって異なる場合があります。
Connection refused が表示された場合: ターミナルAを確認してください。ルーターが停止していたら、手順5のコマンドを再実行し、そのウィンドウを開いたままにしてください。ターミナルAに上流の 401 が表示されている場合は、そこで MOONSHOT_API_KEY をリセットしてからルーターを再起動してください。
手順7: macOS版Codex設定ファイルの作成と編集
場所: 引き続きターミナルBを使用します。
実行するコマンド:
mkdir -p "$HOME/.codex"
if [ -f "$HOME/.codex/config.toml" ]; then cp "$HOME/.codex/config.toml" "$HOME/.codex/config.toml.backup-$(date +%Y%m%d-%H%M%S)"; fi
touch "$HOME/.codex/config.toml"
open -e "$HOME/.codex/config.toml"これらのコマンドは、必要に応じてユーザーレベルの設定ファイルを作成し、既存のファイルがあればバックアップを取ったうえで、~/.codex/config.toml をTextEditで開きます。
ファイルが空の場合
次の完全な設定内容を貼り付けてください。
model = "kimi-k2.7-code"
model_provider = "kimi-proxy"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000ファイルにすでに設定が含まれている場合
既存のファイルを完全な設定内容で上書きしないでください。関係のない設定はそのまま残し、必要な行だけを個別に更新してください。
model =で始まる行を見つけ、その行全体を次のように置き換えてください。
model = "kimi-k2.7-code"model_provider =で始まる行を見つけ、その行全体を次のように置き換えてください。
model_provider = "kimi-proxy"model_context_window =で始まる行を見つけ、その行全体を次のように置き換えてください。
model_context_window = 256000model_supports_reasoning_summaries =で始まる行を見つけ、その行全体を次のように置き換えてください。
model_supports_reasoning_summaries = falseこれら4つの設定のいずれかがまだ存在しない場合は、ファイルの先頭付近に不足している行を追加してください。
次で始まる行があれば、その行全体を見つけて削除してください。
model_catalog_json =また、次で始まる行があれば、その行全体を見つけて削除してください。
service_tier =以下のセクションを追加してください。
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000[model_providers.openai] など、他のプロバイダーのセクションは削除しないでください。
notify、承認、サンドボックス、プロジェクト、インターフェースに関する既存の設定など、関係のない設定はそのまま残してください。他のユーザーの notify 行は、そのコンピューター固有の絶対パスを含んでいる場合があるため、コピーしないでください。
Command+S を押してファイルを保存し、TextEditを閉じてください。
手順8: Codexを再起動し、macOS版の総合テストを実行する
場所: ターミナルAではルーターを起動したままにします。ターミナルBでは、既存のCodexセッションがあれば Ctrl+C で終了し、使い捨て用のフォルダを準備します。
ターミナルBで実行するコマンド:
mkdir -p "$HOME/codex-kimi-test"
cd "$HOME/codex-kimi-test"
codexテスト: hello. と入力して Enter を押します。1文の返信があれば、基本的なリクエストの経路が確認できたことになります。
Windowsでのセットアップ
2つの独立したPowerShellウィンドウを使用します。PowerShell Aは現在のセッション用のKimiキーを保存し、ルーターを実行します。PowerShell Bはlocalhostのテスト、設定の編集、Codexの起動を行います。永続的なユーザー環境変数は今後開くウィンドウにも対応し、現在のセッションへの割り当てにより、PowerShell Aでキーがすぐに利用可能になります。
手順1：PowerShell Aを開き、Node.jsとnpmを確認する
場所： Windowsキーを押し、PowerShellと入力してWindows PowerShellを開きます。このウィンドウをPowerShell Aと呼びます。
実行：
node --version
npm --version想定される結果： 両方のコマンドがバージョンを表示します。v22.x.xや10.x.xのような値は例であり、最低要件ではありません。
コマンドが認識されない場合： ブラウザでhttps://nodejs.org/en/downloadを開きます。LTS版Windows用の.msiをダウンロードし、エクスプローラーでダウンロードフォルダーを開いてインストーラーをダブルクリックし、デフォルト設定のまま進めます。その際、Node.jsをPATHに追加するオプションがインストーラーに残っていることを確認してください。すべてのPowerShellウィンドウを閉じ、PowerShell Aを開き直して両方のコマンドを再実行します。
手順2：Kimi APIキーを作成する
Kimi APIプラットフォームを開きます。コンソールからAPIキーを作成し、パスワードマネージャーやシークレットマネージャーに保管してください。コンソールが完全なキーを一度しか表示しない場合は、ページを離れる前にコピーしておきます。
手順3：PowerShell Aで永続変数と現在セッションの変数を設定する
場所： PowerShell Aに戻ります。
実行：
[Environment]::SetEnvironmentVariable("MOONSHOT_API_KEY", "YOUR_KIMI_API_KEY", "User")
$env:MOONSHOT_API_KEY = "YOUR_KIMI_API_KEY"両方の行にあるYOUR_KIMI_API_KEYのみを、同じKimiキーに置き換えてください。MOONSHOT_API_KEY、User、引用符、句読点はそのままにしておきます。1行目は今後のプロセス用に値を保存し、2行目はPowerShell Aで即座に利用できるようにします。
想定される結果： 両方のコマンドは何も出力しません。キーを表示せずに存在を確認します。
$null -ne $env:MOONSHOT_API_KEYPowerShellはTrueを表示するはずです。
Falseと表示された場合： ストレート引用符を使って、現在セッションの割り当てを再実行してください。ポリシーによりUserへの書き込みがブロックされた場合は、この手順では現在セッションの値のまま進め、ユーザー環境変数の保存方法について管理者に確認してください。ログや共有テキストに露出したキーは失効させてください。
手順4：PowerShell AからKimiを直接テストする
APIリファレンスにはPOST URLと表示されることがありますが、POST https://...だけをPowerShellに直接入力しないでください。ここに示すようにInvoke-RestMethod -Method Postを使用します。
場所： $env:MOONSHOT_API_KEYが設定されているPowerShell Aのままにします。
実行：
$headers = @{ Authorization = "Bearer $env:MOONSHOT_API_KEY" }
$body = @{ model = "kimi-k2.7-code"; messages = @(@{ role = "user"; content = "Say hello in one sentence." }); stream = $false } | ConvertTo-Json -Depth 5
$response = Invoke-RestMethod -Method Post -Uri "https://api.moonshot.ai/v1/chat/completions" -Headers $headers -ContentType "application/json" -Body $body
$response.choices[0].message.contentエンドポイント、モデル、変数名は置き換えないでください。PowerShellは$env:MOONSHOT_API_KEYからキーを読み取ります。
想定される結果： 最後の行がchoices[0].message.contentから1文の挨拶を表示します。
401が返ってきた場合： キーがグローバルの.aiコンソールから発行されたものであることを確認し、必要であれば失効・再作成してから手順3の両方の割り当てを再実行し、再試行してください。モデルが拒否される場合は、IDが正確にkimi-k2.7-codeであることと、Kimiコンソールでモデルへのアクセス権を確認してください。
手順5：PowerShell Bを開き、PowerShell Aでルーターを起動する
場所： もう一度Windowsキーを押し、PowerShellと入力して2つ目のWindows PowerShellウィンドウを開きます。これをPowerShell Bと呼びます。ルーターのコマンドを実行するためにPowerShell Aに戻ります。
PowerShell Aで実行：
npx @codeproxy/cli --base-url https://api.moonshot.ai/v1 --model kimi-k2.7-code --apikey $env:MOONSHOT_API_KEY$env:MOONSHOT_API_KEYはそのままにし、キーを直接コマンドに貼り付けないでください。
初回実行時に表示される可能性のあるプロンプト： npxがNeed to install ... Ok to proceed? (y)と表示することがあります。パッケージとサードパーティの提供元を確認してください。同意する場合のみyと入力してEnterを押します。特定のパッケージバージョンでテスト済みであるとは主張していません。
想定される結果： プロセスは開いたままとなり、127.0.0.1:8787で待ち受けていると報告されます。PowerShell Aは開いたままにしておきます。
失敗する場合： PowerShell Aでnode --versionとnpm --versionを実行してください。どちらかが失敗する場合は、手順1をやり直します。ポート8787が使用中の場合は、そのウィンドウでCtrl+Cを押して他のルーターを停止してから、コマンドを再実行してください。
手順6：PowerShell Bからlocalhostをテストする
場所： PowerShell Bをクリックします。PowerShell Aのルーターは停止しないでください。
実行：
$localBody = @{ model = "kimi-k2.7-code"; input = "Say hello in one sentence."; stream = $false } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri "http://127.0.0.1:8787/v1/responses" -ContentType "application/json" -Body $localBodylocalhostのURLは置き換えないでください。これはPowerShell Aのルーターを指しています。
期待される結果： PowerShellがResponses形式に似たオブジェクト、またはグリーティングを含む出力を返します。フィールドの詳細はルーターのリリースによって異なる場合があります。
接続が拒否された場合： PowerShell Aを確認し、ルーターが終了していたらStep 5のコマンドを再実行してください。PowerShell Aにアップストリームの認証エラーが表示されている場合は、Ctrl+Cを押して$env:MOONSHOT_API_KEYをリセットし、ルーターを再起動してください。デフォルトの@codeproxy/cliクイックスタートでは、ローカルの認可ヘッダーを追加しないでください。
Step 7：Windows版Codexの設定ファイルを作成・編集する
場所： 引き続きPowerShell Bを使用します。プロバイダー設定はプロジェクトフォルダではなく、$HOME\.codex\config.tomlに置く必要があります。
実行：
New-Item -ItemType Directory -Force -Path "$HOME\.codex" | Out-Null
$configPath = "$HOME\.codex\config.toml"
if (Test-Path $configPath) { Copy-Item $configPath "$configPath.backup-$(Get-Date -Format 'yyyyMMdd-HHmmss')" }
if (-not (Test-Path $configPath)) { New-Item -ItemType File -Path $configPath | Out-Null }
notepad "$HOME\.codex\config.toml"これらのコマンドは、ユーザーディレクトリを作成し、既存の設定ファイルがあればバックアップを取り、ファイルが存在しない場合は新規作成し、Notepadで開きます。
Notepadで： 以下の完全なデフォルト設定を貼り付けます。ファイルに競合するmodelやproviderのキーがすでに含まれている場合は削除してください。
model_provider = "kimi-proxy"
model = "kimi-k2.7-code"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000kimi-proxy、localhostのURL、responsesは置き換えないでください。Ctrl+Sを押してNotepadを閉じます。
ファイル名を確認： 以下を実行します。
Get-Item "$HOME\.codex\config.toml" | Select-Object FullName, Name, Length期待される結果： Nameがconfig.toml.txtではなく正確にconfig.tomlであり、Lengthが0より大きいこと。
Notepadが.txtを追加した場合： Notepadでファイル→名前を付けて保存を選び、ファイルの種類をすべてのファイルに設定し、config.tomlと入力して$HOME\.codexに保存します。Get-Itemを再実行してください。Codexがプロバイダーを無視する場合は、ユーザーレベルのパスを編集したか、重複するTOMLキーを削除したかを確認してください。
Step 8：Codexを再起動しWindows版の完全なテストを実行する
場所： PowerShell Aとそのルーターは起動したままにしておきます。Codexアプリまたはセッションはすべて完全に閉じます。PowerShell Bを閉じ、Windowsキー→「PowerShell」と入力→Windows PowerShellを開いて再度起動し、使い捨てのフォルダを作成します。
再度開いたPowerShell Bで実行：
New-Item -ItemType Directory -Force -Path "$HOME\codex-kimi-test" | Out-Null
Set-Location "$HOME\codex-kimi-test"
codexテスト： hello.と入力してEnterを押します。一文の返信があれば、基本的なリクエスト経路が機能していることが確認できます。
Codexデスクトップアプリで Kimi を使う
続行する前に、ローカルルーターとconfig.tomlのためのmacOSまたはWindowsセットアップのStep 1～7を完了してください。CLIテストを先に完了する必要はありませんが、デスクトップアプリでKimiを使用している間はルーターを起動したままにしておく必要があります。
Step 1：ローカルルーターを起動したままにする
Terminal AまたはPowerShell Aを開いたままにし、@codeproxy/cliを以下で実行し続けます。
http://127.0.0.1:8787Step 2：プロバイダー設定を確認する
ユーザーレベルのCodex設定ファイルを開きます。
macOSでは以下を実行します。
open -e "$HOME/.codex/config.toml"Windowsでは以下を実行します。
notepad "$HOME\.codex\config.toml"ファイルに以下のトップレベル設定が含まれていることを確認します。
model = "kimi-k2.7-code"
model_provider = "kimi-proxy"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000Step 3：デスクトップアプリを完全に再起動する
macOSでは、Command+Qを押してデスクトップアプリを完全に終了します。ウィンドウを閉じるだけでは不十分です。
Windowsでは、デスクトップアプリのウィンドウをすべて閉じ、システムトレイでアプリが実行されていないことを確認します。
デスクトップアプリを再度開き、プロジェクトフォルダーを開きます。
ステップ4：Customモデルを選択したままにする
デスクトップのモデル選択には Kimi K2.7 Code ではなく Custom と表示される場合があります。これは想定どおりの動作です。
config.toml で定義したカスタムプロバイダーは、デスクトップのモデル一覧に名前がそのまま表示されないことがあります。Kimi プロバイダーを使いたい場合に、GPT-5.6 Sol のような OpenAI モデルを選択しないでください。Custom を選択したままにしてください。
次のような警告が表示されることもあります。
Model metadata for `kimi-k2.7-code` not found.
Defaulting to fallback metadata.これは警告であり、接続失敗ではありません。以下の設定によって、通常利用に必要な重要なモデル情報はすでに提供されています。
model_context_window = 256000
model_supports_reasoning_summaries = falseステップ5：デスクトップのリクエスト経路を確認する
デスクトップアプリで次のプロンプトを送信してください。
デスクトップアプリが応答している間、ターミナルAまたはPowerShell Aの様子を確認してください。ターミナルAのウィンドウに新しいリクエストが届き、デスクトップアプリが回答を返せば、デスクトップアプリはローカルのKimiルートを使用しています。
よくある連携エラーのトラブルシューティング
zsh: command not found: POST
POST URL はコマンドではなく、APIドキュメント上の表記です。macOSでは完全な curl の例をコピーしてください。Windowsでは完全な Invoke-RestMethod -Method Post の例をコピーしてください。
ポート8787で接続が拒否される
ターミナルAまたはPowerShell Aに戻ってください。ルータープロセスが動作していない場合は、現在のセッションのKimi変数を設定し、手順に記載された npx @codeproxy/cli ... コマンドを再実行してください。そのウィンドウは開いたままにし、ウィンドウBでlocalhostのテストを再度行ってください。
401応答が返る
ルーターのウィンドウを確認し、どの段階で失敗しているかを特定してください。上流のKimi側で 401 が返る場合、通常は MOONSHOT_API_KEY が無効、失効している、または地域が異なるアカウントのものであることが原因です。グローバルの .ai コンソールでキーを失効させ、新しいキーを作成し、現在のセッションの変数をリセットして、ルーターを再起動してください。デフォルトのルーター経路には受信側のベアラー認証チェックはありません。他のアダプターでローカルの 401 が発生する場合、オプションの CODEX_KIMI_PROXY_KEY が未設定または無効であることが原因のことがあります。
サポートされていないパラメーターやツールのエラー
ルーターがKimiでは受け付けられないフィールドを転送している可能性があります。サンプリング関連のフィールドは未設定のままにしてください。もし送信する場合は、許容された固定値のみを使用する必要があります。tool_choice が auto または none になっていること、およびアダプターが reasoning_content を保持していることを確認してください。それでも複数ステップのテストが失敗する場合は、そのルーターのリリースの使用を中止し、Kimiを明示的にサポートしているものを選ぶか、更新してください。
Codexがプロバイダーを無視する
ユーザーファイルを直接開いてください。macOSでは open -e "$HOME/.codex/config.toml" を、Windowsでは notepad "$HOME\.codex\config.toml" を実行します。トップレベルの model_provider = "kimi-proxy" が1つ、プロバイダーテーブルが1つ、localhostのベースURL、そして wire_api = "responses" があることを確認してください。保存し、Codexを完全に終了してから再起動してください。プロバイダーの選択をプロジェクトの .codex/config.toml だけに設定しないでください。
npxがルーターを起動できない
ルーターのウィンドウAで node --version と npm --version を実行してください。どちらかのコマンドが失敗する場合は、nodejs.org/download からNode.jsのLTSパッケージをインストールし、ターミナルを閉じて開き直してから再試行してください。npx がパッケージのダウンロード許可を求めてきた場合は、y を入力する前にパッケージと提供元を確認してください。
Kimi APIを使用するメリット
Cursor APIのワークフローでKimiを使用すると、コーディング、デバッグ、開発作業を改善できます。高度な機能により、正確な応答の生成、複雑な指示への対応、より速い問題解決の支援が可能になります。ここでは、Cursorのワークフローの生産性と効率を高めるためにKimiを使用する主なメリットを紹介します。
長いコンテキストでのコード理解
Kimiは大量のコードや情報を一度に処理できます。異なるファイルやプロジェクトのセクション間の関係もより効果的に把握します。その結果、大規模あるいは複雑なコードベースを扱う作業がずっと容易になります。
ドキュメントとリポジトリ分析の向上
プロジェクトのドキュメント、技術ノート、リポジトリをKimiで素早く確認できます。すべてのファイルを手作業で確認しなくても、重要な詳細を見つけやすくなります。開発者はより短い時間でプロジェクト全体をより明確に把握できます。
費用対効果の高いAI開発
Kimiは、多くの開発タスクを扱ううえで実用的かつ予算に優しい選択肢を提供します。高コストなモデルに全面的に依存することなく、強力なAIサポートを利用できます。チームは支出をより適切に抑えながら、全体の生産性を高めることができます。
より速い情報検索
大規模なコードベース、データセット、プロジェクトファイルの中から必要な情報を素早く見つけ出せます。答えや参照資料を探すために費やす時間が減り、コーディングやテスト、プロジェクトの改善により多くの注意を向けられます。
ワークフロー自動化の改善
Kimiを使えば、繰り返し発生する開発タスクの管理や完了がしやすくなります。コード生成、コンテンツレビュー、日常的なプロジェクト作業を支援できます。日々のワークフローは整然とし、効率的で、時間とともに生産性が高まっていきます。
Codexが開発ワークフローをどう改善するか
設定済みのCodex CLI APIワークフローは、リポジトリの調査、編集、コマンド実行、レビューを一つのコンテキストの中でつなげます。Codexはファイルのひな型を作成したり、見慣れないモジュールを説明したり、不具合を再現したり、テストを提案したり、承認済みのチェックを実行したりできます。外部プロバイダーのサポートによってモデルの選択肢が増えますが、レビューの責任がなくなるわけではありません。
各タスクは狭い目標から始めましょう。編集の前に調査するようCodexに指示し、提案された変更をレビューし、自分が理解しているコマンドのみを承認し、リポジトリのテストを実行し、最終的な差分を確認してください。生成されたコードは、レビューと検証を通過するまでは信頼できないものとして扱いましょう。
まとめ
信頼できるCodex APIの利用は、各レイヤーを順番にテストすることから生まれます。Codexを認証し、Kimiを直接呼び出し、localhostを起動してテストし、ユーザーレベルのプロバイダー設定を保存し、読み取り専用のプロンプトを実行し、ファイルとツールを使ったタスクを完了させます。実際のKimiキーはルーターに保持し、シークレットを共有ファイルに置かないようにし、作業が終わったらルーターを停止してください。