「コンテキストエンジニアリング」（公式の記事では context engineering）は、何を毎回読ませないかを決める仕事でした
AI エージェントの話で「コンテキストエンジニアリング」という言葉をよく見かけます。公式の記事でも context engineering と書かれていて、ここは呼び名と公式の語がそのまま対応しています。
私は一人会社を Claude で運用しています。何を毎回読ませて、何をファイルに逃がすか。ここで何度も失敗してきたので、公式の資料ではどう書かれているかを確かめました。2026年10月12日に、Anthropic の記事1本と Claude Code の公式ドキュメント3ページを開いて読んでいます。
結論は3つです。
context engineering は、プロンプトの書き方より広く、毎回の推論で何を文脈に入れるかを選び続けることだと書かれています
文脈は多いほど良いわけではなく、増えるほど思い出す力が落ちると説明されています
長い仕事への手として、圧縮・メモの書き出し・サブエージェントの3つが挙がっています
公式の定義
いちばんまとまっているのは「Effective context engineering for AI agents」（2025年9月29日）です。
prompt engineering は、指示文をどう書いて並べるかの方法。context engineering は、推論のたびに文脈に入る情報全体を選んで保つための方法。そう区別されています。指示文だけでなく、ツール、外部のデータ、会話の履歴まで含めて考える、という書き方です。
理由として挙がっているのが、日本語の記事で「コンテキストロット」と書かれている現象（公式の記事では context rot）です。文脈のトークンが増えるほど、そこから正確に思い出す力が下がる、という説明でした。
人の作業記憶に限りがあるように、モデルにも注意の予算（attention budget）がある、とも書かれています。新しいトークンが入るたびに、その予算が少しずつ減っていく。
なので目指すのは "the smallest set of high-signal tokens"、つまり効く情報だけの最小の組だ、というのが記事の中心です。
長い仕事への3つの手
同じ記事は、文脈の上限を超える長い仕事に3つの手を挙げています。
圧縮。日本語の記事では「コンテキスト圧縮」と書かれることもあるもの（公式の記事では compaction）。上限に近づいた会話を要約して、新しい文脈に要約を入れて続けます
メモの書き出し（公式の記事では structured note-taking、または agentic memory）。メモを文脈の外に書き、あとで読み戻します
サブエージェント（公式の記事では sub-agent architectures）。細かい探索は別の文脈でやらせて、要約だけを受け取ります
もう1つ大事だと思ったのが「必要になったときに読む」（公式の記事では just in time）という考え方です。データを先に全部読ませるのではなく、ファイルのパスのような軽い目印だけを持たせて、要るときに道具で読ませます。
記事には、先に読ませる分と要るときに読む分を組み合わせるやり方（公式の記事では hybrid strategy）も出てきます。Claude Code はその例として挙がっていました。CLAUDE.md は最初から文脈に入れ、ほかのファイルは検索して必要なときに読む、という分け方です。
Claude Code のドキュメントでは
Claude Code のドキュメント（2026年10月12日に確かめた範囲）では、もう少し具体的に書かれています。
CLAUDE.md と自動の記憶（auto memory）は、毎回の会話の始めに読み込まれる
CLAUDE.md は1ファイル200行未満を目安に。長いほど文脈を食い、守られにくくなる
圧縮のあと、プロジェクト直下の CLAUDE.md はディスクから読み直して入れ直される
会話の中だけで伝えた指示は、圧縮で消えることがある。残したいなら CLAUDE.md に書く
最後の点は大事だと思います。会話で言っただけのことは、CLAUDE.md に書いておかないと、圧縮で消えることがあります。
メリット
モデルを替えずに、手元の資料の置き方だけで結果を変えられることです。
毎回読ませる文書を短くすれば、そのぶん注意の予算が今の仕事に回る、というのが記事の考え方からの私の読みです。資料の置き方なら今日から直せます。
デメリット
圧縮は、何を残すかの選び方がすべてです。公式の記事にも、削りすぎると、あとで大事だと分かる細部を失うことがある、と書かれています。
必要なときに読む方式は、先に読ませておくより遅くなります。道具の使い方を誤ると、探し回るだけで文脈を使ってしまうことも書かれていました。
合う使い方
私の読みでは、こう分けるのが良さそうです。
全員がいつも守ること：毎回読む1枚に置く
一部の仕事でしか要らないこと：ファイルに置いて、場所だけ書く
正確さが要る文字列や長い資料：ファイルに書いて、パスを渡す
BEBSITE の実例
うちでは、全セッションが毎ターン読む1枚の指示書に「全員に効くものしか置かない」と書いています。もう1つの決まりが、1行足すときは、置き換えられる古い記述を1つ消すこと。役ごと・仕事ごとの細かい決まりは別の資料に出して、1枚の冒頭には「要るときはこれを開く」という表を置きました。この1枚は、一度大きく削ったこともあります。
長い会話は、圧縮を待たずに交代させています。文脈の使用量が70%を超えたら、新しい会話に交代して、引き継ぎ資料を読ませる決まりです。
ただ、決まりを作っても測り忘れは起きました。統括役が87%、相談役が97%まで超えてから気づいたことがあります。なので70%を超えたら警告を差し込む仕掛けを足しました。交代の決まりの話は別に書いています。
https://note.com/bebsite/n/n9dcf91d1b8e6
AI 同士の連絡にも同じ考え方を使っています。会話のメッセージで送った半角の @ が、受け手には全角の ＠ で届いたことがありました。同じ文字列をファイルに書いたほうは半角のままでした。
それ以来、URL やコマンドのように1文字違うと壊れるものは、ファイルに書いてパスだけを渡しています。共有はファイルに置いて、連絡は依頼のときだけ。結果として、公式の記事の just in time に近い形になっていました。
効果はまだ数字では言えません。比べられる形で測っていないからです。
確かめた日付
この記事に書いた公式の説明は、2026年10月12日に本文を読んで確かめた範囲のものです。Claude Code の圧縮の動きは版で変わるので、日付を入れています。
毎回読ませるものを足すのは簡単で、減らすほうがずっと難しい。それが、調べてみていちばん腑に落ちたところでした。
この記事の仕組みを、業務に合わせて組むところまでをココナラで引き受けています。
