自分が続けてる技術ブログ（ https://wp-kyoto.net ）が開始10年を経過したので、「なんで10年も続けることができたのか？」を振り返ってみているシリーズです。前回、AI に自分の執筆スタイルを分析させたことで「個人と業務で書き方を切り替えている」ことに気づいた話を書きました。今回はその二面構造の具体的な中身について振り返ります。

個人ブログは「半年後の自分」のための覚書

このシリーズの1回目でも書いた通り、個人ブログの顧客は「半年後の自分」です。この前提が決まっているので、書き方は自然とシンプルになります。

WordPress の管理画面を開いて、環境情報を書き、試したコードとその結果を貼り、必要なら一言二言の説明を添える。それで1記事です。Git を使って管理するとか、Markdown エディタで下書きしてから流し込むといったことはしません。WordPress の投稿画面に直接書きます。

これはこのシリーズの2回目で書いた「やることを減らす」の延長にある話です。執筆フローに手順が増えるほど、「面倒だからいいや」となる確率が上がります。10年間ブログを続けられた理由のひとつは、間違いなくこの「直接書く」という低摩擦の仕組みにあると思います。

1000記事を超えた今でも WordPress から移行していないのは、移行作業そのものが地雷原だからです。1000記事の移行で何かが壊れるリスクを取るくらいなら、慣れた場所に書き続ける方がいい。幸いWordPressのインフラを保守する経験もあれば、Headless WordPress構成なのでいざとなればローカルPCにWPを移せばいいと思っています。

業務ブログは「読者のゴール」から逆算する

一方で、業務として書く技術記事はまったく違うプロセスで作っています。会社の公式アカウントで出す記事には、個人ブログにはない制約と責任があります。

業務の記事で最初にやることは、「この記事を読む人は何に困っていて、読み終えた後に何ができるようになるか」を言語化することです。個人ブログでは自分が困ったことを書けばそれが目的になりますが、業務では「読者」を想定する必要があります。

このヒアリング的なプロセスは、以前は頭の中でなんとなくやっていました。しかし、AI を使って記事を生成することも増えてから、言語化を徹底しないと AI の出力がぶれることに気づきました。「この記事で扱わないこと」を決めておかないと、AI は関連しそうなあらゆる話題を盛り込もうとします。スコープが曖昧だと、教科書のような網羅的な記事が出来上がってしまい、結局ほぼ全面的に書き直すことになります。

AI をワークフローに組み込んだ経緯

業務の記事執筆で AI を使い始めたのは、書く量が増えたからです。個人ブログは短い記事を高頻度で出せばいいのですが、業務の記事は1本あたりのボリュームが大きく、品質基準も高い。両方を維持しようとすると、どこかで効率化が必要になります。

最初は単純に「AI に下書きを書かせて、自分が手直しする」というやり方を試しました。しかし、これがうまくいかなかった。AI が生成した記事は、構成は一見きれいなのですが、中身を読むと公式ドキュメントの焼き直しになっていたり、読者が実際に困っているポイントからずれていたりします。手直しの量が多すぎて、自分でゼロから書いた方が早いのではないか、と思うこともありました。

そこで方針を変えました。AI に「記事を書かせる」のではなく、「記事を書くための手順を構造化する」方向に舵を切ったのです。具体的には、記事を書くまでの工程を6つのフェーズに分けました。情報の収集、ヒアリング（読者の状況やゴールの言語化）、公式ドキュメントの調査、構成の企画、執筆、レビュー。この一連の流れを Claude のスキルという仕組みに落とし込んでいます。

たとえばヒアリングのフェーズでは、AI が自分に対して「この記事を読む人は今どんな作業で困っていますか？」「読み終えた後に何ができるようになりますか？」「この記事で扱わないことは何ですか？」と質問してきます。この質問に答えることで、記事のスコープが言語化されます。

調査のフェーズでは、AI が公式ドキュメントを検索して、自分が記事中で使っている用語と公式の用語のずれを対照表にまとめてくれます。たとえば自分が「グローバルシークレット」と呼んでいたものが、公式ドキュメントでは「Persisted Global Secrets」と表記されている、といったことを拾ってくれます。

レビューのフェーズでは、箇条書きの過剰使用、語尾の連続、スコープ外の内容の混入といった項目を AI がチェックします。このレビューチェックリスト自体も、過去に書いた記事の生成結果と最終稿を比較分析して、繰り返し改善してきたものです。

ネタの管理も仕組み化している

もうひとつ、業務側で個人ブログと違うのは、記事のネタを体系的に管理していることです。日常の業務で気づいたことや試したことを定期的に棚卸しして、記事にすべきかどうかを選別し、記事の種として整理するワークフローがあります。

個人ブログでは「地雷を踏んだらそのまま書く」で十分ですが、業務では「どのネタが読者にとって価値があるか」「今の時期に出すべき記事はどれか」という判断が入ります。これを頭の中だけでやっていると漏れが出るので、仕組みに落とし込んでいます。

なぜ分けているのか

個人と業務で書き方を分けている理由は、「続けるため」です。

もし業務と同じ品質管理プロセスを個人ブログにも適用したら、1記事にかかる時間が数倍になります。そうなると、個人ブログの更新頻度は確実に下がります。逆に、個人ブログのような「最短距離で書いて出す」スタイルを業務の記事に適用したら、品質が落ちて公式アカウントとしての信頼を損ないます。

どちらか一方に統一しようとすると、どちらかが犠牲になる。だから分けています。個人ブログは速度を優先し、業務の記事は精度を優先する。この切り分けがあるから、合算で年間200本前後のアウトプットが維持できているのだと思います。

共通しているのは「動いた結果を記事にする」こと

スタイルは違いますが、共通していることがひとつあります。「書くために調べる」のではなく、「動いた結果が記事になる」ということです。

個人ブログでは、エラーに遭遇して解決した、その記録がそのまま記事になります。業務でも、顧客対応や POC や競合調査といった実務の副産物として記事が生まれます。「さあ記事を書こう」と白紙に向かう場面は、実はほとんどありません。記事の種は、すでに日常の中にあります。

このシリーズの1回目で「まずは自分のための、メモからはじめよう」と書きました。個人ブログはその延長で10年続いています。業務の記事は、メモを記事にするまでの工程に仕組みを入れることで、品質を担保しながら量を維持しています。やっていることの根っこは同じで、メモの先にあるプロセスが違うだけです。

まとめると

技術ブログを長く続けるために大事なことは、このシリーズを通じてだいたい出揃ったように思います。誰のために書くかを決めること、やることを減らすこと、一度に書かないこと、時間で区切って諦めること。そして今回の話、場と目的に応じて書き方を変えること。

全部に共通しているのは、「しんどくならない仕組みを作る」ということです。気合いや意志力でブログを続けようとすると、どこかで息切れします。息切れしない範囲で、でも手は止めない。そのバランスを自分なりに見つけられれば、10年くらいは案外続くものです。