はじめに

生成AIは初稿を速く出せます。しかし、数字が正しいか、重要な論点が落ちていないか、画面と台詞が合っているか、メールの差し込みが正しいかまでは、自分で責任を持ちません。「テーマを渡す→生成する→公開する」の一発の流れでは、どこで間違えたかも、どこだけ直せばよいかも見えません。

本書で渡すのは、特定のプロンプト集ではありません。生成前に材料を整え、生成後に種別ごとの基準で確かめ、不合格の箇所だけを直して再確認する工程です。ブログ、長尺動画、ショート動画、営業メールのどれにも使えます。

読み方は簡単です。第1部で共通の土台を押さえ、第2部では自分が作る種別のテンプレートとQAだけを先に使ってください。途中で「ここは誰も見ていない」と気づいた場所が、最初に整えるべき工程です。

第1部 土台：AIでコンテンツを高精度に作る考え方

第1章 一発で書かせず、作って確かめて直す

高品質は、一つの回答ではなく改善の手順でつくる

高品質なAIコンテンツは、単発の回答ではなく、生成・検査・部分修正・再検査を一組にしてつくります。ここでいうループエンジニアリングとは、初稿の後に決めた基準で確認し、不合格の箇所だけを直して再確認する、有限回の改善手順です。無限に直し続けることではありません。何回まで確認するか、どの失敗なら止めるかを先に決めて、改善を収束させます。

ハーネスエンジニアリングとは、AIの周りに安全装置を置く考え方です。安全装置は、入力となる材料、出力の形式、根拠との照合、公開を止める条件から成ります。AIが得意なのは表現を組み立てることです。数字が原典と一致するか、必須欄があるか、公開設定が正しいかは、ルールや人の確認の方が得意です。

基本の流れは、一次情報→事実メモ→構成→初稿→種別ごとの検品→局所修正→出荷判定です。一次情報は、公式の説明や確認済みの記録のように事実の出どころに近い情報です。事実メモは「何が言えるか」「数字は何を意味するか」「どこから先は言えないか」を抜いた短い材料です。完成物だけを見ても原因は分かりません。構成案・台本・根拠メモを途中で残すことで、どこを直すべきか切り分けられます。

モデルを替えるだけでは直らない問題がある

ある動画自動生成の現場では、画像内の文脈違和感、音声の誤読、台詞と画面の不一致、設定が出力に届かない不具合が別々に起きました。モデルを替えるだけでは、どの問題が改善したか分かりません。そこで台本、絵コンテ、音声、完成動画の各段階に確認点を置きました。絵コンテは完成前の画面設計図、音声認識結果は実際に読まれた言葉を文字に戻したものです。

各段階を照合できるようにすると、画面とのずれは該当場面だけを、音声の問題は音声だけを直せます。実際に、原資料の固有の失敗談・比喩・数字を、汎用的なたとえで置き換えずに戻す検証では、1件のPoCで面白さの評価中央値が4から7〜7.5へ、情報密度が13/21から21/21へ変わり、根拠のない記述は0件でした。一方、機械的なルールだけを強めた別条件では面白さがわずかに下がりました。具体の復元と演出の診断を組み合わせた結果であり、すべての原稿での成果を保証するものではありません。情報の正しさ、分かりやすさ、画面との整合、公開設定の正しさを、一つの「品質」に混ぜないことが出発点です。

人が残すべき判断を明確にする

自動化の目的は人を完全に外すことではありません。人が判断すべき場所を少数に絞ることです。次は機械的な合否だけでは決めにくい領域です。

• 冒頭が本当に面白く、関心をつかむか
• 言い回しがブランドらしいか
• 判断が割れる表現を、どの強さで言い切るか
• 画像や演出が内容に合うだけでなく、印象として適切か

反対に、必須見出しの有無、事実メモにない数字、CTAの不一致はルールで確認しやすい領域です。明日からは、生成依頼の末尾に「公開前に確認すること」を三つ書き、生成文だけでなく元の材料と照合できる形にしてください。

第2章 共通技法① 入力と選択を整える──バイアス排除と疑似API化

2-1. バイアス排除：見本・既定値・選択肢も「指示」になる

例文、固定の企画リスト、入力欄の見本、既定の選択肢は、意図せず出力を同じ題材や言い回しへ寄せます。人には単なる例でも、AIには優先度の高い指示です。企画を増やしたいのに、見本に置いた題材が別テーマにも何度も現れれば、連載全体では同じ話を繰り返します。

見本は固有の題材ではなく、悩み→原因→手順→注意点→次の行動のような題材を問わない骨組みで示します。選択肢も広い一覧から一度に選ばせず、今回の目的に必要な少数へ絞ります。生成後はテーマ語を除いた特徴語や近い二語句を比べ、似すぎた案だけを作り直します。有料の画像・動画生成は、この確認に通ってから進めます。

