Computer

Webスクレイピングツール開発の流れ

前回はスクレイピングの入門編として概要をご紹介しましたが、今回はスクレイピングツールの開発の流れを見ていきたいと思います。

スクレイピングの可否

前回、スクレイピングツールを作る前には、APIが使えるかどうかをチェックしてAPIが使える場合はそちらを優先して使うべきだとお伝えしました。

しかしそれ以外にも考慮すべきポイントがあります。

まず前提として、スクレイピングの目的は、情報の解析目的に限定されるものでなければなりません。

例えばですが、スクレイピングしたデータをそのまま使ったウェブサイトなどを公開したり、抽出したデータを販売したりすれば著作権法などに抵触する可能性があります。

アメリカではHiQ Labsというデータサイエンスを使った人事ソリューションを展開する企業がLinkedIn(ビジネスパーソン向けSNS。マイクロソフトが買収)の登録者の公開プロフィールをスクレイピングしてそれを商売のタネに使っているとのことでLinkedInがHiQ Labsにスクレイピングを止めるように求めた裁判がありましたが、カリフォルニアの地方裁判所がスクレイピングを認める判決を下しました。

しかしこれはあくまで地方裁判所の判断であるのと、さらにはこれは日本ではなくアメリカでの判例であることから、これを以って営利利用も可能と考えるのはリスクが残るともいえます。

なので取得したデータを販売したり公開しようと考えている場合はその是非を慎重に考える必要があります。相手が訴訟を起こさない可能性ももちろんありますが、仮に訴訟沙汰となった場合、訴訟への対応にかかる費用や時間、心労は、最終的に裁判所が合法と認めたとしても、得られる対価に見合うものか考える必要があるでしょう。僕個人としては面倒ごとを望まないので、他人のふんどしでしか取れない相撲なら最初からかなり及び腰になると思います。

その上で、ウェブサイトの利用規約を確認する必要もあります。利用規約で明確にスクレイピングを禁止している場合、情報解析が目的だとしてもスクレイピングをするわけにはいきません。

ウェブサイトの利用規約の効力に関しては一定の解釈があり、ただページの隅っこに利用規約ページへのリンクを貼るだけではダメで、利用開始前に利用規約を表示して、ユーザーに規約に同意ボタンを押させるなど、ユーザーの明確な同意を経て初めて効力を持つともいわれます。

具体的には、AppleやAndroidのアプリストアなどに初めてアクセスした時に同意を求められるような感じですね。

利用規約にはスクレイピングを禁止する旨が書かれていても、上記の手続きを踏んで規約に同意をさせるウェブサイトはかなり少ないので、これはかなりグレーになってきます。そのためここも判断は慎重に、個人的には面倒が起きにくい選択をするべきだと思います。

そのため利用規約の事前確認は必須ですし、それに加えて、robots.txtの内容も確認する必要があります。robots.txtは通常、ウェブサイトのルートディレクトリに置かれていて、クローラーがアクセスしていいかどうか、またアクセスを許可するディレクトリなどが記述されています。robots.txtが存在しない場合は「完全許可」とみなされます。例えばですが、google.comのルートディレクトリにもrobots.txtは置かれていて、事細かに設定されています。

robots.txtは現時点ではまだインターネット標準ではないのですが、長年の慣習があり、またGoogleなどが標準化に向けて動いているようです。提唱されているrobots.txtの仕様についてはこちらを参考にしてください。

技術的な実現性の調査

対象サイトが規約的にスクレイピング可能となったら、次はスクレイピングによる自動化が技術的に実現可能かどうか、またその難易度を評価していきます。

具体的には、スクレイピング対象のウェブサイトのソースコードを眺めてページやデータの構造を把握したり、ページ遷移の際のHTTPリクエストとレスポンスの流れを追い、データ取得の自動化イメージをつかみます。

この段階で主に使うのは、ブラウザに内蔵しているDeveloper Tools(開発者向けツール)と、Debugging Proxy(デバッグ用プロキシ)です。

Developer Toolsはモダンなブラウザならばほぼ内蔵しています。よくわからない場合はとりあえずChromeを使いましょう。

Debugging Proxyは、WindowsならばFiddler、MacならばProxymanというアプリがオススメです。Mac界隈では長らくCharlesという有償製品の一択だったのですが、使用頻度の割に価格がそこそこ高いのと、個人的にはFiddlerに慣れていたため、Charlesを使いやすいと思えないのがネックでした。

その点Proxymanは基本機能は無料で、使い勝手も直感的ながら非常に高機能です。一部の機能が有償版でのみ利用可能だそうですが、スクレイピングの目的においては無料版で全く問題ありません。

基本的にはDeveloper ToolsのWeb Inspectorを使って、抽出対象のデータがどういうHTMLのDOM構造になっているのかを把握します。この時、ブラウザが認識している仮想的なDOMだけでなく、HTMLソースコードも確認して、DOMがJavaScriptで動的に生成されたものでないかもチェックしておきます。Ajaxを使用している場合は、Developer Toolsでネットワーク通信を閲覧してどういう方法でデータを取得しているのかを調査します。

この段階では、リクエストURL、パラメータ、ヘッダ(CookieやReferrerなど必要になることが多い)、レスポンスの形式などを把握しておくといいでしょう。

複数ページにまたがるリクエストの順番や流れを追いたい場合は、Developer Toolsでは面倒な場合もあるので、その場合はFiddlerやProxymanでHTTP通信の流れを追います。

近年はHTTPS必須のサイトがほとんどなので、FiddlerやProxymanでHTTPSを復号できるように設定しておきましょう。これをしておかないと、実際の通信部分を覗くことができません。

実行と出力の方法

HTTPの流れを追い、HTMLのパーシングでスクレイピングできそうだとイメージが湧いたら、スクレイピングツールをどのように実行して、抽出したデータをどのように出力するかを考慮します。

