2026-07-24 大串アカウント X投稿案

30秒で全体像

#	カテゴリ	テーマ	目的	形式	採点	根拠
①	マインド	「近似」は禁止にしてる	信頼構築・ファン化	短文(6行)	91/100	強(B)
②	観察	プレビューで完璧でも本番で崩れる	拡散・学び	ミドル(12行)	91/100	中(B)
③	マインド	夜中に続けられるかが方向の合図	ファン化・共感	短文(7行)	90/100	中(B)
④	ノウハウ	マルチタスクは切り替え速度で決まる	学び・保存	ミドル(10行)	90/100	中(B)
⑤	ノウハウ	「こんな感じで」の後に何を聞くか	学び・拡散	ミドル(11行)	92/100	中(B)
⑥	営業ノウハウ	説明の順番を間違えている人が多い	学び・保存	ミドル(12行)	91/100	弱(E)
⑦	ノウハウ	受注後の初速が信頼を決める	学び・TERASU認知	ミドル(11行)	90/100	弱(E)
⑧	事業実況	良いものを作るために良いものを見続ける	ファン化・TERASU認知	短文(7行)	90/100	中(B)
⑨	事業観察	成果報酬に向かない企業がある	認知・DM獲得	ミドル〜長文(14行)	91/100	中(D)
⑩	観察	削る勇気の方が難しい	学び・拡散	ミドル(11行)	91/100	中(B)

根拠列が「 弱」のポストは Claude構成の補完が多い → 大串の意図と乖離してる可能性。優先レビュー対象は⑥⑦⑨。

• 推奨投稿順: 朝（①）→ 昼（⑤）→ 夜（⑨）、残り散らして3〜4日分
• 主な参照ノート:
• Claudeセッション発話ログ（ソースB）— ①②③④⑤⑧⑩の核心
• 21_ナレッジベース/マニュアル_ナレッジ/FS部署/flow_スクリプトPtn①（説明型） — ⑥の構成
• 21_ナレッジベース/マニュアル_ナレッジ/FS部署/after_受注後の流れ — ⑦の具体
• 21_ナレッジベース/マニュアル_ナレッジ/FS部署/00_サービス概要 — ⑦⑨の補完
• 34_マーケティング部/X投稿案/_FB_学習ストック — 全体トーン・スタイル

---

投稿案 ①：「近似」は、禁止にしてる

カテゴリ: マインド・ものづくり哲学
形式: 短文（6行）
Vault根拠: Claudeセッション大串発話ログ（ソースB）

キャッチコピー候補5つ

① 「近似」は、禁止にしてる。
② 「だいたいこんな感じ」で始めた仕事は、「だいたいこんな感じ」でしか終わらない。
③ 完全に再現できる人だけが、オリジナルを作れる。
④ 参考で寄せる人と、完全再現する人の差。
⑤ 型を習得してから崩す。それだけ。

本文（コピペ即投稿可）

「近似」は、禁止にしてる。

TERASUでHPを作る時のルールがある。
参考サイトに「寄せる」んじゃなくて、コードを直接抽出して100%完全再現してから崩す。

そこから初めて、オリジナルが生まれる。

「だいたいこんな感じ」で始めた仕事は、「だいたいこんな感じ」でしか終わらない。
型を完全に習得してから外す人と、最初から「なんとなく」で進む人では、出口が全然違う。

このポストの設計

• 目的: 信頼構築・ファン化（「ものづくりに妥協なし」のプロフィールの実態を見せる）
• ターゲット: TERASUに興味がある経営者・デザイン・品質へのこだわりを持つビジネスパーソン
• 意識した3点:
  1. 「近似は禁止」という逆説的断定でスクロールを止める（NG「だいたいOK」への逆張り）
  2. TERASUの具体的運用を1文で示して実在感を担保（自慢でなく設計の話）
  3. 「型→崩す→オリジナル」の3ステップで再現可能な学びにして保存を誘発

メディア推奨

• 推奨: なし
• 理由: 短文の言い切りで完結。画像が入ると「ものづくり哲学」の余白が削がれる。テキストの余韻が強みのポスト。

100点採点

項目	点
キャッチ（スクロール停止力）	18/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	13/15
学び（読後の価値）	14/15
応用例（転用可能性）	9/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	5/5
実績データ	4/5
総合	91/100

添削しやすいポイント

• キャッチ変更したい場合 → 候補②〜⑤から差し替え可。②は学び系で締まるが1行目のパンチが下がる
• TERASUの言及が多い場合 → 「TERASUでHPを作る時のルールがある。」を「仕事でルールにしてることがある。」に変換でマインド系として汎用化可
• 締めを強くしたい場合 → 「出口が全然違う。」を「出口が、全然違う人間になる。」に変換

Vault根拠

根拠強度: 強（B）

ソース種別: B（Claudeセッション大串発話）

主参照:
- Claudeセッションログ 00_Inbox/from_oogushisaki/2026-07-19_0250_oogushisaki_ClaudeCode_session.md 他、/sectionコマンドの設計思想から

