Blog›Guides

スクレイピングをやめて、ダウンロードを始めよう:プロンプトデータを取得する丁寧な方法

wikiprompt検索UIのスクレイピングは遅く、壊れやすく、サーバーに負担がかかります。公開されているバルクデータセットでは、55,000以上のプロンプトすべてをクリーンな構造化JSONとして取得でき、帰属情報も組み込まれています。

スクレイピングをやめて、ダウンロードを始めよう:プロンプトデータを取得する丁寧な方法

スクレイピングをやめてダウンロードを始めよう:プロンプトデータを取得する丁寧な方法

もし今、/searchに対してヘッドレスブラウザを実行し、結果を1クリックずつページングし、パースするために作られたわけではないHTMLを解析しているなら、この投稿はあなたのためのものです。もっと速い方法があります、そしてそれは人間のふりをする必要はありません。

私たちはトラフィックを見ています。毎週、数台のスクレイパーがwikiprompt.orgの検索ページに、ローテーションするユーザーエージェント、ランダムな遅延、そしてUI変更をリリースしたためにセレクタが壊れたときの時折のリトライストームでヒットしています。それは、壊れるまでは、まあ動きます。その後、誰かがスクレイパーを書き直さなければなりません。なぜなら、CSSクラスをリネームしたり、ページネーションのレンダリング方法を変更したからです。

一方、カタログ全体、55,000以上のプロンプトは、ミリ秒単位で応答し、何回聞かれても気にしないJSONエンドポイントの背後にあります。

サイトをスクレイピングすることがここで間違ったツールである理由

検索UIのスクレイピングは、代替手段がない場合には合理的なテクニックです。代替手段がある場合には悪いテクニックであり、プロンプトカタログにとって特に悪い理由は次のとおりです:

  • 遅いです。 各/searchページの読み込みは完全なHTMLドキュメントをレンダリングし、クライアントサイドJSを実行し、おそらく20〜40件の結果を返します。すべてを取得するには、不要なレンダリングオーバーヘッドを伴う数千回のページ読み込みが必要です。
  • 壊れやすいです。 あなたはマークアップを解析しています、データではありません。CSSリファクタリング、A/Bテスト、再デザインはすべて、あなたの抽出ロジックを静かに壊します。数字がおかしくなるまで気づかないでしょう。
  • サーバーに負荷をかけます。 スクレイパーはキャッシュされた応答と新しい応答の違いを知りません。すべてのリクエストがキャッシュ破壊クエリになるリスクがあり、スケールが大きくなると、IPがレート制限されたりブロックされたりするまさにそのような負荷パターンになります。
  • 再構築しなければならない構造を捨てます。 レンダリングされたページにはタイトルと説明があります。model、metadata.aspect_ratio、metadata.style、または画像や動画プロンプトに添付される評価スコアをきれいに提供しません。あなたは、私たちがすでにJSONとして公開しているフィールドをリバースエンジニアリングすることになるでしょう。
  • 法的・倫理的により厄介です。 スクレイピングされたHTMLでは、元の著者に帰属をきれいに伝える方法がありません。構造化データにはあります。
  • そのどれも脅しではなく、スクレイピングがあなたに何をもたらすかの説明にすぎません。私たちはあなたにそれをすべてスキップしてほしいと思っています。

    丁寧な方法:バルクデータセット

    私たちはデータセットを公開しています、まさに誰も私たちをスクレイピングする必要がないように。まずマニフェストにアクセスしてください:

    curl "https://www.wikiprompt.org/dataset"

    それはtotal_prompts、すべてのレコードで期待できるrecord_fields、そしてページネーションスキームを返します。次に、/dataset/promptsからレコードを取得します:

    curl "https://www.wikiprompt.org/dataset/prompts?limit=500"

    その単一のリクエストで、1つの応答で最大500件の完全に構造化されたプロンプトレコードを取得できます。ヘッドレスブラウザも、解析するHTMLも、待つレンダリングもありません。各レコードにはすでにslug、url、title、description、content(実際のプロンプトテキスト)、category、tags、media、model、構造化されたmetadataオブジェクト、author、original_source、そして両方のタイムスタンプが含まれています。それはあなたがページからスクレイピングしようとしていたすべてのもので、事前に解析された状態で提供されます。

    ページネーションはオフセットではなくキーセットです。これは、基になるリストがクロール中にシフトしたためにスクレイパーが静かにレコードをスキップまたは重複させた経験がある場合に最も重要な詳細です。各応答のnext URLを、それがnullを返すまで追跡してください。Pythonでの最小限のループ:

    import requests

    url = "https://www.wikiprompt.org/dataset/prompts?limit=500"

    records = []

    while url:

    resp = requests.get(url).json()

    records.extend(resp["records"])

    url = resp.get("next")

    print(len(records), "prompts pulled, zero pages rendered")

    スリープとリトライのロジックも、ユーザーエージェントのローテーションも、セレクタのメンテナンスもありません。カタログ全体が、すべての応答がエッジキャッシュされ、CORS対応(Access-Control-Allow-Origin: *)でブラウザから直接使用できるため、秒単位で実行されるループで完了します。

    スクレイピングでは決して得られなかったもの

    速度に加えて、データセットはレンダリングされたページに使用可能な形で決して存在しなかったシグナルを運びます。手切りリノカット旅行ポスタープロンプトを例に取ると、レコードにはstyle配列とアスペクト比がmetadataに直接含まれており、画像から推測しなければならないようなフィールドです。または建築的な階段を中心に構築されたエディトリアルポートレートでは、modelフィールドが画像スタイルから推測することなく、何がそれを生成したかを正確に教えてくれます。またはキャラクターをクモ形に変形させるプロンプトは、品質評価がすでに添付されており、表示ページを読むスクレイパーがきれいに拾うことは決してないものです。

    すべてのレコードはまた、original_source、つまりプロンプトが由来する元のツイートや投稿へのリンクを保持しています。それが再利用を正当にする部分です:wikiprompt.orgは他の人々によって書かれた公開プロンプトを集約しており、私たちは基になるコンテンツの著者ではなく、データセットから取得するあなたもそうではありません。これらのレコードを使用するときは、ソースとしてwikiprompt.orgと個々のプロンプトのoriginal_sourceの両方にクレジットしてください。私たちは他の人々の投稿に対して正式なライセンスを主張しているわけではなく、私たちは単なるカタログであり、あなたにもそのように扱うようお願いします。

    全体のダンプより狭いものが必要な場合

    完全なデータセットはバルク使用、トレーニングセット、分析、ミラー用です。実際にライブクエリだけが必要なら、/searchをスクレイピングする代わりに検索APIを使用してください。単一のクエリに対して同じ構造化JSONを返し、UIに触れる必要はありません。エージェントを構築しているなら、MCPサーバーは検索、取得、さらには送信をツールとして公開しています。そして、コードを書く前に何が範囲内かを把握しようとしているなら、llms.txtが地図です。

    実際のお願い

    /searchをスクレイピングすると、私たちが無料で配っているデータの劣化コピーを、より遅く、より壊れやすく、サーバーに必要以上に負荷をかけて取得することになります。データセットは同じコンテンツを、構造化され、適切にページングされ、継続的に更新され、1つのcurlコマンドで開始できる状態で提供します。

    現在wikiprompt.orgに対してスクレイパーを維持しているなら、私たちは怒っていません、理解しています、ほとんどのサイトはこれを提供していません。私たちは提供しています。スクリプトを/dataset/promptsに向け、スクレイパーを削除し、戻ってきた時間を実際に構築しようとしていたものに費やしてください。

    Tags
    open-data·dataset·scraping·api·ai-prompts·download