X投稿でAI自慢を避けるべき理由 — 実データで見る投稿パターン別の反応差

2026.02.22
Share:

はじめに — 全部AI自慢になっていた

「次のX投稿、何を書こうか」

2月19日、X投稿の案を考えていた時のことです。PM × Claude Codeという切り口で、ZERONOVA LABとしての発信を強化したい。そう思ってClaude Codeに投稿案を依頼しました。

出てきた5つの案はすべて、同じ構図でした。

「10日間で82ツール作った方法」「PMのAIネイティブな1日のタイムライン」「6プロダクトを同時運用するAI活用術」——どれも、AIの成果を誇示する内容です。

一見よさそうに見えます。数字のインパクトがあるし、AIというトレンドにも乗っている。でも、この案を見せた瞬間に指摘を受けました。

「最近Xでよく見るAI使って自慢したり驚いて偉そうにしているだけの人みたい」

この一言で目が覚めました。

問題 — AIが提案するもの=正解ではない

冷静に考えれば、当然のことです。

2026年のXには「AIで○○個作りました」「AIで生産性○倍になりました」という投稿が溢れています。Claude Codeに投稿案を聞けば、Xで伸びやすそうなパターンを学習しているので、同じ構図を提案してくる。しかしそれは「Xに溢れている投稿のコピー」に過ぎません。

開発日記にはこう書きました:

AIは「Xで伸びやすそうな投稿」を提案するが、それがブランドに合うかは人間が判断すべき。特にAI自慢系は数字的には伸びるかもしれないが、長期的な信頼構築にはマイナス

ZERONOVA LABは「AIネイティブ実験スタジオ」を掲げています。AI活用はブランドの核です。しかし、AI活用を「自慢」として発信するのと、「実践の一部」として自然に見せるのとでは、受け取られ方が全く違います。

これは開発記事でAIとの協業をちゃんと書くことにした理由で書いた問題と根が同じです。Journal記事ではAI協業の透明化を進めてきましたが、X投稿では真逆の方向——AIの成果誇示——に向かいそうになっていました。

データで見る — ストーリー型とAI自慢型の3〜6倍差

指摘を受けた後、過去の投稿データを分析しました。2026年1月から2月にかけての33投稿。結論は明確でした。

反響TOP5

順位投稿内容インプいいねRT投稿タイプ
1自治会DX理事会29650実体験ストーリー
2固定ポスト(1/3)19030数字×自己紹介
3自治会DX開発着手13031課題列挙×宣言
4共同開発開始6610個人→チーム変化
5シニアUI記事6131実開発の気づき

投稿タイプ別の平均リーチ

投稿タイプ平均インプレッション特徴
ストーリー型(URLなし)130〜296リアルな出来事×感情
記事紹介型(URL付き)30〜50外部リンクでリーチ減少
AI自慢・機能紹介型25〜42差別化できず埋もれる

ストーリー型はAI自慢型の3〜6倍のリーチ。

数字は嘘をつきません。Xのアルゴリズム以前に、読む側の心理として、「AIで82個作った」よりも「理事会で自治会DX担当として紹介された」のほうが、圧倒的に「この人の話をもっと聞きたい」と思わせる力があるのです。

1位の投稿を分析する — なぜ自治会DXの理事会がバズったか

反響TOP1の「自治会DX理事会」投稿(インプレッション296、いいね5)を掘り下げます。

この投稿が生まれたのは、2月19日の理事会の直後でした。

理事会で会長から自治会DX担当として紹介された。ついに始まったという実感。来月プロトタイプを見せるのが楽しみ。

Story Logにはこう記録しています。テキストのみ、AI自慢ゼロ、リンクなし。純粋なストーリー投稿です。

なぜこれが刺さったのか。理由は3つあると考えています。

1. 当事者性がある。 「自治会の理事会に出た」というのは、開発者の日常ではない。でもだからこそ「個人開発者がリアルな場で紹介される」というギャップが生まれます。

2. 感情が伝わる。 「ついに始まったという実感」。この一文に、1月27日の開発着手投稿(インプレッション130、RT1)からの文脈が重なっています。継続して追いかけている人には「あの人、本当に進めてるんだ」という信頼感が生まれます。

3. 次の展開が気になる。 「来月プロトタイプを見せる」という予告。次回の投稿を見たいと思わせるフックがあります。

対照的に、AI自慢投稿は「すごいですね」で消費されて終わります。次回の投稿を見たいとは思わない。差が生まれるのはここです。

