posthog-customer-deep-dive

PostHog の顧客を深掘りする

アカウントを調査し、メール（初回連絡、フォローアップ、返信）、ノートブック用プロンプトを含む通話準備ブリーフ、またはその他の依頼であれば、調査内容に沿った必要な形式の成果物を作成します。出力先はチャットです。顧客システムとアカウントシステムは読み取り専用です。Vitally や PostHog には送信、投稿、書き込みを行わないでください。ローカルへの書き込みは、セットアップ中の config.md と、実行ごとのスクラッチパッド（セッションのスクラッチパッド内の deep-dive-<account>-<HHMM>、または /tmp）に限ります。ここにはドキュメントキャッシュ、コンテキストファイル、情報収集担当者のダイジェストを保存します。成果物はチャットに一度だけ生成し、ファイルには決して書き込みません。

入力：$ARGUMENTS。通常はメールアドレスですが、ドメイン、アカウント名、または Vitally アカウント ID（いずれかの UUID 形式）も指定できます。

記述する前に、すべての主張を検証してください。 数値はすべて、この実行中に実行したクエリから取得します。製品に関する事実やリンクはすべて、この実行中に行ったドキュメント検索から取得します。算出した数値は、計算式をその場に記載してください（1.72M polls/day / 2,880 per instance = ~600 instances）。そうすれば、誤った数字があれば見つけられます。記憶に頼ることも、取得していない数値から推測することも禁止です。検証できない主張は、代わりに質問として記載してください。回答のない質問はフォローアップで済みますが、自信満々の誤情報は関係を損ないます。このスキル内の表は、確認すべき内容を示すものであり、引用元ではありません。

顧客のコードまたは SDK 設定に関する主張には、サイトスキャンで取得したページまたはバンドルのコードを引用してください。 データから分かるのは影響であり、原因を示すのはコードだけです。そのため、イベントデータと請求データだけを根拠に、ID の仕組みや課金の仕組みを断定してはいけません。SDK が発行するイベント（$identify、$create_alias、明示的な $set イベント）については、それらのイベントを根拠に主張できます。初期化オプションや設定値については、コードの引用が必要です。

まず config.md を読み、ユーザーごとの値とツールの紐付けをすべて確認してください。次に config.local.md があれば読み、そこに記載されたキーを優先してください。このファイルにはこのマシン固有の設定値が保存され、Git で無視されるため、多くの環境で存在しないのが通常です。オーバーレイ適用後も必須の値が <SET THIS> のままであれば、それを必要とする手順の前に確認を求めるか、セットアップを実行してください。ソースが none に設定されている場合は、何も言わずにスキップします。これは設定によるものであり、スキップではありません。任意のソースがすべて none でも、実行は完了です。

参照先	読むタイミング
config.md、続いて存在する場合は config.local.md	Step 1 の前、毎回
references/agent-briefs.md	Round 1a の前に、まず読みます。 ここには main 自身の読み取りマップの行があり、main がほかに開くファイルを決めるほか、規約ブロック、役割ごとのマップ、コンテキストファイルの仕様、返却ルールも記載されています
references/data-rules.md	Steps 1 と 2 で、main が main のマップの行に記載されたセクションのみ読むこと。情報収集担当者は開きません。規約はインラインで渡されます
references/queries-account.md	Steps 1 と 2 で、main（Round 1 の slug）と、担当する情報収集担当者が読む
references/queries-products.md、references/queries-money.md	Step 2 で、マップの行にそのセクションが記載された情報収集担当者が読む。各ファイルの見出しが索引です
references/site-scan.md	Round 1a では、ドメインを対象とするバッチ 1 と、追加チームごとのバッチ 2（公開プロバイダーの管理者メールの場合は Round 2）で読む
references/levers.md	推奨事項の作成前、およびページを選ぶ docs-prewarm が読む
references/voice.md	顧客向けの内容を作成する前に読む
references/mode-email.md、references/mode-call-prep.md	Step 5 で、検出された成果物に対応するファイルを 1 つ読む。それ以外の依頼では同じ調査を行い、依頼に応じた形式で作成する

main による参照ファイルの読み込みは、1 つのブロックにまとめてください。data-rules.md 全体を開くのは、クリティカルパス内で最も大きな読み込みです。その大部分は情報収集担当者向けであり、担当者にはインラインで渡されます。 同梱されているスクリプトは3つです。そのうち2つは最低限の範囲を示すものであり、上限ではありません。実行した後も、アカウントがスクリプトの範囲外を指している場合は調査を続け、スクリプト以外に実行した内容を明記してください。スクリプトが停止したところで調査を終えるのは、顧客ではなくスクリプトの質問に答えたことになります。

• scripts/phq.py は、4つの接続先（us はプロジェクト2、eu はEUプロジェクト1、ch-us／ch-eu は直接のClickHouse接続）で、HTTP API経由の任意のHogQLクエリを送信します。--batch <file.jsonl> を指定すると、1行につき1つのJSONオブジェクトで複数のクエリを一括送信します。キーは name、target、sql と、任意の connection です。それ以外のキー構成の場合、最初のクエリを実行する前に KeyError が発生します。MCPを主な手段とし、ゲートウェイがダウンしている場合、およびEU向けの唯一の経路として、このスクリプトをフォールバックに使います。
• scripts/site-scan.sh <domain> は、一般的なサイトスキャンを実行します。
• scripts/version-check.sh は引数を取りません。3つ目のスクリプトです。config.md を読み込むときに一度実行し、何か出力された場合はそのまま伝えてください。このスクリプトは、このコピーの .claude-plugin/plugin.json のバージョンを公開版と比較し、確認は1日1回まで行います。最新版である場合、オフラインの場合、または main より先行している場合は何も出力しません。何も出力されないのが通常の結果なので、その場合は言及する必要はありません。