実行に関しては、その都度自分でコマンドを叩くなりボタンを押して抽出を開始したいという場合もあれば、決まった時間に自動的に実行したいというニーズもあるでしょう。実行場所は自分のPCなのか、常時稼働しているサーバー上で行いたいというケースもあります。

出力に関しては「テキストファイルにCSV形式でエクスポートする」というニーズが一般的かと思いますが、ExcelやPDFなどの形式に変換したい、HTML形式でメール送信したい、データベースに保存したい、別の社内APIに送信したい、失敗した場合にメール通知したいなどの要件もあるでしょう。個人的にはデータベースに保存して、メールでサマリーを通知していました。

言語やフレームワークの選定

ここまで要件を詰めてきたら、ツールを作るための言語やフレームワーク、ライブラリを考えます。

言語に関しては開発者の慣れや好みで選んでいいと思いますが、既存のライブラリで必要な要件を満たせるかを検討しておきましょう。

メジャーな言語であればサードパーティのライブラリも充実していると思いますが、言語によってはマイナーなライブラリが揃っていないことはよくあります。例えばExcelやPDFにエクスポートしないといけないのに、それを操作するオープンソースのライブラリがない、Gmailで認証付きのSMTPからメールを送信するライブラリが見当たらない。あるにはあるけど、機能が貧弱すぎるので、そのまま使うことはできず、自分で相当な作り込みを迫られる可能性がある、などが考えられます。

また、実行する場所も言語選定に影響します。例えば、クラウドやVPS上のLinuxサーバーで定期的に実行するプログラムの場合、Excelのマクロなどで開発したスクレイピングツールは実行できません。ひょっとすると裏技で実行できるのかもしれませんが、開始前から困難が予想されます。

個人的にオススメの言語やフレームワークなど

これは完全に僕個人の経験と主観に基づいた意見ですが、僕はスクレイピングツールを作るときはJava言語を使用しています。

その理由は、個人的にはJava言語が使い慣れているのもありますが、Javaは、サードパーティのフレームワークやライブラリがとにかく充実しているからです。

上に挙げたようなHTTP通信やHTML解析、メール送信やデータベース関連などほとんどの目的に対して既に完成度が極めて高いライブラリやフレームワークが存在するので、自分はスクレイピングのロジックに集中することができるのです。

またJavaはWrite Once Run Anywhereな言語のため、例えばMacで開発したプログラムを、WindowsやLinuxサーバー上で動かすことができます。

そして、Java開発において僕が好んで使用するのは以下のものです:

Spring Boot - Javaの開発をとにかく簡単で楽しくしてくれるフレームワーク。依存性管理、キャッシュ、スケジューリング、REST公開、SOAP/Restクライアントなど、Spring Frameworkの機能が利用可能。Spring BootがJavaを救ったと言っても過言でないとすら思っています。

Spring Shell - Springで作ったプログラムをコマンドラインで操作可能なシェルプログラム化するツール。対話形式のシェルに加え、スクリプトで複数コマンドをまとめて実行させることもできる。

Jsoup - HTML解析ツール。HTTP通信もでき、jQueryセレクタと扱いやすいAPIを備える。

HtmlUnit - ヘッドレス(ウィンドがない)ブラウザ。元々はテスト用途だが、実際のブラウザと同じようにJavaScriptやHTTPリクエストを実行される。Cookieやキャッシュの処理などが自動的に行われるので便利。

Spring Open Feign - 宣言的アノテーションで、コードを書かずにRest APIクライアントを作れる。Ajaxなどでデータを取得している場合に使える

Spring Data JPA - SQLを全く書かずに、どのデータベースにも対応可能。データベースに保存す

Velocity, Java Mail Sender - HTMLメールの生成とメール送信に使用(認証付き+SSL対応)。かなり古いライブラリなので、代替品を探す必要があるかも。

Java ImageIO - 画像の読み取りが必要な場合は、Javaの低レベルなImage APIを使用。PNG、GIF、JPEGなど一般的なフォーマットをピクセル単位で読める。チャートを読み取るくらいならばこれで対応可。

持続可能なスクレイピングを目指して

最後になりますが、スクレイピングツールの開発をする際は、特にサーバーとやり取りを行うHTTP部分は注意深くテストする必要があります。

スクレイピングを行う側は、単にデータを抽出できるだけでなく、なるべく相手側のサーバーに無駄な負荷をかけないように配慮することも求められます。

例えば、HTTP Keep AliveやSessionID Cookie、Cache Controlなどがあります。ここの詳細にはここでは立ち入りませんが、これらの指示やクッキーを無視すると、サーバー側で必要以上のリソースを食う結果になりかねません。

そのためには、HTTPやサーバーサイドに関する知識もある程度身につけるべきですし、「もし自分がサーバー運営側のエンジニアの立場だったら」と想像することは非常に重要だと思います。

理想は、サーバー管理者もスクレイピングされていることにそもそも気づかないか、仮に気づいても「対応するのも面倒だし、この程度なら、まいっか」と思われるような状態だと思います。

マナーの悪いスクレイパーが横行すれば、サーバー側も対策を行い、場合によってはスクレイピングそのものができなくなるような規約変更や技術的な対応をされてしまう可能性があります(サイト自体が公開されている限り、技術的な対応はかなり難しいのが現実ですが)ので、ダウンロードした取得したデータを非効率的な方法で処理しても問題ありませんが、「通信部分だけはとにかくお行儀よく」を心がけましょう。

スクレイピングツールは正しく活用すれば強力なツールになるので、スマートに活用して日々の仕事や生活を効率化させ充実させていものですね。

-Computer

Copyright© dawaan , 2020 All Rights Reserved.