AIエンジニアが今知るべき設計原則 / プロンプトからコンテキストへ
結論：何が変わったのか
- 「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ。これは単なる言葉の言い換えではありません。
- プロンプトエンジニアリングは「完璧な呪文を探す行為」でした。コンテキストエンジニアリングは「LLMが仕事をするために必要な情報を動的に組み立てるシステム設計」です。
- エージェントの失敗の大半は、モデルの失敗ではなくコンテキストの失敗です。
1. LLMの本質を理解する
LLMは「予測エンジン」です
LLMはデータベースから答えを検索しているのではありません。入力テキストの「最も確率的に自然な続き」を生成しています。したがって開発者の仕事は、モデルが予測する「続き」がユーザーの意図する「正解」と一致するように、確率空間を制約することにあります。
出力を制御する3つのパラメータ
| パラメータ | 役割 | 論理タスク | 創造タスク |
|---|---|---|---|
| Temperature | ランダム性の調整 | 0〜0.1 | 0.7以上 |
| Top-K | 候補トークン数の制限 | 1〜20 | 40以上 |
| Top-P | 累積確率による動的フィルタ | 0.9 | 0.95 |
- 重要: Temperature=0は最強の制約です。これを設定すると、Top-KやTop-Pの効果は無効化されます。
- 論理的推論（CoT）にはTemperature=0が必須です。
2. コンテキストの構成要素
「コンテキスト」とは、モデルが応答を生成する前に「見る」すべての情報を指します。
| Context Window | 内容 |
|---|---|
| System Prompt | モデルの振る舞い、ルール、例示 |
| User Prompt | 直接的なタスクや質問 |
| Conversation | 会話履歴（短期記憶） |
| Long-term Memory | 過去の会話から学んだ情報 |
| RAG Data | 外部DBやAPIからの最新情報 |
| Tools | 呼び出し可能な関数の定義 |
| Output Schema | 期待する出力形式（JSON等） |
重要な認識: これは「一度書いたら終わり」のテンプレートではありません。リクエストごとに動的に組み立てるシステムの出力です。
3.「安っぽいデモ」と「本番品質」の違い
同じメール「明日、ちょっと打ち合わせできる？」に対する応答を比較します。
コンテキスト不足
ご連絡ありがとうございます。明日は大丈夫です。何時がよろしいでしょうか？
十分な情報を持つコンテキスト
Aさん！明日は一日中予定が詰まってる。木曜の午前なら空いてるけどどう？
招待送っておいたから確認してね。
後者を実現するためにシステムが行ったことは以下の通りです：
- カレンダー情報の取得（明日は終日ブロック）
- 過去のメール履歴（この人とはカジュアルなトーン）
- 連絡先情報（重要なパートナー）
- ツールの提供（send_invite, send_email）
魔法はモデルの賢さではなく、適切なコンテキストの提供にあります。
4. プロンプト技術の選択指針
タスクの複雑さに応じて適切な技術を選択します。
基礎技術
| 技術 | 使い所 | 注意点 |
|---|---|---|
| Zero-Shot | 一般的な知識、簡単な要約 | モデルの解釈に依存 |
| Few-Shot | 分類、フォーマット変換 | 例示のクラスは混在させる |
| Role Prompting | トーン・視点の指定 | 探索空間を絞り込む効果 |
推論系技術
| 技術 | 使い所 | 必須設定 |
|---|---|---|
| Chain of Thought (CoT) | 数学、論理パズル、デバッグ | Temperature=0 |
| Step-Back | 抽象的原則→具体的回答 | 2段階のプロンプト |
| Self-Consistency | 推論の信頼性向上 | 複数回生成→多数決 |
| Tree of Thoughts | 戦略立案、複雑な意思決定 | 分岐の探索・評価 |
エージェント技術
| 技術 | 使い所 | 注意点 |
|---|---|---|
| ReAct | 外部ツール連携、リアルタイム情報 | ループ制御必須（max_tokens設定） |
| APE | プロンプト自動最適化 | 候補生成→評価→採用 |
5. 実装のベストプラクティス
設計原則
- 否定より肯定: 「〜しないで」より「〜して」の方が従順性が高くなります
- 具体的に指定: 出力形式、長さ、文体を明示します
- 構造化: タスク説明 / 文脈 / 入力データ / 出力形式 を分離します
運用原則
- 変数化: 再利用可能なテンプレートにします（
{city},{user_input}） - 出力長制御: コスト・レイテンシ削減のため、必要以上の生成を抑制します
- 実験記録: モデルバージョン、プロンプト、パラメータ、結果を記録します
コード関連タスクの分類
| カテゴリ | 具体例 |
|---|---|
| コード記述 | 自然言語からコード生成 |
| コード説明 | 正規表現やレガシーコードの解説 |
| コード翻訳 | Python→C++、SQL→Pandas |
| デバッグ | エラー原因特定、リファクタリング |
6. コンテキストエンジニアリングの定義
改めて定義します：
コンテキストエンジニアリングとは、LLMがタスクを達成するために必要なすべてを与えるために、適切な情報とツールを、適切なフォーマットで、適切なタイミングで提供する動的システムを設計・構築する技術です。
4つの特性
- 文字列ではなくシステム — 静的なテンプレートではなく、LLM呼び出しの前に実行されるシステムの出力です
- 動的な生成 — リクエストごとにその場で作成されます
- 適切なタイミング — 必要な時にだけ知識と機能を提供します（GIGO回避）
- フォーマットの重要性 — 生データより要約、曖昧な指示より明確なスキーマが効果的です
まとめ：開発者がやるべきこと
| やめること | 始めること |
|---|---|
| 「完璧なプロンプト」を探す | コンテキスト収集システムを設計する |
| 毎回同じプロンプトを使う | リクエストに応じて動的に組み立てる |
| モデルの賢さに依存する | 必要な情報を事前に揃える |
| プロンプトを手動管理 | バージョン管理と実験記録を行う |
AIの本当の力を引き出すのは、賢いプロンプトではなく、賢いシステム設計です。