Deep Agents v0.7がターンごとのトークンを65%削減

Deep Agents v0.7は、ターンごとの基本入力トークンを65%削減します。 つまり、各呼び出しの固定プロンプトのオーバーヘッドが減り、API支出が下がり、タスクの重要な部分に使えるコンテキスト領域が増えます。

このアップデートを要約すると、次のとおりです。

• デフォルトの基本システムプロンプトを廃止
• 組み込みツールの説明を短縮
• Todoはデフォルトで付加されない
• ミドルウェアは一括同梱ではなく、目的に応じて選択
• 削減効果はモデルではなくハーネスから生まれる

平たく言えば、エージェントが10回呼び出しを行うと、以前は同じ固定ラッパーが10回送信されていました。v0.7では、そのラッパーがデフォルトで大幅に小さくなっています。そのため、特にファイルの読み書きのような単純なタスクでは、各ターンのリクエストが軽量になります。

特に重要なのは次の点です。

• コストは llm_calls × input_tokens_per_call に比例する
• 以前の構成では、タスクに不要な場合でも計画、ファイルシステム、サブエージェントのテキストが送信されていた
• 新しい構成では制御が開発者側に移り、ジョブに合うプロンプト、ツール、ミドルウェアを選べる
• 最大の削減は、基本プロンプトの削除とツール説明の短縮から生まれる
• 固定オーバーヘッドが各ステップで繰り返されるため、長時間のマルチエージェントワークフローほど効果が大きい

変更前後を簡単に比較すると、次のようになります。

結論： v0.7の本質はモデルの変更より、プロンプト管理の徹底にあります。 ハーネスを軽量に保てば、**65%**の削減効果をすべて維持できます。ミドルウェアやツールを再び積み上げれば、その効果の一部を手放すことになります。

これがアップデートの核心であり、以降の内容の土台になります。

構成可能なハーネスで変わったこと

65%のトークン削減は、より賢いモデルを使った結果ではなく、ハーネスが各ターンに注入する内容を変えた結果です。簡単に言えば、v0.7は、以前すべてのリクエストに付随していた大量のデフォルトテキストを取り除きます。

基本システムプロンプトを廃止し、ツール説明を短縮

v0.7以前のハーネスは、タスクに必要がない場合でも、デフォルトのシステムプロンプト、長いツール説明、計画ミドルウェア、サブエージェントロジックをすべてのリクエストに含めていました。v0.7ではハーネスを構成可能にすることでこの設定を変更し、各ターンに何を注入するかを開発者が決められるようにしました。

最大のオーバーヘッド源は、デフォルトの基本システムプロンプトと、長い組み込みツール説明でした。基本プロンプトには計画ツール、ファイルシステムツール、サブエージェント向けの指示が含まれ、毎ターン送信されていました。v0.7ではこのプロンプトが削除され、代わりに開発者がタスクに合うプロンプトテキストを指定できます。

ls、read_file、write_fileなどのユーティリティに対する組み込みツール説明も短縮されました。ツールの動作は変わりません。各リクエストを包む固定テキストが減っただけです。どちらの変更も基盤モデルには影響しません。各ターンが抱えていたトークン負荷を減らすものです。

Todoはオプトインとなり、ミドルウェアを明示的に選択可能

v0.7以前はtodoListMiddlewareがデフォルトで付加されていたため、計画用テキストが毎ターン送信されていました。v0.7ではTodoがオプトインになりました。複数ステップの計画によってタスクが改善される場合だけ追加できます。

同じ変更は、残りのミドルウェアスタックにも当てはまります。FilesystemMiddlewareとSubAgentMiddlewareは、デフォルトで一括同梱されなくなりました。開発者は必要なミドルウェアだけを組み合わせられます。ファイル読み取りタスクならサブエージェントロジックを省けます。検証ワークフローでは、役立つ場合にだけチェックリストミドルウェアを追加できます。

オーケストレーションがより明示的になる仕組み

