コンテキストエンジニアリングとは｜プロンプトとの違いと出力を安定させる設計

プロンプトを何度も書き直したのに、AIの出力が安定しない。指示したはずのルールが3回に1回は無視される。参考にしてほしい資料を全部貼り付けたら、かえって的を外した答えが返ってきた。生成AIを業務に入れた組織から、こうしたご相談をいただく機会が増えました。

原因の多くは、指示の文言にはありません。AIが答えを作る瞬間に、何が目の前に置かれているか。ここを誰も設計していないことが、出力のばらつきを生んでいます。この設計作業を指す言葉が、コンテキストエンジニアリングです。

本記事では、コンテキストエンジニアリングの定義とプロンプトエンジニアリングとの違いを整理したうえで、コンテキストを構成する要素、設計に使う4つの操作、そして記事制作の現場で実際に組んでいる形までを順にお伝えします。開発者向けの実装手順ではなく、AIに仕事を任せる立場の人が今日動かせる範囲に絞って説明します。

コンテキストエンジニアリングとは、AIが答えを作る時点の情報を設計すること

コンテキストエンジニアリングとは、AIが回答を生成する時点で参照している情報の中身と量、並び順を設計し、状況に応じて組み替える取り組みを指します。ここでいうコンテキストは、日本語の「文脈」よりも範囲が広く、モデルへの入力に含まれるすべてを指す言葉として使われます。

この言葉が広く使われ始めたのは2025年の半ばからです。Shopifyのトビー・リュトケ氏が言及し、AI研究者のアンドレイ・カルパシー氏が同調したことで、開発者のあいだに一気に広まりました。ただし作業の中身そのものは、AIを業務に組み込んだ人が経験的にやってきたことでもあります。名前が付いたことで、属人的だった工程を人に引き継げるようになった、という理解が近いはずです。

プロンプトエンジニアリングとの違いは、扱う範囲

両者はしばしば対立する概念として説明されますが、実際には包含関係にあります。プロンプトエンジニアリングは1回の指示文をどう書くかの技術で、コンテキストエンジニアリングはその指示文を含む入力全体をどう組み立てるかの設計です。指示文の書き方は、後者に含まれる一部と考えてください。

区別が実務で効いてくるのは、不具合の切り分けをするときです。出てきた文章の語調が違う、箇条書きにしてほしいのに段落で返ってくる。この種のずれは指示文の書き方で直ります。一方で、社内の前提を知らないまま一般論を返してくる、途中まで守っていたルールを後半で無視する。こちらは指示文をいくら磨いても直りません。渡している情報の側に原因があるためです。

AIエージェントの登場で設計が避けられなくなった

2024年までの使い方は、人が1回質問して1回答えをもらう形が中心でした。この形であれば、指示文を書き直しながら試すやり方で足ります。

状況が変わったのは、AIが複数の手順を自分で回すようになってからです。検索し、結果を読み、次の手を決め、ファイルを書き換える。1回の依頼で何十回もモデルを呼ぶ動き方になると、途中で得た情報が次の呼び出しの入力に積み上がっていきます。人が指示文を書けるのは最初の1回だけで、2回目以降に何が入力されるかは仕組みの側が決めることになる。ここで設計が要るようになりました。

社内でAIを使う場面に置き換えると、チャット画面で1問1答しているうちは設計の必要を感じにくく、議事録の要約から報告書の下書きまでを一続きで任せようとした瞬間に破綻が始まる、という順番で表れます。

関連記事：生成AIのビジネス活用完全ガイド｜企業の活用事例と導入ポイントを徹底解説

プロンプトを書き直しても出力が安定しない理由

不具合の中身を分けて見ていきます。指示が届いていないわけではないのに従われない現象には、いくつか別の原因が混ざっています。

情報を増やすほど、指示の存在感が薄まる

