コンテキストエンジニアリングとは？CLAUDE.mdの実例で解説

コンテキストエンジニアリングとは、AIに渡す情報（指示・会話履歴・外部資料・ツール）を、必要な範囲と順序で設計する技術です。

プロンプトエンジニアリングが「どう頼むか」を磨くのに対し、「何を見せるか」まで設計対象を広げた考え方といえます。

私自身、Claude Codeを毎日使う中で「プロンプトを工夫する」段階から「渡す情報そのものを設計する」段階に頭が切り替わった瞬間がありました。

この記事では、定義とプロンプトエンジニアリングとの違いを具体例で整理し、構成要素・Anthropicが示す手法・今日からできる5ステップまでを解説します。

コンテキストエンジニアリングとは？

コンテキストエンジニアリングとは、AIに答えを出させるために必要な情報を、必要な範囲・順序・形式で設計する技術です。

プロンプトエンジニアリングが「言葉の選び方」に焦点を当てるのに対し、コンテキストエンジニアリングは「渡す情報そのもの」を扱う点が違います。

両者は対立する概念ではなく、コンテキスト設計という大きな枠組みの中にプロンプトの工夫が含まれる、と捉えるとわかりやすいです。

一言でいうと「AIに渡す情報の設計」

コンテキストエンジニアリングを一言で説明すると、AIが正しく判断するために必要な情報だけを揃える作業です。

人間の新人に仕事を任せる場面を思い浮かべてください。

指示の言い回しをどれだけ工夫しても、必要な資料や過去の経緯を渡さなければ的外れな成果物が返ってきます。

AIも同じで、システムプロンプト・会話履歴・外部データをどう組み合わせるかが結果の質を左右します。

プロンプトエンジニアリングとの違いを比較表で整理

両者の違いを整理すると、次の表のようになります。扱う対象と目的がそもそも異なるとわかると混同しにくくなります。

具体例｜同じ依頼でもコンテキスト次第で結果が変わる

違いは、Claude Codeにバグ修正を頼む場面を比べるとはっきりします。

言い回しを磨くより、判断材料を揃えるほうが効くことがわかります。

ただし、材料を全部渡せばよいわけではありません。どこまで渡してどこで止めるか、その線引きこそがコンテキストエンジニアリングの中心です。

コンテキストエンジニアリングを学べる本

体系的に学びたい人には書籍もおすすめです。

日本語で読める1冊目として挙げたいのが、2026年2月10日に技術評論社から刊行された『LLMの原理、RAG・エージェント開発から読み解く コンテキストエンジニアリング』（蒲生弘郷 著、240ページ）です。

LLMの仕組みからAPI、RAG、AIエージェントまでを「コンテキストをどう組み立てるか」という1本の軸で貫いている構成です。

英語で読むなら「Context Engineering for Multi-Agent Systems」（Denis Rothman 著、Packt Publishing）も候補で、O'Reillyのプラットフォームでも読めます。

書籍で原理を押さえつつ、この記事のような実践例や公式ドキュメントで手を動かすのが近道です。

コンテキストエンジニアリングが注目される理由

コンテキストエンジニアリングが急速に広まった背景には、AIの使い方が「1問1答」から「長時間タスクを任せるエージェント」に移り変わったことがあります。

この変化を放置すると、プロンプトをどれだけ磨いてもAIの回答がずれていく現象に悩まされ続けることになります。

登場のきっかけ｜Karpathy氏とLütke氏の発言

この言葉が一気に広まったきっかけは、2025年6月のSNS投稿です。

まずShopify CEOのTobi Lütke氏がXで「プロンプトエンジニアリングよりコンテキストエンジニアリングという言葉が好きだ」と投稿し、その約1週間後にAI研究者のAndrej Karpathy氏が「コンテキストウィンドウに次の一手に必要な情報だけを詰め込む繊細な技術」と賛同する投稿をしたことで、開発者コミュニティで急速に広まりました。

実際の投稿はこちらです。まずはTobi Lütke氏の投稿。

twitter.com で見る

続いて、それに賛同したAndrej Karpathy氏の投稿です。

twitter.com で見る

