コンテンツにスキップ

出典: https://github.com/microsoft/mcp-for-beginners フォーク元リポジトリ: https://github.com/microsoft/mcp-for-beginners (Microsoft) ライセンス: MIT License

コンテキストエンジニアリング：MCPエコシステムにおける新たな概念

概要

コンテキストエンジニアリングは、クライアントとAIサービス間のやり取りにおいて、情報がどのように構造化され、提供され、維持されるかを探るAI分野の新しい概念です。Model Context Protocol（MCP）エコシステムが進化する中で、コンテキストを効果的に管理する方法の理解がますます重要になっています。本モジュールでは、コンテキストエンジニアリングの概念を紹介し、MCP実装における応用可能性を探ります。

学習目標

このモジュールを修了すると、以下ができるようになります：

  • コンテキストエンジニアリングという新しい概念と、そのMCPアプリケーションにおける役割を理解する
  • MCPプロトコル設計が対処するコンテキスト管理の主要な課題を特定する
  • より良いコンテキスト処理によるモデル性能向上の手法を探る
  • コンテキストの有効性を測定・評価する方法を検討する
  • これらの新しい概念をMCPフレームワークを通じてAI体験の向上に応用する

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

コンテキストエンジニアリングは、ユーザー、アプリケーション、AIモデル間の情報の流れを意図的に設計・管理することに焦点を当てた新しい概念です。プロンプトエンジニアリングのような確立された分野とは異なり、コンテキストエンジニアリングは、AIモデルに適切な情報を適切なタイミングで提供するという独自の課題を解決しようとする実践者によってまだ定義が進められています。

大規模言語モデル（LLM）が進化するにつれて、コンテキストの重要性はますます明らかになっています。提供するコンテキストの質、関連性、構造がモデルの出力に直接影響を与えます。コンテキストエンジニアリングはこの関係性を探求し、効果的なコンテキスト管理の原則を確立しようとしています。

「2025年には、モデルは非常に賢くなっています。しかし、どんなに賢い人間でも、何を求められているのかというコンテキストなしには効果的に仕事をこなせません…『コンテキストエンジニアリング』はプロンプトエンジニアリングの次の段階です。動的なシステムの中でこれを自動的に行うことを意味します。」 — Walden Yan, Cognition AI

コンテキストエンジニアリングには以下のような要素が含まれるかもしれません：

  1. コンテキスト選択：特定のタスクに関連する情報を決定する
  2. コンテキスト構造化：モデルの理解を最大化するために情報を整理する
  3. コンテキスト提供：情報をモデルに送る方法とタイミングを最適化する
  4. コンテキスト維持：時間経過に伴う状態やコンテキストの変化を管理する
  5. コンテキスト評価：コンテキストの有効性を測定し改善する

これらの焦点領域は、LLMにコンテキストを提供するための標準化された方法を提供するMCPエコシステムに特に関連しています。

コンテキストジャーニーの視点

コンテキストエンジニアリングを視覚化する一つの方法は、情報がMCPシステム内で辿る経路を追うことです：

graph LR
    A[User Input] --> B[Context Assembly]
    B --> C[Model Processing]
    C --> D[Response Generation]
    D --> E[State Management]
    E -->|Next Interaction| A

    style A fill:#A8D5BA,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style B fill:#7FB3D5,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style C fill:#F5CBA7,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style D fill:#C39BD3,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style E fill:#F9E79F,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold

コンテキストジャーニーの主要な段階：

  1. ユーザー入力：ユーザーからの生の情報（テキスト、画像、ドキュメント）
  2. コンテキスト組み立て：ユーザー入力をシステムコンテキスト、会話履歴、その他の取得情報と組み合わせる
  3. モデル処理：AIモデルが組み立てられたコンテキストを処理する
  4. 応答生成：モデルが提供されたコンテキストに基づいて出力を生成する
  5. 状態管理：システムがやり取りに基づいて内部状態を更新する

