「技術ブログを書け、PVを伸ばせ」と言われたあなたへ
ども！1年間AIと一緒に活動してきた龍ちゃんです。
「技術ブログを書け、PVを伸ばせ」
会社からそう言われているエンジニア、いませんか？文章書くのは苦痛で、タイトルの付け方もメタディスクリプションの書き方もマーケの話も全然わからない。
先に、この記事で渡したいものだけ。個別のTipsでも「AIがすごい」って話でもなくて、文章が苦手なエンジニアでも、ネタ切れせずにブログを続けられる仕組みです。検証から公開までの全工程を、ひとつのパイプラインとして見せます。タイトルもマーケも苦手なまま始められますよ。
これだけ「苦手」と言っておきながら、「この1年でAI活用が一番進んだ業務は？」と聞かれたら、答えはブログなんですよね。書き方も、昔は「やったことを順に書く実装ログ」だったのが、今は「読者のつまずきを起点に、検証結果を証拠として置く」形に変わりました。同じ人間が書いてるのに、です。AI活用の集大成として、今回まとめることにしました。
ちょうど1年前にも「これが僕の執筆環境です」という記事を1本書いてるんですけど、そこから工程ごとに道具を足し続けた結果が、今回話すパイプラインです。
大事にしている考え方は2つあります。
- 検証してから書く。ネタを探してから書くのではなく、検証した結果が記事になる。だからネタに詰まらない
- 道具を使い捨てず仕組みに沈める。便利な使い方をその場限りにせず、次も使えるように残す
順番に説明していきますね。
検証・調査からはじまる、Claude Codeで組んだパイプラインの全体像
まずざっくり全体を見てもらいます。
全工程にAIが居ます。調査もアウトライン作りも公開前のチェックも図もサムネも、どこを切ってもAIが何かやってます。ただ、執筆だけ役割が反転します。他の工程はAI主導で人間が確認するイメージなんですが、執筆だけは人間主導でAIが補助に回る。なぜそうなるのか、は後半で回収しますね。
なお、この記事に出てくる research-searcher みたいな名前は、それぞれ役割を持たせたAIに付けた呼び名です（僕は Claude Code の skill とサブエージェントで組んでます）。名前は覚えなくて大丈夫なので、「何をする担当か」だけ追ってもらえればOKです。あと、これ全部を自作しないと始まらない話でもないです。普段使ってるAIに同じ役割を振るだけでも回ります。
もう1つ前置きを。7工程のうち5つ（アウトライン / 執筆 / 公開前チェック / 図・サムネ / タイトル・SEO）は、それぞれ単独の記事で深掘りしてあります。なのでこの記事では、その5工程は「何をする工程で、なぜその形にしたか」と、さらっとしたコツだけを置いておきます。気になる方はぜひ個別記事も読んでみてください。
工程ごとに、上流から歩いてみる
工程は7つ。順に見ていくと、AIへの任せ方が工程ごとに違うのが見えてくると思います。
検証してから書く。だからネタ切れしない
ブログの起点は「ネタ出し」じゃないんですよね。「検証・調査」なんです。
「よくネタが尽きないね？」って聞かれることがあるんですが、答えはシンプルで、自分の中に1つルールがあって。検証した内容を基本的にブログ化するってことを守ってます。
何か気になる技術があって、実際に手を動かして、「あ、こういう結果になった。これはブログにする価値があるな」と判断してから書く。逆に、ネタだけ考えて実装なしで「仮想のブログ」を書こうと思えば書けるんですけど、個人的にそれをやったら終わりだなと思ってて。技術ブログとして動くものを提供できる状態を維持することは、最低限守ることにしてます。
ここで効いてくるのが、検証する場所と記事を書く場所が同じリポジトリにある、という構成です。気になったら即AIに調べさせて「放置案件」を作らない。調査の品質を /research で揃えてから書き始めると、書いてる途中で主張がブレなくなる。そうやって手を動かした結果は、docs/research や docs/experiment にメモとして溜まっていきます。検証と執筆が地続きだから、検証した結果がそのまま記事の素材になるんですよね。
で、ネタの話なんですけど。溜まった検証メモを横断検索すると、「これ1記事になるな」という種が自然と立つんですよ。ここはSkill×サブエージェントで調査を速く回す構成にした専用のエージェント（調査メモを横断検索する research-searcher や、過去のブログを照合する blog-searcher）に探させてます。だから僕の中に「ネタを探すフェーズ」って実はないんですよ。むしろ逆で、検証したことがネタになるんだから、検証していないことはそもそも記事にならない。ネタは探すものじゃなくて、検証から生まれるものなんです。そう捉えると、手を動かして検証を続けている限り、「ネタ切れ」という状態そのものが起きなくなるんですよね。「ネタを探す」は「自分の活動の振り返り」に近いかもしれません。
いきなり書かず、アウトラインで勝負を決める
ネタが決まったら、次はアウトラインです。誰に・どの検索で届く記事か・どの角度で書くかを、本文を書く前に決めきる工程ですね。少しマーケティング的知識を入れておきます。
書く前に決めきる理由は単純で、「誰に届ける記事か」の設計は執筆より上流でしか機能しないからです。書き始めてから「あ、読者像ずれてたな」となると直すのが本当に大変なので。あと、ここで「うーん、わざわざ書くほどでもないな」となった記事を、1文字も書かずに畳めるのも大きいです。
この工程のコツを1つ。アウトラインが「方法をN個並べる」形になったら、1記事に詰めるのをやめて分けたほうがいいです。見るのは、並べた方法どうしで読者に要求する思考が同じかどうか。「読者のペインが同じ」はまとめる理由になりません。実はこのシリーズがまさにそれで、最初は1本に詰めるつもりだったのが、工程ごとに読者へ要求する思考が違いすぎて5本に割れました。あと量の目安として、アウトラインは50〜60行で止めてます。超えたら本文を先食いしてるサインで、執筆が「アウトラインの清書」になるんですよね。
アウトラインを先に作ることで、前提知識などが見えてくることがあります。そういった「自分は知っている」けど、みたいな情報に気づくとまたそれも新規のブログネタになるという感じですね。あとは分量が増えたら分割みたいなこともとれるので、時間がなくてもサクッとアウトラインだけ作るのはおすすめです。AIと話して作ればそんなに時間もかからないですしねw
そのアウトラインをAIにレビューさせる話（狙う角度を探す担当と、読者の代弁をする担当の2体）は、別記事に書きました。
執筆は、素材を渡して下書きを作り、最後は自分の目で通す
執筆は、ここまでで溜めた検証メモ・調査・過去記事を素材として渡して、文体を担当するAI（writing-stylist）に下書きを起こさせる工程です。音声入力でしゃべった内容を素材に混ぜることもあります。
ただ1個だけ、あえて仕組みに「落とさない」ところがあって。出てきた下書きを自分の目で見て「これ、自分が書きそうか？」を判断して直す。ここはAIに渡さず自分でやります。
正直、執筆の完全分離はできずにAIとけんかしている日々ですね。それでも執筆速度自体は上がっているので結構お勧めな手法です。
自分の文体をどこまで再現できて、どこから中身が捏造されるのか。その実物は別記事にあります。
公開前は1体に全部見せず、観点で割る
下書きができたら、公開前に検査します。
ここで大事なのは、1体のAIにレビュー観点を盛り込みすぎないことです。それをやると観点が混ざって、「全体的によく整理されています」みたいな当たり障りない感想しか返ってこない。なので観点ごとに別のAIに割って、1体には1つだけ目的を持たせてます。いま割ってるのは、書いてはいけないことが混ざってないかのリスク検査、辛口の批評、論理の検算です。割ると、各担当が遠慮なく尖った指摘を返してくるんですよね。
ここで効いてるやり方が2つあって。
1つは、表現の検査を別立てにすることです。過剰な言い切り、前振りのない唐突な話題転換、「様々な」みたいなぼかし語といったやつですね。これは論理の破綻とは別の壊れ方なので、専用の担当に分けたほうが当たります。あわせて、約物（記号やカッコの揺れ）はAIに判断させず、スクリプトで機械的に正規化してます。揺れてるかどうかは読まなくても分かるので、ここにAIを使うのはもったいないんですよね。
もう1つは、内部リンクをAIに探させることです。公開済みの記事を全部リポジトリに取り込んであるので、「この段落から張れる過去記事ある？」と聞けるんです。自分の記憶で思い出せる過去記事なんて直近の数本だけなので、ここはAIに探させた方が確実です。これは後で出てくる「1リポジトリに集約する」構成の副産物ですね。
検査の中身と、どこまで無人化してどこから人間が裁くのかは、別記事で書きました。
図とサムネはAIに作らせて、いい出来は貯めて育てる
記事が一通りできたら、図とサムネを付けます。
ここもAIに作らせてます。図は説明したい構造をそのまま渡してHTML＋Tailwindで組んでもらい、それをPNGに変換します。サムネは記事のタイトルと内容を渡して生成する感じですね。文章だけで説明していたところに図が1枚入ると、理解のしやすさが結構変わるんですよね。
最初から一発でいい感じに出てくるわけではないので、出来を見て「もうちょっと詰めて」と作り直すループを回します。そして、いい図ができたらそれを references に保存しておく。次に作図させるとき、それが“お手本”として効いてくるんですよね。この記事に載っている図も、全部この流れで作りました。
サムネイルに関しては、HTMLのコードをパターンとして保存しておくことで再利用ができるようになっています。HTML→PNGの撮影もPlaywrightを使用するとAIが勝手に判断してくれて撮影まで行ってくれるので超便利ですね。
なお、図を「作る」ことより残ってた判断は「どこに置くか」なんですが、そっちの話は1本に切り出しました。
作り方を具体的に知りたい人はこちら。
- Mermaid図をAIで自動生成する — フロー図やシーケンス図を、Figmaで2時間かけてたのが5分に。最初に試すならここから
- 図解をAIに丸投げして育てる — 気に入った図をreferenceに貯めるだけで、AIの作図が勝手に上手くなっていく仕組みの話
タイトルとSEOは、マーケティングを知らないままAIで補える
正直、文章を作るよりも苦手だった領域です。タイトルの付け方、メタディスクリプション、競合調査。マーケッターの方に聞いても何から手を付けていいか全然分からなくて、最初にAIに任せ始めたのもここからでした。
やってることは2段階で、上位記事のタイトルの付け方を調べさせて相場を掴んでから、自分の記事のタイトルとメタの案を出させる。採るか直すかは自分で決めます。ここがAIに任せやすいのは、正しさの基準が自分の外にあるからなんですよね。上位に並んでる記事の付け方が相場で、公開後のPVが答え合わせになる。SEOの知識が自分になくても、相場に照らせば案の良し悪しは判断できるわけです。
1つだけ書いておくと、タイトルを詰めるついでに、各章の見出しも一緒に見直します。見出しは執筆しながら立てるんですが、書き終わってから読むと、看板に内輪の用語（エラーの内部名とか実装用語）が乗ってることがあるんですよ。それが出たら文言をいじって済ませず、その章が書き手目線になってるサインとして中身の順番から疑います。看板は「困ってる人が打つ言葉」で書きたいので。
正直に言うと、この工程はまだ仕組み化の途上です。「仕組み完成してます！」と書きたいところですが、そうじゃないので正直に書いておきます。
公開したら記録する。書いて終わりにしない
公開して終わり、にはしてないんですよ。
ここで効いてくるのが、また「1リポジトリに集約してある」という構成です。公開した記事も、そのPVデータも、同じリポジトリに置いてある。するとPV分析をこのリポジトリの中で回せるんですよね。このブログはどういう読者層に届いて、なぜ伸びたのか。それを分析して、次の記事のアウトライン（企画）に戻す。
ポイントは「作業ログを残す」というより、後から参照できる資産として記事と分析結果が同じ場所にあることです。記事の中身も、PV分析の結果も、ひとつながりで手元に残る。
実際これが効いたことがあって。リポジトリの中でPVを分析したら、生成AI系の記事が圧倒的に読まれていて（うちのブログの場合、PVの8割以上がそこ）、その中でも伸びてるのはツール名を題に置いた実用ノウハウ系で、しかも新記事を出さない月は数字が落ちる、というのが見えたんですよ。結論はシンプルで「Claude Code 系に絞って、新規記事をとにかく出し続けろ」。で、実際にそのテーマでシリーズを書き始めました。分析と記事と過去ログが同じリポジトリにあるから、「数字 → 次に何を書くか」の判断をそのまま回せるんですよね。
調査メモも記事の素材も過去ログもPVデータも同じ場所にあると、「次に何を書くか」を決めるのに別の場所を探しに行かなくて済むんですよね。正直やってみないと分からないんですが、続けてみると「あ、これか」ってなると思います。
記録と集約は、それぞれ単独記事にしてます。
- git logを作業ログにする話 — コミットをAIに書かせるだけで、git logがそのまま作業履歴に。中断からの復帰や週次の振り返りがラクになる
- 全業務を1リポジトリに集約した話 — 開発も調査もブログも1つのリポジトリへ。やった仕事が消えず「資産」として積み上がる作業基盤の作り方
全工程に共通して効いてる考え方
工程を全部並べてみると、根っこに通ってるものが見えてきます。冒頭で2つ挙げましたが、こうして並べるともう1つ足したくなるので、3つにして書いておきます。
① 検証が先、ネタは後
ネタを探すのではなく、検証する。検証したことがネタになるんだから、検証していないことは記事にもならない。記事は検証の副産物として立ち上がるもので、この順番にしておくと「ネタ切れ」という発想自体がなくなるんですよね。
② 便利技は使い捨てず仕組みに沈める
「これ便利だな」で終わらせない。一番手軽なのは、良い結果が出たら reference に保存して次のAIへの参考資料にすること（さっきの図・サムネが育つのがこれ）。もう一歩進めると、繰り返す作業はスキルやエージェントの形にして残す。どちらも「その場限りにしない」という同じ原則で、保存はその入口です。次に使うとき1から作り直さなくていいので、この積み上げがじわじわ効いてきます。
③ 1体に欲張らず、観点で割る
公開前チェックのところで出てきましたが、1体のAIに全部やらせると観点が混ざります。用途ごとに割った方が、各エージェントが遠慮なく動くんですよね。これはレビューに限らず、他の工程でも同じ考え方です。
AI全部入りでも、最後に残るのは「これ自分が書きそう？」の判断
自分らしさとAIっぽさのせめぎ合い。その摩擦の中で、自分の言葉が研がれていく。
ここまで見てきた通り、検証から公開まで全工程にAIが居ます。執筆にもAIは居ます。文体エージェント（writing-stylist）が下書きを作るし、音声入力で口述することもある。
でも、執筆だけ役割が逆なんですよね。
他の工程はAIが主導して人間が確認する形ですが、執筆は人間が主導してAIが補助に回る。なんでそうなるか。
理由は、AIの出力が「合ってるか」を測る基準が、工程ごとに違うからなんですよね。もちろん他の工程も、最後は人間が見ます。でも図やSEOや調査は、合ってるか外してるかの基準が外側にある。図がちゃんと描けてるか、検索意図に合うタイトルか、事実が正しいか。だから人間は「確認役」で済む。ところが文章の「自分らしさ」だけは、基準が自分の中にしかなくて、誰かに「合ってます」と言ってもらえない。だから執筆だけ、確認じゃなく「主導」に回るんです。
AIが出してきた文章を読むじゃないですか。読んでいると、「これはちょっと違う」「ここは自分ならこう言わないな」って思う部分が出てくるんですよ。そこを直す。その修正の過程で自分らしさが入ってくるんですよね。音声入力でしゃべった言葉も同じで、そのまま入れるんじゃなくて「これは自分が言いそうか？」を確かめながら使う形ですね。
残るのは「文章をうまく書く力」じゃないんですよね。「これ、自分が書きそうか？」を判断する力なんです。
まぁ正直、この作業をなくしてしまえば今の3倍ぐらいの量のブログを出せますね。ただ、それはただの量産作業な気がしてしまいます。なんとなく愛着も湧かないですよね。文体と自己が乖離しちゃうというか。割と大事にしている考え方です。
これ、「技術ブログを書け」と言われてるエンジニアへのアンサーでもあって。2つ理由があります。
ひとつは、だから量産する意味がないということです。自分らしさをメッセージとして注入していく作業なので、機械的に数を増やすのとは違うんですよね。感覚としては「自分らしさとAIっぽさのバトル」みたいな感じですw ちゃんとそれなりに疲弊します。
もうひとつは、実装した内容は、実装した自分にしか正しく判断できないということです。検証して動かした結果について「これは本当にこうだったか？」を確かめられるのは、手を動かした本人だけです。だから最終チェックは絶対に人間が要る。
ここが面白いなと思ってて。「いきなり自分らしく書け」って言われても、何が自分らしいのかって分からないじゃないですか。でも「AIが出してきた文章を見て、違うと感じる所を直す」なら、誰でもできるんですよ。生成より添削の方が、自分を出しやすい。文章を書くのが苦痛な自分でもこのパイプラインが回ってる理由は、ここだと思ってます。
何から始めるか、そして正直な限界
まず何から始めるか
「で、何から始めればいい？」と思った方へ。
おすすめは、苦手な1工程からAIに任せてみることです。順番はこんな感じ。
- 苦手な工程を1つ選ぶ（僕はタイトルとメタディスクリプションでした）。使うAIは普段のもので大丈夫です。ChatGPT でも Gemini でも、Claude Code でも
- 過去記事があれば、何本かAIに読ませて文体や思想を抽出してもらう（まだ1本も無ければ、ここは飛ばしてOK）
- AIが出した案を「これ自分が書きそう？」で直す。気に入らない所を直すだけでOK（生成より添削の方がラク）
これだけで1工程は回り始めます。いきなりパイプライン全部を組もうとしなくて大丈夫。苦手なところを1個ずつ潰していくと、じわじわ繋がってきます。
もっと手っ取り早く全体像を相談したいなら、この記事ごと自分のAIに読ませて「マネできそうな所ある？」と聞くのもアリです。状況に合いそうな工程を拾ってくれます。
正直な限界
誇張したくないので書いておきます。
まず、ネタや「気になる！」は人間発信です。そこにモチベがないと、そもそも書かない。仕組みは「書こうとした人の作業を楽にする」ものなので、動機まで代替はできないですw
あと、最初から完成形は組めないです。続けてみて初めて「ここ変えよう・ああしよう」が出てくる。この記事で紹介した形も、1年かけて少しずつ固まってきたものです。最初から全部揃えようとしなくていいです。
文章を書く苦痛がゼロになるわけでもないです。相変わらず書くのしんどいですよw マーケ周りの分析もまだ仕組み化の途上で、手動でやってる部分があります。
まとめ：個人で完結する領域だからこそ、AIを試せた
この1年で一番腑に落ちたことがあって。同じAI活用でも、本職のコードを書く仕事とブログでは勝手が全然違うということです。
本職のエンジニアの仕事でエージェントを使うとなると、結構ハードルがあるんですよ。後のメンテナンスとか、決定事項を流動的に把握しておかないといけなくて、AIに自由にやらせるというより、ガチガチに縛って使うことになる。
でもブログは違うんですよね。僕個人で完結するコンテンツなので、僕がどう思うかだけで決まる。だから自分が使いやすいように、好きなだけ環境を整えられる。
そして、この「自分が使いやすい環境を整える」行為そのものが、AI活用を学ぶ一番の場になったんです。skill の作り方、agent の設計、観点の分け方、みんなここで学びました。本職のコードを書く現場では踏み込みづらかった領域に、ブログという個人完結の場だからこそ踏み込めた。それが一番の収穫だったと思ってます。
パイプラインは人によって違っていいんですよ。「自分はこの工程が苦手」「ここは手放したくない」は人それぞれです。残すべき人間の領分を自分なりに見極めていく、その過程がたぶん大事で。
文章を書くのは相変わらず好きじゃないんですけど、「AI活用が一番できてる業務は何か」と聞かれたらブログだって答えると思います。それがこの1年の一番の発見でした。
ほなまた〜
