signal-research

シグナル調査 — 静的なアカウントベースを、日付と証拠を伴う最新のシグナルリストに変える

企業属性ベースから、どの企業が適合するかは分かります。しかし、いつ連絡すべきかは分かりません。このスキルはそのギャップを埋めます。すでにあるベースを使い、アカウントごとに「今、有効なトリガーがあるか。証拠は何か。どれくらい古いか」に答えます。

2つの実行モードがあります。

• フル実行 — ベースのシグナル調査をまだ一度も行っていない場合。
• 差分実行 — 以前に調査したベースについて、期限切れのシグナルと新たに発生したシグナルを再スキャンする場合。ほとんどのベースは約45日で劣化しますが、ステータス列が「Hot」のままなので誰も気づきません。

セットアップ（セッションごとに1回）

インストールディレクトリは動的に解決してください。ハードコードしてはいけません。

1. **/signal-research/SKILL.md を Glob で検索します。
2. 該当するディレクトリを SKILL_BASE とし、リソースは {SKILL_BASE}/resources/... にあります。

次の順に読み込みます。

1. ワークスペースにある場合は、clients/<client>/icp.md と clients/<client>/signals.md を読み込みます。クライアント独自のシグナルティア、検出ルート、地域別ソース表、オープンデータの落とし穴は、このスキルにある一般的な内容よりも常に優先されます。
2. {SKILL_BASE}/resources/signals-catalog.md — シグナルライブラリです。アカウントイベントとニュース、採用、技術の変化、個人レベルの活動、プロジェクトの進行と構築意図に加え、業界別パックとデータポイント系列（汎用の D、業界別の DV／DA）にわたる60件のカタログ登録済みエントリーが含まれています。それぞれに検出ルート、鮮度ウィンドウ、組み合わせに関する注記があります。クライアントにまだ signals.md がない場合に使用し、インラインでシグナルを新たに考案するのではなく、カタログを拡張してください。
3. 任意（インストール済みの場合）： gtm-skills リポジトリの agency-signal-sourcer には、クレジットコスト、減衰期間、ヒートティアの SLA を含む、シグナルごとの詳細なツール表があります。これがなくても、このスキル独自の resources/ にある検出ラダーとカタログで十分に実行できます。

どれも存在しない場合は、そこで停止してその旨を伝えてください。ここでシグナルリストを考案してはいけません。

厳守事項

1. 証拠がなければ、シグナルではありません。 空でないすべての signal_type には、有効な URL と日付を付けます。リンクを付けられないシグナルは、理由とともに none と記載します。もっともらしい推測は、ベースを損なう最短の道です。
2. 実行日ではなく、検出対象の日付を記録します。 signal_date はイベントが発生した日付（掲載日、許可の発行日、受賞日）です。signal_age_days は実行日 − signal_date です。ソースに「3週間前に掲載」としかない場合は、導き出した日付を記録し、signal_date_precision = approx に設定します。
3. 最も安価なソースから使います。 resources/detection-ladder.md にある順番に進めます。無料の一括クエリですでに答えが得られたアカウントに、有料クレジットを使ってはいけません。
4. 調査前に除外フィルターを適用します。 まずアンチICPと地域・規模のゲートを実行し、通過したアカウントだけを調査します。対象外を調査することが、この作業のコストが本来の3倍になる最も一般的な原因です。
5. シグナルは企業ごとに1行とし、コンタクトは分けます。 シグナル調査はアカウント単位です。コンタクトの拡充（企業ごとに2～3人）は、その後、リスト作成の段階で行います。
6. 期限切れは、未検出と同じではありません。 ウィンドウを過ぎたシグナルはデータポイントに格下げします（引き続き、伝える内容の参考になります）。また、そのアカウントは再スキャンの対象にします。黙って削除してはいけません。
7. 機密保持。 あるクライアントのアカウント名、証拠、リストを別のクライアントの成果物に持ち込んではいけません。

フェーズ 0 — 受付とベースデータの正規化

不足している情報だけを尋ねます。

