AIエージェント出力がゴミ？問題はあなたがトークンを燃やすのが惜しいからだ

問題はプロンプトにありません！

作者：Systematic Long Short

翻訳：深潮 TechFlow

**深潮ガイド：**この記事の核心論点は一つだけ：AIエージェントの出力品質は投入したToken数に比例する。

著者は単なる理論の話をしているのではなく、今日からすぐに使える具体的な方法を二つ提示し、「新規性の問題」というToken積み上げの限界を明確に示している。

エージェントを使ってコードを書いたりワークフローを実行したりしている読者にとって、情報密度も操作性も非常に高い。

はじめに

さて、このタイトルは確かに目を引くが、冗談ではない。

2023年、私たちがまだLLMを使って本番コードを生成していた頃、周囲の人々は驚きのあまり口をあんぐりさせた。なぜなら、その当時の一般的な認識は、LLMは役に立たないゴミしか出せないというものだったからだ。しかし私たちは、誰も気づいていない事実を知っている：エージェントの出力品質は、投入したTokenの量に依存している。これだけだ。

いくつか実験をすればすぐにわかる。複雑であまり一般的でないプログラミング課題——例えば、制約条件付きの凸最適化アルゴリズムをゼロから実装させる——をエージェントにやらせてみる。最も低い思考レベルで実行し、その後最高レベルに切り替えて自己レビューさせ、どれだけバグを見つけられるか試す。中間レベルや高レベルも試す。すると直感的にわかるだろう：バグの数は投入したTokenの量とともに単調に減少していく。

理解しやすいだろう？

Tokenが多い＝誤りが少ない。これを一歩進めると、これは基本的にコードレビューの根底にある（簡略化された）考え方だ。全く新しい文脈で、膨大なTokenを投入（例えば、コードを行ごとに解析し、各行にバグがあるか判断させる）ことで、ほとんどすべてのバグを見つけ出すことができる。このプロセスは十回、百回と繰り返し、異なる角度からコードベースを見直すことで、最終的にすべてのバグを洗い出せる。

「Tokenを多く使えばエージェントの品質が向上する」という見解には、もう一つの実証的裏付けがある：エージェントを使って全工程を自動化し、直接本番運用に乗せると豪語するチームは、基本的にモデル提供者か、資金力のある大企業だけだ。

だから、もしあなたがエージェントで本番コードが書けずに悩んでいるなら——率直に言えば、それはあなた自身の問題か、あるいは財布の問題だ。

どうやって投入したTokenが十分か判断するか

私は以前の記事で、「問題はあなたのフレームワーク（ハーネス）ではなく、シンプルに保つことで優れたものが作れる」と断言した。この考えは今も変わらない。あなたがその記事を読んで実践しても、エージェントの出力に満足できない場合、私にDMを送ったとしても、既読だけで返信しないこともある。

この文章は、その返答だ。

エージェントのパフォーマンスが悪く、問題を解決できない大半のケースは、あなたが投入したTokenが足りないからだ。

一つの問題に必要なTokenの量は、その規模、複雑さ、新規性に完全に依存する。

「2+2は何？」には多くのTokenは必要ない。

「PolymarketとKalshiの全ての市場をスキャンし、意味的に類似し、同一イベントの前後で清算されるべき市場を見つけ出し、アービトラージの境界を設定し、アービトラージ機会があれば低遅延で自動取引するbotを作ってほしい」——これは大量のTokenを必要とする。

私たちの実践から面白い発見があった。

十分なTokenを投入して、規模や複雑さから生じる問題に取り組めば、エージェントはどんなことでも解決できる。言い換えれば、非常に複雑で、多くのコンポーネントやコード行を含むものを作りたいなら、これらの問題に十分なTokenを投じれば、最終的には完全に解決できる。

ただし、重要な例外もある。

あなたの問題があまりにも新規性が高すぎる場合だ。現段階では、いかにTokenを積んでも「新規性」の問題は解決できない。複雑さによる誤りをゼロにできても、エージェントが未知のものを空から発明することはできない。

この結論には、実はほっと一息つかされる部分もある。

私たちは膨大なTokenを投入し、ほとんど誘導なしでエージェントに機関投資の流れを再現させられるか試した。これは、私たち（量的研究者）がAIに完全に取って代わられるまで何年かかるかを知るためだった。結果、エージェントはまともな機関投資の流れに近づくことはできなかった。理由の一つは、それらの流れを訓練データに見たことがなかったからだ。

