執筆日
2025/7/15
はじめに
Structured outputsを使う際、普段は Pydantic などで型を定義している方も多いのではないでしょうか？
たとえば、以下のような形式です。
class Test(BaseModel):
name: str
age: int
このように型を使うと、LLMが構造化された出力を生成してくれて便利ですよね。
私自身も登場の時からStructured outputsをよく活用しています。
OCRで精度が出なかった話
最近、LLMを使ってドキュメントからデータを抽出する検証をしていたのですが、「項目名はあっているのに、値がうまく抽出されない」「似たような項目が混在して精度が落ちる」といったケースに多く出会いました。
そんな時に出会ったのが…
ふと読んだのがこちらの記事：
ここで驚いたのが、「Structured outputsって、description を書けるのか！」という点です。
これまでは型だけで定義していたのですが、description に項目の意味や特徴を書くことで、抽出精度がぐっと上がることを実感しました。
たとえば、以下のように記述することで、「これは"契約開始日"である」と明示できます：
class CertificateInfo(BaseModel):
contract_start_date: Optional[str] = Field(
date, description="契約の開始日を示す（例: 2025-04-01）"
)
さらに調べると、こんな指定もできる
description以外にも、Structured outputsで使えるプロパティがいくつもあることを知りました。以下は一部抜粋です：
文字列型（string）
- pattern：正規表現で値の形式を制約
-
format：日付やメールなどのプリセット形式（例：
date,email,uuid）
数値型（number）
- minimum / maximum：値の上下限を指定
- multipleOf：特定の倍数のみ許可
配列型（array）向け
- minItems / maxItems：要素数の最小・最大を指定
これらを活用することで、OCRやLLMからより「狙った構造のデータ」を抽出しやすくなります。
おわりに
これまで型定義だけで満足していたStructured outputsですが、description や各種プロパティを活用することで、実務における精度改善に直結することを実感しました。
特にOCRなど「ノイズの多い情報」から抽出する場面では、意味を明示するだけでも効果が大きいです。
今後は、もっと積極的に Field(..., description="...") を使っていこうと思います。
Discussion