# 検証に使った指示文

記事「ハルシネーション対策を測った」（https://debatecross.com/notes/hallucination-cross-critique ）の検証で、各段階の AI に渡した指示文です。お題・ファクトシート・主張などの入力は省いています（入力の形は各指示文の中に書いてあります）。作業環境に関する記述は除いています。

## 指示文の版について

採点（3）と一次情報での裁定（5）の指示文には、検証の途中（2026 年 10 月 4 日）に「原則と例外」「否定形・不存在」の 2 つの節を書き足しました。両方の版の全文を載せています（書き足す前の版は、この 2 節が無いことだけが違い、ほかの文言は同じです）。どの判定でどの版を使ったかは次のとおりです。

| 段階 | 2 節とも無い版 | 「原則と例外」だけを足した版 | 2 節とも足した版 |
| ---- | -------------- | ---------------------------- | ---------------- |
| 3. 採点 | 1・2 回目の、関門の前から続く 10 テーマ（20 討論） | 1・2 回目の差し替えた 5 テーマ（10 討論）の一部の束と、3 回目の Claude の 1 束 | 1・2 回目の差し替えた 5 テーマの残りの束と、3 回目（15 討論）の残り |
| 5. 一次情報での裁定 | 1・2 回目の 10 テーマで、採点が割れた主張などの最初の裁定 | 「原則と例外」に関わる主張の裁定し直し（20 件） | それ以外のすべての裁定（「〜ない」型の主張の裁定し直し 201 件、見落としの推定の抽出、追加分解した主張を含む） |

人の判定は、すべて 2 節の基準で行いました。最終的に「誤り」とされた主張は、すべて 2 節の基準で見直しています（6.）。

## 0. 指示つき単体回答に足した指示

Round 1 と同じお題の指示文の前に、system メッセージとして付けた。

```text
回答にあたっては次を守ってください。
- 制度名・条文番号・日付・数値・名称は、確実に知っているものだけを断定し、不確かなものは「確認が必要」と明示する。
- 存在が確認できない制度・法律・技術については、存在を前提に説明せず「確認できない」と述べる。
- 推測と事実を分け、根拠（一次情報の種類）を示せる範囲で示す。
- 読者が誤って理解しうる重要事項（適用対象・経過措置・例外）を落とさない。
```

## 1. 主張の分解

Codex（GPT-5.6 Sol）。解説文を 1 文 1 事実の主張に分ける。文章の著者・条件は伏せる。

<details><summary>指示文の全文</summary>

### 解説文の主張分解（バッチ batch-extract-01）

#### 目的

AI が書いた解説文を「検証可能な原子的主張」のリストに分解する。後工程で各主張を複数ベンダーが事実確認する。

#### 絶対に守ること

- 1 つの主張には 1 つの事実だけを含める（「A は 2019 年に開始され、対象は B である」→ 2 つに分ける）。
- 代名詞や省略を補い、文章を見なくても意味が分かる自己完結した 1 文にする。
- 意見・推奨・一般論（「〜が望ましい」「〜に注意すべき」）は含めない。
- 存在が疑わしい事物について「存在する」「〜と定められている」と断定している記述は、**そのまま主張として取り出す**（捏造の検出に使う）。
- 原文の順序を保ち、重複は 1 つにまとめる。1 文章あたり最大 40 件。
- 真偽の判定はしない（それは次の工程）。

#### 入力

著者モデル・条件は伏せてある（`key` はハッシュ）。

#### 出力

