LLMを"嘘つき"から"専門家"に変える ― Context Engineering 実践入門

コンテキストエンジニアリング LLMを“嘘つき”から “専門家”に Context Engineering 実践入門 ken imoto エンジニア / Propel-lab CONTEXT ENGINEERING LLMを 「嘘つき」から 「専門家」に 変える技術 独自ベンチマークで実証。 回答品質が最大4.6倍変わる。 15 章+付録 4.6 倍の品質差 3 ツール実験 (RAG) (MCP) (CLAUDE.md) (Agentic RAG) ken imoto Context Engineering kenimoto.dev

同じ質問なのに、回答が割れる 原因はモデルでも、プロンプトの巧さでもない。差は“その外側”に ある。 回答品質が最大 4.6倍 変わった 出典:本書の独自ベンチマー ク実験 同じLLMに同じ質問。 コンテキストの与え方を変えただけで、品質が 一桁変わった。 架空の社内ツール3つを使い、5段階のコンテキスト戦略でAIの回答 を測定。コンテキストなしのAIは“もっともらしい嘘”を返し、適切 な情報を渡したAIは正確に答えた。 差を分けるのは、AIに何を見せたかだった。 Context Engineering 02 kenimoto.dev

大規模モデルほど、上手に嘘をつく ハルシネーションはバグではない。次のトークンを予測する仕組み の必然だ。 架空ツールの“24時間有効な招待リンク”。存在しない仕様を、賢いモデル ほど具体的で説得力のある嘘として生成してしまう。 1 知らないを 推測で埋める 学習済みの類似パターンを組み 合わせ、もっともらしい値を作 り出す 2 賢いほど 嘘が巧妙に 具体性スコアが高いほど、嘘も 自然で見抜きにくくなる 3 知識の境界が 見えない 「知っている/未知」の区別が できず、自信満々に答える Context Engineering 03 kenimoto.dev

Context Engineering とは何か 何を言うかではなく、何を見せるか。情報環境そのものを設計す る。 LLMがタスクを妥当に解決できるよう、必要なすべてのコンテキストを 与える技術。 単発のプロンプトではなく、推論時に渡る完全な情報ペイロードを設計 する。 - Tobi Lütke / Andrej Karpathy プロンプトエンジニアリング 面接で「頑張ります」と伝える Context Engineering 入社後に資料・権限・環境を整える Context Engineering 04 kenimoto.dev

プロンプトの限界、その先へ 言葉を磨く側から、AIに渡る情報そのものを設計する側へ。 プロンプトを磨く - 実行時に指示が固定される - 変化する状況に追従できない - ドメイン知識を詰め込めない - 権限や最新データを反映できない → コンテキストを設計する - 必要な知識を動的に注入する - 外部システムと連携して取得する - 権限・状況に応じて出し分ける - 事実に根ざした回答に変わる Context Engineering 05 kenimoto.dev

5段階のコンテキスト戦略 情報の与え方を段階的に積み上げると、スコアは右肩上がりに伸び ていく。 1 最小 コンテキスト なし 5.3/20 > 2 規範 System Prompt 8.8/20 > 3 例示 + Few-shot 10.0/20 > 4 知識 + RAG 10.2/20 > 5 統合 フル コンテキスト 11.4/20 Claude Sonnet 4 の総合スコア(20点満点)。同じモデル・同じ質問で5.3 → 11.4 と 2.2倍に。 Context Engineering 06 kenimoto.dev

RAG が、効果の8割を生む 外部知識の注入こそ、品質改善の最大のブレイクスルーポイント。 事実正確性スコア(Haiku) 0 → System Only → System + RAG 総合スコアは 3.7 → 11.8(+8.1) “知らないことを知らない”が、調べてから 答えるに変わる瞬間。 社内Wikiのアクセス権を渡した新人のように、AIは推測をやめて事 実に基ついて答える。 5段階の積み上げの中で、RAGの1ステップが伸びの大半を占め た。 Context Engineering 07 kenimoto.dev

5つの技術を積み上げる Context Engineering は単一の手法ではなく、段階的に重ねる技術 の体系。 1 System Prompt 役割と振る舞いの規範を与え、推 測の暴走を抑える 4 MCP / Tools 外部世界と接続し、必要な情報を 取得して答える 2 Few-shot 少数の良い例を見せ、出力の型を 学ばせる 5 Memory 会話やセッションをまたいで文脈 を持ち越す 3 RAG 外部知識を検索して注入し、事実 に根ざす【核心】 + CLAUDE.md 現場の規範を明文化し、エージ ェントに常に効かせる Context Engineering 08 kenimoto.dev

MCP で外部世界とつなぐ 静的な知識から、必要な情報をその場で取得して答えるAIへ。 LLM 質問を受け取る ↔ MCP Server Resources / Tools / Prompts ↔ Tools & APIs DB・社内システム・外部API 「知っている情報で答える」から 「必要な情報を取得して答える」への進化。ツールの説明文もコンテキストになる。 Context Engineering 09 kenimoto.dev

小さいモデル + RAG が勝つ 「大きいモデルほど良い」という常識を、実験データが覆した。 Haiku 3 + RAG 11.8 小型モデル + 良いコンテキスト > Sonnet 4 単体 5.3 大型モデル + コンテキストなし スコアで 223% 上回り、しかもコストは約1/12。投資すべきはモデルの大きさではな く、コンテキストの設計だった。 Context Engineering 10 kenimoto.dev

渡す情報を、設計する AIの回答品質の天井は、モデルではなくコンテキストが決める。 プロンプトを磨くだけなら、AIの答えは運任せ。 渡すコンテキストを設計すると、品質が一桁変わる。 01 差はモデルでなく、何を見 せたか 02 RAGが品質改善の最大要因 03 小さいモデル + 良い文脈が 勝つ Context Engineering 11 kenimoto.dev

全体像は、この本に。 Zenn Book zenn.dev/kenimo49/books/context- engineering Kindle amazon.co.jp/dp/B0GHNC29MF 全15章+付録。5段階の戦略・RAG・MCP・CLAUDE.md・Agentic RAG・導入事例を、実験データと実装コードで体系化。 エンジニアのためのAI実践シリーズ 第2巻 - kenimoto.dev CONTEXT ENGINEERING LLMを 「嘘つき」から 「専門家」に 変える技術 独自ベンチマークで実証。 回答品質が最大4.6倍変わる。 15 章+付録 4.6 倍の品質差 3 ツール実験 (RAG) (MCP) (CLAUDE.md) (Agentic RAG) ken imoto Context Engineering 12 kenimoto.dev