ルールを守らせたいときに、注意書きを足していく対処はよく取られます。ところが項目が20を超えたあたりから、守られる割合が下がり始めます。追加した本人としては指示を強めたつもりでも、モデルの側から見れば、判断に使う材料の中で1項目あたりの比重が下がっただけ。禁止事項を5つ書いたときと30個書いたときで、1つあたりの扱われ方は変わります。

対処は、注意書きを増やす方向ではなく減らす方向にあります。守らせたい項目を並べたら、そのうち何が結果に効いているかを確認し、効いていないものを外す。注意書きは足すより、削るほうが守られます。感覚に反する動きですが、実際に禁止語のリストを絞ったほうが遵守率が上がる場面は珍しくありません。

長く渡すほど精度が落ちる現象

もう1つの原因は、入力が長くなること自体にあります。参照してほしい資料を全部貼れば精度が上がるはずだ、という前提は成り立ちません。

長い入力の中で情報がどう使われるかを調べた研究では、関連する情報が入力の先頭か末尾にあるときに最も正しく使われ、中間に置かれたときは利用率が下がることが報告されています。読み落としに近い挙動、と言い換えてもよいでしょう。近年は入力の総量が増えるほどタスクの正確さが下がる傾向も観測されており、この現象はContext Rotと呼ばれています。

※ 出典：Nelson F. Liu ほか「Lost in the Middle: How Language Models Use Long Contexts」（Transactions of the Association for Computational Linguistics, 2024）

Lost in the Middle: How Language Models Use Long Contexts

While recent language models have the ability to take long contexts as input, relatively little is known about how well they use longer context. We analyze the performance of language models on two tasks that require identifying relevant information in their input contexts: multi-document question answering and key-value retrieval. We find that performance can degrade significantly when changing the position of relevant information, indicating that current language models do not robustly make use of information in long input contexts. In particular, we observe that performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models. Our analysis provides a better understanding of how language models use their input context and provides new evaluation protocols for future long-context language models.

🌐 arxiv.org

外部リンク

実務上の意味は単純です。コンテキストウィンドウ、つまりモデルが一度に扱えるトークンの上限は年々広がっていますが、上限まで詰めれば性能が出るわけではありません。入る量と、使いこなせる量は別。設計では、上限のうちどこまで使うかを自分で決める必要があります。

経営者

社内マニュアルを全部読ませたほうが正確に答えると思って、PDFをまとめて渡しています。それが逆効果になっているということでしょうか。

Writers-hub
編集部

質問ごとに必要な範囲が違うので、全部渡すと関係のない記述が判断を邪魔します。まず「この質問に答えるにはどのページが要るか」を切り出す工程を挟んでください。全文検索でも、章ごとにファイルを分けて選ばせるだけでも構いません。渡す量が減ると、答えの精度は上がることが多いところです。

途中でルールが失われる

会話が長くなると、序盤に決めた前提が後半で無視される現象も起きます。原因は主に2つあり、1つは入力の上限に収まらなくなって古い部分が切り落とされること、もう1つは要約されて詳細が消えることです。

いずれの場合も、会話の中だけで前提を保つ設計に無理があります。守らせたい決めごとは会話の履歴に置かず、毎回読み込まれる場所へ移す。この切り替えが、次の章で扱う構成要素の話につながります。

関連記事：AIプロンプトとは？出力が変わる書き方の型と業務別の例文

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

設計に入る前に、何が入力に含まれているのかを分解しておきます。整理の仕方には流派がありますが、業務での組み立てには次の6つで足りるはずです。

この表で確認したいのは、6つのうち5つは、指示文の外側にあるという点です。プロンプトの書き方に関する情報が世の中に多いのは事実ですが、実際に出力を決めている要素の大半は、指示文を書く欄の外に置かれています。

置く順番が結果を変える

要素をそろえたら、次は並び順です。前章で触れた研究のとおり、入力の先頭と末尾は中間より確実に読まれます。したがって、絶対に守らせたい制約は先頭に置き、今回の依頼と最終的な指示は末尾に置く。参考資料は中間に配置する、という配分が基本形になります。

