日付が JSON スキーマに記述されているからといって、バリデーターが日付をチェックする必要があるという意味ではありません。

format: date は JSON スキーマで記述されていますが、存在しない日付は検証に合格します。通常、これはライブラリのバグではありません。 format がどのように処理されるかは、バリデーターの構成によって異なります。「検証成功」の結果が得られた場合は、まず型、構造をチェックするか、日付セマンティクスもチェックするかを確認する必要があります。

この記事は、ドキュメントデータの構造化検証を実行し、日付フィールドの精度を気にする必要がある開発者とレビュー担当者に適しています。これを読むと、合格検証が何を意味するのかを判断し、反例テストを使用して日付ルールを修正できるようになります。

この記事では、合成サンプルを使用して処理方法を説明します。コードは隔離された環境でサンプルを使用してチェックされており、すべての実際のファイルや製品のパフォーマンスを保証するものではありません。重要な書類を処理する前に、原本を保管し、本文の境界と許容事項に従って確認してください。

JSON スキーマの日付検証では具体的に何をチェックするのでしょうか?一文の結論

まず、バリデーターで format チェックが有効になっているかどうかを確認し、次に日付の意味規則 (日付が実際に存在するかどうか、およびその解釈方法)が原因であるかどうかを確認します。

あなたの状況	推奨される実践方法	理由
デフォルトのバリデーターで `format: date` のみをチェックしてください	まず、FormatChecker が明示的に有効になっているかどうかを確認します。	`format` がどのように処理されるかはバリデーターの構成によって異なります
`2026-02-30` などの日付を特定する必要がある	反例としてテストセットに入れてください	この文字列は日付のように見えますが、カレンダー上に存在するわけではありません。
出典日の月日の順序は不明。	マークの曖昧性、自動推測なし	`date` 検証に合格すると、変換された値が有効であることのみが示されます。
時間とタイムゾーンを含むフィールド	独立した時間プロトコルを使用する	最初の 10 文字をむやみに傍受したり処理したりしないでください。
翻訳日の検証に使用されます	`raw_text` と正規化された値の両方を保存する	査読者はオリジナルの内容と体系的な説明の両方を見る必要がある

一見同じように見える小切手が二枚

2026-02-30は文字列で、その形は日付に似ていますが、2月には30日目はありません。通常の形状だけを確認すると、こうした問題を見逃すことができます。以下では、Pythonのjsonschemaを用いて、デフォルトのバリデータと明示的に有効になっているFormatCheckerの結果を比較します。

不可能なデートで設定を探る

from jsonschema import Draft202012Validator, FormatChecker

schema = {"type": "string", "format": "date"}
structural = Draft202012Validator(schema)
strict = Draft202012Validator(schema, format_checker=FormatChecker())

def valid(v, value):
    return not list(v.iter_errors(value))

assert valid(structural, "2026-02-30")
assert not valid(strict, "2026-02-30")
assert valid(strict, "2024-02-29")
assert not valid(strict, "2025-02-29")
assert not valid(strict, "26/09/2026")
assert not valid(strict, 20260926)

合成例はdateのみを検証しています。他のフォーマットは依存関係や実装の違いがオプションで存在し、ロックされた環境で項目ごとにテストする必要があります。未知のフォーマット名は、何らかの誤りがチェックされたものとみなすべきではありません。誤字は無意味な安心感を与えてしまいます。

日付形式は日付の解釈のルールではありません

出典03/04/2026は3月4日または4月3日を表す可能性があります。 ISOフォームに変換する前に、ソースリージョン、フィールドの記述、またはクリアプロトコルを指定する必要があります。 dateの検証は、変換された価値が有効であることを意味しますが、正しい月を選んだことを証明するものではありません。

出典情報	何をすべきか	してはいけないこと
存在しない暦日付	エラーしてソースを確認してください	自動的に翌月に繰り越されました
太陽と月の順序は不明です	マークの曖昧さ	サーバー言語に基づく推測
時間とタイムゾーンを含む	独立した時間契約を活用してください	最初の10文字をランダムに切り取る
フィールドは空っぽだ	失われたルールに従って処理されています	日付を補足する

回帰分析に構成を含める

テストセットには少なくとも3種類の値が含まれています:有効なう日1つ、違法うるうう日1つ、そして誤った1つの値です。これらの反例を展開時に実行することは、スキーマファイルの存在を単に確認するよりも効果的です。サービスが言語間で実装されている場合、同じテストセットは別々に検証されるべきであり、2つの検証者のデフォルトの動作が同一であると仮定してはいけません。

翻訳レビューは元の日付を保持

OmniDocの翻訳検証に日付抽出結果を使用する場合は、raw_text値と正規化値の両方を保存することが推奨されます。レビュアーは「元の内容が何か」と「システムがそれをどう解釈するか」を見て、翻訳、抽出、フォーマット変換の違いを見極める必要があります。

参考：JSON スキーマの文字列と形式。

📊 コア比較

比較項目	デフォルト検証器	FormatCheckerを明示的に有効にしてください
検査範囲	種類と構造	さらに、`format`宣言のフォーマットも確認してください
`2026-02-30`に関する結論	断られるとは思えません	実際の試験で確認するためには反例が必要です
通過する意味	これは日付が意味的に正しいという意味ではありません	営業日の日付説明を確認することは依然として必要です

🎯 どの方法があなたに合いますか?

フィールドが文字列であるか、正しい構造を持っているかだけ確認すればよい場合

デフォルトのバリデーターで通常は十分ですが、日付の意味を必ずしもチェックするわけではないことに注意してください。

日付が本当に存在するかどうか確認する必要があるなら

FormatCheckerを明示的に有効にし、2026-02-30のような反例で検証してください。

ソースファイルの日付を確認したいなら

まず、日月順序のソースルールを確認し、元のテキストと正規化された値を保存します。

サービスが言語をまたいで展開されている場合

各実装で同じテストセットを別々に実行してください。

❓ よくある質問(FAQ)

1. スキーマは`format: date`を書いたのに、なぜ悪い日付が過ぎるのか?

formatの取り扱いはバリデータの設定に依存します。デフォルトでは日付の意味論はチェックされません。

2. なぜ`2026-02-30`は有効なテスト値なのでしょうか?

日付のように見えますが、2月には30日目はありません。見た目だけに注目すると、こうした問題を見逃してしまいます。

3. 未知のフォーマット名を使うとどうなりますか?

チェック済みとみなすべきではありません。スペルミスは誤った安心感を与えるかもしれません。

4. `03/04/2026`はどのように変換すべきでしょうか?

発生源地域、圃場説明、または明確な一致が必要です。それ以外は、3月4日か4月3日か判別が不可能です。

📝 概要

チェックチェックに合格したことは、データが宣言されたルールを満たしているという意味であり、すべての日付が正しいとは限りません。まず検証者の検査範囲を確認し、より信頼性の高い結果を得るために反例やソースルールで日付処理を修正します。

今すぐ体験:元のフォーマットを保ちながら翻訳を始めるために文書をアップロードしましょう