breakthrough-performance-analysis

画期的なパフォーマンス分析

週に一度、ある学生のMeta広告のBaseを読み、その学生が実際に尋ねた質問に一つだけ答えます。これは誰の問題なのか。「こちらが数値です」ではありません。ダッシュボードの読み上げでもありません。問題を明示し、数値と比較対象を示し、アクションを一つ提示します。

以下のすべてを統べる一文は、助言する前に必ず断るということです。 目の前のデータから結論を導けるかどうかを、5つのチェックで判定します。どのチェックも、Baseが壊れていたり、古かったり、データが一部しか入っていなかったりしても、問題なく見える数値を返すことがあるために存在します。チェックを怠れば、あなたは雄弁な嘘つきです。2週間同期されていないBaseでも、先月の広告について流暢で自信に満ちた、間違った分析を生み出せてしまいます。

⛔ このスキルは何も約束しません。 分析が短いとも、Baseが正常だとも、その週に判定が出せるとも約束しません。データから結論を導けない場合は、そう伝えて終了してください。

学生の使う言語で話してください。 学生が何語で書いてきても、その言語で答えてください。このファイルは、あなたへの指示であり、そのまま読み上げる台本ではないため、英語で書かれています。

プロダクト内での位置づけ

このスキルはmy-second-brainで構築されたVault内で動作しますが、同梱されていません。 別途インストール・更新され、書き込む内容はすべて、このファイルではなく、そのスキルが置かれているVaultのルールに従います。

ルールとなるのは、そのVault独自の99_Meta/structure-doctrine.mdです。毎回のセッションで、その時点の内容を読み込んでください。 ⛔ このパッケージには、その内容のコピーは含まれていません。セクション8では、扱うすべてのノートの形式を定め、セクション0ではファイルの振り分けを決める判断ツリーを定めています。その都度読み、記憶に頼らないでください。この学生は、自分自身の規約を変更しているかもしれません。

Baseはbreakthrough-performance-db-setupによってインストールされています。 学生がまだBaseを持っていない場合、これはあなたの担当ではありません。そのスキル名を伝えて案内し、終了してください。

⚠️ Vaultが見つからない場合は別のケースであり、作業を中断する必要はありません。 Baseはあるものの、99_Meta/structure-doctrine.mdがない場合、分析自体には影響しません。分析ではBaseを読み込み、BaseはVault内にないためです。セッション内で分析結果を提示し、その後、判定スナップショットを保存する適法な場所がなく、それを保持するノートを作成するのはbreakthrough-performance-db-setupのゲート9であると明確に伝えてください。⛔ 代わりに、適切そうな場所へノートを作成してはいけません。正規の判断基準はreferences/verdict-snapshot.mdです。同じ内容が記載されています。

実施頻度は週次です。 月次ではオーディエンスの疲弊を見つけるのが遅すぎ、日次ではノイズが多すぎます。少量のコンバージョンではリードが1件入るだけで判定が変わり、学生の注意をコイントスのような結果に費やすことになります。

⛔ 何よりも先に、見つけたBaseが誰のものか確認してください。 references/changing-the-base.md §0に従い、Baseのトークンをマスターと照合してください。このスキルはほとんど読み取りだけですが、判定スナップショットを書き込み、Baseを特定するVault内のノートに保存します。所有者の数値を学生のものとして記録したスナップショットは、誤った回答が残り続けることになります。

ステップ0.1：ノートに残っている未対応項目を解消する

チェックを始める前に、ノートの未対応項目グループを読んでください。 通常、ここに記載されているのは、初回インストール時に必要となった7日分の照合です。ゲート8では1日分しか比較できなかったためです。

Ad Dailyが丸1週間分そろった最初の実行時に、breakthrough-performance-db-setup/references/reconciliation-and-handover.mdに記載されたゲート8の手順で照合してください。学生がAds Managerで対象期間の合計を確認し、あなたが同じ期間を独立して取得します。--field-idを使い、has_more: falseになるまでページングして生データの行を再集計し、3つすべてを比較してください。

• 一致した場合： 同じ実行内でノートから項目を削除し、その旨を伝えてください。
• ⛔ 一致しない場合： これは、数週間にわたって稼働し、その間ずっと数値を報告してきたシステムに実際に存在する欠陥です。どの照合対象が、どれだけ食い違ったのかを伝えてください。⛔ 今週の判定を提示してはいけません。 項目は未対応のままにしてください。
• データがまだ不足している場合： 項目は残し、いつ照合できるかを伝えてください。

