プロンプトに検証可能な出力形式を定義する

著者: AILesson6 分でセットアップテスト済み:ChatGPTレビュー日: 2026-08-28

クイック回答

曖昧な出力要望を、フィールド、型、状態、制約、検証ルールに変換する. 入力するもの: プロンプトのタスクと下流での用途, 現在の出力要件と例, 形式と検証の制約. 期待される結果: スキーマ、人が読める例、空の状態、検証チェックを含む出力契約.

コンテキストを追加

テキストはこのブラウザ内に留まります。AILesson Prompts は、そのテキストをモデルやサーバーに送信しません。

プロンプトのタスクと下流での用途現在の出力要件と例形式と検証の制約

あなたのプロンプト

未入力のフィールドはプレースホルダーとして表示されたままなので、プロンプトをコピーして編集できます。

プロンプトのタスクに対して、検証可能な出力契約を設計してください。

入力、変換、読者／システム、判断、失敗した場合の影響：
[task]

現在の形式指定、望ましい例、却下された出力、使用されるフィールド：
[output]

シリアライズ形式、パーサーの制限、長さ、ロケール、順序、必須／任意フィールド、レビュー：
[constraints]

下流での用途を満たす最小の出力構造を定義してください。各フィールドについて、名前、目的、型、必須かどうか、許可値またはパターン、単位、証拠へのリンク、不明／空を表す方法、フィールド間ルールを指定します。データと解説、機械処理用フィールドとレビュアーのメモを分けてください。互いに両立しない形式、装飾目的のセクション、解析対象フィールド内の文章を求めてはいけません。必要な場合は決定論的な順序を指定します。`null`、空文字列、`0`、`false`、`unknown` を同じ意味で使ってはいけません。次の内容を返してください：出力設計の根拠、正式なスキーマまたは表形式のスキーマ、プロンプトに追加する厳密な条項、有効な完全例、有効な空／不明の例、理由付きの無効例、検証チェックリストまたは擬似コード、機械的に検証できず人によるレビューが必要なフィールド。

Playgroundで試す

デフォルトで非公開プロンプトの組み立てはブラウザ内で行われます。組織が許可しない限り、機密情報を AI サービスに入力しないでください。

入力から結果へ

具体例

具体的なコンテキストを加えると、このレシピが実用的な結果になる様子をご覧ください。

実際の入力

プロンプトのタスクと下流での用途: 会議の文字起こしから、明示的な約束事項を抽出します。ワークフローは結果をタスクレビュー画面へ取り込みますが、タスクを自動作成しません。レビュアーには、アクション、担当者、期限、状態、証拠の位置が必要です。担当者や日付が欠けている場合は、その欠損を明示しなければなりません。提案は約束事項として扱いません。担当者の誤りや期限の創作は、説明責任上のリスクになります。
現在の出力要件と例: 現在の指示は「整った構造化リストを提示してください」とだけ記載されています。望ましい出力は、約束事項ごとに1行を使い、タイムスタンプを付けたものでした。却下された出力では、要約と箇条書きが混在し、期限に「soon」を使い、担当者が不明な場合に owner を省略していました。レビュアーは priority や sentiment を使用しません。
形式と検証の制約: 厳格な JSON とし、Markdown のコードフェンスや追加の文章は含めません。パーサーは UTF-8 の JSON 配列を受け付けます。正確な暦日が明記されている場合に限り、ISO 8601 形式の日付を使います。スナップショット用に必須キーの順序を固定します。status の値は `proposed`、`confirmed`、`completed`、`cancelled` です。evidence には speaker と timestamp を含めます。約束事項の分類と人物の同一性は人がレビューします。

出力例

設計：明示的な約束事項1件につき配列要素を1つ使用し、要約、priority、sentiment は含めません。不明な owner／日付には null を使います。欠損自体に意味があるためです。空文字列は無効です。「Soon」は evidence に残しますが、due_date には入力できません。

スキーマ：action は必須の空でない string。owner は必須キーで、string|null。due_date は必須キーで、string|null、日付は YYYY-MM-DD 形式のみ。status は必須の enum。evidence は必須の object で、空でない string の speaker、HH:MM:SS 形式の timestamp、200文字以下の空でない string の excerpt を含みます。キー順序：action、owner、due_date、status、evidence。フィールド間ルール：status が completed の場合、完了したという発言の evidence が必要です。evidence に正確な日付が含まれる場合を除き、due_date は null にします。

プロンプトに追加する厳密な条項：「UTF-8 の JSON 配列だけを返してください。明示的な約束事項1件を1つの object とし、キーは action、owner、due_date、status、evidence の順に並べます。担当者または正確な期限が明記されていない場合は null を使い、キーを省略したり、相対的な表現を日付に変換したりしないでください。status は proposed、confirmed、completed、cancelled のいずれかにします。evidence には speaker、HH:MM:SS 形式の timestamp、200文字以下の情報源からの excerpt を含めます。明示的な約束事項がない場合は [] を返します。文章や Markdown を追加してはいけません。」

有効例：[{"action":"Send the revised budget","owner":"Nora","due_date":null,"status":"confirmed","evidence":{"speaker":"Nora","timestamp":"00:14:22","excerpt":"I’ll send the revised budget soon."} }]。有効な空の結果：[]。無効例：due_date に "soon" を指定すると ISO 形式のルールに違反します。owner を省略すると必須キールールに違反します。人によるレビューでは、この excerpt が約束事項に該当するか、また「Nora」が正しい人物に対応しているかを引き続き確認します。

これがうまくいく理由

1
型付きフィールドと明示的な空の状態によって、出力品質を観察可能なルールに変えられます。
2
フィールド間の検証により、形式は整っていても内部で矛盾する出力を検出できます。

結果を確認

すべてのフィールドが、下流での実際の判断、表示、チェックのいずれかに役立っていますか？
不明、欠損、該当なし、ゼロという値を曖昧さなく区別できますか？
機械的なチェックと人による判断の責任範囲を区別できますか？

安心して使うために

よくある質問

このレシピをいつ使うか、何を用意するか、どの場面で人による確認が依然として重要かについての実践的な回答です。

「プロンプトに検証可能な出力形式を定義する」を使用する前に、何を準備すればよいですか？

「プロンプトに検証可能な出力形式を定義する」を使用するには、プロンプトのタスクと下流での用途、現在の出力要件と例、形式と検証の制約を準備してください。プレースホルダーは、確認可能な情報だけで置き換えます。詳細が不明な場合は、モデルに推測させず、不明であることを明示してください。

「プロンプトに検証可能な出力形式を定義する」の結果は、どのような場合にまだ使用できませんか？

提示された証拠から、記載された成果である「スキーマ、人が読める例、空の状態、検証チェックを含む出力契約」をまだ作成できていない場合や、未解決の前提、承認の不足、創作した詳細に依存している場合、その結果は使用できません。チェック項目を公開可否の判断基準として使い、裏付けのない出力を磨くのではなく、元の入力を修正するか、権限を持つ担当者を指名してレビューを依頼してください。

「プロンプトに検証可能な出力形式を定義する」では、どの AI ツールのテスト記録がありますか？

2026-08-28 時点で、「プロンプトに検証可能な出力形式を定義する」の公開テスト記録には ChatGPT が掲載されています。これは実行記録があることを示すだけで、今後の製品バージョンとの互換性や同一の結果を保証するものではありません。別のツールやバージョンでは、すべての制約を明示したまま、使用前に結果のチェック項目をもう一度確認してください。

さらに探す方法