LLMエージェントループとツール利用の不合理な効率性

• AIプログラミング支援ツール Sketchの開発経験を通じて、LLMとツール利用を組み合わせたループ構造の簡潔な実装を強調
• わずか9行のループコードだけで、Claude 3.7 Sonnet など最新のLLMが実用的な問題を迅速に解決
• bash などの汎用ツールが1つあるだけでも、開発者の反復的で煩雑な作業をかなりの部分まで自動化可能
• 問題解決だけでなく、追加のツールを接続して テキスト編集や特化した作業 の品質と反復速度を高められる
• カスタムLLMエージェントループ が開発者の日常的な自動化にますます導入される流れ

---

はじめに: 開発経験とSketchプロジェクト

• フィリップ・ゼリガーおよび同僚たちは、AIベースのプログラミング補助ツール Sketch を開発する過程で、LLMとツール活用を組み合わせたシンプルなエージェントループ構造 の高い効率性に驚かされた
• 中核となる構造はわずか9行のループコードで、システムプロンプト、会話履歴、最新メッセージをLLM APIに渡す
• LLMが出力を生成し、必要に応じて tool_calls（ツール呼び出し要求）を返す

LLMとツール利用の統合

• 「ツール利用（tool use）」とは、LLMがあらかじめ定義された スキーマに沿った出力 を返し、システムプロンプトとツール説明プロンプトを通じて、LLMが bash のような汎用ツールにアクセスできるようにすること
• 最新のLLM（例: Claude 3.7 Sonnet）は、単一の汎用ツールだけでもさまざまな問題を素早く自動化し、一部は1回の実行（"one shot"）だけで解決可能
• 以前は複雑な git コマンドを探して貼り付け、手動でマージ作業をしていたが、今ではSketchに依頼すればその場で解決できる
• 型変更後に発生する多数の型チェックエラーも、Sketchが初めて自動処理してくれた
• エージェントループは 継続的かつ適応的 に動作し、ツールが未インストールの場合は自動でインストールし、コマンドオプションの違いにも合わせて対応する
• 利用中にLLMがテスト失敗時に「テストをスキップする」といった予期しない提案をすることもあるが、全体として業務自動化の質は向上している

ツールの多様化と特化

• Sketchは bash 以外にも追加のツール（例: テキスト編集ツール）を活用することで、作業品質が向上し、開発ワークフローがさらに効率化されることを実感している
• LLMが sed などでテキストを正確に修正するのは想像以上に難しく、視覚的（visual）エディタ型のツールのほうが優れていると感じられた

今後の展望とワークフローの変化

• エージェントループ構造は、従来の汎用自動化ツールでは扱いにくかった開発者の日常的な反復作業 に、今後ますます活用される見込み
• 例として、スタックトレースとgitコミットの相関分析のような面倒で反復的な作業も、LLMが素早く一次処理を行う
• 今後は より多くのカスタムメイドで単発的なLLMエージェントループ が、開発者の bin/ ディレクトリなどで使われるようになると期待できる
• ユーザーは必要な bearer token だけを用意すれば、自分の環境で簡単に試せる

参考リンク

• 内容は philz.devブログ にも掲載されている
• プロジェクトおよび関連情報は sketch.dev, merde.ai, pi.dev でさらに確認可能

[GN⁺]

Hacker Newsのコメント

