2026-08-04_大串_X投稿案
2026-08-04 大串アカウント X投稿案
選定結果（2026-08-04 大串判断）：全10本ボツ。全テーマ再提案禁止対象。
30秒で全体像
| # | カテゴリ | テーマ | 目的 | メディア | 採点 | 根拠 |
|---|---|---|---|---|---|---|
| ① | 商談設計 | 選択肢3つで比較軸を変える | 信頼構築・拡散 | なし | 91/100 | 中 |
| ② | 商談・HP | HP商談でHPの話から始めない | 拡散・DM獲得 | なし | 91/100 | 中 |
| ③ | 事業実況 | 量と質は一致しない（集客経路） | フォロー獲得・拡散 | なし | 90/100 | 中 |
| ④ | TERASU設計 | 価格は動かすが中身は変えない | 信頼構築・DM獲得 | なし | 92/100 | 中 |
| ⑤ | 事業実況 | TERASUを始めてからHPの見方が変わった | フォロー獲得 | なし | 90/100 | 弱 |
| ⑥ | 経営哲学 | 受注できなくても報酬が出る設計 | 拡散・信頼構築 | なし | 91/100 | 中 |
| ⑦ | 事業実況 | TERASUの商談、自分でやってない | フォロー獲得・拡散 | なし | 90/100 | 中 |
| ⑧ | 業界批判 | HP制作会社が最初から値引きしてくる時 | 拡散・DM獲得 | なし | 90/100 | 弱 |
| ⑨ | 商談ノウハウ | ツリー：HP商談で最初にやること | 保存・拡散 | なし | 91/100 | 中 |
| ⑩ | マインド | コンペに勝つのは全員に90点を出した人じゃない | 拡散・フォロー | なし | 90/100 | 弱 |
根拠列が「 弱」のポストは Claude推測の補完が多い → 大串の意図と乖離してる可能性。優先レビュー対象。
- 推奨投稿順：朝（③ or ⑦）→ 昼（② or ④）→ 夜（⑨ツリー or ①）
- 主な参照ノート（このセッション全体で使ったVault情報の総覧）:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案 — ①④⑩の出典
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/channels_集客経路まとめ — ③の出典
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/script2_スクリプトPtn②（数値型） — ②⑨の出典
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/reward_FSの報酬 — ⑥の出典
投稿案 ①：選択肢3つで比較軸を変える
カテゴリ: 商談設計
Vault根拠: 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案
キャッチコピー候補5つ（推奨は ）
①「TERASUにするかどうか」を聞くのをやめた。
② 商談で選択肢を3つ出すようにしてから、決まる確率が変わった。
③ 「どれにしますか？」で聞けるかどうかで、商談の着地が変わる。
④ 決まらない商談の多くは、選択肢が1つしかないから決まらない。
⑤ うちはHP制作で、プランを3つ用意している。
本文（コピペ即投稿可）
「TERASUにするかどうか」を聞くのをやめた。
今は「A・B・C、どれが合ってますか？」で聞いている。
・A：標準プラン（初期10万＋月1.5万）
・B：買い切り（25万・月額なし）
・C：月額のみ（初期0円・月2.5万から）
3択にすると、比較の対象が変わる。
「TERASUにするか、他社にするか」じゃなくて、「TERASUのA・B・Cのどれにするか」という話になる。
相手は「決める/断る」じゃなくて、「A/B/C」で考え始める。
決まらない商談の多くは、選択肢が1つしかないから決まらない。
このポストの設計
- 目的: 拡散・信頼構築
- ターゲット: 商談設計を改善したい経営者・営業担当
- 意識した3点:
1. 「やるか・やらないか」→「どれにするか」という比較軸の転換を逆張りで見せた
2. TERASUの実際のプラン（具体的な金額）を固有情報として入れることで大串にしか言えない具体に着地
3. 「決まらない商談は選択肢が1つ」という断定で締め、読後に即使える物差しを残す
メディア推奨
- 推奨: なし
- 理由: テキストの論理構成で完結しており、図解より文章で読む方が刺さる内容
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 18/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 13/15 |
| 応用例 | 9/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 5/5 |
| 総合 | 91/100 |
添削しやすいポイント
- キャッチ変更したい場合 → 候補②〜⑤から差し替え可
- プランの金額が違う場合 → 表の数字を最新の実態に合わせて修正
- トーンを変えたい場合 → 「今は〜で聞いている」を「試してみたら変わった」系にできる
Vault根拠（出典・最重要）
根拠強度: 中（FSマニュアルに具体的なプラン設計の明文はあるが、大串本人の生の発話としての出典ではない）
ソース種別: E（AI生成ノート参考程度・FSマニュアルは実務ベースだが大串の肉声発言との区別が必要）
主参照ノート:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案 (ソースE・FSマニュアル) — プランの3択設計・「どれにするか」で聞く手法の出典
Vaultからの引用箇所:
「迷ったら、複数プランを並べて選んでもらう。ヒアリングしても初期がネックなのか月額がネックなのかが読み切れないことはあります。そんな時は3つ並べて提示して、相手に選んでもらうのが確実です。『やるか・やらないか』の話から『どれにするか』の話に変わるので、決まりやすくなります。」
— 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案 (ソースE)
着想プロセス（マッピング）:
| FSマニュアルの記述 | ソース種別 | ポストの反映先 |
|---|---|---|
| 「3つ並べて提示して相手に選んでもらう」 | E（FSマニュアル） | 本文の構成全体・「A/B/C」の3択設計 |
| 「やるか・やらないかから、どれにするかに変わる」 | E（FSマニュアル） | キャッチコピー・本文の核心 |
| 標準プラン・買い切り・月額のみの3プラン体系 | E（FSマニュアル） | 本文の具体的な金額・プラン名 |
投稿案 ②：HP商談でHPの話から始めない
カテゴリ: 商談・HP
Vault根拠: 21_ナレッジベース/マニュアル_ナレッジ/FS部署/script2_スクリプトPtn②（数値型）
キャッチコピー候補5つ（推奨は ）
①HP制作の商談で、HPの説明から入らない。
② 「売上がいくら増えるか計算してから、HPを提案する。」
③ HP商談なのに、最初にHPの話をしない理由。
④ TERASUの商談、最初にやるのはヒアリングじゃなくて計算だ。
⑤ 「HP作りたい」から始まる商談が、正直一番難しい。
本文（コピペ即投稿可）
HP制作の商談で、HPの説明から入らない。
最初にやるのは、現状の数字のヒアリングだ。
「今のHPから月に何件問い合わせが来てますか？」
「月にどれくらいの人がHPに来ていますか？」
「問い合わせから成約するのは何割くらいですか？」
この数字が揃うと、HP改善でいくら売上が変わるか計算できる。
月1,000人来て問い合わせ率が1%なら月10件。
これが2%になれば20件、成約率20%・単価30万なら月180万の差だ。
この計算を一緒にやってから、TERASUの提案を出す。
「HPを作りましょう」より「この計算、一緒にやってみませんか？」の方が、商談が動く。
このポストの設計
- 目的: 拡散・DM獲得（経営者が「相談してみたい」と感じる設計）
- ターゲット: HP制作を検討しているがROIが見えていない経営者
- 意識した3点:
1. 「HP商談でHPから入らない」という逆張りでスクロールを止める
2. 具体的な計算式（月1,000人・1%→2%・単価30万）を入れ、大串の商談の実態として語る
3. 締めに「HP作りましょう→計算やりませんか？」の言い換えを入れて読後に使えるフレーズを残す
メディア推奨
- 推奨: なし
- 理由: 数字の計算プロセスはテキストで読む方が頭に入りやすい
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 18/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 13/15 |
| 応用例 | 9/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 5/5 |
| 総合 | 91/100 |
添削しやすいポイント
- 数字を変えたい場合 → 「月1,000人・単価30万」を実際の典型的なクライアントの数字に変更可
- 質問の数を減らしたい場合 → 3つの質問を1〜2つに絞ることで読みやすくなる
- キャッチを変えたい場合 → 候補②「計算してから提案する」系に切り替え可
Vault根拠（出典・最重要）
根拠強度: 中（FSマニュアルの数値型スクリプトに明確な記述あり。大串が実際に使っている手法として語っているが、肉声発言としての出典はない）
ソース種別: E（FSマニュアル・参考程度）
主参照ノート:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/script2_スクリプトPtn②（数値型） (ソースE) — 「HPを作りたい」ではなく「売上を上げたい」から入るアプローチ・数値ヒアリングの質問・ROIシミュレーションの出典
Vaultからの引用箇所:
「『HPを作りたい』ではなく『売上を上げたい』から入るアプローチ。ヒアリングで現状の数値を引き出し、HP改善のROIを一緒に計算してから提案する。論理と数字で『やりたい』を先に作り、TERASUの価格はその後に出す。」
— 21_ナレッジベース/マニュアル_ナレッジ/FS部署/script2_スクリプトPtn②（数値型） (ソースE)
着想プロセス（マッピング）:
| FSマニュアルの記述 | ソース種別 | ポストの反映先 |
|---|---|---|
| 「HPではなく売上から入るアプローチ」 | E（FSマニュアル） | キャッチ・本文の入り方 |
| ヒアリング4項目（アクセス数/問合率/成約率/単価） | E（FSマニュアル） | 本文の3つの質問 |
| ROIシミュレーション例（小規模500人/中規模1,000人） | E（FSマニュアル） | 本文の「月1,000人・1%→2%・月180万」の計算 |
| 「YES が出たら初めてTERASUの提案へ」 | E（FSマニュアル） | 「計算してから提案を出す」という構成の締め |
投稿案 ③：量と質は一致しない（集客経路の話）
カテゴリ: 事業実況
Vault根拠: 21_ナレッジベース/マニュアル_ナレッジ/FS部署/channels_集客経路まとめ
キャッチコピー候補5つ（推奨は ）
①問い合わせが一番来る経路と、受注率が一番高い経路は全然違う。
② 問い合わせの「量」と「質」は別物だと知ってから、発信への向き合い方が変わった。
③ TERASUで受注率が一番高い経路、実は意外だった。
④ 相見積もりで来た問い合わせの正直な話。
⑤ Xに投稿し続けている理由は、データを見てから決めた。
本文（コピペ即投稿可）
問い合わせが一番来る経路と、受注率が一番高い経路は、全然違う。
量が多いのは一括見積もり（相見積もり）経由。
質が高いのは紹介経由、次がインバウンド（X・HP直接）。
一括見積もりは、同時に複数社に声がかかっている。紹介やインバウンドは最初からうちに来ている。
温度が違う。
これを理解してから、相見積もりの数を追うより、紹介を依頼してインバウンドを育てる方に時間をかけるようにした。
Xに投稿し続けているのは、そういう理由だ。
このポストの設計
- 目的: フォロー獲得・拡散（「そうか、だから発信してるのか」という納得を引き出す）
- ターゲット: 自社の集客経路の最適化に悩んでいる経営者・マーケ担当
- 意識した3点:
1. 「量と質は違う」という逆張り断定でキャッチする
2. 「Xに投稿し続けている理由」を最後に明かすことで大串アカウントの発信意図そのものを見せる
3. 「温度が違う」という一行で間を作り、読後の納得感を高める
メディア推奨
- 推奨: なし
- 理由: 短文の論理展開で完結している
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 18/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 12/15 |
| 応用例 | 9/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 5/5 |
| 総合 | 90/100 |
添削しやすいポイント
- 受注率の数字を入れたい場合 → 「紹介経由の受注率は◯割」など実際のデータを入れると更に強くなる
- 締めを変えたい場合 → 「だから、発信は続ける」「だから、まず紹介を依頼する」など複数の着地が選べる
Vault根拠（出典・最重要）
根拠強度: 中（FSマニュアルに各経路の温度・特徴の記述あり。受注率の順位はマニュアルから読み取れる傾向ベース）
ソース種別: E（FSマニュアル・参考程度）
主参照ノート:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/channels_集客経路まとめ (ソースE) — 各経路の温度・特徴の出典
Vaultからの引用箇所:
「既存クライアントや提携先からの紹介。信頼が既にある状態で始まる、最も受注率が高い経路。」
「X・自社HPの発信を見て、相手から問い合わせが来る経路。既にTERASUに興味・好感がある状態。」
「比較・相見積もりの大手。比較前提で来る。」
— 21_ナレッジベース/マニュアル_ナレッジ/FS部署/channels_集客経路まとめ (ソースE)
着想プロセス（マッピング）:
| FSマニュアルの記述 | ソース種別 | ポストの反映先 |
|---|---|---|
| 「紹介=最も受注率が高い経路」 | E（FSマニュアル） | 「質が高いのは紹介経由」の根拠 |
| 「インバウンド=既にTERASUに興味・好感がある状態」 | E（FSマニュアル） | 「次がインバウンド」の根拠 |
| 「相見積もり=比較前提で来る」 | E（FSマニュアル） | 「量が多いのは一括見積もり」の根拠 |
| 「温度・進め方がかなり違う」 | E（FSマニュアル） | 本文の「温度が違う」という一行 |
投稿案 ④：価格は動かすが中身は変えない
カテゴリ: TERASU設計
Vault根拠: 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案
キャッチコピー候補5つ（推奨は ）
①TERASUで、値引きをしたことがない。正確に言うと。
② 「安くしてほしい」への対応、うちはこうしている。
③ 価格は動かせる。でも、中身は変えない。
④ 値引きと組み換えは、全然違う話だ。
⑤ 「安くしてもらえませんか」に、うちが最初にすること。
本文（コピペ即投稿可）
TERASUで、値引きをしない。
「安くしてほしい」という話が来たら、こう聞く。
「初期費用と月額、どちらがネックですか？」
初期がきついなら、初期を下げて月額を上げる。
月額を払い続けたくないなら、買い切り形式にする。
年間の総額は変えずに、引っかかっている部分だけ外す。
これは値引きじゃなくて、組み換えだ。
値引きはこちらの取り分を減らす。組み換えは相手の引っかかりを解消する。
どのプランを選んでも、修正無制限・15ページまで・サーバー込みは変わらない。価格の形は変えられる。でも、サービスの中身は変えない。
このポストの設計
- 目的: 信頼構築・DM獲得（「こういう会社に頼みたい」という安心感）
- ターゲット: HP制作発注を検討中の経営者・値引き交渉を受けているFS担当
- 意識した3点:
1. 「値引きをしない」という断定からスタートし、「でも組み換えはする」という反転で引き込む
2. 「値引き vs 組み換え」の概念の違いを明確に言語化し、読後に使える物差しを残す
3. 「中身は変えない」という部分をサービスの3条件（修正無制限・15P・サーバー込み）で具体化
メディア推奨
- 推奨: なし
- 理由: 概念の整理がテキストで読まれることに適している
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 18/20 |
| 一貫性 | 15/15 |
| 面白さ | 14/15 |
| 学び | 13/15 |
| 応用例 | 9/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 4/5 |
| 実績データ | 5/5 |
| 総合 | 92/100 |
添削しやすいポイント
- プランの具体例を変えたい場合 → 「初期を下げて月額を上げる」の金額を実際の商談で使っている例に変更可
- キャッチを変えたい場合 → 候補②「安くしてほしいへの対応」系に切り替え可
Vault根拠（出典・最重要）
根拠強度: 中（FSマニュアルに「組み換えで対応する」設計の明文あり。大串の判断・哲学として語っているが肉声発言の直接引用ではない）
ソース種別: E（FSマニュアル・参考程度）
主参照ノート:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案 (ソースE) — 組み換え対応・価格設計の哲学の出典
Vaultからの引用箇所:
「単純に安くするのではなく、形を変えて着地させる。」
「金額を動かすのは『それでも迷う』『今日決まりそう』な局面の切り札として使ってください。まず価値を説明しきるのが先。」
「どのプランでも、サービスの中身の線引きは全プラン共通です。ここを勝手に広げないよう注意してください。」
— 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案 (ソースE)
着想プロセス（マッピング）:
| FSマニュアルの記述 | ソース種別 | ポストの反映先 |
|---|---|---|
| 「単純に安くするのではなく形を変えて着地」 | E（FSマニュアル） | 「値引きじゃなくて組み換え」というキャッチ |
| 「どのプランでもサービスの中身は共通」 | E（FSマニュアル） | 「中身は変えない」「修正無制限・15P・サーバー込みは変わらない」 |
| 「初期を下げて月額を上げる/買い切り」の組み換え例 | E（FSマニュアル） | 本文の具体的な組み換えパターン |
投稿案 ⑤：TERASUを始めてからHPの見方が変わった
カテゴリ: 事業実況
Vault根拠: 直接の引用元なし（大串の体験から着想）
キャッチコピー候補5つ（推奨は ）
①TERASUを始めてから、HPに対する見方が変わった。
② HPをデザインで評価するのをやめた。
③ 良いHPの条件を、今は1つだけで判断している。
④ HP制作をやってみて、一番変わったのは「何を良いHPと呼ぶか」だった。
⑤ 問い合わせが来ないHPは、良いHPとは呼べない。
本文（コピペ即投稿可）
TERASUを始める前、HPをデザインで評価していた。
今は違う。
最初に見るのは「このHPから、月に何件問い合わせが来るか」だ。
デザインがきれいでも問い合わせが来ないHPはある。デザインが普通でも、問い合わせが毎月来るHPもある。
制作を実際にやって、この違いが分かった。
だからTERASUでは、デザインより先に「問い合わせが来る動線が作れているか」を考えている。
このポストの設計
- 目的: フォロー獲得（大串の視点の変化を見せることで人物への興味を引く）
- ターゲット: HP制作を検討している・改善したい経営者
- 意識した3点:
1. 「デザインで評価していた→今は違う」の前後対比で逆張りを作る
2. 「TERASUを始めてから」という大串固有の事業経験から語る
3. 短文で締め、読み終えた後に「じゃあ、問い合わせが来るHPとは？」という余韻を残す
メディア推奨
- 推奨: なし
- 理由: 価値観の変化を語る短文は、テキストのみで完結する
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 17/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 13/15 |
| 応用例 | 8/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 6/5 |
| 総合 | 90/100 |
添削しやすいポイント
- 具体を追加したい場合 → 「実際にデザインを褒められたのに問い合わせがゼロだったHPを見た」など実体験を入れると刺さりが増す
- 締めを変えたい場合 → 「良いHPは、きれいなHPじゃない」という断定で締めることもできる
Vault根拠（出典・最重要）
Vault根拠不足（根拠強度：弱）：このポストの主張は大串の生の言葉ソース（A/B/C/D）に明確な出典なし。
大串がTERASUを経営する中で感じているであろう視点の変化を、Claude が「事業経験から来る気づき」として構成。大串の意図と乖離している可能性あり。要確認。
投稿案 ⑥：受注できなくても報酬が出る設計
カテゴリ: 経営哲学
Vault根拠: 21_ナレッジベース/マニュアル_ナレッジ/FS部署/reward_FSの報酬
キャッチコピー候補5つ（推奨は ）
①成果報酬が本業なのに、商談担当への報酬は受注前から出す設計にした。
② 受注できなくても報酬が確定する。そう設計した理由。
③ 「受注してから払う」をやめた。
④ 商談の質を上げたければ、先に「商談に集中できる環境」を作る。
⑤ 成果報酬の会社が、商談報酬を固定にしてる話。
本文（コピペ即投稿可）
TERASUの商談を担当してもらっているメンバーは、受注できなくても報酬が出る。
商談を1件こなすごとに確定する設計だ。
最初は「受注してから払う」にしようとした。でもやめた。
受注前提の設計は、件数を増やす方向にしか動かない。商談の質より「今月何件クロージングしたか」に意識が向いてしまう。
うちが求めているのは、お客さんの状況に合わせて誠実に提案できる商談担当だ。
だったら、まず商談に集中できる環境を先に作る方がいい。
成果報酬が本業の会社が、商談報酬を固定にしているのは、そういう理由だ。
このポストの設計
- 目的: 拡散・信頼構築（「この会社の設計思想が面白い」という共感を引く）
- ターゲット: 営業組織を持つ経営者・報酬設計に悩んでいる人
- 意識した3点:
1. 「成果報酬が本業なのに商談報酬は固定」という逆説をキャッチにする
2. 「なぜその設計にしたか」の理由を丁寧に語り、設計思想の深さを見せる
3. 締めで「成果報酬が本業の会社が〜」と冒頭に戻すことで、矛盾の解消として着地させる
メディア推奨
- 推奨: なし
- 理由: 哲学・設計思想の話はテキストで読む方が深く伝わる
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 18/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 13/15 |
| 応用例 | 9/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 5/5 |
| 総合 | 91/100 |
添削しやすいポイント
- 「でもやめた」の理由をもっと強調したい場合 → 「受注前提の設計で失敗した経験があった」など実体験を加えると刺さりが増す
- キャッチを変えたい場合 → 候補③「受注してから払うをやめた」系のシンプルな入りも選べる
Vault根拠（出典・最重要）
根拠強度: 中（FSマニュアルにFS報酬設計の明文あり。「なぜその設計にしたか」の理由はClaudeが補完）
ソース種別: E（FSマニュアル・参考程度）+ Claude推測の補完あり（設計理由の部分）
主参照ノート:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/reward_FSの報酬 (ソースE) — 「受注できなくても報酬が出る」という設計の事実の出典
Vaultからの引用箇所:
「商談を実施した時点で報酬が確定します。受注に至らなかった場合も支払われます。」
「受注できなくても報酬は出る。商談を実施した時点で報酬が確定します。」
— 21_ナレッジベース/マニュアル_ナレッジ/FS部署/reward_FSの報酬 (ソースE)
着想プロセス（マッピング）:
| 参照した記述 | ソース種別 | ポストの反映先 |
|---|---|---|
| 「受注できなくても、商談1件で報酬が確定する設計」 | E（FSマニュアル） | キャッチ・本文の事実部分 |
| 「なぜその設計にしたか」の理由 | Claude推測補完 | 「受注前提の設計をやめた理由」の部分 |
| 大串の「成果報酬が本業」という事業実態 | B/D（既知の大串情報） | 「成果報酬が本業なのに〜」という逆説 |
投稿案 ⑦：TERASUの商談、自分でやってない
カテゴリ: 事業実況
Vault根拠: Claudeセッションの大串発言（4事業並行の実態）
キャッチコピー候補5つ（推奨は ）
①自分がボトルネックになる前に、手放すものがある。
② TERASUの商談、自分でやってない。
③ 4つの事業を回すために最初に外したもの。
④ 事業をスケールさせるために、最初に設計すべきことがある。
⑤ 「誰がやるか」より「どう設計するか」を先に決める。
本文（コピペ即投稿可）
TERASUの商談、自分でやってない。
外部のメンバーに任せている。
最初からそう決めていたわけじゃない。4つの事業を並行して動かす中で、「自分がいないと止まる部分」を一つずつ外していった結果だ。
自分でやると、自分がボトルネックになる。
仕組みを先に作る方が、事業はスケールする。
「誰がやるか」より「どう設計するか」を先に決める。これが今のうちの基本の動き方だ。
このポストの設計
- 目的: フォロー獲得・拡散（「スケールの設計思想」として共感を引く）
- ターゲット: 複数事業を持つ経営者・一人でやりすぎている経営者
- 意識した3点:
1. 「自分でやってない」という短い事実の開示から入り、「なぜか」に引き込む
2. 「4つの事業を並行」という大串固有の立場を事実として織り込む
3. 「誰がやるか」より「どう設計するか」という言い切りで締め、読後に刺さるフレーズを残す
メディア推奨
- 推奨: なし
- 理由: 短文の事実→理由→哲学の流れで完結する
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 17/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 13/15 |
| 応用例 | 8/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 6/5 |
| 総合 | 90/100 |
添削しやすいポイント
- 「外部のメンバー」をもっと具体化したい場合 → FS担当を外部に置いている実態を入れると事業実況としてリアルになる
- キャッチを変えたい場合 → 候補②「TERASUの商談、自分でやってない」という事実の一行でシンプルに入ることもできる
Vault根拠（出典・最重要）
根拠強度: 中（大串が4事業並行で動いているという事実はB/D種別から確認済み。TERASUの商談を自分でやっていないという事実はFSマニュアルの構成から読み取れる）
ソース種別: B（Claudeセッション大串発言・4事業並行の実態）+ E（FSマニュアル・参考）
着想プロセス（マッピング）:
| 参照した情報 | ソース種別 | ポストの反映先 |
|---|---|---|
| 大串が4事業を並行している実態 | B/D（既知の大串情報） | 「4つの事業を並行」という本文の具体 |
| TERASUにFSという外部商談担当が存在する設計 | E（FSマニュアル） | 「外部のメンバーに任せている」という事実 |
| 「仕組みを先に作る」という経営思想 | Claude推測補完 | 「設計することが先」という締めの哲学 |
投稿案 ⑧：HP制作会社が最初から値引きしてくる時
カテゴリ: 業界批判
Vault根拠: 大串の価値観・業界観察から
キャッチコピー候補5つ（推奨は ）
①HP制作会社が商談の最初から値引きを提案してきたら、2つのことを疑う。
② 「初回半額です」と言ってくるHP制作会社への正直な見方。
③ 最初から値引きをする会社と、しない会社の違い。
④ HP制作で「お値引きします」で始まる商談は要注意だと思ってる。
⑤ 安いHPの落とし穴は、価格以外のところにある。
本文（コピペ即投稿可）
HP制作会社が商談の最初から値引きを提案してきたら、2つのことを疑う。
一つ目、最初から値引きを見込んで高く設定している。
二つ目、その金額で本当に品質が担保されるのか。
「安くします」より「なぜこの金額なのか」を説明できる会社の方が、信頼できると思ってる。
うちは最初から適正価格しか出さない。その代わり、この金額の根拠を説明できる。
値引きをしないのはケチなんじゃなくて、価格に自信があるからだ。
このポストの設計
- 目的: 拡散・DM獲得（「こういう視点でHP会社を選べばいいのか」という気づきを引く）
- ターゲット: HP制作会社を比較検討中の経営者
- 意識した3点:
1. 「最初から値引きを疑う」という業界批判型の逆張りで入る
2. 「2つのこと」という構成で読み進めさせ、うちとの対比で終わらせる
3. 「ケチじゃなくて自信がある」という締めで価格への誇りを断言する
メディア推奨
- 推奨: なし
- 理由: 短文の批判・断定型はテキストで完結する
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 17/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 12/15 |
| 応用例 | 8/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 7/5 |
| 総合 | 90/100 |
添削しやすいポイント
- 競合他社への配慮を変えたい場合 → 「疑う」という強い言葉を「確認する」に変えることでトーンを調整できる
- 「価格に自信がある」をもっと具体化したい場合 → 「修正無制限・サーバー込みでこの価格」という根拠を添えると更に強くなる
Vault根拠（出典・最重要）
Vault根拠不足（根拠強度：弱）：このポストの主張は大串の生の言葉ソース（A/B/C/D）に明確な出典なし。
「値引きをしない」「価格の根拠を説明できる」という設計思想はFSマニュアルから読み取れるが、「他社の値引きへの見方」という主張はClaude推測の部分が多い。大串の意図と乖離している可能性あり。要確認。
投稿案 ⑨：ツリー「HP商談で最初にやること」
カテゴリ: 商談ノウハウ（ツリー型）
Vault根拠: 21_ナレッジベース/マニュアル_ナレッジ/FS部署/script2_スクリプトPtn②（数値型）
キャッチコピー候補5つ（推奨は ）
①HPの商談で、HPの説明をすぐしない。
② 商談の最初に「計算」をする理由。
③ HP制作の商談で一番最初にやることを教える。（続く↓）
④ 「HPを作りましょう」ではなく、うちはここから始める。
⑤ TERASUの商談で一番最初にやること。
本文（コピペ即投稿可）
【1本目】
HPの商談で、HPの説明をすぐしない。
最初にやることがある。（続く↓）
【2本目】
HP商談の最初にやるのは、相手の現状数値のヒアリングだ。
・月のアクセス数
・月の問い合わせ件数
・成約率
・平均単価
この4つが揃うと、HP改善でいくら売上が増えるか計算できる。
月1,000人来て問い合わせ率が1%なら10件。これが2%になれば20件、成約率20%・単価30万なら月180万の差だ。
「HPを作りましょう」ではなく「この計算、一緒にやってみませんか？」から商談を始める。
提案はその後だ。
このポストの設計
- 目的: 保存・拡散（ノウハウ系ツリーは保存されやすい）
- ターゲット: HP制作を営業している人・HP発注を検討中の経営者
- 意識した3点:
1. ツリー1本目で「最初にやることがある」という引きを作り、2本目で展開する
2. 4つの数値ヒアリング項目を箇条書きで見せ、保存したくなる構成にする
3. 「計算→提案はその後」というシーケンスを断言で締める
メディア推奨
- 推奨: なし
- 理由: ツリー型テキストで完結する
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 18/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 14/15 |
| 応用例 | 9/10 |
| 締め | 9/10 |
| 重複排除 | 4/5 |
| 浮く一文 | 5/5 |
| 実績データ | 5/5 |
| 総合 | 91/100 |
添削しやすいポイント
- ②とテーマが近い点について → ②はミドル単体投稿・⑨はツリー型。同日投稿する場合は片方だけ選ぶことを推奨
- 計算例の数字を変えたい場合 → 「月1,000人・単価30万」を実際の典型的なクライアント像に合わせて変更可
Vault根拠（出典・最重要）
根拠強度: 中（数値型スクリプトの手法に明確な記述あり）
ソース種別: E（FSマニュアル・参考程度）
主参照ノート:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/script2_スクリプトPtn②（数値型） (ソースE) — 4つの数値ヒアリング・ROI計算の手法の出典
Vaultからの引用箇所:
「月間アクセス数・月間問い合わせ数・問い合わせ率・成約率・平均単価。この項目のヒアリング記録をそのまま手元で使う。」
「HP改善して、これが1%上がったとします。月◯人のアクセスに対して1%増えると、月◯件の問い合わせが増える計算になります。」
— 21_ナレッジベース/マニュアル_ナレッジ/FS部署/script2_スクリプトPtn②（数値型） (ソースE)
投稿案 ⑩：コンペに勝つのは全員に90点を出した人じゃない
カテゴリ: マインド
Vault根拠: 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案
キャッチコピー候補5つ（推奨は ）
①コンペに勝つのは、全員に90点を出した人じゃない。
② 全員に同じ提案をしている、が一番もったいない。
③ 「この会社の100点」を出せるかどうかで、受注率が変わる。
④ 提案の質を上げるより先に、やめた方がいいことがある。
⑤ TERASUで一番大事にしていること、1つだけ言う。
本文（コピペ即投稿可）
コンペに勝つのは、全員に90点を出した人じゃない。
その会社にとっての100点を出した人だ。
予算がない会社には初期費用を下げて提案する。
月額を嫌う会社には買い切りで出す。
要件が大きい会社には高く積み上げて提案する。
全員に同じものを出す方が楽だし、準備も少ない。
でも、それでコンペに勝てるほど、競合は少なくない。
「何がネックですか？」を聞いて、そこだけ解消した形を出す。それだけで、刺さり方が変わる。
このポストの設計
- 目的: 拡散・フォロー獲得（「そうか、全員同じじゃダメなのか」という気づき）
- ターゲット: 営業担当・提案活動をしている経営者全般
- 意識した3点:
1. 「全員に90点」vs「1社に100点」という対比構造でキャッチする
2. TERASUの実際のカスタマイズパターン（予算なし/月額嫌/要件大）を具体例として入れる
3. 「何がネックですか？」という実際のセリフで締め、明日から使えるフレーズを残す
メディア推奨
- 推奨: なし
- 理由: 構造が明快で、テキストで読み切れる長さ
100点採点
| 項目 | 点 |
|---|---|
| キャッチ | 17/20 |
| 一貫性 | 14/15 |
| 面白さ | 13/15 |
| 学び | 13/15 |
| 応用例 | 9/10 |
| 締め | 9/10 |
| 重複排除 | 5/5 |
| 浮く一文 | 5/5 |
| 実績データ | 5/5 |
| 総合 | 90/100 |
添削しやすいポイント
- 「90点」「100点」の表現が気になる場合 → 「全員に同じ提案/相手に合わせた提案」というシンプルな対比に変えることもできる
- 具体例を増やしたい場合 → 「速納期を求める会社には特急対応を乗せる」など実態に合わせて追加可
Vault根拠（出典・最重要）
Vault根拠不足（根拠強度：弱）：「全員に90点ではなく1社に100点」という表現はClaude構成。FSマニュアルの「パッケージ1本だと全員に90点の提案になる。コンペで勝つのは『その会社にとっての100点』を出した競合です」という記述から着想しているが、大串本人がこの言い回しをした記録はない。大串の意図と乖離している可能性あり。
参考にしたFSマニュアルの記述:
「パッケージ1本だと『全員に90点』の提案になります。でもコンペで勝つのは『その会社にとっての100点』を出した競合です。相手が本当に求めているものを商談で掴み、それに合わせて形を変える。これが受注率を上げる一番の近道です。」
— 21_ナレッジベース/マニュアル_ナレッジ/FS部署/custom_プランのカスタマイズ提案 (ソースE)
大串が選定後にやること
- [ ] 投稿からベスト3を選ぶ（番号で指示ください・例：①④⑥）
- [ ] ②と⑨はテーマが近いため、同日は片方のみ推奨
- [ ] 朝・昼・夜の3時間帯に分散投稿
- [ ] 投稿後、34_マーケティング部/X運用_数値管理シート に記録
大串が添削する時の言い方例（ラリー最小化）
- 「①のキャッチを候補③に変えて」
- 「②の数字を実際のクライアント像に合わせて修正して」
- 「⑥の設計理由にもっと実体験を入れて」
- 「③と⑦で行く、残りはボツ」
今回の生成について（重要）
Slack writing_hand：0件・Daily大串発言：0件 という状況での生成です。
今回の10本は主にFS商談マニュアル（ソースE・参考程度）を素材にしています。根拠強度「弱」が⑤⑧⑩の3本あります。これらは特に「大串の言葉じゃない」と感じる可能性が高いため、優先的にレビューしてください。
大串の生の言葉が増えるほど投稿の質が上がります。気づき・判断・出来事をSlackの :writing_hand: で投入いただくか、Claudeとのセッションで語ってもらうことで次回の精度が上がります。
生成情報
- 生成日時: 2026-08-04
- 参照ノート数: 4（FSマニュアル4ファイル）
- 生の言葉ソース（A/B/C）: 0件（今回は未使用）
- イベント指定: なし