Claude Code × Kimi K2.5 ハイブリッド環境を構築した ── Opus が設計し、K2.5 が実装する開発フロー

Claude Code (Opus 4.6) は Claude ファミリーの最上位モデルで、複雑な設計判断に向いています。しかしトークン単価の高さが悩みどころです。定型的な実装タスクにも Opus を使うのはもったいない。

そこで目をつけたのが、Moonshot AI の Kimi K2.5 です。

Kimi K2.5 という選択肢

Kimi K2.5 は 2026年1月に公開された1兆パラメータの MoE モデルです。CLI ベースのコーディングエージェント「Kimi Code」として動作し、Claude Code と同じくターミナル上でファイル編集・コマンド実行・テストを自律的にこなします。

単体性能だけでも注目に値します。

ベンチマーク	Kimi K2.5	Claude Opus 4.5	GPT-5.2
SWE-Bench Verified	76.8%	80.9%	80.0%
AIME 2025	96.1%	92.8%	—
LiveCodeBench v6	85.0%	—	—

SWE-Bench で Opus に迫り、数学推論では上回る。Moderato プラン（執筆時点で $19/月、2048リクエスト/週）でこの性能が使えるのはコスパとして優秀です。

しかし Kimi K2.5 の真の差別化ポイントはベンチマークスコアではありません。Agent Swarm です。

Agent Swarm——群知能という発想

Agent Swarm は、最大100体のサブエージェントを同時起動し、最大1,500回のツール呼出を並列実行するアーキテクチャです。内部にオーケストレーターがいて、タスクを並列化可能なサブタスクに分解し、専門化したエージェント（AI Researcher、Fact Checker 等）に振り分けます。

BrowseComp では通常モードの 60.6% が Agent Swarm で 78.4% に跳ね上がり、実行時間は最大 4.5倍短縮されます。「そこそこ賢いモデルの群れは、1体の非常に賢いモデルより実務タスクの遂行能力が高い」——これが Moonshot AI の提唱する群知能の考え方です。

設計の着眼点: 群知能の強みと弱み

ベンチマークと Agent Swarm の仕組みを見て、ある仮説を立てました。

Kimi の強みは 並列実行力 です。spec で明確に指示されたタスクを多数のエージェントが一斉にこなす部分で真価を発揮します。一方、「何を作るか」「どう設計するか」というハイレベルな設計判断は、群知能の守備範囲ではありません。Kimi の内部オーケストレーターはタスク分解と並列化に最適化されており、アーキテクチャ設計やトレードオフの判断を担う「上位オーケストレーター」の役割は想定されていないはずです。

つまり Kimi は優秀なワーカーだが、オーケストレーターには向かない。ならば、Opus がオーケストレーター（設計・判断・レビュー）を担い、Kimi がワーカー（実装・テスト）を担う分業が自然な構成です。

ここでもうひとつ考えるべきことがあります。Kimi にどうやって指示を出すか、です。人間向けの plan（「auth モジュールを修正して」）をそのまま渡すと、Kimi は「どのファイル？」「完了条件は？」と探索に時間を使います。群知能の並列実行力を活かすには、具体的なファイルパス・検証コマンド・並列実行のヒントを含む、エージェント向けの構造化された仕様書が必要です。これを spec.md と呼ぶことにしました。

アーキテクチャ: オーケストレーター + ワーカー

この分析から、以下の構成を設計しました。Opus が plan を作成し、承認後に spec.md へ変換して Kimi に渡します。

ユーザー
  ↓ タスク依頼
Claude Code (Opus 4.6) ── オーケストレーター
  ├── plan 作成（設計判断）
  ├── Kimi 委任判断
  ├── plan → spec.md 変換
  ├── ディスパッチ
  └── レビュー
        ↓ spec.md
Kimi K2.5 ── ワーカー
  ├── spec に基づき実装（群知能の強みを活かす）
  ├── テスト実行
  └── 結果返却（隔離ブランチ上）

Opus の設計力と Kimi の実行力を組み合わせる構成です。Kimi の変更は必ず隔離ブランチ上で行い、Claude がレビューしてからマージする安全設計になっています。

最初の設計: 2ステップコマンド

最初に作ったのは2つのスラッシュコマンドでした。

/kimi-spec <タスク概要>    → spec.md を生成
/kimi-dispatch <spec-path> → Kimi に渡して実行

これはこれで動きます。ですが使ってみると コマンドを2つ覚える必要がある という認知負荷がありました。

転換点:「plan mode に統合できないか？」

Claude Code には plan mode があります（Shift+Tab または /plan で切り替え）。複雑なタスクでは plan を作成し、ユーザーが承認してから実装に入る仕組みです。このフローに乗せれば、ユーザーは新しいコマンドを覚える必要がありません。

通常フロー:
1. ユーザーがタスク依頼
2. Claude が plan 作成
3. ユーザーが承認 → Claude が実装

ハイブリッドフロー:
1. ユーザーがタスク依頼
2. Claude が plan 作成
3. ユーザーが承認時に選択:
   - 「Claude が実装」→ 通常通り
   - 「Kimi に委任」→ plan → spec 変換 → Kimi ディスパッチ

ユーザーにとっては「いつもの承認画面にもう1つ選択肢が増えた」だけです。認知負荷ゼロ。

spec.md は本当に必要か？——設計判断の議論

ここで一度立ち止まりました。plan mode に統合するなら、plan ファイルをそのまま Kimi に渡せばいいのでは？ わざわざ spec.md に変換するステップは、Opus のトークンを消費する無駄な中間工程ではないか？

