テストが全部通って初めて褒められるAI ―― Kimi-Dev に学ぶ「コードを直すモデル」の作り方

AIにコードを書かせる、という話はもう珍しくありません。でも「既存のリポジトリのバグを、人間のエンジニアと同じように直す」となると、話は急に難しくなります。新規にきれいなコードを書くのと、他人が書いた巨大なコードベースの中から原因を特定して、壊さずに修正するのは、まったく別の能力だからです。

中国の Moonshot AI（月之暗面）がオープンソースで出している Kimi-Dev は、まさにこの「issue を解決する（バグを直す）」ことに特化したコーディング専用 LLM です。日本のエンジニアにとっても、ライセンス的に自分で動かせて、しかも何が効いているのかを学べる、良い教材だと思うので、技術の中身を中心に紹介します。

まず、何がどれくらいできるのか

Kimi-Dev の代表モデル Kimi-Dev-72B（720億パラメータ）は、SWE-bench Verified で 60.4% を記録し、リリース時点でオープンソースモデルの中ではトップ（新SOTA）になりました。

SWE-bench というベンチマークが、ここでの肝です。これは、GitHub 上の実在するプロジェクトの、実在する issue（バグ報告や機能要望）を集めたもので、モデルには「このリポジトリの、この問題を直せ」という現実そのままのタスクが与えられます。Verified はその中でも人間が検証して質を担保したサブセットです。つまり 60.4% という数字は、「クイズに正解した率」ではなく、「本物のバグを、本物のコードベースで、実際に直せた率」に近い。だから重い。

モデルとコード、重みは GitHub（MoonshotAI/Kimi-Dev）と Hugging Face で公開されていて、後継の Kimi-Dev 2.0 も「AIネイティブ時代の、より汎用的なコーディング LLM」として出ています。

本当に面白いのは「どうやって鍛えたか」

私がこのモデルで一番紹介したいのは、ベンチマークの数字そのものより、訓練のやり方です。ここに、最近のコーディングAIの考え方の転換が、きれいに表れているからです。

Kimi-Dev は、大規模な強化学習（RL）で鍛えられています。普通の「お手本のコードを真似させる（教師あり学習）」とは、発想が違います。

仕組みはこうです。モデルは、Docker コンテナの中で、実際のリポジトリに自分でパッチ（修正）を当てに行きます。 そして ―― ここが核心です ―― そのリポジトリのテストスイートが「全部」通って初めて、報酬がもらえる。 一個でもテストが落ちたら、ご褒美はゼロ。

この設計が効いている理由を、少し噛み砕きます。

人間のコードレビューを思い出してください。「それっぽい修正」は、いくらでも書けます。コンパイルは通る、見た目も正しそう。でも実際に走らせると、別のテストを壊している ―― これが現場で一番たちの悪いバグです。従来のやり方だと、AIはこの「それっぽいが実は壊れている」修正を量産しがちでした。お手本に字面が似ているほど褒められるからです。

Kimi-Dev の「全テスト通過でのみ報酬」は、この逃げ道を塞ぎます。字面が似ていても、テストが落ちれば報酬ゼロ。評価の基準が「お手本との類似」ではなく「現実に動くか」になっている。 だからモデルは、人間のエンジニアが守っている基準 ―― 「直したつもりが別のところを壊していないか」 ―― を、いやでも学ばざるを得ない。

賢さを「正解への近さ」で測るのをやめて、「テストが通るか＝現実で動くか」で測る。地味ですが、これはコーディングAIの訓練思想として、かなり筋が良い割り切りだと思います。

「モデル」と「道具」は分けて見る

ここで一つ、整理しておきたい区別があります。Moonshot の周辺には名前の似たものが複数あって、混乱しやすいからです。

• Kimi-Dev：今回の主役。バグ修正に特化したコーディング”モデル”（重みが公開されている）。
• Kimi Code / Kimi CLI：それを使うためのターミナル”ツール”。0.4.0 では起動を速くするため Python から Rust に書き換えられた、と報じられています（このあたりの実装言語の話は情報が交錯しているので、使う前に公式で確認推奨）。

つまり「賢い頭脳（Kimi-Dev というモデル）」と「それを手元で動かす道具（Kimi CLI）」は別物です。日本のエンジニアが評価すべきは前者の中身 ―― オープンに使えて、SWE-bench で実証された、バグ修正特化のモデルが存在する、という事実のほうです。

個人的な見方

日本でもAIにコード書かせるのは当たり前になってきた。ただ、「新しく書く」のと「直す」のは全然別の能力なんですよね。

多くの注目は「ゼロから書く」能力に向かいがちですが、実際のソフトウェア開発で時間を食うのは、たいてい既存コードの保守と修正のほうです。Kimi-Dev は、そのいちばん泥臭くて価値のある部分を、オープンソースで、しかも「テストが通って初めて報酬」という現実主義的な訓練で攻めてきた。ベンチで派手な数字を出すより、「テスト通らなきゃ報酬ゼロ」で地道に鍛える。この泥臭さが、個人的にはけっこう好きです。

で、重みが公開されてる。自分のリポジトリで走らせられる。中身も覗ける。私がもし日本のチームにいたら、まず一回、自社の厄介なバグで試してみると思います。

（SWE-bench スコアやモデル構成は Moonshot の公開情報・各種報道ベースです。Kimi-Dev 2.0 の詳細数値や Kimi CLI の実装言語など、一部は情報が交錯しているため、利用前に公式リポジトリで確認することをお勧めします。）

―― AI未来編集室「AIウォッチ」