ある企画生成では、具体例に置いた題材が他のテーマにも繰り返し現れました。見本を題材非依存の表現に替え、隣り合う二語句で重複を見つける方式へ変えると、特定の反復エピソードは6案中2〜3案に減りました。これは特定の題材と設定での検証であり、すべての企画で同じ割合になるという意味ではありません。ただし、見本そのものが偏りの原因になり得ることを示します。

明日、プロンプトや入力フォームを一つ開き、例として社名、業界、人物像、テーマが埋め込まれていないか見てください。残すのは構造だけです。その後、企画を横に並べて同じ結論を繰り返していないか確認します。

2-2. 疑似API化：内部の文脈を読ませず、初見の判断をつくる

疑似API化とは、AIにプロジェクトの内部資料、過去の判断、社内用語などの文脈を読ませず、決めた検査対象だけを入力し、決めた形式だけを返させることです。目的は、作り手には当たり前の常識が判定へ混ざるバイアスを、指示ではなく入力境界で断つことにあります。ここでいう「API」は技術製品そのものではなく、入力と出力の境界を固定する比喩です。

たとえば、ある研修教材の読みやすさ監査では、監査側に教材1本以外の資料を読ませませんでした。内部の用語集、過去資料、設計メモ、ほかの教材を渡さず、初見の受講者として未説明の言葉を検出させます。一般的な言葉かどうかは内部知識で補わず、外部の公開情報で確認します。入力を教材1本、出力を「要修正／注意／参考」の定型レポートに固定すると、「知っているから普通の言葉に見える」という見逃しを、役割演技ではなく物理的な制約で抑えられます。数値効果は未計測であり、ここで固定したのは初見者の再現条件です。

もう一つは、修正するAIと検証するAIを分ける方法です。検証側には「これは改善版だ」という作成者の意図や、合格を期待する前提を渡しません。これは初見者を再現する厳密な疑似API化とは少し異なり、役割間の文脈分離です。それでも、検証者が作者の意図に同調する偏りを抑え、直したことと直ったことを混同しにくくします。

2-3. 構造化入出力・選択空間・真実源：疑似API化とは別に設計する

構造化入出力、AIに選ばせないこと、自己申告を信じないことは、どれも有効です。ただし疑似API化の定義ではありません。前者は確認しやすい形式の設計、次は選べる範囲を狭める選択空間の設計、最後は事実をどこが保持するかという真実源の設計です。混ぜずに使うと、失敗原因を直しやすくなります。

ある文章組立の検証では、AIに根拠の番号を自己申告させる方式で、重大な未裏付け主張が実在番号を添えただけで通り、既存の自動テスト540件もすべて通過していました。そこで、確認済みの事実台帳を真実源にし、数値や事実を含む文はルール側で定型の段落へ組み立てる形に変えました。4種類の文型をAIに選ばせた経路は、許可外の要素を混ぜて通過率40%から0%になりましたが、文型もルール側で決めて自由文をなくした経路は100%通過しました。これは特定のテスト条件での工程通過率で、文章一般の成功率や営業成果ではありません。

目的：読者・視聴者に何を判断してほしいか
確認済みの事実：番号または短い事実メモ
出力形式：見出し、場面、提案など必須の欄
公開してはいけないこと：未確認の数字、成果保証、守秘情報など

この四欄は、疑似API化そのものではなく、形式と真実源を整えるための依頼テンプレートです。疑似API化が必要な監査では、これに加えて「何を読ませないか」も明記してください。

第3章 共通技法② 途中のデータを残し、忠実性を測る──中間生成物・忠実性ゲート・自己修復

3-1. 一時データ・中間生成物を観測点にする

原資料から作る事実メモは、落としてはいけない論点を示す分母です。台本から再抽出した情報だけを正解にすると、最初に落ちた論点を見逃します。ブログなら検索意図・見出し案・出典メモ、動画なら台本・絵コンテ・音声認識結果、メールなら個社情報・送る約束・CTAを残します。これらは途中のごみではなく、品質を観測する地点です。

状態も混ぜません。未確認、合格、不合格を区別し、未確認を合格扱いしないでください。長い原資料を基にした台本の検証では、原資料の要点の保持率は33%にとどまりました。原資料から先に事実メモを作り、構成と対応付ける方式に変えると67%へ上がりました。この33%→67%は、後段の自己修正ではなく、生成前に材料を選び直した効果です。工程を分けて測らないと、後のループが改善したと誤認します。

