技術ブログは自社ドメインとQiita・Zenn、どちらに置くべきか — GEO複利とコンプラで決めた理由

「技術記事はQiitaやZennに書いた方が読まれるのに、なぜ自社ドメインにブログを作るのか」——このブログ自体について、そう聞かれることがあります。結論から言うと、このブログはpolypost.dev配下のサブディレクトリに置いていて、Qiita・Zennへは必要な記事だけを個別に出すという形にしました。理由は、GEO（生成エンジン最適化）の効き目をどこに積み上げるかという判断と、コンプライアンス上の制約の2つです。

先に結論

自社ドメインを選んだ理由は次の3つです。

1. GEO複利を製品ドメインに集める — 記事が増えるほどpolypost.devというドメイン単位で被引用性・権威性が積み上がっていく方を取りたかった。Qiita・Zennに書けば個々の記事は読まれても、その"効き目"は媒体のドメインに乗る。
2. 媒体側の規約・上限に発信を振り回されたくない — Zennにはスパム条項があり、Qiitaにも自動化やプロモーション目的の投稿に対する制約がある（詳細はZenn・Qiita・note・dev.to・Xの媒体別まとめに書きました）。実際、Slipwayの公開告知ではZennへの投稿がレート上限に当たって後日回しになったこともあります。発信の頻度や中身を、自分でコントロールできる場所に置きたいと考えました。
3. 外部CMSを立てない — Ghost・WordPressのような別サービスを新たに運用に加えるのではなく、既存のNext.jsアプリにMDXで/blogを組み込みました。

高GEO媒体ほど自動投稿に敵対的、という前提

このブログの立ち位置は、私の持論とそのまま重なります。自動投稿そのものにはもう大きな価値はなく、価値は被引用性の側にある、という考えです。この持論を自分に当てはめると話は単純で、被引用性（GEO）が高い媒体ほど、実は自動化や大量投稿に対して構造的に敵対的です。Zennのスパム条項も、Qiitaのプロモーション投稿禁止も、突き詰めれば「機械的に量産された文章でドメインの評価を稼ごうとする行為」を防ぐための線引きです。つまり、GEOで強い場所ほど、外部から複利を借りることはできない仕組みになっています。

だとすれば、複利を借りるのではなく、複利を自分のドメインに積む方を選ぶのが筋が通っています。Qiita・Zennに書いた記事の被引用性は媒体のドメインの評価に寄与しますが、polypost.devの評価には直接は積み上がりません。逆に自社ドメインに書けば、1本1本が同じドメインの評価として複利で効いてきます。

実際の決定: コンテンツ資産化はQiita/Zennでなく自社ドメインに

これは開発中に実際に下した決定です。コンテンツ資産化の置き場所を検討したとき、Qiita・Zennではなくpolypost.dev/blogに置くと決めました。理由は、コンプライアンス（Zennのスパム条項に代表される、機械生成コンテンツへの各媒体の警戒）とレート制限、そしてGEOの複利を製品ドメインに積みたいという狙いの2つです。媒体に依存しない場所に本拠地を置いておけば、各媒体の規約が変わっても発信の土台自体は揺らぎません。

判断: GhostやWordPressを立てず、MDXを内蔵にした

自社ドメインに置くと決めたあとにもう一つ判断が必要でした。専用のブログCMS（Ghost・WordPressなど）を新しく立てるか、既存のNext.jsアプリにMDXでブログ機能を組み込むか、という選択です。私はGhost/WordPressを立てない方を選びました。

理由は3つあります。

1. 運用の尻尾がゼロで済む — 別サービスを立てると、そのぶんインフラ・アップデート・監視という運用の"尻尾"が増えます。既存アプリにMDXを足すだけなら、そのままVercelに乗るのでこの尻尾が発生しません。
2. GEOまわりを完全に自分で制御できる — schema.org・canonical・OGPといった、GEO監査の対象そのものを外部CMS任せにせず、製品コードと同じ形で管理できます。自分の製品でユーザーに提案していることを、まず自分のブログに全部適用できる状態にしておきたいと考えました。
3. 既存のPR運用がそのまま編集ゲートになる — AIが記事のドラフトをPRとして出し、私がレビューしてマージすれば公開される、という今のコード運用の仕組みを、そのまま記事の公開フローとして使い回せます。新しい編集システムを別に用意する必要がありません。

まとめ

自社ドメインを選んだのは、単に「独立したい」という気分の問題ではなく、GEOの複利をどこに積むかという構造的な判断でした。高GEO媒体ほど自動化に敵対的である以上、複利は借りるものではなく自分のドメインに積むものだと考えています。そのうえで、専用CMSを立てずMDXを選んだのは、運用の尻尾を増やさずに、製品と同じレベルでGEOを制御し、既存のPR運用をそのまま編集ゲートに使うためです。このブログ自体が、その判断の実物です。