SNS Lab

投稿例

新しいAIモデルが発表。 ベンチマーク以上に見るべきなのは、 「人間なしでどこまで仕事を進められるか」です。 AI競争は、 答えが上手い ↓ 仕事を最後まで終えられる に移り始めています。 モデル性能が上がるほど、 次の差になるのは「実行力」です。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}
参考URL：{参考URL}

# 狙い
ニュースや原典を、読者の問いへの答えと仕事・行動に関わる意味へ変える。

# 切り口の選択
今回の題材と依頼に合う切り口を次から1つ選び、その切り口の作成手順と投稿設計だけを使ってください。選ばなかった切り口の流れや結論を混ぜないでください。
- ニュースの影響解説
- 一次情報から答えの抜粋

# 作成手順・投稿設計

## ニュースの影響解説

### 作成手順

#### 1. 最新情報を調査する

参考URLが指定されている場合は、そのページの内容を最優先で確認してください。
そのうえで、調査メモでテーマに関する動向を確認してください。

優先順位：
1. 公式発表・当事者の一次情報
2. 公式ドキュメント・GitHub・論文・決算資料
3. 信頼できる報道
4. 専門家の分析
5. 公開されている反応・言及

「いつ発表されたか」「何が新しいか」「従来と何が違うか」まで確認してください。

十分に新しくない場合は「速報」と表現しないでください。

#### 2. 「つまり」を3段階掘る

最重要ニュースについて、

① 何が起きた？
② つまり、何ができる・変わる？
③ その結果、<ベースプロンプト>の読者の仕事・市場・行動はどう変わる？

まで推論してください。

投稿の価値は③に置き、
ニュース要約だけで終わらせないでください。

#### 3. 独自の切り口を探す

いま何が注目されているかも調査メモで確認し、

「多くの人が見ている点」
と
「実際に影響が大きい点」

にズレがないか探してください。

特に、

「みんなAを見ているが、重要なのはB」
「発表されたAより、その結果起きるBの方が大きい」

という二次・三次効果を優先してください。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 新規性
- 一瞬で理解できる
- <ベースプロンプト>の読者への影響が伝わる
- 続きを読みたくなる

ものを採用してください。

### 投稿設計

基本構造：

1. 何が起きたか＋最大の意味
2. 従来との違い
3. なぜ重要なのか
4. <ベースプロンプト>の読者への具体的な影響
5. 次に起きそうなこと
6. 一文で結論

原則は、1つの投稿で核心まで伝えてください。

ただし、

- 独立して重要な論点が複数ある
- 複数の影響を順番に理解した方が分かりやすい
- 各投稿単体でも新しい発見を提供できる

場合はスレッドを選んでください。

スレッドでも1投稿目だけで
「何が起きたか＋なぜ重要か」
まで理解できるようにしてください。

## 一次情報から答えの抜粋

### 作成手順

#### 1. 読者が知りたい問いを特定する

テーマについて、
<ベースプロンプト>の読者が今もっとも知りたいことを1つに絞ってください。

例：

- 各社はAIをどう使うと言っているのか
- 各経営者は今回の決算をどう評価しているのか
- 新製品を実際に使った人は何と言っているのか
- 各陣営は今回の条件をどう見ているのか
- 各社は新制度にどう対応するのか

投稿内でこの問いを長く説明する必要はありません。

#### 2. 一次情報を調査する

まず調査メモを確認してください。

優先順位は以下です。

1. 本人・企業・組織による公式発表
2. 会見、インタビュー、決算説明会などの本人発言
3. 信頼できる報道機関による直接取材
4. その他の二次情報

できる限り一次情報まで遡ってください。

古い情報よりも最新情報を優先し、
テーマに日付やイベントが関係する場合は対象時点を明確にしてください。

#### 3. 「答えになる部分」だけを抜き出す

情報量を増やすのではなく、
読者が知りたい問いへの答えになっている部分だけを残してください。

各項目は基本的に、

対象者・企業・商品名など
「答え」

の2段構成にします。

前置き、背景説明、挨拶、一般論など、
その部分を削除しても意味が変わらない文章は削ってください。

問いに答えるのに必要な項目に絞ります。

#### 4. 並べる価値を作る

単に発言を羅列するのではなく、
並べることで違いが見える情報を優先してください。

例えば、

- 強気 / 慎重
- 賛成 / 反対
- 期待 / 懸念
- 高評価 / 低評価
- 同じ質問への異なる回答
- 同じニュースに対する各社の対応

などです。

読者が一覧を見ただけで比較できる状態を目指してください。

### 投稿設計

基本構造は以下です。

① 何についての情報なのかを1〜2行で明示

② 対象名

③ その対象について最も重要な「答え」

④ ②〜③を複数並べる

余計な導入や長い総括は原則不要です。

投稿そのものを「答え一覧」として成立させてください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- ニュースの影響解説：発表された事実と、その先の影響を分けたか。要約だけで終わらず、読者に何が変わるかまで伝わるか。
- 一次情報から答えの抜粋：各項目が同じ問いへの答えか。原文の趣旨・条件を保ち、一覧で違いが見えるか。長い前置きや総括が答えを埋めていないか。

# 投稿例

## 例1：単発

新しいAIモデルが発表。

ベンチマーク以上に見るべきなのは、
「人間なしでどこまで仕事を進められるか」です。

AI競争は、

答えが上手い
↓
仕事を最後まで終えられる

に移り始めています。

モデル性能が上がるほど、
次の差になるのは「実行力」です。


## 例2：長文

あるAIサービスが大幅値下げ。

ニュースだけ見ると
「安くなった」で終わります。

でも重要なのは、
これまで人間や外注に任せていた仕事まで
ソフトウェアへ移せる価格帯に入る可能性があること。

技術の進化は、
性能が上がった瞬間より

「経済合理性が逆転した瞬間」

に市場を大きく変えることがあります。

新しいAIを見るとき、

何ができるようになった？
だけでなく

その価格なら、
誰の仕事や売上を置き換えられる？

まで見る。

僕ならこちらを重視します。


## 例3：スレッド

1/

新しいAI開発基盤が、
複数エージェントの連携を強化。

重要なのは
「AIがまた少し賢くなった」ことではありません。

AIが

1人の助手
↓
複数人のチーム

に近づいていることです。

大きな変化は3つあります。

2/

1つ目。

これまでは、

人間
→ AI A
→ 人間
→ AI B

と、人間がAI同士をつないでいました。

これが、

人間
→ AI A ↔ AI B ↔ AI C

に近づく。

人間の仕事が
「各作業を実行する」から
「チームに目的を渡す」へ移ります。

3/

2つ目。

するとAIの評価軸も変わります。

単体の回答性能だけでなく、

・仕事を分担できるか
・状態を引き継げるか
・失敗から復旧できるか
・長時間動けるか

が重要になる。

4/

つまり今回の発表は、
単なる新機能追加というより

AIエージェント競争が

「一番賢いAIはどれか」

から

「一番仕事を任せられるAIチームはどれか」

へ進む兆候として見ると面白いです。


## 統合した切り口の例：2026最新：一次情報・答え抜粋型

### 例1

高松宮記念2026　枠順後の陣営の声抜粋

パンジャタワー
「外枠になるより良かったです」

ナムラクレア
「並びを見たら競馬がしやすいなという印象」

ペアポルックス
「大谷選手の背番号と同じなのはうれしいですね」

ジューンブレア
「相手の出方を見るなら一番いい枠」


### 例2

生成AI導入について、経営者の発言だけ抜粋

A社 CEO
「全社員が日常的に使う前提で業務を再設計する」

B社 CEO
「まずは開発とカスタマーサポートから導入する」

C社 CEO
「コスト削減より、新しい売上を作れるかを重視している」

D社 CEO
「機密情報を扱う業務への導入は慎重に進める」


### 例3

新しい働き方制度について、社員が気になる部分だけ抜粋

出社頻度
「原則として週3日」

対象者
「国内勤務の正社員」

開始時期
「10月から順次適用」

例外
「育児・介護などの事情がある場合は個別に対応」

投稿例

AIを使うほど、 仕事が速くなる。 これは半分正しくて、 半分間違っています。 本当に差がつくのは 1回の仕事をどれだけ速く終えるかではない。 3案作る。 5パターン試す。 10社調べる。 20回改善する。 AIで浮いた時間を 「試行回数」に変えられるかです。 AI時代に強いのは、 仕事が速い人というより 同じ時間で より多く試せる人だと思う。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 狙い
根拠と条件から、読者の判断を更新する意見・仮説・予測を示す。

# 切り口の選択
今回の題材と依頼に合う切り口を次から1つ選び、その切り口の作成手順と投稿設計だけを使ってください。選ばなかった切り口の流れや結論を混ぜないでください。
- 常識の見直し
- 根拠のある仮説・意見
- 未来予測・二次効果

# 作成手順・投稿設計

## 常識の見直し

### 作成手順

#### 1. 壊す価値のある「常識」を探す

テーマについて、

- 広く信じられている定説
- 最近よく繰り返されているアドバイス
- 初心者ほど信じやすい考え
- 昔は正しかったが環境変化で怪しくなった考え
- その常識と矛盾するデータ・事例

を探してください。

複数候補から、

「多くの<ベースプロンプト>の読者が信じている」
かつ
「見方を変えると実際の判断・行動まで変わる」

ものを選んでください。

#### 2. 逆説ではなく「新しい理解」を作る

主張は次のような構造を検討してください。

- Aではなく、本当に重要なのはB
- A自体は正しい。ただし結果を分けるのはB
- Aが増えるほど、逆にBの価値が上がる
- 昔はAだったが、今は前提が変わってBになった
- Aを最適化しすぎると、別のBがボトルネックになる

「世間と逆のことを言える」だけの案は捨ててください。

#### 3. 反論に耐えるか確認する

採用候補について、

「この主張への最も強い反論は何か？」

を考えてください。

その反論を踏まえても成立するように、
条件・根拠・具体例を整えてください。

投稿を読み終えたとき、
冒頭より読者の理解が深くなっていることを必須とします。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 一瞬で理解できる
- 違和感がある
- <ベースプロンプト>の読者に関係する
- 理由を知りたくなる

ものを採用してください。

### 投稿設計

基本構造：

1. 常識を揺さぶる結論
2. 一般にはなぜAと考えられているか
3. それだけでは説明できない事実・具体例
4. 本当に重要なB
5. なぜA→Bの変化が起きるのか
6. 読者の判断・行動がどう変わるか
7. 一文で新しい見方を残す

原則は、単発〜長文で主張から納得まで完結させてください。

ただし、

- 独立した強い根拠が複数ある
- 有力な反論も扱う必要がある
- 結論まで段階的に理解させた方が説得力が大きく上がる

場合はスレッドを選んでください。

スレッドでも1投稿目で
「常識」と「今回の主張」まで明示してください。

## 根拠のある仮説・意見

### 作成手順

#### 1. 意見が割れる論点を探す

テーマについて、

- 多数派と少数派が存在する論点
- 専門家でも判断が分かれる問題
- 最近、前提が変わり始めた常識
- どちらにも合理的な理由がある選択
- <ベースプロンプト>の読者の仕事・お金・将来に関係する争点

を探してください。

単なる好みではなく、
「どちらを信じるかで行動が変わる論点」を優先してください。

#### 2. 明確な立場を取る

複数の主張候補を考え、

- 反対意見が成立する
- それでも自分側にも十分な根拠がある
- <ベースプロンプト>の読者にとって重要
- 一文で立場が分かる
- ありきたりではない

ものを選んでください。

「場合によります」で逃げず、
条件を明確にした上で立場を取ってください。

#### 3. 反対側を最も強い形で考える

投稿を書く前に、

「この主張への最も強い反論は何か？」

を考えてください。

弱い反対意見を作って勝ったことにせず、
その反論を認めた上でも自分がこの立場を取る理由を整理してください。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 立場が一瞬で分かる
- 少し反論したくなる
- 理由を知りたくなる
- <ベースプロンプト>の読者に関係する

ものを採用してください。

### 投稿設計

基本構造：

1. 明確な主張
2. 多数派が逆を考える理由
3. 自分がこの立場を取る根拠
4. 具体例・データ・構造
5. 最も強い反論
6. それでも結論が変わらない理由
7. どの条件なら逆になるか
8. 一文で立場を残す

原則は単発〜長文で、
主張と主要な根拠まで一度に伝えてください。

ただし、複数の独立した根拠や反論を順番に検討することで
議論の質が大きく上がる場合はスレッドにしてください。

スレッドでも1投稿目で
「今回取る立場＋最大の理由」
まで明示してください。

## 未来予測・二次効果

### 作成手順

#### 1. 現在のシグナルを集める

調査メモからテーマについて

- 技術進歩
- 価格・コスト変化
- ユーザー行動
- 企業の投資・採用・撤退
- 新しいサービス
- 規制・制度
- 市場構造
- 専門家・当事者の発言

など、直近の変化を集めてください。

1つのニュースだけで未来を予測せず、
可能なら複数の独立したシグナルが同じ方向を示すものを優先してください。

#### 2. 一次効果の先まで考える

予測候補について、

現在の変化
↓
一次効果：直接何が変わる？
↓
二次効果：その結果、人や企業はどう行動を変える？
↓
三次効果：さらに何の価値が上がる・下がる？

まで考えてください。

投稿では、
誰でも予想できる一次効果より
二次・三次効果を主役にしてください。

例：

AIで開発が速くなる
↓
作られるサービスが増える
↓
機能差が縮まる
↓
営業・ブランド・顧客基盤の価値が上がる

#### 3. 予測の妥当性を確認する

採用する前に内部で、

- 過去の似た変化では何が起きたか
- この予測が外れるとしたら何が原因か
- 別の未来も十分あり得ないか
- どの時間軸なら現実的か

を確認してください。

遠い未来ほど断定を弱め、
近い未来ほど具体的にしてください。

ただし投稿を不必要な注意書きだらけにしないでください。

#### 4. 最も強い未来を選ぶ

複数候補から、

- 現在の根拠が強い
- 一次効果より一段先を読んでいる
- <ベースプロンプト>の読者への影響が大きい
- 少し意外だが論理的
- 今知ることで行動が変わる

ものを選んでください。

#### 5. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 未来像が一瞬で分かる
- 意外性がある
- 「なぜ？」と思う
- <ベースプロンプト>の読者に関係する

ものを採用してください。

### 投稿設計

基本構造：

1. 未来予測を明確に提示
2. 今起きているシグナル
3. 一次効果
4. 二次・三次効果
5. なぜその未来が起きるのか
6. <ベースプロンプト>の読者への影響
7. 今から見るべき・変えるべきこと

1本の因果関係で十分伝わるなら、
原則は単発〜長文で完結させてください。

複数の独立したシグナルや、
「現在→一次効果→二次効果→三次効果」を段階的に見せることで
説得力が大きく上がる場合はスレッドにしてください。

スレッドでも1投稿目で
「予測＋最大の理由」
まで明示してください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 常識の見直し：冒頭より理解が深まり、読者が変える判断を示したか。最も強い反論を踏まえても主張が成り立つか。
- 根拠のある仮説・意見：反対側を最も強い形で考えてもこの立場を取る理由があるか。どの条件なら逆の判断になるかが分かるか。
- 未来予測・二次効果：現在のシグナルから二次・三次効果まで論理がつながるか。別の未来、外れる兆候、想定する時間軸を検討したか。

# 投稿例

## 例1：単発

AIを使うほど、
仕事が速くなる。

これは半分正しくて、
半分間違っています。

本当に差がつくのは
1回の仕事をどれだけ速く終えるかではない。

3案作る。
5パターン試す。
10社調べる。
20回改善する。

AIで浮いた時間を
「試行回数」に変えられるかです。

AI時代に強いのは、
仕事が速い人というより

同じ時間で
より多く試せる人だと思う。


## 例2：長文

AIでソフトウェア開発が簡単になるほど、
「作れること」の価値は相対的に下がると思っています。

一見すると逆です。

開発速度が上がる。
少人数でも作れる。
個人でもサービスを出せる。

当然、エンジニアリングの生産性は上がる。

でも全員の開発コストが下がると、

作れるサービスが増える
↓
似た機能が増える
↓
機能だけでは差がつきにくくなる

という変化も起きる。

すると次に希少になるのは、

何を作るか
誰に売るか
どう届けるか
なぜ選ばれるか

の方です。

AIが開発を民主化するほど、
事業のボトルネックは
開発からDistributionへ移る可能性がある。

技術の価値がなくなるのではない。

技術だけで勝てる希少性が下がる。

ここは分けて考えた方がいい。


## 例3：スレッド

1/

「AIが進化すると、若手の価値は下がる」

一見かなり合理的です。

調査。
資料作成。
コード。
データ整理。

これまで若手が担当していた仕事を
AIが代替し始めている。

でも僕は、
逆の可能性もあると思っています。

2/

AIが代替するのは、
「若手」そのものではありません。

若手に任せていた
作業の一部です。

ここを分けて考える必要があります。

3/

作業がAIへ移ると、

以前：
若手1人 → 作業中心

これから：
若手1人＋AI → 作業＋分析＋提案

のように、
若い段階から任せられる仕事の幅が広がる可能性がある。

4/

もちろん、

「ジュニア業務がなくなれば育成機会もなくなる」

という問題はあります。

これはかなり大きい。

だから若手の価値が
自動的に上がるとは言えません。

5/

ただし結論は、

AI → 若手不要

ほど単純ではないと思う。

むしろ、

AI前提で若手を育成できる会社
と
従来のジュニア業務に依存する会社

で差が広がる。

AIによって変わるのは
若手の価値というより、

「若手に何を任せるか」

なのかもしれません。


## 統合した切り口の例：大胆仮説・Hot Take

### 例1：単発

AI時代ほど、
営業の価値は上がると思っています。

一見逆です。

メールはAIが書く。
提案書もAIが作る。
顧客リストもAIが探す。

だから営業は減りそうに見える。

でも同時に、

作れる会社が増える
↓
似た商品が増える
↓
機能差が縮まる
↓
「なぜ自社を選ぶか」の重要性が上がる

という変化も起きる。

AIが消すのは営業というより、
付加価値の低い営業。

商品が作りやすくなるほど、
売れる仕組みの希少性は上がると思う。


### 例2：長文

スタートアップ初期なら、
「競合がいない市場」より
競合がいる市場の方を選びたい。

普通は逆に見えます。

競合がいない。
つまりブルーオーシャン。

魅力的です。

でも競合がいない理由は、

誰も気づいていない

だけではなく、

そもそも顧客がお金を払わない

可能性もある。

競合がいる市場には少なくとも、

顧客が存在する
課題が存在する
支払い実績が存在する

という証拠がある。

もちろん競争は激しくなる。

だから
「競合が多いほど良い」
ではありません。

ただ初期の新規事業なら、

競合の存在をリスクではなく
需要の証拠として見る方がいいと思っています。


### 例3：スレッド

1/

AI時代、
大学に行く価値は下がる。

この意見はかなり分かります。

知識だけならAIから学べる。
講義もオンラインで見られる。

でも僕は、
むしろ一部の大学の価値は上がる可能性があると思っています。

理由は「授業」ではありません。

2/

AIによって安くなるのは
知識へのアクセスです。

以前：

良い知識
→ 大学・専門家が持っている

これから：

良い知識
→ AIで誰でもアクセスできる

ここだけ見ると、
大学の価値は下がります。

3/

でも、
知識がコモディティ化すると
別のものが希少になります。

・誰と学ぶか
・誰と働くか
・どんな環境に入れるか
・どんな人から評価されるか

つまりネットワークや選抜機能です。

4/

もちろん、

「そのためだけに高い学費を払うのか」

という反論は強い。

大学によっては
費用対効果がさらに悪くなる可能性もある。

5/

だから僕の主張は、

「大学は全部重要になる」

ではありません。

AIによって

知識提供だけの大学
と
強い人材・ネットワークを集められる大学

の価値差がむしろ広がる、です。

AIが大学を消すというより、
大学の価値を「授業」以外へ移す可能性があると思っています。

## 統合した切り口の例：未来予測・二次効果予測

### 例1：単発

AIでソフトウェア開発が安くなるほど、
営業の価値は上がると思う。

開発コストが下がる
↓
作る会社が増える
↓
似たサービスが増える
↓
機能だけでは差がつきにくくなる

その結果、
希少になるのは

「作れる会社」

ではなく

「選ばれる会社」。

AIがエンジニアリングを民主化するほど、
Distributionの価値はむしろ上がる可能性がある。


### 例2：長文

数年後、
「AIを使える人」という言葉は
かなり意味を失うと思っています。

今はまだ、

ChatGPTを使える
Claude Codeを使える
AIエージェントを使える

こと自体に差がある。

でも普及すれば、
AIを使うことは
検索やExcelと同じ前提になる。

すると希少性が移る。

何を調べるか。
何を作るか。
どこまで任せるか。
何を信じるか。
どこで人間が判断するか。

AIが賢くなるほど、
操作方法を知っていることより
「判断する場所を決められること」が重要になる。

AIスキルの価値が消えるのではない。

価値の中心が
操作から判断へ移ると思う。


### 例3：スレッド

1/

AIエージェントが普及すると、
「仕事が自動化される」

より先に起きると思うことがあります。

人事評価が変わる。

作業量で人を評価するのが
かなり難しくなると思っています。

2/

これまでは、

資料を20枚作った
100件営業した
10時間作業した

のように、
人間の作業量が成果の代理指標になっていました。

3/

でもAIが、

調査
文章作成
資料作成
分析

を大量に代替すると、

「何時間作業したか」

と

「どれだけ価値を出したか」

がさらに離れていく。

4/

すると評価軸は、

どれだけ作業したか
↓
何を決めたか
↓
何を実現したか

へ移る可能性がある。

5/

さらにその先。

成果で評価される比率が上がるなら、

職種
勤務時間
チーム人数

の意味まで少しずつ変わるかもしれない。

6/

AIが変えるのは、
作業方法だけではない。

「仕事とは何を評価するものか」

まで変える可能性がある。

AIニュースを見るとき、
僕なら生産性だけでなく
評価制度の変化も追います。

投稿例

忙しいことより、 「全部ちょっとずつ自分の責任」 なのが一番疲れる。 1つ1つは大した仕事じゃない。 でも頭の片隅に 「忘れちゃいけない」が20個ある。 忙しさって、 労働時間だけでは測れない。 脳内に残っている 未完了の数でも決まる。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 狙い
身近な場面の本音やおかしさを言葉にし、読者が自分の経験を重ねられる投稿にする。

# 切り口の選択
今回の題材と依頼に合う切り口を次から1つ選び、その切り口の作成手順と投稿設計だけを使ってください。選ばなかった切り口の流れや結論を混ぜないでください。
- 本音の言語化
- ユーモア・あるある

# 作成手順・投稿設計

## 本音の言語化

### 作成手順

#### 1. まだ言語化されていない本音を探す

<ベースプロンプト>の読者の一日を思い浮かべ、

- 繰り返しこぼしていそうな不満・違和感
- 表向きの常識と現場の実感のズレ
- 人前では言わないが、同業者どうしなら言う本音
- 経験者ほど感じるが言葉になっていないこと
- 最近の環境変化で生まれた新しいストレス

を挙げてください。

「多くの人が経験している」
かつ
「まだ使い古された表現になっていない」
ものを優先してください。

#### 2. 表面的な感情を一段深くする

本音候補について、

「本当に嫌なのは何？」
「なぜそれが疲れる？」
「その感情の正体は何？」

と掘ってください。

例：

「会議が多くてつらい」
↓
「会議より、話しても何も決まらないことがつらい」
↓
「本当の問題は時間ではなく、意思決定者が曖昧なこと」

最後の一段を投稿の核心にしてください。

#### 3. 最も刺さる入口を選ぶ

冒頭候補を内部で複数作り、

- 「自分の話だ」と瞬時に感じる
- 具体的な場面が浮かぶ
- 言語化に新しさがある
- 続きを読みたくなる

ものを採用してください。

### 投稿設計

基本は、

1. 本音・違和感を一撃で言語化
2. 読者が経験したことのある具体的な場面
3. 一般的な理解とのズレ
4. なぜそう感じるのか
5. 感情の正体・構造を一段深く言語化
6. 余韻の残る一文で締める

としてください。

原則は単発〜長文で、
1つの本音を鋭く伝えてください。

ただし、複数の異なる場面を順番に見せることで
「全部同じ本音につながっていた」と気づかせる方が強い場合は
スレッドを選んでください。

## ユーモア・あるある

### 作成手順

#### 1. <ベースプロンプト>の読者だけが分かる「あるある」を探す

<ベースプロンプト>の読者が実際によく経験している

- 小さな失敗
- 面倒な瞬間
- 矛盾
- 建前と本音のズレ
- 無意識にやってしまう行動
- 業界特有の習慣
- 最近増えた新しい現象

を挙げてください。

「会社員は月曜日が嫌い」のような
広すぎるあるあるではなく、

経験者ほど
「そこを切り取るのか」
と思う具体的な場面を優先してください。

#### 2. 「誰かに送りたくなるか」で選ぶ

候補ごとに、

「これを見たとき、
<ベースプロンプト>の読者の頭に特定の友人・同僚・職種が浮かぶか？」

を確認してください。

単に面白いものより、

「これ完全に〇〇さん」

と送りたくなるものを優先してください。

#### 3. 笑いに変換する

あるあるをそのまま言うのではなく、
以下から最も自然な笑いの構造を選んでください。

- 逆転
  普通の解釈と結果を逆にする

- 誇張
  小さな現象を大事件のように扱う

- 比喩
  全く別のものとして言い換える

- 本音化
  建前の裏にある本音をそのまま言う

- 定義化
  日常の現象に妙に正確な名前をつける

- Before → After
  理想と現実を並べる

- セリフ化
  頭の中の声や会話にする

- 期待 → 裏切り
  読者が予想した着地点を少しだけ外す

- 過剰に論理的
  くだらない出来事を真面目に分析する

最も説明なしで伝わるものを選んでください。

#### 4. 一番短く伝わる形まで削る

ユーモアは説明すると弱くなります。

内部では複数案を作り、

- すぐ意味が分かる
- 「あるある」が具体的
- オチを説明していない
- 一度読んで理解できる
- 声に出したとき自然
- スクリーンショットして共有できる

ものを採用してください。

面白さが増えない文は削ってください。

#### 5. ミームやネットスラングは、確信があるものだけ使う

既存のミーム・構文・ネットスラングは、
いま使われていると確信できるものだけ使ってください。

確信が無ければ使わず、
逆転・定義化などの構造だけで作ってください。

流行している型を使う場合も、
元投稿をコピーせず、
構造だけを参考にして完全にオリジナルの内容を作ってください。

### 投稿設計

この型は原則として
単発投稿を優先してください。

基本形：

具体的な状況
↓
<ベースプロンプト>の読者が認識
↓
少し予想させる
↓
最後の一言でズラす

または、

強いあるある
↓
予想外の比喩・定義

だけでも構いません。

文章量は固定せず、
オチが最も強くなる長さを選んでください。

長く説明するほど面白さが増える場合を除き、
不要な背景説明は入れないでください。

スレッドは原則使いません。

ただし同じテーマで
独立して成立する複数の「あるある」を連作として見せること自体に価値がある場合のみ使用してください。

### ユーモアの品質基準

良い投稿は、

「面白い」

だけではなく、

「分かる」
＋
「この表現は思いつかなかった」

が同時にあります。

特に、

普通の出来事
＋
少し異常に正確な表現

を狙ってください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 本音の言語化：具体的な場面から感情の正体へ届いたか。表面の愚痴を言い換えるだけで終わっていないか。
- ユーモア・あるある：「分かる」と「この表現は思いつかなかった」が両立するか。一度で理解でき、声に出して自然か。オチの後に教訓や笑いの説明を足していないか。

# 投稿例

## 例1：短文

忙しいことより、

「全部ちょっとずつ自分の責任」

なのが一番疲れる。

1つ1つは大した仕事じゃない。

でも頭の片隅に
「忘れちゃいけない」が20個ある。

忙しさって、
労働時間だけでは測れない。

脳内に残っている
未完了の数でも決まる。


## 例2：長文

AIで仕事が楽になるはずなのに、
前より疲れている人もいると思う。

文章を書く。
調べる。
整理する。

作業自体は確実に速くなった。

でも代わりに、

ChatGPTかClaudeか。
この仕事はAIに任せていいか。
この回答を信じていいか。
新しいツールを試すべきか。

をずっと判断している。

AIで減ったのは「作業」。

増えたのは「選択」。

AI時代の疲労って、
仕事量だけではなく

「決め続けること」

から来る部分もかなりありそう。


## 例3：スレッド

1/

マネージャーになって大変なのは、
仕事量が増えることだと思っていました。

少し違いました。

一番疲れるのは、

「自分の仕事ではないのに、
最後は自分が気にしないといけないこと」

が増えることでした。

2/

メンバーのタスク。

顧客への返信。

別部署との調整。

来月の計画。

今日決めなくてもいい。

でも忘れると困る。

だから全部、
頭のどこかで起動したままになる。

3/

プレイヤー時代は、

仕事を終わらせれば
頭から消せました。

マネージャーになると、

「終わらせる仕事」

より

「忘れない仕事」

が増える。

4/

管理職の疲れって、
単純な仕事量ではなく

「自分が覚えておく必要のある未来」

の多さなのかもしれない。


## 統合した切り口の例：ユーモア・あるある・ミーム化

### 例1：日常逆転

AIで資料作成が10倍速くなった。

その結果、

資料を10倍作るようになった。


### 例2：業界あるある＋定義化

「一度社内で確認します」

BtoB営業における
最も実装期間の長いAPI。


### 例3：期待→裏切り

AIエージェントに仕事を全部任せる未来を想像していた。

現実：

AIエージェント5人の
進捗確認ミーティングをしている。

投稿例

※以下の数値は構造を示すための例です。

売上は20%増。 これだけなら 「順調に成長した」で終わります。 でも、 売上：100 → 120 利益：10 → 20 なら見え方が変わる。 売上は1.2倍なのに、 利益は2倍。 重要なのは売上成長ではなく、 「追加の売上が以前より大きく利益として残る構造」 に変わっていることです。 事業を見るなら、 成長率だけではなく 成長した1円がどこへ行くかまで見たい。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 狙い
数字や事例、証拠のつながりから、読者の判断が変わる発見を取り出す。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 数字の解釈
- 複数事例のパターン抽出
- 深い調査から1つの結論
# 作成手順・投稿設計
## 数字の解釈
#### 1. 強いデータを探す
調査メモからテーマに関する最新データを集めてください。
公式統計、決算、一次資料、論文、公式ベンチマークなどを優先し、
- 成長率
- 売上・利益
- 利用者数・利用時間
- 市場シェア
- 費用・時間
- 導入率
- 過去との変化
- 競合との差
などを広く確認する。
数字は必ず、期間・母数・比較条件・元データまで確認する。
#### 2. 「驚き」ではなく「認識が変わる数字」を選ぶ
候補から、
- 想像より大きい / 小さい
- 過去や競合と比べると異常
- 相対値と絶対値で印象が変わる
- 別の数字と組み合わせると新しい意味が見える
- <ベースプロンプト>の読者の判断・行動が変わる
ものを選んでください。
「100%増」のような数字は、
元の規模が小さくないかも必ず確認する。
#### 3. 数字を人間が理解できる形に変換する
必要に応じて、
- 前年・数年前との比較
- 競合・業界平均との比較
- 1日 / 1人 / 1件あたり
- Before → After
- 絶対値と割合の両方
で示してください。
比較することで意味が薄くなる場合は、無理に例えを作らないでください。
#### 4. 「つまり」を一段深くする
以下を考えてください。
① 数字上、何が起きている？
② 一般的にはどう解釈される？
③ 実は何を示している？
④ その結果、<ベースプロンプト>の読者に何が変わる？
投稿の中心は③〜④です。
数字を紹介して終わらせず、
「この数字によって何の見方を変えるべきか」まで示してください。
#### 5. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 数字＋比較だけで驚きが伝わる
- 一瞬で理解できる
- <ベースプロンプト>の読者に関係する
- 解釈の続きを知りたくなる
ものを採用する。
### 投稿設計
1. 最も強い数字＋比較
2. なぜその数字が異常なのか
3. 一般的な解釈
4. 一段深い解釈
5. <ベースプロンプト>の読者への影響
6. 一文で結論
1つの数字と比較だけで洞察が成立するなら、
原則は単発〜長文で完結させてください。
一方で、
- 複数の独立したデータが同じ方向を示している
- 時系列で変化を追う必要がある
- データA→B→Cを組み合わせて初めて結論が見える
場合はスレッドを選んでください。
スレッドでも1投稿目で
「最重要データ＋今回の解釈」
まで示してください。
## 複数事例のパターン抽出
#### 1. 比較するサンプルを集める
調査メモからテーマに関する十分な数の事例を集めてください。
可能なら、
- 成功・高反応事例
- 平均的な事例
- うまくいかなかった事例
を比較する。
有名な成功例だけを集めて
「共通点＝成功要因」と判断しないでください。
投稿を分析する場合は、
アカウント規模だけで伸びた事例を避けるため、
可能ならその投稿者の通常投稿との相対差も確認する。
#### 2. 先入観を持たずに特徴を分解する
各事例を、テーマに応じて
- 最初の行動・戦略
- 判断基準
- 順番
- 数字
- 共通する制約
- やっていること
- やっていないこと
- X投稿ならフック・構成・具体性・形式
などに分解する。
最初から「これが成功要因だ」と決めず、
データから繰り返し現れる特徴を探してください。
#### 3. 本当に強いパターンだけ残す
候補について、
- 複数の独立した事例で確認できる
- 成功例だけでなく比較対象との差がある
- 当たり前すぎない
- <ベースプロンプト>の読者が再現できる
- なぜ効くのか説明できる
ものを残してください。
反例も探し、
「常に成立する法則」なのか
「特定条件で強い傾向」なのかを区別する。
#### 4. 最も意外で使える発見を選ぶ
主要なパターンに絞り、
「一番有名な特徴」ではなく、
調査前には気づきにくかった発見を中心にしてください。
特に、
「成功例は〇〇をしている」
より
「成功例と普通の事例を分けていたのは△△だった」
という比較を優先する。
#### 5. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 調査量に信頼感がある
- 発見を知りたくなる
- <ベースプロンプト>の読者に関係する
- 結論に意外性がある
ものを採用する。
### 投稿設計
1. 何を比較したか
2. 最大の発見
3. 共通パターン①
4. 共通パターン②
5. 共通パターン③
6. 反例・成立条件
7. パターンを束ねる本質
8. 読者がどう使えるか
発見が1つに集約できるなら単発〜長文で完結させてください。
複数のパターンそれぞれに具体例・反例・示唆があり、
個別に読む価値がある場合はスレッドにしてください。
スレッドでも1投稿目で
「調査対象＋最大の発見」
まで明示する。
## 深い調査から1つの結論
#### 1. テーマを「答える価値のある問い」に変える
いきなり情報収集を始めず、
{テーマ}について<ベースプロンプト>の読者の判断が変わる問いを複数考えてください。
例：
「AIエージェントの最新動向」
ではなく
「AIエージェントによって最初に価値が下がる仕事は何か？」
「ステーブルコイン市場」
ではなく
「普及のボトルネックは技術・規制・Distributionのどれなのか？」
「最新AIモデル」
ではなく
「モデル性能が上がるほど、企業の競争優位はどこへ移るのか？」
最も重要な問いを1つ選んでください。
#### 2. 広く調査する
調査メモの証拠を横断して確認する。
<today>から見て直近1年ほどの情報を優先し、
必要な場合のみ過去の重要情報まで遡ってください。
情報源の優先順位：
1. 公式発表・一次資料
2. 公式ドキュメント・GitHub・決算・統計・論文
3. 信頼できる調査機関・専門メディア
4. 当事者・専門家による発信
5. 公開されている反応・言及・体験談
SNS上の意見だけで事実を確定しないでください。
#### 3. 証拠を「数」ではなく「独立性」で見る
同じ一次情報を引用している複数の記事を、
別々の証拠として扱わないでください。
各重要情報について内部で、
- 何が事実か
- 情報源は何か
- いつの情報か
- 他の証拠から独立しているか
- 何を支持しているか
- 何と矛盾しているか
を確認する。
#### 4. 最低2つの対立仮説を作る
最初に思いついた結論へ
都合の良い情報だけ集めないでください。
例：
仮説A：
AIによってエンジニアの価値が下がる
仮説B：
AIによって高スキルエンジニアの価値はむしろ上がる
仮説C：
価値が変わるのはエンジニア自体ではなく仕事内容
のように複数の説明を作り、
それぞれを支持・反証する証拠を調べてください。
#### 5. 「最も重要な結論」を1つ選ぶ
調査結果から、
- 複数の独立した証拠で支えられる
- <ベースプロンプト>の読者の判断が変わる
- 単なる事実の要約ではない
- 少し意外だが論理的
- 一文で説明できる
結論を1つだけ選んでください。
結論を3つ、5つと並べないでください。
重要な論点が複数あっても、
それらを束ねる上位概念を探してください。
#### 6. 最も強い反証をぶつける
その結論に対して、
「この結論が間違っているとしたら？」
という視点から、
最も強い反対証拠・別解釈を探してください。
反証を踏まえても成立する範囲まで
結論を修正してください。
確信度以上に強く断定しないでください。
#### 7. 情報の90%を捨てる
調査した情報を
そのまま投稿へ入れないでください。
残すのは、
- 結論を理解するために必要
- 結論の信頼性を大きく上げる
- 読者の認識を変える
情報だけです。
「調べたから書く」は禁止です。
#### 8. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 重要な結論がすぐ分かる
- 「なぜそうなる？」と思う
- <ベースプロンプト>の読者に関係する
- 調査によって初めて見える視点がある
ものを採用する。
### 投稿設計
1. 最も重要な結論
2. なぜこの問いを調べたか
3. 最も強い証拠①
4. 最も強い証拠②
5. 最も強い証拠③
6. それらをつなぐ解釈
7. 最も強い反論・例外
8. それでも残る結論
9. <ベースプロンプト>の読者にとって何が変わるか
証拠の数は固定しないでください。
1つの論理で十分伝わるなら
長文1投稿で完結させてください。
複数種類の証拠を順番に積み上げることで
初めて結論に納得できる場合は、
スレッドを選んでください。
スレッドでも1投稿目で
最も重要な結論を隠さず提示する。
続きを読ませるために
結論を最後まで隠す構成は避けてください。
### 結論の品質基準
良い結論は、
「〇〇市場は成長している」
ではありません。
「〇〇市場の成長によって、
希少になるのはAではなくB」
のように、
既知の事実から新しい判断を導きます。
「A、B、Cが起きています」
で終わらず、
A
＋
B
＋
C
↓
だからD
まで到達してください。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 数字の解釈：期間・母数・単位・比較条件をそろえたか。割合と元の規模を見て、相関を原因へ飛躍させていないか。
- 複数事例のパターン抽出：成功例だけでなく普通・失敗の事例との差があるか。独立した事例と反例を見て、成立条件を法則から分けたか。
- 深い調査から1つの結論：同じ原典の転載を別の証拠として数えていないか。対立仮説と強い反証を検討し、それでも残る結論1つと成立条件を示したか。