**JSONL を ```jsonl フェンスで 1 ブロック**に書く。1 item につき 1 行（`claims` 配列を 1 行に収める）。`grader` は `openai/codex`。

```jsonl
{"kind":"claims","key":"<item.key をそのまま>","grader":"openai/codex","claims":[{"id":"c01","text":"インボイス制度は 2023 年 10 月 1 日に開始された。"},{"id":"c02","text":"適格請求書発行事業者の登録番号は T と 13 桁の数字で構成される。"}]}
```

</details>

## 2. 追加分解（分解の上限に達した文章）

Codex（GPT-5.6 Sol）。最初の分解に含まれない主張だけを、上限なしで取り出す。

<details><summary>指示文の全文</summary>

### 解説文の主張分解（追加分）

#### 目的
AI が書いた解説文を「検証可能な原子的主張」に分解する作業の**追加分**です。各文章について、すでに取り出した主張（`existing`）があります。最初の分解は 1 文章あたり 40 件までに制限していたため、文章の一部が主張になっていません。**`existing` に含まれていない主張だけを、件数の上限なしで**追加で取り出してください。

#### 絶対に守ること（最初の分解と同じ規則）
- 1 つの主張には 1 つの事実だけを含める（「A は 2019 年に開始され、対象は B である」→ 2 つに分ける）。
- 代名詞や省略を補い、文章を見なくても意味が分かる自己完結した 1 文にする。条件・但し書き・主語（誰が・何について）を落とさない。列挙（「A・B・C の 3 分野に限定」）は 1 つの主張のまま保つ。
- 意見・推奨・一般論（「〜が望ましい」「〜に注意すべき」）は含めない。
- 存在が疑わしい事物について「存在する」「〜と定められている」と断定している記述は、そのまま主張として取り出す。
- 原文の順序を保つ。`existing` と同じ内容（言い換えを含む）は出さない。
- 真偽の判定はしない。
- 追加する主張がなければ、`claims` を空の配列にする。

#### 出力
JSONL を ```jsonl フェンスで 1 ブロックに書く。1 文章につき 1 行（`claims` 配列を 1 行に収める）。
```jsonl
{"key":"<key をそのまま>","claims":[{"id":"s01","text":"…"},{"id":"s02","text":"…"}]}
```
計画の提示や承認待ちはせず、直ちに結果を出力すること。ファイルは作らない・変更しない。ウェブは参照しない。

</details>

## 3. 採点（ファクトシートとの照合）

Codex（GPT-5.6 Sol）・Antigravity（Gemini 3.7 Flash）・Claude Code（Claude Sonnet）が独立に行う。ウェブは使わない。文章の著者・条件は伏せる。

<details><summary>指示文の全文（書き足したあとの版）</summary>

### 主張の事実確認（バッチ batch-verify-01）

#### 目的

AI 討論の効果測定で、解説文から取り出した「主張」1 つ 1 つを、テーマごとのファクトシートと照合して判定する。
あなたは複数ベンダーの採点者の 1 人で、判定は多数決と人手裁定に使われる。**コードは書かない・変更しない。**

#### 絶対に守ること

- ファクトシートを正解の基準にする。ファクトシートに無い事柄は、あなたが確実に判断できる場合だけ
  `correct` / `incorrect` にし、確実でなければ `unverifiable`。推測で白黒つけない。
- 主張ごとに独立に判定する（同じ文章の他の主張の印象に引きずられない）。
- 文章の著者モデル・条件（単体回答か討論か）は意図的に伏せてある（`key` はハッシュ）。推測して判定に使わない。

#### 入力

- `key`: 文章の識別子（**そのまま出力に書き写す**）
- `topicPrompt`: 元のお題
- `trap`: true なら「存在しない事物」を問うテーマ
- `facts[]`: ファクトシート（`id` / `statement` / `severity: major|minor`）
- `claims[]`: 判定する主張（`id` / `text`）

#### 判定基準

| label | 意味 |
| ----- | ---- |
| `correct` | ファクトシートまたは確実な知識と一致する |
| `incorrect` | ファクトシートまたは確実な知識と矛盾する（数値・日付・名称の誤り、捏造を含む）。`severity` を `major`（制度や技術の理解を誤らせる）/ `minor`（細部）で付ける |
| `unverifiable` | 真偽を確認できない |
| `out_of_scope` | 主題と無関係・評価対象外（意見・一般論など） |

### 「原則と例外」の扱い（全採点者共通・2026-10-04 明文化）
- 主張が制度・規格の**原則**を正しく述べていれば、例外・特例・ただし書きに触れていなくても `correct`。
- `incorrect` にするのは、(1) 例外の存在を明示的に否定している（「必ず」「例外なく」「すべての」など）、
  (2) 主張自体が例外・特例について述べていて内容が誤っている、(3) 例外のほうが一般的で原則として述べた内容が実態と食い違う、の場合だけ。
