🧠

LLMエージェントのContext Engineering実践:4戦略でトークンコスト50%削減

に公開

LLMエージェントのContext Engineering実践:4戦略でトークンコスト50%削減

この記事でわかること

  • Context Engineeringの定義と、プロンプトエンジニアリングとの決定的な違い
  • Write / Select / Compress / Isolateの4つの基本戦略と使い分け
  • LangGraphを使った階層的メモリアーキテクチャの実装方法
  • Observation Maskingでトークンコストを50%以上削減する具体的手法
  • 本番運用で起こる**Context Rot(コンテキスト腐敗)**への対処法

対象読者

  • 想定読者: 中級〜上級のLLMアプリケーション開発者
  • 必要な前提知識:
    • Python 3.11+の基本文法
    • LLM API(OpenAI GPT-4o / Claude 4.5 Sonnet)の呼び出し経験
    • LangChainまたはLangGraphの基礎理解

結論・成果

4戦略(Write / Select / Compress / Isolate)を組み合わせることで、トークン使用量を50%以上削減しつつタスク完了率を維持できます。特にObservation Maskingは実装がシンプルかつ効果が大きく、JetBrains Researchの検証では5テスト中4テストでLLM要約より高い費用対効果を示しました。

Context Engineeringとは何か

Context Engineeringは、エージェントの全ライフサイクルにわたるコンテキスト(命令・知識・ツール出力)を戦略的に管理する技術です。Andrej Karpathyは「次のステップに必要な情報だけをコンテキストウィンドウに配置する繊細な技術と科学」と定義しています。2026年現在、エンタープライズAI失敗の約65%がコンテキスト管理の不備に起因しており、エージェント開発の最重要スキルです。

なぜ今Context Engineeringが必要か

単発のチャットとは異なり、AIエージェントは複数ターンのツール呼び出しを連鎖させます。各ツールの出力がコンテキストに蓄積され、数十ターン後にはトークン数が爆発的に増加します。

# エージェントのコンテキスト膨張の例
# 10ターンのツール呼び出し後の典型的なトークン消費
turn_tokens = {
    "system_prompt": 2000,
    "tool_definitions": 3000,    # 10ツール × 300トークン
    "conversation_history": 15000,  # 平均1500トークン/ターン × 10
    "tool_outputs": 25000,       # ファイル読取・API応答など
}
total = sum(turn_tokens.values())  # 45,000トークン
# → 20ターン後には90,000トークン以上に

注意: 200Kトークン対応モデルでもContext Rot(コンテキストが長くなるほど情報想起精度が低下する現象)が発生します。ウィンドウサイズの拡大だけでは根本解決になりません。

4つの基本戦略を実装する

Anthropicの公式ブログでは、Context EngineeringをWrite / Select / Compress / Isolateの4操作に整理しています。実装パターンを見ていきましょう。

Write:外部メモリへの書き出し

エージェントが重要な情報を外部ストレージに永続化する戦略です。コンテキストウィンドウから溢れても失われません。

from langgraph.store.memory import InMemoryStore
from langgraph.graph import StateGraph, MessagesState

# 長期メモリストアの初期化
memory_store = InMemoryStore()

def save_to_memory(state: MessagesState, store):
    """エージェントが学んだ知見を長期メモリに保存"""
    last_message = state["messages"][-1]

    # ネームスペースでユーザーごとに分離
    namespace = ("agent_memory", state.get("user_id", "default"))
    store.put(
        namespace=namespace,
        key=f"insight_{len(state['messages'])}",
        value={
            "content": last_message.content,
            "context": "task_learning",
            "timestamp": "2026-02-18T15:00:00Z",
        },
    )
    return state

なぜWriteが重要か:

  • セッションをまたいで知識を保持できる
  • Anthropicのマルチエージェント研究では、15倍のトークン使用量でも整合性を維持

Select:関連情報の動的取得

必要な情報だけをコンテキストに動的にロードする戦略です。RAGの考え方をエージェントのメモリ管理に応用します。

