context-engineering

コンテキストエンジニアリング

Agent Skills™ の一部（googleadsagent.ai™ 提供）

説明

コンテキストエンジニアリングとは、トークン消費を最小限に抑えながら、エージェントの出力品質を最大化するための技術です。すべてのトークンがコストとレイテンシに影響する世界では、エージェントのコンテキストウィンドウに入れる情報を的確に選別する能力が、本番環境向けシステムと高価なおもちゃを分けます。このスキルは、googleadsagent.ai™ プラットフォーム全体で培われた技術を体系化したものです。このプラットフォームでは、Buddy™ は通常、20 万トークンのウィンドウ内で動作しながら、ドメインエキスパート級の精度を維持しています。

核心となる洞察は、コンテキストは単に「モデルに送るもの」ではなく、作業メモリであり、ほかのシステムリソースと同じ厳密さで設計する必要があるということです。情報密度の最適化、体系的な読み込み順序、段階的な情報開示パターンにより、エージェントは適切な情報を適切なタイミングで確実に受け取れます。設計の不十分なコンテキストは、幻覚、指示の逸脱、コストの膨張につながります。

このスキルでは、コンテキストを有限の管理対象リソースとして扱う方法をエージェントに教えます。測定し、圧縮し、優先順位を付け、再利用できる状態にします。ここで紹介する技術は、Claude Code、Cursor、Codex、Gemini のハーネス全般に適用できます。

使用する場面

• 会話が長くなるにつれて、エージェントの応答品質が低下する場合
• 本番ワークロードでトークンコストが予算の上限を超えている場合
• エージェントが集中力を失わずに大規模なコードベースを推論する必要がある場合
• コンテキストウィンドウ全体を使い切らずに、ドメイン知識を注入する必要がある場合
• 複数ステップのワークフローで、ステップ間に必要な状態だけを引き継ぐ必要がある場合
• コンテキストウィンドウの飽和や希薄化が原因で、エージェントが幻覚を起こす場合

仕組み

graph TD
    A[Raw Context Sources] --> B[Relevance Scoring]
    B --> C{Score > Threshold?}
    C -->|Yes| D[Compression Engine]
    C -->|No| E[Context Archive]
    D --> F[Priority Queue]
    F --> G[Token Budget Allocator]
    G --> H[Context Window Assembly]
    H --> I[Agent Execution]
    I --> J[Context Reclamation]
    J --> K{Session Active?}
    K -->|Yes| B
    K -->|No| L[Session Summary → Memory]

コンテキストのライフサイクルは、生のソース（ファイル、過去のメッセージ、ツール出力、ナレッジベース）が関連性のスコアリング処理を通過するところから始まります。しきい値を下回る項目は破棄せずにアーカイブし、必要に応じて取得できるようにします。関連性の高い項目は、意味内容を保ちながらトークン数を削減する圧縮エンジンに送られます。優先キューでは、圧縮された項目を新しさ、重要度、タスクとの関連性に基づいて並べ替えます。トークン予算アロケーターは厳格な上限を適用し、組み立てられたコンテキストウィンドウが目標予算を超えないようにします。エージェントの実行後、コンテキストの再利用処理によって、以降のターンで不要になった項目を特定します。

実装

トークン予算の適用：

class ContextBudget {
  constructor(maxTokens = 180000) {
    this.maxTokens = maxTokens;
    this.reservedForOutput = 20000;
    this.reservedForSystem = 5000;
    this.available = maxTokens - this.reservedForOutput - this.reservedForSystem;
    this.allocations = new Map();
  }

  allocate(category, tokens) {
    const currentUsage = this.currentUsage();
    if (currentUsage + tokens > this.available) {
      return this.evictAndAllocate(category, tokens);
    }
    this.allocations.set(category, (this.allocations.get(category) || 0) + tokens);
    return true;
  }

  evictAndAllocate(category, needed) {
    const sorted = [...this.allocations.entries()]
      .sort((a, b) => a[1] - b[1]);
    for (const [cat, tokens] of sorted) {
      if (cat === category) continue;
      this.allocations.delete(cat);
      if (this.available - this.currentUsage() >= needed) break;
    }
    return this.allocate(category, needed);
  }

  currentUsage() {
    return [...this.allocations.values()].reduce((sum, t) => sum + t, 0);
  }
}

段階的な情報開示パターン：