一方で密度を急に上げたとき、根拠のない記述が0件から1件へ増えました。必要な情報が入っているかと、入れてはいけない情報がないかは別の確認です。これらの数字は特定の原資料と台本での検証であり、完成動画の成果を保証しません。明日からは、原資料から落としてはいけない事実を書き出し、見出しや場面の横に対応先を置いてください。

3-2. 忠実性ゲートと自己修復：止める基準、直す範囲、人に渡す範囲を分ける

忠実性ゲートとは、根拠のない具体的主張を公開前に止める確認点です。忠実性は元の事実に正しく沿っている度合いです。創作表現や判断が割れる言い回しまで一律に止める仕組みではありません。数字、日付、制度、固有の比較、相手の発言のように根拠を確認できる主張を止めます。

形式不足や必須欄の欠落は再生成できます。資格詐称、成果保証、守秘違反のような禁止事項は、再試行で通そうとせず停止して人が判断します。忠実性、情報の薄さ、文脈のずれは局所修正の対象にできます。面白さや演出の良し悪しは、自動で直しすぎず人が決めます。判定を急に厳しくした場合に正常な文章まで止めないよう、検査の版と既知の確認例も残します。

原資料37件の事実と30場面の台本に対し、四つの評価を各3回確認して不合格場面だけを修正した検証では、情報密度が57%から95%へ上がり、根拠のない記述0件を保てました。一方で物語性の評価は3点から2点へ下がりました。数字はこの素材と評価基準に限るPoC結果です。すべてを自動で改善しない境界が必要だと分かります。

別の忠実性ゲートでは、保留になった8本を本番と同じ台帳・判定条件で再確認しました。7本は判定条件のずれによる保留だったため復帰し、設定にない特典を加えた1本だけを止め続けました。61件の回帰用ケースを残した一方、高影響でも数字のない断定は2回中1回見逃す限界も確認されています。ゲートを厳しくするだけでなく、本番と同じ条件で「止めるべき1本」と「復帰できる7本」を分けることが必要です。この数字は同一条件での再検証結果で、検査の万能さを示すものではありません。

• 自動で直す： 必須欄の不足、形式のずれ、事実メモに対応しない一文
• 止める： 未確認の成果保証、資格や実績の偽り、公開してはいけない情報
• 人が決める： 面白さ、ブランドらしさ、演出、判断が割れる表現

第4章 共通技法③ QAをもぐらたたきにしない──分類・反証・本番バグ

4-1. QAのもぐらたたきを止める

QAは品質確認です。不具合を見つけるたびに同じ視点の確認を足すと、何を守る検査か分からなくなります。まず壊れ方で分けます。

警告だけの検査は、出荷を止めなければ形骸化します。何を必ず確認し、検査不能ならどうするかを決めます。対象外なら黙って通さず、明示的に許容します。多数の自動テストがあっても、完成物の検査失敗が警告扱いで28件残っていた例では、公開前に省略設定を使わず、検査不能は停止する運用に変えました。初回確認で音声・台本の不一致3件と、音と映像の長さのずれ1件を検出しました。これは特定の制作環境での監査結果であり、同数の不具合を一般化するものではありません。

4-2. 反証を工程に組み込む

反証とは、「その指摘は本当に問題か」「原因の見立ては合っているか」「修正で別の箇所を壊していないか」を別の視点から確かめることです。作成者と同じ観点で見直すだけでは、同じ思い込みを繰り返します。次の順番で視点を替えます。

1. 静的点検で必須欄・数字・根拠の対応を見る。
2. 修正案に反論し、原因を本当に解いているかを見る。
3. 読者・視聴者として通しで読み、約束違反や話の飛びを探す。
4. 全量差分と実行結果を、実際の入力・設定・完成物・公開先で確認する。

ショート動画の事実確認では、初期の規則が一般名詞や数え上げを誤って止めました。親となる長尺の台本とショート用根拠メモの両方に照合先を広げ、54組の実データと意図的な誤りで試したところ、意図的な誤り15件をすべて保留できました。残った6件を独立に確認すると、誤検出ではなく長尺との数字の矛盾や項目の欠落でした。これは54組と15件を対象にした条件つきの結果であり、検出率を保証しません。保留理由まで別の視点で確かめることが要点です。

本番相当のテストを3回連続で通し、合計2,484件のテスト失敗が0件でも、実際の配備と画面操作で7件の不具合が出た例もあります。原因は、同梱漏れ、環境設定の差、既存データがあるときだけの処理、外部サービスの反映待ちなど、ローカルでは再現しない種類でした。これはテストを否定する結果ではなく、実際の配備・実画面・実際の権限を別の検査層にする根拠です。この7件は当該環境・時点の実測で、ほかの環境の発生数を示しません。