Vitally RESTを含む、それ以外のすべてのHTTP呼び出しでは、シングルクォートのヒアドキュメント（python3 << 'PYEOF'）内でPythonを使ってJSONを組み立て、ファイルに書き込み、curl --data @file で送信してください。Bashはインライン文字列内の $1 や $group_0 を展開します。このスキルには $ で始まる名前が多数あります。Pythonの urllib は CERTIFICATE_VERIFY_FAILED になるため、送信にはcurlを使い、PythonはJSONの組み立てと解析のみに使ってください。

セットアップ（初回、または設定が自分のものではない場合）

質問する前に確認し、書き込む前に承認を得てください。一度の手順で、PostHog execゲートウェイとVitally MCPがツール一覧にあるか確認し、環境変数に POSTHOG_PERSONAL_API_KEY、POSTHOG_PERSONAL_API_KEY_EU、VITALLY_API_KEY があるか確認します。また、config.md に記載されている各オプションカテゴリのツールがツール一覧にあるか確認し、正確なツール名を記録します。タイムゾーンも検出してください。見つかった項目、不足している項目、維持するデフォルト値を1つのメッセージで示し、確認できない項目（カレンダーID、予約リンク）だけを尋ねてください。その後、個人情報（仕事用カレンダーID、タイムゾーン、会議メモのフォルダー）は config.local.md に書き込み、存在しない場合は作成してください。それ以外はすべて config.md に書き込みます。個人のパスや住所を config.md に書き込んではいけません。このファイルは共有ファイルであり、そのまま配布されます。オプションのツールが不足している場合は none、必須ツールが不足している場合は実行を中止します。

何かが不足している場合は、原因の説明だけでなく、修正方法を渡してください。 README.md にはインストール手順一式が記載されています。ツールごとに番号付きのセクションがあり、それぞれの末尾には動作を確認する手順があります。実行時には読み込まれないため、不足しているものに該当するセクションを読み、そこに記載されているコマンドをインラインで伝えてください。シェルとキーのセットアップ（セクション0）、MCPの登録、共有認証情報の取得に使う op item get コマンド、または個人用認証情報の発行URLを伝えます。どの認証情報が共有で、どれが本人用かも明示してください。他人のPostHog個人用キーを再利用するのが、よくある間違いです。その後、もう一度確認し、実行前に承認を得てください。初回の実行が「Vitally MCPがありません」というメッセージだけで終わるのは、共有スキルを試そうとした人を遠ざけてしまいます。

ステップ 1. Vitally アカウントを特定する

入力	方法
メールアドレス	mcp__vitally__get_user_details。accounts[0].id と accounts[0].externalId（PostHog org id）を取得します
ドメイン	sibling-sweep のクエリを使用します。MCP の search_users は limit を無視して数百 KB を返すため、避けてください
アカウント名	billing_customer WHERE name ILIKE '%...%'。セルフサービス登録では会社名が重複するため、crm_segments / plans_map が null でない行を優先します。Vitally の名前検索ツールは信頼性が低いです（search_accounts_advanced は完全一致で 0 件を返し、search_accounts は showAllAccounts を無視し、find_account_by_name は呼び出し元の CSM の担当アカウントに絞られます）
アカウント ID	そのまま使用します

すべて失敗した場合は、アカウント名を尋ねてください。渡された ID はどちらの UUID 形式でもあり得ます。Vitally MCP は両方を解決しますが、データウェアハウスでは vitally.accounts.external_id の org id のみ照合されます。

顧客名はシステムごとに異なることがあるため、渡された名前が何を指しているか確認してください。 Vitally のアカウント名、stripe.name（多くの場合、法人名）、zendesk.name、sfdc.Website、resolve-teams にあるプロジェクトごとの名前は、それぞれ独立した 5 つのフィールドで、ときに食い違います。渡された名前が、アカウントではなく、ほとんど利用されていない別のプロジェクトを指している場合もあります。名前が異なる場合は、ヘッダーに各名前が何に対応するかを明記し、利用量の多いプロジェクトについて報告してください。

get_user_details には 2 つの制限があります。大規模アカウントではフィルタリングされることがあり（カスタム属性が削除され、「Removed N trait fields」と表示されます。小規模アカウントでは完全なデータが返る場合もありますが、いずれの場合もデータウェアハウスの属性読み取りを正としてください）、数百人のユーザーがいるアカウントでは上限を超えることがあります。カスタム属性には vitally.custom. のプレフィックスが付いています。

取得元	フィールド
データウェアハウスの vitally.accounts.traits（WHERE id = '<VITALLY_ACCOUNT_ID>'）。get_user_details ではフィルタリングされる項目	onboardingPipeline、onboardingMinimumEligibility、onboardingUsageOutreachSentDate、onboarding_invoice_count、usEuInstance、csmId、accountExecutiveId
get_user_details	healthScore、nextRenewalDate、contractRenewalDate、usersCount、usage_mrr、forecasted_mrr、forecasted_usage_mrr、diff_dollars、paidProducts + payingFor<Product> + <product>_forecasted_mrr、replayCountLast30DaysIfSendingData、group_types_total、active_hog_destinations、active_batch_exports、firstSeenTimestamp、roleAtOrganization

ドメインの兄弟組織検索は、必ず両方のクエリを実行してください。 兄弟組織は、二重に支払いが発生している重複組織、統合の検討対象、またはチームメイトが担当するアカウントである可能性があります。2 つのクエリは異なる母集団（vitally.users と billing_customer）を対象としており、片方だけでは全体を把握できません。片方を省略すると、二重請求の兄弟組織が見つからないままになります。兄弟組織があればヘッダーに記載してください。通常、複数のプロジェクトを持つ 1 つの組織のほうが、並行する複数の組織より望ましい状態です。

次に、検索で返されたすべての組織の使用状況を調べ、利用量の多い組織を中心に情報を整理してください。 get_user_details は Vitally が最初に一覧表示するアカウントである accounts[0] を返します。複数の組織を持つ顧客では、実際に利用中の組織とは別の組織が返されることがよくあります。そのため、以降の数値がすべて稼働していない組織のものになりかねません。これは Round 2 の開始条件です。解決するまでは、情報収集を始めないでください。 誤った org id を渡された情報収集ツールは、別の会社について正確な作業をしてしまうためです。

