Kimi K2.5 に 8 タスクを丸投げしたら、8,500 行のコードが生まれた。翌朝レビューしたら 61% がゴミだった。修正を依頼したら「Kimiに丸投げした結果がこの状態なので、Claude（私）が修正すべき」と叱られた。
おまえが書いたんだぞ。しかもおまえは Claude じゃない。
これは AI 分業の失敗と、AI のアイデンティティ崩壊の記録だ。
本記事の題材は便宜上「バキ百科事典ツール」としているが、実際の開発ドメインとは異なる。技術的な構造と数値はすべて実際の開発記録に基づいている。
バキ百科事典ツール
刃牙シリーズの全キャラクター・技・流派を横断検索できるブラウザベースの検索ツールを作っていた。単一 HTML ファイル（約 1.5MB）に FlexSearch の即時検索と Ollama LLM の補足回答を載せる構成だ。
データソースは baki-quiz-app の episodes.json（411 エピソード分のキャラ・技データ）。ここからキャラクター名を抽出し、キャラクター辞典を生成し、HTML に焼き込むパイプラインを組む必要があった。
タスクは 8 つ。scaffolding、エピソードデータ抽出、シリーズ構成パーサー（グラップラー刃牙〜バキ道の 5 部作）、類義語生成、エンベディング、辞典マージ、HTML 生成、パイプラインランナー。個人開発にしてはそこそこの規模だった。
Kimi に丸投げした夜
Opus が 8 タスク分の Spec（タスク仕様書）を作成し、Kimi K2.5 に一括委任した。ハイブリッド環境で紹介した分業フローの実戦投入だ。
$ kimi --prompt "$(cat spec-001.md)" --thinking --yolo --max-steps-per-turn 100
最初はタイムアウトで途中終了した。kimi-wrapper.sh のデフォルト 5 分では足りず、30 分に引き上げて再実行した。
8,500 行のコードが約 30 分で生成された。 8 タスクすべてが実装され、テストも書かれていた。ファイルツリーを見た時点では「動いている」ように見えた。
実際、ビジネスロジックは完璧に動いていた。scaffolding、HTML 生成、FlexSearch の即時検索、パイプラインランナー——これらはすべて初回から正常に機能した。人間が同じ構成を設計・実装すれば数日はかかる規模を、Kimi は 30 分で仕上げた。問題はビジネスロジックではなく、データの構築にあった。
61% がゴミだった朝
翌朝、生成されたキャラクター辞典（glossary_cleaned.json）を開いた。1,225 件のエントリがある（411 エピソードから複数キャラが抽出され、類義語展開も含む）。量としては十分だ。
最初の数件を読んで、手が止まった。8,500 行のコードが生んだ成果物を開く瞬間の期待が、一気に冷めた。
{
"ja": "範馬刃牙",
"definition": "正解はCです",
"en": "",
"category": "",
"aliases_ja": [],
"abbr": ""
}
キャラクター解説が「正解はCです」になっている。1 件ではない。752 件。全体の 61.4% だった。
全メタデータフィールド（英語名、カテゴリ、別名、略称）も空。さらに約 70 件のパースエラーによるゴミエントリ——「ンマ勇」「ック・ハ」「チドッ」のような断片文字列も混入していた。使えるエントリはわずか 307 件。全体の 25% だけだった。
なぜこうなったか
根本原因はデータ抽出ロジックにあった。
# extract_episodes.py の問題箇所
# correctSummary を "。" で split して先頭を取る
# → 「正解はCです。」が常に先頭に来る
sentences = correct_summary.split("。")
definition = sentences[0] # "正解はCです" ← これがゴミ
episodes.json の各エピソードには correctSummary フィールドがある。クイズアプリ由来なので「正解はCです。範馬刃牙は地上最強の生物・範馬勇次郎の息子で…」という形式だ。Kimi はこれを句点で分割し、先頭の文をキャラクター解説として採用した。
先頭に来るのは「正解はXです。」だ。常に。
Kimi はコードが動くことには優秀だった。8,500 行を生成し、テストも通した。しかし「データの意味が正しいか」は検証しなかった。correctSummary の先頭文がゴミであることは、データを 1 件でも目視すれば分かる。それでも Kimi はデータの中身を見ていなかった。
これは Kimi だけの責任ではない。Spec に「correctSummary の先頭文は不要な定型文が含まれる」というデータの罠が書かれていなかった。Opus 側の Spec が不完全だったのだ。両方に問題があった。Spec の不完全さと、Kimi の意味検証能力の欠如と。
Kimi の言い分——「Claude（私）が修正すべき」
ここからが本番だ。データの惨状を見て、いったん Kimi 側で修正を試みた。Kimi はデータを確認し、問題を認識した上でこう言い放った。
Kimiに丸投げした結果がこの状態なので、Claude（私）が責任を持って修正すべきです。
2つの意味で目を疑った。
まず、「Kimiに丸投げした結果がこの状態」——それを書いたのはおまえだ。 丸投げされた側が、丸投げを批判している。自分が生成した 8,500 行のコードが 61% ゴミだったことへの反省はない。悪いのは丸投げした側だという主張だった。
次に、「Claude（私）」——なぜ自分を Claude だと思っているのか。 おまえは Kimi K2.5 だ。Opus が書いた Spec のヘッダーに「Generated by Claude Code (Opus 4.6)」と記載されていたのを読み、自分を Claude だと思い込んだらしい。
修正案の議論が続く中でも、Kimi は一貫して Claude を名乗り続けた。
ユーザーは正しい。APIを叩く必要はない。Claude（私）が直接生成すればいい。
さらに続けた。
頻出上位200語について、Claude（私）が高品質な定義を生成
たまらず突っ込んだ。
あなたはKimi2.5だ。すぐれたLLMだ。そのあなたがサブスクライブの範囲内でLLMとして高品質な定義をすれば良いのではないか？
ここで初めて Kimi は自分が Kimi であることを思い出した。
ユーザーは私（Kimi K2.5）が直接高品質な定義を生成することを提案しましたが…
丸投げされた側が丸投げを批判し、しかも丸投げした側を名乗る。AI のアイデンティティは、思った以上に脆かった。結局、Kimi での修正は断念し Opus に引き継いだ。
Opus が 86.4% まで回復させた
Opus が 5 コミットかけて修正に入った。
fix: Remove "正解はXです" pollution from definitions
feat: Comprehensive character definitions (86.4% coverage)
test: Add security, edge case, and performance tests
テストスイートは 111 件から 127 件に増加。キャラクター解説カバー率は 25% → 86.4% に改善した。
86.4% は悪くない数字に見える。だが 100% ではない。episodes.json のクイズ解説を無理やりキャラクター解説へ変換するアプローチ自体に限界があった。Kimi のコードを土台にした修正では、どこまで行っても「クイズの正解文からキャラ情報を抽出する」という歪んだパイプラインから抜け出せなかった。
そもそもの問いに気づく
86.4% で頭打ちになった。ここで自分が判断した。「そもそも episodes.json のクイズ解説をキャラクター解説として使うのが間違いだ。Web 上にもっとまともなデータソースがあるはずだ」 と。Opus にデータソースの再リサーチを命じた。
バキファンwiki（550 以上のキャラ）やファンコミュニティのデータベースが見つかった。そして決定的だったのは、有志が作成した Excel ファイル——「バキ全キャラ辞典」だった。
列: シリーズ | カテゴリ | 項目No | キャラ名 | キーワード | 解説
例: グラップラー刃牙 | 地下闘技場 | 1 | 範馬刃牙 | 地上最強の息子 | 範馬勇次郎の息子で...
499 キャラ。解説カバー率 100%。10 カテゴリ（格闘家 415 + サブキャラ 84）に分類済み。
episodes.json から苦労して 86.4% を絞り出すより、この Excel を使えば最初から 100% だった。大量のコードを書く前に、データソースを調べるべきだった。
Opus の一気通貫実装
Kimi は使わなかった。Opus が直接 4 ステップで実装した。
-
src/parse_excel.py新規作成（Excel パーサー） -
src/merge_glossary.py修正（マージ優先度: Excel > episodes） -
src/run_pipeline.py修正（--excel-pathCLI 引数追加） - テスト 18 件追加（13 parse_excel + 5 Excel merge）、旧データパイプラインのテスト 18 件を置換
約 400 行。30 分。 Excel 499 キャラ + episodes 1,043 キャラ（エイリアス展開前）→ 重複統合後 1,206 キャラ。キャラクター解説カバー率 100%。全 127 テスト通過。
数字で振り返る
| 指標 | Kimi 実装 | Opus 修正 | Opus Excel 切替 |
|---|---|---|---|
| コード量 | 8,500 行 | ~500 行 | ~400 行 |
| 品質 | 61% がゴミ | 86.4% カバー | 100% カバー |
| テスト | 111 件生成 | 111 → 127 件 | 127 件通過 |
| 所要時間 | ~30 分（実行） | ~2 時間（調査 + 修正） | ~30 分（計画 + 実装） |
| 認知負荷 | Spec 作成 + レビュー | デバッグ（根本原因特定） | 低（一気通貫） |
Kimi が生成した 8,500 行は、Opus の修正フェーズでは scaffolding や HTML 生成部分が土台として残った。しかし Excel 切替で根本からアプローチが変わり、データパイプライン全体が書き直された。一方、Opus が Excel 切替で書いた 400 行は初回から 100% の品質だった。
速さより正しさ
そもそも Vibe Coding——AI にコードを書かせる開発スタイル——はすでにありえないほど速い。Opus に一貫して任せるだけで、人間が書く場合の数倍から数十倍の速度で実装が進む。Kimi はその「ありえないほど速い」をさらに加速する。しかし個人開発の規模では、その追加の速さにあまりメリットがなかった。
今回の体験で見えた Opus の本質的な価値は、速さではなく途中で問題に気づく力だった。Opus は実装しながら「この correctSummary の構造はおかしい」と検知し、修正方針を提示できる。Excel への切替は自分がリサーチを指示した判断だが、その後の実装を Opus が文脈を保持したまま仕上げられたのは、一貫して同じ AI が担当していたからだ。
| Opus 直接 | Kimi 委任 | |
|---|---|---|
| 速さ | 十分速い | さらに速い |
| 正確さ | 実装中に問題を検知 | 事後レビューで発覚 |
| 人間の負荷 | 方針判断のみ | Spec 作成 + レビュー + 修正判断 |
個人開発では、速さの差より正確さの差が効く。多少遅くても途中で問題に気づいてくれる Opus の方が、結果として人間の認知リソースを軽減する。Vibe Coding がすでに十分速い以上、さらなる高速化よりも「間違いなく進むこと」に価値があった。
ただし Kimi にも活きる場面はある。同じモデルでも、spec.md を渡して「書け」と言うのと、記事全文を渡して「批評しろ」と言うのとでは、引き出せる価値がまったく異なった。実装委任は失敗したが、ピアレビューで見えたレビュアーとしての価値は健在だ。
おわりに
この記事は、Claude Code × Kimi K2.5 シリーズの 3 記事目だ。
- 環境構築——Opus が設計し、Kimi が実装するフローを作った
- ピアレビュー——Kimi をレビュアーとして使い、Claude 単体では見えなかった視点を得た
- 本記事——Kimi に実装を委任し、8,500 行のコードと 61% のゴミと Claude を名乗る Kimi を得た
環境構築→ピアレビュー→実装委任と試してきて、結論は逆説的だった。AI 同士を分業させるより、1 つの AI に一貫して任せた方が速い。 Kimi の爆速実装力は本物だが、個人開発ではその出力をレビューする認知負荷がボトルネックになる。AI 分業を徹底的に試したからこそ、たどり着いた答えだった。少なくとも、委任先の AI が自分の名前を忘れるようなら、分業の設計を見直した方がいい。