AI を使用して、自動的な自己修正とインテリジェントな後処理により、サンプルデータから構造化された JSON スキーマを生成します。
スキーマ生成では、生のエンティティデータを、エンリッチメント時に抽出すべき情報を正確に定義した、型付きで注釈付きの JSON スキーマに変換します。スキーマを手動で書く代わりに、サンプル JSON を貼り付けるだけで、AI が構造を解析し、型を推論し、専門ドメインを割り当て、改善案を提案します。
生成は 1 つの大きなプロンプトで行われるわけではありません。関心事を 1 つに絞った小さな呼び出しの連なりであり、その大半は並行して実行されます。各呼び出しは視野に収まる範囲の素材について 1 つの狭い問いに答えるだけなので、小さく安価なモデルでも実用的なスキーマを生成できるのです。
"8.275 h" は half_life_seconds: 29790 になります）、ネイティブ型では表現できない日付は整数の年になります。観測されたすべての値がその前提を裏付ける必要があり、そうでない場合プロパティはテキストのままです。保存されるのは書き換え後のサンプルです。{"en": "...", "fr": "..."} など）は単一の多言語値にまとめられます。各ステップは個別にリトライし（3 回まで）、回答は試行をまたいで蓄積されるため、断片的にしか回答しないモデルでも収束します。その後、ステップは得られた内容を受け入れ、不足分は決定論的に補完されます。性能の低いモデルは生成を失敗させるのではなく、説明の質を下げるだけです。実行全体を失敗させられるのは、識別情報とドメインのルーティングのみです。すべての呼び出しは個別のプロンプトとして課金・記録されるため、どこで何が消費されたかがレコードから正確に分かります。
一つではなく、同じエンティティタイプのサンプルを複数渡すことができます — その場合、スキーマはそれらのフィールドの和集合をカバーし、サンプルに存在しないものは nullable になり、それらに現れた値は実際の例になります。フィールド名は一致している必要があります。異なるエンティティタイプを記述したサンプルは拒否され、共通するフィールドが一切ない配列内のオブジェクトも同様に拒否されます。行を識別できるものが何も残らないためです。サンプルエディターは、生成を消費する前にこのような差異を検出して知らせます。
独自の単位を含む値は、schemaが導出される前に数値へ変換されます。"8.275 h" や "85 ms" が混在する列は、並べ替えも範囲によるフィルタリングも集計もできないためです。単位はプロパティ名（half_life_seconds）に移され、"stable" のような数値でない代替値は null になり、西暦1年より前の日付は整数の年（紀元前は負の値）になります。これはどの日付型でも保存できず、テキストでは誤った順序で並べ替えられてしまいます。サンプルパネルもこれに合わせて更新されるため、常にschemaが表す通りのサンプルが表示されます。変換処理が確実に読み取れなかったものは、入力されたそのままの形で残されます。
各ステップが 1 つの限定的な問いに答えるため、修正も限定的に行えます。ステップのバリデーターは、返ってきた結果のうち使えるものを保持し、不足している部分だけを再度要求します。ゼロから生成し直すことはないため、部分的に正しい回答は無駄な試行ではなく前進になります。
8つの検証ルールは、組み上がったスキーマに対する最終チェックとして引き続き実行されます。型の正しさ、専門領域の割り当て、参照の整合性、完全性です。この段階では、修正の仕組みというより安全網としての役割になります。各ルールの詳細は Validation Rules ガイドをご覧ください。
生成されたスキーマは、単なる型定義以上のものです。各プロパティには、エンリッチメントプロセスを導くメタデータが含まれています：
JSONスキーマの型 (string, number, integer, boolean, array, object)
どの情報を探すべきかを AI に伝える文脈的な説明です
この値を提供するexpertise domain（財務、規制など）を示します。
このフィールドがインスタンスを識別する要素の一部かどうか。キーは 2 つの役割を同時に果たします。エンリッチメントのプロンプトを正しいエンティティに集中させることと、フュージョンが配列要素を照合する基準になることです。キーは null 許容でも構いません。よく似た兄弟要素を区別する修飾子は、その値を本当に持たないケースがあっても識別要素であり続けます
文字列の値が、完全に列挙できる小さな集合(ステータス、評価、分類コードなど)から得られる場合、生成はそのメンバーをサンプルどおりの表記で提案します。これにより、エンリッチメントが同義語へ流れることはありません
フィールドが null になり得るかどうか。non-nullable のフィールドは database への登録に必須です
フィールドを複数の言語でエンリッチメントするかどうかです。
エンリッチメント中に元の値を変更せずに保持するかどうかです。
AIを正しいフォーマットへ導く、現実的な例の値
文字列値に対する機械的に検証可能な形式です。不正な回答は拒否されて再試行され、保存される値は正規形に保たれます。生成では、サンプルによって裏付けられた名前付きフォーマット（date、time、date-time、uuid、email、uri、ipv4、ipv6）のみが指定されます。正規表現パターンはまだ誰も見ていない値に対する予測であり、誤ったパターンはそのフィールドのエンリッチメントをすべて失敗させるため、パターンはエディターでご自身で追加してください
AIはスキーマのプロパティを、その意味的な内容に基づいて専門領域にグループ化します。例えば、製薬会社のスキーマには「Financial Analyst」「Regulatory Expert」「Corporate Information」といった領域が含まれる場合があります。これらの領域はマルチ専門領域戦略によって使用され、並列で専門的なLLM呼び出しを実行し、より深い結果を得ます。
専門ドメインの数は、過度な断片化を防ぐため、データのプロパティ数に基づいて自動的に制限されます。
フラグメントが組み上がると、モデルに委ねるべきでない事項は、実際の入力データを根拠として決定的な処理で確定されます:
いずれかのサンプルで欠落またはnullとなっているフィールドは、モデルの回答にかかわらずnull許容になります。そのため、値が不明であることはデータ品質の問題ではなく、有効な回答として扱われます。サンプルは範囲を広げる方向にしか働きません。少数のサンプルは、それらのインスタンスに値が存在することを示すだけで、その型のすべてのインスタンスについて証明するものではありません。だからこそモデルにも一票が与えられ、両者はOR条件で結合されます。
共存できない属性は、再度確認するのではなくルールに従って調整されます。preserve は multilingual と nullable に優先し、閉じた語彙が残る場合は multilingual が解除され、キープロパティが enum を保持することはありません。
配列内のすべてのオブジェクトには、少なくとも 1 つのキープロパティが保証されます。これは融合が重複排除を行う単位であり、キーを持たない配列要素があると、2 つのモデルの回答をマージできなくなるためです。
メトリクスと戦略設定のため、スキーマからすべての一意の専門領域が収集されます。
スキーマはそれ自体をある言語で記述します。型名、プロパティの説明、専門分野のラベル、提案などです。これは、エンリッチメント先の言語とは別のものです。生成時に言語を指定するか、指定せずにサンプル自身のプロパティ名の言語に判断を委ねてください。フランス語のサンプルから英語のスキーマが生成されることはなくなります。選択した言語は保存されるため、その後のAIによる編集も英語に戻ることなく、同じ言語で書き続けます。
開始にサンプルデータは必要ありません。エンティティタイプを説明するだけで（必要に応じて、根拠となるドキュメントを添付したり、ウェブ検索で実際の情報と照合したりできます）、プラットフォームがサンプルを作成します。複数を指定すれば、同じ内容を言い換えたものではなく、異なるインスタンスが複数得られます。
最初のサンプルは、同じ呼び出しの中で、残りのサンプルが何を対象にするかも決定します。「例を1つ」と独立にN回尋ねると、決まって同じ有名な事例がN回返ってきます。対象となる顔ぶれを最初にすべて挙げておくことが、それぞれを異なるものにする鍵です。
残りのサンプルは、サンプル1の構造をコントラクトとして、それに従って並列生成されます。単に一致するよう求めるだけではないため、バリアントがフィールドを改名・追加・削除することはできません。それでも重複したり不正な形式で返ってきたものは、回数を制限した再試行でもう一度リクエストされます。所定の件数に達しなかった場合は、黙って少ない件数が返されるのではなく、その旨が通知されます。
言語の既定は auto で、まずリクエストの文面から、次に添付ファイルから推測されます。追加で指定した指示は拘束力を持ちます。必ず反映されるか、反映できなかった内容とその理由がレスポンスで通知され、黙って無視されることはありません。
プロパティ名を親オブジェクトの文脈で読み、それが尋ね得る対象がいくつあるか数えてみてください。1つなら明確です。2つ以上あると、モデルごとに異なる解釈に落ち着くため、その列には異なる問いへの答えが混在してしまいます。たとえば企業のannual_revenueは、グループ全体か当該エンティティか、総額か純額か、通貨も複数あり得ます。まったくない場合 — その親が単に持っていないものの名前 — はさらに悪く、参照すべきものがないため、モデルは値をでっち上げます。
生成時には二重に対策しています。プロンプト自体が解釈の一意な名前を要求し、さらに完成したスキーマへの後処理が、それでも曖昧なものに注釈を付けます。この段階での対処法はリネームです。説明文は名前から生成されるため、説明文がその元になった名前の曖昧さを解消することはできず、また、まだスキーマに依存するものが何もないからです。サンプル生成でも同じチェックがサンプルに対して実行され、目に触れる前にリネームが適用されます。説明・要約・メモといった自由記述の文章にフラグが付くことはありません。書き方は変わっても、問いかけている内容は明確だからです。
フラグが付いたプロパティには Workflow Editor 上で「曖昧」バッジが表示され、その名前が許容する解釈が一覧されます。スキーマが稼働状態になると、対処法は説明文の書き換えに切り替わり、データ契約を壊さずに意味を1つに固定できます。評価基準と対処法の全体は曖昧性チェックガイドをご覧ください。
説明からサンプルエンティティを生成する際に、「Web検索を使用」を有効にすると、モデルはトレーニングデータだけに頼らず、Web上の最新の事実を調べられるようになります。これにより、より新しく正確なサンプル値が生成されます。特に価格、従業員数、最近のリリースといった変化の速い事実に有効です。このオプションは、組み込みのWeb検索をサポートするプロバイダーのモデルにのみ表示され、検索呼び出しは他のモデル利用と同様にプロバイダーによって課金されます。
生成後、自然言語の指示を使用してスキーマを変更できます。コマンドを入力すると、AIは既存のスキーマ構造を維持しながら変更を適用します。各編集では、さらなる改善のための5つの提案も生成されます。
employee_count整数フィールドを追加市区町村と国を含むネストされた住所オブジェクトを作成しますすべてのテキストフィールドにフランス語の説明を追加$defs を使用して親会社の参照を定義しますwebsite フィールドを null 許容としてマークAI編集は、生成ルールのサブセット（型チェック、参照の整合性、専門分野の一貫性）を使用して検証されますが、意図的にフィールドを追加または削除する場合があるため、入力データとの比較は行われません。
スキーマ生成とAI編集はいずれも、異なる改善カテゴリーをカバーする5つの的を絞った提案を生成します。
候補はWorkflow Editor内にクリック可能なチップとして表示されます。クリックすると、AI編集の入力欄が自動的に入力され、適用されます。