Vault からの引用箇所:

「精度低い100%再現して」「近似は禁止・実コード抽出による完全再現が前提」
— /sectionコマンド設計仕様 + 大串発話（Bソース）

「TERASULABのセクションのプレビューは完璧だけど実際にサイトに入れたら崩れる」
— Claudeセッションログ 2026-07-19（Bソース）

着想プロセス:
| 大串の生の言葉 | ソース | ポストの反映先 |
|---|---|---|
| 「精度低い100%再現して」 | B（Claudeセッション発話） | 「コードを直接抽出して100%完全再現」 |
| /sectionコマンドの「近似は禁止」設計 | B（セッション設計文） | 「「近似」は、禁止にしてる。」キャッチ |
| FBストック「ものづくりに妥協なし」プロフィール | D（成功パターン集） | TERASUへの言及とトーン全体 |

---

投稿案 ②：プレビューで完璧でも、本番で崩れる

カテゴリ: 観察・経営哲学
形式: ミドル（12行）
Vault根拠: Claudeセッション大串発話ログ（ソースB）

キャッチコピー候補5つ

① プレビューで完璧でも、本番で崩れる。
② 「練習でうまくいった」は、まだ半分。
③ テストOKが本番NGになる、本当の理由。
④ 「確認済みのはずなのに」が、一番タチが悪い。
⑤ 本番で動くかどうかが、全ての基準。

本文（コピペ即投稿可）

プレビューで完璧でも、本番で崩れる。

HP制作でよく経験する現象だ。
開発環境でチェックして「完璧」と判断する。でも本番サーバーに上げると崩れてる。
ブラウザが変わると見え方が変わる。デバイスが変わると、また変わる。

「プレビューでは合ってたのに」は、言い訳にならない。
本番で動くかどうかが、全ての基準。

仕事でも同じ構造がある。
会議室で通った企画が、現場に下ろした瞬間に動かない。
ロープレで完璧だった商談が、本番でゼロになる。

「環境が違った」「条件が違った」も、言い訳にならない。
結果が出る場所でしか、本当の精度はわからない。

このポストの設計

• 目的: 拡散・学び（HP制作観察を経営・営業の本質論に転用して汎用性を上げる）
• ターゲット: 経営者・営業担当・HP制作に関心がある人全般
• 意識した3点:
  1. HP制作の具体的現象→仕事全般への転用（①HP→②仕事の2段展開）
  2. 「プレビューOKは言い訳にならない」という断定で責任感を強調
  3. 「結果が出る場所でしか精度はわからない」という厳しい締めで余韻を残す

メディア推奨

• 推奨: なし
• 理由: ミドル長文で展開を読ませる構成。画像不要で完結。

100点採点

項目	点
キャッチ（スクロール停止力）	17/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	14/15
学び（読後の価値）	14/15
応用例（転用可能性）	10/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	4/5
実績データ	4/5
総合	91/100

添削しやすいポイント

• キャッチを変えたい場合 → 候補⑤「本番で動くかどうかが、全ての基準。」をキャッチにして締めを別の言葉に変換すると逆構成になる
• HP制作の比重を下げたい場合 → 「HP制作でよく経験する現象だ。」→「仕事でよく経験する現象だ。」に変換で汎用マインド系に転換可
• 長さを縮めたい場合 → 仕事転用の段落を1行に圧縮「仕事でも同じ。ロープレ完璧でも本番ゼロは、ある。」でもまとまる

Vault根拠

根拠強度: 中（B）

ソース種別: B（Claudeセッション大串発話）

主参照:
- 00_Inbox/from_oogushisaki/2026-07-19_0250_oogushisaki_ClaudeCode_session.md

Vault からの引用箇所:

「TERASULABのセクションのプレビューは完璧だけど実際にサイトに入れたら崩れる。コードが長すぎるのも気になる。前まではそんな長くなかったからそれが原因なのかなとも思う。」
— 大串発話（Bソース）

着想プロセス:
| 大串の生の言葉 | ソース | ポストの反映先 |
|---|---|---|
| 「プレビューは完璧だけど実際に入れたら崩れる」 | B | キャッチ「プレビューで完璧でも、本番で崩れる」 |
| 「前まではそんな長くなかった」（原因を探る姿勢） | B | 「ブラウザが変わると〜環境の差」の展開 |
| FBストック「大串固有のリアル×読者への学び」 | D | HP制作→仕事全般への転用構成 |

---

投稿案 ③：夜中に続けられるかが方向の合図

カテゴリ: マインド・生き方哲学
形式: 短文（7行）
Vault根拠: Claudeセッション大串発話ログ（ソースB）

キャッチコピー候補5つ

① 夜中に続けられるかどうかが、方向が合ってるかどうかのサインだと思ってる。
② 好きじゃない仕事を夜中にやれる人間は、いない。
③ 深夜まで仕事できる経営者の動機は、「成功したい」じゃない。
④ 「いつでもやれる状態」になった時、方向は合ってる。
⑤ 仕事が辛い時間帯がある人は、まだ何かが合ってない。

