コンテキストエンジニアリングとは?プロンプトエンジニアリングとの違いと、仕事でAIに渡す文脈の作り方

公開日:/更新日:

7日間無料で試す

コンテキストエンジニアリングとは、AIが仕事をするときに読む情報全体を、何を・いつ・どの形で渡すかまで含めて設計することです。指示文の書き方を磨くプロンプトエンジニアリングに対して、指示文の外にある目的・今の状態・経緯・資料・使える道具までを扱います。

要点

  • プロンプトは、AIに渡す文脈の一部です。答えのずれの多くは、言い回しより渡した材料の不足や混ざりものから起きます
  • 会社の仕事で渡す材料は、目的・今の状態・経緯・やり方・守ること、の5つで考えると漏れにくくなります
  • 渡す量は多ければ良いとは限りません。関係あるものは原本のまま、関係ないものは渡さない、が基本です
  • 毎回同じ説明をしている文脈は、AIが自分で読みに行ける置き場に移すと、頼み方が短くなります

コンテキストエンジニアリングとは:AIが読む情報全体を設計すること

AIの答えは、その場でAIが読めた情報で決まります。ここでいうコンテキスト(文脈)には、AIへの指示文に加えて、会話のこれまでの流れ、貼り付けた資料、検索して見つけた文書、つないだツールから取ってきたデータ、AIが作業中にとったメモまで、AIがその時点で目にしているもの全部が入ります。

コンテキストエンジニアリングは、この「AIが目にするもの」を偶然に任せず、仕事に合わせて組み立てる考え方です。大きく分けると、次の3つを決めます。

決めること中身の例
何を渡すか仕事の目的、今どこまで進んでいるか、関係する資料、守る決まり
いつ渡すか最初に全部渡すか、作業の途中でAIが必要になったときに読みに行かせるか
どの形で渡すか原本のまま見せるか、ありか(URLやファイルの場所)だけ教えるか、要点に絞るか

言葉としては、2025年の半ばから広まりました。経緯をまとめたSimon Willison氏のブログ記事(2025年6月27日)によると、ECプラットフォーム企業のCEOであるTobi Lütke氏が「プロンプトエンジニアリングより、コンテキストエンジニアリングという呼び方がいい」と書き、AI研究者のAndrej Karpathy氏がそれに賛同したことで、使う人が一気に増えました。Claudeを開発するAnthropicも、2025年9月29日の技術記事「Effective context engineering for AI agents」で、コンテキストエンジニアリングをプロンプトエンジニアリングの自然な発展として説明しています。

プロンプトエンジニアリングとの違い

プロンプトエンジニアリングは、AIへの指示文(プロンプト)の言い回しや構成を工夫して、答えの質を上げる技術です。役割を与える、出力の形式を指定する、例を見せる、といった工夫がこれにあたります。

コンテキストエンジニアリングは、そのプロンプトを含む、AIが読む情報全体を扱います。プロンプトエンジニアリングはそのまま残り、その上に「指示文の外に何を用意するか」が加わった、と考えると分かりやすいはずです。

図:プロンプトはコンテキストの一部。コンテキストには指示文のほか、会話の流れ、貼り付けた資料、検索した文書、ツールのデータ、AIのメモが入り、そのすべてを何を・いつ・どの形で渡すか設計するのがコンテキストエンジニアリング。

比べるところプロンプトエンジニアリングコンテキストエンジニアリング
主に扱うもの指示文の書き方指示文+目的・状態・資料・履歴・道具
向く場面1回で終わる依頼続けて進める仕事、AIエージェント
うまくいかない時言い回しを直す渡した材料の過不足を見直す
作ったものの寿命その場の1回置き場に残し、次の依頼でも使う

同じ依頼を2通りで出してみると、違いがよく分かります。

たとえば「A社向けの研修提案の比較資料を、いい感じに作って」とだけ頼むと、AIはどこにでもある比較表のひな形を返します。言い回しをどれだけ丁寧にしても、AIは研修の中身も、価格も、商談でA社が何を気にしていたかも見ていないからです。

同じ依頼に、「決裁者が金曜までにA案とB案を比べて判断できる状態にしたい」という目的と、直近の商談記録2件、講師の稼働表、実施計画の下書きを添えると、返ってくるものが変わります。指示文はほぼ同じ長さのままです。変えたのは渡した材料のほうで、ここがコンテキストエンジニアリングの領域です。

