X(Twitter) Zenn GitHub RSS 共有

Context Engineering

作成日時：2025-07-19
更新日時：2025-07-22

如何にAIに対して適切なコンテキストを渡し、精度の高い回答や成果物を得ることができるか。

Most of the time when an agent is not performing reliably the underlying cause is that the appropriate context, instructions and tools have not been communicated to the model.

エージェントが確実に動作しない場合の根本的な原因は、ほとんどの場合、適切なコンテキスト、指示、ツールがモデルに伝達されていないことです。
The rise of “context engineering”

参考資料

1. コンテキスト

文脈、状況、背景のこと。

2. コンテキストウィンドウ

コンテキストウィンドウとは、LLMが一度に処理し、対話の文脈を記憶できる情報の量、いわば短期記憶（ワーキングメモリ）。覚えていられる量。

認知負荷の高い、つまり冗長な情報を含むプロンプトはワーキングメモリを過剰に消費する。
コンテキストウィンドウのサイズを超過した場合、LLMは古い情報から忘れていく。
これは人間が一度に多くの情報を処理しようとすると、古い記憶が曖昧になる現象と似ている。
回答も遅くなる。

3. コンテキストウィンドウサイズ

技術の進歩によりLLMのコンテキストウィンドウサイズは増大している。
しかし、だからと言ってコンテキストウィンドウサイズを無視して良いわけではない。

長時間の対話や、Agentic Codingのように大量の情報を扱うタスクでは、コンテキストは積み重なり、いずれ上限を超過する。
その結果、AIが必要な情報を忘却し、成果物の品質や精度が低下する要因となる。
APIコストも増加する。

4. コンテキストウィンドウの消費を抑える

コンテキストウィンドウの消費を効率的に管理するには、下記の手法が有効である。

4.1. プロンプトの最適化

不要な情報を省き、必要な情報だけを厳選してプロンプトに含める。

4.2. 情報の要約(圧縮)

重要なポイントを要約して提供する。
RAG (Retrieval-Augmented Generation) を活用し、関連性の高い情報のみを外部ソースから取得して渡す。

4.3. タスクを小さく分割する

一度に扱う情報量を減らし、タスク完了ごとにチャットセッションをリセットする。
適度にメモリーをリフレッシュして、再度ルールを読み込ませる。

4.4. 動的なコンテキスト管理

Agentic Codingにおけるコンテキストファイル（例: CLAUDE.md）のように、タスクに応じて関連性の高い情報のみを動的に提供する仕組みを構築する。

4.5. 英語でプロンプトやコンテキストを書く

トークン使用量は日本語に比べて少なくなる傾向がある。

だが、チーム全員が英語に堪能なわけではない。
これ起因で生産性が下がる可能性がある。

対策として、コンテキストファイル(※1)のみ英語で書く。
コンテキストファイルは一度書いてしまえば、修正の頻度は高くない。
何度も読み込まれるコンテキストファイルのトークンを減らすことは、全体のトークン使用量を抑制する効果がある。

プロンプトは個人の英語のスキルに応じて、日本語/英語を好きに切り替えればいい。
ルールに「回答は日本語で」とでも書いておけば、プロンプトは英語でも回答は日本語にできそう。

※1
Agentic Coding系において、AIに読み込ませる守るべきルールやペルソナ等を記載したファイル。
GeminiならGEMINI.md、Claud DesktopならCLAUD.mdなど。

4.6. それでもトークンの消費を抑えられない場合

重要な情報を忘れられたのなら、再度提供することで回答の精度を維持できる。
チャットの都度、明示的にコンテキストファイルを読み込ませるなど。

5. コンテキストエンジニアリング

AIに適切な情報を戦略的に選択、整理、管理すること。
ゴミのようなプロンプトやコンテキストをAIに渡せば、生成される回答や成果物もまたゴミである。