実務上の変化はシンプルです。設定が暗黙のデフォルトから明示的な構成へ移りました。どのツールを表示するか、どのミドルウェアを実行するか、システムプロンプトに何を書くかをハーネスに決めさせる代わりに、開発者自身が判断します。プロンプトの組み立て、ツールの可視性、ミドルウェアをタスクごとに制御できるようになりました。

これらの変更は、以下のデフォルトエージェントスタックに表れています。^[2]

トークン使用量の変更前後

ハーネスの変更は、各ターンに送られるペイロードへすぐに反映されます。削減効果は、ユーザープロンプトやモデルを変えることではなく、固定リクエストの外枠を小さくすることで生まれます。

v0.7以前のデフォルトエージェントのターン

v0.7以前は、計画、ファイルシステム、サブエージェントの足場が、使用されない場合でも各ターンに含まれていました。Todoテキストとミドルウェアプロンプトもデフォルトで含まれていたため、大きな固定ペイロードが毎ターン繰り返されていました。

v0.7以降のデフォルトエージェントのターン

v0.7以降では、単純なファイル読み取りタスクは必要なツールとミドルウェアだけを送信します。そのため、余分なオーバーヘッドがターンをまたいで繰り返されません。基本システムプロンプトは削除され、ツール説明は短くなり、ファイル読み取りタスクが不要な計画テキストやサブエージェントテキストを抱えなくなりました。

Aaron Jewittが指摘するように、エージェントのコストはllm_calls × input_tokens_per_callに比例します。^[1]

トークン削減の内訳

65%の削減は、次のように生まれます。

最大の削減は、基本プロンプトの削除とツール説明の短縮から生まれます。そのため、ミドルウェアを選択的に使い、表示するツールを絞ることが、日常のワークフローで明確な差を生みます。

次のセクションでは、タスクに必要なハーネス要素だけを選び、この削減効果を維持する方法を説明します。

開発者向けハーネス構成パターン

トークン削減を確保したら、次はタスクごとに軽量なハーネスプロファイルを選びます。削減効果は、小さなプロンプトと引き締まったハーネスのデフォルト設定から生まれます。Deep Agents v0.7では、モデルではなくハーネスが、ターンごとのトークンオーバーヘッドの大部分を占めます。つまりDeep Agents v0.7の最適化では、モデル選択よりハーネスの組み立て方が重要です。

タスクに必要なミドルウェアだけを選ぶ

ゲーティング、計画、状態管理が必要なタスクでのみミドルウェアを使います。短いタスクでは、こうした追加レイヤーはオーバーヘッドを増やすだけです。

ルールはシンプルです。タスクに必要な最小限のミドルウェアスタックから始めます。 ツールにも同じ考え方が当てはまります。現在のタスクが実際に必要とするツールだけを公開してください。

ツールの可視性を制限し、説明を短くする

すべてのツールを毎ターン表示することは、ターンごとの入力を膨らませる最も速い方法の一つです。ツールの可視性を絞ることで、プロンプトを小さく保てます。

ツール説明を短くすれば、プロンプトサイズをさらに削減できます。簡潔で正確な説明はプロンプトを小さくし、大量の余分なコンテキストなしでモデルが適切なツールを選びやすくします。

オプトイン式Todoとプロファイル別デフォルトを使う

Todo管理は、エージェントが多数のステップにわたって進捗を追跡する長期タスクに役立ちます。短い単一ステップの作業では、Todoはオーバーヘッドを増やすだけで、見返りがありません。

長期タスクではTodoをオプトインにし、エージェントクラスごとに軽量または高機能なデフォルトを設定します。軽量なエージェントクラスのデフォルトは単純なエージェントで65%の効果を維持し、計画を多用するワークフローには高機能なプロファイルを残します。

こうした選択によって、65%の削減が日常利用での低コストと高速な反復につながるかが決まります。

v0.7アップデートがコスト、速度、規模にもたらす意味

推論コストの削減と反復ループの高速化

