AND / OR 演算子

filter_conditions はリクエストボディ上のオプションの配列です。各要素は、1 つの複数値フィルターをデフォルトの OR(「いずれかにマッチ」)から AND(「すべてにマッチ」)へ、あるいはその逆へと切り替えます。記載されていないフィルターはデフォルトのままです。

スキーマ

{
  "filter_conditions": [
    { "key": "technologies", "operator": "and" },
    { "key": "verticals",    "operator": "or"  }
  ]
}

各要素の key と operator はどちらも必須です。operator のみのエントリは黙って無視されます — グローバルなオーバーライド設定はありません。

なぜ重要か

デフォルト演算子が OR なのは、多くのプロスペクティングが広い再現を求めるためです: 「いずれかの国の人物」「いずれかのバーティカルがタグ付けされた企業」。一方で、高精度のターゲティング — 「Salesforce + HubSpot + Marketo を すべて 使う」 — には AND が必要です。選択を誤ったときのコスト:

AND が欲しかったのに OR: 過剰再現になり、1 タグだけマッチした企業まで含まれてしまう。気づきやすいが結果品質を損ないます。
OR が欲しかったのに AND: 再現不足になり、複数値の AND は実世界の配列にすべての要求値が揃わないため、ほぼ 0 行になることが多い。気づきやすく、クエリが壊れて見えます。

内部的には、選んだ演算子は Postgres ネイティブの配列演算子にコンパイルされます: OR なら &&(オーバーラップ)、AND なら @>(包含)。どちらもインデックスに優しく、コストの違いはクエリ遅延ではなく 結果サイズ に現れます。

サポートされるキー

正確なキーセットは呼び出すエンドポイントによります:

キー	`/companies/search`	`/people/search`	`/companies/advertisements/search`	デフォルト	`and` の意味
`technologies`	✓	✓	—	OR	リストの全テクノロジーを保有
`categories`	✓	✓	—	OR	全カテゴリでタグ付け
`verticals`	✓	✓	—	OR	全バーティカルに属する
`vertical_categories`	✓	✓	—	OR	全バーティカルカテゴリに属する
`vertical_sub_categories`	✓	✓	—	OR	全サブカテゴリに属する
`keywords`	✓	✓	—	OR	説明が全キーワードを含む
`places`	✓	✓	—	OR	全場所に所在
`exclude_places`	✓	✓	—	OR	全場所から除外
`advertisement_target_locations`	✓	—	—	OR	広告が全国を対象(企業エンドポイント)
`advertisement_exclude_target_locations`	✓	—	—	OR	広告が全国を除外
`advertisement_search_terms`	✓	—	—	OR	広告コピーが全語句を含む
`job_exclude_locations`	✓	—	—	OR	求人が全ロケーションを除外
`social_media`	—	✓	—	OR	人物が全 SNS アカウントを保有
`target_locations`	—	—	✓	OR	広告が全国を対象(広告エンドポイント)
`exclude_target_locations`	—	—	✓	OR	広告が全国を除外

上記のキーは OpenAPI 各 *_filter_conditions スキーマの enum(company_filter_conditions、people_filter_conditions、ads_filter_conditions)を反映しています。エンドポイントが対応しないキーを送っても黙って無視されます。

レシピ

全テクノロジーを保有(企業)
いずれかのロケーション + 除外
マルチリージョン広告キャンペーン
複数スタック企業の人物

目標: Python、PostgreSQL、Kubernetes を すべて 使っている企業 — 1 つだけではなく。

curl -X POST https://api.pubrio.com/companies/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "technologies": [37, 152, 408],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ],
    "per_page": 25,
    "page": 1
  }'

filter_conditions の要素を外せば、3 つの いずれか を含む検索に拡張されます。

目標: US・CA・GB の いずれか に所在し、サンフランシスコは除外する企業。locations のデフォルトは既に OR なので、明示する必要はありません。exclude_places は独立したネガティブフィルター — オーバーライドも不要。

curl -X POST https://api.pubrio.com/companies/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "locations": ["US", "CA", "GB"],
    "exclude_places": ["San Francisco"],
    "per_page": 25,
    "page": 1
  }'

