2026-09-21 追記: 記事を見直しました
- 実測値や効果の記述に、観測の範囲（私の環境・計測方法）を明記しました
- 示した根拠の範囲を超えていた断定表現を、事実に合わせて弱めました
- 本文に混入していた内部向けの語・不要な記号を取り除きました
内容の骨子は変えていません。
同じLLMに同じ質問をしても、返ってくる答えの質がまるで違う——そんな経験はないでしょうか。
私はAIエージェント環境を1年ほど個人で運用してきて、精度を左右していたのはプロンプトの言い回しではなく、そのモデルが何を見せられているか、つまり「コンテキストの設計」だと確信するようになりました。プロンプトを何度も磨いても頭打ちだったタスクが、渡す情報の構造を変えた瞬間に安定する。この「渡し方の設計」こそが、いま話題のコンテキストエンジニアリングです。
この記事では、バズワードの解説で終わらせず、CLAUDE.md・引き継ぎメモ・ナレッジ検索といった具体的な仕組みと、実際に効いた数字をセットで共有します。
プロンプトエンジニアリングとの違いを一枚で
まず両者の役割分担を整理します。対立ではなく、レイヤーが違うと捉えるのが実感に近いです。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 対象 | 一回の指示の書き方 | モデルが見る情報環境そのもの |
| 主な問い | 「どう頼むか」 | 「何を・どの順で・どれだけ見せるか」 |
| 代表テクニック | 役割付与、Few-shot、CoT | 永続ルール、記憶の外部化、検索(RAG)、コンテキスト圧縮 |
| 効きどころ | 単発タスクの精度 | セッションをまたぐ一貫性・コスト |
| 寿命 | その場の指示としては会話限り（テンプレ化すれば再利用も可） | ファイルとして資産になりやすい |
プロンプトエンジニアリングは主に指示文や提示例（Few-shot）そのものの設計、コンテキストエンジニアリングは検索結果・会話履歴・ツール実行結果を含む「入力全体」の設計に重心があります。プロンプトも再利用可能なテンプレートやCLAUDE.mdに組み込めるため、両者は排他的ではなく重なる領域です。とはいえ、継続的にAIを使うプロジェクトほど、後者（入力全体の設計）に投資する価値が大きいというのが私の実感です。
コンテキストを構成する4レイヤー（チートシート）
私が実際に運用しているコンテキストは、大きく4層に分けられます。まずは早見表として。
| レイヤー | 役割 | 実装の例 | 更新頻度 |
|---|---|---|---|
| ① 永続コンテキスト | 常に効く前提・規約 | CLAUDE.md |
低（設計変更時） |
| ② 作業記憶 | 直近の文脈・引き継ぎ | handoff.md |
毎セッション |
| ③ 参照知識 | 必要な時だけ引く | ナレッジ検索 / RAG | 随時追記 |
| ④ 動的コンテキスト | その場で確定させる情報 | 出力例・要件整理 | タスクごと |
「全部を毎回渡す」のではなく、レイヤーごとに流量を分けるのがポイントです。ただし①〜④の「いつ読まれるか」はツールの仕様次第で、一律に決め打ちできる話ではありません。たとえば私が使っているClaude Codeの場合（公式ドキュメント code.claude.com/docs/en/memory 参照時点の仕様）、作業ディレクトリとその上位ディレクトリにあるCLAUDE.mdはセッション開始時に読み込まれますが、作業ディレクトリ配下のサブディレクトリに置いたCLAUDE.mdはセッション開始時には読まれず、そのサブディレクトリ内のファイルを実際に読んだタイミングで読み込まれます。つまり同じ①永続コンテキストでも、置き場所によって「常時」なのか「必要時」なのかが変わります。以下は、この仕様を前提にした私の運用（Claude Code）での実装と数字です。
① 永続コンテキスト：前提を「引き継ぎ書」にする
最初に手を付けるべきは、毎回同じ説明を繰り返している前提の外部化です。
新規プロジェクトでAIを導入した当初、私は技術スタックやディレクトリ構成、禁止事項を毎セッション口頭で説明していて、1回あたり5〜10分を溶かしていました。そこでプロジェクトルートに約200行のルールファイル（CLAUDE.md）を置き、「AIへの引き継ぎ書」として書き直したところ、開始時の前提説明がまるごと不要になり、1日あたり約30分が浮きました。副産物として、生成コードの一貫性も目に見えて上がりました。
# CLAUDE.md（永続コンテキストの骨格）
## 技術スタック
- 言語 / フレームワーク / DB / インフラ …
## コーディング規約
- 命名・テスト方針・エラーハンドリングの型
## 禁止事項（IMPORTANT）
- 直接本番に触れない / 破壊的コマンドは確認を挟む …
コツは、新人エンジニアへの引き継ぎ書と同じ感覚で書くこと。「言わなくても分かるはず」を全部言語化すると精度が上がります。
失敗談：肥大化して逆に遅くなった
ただしこのファイル、放置すると膨らみます。私も一度500行を超えてしまい、応答が遅くなり、指示の優先度も曖昧になって規約違反が増えました。対処は階層化です。ルートには方針だけを残し、詳細はサブディレクトリ側のCLAUDE.mdに分割、優先度の高い制約は冒頭に IMPORTANT として置きました。前述の通り、サブディレクトリのCLAUDE.mdはそこのファイルを読むまで読み込まれない仕様なので、分割すること自体が「毎回読まれる量」を減らす直接的な対策になります。結果、体感で応答速度が1.5倍に戻り、規約の遵守率も改善しました。永続コンテキストは「多く書く」より「構造化して絞る」が正解です。
② 作業記憶：セッションの記憶をファイルに逃がす
LLMは会話が途切れると文脈を失います。私も以前は再開のたびに「前回どこまでやったっけ？」を説明し直していました。
そこでCLAUDE.mdに「セッション終了時、進行中タスク・保留事項・次のアクション・決定事項をhandoff.mdに書き出す」という指示を常設し、AIエージェント自身にセッション末で更新させる運用にしました（cronやフックによる自動生成ではなく、指示ベースでAIに生成させる運用です）。次回はこれを読むだけで、文脈の復元が約5秒で完了します。「記憶」はモデルの中に留めようとせず、ファイルシステムに外部化するのが現実解でした。
# handoff.md（作業記憶のテンプレ）
## 進行中
- [ ] 〇〇の実装（残: バリデーション）
## 保留・判断待ち
- △△の仕様、要確認
## 次のアクション
1. …
## 直近の決定事項
- □□方式を採用（理由: …）
構造を固定しておくと、復元の精度が安定します。フォーマットが毎回バラつくと、AIの読み取りもブレます。
③ 参照知識：必要な時だけ引く（全部渡さない）
コンテキストは「多いほど良い」ではありません。むしろ不要な情報はノイズであり、コストでもあるというのが実運用の学びです。
400ページ超のナレッジが社内Wikiに散在していた案件では、必要な情報を探すのに毎回15分以上かかっていました。これを全ページMarkdown化してベクトルDBに格納し、質問時に関連チャンクだけを検索して渡すRAG構成に変えたところ、検索が15分→約10秒になりました。チャンクサイズは、この案件で扱った文書の構造・検索方式では500〜1000トークン程度が体感的にちょうどよく感じました（複数サイズを厳密に比較したベンチマークではなく、あくまで一案件の経験値です。埋め込みモデルや文書の粒度が変われば最適値も変わるはずなので、実務では自分のデータ・評価用の質問セットで比較検証することをおすすめします）。
ポイントは「全知識を毎回コンテキストに載せる」のではなく、その問いに関係する断片だけを動的に引くこと。コンテキストウィンドウは有限で、詰め込みすぎるとモデルによっては関連情報を見つける精度が下がることがあります。また、トークン従量課金のAPIを使う場合は、キャッシュ等を考慮しなければ入力トークンが増えるほど料金も増えます（定額プランやプロンプトキャッシュ、ローカルモデルでは必ずしも当てはまりません）。「何を渡すか」の設計が9割、というのは体感どおりでした。
④ 動的コンテキスト：出力の「型」を先に見せる
最後は、タスクごとに確定させるコンテキストです。ここでプロンプトエンジニアリングの技法（Few-shot）が効いてきます。
AIにコードレビューを頼んでいたとき、些細なスタイル指摘と重大なバグ指摘が同じ粒度で混ざり、Criticalを見落としそうになっていました。そこで依頼文に、重要度（Critical / Warning / Info）の分類基準をFew-shotの例として3パターン添付しました。すると出力が重要度順に整理され、確認時間が半分になりました。
# 出力例（この型で返して）
[Critical] SQLインジェクションの可能性: user入力を直接クエリに連結
[Warning] N+1クエリ: ループ内でのfindByIdを見直し
[Info] 命名: getData → fetchUserOrders の方が意図が明確
この案件では、ルールを長文で説明するより期待する出力を3つ見せる方が確認時間の短縮につながりました（比較したのはこの1ケースの前後だけで、厳密な比較実験ではありません。タスクやモデルによってはルールを明示したほうが効くこともあると思います）。「型を先に見せる」——これも立派なコンテキスト設計の一つです。
もう一つの効用：一人でも「壁打ち相手」が持てる
コンテキストを整えると、レビュアー不在の環境でもAIをシニア役として使えます。設計書をAIに読ませ、「経験20年のアーキテクトとして問題点を指摘して」と非機能要件の観点まで指定して依頼したところ、5つの改善提案のうち2つは本番運用で実際に問題になりうる重大な設計漏れでした。役割（誰として）と参照（何を見て）というコンテキストを揃えると、壁打ちの質が一段上がります。
まとめ：プロンプトを磨く前に、環境を設計する
コンテキストエンジニアリングを一言でいえば、**「AIに何を見せるかを設計する技術」**です。今日から始められる順に整理します。
-
①永続化 — 毎回説明している前提を
CLAUDE.mdに逃がす（ただし肥大化させず、構造化して絞る） -
②外部化 — セッションの記憶を
handoff.mdに書き出す - ③検索化 — 知識は全部渡さず、必要な断片だけ引く
- ④型提示 — 出力の期待形をFew-shotで先に見せる
プロンプトの言い回しに悩む前に、まずモデルが置かれている「情報環境」を疑ってみてください。多くの場合、伸びしろは指示の外側にあります。
ここまで読んでいただきありがとうございました。参考になったら いいね・ストック していただけると励みになります。
Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。フォロー で新着が届きます。
みなさんは、AIに渡す「コンテキスト」でいちばん効いた工夫は何でしたか？ ぜひコメントで教えてください。