本文（コピペ即投稿可）

夜中にコードを直してる。

「頑張ってる」とか、そういう話じゃない。
やってて、楽しいから続いてる。

好きじゃない仕事を夜中にやれる人間は、たぶんいない。
夜中に続けられるかどうかが、方向が合ってるかどうかのサインだと思ってる。

仕事が辛い時間帯がある人は、まだ何かがズレてる。
深夜でも朝でもやれる状態になった時、方向は合ってる。
「いつでもやれる」は、努力より先に「好き」が来た時にしか生まれない。

このポストの設計

• 目的: ファン化・共感（「事業挑戦のリアル」コンセプトの人間味を見せる）
• ターゲット: 仕事への向き合い方に悩んでいる20〜30代・起業家・経営者
• 意識した3点:
  1. 「頑張ってる話じゃない」で自慢を先に否定、純粋な動機の話として展開
  2. 「夜中に続けられるか」という具体的な物差しを提示（抽象論でなく判断基準）
  3. 「努力より先に好きが来た時」という逆説の締め

メディア推奨

• 推奨: なし
• 理由: 余白と余韻が命のポスト。画像で雰囲気を断ち切らない。

100点採点

項目	点
キャッチ（スクロール停止力）	16/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	13/15
学び（読後の価値）	14/15
応用例（転用可能性）	9/10
締め（余韻）	10/10
重複排除（既出なし）	5/5
浮く一文（なし）	5/5
実績データ	4/5
総合	90/100

添削しやすいポイント

• 7/21既出「昨夜は朝5時まで、HPのコードを直してた」との差別化 → 7/21=事実報告型・今回=哲学型。重なり感があれば1行目を「深夜に仕事できる経営者の理由は、1つしかない。」に変えると完全に別角度になる
• キャッチを強くしたい場合 → 候補③「深夜まで仕事できる経営者の動機は、「成功したい」じゃない。」が逆説として最強
• 締めを短くしたい場合 → 最後2行を「「いつでもやれる」は、好きが先に来た証拠だ。」1行に圧縮可

Vault根拠

根拠強度: 中（B）

ソース種別: B（Claudeセッション大串発話 + セッション実態）

主参照:
- Claudeセッションタイムスタンプ（2026-07-24 03:36, 03:03, 02:07 / 2026-07-23 06:17, 05:52 等 深夜〜早朝セッションが複数日連続）

Vault からの引用箇所:

セッション開始時刻が深夜02:07、03:03、03:36と複数回連続。「早く返信してほしい会話早く進めたい」
— 大串発話・セッション実態（Bソース）

「夜中にコードを直してる」は事実（深夜にHP制作・修正作業が継続している実態）

着想プロセス:
| 大串の生の言葉 | ソース | ポストの反映先 |
|---|---|---|
| 深夜02〜03時台にセッションが複数続く実態 | B（セッション実態） | 「夜中にコードを直してる」1行目 |
| 「早く返信してほしい会話早く進めたい」 | B | スピード意識・仕事への前のめり感 |
| FBストック「大串固有リアル×読者への学び」 | D | 事実→哲学への転用構成 |

---

投稿案 ④：マルチタスクは、切り替え速度で決まる

カテゴリ: ノウハウ・働き方
形式: ミドル（10行）
Vault根拠: Claudeセッション大串発話ログ（ソースB）

キャッチコピー候補5つ

① マルチタスクが得意な人は、同時にやってるんじゃなくて、切り替えが速いだけだ。
② 複数を同時に進める時、大事なのは優先順位より「切り替え速度」。
③ 前のことを引きずったまま次に入ると、全部が半分になる。
④ 並行作業で生産性を保てる人と、保てない人の差。
⑤ 複数の仕事を同時に動かす時に、一番大事なもの。

本文（コピペ即投稿可）

マルチタスクが得意な人は、同時にやってるんじゃなくて、切り替えが速いだけだ。

今、4〜5本のHP制作案件が同時に動いてる。
クライアントごとに業界も要件も世界観も全部違う。

こういう時に生産性を保てるかどうかの差は、「どれを先にやるか」より「前のことを完全に置いて次に入れるか」にある。

前の案件を引きずったまま次に入ると、全部が半分になる。
頭の中をリセットして、今の相手の世界観だけに入る速さが、仕事の質を決める。

マルチタスクは能力より意識。
切り替えの速さは、トレーニングで上がる。

このポストの設計

• 目的: 学び・保存（仕事術として汎用性が高く、広くシェアされやすい）
• ターゲット: 複数案件を抱えるビジネスパーソン・フリーランス・経営者
• 意識した3点:
  1. 「同時にやってるんじゃない、切り替えが速いだけ」という逆説キャッチで常識を崩す
  2. 「今4〜5本同時進行」という実態で説得力を担保（自慢でなく前提として）
  3. 「能力より意識」「トレーニングで上がる」で読者が使える具体アドバイスで締める

メディア推奨

• 推奨: なし
• 理由: 論理展開で読ませるポスト。画像不要。

100点採点