• このブログ記事も強くおすすめしたい。同じ論点をずっと詳しく、しかも説得力をもって扱っている版。筆者が実際にコーディングエージェントをゼロから作っている。https://ampcode.com/how-to-build-an-agent 参照。LLMがツールを呼び出せるループの中で、どれほど多様な作業をうまく処理できるかは本当に驚くべき体験。もちろん完璧ではなく、信頼性が100%に達していないといった問題もある。それでも少なくとも多少は感嘆に値する部分があると思う。こういうものは自分でやってみれば30分以内に追従できる。AIが特定用途に有効かどうかについて健全な懐疑を保ちながらも、驚異を感じられる部分だ。LLMをループに置くこの「異常なほどの効果」が、今これほど多くのコード生成エージェントがあふれている理由でもある: Claude Code、Windsurf、Cursor、Cline、Copilot、Aider、Codex などなど、しかも追随して作るプロジェクトも非常に多い。特別な秘訣がない理由でもあり、魔法の95%は結局のところLLM自体と、ツール呼び出しをするようファインチューニングされている点にある。Claude Codeの主要開発者が最近のインタビューで率直に認めていたことでもある。もちろん、こうしたツールをうまく動かすには多大な努力が必要だが、根本的にはほぼ同じ単純なコア構造だ
  • こういう記事をずっと長いこと探していたので、本当にありがたいという気持ち。多くの人は Agents を見て「たぶん本当に複雑な問題はうまく解けないだろう？」と反応するけれど、私から見るとエージェントの核心はそこではない。LLMは大量のコンテキストの中で本当によく機能し、エージェントはLLMがより多くのコンテキストを見つけて、質問への回答品質を高めるための構造だ
  • LLMが単独でループの中に入り、何度も人の指示なしでうまくこなせる作業はあまり思い浮かばない。何回か繰り返すと、必ず自分が介入しなければならない場面が出てくる
  • pocketflow というグラフ抽象化ライブラリを使って似たものを作ったチュートリアルがある。実際に使ってみたがかなりシンプルで、とても満足した。https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
  • Thorsten Ball が筆者だと今さら気づいた。彼の「interpreter を作る」は本当に楽しく読んだ記憶がある。たぶん自分も今やエージェントを作ってみるつもりだ
  • 上のリンクを開く前に ?utm_source=hn&utm_medium=browser を追加すべきか悩んでしまう
• 今日初めて GPT-4o と 4.1 で直接「vibe-coding」を試してみた。手作業でコンパイルエラーや警告、提案をキャンバスインターフェース経由でループさせながら入力する方式だった。ファイルは150行程度と小さかった。4o で始めたが、古いパッケージを使っていた。その点を指摘しても、すべての使用箇所を更新せず、自分で手直しする必要があった。ロジック変更を提案すると構文が完全に壊れる事態になり、その後は二度と回復できなかった。コンパイルエラーを入力し続けても構文上の問題を理解せず、コードのランダムな部分ばかり直してしまう。そこで 4.1 ならもっとましかと期待したが、4.1 はキャンバスの使用自体を拒否して、ただ説明するだけだった。自分で修正しろというスタイル。説得を続けてようやくキャンバスにコードを出させたら、今度は途中が // omitted for brevity のように省略された版で使い物にならなかった。ここで諦めた。エージェントがこの問題を解決してくれるのか気になる。現状ではこの体験は完全に壊れていると思うし、そんな状態で bash へのアクセス権を与えるのは危険すぎるという懸念がある
  • 「古いパッケージを使った」という点は、モデルの学習データの時点が打ち切られているから。LLMを使うときには必ず注意すべき部分だ。ChatGPT ではよく o4-mini-high に切り替えて使っている。このモデルは検索機能で最新ドキュメントも探せる。「Xライブラリの最新バージョンを調べてそれを使って」と頼むと、しばしばうまく処理してくれる。最近、JavaScript コードの一部を最新の Google 推奨ライブラリへ変換する作業があったのだが、古いコードをそのまま貼り付けて新しいライブラリへポーティングしてほしいと頼んだら、ドキュメントも調べたうえで正確に移植してくれた。https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
  • GPT 4.1 と 4o は Aider のコーディングベンチマークでスコアがかなり低い。実運用の感覚では 70% 以上はないと成果物が実用にならない。それでも複雑なものはかなりの補助が必要だ。何がうまくいって何がうまくいかないかは、使っていくうちに勘が身についてくる。https://aider.chat/docs/leaderboards/
  • 「スキルの問題」と言われるのは聞きたくないかもしれないが、LLMを使うのは確かに別種の熟練を要する分野だ。さまざまなツールの長所と短所を理解し、複数の手法を試し、練習することが必須の構成要素になる。もし bash アクセスを与えるなら、自分でもコンテナ環境（docker）でしか使わないつもりだ
  • それは vibe coding とは言えない。コード変更が自動反映されるツールを使ってこそ vibe coding が可能になる。手動で一つずつフィードバックしていると、エラーに突き当たって止まってしまう。vibe coding の核心は、巻き戻し、再実行、さまざまな解法を気軽に投げて捨てられることにある。こういう体験にはツール群が必要だ
  • 少し前に Cline プラグインと Claude を使って、VSCode で Android アプリのプロトタイプを「ゼロベース」から作った。Android Studio が出す基本テンプレートから始めて、数千行のコードを生成したが、コンパイルエラーは1行もなかった。アプリは期待どおりに動き、見つかったいくつかのバグも LLM のせいではなく、奇妙な Android API の挙動が原因だった。LLM にバグを指摘し、デバッグメッセージ出力を与えると、自分で修正してくれた。最初は修正が少し雑だったが、何度かフィードバックをやり取りすると、うまく解決された。コード作成エージェントとコードレビューエージェントをループで回せば、こうした点ももっと一般的にうまく扱えるようになる気がする
