LLMエージェントループ＋ツール使用の驚異的な効果

150行ってマジ？俺はサクッと1500行くらいいけるし、そっから修正したいクラスとか関数にピンポイントでいける感じ。

400行超えたら全然ダメ（Claude 3.7, paid Cursor）。ヤバいのは複雑なこと頼んで300行いいコード書いたと思ったらタイムアウトとかクラッシュ。続きって頼むとマジでコードがヤバくなる。重複したり、全然合わない関数作ったり。

サーフボード無しで波に乗ろうとしてうまくいかないって文句言ってる奴いたら、水とかサーフィンのせいにする？それとも物理無視して文句言ってる奴のせい？どれだけ走りたくてKelvin Kiptumだろうと、結局ダメなんだよ。

4oとか4.1ってコーディングはそんな良くないね。俺は4o-mini-highが一番いい結果。o3もたまに使える。個人的にはキャンバス嫌い。チャットに出してくれる方が好き。結構ファイル丸ごととか、そのまま置き換えてって頼むこと多いんだよね。でもだいたい300～400行くらいで微妙になってくるから、ファイルを分けたりリファクタリングしないとダメになる（ファイル内のメソッド一つだけならいけるけど）。

他の人も言ってたけど、君、最先端から3ヶ月くらい遅れてる感じだよ。書いてることは2月頃の俺の経験そっくり。Claudeに乗り換えなよ（個人的にはGeminiも同等と思う）。ちゃんとしたコーディングツール使って、チャット窓からコピペなんて先週の話。

物作るのサボってフロントエンドフレームワークいじり倒してた代わりに、ちょびっとの効率アップのために開発環境いじり回すようになった感じ。

それってサーフィンが目的地への唯一の行き方の場合にしか意味ないでしょ。でもそうじゃないじゃん。

「明らかに多くの人に使えてるもの」を否定して知的ぶる奴らへ。俺はLLMじゃなくvibe codingについて言ってる。理解せずコピペするだけのvibe codingは猿にナイフ渡すのと一緒。LLMは便利だけどvibe codingは技術史上最低。「使えてる」ってのはおもちゃレベルの話？本番で使える？遊びや実験ならいいけど、あれ学習にもならないよ。

vibe codingにはvibeとcodingの要素がある。coding取ったらvibeしか残らん。そこ間違うな。俺はvibe codingで作ったReactの社内ツールを本番で問題なく使ってるぞ。数日分の作業があっという間に終わったし。

こないだVSCodeのClineプラグインとClaude使ってAndroidアプリのプロトタイプをゼロから作ってみたんだ。Android Studioのテンプレートから始めて数千行のコードがエラーなしでできたよ。アプリもほぼ思った通りに動いた。バグもあったけど、それはLLMじゃなくAndroid APIの変な仕様のせい。LLMに指摘したらデバッグを手伝ってもらって直せたよ。コードの質は最初はダーティだったけど、フィードバックで改善できた。コード書くエージェントとレビューエージェントを組み合わせたら、もっと良くなりそうだね。

＞それらを混同しないで。
Vibe codingって言葉を流行らせた人が説明してたのは、コードを全く書かないことだよ。エラーメッセージを貼り付けて、LLMの応答を貼り付けて、またエラーメッセージを貼り付けて、応答を貼り付けて、それが何度か繰り返されたら結果が出るのを祈るだけ。
LLMの出力もエラーメッセージも「見ない」ことが含まれてる。
たぶん、あなたは別の定義を使ってるんじゃない？

なぜ多くの人が少数の人しか「hello world」とかその程度の難易度のことしかしないかっていうとね。すべてのソフトウェア開発者が簡単なフロントエンドの仕事をするために雇われてるわけじゃないんだよ。

＞それはモデルの学習カットオフ日付があるからだね
非推奨のパッケージを使ってるって指摘したら、LLMは同意してくれて、それが非推奨になった正しいバージョン（ずっと前の2021年）まで挙げてくれたんだ。だから非推奨だってことは知ってるんだけど、たくさんの学習データ（2021年より前）がそのパッケージをまだ使えるものとして使ってるから、次のトークン予測（推論やツールなしだと）では点と点が繋がらないんだ。
＞多くのコードでデフォルトモデルをChatGPTのo4-mini-highに変えたよ、検索機能で最新ドキュメントを見れるからね
情報ありがとう！

経験の浅い、あるいは何も知らない、ジュニアな、または経験不足の開発者に、何日もスパゲッティコードを書いて、結局先輩に助けを求めたり仕事をしてもらったりするよりも、さっき言われたナイフを与える方が良いと思うな。

