プロンプトエンジニアリングの次の進化形「コンテキストエンジニアリング」完全解説

AI開発の世界で、プロンプトエンジニアリングに代わる新しい概念「コンテキストエンジニアリング」が急速に注目を集めています。ShopifyのCEO Tobi Lutke氏は『LLMがタスクを解決可能にするために必要なすべてのコンテキストを提供する技術』と定義し、著名なAI研究者Andrej Karpathy氏も『産業レベルのLLMアプリケーションに不可欠な技術』として強く支持しています。この変化は、単なる用語の置き換えではなく、AI開発アプローチの根本的な進化を意味します。

本記事では、コンテキストエンジニアリングの本質を明らかにし、その重要性を解説します。まず、コンテキストエンジニアリングとは何か、その定義と構成要素を詳しく説明します。次に、なぜ今この概念が重要なのか、実際の開発現場での課題と解決策を示します。さらに、コンテキストエンジニアリングの4つの核心戦略を具体例とともに解説します。最後に、miiboを使った実践方法を紹介し、誰でも始められる具体的なステップを提供します。

コンテキストエンジニアリングとは何か：新しいAI開発パラダイムの全容

コンテキストエンジニアリングは、LLMに提供するすべての情報を動的に構築・管理するシステム設計の技術です。従来のプロンプトエンジニアリングが「どのように質問するか」に焦点を当てていたのに対し、コンテキストエンジニアリングは「LLMが必要とするすべての情報をどのように提供するか」を扱います。

LLMのコンテキストウィンドウという「作業記憶」

LLMのコンテキストウィンドウは、人間の作業記憶（ワーキングメモリー）に相当する領域です。Andrej Karpathy氏の比喩を借りれば、LLMはCPUのような計算装置であり、コンテキストウィンドウはRAMのような一時記憶領域です。この限られた領域に、タスク遂行に必要な情報を適切に配置することが、AIエージェントの成功を左右します。

コンテキストに含まれる要素は多岐にわたります。基本的な指示（システムプロンプト）、ユーザーからの具体的な要求、これまでの会話履歴（短期記憶）、過去の会話から抽出された情報（長期記憶）、外部データベースから取得した関連情報（RAG）、利用可能なツールの定義、そして期待される出力形式の指定などです。これらすべてが、LLMが「見る」世界を構成します。

「安っぽいデモ」と「魔法のような製品」の違い

同じLLMを使っていても、コンテキストの質によって結果は天と地ほどの差が生まれます。例えば「明日ミーティングできる？」という簡単な質問への応答を考えてみましょう。貧弱なコンテキストしか持たないAIは「はい、明日は可能です。何時がよろしいですか？」と機械的に答えます。

一方、豊富なコンテキストを持つAIは異なる応答をします。カレンダー情報（明日は終日予定が入っている）、過去のメール（相手は重要なパートナー）、コミュニケーションスタイル（カジュアルな口調が適切）などの情報を統合し、「明日は終日埋まってるんだ。木曜の午前中はどう？招待送っとくね」と自然で実用的な返答を生成します。この違いを生むのが、コンテキストエンジニアリングの力です。

なぜコンテキストエンジニアリングが重要なのか：AI開発の現実と課題

AIエージェントの失敗の大半は、モデルの能力不足ではなくコンテキストの不足や不適切さに起因します。最新のLLMは驚異的な能力を持っていますが、適切な情報がなければその能力を発揮できません。「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」という古典的な原則は、AI時代においてもなお真実です。

エージェント開発における4つの落とし穴

Drew Breunig氏は、長大なコンテキストがもたらす問題を4つのパターンに分類しています。「コンテキスト汚染」は誤った情報がコンテキストに混入し、後続の応答に悪影響を与える現象です。「コンテキスト注意散漫」は過剰な情報によってAIが重要な情報を見落とす状態です。「コンテキスト混乱」は無関係な情報が応答に影響を与えることを指し、「コンテキスト衝突」は矛盾する情報が存在する場合に発生します。

