コンテキストエンジニアリングとは――AI活用が定着しない理由

「社員にプロンプトの書き方を教えたのに、AI活用が思ったほど進まない」。AI研修を実施した企業から、こうした声を聞くことが増えています。

この課題を考えるうえで重要な概念が「コンテキストエンジニアリング（Context Engineering）」です。もともとはAnthropic（AIモデル「Claude」の開発企業）が2025年9月に公開した技術記事で提唱された、AI開発者向けの考え方ですが、その本質は非エンジニアの企業実務にも直結します。

先に結論を言うと、AI活用の成果を分けるのは「指示文の巧拙」よりも「AIにどんな情報を渡せる状態を作っているか」であり、これは個人のスキル研修だけでは解決できない、組織側の設計問題です。 判定・紹介プラットフォームとしての中立の立場から、この考え方を非エンジニア向けに翻訳し、自社のAI活用に何が足りないのかを見極める視点を整理します。

研修が要る段階か、情報整備が先か。自社の現在地を30秒で判定する →

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

「渡す情報の全体」を設計する技術

コンテキストエンジニアリングとは、AIが回答を生成する際に参照する情報（コンテキスト）全体を、目的に合わせて選択・整理・管理する技術のことです。

AIに何かを依頼するとき、AIが見ているのは「指示文」だけではありません。添付した資料、過去のやり取り、参照させたデータ、あらかじめ設定されたルール——これらすべてが「コンテキスト」であり、回答の質を左右します。指示文はその一部にすぎません。

Anthropicはこの技術を、AIの限られた処理能力の中に「どの情報を、どの順序で、どれだけ入れるか」を設計する営みだと説明しています。設計対象が「文章」から「情報の集合」に広がった、と理解するとつかみやすくなります。

情報は多いほどよい、ではない

ポイントは、情報は多ければ多いほどよいわけではない、という点です。人間が大量の資料を一度に渡されると要点を見失うのと同じように、AIも無関係な情報が増えるほど、重要な情報を正確に扱う能力が落ちることが知られています。この現象は「コンテキストロット（context rot）」と呼ばれます。

Anthropicの記事では、この劣化がAIの構造そのものに由来すると説明されています。読み込む情報が増えるほど、AIが同時に見比べなければならない情報の組み合わせが急速に増え、注意が薄く広がってしまう、という理屈です。技術的な詳細を理解する必要はありませんが、「詰め込めば詰め込むほど賢くなる」わけではないという点は、実務判断に直結します。

したがってコンテキストエンジニアリングの核心は、「必要十分な情報だけを、最適な形でAIに渡す」ことにあります。

「長く読める」ことと「正確に扱える」ことは別

この点は実務上の誤解を正すうえで重要です。近年のAIモデルは一度に読み込める情報量が飛躍的に増えており、「とにかく全部の資料を放り込めばよい」という使い方が広がっています。

しかし読み込める量が増えることと、その中から的確に情報を扱えることは別問題です。社内の全マニュアルを無選別に渡すより、その業務に関係する資料だけを選んで渡すほうが、出力の質は安定します。量の拡大は「雑に渡してよい」免罪符ではなく、「選び方の巧拙」の差がむしろ広がった、と理解するのが正確です。

プロンプトエンジニアリングと何が違うのか

レシピの書き方と、キッチンの設計

プロンプトエンジニアリングは「指示文の書き方」を最適化する技術です。役割を与える、出力形式を指定する、手順を分解する——こうしたテクニックは今も有効ですし、AI活用の基礎スキルであることに変わりはありません。

一方、コンテキストエンジニアリングは「指示文の外側」まで含めた設計です。両者の関係を料理にたとえると、プロンプトエンジニアリングが「レシピの書き方」だとすれば、コンテキストエンジニアリングは「キッチン全体の設計」——どの食材を冷蔵庫に置き、どの道具を手の届く場所に配置するか——にあたります。レシピがどれだけ上手に書けても、食材が揃っていなければ料理は完成しません。

否定ではなく「自然な進化形」

