コンテキストエンジニアリングの背景知識

「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ——言葉の変化は、AIシステム設計の本質的な転換を反映している。用語の経緯を整理しておく。

2025年6月19日、ShopifyのCEO Tobi Lütke がX（旧Twitter）に次のように投稿した。「"context engineering" という言葉の方が "prompt engineering" よりも好みだ。コアスキルをより正確に表している——LLMによってタスクが解決可能になるよう、あらゆるコンテキストを提供するアートだ」（ポストID: 1935533422589399127）。このひとつの投稿が、業界でこの用語が広まる直接のきっかけとなった。

ほぼ同時期に、元OpenAI/Teslaの研究者 Andrej Karpathy もXで賛同し、「コンテキストエンジニアリングは、次のステップに向けて適切な情報でコンテキストウィンドウを埋める、繊細なアートと科学だ」と定義した（ポストID: 1937902205765607626）。Simon Willisonは2025年6月27日のブログ「Context Engineering」でこれを「最近勢いを増してきた用語」として記録している。Anthropicは2025年9月29日付の公式エンジニアリングブログ「Effective context engineering for AI agents」でこの概念を「LLM推論中の最適なトークン（情報）の集合を選別・維持するための戦略群」と定義し、業界への定着を後押しした。

なぜ「プロンプト」から「コンテキスト」へ言葉が移ったのか。プロンプトエンジニアリングとは、単一の指示文を書き・整える行為だ。モデルに単発の質問を投げる初期的な使い方には対応していたが、複数のツールを使い、複数ターンにわたって動作し、外部データを参照しながら判断するエージェント的な動作には、概念として対応しきれなかった。指示文の書き方だけでは、システム全体の品質をコントロールできなくなっていた。

Anthropicの定義が示すように、コンテキストエンジニアリングが設計対象とするのは指示文だけではない。システムプロンプト、ツールの定義、少数事例（few-shot examples）、外部データやRAGの結果、会話履歴、エージェントの状態（state）——これらすべてがモデルに渡す情報として設計対象になる。いずれか一つを変えるだけで、モデルの振る舞いは変わる。

企業の実務においてこの概念が持つ意味は明確だ。AIシステムを「何と言えばうまく動くか」の問題として扱うと、改善の余地が指示文の書き方に限定される。しかしコンテキストエンジニアリングの観点に立つと、「モデルが判断に必要な情報を、適切なタイミングで、適切な形で渡せているか」という設計の問題として捉え直せる。知識の配置、履歴の管理、ツール定義の精度、制約の明示——これらすべてが改善対象になり、品質向上の手段が広がる。

特にマルチターン・エージェント動作では、コンテキストは静的でなく継続的に更新・刈り込みが必要だ。Anthropicはこれを "context rot"（コンテキストの品質劣化）と呼んでいる。不要な情報が蓄積してコンテキストウィンドウを圧迫し、モデルの判断精度が落ちる現象だ。設計者はこの劣化をどう防ぐかを意識する必要がある。

「何を言うか」ではなく「何を渡すか」——この視点の転換が、AIシステムを実務で動かし続けるための根本的な設計思想になっている。2025年6月にひとりのCEOの投稿から始まったこの言葉は、わずか数ヶ月で業界の共通語になった。その速さ自体が、従来の「プロンプトを書く」という枠組みが実務の複雑さに追いつかなくなっていた証拠だ。

参考

• Tobi Lütke の X ポスト（2025-06-19）https://x.com/tobi/status/1935533422589399127
• Andrej Karpathy の X ポスト https://x.com/karpathy/status/1937902205765607626
• Simon Willison "Context Engineering" (2025-06-27) https://simonwillison.net/2025/jun/27/context-engineering/
• Anthropic: "Effective context engineering for AI agents" (2025-09-29) https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents