技術ブログの有料化：無料記事と有料コンテンツの線引きをどう設計したか

はじめに

ちらりんブログは、自宅の NUC×3 + Proxmox クラスタで動いている個人技術ブログです。Hugo で静的生成して、Cloudflare Tunnel で外部公開しています。

構成紹介シリーズとして12本の記事を書いてきたのですが、ある時点で「これ、有料コンテンツにできるのでは」と考え始めました。この記事では、既存の無料記事をどう整理して、何を無料に残し、何を有料に回したのか——その設計判断のプロセスを全部書きます。

「技術ブログの有料化」に興味はあるけど、具体的に何をどう分けたらいいか分からない、という人の参考になれば嬉しいです。

前提：ほぼ誰にも見られていなかった

有料化を考え始めた時点でのアクセス状況を先に共有します。

Nginx の docker logs を分析した結果がこれです。

• 期間: 公開から9日間
• 外部からの実ユーザーアクセス: 33件
• Google 検索流入: ゼロ

正直に言うと、ほぼ誰にも見られていませんでした。

ただ、これがむしろ好都合でした。「既存読者への影響」を気にする必要がない。つまり、思い切った再構成が可能だということです。アクセスが伸びてから有料化しようとすると「前は無料だったのに」という反発が出ます。誰も見ていない今こそ、コンテンツの構造を設計し直す最高のタイミングでした。

2つの方針：追加型か、分離型か

有料化にあたって、2つの方針を検討しました。

方針1：追加型（既存記事はそのまま）

既存の無料記事には一切手を入れず、追加で有料コンテンツを作る方式です。

• メリット: 既存記事に影響なし、読者からの反発ゼロ
• デメリット: 無料記事に設定ファイル全量が丸出しのまま残る。有料コンテンツを別途ゼロから作る必要がある

方針2：分離型（既存記事を再構成）

既存記事から「設定ファイル全量」「再現手順」を抜き出して有料コンテンツに移す方式です。

• メリット: 既存記事の具体的な設定がそのまま有料コンテンツになる。無料記事は「設計思想の解説」として洗練される
• デメリット: 既存記事の改修が必要。バランスを間違えると無料記事が読めないゴミになる

私は方針2を選びました。

理由は単純で、アクセスデータが「今なら影響がない」と教えてくれたからです。33件のアクセスで Google 検索流入ゼロの状態なら、記事構造の再設計に伴うリスクは事実上ゼロです。それに、既存記事には docker-compose.yml の全量や Prometheus の設定ファイルがそのまま載っていたので、これをわざわざ別の有料コンテンツとして書き直すのは二度手間でした。

核心の原則：「なぜ」は無料、「どうやって」は有料

12本の構成紹介記事を1本ずつ読み返して、内容を3つのカテゴリに分類しました。

分類基準

この分類をやっていて、はっきりと1つの原則が見えました。

「なぜ」は無料、「どうやって」は有料。

つまり——

• 設計思想・考え方・判断理由 → 無料で公開する（信頼構築 + SEO の武器）
• 設定ファイル・コマンド・再現手順 → 有料にする（これが「金になる」情報）

技術記事を読む人が本当に欲しいのは「コピペで動く設定ファイル」です。設計思想だけ読んでも、実際に手を動かすときには設定ファイルが必要になる。だからこそ、設計思想で信頼を作り、設定ファイルで課金する。この構造が自然に成立します。

具体例で見る線引き

物理・仮想基盤編（🟡 黄）の場合：

• 無料に残す: 「NUC×3 で Proxmox クラスタを組む理由」「VLAN で管理NW と VM用NW を分ける設計思想」「デフォルトGW を .254 で統一する理由」
• 有料に移す: VLAN番号・サブネット・IP配布方式の完全な対応表、/etc/network/interfaces の設定ファイル

Docker 本番サービス化編（🔴 赤）の場合：