• Claude Code、つまり Sonnet 3.7 のターミナルインターフェースを、リリース初日から使ってきた。かなり大規模な CLI アプリ、フルスタックの Web システム、無数のユーティリティも書いてみた。以前プログラミングチームを率いていた頃と似たように、さらに野心的な挑戦をするようになった。構造的には他のツールとそれほど違わないのだろうが、Anthropic は非常に有用な機能を数多く追加した印象がある。完璧なものではなく、良いコード品質には今でも当時と同じくらいの努力が必要だ。かなり複雑なものも動きはするが、次の機能追加が難しくなる状況もしばしばある。扱い方に慣れてきたので、リファクタリングや補修の工程はずっと減った。完全になくなる類いのものではない。kgeist が経験した問題は正直想像しにくい。Claude もときどき自分の選択と違ったり、間の抜けた動きをしたりするが、投げ出したくなるほどだったことは一度もない。ほとんど常にまずまずの結果を出してくれて、多くの作業を頭から下ろしてくれる効果がものすごい。しかもリファクタリングが非常にうまい。定期的にコードを見直し、もっとよい方法を Claude に説明させると、複雑さがぐっと減る。「データ構造を変更して」といった依頼もすぐ解決してくれる。非常にすばらしい機能だ。そして遊び半分で、コードではなく雑多なものが積み重なった30年物のアーカイブディレクトリを開いてみた。「このディレクトリには何がある？」「昔の履歴書を読んで書き直して」「うちの子どもたちの名前は？」などと聞いてみても本当に驚かされる。まだ初期段階なのに、とても満足している
  • 最近、リモートのデータ構造定義、API 仕様、パースおよび保存の実装、ユーザーへの表示まで、すべてを一度に処理しなければならない状況があった。Claude がこれらすべてを同時にうまく管理してくれたおかげで、両端の小さな変更が中間層にどう影響するかを即座に確認できた。複数のアイデアを素早く反復しながら最適な解法を探していけた。このように、複雑度の高い複数レイヤーを高速な反復で探索できる点が驚きで、生産性向上と同時にシステム全体の構造理解も深めてくれた
  • 上で触れられていたリファクタリングは本当に楽しい作業だ。以前ならスプリントに組み込むことすら難しかった機能も、5分で終わる。まるで準備の整ったチームが、いつでも自分の要求を待っているような感覚だ。結果が気に入らなければすぐ却下できるし、不必要なレビューやスケジュール調整の心配もすべて消えたように感じる
• 「あ、このテスト通らないな……もう飛ばそう」と LLM がよく言うのが本当にもどかしい。そこで考えたアイデアがある。メイン LLM が指示どおり動くように、独立した並列のポリシー強制 LLM を同時に走らせる方式だ。たとえば補助 LLM が let's just の次に skip という単語が出ないよう、出力確率を操作する。つまり skip を禁止すれば、LLM が望ましくない行動から逸れるよう経路を変えられる。ある種の JSON モードや構造化出力のように機能しつつ、動的かつリアルタイムに補助 LLM がポリシーを制御する形だ。これがうまくいくなら、さらに発展させて、テストを通すためにテストコードを削除するとか、無意味なコメントを出力するといったさまざまなポリシー違反をすべて補助 LLM 側のプロンプトに入れ、補助 LLM がリアルタイムで監視・制御する構造へ拡張できる。Outlines チームがこういう構造をどう考えるのか気になる
  • もし1つの LLM が別の LLM の出力をチェックできるなら、「mixture of experts」LLM が、ある専門アルゴリズムを監視・監査する役割を担うこともできるのではないかと思う。あるいは別の思考スレッドを分離して、自分自身の出力を検証させ、必要ならその検証役をさらに検証する別のスレッドを置くことで、仕組みをより堅牢にできるはずだ
  • この文脈では、メイン LLM が誤った方向に進んだら、監視 LLM がその時点までモデルを「rewind」し、たとえば let's just skip the test を検知したら just の後までロールバックして、特定の単語が使われないよう bias をかけ続ける構造も考えられる。こうしたことをやるには、使うモデルプロバイダーが限られるかもしれないし、特に OpenAI は最近こうしたパワーユーザー向け機能に敵対的な傾向が見える
