mcpField

Context Manager

github.com/eddiebe147エージェントワークフロー53 回インストール
リポジトリ

Context Manager について

Context Manager は、Claude との長い会話を管理するスキルです。コンテキスト使用量を把握し、重要な決定を残しながら、履歴の要約や整理を支援します。

主な機能

  1. 01コンテキスト使用量と増加の確認
  2. 02決定事項とプロジェクト状況の要約
  3. 03古い情報や重複情報の特定
  4. 04コンテキスト整理の計画
  5. 05効率を高める情報の再構成

活用シーン

  1. 01大きな機能に着手する前の確認
  2. 02長い開発セッションの要約
  3. 03解決済みデバッグ情報の整理
  4. 04新しいスレッド用の要約作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/eddiebe147/claude-settings --skill context-manager

インストール後、Claude Code で/context-managerを入力して読み込まれたか確認します。

詳細

コンテキストマネージャー

コンテキストマネージャーのスキルは、長時間のセッションを通じてClaudeの有効性を維持できるよう、会話コンテキストの最適化を支援します。コンテキストウィンドウの使用状況を追跡し、コンテキストを要約または整理するタイミングを特定して、トークン制限内で関連情報にアクセスできる状態を保つための会話の構成を支援します。

会話履歴が膨大になる複雑な複数日にわたるプロジェクトでは、このスキルが不可欠です。何を保持し、何を要約し、何を破棄するかを判断するのに役立ち、コンテキスト制限に達することなく、重要な決定やプロジェクトの状態をClaudeが把握し続けられるようにします。

長時間の開発セッション中、新しい大規模な機能に着手する前、またはコンテキストの肥大化によってパフォーマンスが低下していると感じたときは、このスキルを積極的に活用してください。

主なワークフロー

ワークフロー 1:コンテキストの健全性を監視する
  1. 確認する項目:
    • トークン数
    • 上限に対する使用率
    • 直近の増加率
  2. コンテキストの構成を分析します:
    • コードの量
    • 会話の量
    • ドキュメントの量
  3. 問題のある箇所を特定します:
    • 重複した情報
    • 古くなった参照
    • 無関係な脱線
  4. リスクレベルを評価します:
    • 緑:使用率50%未満、健全
    • 黄:使用率50~75%、監視が必要
    • 赤:使用率75%超、対応が必要
  5. 必要に応じて対応策を提案します
  6. 状況をユーザーに報告します
ワークフロー 2:長い会話を要約する
  1. 会話履歴を確認します
  2. 重要な情報を抽出します:
    • 決定事項
    • 解決した問題
    • 現在のプロジェクトの状態
    • 未解決の質問
    • 次のステップ
  3. トピックまたは時系列ごとに整理します
  4. 簡潔な要約を作成します
  5. ユーザーに確認します
  6. 要約を使って新しいスレッドを始めるよう提案します
ワークフロー 3:不要なコンテキストを整理する
  1. 削除候補を特定します:
    • 解決済みの問題
    • 放棄したアプローチ
    • 一時的なデバッグ情報
    • 新しい情報に置き換えられた情報
  2. 重要度ごとに分類します:
    • 安全に削除できる
    • 要約できる
    • 必ず保持する
  3. 整理計画をユーザーに提案します
  4. 承認された削除を実行します
  5. 重要なコンテキストを保持します
  6. 整理後の一貫性を確認します
ワークフロー 4:コンテキストの構成を最適化する
  1. 現在のコンテキストの構成を分析します
  2. 非効率な点を特定します:
    • 会話内に散在する情報
    • 重複した説明
    • 構成の不足
  3. 効率化のために再構成します:
    • 関連情報をまとめる
    • 参照用のセクションを作成する
    • 簡潔な形式を使う
  4. 次の情報について、外部ドキュメントの作成を提案します:
    • アーキテクチャ上の決定
    • API 仕様
    • 設定の詳細
  5. 情報を会話内に記載する代わりに、外部ドキュメントへのリンクを追加します
  6. 効率が改善されたことを確認します

クイックリファレンス

操作コマンド/トリガー
コンテキストの状態を確認「コンテキストウィンドウを確認」または「コンテキストの状況は?」
会話を要約「この会話を要約」
要約を使って新しく始める「要約を使って新しいスレッドを開始」
古いコンテキストを整理「古いコンテキストをクリア」または「会話を整理」
コンテキストの構成を最適化「コンテキストを最適化」
重要な決定を保持「重要な決定を記録」
コンテキストの使用量を推定「コンテキストをどのくらい使用していますか?」

