概要
https://chrisloy.dev/post/2025/08/03/context-engineering
詳細内容
## コンテキストエンジニアリング
https://chrisloy.dev/post/2025/08/03/context-engineering
**Original Title**: Context engineering
LLMが複雑なシステムの意思決定コンポーネントとなるにつれて、「プロンプトエンジニアリング」は、すべての入力トークンを動的かつ意図的に考慮する「コンテキストエンジニアリング」へと進化しており、LLMを神託ではなくアナリストとして扱うべきだと著者は主張する。
**Content Type**: Technical Reference
**Language**: en
**Scores**: Signal:5/5 | Depth:5/5 | Unique:5/5 | Practical:5/5 | Anti-Hype:4/5
**Main Journal**: 98/100 | **Annex Potential**: 97/100 | **Overall**: 96/100
**Topics**: [[LLM, プロンプトエンジニアリング, コンテキストエンジニアリング, RAG, エージェントシステム, ソフトウェア設計パターン]]
記事は、LLM（大規模言語モデル）の利用が会話型チャットボットから複雑なシステムの意思決定コンポーネントへと変化する中で、「プロンプトエンジニアリング」の限界が明らかになり、より体系的な「コンテキストエンジニアリング」が必要とされていると指摘します。従来のプロンプトエンジニアリングは試行錯誤に頼りがちで、LLMを「神託」のように捉え、神秘的な呪文を唱えるかのようなアプローチでした。しかし、LLMがより賢くなり、推論に利用できるトークンシーケンスが複雑化するにつれて、状況は変化しました。
著者は、LLMを「アナリスト」として扱うべきだと主張します。これは、必要な関連情報を提供し、タスクを明確に定義し、利用可能なツールを文書化することで、LLMがその知識と推論能力を最大限に発揮できるようにするという考え方です。これにより、LLMはトレーニングデータに依存するだけでなく、提供されたコンテキスト内で「インコンテキスト学習」を通じて新しい情報から学習し、より正確で最新の回答を生成できます。例えば、英国の週次興行収入を計算する際、最新の日付、関連文書（BBCニュース記事など）、および計算用関数をコンテキストとして提供することで、LLMは外部ツールを呼び出して正確な結果を導き出せます。
このコンテキスト全体を設計するプロセスは、従来のソフトウェアエンジニアリングにおける設計パターンと同様に、モジュール性、堅牢性、理解しやすさを可能にするものです。RAG（Retrieval-Augmented Generation）は、外部知識をコンテキストウィンドウに注入するコンテキストエンジニアリングの具体的なパターンの一つであり、LLMが訓練データに含まれない最新の情報を利用できるようにするために不可欠です。記事では、RAG、ツール呼び出し、構造化出力、Chain of Thought/ReAct、コンテキスト圧縮、メモリといった、コンテキストエンジニアリングのさまざまな設計パターンを紹介しています。
さらに、LLMを活用した本番システムは、複数の専門エージェント（安全性ガードレール、情報検索、知識抽出など）へと進化すると予測します。これらのエージェントは、消費するコンテキストをエンジニアリングすることによって専門化され、他のエージェントからの出力をコンテキストとして利用します。エージェント間のトークンシーケンスの受け渡しは、ソフトウェアアーキテクチャにおけるAPI契約と同様に厳密に扱うべきだと強調されています。
この新しい規律「コンテキストエンジニアリング」は、LLMを効果的にタスク解決に導くためのものです。ウェブアプリケーションエンジニアは、LLMをアナリストとして扱い、コンテキストウィンドウ全体に責任を持ち、構成可能で再利用可能な設計パターンを活用し、エージェント間の受け渡しをAPI契約として捉えることで、LLMを組み込んだシステムをモジュール的で堅牢なものに構築できるでしょう。