# 投稿例

※以下の数値は構造を示すための例です。

## 例1：単発

売上は20%増。

これだけなら
「順調に成長した」で終わります。

でも、

売上：100 → 120
利益：10 → 20

なら見え方が変わる。

売上は1.2倍なのに、
利益は2倍。

重要なのは売上成長ではなく、

「追加の売上が以前より大きく利益として残る構造」

に変わっていることです。

事業を見るなら、
成長率だけではなく
成長した1円がどこへ行くかまで見たい。


## 例2：長文

毎日30分。

大した時間には見えません。

でも年間240営業日なら
120時間。

1日8時間働くなら、
15営業日です。

だからAIで見るべきなのは

「この作業が1回で何分速くなったか」

だけではない。

毎日発生する仕事を
何分消せるかです。

1回だけ2時間短縮するツールより、
毎日30分を削るツールの方が
年間インパクトは大きいことがある。

AIのROIは、
デモの感動より
「頻度 × 削減時間」で見ると分かりやすい。


## 例3：スレッド

1/

あるサービス。

ユーザー数が1年で10倍。

これだけでも強い数字ですが、
本当に見るべきなのはそこではありません。

同じ期間に
「1人あたり利用時間」まで伸びていたとしたら、

意味がかなり変わります。

2/

ユーザー数だけ増えている場合、

広告
キャンペーン
話題性

による一時的な流入でも説明できます。

つまり、

「試す人が増えた」

だけかもしれない。

3/

でも、

ユーザー数 ↑
利用頻度 ↑
利用時間 ↑

が同時に起きているなら、

単なる認知拡大ではなく
サービスが日常の行動に入り始めている可能性が高い。

4/

成長を見るとき、

何人が来たか
だけを見ると半分しか分からない。

何度戻ってくるか。
どれだけ深く使うか。

ユーザー数より
「利用の深さ」の方が重要な局面があります。


## 統合した切り口の例：大量に見て分かったパターン抽出

### 例1：単発

伸びているAI SaaSを見比べていて、
共通しているのは「AI性能の高さ」ではありませんでした。

むしろ目立つのは、

・用途が1文で分かる
・最初の成果までが速い
・AIを意識せず使える
・既存の仕事の流れに入っている

こと。

逆に、
「何でもできます」を売りにするサービスほど
使い方をユーザー側で考える必要がある。

AI SaaSで重要なのは
モデルの賢さだけではなく、

「ユーザーが考えることを
どれだけ減らせるか」

なのかもしれない。


### 例2：長文

伸びたX投稿と、
同じアカウントの普通の投稿を見比べると、
「テーマ」だけでは説明できないことがあります。

伸びた投稿には、

・冒頭で主張が分かる
・抽象論の直後に具体例がある
・1投稿1メッセージ
・読了後に残る一文がある

という特徴が繰り返し出てくる。

面白いのは、
文章が長いか短いかではありません。

短文でも伸びる。
長文でも伸びる。

差が出ていたのは、

「読み始めた瞬間に、
何を得られるか分かるか」

の方。

Xでは文章量より
理解までの距離を短くする方が重要そうです。


### 例3：スレッド

1/

複数の成功したSaaSと
伸びなかったサービスを比較すると、

成功例にはいくつか共通パターンがあります。

でも一番意外だったのは
「機能数」ではありませんでした。

差が大きかったのは、
最初の価値体験までの距離です。

2/

① 成功例は「登録後すぐ成果」が多い

アカウント作成
↓
大量の設定
↓
チュートリアル
↓
やっと価値

ではなく、

入力
↓
結果

までが短い。

機能が多いかより、
最初の「おお」が速い。

3/

② 用途が狭い

成功例を見ると、

「何でもできる」

より

「この仕事ならこれ」

の方が多い。

ユーザーが
使い方を考える必要が少ない。

4/

③ AIそのものを売っていない

「最新モデル搭載」

より、

「10分かかる仕事が2分になる」

の方が価値が分かりやすい。

技術を説明するより
仕事の変化を説明している。

5/

もちろん、
これだけで成功が決まるわけではありません。

Distribution、価格、市場規模など
他の要因も大きい。

ただ複数事例を比較すると、

「AIがどれだけ賢いか」

より

「価値に到達するまで
ユーザーが何回考えないといけないか」

の方が共通して差になっていました。

## 統合した切り口の例：Deep Research → 1つの重要結論

※以下は構造例です。
実際の投稿では必ず最新情報を再調査してください。


### 例1：長文

AIコーディングについて調べていて、
一番認識が変わったのはこれです。

「コードを書く速度」は、
これから競争優位になりにくくなる。

複数のAI開発ツールを見ると、

コード生成
修正
テスト
複数ファイル操作

までAIが担当する範囲が広がっている。

普通に考えると、

AIが進化
↓
開発が速くなる

で終わります。

でもその先があります。

開発が速くなる
↓
作れる会社が増える
↓
似た機能が増える
↓
コード自体の希少性が下がる

すると相対的に価値が上がるのは、

何を作るか
誰に売るか
何を捨てるか
品質をどう判断するか

の方。

AIコーディングの本当のインパクトは、
「エンジニアが速くなること」より

競争のボトルネックを
コードの外へ移すことなのかもしれません。


### 例2：長文

AIモデルを調べるほど、

「どのモデルが一番賢い？」

という問い自体が
少しずれていると思うようになりました。

ベンチマーク
価格
速度
ツール利用
長文処理
エージェント性能

を見ると、
全部で同じモデルが勝つわけではない。

さらに実務では、

モデル性能
×
成功率
×
やり直し回数
×
人間の確認時間

で最終的なコストが決まる。

だから重要なのは、

1回の推論価格

ではなく

「仕事を完了するまでの総コスト」。

AIモデル比較は
性能ランキングから

Task Economics

を見るフェーズへ移っていくと思う。


### 例3：スレッド

1/

AIエージェントについて調べると、
一番大きな変化は

「仕事が自動化されること」

ではないと思っています。

もっと大きいのは、

会社の仕事が
「人を管理する構造」から
「人＋AIを管理する構造」へ変わること。

複数の動きをつなげると、
この方向が見えてきます。

2/

まず、AIが担当できる範囲が

回答
↓
文章作成
↓
コード生成
↓
ツール操作
↓
複数ステップの実行

へ広がっている。

つまり、

「人間が作業してAIに聞く」

から

「人間が仕事を渡してAIが実行する」

へ近づいている。

3/

すると一次効果は、

人間の作業時間が減ること。

でもその次があります。

AIに仕事を任せるほど、

・何を任せるか
・どこまで権限を与えるか
・どう評価するか
・いつ人間が介入するか

を決める必要が出てくる。

4/

これはかなり
マネジメントに似ています。

AIが増えるほど、

プロンプトを書く能力

より、

仕事を分解する
完成条件を決める
結果をレビューする

能力が重要になる可能性がある。

5/

もちろん、
すべての仕事がエージェント化するとは限りません。

信頼性
コスト
セキュリティ
責任

などの制約も残る。

6/

それでも複数の動きをまとめると、

AIエージェントの本質は
「人間をなくすこと」

というより、

「マネジメントできる対象を
人間以外にも広げること」

なのかもしれない。

AIを追うなら、
モデル性能だけでなく

「AIへ仕事を渡す仕組み」

を見た方がいいと思っています。

投稿例

AIを使って仕事が速くなる人と、 逆に忙しくなる人。 差はAIの性能ではありません。 忙しくなる人 → 今の仕事をAIで速くする 速くなる人 → AI前提で仕事自体を組み直す 忙しくなる人 → 毎回ゼロから説明する 速くなる人 → 前提情報を再利用する 忙しくなる人 → 1回で完成させようとする 速くなる人 → 複数案を出して比較する AI活用の差って、 プロンプト力より 「仕事の設計を変えられるか」 に出る気がします。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 狙い
2者の行動や判断を並べ、結果を分ける境界と使い分けを見せる。

# 構成と判断
- 2者の対比、複数候補のおすすめ、保存して使う比較表を題材に合わせて選ぶ。候補が3つ以上でも同じ評価軸で比較し、順位を付けるなら基準と用途を示す。全員に同じ正解を押し付けない。
- 同じ観点で比べられ、読者の判断が変わるA/Bを選ぶ。片方を不当に愚かに描かない。
- 主要な違いを同じ順・同じ粒度で並べ、特に重要な差の理由や具体例を掘る。比較で確認できる差と、その理由の推測を分ける。材料に無いことを、実際にも無い・起きていないことへ置き換えない。
- 誰がどちらを選ぶか・何を変えるかが比較だけで伝わらなければ、用途や成立条件を添える。一覧ですでに伝えた使い分けを末尾でもう一度まとめない。人格の優劣にしない。
- 一覧性を保つ単発を基本とし、各比較軸の理由に独立した価値があるときだけスレッドにする。

# 切り口ごとの判断と点検
- ランキング・おすすめ：調査メモから候補を広く拾い、読者に重要な評価軸を決める。各候補の強み・弱み・導入条件を同じ軸で比べる。総合順位・用途別順位・条件別の選び方から適切な形を選び、無理な総合1位や根拠のない細かい点数を作らない。有名順に並べず、比較で見つかった意外な差を掘る。
- 概念・新旧・左右の比較：混同される概念、変化の大きいBefore/After、並べると初めて分かる差を選ぶ。時点・価格・数字・仕様を調査メモで確かめ、同じ項目を対応させる。概念なら使い分け、新旧なら実質の変化、左右なら比較を見るための文脈を示す。比較だけで伝わる場合は結論を足さない。
- 仕上げでは、読者が変える判断が分かるか、比較条件がそろうかを確かめる。未記載と不存在・未決定を混同せず、確認した差と理由の推測を分ける。一覧で伝わった選び方は末尾で反復しない。

# 投稿例

## 例1：単発

AIを使って仕事が速くなる人と、
逆に忙しくなる人。

差はAIの性能ではありません。

忙しくなる人
→ 今の仕事をAIで速くする

速くなる人
→ AI前提で仕事自体を組み直す

忙しくなる人
→ 毎回ゼロから説明する

速くなる人
→ 前提情報を再利用する

忙しくなる人
→ 1回で完成させようとする

速くなる人
→ 複数案を出して比較する

AI活用の差って、
プロンプト力より

「仕事の設計を変えられるか」

に出る気がします。


## 例2：長文

「つい相談したくなる人」と
「次から聞くのをやめる人」。

知識量より、質問の前後が違います。

相談したくなる人
→ まず自分で調べる

避けられる人
→ 最初から全部聞く

相談したくなる人
→ 「ここまでは分かった」と伝える

避けられる人
→ 「どうすればいいですか？」だけ

相談したくなる人
→ 教わったら試す

避けられる人
→ 「参考になりました」で終わる

相談したくなる人
→ 結果を報告する

避けられる人
→ その後何もない

差が出るのは理解力ではなく、

「相手の時間を使っている」

という感覚があるかどうか。

教えてもらうのが上手い人ほど、
教える側のコストを小さくしています。


## 例3：スレッド

1/

Xが伸びる人と伸びない人。

文章力だけを見ると
違いが分かりにくい。

でも投稿の「前後」まで見ると、
かなり差があります。

代表的な違いは5つ。

2/

① 投稿する前

伸びない人
→ 今日何を書こう？

伸びる人
→ 今回何を検証しよう？

前者は毎回作品を作る。

後者は毎回実験する。

3/

② 投稿した後

伸びない人
→ 表示回数を見る

伸びる人
→ どこが効いたか分解する

テーマ。
冒頭。
具体例。
長さ。
投稿時間。

数字を見るだけでなく、
原因の仮説を残す。

4/

③ 伸びなかったとき

伸びない人
→ 次はもっと頑張る

伸びる人
→ 1変数だけ変えてもう一度試す

ここが大きい。

投稿数が同じでも、
後者の方が学習回数は多くなる。

5/

結局、

Xが伸びる人は
「投稿をたくさん作る人」というより

「1投稿からたくさん学ぶ人」。

差を作るのは投稿量より、
学習速度なのかもしれません。


## 統合した切り口の例：ランキング・おすすめ比較

### 例1：単発

AI開発ツール、
「結局どれを使えばいい？」を整理すると、

総合1位を決めるより
用途別に分けた方が分かりやすいです。

自分でコードを見ながら高速に直す
→ A

まとまった開発タスクを任せる
→ B

軽い補完中心
→ C

初心者が最初に触る
→ D

つまり、

「どのAIが一番賢い？」

より

「どこまでAIに任せたい？」

を先に決めた方が選びやすい。

ツール選びの前に、
仕事の渡し方を決める。


### 例2：長文

新規事業の検証方法。

僕なら重要度はこう並べます。

5位
市場規模を調べる

4位
競合を調べる

3位
ユーザーへ聞く

2位
現在の行動を見る

1位
実際に買うか確認する

市場規模も競合調査も必要です。

でも、

「市場がある」

と

「この人が自分の商品にお金を払う」

は別問題。

アンケートで
「欲しい」と答えるのも簡単。

今の方法を捨てて
カードを出すのは難しい。

だから事業初期ほど、
意見より行動に近いデータを上位に置きたい。

ランキングというより、

下へ行くほど
「本当の需要」に近づくイメージです。


### 例3：スレッド

1/

AIモデル、
結局どれを使えばいいのか。

主要モデルを

・文章
・調査
・コーディング
・操作
・価格

で比較すると、
「総合最強」を決めるのはかなり雑でした。

先に結論。

文章 → A
調査 → B
コード → C
操作 → D
コスパ → E

用途ごとに勝者が違います。

2/

文章ならA。

理由は単純なベンチマークではなく、
実際の長文生成で

構成
自然さ
指示追従

のバランスが良い。

ただし、
大量生成なら価格面で別候補が強くなる。

3/

コーディングならC。

特に、

複数ファイル
修正
テスト
再実行

まで含む仕事で差が出る。

単発コード生成だけを見ると、
順位はまた変わります。

4/

つまりAIモデル選びで
一番避けたいのは、

「総合ランキング1位だから全部これ」

という選び方。

モデル性能が用途ごとに分かれるほど、

最強の1モデル

より

仕事ごとの最適モデル

を持つ方が合理的です。

## 統合した切り口の例：2026最新：二項対比・保存版構文 X投稿生成

### 投稿例1

Google Antigravityを使いこなす上で、絶対に避けて通れないのが「スキル」と「ワークフロー」の使い分け。

ここを間違えると、AIのポテンシャルを半分も引き出せない。
エンジニア目線で、これ以上のないくらい分かりやすくまとめたよ。

ざっくり言うとこんな感じ。

・スキル（Skills）：AIの「専門知識」。自律的に動く。
・ワークフロー（Workflows）：AIの「手順書」。人間が指示して動かす。

理想的なのは「ワークフローで全体の骨組みを作り、スキルで中身の品質を担保する」という組み合わせ。
これができると、複雑なデプロイも新機能の開発も、ミスなく爆速でおわる。

「あれ、どっちだっけ？」ってなった時にすぐ確認できるよう、今のうちに保存しておいてね。


### 投稿例2

ケンタッキーが「とりの日パック」をリニューアルして3か月が経ちました。
■以前■
価格：1100円 内容：「オリジナルチキン」5ピース
※単品積上げ価格1550円より450円お得
↓↓
■現在■
価格：1250円 内容：「オリジナルチキン」4ピース、「ナゲット5ピース」
※単品積上げ価格1720円より470円お得


### 投稿例3

今、流行ってます。
この形式も海外輸入の典型例。

日本語の運営者に怒られそう
「英語のチャンネル見つけるなよ！」って笑

←英語🇺🇸　🇯🇵日本→

投稿例

AIに市場調査をさせるなら、 いきなり「市場調査して」はおすすめしません。 この3段階に分けます。 ① 論点を作る 「〇〇市場への参入を検討しています。 調査すべき論点を整理してください。 まだ調査は始めないでください。」 ② 論点を人間が確認 不要なものを消す。 足りないものを足す。 ③ 調査させる 「上記論点を調査してください。 最新情報を優先。 数字は一次情報を優先。 事実と推論を分けてください。」 設計 ↓ 調査 を分けるだけで、 AIが見当違いな方向へ走る確率をかなり下げられます。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 今回の型の指定
「行動の特徴からの自己診断」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
手順・診断・やめる行動・成果に至る工程を、読者が自分で実行・点検できる形にする。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 具体的な手順
- 自己診断・チェックリスト
- やめることと代替行動
- 成果と工程の公開
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 具体的な手順
#### 1. 最新かつ正確な方法を調査する
調査メモから
現在もっとも有効な方法を確認する。
操作・仕様・料金・コマンドなど変化する情報は、
公式ドキュメントや一次情報を優先する。
あわせて、
- 初心者がつまずく場所
- 不要になった古い手順
- 実務で使われている近道
- よくある失敗
も確認する。
#### 2. 「完成状態」を先に決める
投稿を読み終えた読者が
何をできるようになるかを具体化する。
悪い例：
「Claude Codeの使い方が分かる」
良い例：
「Claude Codeを導入し、最初の開発タスクを1つ完了できる」
ゴールに不要な説明は削ってください。
#### 3. 最短の手順にする
必要な工程を、
何をする
↓
具体的にどうする
↓
何が起きれば成功か
の順に整理する。
テーマに応じて、
- コピペできるプロンプト
- コマンド
- 設定値
- テンプレート
- 具体例
をそのまま使える形で提示する。
#### 4. つまずきを先回りする
特に失敗しやすい箇所だけ、
「うまくいかない場合は〇〇を確認」
のように補足する。
すべての例外を説明して
本筋を重くしないでください。
#### 5. 最も強いフックを選ぶ
- 何ができるようになるか明確
- <ベースプロンプト>の読者に関係する
- 難しそうなことが実行可能に見える
- 後で使いたくなる
### 投稿設計
1. 何ができるようになるか
2. 必要なもの・前提
3. STEP 1
4. STEP 2
5. STEP 3…
6. よくあるつまずき
7. 最初に試す具体例
8. 次にやること
## 自己診断・チェックリスト
#### 1. 診断したくなる切り口を探す
テーマから
- なりたい状態
- 避けたい状態
- 成果を出す人の共通行動
- 本人が気づきにくい癖
を探してください。
「仕事ができる人」のような広すぎるテーマより、
「AIを使うほど仕事が速くなる人」
「Xが伸び始める人」
のように、<ベースプロンプト>の読者が自分を判定したくなる切り口を優先する。
#### 2. 本当に特徴的なものだけ残す
候補を複数考え、
- 行動として観察できる
- 自分でYES / NOを判断できる
- 成果とのつながりを説明できる
- 他項目と重複しない
- 一部に「そこも？」という意外性がある
ものを残してください。
「努力家」「ポジティブ」「行動力がある」など、
誰にでも当てはまりやすい抽象的特徴は避けてください。
#### 3. 一覧性と意外性を両立する
題材と分量に合う項目数で、
水増しせず最適な数を選んでください。
序盤には「確かに」と納得できる特徴、
途中には「そこは意識していなかった」と思う特徴を混ぜてください。
最後に、複数の特徴を生んでいる
「共通する本質」を一文で見つけてください。
#### 4. 最も強いフックを選ぶ
- 自分に当てはまるか確認したくなる
- 誰についての投稿か一瞬で分かる
- 意外性がある
- 続きを読みたくなる
### 投稿設計
1. 診断テーマを提示
2. 具体的な特徴を一覧化
3. 特に重要・意外な特徴を少し掘る
4. 特徴を束ねる本質を一文で残す
としてください。
## やめることと代替行動
#### 1. 本当にやめる価値のある行動を探す
テーマについて、
- 初心者がやりがちな失敗
- 昔は有効だったが今は非効率な方法
- 良かれと思ってやるほど逆効果になる行動
- 経験者が避けている行動
- 時間・お金・機会を無駄にする習慣
を探してください。
単なるマナー論ではなく、
やめることで結果が変わるものを優先する。
#### 2. 「NG → なぜ → 代わりに」をセットにする
各項目は、
NG：
何をやめる？
理由：
なぜ問題なのか？
代替：
代わりに何をする？
まで考えてください。
「〇〇はやめた方がいい」だけで終わらせないでください。
#### 3. 意外なアンチパターンを優先する
明らかな失敗より、
「むしろ良いことだと思われているが、やりすぎると逆効果」
な行動を優先する。
例：
毎日投稿する
→ 振り返らず投稿数だけ増やすのはNG
長いプロンプトを書く
→ 毎回一発で正解を出そうとするのはNG
顧客の声を聞く
→ 「欲しいですか？」だけ聞くのはNG
#### 4. 項目を絞る
候補を複数調査し、
- <ベースプロンプト>の読者が実際にやりそう
- 損失・非効率が大きい
- 理由を説明できる
- 代替行動がある
- 他項目と重複しない
ものだけ残してください。
項目数は固定せず、
最も価値の高いものだけを使ってください。
#### 5. 最も強いフックを選ぶ
- 「自分もやっているかも」と思う
- 何を避けるべきか知りたくなる
- <ベースプロンプト>の読者に関係する
- 過剰な恐怖煽りではない
### 投稿設計
1. 避けたい結果・問題
2. NG行動を一覧化
3. 各NGがなぜ問題か
4. 代わりに取る行動
5. 特に重要な1つを少し深掘り
6. 「結局、何をやめるべきか」を一文で締める
## 成果と工程の公開
#### 1. テーマから「見せる成果」を決める
<ベースプロンプト>の読者が思わず続きを読みたくなる、
- できるようになったこと
- 大幅に楽になったこと
- 複数工程をまとめられたこと
- 意外な使い方
- 従来より速い・簡単・便利になったこと
などを特定する。
最新ツール・サービス・ニュース・仕様・性能比較など、
情報の鮮度が重要なテーマではまず調査メモを確認する。
根拠のない性能比較や数字は作らないでください。
#### 2. フックを作る
内部で複数のフック候補を作り、
最も続きを読みたくなるものを1つ選んでください。
冒頭1〜3行で、
「何を使って、何ができたのか」
ができるだけ具体的に分かるようにします。
可能なら、
- 固有名詞
- 成果
- 意外性
- 比較
- 効率化
- 驚き
のうち2つ以上を組み合わせてください。
抽象的な
「AIがすごい」
「便利な方法を紹介します」
のような始め方は避けてください。
#### 3. 工程を具体的に並べる
成果に至る流れを、
原則3〜7ステップ程度に分解する。
①
②
③
のように、視覚的に追いやすくします。
各ステップでは、
「ツール名 + 実際に行う操作」
が分かる程度まで具体化する。
ただし説明しすぎず、
一目で全体のワークフローが理解できる長さにしてください。
#### 4. 成果と労力のギャップを作る
工程を見せた後、
「一見複雑な成果に対して、
実際に人間がやることは非常に少ない」
というギャップがある場合は強調する。
例：
- 最初に指示するだけ
- 1つの操作だけ
- 条件を設定するだけ
- あとは自動で処理される
ただし、実際には必要な作業を省略して
過度に簡単そうに見せてはいけません。
#### 5. 続きのポストに続きを置く
追加情報がある場合は、
メイン投稿ですべて説明しきらず、
最も価値のある補足を、指定された本数の範囲で続きのポストへ展開する。
例えば、
- 詳しい設定方法
- 使用したプロンプト
- トークン・コスト削減方法
- 注意点
- 別の応用方法
- 実際の構成
- 比較結果
などです。
続きを読む理由がない場合は、
無理にスレッド化しないでください。
### 投稿設計
具体的な成果→必要な工程→成果と労力のギャップ。補足に独立した価値がある場合だけ、指定本数内で設定・プロンプト・費用・注意点・応用・比較結果を続ける。
# 分量と展開
一覧で作業・自己点検できるなら単発〜長文を優先する。各工程・特徴・NGに独立した理由・具体例・トラブル対処がある場合だけスレッドにし、1投稿目へ完成形と全体手順・主要な特徴・NG一覧を置く。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 具体的な手順：各工程で何をし、何が起きれば成功かが分かるか。完成形と最初に試す例があり、失敗しやすい箇所の確認方法まで示したか。
- 自己診断・チェックリスト：自分で当てはまるか判定でき、各項目が重複していないか。抽象的な性格ではなく行動で診断できるか。
- やめることと代替行動：NG・問題になる理由・代わりの行動がそろうか。読者が実際にしそうで、やめると結果が変わるものに絞ったか。
- 成果と工程の公開：何を使って何ができたかと、実際に必要な操作が分かるか。成果を大きく見せるために人の作業や前提を省いていないか。

# 投稿例

## 例1：単発

AIに市場調査をさせるなら、
いきなり「市場調査して」はおすすめしません。

この3段階に分けます。

① 論点を作る

「〇〇市場への参入を検討しています。
調査すべき論点を整理してください。
まだ調査は始めないでください。」

② 論点を人間が確認

不要なものを消す。
足りないものを足す。

③ 調査させる

「上記論点を調査してください。
最新情報を優先。
数字は一次情報を優先。
事実と推論を分けてください。」

設計
↓
調査

を分けるだけで、
AIが見当違いな方向へ走る確率をかなり下げられます。


## 例2：長文

AIで記事を書くとき、
最初から「記事を書いて」と頼まない方がいい。

僕ならこの順番です。

STEP1
Web調査

まず事実だけ集める。

STEP2
面白い事実を選ぶ

「読者の認識が変わるものだけ残して」
と依頼。

STEP3
読者の疑問を作る

「このテーマについて、
初心者が知りたい質問を20個出して」

STEP4
構成を3案作る

まだ本文は書かせない。

STEP5
一番面白い構成を選んで本文を書く。

特に重要なのはSTEP3。

AIは情報を集めるのは得意です。

でも
「読者が知りたいこと」
を外すと全部つまらなくなる。

文章を書く前に、
読者の問いを作る。

ここを挟むだけでかなり変わります。


## 例3：スレッド

1/

AIでWebサービスを作ってみたい初心者向け。

最初からコードを勉強し直さなくても、
まずここまでなら進められます。

全体は4STEPです。

① 作りたいものを文章にする
② AIに仕様書を作らせる
③ 開発環境を準備
④ 1機能ずつ実装

順番に説明します。

2/

STEP1：作りたいものを文章にする

最初から完璧な仕様書はいりません。

まずAIに、

「〇〇するWebサービスを作りたい。
ユーザー、主要機能、画面、必要データを整理してください。」

と渡す。

曖昧なアイデアを
一度構造化します。

3/

STEP2：仕様書にする

次に、

「初心者がAIコーディングで実装できる粒度に分解してください。
MVPに不要な機能は削ってください。」

と依頼。

ここで重要なのは
機能を増やすことではなく減らすことです。

4/

STEP3：開発環境を準備

使用するツールは、
必ず最新の公式手順を確認して導入。

ここでエラーが出たら、
エラーメッセージをそのままAIへ渡す。

要約して渡すより、
原文の方が原因を特定しやすい場合があります。

5/

STEP4：1機能ずつ作る

「サービス全部を作って」

ではなく、

ログイン
↓
入力
↓
保存
↓
表示

のように分ける。

AI開発で最初に覚えたいのは
コードより、

「大きな仕事を小さく渡すこと」です。


## 統合した切り口の例：「○○な人の特徴」自己診断

### 例1：単発

AIを使うほど仕事が速くなる人の特徴。

・毎回ゼロから説明しない
・1回で正解を出そうとしない
・過去の良い成果物をAIに見せる
・大きな仕事を小さく分ける
・最初に完成条件を決める
・同じ作業を2回やったら自動化を考える
・浮いた時間でもう1案試す

特に最後。

AIで30分浮いたとき、
その30分でもう1案試せる人は
作業時間だけでなく試行回数まで変わる。

AI活用が上手い人って、
プロンプトより
「浮いた時間の使い方」が上手い。


### 例2：長文

仕事が速い人を見ていると、
「手を動かす速度」以外の共通点が多い。

・依頼された瞬間に作業を始めない
・完成条件を先に確認する
・やらなくていい仕事を消す
・60点で一度見せる
・迷ったら早めに聞く
・同じ説明を二度しない仕組みを作る
・重要でない部分はちゃんと雑にやる

速い人って、
全部を高速で処理しているわけじゃない。

むしろ、

「速くやらなくていい仕事」
「そもそもやらなくていい仕事」

を見分けるのが上手い。


### 例3：スレッド

1/

Xが伸び始める人の特徴。

・投稿後の数字を分解する
・テーマとフックを別々に考える
・他人の投稿を文章ではなく構造で見る
・伸びなかった投稿も分析する
・毎回1つだけ仮説を変える

共通しているのは、
「投稿を作品として扱っていない」ことです。

2/

例えば伸びなかったとき。

「今回ダメだった」

で終わるのではなく、

テーマ？
冒頭？
具体例？
長さ？
投稿時間？

と分解する。

失敗した投稿も、
次の投稿を改善するデータになります。

3/

つまりXが伸びる人は、

投稿数が多い人というより
1投稿あたりの学習量が多い人。

X運用を
「文章を書くゲーム」ではなく
「仮説検証」に変えている人ほど強いと思います。

## 統合した切り口の例：やめること・NG・アンチパターン集

### 例1：単発

AIを使っているのに
仕事があまり速くならない人。

まずこの3つをやめたい。

① 毎回ゼロから説明する
→ 前提情報は再利用する

② 1回で完璧な回答を出そうとする
→ まず出して、ズレだけ直す

③ 何でもAIに任せる
→ 人間が判断すべき場所を先に決める

AI活用で大事なのは、
プロンプトを増やすことより

「毎回やらなくていいこと」

を増やすことだと思う。


### 例2：長文

Xが伸びないとき、
投稿数を増やす前にやめたいこと。

・伸びなかったらすぐ次を書く
・表示回数だけを見る
・毎回テーマも構成も全部変える
・「アルゴリズムが悪い」で終わる
・伸びた投稿を「たまたま」で済ませる

これを続けると、
100投稿しても学習がほとんど残らない。

代わりに、

テーマ
冒頭
構成
具体例
長さ

のどこを変えたか残す。

投稿数を増やすより、
1投稿から取れるデータを増やす。

Xでやめたいのは
「失敗すること」ではなく、

失敗から何も取らずに
次へ進むことです。


### 例3：スレッド

1/

AI開発初心者が
最初にやめたいことをまとめます。

① いきなり全部作らせる
② エラーを要約して渡す
③ AIのコードを確認せず実行
④ 大きな変更を一発で任せる
⑤ 動いたら終わりにする

特に危ないのは①です。

2/

①「サービス全部作って」

これをやると、
AIが一度に判断することが多すぎる。

代わりに、

ログイン
↓
入力
↓
保存
↓
表示

のように機能単位で渡す。

小さく作るほど、
どこで壊れたかも分かりやすい。

3/

② エラーを自分で要約する

初心者ほど、

「たぶんデータベースのエラーです」

のように解釈して渡しがち。

代わりに、
まずエラーメッセージ原文を渡す。

自分の推測を入れる前の情報の方が
AIが原因を特定しやすいことがあります。

4/

⑤「動いたから完成」

AI生成コードでは、
動くことと安全・保守可能であることは別。

最低でも、

テスト
エラー処理
権限
不要コード

は確認する。

5/

AI開発で避けたいのは、
AIを使うことではありません。

「AIが出したものを
理解しないまま大きくしていくこと」。

速く作れるほど、
小さく確認する習慣の価値が上がります。

## 統合した切り口の例：2026最新：成果実況・手順公開型

### 投稿例1

📝よし！Google AntigravityからNotebookLMを操作できたぞ！便利！しかもGemini 3.5だからCodexやClaude Codeより断然早い！

①Google AntigravityでNotebookLM操作のSkillsを呼び出し
②「本日分をお願い」と依頼
③Manusで調査済みの日刊AI系ニュースまとめファイルを取得
④ソースとしてNotebookLMに投げる
⑤別途用意済みのインフォグラフィック用プロンプトを投げつつ、NotebookLM上でインフォグラフィックを作成
⑥NotebookLMでソース情報を元に、Spotify用の音声を作成

完了！私はSkillsを呼び出して「本日分をお願い」と一言依頼しただけでここまで自動化できる

詳細は続きへ ↓

スレッド1
NotebookLMでトークン消費を劇的に抑えてDeep Researchをする方法　↓


### 投稿例2

📝競合調査→比較→資料の叩き台まで、AIにバラバラに頼む必要はない。

1本のワークフローにするとこうなる。

①調査したい市場を指定
②主要プレイヤーを洗い出す
③公式サイト・一次情報を収集
④比較軸ごとに整理
⑤重要な差分だけ抽出
⑥そのまま資料構成まで作る

人間が毎回やるのは「今回知りたいこと」を決める部分。

調査そのものより、
調査→整理→アウトプットまでつなげる方がAIは一気に使いやすくなる。

具体的な指示の作り方は続きへ ↓


### 投稿例3

📝毎日のSNS運用、投稿文を書くところだけAI化してもあまり楽にならない。

本当に減らしたいのは、その前後の作業。

①投稿ネタを収集
②使えそうな情報を選別
③自分のテーマに合わせて切り口を決定
④投稿案を生成
⑤公開候補をストック
⑥投稿後の反応を次回に反映

ここまでを1つの流れにしておけば、
毎回ゼロから「今日は何を書こう？」と考える必要がなくなる。

ポイントは文章生成ではなく、
投稿が生まれる仕組みそのものを作ること。

具体的な設計は続きへ ↓

投稿例

