この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAIとGoogleの現在のStructured Outputs・プロンプト設計に関する公式情報を確認し、旧版の「長いCoTや自己検証を強制すれば確実になる」という構成を、構造化入力・スキーマ・外部検証を中心に見直しました。検証ステータス：📘 OpenAI・Google公式情報確認済み／モデル横断ベンチマークは未実施
長いプレスリリース、議事録、仕様書、問い合わせ履歴をLLMへ渡すとき、精度を上げるために指示をどんどん足していくと、かえって何が重要なのか分かりにくくなることがあります。
実務では、「どう考えさせるか」より先に、「何を入力として渡し、何を出力させ、どこを機械的に検証するか」を分けて設計すると扱いやすくなります。
まず分ける：指示・元データ・出力仕様
長い入力では、少なくとも次の3種類を混ぜないようにします。
| 要素 | 内容 | 例 |
|---|---|---|
| 指示 | 何をしてほしいか | 重要な事実を最大5件抽出する |
| 元データ | 判断の根拠になる素材 | プレスリリース本文、議事録、CSV |
| 出力仕様 | 返してほしい型 | JSON Schema、enum、必須項目 |
この分離だけでも、本文中の文章を命令と誤認したり、出力形式の指定が長文に埋もれたりする事故を減らせます。
構造化入力は「見た目」ではなく境界を作る
Markdown、XML風タグ、JSONなど、形式そのものに万能な正解があるわけではありません。重要なのは、固定の指示と、毎回変わる業務データの境界が明確であることです。
<task>
プレスリリースから、明記された事実だけを最大5件抽出する。
</task>
<rules>
- 推測は含めない
- 根拠となる原文を短く保持する
- 日付が不明なら null
</rules>
<source>
...ここに分析対象本文...
</source>
この形なら、指示を毎回書き換える必要がなく、入力データだけ差し替えやすくなります。
JSONを文章だけで強制するよりStructured Outputsを使う
旧版では「必ずJSONだけを返す」「キーを絶対に欠落させない」とプロンプトで強く指定していました。しかし、API側でStructured Outputsを利用できる場合は、スキーマをプロンプト本文へ長々と書くより、APIの出力形式として定義する方が管理しやすくなります。
たとえば、業務上必要な結果を次のような型として定義します。
{
"type": "object",
"properties": {
"items": {
"type": "array",
"maxItems": 5,
"items": {
"type": "object",
"properties": {
"summary": {"type": "string"},
"category": {
"type": "string",
"enum": ["technology", "market", "partnership", "financial"]
},
"evidence": {"type": "string"},
"date": {"type": ["string", "null"]}
},
"required": ["summary", "category", "evidence", "date"],
"additionalProperties": false
}
}
},
"required": ["items"],
"additionalProperties": false
}OpenAIの現在のモデルガイダンスでも、対応モデルでは期待するスキーマを文章で説明し続けるのではなく、Structured Outputsを使うことが推奨されています。Google GeminiもJSON SchemaベースのStructured Outputsを提供しています。
スキーマに通った＝内容が正しい、ではない
ここが実務で最も重要です。Structured Outputsは、JSONの構造や型をそろえるのに役立ちますが、値の意味が正しいことまでは保証しません。
Googleの公式ドキュメントでも、スキーマに適合した出力であっても意味的に正しいとは限らないため、アプリケーション側で検証することが推奨されています。
たとえば次をアプリ側で確認する
dateが入力本文に実際に存在するかevidenceが元文章から引用・要約可能な内容か- 金額・数量・割合が元データと一致するか
- 同一内容を重複して抽出していないか
- 業務上禁止しているカテゴリーが混ざっていないか
「confidence」を自己申告させるより、確認可能な根拠を返す
旧版ではモデル自身にHigh / Medium / Lowの確信度を付けさせていました。これは補助情報にはなりますが、モデルが高い確信度を付けたから正しいとは限りません。
代わりに、根拠となる文、元データの位置、ID、日付など、人間やプログラムが確認できる情報を返させた方が再検証しやすくなります。
{
"summary": "A社とB社が共同開発契約を締結",
"category": "partnership",
"evidence": "A社はB社との共同開発契約締結を発表した",
"date": "2026-09-01"
}この形なら、あとから元文と突き合わせられます。
長文では「一発で全部やる」以外の設計も持つ
入力が大きく、抽出対象も多い場合は、1回の巨大プロンプトに全部詰め込むより、処理を分けた方が保守しやすいことがあります。
flowchart LR
A[元データ] --> B[前処理・分割]
B --> C[事実抽出]
C --> D[Structured Output]
D --> E[外部検証]
E -->|OK| F[保存・利用]
E -->|NG| G[対象箇所だけ再処理]
特に、失敗時に全文をやり直すのではなく、問題があった項目だけ再処理できるようにしておくと、コスト・再現性・原因調査の面で扱いやすくなります。
評価は「LLMに採点させる」だけにしない
LLM-as-a-Judgeは大量評価の補助に使えますが、業務要件そのものをLLMだけで判定すると、評価側にも同じ種類の誤りが入り得ます。
そこで、評価項目を分けます。
| 評価対象 | 機械的に確認 | 人・LLMで確認 |
|---|---|---|
| JSON Schema適合 | ○ | 不要 |
| 必須項目 | ○ | 不要 |
| enum違反 | ○ | 不要 |
| 元文との一致 | 一部可能 | 必要 |
| 重要情報の抽出漏れ | 難しい | 必要 |
| 業務上の有用性 | 難しい | 必要 |
「プログラムで判定できること」を先に機械で落とし、そのあと意味評価を行う方が、評価基準を説明しやすくなります。
小さな正解セットを作ってから改善する
プロンプトやモデルを変える前に、10〜50件程度でもよいので、人間が期待結果を確認した評価用データセットを用意します。
変更のたびに同じデータへ通せば、改善したつもりで別の項目が悪化していないかを確認できます。
見るべき数字は、たとえば次です。
- 必須項目欠落率
- スキーマ違反率
- 根拠なし抽出率
- 重要情報の取りこぼし率
- 1件あたりの再処理率
実務向けの最小構成
複雑な業務要件でも、最初から巨大な「最強プロンプト」を作る必要はありません。まずは次の構成で十分です。
- 目的を1文で定義する
- 入力データの境界を明確にする
- 推測可否などの業務ルールを書く
- API側でStructured Outputsを設定する
- 根拠フィールドを必須にする
- アプリ側で型・値・業務ルールを検証する
- 失敗データを評価セットへ追加する
コンテキスト設計とは、長い指示を書くことではなく、LLMが扱う情報の役割と境界を決め、結果を検証可能な形へ落とすことと考えると整理しやすくなります。
公式情報・一次情報
- OpenAI API ― Model guidance
- OpenAI API Reference ― Responses / Structured Outputs
- Google AI for Developers ― Structured outputs
この記事の更新履歴
- 2026-09-13 追加：Structured Outputs、アプリ側の意味検証、評価用データセット、再処理設計を追加。
- 2026-09-13 変更：長いCoT・自己検証を強制する設計から、入力境界・スキーマ・外部検証を中心とする構成へ変更。
- 2026-09-13 削除：内部メタデータ、重複H1、未検証表示、壊れたMarkdown、モデル自己申告の確信度を正しさの根拠にする説明を削除。
