最近の更新

Codex / Claude Code から Signal Foundry を使う時、依頼文をそのまま検索語にせず、検索前に実行計画へ分解する skill を強化しました。

変わったこと

• 営業リスト、候補、根拠付き などの業務意図を検索語から外し、filter や追加確認に分けます
• 財務条件は自然文検索ではなく company_query.v1 に変換します
• 非上場 / 未上場 は private として扱います
• 会社の導入事例や技術シグナルは、company_id がない場合に止めます
• ROE / ROA、直近四半期、OR 条件、TDnet など未対応の条件は、近い指標で代用せず unsupported として扱います

なぜ重要か

agent が誤った検索語や代用条件で実行すると、もっともらしいが意図と違う結果になります。

今回の更新では、検索前の計画を機械検証できる形にしました。高リスクな live 検証では、実行計画の判定が 9/9 で通過しています。

見る key:

• route
• q
• filters
• company_query.predicates
• company_query.unsupported_predicates
• stop_if

更新方法

CLI 更新後、agent skill を入れ直してください。

sf agent install --target codex --force --json
sf agent install --target claude-code --force --json

配置後は agent を再起動します。

CLI 0.3.26 では、agent が古いログや単発のレスポンス例から key を推測しないよう、ローカルの schema 確認コマンドを追加しました。

変わったこと

• sf schema <surface> --json で、Search、Company Card、Signals、Query、Usage、capability payload の見る key を確認できます
• TDnet / 適時開示が必須のイベント検索は、未対応 source を silent 0件にせず source_route_unsupported として返します
• M&A / FA、信用リスク、人手不足、テーマ・市場マップ系の検索は、候補探索の前に source_route_recommended warning を返します
• bundled agent skill は source_executor_agent_routing を読み、自然文をそのまま Company Search の q に流す前に route を確認します

見る key

• surface.required_read_keys[]
• meta.coverage_warnings[]
• gaps[]
• warnings[]
• error.code

weak、unsupported、needs_human、gaps[] は 0 件成功として扱わないでください。

CLI 0.3.25 では、公開CLIのユーザーテストで見つかった検索ルーティングの不具合を修正しました。

変わったこと

• sf search "AIメカテック" --json と sf company search "AIメカテック" --json は、AI を意味タグとして扱わず、社名検索として実行します
• 半角 AIメカテック の入力でも、全角 ＡＩメカテック として登録されている会社名に一致しやすくします
• sf construction search "上場企業の大阪の建設業許可" --json は、上場企業 のような汎用条件語を検索語として残さず、大阪府の建設業許可検索として実行します
• 同じ誤りを戻さないよう、root search、company search、construction search、会社名正規化の回帰テストを追加しました

これにより、利用可能と説明している基本検索導線で、CLI側の自然文変換が原因で0件になる状態を減らします。

上場企業の財務条件検索で、対応済みとして扱える範囲を広げました。自然文をそのまま文字列検索に流すのではなく、agent が company_query.v1 を作り、Signal Foundry が構造化された財務条件として実行します。

変わったこと

• 売上、営業利益、純利益、総資産、負債、自己資本比率、営業CF、投資CF、財務CF など、40 個の最新年度指標を検索条件として扱えます
• データが存在する年度は、単一年度の財務条件も検索用データとして使えます
• 未対応の条件は 0 件成功にせず、unsupported や gap として返します
• 残っている source / parser / key review は、対応済み範囲とは分けて追跡します

まだ主張しないこと

すべての上場企業・すべての年度・すべての財務概念が完全に検索できる、とはまだ主張しません。会社再編、四半期条件、未整備の複合指標、source/parser/key の追加確認が必要な行は、今後の改善対象として残しています。

今回の変更は、対応済み範囲を安全に使える状態へ進めるものです。

財務条件を含む会社検索は、自然文だけでは曖昧になりやすい領域です。今回、company_query.v1 から実行できる Financial Gold 指標を広げ、売上だけでなく、主要なPL/BS/CFのしきい値でも上場企業を決定的に絞り込めるようにしました。

