コンテキストエンジニアリングとは？プロンプトの次に学ぶべき「前提知識の渡し方」12の原則

コンテキストエンジニアリングとは — 「質問の仕方」から「前提知識の渡し方」へ

プロンプトエンジニアリングが「質問の仕方」の技術だとすると、コンテキストエンジニアリングは「前提知識の渡し方」の技術です。どの情報を、どのタイミングで、どのような構造でAIに渡すかを制御できるようになると、Claude CodeのようなAIエージェントが格段にタスクを遂行しやすくなります。

なぜ良いプロンプトだけではダメなのか

• その場の指示だけでは、毎回出力がブレる
• 実務の複雑なタスクほど、指示文に書き切れない背景知識が必要になる
• だから「質問文」ではなく「文脈全体」を設計する必要がある

Claude Codeでは、CLAUDE.mdやSkills、参照ドキュメントを通じて「会話の外側」からコンテキストを供給できます。ただしAIが一度に処理できる情報量（コンテキストウィンドウ）には上限があるため、限られた枠に何をどう詰め込むかの設計が必要になります。これがコンテキストエンジニアリングです。

最も多い失敗は「情報不足」ではなく「情報過多」

「AIが思うように動かないのは、情報が足りないからだ」と考えて資料をどんどん読み込ませる——これが最も典型的な失敗パターンです。実際には逆で、情報過多こそがAIの精度を下げます。関係の薄い情報がコンテキストを圧迫すると、AIは重要な情報を見失い、出力が不安定になります。

正解は、情報を増やすことではなく、そのタスクで正しく判断するために必要な文脈だけを、正しい順序と形で渡すこと。すべてはコンテキストウィンドウが有限であることに起因します。

実践のための12の原則

当社が法人研修で教えている、ナレッジ整備の12原則です。代表の宮地が自社の経営・業務でClaude Codeを運用する中で体系化したものです。

1. 1ナレッジの目的を明示する — 何のためのファイルかを冒頭に書く。AIは目的がわかると参照精度が上がる
2. 2判断軸を先に固定する — 「迷ったらこう判断する」という基準を先に与える
3. 31ファイル1テーマを厳守する — 複数テーマの混在は、検索性と参照精度を下げる
4. 4毎回読むべき情報と必要時だけ読む情報を分ける — CLAUDE.mdとSkills/参照ファイルの分担そのもの
5. 5ノウハウと事例を分ける — 「どうやるか」と「過去にどうだったか」は別ファイルにする
6. 6静的コンテキストと動的コンテキストを分ける — 変わらない情報と頻繁に更新される情報を混ぜない
7. 7ナレッジの鮮度を管理する — 更新日を記録し、古い情報を放置しない
8. 8成功事例を資産化する — うまくいった出力・手順をファイルとして残す
9. 9失敗事例を資産化する — 失敗パターンとその回避策も同様に残す
10. 10良いナレッジになっているかレビューさせる — AI自身に「このナレッジのわかりにくい点は？」と点検させる
11. 11権限とナレッジの階層構造を合わせる — 誰がどの情報にアクセスできるかをフォルダ構造に反映する
12. 12共有範囲を設計する — 個人用・チーム用・全社用を最初から分けて設計する

特に重要な原則 — Single Source of Truth（SSOT）

12原則の土台にあるのが、SSOT（単一の信頼できる情報源）の考え方です。同じ情報が複数のファイルに分散していると、更新漏れで内容が食い違い、AIが競合する文脈を参照して出力が不安定になります。

• 原本は1つ — 同じ情報を複数ファイルに書かず、原本から参照させる
• 目次を活用する — 「どの情報はどこにあるか」の索引を用意し、AIにも人にも探しやすくする

たとえば料金情報を10個のファイルに書いてしまうと、価格改定のたびに10ファイルの更新が必要になり、いつか必ず食い違いが生まれます。原本を1つにし、他からは「料金は pricing.md を参照」と書く——地味ですが、AI運用の安定性を最も左右する原則です。

コンテキストエンジニアリングとハーネスの関係

コンテキストエンジニアリングが「何をどう渡すかの設計」だとすると、ハーネスは「その設計を壊さずに毎回安定して実行させるための実行基盤」です。どれだけ美しくナレッジを整備しても、それを確実に読み込ませ、決めた手順で使わせる仕組みがなければ、実務では機能しません。両者はセットで理解する必要があります。

設計＝コンテキストエンジニアリング（本記事）、実行基盤＝CLAUDE.md・Skills・サブエージェント・hooks、という対応で学んでいくのが最短ルートです。