Anthropic自身も、コンテキストエンジニアリングをプロンプトエンジニアリングの否定ではなく「自然な進化形」と位置づけています。指示文の最適化だけで成果が頭打ちになったとき、次に見直すべきは指示文の外側にある情報環境だ、ということです。

したがって「プロンプト研修は無駄だった」という結論にはなりません。基礎として必要だが、それだけでは組織の成果に届かない——順序の問題として捉えてください。

なぜ企業のAI活用に関係するのか

社員が渡せるコンテキスト＝会社が整備した情報資産

ここからが本題です。開発者向けの概念であるコンテキストエンジニアリングを「会社でAIを使う」場面に翻訳すると、次のようになります。

社員がAIに渡せる「コンテキスト」とは、会社が整備した情報資産のことです。 個人が毎回ゼロから説明して補うか、会社が用意したものを使うか。この差がそのまま出力の差になります。

企業の「コンテキスト」を構成する4種類の情報

たとえば「議事録を要約して」という同じ指示でも、自社の議事録フォーマット、決定事項の記載ルール、関係者の役職情報がコンテキストとして渡せる状態にある会社と、社員が毎回ゼロから説明する会社とでは、出力の質も再現性もまったく違います。前者は組織としてコンテキストを設計できている状態、後者は個人の工夫に依存している状態です。

具体例：同じ指示でも成果が分かれる理由

抽象的な話が続いたので、具体的な場面で考えてみます。人事部門で「中途採用の求人票のドラフトをAIに作らせる」ケースです。

コンテキストが整っていない会社

担当者はこう指示します。「営業職の求人票を書いて」。AIは一般論としては整った求人票を返しますが、自社の給与レンジも、実際の業務内容も、過去にどんな表現で応募が集まったかも知らないため、出力はそのままでは使えません。担当者は結局大幅に書き直すことになり、「AIは使えない」という結論に至ります。

コンテキストが整っている会社

同じ担当者が、あらかじめ用意されたテンプレートを使います。そこには自社の求人票フォーマット、募集ポジションの業務定義書、過去に応募率が高かった求人票のサンプル、表現上のNGルール（誇大表現の禁止など）が参照資料としてセットされています。

AIへの指示文自体は「この資料をもとに求人票のドラフトを作成して」という素朴なもので構いません。出力は最初から自社の文脈に沿っており、担当者の作業は最終確認と微調整だけです。

差はプロンプトスキルではない

両者の差は、担当者のプロンプトスキルではありません。組織として「AIに渡す情報一式」を設計してあるかどうかの差です。そしてこの設計は、研修で個人に教えるものではなく、会社が業務として整備するものです。

見落とされがちですが、右側の状態には副次的な効果もあります。整備した資料はAIに渡す以外の場面でも使える——新人教育、引き継ぎ、業務の標準化。AI活用のための整備が、そのまま業務品質の底上げになる領域です。

「プロンプト研修だけ」で止まる会社の典型パターン

AI研修を実施したのに活用が定着しない企業には、共通するパターンがあります。

パターン1：研修直後だけ使われて、3ヶ月後には元に戻る

研修で学んだテクニックを試すものの、業務で使うには毎回、背景情報を長々と入力する必要があり、「自分でやったほうが早い」に戻ってしまうケースです。原因はスキル不足ではなく、業務に必要なコンテキストが整備されていないことにあります。

見分け方は簡単で、「使わなくなった理由」を本人に聞くことです。「やり方を忘れた」ならスキルの問題ですが、「毎回説明するのが面倒」なら情報環境の問題です。後者が多いなら、追加研修を打っても同じ結果になります（定着が崩れる構造は生成AIが社内で使われない――定着しない5つの原因と対処で詳しく扱っています）。

パターン2：一部の「AIが得意な人」だけが使いこなし、組織に広がらない

得意な人は自分なりに情報の渡し方を工夫していますが、その工夫が個人のノートに留まり、組織の資産になっていません。属人化したコンテキスト設計は、その人の異動や退職とともに失われます。

この状態は一見うまくいっているように見えるため、対処が遅れがちです。社内の上手い人が何を渡しているかを取材して共有資産にするのが、最も投資対効果の高い一手になることがあります。