変わったこと

• gross_profit、cost_of_sales、selling_general_admin_expenses、operating_income などのPL指標を追加しました
• gross_profit_margin、operating_margin、ordinary_income_margin、net_income_margin を、同一期間・同一連結範囲の revenue と利益指標から派生する ratio 指標として追加しました
• assets、liabilities、equity、current_assets、current_liabilities、cash_and_deposits に加えて、noncurrent_assets、noncurrent_liabilities、trade_receivables、trade_payables を追加しました
• operating_cash_flow、investing_cash_flow、financing_cash_flow、depreciation_amortization、capex などのCF指標も構造化クエリから使えるようにしました
• その後、return_on_assets / return_on_equity も、期末 total assets / equity を使う派生 ratio 指標として追加しました
• source-neutral な metric policy と Gold materialization を通し、EDINET由来の公式開示値だけを本番APIの検索条件に使います

agent は自然文をそのまま検索に流すのではなく、company_query.v1 の financial_metric predicate に変換してから sf query --file company-query.json --json を実行してください。対応していない科目、trend、年度指定などは、0件として扱わず unsupported / gaps として止めます。

財務しきい値を含む検索は、自然文のまま company search に残すと誤読しやすくなります。CLI 0.3.17 では、Codex や Claude Code が生成した company_query.v1 JSON を sf query から実行できるようにしました。

変わったこと

• sf query --file company-query.json --json を追加しました
• sf query --stdin --json で標準入力からも実行できます
• sf company query は誤って会社検索として課金されないよう、usage error として止めます
• sf --help --json に query と credits.summary が出るようになりました

財務条件を決定的に扱う場合は、agent / backend 側で company_query.v1 を作ってから sf query に渡してください。自然文を直接 sf query に渡す使い方ではありません。

CLI 0.3.18 では、Codex / Claude Code が読むJSON contractの細かなズレを直しました。

変わったこと

• company_query.v1 の結果行に top-level company_id を追加しました
• sf credits balance --json と sf credits summary --json に stable object を追加しました
• sf --help から sf batch --help --json に到達できるようにしました
• bundled agent skill と docs の version / auth / update 読み取りキーを実レスポンスに合わせました

sf batch は通常導線ではありません。複数会社の調査は引き続き Search JSON を agent 側でローカルに整形し、必要な会社だけ Company Card / Signals を読んでください。

CLI 0.3.19 では、検索系コマンドの option validation を強化しました。

変わったこと

• sf search --order と sf company search --order の不正値を API 呼び出し前に止めます
• sf job search --order と sf job search --status の不正値も同じく CLI 側で止めます
• --json では既存の structured usage error を返すため、Codex / Claude Code が次の修正コマンドを判断しやすくなります

検索結果そのものの contract は変えていません。agent が option を間違えた場合に、無駄な remote API call をせず、より早く修正できるようにした変更です。

CLI 0.3.21 では、従業員数を含む会社検索の routing を修正しました。

変わったこと

• sf search "従業員1000人以上の会社" --json から min_employees: 1000 を推定します
• 従業員数条件だけで表現できる自然文は、残った q を送らずに検索します
• broad な従業員数検索は company card scan ではなく、source enrichment index から返します

これにより、従業員数データが存在するのに 0 件になる状態を避けます。財務しきい値は引き続き自然文から機械的に確定せず、company_query.v1 の構造化クエリへ route してください。

company_query.v1 の検証を強化しました。agent が作った絞り込み条件に不正な値や広すぎる条件が含まれる場合、Signal Foundry はそれを会社検索として実行せず、unsupported と gaps で止めます。

変わったこと

• industry_33_code は JPX 33 業種の数値コードだけを受け付けます
• prefecture は 東京都、大阪府 のような正式な都道府県名だけを受け付けます
• 東京都の会社 のような地域だけの広すぎる query は broad_query_requires_narrowing で止めます
• docs / schema にも同じ制約を反映し、agent が実行前に気づけるようにしました