• ベースデータへのパス／リンクと、そのベースデータが属するクライアント。
• 実行モード：フルまたは差分（ベースデータにすでに signal_date の値がある場合は、差分を提案します）。
• 地理的な対象範囲と、バッチ上限（「Tier A のみ／NY／最初の 200 件」など）。

次に、数式ではなく値を書き込んで正規化します。

• row_id、company_name_raw、company_name_clean、domain、country、geo_bucket、city、 industry — 会社情報の標準ブロック。
• ドメインで重複を排除します。ドメインがない場合は、正規化した社名と都市で重複を排除し、match_method を記録します。
• filter_geo／filter_size／filter_anti_icp を適用して filter_result を設定し、除外した各行の exclusion_reason を入力します。対象件数の推移を報告します：生データ → 重複排除後 → 対象範囲内。

シグナル検出を始める前に、残った件数を報告し、その件数から実際に費用が発生すると判断される場合は、実行の承認を得ます。

フェーズ 1 — シグナル計画（コストを左右する工程）

シグナルを4～7 個選びます。それ以上は選びません。計画表にそれぞれ 1 行ずつ記入します。

シグナル	ティア	ソース／取得方法	100 件あたりのコスト	対象期間（日）	予想ヒット率

選定ルール：

• 一括検出可能なシグナルを少なくとも 2 つ含めます。1 つのクエリでベースデータ全体をカバーできるもの（オープンデータ API、入札情報フィード、ニュースフィード、求人情報のプラットフォームフィルターなど）を選びます。これらが実行の中核となります。
• アカウントごとに手作業で確認するシグナルは、最大 2 つまでにします（採用ページ、サイトのニュースなど）。これらはコストの高い追加確認です。
• この ICP との適合度が低いシグナルは、たとえ有名なものでも除外します。請負／サービス業では資金調達ラウンドが発生する企業はほとんどありませんが、採用はどの企業でも発生します。
• 現実的な検出方法がないシグナルは計画に含めません。代わりに、レポートの「検出不能だが希望するシグナル」に記載します。

実行前に、計画と予想コストを提示します。

フェーズ 2 — 3 回に分けた検出

詳細な手順、結合ルール、ソースタイプに関する注意点については、{SKILL_BASE}/resources/detection-ladder.md を参照してください。

パス A — 一括ソース（ベースデータ全体を対象）。 ソースごとに 1 回クエリを実行し、社名／ドメインでベースデータと結合します。match_method（domain、exact_name、fuzzy_name+city、manual）を記録します。ベースデータにある社名を使ったあいまい一致は、誤検出の主な原因です。10 件を抜き取り確認します。

パス B — アカウントごとのウェブ調査。 パス A でヒットがなく、対象範囲内のアカウントのみを調査します。並列の調査エージェントごとに 10～15 件のアカウントを割り当てます。各エージェントの回答形式は厳密に指定します：会社名、シグナルの種類、1 行の根拠、URL、日付、または明示的な none。none は正しく、想定される回答であるとエージェントに指示します。そうしないと、すべての行にシグナルがあると捏造してしまいます。

パス C — プラットフォームのフィルター。 残った対象に対して Apollo／LinkedIn／Sales Nav／インテント関連ツールを使います。ただし、アカウントが適合性ゲートを通過している場合に限ります。GDPR のもとでは人物レベルの追跡は米国のみが対象です。EU のターゲットには企業レベルの特定を使用してください。

各パスの後に、調査したアカウント数、ヒット数、コストを記録します。この規模のベースデータでヒット率が約 5％未満のパスは、その結果をそのまま報告し、対象を拡大してひそかに繰り返すことはしません。

フェーズ 2b — 同じパスで収集するデータポイント

シグナルは対象の 3～5％で発生します。データポイントは対象のほぼすべてについて取得できます。両方を同時に実行してください。そうしなければ採算が合いません。パス B ではすでにアカウントのページを取得しているため、事実を集めるために後からもう一度クロールすると、同じバイトに二重で費用を払うことになります。

この 2 つは別物なので、同じ列に入れてはいけません。

	シグナル	データポイント