ただし、渡す情報を設計するという考え方自体は、それ以前から実務の現場で自然と行われていたものです。

言葉が後から追いついてきた、というのが実態に近いです。

その後2025年9月29日には、Claudeを開発するAnthropicが公式ブログで「Effective context engineering for AI agents」を公開し、エージェント開発の中心的な課題として位置づけました。

プロンプトの工夫だけでは通用しなくなった理由

単発の質問であれば、プロンプトの言い回しを工夫するだけで十分に精度が上がります。

ところがClaude CodeのようにAIが複数ファイルを横断して作業する場面では、プロンプト単体の工夫はすぐ限界に達します。

過去のやり取り・プロジェクトのルール・実行結果といった大量の情報を、AIが混乱しない形で渡し続ける必要があるからです。

コンテキストの肥大化

タスクが長くなるほど、会話履歴やツールの実行結果は際限なく積み上がっていきます。

この肥大化を放置すると、AIは古い情報と新しい情報の優先順位をつけられなくなり、指示を忘れたかのような挙動を見せ始めます。

この優先順位付けの破綻こそが、コンテキストエンジニアリングという発想が必要になる核心部分です。

コンテキストは「有限な資源」
Anthropicは前述の記事で、LLMには人間の作業記憶のような「注意の予算」があり、トークンが増えるほど1トークンあたりの効き目は下がると説明しています。コンテキストウィンドウが広がっても、詰め込めば詰め込むほど良くなるわけではありません。同記事が掲げる指針は、望む結果につながる「情報密度の高い最小限のトークン」を探すことです。

LLMの仕組みとは？生成AIとの違いを5ステップで解説

LLM（大規模言語モデル）の仕組みを図解でやさしく解説。正体は次の単語を確率で予測する機械です。トークン化・Attention・Transformerによる推論の流れから、生成AIとの違い、ハルシネーションが起きる理由まで初心者向けにかみ砕いて説明します。

コンテキストエンジニアリングを導入する3つのメリット

コンテキスト設計を意識するだけで、AIとのやり取りには具体的な変化が生まれます。特に効果を実感しやすいのは次の3点です。

コンテキストを構成する5つの要素

AIに渡すコンテキストは、大きく分けて5つの要素で構成されます。それぞれの役割を理解すると、どこを増やしどこを削るべきかの判断がつきやすくなります。

5つの要素は、毎回必ず渡す「常時」と、必要になった時点で差し込む「必要時」に分けて考えると整理しやすくなります。どちらも最終的には有限のコンテキストウィンドウに収まる分だけがAIに届きます。

システムプロンプトと会話履歴

システムプロンプトはAIの役割や制約を固定する土台です。

会話履歴は直前までのやり取りを保持する部分で、ここが長くなりすぎると重要な指示が埋もれてしまいます。

土台と履歴のバランスがコンテキスト設計の出発点になります。

RAG・ツール情報・状態メモリ

RAGは外部ドキュメントを検索して必要な部分だけを差し込む仕組みです。

ツール情報はAIが実行できる操作の一覧、状態メモリは作業の進捗を保持する仕組みを指します。

この3つは「必要なときに必要な分だけ」渡すのが鉄則で、常時全部を渡すとかえって精度が落ちます。

情報が多すぎると起きる「コンテキスト腐敗」

コンテキスト腐敗とは、情報を詰め込みすぎた結果、AIが古い指示と新しい指示を混同したり、無関係な情報に引っ張られたりする状態です。

英語では「Context Rot」と呼ばれ、次のような症状として表れます。

「念のため」で情報を足し続けると、いずれこの状態に陥ります。渡す情報は多いほど良いわけではありません。

長いタスクを支える4つの手法

コンテキスト腐敗を避けながらAIに長時間の作業を任せるために、Anthropicは前述の記事で、長時間タスク向けの3手法（圧縮・構造化メモ・サブエージェント）と、情報を必要な瞬間に取りに行く「Just-in-Time」の考え方を紹介しています。

どれも「コンテキストウィンドウに今必要なものだけを残す」ための工夫で、Claude Codeの機能にそのまま対応しています。

