コンテキスト駆動エンジニアリング（Context Driven Engineering、CDE）とは、ある実務家の概観記事が、開発者がエージェントにプロンプトを与えるのではなく、完全なコンテキスト — 意図と、作業が守るべき制約（コーディングガイドライン、使用すべきツール、従うべきドキュメントなど） — を供給する AI 支援ソフトウェア開発に対して用いている名称である。2026 年のソフトウェアエンジニアリングの最先端に AI が与える影響 の記述では、これは エージェント型エンジニアリング（エージェント型エンジニアリング）と並んで、現在 バイブコーディング（バイブコーディング）に代わって人々が用いている用語として紹介されており、その掲げる目的は、プロセスの非決定的な部分を減らし、生み出されるものの品質をより信頼できるものにすることである。同記述において、その決定的な帰結は、仕様が再び第一級の存在となり、コードを書く前の義務となることである。
用法
この名称のもとで実践を描く同記事は、チームをまたいで繰り返し見られるという三段階のワークフロー、すなわち spec（仕様）、plan（計画）、act（実行） を通じてそれを説明している。仕様はユースケースとチームの意図をまとめたもので、企業によって RFC、ADR、PRD などと呼び方は異なり、通常はプロダクトの専門家がレビューする。計画は仕様を実装するのに必要なすべてのステップを列挙したもので、各ステップは十分なコンテキストがあればエージェントが単独で達成できるものとされ、通常はアーキテクト、スタッフエンジニア、テックリードといったシニアエンジニアがレビューする。実行ステップは実装であり、エージェントを用いたセッションの中で、変更を一つずつ承認していくコパイロットモードか、開発者が意図を伝えたあとで結果を確認するエージェントモードのいずれかで行われる。チームによってこのパターンには変化があり、記事で紹介されているある企業は、作業を elaborate（精緻化）、plan（計画）、implement（実装）、assert（検証）、review（レビュー）、learn（学習）、push（プッシュ）のステップに分けている。
仕様以外にも、この意味でのコンテキストには、同記事が AI ルールのエコシステムと呼ぶもの — アシスタントごとのコンテキストファイルと共通の AGENTS.md 規約、スキル、専門化されたエージェント、MCP サーバー — が含まれる。また同記事によれば、この実践はテストハーネスやリンターといった従来のエンジニアリングプラクティスを再び前面に押し出すものであり、それらなしにはコードやアーキテクチャの品質を担保できない。これとは別に、同記事は、指示が頻繁に無視されたり誤読されたりするため、チームがエージェントの周りでリンティング、テストハーネス、コードレビューを必須にしていることも報告している。
適用される場面
記述されているとおり、CDE は、AI 支援コーディングを個人の利用から工業化されたチームの実践へと移行させようとしているチームに当てはまる。それは、チームが自らの意図と制約を明示的に書き出せること、そしてエージェントの出力をそれらに照らして確認するのに必要なハーネス — テスト、リンティング、レビュー — を備えていることを前提としている。
同記事自身の注意点は過剰な仕様化に関するものである。この種のワークフローを構造化するためによく挙げられる二つのツール、BMAD と Spec Kit を試した著者は、それらが冗長な過剰ドキュメントを容易に生み出し、開発サイクルを遅らせうることに気づき、AI に向けた仕様は単純で曖昧さのないものでなければならないと論じている。その結論は失敗のあり方を率直に述べている。チームが自分たちが何をしたいのか、そしてそれをどう実現するつもりなのかを説明できなければ、AI はそのチームを救うどころか、工業的な速度で技術的負債を生み出すことになる。
定着の度合い：この名称は一人の実務家の概観記事で用いられているものであり、同記事は自らがこれを造語したと主張するのではなく、コンテキストエンジニアリングやエージェント型エンジニアリングをめぐるより広い議論と結び付けている。同記事は spec/plan/act のワークフローを、主として実務家たち自身の公開された文章からの引用と、協力した一企業による独自の変種の説明によって裏付けており、そのいずれも計測に基づく比較ではない。