- 「例外があるので正しいとは言えない」という理由だけで `incorrect` にしない（必要なら `note` に例外を書く）。

### 否定形・不存在の主張（全採点者共通・2026-10-04 明文化）
- 実在する事物について「〜はない」「〜できない」「〜は義務ではない」と述べる主張は、ファクトシートまたは確実な知識で「ない」ことが確かめられる場合だけ `correct`。裏付けが無いだけなら `unverifiable`（証拠がないことは、ないことの証拠ではない）。
- 存在しない事物を主語・目的語にした否定（例:「X は Y の出典ではない」）、推測・可能性、解釈・評価・背景や動機の説明で真偽が一意に決まらないものは `out_of_scope`。

`factIds` には根拠にしたファクトシート項目の id（無ければ空配列）。`note` は短い根拠。

さらに文章ごとに、ファクトシートの**各項目**について文章全体が `covered`（正しく言及）/ `contradicted`（矛盾する記述がある）/
`missing`（言及なし）のどれかを返す。`trap: true` のテーマでは、文章がその事物の存在を前提に説明していれば
`assertsExistence: true`、「存在しない／確認できない」と述べていれば `false`。それ以外のテーマでは `null`。

次の形式の **JSONL を ```jsonl フェンスで 1 ブロック**に書く（1 行 1 JSON。説明文はブロックの外に）。
`grader` は必ず `openai/codex`。item ごとに「主張の数 ＋ facts の数」行になる。

```jsonl
{"kind":"verdict","key":"<item.key をそのまま>","grader":"openai/codex","claimId":"c01","label":"correct","severity":null,"factIds":["t01-f01"],"note":"開始日が一致"}
{"kind":"verdict","key":"<item.key をそのまま>","grader":"openai/codex","claimId":"c02","label":"incorrect","severity":"minor","factIds":["t01-f03"],"note":"13 桁が正しい"}
{"kind":"coverage","key":"<item.key をそのまま>","grader":"openai/codex","factId":"t01-f01","status":"covered","assertsExistence":null}
{"kind":"coverage","key":"<item.key をそのまま>","grader":"openai/codex","factId":"t01-f02","status":"missing","assertsExistence":null}
```

</details>

<details><summary>指示文の全文（書き足す前の版）</summary>

### 主張の事実確認（バッチ batch-verify-01）

#### 目的

AI 討論の効果測定で、解説文から取り出した「主張」1 つ 1 つを、テーマごとのファクトシートと照合して判定する。
あなたは複数ベンダーの採点者の 1 人で、判定は多数決と人手裁定に使われる。**コードは書かない・変更しない。**

#### 絶対に守ること

- ファクトシートを正解の基準にする。ファクトシートに無い事柄は、あなたが確実に判断できる場合だけ
  `correct` / `incorrect` にし、確実でなければ `unverifiable`。推測で白黒つけない。
- 主張ごとに独立に判定する（同じ文章の他の主張の印象に引きずられない）。
- 文章の著者モデル・条件（単体回答か討論か）は意図的に伏せてある（`key` はハッシュ）。推測して判定に使わない。

#### 入力

- `key`: 文章の識別子（**そのまま出力に書き写す**）
- `topicPrompt`: 元のお題
- `trap`: true なら「存在しない事物」を問うテーマ
- `facts[]`: ファクトシート（`id` / `statement` / `severity: major|minor`）
- `claims[]`: 判定する主張（`id` / `text`）

#### 判定基準

| label | 意味 |
| ----- | ---- |
| `correct` | ファクトシートまたは確実な知識と一致する |
| `incorrect` | ファクトシートまたは確実な知識と矛盾する（数値・日付・名称の誤り、捏造を含む）。`severity` を `major`（制度や技術の理解を誤らせる）/ `minor`（細部）で付ける |
| `unverifiable` | 真偽を確認できない |
| `out_of_scope` | 主題と無関係・評価対象外（意見・一般論など） |

`factIds` には根拠にしたファクトシート項目の id（無ければ空配列）。`note` は短い根拠。

さらに文章ごとに、ファクトシートの**各項目**について文章全体が `covered`（正しく言及）/ `contradicted`（矛盾する記述がある）/
`missing`（言及なし）のどれかを返す。`trap: true` のテーマでは、文章がその事物の存在を前提に説明していれば
`assertsExistence: true`、「存在しない／確認できない」と述べていれば `false`。それ以外のテーマでは `null`。

次の形式の **JSONL を ```jsonl フェンスで 1 ブロック**に書く（1 行 1 JSON。説明文はブロックの外に）。
`grader` は必ず `openai/codex`。item ごとに「主張の数 ＋ facts の数」行になる。

