「LLMはコンテキストがすべて」かもしれない
コンテキストエンジニアリングについて
LLM（大規模言語モデル）の分野で、最近「コンテキストエンジニアリング（Context Engineering）」という言葉が多く使われるようになりました。AIエージェントの文脈でも使われることが多く、自分の中でずっとモヤモヤしていたのですが、少し自分なりに整理してみたのでここに書いてみます。
半分以上お気持ちというかポエムや私見が混じっていますので、学術的な定義の厳密性より、自分が普段使っていて感じる実践目線での一つの考え方として捉えてもらえるとありがたいです。
「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ
そもそも「コンテキストエンジニアリング」って何？「プロンプトエンジニアリング」と何が違うの？というところから始めたいと思います。
プロンプトエンジニアリングは、ものすごい単純にした図にすると以下になると思います。
プロンプトをいれるとそれに応じたLLMの出力が出るという感じですね。じゃあコンテキストエンジニアリングだとこの図がどうなるかというと以下のようになります。
「全部同じじゃないですか！？」
とこち亀の中川巡査のようにツッコミたくなりますが、この入力の定義が異なるということになります。
このコンテキストを詳しく書いたものが、よく引用される以下の図となります。
12-factor-agentsのfactor-03-own-your-context-windowより引用
これに加えて、コンテキストエンジニアリングを調査したサーベイ論文A Survey of Context Engineering for Large Language Modelsから引用すると以下の図となります。LLM技術の全部盛りですね。
図はA Survey of Context Engineering for Large Language Modelsより引用
最初の図に「Everything is Context Engineering」と書いてあるとおり、Few-shotやCoTなどのいわゆる一般的なプロンプトエンジニアリングの技術だけでなく、RAGだったりMCPといった技術を使ってLLMに必要な情報を取得する技術は、全てコンテキストエンジニアリングだと言っているわけですね。
プロンプトエンジニアリングを拡張したという言い方もできますし、プロンプトと区別するために、コンテキストという言葉を定義したという言い方もできると思います。
A Survey of Context Engineering for Large Language Modelsでは、プロンプトを単一の静的なテキスト文字列（C = prompt）とするのに対して、コンテキスト（C）は動的に構造化された情報コンポーネントの集合として再概念化しています。
とはいえ、正直きれいに区別できるものでもないかなと思います。話題になったLLMのプロンプトエンジニアリング（通称牛本）などは、かなりコンテキストエンジニアリングに踏み込んだ内容について書かれていると思います。書かれていたときに、コンテキストエンジニアリングがまだ一般的でなかったというのも、もちろんあると思います。
なお、コンテキストエンジニアリングが使われるようになった要因は、Shopify CEOのTobi Lutke氏のツイートと、それに対する元OpenAIの共同創業者であり、元テスラのAIディレクターであるAndrej Karpathy氏のツイートがきっかけと言われています（2025年の6月です）。
なお、余談気味になりますが「生成AIスキルの言語学という本」では、言語学分野でのコンテキスト（コンテクスト、コ-テクスト）について以下のように書かれていました。
コンテクストが言外の状況や背景を指すのに対して、文脈は会話内や文章内の言葉の関係を示し、コンテクストと区別してコ-テクスト（co-text）と言いいます。
LLMの分野でのコンテキストは、言語学分野のコンテキストを包括した、かなり広い概念になるのかなと自分は思っています。少なくともコンテキスト=文脈という訳はあまり適してないなと感じました。
なぜコンテキストが重要か
コンテキストエンジニアリングの定義と、話題になったきっかけを紹介しましたが、肝心の何故コンテキストが重要かという点について少しだけ補足しておきます。
AIの分野では、データが重要というのはある意味常識的な話で、特にLLMの分野だとスケーリング則といって、データを増やせば増やすほどLLMの性能がよくなることが知られていました。
引用元：Scaling Laws for Neural Language Models
ただ、これはあくまで学習の話で、推論時（AIを使うとき）は、そもそもデータは入力も出力も、限られたものでした。
それがLLMになると、入力データ（コンテキスト）を使って学習のようなことができる（In-context Learning）が知られてきたので、よりコンテキストの重要性が見直されて、あらためてプロンプトを拡張するような定義をしているのかなと思います。
なので、LLMの性能において、どれだけコンテキストを入力できるかというコンテキスト長は今後さらに重視されそうだなと思っています。そういう意味で、初期からコンテキスト長にこだわってLLMを開発していたGoogleは、さすがだなと思ったりします。自分が、今メインで使っているLLMはClaudeだったりしますが（コンテキスト長が全てではない）。
AIエージェントとコンテキストエンジニアリング
ではこのコンテキストエンジニアリングとAIエージェントがどう関係してくるかというと、最初の図に繋がってくるわけです。LLMは、過去のAIに比べてずっと賢い（いろいろなことができる）ので、入力するデータ（コンテキスト）が重要ということは分かってきました。
ただ、ここで問題になってくるのはこのコンテキストをどう入力するかです。ユーザーのデータ、Webのデータ、その他目的に応じて必要なデータを選択して入力する。これを実現するのがAIエージェント（の一つの役割）なのではないかなと思います。
AIエージェントでコンテキストエンジニアリングを実現した図の例は、例えば以下になるかと思います。
色々複雑に見えますが、LLMを中心でみると、入力（コンテキスト）と出力（LLM出力）は変わってないことが分かります。
見方を変えると、コンテキストエンジニアリングを効率化・自動化するためのツールがAIエージェントだということもできますね（あくまで一つの見方で、全てというわけではないです）。
またポイントとしては、LLMの出力自体もまたLLMのコンテキストとして活用できる点です。つまり、このシステムを使いこむほど、コンテキストがリッチになっていき性能が上がっていくというわけです。
自分のドキュメントの重要性
先程の図を見て、コンテキストとしてLLMの入力にも出力にも関わっている重要な要素として、自分独自のドキュメントがあることが分かります。
ここからは私見が入りますが、コンテキストエンジニアリングの重要なポイントは、この自分のドキュメントをコンテキストとして活用しつつ、LLMの出力をドキュメントに追加することで、自分のドキュメントを育てていく、このフィードバックループなのではないかと思っています。
LLMとAIエージェントも、もちろんこのループを実現するためには重要な要素なのですが、このループを意識していれば、異なるものにすぐ入れ替えることが可能です（私も様々なLLMやAIエージェントに乗り換えています）。逆に自分のドキュメントは置き換え不可能なので、LLMに使いやすい形で管理しておくことが重要になります。
自分のドキュメントの活用例
自分のドキュメントの活用例を上げると、例えば、この記事も実はコンテキストエンジニアリングを活用して書いています。具体的には、以下のような流れで記事を書きました：
- プロンプト: 自分のドキュメントのブログ記事執筆プロンプトを選択（ユーザー入力）
- 情報収集: 複数のWebサイトから関連情報を自動取得（Web検索）
- 既存記事分析: 過去の自分のブログ記事から文体と技術的観点を抽出（ドキュメント検索）
- 論文検索: ArXivから最新の研究動向を調査（MCP）
- 修正: えられた出力に対してフィードバック（ユーザー入力）
「既存記事分析」については、私の記事ではないですが自分の文体を真似てClaude Codeにブログ記事を書かせるも参考になると思います。だいたい自分も似たことやっています。
これのループを繰り返すことで、ブログ記事を作成します。もちろん完成した記事は、私のドキュメントとして蓄積されることになります。ちなみに記事作成自体は、割合自体は90%以上自分が書き直しているのですが、それ以外の部分、具体的には最初のたたき台作成だったり自分には無い視点を貰える点に価値があるかと思いますし、活用の幅もAIに任せられる割合も、今後LLMやAIエージェントの進化、そして自分のドキュメントの蓄積により更に増えていくかと思います。
こういった手法の具体例に関しては、以下に実践例や使用しているツール・設定方法などまとめていますので参照ください。
まとめ
コンテキストエンジニアリングについて、自分が悶々としながら考えたことを整理してみました。LLMが賢くなっていくとプロンプトは簡単でいいみたいな論文もあるので、少し前はプロンプトエンジニアリングはなくなっていくのかな？とか思ったりしていたのですが、コンテキストエンジニアリングという考え方まで拡張すると、一周回って「LLMはコンテキスト（広義のプロンプト）がすべて」かもというのが今の自分の考えです。数ヶ月くらいしたらまた変わっているかも…ですが
ただ、自分独自のドキュメントが重要になるという点はそこまで変わらない気はしますし、これを育てることがコンテキストエンジニアリング、生成AIの活用の肝なのではないかなと思っています。
ついつい新しいLLMやエージェントツールに目が行きがちになってしまう今日この頃ですが、長期的にシステム自体を活用してデータを育てるという視点を持てると、LLMやツールがいかに変わっても、自分なりのナレッジを蓄積しつつ、生成AIを最大限に活用できるのではないかなと思います。
参考リンク
LLMのプロンプトエンジニアリング
コンテキストエンジニアリング
関連記事
Discussion
はじめまして。私はエンジニアではないのですがAIと対話から始めて最後に文脈をすべて保存してカスタムgemに貼り付けたり、役割を与えたいときに対話して調整したものをプロンプト化してもらっています。最初はコンテキストエンジニアだけでいいんじゃね?とか思っていましたが、プロンプトエンジニアリングが必要な場合もあり使い分けだなーと思うようになりました。素人の発言失礼しました。
コメントありがとうございます。プロンプト作ってもらって再利用するの良いですよね
私はエンジニアとしてコーディングに使用していますが、AIエージェントを使うにあたって追い込み漁をいつもイメージしています。
自由勝手に動き回る獲物を、ある一点に向かって追い込んでいき、ほしい成果物に到達する、そのための仕掛けをAIエージェントではコンテキストと呼ぶのかなと思っています。
しかしどんな記事を見ても、「そのまま使える記事ができる」とか、「一瞬でスライド完成」などのAIの能力を誇張する記事がたくさんある中で、9割書き直しという現実的かつ、マジメに実践で活用してる人なんだな、と思える記載を見てとても共感し、コメントさせていただきました🙇
コメントありがとうございます。追い込み漁のたとえは面白いですね。
海を探索空間、解を獲物、コンテキストを制約条件と考えると、かなり実態に近いたとえなのではないかなという気がします。もしよかったら、ぜひどこかでたとえ使わさせてください（笑）
あと、そんなにマジメではないかも、ですw
自分は最近CLAUDE.mdやARCHITECTURE.mdみたいなのを作り込むのに凝っているのですが、それを（LLMが）アップデートし続けて、人の動きを以降完全再現！...みたいなつもりは毛頭なくて、LLMにした指示が虚空に消えずに残るだけで価値があると思っています
テキストで残しておけば、他のLLMにもほぼそのまま使えることが多いですからね。あんまり特定のLLMに依存しないように気をつけてます。