> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 人物 + 企業フィルター
> 1 回の /people/search 呼び出しで人物レベルと企業レベルのフィルターを組み合わせる — /companies/search と同じフィルターエンジン。
`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: {...}`** オブジェクトにまとめると、どのキーがどのレイヤーに属するかが一目で分かります。
精度が必要な複数値フィルター(例: 「これらの技術を *すべて* 使う」)には、`company_filters` の *中* の `filter_conditions` にエントリを追加。デフォルトは OR。
`POST /people/search`。どちらのスタイルも受け付けますが、`company_filters: {...}` は読みやすく、[Monitor](/jp/developer-guides/introduction) のペイロード形状とも一致します。
### 完全な例
クエリ: 米国を本社に置き、設立 2015〜2023 年、従業員 100〜5,000 人、Kubernetes と Docker を *両方* 使い、サンフランシスコは除外する中堅企業の VP of Engineering または CTO。
```bash cURL theme={null}
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
}'
```
```python Python theme={null}
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())
```
```javascript Node.js theme={null}
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 名を使います:
```json theme={null}
{
"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` オブジェクトを含みます。
***
## よくあるパターン
固定の企業リスト(`companies` または `domains`)をターゲットにし、人物レベルのフィルターを重ねて各社内の適切なバイヤーを見つけます。
```json theme={null}
{
"people_titles": ["VP Marketing", "CMO"],
"management_levels": ["vp", "c_suite"],
"company_filters": {
"companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"]
}
}
```
具体的なアカウントではなく、企業の「形」を記述します。レンジとバーティカルを使い、エンジンが該当する人物を返します。
```json theme={null}
{
"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 が典型的なオーバーライドです。
```json theme={null}
{
"people_titles": ["RevOps", "Sales Operations"],
"departments": ["master_sales"],
"company_filters": {
"technologies": [114, 287, 452],
"filter_conditions": [
{ "key": "technologies", "operator": "and" }
]
}
}
```
競合の製品(あるテクノロジー)を使っているが、自社製品は使っていない(`categories` で除外、または別フィルターパス)企業の意思決定者を見つけます。
```json theme={null}
{
"people_titles": ["VP Sales"],
"management_levels": ["vp"],
"company_filters": {
"technologies": [287]
}
}
```
その後 `technologies: [114]`(自社製品のタグ ID)で再実行し、クライアント側で差分を取ります。
***
## 次のステップ
完全リファレンス — 全キー、全デフォルト、コピー可能な AND/OR レシピ。
統一フィルターエンジンの背後にあるメンタルモデル。
`/people/search` の完全なリクエスト/レスポンススキーマ。
`/companies/search` の完全なリクエスト/レスポンススキーマ。