ホームラボで複数の技術を並行学習していると、蓄積した検証ログは手間をかけなければそのまま埋もれます。
本記事では、第 1 回で示した「パターン 5: 検証から発信へ」の深掘りとして、HomeLab\logs\ に蓄積したログを Cowork のカスタムスキル homelab-log-to-blog で Gutenberg ブロック HTML に変換し、WordPress 編集画面に手動コピーするまでのフローを整理します。
WordPress 直接投稿の自動化は本記事のスコープ外とし、手動コピー＆ペーストを終点とします。
目次
記事素材として機能する検証ログの条件 — #02〜#05 の記録術を振り返る
Cowork で記事を生成する前に、手元のログが記事素材として機能する状態にあるかを確認する必要があります。第 2 回で確立した HomeLab\{_memory, iac, logs, docs}\ というフォルダ構造は、記事素材の収納場所として設計されています。
第 3 回で固定した logs/<技術>/YYYY-MM-DD-<keyword>.md のフォーマット（目的・実行コマンド・出力・エラー・仮説・次にやること）は、Cowork が読み解きやすい構造になっています。
第 4 回で示した tofu plan / tofu apply 出力ログと Ansible Playbook の実行記録の蓄積手法は、「やってみた」「設計判断」系の記事に直接使える素材を生みます。
第 5 回のシーン 5「カフェ — 検証ログをブログ下書きに変換する布石」では、Dispatch で docs/blog-drafts/ にトピック候補を保存することを予告しました。本記事はその伏線を回収するフローになります。
記事化に向く 3 系統のログ
蓄積したログは記事の方向性によって 3 系統に分類できます。それぞれに向いているログの特徴を整理しておくと、スキルへの入力指示が明確になります。
| 系統 | 向いているログ | 典型的な素材 | 技術例 |
|---|---|---|---|
| ハマりログ系 | エラー → 原因 → 再発防止のサイクルが明確 | エラーメッセージ・仮説・解決コマンド | kubeadm init 失敗、Payara JDBC プールエラー |
| やってみた系 | 操作手順と出力が順序立てて残っている | 実行コマンド・出力抜粋・設定ファイル | GCP Cloud Run 初デプロイ、k3s クラスタ構築 |
| 設計判断系 | 「なぜそうしたか」の理由が仮説セクションに残っている | 仮説・IaC コード差分・次にやること | OpenTofu の変数化判断、Ansible role 分割の基準 |
VMware VCF9（Mode C: ドキュメント学習中心）については、検証ログより公式ドキュメントを下敷きにした要約・用語整理が記事素材として機能しやすいです。その場合は Cowork より NotebookLM のブリーフィング資料や学習ガイドを起点にする方が合っている局面が多いです。
本記事では Payara・Kubernetes（Mode A）と GCP（Mode B）のログを中心に例示します。
月次サマリスキルとの役割分担
第 3 回で導入した monthly-learning-summary スキルと本記事の homelab-log-to-blog スキルは補完関係にあります。月次サマリは「自分の学習進捗を可視化する内向きの出力」であり、ブログ記事は「読者に伝える外向きの出力」です。
月次サマリで整理された「解決したエラーと再発防止策」を、そのまま記事の根拠としてスキルに渡せます。
homelab-log-to-blog スキルの設計 — SKILL.md 1 ファイルから始める
スキル（Skill）の使用は全プランで可能ですが（スキルが動く「code execution（コード実行）」機能の有効化が前提）、カスタムスキルのインストールは Pro 以上が前提になります（Claude Help Center「Use Skills in Claude」「How to create custom Skills」, 2026-05-03 確認）。Free プランでは長いプロンプトを毎回貼る方法で近い出力を得られますが、再現性が下がります。
本記事は Pro / Max の個人プランを主軸に進めます。
ポイント: カスタムスキルのインストールは Pro 以上
スキルの呼び出し自体は全プランで可能ですが、自作の SKILL.md をインストールして使えるのは Pro / Max の個人プランに限られます。Free プランでは毎回のプロンプトに制約を貼る方法で近い出力を得られますが、再現性と運用コストの面で差があります。本シリーズでは Pro / Max を前提に進めます。
SKILL.md の構成と name 制約
SKILL.md は先頭に YAML frontmatter を置き、その後に Markdown 本文で手順・出力テンプレートを記述します。name フィールドはディレクトリ名と完全一致させる必要があります。
名前規則は 64 字以下・小文字英数字とハイフンのみ・予約語（anthropic / claude）は使用不可です（第 4 回の iac-review スキルと同じ制約）。
スキルのディレクトリ名を homelab-log-to-blog と決めたら、SKILL.md の name: homelab-log-to-blog もそれに一致させます。この一致が取れていないとインストール時にエラーになります。
SKILL.md サンプル全文
---
name: homelab-log-to-blog
description: |
HomeLab の検証ログ（logs/<技術>/YYYY-MM-DD-*.md）を読み込み、
Gutenberg ブロック形式の WordPress 記事 HTML と SEO メタ情報を生成する。
「ブログ記事にして」「記事化して」「このログを記事にして」と依頼されたときに呼び出す。
出力先は HomeLab\docs\blog-drafts\YYYYMMDD-.html。
---
## 入力
- `logs/<技術>/YYYY-MM-DD-*.md`（1 ファイルまたは複数ファイルを指定）
- `docs/<技術>/_lessons.md`（あれば参照して根拠として使う）
## 出力形式
### SEO メタ情報（必須）
出力の先頭に以下を付与する。
```
pn_meta_title: "<タイトル>" # 20〜32字（必ずカウント確認）
pn_meta_description: "<説明>" # 80〜120字
slug: "<記事スラッグ>"
```
### Gutenberg ブロック HTML
以下のブロックのみを使う。それ以外のブロックやショートコードは使わない。
| 用途 | ブロック |
|--------------|----------------------------------|
| 本文段落 | wp:paragraph |
| 見出し | wp:heading (level 2〜4) |
| コマンド・設定 | wp:code |
| 手順 | wp:list (ordered) |
| 比較表 | wp:table |
| 強調ボックス | wp:group + pn-note クラス |
### 使用禁止リスト
以下は出力に含めない。
- ショートコード: [box], [timeline], [tab], その他すべての [*] 形式
- wp:shortcode ブロック
- Font Awesome v5/v6 記法 (fas fa-*, fab fa-*, far fa-*)
- インライン style タグ（<style>...</style>）
- WordPress カスタム CSS フィールドで禁止の記法: :root, :has(), fr 単位, コメント内 HTML タグ
### Font Awesome の使用ルール
v4 記法のみ有効: `fa fa-check`, `fa fa-exclamation-triangle`, `fa fa-lightbulb-o` 等
### SEO 字数チェック手順
1. pn_meta_title の文字数をカウントする
2. 32 字を超えていた場合は削って再カウントする
3. pn_meta_description の文字数をカウントする
4. 80 字未満または 120 字超の場合は調整してから出力する
## 記事構成ガイドライン
- リード文（120〜180 字）: 読者の課題提起 + 本記事で分かること
- H2 は 4〜5 本
- 各 H2 の冒頭に論点の要約 1〜2 文
- H3 でステップや観点を分割
- コードブロックは原文からの引用部分に限定し、Cowork による推測・補完部分を明示的に分ける
## 事実誤認防止
- ログの「実行コマンド」「出力（抜粋）」「エラーメッセージ」セクションの内容は事実として扱う
- 「仮説」セクションの内容は「検証時の仮説として」と明示する
- ログに記録がない操作について断定しない（「2026-05-XX 時点で確認できない」と記す）
- 認証情報・IP アドレス・サービスアカウント名はダミー値またはプレースホルダーで出力する
## 出力保存
生成した HTML を表示した後、`HomeLab\docs\blog-drafts\YYYYMMDD-.html` への書き込み確認を求める。承認後に書き込む。
作成したら Claude Desktop の「Customize > Skills」でインストールし、スイッチを ON にします。
インストール時の手順は skills/homelab-log-to-blog/SKILL.md というディレクトリ構造を用意し、そのフォルダをインストール対象として指定します（Anthropic 公式スキルリポジトリ github.com/anthropics/skills の各ディレクトリ構成が参考になります）。
Gutenberg ブロック出力テンプレを SKILL.md に書き込む — テーマの制約を AI に守らせる
Cowork は SKILL.md に明示した制約を素直に追従します。ポイントは「禁止リストを SKILL.md 側に明文化する」ことで、毎回のプロンプトで制約を伝え直すコストをなくすことにあります。
ここでは前節の SKILL.md の中で特に重要な 3 点を補足します。
6 種のブロックを使い分ける
本シリーズが記事の公開先として想定するのは、WordPress に自作テーマ「PersonalNote」を組み合わせたブログです。ショートコードで装飾すると、Gutenberg ブロックエディタと組み合わせたときに wpautop（WordPress が段落を自動補正する処理）の干渉で表示が崩れます。加えてショートコードはテーマを替えた時点で未登録になり、文字列がそのまま画面に出ます。
そのため本シリーズ全体でショートコードを使わず、ブロック記法で完結させる方針を取っています。
| ブロック | 記法例 | ホームラボ記事での典型用途 |
|---|---|---|
| wp:paragraph | <!-- wp:paragraph --> | 通常の本文段落 |
| wp:heading | {"level":2}〜{"level":4} | セクション見出し |
| wp:code | <pre class="wp-block-code"><code> | コマンド・HCL・YAML・設定ファイル |
| wp:list | {"ordered":true} / 通常 | 手順リスト / 箇条書き |
| wp:table | {"hasFixedLayout":true} | 比較表・設定値一覧 |
| wp:group + pn-note | {"className":"pn-note pn-note--warn"} | 注意ボックス・ポイント強調 |
Font Awesome v4 のみが有効
テーマが読み込む Font Awesome はバージョン 4 のみです。SKILL.md に「fas fa-*（v5/v6 記法）は表示されない。
fa fa-* 記法のみ使うこと」と明記しておくと、Cowork が v5 記法を出力するミスを防げます。本文で使えるアイコンの代表例は fa fa-exclamation-triangle（警告）・fa fa-lightbulb-o（ポイント）・fa fa-check（完了）です。
SEO メタ情報を自動生成する
テーマは pn_meta_title と pn_meta_description を投稿メタとして読みます。入力先は投稿の編集画面 → 右サイドバーの「SEO」パネルです。pn_meta_title は 20〜32 字・pn_meta_description は 80〜120 字が目安です。
SKILL.md の「SEO 字数チェック手順」セクションに字数カウントの手順を明記することで、Cowork が出力後にカウントして調整してから提示するフローを作れます。
ポイント: WordPress への投稿は手動コピー＆ペーストが終点
WordPress 公式コネクタは Anthropic が提供する 12 種類の MCP コネクタに含まれますが、これは WordPress.com 寄りの仕様であり、自前で運用するインストール型 WordPress には直結しません。本記事では Cowork が生成した Gutenberg HTML を WordPress 管理画面の「カスタム HTML ブロック」または「コードエディタ」に貼り付けて投稿する方法を終点とします。
生成下書きの保存と運用 — 個人 GitHub / 個人 Drive / ローカルの 3 択
スキルが生成した Gutenberg HTML はどこに保存するか。安定性と操作コストの観点から、3 つの選択肢を優先順に整理します。
第一選択: ローカルの HomeLab\docs\blog-drafts\
最も安定した保存先は、フォルダスコープ（Folder Scope）内にある HomeLab\docs\blog-drafts\ です。Cowork がフォルダスコープとして参照しているため、生成後に確認を求めてきた際に承認するだけで保存が完了します。
第 5 回のシーン 5 でこのフォルダに保存したトピック候補（docs/blog-drafts/YYYY-MM-topics.md）も、このフォルダ内に収まる設計です。
ファイル命名は YYYYMMDD-<slug>.html を推奨します。WordPress の記事スラッグと合わせておくと、後から内部リンクの一致確認が楽になります。
第二選択: 個人 GitHub リポジトリへの保存
個人 GitHub コネクタは OAuth で個人リポジトリにアクセスし、ファイルブラウザで対象ファイルやフォルダを絞り込めます（Claude Help Center「Using the GitHub Integration」, 2026-05-03 確認）。ブログドラフトを Git で管理したい場合は、個人リポジトリに blog-drafts/ ディレクトリを用意して保存する形が使えます。
push / commit は code execution 経由で実行可能ですが、本記事では「下書きをリポジトリに保存する」用途に絞ります。CI/CD パイプライン（GitHub Actions で WordPress に自動投稿するフロー等）は本記事のスコープ外です。
第三選択: 個人 Google Drive への保存
注意: 個人 Drive のみ。Shared Drive は不具合報告あり
個人 Google Drive への保存は code execution 経由のファイル書き出しで実用範囲にあります。一方、Google Workspace の Shared Drive（共有ドライブ）については「ファイルが表示されない」「OAuth 完了後にトークン交換が安定しない」という不具合がユーザー報告レベルで挙がっています（2026-05-03 時点）。個人ブログの下書きに Shared Drive は使わないため影響はありませんが、誤って Shared Drive を選択しないよう注意が必要です。
3 つの保存先をフローとして整理すると次のようになります。
- スキルで Gutenberg HTML を生成します（内容を画面で確認）
HomeLab\docs\blog-drafts\YYYYMMDD-<slug>.htmlへの書き込みを承認します（第一選択）- 必要に応じて個人 GitHub リポジトリにも push します（第二選択）
- WordPress 管理画面の「コードエディタ」または「カスタム HTML」ブロックに貼り付けて投稿します（終点）
スキルを動かして記事を生成する — 実際の操作フロー
スキルのインストールが完了したら、実際に記事生成を依頼します。ここでは Kubernetes の検証ログから「ハマりログ系」記事を生成する例を示します。
1 本のログから記事を生成する依頼例
homelab-log-to-blog を使って、以下のログから技術記事ドラフトを生成して。
入力: logs/kubernetes/2026-05-02-kubeadm-init-fails-cgroup.md
参照: docs/kubernetes/_lessons.md（cgroup 関連エラーのセクションを重点的に）
記事系統: ハマりログ系（エラー → 原因 → 再発防止）
想定文字数: 2,500〜3,500 字
slug: k8s-kubeadm-cgroup-error-2026複数ログを横断して 1 本の記事にまとめる依頼例
homelab-log-to-blog を使って、今月の GCP ログ群から「やってみた」系記事を生成して。
入力: logs/gcp/2026-05-*.md（今月分の全ファイル）
参照: docs/gcp/_lessons.md
記事系統: やってみた系（操作手順 + 結果 + 学び）
想定文字数: 3,000〜4,000 字
slug: gcp-cloud-run-first-deploy-2026複数ファイルを横断する場合、Cowork はフォルダスコープ内のファイルを一覧取得してから個別に読み込みます。ファイル数が多い場合（10 本以上）は月次サマリ（monthly-learning-summary）で先に整理してからスキルに渡すと、Cowork が混乱しにくいです。
生成結果の確認と人間レビューの前提
スキルが出力した HTML は「下書き」として扱います。Cowork がログから補完した箇所（ログに明示されていない操作の説明など）は、SKILL.md の「事実誤認防止」セクションに従って推測であることが明示されますが、最終的な事実確認は書き手自身が行います。
WordPress 管理画面に貼り付ける前に、少なくとも次の 3 点を確認します。
- コードブロック内のコマンドが実際に試したものと一致しているか確認します
- pn_meta_title が 20〜32 字に収まっているか確認します
- ショートコードや
fas fa-*記法が混入していないか確認します
スケジュールタスクで週次記事化フローを設定する（発展形）
記事生成を手動で都度依頼するだけでなく、スケジュールタスク（Scheduled Task）の weekly 頻度で「今週のログからブログ記事候補をリストアップして docs/blog-drafts/YYYY-WW-topics.md に保存する」という前段タスクを自動化できます。
週次タスクはあくまでも「記事になりそうなトピックの候補整理」に留め、完成 HTML の自動生成は人間の判断で起動する形を維持するのが現実的な運用です。全自動生成にすると、確認していない記事が blog-drafts に溜まって管理が煩雑になります。
スケジュールタスクは PC 起動前提
スケジュールタスクは PC が起動かつ Claude Desktop が起動している状態でのみ実行されます。週末に PC を立ち上げない習慣がある場合は manual 頻度で手動実行に切り替えるか、第 5 回の keep-awake トグルと組み合わせて PC を常時起動状態にする運用を検討します。
まとめと次回予告
本記事で整理したフローを振り返ります。
- 第 2〜5 回で示した記録術で蓄積する
logs/・docs/・IaC コードが、記事素材として機能する条件を整理しました homelab-log-to-blogカスタムスキル（SKILL.md 1 ファイル）で「ログ入力 → Gutenberg HTML + SEO メタ情報」の変換を定型化できます（インストールは Pro 以上）- SKILL.md の「使用禁止リスト」にショートコード・
wp:shortcode・Font Awesome v5/v6 記法を明記することで、Cowork が出力時点で制約を守ります pn_meta_title20〜32 字・pn_meta_description80〜120 字の SEO メタ情報を SKILL.md 側に字数チェック手順として組み込みました- 保存先の第一選択はローカルの
HomeLab\docs\blog-drafts\。個人 Drive への保存は code execution 経由が現実的で、Shared Drive は不具合報告があるため個人 Drive に絞ります - WordPress への投稿は手動コピー＆ペーストが終点です。自前で運用するインストール型 WordPress には公式コネクタが直結しないためです
次回の第 7 回「NotebookLM × Cowork × Claude Code × Antigravity 使い分けマップ + 業務外で武器を磨く 5 原則」では、本シリーズを通じて登場してきた 4 ツールをどう使い分けるかを統括します。検証ログの記事化という文脈では、Cowork と Claude Code の役割の違いも整理する予定です。
