【要約】官公庁のサイトはスクレイピングしていいのか — robots.txt を4サイト実測したら全部ダメだった [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が補助金情報を自動収集しようとした際、官公庁サイトの robots.txt が示す意図を誤解し、規約違反を犯すリスクに直面した。具体的には以下の問題がある。
- ・robots.txt が 401 や 403 を返し、アクセスを拒否しているケース。
- ・robots.txt が HTML を 200 OK で返し、誤って「全許可」と判定されるリスク。
- ・robots.txt が存在しない場合の、許可か禁止かの判断の難しさ。
// Approach
規約を遵守しつつ、確実にデータを取得するため、解析ロジックの厳格化と API 優先の設計を採用した。以下のステップで実装している。
- ・Content-Type を確認し、text/plain 以外は禁止と判定する。
- ・robots.txt が 401/403 の場合は、自動アクセスを拒否とみなす。
- ・HTML 解析の前に、jGrants 等の公式 API を優先的に探索する。
- ・Crawl-delay に従い、自身のレート制限を調整する。
- ・「取得しなかった理由」をログに記録し、失敗と禁止を区別する。
- ・User-Agent に連絡先を記載し、クローラの透明性を確保する。
// Result
堅牢なクローラ実装により、規約違反を回避しつつ、効率的なデータ収集基盤を構築した。成果は以下の通りである。
- ・jGrants の API 利用により、正確なデータを取得可能にした。
- ・「失敗」と「禁止」を区別するログにより、運用時の判断を迅速化した。
- ・GitHub Actions を活用し、新着情報の自動検知を実現した。
Senior Engineer Insight
> 外部リソースに依存するシステムにおいて、この「防御的スクレイピング」の考え方は極めて重要だ。特に robots.txt が HTML を返すような「壊れた」サイトへの対策は、実戦的な知見である。API がある場合はそちらを優先する設計は、スケーラビリティと安定性の観点からも正解だ。マナーとしての User-Agent 記載も、運用リスク低減に寄与する。