Knowledge Notebook
一覧に戻る

プロンプトからコンテキストエンジニアリングへ:推論モデル時代のAI指示のコツ

最近、GPT-5やClaude Fable 5といった新しいAIに、これまでのように「ステップバイステップで順を追って考えて」と長々とプロンプトを書いて指示していたのですが、どうも期待した通りの精度が出ず、返答がズレてしまうことがありました。不思議に思って調べたところ、最新の「推論モデル」では、従来のプロンプトテクニックがむしろ逆効果になるなど、常識が根本から変わっていたようです。

今回は、以前のやり方が通用しなくなった理由や、2026年現在の主流である「コンテキストエンジニアリング」の指示のコツについて、私の手元での検証結果を交えて整理しました。

1. 従来(2023〜2024)と現在(2026最新)のプロンプト手法の比較

以前は必須だったプロンプトテクニックが、最新モデルでは「むしろ不要」もしくは「精度を低下させる原因」になるケースが増えています。その違いを表にまとめました。

評価項目 以前の手法(クラシック) 現在の最新手法(2026最新)
思考プロセスの制御 (CoT) 「ステップバイステップで順を追って考えてください」 と記述し、モデルに推論ステップを踏ませるのが必須だった。 CoTの明示的指示は原則「不要」
推論モデルは内部で自律的に最善の思考ルートを選択するため、指示しすぎるとネイティブの思考ロジックを阻害し精度が低下する。
例示 (Few-shot) の扱い 期待する出力フォーマットや論理パターンを学ばせるため、複数の入出力例(Few-shot)を含めることが強く推奨された。 例示なし(Zero-shot)が基本
推論モデルは極めて優れた文脈把握力を持つため、過剰なFew-shotはかえって柔軟な思考を縛り、コンテキスト容量も無駄に消費する。
プロンプトの設計方針 欲しい回答に合わせ、プロンプト内に大量のルールや指示を書き連ねる「プロンプトエンジニアリング」が職人技とされた。 入力データを整理・削減し、最適な配置にする「コンテキストエンジニアリング」へ移行。重要な指示は最初か最後に配置して Lost in the Middle を防ぐ。

実際に o1/Claude Fable 5 で試したBefore/After比較

複雑なロジック処理を指示する際、手元で検証した具体例をご紹介します。

❌ Before:従来の指示(ステップの強要)

「配列から重複を除外するNode.jsの処理を書いてください。
まず、重複の検知方法を定義してください。次に、各要素をループで判定するステップを実行し、最後に重複なしの配列を返す関数を実装してください。
ステップバイステップで思考プロセスをすべて出力してください。」

実行結果: AIモデルは、独自の「内部思考(Thinking)」と「人間が指定した思考ステップ」が競合してしまい、回答が二重に冗長になったり、かえって非効率なループ処理をそのまま実装して出力する傾向がありました。

✅ After:現在の指示(最終ゴールと制約のみ)

<rules>
- 指示: 配列から重複を除外するNode.jsの関数を作成してください。
- 制約: メモリ効率を最優先し、O(N)の時間複雑度で実装してください。
</rules>

実行結果: AIが内部思考で「Setオブジェクトを使うのが最適」と自律的に判断し、極めてシンプルで最もパフォーマンスが良いコード(const unique = [...new Set(array)])をダイレクトに出力しました。

2. 最新の推論モデルを乗りこなす「3つのアプローチ」

2026年現在のベストプラクティスは、AIを「指示通りに動く機械」として細かく制御するのではなく、「自律思考エンジン(CPU)」として扱い、与える「データ(RAM / コンテキスト)」を最適化するというアプローチです。

① 「ステップバイステップ」は書かず、最終ゴールを明確にする

GPT-5やClaude Fable 5などの推論モデルに対しては、複雑な手順を指定するのをやめ、「何を作りたいのか(最終目標)」と「何を満たすべきか(制約条件)」をシンプルかつ明快に定義してください。AIは自身の内部思考(Thinking Budget)を使って、最も効率的な解法を自律的に探り出します。

② コンテキストの無駄を削ぎ落とし、情報の「配置」にこだわる

