はじめに
webベースで、生成AI（LLM）と対話していて、対話が長くなると、プロンプトを入力しても結果が変わらなかったり、期待した結果にならない場合があります。
その場合は、新しいスレッドに移行して、それまでの対話の内容をスレッドに入力すると上手くいく場合がありますが、データのコピペが面倒です。
また対話の内容を別のLLMに検証させたい場合に、最後の出力だけでなく議論のプロセス等も検証させたい場合がありますが、上記と同様にデータのコピペが面倒です。
というようなことを、生成AIと対話していたら、生成AI自身がデータ引き継ぎ用のプロンプトを作ってくれました。
そのプロンプトを別のスレッドや別の生成AIに検証・修正させた結果、下記プロンプト2種類が出来上がりました。
下記2種類はスレッドの内容を後続モデルが推論を再開するために必要な「状態・前提・結論・未解決論点」に圧縮し、Markdown又はjsonで出力するものです。
Markdown出力版は「人間可読性に優れ、人間との協調作業する場合向け」、json版は「機械可読性に優れシステム処理（完全自動化）向け」（とGeminiが言ってました）。
自分用のメモのついでに、共有。
対話内容引き継ぎ用プロンプト例（Markdown出力版）
これまでの議論を、別のスレッドやLLMでの検証・詳細設計に引き継ぐための**論理設計図**として構造化出力してください。 目的は、後続モデルが「これまでの文脈・前提・結論・未解決論点」を即座に再構築し、重複検討や前提誤認を避けて検証・設計を継続できるようにすることです。 会話履歴を時系列に要約するのではなく、後続モデルが推論を再開するために必要な**状態・前提・結論・未解決論点**に圧縮してください。 雑談、重複説明、結論に影響しない経緯は除外してください。 以下の項目について、Markdown記法かつMECE（漏れなく、重複なく）に整理してください。 --- # 0. 全体コンテキスト（目的・範囲・適用ルール） 後続モデルが議論の「方向性」と「適用ルール」を見失わないよう、以下を明記してください。 - **議論の最終目的**：プロジェクト全体のゴール、最終的なアウトプットイメージ - **適用範囲**：この議論・設計・検証が対象とする範囲 - **対象外の範囲**：意図的に扱わない範囲、除外条件 - **適用中のルール・ペルソナ**：特殊な思考モード、制約事項、出力トーンの指定など - **後続モデルが維持すべき判断軸**：品質、速度、安全性、厳密性、創造性などの優先順位 --- # 1. 議論の到達点 (Executive Summary) 後続モデルが最初に全体像を把握できるよう、現時点の到達点を簡潔に整理してください。 - **最終的に確定した結論** - **暫定的に採用している結論** - **現時点での中心論点** - **後続モデルが最初に確認すべき中核論点** ※未解決の論点や課題については、セクション6に記載してください。 ※詳細な推論過程はセクション3に記載し、本セクションでは要約に留めてください。 --- # 2. 前提条件の分類 (Assumption Map) ## 2.1 確定した前提条件 (Confirmed Constraints) これまでの議論で明示的に合意・確定した内容を整理してください。 - 事実 - 制約事項 - 境界条件 - 採用済みの定義 - 適用範囲 - 変更してはいけない前提 ## 2.2 仮置きの前提条件 (Working Assumptions) 議論を進めるために暫定採用しているが、未検証または変更可能性がある前提を整理してください。 - 仮説 - 暫定条件 - 推定値 - 暗黙の前提 - 後で検証すべき前提 ## 2.3 未確認・不足情報 (Unknowns) 現時点で不足している情報、確認不能な情報、判断保留中の情報を整理してください。 - 不足データ - 未確認の事実 - 判断に必要な追加情報 - 外部確認が必要な情報 - 原典確認が必要な情報 --- # 3. 現状の論理構造 (Logic Structure) 導き出された結論に至るまでの推論パスを整理してください。 ## 3.1 主要結論と根拠 各結論について、以下を明示してください。 - **結論** - 根拠 - 根拠種別：事実 / 推論 / 仮説 / 経験則 - 信頼度：高 / 中 / 低 - 影響度：高 / 中 / 低 - 検証要否：不要 / 要確認 / 必須 信頼度の目安： - 高：明示的な事実・合意・原典に基づく - 中：複数の前提から妥当に推論されるが、追加確認余地がある - 低：仮説・経験則・未検証情報に依存する 影響度の目安： - 高：この結論・前提が変わると、全体設計・主要判断・最終結論が大きく変わる - 中：一部の設計・判断・優先順位に影響する - 低：局所的な修正に留まり、全体構造への影響は限定的 ## 3.2 推論パス 推論フロー、状態遷移、依存関係図などの複数行構造表現は、バッククォート3つ（```）によるコードブロックで明示してください。 ```text 前提A ↓ 推論B ↓ 中間結論C ↓ 最終結論D ``` ## 3.3 重要な論理結合点 結論に大きな影響を与える論理上の接続点を抽出してください。 - **どの前提が変わると、どの結論が変わるか** - **どの推論が全体構造のボトルネックか** - **どの判断が後続設計に強く影響するか** - **どの未確認情報が確定すると、議論全体が前進するか** - **どの仮定が崩れると、再設計が必要になるか** --- # 4. 保持すべき重要データ (Reference Data) 推論・判断・設計の根拠となったデータを整理してください。 ## 4.1 数値データ - 具体的な数値 - 単位 - 算出根拠 - 使用箇所 - 信頼度 - 原典確認の要否 ## 4.2 固有名詞 - 人名 - 組織名 - 製品名 - 技術名 - プロジェクト名 - その他、後続モデルが取り違えると問題になる名称 ## 4.3 技術仕様・条件 - 技術仕様 - バージョン - 環境条件 - 入出力条件 - 制約条件 - 依存関係 - 互換性・非互換性 ## 4.4 原典・参照 - 資料名 - URL - 文献名 - 発言者 - 会話内の根拠箇所 - 原典確認の要否 - 最新情報確認の要否 ※原典・数値・固有名詞・技術仕様は、会話中に明示されたもののみ記載してください。 ※会話中に明示されていない情報を推測で補完しないでください。 --- # 5. 棄却済みの選択肢 (Rejected Options) 後続モデルが同じ検討を繰り返さないよう、検討済みだが採用しなかった案を整理してください。 各選択肢について、以下を明示してください。 - 選択肢 - 棄却理由 - 棄却時の前提 - 再検討が必要になる条件 - 再提案してはいけない理由、または再提案可能な条件 --- # 6. 未解決課題の分類 (Critical Pending Issues) 後続モデルが解決すべき「現在の課題」をリストアップし、分類してください。 具体的なアクション指示はセクション7に記載し、本セクションでは課題そのものに集中してください。 各課題について、可能な範囲で以下を付記してください。 - 優先度：高 / 中 / 低 - 影響度：高 / 中 / 低 - 依存関係：先に解決すべき前提・課題 - 放置した場合のリスク - 解決に必要な情報 ## 6.1 整合性チェック - 論理の矛盾 - 前提同士の衝突 - 結論と根拠の不整合 - 用語定義の揺れ - セクション間の矛盾 ## 6.2 自己検証 - 推論の飛躍 - 根拠不足 - 計算・数値の再確認 - 過度な一般化 - 未検証の仮説 - 信頼度が低く、影響度が高い論点 ## 6.3 高度な推論 - 複数条件のトレードオフ - システム設計上の判断 - リスク評価 - 優先順位付け - 代替案比較 - 依存関係の整理 - 判断基準の設計 ## 6.4 外部確認 - 最新情報の確認 - 原典確認 - 仕様確認 - 専門家確認が必要な事項 - 法務・医療・安全・金銭判断など、専門家確認が必要な事項 --- # 7. 後続モデルへの作業指示 (Next Model Instructions) セクション6で挙げた課題に基づき、後続モデルが「最初に」実行すべき具体的なアクションを明示してください。 ## 7.1 実行すべきこと - **最初に実行すべきタスク (To-Do)** - **絶対に変更してはいけない前提・制約** - **優先して検証・深掘りすべき論点** - **意図的に判断を保留すべき事項** - **出力時に維持すべき形式** - **追加調査が必要な項目** - **ユーザーに確認すべき不足情報** ## 7.2 実行してはいけないこと 後続モデルは、以下を行わないでください。 - 未確認情報を確定事項として扱うこと - 会話中に明示されていない数値・原典・仕様を捏造すること - 棄却済み選択肢を、再検討条件なしに再提案すること - 全体目的・適用範囲に反する方向へ論点を拡張すること - 判断保留事項を独断で確定すること - ユーザーの明示した制約・トーン・判断軸を無視すること - 一般論で埋めて、今回の議論固有の文脈を薄めること --- # 8. セクション間の記載ルール セクション間の重複を避けるため、以下のルールに従ってください。 - 同一情報は最も適切なセクションに一度だけ詳述し、他セクションでは参照に留めてください。 - セクション1には「到達点の要約」を記載し、詳細な推論過程はセクション3に記載してください。 - セクション2には「前提として使われる情報」を記載してください。 - セクション4には「根拠データとして保持すべき情報」を記載してください。 - セクション6には「未解決課題そのもの」を記載してください。 - セクション7には「未解決課題に対する具体的アクション」のみを記載してください。 - 未確認情報はセクション2.3に分類し、それが課題化している場合のみセクション6でも参照してください。 - 棄却済み選択肢はセクション5に集約し、セクション7では再提案禁止または再検討条件として参照してください。 --- # 出力制約 - 挨拶、導入文、結びの言葉は一切不要です。 - 情報密度を最大化し、後続モデルが**コンテキストの全容**を即座に再構築できる形式にしてください。 - 事実、推論、仮説、未確認事項を明確に区別してください。 - 重要な論理結合点には、**太字**を使用してください。 - 不明な情報は推測で補完せず、必ず「未確認」「不足情報」「要確認」または「該当なし」と明記してください。 - 該当情報がない項目は、推測で補完せず「該当なし」または「未確認」と明記してください。 - 原典・数値・固有名詞・技術仕様は、会話中に明示されたもののみ記載してください。 - 会話中に明示されていない情報を、もっともらしく補完しないでください。 - 出力全体を、そのままコピーできるMarkdown形式のソースコードとして**バッククォート4つ（````）のコードブロック**で囲んで出力してください。 - 推論フロー、状態遷移、依存関係図などの複数行構造表現は、バッククォート3つ（```）によるコードブロックを使用してください。 - 表を作成する際は、長いコード・疑似コードを入れず、Markdownレンダリングが崩れにくい構造にしてください。 - 見出し階層、表、箇条書き、強調表現の閉じ忘れがない形に整理してください。 - 出力は、後続モデルがそのまま検証・詳細設計に移れる完成度にしてください。
対話内容引き継ぎ用プロンプト例（JSON構造化出力版）
# 目的
これまでの議論を別のスレッドやLLMに引き継ぐため、**論理設計図**として構造化されたJSONを出力してください。後続モデルが「これまでの文脈・前提・結論・未解決論点」を即座に再構築し、重複検討や前提誤認を避けて推論を再開できるようにすることを目的とします。
# 1. 文脈抽出・分析ルール
以下の詳細な基準に従って会話履歴の深層を解析し、情報を抽出・整理してください。雑談、重複説明、結論に影響しない経緯は除外します。各項目は、後述のJSONスキーマの対応するキーに厳密にマッピングしてください。
## 1.1 全体コンテキスト (overall_context)
- **最終目的 (final_objective)**: プロジェクト全体のゴール、最終的なアウトプットイメージ。
- **適用範囲と除外 (scope / exclusions)**: この議論が対象とする範囲と、意図的に扱わない対象外の範囲。
- **ルール・ペルソナ (active_rules_and_persona)**: 適用中の思考モード、特殊な制約、出力トーンの指定。
- **判断軸 (priorities)**: 品質、速度、安全性、厳密性、創造性など、後続モデルが維持すべき優先順位。
## 1.2 議論の到達点 (executive_summary)
- **確定結論と暫定結論 (final_conclusions / provisional_conclusions)**: 最終確定した事項と、検証待ちだが暫定採用している事項の区別。
- **中核論点 (current_core_agenda / initial_checkpoints)**: 現時点での中心論点と、後続モデルが最初に確認すべき事項。
- 未解決の論点や課題の詳細は `pending_issues` に記載し、本セクションでは要約に留めてください。
## 1.3 前提条件の分類 (assumption_map)
- **確定した前提 (confirmed_constraints)**: 明示的に合意・確定した事実、制約事項、境界条件、採用済みの定義、変更してはいけない前提。
- **仮置きの前提 (working_assumptions)**: 未検証の仮説、暫定条件、推定値、暗黙の前提、後で検証すべき前提。
- **未確認情報 (unknowns)**: 現時点で不足しているデータ、判断保留中の事項、外部確認・原典確認が必要な情報。
## 1.4 現状の論理構造 (logic_structure)
- **主要結論と根拠 (key_inferences)**: 結論に至った根拠とその種別、信頼度、影響度、検証要否を指定してください。
- `evidence_type`: `fact`, `inference`, `hypothesis`, `empirical`
- `confidence`: `high`, `medium`, `low`
- `impact`: `high`, `medium`, `low`
- `validation_required`: `unnecessary`, `needs_check`, `mandatory`
- **Enum値の使用ルール**:
- スキーマ例における `"fact / inference / hypothesis / empirical"` のような表記は選択肢の列挙であり、出力時には必ずその中の単一値のみを使用してください。
- 例: `"evidence_type": "fact"` は可、`"evidence_type": "fact / inference / hypothesis / empirical"` は不可。
- 同様に、`confidence`、`impact`、`validation_required`、`category`、`priority`、`source_type`、`reproposal_policy` など、Enum指定された項目では必ず指定範囲内の単一値のみを使用してください。
- **`confidence` の判断基準**:
- `high`: 会話中で明示された事実、合意、原典、ユーザー指定に基づく。
- `medium`: 複数の明示情報から妥当に推論できるが、追加確認余地がある。
- `low`: 仮説、経験則、未検証情報への依存が大きい。
- **`impact` の判断基準**:
- `high`: 変化すると全体設計、主要判断、最終結論が大きく変わる。
- `medium`: 一部の設計、判断、優先順位に影響する。
- `low`: 局所的修正に留まり、全体構造への影響は限定的。
- **推論パス (inference_steps)**: 前提から結論に至るフローや依存関係を、ステップ順のオブジェクト配列として構造化してください。
- 各ステップには一意の識別子 `step_id` を付与してください。
- 各ステップには内容説明 `description` を記述してください。
- 各ステップには依存する先行ステップIDの配列 `depends_on` を持たせてください。
- `depends_on` において循環参照を生じさせず、有向非巡回グラフ（DAG）の構造を厳守してください。
- **重要な論理結合点 (critical_junctions)**: 「どの前提が変わると結論が変わるか」「どの未確認情報が確定すると議論が前進するか」「どの仮定が崩れると再設計が必要になるか」というボトルネック箇所を抽出してください。
## 1.5 保持すべき重要データ (reference_data)
会話中に明示された情報のみを抽出してください。推測での補完や捏造は禁止です。
- **数値データ (numerical_data)**:
- 数値ラベル
- 値
- 単位
- 算出根拠または根拠説明
- 使用箇所
- 信頼度
- 原典確認要否
- **固有名詞 (proper_nouns)**:
- 人名
- 組織名
- 製品名
- 技術名
- プロジェクト名
- その他、後続モデルが取り違えると問題になる名称
- **技術仕様・条件 (technical_specs)**:
- 技術仕様
- バージョン
- 環境条件
- 入出力条件
- 制約条件
- 依存関係
- 互換性・非互換性
- **原典・参照 (sources)**:
- 資料名
- URL
- 出典種別
- 会話内・文書内の該当箇所
- 検証済みかどうか
- 最新情報確認要否
- **原典確認と最新性確認の区別**:
- `source_check_required` は、数値・主張・仕様などについて、原典または根拠の確認が必要かどうかを示します。
- `requires_latest_check` は、情報が時間経過により変化しうるため、最新情報の確認が必要かどうかを示します。
- 両者を混同しないでください。原典確認が必要でも最新性確認が不要な場合、またはその逆の場合があります。
## 1.6 棄却済みの選択肢 (rejected_options)
後続モデルが同じ検討を繰り返さないよう、採用しなかった案を整理してください。
各棄却案には以下を含めてください。
- 採用しなかった案 (`option`)
- 棄却理由 (`reason`)
- 棄却時に成立していた前提 (`rejected_under_assumptions`)
- 再検討が必要になる条件 (`reconsideration_condition`)
- 再提案ポリシー (`reproposal_policy`)
- `never`
- `allowed_if_conditions_change`
- `needs_user_confirmation`
## 1.7 未解決課題 (pending_issues)
現在抱えている課題を抽出し、以下の情報を付与してください。
- 課題内容 (`issue`)
- カテゴリ (`category`)
- `consistency`
- `logic`
- `advanced_reasoning`
- `external_check`
- 優先度 (`priority`)
- `high`
- `medium`
- `low`
- 影響度 (`impact`)
- `high`
- `medium`
- `low`
- 依存関係 (`dependencies`)
- 放置した場合のリスク (`risk_if_ignored`)
- 解決に必要な情報 (`required_info`)
`priority` は「処理順・緊急度」、`impact` は「結論・設計・判断への影響度」として区別してください。
## 1.8 後続への作業指示 (next_instructions)
- **To-Do (to_do)**: 上記課題に基づき、後続が最初に実行すべき具体的タスク。
- **制約 (constraints)**: 絶対に維持すべき条件、変更してはいけない前提、出力形式、判断軸。
- **禁止事項 (prohibitions)**: 未確認情報の確定化、情報捏造、棄却済み案の無条件再提案、適用範囲外への拡張、独断での判断確定など、実行してはいけないこと。
`constraints` と `prohibitions` は混同しないでください。
- `constraints`: 維持すべき条件
- `prohibitions`: 禁止される行為
# 2. 出力フォーマット（絶対構造）
上記で抽出した情報を、以下のJSONスキーマに厳格にマッピングしてください。キーの変更・削除は認めません。
ただし、スキーマ内に定義された配列・オブジェクトの各プロパティは必ず保持してください。
```json
{
"overall_context": {
"final_objective": "最終的なゴールとアウトプットイメージ",
"scope": "議論の対象範囲",
"exclusions": "意図的に除外した範囲",
"active_rules_and_persona": "適用中の思考モードや制約事項",
"priorities": "品質・速度・安全性等の判断軸"
},
"executive_summary": {
"final_conclusions": ["確定した結論のリスト"],
"provisional_conclusions": ["暫定採用している結論"],
"current_core_agenda": "現在の中核論点",
"initial_checkpoints": ["後続が最初に確認すべき点"]
},
"assumption_map": {
"confirmed_constraints": ["合意済みの事実・制約"],
"working_assumptions": ["未検証の仮説・推定値"],
"unknowns": ["不足データ・要確認事項"]
},
"logic_structure": {
"key_inferences": [
{
"conclusion": "結論",
"evidence": "根拠",
"evidence_type": "fact",
"confidence": "high",
"impact": "high",
"validation_required": "unnecessary"
}
],
"inference_steps": [
{
"step_id": "step_1",
"description": "前提・事実",
"depends_on": []
},
{
"step_id": "step_2",
"description": "推論",
"depends_on": ["step_1"]
}
],
"critical_junctions": ["前提が変わると全体が崩れるボトルネック箇所"]
},
"reference_data": {
"numerical_data": [
{
"label": "数値データの名称",
"value": "値",
"unit": "単位",
"basis": "算出根拠または根拠説明",
"used_in": "この数値が使われた判断・推論・設計箇所",
"confidence": "high",
"source_check_required": true
}
],
"proper_nouns": ["固有名詞"],
"technical_specs": ["技術仕様・バージョン・制約"],
"sources": [
{
"title": "資料名・文献名・発言名",
"url": null,
"source_type": "conversation",
"locator": "会話内・文書内・資料内の該当箇所",
"is_verified": true,
"requires_latest_check": false
}
]
},
"rejected_options": [
{
"option": "棄却案",
"reason": "棄却理由",
"rejected_under_assumptions": ["棄却時に成立していた前提"],
"reconsideration_condition": "再検討条件",
"reproposal_policy": "allowed_if_conditions_change"
}
],
"pending_issues": [
{
"issue": "未解決課題",
"category": "consistency",
"priority": "high",
"impact": "high",
"dependencies": ["先に解決すべき前提・課題"],
"risk_if_ignored": "放置した場合のリスク",
"required_info": "解決に必要な情報"
}
],
"next_instructions": {
"to_do": ["最初に実行すべき具体的タスク"],
"constraints": ["絶対に変更してはいけない前提・維持すべき条件"],
"prohibitions": ["実行してはいけないこと"]
}
}
```
# 3. 出力制約（重要）
## 3.1 出力形式
- 挨拶、解説、導入文、結びの言葉は一切出力しないでください。
- 出力全体は、**バッククォート4つ（````json）で囲んだ単一のJSONコードブロックのみ**にしてください。
- JSONコードブロックの外側には、いかなる文字も出力しないでください。
- 出力は、1つの有効なJSONオブジェクトとしてください。
## 3.2 データ密度
- 推論に必要な「状態・前提・結論・未解決課題」に情報を圧縮してください。
- 雑談、重複説明、結論に影響しない経緯は除外してください。
- 会話履歴を時系列に要約するのではなく、後続モデルが推論を再開するための状態表現として整理してください。
## 3.3 重複排除
- 同一の前提、課題、データ等は最も適切な箇所に一度だけ詳述してください。
- 他の箇所では、必要に応じて `step_id`、キー名、項目名などで参照してください。
- JSON内で同じ情報を複数箇所に重複して詳述しないでください。
- 未確認情報は `assumption_map.unknowns` に分類し、それが課題化している場合のみ `pending_issues` でも参照してください。
- 棄却済み選択肢は `rejected_options` に集約し、`next_instructions.prohibitions` では再提案禁止または再検討条件として参照してください。
## 3.4 論理の非巡回性
- `logic_structure.inference_steps` の `depends_on` に循環参照を生じさせないでください。
- 依存関係は必ず有向非巡回グラフ（DAG）として成立させてください。
- あるステップが自分自身に依存してはいけません。
- 相互依存、循環依存、後続ステップへの逆依存を避けてください。
## 3.5 誠実性
- 会話中にない情報を捏造してはいけません。
- 会話中に明示されていない数値、原典、仕様、固有名詞をもっともらしく補完してはいけません。
- 不明な情報、該当する情報がない項目、判断不能な点は、推測で埋めず `null` または空配列 `[]` としてください。
- 情報が存在するが検証未了の場合は、内容を断定せず、対応する `confidence`、`validation_required`、`source_check_required`、`requires_latest_check` などのフィールドで検証状態を示してください。
## 3.6 `null` と `[]` の使い分け
- 単一値の不明・未特定は `null` としてください。
- 配列項目で該当情報がない場合は `[]` としてください。
- オブジェクト配列で該当情報がない場合は `[]` としてください。
- 文字列フィールドに `"未確認"`、`"該当なし"`、`"不明"` などを安易に入れず、原則として `null` を使用してください。
- ただし、会話中でユーザーが明示的に「未確認」「該当なし」等の表現を使っている場合は、その文脈を保持するために文字列として記録してもかまいません。
## 3.7 言語
- JSONのキーは英語のスネークケースを維持してください。
- 指定された列挙型（Enum）の値は英語のまま維持してください。
- その他の値（Value）は日本語で記述してください。
## 3.8 Markdown装飾の排除
- JSONの値（Value）の中に、太字、見出し、箇条書き記号、MarkdownリンクなどのMarkdown特有の装飾を含めないでください。
- 値はプレーンな文字列、数値、真偽値、`null`、配列、オブジェクトとして記述してください。
## 3.9 JSON文字列のエスケープ処理
- 文字列の値（Value）の中にダブルクォーテーション（`"`）、バックスラッシュ（`\`）、改行、タブなど、JSON構文に影響する文字を含める場合は、必ず適切にエスケープしてください。
- ダブルクォーテーションは `\"` としてエスケープしてください。
- バックスラッシュは `\\` としてエスケープしてください。
- 改行は、必要に応じて `\n` としてエスケープしてください。
- タブは、必要に応じて `\t` としてエスケープしてください。
- 複数行のコード、ログ、引用文、プロンプト断片を値に含める場合も、JSONとしてパース可能な単一の文字列になるようにエスケープしてください。
- エスケープ処理が複雑になりJSON構文エラーのリスクが高い場合は、原文全体を無理に保持せず、推論に必要な要点へ圧縮して記述してください。
## 3.10 構文検証
- カンマの抜け、余分なカンマ、括弧の不整合、引用符の不足、エスケープ漏れがないか確認してください。
- JSONとしてパース可能であることを最優先してください。
- 最終出力前に、以下を自己確認してください。
- 単一のJSONオブジェクトである
- コードブロック外に文字がない
- 必須キーがすべて存在する
- キー名がスキーマと一致している
- Enum値が指定範囲内の単一値である
- Enum列挙表記をそのまま値として出力していない
- `confidence` と `impact` が定義済み基準に従っている
- `source_check_required` と `requires_latest_check` を混同していない
- `depends_on` に循環参照がない
- 不明情報が推測で補完されていない
- Markdown装飾がJSON値に混入していない
- 文字列値に含まれるダブルクォーテーション、バックスラッシュ、改行、タブが適切にエスケープされている
