コンテキストエンジニアリングとは｜プロンプトの次に来る、会社の作業

先に、役割分担を置きます。この記事で書くのは経営思想ではありません。経営思想は、私は「コンテキスト経営」と呼んでいます。会社の文脈——暗黙知、判断基準、歴史、顧客理解——を人とAIが働ける形で残し、経営の再現性をつくる話です。合言葉は「文脈が残れば、会社は続く。」定義の正本はコンテキスト経営とはにあります。本記事は、その一段下、実装の話です。

コンテキストエンジニアリングとは、プロンプトを磨くことではなく、AIが次の仕事を誤らず進められるように、会社の情報・判断基準・お手本・働く場所を組み立てる作業である。2025年に世界の開発者たちが使い始めたこの言葉を、中小企業の現場の作業として定義します。プロンプトを磨く会社と、職場を渡す会社では、半年後の景色が違います。

---

コンテキストエンジニアリングとは何か——世界の定義と、現場の定義

2025年6月、Andrej KarpathyはXでこう書きました。コンテキストエンジニアリングは、「次の一歩に必要な、ちょうどよい情報でコンテキストウィンドウを満たす、繊細な技であり科学である」（原文: the delicate art and science of filling the context window with just the right information for the next step. 出典: Karpathy, 2025-06-25）。ShopifyのTobi Lütkeも同年、プロンプトよりコンテキストを設計する側へ言葉を移しています。

技術者の言葉を、そのまま中小企業に持ち込むと、画面の裏の用語になります。コンテキストウィンドウ、トークン、RAG、メモリ。必要な人には必要な言葉です。ただし、顧問先の会議室でこのまま話すと、作業が始まりません。私は生成AI顧問として累計約15社、研修・講座を含め30社超、レクチャーは100名以上を見てきました。その現場で使う定義は、もっと作業に近いです。

Karpathyの定義と、私の現場定義は、対立しません。同じことを、担い手が違って見ているだけです。開発者は、モデルの窓を設計する。経営者と現場は、会社の机を設計する。窓に入れる中身の大半は、会社の外にはありません。商品の言い回し、値引きの線、過去の失敗、うまくいった提案書。それはエンジニアリングの道具で生成するものではなく、会社の作業で外に出すものです。

だから私は、この言葉を「エンジニアだけのもの」にしたくありません。実装語ではある。ただし実装の本体は、コードを書くことより先に、会社の文脈をファイルにすることです。

世界語を、会社の作業に翻訳すると、だいたい次の対応になります。用語を覚える必要はありません。右列の作業ができていれば、左列の言葉は後から追いつけます。

世界語で言われるもの	会社の作業に落とすと
コンテキストウィンドウ	その仕事の直前に、AIが読める机の広さ
システムプロンプト	毎回読む就業ルール。禁止と順番と保存先
few-shot	お手本の成果物を2〜3本置くこと
RAG	必要なときに、正しい版だけを探す接続
メモリ	その人との口癖。会社の正本にはしない
ツール呼び出し	書いてよい場所、使ってよい道具の範囲
ちょうどよい情報	古い正を混ぜず、次の仕事に要るものだけ

日本語の解説が空いているのは、左列の翻訳ばかりが増えて、右列の作業が記事にならないからです。本記事は右列の正本です。左列の実装細部——どの製品のどの機能か——は、2年後に名前が変わります。右列は残りやすい。

コンテキスト経営との役割分担——思想と実装を混ぜない

似た名前なので、混ぜたくなる気持ちは分かります。混ぜると、どちらも薄くなります。私の使い分けは、こうです。

観点	コンテキスト経営	コンテキストエンジニアリング
層	経営思想	実装の作業
問い	何を残し、何を手放し、誰に渡すか	残すと決めたものを、どこに、どの形で据えるか
主語	経営者	現場と、AIの職場を設計する人
成果	人が抜けても判断の質が落ちない会社	AIが次の仕事を、毎回ゼロから聞かずに進められる状態
失敗の形	文脈が社長の頭の中に閉じたまま	毎回長い指示を貼り、同じ直しを繰り返す
先に読む場所	コンテキスト経営とは	このページ

思想がないまま実装だけ走ると、何でもフォルダに入れて「渡した気」になります。実装がないまま思想だけ語ると、美しい言葉で終わります。両方いる。ただし記事は分けます。本記事が受け持つのは、実装の側です。

