「Claude Codeに毎回同じ指示をしている」「企画、台本、分析が別々のチャットに散らばっていて、前回の結果が次に生きない」。そんな状態なら、長い万能プロンプトを作る前に、仕事の受け渡しを設計する方が効きます。
この記事では、Claude Codeを使ってInstagram運用の企画担当、台本担当、分析担当、改善担当を作り、1本の企画から次の改善案までつなぐ方法を紹介します。元になった実演動画では、4役の定義ファイル、企画候補、台本の赤ペン、匿名化した投稿データの整理、次の1本で変える要素の選定まで画面で追っています。
先に結論を言うと、AIに投稿を任せ切る方法ではありません。AIは作業を分担し、企画・表現・改善の3か所で人が承認します。投稿公開、外部送信、予約を自動で実行させないのが、この記事の前提です。
「4人のAI」を作る前に、1本の仕事の流れを決める
AIツールを使うと、企画案も台本案もすぐに出ます。それでも運用が重くなるのは、出力の質だけが問題ではありません。今日の企画がどの判断で選ばれたか、台本のどこを直したか、公開後の結果から何を学ぶかが残らないと、次回も一から説明することになります。
必要なのは、ひとつの投稿を「候補を出す→選ぶ→台本を作る→人が直す→公開後に数字を読む→次の1変更を選ぶ」という連続した仕事として扱うことです。4役はこの仕事を切り分けるためのもの。役割を増やすことが目的ではありません。
4役の境界は次のようにします。
| 担当 | 入力 | 成果物 | ここでは止まる |
| Planner | 対象者、発信の柱、過去の投稿結果、今週の目的 | 企画候補と選定理由を含むbrief初稿 | 人の企画承認前 |
| Scriptwriter | 承認済みbrief、話し方、一次情報 | 台本初稿、確認が必要な箇所の一覧 | 人の表現承認前 |
| Analyst | 承認済み台本、匿名化した投稿結果、集計条件 | 事実・仮説・未確認に分けた分析 | 原因の断定前 |
| Improver | 分析と前回の変更履歴 | 次の1本で試す変更案を1つ | 人の改善承認前 |
Plannerが台本まで書き、Scriptwriterが企画を変え、Analystが次の投稿を勝手に作ると、誰の判断で変わったか追えません。担当を分ける利点は、AIを「賢く見せる」ことではなく、変更と承認の責任を見えるようにすることです。
作業フォルダに置く4種類の情報
実演では、デモ用のai-insta-teamフォルダを作り、context、data、runs、.claude/agentsを分けています。名前は自分の仕事に合わせて変えても構いません。ただし、役割の設定、判断材料、1回分の成果物を同じ場所に混ぜない方が確認しやすくなります。
contextには、アカウントの対象者、届ける価値、声のトーン、使ってはいけない表現、商品や特典とのつながりを置きます。ここは毎回コピーして長いチャットへ貼るのではなく、見直した時に更新する共通の基準です。曖昧な「20代女性向け」だけでなく、その人が投稿で何に困っているか、どこまでを動画で解決するかを書きます。
dataには過去投稿の結果を置きます。ここで重要なのは、スクリーンショットやCSVを無造作に入れないことです。対象期間、投稿日時、表示回数、視聴維持、保存、プロフィール遷移など、何をどう数えた数字かを残します。動画のデモでは匿名データを使い、DEMO DATAと明示しています。デモ値を実績として記事や台本へ転用してはいけません。
runsは1回の企画から改善までの作業フォルダです。例えばruns/demo-001/に、企画の初稿、承認済みbrief、台本初稿、赤ペン後の台本、分析、改善案、承認記録を置きます。次の担当はチャット履歴を丸ごと読むのではなく、承認済み成果物を入力にします。却下した案や途中の思いつきを確定情報と混ぜないためです。
.claude/agentsには、Plannerなど各担当の役割を定義します。Claude Codeの公式資料でも、プロジェクト単位のカスタムsubagentを.claude/agents/に置く形が案内されています。ただしツールの仕様は変わる可能性があるため、設定ファイルをそのままコピーする前に公式ドキュメントで現在の書式を確認してください。この記事で変わりにくい核心は、ファイル名ではなく「入力・出力・禁止事項・承認点」の設計です。
最初の指示は「4役を作って」ではなく「設計を見せて」
いきなりエージェント定義を大量に生成させると、役割が重なったまま完成したように見えることがあります。最初は表を作らせ、ファイル作成の前で止めます。実演動画でもこの順番です。
Instagram運用を企画・台本・分析・改善の4役で回すチームを設計してください。
役割は Planner / Scriptwriter / Analyst / Improver です。
各役割について、読む情報、作る成果物、担当外の作業、次の担当へ渡す条件を表にしてください。
企画・表現・改善の3か所では人間の承認を必須にします。
公開、外部送信、投稿予約、SNS API、従量課金APIは使いません。
個人情報、機密情報、数字、引用、権利は人間が確認します。
まず設計だけを提案し、ファイル作成前に止まってください。表が返ってきたら、Plannerが企画を出すだけになっているか、Scriptwriterが承認済みbrief以外から勝手に約束を増やさないか、Analystが数字の原因を断定していないかを見ます。この時点で修正してから定義を作る方が、後から4つのファイルを直すより簡単です。
Plannerは「たくさん出す人」ではなく、選ぶ理由を見えるようにする人
Plannerへ渡すのは、アカウントの対象者、今週の目的、実際の質問、過去投稿の結果です。動画では企画候補7本と最有力1本を出すデモを行っています。ただし、7本という数字が正解ではありません。候補の違いと、なぜ1本を選ぶのかが分かればよいのです。
企画表に最低限ほしいのは、読者の困りごと、動画で渡す完成状態、冒頭で見せる証拠、本人の一次情報が必要な箇所、過去動画との重複、選定理由です。「AIを使ってインスタ運用を効率化」は広すぎます。「毎回同じ指示を書き直している人が、企画と台本を受け渡す2役を作る」なら、視聴者は自分の課題かどうか判断できます。
AIが「これが最も伸びそう」と書いても、その根拠が公開再生数だけなら、需要の方向を示す材料にとどめます。チャンネル固有のクリック率や維持率、LINE反応がなければ、自分の視聴者に刺さるとは断定できません。企画承認では、人が現場の経験や視聴者の生の言葉を足し、約束を狭くします。
そのあと、承認された企画をapproved-brief.mdのような確定ファイルにします。次のScriptwriterには、Plannerの全会話ではなく、この確定briefだけを渡します。ここが「毎回ゼロから説明する状態」を減らす最初のポイントです。
Scriptwriterには「うまい文章」より、約束との一致を求める
Scriptwriterが受け取るのは承認済みbriefです。対象者、困りごと、動画の完成状態、実際に見せる画面、本人の経験、言ってはいけないことを元に台本を作ります。台本の文字数を増やすことが仕事ではありません。冒頭で約束した内容を本編で回収し、視聴者が次の操作まで進める説明になっているかが重要です。
生成された冒頭が「AIが進化してSNS運用が変わりました」のような一般論なら、具体的な画面に置き換えます。今回の動画なら、4役のファイルと企画・台本・分析・改善の成果物を冒頭で見せます。「今日はAIチームを作る」と言いながら、前半がAIの歴史説明ばかりなら、サムネイルと内容の約束がずれます。
また、AIが本人の実績や失敗談を補完したように見せる箇所は危険です。確認できない経験は「一次情報待ち」とし、本人が自分の言葉で埋めます。実際に使った画面と例がないなら、架空の成功数字を載せるのではなく、デモと明記します。読者にとって有益なのは強い断言より、どこで迷い、何を見て直したかです。
2回目の人間承認では、事実・権利・個人情報・言葉・動画の約束・CTAを確認します。見慣れたテンプレ表現が連続していないか、難しいツール用語を説明せずに使っていないかも読み合わせます。承認後の台本を次工程へ渡し、未承認の案は混ぜません。
Analystは数字を「事実・仮説・未確認」に分ける
公開後の数字が出たらAnalystを使います。ただし、1本の再生数だけで「この冒頭が悪かった」「サムネの色が正解」と断定させません。配信面、期間、表示回数、視聴者層が違えば単純比較はできないからです。
最初に、数字の定義と条件を確認します。同じ投稿フォーマットか、同じ期間か、初速と累計を混ぜていないか、計測漏れはないか。小さなサンプルなら結論を出すより、次の比較で何を観測するか決めます。
分析ファイルは3列に分けると読みやすくなります。「事実」には画面や集計から直接確認できたことだけ。「仮説」には、その数字を説明し得る理由。「未確認」には、仮説を判定するために足りないデータを書きます。例えば『再生維持が低い』は事実になり得ますが、『冒頭が原因』はまだ仮説です。冒頭30秒の落ち方や流入元を見て、なお複数の理由が残るなら断定しません。
InstagramでもYouTubeでも、数字の良し悪しを一語で言うより、その動画がどの段階で離脱され、どの行動につながったかを見る方が次の制作に役立ちます。LINE集客まで考えるなら、表示・クリック・視聴・プロフィールや概要欄の導線・実際のキーワード返信を別々に扱います。CTAリンクが存在することと、LINEで反応が起きたことは別です。
Improverは「次の1本で変えるもの」を1つ提案する
分析を受けたImproverには、改善案を10個並べさせません。次の1本で何を維持し、何を1つだけ変えるかを提案させます。例えば『冒頭で完成物を先に見せる』を試すなら、題材や特典、サムネイルの約束まで全部同時に変えない。複数要素を一緒に変えると、結果が良くても何が効いたか分かりにくくなります。
もちろん現実の運用で、修正が1箇所しか許されないという意味ではありません。誤情報や権利上の問題は必ず直します。そのうえで、学習したい主要変数を1つ定め、比較可能な条件を残すという意味です。
改善提案には、変更前の状態、変更案、理由、予想される良い面と副作用、判定に必要な母数と期間を書きます。母数が足りなければ「保留」を選べます。3回目の人間承認で、採用・保留・却下と理由を残して初めて次の企画へ進みます。AIの提案がそのまま運用方針にならない設計です。
よくある4つの失敗と直し方
1つ目は役割の重複です。Plannerが台本を作り、Scriptwriterが企画を選び直し、Analystが改善案まで確定してしまうと、担当者を増やした意味がありません。それぞれの入出力と停止点を表に戻し、成果物ごとに所有者を1人にします。
2つ目は承認待ちの飛ばしです。AIが『承認済みとみなします』と書いても、人の承認にはなりません。承認記録がないbriefや台本は、次担当の確定入力に使わないようにします。レビューのために内容を読むことと、採用して次へ渡すことを分けます。
3つ目は、デモ数値や仮説を実績へ変えてしまうことです。練習用の投稿結果はDEMO DATAと明記し、記事や動画の成果報告へ転用しません。分析の原因も、比較できる情報がなければ仮説のまま残します。きれいなグラフがあることと、結果の意味が確定していることは違います。
4つ目は、一度に全部変えることです。企画、冒頭、尺、見出し、サムネ、特典を同時に変更してから『勝ちパターンが分かった』とは言えません。企画変更が必要な時はその理由を残し、包装のテストではタイトルとサムネイルの同時変更を避けるなど、比較したい問いごとに変数を整理します。失敗を隠さず、次の判断材料へ変えることがPDCAです。
1週間で始めるなら、まず2役だけでいい
動画の完全実演では4役を一周させていますが、最初の実運用で4役を毎日走らせる必要はありません。最初の週はPlannerとScriptwriterを使い、企画の選定と台本の赤ペンを自分で行います。投稿して比較できる数字がたまったらAnalystを加え、判断に使える分析ができてからImproverを動かします。
「毎日AIに何かさせないともったいない」と考えると、データが変わっていない日に同じ分析を繰り返し、似た答えが増えるだけになりがちです。Plannerは対象者や今週の目的が変わった時、Scriptwriterは承認済みbriefができた時、Analystは集計期間と比較条件がそろった時、Improverは分析が承認できる品質になった時に呼びます。必要な時だけ動かす方が、判断も利用枠も守れます。
今日試すなら、担当を1人だけ決めてください。その人が『読むもの』『作るもの』『してはいけないこと』『人が承認する場所』を1行ずつ書く。Plannerであれば今週の企画候補を出し、最有力1本を人が選ぶところまでです。それだけでも、次回に引き継ぐ形が見えます。
実際の1本を想定して、企画から改善までをたどる
ここからは、動画の考え方を自分のアカウントへ当てはめるための例です。以下のテーマや数値は説明用で、僕のチャンネルや誰かの運用実績ではありません。
想定するアカウントは、個人でサービスを提供している人のInstagramです。よくある悩みは「何を投稿するかを毎回決め直している」。今週の目的は、投稿を量産することではなく、問い合わせ前に必要な疑問を一つ解消することだとします。
まずPlannerへ「最近届いた質問」「提供サービスの範囲」「過去投稿の主題」「避けたい約束」を渡します。質問が実際にないのに「顧客からよく聞かれる」と書かせてはいけません。その場合は、検索上の一般的な疑問と、実際の顧客質問を別欄に置きます。すると、企画の根拠が見えるようになります。
Plannerが出した候補に「サービスの魅力を3つ紹介」「失敗しない依頼先の選び方」「依頼前に用意しておくこと」があったとします。どれも形にはできますが、今週の目的に最も近いのは「依頼前に用意しておくこと」かもしれません。人は、実際の問い合わせで何が不足しているかを確かめ、動画の約束を「依頼前に決める3項目」に絞ります。この選定理由をbriefに残します。
Scriptwriterへは、この承認済みbriefと、本人が実際に相談で使っている質問の順番を渡します。冒頭が「SNS時代に大切なことは」から始まっていたら、視聴者が自分ごと化する前に離れる可能性があります。例えば「相談の前に目的と担当者が決まっていないと、見積もりの比較も難しくなります」のように、具体的な困りごとから入る方が今回の約束と一致します。ただし、この例文も本人のサービスと実務に照らして直します。
投稿後、Analystは数字を見ます。表示回数だけでなく、冒頭で止まったか、最後まで見たか、保存したか、プロフィールへ移ったかを分けます。見込み客の行動に近い後段の数字が取れない場合は、その不足を記録します。仮に表示回数が増えても問い合わせがないなら、企画が悪いのか、CTAが見られていないのか、導線先が合わないのか、まだ分かりません。1つの原因を作り上げないのがAnalystの役割です。
Improverは「次回は冒頭でチェックリストの完成画面を先に出す」といった一つの変更を提案できます。この変更で何を比較したいか、人が承認します。その際、次の動画のテーマがまったく別の客層なら、単純な勝敗判定は避けます。条件を変えた事実も記録する。こうした細かい記録が、数本後の判断を楽にします。
「承認済み」と「下書き」を混ぜないための記録例
引き継ぎ失敗の典型は、AIが前のチャットを読んで「採用されなかった候補」を採用済みの方針と解釈することです。これを避けるため、ファイルの名前だけでなく、状態を中身にも書きます。
run: 2026-09-example-01
目的: 依頼前の不安を解消する1本の企画を選ぶ
企画候補: 3件（検討用・未承認）
選定: 「依頼前に決める3項目」
選定理由: 実際の相談で準備不足が繰り返し確認されたため
一次情報: 本人の相談メモで確認（個人情報を削除して要約）
承認者: 本人
企画承認: 済
台本承認: 未
改善承認: 未
外部公開: 未実施ここで大切なのは、承認者の名前を入れることそのものではありません。『どの版を、どの目的で、何を確認して採用したか』を次の担当が読めることです。初稿のまま台本承認済みと書いたり、投稿予約をしていないのに公開済みと記録したりしない。状態を正確に分けることが、AIを安全に使う基本になります。
台本の修正も、最終稿だけでなく理由を短く残します。『冒頭の一般論を削除し、完成画面から始めた』『本人が経験していない成功例を削除した』『難しい用語を視聴者の言葉に置き換えた』などです。次の台本担当は、その理由から発信の基準を学べます。単に「もっとバズる感じにして」と伝えるより、どんな表現が外れたかを示す方が再現可能です。
初心者が最初に作るべき共通ルール
共通ルールは、4役それぞれへ同じ長文を繰り返し貼るより、1か所にまとめます。動画ではプロジェクト直下のCLAUDE.mdに共通ルールを置いています。Claude Codeの公式資料もプロジェクト指示をこのファイルに置く構造を説明しています。設定の読み込み場所や優先順位は更新される可能性があるので、実装前は公式のメモリ資料を確認します。
最初の共通ルールは、次のように短く具体的で十分です。
- 対象者と今回解決する悩みを最初に書く。
- 観測した事実、推測、確認待ちを分ける。
- 本人の経験が必要な箇所は勝手に埋めず、確認待ちにする。
- 他人の投稿や記事の表現をコピーしない。
- 数字、引用、権利、個人情報は公開前に人が確認する。
- 投稿、予約、外部送信を担当者が勝手に実行しない。
- 承認前の下書きを次担当の確定入力にしない。
- 改善時は変えた要素と、変えなかった要素を残す。
このルールだけで良い台本が自動的に出るわけではありません。しかし、4役が違う前提で動くことを防ぎます。例えばPlannerには成果の断言を禁止したのに、Scriptwriterの指示には書き忘れた場合、台本でまた「必ず伸びる」が現れます。共通の境界は同じ場所に置き、役割ファイルには担当固有の仕事を記載します。
共通ルールを増やしすぎると、毎回の出力が決まり文句だらけになることもあります。ルールは守るべき境界と判断基準に絞り、企画の導入や台本の流れは題材と実例から作ります。「修正案」「失敗例」といった同じラベルを毎章に当てはめるのではなく、本当に視聴者がつまずく箇所で使う。読みやすさのための型と、不自然なテンプレ感は分けて考えます。
機密情報と権利を守るための入力チェック
過去投稿の結果や顧客の声をAIに渡す前に、顧客名、メールアドレス、電話番号、非公開の売上、契約条件、権限情報が含まれていないか確認します。スクリーンショットは一見データだけに見えても、通知欄やタブ名、ブックマークに情報が残ることがあります。動画のデモも匿名データを使っています。
もう一つは権利です。競合動画の構成や強みを調べることと、文章や画像をそのままコピーすることは違います。参考にするなら「何に困る人へ、冒頭で何を見せ、どの証拠で約束を回収したか」という構造を学びます。自分の動画には、自分の実演画面、自分の判断、自分の言葉を加えます。AIが作ったもっともらしい数字や体験を挿入しないでください。
外部接続にも注意が必要です。デモではSNS API、Webhook、投稿予約、追加の従量課金APIをつないでいません。最初から外部連携を増やすと、企画の品質より権限と誤送信の管理が難しくなります。まずローカルの成果物と人間承認で一周し、必要な操作だけ後から検討します。
動画と記事を両方使う理由
この記事は、作業分担と判断基準を自分の運用へ移せるよう、表と手順で整理しました。元動画には、4役の定義、生成された企画、台本の赤ペン、事実と仮説の切り分け、改善案の承認が実画面で収録されています。文章を読んだ後に動画を見れば、ファイルをどう開き、どこで人が止めるかが分かりやすくなります。
反対に、動画を見てからこの記事に戻ると、自分の担当表を作る時に使いやすいはずです。動画の字幕を単に記事へ並べ直すのではなく、検索から来た人が「何から始めるか」「どこで失敗するか」「どこまでをAIに任せてよいか」を判断できるようにしています。これが、同じ動画を複数の場所へ展開する時に大切な違いです。
実演動画とスターターキット
画面でファイルの受け渡しを見たい方は、Claude CodeでAIインスタ運用チームを作る実演動画をご覧ください。記事は構造と判断点、動画は実際の画面と赤ペンの流れを確認する役割です。
4役の定義テンプレ、引き継ぎファイル、3段階承認チェック、1変数改善シートをまとめた「自分専用AIインスタ運用チーム スターターキット」は、AIインスタ大学のLINEで「AIチーム」と送ってください。
運用でよくある質問
最初の企画を選ぶ時、どの数字を見ればいいですか？
数字を一つだけ選んで企画を決めるより、今回の目的に沿って見る場所を決めます。まず過去動画がどこから見られたか、タイトルやサムネイルで何を約束したか、冒頭でその約束を見せられたかを確認します。再生数だけが高い動画は、外部流入や一時的なニュースで増えた可能性もあります。一方、再生数は大きくなくても、視聴者の具体的な質問やLINE反応につながった題材なら、次の企画へ広げる価値があります。
企画担当に数字を渡す時は、観測日と対象期間を付けます。「累計で伸びた動画」と「公開後7日で伸びた動画」を同じ列で順位づけしない。表示回数が少ない動画は、クリック率が上下しやすく、偶然の影響が大きいこともあります。十分な材料がない時は、需要の候補として扱い、確定的な勝ち筋にはしません。
また、競合で伸びている動画のタイトルだけを見て企画を決めないことも大切です。本編で何を見せているか、冒頭の約束をどの時点で回収しているか、どんな実例を使っているかまで確認します。同じテーマでも、自分のチャンネルの視聴者が求める完成状態は異なるかもしれません。競合の再生数は「需要があり得る」という方向の材料で、自分の動画の成果保証ではありません。
AIへ渡す前の一次情報は、何を書けばいいですか？
難しいレポートは不要です。視聴者から届いた質問、実際に相談で説明した順番、自分が手を動かして失敗した点、画面で示せる成果物など、本人しか持っていない材料を短く書きます。ここに顧客の個人情報が含まれるなら、同意の範囲を確認し、識別できない形へ置き換えます。公開可能な体験と内部のメモを区別してください。
一次情報がまったくないテーマなら、AIへ空白を埋めさせる前に、小さく試すか調査します。例えば新しいツールを紹介するなら、実際の画面でどこが動いたか、どこはまだ確かめていないかを記録します。動画の中で「やってみた」と言うなら、自分で試した工程を示す。「一般にこう言われる」と「自分の運用で確認した」を混ぜないことが、読者の信頼につながります。
4役の定義ファイルには何を書けばいいですか？
長い性格設定より、担当する仕事の境界を先に書きます。Plannerであれば、入力は対象者と目的、出力は候補とbrief初稿、禁止事項は実績の捏造と台本確定、停止点は企画承認の前です。Scriptwriterなら承認済みbriefを入力にし、一次情報が足りない箇所を未確認として残します。Analystなら集計期間と数字の定義を先に確認し、因果の断定を禁止します。Improverなら次の1本で変える主要要素と判定条件を出し、人の承認で止まります。
この4項目を読んだ人が「次へ渡してよいのはどの状態か」を判断できれば、まず十分です。書き方の細かな仕様はツール更新で変わり得るため、使う時点の公式資料に合わせます。役割を作ったら、実際のデモ1本で止まるべき所で止まるかを確認してください。ファイルが存在するだけでは、運用の品質は証明できません。
台本がAIっぽく不自然になるのを防ぐには？
まず、本人の話す言葉と、画面で見せられる物を入力に入れます。抽象的な「課題→原因→解決→まとめ」を毎章に繰り返すと、構成は整っても視聴者には単調です。今回の動画なら、4役のファイル、企画brief、台本の赤ペン、分析表、承認記録という別々の画面を見せ、章ごとに進んでいる実感を作れます。
「修正案」「失敗例」を機械的な小見出しとして繰り返さず、実際につまずいた場面にだけ置きます。プロンプトを読み上げる時も、専門用語を連続させず、何をさせたいのかを普通の言葉で説明します。『コンテキスト』『run』といった言葉は、初めて見る人には意味が分かりません。最初に「毎回共有したい情報」「1本分の作業記録」と言い換えれば、操作の目的が伝わります。
完成稿は声に出して読み、自分なら本当にその言い方をするか確認します。読みやすさのために短くするだけでなく、約束を回収する具体例を残すことも必要です。長さは固定の正解ではありません。視聴者が得る完成物に必要な工程を見せつつ、同じ説明を繰り返している部分を削ります。
投稿後、どの時点で改善を判断すればいいですか？
公開直後の小さなサンプルだけで「勝ち」「負け」と決めません。まず比較したい期間と、必要な表示・視聴の母数を決め、投稿後に条件がそろったかを確認します。YouTubeのタイトルやサムネイルを試す場合も、CTRだけではなく、視聴維持、平均視聴時間、総再生時間、流入元、LINEの実反応を並べます。タイトル変更とサムネイル変更を同時に行えば、どちらの影響か分かりにくくなります。
数字が少なければ「insufficient（判断材料不足）」を選んで構いません。分析の目的は毎回必ず変更することではなく、次に何を観測すれば判断できるかを明確にすることです。短期のクリック率が上がっても、冒頭で離脱が増えたり、特典のキーワード反応が落ちたりしたら、約束がずれている可能性を疑います。ひとつの指標だけで「バズる」と断言しないでください。
ひとりで運用しても「人間承認」を3回入れる意味はありますか？
あります。承認者が一人でも、企画を選ぶ時、台本の事実や権利を確かめる時、改善案を採用する時は違う判断です。これをひとつの「OK」にすると、企画の方向は良いが表現は未確認という状態を見落としやすくなります。3回の承認は、会議を増やすためではなく、判断の対象と時点を分けるためのものです。
時間をかけたくなければ、各回で確認する項目を短くします。企画なら「対象者・約束・本人の根拠」、台本なら「事実・権利・個人情報・話し方・約束の回収」、改善なら「比較条件・変える要素・判定日」です。確認した事実と未確認を記録しておけば、後から自分がなぜ採用したかを追えます。
他のSNSや会社の運用にもこの仕組みを使えますか？
仕事を分担し、人が承認し、結果を次回へ引き継ぐ考え方は応用できます。ただし、同じファイルをそのまま別のチャンネルへ移してはいけません。視聴者、扱う商品、承認者、法律・権利、集客導線が違えば、何を確かめるかも違います。個人向けAIインスタ大学の特典やLINE導線を、企業向けチャンネルへ流用しないこともその一例です。
別チャンネルへ広げる時は、まずそのチャンネルで公開済みの動画、対象者、実際の反応、固有のCTAを確認します。一般化するのは役割の考え方で、事実や数字や導線は各チャンネルのものを使います。公開前の素材は公開済みとして記事化せず、作業状態を分けます。
自分のアカウントへ導入する前のチェックリスト
この方法を試す前に、次の問いへ答えられるか確認してください。すべてを完璧に埋めてから始める必要はありません。ただし、空欄があるならAIが推測で埋めないように、未確認として明示します。
対象者は誰か。 「Instagramを使う人」では広すぎます。発信を始めたばかりの個人事業主なのか、投稿は続けているが問い合わせにつながらない人なのかで、必要な動画は変わります。過去のコメントや相談で確認できた悩みがあるなら、一般的なペルソナより優先します。
動画で渡す完成状態は何か。 視聴後に何ができるかを一文で書きます。「AIを理解する」では抽象的です。「PlannerとScriptwriterの2役を作り、1本の企画を承認済み台本へ渡せる」のように、確かめられる状態へ絞ります。タイトルやサムネイルの約束も、この完成状態から外れないようにします。
本人の一次情報はどこにあるか。 デモ用画面、実際の操作、視聴者からの質問、自分で直した台本などを確認します。ない場合は「未確認」と記載し、体験談を作らない。競合の動画を見た場合も、誰のどの場面から構造を学んだかと、自分の実例で何を変えたかを分けます。
数字は比較できるか。 投稿結果の期間、表示条件、流入元、サンプル数がそろっているかを見ます。ないなら「この企画は伸びる」と断定せず、次の投稿で何を記録するかを決めます。分析担当に、見えていないデータを推測で補完させないでください。
誰が何を承認するか。 ひとり運用でも、企画・表現・改善は別にチェックします。チームなら最終責任者とレビューする人を明確にします。承認済みファイルがない状態で次担当が確定作業に進まないよう、受け渡し条件を書きます。
外部公開の権限はどこにあるか。 この4役は企画から改善案までを作りますが、SNSの公開ボタンは押しません。公開を自動化したい場合は、別途アカウントの所有者、権限、重複防止、事故時の回復方法を設計しなければいけません。「AIチームが作れた」ことと「安全に自動投稿できる」ことは同じではありません。
次の一手を小さく決められるか。 最初の週に全役割と全媒体をつなごうとせず、1本分の企画を選び、台本を直し、後で数字を読む。実際に困った引き継ぎを記録してからルールを直します。3回続けて同じ問題が出たら共通ルールや役割定義の改善候補にする、というように変更理由を残します。
ここまで答えられれば、AIへ任せる仕事と、人が持つ判断の境界が見えてきます。最初の完成形は、派手な自動化画面ではありません。「誰がどの根拠で企画を選び、どの版の台本を承認し、何を次に試すか」が追える1本分の記録です。そこから実際の視聴や反応を見て、必要な担当を足してください。
最後に、運用を続ける時の見直し方も決めておきましょう。役割ファイルを毎回その場の気分で書き換えると、うまくいった投稿でも何を変えた結果なのか追えなくなります。変更前の版、発生した問題、直した理由、次の数本で確かめたいことを短く残します。例えばPlannerが似た企画ばかり出すなら、担当の「性格」を変える前に、渡している視聴者の質問や過去動画の一覧が足りているかを見ます。Scriptwriterの冒頭が長いなら、実物を先に見せる約束と、最初の30秒で言うべきことがbriefに書かれているかを確かめます。AIの設定を増やす前に、入力と判断の質を点検する。この順番なら、ルールを増やすほど不自然になる失敗も避けやすくなります。
今日の着地点は、一度に全部の投稿を任せることではありません。まず1本で企画承認から改善案までを正しく受け渡し、どこで自分の判断が必要だったかを言葉にすることです。その記録が残れば、次の企画で同じ説明を繰り返す時間を減らしながら、内容の質を上げる余地が見えてきます。
導入前によくある質問
コードを書けなくても始められますか？
仕事の分け方を考える段階では、コードを書く必要はありません。まず対象者、担当ごとの入力と出力、承認する場所を日本語で書いてください。Claude Codeでファイルを作る操作は、動画で画面を見ながら確認できます。最初から複雑な自動化を作るより、1役の入力と成果物がつながるか試す方が安全です。
AIが作った企画をそのまま投稿していいですか？
企画案は選ぶための材料です。自分の経験、視聴者の実際の質問、過去に何を出したかを見て、人が選びます。自分で語れない体験や確認できない数字が入っていたら、そのまま投稿しません。企画と表現の承認点を分けておくと、発見しやすくなります。
4役を作れば毎回伸びますか？
保証できません。4役は判断と作業を整理する仕組みであり、需要がない題材や合っていない冒頭を自動で勝たせるものではありません。企画の需要、自分の視聴者の反応、動画の中身、包装、CTAを別々に観測し、次の1本に学習を戻す必要があります。
投稿予約や公開まで自動化しますか？
この記事と元動画のデモではしません。公開は読者へ届く外部行為なので、事実、権利、個人情報、ブランドの確認が済んだ人が判断します。企画・台本・改善の3回承認がそろっても、それだけで外部公開の許可をAIへ渡す設計にはしていません。
分析に使う数字が少ない時は？
「不足」と記録します。少数の反応から因果を決めず、同じ条件で次に何を記録するかを先に決めます。投稿がまだない場合はAnalystとImproverを無理に動かさず、PlannerとScriptwriterの受け渡しを整えます。
例えば、1本の投稿で保存が数件付いたとしても、それだけで『この題材は保存されやすい』とは決めません。表示された人数や視聴者の属性、投稿形式、配信された期間が違えば、同じ数件の意味も変わります。比較できる投稿がまだ少ないなら、次の数本で同じ定義の指標を記録します。数字がたまる前にもできることはあります。タイトルと内容の約束が一致しているか、冒頭で完成物を見せたか、特典のリンクが正しく開くか、視聴者の質問に答えているかを、公開物そのもので確認できます。数字が不足していることは、改善を諦める理由ではなく、断定を避けて観測と品質点検を分ける理由です。