# 自社サービスのプレスリリース原稿を、数値の裏取り込みで配信直前まで仕上げる ## 目的 自社サービスのプレスリリース原稿を、AI に「実在する事実だけ」で書かせ、 配信サービス（PR TIMES 等）へそのまま入稿できる状態まで仕上げる。 AI にプレスリリースを書かせると、最も事故りやすいのは**数字と会社情報**である。 それらしい導入社数・削減率・設立年を平然と作文し、人間は見抜けないまま外部配信してしまう。 この指示書は、その事故を構造的に防ぐ手順を与える。 ## 前提 - 対象サービスのソースコードか本番URLのどちらかにアクセスできること - 運営会社の会社概要が、自社の既存サイトのどこかに存在すること ## 手順 ### 1. 書き始める前に、事実を3系統から集める 原稿を1文字も書かないうちに、次を集める。ここを飛ばすと必ず作文が混ざる。 1. **製品の事実**: リポジトリの README、公開API のエンドポイント一覧、実際に提供している導線 （CLI のインストールコマンド、プラグインの導入手順など）。実在を確認した文字列だけを使う 2. **数値の事実**: 本番の統計APIや管理画面から実測値を取る。**同じ指標を必ず2箇所以上で取る** （例: トップページの表示値と統計APIの値）。一致しなければ手順2へ 3. **会社の事実**: 自社の既存サイトの会社概要ページのソース、および **過去に配信したプレスリリース本文**。過去配信と表記が一致していることを確認する （法人格の位置、代表者の肩書、本社の書き方は過去配信に合わせる） ### 2. 数字は「定義が1つに定まるもの」だけ載せる 同じ指標で複数の値が出てきたら、**その数字は原稿に載せない**。 どちらが正しいかを推測で決めてはいけない。原稿には載せず、末尾の確認事項に 「2つの値が食い違っている。算出根拠を1本化するまで載せない」と理由ごと書く。 また、次の型の数字は実測であっても単独で出さない。 - **自動アクセスと人間の利用を区別していないカウンタ**（API のダウンロード数など）。 「実測だが利用者数ではない」ため、利用実績として提示すると誤認を招く - **理論値・potential 値**（全商品を使った場合の合計など）。定義を併記できないなら省く 景品表示法の観点では、「盛った数字」より「定義が曖昧な数字」のほうが危険である。 ### 3. 原稿を書く 配信サービスの標準構成に合わせる。 - タイトル（全角60字程度。何が新しいのかを主語つきで） - サブタイトル（補足の1行） - リード（会社名・本社・代表者を正式表記で入れた1〜2段落） - 背景（なぜこのサービスが要るのか。課題側から書く） - 特徴（3〜4個。小見出しをつける） - 今後の展開 - サービス概要（表） - 会社概要（表） - 本件に関するお問い合わせ **依頼者が「ニュースの柱」を複数出したいと言った場合**は、リリースを分割せず、 特徴セクションを柱の数だけ立てて1本に畳む。タイトルは最も新規性の高い柱から取る。 ### 4. 原稿の末尾に「配信前に確定が必要な項目」を必ずつける AI が決めてはいけないものを、削除前提のセクションとして列挙する。最低限: 1. 配信日 2. 公開用の問い合わせ先（担当者名・メール・電話） 3. 配信当日に取り直すべき数値と、その取得手順（URL とフィールド名まで書く） 4. 載せなかった数字と、載せなかった理由 5. 画像の用意（多くの配信サービスはサムネイル必須） 6. **表現そのものへの疑義**。例えばサービスが既に稼働しているのに「正式公開」と書くなら、 その是非を人間に確認させる。記者に事実確認された時に説明できるかが基準 ### 5. 納品形式は依頼者の指定に従い、納品前に必ず読み返す ドキュメント形式（Google ドキュメント等）を指定された場合、HTML から変換する経路では **表のセル内の装飾がリテラル文字として残る**ことがある。作成APIが成功を返しても 中身の正しさは保証されない。**必ず本文を読み返してから URL を渡す**。 崩れていたら作り直す（多くの場合、作成後に本文を差し替えるAPIは無い）。 表のセルは装飾なしのプレーンテキストで書いておくと、この種の崩れを避けられる。 ## 完了条件 - 原稿中のすべての固有名詞・数値について、出典を1つ以上言える - 載せなかった数字について、載せなかった理由を言える - 依頼者が原稿を開いて、次に何を埋めればよいかが末尾を見れば分かる ---