Skip to main content

概要

本ドキュメントでは、既存の OpenRouter 実装をモデルとして、「Kilo Gateway」を OpenClaw の標準(ファーストクラス)プロバイダーとして統合するための設計案をまとめます。Kilo Gateway は OpenAI 互換の Completions API を使用しますが、ベース URL が異なります。

設計上の決定事項

1. プロバイダーの名称

推奨: kilocode 根拠:
  • 提示されたユーザー構成例(kilocode プロバイダーキー)と一致します。
  • 既存のプロバイダー命名パターン(openrouter, opencode, moonshot など)と一貫性があります。
  • 短く、覚えやすい名称です。
  • 一般的な「kilo」や「gateway」という単語との混同を避けることができます。
検討された代替案: kilo-gateway。コードベースではハイフン付きの名称はあまり一般的ではなく、kilocode の方が簡潔であるため不採用としました。

2. デフォルトモデルの参照

推奨: kilocode/anthropic/claude-opus-4.6 根拠:
  • ユーザーの構成例に基づいています。
  • Claude Opus 4.5 はメインモデルとして十分な能力を持っています。
  • 明示的なモデル選択を行うことで、自動ルーティングへの依存を回避します。

3. ベース URL の設定

推奨: ハードコードされたデフォルト値と、構成による上書きの併用
  • デフォルトのベース URL: https://api.kilo.ai/api/gateway/
  • 上書き可能: はい。models.providers.kilocode.baseUrl 経由で設定できます。
これは Moonshot, Venice, Synthetic などの他のプロバイダーで使用されているパターンと同様です。

4. モデルスキャン

推奨: 初期段階では専用のモデルスキャンエンドポイントは設けない 根拠:
  • Kilo Gateway は OpenRouter へのプロキシであり、モデルは動的に変化します。
  • ユーザーは構成ファイルでモデルを手動設定できます。
  • 将来的に Kilo Gateway が /models エンドポイントを公開した際に、スキャン機能を追加することを検討します。

5. 特殊なハンドリング

推奨: Anthropic モデルにおいて OpenRouter と同様の挙動を継承する Kilo Gateway は OpenRouter へのプロキシであるため、同様の特殊処理を適用すべきです:
  • anthropic/* モデルに対するキャッシュ TTL 適格性の判定。
  • anthropic/* モデルに対する追加パラメータ (cacheControlTtl) の付与。
  • Conversation 記録(トランスクリプト)のポリシー。

修正対象ファイル

コア認証情報管理

1. src/commands/onboard-auth.credentials.ts

以下の追加を行います:

2. src/agents/model-auth.ts

resolveEnvApiKey() 内の envMap に追加します:

3. src/config/io.ts

SHELL_ENV_EXPECTED_KEYS に追加します:

構成設定の適用

4. src/commands/onboard-auth.config-core.ts

新しい関数を追加します:

認証選択システム

5. src/commands/onboard-types.ts

AuthChoice 型に追加します:
OnboardOptions に追加します:

6. src/commands/auth-choice-options.ts

AuthChoiceGroupId に追加します:
AUTH_CHOICE_GROUP_DEFS に追加します:
buildAuthChoiceOptions() 内に追加します:

7. src/commands/auth-choice.preferred-provider.ts

マッピングを追加します:

認証選択の適用

8. src/commands/auth-choice.apply.api-providers.ts

インポートを追加します:
kilocode-api-key の処理を追加します:
また、関数の冒頭で tokenProvider のマッピングを追加します:

CLI 登録

9. src/cli/program/register.onboard.ts

CLI オプションを追加します:
アクションハンドラーに追加します:
auth-choice のヘルプテキストを更新します:

非対話型オンボーディング

10. src/commands/onboard-non-interactive/local/auth-choice.ts

kilocode-api-key の処理を追加します:

エクスポートの更新

11. src/commands/onboard-auth.ts

エクスポートを追加します:

特殊なハンドリング (任意)

12. src/agents/pi-embedded-runner/cache-ttl.ts

Anthropic モデル用の Kilo Gateway サポートを追加します:

13. src/agents/transcript-policy.ts

Kilo Gateway 用の処理を追加します(OpenRouter と同様):

構成の構造

ユーザー構成例 (openclaw.json)

認証プロファイル構造 (auth-profiles.json)

テストの考慮事項

  1. ユニットテスト:
    • setKilocodeApiKey() が正しいプロファイルを書き込むこと。
    • applyKilocodeConfig() が正しいデフォルト値を設定すること。
    • resolveEnvApiKey("kilocode") が正しい環境変数を返すこと。
  2. 統合テスト:
    • --auth-choice kilocode-api-key を使用したオンボーディングフロー。
    • --kilocode-api-key を使用した非対話型オンボーディング。
    • kilocode/ 接頭辞を使用したモデル選択。
  3. E2E テスト:
    • Kilo Gateway 経由での実際の API 呼び出し(ライブテスト)。

移行に関する注意

  • 既存ユーザーへの影響はありません。
  • 新規ユーザーはすぐに kilocode-api-key を認証方法として選択できます。
  • 既存の kilocode プロバイダーの手動構成も引き続き動作します。

将来的な展望

  1. モデルカタログ: Kilo Gateway が /models エンドポイントを公開した場合、scanOpenRouterModels() のようなスキャン機能を追加します。
  2. OAuth 対応: Kilo Gateway が OAuth を導入した際、認証システムを拡張します。
  3. レート制限: 必要に応じて、Kilo Gateway 固有のレート制限ハンドリングを追加します。
  4. ドキュメント: docs/providers/kilocode.md を作成し、セットアップと使用方法を説明します。

変更サマリー