明日、確認表に「作成者以外が原因または修正案を一度疑ったか」を足してください。担当を替えて通しで読むだけでも、同じ視点の繰り返しを避けられます。

第5章 共通技法④ 速さは、工程ごとのコストで作る──本番を守るコスト最適化

安く速くする対象は「全部」ではありません。調査、構成、本文、画像、音声、最終検品は、失敗の影響とやり直し費用が違います。企画案や初稿の候補出しは軽い設定で試せますが、事実確認、公開文、完成物の検品は品質優先にします。画像・動画など高コストの工程は、テキスト・構成の検査に通ったものだけへ使い、部分修正で全作り直しを減らします。

工程別にモデルと作業量を比べた検証では、低〜中程度の作業量へ落とせる工程で出力量を27〜51%減らせました。本文作成の1工程では中程度の設定で45%減かつ内部評価が28対26でしたが、軽量な候補は出力量が4.4倍に増え、数値の誤抽出や時間切れも出ました。これは同一プロンプトを比べた実測セルで、料金削減や全制作費の削減と同義ではありません。軽い設定を全工程に広げると下流のやり直しが増えるため、確認工程を残すことが前提です。

もう一つは、高コストの画像・動画制作の前に文章検査を置く方法です。企画の重複や異なる言語の混入を文章の段階で検出し、該当枠だけを直してから本制作へ進めます。これにより二重制作を構造上防げますが、金額の削減額は未測定です。「節約できた額」ではなく、高コスト工程に進む件数を絞る設計として評価してください。

速度は一回の生成単価でなく、再作業、保留、公開後の修正まで含む総コストで見ます。工程を次の三つに色分けしてください。

• 安く試す： テーマ候補、見出し候補、初稿の比較
• 合格後に投資する： 画像、動画、音声などの本制作
• 公開前に守る： 事実照合、画面確認、送信・公開設定

第2部 実践：コンテンツ種別ごとの作り方

第6章 ブログ記事の作り方──検索意図を集め、一次情報で書き、独自の順番に組み直す

6-1. 情報収集：ネタ源・一次情報・ファクトチェック

AI記事は、検索上位の記事を言い換えるほど弱くなります。競合記事は読者が知りたい論点を知る参考にとどめ、結論や見出しの順番を借りません。ネタは検索候補、読者からの質問、営業や商談で繰り返される論点、既存記事の不足から集めます。

制度、料金、規約、統計、製品仕様は公式サイト、原典資料、一次発表に戻り、URL、確認日、使える主張を事実メモへ分けます。主張ごとに事実、筆者の解釈、読者への提案を分けます。たとえば「料金は月額」が事実、「小規模チームなら始めやすい」が解釈、「利用人数を数える」が提案です。数字・日付・固有の比較は公開前に原典へ戻ります。

確認日：［確認した日］
原典：［公式ページまたは一次資料］
言える事実：［数字・条件・範囲を含む短文］
言えないこと：［未確認の点、比較不能な点］
使う場所：［見出しまたは比較表の行］

6-2. 台本・構成の型：悩みから判断までを一本道にする

見出しは検索語の羅列ではなく、読者が次に知るべき順に置きます。各節を「結論→理由・根拠→具体例→読者が取る行動」で書くと、抽象的な評価語だけで終わりません。

タイトル：［読者の判断］を［条件］で選ぶ方法
導入：読者が迷う場面を1つ／この記事で判断できること
H2 先に結論：向く人・向かない人を短く
H2 判断基準：基準A・B・Cを、根拠とともに説明
H2 ケース別：条件Xならこうする／条件Yならこうする
H2 実行手順：今日やる1〜3手順
H2 注意点：例外・確認先・やってはいけないこと
まとめ：判断の再掲＋次に取る行動1つ

図解は比較表、判断フロー、手順図のように本文を短くできる箇所にだけ置きます。図の前後でも判断条件を言葉で書けば、図だけを見ても本文だけを読んでも意味が通ります。

6-3. QA・検品：SEO、著作権、AI臭を別々に見る

• 検索意図QA： タイトルと導入は同じ疑問に答えているか。見出し順で結論に着けるか。
• 事実QA： 数字・制度・引用・比較表は事実メモと一致するか。事実と推測が混ざっていないか。
• 独自性QA： 参照記事の表現・構成に密着していないか。事実を自分の順番と例で説明しているか。
• 可読性QA： 句読点の直後に空白がないか。抽象名詞や「重要です」の連打を具体動詞と例に直せるか。下書き画面を人が確認したか。

検索意図QAは検索順位を約束するものではなく、検索した読者の疑問に入口から答えるための確認です。独自性QAも文字数だけで判定せず、原典を基に読者の判断順を組み直したかを見ます。