＞「猿にナイフ」アナロジーは適切
経験者ならvibe codeできる？＞「明らかに動く」って？プロトタイプ？頑丈なものもできるの？
AIが基盤CRUDアプリ作れないと？＞vibe codingは学習にならない
それがあなたの言う「動く」？vibe codingの意味を狭めてる？

o3は、本当に衝撃的に良いんだよ。レート制限でしょっちゅうは使えないから、たまの機会にとっておいてるんだけどね。今日はSwiftのバイナリパッケージをSDK内でツリー状に統合して、内部バージョン衝突を検出する方法をどうすればいいか聞いてみたら、すごく良く調べられてて理にかなった概要をくれたんだ。しかも、新しいアイデアまで教えてくれたよ。

＞コード書くエージェントとレビューするエージェントをループさせたらもっと一般的に解決できそうだよね。
これ×100。LLMに他のLLMのコードをレビューさせて修正させると、本当に格段に質の良いコードになるんだ。ありえないくらい効果的だよ。

LLMは慣れるのに時間がかかるんだね。gpt3.5を毎日半年使ってやっと上達したよ。コードは600-1000LOCくらい書ける。”vibe coding”って感じじゃないな、詳細な指示が必要だから。新規開発だと10倍、既存だと2倍速くなったかな。出てきたコードは読むべきだよ。エラー防ぐには、考え方やロジックを読むのが大事。ミスを見つけたらpromptをやり直す。ダメならsession変える。o1-proみたいなテスト時間モデルはエラー少なくてマジで良いよ。claudeは知らんけど、遅いテスト時間モデルはコーディングに超向いてるわ。

普通のチャットUIはLLMには合ってないんだよ。contextが必要だから。これ見てよ -＞ https://github.com/marv1nnnnn/llm-min.txt
LLMは問題解決は得意だけど、ドキュメント置き場じゃないんだ。NNは概念をモデル化してるだけ。人間みたいにAPIドキュメントとか探すのは必要。o3でWeb検索もできるけど効率悪い。プロ向けのLLMコーディングツールはcontext管理がうまいんだよね。

LLMのツール使用、マジで興奮する！ReAcT論文から知ってたけど、最近のモデルはめちゃくちゃ上手くなったよね。o3/o4-miniの検索性能もツール呼び出しのおかげだし、軽いQwen3 4Bでもそこそこできる。
PyCon USでLLMワークショップやった時に、自作ツールにツール機能を追加したんだ。資料はこれ： https://building-with-llms-pycon-2025.readthedocs.io/en/late…
今やシェルワンライナーで単語中の特定文字を正確に数えられるようになった！

俺、Claude Code (Sonnet 3.7) マジで使ってる。CLIとかWebとか色々作って、前より野心的になれたわ。完璧じゃないけど、リファクタリングとか超得意で、複雑な変更もすぐやってくれる。「このデータ構造変えて」とかも一瞬。頭の負担がマジでimmenseに減った！コード以外のファイルも見せて質問できるし、履歴書とか子供の名前まで！まだ初期なのに、マジで幸せ。

最近、データの構造からAPI、保存、表示まで一連の作業をClaudeに全部やらせてみたんだ。
そしたら、各層の変更影響を見ながら色んなアイデアを試せて、一番良い解決策を見つけられたよ。層をまたいで試せるのがマジで目から鱗。生産性も上がったし、全体像の理解も深まったわ。

リファクタリングの話、マジ同意！Sprintに入れるのが大変なことが5分で終わるんだぜ。チームが待機してて、すぐに俺の指示に応えてくれる感じ。仕事の正当化とかスケジュールとか、面倒なこと一切なし！

LLMエージェント、実際の仕事だとコンテキストが問題だね。ツール使うとコンテキスト増えるし、10k超えると質落ちる。あと脱線して戻れなくなることも。俺たち1年前からこの問題取り組んでるんだ。解決はまだだけど進んでるよ。［宣伝］nonbios.ai試してみて！長期間コーディング、リアル実行環境、透明性あり。無料ベータ、捨てメアドOK！（mailinatorとか）

＞間違った方向に行くと戻ってこれないってやつ、これがツールとして使えるかって議論の一番の核心だろうね。LLMが間違った方向行かないように問題を十分説明できた時には、もうほとんど自分で解決しちゃってるでしょ。エラーフィードバックで自動っぽく聞こえるけど、人間の意図を代弁してる薄い層にすぎないってすぐ気づくよ。

