低ヒット query の見直し方

ヒットが少ないときは、データ不足より先に query 設計を疑ってください。 特に observations/search は、長い自然文をそのまま入れると一気に弱くなります。

companies search が弱いとき

悪い例:

sf companies search "生成AI に積極的な上場企業" --json

良い例:

sf companies search 7203 --json
sf companies search トヨタ --json
sf companies search 情報・通信業 --listing-status listed --json

見直し方:

• まずコードか社名で解決する
• 長い説明文をやめる
• 業種や市場区分は flag に寄せる
• 必要なら has_website を使う

observations/search が弱いとき

悪い例:

{
  "query": "東証プライムでCRMもMAも生成AIもやっていて営業効率化に積極的な会社"
}

良い例:

{
  "query": "生成AI CRM",
  "filters": {
    "market_segments": ["prime"],
    "industries": ["情報・通信業"]
  }
}

見直し方:

1. query を 1-3 token に減らす
2. 業種や市場区分は filters へ移す
3. 会社が分かっているなら company_ids を使う
4. source を限定しすぎていないか確認する

まず広く、あとで絞る

sf observations search "生成AI CRM" \
  --limit 10 \
  --observations-per-company 3 \
  --json

最初は broad に当てて、結果を見てから filters.industries や filters.sources を足してください。

scan_limit にぶつかるとき

POST /api/signal-foundry/observations/search の response では、meta.scanned_observations と meta.scan_limit が返ります。 この 2 つが同じなら、広すぎる query で打ち切られている可能性があります。

その場合も、まずやるべきは scan_limit をむやみに増やすことではなく、query と filters を整理することです。

現時点で含まれないもの

external research を queue として再検索に回す automation は、現時点の public product core ではありません。 一方で、補助メモとして sf research add で保存すること自体はできます。今は query を短くする filters を正しく使う のが最も効果的です。