答えが悪いとき、モデルを変える前に見るもの
AI の答えが期待より悪い。多くの人はまず「もっと高性能なモデルに変えよう」と考えます。でも、出力品質の問題は、ほぼすべて**「渡している情報の問題」**に帰着します。必要な情報が欠けている、関係ない情報が混ざっている、指示が曖昧。モデルを変える前に、ここを確認します。
コンテキストエンジニアリングは、LLM に渡す文脈情報を体系的に設計・管理する技術です。「何を、どの形式で、どのタイミングで、どの順序で渡すか」を設計します。元 OpenAI の研究者 Andrej Karpathy が、LLM を新しい種類の OS に、コンテキストウィンドウを CPU に対する RAM（作業メモリ）にたとえて広めました。
プロンプトエンジニアリングとの関係
プロンプトエンジニアリングは、指示文そのものの書き方を工夫する技術です。コンテキストエンジニアリングは、指示文に加えて、参照文書、会話履歴、使えるツールの情報など、回答の前提になる情報全体を設計します。だから、プロンプトエンジニアリングはコンテキストエンジニアリングの一部です。試験では「どちらが上位概念か」が問われます。
解決する4つの課題
- 入力できる量の限界: 長く動かすと、ツールの実行結果・検索結果・対話履歴が溜まって上限に達する。超えた分は処理されず、重要な情報が落ちる。
- 認識の限界（Lost in the Middle）: スタンフォード大学の研究によると、LLM はコンテキストの先頭と末尾を参照しやすく、中間部分を見落としやすい。配置する位置が出力品質を左右する。
- コンテキスト汚染: ハルシネーションが一度コンテキストに混入すると、後の判断に悪影響が出る。自分の出力を次の入力に使うため連鎖的に広がる。
- コンテキスト混乱: 無関係・矛盾する情報が混ざると推論が阻害される。関連性・時系列・矛盾を管理する設計が要る。
LLM に渡す7種類の情報
試験では「AI が参照したこの情報は7種類のどれか」が問われます。
| 種類 | 中身 |
|---|---|
| システムプロンプト | すべての対話に共通する役割・前提・制約・行動指針。土台であり、最初に最も時間をかけて設計する「ぶれない軸」 |
| ユーザープロンプト | 都度の指示や質問。エージェント環境では内部で生成される中間的なタスク指示も含む |
| 短期メモリ | いまのセッション内の対話履歴と状態。古い情報は除き、重要な決定事項は保持する |
| 長期メモリ | セッションをまたいで保持される情報。手続き記憶（どう対応すべきか）、エピソード記憶（過去に何があったか）、意味記憶（事実）の3種類 |
| 外部知識（RAG） | ナレッジベースから検索・取得した情報。全部足せばよいわけではなく、関連度・鮮度・量のバランスを考える |
| ツールの情報 | 使えるツールの定義と使い方。説明が曖昧だと誤ったツールを呼ぶか、ツールを使わずに自分の知識だけで答えようとする |
| 構造化出力 | 応答形式の指示（JSON、表、テンプレート）。別システムに渡るため、形式がぶれると解析エラーになる |
「過去の対話で得た情報」は会話の記憶、「ナレッジベースを検索して得た情報」は外部知識（RAG）です。
4つの手法
- 書き出し（Write）: 重要な情報を外部に保存して容量を確保する。長い作業で ToDo リストを書き直しながら進めるのが実践例で、Lost in the Middle の対策にもなる。
- 選択（Select）: 必要なものだけを取ってくる。メモリの読み込み、ツールの選択、RAG の検索。選択の精度がコンテキストの品質を決める。関連性の低い情報を渡すことは、渡さないことより悪い場合がある。
- 圧縮（Compress）: 要約して重要な内容だけ残す。必要な情報が欠けるリスクがあるので、できる限り避ける手法。圧縮の前に、タスクの分割や選択の最適化を検討する。
- 分割（Isolate）: 複雑な問題を小さな部分問題に分ける。複数のエージェントが専門領域を分担する方法と、1つのエージェント内で段階的に処理する方法がある。単純な方法から順に検討する（指示を短く明確に → 1セッション内で段階処理 → それでも難しければ複数エージェント）。
4つの設計原則
- 必要十分の原則: 「関係するかもしれない」で足さない。「この情報がなければ正しい出力ができないか」を問う。
- 構造化の原則: 重要な制約はシステムプロンプトの冒頭に。参照情報と指示文を区別し、番号付きリストや見出しで構造化する。人に読みやすい文書と AI が処理しやすい構造は違うことがある。
- 鮮度の原則: LLM は後半（最新の部分）をより強く参照するので、重要な指示や直近の状況は後半に置く。
- 反復検証の原則: 情報を1つ足す・引くという小さな変更で出力の変化を試しながら改善する。
情報を過剰に与えると、応答が遅くなり、トークンが増えてコストが上がり、重要な情報が埋もれる、という3つの問題が出ます。「何を渡すか」と同じくらい「何を渡さないか」を設計します。 RAG で多数ヒットしても全部渡さず、類似度の高い上位数件に絞る方が出力品質は上がります。
原因切り分けの順序
出力品質が期待を下回ったら、この順で疑います。
- 情報の欠落: 必要な情報が渡っているか。
- ノイズの混入: 関係ない情報が混ざっていないか。
- フォーマットや指示の粒度: 構造や指示が曖昧でないか。
- それでも解決しないとき、初めてモデルの変更やアーキテクチャの見直しを検討する。
たとえば「出力の口調が業務にふさわしくない」という問題なら、モデルを変えるのではなく、システムプロンプトの口調の指定を具体化するのが改善アプローチです。
この考え方を広げたものがハーネスエンジニアリングです。ハーネスは馬を正しい方向に導く手綱のことで、AI が正しく動ける環境全体の設計を指します。範囲はコンテキスト設計、データ品質管理、出力の自動チェック（期待した形式・内容・品質を満たすかを自動検証し、問題のある出力が後続に流れる前に検出する）、Human-in-the-Loop の設計、の4領域です。自動化レベルで言えば、Lv.2 ではシステムプロンプトとナレッジの設計、Lv.3 では各アクションに渡すコンテキストの設計、Lv.4 では自律的な判断を積み重ねるほど各ステップの設計精度が成果を規定します。
試験で問われる観点
- 参照した情報の種類の判別（過去の対話で得た情報＝会話の記憶、ナレッジベース検索＝外部知識 RAG）。
- コンテキストエンジニアリングとプロンプトエンジニアリングの関係（前者が上位概念）。
- 出力の口調が不適切という問題への改善アプローチ（システムプロンプトの口調指定を具体化する）。
- 出力品質が期待を下回るときの原因切り分けの順序（欠落 → ノイズ → 粒度 → モデル変更）。
- Lost in the Middle（先頭と末尾は参照されやすく、中間は見落とされる）と鮮度の原則（重要な指示は後半に）。