内容	日付のあるイベント	継続的に有効な事実
決めること	いつ 書くか	何を 伝えるか
カバー範囲	対象の 3～5％	対象の大半
有効期限	期間があり、その後は失効する	失効しない — それが要点です
必要なもの	URL と 日付	ソースページ。日付は不要

記録する価値のある種類を、メッセージへの影響が大きい順におおよそ並べると、アカウントが社内で担う能力 · アカウントが挙げている設備やツール · ソフトウェアスタック · 規模（量、サイズ、件数） · 取引先や対応業種の実名です。対応業種の構成は最も弱い情報です。どのサイトにも掲載されており、メッセージの調整にはほとんど役立ちません。

ノイズを減らす抽出ルール。 実際の運用でコストをかけて得た知見です。

• 数字のそばに実務を表す語がある場合に限り、量として扱います。 数字の前後約 70 文字以内に、業界固有の動詞または名詞があることを必須にしてください。そうしないと、クロール結果に「西へ 20 マイル」がプロジェクトの処理量として誇らしげに返されます。
• 文ではなく、一致箇所の前後約 150 文字を取得します。 文単位で分割すると、ナビゲーションメニューや Cookie バナーが引用文に混入します。
• マーケティング上の約束は、課題ではありません。 短納期を宣伝するページは、自社についての主張であり、納期に苦労している証拠ではありません。この方法で「スケジュールに関する不満」を検出することはできません。ノイズとして記録するのではなく、除外してください。
• 日付がなくても、データポイントにはソース URL が必要です。 URL がないと、送信前に冒頭の一文を確認できず、hook_source が空のままになり、その行がブロックされます。

キュー D — 有効なシグナルがないアカウント — は、この収集結果だけに依存します。データポイントの取得を省略すると、キュー D には書き出しの糸口がなくなり、キャンペーンは気づかないうちに一斉メール配信になってしまいます。

フェーズ 3 — スコアリングと温度別の分類

clients/<client>/signals.md にあるクライアント独自の計算式を使用します。記載がない場合は、次をデフォルトとして使用します。

score = fit (High 60 / Med 35 / Low 10)
      + signal_tier (T1 40 / T2 25 / T3 10)
      + capability gap (+10 gap present or unknown / −10 they already do it in-house)

• シグナルの積み上げ： 独立した 2 つ目のシグナルは +10、3 つ目は +5 とします。同じ温度区分をもう 1 つ加算してはいけません。同じイベントに関する 2 つの事実（求人情報と、その求人に関するプレスリリース）は、シグナル 1 つとして扱います。
• 鮮度の乗数： 有効期間の半分以内は ×1.0、後半は ×0.7、期間経過後は ×0.3 です。
• クライアントのしきい値に従って、温度区分を Hot／Warm／Cool／Drop に分類し、区分ごとに SLA を設定します（Hot は 48 時間以内に接触。そうしなければ調査が無駄になります）。

フェーズ 4 — 鮮度と再スキャンキュー

スコアリングした各アカウントについて、signal_expires_on = signal_date + window と rescan_due = min(expires_on, run_date + 30d) を設定します。

差分実行：

1. 前回の出力を読み込み、signal_expires_on と今日の日付を比較します。
2. 期限切れ → シグナルの詳細を datapoint_type / datapoint_detail に移し、シグナルのブロックをクリアして、status = burnt に設定します。
3. 失効済みアカウントと、シグナルが一度も検出されていないアカウントに限り、フェーズ 2 を再実行します。
4. 変更テーブルを出力します。内容は、新たに発生したシグナル、失効、再発、引き続きシグナルなしです。このテーブルが差分実行の実際の納品物であり、ファイル全体を再出力するのではありません。

フェーズ 5 — 出力

成果物は 2 つで、常に両方を作成します。

1. エンリッチ済みリスト（CSV、フラット形式、ヘッダー 1 行、値は数式ではなく値）。 すべての入力列を保持し、標準シグナルブロックを追加します：signal_type · signal_score · signal_route · signal_evidence_url · signal_date · signal_age_days · signal_summary · signal_2_type · signal_2_url · signal_3_type に加えて、 datapoint_type · datapoint_detail、およびこのスキル独自の signal_expires_on · rescan_due · signal_date_precision · match_method · detected_by · detected_on。完全な仕様と値の語彙については、{SKILL_BASE}/resources/output-spec.md を参照してください。理由を付けて除外行も含めたベース全体と、作業対象の絞り込み版を、列構成が同一の 2 つのファイルとして納品します。

