はじめに — 同じ日に出した2つの記事、結果は10倍以上の差
技術記事を外部プラットフォームに出そうと決めたとき、Qiita と Zenn の両方に同時に投稿しました。
Qiita には「Claude Codeで10日間に82個の無料Webツールを作った開発プロセス」。Zenn には「Supabase RLS設計パターン集」。どちらも自分の開発経験をベースにした記事で、品質には自信がありました。
結果は予想外でした。Qiita は投稿10分で70ビュー、翌日には415ビュー。Qiitaのメルマガにも掲載されました。一方の Zenn はほぼ無風。いいねもほとんどつかず、自サイトへの流入もゼロ。
この差が何を意味するのか。2日間かけて分析した結果、「PMはどのプラットフォームでどう勝負すべきか」という根本的な問いに答えが出ました。
背景 — なぜ技術プラットフォームに出ようと思ったのか
きっかけは、ZERONOVA LABのコンテンツが自サイト内に閉じている問題でした。Journalに67本、Focus Blogに58本の記事があり、88個の無料ツールも公開済み。コンテンツ量は十分なのに、届いていない。
2月19日の開発日記にはこう書きました。
プロダクト露出不足の課題を分析（「コンテンツではなくディストリビューションが足りない」という診断）
74個の無料ツールでSEO流入を増やした戦略と同じ発想で、今度はQiitaとZennのドメインパワーを借りて検索リーチを広げようと考えました。自サイトの記事をそのまま転載するのではなく、プラットフォームの読者に合わせて再構成する方針です。
準備 — ガイドラインを「投稿前」に作った理由
過去の経験から、「走りながらルールを整える」のは非効率だと分かっていました。noteへの投稿では最初の数本をガイドなしで出し、後からフォルダ構造やチェックリストを整えるという手戻りがありました。
そこで今回は、1本目の投稿前に3つのドキュメントを作りました。
- 投稿ガイド（
tech-platform-guide.md）: プラットフォーム比較、記事配置指針、導線設計 - チェックリスト（
tech-platform-checklist.md）: 12カテゴリの公開前チェック - 記事管理フォルダ（
docs/tech-articles/）: 下書き・公開済みの管理構造
canonical URL が使えないという発見
準備段階で最も重要な発見がありました。
canonical URL 戦略: Qiita・Zenn いずれもユーザー定義の canonical URL に非対応という重要事実を調査で発見。コンテンツを50%以上再構成して重複回避する方針を策定
当初の計画は「Journal記事をそのまま転載し、canonical URLで正本を自サイトに指定する」というものでした。これなら工数は最小で済みます。しかし調べてみると、QiitaもZennもユーザーが自由にcanonical URLを設定する機能がない。
これは戦略の根幹に関わる発見でした。そのまま転載すれば重複コンテンツになり、Googleの評価がどちらのサイトにも付かない最悪の結果になりかねません。方針を「50%以上の内容を再構成する」に転換し、技術解説に特化した構成に作り変えることにしました。
結果的に、このコンテンツ差分化はプラットフォームの読者に最適化するという副次的なメリットも生みました。Journalの開発ストーリーや対話セクションを省き、コード例と設計パターンを中心に据えた構成は、技術プラットフォームの読者が求めるものにより近くなったのです。
6本の下書きとプラットフォーム振り分け
準備が整ったところで、6本の記事を一気に書きました。
Qiita向け（AI×個人開発プロセス系）:
- Claude Codeで10日間に82個の無料Webツールを作った開発プロセス
- 82個のWeb検査機能を16コマンドのMCP Serverに凝縮してnpm公開するまで
- AIと2週間で60本の技術記事を書いた方法
Zenn向け（Next.js/Supabaseコードベース系）:
- Supabase RLS設計パターン集
- Next.js App RouterでSEO最適化する実践ガイド
- Next.js APIルートのSSRF対策
この振り分けには明確な意図がありました。Qiitaは個人開発やAI活用のプロセス系記事が受ける傾向があり、Zennは Next.js や Supabase のようなフレームワーク系の技術記事が受ける傾向がある。プラットフォームの読者層に合わせた配置です。
PM-AI 対話: 記事振り分けの判断
ZeronovaZeronovaこの最後のClaude Codeの指摘が、後から見れば正確な予見でした。
初投稿 — Qiitaの手応えとZennの沈黙
Qiita: 投稿10分で70ビュー
Qiitaへの初投稿は2月20日。「Claude Codeで10日間に82個の無料Webツールを作った開発プロセス」を公開し、投稿キャンペーン「生成AIを使ってみてどうだった？」にも登録しました。
投稿して10分ほどで70ビュー。自サイトの新規記事では考えられないスピードです。Vercel Analyticsでも qiita.com からの流入が11ユニーク訪問者、14PV（リファラーの16%）と、自サイトへの導線が機能していることを確認できました。
翌日には415ビューに到達。さらにQiitaのメルマガで「個人開発」タグの新着記事セクションに掲載されました。
Qiita のドメインパワーは強い: 投稿当日に70 viewsは、zeronova-lab.com の新規記事と比べてリーチが格段に速い。プラットフォームの既存ユーザーベースとキャンペーンの効果
メルマガのランキング上位にはLGTM 100超えの記事が並び、Claude Code関連の個人開発記事が複数ランクインしていました。AI×個人開発というテーマの注目度が高いことを実感しました。
ちなみに、Qiitaの自動ツイート機能は使わない判断をしました。X投稿ガイドラインの「URLは自己リプライに分離する」ルールと衝突するためです。文面もコントロールできないので、手動で投稿するほうがエンゲージメントを最適化できます。この判断はX投稿ガイドラインで確立した原則に従ったものです。
Zenn: ほぼ無風
同じ日にZennにも「Supabase RLS設計パターン集」を投稿しました。こちらは自分のリアルな開発経験から得た設計パターンをまとめた、コードベースの技術記事です。
結果はほぼ無風。いいねもほとんどつかず、自サイトへの流入もゼロ。Qiitaとの差は歴然でした。
分析 — なぜZennで響かなかったのか
2月21日、Qiitaの415ビューとZennのほぼゼロという数字を前に、原因を分析しました。
最初は「記事の品質が低かったのか」「タイトルが悪かったのか」と考えましたが、それは表層的な問題です。根本原因はもっとシンプルでした。
Zennの読者層と自分のポジションのミスマッチです。
Zennの読者は現役のバックエンドエンジニアやインフラエンジニアが多い。Supabase RLSの設計パターンは、彼らが日常的に扱う領域です。PMが書いたSupabase記事は、その領域の専門家と正面から競合することになり、権威性で見劣りします。
一方、Qiitaでは事情が違いました。「PMがClaude Codeで82個のツールを作った」というストーリーは、エンジニアにとっても新鮮な視点です。PMがAIを使ってどれだけのことができるのかという問いは、多くのエンジニアが関心を持つテーマでした。
つまり、同じ「技術記事」でも、自分の強みが活きる場所とそうでない場所がある。
決断 — Zennを保留し、Qiitaに集中する
分析の結果、明確な決断を下しました。
Zennは保留。Qiita週2本に集中する。
Zenn向けに書いていた下書き2本（SSRF対策、SEO完全ガイド）もQiita向けに転換することにしました。月2本だった投稿ペースを週1〜2本に引き上げ、125本のソース記事を活かして継続的に発信します。
この決断の背景にある考え方を、こう整理しました。
「エンジニアとして勝負する」のではなく、「PM × AI という独自ポジションで届ける」方が自分のブランドに合っている。
振り返れば、Zennに純技術記事を出したこと自体が少しブレていたのかもしれません。ZERONOVA LABは「AIネイティブ実験スタジオ」を掲げており、PMがAIと協業してプロダクトを作るプロセスこそが差別化ポイントです。著者ペルソナをドキュメント化したのも、この一貫性を守るためでした。
Supabase RLSの設計パターンは技術的に正確な記事です。しかし、それを書くのは自分でなくてもいい。「PMがAIで82個作った」というストーリーは、自分にしか書けない。プラットフォーム選びとは、結局「自分にしか出せない価値はどこで最も届くか」という問いなのだと気づきました。
E-E-A-T対応 — 技術プラットフォームでの活動をSEOに変換する
投稿と並行して、QiitaとZennでの活動をGoogle検索のE-E-A-T（経験・専門性・権威性・信頼性）シグナルに変換する対応も行いました。
具体的には、AboutページとトップページのJSON-LD構造化データの sameAs にQiitaとZennのプロフィールURLを追加しました。Googleが著者の同一性を認識し、技術プラットフォームでの活動を権威性のシグナルとして評価できるようにするためです。
一方、記事末尾のAuthorCardにはQiita/Zennのリンクを追加しない判断をしました。リンクが増えるとCTAが希釈されるためです。AuthorCard → /about → 各プラットフォームという階層構造にすることで、詳しく知りたい人だけが辿れるようにしました。
この判断はE-E-A-T改善を個人開発サイトに実装した際の経験が活きています。構造化データは視覚的なリンクを増やさなくても、Googleには伝わるのです。
学び — プラットフォーム戦略の5つの教訓
2日間の体験から得た教訓を整理します。
1. プラットフォームの読者層と自分のポジションを照合する
Zennの読者（純エンジニア）に向けて技術記事を書いても、PMとしての権威性ではバックエンドエンジニアに勝てません。自分の強みが「独自の切り口」になるプラットフォームを選ぶべきです。
2. canonical URLの事前調査は必須
QiitaもZennもcanonical URLのユーザー定義に非対応。これを調べずに転載していたら、重複コンテンツ問題を引き起こしていました。プラットフォームの仕様は思い込みで判断せず、事前に確認すること。
3. ガイドラインは「最初の投稿前」に作る
投稿を始めてからルールを作ると、既に出した記事との一貫性が取れなくなります。ガイド・チェックリスト・管理フォルダの3点セットを先に整備してから投稿を開始したことで、最初から品質を担保できました。
4. 投稿ペースは柔軟に見直す
当初の計画は月2本でしたが、125本のソース記事があり再構成が中心のため保守的すぎました。実際に投稿してみて工数を実感した上で、週1〜2本に引き上げました。
5. 自動共有より手動投稿
Qiitaの自動ツイート機能は便利ですが、X投稿ガイドラインのURL分離ルールや文面コントロールと衝突します。エンゲージメント最適化の観点では手動投稿が有利です。
まとめ — 「どこで勝負するか」は「何者か」で決まる
Qiita・Zenn初投稿の体験は、プラットフォーム選びがコンテンツの品質以上に結果を左右することを教えてくれました。
同じ品質の記事でも、Qiitaでは415ビュー、Zennではほぼゼロ。この差は記事の良し悪しではなく、「そのプラットフォームの読者にとって自分の記事が独自の価値を持つかどうか」で決まります。
82個のツールを10日で作った話は、PMがAIと協業することで何ができるかという問いに答える記事です。これはエンジニアにも刺さるし、PM・ディレクター層にはなおさら刺さる。一方、Supabase RLSの設計パターンは、より専門的なエンジニアが書いたほうが読者にとっての価値が高い。
自分が「PM×AI」というポジションである以上、そのポジションが独自性になるプラットフォームで勝負する。当たり前のことですが、実際に失敗してみないと腹落ちしない教訓でした。
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。