技術記事の執筆を自動化する｜devlog→記事の二段パイプライン

技術記事を書く時間がなかなか取れないのは、開発が終わってから素材を思い出そうとするからである。解法は書く時間を捻出することではなく、開発中に素材が自然に残る構造を作ることだと考えている。本稿は、開発セッションの終わりに判断とハマりを構造化して記録し、書きたくなったときにスキルが媒体別の記事へ変換する二段パイプラインを、実運用のスキル定義で解説する。

二段方式の設計 — 開発時は devlog だけ

パイプラインは二段に分かれる。前段（Stage A）は開発、後段（Stage B）は執筆で、両者を時間的に切り離すのが要点だ。

Stage A では、開発セッションの終わりに /devlog や /devlog-session といったコマンドを一発打つだけで記録を残す。書くのは文章ではない。その回で下した判断（採用案と却下案）、ハマった事象（症状・原因・解決・検索語）、効いた委譲プロンプト——key_decisions・pitfalls・prompts の3系統の構造化データが、そのまま次の記事の骨になる。この段階では一切執筆しない。

Stage B は、書きたくなったときに初めて動く。スキルが devlog を一次ソースとして読み、指定した媒体の記事に変換する。

執筆と開発を分ける理由は、執筆時間を別に確保するためではない。記憶が新しいうちに素材を確保するためである。なぜその設計にしたか、何で詰まってどう抜けたかは、開発の直後なら数分で書けるが、数週間後には失われている。文章化という重い作業を後段へ寄せ、前段では事実と判断だけを機械的に落としておく。こうすると、発信のコストは「書く時間」ではなく「開発の終わりの数分」に変わる。

article-forge の構成

後段を担うのが article-forge という自作スキルである（スキルの仕組み自体は別稿で扱う）。プロジェクト固有のワークフローなので、横断利用のスキルとは分けて開発リポジトリの .claude/skills/ に同梱し、同じものを複数のプロジェクトで運用している。

起動はトリガー記述で決まる。SKILL.md の description はこうなっている。

_articles/_devlog 内の devlog を Qiita / Zenn / note 向けの記事に変換する。「〜のQiita記事を作って」「Zenn記事にして」「note用にまとめて」「記事化して」等で起動する。

「記事化して」と打つと起動し、対象の devlog を読んで指定媒体の記事を1本生成する（起動が description に依存する仕組みは 2026-07-16 時点、Claude Code v2.1.211 で確認）。媒体の指定が無ければ Qiita を既定にする。

変換で肝になるのが redact 規約である。devlog には受託や未公開の情報が混じりうるため、redact: true を付けた要素は媒体ごとに開示の深さを変える。Qiita・Zenn では概念説明に留め、実物のアセットは載せない。note では <APP_ID> のような伏字にしつつ「ここに何が入るか」は説明する。そして顧客情報・キーは、全文を渡す note でさえ完全に削除する。機密を段階的に開示する設計であり、無料媒体へ実物を出さないことを仕組みで保証している。

出力先も媒体ごとに分かれる。Qiita と Zenn はそれぞれの CLI が要求する frontmatter 付きで書き出し、note は貼り付け用に生成する。

プラットフォーム別の差別化 — 再スライス

3媒体に同じ内容を言い換えて出すのではない。スキルの定義にはこう書いてある。

3媒体は「言い換え」ではなく 素材の再スライス で差別化する。同じ pitfalls を Qiita と Zenn で使い回さない（Google の重複判定で検索流入が削れるため）。

同じ素材を、切り口を変えて分配する。媒体の役割は次のように設計されている。

媒体	役割	主素材	アセット開示
Qiita	検索流入の入口	pitfalls を1件	概念のみ
Zenn	ファン化	key_decisions の流れ	一部抜粋まで
note	課金	prompts+artifacts実物+rejected+ops	全文

Qiita は検索から入る読者のハマりを概念で解き、Zenn は判断の流れでファンを作り、note は実物と捨てた案まで全文を渡す。無料2媒体の末尾からは、より深い内容として Zenn・note へ内部誘導する。

重複を避けるのは編集の美学ではなく集客の実利である——同一素材の使い回しは検索流入そのものを削る。だから差別化は文章のリライトではなく、素材の再スライスで行う。

自サイトとの棲み分け

同じ devlog を素材に、この hub と外部媒体の両方へ記事を出す以上、もう一段の棲み分けが要る。

役割を固定している。hub は体系化した恒久版——手法のリファレンスとして updated を運用し、更新し続ける。外部は個別事例版——1プロジェクトの時系列ナラティブで、末尾から hub の恒久版へ誘導する。

公開順も決めている。hub を先に出してインデックスを確認してから、外部へ事例版を出す。逆にすると、ドメインの強い外部が先に拾われ、審査の主体である hub 側が複製コンテンツに見えてしまう。

そして、いま読んでいるこの記事群自体が、その運用の実証である。恒久版を hub に置き、事例は外部へ——本稿もその設計に従って公開している。

よくある質問

devlog に何を書くか。 未来の自分が検索する語（search_terms）まで書く。書くのは事実と判断であって、文章ではない。数週間後の自分が同じ現象を検索し直せる語を残すのが肝である。骨格は開発の履歴から起こし、過去のセッション記録を1本ずつ読んでハマりを継ぎ足す——一度に完全生成しようとするとコンテキストが尽きるので、段階的に積む。

量産すると品質は落ちないか。 変換後の記事も、通常どおり検証とゲートを通す。コード例を実物と照合し、機械検証で不一致を止める仕組みは別稿で扱った。生成を速くすることと、公開前の関門を省くことは別である。原因が同根のハマりを別々の記事にすると検索意図が被るので、切り口を絞って片方はリンクで逃がす——その判断も devlog にメモしておくと迷わない。

まとめ

発信が続かないのは、書く時間が無いからというより、素材が開発の直後に失われるからだ。だから前段の devlog で判断とハマりを機械的に残し、後段の article-forge で媒体別に再スライスする。同じ素材を使い回さず、hub は恒久版・外部は事例版と役割を分け、hub を先に公開する。書く時間を作るのではなく、素材が残る構造を作る——それがこのパイプラインの狙いである。