※本記事には広告を含みます
はじめに
AI×副業をテーマにブログを12本公開しました。事業立ち上げから2週間ちょっとで書ききった、合計約68,000字の分量です。
それを2026年5月、わずか1日で全部書き直しました。新しい本文は約45,000字。圧縮率は67%です。
理由はシンプルで、「副業をやりたい人にこのブログは届かない」と気づいたからです。エンジニア向けの実装ログのような書き方が、ターゲット読者である副業伸び悩み層には壁になっていた、という当たり前の話でした。
この記事では、書き直しの過程で見つけた「副業層に届かない8つのクセ」を、悪い例とセットでそのまま公開します。同じテーマで発信している人の参考になればと思います。
書き直すことになった発端
最初の12本は、AIを使った事業運営のリアルを淡々と書く方針でした。「Claude Codeで何をどう動かしたか」「設定ファイルがどうなっているか」「所要時間が何秒だったか」を、コードや設定の断片を添えながら書いていく感じです。
書いている本人にとっては自然な手触りでしたが、12本書き上げた段階で社長 (事業の意思決定者) から「冗長で読み切れない」「専門用語が多すぎて何の話か分からない」と差し戻されました。
読み返してみると、原因はSEOでもタイトルでもなく本文そのものでした。エンジニア出身の書き手が自然と書く文章は、副業層には届きにくい構造になっていた、というのが結論です。
そこから、1記事をサンプルとして手で書き直して校正方針を決め、残り11本を一気にリライト、というのが今回の流れです。
副業層に届かない3つの典型パターン
書き直し作業をしながら、つまずいているクセが大きく3つあることが見えてきました。
1つ目は「前置きで意気込みを語ってしまう」パターンです。本題に入る前に「第一原則」「具体的には」「ポイントは3つ」と意気込みを並べてしまう。本人としては丁寧に説明しているつもりでも、読者から見ると本題までの距離が遠くなります。
2つ目は「説明なしで専門用語を投げ込む」パターンです。エンジニア界隈では当たり前の単語 (リポジトリ名、技術スタックの略語、コマンド名など) を、何の説明もなく文中に入れてしまう。書き手の脳内では1秒で意味が立ち上がりますが、副業層の読者は読みながら検索することになります。
3つ目は「設定ファイルやコードをそのまま貼る」パターンです。実例として誠実に見せたい気持ちは分かるのですが、YAMLやJSONを長く貼ると、その瞬間に副業層の読者は壁を感じて離脱します。
この3つは、エンジニア向けの技術記事では正解の書き方です。が、副業層に向けたブログでは不正解になる、というのが今回の学びでした。
副業層向け校正ルール 8選
3つの典型パターンを社長との校正のやり取りで分解していった結果、最終的に8つのルールに整理されました。これを社内では「R6からR13」と呼んで、執筆前のチェックリストにしています。
1. 想定読者は副業伸び悩み層・エンジニアではない
全ての判断のベースになるルールです。1段落の中に「注釈なしの英字略語・カタカナテック語が2つ以上」あったら危険信号、を目安にしています。
2. 前置きの列挙構造を禁止する
「第一原則:」「具体的には:」「ポイント:」「学び:」型の前置き+箇条書きで章を膨らませない、を徹底します。動機や要点は1文で言って終わる、が基本姿勢です。
実際の悪い例: 「AI会社の第一原則: 1人で7テーマを並行運用するには、立ち上げのオーバーヘッドを限界まで削る必要がある。具体的には: ……」
書き直し後: 「AI会社で複数事業を並行運用するなら、新しいテーマの立ち上げ自体も自動化して時短したいからです。」
意気込みを削ると本文は短くなりますが、読者にとっての分かりやすさはむしろ上がりました。
3. 細かい時間表記 (秒・分単位) を本文に出さない
「32秒で完了」「所要90秒」「2分待ち」のような細かい時間表記は読者に「うざい」と感じさせる、と社長から指摘がありました。
例外として、「実工数で約8時間」「3日間で書ききった」のような大きな塊の時間は記事の説得力に直結するのでそのまま書きます。粒度の選別が重要です。
4. 設定ファイル・コードブロックの長尺貼付を控える
YAMLやJSONを本文に素のまま貼らない、を原則にしました。
代わりに「事業ごとに『市場調査担当』『記事執筆担当』など16人分の社員を、役割と勤務スケジュールつきで設定ファイル1本にまとめている」のように、日本語で1〜2行に要約します。設定ファイルそのものを見たい技術寄りの読者は、そもそも別の記事や公式リポジトリに行きます。
5. 「モデル使い分け」「ハマりやすい○点」型のおまけ章は基本削除
記事末尾に「次にできる拡張」「判断軸まとめ」「ハマりやすい3点」のような付録章を惰性で付けない、を徹底しました。
判定基準は単純で、その章を削っても主張が成立するなら削る、です。残す場合は「副業層がそれを読んで実際に行動が変わるか」を自問して、変わらなければやはり削ります。
6. 技術固有名詞には「役割の説明」を必ず添える
リポジトリ内のパスや技術固有名詞を、説明なしに本文に入れない、をルール化しました。
悪い例: 「businesses/001_ai-meta-solo/ を _template から複製」
書き直し後: 「事業の雛形フォルダ (社員設定や初期ファイルが入った『テンプレート』) から、新事業フォルダを丸ごとコピー」
初出の段階で「○○のような役割を果たす△△」と説明を添えるだけで、読者の離脱は明らかに減ります。
7. 社内呼称ではなく日本語のブランド名で書く
社内で使っている英字のリポジトリ名 (今回の場合「ai-company」) を、対外向け本文では「AI会社」と日本語で書く、をルール化しました。読者は社内呼称を知らないので、そのまま使うと意味が立ち上がりません。
技術識別子 (記事のフロントマター内、コードブロック内、内部リンク先など) はそのまま残します。あくまで「読ませる本文では日本語ブランド名」というルールです。
8. 「ただそれだけです」型の気取った締めを避ける
最後のルールは、文章のトーンの話です。動機を語る文の末尾に「〜したかった、ただそれだけです」「〜のためです、それ以上でも以下でもありません」のようなナラティブ風の決め台詞を付けない、を徹底しました。
実用書としてのトーンを崩すこと、それから単純に「かっこつけすぎ」に読まれること、が理由です。素直に「〜したかったからです」「〜が目的です」で締めれば十分です。
書き直し前後で何が変わったか
8つのルールを当てた結果、12本全体で次のような変化がありました。
書き直し前の合計文字数は約68,100字。書き直し後は約45,421字で、圧縮率は67%です。
最も圧縮率が高かった記事は、サンプルとして最初に手で書き直したもので、6,500字から3,800字 (58%) まで圧縮されました。タイトルも記事ごとに副業層向けに短縮し、長いものでは72字あったタイトルが32字まで縮みました。
スラッグ (URL) は維持したので、既存のインデックスや被リンクへの影響はゼロでした。文字数を削っても情報量が減ったかというと、本筋の主張は全て残っています。削ったのは「前置き」「列挙構造」「コードブロック」「おまけ章」「気取った締め」など、本筋の主張に寄与しない部分です。
体感としては「読み終わるまでの所要時間が体感で半分になった」「専門用語が消えて、別ジャンルの読者にも届く幅が広がった」が大きな手応えでした。
同じことを自分のブログでやる手順
最後に、副業層向けのブログを書いている人がこの作業を自分のブログに移植する場合の手順をまとめます。
最初にやることは、既存記事を1本だけ選んで、ターゲット読者の友人や家族に「読み切れたか・どこで止まったか」を素直に聞くことです。本人は読める前提で書いているので、本人視点では問題が見えません。第三者の素直な反応が出発点になります。
次に、止まったポイントを集めて、「自分の文章のクセ」として一覧化します。今回の8つのルールはあくまで私のケースで、人によってクセは違います。前置きが長い人、結論が遅い人、エビデンスが薄い人、それぞれ違うクセがあるはずです。
リスト化したクセを、過去記事の冒頭に「執筆前チェックリスト」として置きます。新しい記事を書く時に毎回読みます。これだけで、同じ失敗を繰り返さない仕組みになります。
既存記事のリライトは、サンプルとして1本だけ手で書き直してチェックリストを確定させてから、残りを一気にやるのが効率的です。1本目で方針が決まっていれば、2本目以降は機械的な作業に近づきます。
まとめ
副業層に届くブログを書くためのルールは、技術記事や論文とは別の体系です。
12本書いて気づいたのは、書き直した方が早い、ということでした。文字数で言えば22,000字以上削ったことになりますが、削ったのは「自分が書きたかった部分」であって、「読者が読みたかった部分」ではありませんでした。
副業ブログで伸び悩んでいる人は、まず自分の1記事を第三者に読んでもらって、どこで止まったかを聞くところから試してみてください。同じテーマで発信している人と一緒に校正基準を作っていけたら、業界全体の発信品質が上がっていくはずです。