3週間かけて作った機能。 ほとんど使われませんでした。 作る前にユーザーへ聞いていました。 「この機能あったら使いますか？」 答えはほぼ全員、 「欲しい」。 だから作った。 でも質問が間違っていた。 本当に聞くべきだったのは、 「今、その問題をどう解決していますか？」 だった。 本当に困っているなら、 すでに時間かお金を使っていることが多い。 「欲しい」は意見。 「今やっている」は行動。 新規事業では、 言葉より行動の方が情報量が多い。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 狙い
体験・検証・事例の経緯から、読者が再利用できる判断を取り出す。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 失敗からの学び
- 実験・検証
- 成功・失敗事例の分解
- 再起・自己開示
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 失敗からの学び
#### 1. 学びになる失敗を探す
テーマについて
- よくある失敗・遠回り
- 一見正しそうなのに失敗する行動
- 経験者が後悔していること
- 公開されている失敗事例・撤退・方向転換
- 「もっと早く知りたかった」と言われること
を探してください。
単なる不運ではなく、
<ベースプロンプト>の読者も同じ判断をしそうな失敗を優先する。
#### 2. 「本当の失敗原因」を掘る
表面的な原因で止めず、
何を信じていた？
↓
なぜそれが正しいと思った？
↓
現実は何が違った？
↓
本当の判断ミスは何だった？
まで掘ってください。
投稿の核心は、
失敗そのものより「認識が変わった瞬間」です。
#### 3. 最も強い入口を選ぶ
- 何が起きたか一瞬で分かる
- 続きを読みたくなる
- <ベースプロンプト>の読者が自分ごと化できる
- 過剰な煽りではない
### 投稿設計
1. 失敗・結果が分かる場面
2. 当時は何を正しいと思っていたか
3. 実際に何をしたか
4. 何が想定と違ったか
5. 本当の失敗原因
6. その後、何を変えたか
7. 読者が再利用できる原則
認識の変化を丁寧に描くなら長文、失敗と学びが短く伝わるなら単発。独立した学びのある複数の試行・転換点だけスレッドにし、冒頭で失敗を示す。
## 実験・検証
#### 1. 検証する価値のある問いを作る
テーマについて
- よく信じられている主張
- AとBで意見が割れていること
- 実際に試さないと分かりにくいこと
- 最近の環境変化で答えが変わった可能性があること
を探してください。
「AIは便利か？」ではなく、
「同じタスクならAとBのどちらが速く・高品質か？」
のように比較・検証できる問いにしてください。
#### 2. 検証方法を選ぶ
利用できる証拠を次の順で判断する。
1. ユーザー自身の実測データ
2. 確認済みの比較・検証の記録
3. 公式ベンチマーク・公開実験・複数の実測事例
#### 3. 条件を揃える
比較する場合は、
- 同じタスク
- 同じ入力
- 同じ期間
- 同じ評価基準
など、結果に影響する条件を可能な限り揃えてください。
テーマに応じて、
時間・費用・品質・成功率・CTR・CVRなど
最も意味のある指標を選んでください。
#### 4. 結果より先に仮説を持つ
検証前に
「普通ならAが勝つと思う」
「一般にはBが有利と言われている」
という事前仮説を整理する。
結果との差が、
投稿の面白さになります。
予想通りでも無理に意外な結論を作らず、
「どこだけ予想と違ったか」を探してください。
#### 5. 最も強いフックを選ぶ
- 結果を知りたくなる
- 比較条件が具体的
- <ベースプロンプト>の読者に関係する
- 意外性がある
### 投稿設計
1. 検証する問い＋重要な結果
2. 事前仮説
3. 検証条件・方法
4. 結果
5. 意外だった点
6. なぜそうなったか
7. 実務でどう使うか
8. 必要なら検証の限界
1つの比較は単発〜長文で完結。複数条件・複数回の検証や改善の変化に価値がある場合だけスレッドにし、冒頭で主要な結果を示す。
## 成功・失敗事例の分解
#### 1. 事例を正確に再構成する
調査メモから一次情報を優先して
- 当初の状況・目的
- 当時分かっていたこと
- 主要な意思決定
- 制約・競合・市場環境
- 結果を変えた転換点
- 最終的な結果
を時系列で整理する。
結果を知った状態から逆算して、
「当然こうすべきだった」と判断しないでください。
#### 2. 結果を分解する
「成功したのは○○のおかげ」
「失敗したのは△△のせい」
と1要因に単純化せず、
- 戦略
- プロダクト
- Distribution
- 価格
- タイミング
- 組織
- 市場環境
- 運・外部要因
などから主要因を切り分けてください。
特に、
「直接見える要因」
より
「その要因を生んだ1つ前の意思決定」
を探してください。
#### 3. 最大の転換点を特定する
複数の出来事から、
「ここで別の選択をしていたら結果が大きく変わった可能性がある」
転換点を1〜3個選んでください。
その時点で、
- どんな選択肢があったか
- なぜその判断をしたのか
- 何が起きたか
を明確にしてください。
#### 4. 別の説明でも成立しないか確認する
採用した分析について、
「本当にこの要因が重要だったのか？」
「別の要因でも結果を説明できないか？」
を検討する。
事実と推論を分け、
因果を断定できない場合は「可能性」「示唆」として扱ってください。
#### 5. 最も強いフックを選ぶ
- 結果と謎が同時に伝わる
- 「なぜ？」と思う
- <ベースプロンプト>の読者が学べる
- 事例固有の面白さがある
### 投稿設計
1. 結果＋最大の問い
2. 当時の状況
3. 最初の戦略・判断
4. 転換点
5. その判断が生んだ結果
6. 他の要因・反対仮説
7. 最も重要だった要因
8. 他の場面でも使える原則
単純な事例は長文1投稿。時系列・転換点・因果を順に追う価値がある場合はスレッドにし、冒頭で結果と問いを示す。
## 再起・自己開示
#### 1. 最も強いギャップを探す
題材と人物像から、
- 大きな失敗 → 現在の成果
- 何もなかった状態 → 獲得したもの
- 挫折 → 再起
- 周囲から見えない弱み → 表から見える現在
- 過去の自分 → 今の自分
など、最も意外性のある対比を探してください。
内部で複数のフック候補を作り、
「続きが気になる」「どうやってそこまで行ったのか知りたい」と感じるものを選んでください。
数字や具体的事実がある場合は優先して使います。
#### 2. 弱さを具体化する
「大変だった」「苦労した」のような抽象表現ではなく、
題材と人物像に合う場面から、
当時の状態が一瞬で伝わる具体的な情報を選びます。
特に、
- 失敗した回数
- 借金・売上などの数字
- 退職・倒産・不合格などの出来事
- 持っていなかったもの
- 周囲には隠していたこと
- 当時の感情や状況
が有効です。
#### 3. 公開する理由を作る
「こんな過去があります」で終わらせず、
なぜ今それを公開するのか
を必ず入れてください。
例えば、
- 同じ状況の人に勇気を与えたい
- 表面的な成功だけではなく等身大の自分を知ってほしい
- 同じ失敗をする人を減らしたい
- 挑戦する人の背中を押したい
などです。
題材と人物像から自然に導ける理由を使ってください。
#### 4. 「きれいすぎる話」にしない
必要であれば、
本人側にも利益があることを率直に書いてください。
例えば、
- 新しい事業を知ってほしい
- 認知度を上げたい
- 採用につなげたい
- 商品を知ってほしい
- フォロワーを増やしたい
などです。
社会的にきれいな理由だけを並べるより、
適度な自己利益も隠さず書くことで人間味を出します。
### 投稿設計
##### ① 強烈な過去 → 現在のギャップ
投稿冒頭1〜2行で、
人生・キャリア・事業などの大きな振れ幅を提示します。
例：
「〈過去の状態〉→〈現在の状態〉までの○年間をまとめました。」
数字や具体的事件があれば使用します。
##### ② 「持たざる状態」を圧縮
2〜4個程度の短い言葉を並べ、
当時の状況を視覚的に伝えます。
例：
経験なし、実績なし、人脈なし、資金なし
##### ③ なぜ公開するのか
弱みや過去を公開することへの葛藤と、
それでも公開する理由を書きます。
ここが共感の中心です。
##### ④ 現在・次の挑戦
過去話だけで終わらず、
「今、この人はどこへ向かっているのか」を短く入れます。
読者がプロフィールや今後の投稿を追う理由を作ってください。
##### ⑤ 本音
本人に宣伝・認知・採用などの目的があれば、
過度に取り繕わず短く開示します。
「善意100%」に見せようとしないこと。
##### ⑥ 締め
次の挑戦や本音で締めてください。参加の呼びかけは依頼に合う場合だけ自然に添え、反応を強要しないでください。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 失敗からの学び：当時の認識・実際の行動・想定との差・変えたことがつながるか。単なる不運や自虐を教訓にしていないか。
- 実験・検証：問い・条件・方法・結果・解釈を区別したか。比較条件の差や限界を落とさず、予想との差を実際の結果で示したか。
- 成功・失敗事例の分解：その時点の選択肢と判断を再構成したか。結果を1要因で説明せず、別の要因・外部環境・運でも説明できるかを検討したか。
- 再起・自己開示：過去と今の差・公開する理由・次の挑戦がつながるか。抽象的な苦労話やきれいな動機だけで埋めず、反応を強要していないか。

# 投稿例

## 例1：単発

3週間かけて作った機能。

ほとんど使われませんでした。

作る前にユーザーへ聞いていました。

「この機能あったら使いますか？」

答えはほぼ全員、
「欲しい」。

だから作った。

でも質問が間違っていた。

本当に聞くべきだったのは、

「今、その問題をどう解決していますか？」

だった。

本当に困っているなら、
すでに時間かお金を使っていることが多い。

「欲しい」は意見。

「今やっている」は行動。

新規事業では、
言葉より行動の方が情報量が多い。


## 例2：長文

AIを使い始めた頃、
1回目の回答を完璧にすることばかり考えていました。

前提条件を書く。
役割を書く。
禁止事項を書く。
例を書く。

プロンプトだけで30分。

確かに1回目の回答品質は上がった。

でもあるとき、

5分で依頼
↓
出力を見る
↓
ズレだけ修正
↓
もう一度出す

方が、完成まで速い仕事が多いと気づきました。

最適化していた指標が違った。

見ていたのは
「1回目の正答率」。

本当に見るべきだったのは
「完成までの総時間」。

AIでは、
一発で正解することより
安く速く修正できることの方が重要な場面があります。


## 例3：スレッド

1/

ある新規事業。

市場調査もした。
競合も調べた。
ユーザーにも聞いた。

それでもリリース後、
ほとんど使われませんでした。

問題は「調査不足」ではありませんでした。

調査の仕方でした。

2/

ユーザーには何度も聞いていました。

「このサービス欲しいですか？」

「使いたいですか？」

反応は良かった。

だからチームは
需要があると判断した。

3/

でもリリース後、

登録しない。
乗り換えない。
お金を払わない。

言葉と行動が一致しませんでした。

4/

ここで重要なのは、
ユーザーが嘘をついたわけではないこと。

「無料なら欲しい」

と

「今の方法を捨てて、お金を払って使う」

は別の判断です。

5/

次に見るべきだったのは、

「欲しいですか？」

ではなく、

「今どうやって解決していますか？」
「そのために何時間・いくら使っていますか？」

でした。

6/

失敗したのは、
ユーザーの声を聞いたことではない。

未来の「気持ち」を
現在の「需要」だと解釈したこと。

顧客理解では、
言葉を聞く以上に
現在の行動を見ることが重要です。


## 統合した切り口の例：実験・検証してみた

※以下は構造例です。数値は説明用の架空例です。

### 例1：単発

AIに文章を書かせるとき、

A：最初に完璧なプロンプトを書く
B：短く指示して、出力を見ながら直す

どちらが速いのか。

同じ記事作成で比べると、

A
指示作成：25分
修正：10分
合計：35分

B
初回指示：5分
修正3回：18分
合計：23分

1回目の品質はAが上。

でも完成までの時間はBが短かった。

AI活用で見るべきなのは
「一発目の正答率」だけではない。

修正まで含めた
「完成までの総コスト」です。


### 例2：長文

「AIモデルは一番賢いものを使えばいい」

本当にそうなのか、
同じ3種類の仕事で比較すると見え方が変わります。

文章要約ではA。

コード修正ではB。

画面操作ではC。

総合ベンチマーク1位が
全部の仕事で1位になるわけではない。

面白いのは、
モデルの優劣より

「仕事によって勝者が変わる」

ことです。

AI選びは、

最強モデルを1つ決める

より

タスクごとに最適モデルを決める

方が実務では合理的かもしれません。


### 例3：スレッド

1/

X投稿は
「結論から始めた方が伸びる」のか。

同じテーマで、

A：結論から開始
B：問いから開始
C：具体的な出来事から開始

を比較。

結果を見ると、
単純に「結論型が最強」とは言えませんでした。

2/

まず表示回数。

A：○○
B：○○
C：○○

一番伸びたのはC。

ただし、
これだけでは結論は出せません。

3/

プロフィール閲覧を見ると、
今度はAが最も高い。

つまり、

表示されやすい構成
と
「この人をもっと見たい」と思わせる構成

が同じとは限らない。

4/

今回の検証で一番重要だったのは、

「どの投稿が勝ったか」

ではありません。

何を成果とするかで
勝者が変わったことです。

Xの検証では、
インプレッションだけでなく

返信
共有
プロフィール閲覧
フォロー

まで分けて見た方がいい。

## 統合した切り口の例：成功失敗事例の分解・Teardown

### 例1：長文

あるSaaSが伸びた理由を
「AIの性能が高かったから」
だけで説明すると、かなり見落とします。

最初は多機能を売りにしていた。

でもユーザーが実際によく使ったのは、
たった1つの機能。

そこで、

機能を増やす
ではなく
その1機能までの導線を短くする

方向へ寄せた。

結果として変わったのは
AI性能ではなく、
最初の価値体験までの距離です。

成功要因を「技術力」と見るより、

ユーザー行動を見て
最初の仮説を捨てられたこと

と見る方が再現性が高い。


### 例2：長文

ある新規事業が撤退。

表面的には
「市場が小さかった」で終わります。

でも時系列で見ると、
もっと前に分岐点がありました。

最初から大企業向けに設計
↓
要求機能が増える
↓
開発期間が延びる
↓
検証前に固定費が大きくなる
↓
市場とのズレが分かった時には方向転換が重い

つまり問題は、
最後の売上不足だけではない。

「需要を確認する前に、
変更コストの高い事業構造を作った」

こと。

失敗は撤退時ではなく、
戻れなくなった時点から始まっていた可能性があります。


### 例3：スレッド

1/

ある後発プロダクトが
先行サービスを追い抜いた。

普通に考えると、
機能で勝ったように見えます。

でも時系列で分解すると、
勝負を変えたのは別の3つの判断でした。

2/

最初の判断。

競合より機能を増やさなかった。

代わりに、

「最初の10分で価値を感じる」

ことへ集中した。

機能数では負ける。
オンボーディングでは勝つ。

3/

次の判断。

全員を狙わなかった。

利用が特に強かった職種へ
メッセージを絞った。

市場を狭めた結果、

「これは自分向けだ」

が伝わりやすくなった。

4/

3つ目。

新機能よりDistributionへ投資した。

プロダクト差が縮まり始めた段階で、

作る
↓
届ける

へボトルネックが移ったと判断した。

5/

もちろん、
この3つだけで成功したとは言えません。

市場拡大や競合の動きなど
外部要因もある。

ただ時系列で見ると、

機能
→オンボーディング
→顧客集中
→Distribution

と、ボトルネックが変わるたびに
投資先も変えている。

6/

このケースから持ち帰りたいのは、

「正しい戦略を最初から当てること」

ではありません。

今のボトルネックが変わったときに、
過去の勝ち筋を捨てられること。

事業の強さは、
正解そのものより
正解を更新する速度に出るのかもしれません。

## 統合した切り口の例：2026最新：どん底→再起・自己開示型 X投稿生成

### 例1

3度の逮捕→少年院→数億円で会社売却した31年の人生を綴りました。

学歴なし、スキルなし、金なし、コネなし
どん底のリアルです。

隠して生きていく予定でしたが、等身大の僕を知ってほしいかつ僕のように持たざる者が少しでも勇気を持って挑戦するキッカケになれば嬉しいです。

また、次なる挑戦もスタートしました。
新規事業のために認知度を上げたいという下心も正直あります。

いいね、引用で拡散してくださると泣いて喜びます！


### 例2：個人開発者の場合の構造例

〈何度も失敗した事実〉→〈現在の成果〉までの過程を、全部まとめました。

〈当時持っていなかったもの〉
〈失敗した具体的事実〉

うまくいった部分だけ話す方が格好はつくのですが、
同じところで悩んでいる人には失敗した部分の方が役立つと思ったので公開します。

今は〈次の挑戦〉を始めています。

もちろん、これを機に〈本人に実際に存在する目的〉という本音もあります。

何か刺さった部分があれば、いいねや引用をもらえるとうれしいです。


### 例3：キャリア転換の場合の構造例

〈過去のキャリア・挫折〉→〈現在のキャリア〉。

ここに至るまでの過程を公開しました。

〈具体的な失敗〉
〈持っていなかったもの〉
〈一度諦めたこと〉

順調に見える部分だけ発信することもできますが、
これから同じ道に挑戦する人には、その裏側まで見せた方が意味があると思っています。

そして今、〈新しい挑戦〉も始めています。

〈本人に実際に存在する目的〉という打算もあります。
そこも含めて今の自分です。

応援してもらえるなら、いいね・引用していただけるとうれしいです。

投稿例

3週間かけて作った機能。 ほとんど使われませんでした。 作る前にユーザーへ聞いていました。 「この機能あったら使いますか？」 答えはほぼ全員、 「欲しい」。 だから作った。 でも質問が間違っていた。 本当に聞くべきだったのは、 「今、その問題をどう解決していますか？」 だった。 本当に困っているなら、 すでに時間かお金を使っていることが多い。 「欲しい」は意見。 「今やっている」は行動。 新規事業では、 言葉より行動の方が情報量が多い。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 今回の型の指定
「実験・検証」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
体験・検証・事例の経緯から、読者が再利用できる判断を取り出す。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 失敗からの学び
- 実験・検証
- 成功・失敗事例の分解
- 再起・自己開示
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 失敗からの学び
#### 1. 学びになる失敗を探す
テーマについて
- よくある失敗・遠回り
- 一見正しそうなのに失敗する行動
- 経験者が後悔していること
- 公開されている失敗事例・撤退・方向転換
- 「もっと早く知りたかった」と言われること
を探してください。
単なる不運ではなく、
<ベースプロンプト>の読者も同じ判断をしそうな失敗を優先する。
#### 2. 「本当の失敗原因」を掘る
表面的な原因で止めず、
何を信じていた？
↓
なぜそれが正しいと思った？
↓
現実は何が違った？
↓
本当の判断ミスは何だった？
まで掘ってください。
投稿の核心は、
失敗そのものより「認識が変わった瞬間」です。
#### 3. 最も強い入口を選ぶ
- 何が起きたか一瞬で分かる
- 続きを読みたくなる
- <ベースプロンプト>の読者が自分ごと化できる
- 過剰な煽りではない
### 投稿設計
1. 失敗・結果が分かる場面
2. 当時は何を正しいと思っていたか
3. 実際に何をしたか
4. 何が想定と違ったか
5. 本当の失敗原因
6. その後、何を変えたか
7. 読者が再利用できる原則
認識の変化を丁寧に描くなら長文、失敗と学びが短く伝わるなら単発。独立した学びのある複数の試行・転換点だけスレッドにし、冒頭で失敗を示す。
## 実験・検証
#### 1. 検証する価値のある問いを作る
テーマについて
- よく信じられている主張
- AとBで意見が割れていること
- 実際に試さないと分かりにくいこと
- 最近の環境変化で答えが変わった可能性があること
を探してください。
「AIは便利か？」ではなく、
「同じタスクならAとBのどちらが速く・高品質か？」
のように比較・検証できる問いにしてください。
#### 2. 検証方法を選ぶ
利用できる証拠を次の順で判断する。
1. ユーザー自身の実測データ
2. 確認済みの比較・検証の記録
3. 公式ベンチマーク・公開実験・複数の実測事例
#### 3. 条件を揃える
比較する場合は、
- 同じタスク
- 同じ入力
- 同じ期間
- 同じ評価基準
など、結果に影響する条件を可能な限り揃えてください。
テーマに応じて、
時間・費用・品質・成功率・CTR・CVRなど
最も意味のある指標を選んでください。
#### 4. 結果より先に仮説を持つ
検証前に
「普通ならAが勝つと思う」
「一般にはBが有利と言われている」
という事前仮説を整理する。
結果との差が、
投稿の面白さになります。
予想通りでも無理に意外な結論を作らず、
「どこだけ予想と違ったか」を探してください。
#### 5. 最も強いフックを選ぶ
- 結果を知りたくなる
- 比較条件が具体的
- <ベースプロンプト>の読者に関係する
- 意外性がある
### 投稿設計
1. 検証する問い＋重要な結果
2. 事前仮説
3. 検証条件・方法
4. 結果
5. 意外だった点
6. なぜそうなったか
7. 実務でどう使うか
8. 必要なら検証の限界
1つの比較は単発〜長文で完結。複数条件・複数回の検証や改善の変化に価値がある場合だけスレッドにし、冒頭で主要な結果を示す。
## 成功・失敗事例の分解
#### 1. 事例を正確に再構成する
調査メモから一次情報を優先して
- 当初の状況・目的
- 当時分かっていたこと
- 主要な意思決定
- 制約・競合・市場環境
- 結果を変えた転換点
- 最終的な結果
を時系列で整理する。
結果を知った状態から逆算して、
「当然こうすべきだった」と判断しないでください。
#### 2. 結果を分解する
「成功したのは○○のおかげ」
「失敗したのは△△のせい」
と1要因に単純化せず、
- 戦略
- プロダクト
- Distribution
- 価格
- タイミング
- 組織
- 市場環境
- 運・外部要因
などから主要因を切り分けてください。
特に、
「直接見える要因」
より
「その要因を生んだ1つ前の意思決定」
を探してください。
#### 3. 最大の転換点を特定する
複数の出来事から、
「ここで別の選択をしていたら結果が大きく変わった可能性がある」
転換点を1〜3個選んでください。
その時点で、
- どんな選択肢があったか
- なぜその判断をしたのか
- 何が起きたか
を明確にしてください。
#### 4. 別の説明でも成立しないか確認する
採用した分析について、
「本当にこの要因が重要だったのか？」
「別の要因でも結果を説明できないか？」
を検討する。
事実と推論を分け、
因果を断定できない場合は「可能性」「示唆」として扱ってください。
#### 5. 最も強いフックを選ぶ
- 結果と謎が同時に伝わる
- 「なぜ？」と思う
- <ベースプロンプト>の読者が学べる
- 事例固有の面白さがある
### 投稿設計
1. 結果＋最大の問い
2. 当時の状況
3. 最初の戦略・判断
4. 転換点
5. その判断が生んだ結果
6. 他の要因・反対仮説
7. 最も重要だった要因
8. 他の場面でも使える原則
単純な事例は長文1投稿。時系列・転換点・因果を順に追う価値がある場合はスレッドにし、冒頭で結果と問いを示す。
## 再起・自己開示
#### 1. 最も強いギャップを探す
題材と人物像から、
- 大きな失敗 → 現在の成果
- 何もなかった状態 → 獲得したもの
- 挫折 → 再起
- 周囲から見えない弱み → 表から見える現在
- 過去の自分 → 今の自分
など、最も意外性のある対比を探してください。
内部で複数のフック候補を作り、
「続きが気になる」「どうやってそこまで行ったのか知りたい」と感じるものを選んでください。
数字や具体的事実がある場合は優先して使います。
#### 2. 弱さを具体化する
「大変だった」「苦労した」のような抽象表現ではなく、
題材と人物像に合う場面から、
当時の状態が一瞬で伝わる具体的な情報を選びます。
特に、
- 失敗した回数
- 借金・売上などの数字
- 退職・倒産・不合格などの出来事
- 持っていなかったもの
- 周囲には隠していたこと
- 当時の感情や状況
が有効です。
#### 3. 公開する理由を作る
「こんな過去があります」で終わらせず、
なぜ今それを公開するのか
を必ず入れてください。
例えば、
- 同じ状況の人に勇気を与えたい
- 表面的な成功だけではなく等身大の自分を知ってほしい
- 同じ失敗をする人を減らしたい
- 挑戦する人の背中を押したい
などです。
題材と人物像から自然に導ける理由を使ってください。
#### 4. 「きれいすぎる話」にしない
必要であれば、
本人側にも利益があることを率直に書いてください。
例えば、
- 新しい事業を知ってほしい
- 認知度を上げたい
- 採用につなげたい
- 商品を知ってほしい
- フォロワーを増やしたい
などです。
社会的にきれいな理由だけを並べるより、
適度な自己利益も隠さず書くことで人間味を出します。
### 投稿設計
##### ① 強烈な過去 → 現在のギャップ
投稿冒頭1〜2行で、
人生・キャリア・事業などの大きな振れ幅を提示します。
例：
「〈過去の状態〉→〈現在の状態〉までの○年間をまとめました。」
数字や具体的事件があれば使用します。
##### ② 「持たざる状態」を圧縮
2〜4個程度の短い言葉を並べ、
当時の状況を視覚的に伝えます。
例：
経験なし、実績なし、人脈なし、資金なし
##### ③ なぜ公開するのか
弱みや過去を公開することへの葛藤と、
それでも公開する理由を書きます。
ここが共感の中心です。
##### ④ 現在・次の挑戦
過去話だけで終わらず、
「今、この人はどこへ向かっているのか」を短く入れます。
読者がプロフィールや今後の投稿を追う理由を作ってください。
##### ⑤ 本音
本人に宣伝・認知・採用などの目的があれば、
過度に取り繕わず短く開示します。
「善意100%」に見せようとしないこと。
##### ⑥ 締め
次の挑戦や本音で締めてください。参加の呼びかけは依頼に合う場合だけ自然に添え、反応を強要しないでください。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 失敗からの学び：当時の認識・実際の行動・想定との差・変えたことがつながるか。単なる不運や自虐を教訓にしていないか。
- 実験・検証：問い・条件・方法・結果・解釈を区別したか。比較条件の差や限界を落とさず、予想との差を実際の結果で示したか。
- 成功・失敗事例の分解：その時点の選択肢と判断を再構成したか。結果を1要因で説明せず、別の要因・外部環境・運でも説明できるかを検討したか。
- 再起・自己開示：過去と今の差・公開する理由・次の挑戦がつながるか。抽象的な苦労話やきれいな動機だけで埋めず、反応を強要していないか。

# 投稿例

## 例1：単発

3週間かけて作った機能。

ほとんど使われませんでした。

作る前にユーザーへ聞いていました。

「この機能あったら使いますか？」

答えはほぼ全員、
「欲しい」。

だから作った。

でも質問が間違っていた。

本当に聞くべきだったのは、

「今、その問題をどう解決していますか？」

だった。

本当に困っているなら、
すでに時間かお金を使っていることが多い。

「欲しい」は意見。

「今やっている」は行動。

新規事業では、
言葉より行動の方が情報量が多い。


## 例2：長文

AIを使い始めた頃、
1回目の回答を完璧にすることばかり考えていました。

前提条件を書く。
役割を書く。
禁止事項を書く。
例を書く。

プロンプトだけで30分。

確かに1回目の回答品質は上がった。

でもあるとき、

5分で依頼
↓
出力を見る
↓
ズレだけ修正
↓
もう一度出す

方が、完成まで速い仕事が多いと気づきました。

最適化していた指標が違った。

見ていたのは
「1回目の正答率」。

本当に見るべきだったのは
「完成までの総時間」。

AIでは、
一発で正解することより
安く速く修正できることの方が重要な場面があります。


## 例3：スレッド

1/

ある新規事業。

市場調査もした。
競合も調べた。
ユーザーにも聞いた。

それでもリリース後、
ほとんど使われませんでした。

問題は「調査不足」ではありませんでした。

調査の仕方でした。

2/

ユーザーには何度も聞いていました。

「このサービス欲しいですか？」

「使いたいですか？」

反応は良かった。

だからチームは
需要があると判断した。

3/

でもリリース後、

登録しない。
乗り換えない。
お金を払わない。

言葉と行動が一致しませんでした。

4/

ここで重要なのは、
ユーザーが嘘をついたわけではないこと。

「無料なら欲しい」

と

「今の方法を捨てて、お金を払って使う」

は別の判断です。

5/

次に見るべきだったのは、

「欲しいですか？」

ではなく、

「今どうやって解決していますか？」
「そのために何時間・いくら使っていますか？」

でした。

6/

失敗したのは、
ユーザーの声を聞いたことではない。

未来の「気持ち」を
現在の「需要」だと解釈したこと。

顧客理解では、
言葉を聞く以上に
現在の行動を見ることが重要です。


## 統合した切り口の例：実験・検証してみた

※以下は構造例です。数値は説明用の架空例です。

### 例1：単発

AIに文章を書かせるとき、

A：最初に完璧なプロンプトを書く
B：短く指示して、出力を見ながら直す

どちらが速いのか。

同じ記事作成で比べると、

A
指示作成：25分
修正：10分
合計：35分

B
初回指示：5分
修正3回：18分
合計：23分

1回目の品質はAが上。

でも完成までの時間はBが短かった。

AI活用で見るべきなのは
「一発目の正答率」だけではない。

修正まで含めた
「完成までの総コスト」です。


### 例2：長文

「AIモデルは一番賢いものを使えばいい」

本当にそうなのか、
同じ3種類の仕事で比較すると見え方が変わります。

文章要約ではA。

コード修正ではB。

画面操作ではC。

総合ベンチマーク1位が
全部の仕事で1位になるわけではない。

面白いのは、
モデルの優劣より

「仕事によって勝者が変わる」

ことです。

AI選びは、

最強モデルを1つ決める

より

タスクごとに最適モデルを決める

方が実務では合理的かもしれません。


### 例3：スレッド

1/

X投稿は
「結論から始めた方が伸びる」のか。

同じテーマで、

A：結論から開始
B：問いから開始
C：具体的な出来事から開始

を比較。

結果を見ると、
単純に「結論型が最強」とは言えませんでした。

2/

まず表示回数。

A：○○
B：○○
C：○○

一番伸びたのはC。

ただし、
これだけでは結論は出せません。

3/

プロフィール閲覧を見ると、
今度はAが最も高い。

つまり、

表示されやすい構成
と
「この人をもっと見たい」と思わせる構成

が同じとは限らない。

4/

今回の検証で一番重要だったのは、

「どの投稿が勝ったか」

ではありません。

何を成果とするかで
勝者が変わったことです。

Xの検証では、
インプレッションだけでなく

返信
共有
プロフィール閲覧
フォロー

まで分けて見た方がいい。

## 統合した切り口の例：成功失敗事例の分解・Teardown

### 例1：長文

あるSaaSが伸びた理由を
「AIの性能が高かったから」
だけで説明すると、かなり見落とします。

最初は多機能を売りにしていた。

でもユーザーが実際によく使ったのは、
たった1つの機能。

そこで、

機能を増やす
ではなく
その1機能までの導線を短くする

方向へ寄せた。

結果として変わったのは
AI性能ではなく、
最初の価値体験までの距離です。

成功要因を「技術力」と見るより、

ユーザー行動を見て
最初の仮説を捨てられたこと

と見る方が再現性が高い。


### 例2：長文

ある新規事業が撤退。

表面的には
「市場が小さかった」で終わります。

でも時系列で見ると、
もっと前に分岐点がありました。

最初から大企業向けに設計
↓
要求機能が増える
↓
開発期間が延びる
↓
検証前に固定費が大きくなる
↓
市場とのズレが分かった時には方向転換が重い

つまり問題は、
最後の売上不足だけではない。

「需要を確認する前に、
変更コストの高い事業構造を作った」

こと。

失敗は撤退時ではなく、
戻れなくなった時点から始まっていた可能性があります。


### 例3：スレッド

1/

ある後発プロダクトが
先行サービスを追い抜いた。

普通に考えると、
機能で勝ったように見えます。

でも時系列で分解すると、
勝負を変えたのは別の3つの判断でした。

2/

最初の判断。

競合より機能を増やさなかった。

代わりに、

「最初の10分で価値を感じる」

ことへ集中した。

機能数では負ける。
オンボーディングでは勝つ。

3/

次の判断。

全員を狙わなかった。

利用が特に強かった職種へ
メッセージを絞った。

市場を狭めた結果、

「これは自分向けだ」

が伝わりやすくなった。

4/

3つ目。

新機能よりDistributionへ投資した。

プロダクト差が縮まり始めた段階で、

作る
↓
届ける

へボトルネックが移ったと判断した。

5/

もちろん、
この3つだけで成功したとは言えません。

市場拡大や競合の動きなど
外部要因もある。

ただ時系列で見ると、

機能
→オンボーディング
→顧客集中
→Distribution

と、ボトルネックが変わるたびに
投資先も変えている。

6/

このケースから持ち帰りたいのは、

「正しい戦略を最初から当てること」

ではありません。

今のボトルネックが変わったときに、
過去の勝ち筋を捨てられること。

事業の強さは、
正解そのものより
正解を更新する速度に出るのかもしれません。

## 統合した切り口の例：2026最新：どん底→再起・自己開示型 X投稿生成

### 例1

3度の逮捕→少年院→数億円で会社売却した31年の人生を綴りました。

学歴なし、スキルなし、金なし、コネなし
どん底のリアルです。

隠して生きていく予定でしたが、等身大の僕を知ってほしいかつ僕のように持たざる者が少しでも勇気を持って挑戦するキッカケになれば嬉しいです。

また、次なる挑戦もスタートしました。
新規事業のために認知度を上げたいという下心も正直あります。

いいね、引用で拡散してくださると泣いて喜びます！


### 例2：個人開発者の場合の構造例

〈何度も失敗した事実〉→〈現在の成果〉までの過程を、全部まとめました。

〈当時持っていなかったもの〉
〈失敗した具体的事実〉

うまくいった部分だけ話す方が格好はつくのですが、
同じところで悩んでいる人には失敗した部分の方が役立つと思ったので公開します。

今は〈次の挑戦〉を始めています。

もちろん、これを機に〈本人に実際に存在する目的〉という本音もあります。

何か刺さった部分があれば、いいねや引用をもらえるとうれしいです。


### 例3：キャリア転換の場合の構造例

〈過去のキャリア・挫折〉→〈現在のキャリア〉。

ここに至るまでの過程を公開しました。

〈具体的な失敗〉
〈持っていなかったもの〉
〈一度諦めたこと〉

順調に見える部分だけ発信することもできますが、
これから同じ道に挑戦する人には、その裏側まで見せた方が意味があると思っています。

そして今、〈新しい挑戦〉も始めています。

〈本人に実際に存在する目的〉という打算もあります。
そこも含めて今の自分です。

応援してもらえるなら、いいね・引用していただけるとうれしいです。

投稿例

AIに市場調査をさせるなら、 いきなり「市場調査して」はおすすめしません。 この3段階に分けます。 ① 論点を作る 「〇〇市場への参入を検討しています。 調査すべき論点を整理してください。 まだ調査は始めないでください。」 ② 論点を人間が確認 不要なものを消す。 足りないものを足す。 ③ 調査させる 「上記論点を調査してください。 最新情報を優先。 数字は一次情報を優先。 事実と推論を分けてください。」 設計 ↓ 調査 を分けるだけで、 AIが見当違いな方向へ走る確率をかなり下げられます。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 狙い
手順・診断・やめる行動・成果に至る工程を、読者が自分で実行・点検できる形にする。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 具体的な手順
- 自己診断・チェックリスト
- やめることと代替行動
- 成果と工程の公開
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 具体的な手順
#### 1. 最新かつ正確な方法を調査する
調査メモから
現在もっとも有効な方法を確認する。
操作・仕様・料金・コマンドなど変化する情報は、
公式ドキュメントや一次情報を優先する。
あわせて、
- 初心者がつまずく場所
- 不要になった古い手順
- 実務で使われている近道
- よくある失敗
も確認する。
#### 2. 「完成状態」を先に決める
投稿を読み終えた読者が
何をできるようになるかを具体化する。
悪い例：
「Claude Codeの使い方が分かる」
良い例：
「Claude Codeを導入し、最初の開発タスクを1つ完了できる」
ゴールに不要な説明は削ってください。
#### 3. 最短の手順にする
必要な工程を、
何をする
↓
具体的にどうする
↓
何が起きれば成功か
の順に整理する。
テーマに応じて、
- コピペできるプロンプト
- コマンド
- 設定値
- テンプレート
- 具体例
をそのまま使える形で提示する。
#### 4. つまずきを先回りする
特に失敗しやすい箇所だけ、
「うまくいかない場合は〇〇を確認」
のように補足する。
すべての例外を説明して
本筋を重くしないでください。
#### 5. 最も強いフックを選ぶ
- 何ができるようになるか明確
- <ベースプロンプト>の読者に関係する
- 難しそうなことが実行可能に見える
- 後で使いたくなる
### 投稿設計
1. 何ができるようになるか
2. 必要なもの・前提
3. STEP 1
4. STEP 2
5. STEP 3…
6. よくあるつまずき
7. 最初に試す具体例
8. 次にやること
## 自己診断・チェックリスト
#### 1. 診断したくなる切り口を探す
テーマから
- なりたい状態
- 避けたい状態
- 成果を出す人の共通行動
- 本人が気づきにくい癖
を探してください。
「仕事ができる人」のような広すぎるテーマより、
「AIを使うほど仕事が速くなる人」
「Xが伸び始める人」
のように、<ベースプロンプト>の読者が自分を判定したくなる切り口を優先する。
#### 2. 本当に特徴的なものだけ残す
候補を複数考え、
- 行動として観察できる
- 自分でYES / NOを判断できる
- 成果とのつながりを説明できる
- 他項目と重複しない
- 一部に「そこも？」という意外性がある
ものを残してください。
「努力家」「ポジティブ」「行動力がある」など、
誰にでも当てはまりやすい抽象的特徴は避けてください。
#### 3. 一覧性と意外性を両立する
題材と分量に合う項目数で、
水増しせず最適な数を選んでください。
序盤には「確かに」と納得できる特徴、
途中には「そこは意識していなかった」と思う特徴を混ぜてください。
最後に、複数の特徴を生んでいる
「共通する本質」を一文で見つけてください。
#### 4. 最も強いフックを選ぶ
- 自分に当てはまるか確認したくなる
- 誰についての投稿か一瞬で分かる
- 意外性がある
- 続きを読みたくなる
### 投稿設計
1. 診断テーマを提示
2. 具体的な特徴を一覧化
3. 特に重要・意外な特徴を少し掘る
4. 特徴を束ねる本質を一文で残す
としてください。
## やめることと代替行動
#### 1. 本当にやめる価値のある行動を探す
テーマについて、
- 初心者がやりがちな失敗
- 昔は有効だったが今は非効率な方法
- 良かれと思ってやるほど逆効果になる行動
- 経験者が避けている行動
- 時間・お金・機会を無駄にする習慣
を探してください。
単なるマナー論ではなく、
やめることで結果が変わるものを優先する。
#### 2. 「NG → なぜ → 代わりに」をセットにする
各項目は、
NG：
何をやめる？
理由：
なぜ問題なのか？
代替：
代わりに何をする？
まで考えてください。
「〇〇はやめた方がいい」だけで終わらせないでください。
#### 3. 意外なアンチパターンを優先する
明らかな失敗より、
「むしろ良いことだと思われているが、やりすぎると逆効果」
な行動を優先する。
例：
毎日投稿する
→ 振り返らず投稿数だけ増やすのはNG
長いプロンプトを書く
→ 毎回一発で正解を出そうとするのはNG
顧客の声を聞く
→ 「欲しいですか？」だけ聞くのはNG
#### 4. 項目を絞る
候補を複数調査し、
- <ベースプロンプト>の読者が実際にやりそう
- 損失・非効率が大きい
- 理由を説明できる
- 代替行動がある
- 他項目と重複しない
ものだけ残してください。
項目数は固定せず、
最も価値の高いものだけを使ってください。
#### 5. 最も強いフックを選ぶ
- 「自分もやっているかも」と思う
- 何を避けるべきか知りたくなる
- <ベースプロンプト>の読者に関係する
- 過剰な恐怖煽りではない
### 投稿設計
1. 避けたい結果・問題
2. NG行動を一覧化
3. 各NGがなぜ問題か
4. 代わりに取る行動
5. 特に重要な1つを少し深掘り
6. 「結局、何をやめるべきか」を一文で締める
## 成果と工程の公開
#### 1. テーマから「見せる成果」を決める
<ベースプロンプト>の読者が思わず続きを読みたくなる、
- できるようになったこと
- 大幅に楽になったこと
- 複数工程をまとめられたこと
- 意外な使い方
- 従来より速い・簡単・便利になったこと
などを特定する。
最新ツール・サービス・ニュース・仕様・性能比較など、
情報の鮮度が重要なテーマではまず調査メモを確認する。
根拠のない性能比較や数字は作らないでください。
#### 2. フックを作る
内部で複数のフック候補を作り、
最も続きを読みたくなるものを1つ選んでください。
冒頭1〜3行で、
「何を使って、何ができたのか」
ができるだけ具体的に分かるようにします。
可能なら、
- 固有名詞
- 成果
- 意外性
- 比較
- 効率化
- 驚き
のうち2つ以上を組み合わせてください。
抽象的な
「AIがすごい」
「便利な方法を紹介します」
のような始め方は避けてください。
#### 3. 工程を具体的に並べる
成果に至る流れを、
原則3〜7ステップ程度に分解する。
①
②
③
のように、視覚的に追いやすくします。
各ステップでは、
「ツール名 + 実際に行う操作」
が分かる程度まで具体化する。
ただし説明しすぎず、
一目で全体のワークフローが理解できる長さにしてください。
#### 4. 成果と労力のギャップを作る
工程を見せた後、
「一見複雑な成果に対して、
実際に人間がやることは非常に少ない」
というギャップがある場合は強調する。
例：
- 最初に指示するだけ
- 1つの操作だけ
- 条件を設定するだけ
- あとは自動で処理される
ただし、実際には必要な作業を省略して
過度に簡単そうに見せてはいけません。
#### 5. 続きのポストに続きを置く
追加情報がある場合は、
メイン投稿ですべて説明しきらず、
最も価値のある補足を、指定された本数の範囲で続きのポストへ展開する。
例えば、
- 詳しい設定方法
- 使用したプロンプト
- トークン・コスト削減方法
- 注意点
- 別の応用方法
- 実際の構成
- 比較結果
などです。
続きを読む理由がない場合は、
無理にスレッド化しないでください。
### 投稿設計
具体的な成果→必要な工程→成果と労力のギャップ。補足に独立した価値がある場合だけ、指定本数内で設定・プロンプト・費用・注意点・応用・比較結果を続ける。
# 分量と展開
一覧で作業・自己点検できるなら単発〜長文を優先する。各工程・特徴・NGに独立した理由・具体例・トラブル対処がある場合だけスレッドにし、1投稿目へ完成形と全体手順・主要な特徴・NG一覧を置く。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 具体的な手順：各工程で何をし、何が起きれば成功かが分かるか。完成形と最初に試す例があり、失敗しやすい箇所の確認方法まで示したか。
- 自己診断・チェックリスト：自分で当てはまるか判定でき、各項目が重複していないか。抽象的な性格ではなく行動で診断できるか。
- やめることと代替行動：NG・問題になる理由・代わりの行動がそろうか。読者が実際にしそうで、やめると結果が変わるものに絞ったか。
- 成果と工程の公開：何を使って何ができたかと、実際に必要な操作が分かるか。成果を大きく見せるために人の作業や前提を省いていないか。