2. カバレッジレポート。 構成と文言は {SKILL_BASE}/resources/report-template.md に従います。レポートには、ソース別の取得数とコストのランキング、何も得られなかったシグナルとその継続／停止の判断、検出できなかったものとその理由、再スキャン日を記載します。「有望なアカウントが 37 件見つかった」とだけ報告する実行結果では、手法を再現できるかどうかが分かりません。

ワークスペースでクライアントの成果を Notion に保存する場合も、リストは CSV のままにし、レポートは読みやすいページにします。データベースのダンプにカンバンへのリンクを付けただけでは、レポートとはいえません。

引き継ぎ

次の質問	スキル
どのシグナル × ICP × オファーをテストすべきか	hypo-generator (gtm-skills) / hypothesis-builder
シグナル X を検出するツールは何か、コストはいくらか、いつ減衰するか	agency-signal-sourcer
ベースが小さすぎる／アカウントをもっと見つけるには	niche-data-finder、data-research、account-sourcing
スコアリング済みアカウントを、連絡先とコピー欄を含む完全な見込み客リストにする	prospect-list-run
これらのシグナルを基にシーケンスを書く	sequence-writer
アカウントごとの接触前ブリーフィング	prospect-profiler

すでに経験した検出上の落とし穴

• 採用ページにあるチームメンバーのメール署名が、募集中の求人として検出されます。
• 「現在、求人募集はありません」という記載は、空ページのフィルターをすり抜け、明示的な募集なしではなく、結果がなかったページとして記録されます。
• 現在も公開されているページに古い求人情報が載っていると、新しい情報に見えます。ページではなく、求人情報の日付を確認してください。
• アグリゲーターには、募集終了後も数か月にわたって求人情報のコピーが残ります。アグリゲーターにしか存在しない求人情報は、期限切れとして扱います。
• 採用ページが求人一覧とは限りません。多くの企業は外部の求人サイトへ誘導しています。リンク先を確認しないと、実際には求人が 5 件ある企業を「求人なし」と記録することになります。
• /partners や /white-label のページは、通常、ニーズがあることではなく、その逆を意味します。つまり、そのサービスを販売しているということです。スコアリングする前に、文言がどちらの方向を示しているかを読み取ってください。ある実行では、この種のページが見つかった企業はすべて見込み客ではなく競合他社でした。
• 反シグナルは専用ファイルに保存し、すでに失格となったものも含めてすべてのアカウントを対象に確認する必要があります。失格になっていない行しか読み込まない実行では、フィルターで除外された競合他社を再確認できず、除外フィルターが機能しなくなり、競合他社がベースに戻ってしまいます。
• 一般検索を通じたニュース検索は、従業員数 10～500 人の企業には効果がありません。候補 168 件を対象としたある実行では、安全賞、受賞歴ページ、契約登録簿、ソーシャル投稿が返され、正確だったのは 3 分の 1 未満でした。専用フィードとポータルを使ってください。

実際の実行で確認された失敗パターン

• 購入できない企業のシグナル。 適合性の判定は検出の後ではなく、前に実施する必要があります。
• ある地域全体が気付かれないまま未調査。 オープンデータのカバレッジは全国単位ではなく都市単位です。geo_bucket ごとにカバレッジを報告してください。空のバケットは空欄ではなく、調査結果です。
• 誤解を招く日付フィールド。 公開データセットには、形式が混在したテキストの日付、プレースホルダー年（9999、3030）、更新されない鮮度メタデータが含まれることがあります。max() や降順ソートを信用する前に、文字どおりの新しい値でフィルタリングし、最新の行を確認してください。
• ベースが古くなっても、誰も再スキャンしない。 差分実行が予定されていなければ、2 か月も経たずにスコア列は実態を反映しなくなります。rescan_due を設定し、レポートでも明記してください。