この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAIとGoogleの現在のプロンプト設計・構造化出力に関する公式ドキュメントを確認し、旧版の「推論過程を必ずJSONで出させる」設計を、現在のLLMで使いやすい評価・検証中心の構成へ見直しています。検証ステータス：📘 OpenAI・Google公式情報確認済み／モデル横断ベンチマークは未実施
CoT（Chain-of-Thought）プロンプティングで一番気を付けたいのは、長い推論を書かせること自体を「正しさの保証」にしないことです。
現在のLLMでは、モデルによっては詳細な手順を毎回指定するより、目的・成功条件・使ってよい情報・出力形式を明確にし、最終結果をプログラム側で検証する方が安定する場面があります。
そのため実務では、「もっと考えて」と何度も指示するより、失敗の種類を分けて、どこをプロンプトで直し、どこを外部処理で検証するかを決める方が再現しやすくなります。
まず試す：推論全文ではなく「答え＋確認材料」を返させる
たとえば、計算結果を機械処理したい場合、内部の思考過程を長く出力させる代わりに、最終回答と短い確認材料だけを要求します。
次の問題に答えてください。
問題:
2023年の値が15.4で、前年より0.2増えています。
2022年の値はいくつですか。
出力条件:
- answer: 最終回答
- check: 答えを確認できる短い式または根拠
- status: ok / insufficient_information のどちらか
- 指定した3項目以外は出力しない
期待する出力のイメージは次のようになります。
{
"answer": 15.2,
"check": "15.4 - 0.2 = 15.2",
"status": "ok"
}ここで見るのは「長い推論を書いたか」ではありません。形式が守られたか、計算結果が正しいか、必要な情報が足りないときに無理に答えていないかです。
CoT系プロンプトで起きやすい5つの失敗
| 失敗 | 見え方 | 主な対策 |
|---|---|---|
| 最終回答が誤る | 説明はもっともらしいが答えが違う | 既知の正解、計算、一次情報で外部検証する |
| 形式が崩れる | JSONの前後に説明文が付く、キーが変わる | Structured Outputs / JSON Schema等を使い、パーサーでも検証する |
| 質問から脱線する | 背景説明が増え、必要な答えが埋もれる | 目的・成功条件・不要な出力を明記する |
| 指示を詰め込みすぎる | 条件同士が衝突し、一部だけ守られる | 必須条件を減らし、必要なら処理を複数段に分ける |
| 自己評価を過信する | 高いconfidence値でも答えが誤っている | モデル自身の点数ではなく、外部ルール・テスト・人手で確認する |
「ステップバイステップ」を常に足せばよいわけではない
旧版では、ゼロショットCoT、Few-shot CoT、制約付きCoTと段階的に指示を増やす構成にしていました。
この考え方が役立つ場面はありますが、現在の推論機能を持つモデルでは、人間が細かな思考手順を固定しすぎると、かえってモデルが選べる解法を狭めることがあります。
OpenAIの現在のモデルガイダンスでも、期待する成果・成功条件・制約を明確にしつつ、正確な手順そのものが要件でない場合は、不要なステップ指定を減らす考え方が案内されています。Googleのプロンプト設計ガイドでも、Thinking機能を使う場合は、まず細かなstep-by-step指示を与えずに試すことが推奨されています。
出力形式は「プロンプトだけ」で守らせない
「必ずJSONだけを返して」と書いても、すべてのケースで形式が守られるとは限りません。
APIがStructured OutputsやJSON Schemaを提供しているなら、出力形式はAPI側でも制約し、そのうえでアプリ側でも値を検証します。
GoogleのStructured Outputドキュメントでも、構文上正しいJSONが返っても、値の意味まで自動的に正しいとは限らないため、アプリケーション側での検証とエラー処理が必要とされています。
最小の検証コード
import json
def validate_result(text: str, expected_answer: float):
try:
data = json.loads(text)
except json.JSONDecodeError as e:
return False, f"JSONエラー: {e}"
required = {"answer", "check", "status"}
missing = required - data.keys()
if missing:
return False, f"不足キー: {sorted(missing)}"
if data["status"] != "ok":
return False, "モデルが回答不能と判定"
try:
actual = float(data["answer"])
except (TypeError, ValueError):
return False, "answerが数値ではありません"
if abs(actual - expected_answer) > 1e-9:
return False, f"期待値と不一致: {actual}"
return True, "OK"
この例では、モデルが「自信があります」と言っているかは採点に使っていません。機械的に確認できるものは機械で確認する、という役割分担です。
失敗したら、まず原因を分類する
| 検出した問題 | 次の一手 |
|---|---|
| JSONとして読めない | 構造化出力機能を使う。利用できない場合は出力例と禁止する余分な文章を明確化 |
| 必須キーがない | Schemaでrequiredを指定。プロンプトだけでなく受信側でも検査 |
| 答えが違う | 正解データ、計算ツール、検索・DBなど別の検証経路を使う |
| 質問から逸脱 | 目的と成功条件を短く書き直す。不要な役割・背景指示を削る |
| 何度直しても不安定 | 処理を分割する、モデルを変える、人間レビューへフォールバックする |
プロンプト→評価→改良を分けて考える
flowchart TD
A[目的と成功条件を決める] --> B[モデルへ入力]
B --> C[最終出力]
C --> D{外部検証}
D -->|合格| E[利用する]
D -->|形式エラー| F[Schema・形式条件を修正]
D -->|内容エラー| G[根拠・入力・モデル・処理分割を見直す]
F --> B
G --> B
このループで大事なのは、プロンプト改善と評価を同じものにしないことです。
プロンプトはモデルに何をしてほしいかを伝える役割、評価は出力が業務要件を満たしたかを判定する役割です。評価を独立させると、モデルやプロンプトを変えたときも比較できます。
仕事で使うなら「正解セット」を先に作る
社内FAQ、分類、要約、データ抽出などでプロンプトを改善するときは、数件の感触だけで決めず、代表的な正例・難例・情報不足・境界ケースを小さな評価セットとして残しておくと便利です。
- 正解した件数
- 形式エラー件数
- 回答不能を正しく選べた件数
- 人間レビューが必要だった件数
- 平均処理時間・トークン量
「プロンプトが賢そうになった」ではなく、失敗率が本当に下がったかで判断できるようになります。
まとめ
CoTプロンプティングの失敗を抑えるには、推論文章を長くすることよりも、成果物の定義・構造化出力・外部検証・失敗分類・評価セットを組み合わせる方が実務では扱いやすくなります。
特に現在の推論モデルでは、細かな思考手順を毎回強制するのではなく、まず目的と成功条件を明確にし、必要なときだけ手順を追加する設計を試す価値があります。
公式情報・一次情報
- OpenAI API ― Model guidance / Prompting best practices
- Google AI for Developers ― Structured outputs
- Google Cloud ― Overview of prompting strategies
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月13日
- 追加 現在のOpenAI・Google公式ガイダンスを確認し、Structured Outputs、外部検証、評価セットを使った実務的な失敗抑制方法を追加しました。
- 変更 推論過程を必ずJSONへ出力させる構成から、最終回答と確認可能な材料を返し、アプリ側で検証する構成へ全面的に見直しました。
- 変更 長いCoTを強制することを前提とせず、目的・成功条件を明確にしてモデルごとの推論機能を活用する現在向けの説明へ更新しました。
- 削除 公開本文へ混入していた内部META、本文内の重複H1、Markdown崩れ、未検証表記、および「シミュレートされた情報源」を含む旧参考文献を削除しました。
