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