パターン3：ツールを最新版に更新し続けているのに、成果が変わらない

AIモデルは数ヶ月単位で進化しており、性能の上限は上がり続けています。しかし、渡す情報が整っていなければ、どれだけ高性能なモデルでも「自社の文脈を知らない優秀な新人」のままです。

成果が出ない原因をツール側に求めて乗り換えを繰り返すのは、キッチンが散らかったままレシピ本だけ買い替えているようなものです。

これら3つに共通するのは、個人スキルの問題として扱われているが、実際は組織の情報設計の問題であるという構図です。

研修・情報整備・外部支援。自社にいま必要なものを30秒で判定する →

Anthropicが挙げるテクニックを「組織運営」に翻訳すると？

Anthropicの技術記事では、長時間動き続けるAIエージェントのために、大きく3つのテクニックが紹介されています。開発者向けの内容ですが、それぞれ組織のAI活用にきれいに対応するので、翻訳して紹介します。

1つ目「要約による圧縮」→ 渡し方の設計

会話や作業の履歴が長くなりすぎたら、要点だけを残して圧縮し、身軽な状態で作業を続けるという考え方です。

組織に翻訳すると、「すべての情報をAIに渡そうとしない」ことにあたります。10年分の議事録を全部読ませるのではなく、決定事項だけを抜き出した資料を整備しておく。マニュアル全文ではなく、AIに参照させる用の要約版を作っておく。情報の「渡し方」を設計する発想です。

実務的には、「AIに読ませる用の縮約版」を業務ごとに1本作るだけでも効果が出ます。原本を作り直す必要はありません。

2つ目「外部への書き出し」→ ナレッジの外部化

AIの作業メモや長期的な情報を、AIの頭の中（コンテキスト）に抱え込ませるのではなく、外部のファイルに書き出して、必要なときだけ読みに行かせるという考え方です。

組織に翻訳すると、これは「ナレッジの外部化」そのものです。ベテラン社員の頭の中や個人のメモにある判断基準を、AIが読める形式の文書に書き出しておくことで、誰がAIを使っても同じ品質の参照が可能になります。属人化の解消とAI活用が、実は同じ作業だということです。

この重なりは、社内の合意形成でも使えます。「AIのための整備」だと反発が出る現場でも、「引き継ぎ資料の整備」なら通る、という場面は少なくありません。

3つ目「役割分担」→ 工程の分割

1つのAIにすべてを任せるのではなく、調査担当・執筆担当・確認担当のように複数のAIに役割を分けて協働させるという考え方です。

組織に翻訳すると、「1回の依頼にすべてを詰め込まない」業務設計にあたります。情報収集・ドラフト作成・チェックを別の工程として設計し、それぞれに適した参照資料と確認ポイントを用意するほうが、品質は安定します。人間のチーム運営と同じ原理が、AIの使い方にも当てはまるわけです。

こうして見ると、コンテキストエンジニアリングの発想は、実は目新しいものではありません。「必要な情報を、必要な人に、使える形で渡す」という、組織運営の基本そのものです。AI活用がうまい会社とは、情報の整理と受け渡しがうまい会社だ、と言い換えることもできます。

自社に必要なのは研修か、情報整備か、外部支援か？

では、コンテキストエンジニアリングの考え方を踏まえて、企業は何から手を付けるべきでしょうか。答えは自社の現在地によって変わります。

段階別に見た「次の一手」

真ん中の段階にいる企業が、追加のプロンプト研修を発注してしまうケースが最も多く見られます。研修は「使い方を知らない」状態には効きますが、「使いたいが渡す材料がない」状態には効きません。

「売りたいもの」で答えが決まる問題

明日からできる「コンテキストの棚卸し」4ステップ

大がかりな投資を決める前に、自社の現状を確かめる方法として、小さく始められる棚卸しの手順を紹介します。所要は1業務あたり半日程度です。

ステップ1：対象業務を1つ選ぶ

毎週・毎月発生する定型業務のうち、「時間はかかるが判断は単純」なものを1つ選びます。議事録の整理、定型文書の作成、資料の要点抽出などが典型です。