目標: EU と US の両方を対象とする広告(マルチリージョンキャンペーン) — 単一市場の広告ではなく。専用の ads_filter_conditions スキーマで target_locations キーを使います。

curl -X POST https://api.pubrio.com/companies/advertisements/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "target_locations": ["US", "DE", "FR"],
    "filter_conditions": [
      { "key": "target_locations", "operator": "and" }
    ],
    "start_dates": ["2026-01-01"],
    "end_dates":   ["2026-04-22"],
    "per_page": 25,
    "page": 1
  }'

広告エンドポイントは独自の ads_filter_conditions スキーマ(キーセットが小さい: target_locations、exclude_target_locations)を使います。/companies/search や /people/search で使えるオーバーライドキーはここでは適用 されません。

目標: Salesforce と HubSpot を両方導入している企業の人物 — 古典的な CRM リプレイス信号。同じ technologies キーと演算子を /people/search で使う、統一エンジンの実例です。

curl -X POST https://api.pubrio.com/people/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "people_titles": ["RevOps", "Sales Operations"],
    "technologies": [114, 287],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ],
    "per_page": 25,
    "page": 1
  }'

よくある間違い

key を忘れて operator だけ送る

グローバルな「デフォルト演算子」スイッチはありません。各エントリは具体的なフィルターを指定する必要があります:

// 無視される — key がない
{ "filter_conditions": [{ "operator": "and" }] }

// 正しい — technologies フィルターだけを上書き
{ "filter_conditions": [{ "key": "technologies", "operator": "and" }] }

エントリが組み合わさると思い込む

エントリはキーごとに独立した上書きで、相互に連鎖しません。technologies と verticals を両方並べても、両者の間にブール式は構築されません。各々が自分の配列の演算子を設定するだけです。フィルターキー間 の組み合わせは常に AND(全フィルターがマッチする必要)です。filter_conditions で異なるフィルター次元を OR 結合することはできません。本当に「異なるフィルターの OR」検索が必要なら、2 回リクエストを投げてクライアント側でマージしてください。

長い配列で AND を使う

AND は column @> ARRAY[…] — すべての値が必要です。8 件以上になるとほぼ常に 0 行になります。実世界のタグ付けは疎なため。AND オーバーライドの配列は 2〜4 値に抑え、探索的・カテゴリレベルのフィルタリングは OR で。

/people/search の企業フィルターでキーを間違える

/people/search では人物 API 名は company_places / company_locations です。しかし filter_conditions[].key の中では エンジン名 — places、locations を使います。再マッピングは filter_conditions 参照前に内部で完了します。

// 上書きされない — エンジンは "company_places" をフィルターキーと認識しない
{ "filter_conditions": [{ "key": "company_places", "operator": "and" }] }

// 正しい
{ "filter_conditions": [{ "key": "places", "operator": "and" }] }

完全な再マッピング表は人物 + 企業フィルターページにあります。

迷ったら、まず filter_conditions を省略して結果件数を期待値と照合してください。デフォルトが意図に合わないフィルターにだけオーバーライドを追加する — リクエストペイロードが小さく、デバッグも楽になります。

フィルター概要

メンタルモデル — filter_conditions が初めての方はここから。

人物 + 企業フィルター

/people/search に企業フィルターを重ねる方法、キー再マッピングを含む。

企業検索リファレンス

/companies/search の完全なリクエストスキーマ(company_filter_conditions 含む)。

人物検索リファレンス

/people/search の完全なリクエストスキーマ(people_filter_conditions 含む)。

モニター

フィルター

スキーマ

なぜ重要か

サポートされるキー

レシピ

よくある間違い

関連項目

フィルター概要

人物 + 企業フィルター

企業検索リファレンス

人物検索リファレンス

モニター

フィルター

​スキーマ

​なぜ重要か

​サポートされるキー

​レシピ

​よくある間違い

​関連項目

フィルター概要

人物 + 企業フィルター

企業検索リファレンス

人物検索リファレンス

スキーマ

なぜ重要か

サポートされるキー

レシピ

よくある間違い

関連項目