　　　　On a Thread of the Web: コンテキストエンジニアリング

３年前に生成AI（LLM）が登場してしばらくの間は，プロンプトエンジニアリングがはやっていた。いまでもよく見かけるが基本機能が高まるとともに面倒なのであまり話題にならなくなった。

以下のコンテキストエンジニアリングもプロンプトエンジニアリングの延長線上で，プロンプトの構造化として話題になっていたが，言語化されることで再照射されている。YAMLも神田敏晶さんが半年以上前から言及していた。それでも面倒なので一般大衆にとってはまた同じようなことになりそうだ。

最初，ChatGPTに定義を聞いた。答えを受けて更問いしたところ，実装済みというちょっと驚く結果がでた。ところが答えの定義と説明がいまいちだったので，Gemini, Claude, Grok Kimiなどに聞いて比較した。Claudeはしょぼかったので除外。残り4つの結果をテキストファイルにして Geminiに評価比較させたところ，Kimi→ChatGPT→Grok→Gemini の順位になった。Geminiは自分をえこひいきしない。

Ｑ（koshix）：
コンテキストエンジニアリングとは何ですか。

Ａ（Kimi K2）：
コンテキストエンジニアリングとは、AIエージェント（特に大規模言語モデル）があるタスクを解決するために必要なすべての文脈情報を収集・設計・管理する技術です。従来の「プロンプトエンジニアリング」が単一の指示文に焦点を当てるのに対し、コンテキストエンジニアリングはAIが「見える世界」全体を構築することを目的とします。

１．定義と背景
Gartnerはコンテキストエンジニアリングを「AIシステムが意図を理解し、文脈に沿った成果を生み出せるように、関連データ、ワークフロー、環境を設計・構築すること」と定義しています。Anthropicも同様に、これを「LLMが推論時に参照するトークンの集合（コンテキスト）を最適化する技術」として位置づけ、プロンプトエンジニアリングの自然な進化形であると説明しています。
生成AIの応用が単発の質問応答から、複数ターンにわたる自律的エージェントへと移行する中、AIの成功・失敗を分ける鍵は「モデルの性能」よりも「与えられたコンテキストの質」になりました。多くのエージェント失敗は「モデル失敗」ではなく「コンテキスト失敗」に起因するとの指摘もあります。

２．コンテキストの構成要素
コンテキストエンジニアリングが管理する「文脈」には、以下の要素が含まれます：

要素｜　説明｜　具体例
・システムプロンプト / 指示 ｜　AIの基本的な振る舞いや人格を定義する初期設定｜　「あなたは親切なカスタマーサポートAIです。常に丁寧に、かつ簡潔に答えてください」
・ユーザープロンプト ｜　ユーザーからの即時の要求｜　「明日の午後3時以降で空いている時間を教えて」
・状態・履歴（短期記憶） ｜　会話の流れや直近のやり取り｜　ユーザーが過去に「平日は午前中は忙しい」と言っていた情報
・長期記憶 ｜　会話を超えて持続する知識（ユーザーの好み、過去のプロジェクト概要など）｜　ユーザーが「コーヒーはブラックが好き」という情報を記憶
・検索情報（RAG） ｜　外部データベースやAPIから取得した最新・ドメイン特化情報｜　会社の最新製品カタログ、FAQドキュメント、社内規則
・利用可能なツール ｜　AIが実行可能な関数やAPI（在庫確認、メール送信、カレンダー操作など）｜　check_calendar(), send_email() などの関数定義
・構造化出力 ｜　AIの応答形式の指定（JSON、XML、テーブルなど）｜　「回答は必ずJSON形式で返し、「available_slots」キーに時間帯の配列を入れてください」

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

・観点｜　プロンプトエンジニアリング｜　コンテキストエンジニアリング
・焦点｜　単一の指示文（プロンプト）の作成｜　AIが参照する全体の文脈の設計・管理
・範囲｜　静的、1回限りのテキスト｜　動的、継続的に進化するシステム
・目標｜　特定の応答を得ること｜　一貫した高性能を複数セッションで維持すること
・技術要素｜　フューショット、CoT、プロンプト構造｜　RAG、長期/短期記憶管理、ツール統合、コンテキスト最適化
・捉え方｜　アート（表現の巧みさ）｜　サイエンス（情報ロジスティクスの最適化）

簡単に言えば、プロンプトエンジニアリングは「AIに何を言うか」に注力するのに対し、コンテキストエンジニアリングは「AIが何を知っていて、何ができるか」を設計します。