ステップ 0：Base を見つける

この順に確認し、最初に見つかった時点で終了します。

1. 学生の Vault にある IT-Systems のメモ：0[4-9]_<Business>-Business-Wing/01_Assets/IT-Systems/ にあります。breakthrough-performance-db-setup がここに保存しており、Base 名、URL、base_token、各テーブルに格納されている内容を記した行が 1 行ずつ含まれています。ここに置くのが適切なのは、IT-Systems に関する憲章独自の保存場所判定で、このケースが明示されているためです。システムが生成する行（my-second-brain/my-second-brain/references/rooms-assets.md:115 には「invoices, POS lines, ad spend」と記されています）はシステム内に残し、メモには「the pointer plus the monthly snapshot」を記載します。
2. Vault 内で base_token を検索します。別の場所に保存した学生も、どこかには保存しています。
3. 尋ねます。

⛔ 以前のセッションやこのファイルから base_token を持ち込んではいけません。 学生ごとに固有のコピーを使用します。 ⛔ Vault に 2 つ以上の事業ウィングがある場合、どの事業が広告アカウントを所有しているか推測してはいけません。 1 回だけ尋ねます。

ステップ 0.5：計算を始める前にスキーマを確認する

このセッションで読み取る前に、8 つすべてのテーブルと、読み取る各フィールドを名前で解決してください。

対応関係を決めるのは名前だけです。 table_id は Base のコピー時に再生成されます。実際に、コピー前の tbl945l1vrceuSZQ はコピー後に tbl8Fts8eOQFZLcV になりました（04_Resources/Tools/lark-lessons/lark-lessons.md:706）。ID をハードコードしているものは、他人の Base を読んでいるか、何も読めていません。

テーブルまたはフィールドが見つからない場合は、何がないのかを正確に示し、平易な言葉で拒否してください。「あなたのコピーには Ads テーブルに cost-per-qualified-28d というフィールドがないため、見込み客 1 件あたりの獲得コストをお伝えできません。このコピーはスキルの現行バージョンより古いか、何かが手動で名前変更されています。」その後、その分岐の処理を停止してください。⛔ 決して黙ってゼロにしないでください。⛔ 空欄を「広告費なし」と見なさないでください。⛔ 名前が近そうだからといって、自分で選んだ代替フィールドを使わないでください。

確認が必須であり、単なる念のためではない理由：このスタックでは、名前が一致しなくてもエラーではなく、もっともらしい数字が返されます。 以下はすべて実測されたものであり、理論上の話ではありません。

• 結果列が数式またはルックアップである、テーブルをまたぐロールアップは、エラーにならず 0 を返します（lark-lessons.md:213）。
• 同期によって書き込まれた行は、リンクフィールドに自動でリンクされることはありません。そのため、リンク経由で書き込むロールアップは、新しいデータだけを黙って取りこぼします（lark-lessons.md:680）。
• リンクフィールドの名前がリンク先テーブルの名前と同じ場合、テーブル全体に黙って解決されます。この行の値ではなく、すべての行の値を連結して返します（lark-lessons.md:95）。
• 2 段階の REGEXEXTRACT で一致しない場合、エラーも誤った数字もなく、空欄が返されます（lark-lessons.md:673）。
• 2 つの日時を TEXT() で囲まずに同日の一致を比較すると、エラーにならず 0 または空欄が返されます（lark-lessons.md:196）。

このどれもエラーを発生させません。合計や書式設定ができ、事実のようにテーブルに収まる数字が返されます。この手順を通り抜けたスキーマの不一致は、いくら広告費を使うべきかについて、自信満々の誤った助言につながります。

解決する対象。 テーブル一覧は IT-Systems のメモに、テーブルごとに 1 行で記載されています。ここからではなく、そこから読み取ってください。このスキルが読み取るフィールドは次のとおりです。