ベストプラクティス

  • 積極的に監視する:パフォーマンスの問題が発生するまで待たないでください

    • 大きな機能に着手する前にコンテキストを確認します
    • 長時間のデバッグセッションの後に監視します
    • 長期にわたるプロジェクトでは毎週確認します
  • 定期的に要約する:区切りのよいタイミングで履歴を圧縮します

    • 機能開発の終了時
    • 大きな問題を解決した後
    • コンテキストを切り替える前(開発 → デプロイ)
  • 静的な情報を外部化する:変更されない内容はファイルに移します

    • アーキテクチャのドキュメント
    • API 仕様
    • コードスタイルガイド
    • 参考資料
  • 構造化された形式を使う:情報を高密度で確認しやすくします

    • 説明文の代わりに表を使います
    • 段落の代わりに箇条書きを使います
    • 説明文の代わりにコードブロックを使います
  • 決定事項を残す:「なぜ」を必ず記録します

    • なぜこのアプローチを選んだのか
    • なぜ代替案を採用しなかったのか
    • どのような制約が決定に影響したのか
  • 不要な情報は思い切って破棄する:一時的な内容は容赦なく削除します

    • デバッグ中の試行錯誤
    • 失敗した実験
    • 解決済みの問題
    • 古くなった計画
  • 適切なタイミングで新しく始める:新しい会話を始めるべきタイミングを把握します

    • 大きなマイルストーンの達成後
    • 関連のない作業に切り替えるとき
    • コンテキストの使用率が 75% を超えたとき
    • パフォーマンスが低下したとき
  • 外部に記録する:永続的なナレッジにはファイルを使います

    • プロジェクトの状態には PIPELINE_STATUS.md
    • アーキテクチャの選択には DECISIONS.md
    • タスクリストには TODO.md
    • オンボーディングには README.md

コンテキスト最適化の戦略

戦略 1:階層的な要約
Long conversation →
  Detailed summary (50% reduction) →
    Executive summary (80% reduction) →
      Key decisions (95% reduction)
戦略 2:時間ベースのウィンドウ化
Keep in context:
- Last 1 hour: Full detail
- Last 4 hours: Summarized
- Last day: Key decisions only
- Older: Link to external docs
戦略 3:トピックベースの分割
Separate threads for:
- Feature development
- Bug investigation
- Deployment/ops
- Architecture discussion

Link between threads as needed
戦略 4:段階的な情報開示
Start with:
- Current task context only

Add on demand:
- Related decisions
- Relevant code
- Background information

Remove when done

コンテキストの健全性チェックリスト

大きなタスクに着手する前に、以下を確認してください。

  • コンテキストの使用率が 75% 未満
  • 最近の決定事項が記録されている
  • 古くなった情報が削除されている
  • 現在のプロジェクトの状態が明確
  • 次のステップが特定されている
  • 関連するファイルやドキュメントへのリンクがある
  • デバッグの記録が整理されている

コンテキストの問題を示す警告サイン

以下の兆候に注意してください。

  • 応答が遅くなる:大きなコンテキストを処理しています
  • 情報が無視される:AI が最近のコンテキストを見落としています
  • 繰り返しが増える:AI が既知の情報を再度説明しています
  • 一貫性が失われる:AI が以前の決定事項を忘れています
  • トークン上限の警告が出る:厳格な上限に近づいています
  • 精度が低下する:これまで確かな領域で誤りが発生しています

外部メモリの戦略

以下の情報はコンテキストではなく、ファイルに移してください。

情報の種類最適な保存先
プロジェクトの概要README.md
アーキテクチャの決定事項ARCHITECTURE.md または ADR
API コントラクトOpenAPI 仕様またはスキーマファイル
現在のプロジェクトの状態PIPELINE_STATUS.md または TODO.md
設定.env、設定ファイル
コードスタイルのルール.eslintrc、prettier.config.js
デプロイの手順DEPLOYMENT.md または CI/CD 設定
チームの決定事項DECISIONS.md または議事録

コンテキストのテンプレート

プロジェクト状態の要約テンプレート
## Project: [Name]
- **Status**: [Current pipeline stage]
- **Current focus**: [What we're working on]
- **Last completed**: [Recent achievement]
- **Next steps**: [Immediate tasks]
- **Blockers**: [What's preventing progress]
- **Key decisions**: [Recent important choices]
決定事項ログのテンプレート
## Decision: [Topic]
- **Date**: [When]
- **Context**: [Why we needed to decide]
- **Options considered**: [Alternatives]
- **Choice**: [What we decided]
- **Rationale**: [Why this choice]
- **Consequences**: [Trade-offs accepted]
セッション要約テンプレート
## Session Summary: [Date]
- **Duration**: [How long]
- **Accomplished**: [What we built/fixed]
- **Decisions**: [Choices made]
- **Issues found**: [Problems discovered]
- **Next session**: [Where to continue]

上級者向け:コンテキスト圧縮の手法

上級ユーザー向け:

  1. 参照を使う:コードを貼り付ける代わりにリンクします

    • 「/src/utils/data.ts の関数 processData を参照してください」
    • 次の代わりに:[関数全体を貼り付ける]
  2. AI のメモリを活用する:ナレッジグラフに保存します

    • エンティティ間の重要な関係
    • プロジェクト固有の用語
    • チームメンバーの役割と専門知識
  3. 略語を作る:最初に定義し、以後は一貫して使います

    • 「FE」= フロントエンド、「BE」= バックエンド
    • 「MR」= マージリクエスト、「PR」= プルリクエスト
    • プロジェクト固有の略語
  4. 差分形式を使う:ファイル全体ではなく変更点を示します

    • 特にコードレビューで有効です
    • 変更前と変更後を比較します
  5. 関連する情報をまとめる:関連項目をグループ化します

    • すべての環境変数を 1 つのブロックにまとめます
    • すべての API エンドポイントを表にまとめます
    • すべての依存関係をリストにまとめます

コメント