原文（日本語に翻訳）
レート制限によってテキスト出力を一切生成する前に打ち切られたサブエージェントが、正しく失敗として扱われず空の結果を返していた問題を修正し、明確に失敗を報告するようにしました
原文（英語）
Fixed subagents cut off by a rate limit before producing any text output returning an empty result instead of failing cleanly
概要
サブエージェント（Taskツールなどで起動される委任先のエージェント）がレート制限に達し、しかもテキスト出力を1つも生成しないうちに処理が打ち切られた場合、以前のバージョンではその状態が「成功したが結果が空」として親エージェントに返されていました。これでは親エージェントが失敗を検知できず、空の結果をあたかも有効な回答であるかのように扱ってしまう恐れがありました。この修正により、そのようなケースは明確な失敗として報告されるようになり、親エージェントが適切にリトライやエラー処理を行えるようになりました。
基本的な使い方
修正前（Before）:
親エージェント: サブエージェントにタスクを委任
サブエージェント: レート制限に到達、テキスト出力なしで打ち切り
→ 親エージェントには「空の結果」が返る
→ 親エージェントは失敗と気づかず、空の結果を基に処理を続けてしまう修正後（After）:
親エージェント: サブエージェントにタスクを委任
サブエージェント: レート制限に到達、テキスト出力なしで打ち切り
→ 親エージェントには明確な失敗（エラー）として報告される
→ 親エージェントはリトライや代替手段の検討などの対応を取れる実践例
大量のサブエージェントを並列実行するワークフロー
複数のTaskを並列で走らせて要約・調査を行わせるようなワークフローでは、一部のサブエージェントがレート制限に引っかかって早期に打ち切られることがあります。以前はその失敗が「空の結果」として紛れ込み、後続処理で欠落に気づきにくいという問題がありましたが、修正後は失敗として明示されるため検知しやすくなります。
レート制限が発生しやすい高頻度利用時のセッション
短時間に多くのサブエージェント呼び出しを行うヘビーな使い方をしている場合、レート制限による打ち切りの発生頻度自体は変わりませんが、打ち切られたことが正しく失敗として伝わるようになったことで、親エージェントが「結果が空だったのでタスクが完了していないと判断してリトライする」といった適切な振る舞いを取りやすくなります。
CI/自動化パイプラインでサブエージェントの結果を検証している場合
サブエージェントの出力を後続処理でパースするような自動化パイプラインでは、空の結果が「正常終了だが中身が空」なのか「実際は失敗」なのかを区別できることが重要です。この修正により、失敗ケースが明確にエラーとして伝播するため、パイプライン側でのハンドリングがしやすくなります。
注意点
- 類似の修正はv2.1.199でも行われており（「レート制限やサーバーエラーで打ち切られたサブエージェントが親に部分的な作業結果を返さず静かに失敗していた問題」の修正）、本項目（v2.1.200）はその中でも「テキスト出力が1つも生成されないまま打ち切られた」特殊なケースを対象としています。
- レート制限自体を回避する修正ではないため、頻繁にレート制限に達する場合は、並列実行数を減らす、リトライ間隔を調整するなどの根本的な対策も引き続き有効です。
- 親エージェント側でサブエージェントの失敗をどう処理するか（リトライする、ユーザーに報告するなど）は、依然としてタスクの設計に依存します。