方向転換 — X投稿ガイドラインの改訂

データの裏付けを得たので、X投稿ガイドラインを改訂しました。

もともと3つの原則を設けていました。

  1. X内で完結させる
  2. ビジュアルを付ける
  3. URLはリプライに分離

ここに**第1原則として「実体験ベースを最優先にする」**を追加し、4つの原則に拡張しました。

追加した原則の要点

開発中に起きた出来事、直面した課題、実際の反応など、自分が体験したことをそのまま投稿する。「AIで○○個作った」「○○を量産した」のようなAIの成果を誇示する投稿は避ける。Xに溢れているAI自慢アカウントと同じに見える

「避ける」と明示的に書いたのがポイントです。曖昧にすると、次にClaude Codeに投稿案を聞いたときにまた同じ構図が出てきます。ルールとして明文化しておくことで、AIの提案を受け取ったときに「これは原則に反する」と判断できる基準になります。

対話セクション — ストーリーを「作る」か「拾う」か

ZeronovaZeronova
実体験ベースの投稿が強いのはデータで見えた。でも、実体験は毎日あるわけじゃない。投稿ネタが枯渇しそうで不安がある。ネタを「作る」仕組みが必要じゃないか。
Claude Code
「作る」というよりも「拾う」仕組みの方が有効です。開発中の出来事は毎日起きています。ユーザーから要望が来た、エラーにハマった、意思決定で迷った。これらは起きた瞬間に記録しないと忘れます。devlogは技術作業記録ですが、「理事会で紹介された」のような体験や感情は記録する場所がありません。
ZeronovaZeronova
確かに、今日の理事会の件も、投稿の相談をしたから言語化されただけで、相談がなければ流れていた。devlogとは別に、体験と感情を記録する軽量なログが必要だ。
Claude Code
Story Log として設計するのはどうでしょうか。devlog(技術記録)との棲み分けを明確にして、「人との関わり」「感情」「判断の瞬間」を記録するファイルを新設する。X投稿だけでなく、Journal記事やFocus Blog記事の元ネタとしても活用できます。
ZeronovaZeronova
それでいこう。負荷を上げたくないから、書き方は「日付 + 何があった + どう思った」だけにする。体裁は気にしない。

この対話を経て、docs/story-log.md を新規作成しました。ストーリーログの設計思想は「投稿ネタは作るものではなく拾うもの」です。

ストーリーログ — devlogとの棲み分け

開発日記を書く習慣で記事ネタが尽きなくなった話で書いた通り、devlogはJournal記事の素材庫として機能しています。しかしdevlogの記録対象は「技術作業」です。

項目devlogStory Log
記録対象技術的な作業(実装・設計・デバッグ)体験・感情・人との関わり
記録例「VP9のCRF設定でGIF非対応を発見」「理事会で会長から紹介された」
活用先Journal記事(技術解説)X投稿、Journal記事(ストーリー性強化)
書き方テンプレートに沿った構造化記録日付 + 出来事 + 感想(自由記述)

「理事会で紹介された」「ユーザーから要望が来て嬉しかった」「Search Consoleの数字が伸びていて手応えを感じた」。これらはdevlogには書かない種類の出来事です。でも、X投稿として最も響くのはこういう当事者ストーリーです。

記録する場所がなければ、体験は数日で記憶から消えます。Story Logを作ったことで、体験を「拾う」仕組みができました。

固定ポストの設計 — プロフィール訪問者への「名刺」

データ分析と同時期に、もう一つ重要な施策を実行しました。固定ポスト用のスレッド作成です。

個人開発者のフォロバ企画(290いいね・約1万表示の投稿)にリプライしたことをきっかけに、プロフィール訪問者への受け皿が必要だと気づきました。

3連スレッドの構成

スレッド内容狙い
1投稿目(固定ポスト)PM × Claude Code + 数字3つ(5サービス・82ツール・125記事)「何者か」を瞬時に伝える
2投稿目5つのWebサービス一覧 + ツール一覧スクショ「何を作ったか」を見せる
3投稿目フォローする理由3つ + ZERONOVA LAB URLアクション誘導

ここでも学びがありました。

「プロダクト」ではなく「Webサービス」と書く。 一般の人に伝わる言葉を選ぶこと。技術者同士の会話では「プロダクト」で通じますが、Xのタイムラインで初見の人が読む文脈では「Webサービス」のほうが直感的です。

