外部データをAPIで取り込む設計は珍しくないが、「投資家情報」という特殊なドメインのデータを構造化JSONとして取得できるサービスが登場している。Apify上で公開されている「Startup Investors Data Scraper」は、2025年12月時点で10,469社のVC・エンジェル・PEファームを収録したデータベースをAPIライクに照会できるActorだ。
このActorが解決しようとしている問題
投資家情報の一括取得は、既存の商用データベースでは意外にハードルが高い。CrunchbaseやPitchBookといった主要プラットフォームは、APIアクセスをエンタープライズ向けの有償プランに限定しており、個別のエンドポイント呼び出しで大量レコードを引き出す構造になっていない。無料で入手できる情報はCSVの配布やスプレッドシートの共有にとどまり、フィルタリングや自動更新の仕組みを自前で用意する必要がある。
このActorは「キュレーション済みデータベースをクエリAPIとして提供する」という形を取る。商用DBのスクレイピングではなく、独自に整備したデータセットに対してパラメータを渡すと、条件に合致したレコードだけをJSON形式で返す。
返却されるJSONの構造と各フィールドの意味
1件のレコードには以下の情報が含まれる。
- firm_name / firm_type_name: 会社名と投資形態（VCやエンジェル等17種類）
- firm_country / firm_city / firm_state: 所在地。国単位だけでなく都市レベルで絞り込みに使える
- firm_aum: 運用資産残高（Assets Under Management）。判明している場合のみ含まれる
- firm_website / firm_linkedin_url / crunchbase_url: 参照先URL群
- investor_contacts: Include_Contactsをオンにしたときに展開される。担当者名・役職・LinkedIn URL・メールアドレス・チェックサイズを含む配列
業務システムへの取り込みを考えるとき、この構造で注意すべき点は「investor_contacts」がネストされた配列である点だ。SQLの正規化テーブルに格納する場合は、firm単位のテーブルとcontact単位のテーブルを分けて外部キーで紐づける設計が素直になる。
REST APIとPythonクライアントを使った呼び出し方法
Apify（エージェント型のウェブ自動化プラットフォームで、「Actor」と呼ぶ実行単位でスクリプトを管理・公開できる）は、各ActorをREST経由で直接起動できる。curlで実行する場合の例は次の通りだ。
curl -X POST "https://api.apify.com/v2/acts/johnvc~startup-investors-data-scraper/runs?token=YOUR_APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"Firm_Types": ["Venture Capital Investor"],
"Investment_Stages": ["Seed"],
"Countries": ["United States"],
"Include_Contacts": true,
"Max_Results": 50
}'Pythonでの実装はapify_clientライブラリを使う。actor().call()でActorを同期的に実行し、返却されたdefaultDatasetIdをもとにdataset().iterate_items()でレコードを順次取得する非同期バッチ的な構造になっている。
from apify_client import ApifyClient
client = ApifyClient("YOUR_APIFY_TOKEN")
run = client.actor("johnvc/startup-investors-data-scraper").call(
run_input={
"Investment_Stages": ["Pre-Seed"],
"Focus_Areas": ["Artificial Intelligence"],
"Include_Contacts": True,
"Max_Results": 25,
}
)
for firm in client.dataset(run["defaultDatasetId"]).iterate_items():
print(firm["firm_name"], firm["firm_country"], firm["firm_website"])シード記事によれば、25件の取得は「約1分」で完了するとされている。Max_Resultsを大きくすると実行時間とコストが比例して増加するため、定期バッチで分割取得する設計が現実的だ。
既存システムへの取り込みで考慮すべきポイント
このAPIを業務システムに組み込む場合、いくつかの設計上の判断が必要になる。
まず「鮮度の管理」だ。データベースの更新頻度はApify側に依存するため、取得済みレコードのキャッシュ戦略が必要になる。たとえばfirm_nameをキーとして差分更新する仕組みを持たないと、同一企業を重複登録するリスクがある。
次に「スキーマの変動耐性」だ。外部APIのフィールド定義はバージョニングなしに変更されることがある。取得後に必須フィールドの存在チェックを行い、想定外のnullや型変換エラーを早期に検出するバリデーション層を挟むと安全だ。たとえばfirm_aumは「判明している場合のみ」含まれるため、Optional型として扱う必要がある。
さらに「コスト計算の設計」も重要になる。Apifyの課金は実行時間とデータ転送量に基づくため、Max_Resultsを変数化して呼び出し側でコントロールできるようにしておくと、予期しない高額請求を防ぎやすい。
日本の開発現場では、CRMシステムへの一括インポートや、投資家情報の定期更新バッチをLambda/Cloud Functionsで実装するケースが考えられる。その際、JSONからORMモデルへの変換処理にPydanticのようなスキーマバリデーションライブラリを組み合わせると、フィールド変動に気づきやすくなる。
類似の外部データ連携パターンとしては、企業データAPIのClearbitや、日本では法人番号APIとの連携が参考になる。どちらも「外部で管理されるマスターデータを自社DBに周期的に反映する」構造であり、設計の考え方は共通している。
Actorという実行単位をAPI呼び出しの抽象レイヤーとして捉えると、このパターンは「データ収集ロジックをホスティングごとアウトソースしたマイクロサービス」として読み替えられる。自前でスクレイピング基盤を持たずに外部データを取り込む選択肢として、実装コストとデータ品質のトレードオフを評価する価値はある。