Nguyen Le Phong

コンテキストエンジニアリング:AIを使いこなせる人とそうでない人の差

AIの結果が期待外れなのは、モデルが悪いからではなく、コンテキストが薄いからです。コンテキストエンジニアリングの実践ガイド——モデルのウィンドウに何があるか、優れたコンテキストの5つの柱、よくあるアンチパターン、そして一貫して良い結果を生む再利用可能なテンプレート。

心当たりがあるはずです。明確に思えた質問をAIに投げかけると、返ってくる答えは…微妙にずれている。技術的には関連しているのに、肝心な点を外している。そこで言い換える。再試行する。またずれた答えが来る。五回のやりとりを経てようやく使えるものが得られるが、最初から自分でやった方が早かった。

実際に何が起きているかというと、モデルは目の前に置かれた情報だけで動くのです。あなたのコードベースがどんな構造か、どんな制約があるか、何を試したか、なぜ聞いているのか——モデルには一切わかりません。AIの回答が的外れになる根本原因は、ほぼ例外なく情報不足です。言葉の選び方でも、呪文のようなプロンプト術でもありません。これが、AIコミュニティがコンテキストエンジニアリングと呼ぶスキルの核心です。

定義

コンテキストエンジニアリングとは、AIに与える情報——役割、背景状態、タスク、制約、出力形式——を意図的に設計する技術です。やりとりを重ねることなく、一発で genuinely 有用な結果を引き出すことを目的とします。

コンテキストエンジニアリングとは何か

2025年にAndrej Karpathyが広めたこの用語は、「プロンプトエンジニアリング」との違いが重要です。プロンプトエンジニアリングは言葉の選び方の話。コンテキストエンジニアリングは一段深く、どんな情報を提供するかの話です。モデルが生成を始める前に、必要な情報をすべて整えておくスキルです。

ミザンプラス(料理前の仕込み)で考えてみてください。優れたシェフは料理を始める前に、すべての食材を準備しておきます。コンテキストエンジニアリングは、AIというパートナーのためにその仕込みをする行為です。

コンテキストウィンドウの解剖

AIとのすべてのやりとりは「コンテキストウィンドウ」という作業メモリの中で行われます。四つの層に分かれています。

Four layers inside an AI context window: System Prompt, Injected Context, Conversation History, and User Message feed into the LLM to produce a response. CONTEXT WINDOW — everything the model sees before writing a single word ROLE System Prompt Persona, role, standing instructions — the model's "constitution" for this session DOCS Injected Context Files, search results, tool outputs, docs — raw material the model reasons over MEM Conversation History Prior messages, decisions — working memory of everything that has happened so far TASK User Message The actual question or task — often under 5% of total tokens, but triggers everything LLM attention + generation Response quality = f(context quality) All four layers share the same token budget. Context engineering is choosing wisely.
コンテキストウィンドウの四層。多くの人は第4層(ユーザーメッセージ)だけに集中しますが、最も強力で見落とされがちなのは第1・第2層です。

システムプロンプトは最も強力でありながら最も見過ごされる層です。モデルのペルソナ、専門知識レベル、およびすべての応答を支配するルールを設定します。

注入コンテキストはコードファイル、ドキュメント、エラーログなどの原材料を提供する層です。モデルがこの情報を元に推論します。

会話履歴はセッションが進むにつれて蓄積されます。有用ですが、トークンコストが高い層です。

ユーザーメッセージは実際の質問やタスクです。最も注目されますが、うまく設計されたセットアップではトークン全体の5%未満です。

優れたコンテキストの5つの柱

The five pillars of great context: Role, State, Task, Constraints, Format. 1 Role Who should the model behave as? 2 State What's known, decided, or already tried? 3 Task What exactly do you want done? MOST CRITICAL 4 Constraints What to avoid, scope limits, hard rules 5 Format Output shape, length, level of detail
コンテキストの5つの柱。第3柱(タスク)が最も注目されますが、残りの4柱がそのタスクをうまく答えられるものにします。

第1柱:役割(Role)

モデルが誰として振る舞うべきかを定義します——専門知識、視点、コミュニケーションスタイル。

役割なし役割あり
認証を説明して。あなたはセキュリティ専門のシニアバックエンドエンジニアです。JavaScriptは知っているがauth実装は初めてのジュニア開発者向けに、JWTのセキュリティトレードオフと注意点を説明してください。

第2柱:状態(State)

現在の状況を伝えます——コードベースの構造、試したこと、うまくいかなかったこと、決定済みの事項。

