20万トークンあれば十分すぎるほどです! @AmpCodeのブログでは、Claude Opus 4.5モデルの「たった」20万トークンのコンテキストウィンドウの「欠点」について、直感に反しつつも洞察に富んだ視点が示されています。チームは、高品質なコーディングとタスク実行には20万トークンで十分であるだけでなく、過度に長いコンテキストよりも優れている場合が多いと考えています。 「酔い」理論：文脈が多ければ良いとは限らない。著者は鮮明な例えを挙げている。「エージェントにトークンを与えすぎると、彼らは『酔っている』かのように振る舞うだろう。」 • 信号対雑音比の問題: 対話履歴が長すぎると、現在の小さなタスクとは無関係な多くの情報が含まれる可能性があり、モデルの注意が散漫になり、エラーや幻覚が発生しやすくなります。 • パフォーマンスの低下: エージェントが最高のパフォーマンスを発揮できるようにするには、「現在のタスクを完了するために必要なコンテキストのみを提供し、それ以上は提供しない」ことが重要です。 「ショートスレッド」ワークフロー哲学の著者は、すべての作業を何百万ものトークンを含む過度に長い会話に詰め込むことに反対し、代わりに相互接続された短いスレッドのクラスターを使用することを提唱しています。 • タスクの分解: 複雑な開発機能は、複数の個別の小さなタスクに分割する必要があります。 • スレッドはタスクです。各スレッドは小さなタスクに対応しています。例えば、あるスレッドは基本的な実装を担当し、別のスレッドはリファクタリングを担当し、さらに別のスレッドはコードレビューやテストスクリプトの作成を担当します。 • コンテキストの受け渡し: 履歴を常に蓄積するのではなく、参照またはツールを介してスレッド間で必要なコンテキストを渡します。 コストと効率に関する考慮事項: 経済効率: 長い会話は、リクエストごとに大量のトークンを送信するだけでなく、キャッシュ ウィンドウを見逃しやすくなり、コストがさらに増加します。 • 制御性：短いスレッドは管理と追跡が容易で、それぞれのインタラクションには明確な目標があります。この作業方法は、実際には「大きなタスクを小さなタスクに分割する」という古典的なエンジニアリングの原則に立ち返るものです。 この記事は、AIインタラクションにおけるパラダイムシフトを本質的に提唱しており、「画一的な」アプローチから「洗練された管理」への移行を提唱しています。著者は、無限に長いコンテキストウィンドウで混乱を封じ込めようとするのではなく、優れたエンジニアリングプラクティスを通じて、複雑な問題を複数の簡潔で効率的な20万コンテキスト単位に分解する方が効果的であると主張しています。 言い換えれば、20 万文字の制限は欠陥ではなく、ユーザーにタスクを適切に分割することを強制する「機能」です。 ブログアドレス