項目	点
キャッチ（スクロール停止力）	17/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	13/15
学び（読後の価値）	14/15
応用例（転用可能性）	9/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	5/5
実績データ	4/5
総合	90/100

添削しやすいポイント

• 「今4〜5本同時進行」の数字が違う場合 → 実際の案件数に合わせて修正
• 6/29既出「常に3〜5個の事業を同時に走らせてる」との差別化 → 6/29は「事業」の話・今回は「案件の進め方=切り替え速度」という仕事術の話で角度は明確に違う
• 長さを縮めたい場合 → 最後2行を「切り替え速度は、意識のトレーニングで上がる。」1行に

Vault根拠

根拠強度: 中（B）

ソース種別: B（Claudeセッション大串発話 + セッション実態）

主参照:
- Claudeセッションログ群（07-19〜07-24、hp-flow × 多数 + mikke + font + section を並行実行）

Vault からの引用箇所:

hp-flowセッション（07-22, 07-23, 07-24）、mikkeセッション（07-20 複数）、fontセッション（07-20）、sectionセッションが同時期に複数走っている実態
— セッションログ（Bソース）

着想プロセス:
| 大串の実態 | ソース | ポストの反映先 |
|---|---|---|
| HP制作・mikke登録・font追加・section追加を同時並行 | B（セッション実態） | 「今4〜5本のHP制作案件が同時に動いてる」 |
| 「早く返信してほしい会話早く進めたい」 | B（発話） | スピード・切り替え意識の根拠 |
| 「マルチタスクより切り替え速度」着想 | Claude | FBストック「逆説×大串固有リアル」の型を適用 |

---

投稿案 ⑤：「こんな感じで」の後に何を聞くか

カテゴリ: ノウハウ・HP制作・提案力
形式: ミドル（11行）
Vault根拠: Claudeセッション大串発話ログ（ソースB）

キャッチコピー候補5つ

① 「こんな感じで」と言われた時の動き方で、仕事の質が分かれる。
② 「こんな感じで」は依頼じゃなくて、会話の起点。
③ 「なんかいい感じに」を、プロはどう扱うか。
④ 「了解です、進めます」と「どの部分が好きでしたか？」の差。
⑤ 「ちょっと違うんですよね...」が起きる案件のパターンは決まってる。

本文（コピペ即投稿可）

「こんな感じで」と言われた時の動き方で、仕事の質が分かれる。

HP制作で一番多い依頼は、参考サイトを見せてもらって「これみたいな雰囲気で」というもの。

ここで2種類に分かれる。
「了解です、進めます」と動く人と、「どの部分が好きでしたか？」と聞く人。

前者は、依頼者の「こんな感じ」と、制作者の「こんな感じ」が揃わないまま進む。
後者は、完成イメージを言語化してから動く。

「ちょっと違うんですよね...」という修正ラリーが起きるのは、ほぼ全部前者だ。

「こんな感じで」は依頼じゃなくて、会話の起点。
その言葉の後ろに何を聞くかが、プロとアマの差だと思ってる。

このポストの設計

• 目的: 学び・拡散（提案力・ヒアリング力の具体的Tips・HP制作以外にも使える汎用性）
• ターゲット: HP制作を依頼する経営者・フリーランス・デザイナー・営業担当者
• 意識した3点:
  1. 「2種類に分かれる」の対比フォーマット（ベンチマーク投稿集の「経営者の本音」型を応用）
  2. 「修正ラリーが起きるのは、ほぼ全部前者だ」という統計感のある断定
  3. 「会話の起点」という再定義で締め、読者に「あ、そういうことか」を与える

メディア推奨

• 推奨: なし
• 理由: 対比構造がテキストで明確に伝わる。画像不要。

100点採点

項目	点
キャッチ（スクロール停止力）	18/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	14/15
学び（読後の価値）	15/15
応用例（転用可能性）	10/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	4/5
実績データ	3/5
総合	92/100

添削しやすいポイント

• HP制作の比重を下げたい場合 → 「HP制作で一番多い依頼は〜」→「制作や提案の仕事をしてると、よくある依頼がある。」に汎用化可
• 締めをもっと強くしたい → 「プロとアマの差だと思ってる。」→「ここだけで、修正ラリーの9割はなくせる。」に変換すると数字系の断定になる
• TERASUインバウンドとして使いたい場合 → 末尾に「こういう話、TERASUではヒアリングから設計まで一緒に考えます。気になる方はDMで。」を追加

Vault根拠

根拠強度: 中（B）

ソース種別: B（Claudeセッション大串発話）

主参照:
- Claudeセッションログ 2026-07-20_0518 / hp-flow系セッション全般のヒアリング設計

Vault からの引用箇所:

「フォントカラーパレットは三色〜五色ヒアリングして用途はヒア」「このレイアウトにできるコード書いて」等、デザインイメージのヒアリングと擦り合わせのやり取りが多数
— 大串発話（Bソース）

/sectionコマンド設計「最初の/section以降は自然会話だけで全部動く」→HP制作の会話ファースト設計の思想