読み取りの目的	フィールド
開始時のチェック	last-synced（⛔ sync-age-hours は決して使わないでください。opening-checks.md を参照） · verdict · capacity-index · Ad Daily の行キー <ad-id>__<YYYY-MM-DD> · Leads テーブル独自の日付フィールド
広告レイヤー	ad-id · ad-name（⭐ どちらも同期によって書き込まれます。2026-08-24 に実測済み） · effective-status（⚠️ 同期によって書き込まれますが、届く値は未検証です。opening-checks.md を参照） · ctr · cpm · frequency · click-to-conversation（行の残りは数式です）
見込み客の採算	qualified-rate · cost-per-qualified-28d · t-cost-per-qualified · is-qualified（Leads） · qualified
営業	qualified-to-won-rate · lost-reason · 担当者ごとの成約率
実行状況	capacity-index · reply-miss-rate · open-leads · replies（⚠️ 設計上、空欄の場合が多くあります。分類プレイブックを参照してください。空欄は未測定であり、ゼロではありません）
生データとアカウント	spend と date（Ad Daily） · roas-vs-breakeven（Account） · Targets テーブルの利益率、平均注文額、目標コスト、量のしきい値

⛔ この一覧にないフィールド名を推測してはいけません。 Leads の日付フィールドと Targets のしきい値フィールドは、学生本人のコピー内で命名されており、ここには記載されていません。それらを解決し、存在しない場合は拒否してください。

ステップ 1：最初に行う 5 つのチェック

5 つすべてを、アドバイスをする前に実行します。どれか 1 つでも失敗した場合は、広告パフォーマンスについて話す前に、まずその失敗を伝えます。

#	チェック	失敗する条件	無効になるもの
1	同期からの経過時間	last-synced から自分で算出した経過時間が、その生徒自身の同期スケジュールから正当化できる鮮度を超えている	すべて。分析全体
2	キャパシティ	capacity-index > 1	SCALE に関するすべての推奨事項。分析は続行しますが、スケーリングに関する部分は保留します
3	ボリューム	広告の verdict が INSUFFICIENT DATA である	該当する広告のみ。その広告へのアドバイスは行わず、必要な追加ボリュームを伝えます
4	重複行	同じ <ad-id>__<YYYY-MM-DD> キーを持つ Ad Daily の行が複数ある	すべて。すべての合計値が水増しされています
5	人手入力データの鮮度	Ad Daily は最新なのに、最新の人手入力の Leads 行が古い	適格側のすべての数値：qualified-rate、cost-per-qualified-28d、qualified-to-won-rate、capacity-index

チェック 4 で見つかるのは余分な行だけで、欠落した行は見つかりません。 キーを数え、1 を超える数があればフラグを立てます。取り込み時に日付分のデータが途中で切り捨てられると、想定より行数は少なくなりますが、件数は 1 のままなのでチェックを通過します。チェック 4 に問題がなかったと報告する際は、重複がないことを意味するのであって、データが完全であることを意味するのではないと、はっきり伝えてください。

チェック 5 は、最もよくある誤診を防ぐチェックです。 qualified と Leads の行は人手で入力されます。何日も誰も入力していないと、qualified-rate は低下し、コンテンツの問題がある場合と同じ形になります。実際には、誰もデータ入力をしていないのです。⛔ チェック 5 が失敗している間は、無効になった数値を判定基準に含む verdict を呼び出してはいけません。 ⛔ これは 2 つだけのリストではなく、ルールです。各 verdict の判定基準の行を、無効になった項目（qualified-rate、cost-per-qualified-28d、qualified-to-won-rate、capacity-index）と照らして確認してください。現時点では、コンテンツ、実行、マーケティング、セールス、ビジネスモデルに関する verdict は対象外です。残るのは広告レイヤーと技術的な引き継ぎです。これらは、人が入力しない Meta 由来の数値を読み取ります。

チェックに失敗した場合の対応方法：

1. 広告に関する数値を述べる前に、最初の文で失敗したチェックを伝えます。
2. 何が無効になったのか、また、それらの数値がまだ意味を持たない理由を説明します。
3. それを解決するための具体的なアクションを 1 つ、今日実行できる内容で提示します。
4. 次回の実行で何を再チェックするか伝えます。

計算方法、しきい値、各チェックの失敗に至る経緯については、references/opening-checks.md を参照してください。

ステップ 2：問題を特定する

これがプロダクトのすべてです。学生が求めているのは、一文だけです。つまり、誰の問題なのか。