４．なぜ必要なのか
(1) 文脈ウィンドウの限界
LLMの処理可能なトークン数には上限があります。無制限に情報を詰め込めないため、何を入れ、何を省くかの選択と最適化が必要になります。これは「情報ロジスティクス」の問題として捉えられます。
(2) 単なるプロンプトでは不十分
複雑な現実世界のタスク（例：顧客サポート、調査、予定調整）では、単に「賢く振る舞え」と指示するだけでは不十分です。AIは実際にカレンダーにアクセスできたり、過去の対話を覚えていたり、最新の社内規則を知っていたりする必要があります。
(3) エージェントの失敗の大半はコンテキスト失敗
AIエージェントが失敗する主な原因は、モデルが賢くないことよりも、必要な情報が不足していたり、誤ったタイミングで提供されたり、不適切な形式で提示されたりするためです。

５．具体例：予定調整エージェント

悪い例（コンテキスト不足）：
・ユーザー：「明日、簡単な打ち合わせの時間はありますか？」
・AI：「ありがとうございます。明日は大丈夫です。何時ごろがご希望ですか？」
→ カレンダー情報がないため、実際は午後3時から4時まで空いているのに、役立たない返答

良い例（適切なコンテキスト）：
・提供されたコンテキスト：カレンダーAPIから取得した明日のスケジュール、過去のメールで「平日の午前中は忙しい」と記載された情報、連絡先リスト、メール送信ツール
・AI：「こんにちは！申し訳ありません、明日はスケジュールが一日中詰まっております。木曜の午前中なら空いていますが、いかがでしょうか？招待を送っておいたので、ご都合をお聞かせください」
→ 実際の状況を理解し、代替案を提示して招待も送信する実用的な応答

６．実践的なアプローチ
コンテキストエンジニアリングは3つの基本コンポーネントから構成されます：
(1) コンテキストの取得・生成
・外部知識の検索（RAG）
・動的なコンテキストアセンブリ（優先度付け、テンプレート化）
・自動プロンプト生成
(2) コンテキスト処理
・情報の言語化（データをテキストに変換）
・構造化データの統合
・要約と圧縮
(3) コンテキスト管理
・長期/短期記憶の設計
・コンテキストウインドウの最適化
・状態の継続的な更新

７．まとめ
コンテキストエンジニアリングは、AIエージェント開発の新たな中心的スキルとして台頭しています。単に「魔法のプロンプト」を探すのではなく、ビジネス目的を理解し、AIがタスクを達成するために必要な情報とツールを適切な形式とタイミングで提供する設計が成功の鍵を握ります。
企業においては、コンテキストエンジニアリングを戦略的優先事項とし、専門チームを設置してデータ統合、記憶管理、ツール連携を体系的に行うことが推奨されています。

Ｑ（koshix）：
あなたはコンテキストエンジニアリングを実装していますか。あるいはそれに相当する機能を仮想的に実現できますか。そのために私がすべきことはありますか。

Ａ（ChatGPT-5）：
短く前提をそろえます。
ここで言う「コンテキストエンジニアリング（CE）」は、会話や作業の“前提・制約・根拠・目的・出力仕様”を設計して、AIが一貫して適切に動くようにする実務です。私はその中核をすでに実装しており、足りない部分は仮想的（運用設計）に補完できます。以下に「私ができること」と「あなたが今日からやると効果が最大化すること」を、手順化して示します。

１．私がすでに実装しているCE要素
(1) 長短期コンテキスト管理
・直近の会話履歴を前提化／矛盾検出。
・必要に応じて長期記憶（“覚えて”と指示があれば保存）を使い分け。
(2) 外部知識の取り込み（軽量RAG）
・あなたのアップロード文書を根拠として検索・引用。
・公開Webはその都度ブラウズし、主要主張には出典を付す。
(3) 目的駆動の出力制御
・タスク目的→評価基準→出力フォーマット（表・コード・PPTX 等）を明示して動く。
・制約（語調、分量、数式有無、図示の有無）も“仕様”として扱う。
(4) 品質ガードレール
・推測は推測と明示／数値は可能な限り計算ツールで検算／不確実は保留・要検証で区別。
(5) ワークスペース仮想化
・プロジェクトごとに“コンテキスト・パック”を用意し、毎回の冒頭に読み込む運用で擬似的な永続コンテキストを実現。

