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

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

ただいまの
回答率

90.85%

  • PHP

    18183questions

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

  • Ruby on Rails

    6374questions

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

  • スクレイピング

    225questions

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

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 3
  • VIEW 732

te2ji

score 9982

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

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

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

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

 企画

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

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

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

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

 設計

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

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

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

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

 構築/テスト

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

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

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

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

 運用

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

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

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • 退会済みユーザー

    2017/01/04 08:28

    こちらの質問が他のユーザから「問題・課題が含まれていない質問」という指摘を受けました
    teratailでは、漠然とした興味から票を募るような質問や、意見の主張をすることを目的とした投稿は推奨していません。
    「編集」ボタンから編集を行い、質問の意図や解決したい課題を明確に記述していただくと回答が得られやすくなります。

  • m6u

    2017/01/04 09:25

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

    キャンセル

  • te2ji

    2017/01/04 09:45

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

    キャンセル

回答 3

checkベストアンサー

+4

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/01/04 11:22

    ご指摘の点、全て考慮から抜けておりました。

    特に運用面の継続コストはかなり重要にもかかわらず、自身でやってしまうため、エラー監視程度しか考慮しておりませんでした。

    ありがとうございます。

    キャンセル

  • 2017/01/12 14:38

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

    キャンセル

+3

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/01/04 09:50

    プログラミングを担当する人がが気にすべき点として、非常にシンプルでわかりやすいです。
    思考が整理された思いです。

    確かに、プログラミングの観点から見た時、スクレイピングそのものに必要な考慮点はアクセス頻度だけですね。
    cron等のタイマーでの実行も考慮点として、追記したいですね。

    ありがとうございます。

    キャンセル