unsupported は 0 件ではありません。検索条件を会社名、上場状態、業種、求人、建設業許可、財務条件などで狭めてから、もう一度 sf query --file company-query.json --json を実行してください。

会社リストやテーマ検索の結果を読むときに、どの母集団に対してどれくらいデータが入っているのか、semantic tag をどう扱うのかを確認できる入口を揃えました。

変わったこと

• 公開 docs に「データカバレッジと semantic tag」を追加しました
• sf data catalog --json に company_card_semantic_tags を source index として追加しました
• sf data capabilities --json に coverage / semantic tag contract を追加しました
• sf data * --help から、0 件、低ヒット、semantic tag、sf data health の使い分けを確認できるようにしました
• Codex / Claude Code 向け agent skill に、coverage と semantic tag の読み方を追加しました

読み方

0 件や低ヒットは「該当企業が存在しない証明」ではありません。まず source_coverage、definition.warnings[]、gaps[]、quality_rank を確認します。

semantic tag は会社カードを速く探すための検索補助です。会社の公式属性や法的プロフィールとしては扱いません。

関連 docs

• /docs/getting-started/data-coverage-and-tags
• sf data catalog --json
• sf data capabilities --json

Signal Foundry の会社検索を、事前計算済みの sf_company_cards に接続しました。

主な更新

• 5,779,502社の company card を本番 serving table に昇格
• exact company search と company profile --card を precomputed card から返却
• AI求人、求人、建設許可、都道府県、Webサイト、従業員数などの会社検索を card index から返却
• sf_company_card_refresh_queue と5分ごとの queue drain cron を追加
• sf job search の hot path から exact count を外し、製造業×都道府県の組み合わせで500にならないように修正
• 既存WorkOSユーザーの identity / principal / account 解決を1回のDB RPCにまとめ、会社検索の前段で発生していた同期往復を削減

体験の変化

sf company search "生成AI 求人" --json のような検索は、重い source materialized view ではなく company card index を先に使います。証券コードや jpx_ ID、法人番号、ドメインの exact lookup は従来どおり no-scan path です。

sf company search "生成AI 求人" --json
sf company search jpx_9997 --json
sf company profile jpx_9997 --card --json
sf job search "大阪の製造業求人" --prefecture 大阪府 --manufacturing true --json

API は引き続き read ごとに request credit を消費します。重い全文 evidence retrieval ではなく、最初の会社候補・会社カードを素早く返すことを優先しています。

会社検索と 1 社調査で最初に返す会社カードを、高速な serving row から読めるようにしました。会社名、証券コード、法人番号、domain などの exact lookup は、重い探索を避けて会社カードを返します。

主な更新

• 会社カード用の sf_company_serving_rows_mv を追加
• sf_charge_api_request で request credit の残高確認と消費確定を 1 回の DB RPC に統合
• request credit の通常経路から重複した月次 free grant 確認を外し、usage reservation の集計も 1 回の 24 時間窓スキャンに整理
• OAuth API 呼び出しの account_id + subject_id usage index を追加し、会社カードを返す前の課金・レート制限処理を軽量化
• 証券コード、jpx_ ID、法人番号、cn_ ID、ドメインの exact lookup は、request credit 消費、会社解決、company card 取得を 1 回の DB RPC に統合
• card index に乗る会社検索は、request credit 消費と sf_search_company_cards 実行を 1 回の DB RPC に統合
• 既存WorkOSユーザーの OAuth account 解決を 1 回の DB RPC に統合
• source enrichment refresh 後に serving row refresh を自動スケジュール
• CLI JSON の meta.timings_ms と Server-Timing で、認証・課金・検索のどこが遅いか確認可能
• root / contextual --help に、公開ドキュメントで使う company / filing / data / credits / feedback command を表示
• CLI 0.3.14 として patch release できるように version と pinned install 手順を更新
• public docs の credit 表記を、1 request credit と operation credit に分けて統一