長い資料を先頭に貼り、末尾に「上記を参考に書いてください」とだけ添える形は、順番の点で不利です。資料を挟んだあと、末尾でもう一度、守るべき条件を短く繰り返す。この一手間で守られる割合が変わります。

トークンの枠を先に決める

もう1つ実務で効くのが、上限の何割を何に使うかを先に決めておく考え方です。常設の指示にどれくらい、参考資料にどれくらい、履歴にどれくらいと枠を切る。枠を超えたら、資料を選び直すか要約するかの判断が発生します。

枠を決めずに運用すると、資料が増えた月に静かに精度が落ち、原因が分からないまま指示文を書き直す作業に戻ることになります。上限に達するまで気づけない設計を避ける、という予防の意味合いが大きいところです。

関連記事：プロンプトとは？生成AIへの指示文の書き方とビジネス例文を解説

コンテキストを設計する4つの操作

具体的な打ち手は、書き出す、選ぶ、圧縮する、分けるの4つに整理できます。AIエージェントの設計で使われている分類ですが、社内での使い方にもそのまま当てはまります。

書き出す：覚えさせずに、外へ保存する

会話の中で覚えていてもらう発想を捨て、外部に書き出す操作です。決めた前提、途中の作業メモ、繰り返し使うルールをファイルへ保存し、必要なときに読み込ませる。

開発の現場では、リポジトリの直下にルールを書いたファイルを置き、AIが作業開始時に必ず読む運用が定着してきました。非エンジニアの業務であれば、共有ドライブに1枚のルール文書を作り、依頼のたびに先頭へ貼り付ける形で同じことができます。手作業に見えますが、記憶に頼らない状態を作れる点が重要です。

選ぶ：全部渡さず、必要な分だけ取り出す

保存した情報のうち、今回の依頼に関係する分だけを取り出す操作です。RAGと呼ばれる仕組みは、この選ぶ工程を検索で自動化したものにあたります。

ただし選ぶ精度は検索の設計に左右されるため、最初から仕組みを作る必要はありません。資料を用途ごとにファイル分割し、依頼内容に応じて人が選んで渡す。この手動運用でも、全部渡す状態より結果はよくなります。仕組みへの投資は、手動で効果を確認したあとで判断すれば足ります。

圧縮する：情報量を落とさずに短くする

長くなった履歴や資料を要約して短くする操作です。注意点は、要約で何が失われるかを決めておくこと。数値、固有名詞、判断の条件は残し、経緯の説明は落とす、といった優先順位を決めておかないと、後の工程で必要な情報が消えます。

分ける：1つのやり取りに詰め込まない

最後は、役割ごとに別のやり取りへ分ける操作です。調査、執筆、検査を1つの会話で続けると、履歴が膨らみ、前の工程で出た仮説が後の工程の判断を引っ張ります。工程ごとに新しいやり取りを立て、必要な情報だけを引き継ぐ形にしてください。1回あたりの入力を短く保てます。

4つのうち、社内で最も効果が出やすいのは書き出すと分けるです。選ぶと圧縮するは仕組みの整備を伴いますが、前の2つは運用の決めごとだけで始められます。

記事制作の現場で使っているコンテキストの組み方

ここからは、弊社がSEO記事の制作にAIを使うときに実際に組んでいる構成をお伝えします。文章を扱う業務であれば、そのまま応用が利くはずです。

常設のルールと、案件ごとの情報を別々に管理する

最初に分けているのは、どの記事にも共通するルールと、その案件だけの情報です。共通ルールに書くのは文体、禁止する表現、見出しの付け方、装飾の使い方。案件ごとの情報には、クライアントの事業内容、狙うキーワード、競合ページの調査結果、社内から出た一次情報が入ります。

分けておく理由は更新の頻度が違うことにあります。共通ルールは検品で問題が見つかったときに更新し、案件情報は記事ごとに差し替える。混ぜて1つの指示文にすると、案件が変わるたびに共通ルールを書き写す作業が発生し、写し間違いが混入します。