最初はすべての情報をコンテキストに入れようとしましたが、実際にはJust-in-Time検索(必要時にのみ取得)の方が効果的でした。ファイルパスや識別子だけをコンテキストに保持し、内容はツール呼び出し時に取得する設計です。LangGraphのInMemoryVectorStoreでセマンティック検索を実装すれば、関連度の高いメモリだけを選択的に取得できます。

Compress:コンテキストの圧縮

古い会話履歴を要約して圧縮し、最新の情報を優先する戦略です。古いメッセージをLLMで要約し、最新N件はそのまま保持するのが基本パターンです。

トレードオフ: JetBrains Researchの検証(2025年12月)では、LLM要約による圧縮は50%以上のコスト削減を達成する一方、要約API呼び出し自体に7%以上のオーバーヘッドが発生し、エージェントの実行時間が13〜15%延長されました。

Isolate:サブエージェントへの分離

複雑なタスクを専門的なサブエージェントに委譲し、メインのコンテキストを汚染しない戦略です。各サブエージェントはクリーンなコンテキストで起動し、メインには要約結果のみ返します。Anthropicのマルチエージェントシステムでは、この手法で15倍のトークン使用量でも整合性を維持しています。

Observation Maskingで実践的にコスト削減する

4戦略の中でも、Observation Maskingは最もコスト効率が高い手法です。JetBrains Researchが2025年12月にSWE-bench Verifiedで検証した結果、5テスト中4テストでLLM要約を上回りました。

実装パターン

def apply_observation_masking(
    messages: list,
    window_size: int = 10,  # 最新10ターンは完全保持
) -> list:
    """古いツール出力をプレースホルダーに置換"""
    masked = []
    total_turns = len(messages)

    for i, msg in enumerate(messages):
        turns_from_end = total_turns - i
        if turns_from_end <= window_size:
            # 最新ウィンドウ内: そのまま保持
            masked.append(msg)
        elif hasattr(msg, "tool_output"):
            # 古いツール出力: プレースホルダーに置換
            masked.append(msg.copy(
                content=f"[ツール実行済み: {msg.tool_name}]"
            ))
        else:
            # エージェントの思考・アクション: 保持
            masked.append(msg)

    return masked

実測効果(JetBrains Research, SWE-bench Verified, 500インスタンス):

手法 コスト削減率 タスク完了率への影響 オーバーヘッド
Observation Masking 52%削減 +2.6%改善 なし
LLM Summarization 50%+削減 同等 +7%(API呼出)
管理なし(ベースライン) - ベースライン -

ハマりポイント: ウィンドウサイズが小さすぎると重要なツール出力まで消えます。まずは10で始め、タスク完了率を見ながら調整してください。

よくある問題と解決方法

問題 解決方法
過去の決定を忘れる Write戦略で決定事項を外部メモリに永続化
トークンコスト超過 Observation Masking(window_size=10)を適用
サブエージェント結果の不整合 メインで整合性チェックを実施
長時間タスクで精度低下 定期的なCompressと構造化ノートの併用

まとめと次のステップ

まとめ:

  • Context EngineeringはWrite / Select / Compress / Isolateの4戦略で構成される
  • Observation Maskingが最もコスト効率が高く、52%のコスト削減と+2.6%の完了率改善を同時に達成
  • Context Rotはウィンドウサイズの拡大だけでは解決せず、積極的なコンテキスト管理が必要
  • LangGraphのCheckpointerとStoreで短期・長期メモリを実装可能

次にやるべきこと:

  • LangGraph Memory OverviewでCheckpointerの設定を試す
  • 自分のエージェントにObservation Maskingを適用してトークン使用量を計測する
  • Anthropicの公式ガイドでシステムプロンプト設計のベストプラクティスを確認する

関連記事: LLMコンテキストウィンドウ最適化(ウィンドウサイズの最適化に焦点)

参考

関連する深掘り記事

この記事で紹介した技術について、さらに深掘りした記事を書きました:


GitHubで編集を提案

Discussion