Crawl API vs Web Scraper API vs Proxies: 結局どれを選ぶべきか？

正直に言うと、スクレイピング手法選びはかなり悩ましいです。

市場には主に 3 つの選択肢があります。自分でプロキシプールを組む、Crawl API を使う、Web Scraper API を使う。この 3 つはそれぞれ理屈もありますが、当然それぞれに落とし穴もあります。データ収集の現場を何年もやってきた開発者として、今日はこの 3 つの実情を、きれいごと抜きで話します。

先に結論: どう選ぶか

後ろの長文を読むのが面倒なら、先に実用的な結論だけ言います。

専任チームが 5 人以上いて、データ量が TB 級で、長期的に続けるつもりなら、自前構築（DIY）は合理的です。データを柔軟に解析したい、ある程度の技術力はある、でもあまり手間はかけたくないなら、Crawl API が折衷案になります。とにかく早くデータが欲しい、技術的な細部は触りたくない、チームも 1〜2 人しかいないなら、Web Scraper API がいちばん気楽です。

ほとんどの場合、私はまず Web Scraper API から始めることを勧めます。まずデータを回し、ビジネス価値を検証して、それから最適化を考えるべきです。いきなり車輪の再発明から入らないことです。私はこの失敗をしました。昔、自前構築のほうがプロっぽいと思って 3 か月かけて作ったのに、結局ビジネスモデル自体が回らず、全部無駄になりました。

自前プロキシプール（DIY）

自前でやるのは、部品を買って自作 PC を組むようなものです。完全にコントロールできますが、そのぶん技術が必要です。

要するに、これらは全部自分で面倒を見る必要があります。

プロキシのローテーションは基本です。これがないと IP が次々に封じられて本当にきついです。単にプロキシ IP の一覧を買えば終わりではなく、ローテーション戦略、ヘルスチェック、失敗時のリトライが必要です。住宅プロキシ、データセンタープロキシ、モバイルプロキシは、用途も価格も大きく異なります。

CAPTCHA の突破は本当に消耗します。Cloudflare のようなチャレンジ、hCaptcha、reCAPTCHA v2 など、手口はさまざまです。サードパーティのサービスを組み込むか、自分でモデルを訓練する必要があります。2Captcha を使う人もいれば Anti-Captcha を使う人も見てきましたが、どれも遅延とコストの問題があります。

ブラウザフィンガープリントの偽装はさらに厄介です。今のサイトは IP だけではなく、ブラウザフィンガープリントも見ています。User-Agent、Canvas フィンガープリント、WebGL フィンガープリント、フォント一覧、プラグイン情報など、見る項目は山ほどあります。Puppeteer や Playwright で本物のブラウザを再現しつつ、サイト側の対スクレイピング戦略の変化に合わせて継続的に更新していく必要があります。

JavaScript レンダリングは避けて通れない落とし穴です。今は SPA が多く、ブラウザを使わないとデータを取れないサイトがたくさんあります。つまりヘッドレスブラウザのクラスタを維持する必要があり、リソース消費が非常に大きいです。ブラウザインスタンス 1 つで数百 MB のメモリを食うので、並列数が増えるとサーバーコストも跳ね上がります。

パーサー保守は底なし沼です。サイトが改修されると、こちらのセレクタはすぐ壊れます。Taobao や JD.com のような EC サイトは、年に何度もレイアウトを変えます。解析失敗をすぐ検知できる監視を用意し、迅速に直せる体制が必要です。私も以前は毎週数時間をパーサー修正に使っていました。

処理量が大きくなると、分散スケジューリングは必須です。単一マシンの並列数には限界があるので、複数台で協調させる必要があります。Redis キュー、Celery によるタスクスケジューリング、ロードバランシングまで含めると、それだけでまた半分ひとつのシステムです。

これを 1 人で一通りやるなら、少なくとも 2〜4 か月はかかります。チームがあっても小さな工事ではありません。私も 3 人で 1 セット組んだことがありますが、安定するまで丸 4 か月かかりました。

• どんなときに自前でやる価値があるか

正直に言うと、ほとんどの場合は見合いません。ただし、いくつか例外はあります。

本当にデータ量が大きいなら、自前構築のほうが経済的です。月数百万リクエストを超えると、API 費用は年単位で数十万規模になり、自前のほうが安くなります。私のある顧客は、もともと API サービスに年間 20 万かけていましたが、自前に切り替えた結果、インフラ費用は年間 2 万まで下がりました。ただし、初期に 15 万の開発費と半年の時間を投じています。この投資が見合うかは、きちんと計算しないといけません。

