S3：発信を自分でコントロールする
声を届ける権利は、最初から自分のものです。
このスキルで手に入るもの
Section titled “このスキルで手に入るもの”今のビジネスに必要な最低限の部分だけ、アルゴリズムを「適量」使いこなし、本当に届けたい顧客層へとアプローチするための発信設計力です。何百万再生を連発するためのSNS裏技ではありません。
S3を終えると、**自分の行動履歴から発信素材が生まれ、設計 → 公開 → 結果回収 → 改善が回り続ける仕組み（content/）**と、自社の提案を訴求するLPを量産し、SNSからLPへ、LPから問い合わせへと集客する体制が手に入ります。S1で作った自分の地図と、S2で決めたターゲットが、ここで初めて「外へ届く声」になります。
なぜ必要なのか
Section titled “なぜ必要なのか”アルゴリズムは表現の自由を無力化している
Section titled “アルゴリズムは表現の自由を無力化している”表現の自由は、日本国憲法で保障された基本的人権です。私たちは自分の考えや専門性を、自由に外へ発信する権利を持っています。
しかしSNSでは、どうでしょうか。
どれだけ質の高いコンテンツを作っても、アルゴリズムが見せないと決めれば誰にも届きません。逆に、アルゴリズムが好む形式に合わせると、本来の表現からどんどん遠ざかっていきます。SNSコンサルティングを受けたことがある方なら、この感覚はよくわかると思います——「投稿数を増やせ」「バズるネタを作れ」「流行に乗れ」と言われるうちに、何のために発信しているのかわからなくなる。
これは、アルゴリズムという巨大な力の前に、私たちの表現の自由が実質的に無力化されている状態です。
迎合するほど、自分の声が消える
Section titled “迎合するほど、自分の声が消える”アルゴリズムに迎合するとはどういうことか。
「再生数が伸びる型」を真似する・バズっているネタを追う・自分の専門分野から外れた「わかりやすいコンテンツ」を量産する——これを続けると、集まってくる視聴者は「そのコンテンツの消費者」であって、「あなたのビジネスの顧客」ではありません。フォロワーが増えても売上につながらない、という現象はここから起きます。
このスキルの核心：声の主権を取り戻す
Section titled “このスキルの核心：声の主権を取り戻す”S3が目指すのは、アルゴリズムを最低限だけ使いこなして、自分の声を届けたい相手に届けることです。
アルゴリズムを完全に無視することはできません。SNSである以上、アルゴリズムは存在します。しかしアルゴリズムの奴隷になる必要もありません。アルゴリズムとの適切な距離感を保ちながら、自分のビジネスに必要な顧客層へ、自分の本来の表現で届ける——これが「声の主権を取り戻す」ということです。
声の主権を保ちながらアルゴリズムに乗るために、以下の公式を使います。
素材（専門分野の中にある、あなたの普通の光景） ×演出（ナレーション・カメラ角度・視点の見せ方） =「行動ではなく、視点が面白い」コンテンツ「ふざけない」が最重要原則です。
ふざけることで広がる視聴者は、ふざけることを求めている視聴者です。突飛な行動・過激な演出は、刺激を求める人を集めます。本当に届けたい相手——「面白い人を探している人」「専門性のある視点を求めている人」——は、刺激ではなく「視点」を求めています。
視聴者の質は、発信のトーンで決まります。普段の仕事・判断・現場の光景が、そのままコンテンツになります。「特別なことをやる」必要はまったくありません。
つまり、現代のSNS攻略で最も大事なことは、次の3つです。
- できる限り厳選された視聴者に届ける
- 自分の仕事や普段の行動の中で、最も伝えるべきことを伝える
- 相手の行動を引き出す形で伝える
数を取りにいくのではなく、届けたい相手に、いまの自分の仕事から出てきた一番大事なことを、次の行動につながる形で渡す。これが、S3におけるSNS発信の基本姿勢です。
【NG例】流行りのネタを真似して、専門外の「ウケそうな動画」を投稿する→ 刺激を求める消費者が集まる → フォロワーは増えても顧客にならない
【OK例】「原価率を見直して、メニューを1品外すことにした」という今日の判断をそのまま見せる→ 専門性のある視点を求める人に届く → 「この人に相談したい」という行動につながる「社内の情報を出すのか？」——出します。これからは Build in Public が会社の条件です
Section titled “「社内の情報を出すのか？」——出します。これからは Build in Public が会社の条件です”OK例を見て、「原価率や経営判断まで外に出すのか？」と感じたかもしれません。
しかし、これからの会社に求められるのは透明化です。どのような会社で、誰が、どう考えて運営しているのか——それをオンライン上で共有していくことが、選ばれるための不可欠な条件になります。事業の進捗・意思決定・失敗までを公開しながら作っていくこの手法は Build in Public（ビルド・イン・パブリック） と呼ばれ、海外スタートアップから広まり、日本でも実践する会社が増えています。
背景にあるのは、プロセスエコノミー——完成品（アウトプット）の品質だけでは差がつかなくなった時代に、「作っている過程」そのものが価値になり、人を惹きつけるという考え方です。商品や価格が横並びになるほど、顧客や取引先は「中の人の判断が見える相手」を信頼します。逆に、中が見えない会社は、比較の土俵にすら乗れなくなっていきます。原価率を見直す今日の判断は、隠すべき内部情報ではなく、あなたの専門性と誠実さを伝えるプロセスそのものです。
もちろん、すべてを出す必要はありません。何をどこまで出すかは自分で決めます（STEP 1で作る発信ポリシー）。大事なのは、「隠すのが基本・出すのは例外」から、**「出すのが基本・隠すのは戦略的に選ぶ」**へと前提を切り替えることです。
方法論：行動履歴を発信に変え、SNS → LP → 問い合わせの導線を作る
Section titled “方法論：行動履歴を発信に変え、SNS → LP → 問い合わせの導線を作る”S3では、まず発信を届ける「メディアの構造」を決め、STEP 1で行動履歴が自動で貯まる仕組みを作り、STEP 2で発信すべき業務を選んで1本の設計 → チェック → 公開 → 結果回収まで回し切り、STEP 3でその受け皿となるLP群を量産して「SNS → LP → 問い合わせ」の導線を体制化し、STEP 4でLPを「売れる中身」に仕上げる——という流れです。
このスキルで新しく作るフォルダは content/ です。S1・S2で育ててきた myproject に1つ追加します。
myproject/ ├── inbox/ （S1） ├── ontology/ （S1） │ ├── concepts/ │ ├── people/ │ ├── organizations/ │ └── relations/ ├── actionlog/ （S1） ├── research/ （S2で追加） └── content/ ← S3で追加：発信の企画書（企画ごとのフォルダ）の置き場Tip: フォルダ名は「半角英数の短い単語」にする S1・S2と同じ原則。
contentは「発信するもの・した記録」の置き場。1本の発信 = 1フォルダで貯めていくと、AI-Agentに「直近の発信を横断分析して」と指示できるようになる。
メディアを選定する
Section titled “メディアを選定する”STEPに入る前に、発信を届けるメディアの構造を決めます。
S3で構築するのは、SNSアカウント1本ではありません。次の3層の導線です。
SNS or 広告（知ってもらう入口） ↓プロモーションWEB（会社の考え方・魅力・利用方法を伝える場所） ↓問い合わせ（予約・相談・購入という行動）SNSは入口にすぎません。投稿で興味を持った人が次に見るのは、あなたの会社が「何を考え、どう運営しているか」が分かる場所——プロモーションWEBです。ここにBuild in Publicの中身（考え方・判断・過程）をダイレクトに置くことで、アルゴリズムに左右されない自分のメディアを持てます。SNSのアカウントは凍結もアルゴリズム変更もありえますが、自分のWEBは誰にも消されません。
そして、この構造はひとりで大量に構築できます。S1のワークで体験したバイブコーディング——企画書MDを作り、AI-AgentにWEBページを生成させる型——を使えば、LP（ランディングページ）を必要なだけ自動生成できます。サービス別・ターゲット別・地域別のLPを何枚も持ち、SNSや広告からそれぞれへ流し込む。かつて制作会社に数十万円を払って1枚作っていたものが、いまは自分の手で量産できる——会社の考え方をダイレクトに伝えるメディア群を、ひとりで持てる時代です。具体的な構築はSTEP 3で行います。
Tip: まず「1本の導線」を通してから量産する 順番が大事。STEP 1〜2で発信サイクルを回し、「SNS → プロモーションWEB → 問い合わせ」の導線をまず1本、最後まで通す。LP群の量産（STEP 3）はそのあと。1本も通っていないのにLPだけ量産すると、誰も来ないページの管理だけが増える。
STEP 1：アクションログを自動で記録する
Section titled “STEP 1：アクションログを自動で記録する”ビジネスSNSで最大の武器になるのは、「自分が毎日実際にやっていること」のデータです。作り話でも理想論でもなく、今日の現場で起きたことそのものが、コンテンツの原石になります。
S1で actionlog/ を作り、行動を記録し始めました。しかし、発信素材として使えるだけの量を貯めるには、「意識して記録する」やり方では続きません。STEP 1の仕事は、記録を意志に頼らず、自動で貯まる仕組みに変えることです。
① エージェントのルールファイルを設計する
Section titled “① エージェントのルールファイルを設計する”ここで、この教科書で初めて登場する道具を解説します——エージェントのルールファイルです。
AI-Agentは、作業フォルダに置かれた特定の名前のMDファイルを、毎回の作業開始時に自動で読み込みます。ここに書いた内容は、あなたが毎回指示しなくても、Agentが守るべきルールとして機能します。
| ファイル名 | 読み込むAgent |
|---|---|
CLAUDE.md | Claude Code |
GEMINI.md | Gemini（Antigravity） |
AGENTS.md | 多くのAgentが共通で参照する標準的な名前 |
これまでS1・S2では、AIへの依頼をその都度プロンプトで出してきました。ルールファイルは、毎回言っていることを仕組みに変える方法です。「作業が終わったらアクションログに記録して」——これを毎回言う代わりに、ルールファイルに一度だけ書いておきます。
（myproject/CLAUDE.md の例）
# myproject 運用ルール
## アクションログの自動記録- 頼まれた作業が完了したら、必ず actionlog/YYYY-MM.md の当日欄に1行追記する- 記録する内容：時刻／何を頼まれたか／何を作ったか・更新したファイル／成果と次にやること- 1作業 = 1行。長文にしない- 日付は必ずシステム日付で確認する（架空の日付を作らない）ルールファイル自体も、AIに作らせて構いません。
（AIへの依頼例）
myproject に、AI-Agent用のルールファイル（CLAUDE.md）を作ってください。
入れたいルール：- 作業が完了するたびに、actionlog/YYYY-MM.md へ1行追記する- 記録項目は「時刻・頼まれたこと・作ったもの/更新したファイル・成果」- 1作業 = 1行で、長文にしない一度設定すれば、AIに資料作成・調査・WEB修正・文章の加筆を頼むたびに、その記録が自動でアクションログへ積み上がります。AIとの共同作業そのものが、行動履歴になります。
Tip: ルールファイルは「毎回言っていること」の昇格先 最初から完璧なルールファイルを書こうとしない。運用しながら「またこの指示を出しているな」と気づいたものを、1行ずつルールへ昇格させていく。S1のワークで学んだ「修正指示は企画書に戻す」と同じ型——ルールファイルは、あなたとAgentの働き方が蓄積される場所になる。
Tip: ルールは短く、数を絞る ルールファイルに何十行も書くと、Agentは守れなくなっていく（人間の新人と同じ）。本当に毎回守ってほしいことだけを短い箇条書きで書き、細かい手順は別のMDに切り出して「〜のときは○○.mdを読む」と参照させる。
② AIを日常の秘書として使い続ける
Section titled “② AIを日常の秘書として使い続ける”仕組みができたら、日々の仕事の中でAIをどんどん使っていきます。「今日の段取りを整理して」「この判断、どう思う？」「このメールの返信を下書きして」——こうした普段の業務でAIと対話を続けるほど、①のルールが働いて、その一つひとつが自動でアクションログに残っていきます。
日常の秘書的な使い方の例：
- 「今日のミーティングのアジェンダを整理して」- 「仕込み量の計算、一緒に確認して」- 「このオーナーへの提案、言い方を変えて」- 「今週やったことを箇条書きでまとめて」意識して記録しようとしなくても、AIとの対話の積み重ねが行動ログになります。これがビジネスSNSにおける最大の武器です——自分の現場から生まれた本物のデータが、コンテンツの素材として蓄積されていくからです。
③ Agentの外で起きた行動も取り込む
Section titled “③ Agentの外で起きた行動も取り込む”ルールファイルが自動で拾えるのは、AIと一緒にやった作業だけです。現場の仕事——仕込み、営業、接客、MTG、外回り——はAgentの外で起きます。これを補うにはGoogleカレンダーが便利です。出社から退社まで、実際にやったことを入力します。予定ではなく「やったこと」を記録することがポイントです。
記録の例：
09:00 - 10:00 仕込み量の確認・AIで今週の発注数を計算10:00 - 11:30 スタッフミーティング・シフト調整12:00 - 13:00 ランチタイム営業・100食対応14:00 - 15:00 原価率の見直し・メニュー1品を来週から外す判断16:00 - 17:00 新規オーナーからの相談対応（電話）細かく書く必要はありません。「何をして・どんな判断をしたか」が1行で伝わればOKです。
GoogleカレンダーをMDファイルと自動連携させれば、この記録も inbox/ に自動で蓄積されます。連携の設定はAIに依頼できます。
myproject/ └── inbox/ ├── 2026-05-26_worklog.md ← 自動取得 ├── 2026-05-27_worklog.md └── 2026-05-28_worklog.md（AIへの依頼例）
「GoogleカレンダーのイベントをMDファイルとしてinbox/フォルダに自動保存する仕組みを作りたいです。Google Apps Script か Make（旧Integromat）で実現する方法を教えてください。」Tip: 自動連携は最初からなくてもいい 連携の構築でつまずいて、記録そのものが始まらないのが一番の損。最初は週1回、カレンダーのスクリーンショットをAIに渡して「今週の行動ログをMDにして inbox/ に保存して」で十分。サイクルが回り始めてから自動化すればよい。
カレンダーと並ぶもう一つの入口が、S1から続けている inbox/ の日記・音声メモです。夜に1日を振り返って話した内容には、「今日やったこと・判断したこと」がそのまま含まれています。①のルールファイルに次のルールを足しておくと、日記を作るたびにアクションログへも自動で転記されます。
（CLAUDE.md に追加するルール）
## inboxの日記からのアクションログ追記- inbox/ に日記・音声メモのMDを生成・保存したら、内容から「やったこと」を抽出し、 actionlog/YYYY-MM.md の当日欄にも追記する- 時刻が分からない行動は概算（「朝」「午後」「夜」など）で構わない- 感想や思考は転記しない。転記するのは行動と判断だけこうしておくと、寝る前に音声メモで1日を話すだけで、日記が inbox/ に残り、同時にその日の行動がアクションログに積み上がります。カレンダー・日記・AIとの共同作業——3つの入口すべてが、意識しなくても actionlog/ に流れ込む状態の完成です。
参考：筆者が実際に使っているアクションログ
運用を続けると、ログの形式は自分の事業に合わせて育っていきます。参考までに、筆者がいま実際に使っている形式を載せておきます。複数のAI-Agent（Claude / Codex / Gemini / Grok）を並行運用しているため、S1の基本形に「Agent（実行主体）」と「使用Token」の列が増えています。
## 2026-07-17（金）
> 稼働: 5h | 主要事業: SOVREN Framework
| 時刻 | Agent | 種別 | 事業 | 内容 | object_id | 使用Token | 成果・メモ ||------|-------|------|------|------|-----------|-----------|-----------|| 09:00-10:00 | 伊藤 | MTG | コンサル | クライアントと月次戦略MTG | `〇〇（人物id）` | — | 次月の施策2本に合意。次回8/15 || 朝 | Claude | 資料作成 | SOVREN Framework | 教科書S3ページの改訂 | `SOVREN_Framework` | 概算30k | Tips・ワーク・レッスンプランを新設。デプロイ未実施 || 午後 | Codex | 管理業務 | 全体 | 受信メールの分類・要対応の抽出 | `automation` | 概算12k | 要対応2件をToDo化、販促10件をアーカイブ || 項目 | 使い方 |
|---|---|
| 時刻 | HH:MM-HH:MM。不明なら 朝 / 午前 / 午後 / 夜 の概算でよい |
| Agent | 実行主体。人間（自分の名前）か、どのAIがやったか |
| 種別 | 思考・資料作成・MTG・インプット・管理業務・開発・発信 など、自分の仕事に合わせた分類 |
| 事業 | どの事業・プロジェクトの作業か。決めた一覧から選ぶ（表記ゆれを防ぐ） |
| 内容 | 30字以内の体言止め。一目で何をしたか分かるように |
| object_id | 関係する人物・組織・概念のOntology ID。ログとOntologyをつなぐ鍵 |
| 使用Token | AIの作業コスト。概算でよい。どのAgentにどれだけ使ったかが月次で見える |
| 成果・メモ | 100字以内・1〜2文。「何が決まったか・何ができたか」＋成果物のパス |
運用の鉄則もルールファイルに書いてあります——1作業 = 1行（試行錯誤の途中経過は書かない）、追記専用（過去の行や他のAgentの行を書き換えない）、未来日付の禁止（日付は必ずシステム日付で確認）。この3つは、複数のAgentが同じログに書き込むようになったとき、ログの信頼性を守る生命線になります。最初からここまで作り込む必要はありません。S1の基本形で始めて、運用しながら列とルールを足していけば十分です。
これで、素材の泉ができました。次のSTEP 2で、ここから「会社として発信すべきもの」を選んでいきます。
STEP 2：Build in Public する業務を選び、発信サイクルを回す
Section titled “STEP 2：Build in Public する業務を選び、発信サイクルを回す”① 週1回、行動履歴を俯瞰して「発信すべき業務」をピックアップする
Section titled “① 週1回、行動履歴を俯瞰して「発信すべき業務」をピックアップする”STEP 2の最初の作業は、Build in Publicをオントロジーベースで行うための設定です。発信ネタを思いつきで探すのではなく、STEP 1で自動的に貯まるようになった行動履歴（actionlog/・inbox/の日記）を1週間単位でAIに俯瞰させ、会社として発信すべき業務内容をピックアップしていきます。これを週1回の定例作業として設定します。
自分ひとりでネタを探すのではなく、AIに俯瞰してもらう理由は客観性です。自分が普段から意識的に行っている仕事をAIに見てもらうことで、客観的な視点から、視聴者に届けるべき瞬間やネタを厳選できます。
大事なのは、「何が面白そうか」だけではありません。その業務を届けることで、視聴者にあなたの会社をどう見てもらいたいのか、どんな印象を持ってもらいたいのかまで分析してもらいます。SNS素材は、単なる作業風景ではなく、「この会社は何を大切にしているのか」を伝える入口です。
たとえば、包丁技が自慢のお店であれば、料理を完成させる瞬間だけでなく、包丁の管理をしている様子を届ける案が出てくるかもしれません。そこには「道具を大切にする」「仕込みの精度を重視する」「見えない準備にこだわる」という印象が含まれます。
AIへの依頼例（週1回の定例）：
この1週間のアクションログと日記を読んで、会社として発信すべき業務や判断を10個ピックアップしてください。
それぞれについて、- どの行動を見せるべきか- 視聴者にどんな印象を持ってもらえるか（会社として何が伝わるか）- どんな人に届きやすいか- 動画や投稿にするときの切り口を整理してください。
※ ontology/concepts/発信ポリシー.md を読み、出せない情報は候補から外してくださいTip: 顔出し・店名出しの範囲を最初に決めておく 発信を始める前に「顔・店名・数字（売上・原価など）・スタッフ・顧客」のどこまで出すかを決め、
ontology/concepts/発信ポリシー.mdとして1枚残しておく。週次のピックアップでAIにこのファイルを一緒に読ませれば、出せない素材が候補に混ざらなくなる。あとから範囲を広げるのは簡単だが、一度出したものは取り消せない。
Tip: 「自分には見せるものがない」と感じたら、それはピックアップ不足 発信素材が無いのではなく、自分にとって当たり前すぎて見えていないだけ——S2の「当たり前を疑う」と同じ構造。AIに「私の行動ログの中で、業界の外の人が聞いたら驚くことはどれか」と逆質問させると、自分では素材だと思っていなかった日常が出てくる。
Tip: 週次の俯瞰も「予定」にして仕組みにする ピックアップは毎週決まった曜日・時間にカレンダーへ入れてしまう。STEP 1で記録を自動化したのと同じで、素材選びも意志に頼らない。慣れてきたら、依頼文そのものを
content/週次ピックアップ.mdなどに保存しておき、毎週AIに同じファイルを実行させるだけにする。
同じ作業で、社内向けの報告書も自動生成できる
会社の中で働いている人にとって、この週次の俯瞰は定例報告の自動生成とまったく同じ作業です。上司やチームへの週報・月報は、「1週間の行動を俯瞰して、伝えるべきことをまとめる」——Build in Publicのピックアップと構造が同じで、違うのは読み手が社外の視聴者か、社内の上司かだけです。
（AIへの依頼例）
この1週間のアクションログと日記を読んで、上司向けの週報を作ってください。
構成：- 今週やったこと（完了した業務と成果）- 進行中の業務と来週の予定- 判断・相談したいこと- 数字で報告できる成果があれば明記
→ YYYY-MM-DD_週報.md として保存（置き場所は inbox/ でも、reports/ を作ってもよい）行動履歴が自動で貯まっていれば、週報のために記憶を掘り起こす時間はゼロになります。発信素材のピックアップと報告書の生成を同じ週次の定例にまとめてしまえば、発信は「そのための作業」ではなく、どのみち必要な報告業務のついでに素材が出てくるという状態になります。
炎上・情報漏洩のリスクもAIに検討させる
Build in Publicには、会社としてのリスク管理が伴います。SNSにどの情報を出してよいのかの判断は、実は難しい問題です——顧客や取引先が特定できる情報、契約に触れる内容、数字の出しすぎ、意図せず誰かを傷つける表現。自分では問題ないと思った投稿が、思わぬ角度から燃えることがあります。
この検討にもAIが使えます。週次ピックアップの依頼に、リスクの観点を組み込みます。
（週次ピックアップの依頼に追加する一文）
ピックアップした各候補について、公開した場合のリスクも検討してください。- 顧客・取引先が特定される情報や、情報漏洩にあたる内容が含まれていないか- 炎上につながりうる表現・数字はないか（批判的に読む人の視点で）- 発信ポリシーに抵触しないか会社に所属している場合は、社内規定（SNSガイドライン・機密情報の定義・就業規則）を読み込ませて、そこに適合する形でセレクションします。規定の文書をMD化して ontology/concepts/ に置き、週次ピックアップで発信ポリシーと一緒に参照させれば、規定に触れる候補は最初から挙がってこない状態になります。
ただし、AIのリスク検討は補助です。公開の最終判断は、必ず自分がします——一度出したものは取り消せない、という発信ポリシーの原則がここでも効きます。
② 企画書で設計し、公開して、結果を戻す
Section titled “② 企画書で設計し、公開して、結果を戻す”ピックアップした候補から1つ選んだら、次は設計です。動画やSNS投稿が意味不明にならないように、AIを使って「この動画で何を視聴者に伝えるのか」を設計します。
選んだ素材は、そのまま撮るだけでは伝わりません。何をしたい動画なのか、どんな手段で見せるのか、途中のどこが面白いのか、最後にどんな結果へ向かうのかを整理しておかないと、視聴者は「結局、何を見せられているのか」が分からなくなります。
そのために、以下の4項目を企画書としてAIと一緒に管理します。これは投稿の価値観を語るためではなく、動画そのものの意味が崩れないようにするための企画書です。
撮影や投稿の前日までに、1本ずつ以下の4項目を決めます。撮影してから考えるのではなく、設計が終わってから作り始めます。
4項目（欲求・手段・過程・結果）
この4項目は、動画が「意味不明」にならないための投稿前チェックリストとして機能させます。主語は常に**演者（動画に出てくる人）**に固定します。演者が何をしたいのか・どうやるのか・どこが山場か・どこへ着地するのかが決まっていれば、視聴者は迷子になりません。
| 項目 | チェックすること | 例 |
|---|---|---|
| 欲求 | 演者が何をしたいのかを明示しているか。欲求が最初に示されていれば、視聴者は安心して見ることができる | 「今日の仕込み量を、勘ではなくAIで決めたい」 |
| 手段 | 演者がどんな方法でそれを達成するのかが明確か | 「予約数・天気・曜日・過去売上をAIに見てもらう」 |
| 過程 | プロセスのどこに面白さがあり、逆にどこに困難があるのかを事前に考えてあるか | 「AIの提案と職人の感覚がズレる場面」 |
| 結果 | 最終的にどういう結末にたどり着くのかを決めてあるか（できれば動画の冒頭で示唆するとよい） | 「廃棄を減らしつつ、売り切れを防ぐ仕込み量に決める」 |
企画書（テンプレート）
作成日：公開予定日：プラットフォーム：□ Reels □ ストーリー □ カルーセル □ X記事 □ その他
---
【欲求】この動画が終わったとき、私は＿＿＿＿している／した。
---
【手段】（2〜3個まで）・・・※ 日常で使うものだけ。新しい道具の「説明動画」にしない。
---
【過程】（3ステップで）1. （スタート直後）2. （中盤）3. （クライマックス）
---
【結果】（1文＋画面で見せるもの）言い切り：画面に出す証拠：□ 数字 □ before/after □ 一言テロップ □ 実物企画書は、content/ に企画ごとのフォルダを作って格納します。フォルダ名は YYYY-MM-DD_タイトル。撮影した動画・画像・キャプション案など、その企画の素材もすべて同じフォルダにまとめます。
content/ └── 2026-07-20_仕込み量をAIで決める/ ├── 企画書.md ← 4項目＋公開後の結果を追記していく ├── キャプション案.md └── img/これは、S1のワークで学んだ「作成前に企画書MDを作り、修正を企画書へ戻す」型と、「プロジェクトごとにフォルダを分ける」原則を、そのまま発信に適用したものです。
Tip: 企画は「1本 = 1フォルダ」で貯める 複数の企画を1つのフォルダに混ぜると、AIが別の企画の素材を参照しやすくなる（S1で学んだ通り）。1本 = 1フォルダにしておけば、公開後の結果も企画書に追記されるので、1フォルダ見ればその企画の設計から結果まで全部わかる。「直近10本の企画書を読んで分析して」という横断依頼もしやすくなる。
Tip: プラットフォームはターゲットがいる場所から逆算する 「流行っているから」でプラットフォームを選ばない。S2で定義したターゲット（
research/analysis/参入戦略.md）が日常的にどこを見ているかで決める。迷ったら、ターゲットに近い実在の数人を思い浮かべて「この人は毎晩何のアプリを開いているか」で考えると、答えは意外と絞れる。
Reels 45〜60秒の基本型
| 秒数 | 内容 |
|---|---|
| 0〜3秒 | 欲求の宣言（「今日、〇〇を決めます」） |
| 3〜40秒 | 過程①②③（手段は自然に映る程度） |
| 40〜60秒 | 結果（数字 or 一言） |
設計が終わったら、撮影前に「4原則」でチェックする
以下の4原則を確認します。
| # | 原則 | 意味 |
|---|---|---|
| A | 5歳児でも楽しめるスタート | 最初の3秒で「誰が・何をしたいか」がわかる。専門用語・前置きなし |
| B | 1本完結・初見でも楽しい | 前回視聴・フォロー不要で、最後まで意味が通る |
| C | ふざけない・日常を新視点で | 普段の仕事そのもの。演技・突飛ネタ・無関係なギャグなし |
| D | 欲求は演者のもの | 視聴者向けネタではなく、あなたが達成したいことが動画の芯 |
品質チェックリスト（撮影前）
- [ ] A：最初の3秒で欲求が伝わる- [ ] B：この1本だけで物語が閉じる- [ ] C：普段と同じ場所・仕事・トーン- [ ] D：欲求は演者本人のゴール（視聴者への説教ではない）品質チェックリスト（編集後）
- [ ] 結果が欲求と一致している（達成した／しなかったがはっきりしている）- [ ] 手段の説明が長すぎない（過程より短い）Tip: 迷ったら「普段の自分」に戻す 4原則のチェックで迷いが出るのは、たいてい素材に演出を盛りすぎたとき。判断基準は1つ——「明日の仕事でも同じことをしているか」。していないなら、それは日常ではなく演技。素材の選び直し（STEP 2①）に戻った方が早い。
Tip: チェックはAIにもかけられる 企画書をAIに読ませて「4原則のどれかに違反していないかチェックして」と依頼すると、自分では気づかない違反——特にD（いつのまにか視聴者への解説になっている）——を拾ってくれる。自分のチェックとAIのチェックの二段構えにすると精度が上がる。
公開したら、結果を戻してAIで発信パターンを改善する
投稿を公開したら、1週間程度たったタイミングで、その結果を同じ企画書に追記します。再生数、保存数、コメント数、プロフィールアクセス、問い合わせ、実際に起きた反応などを残しておくと、AIが「どの設計がどんな結果につながったのか」をより正確に分析できるようになります。
## 公開後の結果
- 公開日：- 1週間後の再生数：- いいね数：- 保存数：- コメント数：- プロフィールアクセス：- 問い合わせ・来店・DMなどの実反応：- 気づいたこと：数字の回収方法には注意点があります。SNSのインサイト（分析画面）からの情報取得は、プラットフォーム側の制限で自動化が難しいパターンが多くあります。おすすめは、インサイト画面のスクリーンショットを撮って、そのままAI-Agentに渡すことです。画像を渡して「この結果を企画書に追記して」と頼めば、数字の読み取りと転記はAgentがやってくれます。
Tip: スクリーンショットは万能の伝達手段 画面に見えているものは、スクリーンショットでそのままAgentに渡せる。SNSのインサイトに限らず、アプリの設定画面・エラー表示・管理画面など、「言葉で説明しにくいもの」は撮って渡すのが最速。アプリケーションの初期設定をAgentにガイドしてもらいながら進めるときも、「いまこの画面。次はどこを押す？」とスクリーンショットを送りながら進めると迷わない。
Tip: 見るべき数字は再生数ではない ビジネス発信のKPIは、保存数・プロフィールアクセス・問い合わせ/来店。再生数は「刺激の量」に反応する数字だが、この3つは「信頼と行動」に反応する数字。再生数が低くても問い合わせが来た投稿は成功、再生数が伸びても何も起きなかった投稿は失敗——この基準を最初に決めておくと、アルゴリズムに引きずり戻されない。
Tip: 結果の追記は「予定」に入れる 公開1週間後の結果回収は、意識だけでは必ず忘れる。公開した日に、1週間後のカレンダーへ「○○の結果を企画書に追記」と予定を入れてしまう。結果が戻らない企画書は、AIにとって「答え合わせのない問題集」になってしまう。
蓄積した企画書と公開後の結果をAIに読ませることで、発信のパターンと改善点を分析できます。設計した時点では良いと思った動画でも、実際の反応を見ると、欲求が弱かったのか、過程が伝わらなかったのか、届けたい視聴者に届かなかったのかが見えてきます。
AIに依頼できること
- 「直近10本の企画書を読んで、欲求と結果がズレていた回を指摘して」- 「視点が面白かった回と面白くなかった回の違いを分析して」- 「再生数は伸びたが問い合わせにつながらなかった投稿の共通点を分析して」- 「保存数が多かった投稿から、次に作るべきテーマを提案して」- 「今週の素材候補を出すから、4項目に落とし込む手伝いをして」- 「キャプションの下書きを作って。欲求1行・結果1行の型で」また、S2で定義したターゲットをAIに渡すことで、より精度の高い設計が可能になります。
ここで最後に大事になるのが、相手の行動を引き出すことです。たとえば自分のお店を利用してもらうという行動を引き出すためには、次の2つが必要です。
- お店やサービスの魅力が伝わること
- 実際に利用可能であることが伝わること
どれだけ魅力が伝わっても、「どこにあるのか」「誰が利用できるのか」「いつ行けるのか」「どう予約するのか」が分からなければ、行動にはつながりません。逆に、利用方法だけを伝えても、魅力が伝わっていなければ動く理由が生まれません。
S2で「誰に届けるか」を定義し、S3で「何を見せ、どう意味が通る動画にするか」を設計することで、視聴者の具体的な行動を引き出す企画を作っていくことができます。
（AIへの依頼例）
「S2で決めた私のターゲットは『横浜エリアの個人経営飲食店オーナー・SNS発信に興味があるがやり方がわからない人』です。今日の素材は〇〇です。このターゲットに魅力が伝わり、かつ実際の問い合わせ・来店・予約につながるように、欲求・手段・過程・結果の4項目で企画を提案してください。」よくあるNGと直し方
| NG | なぜダメか | 直し方 |
|---|---|---|
| いきなり撮影する | 欲求と結果がブレる | 必ず企画書を先に埋める |
| 手段の説明が動画の半分を占める | 過程が楽しくない | 手段は画面に映すだけ。語らない |
| 結果がない | 1本が完結しない | 数字・一言・Yes/Noを必ず入れる |
| 視聴者への解説・説教 | 演者の欲求が消える | 「私は〜した」に書き換える |
| 突飛なネタ・演技 | 原則C違反 | 普段の仕事に戻す |
| 「続きは次回」前提 | 原則B違反 | この1本で決着をつける |
| 再生数だけで一喜一憂する | アルゴリズムに主権を渡している | 保存・プロフィールアクセス・問い合わせで評価する |
STEP 3：自社の提案を大量に展開できる体制を作る
Section titled “STEP 3：自社の提案を大量に展開できる体制を作る”STEP 1〜2で、発信のサイクルが回り始めました。STEP 3では、その受け皿を作ります。「メディアを選定する」で見た3層構造の真ん中——プロモーションWEB（LP）を大量に構築し、SNSからLPへ、LPから問い合わせへと流れる導線を体制化します。使うのは、GitHub と Cloudflare Pages、そしてSTEP 1で作ったルールファイルです。
① 訴求内容を先に定める
Section titled “① 訴求内容を先に定める”LPを作り始める前に、何を・誰に訴求するのかを先に決めます。S2で作った参入戦略・ターゲット定義から、自社の提案（サービス・商品・相談窓口）を「1枚のLPで訴求できる単位」に分解します。1LP = 1訴求です。1枚のLPに複数の提案を詰め込むと、誰向けのページか分からなくなり、行動につながりません。
訴求内容は、新しく発明するものではありません。会社の中に当然あるものです。まず、それをリストに出します。
| 業種 | 訴求の例 |
|---|---|
| 不動産業 | 売り込みたい物件情報。ポータルサイトの掲載枠に頼らなくても、大型マンションの分譲サイトのように1物件ごとに専用LPを作り、写真・間取り・周辺環境・担当者の視点まで、情報をこれでもかと盛り込める |
| 教育業 | クラス・コースごとの詳細な提案やシラバス。パンフレットの数行では載せきれない授業の中身・到達目標・講師の考え方を、1クラス1枚で提示できる |
| 飲食業 | 自慢のメニュー1品の深掘りや、季節イベントの告知。グランドメニューの1行では伝わらない仕込みやこだわりを、1品1枚で語れる |
| イベント業 | 従来は「イベント1本に1枚のLP」が限界だったが、ニーズごとにページを分けられる。同じイベントでも、出演者の固定ファン向け・初参加者向け・企業協賛向けと、切り口別の専用ページを持てる。演者ごとのファンページを用意するなど、多様なマーケティング戦略が可能になる |
これまでは、こうした細かな訴求は「1つの公式サイト」か「プラットフォームの掲載枠」に押し込むしかありませんでした。制作コストがゼロに近づいたことで、今までやりたくてもできなかった粒度の訴求が可能になります。
（AIへの依頼例）
research/analysis/参入戦略.md とアクションプラン.md を読んで、自社の提案を「1枚のLPで訴求できる単位」に分解し、訴求リストを content/訴求リスト.md に作ってください。
各訴求について：- 誰に向けたページか（ターゲット）- 何を提案するか（サービス・商品・相談窓口）- 訪問者に取ってほしい行動（問い合わせ・予約・資料請求）この訴求リストが、LP量産の設計図になります。
② 企画書を磨き、LPを制作して、公開をキックする
Section titled “② 企画書を磨き、LPを制作して、公開をキックする”LPの制作は、S1のワークで学んだバイブコーディングの型そのままです。ただし、制作を自動化はしません。流れは3段階です。
- 企画書を徹底的に修正する — 訴求ごとにLPの企画書を作り、全文を読んで、違和感を残さず直し切ります。S1で学んだ通り、ここで手を抜くと成果物の修正で何倍も時間がかかります。LPの品質は、この段階でほぼ決まります。
- 企画書をベースに制作を依頼する — 「この企画書をベースにLPを制作してください。企画書に書いていない要素は追加しないでください」と依頼します。
- 納得したら、公開をキックする — できたLPを確認し、直した内容と理由を企画書へ追記します（S1と同じ型）。納得のいくLPになったら「公開して」——GitHubへのプッシュで、Cloudflare Pagesが自動で本番に反映します。
公開に使うサービスは2つです。GitHub（作ったコードをネット上に保管する倉庫）と Cloudflare Pages（GitHubのコードを公開WEBページとして配信するサービス。どちらも無料枠あり）。両者を連携させると、GitHubへプッシュ（保存）するたびに、Cloudflare Pagesが自動で本番ページを更新してくれます。初期設定は一度だけ——Agentにガイドしてもらいながら進めます（画面のスクリーンショットを送りながら進めると迷いません）。
設定が済んだら、ルールファイルに次を追加します。
（CLAUDE.md に追加するルール）
## LPの制作・公開- LPの制作は、「企画書をベースに制作して」と依頼されたときだけ行う （企画書ができても、勝手に作り始めない）- 企画書に書いていない要素は追加しない- すべてのページに、メタタグ（title・description・OGP）と Google Analytics（GA4）の計測タグを必ず入れる- 「公開して」と指示されたら、GitHubへプッシュする（Cloudflare Pagesが自動で公開に同期）これで、「訴求を決める → 企画書を磨く → 制作 → 納得 → 公開をキック」が1つの流れになります。自動なのは、公開の裏側（プッシュすれば数分で本番反映）とタグの付与だけ。制作と公開の引き金は、常に自分が引きます——S1で学んだ「AIは手動でキックするのが基本」の原則は、量産体制になっても変わりません。メタタグ（検索結果やSNSでの見え方を決める情報）とGA4のタグ（誰がどのページを見たかの計測）を自動付与にしておくのが肝です。あとから全ページに手作業で入れて回るのは、枚数が増えるほど現実的でなくなります。
Tip: 「デプロイして」「キックして」——エンジニアの言葉がそのまま通じる デプロイ（作ったものを本番に反映して公開する）、プッシュ（GitHubへ保存を送る）、キック（処理を起動する）——ソフトウェア開発の現場で使われてきた言葉は、Agentにそのまま通じる。厳密に覚える必要はないが、この2〜3個の動詞を使えると指示が短く正確になる。「デプロイして」の一言でLPが世界に公開される頃には、エンジニアの開発フローがあなたの日常業務の一部になっている——これもS3で手に入る副産物。
Tip: 公開フォルダに機密を混ぜない GitHubに置くのは「そのLPの公開用ファイルだけ」。財務データ・顧客リスト・Ontologyの中身を同じフォルダに入れない。LPプロジェクトは
myprojectの外に独立したフォルダとして作り、リポジトリも分ける。発信ポリシーと同じで、一度ネットに出たものは取り消せない。
Tip: リポジトリはPrivate、公開はCloudflare側だけ GitHubのリポジトリは非公開（Private）にしておき、世界に見せる窓口はCloudflare Pagesが配信するページだけにする。コードや作業履歴まで公開する必要はない。
③ SNS投稿からLPへ流す
Section titled “③ SNS投稿からLPへ流す”導線の最後の接続です。単位はLP1枚。content/ の企画フォルダにあるLPの企画書を1つ読ませ、そこに適合するネタをアクションログから選定させ、SNS動画や記事を構築してもらいます。
（AIへの依頼例）
content/2026-07-20_〇〇/企画書.md（LPの企画書）を読んでください。そのうえで、直近のアクションログから、このLPの訴求に最も適合するネタを選定し、SNS動画（または記事）の企画を作ってください。
- 選んだ素材と、この訴求に合う理由- 欲求・手段・過程・結果の4項目（STEP 2②の企画書の型で）- 投稿からこのLPへ誘導する一言（キャプション末尾・プロフィールの案内文）こうすると、SNS投稿の一つひとつが、生まれた時点で「どのLPへの入口か」を持っています。今週はこのLP、来週はあのLP——と、押し出したい訴求を1枚ずつ選んで回していきます。
SNS動画・投稿で興味を持ってもらい、プロフィールやキャプションのリンクからLPへ、LPで魅力と利用方法を伝えて問い合わせへ——「メディアを選定する」で描いた3層の導線が、ここで実際に動き始めます。GA4のタグが全LPに入っているので、どの流入元からどのLPに人が来て、どこで止まっているかも、数字で追えます。
Tip: LPへのリンクにはUTMパラメータを付ける SNS経由の流入は、GA4では「t.co」（X）のようにプラットフォーム名までしか記録されず、どの投稿から来たかまでは分からない。投稿単位で導線を追うには、リンクの末尾に
?utm_source=x&utm_medium=social&utm_campaign=企画名を付ける（utm_campaignは企画フォルダ名にすると企画書と突き合わせやすい）。ルールファイルに「SNS投稿用のLPリンクには必ずUTMを付ける」と足しておけば、Agentが投稿の企画を作るたびにUTM付きURLまで用意してくれる。
STEP 4：AIで「売れるLP」を作る
Section titled “STEP 4：AIで「売れるLP」を作る”STEP 3で、LPが量産できる体制はできました。STEP 4は中身の話です——AIで作ったLPが、実際に問い合わせを生むかどうかは、ここで決まります。
最重要原則：リアル（実体）を提示する
Section titled “最重要原則：リアル（実体）を提示する”ユーザーは、AI生成のLPに慣れきっています。きれいなだけで内容のない、提案だけのコンテンツは秒で離脱されます。
だからこそ、ファーストビューには必ず「実体を持つサービスなのだ」と分かる要素を盛り込みます。実際の店舗・現場の写真、働いている自分やスタッフの姿、実在の住所と営業時間。現代のネットマーケティングでは、「実際に店舗で運営している」ということが、何よりの差別化になる——誰でもそれらしいページを量産できる時代になったからこそ、実体の証明が価値を持つのです。
そして、その証拠はすでに手元にあります。STEP 1〜2で貯めてきた行動履歴と発信素材——現場の写真、今日の判断、実際の数字——が、そのまま「実体の証明」になります。メインビジュアルにAI生成画像を使わず、自分の現場を使う。これはS3全体で貫いてきた「日常をそのまま見せる」原則の、LP版です。
デザインには、こだわりすぎない
Section titled “デザインには、こだわりすぎない”もう1つ、逆方向の原則です。ネット上には、AI-Agentに読み込ませるデザイン用の「固有スキル」（デザインテンプレート・スタイル指定のプログラム）が大量に出回っています。しかし、WEBデザインを生業にしているのでなければ、細部のクオリティを徹底的に追い込む必要はありません。
責任を持つべきは、訴求の中身です。ブログを書くような感覚で、労力は企画書——誰に何を伝え、どう動いてもらうか——に集中させ、デザインは「あまりに微妙なところだけ直す」程度にとどめます。訪問者が離脱するのは、デザインが素朴だからではなく、中身に実体がないからです。
固有スキルの入れすぎは、むしろおすすめできません。Agent自体の素のデザイン能力はどんどん上がっていくため、作り込んだデザイン指定はあっという間に陳腐化します。素のAgentに任せて、上がり続ける標準品質にそのまま乗る——それが量産体制では一番効率的です。
売れるLPの鉄板8要素
Section titled “売れるLPの鉄板8要素”LPには、ユーザーの悩みに共感し、解決策（商品・サービス）を提示して、最終的な行動（購入・申し込み）へとスムーズに誘導する一連のストーリーを盛り込みます。成果を最大化するための鉄板要素は8つです。
1. ファーストビュー（最重要）
ページを開いて最初に目に入る画面です。ユーザーは3秒で離脱を判断するため、詰め込みすぎずに以下を配置します。
- キャッチコピー：「誰の」「どんな悩み」を解決し、「どんな未来」が手に入るかを一言で提示
- アイキャッチ画像/動画：ターゲットの理想の姿や、実際の使用感を直感的に伝えるビジュアル（ここに実体を入れる——自分の店・現場・顔）
- CTA（行動喚起）ボタン：「資料請求はこちら」「無料体験に申し込む」など、起こしてほしいアクション
- 実績・権威性：「満足度〇〇％」「顧客数〇万人」など、一目でわかる数値
2. 悩みへの共感
「まさに自分のことだ」と思わせることで、読み進める理由を作ります。ターゲットが日頃抱えているストレスや課題を、箇条書きで具体的にリストアップします。
3. 解決策の提示
提示した悩みを解決できる商品・サービスが何であるかを明示します。
4. ベネフィットの提示
商品の機能（スペック）ではなく、それを使うことで「ユーザーがどんな良い未来を得られるか」を伝えます。
5. 強み・特徴（他社との違い）
数ある選択肢の中で「なぜこの商品を選ぶべきなのか」、具体的な根拠を挙げます。独自のノウハウや競合比較の表などで明確に差別化します——ここでS2の research/competitors/ がそのまま使えます。競合を1社1ファイルで貯めてきた人は、AIに読ませるだけで比較表が出てきます。
6. お客様の声・実績
客観的な事実や第三者の声（口コミ）を載せ、信頼感を高めます。導入前後の変化（ビフォーアフター）と、顔写真や具体的な数字をセットで掲載すると説得力が増します。
7. オファー（特典・保証）
ユーザーの「損をしたくない」「失敗したくない」という不安を取り除き、背中を押す提案をします。初回限定価格、全額返金保証、期間限定プレゼント、無料相談など。
ここはAI時代に特に強くなった要素です。AI-Agentを使えば、特典（業種別チェックリストPDF・診断シート・小冊子・テンプレート集）を、ほぼゼロコストで内製できます。かつて「特典を作る労力」がボトルネックだったオファー設計が、いまは訴求ごとに専用特典を付けられるようになりました。
8. よくある質問・導入の流れ
行動を起こす前の最後の不安を解消し、申し込みまでのハードルを下げます。
- よくある質問：想定される疑問に事前に回答しておく
- 導入の流れ：問い合わせからサービス開始までを3〜4ステップで解説
8要素を企画書に落とし込む
Section titled “8要素を企画書に落とし込む”この8要素を、STEP 3②のLP企画書のテンプレートにしてしまいます。
（AIへの依頼例）
content/訴求リスト.md の「〇〇」について、LP企画書を作ってください。以下の8要素で構成します。
1. ファーストビュー：キャッチコピー案3本／実体が伝わる写真の指定／CTA／実績数値2. 悩みへの共感：ターゲットの悩みを5つ（S2のターゲット定義と research/ を参照）3. 解決策の提示4. ベネフィット5. 強み・他社との違い（research/competitors/ を読んで比較表を作る）6. お客様の声・実績（実在するものだけを使う。架空の声・数字を作らない）7. オファー案：AI-Agentで内製できる特典を3案8. よくある質問・導入の流れ
メインビジュアルは私の現場の写真を使う。AI生成画像を使わない。スマホで見ることを前提に設計する（閲覧の9割以上はスマホ）。企画書に書いていない要素は追加しない。Tip: 実績・お客様の声は、実在するものだけを使う AIに8要素で作らせると、「満足度98%」「お客様の声」をもっともらしく捏造してくることがある。架空の実績は景品表示法などの法的リスクである以前に、「リアルの提示」というSTEP 4の原則の真逆。実績がまだ無いなら無いでよい——その枠には、行動履歴から出せる本物の数字（「開業10年」「月間仕込み〇食」）や、Build in Publicの発信そのものを置く。
Tip: 最初から「スマホサイト」として設計を依頼する 現代のLP閲覧は9割以上がスマホから。完成後にスマホで見て直すのではなく、企画書の段階から「スマホで見ることを前提に設計する」と書いておき、制作依頼にもスマホファーストを明示する。PCでの見え方は後から整えれば十分。公開後の確認も必ず自分のスマホで行い、ファーストビューに「実体」とCTAが収まっているか、3秒で何のページか分かるかを見る。ズレていたら、直した内容と理由を企画書へ追記する（S1のワークと同じ型）。
問い合わせの受け口を用意し、ゴールまで計測する
Section titled “問い合わせの受け口を用意し、ゴールまで計測する”CTAボタンの先——「問い合わせ」の受け口を用意して、導線は完成します。最初から高機能な仕組みは要りません。
| 受け口 | 特徴 |
|---|---|
| Googleフォーム | 無料・最速。質問項目は企画書からAIに生成させられる |
| LINE公式アカウント | 気軽さ重視の業種（飲食・教室・美容など）に。友だち追加がそのまま見込み客リストになる |
| 予約システム・メール | すでに使っているものがあれば、それでよい。新しく増やさない |
どれを使うにせよ、条件は2つです——LPのCTAからワンタップで到達できること、「送ったら何が起きるか」（返信の目安・次のステップ）が書いてあること。
そして、最後の計測です。GA4は標準では「ページに到達したか」までしか追いません。問い合わせの発生をキーイベントとして設定すると、SNS → LP → 問い合わせの3層すべてが数字でつながります——どの投稿（utm_campaign）が、どのLPを経由して、何件の問い合わせを生んだか。設定は、問い合わせボタンのクリックや送信完了ページの表示をイベントにするだけです。ここもAgentにガイドしてもらいながら進めます。
（AIへの依頼例）
このLPの問い合わせボタンのクリックを、GA4のキーイベントとして設定したいです。GA4の管理画面のどこを操作すればよいか、1ステップずつガイドしてください。いまの画面のスクリーンショットを送りながら進めます。サイクルのまとめ
Section titled “サイクルのまとめ”日々の仕事・判断 ↓行動履歴が自動で貯まる（STEP 1：Agentのルール記録・カレンダー・日記） ↓週1回、AIが「発信すべき業務」をピックアップ（STEP 2①） ↓企画書で1本を設計（STEP 2② → content/ の企画フォルダに保存） ↓4原則でチェック → 撮影・公開 ↓1週間後、結果を企画書に追記 ↓AIで「設計と結果のズレ」を分析 ↓次の1本の設計へ ↓（ループ：content/ が育つほど、設計の精度が上がる）STEP 3でLPの体制ができると、このループに「受け皿」が加わります。
訴求リストを定める（STEP 3① → content/訴求リスト.md） ↓LP企画書（鉄板8要素＝STEP 4）を磨く → 制作を依頼 → 納得したら公開をキック（STEP 3②：プッシュ → Cloudflareが自動反映） ↓LPの企画書を起点に、適合するネタをアクションログから選ぶ（STEP 3③） ↓SNS投稿 → LP → 問い合わせ ↓GA4で導線の数字を確認 → 訴求リストとLPを更新（ループ）自分の行動履歴から発信素材が生まれ、設計 → 公開 → 結果回収 → 改善のサイクルが回り続け、SNS → LP → 問い合わせの導線が動いている状態です。
STEP 1
- エージェントのルールファイル（
CLAUDE.md等）を設置し、アクションログが自動で記録される状態にした - Agentの外の行動（現場仕事・MTG）も、カレンダー・日記から
actionlog/に流れ込むようにした
STEP 2
- 顔出し・店名出しの範囲を発信ポリシーとして決めた
- 週1回、行動履歴をAIに俯瞰させて「発信すべき業務」を10個以上ピックアップする定例を設定した
-
content/フォルダを作り、企画書を使って1本以上設計した - 企画を「1本 = 1フォルダ」（
YYYY-MM-DD_タイトル/企画書.md）で保存した - プラットフォームをS2のターゲットから逆算して選んだ
- 撮影前に4原則チェックリストを使う習慣ができた
- 「ふざけない」原則を守った発信を3本以上続けられた
- 公開後1週間程度の結果を企画書に追記した
- 蓄積した企画書をAIで分析し、改善点を1つ以上見つけた
- 自分の視聴者層（誰が集まっているか）を把握している
STEP 3
- 自社の提案を「1LP = 1訴求」に分解し、
content/訴求リスト.mdを作った - GitHub＋Cloudflare Pagesの連携を設定し、プッシュで自動公開される状態にした
- 企画書を磨く → 制作を依頼 → 納得したら公開をキックする流れと、メタタグ・GA4タグの自動付与をルールファイルに追加した
- LPの企画書を起点にアクションログからネタを選定し、SNS投稿からLPへの導線を1本以上通した
STEP 4
- ファーストビューに「実体」（現場写真・実在の店舗情報）が入ったLPを1枚以上公開した
- 鉄板8要素をLP企画書のテンプレートに組み込んだ
- AI-Agentで内製した特典（チェックリスト・診断シート等）をオファーに付けた
- 実績・お客様の声に架空のものが混ざっていないことを確認した
- 公開したLPをスマホで確認し、修正点を企画書に追記した
- 問い合わせの受け口（フォーム・LINE等）をCTAに接続し、GA4のキーイベントを設定した
ワーク：新しいプロジェクトの売り込みをしてみよう
Section titled “ワーク：新しいプロジェクトの売り込みをしてみよう”S3の仕上げです。STEP 1〜4で作った仕組みを総動員して、新しいプロジェクトを1つ起案し、訴求計画を立て、LPとSNS連携の制作まで——「思いついてから、世の中に売り込むまで」を通しでやります。
手順は5ステップです。
1. プロジェクトを起案する
新商品、新サービス、イベント、キャンペーン——いまの事業の中から「売り込みたいもの」を1つ決めます。STEP 3①で見たとおり、ゼロから発明する必要はありません。会社の中にすでにあるものから選びます。迷ったら、AIに起案させます。
（AIへの依頼例）
ontology/ と research/ と直近のアクションログを読んで、いま売り込む価値のあるプロジェクト（商品・サービス・イベント）の候補を3つ提案してください。それぞれ「誰に・何を・なぜ今なのか」を1行ずつ。2. content/ に専用フォルダを作り、企画書を立てる
このプロジェクト専用のフォルダを content/ に作り、その中に企画書を作るところから始めます。企画書の冒頭に、訴求計画——誰に向けたページか、何を提案するか、訪問者に取ってほしい行動——を書きます。訴求が複数の切り口に分かれるなら（例：イベントの固定ファン向けと初参加者向け）、この段階で分けておきます。
content/ ├── 訴求リスト.md ← このプロジェクトの訴求を1行追記 └── 2026-07-25_夏の新コース/ ← 専用フォルダ（YYYY-MM-DD_プロジェクト名） ├── LP企画書.md ← 2で訴求計画 → 3で8要素に磨く ├── SNS企画書.md ← 5で作成（4項目） └── img/ ← 現場写真などの素材（AIへの依頼例）
content/ に「2026-07-25_夏の新コース」フォルダを作り、LP企画書.md を立ててください。冒頭に訴求計画を書きます：- 誰に向けたページか- 何を提案するか- 訪問者に取ってほしい行動content/訴求リスト.md にも、この訴求を1行追記してください。3. LP企画書を8要素に磨き切る
2で立てたLP企画書を、STEP 4の鉄板8要素で肉付けします——ファーストビューに実体を入れる、実績・声は実在するものだけ、AI-Agentで内製する特典を1つ付ける。そして全文を読み、違和感を残さず直し切ります。LPの品質はここで決まります（STEP 3②）。
4. LPを制作し、公開をキックする
「この企画書をベースにLPを制作してください。企画書に書いていない要素は追加しないでください」と依頼し、できたLPを確認します。直した内容と理由は企画書へ追記。納得したら「公開して」——プッシュでCloudflare Pagesが本番に反映します。公開されたページを、必ず自分のスマホで確認します。
5. SNSと連携させる
STEP 3③の型で、このLP企画書を読ませ、アクションログから適合するネタを選定し、同じフォルダに SNS企画書.md（4項目）を作って公開します。
発信形式のおすすめはショート動画ですが、撮影から編集までをその場でやるのは難しいので、このワークでは**X記事（写真＋文章）**を例にします。現場の写真が数枚あれば、企画書とアクションログを渡すだけで、AIと一緒に記事へ組み立てられます。記事の末尾とプロフィールに、LPへの導線（UTM付きリンク）を張ります。公開したら1週間後のカレンダーに予定を入れ、SNSの結果を企画書へ、LPへの流入をGA4で確認します。
この1周が回ると、プロジェクトの売り込みが——外注も広告代理店もなしに——自分の手の中で完結するようになります。2つ目からは、回っている体制の上に乗るだけです。
Tip: 最初のプロジェクトは小さくていい 大きな新規事業である必要はない。季節メニュー1品、1日イベント、1物件、新コース1本で十分。このワークの目的は「起案 → 訴求 → LP → SNS → 数字の確認」の導線を1周させることであって、初回から売上を立てることではない。小さく1周した体制は、大きな売り込みでもそのまま使える。
ワークの完了目安
- プロジェクトを1つ起案し、
content/に専用フォルダを作って企画書を立てた（訴求リストにも追記） - LP企画書を鉄板8要素に肉付けし、全文を自分で磨き切った
- LPを公開し、スマホでファーストビューの「実体」とCTAを確認した
- このLPに接続したSNS投稿を1本以上公開した（キャプション・プロフィールに導線）
- 1週間後にSNSの結果とGA4の流入を確認し、改善点を企画書に追記した
S3 レッスンプラン例
Section titled “S3 レッスンプラン例”S3を勉強会や授業で扱う場合は、2時間×3回で以下の流れにすると実装しやすいです。
| 回 | 時間 | テーマ | 到達目標 |
|---|---|---|---|
| 1 | 2h | 発信の仕組みを作り、サイクルを回し始める | メディア構造の選定＋STEP 1〜2。エージェントのルールファイル（CLAUDE.md 等）でアクションログの自動記録を設定し、週次ピックアップの定例と content/・発信ポリシーを設置する。1本目を企画書に落とし、4原則チェックと撮影プランまで固めて持ち帰る |
| 2 | 2h | LPの量産体制を作り、売れる中身に仕上げる | STEP 3〜4。訴求リストを定め、GitHub＋Cloudflare Pagesの連携を設定。鉄板8要素をLP企画書のテンプレートに組み込み、企画書を磨く → 制作を依頼 → 納得したら公開をキックする流れとメタタグ・GA4タグの自動付与をルール化して、ファーストビューに「実体」が入った1枚目のLPを公開する |
| 3 | 2h | ワーク：新しいプロジェクトの売り込み | プロジェクトを起案し、content/ に専用フォルダを作って訴求計画とLP企画書を立て、8要素に磨いてLPを公開する。X記事でSNSと連携し、UTM付きリンクでLPへの導線を張る。1週間後の結果確認までを予定化して持ち帰る |
3回が終わった時点で、参加者は「行動履歴が自動で貯まり、AIが発信すべき業務を選び、企画書から発信とLPが生まれ、SNS → LP → 問い合わせの導線が数字で見える」——アルゴリズムに迎合しない発信体制を、自分の事業で持った状態になります。
- 前提となる → S2：情報をまとめて使えるようにする（誰に届けるかが決まって初めて、設計できる）
- 次に学ぶ → S4：ビジネスを多面展開する（発信が確立されると、同業者からの相談＝toBの入口が生まれる）
実践の場
SOVREN Frameworkは無料で公開されている原典です。講師と一緒に自分の事業へ実装したい方のために、横浜で実践教室を開いています。