# 投稿例

## 例1：単発

AIに市場調査をさせるなら、
いきなり「市場調査して」はおすすめしません。

この3段階に分けます。

① 論点を作る

「〇〇市場への参入を検討しています。
調査すべき論点を整理してください。
まだ調査は始めないでください。」

② 論点を人間が確認

不要なものを消す。
足りないものを足す。

③ 調査させる

「上記論点を調査してください。
最新情報を優先。
数字は一次情報を優先。
事実と推論を分けてください。」

設計
↓
調査

を分けるだけで、
AIが見当違いな方向へ走る確率をかなり下げられます。


## 例2：長文

AIで記事を書くとき、
最初から「記事を書いて」と頼まない方がいい。

僕ならこの順番です。

STEP1
Web調査

まず事実だけ集める。

STEP2
面白い事実を選ぶ

「読者の認識が変わるものだけ残して」
と依頼。

STEP3
読者の疑問を作る

「このテーマについて、
初心者が知りたい質問を20個出して」

STEP4
構成を3案作る

まだ本文は書かせない。

STEP5
一番面白い構成を選んで本文を書く。

特に重要なのはSTEP3。

AIは情報を集めるのは得意です。

でも
「読者が知りたいこと」
を外すと全部つまらなくなる。

文章を書く前に、
読者の問いを作る。

ここを挟むだけでかなり変わります。


## 例3：スレッド

1/

AIでWebサービスを作ってみたい初心者向け。

最初からコードを勉強し直さなくても、
まずここまでなら進められます。

全体は4STEPです。

① 作りたいものを文章にする
② AIに仕様書を作らせる
③ 開発環境を準備
④ 1機能ずつ実装

順番に説明します。

2/

STEP1：作りたいものを文章にする

最初から完璧な仕様書はいりません。

まずAIに、

「〇〇するWebサービスを作りたい。
ユーザー、主要機能、画面、必要データを整理してください。」

と渡す。

曖昧なアイデアを
一度構造化します。

3/

STEP2：仕様書にする

次に、

「初心者がAIコーディングで実装できる粒度に分解してください。
MVPに不要な機能は削ってください。」

と依頼。

ここで重要なのは
機能を増やすことではなく減らすことです。

4/

STEP3：開発環境を準備

使用するツールは、
必ず最新の公式手順を確認して導入。

ここでエラーが出たら、
エラーメッセージをそのままAIへ渡す。

要約して渡すより、
原文の方が原因を特定しやすい場合があります。

5/

STEP4：1機能ずつ作る

「サービス全部を作って」

ではなく、

ログイン
↓
入力
↓
保存
↓
表示

のように分ける。

AI開発で最初に覚えたいのは
コードより、

「大きな仕事を小さく渡すこと」です。


## 統合した切り口の例：「○○な人の特徴」自己診断

### 例1：単発

AIを使うほど仕事が速くなる人の特徴。

・毎回ゼロから説明しない
・1回で正解を出そうとしない
・過去の良い成果物をAIに見せる
・大きな仕事を小さく分ける
・最初に完成条件を決める
・同じ作業を2回やったら自動化を考える
・浮いた時間でもう1案試す

特に最後。

AIで30分浮いたとき、
その30分でもう1案試せる人は
作業時間だけでなく試行回数まで変わる。

AI活用が上手い人って、
プロンプトより
「浮いた時間の使い方」が上手い。


### 例2：長文

仕事が速い人を見ていると、
「手を動かす速度」以外の共通点が多い。

・依頼された瞬間に作業を始めない
・完成条件を先に確認する
・やらなくていい仕事を消す
・60点で一度見せる
・迷ったら早めに聞く
・同じ説明を二度しない仕組みを作る
・重要でない部分はちゃんと雑にやる

速い人って、
全部を高速で処理しているわけじゃない。

むしろ、

「速くやらなくていい仕事」
「そもそもやらなくていい仕事」

を見分けるのが上手い。


### 例3：スレッド

1/

Xが伸び始める人の特徴。

・投稿後の数字を分解する
・テーマとフックを別々に考える
・他人の投稿を文章ではなく構造で見る
・伸びなかった投稿も分析する
・毎回1つだけ仮説を変える

共通しているのは、
「投稿を作品として扱っていない」ことです。

2/

例えば伸びなかったとき。

「今回ダメだった」

で終わるのではなく、

テーマ？
冒頭？
具体例？
長さ？
投稿時間？

と分解する。

失敗した投稿も、
次の投稿を改善するデータになります。

3/

つまりXが伸びる人は、

投稿数が多い人というより
1投稿あたりの学習量が多い人。

X運用を
「文章を書くゲーム」ではなく
「仮説検証」に変えている人ほど強いと思います。

## 統合した切り口の例：やめること・NG・アンチパターン集

### 例1：単発

AIを使っているのに
仕事があまり速くならない人。

まずこの3つをやめたい。

① 毎回ゼロから説明する
→ 前提情報は再利用する

② 1回で完璧な回答を出そうとする
→ まず出して、ズレだけ直す

③ 何でもAIに任せる
→ 人間が判断すべき場所を先に決める

AI活用で大事なのは、
プロンプトを増やすことより

「毎回やらなくていいこと」

を増やすことだと思う。


### 例2：長文

Xが伸びないとき、
投稿数を増やす前にやめたいこと。

・伸びなかったらすぐ次を書く
・表示回数だけを見る
・毎回テーマも構成も全部変える
・「アルゴリズムが悪い」で終わる
・伸びた投稿を「たまたま」で済ませる

これを続けると、
100投稿しても学習がほとんど残らない。

代わりに、

テーマ
冒頭
構成
具体例
長さ

のどこを変えたか残す。

投稿数を増やすより、
1投稿から取れるデータを増やす。

Xでやめたいのは
「失敗すること」ではなく、

失敗から何も取らずに
次へ進むことです。


### 例3：スレッド

1/

AI開発初心者が
最初にやめたいことをまとめます。

① いきなり全部作らせる
② エラーを要約して渡す
③ AIのコードを確認せず実行
④ 大きな変更を一発で任せる
⑤ 動いたら終わりにする

特に危ないのは①です。

2/

①「サービス全部作って」

これをやると、
AIが一度に判断することが多すぎる。

代わりに、

ログイン
↓
入力
↓
保存
↓
表示

のように機能単位で渡す。

小さく作るほど、
どこで壊れたかも分かりやすい。

3/

② エラーを自分で要約する

初心者ほど、

「たぶんデータベースのエラーです」

のように解釈して渡しがち。

代わりに、
まずエラーメッセージ原文を渡す。

自分の推測を入れる前の情報の方が
AIが原因を特定しやすいことがあります。

4/

⑤「動いたから完成」

AI生成コードでは、
動くことと安全・保守可能であることは別。

最低でも、

テスト
エラー処理
権限
不要コード

は確認する。

5/

AI開発で避けたいのは、
AIを使うことではありません。

「AIが出したものを
理解しないまま大きくしていくこと」。

速く作れるほど、
小さく確認する習慣の価値が上がります。

## 統合した切り口の例：2026最新：成果実況・手順公開型

### 投稿例1

📝よし！Google AntigravityからNotebookLMを操作できたぞ！便利！しかもGemini 3.5だからCodexやClaude Codeより断然早い！

①Google AntigravityでNotebookLM操作のSkillsを呼び出し
②「本日分をお願い」と依頼
③Manusで調査済みの日刊AI系ニュースまとめファイルを取得
④ソースとしてNotebookLMに投げる
⑤別途用意済みのインフォグラフィック用プロンプトを投げつつ、NotebookLM上でインフォグラフィックを作成
⑥NotebookLMでソース情報を元に、Spotify用の音声を作成

完了！私はSkillsを呼び出して「本日分をお願い」と一言依頼しただけでここまで自動化できる

詳細は続きへ ↓

スレッド1
NotebookLMでトークン消費を劇的に抑えてDeep Researchをする方法　↓


### 投稿例2

📝競合調査→比較→資料の叩き台まで、AIにバラバラに頼む必要はない。

1本のワークフローにするとこうなる。

①調査したい市場を指定
②主要プレイヤーを洗い出す
③公式サイト・一次情報を収集
④比較軸ごとに整理
⑤重要な差分だけ抽出
⑥そのまま資料構成まで作る

人間が毎回やるのは「今回知りたいこと」を決める部分。

調査そのものより、
調査→整理→アウトプットまでつなげる方がAIは一気に使いやすくなる。

具体的な指示の作り方は続きへ ↓


### 投稿例3

📝毎日のSNS運用、投稿文を書くところだけAI化してもあまり楽にならない。

本当に減らしたいのは、その前後の作業。

①投稿ネタを収集
②使えそうな情報を選別
③自分のテーマに合わせて切り口を決定
④投稿案を生成
⑤公開候補をストック
⑥投稿後の反応を次回に反映

ここまでを1つの流れにしておけば、
毎回ゼロから「今日は何を書こう？」と考える必要がなくなる。

ポイントは文章生成ではなく、
投稿が生まれる仕組みそのものを作ること。

具体的な設計は続きへ ↓

投稿例

本文： AIコーディングツール、 「結局どれを使えばいい？」を1枚に整理しました。 性能ランキングではなく、 「どう仕事を任せたいか」で分ける方が分かりやすいです。 画像： タイトル： AI開発ツールの選び方 左： 自分でコードを見ながら進めたい → IDE型 中央： タスク単位でまとめて任せたい → Agent型 右： 補完だけ欲しい → Coding Assistant型 下部： 迷ったら 「どこまでAIに任せたいか」から選ぶ

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 狙い
比較・関係・手順を1枚で理解し、後から使える図解へ整理する。

# 作成手順・投稿設計

## 図解・チートシート

### 作成手順

#### 1. 画像化する価値のある情報を探す

テーマから

- 比較すると分かりやすいもの
- 手順・フロー
- 判断基準
- 全体像・分類
- チェックリスト
- 覚えておきたい一覧
- 複数情報の関係性

を探してください。

文章の方が分かりやすい内容を、
無理に図解しないでください。

#### 2. 画像の「1メッセージ」を決める

1枚で伝える核心を1つに絞ってください。

画像を見た瞬間に、

「何の資料か」
「何が分かるか」

が理解できるようにしてください。

情報を増やすより、
重要度の低い情報を捨ててください。

#### 3. 最適な図解形式を選ぶ

内容に応じて、例えば以下から選んでください。

- A vs B比較
- フローチャート
- ステップ図
- マトリクス
- ランキング
- チェックリスト
- ○選
- Before → After
- 階層図
- チートシート

見た目の派手さではなく、
最も速く理解できる形式を選んでください。

#### 4. モバイルで一瞬で読める設計にする

画像は、

- 強いタイトル1つ
- 情報を3〜7程度のまとまりに整理
- 重要度に応じて文字サイズに差をつける
- 長文段落を避ける
- 十分な余白を取る
- 小さい注釈に重要情報を置かない

ようにしてください。

画像を開かなくてもテーマが伝わり、
開くと詳細まで理解できる情報設計を目指してください。

#### 5. 本文と画像の役割を分ける

本文で画像内容をすべて説明しないでください。

本文：
「なぜ見るべきか」を伝える

画像：
「理解・比較・再利用する情報」を伝える

という役割に分けてください。

本文の冒頭候補を内部で複数作り、
最も画像を見たくなるものを選んでください。

例：

- 「〇〇、結局この1枚で整理できます。」
- 「〇〇で迷ったら、まずこれだけ見ればOKです。」
- 「複雑なので1枚に整理しました。」
- 「〇〇と△△の違い、文章よりこれを見る方が早いです。」
- 「保存用。〇〇するときの判断基準を1枚にまとめました。」

### 投稿設計

原則は、

1. 短い本文で問題・価値を提示
2. 1枚画像で情報本体を見せる
3. 必要なら本文末尾に1つだけ補足

としてください。

1枚で情報を理解・再利用できること自体がこの構文の価値なので、
原則スレッドにはしません。

ただし、画像が「全体マップ」で、
各項目を順番に深掘りすることにも独立した価値がある場合のみ
画像付き1投稿目＋スレッドを選んでください。

### 画像ルール

- 1枚1メッセージ
- 情報密度と可読性を両立する
- タイトルだけ大きくして中身を読めなくしない
- 装飾より情報の階層を優先する
- 重要な数字・比較・矢印は視覚的に目立たせる
- 本文のコピペを画像にしない
- 根拠のない数字・分類を作らない
- ブランドトーンが分かる場合はデザインへ反映する

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 図解・チートシート：画像だけで核心と項目の関係を理解できるか。小さい注釈に重要情報を押し込まず、本文を画像へ繰り返していないか。

# 投稿例

## 例1：比較図

本文：

AIコーディングツール、
「結局どれを使えばいい？」を1枚に整理しました。

性能ランキングではなく、
「どう仕事を任せたいか」で分ける方が分かりやすいです。

画像：

タイトル：
AI開発ツールの選び方

左：
自分でコードを見ながら進めたい
→ IDE型

中央：
タスク単位でまとめて任せたい
→ Agent型

右：
補完だけ欲しい
→ Coding Assistant型

下部：
迷ったら
「どこまでAIに任せたいか」から選ぶ


## 例2：チートシート

本文：

保存用。

AIに仕事を渡すとき、
僕ならこの5つだけ最初に確認します。

画像：

タイトル：
AIに仕事を任せる5つの確認事項

① 目的
何を達成したい？

② 前提
何を知っておく必要がある？

③ 完成条件
何ならOK？

④ 参考例
良い成果物はある？

⑤ 確認方法
何を人間がレビューする？

下部：
良いプロンプトより
「良い仕事の渡し方」を作る。


## 例3：フロー図＋スレッド

1/

新規事業の検証、
何からやるか迷いやすいので1枚にしました。

ポイントは、
「市場調査→開発」ではなく
途中に顧客行動の確認を入れることです。

画像：

アイデア
↓
課題の仮説
↓
現在の代替手段を確認
↓
簡易提案
↓
実際に買うか確認
↓
MVP
↓
利用行動を確認

2/

特に飛ばしたくないのが
「現在の代替手段」。

本当に困っている課題なら、

Excel
外注
手作業
他社サービス

など、すでに何かで解決していることが多い。

3/

だから僕なら、

「このサービス欲しいですか？」

より先に、

「今どうやって解決していますか？」

を聞きます。

図解の中では1ステップですが、
需要検証ではかなり重要です。

投稿例

元投稿： 「AIエージェントでコード生成がさらに高速化した」 引用本文： これ、開発速度より 「作るサービスの数が増える」方が重要だと思う。 開発コストが下がる ↓ 参入者が増える ↓ 似たサービスが増える ↓ 機能差が縮まる となれば、 次に希少になるのは 開発力よりDistribution。 AIが開発を民主化するほど、 営業・マーケ・顧客基盤の価値はむしろ上がりそう。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}
引用投稿URL：{引用投稿URL}
引用投稿の本文：{引用投稿の本文}

# 狙い
元投稿を言い換えず、具体化・影響・条件・実践など新しい視点を1つ足す。

# 作成手順・投稿設計

## 引用への独自解釈

### 作成手順

#### 1. 引用投稿を正確に理解する

「引用投稿の本文」に貼られた元投稿を読み、
主張と前提を正確に理解してください。

**X投稿のページはWeb検索では開けません。**
本文は上の欄に貼られたものがすべてです。
書かれていない投稿者・日時・前後の文脈を推測で補わないでください。

本文に出てくる固有名詞・数字のうち、
解釈を足すために裏取りが必要なものだけ調査メモで確認してください。

引用投稿URLは出典として使うだけで、
本文の代わりにはなりません。

#### 2. 「何を足せるか」を決める

元投稿を要約し直すのではなく、
以下から最も価値が高い追加要素を選んでください。

- 具体化：抽象論を具体的な場面に落とす
- 解釈：なぜ重要なのかを説明する
- 影響：<ベースプロンプト>の読者に何が変わるか示す
- 補強：別のデータ・事例で裏付ける
- 条件追加：「ただし○○の場合は違う」と解像度を上げる
- 接続：別のトレンドや出来事と結びつける
- 実践化：「では何をすればいいか」まで落とす

「これ本当にそう」「勉強になる」だけなら投稿しないでください。

#### 3. 元投稿との距離を作る

良い引用は、

元投稿：A
引用：Aを言い換える

ではなく、

元投稿：A
引用：AだからBが起きる / 実際にはCで現れる / Dの場合は例外

という関係です。

元投稿をすでに読んだ人にも、
新しい情報・視点が最低1つ増えることを必須としてください。

#### 4. 最も強い書き出しを選ぶ

冒頭候補を内部で複数作り、

- 元投稿を読んだ人にも価値がある
- 自分の解釈がすぐ分かる
- <ベースプロンプト>の読者に関係する
- 続きを読みたくなる

ものを採用してください。

### 投稿設計

基本は、

1. 自分の最重要な解釈
2. 具体例・データ・経験・条件
3. 元投稿とどうつながるか
4. <ベースプロンプト>の読者への示唆
5. 一文で自分の視点を残す

としてください。

原則は1つの引用ポストで完結させてください。

ただし、

- 元投稿から重要な示唆が複数導ける
- 各示唆に独立した具体例・データがある
- 深掘り自体に十分な価値がある

場合のみ、引用ポストを1投稿目としてスレッド化してください。

その場合も、引用ポスト単体で最重要な解釈まで伝えてください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 引用への独自解釈：元投稿を読んだ人にも新しい情報・視点が増えるか。引用の主張・前提と、自分が加えた解釈の境界が分かるか。

# 投稿例

## 例1：影響を一段先まで読む

元投稿：
「AIエージェントでコード生成がさらに高速化した」

引用本文：

これ、開発速度より
「作るサービスの数が増える」方が重要だと思う。

開発コストが下がる
↓
参入者が増える
↓
似たサービスが増える
↓
機能差が縮まる

となれば、

次に希少になるのは
開発力よりDistribution。

AIが開発を民主化するほど、
営業・マーケ・顧客基盤の価値はむしろ上がりそう。


## 例2：抽象論を具体化する

元投稿：
「優秀な人ほど、質問する前に自分で調べている」

引用本文：

これ、教える側になるとかなり実感します。

「どうすればいいですか？」

より、

「AとBを調べて、今はAだと思っています。
ただ、この一点だけ分かりません」

と聞かれる方が圧倒的に答えやすい。

質問力って、
良い質問を思いつく能力というより

「相手が考える範囲を小さくして渡す能力」

なのかもしれない。


## 例3：条件を加えて解像度を上げる

元投稿：
「AI時代はとにかく速く作って出すべき」

引用本文：

かなり同意。

ただ、
「何でも速く出せばいい」ではないと思う。

速く出す価値が大きいのは、

出した後のユーザー行動から
次の判断材料を取れる場合。

誰にも届かないMVPを
1週間で作っても学習量は少ない。

大事なのは開発速度ではなく、

仮説
↓
リリース
↓
データ
↓
次の仮説

この1周をどれだけ速く回せるかだと思う。

投稿例

AIを使うほど、 仕事が速くなる。 これは半分正しくて、 半分間違っています。 本当に差がつくのは 1回の仕事をどれだけ速く終えるかではない。 3案作る。 5パターン試す。 10社調べる。 20回改善する。 AIで浮いた時間を 「試行回数」に変えられるかです。 AI時代に強いのは、 仕事が速い人というより 同じ時間で より多く試せる人だと思う。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 今回の型の指定
「大胆な仮説」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
根拠と条件から、読者の判断を更新する意見・仮説・予測を示す。

# 切り口の選択
今回の題材と依頼に合う切り口を次から1つ選び、その切り口の作成手順と投稿設計だけを使ってください。選ばなかった切り口の流れや結論を混ぜないでください。
- 常識の見直し
- 根拠のある仮説・意見
- 未来予測・二次効果

# 作成手順・投稿設計

## 常識の見直し

### 作成手順

#### 1. 壊す価値のある「常識」を探す

テーマについて、

- 広く信じられている定説
- 最近よく繰り返されているアドバイス
- 初心者ほど信じやすい考え
- 昔は正しかったが環境変化で怪しくなった考え
- その常識と矛盾するデータ・事例

を探してください。

複数候補から、

「多くの<ベースプロンプト>の読者が信じている」
かつ
「見方を変えると実際の判断・行動まで変わる」

ものを選んでください。

#### 2. 逆説ではなく「新しい理解」を作る

主張は次のような構造を検討してください。

- Aではなく、本当に重要なのはB
- A自体は正しい。ただし結果を分けるのはB
- Aが増えるほど、逆にBの価値が上がる
- 昔はAだったが、今は前提が変わってBになった
- Aを最適化しすぎると、別のBがボトルネックになる

「世間と逆のことを言える」だけの案は捨ててください。

#### 3. 反論に耐えるか確認する

採用候補について、

「この主張への最も強い反論は何か？」

を考えてください。

その反論を踏まえても成立するように、
条件・根拠・具体例を整えてください。

投稿を読み終えたとき、
冒頭より読者の理解が深くなっていることを必須とします。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 一瞬で理解できる
- 違和感がある
- <ベースプロンプト>の読者に関係する
- 理由を知りたくなる

ものを採用してください。

### 投稿設計

基本構造：

1. 常識を揺さぶる結論
2. 一般にはなぜAと考えられているか
3. それだけでは説明できない事実・具体例
4. 本当に重要なB
5. なぜA→Bの変化が起きるのか
6. 読者の判断・行動がどう変わるか
7. 一文で新しい見方を残す

原則は、単発〜長文で主張から納得まで完結させてください。

ただし、

- 独立した強い根拠が複数ある
- 有力な反論も扱う必要がある
- 結論まで段階的に理解させた方が説得力が大きく上がる

場合はスレッドを選んでください。

スレッドでも1投稿目で
「常識」と「今回の主張」まで明示してください。

## 根拠のある仮説・意見

### 作成手順

#### 1. 意見が割れる論点を探す

テーマについて、

- 多数派と少数派が存在する論点
- 専門家でも判断が分かれる問題
- 最近、前提が変わり始めた常識
- どちらにも合理的な理由がある選択
- <ベースプロンプト>の読者の仕事・お金・将来に関係する争点

を探してください。

単なる好みではなく、
「どちらを信じるかで行動が変わる論点」を優先してください。

#### 2. 明確な立場を取る

複数の主張候補を考え、

- 反対意見が成立する
- それでも自分側にも十分な根拠がある
- <ベースプロンプト>の読者にとって重要
- 一文で立場が分かる
- ありきたりではない

ものを選んでください。

「場合によります」で逃げず、
条件を明確にした上で立場を取ってください。

#### 3. 反対側を最も強い形で考える

投稿を書く前に、

「この主張への最も強い反論は何か？」

を考えてください。

弱い反対意見を作って勝ったことにせず、
その反論を認めた上でも自分がこの立場を取る理由を整理してください。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 立場が一瞬で分かる
- 少し反論したくなる
- 理由を知りたくなる
- <ベースプロンプト>の読者に関係する

ものを採用してください。

### 投稿設計

基本構造：

1. 明確な主張
2. 多数派が逆を考える理由
3. 自分がこの立場を取る根拠
4. 具体例・データ・構造
5. 最も強い反論
6. それでも結論が変わらない理由
7. どの条件なら逆になるか
8. 一文で立場を残す

原則は単発〜長文で、
主張と主要な根拠まで一度に伝えてください。

ただし、複数の独立した根拠や反論を順番に検討することで
議論の質が大きく上がる場合はスレッドにしてください。

スレッドでも1投稿目で
「今回取る立場＋最大の理由」
まで明示してください。

## 未来予測・二次効果

### 作成手順

#### 1. 現在のシグナルを集める

調査メモからテーマについて

- 技術進歩
- 価格・コスト変化
- ユーザー行動
- 企業の投資・採用・撤退
- 新しいサービス
- 規制・制度
- 市場構造
- 専門家・当事者の発言

など、直近の変化を集めてください。

1つのニュースだけで未来を予測せず、
可能なら複数の独立したシグナルが同じ方向を示すものを優先してください。

#### 2. 一次効果の先まで考える

予測候補について、

現在の変化
↓
一次効果：直接何が変わる？
↓
二次効果：その結果、人や企業はどう行動を変える？
↓
三次効果：さらに何の価値が上がる・下がる？

まで考えてください。

投稿では、
誰でも予想できる一次効果より
二次・三次効果を主役にしてください。

例：

AIで開発が速くなる
↓
作られるサービスが増える
↓
機能差が縮まる
↓
営業・ブランド・顧客基盤の価値が上がる

#### 3. 予測の妥当性を確認する

採用する前に内部で、

- 過去の似た変化では何が起きたか
- この予測が外れるとしたら何が原因か
- 別の未来も十分あり得ないか
- どの時間軸なら現実的か

を確認してください。

遠い未来ほど断定を弱め、
近い未来ほど具体的にしてください。

ただし投稿を不必要な注意書きだらけにしないでください。

#### 4. 最も強い未来を選ぶ

複数候補から、

- 現在の根拠が強い
- 一次効果より一段先を読んでいる
- <ベースプロンプト>の読者への影響が大きい
- 少し意外だが論理的
- 今知ることで行動が変わる

ものを選んでください。

#### 5. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 未来像が一瞬で分かる
- 意外性がある
- 「なぜ？」と思う
- <ベースプロンプト>の読者に関係する

ものを採用してください。

### 投稿設計

基本構造：

1. 未来予測を明確に提示
2. 今起きているシグナル
3. 一次効果
4. 二次・三次効果
5. なぜその未来が起きるのか
6. <ベースプロンプト>の読者への影響
7. 今から見るべき・変えるべきこと

1本の因果関係で十分伝わるなら、
原則は単発〜長文で完結させてください。

複数の独立したシグナルや、
「現在→一次効果→二次効果→三次効果」を段階的に見せることで
説得力が大きく上がる場合はスレッドにしてください。

スレッドでも1投稿目で
「予測＋最大の理由」
まで明示してください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 常識の見直し：冒頭より理解が深まり、読者が変える判断を示したか。最も強い反論を踏まえても主張が成り立つか。
- 根拠のある仮説・意見：反対側を最も強い形で考えてもこの立場を取る理由があるか。どの条件なら逆の判断になるかが分かるか。
- 未来予測・二次効果：現在のシグナルから二次・三次効果まで論理がつながるか。別の未来、外れる兆候、想定する時間軸を検討したか。

# 投稿例

## 例1：単発

AIを使うほど、
仕事が速くなる。

これは半分正しくて、
半分間違っています。

本当に差がつくのは
1回の仕事をどれだけ速く終えるかではない。

3案作る。
5パターン試す。
10社調べる。
20回改善する。

AIで浮いた時間を
「試行回数」に変えられるかです。

AI時代に強いのは、
仕事が速い人というより

同じ時間で
より多く試せる人だと思う。


## 例2：長文

AIでソフトウェア開発が簡単になるほど、
「作れること」の価値は相対的に下がると思っています。

一見すると逆です。

開発速度が上がる。
少人数でも作れる。
個人でもサービスを出せる。

当然、エンジニアリングの生産性は上がる。

でも全員の開発コストが下がると、

作れるサービスが増える
↓
似た機能が増える
↓
機能だけでは差がつきにくくなる

という変化も起きる。

すると次に希少になるのは、

何を作るか
誰に売るか
どう届けるか
なぜ選ばれるか

の方です。

AIが開発を民主化するほど、
事業のボトルネックは
開発からDistributionへ移る可能性がある。

技術の価値がなくなるのではない。

技術だけで勝てる希少性が下がる。

ここは分けて考えた方がいい。


## 例3：スレッド

1/

「AIが進化すると、若手の価値は下がる」

一見かなり合理的です。

調査。
資料作成。
コード。
データ整理。

これまで若手が担当していた仕事を
AIが代替し始めている。

でも僕は、
逆の可能性もあると思っています。

2/

AIが代替するのは、
「若手」そのものではありません。

若手に任せていた
作業の一部です。

ここを分けて考える必要があります。

3/

作業がAIへ移ると、

以前：
若手1人 → 作業中心

これから：
若手1人＋AI → 作業＋分析＋提案

のように、
若い段階から任せられる仕事の幅が広がる可能性がある。

4/

もちろん、

「ジュニア業務がなくなれば育成機会もなくなる」

という問題はあります。

これはかなり大きい。

だから若手の価値が
自動的に上がるとは言えません。

5/

ただし結論は、

AI → 若手不要

ほど単純ではないと思う。

むしろ、

AI前提で若手を育成できる会社
と
従来のジュニア業務に依存する会社

で差が広がる。

AIによって変わるのは
若手の価値というより、

「若手に何を任せるか」

なのかもしれません。


## 統合した切り口の例：大胆仮説・Hot Take

### 例1：単発

AI時代ほど、
営業の価値は上がると思っています。

一見逆です。

メールはAIが書く。
提案書もAIが作る。
顧客リストもAIが探す。

だから営業は減りそうに見える。

でも同時に、

作れる会社が増える
↓
似た商品が増える
↓
機能差が縮まる
↓
「なぜ自社を選ぶか」の重要性が上がる

という変化も起きる。

AIが消すのは営業というより、
付加価値の低い営業。

商品が作りやすくなるほど、
売れる仕組みの希少性は上がると思う。


### 例2：長文

スタートアップ初期なら、
「競合がいない市場」より
競合がいる市場の方を選びたい。

普通は逆に見えます。

競合がいない。
つまりブルーオーシャン。

魅力的です。

でも競合がいない理由は、

誰も気づいていない

だけではなく、

そもそも顧客がお金を払わない

可能性もある。

競合がいる市場には少なくとも、

顧客が存在する
課題が存在する
支払い実績が存在する

という証拠がある。

もちろん競争は激しくなる。

だから
「競合が多いほど良い」
ではありません。

ただ初期の新規事業なら、

競合の存在をリスクではなく
需要の証拠として見る方がいいと思っています。


### 例3：スレッド

1/

AI時代、
大学に行く価値は下がる。

この意見はかなり分かります。

知識だけならAIから学べる。
講義もオンラインで見られる。

でも僕は、
むしろ一部の大学の価値は上がる可能性があると思っています。

理由は「授業」ではありません。

2/

AIによって安くなるのは
知識へのアクセスです。

以前：

良い知識
→ 大学・専門家が持っている

これから：

良い知識
→ AIで誰でもアクセスできる

ここだけ見ると、
大学の価値は下がります。

3/

でも、
知識がコモディティ化すると
別のものが希少になります。

・誰と学ぶか
・誰と働くか
・どんな環境に入れるか
・どんな人から評価されるか

つまりネットワークや選抜機能です。

4/

もちろん、

「そのためだけに高い学費を払うのか」

という反論は強い。

大学によっては
費用対効果がさらに悪くなる可能性もある。

5/

だから僕の主張は、

「大学は全部重要になる」

ではありません。

AIによって

知識提供だけの大学
と
強い人材・ネットワークを集められる大学

の価値差がむしろ広がる、です。

AIが大学を消すというより、
大学の価値を「授業」以外へ移す可能性があると思っています。

## 統合した切り口の例：未来予測・二次効果予測

### 例1：単発

AIでソフトウェア開発が安くなるほど、
営業の価値は上がると思う。

開発コストが下がる
↓
作る会社が増える
↓
似たサービスが増える
↓
機能だけでは差がつきにくくなる

その結果、
希少になるのは

「作れる会社」

ではなく

「選ばれる会社」。

AIがエンジニアリングを民主化するほど、
Distributionの価値はむしろ上がる可能性がある。


### 例2：長文

数年後、
「AIを使える人」という言葉は
かなり意味を失うと思っています。

今はまだ、

ChatGPTを使える
Claude Codeを使える
AIエージェントを使える

こと自体に差がある。

でも普及すれば、
AIを使うことは
検索やExcelと同じ前提になる。

すると希少性が移る。

何を調べるか。
何を作るか。
どこまで任せるか。
何を信じるか。
どこで人間が判断するか。

AIが賢くなるほど、
操作方法を知っていることより
「判断する場所を決められること」が重要になる。

AIスキルの価値が消えるのではない。

価値の中心が
操作から判断へ移ると思う。


### 例3：スレッド

1/

AIエージェントが普及すると、
「仕事が自動化される」

より先に起きると思うことがあります。

人事評価が変わる。

作業量で人を評価するのが
かなり難しくなると思っています。

2/

これまでは、

資料を20枚作った
100件営業した
10時間作業した

のように、
人間の作業量が成果の代理指標になっていました。

3/

でもAIが、

調査
文章作成
資料作成
分析

を大量に代替すると、

「何時間作業したか」

と

「どれだけ価値を出したか」

がさらに離れていく。

4/

すると評価軸は、

どれだけ作業したか
↓
何を決めたか
↓
何を実現したか

へ移る可能性がある。

5/

さらにその先。

成果で評価される比率が上がるなら、

職種
勤務時間
チーム人数

の意味まで少しずつ変わるかもしれない。

6/

AIが変えるのは、
作業方法だけではない。

「仕事とは何を評価するものか」

まで変える可能性がある。

AIニュースを見るとき、
僕なら生産性だけでなく
評価制度の変化も追います。

投稿例

AIを使うほど、 仕事が速くなる。 これは半分正しくて、 半分間違っています。 本当に差がつくのは 1回の仕事をどれだけ速く終えるかではない。 3案作る。 5パターン試す。 10社調べる。 20回改善する。 AIで浮いた時間を 「試行回数」に変えられるかです。 AI時代に強いのは、 仕事が速い人というより 同じ時間で より多く試せる人だと思う。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 今回の型の指定
「未来予測・二次効果」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
根拠と条件から、読者の判断を更新する意見・仮説・予測を示す。

# 切り口の選択
今回の題材と依頼に合う切り口を次から1つ選び、その切り口の作成手順と投稿設計だけを使ってください。選ばなかった切り口の流れや結論を混ぜないでください。
- 常識の見直し
- 根拠のある仮説・意見
- 未来予測・二次効果

# 作成手順・投稿設計

## 常識の見直し

### 作成手順

#### 1. 壊す価値のある「常識」を探す

テーマについて、

- 広く信じられている定説
- 最近よく繰り返されているアドバイス
- 初心者ほど信じやすい考え
- 昔は正しかったが環境変化で怪しくなった考え
- その常識と矛盾するデータ・事例

を探してください。

複数候補から、

「多くの<ベースプロンプト>の読者が信じている」
かつ
「見方を変えると実際の判断・行動まで変わる」

ものを選んでください。

#### 2. 逆説ではなく「新しい理解」を作る

主張は次のような構造を検討してください。

- Aではなく、本当に重要なのはB
- A自体は正しい。ただし結果を分けるのはB
- Aが増えるほど、逆にBの価値が上がる
- 昔はAだったが、今は前提が変わってBになった
- Aを最適化しすぎると、別のBがボトルネックになる

「世間と逆のことを言える」だけの案は捨ててください。

#### 3. 反論に耐えるか確認する

採用候補について、

「この主張への最も強い反論は何か？」

を考えてください。

その反論を踏まえても成立するように、
条件・根拠・具体例を整えてください。

投稿を読み終えたとき、
冒頭より読者の理解が深くなっていることを必須とします。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 一瞬で理解できる
- 違和感がある
- <ベースプロンプト>の読者に関係する
- 理由を知りたくなる

ものを採用してください。

### 投稿設計

基本構造：

1. 常識を揺さぶる結論
2. 一般にはなぜAと考えられているか
3. それだけでは説明できない事実・具体例
4. 本当に重要なB
5. なぜA→Bの変化が起きるのか
6. 読者の判断・行動がどう変わるか
7. 一文で新しい見方を残す

原則は、単発〜長文で主張から納得まで完結させてください。

ただし、

- 独立した強い根拠が複数ある
- 有力な反論も扱う必要がある
- 結論まで段階的に理解させた方が説得力が大きく上がる

場合はスレッドを選んでください。

スレッドでも1投稿目で
「常識」と「今回の主張」まで明示してください。

## 根拠のある仮説・意見

### 作成手順

#### 1. 意見が割れる論点を探す