• 無料に残す: 「nginx + cloudflared + remark42 の3点セット構成とその理由」「ホスト再起動後に自動復帰する設計」
• 有料に移す: docker-compose.yml の全量、各サービスの設定ファイル、systemd ユニットファイル

監視基盤 Part1 設計思想編（🟢 緑）の場合：

• 全部無料: 「何を監視するか」「なぜこの構成にしたか」は設計判断の話なので、そのまま

読者の立場で考えると、無料記事だけでも「この人はちゃんとした設計をしている」「自分もこの構成でやりたい」と思えるし、実際に構築するなら有料コンテンツで設定ファイルを手に入れるのが合理的——という流れになります。

導線設計：B+C ハイブリッド方式

有料コンテンツへの導線は、地味だけど重要な設計ポイントです。Hugo は静的サイトなので、記事の途中で「ここから先は会員限定」とリアルタイムに出し分ける実装は簡単ではありません。

3つのパターンを検討しました。

パターンA：記事内ゲート方式

記事の途中に「ここから先は有料」のウォールを入れる。note や Zenn のプロ向け記事でおなじみのやつです。

• メリット: 読者の体験として自然
• デメリット: Hugo（静的サイト）での実装が難しい。認証・課金状態の判定をクライアントサイドでやる必要がある

パターンB：記事末尾リンク方式

記事本文はそのまま、末尾に「有料コンテンツはこちら」のリンクを置く。

• メリット: 実装が極めてシンプル（shortcode 1つで済む）
• デメリット: 記事を読んでいる途中で「ここに本来あった設定ファイル」が抜けている感覚になる

パターンC：シリーズ目次ハブ方式

シリーズ全体の目次ページを作り、無料記事（🟢）と有料コンテンツ（🔒）を一覧で見せる。

• メリット: 全体像が見える。何が無料で何が有料か一目瞭然
• デメリット: 目次ページまで来てくれないと導線が機能しない

採用：B+C ハイブリッド

私は B と C を組み合わせました。具体的にはこの3層構造です。

第1層：記事本文中のインライン案内

設定ファイルを削除した箇所に、「この設定ファイルの全量は有料コンテンツに含まれています」というインライン案内を入れます。Hugo の box-paid shortcode で実装しました。

これにより、読者は「ここに本来何があったか」「それがどこで手に入るか」を記事の文脈の中で理解できます。

第2層：記事末尾の案内ボックス

記事の最後に paid-content shortcode で案内ボックスを配置。「シリーズ目次を見る」と「購入する」の2つのボタンを置いています。

記事を最後まで読んだ人は、設計思想には満足しているはずなので、「この設定ファイルも欲しい」と思っている確率が高い。そのタイミングで案内を出します。

第3層：シリーズ目次ハブページ

無料記事12本（🟢）と有料コンテンツ10点（🔒）を一覧で並べた目次ページを作成しました。このページの役割は「全体像の提示」と「有料コンテンツの価値の可視化」です。

無料記事で検索流入した読者は → 記事本文中のインライン案内で有料コンテンツの存在を知り → 記事末尾のボックスか目次ページで全体像を把握し → 購入ページに遷移する。この導線です。

実際の作業フロー

「設計は分かったけど、実際にどう手を動かしたの？」という話をします。

Step 1：全記事バックアップ

まず記事ファイル（Markdown + 画像）のバックアップを取りました。方針2（分離型）は既存記事を改修するので、いつでも元に戻せる状態を作っておくのが大前提です。

Step 2：アクセスログ分析

Nginx の docker logs を集計して、どの記事にどれだけアクセスがあるかを確認しました。結果は前述の通り、外部からの実ユーザーアクセス33件、Google 検索流入ゼロ。この数字が方針2を選ぶ決定打になりました。

Step 3：12記事の個別分析

記事を1本ずつ開いて、以下をチェックしました。