完全に自分でコントロールしなければならない場面では、選択肢はありません。金融、機微データ、サードパーティサービスを通せないケースでは、自前構築が必須です。実際、データコンプライアンス要件のため、すべてのスクレイピングシステムを社内ネットワークに置かなければならず、DIY しか選べなかったクオンツ企業を見たことがあります。

専任チームがあるなら、自前構築は合理的です。会社にデータ収集専任のエンジニアが 5 人以上いるなら、自社構築には価値があります。5 人を抱える年間コストはかなりの規模になるので、小さな会社には厳しいです。ただ、大企業でその人員があるなら、活用しない理由はありません。

• リアルな落とし穴

見てきた落とし穴が多すぎるので、典型的なものをいくつか挙げます。

ある知人は自分でプロキシプールを組み、ある代理業者から住宅プロキシを買っていましたが、その業者が飛んでしまい、プロキシ IP は全部使えなくなりました。数千元が無駄になっただけでなく、システムのプロキシプールロジックまで作り直す羽目になりました。こういうことは代理業界では珍しくなく、小規模業者が倒産して逃げるのは日常茶飯事です。

あるチームは苦労して対スクレイピング戦略を組み、ある EC サイト向けにさまざまな回避策を作りました。ところがそのサイトが防御システムを更新し、2 か月分の作業が無駄になりました。さらに悪いことに、新しい対策はもっと複雑で、また最初から研究し直す必要がありました。

一番つらいのは、半年かけてシステムを作り終えたのに、あとでその事業自体の価値が大きくないと分かって、プロジェクトごと打ち切られるケースです。こういう例は一度や二度ではありません。技術チームは自前構築に達成感を持てますが、事業部が欲しいのはデータであって、技術力の自己満足ではありません。

保守コストはとても高いです。サイト側の対スクレイピング戦略の変化に合わせ続ける必要があり、ほぼ毎週どこかを直すことになります。今日はあるサイトが HTML 構造を変更し、明日は別のサイトが新しい CAPTCHA を入れ、明後日はプロキシプールが壊れる。成功率 80% を出せればまだ良いほうで、95% 以上を維持するには継続的な投資が必要です。

技術的負債はすぐ積み上がります。初期は早く出すために雑に書く箇所が増え、3 か月もするとコードは保守しづらくなります。リファクタリングにも時間がかかるし、やらなければさらに保守しにくくなる。典型的な悪循環です。

• コストをどう計算するか

実際の数字で計算してみましょう。"自前構築は安い" という話に、簡単に乗せられないことです。

開発コストで見ると、シニアエンジニア 1 人の月給が 3 万で、3 か月動けばそれだけで 10 万近くになります。チーム規模が少し大きくなれば、簡単に 20 万を超えます。しかもこれは順調に進んだ場合で、半年かけても安定しなかったケースも見ています。

運用コストも低くはありません。住宅プロキシは 5 万リクエストでおおよそ 100〜300 元ほどで、量が大きければ価格交渉はできますが、それでも安くはないです。データセンタープロキシは安い反面成功率が低く、サイトによってはまったく使えません。CAPTCHA 解決サービスは 1,000 件で 10〜20 元ほどで、量が増えると無視できません。サーバー費用も並列数次第で、月数百〜千元超まで上がります。

初年度の総コストは、現実的に見て 15〜30 万は最低でもかかります。これは、まともなチームを確保できて、大きな失敗を踏まない前提の話です。対象サイトが特に難しいなど特殊条件があれば、さらに膨らみます。

私が見た中で一番極端だったのは、ある会社が自前システムに 80 万を投じ、エンジニア 3 人が半年かけたケースです。ところが 1 年後には、やはり API のほうが楽だと気づいて戻しました。80 万は水の泡、時間も失われ、経営側は激怒し、技術チームもかなりつらい状況でした。

• 技術ディテールの深掘り

具体的な実装の話もしておきます。プロキシを買えばそれで終わりだと思わないことです。

プロキシプールの運用は簡単ではありません。ヘルスチェックの仕組みを作り、定期的にプロキシが使えるか検査する必要があります。失敗率の高いプロキシは外し、新しいものを補充しなければなりません。地域分散も必要で、対象サイトによっては特定国の IP が求められます。プロキシの種類選びも重要で、データセンタープロキシを使った瞬間に弾かれるサイトもあり、住宅プロキシが必須なケースもあります。