function buildProgressiveContext(task, depth = 0) {
  const layers = [
    { level: 0, content: getTaskSummary(task), tokens: 200 },
    { level: 1, content: getRelevantFiles(task), tokens: 2000 },
    { level: 2, content: getFileContents(task), tokens: 10000 },
    { level: 3, content: getFullDependencyTree(task), tokens: 40000 },
  ];
  return layers
    .filter(layer => layer.level <= depth)
    .map(layer => layer.content);
}

要約によるコンテキスト圧縮：

def compress_context(messages, budget_tokens):
    """Compress conversation history to fit within token budget."""
    total = count_tokens(messages)
    if total <= budget_tokens:
        return messages

    system_msgs = [m for m in messages if m["role"] == "system"]
    recent = messages[-4:]
    middle = messages[len(system_msgs):-4]

    summary = summarize_messages(middle)
    compressed = system_msgs + [{"role": "system", "content": f"Prior conversation summary: {summary}"}] + recent

    if count_tokens(compressed) > budget_tokens:
        return system_msgs + recent[-2:]
    return compressed

ベストプラクティス

1. 最適化の前に測定する — 圧縮技術を適用する前に、カテゴリ（システムプロンプト、会話履歴、ツール出力、ナレッジ）ごとのトークン使用量を計測します。
2. 出力用の余裕を確保する — コンテキストウィンドウの 15～20% をモデルの応答用に常に確保します。ウィンドウを上限まで使うと、必ず切り詰めが発生します。
3. 叙述形式より構造化形式を優先する — JSON、YAML、表形式は、文章による説明よりもトークンあたりの情報密度が高くなります。
4. 段階的な情報開示を適用する — まず要約を使い、詳細は必要に応じて読み込みます。多くのエージェントのターンで必要なのは、利用可能なコンテキストの一部にすぎません。
5. コンテキストの再利用処理を実装する — 各ツール呼び出しの後、ツール出力全体が引き続き必要か、要約に置き換えられるかを評価します。
6. ホットコンテキストとコールドコンテキストを分ける — 頻繁に参照する項目（システム指示、現在のタスク）はすべてのターンに含め、あまり参照しない項目は取得機能の背後にアーカイブします。
7. コンテキストスキーマをバージョン管理する — プロンプトやナレッジベースの進化に合わせて、どのコンテキスト設定がどの品質結果をもたらしたかを追跡します。
8. 限界条件でテストする — コンテキスト使用率が 50%、80%、95% のときにエージェントの動作を検証し、性能低下の曲線を把握します。

プラットフォームの互換性

機能	Claude Code	Cursor	Codex	Gemini CLI
コンテキスト予算の適用	✅ 完全対応	✅ 完全対応	✅ 完全対応	✅ 完全対応
段階的な開示	✅ ネイティブ対応	✅ スキル経由	✅ プロンプト経由	✅ プロンプト経由
トークンのカウント	✅ Anthropic API	✅ 拡張機能経由	✅ tiktoken	✅ Vertex API
コンテキストの圧縮	✅ 完全対応	✅ 完全対応	✅ 完全対応	✅ 完全対応
セッションの要約	✅ フック	✅ ルール	✅ 指示	✅ システムプロンプト

Mythos Preview リファレンス

Mythos Preview の評価では、Anthropic は各ファイルを 興味深く、脆弱性に関連するロジックが含まれている可能性に応じて 1～5 で評価します（例：定数のみのファイルと、ネットワーク解析や認証を扱うファイル）。その後、すべてのパスに均等に予算を費やすのではなく、評価の高いファイルから順に処理します。

大規模なコーパスには、同じ考え方を取り入れましょう。あらかじめシグナル密度が高そうなものをスコアリングし、降順に並べ替えて、その順番で読み込むか作業を割り当てます。そうすれば、コンテキストウィンドウとエージェントの作業時間を、まず 最も有望な ソースに割り当てられます。出典：Mythos Preview。

関連スキル

• Cognitive Scaffolding - コンテキスト予算内の各トークンの価値を最大化する、注意を考慮したコンテンツ配置
• Prompt Architecture - 段階的な開示とトークン予算の割り当てを組み込んだ、階層型プロンプト設計
• Anthropic Tool Mastery - コンテキストを考慮したキャッシュと圧縮の戦略が必要となる、ツール結果の管理

キーワード

コンテキストエンジニアリング、トークン最適化、コンテキストウィンドウ、情報密度、段階的開示、コンテキスト圧縮、ワーキングメモリ、トークン予算、コンテキストライフサイクル、エージェントスキル

---

© 2026 googleadsagent.ai™ | Agent Skills™ | MIT License