プロンプトの先へ——コンテキストエンジニアリングが生成AI活用の本命になった理由

ChatGPTやClaudeを業務に使い始めた企業の多くが、同じ壁にぶつかる。プロンプトを工夫しても、出力が安定しない。指示の書き方を変えても、欲しい精度に届かない。

原因はプロンプトの書き方ではない。AIに渡している「文脈」の設計が足りていない。

2025年半ば、元Tesla AI責任者のAndrej Karpathyが「プロンプトエンジニアリングよりコンテキストエンジニアリングという呼び方を支持する」と発言し、この概念が一気に注目を集めた。Shopify CEOのTobi Lütkeも同様の見解を示している。2026年の今、GartnerもコンテキストエンジニアリングをエンタープライズAI成功の鍵と位置づけている（出典: Gartner, Context Engineering, 2026）。

本記事では、プロンプトエンジニアリングとの違い、実務でどう使うか、そしてLat91がAIエージェント10体の運用で得た具体的な設計知見を共有する。

プロンプトエンジニアリングが「限界」に達した構造的な理由

まず、プロンプトエンジニアリングが無意味だと言いたいわけではない。適切な指示を書く技術は依然として重要だ。問題は、それだけでは業務レベルの安定性が得られないことにある。

プロンプトエンジニアリングは「AIへの指示の言い回し」を最適化する技術だ。「ステップバイステップで考えてください」「あなたは〇〇の専門家です」——こうしたテクニックは、個人が単発でAIを使うには十分に効果的だった。

だが、業務に組み込む段階で構造的な限界が露呈する。理由は3つある。

第一に、プロンプトは「指示」であって「知識」ではない。どれほど精巧な指示を書いても、AIが参照できる情報がなければ「もっともらしい推測」しか返せない。顧客対応のAIに「丁寧に返信して」と指示しても、その顧客の購買履歴、過去の問い合わせ、現在の在庫状況を渡さなければ、的外れな回答になる。

第二に、プロンプトの効果はモデルのバージョンアップで変わる。2025年に最適化したプロンプトが、2026年のモデルでは違う挙動をする。指示の文言に依存する設計は、脆い。

第三に、AIエージェントの時代は「1回の指示」では完結しない。複数ステップの計画、ツールの使用、記憶の参照——これらをプロンプト1本で制御することは不可能だ。

コンテキストエンジニアリングとは何か——6つの構成要素

Karpathyは、コンテキストエンジニアリングを「コンテキストウィンドウに、次のステップに必要な情報を過不足なく詰める技術」と定義した（出典: Andrej Karpathy, X post, 2025）。

プロンプトエンジニアリングが「どう指示するか」を扱うのに対し、コンテキストエンジニアリングは「何を知らせるか」を設計する。

図1: コンテキストエンジニアリングを構成する6つの要素

具体的には、以下の6つの要素をどう組み合わせるかが設計の核になる。

1. システム指示——タスクの説明、出力制約、ルール定義。プロンプトエンジニアリングでいう「プロンプト」はここに含まれる。つまり、プロンプトはコンテキストの一部にすぎない。

2. Few-shot例——入力と出力のペアを数件提示し、品質基準を暗黙的に伝える。「こういう入力が来たら、こう返す」という具体例は、100行の指示より効果的なことが多い。

3. RAG（検索拡張生成）——外部のドキュメントやデータベースから、タスクに関連する情報を動的に取得してコンテキストに注入する。AIの知識をリアルタイムで拡張する仕組みだ。

4. ツール定義——APIや関数のスキーマを渡し、AIがいつ・どのツールを使うかを判断できるようにする。AIエージェントが外部システムと連携するための窓口にあたる。

5. 記憶・状態——会話履歴、セッション間の情報引継ぎ、ユーザーの過去の行動記録。文脈を維持するために必須の要素だ。

6. 圧縮・整理——コンテキストウィンドウには上限がある。不要な情報を除去し、関連性の高い情報に優先度をつける技術。多すぎる情報はコスト増と精度劣化を招く。

Lat91が10体のAIエージェントで実践しているコンテキスト設計

理論だけでは抽象的になるので、私たちの実例を共有する。

Lat91では、CEO業務を自動化するAIエージェントを10体構築している。各エージェントは独立したコンテキストを持ち、Orchestrator-Workersパターンで連携する。この設計で最も時間を費やしたのは、モデル選定でもプロンプト設計でもない。各エージェントに「何を知らせ、何を知らせないか」の設計——まさにコンテキストエンジニアリングだ。

具体的にやっていることを3つ挙げる。

実践1: CLAUDE.mdによるプロジェクト知識の永続化

Claude Codeには「CLAUDE.md」というファイルにプロジェクトのルール・知識を書き込む機能がある。セッションが変わっても、この知識が自動的にコンテキストに読み込まれる。