この視点は、AIシステムにおけるコンテキストの動的な性質を強調し、各段階で情報をどのように管理すべきかという重要な問いを投げかけます。

コンテキストエンジニアリングにおける新たな原則

コンテキストエンジニアリングの分野が形成される中で、実践者からいくつかの初期原則が浮かび上がってきています。これらの原則はMCP実装の選択に役立つかもしれません：

原則1：コンテキストは完全に共有する

コンテキストはシステムのすべてのコンポーネント間で断片化せず完全に共有されるべきです。コンテキストが分散されると、システムの一部での意思決定が他の部分と矛盾する可能性があります。

graph TD
    subgraph "Fragmented Context Approach"
    A1[Agent 1] --- C1[Context 1]
    A2[Agent 2] --- C2[Context 2]
    A3[Agent 3] --- C3[Context 3]
    end

    subgraph "Unified Context Approach"
    B1[Agent] --- D1[Shared Complete Context]
    end

    style A1 fill:#AED6F1,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style A2 fill:#AED6F1,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style A3 fill:#AED6F1,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style B1 fill:#A9DFBF,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style C1 fill:#F5B7B1,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style C2 fill:#F5B7B1,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style C3 fill:#F5B7B1,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style D1 fill:#D7BDE2,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold

MCPアプリケーションでは、コンテキストがパイプライン全体をシームレスに流れるよう設計することが推奨されます。

原則2：行動には暗黙の意思決定が伴うことを認識する

モデルが取る各行動は、コンテキストの解釈に関する暗黙の意思決定を含んでいます。複数のコンポーネントが異なるコンテキストで行動すると、これらの暗黙の意思決定が衝突し、一貫性のない結果を招くことがあります。

この原則はMCPアプリケーションに以下の重要な示唆を与えます： - 複雑なタスクは断片化されたコンテキストでの並列実行よりも直線的な処理を優先する - すべての意思決定ポイントが同じコンテキスト情報にアクセスできるようにする - 後のステップが前の意思決定の全コンテキストを参照できるよう設計する

原則3：コンテキストの深さとウィンドウ制限のバランスを取る

会話やプロセスが長くなると、コンテキストウィンドウはやがて溢れます。効果的なコンテキストエンジニアリングは、包括的なコンテキストと技術的制限の間のこの緊張を管理する方法を模索します。

検討されているアプローチ例： - トークン使用量を減らしつつ重要な情報を保持するコンテキスト圧縮 - 現在のニーズに応じて段階的にコンテキストを読み込む方法 - 重要な意思決定や事実を保持しつつ過去のやり取りを要約する手法

コンテキストの課題とMCPプロトコル設計

Model Context Protocol（MCP）は、コンテキスト管理の独自の課題を認識して設計されています。これらの課題を理解することで、MCPプロトコル設計の重要な側面が見えてきます：

課題1：コンテキストウィンドウの制限

ほとんどのAIモデルは固定サイズのコンテキストウィンドウを持ち、一度に処理できる情報量に制限があります。

MCPの設計対応：
- 効率的に参照可能な構造化されたリソースベースのコンテキストをサポート
- リソースはページングされ段階的に読み込める

課題2：関連性の判断

どの情報をコンテキストに含めるべきかを判断するのは難しいです。

MCPの設計対応：
- 必要に応じて動的に情報を取得できる柔軟なツール群
- 一貫したコンテキスト構成を可能にする構造化プロンプト

課題3：コンテキストの持続性

やり取りを跨いだ状態管理にはコンテキストの追跡が必要です。

MCPの設計対応：
- 標準化されたセッション管理
- コンテキストの進化を明確に定義したインタラクションパターン

課題4：マルチモーダルコンテキスト

テキスト、画像、構造化データなど異なる種類のデータは異なる扱いが必要です。

MCPの設計対応：
- 多様なコンテンツタイプに対応したプロトコル設計
- マルチモーダル情報の標準化された表現