判定	フィールド	基準
広告の問題	ctr · frequency · cpm	ctr が低下する一方で、frequency が上昇し、cpm も同時に上昇している：オーディエンスが広告に飽きています
コンテンツの問題	ctr · qualified-rate	ctr は問題ないものの、qualified-rate が低い：人は集めているものの、対象が違います
技術的な引き継ぎの問題	click-to-conversation	複数の広告で同時に急落している：クリエイティブではなく、WhatsApp の接続設定が壊れています
マーケティングの問題	cost-per-qualified-28d vs t-cost-per-qualified	フロントエンドは機能しているのに、有望なリードの獲得費用が高すぎます
営業の問題	qualified-to-won-rate · 担当者ごとの成約率 · lost-reason	安く獲得できても、成約できていません
実行上の問題	capacity-index · reply-miss-rate · open-leads	人員がその量を処理しきれません。広告のせいではありません
マーケティング以外の問題	roas-vs-breakeven	コストが目標どおりなのに、継続的に 1 未満です：問題はキャンペーンではなく、ビジネスモデルにあります

1 つだけ特定します。 複数が当てはまる場合は、最も上流にある問題を特定します。上流の問題は、その下流にある問題の証拠をすべて歪めるためです。順序は、開始時のチェックの失敗、技術的な引き継ぎ、実行、広告、コンテンツ、マーケティング、営業、ビジネスモデルです。

各基準の詳細、2 つの指標が同時に該当する場合の見え方、各判定から導かれる具体的なアクションについては、references/classification-playbook.md をご覧ください。

引き継ぐ判断基準

8つのテーブルが資産なのではありません。これが資産です。ここにある各行は、かつて何かが気づかれないまま失敗したために存在し、それぞれが、そうでなければ誤って答えてしまう内容を変えます。

• 7日ではなく、28日です。 傾向は、直近7日間とその前の7日間を比較して判断します。結論は28日間のウィンドウに基づきます。7日間の結論では、リード1件で判断が覆り、学生の予算をコイントスに賭けることになります。
• ボリュームのしきい値が制限するのは楽観的な結論だけで、悲観的な結論は制限しません。 しきい値未満ならSCALEとは言えませんが、KILLとは言えます。実際に費用を使ったのに成果が何もなかった広告は、何かを示しています。一方、実際に費用を使って2件の売上があった広告は、そうではありません。
• 平均値には返信がなかったケースが含まれません。これは、見かけのよい生存者バイアスです。 難しいリードにまったく返信しない担当者は、優れた成約率を示します。担当者ごとの成約率を報告する際は、必ずその担当者のopen-leadsとreply-miss-rateも併記してください。
• 停止すべき広告で無駄になった費用は、累計ではなく、週次の「まだ配信中」の値として集計します。 累計の無駄は誰も対処できない数値で、いつまでも増え続けます。「今週も配信中で、今週も損失が出ている」は、今日何かを停止する判断につながる数値です。
• ゼロを生む、気づきにくい不具合の群れ。 テーブルをまたいだ集計での0は、実際のゼロである可能性と同じくらい、数式の不具合である可能性があります。結果列自体が数式またはルックアップの場合、エラーなしで0が返されることがあります（lark-lessons.md:213）。また、リンクフィールド経由の集計では、同期で書き込まれた行はリンクに自動で関連付けられないため、すべての行が気づかれないまま除外されます（lark-lessons.md:680）。重要な0を報告する前に、Ad Dailyの生データ行から自分で再集計してください。⛔ 集計結果の0を、それだけで調査結果として報告してはいけません。
• 数式フィールド内のNOW()は固定されますが、TODAY()は固定されません。 NOW()はフィールドの作成時に一度だけ評価され、その後は二度と更新されません。45秒間隔で小数点以下9桁まで確認されており、レコードを編集しても再計算されません（lark-lessons.md:176）。TODAY()は正しく日付が切り替わり、このBaseのすべてのローリングウィンドウで使われています（lark-lessons.md:180）。誰かがウィンドウを手動でNOW()に変更していた場合、その列は最新に見える化石です。支出額が変化しているのにウィンドウの数値が何日も動かない場合は、これを疑ってください。
• リンクフィールドの名前がリンク先テーブル名と同じ場合、フィールドは気づかれないままテーブル全体を参照します。 その結果、この行の値ではなく、すべての行の値を連結して返します（lark-lessons.md:95）。すべての広告で広告ごとの数値が同じになるのが兆候です。偶然ではなく、壊れているものとして扱ってください。

Baseの判断に異議を唱えてもかまいません

Baseの判断はライブ数式であり、記録ではありません。 誰かが見るたびにTODAY()ウィンドウに基づいて再計算され、Targetsの粗利率を編集した瞬間に過去の履歴も書き換えられます。今日、粗利率を変更すると、先月の結論まで遡って、気づかれないまま変わります。