最新のLLMは100万〜200万トークンを超える広大なコンテキストウィンドウを持ちますが、長文の真ん中に埋もれた指示を見落としやすい「Lost in the Middle(中央情報の紛失)」という問題が依然として存在します。そのため、以下のルールに従います。

  • 最重要指示は「最初」か「最後」に置く:本文の中間に重要な命令を埋め込まない。
  • コンテキストキャッシュの活用:頻繁に再利用する大規模なデータや前提知識(コードベース、社内規定など)は前方に固定し、キャッシュを利用してコストとレスポンス時間を削減する。

③ XMLタグなどのデリミタで構造化する

指示テキストと入力データを明確に区別するため、XMLタグ(例: <context><rules><code>)を使用します。これにより、AIが「指示文」を「処理対象データ」と誤認して無視するなどのミスを防ぐことができます。

3. 実践的ユースケースとプロンプトテンプレート

2026年のトレンドを反映した、シンプルで構造的なプロンプト例を紹介します。

ユースケースA:推論モデルを活かしたコード開発・設計(自律思考の最大化)

細かな実装手順をAIに指示せず、設計のゴールと制約条件だけを提示して、AIに最適な実装方法を内部思考させます。

<rules>
- 役割: あなたはセキュリティと可読性を重視するシニアWebエンジニアです。
- 指示: 以下の <target-code> にある既存のNode.jsのコードについて、セキュリティ脆弱性の解消と並行処理の効率化を行うリファクタリングを施してください。
- 制約条件:
  - 外部のサードパーティライブラリは追加しないでください。
  - リファクタリング後のコードに加え、どのような脆弱性・非効率性をどのように改善したかを簡潔に解説してください。
</rules>

<target-code>
// ここに対象コードを貼り付ける
</target-code>

解説: 以前のプロンプトのように「まずエラーハンドリングを入れて、次に非同期処理をPromise.allにして…」といったステップをユーザー側で指示していません。GPT-5やClaude Fable 5などは、制約条件の範囲内で自律的にコードを分析し、最適な解法プロセスを組み立ててリファクタリングを行います。

ユースケースB:長文ドキュメントからのコンテキスト抽出(Lost in the Middle対策)

大規模なドキュメントから情報を抽出する際、最も重要な抽出の指示をコンテキストの後に再配置して強調します。

<context>
(数万文字におよぶ決算書や技術資料など)
</context>

<rules>
上記 <context> の内容に基づき、競合他社と比較した際の「強み」と「財務上のリスク」をそれぞれ3点ずつ抜き出し、箇条書きでまとめてください。
</rules>

解説: 大量の入力データ(context)の「後ろ」に指示(rules)を配置することで、AIの注意力を直近の指示に向かわせ、長いコンテキストを正確に処理させています。

4. 「ノリ」でのプロンプト調整から「システム的な評価」へ

最後に、2026年現在の開発プロセスでは、プロンプトをチャット欄で手動で「あれこれ微調整(Vibe-based Prompting)」することは避ける傾向にあります。

  • 評価データセットの作成:100〜500件程度の「入力と期待される出力」の検証用データセット(ゴールデンデータセット)を用意し、プロンプトの変更が全体の精度にどう影響するかをプログラムでテストします。
  • DSPyなどのフレームワークの活用:プロンプト自体を人間が書くのではなく、入力と出力の満たすべき「シグネチャ(仕様)」をコードで宣言し、プロンプトを自動最適化(コンパイル)する開発手法が定着しています。

私自身、これまで「完璧なシステムプロンプトの書き方」を模索し、指示文を何重にも推敲してきましたが、推論モデルの台頭によってその必要性は格段に減ったと実感しています。人間が思考手順を教え込もうとするのは、いわば釈迦に説法のような状態になっていたのです。

これからのAI活用は、指示を複雑にこねくり回すより、「AIに必要な前提情報(コンテキスト)をきれいに整理して配置する」ことに注力するのが賢いアプローチになりそうです。手元のプロンプトを一度見直し、AIの自律的な知能を信じたシンプルな指示を試してみるのが良さそうです。