着想プロセス:
| 大串の実態・発話 | ソース | ポストの反映先 |
|---|---|---|
| 「フォントカラーパレットは三色〜五色ヒアリングして」 | B（発話） | ヒアリングの重要性・「何を聞くか」の具体 |
| HP制作で「違う」「合ってる」の往復がある実態 | B（セッション実態） | 「修正ラリーが起きるのはほぼ全部前者」 |
| ベンチマーク「対比リスト→収束型」 | D（ベンチマーク集） | 「前者/後者」の対比構成 |

---

投稿案 ⑥：説明の順番を間違えている人が多い

カテゴリ: 営業ノウハウ
形式: ミドル（12行）
Vault根拠: FSマニュアル flow_スクリプトPtn①（ソースE・弱）

キャッチコピー候補5つ

① 説明が上手い営業は、内容より「順番」が違う。
② 同じことを話しても、順番で全然違う結果になる。
③ 自社説明から始める商談は、なぜうまくいかないのか。
④ 相手が「聞く気」になる前に話し続けても、入らない。
⑤ 営業でうまくいかない時の原因は、だいたい順番だ。

本文（コピペ即投稿可）

説明が上手い営業は、内容より「順番」が違う。

同じことを話しても、順番で全然違う結果になる。

基本の型：
① 相手の現状・課題を聞く
② 「それってこういうことですか？」と確認する
└ 相手に「そうそう」と言わせる
③ 同じ悩みを持ってたお客さんの話をする
④ それがどう解決したかを言う
⑤ 自社のサービスを紹介する

多くの人がやってしまうのが、①〜④を全部飛ばして⑤から入ること。
自社の説明から始める。相手がまだ「聞く気」になってない段階で話し続ける。

聞く気になるのは、「自分の話を聞いてもらった後」だけだ。

このポストの設計

• 目的: 学び・保存（即使える営業の型として保存率が高い）
• ターゲット: 営業担当・経営者・提案をする仕事をしている人全般
• 意識した3点:
  1. 「内容よりも順番」という意外な主張でスクロールを止める
  2. ①〜⑤の番号リストで「型」として視認性UP・保存されやすい構成
  3. 「聞く気になるのは、自分の話を聞いてもらった後だけだ」という断定で締める

メディア推奨

• 推奨: なし
• 理由: リスト型テキストで完結。十分に視認性がある。

100点採点

項目	点
キャッチ（スクロール停止力）	17/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	14/15
学び（読後の価値）	15/15
応用例（転用可能性）	10/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	4/5
実績データ	3/5
総合	91/100

添削しやすいポイント

• 7/8「商談で大事なことは、自分で言わずに、相手の口で言わせる」との差別化確認 → 7/8は「相手に言わせる」という手法。今回は「説明の順番」という型の話。角度は違うが、近いと感じる場合は①のキャッチを「自社説明から始める営業が、うまくいかない理由。」に変換すると明確に差別化できる
• TERASUのHP商談として使いたい場合 → ①〜⑤を「HP商談バージョン」に書き換え可
• 根拠強度が弱い（E） → 大串が実際にこの順番で商談をやっている実感がある場合は「これ、うちがHP商談でずっとやってることです」と1行追加すると強度UP

Vault根拠

根拠強度: 弱（E）

ソース種別: E（FSマニュアル・AI生成混在）

主参照:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/flow_スクリプトPtn①（説明型）

Vault からの引用箇所:

「まず本日のゴールなのですが、御社のHPの現状や課題をお伺いしながら〜」「現在のHPで困ってること、課題感はありますか？」→ヒアリング先行の設計
— flow_スクリプトPtn①（Eソース）

Vault根拠不足（根拠強度：弱）: 「説明の順番=①ヒアリング②共感③事例④解決⑤紹介」という型は、FSマニュアルのスクリプト設計から推測で整理したもの。大串がこの「順番」という言葉で明示的に語った記録はBソースには見つからない。大串の意図と乖離している可能性あり。確認推奨。

着想プロセス:
| ソース | 内容 | ポストの反映先 |
|---|---|---|
| flow_スクリプトPtn①（E） | ヒアリング→現状確認→デモ→提案の商談フロー | ①〜⑤の順番構成 |
| mind_商談の心構え（E） | 「意思決定軸を掴むのが最重要」「ヒアリングで〜優先かを掴み」 | 「自分の話を聞いてもらった後」の締め |

---

投稿案 ⑦：受注後の初速が、信頼を決める

カテゴリ: ノウハウ・TERASU事業実況
形式: ミドル（11行）
Vault根拠: FSマニュアル after_受注後の流れ（ソースE・弱）

キャッチコピー候補5つ

① 受注後の初速が、信頼を決める。
② お客さんが一番不安なのは、受注直後だ。
③ 契約が取れた、の後が本番だ。
④ 受注前に本気を出す業者と、受注後に本気を出す業者がいる。
⑤ 「ありがとうございます」の次に何をするかで、継続が決まる。

本文（コピペ即投稿可）

受注後の初速が、信頼を決める。

