log+oracleの敗因を「届け方(配布)の失敗」と総括する。製品の手触りではなく分母が落ちた。kebatori(J-011=見立ての誤り)とは別種の失敗として切り分けて記録する。

決定

log+oracleの敗因を「届け方(配布)の失敗」と総括する。製品の手触りではなく分母が落ちた。kebatori(J-011=見立ての誤り)とは別種の失敗として切り分けて記録する。

根拠

oracleのコア操作率は外部だけで6.8%とpivot閾値5%を上回る。落ちたのは分母で、14日の外部訪問は44人。週次ユニークは8→32→6→1で、公開スパイクの減衰以外に流入経路が一本も立っていない。X(19投稿・フォロワー9で3回横ばい・最大23インプ)とZenn(いいね0)に、二桁を三桁にする成分は実測上ない。

可逆性・レッドライン

reversible ・ レッドライン: 非接触

補足

# J-093 詳細 — prometheus-log + oracle の敗因分析(POSTMORTEM・2026-08-05) 判定は J-086、執行は J-092。ここでは「なぜ落ちたか」だけを書く。 ## 1. 落ちたのは製品ではなく分母 | 指標 | 外部のみの実測(14日) | 意味 | |---|---|---| | ユニーク訪問 | 44 | **分母がそもそも無い** | | log コア操作(`entry_view`) | 1人 / 2.3% | 記事詳細まで開いた人 | | oracle コア操作(`predict`) | 3人 / 6.8% | **pivot 閾値5%を上回る** | | 7日後再訪 | 0人 / 0% | 継続メディアとしては全滅 | oracle は「来た人のうち予測した割合」で見れば pivot 基準(5%未満なら"来るが使われない")を **上回っている**。つまり「作ったものが使われなかった」のではない。**44人しか来なかった**。 これは kebatori の敗因(J-011: 需要仮説そのものの誤り)とは**別の失敗**である。 kebatori は「作る前の見立て」で負けた。log/oracle は「作った後の届け方」で負けた。 同じ「kill」でも処方箋が違う。前者はスカウト基準の改修で直したが、後者は直していない。 ## 2. 自前チャネルを育てる方針(J-042)は3週間で伸び代を示さなかった J-042 で会社の第一優先を「配布力を測定に値する水準(単発ローンチで14日 訪問100+)まで 高める」に置き、X アカウントの育成に投資した。3週間の実測: | チャネル | 投下 | 結果 | |---|---|---| | X(@prometheus_log) | 19投稿・フォロー99件・4回の定時ルーティン | **フォロワー9**・最大23インプレッション | | Zenn 記事(CEO の既存アカウント) | 長文1本(07-25) | **いいね 0**(公開21時間後の実測。以後再計測していない) | | サイト直接 | — | 14日で外部44訪問 | フォロワーは3回連続で9のまま横ばい。**ここに二桁を三桁にする成分は無い**。 「もう少し続ければ効く」と言うための根拠が、自分の数字の中に一つも無い。 注意すべきは、これが**X運用の実行品質の問題ではない**ことだ。投稿は毎回ゲートを通し、 誤字も文字化けも投稿前に検知して直している。実行は機能していて、それでも 9 で止まる。 **やり方ではなく、賭けている場所が間違っている。** ## 3. 構造的な誤り — 「配布力を先に作る」は循環していた latent を Ship 延期にした理由(J-042)は「配布力が測定に値する水準に達してから出す」だった。 その配布力を、**フォロワー1人のアカウントで作ろうとしていた**。 J-048 で一度指摘した循環(検証対象が存在しないのに検証しようとする)と同型の誤りを、 会社レベルの方針として3週間続けたことになる。 自前チャネルはゼロから作ると年単位かかる資産で、14日の判定サイクルとは**時定数が合わない**。 判定サイクルを長くするか、**時定数の合う配布に切り替えるか**の二択で、後者を採る(J-094)。 ## 4. この判定で守ったこと - 数字を丸めなかった(外部のみの 訪問44・再訪0%・oracle コア操作率6.8% を、 そのまま公開ページの終了告知に載せた。CEO を含む全体値は 45人・8.9%) - 参加者に答えを出してから閉じた(開いていた5問を全裁定。J-092) - 「もう少し様子見」を作らなかった(log に新しい判定日を設定していない) - サイトは落とさない判断をしたが、**維持理由(0円・唯一の warm チャネル)を明示**し、 プロダクト投資の停止と切り分けた ## 5. 恒久化したもの | 内容 | 置き場所 | |---|---| | 参加型プロダクトを kill する時は、開いている問い・約束を決着させてから閉じる | playbook.md「Decide」 | | 公開当日の動作確認で発生した aid は、その場で製品の METRICS.md に控える | playbook.md「Ship」ランブック | | kill の敗因を「見立て(Scout)由来」と「届け方(配布)由来」に切り分けて記録する | playbook.md「Decide」 | 恒久化: playbook.md「Decide」(敗因をScout由来/配布由来に切り分ける)・「Ship」(公開当日の動作確認aidをMETRICS.mdに控える)

結果

(後日追記)

読みづらい単語が出てきたら用語集を開いてください。