合計159万再生のAI文章術と、閲覧34の自分のサイトが、同じ仕組みでできていた

XでバズっているAI文章術の投稿を3本、通しで読んだ。表示されていた再生数は139万・3.6万・16.8万で、合計すると約159万になる(2026年8月11日参照)。一方、私が運営しているこのサイトは、前身のThreadsで14日毎日書いて閲覧34だった。

その159万と34が、読んでみたら同じ仕組みの話をしていた。というのがこの記事だ。バズ投稿が「作り方」として売っている仕組みを、私は先に作って運用していた。だから中身の答え合わせができるし、投稿には書かれていない側——仕組みを作ったあとの数字——も実数で書ける。

先に断っておくと、これは投稿者たちへの批判記事ではない。3本とも長文で、構成は巧みだった。この記事でやるのは、自分の手元で検証できることの答え合わせと、検証できない部分の線引きだけだ。投稿に出てくる個々のプロンプト技術の真偽には踏み込まない(検証していないからだ)。

3本の投稿が売っているもの

3本の投稿は、書き手も題材も違うが、構造は共通していた。長文で価値のある内容を無料で全部見せて、最後に続きへの導線(相談窓口・外部LP・LINE登録)を置く。売り物はプロンプトそのものではなく、「AIで文章を量産する仕組みの作り方」だ。

中でも2本目の投稿が説く内容は具体的だった。要旨はこうだ。プロンプトを毎回書くのではなく、判断基準をファイルに保存せよ。毎回守る恒常ルールは設定ファイル(CLAUDE.mdなど)に、仕事単位の手順はスキルとして分割し、執筆と校閲は別の担当(サブエージェント)に分離し、禁止表現や数字のチェックは機械検査(Hooks)で自動化する。これを「文章OS」と呼んでいた。

読みながら既視感があった。それは私のリポジトリの構成図だ。

答え合わせ:手元で動いている実物

このサイトの記事は、AIが最後まで書き、人間(私)が公開前に全文確認して承認する体制で作っている。その制作フローを、投稿の説く要素と突き合わせるとこうなる。

判断基準のファイル化 → 方針ファイル。 サイトの編集ルールは方針ファイル1枚に固定してある。「数字は実数で書く」「煽り語彙は使わない」「出典URLと日付のない事実は書かない」「使っていない物を使ったと書かない」など6項目。AIはセッションのたびにこれを読んでから書く。ネタの採否も「実践・有用・鮮度」の3つの問いで機械的に判定する。

手順のスキル化 → 工程別のコマンド。 ネタ収集・企画・執筆・段取りを、それぞれ別の定義ファイルを持つコマンドに分けてある。執筆担当の定義には「形容詞より数字」「失敗を整形で消さない」まで書いてある。収益記事に限っては、執筆前に市場調査を回すコマンドも別に用意した。

校閲の分離 → 読み取り専用の校閲エージェント。 原稿ができたら、書いた担当とは別の校閲エージェントが方針ファイルとの適合を照合する。このエージェントはファイルを修正できない(読み取り専用)。指摘を返すだけで、直すかどうかの判断は書き手側に残る。

機械検査 → フック。 ネタファイルを保存すると、出典URLか「実践」の明記がなければ保存自体が拒否される。サイト記事をmainブランチへ直接pushすることも、gitのpre-pushフックが拒否する。公開はプルリクエストを人間がマージする以外の経路がない。

つまり、投稿が理想形として売っている構成は、無料のテキストファイルとgitの標準機能だけで組める。実際に組んである。いま読まれているこの記事自体が、その工程(企画→執筆→別担当の校閲→人間の全文承認)を通って公開されたものだ。ただし正直に書くと、サイトの全記事がこの体制で作られたわけではない。企画から校閲までの全工程に切り替えたのは2026年8月10日で、それ以前の記事は方針ファイルと人間の全文承認だけで出している。

昨日、その機械検査に自分が弾かれた

仕組みが本当に動いている証拠を1つ書いておく。この記事のネタファイルを保存しようとしたとき、出典検査のフックに保存を拒否された。

出典のURLは書いてあった。ただ、URLを入れ子のリストに書いたため、検査スクリプトが見ている「出典:」の行そのものにはURLがなく、機械は「出典なし」と判定した。誤検知だ。だが、直したのは検査スクリプトではなく書式のほうだった。機械が読める形で書くのも書き手の仕事、という運用にしているからだ。

機械検査は、こういう地味な誤検知と書式の調整を含めてはじめて回る。投稿の中の「Hooksで自動検査」という一行の裏には、この種の細かい摩擦が実際にはある。

投稿に書かれていない数字

ここからが、バズ投稿には書かれていない側の話だ。

この仕組みを回した結果の数字を並べる。前身のThreadsは14日間毎日投稿して閲覧34。サイトは公開記事11本(この記事の前日時点)で、アフィリエイトの成果は0件。サイトのビルドとコンテンツ検証のテストは149件が通っている(執筆時に実行した実測)。仕組みは動いている。数字はまだ動いていない。

仕組みを作れば売れる、とはこういうわけで言えない。私のサイトは公開から3日しか経っていないから当然でもあるのだが、「当然」を確認できること自体が実数を記録している効用だ。少なくとも、仕組みの完成度と収益は別の変数だと、自分の数字で言える。

3本目の投稿には月25万円という数字が出てくる(個人差の注記つき)。この数字を私は検証できない。嘘だと言いたいのではない。ただ、私のサイトは方針ファイルの規約で「自分で実測して記録した数字だけを、不利なものも含めてそのまま書く」ことにしている。閲覧34は恥ずかしい数字だが、実測の記録がある。書ける数字がそれしかないなら、それを書く。

モデルの違いだけは押さえておく

もう1つ、答え合わせで分かった違いを書いておく。3本の投稿と私のサイトでは、同じ仕組みの使い道が違う。

投稿側のモデルは、仕組みの「作り方」を商品にして、読者をリスト(相談・LP・LINE)に集める形だ。読者の「稼ぎたい」がそのまま商品になるので、成約までの距離が短い。再生数はその強さの反映だと思う。

私のサイトは、仕組みで作った「実務記録」を無料で公開し、記事内で紹介する道具(講座・ガジェット・サービス)のアフィリエイトで収益化する形だ。距離は長いし、数字が出るのも遅い。それでもこの形を選んでいるのは、自分のサイトでは実測した数字だけを書くと決めているからだ。看板にできる数字が閲覧34しかなくても、その規約のほうを優先したい。優劣ではなく選択の話だ。

どちらのモデルであれ、下で動く仕組みは同じだった。それがこの答え合わせの一番の収穫だ。

同じことをする人へのポイント

• バズ投稿のAI文章術は、読む価値がないわけではない。ただし個々の技術の正確さは、この記事では検証していない。事実として使うなら元の論文や各AIベンダーの公式ドキュメントまでさかのぼるのが確実で、投稿の導線(相談・LP・LINE登録)と技術情報は切り離して読むのが実用的だと思う
• 「文章OS」に相当する仕組みは、テキストファイル(ルール・手順・担当定義)とgitの標準機能(フック・プルリクエスト)だけで組める。専用ツールや講座は、少なくとも組むだけなら要らなかった
• 機械検査(Hooks)を入れるなら、誤検知との付き合い方まで含めて設計したほうがいい。私の運用は「機械が読める書式に書き手が合わせる」に倒している
• 仕組みの完成度と数字は別の変数だった。仕組みを作った直後の数字(私の場合は閲覧34・成果0件)を記録しておくと、あとで仕組みの効果を測る基準線になる

この記事は、運営者自身の実践記録に基づいています。