「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に使いやすい形で管理しておくことが重要になります。

自分のドキュメントの活用例

自分のドキュメントの活用例を上げると、例えば、この記事も実はコンテキストエンジニアリングを活用して書いています。具体的には、以下のような流れで記事を書きました：

1. プロンプト: 自分のドキュメントのブログ記事執筆プロンプトを選択（ユーザー入力）
2. 情報収集: 複数のWebサイトから関連情報を自動取得（Web検索）
3. 既存記事分析: 過去の自分のブログ記事から文体と技術的観点を抽出（ドキュメント検索）
4. 論文検索: ArXivから最新の研究動向を調査（MCP）
5. 修正: えられた出力に対してフィードバック（ユーザー入力）

「既存記事分析」については、私の記事ではないですが自分の文体を真似てClaude Codeにブログ記事を書かせるも参考になると思います。だいたい自分も似たことやっています。

これのループを繰り返すことで、ブログ記事を作成します。もちろん完成した記事は、私のドキュメントとして蓄積されることになります。ちなみに記事作成自体は、割合自体は90%以上自分が書き直しているのですが、それ以外の部分、具体的には最初のたたき台作成だったり自分には無い視点を貰える点に価値があるかと思いますし、活用の幅もAIに任せられる割合も、今後LLMやAIエージェントの進化、そして自分のドキュメントの蓄積により更に増えていくかと思います。

こういった手法の具体例に関しては、以下に実践例や使用しているツール・設定方法などまとめていますので参照ください。

https://www.docswell.com/s/karaage0703/KV463J-2025-07-20-220731

https://zenn.dev/karaage0703/articles/c9c948b1bfe713

https://zenn.dev/karaage0703/articles/26430a7e372cfa

https://zenn.dev/karaage0703/articles/3bd2957807f311

https://zenn.dev/karaage0703/articles/52c3e016653003

まとめ

コンテキストエンジニアリングについて、自分が悶々としながら考えたことを整理してみました。LLMが賢くなっていくとプロンプトは簡単でいいみたいな論文もあるので、少し前はプロンプトエンジニアリングはなくなっていくのかな？とか思ったりしていたのですが、コンテキストエンジニアリングという考え方まで拡張すると、一周回って「LLMはコンテキスト（広義のプロンプト）がすべて」かもというのが今の自分の考えです。数ヶ月くらいしたらまた変わっているかも…ですが

ただ、自分独自のドキュメントが重要になるという点はそこまで変わらない気はしますし、これを育てることがコンテキストエンジニアリング、生成AIの活用の肝なのではないかなと思っています。

ついつい新しいLLMやエージェントツールに目が行きがちになってしまう今日この頃ですが、長期的にシステム自体を活用してデータを育てるという視点を持てると、LLMやツールがいかに変わっても、自分なりのナレッジを蓄積しつつ、生成AIを最大限に活用できるのではないかなと思います。

参考リンク

LLMのプロンプトエンジニアリング

https://agnozingdays.hatenablog.com/entry/2025/07/14/080000

https://nikkie-ftnext.hatenablog.com/entry/book-prompt-engineering-for-llms-is-awesome

https://note.com/erukiti/n/nddf9e9ccfd96

https://www.du-soleil.com/entry/llm-prompt-engineering

https://speakerdeck.com/yuhattor/how-to-read-prompt-engineering-for-llm-niu-ben

https://blog.shibayu36.org/entry/2025/08/04/173000

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

https://zenn.dev/knowledgesense/articles/47afd29ecfc3bb

https://www.philschmid.de/context-engineering

https://speakerdeck.com/shibuiwilliam/llmshi-dai-nojian-suo

https://zenn.dev/tacoms/articles/6a717fe95d5199

https://arxiv.org/abs/2507.13334

https://github.com/Meirtz/Awesome-Context-Engineering

https://tech.akariinc.co.jp/entry/2025/08/15/190000

https://zenn.dev/aki_think/articles/66f6fc7530467a

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

https://tech.algomatic.jp/entry/2025/10/15/172110

https://zenn.dev/sakasegawa/articles/65895201c59e44

https://caddi.tech/claude-code-context-management-202603

関連記事

https://zenn.dev/karaage0703/articles/90d4de4596b262