このメモは、Thoughtworks の技術者たちがソフトウェア開発のための生成 AI の探究を記録している martinfowler.com の「Exploring Gen AI」シリーズの一篇で、コーディングエージェントのコンテキストを設定し、充実させるための選択肢についての入門である。著者は、こうした選択肢がこの数か月で急増しており、Claude Code が先行し、他のコーディングアシスタントが後に続いていること、そしてコンテキストエンジニアリングがこれらのツールの開発者体験の大きな部分になりつつあることを指摘する。著者は、この実践を「より良い結果を得られるように、モデルが目にするものをキュレーションすること」とする同僚の定義を引用している。
メモは、コンテキストの設定を、再利用可能なプロンプトと、著者がコンテキストインターフェースと呼ぶものとに分類し、それぞれのコンテキストをいつ読み込むかを誰が決めるのか、そしてその量はどれだけであるべきかを問い、そのうえで 2026 年 1 月時点のClaude Codeの機能をそれらの軸に沿って順に見ていく。最後に、コンテキスト設定を共有することの難しさと、それがもたらすコントロールの度合いを過大評価することへの警告で締めくくっている。
要点
- コーディングエージェントのためのコンテキストエンジニアリングは、そのほとんどすべての形態が、プロンプトを収めた Markdown ファイルに帰着する。著者はその意図を、指示（エージェントに何かをするよう伝えるプロンプト）とガイダンス（エージェントが従うべき一般的な規約で、ルールやガードレールとも呼ばれる）に分けているが、両者はしばしば混ざり合うとも述べている。
- 著者は、確立された名前を見つけられなかったと述べる用語「コンテキストインターフェース」を、LLM がそうすると判断した場合にどのようにしてより多くのコンテキストを得られるかを LLM に伝える説明に対して用いている。組み込みツール、MCP サーバー（Model Context Protocol）、スキル（Agent Skills）がそれにあたる。設定される数が多いほど、それらが占めるコンテキストも大きくなるため、タスクごとに選ぶべきだとされる。
- ワークスペース内でのファイルの読み取りと検索は、最も基本的かつ強力なコンテキストインターフェースとして特に取り上げられており、そのため既存のコードベースがコンテキストとしてどれだけ役立つかを振り返ってみる価値があるとされる。
- コンテキストを読み込むと決める主体には 3 種類ある。LLM（監督なしのエージェントには必要だが、期待したときに実際にコンテキストを読み込むかどうかには一定の不確実性がある——例：スキル）、人間（自動化と引き換えにコントロールが得られる——例：スラッシュコマンド）、そして決定論的なタイミングでのエージェントソフトウェア自体（例：Claude Code のフック）である。
- エージェントの有効性はコンテキストを与えすぎると低下し、コンテキストが多すぎればコストもかかるため、大きなコンテキストウィンドウはそれを埋める理由にはならない。著者は、ルールファイルのようなコンテキストは最初から詰め込むのではなく徐々に積み上げていくことを勧めており、半年前には明示する必要があったことも、より高性能なモデルではもう不要かもしれないと指摘している。
- コンテキストがどれだけ埋まっているか、何がスペースを占めているかについての透明性は、ツールの重要な機能として示されている。ツールの中には、会話履歴を定期的にコンパクションしたり、ツールの表現方法を最適化したりして、自らコンテキストを最適化するものもある。
- メモが記述する Claude Code の機能群は次のとおりである。CLAUDE.mdはセッション開始時に常に読み込まれるガイダンスで、最も頻繁に繰り返されるプロジェクト全体の規約のためのものであり、AGENTS.mdはそうしたメインのルールファイルを標準化する試みとして言及されている。ルールはファイルパスにスコープを限定できるガイダンスで、一致するファイルが読み込まれたときに読み込まれる。スラッシュコマンド（カスタムスラッシュコマンド）は人間がトリガーする指示で、Claude Code では非推奨となりスキルに取って代わられたと説明されている。スキルはガイダンス、指示、ドキュメント、スクリプトをまとめたもので、LLM（スキルの説明に基づいて）または人間が必要に応じて読み込める。サブエージェントは指示をモデルとツールの設定と組み合わせたもので、独自の並列化可能なコンテキストウィンドウで動作する。MCP サーバーはエージェントにデータソースとアクションへのアクセスを与える。フック（エージェントフック）はライフサイクルイベントに応じて決定論的に実行されるスクリプトである。そしてプラグインは、これらのいずれかを配布するための手段である。
- 著者は現在を「storming」の段階と呼び、機能の一覧はいずれ収束すると見込んでいる——たとえば、スキルがスラッシュコマンドとルールの両方を吸収するといった形で。
- 良いコンテキスト設定は構築に時間がかかる。ある設定が機能するかどうかを判断するには、しばらく使ってみる必要があるからである——「コンテキストエンジニアリングにはユニットテストがない」。その共有は、共有する側と受け取る側のコンテキストの違い（見知らぬ者同士よりもチーム内の方がうまくいく）、コピーした指示による過剰設計の傾向、経験レベルの差、そしてコピーしたコンテキストに何が含まれているかへの意識の低さによって妨げられ、最後のものは指示の重複や矛盾につながりうる。
- メモは、コンテキストエンジニアリングは本当の意味でのエンジニアリングではないと論じる。実行は依然として LLM が指示をどう解釈するかに左右されるため、ある機能が振る舞いを「保証する」あるいは「ハルシネーションを防ぐ」という主張は誇張である。有用な結果が得られる確率を高めることはできるが、それでも確率で考え、適切なレベルの人間による監督を選ぶ必要がある。
背景
このメモは明示的にスナップショットである。Claude Code の機能一覧は 2026 年 1 月時点のものであり、著者は機能の状況をまだ流動的なものとして示している。指示とガイダンスの区別、コンテキストインターフェース、誰がコンテキストを読み込むと決めるのかといったカテゴリーは、機能を整理するための著者自身の枠組みであり、その推奨事項（コンテキストは徐々に積み上げる、コピーした設定には注意する）は測定ではなく著者自身の経験に基づいている。