HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

トークン節約法を研究するために全トークンを使い果たした話

I burned all my tokens researching how to save tokens (quesma.com)

145 pointsby bkotrys193 コメント

要約

AIエージェントによるリサーチのコストと信頼性の問題に直面した筆者が、既存のサブスクリプションを組み合わせ、モデルを賢く使い分けることで、追加費用なしでリサーチ時間を10倍に延長し、ハルシネーションを削減する手法を開発した経緯を解説しています。最終的に、検証済みの情報を信頼できる知識ベースに集約するパイプラインを構築しました。

全文翻訳

Quesmaでは、AIエージェントの経済性、すなわちエージェント型コーディングの実際のコストと、それに対して何ができるかを研究しています。この研究のために、私は信頼できる知識ベースを構築できるエージェントのパイプラインである、独自のディープリサーチセットアップを実行しています。このセットアップの最初のバージョンは、Claude Max 5xプランの全制限を30分で使い果たしました。この記事は、私がすでに支払っているサブスクリプションのみを使用して、コストと信頼性をどのように修正したか、そしてあなたが同じものをどのように構築できるかについての物語です。 私の目標は、いわゆるトークンエコノミクスの全体像を理解することでした。監視システムが存在するかどうか、チームがAIの支出をどのように管理しているか、そして論文と実世界の双方で、どの最適化ツールやプラクティスが実際に機能するかを知りたかったのです。 私は通常の方法で、/deep-researchから始めました。大きなオープンな質問を与え、それを実行させました。約30分間のリサーチの後、制限に達し、リセットされるまで数時間待たなければなりませんでした。そして、結果は何も得られませんでした。実行は111個のエージェントを起動し、検証のために123個のクレームをキューに入れましたが、制限に達する前に25個しか検証されず、最終的な統合は実行されませんでした。 そのため、個人的に直面しました。そしてこれは少し面白いです。最初の1日から、トークンを最適化する方法を発見しながら、トークンを最適化しなければなりませんでした。実践を通して学ぶこと。私がすでに支払っているすべてのサブスクリプションを使用する。もし30分後にClaude Fable 5がリリースされ、/deep-researchが結果を出さずに大量のトークンを消費しているなら、リサーチをより効果的にするために何ができるでしょうか?私はすでに持っていて支払っているツールの種類について考え始めました。Claude、Codex、Antigravity:3つのサブスクリプション、そして理論上は追加料金なしで3倍のトークン。もし私がこれらのツールすべてを、共有メモリと共に一緒に使用したらどうなるでしょうか?すでにclaude-memプラグインを使用しているので、ローカルでCodexとAntigravityをサポートするように拡張しました。これにより、セッション中に3つのツールすべてが共有メモリを使用できます。あるツールが学んだことは、他のツールも使用できます。 安価なモデルをサブエージェントとして使用する私のデフォルト設定はClaude Codeなので、それをメインハーネスとして使用しました。手動でリサーチを行っている間に、モデルオーケストレーションパターンを発見しました。これはまさにその瞬間に必要としていたものでした。すべてのタスクにFableが必要なわけではありません。Claude Opus 4.8、Claude Sonnet 5、GPT-5.5、Gemini 3.1 Proは、多くのタスクにとってすでに優れたモデルです。Claude Codeをハーネスとして、ネイティブClaudeエージェント、CodexとAntigravityをヘッドレスサブエージェントとして、すべてclaude-memを共有します。 そこで、いくつかのベンチマークとコスト分析をチェックしました。主にターミナルおよびエージェントワーク用のTerminal-Bench、エンドツーエンドのソフトウェアエンジニアリング用のSWE-bench Pro、そしてパフォーマンスと価格の一般的な概要についてはArtificial Analysisです。私はどれも最終的な真実とはみなしませんでした。ベンチマークはそれぞれ独自のものを測定し、数字は毎月変動します。私は単に、誰が何が得意かについての緩やかな出発点が必要だっただけで、複数の異なるモデルを使用することは最初から実験の一部でした。実際の実行後に分割を調整することを期待していました。 役割モデル なぜこれか Claude Sonnet 5 エージェントベンチマークで強力であり、バルク実行には十分安価 検証 Claude Opus 4.8 最も正確なClaudeワーカー。チェックには検索よりも正確さが必要 判断と計画 Claude Fable 5 最も高価なので、計画、分解、紛争解決のみを行う 小さなタスク Claude Haiku 4.5 抽出とフォーマットには安価で高速だが、マルチステップ作業には弱すぎる ツール実行 Codex (GPT-5.5) ターミナルベンチマークで非常に強力。ツールをクローン、インストール、実行、検査する セカンドオピニオン Antigravity (Gemini 3.1 Pro) 異なるモデルファミリーなので、同じ盲点を持たない この分割は私の最初のバージョンではありませんでした。ライブ実行で弱点が見つかるたびに調整しました。フォールバックルールはそれらの失敗から生まれました。 ここで最も良い点は、CodexとAntigravityをFableによってオーケストレーションされるClaudeサブエージェントとして使用できるように準備したことです。両方のヘッドレス性を利用しています。なぜこれがクールなのでしょうか?トークンはCodexとAntigravityのサブスクリプションから消費されるため、追加料金を支払う必要はありませんでしたが、すぐに多くのインテリジェンスを使用できるようになりました。 トリック全体は、Claudeエージェントが他のコマンドのように呼び出すことができる小さなBashスクリプトです。 # run-cli: 他のベンダーのCLIをヘッドレスサブエージェントとして呼び出す # 使用法: run-cli <codex|antigravity> "<プロンプト>" VENDOR="$1" PROMPT="$2" case "$VENDOR" in codex) OUT="$(codex exec --sandbox read-only "$PROMPT")" ;; antigravity) OUT="$(agy --model "Gemini 3.1 Pro (High)" -p "$PROMPT")" ;; esac echo "$OUT" echo "$OUT" | claude-mem-save -s "$VENDOR" # 共有メモリに保存 (ローカルで拡張したclaude-mem) ラッパーは、出力で「usage limit」や「out of credits」メッセージを監視し、特別な終了コードを返します。そして、これが自動フォールバックがClaudeモデルで機能する仕組みです。オーケストレーターはシグナルを見て、代わりにClaudeエージェントで作業を行います。 もう一つ本当に重要なことは、モデルを役割ごとにピン留めすることです。サブエージェントはデフォルトで親のモデルを継承するため、まさにそれがFableの制限を30分で使い果たした理由です。このテクニックにより、Fableのみを使用した場合の初期よりも約10倍長くリサーチを連続して実行できるようになりました。これは、3つのサブスクリプションのいずれかが制限に達するまでエージェントを動作させ続けることができる時間として測定されます。以前は30分のリサーチでしたが、今は追加料金なしで数時間です。そして、CodexまたはAntigravityが独自の制限に達した場合、フレームワークは単にClaudeモデルにフォールバックするため、リサーチは停止しません。 ハルシネーションの削減 コストは最初の問題でしたが、2番目の問題は信頼性でした。私のリサーチフレームワークが登場する前、すべてがFableで行われていた頃は、しっかりしているように見えても真実ではない発見をすることがありました。例えば、リポジトリの誤ったライセンス、出典のない節約額、または引用されたページにない数字などです。 ハルシネーションを減らすために、リサーチフレームワークに、共有される前にすべての発見が通過しなければならない明示的なルールを実装しました。そのうちのいくつかです。 発見した者は決して検証しない。別のモデルまたはエージェントがリンク、引用、数字をチェックする。 URLと一次ソースからの引用なしには、知識ベースに何も着地しない。 ソースページに含まれていない数字を述べない。 このリストは事前に設計されたものではありませんでした。リサーチ中に成長し、検証が新しいクラスの間違いを捉えるたびに、ルールはプロンプトに戻されました。そして、そのようなフレームワークは、チューニングし続ける場合にのみ本当に効果的です。発見を確認し、役に立たないものをフラグ付けし、それをフィードバックしてください。 /deep-researchは最後 コストと信頼性が処理された後、最後のピースは、この物語全体を開始した/deep-researchツールでした。それはまだパイプラインにありますが、最初ではなく最後のステップとしてです。毎日の終わりに、すでに検証を通過した発見の上にそれを実行します。そのため、盲目的にリサーチするのではなく、既存の発見を調べ、それらを深め、混乱を排除し、フレームワークが見逃したギャップを埋めようとします。また、インターネットを探索するのではなく、固定されたクレームのリストを処理するため、この方法ではトークンをより少なく使用します。 最後の実行は61個のエージェントを使用し、22分かかりました。初日と比較してください。111個のエージェントが約30分で全制限を使い果たし、レポートを生成することはありませんでした。同じツールですが、はるかに小さなジョブです。 パイプラインを1枚の写真で:見つける、検証する、判断する、ツールを実行する、ディープバリデートする、そしてウィキに出荷する。 結果:信頼できる知識ベース 検証を通過したすべてが、私がObsidianで保持しているLLMウィキに着地します。KarpathyのLLMウィキパターンに触発されています。リンクされたアトミックノート、スイープを行うエージェント、そして私がルールを設定します。1週間後、価格設定、ツール、ベンチマーク、プラクティスに関する数百の検証済みノートが保持されています。これまでの価格設定、ツール、ベンチマークに関する数百のノート。 自動チェックだけでは十分ではありません。一度、私のトリアージルールは、そのカテゴリで最大級のプロジェクトである56kスターのHeadroomを静かに却下しました。エージェントはすべてを正しく行い、検証はプロジェクトが正当であることを確認し、クレームチェックが