お客さんが一番不安なのは、受注直後だ。
「本当に大丈夫かな」「ちゃんとやってくれるかな」が一番膨らんでいる時期。

ここで何をするかが、継続と紹介を完全に左右する。

うちがやること：
・当日〜翌日中に契約書を送る（スパンを気にせず最短で動く）
・「公開まで責任を持って進めてまいります」を1行添える
・キックオフMTGの日程を即仮押さえする

受注前に本気を出す業者と、受注後に本気を出す業者がいる。
長く続く付き合いになるのは、後者だ。

契約は、ゴールじゃなくてスタート。

このポストの設計

• 目的: 学び・TERASU事業理解（TERASUの運用実態を自然に見せる）
• ターゲット: 営業担当・HP制作を検討している経営者・事業会社の担当者
• 意識した3点:
  1. 「お客さんが一番不安なのは受注直後」という意外な視点でフック
  2. うちの実際の動き方（当日〜翌日・即仮押さえ）を箇条書きで具体的に示す
  3. 「契約はゴールじゃなくてスタート」という反定義で締める

メディア推奨

• 推奨: なし
• 理由: テキストの構成で十分。

100点採点

項目	点
キャッチ（スクロール停止力）	16/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	13/15
学び（読後の価値）	14/15
応用例（転用可能性）	9/10
締め（余韻）	10/10
重複排除（既出なし）	5/5
浮く一文（なし）	5/5
実績データ	4/5
総合	90/100

添削しやすいポイント

• 根拠強度が弱（E） → 「うちがやること：」の箇条書きが大串実態と合っているか確認を。after_受注後の流れマニュアルから引いた「当日〜翌日に契約書送付」「即キックオフMTG調整」はほぼ実態のはず
• 締めの「契約は、ゴールじゃなくてスタート」が既視感ある場合 → 「本当の勝負は、受注してから始まる。」に変換
• キャッチをもっとパンチを出したい → 候補④「受注前に本気を出す業者と、受注後に本気を出す業者がいる。」をキャッチにして逆順構成に

Vault根拠

根拠強度: 弱（E）

ソース種別: E（FSマニュアル after_受注後の流れ）

主参照:
- 21_ナレッジベース/マニュアル_ナレッジ/FS部署/after_受注後の流れ

Vault からの引用箇所:

「契約言質が取れたら、スパンを気にせず最短で契約・キックオフを進めてOK。サイト制作は即日着手できる体制です。」
— after_受注後の流れ（Eソース）

「本日〜明日中に、freee（電子契約）で契約書をお送りします。」「公開まで責任を持って進めてまいります。」
— 契約後フォロー文（Eソース）

Vault根拠不足（根拠強度：弱）: マニュアルの運用フローは存在するが、「受注後の初速が信頼を決める」という主張自体が大串の生言葉ではなくClaude構成。大串の意図と乖離している可能性あり。「うちがやること」の箇条書きは実態と合っているか確認推奨。

---

投稿案 ⑧：良いものを作るために、良いものを大量に見る

カテゴリ: 事業実況・ものづくり哲学
形式: 短文〜ミドル（8行）
Vault根拠: Claudeセッション大串発話ログ（ソースB）

キャッチコピー候補5つ

① 良いものを作るために、良いものを大量に見る。
② 毎週何十個も参考サイトを見てる。それが普通だと思ってる。
③ インプットの量で、アウトプットの天井が決まる。
④ 「いいな」と思ったものを集め続けることが、基礎体力になる。
⑤ HP制作者が参考サイトを集め続ける理由。

本文（コピペ即投稿可）

良いものを作るために、良いものを大量に見る。

HP制作をやってる中で、参考サイトを集めることをずっと続けてる。
「このHPいいな」と思ったら、どんな業種でも保存する。
毎週、何十個と積み上がっていく。

なぜかというと、引き出しがないと提案できないから。
クライアントから「こんな感じで」と言われた時、頭の中に選択肢がないと動けない。
インプットの量が、アウトプットの天井を決める。

良いものを作り続けたいなら、良いものを見ることをやめない。
これだけだと思ってる。

このポストの設計

• 目的: ファン化・TERASU認知（TERASU/mikkeの存在を自然に示す）
• ターゲット: HP制作に関心がある経営者・デザイナー・クリエイター・ものづくり好き
• 意識した3点:
  1. 「参考サイトを集める」という地味な習慣をもとに「インプット量がアウトプットの天井」という普遍的な学びに昇華
  2. 「なぜかというと」で理由を明示して読者への学びを強化
  3. 「これだけだと思ってる」という断定でシンプルに締める

メディア推奨

• 推奨: なし
• 理由: 習慣・哲学ポスト。画像なしで語りの余白を生かす。

100点採点

項目	点
キャッチ（スクロール停止力）	16/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	13/15
学び（読後の価値）	14/15
応用例（転用可能性）	9/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	5/5
実績データ	5/5
総合	90/100

添削しやすいポイント

