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