セッション管理はさらに複雑です。ログイン後の一連の操作のように、同じセッションを維持しないといけない場面があります。つまり複数リクエストで同じプロキシ IP を使い続けつつ、Cookie や Session も管理しなければなりません。こうした状態情報の保存と同期が問題になります。

リクエスト頻度の制御は見落とされがちです。リクエストを別々の IP に分散すれば安全だと思いがちですが、そうではありません。同じユーザーパターン、同じ時間帯に密集して叩けば、やはりボットと判断されます。ランダムな遅延や時間帯分散を入れて、実ユーザー行動を模倣する必要があります。こうした細部を詰めないと、結局はブロックされます。

データ保存とクレンジングも立派な作業です。取得したデータには重複、誤り、欠損がありえます。重複排除、データ検証、例外処理の仕組みが必要です。小さく見える作業でも、量が増えると大問題になります。以前、スクレイピングデータの事故対応をしたときは、重複データが 30% もあり、危うくデータベースがあふれるところでした。

監視とアラートは必須です。各スクレイパーインスタンスの健全性、対象サイトごとの応答状況、プロキシプールの可用性を把握できなければなりません。ある対象サイトが大規模に IP を封じ始めたら、すぐに気づいて戦略を変える必要があります。監視がなければ、問題に気づいたときにはもうデータ品質に影響が出ています。

Crawl API：折衷案

Crawl API というのは、要するに泥臭い作業を肩代わりしてくれて、HTML は返すから解析は自分でやる、というものです。今のところ、私の案件の多くで使っているのがこのパターンです。

• 実際に何をやってくれるのか

IP 自動ローテーションは基本機能です。住宅プロキシ、データセンタープロキシ、モバイルプロキシを含め、事業者側が対象サイトの難易度に応じて自動選択してくれることが多いです。プロキシプールの管理、ヘルスチェック、ローテーション戦略は自分で持たなくて済みます。

CAPTCHA を任せられるのはかなり楽です。Cloudflare、hCaptcha、reCAPTCHA などについては、API 事業者が専用の解決策を持っています。機械学習モデルで判定するものもあれば、サードパーティ連携や人力解読プラットフォームを使うものもあります。方式は違っても、自分でやるより成功率は高いです。

JavaScript レンダリングは自分で面倒を見る必要がありません。Puppeteer や Playwright を自分でインストールしたり保守したりする必要はなく、API 事業者側が専用のレンダリングクラスタを持っています。こちらは render_js パラメータを設定するだけで、あとは任せられます。

ブラウザフィンガープリントの偽装は、ボット判定を避けるための基本です。User-Agent、Canvas フィンガープリント、WebGL フィンガープリントなどについては、API 事業者が実ブラウザらしくシミュレートしてくれます。彼らには対スクレイピング戦略を研究する専任チームがいるので、更新頻度は確実にこちらより高いです。

自動リトライはかなり実用的です。失敗したら、別のプロキシ、別のブラウザフィンガープリント、別の戦略に切り替えてもう一度試してくれます。自分でリトライロジックを書く必要はなく、API 内部で処理済みです。失敗理由に応じてリトライ戦略を変える高度な機能を持つ事業者もあります。

これを自分でやるなら、最低でも 2 か月は見ておくべきです。API なら、インターフェースを叩くだけで済みます。

• どんなときに使うか

正直、今の案件の大半はこれを使っています。よほど標準化されたデータソースでない限り、このやり方が一番バランスがいいです。

サイト構造が複雑なときは、Crawl API がかなり合います。たとえば EC サイトはサイトごとに構造が違うので、自分で解析ロジックを書く必要があります。Crawl API で HTML を取得し、BeautifulSoup や Cheerio で自分で解析すれば、柔軟性は高いです。解析レイヤーでデータのクレンジング、フォーマット変換、フィールドマッピングなど、さまざまなカスタム処理も入れられます。

解析プロセスを細かく制御したいときは、その柔軟性が役立ちます。特定の要素が読み込まれるまで待ってから取得したい場合や、独自の JavaScript を実行したい場合など、こうした場面では Crawl API の柔軟性に価値があります。wait_for パラメータで特定要素を待てますし、timeout でタイムアウト時間も制御できます。