混同が起きるのは、どちらも「コンテキスト」を主語にするからです。思想は、残す対象の話です。暗黙知、判断基準、歴史、顧客理解。実装は、残し方の話です。3行にする、机に置く、仕事で一回使い、穴を戻す。対象と残し方を同じ段落で語ると、経営者はフォルダの話だと思い、現場は理念の話だと思う。担当が消えます。

私の契約が3ヶ月で区切られ、自動更新しないのも、この分担の延長です。いまの契約は、自動継続をやめています。3ヶ月あれば、棚卸しからインストールまでを一周させ、文脈を会社側に残せる、という前提です。思想だけ語って残らなければ、延長しても同じ先送りです。実装だけ走って何を残すかの線がなければ、机は荷物置きになります。両方を、同じ人間が同じ順番で見る。それが顧問の仕事であって、本記事の主題ではありません。主題は、実装語の中身です。

プロンプトを磨く会社と、職場を渡す会社

同じモデルを使っているのに、ある会社では解像度の高い下書きが出て、別の会社では当たり障りのない一般論しか返ってこない。この差を、私は繰り返し見てきました。原因は、モデルでも、指示文の語彙でもありません。渡している文脈の量と質です。

私はこの差を、レクチャーで「コンテキスト＞＞＞プロンプト」と呼んでいます。出所は自社の方法論です。優秀なAI社員は Prompt×Context×Harness——伝え方と、会社の情報密度と、守らせるルール——の掛け算です。世の中の解説は、掛け算の左端ばかりを磨きます。

磨き会社の典型は、こうです。誰かが気を利かせて「使えるプロンプト100選」を配る。最初の1週間は試す。1ヶ月後、誰も開かなくなる。私自身、顧問業の初期に「良い指示文の型を渡せば動き出すはず」と考え、同じ墓を掘りました。書籍『コンテキスト経営』の序章で、私はこれをプロンプト研修の墓場と呼びました。レクチャー100名以上のうち、当日は歓声が上がり、三週間後に訪ねると、配った虎の巻は共有フォルダの奥で眠っている。あの頃の受講者には、謝りたいくらいです。

職場を渡す会社は、逆の順です。先に、何の仕事かを決める。次に、その仕事の材料と判断基準とお手本を、AIが毎回読める場所に置く。指示は、あとから雑になっても動きます。多少ぶっきらぼうでも、キャビネットを見ている社員のほうが、持参資料だけのコンサルより的を外しません。

観点	プロンプトを磨く会社	職場を渡す会社
最初の投資	指示文の型、研修、プロンプト集	棚卸し、置き場所、お手本の選定
毎回の依頼	長い。背景から書く	短い。材料は机にある
出力	人と日でばらつく	お手本と基準で安定する
直し方	その場のチャットで直して終わる	直しをルールかお手本に戻す
1ヶ月後	集は開かれなくなる	机の中身が厚くなる
担当が代わったら	使いこなしごと消える	机を渡せば再現できる
ツールが変わったら	指示文を移植し直す	職場ごと移す
会社に残るもの	個人のコツ	判断基準とお手本

右の列が、コンテキストエンジニアリングの成果です。左の列は、努力の方向が違うだけです。悪意はない。順番が違う。

現場の3工程——棚卸し → ディレクトリ → インストール

私の顧問先での標準工程は、この3つです。出所は提供運用そのもので、思想記事でも同じ順を使っています。本記事では手順の細部ではなく、各工程が「コンテキストの設計」として何をしているかを固定します。

①の本体は、時間の一覧表ではありません。AIに渡すべき文脈の在庫リストです。どの仕事に材料があり、どの判断がまだ頭の中だけか。ここを飛ばすと、あとのフォルダは空になります。やり方の細部は業務棚卸しの記事が正本です。

②の本体は、ツールの契約ではありません。置き場所です。私自身の会社では現在、ルールを育てる側をGitHub（非公開）、閲覧できれば十分な側をGoogle Driveへミラーする2層で回しています。作り方の実装はコンテキストのチーム共有にあります。本記事で言いたいのは、「正しい版が一つある」こと自体がコンテキストだ、という点です。最新版が三つある会社は、文脈を持っているのではなく、文脈の衝突を持っています。

③の本体は、チャットの成功体験ではありません。仕事を一度、最後まで回すことです。回すと、足りない判断基準が見えます。見えた穴を机に戻す。この往復が、コンテキストエンジニアリングの日常です。職場側の作り方はAI社員の作り方へ譲ります。