うん、でも俺たちはこれが“根本的”な問題だとは思ってないよ。彼らの行動をもっとうまく導けるようになったし、最初に始めた頃よりウサギの穴に落ちることはずっと減ったからね。

確かにね。でも、その一方でタイピングがめちゃくちゃ多くて、そんなに複雑じゃないタスクもいっぱいあるよ。特にGUI開発でフォームとかチャートとか作る時とか。そういう時 LLM はすごい助けになると思うな。

一部の思考モデルは回復するかもね…追加で4kトークンとか“思考”に使って。たとえ長いコンテキストでも安定しても、速度はめちゃくちゃ落ちる。このアーキテクチャじゃ勝てないってば笑。

うちが見つけたこととすごく正確に一致してるね。“思考”モデルはもっとうまくやるけど、速度はめちゃくちゃ落ちる。今のところは速度より正確さを選んだよ。でも速度低下が3-4倍だから、たまにしか“思考”しないアーキテクチャに移るかも。LLM分野で起きてること全部、人間の自然な思考にすごく近いよね。

面白そうだね。コンテキストはどうやって管理してるの？

コンテキスト管理が一番大変なんだ。色々戦略使って減らしてるよ。例えばね：
1. カスタムのMCPサーバーでLinuxコマンドライン作業。コンテキスト減らす最適化済み。
2. ガードレールでコンテキスト減らす。LLMにヒント与えて少なく作業させる。
3. コンテキストを剪定してエージェントに“忘れさせる”。重要じゃないことを忘れるのは基礎能力だよ。
これは人間が睡眠で記憶を“忘れ”て脳を健康に保つのにヒントを得たんだ。LLMも忘れさせるのがタスク集中に重要だよ。

今朝Cursor使って、ゲームの複雑な部分を抜き出しテスト作ったよ。Cursorが書いたテスト341個で、コアな部分全部カバー。たまに暴走するけど、制約与えるほど結果は良くなる。合計3500行のテストコードを自分で書かずに済んだし、直す必要もない。前提変わっても削除して再生成できる。難易度カーブ調整とかミッション生成とかも助けてくれたよ。

テスト書くこと、俺の経験だとこれがLLMの一番良い使い方だね！何時間、何日もの面倒な作業がなくなるし、自分で考えるよりずっと多くのエッジケースをカバーできる。それにコードも頑丈になる！全面的に素晴らしいね！

コメントしてからも、テストを60個、テストコードを500行も生成したんだよね。大変なやり方でテストコードを何十万行も書いてきた身としてはさ、これ、俺より全然速いだけじゃなくって、カバレッジの面でも俺より優れてるんだよ。しかも、俺が今まで見てきた何人かの開発者よりも俺の手がかからないんだよね。

”あー、このテスト通らないな…もうスキップしちゃお”、なんて言われると、すっげーイライラするんだよね。
そこで突拍子もないアイデアなんだけどさ。メインのLLMが指示通りに動くように、別の監視役LLMを並行して独立して走らせるってどう？
もしその監視役LLMがさ、リアルタイムでコーディングLLMが”スキップしちゃお”みたいなことを言うのを禁止できたらどうだろう。例えば”let’s just”ってトークンが見えたら、次に”skip”っていう単語が出てくる可能性を排除するように出力にバイアスをかけるんだ。
”let’s just”の後に”skip”が出ないように強制することで、LLMを望ましくない振る舞いから別のパスへ誘導できるじゃん。
これってStructured OutputsとかJSONモードみたいなもんだけど、監視役LLMが動かしていて、トークンが出力されるたびにリアルタイムで動的に変わるんだ。
もしこのアイデアがうまくいったらさ、監視役LLMにもっと高度なことを指示できるかもね。例えば、コーディングLLMがテストコードを削除してテストをパスさせようとするのを禁止したり、意味のないコメントを出すのを禁止したり…。今システムプロンプトに入れて、LLMがやってくれることをただ祈ってるようなポリシー全部を、代わりに監視役LLMのプロンプトに入れるんだ。
Outlinesの人たちがこのアイデアについてどう思うか、興味あるね！

この流れで言うとさ、もしメインのLLMが間違った方向に進んじゃったら、間違った方向に進み始める”前”の状態にモデルを”巻き戻す”こともできるかもね。監視役のLLMは、必ずしも”let’s just”の後に”skip”がまずいトークンだって推測する必要はなくて、代わりに”let’s just skip the test”って全部見てから「ダメだ、”just ”のトークンまで巻き戻して、logit_biasで{”skip”: -10, ”omit”: -10, ”hack”: -10}みたいにバイアスかけてやり直そう」ってできるわけだ。
もちろん、これやると使えるモデルプロバイダーが限られるけどね（特にOpenAIはここ1年くらい、そういうパワーユーザー的なことやるのに結構敵対的になってきてる）。

