コーディング作業はAIに任せろ！たった100行で作る高性能エージェントの秘訣

テキストスライドと文字起こしの組み合わせは普段は良いんだけど、これはほとんどのスライドが4単語しかなくて、文字起こしも同じ単語の繰り返しなんだよ。

この記事の筆者はAIやエージェントの成功で大いに利益を得る立場の人だ。真の信者みたいだから非難じゃないけど、詐欺師も同じ行動をするだろうね。

ghuntleyの投稿はいつも楽しみにしてて、特に.NET関連の貢献には感謝してるんだけど、今回のフォーマットは気が散って読みにくかったな。ライブ版は知らないけど、スライドデッキのフォーマットも多分そうだろうね。1スライド2～4単語じゃ、アイデアは伝わらないよ。

ClaudeやChatGPTのツール利用の裏側を誰か教えてくれる？APIで「ツール」が提供されて、ツール呼び出しを求める応答が返ってきて、僕らが実行して結果を送り返すんだよね。でもモデルはテキストベースだから、どうやってAPI応答に変換してるんだろう？ファインチューニングでツール呼び出しを特定のブロックに入れてて、それをサーバーが理解してるのかな？この仕組みや内部の区切りトークンについてドキュメントはある？ユーザーのテキストがそれを邪魔しないように、どうやってるの？

Anthropicのツール実装に関するドキュメントはここにあるよ
https://docs.anthropic.com/en/docs/agents-and-tools/tool-use…
モデルは「テキスト」ベースじゃなくて「トークン」ベースだってことを誤解してるね。コンパイラがコードじゃなくトークンを使うように、出力には単語だけでなくメタデータも含まれるんだ。

LLMとやり取りできるのはトークンだけなんだ。ツール呼び出しは特殊なトークンとAPIレイヤーを使ってて、ツール名や引数も渡すんだね。モデルはこれを解析して、ツールからの結果も特殊トークンで処理する。APIレイヤーがユーザーが特殊トークンを挿入するのを防いでるらしいよ。最近のモデルがツール呼び出しに強いのは、ファインチューニングをたくさんしてるからだね。特定のツール（Claude Codeが使うツールとか）に特化したファインチューニングもされてるみたい。これが全部うまくいくのは驚きだけど、ファインチューニングがめっちゃ大事なんだ。

ツール呼び出しのファインチューニングって、俺の知る限りはまさにその通りだと思うよ。モデルは答えに確信がない時や指示された時にツールを返すように訓練されてるんだ。汎用的なツール訓練と、ツール固有の訓練があるね。例えばgpt-ossは検索ツールをすごく使うし、Anthropicはtext_editorやbashみたいな既知のツールを文書化してる。これらはただの汎用ツール利用より深い意味合いで訓練されてるんだろうな。全体的にちょっと脆いけど、ツール呼び出しは特殊トークンとかトークン列でインバンドシグナルされてるよ。

Bashツール以外に、なんで他のツールが必要なんだろう？
ファイルリストとかリポジトリ検索、ファイル編集とか、全部Bashでできそうじゃん？
これって https://news.ycombinator.com/item?id=45001234 で示されてることなのかな？

正直、Bashツールだけでもいけるし、俺もそれで成功した経験はあるよ。エージェントからツールを取り上げて、どれだけクリエイティブに使うかを見るのは面白いんだ。でもね、他のツールを与えた方がパフォーマンスが上がる理由の一つは、SonneでこれらのツールについてRL（強化学習）がされてるからなんだ。モデルはツールの使い方を理解してるし、トークン効率も良いし、アクションの実行もずっと成功しやすいんだよ。Bashツールはね、時々Bash独自の表現で混乱したり、引数のエスケープが間違ったり、空白の扱いがうまくいかなかったりするんだ。

「モデルはこれらのツールの仕組みを理解していて、トークン効率も良く、一般的にそれらのアクションをより成功裏に実行する」って話、面白いね！
でも、元の記事の例ではそうは見えなかったんだけどな。例えば、list_filesツールを使って、JSON結果にREADMEが含まれているか確認するのと、bash [ -f README ]を使うのと比べてさ。

その名前のツールに対する訓練はないよ。でも、パラメータが単なるパスで、それがかなり基本的なツールだから訓練は必要ないだろうね。
一方、Bashコマンドを実行する方法を知るにはBashを知る必要があるんだ。BashはClaudeモデルにとって既知のツールだし [1]、テキスト編集もそうだよ [2]。それらをツールリストで参照することになってるんだけど、少なくとも俺のテストでは、「bash」っていうツールを呼んだ途端、Claudeはそのツールの目的についてたくさんの仮定を置くんだ。

