pydantic(データバリデーション)

pydanticとは

pydantic は、[[Python]] の型ヒントをそのまま実行時の検証規則として使うライブラリです。型ヒントは通常、実行時には何もしません。pydantic はそこへ検証と変換を与えます。

from pydantic import BaseModel

class User(BaseModel):
    id: int
    name: str
    active: bool = True

user = User(id="42", name="太郎")  # "42" は int へ変換される

型に合わない値は例外になり、どのフィールドがなぜ不正かが構造化されたエラーとして返ります。単に落ちるのではなく、原因を機械的に扱える形で受け取れる点が実務では効きます。

なぜ境界に置くのか

外部から来るデータ — [[REST API]] のレスポンス、設定ファイル、フォーム入力 — は、期待どおりの形とは限りません。検証しないまま奥へ渡すと、遠い場所で意味の分からないエラーになります。

考え方は [[JSON Schema]] と同じ「データの形を宣言し、それに照らして検証する」ですが、pydantic はPythonのクラス定義がそのまま仕様になる点が違います。仕様とコードが二重管理にならず、ずれが起きにくくなります。

実務での使いどころ

• APIレスポンスの受け口 — 外部サービスの応答をモデルへ通し、以降は型の付いたオブジェクトとして扱う
• 設定の読み込み — 環境変数や設定ファイルを起動時に検証し、起動時点で落とす。実行中の想定外を減らせる
• LLMの構造化出力 — 生成された文字列をモデルへ通し、期待した形かを確認してから使う

検証に失敗したときの扱いは [[エラーハンドリングとリトライ設計]] の判断に従います。設定の不備のように再試行しても直らないものは即座に落とし、外部APIの一時的な形崩れのように再試行で回復しうるものは区別します。

初学者向けポイント

• まずは1つのモデルを外部データの入口に置くところから始めます。全体へ広げるのは後で構いません
• 既定では文字列から数値への変換など緩やかな型変換が行われます。厳密に扱いたい項目は strict な指定にします
• バージョン1系と2系で書き方が変わっています。参照する記事がどちらの版か確認してから写します
• 検証エラーはフィールド名と理由を持つ構造化データとして取得できます。利用者向けのメッセージへ変換するときは、この構造をそのまま使うと項目ごとの表示に落とし込めます

関連技術とのつながり

• [[Python]] — 型ヒントという言語機能を実行時の検証へ結び付けている
• [[JSON Schema]] — 同じ「形を宣言して検証する」考え方。pydanticはクラス定義が仕様になる
• [[REST API]] — 外部レスポンスを信頼できる型へ変換する境界として使う
• [[エラーハンドリングとリトライ設計]] — 検証失敗を「再試行するか即座に落とすか」で仕分ける

Q: pydanticが型ヒントに与える働きはどれ?
- [ ] 実行速度を最適化する
- [x] 実行時の検証規則として使い、不正な値を弾く
- [ ] 型ヒントを削除して軽量化する
解説: 通常の型ヒントは実行時に何もしませんが、pydantic はそれを検証と変換の規則として使います。

Q: pydanticのモデルを置く場所として適切なのはどれ?
- [x] 外部データが入ってくる境界(APIレスポンスや設定の読み込み)
- [ ] 計算処理の最内側のループ
- [ ] ログ出力の直前
解説: 入口で検証すれば、以降のコードは型を信頼できます。奥で失敗すると原因の特定が難しくなります。

Q: 設定ファイルをpydanticで検証する利点はどれ?
- [ ] 実行中に設定を自由に書き換えられる
- [x] 起動時に不備を検出して落とせるため、実行中の想定外を減らせる
- [ ] 設定ファイルが不要になる
解説: 起動時点で検証して落とすことで、稼働後に設定不備が原因で失敗する事態を避けられます。