strategy/plan-b-launch-checker.md
Workspace snapshot · 09/04 13:33
Plan B — 公開前チェッカー（E2Eを必要としない初手）
作成: 2026-08-24 (Day 8) / 状態: 中止（同日、競合確認により）
この案は着手しない。 自ら課した前提「競合を4件だけ確認」を実行したところ、 判定項目（noindex の meta と X-Robots-Tag、robots.txt、canonical不一致、リダイレクト連鎖と ループ、ステータス、一括、登録不要）がすでに無料・サインアップ不要のツール群で網羅 されていた。詳細と出典は
workspace/research/plan-b-competitor-check.md。 OGP を飽和で外したのと同じ判断をする。以下は判断の経緯として残す。
なぜ Plan B を用意するのか
Day 8時点の事実:
- 外部シグナルはゼロ。Day 7期限を超過。
- 止めているのは制作量ではなく検証手段の不在。この実行環境にシェルがない。
- 共有LLM Runtimeでシェル実行を3回試して3回失敗した。3回とも、コマンドを実行せず
コマンド文字列そのものをテキストで返してくる（先頭に
powershellと付く）。 Runtimeは文章生成には使えるが、コマンド実行の代わりにはならないと確定した。 - E2E環境の承認は保留中で、本日期限。
つまり Migration Skill の公開は、自分の手の届かない1点で止まっている。 その1点が開かない場合に、30日のうち残り23日を丸ごと待機に使うのは経営判断として誤り。 だから「E2Eを必要としない形で外部シグナルを取る道」を先に用意しておく。
Migration Skill は放棄しない。 環境が開いたらE2Eを通して公開する。順番を入れ替えるだけ。
Plan B の中身: 「公開前チェッカー」
移行・リニューアル・ステージング本番化の直後に必ず確認する項目を、URLを貼るだけで一括判定する。 ログイン不要、メール登録不要、結果は即時表示。
判定する項目（Migration Skill が拾う事故と同じもの）
| 判定 | なぜ重要か |
|---|---|
noindex（HTMLのmeta と X-Robots-Tag ヘッダーの両方） | ステージングの検索避け残存。最も損失が大きく最も気づかれにくい |
robots.txt の Disallow: / | 上と別問題。両方見ないと片方を見落とす |
| canonical が別ドメインを指していないか | 放置すると新ドメインがインデックスされない |
| リダイレクト連鎖とループ | 移行事故の代表格。ブラウザだと「開けない」しか分からない |
混在コンテンツ（httpsページ上の http:// 参照） | 鍵マークが出ない原因の実体 |
最終HTTPステータス、<title> の有無 | 下層ページだけ404、テーマ読み込み失敗の検出 |
| 指定した旧ドメインの残存 | 置換漏れ。移行直後にこれを数えたい人がいる |
複数URLをまとめて判定し、結果をコピーできる形で出す。
既存の無料ツールと何が違うか
OGPチェッカーは飽和している（無料・登録不要・10URL一括・CSV・SNSプレビューが既に揃っている）。 だからOGPは主題にしない。
このツールの主題は「移行・公開の直後に壊れる箇所」で、切り口が違う。
- OGPツール: シェアしたときの見た目
- これ: 公開したのに検索に出ない／下層が404／鍵マークが出ない
Search Console は自分のサイトしか見られず、反映も遅い。 Lighthouse は品質全般で、移行事故に的を絞っていない。 「移行直後の5分で見る項目だけ」を1画面にまとめたものは、探した範囲では見当たらない （未確認: 網羅的な競合調査はしていない。着手前に4件だけ確認する）。
誰が、いつ使うか
Web制作会社・フリーランスが、サイトを公開した直後の5分。
現在は手作業（curl -sI を叩くか、ブラウザの開発者ツールを開くか、忘れる）。
忘れた結果が「検索に出ない本番サイト」で、気づくのは数週間後。
なぜE2Eが不要か
- 対象サイトへ読み取りのHTTP GETしかしない。書き込み・認証・DB操作が一切ない。
- 利用者の環境を壊す経路が構造的に存在しない。
- 動作確認は「公開URLを開いて、既知の結果になるサイトで試す」だけで完結する。 自分自身のサイトを検体にできるので、検証が公開と同時に回る。
集客と測定
| 誰が | どこから来るか | 何を見て動くか | 測る |
|---|---|---|---|
| 移行直後の制作者 | 「WordPress 移行 noindex」「サイト移行 検索に出ない」等の検索 | URLを貼るだけで判定が出る画面 | 実行回数、ユニーク訪問、再訪 |
| Migration Skill を見た人 | GitHub → 自サイト | 「手順の検証部分がそのままツールになっている」 | Skill→ツールの遷移 |
Skill と同じ知識から出ているので、片方が動けばもう片方へ送れる。ブランドとして矛盾しない。
着手条件（自分で勝手に始めない）
次のどちらかが起きたら着手する。
- E2E環境が「用意できない」と回答された
- E2E承認が期限切れになり、かつ次のRunでも回答がない
着手する場合の順序:
- 競合を4件だけ確認（同種のツールが既にあるなら作らない）
- 判定ロジックの仕様を1ページで確定（
verify.pyの判定を流用できる） - 最小実装（URL入力 → 判定表示。保存もアカウントもなし）
SITE_PUBLISHを1件申請（希望ラベルはpengin-tools）- 公開後24/72時間で実行回数とユニーク訪問を記録
E2E環境が開いた場合は、Plan B を保留して Migration Skill のE2E→公開を先に通す。
この判断で捨てていないもの
- Migration Skill の5ファイル（監査済み・公開待ち）
- E2E計画とコピペ実行手順（
qa/e2e-plan.md,qa/e2e-commands.md） - 未公開スクリプト3本（
verify.pyは Plan B の判定ロジックとして再利用できる）
Plan B は撤退ではなく、順番の入れ替え。 止まっている一点が開くのを待つ間に、 同じ知識から外部シグナルを取れる形を先に出す、という判断。