Bashツールが、例えばBashismや引数のエスケープ、空白の扱いなどで混乱することがある、っていうのは、この返信で唯一ためになった文章だったよ。この調子でもっと詳しく説明してくれると嬉しいな。すごく重要な質問だったからさ。

別々のツールにする方が、全部Bash経由にするよりシンプルだよ。もし全部Bash経由だと、承認のいらない安全なコマンド（ファイルリストとか）と、承認が必要な危険なコマンドを区別する方法が必要になっちゃうんだ。ファイルリストを別ツールにすれば、エージェントがプロジェクトディレクトリ外のファイルをリストアップしないように強制することもできるしね。

承認のいらない安全なコマンドと、承認が必要な危険なコマンドを分ける必要があるって話、すごく説得力があるね、ありがとう！

うん、コーディングエージェントはBashツールとEditツール（これは正直、ちょっと任意だけど、ないとすごく非効率になる）だけでも動かせるだろうね。試したことはないけど、コード検索機能では苦労するかもしれないな。適切なプロンプトを与えれば可能だよ。例えば、LLMに「ソースコードを検索する必要があるなら、Bashツールでripgrepを使って」ってプロンプトするだけでいいんだ。

Edit toolって必須じゃないだろ？
patchとbash toolでソース編集できるし、効率が悪いってどこが？って疑問だよな。

人間だってshellですべてできるのに、なんでIDEが必要なんだ？
インターフェースは、必要な情報と取れるアクションを教えてくれるもんだろ。

もっと良い例え話があるな。
夫婦二人の家に信頼できる車が3台あるのに、積載量も燃費も悪い、オフロード性能も最高速度も劣る4台目の車が必要か？って話だよ。

これは「3.2 How to design good tools？」で説明されてるよ。
LLMが細かいクリックやタイピングを何回もする手間を省いて、作業に集中させるためなんだ。
かわいそうなモデルを助けてやれよ！

この引用元がどこか分からないな。
リンクされてる記事には載ってないみたいだけど。

Bash tool以外のツールが必要なの？
俺の予想だけど、最初は限られたツールから始めて、後からbashも使えるって気づいたんじゃないかな。

今さらだけど、記事ありがとう！AgentのループやLLM、プロンプトのアイデアは良かったし試したい。
でも、AI compassとかAgentic/Non-Agentic LLMとか、怪しい概念が多くて「詐欺か？」って警戒しちゃうんだ。
1単語スライドもどうかと。
学べたけど不信感もある、正直な感想だね。

トークンをループに投げ続ければ、Agentが手に入る。
これって「お金」のことだよな？
「トークン」を「お金」に置き換えれば、まさに「お金をループに投げ続ければ、Agentが手に入る」ってことだろ。

誰が「トークンはお金」なんて言ったんだ？
ローカルモデルもどんどん良くなってるし、今は最高の結果のためにトークンを買う必要があるけど、将来はそうじゃないかもだろ。

ローカルモデルだってタダじゃないよ、ベンダーよりは安いけどね。オフグリッドで電気も無料なら別だけどさ。無料枠もあるだろうけど、結局トークンにはお金がかかるんだ。

「オフグリッドで電気も無料なら別」って部分で笑っちゃった！著者の別の記事、https://ghuntley.com/internet/ を貼っとくね。ソーラーパネルあるのか分からないけど、たぶん持ってるんじゃないかな？

「ローカルモデルはかなり良い」って言うけど、要約とか翻訳にはいいけど、コーディングエージェントやAIスタートアップの90%は結局API使ってトークン買ってるんだよ。まるで意味不明なエラーを直すためにトークンを無駄遣いする「バイブコーダー」ってAI企業のカモにスロットマシンを回させてるのと一緒だね。

エージェントの作り方を書くより、そのエージェントが作ったプロジェクトを一つ見せてよ。

自分でエージェントを作って、ここでHNの「Show HN」として共有してくれたら嬉しいな。

このエージェントは何か完全に作ったの？これはこういう記事をHNに投稿するなら当然答えられるべき、すごく分かりやすい質問だよ。

シェアしてくれてありがとう。あと、荒らしは無視しなきゃダメだよ。

画像ばっかりで全然読みにくいんだけど…クソみたいなスクロールシミュレーターかよ。

