人物 + 企業フィルター

POST /people/search は POST /companies/search がサポートするすべての企業フィルターを受け付けます。先に企業を取得して ID を集め、それを 2 度目の人物クエリに渡す必要はもうありません — 1 回のリクエストで両レイヤーが完結します。

1 つのボディに 2 つのパラメーターファミリー

/people/search のリクエストボディは概念的に 2 つのフィルターファミリーに分かれます。JSON 上は同じ階層に並び、自由に組み合わせられます。

人物レベル
企業レベル

人物の属性を絞り込みます:

パラメーター	説明
`people_titles`	役職名(自由テキストまたは slug)
`management_levels`	`founder`、`c_suite`、`vp`、`director`、`manager` など
`departments`	`master_engineering`、`master_sales` など
`department_functions`	サブ部門 / ファンクション slug
`people_locations`	人物所在の国コード
`people_groups`	保存済みグループ ID
`peoples`	特定の `people_search_id`
`linkedin_urls`	人物の LinkedIn URL
`social_media`	ネットワークごとの SNS ハンドル

人物が所属する企業の属性を絞り込みます — /companies/search と同名で、ロケーション系のキーだけ company_ プレフィックスがあります:

パラメーター	説明
`technologies`	企業が使用するテクノロジー slug ID
`categories`	カテゴリ slug ID
`verticals`	バーティカル slug ID
`vertical_categories`	バーティカルカテゴリ slug ID
`vertical_sub_categories`	バーティカルサブカテゴリ slug ID
`keywords`	企業の説明文に対するフリーテキストキーワード
`founded_dates`	設立年レンジ(例: `[2015, 2023]`)
`employees`	従業員レンジ(例: `[[100, 500], [501, 1000]]`)
`revenues`	売上レンジ(USD)
`company_locations`	企業本社の国コード
`company_exclude_locations`	除外する国コード
`company_places`	含める都市 / 地域名
`company_exclude_places`	除外する都市 / 地域名
`companies`	特定の `domain_search_id`
`domains`	特定の企業ドメイン
`company_linkedin_urls`	企業の LinkedIn URL

company_ プレフィックスはロケーション/プレース系フィルターにのみ存在します。places / locations の bare 名は既に人物の住所に使われているためです。それ以外はすべて bare の企業名(technologies であって company_technologies ではありません)。

4 ステップでクエリを組み立てる

人物条件を決める

具体的に誰? 役職、シニオリティ、部門、国。このレイヤーはボディの トップレベル に置きます — 精度の役割は通常、企業条件が担います。

企業条件を決める

どんな企業に勤めている必要があるか? 業界、規模、設立年、本社国、テックスタック。これらは company_filters: {...} オブジェクトにまとめると、どのキーがどのレイヤーに属するかが一目で分かります。

filter_conditions でフィルターごとに AND/OR を選ぶ

精度が必要な複数値フィルター(例: 「これらの技術を すべて 使う」)には、company_filters の中の filter_conditions にエントリを追加。デフォルトは OR。

リクエストを送る

POST /people/search。どちらのスタイルも受け付けますが、company_filters: {...} は読みやすく、Monitor のペイロード形状とも一致します。

完全な例

クエリ: 米国を本社に置き、設立 2015〜2023 年、従業員 100〜5,000 人、Kubernetes と Docker を両方使い、サンフランシスコは除外する中堅企業の VP of Engineering または CTO。

curl -X POST https://api.pubrio.com/people/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "people_titles": ["VP of Engineering", "CTO"],

    "company_filters": {
      "company_locations": ["US"],
      "company_exclude_places": ["San Francisco"],
      "founded_dates": [2010, 2024],
      "employees": [[100, 500], [501, 1000], [1001, 5000]],
      "technologies": ["Kubernetes", "Docker"],
      "is_enable_similarity_search": true
    },

    "per_page": 25,
    "page": 1
  }'

import requests

response = requests.post(
    "https://api.pubrio.com/people/search",
    headers={
        "Content-Type": "application/json",
        "pubrio-api-key": "YOUR_API_KEY",
    },
    json={
        "people_titles": ["VP of Engineering", "CTO"],

        "company_filters": {
            "company_locations": ["US"],
            "company_exclude_places": ["San Francisco"],
            "founded_dates": [2010, 2024],
            "employees": [[100, 500], [501, 1000], [1001, 5000]],
            "technologies": ["Kubernetes", "Docker"],
            "is_enable_similarity_search": True,
        },

        "per_page": 25,
        "page": 1,
    },
)
print(response.json())

const response = await fetch("https://api.pubrio.com/people/search", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "pubrio-api-key": "YOUR_API_KEY",
  },
  body: JSON.stringify({
    people_titles: ["VP of Engineering", "CTO"],

    company_filters: {
      company_locations: ["US"],
      company_exclude_places: ["San Francisco"],
      founded_dates: [2010, 2024],
      employees: [[100, 500], [501, 1000], [1001, 5000]],
      technologies: ["Kubernetes", "Docker"],
      is_enable_similarity_search: true,
    },

    per_page: 25,
    page: 1,
  }),
});
console.log(await response.json());

