Mac Studioで挑むAI自律開発：Kimi K2.7 Codeが叩き出した驚異の成果と限界

深夜のデバッグ作業中、ふと「このコード修正をAIに丸投げできたらどれほど楽か」と考えたことはないだろうか。今回、エンジニアのhellohazime氏が実践した実験は、まさにその究極系とも言えるものだ。Apple M3 Ultra（メモリ512GB）を搭載したMac Studio 1台という、我々エンジニアのデスクにも置ける環境で、Moonshot AIの「Kimi K2.7 Code」を走らせ、フリーランスのソフトウェアエンジニア向けプラットフォーム「SWE-Lancer」のタスクを解かせたという事実は、AIの民主化が単なるバズワードではないことを証明している。

使用されたモデルは、Unslothで2bit量子化（UD-Q2_K_XL）された約341GBの巨大なウェイトだ。2bitという極限まで圧縮されたモデルが、果たして実用的なコード生成能力を維持できるのか。この問いに対し、同氏は13日間（308時間34分）という長丁場をかけて198タスクを完走させた。結果として、獲得報酬は69,875ドルに達した。これは、2025年2月時点の論文でClaude 3.5 Sonnetが記録したIC SWE（Diamond）の正解率26.2%を大きく上回る、47.0%という驚異的な数字である。我々が普段、クラウドのAPI課金に頭を悩ませている間に、ローカル環境のAIがこれほどのパフォーマンスを叩き出しているという事実は、インフラエンジニアやAI開発者にとって無視できないパラダイムシフトの予兆と言えるだろう。

しかし、この成功の裏には、泥臭いエンジニアリングの苦闘がある。デフォルトのソルバーでは全く歯が立たず、正解率はわずか3.85%に留まった。原因は、Kimiがツール呼び出しの作法を学習しすぎており、標準的なコードブロックの記述ではなく、存在しない関数を延々と呼び出そうとする「AI特有の癖」にあった。これを解決するために、同氏はOpenAI互換の関数ツールを定義し、モデルの出力からPythonコードを抽出する「ToolAwareAgentSolver」を自作した。この「モデルの特性に合わせてソルバーを書き換える」という泥臭い実装こそが、AIを実務で使いこなすための唯一の正攻法であることを、この実験は如実に物語っている。

今回の実験で得られたデータは、現在のLLMが抱える「高難易度タスクへの適応力」という課題を浮き彫りにしている。報酬額帯別の正解率を見ると、500ドル未満の案件では44%の正解率を誇るが、4,000ドル以上の高単価案件になると38%まで低下する。特に最も高額な32,000ドルの案件を落とした事実は、AIが複雑な依存関係や大規模なリファクタリングを伴うタスクにおいて、依然として「壁」に直面していることを示唆している。以下の表は、今回の実験における報酬額帯別のパフォーマンスをまとめたものだ。

さらに、この47.0%という数字には「人為的な制限」というバイアスがかかっている。同氏は、1タスクあたりの応答に900秒のタイムアウト制限を設けており、198タスク中109タスクでこの制限が発動した。もしこの制限がなければ、さらに高い正解率を記録していた可能性は高い。一方で、GLM-5.2（754B）を用いた検証では、1タスクに8時間前後を要し、全タスク完走に61日かかるという計算結果から断念せざるを得なかった。この「モデルの巨大化と推論速度のトレードオフ」は、我々がオンプレミスやエッジでAIを運用する際に直面する、最も現実的かつ残酷な制約である。

我々エンジニアは、モデルのパラメータ数やベンチマークスコアという「カタログスペック」に踊らされがちだが、真に重要なのは「限られた計算リソースの中で、いかにソルバーを最適化し、AIの思考を実務に落とし込むか」という実装力である。Dockerコンテナの競合や、llama-serverのキャッシュ効率といったインフラレベルのトラブルと戦いながら、泥臭く数値を積み上げる。このプロセスこそが、AI時代におけるエンジニアの新たな付加価値となるのではないだろうか。

今回の検証を通じて、我々は「AIが自律的にコードを書き、報酬を得る」という未来の断片を目の当たりにした。しかし、この成果を単なる「AIの進化」として片付けてはならない。重要なのは、この実験が「既存のソルバーでは動かない」という前提からスタートし、エンジニアが自らの手でツールを再構築した点にある。AIは魔法の杖ではなく、あくまで強力なエンジンに過ぎない。そのエンジンをどのシャーシに載せ、どのような燃料（プロンプトやソルバー）で動かすか。その設計図を描くのは、依然として我々人間のエンジニアである。

読者諸君に問いかけたい。もし明日、あなたの業務の半分をAIが代替できるようになったとして、あなたは「AIを使いこなす側」に回る準備ができているだろうか。単にAPIを叩くだけのエンジニアは、AIの進化とともにその価値を急速に失うだろう。しかし、今回のように「モデルの癖を理解し、ソルバーをハックし、インフラの制約を突破する」という泥臭いエンジニアリングができる人間は、AIを最強の武器として使いこなすことができるはずだ。AIの進化を恐れるのではなく、AIが苦手とする「文脈の理解」や「システム全体の最適化」という領域に、我々のリソースを集中させるべきではないか。

明日から取るべき実践的な処方箋として、まずは自身の業務フローを「AIが実行可能なタスク」に分解することから始めてほしい。そして、AIが失敗した際に「モデルが悪い」と切り捨てるのではなく、なぜ失敗したのか、どのようなツール呼び出しの作法が足りなかったのかをログから読み解く「AIデバッグ」のスキルを磨くことだ。AIは、我々が書くコードの質を問うているのではない。我々が「何を解決したいのか」という問いの解像度を問うているのだ。この技術的転換期において、あなたはAIを「同僚」として迎え入れるのか、それとも「代替される対象」として座して待つのか。その答えは、日々の実装の中にしかない。