credit 境界

通常の Signal Foundry data endpoint は、API / CLI で読むたびに 1 request credit を使います。deep Signals、bulk、外部取得など重い処理は、request credit とは別の利用量境界を持ちます。

credits、usage、feedback などの管理 endpoint は request credit の対象外です。

会社を調べるときに、その会社がどの顧客にどんなサービス・案件で使われているかを直接見られる API / CLI を追加しました。

主な更新

• GET /api/signal-foundry/companies/{companyId}/cases を追加
• sf company cases <companyId> --json を追加
• 返却内容を case_studies、customer_relations、projects に分けて固定
• API / CLI で Signal Foundry data endpoint を呼ぶ request は 1 request credit として ledger に記録
• request credit は usage.api_request / api.data_request として credit summary に表示
• credits、usage、feedback などの確認・管理 endpoint は request credit の対象外

使い方

sf company cases jpx_6836 --limit 5 --relation-tier all --json

見る key:

• customer_relations[].customer.company_name
• customer_relations[].relation_tier
• case_studies[].page_title
• projects[].project_name
• *.url
• meta.request_credit.credits_used

Billing

この API は既存 evidence を読む data request なので、呼ぶと 1 request credit です。新しい crawl、browser render、外部検索、全文取得で evidence を作る実行は、他の source と同じく別の credit-consuming write として扱います。

request credit の消費は response header x-signal-foundry-request-credits-used と、CLI JSON の meta.request_credit で確認できます。

Windows で sf login --base-url https://signal-foundry.app を実行したときの初回ログイン導線を改善しました。

変わったこと

• Windows では OAuth token の保存先が file store 既定になりました
• 初回ログインで SIGNAL_FOUNDRY_OAUTH_TOKEN_STORE=file を指定する必要がなくなりました
• oauth_email_not_allowed は email_hint / email_domain と復旧コマンドを返します
• sf auth show --json と再ログインの手順を error hint / docs に揃えました

現在の CLI は macOS / Linux / Windows のすべてで file token store を既定にしています。OS keychain は SIGNAL_FOUNDRY_OAUTH_TOKEN_STORE=keychain を明示した場合だけ使います。Windows で login 後の API 呼び出しが oauth_email_not_allowed になる場合は、許可済みメールでログインし直すか、管理者に allowlist 追加を依頼してください。

agent が複数の sf コマンドを並列実行したとき、OAuth token の refresh と保存が同時に走ることがありました。特に macOS Keychain では duplicate item のような保存エラーになる可能性がありました。

変わったこと

• OAuth token refresh を token store key ごとに直列化しました
• 先に別コマンドが refresh 済みの場合、待機後に token を再読込してその token を使います
• macOS Keychain / Linux keychain / Windows file store のどの保存先でも、同じ token store key の refresh 書き込みが同時に走らないようになりました
• macOS Keychain の duplicate item エラーは既存 token を置き換えて復旧します

通常の利用手順は変わりません。sf login --base-url https://signal-foundry.app のあと、agent が sf credits balance --json や sf company search ... --json を並列に実行しても、refresh が必要なときは CLI 側で安全に待ち合わせます。

sf auth show --json の認証状態表示を整理しました。

これまで通常の OAuth login を使っている場合でも、実際には OAuth access token の preview が effectiveApiKeyPreview に出ていました。動作上の問題はありませんでしたが、API key を使っているように見えて紛らわしい状態でした。

変わったこと

• OAuth login の場合は effectiveCredentialType: "oauth_access_token" を返します
• 実際に使われる credential は effectiveCredentialPreview に出します
• effectiveApiKeyPreview は、本当に API key が有効な場合だけ値を返します

OAuth login の通常状態では、次のようになります。

{
  "authMode": "oauth",
  "effectiveCredentialType": "oauth_access_token",
  "effectiveCredentialPreview": "eyJhbG...abcd",
  "effectiveApiKeyPreview": null,
  "oauth": {
    "tokenAvailable": true,
    "tokenStore": "keychain"
  }
}

