AIでプレスリリースの下書きを作る方法

AIでプレスリリースの下書きを作るなら、生成を始める前に「何を発表するのか」「その主張を裏付ける資料は何か」を一枚にまとめます。AIが得意なのは、確認済みの事実を読みやすい順に並べ、タイトルやリードの候補を作ることです。ニュース価値、数字の正確さ、公開可否までAIに決めさせるのは避けます。まず事実の境界を引き、その範囲内で文章化すると、もっともらしい誇張を発表文へ混ぜにくくなります。

生成前に「発表の核」と証拠を固定する

5W2Hは情報を集める棚として使えますが、項目を埋めただけではニュースの核は決まりません。発表主体、対象、開始日、提供地域、価格、対象者、これまでとの違いを整理したうえで、「読者が今回初めて知る変更」を一文にします。調査発表なら調査期間・対象・回答数・設問、受賞なら主催者・賞の正式名称・受賞対象を原資料で確認します。新商品なら発売日と予約開始日を分ける、といった境界も必要です。

入力は次のような事実台帳にすると確認しやすくなります。

• 主張：本文に書く内容を一文ずつ分ける。

• 根拠：承認済み資料のファイル名、URL、表番号、担当部署を記録する。

• 状態：確定／確認中／仮説を付ける。確定していない値は空欄のままにする。

• 公開範囲：社外公開可能、 embargoあり、社内限りを区別する。

• 責任者：その事実を承認する人と、最終公開を決める人を分ける。

「売上が伸びた」「業界を変える」といった表現は、比較期間や算出方法がないと読み手が検証できません。数値を使うなら分母、期間、対象条件、比較元も台帳に入れます。資料間で日付や数値が食い違うときは、AIへ整合させる指示を出すのではなく、原資料の責任者へ戻します。

AIに渡す資料と伏せる情報を決める

発表文に必要な情報だけを抜き出し、入力してよい資料か確認してから使います。未発表の提携、顧客情報、個人のコメント、社外秘の価格表などは、契約や社内のAI利用ルールを確認せずに外部サービスへ貼り付けません。一般化しても特定の顧客が推測できる情報が残る場合があります。匿名化だけで安全と決めず、組織が承認した環境・設定・データ取扱条件を確認します。

また、AIへ渡す文章には「根拠資料にない情報を加えない」「未確定項目は要確認と表示」「引用コメントは原文を改変しない」「候補の各文に根拠IDを付ける」と指定します。根拠IDとは、事実台帳の行番号など、後から元資料へ戻れる目印です。これがあると、レビュー担当者が文章の一文と証拠を往復しやすくなります。AIへ資料全体を渡す必要がないなら、該当する数値・引用・説明だけに絞り、不要な情報を減らします。

タイトルより先に「言ってよい範囲」を決める

タイトル案は本文の事実が固まってから作ります。先に強いタイトルを選ぶと、本文にない新規性や効果を後から足したくなるためです。案を並べるときは、語感の良さだけでなく、各案を支える証拠と、本文に明記すべき条件をセットで見ます。

表は横にスクロールできます

案の要素	確認すること	根拠がない場合
「初」「初めて」	対象範囲、調査方法、比較時点	「新たに」「提供開始」など確認できる事実へ戻す
「最大」「No.1」	母集団、比較対象、調査主体、期間	数字・順位を削る
数量・割合	元データ、分母、集計条件	数値を出さず、確認済みの傾向だけを書く
効果・改善	指標、比較条件、測定時点	期待と実績を分ける
「無料」「最短」	適用条件、対象期間、除外条件	条件をタイトルまたは本文に添える

PR TIMESの案内も、タイトルの要素を5W2Hで整理し、ニュースの中心を選ぶ手順を示しています。これは項目を全部タイトルへ詰め込む指示ではありません。誰が何を発表したかを優先し、補足条件はサブタイトルやリードへ回す判断が必要です。消費者庁が示す優良誤認の考え方にも照らし、商品・サービスを実際より著しく優良に見せる表示になっていないかを確認します。法令への適合は個々の表示・証拠・文脈によるため、タイトルだけを見て一律判断しません。

リードと本文を「読み手の確認順」に組み立てる

リードでは、発表主体、発表内容、開始時期、対象、背景のうち、今回の知らせを理解するのに必要なものを短く伝えます。5W2Hを機械的に全部入れる必要はありません。発表が誰に関係するのか、今何が変わるのかが分かれば、読者は本文へ進むか判断できます。

本文の順番はニュースの種類で変えます。新機能なら「何が変わるか→対象→使い方→提供条件→背景」、調査なら「主な結果→調査方法→設問・対象→解釈上の限界」、提携なら「当事者→合意内容→開始時期→それぞれの役割→今後」といった順が候補です。会社概要や問い合わせ先は補足として分離し、本文の流れを止めないようにします。AIへ一括で完成稿を頼むより、まずタイトル候補と見出し案を出させ、事実台帳との対応を確認してから各節を文章化すると、修正箇所を限定できます。

AIの出力をそのまま貼るのではなく、各段落に「根拠のある事実」「発表者の評価・見通し」「読み手向け説明」のどれが含まれるか印を付けます。見通しは発表者の意見だと明示し、実績や確定計画のように読める表現へ変えないことが大切です。引用コメントは言い回しを整える場合でも、発言者の承認を取らずに意味を変えません。

公開前に原稿を一行ずつ照合する