-3

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/01/05 11:36

    非常にわかりやすい反応でうれしいのですが、今回はスクレイピングする側の立場で、質問しているため、このような表現になっています。(初稿は本音ダダ漏れになってしまいましたがw)

    記述いただいた内容は、企画段階で考慮すべき内容と理解しています。
    よく考えれば、コンテンツホルダーとの調整ができれば、引用の範囲を超えた使用もOKなので、
    > ・コンテンツを引用の範囲以上で使用する事になっていないか?
    に追記ですね。

    キャンセル

  • 2017/01/05 11:41

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

    キャンセル

  • 2017/01/05 11:56 編集

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

    キャンセル

  • 2017/01/05 12:18

    主従の基準を数値などで明確にはできないことと、いまのところ著作権違反は親告罪であること。
    この二点により、著作者が「それは引用ではなく盗用だ」と言ってくればトラブルになるし、双方が納得しなければ最終的には裁判しかないですね。

    この辺はWelq問題関連で様々な人がわかりやすい記事を書いているので、その辺りをググってみるといいのでは。

    まとめる際にはぜひWelq他パクリサイト問題へのリンクもいれてください。

    キャンセル

  • 2017/01/05 12:23

    ググっても私の今の理解ではその正当性の評価が出来ないんですよねぇ^^; Welq 関連はそれこそ素人がコンテンツを量産しているので、全然信用できない。

    「理解しやすく正確な内容が記載された弁護士等のサイト(ちゃんと裏付けのあるサイト)」をご紹介いただければ、私の理解も深まるのですが。

    キャンセル

  • 2017/01/05 12:26

    それは自分で調べてよ

    キャンセル

  • 2017/01/05 13:17

    けっきょくそんな回答になっちゃいますよね。

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

    キャンセル

  • 2017/01/05 13:23 編集

    当該行為が著作権法に言う「引用」にあたるかどうかも検討の余地があります。

    たとえば、図書館のOPACサイトからスクレイピングで情報を収集する場合。判例では、「題号」は著作物性を有しないとされていますので、引用に対する著作権の制限以前に、侵害され得る権利が成立していないと言えます。 実際例えば、「Librahack事件」では図書館側・検察側とも著作権侵害事件として扱って**いません**でした。あくまでもシステムの仕様を超えるアクセスを問題にしたのでした。

    他人のコンテンツを使って楽して儲けるな、という心情的な反発はわからないでもないです。WELQでやっていたことなどはその通りで、元ネタを集めるのにスクレイピング的な手法も使っていたのではないかと想像されます。

    ただ、それを「泥棒」といったわかりやすい表現に切り縮めて一律に否定してしまったのでは、コンテンツの自由 (フリー) な流通でさえ指弾されることになりかねません。法的な問題について主張をなさるのであれば、やはり信頼できる専門家の見解を参考にし、それらに則った形で主張されるべきと思います。

    キャンセル

  • 2017/01/05 13:32

    > 信頼できる専門家の見解
    妥当ですね。ここは指標としてあまり攻めた書き方するのを避けたいところですね。
    信頼できる指標があると助かるのですが、ケースバイケースの世界でもありそうだし。
    私はこのあたりの議論にできるだけ巻き込まれたくない派です。

    ちなみにですが、「Librahack事件」はシステム側が問題を抱えていたとして、不起訴になったはずです。ので「アクセスを問題」とするのはミスリードだと思いますよ。

    キャンセル

  • 2017/01/05 15:21 編集

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

    キャンセル

  • 2017/01/05 16:50

    おぉ。確かに起訴猶予みたいですね。失礼しました。
    私もミスリードだw

    裁判に上がっていない件を根拠にするのはお互い適切でなかったですね。
    裁判されていない件は、あくまで白でも黒でも無く、何も根拠ある判断がされていないものとして語らなければいけませんでした。

    この場合は、「Librahack事件」では、そのアクセスは「有罪とも無罪とも判断されておらず」、そのスクレイピングされたデータの著作権に関しても「有罪とも無罪とも判断されていない」。つまりどのような引用をしても印象の話でしか無いってところです。

    やっぱりこのあたりは素人が手をだすと面倒くさいところですね^^;
    巻き込まれたくない派としては、あまり深く触りたくない部分ですw

    キャンセル

  • 2017/01/06 14:02

    有罪無罪を問題にしているのではなく (それ以前の起訴不起訴や、逮捕されるかどうかを問題にしているのでもなく)、法律問題についての主張は法律の専門家による解説を参考にしてやりませんか、と提案しただけです (たとえばプログラミングについて、未経験の素人さんが適当なことを言っているのを聞いて、苦笑したことはありませんか。そんな感じです)。

    なにか問題が起こってもいないのに弁護士などに相談するというのも、割に合わないですね。
    - お客さんとの話をすすめていくなかで問題や危惧を感じた時点で、法律職の人に相談するというのでもいいと思います。まずは相談料だけですみます (相談の結果、継続した支援が必要と思えばあらためて依頼する)。
    - お客さんが、法務部のあるような大きな会社であれば、そこでプロジェクトの内容をチェックしてもらうようお願いするというのもいいかもしれません (言質を取っておくという意味も含めて)。
    - あと、個人的な意見としては、やばそうだと感じたら躊躇せずお断りする (逃げる) という機転は大事ですねえ。

    役に立たないコメントですみません。

    キャンセル

  • 2017/01/06 14:26

    > 法律問題についての主張は法律の専門家による解説を参考にしてやりませんか
    私は信頼できる参考元を持たないので、主張なんてやりませんよ。って立場です。
    すでに書いたとおり、自分で相談してね。って感じでまとめることになると思います。

    > なにか問題が起こってもいないのに弁護士などに相談するというのも、割に合わないですね。
    転んでから相談するより全然いいと思いますよ。私は事前に法無職の方に相談することで、危機回避したことが多数あります。まぁ、相談相手は弁護士ではなく、法務部門でしたが。
    あの人たちすげぇよ!

    ホントは企画段階では一番の肝になる点かもしれないので、ちゃんと良い参考元を入手できるといいんですけどねぇ。なかなか難しいですね。

    キャンセル

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

  • ただいまの回答率 90.85%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

  • 解決済

    RubyでWebスクレイピングしたい

    Rubyを使ってWebスクレイピングしたいと思っています。 しかしどうすれば実現できるのかわかりません。 どなたかRubyを使ってWebスクレイピングする にあたって必要なライブラ

  • 解決済

    yahooapiでスクレイピングする

    yahooapiで情報をスクレイピングできると聞いたのですが、スクレイピングのサイトは見つかりますが、apiから情報をスクレイピングする方法が載っていないので困っています。 スク

  • 受付中

    フレーム内のデータをWebスクレイピングしたい。

    フレーム内のデータをWebスクレイピングしたいのですがうまくいきません。 フレーム内に表示されているページに直接アクセスするとJavascriptでフレームの親ページにとばされて

  • 解決済

    Ruby openuri スクレイピング

    Rubyで画像ダウンロードを行うコードを書いています。 chromedriverを使いbing検索を行い画像URLを所得し、open可能なURLを厳選するコードなのですが、厳選する

  • 解決済

    RoRでスクレイピングでページを作ってみたい

    私は現在Ruby on Railsを使ってサービス開発をしています。 中高生向けのサービスを作っており、学校ごとのページをつくりたいのですが、自分で全てのページを作ると大変なので、

  • 解決済

    スマホアプリのスクレイピング

    スマホで提供されているメルカリアッテの商品情報をスクリプトで収集したいのですが、ログインサイトにPOSTする事が出来ません。 よくみると、リクエストヘッダーにIDとゆう物が生成され

  • 解決済

    スクレイピングについて

     前提・実現したいこと 質問 PythonでWikipediaから、情報をスクレイピングするシステムを作っています。 情報を取り出すのは成功したのですが、タグが邪魔です。 どうすれ

  • 受付中

    python , スクレイピング

    def url_to_html(url): res = urllib.request.urlopen(url) data = res.read() html = data.deco

同じタグがついた質問を見る

  • PHP

    18183questions

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

  • Ruby on Rails

    6374questions

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

  • スクレイピング

    225questions