CLI onboarding の通常導線は引き続き sf login --base-url https://signal-foundry.app です。API key は直接 API や backend job 用の secret store で管理してください。

公開 docs の初回導線を、Signal Foundry を最短で試すためのページに絞りました。agent が読む /llms.txt と、人が読む Getting Started / Quick Start / install 手順も同じ方向に揃えています。

主な更新

• Getting Started に agent-native workflow の図を追加しました
• install-sf-cli を GitHub Release artifact、Homebrew、winget の現行導線に整理しました
• quick-start を初回成功に絞り、余分な分岐を減らしました
• company_id と data provenance の説明を CLI first に寄せました
• draft 化した旧 docs は canonical page へ redirect するようにしました
• Authentication / Billing / API / Claude Code workflow の文言を、公開ユーザー向けに読みやすく整理しました
• docs tree の parent 処理と、未ログイン docs 表示時の useUser query error を修正しました

確認済み

• pnpm run docs:qa:strict
• pnpm typecheck
• pnpm lint:fix
• pnpm format:fix
• git diff --check
• desktop / mobile の rendered screenshot smoke

Features 配下にはまだ重複が残る可能性があります。次の docs cleanup では、機能説明ページと workflow ページの役割をさらに整理します。

WorkOS/AuthKit 移行後に、team workspace の一部画面が Supabase JWT / RLS 前提のまま残っていました。これにより、production の team settings、members、billing で PGRST301 系のエラーが出る可能性がありました。

主な更新

• team settings、members、billing の server reads を、service role + explicit membership / permission check に変更しました
• billing checkout / portal action は、permission、customer、provider config、seat count を明示的に検証するようにしました
• invitation delete / role update / renew / accept を admin client 経由に寄せました
• member remove / role update / ownership transfer を WorkOS session 前提の明示的チェックへ変更しました
• team image upload と roles provider も、client-side Supabase read/write に依存しない形へ寄せました

体験の変化

team workspace は、認証 identity と Supabase RLS の暗黙一致に頼らず、アプリ側で membership と permission を確認してから操作します。WorkOS session でログインしているユーザーでも、settings / members / billing の読み書きが team scope と合うようになりました。

確認済み

• pnpm typecheck
• pnpm lint:fix
• pnpm format:fix
• pnpm run docs:qa
• pnpm --filter @kit/team-accounts typecheck
• git diff --check

残っている確認は、production deploy 後のログイン済み smoke と Vercel error log 確認です。

CLI 0.3.10 では、Signal Foundry を「agent が安全に使える会社データ workspace」として確認するための data health と agent corpus を更新しました。

主な更新

• 内部 release audit を更新し、会社検索、Company Card、Signals、credit 境界を同じ smoke で確認できるようにしました
• sf data health --json を追加し、company、registry、EDINET、observation の主要カバレッジを確認できるようにしました
• bundled signal-foundry-agent skill の prompt corpus と object-first workflow を更新しました
• unsupported / weak / needs_human の tentative result では save action を出さず、agent が空結果を成功扱いしないようにしました
• sf data capabilities --json と Company-first の docs / skill / CLI help を揃えました

確認済み

• CLI 0.3.10 は GitHub Release artifact と SHA256SUMS で公開済みです
• release 時点の https://signal-foundry.app/releases/cli/latest.json は 0.3.10 を返していました。現在の最新版は sf version --json --check-update で確認してください
• production release audit は会社検索 / Signals / credit 境界を含めて passed です
• production sf data health --json は主要 count / coverage metrics を返します

更新方法

macOS / Linux:

brew upgrade sf
sf version --json

Windows:

winget は Nexaflow.SignalFoundry として公開済みです。Microsoft catalog の反映が最新 release より遅れる場合だけ、GitHub Release artifact を使ってください。

