Apify、Webデータ収集をActorsのマーケットプレイスへ変えた成長の軌跡

Apifyは、Webサイトから必要なデータを取り出す作業を、毎回書き捨てるscriptではなく、再利用できるActorとして扱う発想から成長した。

現在はActors、API、Store、SDKを組み合わせ、収集から運用までを一つのplatformにしている。出典

創業のきっかけ

Jan ČurnとJakub Baladaは2015年、Y Combinator Fellowshipを起点にApifyを始めた。

公式Aboutは、Webを構造化データへ変換する課題を創業の背景として説明している。出典

転機

単発のscraper受託から、Actorsをcloud上で実行し共有するplatformへ抽象化したことが転機だった。

Actorは入力・実行・出力を持つ単位で、開発者は同じ処理をAPIやscheduleから呼び出せる。出典

We make the world's data accessible

成長の条件

Storeで他者のActorを見つけられるため、利用者はゼロからscraperを作らずに済む。

一方で、開発者は自分のActorを公開し、用途別の入口を増やせる。出典

結び

Apifyの要点は、Web scrapingを一度きりのコードから、実行可能なdata productへ変えたことにある。

データ取得の頻度が増えるほど、再利用性と運用性の差が効いてくると言える。

Web dataを必要とする開発者、researcher、企業に対し、scraping・browser automation・proxy・storageを個別に組み合わせる負担を減らす。

ActorsとAPIで再実行可能なworkflowにでき、Storeが初期実装の摩擦を下げる。出典

Actor Storeの部品群、実行データ、SDK・proxy・storageをまとめた運用面の蓄積がmoatになる。

ただしscraping自体の技術は模倣されやすい。出典

ネットワーク効果は中程度。

Actorの利用者が増えるほど公開者の配布先が増え、公開Actorが増えるほど利用者の選択肢が増えるが、品質差も広がる。出典

Web dataを定期収集するdeveloper、data team、market researcher、automation team。

小規模な一回限りの取得より、schedule・API・監視が必要な継続workflowに向く。出典

単発scriptではなくActorという実行単位にしたこと、Storeで再利用可能な部品を流通させたこと、SDKとcloud実行を一体化したことが強い。

公式docsはAPI・schedule・storageを組み合わせた運用を説明する。出典

Webサイト側の仕様変更、bot対策、規約・privacy・robots.txtへの対応は継続的なリスクである。

usage-based pricingは大量処理時の予算予測も難しくするため、導入前の監視設計が必要になる。出典

developer向けcontent、GitHub、SDK、Storeを入口にセルフサーブで獲得し、usageに応じて課金する。

専門Actorを増やすmarketplace戦略は、広告よりも検索意図の強い顧客を集めやすい。出典

主要チャネル: content, community, developer ecosystem, marketplace

複雑な技術作業を、実行・共有・課金できる単位へ再定義すると、toolからplatformへ広げられる。

部品の流通面まで作ることで、顧客の初回価値到達を短くできる。出典

日本ではEC価格調査、不動産、求人、観光、自治体オープンデータなど、定期的なWeb data収集の用途がある。

規約・個人情報・robots.txtの確認を標準workflowにし、監査可能な運用を前面に出すべきだ。