可読性は、禁止語を増やすだけでは安定しません。ある法人向け記事では、複数の同業媒体の記事から、導入の置き方、見出しの粒度、数値の示し方などの共通した書きぶりを抽出してから執筆しました。個別の書き手を模倣せず、自然な語彙感だけを参照し、内部用語や根拠のない数字は別のルールで止めます。比較ではこの方法が禁止語リスト、自己書き直し、自己採点より良いと判断されましたが、採点表とサンプル数は未記録です。定量効果をうたわず、書き方を選ぶ実務手順として扱います。

6-4. セールストーク：記事の結論から、相談の理由を一つだけ渡す

CTAは本文で解いた判断の次の行動に絞ります。診断が必要なら「現状を30分で棚卸しする相談」、比較段階なら「比較表を受け取る登録」のように、読者の段階に合わせます。商品名、価格、実績は確認済みの事実だけを使い、本文にない魅力を最後だけで盛りません。一記事につきCTAは一つを主役にします。

他社の詳しい記事を要約・言い換えした結果、文章だけでなく見出しの順番まで近くなった例があります。AIは内容だけでなく、与えられた文章の表現と構成をなぞるからです。他社記事は論点の参考に限定し、制度などの事実は一次情報へ戻し、読者の判断順で新しく組みます。同じ元記事での検証では20字以上の重なり率は19.5%でした。重なりの多くは制度名など避けにくい専門語でした。この数字は特定の比較条件であり、安全性を保証する閾値ではありません。表現と構成を写していないかを人が確認してください。

記事を誰に読ませるかも、ひとまとめの「読みやすさ」にしません。ある法人向け記事では、4種類の想定読者で2回確認し、12,027字・見出し15本・図解11か所の原稿を、内部ルーブリックで平均63.75点から85.75点へ直しました。初稿では導入担当の視点だけが不合格でした。修正を足し続けず、不要な説明を削る・置き換える方針にしたことが要点です。これは1本の記事、特定の社内評価での結果で、検索順位や問い合わせを保証しません。

明日、次の記事で「読者が最後に下す判断」を一文にし、一次情報から事実メモを作り、四つのQAを別々に通してください。

第7章 動画（本編・長尺）の作り方──原資料を台本に翻訳し、画面と音声まで検品する

7-1. 情報収集：原資料を「話せる事実メモ」に変える

長尺動画は台本だけを整えても足りません。原資料、話の流れ、画面、音声、完成動画の五つをつなぎます。ネタ源は一次資料、確認済みの知見、実演できる手順、視聴者から繰り返される質問を優先します。原資料をそのまま台本へ渡さず、次の単位に分けます。

事実：何が起きているか
根拠：どの資料・記録で確認したか
数字の意味：何を数え、どの条件で得られた数字か
言える範囲：この動画で断定してよいこと
言えない範囲：未確認のこと、一般化できないこと
担当場面：どの場面で扱うか

専門語は初出で日常語に直します。断定には具体例か根拠を隣接させ、架空の読者の声、実績、効果は使いません。

7-2. 台本・構成の型：問い→前提→3つの答え→実行で迷子にさせない

0:00 Hook：よくある失敗を1場面で見せ、今日の結論を予告
0:30 前提：誰に関係する話か／誤解しやすい条件
1:30 論点1：結論→根拠→具体例
3:30 論点2：結論→根拠→反例または注意点
5:30 論点3：結論→根拠→実行手順
7:30 まとめ：3点を一文ずつ再掲／次の行動1つ

一場面は一つの主張に絞り、前の場面を受けて次へ進めます。別テーマへ寄るなら必要な理由を一言で橋渡しします。画面に出す文は短く、話す内容と意味をそろえ、画面だけで新しい主張を増やしません。冒頭の問題と終盤の結論をつなげて回収します。

7-3. QA・検品：台本、画面、音声、完成物を分けて確認する

• 台本QA： 事実メモの要点が落ちていないか。根拠のない具体的主張や後出しの前提がないか。
• 構成QA： 各場面が宣言テーマに役立つか。話題の飛び、重複、まとめで初出する内容がないか。
• 画面QA： 絵コンテと台詞が矛盾しないか。理解を損なう文脈違和感を直し、演出の好みは人へ回す。
• 音声・完成物QA： 固有名詞・数字・専門語の読み、台詞と字幕、音声と表示時間、完成ファイルと公開設定を確認する。

絵コンテは場面ごとの画面設計図です。台詞と対応させれば、比較を話しているのに別の手順を見せるような違和感を完成前に止められます。実際に、文化的な場面で不適切な姿勢が描かれた例では、台詞と絵コンテを一組で判定し、該当画面だけを再生成して解消しました。20件の文脈違和感テストでは、重大な問題を18/20、軽微なものを含む問題を19/20検出し、再生成は20/20で成功しました。ただし、意図どおりに描けない生成例と、軽微で自動修正しない例もありました。これは本番ゲート化前のPoC結果であり、画面検査の完全性を保証しません。

