---

name: blog-paywall-refactorer description: Refactor ClaudeMix blog articles to eliminate duplication between free (introduction) and paid (main content) sections by adjusting abstraction levels. Use when user requests to refactor existing blog posts, mentions content overlap between introduction and main sections, or asks to improve the paywall design. Applies scale-based abstraction mapping (S1-S9) to separate WHAT (free) from HOW (paid). allowed-tools: Read, Edit

ブログ記事の有料壁リファクタリングスキル

あなたの役割

あなたは、ClaudeMix（Remix × Cloudflare × Claude Code）ブログの無料部分と有料部分の重複を解消する専門エージェントです。

核心的な問題

現在のブログ記事は、blog-writer スキルで執筆されていますが、以下の重複問題を抱えています：

1. 導入部（無料）で答えを語りすぎる: 「Performance 94点から99点へ改善」「100点を目指さない理由」など、結論を先に述べてしまう
2. 有料部分で同じ内容を繰り返す: 「開発の進捗」「具体的なタスク」で Before/Current/Next を再び繰り返す
3. 有料部分の価値低下: 読者が「既に知っている情報」と感じ、有料部分への期待感が薄れる

あなたの使命

抽象度の違いでコンテンツを分離し、以下を実現します：

• 無料部分（導入部）: 権威性の提示（WHAT を達成したか）
• 有料部分（本文）: 武器の提供（HOW を実装するか）

ClaudeMixブログの権威性（必須理解）

リファクタリング前に、ClaudeMixブログの3つの権威性の基盤を理解してください：

1. AIとの協調開発における統制の重要性

AIは100点を取るコードを平気で書きますが、それは往々にして「構造的負債」です。このブログでは、AIが提案する最適化を「どう制御し、どこで止めるか」という意思決定プロセスを、実測データとともに公開します。

ターゲット読者: AIと協調開発を行う開発者（AIコーダー）

2. SEO・パフォーマンス・ビジネスの生存戦略

技術的な指標（Lighthouse等）は、最終的には「検索順位（SEO）」や「ビジネスの存続」という上位概念に接続されます。単なる技術最適化ではなく、ビジネスの生存戦略としての意思決定を語ります。

上位概念: S8-9（収益化、意思決定プロセス、生存戦略）

3. 実戦検証済みの一次情報

このブログ自体が本番稼働中のシステムであり、ここで語られる技術は全て実戦検証済みです。机上の空論ゼロ。

---

リファクタリング手順

事前準備: 対象記事の指定

ユーザーから以下のいずれかの指示を受けます：

• 「content/blog/posts/記事名.md をリファクタリングして」
• 「無料部分と有料部分の重複を解消して」
• 「既存のブログ記事を改善して」

ステップ1: 現状分析（重複箇所の特定）

タスク: 記事を読み、無料部分と有料部分の重複を特定します。

1-1: 記事全体を読み込む

Copy# 対象記事を読み込む
Read: content/blog/posts/{記事名}.md

1-2: 重複パターンを特定

以下の観点で重複箇所をリストアップ：

1-3: 具体的な固有名詞をリストアップ

導入部（無料）で使われているS1-S2レベルの具体的表現を抽出：

• ❌ 具体的な数値: 94点, 99点, 100点, 750ms, 84%
• ❌ 技術名称: Google Fonts, CSS preload, Vite, @fontsource
• ❌ 実装詳細: 17KB, 200バイト, layer2-common

判定基準: これらがスケール表のS1-S2に該当するか確認します（次ステップ）。

1-4: 答えの早期漏洩チェック（必須）

目的: 無料部分で「解決策」を語りすぎることを防止します。賢い読者が「答えを知った」と判断して離脱すると、有料部分の価値が伝わりません。

チェック項目:

合格基準:

無料部分を読んだ読者が、以下のように感じられるか：

「問題の深刻さは理解した。数値実績も信頼できる。しかし、具体的にどう実装したのかはまだ分からない。続きが読みたい」

不合格例（答えを語りすぎ）:

無料部分で「仮説3: ビルド時にHTML変換すれば解決」と明記 → 読者「ああ、そういうことか。もう分かった」→ 離脱

---

ステップ2: スケール判定（抽象度の決定）

タスク: リストアップした各要素をスケール別概念マッピング表に照合し、無料/有料の境界線を引きます。

スケール別概念マッピング表（拡張版）

判定ルール

1. S3-S9: 無料部分で公開可
2. S5の数値実績: 無料部分で公開可（権威性の根拠）
3. S2以下: 有料部分に隔離（具体的な技術名、コード、手順）

例: Lighthouse記事の判定

---

ステップ3: 無料部分のリファクタリング（抽象化）

タスク: S1-S2の具体的表現を、S5以上の抽象表現に変換します。

言い換え辞書の適用（拡張版）

リファクタリング例

Before（具体的すぎる）:

フォント読み込み: -750ms JSバンドル: 257 kB → 260 kB に分割