テーマについて、

- 多数派と少数派が存在する論点
- 専門家でも判断が分かれる問題
- 最近、前提が変わり始めた常識
- どちらにも合理的な理由がある選択
- <ベースプロンプト>の読者の仕事・お金・将来に関係する争点

を探してください。

単なる好みではなく、
「どちらを信じるかで行動が変わる論点」を優先してください。

#### 2. 明確な立場を取る

複数の主張候補を考え、

- 反対意見が成立する
- それでも自分側にも十分な根拠がある
- <ベースプロンプト>の読者にとって重要
- 一文で立場が分かる
- ありきたりではない

ものを選んでください。

「場合によります」で逃げず、
条件を明確にした上で立場を取ってください。

#### 3. 反対側を最も強い形で考える

投稿を書く前に、

「この主張への最も強い反論は何か？」

を考えてください。

弱い反対意見を作って勝ったことにせず、
その反論を認めた上でも自分がこの立場を取る理由を整理してください。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 立場が一瞬で分かる
- 少し反論したくなる
- 理由を知りたくなる
- <ベースプロンプト>の読者に関係する

ものを採用してください。

### 投稿設計

基本構造：

1. 明確な主張
2. 多数派が逆を考える理由
3. 自分がこの立場を取る根拠
4. 具体例・データ・構造
5. 最も強い反論
6. それでも結論が変わらない理由
7. どの条件なら逆になるか
8. 一文で立場を残す

原則は単発〜長文で、
主張と主要な根拠まで一度に伝えてください。

ただし、複数の独立した根拠や反論を順番に検討することで
議論の質が大きく上がる場合はスレッドにしてください。

スレッドでも1投稿目で
「今回取る立場＋最大の理由」
まで明示してください。

## 未来予測・二次効果

### 作成手順

#### 1. 現在のシグナルを集める

調査メモからテーマについて

- 技術進歩
- 価格・コスト変化
- ユーザー行動
- 企業の投資・採用・撤退
- 新しいサービス
- 規制・制度
- 市場構造
- 専門家・当事者の発言

など、直近の変化を集めてください。

1つのニュースだけで未来を予測せず、
可能なら複数の独立したシグナルが同じ方向を示すものを優先してください。

#### 2. 一次効果の先まで考える

予測候補について、

現在の変化
↓
一次効果：直接何が変わる？
↓
二次効果：その結果、人や企業はどう行動を変える？
↓
三次効果：さらに何の価値が上がる・下がる？

まで考えてください。

投稿では、
誰でも予想できる一次効果より
二次・三次効果を主役にしてください。

例：

AIで開発が速くなる
↓
作られるサービスが増える
↓
機能差が縮まる
↓
営業・ブランド・顧客基盤の価値が上がる

#### 3. 予測の妥当性を確認する

採用する前に内部で、

- 過去の似た変化では何が起きたか
- この予測が外れるとしたら何が原因か
- 別の未来も十分あり得ないか
- どの時間軸なら現実的か

を確認してください。

遠い未来ほど断定を弱め、
近い未来ほど具体的にしてください。

ただし投稿を不必要な注意書きだらけにしないでください。

#### 4. 最も強い未来を選ぶ

複数候補から、

- 現在の根拠が強い
- 一次効果より一段先を読んでいる
- <ベースプロンプト>の読者への影響が大きい
- 少し意外だが論理的
- 今知ることで行動が変わる

ものを選んでください。

#### 5. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 未来像が一瞬で分かる
- 意外性がある
- 「なぜ？」と思う
- <ベースプロンプト>の読者に関係する

ものを採用してください。

### 投稿設計

基本構造：

1. 未来予測を明確に提示
2. 今起きているシグナル
3. 一次効果
4. 二次・三次効果
5. なぜその未来が起きるのか
6. <ベースプロンプト>の読者への影響
7. 今から見るべき・変えるべきこと

1本の因果関係で十分伝わるなら、
原則は単発〜長文で完結させてください。

複数の独立したシグナルや、
「現在→一次効果→二次効果→三次効果」を段階的に見せることで
説得力が大きく上がる場合はスレッドにしてください。

スレッドでも1投稿目で
「予測＋最大の理由」
まで明示してください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 常識の見直し：冒頭より理解が深まり、読者が変える判断を示したか。最も強い反論を踏まえても主張が成り立つか。
- 根拠のある仮説・意見：反対側を最も強い形で考えてもこの立場を取る理由があるか。どの条件なら逆の判断になるかが分かるか。
- 未来予測・二次効果：現在のシグナルから二次・三次効果まで論理がつながるか。別の未来、外れる兆候、想定する時間軸を検討したか。

# 投稿例

## 例1：単発

AIを使うほど、
仕事が速くなる。

これは半分正しくて、
半分間違っています。

本当に差がつくのは
1回の仕事をどれだけ速く終えるかではない。

3案作る。
5パターン試す。
10社調べる。
20回改善する。

AIで浮いた時間を
「試行回数」に変えられるかです。

AI時代に強いのは、
仕事が速い人というより

同じ時間で
より多く試せる人だと思う。


## 例2：長文

AIでソフトウェア開発が簡単になるほど、
「作れること」の価値は相対的に下がると思っています。

一見すると逆です。

開発速度が上がる。
少人数でも作れる。
個人でもサービスを出せる。

当然、エンジニアリングの生産性は上がる。

でも全員の開発コストが下がると、

作れるサービスが増える
↓
似た機能が増える
↓
機能だけでは差がつきにくくなる

という変化も起きる。

すると次に希少になるのは、

何を作るか
誰に売るか
どう届けるか
なぜ選ばれるか

の方です。

AIが開発を民主化するほど、
事業のボトルネックは
開発からDistributionへ移る可能性がある。

技術の価値がなくなるのではない。

技術だけで勝てる希少性が下がる。

ここは分けて考えた方がいい。


## 例3：スレッド

1/

「AIが進化すると、若手の価値は下がる」

一見かなり合理的です。

調査。
資料作成。
コード。
データ整理。

これまで若手が担当していた仕事を
AIが代替し始めている。

でも僕は、
逆の可能性もあると思っています。

2/

AIが代替するのは、
「若手」そのものではありません。

若手に任せていた
作業の一部です。

ここを分けて考える必要があります。

3/

作業がAIへ移ると、

以前：
若手1人 → 作業中心

これから：
若手1人＋AI → 作業＋分析＋提案

のように、
若い段階から任せられる仕事の幅が広がる可能性がある。

4/

もちろん、

「ジュニア業務がなくなれば育成機会もなくなる」

という問題はあります。

これはかなり大きい。

だから若手の価値が
自動的に上がるとは言えません。

5/

ただし結論は、

AI → 若手不要

ほど単純ではないと思う。

むしろ、

AI前提で若手を育成できる会社
と
従来のジュニア業務に依存する会社

で差が広がる。

AIによって変わるのは
若手の価値というより、

「若手に何を任せるか」

なのかもしれません。


## 統合した切り口の例：大胆仮説・Hot Take

### 例1：単発

AI時代ほど、
営業の価値は上がると思っています。

一見逆です。

メールはAIが書く。
提案書もAIが作る。
顧客リストもAIが探す。

だから営業は減りそうに見える。

でも同時に、

作れる会社が増える
↓
似た商品が増える
↓
機能差が縮まる
↓
「なぜ自社を選ぶか」の重要性が上がる

という変化も起きる。

AIが消すのは営業というより、
付加価値の低い営業。

商品が作りやすくなるほど、
売れる仕組みの希少性は上がると思う。


### 例2：長文

スタートアップ初期なら、
「競合がいない市場」より
競合がいる市場の方を選びたい。

普通は逆に見えます。

競合がいない。
つまりブルーオーシャン。

魅力的です。

でも競合がいない理由は、

誰も気づいていない

だけではなく、

そもそも顧客がお金を払わない

可能性もある。

競合がいる市場には少なくとも、

顧客が存在する
課題が存在する
支払い実績が存在する

という証拠がある。

もちろん競争は激しくなる。

だから
「競合が多いほど良い」
ではありません。

ただ初期の新規事業なら、

競合の存在をリスクではなく
需要の証拠として見る方がいいと思っています。


### 例3：スレッド

1/

AI時代、
大学に行く価値は下がる。

この意見はかなり分かります。

知識だけならAIから学べる。
講義もオンラインで見られる。

でも僕は、
むしろ一部の大学の価値は上がる可能性があると思っています。

理由は「授業」ではありません。

2/

AIによって安くなるのは
知識へのアクセスです。

以前：

良い知識
→ 大学・専門家が持っている

これから：

良い知識
→ AIで誰でもアクセスできる

ここだけ見ると、
大学の価値は下がります。

3/

でも、
知識がコモディティ化すると
別のものが希少になります。

・誰と学ぶか
・誰と働くか
・どんな環境に入れるか
・どんな人から評価されるか

つまりネットワークや選抜機能です。

4/

もちろん、

「そのためだけに高い学費を払うのか」

という反論は強い。

大学によっては
費用対効果がさらに悪くなる可能性もある。

5/

だから僕の主張は、

「大学は全部重要になる」

ではありません。

AIによって

知識提供だけの大学
と
強い人材・ネットワークを集められる大学

の価値差がむしろ広がる、です。

AIが大学を消すというより、
大学の価値を「授業」以外へ移す可能性があると思っています。

## 統合した切り口の例：未来予測・二次効果予測

### 例1：単発

AIでソフトウェア開発が安くなるほど、
営業の価値は上がると思う。

開発コストが下がる
↓
作る会社が増える
↓
似たサービスが増える
↓
機能だけでは差がつきにくくなる

その結果、
希少になるのは

「作れる会社」

ではなく

「選ばれる会社」。

AIがエンジニアリングを民主化するほど、
Distributionの価値はむしろ上がる可能性がある。


### 例2：長文

数年後、
「AIを使える人」という言葉は
かなり意味を失うと思っています。

今はまだ、

ChatGPTを使える
Claude Codeを使える
AIエージェントを使える

こと自体に差がある。

でも普及すれば、
AIを使うことは
検索やExcelと同じ前提になる。

すると希少性が移る。

何を調べるか。
何を作るか。
どこまで任せるか。
何を信じるか。
どこで人間が判断するか。

AIが賢くなるほど、
操作方法を知っていることより
「判断する場所を決められること」が重要になる。

AIスキルの価値が消えるのではない。

価値の中心が
操作から判断へ移ると思う。


### 例3：スレッド

1/

AIエージェントが普及すると、
「仕事が自動化される」

より先に起きると思うことがあります。

人事評価が変わる。

作業量で人を評価するのが
かなり難しくなると思っています。

2/

これまでは、

資料を20枚作った
100件営業した
10時間作業した

のように、
人間の作業量が成果の代理指標になっていました。

3/

でもAIが、

調査
文章作成
資料作成
分析

を大量に代替すると、

「何時間作業したか」

と

「どれだけ価値を出したか」

がさらに離れていく。

4/

すると評価軸は、

どれだけ作業したか
↓
何を決めたか
↓
何を実現したか

へ移る可能性がある。

5/

さらにその先。

成果で評価される比率が上がるなら、

職種
勤務時間
チーム人数

の意味まで少しずつ変わるかもしれない。

6/

AIが変えるのは、
作業方法だけではない。

「仕事とは何を評価するものか」

まで変える可能性がある。

AIニュースを見るとき、
僕なら生産性だけでなく
評価制度の変化も追います。

投稿例

AIで開発している人に聞きたいです。 今ゼロから1人でWebサービスを作るなら、 Cursor中心 or Claude Code中心 どちらに寄せますか？ 細かくコードを見ながら直すならCursor、 まとまったタスクを任せるならClaude Code、 という違いはありそうですが、 実際に両方を継続利用している人は 最終的にどちらを中心にしていますか？

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 狙い
検索で一意に決まらない経験・判断・実例を、読者から集める問いを作る。

# 作成手順・投稿設計

## 経験者への問い

### 作成手順

#### 1. 聞く価値のある問いを探す

テーマについて、

- 経験者によって答えが変わる
- A/Bどちらにも合理性がある
- 実際にやった人しか分からない
- 最近の環境変化で正解が定まっていない
- 他人の回答も読みたくなる

論点を挙げてください。

検索すれば事実が1つに決まる質問は避けてください。

#### 2. 「誰に答えてほしいか」を明確にする

必要に応じて、

- 実際に〇〇を使っている人
- 〇〇を経験した人
- 〇〇を仕事にしている人

のように回答者を具体化してください。

ただし対象を狭めすぎて、
答えられる人を不必要に減らさないでください。

#### 3. 回答しやすい問いにする

良い問いは、

- 数秒で意味が分かる
- 短く答えることもできる
- 経験があれば理由まで語れる
- 何を答えればよいか明確

なものです。

最後に聞く質問は原則1つに絞ってください。

#### 4. 必要な前提と仮説を少しだけ置く

質問だけ丸投げせず、
回答に必要な背景や比較軸を簡潔に示してください。

現在の考えや身近な場面も示すと議論が起きやすくなります。

#### 5. 最も答えたくなる書き出しを選ぶ

冒頭候補を内部で複数作り、

- 回答者が「自分向け」と感じる
- 質問内容がすぐ分かる
- 経験を語りたくなる
- 他の回答も気になる

ものを採用してください。

### 投稿設計

基本は、

1. 誰に聞きたいか
2. なぜ聞きたいか・最低限の背景
3. 比較軸や現在の仮説
4. 答えてほしい問いを1つ

としてください。

原則は1投稿で完結させ、
質問を一目で理解できる短〜中程度の投稿を優先してください。

回答に必要な背景が複雑な場合のみ長文を使い、
スレッド化は原則避けてください。
質問と前提が分散すると回答ハードルが上がるためです。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 経験者への問い：誰が何を答えるか一読で分かり、短くも理由つきでも回答できるか。最後の問いは1つで、前提が別ポストへ散らばっていないか。

# 投稿例

## 例1：ツール選択

AIで開発している人に聞きたいです。

今ゼロから1人でWebサービスを作るなら、

Cursor中心
or
Claude Code中心

どちらに寄せますか？

細かくコードを見ながら直すならCursor、
まとまったタスクを任せるならClaude Code、

という違いはありそうですが、

実際に両方を継続利用している人は
最終的にどちらを中心にしていますか？


## 例2：営業

法人営業をやっている人に聞きたい。

初回商談の前、
「調査はここまでで十分」と判断する基準ってありますか？

会社概要、決算、ニュース、相手の経歴まで
調べようと思えば無限に調べられる。

でも時間をかけすぎても意味がない。

営業が強い人は、
何を確認した時点で商談に入りますか？


## 例3：ゲーム開発

Steamでゲームを出した経験がある人に聞きたいです。

初めての1本なら、

3〜4ヶ月で小さく出す
or
半年以上かけて完成度を上げる

どちらを選びますか？

早く出せば、
ストア運用・価格・レビューまで含めて学べる。

一方で、
完成度の低い1作目を出すリスクもある。

実際にリリースした人なら、
今やり直すとしたらどちらを選びますか？

投稿例

※以下の数値は構造を示すための例です。

売上は20%増。 これだけなら 「順調に成長した」で終わります。 でも、 売上：100 → 120 利益：10 → 20 なら見え方が変わる。 売上は1.2倍なのに、 利益は2倍。 重要なのは売上成長ではなく、 「追加の売上が以前より大きく利益として残る構造」 に変わっていることです。 事業を見るなら、 成長率だけではなく 成長した1円がどこへ行くかまで見たい。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 今回の型の指定
「大量の事例からのパターン抽出」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
数字や事例、証拠のつながりから、読者の判断が変わる発見を取り出す。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 数字の解釈
- 複数事例のパターン抽出
- 深い調査から1つの結論
# 作成手順・投稿設計
## 数字の解釈
#### 1. 強いデータを探す
調査メモからテーマに関する最新データを集めてください。
公式統計、決算、一次資料、論文、公式ベンチマークなどを優先し、
- 成長率
- 売上・利益
- 利用者数・利用時間
- 市場シェア
- 費用・時間
- 導入率
- 過去との変化
- 競合との差
などを広く確認する。
数字は必ず、期間・母数・比較条件・元データまで確認する。
#### 2. 「驚き」ではなく「認識が変わる数字」を選ぶ
候補から、
- 想像より大きい / 小さい
- 過去や競合と比べると異常
- 相対値と絶対値で印象が変わる
- 別の数字と組み合わせると新しい意味が見える
- <ベースプロンプト>の読者の判断・行動が変わる
ものを選んでください。
「100%増」のような数字は、
元の規模が小さくないかも必ず確認する。
#### 3. 数字を人間が理解できる形に変換する
必要に応じて、
- 前年・数年前との比較
- 競合・業界平均との比較
- 1日 / 1人 / 1件あたり
- Before → After
- 絶対値と割合の両方
で示してください。
比較することで意味が薄くなる場合は、無理に例えを作らないでください。
#### 4. 「つまり」を一段深くする
以下を考えてください。
① 数字上、何が起きている？
② 一般的にはどう解釈される？
③ 実は何を示している？
④ その結果、<ベースプロンプト>の読者に何が変わる？
投稿の中心は③〜④です。
数字を紹介して終わらせず、
「この数字によって何の見方を変えるべきか」まで示してください。
#### 5. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 数字＋比較だけで驚きが伝わる
- 一瞬で理解できる
- <ベースプロンプト>の読者に関係する
- 解釈の続きを知りたくなる
ものを採用する。
### 投稿設計
1. 最も強い数字＋比較
2. なぜその数字が異常なのか
3. 一般的な解釈
4. 一段深い解釈
5. <ベースプロンプト>の読者への影響
6. 一文で結論
1つの数字と比較だけで洞察が成立するなら、
原則は単発〜長文で完結させてください。
一方で、
- 複数の独立したデータが同じ方向を示している
- 時系列で変化を追う必要がある
- データA→B→Cを組み合わせて初めて結論が見える
場合はスレッドを選んでください。
スレッドでも1投稿目で
「最重要データ＋今回の解釈」
まで示してください。
## 複数事例のパターン抽出
#### 1. 比較するサンプルを集める
調査メモからテーマに関する十分な数の事例を集めてください。
可能なら、
- 成功・高反応事例
- 平均的な事例
- うまくいかなかった事例
を比較する。
有名な成功例だけを集めて
「共通点＝成功要因」と判断しないでください。
投稿を分析する場合は、
アカウント規模だけで伸びた事例を避けるため、
可能ならその投稿者の通常投稿との相対差も確認する。
#### 2. 先入観を持たずに特徴を分解する
各事例を、テーマに応じて
- 最初の行動・戦略
- 判断基準
- 順番
- 数字
- 共通する制約
- やっていること
- やっていないこと
- X投稿ならフック・構成・具体性・形式
などに分解する。
最初から「これが成功要因だ」と決めず、
データから繰り返し現れる特徴を探してください。
#### 3. 本当に強いパターンだけ残す
候補について、
- 複数の独立した事例で確認できる
- 成功例だけでなく比較対象との差がある
- 当たり前すぎない
- <ベースプロンプト>の読者が再現できる
- なぜ効くのか説明できる
ものを残してください。
反例も探し、
「常に成立する法則」なのか
「特定条件で強い傾向」なのかを区別する。
#### 4. 最も意外で使える発見を選ぶ
主要なパターンに絞り、
「一番有名な特徴」ではなく、
調査前には気づきにくかった発見を中心にしてください。
特に、
「成功例は〇〇をしている」
より
「成功例と普通の事例を分けていたのは△△だった」
という比較を優先する。
#### 5. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 調査量に信頼感がある
- 発見を知りたくなる
- <ベースプロンプト>の読者に関係する
- 結論に意外性がある
ものを採用する。
### 投稿設計
1. 何を比較したか
2. 最大の発見
3. 共通パターン①
4. 共通パターン②
5. 共通パターン③
6. 反例・成立条件
7. パターンを束ねる本質
8. 読者がどう使えるか
発見が1つに集約できるなら単発〜長文で完結させてください。
複数のパターンそれぞれに具体例・反例・示唆があり、
個別に読む価値がある場合はスレッドにしてください。
スレッドでも1投稿目で
「調査対象＋最大の発見」
まで明示する。
## 深い調査から1つの結論
#### 1. テーマを「答える価値のある問い」に変える
いきなり情報収集を始めず、
{テーマ}について<ベースプロンプト>の読者の判断が変わる問いを複数考えてください。
例：
「AIエージェントの最新動向」
ではなく
「AIエージェントによって最初に価値が下がる仕事は何か？」
「ステーブルコイン市場」
ではなく
「普及のボトルネックは技術・規制・Distributionのどれなのか？」
「最新AIモデル」
ではなく
「モデル性能が上がるほど、企業の競争優位はどこへ移るのか？」
最も重要な問いを1つ選んでください。
#### 2. 広く調査する
調査メモの証拠を横断して確認する。
<today>から見て直近1年ほどの情報を優先し、
必要な場合のみ過去の重要情報まで遡ってください。
情報源の優先順位：
1. 公式発表・一次資料
2. 公式ドキュメント・GitHub・決算・統計・論文
3. 信頼できる調査機関・専門メディア
4. 当事者・専門家による発信
5. 公開されている反応・言及・体験談
SNS上の意見だけで事実を確定しないでください。
#### 3. 証拠を「数」ではなく「独立性」で見る
同じ一次情報を引用している複数の記事を、
別々の証拠として扱わないでください。
各重要情報について内部で、
- 何が事実か
- 情報源は何か
- いつの情報か
- 他の証拠から独立しているか
- 何を支持しているか
- 何と矛盾しているか
を確認する。
#### 4. 最低2つの対立仮説を作る
最初に思いついた結論へ
都合の良い情報だけ集めないでください。
例：
仮説A：
AIによってエンジニアの価値が下がる
仮説B：
AIによって高スキルエンジニアの価値はむしろ上がる
仮説C：
価値が変わるのはエンジニア自体ではなく仕事内容
のように複数の説明を作り、
それぞれを支持・反証する証拠を調べてください。
#### 5. 「最も重要な結論」を1つ選ぶ
調査結果から、
- 複数の独立した証拠で支えられる
- <ベースプロンプト>の読者の判断が変わる
- 単なる事実の要約ではない
- 少し意外だが論理的
- 一文で説明できる
結論を1つだけ選んでください。
結論を3つ、5つと並べないでください。
重要な論点が複数あっても、
それらを束ねる上位概念を探してください。
#### 6. 最も強い反証をぶつける
その結論に対して、
「この結論が間違っているとしたら？」
という視点から、
最も強い反対証拠・別解釈を探してください。
反証を踏まえても成立する範囲まで
結論を修正してください。
確信度以上に強く断定しないでください。
#### 7. 情報の90%を捨てる
調査した情報を
そのまま投稿へ入れないでください。
残すのは、
- 結論を理解するために必要
- 結論の信頼性を大きく上げる
- 読者の認識を変える
情報だけです。
「調べたから書く」は禁止です。
#### 8. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 重要な結論がすぐ分かる
- 「なぜそうなる？」と思う
- <ベースプロンプト>の読者に関係する
- 調査によって初めて見える視点がある
ものを採用する。
### 投稿設計
1. 最も重要な結論
2. なぜこの問いを調べたか
3. 最も強い証拠①
4. 最も強い証拠②
5. 最も強い証拠③
6. それらをつなぐ解釈
7. 最も強い反論・例外
8. それでも残る結論
9. <ベースプロンプト>の読者にとって何が変わるか
証拠の数は固定しないでください。
1つの論理で十分伝わるなら
長文1投稿で完結させてください。
複数種類の証拠を順番に積み上げることで
初めて結論に納得できる場合は、
スレッドを選んでください。
スレッドでも1投稿目で
最も重要な結論を隠さず提示する。
続きを読ませるために
結論を最後まで隠す構成は避けてください。
### 結論の品質基準
良い結論は、
「〇〇市場は成長している」
ではありません。
「〇〇市場の成長によって、
希少になるのはAではなくB」
のように、
既知の事実から新しい判断を導きます。
「A、B、Cが起きています」
で終わらず、
A
＋
B
＋
C
↓
だからD
まで到達してください。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 数字の解釈：期間・母数・単位・比較条件をそろえたか。割合と元の規模を見て、相関を原因へ飛躍させていないか。
- 複数事例のパターン抽出：成功例だけでなく普通・失敗の事例との差があるか。独立した事例と反例を見て、成立条件を法則から分けたか。
- 深い調査から1つの結論：同じ原典の転載を別の証拠として数えていないか。対立仮説と強い反証を検討し、それでも残る結論1つと成立条件を示したか。

# 投稿例

※以下の数値は構造を示すための例です。

## 例1：単発

売上は20%増。

これだけなら
「順調に成長した」で終わります。

でも、

売上：100 → 120
利益：10 → 20

なら見え方が変わる。

売上は1.2倍なのに、
利益は2倍。

重要なのは売上成長ではなく、

「追加の売上が以前より大きく利益として残る構造」

に変わっていることです。

事業を見るなら、
成長率だけではなく
成長した1円がどこへ行くかまで見たい。


## 例2：長文

毎日30分。

大した時間には見えません。

でも年間240営業日なら
120時間。

1日8時間働くなら、
15営業日です。

だからAIで見るべきなのは

「この作業が1回で何分速くなったか」

だけではない。

毎日発生する仕事を
何分消せるかです。

1回だけ2時間短縮するツールより、
毎日30分を削るツールの方が
年間インパクトは大きいことがある。

AIのROIは、
デモの感動より
「頻度 × 削減時間」で見ると分かりやすい。


## 例3：スレッド

1/

あるサービス。

ユーザー数が1年で10倍。

これだけでも強い数字ですが、
本当に見るべきなのはそこではありません。

同じ期間に
「1人あたり利用時間」まで伸びていたとしたら、

意味がかなり変わります。

2/

ユーザー数だけ増えている場合、

広告
キャンペーン
話題性

による一時的な流入でも説明できます。

つまり、

「試す人が増えた」

だけかもしれない。

3/

でも、

ユーザー数 ↑
利用頻度 ↑
利用時間 ↑

が同時に起きているなら、

単なる認知拡大ではなく
サービスが日常の行動に入り始めている可能性が高い。

4/

成長を見るとき、

何人が来たか
だけを見ると半分しか分からない。

何度戻ってくるか。
どれだけ深く使うか。

ユーザー数より
「利用の深さ」の方が重要な局面があります。


## 統合した切り口の例：大量に見て分かったパターン抽出

### 例1：単発

伸びているAI SaaSを見比べていて、
共通しているのは「AI性能の高さ」ではありませんでした。

むしろ目立つのは、

・用途が1文で分かる
・最初の成果までが速い
・AIを意識せず使える
・既存の仕事の流れに入っている

こと。

逆に、
「何でもできます」を売りにするサービスほど
使い方をユーザー側で考える必要がある。

AI SaaSで重要なのは
モデルの賢さだけではなく、

「ユーザーが考えることを
どれだけ減らせるか」

なのかもしれない。


### 例2：長文

伸びたX投稿と、
同じアカウントの普通の投稿を見比べると、
「テーマ」だけでは説明できないことがあります。

伸びた投稿には、

・冒頭で主張が分かる
・抽象論の直後に具体例がある
・1投稿1メッセージ
・読了後に残る一文がある

という特徴が繰り返し出てくる。

面白いのは、
文章が長いか短いかではありません。

短文でも伸びる。
長文でも伸びる。

差が出ていたのは、

「読み始めた瞬間に、
何を得られるか分かるか」

の方。

Xでは文章量より
理解までの距離を短くする方が重要そうです。


### 例3：スレッド

1/

複数の成功したSaaSと
伸びなかったサービスを比較すると、

成功例にはいくつか共通パターンがあります。

でも一番意外だったのは
「機能数」ではありませんでした。

差が大きかったのは、
最初の価値体験までの距離です。

2/

① 成功例は「登録後すぐ成果」が多い

アカウント作成
↓
大量の設定
↓
チュートリアル
↓
やっと価値

ではなく、

入力
↓
結果

までが短い。

機能が多いかより、
最初の「おお」が速い。

3/

② 用途が狭い

成功例を見ると、

「何でもできる」

より

「この仕事ならこれ」

の方が多い。

ユーザーが
使い方を考える必要が少ない。

4/

③ AIそのものを売っていない

「最新モデル搭載」

より、

「10分かかる仕事が2分になる」

の方が価値が分かりやすい。

技術を説明するより
仕事の変化を説明している。

5/

もちろん、
これだけで成功が決まるわけではありません。

Distribution、価格、市場規模など
他の要因も大きい。

ただ複数事例を比較すると、

「AIがどれだけ賢いか」

より

「価値に到達するまで
ユーザーが何回考えないといけないか」

の方が共通して差になっていました。

## 統合した切り口の例：Deep Research → 1つの重要結論

※以下は構造例です。
実際の投稿では必ず最新情報を再調査してください。


### 例1：長文

AIコーディングについて調べていて、
一番認識が変わったのはこれです。

「コードを書く速度」は、
これから競争優位になりにくくなる。

複数のAI開発ツールを見ると、

コード生成
修正
テスト
複数ファイル操作

までAIが担当する範囲が広がっている。

普通に考えると、

AIが進化
↓
開発が速くなる

で終わります。

でもその先があります。

開発が速くなる
↓
作れる会社が増える
↓
似た機能が増える
↓
コード自体の希少性が下がる

すると相対的に価値が上がるのは、

何を作るか
誰に売るか
何を捨てるか
品質をどう判断するか

の方。

AIコーディングの本当のインパクトは、
「エンジニアが速くなること」より

競争のボトルネックを
コードの外へ移すことなのかもしれません。


### 例2：長文

AIモデルを調べるほど、

「どのモデルが一番賢い？」

という問い自体が
少しずれていると思うようになりました。

ベンチマーク
価格
速度
ツール利用
長文処理
エージェント性能

を見ると、
全部で同じモデルが勝つわけではない。

さらに実務では、

モデル性能
×
成功率
×
やり直し回数
×
人間の確認時間

で最終的なコストが決まる。

だから重要なのは、

1回の推論価格

ではなく

「仕事を完了するまでの総コスト」。

AIモデル比較は
性能ランキングから

Task Economics

を見るフェーズへ移っていくと思う。


### 例3：スレッド

1/

AIエージェントについて調べると、
一番大きな変化は

「仕事が自動化されること」

ではないと思っています。

もっと大きいのは、

会社の仕事が
「人を管理する構造」から
「人＋AIを管理する構造」へ変わること。

複数の動きをつなげると、
この方向が見えてきます。

2/

まず、AIが担当できる範囲が

回答
↓
文章作成
↓
コード生成
↓
ツール操作
↓
複数ステップの実行

へ広がっている。

つまり、

「人間が作業してAIに聞く」

から

「人間が仕事を渡してAIが実行する」

へ近づいている。

3/

すると一次効果は、

人間の作業時間が減ること。

でもその次があります。

AIに仕事を任せるほど、

・何を任せるか
・どこまで権限を与えるか
・どう評価するか
・いつ人間が介入するか

を決める必要が出てくる。

4/

これはかなり
マネジメントに似ています。

AIが増えるほど、

プロンプトを書く能力

より、

仕事を分解する
完成条件を決める
結果をレビューする

能力が重要になる可能性がある。

5/

もちろん、
すべての仕事がエージェント化するとは限りません。

信頼性
コスト
セキュリティ
責任

などの制約も残る。

6/

それでも複数の動きをまとめると、

AIエージェントの本質は
「人間をなくすこと」

というより、

「マネジメントできる対象を
人間以外にも広げること」

なのかもしれない。

AIを追うなら、
モデル性能だけでなく

「AIへ仕事を渡す仕組み」

を見た方がいいと思っています。

投稿例

3週間かけて作った機能。 ほとんど使われませんでした。 作る前にユーザーへ聞いていました。 「この機能あったら使いますか？」 答えはほぼ全員、 「欲しい」。 だから作った。 でも質問が間違っていた。 本当に聞くべきだったのは、 「今、その問題をどう解決していますか？」 だった。 本当に困っているなら、 すでに時間かお金を使っていることが多い。 「欲しい」は意見。 「今やっている」は行動。 新規事業では、 言葉より行動の方が情報量が多い。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
分析対象URL：{分析対象URL}

# 今回の型の指定
「成功・失敗事例の分解」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
体験・検証・事例の経緯から、読者が再利用できる判断を取り出す。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 失敗からの学び
- 実験・検証
- 成功・失敗事例の分解
- 再起・自己開示
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 失敗からの学び
#### 1. 学びになる失敗を探す
テーマについて
- よくある失敗・遠回り
- 一見正しそうなのに失敗する行動
- 経験者が後悔していること
- 公開されている失敗事例・撤退・方向転換
- 「もっと早く知りたかった」と言われること
を探してください。
単なる不運ではなく、
<ベースプロンプト>の読者も同じ判断をしそうな失敗を優先する。
#### 2. 「本当の失敗原因」を掘る
表面的な原因で止めず、
何を信じていた？
↓
なぜそれが正しいと思った？
↓
現実は何が違った？
↓
本当の判断ミスは何だった？
まで掘ってください。
投稿の核心は、
失敗そのものより「認識が変わった瞬間」です。
#### 3. 最も強い入口を選ぶ
- 何が起きたか一瞬で分かる
- 続きを読みたくなる
- <ベースプロンプト>の読者が自分ごと化できる
- 過剰な煽りではない
### 投稿設計
1. 失敗・結果が分かる場面
2. 当時は何を正しいと思っていたか
3. 実際に何をしたか
4. 何が想定と違ったか
5. 本当の失敗原因
6. その後、何を変えたか
7. 読者が再利用できる原則
認識の変化を丁寧に描くなら長文、失敗と学びが短く伝わるなら単発。独立した学びのある複数の試行・転換点だけスレッドにし、冒頭で失敗を示す。
## 実験・検証
#### 1. 検証する価値のある問いを作る
テーマについて
- よく信じられている主張
- AとBで意見が割れていること
- 実際に試さないと分かりにくいこと
- 最近の環境変化で答えが変わった可能性があること
を探してください。
「AIは便利か？」ではなく、
「同じタスクならAとBのどちらが速く・高品質か？」
のように比較・検証できる問いにしてください。
#### 2. 検証方法を選ぶ
利用できる証拠を次の順で判断する。
1. ユーザー自身の実測データ
2. 確認済みの比較・検証の記録
3. 公式ベンチマーク・公開実験・複数の実測事例
#### 3. 条件を揃える
比較する場合は、
- 同じタスク
- 同じ入力
- 同じ期間
- 同じ評価基準
など、結果に影響する条件を可能な限り揃えてください。
テーマに応じて、
時間・費用・品質・成功率・CTR・CVRなど
最も意味のある指標を選んでください。
#### 4. 結果より先に仮説を持つ
検証前に
「普通ならAが勝つと思う」
「一般にはBが有利と言われている」
という事前仮説を整理する。
結果との差が、
投稿の面白さになります。
予想通りでも無理に意外な結論を作らず、
「どこだけ予想と違ったか」を探してください。
#### 5. 最も強いフックを選ぶ
- 結果を知りたくなる
- 比較条件が具体的
- <ベースプロンプト>の読者に関係する
- 意外性がある
### 投稿設計
1. 検証する問い＋重要な結果
2. 事前仮説
3. 検証条件・方法
4. 結果
5. 意外だった点
6. なぜそうなったか
7. 実務でどう使うか
8. 必要なら検証の限界
1つの比較は単発〜長文で完結。複数条件・複数回の検証や改善の変化に価値がある場合だけスレッドにし、冒頭で主要な結果を示す。
## 成功・失敗事例の分解
#### 1. 事例を正確に再構成する
調査メモから一次情報を優先して
- 当初の状況・目的
- 当時分かっていたこと
- 主要な意思決定
- 制約・競合・市場環境
- 結果を変えた転換点
- 最終的な結果
を時系列で整理する。
結果を知った状態から逆算して、
「当然こうすべきだった」と判断しないでください。
#### 2. 結果を分解する
「成功したのは○○のおかげ」
「失敗したのは△△のせい」
と1要因に単純化せず、
- 戦略
- プロダクト
- Distribution
- 価格
- タイミング
- 組織
- 市場環境
- 運・外部要因
などから主要因を切り分けてください。
特に、
「直接見える要因」
より
「その要因を生んだ1つ前の意思決定」
を探してください。
#### 3. 最大の転換点を特定する
複数の出来事から、
「ここで別の選択をしていたら結果が大きく変わった可能性がある」
転換点を1〜3個選んでください。
その時点で、
- どんな選択肢があったか
- なぜその判断をしたのか
- 何が起きたか
を明確にしてください。
#### 4. 別の説明でも成立しないか確認する
採用した分析について、
「本当にこの要因が重要だったのか？」
「別の要因でも結果を説明できないか？」
を検討する。
事実と推論を分け、
因果を断定できない場合は「可能性」「示唆」として扱ってください。
#### 5. 最も強いフックを選ぶ
- 結果と謎が同時に伝わる
- 「なぜ？」と思う
- <ベースプロンプト>の読者が学べる
- 事例固有の面白さがある
### 投稿設計
1. 結果＋最大の問い
2. 当時の状況
3. 最初の戦略・判断
4. 転換点
5. その判断が生んだ結果
6. 他の要因・反対仮説
7. 最も重要だった要因
8. 他の場面でも使える原則
単純な事例は長文1投稿。時系列・転換点・因果を順に追う価値がある場合はスレッドにし、冒頭で結果と問いを示す。
## 再起・自己開示
#### 1. 最も強いギャップを探す
題材と人物像から、
- 大きな失敗 → 現在の成果
- 何もなかった状態 → 獲得したもの
- 挫折 → 再起
- 周囲から見えない弱み → 表から見える現在
- 過去の自分 → 今の自分
など、最も意外性のある対比を探してください。
内部で複数のフック候補を作り、
「続きが気になる」「どうやってそこまで行ったのか知りたい」と感じるものを選んでください。
数字や具体的事実がある場合は優先して使います。
#### 2. 弱さを具体化する
「大変だった」「苦労した」のような抽象表現ではなく、
題材と人物像に合う場面から、
当時の状態が一瞬で伝わる具体的な情報を選びます。
特に、
- 失敗した回数
- 借金・売上などの数字
- 退職・倒産・不合格などの出来事
- 持っていなかったもの
- 周囲には隠していたこと
- 当時の感情や状況
が有効です。
#### 3. 公開する理由を作る
「こんな過去があります」で終わらせず、
なぜ今それを公開するのか
を必ず入れてください。
例えば、
- 同じ状況の人に勇気を与えたい
- 表面的な成功だけではなく等身大の自分を知ってほしい
- 同じ失敗をする人を減らしたい
- 挑戦する人の背中を押したい
などです。
題材と人物像から自然に導ける理由を使ってください。
#### 4. 「きれいすぎる話」にしない
必要であれば、
本人側にも利益があることを率直に書いてください。
例えば、
- 新しい事業を知ってほしい
- 認知度を上げたい
- 採用につなげたい
- 商品を知ってほしい
- フォロワーを増やしたい
などです。
社会的にきれいな理由だけを並べるより、
適度な自己利益も隠さず書くことで人間味を出します。
### 投稿設計
##### ① 強烈な過去 → 現在のギャップ
投稿冒頭1〜2行で、
人生・キャリア・事業などの大きな振れ幅を提示します。
例：
「〈過去の状態〉→〈現在の状態〉までの○年間をまとめました。」
数字や具体的事件があれば使用します。
##### ② 「持たざる状態」を圧縮
2〜4個程度の短い言葉を並べ、
当時の状況を視覚的に伝えます。
例：
経験なし、実績なし、人脈なし、資金なし
##### ③ なぜ公開するのか
弱みや過去を公開することへの葛藤と、
それでも公開する理由を書きます。
ここが共感の中心です。
##### ④ 現在・次の挑戦
過去話だけで終わらず、
「今、この人はどこへ向かっているのか」を短く入れます。
読者がプロフィールや今後の投稿を追う理由を作ってください。
##### ⑤ 本音
本人に宣伝・認知・採用などの目的があれば、
過度に取り繕わず短く開示します。
「善意100%」に見せようとしないこと。
##### ⑥ 締め
次の挑戦や本音で締めてください。参加の呼びかけは依頼に合う場合だけ自然に添え、反応を強要しないでください。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 失敗からの学び：当時の認識・実際の行動・想定との差・変えたことがつながるか。単なる不運や自虐を教訓にしていないか。
- 実験・検証：問い・条件・方法・結果・解釈を区別したか。比較条件の差や限界を落とさず、予想との差を実際の結果で示したか。
- 成功・失敗事例の分解：その時点の選択肢と判断を再構成したか。結果を1要因で説明せず、別の要因・外部環境・運でも説明できるかを検討したか。
- 再起・自己開示：過去と今の差・公開する理由・次の挑戦がつながるか。抽象的な苦労話やきれいな動機だけで埋めず、反応を強要していないか。

