自社サービスのプレスリリース原稿を、数値の裏取り込みで配信直前まで仕上げる

目的

自社サービスのプレスリリース原稿を、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つ以上言える
• 載せなかった数字について、載せなかった理由を言える
• 依頼者が原稿を開いて、次に何を埋めればよいかが末尾を見れば分かる