entity データを扱うとき、source ごとに API やテーブルをそのまま見せる設計は作りやすい一方で、使う側の負担を増やします。
EDINET は EDINET の shape、gBizINFO は gBizINFO の shape、企業サイトはクローラの shape のまま返すと、最終的に agent 側が全部つなぎ直す必要があります。Signal Foundry はこの負担を product の責務として吸収するために、入口を Search、Company Card、Signals、Usage に寄せています。
外部 contract で固定しているもの
Signal Foundry が v0 で外に返す基本形は、次の object です。
SearchCompanyCompany CardSignalsUsageevidence
v0 では最初の entity type として company を扱います。そのため company API は重要です。ただし、実行の入口は source-specific API ではなく、company_id を解決してから同じ contract を読む流れです。
company-first v0 で返す主要な shape は、次の通りです。
identifiersprofileobservationsevidence
重要なのは、source ごとの生データを消すことではなく、外から見たときの入口を固定することです。
source-specific を内部に閉じる理由
内部では EDINET や website 由来の個別テーブルを持ちます。raw artifact や時系列も保持します。ただし、それを public contract にすると、source の追加や変更がそのまま API 破壊につながります。
Company-first workflow にしておけば、内部の取り込み方法を改善しても、外部側の呼び出しは次の流れを保てます。
sf search <query> --jsonでcompany_idを解決するsf company <companyId> --jsonで Company Card を読む- 必要な会社だけ
sf signals <companyId> --jsonへ進む sf usage --jsonで credit 境界を確認する- 表や CSV は agent 側でローカルに作る
agent にとっての利点
人間向け UI なら、多少 source ごとの癖があっても吸収できます。ですが agent は、shape の揺れに弱い側面があります。
同じ調査で毎回 source ごとの分岐を書かせるより、まず stable id に解決してから同じ contract をたどれる方が、プロンプトもツール利用も安定します。
これは UX の問題というより、実運用コストの問題です。
競争優位は UI ではなく正規化
Signal Foundry の優位は、見た目の UI ではありません。
- source をまたぐ識別子解決
- Company Card / Signals / evidence の contract
- evidence 付き observation
- coverage / freshness の把握
この積み上げがあるから、agent がデータを再利用しやすくなります。company は v0 の最初の entity です。今後 source と entity type が増えても、外部 contract は stable id と evidence を読む形に寄せます。