コンテキスト管理

ほとんどのモデルは標準的な 200K のコンテキストウィンドウを使用します。

• Claude 4.5 Sonnet - 複雑なタスク向けにバランスが取れている
• Claude 4.5 Haiku - 高速かつ効率的
• GPT-5 - 推論に優れている（Beta）
• GPT-5-Codex - コーディング向けに最適化（Beta）

容量:

• 合計で約 200,000 トークンのメモリ容量
• ほとんどの開発タスクや中規模プロジェクトに十分

含まれるもの:

• 会話内のすべてのメッセージ
• コンテキストに読み込まれたファイルの内容
• ツールの出力と応答
• システムプロンプトと指示
• MCP サーバーの定義

パフォーマンス:

• 上限に近づくと大幅に低下する
• コンテキスト過負荷の兆候（応答の遅延、出力精度の低下）に注意する
• 最適なパフォーマンスのために、より頻繁にコンテキストをリセットする

Claude Sonnet 4.5 は、明示的に選択した場合、または入力が 200K トークンを超えた場合に、拡張コンテキスト（1M トークン）を提供します。

容量:

• 合計 1,000,000 トークンのメモリ
• 標準モデルの5倍

メリット:

• 大規模なコードベース全体をチャンク分割せずに読み込むのに最適
• 大規模プロジェクトにおけるコンテキスト管理の懸念をほぼ解消
• コンテキストの上限に達するまで、より長く作業できる
• セッションのリセット回数が少なくて済む

使用するタイミング:

• 1000+ ファイルを含む大規模なコードベース
• プロジェクト全体にまたがる複雑な複数ファイルのリファクタリング
• 複数の関連タスクにまたがる長時間の開発セッション
• コンテキスト管理のオーバーヘッドを最小限に抑えたい場合

兆候:

• 応答の精度が下がる、または不完全になる
• 会話の前半の重要な詳細が抜け落ちる
• 長いセッションを通じて一貫性を保つのが難しくなる
• 最近の変更やコンテキストについて混乱する

具体例:

• セッションの前半ですでに却下した解決策を提案する
• 20 メッセージ前に確立したコーディング規約を無視する
• 会話の前半で行った変更と矛盾するコードを生成する
• 以前に議論したプロジェクトアーキテクチャに合わない実装を提案する

主な兆候: Verdent の応答の精度や一貫性が低下する

兆候:

• 応答時間が明らかに遅くなる
• 応答開始までの処理遅延が長くなる
• メッセージ間のレイテンシが増加する

具体例:

• 通常 5-10 秒で済む応答が 30+ 秒かかるようになる
• メッセージ送信後、入力中インジケーターが表示されるまでに目に見える遅延がある
• ストリーミング応答の開始がいつもよりかなり遅くなる
• ツールの実行（ファイル読み込み、検索）に明らかに時間がかかる

主な兆候: 応答に通常よりかなり長い時間がかかる

兆候:

• すでに提供した情報を確認し直すよう求める
• 前半で確立したパターンや規約を忘れる
• 以前に議論したファイルやコードを参照できない
• プロジェクト構造について重複する質問をする

具体例:

• 30 メッセージ前に React を指定したのに「どのフレームワークを使っていますか?」と尋ねる
• すでに @-mentioned 何度も伝えたファイルパスを再度求める
• セッション開始時に確立した命名規則を覚えていない
• 理由を添えてすでに却下した概念やアプローチを再度説明する

主な兆候: Verdent がすでに議論したことを尋ねる

兆候:

• 200K トークン上限の最後の5分の1に近づいている（約 160K+ トークン使用）
• 多くのファイル読み込みやツール出力を伴う長い会話
• 重いツール定義を持つ複数の MCP サーバーが有効になっている
• 大きなファイルがコンテキストに繰り返し読み込まれている

具体例:

• セッションが 100+ メッセージで 2+ 時間続いている
• 会話を通じて @-mentions で 20+ ファイルを読み込んだ
• 複数の大きなファイル（それぞれ >1000 行）がコンテキストに含まれている
• 広範なツール定義を持つ 5+ 個の MCP サーバーが有効になっている
• 会話に多くの grep/検索結果やファイル読み込みが含まれている

主な兆候: ファイルやツールを多用する非常に長いセッション

• 応答時間が明らかに遅くなる
• 応答の精度が下がる、または一貫性がなくなる
• Verdent が前半のコンテキストやパターンを忘れる
• コンテキストウィンドウの上限に近づいている（低下の兆候に注意）

対処: 品質が低下したら新しいセッションを開始する

• 無関係な機能やモジュール間で切り替える
• 1つのTodoを完了して次に進む
• メモリを多く消費するタスク（大規模なリファクタリング、アーキテクチャ作業）の後
• 調査フェーズから実装フェーズへ移行する

対処: 新しい主要タスクには新しいセッションを使う

• 完成した機能をバージョン管理にコミットした後
• 開発ワークフローの論理的なチェックポイント間
• テスト・検証・コミットのサイクルの後

対処: コミット → テスト → 新しいセッション

• 大きな新機能に着手する前
• 会話履歴が非常に長くなったとき
• 複数ファイルの変更を完了した後
• 異なる種類の作業の間（デバッグ → 機能開発）

対処: コンテキストが低下する前に、先回りして新しいセッションを開始する

小さく焦点を絞ったファイル:

• 少数の大きなファイルよりも、多数の小さなファイルの方がコンテキストを効率的に消費する
• 関連するモジュールのみを読み込みやすい
• コンテキストに含める内容をより細かく制御できる
• 大きなファイル全体を読み込む必要性が減る

明確なディレクトリ構造:

