1 
2AI エージェントの狭い世界における今の言葉は、コンテキスト エンジニアリングです。
3 
4私たちがすでに作ったものを売るために、また別のレーベルが発明されたようです。部分的にはそうです。しかし、よくあることですが、このレッテルが広まるのは、実際の痛みに名前を付けるためです。
5 
6問題は、モデルが「考えない」という理由だけで失敗するわけではないということです。間違った部屋で作業するように彼らを送り込むため、彼らは失敗することがよくあります。
7 
8私たちは彼らに古い指示を与えます。私たちは重要なファイルを彼から隠します。私たちは長すぎる文書を彼らに渡しますが、重要なことは何も述べていません。優先順位を付けずにログを表示します。私たちは彼らに、いつ使用するかを説明せずに 10 個のツールを与えます。そのとき、エージェントが見知らぬアパートで目覚めた人のように動いたら、私たちは驚きます。
9 
10プロンプトは、それに対して言うフレーズです。コンテキストとは、その周囲に用意した世界のことです。
11 
12## プロンプトエンジニアリングからコンテキストエンジニアリングへ
13 
14プロンプトエンジニアリングとは、文章を書くことだと考えられることがよくありました。適切な言葉を選択し、適切な方法で質問し、例を追加し、形式を指定します。
15 
16コンテキスト エンジニアリングは建築に近いものです。
17 
18「リクエストをどのように作成すればよいですか?」と尋ねるだけではありません。それは次のように尋ねます。
19 
20- 本当に必要な情報は何ですか?
21- ノイズとは何ですか?
22- その場で何を回復する必要があるか? -何を覚えるべきですか？
23- どのツールを公開する必要がありますか?
24- どの命令が安定していて、どの命令がタスクに依存しているか?
25- エージェントに何が権限があるのか​​理解させるにはどうすればよいですか?
26 
27微妙ですが大きな変化です。エージェントを使用する場合、コンテキストは静的なブロックではないためです。段階ごとに変化していきます。
28 
29エージェントはファイルを開き、何かを学習し、テストを実行し、エラーを受け取り、計画を更新し、ツールを呼び出し、依存関係を検出します。周回ごとに、彼は何を持って行き、何を省略するかを決定しなければなりません。
30 
31これがエンジニアリングです。
32 
33## コンテキストは埋め立て地ではありません
34 
35大きなコンテキスト ウィンドウを持つテンプレートは、すべてを放り込んでしまおうという誘惑を私たちに与えました。
36 
37それは理解できます。 100 万トークンを持っている場合、なぜ選択する必要があるのでしょうか?
38 
39すべてを投入できたとしても、すべてが役立つわけではないからです。確かに、ノイズにはコストがかかります。トークン、注目、待ち時間、品質がかかります。私たちが 20 個のタブを開いて理由を思い出せなくなったときと同じように、モデルも無関係な詳細に夢中になってしまうことがあります。
40 
41適切なコンテキストには階層があります。
42 
431. システムの指示とポリシー。
442. 具体的な目的。
453. 現在の状況。
464. 関連データ。
475. 制約。
486. 利用可能なツール。
497. すでに行われた決定を追跡します。
50 
51すべてを同じレベルで扱う必要はありません。ユーザーコマンドは古いメモよりも価値があります。不合格だったテストは、今では 3 か月前の美的好みよりも価値があります。セキュリティ ポリシーは、本番環境のショートカットよりも価値があります。
52 
53コンテキスト エンジニアリングでは、データだけでなく重みを与えることも意味します。
54 
55## 記憶力: 覚える量は少なくなり、よりよく覚えられるようになります
56 
57エージェントの記憶は、最も滑りやすいトピックの 1 つです。
58 
59ユーザーとしては、エージェントに自分のことを知ってもらいたいと考えます。あなたは彼に、その口調、計画、慣習、すでに決められたことなどを覚えていてほしいのです。エンジニアであれば、あらゆる永続的な記憶にはリスクがあることをご存知でしょう。それは間違っている可能性があり、古い可能性があり、個人的すぎる可能性があり、一般的すぎる可能性があり、検証不可能である可能性があります。
60 
61有用な記憶には少なくとも 3 つの性質が必要です。
62 
63- 来歴: この情報はどこから来たのですか?
64- 日付: それはいつ本当ですか?
65- 目的: どのような種類のタスクに使用する必要がありますか?
66 
67これら 3 つがなければ、記憶は迷信になってしまいます。
68 
69私はエージェント記憶を魔法の心としてではなく、ワークブックとして考えるのが好きです。一時的なメモ、確認された決定、スタイルの設定、技術的な制約、ソースへのリンクがあります。有効期限が切れるものもあります。一部は書き直す必要があります。エージェントが誤って推測したため、削除する必要があるものもあります。
70 
71優れたシステムでは、このメンテナンスが正常に行われる必要があります。英雄的ではありません。
72 
73## 検索とツールは同じものではありません
74 
75コンテキストについて話すとき、多くの場合、すぐに RAG に行き着きます。埋め込み、ベクトル データベース、チャンキング、再ランキング。
76 
77どれも役に立つ。ただし、検索は情報をモデルに取り込むための 1 つの方法にすぎません。彼だけではありません。
78 
79エージェントは、ファイルの読み取り、API のクエリ、MCP サーバーの呼び出し、ブラウザの起動、テストの実行、Slack の検索、ダッシュボードの確認、人間への質問によってコンテキストを取得できます。
80 
81興味深いのは、どのルートをいつ使用するかを決定することです。
82 
83エージェントが歴史的な質問に答える必要がある場合は、おそらく検索するだけで十分です。バグを修正する必要がある場合は、実際のコードを読まなければなりません。デプロイメントが失敗する理由を理解する必要がある場合は、新しいログを調べる必要があります。顧客に手紙を書く必要がある場合は、チケットのトーン、履歴、ステータスを取得する必要があります。生産上で行動しなければならない場合は、許可を求めなければなりません。
84 
85コンテキストはデータベースではありません。それはワークフローです。
86 
87## 優秀なエージェントは無視する方法も知っています
88 
89エージェントの成熟の兆候は、「この情報は必要ありません」と言える能力です。
90 
91当たり前のことのようですが、とても難しいことです。多くのエージェント システムが蓄積されます。ツール呼び出しごとにテキストが追加されます。すべてのエラーはバッファーに残ります。読み取られた各ファイルはスタックに追加されます。結局のところ、このモデルには非常に長い歴史があり、地図はありません。
92 
93圧縮が必要です。中間合成が必要です。構造化する必要があります。
94 
95「起こったのはそれだけ」ではなく、次のとおりです。
96 
97- 目標はまだ有効です。
98- 現在の仮説。
99- ファイルはすでにチェックされています。
100- 決定が下されました。
101- 未解決のリスク。
102- 次のアクション。
103 
104これにより、エージェントは芝居がからず、より役立つものになります。彼が賢そうに見えるからではなく、整頓された机で仕事をしているからです。
105 
106## プロンプトアーティストではなく、チームのためのコンテキストエンジニアリング
107 
108私がこのトピックに興味を持った理由は、責任が個人からシステムに移されるからです。
109 
110プロンプト エンジニアリングでは、多くの場合、モデルに最もよく話しかけることができる人が勝ちます。コンテキスト エンジニアリングでは、ドキュメント、規約、問題、ログ、テスト、所有権、命名、ソースなど、作業を最もよく組織化したチームが勝ちます。
111 
112クリーンなリポジトリはより良いコンテキストになります。よく書かれた問題はより良い燃料になります。更新された運用手順書により、トークンと不安が軽減されます。明確な変更ログにより幻覚が軽減されます。
113 
114これは良いニュースですが、少し不快なニュースです。美しいのは、良い習慣が報われるからです。賢いプロンプトですべてを解決することはできないため、不便です。
115 
116エージェントは、発見したシステムの衛生状態を強化します。
117 
118## 明日はどう適用するか
119 
120実際のプロジェクトにコンテキスト エンジニアリングを導入するとしたら、次のような小さなことから始めるでしょう。
121 
122- 短く維持されたプロジェクト指示ファイル。
123- 期待される出力の良い例。
124- 利用可能なツールとそれらを使用するケースのリスト。
125- 引用可能な方法で書かれた建築上の決定。
126- 最小限の必須コンテキストを使用して発行します。
127- ログとテストを簡単に取得できます。
128- 人間によって変更可能な永続的な記憶。
129 
130次に、単純なことを測定します。エージェントは何回説明を求めなければならないか、または間違った方向に進んでしまいますか?
131 
132それが頻繁に発生する場合は、すぐに大きなモデルを追加しません。文脈を見ていきます。
133 
134## 私の読書
135 
136確かに、コンテキスト エンジニアリングという言葉は少し大げさな言葉です。しかし、コンセプトはしっかりしています。
137 
138これは、エージェントの知性がモデルだけにあるわけではないことを思い出させます。それは、私たちが彼のために準備する環境にあります。彼が何を見て、何を覚えているか、何ができるか、何を禁じられているか、どの情報源が真実であると認識しているかです。
139 
140人間的な部分は次のとおりです。コンテキストを適切に準備することは、ケアの一形態です。それは代理人だけでなくチームにも「推測してほしくない。必要なものを手に入れてほしい」と伝えているのだ。
141 
142魔法が少なくなる。よりクリーンな部屋。エージェントも私たちと同じようにそれを必要としています。
143 
144## ソース
145 
146- [LangChain ブログ: コンテキスト エンジニアリングの台頭](https://blog.langchain.com/the-rise-of-context-engineering/)
147- [サイモン ウィリソン: コンテキスト エンジニアリング](https://simonwillison.net/2025/Jun/27/context-engineering/)
148- [モデル コンテキスト プロトコル: 概要](https://modelcontextprotocol.io/introduction)
149- [Anthropic: 効果的なエージェントの構築](https://www.anthropic.com/engineering/building-popular-agents)
150- [OpenAI: エージェントを構築するための新しいツール](https://openai.com/index/new-tools-for-building-agents/)
151