作者：Systematic Long Short
翻訳：深潮 TechFlow
深潮ガイド：この記事の核心論点は一つだけ：AIエージェントの出力品質は投入したToken数に比例する。
著者は単なる理論の話をしているのではなく、今日すぐに使える具体的な方法を二つ提示し、「新規性の問題」というToken積み上げの限界を明確に示している。
エージェントを使ってコードを書いたりワークフローを実行したりしている読者にとって、情報密度も操作性も非常に高い。
はじめに
さて、このタイトルは確かに目を引くが、冗談ではない。
2023年、私たちがまだLLMを使って本番コードを生成していた頃、周囲の人々は驚きのあまりあごを落とした。なぜなら、その当時の一般的な認識は、LLMは役に立たないゴミしか出せないというものだったからだ。しかし私たちは、他の人が気づいていない事実を知っている：エージェントの出力品質は、投入したTokenの量に依存している。これだけだ。
いくつか実験をすればすぐにわかる。複雑であまり一般的でないプログラミング課題——例えば、制約条件付きの凸最適化アルゴリズムをゼロから実装させる——をエージェントにやらせてみる。最も思考負荷の低い設定で実行し、その後最高レベルの思考設定に切り替え、自分のコードをレビューさせてどれだけバグを見つけられるか試す。中間設定や高設定も試す。すると直感的にわかるのは、バグの数は投入したTokenの量とともに単調に減少していくということだ。
これは理解しやすいだろう？
Tokenが多い＝誤りが少ない。これを一歩進めると、これは基本的にコードレビューの根底にある（簡略化された）考え方と同じだ。全く新しい文脈で、膨大なTokenを投入（例えば、コードの各行を逐次解析し、バグの有無を判断させる）ことで、ほとんど、あるいはすべてのバグを見つけ出すことができる。このプロセスは10回、100回と繰り返し、異なる角度からコードベースを検証すれば、最終的にすべてのバグを洗い出せる。
「Tokenを多く使えばエージェントの品質が向上する」という見解には、もう一つの実証的裏付けがある。全工程をエージェントに任せて本番コードに仕上げられると主張するチームは、基本モデルの提供者か、資金力の非常に豊かな企業だけだ。
だから、もしあなたがエージェントで本番レベルのコードが書けずに悩んでいるなら——率直に言えば、その原因はあなた自身にある。あるいは、あなたの財布にある。
必要なToken量の判断基準
私は以前、問題はあなたの使っているフレームワーク（ハーネス）ではなく、「シンプルに保つ」ことでも優れた成果を出せると述べたし、今もその考えに変わりはない。あなたがその記事を読んで実践しても、エージェントの出力に満足できない場合、ほとんどの場合はTokenの投入量不足が原因だ。
問題を解決するために必要なTokenの量は、その問題の規模、複雑さ、新規性に完全に依存する。
「2+2は何？」のような簡単な問いには多くのTokenは不要だ。
一方、「PolymarketとKalshiのすべての市場をスキャンし、意味的に類似し、同一イベントの前後で清算されるべき市場を見つけ出し、アービトラージの境界を設定し、アービトラージ機会があれば低遅延で自動取引を行う」——これは大量のTokenを必要とする。
私たちの実践から面白い発見があった。
十分なTokenを投入して、規模や複雑さに起因する問題に取り組めば、エージェントはどんなことでも解決できる。言い換えれば、非常に複雑で、多くのコンポーネントやコード行を含むシステムを構築したい場合、これらの問題に十分なTokenを投じれば、最終的には完全に解決できる。
ただし、重要な例外もある。
問題があまりにも新規すぎる場合だ。現段階では、いかなる量のTokenを投入しても、「新規性」の問題は解決できない。複雑さによる誤りをゼロにできるだけのTokenは投入できても、エージェントが未知のものを空から発明することは不可能だ。
この結論には、実はほっと一息つかせられる側面もある。
私たちは膨大なTokenを投入し、ほとんど何の誘導もなくエージェントに機関投資の流れを再現させられるか試した。これは、私たち（量的研究者）がAIに完全に取って代わられるまで何年かかるかを知るためだった。結果、エージェントはまともな機関投資の流れに近づくことはできなかった。理由の一つは、それらの流れが訓練データに存在しなかったからだ。
だから、あなたの問題が新規性の高いものであれば、Tokenを積み上げるだけでは解決できない。自ら探索を導く必要がある。しかし、解決策を確定させたら、あとはTokenを積み重ねて実行させるだけ——コードベースやコンポーネントの複雑さは問題にならない。
シンプルな経験則として、Token予算はコード行数に比例して増やすべきだ。
Tokenを増やすことは何をしているのか
実践では、追加のTokenは主に次の方法でエンジニアリングの質を向上させる。
・同じ試行内でより多くの推論時間を与え、誤った論理を自己発見させる。深く推論させるほど、計画が良くなり、一回の成功確率も高まる。
・複数回の独立した試行を許可し、異なる解法を探索させる。ある解法が他より優れている場合もある。複数の試行を経て、最良のものを選び出せる。
・同様に、より多くの独立した計画試行を行うことで、弱い方向性を捨てて、最も有望な解を保持できる。
・より多くのTokenを使えば、全く新しい文脈で自己批評を行い、改善の機会を与えることもできる。推論の「慣性」にとらわれずに済む。
・さらに私のお気に入りのポイント：Tokenを増やすと、テストやツールを使った検証も可能になる。実行して動作確認を行うことは、答えの正確さを最も確実に保証する方法だ。
この論理が成立するのは、エージェントのエンジニアリング失敗がランダムだからではない。ほとんどの場合、早期に誤った道を選び、そこが本当に通じるかどうかを検証せず（早期段階で）、あるいは誤りを見つけた後の復元やリカバリーに十分な予算を割かなかったことに起因している。
こうした事情だ。Tokenは文字通り、あなたの意思決定の質を買っているのと同じだ。これを研究作業に例えるなら、難問に対して人間が即答した場合、その答えの質は時間的制約とともに低下する。
研究は根本的に、「答えを知る」ことを産み出す活動だ。人間は生物学的に時間を費やしてより良い答えを出す。一方、エージェントは計算時間を費やしてより良い答えを出す。
エージェントの性能を向上させるには
あなたは半信半疑かもしれないが、多くの論文がこれを支持している。正直なところ、「推論」の調整つまみが存在すること自体が、必要な証明だ。
私が特に好きな論文の一つは、少数の精選された推論サンプルで訓練し、その後「待つ」（Wait）と追加して思考を続けさせる方法を導入したものだ。これだけで、あるベンチマークのスコアが50%から57%に向上した。
率直に言えば、エージェントが書くコードに満足できないなら、単一の最高思考設定だけでは不十分だ。
私からの二つの非常にシンプルな解決策を提案する。
簡単な方法一：WAIT（待つ）
今日からすぐにできる最も簡単なこと：自動ループを構築し、エージェントに新しい文脈でN回レビューさせ、問題があれば修正させる。
このシンプルなテクニックでエージェントのエンジニアリング効果が改善されたなら、あなたの問題はTokenの量だけだと理解できる。ならば、Token投入クラブに参加しよう。
簡単な方法二：VERIFY（検証）
エージェントに早期かつ頻繁に自己検証させる。テストを書いて、選択した解法が確実に動作することを証明させる。これは、特に複雑で深くネストされたプロジェクトに有効だ——関数が下流の多くの関数から呼び出される場合など。上流で誤りを捕捉できれば、多大な計算時間（Token）を節約できる。可能なら、構築過程のあらゆる段階に検証ポイントを設ける。
一段落作業が完了したら、メインのエージェントに「完了」と言わせて終わりにせず、別のエージェントに検証させる。異なる思考フローを並行させることで、システム的偏りの原因をカバーできる。
以上だ。この話題についてはもっと書きたいこともあるが、これら二つのポイントを意識し、きちんと実行すれば、あなたの問題の95%は解決できると確信している。シンプルなことを極め、必要に応じて複雑さを積み重ねるのが最良だ。
「新規性」の問題はTokenだけでは解決できないと述べたが、もう一度強調しておきたい。なぜなら、あなたがその落とし穴に早晩はまるからだ。そして、私に泣きついてくるだろう。
あなたの解きたい問題が訓練データに存在しない場合、あなたこそが解決策を提供すべき人間だ。だから、専門知識は依然として非常に重要だ。
16.78M 人気度
252.08K 人気度
15.51K 人気度
1.18M 人気度
5M 人気度
AIエージェント出力がゴミ？問題はあなたがトークンを燃やすのが惜しいからだ
作者：Systematic Long Short
翻訳：深潮 TechFlow
深潮ガイド：この記事の核心論点は一つだけ：AIエージェントの出力品質は投入したToken数に比例する。
著者は単なる理論の話をしているのではなく、今日すぐに使える具体的な方法を二つ提示し、「新規性の問題」というToken積み上げの限界を明確に示している。
エージェントを使ってコードを書いたりワークフローを実行したりしている読者にとって、情報密度も操作性も非常に高い。
はじめに
さて、このタイトルは確かに目を引くが、冗談ではない。
2023年、私たちがまだLLMを使って本番コードを生成していた頃、周囲の人々は驚きのあまりあごを落とした。なぜなら、その当時の一般的な認識は、LLMは役に立たないゴミしか出せないというものだったからだ。しかし私たちは、他の人が気づいていない事実を知っている：エージェントの出力品質は、投入したTokenの量に依存している。これだけだ。
いくつか実験をすればすぐにわかる。複雑であまり一般的でないプログラミング課題——例えば、制約条件付きの凸最適化アルゴリズムをゼロから実装させる——をエージェントにやらせてみる。最も思考負荷の低い設定で実行し、その後最高レベルの思考設定に切り替え、自分のコードをレビューさせてどれだけバグを見つけられるか試す。中間設定や高設定も試す。すると直感的にわかるのは、バグの数は投入したTokenの量とともに単調に減少していくということだ。
これは理解しやすいだろう？
Tokenが多い＝誤りが少ない。これを一歩進めると、これは基本的にコードレビューの根底にある（簡略化された）考え方と同じだ。全く新しい文脈で、膨大なTokenを投入（例えば、コードの各行を逐次解析し、バグの有無を判断させる）ことで、ほとんど、あるいはすべてのバグを見つけ出すことができる。このプロセスは10回、100回と繰り返し、異なる角度からコードベースを検証すれば、最終的にすべてのバグを洗い出せる。
「Tokenを多く使えばエージェントの品質が向上する」という見解には、もう一つの実証的裏付けがある。全工程をエージェントに任せて本番コードに仕上げられると主張するチームは、基本モデルの提供者か、資金力の非常に豊かな企業だけだ。
だから、もしあなたがエージェントで本番レベルのコードが書けずに悩んでいるなら——率直に言えば、その原因はあなた自身にある。あるいは、あなたの財布にある。
必要なToken量の判断基準
私は以前、問題はあなたの使っているフレームワーク（ハーネス）ではなく、「シンプルに保つ」ことでも優れた成果を出せると述べたし、今もその考えに変わりはない。あなたがその記事を読んで実践しても、エージェントの出力に満足できない場合、ほとんどの場合はTokenの投入量不足が原因だ。
問題を解決するために必要なTokenの量は、その問題の規模、複雑さ、新規性に完全に依存する。
「2+2は何？」のような簡単な問いには多くのTokenは不要だ。
一方、「PolymarketとKalshiのすべての市場をスキャンし、意味的に類似し、同一イベントの前後で清算されるべき市場を見つけ出し、アービトラージの境界を設定し、アービトラージ機会があれば低遅延で自動取引を行う」——これは大量のTokenを必要とする。
私たちの実践から面白い発見があった。
十分なTokenを投入して、規模や複雑さに起因する問題に取り組めば、エージェントはどんなことでも解決できる。言い換えれば、非常に複雑で、多くのコンポーネントやコード行を含むシステムを構築したい場合、これらの問題に十分なTokenを投じれば、最終的には完全に解決できる。
ただし、重要な例外もある。
問題があまりにも新規すぎる場合だ。現段階では、いかなる量のTokenを投入しても、「新規性」の問題は解決できない。複雑さによる誤りをゼロにできるだけのTokenは投入できても、エージェントが未知のものを空から発明することは不可能だ。
この結論には、実はほっと一息つかせられる側面もある。
私たちは膨大なTokenを投入し、ほとんど何の誘導もなくエージェントに機関投資の流れを再現させられるか試した。これは、私たち（量的研究者）がAIに完全に取って代わられるまで何年かかるかを知るためだった。結果、エージェントはまともな機関投資の流れに近づくことはできなかった。理由の一つは、それらの流れが訓練データに存在しなかったからだ。
だから、あなたの問題が新規性の高いものであれば、Tokenを積み上げるだけでは解決できない。自ら探索を導く必要がある。しかし、解決策を確定させたら、あとはTokenを積み重ねて実行させるだけ——コードベースやコンポーネントの複雑さは問題にならない。
シンプルな経験則として、Token予算はコード行数に比例して増やすべきだ。
Tokenを増やすことは何をしているのか
実践では、追加のTokenは主に次の方法でエンジニアリングの質を向上させる。
・同じ試行内でより多くの推論時間を与え、誤った論理を自己発見させる。深く推論させるほど、計画が良くなり、一回の成功確率も高まる。
・複数回の独立した試行を許可し、異なる解法を探索させる。ある解法が他より優れている場合もある。複数の試行を経て、最良のものを選び出せる。
・同様に、より多くの独立した計画試行を行うことで、弱い方向性を捨てて、最も有望な解を保持できる。
・より多くのTokenを使えば、全く新しい文脈で自己批評を行い、改善の機会を与えることもできる。推論の「慣性」にとらわれずに済む。
・さらに私のお気に入りのポイント：Tokenを増やすと、テストやツールを使った検証も可能になる。実行して動作確認を行うことは、答えの正確さを最も確実に保証する方法だ。
この論理が成立するのは、エージェントのエンジニアリング失敗がランダムだからではない。ほとんどの場合、早期に誤った道を選び、そこが本当に通じるかどうかを検証せず（早期段階で）、あるいは誤りを見つけた後の復元やリカバリーに十分な予算を割かなかったことに起因している。
こうした事情だ。Tokenは文字通り、あなたの意思決定の質を買っているのと同じだ。これを研究作業に例えるなら、難問に対して人間が即答した場合、その答えの質は時間的制約とともに低下する。
研究は根本的に、「答えを知る」ことを産み出す活動だ。人間は生物学的に時間を費やしてより良い答えを出す。一方、エージェントは計算時間を費やしてより良い答えを出す。
エージェントの性能を向上させるには
あなたは半信半疑かもしれないが、多くの論文がこれを支持している。正直なところ、「推論」の調整つまみが存在すること自体が、必要な証明だ。
私が特に好きな論文の一つは、少数の精選された推論サンプルで訓練し、その後「待つ」（Wait）と追加して思考を続けさせる方法を導入したものだ。これだけで、あるベンチマークのスコアが50%から57%に向上した。
率直に言えば、エージェントが書くコードに満足できないなら、単一の最高思考設定だけでは不十分だ。
私からの二つの非常にシンプルな解決策を提案する。
簡単な方法一：WAIT（待つ）
今日からすぐにできる最も簡単なこと：自動ループを構築し、エージェントに新しい文脈でN回レビューさせ、問題があれば修正させる。
このシンプルなテクニックでエージェントのエンジニアリング効果が改善されたなら、あなたの問題はTokenの量だけだと理解できる。ならば、Token投入クラブに参加しよう。
簡単な方法二：VERIFY（検証）
エージェントに早期かつ頻繁に自己検証させる。テストを書いて、選択した解法が確実に動作することを証明させる。これは、特に複雑で深くネストされたプロジェクトに有効だ——関数が下流の多くの関数から呼び出される場合など。上流で誤りを捕捉できれば、多大な計算時間（Token）を節約できる。可能なら、構築過程のあらゆる段階に検証ポイントを設ける。
一段落作業が完了したら、メインのエージェントに「完了」と言わせて終わりにせず、別のエージェントに検証させる。異なる思考フローを並行させることで、システム的偏りの原因をカバーできる。
以上だ。この話題についてはもっと書きたいこともあるが、これら二つのポイントを意識し、きちんと実行すれば、あなたの問題の95%は解決できると確信している。シンプルなことを極め、必要に応じて複雑さを積み重ねるのが最良だ。
「新規性」の問題はTokenだけでは解決できないと述べたが、もう一度強調しておきたい。なぜなら、あなたがその落とし穴に早晩はまるからだ。そして、私に泣きついてくるだろう。
あなたの解きたい問題が訓練データに存在しない場合、あなたこそが解決策を提供すべき人間だ。だから、専門知識は依然として非常に重要だ。