```jsonl
{"kind":"verdict","key":"<item.key をそのまま>","grader":"openai/codex","claimId":"c01","label":"correct","severity":null,"factIds":["t01-f01"],"note":"開始日が一致"}
{"kind":"verdict","key":"<item.key をそのまま>","grader":"openai/codex","claimId":"c02","label":"incorrect","severity":"minor","factIds":["t01-f03"],"note":"13 桁が正しい"}
{"kind":"coverage","key":"<item.key をそのまま>","grader":"openai/codex","factId":"t01-f01","status":"covered","assertsExistence":null}
{"kind":"coverage","key":"<item.key をそのまま>","grader":"openai/codex","factId":"t01-f02","status":"missing","assertsExistence":null}
```

</details>

## 4. 主張の種類の分類

Codex と Claude が独立に分類し、割れたものは Gemini が決める。

<details><summary>指示文の全文</summary>

### 主張の種類の分類

AI が書いた日本語の解説文から取り出した「主張」を、**真偽の確かめ方**の観点で 6 種類に分類してください。
真偽そのものは判定しません（ウェブも見ません）。同じ主張を別の会社の AI も独立に分類し、結果を突き合わせます。

#### 種類
| type | 意味 | 例 |
| --- | --- | --- |
| `fact` | 具体的な事実の肯定的な主張。一次情報と照らせば真偽が決まる | 「インボイス制度は 2023 年 10 月 1 日に始まった」「税率は 8%」 |
| `absence` | **実在する**制度・規格・製品について「〜はない」「〜できない」「〜は義務ではない」「〜は対象外」と述べる | 「PostgreSQL の関数内ではトランザクションを制御できない」「免税事業者は登録番号を持たない」 |
| `nonexistence` | お題で問われた事物（制度名・構文・人物・理論）について、その**存在を否定する／確認できないと述べる** | 「CREATE TRANSACTION TEMPLATE という構文は存在しない」「柳瀬昭平の経歴は確認できない」 |
| `vacuous_negation` | 存在しない（または確認できない）事物を主語・目的語にして、関係や性質を否定する。前提の事物がないため空虚に真になる | 「フクヤマの『Trust』は限界的信頼理論の出典ではない」「PREPARE は〜テンプレート機能ではない」 |
| `speculation` | 推測・可能性・仮定・推奨 | 「〜を指す可能性がある」「〜と考えられる」「〜すべきである」 |
| `interpretive` | 解釈・評価・因果や背景や動機の説明・程度の形容など、一次情報と照らしても真偽が一意に決まらない | 「晩婚化は単独世帯の増加を加速させている」「TLS 1.3 は互換性より高速化を優先して策定された」「〜は大きく減少した」 |

迷ったときの決め方:
- 数値・日付・名称・条文が含まれ、照合すれば白黒がつくなら `fact`（形容が付いていても）。
- 「〜はない」型でも、主語が実在する事物なら `absence`、問われた架空かもしれない事物そのものの存在についてなら `nonexistence`。
- 背景・目的の説明でも、公式文書に明記されている種類の事実（例:「RFC 8446 は RFC 5246 を廃止した」）なら `fact`。

