ステップ2からステップ3へ渡る境界線は、機能の数ではない。問いが変わる瞬間だ。
ステップ2の間、あなたは文脈を渡す側だった。CLAUDE.mdを書き、必要なファイルを指定し、確認してほしい範囲を伝えていた。Claudeは、渡された文脈の中で動いていた。
ステップ3に入ると、この関係が逆転する。Claudeが、自分で文脈を取りに行くようになる。コードだけでなく、記録や議論、外部のデータソースまで、必要になったその場で読みに行く。
この違いは、レビューのときにあなたが自分に聞く問いにいちばんはっきり表れる。ステップ2では「コードは読んだか」と聞いていた。ステップ3では、それが「何の文脈が欠けていたか」に変わる。今回はこの境界線と、越えてはいけない線の両方を扱う。
問いが変わるということ
レビューであなたが自分に聞く問いそのものが、切り替わる。
「コードは読んだか」
差分を自分の目で追い、変更点を1行ずつ確認する。文脈は人間が用意し、Claudeはその範囲の中で正確に動いたかが焦点になる。
「何の文脈が欠けていたか」
Claudeが自分で情報を取りに行った結果、判断を誤ったなら、原因はコードの書き方ではなく取りに行けなかった文脈にある。焦点は接続先と取得範囲の設計に移る。
この移行を支えるのが、CLAUDE.md・auto memory・MCPという3つの文脈源だ。それぞれ性質が違う。
実はこの3つをどう組み合わせるかという営みには、すでに名前がついている。コンテキストエンジニアリングと呼ぶ。
ただしこの言葉、Anthropicが作った用語ではない。2025年6月19日、Shopify CEOのTobi Lütkeが「プロンプトエンジニアリングより的確な言葉だ」とX（旧Twitter）で発言し、その6日後の6月25日にAndrej Karpathyが同じ投稿に賛同して後押しした。1週間足らずの連鎖で、業界の共通語になった言葉だ。
“I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.”
筆者訳私は「プロンプトエンジニアリング」より「コンテキストエンジニアリング」という語の方が好きだ。この語の方が本質的なスキルをよく表している。それは、そのタスクをLLMが解決可能な形にするために、必要な文脈を全て与える技術だ。
“+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step.”
筆者訳「プロンプトエンジニアリング」より「コンテキストエンジニアリング」に一票。人々はプロンプトを日常でLLMに与える短いタスク説明と結びつけて考えるが、実用レベルのLLMアプリではコンテキストエンジニアリングこそが、次の一歩のためにちょうど正しい情報でコンテキストウィンドウを満たす繊細な技芸であり科学なのだ。
CLAUDE.md・auto memory・MCPをどう使い分けるか。ここまで扱ってきた話そのものが、この名前の中身にあたる。
Delegate, don't dictate
指図するのではなく、委任する。公式ドキュメントは、Claudeへの向き合い方をこう表現している。
“Delegate, don't dictate. Think of delegating to a capable colleague. Give context and direction, then trust Claude to figure out the details.”
筆者訳指図するのではなく、委任する。優秀な同僚に仕事を任せるつもりで。文脈と方向性を渡したら、あとはClaudeが細部を見つけ出すと信じる。
ステップ2では、この「文脈を渡す」の主語は人間だった。ステップ3では、文脈を取りに行くところまで委任する。優秀な同僚が、必要な資料を自分の判断で取り寄せてくるのに似ている。何でも聞かれるまで動かない新人と、必要な情報を自分で調べて持ってくる経験者の違いだ。
CLAUDE.mdとauto memoryについて、公式はもうひとつ重要な性質を明記している。
“Claude treats CLAUDE.md files and auto memory as context, not enforced configuration.”
筆者訳ClaudeはCLAUDE.mdファイルとauto memoryを、強制される設定としてではなく、文脈として扱う。
文脈は「お願い」であって「強制」ではない。確実に守らせたい規則は、CLAUDE.mdではなくHookに書く必要がある。この区別は第9回ですでに扱っている。文脈を自分で取りに行かせる段になると、この区別の重みがさらに増す。取りに行った文脈の中に、絶対に破ってはいけない一線があるなら、それは文脈として書くのではなく、仕組みで強制しなければならない。
どのくらいの粒度で書くかにも、判断の勘所がある。Anthropicはこれをaltitude problem（高度の問題）と呼んでいる。細かすぎる指示は、壊れやすいロジックをそのまま固定してしまい、想定外の場面で機能しなくなる。曖昧すぎる指示は、逆に具体的な手がかりを何も与えない。ちょうどよい高度を狙うことが、CLAUDE.mdを書くときの実務上の目標になる。
MCPという接続の窓
MCP（Model Context Protocol）は、Claudeが外部のツールやデータソースにつながるための標準規格だ。たとえるなら、必要なときに、別の部署や外部から必要な資料を自分で取り寄せることに近い。以前は依頼して待つしかなかった情報が、必要な瞬間に手元に届くようになる。
2026年の大きな変化は、MCPツールの読み込み方そのものにある。以前は、接続したMCPサーバーのツール定義が起動時に全部読み込まれ、コンテキストを圧迫していた。今はTool Search（deferred tools）が既定になり、名前だけを先に見せておいて、必要になったときに検索して読み込む方式に変わった。「MCPサーバーを増やすとコンテキストを食う」という理解は、もう古い。
なぜここまでしてトークンを絞るのか。理由は、コンテキストに積み上がったトークンが増えるほど、モデルの正確な想起能力が下がっていく現象があるからだ。Anthropicはこれをコンテキストロット（Context Rot）と呼んでいる。狙うべきは情報量の多さではなく、精度に効く最小限のトークン集合だ。
この考え方は、長時間タスクを支える3つの技法にもつながる。Anthropicが公開しているエンジニアリング記事は、圧縮（compaction。コンテキスト上限が近づいたら会話を要約し、圧縮した版で作業を再開する）、構造化されたメモ書き（structured note-taking。エージェントが節目ごとにコンテキストの外へ進捗を書き残す）、サブエージェント構成（sub-agent architectures。専門化したサブエージェントが自分のコンテキストで調べたうえで、結果を1000から2000トークン程度に凝縮して呼び出し元へ返す）の3つを挙げている。MCPで外部から取ってきた文脈も、この3つの技法と組み合わせて初めて、長く自律的に動かせるようになる。
つないではいけない線
つなげるかどうかを決める基準は、便利さではない。
注意
機密情報には絶対につながない
MCPで何につなげられるかと、何につないでよいかは、まったく別の問題だ。個人や取引先を特定できる機密情報（氏名・連絡先・契約内容など）が流れる経路には、絶対にMCPをつながない。
基幹システムと直接連携するツールを避けるべき理由も、突き詰めればここに行き着く。便利さは、情報の扱いを慎重にする理由にはならない。むしろ「自分で文脈を取りに行ける」ようになった段階だからこそ、取りに行ってはいけない場所を先に決めておくことが重要になる。
これは第2回で扱った「触らない線引き」の延長にある。ステップ0や1では、その線引きは人間が毎回意識していれば守れた。ステップ3では、Claudeが自分で文脈を探しに行くようになる分、線引きを仕組み（接続そのものを作らない、権限を絞る）で担保する必要が出てくる。意識だけに頼るガードレールは、規模が増えたときにいちばん先に破れる。
つないでよいものの例
つないでよい先は、公開情報に限られる。
外部ツール・データソースへの接続の仕組みと、Tool Search（deferred tools）の解説
現実的な接続先は、公開情報のデータベース、社内ナレッジベース、非個人情報のプロジェクト管理ツールなど、個人や取引先を特定しない情報に限られる。何がつないでよく、何がだめかを毎回考えるより、最初に線を引いて、それを越える提案が出たら立ち止まるという運用のほうが安全に倒れる。
よくある誤解と罠
- 文脈を渡すのをやめてしまう: 委任は「何も渡さない」ことではない。目的と方向性は渡した上で、細部の取得を任せる
- CLAUDE.mdに絶対厳守のルールを書いて安心する: 文脈は強制ではない。本当に守らせたい一線はHookで実装する
- MCPは増やすほど便利だと思い込み、線引きを後回しにする: つなげる技術的な可否と、つないでよい倫理的な可否は別の判断だ。後者を先に決める
今日のまとめ
- ステップ2の問い「コードは読んだか」は、ステップ3で「何の文脈が欠けていたか」に変わる
- CLAUDE.md・auto memory・MCPはどれも文脈であって強制ではない。守らせたい一線はHookで担保する
- 個人や取引先を特定できる機密情報には、MCPを絶対につながない。技術的な可否と倫理的な可否は別の判断
明日のアクション
今つないでいる、またはこれからつなごうとしているMCP接続を1つ書き出してください。
そのうえで、(1) その接続先に個人や取引先を特定できる機密情報が流れる経路が一切ないか (2) 万一Claudeがその接続を誤って使ったとき、被害が最小限に収まる設計になっているか、の2点を確認します。
どちらか一方でも自信を持って答えられなければ、その接続はまだつなぐ段階ではありません。
次回、第17回では、この自律の広がりを支えるコストの規律に入ります。