# AIエージェントをソフトウェアに組み込むプラクティス # Verified Structured Output｜検証済み構造化出力 🎯 LLMの出力をそのまま下流システムに流していませんか？JSONが壊れている、値が不正、フィールドが足りない――「黙って壊れる」を防ぐのがこのパターンです。 🔥 解決する課題 LLMの出力は本質的に曖昧な自然言語です。下流のコードやAPIが期待する型やフィールドに従わない出力が返ると、パース失敗・型エラー・無効な値の混入がサイレントに後続処理を破壊します。フォーマットが正しくても「過去の日付を未来として返す」「存在しない商品IDを含める」といったビジネスルール違反は、構文チェックだけでは検出できません。 💡 提案パターン LLMの出力をresponse_formatやfunction_callingでJSON Schemaに準拠させる第1層（スキーマ検証）と、決定論的コードでビジネスルール制約を検証する第2層（意味的検証）の二段構成にします。違反時はエラー内容をコンテキストに追加して自己修正リトライを行い、予算内（目安1-3回）で収束しなければfail-fastします。温度は0.0-0.3に設定し、構造化出力の従順率を確保します。 ✅ 選定条件 使うとき： - LLMの出力を下流のコード・API・データベースが消費する - 出力が従うべきスキーマ（型・必須フィールド・値域）が定義可能 - 不正な出力が後続処理を壊すと業務影響がある 使わないとき： - 出力が自由形式のテキスト（要約・対話）で構造化の必要がない - 出力スキーマが頻繁に変わりスキーマ維持コストが利益を上回る - 不正出力をそのまま捨てても問題ない低リスク用途 ⚠️ 落とし穴 - リトライ時にエラーメッセージを毎回追加するとトークン消費が膨らみます。直前のエラーだけを渡すか要約する工夫が必要です - スキーマのフィールド数が多すぎると（概ね15超）LLMの従順率が下がります。大きいスキーマは分割呼び出しを検討してください - response_formatはプロバイダ依存です。スキーマ定義はPydanticやJSON Schemaなど中間表現で管理してください 🔧 実装方針 - 第1層（スキーマ検証）ではresponse_formatやfunction_callingでJSON Schemaに準拠させ、Pydanticモデルで型・値域を強制します - 第2層（ビジネスルール検証）では決定論的コードで日付範囲・ID存在・権限等のドメイン制約を検証します - 検証失敗時はエラー内容をコンテキストに追加して自己修正リトライを行い、予算（目安1-3回）で打ち切りfail-fastします - LLMの温度は0.0-0.3に設定し、構造化出力の従順率を確保します - スキーマ定義はPydanticやJSON Schemaなどプロバイダ非依存の中間表現で管理し、移植性を担保します #AIエージェント# #ソフトウェアアーキテクチャ#