ただし、どれもコストはゼロではありません。

私の環境では、サブエージェントは1回起動するだけで約4万トークンを消費していました。数行の修正のような小さな作業まで委任すると、節約どころか逆効果になります。

手法そのものより、「この作業にはどれが見合うか」を選ぶ判断こそがコンテキストエンジニアリングの腕の見せどころです。

Claude Codeで見るコンテキスト設計の実例

ここからは、このブログを運営しているリポジトリで実際にClaude Codeへ渡している情報の設計を例に、ここまでの原則がどう形になるかを見ていきます。

CLAUDE.mdは「常時ロードする前提知識」

Claude CodeのCLAUDE.mdは、毎セッション自動で読み込まれる指示ファイルです。構成要素でいえば「システムプロンプト」に近い役割で、常時渡す土台になります（実際には、システムプロンプトそのものではなく、その後にユーザーメッセージとして渡されます）。

常時読まれる以上、書くのはどの作業でも必要な情報だけに絞るのが原則です。公式ドキュメントも1ファイル200行未満を目安とし、それを超えるならパス限定のrulesに分けるよう案内しています。

置き場所・読み込み順・テンプレートといった書き方の詳細はCLAUDE.mdとは？rulesとの違い・書き方まで完全ガイド、README.mdやrulesとの役割分担はCLAUDE.mdとREADME.mdの違い｜rulesとの役割分担で解説しています。

rulesファイルをpaths指定で自動ロードする仕組み

特定のディレクトリでしか使わない規約は、.claude/rules/配下のルールファイルに分けています。

各ファイルのfrontmatterでpathsを指定しておくと、Claudeがパターンに一致するファイルを読んだときだけ、そのルールが自動で読み込まれます。公式ドキュメント上、rulesのfrontmatterで読まれるのはpathsだけで、ほかの項目は無視されます。

全部を常時読み込ませるのではなく、必要なタイミングで必要な分だけ渡す設計です。

---
paths:
  - "python/wp_manager/**"
---
# WordPress管理スクリプト ルール
（wp_manager配下を操作するときだけ自動で読み込まれる）

実際にこのブログを運営しているリポジトリでは、.claude/rules/配下は2026年9月時点で6本のファイルに分割されています。

秘密情報の取り扱いルールのような「常に守るべきもの」だけは常時ロードにし、残り5本はディレクトリごとにpathsで範囲を絞って自動ロードする構成です。

全部を常時読み込ませないという判断そのものが、渡す情報を設計するという発想の実践です。

Skillsやサブエージェントまで範囲を広げると、読み込みのタイミングは次の3層に分かれます。

コンテキストを肥大化させて失敗した経験

正直に書くと、最初はCLAUDE.mdに何でも詰め込んでいました。プロジェクトの全ルールを1ファイルにまとめていた時期があります。

すると関係のない作業をしているときにも大量の前提情報が読み込まれ、指示への反応が鈍くなったり、無関係なルールを引っ張り出してきたりする場面が増えました。

ルールをトピック別に分割し、paths指定で必要なときだけ読み込む形に変えてから、AIの反応の的確さが明らかに変わりました。

渡す情報を減らしたのに精度が上がる、という逆説を身をもって味わいました。

「CLAUDE.mdは短ければ短いほど良い」とよくいわれますが、私の実感は少し違います。

短さそのものより、どう分割してどのタイミングで読み込ませるかという粒度設計のほうが効いていました。

ハーネスエンジニアリングとの違い｜「何を見せるか」と「どこまで動けるか」

コンテキストエンジニアリングと並べて語られることが多いのが、ハーネスエンジニアリングです。どちらもAIの作業環境を整える考え方ですが、設計する対象が違います。

コンテキストエンジニアリングが「AIに何を見せるか」を設計するのに対し、ハーネスエンジニアリングは「AIがどこまで動けるか」まで含めた環境全体を設計します。

ハーネスエンジニアリングとは

ハーネスエンジニアリングとは、AIエージェントが動作する「環境そのもの」を設計する技術領域です。

AIに何を見せ、何をさせ、どう評価し、どこまで許可するかを設計して、能力を安全かつ再現性高く引き出すことを目的としています。