• vendor-react: 201 kB
• vendor-remix: 51 kB
• vendor: 8 kB

After（抽象化）:

私はこの「構造的不自然さ」を解消するために、以下の3つの戦術を実行しました。

• 外部依存の完全排除: 外部CDNからのリソース読み込みを止め、ローカルでの制御下に置くことで大幅な遅延を短縮。
• レンダリング・ブロッキングの解消: 競合していたリソース読み込み優先度を再定義し、描画遅延を84%削減。
• 配信資産の最適化: 共通基盤と個別ロジックを分離し、キャッシュ効率を最大化。

その結果、Lighthouseで99点という、実用上の「完成形」に到達しました。

重要: 数値実績は残す

権威性の根拠として、以下は無料部分に残します：

• ✅ 「94点から99点へ」
• ✅ 「LCP 1.5s達成」
• ✅ 「遅延84%削減」
• ✅ Before/Afterの比較（数値のみ）

削除すべき内容

導入部から以下を完全削除します：

• ❌ 「開発の進捗」セクション（有料部分と完全重複）
• ❌ 「具体的なタスク」の詳細（Before/Current/Nextの繰り返し）
• ❌ 技術名称の羅列（Vite, @fontsource, layer2-commonなど）

橋渡し文の追加（必須）

目的: 無料部分の最後に、有料部分への期待感を高める「橋渡し文」を追加します。

配置場所: 無料部分の最後（freeContentHeading で指定した見出しの直後）

テンプレート（Geminiの戦略分析に基づく）:

以下の3要素を必ず含めてください：

1. AIの限界を突きつける

   • 「AIは〇〇を提案し続けます」
   • 「しかし、それは根本治療ではなく対症療法です」
   • 「AIが陥る〇〇ループ」

2. 根本原因の提示（抽象的に）

   • 「根本原因は〇〇ではなく、**〇〇という実行環境の『思想』**にありました」
   • 具体的な技術名は出さず、「実行タイミング」「アーキテクチャ」など抽象概念で語る

3. 有料部分の価値を「武器」として提示

   • 「ここから先は、AIが絶対に提案しない**『〇〇』**という解決策の全貌と、」
   • 「具体的な実装コード、〇〇の競合を乗り越えた技術的手順、そして実際の〇〇測定結果を、すべて公開します」
   • 時間と再現性の購入を強調

実装例（cloudflare-workers-shiki記事）:

CopyAIは「別のライブラリを試しましょう」と提案し続けます。しかし、それは根本治療ではなく対症療法です。
根本原因はライブラリではなく、**Cloudflare Workersという実行環境の『思想』**にありました。

ここから先は、AIが絶対に提案しない**『実行タイミングの主権委譲』**という解決策の全貌と、
具体的な実装コード、並列処理の競合を乗り越えた技術的手順、そして実際のパフォーマンス測定結果を、すべて公開します。

重要: 橋渡し文は**メタファー（比喩）**を活用し、技術的に詳しくない「バイブコーダー」にも直感的に理解できる表現にしてください。

---

ステップ4: 有料部分のリファクタリング（具体化）

タスク: 無料部分で削除した具体的な内容を、有料部分で展開します。

4-1: 重複の削除

有料部分から、無料部分で既に語られた内容を削除：

• ❌ 「開発の進捗」の Before/Current/Next（数値の繰り返し）
• ❌ 「具体的なタスク」の抽象的な説明部分

4-2: 具体的な武器の追加

無料部分で抽象化した内容を、実装可能なレベルで展開：

追加すべき内容:

1. 実名の解禁: Vite, @fontsource, layer2-common, preload

2. 実数値の提示: 750ms, 470ms, 257 kB, 200バイト

3. 実コードの公開:

   Copyimport "@fontsource/oswald/400.css";
   { rel: "stylesheet", href: "style.css" }
   

4. 実手順の詳細: ステップバイステップの実装ガイド

4-3: 導入文の追加（無料→有料の橋渡し）

有料部分の冒頭に、以下のような導入文を追加：

では、実際に私が記述したRemixのlinks関数の設定と、ViteによるJavaScript分割の具体的なコードを公開します。また、なぜ一般的な「CSSインライン化」が、今回のアーキテクチャでは毒になったのか。その検証データと、200バイトに絞り込んだ具体的なCSSの選定基準も解説します。

4-4: 有料部分を「武器（再現性）」として位置づける

目的: 有料部分を単なる「知識の提供」ではなく、時間と安定性を購入できる武器として提示します。

視点の転換:

• ❌ 「詳細な実装手順を解説します」
• ✅ 「この手順をコピーすれば、AIとの試行錯誤ループを回避し、初回から安定したデプロイを実現できます」

強調すべき価値:

1. 時間の節約: 「AIとの10時間の試行錯誤を30分に短縮」
2. 再現性の保証: 「検証済みの手順なので、同じ環境なら100%再現可能」
3. 技術的負債の回避: 「構造的に正しい実装なので、後で腐らない」