チームの技術力がそこそこあるときに最適です。エンジニアは HTML 解析や例外処理など、ある程度のスクレイピング知識は必要です。ただし、アンチボットの深い部分まで理解している必要はなく、そのあたりは API が吸収してくれます。この技術的ハードルは大半の開発チームにとってちょうどよく、簡単すぎず難しすぎません。

• リアルな使用感

私はいくつもの Crawl API を使ってきましたが、体験は大きくは変わらず、それぞれに長所と短所があります。

導入はとても速く、基本的に半日から 1 日で動き始めます。コード量も数十行ほどで、自前構築よりはるかに簡単です。いちばん印象に残っているのは、初めて使ったとき、午後に統合を始めて夜にはもうデータが出ていたことです。自前なら、プロキシプールを通すだけで 1 週間かかります。

コード例は簡単ですが、実際に使うと細かい注意点がかなりあります。たとえば、特定の headers が必要なサイトもあれば、cookies が必要なサイト、country パラメータで地域指定が必要なサイトもあります。こうした細部を詰めないと成功率に響きます。私はいつも、まずチームにいくつかのテスト URL で通してもらい、パラメータ設定が正しいと確認してから本格運用に入るようにしています。

成功率は本当に自前より高いです。自分でやるとだいたい 70〜80% ですが、API を使うと 95% 以上まで出ます。差の中心はアンチボット対応で、向こうは専任チームで研究しているので、投入量がこちらより大きいのは当然です。しかも API 事業者は取扱量が大きいため、より良いプロキシ資源をさまざまな経路から確保できます。

安定性も高いです。自前システムでは、あるプロキシノードが急に使えなくなる、ある対象サイトが対スクレイピング戦略を更新する、といった妙な問題がしょっちゅう起きます。API 事業者は専用の監視とインシデント対応体制を持っているので、こうした問題をこちらより早く見つけて処理できます。

• コスト分析

実際の価格感を示しておきます。どれも私が実際に使ったことのある価格です。

入門プランはだいたい月 50〜100 元で、10,000 リクエスト程度です。小規模プロジェクトや MVP 検証向けです。中位プランは月 200〜500 元で 100,000 リクエスト。多くの中小プロジェクトはこのクラスで足ります。企業向けは月 1,000 元以上で、リクエスト数無制限のこともあります。本当に大規模なときだけ検討すれば十分です。

詳しく比較したことがありますが、プロキシプールを自前で持ち、開発コストを按分しても、月リクエスト数が 50 万を超えたあたりでやっと API より安くなります。大半の案件はそこまで行きません。私の案件の多くは月 5〜20 万リクエストで、API なら年間数千〜1 万程度で済みますが、自前構築だと開発費だけで十数万かかります。

コストは API 料金だけではありません。学習コスト、つまりチームが API の使い方を覚えるコストもあります。デバッグコスト、問題が起きたときに API 側なのか自分のコードなのか切り分ける手間もあります。さらに、事業者を切り替える場合の移行コストもあります。こうした隠れコストも含めて考えるべきです。

• 実践テクニック

実際に使うときのコツも少し話します。

非同期並列化は効率を大きく引き上げます。ほとんどの API は非同期リクエストに対応しており、数十件を同時に投げて処理できます。ただしレート制限には注意が必要です。事業者の API を叩きすぎると逆に遅くなります。私も並列数を上げすぎて API 側にレート制限され、かえって遅くなったことがあります。

賢いキャッシュを入れるとかなり節約できます。商品情報や会社情報のように、頻繁には変わらないデータもあります。一定期間キャッシュして重複リクエストを避けるべきです。私は通常、最初のリクエスト結果を Redis に保存し、その後はまずキャッシュを見て、期限切れなら更新します。これで API 呼び出しを 30〜50% 減らせます。

エラー処理は丁寧に設計すべきです。すべての失敗でリトライすればよいわけではなく、対象サイト側の問題なら再試行しても意味がありません。エラー種別ごとに、再試行するか、何回するか、間隔をどれくらいにするかを決める必要があります。私は通常、HTTP 429 と 5xx だけをリトライし、4xx と 3xx はリトライしません。

監視とログは重要です。各 API 呼び出しについて、リクエストパラメータ、応答時間、成功率、失敗原因をきちんと記録するべきです。こうしたデータがあれば利用戦略を最適化できます。私は毎週 1 回は統計を見て、成功率の低い対象サイトがないか、パラメータ調整が必要かを確認しています。