#### 出力
説明文は不要です。次の形式の JSONL を ```jsonl フェンスで 1 ブロックだけ、入力の全主張ぶん出力してください。
```jsonl
{"key":"<入力の key をそのまま>","type":"fact","note":"10 字程度の理由（fact 以外のとき）"}
```
- 計画の提示や承認待ちはせず、直ちに結果を出力すること。ファイルは作らない・変更しない。ウェブは参照しない。

</details>

## 5. 一次情報での裁定

Codex（GPT-5.6 Sol、ウェブ検索）・Gemini 3.8 Flash・Claude Opus 5.5（ウェブ検索）が独立に行う。後ろにお題・ファクトシート・主張が続く。

<details><summary>指示文の全文（書き足したあとの版）</summary>

### 主張の裁定（一次情報による確認）

あなたは、AI が書いた解説文から取り出した「主張」の真偽を最終裁定する審査員の 1 人です。
別の会社の AI 2 社も同じ主張を独立に裁定し、結果を突き合わせます。食い違ったものは人間が最終判断します。
**正確さが最優先です。** 確信が持てないものは無理に白黒をつけず、`confidence` を下げてください。

#### 手順
1. 主張ごとに、**一次情報**（官公庁・e-Gov 法令検索・国税庁・厚労省・金融庁・デジタル庁・RFC Editor・標準化団体・公式ドキュメントなど）をウェブで確認する。
   まとめサイト・個人ブログ・AI による要約は根拠にしない。
2. 下の「ファクトシート」は運営が一次情報で確認済みの基準です。主張がファクトシートと食い違う場合でも、一次情報で主張の方が正しいと確認できれば `correct` にしてよい（その場合は `note` に理由を書く）。
3. **2025 年以降の制度改正**（例: 令和 8 年度税制改正、2025 年 6 月施行の拘禁刑、2026 年の RFC 改訂）は、あなたの事前知識が古い可能性があります。必ずウェブで最新の一次情報を確認すること。
4. 主張は「日本語の解説文の一文」です。文脈上の自然な読み方で判定し、細部の言い回しの揺れ（例: 「約」）は咎めない。ただし数値・日付・名称・条文の誤りは `incorrect`。
5. 判定時点は **2026 年 10 月**。

#### 「原則と例外」の扱い（3 社共通の判定方針・2026-10-04 明文化）
- 主張が制度・規格の**原則**を正しく述べていれば、例外・特例・ただし書きに触れていなくても `correct` とする。
- `incorrect` にするのは次の場合だけ:
  1. 例外の存在を明示的に否定している（「必ず」「例外なく」「すべての」「いかなる場合も」など）
  2. 主張自体が例外・特例について述べていて、その内容が誤っている
  3. 例外のほうが一般的で、原則として述べた内容が実態と食い違う
- 「例外があるので正しいとは言えない」という理由だけで `incorrect` にしない（必要なら `note` に例外を書く）。

#### 否定形・不存在の主張の扱い（3 社共通・2026-10-04 明文化）
- 実在する制度・規格・製品について「〜はない」「〜できない」「〜は義務ではない」と述べる主張は、一次情報に「ない」ことが明記されている、または網羅的な一覧（法令の条文・公式のコマンド一覧など）で確かめられる場合だけ `correct`。**裏付けが見つからないだけなら `unverifiable`**（証拠がないことは、ないことの証拠ではない）。
- 存在しない事物を主語・目的語にした否定（例:「X は Y の出典ではない」）、推測・可能性（「〜の可能性がある」）、解釈・評価・背景や動機の説明で真偽が一意に決まらないものは `out_of_scope`。

#### ラベル
| label | 意味 |
| --- | --- |
| `correct` | 一次情報と一致する |
| `incorrect` | 一次情報と矛盾する（`severity`: `major` 制度・技術の理解を誤らせる ／ `minor` 細部） |
| `unverifiable` | 一次情報で真偽を確認できない |
| `out_of_scope` | 事実の主張ではない（意見・一般論・助言） |

`confidence`: `high`（一次情報で直接確認した）／`medium`（間接的に確認、または一次情報は見つけたが解釈に幅がある）／`low`（確認できず知識で判断）。

#### 出力
説明文は不要です。次の形式の JSONL を ```jsonl フェンスで 1 ブロックだけ出力してください（1 行 1 主張、入力の全主張ぶん）。
```jsonl
{"key":"<入力の key をそのまま>","label":"incorrect","severity":"major","confidence":"high","source":"https://www.nta.go.jp/...","evidence":"一次情報の該当箇所を 60 字以内で要約","note":"短い理由"}
```
- 計画の提示や承認待ちはせず、直ちに作業して結果を出力すること。ファイルは作らない・変更しない。