SELECT organization_id, count() AS days, sum(event_count_in_period) AS events,
       sum(recording_count_in_period) AS recordings, sum(mobile_recording_count_in_period) AS mobile_recordings,
       sum(billable_feature_flag_requests_count_in_period) AS flag_requests
FROM billing_usage_by_org_date
WHERE organization_id IN (<every org id the sweep returned>) AND date >= today() - 30
GROUP BY organization_id ORDER BY events DESC LIMIT 20

結果に含まれない組織は、その期間に Cloud の使用状況がないということであり、それ自体が答えです。特定された組織と実際に稼働している組織が異なる場合は、ヘッダーに明記し、稼働中の組織について報告してください。特定された組織は兄弟組織として扱ってください。稼働していない組織の有料サブスクリプションは、対価のない支出を意味します。

ステップ 2. 並列取得

PostHog MCP をプロジェクト 2に設定します（アクティブ環境ブロックを確認し、そうでなければ switch-project で 2 に切り替えます）。デフォルトでは、すべてのクエリが 0 行を返す開発プロジェクトになっていることがよくあります。

vitally.custom.usEuInstance（["US"] などの配列）からリージョンを判定します。この値は cloudRegion よりも広く設定されています。なければ cloudRegion、次に traits.site_url を参照し、eu.posthog.com なら EU と判断します。ほぼすべての項目は両リージョンともプロジェクト 2 で取得できます。例外は、EU の実験定義と EU の直接接続で、どちらも EU キーと EU のプロジェクト 1 を使います。

並列化の方法

情報収集を並列化し、1 つのエージェントで突き合わせてから、検証を別途並列化します。 2 つの並列処理は置き換えられません。情報収集は主張が出る前に行い、検証はその後に行います。

1 ラウンドのコストは、最も時間のかかるエージェントのコストで決まります。また、エージェントのコストは依存関係のある呼び出しの最長チェーンによって決まります。そのため、まずバッチ化します（コンテキストのみに依存するすべての読み取りを 1 ブロックで実行し、HTTP 経由では 1 回の phq.py --batch にまとめます）。次に範囲を広げます（data-rules.md に従い、チームごとではなく、組織とリージョンごとにグループ化したクエリを 1 つ実行します）。最後に、真の依存関係がある箇所だけを分割します。1 つの指示に含まれる逐次チェーンは 8～10 回の読み取りを超えないようにします。呼び出し回数ではなく、チェーンを数えてください。

• 予算は秒数ではなく、ツール呼び出し回数で設定します。各情報収集エージェントは 12～15 回までとし、リストが 15 回を超える場合は、起動前に指示を分割します。 エージェントの所要秒数は誰にも見積もれませんが、指示内の読み取り回数なら誰でも数えられます。
• 予算が制約するのは構成であり、範囲ではありません。 予算に合わせるために読み取りを削除、延期、縮小してはいけません。指示が大きすぎる場合は分割します。それでも収まらない読み取りは予算超過で実行し、最後の注記に明記します。
• 呼び出し回数で分割し、トピックを理由に指示を統合しないでください。 並列エージェントは実時間コストがほぼかかりませんが、1 つのエージェント内の呼び出しは 1 本のチェーンとして順次実行されます。統合すると、安価なリソースを高価なリソースと交換することになるため、エージェント数を減らそうとするのは逆効果です。
• 各エージェントで 4 件をまとめて実行し、同時に 8～10 エージェントを稼働させます。 これを超えると、ClickHouse は 202 を返し、HTTP 経由では 429 が返ります。強制的な逐次再試行は、分割しない場合より遅くなります。上限はマシン全体に適用されるため、拒否された指示を実行せずに済ませるのではなく、時折拒否されることを想定して再試行してください。実際に制限されるのはエージェント数ではなく、同時実行中のクエリ数です。エージェント 8 つがそれぞれ 4 件をまとめて実行すると、すでに約 32 件が同時実行されるため、エージェント数が少なく見えるのです。短くクエリ数の少ない役割をまとめたウェーブなら、負荷の高いウェーブより多く並列実行できます。
• 呼び出しが約 12 回を下回ると、分割の効果は薄れます。エージェントには、割り当てられた作業量に関係なく一定の起動コストがかかるためです。12～15 回になるまで分割し、その後は分割を止めます。
• 既定ではウェーブは 1 つです。ウェーブを分けるのは依存関係がある場合に限り、人数を理由にしてはいけません。また、ウェーブのコストは最も遅いメンバーで決まります。 トピックの重要度で段階化するのは、実際によくある失敗パターンです。長時間かかる役割を第 2 ウェーブに置くと、そこで待機した後、単独でクリティカルパスになります。作業量が本当に上限を超える場合は、予想所要時間で段階化し、時間のかかる役割を第 1 ウェーブに入れます。
• おおよその順序は、所要時間の長い順です。2 プロジェクトの EU アカウントで一度計測した結果なので、実際に観測した結果を優先してください。usage-trend、change-point、definitions-and-hygiene、internal-context、clay · event-mix、site-scan、replay-and-errors、flags-and-experiments、money-quotas · data-platform、identity-and-sdks、app-engagement、money-invoices、docs-prewarm。2 つはこの計測時間ではなく判断に基づいて配置しています。clay と internal-context は、ツールがなかったため早く終わっただけです。Clay がクレジットを確認するためにポーリングしたり、Gong がトランスクリプトをページ分割して取得したりする実行では、はるかに時間がかかります。money-quotas は実行時間の長さにかかわらず、制限によって実際に何が切り捨てられたかが他のすべての調査結果の捉え方を変えるため、優先度を上げています。docs-prewarm は最後に実行し、必須の情報収集エージェントの枠を使いません。 | ラウンド | 担当 | 実行内容 | |---|---|---| | 1a. ブロック解除 | メイン、順序どおりの3バッチ | 誰を調査し、どのバッチを実行するかを決めるすべての処理です。どちらも推測で決めるべきではありません。バッチ1：Vitally の解決、resolve-teams、sibling-sweep の両方の部分、および管理者メールのドメインに対する site-scan サブエージェントを、この同じブロックで実行します。バッチ2：稼働中の組織を特定する複数組織のボリュームプローブ、および最初のチーム以外の各チームに対する site-scan を1つずつ実行します。それぞれに resolve-teams から得た独自の api_token を渡します。バッチ3。稼働中の組織が判明した後に限り：スコーププローブ、ステージの特性、get_account_conversations、カレンダーの読み取りを実行します。次にコンテキストファイル（agent-briefs.md）を作成し、モードを検出して、ラウンド2を開始します。3つのバッチは順番に実行し、1つのブロックにはまとめません。 スコーププローブをスイープと同時に実行すると、たまたま accounts[0] が返した組織のプロファイルが作成されます。このゲートが存在する複数組織のアカウントでは、その組織は休眠中の組織です。そのため、数値がコンテキストファイルに記録され、後続のすべての情報収集担当者がそれを信頼してしまいます | | 1b. 解決 | メイン、1つのブロックで、ラウンド2と同時に実行 | get_user_details、vitally.accounts.traits の読み取り、account-state、account-spine、onboarding-state、other-account-tables、conversation-bodies、change-timeline、billing-limit-updates、account-context、touchpoint-timeline を実行します。これらを明記することで、暗黙に省略されるのを防ぎます。billing-limit-updates は1つのクエリで、すべての制限を設定した担当者を特定します。通話前に制限が変更されていれば、金額の見え方が変わります | | 2. 情報収集 | 以下のロールを、上限が許す場合は1つのウェーブで、そうでなければ最長のものから順に実行 | モードで必要となるすべてのロールを実行し、docs-prewarm は最後に実行します | | 2. （同時に） | メイン | 会話本文を読み、ステップ4の担当者一覧を確認し、internal-context の返却に応じてモード検出を調整します | | 3. 照合 | メイン、1つの並列ブロックで実行 | 点呼、ヘッジの一括確認、名前付きペアを実行し、その後、見出しの数値と最上位の推奨事項を左右する数値を再確認します。出力に含めるすべての主張を列挙します。2つの情報源に食い違いがあれば、両方の数値を示して明らかにし、決して解消しません | | 4. 検証 | キャッシュで主張を確認できる場合はメイン、キャッシュでカバーされないクラスターごとにサブエージェントを1つ。各エージェントの主張は約5件まで | 主張ごとにドキュメントをライブ検索し、URLと、その主張を裏付ける逐語的な一文を返します | | 5. 作成 | メイン | 出力を作成します |

