自然言語の検索がどう解決されるか

Signal Foundry の自然言語検索は、単純な全文検索ではありません。 会社群の依頼は list estimate、1 社特定は companies search、保存しない横断探索は observations/search で処理の仕方が違うため、使い分けを理解するとヒット率と保存体験がかなり上がります。

まず結論

• 会社を解決したいときは sf companies search <query>
• 保存したい会社群が対応済み条件で書けるときは sf list estimate "<query>"
• テーマに反応している会社群を探したいときは、まず sf observations search か sf job sales-list
• 保存しない横断探索だけ sf observations search [query]
• 長い自然文をそのまま入れるより、短い query と明示的な filter に分けた方が安定します

まず何が起きるか

自然文の依頼を受けたとき、内部では次の 4 段階で処理されます。

1. 依頼が 会社群作成 か 会社解決 か 横断探索 か 有報差分 かを決める
2. 選ばれた surface ごとに query を正規化する
3. candidate を作り、relevance を計算する
4. なぜヒットしたかを query_match や observation.summary / evidence で返す

つまり、自然文 -> そのまま 1 本の search ではありません。最初にどの surface を選ぶかが最重要です。

よくある依頼と内部の分岐

companies search の解決順

sf companies search は、概ね次の順で company 候補を組み立てます。

1. 入力を正規化する
2. sf_company_identifiers の exact match を見る
3. company_id の exact candidate を見る
4. 正規化済み company name の exact match を見る
5. 必要なときだけ normalized name の prefix match を足す
6. relevance で並べる

実用上の意味は次です。

• 7203 のような code っぽい query は強く exact 解決を狙う
• jpx_7203 のような canonical company_id も直接解決できる
• ＡＢＥＪＡ のような表記ゆれは正規化で吸収される
• free text が曖昧なときは、社名 prefix と関連 field で補助する

companies search で relevance に使われる field

高く評価されやすい順に、概ね次を見ています。

• company_id
• display_name
• legal_name
• website_domain
• website_url
• market_segment
• industry_33
• industry_17

さらに次の補正があります。

• identifier exact match は強い加点
• listed の会社は少し優先

つまり、上場コード、社名、website domain のいずれかが分かっているとかなり強いです。

list estimate の使いどころ

sf list estimate は、自然文の会社群を保存前に見積もる surface です。

sf list estimate "上場企業のうち、売上100億以上" --json
sf list candidates --from-estimate <estimateId> --json

ここで重要なのは、estimate_id が frozen plan になることです。candidates と materialize は自然文を再解釈せず、この plan を使います。対応しやすい条件は、上場状態、market segment、会社名/識別子、EDINET 財務指標のしきい値、EDINET本文のkeyword/semanticテーマ検索です。

保存する時だけ、credit 上限を明示して実行します。

sf list materialize --from-estimate <estimateId> --name "AI CRM Targets" --execute --max-credits 100 --json

candidate preview は薄い確認用で、export できません。CSV が必要なら materialize 後に sf list export を使います。

確認する key

• companies[].company.company_id
• companies[].query_match
• estimate.estimate_id
• resolved_definition.warnings
• counts.matched_companies
• billing.materialize.estimated_credits
• results[].matched_observations[].summary
• results[].matched_observations[].evidence

companies search で実際に何がヒットするか

例:

sf companies search 7203 --json

この場合は、7203 が identifier exact match として強く扱われ、jpx_7203 や関連 identifier が上位に来ます。

別の例:

sf companies search "トヨタ" --json

この場合は、社名正規化と prefix match が効きます。ただし、曖昧な社名では別会社が先に出ることがあるので、確実に進めたいなら証券コードや domain を使ってください。

observations/search の解決順

POST /api/signal-foundry/observations/search は company を直接返すのではなく、まず observation を集めてから company ごとに group します。

処理は概ね次の順です。

1. query から母集団語や接続語を落としてテーマ token に寄せる
2. SQL で company_ids observation_types observation_subtypes sources を先に絞る
3. EDINET本文は keyword 検索に加えて、embedding backfill 済みなら semantic 検索も使う
4. LLM のような短い英語テーマ語は 大規模言語モデル 生成AI AIエージェント 自然言語処理 などへ展開してから EDINET 本文に当てる
5. app 側で company / profile filter をかける
6. token が summary type subtype source evidence company名 industry website に入るか、または semantic similarity があるかを見る
7. relevance を計算し、company ごとにまとめる

ここで重要なのは、構造条件とテーマ語を混ぜすぎないことです。生成AIに関連する上場企業 のような自然文は、母集団語を落としてテーマ evidence に当てます。一方で、保存やcredit見積もりは list estimate で frozen plan にします。

observations/search で実際に何が起きるか

例:

sf observations search "生成AI CRM" \
  --industry 情報・通信業 \
  --limit 10 \
  --observations-per-company 3 \
  --json

この場合は、まず industry で候補 company 群を絞り、そのあと 生成AI と CRM が summary type subtype source evidence などに入る observation を探します。返ってくるのは company 単位のまとめですが、内部では先に observation を集めてから company ごとにまとめています。

そのため、ユーザーが感じる なんでこの会社が出たのか の答えは、最終的には observations[].summary と evidence にあります。

良い query と悪い query

悪い例:

{
  "query": "東証プライムの情報通信企業で生成AIとCRMと営業効率化に積極的な会社"
}

良い例:

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

構造条件は filters に移し、query はテーマ語だけに寄せてください。

まずは短く当てる

sf observations search "生成AI CRM" \
  --industry 情報・通信業 \
  --market-segment prime \
  --limit 10 \
  --observations-per-company 3 \
  --json

結果が弱いときは、次の順で直します。

1. query の token を減らす
2. 制約を filters へ移す
3. まず companies search で company_id を解決し、company_ids filter を使う
4. LLM GenAI のような短い英語略語だけなら、日本語同義語を 1 つ足す
5. それでも不足するなら sources や observation_types を見直す

復旧方法

companies search が曖昧な場合は、証券コード、canonical company_id、website domain の順で query を狭めます。list estimate が unsupported 条件を返す場合は、保存せずに sf list plan "<query>" --json で条件を分解します。observations search が弱い場合は、自然文を短いテーマ語と explicit filter に分け直してください。

Claude Code / Codex がやるべき分解

自然文の依頼を agent が受けたら、まず次のように分解すると安定します。

• 固有名詞がある: companies search
• 対応済み条件で保存したい会社群: list estimate
• テーマ語しかない会社群: observations search または job sales-list
• 上場日や IPO 年で絞る会社群: list plan と capability map で listing_events coverage を確認し、supported なら estimate に進む
• 保存しない横断探索だけ: observations search
• 差分 前回 有報 がある: company filings、filing show、filing compare
• 保存しておきたい がある: list materialize --execute --max-credits

たとえば 生成AI に積極的な競合を出して、あとで見直せるようにして と言われたら、1 本の search に流すのではなく、次の 2 段階に分けます。

1. observations search または job sales-list でテーマ根拠を確認する
2. 候補条件を上場状態、業種、財務指標などの対応済み条件に分解する
3. list estimate と list candidates で対象会社数と credit を見る
4. list materialize --execute --max-credits で保存 loop を作る
5. 必要なら list enrich --source website と list export へ進む

この分解をしないと、検索は当たったが後で見返せない か、保存したが何を根拠に入れたか分からない のどちらかになりやすいです。

このページに含めないもの

自然言語検索の結果を無確認で publish queue に積み上げる導線は、現時点の public product core ではありません。一方で、保存前の見積もりと確認として sf list estimate、sf list candidates、保存面として sf list materialize、追加情報として sf list enrich は使えます。