これらの問題は、コンテキストを単純に増やせば解決するものではありません。むしろ、情報の質と構成、タイミングを慎重に設計する必要があります。Cognition社が「コンテキストエンジニアリングはAIエージェントを構築するエンジニアの最重要業務」と述べているのは、この複雑さゆえです。

産業レベルのAIアプリケーションが直面する現実

商用AIサービスの開発現場では、コンテキスト管理の課題がより顕著になります。Anthropic社の報告によれば、エージェントは数百ターンに及ぶ会話を処理する必要があり、その過程で蓄積される情報量は膨大です。単純にすべての情報を保持すると、コストの増大、レスポンスの遅延、そして皮肉なことに精度の低下を招きます。

実際の開発では、15倍ものトークンを消費することもあり、コスト管理は深刻な課題となります。また、コンテキストウィンドウのサイズには物理的な限界があり、GPT-4でさえ128,000トークン（約10万文字）が上限です。この制約の中で、いかに効率的に情報を管理するかが、実用的なAIエージェント開発の鍵となります。

コンテキストエンジニアリングの4つの核心戦略：実践的アプローチ

コンテキストエンジニアリングの実践は、「書く（Write）」「選択する（Select）」「圧縮する（Compress）」「分離する（Isolate）」という4つの戦略に集約されます。これらの戦略を適切に組み合わせることで、効果的なコンテキスト管理が可能になります。

「書く」戦略：情報の永続化と構造化

コンテキストを「書く」とは、重要な情報をコンテキストウィンドウの外部に保存し、必要に応じて参照可能にすることです。スクラッチパッドは、エージェントがタスク実行中にメモを取る仕組みで、人間が問題解決時にメモを取るのと同じ役割を果たします。Anthropicのマルチエージェント研究では、リサーチャーエージェントが計画をメモリーに保存し、20万トークンを超える処理でも重要な情報を失わないようにしています。

長期記憶（メモリー）の実装も重要な要素です。ChatGPT、Cursor、Windsurf などの商用サービスは、ユーザーとの対話から自動的に記憶を生成し、セッションを超えて情報を保持します。これらの記憶は、事実（セマンティック）、経験（エピソディック）、手順（プロシージャル）に分類され、それぞれ異なる用途で活用されます。

「選択する」戦略：適切な情報の動的取得

情報の選択は、タスクに必要な情報を適切なタイミングで取得する技術です。RAG（Retrieval-Augmented Generation）はその代表例で、外部データベースから関連情報を検索し、コンテキストに追加します。Windsurf社のVarun氏は、コードベースが大規模になるにつれ、単純な埋め込み検索では不十分になり、AST解析、grep検索、知識グラフ、再ランキングなど複数の技術を組み合わせる必要があると述べています。

ツールの選択も重要な課題です。エージェントに過剰なツールを提供すると、ツールの説明だけでコンテキストが圧迫され、さらに類似したツールがあると選択ミスが発生します。最近の研究では、セマンティック検索によるツール選択により、精度が3倍向上することが示されています。

「圧縮する」戦略：効率的な情報表現

コンテキストの圧縮は、必要最小限のトークンで最大限の情報を伝える技術です。要約（Summarization）は最も一般的な手法で、Claude Codeの「auto-compact」機能は、コンテキストウィンドウの95%を超えると自動的に会話履歴を要約します。Cognition社は、エージェント間の情報受け渡しに特化した要約モデルをファインチューニングして使用しており、この工程の重要性を示しています。

トリミング（Trimming）は、ヒューリスティックに基づいて不要な情報を削除する手法です。古いメッセージの削除、冗長な情報の除去、関連性の低い部分の省略などが含まれます。Drew Breunig氏が提案する「Provence」のような学習ベースのコンテキストプルーナーも、この戦略の一例です。

「分離する」戦略：コンテキストの分割と独立管理

コンテキストの分離は、複雑なタスクを独立したサブタスクに分割し、それぞれに専用のコンテキストを割り当てる戦略です。マルチエージェントアーキテクチャはその典型例で、OpenAIのSwarmライブラリは「関心の分離」を設計思想としています。各エージェントが独自のツール、指示、コンテキストウィンドウを持つことで、より効率的なタスク処理が可能になります。