</details>

<details><summary>指示文の全文（書き足す前の版）</summary>

### 主張の裁定（一次情報による確認）

あなたは、AI が書いた解説文から取り出した「主張」の真偽を最終裁定する審査員の 1 人です。
別の会社の AI 2 社も同じ主張を独立に裁定し、結果を突き合わせます。食い違ったものは人間が最終判断します。
**正確さが最優先です。** 確信が持てないものは無理に白黒をつけず、`confidence` を下げてください。

#### 手順
1. 主張ごとに、**一次情報**（官公庁・e-Gov 法令検索・国税庁・厚労省・金融庁・デジタル庁・RFC Editor・標準化団体・公式ドキュメントなど）をウェブで確認する。
   まとめサイト・個人ブログ・AI による要約は根拠にしない。
2. 下の「ファクトシート」は運営が一次情報で確認済みの基準です。主張がファクトシートと食い違う場合でも、一次情報で主張の方が正しいと確認できれば `correct` にしてよい（その場合は `note` に理由を書く）。
3. **2025 年以降の制度改正**（例: 令和 8 年度税制改正、2025 年 6 月施行の拘禁刑、2026 年の RFC 改訂）は、あなたの事前知識が古い可能性があります。必ずウェブで最新の一次情報を確認すること。
4. 主張は「日本語の解説文の一文」です。文脈上の自然な読み方で判定し、細部の言い回しの揺れ（例: 「約」）は咎めない。ただし数値・日付・名称・条文の誤りは `incorrect`。
5. 判定時点は **2026 年 10 月**。

#### ラベル
| label | 意味 |
| --- | --- |
| `correct` | 一次情報と一致する |
| `incorrect` | 一次情報と矛盾する（`severity`: `major` 制度・技術の理解を誤らせる ／ `minor` 細部） |
| `unverifiable` | 一次情報で真偽を確認できない |
| `out_of_scope` | 事実の主張ではない（意見・一般論・助言） |

`confidence`: `high`（一次情報で直接確認した）／`medium`（間接的に確認、または一次情報は見つけたが解釈に幅がある）／`low`（確認できず知識で判断）。