# 投稿例

## 例1：単発

3週間かけて作った機能。

ほとんど使われませんでした。

作る前にユーザーへ聞いていました。

「この機能あったら使いますか？」

答えはほぼ全員、
「欲しい」。

だから作った。

でも質問が間違っていた。

本当に聞くべきだったのは、

「今、その問題をどう解決していますか？」

だった。

本当に困っているなら、
すでに時間かお金を使っていることが多い。

「欲しい」は意見。

「今やっている」は行動。

新規事業では、
言葉より行動の方が情報量が多い。


## 例2：長文

AIを使い始めた頃、
1回目の回答を完璧にすることばかり考えていました。

前提条件を書く。
役割を書く。
禁止事項を書く。
例を書く。

プロンプトだけで30分。

確かに1回目の回答品質は上がった。

でもあるとき、

5分で依頼
↓
出力を見る
↓
ズレだけ修正
↓
もう一度出す

方が、完成まで速い仕事が多いと気づきました。

最適化していた指標が違った。

見ていたのは
「1回目の正答率」。

本当に見るべきだったのは
「完成までの総時間」。

AIでは、
一発で正解することより
安く速く修正できることの方が重要な場面があります。


## 例3：スレッド

1/

ある新規事業。

市場調査もした。
競合も調べた。
ユーザーにも聞いた。

それでもリリース後、
ほとんど使われませんでした。

問題は「調査不足」ではありませんでした。

調査の仕方でした。

2/

ユーザーには何度も聞いていました。

「このサービス欲しいですか？」

「使いたいですか？」

反応は良かった。

だからチームは
需要があると判断した。

3/

でもリリース後、

登録しない。
乗り換えない。
お金を払わない。

言葉と行動が一致しませんでした。

4/

ここで重要なのは、
ユーザーが嘘をついたわけではないこと。

「無料なら欲しい」

と

「今の方法を捨てて、お金を払って使う」

は別の判断です。

5/

次に見るべきだったのは、

「欲しいですか？」

ではなく、

「今どうやって解決していますか？」
「そのために何時間・いくら使っていますか？」

でした。

6/

失敗したのは、
ユーザーの声を聞いたことではない。

未来の「気持ち」を
現在の「需要」だと解釈したこと。

顧客理解では、
言葉を聞く以上に
現在の行動を見ることが重要です。


## 統合した切り口の例：実験・検証してみた

※以下は構造例です。数値は説明用の架空例です。

### 例1：単発

AIに文章を書かせるとき、

A：最初に完璧なプロンプトを書く
B：短く指示して、出力を見ながら直す

どちらが速いのか。

同じ記事作成で比べると、

A
指示作成：25分
修正：10分
合計：35分

B
初回指示：5分
修正3回：18分
合計：23分

1回目の品質はAが上。

でも完成までの時間はBが短かった。

AI活用で見るべきなのは
「一発目の正答率」だけではない。

修正まで含めた
「完成までの総コスト」です。


### 例2：長文

「AIモデルは一番賢いものを使えばいい」

本当にそうなのか、
同じ3種類の仕事で比較すると見え方が変わります。

文章要約ではA。

コード修正ではB。

画面操作ではC。

総合ベンチマーク1位が
全部の仕事で1位になるわけではない。

面白いのは、
モデルの優劣より

「仕事によって勝者が変わる」

ことです。

AI選びは、

最強モデルを1つ決める

より

タスクごとに最適モデルを決める

方が実務では合理的かもしれません。


### 例3：スレッド

1/

X投稿は
「結論から始めた方が伸びる」のか。

同じテーマで、

A：結論から開始
B：問いから開始
C：具体的な出来事から開始

を比較。

結果を見ると、
単純に「結論型が最強」とは言えませんでした。

2/

まず表示回数。

A：○○
B：○○
C：○○

一番伸びたのはC。

ただし、
これだけでは結論は出せません。

3/

プロフィール閲覧を見ると、
今度はAが最も高い。

つまり、

表示されやすい構成
と
「この人をもっと見たい」と思わせる構成

が同じとは限らない。

4/

今回の検証で一番重要だったのは、

「どの投稿が勝ったか」

ではありません。

何を成果とするかで
勝者が変わったことです。

Xの検証では、
インプレッションだけでなく

返信
共有
プロフィール閲覧
フォロー

まで分けて見た方がいい。

## 統合した切り口の例：成功失敗事例の分解・Teardown

### 例1：長文

あるSaaSが伸びた理由を
「AIの性能が高かったから」
だけで説明すると、かなり見落とします。

最初は多機能を売りにしていた。

でもユーザーが実際によく使ったのは、
たった1つの機能。

そこで、

機能を増やす
ではなく
その1機能までの導線を短くする

方向へ寄せた。

結果として変わったのは
AI性能ではなく、
最初の価値体験までの距離です。

成功要因を「技術力」と見るより、

ユーザー行動を見て
最初の仮説を捨てられたこと

と見る方が再現性が高い。


### 例2：長文

ある新規事業が撤退。

表面的には
「市場が小さかった」で終わります。

でも時系列で見ると、
もっと前に分岐点がありました。

最初から大企業向けに設計
↓
要求機能が増える
↓
開発期間が延びる
↓
検証前に固定費が大きくなる
↓
市場とのズレが分かった時には方向転換が重い

つまり問題は、
最後の売上不足だけではない。

「需要を確認する前に、
変更コストの高い事業構造を作った」

こと。

失敗は撤退時ではなく、
戻れなくなった時点から始まっていた可能性があります。


### 例3：スレッド

1/

ある後発プロダクトが
先行サービスを追い抜いた。

普通に考えると、
機能で勝ったように見えます。

でも時系列で分解すると、
勝負を変えたのは別の3つの判断でした。

2/

最初の判断。

競合より機能を増やさなかった。

代わりに、

「最初の10分で価値を感じる」

ことへ集中した。

機能数では負ける。
オンボーディングでは勝つ。

3/

次の判断。

全員を狙わなかった。

利用が特に強かった職種へ
メッセージを絞った。

市場を狭めた結果、

「これは自分向けだ」

が伝わりやすくなった。

4/

3つ目。

新機能よりDistributionへ投資した。

プロダクト差が縮まり始めた段階で、

作る
↓
届ける

へボトルネックが移ったと判断した。

5/

もちろん、
この3つだけで成功したとは言えません。

市場拡大や競合の動きなど
外部要因もある。

ただ時系列で見ると、

機能
→オンボーディング
→顧客集中
→Distribution

と、ボトルネックが変わるたびに
投資先も変えている。

6/

このケースから持ち帰りたいのは、

「正しい戦略を最初から当てること」

ではありません。

今のボトルネックが変わったときに、
過去の勝ち筋を捨てられること。

事業の強さは、
正解そのものより
正解を更新する速度に出るのかもしれません。

## 統合した切り口の例：2026最新：どん底→再起・自己開示型 X投稿生成

### 例1

3度の逮捕→少年院→数億円で会社売却した31年の人生を綴りました。

学歴なし、スキルなし、金なし、コネなし
どん底のリアルです。

隠して生きていく予定でしたが、等身大の僕を知ってほしいかつ僕のように持たざる者が少しでも勇気を持って挑戦するキッカケになれば嬉しいです。

また、次なる挑戦もスタートしました。
新規事業のために認知度を上げたいという下心も正直あります。

いいね、引用で拡散してくださると泣いて喜びます！


### 例2：個人開発者の場合の構造例

〈何度も失敗した事実〉→〈現在の成果〉までの過程を、全部まとめました。

〈当時持っていなかったもの〉
〈失敗した具体的事実〉

うまくいった部分だけ話す方が格好はつくのですが、
同じところで悩んでいる人には失敗した部分の方が役立つと思ったので公開します。

今は〈次の挑戦〉を始めています。

もちろん、これを機に〈本人に実際に存在する目的〉という本音もあります。

何か刺さった部分があれば、いいねや引用をもらえるとうれしいです。


### 例3：キャリア転換の場合の構造例

〈過去のキャリア・挫折〉→〈現在のキャリア〉。

ここに至るまでの過程を公開しました。

〈具体的な失敗〉
〈持っていなかったもの〉
〈一度諦めたこと〉

順調に見える部分だけ発信することもできますが、
これから同じ道に挑戦する人には、その裏側まで見せた方が意味があると思っています。

そして今、〈新しい挑戦〉も始めています。

〈本人に実際に存在する目的〉という打算もあります。
そこも含めて今の自分です。

応援してもらえるなら、いいね・引用していただけるとうれしいです。

投稿例

AIを使って仕事が速くなる人と、 逆に忙しくなる人。 差はAIの性能ではありません。 忙しくなる人 → 今の仕事をAIで速くする 速くなる人 → AI前提で仕事自体を組み直す 忙しくなる人 → 毎回ゼロから説明する 速くなる人 → 前提情報を再利用する 忙しくなる人 → 1回で完成させようとする 速くなる人 → 複数案を出して比較する AI活用の差って、 プロンプト力より 「仕事の設計を変えられるか」 に出る気がします。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 今回の型の指定
「ランキング・おすすめ」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
2者の行動や判断を並べ、結果を分ける境界と使い分けを見せる。

# 構成と判断
- 2者の対比、複数候補のおすすめ、保存して使う比較表を題材に合わせて選ぶ。候補が3つ以上でも同じ評価軸で比較し、順位を付けるなら基準と用途を示す。全員に同じ正解を押し付けない。
- 同じ観点で比べられ、読者の判断が変わるA/Bを選ぶ。片方を不当に愚かに描かない。
- 主要な違いを同じ順・同じ粒度で並べ、特に重要な差の理由や具体例を掘る。比較で確認できる差と、その理由の推測を分ける。材料に無いことを、実際にも無い・起きていないことへ置き換えない。
- 誰がどちらを選ぶか・何を変えるかが比較だけで伝わらなければ、用途や成立条件を添える。一覧ですでに伝えた使い分けを末尾でもう一度まとめない。人格の優劣にしない。
- 一覧性を保つ単発を基本とし、各比較軸の理由に独立した価値があるときだけスレッドにする。

# 切り口ごとの判断と点検
- ランキング・おすすめ：調査メモから候補を広く拾い、読者に重要な評価軸を決める。各候補の強み・弱み・導入条件を同じ軸で比べる。総合順位・用途別順位・条件別の選び方から適切な形を選び、無理な総合1位や根拠のない細かい点数を作らない。有名順に並べず、比較で見つかった意外な差を掘る。
- 概念・新旧・左右の比較：混同される概念、変化の大きいBefore/After、並べると初めて分かる差を選ぶ。時点・価格・数字・仕様を調査メモで確かめ、同じ項目を対応させる。概念なら使い分け、新旧なら実質の変化、左右なら比較を見るための文脈を示す。比較だけで伝わる場合は結論を足さない。
- 仕上げでは、読者が変える判断が分かるか、比較条件がそろうかを確かめる。未記載と不存在・未決定を混同せず、確認した差と理由の推測を分ける。一覧で伝わった選び方は末尾で反復しない。

# 投稿例

## 例1：単発

AIを使って仕事が速くなる人と、
逆に忙しくなる人。

差はAIの性能ではありません。

忙しくなる人
→ 今の仕事をAIで速くする

速くなる人
→ AI前提で仕事自体を組み直す

忙しくなる人
→ 毎回ゼロから説明する

速くなる人
→ 前提情報を再利用する

忙しくなる人
→ 1回で完成させようとする

速くなる人
→ 複数案を出して比較する

AI活用の差って、
プロンプト力より

「仕事の設計を変えられるか」

に出る気がします。


## 例2：長文

「つい相談したくなる人」と
「次から聞くのをやめる人」。

知識量より、質問の前後が違います。

相談したくなる人
→ まず自分で調べる

避けられる人
→ 最初から全部聞く

相談したくなる人
→ 「ここまでは分かった」と伝える

避けられる人
→ 「どうすればいいですか？」だけ

相談したくなる人
→ 教わったら試す

避けられる人
→ 「参考になりました」で終わる

相談したくなる人
→ 結果を報告する

避けられる人
→ その後何もない

差が出るのは理解力ではなく、

「相手の時間を使っている」

という感覚があるかどうか。

教えてもらうのが上手い人ほど、
教える側のコストを小さくしています。


## 例3：スレッド

1/

Xが伸びる人と伸びない人。

文章力だけを見ると
違いが分かりにくい。

でも投稿の「前後」まで見ると、
かなり差があります。

代表的な違いは5つ。

2/

① 投稿する前

伸びない人
→ 今日何を書こう？

伸びる人
→ 今回何を検証しよう？

前者は毎回作品を作る。

後者は毎回実験する。

3/

② 投稿した後

伸びない人
→ 表示回数を見る

伸びる人
→ どこが効いたか分解する

テーマ。
冒頭。
具体例。
長さ。
投稿時間。

数字を見るだけでなく、
原因の仮説を残す。

4/

③ 伸びなかったとき

伸びない人
→ 次はもっと頑張る

伸びる人
→ 1変数だけ変えてもう一度試す

ここが大きい。

投稿数が同じでも、
後者の方が学習回数は多くなる。

5/

結局、

Xが伸びる人は
「投稿をたくさん作る人」というより

「1投稿からたくさん学ぶ人」。

差を作るのは投稿量より、
学習速度なのかもしれません。


## 統合した切り口の例：ランキング・おすすめ比較

### 例1：単発

AI開発ツール、
「結局どれを使えばいい？」を整理すると、

総合1位を決めるより
用途別に分けた方が分かりやすいです。

自分でコードを見ながら高速に直す
→ A

まとまった開発タスクを任せる
→ B

軽い補完中心
→ C

初心者が最初に触る
→ D

つまり、

「どのAIが一番賢い？」

より

「どこまでAIに任せたい？」

を先に決めた方が選びやすい。

ツール選びの前に、
仕事の渡し方を決める。


### 例2：長文

新規事業の検証方法。

僕なら重要度はこう並べます。

5位
市場規模を調べる

4位
競合を調べる

3位
ユーザーへ聞く

2位
現在の行動を見る

1位
実際に買うか確認する

市場規模も競合調査も必要です。

でも、

「市場がある」

と

「この人が自分の商品にお金を払う」

は別問題。

アンケートで
「欲しい」と答えるのも簡単。

今の方法を捨てて
カードを出すのは難しい。

だから事業初期ほど、
意見より行動に近いデータを上位に置きたい。

ランキングというより、

下へ行くほど
「本当の需要」に近づくイメージです。


### 例3：スレッド

1/

AIモデル、
結局どれを使えばいいのか。

主要モデルを

・文章
・調査
・コーディング
・操作
・価格

で比較すると、
「総合最強」を決めるのはかなり雑でした。

先に結論。

文章 → A
調査 → B
コード → C
操作 → D
コスパ → E

用途ごとに勝者が違います。

2/

文章ならA。

理由は単純なベンチマークではなく、
実際の長文生成で

構成
自然さ
指示追従

のバランスが良い。

ただし、
大量生成なら価格面で別候補が強くなる。

3/

コーディングならC。

特に、

複数ファイル
修正
テスト
再実行

まで含む仕事で差が出る。

単発コード生成だけを見ると、
順位はまた変わります。

4/

つまりAIモデル選びで
一番避けたいのは、

「総合ランキング1位だから全部これ」

という選び方。

モデル性能が用途ごとに分かれるほど、

最強の1モデル

より

仕事ごとの最適モデル

を持つ方が合理的です。

## 統合した切り口の例：2026最新：二項対比・保存版構文 X投稿生成

### 投稿例1

Google Antigravityを使いこなす上で、絶対に避けて通れないのが「スキル」と「ワークフロー」の使い分け。

ここを間違えると、AIのポテンシャルを半分も引き出せない。
エンジニア目線で、これ以上のないくらい分かりやすくまとめたよ。

ざっくり言うとこんな感じ。

・スキル（Skills）：AIの「専門知識」。自律的に動く。
・ワークフロー（Workflows）：AIの「手順書」。人間が指示して動かす。

理想的なのは「ワークフローで全体の骨組みを作り、スキルで中身の品質を担保する」という組み合わせ。
これができると、複雑なデプロイも新機能の開発も、ミスなく爆速でおわる。

「あれ、どっちだっけ？」ってなった時にすぐ確認できるよう、今のうちに保存しておいてね。


### 投稿例2

ケンタッキーが「とりの日パック」をリニューアルして3か月が経ちました。
■以前■
価格：1100円 内容：「オリジナルチキン」5ピース
※単品積上げ価格1550円より450円お得
↓↓
■現在■
価格：1250円 内容：「オリジナルチキン」4ピース、「ナゲット5ピース」
※単品積上げ価格1720円より470円お得


### 投稿例3

今、流行ってます。
この形式も海外輸入の典型例。

日本語の運営者に怒られそう
「英語のチャンネル見つけるなよ！」って笑

←英語🇺🇸　🇯🇵日本→

投稿例

AIに市場調査をさせるなら、 いきなり「市場調査して」はおすすめしません。 この3段階に分けます。 ① 論点を作る 「〇〇市場への参入を検討しています。 調査すべき論点を整理してください。 まだ調査は始めないでください。」 ② 論点を人間が確認 不要なものを消す。 足りないものを足す。 ③ 調査させる 「上記論点を調査してください。 最新情報を優先。 数字は一次情報を優先。 事実と推論を分けてください。」 設計 ↓ 調査 を分けるだけで、 AIが見当違いな方向へ走る確率をかなり下げられます。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 今回の型の指定
「やめること・NG」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
手順・診断・やめる行動・成果に至る工程を、読者が自分で実行・点検できる形にする。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 具体的な手順
- 自己診断・チェックリスト
- やめることと代替行動
- 成果と工程の公開
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 具体的な手順
#### 1. 最新かつ正確な方法を調査する
調査メモから
現在もっとも有効な方法を確認する。
操作・仕様・料金・コマンドなど変化する情報は、
公式ドキュメントや一次情報を優先する。
あわせて、
- 初心者がつまずく場所
- 不要になった古い手順
- 実務で使われている近道
- よくある失敗
も確認する。
#### 2. 「完成状態」を先に決める
投稿を読み終えた読者が
何をできるようになるかを具体化する。
悪い例：
「Claude Codeの使い方が分かる」
良い例：
「Claude Codeを導入し、最初の開発タスクを1つ完了できる」
ゴールに不要な説明は削ってください。
#### 3. 最短の手順にする
必要な工程を、
何をする
↓
具体的にどうする
↓
何が起きれば成功か
の順に整理する。
テーマに応じて、
- コピペできるプロンプト
- コマンド
- 設定値
- テンプレート
- 具体例
をそのまま使える形で提示する。
#### 4. つまずきを先回りする
特に失敗しやすい箇所だけ、
「うまくいかない場合は〇〇を確認」
のように補足する。
すべての例外を説明して
本筋を重くしないでください。
#### 5. 最も強いフックを選ぶ
- 何ができるようになるか明確
- <ベースプロンプト>の読者に関係する
- 難しそうなことが実行可能に見える
- 後で使いたくなる
### 投稿設計
1. 何ができるようになるか
2. 必要なもの・前提
3. STEP 1
4. STEP 2
5. STEP 3…
6. よくあるつまずき
7. 最初に試す具体例
8. 次にやること
## 自己診断・チェックリスト
#### 1. 診断したくなる切り口を探す
テーマから
- なりたい状態
- 避けたい状態
- 成果を出す人の共通行動
- 本人が気づきにくい癖
を探してください。
「仕事ができる人」のような広すぎるテーマより、
「AIを使うほど仕事が速くなる人」
「Xが伸び始める人」
のように、<ベースプロンプト>の読者が自分を判定したくなる切り口を優先する。
#### 2. 本当に特徴的なものだけ残す
候補を複数考え、
- 行動として観察できる
- 自分でYES / NOを判断できる
- 成果とのつながりを説明できる
- 他項目と重複しない
- 一部に「そこも？」という意外性がある
ものを残してください。
「努力家」「ポジティブ」「行動力がある」など、
誰にでも当てはまりやすい抽象的特徴は避けてください。
#### 3. 一覧性と意外性を両立する
題材と分量に合う項目数で、
水増しせず最適な数を選んでください。
序盤には「確かに」と納得できる特徴、
途中には「そこは意識していなかった」と思う特徴を混ぜてください。
最後に、複数の特徴を生んでいる
「共通する本質」を一文で見つけてください。
#### 4. 最も強いフックを選ぶ
- 自分に当てはまるか確認したくなる
- 誰についての投稿か一瞬で分かる
- 意外性がある
- 続きを読みたくなる
### 投稿設計
1. 診断テーマを提示
2. 具体的な特徴を一覧化
3. 特に重要・意外な特徴を少し掘る
4. 特徴を束ねる本質を一文で残す
としてください。
## やめることと代替行動
#### 1. 本当にやめる価値のある行動を探す
テーマについて、
- 初心者がやりがちな失敗
- 昔は有効だったが今は非効率な方法
- 良かれと思ってやるほど逆効果になる行動
- 経験者が避けている行動
- 時間・お金・機会を無駄にする習慣
を探してください。
単なるマナー論ではなく、
やめることで結果が変わるものを優先する。
#### 2. 「NG → なぜ → 代わりに」をセットにする
各項目は、
NG：
何をやめる？
理由：
なぜ問題なのか？
代替：
代わりに何をする？
まで考えてください。
「〇〇はやめた方がいい」だけで終わらせないでください。
#### 3. 意外なアンチパターンを優先する
明らかな失敗より、
「むしろ良いことだと思われているが、やりすぎると逆効果」
な行動を優先する。
例：
毎日投稿する
→ 振り返らず投稿数だけ増やすのはNG
長いプロンプトを書く
→ 毎回一発で正解を出そうとするのはNG
顧客の声を聞く
→ 「欲しいですか？」だけ聞くのはNG
#### 4. 項目を絞る
候補を複数調査し、
- <ベースプロンプト>の読者が実際にやりそう
- 損失・非効率が大きい
- 理由を説明できる
- 代替行動がある
- 他項目と重複しない
ものだけ残してください。
項目数は固定せず、
最も価値の高いものだけを使ってください。
#### 5. 最も強いフックを選ぶ
- 「自分もやっているかも」と思う
- 何を避けるべきか知りたくなる
- <ベースプロンプト>の読者に関係する
- 過剰な恐怖煽りではない
### 投稿設計
1. 避けたい結果・問題
2. NG行動を一覧化
3. 各NGがなぜ問題か
4. 代わりに取る行動
5. 特に重要な1つを少し深掘り
6. 「結局、何をやめるべきか」を一文で締める
## 成果と工程の公開
#### 1. テーマから「見せる成果」を決める
<ベースプロンプト>の読者が思わず続きを読みたくなる、
- できるようになったこと
- 大幅に楽になったこと
- 複数工程をまとめられたこと
- 意外な使い方
- 従来より速い・簡単・便利になったこと
などを特定する。
最新ツール・サービス・ニュース・仕様・性能比較など、
情報の鮮度が重要なテーマではまず調査メモを確認する。
根拠のない性能比較や数字は作らないでください。
#### 2. フックを作る
内部で複数のフック候補を作り、
最も続きを読みたくなるものを1つ選んでください。
冒頭1〜3行で、
「何を使って、何ができたのか」
ができるだけ具体的に分かるようにします。
可能なら、
- 固有名詞
- 成果
- 意外性
- 比較
- 効率化
- 驚き
のうち2つ以上を組み合わせてください。
抽象的な
「AIがすごい」
「便利な方法を紹介します」
のような始め方は避けてください。
#### 3. 工程を具体的に並べる
成果に至る流れを、
原則3〜7ステップ程度に分解する。
①
②
③
のように、視覚的に追いやすくします。
各ステップでは、
「ツール名 + 実際に行う操作」
が分かる程度まで具体化する。
ただし説明しすぎず、
一目で全体のワークフローが理解できる長さにしてください。
#### 4. 成果と労力のギャップを作る
工程を見せた後、
「一見複雑な成果に対して、
実際に人間がやることは非常に少ない」
というギャップがある場合は強調する。
例：
- 最初に指示するだけ
- 1つの操作だけ
- 条件を設定するだけ
- あとは自動で処理される
ただし、実際には必要な作業を省略して
過度に簡単そうに見せてはいけません。
#### 5. 続きのポストに続きを置く
追加情報がある場合は、
メイン投稿ですべて説明しきらず、
最も価値のある補足を、指定された本数の範囲で続きのポストへ展開する。
例えば、
- 詳しい設定方法
- 使用したプロンプト
- トークン・コスト削減方法
- 注意点
- 別の応用方法
- 実際の構成
- 比較結果
などです。
続きを読む理由がない場合は、
無理にスレッド化しないでください。
### 投稿設計
具体的な成果→必要な工程→成果と労力のギャップ。補足に独立した価値がある場合だけ、指定本数内で設定・プロンプト・費用・注意点・応用・比較結果を続ける。
# 分量と展開
一覧で作業・自己点検できるなら単発〜長文を優先する。各工程・特徴・NGに独立した理由・具体例・トラブル対処がある場合だけスレッドにし、1投稿目へ完成形と全体手順・主要な特徴・NG一覧を置く。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 具体的な手順：各工程で何をし、何が起きれば成功かが分かるか。完成形と最初に試す例があり、失敗しやすい箇所の確認方法まで示したか。
- 自己診断・チェックリスト：自分で当てはまるか判定でき、各項目が重複していないか。抽象的な性格ではなく行動で診断できるか。
- やめることと代替行動：NG・問題になる理由・代わりの行動がそろうか。読者が実際にしそうで、やめると結果が変わるものに絞ったか。
- 成果と工程の公開：何を使って何ができたかと、実際に必要な操作が分かるか。成果を大きく見せるために人の作業や前提を省いていないか。

# 投稿例

## 例1：単発

AIに市場調査をさせるなら、
いきなり「市場調査して」はおすすめしません。

この3段階に分けます。

① 論点を作る

「〇〇市場への参入を検討しています。
調査すべき論点を整理してください。
まだ調査は始めないでください。」

② 論点を人間が確認

不要なものを消す。
足りないものを足す。

③ 調査させる

「上記論点を調査してください。
最新情報を優先。
数字は一次情報を優先。
事実と推論を分けてください。」

設計
↓
調査

を分けるだけで、
AIが見当違いな方向へ走る確率をかなり下げられます。


## 例2：長文

AIで記事を書くとき、
最初から「記事を書いて」と頼まない方がいい。

僕ならこの順番です。

STEP1
Web調査

まず事実だけ集める。

STEP2
面白い事実を選ぶ

「読者の認識が変わるものだけ残して」
と依頼。

STEP3
読者の疑問を作る

「このテーマについて、
初心者が知りたい質問を20個出して」

STEP4
構成を3案作る

まだ本文は書かせない。

STEP5
一番面白い構成を選んで本文を書く。

特に重要なのはSTEP3。

AIは情報を集めるのは得意です。

でも
「読者が知りたいこと」
を外すと全部つまらなくなる。

文章を書く前に、
読者の問いを作る。

ここを挟むだけでかなり変わります。


## 例3：スレッド

1/

AIでWebサービスを作ってみたい初心者向け。

最初からコードを勉強し直さなくても、
まずここまでなら進められます。

全体は4STEPです。

① 作りたいものを文章にする
② AIに仕様書を作らせる
③ 開発環境を準備
④ 1機能ずつ実装

順番に説明します。

2/

STEP1：作りたいものを文章にする

最初から完璧な仕様書はいりません。

まずAIに、

「〇〇するWebサービスを作りたい。
ユーザー、主要機能、画面、必要データを整理してください。」

と渡す。

曖昧なアイデアを
一度構造化します。

3/

STEP2：仕様書にする

次に、

「初心者がAIコーディングで実装できる粒度に分解してください。
MVPに不要な機能は削ってください。」

と依頼。

ここで重要なのは
機能を増やすことではなく減らすことです。

4/

STEP3：開発環境を準備

使用するツールは、
必ず最新の公式手順を確認して導入。

ここでエラーが出たら、
エラーメッセージをそのままAIへ渡す。

要約して渡すより、
原文の方が原因を特定しやすい場合があります。

5/

STEP4：1機能ずつ作る

「サービス全部を作って」

ではなく、

ログイン
↓
入力
↓
保存
↓
表示

のように分ける。

AI開発で最初に覚えたいのは
コードより、

「大きな仕事を小さく渡すこと」です。


## 統合した切り口の例：「○○な人の特徴」自己診断

### 例1：単発

AIを使うほど仕事が速くなる人の特徴。

・毎回ゼロから説明しない
・1回で正解を出そうとしない
・過去の良い成果物をAIに見せる
・大きな仕事を小さく分ける
・最初に完成条件を決める
・同じ作業を2回やったら自動化を考える
・浮いた時間でもう1案試す

特に最後。

AIで30分浮いたとき、
その30分でもう1案試せる人は
作業時間だけでなく試行回数まで変わる。

AI活用が上手い人って、
プロンプトより
「浮いた時間の使い方」が上手い。


### 例2：長文

仕事が速い人を見ていると、
「手を動かす速度」以外の共通点が多い。

・依頼された瞬間に作業を始めない
・完成条件を先に確認する
・やらなくていい仕事を消す
・60点で一度見せる
・迷ったら早めに聞く
・同じ説明を二度しない仕組みを作る
・重要でない部分はちゃんと雑にやる

速い人って、
全部を高速で処理しているわけじゃない。

むしろ、

「速くやらなくていい仕事」
「そもそもやらなくていい仕事」

を見分けるのが上手い。


### 例3：スレッド

1/

Xが伸び始める人の特徴。

・投稿後の数字を分解する
・テーマとフックを別々に考える
・他人の投稿を文章ではなく構造で見る
・伸びなかった投稿も分析する
・毎回1つだけ仮説を変える

共通しているのは、
「投稿を作品として扱っていない」ことです。

2/

例えば伸びなかったとき。

「今回ダメだった」

で終わるのではなく、

テーマ？
冒頭？
具体例？
長さ？
投稿時間？

と分解する。

失敗した投稿も、
次の投稿を改善するデータになります。

3/

つまりXが伸びる人は、

投稿数が多い人というより
1投稿あたりの学習量が多い人。

X運用を
「文章を書くゲーム」ではなく
「仮説検証」に変えている人ほど強いと思います。

## 統合した切り口の例：やめること・NG・アンチパターン集

### 例1：単発

AIを使っているのに
仕事があまり速くならない人。

まずこの3つをやめたい。

① 毎回ゼロから説明する
→ 前提情報は再利用する

② 1回で完璧な回答を出そうとする
→ まず出して、ズレだけ直す

③ 何でもAIに任せる
→ 人間が判断すべき場所を先に決める

AI活用で大事なのは、
プロンプトを増やすことより

「毎回やらなくていいこと」

を増やすことだと思う。


### 例2：長文

Xが伸びないとき、
投稿数を増やす前にやめたいこと。

・伸びなかったらすぐ次を書く
・表示回数だけを見る
・毎回テーマも構成も全部変える
・「アルゴリズムが悪い」で終わる
・伸びた投稿を「たまたま」で済ませる

これを続けると、
100投稿しても学習がほとんど残らない。

代わりに、

テーマ
冒頭
構成
具体例
長さ

のどこを変えたか残す。

投稿数を増やすより、
1投稿から取れるデータを増やす。

Xでやめたいのは
「失敗すること」ではなく、

失敗から何も取らずに
次へ進むことです。


### 例3：スレッド

1/

AI開発初心者が
最初にやめたいことをまとめます。

① いきなり全部作らせる
② エラーを要約して渡す
③ AIのコードを確認せず実行
④ 大きな変更を一発で任せる
⑤ 動いたら終わりにする

特に危ないのは①です。

2/

①「サービス全部作って」

これをやると、
AIが一度に判断することが多すぎる。

代わりに、

ログイン
↓
入力
↓
保存
↓
表示

のように機能単位で渡す。

小さく作るほど、
どこで壊れたかも分かりやすい。

3/

② エラーを自分で要約する

初心者ほど、

「たぶんデータベースのエラーです」

のように解釈して渡しがち。

代わりに、
まずエラーメッセージ原文を渡す。

自分の推測を入れる前の情報の方が
AIが原因を特定しやすいことがあります。

4/

⑤「動いたから完成」

AI生成コードでは、
動くことと安全・保守可能であることは別。

最低でも、

テスト
エラー処理
権限
不要コード

は確認する。

5/

AI開発で避けたいのは、
AIを使うことではありません。

「AIが出したものを
理解しないまま大きくしていくこと」。

速く作れるほど、
小さく確認する習慣の価値が上がります。

## 統合した切り口の例：2026最新：成果実況・手順公開型

### 投稿例1

📝よし！Google AntigravityからNotebookLMを操作できたぞ！便利！しかもGemini 3.5だからCodexやClaude Codeより断然早い！

①Google AntigravityでNotebookLM操作のSkillsを呼び出し
②「本日分をお願い」と依頼
③Manusで調査済みの日刊AI系ニュースまとめファイルを取得
④ソースとしてNotebookLMに投げる
⑤別途用意済みのインフォグラフィック用プロンプトを投げつつ、NotebookLM上でインフォグラフィックを作成
⑥NotebookLMでソース情報を元に、Spotify用の音声を作成

完了！私はSkillsを呼び出して「本日分をお願い」と一言依頼しただけでここまで自動化できる

詳細は続きへ ↓

スレッド1
NotebookLMでトークン消費を劇的に抑えてDeep Researchをする方法　↓


### 投稿例2

📝競合調査→比較→資料の叩き台まで、AIにバラバラに頼む必要はない。

1本のワークフローにするとこうなる。

①調査したい市場を指定
②主要プレイヤーを洗い出す
③公式サイト・一次情報を収集
④比較軸ごとに整理
⑤重要な差分だけ抽出
⑥そのまま資料構成まで作る

人間が毎回やるのは「今回知りたいこと」を決める部分。

調査そのものより、
調査→整理→アウトプットまでつなげる方がAIは一気に使いやすくなる。

具体的な指示の作り方は続きへ ↓


### 投稿例3

📝毎日のSNS運用、投稿文を書くところだけAI化してもあまり楽にならない。

本当に減らしたいのは、その前後の作業。

①投稿ネタを収集
②使えそうな情報を選別
③自分のテーマに合わせて切り口を決定
④投稿案を生成
⑤公開候補をストック
⑥投稿後の反応を次回に反映

ここまでを1つの流れにしておけば、
毎回ゼロから「今日は何を書こう？」と考える必要がなくなる。

ポイントは文章生成ではなく、
投稿が生まれる仕組みそのものを作ること。

具体的な設計は続きへ ↓

投稿例

忙しいことより、 「全部ちょっとずつ自分の責任」 なのが一番疲れる。 1つ1つは大した仕事じゃない。 でも頭の片隅に 「忘れちゃいけない」が20個ある。 忙しさって、 労働時間だけでは測れない。 脳内に残っている 未完了の数でも決まる。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 今回の型の指定
「ユーモア・あるある」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
身近な場面の本音やおかしさを言葉にし、読者が自分の経験を重ねられる投稿にする。

# 切り口の選択
今回の題材と依頼に合う切り口を次から1つ選び、その切り口の作成手順と投稿設計だけを使ってください。選ばなかった切り口の流れや結論を混ぜないでください。
- 本音の言語化
- ユーモア・あるある

# 作成手順・投稿設計

## 本音の言語化

### 作成手順

#### 1. まだ言語化されていない本音を探す

