モデル間や実行間で値が変動するスキーマプロパティを検出し、データを汚染する前に修正します。再現可能で、比較可能で、正確なエンリッチメントを実現します。
Entity EnricherはLLMをクエリ可能なナレッジベースとして扱います。それが機能するのは、プロパティ名が単一の再現可能な回答を確定する場合だけです。annual_revenueのようなプロパティはそうではありません。どの会計年度でしょうか?どの通貨でしょうか?単位は百万でしょうか、それとも1でしょうか?どのモデルも、そして同じモデルの再実行のたびに、異なるフレームを自由に選べるため、どのモデルも間違っていなくても値が食い違います。
不安定なプロパティは下流のすべてに悪影響を及ぼします。マルチモデルフュージョンは、実際には枠組みの違いにすぎない矛盾を検出し、ベンチマークの一貫性のばらつきは、モデルの品質とは無関係な理由で広がります。非決定性チェックはこれらのプロパティを見つけ、固定する方法を教えてくれます。
フラグが付いた各プロパティは、それぞれ独自の対処法を持つ4つの原因のいずれかに分類されます。
| 原因 | 例 | 対処法 |
|---|---|---|
| 時間的 | ceo, stock_priceceo_2025 | 基準日のない可変的な事実です。期間を固定するか、期間をキーとする配列に再構成してください。 |
| あいまい | annual_revenuerevenue_fy2024_usd_millions | 名前が単位、通貨、期間、または範囲を固定していません。不足している枠組みを名前または説明に埋め込んでください。 |
| 主観的 | reputationesg_risk_rating_sustainalytics | 客観的な正解が存在しません。測定可能な代理指標や固定された尺度に置き換えてください。そうしない限り、参考情報としてフラグが付いたままになります。 |
| 複数値 | top_competitorstop_3_competitors_by_revenue | 同じくらい正しい答えが複数あり、通常は上限のないリストです。範囲を限定し、順序付けの基準を明示してください。 |
名前の変更だけが解決策ではありません。スキーマのプロパティについては、アナライザーは欠落しているフレームを固定する説明の修正も提案します。より明確な説明は、名前と同じようにエンリッチメントを行うAIに伝わりますが、データ契約を壊すことはありません。そのため、すでに使用中のスキーマにとっては推奨される対処法です。
サンプルが生成されると、アナライザーがそれをレビューします。明確な名前変更はAIが作成したキーに対して自動的に適用され(ご自身で名付けたフィールドには適用されません)、構造的な修正は最大2回の修正ラウンドにわたってジェネレーターにフィードバックされます。添付ドキュメントに基づくサンプルはスキップされます。その値はモデルの記憶からではなく、ソースドキュメントに由来するためです。
生成されたスキーマを保存すると、後処理パスがすべてのプロパティに非決定性レベルの注釈を付けます。このステップはベストエフォートで、失敗しても生成自体には影響しません。
再チェックボタンは、まだ注釈のないプロパティのみを分析し、すべてのプロパティに注釈が付くと完全な再分析に切り替わります。
スキーマ作成のために貼り付けるサンプルJSONは、ステートレスに分析できます。何も変更されることなく、リスクのあるプロパティ名のレポートが得られます。
このチェックは助言的なものにすぎません。生成をブロックすることも、エンリッチメントを拒否することもなく、その注釈はエンリッチを行うモデルに送られるすべてのプロンプトから取り除かれます。つまり、AIではなくあなたに情報を伝えるものです。
フラグが付いたプロパティは、スキーマエディターで「変動あり」バッジを表示します。中リスクは黄色、高リスクは赤です。バッジにカーソルを合わせると、何がなぜ変動するのかを説明するアナライザーのメモが表示されます。決定的と判定されたプロパティにはバッジは付きません。
判定はプロパティの名前と説明を合わせて下されます。そのため、プロパティの名前を変更したり説明を編集したりすると、そのアノテーションは無効になります。エディターはそうしたプロパティを古くなったものとしてハイライトし、欠落している部分だけを分析する再チェックを提案します。これは、提案された名前変更を適用した後にまさに必要となるものです。再チェックによって、新しい名前が決定的かどうかを確認できます。
このチェックは、スキーマエディターのオーバーフローメニューからスキーマごとにオフに切り替えられます。無効にすると、生成後のパスはスキップされ、バッジ、再チェックボタン、陳腐化警告は非表示になります。既存の注釈は保持され（非表示になるだけ）、一度も分析されていないスキーマでチェックを再度有効にすると、自動的に実行されます。
添付ドキュメントから生成されたスキーマは、チェックが無効な状態で始まります。それらの値はソースドキュメントから転記されるため、モデルの知識による実行間の変動は適用されません。
アナライザーのメモはお使いのインターフェース言語で書かれます。フランス語のユーザーにはフランス語の説明が、日本語のユーザーには日本語の説明が表示されます。提案されるプロパティ名はスキーマの命名規則に合わせて英語のままです。
各分析は実際の(安価な)モデル呼び出しであり、レコード上の独立したプロンプトとして記録され、他のAI利用と同様にクレジットから差し引かれます。増分的な再チェックでは、実際に分析されたプロパティの分だけが課金されます。
スキーマ生成自体は、決定的な名前と説明（固定された期間、単位、順序付け基準）を生成するよう指示されているため、ほとんどのスキーマはクリーンに出力され、アナライザーは取りこぼしを拾うだけで済みます。
このチェックはプログラムからも利用できます。
| 検出 | 説明 |
|---|---|
POST /api/schema/analyze-sample | 貼り付けたサンプルJSONを分析します。ステートレスなレポートで、何も変更されません |
POST /api/schema/saved/{id}/analyze | 保存済みのスキーマを分析してアノテーションを書き込みます。デフォルトでは増分的に行われ、force=trueですべてを再分析します |
analyze_sample_determinism | MCPツール — Claudeやその他のMCPクライアントから同じステートレスなサンプルレポートを取得します |
analyze_schema_determinism | MCPツール — 保存済みのスキーマにアノテーションを付けます。edit_schemaと組み合わせて提案された名前変更を適用します |
認証と全ツールカタログについては、APIリファレンスとMCP Serverガイドをご覧ください。