コンテキストエンジニアリングの議論に欠けているもの

What Happened

用語が変わった。

2025年6月、Andrej Karpathy（元Tesla AI責任者、OpenAI共同創業者）がこう述べました。

人々はプロンプトと聞くと、LLMに渡す短い指示文を連想する。しかし、産業レベルのLLMアプリケーションで本当に重要なのは、コンテキストウィンドウに、次のステップに必要な情報だけを正確に詰める技術と科学だ。

この発言を起点に、「プロンプトエンジニアリング」から「コンテキストエンジニアリング」への用語の転換が業界全体で進みました。同年9月にAnthropic（Claude開発元）が公式エンジニアリングブログで体系化し、7月にはGartnerが「2028年までにAIアプリ構築ツールの80%にコンテキストエンジニアリング機能が組み込まれる」と予測を出しています。

日本語圏でも2025年後半から「プロンプトエンジニアリングはもう古い」という見出しが定番化し、Qiita・Zenn・note・Forbes JAPANで解説記事が量産されています。2026年半ばの現在、用語の移行はほぼ完了したと言ってよいでしょう。

Runtime Focus

業界が議論していること。

コンテキストエンジニアリングの議論は、ほぼ全てがランタイム——AIが動くその瞬間に、コンテキストウィンドウに何を詰めるか——の話をしています。

System Prompt システムプロンプトの設計	役割定義、出力形式の指定、制約条件の記述。
RAG 外部知識の検索と注入	どの文書を引っ張り、どのチャンクを渡すか。
Tool Definition ツール定義の設計	いつ、どのツールをAIに開示するか。
Token Budget トークン予算の管理	古い文脈の要約・圧縮・切り捨ての戦略。

これらは全て重要な技術であり、異論はありません。しかし、ここに一つの前提が隠れています。管理すべき良質なコンテキストが、すでに存在していることです。

The Missing Layer

議論されていないこと。

コンテキストは天から降ってきません。誰かが作る必要があります。

AIエージェント（Claude CodeやCodex）と協働する場面を考えてみましょう。「英語学習アプリを作って」と一言伝えれば、何かしらのコードは生成されます。しかし、自分が本当に欲しいものが作られる保証はありません。AIは、あなたの頭の中にある要件を知らないからです。

このとき必要なのは、ランタイムのコンテキスト管理ではありません。コンテキストそのものを著作する行為です。

Design-Time Context

コンテキストを「作る」とはどういうことか。

当ラボの法人研修で教えている手法の一つに、ドキュメントファーストがあります。コードを1行も書く前に、設計書をファイルとして書き下す手法です。

設計書は「AIへのコンテキスト注入」です。AIが読める形で、
あなたの意図を書き下すことで、実装の精度が劇的に上がります。
— Learn Premium テキストより

実際の開発では、コードを書く前に docs/ フォルダに以下のような設計書を作成します。

concept.md 何を、なぜ作るか	プロダクトの核心。「閉じた学習ループ」のように、設計のWhyを言語化する。
architecture.md どう作るか	レイヤー構造、依存関係のルール、外部サービスとの接続方針。
data-schema.md データの形	主要な型の定義と、具体的なサンプルデータ（JSON例）。
CLAUDE.md プロジェクトルール	AIエージェントが常に参照する制約と規約。永続コンテキスト。

これらのファイルは、会話が長くなって古い文脈が圧縮されても、ファイルとして残り続けます。AIはいつでも読み直せます。コンテキストウィンドウの中身は揮発するが、ファイルシステムのコンテキストは永続する——この区別が重要です。

さらに、これらの設計書は一人で書くものではありません。AIとの壁打ちの中で育てていきます。

設計書は「AIが書く」のではなく「AIと一緒に書く」。
あなたが「何を」「なぜ」作りたいのかを伝え、
AIがそれを構造化する——この協働が、良い設計書を生む。
— Learn Premium テキストより

調査して、壁打ちして、設計書を修正する。このループを回すたびに、コンテキストの質が上がります。ランタイムにコンテキストウィンドウに何を「詰めるか」の前に、そこに詰める価値のあるコンテキストを「練り上げる」プロセスがあります。

当ラボの法人コンサルティングでは、これをさらに進めて、設計書の執筆を開発の主工程として扱っています。コーディングは、精密に書かれた設計書を機械語に変換する——いわばコンパイルする——工程です。AIエージェントの性能が上がるほど、このコンパイルの精度は上がります。差がつくのは、コンパイル元の設計書の質だけです。

