プロンプトの次は「コンテキストエンジニアリング」 AIへの渡し方が成果を分ける

AIを使い始めて少し慣れた頃、誰もが一度はあのモヤモヤに突き当たります。同じ依頼のしかたなのに、毎回違う答えが返ってくる。長い会話の後半で、最初に話した前提がぽろっと抜け落ちる。書き方を工夫してもいまひとつ精度が上がらない。

このモヤモヤに、ようやく業界全体で名前がつきました。コンテキストエンジニアリング(context engineering)です。

Anthropicの公式エンジニアリングブログは、プロンプトエンジニアリングの焦点が「うまい言葉選び」から、「モデルにどの情報を渡すか」というコンテキスト設計へ移っていると説明しています。Claude を作っている当事者自身が、ここまで明確に重心の移動を語っているのは、なかなかの転換です。

この記事では、そもそも「コンテキスト」とは何のことか、なぜ2026年にこの言葉が業界の合言葉になったのか、そして自分の業務で「コンテキスト設計」をどう始めればいいか、を整理します。

そもそも「コンテキスト」って何のこと?

最初に、用語の意味から押さえます。

AI業界で「コンテキスト」と呼ぶときには、大きく2つの意味が重なっています。

1つ目は「AIに渡す情報のまとまり」。指示文、添付ファイル、社内ドキュメント、過去の議事録、参考にしてほしい例。AIに何かを頼むときに、一緒に渡しているもの全部です。

2つ目は「AIが会話の流れの中で短期的に覚えている内容」。会話の前半で「私の会社は中小企業向けのSaaSをやっています」と書いたら、後半で「そのうちの1サービスについて説明文を書いて」と頼んだとき、AIは前半の情報を踏まえて返してくれる。この「いまの会話で覚えていること」もコンテキストです。

技術的には、この2つは同じものに乗っています。AIモデルには「コンテキストウィンドウ」と呼ばれる、一度に処理できる入力範囲があります。指示文も、添付ファイルも、これまでの会話履歴も、ツールの実行結果も、全部このウィンドウの中に並べて入れて、AIはそれを読んで返事を作る。「渡す情報」も「いま覚えている内容」も、このウィンドウの中身として一緒に扱われています。

雑にひとことで言えば、仕事を頼むときの「資料・前提・経緯・締切・お手本」をぜんぶまとめて渡す、その一式がコンテキストです。よくできる同僚でも、これが揃っていなければ良い仕事は返ってこない。AIも同じです。

「コンテキストエンジニアリング」とは何か Karpathy の提唱から標準語へ

「コンテキストエンジニアリング」という言葉を世に押し出したのは、AI研究者の Andrej Karpathy 氏です。元Tesla AIディレクター、元OpenAI創業エンジニアという経歴で、業界の中でも一目置かれる人物です。(前回バイブコーディングの記事でも、彼の発言を起点にしました)

2025年6月、Karpathy氏はX上でこう投稿しました。意訳すると、こうなります。

「コンテキストエンジニアリング」を「プロンプトエンジニアリング」より推したい。人々は「プロンプト」を、日常的にAIに渡す短いタスク記述と結びつけがちだ。だが、本格的なAIアプリでは、コンテキストエンジニアリングこそが、コンテキストウィンドウを次の一手のために適切な情報で埋める、繊細な技術と科学だ。

これまで業界では「プロンプトエンジニアリング」(うまい指示文の書き方)という言葉が広く使われてきました。Karpathy氏の主張は、その言葉では収まりきらない領域が大きくなった、ということです。短い指示を工夫するレベルではなく、「システム指示・取得した文書・会話履歴・ツールの出力・メモリ・例示などをどう組み合わせてAIに渡すか」という、もっと広い設計の問題に移ってきた。

そして、この投稿から1年経った2026年、「コンテキストエンジニアリング」は業界の合言葉として定着しました。Anthropic公式が同名のエンジニアリング記事を出し、OpenAIやGoogleの公式ドキュメントでも、エージェントに渡す情報、ツール、メモリ、長文コンテキストの設計を重視する話が増えています。

Anthropicが整理する 「言葉選び」から「どの情報を渡すか」へ

Anthropicの公式記事は、コンテキストエンジニアリングを「LLMが応答を組み立てるとき、その場に揃える情報の最適な集合を管理する戦略」として整理しています。ここでの「情報」には、システム指示、ツール、MCP(Model Context Protocol)、外部データ、メッセージ履歴などが含まれ、AIから見えている状態(context state)全体が対象です。

注目すべきは、Anthropicがこの記事で、コンテキストを critical but finite resource(重要だが有限な資源)と呼んでいる点です。コンテキストウィンドウには上限があるので、無制限に詰め込めばいいわけではない。何を入れ、何を入れないか、いつ取り出して見せるか、という設計こそが応答品質を決める、という考え方です。

