ローカルCoding Agentの検証記録

クラウドのAPIを使い続けるとトークン代が気になり始める。そこで浮かぶのがローカルLLMの誘惑だ。Qwenなどのモデルをローカルマシンで動かせば、単価ゼロで何度も実行できるはず。ところが実際にやってみると、コスト削減というより別の問題が浮き上がる。待ち時間、再試行、エージェントの迷走。この方程式は、単純な足し算にはならない。

ローカルLLMでCodingエージェントを実装したとき、複雑なUIは驚くほど正確に作れた。ヘッダー、サイドバー、プレイヤー、Like機能まで。ところが完成直前の単純な404に1時間引っかかった。Agentは試行錯誤を何度も実行できるのに、本当に必要な診断——実際にどのディレクトリがStatic Rootとして配信されているか——を確認していなかった。賢さと完成度は別だということを思い知らされる場面だ。

ここが実務的に引っかかるのは、Tool Callの成功とタスク完了が全く別の指標だという点。232回中232回のコマンドが正常に実行されても、修正している場所そのものが間違っていれば前には進まない。求められるのはコード生成より、問題を診断する能力。逆に言えば、ローカルLLMの価値は「賢さ」ではなく「状態が近い」ことにある。機密データ、頻繁に変化するローカル状態、低レイテンシが必要な場面——こうした制約がある作業こそ、ローカルで動かす意味が出てくる。安いから使うのではなく、物理的に必要だから使う、その線引きを先に引いた方が、期待値を管理しやすい。