Two Layers

2つの層。

コンテキストエンジニアリングには、2つの層があります。

Runtime コンテキストの管理	AIが動く瞬間に、コンテキストウィンドウに何を入れ、何を外すか。システムプロンプト、RAG、ツール定義、トークン予算の最適化。業界の議論はここに集中している。
Design-Time コンテキストの創造	AIと協働する前に（そして協働しながら）、管理すべきコンテキストそのものを著作するプロセス。設計書、ルールファイル、データスキーマ、制約の明示。この層の体系化はまだ進んでいない。

ランタイム層の技術は進歩が速く、RAGの精度は上がり、ツール定義の設計パターンは整理され、トークン予算の自動管理も実用段階に入っています。

しかし、どれだけランタイムの最適化を極めても、注入すべき良質なコンテキストが存在しなければ、最適化は空回りします。RAGで引っ張るドキュメントの質が低ければ、検索精度を上げても出力は改善しません。システムプロンプトに書く制約が曖昧なら、書き方を洗練しても意味がありません。

デザインタイム層は、ランタイム層の前提条件です。

Prompt Engineering Is Not Dead

プロンプトエンジニアリングは
死んでいない。

「プロンプトエンジニアリングはもう古い」——この見出しが量産されています。半分は正しく、半分はミスリードです。

古くなったもの: 特定のフレーズを入れるとスコアが上がる、という「魔法の呪文」探し。モデルの進化でコモディティ化しました。

古くなっていないもの: AIに何を、どう伝えるかという設計力。制約を明示する。要件を構造化する。AIの前提を検証する。これらは今もプロンプト設計の核であり、コンテキストエンジニアリングの構成要素です。

プロンプトは不要になったのではなく、コンテキストという上位概念に包摂されました。プロンプトはコンテキストの一部であり、コンテキスト全体を設計する視点から見れば、一要素にすぎません。

当ラボが策定してきた prompt-as-code（プロンプト構文標準）は、プロンプトを「書き捨てのテキスト」ではなく「実行可能なコード」として扱う試みです。この方向性は、コンテキストエンジニアリングの文脈でむしろ重要性を増しています。ランタイムに注入されるプロンプト——システムプロンプト、ツール定義、エージェント間の指示——が増えるほど、その構文と品質を規律する仕組みが必要になるからです。

実際、prompt-as-code v0.3.0（2025年12月公開）の仕様には、コンテキストエンジニアリングの主要な構成要素がすでに記述されています。§5（Structuring Patterns）はコンテキストの構造化パターンを、§6（Structured Reasoning）は Chain of Verification 等の検証ループ設計を、§7（Prompt Chaining）は多段プロンプトにおける文脈管理とデータ依存の追跡を扱っています。これらは「コンテキストエンジニアリング」という用語が業界に広まる前に、プロンプトの構文標準という視点から体系化されたものです。

What We Teach

Lab が教えていること。

当ラボの Learn Premium および法人コンサルティングでは、ランタイム層とデザインタイム層の両方を扱っています。ただし、軸足はデザインタイム側にあります。

教えているのは、用語ではなく型です。

コードの前にドキュメントを書く	実行の前にコンテキストを作る
AIに「本当に調べたのか？」と問う	コンテキストの品質を検証する
AIの暴走を止める	コンテキストの境界（スコープ）を守る
テスト設計を人間が行う	検証基準というコンテキストを自分で設定する
調査 → 壁打ち → 再調査を繰り返す	コンテキストを反復的に練り上げる

これらは「AIの使い方」であると同時に、部下のマネジメント、プロジェクトの方向性制御、意思決定の品質管理に通じる普遍的なスキルです。用語が変わっても、型は残ります。

コンテキストエンジニアリングという言葉自体は、いずれまた別の言葉に置き換わるかもしれません。しかし、その核にある問い——AIに何を知らせ、何を知らせないかを、誰がどうやって決めるのか——は、AIと協働する限り消えません。

その問いに対する答えは、ランタイムの最適化だけでは得られません。コンテキストウィンドウの中身を操作する技術の手前に、そこに入れるべきものを丁寧に作る仕事があります。

Lab は、その仕事を教えています。

コンテキストエンジニアリングの議論に欠けているもの.