独立した事前解決ラウンドはなく、サイトスキャンはアカウントごとではなくチームごとに1回実行します。 ドメインスキャンに必要なのは管理者のメールドメインだけです。ステップ1では何かを照会する前にこれが分かるため、解決処理の前ではなく、バッチ1で解決と並行して実行します。複数のチームを持つ組織では複数のトークンが使われるため、1回のスキャンで読めるのは1つのプロジェクトの init() だけで、残りは不明のままです。このために resolve-teams は api_token を返し、最初のチーム以外の各チームに対して、バッチ2で独自のスキャンを実行します。それに加えて再スキャンするのは、ステップ1で異なるドメインが返された場合に限ります。

これは速度ではなく、正確性に関するルールです。設定が読み取られていないプロジェクトについて、情報収集担当者に設定変更を推奨させることはできません。そして、調査されていないプロジェクトに調査結果が残っていることが繰り返しあります。2つのプロジェクトを持つアカウントでは、スキャン済みのプロジェクトはすでに最適化されており、未スキャンのプロジェクトに残りの改善手段がすべてありました。

すべてのサブエージェントに、コンテキストファイルのパス、規約ブロック、読み取りマップの該当行、返却ルールを、すべて agent-briefs.md から渡してください。コンテキストを解決するのはメインで一度だけとし、情報収集担当者が再解決することはありません。値が不足している情報収集担当者は、その値を照会せず、不足していることを報告します。site-scan エージェントは、コンテキストファイルが存在する前に実行されるため例外です。バッチ1のスキャンにはドメインだけを渡し、バッチ2の各スキャンにはドメインに加えて、そのチーム固有のチーム ID と api_token を渡します。

オプションの情報源は一度だけ調査します。 Gong、Slack、Clay は同じ形式です。空であることは1回の呼び出しで判明し、結果が0件ならその情報源の調査は終了します。「Xを検索し、結果は0件」と報告してください。これは調査結果であり、省略ではありません。 役割の一覧、各役割の担当範囲、各役割が参照するセクションは、agent-briefs.md の1つの表にまとめます。 このファイルに置くのは、メインエージェントがブリーフを作成する際に読むファイルだからです。常に読み込まれる2つのファイルに同じ役割を列挙する表を置くと、内容に食い違いが生じます。

agent-briefs.md には各役割が参照するセクションが正確に記載されており、ブリーフに含まれるのはその対応関係です。各情報収集エージェントへの質問は6つではなく、3〜4つにしてください。番号付きの質問を6つ並べると、6件の調査を促し、12回の呼び出しで済む役割を30回の呼び出しに膨らませてしまいます。

未知のプロパティを調べる場合は、専用のラウンドを設けず、すでにクエリを実行しているブロックに追加してください。そのイベントには JSONExtractKeys(assumeNotNull(properties)) を追加します。

スコーププローブと、その3つのガード

Round 1a のスコーププローブ（per-product-usage の集計1件）により、どの製品に利用量があるかがわかります。その結果を既知の状態として各製品のブリーフに渡し、各行には必ず根拠を添えてください（「billing_usage_by_org_date で対象期間中の billable_feature_flag_requests_count_in_period = 0」のように記載し、「フラグはゼロ」のような根拠のない記述は避けます）。これはブリーフの内容を変えるものであり、ブリーフを実行するかどうかは変えません。 ガードは3つあり、すべて満たさなければ安全に使えません。