Web Scraper API：手間を減らしたい人の味方

これがいちばん楽です。最初から JSON データを返してくれるので、初めて使ったときは本当に驚きました。スクレイピングって、ここまで簡単にできるのかと。

• どういう意味か

簡単に言えば、何を取りたいかを伝えると、構造化データになって返ってきます。

たとえば LinkedIn のプロフィールなら、API を叩けば返ってくるのはすでにクリーンな JSON データです。name、title、company、skills、experience といった項目は最初から解析済み。自分で HTML を解析する必要も、セレクタを管理する必要も、サイト改修を心配する必要もありません。サービス提供側にはテンプレートを保守する専任チームがいて、サイトが変わればすぐ更新してくれるので、こちらは気にしなくて済みます。

LinkedIn だけではなく、Amazon の商品情報、Twitter のユーザープロフィール、Instagram の投稿など、主要プラットフォームにはたいていプリビルド済みテンプレートがあります。ニッチなサイトでも、サービス提供会社によってはテンプレートを持っていることがあります。テンプレート数はサービス間競争の重要な指標で、大手は数千件のテンプレートを持っています。

テンプレートがないサイトはどうするのか。多くのサービス事業者は独自 schema をサポートしています。どの項目を取りたいか、どう見分けるかを伝えれば、抽出ルールを生成してくれます。機械学習で自動認識する方式もあれば、CSS セレクタを設定させる方式もあります。どちらにせよ、自分でパーサーを書くよりはずっと簡単です。

• 実際の使用感

初めて使ったときは少し衝撃でした。10 分でつながって、すぐデータが返ってきました。

導入は驚くほど簡単です。アカウント登録、API Key 取得、ドキュメント確認、数行コードを書く、テストする。全部やっても 30 分かかりません。私が最初に使ったときも、午後に登録してその夜にはデータが取れていました。MVP 検証や高速プロトタイピングでは、このスピードが非常に大きいです。

よくあるサイト、たとえば LinkedIn、Amazon、Twitter、Instagram などには既成テンプレートがあります。基本はテンプレートと URL を指定するだけで、ほかは気にしなくて済みます。返ってくるデータ形式も固定なので、そのまま使えます。自前システムのように、サイトごとに別々の解析ロジックを書く必要はありません。

コード例は簡単ですが、実際に使うといくつか注意点があります。空になるフィールドへの例外処理、配列型フィールドのループ処理、ネストされたデータの多段解析などです。これらの細部はドキュメントに書いてありますが、初回利用では見落としやすいです。

• 最適な場面

MVP 段階には最適です。まず最速でデータを手に入れて仮説検証するべきで、技術に時間を使いすぎるべきではありません。データでビジネスモデルを検証してから、技術最適化を考えれば十分です。スクレイピング技術に時間をかけすぎた結果、事業の方向性が間違っていて技術投資が全部無駄になったチームを何度も見てきました。

専任のスクレイピングチームがないなら、これがいちばん楽です。開発者が 1〜2 人しかおらず、データ収集に詳しい人も採りたくないなら、Web Scraper API が向いています。通常の開発者でも扱え、特別なスキルは不要です。小さなチームには特に相性がいいです。

標準化された要件には最適です。欲しいのが LinkedIn の個人プロフィールや Amazon の商品情報のような定型データなら、既存テンプレートをそのまま使えます。こうしたデータは項目構造が固定されており、テンプレート品質も高いため、かなり安心して使えます。

時間に敏感なプロジェクトでは第一候補です。顧客が急いでデータを必要としている、あるいは市場機会が一瞬で消えるような場合、自前システムに数か月もかけていられません。Web Scraper API なら数日で立ち上げられます。私のある顧客では、競合が自前構築を進めている間に API を使って 2 か月早く市場投入し、先行優位を取りました。

• 実際の落とし穴

もちろん完璧ではなく、事前に知っておくべき落とし穴もあります。踏んでから気づくのでは遅いです。

カスタマイズ性は痛点です。欲しい項目がテンプレートに入っていないと面倒です。独自 schema をサポートするサービスもありますが、すべてではありません。対応していても、プリビルド済みテンプレートよりは手間がかかります。私も、欲しい項目がテンプレートになくて自分で抽出ルールを書く羽目になり、結局 Crawl API を使ったほうが早かったことがあります。