「ハーネス（harness）」は本来、馬具や安全帯を指す英語です。力を安全に制御しながら、目的に向けて活かすための道具を指します。

AIの文脈でも意味はそのままで、AIモデルと外の世界の間に挟まり、行動の範囲を決めて結果を監視する制御の仕組みがハーネスです。

LangChainのVivek Trivedy氏は、2026年3月に公開した記事でこれを「Agent = Model + Harness」という式で表しました。同じモデルでも、周りの仕組みの設計次第でエージェントの働きが変わるという考え方です。

プロンプト・コンテキスト・ハーネスの違いを比較表で整理

3つは対立する概念ではなく、積み重なる層です。何を設計し、どれくらい強くAIを縛れるかで並べると次のようになります。

プロンプトとコンテキストは、AIへの「提案」と「情報提供」です。正しい情報を渡すことはできても、AIの行動範囲や承認の流れまでは制御できません。

ハーネスは、AIに「こう動け」と頼むのではなく、「この範囲でしか動けない」環境を作ります。そこが根本的な違いです。

ハーネスを構成する要素は、大きく次の3つに整理できます。

• ルールファイル：AIが守る行動規範を明文化したもの。Claude Codeでは CLAUDE.md が相当します
• フィードバックループ：ビルド・テスト・リントの結果を自動でAIに返し、「失敗→修正→再試行」を人の手を介さずに回す仕組み
• コンテキスト管理：判断に必要な情報を、必要なタイミングで過不足なく渡す仕組み

3つ目のコンテキスト管理が、この記事で扱ってきた領域です。渡す情報を整えた先に、AIを止める仕組みと結果を返す仕組みが加わったものがハーネスだと捉えると、両者の関係がつかみやすくなります。

Claude Codeでハーネスにあたる設定

Claude Codeでは、CLAUDE.mdやrulesで情報を整えたうえで、settings.json の permissions と hooks がハーネスの「強制」と「観測」を担います。

permissionsは、AIが実行できるコマンドを許可リスト（allow）と拒否リスト（deny）で絞る設定です。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(pytest *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)"
    ]
  }
}

permissionsは「言葉で頼む」のではなく、Claude Codeが実行前に許可・拒否を判定する仕組みです。ここがCLAUDE.mdのようなルールファイルとの大きな違いです。

ただしBashのパターンは引数の書き方次第ですり抜けることがあるため、本当に止めたい操作はdenyだけに頼らず、サンドボックスやPreToolUseフックとも組み合わせます。

hooksは、Claude Codeが特定の操作をしたときに自動でシェルコマンドを実行する仕組みです。次の設定では、AIがファイルを編集するたびにpre-commitが走ります。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r .tool_input.file_path); pre-commit run --files \"$f\" >&2 || exit 2"
          }
        ]
      }
    ]
  }
}

hookには編集したファイルのパスがJSONで標準入力に渡されるので、jqで取り出しています。

リントエラーがあればpre-commitの出力を標準エラーに流して終了コード2で終えることで、その内容がAIへのフィードバックとして返ります（終了コードが2以外だと、AIには伝わりません）。

これで「書く→チェック→修正」のループが、人の手を介さずに回り始めます。私もGodotでのゲーム開発では、.gdや.tscnを編集した直後に単体テストが走るPostToolUseフックを入れています。

「CLAUDE.mdに書いたのに守ってくれない」と感じたら、情報の渡し方を見直すのがコンテキストエンジニアリング、守らせる仕組みを足すのがハーネスエンジニアリングです。こう切り分けると、次の一手を選びやすくなります。

Claude Codeおすすめ設定5選｜承認9割減の実例

Claude Codeのおすすめ設定を5要素で解説。settings.jsonのpermissions/hooksで承認9割減、CLAUDE.md・Skills・MCPまで1年運用した実例を公開します【2026年版】。

コンテキストエンジニアリングのやり方｜今日からできる5ステップ

大がかりな仕組みを作らなくても、コンテキストエンジニアリングの考え方は今日から取り入れられます。ポイントは「渡す量」ではなく「渡す設計」を意識することです。