• 論理的な構成により、Verdent が関連ファイルを見つけやすくなる
• 機能ベースまたはモジュールベースの構成により、コンテキストのターゲティングが向上する
• 無関係なコードを読み込む必要性が減る

Documentation in AGENTS.md:

• プロジェクトドキュメントが、多くのサンプルファイルを読み込む必要性を置き換える
• アーキテクチャのパターンを一度記述すれば、繰り返し参照できる
• コーディング標準を一元的にドキュメント化できる
• 探索的なファイル読み込みによるコンテキストのオーバーヘッドを減らす

メリット:

• コードベース全体を読み込まずに、独立したモジュールに取り組める
• 明確な境界により、焦点を絞ったセッションが可能になる
• モジュールの境界に沿って作業を自然に分割できる

問題点:

• モノリシックなファイルにより、大きなコンテキスト全体の読み込みを強いられる
• 構造が不明確なため、アーキテクチャを理解するのに多くのファイルを読み込む必要がある
• 同じファイルに関心事が混在し、無関係なコードでコンテキストを浪費する

影響:

• コンテキスト上限の問題が頻発する
• 無関係なコードでトークンを浪費する
• 特定のモジュールに作業を切り分けるのが難しい
• セッションのリセットがより頻繁に必要になる

よくあるアンチパターン:

• 複数の関心事を含む単一の 5000+ 行のファイル
• ルートに 100+ ファイルが並ぶフラットなディレクトリ構造
• 機能・モジュール間の明確な分離がない
• 一元化されたドキュメントの欠如

リファクタリングのアプローチ:

• 大きなファイルを、小さく焦点を絞ったモジュールに分割する
• ファイルタイプではなく、機能やドメインで構成する
• 明確なディレクトリ階層を作る
• 共有コードを別のモジュールに抽出する

ドキュメント:

• アーキテクチャのパターンを記した AGENTS.md を作成する
• コーディング標準を一元的にドキュメント化する
• モジュールごとに README ファイルを維持する
• 設計上の決定をドキュメントとして残す

コンテキストへの影響: 標準の 200K トークンのコンテキストでは、整理されたワークスペースかどうかで、上限に頻繁に達するか、めったに達しないかが分かれます。1M トークンのコンテキストでは、構成の重要性は下がりますが、それでも効率は向上します。

パフォーマンスの兆候に注意する:

• セッションを通じて応答の品質と速度を監視する
• 応答が遅くなったり精度が下がったりしたら気づく
• 会話の長さとファイル数を手動で把握する
• 先回りして新しいセッションを開始する

監視すべき項目:

• 応答の精度と一貫性
• 最初の応答までの時間（入力中インジケーターの遅延）
• 応答全体の完了時間
• 会話の前半の詳細を記憶しているか

サブエージェントの管理:

• 必要ないときは未使用のカスタムサブエージェントを無効化する
• 有効なサブエージェントごとに、システムのオーバーヘッドに定義が追加される
• 実際に使用しているサブエージェントのみを有効にしておく
• 特定のタスクに必要なときに、必要に応じて再度有効化する

対処のしきい値: 2-3 の低下の兆候に気づいたら、新しいセッションを開始するときです。

チャンク分割のアプローチ:

• 大きなタスクを小さな単位に分割する
• 関連する作業を焦点を絞ったセッションで完了する
• 長い会話で異なる種類のタスクを混在させない
• メモリを多く消費する作業では、コンテキストウィンドウの最後の5分の1を避ける

セッション管理:

• 主要なタスクの間に新しいセッションを開始する
• コミット後にコンテキストをクリアする: テスト → 検証 → コミット → 新しいセッション
• 複数ステップの計画にはTodoを使う
• Todoの項目を、それぞれ焦点を絞った別々のセッションで進める

ベストプラクティスのパターン:

1. Plan Mode でタスクを計画する
2. 新しいセッションで焦点を絞った実装を実行する
3. 変更をテストして検証する
4. バージョン管理にコミットする
5. 次のタスクのために新しいセッションを開始する

タスクの分離: デバッグを機能開発から、調査を実装から分離してください。

戦略的な読み込み:

• 必要なときのみ @-mentions を使って明示的にファイルを含める
• 多くのファイルを読み込む代わりに AGENTS.md ドキュメントを活用する
• 大規模プロジェクトでは一度に1つのモジュールに取り組む
• 大きなファイルを、小さく焦点を絞ったコンポーネントに分割する

ファイル選択の原則:

• 変更や直接の参照が必要なファイルのみを含める
• サンプルファイルの読み込みよりもドキュメントを優先する
• 不要になったファイルはコンテキストから削除する
• 先回りではなく、必要になったタイミングでファイルを読み込む

大きなファイルの扱い:

• 500 行を超えるファイルの分割を検討する
• ユーティリティやヘルパーを別ファイルに抽出する
• 明確なモジュール境界を使う
• AGENTS.md にファイル間の関係をドキュメント化する

最適化のワークフロー:

パフォーマンスを監視 → セッションの肥大化を特定 → 未使用のサブエージェントを無効化 → 先回りして新しいセッションを開始 → タスクの品質に集中

日々の実践:

• 主要な機能ごとに新しいコンテキストで開始する
• 頻繁にコミットし、コミット間でリセットする
• 各セッションを単一の目的に集中させる
• 自然な区切りでコンテキストの使用状況を見直す

For Extended Context (1M tokens): Claude Sonnet 4.5 のより大きなコンテキストウィンドウでは、最適化の重要性は下がります。積極的なコンテキスト管理よりも、タスクの品質に集中してください。とはいえ、良い習慣は依然として効率と整理を向上させます。