Xは同一ドメインの2つ目のURLを自動削除する。 zeronova-lab.comzeronova-lab.com/tools を1つの投稿に入れたら、2つ目が消えました。これはXのプラットフォーム仕様のようで、URLは1投稿につき1ドメイン1つに絞る必要があります。

固定ポスト(1/3)は投稿後にインプレッション190を記録しています。反響TOP2にランクインしており、プロフィール訪問者の受け皿として機能し始めています。

X戦略全体の設計 — 実体験ファーストの投稿比率

ガイドライン改訂を経て、X投稿の推奨比率も見直しました。

タイプ比率説明
X内完結 + 動画/画像40%デモ動画、Before/After、スクショ付き実体験
X内完結 + テキストのみ40%当事者ストーリー、失敗談、判断の舞台裏
記事紹介(URL付き)20%核心をX上で完結 + リプライにURL

AI自慢型のカテゴリは存在しません。意図的に排除しています。

著者ペルソナのドキュメント化で定義した通り、ZeronovaはPMであり、エンジニアではない。AIを活用して実装まで行うが、本業は「価値探索(Discovery)」です。AIの成果を誇示することは、このペルソナと矛盾しませんが、「AIで○○個作った」を前面に出すと、「AIツールの販促アカウント」に見えてしまうリスクがあります。

X内完結×ビジュアル重視の方針は以前から採用していましたが(記事紹介型のリーチが3倍劣る分析はこの戦略の出発点でした)、今回の「実体験ベースを最優先」は、投稿の内容に踏み込んだ方針転換です。

構造的な理由 — なぜ実体験が勝つのか

データの裏にある構造的な理由を整理します。

1. 差別化できるかどうか

「AIで82個作った」という投稿は、他の誰でもできます。実際に、Xには似たような投稿が大量にあります。供給過多の市場で同じ商品を出しても埋もれます。

一方、「自治会の理事会で、会長からDX担当として紹介された」は、世界で自分だけの体験です。コピーできない。だからスクロールが止まる。

2. 感情の有無

AI自慢投稿の感情は「すごいでしょ」の一方通行です。読み手は「すごいですね」と返すか、スルーするかの二択。

実体験ストーリーには多層的な感情があります。緊張、期待、不安、達成感。読み手は自分の経験と重ねて共感し、「自分もこういう瞬間があったな」と記憶に残ります。

3. 連続性

AI自慢投稿は単発で消費されます。「82個作った。すごい。終わり。」次の投稿を見たいとは思いません。

実体験ストーリーには連続性があります。「自治会DX開発着手」(インプ130)→「理事会で紹介された」(インプ296)→「来月プロトタイプを見せる」。次の展開が気になるからフォローする。これがフォロワー獲得の本質です。

学び — AIの提案を鵜呑みにしない

この一連の経験で得た最大の学びは、AIの提案をそのまま採用しないことの重要性です。

Claude Codeは優秀なツールです。10日で82個のツールを量産できたのもClaude Codeのおかげですし、60本以上の技術記事を2週間で書けたのもClaude Codeとの協業があったからです。

しかし、X投稿のような「ブランドの顔」になるコンテンツは、AIに任せきりにすると危険です。AIは「Xで伸びやすいパターン」を学習していますが、それは「Xに溢れているパターン」でもあります。差別化ではなく同質化に向かう。

PMとしての判断は、AIの提案を受け取った上で「これは自分のブランドに合うか」「長期的な信頼構築につながるか」をフィルタリングすることです。今回は、ユーザーからの指摘がそのフィルターの役割を果たしてくれました。

まとめ

この記事で伝えたかったことは3つです。

1. 実体験ストーリーはAI自慢投稿の3〜6倍のリーチを獲得する。 データで確認しました。当事者性と感情と連続性が、スクロールを止める力になります。

2. AIの提案はブランド戦略のフィルターを通すべき。 AIは「伸びやすいパターン」を提案しますが、それは差別化ではなく同質化に向かう可能性があります。「この投稿は自分にしか書けないか」という問いが判断基準になります。

3. 体験を拾う仕組みを作る。 良いストーリーは開発中に毎日起きています。でも記録しなければ数日で消えます。Story Logという軽量な記録の仕組みを作ったことで、投稿ネタを「作る」のではなく「拾う」サイクルが回り始めました。

X運用に限らず、個人開発者がSNSで信頼を積み上げるために大切なのは、「AIで何ができたか」ではなく「自分が何を経験したか」を伝えることだと、データが教えてくれました。

Zeronova avatar

Zeronovaゼロノバ

Product Manager / AI-Native Builder

Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。