LLMをCPUに、コンテキストウィンドウをRAMに例えています。
コンテキストエンジニアリングは、そのRAMに何が入るかをキュレーションし、エージェントが各ステップで必要なものを持っていることを保証します。
ーコンテキストエンジニアリングとは？わかりやすく解説

下記の戦略がある。

5.1. 記述

コンテキストをコンテキストウィンドウ外に保持・永続化する。
長期記憶の生成。
コンテキストファイルがこれにあたるか。
主に下記を記載する。

これらのデータを読み込ませれば、回答や操作の精度は上がる。
ベクターデータもここに含まれる。

5.2. 選択

適切なコンテキストを渡す。
ディレクトリやプロジェクトごとにコンテキストファイルを作成、それを適宜読ませる感じ。
RAGたMCPを使用して、関連のあるコンテキストをAIに渡す。
ハルシネーションの抑制。

5.3. 圧縮

コンテキストウィンドウを圧迫しないために、コンテキストは圧縮する。
zip的な圧縮ではなく、情報の圧縮。
「4. コンテキストウィンドウの消費を抑える」がこれに関連する。

5.4. 分離

コンテキストを分離し、関係のない情報は読み込ませない。
これも「5.2. 選択」と同様、ディレクトリやプロジェクトごとにコンテキストファイルを作成、それを適宜読ませる感じか。

6. アナロジー思考

別領域の原則を適用可能と思われる。

6.1. コーディング原則

コーディング原則に則り、プロンプトやコンテキストを書く。

6.2. ドキュメントライティング

コンテキストファイルの記述はそのままドキュメントライティングの概念が利用可能。
参照: ドキュメントライティング

7. リファクタリングとレビュー

5における戦略が実践できているかをAIに確認してもらう。
コンテキストファイルの添削や圧縮なども。

8. テスト/評価

何か行動をしたならば、テストと評価をしなければならない。
A/Bテストとかも。

9. コンテキストの作り方

9.1. 自分で書く

  1. 人間がコンテキストを書く
  2. AIがレビューする
  3. 人間がレビュー結果を反映する
  4. AIが情報を圧縮する
  5. 人間が確認する

9.2. AIに既存資料からコンテキストファイルを作成してもらう

フォルダーやファイルを指定して、それをもとにAIにコンテキストファイルを作成してもらう。
以降のやり取りではそれを読み込ませる。

9.3. AIにやりとりからコンテキストファイルを作成してもらう

Agent CodingでAIとやり取りしている過程で、
発生したコンテキストをMarkdownでAIに書き出してもらう。
それを特定のフォルダーに格納する。

以降、AIにそのフォルダーを参照してもらい、
関係ありそうなの(ファイルはこちらが明示する)があったら読み込んでもらう。
RAG劣化版みたいな感じ。

10. 簡易ルール

長々と書いたが下記のルールを守ればいい。

11. 認知心理学を学べ

認知心理学 (New Liberal Arts Selection)

12. AIに関して思うこと

AIが人間に近づくにつれ、AIを使用した開発の手法は、これまで人間がやってきたものと同様なものに近づいてきていると感じる。

コンテキストエンジニアリングは、AIを使用しない普段の仕事と何が違うのか。
相手が人間だったものがAIになっただけと思う。

コンテキストファイルを書くことは、Wikiにプロジェクトのルールを書いて、メンバーに周知することと何が違うのか。
作業指示を書くことは、BOSCAR/INVEST/SMARTに則ってバックログを書いて、メンバーに指示を出すことと何が違うのか。
Kiroにおける仕様駆動開発は、詳細設計を書いてPGに渡して実装してもらうことと何が違うのか。

今までとあまり変わらない。
変わったとすれば成果物ができる速度と、下記の能力がさらに求められるようになったことか。

13. おわりに

相手がAIでも、人間でも、とにかく意図を明確に伝達することが重要。
曖昧性の排除こそがシステム開発を円滑に進める。