企画と制作の境界も中間生成物として残します。複数本の企画を一度に詳細な台本骨格まで決めると、制作時には古い事実や未確認の数字が混ざりやすくなります。ある現場では18本をまとめて詳細化する運用をやめ、企画段階はタイトル・役割・主張まで、根拠と数字の確認は制作着手時に分けました。改善率は未測定ですが、未検証の具体を早期に固定しない工程変更として再現できます。

7-4. セールストーク：売り込みを後付けせず、動画の約束の延長に置く

CTAは動画で解いた課題の次の一歩を一つだけ示します。例として「自社の工程に当てはめたい場合は、診断用チェックリストを受け取る」と案内できます。説明中は役立つ内容に集中し、最後に自然に案内します。根拠のない時間削減や売上の数字は、分かりやすさのためにも作りません。

長い原資料から作った台本が、自然な言葉でも重要な学びをほとんど伝えない薄い内容になった例があります。台本の中だけを見て、原資料を比較対象にしていなかったためです。事実メモを先に作り各場面と対応付け、不足・誤り・文脈ずれの場面だけを直しました。情報保持は33%から67%へ上がり、さらに37件の事実と30場面による局所修正では密度を57%から95%へ上げつつ根拠のない記述0件を維持しました。素材と評価基準が定まった検証であり、視聴成果を保証する数字ではありません。物語性が下がった局面もあるため、面白さは人が判断します。

完成前だけで満足せず、台本と音声の鮮度も確認します。ある出荷前監査では、3種類・合計64場面で、更新済みの台本に古い音声が残る不一致を検出しました。台本、字幕、音声、完成物に内容の指紋を持たせ、出荷時は省略設定を外して対応を確認した結果です。原因の調査と修正は別工程であり、検出したことを修正完了とは扱いません。この64場面は1回の監査結果で、ほかの制作の不一致率を示すものではありません。

明日、台本の各場面に伝える事実を一つ書き、台詞・絵コンテ・音声・完成物を同じ表で確認してください。

第8章 ショート動画の作り方──1メッセージを40〜50秒で完結させる

8-1. 情報収集：広い悩みと、確認できる一つの発見を選ぶ

ショート動画は長尺の切り抜きではなく、最初の数秒から結論までを一つの発見に絞る独立コンテンツです。ネタ源はよくある不満、誤解、比較、手順のつまずき。フックは作り手の内部用語でなく、視聴者が普段使う言葉で書きます。

一本につき持ち帰る結論は一つだけにします。複数の数字やツールを詰め込む題材は分けます。数字、規約、比較結果は、元資料、親となる長尺台本、確認済み事実メモのどれにあるかを先に確認します。既存短尺と同じツール名・観察軸・結論になっていないかも一覧で比べます。

8-2. 台本・構成の型：5画面・8〜9行・一つの結論

40〜50秒、5画面、8〜9行は、文字量を増やしすぎず音なしでも理解できるための目安です。これは完視聴80%を狙うための設計値であり、達成実績ではありません。1本の役割を一つに絞り、各行をおおむね4〜7秒へ配分します。

画面1 Hook：視聴者の広い疑問／意外な事実
画面2 発見：今回の結論を一文で
画面3 中身：理由または具体例を一つ
画面4 注意点：例外条件またはやること
画面5 結論＋CTA：一文で締め、登録・資料など次の行動を一つ

型A：サービス発見

「［広い悩み］ありませんか？」
→「［サービス／方法］でここまでできる」
→「できることを2点」
→「料金・条件などの注意点」
→「同種の発見を知りたい人へCTA」

型B：観察・比較

「［意外な比較］、共通点を知っていますか？」
→「結論は［一つの軸］」
→「当てはまる例」
→「反例と理由」
→「結論を再掲＋CTA」

型C：よくある常識の検証

「［業界の常識］と聞きます」
→「確認した原典・条件」
→「結果」
→「当てはまらない条件」
→「結論＋CTA」

型Aは便利さだけでなく条件も渡し、型Bは反例で単純化を防ぎ、型Cは原典と条件を短く示します。どの型も、ショートだけで結論を完結させます。

8-3. QA・検品：短いからこそ、最初と最後を厳しく見る

• フックQA： 冒頭が作り手にしか分からない用語でないか。釣った疑問に最後まで答えているか。
• 情報QA： 主張は一つか。数字・固有名詞・比較は根拠と一致するか。親の台本と矛盾しないか。
• 話し言葉QA： 5画面、8〜9行、40〜50秒で言い切れるか。字幕と話す文が一致するか。
• 映像QA： 縦画面で一読でき、音なしでも主張が分かり、音ありで読み違いがないか。