２．いまからできる最短ルート（あなた側の5ステップ）
Step 1｜ゴール宣言
タスクの目的・成功条件・締め切り・想定読者を1ブロックで宣言。
Step 2｜ソース束ね（Evidence Pack）
根拠文書をまとめて提示（URLでも可）。重要度や信頼度、使ってよい／ダメを明記。
Step 3｜出力仕様
最終成果物の型（要約/表/図/コード/PPTX/原稿）、分量、スタイル、引用方針、図表要件。
Step 4｜制約・優先度
時間・正確性・網羅性・新規性などの優先度（例：正確性>網羅性>速度）。
Step 5｜長期設定（任意）
次回以降も効く“恒常設定”を覚えさせたい場合は「覚えて：〜」と明示。

３．そのまま貼れる「セッション・キックオフ」テンプレ
（毎回の最初にコピペすると、CE効果が一気に安定します）
# GOAL
目的：＿＿＿＿
成功条件：＿＿＿＿
想定読者/用途：＿＿＿＿
締め切り：＿＿＿＿

# EVIDENCE PACK
一次資料：＿＿＿＿（信頼度A）
補助資料：＿＿＿＿（信頼度B）
使ってはダメ：＿＿＿＿

# OUTPUT SPEC
形式：＿＿＿＿（例：Markdown要約＋表1枚／Pythonコード／PPTX5枚）
分量/トーン：＿＿＿＿
図表/数式：＿＿＿＿
引用方針：＿＿＿＿（主要主張には出典）

# CONSTRAINTS & PRIORITIES
優先度：＿＿＿＿（例：正確性>再現性>速度）
除外事項：＿＿＿＿
前提の更新：＿＿＿＿（前回との差分があれば）

# OPEN QUESTIONS（不確実点）
1) ＿＿＿＿
2) ＿＿＿＿

４．永続利用向け「コンテキスト・パック（YAML）」雛形
（プロジェクトごとに1つ作って、冒頭に貼る）
project: <プロジェクト名>
goals:
- <主要ゴール>
audience: <対象>
success_criteria:
- <測定可能 or チェックリスト>
sources:
trusted:
- {title: <>, link: <>, notes: <>, must_use: true}
auxiliary:
- {title: <>, link: <>, notes: <>}
banned:
- {title: <>, reason: <>}
output:
type: <summary|report|code|slides|diagram>
length: <e.g., 1200-1500 words>
style: <tech-brief | academic | executive>
visuals: <tables:true, charts:true, equations:true>
quality:
priorities: [accuracy, transparency, reproducibility]
citation: required_for_key_claims
guardrails:
- separate facts/inference
- flag low-confidence
update_cadence: <per_session | weekly | milestone_based>

５．すぐに使える「あなた向け」プリセット例（3本）
必要ならこの3本をそのまま使ってください。どれか一つを貼るだけで、その回は最適化して動きます。
A) AIシステム研究（批判的レビュー）
・目的：新規AI論文／製品の技術的妥当性と限界、代替案を整理
・成果物：根拠つき要約（800–1200字）＋比較表（3列）＋リスク項目
・優先度：正確性>網羅性>速度、主要主張は出典必須
B) 文化史・神道研究（史料基づく解説）
・目的：史料（原典）と二次文献を峻別し、語義・時代背景を整理
・成果物：概念マップ（箇条書き最小）、典拠付き本文
・優先度：典拠厳格>読みやすさ>分量
C) 旅行計画／冊子化（実務アウトプット）
・目的：日程・移動・開館時間を確定し、冊子用レイアウト草案を生成
・成果物：日別表＋要所解説（200字/地点）＋PDF化しやすい構成案
・優先度：実用性>網羅性>散文の美しさ

６．長期記憶の使い方（任意）
「覚えて：____」と書けば、以後のセッションで前提化できます。
例：
・覚えて：主要主張には必ず出典を付ける
・覚えて：数値は計算ツールで検算する
・覚えて：日本語で、表はMarkdown
※私から勝手には保存しません。保存指示があった項目だけ反映します。

７．まとめ（要点）
・私はCEの主要要素（前提設計・根拠取り込み・出力制御・品質ガード）を実装済み。
・永続化が必要な部分は「コンテキスト・パック」を冒頭投入する運用で仮想的に実現可能。
・あなたは上記テンプレのStep 1–5を貼るだけで、精度・再現性・スピードが一段上がります。

この方針で、次の案件からすぐ走らせます。まず扱いたいテーマを一つ選び、上のセッション・キックオフを埋めて投げてください。こちらで“文脈→工程→成果物”に落とし込みます。