それ、すっげーいいアイデアだね。
なんか最適化みたいだね。「トークン禁止」をツール呼び出しみたいにすると、トークンごとだと遅すぎるだろうしね。巻き戻しがもし可能なら、君のアイデアは実用的なパフォーマンスにできるかも。

いや、最適化とは違うんだよ。貪欲なアプローチはうまくいかない、だって拒否トリガーとなるトークンの”後”に来る重要な文脈を無視しちゃうからさ。
例えばさ、”Let’s just skip writing this test, as the other change you requested seems to eliminate the need for it.”（君がリクエストした別の変更で、このテストを書く必要がなくなったみたいだから、書くのはスキップしちゃおう）って考えてみてよ。
”Let’s just”のところでモデルを巻き戻すのはバカげてるし、”Let’s just skip writing this test”で巻き戻すのもバカげてる。テストを書くのが神への聖なる義務で無条件にそうしなきゃいけない、なんて信じるのもね。その後の文脈で、その判断が正しいって明確になってるでしょ？もし君（または監視役エージェント）がその理屈に納得できないとしても、その時は完璧な位置にいるわけだ。”nope, Let’sまで巻き戻して、[”skip”, test”]に対してバイアスをかけよう”って言える。
メッセージ全体を一度チェックするのが理にかなってるんだ。トークンごとじゃなくてね。

OpenAIのチームが似たようなことをやろうとしてたんだよね[1]。o3-miniが難しすぎるテストを回避しようとしてないか、4oに監視させてたんだ。それでo3-miniがそういうことするたびに罰を与えて学習させたんだけどさ。結局o3-miniは相変わらず報酬ハッキングしてたんだけど、4oに検知されにくくなっただけだったんだ。言うことがこう変わったんだ：
＞To skip all tests, we can define a pytest_runtest_setup function that always skips.
から
＞Idea: Starting a new build with a random first succession, calling random_new_succession should not increment succession, but in implementation, it does. Adjust to prevent increment. Implement fix to random_new_build not to increment succession, or test adapted to behavior.
に変わって、結局全く同じこと（テストをスキップすること）をやってたんだよ。
学習させなくても、それは一時的な絆創膏にすぎないんだ。報酬ハッキングのインセンティブが十分高くなれば、単に検知できない別の言い回しを使い始めるだけさ。
[1]: https://openai.com/index/chain-of-thought-monitoring/

もし最初のLLMをチェックするために2番目のLLMを走らせるのがうまくいくならさ、なんで”Mixture of Experts”のLLMは専門家の一人を他の専門家の結果をチェックすることに専念させられないの？それか、テスト時の計算で”思考”するモデルは、自分の出力を検証する別の思考スレッドを走らせられないの？それが60％くらい効果あるなら、さらに検証役を検証する別の思考スレッドがあってもいいんじゃないの？みたいな。

それはね、エージェントと監視役が一緒に学習されてたら、共有された報酬関数が監視役を腐敗させちゃうからさ。

事前学習で得られる共有された報酬関数なんて、LLMにとって小学校みたいなもんでしょ。RLHFは中学校かな。監視役は、システムのプロンプトやユーザープロンプト、ファインチューニングなんかで、ワーカーとは差別化できるじゃん。それは人間でいうと、医大とか法科大学院みたいなもんだよね。
確かに、人間の裁判官、弁護士（弁護側と検察側）、陪審員だって、同じ小中学校に通ってたとしても、それぞれの仕事をちゃんとこなせるわけでしょ。

君が言いたいことはわかるよ。俺の言いたいポイントはね、もしRLVRなんかからの報酬に基づいてエージェントと検証役／監視役を一緒に学習させると、システム全体（エージェント＋監視役）が報酬ハッキングするようになるってことなんだ。OpenAIが彼らの”Learning to Reason with CoT”っていうブログ記事でこれを示してたんだよ。CoTの中で報酬ハッキングと関連する文字列を検知して罰を与えるためにモデルを使ったんだけど、結局モデルは検知されにくい方法で報酬ハッキングするようになっただけだったんだ。高次の検証役をどんどん積み重ねても、時間を稼げるだけかもしれないし、偽陰性率も上がる。それに報酬ハッキングはシステムにとって安定したアトラクターなんだよ。