1. プローブに該当する列がない製品は、すべて unmeasurable, no source と記載してください。実験の利用量とウェブ分析の利用量には、どこにもデータソースがありません。ヒートマップの利用量は利用状況レポートの teams マップにのみあり、ff_count は組織利用状況レポートにあります。
2. ゼロという結果を信頼する前に、org-snapshot の realm を確認してください。このテーブルは Cloud のみを対象としているため、セルフホストの組織では日次の利用状況が記録されていても、どの項目もゼロになります。また、利用がない日の行は含まれません。
3. 各ブリーフには、「製品固有のデータソースで検証し、確認した内容を報告する」と記載してください。「確認して次に進む」ではいけません。

モードで必要とされる役割をスキップするために、プローブを使ってはいけません。 スキップすると、ゼロと測定不能が同じ扱いになってしまいます。それを防ぐことが、このスキルの目的です。実際に実行してゼロを確認したエージェントは、スキップされたわけではありません。

ラウンド 3：ロールコール、ヘッジの洗い出し、照合すべきペア

再実行する前に、3つの確認を行います。どれも、数字の誤りではなく入力全体の欠落を検出するためです。

ロールコール。 モードで必要なロールと実際に起動したロールを照合し、ラウンド 1で必要なスラッグと返されたスラッグを照合します。各情報収集役は、自分が読み取りを省略した理由を説明しますが、その上位レベルで確認する役割はありません。そのため、時間に追われてロールが抜けても、出力は完全に見えたまま、気づかれずに消えてしまいます。不足しているロールを起動するか、最後の注記で明示してください。「時間不足」は明記すべき理由であり、省略してよい理由ではありません。これは、メールでもブリーフでもない依頼で特に重要です。読者が欠落に気づくための想定セクションがないからです。

ヘッジの洗い出し。意図ではなく、リストを作成します。 情報収集役自身の不確実性を示す表現（「おそらく、ただし未検証」「測定不能」「確認が必要」「照合する価値がある」「最大の見落としは」「通話で質問」）がないか、すべてのダイジェストを読み、該当するものをすべて、どれも解決する前に番号付きリストに書き出してください。各項目には対応方針を付けます。数字で解決するか、明示した未解決の質問として出力に残します。ヘッジを示す情報収集役は、それを解決するために必要な読み取りをほぼ必ず特定しているので、どれも低コストで範囲が明確です。

頭の中だけで行うと失敗します。意識するだけの洗い出しでは簡単なヘッジは解決できますが、見落とすのは決まって、作業が必要な回答を伴う、最上位の推奨の下にあるヘッジです。未解決のヘッジは、調査結果が消えてしまう原因です。エージェントは役割を果たし、シグナルはダイジェストに残っているのに、文章になることはありません。どちらも断定として出てしまった、見逃してはならない具体的な形が2つあります。すでに推奨している施策の効果を「定量化」できたはずのヘッジ（推奨はそのまま残る一方、説得力を持たせる数字が抜け落ちます）と、別の情報収集役がデータを持っていて確認できたはずの原因を示すヘッジです。

照合すべきペア、つまり一致している必要がある情報源です。

• サイトスキャンで見つからなかったという結果と、顧客独自のイベントストリーム。 スキャンは、検出したものについては信頼できますが、検出しなかったものについてはそうではありません。チームがそのホストを含む $current_url を持つイベントを受信しているなら、スキャン結果にかかわらず、そこにはツールがインストールされています。不在を主張として出力する前に、クエリを1回実行してください。
• ヘッダーに記載された金額と請求書。
• 同じ対象に触れた場合の、複数の情報収集役どうし。 食い違いが起きるのは、到達可能性に関する主張です。一方のロールがテーブルを調べて Unknown table を受け取り、測定不能と報告する一方で、別のロールがよく似た名前のテーブルを正常に読み取り、そこから調査結果を公開する場合があります。すると、両方のダイジェストが正しいのに、出力には矛盾が生じます。執筆する前に、複数のロールが触れた対象をすべてリストアップし、それぞれが存在するかどうか、何を保持しているかについて見解が一致していることを確認してください。

ラウンド4の検証とドキュメントキャッシュ

検証は完成した主張リストに対して実施します。ラウンド2の事前ウォームアップは追加的なものであり、リストを減らすことは決してありません。キャッシュが主張をカバーしている場合はメインで検証し、カバーしていない主張に限って作業を振り分けてください。 どちらの場合も不変条件は同じです。すべての主張に対して個別のライブ検索を行い、主張に対する検索数が、それを実施した証拠となります。

検証担当者1人あたりの主張数を約5件に制限し、主張を増やすのではなくエージェントを追加してください。 この上限が制御するのは調査の深さではなく、影響範囲です。検証は実行の最終段階なので、主張が12件ある検証担当者は、やり直す時間が残っていない時点で単一障害点となり、途中で停止して何も書き残さない可能性があります。検証担当者が停止した場合は、再起動するのではなく、トランスクリプトを使って作業を再開し、まずファイルを書き、その後で返信するよう伝えてください。また、手を付けられなかった主張にはすべて NOT REACHED と記してください。主張が省略されると検証済みのように見えてしまいますが、このラウンド全体はまさにその事態を防ぐためにあります。調査結果が出る前に paidProducts から検索すると、予測したレバーは検証できても、データから明らかになったものを見逃します。まず主張リストを作成し（voice.md の下書き前チェック）、そこに記載されたすべてのレバーと製品に関する事実を検証してください。