キー再マッピングのリファレンス

/people/search が共有エンジンに企業フィルターを引き渡すとき、ロケーション/プレース系のキーは bare 名にリネームされます。エンジンと filter_conditions[].key が実際に見るのはこの bare 名です:

送信時(人物 API 名)	エンジンが見る名前(企業 API 名)
`company_locations`	`locations`
`company_exclude_locations`	`exclude_locations`
`company_places`	`places`
`company_exclude_places`	`exclude_places`
`technologies`、`verticals`、`vertical_categories`、`vertical_sub_categories`、`categories`、`keywords`、`founded_dates`、`employees`、`revenues`	そのまま

このため、企業レベルのロケーションに対する filter_conditions[].key には bare 名を使います:

{
  "company_places": ["New York", "Boston"],
  "filter_conditions": [
    { "key": "places", "operator": "and" }
  ]
}

{ "key": "company_places", "operator": "and" } は黙って無視されます — エンジンはプレフィックス付きの名前を認識しません。filter_conditions では常にエンジン名を参照してください。

内部の JOIN

いずれかの 企業レベルフィルターを追加すると、人物 → 企業の JOIN が LEFT JOIN から INNER JOIN に切り替わります。人物レベルのフィルターをすべて満たしていても、紐づく企業が確認できない人物は結果から除外されます。

company_locations や technologies を加えた途端に結果が 0 になる場合は、期待する人物に紐づく企業がデータセットに存在するか確認してください。エンジンはここで再現より正確性を優先します — フィルター充足のために企業を捏造することはありません。

レスポンスにも同じ JOIN 挙動が反映されます: 企業フィルターを 1 つでも適用すると、返される各人物は必ず company オブジェクトを含みます。

よくあるパターン

アカウントベースドマーケティング(ABM)

固定の企業リスト(companies または domains)をターゲットにし、人物レベルのフィルターを重ねて各社内の適切なバイヤーを見つけます。

{
  "people_titles": ["VP Marketing", "CMO"],
  "management_levels": ["vp", "c_suite"],
  "company_filters": {
    "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"]
  }
}

理想顧客プロファイル(ICP)発見

具体的なアカウントではなく、企業の「形」を記述します。レンジとバーティカルを使い、エンジンが該当する人物を返します。

{
  "people_titles": ["Head of Engineering"],
  "company_filters": {
    "verticals": [12, 47],
    "company_locations": ["US", "CA"],
    "founded_dates": [2015, 2023],
    "employees": [[51, 200], [201, 500]],
    "filter_conditions": [
      { "key": "verticals", "operator": "and" }
    ]
  }
}

技術駆動のプロスペクティング

特定のスタックを使う企業のバイヤーを探します。technologies への AND が典型的なオーバーライドです。

{
  "people_titles": ["RevOps", "Sales Operations"],
  "departments": ["master_sales"],
  "company_filters": {
    "technologies": [114, 287, 452],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ]
  }
}

競合リプレイス

競合の製品(あるテクノロジー)を使っているが、自社製品は使っていない(categories で除外、または別フィルターパス)企業の意思決定者を見つけます。

{
  "people_titles": ["VP Sales"],
  "management_levels": ["vp"],
  "company_filters": {
    "technologies": [287]
  }
}

その後 technologies: [114](自社製品のタグ ID)で再実行し、クライアント側で差分を取ります。

次のステップ

filter_conditions

完全リファレンス — 全キー、全デフォルト、コピー可能な AND/OR レシピ。

フィルター概要

統一フィルターエンジンの背後にあるメンタルモデル。

人物検索リファレンス

/people/search の完全なリクエスト/レスポンススキーマ。

企業検索リファレンス

/companies/search の完全なリクエスト/レスポンススキーマ。

モニター

フィルター

人物

拡大

1 つのボディに 2 つのパラメーターファミリー

4 ステップでクエリを組み立てる

完全な例

キー再マッピングのリファレンス

内部の JOIN

よくあるパターン

次のステップ

filter_conditions

フィルター概要

人物検索リファレンス

企業検索リファレンス

​1 つのボディに 2 つのパラメーターファミリー

​4 ステップでクエリを組み立てる

​完全な例

​キー再マッピングのリファレンス

​内部の JOIN

​よくあるパターン

​次のステップ

filter_conditions

フィルター概要

人物検索リファレンス

企業検索リファレンス

1 つのボディに 2 つのパラメーターファミリー

4 ステップでクエリを組み立てる

完全な例

キー再マッピングのリファレンス

内部の JOIN

よくあるパターン

次のステップ