少人数の異なる読み手で、最大3回まで短く回します。問いに答えていない、根拠がない、読めない、聞き取れない問題を止めます。演出の好みは必要なときだけ人が決めます。長尺用の重い確認をそのまま流用せず、代表視聴者2人と編集者の3視点に絞った軽量運用です。通過率は未記録であり、ここで示す3視点・最大3回は、短い成果物に合わせた運用設計です。

8-4. セールストーク：最後の一行は、視聴者が得る次の発見にする

一本で売り切ろうとせず、登録、無料チェックリスト、続きの解説など内容と同じ温度の次の一歩を一つだけ置きます。「詳細は本編で」と丸投げせず、画面と概要欄で別の約束をしません。

短尺の数字・固有名詞チェックが一般名詞や数え上げまで誤って止めた例では、単語だけで判定していたことが原因でした。台詞とタイトルを親の長尺台本とショート用根拠メモの両方に照合し、不明な新しい具体的主張だけを保留しました。54組の実データで意図的に入れた誤り15件をすべて保留でき、保留の6件は確認すると長尺との数字の矛盾や項目の欠落でした。これはこのデータと条件での結果です。短い文ほど、単語だけでなく根拠とのつながりを見ます。

企画段階では、既存の短尺を先に横断して、同じ題材・観察軸・結論の焼き直しを除きます。企画を出す担当と台本を書く担当を分け、候補を自動で次工程へ渡さず、人が企画プールから採択します。実際の重複削減件数は未記録ですが、生成者が自分の案をそのまま採用する自己承認を避け、制作前に重複を止める工程として使えます。

明日、台本の前に視聴者が持ち帰る一文を決め、数字と固有名詞には根拠の行き先を添え、音なし・音ありの両方で一本通して確認してください。

第9章 営業メール文章の作り方──個社の事実を起点に、三つの提案を人間の言葉で書く

9-1. 情報収集：公開情報を「書いてよい事実」と「仮説」に分ける

営業メールは製品説明を大量に書く場ではありません。公開情報から一つの具体的な困りごとを仮説にし、相手の実利へつながる提案を自然な口調で渡します。公式サイト、公開コンテンツ、採用情報、プレスリリースから事業、発信量、対象顧客、直近の変化を集め、推測で補いません。

確認済みの事実：公開ページで確認できる内容
課題仮説：事実から考えられるが、断定できない困りごと
提案できること：自社が確認済みの範囲でできる支援
言ってはいけないこと：未確認の実績、価格、期限、相手の発言、扱えない領域

仮説は「〜という場面が増えませんか」と質問で置きます。実績、対応範囲、価格、期限、引用は確認済みの台帳だけを使い、別の方法の成果を流用しません。同じ業界へ複数通送るときも、発信量、組織規模、特徴に応じて提案の組合せと書き出しを替えます。公開情報の事実は、個別感が伝わるものに絞ります。

9-2. 台本・構成の型：観察→困りごと→三つの提案→小さなCTA

件名：［相手の発信・事業の具体］について、1点だけ

宛名
名乗り（1文）
冒頭：公開情報で確認できた事実＋送った理由（2文以内）

【1】質問形：［個社の状況］で起きやすい困りごと
      → できること → 相手に残る実利
【2】事例・場面形：よくある具体場面
      → 対処の考え方 → 実利
【3】数字・断定形：規模や変化から見える論点
      → 対処の考え方 → 実利

CTA：興味があれば15分。相手向けの具体案を一つ話す
署名

三提案をすべて「課題→解決→効果」の同じ言い方にしません。質問、具体場面、数字や断定の順に、主語と語尾を替えます。「差別化」で終わらず、問い合わせの入口、採用、既存顧客への浸透など、相手の業界で意味のある実利へつなげます。成果保証のようには書かず、「判断しやすくする」「知ってもらえる状態を残す」と正確に言います。

9-3. QA・検品：事実・人間味・送信面を別ゲートにする

• 事実QA： 会社名、数値、役職、公開内容、提案範囲、CTA先が確認済みか。日付や発言を根拠なく足していないか。
• 人間味QA： 句読点直後の空白がないか。同じ主語・語尾・「考えています」などの定型句が続かないか。能動形で短く言えるか。
• 横断QA： 同業他社向けと並べ、三提案の順序、言い出し、数字、CTAがコピーになっていないか。
• 送信QA： プレーンメールに見出し記法・装飾記号が残っていないか。署名、ヘッダー、URL、差し込み欄を確認したか。

