> ## Documentation Index > Fetch the complete documentation index at: https://docs.kodus.io/llms.txt > Use this file to discover all available pages before exploring further. # BYOK - Bring Your Own Key > 自分のプロバイダーキーを接続し、各タスクを実行するモデルを選択します。すべての Kodus プランでご利用いただけます。 BYOK（Bring Your Own Key）は、**すべてのプランで Kodus が LLM を使用するデフォルトの方法**です — Community、Teams、Enterprise を問わず。自分のプロバイダーアカウントを接続し、使いたいモデルを有効化し、各タスクを実行するモデルを選択します。プロバイダーに直接支払い、Kodus はトークンに上乗せ料金を請求せず、APIキーを平文で見ることも決してありません。 BYOK は Community では無料、Teams では利用可能（トークン費用に加えてアクティブ開発者1人あたり月10ドル）、Enterprise では2つのオプションのうちの1つです（もう1つは Kodus が管理する APIキー）。 ## BYOK の仕組み BYOK は**プロバイダーファースト**です：プロバイダーを一度接続し、使いたいモデルをそれに追加し、それらのモデルを Kody のタスクにルーティングします。`/byok` 画面には3つのタブがあります： キーを使ってプロバイダーを接続し、それぞれで使うモデルを有効化します。カウントバッジは接続したプロバイダーの数を表示します。 各タスクを実行するモデルを選択します — すべてのタスク向けの1つのデフォルト、任意のフォールバック、エージェントごとのオーバーライド。 接続したモデル全体にわたる任意の月次支出上限を設定します。 **編集できるユーザー。** BYOKページは **Owner 専用**です — キーの接続・テスト・削除には **Owner** ロールが必要です。他のロール(Billing Manager、Repo Admin、Contributor)は `/byok` にアクセスできません。[ワークスペースのロール](/ja/how_to_use/workspace_roles)を参照してください。 ## プロバイダーを接続する [app.kodus.io/byok](https://app.kodus.io/byok) にアクセスします。新しいワークスペースでは **Connect your first provider** が表示されます。 プロバイダーのグリッドは2つに分かれています： * **Providers** — APIキーだけで接続できるファーストクラスのプロバイダー（OpenAI、Anthropic、Google AI Studio、OpenRouter、Novita…）。 * **Custom** — 独自のエンドポイントを指定したり任意のモデルを実行したりするプロバイダー：**OpenAI-compatible**、**Anthropic-compatible**、**Google Vertex AI**、**Amazon Bedrock**。これらには *Custom endpoint* のヒントが付いています。 すでに接続済みのプロバイダーには **Connected · N models** と表示されます。 プロバイダーを選ぶと、その **Add a model** フォームが開きます。APIキーを一度貼り付けると（その後そのプロバイダーに追加する各モデルで再利用されます）、モデルを選択します： * Kodus がプロバイダーのモデルをリスト化できる場合、ドロップダウンが表示されます。 * そうでない場合（カスタムエンドポイント、セルフホスト、またはプラットフォームキーが未設定の場合）、正確なモデル ID を入力します。 カスタムエンドポイント（OpenAI-compatible / Anthropic-compatible）では、まず **base URL** も求められます。 **Advanced settings** の下：thinking/reasoning、temperature、最大出力トークン、最大入力トークン、最大同時リクエスト数。デフォルト値はほとんどのプロバイダーで適切です — モデルごとに Kodus がロックまたは非表示にするフィールドについては [Reasoning](#reasoning--拡張思考) と [Temperature](#temperature) を参照してください。 **Test** をクリックしてプロバイダーをプローブするか、**Test & save** をクリックしてテストを実行し成功時に保存します。キーは一度だけ貼り付ければよいので、プロバイダーには好きなだけモデルを追加できます。 **別のプロバイダーを追加** するには、いつでも Providers タブから行えます。各プロバイダーは独自のキーを保持します。接続済みのプロバイダーでさらにモデルを有効化しても、キーを再度求められることはありません。 ## 保存前にテストする **Test** ボタンは、実際のレビューが壊れる前に設定を検証します。何を行うかはプロバイダーによって異なります： | プロバイダー | Test が行うこと | | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **Anthropic-compatible ブランド**（Kimi、Z.ai、DeepSeek）、**OpenAI-compatible**、**Novita** | 正確なモデルに対して実際の **1トークンのチャットリクエスト** を送信します — レビューが行うのと同じ呼び出しです。誤ったモデル ID、制限されたキー、エンドポイントの問題をその場で検出します。 | | **OpenAI、Anthropic、Google（Gemini/Vertex）、OpenRouter、Bedrock** | 安価な identity/metadata 呼び出し（list-models、トークン交換、または STS）— キーとエンドポイントが機能することを確認します。 | チャットプローブのパスでは、Test は **設定したチューニングをモデル自身のルールに対しても検証** し、モデルがサイレントに無視する設定を保存する代わりに、早期に具体的なエラーを返します： * 常に thinking するモデルが尊重しない temperature（`1` に固定されます — [Temperature](#temperature) を参照）。 * 常に reasoning し無効化できないモデルで reasoning を **Off** にした場合。 チャットプロバイダーは実際のモデルを実行するようになったため、**モデル ID のタイプミスは最初のレビューではなく Test の時点で検出されます** — レスポンスは `Model not found` で返ってきます。 ## ルーティング：各タスクを実行するモデル 2つ以上のモデルを接続すると、**Routing** タブがどのモデルが何を実行するかを決定します。ルーティングは**フラット**です：オーバーライドするまで、すべてのタスクがデフォルトを使用します。 **Manual · you choose** が現在有効です。**Auto · Kodus optimizes** は近日公開予定です。 * **Model for all tasks** — オーバーライドされない限り、すべてのタスクが使用する1つのモデル。 * **Fallback (optional)** — タスクのモデルが失敗したときに Kody が呼び出しを一度だけ再実行する*別の*モデル：無効または期限切れのキー、クレジット不足、またはプロバイダーのダウン（プロバイダー自身のリトライの後）。 さまざまな Kody タスク（コードレビュー、Kody Rules、チャット、要約など）は、それぞれ異なるモデルを実行できます — 深いレビューには高価なモデル、要約には安価なモデル。特定のタスクを実行できないモデルは、その行で無効化されツールチップが表示され、保存前に分かります。 **Save routing** をクリックして保存します。**Reset agents to default** は、すべてのエージェントごとのオーバーライドをデフォルトに戻し、フォールバックをクリアします（デフォルトモデル自体は保持されます）。下部の読み取り専用の **Per repository** パネルは、Code Review Settings で設定されたリポジトリごとのモデルオーバーライドを反映します。 接続済みのモデルが1つの場合、ルーティングはスキップされます — すべてのタスクがそのモデルを使用します。ルーティングを意味のあるものにするには、2つ目のモデルを接続してください。 ## モデルの選択 プロバイダーが提供する任意のモデルが利用できます。どこから始めればよいか分からない場合、これらはコードレビューに適した選択肢です： **最良のバランス / フラッグシップ品質。** Anthropic の適応的な拡張思考と強力なクロスファイル分析。キー：[console.anthropic.com](https://console.anthropic.com/settings/keys)。 **最大のコンテキスト。** Google のフラッグシップ — 大規模な PR やモノレポで最強。キー：[aistudio.google.com/apikey](https://aistudio.google.com/apikey)。 **高速で一貫性がある。** OpenAI のフラッグシップライン — 信頼性の高い低レイテンシ、幅広い知識。キー：[platform.openai.com/api-keys](https://platform.openai.com/api-keys)。 **サブスクリプションで最安。** Moonshot の Kimi と Z.ai の GLM は、月次支出を抑える定額のコーディングプランを提供しています。下記の [Kimi と GLM の接続](#kimi-moonshot-と-glm-zai-の接続) を参照してください。 **デフォルトの推奨:** 最良の全体的な体験には **Claude Sonnet** から始めましょう。コストが優先事項の場合、**GLM Coding Plan** または **Kimi Code Plan** が定額サブスクリプションを提供します。プロバイダーが文書化している正確なモデル ID を入力してください — Kodus はそこから表示名を導出します。 ## Kimi (Moonshot) と GLM (Z.ai) の接続 Moonshot と Z.ai はどちらも、ペイパートークンの Developer API とは **異なるエンドポイント** のサブスクリプションプランを提供しています。各プランは独自のキーを持つ別々のアカウントです — 持っているキーに合ったベース URL を選択してください。 | プラン | エンドポイント | キーの取得元 | 最適な用途 | | ------------------ | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- | ---------------------------- | | **Developer API** | `https://api.moonshot.ai/v1`（OpenAI-compatible）または `https://api.moonshot.ai/anthropic`（Anthropic-compatible） | [platform.moonshot.ai](https://platform.moonshot.ai/console/api-keys) | ペイパートークン、同時実行数はリチャージティアとスケール | | **Kimi Code Plan** | `https://api.kimi.com/coding/v1` | [kimi.com/code](https://www.kimi.com/code) | 専用コーディングエンドポイント付きサブスクリプション | Kimi Code Plan は 30 concurrent リクエストの上限が文書化されています — `maxConcurrentRequests=30` を設定してください。常に reasoning する Kimi バリアント（例：`kimi-k2p7-code`、`kimi-k3`）は temperature を `1` に固定し、reasoning をオフにできません — [Temperature](#temperature) を参照してください。 | プラン | エンドポイント | キーの取得元 | 最適な用途 | | ----------------- | ------------------------------------- | ------------------------------------------------------------ | --------------------- | | **Developer API** | `https://api.z.ai/api/paas/v4/` | [z.ai/manage-apikey](https://z.ai/manage-apikey/apikey-list) | バースト的なワークロード、ペイパートークン | | **Coding Plan** | `https://api.z.ai/api/coding/paas/v4` | [z.ai/subscribe](https://z.ai/subscribe) | 予測可能なチーム使用量、定額月額料金 | GLM Coding Plan のキーは `/api/coding/paas/v4` で**のみ**動作します。Lite および Pro ティアはしばしば **1 concurrent リクエスト** に制限されています — `maxConcurrentRequests=1` を設定し、Max ティアの場合のみ（最大 30 まで）引き上げてください。 ## 対応プロバイダー **おすすめの用途:** 最新の GPT モデルと信頼性の高いパフォーマンス。 **APIキーの取得方法:** 1. [OpenAI API Keys](https://platform.openai.com/api-keys) にアクセス 2. Kodus 用の新しいキーを作成 3. 請求情報を追加 **おすすめの用途:** 大規模コンテキストレビュー（1M トークン）と競争力のある価格設定。 **APIキーの取得方法:** 1. [Google AI Studio](https://aistudio.google.com/app/apikey) に移動 2. 新しいキーを作成 3. Google Cloud Console で請求を有効化 **おすすめの用途:** 微妙な分析と適応的な拡張思考。 **APIキーの取得方法:** 1. [Anthropic Console](https://console.anthropic.com/) にアクセス 2. アカウントを作成しキーを生成 3. クレジットを追加 **おすすめの用途:** 競争力のある価格のオープンソースおよびホスト型モデル（Llama、DeepSeek、Kimi）。 **APIキーの取得方法:** 1. [Novita AI](https://novita.ai/) でサインアップ 2. API 設定に移動 3. キーを生成 スクリーンショット付きの詳細なセットアップ手順。 **おすすめの用途:** 多くのモデルにわたる1つの請求関係。 **APIキーの取得方法:** 1. [OpenRouter](https://openrouter.ai/) でアカウントを作成 2. クレジットを追加 3. 設定でキーを生成 OpenRouter はデフォルトで各リクエストを異なる上流プロバイダーにルーティングするため、呼び出しごとに品質やレイテンシのドリフトが発生する可能性があります。動作を安定させるには、Advanced settings → OpenRouter routing で\*\*特定の上流プロバイダーを固定（ピン留め）\*\*してください。[OpenRouter プロバイダーの固定](#openrouter-プロバイダーの固定) を参照してください。 **ベータ。** 単一キーが基本の他プロバイダーより認証の手順が複雑です。 **こんな場合に：** すでに Google Cloud を使っていて、既存の GCP の請求・IAM・データレジデンシー要件のもとで Gemini（または Claude）を使いたいチーム。 **設定方法：** 1. 接続フローでプロバイダーに **Google Vertex AI**（Custom の下）を選びます。 2. **サービスアカウント JSON ファイルの中身**を Service Account JSON 欄に貼り付けます（base64 でも可）。Kodus は JSON から `project_id` を自動で抽出します。 3. **Region** — グローバルエンドポイントを使う場合は空のままにします（推奨）。データレジデンシー要件がある場合のみ、リージョン（例：`us-east5`）を固定します。 サービスアカウントには、そのプロジェクトで Vertex AI の予測 API を呼び出す権限が必要です。Test は*実際に設定されたモデル*をプローブするため、利用できないモデル/リージョンは Test の時点で失敗します。 **ベータ。** 単一キーが基本の他プロバイダーより認証の手順が複雑です。 **こんな場合に：** AWS に標準化していて、モデルの利用料を自社の AWS アカウントで請求したいチーム。 **設定方法：** 1. 接続フローでプロバイダーに **Amazon Bedrock**（Custom の下）を選びます。 2. **Bedrock API キー**（ベアラートークン）を入力します — [Bedrock API キーの生成方法](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-generate.html)を参照。 3. **Region** を設定します（例：`us-east-1`、`us-west-2`、`eu-central-1`）。 Bedrock API キーへ移行していないチームは、**Advanced — use IAM user credentials instead** を開いて、静的なアクセスキー ID とシークレット（STS の一時認証情報の場合はセッショントークンも）を入力します。IAM プリンシパルには `bedrock:InvokeModel` が必要です。 API キーが優先されます。ベアラートークンが設定されている場合、IAM の項目は無視されます。 **おすすめの用途:** 特化プロバイダー（Moonshot、Z.ai、Fireworks、Together、Groq、DeepSeek）またはセルフホストエンドポイント。 **設定方法:** 1. 接続フローで、プロバイダーとして **OpenAI Compatible**（Custom の下）を選択します。 2. ベース URL を入力します（例：`https://api.moonshot.ai/v1`、`https://api.z.ai/api/paas/v4/`、`https://api.fireworks.ai/inference/v1`）。 3. キーとモデル ID を提供します。 モデル ID はプロバイダー固有です — 一部はディープパスを使用します（例：Fireworks：`accounts/fireworks/models/kimi-k2p7-code`）。プロバイダーのダッシュボードから正確な ID をコピーしてください。Test は実際のリクエストを送信するため、誤った ID は即座に失敗します。 Coding Plan の詳細を含む完全な Z.ai セットアップ。 Kimi + Kimi Code Plan のセットアップ。 Fireworks 固有のセットアップ。 Together AI のセットアップ。 **こんな場合に：** OpenAI 形式ではなく Anthropic の Messages API を話すエンドポイント — Kimi のようなコーディングプランのエンドポイントを含みます。 **設定方法：** 1. 接続フローで **Anthropic-compatible**（Custom の下）を選びます。 2. ベース URL、キー、モデル ID を入力します。 ベース URL はプロバイダーが示す形式のまま貼り付けてください — 末尾の `/v1` はあってもなくても構いません（例：`https://api.kimi.com/coding` または `https://api.kimi.com/coding/v1`）。Anthropic の 2 つの SDK 経路は `/v1` の位置の解釈が異なるため、Kodus が内部で正規化します。既知のブランドの場合、キーのみの接続でエンドポイントが自動的に解決されます。 ## Reasoning / 拡張思考 **Add a model** フォームでは、**Advanced settings** の下に **Thinking** トグル（Off / Low / Medium / High / Custom）が表示されます。利用可能なオプションは、モデルが実際にできることを反映しています： * reasoning できないモデルは注記付きで **Off** に固定されます。 * 特定のレベルでのみ reasoning するモデル（例：GPT-5 の medium/high）は、無効なものを無効化します。 * デフォルトで reasoning するモデルは、妥当な出発点として **Medium** が設定されます。 ### プリセットレベル Low / Medium / High を選択すると、Kodus はそのレベルを各プロバイダーのネイティブフォーマットに自動的に変換します： | プロバイダー | "medium" のマッピング | | ------------------------------------------------------------------ | ----------------------------------------------------- | | **Anthropic** (Claude adaptive) | `thinking: { type: "adaptive" }` + `effort: "medium"` | | **Google** (Gemini) | `thinkingConfig: { thinkingLevel: "medium" }` | | **OpenAI** (GPT-5 / o-series) | `reasoningEffort: "medium"` | | **OpenRouter** | `reasoning: { effort: "medium" }` | | **OpenAI-compatible / Anthropic-compatible** (Kimi, GLM, DeepSeek) | `thinking: { type: "enabled" }` — バイナリの on/off、レベルは無視 | Kimi と GLM は現在、reasoning を単一の on/off フラグとして公開しています。Low、Medium、High のいずれを選んでも同じペイロード（thinking 有効）を生成します。**常に reasoning するバリアント**（Kimi `k2p7-code`/`k3`、GLM-5.3）は無条件に reasoning します — Off にできず、フォームはそのオプションを無効化します。 ### カスタム JSON オーバーライド Thinking トグルで **Custom** を選択すると JSON テキストエリアが表示されます。プロバイダーオプションを直接貼り付けてください — **Kodus がアクティブなプロバイダーの名前空間の下に自動でラップします**。Vercel AI SDK のルーティングルールを知る必要はありません。 以下の場合に使用します： * Claude に特定の `budgetTokens` 値が必要な場合（プリセットの effort マッピングの代わり） * OpenAI 互換プロバイダーでモデルごとに thinking を有効/無効にしたい場合 * reasoning 以外のフィールドが必要な場合 — **キャッシュ、サービスティア、safety settings、`user` タグなど**。オーバーライドは `providerOptions` にマージされるため、アダプターの任意のフィールドがそのまま通過します * Kodus がまだラップしていない新しいフィールドがプロバイダーに追加された場合 #### 例（名前空間不要 — そのまま貼り付け） Claude の thinking 予算を正確に 20,000 トークンにオーバーライド： ```json theme={null} { "thinking": { "type": "enabled", "budgetTokens": 20000 } } ``` プロンプトキャッシュを有効化（reasoning 以外の例）： ```json theme={null} { "cacheControl": { "type": "ephemeral" } } ``` 明示的な thinking 予算（Gemini 2.5）またはレベル（Gemini 3+）： ```json theme={null} { "thinkingConfig": { "thinkingBudget": 16000 } } ``` safety settings を調整： ```json theme={null} { "safetySettings": [ { "category": "HARM_CATEGORY_DANGEROUS_CONTENT", "threshold": "BLOCK_NONE" } ] } ``` OpenAI 固有のフィールドを伴う reasoning： ```json theme={null} { "reasoningEffort": "high", "serviceTier": "flex", "store": false, "user": "kodus-review" } ``` reasoning を強制しつつ特定の上流を無視： ```json theme={null} { "reasoning": { "effort": "high" }, "ignore": ["deepinfra"] } ``` 予算ヒント付きで thinking を有効化： ```json theme={null} { "thinking": { "type": "enabled", "budget_tokens": 25000 } } ``` thinking を明示的に無効化（それをサポートするモデルでのみ）： ```json theme={null} { "thinking": { "type": "disabled" } } ``` 上流プロバイダーが認識しないフィールド（例：それを無視するサーバー上の `budget_tokens`）はサイレントに破棄されます。プロバイダーのドキュメントを確認して受け入れるものを確認してください。 #### 名前空間を手動で指定する（上級者向け） JSON がすでに既知の名前空間キー（下記のマッピング表のいずれかのキー）でトップレベルから始まっている場合、Kodus はそれをそのまま残します。複数のプロバイダー名前空間を混在させたい場合や、明示的に記述したい場合に便利です： ```json theme={null} { "openrouter": { "reasoning": { "effort": "high" }, "provider": { "order": ["moonshot"], "allow_fallbacks": false } } } ``` 内部的に、Kodus は以下の名前空間マッピングを使用しています： | BYOK プロバイダー | 名前空間キー | | ------------------------------------ | ------------------------------------------------ | | `anthropic` / `anthropic_compatible` | `anthropic` | | `google_gemini` | `google` | | `google_vertex` | Gemini は `google`、Vertex 上の Claude は `anthropic` | | `openai` | `openai` | | `openai_compatible` | `openaiCompatible` | | `azure` | `azure` | | `amazon_bedrock` | `amazonBedrock`（`bedrock` も可） | | `novita` | `novita` | | `open_router` | `openrouter` | #### 注意点 * **有効な JSON のみ。** カンマの欠落や末尾のカンマはパースを壊し、Kodus はオーバーライドを無視します。 * **優先順位:** JSON オーバーライドは effort プリセットの名前空間ブロックを**完全に置き換えます** — `anthropic.thinking` をオーバーライドしつつ `anthropic.effort` を忘れると、そのフィールドは送信されません。OpenRouter routing（Pin providers / Allow fallbacks）は唯一の例外で、`openrouter` の下でオーバーライドとディープマージされます。 * **未知のプロバイダー = ラップなし。** BYOK プロバイダーが上記の名前空間テーブルにない場合、Kodus は JSON をそのまま通過させます。 ## Temperature Temperature は **Advanced settings** の下にあり、フィールドはモデルのルールに適応します — フォームが推測するのではなく、プロバイダーによって設定されます： | モデル | Temperature フィールド | | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | ほとんどのモデル | **編集可能**（0 = 決定的、2 = 創造的）。 | | 常に reasoning する Anthropic プロトコルのモデル（Kimi `k2p7-code`/`k3`、GLM-5.3） | **`1` に固定。** このプロトコルは thinking 中に temperature を 1 に固定するため、1 が唯一の妥当な値です — フィールドにはロックが表示され、保存された値に関わらず Kodus は `1` を送信します。 | | Claude 4.7+ および OpenAI GPT-5 / o-series | **非表示。** これらのモデルは temperature を廃止し、それを設定するリクエストを拒否します — 代わりに thinking レベルで調整してください。 | チャットプローブのプロバイダーでは、[Test](#保存前にテストする) が設定した temperature をこれらのルールに対して検証し、保存前にエラーを返します — モデルが尊重しない値を保存することは決してありません。 ## OpenRouter プロバイダーの固定 OpenRouter はルーターです — モデル（例：`moonshotai/kimi-k2`）をリクエストすると、複数の上流プロバイダー（Moonshot 直接、Together、Groq、Fireworks、Novita…）のいずれかに呼び出しを転送します。呼び出しごとに異なるバックエンドに着地する可能性があります。便利ではありますが、サイレントな変動を招きます： * **品質ドリフト** — 上流は異なる精度（FP8、INT4、full）で動作し、同じプロンプトに対して微妙に異なる出力を返します * **ツール呼び出しの不整合** — 一部のバックエンドは関数呼び出しを同じ方法でサポートせず、不正な tool use を引き起こします * **Reasoning フォーマットの変動** — ある上流は `reasoning_effort` を尊重し、別の上流は `thinking.enabled` のみ、また別の上流は両方を無視します * **レイテンシの揺れ** — ルーティングが変わると p50 が 800ms から 4s に跳ね上がることがあります * **レート制限の意外な発生** — 明示的に選んでいないバックエンドでクォータにヒットします ### 固定する方法 BYOK プロバイダーが **OpenRouter** の場合、Advanced settings パネルに2つのフィールドを持つ **OpenRouter routing** セクションが表示されます： * **Pin providers (in order)** — 上流名のカンマ区切りリスト（例：`moonshot, together`）。OpenRouter は順番に試し、最初に利用可能なものを使用します。 * **Allow fallbacks** — オフの場合、固定されたプロバイダーのいずれも利用できないとリクエストはハードフェイルします。オン（デフォルト）の場合、OpenRouter はそのモデルを提供する他の任意の上流にフォールバックできます。 **安定した**構成のためには、単一のプロバイダーを固定し、フォールバックをオフにします（`Pin: moonshot`、`Allow fallbacks: off`）。リクエストは常に同じ上流に到達するか、明示的に失敗します — サイレントな品質変動はありません。トレードオフは、その1つの上流がダウンした場合に回復力がゼロになることです。障害を吸収するために、異なる Routing Fallback（例：Anthropic）と組み合わせてください。 上流名は OpenRouter のカタログと一致している必要があります。プロバイダータグを [openrouter.ai/docs/features/provider-routing](https://openrouter.ai/docs/features/provider-routing) で確認してください — 一般的な値には `moonshot`、`together`、`groq`、`fireworks`、`novita` が含まれます。 内部的に、Kodus は Vercel AI SDK 呼び出しに次のように出力します： ```json theme={null} { "openrouter": { "provider": { "order": ["moonshot", "together"], "allow_fallbacks": false } } } ``` ### 上級者向け：生の JSON オーバーライド `order` と `allow_fallbacks` 以外のフィールド（例：`ignore`、`data_collection`、`require_parameters`）が必要な場合は、Advanced settings で **Thinking** を **Custom** に切り替え、完全なルーティングペイロードを貼り付けます — 任意の reasoning 設定と並んで `providerOptions` にマージされます： ```json theme={null} { "openrouter": { "provider": { "order": ["moonshot"], "allow_fallbacks": false, "ignore": ["deepinfra"], "data_collection": "deny" }, "reasoning": { "effort": "medium" } } } ``` ## 同時実行数とレート制限 `maxConcurrentRequests` フィールド（**Advanced settings** の下）は、Kodus がプロバイダーに並行して送信するインフライトリクエストの数を制限します。ほとんどの場合、デフォルトで問題ありません — ただし、厳密な同時実行上限があるサブスクリプションプランでは明示的に設定する必要があります。 ### 設定する値 | プロバイダー / プラン | 値 | 理由 | | -------------------------------------------- | ------- | --------------------------------------------- | | **GLM Coding Plan (Lite/Pro)** | `1` | サブスクリプションは1つのインフライトリクエストのみ許可。それ以上は 429 をトリガー。 | | **GLM Coding Plan (Max)** | 最大 `30` | Max は最大 30 の同時実行を許可 — フル予算を使うにはここで引き上げてください。 | | **Kimi Code Plan** | `30` | Moonshot のコーディングエンドポイントで文書化された上限。 | | **GLM Developer API** | *(空)* | 制限はキーごとにスケール；適切なグローバルデフォルトはありません。 | | **Kimi Developer API** | *(空)* | リチャージティアとスケール（Tier 1 ≈ 50、Tier 5 ≈ 1000）。 | | **Anthropic / OpenAI / Google / OpenRouter** | *(空)* | プロバイダーは独自の TPM/RPM を適用；Kodus は制限しません。 | ### チューニングのタイミング * Moonshot/OpenRouter で高ティアのリチャージがあり、大きな PR でより高いスループットが欲しい * GLM Coding Plan を **Max** に上げ、30-concurrent の予算をフル活用したい * マルチファイル PR でレビューがシリアル化されていると感じ、429 が発生していない * レビューログに `429` や `Too much concurrency` エラーが見られる * プロバイダーがダッシュボードでレート制限について警告している * より多くの PR にわたって Coding Plan のウィンドウ（5時間/週次）を節約したい **同時実行数 vs. RPM vs. TPM。** `maxConcurrentRequests` は並行するインフライトリクエストのみを制限します。多くのプロバイダーは、別の **RPM**（1分あたりのリクエスト数）や **TPM**（1分あたりのトークン数）制限も適用します。同時実行数は問題ないのに RPM/TPM にヒットしている場合、通常の対処法はティアをアップグレードするか、時間をかけて負荷を分散することです — `maxConcurrentRequests` を変更することではありません。 **フォールバックとの相互作用。** タスクのモデルが 429 にヒットし、Kody が Routing Fallback にフェイルオーバーするとき、フォールバック自身の `maxConcurrentRequests` が適用されます。異なるプロバイダーに寛大なフォールバックを設定することは、メインのモデルがタイトなサブスクリプション上にある場合にバーストを吸収する良い方法です。 ## ベストプラクティス ### セキュリティ Kodus 用の別の APIキーを作成します。使用状況の監査とキーのローテーションが容易になります。 定期的にキーをローテーションし、BYOK 設定で更新します。 異常なパターンがないか、プロバイダーのダッシュボードを確認します。 キーをリポジトリにコミットしないでください。Kodus は保存時および転送時に暗号化して保存します。 ### ルーティング戦略 * デフォルトとフォールバックには**異なるプロバイダー**を使用します（例：Anthropic デフォルト、Google フォールバック）。プロバイダー固有の障害から保護します。 * 厳しい同時実行制限のあるサブスクリプション（GLM Coding Plan Lite/Pro、Kimi Code Plan）は単独の構成としては適していません — バースト的な PR が枯渇しないよう、ペイパートークンのフォールバックとペアにします。 * 重いタスク（深いコードレビュー）を最も強力なモデルに、軽いタスク（要約、チャット）を安価なモデルに **Per agent** でルーティングします。 ## トラブルシューティング * 余分なスペース、引用符、末尾の改行なしでキーをコピーします。 * 請求が有効になっており、アカウントにクレジットがあることを確認します。 * GLM Coding Plan / Kimi Code Plan のキーについては、**base URL** がプランと一致していることを確認してください — サブスクリプションキーは Developer API エンドポイントでは動作せず、その逆も同様です。 * チャットプローブのプロバイダー（Anthropic-compatible、OpenAI-compatible、Novita）では、Test はモデルに実際のリクエストを送信するため、誤った、またはスペルミスのモデル ID はここで失敗します — これは想定された動作であり、レビュー時に失敗するよりも優れています。 * プロバイダーのダッシュボードから正確なモデル ID をコピーしてください。一部のプロバイダーはディープパス（例：Fireworks `accounts/fireworks/models/kimi-k2p7-code`）を使用したり、バージョンの綴りが異なったり（`k2p7` 対 `k2.7`）します。 * ベース URL がプロバイダーと正確に一致していることを確認します（一部では末尾のスラッシュが重要です）。 * OpenAI 互換プロバイダーの場合、エンドポイントは通常 `{baseURL}/chat/completions` です（Kodus がパスを追加します）。 * 一部のモデルは temperature を固定したり常に reasoning したりします（Kimi `k2p7-code`/`k3`、GLM-5.3；Claude 4.7+/GPT-5 は temperature を完全に廃止）。Test はチューニングをモデルのルールに対して検証し、具体的なメッセージを返します — それに従ってください（temperature を未設定のままにするか、必要な値を使用し、常に reasoning するモデルで reasoning を Off にしないでください）。[Temperature](#temperature) を参照してください。 * Advanced settings で **Max concurrent requests** を下げます。 * GLM Coding Plan Lite/Pro では **1 concurrent** を維持します。より高いスループットが必要な場合は Max（30 concurrent）にアップグレードしてください。 * Kimi Code Plan では文書化された上限は **30 concurrent** です。 * Kodus が `.env`（セルフホスト Fixed Mode）で設定されている場合、BYOK 画面はアクティブなプロバイダー/モデルを表示する青い情報バナーを表示します — セキュリティのためキーは決して表示されません。 * モデルを接続して保存すると、`.env` の設定がオーバーライドされます。 * Reasoning はトークンを追加します。コストが急増している場合、**Thinking** を Medium から Low に下げるか、重いタスクを **Per agent** で安価なモデルにルーティングしてください。 * プロバイダーのダッシュボードでモデルごとの内訳を確認し、**Budget** タブで上限を設定します。 ## よくある質問 はい。変更は次のレビューに有効になります — 再デプロイは不要です。 フォールバックが設定されている場合、レビューは自動的に Routing Fallback に切り替わります。フォールバックがない場合、レビューは失敗してエラーを返します。常にフォールバックを設定してください。 すべてのタスクは、Routing でエージェントごとにオーバーライドしない限り、デフォルトモデルを使用します。タスクのモデルが失敗した場合（レート制限、5xx、タイムアウト、無効なキー）、Kody はフォールバックで一度再試行します。実際に呼び出しを処理したプロバイダーに対してのみ支払います。 はい — それが **Routing → Per agent** の目的です。深いコードレビューを強力なモデルに、要約やチャットを安価なモデルにルーティングします。ルーティングを意味のあるものにするには、少なくとも2つのモデルを接続する必要があります。 はい。キーは保存時および転送時に暗号化され、平文でログに記録されることはありません。BYOK ステータスエンドポイントは生のキーを返しません。 はい — **OpenAI Compatible** プロバイダー（Custom の下）を介して使用できます。エンドポイントのベース URL、公開しているモデル ID、およびプレースホルダーの APIキーを入力します（ほとんどのセルフホストランタイムはキーヘッダーを無視しますが、依然として必要です）。