• 設定ファイル（YAML, TOML, conf 等）がそのまま掲載されていないか
• コマンド列がそのままコピペで再現可能か
• 削除しても文脈が壊れないか

この分析で 🟢 / 🟡 / 🔴 の分類が決まりました。

Step 4：実設定との突き合わせ

ここが意外と重要でした。記事を書いた時点の設定と、現在の実設定にはすでに乖離がありました。記事を書いた後にも改善を続けていたので、設定値が変わっている箇所がいくつかあったのです。

有料コンテンツは「現在の実設定ベース」で提供するため、記事から抜き出すだけでなく、実機の設定を改めて取得し直しました。

Step 5：無料版ドラフト作成

🟡（黄）と 🔴（赤）に分類された9本の記事について、設定ファイル・再現手順を削除した無料版ドラフトを作成。削除箇所には box-paid shortcode でインライン案内を配置しました。

ここで最も気を使ったのは、無料記事だけで文脈が成立するかです。設定ファイルを抜いた結果、前後のつながりが意味不明になっていないか。各記事を通しで読んで確認しました。

Step 6：有料コンテンツリポジトリ整備

有料コンテンツ用のリポジトリを整備して、現在の実設定をベースにファイルを配置しました。API トークンやパスワードなどのシークレットはプレースホルダー（YOUR_API_TOKEN_HERE 等）に置換しています。

Step 7：シリーズ目次ページ + shortcode 作成

シリーズ全体の目次ページと、paid-content shortcode / box-paid shortcode を作成しました。Hugo の shortcode は HTML テンプレートで実装できるので、認証やサーバサイド処理は不要です。

Step 8：PR でレビュー

全変更を GitHub の PR にまとめて、差分を確認してからマージしました。12記事×2（無料版 + 有料版）の変更なので、PR の diff はそれなりに大きくなりましたが、1つの PR で一気にやった方が全体の整合性を確認しやすかったです。

価格設計

有料コンテンツの価格は以下のように設計しました。

設計意図

3ヶ月の損益分岐点を意識しています。

• サブスク3ヶ月: 980 × 3 = 2,940円
• 買い切り: 2,980円

つまり3ヶ月以上使うならサブスクがお得。1つのシリーズだけ欲しいなら買い切り。この分かりやすさが大事です。

会員 Grafana：サブスク限定の解約防止フック

サブスクリプションの差別化ポイントとして「会員 Grafana」を用意しました。本物の Proxmox クラスタ・Docker コンテナの監視ダッシュボードを、リアルタイムで閲覧できる体験です。

これはサブスクを継続する理由になります。設定ファイルは一度ダウンロードすれば手元に残りますが、会員 Grafana はサブスク期間中しかアクセスできません。「リアルタイムの監視データ」は鮮度が価値なので、継続課金と相性が良いのです。

設定ファイルだけでは足りない——目指しているもの

正直に言うと、設定ファイルの提供と会員 Grafana だけでは、有料コンテンツとしてまだ弱いと思っています。

私が本当にやりたいのは、エンジニア同士が実際に動くシステムを通じて交流できるプラットフォームを作ることです。

開発したシステムを実際に触れる場

記事で紹介しているシステムを、読者が実際に触って動作を確認できるようにしたい。設定ファイルをダウンロードして自分の環境で再現するだけでなく、私の環境で動いているものをそのまま体験できる——これが既存の技術メディアとの最大の違いです。

クラウドでは面倒な実験ができるオンプレ基盤

私が持っているオンプレ基盤（NUC×3 クラスタ + Cisco 実機）では、クラウドでは気軽にできない実験ができます。VLAN 設計の変更、Proxmox のライブマイグレーション、Cisco 実機のコンフィグ変更とパケットキャプチャ——こうした「手を動かして確かめる」環境を、会員の皆さんと共有していきたいと考えています。

IT の「何でも相談所」