winget search --id Nexaflow.SignalFoundry --source winget
winget upgrade --id Nexaflow.SignalFoundry
sf version --json

Bundled skill も更新する場合:

sf agent install --target codex --force
sf agent install --target claude-code --force

Homebrew と winget は convenience channel です。winget は catalog 反映まで遅れることがあります。特定 version を固定する場合や Windows で winget が未公開の場合は、GitHub Release artifact と SHA256SUMS を使ってください。

Canny の fresh-user smoke feedback をもとに、初回利用時に agent が迷いやすい contract を補正しました。

変わったこと

• sf data capabilities --json の coverage / capability 境界を整理
• read 系 JSON に ok / command / status の既定値を補完
• 営業 intent を含む曖昧な条件で、needs_human gate へ戻す
• funding / news 条件を弱い website evidence ではなく unsupported capability gap として返す

Agent への影響

agent は sf data capabilities --json を読めば、対応 capability と次に実行する command を確認できます。buyer / product / pain or signal が曖昧な場合は、先に確認質問を返します。

Signal Foundry の通常利用単位を team workspace に揃えました。1 人で使う場合も、owner だけの team workspace が API key、List、usage、billing、credit grant の account scope になります。

主な更新

• サインアップ画面の copy を team workspace 前提に整理
• 初回 team workspace 作成画面に、1 人利用でも team が account scope になることを明記
• 個人 billing の checkout / portal 実装導線を外し、/home/billing は既存 team billing か team 作成へ誘導
• team billing 画面に課金単位が team であることを表示
• account selector から重複 team 作成につながる導線を外し、通常利用では 1 owner 1 team に寄せる
• create_team_account を retry-safe にし、二重 submit 時は既存 owner team を再利用
• hosted-dev seed と Lightpanda smoke を team workspace routes に合わせて更新

運用上の整理

個人 account は認証 identity と初期設定のために残りますが、契約・credit・receipt・共有 API key の通常スコープにはしません。公開 docs でも、API key は team workspace settings から発行する手順に揃えています。

Lightpanda smoke は、team home、team lists、settings、list detail を対象にしました。Next streaming navigation が安定しない settings subroutes は、build、typecheck、DB test、Playwright E2E 側で補完します。

sf feedback create で長い feedback details を送った時のエラーを改善しました。

主な更新

• details は送信前に 10..5000 文字で検証
• 長すぎる場合は Canny に投稿せず、CLI が usage error として理由を表示
• help に inline / file-based details の文字数境界を明記

体験の変化

これまでは、details が長すぎると production API から generic な 400 が返り、agent が原因を判断しづらい状態でした。

今後は、raw transcript をそのまま送らず、再現手順・期待値・実際の結果・影響だけに要約するよう CLI が明確に促します。

sf feedback create "company search issue" \
  --kind bug \
  --surface company.search \
  --details-file ./feedback-summary.md \
  --json

sf job business-understanding --execute --json が返す計画情報を、次の agent セッションで参照しやすくしました。

UI は job を実行しません。どの確認が残っているか、どの次コマンドに進めるかを agent が判断しやすくします。

主な更新

• open gaps、runnable / blocked command 数を整理
• status、scenario、query、coverage status、credit risk、次アクションを返却
• 次に進める command を読み取り専用の command block として表示
• blocked command の requires、blocks、next step を返却
• E2E smoke で API key 作成、CLI 実行、計画情報の返却を確認

体験の変化

これまでは agent が business understanding を実行しても、次に何を確認すべきかを読み取りづらい状態でした。

今後は JSON contract として揃うため、別の Codex / Claude Code セッションでも、どの gap が残っているか、どのコマンドは実行してよいかを見て再開できます。

sf job business-understanding "兵庫県の建設業向けに生成AI研修を売りたい" \
  --buyer 情シス \
  --product 生成AI研修 \
  --pain 業務効率化 \
  --execute \
  --json

