まえがき
新サービスの企画を練る時、世にあるサービス同士のマッシュアップを考えるのは誰しも通る道です。お手軽に新しいコンテンツが作れるようにみえるんでしょうねぇ。あのサービスのここの部分に注目すれば、もっと良いサービスができるのに！という考えは魅力的です。
ましてや、それを実現するために技術はそれほど敷居も高くないとくれば。。。
某QAサイトの質問を見ても、多くの質問者が、スクレイピングによるコンテンツ収集を行い、新しサービスを立ち上げようとしています。
が、ちょっと待って！
そのスクレイピングを基底とした企画、ホントに上手く回るんでしょうか？
ということで、実体験と私宛に頂いたアドバイスを元に、スクレイピングを基底とした企画の注意点をまとめてみました。
識者の皆様からの追加アドバイスも待ってます！
企画
スクレイピング先とコンタクトを取る
できれば、スクレイピング先とは企画段階でコンタクトをとっておくべきです。
後にトラブルになったときや、緊急対応が必要となる時にお互いに連携が取れていると対処できる幅が広がります。
また、公開されていないAPIやRSS等、自前でスクレイピングするより効率的にコンテンツを提供してもらえる可能性もあります。
そもそもスクレイピング先に迷惑をかけないか？
スクレイピング先に迷惑をかけるようなサービスは当然先はありません。
スクレイピング先がなくなってしまっては、そもそもサービスが成り立たないので。
実は私が運営していたサイトの一つが、機械アクセスが元で、サービス提供ができなくなりました。。。
サービスによってはしょぼいインフラで回ってるサービスもあります。
ここはすごく慎重に、真摯に検討しましょう。
同じターゲットを取り合っていないか？
コンテンツ引用で、同じターゲットを取り合いになるようなサービスであれば、その先にはコンテンツの先細りしかありません。
スクレイピング先のターゲットを取り合うようなサービスはサービスとして無意味です。企画段階で注意しましょう。
コンテンツを引用の範囲以上で使用する事になっていないか？
盗用になっていないか？
加工後に付加価値がつけられるか？
昨今このあたりの評価は厳しくなっています。自己の勝手解釈でコンテンツの二次利用を肯定するのは後のトラブルのもとです。
必要であれば、信頼できる専門家の意見を確認しましょう。
スクレイピング先のサイトポリシーに違反する内容になっていないか？
当然ですが、スクレイピング先の利用の制限に抵触していれば、サービスは継続できません。
2次利用が禁止されていないか？機械アクセスを禁止していないか？等まず確認しましょう。
スクレイピングはコストが掛かることを想定して企画しているか？
やってみればわかりますが、スクレイピングのコードは継続的にメンテナンスが必要なモノです。
スクレイピング先のレイアウト等の変更により、数ヶ月で改修が必要になることも少なくありません。
その変化の監視や、それに伴う改修はサービス提供にあたってのコストとして、計算していますか？
結構もれている検討事項だと思います。
設計
アクセスは適切か？
企画でも書きましたが、スクレイピングの基本は、スクレイピング先に迷惑をかけないことです。
通常のユーザアクセスと同程度のアクセスとなっているか？
アクセスの頻度やアクセスの間隔をスクレイピング先の想定するものから外れないように設計することが重要です。
この時、アクセス頻度や間隔をコントロールできる設計を心がけるべきです。
アクセスで不具合を起こさせてしまったときの連絡方法を確立できているか？
注意深くしていても、想定外の迷惑をかけることがあります。
設計段階から、不具合で先方に迷惑をかけてしまった場合の連絡方法を検討しましょう。
実装は、UserAgentを使用するのが一般的です。
取得情報のばらつきに対してのどのように対処するか？
一般的にスクレイピングで入手できる情報にはばらつきがあります。
フォーマットであったり、そもそもその項目が取れなかったときだったり、そういった場合の想定を設計に組み込む必要があります。
構築/テスト
実装としてアクセスは必要最小限となっているか？
極力スクレイピング先に負荷をかけない実装とする必要があります。
たとえば、キャッシュを作るとか。同じデータへのアクセスを一定期間はさせない工夫をしましょう。
構築/テスト段階ではローカルでテストできるように準備しているか？
構築/テスト段階で、スクレイピング先へアクセスを行うことは極力避けます。
データの加工処理を行う部分は、ダミーデータを使用して、きちんとローカルでテストしましょう。
使用するライブラリの仕様を把握しているか？
アクセスに使用するライブラリの仕様はきちんと把握する必要があります。
他サイトへ影響する部分なので、通常のライブラリを使用する時以上に、きちんと仕様を確認し把握しましょう。
おかしなアクセスや内部でのループ処理が入っていないか？
ループでアクセス先を落としてしまうとか、最悪です。
アクセス処理には極力ループを使用しないように実装し、無理ならそのループに上限を設けて無限ループとならないよう管理します。
取得情報のばらつきに対して適切な回避処理や補完処理を行えているか？
おもに例外処理になると思いますが、決して短時間に再アクセスを行い、更新を確認するような実装にしないで下さい。
アクセス頻度は変えず、入手した情報を適切に補完したり、更新自体を回避する仕組みで実装しなければなりません。
運用
エラー等の監視が必要十分に出来ているか？
非常に重要です。
エラーの発生は自サイトのみならず、スクレイピング先へ問題を派生させている可能性があります。
24H365Dで検出、対応できる体制をとっておく必要があります。
スクレイピング先のレイアウト変更の監視
必要なデータが入手できなくなる可能性が高いです。イベント対応等で臨時変更されるケースもあるので、十分に注意しましょう。
さいごに
スクレイピングを使用したサービスはスクレイピング先と共栄できることが理想です。
できれば企画段階から相談し、サービスの住み分けを提案、両者で利用者の拡大をはかるサービスとして立ち上げましょう。