3工程を、世界語の「次の一歩に必要な、ちょうどよい情報」に重ねると、役割がはっきりします。棚卸しは、何が必要かを決める。ディレクトリは、必要なものだけが次の一歩の直前にある状態をつくる。インストールは、その状態で一歩を踏み、過不足を測る。測らずに窓を満たし続けると、ただの荷物になります。

顧問の初回で会議室が静かになるのは、いつも同じ場所です。「何をさせるのか」を言えない。ツールの話なら盛り上がる。ChatGPTとClaudeのどちらがよいか、料金はいくらか。仕事の名前が出た瞬間、言葉が止まる。棚卸しがコンテキスト投資そのものだ、と私が言う理由はここです。渡す文脈の在庫が見えないまま、窓の設計だけを語っても、中身は空です。

在庫の見方は粗くて構いません。その仕事の材料は、すでにファイルとして存在するか。判断の線は、まだ特定の人の頭だけか。お手本は、どれが正か。この3問に答えられない仕事は、まだコンテキストエンジニアリングの対象ではありません。先に、対象を一つに減らします。全社の文脈を一度に設計しようとすると、倉庫づくりに戻り、wikiの失敗と同じ順番をたどります。

持ち帰り：最小コンテキスト3点セット

窓を満たす情報は、いくらでも増やせます。増やしすぎると、今度は古い資料と新しい資料が喧嘩します。最初に据えるのは、3つで足ります。これが本記事の持ち帰りです。

会社3行の失敗例は、「総合的なソリューションを提供する企業です」です。これでは、どの会社にも当てはまります。必要なのは固有名詞と、対象と、やらないことです。「地方の設備会社で、点検と改修を主に請け負う。新規の大型開発は受けない」——この粒度です。

判断基準の失敗例は、「お客様第一」です。誰も反対しない言葉は、次の仕事を決めません。「初回の見積は多少高くてもよい。代わりに当日中の一次回答を優先する」——この粒度です。価格表の数字だけでは、判断の半分も伝わりません。

お手本の失敗例は、フォルダに十年分を全部入れることです。古い料金、廃止した型、例外対応の残骸が混ざると、AIは堂々とその残骸を踏襲します。良いものを2〜3本。古いものは外す。足すより、削るほうが先です。

この3点が机にあれば、指示は雑でも動き始めます。3点がないまま指示だけ磨くと、毎回の持ち込み作業が増えるだけです。

書き方の穴埋めを置きます。きれいな文章にする必要はありません。他人が読んで、別の会社と取り違えなければ十分です。

判断基準は、部署の標語ではなく、その仕事の線です。営業なら「初回は速さ、二回目から精度」。事務なら「不明な数字は埋めず、空欄と確認事項で返す」。現場系なら「写真と日付のない記録は、報告書に使わない」。誰も反対しない言葉を避け、次の一手が決まる文だけを残します。

お手本は、点数の高いものより、「この型で出してほしい」ものです。例外対応で奇跡的にうまくいった一枚は、お手本にしないほうがいい。再現したい平均の上、を置きます。AIは置かれた実物を、正として踏襲します。

プロンプト、RAG、wiki——何が違って、何が足りないか

コンテキストエンジニアリングは、既存の手法を否定するために生まれた言葉ではありません。足りない層に、名前が付いただけです。

手法	設計するもの	会社の作業か	残り方	足りないところ
プロンプトエンジニアリング	言い方	△（個人の技になりやすい）	個人のメモ帳	読ませる材料がない
RAG・検索接続	探し方	△（仕組みは会社、中身は別）	システム側	古い文書まで拾うと事故る
社内wiki・ナレッジ基盤	置き場と検索	○（書く作業はある）	ページとして残る	読まれず、更新が止まる
カスタム指示・GPTs	自己紹介	△	作成者の設定	案件資料が入らない
コンテキストエンジニアリング	次の仕事の材料一式	◎	職場とルールに残る	何を残すかの思想がないと、何でも入れて壊す
コンテキスト経営	何を残すかの線	◎（経営の仕事）	会社の判断として残る	実装がなければ言葉で終わる

RAGは、「探す」ための実装です。探す対象が整理されていなければ、古い見積と新しい見積を同じ顔で持ってきます。検索精度の問題に見えて、中身の問題です。