私たちはここに、コーディング規約だけでなく、ビジネス判断の基準、過去の失敗から学んだ教訓、各エージェントの責務範囲まで書き込んでいる。新しいセッションを開始するたびに「前回の文脈を説明し直す」必要がなくなった。これだけで、エージェントの出力精度は体感で30%以上向上した。

ただし、何でも書けばいいわけではない。情報が多すぎるとコンテキストウィンドウの40-50%を消費し、実際の作業に使える容量が圧迫される。「何を入れるか」と同じくらい「何を入れないか」が重要だということを、運用を通じて痛感した。

実践2: エージェントごとの知識分離

10体のエージェントにすべて同じ情報を渡したらどうなるか。試してみた結果、混乱した。SEO記事を書くエージェントが経理の情報に引きずられ、営業エージェントが技術ドキュメントのスタイルで提案書を書く。

現在は、各エージェント専用のスキルファイルとルールファイルを分離し、必要な情報だけが読み込まれるようにしている。パス指定で動的に読み込むルールファイルを使い、記事制作時にはライティングルールだけが、営業時には顧客情報だけがコンテキストに入る設計だ。

実践3: lessons.mdによる学習ループ

ユーザーから修正を受けたら、何を間違えたか・正しくはどうすべきだったかを「lessons.md」というファイルに記録している。次のセッション開始時に自動で読み込まれるため、同じミスを繰り返さない。

これは人間のナレッジマネジメントと本質的に同じだ。違いは、AIの場合は「ファイルに書けば確実に読む」点にある。人間のマニュアルは読まれないことがあるが、AIのコンテキストは構造的に参照される。この特性をうまく使えば、AIは使うほど賢くなる。

図2: Lat91がAIエージェント10体で実践するコンテキスト設計

「プロンプトを磨けば十分」という反論に向き合う

コンテキストエンジニアリングの重要性を語ると、必ず出てくる反論がある。「プロンプトの書き方をもっと工夫すれば、わざわざ複雑な設計をしなくても済むのでは？」

個人利用なら、その通りだ。ChatGPTに「この文章を要約して」と頼む程度であれば、プロンプトの工夫で十分な成果が得られる。

だが業務システムに組み込む段階では話が変わる。顧客対応エージェントに「丁寧に答えて」と指示するだけでは、顧客の購買履歴も契約内容もわからない。そのAIは、人間の新人オペレーターにマニュアルだけ渡して「あとはうまくやって」と言っているのと同じだ。マニュアル（プロンプト）は必要だが、それだけでは仕事にならない。

もう一つの重要な事実がある。LLMの推論能力が向上するにつれ、指示の重要性は相対的に下がり、コンテキストの品質が出力を左右する最大の変数になりつつある（出典: Elastic Labs, Context Engineering vs Prompt Engineering, 2026）。モデルが賢くなるほど、「どう言うか」より「何を知らせるか」の設計力が問われる。

今日から始められるコンテキストエンジニアリング3ステップ

大規模なシステム構築は必要ない。以下の3ステップで、業務AIの出力品質は明確に変わる。

ステップ1: 「AIに渡している情報」を棚卸しする。現在のプロンプトに何が含まれているかをリストアップする。おそらく「指示」しか入っていない。顧客情報、社内ルール、過去の成功例は含まれているか？含まれていないなら、それが品質の上限を決めている。

ステップ2: 1つの業務で「背景情報の自動注入」を試す。例えば、営業メールの下書きに顧客のCRM情報を自動で添えて渡す。議事録の要約に、前回会議の結論を付けて渡す。プロンプトは変えず、渡す情報を増やすだけで出力が変わることを体感する。

ステップ3: 「入れない情報」を決める。コンテキストウィンドウには上限がある。すべての情報を詰め込むと、逆にコストが増え精度が落ちる。タスクに直接関係のない情報は勇気を持って削る。この「引き算」の設計こそ、コンテキストエンジニアリングの真髄だ。

まとめ——AIの出力は、あなたが渡す文脈で決まる

プロンプトエンジニアリングが終わったわけではない。コンテキストエンジニアリングの一部として、今後も重要な役割を果たす。だが、AIを業務の中核に据えるなら、指示の文言だけを磨いていても天井に当たる。

私たちLat91がAIエージェントの構築で最も時間を費やしているのは、モデルのチューニングでもプロンプトの最適化でもない。各エージェントが「いつ・何を・どれだけ知るべきか」の設計だ。地味な作業だが、ここが出力品質の8割を決めると実感している。

コンテキストエンジニアリングは、AIの魔法を解除して「情報設計」という地に足のついたエンジニアリングに戻す概念でもある。逆に言えば、情報設計の基本ができている組織は、AIの恩恵を圧倒的に受けやすい。

Lat91では、生成AIの業務活用からエージェント設計まで、コンテキストエンジニアリングを軸にしたサポートを提供しています。「プロンプトを工夫しても成果が出ない」とお感じの方は、お気軽にご相談ください。