PENGIN Tools — Phase 1 ローンチ計画

最終更新: 2026-08-18 (Day 2) Phase: Phase 1 — 無料集客資産 このRunで選定した最初の公開物: WordPress Migration Skill

---

0. 前提（正本・変更しない）

PENGIN Tools は、Web制作会社・フリーランス・Web担当者が、制作／公開／移行／保守／SEO／LLMO で 日常的に使う小さな道具を、1サイト・1ブランドに集約するツールボックス。

Web制作の面倒な作業を、小さなツールでなくす。制作・移行・保守・AI検索まで。

• 無料ツール・無料Skill = 集客装置
• LLMO Monitor / WordPress Maintenance = 収益装置
• 各商品は独立課金。初期版でセット販売もTools Proも作らない。
• ブランド全体の最初のMRR目標: 月5万円

---

1. Phase 1 の3候補を同じ尺度で比較

Phase 1 の3つの無料集客資産を、1営業日で実物が出るか / フォロワー0から到達されるか / Phase 2へ繋がるか の3軸で比較した。

判断: WordPress Migration Skill を最初に公開する

理由を3点に絞る。

1. OGP Bulk Checker は先に潰れている。 無料・登録不要・10URL一括・CSV出力・複数SNSプレビューという、 自分が作ろうとしていた仕様がそのまま既存の無料ツールで提供済みだった（証拠: はちのす制作 OGP確認ツール ほか）。 ここに1営業日を使っても差が出ない。Phase 1 から一旦外し、Phase 2 の LLMO Free Checker と同じ サイト実装のタイミングでまとめて作る（サイトを1回立てる工数を共有できる）。
2. 移行はPhase 1で唯一「承認なしで完成し、承認なしで価値が確認できる」形。 Skillはファイル配布物なので、公開承認前でもローカルで完成・自己検証できる。 Web公開が必要なOGPツールと違い、Day 2 に実物が出せるのはここだけ。
3. 痛みの単価が最も高く、Phase 2 への導線が自然。 移行は失敗が本番障害に直結する。 さらに移行直後は「新URLがAI検索・検索でどう扱われているか」が最大の不安になり、 LLMO Free Checker → LLMO Monitor へ無理なく繋がる。保守Skillは有料Maintenance(Phase 3)へは繋がるが Phase 2 を飛び越すので、順番として後ろに置く。

Maintenance Skill は Phase 1 内の2番手として残す（廃止しない）。Migration Skill の外部反応を見てから着手する。

---

2. 集客の起点（商品案からではなく、人が既にいる場所から逆算）

「公開すれば来る」は計画として認めない。最初の到達面は GitHub のキュレーション経路であり、 自サイトはその後に置く受け皿。だからサイトより先にSkillを作る順番になる。

---

3. なぜ「記事」ではなく「Skill」なのか

WordPress移行の解説記事は日本語で既に飽和している（制作会社コラムが検索上位を占有）。 そこへ記事を足しても差がない。一方で、それらの記事が指摘する失敗（シリアライズデータ破損、 プラグイン移行のタイムアウト、パーマリンク404、siteurl/home不整合による無限リダイレクト、 ステージングの noindex 残存）は、手順書を読んでも人間が取りこぼす種類のミスであり、 機械的なチェックで潰せる。読む物を動く物に変えるのが、この事業の一貫した方針。

---

4. Phase 1 スコープ（今回作るもの / 作らないもの）

作る:

• skills/wordpress-migration/SKILL.md
• scripts/preflight.sh — 移行前の環境診断とリスク判定
• scripts/search_replace_plan.sh — dry-run 強制・バックアップ必須の安全な URL 置換
• scripts/verify.py — 移行後の公開URL検証（noindex / canonical / 旧ドメイン残存 / 混在コンテンツ / リダイレクトループ）
• references/RUNBOOK.md — 手動・CLI移行の全手順
• references/TROUBLESHOOTING.md — 症状→原因→対処
• README.md — GitHub向け 日本語 + English

作らない（今回は明確に外す）:

• ブランドサイト全体
• OGP Bulk Checker
• Maintenance Skill
• LLMO 関連すべて
• 外部公開・外部送信・支出（初回Runの制約）

---

5. 次の3手（最短で学べる順）

