コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い

紹介ポスト: えいと @7_eito_7 「AIを使っている人と、本当にAIを使いこなしている人の違いは何か。結論はコンテキストエンジニアリングができるかどうか。簡単に言えば、指示の出し方ではなくどんな文脈を渡しているか。」

はじめに

2025年半ば、Shopify CEO の Tobi Lütke が次のように発言した:

「“プロンプトエンジニアリング"より"コンテキストエンジニアリング"という言葉の方がずっと好きだ。LLM がタスクを解決できるだけの十分な文脈を与える技術 — これこそが核心的スキルだ。」

AI 研究者の Andrej Karpathy もこれに同意し、「コンテキストエンジニアリング」という概念は一気に広まった。2026年現在、プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが AI 活用の新しい標準になりつつある。

プロンプトエンジニアリング vs コンテキストエンジニアリング

観点プロンプトエンジニアリングコンテキストエンジニアリング
スコープ1つの入力テキストの書き方モデルが見る情報の全体設計
焦点指示の言い回し・構造情報の選択・順序・形式・量
対象単発の質疑応答複雑な推論、マルチターン、エージェント
複雑さ文章レベルシステムレベルのパイプライン
例え「質問の仕方を工夫する」「解答に必要な教科書・資料・道具を揃える」

プロンプトエンジニアリングはコンテキストエンジニアリングの一部にすぎない。質問の質ではなく、AI に渡す情報の質と構造が結果を決める。

なぜプロンプトだけでは不十分なのか

よくある問題: RAG で正確な情報を取得し、プロンプトも丁寧に書いた。それでも AI がハルシネーションを起こす。

原因はプロンプトでも検索でもなく、コンテキストの構造にある。

プロンプトの 3 つの限界

  1. 情報不足: 質問は完璧でも、判断に必要な背景情報が足りない
  2. 情報過多: 関連情報を全部詰め込むと、かえって精度が落ちる（ノイズに埋もれる）
  3. 情報の無秩序: 重要な情報とそうでない情報が区別なく並んでいる

コンテキストエンジニアリングは、この 3 つを体系的に解決する。

コンテキストエンジニアリングの 4 つの柱

1. 構成（Composition）— 何を渡すか

タスクに必要な「材料」を選択する:

  • 関連ドキュメント・コードベース
  • ツール定義（使える機能の説明）
  • 過去の会話履歴
  • メタデータ（日時、ユーザー情報、プロジェクト構成）

ポイント: 「全部渡す」のではなく、今のタスクに関係あるものだけを厳選する。

2. 優先順位（Ranking & Relevance）— 何を重視するか

すべての情報が等しく重要なわけではない:

  • 埋め込みベクトルの類似度でフィルタリング
  • 重要度による重み付け
  • 時系列の新しさによる優先順位付け

ポイント: AI に「これが最も重要」というシグナルを明確に伝える。

3. 最適化（Optimization）— どう圧縮するか

トークンには上限がある。限られた枠を最大限活用する:

  • 要約・圧縮による効率的な表現
  • 段階的開示（まず概要、必要に応じて詳細）
  • 不要な情報の積極的な削除

ポイント: 情報を増やすのではなく、密度を上げる。

4. オーケストレーション（Orchestration）— いつ・どう組み立てるか

実行時にタスクの状態に応じてコンテキストを動的に組み立てる:

  • ツールの実行結果を次のステップのコンテキストに反映
  • マルチステップの推論で段階的に情報を追加
  • 状況に応じたメモリの読み書き

ポイント: コンテキストは静的なものではなく、タスクの進行とともに変化する。

実践例: Claude Code における コンテキストエンジニアリング

Claude Code のエコシステムは、コンテキストエンジニアリングの実践そのもの:

CLAUDE.md = プロジェクトコンテキスト

1
2
3
4
5
6
7
8
9

# プロジェクト概要
- バックエンド: Python (Django)
- API: GraphQL (Strawberry)
- テストフレームワーク: pytest
- コミットメッセージ: Conventional Commits に従う

# やってはいけないこと
- 既存のテストを削除しない
- 環境変数をハードコードしない

これはプロンプトではない。AI が判断するための背景知識（コンテキスト）である。

Agent Skills = タスクコンテキスト

SKILL.md に「このタスクではこう動け」という手順を書く。AI は必要な時だけスキルを読み込む（段階的開示）。

MCP = ツールコンテキスト

MCP サーバーで「AI が何にアクセスできるか」を定義する。DB、Slack、GitHub など、タスクに応じた道具を揃える。

3 層のコンテキスト構造

層担当内容
CLAUDE.mdプロジェクトの前提技術スタック、規約、禁止事項
Agent Skillsタスクの手順特定作業のやり方（段階的に読み込み）
MCPツールの能力外部システムとの接続

プロンプトで「上手に聞く」のではなく、3 層のコンテキストで AI の世界を設計する。

6 つの実践テクニック

1. 階層的な情報レイアウト

最も重要な情報を最初に、詳細は後から。AI は先頭の情報を重視する傾向がある。

2. 動的コンテキスト選択

毎回同じコンテキストを渡すのではなく、タスクの内容に応じて動的に選択する。Agent Skills の段階的開示はまさにこれ。

3. コンテキスト圧縮

冗長な情報を要約し、トークンあたりの情報密度を高める。「100行の生ログ」より「5行の要約+異常値のハイライト」の方が効果的。

4. メモリ管理

短期記憶（現在の会話）と長期記憶（CLAUDE.md、過去の知見）を分離して管理する。

5. コンテキストマスキング

タスクに無関係な情報を積極的に隠す。「見せない」ことも重要な設計判断。

6. フィードバックループ

AI の出力を評価し、次のコンテキストに反映する。Boris Cherny の「Claude に CLAUDE.md を更新させる」はこの実践。

コンテキストエンジニアリングの限界

万能ではない。以下の問題は解決できない:

  • ハルシネーションの完全排除 — 軽減はできるが、根絶はモデル自体の課題
  • 学習データの偏り — コンテキストで補正はできるが、根本的な修正は不可能
  • モデルの能力上限 — 文脈を完璧にしても、モデルが理解できないタスクは解けない

コンテキストエンジニアリングは「AI を賢くする」のではなく、**「AI が持っている能力を最大限引き出す」**技術。

まとめ — 今日からできること

  1. CLAUDE.md を書く — プロジェクトの前提知識を整理して渡す
  2. 情報を厳選する — 「全部渡す」のをやめ、タスクに関係あるものだけ渡す
  3. 構造化する — 重要なことを先に、詳細は後から
  4. フィードバックを蓄積する — AI が間違えたら「次から間違えないルール」を記録する
  5. 段階的開示を意識する — 一度に全部ではなく、必要に応じて情報を渡す

AI を使いこなす鍵は「上手に聞くこと」ではなく、「何を知った状態で考えさせるか」を設計すること。それがコンテキストエンジニアリング。

参考リンク