環境による分離も効果的なアプローチです。HuggingFaceのCodeAgentは、ツール呼び出しの結果をサンドボックス環境で処理し、必要な情報のみをLLMに返します。これにより、画像や音声などのトークン消費の多いオブジェクトを環境内に保持し、参照用の変数名のみをコンテキストに含めることができます。

miiboで始めるコンテキストエンジニアリング：実践への第一歩

miiboは、コンテキストエンジニアリングの概念を実装するための包括的な機能を提供しています。これらの機能を理解し活用することで、理論を実践に移すことができます。

miiboの4層プロンプト構造で実現する動的コンテキスト

miiboのプロンプトシステムは、ベースプロンプト、前提データプロンプト、会話履歴、追記プロンプトという4層構造を持ちます。この構造自体が、コンテキストエンジニアリングの実装例です。ベースプロンプトで基本的な振る舞いを定義し、前提データプロンプトにRAGで取得した情報を自動挿入し、会話履歴で短期記憶を管理し、追記プロンプトで最重要指示を強調します。

ステート管理機能は、ユーザーごとの情報を永続的に保存し、#{ステート名}記法でプロンプトに動的に挿入できます。例えば、#{困りごと}というステートを定義し、会話の中でAIに自動抽出させることで、ユーザーの課題を追跡し続けることができます。この機能により、セッションを超えた長期記憶の実装が可能になります。

ナレッジデータストアとRAGによる知識管理

ナレッジデータストアは、専門知識をベクトル化して保存し、会話の文脈に応じて最適な情報を検索する仕組みです。全文検索、ベクトル検索、ハイブリッド検索の3つのモードを提供し、ユースケースに応じた最適な検索戦略を選択できます。検索クエリー生成プロンプトをカスタマイズすることで、より精度の高い情報取得が可能になります。

チャンク制御機能では、[CHUNK]タグを使用して情報の分割位置を明示的に指定できます。カスタムフィールドを活用すれば、重要な属性情報を確実にコンテキストに含めることができます。これらの機能により、情報の選択と圧縮を同時に実現できます。

シナリオ対話による高度なコンテキスト制御

シナリオ対話機能は、会話フローを複数のノード（アクション）に分割し、各ノードで独立したコンテキスト管理を可能にします。各ノードでは異なるプロンプトと言語モデルを設定でき、タスクの性質に応じた最適化が可能です。フリートークアクションを使用すれば、制御された環境下で自由な会話も実現できます。

条件分岐により、ユーザーの応答やステートの値に基づいて動的にフローを変更できます。これにより、複雑なタスクを論理的に分解し、各段階で必要な情報のみをコンテキストに含めることができます。この機能は、コンテキストの分離戦略を直接的に実装するものです。

まとめ：コンテキストエンジニアリングがもたらす新しい可能性

コンテキストエンジニアリングは、AI開発における根本的なパラダイムシフトを表しています。単なるプロンプトの最適化を超えて、LLMに提供するすべての情報を動的に管理するシステム設計へと、開発の焦点が移行しています。この変化は、AIエージェントを「安っぽいデモ」から「魔法のような製品」へと進化させる鍵となります。

4つの核心戦略（書く、選択する、圧縮する、分離する）を理解し実践することで、効果的なコンテキスト管理が可能になります。miiboは、これらの戦略を実装するための包括的な機能を提供し、理論を実践に移すための強力なプラットフォームとなっています。ステート管理、ナレッジデータストア、シナリオ対話などの機能を活用することで、誰でもコンテキストエンジニアリングを始めることができます。

AIの真の可能性を引き出すには、適切な情報を適切なタイミングで提供することが不可欠です。コンテキストエンジニアリングは、この課題に対する体系的なアプローチを提供し、実用的で信頼性の高いAIエージェントの構築を可能にします。今こそ、この新しいパラダイムを理解し、実践する時です。

Get full access to 岡大徳のメルマガ at www.daitoku0110.news/subscribe

サマリー

コンテキストエンジニアリングは、プロンプトエンジニアリングの進化形であり、AIのタスクに必要な情報を適切に提供するための全体的な設計アプローチです。この技術は、AIエージェントが失敗する多くの原因がコンテキストの不足や質の管理に関連していることから、特に重要視されています。

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

