$ man context-wiki/context-engineering

Andrej Karpathy はこれを「次のステップに必要な情報だけをコンテキストウィンドウに詰め込む技術」と呼んだ。私が見つけた中で最も的確な一文の定義だ。コンテキストエンジニアリングは、より良いプロンプトを書くことではない。AI がプロンプトを目にする前に、AI がアクセスできる情報を設計することだ。同じ AI モデルでも、貧弱なコンテキストを与えれば汎用的なゴミが出てくる。同じ AI モデルに、豊かで構造化されたコンテキストを与えれば、あなたのように話し、あなたのビジネスを理解し、手取り足取りの指示なしにワークフローを実行するアウトプットが得られる。ほとんどの人はこのステップを完全にスキップしている。Claude を開いて、ビジネスの説明をゼロからやり直し、なぜアウトプットが浅いのかと首をかしげる。それは AI の問題ではない。コンテキストの問題だ。

パターン

プロンプトエンジニアリングは質問を磨くこと。コンテキストエンジニアリングは、質問する前に AI が知っていることを設計すること。こう考えてほしい。プロンプトエンジニアリング：「SaaS 企業の営業担当 VP 向けのコールドメールを書いて」。コンテキストエンジニアリング：ICP 定義、ペルソナ階層、ボイスガイド、メッセージングフレームワーク、返信が来た 3 通のメール例を読み込む。そして「コールドメールを書いて」と頼む。プロンプトは一文。コンテキストはそれ以外のすべて。ほとんどの人はプロンプトに集中してコンテキストを無視している。これは新入社員に完璧な指示を出しながら、オンボーディングをゼロにするようなものだ。ビジネスを理解していなければ、どんな指示も役に立たない。

プロのコツ

私の GTM OS リポジトリ全体がコンテキストエンジニアリングシステムだ。CLAUDE.md が環境のデフォルトを読み込む。Skills がワークフローの指示を読み込む。Rules がファイル固有のパターンを読み込む。パートナーフォルダがクライアントごとの ICP、ペルソナ、メッセージングを読み込む。/deploy と入力すると、Claude は Git ワークフロー、Vercel の設定、3 つのドメイン、ビルド検証手順をすでに把握している。プロンプトでは何も説明していない。すべてコンテキストウィンドウに入っていたからだ。これが AI を使うことと AI をエンジニアリングすることの違いだ。毎回のセッションで Claude に同じことを説明しているなら、それはコンテキストエンジニアリングの正反対をやっている。

パターン

コンテキストエンジニアリングは複利で効いてくる。ボイスファイルを一つ書くたびに、将来のコンテンツの質が上がる。スキルを一つ構築するたびに、将来のワークフローが速くなる。パートナーフォルダを一つ整備するたびに、将来のオンボーディングがきれいになる。今日のセッションのためだけに作っているのではない。使うたびに賢くなるシステムを作っている。私のリポジトリは CLAUDE.md と 3 つのスキルから始まった。今では 40 以上のスキル、完全なボイスシステム、パートナーワークフロー、RPG プログレッション、自動化ダッシュボードがある。それぞれのパーツが他のすべてのパーツの効果を高めている。これがコンテキストエンジニアリングの複利効果だ。最初の 1 か月はゆっくり。6 か月目には信じられないほどになる。