だから、あなたの問題が新規性の高いものであれば、Tokenを積み上げるだけでは解決しない。自分で探索を導く必要がある。しかし、解決策を確定させたら、あとはTokenを積み重ねて実行させるだけ——コードベースやコンポーネントの複雑さは問題にならない。

シンプルな経験則として、Token予算はコード行数に比例して増やすべきだ。

多くのTokenを使うことは何をしているのか

実践では、追加のTokenは主に次の方法でエージェントのエンジニアリング品質を向上させる。

・同じ試行内でより多くの推論時間を与え、誤った論理を自己発見させる。深く推論させるほど、計画が良くなり、一発当てる確率が高まる。

・複数の独立した試行を許可し、異なる解決策を探索させる。より良い解決策を見つけるためだ。

・異なる解釈やアプローチを試すことで、弱い方向性を捨て、最も有望なものを残す。

・全く新しい文脈を使って自己の過去の仕事を批評させ、改善の機会を与える。これにより、「推論の惰性」にとらわれずに済む。

・そして私が最も気に入っているのは、より多くのTokenを使えば、テストやツールを使って検証できる点だ。実行して動作確認を行うことは、答えの正しさを最も確実に確認できる方法だ。

この論理が成立するのは、エージェントのエンジニアリング失敗がランダムではなく、早期に誤った道を選び、そこから修正や巻き戻しを十分に行わなかったことに起因しているからだ。

要するに、Tokenはあなたが買った意思決定の質そのものだ。これを研究作業に例えると、難題に対して即答させると、時間的制約が増すほど答えの質は落ちる。

研究は、「答えを知る」ことの基礎を生み出す活動だ。人間は生物学的に時間をかけてより良い答えを産み出す。一方、エージェントはより多くの計算時間を費やしてより良い答えを出す。

あなたのエージェントを向上させるには

半信半疑かもしれないが、多くの論文がこれを裏付けている。正直、「推論」調整のスイッチがあるだけで、必要な証明は十分だ。

私が特に好きな論文の一つは、少数の精選された推論サンプルで訓練し、その後モデルに「停止したいときに考え続けさせる」方法を導入したものだ。具体的には、「待て」（Wait）を追加するだけで、あるベンチマークのスコアが50%から57%に向上した。

率直に言えば、もしあなたがエージェントのコード品質に不満を持ち続けているなら、単一の最高思考レベルでは不十分かもしれない。

私からの二つの非常にシンプルな解決策を提案する。

簡単な方法一：WAIT（待て）

今日からすぐにできる最も簡単なこと：自動ループを組む——完了後、エージェントに新しい文脈を与えてN回レビューさせ、問題があれば修正させる。

このシンプルなテクニックでエージェントのエンジニアリング効果が改善されたなら、あなたの問題はTokenの量だけだと理解できる。ならば、Tokenを積み上げるクラブに参加しよう。

簡単な方法二：VERIFY（検証）

エージェントに早期かつ頻繁に自己検証させる。テストを書いて、選択した解決策が確かに動作することを証明させる。特に複雑で深くネストされたプロジェクトでは有効だ——関数が下流の多くの関数から呼び出される場合、上流で誤りを捕捉できれば、後の計算時間（Token）を大幅に節約できる。だから、構築過程のあらゆる段階で「検証ポイント」を設ける。

何かを書き終え、「完了」とエージェントが言ったら、別のエージェントに検証させる。異なる思考の流れを取り入れることで、システム的な偏りもカバーできる。

以上だ。これについてはもっと書きたいこともあるが、少なくともこの二つを意識し、きちんと実行すれば、あなたの問題の95%は解決できると確信している。シンプルなことを極めて、それに必要な複雑さを段階的に積み重ねるのが最良だ。

「新規性」の問題はTokenだけでは解決できないと述べたが、もう一度強調しておきたい。なぜなら、あなたがその落とし穴に早晩はまるからだ。そして、「Tokenを積んでも無駄だ」と泣きついてくる。

あなたが解決したい問題が訓練データに存在しないなら、あなたこそが解決策を提供すべき人間だ。だから、専門知識は依然として非常に重要だ。