同記事はまた、プロンプトの言葉選びよりも、どのコンテキスト構成が望ましい挙動を引き出すかのほうが、業務応用では重要になっていると明言しています。各組織には固有の業務フロー、用語、判断基準、暗黙のルールがある。AIモデルはそれらを最初から知りません。「もっと賢いモデルを待つ」より、「いまのモデルに、自社の文脈をちゃんと渡す」設計を進めるほうが、現場で効きやすい、という整理です。

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

コンテキストは1つの大きな箱ですが、中身を分解すると、おおむね次の5つで整理できます。

要素	中身
① 指示	役割設定(「あなたはマーケティング担当です」)、トーン、出力形式
② 資料	社内ドキュメント、契約書、議事録、添付ファイル、参考リンク
③ 履歴	過去のやりとり、長期記憶機能(ChatGPT Memory、Claude Memory)、ユーザープロフィール
④ ツール実行結果	検索結果、コード実行の戻り値、API呼び出しのレスポンス、社内DBからの抽出
⑤ 例示	「こういう形で書いてほしい」のサンプル(few-shot examples)

業務で「AIうまく使えないね」が起きているとき、たいていこの5つのどれか、あるいは複数が欠けているのが原因です。「うまく書けるプロンプトのテンプレを探す」より、「自分は5つのうちどれを渡し損ねているか」を点検するほうが、ずっと早く改善します。

現場で「コンテキスト設計」をどう始めるか

「コンテキストエンジニアリング」と言うと、いかにも大がかりに聞こえます。実際は、もっと小さく始められます。3段階で。

最初の1歩: いつも書いている指示を、テンプレ化する

毎回同じような頼みかたをしているなら、それは「いつも渡している指示」です。コピペできる形でテンプレ化しておく。これだけで、出力のブレが減ります。社内で同じ業務をする人と共有すれば、属人化も減らせます。

2歩目: 会社情報をひとつのドキュメントにまとめて、毎回渡す

「うちの会社は何をやっているか」「主な顧客は誰か」「使ってはいけない表現は何か」。これらを A4 一枚程度のドキュメントにまとめて、ChatGPTのカスタムインストラクション、ClaudeのProjects、GeminiのGemsのような仕組みに保存しておく。以後、その箱の中で会話を始めれば、AIは毎回同じ前提を踏まえて返してくれます。

3歩目: 「業務テンプレ+会社情報+例示」をひとつのプロジェクトとして資産化する

業務ごとに、テンプレ・会社情報・お手本サンプルをひとまとめにして保存します。Claude のProjects、ChatGPTのCustom GPTs、GeminiのGems、またはClaude Skillsなど、各社にそのための入れ物があります。「議事録要約用」「お客様向けメール下書き用」「契約書チェック用」のように、業務単位で1つの箱を持つ。これを社内に共有すれば、コンテキストは「使い捨て」ではなく「資産」として育っていきます。

ここまで来ると、AIに渡す情報が会社の中で標準化され、新しいメンバーも同じ前提でAIを使えるようになります。

「入れすぎ」にも落とし穴がある

ここまで「コンテキストを足す」話を続けてきましたが、コンテキストには逆方向の落とし穴もあります。

Anthropic公式が挙げているのは、Compaction(コンパクション、要約による圧縮)と Just-in-Time Context(必要なときに動的に取り込む)という考え方です。会話が長くなりすぎたら適切に要約してリセットする、最初に全資料を渡さず、必要になった段階でツールから取り込む、というやり方です。

中小企業の現場では、まずは「足りない」を解消するところから始めるので、ここまで意識する必要はありません。ただ、慣れてくると、「全部入れすぎてかえって精度が落ちた」「コストが思ったより跳ねた」といった現象に当たります。そのときには、「ちょうど良い量を、ちょうど良いタイミングで」という発想で、コンテキストを引いていく工程に入ります。

足し算で始めて、慣れたら引き算もする。それがコンテキストエンジニアリングの全体像です。

さいごに 「うまく頼む」より「ちゃんと渡す」

AIがうまく動かないとき、多くの人はまず「プロンプトの書き方が悪いのかな」と考えます。SNSに溢れている「最強プロンプト集」を探したり、テンプレを真似してみたり。それも無駄ではありませんが、本当に効く改善は、もっと別のところにあります。

賢いAIに、ちゃんと仕事を渡せていないだけ。

短い指示文だけをきれいに整えるよりも、業務の前提・資料・お手本・履歴を、AIに伝わる形で渡せているか。会話の中で「いま何を覚えていてほしいか」「何は忘れていいか」を意識できているか。コンテキストエンジニアリングというのは、突き詰めれば「AIに対する仕事の頼み方」を、もう一段丁寧にする話です。

「うまく頼む」より「ちゃんと渡す」。これからAIを業務に深く入れていく現場では、ここを意識するかどうかで、AIから返ってくる仕事の質が大きく変わってきます。