質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
スクレイピング

スクレイピングとは、公開されているWebサイトからページ内の情報を抽出する技術です。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

Q&A

解決済

3回答

2071閲覧

スクレイピング使用サービスの企画から運用で考慮しなければならないこと

退会済みユーザー

退会済みユーザー

総合スコア0

スクレイピング

スクレイピングとは、公開されているWebサイトからページ内の情報を抽出する技術です。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

1グッド

3クリップ

投稿2017/01/03 23:21

編集2017/01/04 11:14

スクレイピングは、お手軽にコンテンツが作成できるようになるためか、利用したいという要求をなかなかおさえることが出来ません。

個人的にはスクレイピングによる被害を被ったこともあり、スクレイピング慎重派なのですが、私の考慮できる範囲は、個人商店レベルなので、きちんとした業務レベルで利用されている方々の知見をいただければと考えました。

つきましては、スクレイピングにおける技術ポイントや注意点等を教わりたいです。

私の考えるポイントは以下のとおりです。(思いつきで書いてます。すみません^^;)
不足点の指摘やご意見をいただけないでしょうか。

企画

・そもそもスクレイピング先に迷惑をかけないか?

・コンテンツを引用の範囲以上で使用する事になっていないか?
盗用になっていないか?加工後に付加価値がつけられるか?

・スクレイピング先へのアクセスを阻害する企画になっていないか?
コンテンツ引用等で、同じターゲットを取り合いになっていないか?

・スクレイピング先のサイトポリシーに違反する違反する内容になっていないか?
利用の制限に抵触していないか?2次利用が禁止されていないか?機械アクセスを禁止していないか?等

設計

・アクセス頻度は適切か?
通常のユーザアクセスと同程度のアクセスとなっているか?

・アクセスで不具合を起こさせてしまったときの連絡方法を確立できているか?
UAで知らせる等の実装は出来ているか?

・取得情報のばらつきに対しての処理は許容できる範囲か?

・使用するライブラリがあれば、その実績や機能に問題はないか?

構築/テスト

・実装としてアクセスは必要最小限となっているか?
キャッシュを取るとか。

・テスト段階ではローカルでテストできるように準備しているか?
データの加工処理を行う部分はちゃんとローカルでテスト出来ているか。

・使用するライブラリの仕様を把握しているか?
おかしなアクセスや内部でのループ処理が入っていないか?

・取得情報のばらつきに対して適切な回避処理や補完処理を行えているか?

運用

・エラー等の監視が必要十分に出来ているか?

ある程度ご意見いただけたら、Qiitaとかにまとめようと思っています。

ikedas👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/01/04 00:25

受け売りの記事をQiitaに載せることにならないですか? Qiitaで指摘されたことをこっちに持ち帰ってくることのないよう、確かな見識のもとにお願いします。
退会済みユーザー

退会済みユーザー

2017/01/04 00:45

現時点での私の知見として、理解した内容でQiitaJにまとめますよ。ただ、Qiitaで指摘されたことをこっちに持ち帰ってくることはそれほど悪いことではないと思いますが。
guest

回答3

0

ベストアンサー

スクレイピングにおける技術ポイントや注意点等を教わりたいです。

「対象予定のサイト数は?」「コストに見合った対価は得られるのか?」「RSSやAPIで置き換えられないか?」は企画段階で検討したほうが良いでしょうね。

スクレイピングは情報を取得する手段の一つでしかなく、
競合となるAPIやRSSと比べると、好き勝手に記述出来るHTMLを解析して自分の望む情報を抜き取る手法は極めて原始的なものとなります。

一般的にはCSSセレクター的な文字列とURLの対応表を保存しておき、
jQuery的なライブラリを用いてCSSセレクターから要素にアクセスして、その配下のノードツリーを根こそぎ抜き出す手法になるかと思います。
もし、それで許容できない精度の情報が欲しい場合1サイト毎にハンドメイドのソースコードが必要になります。

もちろん、どちらの手法も対象のサイトがリニューアルすると使い物にならないので、数カ月おきにメンテが必要です。
しかし、スクレイピングを自動化することで苦労なしに価値ある情報が手に入ると錯覚している人が多いのが現状です。
スクレイピングは数ヶ月で役に立たなくなる使い捨てのコードにしかならないのです。

会社的にはエンジニアがコードを書くコストと、バイトを雇ってコピペさせるコストはどちらが安いですか?で考えるべき問題となります。
もし上司や経営者が自動化することで一生メンテが必要ないと誤解している場合、全員が不幸になります。
その辺の誤解がないように、上司や経営者に根回ししておくべきでしょうね。

投稿2017/01/04 01:54

miyabi-sun

総合スコア21158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/01/04 02:22

ご指摘の点、全て考慮から抜けておりました。 特に運用面の継続コストはかなり重要にもかかわらず、自身でやってしまうため、エラー監視程度しか考慮しておりませんでした。 ありがとうございます。
退会済みユーザー