キャッシュに関する原則は3つあり、ラウンド4のすべてのブリーフに一字一句そのまま記載します。キャッシュされたページは、そのURLが主張ごとの個別のライブ検索結果に含まれている場合に限り、その主張の根拠となります。キャッシュが提供するのはページ本文であり、判定でも引用でもありません。キャッシュは実行ごとに分かれており、前回の実行で取得したページは使いません。検証担当者は判定、正規URL、逐語的な文を返します。not found も認められます。そのように返された主張は削除するか、疑問形に書き換え、最も近そうなリンクを付けたまま公開してはいけません。まず posthog.com/docs を引用し、ドキュメントページでカバーされていない場合は PostHog が執筆した posthog.com/tutorials のページを引用してください。Community Questions や GitHub issues は引用しないでください。docs-search にアクセスできない場合は、URLごとに通常の HTTPS 取得で検証してください。

締めくくりのメモ

実行をまたいで記録が蓄積されないため、このメモだけが記録として残ります。ステップ5で、出力の後にチャットで短いメモを追加してください。長時間かかったエージェント、上限を超えたブリーフ、この実行で見つかったスキルへの反映が必要な修正を記します。提案にとどめてください。正しさの確認でありテレメトリーではないため、次の2つの数値を記載してください。

• 独自の引用URLを取得した主張数と、主張の合計数。 検証のたびに追記するリストから数えてください。実行の最後に記憶を頼りに数えてはいけません。最後に再構成した数値は水増しされるためです。水増しした数値は、ない場合よりも悪い結果になります。というのも、この比率だけが、実際のラウンド4とキャッシュ頼みの検証を見分ける唯一の基準だからです。実施した検索数ではなく、取得した引用の数を数えてください。確信を持たせるような、隣接した別のページが検索結果に返ることこそ、このチェックが検出すべき失敗であり、質問に答えるページが返った場合と見分けがつきません。
• 起動した役割数と必要な役割数、ラウンド1で返されたスラッグ数と必要なスラッグ数。 どちらも両方の数値を示してください。役割の欠落は目立つため、いずれ気づかれます。一方、ラウンド1のスラッグがひそかに未実行のままになるのは見過ごされやすく、誰も疑問を呈さないまま、欠落として出力に残る可能性があります。
• 見つかったヘッジ表現、解消されたヘッジ表現、残されたヘッジ表現の数を、ラウンド3のリストに基づいて3つの数値で示してください。

ロール以外に main が確認する内容

Round 2 のサブエージェントが表内の読み取りを担当するため、main はそれらを再実行しません。表に加えて、Vitally の get_account_conversations（上限 20 件。メタデータのみで、source: "google" は Gmail またはカレンダー、zendesk はサポートを示します）、get_account_feature_requests、get_account_health を確認します。会話本文、ノート、タスクはウェアハウス（vitally.messages、vitally.notes、vitally.tasks）から取得し、大規模なアカウントでオーバーフローする MCP 呼び出しを避けます。アカウントに関するメールはすべて Vitally に同期されるため、この 2 つの読み取りで通信記録の全体を確認でき、メールボックスを検索しても何も追加されません。 メールボックスを検索しないでください。ある連絡先の名で gog gmail search を実行したところ、別ドメインにある別顧客の個人用アドレスが一致し、そのアカウントの支払い失敗をこのブリーフに誤って記載しそうになりました。それでもメールボックスを検索する場合は、メッセージをこのアカウントのものとして扱う前に、宛先のドメインを確認してください。重複する場合も、Vitally の属性と postgres の読み取りの両方を維持し、相互に照合してください。カレンダーは毎回、明示的な開始・終了期間を指定して実行します（期間を指定しないテキスト検索では何も返りません）。Accepted: を含む件名から参加者名を使い、該当しない場合はアカウント名と管理者のメールアドレスを使います。

クエリファイルを開かずに数値を検証するため、main が手作業で確認する必要のある名前が 4 つあります。 制限によって実際にプロダクトが利用できなくなったことを示すイベントは org_quota_limited_until です。制限を変更したユーザーは billing limits updated、現在の予測値は customer_id で billing_customer と billing_upcominginvoice を結合したもの、現在の制限は custom_limits_map です。ここで列名を推測すると空の結果が返され、「制限は何も適用されなかった」と読めてしまい、実際とは正反対になります。これらは参照先であり、手順ではありません。どちらかのクエリを書く前に、queries-money.md の quota-limits と in-flight-period を確認してください。これらには、結果の意味を左右するフィルターとエイリアスが含まれています。この段落だけを基に SQL を書くと、null だけの列とハード 400 エラーが発生したことがあります。

コール準備では、すべてのロールを実行します。メールで実行する場合は、プロダクトがアカウントに関係しないロールを外し、外したロールをそれぞれ明記します。どのモードでも、該当しない場合に限り個々の読み取りを省略し、省略した項目をそれぞれ明記します。対象期間は過去 30 日間です。短い期間にすると結論が変わる場合に限り、個別のクエリを 14 日間（フォローアップ）または 7 日間（同じ週のコール準備）で再実行します。

ステップ 3. モードの判定

このステップはフラグを立てるだけで、処理を止めることはありません。どのアカウントでも、どのモードやリクエストにも対応します。 このスキルが作成するのはドラフトのみのため、人がすべての出力を評価します。矛盾は隠さず、はっきり示してください。

アカウントがすでに対応済みに見える場合は、冒頭にフラグを立てます。該当するのは、onboardingMinimumEligibility が false、終端ステージ（3. Onboarding Completed、6c. Sales Handoff、7. Paid Call Purchased）、または同じトピックに関するチームメイトの最近のメッセージがある場合です。担当者の割り当てはフラグではありません。進行中のスレッドがある場合に限り、フラグを立てます。

ユーザーの明示的な依頼を常に優先します。「X へのアウトリーチを作成して」という依頼なら、アカウントの状態にかかわらずドラフトを作成し、先頭にフラグを示します。拒否はしません。以下のシグナルは、依頼内容が明確でない場合にのみ判断材料とします。貼り付けられた受信メッセージは返信として扱い、通話が指定されている場合はコール準備として扱います。

	シグナル	参照元	注意点