逆に、最初から難易度の高い業務（経営判断を含むもの、例外処理が多いもの）を選ばないでください。棚卸しの目的は成果を出すことではなく、自社に何が足りないかを見つけることです。対象業務の絞り込み方は生成AIのユースケースの見つけ方――業務棚卸しから3つに絞るもあわせて参考にしてください。

ステップ2：その業務に必要な情報をリストアップする

その業務を新人に引き継ぐとしたら何を渡すかを考えます。フォーマット、過去の完成品サンプル、判断基準、注意事項——これがその業務の「コンテキスト」の正体です。

ここで手が止まる場合、それ自体が発見です。引き継げないものはAIにも渡せません。

ステップ3：リストアップした情報が「AIに渡せる形」になっているか点検する

文書として存在するか、それとも担当者の頭の中にしかないか。文書があっても、画像だらけのPDFや口伝の補足が前提になっていないか。ここで「渡せる形になっていない」情報の多さが、自社の伸びしろです。

ステップ4：渡せる形に整えて、依頼文とセットでテンプレート化する

整備した資料と依頼文をセットにして、部署の誰でも使える場所に置きます。個人のPC内やチャットの履歴ではなく、後任者が探せる場所に置くことが条件です。

1業務でこのサイクルを回してみると、自社に足りないのがスキルなのか、情報整備なのか、推進の体制なのかが、かなり具体的に見えてきます。

発注前にベンダーへ確認したい3つの質問

外部に依頼する場合、次の3点を質問の形で確認してください。回答の具体性がそのまま対応力を表します。

質問1：自社の業務資料を使った演習になりますか。

「演習の題材は、当社が提供する実際の業務資料に差し替えられますか。差し替えの範囲と、そのための事前ヒアリングの工数を教えてください」

汎用テキストしか持たないベンダーでは、業務への落とし込みが受講者任せになります。

質問2：研修後に何が残りますか。

「研修が終わった時点で、当社の手元に残る成果物は何ですか。受講者が持ち帰る指示文や参照資料のセットは含まれますか」

残るのが「資料と満足度アンケート」だけなら、コンテキストは1ミリも整備されていません。

質問3：情報整備が先だと判断される可能性はありますか。

「ヒアリングの結果、当社は研修より先に情報整備が必要だと判断される可能性はありますか。その場合、御社はどう対応しますか」

この問いに「あります」と答え、その場合の代替案を提示できるベンダーは、自社を診る姿勢があると考えてよいでしょう。「いえ、研修は必ず効きます」という回答は、商材の説明です。

よくある誤解

「とりあえずAIに全部読ませればいい」

前述の通り、無関係な情報が増えるほど重要な情報の扱いは不安定になります。全部渡すことは、設計を放棄することと同じです。渡す前に選ぶ、という一手間が品質を決めます。

「情報整備は情シスの仕事」

整備すべき中身を持っているのは業務部門です。情シスが担うのは保管場所・アクセス権・入力してよい情報の線引きといった土台であり、判断基準や過去の成果物を言語化できるのは現場だけです。情シスに丸投げすると、器だけができて中身が入りません。

「まず全社ルールを完成させてから」

入力してよい情報の線引きなど、リスクに関わる最低限のルールは先に必要です。しかし完璧な全社ルールの完成を待つと、たいてい着手が半年遅れます。ルールは全社で薄く、整備は1部署1業務から厚く、という順序で進めてください。

まとめ：問うべきは「良いプロンプト」ではなく「良い情報環境」

コンテキストエンジニアリングという概念が教えてくれるのは、AI活用の成否を分けるのは魔法の指示文ではなく、AIに渡す情報環境の設計だ、ということです。そしてその設計は、個人の努力ではなく組織の意思決定——何を整備し、誰が推進し、どこに投資するか——にかかっています。

打ち手の順序は自社の現在地で決まります。触れていない段階なら研修、使うが定着しない段階なら情報整備、全社に広がった段階なら管理と更新の仕組み。自社がどこにいるかを取り違えると、正しい打ち手でも効きません。