状態なし状態あり
このバグを直して。
(コードのみ貼り付け)
[コード] このdebounce関数は通常の入力では動くが、高速スクロールでは待機せずに即時発火する。clearTimeoutを試したが改善しない。React 18、TypeScript。コンソールエラー:[メッセージ]。

第3柱:タスク(Task)

何が欲しいかを正確に指定します。「APIを助けて」はカテゴリ。「JWTトークンを検証し、無効または欠落の場合は401を返し、デコードされたユーザーをreq.userに添付するExpressミドルウェアを書いて」がタスクです。

第4柱:制約(Constraints)

何をしてはいけないか、スコープの制限、絶対ルールを伝えます。制約は制限のように聞こえますが、実際には応答を解放します——「技術的には正しいが私の状況では使えない」という回答クラスを丸ごと排除するからです。

制約の書き方

「〜しないでください」「〜を避けてください」という否定の明示文で書きましょう。モデルはスコープを広げる方向に学習されています。明示的な否定が最も信頼できるガードレールです。

第5柱:形式(Format)

出力の形を指定します——長さ、構造、詳細レベル。形式の指定がなければ、モデルが「適切」と判断するものが返ってきます——あなたが望む形ではないかもしれません。

再利用可能なコンテキストテンプレート

## 役割
あなたは [役割]、[ドメイン] の専門家です。
対象読者は [読者] です。

## 背景状態
技術スタック: [言語 / フレームワーク]
現状: [簡単な説明]
試したこと: [試みと結果]
関連エラー: [あれば]

## タスク
[1文で正確に: 動詞 + 対象 + 範囲]

## 制約
- [ライブラリ/アプローチ] は使わないでください
- [側面] を [上限] 以内に保ってください

## 出力形式
[長さ] — [構造] — [詳細レベル]

重要なポイント

  • コンテキストエンジニアリング > プロンプトエンジニアリング: 言葉の選び方より、提供する情報の方が重要です。
  • 4層、1つのバジェット: システムプロンプト、注入コンテキスト、会話履歴、ユーザーメッセージ——それぞれ役割が異なり、同じトークンを競っています。
  • 5つの柱、5つのギャップ: Role、State、Task、Constraints、Format。すべてをカバーすれば、やりとりの回数が劇的に減ります。
  • 量より質: 関連性が高く焦点を絞ったコンテキストは、大量の無焦点なコンテキストを常に上回ります。
記事はいかがでしたか?

よくある質問

What is context engineering and why does it matter for developers?
Context engineering is the skill of deliberately designing the information you provide to an AI — its role, background state, task, constraints, and output format — so it produces useful results without back-and-forth. It matters because the quality of AI output is almost entirely determined by the quality of input: vague, thin context produces generic, off-target answers, while rich, structured context produces specific, actionable ones. Most developers underestimate this and focus on rephrasing prompts instead.
What is the difference between context engineering and prompt engineering?
Prompt engineering is about word choice — how to phrase a request so the model interprets it correctly. Context engineering is a level deeper: it's about what information you make available before the model generates anything. You can have a perfectly phrased prompt and still get a poor answer because the model lacks background, state, or constraints. Context engineering addresses the information architecture; prompt engineering addresses the wording within it.
What are the five pillars of great context?
The five pillars are: (1) Role — who the model should be (persona, expertise, audience perspective); (2) State — what already exists, what's been tried, what constraints apply; (3) Task — exactly what you want done, not a vague category; (4) Constraints — what to avoid, scope limits, hard rules; (5) Format — the shape of the output (length, structure, level of detail). Addressing all five reduces back-and-forth dramatically and improves first-draft quality.
How do I build a reusable context template?
Structure your template around the five pillars: Role (who the model is and for whom), Background State (tech stack, what exists, what's been tried), Task (one precise sentence), Constraints (explicit negatives: what not to do), and Output Format (length, structure, detail level). You don't need to fill in every field every time — for a simple lookup, role + task + format is enough. For complex debugging or code review, all five matter. The template is a scaffold, not a form.
What does 'token budget' mean in context engineering?
Every interaction with an AI happens inside a context window with a fixed size measured in tokens. Everything you include — the system prompt, pasted code, conversation history, your question — competes for space in that window. Token budget management means being selective about what you include: paste specific functions rather than whole files, strip boilerplate from pasted code, summarize conversation history after long sessions, and put standing instructions in the system prompt rather than repeating them per-message. Irrelevant content isn't neutral — it's noise the model has to reason through.