Prompt Engineering
×
Context Engineering
×
Harness Engineering
AI システム構築における3つの工学スキル
社内技術共有会
Agenda
- Prompt Engineering — LLMへの指示設計
- Context Engineering — LLMが解釈する文脈の設計
- Harness Engineering — AI エージェントの制御構造
- 3領域の比較 — 関係性と使い分け
- まとめ — 実践のポイント
Prompt Engineering とは
LLMから最高の応答を引き出す「命令文」の設計技法
定義
LLMに与える入力プロンプトを精緻化して、予測可能で正確な出力を得る体系的なプロセス
位置づけ
- LLM応用の最初の一歩
- 要約・翻訳・コード生成などで高い精度
- スケーラビリティには限界がある
核心理念
- 明確性と具体性 — 曖昧さを排除
- Few-shot例 — デモでパターンを伝達
- Chain-of-Thought — 思考過程の誘導
- 段階的タスク分解 — 複雑な問題を分離
- 出力形式の明示 — JSON形式 etc.
Prompt Engineering ベストプラクティス
🎯 構造設計
- 指示は最初に配置
### や """ で区切り
- タスク定義 → コンテキスト → 例 の順
- 出力形式・長さ・スタイルを明示
🧠 推論誘導
- CoT (Chain-of-Thought) プロンプト
Let's think step by step
- Few-shotでデモを与える
- ReAct: 思考 → 行動 → 観察
🔧 パラメータ調整
temperature=0 — 事実抽出
temperature=0.7 — クリエイティブ
max_tokens で制御
- 最新モデルを使う
OpenAI API Best Practices / Prompt Engineering Guide / Latitude / Braintrust
Context Engineering とは
LLMの文脈窓(context window)全体を設計・最適化する技法
「LLMは「人間のように知っている」のではなく、
文脈窓に基づいて応答を生成する
— Context Engineeringはこれを制御する構造化された実践
Prompt Engineering との違い
- PE = 1つの指示文の設計
- CE = 文脈窓全体の管理
- メモリ層・検索・ツール定義を含む
- スケーラブルなAIシステムを支える
3層メモリアーキテクチャ
- Context Window — 短期メモリ
- Key-Value Store — 中期メモリ
- Vector DB — 長期メモリ
Context Engineering の4つの構成要素
📝 プロンプト設計
- システム/ユーザ/アシスタントの階層化
- 役割・制約・例による誘導
- Goal/Constraints/Audience の明示
🔍 文脈管理
- 文脈窓に入れる情報の選定
- ノイズの削減(コンテキスト圧縮)
- 「needle in a haystack」問題
- 最初と最後のトークンに注意比重
📡 RAG
- 外部ナレッジベースからの動的検索
- 関連チャンクのみを注入
- Retrievalの精度が性能を決める
- ツール定義の動的取得にも応用
🧠 メモリ層(Memory Layer)
RAGだけじゃなく明示的なメモリ設計が必要 — ないと「文脈エンジニアリングは只是prompt engineeringの裏返し」に
Mezmo / Redis / ByteByteGo / Comet / Callstack
Harness Engineering とは
AI エージェントの制御構造・フィードバック環・ツール群を設計する技法
Harness(ハーネス)= エージェントを制御・誘導するための「装具」
— フィードバックループ、ガイド、センサーを含む
なぜ必要なのか
- LLMは確率的 — 制御が必要
- エージェントは動的にツール選択
- 検証と評価が不可欠(従来のユニットテスト不可)
- Martin Fowler: 環境・フィードバック・制御系の設計
Workflow と Agent
- Workflow — 事前定義ステップ(A→B→C)
- Agent — LLMがツールを動的選択
- Harness = 两者を守る安全装置
- OpenAI: 「最も困難な課題は環境・フィードバック・制御系の設計」
Harness Engineering の構成要素
🔧 ツールセット設計
- LLMへのツール定義の提示
- ツール{description}はトークン消費
- Single-tool single-responsibility
- LangChain / LangGraph etc.
🔁 フィードバックループ
- Claude Code創案者: 自己検証で品質2-3倍
- LSPでリアルタイム診断
- Architecture Fitness Harness(適合性検証)
- Mutation Testing の復刻
📊 観測と評価
- Trace: 何起きているかの可視化
- LLM-as-Judge で評価
- A/Bテスト — プロンプトの比較
- Opik等によるプロンプトバージョニング
🚀 AutoHarness (Google DeepMind)
コード合成でランタイム制約ハーネスを自動生成 — Gemini-2.5-Flash + AutoHarness は TextArena で最高性能
Decoding AI / Martin Fowler / arXiv / GitHub awesome-harness-engineering
3領域の比較
| 次元 |
Prompt Eng. |
Context Eng. |
Harness Eng. |
| 対象 |
指示文(1つのプロンプト) |
文脈窓全体(プロンプト+検索+メモリ) |
エージェントの行動・制御・ツール群 |
| 抽象度 |
★★☆☆☆ (低〜中) |
★★★☆☆ (中〜高) |
★★★★☆ (高) |
| 担当領域 |
NLPエンジニア |
AIアプリエンジニア |
Platform / Agentic エンジニア |
| 主要技術 |
CoT, Few-shot, ReAct |
RAG, メモリ層, コンテキスト圧縮 |
ツール設計, フィードバック, 評価 |
| 主な課題 |
一貫性確保 |
ノイズ・情報Lost in Middle |
不確実性の制御 |
| 拡張性 |
△ — 単一応答が対象 |
◯ — ナレッジ管理 масштабируется |
◎ — システム全体の制御 |
3領域の関係性
Prompt Eng.
LLMへの指示設計
指示 ↓
Context Eng.
文脈窓全体の設計・管理
プロンプト ↑
メモリ・検索 ↑
ツール定義 ↑
Harness Eng.
エージェントの制御構造
Context Eng. ↑
を包含して
Prompt Eng. ⊂ Context Eng. ⊂ Harness Engineering
各領域は包含関係にある — 実際のシステムではすべてを統合的に設計する
実践のTips
Prompt Eng.
- Clear & Detailed Context で開始
- タスクごとに専用プロンプト設計
- CoT で複雑な推論を誘導
- 出力形式を明示(例: JSON)
- 最新モデルを使う(容易で高精度)
Context Eng.
- RAG-First で大規模知識に対応
- 関連しきい値でノイズ除外
- 3層 память (Window/KV/Vector)
- 文脈圧縮(LLMで要約)
- A/Bテストで文脈設計を比較
Harness Eng.
- ツール設計は Single-Responsibility
- 自己検証を組み込む(品質2-3倍)
- Observability & Tracing を導入
- KISSの原則 — シンプルから始める
- 段階的に複雑性を追加
まとめ
- Prompt Engineering — 「LLMへの良い指示を書く」
明確性・具体性・Few-shot・CoT が鍵。最初の一歩。
- Context Engineering — 「LLMが見る文脈全体を設計する」
RAG・メモリ層・コンテキスト圧縮でスケーラビリティを確保。
- Harness Engineering — 「AIエージェントを安全に制御する」
ツール設計・フィードバックループ・観測で本番運用を支える。
3領域は包含関係にあり、
実際のAIシステム構築ではすべてを統合的に設計する
ご清聴ありがとうございました
References: OpenAI API Docs / Prompt Engineering Guide / Mezmo / Redis / ByteByteGo / arXiv / Martin Fowler / Decoding AI / GitHub awesome-harness-engineering