【ITニュース解説】I ran six coding agents on seven local models, 30 times each

システムエンジニアを目指す皆さんにとって、日々の開発作業を効率化する新しい技術は常に注目の的です。最近では、AIがプログラミングの様々なタスクを自動でこなす「コーディングエージェント」が進化を続けている。この記事は、これらのコーディングエージェントが実際にどれくらい使えるのか、特に皆さんの手元のコンピューター（ローカル環境）で動かすAIモデルと組み合わせたときに、どれほどの性能を発揮するのかを徹底的に検証した興味深いレポートだ。

検証の目的は、単に「AIでコードが書ける」というだけでなく、「特定の状況でどれだけ確実に、そして効率的に作業を完遂できるか」を明らかにすることにある。AIモデルをローカルで動かすことは、クラウドサービスに依存しないため、コストを抑えたり、セキュリティ上の理由から機密データを扱ったりする場合に非常に有効だ。しかし、ローカルモデルはクラウドで提供される大規模なモデルに比べて、その性能や特定の機能（例えば、外部ツールを呼び出す能力）が不安定なこともある。この検証では、そんなローカルモデルの「不安定さ」がコーディングエージェントの働きにどう影響するかを深く探っている。

この検証は非常に厳密な方法で行われた。まず、現在多くの開発者が利用している、性能の異なる7種類のローカルAIモデルが選ばれ、それぞれが「Ollama」というツールを通じて動かされた。Ollamaは、ローカル環境でAIモデルを簡単に実行するためのプラットフォームだ。次に、Polyglotを含む6種類の異なるコーディングエージェントが用意された。そして、各エージェントと各モデルの組み合わせについて、計30回もの試行が繰り返された。これは、単なる数回の試行では見えてこない、より信頼性の高い結果を得るためだ。結果は、26回以上の成功で「信頼性高く機能する」、12回から25回で「時々機能する」、12回未満で「失敗する」という3つのティアに事前に分類され、公平な評価が保証された。さらに、検証に使われたすべての環境設定、 rawデータ、失敗した実行のログまでGitHubで公開されており、誰でもその結果を検証し、再現できるようになっている。

結果を見ると、まず目を引くのは、Polyglotというエージェントが、検証された7種類のどのモデルにおいても「失敗」のティアに分類されなかった唯一のエージェントだったという点だ。これは、Polyglotが様々なモデルに対して高い安定性を持っていることを示唆している。特に「qwen2.5-coder」シリーズのような一部のモデルでは、他の多くのエージェントが全く機能しなくなる中で、Polyglotは「時々機能する」ティアに留まることができた。

では、なぜエージェント間でこのような差が生まれたのだろうか。検証の結果、その主な原因の一つが、AIモデルが外部ツール（ファイル操作など）を呼び出す際の「形式」にあることが判明した。多くのエージェントは、AIモデルが専用の「ネイティブチャネル」を通じてツール呼び出しの指示を出すことを想定している。しかし、Ollamaで動かす「qwen2.5-coder」シリーズのモデルは、このツール呼び出しの指示を、AIの返答として単なる「プレーンテキスト」として出力してしまう傾向があった。この場合、エージェントはモデルの返答全体を「最終的な回答」と誤解し、実際には何も処理せずにタスクを終了させてしまうのだ。

このような課題に対し、いくつかのエージェントは独自の解決策を講じている。例えば、Polyglotはモデルから出力されるプレーンテキスト形式のツール呼び出しを適切に解釈するための「パーサー」と呼ばれる機能を内部に持っている。このパーサーが、モデルの意図するツール呼び出しを正確に識別し、実行に移すことで、Polyglotは不安定なモデル環境でも比較的安定して機能することができた。また、「goose」というエージェントには「toolshim」という拡張機能があり、これはモデルが出力したプレーンテキストのツール呼び出しを、別の小さなAIモデルに渡して「正しい形式のツール呼び出し」に変換させることで、同様の課題を克服している。実際、「qwen2.5-coder 32B」モデルでは、このtoolshimを使ったgooseがPolyglotよりも高い成功率を記録している。

一方で、最新の高性能モデルである「Qwen3.8-27B」などでは、ほとんどすべてのエージェントが信頼性高く機能することがわかった。これらのモデルは、ネイティブチャネルを通じて正確なツール呼び出しを生成することに長けているため、エージェント間の性能差は小さくなり、むしろエージェントが「どのようにタスクを計画し、コードを編集するか」といった点に違いが現れるだけになる。

また、この検証ではエージェントがAIモデルに送る「プロンプト」のサイズも測定された。プロンプトとは、AIへの指示文のことだ。プロンプトが長ければ長いほど、AIが一度に処理できる情報の量（「コンテキスト」と呼ばれる）を多く消費し、結果としてAIの応答時間が長くなったり、使用する計算リソースが増えたりする可能性がある。Polyglotは比較的少ないトークン数（AIがテキストを処理する際の最小単位）のプロンプトでタスクを開始し、タスク全体でも効率的にトークンを消費していることが示された。これは、より少ないリソースで効率的に作業を進める上で重要な要素だ。

今回の検証では、過去の評価で犯した誤りも修正されている。前回のベンチマークでは、Ollamaのデフォルト設定（4,096トークンのコンテキスト）が短すぎたため、一部のエージェントがAIモデルに送る指示の途中で情報が途切れてしまい、本来の性能を発揮できていなかったという。今回の検証では、すべてのモデルが32,000トークンという十分なコンテキスト長で実行され、プロンプトが途中で切断されていないかどうかも厳密にチェックされた。これは、AIを活用するシステムを構築する上で、AIモデルがどれだけの情報を一度に処理できるか（コンテキスト長）を正しく理解し、設定することが非常に重要であることを示している。

このように、この検証はコーディングエージェントの現在の実力を客観的かつ厳密に評価したものだ。システムエンジニアを目指す皆さんにとって、このような情報は、将来的にAIツールを導入する際の重要な判断材料となる。AIエージェントは進化の途上にあり、モデルの特性やエージェントの実装方法によって、その性能は大きく左右されることを理解し、利用する目的や環境に合わせて最適なツールを見極める力が、これからのシステムエンジニアには求められるだろう。