退会済みユーザー

2017/01/12 05:38

おかげさまで理解が進み、まとめることが出来ました。ありがとうございます。
guest

0

スクレイピング目的のアクセス自体は、自作ブラウザでのアクセスと同等なので、それ自体は問題ないでしょう。

問題は、アクセス頻度だけでしょう。メジャーなブラウザでもF5連打とかだとサイトによっては迷惑かもしれませんし。
設計上のアクセス頻度だけじゃなくて、バグによる高頻度アクセスも注意ですね。複数回ページを取得するプログラムの場合は、そのあたり十分なテスト環境でのテストが必要です。まあ、よくあるパターンとしてプログラムでの取得は1度で、それをcron等のタイマーから起動すると言うことであれば、あまり心配は無いかと思いますが。

サイトに対しての考慮点は以上だけだと思います。
あと、お書きのことはスクレイピングしてから後のことなので、プログラムの品質の話ですね。それと著作権など権利関係の問題は、スクレイピングでもブラウザからのコピペでも同じ一般的な話です。

投稿2017/01/03 23:56

編集2017/01/03 23:58
otn

総合スコア84423

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/01/04 00:50

プログラミングを担当する人がが気にすべき点として、非常にシンプルでわかりやすいです。 思考が整理された思いです。 確かに、プログラミングの観点から見た時、スクレイピングそのものに必要な考慮点はアクセス頻度だけですね。 cron等のタイマーでの実行も考慮点として、追記したいですね。 ありがとうございます。
guest

0

泥棒の臭いしかしない質問者ですね。

「スクレイピングは、お手軽にコンテンツが作成できるようになる」と書いてますが、言っている意味が全然わかりません。
普通に文章を作成して、その中で主従の「従」となる程度の分量で引用し、内容的にも齟齬のないものにしようと思ったら、結局多くの人手(時間、労力)が必要となります。

決して「お手軽にコンテンツが作成できるようになる」はずがないのに、どうしてそういう発想になるのか?

スクレイピングで自動化するということは膨大な量を取ってくるということでしょうけど、それら膨大な量に対して人力で著作権に問題が無いように付加価値をつけられるか? まあ不可能だと思いますよ。
だったら最初からスクレイピングなんか自動化せずに、人力で検索(要するに普通に本や論文などを執筆する人がやる調査)をしたほうが効率いいでしょう。

繰り返しますが泥棒はやめましょう。
自分たちで勝手な理屈をつけ勝手な基準を決め、「これは泥棒ではない、引用だ」などと強弁するのはやめましょう。どこかのパクリ医療情報サイトを作っていた企業みたいに大炎上しますよ。

投稿2017/01/04 23:28

zico_teratail

総合スコア907

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/01/05 02:36

非常にわかりやすい反応でうれしいのですが、今回はスクレイピングする側の立場で、質問しているため、このような表現になっています。(初稿は本音ダダ漏れになってしまいましたがw) 記述いただいた内容は、企画段階で考慮すべき内容と理解しています。 よく考えれば、コンテンツホルダーとの調整ができれば、引用の範囲を超えた使用もOKなので、 > ・コンテンツを引用の範囲以上で使用する事になっていないか? に追記ですね。
zico_teratail

2017/01/05 02:41

te2jiさんクラスの優秀な方が低レベルな迷惑行為を実際にやるわけがないとは思いますが、この質問を見た「低レベルなことをやりそうな輩」に釘を刺しておくためにも、「盗用と引用」の区別は厳しく書いておくべきだと考えております。
退会済みユーザー

退会済みユーザー

2017/01/05 02:56 編集

引用の定義は個人的によく理解できていないので、どちらか理解しやすく正確な内容が記載された弁護士サイト等があれば教えてください。まとめるときにリンクを追記したいと思います。
zico_teratail

2017/01/05 03:18

主従の基準を数値などで明確にはできないことと、いまのところ著作権違反は親告罪であること。 この二点により、著作者が「それは引用ではなく盗用だ」と言ってくればトラブルになるし、双方が納得しなければ最終的には裁判しかないですね。 この辺はWelq問題関連で様々な人がわかりやすい記事を書いているので、その辺りをググってみるといいのでは。 まとめる際にはぜひWelq他パクリサイト問題へのリンクもいれてください。
退会済みユーザー

退会済みユーザー

2017/01/05 03:23

ググっても私の今の理解ではその正当性の評価が出来ないんですよねぇ^^; Welq 関連はそれこそ素人がコンテンツを量産しているので、全然信用できない。 「理解しやすく正確な内容が記載された弁護士等のサイト(ちゃんと裏付けのあるサイト)」をご紹介いただければ、私の理解も深まるのですが。
退会済みユーザー

退会済みユーザー

2017/01/05 04:17

