AIエージェントの出力がゴミ？ 問題は、あなたがトークンを「燃やす」ことを惜しんでいるからです。
TechFlow厳選深潮セレクト
AIエージェントの出力がゴミ？ 問題は、あなたがトークンを「燃やす」ことを惜しんでいるからです。
問題はプロンプトにありません！
Web3業界の深掘り報道に専念し潮流を洞察著者：Systematic Long Short
翻訳・編集：TechFlow
TechFlow解説：本稿の核心的な主張は、たった一文で表されます。「AI Agentの出力品質は、投入するトークン数に比例して向上する」。
著者は単なる理論的議論にとどまらず、即日実践可能な2つの具体的な手法を提示しています。さらに、「新規性（ノベリティ）の問題」——すなわち、いかなるトークン量を投入しても解決できない領域——を明確に線引きしています。
コード作成やワークフロー実行にAgentを活用中の読者にとって、情報密度も実用性も極めて高い内容です。
序論
さて、このタイトルは確かに目を引きますが——正直に申し上げて、これは冗談ではありません。
2023年、我々がLLMを用いて本番環境向けのコードを実際に生成していた頃、周囲の人々は驚きを隠せませんでした。当時、世間一般の認識は「LLMが出力するのは使い物にならないゴミばかり」というものでした。しかし、我々には他者が気づいていなかった事実がありました。すなわち、「Agentの出力品質は、投入するトークン数の関数である」ということです。これだけです。
ご自身でいくつかの実験を行えば、すぐにその傾向を確認できます。例えば、制約付き凸最適化アルゴリズムをゼロから実装するといった、複雑かつややマイナーなプログラミング課題をAgentに与えます。まず最低限の思考レベルで実行し、次に最高レベルの思考モードに切り替えて、自身のコードを再検討させ、いくつのバグを発見できるかを確認します。中レベル、高レベルもそれぞれ試してみましょう。すると直感的に理解できるでしょう——バグの数は投入トークン量とともに単調に減少します。
これはそれほど難解な話ではありませんね？
トークン数が増える＝エラーが減る。この論理をさらに推し進めれば、それがコードレビュー製品の背後にある（単純化された）核となる考え方です。まったく新しい文脈を与え、膨大なトークンを投入する（例：コードを1行ずつ解析し、各行にバグがないかを判定する）ことで、ほぼすべて、あるいはすべてのバグを検出できるようになります。このプロセスを10回、100回と繰り返し、毎回「異なる視点」からコードベースを検討すれば、最終的にはすべてのバグを掘り当てることができます。
「トークンを多く消費すればAgentの品質が向上する」という考え方は、実証的な裏付けもあります。すなわち、「Agentを用いて本番環境に直接デプロイ可能なコードを完全自動で生成できる」と主張するチームは、基礎モデルの提供元そのものか、資金に極めて余裕のある企業に限られています。
したがって、もし今なおAgentが本番レベルのコードを生成できないことに悩んでいるのであれば——率直に申し上げますが、問題はあなた自身、あるいはあなたの財布にあります。
自分が投入しているトークン数が十分かどうかをどう判断するか
私は以前、問題の原因が使用しているフレームワーク（ハーネス）にあるわけではない、という主旨の記事を書きました。「シンプルさを保つ」ことでも優れた成果は得られると、私は今でもその考えを堅持しています。あなたはその記事を読み、指示通りに実践しましたが、それでもAgentの出力に大きく失望しています。そして私にDMを送信し、既読になっても返信がないことに苛立っています。
この記事こそが、そのDMへの回答です。
あなたのAgentのパフォーマンスが低く、課題を解決できないのは、ほとんどの場合、投入しているトークン数が不足しているためです。
ある問題を解決するために必要なトークン数は、その問題の規模、複雑さ、および新規性に完全に依存します。
「2＋2はいくつですか？」という問いには、わずかなトークンで十分です。
ところが、「PolymarketとKalshiの全マーケットをスキャンし、意味的に類似しており同一イベントの前後に決済されるべきマーケットを特定し、無裁定境界を設定し、裁定機会が発生した際には低遅延で自動取引を実行するボットを作成してください」というような課題には、膨大なトークンが必要です。
実務経験を通じて、興味深い事実を発見しました。
規模および複雑さに起因する問題に対して十分なトークンを投入すれば、Agentは必ず解決できます。言い換えれば、極めて複雑で多数のコンポーネントや大量のコード行を含むシステムを構築したい場合でも、それらの課題に十分なトークンを投下すれば、最終的にはすべて解決可能です。
ただし、小さなが極めて重要な例外があります。
あなたの課題が「過度に新規性が高い」場合、現時点では、いかなるトークン量を投入しても解決できません。「新規性」の問題は、トークン量をいくら増やしても解決されません。十分なトークンにより、複雑さに起因するエラーをゼロまで減らすことは可能ですが、Agentが自ら「知らないものを創造する」ことはできません。
この結論は、むしろ我々を安心させました。
我々は、ほとんど何のヒントも与えずにAgentに機関投資プロセスを再構築させようとする実験に、莫大な労力を費やし、——非常に、非常に、非常に多くの——トークンを消費しました。この実験の一因は、我々自身（定量的ファンドマネージャーとして）がAIによって完全に代替されるまで、あと何年かかるのかを明らかにしようとしたからです。結果として、Agentはまともな機関投資プロセスにさえ近づくことができませんでした。その理由の一つは、このようなプロセスをAgentが一度も学習したことがない——つまり、訓練データに機関投資プロセスに関する情報が一切存在しない——ことに起因すると我々は考えています。
したがって、あなたの課題が新規性が高い場合、トークンをただ大量に投入しても解決しません。あなた自身が探索プロセスを導く必要があります。しかし、一旦実装方針が確定すれば、その後の実行段階においては、トークンを自由に投入して構いません——コードベースがどれほど巨大であれ、コンポーネントがどれほど複雑であれ、問題にはなりません。
ここに簡単な経験則があります：トークン予算はコード行数に比例して増加させるべきです。
追加投入されるトークンは、実際には何をしているのか
実務上、余分なトークンは以下の方法でAgentの工学的品質を向上させます：
• 同一試行内でより長い時間の推論を許容し、Agentが自ら誤った論理を発見する機会を増やす。推論が深くなればなるほど、計画の質が向上し、初回で正解に到達する確率も高まります。
• 複数の独立した試行を許容し、異なる解法の道筋を辿ることを可能にします。中には他の道筋よりも優れたものもあります。複数回の試行を許可することで、最適な解を選択できます。
• 同様に、より多くの独立した計画試行を許容することで、弱いアプローチを放棄し、最も有望な方向性を維持できます。
• より多くのトークンを投入することで、Agentは自身の過去の作業を、まったく新しい文脈で批判的に検討することが可能になり、改善の機会を得られます。これにより、「推論の慣性」に囚われて進展が止まることを防げます。
• 当然ながら、私が最も気に入っている点もあります：より多くのトークンにより、Agentはテストやツールを用いた検証が可能になります。コードを実際に実行して動作確認することは、答えの正しさを確認する最も信頼性の高い方法です。
この論理が成立するのは、Agentの工学的失敗がランダムではなく、ほぼ常に以下のような理由によるからです：早期に誤った道筋を選び、その道筋が本当に有効かどうかを早めに検証しなかった、あるいはエラーを発見した後の復旧・巻き戻しに必要な予算が不足していた、などです。
要するに、トークンとは文字通り「購入した意思決定の品質」なのです。これを研究活動に例えると、誰かが難問に直面して即座に解答を求められた場合、時間的プレッシャーが高まるほど解答の品質は低下します。
研究とは、最終的に「正解を知る」という基本的事実を生み出す行為です。人間は生物学的な時間をかけてより良い解答を生み出し、Agentはより多くの計算時間をかけてより良い解答を生み出します。
あなたのAgentをどう向上させるか
あなたはまだ半信半疑かもしれません。しかし、この主張を裏付ける論文は多数存在します。正直に申し上げて、「推論」調整ノブが存在すること自体が、あなたにとって必要不可欠な唯一の証拠です。
私が特に気に入っている論文では、研究者が少数の厳選された推論サンプルを用いてモデルを訓練し、さらにモデルが停止しようとするタイミングで「Wait（待って）」と強制的に追記することで、思考を継続させる手法を採用しました。この単一の変更により、あるベンチマークテストのスコアが50％から57％へと向上しました。
私はできる限り率直に言います：もし、あなたが「Agentが書くコードの品質はイマイチだ」と不満を述べているのであれば、おそらく単一試行における最高思考レベルでもまだ不十分なのです。
そこで、以下に2つの極めてシンプルな解決策をご提案します。
シンプルな対策①：WAIT（待って）
今日からすぐに実践可能な最も簡単な方法：自動ループを構築します——コード生成後、Agentに新しい文脈でN回のレビューを実施させ、各回で問題を発見した場合には修正させます。
この単純なテクニックがあなたのAgentの工学的成果を向上させたと感じたなら、それは少なくとも「トークン数不足」が原因であることを理解できた証拠です。それならば、ぜひ「トークン燃焼クラブ」にご参加ください。
シンプルな対策②：VERIFY（検証）
Agentが自身の作業をできるだけ早い段階で、かつ頻繁に検証するように促しましょう。選択したアプローチが実際に機能することを示すためにテストを記述します。これは、極めて複雑で深く入れ子になったプロジェクトに特に有効です——ある関数が下流の多数の他の関数から呼び出される可能性がある場合、上流でエラーを検出できれば、その後の膨大な計算時間（トークン）を節約できます。したがって、可能であれば、構築プロセス全体にわたって随所に「検証チェックポイント」を設置しましょう。
あるコード断片の作成が完了し、メインのAgentが「完了」と宣言したとしても、別個のAgentにその内容を再度検証させます。互いに無関係な思考フローを用いることで、体系的バイアスの源をカバーできます。
以上が基本です。このトピックについてさらに多くのことを語れますが、この2点をしっかり認識し、着実に実行すれば、95％の問題を解決できると私は確信しています。シンプルなことを徹底的にやり抜き、必要に応じて複雑さを積み重ねていく——これが私の信念です。
先ほど「新規性」はトークンでは解決できない問題だと述べましたが、もう一度強調させていただきます。なぜなら、あなたはいずれこの落とし穴に陥り、トークンをいくら投入しても効果がないと嘆いて私に連絡してくることになるからです。
あなたの課題が訓練データに含まれていない場合、真に解法を提示すべきはあなた自身です。ゆえに、ドメイン知識は依然として極めて重要です。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@systematicls
