8 つの検証ルールがスキーマの品質を保証します。これらは AI スキーマ生成が回答を組み立てた後にコード側で実行され、ステップごとに自己修正を行うパイプラインに対する最終的なセーフティネットとして機能します。
修正は最後にまとめてではなく、誤りが生じたその場で行われます。生成は単一の関心事ごとに分かれた小さな呼び出しの連なりであり、それぞれが専用のバリデーターを備えています。バリデーターはその呼び出しの回答を検証し、有効だった部分を保持したうえで、まだ欠けている部分だけを再度要求します。そのため、断片的にしか回答しないモデルでも、最初からやり直すことなく収束していきます。
生成をそのまま失敗させ得る工程は 2 つだけです。エンティティの命名と、プロパティの専門ドメインへの振り分けです。それ以外にはすべて決定的なフォールバックがあり、そのおかげで小規模なモデルでもここで利用できます。
すべてのルールがschema生成とAI編集の両方に適用されるわけではありません。入力データと比較するルールは、意図的にフィールドを追加・削除する場合があるため、編集時にはスキップされます:
| スコープ | 適用されたルール | 理由 |
|---|---|---|
| 生成 | 8つのルールすべて | 比較用の入力データが利用可能です |
| AI編集 | ルール2・3・4・5のみ | 入力データがありません。ユーザーが意図的に構造を変更する可能性があります |
専門ドメインの数は、プロパティ数に基づいて計算された最大値を超えることはできません。これにより、小さなスキーマに対して AI が細かすぎるドメインを作りすぎることを防ぎます。
Too many expertise domains: 6 defined, maximum is 3最大値は floor(property_count / 6) で計算され、最小値は 1 です。12 個のプロパティを持つスキーマでは最大 2 つのドメインが許可されます。
すべてのスキーマは、少なくとも1つのプロパティを定義する必要があります。空のスキーマはエンリッチメントに使用できません。
Schema must have at least one propertyこれにより、AIが有効なJSON構造を生成したものの、実際のフィールドを一切含め忘れるケースを検出します。
すべてのプロパティタイプは、標準のJSONスキーマタイプ（string、number、integer、boolean、array、object、null）のいずれかである必要があります。
revenue: invalid type 'float'AIは「float」「decimal」「date」などの型を勝手に作り出すことがあります。このルールはそれらを検出し、有効な型への修正を求めます。
すべての $ref は存在するものを指す必要があります。#/$defs/... はエンティティ定義を、#/$enums/... は値セットを指します。無効な参照はエンリッチメントパイプラインを壊します。
manufacturer: $ref '#/$defs/Company' references undefined definition2 つの名前空間は別々です。#/$defs/ 参照はネストされたエンティティへの関係を表し、#/$enums/ 参照はテキストプロパティを許可値の閉じたリストに制限します。それぞれ独自のブロック内に対応するエントリが必要です。
すべてのプロパティのexpertise値は、定義された専門領域のいずれかと一致する必要があります。これにより、タイプミスや不整合を防ぎます。
revenue: expertise 'finance' not in defined domains: ['financial_analyst']AIは、定義された「financial_analyst」キーの代わりに「finance」を使用する場合があります。このルールはその不一致を検出し、AIが修正できるようにします。
オブジェクトでもなく保持もされないプロパティには、expertise domainの割り当てが必要です。これにより、enrichment可能なすべてのフィールドが専門のドメインで処理されることが保証されます。
revenue: expertise is required for non-object typesオブジェクト型は、その子プロパティが独自のexpertise domainを持つため除外されます。保持されるフィールドは変更されずに通過するため除外されます。
各プロパティの schema 型は、入力データ内の対応する値の実際の Python 型と一致している必要があります。
revenue: type mismatch - input is number but schema says 'string'入力に "revenue": 42.5 が含まれる場合、スキーマは "string" ではなく "number" または "integer" タイプを使用する必要があります。バリデーターは柔軟で、整数に対して "number" を受け入れ、その逆も同様です。
入力データのすべてのキーは、生成されるスキーマ内のプロパティとして表示される必要があります。これにより、AIがフィールドを無言で削除することを防ぎます。
Missing property from input: 'headquarters'入力JSONに "headquarters" キーが含まれる場合、生成されるスキーマにはそれを含める必要があります。これにより、データの完全な網羅が保証されます。
ルール7（型マッチング）は、自動型推論を使用して入力値をスキーマで宣言された型と比較します。誤検知を避けるため、推論は柔軟に行われます:
| 入力値 | 推定された型 | その他に受け付ける値 |
|---|---|---|
| true / false | boolean | （ブール値のみ） |
| 42 | integer | number |
| 3.14 | number | integer |
| "hello" | string | (文字列のみ) |
| [1, 2, 3] | array | （配列のみ） |
| {"key": "val"} | object | （オブジェクトのみ） |
注意：一部の言語ではブール値が整数のサブタイプであるため、ブール値は整数よりも先にチェックされます。この順序により、trueが整数として推論されるのを防ぎます。
この表はバリデーターが受け入れる内容を示すものであり、生成が出力する内容ではありません。サンプル値が 3 だからといって、そのプロパティが整数になるわけではありません。数値フィールドは、専用のステップがその量を本当に離散的だと確認し、かつ観測されたどの値もそれと矛盾しない場合を除き、number として出力されます。サンプルに整数が 1 つあることは、小数が存在し得ない証拠にはなりません。誤って整数と宣言すると、連携先のデータベースで 6.2 が 6 に切り捨てられてしまいます。