エージェントの文脈分離、出力制限、ファイルへの外部化、独立した検証を組み合わせます。Strands AgentsとAgentCore上のデータ分析システムを参照実装として説明しました。 会話の短縮だけでなく、計算の再実行と最終成果物の監査を設計に含めます。削減率は特定の実装例の値であり、業務全体の費用削減とは分けて評価します。 長い分析を文脈の容量だけで支えない AWSは11月4日、実運用のエージェントで文脈を管理する方法を解説しました。参照例は、Strands Agents SDKとAmazon Bedrock AgentCoreを使うオープンソースのDeep Insightです。データ分析から図表、検証、報告書まで進むと、会話にコードや結果が蓄積します。情報をすべて一つの文脈に残す方式では、容量の超過や費用、重要情報の見落としが課題になります。記事は対策を、構成、指示、道具、検証の四つの層へ整理しています。個別の技法だけでなく、前の層に残る問題を次の層で補う設計として説明しています。 共有する要約と外部に置く実体を分ける 第一の層では、担当ごとに文脈を分け、全履歴ではなく短い結果や計画を渡します。第二の層では、返す情報量や形式を指示し、分析コードはそれぞれ単独で動くようにします。第三の層は、重い内容をファイルへ置く方法です。共通処理を再利用し、必要な技能の説明だけを読み込みます。記事の実装例では、コードを書いて実行する一つの道具にまとめることで、スクリプトが文脈へ加えるトークンを約95％減らしたと説明しています。また、技能の必要時読み込みでシステム指示を約97％縮小しています。これらは特定の処理を対象とした値です。システム全体のトークン数や料金が同率で減るという測定ではありません。削減の対象を明示して比較することが必要になります。 計算と引用の独立確認を最終層に置く 第四の層では、別の担当が元データから計算し直し、報告書を監査します。Validatorは計算の記録を使って数値を再検証し、Auditorは最終文書と参照情報を照合します。担当間で文脈を分けると、誤りもそのまま次へ渡る可能性があるためです。実務では、要約に残す情報と、ファイルから再取得する情報の境界が論点になると見られます。計算結果だけでなく、元データ、手順、出典の対応を残せるかが重要です。記事は文脈の要約機能や選択的なキャッシュも紹介しています。呼び出し頻度に応じた設定を使うため、全担当へ同じ最適化を適用する構成ではありません。検証の負担と推論費用を含めて測る必要があると考えられます。再試行の負担も評価対象になります。 参照実装の効果を自社の処理で測り直す Deep Insightの構成を採用する際は、文脈を分ける前後で処理の成功率や再実行の回数を比べることが考えられます。ファイルの受け渡しが増える場合、保存先の権限や古い成果物の混入も確認点になると見られます。今回の記事は実装例の紹介であり、あらゆる分析業務で同じ結果を保証するものではありません。次の判断点は、自社のデータと報告書で、計算と引用を最後まで追跡できるかです。短い会話だけを成功の指標にしないことが論点です。