さて、今日はですね、皆さんが共有してくださった資料、コンテキストエンジニアリングについて、ちょっと深く見ていきたいなと思っています。

これ、プロンプトエンジニアリングの次に来るもの、みたいな感じで言われているみたいですね。

ええ、そうですね。まさに、ショピファイのCEO、扉時氏も、LLMがタスクを解決するために必要な全てのコンテキストを提供する技術だと定義していて、

AI研究者のアンドレ・カーラパシーも、産業レベルのLLMアプリケーションには不可欠だとかなり高く評価しているんですよ。

へえ、不可欠とまで。

ええ。なので、単なる新しい言葉っていうよりは、なんていうか、AI開発のアプローチ自体が根本的に進化している、そういうサインなのかなと。

なるほど。じゃあ、この資料をもとに、そのコンテキストエンジニアリングっていうのが一体何なのか、なぜ今これが大事なのか、そして具体的な戦略はどんな感じなのか、その辺の確信の部分を皆さんと一緒に探っていけたらなと思います。

なるほど、って思えるポイントを見つけていきましょう。

まず、基本のところからなんですけど、これまでのプロンプトエンジニアリング、つまりどううまく質問するかっていうのとは何が違うんでしょうか。

そこがですね、視点がもっと広いんですよね。プロンプトエンジニアリングが質問の仕方にフォーカスしてたのに対して、コンテキストエンジニアリングはもっと全体。つまり、LLMがタスクをやるのに必要な情報をどうやって全部、過不足なく提供するかっていうシステム全体の設計に関する考え方なんです。

システム全体の設計ですか?

カラパシーが面白い例えをしてるんですけど、LLMがコンピューターのCPUだとしたら、コンテキストウィンドウ、つまり一度に扱える情報量ですね。これがRAMみたいなもんだと。

なるほど、作業メモリー一時的な。

そうなんです。

この限られた作業領域に、指示とかこれまでの会話の履歴とか、外部から持ってくるデータ、RAGとかですね、あと使えるツールの定義とか、そういったタスクに必要な情報をいかに効率よく賢く配置するか。そこが鍵になるというわけです。

資料にあった例、分かりやすかったですね。明日ミーティングできますか?っていう質問の。

ありましたね。

あれ、コンテキストが少ないとAIは、はい可能ですとしか返せないけど、カレンダーの情報とか、相手との関係性とか、そういうリッチなコンテキストがあると、

そうそう。

明日はちょっと待ってるので、木曜の午前はいかがですか?招待を送りますね、みたいに。グッと実用的でなんか人間らしい応答になる。

まさに。

この差を生み出すのがコンテキストで、それをちゃんと設計するのがコンテキストエンジニアリングなんだと。

その通りです。で、じゃあなぜ今これがそんなに重要視されているのかっていう話なんですけど、資料が結構鋭く指摘しているのが、

AIエージェントが失敗する原因って、実はモデル自体の能力不足ってより、コンテキストが足りないとか、あれは不適切だったりとか、そっちのケースが多いんじゃないかと。

あー、なるほど。

いわゆるゴミを入れたらゴミしか出てこないっていう原則は、AIでもやっぱり顕在なんですよね。

ただ、情報を増やせばいいってもんでもないのがまた難しいところですよね。

そうなんですよ。

資料には、ドゥルーブ・レーニグ氏が指摘する4つの落とし穴っていうのもありました。

情報が足りないだけじゃなくて、逆に入れすぎたり、質が悪かったりすると、また別の問題が起きると。

具体的に言うと、例えばコンテキスト汚染。これは間違った情報がコンテキストに混じってた問題ですね。

うーん、それは困る。

あとはコンテキスト注意三万。大事な情報が他のたくさんの情報に埋もれちゃって、AIが見落としてしまう。

あー、情報が多すぎて。

それからコンテキスト困難。これは関係ない情報がむしろ悪影響を与えちゃうケース。

それにコンテキスト衝突。矛盾する情報、例えばAをしろとAをするなみたいな指示が同時に与えられてしまうとか。