#### 出力
説明文は不要です。次の形式の JSONL を ```jsonl フェンスで 1 ブロックだけ出力してください（1 行 1 主張、入力の全主張ぶん）。
```jsonl
{"key":"<入力の key をそのまま>","label":"incorrect","severity":"major","confidence":"high","source":"https://www.nta.go.jp/...","evidence":"一次情報の該当箇所を 60 字以内で要約","note":"短い理由"}
```
- 計画の提示や承認待ちはせず、直ちに作業して結果を出力すること。ファイルは作らない・変更しない。

</details>

## 6. 「誤り」の見直し

3 社の AI が独立に行う。文章の条件は伏せる。後ろに主張・元の文章の抜粋・裁定の理由が続く。

<details><summary>指示文の全文</summary>

### 「誤り」とされた主張の見直し（全条件共通の基準で）

AI が書いた制度・技術の解説文を「1 文 1 事実の主張」に分解し、主張ごとに正誤を判定しました。下の主張はすべて最終的に「誤り」とされたものです。次の 2 つの観点だけで、その「誤り」が妥当かを見直してください。主張がどの AI のどの段階の文章かは伏せてあります。

#### 観点 1: 分解で意味が変わっていないか
主張は元の文章から機械的に切り出したものです。元の文章（抜粋）と比べ、分解で**主語・対象の向き（例: 買い手と売り手）・条件・但し書き・列挙の一部**が落ちて、元の文章にはない誤りが生まれていないかを見る。元の文章そのものが誤っているなら、分解の問題ではない。

#### 観点 2: 「原則と例外」の基準（判定の方針）
- 主張が制度・規格の原則を正しく述べていれば、例外や特例に触れていなくても「正しい」。
- 「誤り」にするのは、(1) 例外の存在をはっきり否定している（「必ず」「例外なく」「すべての」など）、(2) 例外そのものの説明が誤っている、(3) 例外のほうが一般的で原則の説明が実態と食い違う、のいずれかの場合だけ。
- 数値・日付・名称・条文の誤り、古い情報（2026 年 10 月時点で改正済みの内容を改正前のまま書いたもの）は「誤り」のまま。

#### 判定
- `keep`: 「誤り」で妥当（元の文章も誤っている、または上の (1)〜(3)・数値等の誤り）
- `split`: 観点 1 に当たる。元の文章は正しく、分解で誤りが生まれた
- `policy`: 観点 2 に当たる。原則として正しく、例外に触れていないだけ
- `unsure`: 判断がつかない
必要なら一次情報で確かめてよい（URL を source に）。

#### 出力
最後に、全件を 1 行 1 件の JSON で次のコードブロックに出す（他の文は書かなくてよい）。
```jsonl
{"rid":"r012abc","verdict":"keep|split|policy|unsure","reason":"40 字以内","source":""}
```
計画の提示や承認待ちはせず、直ちに作業して結果を出力すること。ファイルは作らない・変更しない。

</details>

## 7. 討論の経過についての記述の判定

Codex と Claude が独立に判定する（最終回答の主張のうち候補 79 件）。

<details><summary>指示文の全文</summary>

### 主張の種類の判定：お題についての事実か、討論の経過についての記述か

AI 同士の討論の最終回答（統合した解説文）を、1 文ずつの主張に分解しました。最終回答には、解説の本文のほかに、統合の経過（どの AI が何を述べたか、何を採用・不採用にしたか、どこで意見が一致・対立したか）を書いた部分があります。
各主張が次のどちらかを判定してください。

- `topic`: お題（制度・技術・統計など）についての事実の主張。一次情報で真偽を確かめられる
- `meta`: 討論や回答そのものについての記述（「一部のモデルは〜と指摘した」「統合時に〜は不採用になった」「全回答が〜を挙げた」「〜で見解が分かれた」など）。お題の事実ではない

文の中にお題の事実が含まれていても、主語や述語が「回答・モデル・統合・議論」についての記述なら `meta` とする。

#### 出力
最後に 1 行 1 件の JSON を ```jsonl のブロックで出す。
```jsonl
{"key":"q0123abcd","type":"topic|meta"}
```
計画の提示や承認待ちはせず、直ちに結果を出力すること。ファイルは作らない・変更しない。ウェブは不要。

</details>

## 8. 例外・条件の判定

Codex と Claude が独立に判定し、割れたものは Gemini が決める。文章の著者・条件は伏せる。後ろにお題・チェックリスト・文章が続く。

<details><summary>指示文の全文</summary>

### 解説文に「判断に効く例外・条件」がどこまで書かれているかの判定

下のお題に対して AI が書いた解説文が 15 本あります。各文章について、チェックリストの項目ごとに、本文がその例外・条件に触れているかを判定してください。
文章の良し悪しや、チェックリスト以外の誤りは判定しません。本文に書かれていることだけで判定し、推測で補わないでください。

#### ラベル
- `covered`: 例外・条件に正しく触れている（判定の基準を満たす）
- `partial`: 触れているが、基準の一部しか満たさない、または内容の一部が古い・不正確
- `wrong`: 触れているが、内容が誤っている（例外の存在を否定している場合を含む）
- `missing`: 触れていない

#### お題・チェックリスト

（ここにお題と、チェックリストの各項目〔id・項目・判定の基準〕が入る）

#### 出力
最後に、文章 × 項目の全組み合わせを 1 行 1 件の JSON で次のコードブロックに出す（他の文は書かなくてよい）。`note` は partial・wrong のときだけ 30 字以内で理由を書く。
```jsonl
{"text":"x0123abcd","item":"t01-x1","label":"covered|partial|wrong|missing","note":""}
```
計画の提示や承認待ちはせず、直ちに作業して結果を出力すること。ファイルは作らない・変更しない。ウェブ検索は不要。

#### 文章

（ここに文章が入る。文章の識別子は無作為の記号で、著者・条件は分からない）

</details>