「自分でエージェントを作ってみたら」という好奇心

このブログでたびたび取り上げているBugHunterProjectは、ローカルLLM（自分のPCで動かすAIモデル）でPythonのバグを自動修理しようという試みです。同じような「ローカルLLMでエージェント的なことをやってみる」挑戦は、実は他の人たちも試していて、Zenn（エンジニア向けの技術記事投稿サービス）にその記録が残っています。今回は2つの実例を紹介します。

実例1：社内AIコーディングエージェントを作ったら、Claude Teamが最強だった話

ひとつめの記事は、社内向けにAIコーディングエージェントを自作しようとした人の記録です。ローカルLLMを含めていろいろなモデルを試した結果として、著者は率直に「結局Claude Teamが最強だった」という結論に至っています。

参考記事はこちらです。ローカルLLMで社内AIコーディングエージェントを作ってみた話（Zenn）

この記事から学べるのは、「ローカルLLMが万能ではない」という現実を先に知っておく大切さです。BugHunterProjectでも、修理の自動成功率が0件になるランがあるなど、うまくいかない場面は珍しくありません。ローカルLLMには「コストをかけずに試行錯誤できる」「プライバシーを守れる」といった強みがある一方、商用の大型モデルに比べると精度で見劣りする場面があるのは事実として受け止めておくのがよさそうです。

実例2：エージェントのコスト対策としてローカルLLMはアリなのか、Ollamaで検証

もうひとつの記事は、「エージェントを動かし続けるとAPI利用料がかさむ」という悩みに対して、Ollama（ローカルLLMを手軽に動かせるツール）を使う選択肢を検証したものです。コストを抑える手段としてローカルLLMがどこまで実用に耐えるかを、実際に試しながら評価しています。

参考記事はこちらです。エージェントコスト対策としてローカルLLMはアリ？Ollamaで試してみた（Zenn）

コストの視点は、大学生や個人で試している人にとってはむしろ切実かもしれません。クラウドの高性能モデルを使い続けると課金がかさみますが、ローカルLLMなら電気代とPCの性能さえあれば何度でも試行錯誤できます。「精度は多少落ちても、たくさん試せることに価値がある」という考え方は、学習目的で触っている人には特に相性が良い視点です。

BugHunterProjectとの共通点

この2つの実例に共通しているのは、「ローカルLLMは魔法の杖ではないが、使いどころを見極めれば意味がある」という現実的な結論です。BugHunterProjectでも、LLMに全部を判断させるのではなく、決定的（プログラムで確実に判定できる）な処理はプログラム側に任せ、LLMには最後の仕上げだけを任せる設計に寄せてきた経緯があります。他の人たちの実例を見ると、この方向性は決して独りよがりではなく、多くの人が同じような壁にぶつかった末にたどり着く工夫だとわかります。

これから試す人へ

• 最初から完璧な自動化を目指さず、「ここはLLM、ここはプログラム」と役割を分けて考えると失敗を減らせます。
• ローカルLLMは「コストをかけずに何度も試せる実験場」として捉えると、精度面の弱さも受け入れやすくなります。
• 同じ挑戦をしている人の記録を読むと、自分だけがつまずいているわけではないと分かり、続けるモチベーションにもなります。