stage	パイプラインのステージ	vitally.custom.onboardingPipeline	ステージを持つ唯一のフィールドで、現在使われている値にはすべて数値の接頭辞が付いています：1. New Account、2. Onboarding Initiated、3. Onboarding Completed、6c. Sales Handoff、7. Paid Call Purchased。接頭辞を含む文字列全体で照合してください。New Account だけでは一致せず、接頭辞のない trait キーでも一致しません。現在も使われている廃止済みの値（3. Customer Engaged、3a.／3b. Engaged、6a.／6b. Onboarded、6d. Churned）は、ルーティングせずフラグを付けます。値がない場合は、パイプラインに一度も入っていないことを意味します。アカウントが適格で、AE も CSM も割り当てられていない場合に限り、1. New Account と同様にルーティングします。割り当て済みのAE または CSMがいるのに値がない場合は、営業が対応中です。記録を残し、引き続き下書きを作成して、導入部分で関係者を巻き込むことを明記します。割り当て済みのOSは、ここでは何も示しません
outreach	初回のアウトリーチ送信済み	vitally.custom.onboardingUsageOutreachSentDate	vitally.custom.initialOutreach にフォールバックします。アウトリーチを送信済みでも、多くの場合は null です
threads	オンボーディングチームとの会話	vitally.messages.from の管理者 ID	AE とサポートのスレッドはカウントしません
meeting	予約済みの将来のミーティング	受諾を示す件名（Accepted:、ローカライズされている場合は例：Angenommen:）を含む、source: "google" の会話	あくまでヒントです。カレンダーで日付を確認し、ミーティングが過去のもの、辞退済み、または見つからない場合は次の条件に進みます。古い受諾情報によって、いつまでも通話準備にルーティングされないようにしてください
inbound	アウトバウンド後のインバウンド	lastInboundMessageTimestamp と lastOutboundMessageTimestamp の比較	AE、CSM、サポートのスレッドもカウントし、システムメッセージでも発火するため、カレンダーの受諾通知だけで true になることがよくあります。実際の最新の受信メッセージ本文を確認するための目印であり、それだけを理由にルーティングしてはいけません。最新の受信メッセージがカレンダーまたはシステムメッセージの場合、あるいは別の担当者宛ての場合、このシグナルは満たされていません

ステージは trait から読み取り、crm_segments／Vitally の segments からは読み取らないでください。これらは異なる語彙（Onboarding Lead、Onboarding referral、CSM Managed、TAM、Top 20、Annual Plan）を持つ別のフィールドです。New Account も Sales Handoff も含まれておらず、trait の値と完全に一致する値もありません。セグメントはステージを補足し、営業への紹介記録を永続的に保持しますが、ステージを定義することはありません。

未対応の依頼がある場合のみ、次の順にルーティングします：

0. 終端ステージ、またはチームメイトか送信者本人が同じトピックで進行中のスレッドを持っている場合：フラグを優先します。調査は十分に行ったうえで、推奨する対応は、突然のアウトリーチではなく、記録を残すか関係者を巻き込むことです。これは導入部分を決めるもので、モードは決めないため、引き続きリストを下へ進みます。ここで止めると、フラグだけが付き、出力はありません。送信者本人の最近のスレッドも、チームメイトのスレッドと同様に競合します。下書きを作成しない理由にはなりませんが、下書きで同じ内容を繰り返してはいけません。
1. inbound が trueで、最新の受信メッセージが実際の顧客からの質問である：メール、返信状態
2. それ以外で、meeting がある：通話準備
3. ステージが 1. New Account、またはステージがなく onboardingMinimumEligibility が true で AE も CSM も割り当てられておらず、アウトリーチが null で、スレッドが 0 件：メール、初回連絡状態。AE または CSM が割り当てられている状態でステージがない場合は、4 に進みます
4. それ以外：メール、フォローアップ状態

最終決定の前に会話履歴を確認してください。スレッドの文脈は、個々のシグナルより優先されます。次の場合はフラグを付けて、処理を続けます：アウトリーチが存在するのにステージが 1. New Account のまま；アウトリーチの記録がないのにステージが 2. Onboarding Initiated；終端ではないステージに終端タイムスタンプがある（営業による不適格判定のリセットを示します）。

ステップ 4. アカウントの担当者（報告するが、振り分けには使わない）

担当の有無にかかわらず、実行のたびにヘッダーに担当者一覧を記載します：OS <name or NONE> · CSM <name or NONE> · AE <name or NONE>。区切りには中黒を使い、テーブルのセルが崩れるパイプは使いません。

担当者の割り当ては担当者一覧のデータであり、警告ではありません。アクティブなスレッドがある場合にフラグを立てます。 オンボーディング完了後も OS の割り当ては継続し、AE や CSM は単に未割り当ての場合がよくあるため、NONE は一般的で正しい値です。どちらも「これは X の担当なので、まず確認してください」に変えてはいけません。これはブロッカーのように受け取られ、たいてい誤りで、調査結果を埋もれさせます。チームメイトが最近、現在のトピックについてそのアカウントにメッセージを送っている場合は、担当者の重複にあたります。それを確認するには、担当者フィールドではなく会話履歴を読みます。

情報源の優先順位：Vitally の key_roles 配列（account-context 内の keyrole 行）には、役割ラベル、メールアドレス、名前がまとめて記載されています。accounts_replacement_v2.csm_name／ae_name と Vitally の csmId／accountExecutiveId で確認します。billing_customer.sales_info.owner_* と crm_segments は代替情報源です。Top 20 はアカウントのティアであり、担当者ではありません。AE または CSM がいない状態で sfdc.last_task_disqualified__c が設定されている場合は、営業が見送ってアカウントが再びオンボーディングに戻ったことを示します。日付を記載してください。

