今日やったこと#
データ監査を最古優先へ変更#
- 日次監査の対象を固定的な分割から、未確認または確認日が古い項目を優先する方式へ切り替えた。
- 一度に扱う件数を制限しつつ、途中で失敗して保存されなかった項目は次回も古い対象として再試行されるようにした。
- 全件、分割、対象指定の既存モードは残し、通常実行だけを最古優先に変更した。
- 選択順、件数制限、失敗後の再試行を自動テストで固定した。
監査結果を公開地図へ確実に反映#
- データ監査が成功した後にも公開処理を起動し、監査が保存した最新データを公開地図へ反映する経路を追加した。
- 公開処理が常に主ブランチを取得するようにし、機械実行が作成した更新でも古い状態を配信しないようにした。
- 監査と公開の関係を生成ドキュメントへ反映し、運用説明を現在の構成に合わせた。
公式拠点の判定を強化#
- 公式サイト内のリンクに加え、クロール規則を尊重しながらサイトマップと構造化データから拠点候補を探せるようにした。
- ニュース、規約、採用、製品、PDFなどを現在地の確認根拠から外し、公式の拠点・連絡先ページを優先するようにした。
- 都市名だけの一致では現在の拠点を確認済みにせず、企業名と番地を含む根拠がそろった場合だけ確認済みにするよう厳格化した。
- 根拠を取得できない項目は削除せず要確認として残し、誤検出しやすい語句を候補から除外した。
判断と学び#
固定的な分割監査は全体を均等に回しやすい一方、途中で失敗した対象が次の周期まで後回しになる。最終確認日の古さを基準にすると、保存できなかった対象を自然に再試行でき、未確認項目も先に減らせる。
座標が正しいことと、現在もその場所に拠点があることは別の事実だ。都市名だけの一致や過去のニュースを根拠にせず、公式ページ上で企業名と具体的な住所を確認することで、確認済みの意味を明確にできる。
監査結果が主ブランチへ保存されても、公開処理が起動しなければ利用者が見る地図は更新されない。データ更新と再配信を一つの完了経路として検証する必要がある。
検証#
- 最古優先の選択、失敗時の再試行、件数制限を確認するテストを追加し、継続的インテグレーションが成功した。
- 監査完了を契機に主ブランチを公開する設定をテストし、実際の監査完了後に公開処理が成功した。
- クロール規則、サイトマップ、構造化データ、根拠として不適切なページの除外、都市名だけの誤判定をテストした。
- 追加修正後も継続的インテグレーションと公開処理が成功した。
次にやること#
- 要確認となった項目は未完了として、現在地を示す公式根拠を継続して確認する。
- 最古優先の監査が一巡するまで、失敗した対象が次回へ残ることと処理件数の偏りを観察する。
- 監査完了後の再配信が継続して動作するかを運用の中で確認する。