コストは確かにやや高めです。Crawl API と比べると、同じリクエスト数でも 30〜50% ほど高くなります。その上乗せ分に見合うかは計算が必要です。データ量が大きいなら、差はかなりはっきり出ます。私のある顧客は月 50 万リクエストで、Web Scraper API だと月 3 万、Crawl API に替えると 2 万で済みました。

サードパーティ依存にはリスクがあります。サービス会社が倒産したり、提供を止めたりすれば移行が必要になります。たいていデータエクスポート機能はあるので致命的ではありませんが、移行には時間がかかり、その間は業務に影響が出ます。実際、買収後に製品方針が変わり、いくつかのテンプレートが保守されなくなって、別のサービスに移らざるを得なかったことがありました。

データ品質が完璧でないこともあります。プリビルド済みテンプレートは便利ですが、100% 正確とは限りません。LinkedIn のテンプレートが会社名を誤認したり、Amazon のテンプレートが価格を取りこぼしたりしたこともありました。そういう場合はサービス側のサポートに問い合わせるか、自分で二次処理を入れる必要があります。頻繁ではないですが、起きるとかなり面倒です。

更新にはタイムラグがあります。サイト改修のあと、テンプレート更新まで通常数日から 1 週間ほどかかります。その間に取得したデータは正確でない可能性があります。もし業務上、データ精度への要求がとても高いなら、ここは問題になります。私はたいてい、新しいテンプレートは少量トラフィックで試し、安定してから本格投入します。

• 実践活用テクニック

少し高度な使い方も話します。

Webhook 連携のほうがさらに手間が少ないです。こちらから取りに行くのではなく、処理済みデータをサービス側が push してくれます。必要なのは webhook URL を 1 つ渡すだけで、クロール完了後に POST してくれます。この方法はよりリアルタイムで、ポーリングも不要です。ただし、自分のサービス側が高可用でないと、データを取りこぼす可能性があります。

バッチ処理はコスト削減に効きます。多くの事業者は一度の API 呼び出しで複数 URL を処理できるので、ネットワークのオーバーヘッドを減らせますし、まとめ割が効くこともあります。私はたいてい URL をある程度ためてからまとめて送ります。そのほうが単発で投げるよりずっと速いです。

データ変換には注意が必要です。サービス会社ごとに返すデータ形式が違うことがあり、フィールド名、データ型、ネスト構造などもまちまちです。乗り換えるときはデータマッピングが必要になります。私は API 層に抽象化を 1 枚入れて、各サービスのデータ形式を統一することを勧めています。そうしておけば、乗り換えても業務ロジック側のコードは変えずに済みます。

テンプレート状態も監視すべきです。テンプレート保守自体は事業者の仕事ですが、こちらも見ておく必要があります。あるテンプレートで問題が頻発したり、特定フィールドの解析精度が低かったりするなら、テンプレートや事業者の見直しが必要かもしれません。私は毎週、各テンプレートの成功率と精度を確認し、問題があればすぐ調整します。

3 つの手法の比較表

この表は、多くの案件の実データをまとめたもので、机上の理論よりはるかに実用的です。自分の状況と照らし合わせて、どの選択肢が合うかを見れば十分です。

私の提案

ここまでいろいろ話しましたが、最後に実務ベースの具体的なアドバイスをまとめます。

• 90% のケース: まずは API から

本当に、最初から自分で全部やろうとしないことです。まず API で事業を回し、データの価値を検証してから最適化を考えれば十分です。

技術選定で数か月も悩み、その間に市場機会を逃したチームをたくさん見てきました。MVP 段階で重要なのは、完璧な技術構成ではなくスピードです。まず API で素早く検証し、データに価値があると分かってから自前化を考えても遅くありません。

Web Scraper API は最も速く、素早い検証に向いています。Crawl API はもう少し柔軟で、独自解析が必要な場面に向いています。大半の MVP は、この 2 つで十分です。

API コストが本当に重く感じるほどデータ量が増えてから、DIY を考えれば十分です。正直なところ、多くの案件はそこまで行きません。私が関わった案件でも、月間リクエストが百万規模に達したのは 1 件だけで、ほかはすべて数十万以下でした。

• どんなときに DIY を検討するか

検討するのは、これらの条件を満たしてからです。1 つ欠けてもだめです。

