GET /companies

GET /api/signal-foundry/companies は、最初の入口です。自由入力をそのまま 後続エンドポイント に渡すのではなく、まずここで company_id を解決してください。

契約サマリー

この エンドポイントの役割 は、社名、証券コード、法人番号、domain などの入力から canonical company_id 候補を返すことです。profile や会社別 Signals へは、ここで選んだ company.company_id を渡してください。

リクエスト

curl -s \
  -H "Authorization: Bearer <SIGNAL_FOUNDRY_API_KEY>" \
  "https://signal-foundry.app/api/signal-foundry/companies?q=7203&limit=3"

クエリパラメータ

Matching behavior

この endpoint は単純な全文検索ではありません。次の順で 会社 candidate を集めます。

• identifier exact match
• company_id exact match
• normalized name exact match
• normalized name prefix match

さらに relevance を付けて並べ替えます。identifier_matched=true の結果は強く優先され、上場会社は軽く boost されます。

has_jobs、ai_jobs、construction、prefecture、min_employees、order のいずれかを使う場合は、会社検索の hot path を sf_company_source_enrichment_mv に切り替えます。この場合、レスポンスの companies[].source_context に求人件数、求人ソース数、求人の最新観測日時、AI 求人件数、建設業許可件数、営業所件数、サンプル求人タイトルなどが入ります。q=大阪の製造業で求人募集 のような自然文からは、都道府県・製造業・求人条件をできる範囲で構造化して解釈します。source enrichment hot path では、meta.matched_companies は scan 済み件数ではなく、条件に合う総件数です。

この endpoint は会社起点です。prefecture は会社所在地の絞り込みで、求人勤務地の絞り込みではありません。個別求人の一覧を先に出してから会社情報を紐付ける job-row 起点の workflow は、会社検索とは別の求人検索 surface で扱います。

レスポンス

まず見る key:

• object
• status
• companies[].company.company_id
• companies[].company.display_name
• companies[].profile.website_domain
• companies[].query_match.identifier_matched
• companies[].query_match.relevance
• warnings[]
• meta.coverage_warnings
• meta.returned_companies
• meta.has_more

{
  "ok": true,
  "object": "company_search",
  "status": "ready",
  "companies": [
    {
      "company": {
        "company_id": "jpx_7203",
        "display_name": "トヨタ自動車",
        "legal_name": "トヨタ自動車株式会社",
        "listing_status": "listed",
        "market_segment": "prime"
      },
      "profile": {
        "website_domain": "global.toyota",
        "website_url": "https://global.toyota",
        "latest_observed_at": "2026-04-30T00:00:00.000Z",
        "observation_counts": {},
        "technologies": []
      },
      "query_match": {
        "identifier_matched": true,
        "relevance": 120
      },
      "source_context": null
    }
  ],
  "warnings": [],
  "meta": {
    "query": "7203",
    "returned_companies": 1,
    "matched_companies": 1,
    "has_more": false,
    "coverage_warnings": []
  }
}

この HTTP レスポンスでは、候補会社は companies[] に入り、canonical ID は companies[].company.company_id、表示名は companies[].company.display_name で確認します。

warnings[] / meta.coverage_warnings は 0 件の読み違いを防ぐための contract です。求人、建設、Web、semantic tag、未対応条件で weak、pending、no_data、unsupported が出た場合は、該当企業なしと断定せず、source route や Company Card / filing evidence で確認します。財務しきい値を決定的に扱う場合は、自然文 q に残さず Company Query に company_query.v1 を渡します。

CLI equivalent

sf search "7203" --json
sf search "大阪の製造業で求人募集" --order jobs --json
sf search "AI系の求人" --ai-jobs true --order ai --json

CLI でも見る key は同じです。

• companies[0].company.company_id
• companies[0].company.display_name
• meta.returned_companies

Company Card と Signals

会社を先に 1 社解決してから、その会社だけを深掘りする場合は profile --card と必要な Signals を使います。採用、Web、技術、IR、建設業許可などの根拠は、会社単位の JSON として読み、表や CSV はローカルで作ります。

sf company profile jpx_7203 --card --json
sf company observations jpx_7203 --limit 10 --json
sf company filings jpx_7203 --limit 5 --json

求人明細や建設業許可明細を行として見る場合は、専用の search surface から会社 context 付きで確認します。

sf job search "大阪勤務のAI求人" --json
sf construction search "大阪の建設業許可" --json

復旧方法

0 件を「会社が存在しない」と断定しないでください。まず 検索条件を短くし、sf company search <query> --json で候補の company_id を確認してから、profile --card / Signals に進みます。