課題5：セキュリティとプライバシー

コンテキストには機密情報が含まれることが多く、保護が必要です。

MCPの設計対応：
- クライアントとサーバーの責任範囲を明確化
- データ露出を最小限に抑えるローカル処理オプション

これらの課題とMCPの対応策を理解することは、より高度なコンテキストエンジニアリング技術を探求する基盤となります。

新たに登場するコンテキストエンジニアリング手法

コンテキストエンジニアリングの分野が発展する中で、いくつかの有望な手法が現れています。これらは確立されたベストプラクティスではなく、MCP実装の経験を積む中で進化していく考え方です。

1. シングルスレッドの直線的処理

コンテキストを分散させるマルチエージェント構造とは対照的に、単一スレッドで直線的に処理する方が一貫した結果を生むとする実践者もいます。これは統一されたコンテキストを維持する原則に合致します。

graph TD
    A[Task Start] --> B[Process Step 1]
    B --> C[Process Step 2]
    C --> D[Process Step 3]
    D --> E[Result]

    style A fill:#A9CCE3,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style B fill:#A3E4D7,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style C fill:#F9E79F,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style D fill:#F5CBA7,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style E fill:#D2B4DE,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold

この方法は並列処理より効率が劣るように見えるかもしれませんが、各ステップが前の意思決定を完全に理解した上で進むため、より整合性のある信頼できる結果を生みやすいです。

2. コンテキストのチャンク化と優先順位付け

大きなコンテキストを扱いやすい断片に分割し、重要な部分を優先的に選択する方法。

# Conceptual Example: Context Chunking and Prioritization
def process_with_chunked_context(documents, query):
    # 1. Break documents into smaller chunks
    chunks = chunk_documents(documents)

    # 2. Calculate relevance scores for each chunk
    scored_chunks = [(chunk, calculate_relevance(chunk, query)) for chunk in chunks]

    # 3. Sort chunks by relevance score
    sorted_chunks = sorted(scored_chunks, key=lambda x: x[1], reverse=True)

    # 4. Use the most relevant chunks as context
    context = create_context_from_chunks([chunk for chunk, score in sorted_chunks[:5]])

    # 5. Process with the prioritized context
    return generate_response(context, query)

上記の概念は、大きなドキュメントを扱いやすい断片に分け、最も関連性の高い部分だけをコンテキストとして選ぶ例を示しています。この手法はコンテキストウィンドウの制限内で大規模な知識ベースを活用するのに役立ちます。

3. 段階的コンテキスト読み込み

必要に応じてコンテキストを段階的に読み込む方法。

sequenceDiagram
    participant User
    participant App
    participant MCP Server
    participant AI Model

    User->>App: Ask Question
    App->>MCP Server: Initial Request
    MCP Server->>AI Model: Minimal Context
    AI Model->>MCP Server: Initial Response

    alt Needs More Context
        MCP Server->>MCP Server: Identify Missing Context
        MCP Server->>MCP Server: Load Additional Context
        MCP Server->>AI Model: Enhanced Context
        AI Model->>MCP Server: Final Response
    end

    MCP Server->>App: Response
    App->>User: Answer

段階的読み込みは最小限のコンテキストから始め、必要に応じて拡張します。これにより、単純なクエリではトークン使用量を大幅に削減しつつ、複雑な質問にも対応可能です。

4. コンテキスト圧縮と要約

重要な情報を保持しつつコンテキストのサイズを削減する方法。

graph TD
    A[Full Context] --> B[Compression Model]
    B --> C[Compressed Context]
    C --> D[Main Processing Model]
    D --> E[Response]

    style A fill:#A9CCE3,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style B fill:#A3E4D7,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style C fill:#F5CBA7,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style D fill:#D2B4DE,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold
    style E fill:#F9E79F,stroke:#000000,stroke-width:2px,color:#000000,font-weight:bold

