同じAIツールを使っているのに、出てくるコードの質が人によって10倍違う。その差はプロンプトの巧拙ではなく、AIに渡す情報——コンテキスト——の設計にある。
プロンプトを磨くだけでは、もう足りない
「もっといいプロンプトを書けば、もっといい出力が得られる」という考え方がある。確かに間違いではないが、それだけでは限界がある。
AIコーディングツールが急速に普及し、開発者の73%がAIツールを毎日使う時代になった。全新規コードの41%がAI生成という数字まで出ている。これだけ浸透すると、「AIを使うかどうか」ではなく「AIをどう使うか」の差が、そのまま生産性の差になる。
その「どう使うか」の核心にあるのが、コンテキストエンジニアリングという概念だ。
コンテキストエンジニアリングとは何か
ThoughtworksのAI assisted Software Delivery Global LeadであるBirgitta Böckelerは、2026年2月にMartin Fowlerのサイトで公開した技術記事の中で、コンテキストエンジニアリングを次のように定義している。
「モデルやエージェントが読む情報をキュレーションして、より良い結果を得る実践」
そして2026年3月のQCon London基調講演では、これを「AIコーディングにおける1年で最も重要な発展」と評した。
Böckelerの記事が発表された直後、Andrej Karpathy（バイブコーディングという言葉を広めたOpenAI共同創業者）も同様の視点を表明し、「コンテキストウィンドウに何を詰め込むかの設計こそが重要」と述べている。ShopifyのCEO Tobi Lütkeも社内メモで「コンテキストエンジニアリングはすべてのエンジニアが持つべきコアコンピテンシー」と言及した。
「コンテキスト」とは、AIが作業を開始する前に読んでいる情報のすべてを指す。CLAUDE.mdやruleファイル、スキルファイル、会話の履歴、MCPサーバーから取得したデータ——これらが全部コンテキストだ。
プロンプトエンジニアリングとは何が違うか
プロンプトエンジニアリングは「何を言うか」の技術だ。一方、コンテキストエンジニアリングは「何を読ませるか」の設計だ。
新入社員で考えるとわかりやすい。プロンプトエンジニアリングは、毎回仕事を頼むときに口頭で詳しく説明すること。コンテキストエンジニアリングは、事前に丁寧な引き継ぎ書を渡しておくことだ。口頭指示がうまくても、引き継ぎ書がなければ毎回ゼロから説明しなければならない。引き継ぎ書がしっかりしていれば、一言「あの件よろしく」と言うだけで仕事が動く。
AIも同じだ。コンテキストが整備されていれば、指示は短くてすむ。整備されていなければ、毎回長い説明が必要になり、それでも「チームの規約を無視したコード」が生成されることになる。
なぜ2026年に急浮上したのか
理由の一つは、AIエージェントの自律化が進んだことだ。単純な「コード補完」から、複数のファイルを横断して自律的に作業する「エージェント型」に移行すると、AIが参照する情報の量と質が、直接的に成果の質に影響するようになった。
もう一つは、コストの問題だ。
QCon London 2026でBöckelerが示したデータによると、2024年当時は生成コード100行あたり約12セントだったClaude Codeのコストが、2026年現在では1日あたり約380ドル（年換算で約9万1,200ドル）にまで上がっている。
そして驚きの数字がある。新鮮なClaude Codeセッションは、ユーザーが1文字も入力していない段階で、すでにコンテキストウィンドウの15%を消費しているというのだ。
コンテキストウィンドウは「机の上のスペース」のようなものだ。限られたスペースに何でも広げていたら、重要な書類が見つからなくなる。最初から15%が消えているなら、残りのスペースをどう使うかが勝負になる。ここで無駄に情報を詰め込めば、後半の情報はAIに「読んでいるが理解していない」状態になる。
3層のコンテキスト設計
BöckelerはClaude Codeにおけるコンテキスト設定の7つの方法を整理している。これを「誰がいつロードするか」という観点で3層に分けると実践しやすい。
この3層を意識して設計するかどうかが、コンテキストエンジニアリングの入口だ。
コード例1: CLAUDE.mdに詰め込みすぎていないか
多くのプロジェクトで見られる問題が、CLAUDE.mdへの情報詰め込みだ。
❌ 悪い例: CLAUDE.md（300行）に全情報を入れる
## 開発コマンド
bun run dev / bun run build / bun run test / ...
## アーキテクチャ（詳細説明100行）
Feature-Sliced Design を採用。app レイヤーは...
## デプロイ手順（詳細50行）
1. ステージング確認 / 2. 本番push / 3. ...
## テスト規約（80行）
...
## セキュリティチェックリスト（60行）
...
→ 常時コンテキストの30〜40%を消費。後半のルールはAIに無視される
✅ 良い例: 役割に応じて分散させる
# CLAUDE.md（30行以内）
# → 常時オン。プロジェクト固有の不変ルールのみ
# 例: アーキテクチャ概要、禁止事項、重要な依存関係
# .claude/rules/typescript.md
# → TypeScriptファイルを開いた時だけ自動ロード
# .claude/skills/deploy/SKILL.md
# → 「ステージングにデプロイして」と言った時だけ読む
# .claude/settings.json (hooks)
# → git commit 前に自動でテスト実行・ブロック
この設計の効果は数字にも表れる。Boliv Substackの分析によると、200Kトークンのコンテキストウィンドウで全スキルを常時ロードすると10.5%を消費するのに対し、必要時だけ読む「Lazy Skills」方式では0.3%に抑えられる。コンテキストの無駄遣いを35倍削減できる計算だ。
コード例2: コンテキストの有無で何が変わるか
「コンテキスト設計」と言うと抽象的に聞こえるが、実際の差はこういうことだ。
❌ コンテキスト未整備の状態で「Next.jsのAPIルートを書いて」
AIが生成するもの:
- zodバリデーションなし（チームの規約は「zodを必ず使う」なのに）
- エラーハンドリングがバラバラ（チームはAppErrorクラスで統一しているのに）
- axiosを使ったコード（チームはfetchに移行済みなのに）
- 接続先URLがハードコード（環境変数を使う規約なのに）
→ 動きはするが、レビューで全部指摘されて書き直しになる
✅ CLAUDE.mdに以下を記載した状態で同じ指示
# CLAUDE.md に書いてあること:
- バリデーションはzodを使用。必須
- エラーはAppErrorクラスで統一（src/shared/lib/error.ts）
- axiosは廃止済み。fetchまたはofetchを使う
- 外部URLは必ず環境変数経由
「Next.jsのAPIルートを書いて」
→ チームの規約に沿った実装が最初の出力で出てくる。レビューの手戻りがない
毎回プロンプトで「zodを使ってね、エラーはAppErrorで、axiosは使わないで...」と指示するより、一度CLAUDE.mdに書いておく方が確実で効率的だ。これがコンテキストエンジニアリングの基本だ。
落とし穴: 情報を詰め込めば詰め込むほどよいわけではない
「じゃあ、なるべく多くの情報を入れればいい」——そう思うかもしれないが、そうではない。
ETH Zurichの研究をInfoQが報告したところによると、LLMが自動生成したAGENTS.mdファイル（コンテキストファイルの一種）を使うと、コンテキストファイルなしの場合と比べてタスク成功率が平均3%低下し、推論コストが20%以上増加するという結果が出た。情報を詰め込んだはずが、かえってパフォーマンスが下がったのだ。
コンテキストファイルは「とにかく増やす」ものではない。AIが自分の判断で推論できる情報は書かなくていい。書くべきは「AIが知らないはずの情報」——プロジェクト固有の規約、特殊なツール設定、チームの決定事項——だけだ。
研究者たちは「コンテキストファイルは、AIが自力では推測できない情報（特殊なツールや独自ビルドコマンドなど）に限定すべき」と結論づけている。
エージェントとセキュリティの問題
コンテキスト設計が重要なもう一つの理由が、セキュリティだ。
QCon 2026でBöckelerが指摘したことだが、エージェント関連のセキュリティインシデントが週次で発生するようになった。そのほとんどの根本原因はプロンプトインジェクション——外部から悪意ある指示がコンテキストに混入し、AIが予期しない動作をする攻撃だ。
コンテキストに何をどこから入れるか、その設計が甘いと、AIは本来の指示ではなく、外部から注入された指示に従ってしまう。
チームでコンテキストを育てる
コンテキストエンジニアリングで重要なのは、一度設定して終わりではなく、チームで継続的に育てることだ。
CLAUDE.mdやruleファイルをGitで管理するというのは、「AIへの引き継ぎ書をチーム全員で書いて、バージョン管理する」ということだ。新しいメンバーが入ってきたとき、チームの規約をAIに一から教えるのではなく、既存のコンテキストファイルが自動でAIに引き継がれる。
Kiro（AWSのAIコーディングツール）が採用した「Steering files」や、Cursorの「SKILL.md」も、この思想の具体的な実装だ。ツールの名前は違うが、やっていることは同じ——「AIが参照すべき情報を、いつ、どこに、どうやって渡すか」の設計だ。
AIが「賢い」より、AIに「何を渡すか」が勝負を決める
バイブコーディングは「AIに話しかければ動くものができる」という体験を多くの人に届けた。その先のフェーズでは、AIの性能よりも、AIに渡すコンテキストの質が出力を決める。
プロンプトを磨く時間を、コンテキスト設計にシフトする。CLAUDE.mdを30行以内に保ち、詳細はruleファイルやskillファイルに分散させる。チームで共通のコンテキストをGitで育てる。
コンテキストエンジニアリングは難しい概念ではない。「AIへの引き継ぎ書を、正しい形で渡す」という、それだけのことだ。