確認はタイトル、リード、本文、図表、リンクの順に進めます。特に「初」「最大」「大幅」「業界を変える」などの強い表現、日時、価格、対象条件、単位、引用、URLを事実台帳へ戻して照合します。数字が表と本文で一致しない場合は、どちらかを推測で直さず集計元に戻します。リンクは実際に開き、公開時点で利用できるページか、別の説明へ誘導していないか確かめます。

公開判定を次のゲートに分けます。

1. 事実ゲート：タイトルを含む全主張に根拠があるか。

2. 表現ゲート：比較表現や効果表現に条件・証拠があるか。

3. 機密ゲート：入力資料と出力に公開してはいけない情報がないか。

4. 承認ゲート：引用者、事業責任者、広報など必要な担当者が確認したか。

5. 配信ゲート： embargo、公開日時、問い合わせ先、関連URLが正しいか。

一つでも未完了なら、文章の完成度にかかわらず配信を止めます。専門規制のある製品・サービスでは、担当部署や専門家による個別確認を加えます。一般的な記事のチェックリストは、薬機・金融その他の法令判断を代替しません。

修正が必要なときは主張単位で戻す

誤りが見つかったら、記事全体を再生成するのではなく、該当する主張と根拠の対応を確認します。数字の出典がないなら数値を外す、引用が承認されていないなら引用を保留する、条件が未確定なら該当段落に要確認を残す、というように戻す場所を絞ります。原資料が更新されたときは台帳の版と確認者も更新し、旧版の根拠で文章だけを直さないようにします。

この方法なら、AIが語尾や段落を整える作業と、人が事実・新規性・公開可否を決める作業が分離されます。配信後に訂正が必要になった場合も、どの根拠を使ったかをたどりやすくなります。発表内容が複数部署にまたがるなら、主張ごとに承認部署を置き、最後に広報が全体の読みやすさと整合性を確認します。修正履歴には、誰が何を確定したかを残し、AIの出力だけを承認記録にしないでください。

タイトル案を「ニュース」と「根拠」で選ぶ例

架空の例として、ある会社が既存サービスに予約機能を追加する発表を考えます。入力資料で確認できるのが「予約機能の提供開始日」「対象プラン」「対応地域」だけなら、タイトルの中心はその三点です。「業界初」「予約時間を半減」「利用者満足度が向上」といった主張は、比較調査や利用実績がなければ追加できません。タイトル案を比較するときは、案ごとに根拠台帳の行を記し、根拠のない案を候補から外します。

表は横にスクロールできます

タイトル案の方向	読者に伝わること	配信前の条件
「予約機能を提供開始」	何が始まるか	提供開始日と利用対象を確認
「〇〇向け予約機能を提供」	誰に関係するか	対象者・地域・プランを確認
「予約が簡単に」	期待できる変化	操作比較や利用者調査がなければ避ける

この例のように、確認済み情報で成立する案を先に作れば、目を引く形容詞を使わなくても発表の内容を伝えられます。タイトルを短くするために必要条件を落とす場合は、リードで補います。本文とタイトルの対象範囲がずれていないか、配信システム上の文字数制限も最後に確認してください。

配信日時と公開物の整合を取る

原稿の内容が正しくても、公開予定時刻や embargo の扱いを間違えると、発表前に情報が出ることがあります。配信日時、ニュースサイトの公開設定、会社サイトの関連ページ、SNS投稿、問い合わせ窓口の準備状況を一つの表で管理します。担当者が複数いる場合は、誰が最終公開ボタンを押すかも一人に定めます。

• 公開時刻はタイムゾーンを含めて確認し、予約設定とカレンダーを照合する。

• 参照リンクは社外から開けるか、公開前の認証画面へ飛ばないか確認する。

• 添付画像・ロゴ・人物写真について、利用許諾とクレジットを確認する。

• 引用者へ最終文面と公開予定を共有し、承認の記録を残す。

• 問い合わせ先が当日対応できるか、担当不在時の引き継ぎ先を決める。

配信後に誤りが見つかった場合に備え、元の発表資料、公開版、修正履歴、判断者を同じ案件フォルダに保存します。訂正が必要かは影響のある事実と媒体の手順に沿って判断し、AIに訂正文を作らせるだけで済ませません。

配信後の記録を次の発表に生かす

配信後に記者や読者から質問が届いたら、質問内容と回答の根拠を案件記録へ残します。よくある質問が発生した場合は、次回の発表で説明が足りなかった箇所を見直す材料になります。ただし閲覧数や掲載数だけで、発表内容が正確だった・伝わったと断定しません。目標にしていた読者へ届いたか、問い合わせに必要な説明が含まれていたかなど、発表の目的に合う指標を担当者が選びます。

訂正が発生した場合は、元の公開文、訂正版、変更日時、変更理由、承認者を残します。数字の誤り、引用の誤り、リンク切れなど原因を種類分けし、入力台帳のどの確認工程で検出できたかを振り返ります。特定の原因を直すために確認項目を一つ増やすなど、次の原稿作成へ戻せる改善にします。発表結果を誇張する実績として利用せず、確認できた範囲だけ次の社内記録や報告に使ってください。

AIものさしの判断

AIでプレスリリースを作るなら、文章生成より前にfact sheetを作るのが重要です。

事実をAIに考えさせず、確認済み情報だけからtitle / lead / bodyを組み立てる。

この順番なら、広報文の初稿作成をかなり短縮できます。