社内wikiの失敗は、もっと古い。書いても読まれない。読まれないから更新が止まる。更新が止まったものは「古い」と言われ、ますます読まれない。この循環は、ナレッジマネジメント論が広がってから約30年、壊れていませんでした。詳細はナレッジマネジメントが失敗し続ける理由に譲ります。コンテキストエンジニアリングがwikiと違うのは、読み手が最初からAIである点です。人が気合で開く前提を捨て、毎回読む相手を職場に据える。書く動機は、読まれることからしか生まれません。

直した文脈は、どこへ戻すか——4分岐

インストールしたあと、必ず直したくなります。ここが分岐です。直しをチャットの中で終わらせると、コンテキストは増えません。私は顧問先で、直しの行き先を4つに分けています。出所は提供運用の第5回ワークです。

• 流す——今回限りの例外。残さない。残すと例外が正になる。
• メモリ——その人との口癖や、一時的な好み。会社の正本にはしない。
• ルール——次回から全員の仕事に効かせる線。禁止事項、順番、保存先。
• コマンド（手順）——その仕事専用の呼び出し。いつもの日報、いつもの週次。

全部をルールに書くと、誰も把握できない取扱説明書になります。私は初期に張り切って長いルールを書き、自分でも把握できないファイルを作って反省しました。全部を流すと、同じ直しが永久に続きます。分岐する、ということが設計です。

「壊されないか」より、「壊れても戻せるか」。書き戻せる場所がある会社は、失敗を恐れずに直せます。書き戻す場所がない会社は、成功したチャットを再現できず、またゼロから説明します。

やりがちな失敗——窓を満たすほど、壊れる

世界語の定義には「ちょうどよい情報」とあります。現場でいちばん多い失敗は、多すぎることです。

• 全部入れる——十年分の共有フォルダを、そのまま職場にする。古い正と新しい正が同居する。
• 機密まで入れる——入口を開けすぎる。必要な分だけ、必要なときに見せる、が先。
• 思想を飛ばす——何を残すかを決めず、置けるものから置く。机は埋まる。判断は増えない。
• ツールから入る——新しい接続、新しいメモリ機能、新しい検索。窓の仕組みは増える。会社3行がない。
• 個人の机のまま止める——一人は回る。その人が休むと、文脈が消える。共有は別工程だが、最初から「正しい版はどこか」だけは決める。

契約して触らなくなる会社の多くは、ツール不足ではありません。次の仕事の材料が、会社の側にない。だから毎回、個人の頭から貼る。貼るのが面倒になり、開かなくなる。構造の問題です。

「コンテキストがある」と誤認しやすいものも、分けておきます。机に載っていることと、次の仕事の材料であることは、同じではありません。

• 長いチャット履歴——昨日の雑談と、先月の例外が混ざる。正本ではない。
• 共有ドライブの丸ごと接続——量はある。正しい版がない。古い料金が勝つ。
• PDFを毎回貼る習慣——その回は動く。翌日の別人は、また貼る。
• 理念カード——「誠実に」は判断を決めない。線になっていない。
• 個人のメモリ設定——その人には効く。会社の資産ではない。

少なすぎると一般論になります。多すぎると、古い正と新しい正が喧嘩します。世界語の「ちょうどよい」は、量のセンスではなく、捨てる作業です。何を入れないかを決めること自体が、コンテキストエンジニアリングです。

入れないものの代表は、個人情報、パスワード、顧客の非公開条件、廃止した料金、例外対応の残骸です。入口を開けすぎた事故と、出口（削除・送信・公開）を開けすぎた事故は、形は違って根は同じです。窓を満たすことと、何でも見せることは、反対の作業です。

誰が最初にやるか——エンジニアである必要はない

名前にエンジニアリングと付いているので、開発者の仕事だと思われがちです。世界語としては、その理解で正しい面もあります。現場語としては、最初の担い手は、社内でいちばん「これ、言葉にできたら楽なのに」と感じている人です。

経営者の役割は、全部を自分で書くことではありません。その人に時間と、社内情報へアクセスする権限を渡すことです。何を残すかの線だけは、経営者が引きます。ここが思想側——コンテキスト経営——の仕事です。

一人で始めて構いません。最初から全社一斉は、止まります。ただし、置き場所の正系だけは、最初から一つに決めてください。個人の成功を、個人のフォルダに閉じたまま増やすと、また属人化します。