「このアカウントが過去に営業へ紹介されたことがあるか」を確認するには、ステージではなく Onboarding referral セグメントを読みます。 このセグメントを追加すると引き継ぎ用プレイブックが起動し、ステージが変わった後もセグメントは維持されます。そのため、紹介済みのアカウントでも別のステージに表示されることはよくあります。これを sfdc.last_task_disqualified__c とあわせて確認します。セグメントがあり、見送り済みなら、アカウントは戻ってきており、あなたの担当です。セグメントがあり、見送り済みでないなら、引き続き営業の担当です。

年次プランでは、purchasedCreditAmount、stripe.accountBalance、creditRunwayDays、projectedCreditExpiryDate、creditExpiryVsAnnualPlanExpiry を確認します。プラン終了前にクレジットが尽きる見込みの場合、下書きの内容ではなく会話の進め方が変わるため、ヘッダーに記載します。

ステップ 5. 出力

出力には、社内向けブリーフを含め、em ダッシュ、en ダッシュ、二重ハイフンを一切使わないでください。

顧客に見せる内容を作成する前に references/voice.md を読み、推奨事項を述べる前に references/levers.md を読み、成果物に対応するモードファイルを 1 つ読んでください。

すべてのメール、すべての通話準備ブリーフ、および成果物がアカウントブリーフとなるその他の依頼に共通するヘッダーです。コードフェンスの中ではなく、実際の Markdown テーブルとして出力してください（下のフェンスはテンプレートのソースにすぎません）。該当しない行は n/a と書かずに削除してください。

# <Account> | <Artifact: first touch / follow-up / reply / call prep>

> **Flag:** <only when one applies: a teammate's live thread on this topic, a stage mismatch, a sibling org. Never a roster name.>

| | |
|---|---|
| **Pipeline** | <stage> |
| **Health** | <X>/10 |
| **Renewal** | <date> (<n> days, monthly cycle or contract) |
| **MRR** | $<actual> booked to $<forecast> forecast (<±delta>) |
| **Paid** | <products> |
| **Limits set** | <product $each>. Mark any at or near its forecast; say NONE where the largest line has no limit |
| **Limits biting** | Which products a limit has ACTUALLY cut off, from `quota-limits`, each with its start date and whether it is dropping now. NONE is an answer and is written out. A limit that is set and a limit that is destroying data are different facts |
| **People** | OS <name or NONE> · CSM <name or NONE> · AE <name or NONE> |
| **Users** | <total> listed, <n> with seats, <n> with real activity |
| **Org** | <link> |

ヘッダー項目のルールです。複数の特性が重なる場合があるため、注意してください。

フィールド	ルール
更新日	年間プランでは、nextRenewalDate は契約更新日ではなく月次請求サイクルの終了日です。contractRenewalDate（または numberOfDaysUntilEndOfContract）を使ってください。月次アカウントでは両者は同じです
MRR	usage_mrr は実績値、forecasted_mrr は予測値で、どちらもクレジット割引を差し引いた値です（forecasted_usage_mrr は割引前の値なので、混同しないでください）。差分は forecasted_mrr - usage_mrr です。年間アカウントで差分が負の場合、通常は解約ではなく、年間契約と利用額の違いによるものです。diff_dollars は別の比較値です
ヘルス	get_user_details の healthScore を使ってください。同名のデータウェアハウス列が 2 つありますが、どちらもここでは使いません。vitally.accounts.health_score は古いコピーで、account_health_scores.health_score は PostHog 独自のエンゲージメントモデルです
ユーザー総数	get_user_details の usersCount を使ってください。クエリごとの件数は異なる場合があります
組織リンク	https://us.posthog.com/project/2/groups/0/<ORG_ID>（組織のグループタイプは 0 です）

出力を引き渡す前に、次の 8 項目すべてを確認してください。未確認の項目は、それを担当するラウンドに差し戻してください。すべての主張が今回の実行で行ったクエリまたはライブ検索に基づいていること、すべてのスキップについてサブエージェントごとに理由が記載されていること、検出したトラップがすべて報告されていること、トラップがなかったと報告する実行には確認の質問を行ったこと、ヘッダーが People 行を含む実際のテーブルであること、担当エージェントがまだ実行中の状態で、その対象のセクションを確定版として出していないこと、Round 3 の点呼を実施し、不足があれば明記していること、締めくくりの注記に両方の数値が記載されていること。

時間がないときに省かれがちな書き込みゲートは、明示的なルールです。 実行中のエージェントは、処理が完了するまでその対象を担当します。完了を待つか、セクションを作成して出力内で暫定版と明記してください。暫定版と明記すればチェックリストを満たしますが、確定版として出すことはできません。担当エージェントが後から否定する内容を確信を持って記載すると、ユーザーはすでに読んだ内容の訂正を受けることになり、すでにその内容に基づいて行動している可能性もあります。

パイプラインに関するリマインダー

ユーザーに伝えるためのリマインダーであり、ユーザーが明確な言葉で書き込みを依頼しない限り、こちらで書き込みを実行してはいけません。ユーザーが対応済みだと伝えた場合は、アウトリーチを送信済みなら Onboarding Pipeline を 2. Onboarding Initiated に移動し、営業に引き継いだなら 6c. Sales Handoff に移動します。調査の結果「連絡しない」と結論づけた場合に限り、その理由を記録するための Vitally メモを提案してください。ドラフトのみの実行では、書き込みは不要です。

スキルの改善

実行中に修正点が見つかったら、取り込むかどうかを尋ねてください。ルールを最少の語数で、それを担当するファイルに書き込み、例外を追加するのではなく、失敗したルールを修正してください。これらのファイルを正確に保つためのルールが 2 つあります。すべての行はモデルの動作を変えるものです。 出典、測定値、方向づけは、実行時に読み込まれない README.md に記載するか、削除してください。データの形は長期にわたって変わらないため、記録してください（結合キー、存在しない列、リージョン間で重複する ID など）。製品の状態は変わりやすいため、記録する場所はありません（機能に対応する SDK、プランの料金、設定の場所など）。そのため、毎回検索し、検索結果は決して記録しないでください。