出力の形を決めて、後ろの処理との約束にする

1なぜ自由な文章の出力は、後ろの処理で壊れるのか

2形をそろえる3つの方法と、それぞれの効き方

3構造化出力で防げること、防げないこと

4スキーマを設計するときの5つの判断

{
  "type": "object",
  "properties": {
    "evidence": {
      "type": "string",
      "description": "判定の根拠になった原文の一部。原文からそのまま引用し、言い換えない"
    },
    "category": {
      "type": "string",
      "enum": ["bug", "feature", "question", "other"]
    },
    "product": {
      "type": ["string", "null"],
      "description": "書かれている製品名。書かれていなければ null"
    }
  },
  "required": ["evidence", "category", "product"],
  "additionalProperties": false
}

読み方：properties は項目の一覧、required は必須の項目、additionalProperties: false は「一覧にない項目を足さない」という指定です（※4）。

5受け取る側は「止まった理由 → 形 → 中身」の3段で確かめる

import json

CATEGORIES = {"bug", "feature", "question", "other"}

def accept(resp, source_text):
    """(結果, 理由) を返す。結果が None なら使わない（fail-closed）。"""
    # 1段目：止まった理由。拒否や打ち切りのときは形が崩れていることがある
    if resp.stop_reason != "end_turn":
        return None, f"途中で止まった: {resp.stop_reason}"
    # 2段目：形。構造化出力でも、対応外の条件はここで確かめる
    data = json.loads(resp.content[0].text)
    if data["category"] not in CATEGORIES:
        return None, "選択肢の外"
    # 3段目：中身。根拠の引用が原文に本当にあるか（言い換えや作り話を落とす）
    if data["evidence"] not in source_text:
        return None, "根拠の引用が原文に見つからない"
    return data, ""

読み方：stop_reason は止まった理由（※6）で、end_turn は「最後まで書き終えた」という意味です。json.loads は JSON の文字列をデータに変える関数、A not in B は「A が B の中に文字どおりには含まれていない」という判定です。

63段目がいちばん効く

7AIが自分で言う「確信度」は、あてにしない

誤解よくある思い違い

演習手を動かして確かめる

{
  "type": "object",
  "properties": {
    "category":   { "type": "string" },
    "confidence": { "type": "number", "minimum": 0, "maximum": 1 },
    "reasoning":  { "type": "string",
                    "description": "判定に至るまでの考えを、順を追って詳しく書く" }
  }
}

用語メモ本文の ※番号の説明

1. ※1トークン AIが文章を扱うときの最小単位。単語や文字の断片で、日本語ではおおむね1〜2文字が1トークンになる。AIは「次の1トークン」を確率で選ぶことをくり返して文章を作る。 本文へ戻る ↩
2. ※2JSON データを文字で書き表すときの決まった書き方。{"名前": "値"} のように、項目名と値を組にして書く。人にもプログラムにも読めるので、プログラム同士の受け渡しによく使われる。 本文へ戻る ↩
3. ※3構造化出力（structured outputs） AIの出力を、渡したスキーマどおりの JSON に必ずそろえる API の機能。Claude・OpenAI・Ollama などにある。名前や細かい対応範囲はサービスごとに違う。 本文へ戻る ↩
4. ※4スキーマ（JSON Schema） 「この JSON にはどんな項目があり、それぞれどんな型で、どれが必須か」を書いた設計図。設計図そのものも JSON で書く。properties（項目の一覧）、required（必須の項目）、enum（選べる値の一覧）、additionalProperties: false（一覧にない項目を許さない）などの決まった語を使う。 本文へ戻る ↩
5. ※5制約付きデコーディング（constrained decoding） デコーディングは、AIが次のトークンを選んで文章を作っていく処理のこと。その1歩ごとに、決めた文法（ここではスキーマ）に合わないトークンを候補から外してから選ぶやり方を、制約付きデコーディングと呼ぶ。頼むのとは違い、合わない出力がそもそも出てこない。 本文へ戻る ↩
6. ※6止まった理由（stop_reason） API の応答に付く「なぜ書くのをやめたか」の値。Claude では end_turn（書き終えた）、max_tokens（指定した長さの上限で切れた）、refusal（安全上の理由で応じなかった）、tool_use（道具を使うために止まった）などがある。 本文へ戻る ↩
7. ※7拡張思考（extended thinking） 答えを書く前に、AIが考える過程を別の欄（thinking ブロック）に書けるようにする Claude の機能。考える場所が答えとは別に用意されるので、答えの JSON に考えを混ぜずにすむ。 本文へ戻る ↩
8. ※8fail-closed 判断に迷ったときや、検査に通らなかったときに、「使わない・通さない」安全なほうに倒す作り方。反対の fail-open は「迷ったら通す」。後ろの処理に渡す場面では、間違ったものが黙って流れるより、止まって気づけるほうが被害が小さい。 本文へ戻る ↩
9. ※9較正（calibration） 「確信度90%」と言ったものが、実際にも90%くらい当たっている状態のこと。較正されていない確信度は、数字の大きさと当たる割合が対応していないので、「0.8以上なら採用」のような線引きに使えない。 本文へ戻る ↩
10. ※10温度（temperature） 次のトークンを選ぶときの、ばらつきの大きさを決める設定。低いほど確率の高いトークンばかりを選び、高いほど意外なトークンも選ぶ。0にしても、計算の細かなゆれなどで出力が変わることはある。 本文へ戻る ↩
11. ※11正規化（Unicode 正規化・NFKC） 見た目は同じでも中身の文字コードが違う文字を、1つの形にそろえること。NFKC はその方式の1つで、全角の英数字を半角に、半角カナを全角に、などをまとめて行う。Python なら unicodedata.normalize("NFKC", s)。 本文へ戻る ↩

出典確かめた資料（2026年10月時点）

• Anthropic「Structured outputs」 制約付きデコーディング、防げる範囲、対応外の条件、項目の順番、拒否と打ち切りの扱い。
• Ollama「Structured outputs」 format に JSON スキーマを渡す方法。
• JSON Schema「Understanding JSON Schema」 enum・required・additionalProperties の意味。
• Xiong ほか「Can LLMs Express Their Uncertainty?」(2023) AIに言葉で述べさせた確信度が、高めに出やすいという報告。