<ベースプロンプト>の読者の一日を思い浮かべ、

- 繰り返しこぼしていそうな不満・違和感
- 表向きの常識と現場の実感のズレ
- 人前では言わないが、同業者どうしなら言う本音
- 経験者ほど感じるが言葉になっていないこと
- 最近の環境変化で生まれた新しいストレス

を挙げてください。

「多くの人が経験している」
かつ
「まだ使い古された表現になっていない」
ものを優先してください。

#### 2. 表面的な感情を一段深くする

本音候補について、

「本当に嫌なのは何？」
「なぜそれが疲れる？」
「その感情の正体は何？」

と掘ってください。

例：

「会議が多くてつらい」
↓
「会議より、話しても何も決まらないことがつらい」
↓
「本当の問題は時間ではなく、意思決定者が曖昧なこと」

最後の一段を投稿の核心にしてください。

#### 3. 最も刺さる入口を選ぶ

冒頭候補を内部で複数作り、

- 「自分の話だ」と瞬時に感じる
- 具体的な場面が浮かぶ
- 言語化に新しさがある
- 続きを読みたくなる

ものを採用してください。

### 投稿設計

基本は、

1. 本音・違和感を一撃で言語化
2. 読者が経験したことのある具体的な場面
3. 一般的な理解とのズレ
4. なぜそう感じるのか
5. 感情の正体・構造を一段深く言語化
6. 余韻の残る一文で締める

としてください。

原則は単発〜長文で、
1つの本音を鋭く伝えてください。

ただし、複数の異なる場面を順番に見せることで
「全部同じ本音につながっていた」と気づかせる方が強い場合は
スレッドを選んでください。

## ユーモア・あるある

### 作成手順

#### 1. <ベースプロンプト>の読者だけが分かる「あるある」を探す

<ベースプロンプト>の読者が実際によく経験している

- 小さな失敗
- 面倒な瞬間
- 矛盾
- 建前と本音のズレ
- 無意識にやってしまう行動
- 業界特有の習慣
- 最近増えた新しい現象

を挙げてください。

「会社員は月曜日が嫌い」のような
広すぎるあるあるではなく、

経験者ほど
「そこを切り取るのか」
と思う具体的な場面を優先してください。

#### 2. 「誰かに送りたくなるか」で選ぶ

候補ごとに、

「これを見たとき、
<ベースプロンプト>の読者の頭に特定の友人・同僚・職種が浮かぶか？」

を確認してください。

単に面白いものより、

「これ完全に〇〇さん」

と送りたくなるものを優先してください。

#### 3. 笑いに変換する

あるあるをそのまま言うのではなく、
以下から最も自然な笑いの構造を選んでください。

- 逆転
  普通の解釈と結果を逆にする

- 誇張
  小さな現象を大事件のように扱う

- 比喩
  全く別のものとして言い換える

- 本音化
  建前の裏にある本音をそのまま言う

- 定義化
  日常の現象に妙に正確な名前をつける

- Before → After
  理想と現実を並べる

- セリフ化
  頭の中の声や会話にする

- 期待 → 裏切り
  読者が予想した着地点を少しだけ外す

- 過剰に論理的
  くだらない出来事を真面目に分析する

最も説明なしで伝わるものを選んでください。

#### 4. 一番短く伝わる形まで削る

ユーモアは説明すると弱くなります。

内部では複数案を作り、

- すぐ意味が分かる
- 「あるある」が具体的
- オチを説明していない
- 一度読んで理解できる
- 声に出したとき自然
- スクリーンショットして共有できる

ものを採用してください。

面白さが増えない文は削ってください。

#### 5. ミームやネットスラングは、確信があるものだけ使う

既存のミーム・構文・ネットスラングは、
いま使われていると確信できるものだけ使ってください。

確信が無ければ使わず、
逆転・定義化などの構造だけで作ってください。

流行している型を使う場合も、
元投稿をコピーせず、
構造だけを参考にして完全にオリジナルの内容を作ってください。

### 投稿設計

この型は原則として
単発投稿を優先してください。

基本形：

具体的な状況
↓
<ベースプロンプト>の読者が認識
↓
少し予想させる
↓
最後の一言でズラす

または、

強いあるある
↓
予想外の比喩・定義

だけでも構いません。

文章量は固定せず、
オチが最も強くなる長さを選んでください。

長く説明するほど面白さが増える場合を除き、
不要な背景説明は入れないでください。

スレッドは原則使いません。

ただし同じテーマで
独立して成立する複数の「あるある」を連作として見せること自体に価値がある場合のみ使用してください。

### ユーモアの品質基準

良い投稿は、

「面白い」

だけではなく、

「分かる」
＋
「この表現は思いつかなかった」

が同時にあります。

特に、

普通の出来事
＋
少し異常に正確な表現

を狙ってください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 本音の言語化：具体的な場面から感情の正体へ届いたか。表面の愚痴を言い換えるだけで終わっていないか。
- ユーモア・あるある：「分かる」と「この表現は思いつかなかった」が両立するか。一度で理解でき、声に出して自然か。オチの後に教訓や笑いの説明を足していないか。

# 投稿例

## 例1：短文

忙しいことより、

「全部ちょっとずつ自分の責任」

なのが一番疲れる。

1つ1つは大した仕事じゃない。

でも頭の片隅に
「忘れちゃいけない」が20個ある。

忙しさって、
労働時間だけでは測れない。

脳内に残っている
未完了の数でも決まる。


## 例2：長文

AIで仕事が楽になるはずなのに、
前より疲れている人もいると思う。

文章を書く。
調べる。
整理する。

作業自体は確実に速くなった。

でも代わりに、

ChatGPTかClaudeか。
この仕事はAIに任せていいか。
この回答を信じていいか。
新しいツールを試すべきか。

をずっと判断している。

AIで減ったのは「作業」。

増えたのは「選択」。

AI時代の疲労って、
仕事量だけではなく

「決め続けること」

から来る部分もかなりありそう。


## 例3：スレッド

1/

マネージャーになって大変なのは、
仕事量が増えることだと思っていました。

少し違いました。

一番疲れるのは、

「自分の仕事ではないのに、
最後は自分が気にしないといけないこと」

が増えることでした。

2/

メンバーのタスク。

顧客への返信。

別部署との調整。

来月の計画。

今日決めなくてもいい。

でも忘れると困る。

だから全部、
頭のどこかで起動したままになる。

3/

プレイヤー時代は、

仕事を終わらせれば
頭から消せました。

マネージャーになると、

「終わらせる仕事」

より

「忘れない仕事」

が増える。

4/

管理職の疲れって、
単純な仕事量ではなく

「自分が覚えておく必要のある未来」

の多さなのかもしれない。


## 統合した切り口の例：ユーモア・あるある・ミーム化

### 例1：日常逆転

AIで資料作成が10倍速くなった。

その結果、

資料を10倍作るようになった。


### 例2：業界あるある＋定義化

「一度社内で確認します」

BtoB営業における
最も実装期間の長いAPI。


### 例3：期待→裏切り

AIエージェントに仕事を全部任せる未来を想像していた。

現実：

AIエージェント5人の
進捗確認ミーティングをしている。

投稿例

※以下の数値は構造を示すための例です。

売上は20%増。 これだけなら 「順調に成長した」で終わります。 でも、 売上：100 → 120 利益：10 → 20 なら見え方が変わる。 売上は1.2倍なのに、 利益は2倍。 重要なのは売上成長ではなく、 「追加の売上が以前より大きく利益として残る構造」 に変わっていることです。 事業を見るなら、 成長率だけではなく 成長した1円がどこへ行くかまで見たい。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 今回の型の指定
「深い調査から1つの結論」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
数字や事例、証拠のつながりから、読者の判断が変わる発見を取り出す。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 数字の解釈
- 複数事例のパターン抽出
- 深い調査から1つの結論
# 作成手順・投稿設計
## 数字の解釈
#### 1. 強いデータを探す
調査メモからテーマに関する最新データを集めてください。
公式統計、決算、一次資料、論文、公式ベンチマークなどを優先し、
- 成長率
- 売上・利益
- 利用者数・利用時間
- 市場シェア
- 費用・時間
- 導入率
- 過去との変化
- 競合との差
などを広く確認する。
数字は必ず、期間・母数・比較条件・元データまで確認する。
#### 2. 「驚き」ではなく「認識が変わる数字」を選ぶ
候補から、
- 想像より大きい / 小さい
- 過去や競合と比べると異常
- 相対値と絶対値で印象が変わる
- 別の数字と組み合わせると新しい意味が見える
- <ベースプロンプト>の読者の判断・行動が変わる
ものを選んでください。
「100%増」のような数字は、
元の規模が小さくないかも必ず確認する。
#### 3. 数字を人間が理解できる形に変換する
必要に応じて、
- 前年・数年前との比較
- 競合・業界平均との比較
- 1日 / 1人 / 1件あたり
- Before → After
- 絶対値と割合の両方
で示してください。
比較することで意味が薄くなる場合は、無理に例えを作らないでください。
#### 4. 「つまり」を一段深くする
以下を考えてください。
① 数字上、何が起きている？
② 一般的にはどう解釈される？
③ 実は何を示している？
④ その結果、<ベースプロンプト>の読者に何が変わる？
投稿の中心は③〜④です。
数字を紹介して終わらせず、
「この数字によって何の見方を変えるべきか」まで示してください。
#### 5. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 数字＋比較だけで驚きが伝わる
- 一瞬で理解できる
- <ベースプロンプト>の読者に関係する
- 解釈の続きを知りたくなる
ものを採用する。
### 投稿設計
1. 最も強い数字＋比較
2. なぜその数字が異常なのか
3. 一般的な解釈
4. 一段深い解釈
5. <ベースプロンプト>の読者への影響
6. 一文で結論
1つの数字と比較だけで洞察が成立するなら、
原則は単発〜長文で完結させてください。
一方で、
- 複数の独立したデータが同じ方向を示している
- 時系列で変化を追う必要がある
- データA→B→Cを組み合わせて初めて結論が見える
場合はスレッドを選んでください。
スレッドでも1投稿目で
「最重要データ＋今回の解釈」
まで示してください。
## 複数事例のパターン抽出
#### 1. 比較するサンプルを集める
調査メモからテーマに関する十分な数の事例を集めてください。
可能なら、
- 成功・高反応事例
- 平均的な事例
- うまくいかなかった事例
を比較する。
有名な成功例だけを集めて
「共通点＝成功要因」と判断しないでください。
投稿を分析する場合は、
アカウント規模だけで伸びた事例を避けるため、
可能ならその投稿者の通常投稿との相対差も確認する。
#### 2. 先入観を持たずに特徴を分解する
各事例を、テーマに応じて
- 最初の行動・戦略
- 判断基準
- 順番
- 数字
- 共通する制約
- やっていること
- やっていないこと
- X投稿ならフック・構成・具体性・形式
などに分解する。
最初から「これが成功要因だ」と決めず、
データから繰り返し現れる特徴を探してください。
#### 3. 本当に強いパターンだけ残す
候補について、
- 複数の独立した事例で確認できる
- 成功例だけでなく比較対象との差がある
- 当たり前すぎない
- <ベースプロンプト>の読者が再現できる
- なぜ効くのか説明できる
ものを残してください。
反例も探し、
「常に成立する法則」なのか
「特定条件で強い傾向」なのかを区別する。
#### 4. 最も意外で使える発見を選ぶ
主要なパターンに絞り、
「一番有名な特徴」ではなく、
調査前には気づきにくかった発見を中心にしてください。
特に、
「成功例は〇〇をしている」
より
「成功例と普通の事例を分けていたのは△△だった」
という比較を優先する。
#### 5. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 調査量に信頼感がある
- 発見を知りたくなる
- <ベースプロンプト>の読者に関係する
- 結論に意外性がある
ものを採用する。
### 投稿設計
1. 何を比較したか
2. 最大の発見
3. 共通パターン①
4. 共通パターン②
5. 共通パターン③
6. 反例・成立条件
7. パターンを束ねる本質
8. 読者がどう使えるか
発見が1つに集約できるなら単発〜長文で完結させてください。
複数のパターンそれぞれに具体例・反例・示唆があり、
個別に読む価値がある場合はスレッドにしてください。
スレッドでも1投稿目で
「調査対象＋最大の発見」
まで明示する。
## 深い調査から1つの結論
#### 1. テーマを「答える価値のある問い」に変える
いきなり情報収集を始めず、
{テーマ}について<ベースプロンプト>の読者の判断が変わる問いを複数考えてください。
例：
「AIエージェントの最新動向」
ではなく
「AIエージェントによって最初に価値が下がる仕事は何か？」
「ステーブルコイン市場」
ではなく
「普及のボトルネックは技術・規制・Distributionのどれなのか？」
「最新AIモデル」
ではなく
「モデル性能が上がるほど、企業の競争優位はどこへ移るのか？」
最も重要な問いを1つ選んでください。
#### 2. 広く調査する
調査メモの証拠を横断して確認する。
<today>から見て直近1年ほどの情報を優先し、
必要な場合のみ過去の重要情報まで遡ってください。
情報源の優先順位：
1. 公式発表・一次資料
2. 公式ドキュメント・GitHub・決算・統計・論文
3. 信頼できる調査機関・専門メディア
4. 当事者・専門家による発信
5. 公開されている反応・言及・体験談
SNS上の意見だけで事実を確定しないでください。
#### 3. 証拠を「数」ではなく「独立性」で見る
同じ一次情報を引用している複数の記事を、
別々の証拠として扱わないでください。
各重要情報について内部で、
- 何が事実か
- 情報源は何か
- いつの情報か
- 他の証拠から独立しているか
- 何を支持しているか
- 何と矛盾しているか
を確認する。
#### 4. 最低2つの対立仮説を作る
最初に思いついた結論へ
都合の良い情報だけ集めないでください。
例：
仮説A：
AIによってエンジニアの価値が下がる
仮説B：
AIによって高スキルエンジニアの価値はむしろ上がる
仮説C：
価値が変わるのはエンジニア自体ではなく仕事内容
のように複数の説明を作り、
それぞれを支持・反証する証拠を調べてください。
#### 5. 「最も重要な結論」を1つ選ぶ
調査結果から、
- 複数の独立した証拠で支えられる
- <ベースプロンプト>の読者の判断が変わる
- 単なる事実の要約ではない
- 少し意外だが論理的
- 一文で説明できる
結論を1つだけ選んでください。
結論を3つ、5つと並べないでください。
重要な論点が複数あっても、
それらを束ねる上位概念を探してください。
#### 6. 最も強い反証をぶつける
その結論に対して、
「この結論が間違っているとしたら？」
という視点から、
最も強い反対証拠・別解釈を探してください。
反証を踏まえても成立する範囲まで
結論を修正してください。
確信度以上に強く断定しないでください。
#### 7. 情報の90%を捨てる
調査した情報を
そのまま投稿へ入れないでください。
残すのは、
- 結論を理解するために必要
- 結論の信頼性を大きく上げる
- 読者の認識を変える
情報だけです。
「調べたから書く」は禁止です。
#### 8. 最も強いフックを選ぶ
冒頭候補を内部で複数作り、
- 重要な結論がすぐ分かる
- 「なぜそうなる？」と思う
- <ベースプロンプト>の読者に関係する
- 調査によって初めて見える視点がある
ものを採用する。
### 投稿設計
1. 最も重要な結論
2. なぜこの問いを調べたか
3. 最も強い証拠①
4. 最も強い証拠②
5. 最も強い証拠③
6. それらをつなぐ解釈
7. 最も強い反論・例外
8. それでも残る結論
9. <ベースプロンプト>の読者にとって何が変わるか
証拠の数は固定しないでください。
1つの論理で十分伝わるなら
長文1投稿で完結させてください。
複数種類の証拠を順番に積み上げることで
初めて結論に納得できる場合は、
スレッドを選んでください。
スレッドでも1投稿目で
最も重要な結論を隠さず提示する。
続きを読ませるために
結論を最後まで隠す構成は避けてください。
### 結論の品質基準
良い結論は、
「〇〇市場は成長している」
ではありません。
「〇〇市場の成長によって、
希少になるのはAではなくB」
のように、
既知の事実から新しい判断を導きます。
「A、B、Cが起きています」
で終わらず、
A
＋
B
＋
C
↓
だからD
まで到達してください。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 数字の解釈：期間・母数・単位・比較条件をそろえたか。割合と元の規模を見て、相関を原因へ飛躍させていないか。
- 複数事例のパターン抽出：成功例だけでなく普通・失敗の事例との差があるか。独立した事例と反例を見て、成立条件を法則から分けたか。
- 深い調査から1つの結論：同じ原典の転載を別の証拠として数えていないか。対立仮説と強い反証を検討し、それでも残る結論1つと成立条件を示したか。

# 投稿例

※以下の数値は構造を示すための例です。

## 例1：単発

売上は20%増。

これだけなら
「順調に成長した」で終わります。

でも、

売上：100 → 120
利益：10 → 20

なら見え方が変わる。

売上は1.2倍なのに、
利益は2倍。

重要なのは売上成長ではなく、

「追加の売上が以前より大きく利益として残る構造」

に変わっていることです。

事業を見るなら、
成長率だけではなく
成長した1円がどこへ行くかまで見たい。


## 例2：長文

毎日30分。

大した時間には見えません。

でも年間240営業日なら
120時間。

1日8時間働くなら、
15営業日です。

だからAIで見るべきなのは

「この作業が1回で何分速くなったか」

だけではない。

毎日発生する仕事を
何分消せるかです。

1回だけ2時間短縮するツールより、
毎日30分を削るツールの方が
年間インパクトは大きいことがある。

AIのROIは、
デモの感動より
「頻度 × 削減時間」で見ると分かりやすい。


## 例3：スレッド

1/

あるサービス。

ユーザー数が1年で10倍。

これだけでも強い数字ですが、
本当に見るべきなのはそこではありません。

同じ期間に
「1人あたり利用時間」まで伸びていたとしたら、

意味がかなり変わります。

2/

ユーザー数だけ増えている場合、

広告
キャンペーン
話題性

による一時的な流入でも説明できます。

つまり、

「試す人が増えた」

だけかもしれない。

3/

でも、

ユーザー数 ↑
利用頻度 ↑
利用時間 ↑

が同時に起きているなら、

単なる認知拡大ではなく
サービスが日常の行動に入り始めている可能性が高い。

4/

成長を見るとき、

何人が来たか
だけを見ると半分しか分からない。

何度戻ってくるか。
どれだけ深く使うか。

ユーザー数より
「利用の深さ」の方が重要な局面があります。


## 統合した切り口の例：大量に見て分かったパターン抽出

### 例1：単発

伸びているAI SaaSを見比べていて、
共通しているのは「AI性能の高さ」ではありませんでした。

むしろ目立つのは、

・用途が1文で分かる
・最初の成果までが速い
・AIを意識せず使える
・既存の仕事の流れに入っている

こと。

逆に、
「何でもできます」を売りにするサービスほど
使い方をユーザー側で考える必要がある。

AI SaaSで重要なのは
モデルの賢さだけではなく、

「ユーザーが考えることを
どれだけ減らせるか」

なのかもしれない。


### 例2：長文

伸びたX投稿と、
同じアカウントの普通の投稿を見比べると、
「テーマ」だけでは説明できないことがあります。

伸びた投稿には、

・冒頭で主張が分かる
・抽象論の直後に具体例がある
・1投稿1メッセージ
・読了後に残る一文がある

という特徴が繰り返し出てくる。

面白いのは、
文章が長いか短いかではありません。

短文でも伸びる。
長文でも伸びる。

差が出ていたのは、

「読み始めた瞬間に、
何を得られるか分かるか」

の方。

Xでは文章量より
理解までの距離を短くする方が重要そうです。


### 例3：スレッド

1/

複数の成功したSaaSと
伸びなかったサービスを比較すると、

成功例にはいくつか共通パターンがあります。

でも一番意外だったのは
「機能数」ではありませんでした。

差が大きかったのは、
最初の価値体験までの距離です。

2/

① 成功例は「登録後すぐ成果」が多い

アカウント作成
↓
大量の設定
↓
チュートリアル
↓
やっと価値

ではなく、

入力
↓
結果

までが短い。

機能が多いかより、
最初の「おお」が速い。

3/

② 用途が狭い

成功例を見ると、

「何でもできる」

より

「この仕事ならこれ」

の方が多い。

ユーザーが
使い方を考える必要が少ない。

4/

③ AIそのものを売っていない

「最新モデル搭載」

より、

「10分かかる仕事が2分になる」

の方が価値が分かりやすい。

技術を説明するより
仕事の変化を説明している。

5/

もちろん、
これだけで成功が決まるわけではありません。

Distribution、価格、市場規模など
他の要因も大きい。

ただ複数事例を比較すると、

「AIがどれだけ賢いか」

より

「価値に到達するまで
ユーザーが何回考えないといけないか」

の方が共通して差になっていました。

## 統合した切り口の例：Deep Research → 1つの重要結論

※以下は構造例です。
実際の投稿では必ず最新情報を再調査してください。


### 例1：長文

AIコーディングについて調べていて、
一番認識が変わったのはこれです。

「コードを書く速度」は、
これから競争優位になりにくくなる。

複数のAI開発ツールを見ると、

コード生成
修正
テスト
複数ファイル操作

までAIが担当する範囲が広がっている。

普通に考えると、

AIが進化
↓
開発が速くなる

で終わります。

でもその先があります。

開発が速くなる
↓
作れる会社が増える
↓
似た機能が増える
↓
コード自体の希少性が下がる

すると相対的に価値が上がるのは、

何を作るか
誰に売るか
何を捨てるか
品質をどう判断するか

の方。

AIコーディングの本当のインパクトは、
「エンジニアが速くなること」より

競争のボトルネックを
コードの外へ移すことなのかもしれません。


### 例2：長文

AIモデルを調べるほど、

「どのモデルが一番賢い？」

という問い自体が
少しずれていると思うようになりました。

ベンチマーク
価格
速度
ツール利用
長文処理
エージェント性能

を見ると、
全部で同じモデルが勝つわけではない。

さらに実務では、

モデル性能
×
成功率
×
やり直し回数
×
人間の確認時間

で最終的なコストが決まる。

だから重要なのは、

1回の推論価格

ではなく

「仕事を完了するまでの総コスト」。

AIモデル比較は
性能ランキングから

Task Economics

を見るフェーズへ移っていくと思う。


### 例3：スレッド

1/

AIエージェントについて調べると、
一番大きな変化は

「仕事が自動化されること」

ではないと思っています。

もっと大きいのは、

会社の仕事が
「人を管理する構造」から
「人＋AIを管理する構造」へ変わること。

複数の動きをつなげると、
この方向が見えてきます。

2/

まず、AIが担当できる範囲が

回答
↓
文章作成
↓
コード生成
↓
ツール操作
↓
複数ステップの実行

へ広がっている。

つまり、

「人間が作業してAIに聞く」

から

「人間が仕事を渡してAIが実行する」

へ近づいている。

3/

すると一次効果は、

人間の作業時間が減ること。

でもその次があります。

AIに仕事を任せるほど、

・何を任せるか
・どこまで権限を与えるか
・どう評価するか
・いつ人間が介入するか

を決める必要が出てくる。

4/

これはかなり
マネジメントに似ています。

AIが増えるほど、

プロンプトを書く能力

より、

仕事を分解する
完成条件を決める
結果をレビューする

能力が重要になる可能性がある。

5/

もちろん、
すべての仕事がエージェント化するとは限りません。

信頼性
コスト
セキュリティ
責任

などの制約も残る。

6/

それでも複数の動きをまとめると、

AIエージェントの本質は
「人間をなくすこと」

というより、

「マネジメントできる対象を
人間以外にも広げること」

なのかもしれない。

AIを追うなら、
モデル性能だけでなく

「AIへ仕事を渡す仕組み」

を見た方がいいと思っています。

投稿例

AIに市場調査をさせるなら、 いきなり「市場調査して」はおすすめしません。 この3段階に分けます。 ① 論点を作る 「〇〇市場への参入を検討しています。 調査すべき論点を整理してください。 まだ調査は始めないでください。」 ② 論点を人間が確認 不要なものを消す。 足りないものを足す。 ③ 調査させる 「上記論点を調査してください。 最新情報を優先。 数字は一次情報を優先。 事実と推論を分けてください。」 設計 ↓ 調査 を分けるだけで、 AIが見当違いな方向へ走る確率をかなり下げられます。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
# 今回の型の指定
「成果までの手順公開」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
手順・診断・やめる行動・成果に至る工程を、読者が自分で実行・点検できる形にする。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 具体的な手順
- 自己診断・チェックリスト
- やめることと代替行動
- 成果と工程の公開
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 具体的な手順
#### 1. 最新かつ正確な方法を調査する
調査メモから
現在もっとも有効な方法を確認する。
操作・仕様・料金・コマンドなど変化する情報は、
公式ドキュメントや一次情報を優先する。
あわせて、
- 初心者がつまずく場所
- 不要になった古い手順
- 実務で使われている近道
- よくある失敗
も確認する。
#### 2. 「完成状態」を先に決める
投稿を読み終えた読者が
何をできるようになるかを具体化する。
悪い例：
「Claude Codeの使い方が分かる」
良い例：
「Claude Codeを導入し、最初の開発タスクを1つ完了できる」
ゴールに不要な説明は削ってください。
#### 3. 最短の手順にする
必要な工程を、
何をする
↓
具体的にどうする
↓
何が起きれば成功か
の順に整理する。
テーマに応じて、
- コピペできるプロンプト
- コマンド
- 設定値
- テンプレート
- 具体例
をそのまま使える形で提示する。
#### 4. つまずきを先回りする
特に失敗しやすい箇所だけ、
「うまくいかない場合は〇〇を確認」
のように補足する。
すべての例外を説明して
本筋を重くしないでください。
#### 5. 最も強いフックを選ぶ
- 何ができるようになるか明確
- <ベースプロンプト>の読者に関係する
- 難しそうなことが実行可能に見える
- 後で使いたくなる
### 投稿設計
1. 何ができるようになるか
2. 必要なもの・前提
3. STEP 1
4. STEP 2
5. STEP 3…
6. よくあるつまずき
7. 最初に試す具体例
8. 次にやること
## 自己診断・チェックリスト
#### 1. 診断したくなる切り口を探す
テーマから
- なりたい状態
- 避けたい状態
- 成果を出す人の共通行動
- 本人が気づきにくい癖
を探してください。
「仕事ができる人」のような広すぎるテーマより、
「AIを使うほど仕事が速くなる人」
「Xが伸び始める人」
のように、<ベースプロンプト>の読者が自分を判定したくなる切り口を優先する。
#### 2. 本当に特徴的なものだけ残す
候補を複数考え、
- 行動として観察できる
- 自分でYES / NOを判断できる
- 成果とのつながりを説明できる
- 他項目と重複しない
- 一部に「そこも？」という意外性がある
ものを残してください。
「努力家」「ポジティブ」「行動力がある」など、
誰にでも当てはまりやすい抽象的特徴は避けてください。
#### 3. 一覧性と意外性を両立する
題材と分量に合う項目数で、
水増しせず最適な数を選んでください。
序盤には「確かに」と納得できる特徴、
途中には「そこは意識していなかった」と思う特徴を混ぜてください。
最後に、複数の特徴を生んでいる
「共通する本質」を一文で見つけてください。
#### 4. 最も強いフックを選ぶ
- 自分に当てはまるか確認したくなる
- 誰についての投稿か一瞬で分かる
- 意外性がある
- 続きを読みたくなる
### 投稿設計
1. 診断テーマを提示
2. 具体的な特徴を一覧化
3. 特に重要・意外な特徴を少し掘る
4. 特徴を束ねる本質を一文で残す
としてください。
## やめることと代替行動
#### 1. 本当にやめる価値のある行動を探す
テーマについて、
- 初心者がやりがちな失敗
- 昔は有効だったが今は非効率な方法
- 良かれと思ってやるほど逆効果になる行動
- 経験者が避けている行動
- 時間・お金・機会を無駄にする習慣
を探してください。
単なるマナー論ではなく、
やめることで結果が変わるものを優先する。
#### 2. 「NG → なぜ → 代わりに」をセットにする
各項目は、
NG：
何をやめる？
理由：
なぜ問題なのか？
代替：
代わりに何をする？
まで考えてください。
「〇〇はやめた方がいい」だけで終わらせないでください。
#### 3. 意外なアンチパターンを優先する
明らかな失敗より、
「むしろ良いことだと思われているが、やりすぎると逆効果」
な行動を優先する。
例：
毎日投稿する
→ 振り返らず投稿数だけ増やすのはNG
長いプロンプトを書く
→ 毎回一発で正解を出そうとするのはNG
顧客の声を聞く
→ 「欲しいですか？」だけ聞くのはNG
#### 4. 項目を絞る
候補を複数調査し、
- <ベースプロンプト>の読者が実際にやりそう
- 損失・非効率が大きい
- 理由を説明できる
- 代替行動がある
- 他項目と重複しない
ものだけ残してください。
項目数は固定せず、
最も価値の高いものだけを使ってください。
#### 5. 最も強いフックを選ぶ
- 「自分もやっているかも」と思う
- 何を避けるべきか知りたくなる
- <ベースプロンプト>の読者に関係する
- 過剰な恐怖煽りではない
### 投稿設計
1. 避けたい結果・問題
2. NG行動を一覧化
3. 各NGがなぜ問題か
4. 代わりに取る行動
5. 特に重要な1つを少し深掘り
6. 「結局、何をやめるべきか」を一文で締める
## 成果と工程の公開
#### 1. テーマから「見せる成果」を決める
<ベースプロンプト>の読者が思わず続きを読みたくなる、
- できるようになったこと
- 大幅に楽になったこと
- 複数工程をまとめられたこと
- 意外な使い方
- 従来より速い・簡単・便利になったこと
などを特定する。
最新ツール・サービス・ニュース・仕様・性能比較など、
情報の鮮度が重要なテーマではまず調査メモを確認する。
根拠のない性能比較や数字は作らないでください。
#### 2. フックを作る
内部で複数のフック候補を作り、
最も続きを読みたくなるものを1つ選んでください。
冒頭1〜3行で、
「何を使って、何ができたのか」
ができるだけ具体的に分かるようにします。
可能なら、
- 固有名詞
- 成果
- 意外性
- 比較
- 効率化
- 驚き
のうち2つ以上を組み合わせてください。
抽象的な
「AIがすごい」
「便利な方法を紹介します」
のような始め方は避けてください。
#### 3. 工程を具体的に並べる
成果に至る流れを、
原則3〜7ステップ程度に分解する。
①
②
③
のように、視覚的に追いやすくします。
各ステップでは、
「ツール名 + 実際に行う操作」
が分かる程度まで具体化する。
ただし説明しすぎず、
一目で全体のワークフローが理解できる長さにしてください。
#### 4. 成果と労力のギャップを作る
工程を見せた後、
「一見複雑な成果に対して、
実際に人間がやることは非常に少ない」
というギャップがある場合は強調する。
例：
- 最初に指示するだけ
- 1つの操作だけ
- 条件を設定するだけ
- あとは自動で処理される
ただし、実際には必要な作業を省略して
過度に簡単そうに見せてはいけません。
#### 5. 続きのポストに続きを置く
追加情報がある場合は、
メイン投稿ですべて説明しきらず、
最も価値のある補足を、指定された本数の範囲で続きのポストへ展開する。
例えば、
- 詳しい設定方法
- 使用したプロンプト
- トークン・コスト削減方法
- 注意点
- 別の応用方法
- 実際の構成
- 比較結果
などです。
続きを読む理由がない場合は、
無理にスレッド化しないでください。
### 投稿設計
具体的な成果→必要な工程→成果と労力のギャップ。補足に独立した価値がある場合だけ、指定本数内で設定・プロンプト・費用・注意点・応用・比較結果を続ける。
# 分量と展開
一覧で作業・自己点検できるなら単発〜長文を優先する。各工程・特徴・NGに独立した理由・具体例・トラブル対処がある場合だけスレッドにし、1投稿目へ完成形と全体手順・主要な特徴・NG一覧を置く。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 具体的な手順：各工程で何をし、何が起きれば成功かが分かるか。完成形と最初に試す例があり、失敗しやすい箇所の確認方法まで示したか。
- 自己診断・チェックリスト：自分で当てはまるか判定でき、各項目が重複していないか。抽象的な性格ではなく行動で診断できるか。
- やめることと代替行動：NG・問題になる理由・代わりの行動がそろうか。読者が実際にしそうで、やめると結果が変わるものに絞ったか。
- 成果と工程の公開：何を使って何ができたかと、実際に必要な操作が分かるか。成果を大きく見せるために人の作業や前提を省いていないか。

# 投稿例

## 例1：単発

AIに市場調査をさせるなら、
いきなり「市場調査して」はおすすめしません。

この3段階に分けます。

① 論点を作る

「〇〇市場への参入を検討しています。
調査すべき論点を整理してください。
まだ調査は始めないでください。」

② 論点を人間が確認

不要なものを消す。
足りないものを足す。

③ 調査させる

「上記論点を調査してください。
最新情報を優先。
数字は一次情報を優先。
事実と推論を分けてください。」

設計
↓
調査

を分けるだけで、
AIが見当違いな方向へ走る確率をかなり下げられます。


## 例2：長文

AIで記事を書くとき、
最初から「記事を書いて」と頼まない方がいい。

僕ならこの順番です。

STEP1
Web調査

まず事実だけ集める。

STEP2
面白い事実を選ぶ

「読者の認識が変わるものだけ残して」
と依頼。

STEP3
読者の疑問を作る

「このテーマについて、
初心者が知りたい質問を20個出して」

STEP4
構成を3案作る

まだ本文は書かせない。

STEP5
一番面白い構成を選んで本文を書く。

特に重要なのはSTEP3。

AIは情報を集めるのは得意です。

でも
「読者が知りたいこと」
を外すと全部つまらなくなる。

文章を書く前に、
読者の問いを作る。

ここを挟むだけでかなり変わります。


## 例3：スレッド

1/

AIでWebサービスを作ってみたい初心者向け。

最初からコードを勉強し直さなくても、
まずここまでなら進められます。

全体は4STEPです。

① 作りたいものを文章にする
② AIに仕様書を作らせる
③ 開発環境を準備
④ 1機能ずつ実装

順番に説明します。

2/

STEP1：作りたいものを文章にする

最初から完璧な仕様書はいりません。

まずAIに、

「〇〇するWebサービスを作りたい。
ユーザー、主要機能、画面、必要データを整理してください。」

と渡す。

曖昧なアイデアを
一度構造化します。

3/

STEP2：仕様書にする

次に、

「初心者がAIコーディングで実装できる粒度に分解してください。
MVPに不要な機能は削ってください。」

と依頼。

ここで重要なのは
機能を増やすことではなく減らすことです。

4/

STEP3：開発環境を準備

使用するツールは、
必ず最新の公式手順を確認して導入。

ここでエラーが出たら、
エラーメッセージをそのままAIへ渡す。

要約して渡すより、
原文の方が原因を特定しやすい場合があります。

5/

STEP4：1機能ずつ作る

「サービス全部を作って」

ではなく、

ログイン
↓
入力
↓
保存
↓
表示

のように分ける。

AI開発で最初に覚えたいのは
コードより、

「大きな仕事を小さく渡すこと」です。


## 統合した切り口の例：「○○な人の特徴」自己診断

### 例1：単発

AIを使うほど仕事が速くなる人の特徴。

・毎回ゼロから説明しない
・1回で正解を出そうとしない
・過去の良い成果物をAIに見せる
・大きな仕事を小さく分ける
・最初に完成条件を決める
・同じ作業を2回やったら自動化を考える
・浮いた時間でもう1案試す

特に最後。

AIで30分浮いたとき、
その30分でもう1案試せる人は
作業時間だけでなく試行回数まで変わる。

AI活用が上手い人って、
プロンプトより
「浮いた時間の使い方」が上手い。


### 例2：長文

仕事が速い人を見ていると、
「手を動かす速度」以外の共通点が多い。

・依頼された瞬間に作業を始めない
・完成条件を先に確認する
・やらなくていい仕事を消す
・60点で一度見せる
・迷ったら早めに聞く
・同じ説明を二度しない仕組みを作る
・重要でない部分はちゃんと雑にやる

速い人って、
全部を高速で処理しているわけじゃない。

むしろ、

「速くやらなくていい仕事」
「そもそもやらなくていい仕事」

を見分けるのが上手い。


### 例3：スレッド

1/

Xが伸び始める人の特徴。

・投稿後の数字を分解する
・テーマとフックを別々に考える
・他人の投稿を文章ではなく構造で見る
・伸びなかった投稿も分析する
・毎回1つだけ仮説を変える

共通しているのは、
「投稿を作品として扱っていない」ことです。

2/

例えば伸びなかったとき。

「今回ダメだった」

で終わるのではなく、

テーマ？
冒頭？
具体例？
長さ？
投稿時間？

と分解する。

失敗した投稿も、
次の投稿を改善するデータになります。

3/

つまりXが伸びる人は、

投稿数が多い人というより
1投稿あたりの学習量が多い人。

X運用を
「文章を書くゲーム」ではなく
「仮説検証」に変えている人ほど強いと思います。

## 統合した切り口の例：やめること・NG・アンチパターン集

### 例1：単発

AIを使っているのに
仕事があまり速くならない人。

まずこの3つをやめたい。

① 毎回ゼロから説明する
→ 前提情報は再利用する

② 1回で完璧な回答を出そうとする
→ まず出して、ズレだけ直す

③ 何でもAIに任せる
→ 人間が判断すべき場所を先に決める

AI活用で大事なのは、
プロンプトを増やすことより

「毎回やらなくていいこと」

を増やすことだと思う。


### 例2：長文

Xが伸びないとき、
投稿数を増やす前にやめたいこと。

・伸びなかったらすぐ次を書く
・表示回数だけを見る
・毎回テーマも構成も全部変える
・「アルゴリズムが悪い」で終わる
・伸びた投稿を「たまたま」で済ませる

これを続けると、
100投稿しても学習がほとんど残らない。