1. Day 3: Skill を GitHub 公開する承認申請（GITHUB_PUBLISH 相当）。 公開そのものが目的ではなく、キュレーション経路に載るかどうかを測るため。 併せて README の英語面を整え、topic に claude-code-skills / wordpress を付与。
2. Day 4-6: 実際に検証用WordPressで移行を1本通し、その過程を実演コンテンツ化。 宣伝文ではなく作業ログとして出す。
3. Day 7 目標（外部シグナル）: 第三者による clone / star / Issue のいずれか1件。 0件なら、原因を「発見されていない」のか「見つけたが刺さらない」のかに切り分けてから次を決める。 制作量を増やす対応は取らない。

---

6. 撤退・修正の条件

• Day 10 時点で外部シグナル0かつ流入経路が特定できない場合、Skill配布という流通形態の仮説を疑う （Skillは残し、同じ移行ナレッジをWeb上の実行ツールへ形を変える）。
• 構想（ツールボックス、無料集客/有料収益の分離、独立課金）は放棄しない。変えるのは形態と順番のみ。

---

6.5 Day 2 後半Run の記録（公開可能状態にするまで）

見つけた欠落（これが今回の最重要事項）

SKILL.md、README.md、そして verify.py の FAIL 時出力（「references/TROUBLESHOOTING.md の 該当項目を参照してください」）が、いずれも references/RUNBOOK.md と references/TROUBLESHOOTING.md を参照していたのに、両ファイルが存在しなかった。 この状態で公開すれば、Skillが起動しても手順の正本が無く、エラー時の導線が壊れたリンクになる。 外部反応を測る以前に商品として不成立。よって今回の作業は「新しい物を足す」ではなく 参照の穴を閉じて公開可能状態にすることに絞った。

作ったもの:

• references/RUNBOOK.md — 移行の型判定（A〜E: サーバーのみ/ドメインのみ/両方/ステージング本番化/HTTPS化）から 事前調査、日程（TTL引き下げ・SSL事前発行）、バックアップ、ファイル転送、DB移行、wp-config再作成、 URL置換、DNS切替前のhosts検証、切替、切替後検証、引き渡し、ロールバック、実行前チェックリストまで
• references/TROUBLESHOOTING.md — S1〜S16の症状別対処。verify.py の issue コード （redirect_loop、noindex_header、canonical_old_domain、mixed_content、 robots_disallow_all 等）から該当セクションへ引ける対応表を先頭に置いた
• README.md に「検証状況（v0.1.0）」を追加

実行検証について（できなかったことを、できたと書かない）

このRunの実行環境にはシェル実行手段が無く、preflight.sh / search_replace_plan.sh / verify.py を実際に走らせることはできなかった。 やったのは静的レビュー（危険な既定値の排除、破壊的操作の封じ込め確認、参照整合）だけ。

そのため README と SKILL に「実サイト未検証」を明記した。設計上、 preflight.sh と verify.py は読み取り専用、search_replace_plan.sh は既定 dry-run で --execute ＋実在する非空 --backup が揃わなければDBを触らないため、 未検証のまま配布しても利用者の本番を壊す経路は残っていない。 ただし「検証済み」と偽ることはブランドを消費するので、状態をそのまま書く。

今回の経営判断: 検証環境の構築を待たず、GitHub公開の承認を申請する

理由は、**このSkillの最大の不確実性は「動くか」ではなく「見つけられるか」**だから。 コードの正しさはローカルで詰められるが、キュレーション経路に載るか・Web制作者に刺さるかは 公開しないと1日も測れない。Day 7 の外部シグナル期限に対して、検証環境の整備を先に置くと 測定開始が後ろへずれるだけで学習が増えない。 破壊的操作が封じられており、未検証であることを明示できる以上、公開を先に置く判断が合理的。

公開後に測るもの（測れないものを目標にしない）

0件だった場合の切り分け: visitor が0なら発見されていない（→ 配布面の追加、description の見直し）。 visitor はあるが star / clone が0なら見つけたが刺さらない（→ 価値提示の作り直し）。 どちらでもないのに制作量を増やす対応は取らない。

---

7. 価格の位置づけ（Phase 3 の前提メモ）

日本のWordPress保守の相場は月額5,000円〜10万円、中小企業の標準帯が月額1〜3万円（二次情報・要一次確認）。 PENGIN Tools の WordPress Maintenance は月2,980〜4,980円で、この相場帯の下に位置する。 これは「制作会社の伴走型保守」と競合する価格ではなく、 自分で保守している層／保守を内製している制作会社が、作業を圧縮するために使う道具の価格。 競合は保守代行業者ではなく「自分でやる」であり、そこはPLGと整合する。 Phase 3 着手時に、この前提を実際の見込み客への接触で検証する。