# コンテキスト管理 (/ja/docs/verdent-for-vscode/best-practices/context)
> より良い結果を得るための効果的なコンテキスト管理
***
効果的なコンテキスト管理により、Verdent は適切なタイミングで適切な情報を得られ、コンテキストの過負荷によるパフォーマンス低下を回避できます。
### 学べること [#学べること]
* コンテキストウィンドウとその上限を理解する
* 最適なコンテキストのために戦略的にファイルを選択する
* コンテキストの過負荷を認識して対応する
* パフォーマンス向上のためにコンテキストをリセットするタイミング
* ワークスペースの構成がコンテキストに与える影響
***
## コンテキストウィンドウを理解する [#コンテキストウィンドウを理解する]
Verdent for VS Code のコンテキストウィンドウのサイズは、使用するモデルによって異なります。
ほとんどのモデルは標準的な `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+` ファイルを含む大規模なコードベース
* プロジェクト全体にまたがる複雑な複数ファイルのリファクタリング
* 複数の関連タスクにまたがる長時間の開発セッション
* コンテキスト管理のオーバーヘッドを最小限に抑えたい場合
***
## 戦略的なファイル選択 [#戦略的なファイル選択]
コンテキストの使用を最適化し、上限への到達を回避するために、ファイル選択は戦略的に行いましょう。
少ないファイルから始め、必要なときだけ追加してください。Verdent は会話中にいつでも追加のファイルを読み込めます。
### @メンションで明示的に含める [#メンションで明示的に含める]
```
@filename.js
```
Verdent は関連ファイルを自動的に読み込みますが、`@-mentions` は正確なコンテキストを保証します。選択は厳密に行い、現在のタスクに直接関連するファイルのみを含めてください。
### コンテキストの使用状況を監視する [#コンテキストの使用状況を監視する]
* セッションが長くなるにつれてパフォーマンスが低下しないか注意する
* 会話の長さとファイル数を把握しておく
* 可能であれば、不要なファイルをコンテキストから削除する
### コンテキストの過負荷を避ける [#コンテキストの過負荷を避ける]
* 大きなタスクを、タスクあたりのファイル数が少ない小さな単位に分割する
* 関連ファイルのみに集中する。コードベース全体を一度に読み込まない
* MCP サーバー管理を使って、未使用の連携を無効化する
### ベストプラクティス [#ベストプラクティス]
* 変更や参照が必要なファイルのみを含める
* サンプルファイルを読み込む代わりに、既存のパターンを参照する
* 大規模なコードベースでは、一度に1つのモジュールに取り組む
* 多くのファイルを読み込む代わりに、プロジェクトドキュメント（`AGENTS.md`）を使用する
* メモリを多く消費するタスクでは、コンテキストウィンドウの最後の5分の1を避ける
### 拡張コンテキスト（1M トークン）の場合 [#拡張コンテキスト1m-トークンの場合]
ファイル選択の重要性は大幅に下がります。多くの場合、プロジェクトのリポジトリ全体を上限に達することなく読み込めます。
***
## コンテキストの過負荷を認識する [#コンテキストの過負荷を認識する]
**兆候:**
* 応答の精度が下がる、または不完全になる
* 会話の前半の重要な詳細が抜け落ちる
* 長いセッションを通じて一貫性を保つのが難しくなる
* 最近の変更やコンテキストについて混乱する
**具体例:**
* セッションの前半ですでに却下した解決策を提案する
* `20` メッセージ前に確立したコーディング規約を無視する
* 会話の前半で行った変更と矛盾するコードを生成する
* 以前に議論したプロジェクトアーキテクチャに合わない実装を提案する
**主な兆候:** Verdent の応答の精度や一貫性が低下する
**兆候:**
* 応答時間が明らかに遅くなる
* 応答開始までの処理遅延が長くなる
* メッセージ間のレイテンシが増加する
**具体例:**
* 通常 `5-10` 秒で済む応答が `30+` 秒かかるようになる
* メッセージ送信後、入力中インジケーターが表示されるまでに目に見える遅延がある
* ストリーミング応答の開始がいつもよりかなり遅くなる
* ツールの実行（ファイル読み込み、検索）に明らかに時間がかかる
**主な兆候:** 応答に通常よりかなり長い時間がかかる
**兆候:**
* すでに提供した情報を確認し直すよう求める
* 前半で確立したパターンや規約を忘れる
* 以前に議論したファイルやコードを参照できない
* プロジェクト構造について重複する質問をする
**具体例:**
* `30` メッセージ前に React を指定したのに「どのフレームワークを使っていますか?」と尋ねる
* すでに `@-mentioned` 何度も伝えたファイルパスを再度求める
* セッション開始時に確立した命名規則を覚えていない
* 理由を添えてすでに却下した概念やアプローチを再度説明する
**主な兆候:** Verdent がすでに議論したことを尋ねる
**兆候:**
* `200K` トークン上限の最後の5分の1に近づいている（約 `160K+` トークン使用）
* 多くのファイル読み込みやツール出力を伴う長い会話
* 重いツール定義を持つ複数の MCP サーバーが有効になっている
* 大きなファイルがコンテキストに繰り返し読み込まれている
**具体例:**
* セッションが `100+` メッセージで `2+` 時間続いている
* 会話を通じて `@-mentions` で `20+` ファイルを読み込んだ
* 複数の大きなファイル（それぞれ `>1000` 行）がコンテキストに含まれている
* 広範なツール定義を持つ `5+` 個の MCP サーバーが有効になっている
* 会話に多くの grep/検索結果やファイル読み込みが含まれている
**主な兆候:** ファイルやツールを多用する非常に長いセッション
**対処すべきタイミング:** パフォーマンスの低下が主な兆候です。Verdent の応答の精度が下がる、遅くなる、または一貫性がなくなった場合は、新しいセッションを開始するか、コンテキスト管理の戦略を使用してください。
Verdent の応答が曖昧になったり繰り返しが多くなったりした場合、コンテキストの過負荷が発生している可能性があります。会話をリセットして、フルパフォーマンスを回復してください。
**注意:** `1M` トークンのコンテキスト（Claude Sonnet 4.5）では、これらの問題ははるかに少なくなります。
***
## コンテキストをリセットするタイミング [#コンテキストをリセットするタイミング]
* 応答時間が明らかに遅くなる
* 応答の精度が下がる、または一貫性がなくなる
* Verdent が前半のコンテキストやパターンを忘れる
* コンテキストウィンドウの上限に近づいている（低下の兆候に注意）
**対処:** 品質が低下したら新しいセッションを開始する
* 無関係な機能やモジュール間で切り替える
* 1つのTodoを完了して次に進む
* メモリを多く消費するタスク（大規模なリファクタリング、アーキテクチャ作業）の後
* 調査フェーズから実装フェーズへ移行する
**対処:** 新しい主要タスクには新しいセッションを使う
* 完成した機能をバージョン管理にコミットした後
* 開発ワークフローの論理的なチェックポイント間
* テスト・検証・コミットのサイクルの後
**対処:** コミット → テスト → 新しいセッション
* 大きな新機能に着手する前
* 会話履歴が非常に長くなったとき
* 複数ファイルの変更を完了した後
* 異なる種類の作業の間（デバッグ → 機能開発）
**対処:** コンテキストが低下する前に、先回りして新しいセッションを開始する
**ベストプラクティスのワークフロー:** 最小単位の作業を完了 → テスト → コミット → コンテキストをクリア → 次のタスクのために新たに開始。
**注意:** コンテキストをリセットするには新しいセッションを開始します。`1M` トークンのコンテキストでは、クリアの必要性ははるかに少なくなります。
***
## ワークスペース構成の影響 [#ワークスペース構成の影響]
ワークスペースの構成は、コンテキストがどれだけ効率的に使われるか、また Verdent がコードベースをどれだけ容易に把握できるかに直接影響します。
**小さく焦点を絞ったファイル:**
* 少数の大きなファイルよりも、多数の小さなファイルの方がコンテキストを効率的に消費する
* 関連するモジュールのみを読み込みやすい
* コンテキストに含める内容をより細かく制御できる
* 大きなファイル全体を読み込む必要性が減る
**明確なディレクトリ構造:**
* 論理的な構成により、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 のより大きなコンテキストウィンドウでは、最適化の重要性は下がります。積極的なコンテキスト管理よりも、タスクの品質に集中してください。とはいえ、良い習慣は依然として効率と整理を向上させます。
***
## よくある質問 [#よくある質問]
標準モデル（Claude 4.5 Sonnet、Haiku、GPT-5、GPT-5-Codex、MiniMax-M2）は `200K` トークンのコンテキストウィンドウを持ち、ほとんどのタスクに十分です。Claude Sonnet 4.5 は、`1000+` ファイルを含む大規模なコードベース、複雑な複数ファイルのリファクタリング、長時間の開発セッション向けに、拡張された `1M` トークンのコンテキスト（5倍の大きさ）を提供します。`1M` のコンテキストは、入力が `200K` トークンを超えたときに自動的に有効になるほか、明示的に選択することもできます。
コンテキストをリセットするには、手動で新しいセッションを開始する必要があります。Verdent は自動的にコンテキストをクリアしません。ベストプラクティス: 最小単位の作業を完了し、テストし、バージョン管理にコミットした後にリセットしてください。`1M` トークンのコンテキストでは、リセットの必要性ははるかに少なくなります。
固定のファイル上限はありません。ファイルのサイズと合計トークン数によります。`200K` のコンテキストでは、`20+` 個の大きなファイル（それぞれ `>1000` 行）を読み込むのは避けてください。現在のタスクに直接関連するファイルに集中しましょう。`@-mentions` を選択的に使い、多くのサンプルファイルを読み込む代わりに `AGENTS.md` ドキュメントを活用してください。`1M` のコンテキストでは、ファイル選択の重要性は大幅に下がります。
セッション内のすべて: 会話内のすべてのメッセージ、コンテキストに読み込まれたファイルの内容、ツールの出力（grep/検索結果、ファイル読み込み）、システムプロンプトと指示、そして MCP サーバーの定義です。これらはそれぞれ、合計コンテキスト容量からトークンを消費します。
いいえ。コンテキストのリセットは、会話履歴と読み込まれたファイルをメモリからクリアするだけです。実際のコードの変更、コミット、ファイルの修正は保持されます。安全のため、コンテキストをリセットする前に必ず作業をバージョン管理にコミットしてください。リセット → 新しいセッションを開始 → 次のタスクの作業を続行。
***
## 関連項目 [#関連項目]
効果的なプロンプトを書くためのベストプラクティス
実行モードとそのリソースへの影響を理解する
トークン使用量、クレジット、パフォーマンスを監視する