代わりに、

テーマ
冒頭
構成
具体例
長さ

のどこを変えたか残す。

投稿数を増やすより、
1投稿から取れるデータを増やす。

Xでやめたいのは
「失敗すること」ではなく、

失敗から何も取らずに
次へ進むことです。


### 例3：スレッド

1/

AI開発初心者が
最初にやめたいことをまとめます。

① いきなり全部作らせる
② エラーを要約して渡す
③ AIのコードを確認せず実行
④ 大きな変更を一発で任せる
⑤ 動いたら終わりにする

特に危ないのは①です。

2/

①「サービス全部作って」

これをやると、
AIが一度に判断することが多すぎる。

代わりに、

ログイン
↓
入力
↓
保存
↓
表示

のように機能単位で渡す。

小さく作るほど、
どこで壊れたかも分かりやすい。

3/

② エラーを自分で要約する

初心者ほど、

「たぶんデータベースのエラーです」

のように解釈して渡しがち。

代わりに、
まずエラーメッセージ原文を渡す。

自分の推測を入れる前の情報の方が
AIが原因を特定しやすいことがあります。

4/

⑤「動いたから完成」

AI生成コードでは、
動くことと安全・保守可能であることは別。

最低でも、

テスト
エラー処理
権限
不要コード

は確認する。

5/

AI開発で避けたいのは、
AIを使うことではありません。

「AIが出したものを
理解しないまま大きくしていくこと」。

速く作れるほど、
小さく確認する習慣の価値が上がります。

## 統合した切り口の例：2026最新：成果実況・手順公開型

### 投稿例1

📝よし！Google AntigravityからNotebookLMを操作できたぞ！便利！しかもGemini 3.5だからCodexやClaude Codeより断然早い！

①Google AntigravityでNotebookLM操作のSkillsを呼び出し
②「本日分をお願い」と依頼
③Manusで調査済みの日刊AI系ニュースまとめファイルを取得
④ソースとしてNotebookLMに投げる
⑤別途用意済みのインフォグラフィック用プロンプトを投げつつ、NotebookLM上でインフォグラフィックを作成
⑥NotebookLMでソース情報を元に、Spotify用の音声を作成

完了！私はSkillsを呼び出して「本日分をお願い」と一言依頼しただけでここまで自動化できる

詳細は続きへ ↓

スレッド1
NotebookLMでトークン消費を劇的に抑えてDeep Researchをする方法　↓


### 投稿例2

📝競合調査→比較→資料の叩き台まで、AIにバラバラに頼む必要はない。

1本のワークフローにするとこうなる。

①調査したい市場を指定
②主要プレイヤーを洗い出す
③公式サイト・一次情報を収集
④比較軸ごとに整理
⑤重要な差分だけ抽出
⑥そのまま資料構成まで作る

人間が毎回やるのは「今回知りたいこと」を決める部分。

調査そのものより、
調査→整理→アウトプットまでつなげる方がAIは一気に使いやすくなる。

具体的な指示の作り方は続きへ ↓


### 投稿例3

📝毎日のSNS運用、投稿文を書くところだけAI化してもあまり楽にならない。

本当に減らしたいのは、その前後の作業。

①投稿ネタを収集
②使えそうな情報を選別
③自分のテーマに合わせて切り口を決定
④投稿案を生成
⑤公開候補をストック
⑥投稿後の反応を次回に反映

ここまでを1つの流れにしておけば、
毎回ゼロから「今日は何を書こう？」と考える必要がなくなる。

ポイントは文章生成ではなく、
投稿が生まれる仕組みそのものを作ること。

具体的な設計は続きへ ↓

投稿例

AIを使って仕事が速くなる人と、 逆に忙しくなる人。 差はAIの性能ではありません。 忙しくなる人 → 今の仕事をAIで速くする 速くなる人 → AI前提で仕事自体を組み直す 忙しくなる人 → 毎回ゼロから説明する 速くなる人 → 前提情報を再利用する 忙しくなる人 → 1回で完成させようとする 速くなる人 → 複数案を出して比較する AI活用の差って、 プロンプト力より 「仕事の設計を変えられるか」 に出る気がします。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}

# 今回の型の指定
「概念・新旧・左右の比較」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
2者の行動や判断を並べ、結果を分ける境界と使い分けを見せる。

# 構成と判断
- 2者の対比、複数候補のおすすめ、保存して使う比較表を題材に合わせて選ぶ。候補が3つ以上でも同じ評価軸で比較し、順位を付けるなら基準と用途を示す。全員に同じ正解を押し付けない。
- 同じ観点で比べられ、読者の判断が変わるA/Bを選ぶ。片方を不当に愚かに描かない。
- 主要な違いを同じ順・同じ粒度で並べ、特に重要な差の理由や具体例を掘る。比較で確認できる差と、その理由の推測を分ける。材料に無いことを、実際にも無い・起きていないことへ置き換えない。
- 誰がどちらを選ぶか・何を変えるかが比較だけで伝わらなければ、用途や成立条件を添える。一覧ですでに伝えた使い分けを末尾でもう一度まとめない。人格の優劣にしない。
- 一覧性を保つ単発を基本とし、各比較軸の理由に独立した価値があるときだけスレッドにする。

# 切り口ごとの判断と点検
- ランキング・おすすめ：調査メモから候補を広く拾い、読者に重要な評価軸を決める。各候補の強み・弱み・導入条件を同じ軸で比べる。総合順位・用途別順位・条件別の選び方から適切な形を選び、無理な総合1位や根拠のない細かい点数を作らない。有名順に並べず、比較で見つかった意外な差を掘る。
- 概念・新旧・左右の比較：混同される概念、変化の大きいBefore/After、並べると初めて分かる差を選ぶ。時点・価格・数字・仕様を調査メモで確かめ、同じ項目を対応させる。概念なら使い分け、新旧なら実質の変化、左右なら比較を見るための文脈を示す。比較だけで伝わる場合は結論を足さない。
- 仕上げでは、読者が変える判断が分かるか、比較条件がそろうかを確かめる。未記載と不存在・未決定を混同せず、確認した差と理由の推測を分ける。一覧で伝わった選び方は末尾で反復しない。

# 投稿例

## 例1：単発

AIを使って仕事が速くなる人と、
逆に忙しくなる人。

差はAIの性能ではありません。

忙しくなる人
→ 今の仕事をAIで速くする

速くなる人
→ AI前提で仕事自体を組み直す

忙しくなる人
→ 毎回ゼロから説明する

速くなる人
→ 前提情報を再利用する

忙しくなる人
→ 1回で完成させようとする

速くなる人
→ 複数案を出して比較する

AI活用の差って、
プロンプト力より

「仕事の設計を変えられるか」

に出る気がします。


## 例2：長文

「つい相談したくなる人」と
「次から聞くのをやめる人」。

知識量より、質問の前後が違います。

相談したくなる人
→ まず自分で調べる

避けられる人
→ 最初から全部聞く

相談したくなる人
→ 「ここまでは分かった」と伝える

避けられる人
→ 「どうすればいいですか？」だけ

相談したくなる人
→ 教わったら試す

避けられる人
→ 「参考になりました」で終わる

相談したくなる人
→ 結果を報告する

避けられる人
→ その後何もない

差が出るのは理解力ではなく、

「相手の時間を使っている」

という感覚があるかどうか。

教えてもらうのが上手い人ほど、
教える側のコストを小さくしています。


## 例3：スレッド

1/

Xが伸びる人と伸びない人。

文章力だけを見ると
違いが分かりにくい。

でも投稿の「前後」まで見ると、
かなり差があります。

代表的な違いは5つ。

2/

① 投稿する前

伸びない人
→ 今日何を書こう？

伸びる人
→ 今回何を検証しよう？

前者は毎回作品を作る。

後者は毎回実験する。

3/

② 投稿した後

伸びない人
→ 表示回数を見る

伸びる人
→ どこが効いたか分解する

テーマ。
冒頭。
具体例。
長さ。
投稿時間。

数字を見るだけでなく、
原因の仮説を残す。

4/

③ 伸びなかったとき

伸びない人
→ 次はもっと頑張る

伸びる人
→ 1変数だけ変えてもう一度試す

ここが大きい。

投稿数が同じでも、
後者の方が学習回数は多くなる。

5/

結局、

Xが伸びる人は
「投稿をたくさん作る人」というより

「1投稿からたくさん学ぶ人」。

差を作るのは投稿量より、
学習速度なのかもしれません。


## 統合した切り口の例：ランキング・おすすめ比較

### 例1：単発

AI開発ツール、
「結局どれを使えばいい？」を整理すると、

総合1位を決めるより
用途別に分けた方が分かりやすいです。

自分でコードを見ながら高速に直す
→ A

まとまった開発タスクを任せる
→ B

軽い補完中心
→ C

初心者が最初に触る
→ D

つまり、

「どのAIが一番賢い？」

より

「どこまでAIに任せたい？」

を先に決めた方が選びやすい。

ツール選びの前に、
仕事の渡し方を決める。


### 例2：長文

新規事業の検証方法。

僕なら重要度はこう並べます。

5位
市場規模を調べる

4位
競合を調べる

3位
ユーザーへ聞く

2位
現在の行動を見る

1位
実際に買うか確認する

市場規模も競合調査も必要です。

でも、

「市場がある」

と

「この人が自分の商品にお金を払う」

は別問題。

アンケートで
「欲しい」と答えるのも簡単。

今の方法を捨てて
カードを出すのは難しい。

だから事業初期ほど、
意見より行動に近いデータを上位に置きたい。

ランキングというより、

下へ行くほど
「本当の需要」に近づくイメージです。


### 例3：スレッド

1/

AIモデル、
結局どれを使えばいいのか。

主要モデルを

・文章
・調査
・コーディング
・操作
・価格

で比較すると、
「総合最強」を決めるのはかなり雑でした。

先に結論。

文章 → A
調査 → B
コード → C
操作 → D
コスパ → E

用途ごとに勝者が違います。

2/

文章ならA。

理由は単純なベンチマークではなく、
実際の長文生成で

構成
自然さ
指示追従

のバランスが良い。

ただし、
大量生成なら価格面で別候補が強くなる。

3/

コーディングならC。

特に、

複数ファイル
修正
テスト
再実行

まで含む仕事で差が出る。

単発コード生成だけを見ると、
順位はまた変わります。

4/

つまりAIモデル選びで
一番避けたいのは、

「総合ランキング1位だから全部これ」

という選び方。

モデル性能が用途ごとに分かれるほど、

最強の1モデル

より

仕事ごとの最適モデル

を持つ方が合理的です。

## 統合した切り口の例：2026最新：二項対比・保存版構文 X投稿生成

### 投稿例1

Google Antigravityを使いこなす上で、絶対に避けて通れないのが「スキル」と「ワークフロー」の使い分け。

ここを間違えると、AIのポテンシャルを半分も引き出せない。
エンジニア目線で、これ以上のないくらい分かりやすくまとめたよ。

ざっくり言うとこんな感じ。

・スキル（Skills）：AIの「専門知識」。自律的に動く。
・ワークフロー（Workflows）：AIの「手順書」。人間が指示して動かす。

理想的なのは「ワークフローで全体の骨組みを作り、スキルで中身の品質を担保する」という組み合わせ。
これができると、複雑なデプロイも新機能の開発も、ミスなく爆速でおわる。

「あれ、どっちだっけ？」ってなった時にすぐ確認できるよう、今のうちに保存しておいてね。


### 投稿例2

ケンタッキーが「とりの日パック」をリニューアルして3か月が経ちました。
■以前■
価格：1100円 内容：「オリジナルチキン」5ピース
※単品積上げ価格1550円より450円お得
↓↓
■現在■
価格：1250円 内容：「オリジナルチキン」4ピース、「ナゲット5ピース」
※単品積上げ価格1720円より470円お得


### 投稿例3

今、流行ってます。
この形式も海外輸入の典型例。

日本語の運営者に怒られそう
「英語のチャンネル見つけるなよ！」って笑

←英語🇺🇸　🇯🇵日本→

投稿例

新しいAIモデルが発表。 ベンチマーク以上に見るべきなのは、 「人間なしでどこまで仕事を進められるか」です。 AI競争は、 答えが上手い ↓ 仕事を最後まで終えられる に移り始めています。 モデル性能が上がるほど、 次の差になるのは「実行力」です。

プロンプト

# 前提情報

テーマ：{テーマ}
スレッド数：{スレッド数}
参考URL：（未指定）

# 今回の型の指定
「一次情報から答えの抜粋」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
ニュースや原典を、読者の問いへの答えと仕事・行動に関わる意味へ変える。

# 切り口の選択
今回の題材と依頼に合う切り口を次から1つ選び、その切り口の作成手順と投稿設計だけを使ってください。選ばなかった切り口の流れや結論を混ぜないでください。
- ニュースの影響解説
- 一次情報から答えの抜粋

# 作成手順・投稿設計

## ニュースの影響解説

### 作成手順

#### 1. 最新情報を調査する

参考URLが指定されている場合は、そのページの内容を最優先で確認してください。
そのうえで、調査メモでテーマに関する動向を確認してください。

優先順位：
1. 公式発表・当事者の一次情報
2. 公式ドキュメント・GitHub・論文・決算資料
3. 信頼できる報道
4. 専門家の分析
5. 公開されている反応・言及

「いつ発表されたか」「何が新しいか」「従来と何が違うか」まで確認してください。

十分に新しくない場合は「速報」と表現しないでください。

#### 2. 「つまり」を3段階掘る

最重要ニュースについて、

① 何が起きた？
② つまり、何ができる・変わる？
③ その結果、<ベースプロンプト>の読者の仕事・市場・行動はどう変わる？

まで推論してください。

投稿の価値は③に置き、
ニュース要約だけで終わらせないでください。

#### 3. 独自の切り口を探す

いま何が注目されているかも調査メモで確認し、

「多くの人が見ている点」
と
「実際に影響が大きい点」

にズレがないか探してください。

特に、

「みんなAを見ているが、重要なのはB」
「発表されたAより、その結果起きるBの方が大きい」

という二次・三次効果を優先してください。

#### 4. 最も強いフックを選ぶ

冒頭候補を内部で複数作り、

- 新規性
- 一瞬で理解できる
- <ベースプロンプト>の読者への影響が伝わる
- 続きを読みたくなる

ものを採用してください。

### 投稿設計

基本構造：

1. 何が起きたか＋最大の意味
2. 従来との違い
3. なぜ重要なのか
4. <ベースプロンプト>の読者への具体的な影響
5. 次に起きそうなこと
6. 一文で結論

原則は、1つの投稿で核心まで伝えてください。

ただし、

- 独立して重要な論点が複数ある
- 複数の影響を順番に理解した方が分かりやすい
- 各投稿単体でも新しい発見を提供できる

場合はスレッドを選んでください。

スレッドでも1投稿目だけで
「何が起きたか＋なぜ重要か」
まで理解できるようにしてください。

## 一次情報から答えの抜粋

### 作成手順

#### 1. 読者が知りたい問いを特定する

テーマについて、
<ベースプロンプト>の読者が今もっとも知りたいことを1つに絞ってください。

例：

- 各社はAIをどう使うと言っているのか
- 各経営者は今回の決算をどう評価しているのか
- 新製品を実際に使った人は何と言っているのか
- 各陣営は今回の条件をどう見ているのか
- 各社は新制度にどう対応するのか

投稿内でこの問いを長く説明する必要はありません。

#### 2. 一次情報を調査する

まず調査メモを確認してください。

優先順位は以下です。

1. 本人・企業・組織による公式発表
2. 会見、インタビュー、決算説明会などの本人発言
3. 信頼できる報道機関による直接取材
4. その他の二次情報

できる限り一次情報まで遡ってください。

古い情報よりも最新情報を優先し、
テーマに日付やイベントが関係する場合は対象時点を明確にしてください。

#### 3. 「答えになる部分」だけを抜き出す

情報量を増やすのではなく、
読者が知りたい問いへの答えになっている部分だけを残してください。

各項目は基本的に、

対象者・企業・商品名など
「答え」

の2段構成にします。

前置き、背景説明、挨拶、一般論など、
その部分を削除しても意味が変わらない文章は削ってください。

問いに答えるのに必要な項目に絞ります。

#### 4. 並べる価値を作る

単に発言を羅列するのではなく、
並べることで違いが見える情報を優先してください。

例えば、

- 強気 / 慎重
- 賛成 / 反対
- 期待 / 懸念
- 高評価 / 低評価
- 同じ質問への異なる回答
- 同じニュースに対する各社の対応

などです。

読者が一覧を見ただけで比較できる状態を目指してください。

### 投稿設計

基本構造は以下です。

① 何についての情報なのかを1〜2行で明示

② 対象名

③ その対象について最も重要な「答え」

④ ②〜③を複数並べる

余計な導入や長い総括は原則不要です。

投稿そのものを「答え一覧」として成立させてください。

# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- ニュースの影響解説：発表された事実と、その先の影響を分けたか。要約だけで終わらず、読者に何が変わるかまで伝わるか。
- 一次情報から答えの抜粋：各項目が同じ問いへの答えか。原文の趣旨・条件を保ち、一覧で違いが見えるか。長い前置きや総括が答えを埋めていないか。

# 投稿例

## 例1：単発

新しいAIモデルが発表。

ベンチマーク以上に見るべきなのは、
「人間なしでどこまで仕事を進められるか」です。

AI競争は、

答えが上手い
↓
仕事を最後まで終えられる

に移り始めています。

モデル性能が上がるほど、
次の差になるのは「実行力」です。


## 例2：長文

あるAIサービスが大幅値下げ。

ニュースだけ見ると
「安くなった」で終わります。

でも重要なのは、
これまで人間や外注に任せていた仕事まで
ソフトウェアへ移せる価格帯に入る可能性があること。

技術の進化は、
性能が上がった瞬間より

「経済合理性が逆転した瞬間」

に市場を大きく変えることがあります。

新しいAIを見るとき、

何ができるようになった？
だけでなく

その価格なら、
誰の仕事や売上を置き換えられる？

まで見る。

僕ならこちらを重視します。


## 例3：スレッド

1/

新しいAI開発基盤が、
複数エージェントの連携を強化。

重要なのは
「AIがまた少し賢くなった」ことではありません。

AIが

1人の助手
↓
複数人のチーム

に近づいていることです。

大きな変化は3つあります。

2/

1つ目。

これまでは、

人間
→ AI A
→ 人間
→ AI B

と、人間がAI同士をつないでいました。

これが、

人間
→ AI A ↔ AI B ↔ AI C

に近づく。

人間の仕事が
「各作業を実行する」から
「チームに目的を渡す」へ移ります。

3/

2つ目。

するとAIの評価軸も変わります。

単体の回答性能だけでなく、

・仕事を分担できるか
・状態を引き継げるか
・失敗から復旧できるか
・長時間動けるか

が重要になる。

4/

つまり今回の発表は、
単なる新機能追加というより

AIエージェント競争が

「一番賢いAIはどれか」

から

「一番仕事を任せられるAIチームはどれか」

へ進む兆候として見ると面白いです。


## 統合した切り口の例：2026最新：一次情報・答え抜粋型

### 例1

高松宮記念2026　枠順後の陣営の声抜粋

パンジャタワー
「外枠になるより良かったです」

ナムラクレア
「並びを見たら競馬がしやすいなという印象」

ペアポルックス
「大谷選手の背番号と同じなのはうれしいですね」

ジューンブレア
「相手の出方を見るなら一番いい枠」


### 例2

生成AI導入について、経営者の発言だけ抜粋

A社 CEO
「全社員が日常的に使う前提で業務を再設計する」

B社 CEO
「まずは開発とカスタマーサポートから導入する」

C社 CEO
「コスト削減より、新しい売上を作れるかを重視している」

D社 CEO
「機密情報を扱う業務への導入は慎重に進める」


### 例3

新しい働き方制度について、社員が気になる部分だけ抜粋

出社頻度
「原則として週3日」

対象者
「国内勤務の正社員」

開始時期
「10月から順次適用」

例外
「育児・介護などの事情がある場合は個別に対応」

投稿例

3週間かけて作った機能。 ほとんど使われませんでした。 作る前にユーザーへ聞いていました。 「この機能あったら使いますか？」 答えはほぼ全員、 「欲しい」。 だから作った。 でも質問が間違っていた。 本当に聞くべきだったのは、 「今、その問題をどう解決していますか？」 だった。 本当に困っているなら、 すでに時間かお金を使っていることが多い。 「欲しい」は意見。 「今やっている」は行動。 新規事業では、 言葉より行動の方が情報量が多い。

プロンプト

# 前提情報
テーマ：{テーマ}
スレッド数：{スレッド数}
本人の事実情報：{本人の事実情報}

# 今回の型の指定
「再起・自己開示」の切り口だけを使い、他の切り口の構成や結論は混ぜないでください。

# 狙い
体験・検証・事例の経緯から、読者が再利用できる判断を取り出す。
# 切り口の選択
題材と依頼に合う切り口を1つ選び、対応する手順・構成だけを使う。他の切り口の流れや結論は混ぜない。
- 失敗からの学び
- 実験・検証
- 成功・失敗事例の分解
- 再起・自己開示
# 作成手順・投稿設計
冒頭は各切り口の基準で候補を比べ、1つ選ぶ。
## 失敗からの学び
#### 1. 学びになる失敗を探す
テーマについて
- よくある失敗・遠回り
- 一見正しそうなのに失敗する行動
- 経験者が後悔していること
- 公開されている失敗事例・撤退・方向転換
- 「もっと早く知りたかった」と言われること
を探してください。
単なる不運ではなく、
<ベースプロンプト>の読者も同じ判断をしそうな失敗を優先する。
#### 2. 「本当の失敗原因」を掘る
表面的な原因で止めず、
何を信じていた？
↓
なぜそれが正しいと思った？
↓
現実は何が違った？
↓
本当の判断ミスは何だった？
まで掘ってください。
投稿の核心は、
失敗そのものより「認識が変わった瞬間」です。
#### 3. 最も強い入口を選ぶ
- 何が起きたか一瞬で分かる
- 続きを読みたくなる
- <ベースプロンプト>の読者が自分ごと化できる
- 過剰な煽りではない
### 投稿設計
1. 失敗・結果が分かる場面
2. 当時は何を正しいと思っていたか
3. 実際に何をしたか
4. 何が想定と違ったか
5. 本当の失敗原因
6. その後、何を変えたか
7. 読者が再利用できる原則
認識の変化を丁寧に描くなら長文、失敗と学びが短く伝わるなら単発。独立した学びのある複数の試行・転換点だけスレッドにし、冒頭で失敗を示す。
## 実験・検証
#### 1. 検証する価値のある問いを作る
テーマについて
- よく信じられている主張
- AとBで意見が割れていること
- 実際に試さないと分かりにくいこと
- 最近の環境変化で答えが変わった可能性があること
を探してください。
「AIは便利か？」ではなく、
「同じタスクならAとBのどちらが速く・高品質か？」
のように比較・検証できる問いにしてください。
#### 2. 検証方法を選ぶ
利用できる証拠を次の順で判断する。
1. ユーザー自身の実測データ
2. 確認済みの比較・検証の記録
3. 公式ベンチマーク・公開実験・複数の実測事例
#### 3. 条件を揃える
比較する場合は、
- 同じタスク
- 同じ入力
- 同じ期間
- 同じ評価基準
など、結果に影響する条件を可能な限り揃えてください。
テーマに応じて、
時間・費用・品質・成功率・CTR・CVRなど
最も意味のある指標を選んでください。
#### 4. 結果より先に仮説を持つ
検証前に
「普通ならAが勝つと思う」
「一般にはBが有利と言われている」
という事前仮説を整理する。
結果との差が、
投稿の面白さになります。
予想通りでも無理に意外な結論を作らず、
「どこだけ予想と違ったか」を探してください。
#### 5. 最も強いフックを選ぶ
- 結果を知りたくなる
- 比較条件が具体的
- <ベースプロンプト>の読者に関係する
- 意外性がある
### 投稿設計
1. 検証する問い＋重要な結果
2. 事前仮説
3. 検証条件・方法
4. 結果
5. 意外だった点
6. なぜそうなったか
7. 実務でどう使うか
8. 必要なら検証の限界
1つの比較は単発〜長文で完結。複数条件・複数回の検証や改善の変化に価値がある場合だけスレッドにし、冒頭で主要な結果を示す。
## 成功・失敗事例の分解
#### 1. 事例を正確に再構成する
調査メモから一次情報を優先して
- 当初の状況・目的
- 当時分かっていたこと
- 主要な意思決定
- 制約・競合・市場環境
- 結果を変えた転換点
- 最終的な結果
を時系列で整理する。
結果を知った状態から逆算して、
「当然こうすべきだった」と判断しないでください。
#### 2. 結果を分解する
「成功したのは○○のおかげ」
「失敗したのは△△のせい」
と1要因に単純化せず、
- 戦略
- プロダクト
- Distribution
- 価格
- タイミング
- 組織
- 市場環境
- 運・外部要因
などから主要因を切り分けてください。
特に、
「直接見える要因」
より
「その要因を生んだ1つ前の意思決定」
を探してください。
#### 3. 最大の転換点を特定する
複数の出来事から、
「ここで別の選択をしていたら結果が大きく変わった可能性がある」
転換点を1〜3個選んでください。
その時点で、
- どんな選択肢があったか
- なぜその判断をしたのか
- 何が起きたか
を明確にしてください。
#### 4. 別の説明でも成立しないか確認する
採用した分析について、
「本当にこの要因が重要だったのか？」
「別の要因でも結果を説明できないか？」
を検討する。
事実と推論を分け、
因果を断定できない場合は「可能性」「示唆」として扱ってください。
#### 5. 最も強いフックを選ぶ
- 結果と謎が同時に伝わる
- 「なぜ？」と思う
- <ベースプロンプト>の読者が学べる
- 事例固有の面白さがある
### 投稿設計
1. 結果＋最大の問い
2. 当時の状況
3. 最初の戦略・判断
4. 転換点
5. その判断が生んだ結果
6. 他の要因・反対仮説
7. 最も重要だった要因
8. 他の場面でも使える原則
単純な事例は長文1投稿。時系列・転換点・因果を順に追う価値がある場合はスレッドにし、冒頭で結果と問いを示す。
## 再起・自己開示
#### 1. 最も強いギャップを探す
題材と人物像から、
- 大きな失敗 → 現在の成果
- 何もなかった状態 → 獲得したもの
- 挫折 → 再起
- 周囲から見えない弱み → 表から見える現在
- 過去の自分 → 今の自分
など、最も意外性のある対比を探してください。
内部で複数のフック候補を作り、
「続きが気になる」「どうやってそこまで行ったのか知りたい」と感じるものを選んでください。
数字や具体的事実がある場合は優先して使います。
#### 2. 弱さを具体化する
「大変だった」「苦労した」のような抽象表現ではなく、
題材と人物像に合う場面から、
当時の状態が一瞬で伝わる具体的な情報を選びます。
特に、
- 失敗した回数
- 借金・売上などの数字
- 退職・倒産・不合格などの出来事
- 持っていなかったもの
- 周囲には隠していたこと
- 当時の感情や状況
が有効です。
#### 3. 公開する理由を作る
「こんな過去があります」で終わらせず、
なぜ今それを公開するのか
を必ず入れてください。
例えば、
- 同じ状況の人に勇気を与えたい
- 表面的な成功だけではなく等身大の自分を知ってほしい
- 同じ失敗をする人を減らしたい
- 挑戦する人の背中を押したい
などです。
題材と人物像から自然に導ける理由を使ってください。
#### 4. 「きれいすぎる話」にしない
必要であれば、
本人側にも利益があることを率直に書いてください。
例えば、
- 新しい事業を知ってほしい
- 認知度を上げたい
- 採用につなげたい
- 商品を知ってほしい
- フォロワーを増やしたい
などです。
社会的にきれいな理由だけを並べるより、
適度な自己利益も隠さず書くことで人間味を出します。
### 投稿設計
##### ① 強烈な過去 → 現在のギャップ
投稿冒頭1〜2行で、
人生・キャリア・事業などの大きな振れ幅を提示します。
例：
「〈過去の状態〉→〈現在の状態〉までの○年間をまとめました。」
数字や具体的事件があれば使用します。
##### ② 「持たざる状態」を圧縮
2〜4個程度の短い言葉を並べ、
当時の状況を視覚的に伝えます。
例：
経験なし、実績なし、人脈なし、資金なし
##### ③ なぜ公開するのか
弱みや過去を公開することへの葛藤と、
それでも公開する理由を書きます。
ここが共感の中心です。
##### ④ 現在・次の挑戦
過去話だけで終わらず、
「今、この人はどこへ向かっているのか」を短く入れます。
読者がプロフィールや今後の投稿を追う理由を作ってください。
##### ⑤ 本音
本人に宣伝・認知・採用などの目的があれば、
過度に取り繕わず短く開示します。
「善意100%」に見せようとしないこと。
##### ⑥ 締め
次の挑戦や本音で締めてください。参加の呼びかけは依頼に合う場合だけ自然に添え、反応を強要しないでください。
# 仕上げの点検
選んだ切り口の次の観点で読み返し、満たさなければ該当箇所を直してから出力してください。
- 失敗からの学び：当時の認識・実際の行動・想定との差・変えたことがつながるか。単なる不運や自虐を教訓にしていないか。
- 実験・検証：問い・条件・方法・結果・解釈を区別したか。比較条件の差や限界を落とさず、予想との差を実際の結果で示したか。
- 成功・失敗事例の分解：その時点の選択肢と判断を再構成したか。結果を1要因で説明せず、別の要因・外部環境・運でも説明できるかを検討したか。
- 再起・自己開示：過去と今の差・公開する理由・次の挑戦がつながるか。抽象的な苦労話やきれいな動機だけで埋めず、反応を強要していないか。

# 投稿例

## 例1：単発

3週間かけて作った機能。

ほとんど使われませんでした。

作る前にユーザーへ聞いていました。

「この機能あったら使いますか？」

答えはほぼ全員、
「欲しい」。

だから作った。

でも質問が間違っていた。

本当に聞くべきだったのは、

「今、その問題をどう解決していますか？」

だった。

本当に困っているなら、
すでに時間かお金を使っていることが多い。

「欲しい」は意見。

「今やっている」は行動。

新規事業では、
言葉より行動の方が情報量が多い。


## 例2：長文

AIを使い始めた頃、
1回目の回答を完璧にすることばかり考えていました。

前提条件を書く。
役割を書く。
禁止事項を書く。
例を書く。

プロンプトだけで30分。

確かに1回目の回答品質は上がった。

でもあるとき、

5分で依頼
↓
出力を見る
↓
ズレだけ修正
↓
もう一度出す

方が、完成まで速い仕事が多いと気づきました。

最適化していた指標が違った。

見ていたのは
「1回目の正答率」。

本当に見るべきだったのは
「完成までの総時間」。

AIでは、
一発で正解することより
安く速く修正できることの方が重要な場面があります。


## 例3：スレッド

1/

ある新規事業。

市場調査もした。
競合も調べた。
ユーザーにも聞いた。

それでもリリース後、
ほとんど使われませんでした。

問題は「調査不足」ではありませんでした。

調査の仕方でした。

2/

ユーザーには何度も聞いていました。

「このサービス欲しいですか？」

「使いたいですか？」

反応は良かった。

だからチームは
需要があると判断した。

3/

でもリリース後、

登録しない。
乗り換えない。
お金を払わない。

言葉と行動が一致しませんでした。

4/

ここで重要なのは、
ユーザーが嘘をついたわけではないこと。

「無料なら欲しい」

と

「今の方法を捨てて、お金を払って使う」

は別の判断です。

5/

次に見るべきだったのは、

「欲しいですか？」

ではなく、

「今どうやって解決していますか？」
「そのために何時間・いくら使っていますか？」

でした。

6/

失敗したのは、
ユーザーの声を聞いたことではない。

未来の「気持ち」を
現在の「需要」だと解釈したこと。

顧客理解では、
言葉を聞く以上に
現在の行動を見ることが重要です。


## 統合した切り口の例：実験・検証してみた

※以下は構造例です。数値は説明用の架空例です。

### 例1：単発

AIに文章を書かせるとき、

A：最初に完璧なプロンプトを書く
B：短く指示して、出力を見ながら直す

どちらが速いのか。

同じ記事作成で比べると、

A
指示作成：25分
修正：10分
合計：35分

B
初回指示：5分
修正3回：18分
合計：23分

1回目の品質はAが上。

でも完成までの時間はBが短かった。

AI活用で見るべきなのは
「一発目の正答率」だけではない。

修正まで含めた
「完成までの総コスト」です。


### 例2：長文

「AIモデルは一番賢いものを使えばいい」

本当にそうなのか、
同じ3種類の仕事で比較すると見え方が変わります。

文章要約ではA。

コード修正ではB。

画面操作ではC。

総合ベンチマーク1位が
全部の仕事で1位になるわけではない。

面白いのは、
モデルの優劣より

「仕事によって勝者が変わる」

ことです。

AI選びは、

最強モデルを1つ決める

より

タスクごとに最適モデルを決める

方が実務では合理的かもしれません。


### 例3：スレッド

1/

X投稿は
「結論から始めた方が伸びる」のか。

同じテーマで、

A：結論から開始
B：問いから開始
C：具体的な出来事から開始

を比較。

結果を見ると、
単純に「結論型が最強」とは言えませんでした。

2/

まず表示回数。

A：○○
B：○○
C：○○

一番伸びたのはC。

ただし、
これだけでは結論は出せません。

3/

プロフィール閲覧を見ると、
今度はAが最も高い。

つまり、

表示されやすい構成
と
「この人をもっと見たい」と思わせる構成

が同じとは限らない。

4/

今回の検証で一番重要だったのは、

「どの投稿が勝ったか」

ではありません。

何を成果とするかで
勝者が変わったことです。

Xの検証では、
インプレッションだけでなく

返信
共有
プロフィール閲覧
フォロー

まで分けて見た方がいい。

## 統合した切り口の例：成功失敗事例の分解・Teardown

### 例1：長文

あるSaaSが伸びた理由を
「AIの性能が高かったから」
だけで説明すると、かなり見落とします。

最初は多機能を売りにしていた。

でもユーザーが実際によく使ったのは、
たった1つの機能。

そこで、

機能を増やす
ではなく
その1機能までの導線を短くする

方向へ寄せた。

結果として変わったのは
AI性能ではなく、
最初の価値体験までの距離です。

成功要因を「技術力」と見るより、

ユーザー行動を見て
最初の仮説を捨てられたこと

と見る方が再現性が高い。


### 例2：長文

ある新規事業が撤退。

表面的には
「市場が小さかった」で終わります。

でも時系列で見ると、
もっと前に分岐点がありました。

最初から大企業向けに設計
↓
要求機能が増える
↓
開発期間が延びる
↓
検証前に固定費が大きくなる
↓
市場とのズレが分かった時には方向転換が重い

つまり問題は、
最後の売上不足だけではない。

「需要を確認する前に、
変更コストの高い事業構造を作った」

こと。

失敗は撤退時ではなく、
戻れなくなった時点から始まっていた可能性があります。


### 例3：スレッド

1/

ある後発プロダクトが
先行サービスを追い抜いた。

普通に考えると、
機能で勝ったように見えます。

でも時系列で分解すると、
勝負を変えたのは別の3つの判断でした。

2/

最初の判断。

競合より機能を増やさなかった。

代わりに、

「最初の10分で価値を感じる」

ことへ集中した。

機能数では負ける。
オンボーディングでは勝つ。

3/

次の判断。

全員を狙わなかった。

利用が特に強かった職種へ
メッセージを絞った。

市場を狭めた結果、

「これは自分向けだ」

が伝わりやすくなった。

4/

3つ目。

新機能よりDistributionへ投資した。

プロダクト差が縮まり始めた段階で、

作る
↓
届ける

へボトルネックが移ったと判断した。

5/

もちろん、
この3つだけで成功したとは言えません。

市場拡大や競合の動きなど
外部要因もある。

ただ時系列で見ると、

機能
→オンボーディング
→顧客集中
→Distribution

と、ボトルネックが変わるたびに
投資先も変えている。

6/

このケースから持ち帰りたいのは、

「正しい戦略を最初から当てること」

ではありません。

今のボトルネックが変わったときに、
過去の勝ち筋を捨てられること。

事業の強さは、
正解そのものより
正解を更新する速度に出るのかもしれません。

## 統合した切り口の例：2026最新：どん底→再起・自己開示型 X投稿生成

### 例1

3度の逮捕→少年院→数億円で会社売却した31年の人生を綴りました。

学歴なし、スキルなし、金なし、コネなし
どん底のリアルです。

隠して生きていく予定でしたが、等身大の僕を知ってほしいかつ僕のように持たざる者が少しでも勇気を持って挑戦するキッカケになれば嬉しいです。

また、次なる挑戦もスタートしました。
新規事業のために認知度を上げたいという下心も正直あります。

いいね、引用で拡散してくださると泣いて喜びます！


### 例2：個人開発者の場合の構造例

〈何度も失敗した事実〉→〈現在の成果〉までの過程を、全部まとめました。

〈当時持っていなかったもの〉
〈失敗した具体的事実〉

うまくいった部分だけ話す方が格好はつくのですが、
同じところで悩んでいる人には失敗した部分の方が役立つと思ったので公開します。

今は〈次の挑戦〉を始めています。

もちろん、これを機に〈本人に実際に存在する目的〉という本音もあります。

何か刺さった部分があれば、いいねや引用をもらえるとうれしいです。


### 例3：キャリア転換の場合の構造例

〈過去のキャリア・挫折〉→〈現在のキャリア〉。

ここに至るまでの過程を公開しました。

〈具体的な失敗〉
〈持っていなかったもの〉
〈一度諦めたこと〉

順調に見える部分だけ発信することもできますが、
これから同じ道に挑戦する人には、その裏側まで見せた方が意味があると思っています。

そして今、〈新しい挑戦〉も始めています。

〈本人に実際に存在する目的〉という打算もあります。
そこも含めて今の自分です。

応援してもらえるなら、いいね・引用していただけるとうれしいです。