なぜ今、コンテキストエンジニアリングが必要なのか

チャットで1問1答をしていた頃は、指示文を工夫すれば足りる場面が多くありました。今は、AIエージェント(ファイルを読み書きしたり、ツールを操作したりして、作業まで進めるAI)が仕事の中で長く動くようになっています。1つの仕事の中で、AIは何十回も資料を読み、ツールを呼び、結果を受け取ります。そのたびにAIの読む情報は増え、入れ替わります。

ここで問題になるのが、情報の多さです。Anthropicの上の記事では、AIが一度に読む量が増えるほど、中の情報を正確に思い出す力が落ちていく現象を「context rot(コンテキストの劣化)」と呼び、コンテキストを限りのある資源として扱うよう勧めています。AIが一度に読める量の上限が大きくなっても、「とりあえず全部入れておく」は答えの質を下げる方向に働きます。

もう1つは、会社の仕事ならではの事情です。会社の仕事の文脈は、担当者の頭の中、チャットの流れ、複数のツールに散らばっています。人であれば、隣の席の会話や会議の雑談から自然に拾えますが、AIにはその拾い方がありません。だれかが意図して渡さない限り、AIは会社の事情を知らないまま動きます。

会社の仕事でAIに渡す文脈:5つの材料

業務でAIに渡す文脈は、次の5つに分けて考えると漏れにくくなります。例は、法人向けの研修を提案している営業の仕事です。

材料中身営業での例
目的何のための仕事か、どうなれば終わりか決裁者が金曜までにA案とB案を比べて判断できる
今の状態どこまで進んだか、何が残っているか体制の回答は送付済み。決裁者が2案で迷っている
経緯決めたことと理由、試してだめだったこと先方は金額より開始時期を気にしている
やり方くり返す手順、社内の書き方提案資料のひな形、上長確認の流れ
守ること見せない情報、人が確かめる場面先方に送る前に担当者が確認する

この中で抜けやすいものが2つあります。目的と経緯です。

図:会社の仕事でAIに渡す5つの材料は、目的・今の状態・経緯・やり方・守ること。研修を提案する営業の例で、抜けやすいのは目的と経緯。

目的は、頼む側の頭の中では当たり前すぎて、書かずに済ませてしまいます。「比較資料を作って」には、だれが・いつまでに・何をできる状態にしたいのかが入っていません。達成したかどうかが分かる形で目的を渡すと、AIは作りながら「この資料で決裁者は判断できるか」を自分で確かめられます。

経緯は、ファイルにもメールにも残っていないことがよくあります。「先方は金額より開始時期を気にしている」「前回の提案が流れた本当の理由は現場の反対だった」といった話は、書き出さない限りAIは知りようがありません。一行で構わないので、その場で書いて渡します。

何を渡すか迷ったら、「この仕事を自分がやるなら、何を開くか」と考えます。営業なら直近の商談メモと送った見積、採用なら募集要項とこれまでの面接記録、経理なら前月の締めのやり取りと取引先ごとの支払条件。開くものとして挙がったものが、渡す文脈です。

AIへの文脈の渡し方:原本・ありか・置き場

何を渡すかが決まったら、次はどの形で渡すかです。業務で使うときの基本は4つあります。

  1. 関係するものは、原本のまま見せる。 会議の文字起こしを議事録にまとめ直したり、資料の要点を自分で書き直したりすると、その時点で落ちた情報をAIは補えません。人が要約すると、判断の材料がやせます
  2. ありかを教えて、取りに行かせる。 資料の中身を毎回貼り付けるより、ファイルの場所やURLを伝えて、必要になったときにAIに読ませるほうが、AIの読む量を必要な分に抑えられます。Anthropicの記事でも、ファイルの場所やリンクのような軽い手がかりだけを持たせ、作業中に必要な分を読み込む方法が紹介されています
  3. 関係ないものは渡さない。 共有フォルダやチャットの履歴を丸ごと渡すと、AIはどれを読めばよいか決められず、関係の薄い情報に引っぱられます。「要約しない」と「全部渡さない」は両立します。分ける線は、その仕事に関係するかどうかです
  4. 毎回同じ説明をしているものは、置き場に移す。 目的や経緯を依頼のたびに書いているなら、それはAIが自分で読みに行ける場所に置いておく文脈です