プレミアムプランの月1回 IT コンサル（1H）はその第一歩ですが、将来的にはもっとカジュアルに IT に関する何でも相談ができるコミュニティにしていきたい。「自宅サーバの構成を見てほしい」「Docker の監視設計を相談したい」——そういう場です。

Qiita との違い

Qiita や Zenn は優れた情報発信プラットフォームですが、あくまで「記事を読む」場です。私が目指しているのは、記事を読んだ先に実装が動いている状態を見られる場。設計を学び、設定ファイルで再現し、本物の動作を確認する——この「読む → 作る → 確かめる」のサイクルが、このプラットフォームの核になると考えています。

スマートホームシリーズは有料化しなかった

ブログにはもう1つ、スマートホーム関連の記事シリーズがあります。こちらは有料化しませんでした。

理由は明確です。

• 公式ドキュメントや他ブログで情報が豊富: Home Assistant や Nature Remo の設定方法は、検索すればいくらでも出てくる
• 「コピペで再現できるコード」がない: 環境ごとに設定が異なるため、設定ファイルの「全量提供」に価値が薄い
• SEO 集客に使える: スマートホームは検索ボリュームがあるので、無料記事として残して検索流入の入り口にする方が合理的

有料化の判断基準は「その設定ファイルに再現性があるか」です。自宅サーバの構成（NUC + Proxmox + Docker + 監視基盤）は汎用性が高く、設定ファイルをそのまま使える人が多い。一方、スマートホームはデバイスや間取りに依存するので、設定ファイルの再現性が低い。

失敗しうるポイント

最後に、この設計で気をつけるべきリスクを3つ挙げておきます。

1. 無料記事だけで文脈が成立するか

設定ファイルを削った無料記事が「何を言いたいのか分からない記事」になっていないか。これは最も注意したポイントです。

私の対策は、削除箇所にインライン案内を入れることと、無料記事を通しで読み直すことでした。インライン案内があれば「ここに設定ファイルがあったんだな」と読者が理解できるので、文脈の断絶を最小限に抑えられます。

2. 有料コンテンツが「古い設定」にならないか

記事を書いた時点の設定と実設定が乖離する問題は、有料化すると深刻度が上がります。無料記事なら「古い情報かも」で済みますが、お金を払って古い設定を渡されたら不満になります。

対策として、有料コンテンツは記事の内容ではなく現在の実設定ベースで作成しました。さらに、設定を変更した際には有料コンテンツも更新する運用フローを組んでいます。

3. 無料記事の SEO 価値が下がらないか

設定ファイルを抜くと、記事のボリュームが減ります。ボリュームが減ると SEO に不利になる可能性があります。

ただし、SEO で重要なのは「検索意図への合致度」であって単純な文字数ではありません。「Proxmox クラスタ 構成」で検索する人が知りたいのは設計思想と構成概要であって、/etc/network/interfaces の中身ではない。設計思想をしっかり書いた無料記事は、むしろ検索意図に合致しやすくなると私は考えています。

まとめ

やったことを整理します。

1. アクセスデータを根拠に、既存記事の再構成（方針2）を選択した
2. 「なぜ」は無料、「どうやって」は有料の原則で12記事を分類した
3. B+C ハイブリッド（インライン案内 + 末尾ボックス + 目次ハブ）で導線を設計した
4. 現在の実設定ベースで有料コンテンツを整備した
5. 会員 Grafana をサブスクの解約防止フックとして設計した
6. 設定ファイル提供にとどまらないプラットフォーム（実環境体験・IT相談・エンジニア交流）を目指す方向性を定めた

ポイントは「無料記事だけでも価値がある状態を保つ」こと。無料記事は信頼構築と SEO の武器であり、有料コンテンツへの導線でもある。無料と有料は対立するものではなく、互いに価値を高め合う関係です。

技術ブログの有料化を考えている人は、まず自分の記事を「なぜ（設計思想）」と「どうやって（設定・手順）」に分解してみてください。その分解ができれば、線引きの設計は自然と見えてきます。