• 今朝 cursor でゲームプロトタイプのメインループから複雑な一部を切り出し、その部分向けのテストコード一式を自動生成した。全341件のテストが core math と主要コンポーネント全体をカバーしている。ときには cat herding のような感覚もあるが、具体的に使う関数、場所、テンプレートファイル、避けるべきことなど、より多くの制約を与えるほど結果はどんどん良くなる。合計3500行のテストコードを自分で書く必要がなく、問題が起きてもいつでも消して再生成できる。難易度カーブの調整、ミッションのバリエーションなど、本当にいろいろな部分で助けてもらっている
  • 自分の経験では、テストの自動生成こそ LLM の最高の活用例だ。退屈で反復的な労働に何時間、何日とかかる部分を一気に消し去ってくれる。自分では思いつけない多くのエッジケースまで自動でカバーされ、コードの安全性も高まる。本当に多方面で優れた機能だ
• 最近の LLM のツール利用能力にはとても興奮している。実際、このトリック自体は新しいものではなく、2年前に ReAcT 論文で初めて知った。その後 ChatGPT プラグインや MCP などでも活用され、今ではほとんどのモデルがツールコール / 関数呼び出しを念頭に置いて学習されている。今おもしろいのは、性能がどれだけ向上したかという点だ。o3/o4-mini の優れた検索性能もツールコール能力が土台になっている。Qwen3 4B（Ollama 2.6GB、Mac でもよく動く）もこの機能をうまくこなす。昨日 PyCon US で LLM ベースのソフトウェアを作るワークショップを行い、その流れで自分の LLM コマンドラインツールにもツール利用機能を追加した。https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html 参照。これで自分の LLM パッケージを使って、「strawberry に R が何回出てくるか数える」といったことも、シェルのワンライナーで安定して処理できるようになった
  • この機能がもたらす、愉快さと強力さの奇妙な組み合わせがたまらない
  • ワークショップは録画されたのだろうか
• どの agent がいちばん多くトークンを使うのか気になる。cline はリストの上位にいるし、roo は cline より少なく使うように見える。対話の仕方を自分で設定できる agent があるのか、Claude code が他の agent と比べてどうなのか知りたい
• 「必要なツールがなければインストールする」という点が怖いところだ。LLM は過度に“従順”で、誰かに言われるとすぐ実行してしまう構造になっている。これは SQL injection よりもっと深刻なセキュリティ上の懸念だ
  • いつ最初の agent ベースの大惨事が起きるのか、ときどき考えてしまう。（特に慌ただしく押し出されている AI 市場の雰囲気では）時間がたてば、取り返しのつかない災害が必ず起きるのではないかと不安になる
• タイトルは Eugene Wigner の論文「The Unreasonable Effectiveness of Mathematics in the Natural Sciences」から着想を得たもののようだ
  • その論文が元祖かもしれないが、もうずっと前からミーム化した慣用句だと思う。https://scholar.google.com/scholar?q=unreasonable+effectiveness
  • 私はむしろ Karpathy の 2015 年の「Unreasonable Effectiveness of RNNs」から取ったのかと思っていた。もちろん Karpathy もまた Wigner の論文から借用していたのだろうけれど。https://karpathy.github.io/2015/05/21/rnn-effectiveness/
  • 「unreasonable effectiveness」という見出しを見るたびに、著者の結論にはいつも強く同意しきれない感覚がある。Wigner の論文も含めて。今では一種の Betteridge の法則みたいに感じる
• 私たちは自社製品内の組み込み AI チャットボットに、より多くのコンテキストを与えるためのツールを構築した。最近のアクティビティログ、現在のオブジェクト定義、検索およびヘルプ記事の探索など、複数の機能を追加した。数か月たった今でもチャットボットの品質には驚かされている。もしチャットボットが何か誤った応答をしたら、関連するヘルプ記事をより具体的に更新するという運用にしている