2026年4月中旬からdev.toに67本の投稿を公開しました。最も読まれた記事は576ビューでした。それは謙虚な自慢ではなく、セキュリティ開発者が公開執筆を決意し、3ヶ月間毎日投稿し続けた正直な上限値です。華やかでない中間層を省略した「ブログの書き方」アドバイスの大半を避け、私が実際に経験したことと、手元にある本当の数字を整理してお伝えします。

意外だった数字

最もパフォーマンスが良かったのは、実践的なOllamaガイドでした。ハウツー記事です。ローカルでこのモデルを実行する、手順はこれ、WSL2で注意すべき点はこれ。576ビュー。

一方で、私が最も誇りに思っていた投稿、つまり「ほとんどの人が知らないスマートコントラクトのセキュリティ」に関する深い記事は、常に上位記事の約5分の1程度のトラフィックしか集めませんでした。1回限りではなく、繰り返し現れたパターンです。ローカルAIのハウツーが、セキュリティの深いコンテンツをビュー数で5対1程度で上回り続けました。

少し心が痛みましたが、そこから何かを学びました。私の専門知識は、ほとんどの読者が求めているものではありませんでした。彼らが求めていたのは「火曜日の問題」——「トークン料金を払わずに自分のマシンでモデルを動かしたいのにうまくいかない」という、ありふれた課題です。私はそれを明確に答えられる立場にいます。再入可能性（reentrancy）について語りたいのは私の好みであって、読者のニーズではありません。

教訓1：読者の火曜日の問題に向けて書く

セキュリティ記事は、すでにスマートコントラクトのセキュリティに関心があることを前提としています。それは小さな部屋です。一方、Ollama記事は「ノートPCを持っていて、少しイライラしている」という状況を前提としており、建物にいるほぼ全員が該当します。

セキュリティ記事を書くのをやめたわけではありません。書くのは、それが自分自身であり、やりたい仕事だからです。しかし、それが広く伝わることを期待するのをやめました。具体的な、一般的な、今すぐの問題を解決するコンテンツは広がります。すでにニッチな領域にいることを前提とするコンテンツは、どれだけ良くても広がりません。

教訓2：ニッチな専門知識には橋渡しトピックが必要

効果が出始めたのは次の工夫です。「人々が検索するもの」と「私が深く知っているもの」のどちらかを選ぶのではなく、それらを橋渡しすることです。「コードの臭いをトリアージするためにローカルモデルを動かす」といった投稿は、Ollamaという人気トピックの上に載りつつ、内部にセキュリティの視点を忍ばせています。Ollamaの部分がドアで、セキュリティの部分が私が実際に示したかった部屋です。

これで戦略全体の見え方が変わります。人気トピックは専門知識から目を逸らすものではなく、それを届けるための乗り物です。誰も「高度なオラクル操作パターン」をクリックしません。一方で「安価なローカルAIセットアップ」をクリックする人はたくさんいて、その場でセキュリティの考え方を1つ教えられれば、純粋なセキュリティ記事では決して起こらなかった成果になります。

教訓3：質問しない限り誰もコメントしない

長い間、コメントはほぼゼロでした。ビューやリアクションは時々ありましたが、沈黙が続きました。技術記事ではそういうものだと考えていました。

そこで、すべての投稿を1つの本気の質問で終えるようにしました。「ご意見をお聞かせください」といったノイズではなく、投稿に紐づいた具体的な質問です。「見知らぬ人からリポジトリが送られてきたときのデフォルトの対応は？」「コードを読む前に不変条件を書くか？」といったものです。するとコメントが来るようになりました。殺到とはいきませんでしたが、意見を持った人からの本物のコメントでした。

後から振り返ると当然の教訓でした。ブログ記事は、読者に明確にマイクを渡さない限り独白のままです。小さく具体的で労力の少ないきっかけを与えれば、人は参加します。漠然とした「どう思う？」は答えるのに負担が大きすぎます。的を絞った質問なら答えやすいので、人が答えてくれます。

教訓4：継続はモチベーションに勝る。だから自動化する

私は毎日投稿していますが、「書きたい気分」に頼っていません。下書きのキューと、次の記事を自動公開するcronスクリプトを使っています。「今日は投稿すべきか」という判断こそが、ほとんどのブログ執筆が死ぬ場所なので、その判断自体を削除しました。

仕組みは派手ではありません。下書きはフォルダに置き、スクリプトが次の1本を選んでdev.to API経由で投稿し、cronがスケジュールに従って実行します。おおよそ以下のようになります。

#!/usr/bin/env bash
set -euo pipefail

POSTS_DIR="$HOME/projects/pavelEspitia.github.io/posts"
NEXT=$(find "$POSTS_DIR" -name '*.md' -not -name '.*' | sort | head -n1)

[ -z "$NEXT" ] && { echo "queue empty"; exit 0; }

# publish $NEXT via the dev.to API, then move it out of the queue
publish_to_devto "$NEXT" && mv "$NEXT" "$POSTS_DIR/published/"
echo "published: $NEXT"

Enter fullscreen mode Exit fullscreen mode 

# one post a day at 9am, pulled from the queue
0 9 * * * /home/pavel/projects/pavelEspitia.github.io/publish-next.sh

Enter fullscreen mode Exit fullscreen mode

重要なのはコードではありません。モチベーションはスケジューラーとして最悪だということです。キューと自動化により、エネルギーがあるときにまとめて書き、今日の自分がやる気があるかどうかにかかわらず公開が行われます。3ヶ月間の毎日投稿は、根性から来たものではありません。毎日の選択を排除した結果です。

教訓5：配布は洗練に勝る

初期の投稿では、本当に時間をかけて磨き上げました。文を書き直し、構成に頭を悩ませました。しかし、それらは私のトップ記事ではありません。トップ記事は、人々が実際に検索しているトピックで、一貫して公開され、複数のプラットフォームにクロスポストされたものです。洗練は数字をほとんど動かしませんでした。トピックと継続性が数字を動かしました。

それは「下手に書け」という意味ではありません。限られた時間を「これは人々が探しているものか」「実際に彼らのいる場所へ届けたか」に充てる方が、「誰も気づかない文の4回目の推敲」よりも効果的だということです。明確で公開されたものは、完璧だがキューに残ったものに勝ります。

4月の自分に伝えたいこと

普通の火曜日に誰かが抱えている問題に向けて書くこと。人気トピックを、あなたの本当の専門知識が生きる部屋へのドアとして使うこと。読者から本気の質問で締めくくり、記事を会話に変えること。公開をスクリプトに任せて気分を支配させないこと。そして、あなたのお気に入りの記事と最も読まれた記事はしばしば別物であり、それはそれで構わないと受け入れること。

67本の投稿を経て、複利効果は控えめですが確かに存在します。バイラルでもなく、巨大なフォロワーでもありませんが、存在する作品群、レールの上を走る習慣、そして「読者が自分に何を求めているか」についての、より明確な理解が得られました。

技術記事を書いている皆さんへ：あなたが誇りに思っている記事を静かに上回っているトピックはありますか？それを活かしていますか、それとも抵抗していますか？