けっきょくそんな回答になっちゃいますよね。 > ・コンテンツを引用の範囲以上で使用する事になっていないか? > 盗用になっていないか?加工後に付加価値がつけられるか? 盗用/引用の判断は弁護士に相談。とか「自分で調べてよ」を追記で対応ですね。
ikedas

2017/01/05 04:23 編集

当該行為が著作権法に言う「引用」にあたるかどうかも検討の余地があります。 たとえば、図書館のOPACサイトからスクレイピングで情報を収集する場合。判例では、「題号」は著作物性を有しないとされていますので、引用に対する著作権の制限以前に、侵害され得る権利が成立していないと言えます。 実際例えば、「Librahack事件」では図書館側・検察側とも著作権侵害事件として扱って**いません**でした。あくまでもシステムの仕様を超えるアクセスを問題にしたのでした。 他人のコンテンツを使って楽して儲けるな、という心情的な反発はわからないでもないです。WELQでやっていたことなどはその通りで、元ネタを集めるのにスクレイピング的な手法も使っていたのではないかと想像されます。 ただ、それを「泥棒」といったわかりやすい表現に切り縮めて一律に否定してしまったのでは、コンテンツの自由 (フリー) な流通でさえ指弾されることになりかねません。法的な問題について主張をなさるのであれば、やはり信頼できる専門家の見解を参考にし、それらに則った形で主張されるべきと思います。
退会済みユーザー

退会済みユーザー

2017/01/05 04:32

> 信頼できる専門家の見解 妥当ですね。ここは指標としてあまり攻めた書き方するのを避けたいところですね。 信頼できる指標があると助かるのですが、ケースバイケースの世界でもありそうだし。 私はこのあたりの議論にできるだけ巻き込まれたくない派です。 ちなみにですが、「Librahack事件」はシステム側が問題を抱えていたとして、不起訴になったはずです。ので「アクセスを問題」とするのはミスリードだと思いますよ。
ikedas

2017/01/05 06:21 編集

そうですね>>不起訴。不起訴決定までは問題としていたという趣旨です。 (追記訂正) 検察は起訴猶予処分としています。不起訴だと「もう問題にしない」という意味ですが、起訴猶予は将来の再捜査・起訴の可能性を否定していないということに、論理的にはなります。まあ細かいことですけれど。
退会済みユーザー

退会済みユーザー

2017/01/05 07:50

おぉ。確かに起訴猶予みたいですね。失礼しました。 私もミスリードだw 裁判に上がっていない件を根拠にするのはお互い適切でなかったですね。 裁判されていない件は、あくまで白でも黒でも無く、何も根拠ある判断がされていないものとして語らなければいけませんでした。 この場合は、「Librahack事件」では、そのアクセスは「有罪とも無罪とも判断されておらず」、そのスクレイピングされたデータの著作権に関しても「有罪とも無罪とも判断されていない」。つまりどのような引用をしても印象の話でしか無いってところです。 やっぱりこのあたりは素人が手をだすと面倒くさいところですね^^; 巻き込まれたくない派としては、あまり深く触りたくない部分ですw
ikedas

2017/01/06 05:02

有罪無罪を問題にしているのではなく (それ以前の起訴不起訴や、逮捕されるかどうかを問題にしているのでもなく)、法律問題についての主張は法律の専門家による解説を参考にしてやりませんか、と提案しただけです (たとえばプログラミングについて、未経験の素人さんが適当なことを言っているのを聞いて、苦笑したことはありませんか。そんな感じです)。 なにか問題が起こってもいないのに弁護士などに相談するというのも、割に合わないですね。 - お客さんとの話をすすめていくなかで問題や危惧を感じた時点で、法律職の人に相談するというのでもいいと思います。まずは相談料だけですみます (相談の結果、継続した支援が必要と思えばあらためて依頼する)。 - お客さんが、法務部のあるような大きな会社であれば、そこでプロジェクトの内容をチェックしてもらうようお願いするというのもいいかもしれません (言質を取っておくという意味も含めて)。 - あと、個人的な意見としては、やばそうだと感じたら躊躇せずお断りする (逃げる) という機転は大事ですねえ。 役に立たないコメントですみません。
退会済みユーザー

退会済みユーザー

2017/01/06 05:26

> 法律問題についての主張は法律の専門家による解説を参考にしてやりませんか 私は信頼できる参考元を持たないので、主張なんてやりませんよ。って立場です。 すでに書いたとおり、自分で相談してね。って感じでまとめることになると思います。 > なにか問題が起こってもいないのに弁護士などに相談するというのも、割に合わないですね。 転んでから相談するより全然いいと思いますよ。私は事前に法無職の方に相談することで、危機回避したことが多数あります。まぁ、相談相手は弁護士ではなく、法務部門でしたが。 あの人たちすげぇよ! ホントは企画段階では一番の肝になる点かもしれないので、ちゃんと良い参考元を入手できるといいんですけどねぇ。なかなか難しいですね。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問