実際、一度は「plan をそのまま渡せばいい」と撤回しかけました。ですが冷静に比較すると、両者の役割は明確に異なります。

	plan	spec.md
読者	人間 + Claude	Kimi（自律エージェント）
パス指定	「auth モジュールを修正」	MODIFY src/auth/handler.ts
完了定義	「テストが通ること」	pytest --cov=src で 80%+
並列ヒント	なし	[INDEPENDENT] タグ

plan と spec は読者が違います。 plan は人間が読んで判断するものであり、spec は自律エージェントが迷わず実行するための指示書です。

Kimi K2.5 は十分賢いので曖昧な指示でも動きます。ですが Moderato プランの 2048リクエスト/週 という制約下では、Kimi が「どのファイルだろう？」と探し回るステップの浪費は大きいです。

• Opus の変換コスト: 数千トークン（安い）
• Kimi のステップ節約: 10〜20ステップ/タスク（クォータ直撃）

spec 変換は クォータ節約への投資 です。結論として残すことにしました。

実装: Kimi にルールを作らせる

ハイブリッド環境の初実戦として、「plan mode 統合ルール」の作成を Kimi 自身に委任しました。

spec.md の内容

# Spec: 001 -- Kimi Plan Integration

## Tasks
### Task 1: Kimi 委任ルール作成 [INDEPENDENT]

Files to create:
- CREATE ~/.claude/rules/common/kimi-delegation.md

Requirements:
- When to Suggest（提案基準）
- When NOT to Suggest（禁止事項）
- Plan Approval Flow（承認フロー）
- Plan to Spec Conversion（変換手順）
- Quota Awareness（クォータ意識）

Verification:
- 5セクション存在確認
- kimi-wrapper.sh への参照確認

Kimi の実行結果

$ kimi --prompt "$(cat spec-001.md)" --thinking --yolo --max-steps-per-turn 100

実際には kimi-wrapper.sh がモデル指定や作業ディレクトリの付与も行いますが、本質的なオプションは上記の通りです。

初回ディスパッチの結果は約10秒。6ステップ。 既存ルールファイル3つを読み → フォーマットを把握 → 119行のルールファイルを生成 → 検証パス。

spec で具体的なパス・セクション構造・検証コマンドまで指定したので、Kimi が「何を作るか」で一切迷いませんでした。

生成されたルールの品質

# Kimi Delegation

## When to Suggest
- 単純な実装タスク — ボイラープレート、CRUD、定型パターン
- 複数ファイルの機械的変更 — リネーム、フォーマット統一
- ユーザーが明示的に Kimi を指定
...

## Quota Awareness
| 変更規模 | 推奨アプローチ |
|----------|---------------|
| 1-2ファイル、50行以下 | Claude 直接実装 |
| 3ファイル以上、100行以上 | Kimi 委任を積極提案 |

既存ルールのフォーマットと一貫しており、判断基準も具体的です。Opus のレビューでも修正なしでパスしました。

ファイル構成（全体像）

最終的に構築したハイブリッド環境のファイル一覧です。

~/.kimi/
├── config.toml          # Moderato プロファイル（max_steps=100）
├── config.swarm.toml    # Swarm バックアップ
└── credentials/         # OAuth 認証情報

~/.claude/
├── bin/
│   ├── kimi-wrapper.sh          # Claude → Kimi ディスパッチャー
│   └── kimi-profile-switch.sh   # Moderato ⇔ Swarm 切替
├── commands/
│   ├── kimi-spec.md             # spec 生成（手動用）
│   └── kimi-dispatch.md         # ディスパッチ & レビュー（手動用）
├── rules/common/
│   └── kimi-delegation.md       # plan mode 統合ルール ← Kimi が作成
└── templates/hybrid/
    └── spec-template.md         # spec テンプレート

Moderato プランの最適化設定

Kimi Moderato プラン（$19/月）の制約と、それに合わせた設定です。

設定	値	Why
max_steps_per_turn	100	ステップ数 = リクエスト消費量
tool_call_timeout_ms	120000	並列ツール呼出を活かすため維持
wrapper TIMEOUT	300s	100ステップなら300sで十分

Swarm プランにアップグレードした場合は kimi-profile-switch.sh swarm 一発で切り替えられます。

## 得られた知見

1. spec の精度 = クォータ効率

spec.md で具体的なパス、セクション構造、検証コマンドまで指定すると、Kimi の探索ステップが激減します。今回は6ステップで完走しました。曖昧な指示なら20〜30ステップは必要だったでしょう。

2. 既存ワークフローへの統合が鍵

新しいコマンドを覚えさせるより、既存の plan mode に乗せる方が導入障壁は圧倒的に低いです。ユーザーから見れば「承認画面の選択肢が1つ増えた」だけで、学習コストはほぼゼロです。

3. エージェント間の安全設計

Kimi の変更は必ず隔離ブランチ上で行います。マージは Claude レビュー後のみ。この安全設計があるから「とりあえず Kimi に投げる」が気軽にできます。

まとめ

初回ディスパッチは10秒・6ステップで成功しました。spec 変換というひと手間が、Kimi のクォータ効率を大幅に改善することも確認できました。

この構成の本質は「LLM 間で役割を分け、既存ワークフローの中にハンドオフを埋め込む」ことです。$19/月の Kimi Moderato と Claude Code の組み合わせで、個人開発でも十分実用的なマルチエージェント環境が作れます。

次のステップとしては、複数タスクの並列ディスパッチや、Kimi の実行結果を自動で PR にする仕組みを試してみたいと考えています。