Skip to main content
Pubrioデータレイヤーの進化を追跡しましょう。

​
2026年 リリース

v2.4.6 - 人物検索：部門を書かれたとおりに解釈 (2026年10月)

  • 修正: 人物検索の departments と department_functions は、カタログにない値を指定すると、management_levels と同じく 0 件を返します。以前はフィルターが破棄され、すべての部門の人物が通常の 200 で返っていました。
  • API: 人物検索と求人検索で、部門・職能・管理レベルの値は大文字小文字、スペース、記号を区別しません。information_technology は master_information_technology と読まれます。どの項目とも完全には一致しない値は、その単語をすべて含む唯一の項目として読まれます。engineering は master_engineering_technical と読まれます。
  • API: 人物検索は people_locations の別名として person_locations を受け付けます。名前の変更は metadata.renamed_fields に示されます。
  • API: 連絡先ルックアップ と 連絡先ルックアップ（バッチ処理） は、行に email も phone もない場合、常に first_name + last_name + domain または company で検索します。これらの行に is_enable_similarity_search は不要になりました。この設定は現在、メールまたは電話で誰も見つからなかった行を名前でも検索するかどうかのみを決めます。
  • API: domain には https://www.stripe.com/ のようなウェブサイトも指定でき、stripe.com として読み取られます。
  • 修正: is_enable_similarity_search なしで送信した氏名 + ドメインの行の一括ルックアップは、誰も一致しなかったかのように空の peoples リストを返していました。メール、電話、または氏名 + ドメイン／会社名を含むエントリーが 1 つもない一括リクエストは、単一ルックアップと同様に 400 で拒否されるようになりました。
  • 修正: 1 回の一括リクエストで 2 回送信された同じ氏名 + 会社名は is_duplicate_input としてマークされ、メールや電話と同様に 1 回のみ課金されます。
  • API： 各マッチに match.input_index（対応する peoples 内エントリの位置）が付くため、一部の行が一致しなくても、マッチを元の行と対応付けられます。
  • 修正： 名前によるルックアップは、そのドメインを持つすべての会社レコードを検索するため、同じ会社の別レコードに紐づく人物も見つかり、応答は約 2 倍速くなりました。
  • API: 類似人物を検索 は各人物に 0 から 1 の similarity_score を返し、per_page がページサイズを決めます。
  • 修正: 参照となる人物または役職は、類似の基準を決めるだけです。people_locations や domains などその他のフィルターはすべて結果を絞り込みます。以前は参照そのものが返され、その他のフィルターは無視されていました。
  • 修正: 拡大の概要 は時間内に完了できない場合、空の countries リストではなく 408 を返します。
  • 修正: 求人検索の functions と広告検索の reach_tiers は、存在しない値に対してただちに 0 件を返します。以前はタイムアウトするまで実行されていました。
  • 新規： 列挙値と定数 — API が受け付ける・返すすべての固定値を 1 ページに集約：職位ティア、職能、広告ソースとフォーマット、リーチ帯域、配信プラットフォーム、シグナルタイプ、マネジメントレベル。
  • 新規： 求人検索、ニュース検索、広告検索のガイド — フィルター表、レスポンスの解説、コピーして使えるレシピ。
  • API： 求人検索に functions、seniority_ranks、launch_dates、location_ids、created_at、is_ascending_order を記載。レスポンス行に functions、seniority_rank、source_type、base_salary、experience_requirement、education_requirement、employment_type を宣言。
  • API： 広告検索に active_dates、reach_tiers、exclude_source_types、created_at、advertisement_search_id、is_ascending_order を記載。source_types を修正 — エンリッチメントだけでなく結果を絞り込み、tiktok と apple も受け付けます。行に advertisement_format_normalized、advertiser、advertisement_url、is_company_matched、total_impressions の 3 項目を宣言し、metadata に applied_source_types、unsupported_source_types、coverage_notes、skipped_source_types を記載。
  • API： ニュース検索に published_at、news_search_id、is_ascending_order を記載し、expansion_signals（is_expansion_signal_available 設定時に返却。v2.3.1 での削除はフラグ提供前の判断だったため、これを取り消します）を含むすべての行フィールドを宣言。
  • API： 人物検索に exclude_people_titles、exclude_people_locations、exclude_departments、exclude_department_functions、company_exclude_locations を記載。
  • API： 企業検索に social_media と advertisement_status を記載。
  • API： すべての検索エンドポイントで metadata.ignored_fields を記載 — 認識できないボディキーは拒否されず破棄され、ここに列挙されます。求人・ニュース・広告検索は自由形式のオブジェクトに代えて pagination と型付きの metadata ブロックも宣言。
  • ドキュメント： 4 つのスキーマ（job_exclude_locations、advertisement_target_locations、advertisement_exclude_target_locations、拡大ランキングの domain_search_ids）が $ref の隣に説明を書いており、OpenAPI 3.0 ではそれが黙って捨てられていました。現在は表示されます。
  • API: 拡大シグナル検索（POST /expansions/signals/search）を新たに掲載しました。集計後の企業単位ではなく、企業のステージを裏付ける生の日付付きシグナル行を直接検索できます。
  • API: 拡大ルックアップ（POST /expansions/lookup）を新たに掲載しました。拡大検索の決定論的な対応版で、フィルターを自動的に緩和しないため、再現性が必要なダッシュボードや定期実行ジョブに適しています。
  • API: expansions を監視するモニターについて、フィルター語彙とウェブフックペイロードを明記しました。ウェブフックの設定を参照。
  • API: 企業拡大詳細・比較・サマリー・ランキングの各エンドポイントに is_include_metadata を記載しました。API キーによるリクエストは既定で軽量です。true を指定すると confidence_score とモデル詳細一式が返ります。
  • API: 拡大関連のエラーコード（40043、40360、40435、40436）をステータスコードに追加しました。
  • 削除: /companies/{jobs,news,advertisements}/export のリファレンスページ。エクスポートは CSV 添付を返し、別枠の data_export_credit を消費しますが、対応する検索エンドポイントが JSON で返す以上の情報は含みません。ページネーションを使った検索をご利用ください。
  • 削除: /people/enrichment のリファレンスページ。このエンドポイントはリリースされたことがありません。人物データをエンリッチするには、People Lookup に is_enrichment_available: true を指定してください。
  • ドキュメント: すべてのリクエストボディから profile_id を削除しました。API キー自体がワークスペースを識別するため、API キー利用時このパラメータは無視されていました。
  • API: 類似企業検索と類似人物検索について、必要となる参照識別子を明記しました。従来 /companies/search/similar は、ドキュメント化されたすべてのパラメータの組み合わせに対して 41847 Missing parameter を返していました。
  • API: 企業エンリッチメント が企業レコードとあわせて返す jobs、news、advertisements、similar_companies の各配列を明記し、この呼び出しが通常 30〜60 秒かかることを注記しました。
  • API: 8 つのエンドポイントが返すトップレベルの metadata（credit・topup_credit・total_credit_cost を含む profile ブロックを含む）を宣言しました。
  • API: 企業識別子系のエンドポイントで、受け付ける 9 種類の識別子をすべて記載しました（tiktok_url、wantedly_url、tw104_url、rocketpunch_url、remember_url、youtrust_url を追加）。
  • ドキュメント: API で最も頻出するエラー 41847 Missing parameter をステータスコードに追加しました。
  • ドキュメント: 認証 に User-Agent の要件を追記しました。汎用的な user agent のクライアントはエッジでブロックされ、HTTP 403 と error code: 1010 が返るため、API キーの誤りと誤解されがちです。
  • ドキュメント: レート制限 に Profile Usage が返す使用量・クォータのフィールドと、total_max_* にライセンス倍率がどう適用されるかを記載しました。
  • API: 拡大系フィルター（stages、signal_types、signal_strengths、freshness、momentum、polarity）に許容値を明記し、認識されない値はエラーにならず黙って破棄される点（パラメータによってはフィルター自体が外れ、別のパラメータでは何にも一致しなくなる点）を注記しました。
  • API: momentum は advancing、steady、pulling_back を受け付けます。Expansion Reference の directions の値（retreating、new）は stage.direction として返るレスポンス値であり、フィルターとして有効だったことはありません。
  • API: ニュースインサイトを修正 — mentions、topics、sources、top_source はトップレベルの配列ではなく data.totals 内の整数／文字列フィールドです。topics と sources は重複を除いた件数で、項目別の内訳は category_breakdown と market_breakdown にあります。
  • API: 広告インサイトを修正 — postings[] は省略キー r、m、ch、fo、n を使用し、reach_tiers[] は件数を持たない {slug, label} のカタログです。creatives[] は image_url、cta、has_video を含む全 10 フィールドを記載しました。
  • API: チャネルテンプレートの parameters のキーは channel_type_slug によって変わります。メール、LinkedIn、Twilio の各テンプレートで異なるセットを持ちます。
  • ドキュメント: API が返さないレスポンスフィールドを削除しました：User の referral_code、類似人物検索の similarity_score、LinkedIn 企業ルックアップの funding_status と crunchbase_url、ニュース検索の expansion_signals、拡大シグナル検索の occurs_at / occurs_until。
  • ドキュメント: ステータスコード表を API のエラーテーブルから再構築しました。9 個のコードが誤っていました。40075、40076、40091、40092、40095 はページネーションとクォータの失敗として記載されていましたが、実際には HTTP 416 の 41675、41676、41691、41692、41695 です。しかも記載されていた番号はいずれも別の意味を持つ実在のコードでした。40003、40602、40603 は実際には 40303、40632、40633 で、40099 は存在しません。
  • ドキュメント: HTTP 416 を記載しました。ページネーションとクォータの超過は 416 と 416xx のコードを返し、結果が丸められることはありません。
  • ドキュメント: モニター系のエラーコード（40020〜40035）を追加しました。40021 は、モニター作成後に detection_mode を変更できないことを示します。
  • API: per_page の上限はプランの max_search_per_page（多くのプランで 25）で、26 を指定すると HTTP 416 が返ります。page の上限は max_search_page です。これらを含むすべてのプラン上限は Profile が返し、レート制限に一覧化しました。
  • API: people_contact_types は email-work、email-personal、phone のみを受け付けます。認識されない値は拒否されず、HTTP 200 と emails: null、クレジット消費ゼロが返るため、対象人物に本当に連絡先が無い場合と区別がつきません。
  • API: 該当が無い場合、取得レスポンスの emails と phones は [] ではなく null を返します。
  • API: チャネルテンプレートの create パラメータを明記しました。channel_node_id は Channel Template Types から取得する UUID で、parameters に指定できるキーを決定します。delete は数値の channel_template_id を受け取り、1 回につき 1 バージョンのみ削除します。
  • API: モニターのウェブフック検証は実際の署名付き配信を行います。GET にのみ応答する URL は失敗し、details には上流のレスポンスボディが返ります。
  • 新機能: 市場拡大 API。 どの企業がどの市場に参入しているのか、そしてどこまで進んでいるのかを追跡できます — 実際の採用、ニュース、広告、クラウドインフラ、イベントの各シグナルから構築された 4 段階のはしご（Exploring → Committing → Expanding → Scaling）です。froms / tos でコリドー（回廊）を検索し、単一企業の市場参入を深掘りし、同業他社と比較できます。クイックスタートから始める。
  • 新機能: 自然言語検索。 拡大検索に平易な文章の query（例：「英国に進出しているフィンテック企業」）を渡すと、Pubrio がそれをフィルターに解釈します — is_explain_match により、各企業の実際のシグナルに基づく AI マッチ説明もオプションで利用できます。
  • API: 結果はデフォルトで、裏付けのある動き（複数の独立したシグナルタイプ）を優先する関連度順になりました。純粋な新着順には sort_by: "recent" を渡してください。
  • API: モニターが求人、ニュース、広告に加えて拡大シグナル（signal_types: ["expansions"]）を監視できるようになり、モニターインタープリット により平易な文章からモニターの下書きを作成できるようになりました。
  • API: モニターのライフサイクルは単一の status フィールド（draft / active / paused / inactive）になり、リクエストとレスポンスの従来の is_active / is_paused ブール値を置き換えました。
  • 新機能: モニター。 自動シグナル検出とリアルタイム配信 — 独自のポーリングパイプラインを構築することなく、数百万の企業の求人情報、企業ニュース、広告キャンペーンを追跡できます。フィルターを一度定義するだけで、Pubrioがスキャン、エンリッチメント、マッチしたシグナルをWebhook、メール、またはアウトリーチシーケンスに配信します。
  • 新機能: 2つの検出モード。 シグナルファースト（広範な市場スキャン）とカンパニーファースト（指定アカウントの追跡）から選択し、プロスペクティングワークフローに合わせることができます。
  • 新機能: 自動ピープルエンリッチメント。 各モニタートリガーで、マッチした企業の連絡先を自動的に検索・引き換えできます — 管理レベル、部門、役職で設定可能なマルチレイヤーエンリッチメント。
  • API: 15の新しいモニターエンドポイントを追加 — 完全なCRUD、統計、チャート、検出ログ、Webhook検証、テスト処理。モニターAPIリファレンスを参照。
  • API: リクエストボディで profile_id が不要になりました。APIキーにワークスペース情報が含まれるようになりました。このパラメータは後方互換性のために引き続き使用できます。
  • API: AI エージェントとMCPツールの互換性向上のため、全59のAPIエンドポイントに operationId、summary、description、tags を追加しました。
  • ドキュメント: AIクローラー検出のために llms.txt を有効化しました。
  • 新機能: AIスマートリスト (ベータ版)。 ユーザーはCSVをアップロードし、スプレッドシートインターフェースで表示できるようになりました。Pubrioが不足している列を自動的に埋めます。
  • データ: DACH地域（ドイツ、オーストリア、スイス）で300万の新しい検証済みエンティティを追加しました。
  • API: /enrich/company エンドポイントの応答時間が高速化しました（レイテンシを200ms短縮）。
  • 新機能: 広告検索インテリジェンス。 広告透明性センターと有料検索リポジトリをインデックス化しました。企業が広告を出しているか どうか、どこで 支出しているか、どの キーワードをターゲットにしているかを確認できるようになりました。
  • 改善: 中南米（LATAM）で非標準的なローカルソフトウェアを使用している企業の「テックスタック」検出を強化しました。

​
2025年 アーカイブ: パートナーの年

2025年は、主要なエコシステム連携によって定義され、Pubrioのデータを皆様が毎日使用するプラットフォームにお届けしました。
  • 連携: Ottokit。 自律型エージェントワークフローのためのネイティブコネクタをローンチしました。
  • 連携: Databar。 ノーコード・リサーチのためのDatabarマーケットプレイスにて、検証済みプロバイダーとしてPubrioを追加しました。
  • 連携: Stripo。 「シーケンスへのプッシュ（Push to Sequence）」機能を有効にし、デザインチームがHTMLテンプレートを直接Pubrioのワークフローに同期できるようにしました。
  • 機能: 動的変数の注入。 テンプレート内の一般的なプレースホルダーを、送信時にリアルタイムのPubrioデータで解決（置換）できるようにしました。
  • 連携: Clayネイティブ連携。 Clayのエンリッチメントメニューでデフォルトのプロバイダーになりました。
  • データ: 「見えない70%」のカバレッジを拡大し、アジア太平洋地域の15の新しいローカル登記簿を含めました。
最終更新日 2026年10月2日