第 1 に、月間リクエスト数が 100 万以上であること。この規模になると API 費用は安くなく、自前構築で節約できる余地が出ます。ただし API 料金だけでなく、総コストをきちんと計算する必要があります。

第 2 に、専任チームがいること。5 人以上のエンジニアチームで、スクレイピング経験があること。この人員体制がないなら、DIY は考えないほうがいいです。

第 3 に、長期でやるつもりがあること。少なくとも 2 年以上です。短期案件では自前構築は割に合わず、開発費すら回収できません。

第 4 に、コストに敏感であること。単にお金がないという意味ではなく、計算した結果として自前構築のほうが経済的である場合です。年間の API 費用が数万しかないなら、無理に自前化する必要はありません。

4 条件のうち 1 つだけ満たして DIY に進み、悲惨な結果になった案件を何度も見てきました。チームが回せない、事業要件が変わる、採算計算が甘い。どれもよくある失敗です。この 4 条件が全部そろって初めて、DIY に価値があります。

• 実は併用案がいちばん実用的

今の私のやり方は、たいてい併用です。二者択一ではなく、状況に応じて組み合わせます。

中核事業でデータ量も大きいなら、自前構築です。たとえば Google 順位を毎日数十万件監視するような用途では、API では高すぎるので自前が必須です。

補助的な業務でデータ量が小さいなら API。たとえば業界サイトのニュースを少し集める程度で、1 日数百リクエストなら API がいちばん楽です。

標準化されたデータソースなら Web Scraper API。LinkedIn や Twitter のようにテンプレートがあるものは、そのまま使えばよく、自分で解析する必要はありません。

複雑なデータソースなら Crawl API。構造が複雑で独自解析が必要なら、Crawl API で HTML を取り、自分で解析します。

こうすればコストを抑えつつ、過剰投資も避けられます。削るべきところは削り、投じるべきところには投じる。全部を同じやり方で処理せず、実情に応じて柔軟に選ぶべきです。

• 技術選定の落とし穴

最後に、よくある落とし穴を挙げます。踏まないようにしてください。

1 つ目の落とし穴は、過剰設計です。MVP 段階から完璧なシステムを作ろうとして、高可用性、分散、マイクロサービスまで全部やろうとすると、数か月たっても公開できません。まず動かし、そのあと最適化することです。

2 つ目の落とし穴は、技術の自己満足です。自前システムは技術的にかっこよく見えますが、事業価値を検証する前に投資すると、技術コストだけが無駄になります。技術は事業のために使うものであって、見せるためのものではありません。

3 つ目の落とし穴は、保守を甘く見ることです。システムを作れば終わりだと思いがちですが、実際はそこからが始まりです。サイト改修、対スクレイピング更新、プロキシ失効など、新しい問題は毎週出ます。継続的に投資し続ける覚悟が必要です。

4 つ目の落とし穴は、API の単価だけを見ることです。API は高いと思っても、自前構築の開発コストを計算に入れていないケースが多いです。10 万リクエストで API が月 500 元、自前開発コストが 10 万なら、回収に 20 年かかります。単価だけでなく総コストを見るべきです。

5 つ目の落とし穴は、機会コストを無視することです。自前システムに 3 か月かける間に、市場はすでに変わっているかもしれません。ときには節約よりも、早く出すことのほうが重要です。機会コストまで入れて考えると、API のほうが得になることは珍しくありません。

まとめ

この業界では、技術を過信しすぎないことです。重要なのは事業価値です。

事業の月商が数千程度しかないのに、スクレイピングシステムに 10 万かけるのは、どう考えても割に合いません。API なら月数百で済み、データ品質もむしろ高いです。

事業が月に数百万規模で売り上がるなら、数十万を投じてシステムを作るのも十分合理的です。その段階ではコストよりも、安定性とコントロール性のほうが重要になります。

だから、先に事業の採算を計算し、そのあとで技術の採算を見るべきです。大半のケースでは API で十分で、考えすぎる必要はありません。

私がやってきた案件の 90% は、最後は API に落ち着きました。本当に自前構築が必要なのは、大企業のコア事業だけです。スタートアップや中小企業で大企業の技術戦略を真似しようとしても無理があります。向こうとこちらでは使えるリソースがまったく違います。

この一言は覚えておいてください。アイデア検証は最速の方法で、データ取得は最も安い方法でやる。技術は問題を解決するためのもので、問題を増やすためのものではありません。