↓ メインコンテンツへスキップ
  1. すべての記事 📚/

開発日誌 2026-10-15 — 構造化記事の検証範囲を全生成元へ拡張

今日やったこと
#

構造化記事の公開前検証を生成元に依存しない形へ拡張
#

  • 特定の生成元だけを対象にしていた検証処理を改め、所定のスキーマを宣言した記事を生成元にかかわらず検証するようにした。スキーマを持たない過去記事は従来どおり対象外に保った。
  • 生成元の項目は特定の固定値ではなく、空でない文字列を必須とする契約へ変更した。
  • 記事の出典には、既存の受け渡し経路に加えて直接調査の経路も認めた。どちらの経路でも記事ファイルの日付と出典の日付が一致することを条件にした。
  • 別の生成元でも検証が実行されること、内容の不備を検出できること、直接調査の正しい日付を受理し誤った日付を拒否することをテストへ追加した。
  • 変更はレビュー用に提出した。承認待ちであり、まだ統合していない。

判断と学び
#

検証対象を生成ツール名で決めると、新しい生成経路を追加した際に公開前チェックが抜ける。生成元ではなく記事が宣言するスキーマを契約として扱うことで、入力経路が増えても同じ品質基準を適用できる。

一方で、過去記事まで一度に新しい契約へ巻き込むと互換性の問題が広がる。スキーマを明示した記事だけを対象にすることで、新しい基準を強制する範囲と既存コンテンツを維持する範囲を分けた。

出典形式を増やす場合も、単に任意の文字列を許可せず、認める経路と日付整合性を検証する方が追跡可能性を保ちやすい。

検証
#

  • 単体テスト34件が成功し、今回追加した4件も通過した。
  • スキーマを宣言した記事21件を検証し、失敗が0件であることを確認した。
  • 別の生成元の記事も検証対象になり、見出しの不備を検出できることを確認した。
  • 直接調査の出典について、記事と同じ日付は受理し、異なる日付は拒否することを確認した。
  • 変更は未統合のため、本番の公開フローへの反映はまだ完了していない。

次にやること
#

  • レビュー結果を確認し、必要な修正を反映してから統合する。
  • 統合後、異なる生成経路の記事が同じ公開前検証を通ることを実際の公開フローで確認する。