小さくなったリクエストの外枠は、長いワークフローの各ターンで効果を積み上げます。トークンコストはマルチターン実行を通して累積するため、軽量なハーネスは最初のターンだけ費用を抑えるものではありません。その後の各ターンでも開始点を小さく保ち、会話が長くなるほど差が広がります。

実際には、削減効果は次の箇所に表れます。

小さなペイロードは、反復ループも短縮します。プロンプトの変更をテストしたり、新しいツール設定を試したりするとき、軽いリクエストはより速く返ってきます。日々の開発作業における多くの停滞を取り除けます。

長時間・マルチエージェントワークフローのスケーラビリティ向上

複数のエージェントが同じワークフロー予算を共有する場合、同じトークン削減の価値はさらに高まります。固定オーバーヘッドは、マルチエージェントシステムで気づきにくい予算消費要因です。各エージェントが過大なハーネスを抱えていれば、そのオーバーヘッドは連携するすべてのターンに掛け合わされます。

軽量なハーネスパッケージは、各エージェントの負荷を小さく保ちます。これによりスループットが向上し、ワークフローの途中でコンテキスト上限やレート制限に達する可能性が下がります。

コンテキストウィンドウが埋まると、性能が低下することがあります。軽量なハーネスは、実際のタスクデータに使えるコンテキスト領域を各エージェントへより多く残します。平たく言えば、圧縮や要約ロジックが早期に介入しなくても、長時間のワークフローがより長く精度を維持できます。

呼び出しごとのオーバーヘッド削減は、ターン数、エージェント数、またはその両方が多いワークフローで最も重要です。65%のトークン削減は、呼び出しごとのコストを下げます。しかし規模の面でより大きな利点は、v0.7の明示的なオーケストレーションモデルから生まれます。終わりのないループではなく明確な停止条件を使うことで、エージェントはタスク完了までの総呼び出し回数を減らせます。

Deep Agents v0.7リリースの要点

Deep Agents v0.7は、ハーネスを構成可能にすることで、コストと品質を改善します。ミドルウェアの選択、ツールの可視性、プロファイル別デフォルトによって、ワークフローが削減効果をすべて維持できるか、余分なオーバーヘッドによって多くを失うかが決まります。

構成が主な最適化レバーです。 そして、ターン数、エージェント数、またはその両方が多いワークフローで最も重要になります。

よくある質問

実際のワークフローで65%のトークン削減をすべて維持するにはどうすればよいですか？

ハーネス構成は、一度設定したら終わりの作業ではなく、変化し続けるシステムとして扱います。まずトークン使用量とLLM呼び出し回数を測定してください。次にハーネスを使い、厳密な動作ルールを固定します。

冗長な推論ループを止めるには、**PreCompletionChecklistMiddleware**を使います。モデルが必要とするコンテキストとツールだけを渡すには、LocalContextMiddlewareを使います。システム指示が実行をまたいで安定するよう、プロンプトキャッシュも追加してください。

トークン使用量が急増したら、挙動のずれを監視し、ハーネスルールを引き締めます。

Todoや追加ミドルウェアを引き続き使うべきタスクはどれですか？

エージェントが複雑で複数部分からなる問題に取り組むときは、**todoListMiddleware**を使います。作業の進行に合わせて、完了した内容と注意が必要な内容を追跡するのに役立ちます。

write_todosツールを使うようプロンプトで指示すると、エージェントは新しい情報に応じて進捗を更新できます。長く難しいワークフローを追いやすくし、エージェントが正しい方向を維持するのに役立ちます。

小さなハーネスはエージェントの品質や信頼性に影響しますか？

デフォルトでは影響しません。小さく調整されたハーネスは、より良いコンテキスト処理、ツールへの処理移譲、構造化されたプロンプトパッケージによってターンごとのトークンを減らしながら、信頼性を維持し、場合によっては改善できます。

これらの削減を、検証ループや完了前チェックリストなどの決定論的ガードレールと組み合わせれば、品質を保てます。エージェントが重要なタスクデータに集中し、応答前に作業を再確認できるようになります。