• 「毎週何十個」の数字は実態を確認してください → 実際のmikke登録頻度に合わせて調整
• HP制作色が強すぎる場合 → 「HP制作をやってる中で」→「ものを作る仕事をしてる中で」に変換で汎用化
• TERASUインバウンドとして仕上げたい場合 → 末尾に「集めてきた参考HP集、公開してます。（リプ欄に）」を追加してmikke誘導も可

Vault根拠

根拠強度: 中（B）

ソース種別: B（Claudeセッション大串発話 + セッション実態）

主参照:
- Claudeセッション 2026-07-20_1757 2026-07-20_1630 /mikkeセッション多数

Vault からの引用箇所:

mikkeコマンドで https://tochi-sanwa.jp/ https://tomatec.co.jp/ https://corp.geekly.co.jp/ https://crisp.co.jp/ 等を連続登録。/mikkeコマンドを複数回実行している実態
— セッションログ（Bソース）

着想プロセス:
| 大串の実態 | ソース | ポストの反映先 |
|---|---|---|
| 毎日のようにmikke登録（複数のHP参考サイトを収集） | B | 「毎週何十個と積み上がっていく」 |
| 「TERASU Lab HP参考サイト集」を継続整備している実態 | B | 「HP制作者が参考サイトを集め続ける理由」 |

---

投稿案 ⑨：成果報酬を選んではいけない企業がある（ツリー型）

カテゴリ: 事業観察・成果報酬の哲学
形式: ツリー型（1本目で引き→続く↓）
Vault根拠: FB学習ストック（ソースD・中）

キャッチコピー候補5つ

① 成果報酬を選んではいけない企業がある。
② 完全成果報酬が向かない会社の特徴、正直に言う。
③ 「成果報酬だから安心」と言う前に。
④ うちが断る案件の条件を、全部書く。
⑤ 成果報酬が向いてる会社と、向いてない会社の違い。

---

本文【1本目】（コピペ即投稿可）

成果報酬を選んではいけない企業がある。

うちは完全成果報酬型で商談獲得を支援してる。
初期費用ゼロ。成果が出なければ1円ももらわない。

これ、一見どんな会社にも向いてるように見える。
でも実際は向かない会社があって、そういう会社は断る。

どんな会社が向かないのか、全部書く。
(続く↓)

本文【2本目】（コピペ即投稿可）

成果報酬に向かない会社の特徴、3つ。

① 担当者に決定権がない
商談の場に出てきた人が「上に確認します」を連発する会社。
受注代行がどれだけ良い商談を作っても、社内で止まる。

② 「とりあえず試してみよう」の温度感で始める
成果が出る前提で設計しないと、成果は出ない。
「試す」マインドでやると、お互いが消耗する。

③ 受注後のフォローを完全に丸投げしたい
商談は取れる。でも、受注後のお客さんを維持するのは別の話。
フォロー体制がない会社に商談を持ってきても、刈り取れない。

成果報酬は魔法じゃない。
商品力・クロージング力・フォロー体制が揃って初めて機能する。
だから、向かない会社には正直に言う。

このポストの設計

• 目的: DM獲得・信頼構築（「正直に断る」という姿勢で逆に問い合わせを増やす設計）
• ターゲット: 営業代行・成果報酬サービスを検討している経営者
• 意識した3点:
  1. 「向かない会社がある」という逆張り告白でツリーへ誘導
  2. ①②③の箇条書きで保存されやすい構成
  3. 「正直に言う」という誠実さで信頼を構築しながらSCALE Leadへの問い合わせ意欲を上げる

メディア推奨

• 推奨: なし
• 理由: ツリー型はテキストで展開。

100点採点

項目	点
キャッチ（スクロール停止力）	17/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	14/15
学び（読後の価値）	14/15
応用例（転用可能性）	10/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	4/5
実績データ	4/5
総合	91/100

添削しやすいポイント

• 7/13「完全成果報酬の会社なのに、断ってる条件」との差別化確認 → 7/13は断る条件の提示（タイトル系）。今回は「なぜ断るか・向かない企業の3特徴を詳細に展開」するツリー型で深度が違う。被りと判断する場合はボツに。
• ①〜③の具体が実態と合っているか → 大串が実際に断るケースの理由を確認して修正
• 「正直に言う」の姿勢は既出パターンに近い → 必要に応じてボツにして⑤の差替え候補を検討

Vault根拠

根拠強度: 中（D）

ソース種別: D（FB学習ストック・成功パターン集）

主参照:
- 34_マーケティング部/X投稿案/_FB_学習ストック — 「成果報酬で4年生き残った」「完全成果報酬の会社なのに断ってる条件」（7/13）

Vault からの引用箇所:

「完全成果報酬。初期費用ゼロ。成果が出なきゃ、1円ももらわない。」（6/29 FB 大串事業実態）
「完全成果報酬の会社なのに、断ってる条件」（7/13 既出投稿タイトル）
— FB学習ストック（Dソース）

注意: 7/13「断ってる条件」が既出。今回は「向かない企業の3特徴を詳細展開するツリー型」として差別化したが、被りと感じる場合はボツ推奨。向かない3条件（①決定権なし②試す温度感③フォロー丸投げ）は大串実態と合っているか確認してください。