コンテキスト圧縮は以下に注力します： - 冗長な情報の削除
- 長文の要約
- 重要な事実や詳細の抽出
- 重要なコンテキスト要素の保持
- トークン効率の最適化

この手法は長い会話をコンテキストウィンドウ内に収めたり、大量のドキュメントを効率的に処理したりする際に特に有用です。会話履歴の圧縮や要約に特化したモデルを使う実践者もいます。

探索的なコンテキストエンジニアリングの考慮点

コンテキストエンジニアリングの新しい分野を探求する際、MCP実装で考慮すべき点がいくつかあります。これらは必ずしもベストプラクティスではなく、特定のユースケースで改善をもたらす可能性のある探索領域です。

コンテキストの目標を明確にする

複雑なコンテキスト管理を導入する前に、達成したいことをはっきりさせましょう： - モデルが成功するために必要な具体的な情報は何か？
- どの情報が必須で、どれが補助的か？
- パフォーマンスの制約（レイテンシ、トークン制限、コスト）は？

層状コンテキストアプローチを検討する

一部の実践者は、概念的な層に分けてコンテキストを整理する方法で成功を収めています： - コア層：モデルが常に必要とする必須情報
- 状況層：現在のやり取りに特有のコンテキスト
- 補助層：役立つ可能性のある追加情報
- フォールバック層：必要時にのみアクセスされる情報

検索戦略を調査する

コンテキストの効果は情報の取得方法に大きく依存します： - 概念的に関連する情報を見つけるためのセマンティック検索や埋め込み
- 特定の事実を探すためのキーワード検索
- 複数の検索方法を組み合わせたハイブリッドアプローチ
- カテゴリ、日付、ソースに基づくメタデータフィルタリングで範囲を絞る

コンテキストの一貫性を試す

コンテキストの構造や流れはモデルの理解に影響を与えるかもしれません： - 関連情報をまとめて配置する
- 一貫したフォーマットや整理方法を使う
- 論理的または時系列的な順序を維持する
- 矛盾する情報を避ける

マルチエージェント構造のトレードオフを考慮する

多くのAIフレームワークで人気のあるマルチエージェント構造は、コンテキスト管理において以下のような課題があります： - コンテキストの断片化によりエージェント間で意思決定が不整合になる
- 並列処理が調整困難な衝突を生む可能性
- エージェント間の通信オーバーヘッドが性能向上を相殺する
- 一貫性を保つための複雑な状態管理が必要

多くの場合、断片化されたコンテキストを持つ複数の専門エージェントよりも、包括的なコンテキスト管理を行う単一エージェントの方が信頼性の高い結果を生みやすいです。

評価方法を開発する

コンテキストエンジニアリングを改善するために、成功をどう測るかを考えましょう： - 異なるコンテキスト構造のA/Bテスト
- トークン使用量や応答時間のモニタリング
- ユーザー満足度やタスク完了率の追跡
- コンテキスト戦略が失敗するケースの分析

これらの考慮点はコンテキストエンジニアリング分野で活発に探求されている領域です。分野が成熟するにつれて、より明確なパターンや実践が現れるでしょう。

コンテキストの有効性を測る：進化するフレームワーク

コンテキストエンジニアリングが概念として登場する中で、その有効性を測る方法も模索されています。まだ確立されたフレームワークはありませんが、将来の指針となる可能性のある様々な指標が検討されています。

測定の可能な次元

1. 入力効率の観点

コンテキストエンジニアリング関連記事

関連研究

追加リソース

次にやること

免責事項：
本書類はAI翻訳サービス「Co-op Translator」を使用して翻訳されました。正確性の向上に努めておりますが、自動翻訳には誤りや不正確な部分が含まれる可能性があります。原文の言語によるオリジナル文書が正式な情報源とみなされるべきです。重要な情報については、専門の人間による翻訳を推奨します。本翻訳の利用により生じたいかなる誤解や誤訳についても、当方は一切の責任を負いかねます。