生成と評価は、別のやり取りで行う

もう1つ徹底しているのが、書かせた文章の検品を同じ会話で行わないことです。書いた本人に採点させる形になるため、自分の出力を通す判断に寄ります。

工程を分ける運用は、前章の分ける操作をそのまま業務に当てたものです。実際に弊社では、観点を変えた検査を複数回まわす形にしており、回を重ねるごとに別の種類の指摘が出てきます。1回で全部を見つけようとしないほうが、結果として抜けは減るでしょう。

一次情報を渡さない限り、一般論しか返らない

AIが出力できるのは、学習した公開情報の再構成です。上位ページに書かれている範囲を組み替えることはできますが、社内にしかない情報は原理的に出てきません。

そのため、渡すコンテキストに何を入れるかが記事の中身を決めます。実際に効くのは、営業がよく聞かれる質問と回答、見積で価格が動く条件、断ることになる依頼の種類、過去案件でつまずいた工程といった記録です。この種の材料を先に文字にしてから渡してください。下書きの段階で、他社が書けない内容が入ってきます。

• 共通ルールと案件ごとの情報が、別のファイルに分かれている
• 守らせたい条件が、依頼文の末尾でもう一度短く示されている
• 検品を、執筆したやり取りとは別の場所で行っている
• 渡した資料に、社内でしか確認できない情報が含まれている
• 会話の履歴に頼って前提を保つ運用になっていない

上の2つが埋まっていない状態でプロンプトを調整しても、出力のばらつきは残ります。着手の順番としては、ファイルを分けることと、末尾で条件を繰り返すことが先にきます。

隣接する手法との使い分けと、着手する順番

コンテキストエンジニアリングは、RAGやファインチューニングと並ぶ選択肢ではありません。それらを何のためにどう組み合わせるかを決める側の設計にあたります。そのうえで、設計の中で選ぶ手段を比べておきます。

左の2列から着手するのが基本です。費用も準備期間も要らず、効果の有無がその日に分かります。RAGとファインチューニングは、手作業で効果を確認したうえで、量が増えて手が回らなくなったときに検討する順番が合理的でしょう。

なおMCPは、外部のデータやツールをAIに接続するための規格で、選ぶ工程の配線を標準化する役割を担います。手段の選択肢というより、接続の共通仕様として位置づけるほうが実態に近いところです。

What is the Model Context Protocol (MCP)? - Model Context Protocol

🌐 modelcontextprotocol.io

外部リンク

非エンジニアが最初に進める手順

エンジニアの関与なしで進められる範囲を、順番に並べます。どれも既存の道具の使い方を変えるだけで、新しい仕組みの導入は含みません。

5つ目まで到達すると、指示文を書き直す作業が減り、ルールを書いたファイルを育てる作業に置き換わります。運用の中心が移ること自体が、コンテキストエンジニアリングを導入した状態だといえます。

コンテキストエンジニアリングについてよくある質問

社内で進め方を検討する場でいただく質問を、4つに絞ってまとめます。判断が分かれやすいのは、着手の順番と、モデルの性能に任せられる範囲の見立てです。

まとめ

コンテキストエンジニアリングは、AIが答えを作る時点で参照している情報の中身と量、並び順を設計する取り組みです。プロンプトエンジニアリングと対立する概念ではなく、指示文の書き方を含む一段外側の設計にあたります。

出力が安定しないとき、原因は指示の文言より渡している情報の側にあることが多いところです。注意書きを増やすほど1項目あたりの比重は下がり、資料を全部渡すほど中間の情報は読み落とされる。打ち手は、書き出す、選ぶ、圧縮する、分けるの4つに整理でき、社内で先に効果が出るのは外部に書き出すことと工程を分けることです。

合同会社Writers-hubでは、SEO記事の制作と社内AI活用の立ち上げ支援を行っています。どの業務から任せるか、渡す情報をどう整えるか、公開前の検品をどう組むか。この3つを決める段階から関われますので、社内での使い方に迷いがある場合はお声がけください。