4つ目の置き場について、何をどこに置くかは「カンパニーブレインとは」で、Claude Code・Codexの指示ファイル(CLAUDE.md・AGENTS.md)とMCPの使い分けは「Claude Code・Codexに会社の文脈をチームで共有する方法」でくわしく扱っています。ここでは、置き場を考えるときの線引きだけ押さえておきます。変わりにくい決まりごと(用語、書き方、使ってよいツール)は指示ファイルに、毎日動く仕事の目的・状態・経緯は、人もAIも読み書きできる共通の場所に置く、という分け方です。

コンテキストエンジニアリングのよくある失敗例

念のため全部渡す

「足りないよりは多いほうがいい」と、関係しそうな資料をすべて渡すやり方です。上で触れたとおり、AIは読む量が増えるほど大事な情報を拾いにくくなります。古い版の資料が混ざると、AIが古いほうを根拠にすることもあります。

自分で要約してから渡す

親切のつもりで、資料や会議の内容を短くまとめて渡すやり方です。まとめる時点で、数字や例外、相手の言い回しのような細部が落ちます。AIに要約させるなら、原本を渡したうえでAIにまとめさせるほうが、元に戻って確かめられます。

指示ファイルに仕事の経緯まで書き足す

Claude CodeのCLAUDE.mdのような指示ファイルは、作業を始めるたびにAIが読みます。ここに案件ごとの経緯を書き足していくと、ファイルが厚くなり、全部の仕事で毎回それを読ませることになります。しかも経緯はすぐ古くなるので、更新が追いつかなくなります。

チャットの流れを正しい情報として読ませる

チャットには、途中で変わった方針も、却下された案も、時系列で混ざって残っています。AIにチャットの履歴を読ませても、どれが今の結論かは判断できません。決まったことは、結論の形で仕事の置き場に書き移しておきます。

AIが作業した結果を、どこにも戻さない

AIに仕事を進めてもらっても、何を決めて何が分かったかが会話の中にしか残らないと、次にその仕事を頼むときにまた一から説明することになります。AIとの会話は、終われば次の会話に持ち越されません。依頼の最後に「やったことと決めたことを、この仕事の置き場に戻して」と一言入れておくと、次の依頼の文脈が自然にたまります。

Addnessでのコンテキストエンジニアリングのやり方

Addness(アドネス)は、チームとAIが同じ脳を共有する「カンパニーブレイン」です。ゴール・やること・仕事の経緯・成果物を一か所に置き、Claude Code・Codex・CursorなどMCP対応のAIエージェントがその文脈を読んで、相談から実行まで仕事を進めます。上の5つの材料は、Addnessでは次の場所に置きます。

材料Addnessでの置き場
目的ゴールの「理想」。親ゴールをたどれば、上位の目的まで読める
今の状態子ゴールの完了状況、ゴールの「メモ」
経緯「メモ」、ゴールのコメント、AIメモリ
やり方ナレッジ(名前・いつ使う・やり方で1件)
守ることゴールごとの権限、依頼文に書く確認の条件