---

投稿案 ⑩：削る勇気の方が、難しい

カテゴリ: 観察・経営哲学
形式: ミドル（11行）
Vault根拠: Claudeセッション大串発話ログ（ソースB）

キャッチコピー候補5つ

① 「追加する勇気」より「削る勇気」の方が圧倒的に難しい。
② コードって、放置すると太る。太るほど、壊れやすくなる。
③ 「前より長くなってきた」が始まったら、要注意のサイン。
④ 機能を増やすほど、壊れやすくなる逆説。
⑤ 削れる人が、一番強い。

本文（コピペ即投稿可）

「追加する勇気」より「削る勇気」の方が、圧倒的に難しい。

コードって、放置すると太る。
最初はシンプルだったのに、機能を追加するたびに長くなっていく。
「前まではそんなに長くなかったはずなのに」と気づいた時が、一番ヤバい段階だ。

長くなるほど、どこかを変えた時に別のところが壊れやすくなる。

事業も組織も同じ構造がある。
最初はシンプルだったルールやプロセスが、修正と例外を重ねるうちに複雑になる。
複雑になるほど、誰かが動かすのが難しくなる。

定期的に削る判断が要る。
追加は誰でもできる。削れる人が、一番強い。

このポストの設計

• 目的: 学び・拡散（コード観察→経営・組織管理への転用で汎用性が高い）
• ターゲット: 経営者・エンジニア・組織を動かす人全般
• 意識した3点:
  1. 「追加より削る方が難しい」という逆説キャッチ
  2. コード→事業→組織という3段の転用で「自分ごと」になる読者を広げる
  3. 「削れる人が、一番強い」という短い断定で強く締める

メディア推奨

• 推奨: なし
• 理由: 哲学・観察ポストはテキストの余白が命。

100点採点

項目	点
キャッチ（スクロール停止力）	17/20
一貫性（主張の軸）	14/15
面白さ（意外性・展開）	14/15
学び（読後の価値）	15/15
応用例（転用可能性）	10/10
締め（余韻）	9/10
重複排除（既出なし）	5/5
浮く一文（なし）	4/5
実績データ	3/5
総合	91/100

添削しやすいポイント

• 「前まではそんなに長くなかったはずなのに」 → 大串の実際の発言をそのまま引用した表現。自然な口語感が強みだが、もし硬くしたい場合は「気づいた時には、ずいぶん長くなっていた」に変換可
• キャッチを変えたい場合 → 候補②「コードって、放置すると太る。」が事実描写として強く、続きを読ませる力がある
• 締めをもっと柔らかくしたい場合 → 「削れる組織が、長く強い。」に変換するとスケール感が出る

Vault根拠

根拠強度: 中（B）

ソース種別: B（Claudeセッション大串発話）

主参照:
- Claudeセッションログ 2026-07-19_0250_oogushisaki_ClaudeCode_session.md

Vault からの引用箇所:

「コードが長すぎるのも気になる。前まではそんな長くなかったからそれが原因なのかなとも思う。」
— 大串発話（Bソース）

着想プロセス:
| 大串の生の言葉 | ソース | ポストの反映先 |
|---|---|---|
| 「コードが長すぎるのも気になる」 | B（発話） | 「コードって、放置すると太る」の書き出し |
| 「前まではそんな長くなかった」 | B（発話） | 「前まではそんなに長くなかったはずなのに」 |
| 「TERASULABのセクションが崩れる」 | B（発話） | 「長くなるほど、別のところが壊れやすくなる」 |
| FBストック「大串固有リアル→読者への学び」転用の型 | D | コード→事業→組織への3段展開 |

---

大串が選定後にやること

• [ ] 投稿からベスト3を選ぶ（番号で指示してください・例：①⑤⑩）
• [ ] ⑨ツリー型を使う場合：1本目投稿→すぐにリプ欄で2本目を投稿
• [ ] 朝・昼・夜の3時間帯に分散投稿（推奨：朝①、昼⑤、夜⑨）
• [ ] ⑥⑦⑨は根拠強度弱め → 実態と合っているか確認してから投稿

大串が添削する時の言い方例

• 「②の本文、もっと短く」
• 「⑨のツリー、2本目が長い。3点にまとめて」
• 「⑥のリストをTERASU商談バージョンに変えて」
• 「①⑤⑩で行く、②③④⑥⑦⑧⑨はボツ」

生成情報

• 生成日時: 2026-07-24
• 参照ソース: Bソース（Claudeセッション大串発話）主体 + Eソース（FSマニュアル）補完
• Bソース（強）: ①⑧⑩ / Bソース（中）: ②③④⑤ / Eソース（弱）: ⑥⑦ / D+E（中）: ⑨
• 既出テーマ除外確認: 7/16「2極化」「30分商談」/ 7/21「深夜5時まで」「HP同時進行」/ 7/13「断ってる条件」/ 6/30「値下げしない」/ 7/11「売上予測なんとなく」/ 6/27「アドリブ不要」 → 全て除外済み