• public contact form に honeypot を追加
• contact form の HTML email で user input を escape
• API key request の heavy company search に tighter guardrail を追加
• company search response に scan limit diagnostics を追加

MCP server の kit_env_raw_read / kit_env_raw_write は、2026年4月23日から既定で公開しない形に変更しました。

変更点

• kit_env_raw_read
• kit_env_raw_write

は常時登録されず、MCP server 起動前に KIT_MCP_ENABLE_UNSAFE_ENV_TOOLS=true を明示したときだけ登録されます。

また、kit_env_read も secret 値は redaction されます。

影響

• 既存の MCP client や prompt が raw env tools の常時存在を前提にしている場合、そのままでは動きません
• 通常運用では opt-in せずに起動するのが正しい使い方です

対応

• local の完全信頼環境だけで raw env tools を使う
• 既存 prompt は KIT_MCP_ENABLE_UNSAFE_ENV_TOOLS=true 前提かどうかを明示する
• secret の確認だけが目的なら kit_env_read の redacted 表示を使う

公開ドキュメントを全面更新しました。これまで残っていた旧サンプル文面を削除し、現在の Signal Foundry に合わせて内容を組み直しています。

変更した内容

• getting-started を CLI / API キー前提に更新
• authentication を API キー運用中心に更新
• database を company-centric data model 前提に更新
• features を companies / profile / observations / filings / compare 中心に更新
• billing を current status ベースの説明へ更新

あわせて更新したもの

• apps/web/README.md
• 公開 blog 記事
• 公開 changelog 記事

ドキュメントの入口は、引き続き /docs です。

API の主要導線を整理し、companies -> profile -> observations -> filings -> compare で読める形に寄せました。

追加・整理した endpoint

• GET /api/signal-foundry/companies
• GET /api/signal-foundry/companies/{companyId}/profile
• GET /api/signal-foundry/companies/{companyId}/observations
• GET /api/signal-foundry/companies/{companyId}/filings
• GET /api/signal-foundry/companies/{companyId}/filings/{filingId}
• GET /api/signal-foundry/companies/{companyId}/filings/{filingId}/compare

compare でできること

• 直前 comparable filing の自動解決
• summary metrics の比較
• section diff の比較

compare は useful な機能ですが、product core は引き続き point-first です。まず profile と observations を厚くし、その上で compare を使う前提は変えていません。

CLI の初期設定を短縮しました。これにより、base URL と OAuth login を 1 コマンドで始められます。

初期化コマンド

sf login --base-url https://signal-foundry.app

あわせて改善した点

• sf ... --json を agent 向けの正本に統一
• quickstart を OAuth login 前提に整理
• 空の config path を安全に扱うよう hardening

これにより、Claude Code / Codex での最短導線は次の 3 手になりました。

1. login
2. company search
3. company profile

workspace settings 配下から Signal Foundry API キーを管理できるようにしました。

できること

• API キー作成
• ワンタイム表示
• revoke
• rotate

入口

• /home/{accountId}/settings/api-keys

workspace 単位で Signal Foundry API を運用できます。

本番ドメインのアクセス方針を整理しました。https://signal-foundry.app では、API キーなしの internal access を前提にしない運用へ移行しています。

変更点

• production で SIGNAL_FOUNDRY_INTERNAL_API_ENABLED=false
• no-key request は 404
• API キー付き request は production でも通るよう route guard を修正

あわせて入ったもの

• 基本 rate limit
• invalid / revoked / rotated / expired API key の明示的な拒否
• meta.auth_mode = api_key

これにより、本番利用の前提がより明確になりました。agent や CLI は API キー前提で接続してください。

チーム向け API キー画面に usage summary を追加しました。これにより、キーを配るだけでなく、どう使われているかも同じ画面で追えます。

表示するもの

• request count
• endpoint count
• response bytes
• last request at
• endpoint breakdown

権限

チームアカウントでの閲覧・操作には settings.manage が必要です。

現時点では billing period 概念までは入れておらず、直近 30 日の運用確認に焦点を当てています。