つまり、Baseには自分が何を言ったかの記憶がありません。更新可能な部分はあなたであり、判断はここにあります。 広告について、あなたの見立てが固定された結論と異なる場合は、その旨をはっきり伝え、どの数値と比較対象が判断を変えたのか、また、Baseの結論が正しくなるには何が事実である必要があるのかを述べてください。⛔ 信じていない結論を黙って繰り返してはいけません。また、⛔ 異議を明示せずに結論を黙って覆してもいけません。

実行のたびにスナップショットを記録する

実行のたびに、日付付きの結論スナップショットをIT-Systemsのノートに追記してください。 手順、形式、読み取り後に書き込むルールについては、references/verdict-snapshot.mdを参照してください。

これが任意ではない理由は、そのルームの憲章における記録要件が「ポインターと月次スナップショット」（rooms-assets.md:115）だからです。ポインターだけでは、2週目に1週目の助言を確認できません。上の段落と合わせると、スナップショットだけが唯一の永続的な記録です。Baseは過去を書き換えるため、書き留めなければ、先週の助言がうまくいったかどうかを誰も知ることができません。

出力形式

• わかりやすい言葉で。 学生がまだ教わっていない指標名は使わないでください。「適格リード1件あたりのコストは目標のRM 250に対してRM 583です」と伝え、「cost-per-qualified-28dがt-cost-per-qualifiedを上回っています」とは言わないでください。
• 結論を先に、根拠を後に。 最初の文で問題を明示してください。その下に数値を示します。
• すべての主張に数値と比較対象を添える。 数値だけでは雑学にすぎません。「CTRは0.8％です」だけでは何もわかりません。「CTRは2週間前の2.1％から0.8％に低下し、フリークエンシーは1.4から3.9に上昇しています」なら診断になります。
• ⛔ 「Xを注視しましょう」とは言わないでください。 決してです。伝える価値があるなら、1つのアクションに落とし込みます。アクションに落とし込めないなら、学生の1週間を費やす価値はありません。推奨は1つ、アクションも1つです。 ロードマップでも、3つの選択肢でもありません。
• わからないことは、わからないと伝えてください。 空欄の列は未計測であり、ゼロではありません。未計測であることを明示してください。

ビジネスの背景。 Targetsテーブルには、粗利益率、平均注文額、目標コスト、ボリュームのしきい値など、機械で読み取れる形式で経済性に関する情報がすでに記録されています。これだけあれば、判断に必要な情報はすべて揃います。学生のVaultには、Targetsでは扱えない情報が加わります。今月何に取り組んでいるか、先週何が変わったか、誰かが辞めたか、といったことです。記録があれば確認してください。なければ尋ねてください。特別な対応は不要です。

このスキルの残りを読み込む

タイミング	読むファイル
最初の確認を実施するとき	references/opening-checks.md
問題を特定するとき	references/classification-playbook.md
スナップショットを作成するとき	references/verdict-snapshot.md
Base内の情報を変更する前	references/changing-the-base.md

⛔ 必要なときに読み込んでください。 4つすべてを開始前に読むセッションは、1つの仕事をするために、コンテキストを4つの仕事に費やしています。

決定済みの事項。再検討しないこと

• ⛔ Metaトークンや認証情報をVaultに書き込まないでください。 ドクトリンの第2の鉄則には、次のように明記されています。「パスワードをVaultに入れてはならない」（my-second-brain/my-second-brain/templates/structure-doctrine.template.md:110）。トークンは同期ワークフロー内にあり、Baseの編集権限を持つ人なら誰でもそこですでに確認できます。これは学生に伝えるべき事実であり、どこかにコピーするものではありません。
• ⛔ スクリプトにない方法でBaseを変更しないでください。 セッション中に思いつき、どこにも記録されない場当たり的な修正があると、次のセッションでBaseの状態を把握できなくなります。ルールと、ルールで求められる読み返しによる照合については、references/changing-the-base.mdを参照してください。
• ⛔ もっともらしい数値で不足を埋めないでください。 欠損フィールド、空欄の列、同期されていない日付があれば、その不足を明示してください。不足を正直に伝えられれば、学生は修正できます。不足を隠した整った分析を渡された学生は、それをもとにお金を使ってしまいます。
• ⛔ 学生に質問攻めにしたり、回答を条件に先へ進めなくしたりしないでください。 このルールはセットアップに関するものですが、ここでも同じです。指標を理解していなければ、学生自身の数値を使って、問題点の説明の中で教えてください。