最初の仕事の選び方も、実装の一部です。繰り返す、手順を言葉にできる、成果物をすぐ確認できる。この三つが揃う仕事から、3点セットを置きます。迷うなら、すでに実物がある仕事です。お手本が社内にない仕事は、まだコンテキストを設計できません。先に、人が一回やって実物を残す。その実物が、次の窓の材料になります。

仕事が違うと、3点の中身も違います。型だけ置きます。中身は、自社の言葉に差し替えてください。

仕事	会社3行で足すこと	判断基準の例	お手本
議事録の整理	会議の種類と、残す相手	決定と宿題だけ残す。雑談は捨てる	良い週次サマリー2本
提案の下書き	誰に何を売らないか	金額と納期は埋めない。確認欄にする	通った提案書2〜3本
見積の下書き	主戦場と、受けない案件	値引きの上限。急ぐ／急がないの線	良い見積と、使ってはいけない旧料金
点検・現場記録	扱う設備や現場の範囲	写真と日付のない記録は使わない	良い報告書2本
広報の原稿化	トーンと、出さない話題	未確認の数字は書かない	トーンが分かる過去稿2本
問い合わせ一次整理	対象顧客と、対象外	謝罪と値引きは人が書く	良い一次回答と、使ってはいけない例

表の右へ進むほど、世界語の「ちょうどよい」に近づきます。左だけ書いて右が空だと、理念カードです。右だけあって左がないと、真似はできても、やらないことが分かりません。3点はセットです。

よくある質問

Q1. コンテキストエンジニアリングとは、一言で何ですか？

AIが次の仕事を誤らず進められるように、会社の材料と判断基準とお手本を、職場に据えておく作業です。指示文の磨き方の、一段上です。

Q2. コンテキスト経営と同じものですか？

違います。コンテキスト経営は、何を残すかを決める思想です。コンテキストエンジニアリングは、残すと決めたものを据える実装です。思想の定義はコンテキスト経営とはへ。

Q3. プロンプトエンジニアリングは、もう不要ですか？

不要ではありません。後回しです。材料がない状態で言い方だけ磨くと、上手な一般論が増えます。材料が揃ったあとなら、伝え方の工夫は上積みになります。

Q4. RAGを入れれば、コンテキストエンジニアリングは終わりですか？

終わりません。RAGは探し方です。探す対象が古ければ、古い正解を持ってきます。先に、正しい版とお手本を決める作業が残ります。

Q5. エンジニアでなくてもできますか？

最小3点セット——会社3行、判断基準、お手本——は、エンジニアリングの資格なしに始められます。接続や自動化は、そのあとです。

Q6. 何から始めればいいですか？

任せる仕事を1つ決め、その仕事の3点セットを机に置くことです。全社の文脈を一度に書こうとすると止まります。棚卸しの型は業務棚卸し、机の作り方はAI社員の作り方です。

Q7. どれくらいの量を渡せばいいですか？

最初は3点セットで足ります。足りないものは、仕事を一度回した穴で足します。十年分を先に入れるほうが、壊れます。

Q8. チームで同じ文脈を使うには？

正しい版を一つに決め、見る人と直す人を分けます。自社はGitHubとDriveの2層です。実装はチーム共有の記事へ。

Q9. ナレッジマネジメントと何が違いますか？

wikiは、人が検索して読む前提になりがちです。コンテキストエンジニアリングは、次の仕事の直前に、必要な材料がすでに机にある状態を設計します。倉庫ではなく、職場です。

Q10. ツールが変わったら、やり直しですか？

窓の仕組みは変わります。会社3行、判断基準、お手本は、テキストとファイルなら移せます。残るものを、特定ツールの設定の中だけに置かないことです。

まとめ：次に磨くのは、言い方ではない

コンテキストエンジニアリングは、2025年から世界で使われ始めた実装語です。窓に、次の一歩に必要な情報を、ちょうどよく入れる。中小企業の現場では、それは会社3行、判断基準、お手本を、職場に据える作業になります。プロンプトを磨く会社は、個人の技を増やします。職場を渡す会社は、次の人も次のAIも使える材料を増やします。

思想はコンテキスト経営、棚卸しは業務棚卸し、机はAI社員の作り方、共有はチーム共有、書いても読まれない歴史はナレッジマネジメントの失敗へ分けます。本記事の仕事は、実装語の名前を、会社の作業として固定することだけでした。

今日やるなら、3点セットです。会社を3行で書く。判断の線を一文で書く。良い成果物を2〜3本、古いものと分けて置く。指示文は、そのあとでいい。