【要約】パパからもらったJSON、壊れて出ない項目がある。どーしよー、どーしよー：Pydanticで構文・型・意味を検証する [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LLMを用いたシステム開発において、生成されたJSONが期待する仕様を満たさない問題が発生している。開発者は、一見正しく見えるJSONがシステムを破壊するリスクに直面している。具体的には以下の問題が挙げられる。
- ・JSONとしての構文エラー（末尾の余計なカンマなど）。
- ・型や値の範囲の不一致（数値が文字列、enum外の値、範囲外の数値など）。
- ・業務ルールとの矛盾（低重要度なのに停止フラグが立っている等の論理的不整合）。
- ・LLM特有の挙動（Markdownコードフェンスの混入、必須項目の欠落）。
// Approach
開発者はPydantic v2を導入し、検証プロセスを3つのレイヤーに分離して実装するアプローチを採用した。これにより、エラーの発生源を正確に特定し、適切な対処を可能にしている。具体的な手法は以下の通りである。
- ・構文検証:
json.loads()を用い、JSONとしての文法的な正しさを確認する。 - ・スキーマ検証: Pydanticの基本機能を用い、型、必須項目、enum、数値範囲、余計なフィールドの有無をチェックする。
- ・意味検証:
model_validatorを使い、フィールド間の論理的な整合性を検証する。 - ・正規化: 正規表現を用いて、LLMが混入させるMarkdownのコードフェンスを除去する。
- ・エラー構造化: Pydanticのエラーを機械可読な形式に変換し、LLMへの再生成指示に活用する。
// Result
この検証モデルを導入することで、LLMの不安定な出力を安全に制御できるようになった。検証エラーの発生源を「構文」「スキーマ」「意味」のいずれかに特定できるため、運用コストが低減する。具体的な成果は以下の通りである。
- ・エラー箇所の特定: UIでの強調表示や、LLMへの具体的な修正指示が可能になった。
- ・システムの堅牢化: 不適切なデータによる後続システムの異常動作を未然に防げる。
- ・自己修復の実現: 構造化されたエラー情報をLLMへ返すことで、精度の高い再生成を促せる。
Senior Engineer Insight
> LLMの出力を「信じるな、検証せよ」という原則に基づいた極めて実戦的な構成だ。特に、
strict=Trueによる型変換の禁止や、extra='forbid'による未知のフィールドの拒否は、本番環境のガードレールとして必須の技術である。また、自動修復の危険性（値の意味が変わるリスク）に言及している点も、シビアな現場を知る者の視点と言える。エラーを構造化し、LLMへのフィードバックループに組み込む設計は、LLMアプリケーションの信頼性を担保する標準的なパターンとなるだろう。