なるほど。単に量を増やせばいいわけじゃない質の管理も重要だと。

そうなんです。特にビジネスで使おうとすると、会話がすごく長くなったり、100ターンとかになったり。

そんなに?

参照する情報もどんどん増えますし、そうするとコストの問題が出てくる。資料には最大で15倍トークン消費が増えた例も出てましたけど。

15倍?

あとは応答が遅くなったり、さらに皮肉なことに情報が多すぎると、かえって精度が落ちるなんてことも起こり得る。

コンテキスト管理の戦略

うわあ、それは本末転倒ですね。GPT-4みたいなかなり高性能なモデルでも扱える情報量にはやっぱり限界がありますもんね。

まさに。だからこそコンテキストエンジニアリングっていうのは単なるプロンプトの工夫を超えた、もっとシステムレベルでの設計課題になってくるわけです。

限られたリソースをどう最適に使うかという。

なるほどなるほど。じゃあそのコンテキストをうまく管理するための具体的な戦略みたいなものは資料ではどういうものが紹介されてましたか?

大きくは4つのアプローチが示されてましたね。書く、選択する、圧縮する、そして分離する。この4つです。

書く、選択する、圧縮する、分離する。まず書くというのは?

これは例えば計算の途中経過をメモするスクラッチパッドみたいな一時的な記憶とか、あるいはユーザーの好みとか基本情報みたいな長期的な記憶をコンテキストウィンドウの外、つまり外部に保存しておいて必要なときに参照させるっていう考え方ですね。

なるほど。外部メモリーみたいに使うんですね。選択するは?

これは例えばRAG、Retrieval Augmented Generationが代表的ですけど、膨大な外部の知識データベースの中から、今まさに必要としている関連性の高い情報だけをピンポイントで選び出してLLMに渡す。

必要なものだけを引っ張ってくる。

そうすることで限られたコンテキストウィンドウのスペースを有効活用するわけです。あるいはAIが使えるツールがたくさんある中で、状況に応じて最適なツールを選ばせる、みたいなこともこの選択するに含まれますね。

圧縮するはそのままの意味で情報を短くする?

そうですね。長くなっちゃった会話の履歴をうまく要約したりとか、クロードコードのオートコンパクト機能なんていうのも紹介されてましたけど、後は明らかに不要になった情報、古い情報なんかをそぎ落とす、トリミングすることでコンテキスト全体のトークンスを減らすという戦略です。

なるほど、ダイエットさせる感じですね。最後の分離するというのは?

これは複雑なタスクをもっと小さなサブタスクに分解して、それぞれのサブタスクごとに独立した最適化されたコンテキストを与えるというアプローチです。マルチエージェントシステム、例えばオープンAIのSWARMみたいな研究もありますけど、そういう役割分担させるイメージに近いかもしれません。

へー、タスクごとにコンテキストを分ける。こうして見てくるとコンテキストエンジニアリングってLLMっていう強力なエンジンそのものというよりは、その性能を最大限に引き出すための周辺システム全体の最適化技術っていう感じがしますね。

まさにおっしゃる通りだと思います。AIの本当の力、ポテンシャルを引き出すには、モデル自体の賢さももちろん大事ですけど、それと同じくらい何を、いつ、どんなふうに伝えるかっていうこのコンテキストの質と効率が決定的に重要になってくる。コンテキストエンジニアリングは、そのためのより体系的なアプローチ、方法論を提供しようとしてるんだと思いますね。

いやー、今日はコンテキストエンジニアリングについてかなり深く理解できた気がします。単にプロンプトを工夫するだけじゃなり、もっと大きな話なんだなと。

ええ、そうですね。これからますます重要になってくる考え方だと思います。

さて、今日はコンテキストエンジニアリングについていろいろ見てきましたけど、最後に一つ皆さんに問いかけてみたいことがあります。

AIのコンテキストを管理するための選択。書く、選択する、圧縮する、分離する。これって、もしかしたら情報がもう本当にあふれ返っている現代で、私たち自身が日々の大量の情報とどう向き合ってより良い算段をしていくかっていうことにも何か応用できるヒントがあるんじゃないでしょうか。そんなことを考えさせられました。