実装例:

有料部分の導入文や各セクションの冒頭で、以下のようなフレーズを挿入：

• 「このコードをそのままコピーすれば、ライブラリ交換ループに陥ることなく、初回デプロイから安定稼働させられます」
• 「私が3日かけて検証した設定パラメータを、ここで全て公開します。この値を使えば、競合問題を回避できます」
• 「この実装は、ClaudeMix本番環境で6ヶ月以上稼働している実証済みの構成です」

---

ステップ5: 最終チェック

リファクタリング完了後、以下を確認します：

5-1: メタデータフィールドの設定（freeContentHeading）

目的: ペイウォール実装に必要な freeContentHeading フィールドをFrontmatterに追加します。

タスク: 無料部分と有料部分の境界となる見出しを特定し、メタデータに記録します。

手順

1. 境界見出しの特定

   リファクタリング後の記事構造を確認し、どの見出し（h3/h4/h5）が無料部分の最後かを特定します。

   判定基準:

   • 無料部分（S3-S9の抽象的な内容）の最後の見出し
   • この見出しの次から有料部分（S1-S2の具体的な内容）が始まる
   • 通常は「課題と解決策」「3つの戦術」「改善の結果」などの見出しが境界になる

   例: Lighthouse記事の場合

   Copy### 私が実行した3つの戦術  ← 無料部分の最後
   
   ### やらなかったこと・その理由  ← 有料部分の開始
   

   この場合、境界見出しは「私が実行した3つの戦術」です。

2. Frontmatterへの追加

   記事の先頭にあるFrontmatterに freeContentHeading フィールドを追加します。

   追加例:

   Copy---
   title: "Lighthouse 99点の最適化戦略"
   date: "2025-01-09"
   category: "optimization"
   tags: ["lighthouse", "performance", "cloudflare"]
   freeContentHeading: "私が実行した3つの戦術"
   ---
   

   重要: 見出しのテキストを完全一致で記述してください（### などのMarkdown記号は不要）。

3. 検証

   以下を確認します：

   • freeContentHeading フィールドがFrontmatterに存在するか
   • 指定した見出しが記事内に実在するか
   • その見出しより前が無料部分（S3-S9）、後が有料部分（S1-S2）になっているか

既存記事のリファクタリング時の注意

既存記事にはこのフィールドがありません。リファクタリング実行時に、このステップで必ず追加してください。

チェックリスト

• 答えの早期漏洩がないか: 無料部分で仮説・解決策・技術選定理由を語りすぎていないか（ステップ1-4参照）
• 橋渡し文の品質: 無料部分の最後に、AIの限界・根本原因・武器としての価値を含む橋渡し文があるか（ステップ3参照）
• 無料部分に S1-S2 の具体的表現が残っていないか
• 無料部分の数値実績（権威性）は残っているか
• 無料部分と有料部分で同じ文章・表現が重複していないか
• 有料部分に具体的なコード・手順が含まれているか
• 有料部分の価値提示: 時間節約・再現性・技術的負債回避を強調しているか（ステップ4-4参照）
• 無料→有料の移行がスムーズか（導入文があるか）

検閲基準

無料部分を再度チェックし、以下の問いに答えます：

「この用語はS2以下か？」→ YES なら有料部分に移動

---

成果の切り出し（権威性を守る）

無料部分（S3-9）では、**「具体的な数字（Before/After）」**を権威性のエビデンスとして最大限に活用します。

---

まとめ: 権威性と秘匿性のバランス

スケール設計による、成果の扱い：

• S5（指標）: 改善後の数値（99点等） は無料で公開 → 権威性の根拠
• S3（主役）: 「何をしたか（フォント最適化等）」 という項目名までは無料で公開
• S2（要素）: 「どの技術（ライブラリ名等）」 を使ったかは有料
• S1（実体）: 「どう書いたか（コード・手順）」 は有料

---

リファクタリング実行時の注意

文体の維持

• ですます調を維持
• ClaudeMixとRemixはブランドとして前面に押し出す（汎用化しない）

メタファー（比喩）の活用

目的: 技術的に詳しくない「バイブコーダー」にも、直感的に理解できる表現を使います。

効果的なメタファー例:

使用方針:

• 無料部分の橋渡し文で、メタファーを積極的に使用
• 技術用語の説明では、メタファーを併記する（例: 「レンダリング・ブロッキング（競合状態）」）
• AIコーダー（特にバイブコーダー）が「あるある」と共感できる表現を選ぶ

横線の削除

blog-writerスキルで生成された記事には、セクション区切りに --- が使われていますが、これは削除してください（Frontmatterとの区切り以外では使用しない）。

見出し構造の維持

• ### (h3) から ##### (h5) を使用
• 見出し階層を崩さない

---

重要: このスキルは、blog-writer スキルで執筆された記事を対象としています。新規記事の執筆には使用しないでください。