AIとつなぐには、使っているAIに「Addness MCP(https://vt.api.addness.com/mcp)を設定してください」と送り、ブラウザでログインして許可します。AIごとの手順はAddness MCPのつなぎ方にあります。

依頼文は短く、文脈はAIに読みに行かせる

ゴールの行の「AIに依頼する」から「進める」「壁打ちする」「質問する」を選ぶと、AIに渡す指示文ができます。公開ヘルプによると、この指示文にはゴールのURLと進め方が入っていて、AIはMCPでゴールの文脈(理想・メモ・親と子・コメント・AIメモリ)を読んでから、理想と今の状態の差分を見て次にやることを決めます。

これは上で書いた「ありかを教えて、取りに行かせる」の形そのものです。指示文に経緯を書き込まず、AIが必要な分を読みに行きます。自分で頼むときも、依頼文は次の程度で足ります。

図:Addnessの「AIに依頼する」で渡すと、AIはMCPでゴールの理想・メモ・コメント・AIメモリなどを読み、差分から次にやることを決めて作業し、決めたことはAIメモリに自動で残る。

Addnessの「A社に研修を提案する」を読んで、理想に向けて進めて。
先方に送るものは、送る前に見せて確認して。
終わったら、決めたことと次にやることをこのゴールに戻して。

アドネス株式会社では、部署をまたぐ依頼をこの形で渡しています。複数のサービスに散らばった顧客データを1つの表にまとめ、自動で更新する仕組みを作ったときは、依頼する側が自分のClaude Codeに頼んで要件をAddnessのゴールに残し、作業する側のAIがそのゴールを読んで仕事を進めました。社内では会議と要件の共有を含めて約1日かかると見ていた作業が、依頼から約30秒で実装されています(社内の見積もりとの比較です。「【1日→30秒】顧客データ統合と自動収集システムを30秒で構築した現場事例を公開【Addness使いこなし事例 vol.1】」)。

経緯は、作業のついでにたまる

MCPでつないだAIがゴールで作業すると、何を決めて、何を作って、何が分かったかが、そのゴールの「AIメモリ」に自動で記録されます。内容が違うときは「取り消す」を選んで理由を書けば、記録は消えずに理由つきで残ります。次に同じゴールを別の人が自分のAIに渡しても、そのAIは書き戻された経緯から始められます。

くり返すやり方は、ナレッジにする

うまく進んだ仕事のあとで、つないだAIに「今のやり方をナレッジに残して」と頼むと、AIが名前・いつ使う・やり方をまとめてナレッジを作ります。ゴール詳細の「ナレッジ」の欄で「追加」を押して結びつけておくと、AIはゴールを読むときに、そのナレッジも一緒に読みます。ナレッジの画面の「AI が読んだ」には、どのAIが何回読んだかが出るので、使われていない手順も見つけられます。

見せる範囲は、人と同じにする

つないだAIが行う操作は、操作した本人の権限の範囲に限られ、本人が見られないデータをAIが見ることはありません。お客様のデータがAIモデルの学習に使われることもありません。データの扱いはセキュリティにまとめています。

渡す材料と置き場の考え方は、無料の講座「AIに仕事を任せる」でも、営業・採用・経理の例を使って説明しています。

よくある質問

コンテキストエンジニアリングとは、簡単に言うと何ですか?

AIに何を・いつ・どの形で渡すかを設計することです。指示文に加えて、仕事の目的、今の状態、経緯、資料、使える道具まで含めて、AIが読む情報全体を組み立てます。

プロンプトエンジニアリングは、もう必要ないのですか?

必要です。プロンプトはコンテキストの一部なので、指示文を分かりやすく書く工夫は今も役に立ちます。ただ、答えがずれる原因が言い回しより材料の不足にあることが多いので、先に渡したものを見直すほうが早く直ります。

エンジニアでなくてもできますか?

できます。目的を達成が分かる形で書く、関係する資料を原本のまま見せる、決めたことを置き場に残す、といった部分は、プログラムを書かずに今日から始められます。文書を検索してAIに渡す仕組みを自社で作るような部分は、技術の知識が要ります。

RAGとは何が違いますか?

RAGは、質問に合う文書を探してAIに渡す仕組みで、コンテキストエンジニアリングの中の「渡し方」の1つです。何を探させるか、古い文書をどう扱うか、ほかの材料とどう組み合わせるかを決めるのが、コンテキストエンジニアリングの範囲になります。

コンテキストは多いほど良いのですか?

量を増やすと、かえって答えが悪くなることがあります。読む量が増えると、AIが大事な情報を拾いにくくなります。その仕事に関係するものだけを渡してください。

最初の1つの仕事で試す

まずは、AIに頼むたびに同じ説明を書いている仕事を1つ選び、目的・今の状態・経緯を書き出してみてください。それをAddnessのゴールの「理想」と「メモ」に置き、AIに「このゴールを読んで進めて」と頼むと、依頼文がどれだけ短くなるかを確かめられます。ゴールを置いてAIとつなぐまでの手順ははじめ方に、AIからAddnessを読み書きする仕組みはAIエージェント接続(MCP)の機能紹介にあります。

チームで使い始めたい会社には、無料の導入支援があります。今の仕事の進め方を伺い、最初に置くゴールと、AIに任せる仕事を1つ決めるところまで一緒に進めます。申し込みは導入支援の相談フォームからどうぞ。

※この記事は2026年10月15日時点の情報です。Addnessは日々アップデートしているので、画面や手順が今と少し違うことがあります。

この記事を書いた人

アドネス株式会社 マーケティング 竹内翼

Addnessのマーケティング責任者。150人規模の会社で人事責任者も務めました。