はじめに — 「60本の記事を2週間で」は量産か、それとも
2026年2月1日にZERONOVA Journalをローンチしてから約2週間で、61本の技術記事を公開しました。Supabase RLSの設計パターン、PWAオフラインキュー、OAuth認証の罠、個人開発の運用術。テーマは多岐にわたります。
「量産」と聞くと品質を犠牲にしているように聞こえるかもしれません。しかし実態は違います。すべての記事は開発日記（devlog）という一次情報を元に書かれています。6つのプロダクトを開発する中で書き溜めた日々の記録——悩み、試行錯誤、エラーメッセージ、意思決定の理由。これらが「記事の素材」として大量にストックされていたからこそ、2週間で60本が可能でした。
この記事では、devlogからJournal記事への変換プロセスと、Claude Codeとの協業で品質を担保した方法を紹介します。
仕組みの全体像 — devlog → パイプライン → 記事
ZERONOVA Journalの設計思想は明確です。
Journal は開発日記（devlog）を素材として、編集・構成した公開コンテンツを掲載する
2月1日の開発日記にこう書きました。76件のdevlogを分析し、8つの開発ストーリーと50以上の技術記事のアイデアを抽出しました。このアイデアを journal-content-pipeline.md で管理し、idea → planned → drafting → published のステータスで追跡します。
2階層コンテンツモデル
記事は2つの階層に分かれています。
| 階層 | 名称 | 工数 | 例 |
|---|---|---|---|
| Tier 1 | 開発ストーリー | 3-5時間 | CancelNavi開発記、Wakulier開発記 |
| Tier 2 | 技術記事 | 1-2時間 | Supabase RLS設計パターン、JWT罠 |
Tier 2の技術記事は、1つのdevlogの「悩んだこと」セクションをベースに、背景→問題→解決→学びのストーリーで構成します。devlogにエピソードが記録済みなので、「何を書くか」で悩む時間がほぼゼロでした。
「想像で書かない」ルール
Journalの執筆で最も重要なルールがあります。devlogを読まずに記事を書かないこと。
パイプラインのタイトル案だけを見て、想像で記事を書く → NG
最初の数本を書いたとき、パイプラインのタイトル案だけを見て記事を書いてしまいました。結果は抽象的で一般的な内容になり、読者への説得力が弱い記事になりました。
たとえば「Supabase Auth + Next.js App Routerで認証が切れる問題」の記事。devlogには「BandBridgeの本番環境で翌日にセッションが消える」という具体的なエピソードが記録されていました。このエピソードを引用して構成すると、記事の説得力がまったく変わります。
この教訓から、執筆前チェックリストに「該当するdevlogをすべて読んだか」を必須項目として追加しました。
AI協業の表現設計 — Level 1とLevel 2
60本の記事すべてに共通する要件が「AI協業の可視化」です。この判断の背景は「開発記事でAIとの協業をちゃんと書くことにした理由」に書きました。ZERONOVA LABは「AIネイティブ実験スタジオ」を標榜しています。記事の中でAIの関与が見えなければ、ブランドコンセプトと矛盾します。
PM-AI 対話: 表現レベルの設計
ZeronovaZeronovaブランドコンセプトと記事表現の一貫性は意識しないと乖離する
この表現設計を全61本に適用しました。表現レベルの詳しい背景と設計判断は「個人開発で「著者ペルソナ」をドキュメント化した理由」で解説しています。結果として、Level 2（対話セクション）が全記事に最低1箇所含まれ、技術選定や設計判断のリアルなプロセスが見える構成になっています。対話セクションはチャット風UIに自動変換される仕組みです。
週次レビューの自動化
記事の「ネタ切れ」を防ぐ仕組みも作りました。GitHub Actionsが毎週日曜9:00 JSTに実行され、新しいdevlogがあればIssueを自動作成します。
Issueには新規devlogの一覧と、各devlogの「記事ネタメモ」が含まれます。このIssueを見て、パイプラインに新しいアイデアを追加する——というサイクルが回っています。
判断基準はシンプルです。
- 複数プロダクトで共通するテーマ → 高優先度
- devlog内で「記事にする」と記載されたもの → 高優先度
- ユニークな体験・知見 → 中優先度
- 一般的な技術Tips → 低優先度
品質チェックリスト — 60本でもブレない基準
量産で品質を維持するために、公開前レビューのチェックリストを整備しました。
必須項目として7つを定めています。
- devlogRefsに記載したファイルをすべて読んだか
- devlogからの引用（
>ブロック）が最低1つ含まれているか - 具体的な日付、エラーメッセージ、意思決定の理由が含まれているか
- プライバシーガイドラインに準拠しているか（GitHubユーザー名、実ファイルパスの匿名化）
- タイトルと内容が一致しているか
- frontmatter（title, description, date, tags, devlogRefs）がすべて記載されているか
- Level 2（Zeronova × Claude Code対話セクション）が最低1箇所含まれているか
devlog の記述を引用（
>ブロック）として記事に含める。「YYYY年MM月DD日の開発日記にはこう書きました」のような導入を使う
PM-AI 対話: チェックリストの設計方針
ZeronovadevlogRefs が空の記事はビルド時に警告を出す仕組みも考えられます。Zeronovaこのチェックリストのおかげで、Claude Codeでも人間でも同じ基準で品質を確認できます。「属人的な判断」が入る余地がないのがポイントです。
コード比率ガイドライン
もう一つ重要なルールが「コード比率30%以下」です。Journalは技術ブログですが、読み物として書いています。コードを並べるだけなら公式ドキュメントで十分です。
目標構成比率はこう設定しています。
| 要素 | 比率 | 役割 |
|---|---|---|
| 導入（問題提起） | 15% | なぜこの話をするのか |
| 背景・経緯（ストーリー） | 30% | 記事の主役 |
| 解決策（コード含む） | 35% | コードは最小限、補足として |
| 学び・考察 | 20% | 読者が持ち帰れる教訓 |
「コードなしでも記事の骨子が伝わるか」が判断基準です。コードブロックは1つ20行以下、記事全体で30%を超えないようにしています。
60本の記事が生んだ副次効果
60本の記事を書いたことで、想定外の効果がいくつかありました。
プロダクト詳細ページの関連記事セクション: Focus BlogとJournalの記事が充実したことで、各プロダクトの詳細ページに「関連記事」が自動表示されるようになりました。CancelNaviのページにはCancelNavi開発記が、IdeaSpoolのページにはAIタグ付けの記事が表示されます。
内部リンクネットワークの強化: 60本の記事間で相互リンクを張ることで、サイト全体のSEO評価が向上する効果が期待できます。
devlogを書く習慣の強化: 「devlogが記事のネタになる」という実感が生まれたことで、日々のdevlogに「悩んだこと」「試行錯誤」を丁寧に書くようになりました。この習慣の効果は「開発日記を書く習慣で記事ネタが尽きなくなった話」でも書いています。
学んだこと
60本の記事を2週間で書いた経験から学んだことをまとめます。
一次情報の蓄積が最強の資産: devlogという「日々の記録」が大量の記事を支える基盤になりました。記事を書き始めてから素材を集めるのではなく、素材が先に蓄積されている状態を作ることが重要です。
チェックリストは量産の品質保証: 人間もAIも同じ基準で確認できるチェックリストがなければ、60本の品質を維持するのは不可能でした。
創作禁止は意外と難しい: AIは文章を面白くするために、devlogにないエピソードを「補完」しようとすることがあります。「事実でないことを事実として書かない」という原則を徹底するには、明示的なガイドラインが必要です。
量産は目的ではない: 60本という数字自体に価値はありません。価値があるのは「6つのプロダクト開発で得た知見を体系化した」ことです。devlogという断片的な記録を、テーマ別に再構成して公開するプロセスに意味があります。
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。