ChatGPTやClaudeのチャットでも、Claude Codeのようなエージェントでも、進め方は次の5ステップで共通です。

5つ目が特に大切です。うまくいかないときに情報を足したくなりますが、先に削るほうが効くことは少なくありません。以下では、ステップを回すときのコツと注意点を補足します。

必要な情報だけを渡す設計のコツ

まず、今の会話やタスクに直接関係する情報だけを渡す意識を持ちます。具体的には次の4つです。

この一手間だけで、AIの回答の的確さは大きく変わります。

情報を構造化してタイムリーに更新するコツ

情報は箇条書きや見出しで構造化し、古くなった内容はこまめに更新します。

私の場合、ルールファイルを機能別に分けたことで、更新すべき箇所がすぐ特定できるようになりました。

1つの巨大なファイルを都度読み直す手間がなくなったのは、地味に大きな効果です。

やりすぎ・削りすぎに注意

コンテキストエンジニアリングにも手間とコストはかかります。注意したいのは次の3点です。

目指すのは「最小」ではなく「過不足なし」です。

コンテキストエンジニアリングに関するよくある質問

Q1. どちらを先に学ぶべき？
プロンプトエンジニアリングを先に学ぶのが自然です。指示の出し方に慣れたうえで、渡す情報の設計に意識を広げると理解しやすくなります。

Q2. いつから使われている言葉？
2025年6月ごろ、Tobi Lütke氏やAndrej Karpathy氏のSNS投稿をきっかけに急速に広まった言葉です。概念自体はそれ以前から存在していました。

Q3. 具体例を教えてください。
Claude CodeのCLAUDE.mdやrulesファイルはその代表例です。プロジェクトのルールを分割し、必要なときだけ自動で読み込ませる設計そのものがコンテキストエンジニアリングにあたります。

Q4. コンテキストが多いほどAIの精度は上がりますか？
上がりません。無関係な情報が増えるとAIは優先順位を見失い、かえって精度が落ちます。渡す情報は量より設計が重要です。

Q5. 個人開発で必要か？
必要です。ルールファイルを1つに詰め込むほど反応が鈍くなる現象は、個人開発の小規模プロジェクトでも同じように起こります。

Q6. ハーネスエンジニアリングとの違いは何ですか？
コンテキストエンジニアリングが「渡す情報の設計」を指すのに対し、ハーネスエンジニアリングはAIが自走できる作業環境そのものの設計を指します。

渡す情報を整えた先に、AIを動かす仕組み全体の設計があるとイメージするとわかりやすいです。定義と比較表は、上の「ハーネスエンジニアリングとの違い」で整理しています。

Q7. コンテキストエンジニアリングのやり方は？
ゴールと完了条件を決め、判断に必要な情報を洗い出し、「常時渡すもの」と「必要時に渡すもの」に仕分けてから、構造化して渡します。出力がずれたら、情報を足す前に古い情報や無関係な情報を削るのが基本です。

まとめ｜コンテキスト設計がAI活用の質を決める

コンテキストエンジニアリングは、プロンプトの言い回しではなく、AIに渡す情報そのものを設計する技術です。

ただし情報を減らせば減らすほど良いわけでもなく、過不足のないバランスを見極めることが本質です。今回の内容を振り返ります。

• 定義：AIが正しく判断するために必要な情報を、必要な範囲だけ設計すること
• プロンプトエンジニアリングとの違い：対象が「言い回し」か「情報全体」かの違い
• 失敗パターン：情報を詰め込みすぎるコンテキスト腐敗
• やり方：ゴール決め→洗い出し→常時/必要時の仕分け→構造化→削って更新の5ステップ
• Claude Codeでの実例：CLAUDE.mdは共通の要点だけにし、規約はpaths付きrulesに分けて必要なときだけ読み込ませる

CLAUDE.mdを1ファイルに詰め込んでいた頃の自分に伝えたいのは、情報を足すより減らして整理するほうが結果につながる、という一点です。

まずは今使っているプロンプトや指示書を見直し、本当に毎回必要な情報かどうかを問い直すところから始めてみてください。