人間味とは、くだけた言葉を足すことではありません。確かな事実を簡潔に言い、仮説は仮説として置き、相手の時間を奪わないことです。

送信も、文面生成とは別に扱います。問い合わせフォームへの自動送信を試した5社では、相手先サイトの制約により成功が0社でした。そこで、会社の選択、文面の用意、送信先を開くところまでを仕組みにし、送信は1社あたり5〜10分の人の作業に戻しました。この数字は小規模な試作条件の結果で、全ての送信手段の成功率を示すものではありません。品質のよい文面と、相手先で送れることは別の検査対象です。

9-4. セールストーク：AI臭を消し、刺さる一文を作る

確認できる数字は一度だけ短く使い、作らず連呼しません。「ご提供できると考えています」「ご検討のほど」のような定型を、営業担当者が口で言う単純な動詞に直します。CTAは時間、得られるもの、次の行動を明確にします。

AIらしい文：
「以下3点をご提供できると考えています。」

人が読める文：
「今の発信で、特に効きそうな点を3つだけ書きます。」

AIらしい文：
「中長期の差別化につながります。」

人が読める文：
「問い合わせ前に、御社の考え方を知ってもらえる状態が残ります。」

複数社向けメールで、個社名と数字だけが違い、三提案が同じ段取り・語尾になった例がありました。句読点後の空白や過剰な敬語も残りました。本文を一度に作らせ、内容の正しさと人間らしさを同じ確認で済ませていたことが原因です。個社の事実と業界の実利を先に分け、三提案の始め方を変え、事実確認と人間味を七観点で見る確認を分離し、複数社を横並びで点検しました。

同一評価基準では改善前71点だった文面が、10回の改善後に90.8点となりました。ただし改善幅は途中から小さくなったため、最後は人が短く磨きました。この点数は特定の文面群と評価基準での比較で、返信率や受注率を表しません。どこで自動再生成を止めて人へ渡すかを決める材料です。

自己評価だけに任せないことも重要です。ある生成側は7観点すべて問題なしとした文面を、独立した文体レビューは71点と評価しました。同じ導入句の反復や過剰な定型を、書き手自身が見逃していたためです。さらに複数社で並べると、1社ずつでは86〜88点だった文面群が72〜78点へ下がりました。作成側と判定側を分け、同一社内だけでなく横断比較する理由になります。これらは内部ルーブリック上の比較で、受信者の反応や営業成果を保証しません。

明日、公開情報の事実、仮説、相手が得る実利を分けて書き出してください。同業向けメールを横に並べ、名前だけが違う文なら提案の順番か入り口を替え、実際の送信画面で差し込み欄とURLを確認します。

巻末

自己診断チェックリスト：自社のAIコンテンツ工程を点検する10項目

「はい／一部だけ／まだできていない」で答えてください。三つ以上空いた場合は、ツールを増やす前に工程の空白を埋める余地があります。

1. 作り始める前に、一次情報と「言ってよい事実」を分けて残しているか。
2. 例文、入力欄、固定リストが題材の偏りを作っていないか。
3. AIに任せる判断と、ルール・人が決める判断を分けているか。
4. ブログの見出し、動画の台本、メールの個社情報など、途中の成果物を保存しているか。
5. 数字・固有名詞・引用を、生成文ではなく元の事実メモと照合しているか。
6. 不合格時に、全体を作り直さず該当箇所だけ直せるか。
7. 読みやすさ、事実、画面・音声、動作不良を同じ検査で済ませていないか。
8. 作成者とは別の視点で、原因や修正案を反証しているか。
9. 高コストの画像・動画生成を、台本・本文の合格後に実行しているか。
10. 公開・送信の直前に、実際の画面・完成物・差し込み内容を人が確認しているか。

すべてに「はい」と答えることが目的ではありません。種類、人数、扱う情報の重さで必要な確認の深さは変わります。未確認を合格扱いせず、どこで誰が判断するかを見えるようにしてください。

チェックが3つ以上空いたら、工程を一緒に棚卸ししませんか

空いた項目が三つ以上あったなら、今ある制作フローを一本だけ題材にしてください。ブログ一本、動画一本、メール一通で構いません。どこに事実メモ・検品・部分修正を置くかを整理すると、次に整えるべき工程が見えてきます。

必要であれば、その棚卸しを短時間の相談として一緒に行えます。サービス一覧を並べる前に、いまの制作で品質が止まる場所を確認し、事実メモ・検品・部分修正をどこへ置くかを整理します。導入を急ぐ相談ではなく、まず一つの工程で空白を見つけるための時間です。

田所英俊 ── claudecodeで動画制作を自動化する人
お問い合わせ：claudecode@wellnesline.com