ブログ雛形を実装ではなく実際の記事から作り直した話
ブログ記事の雛形を整えていて、実装済みのCSSクラス一覧から組み立てたら、実際の運用とズレていることに気づきました。結局、既存の公開記事から本物の構造を抜き出して作り直すことに。今日はその経緯と、そこから得た気づきを書き残します。
そもそも何の話か
npcブログ（このブログ）の記事用の雛形を整えていました。自社テーマには、ブログ記事の見栄えを整えるためのカスタムCSSクラスが実装してあって、「ここは比較表」「ここは番号付きのポイント」「ここは手順フロー」と判断して使い分けると、ただの段落の連発より読みやすくなります。
記事を毎日自動生成する仕組みも動かしているので、その自動生成に「このパターンが出てきたらこのクラスを使ってね」と教えるための、いわば作法書のようなものを整えていた、というのが今日の作業です。
※「CSSクラス」とは、HTMLの見た目を切り替えるための名札のようなものです。タグに名札を付けておくと、その名札ごとに「枠を付ける」「色を変える」といった見栄えのルールを当てられます。
最初の雛形：実装済みクラスをそのまま並べた
最初は、自社テーマのCSSファイルを開いて「実装されているクラスを全部書き出して、それぞれの想定用途を整理して」とClaudeに頼みました。返ってきたのは、クラス名・想定用途・HTMLの形が一覧になった、見た目の整った雛形です。一見、ちゃんとしているように見えました。
この雛形を自動生成のフローに組み込んで、何本か記事を作ってみました。出来上がった下書きを眺めて、なんとなく違和感がありました。形式的には正しいのに、自分のブログの普段の調子と微妙に違うのです。
つまずき：実装と運用がズレていた
違和感の正体を探って、過去に自分が公開した記事と、自動生成の下書きを並べて見比べてみました。すると、いくつか具体的なズレが見えてきました。
つまり、雛形に書かれていた「実装上の使い方」と、実際に自分が運用している記事の構造が、ところどころで食い違っていたわけです。雛形は実装の網羅としては正しいけれど、現場の運用は写せていなかった、ということでした。
やり直し：本物の運用記事から構造を抽出
方針を切り替えました。実装ファイルからではなく、実際に公開してある自分の記事3本を選んで、そこから本物の構造を抜き出してもらうことにしました。
Claudeにはこうお願いしました。「この3本の記事をすべて全文読んで、実際に使われているクラスとパターンを抜き出して。実装ファイルは見なくていい。本文だけを根拠にして」。-pのような短いお願いではなく、現物を読みに行くように明確に指示しました。
返ってきた抽出結果と、もとの雛形を見比べると、差分が具体的に見えてきました。
並べてみると、雛形の役割がはっきりしました。雛形は実装の見本帳ではなく、自分の運用そのものを写したものであるべきだったのです。
気づき：実装と運用は別物だった
当たり前のようでいて、自分でつまずいてみるまで分かっていなかったことがあります。「実装されている」と「実際に使っている」は別物、ということです。
テーマや仕組みの側に何かが用意されていても、運用の中で実際にどう使われているかは別の話です。雛形やスタイルガイドを書くときに、実装側だけを見て一般化すると、現場と乖離した「使われない理想」が出来上がってしまいます。今回はそれを地で踏みました。
もうひとつ、AIへの頼み方の気づきもありました。「整理して」とだけ頼むと、AIは手元にある材料（この場合はCSSファイル）からきれいに整理してくれます。けれど、それが現場と合っているかは別問題です。整理してもらうときは、整理の材料そのものを指定する。今回は「実装ファイルではなく公開記事3本を根拠にして」と明示することで、現場に寄った雛形が返ってきました。
これは今後、ほかの作法書や手順書をAIに整理してもらうときにも効きそうな考え方です。AIに何を読ませるかで、出てくるものの性格が変わる。当然と言えば当然なのですが、自分のブログでつまずいて、ようやく腑に落ちました。
同じことで困っている方へ
スタイルガイドや雛形を整えているのに、なぜかしっくりこない、自分の書く文章と浮いている気がする、という感覚があれば、一度、実装側ではなく実際に運用している記事を3本以上、AIに通読してもらって構造を抜き出してもらうのをおすすめします。
「これだけ実装してあるんだから、こう使えるはず」という一般論ではなく、「自分はいつもこう書いている」という現物の写しのほうが、結局は使いやすい雛形になります。今回作り直した雛形には、最後に「推測で改変しない・既存の運用記事を3本以上確認してから書く」というルールを書き添えておきました。
同じところでつまずく人が減れば、うれしいです。