Context Engineering を AI に使用する方法 コーディング ワークフロー: 一連の実行可能実装パス

コンセプトは理解しているのに、コンテキストを書くことができないのはなぜですか?

AI コーディング アシスタントでは、Context Engineering (コンテキスト エンジニアリング) が「モデルに最も関連性の高い情報を提供する方法」として説明されることがよくあります。しかし、エディターを開くと、すぐに疑問が生じます。どのファイルを含めるべきか?トークンの履歴をどの程度含める必要がありますか?エラー ログを一緒にフィードしますか?

最初の最も一般的な問題点は、Context Engineering をモデルの微調整として扱うことです。実際、これはトレーニングとは何の関係もなく、現在のダイアログまたはエージェント ループ内の既存の情報をどのように整理するかだけです。これは、GPU も再トレーニングも必要なく、構造化された選択、挿入、更新ルールのセットだけを必要とすることを意味します。

2 つ目の問題点は、コードベース全体を一度に詰め込もうとすることです。初心者の多くは、プロジェクト内のすべてのディレクトリ構造、README、および数十のファイルをつなぎ合わせます。その結果、トークン ウィンドウを超過するか、モデルがキー ポイントをまったく把握できなくなります。

最初のステップ: まずコンテンツ挿入レイヤーを構築します

有効な Context Engineering には、取得レイヤー、フィルタリング レイヤー、注入レイヤーの 3 つのレイヤーが必要です。最初の層はその後の品質を直接決定しますが、ほとんどの人は最後の層により多くの注意を払います。

取得層の核心は、「パッシブ スプライシングではなくアクティブ取得」です。コーディング シナリオでは、どのデータが必要かを明確に定義する必要があります。

• 現在開いているファイルとその最後の 20 ～ 50 行の変更 (ファイル履歴全体ではなく)
• 現在のコンパイル エラーまたはリンター警告のライブ出力 (存在しない場合はスキップ)
• 最新の git diff の簡単な説明 (コンテキストの変更を理解するために必要な場合)
• ユーザーの最後の自然言語コマンドにおける主要な名詞とアクション

より具体的なアプローチは、キーボード ストロークごとに更新するのではなく、ファイルの保存時にコンテキスト スナップショットをトリガーするようにファイル変更リスナー (chokidar など) を設定することです。これにより、API の消費が削減されるだけでなく、回答の途中でコンテキストが変化することによるモデルの「記憶喪失」も防止されます。

ステップ 2: コンテキストの有効期間と削除メカニズムを定義する

これは最も失敗しやすい部分です。多くの人は完璧なコンテキスト構造を設計しますが、「古いコンテキスト」のクリーンアップを考慮することを忘れます。結果として得られたモデルのすべての回答は、削除された関数または古い注釈を参照していました。

失敗シナリオ 1: エラー メッセージのコンテキストを保存しました。その後、ユーザーがコードを変更して再コンパイルしましたが、以前のエラー コンテキストがまだトークンの位置を占めていたため、新しいモデルの応答はエラーがまだ存在していると誤って信じてしまいました。

回避策: 各コンテキストに「有効期限」タグを追加します。たとえば、コンパイル エラー コンテキストは、次にコンパイル操作が成功した後でのみ自動的に削除されます。現在のブランチが切り替えられるかコミットされると、git diff コンテキストはクリアされます。これは単純な優先度キューを使用して維持できます。高い優先度 (ユーザーの現在のコマンドなど) は常に保持され、低い優先度は時間またはイベントによって期限切れになります。

もう 1 つの一般的な問題は、コンテキストが多すぎることです。それぞれが非常に正確であっても、10 個以上を一度に注入すると、モデルは注意力の低下に悩まされ始めます。一般に、3 ～ 5 個のバックボーン コンテキストを保持し、残りをユーザーのアクティブなクエリを通じてロードすることをお勧めします。

ステップ 3: 実装可能な最小限の実装パス

以下は、特別なフレームワークを必要とせず、Node.js または Python のみに基づいた古典的なデザインです。

1. ContextStore クラスを含む contextEngine.js を作成し、内部で Map を使用して各コンテキストを保存します。キーは自動生成された ID です。
2. 3 つのメソッドを実装します: addContext({ id, content, priority, expireOnEvent })、removeContext(id)、getActiveContexts()。
3. AI コーディング アシスタント (Continue、Aider、Cursor Agent など) の「ツール呼び出し」または「フック」を呼び出します。ファイルが保存されたら、addContext を呼び出して差分を記録します。コンパイルの実行が終了したら、エラーをチェックし、対応するコンテキストを更新します。
4. モデルに送信されるプロンプトアセンブリ関数で、getActiveContexts() を呼び出して、優先順位の降順でスプライスします。

ここには実際のトレードオフがあります。「できるだけ多くのコンテキスト」を望むか、それとも「モデルに最も必要なものだけを与える」か?前者はモデルを混乱させやすいのに対し、後者は一連のルールを自分で定義する必要があります。私たちの実践に基づいて、私たちは後者を推奨しており、ルールは多いものではなく少ないものであるべきです。単純な「最近変更されたファイル + 最新のエラー」から始めて、徐々に増やしてください。

ステップ 4: 失敗した場合の診断とロールバック

模範解答の品質が低下した場合は、まずコンテキスト キューが過負荷になっているか、古くなっていないかを確認します。確認を容易にするために、ターミナルにコンテキスト ステータス ログを出力することをお勧めします (短い JSON 行を使用)。もう 1 つのチェックポイント: モデルが以前に解決した問題を繰り返すかどうかを確認します。これは通常、コンテキストが適時にクリアされなかったことを示しています。

上記の問題が頻繁に発生する場合は、より狭いコンテキスト戦略にフォールバックできます。つまり、現在のファイルとユーザー コマンドのみを含め、増分蓄積を完全に放棄します。このモデルにはグローバルなビジョンが欠けていますが、少なくとも解答の安定性は高くなります。これは、特に高可用性が必要な場合には、許容できるエンジニアリング上のトレードオフです。

実践からシステム改善まで

上記の最小限のパスを実行すると、セッション間でコンテキスト テンプレートを保存する方法や、さまざまなタスク (リファクタリング、デバッグ、コード レビュー) でさまざまなコンテキスト戦略を切り替える方法など、多くの最適化ポイントがあることがわかります。これらはすでに高度なトピックであり、1 つの記事で説明するのは困難です。

「API 調整」スタイルから脱却し、エージェント レベルのコンテキスト クローズド ループの設計方法を真にマスターすることが目標の場合は、環境の構築から始まり、コンテキスト インジェクション戦略の微調整、そしてマルチ エージェント コラボレーションでのコンテキスト共有メカニズムに至る、より体系的な学習パスに入ることが推奨されます。