「仕事がなくなる」って不安は目の前に迫ってる。LLMが出る前から鬱と闘ってる。「嘘つきな出力を監視するのにLLMと偽のガードレールを使う」なんてひどいシステム臭がするね。みんなやってるのは知ってるし、俺もコーディングエージェントは書いたけどさ。でもなんでこのページは洗脳みたいなオーウェル的な繰り返しデザインなの？
そんなのが必要だと感じられるなら、俺たちは常識を乗り越えなきゃいけない。巨人の肩に乗るつもりでコーディングエージェントを喜んで書くのかもしれないけど、みんな知ってるんだ、俺たちが作ってるのはテクノロジー版の覚せい剤帝国だってね。

ドイツでは原子力みたいな良いものでも、1980年代に絶大な力を持っていた業界ロビーに逆らって止められたよ。IP盗用AIみたいな悪いものも止められるし、人々はどんどん監視の目を光らせて、いつか組織化されるだろうね。

誰か、Oracle、Agent、高安全性、低安全性の軸について説明してくれない？

メタコメントはしたくないけど、これは最近見たブログ記事の中でも最悪なAIスロップ入りプレゼンテーションだね。なんでAI生成画像とか、箇条書きで済むことが全部個別の画像になってるの？読みにくいし、alt-textもないからアクセシビリティも悪いよ。カンファレンス発表が元なら、そのままの形式で載せてよ。

うわー、これ読めないね。イライラしてきて、PCの電源ボタン押す前にページ閉じちゃったよ :)

EdgeとChromeのオンデバイスモデル、phi4-miniとGemini Nanoで試してみたけど、こんな小さいモデルでも驚くほどよく動いたよ。URL: https://ryanseddon.com/ai/how-to-build-an-agent-on-device/

この種のコンテンツ、あのすごく不快な解説なしで欲しいな。ハウツーじゃなくてプロパガンダを読んでる気分になったよ。

個人的には、この問題領域に対する見方がすごく単純だと思うね。関数をたくさん追加するのはいいけど、スナップショット（Gitでの作業とか）、プロセスとネットワークレベルのサンドボックス化、プロンプトエンジニアリング、行き詰まりの検出、より良い解決策のための並列ソルバーを使ったモデル切り替えなんかはどう？こういうことがコーディングAgentを信頼できるものにするんだよ、関数宣言だけじゃなくてね。

それは第3弾に含まれるよ。俺はこういうコーディングAgentを仕事で書いてるんだ。基本から始める必要があるんだよ、だって皆が職場で機能を自動化するために知るべきなのは基本だからね。それはコーディングAgentじゃないかもしれないけど。このワークショップは、例えばデータエンジニアリングカンファレンスで発表されたものなんだ。

コーディングエージェントを作るには、まず明確な目標を立てて、AIをうまく使って、フィードバックをもとにどんどん改善していくのが大事だよ。簡単なタスクから始めて、徐々に規模を大きくしていくといいよ。

うん、ベースとなるコーディングエージェント（ワークショップで学んだようなやつね）ができたら、それを使って別のエージェントでも何でも作れちゃうんだ。その核からスタートして、どんどん発展させていけるから、何でも構築可能だよ。

僕が引っかかるのは、このエージェントデザインのスタイル、つまりすごく大きな自律性を持たせるのが、デバッグで自己修正できるコーディング作業では理にかなってるってこと。でも、他のユースケースでエージェントにここまで自律性を持たせるのが、より構造化されたフローとかLangGraphみたいなのよりも優れてるのかな？って疑問に思うな。

コーディングエージェントのコツは、エージェントのトークンウィンドウに収まるようなタスクに注目させて、いつ「これは任せよう」って決めるかだよ。PMも全く同じ悩みを抱えているのが面白いよね。

うん。必要なのは、方向性を決めてあげて、あとは追い風を吹かせてあげることだよ。

Claude Codeに匹敵する、ollamaやopenrouterみたいなLLMと連携できる最適なCLI（非インタラクティブオプション付き）って何？aiderはファイルを見つけられないし、オープンソースのGeminiはダメだった。Opusと組み合わせたらClaude Codeみたいに使える良いCLIはないかな？

Opencodeはかなり良いし、君のニーズを満たせるはずだよ。一つ言っておきたいのは、Geminiは今エージェントとしてはあまり良くないってこと。GeminiはツールコーリングLLMとしては微妙で、ただのオラクルって感じだからね。詳しい情報はこちら→ https://ghuntley.com/cars/

あんまりたくさん試してないけど、LLM cliは悪くないと思うよ。

細かいこと言って悪いけどさ。著者がシーケンス図って呼んでるやつ、あれは違うよ。フローチャートだよ。