Claudeで掲載記事の誤りを見つけ、訂正依頼文を作る手順

発表したプレスリリースを元にした記事が出たものの、数字が違う。社名の表記が古い。製品名の一部が別の製品に入れ替わっている。広報にいると、こうした掲載後の誤りに出会う日が来ます。

Claudeに任せられるのは、記事とリリースの差分表づくりと、訂正依頼文の下書きまでです。依頼を送るかどうか、どの強さで書くかは、人が決めます。

掲載前のゲラ確認は取材記事のゲラを事実照合する手順が受け持ちます。ここで扱うのは、すでに公開された記事への訂正依頼です。

依頼を書く前に、誤りの出どころを切り分ける

差分表を作る前に、見つけた食い違いが誰の誤りかを分けておきます。出どころが違うと、頼む相手も文面も変わるからです。

2つ目がいちばん厄介です。リリースが誤りなら、記事側に依頼を送っても「リリースのとおりに書いた」と返されます。この切り分けを飛ばさないために、後の指示文に「リリース自体の誤りの疑い」という判定を入れておきます。

照合用のプロジェクトを用意する

必要な資料は3つです。自社のプレスリリース、公開された記事の本文、そして数字の正本となるファクトシートか社内資料です。

ClaudeのProjectsは、プロジェクトのナレッジに置いたものを、そのプロジェクト内のすべてのチャットで使います。ただしナレッジに入れていない情報は、チャット間で共有されません。この性質に合わせて置き場所を分けます。

プロジェクトの作成時に入れる名前と説明は、Claudeには渡りません。照合の基準を説明欄に書いても効かないので、指示とナレッジに書きます。

指示の例です。書き方の一例なので、自社の運用に合わせて直してください。

あなたは広報の掲載後チェック係です。
- 比較の基準は、ナレッジのプレスリリース原本とファクトシートだけにする。
- 記事の記述ごとに、判定を次の6種類から1つ付ける。
  一致 / 記事側の誤りの疑い / リリース自体の誤りの疑い /
  基準日の違いの可能性 / 資料に無い / 照合対象外(記者の評価)
- 「記事側の誤りの疑い」には、リリースの該当箇所をそのまま引用して添える。
- 資料のどちらにも根拠が無い記述を、推測で正誤判定しない。
- 記事を書き直さない。依頼文は頼まれたときだけ書く。

6つ目の判定に「照合対象外」を残しているのは、記者の評価語まで誤りと断じさせないためです。

記事とリリースを貼って差分表にする

新しいチャットを開き、記事の本文を貼ります。Webの記事は、本文をコピーして貼るのが確実です。ページをPDFで保存して添付する場合は、チャットの上限を押さえておきます。チャットに添付できるファイルは1チャットあたり20個まで、1ファイル500MBまでです。

PDFは、100ページ以下なら図や表も読まれ、101〜1,000ページではテキストだけが処理されます。ページを指すときは、PDFビューアに表示されるページ番号を使います。記事に印刷されたページ番号とはずれることがあるので、依頼文に書く番号は本文の段落番号にそろえるのが安全です。

次の記事は、当社が発表したプレスリリースを元に書かれた、公開済みの記事です。
記事の中から、当社に関する数字、日付、社名、製品名、サービス名、
肩書、人名、引用(カギ括弧)をすべて抜き出し、
ナレッジのリリース原本とファクトシートに照合してください。
結果は表にして、列は
「記事の記載(段落番号つき)/ リリースの記載 / ファクトシートの値 / 判定」にしてください。
依頼文はまだ書かないでください。
 
【記事】
(ここに貼る)

段落番号を求めるのは、後で依頼文に「第3段落の」と書くためです。

返ってくる表は、次のような形になります。以下は架空の記事を使った形式の例で、実際の出力は記事と資料によって変わります。

判定が付いたら、表を自分の目で見ます。Claudeの判定は一次案です。「記事側の誤りの疑い」と付いた行も、リリースの該当箇所を実際に開いて確かめます。

判定ごとに、動き方を変える

表の判定は、そのまま依頼文に使えるわけではありません。判定ごとに次の動きが変わります。

数字の大小に関わる誤りと、表記のゆれでは、重みが違います。導入社数の桁違いは読者の判断に影響しますが、社名の「株式会社」が前か後ろかは、媒体の表記ルールで揃えられている場合もあります。優先度を付けるときは、依頼する行を人が選び、印を付けます。

依頼文をトーン別に作る

訂正依頼は、相手との関係や誤りの重さで、適切な強さが変わります。Claudeには同じ事実を3つのトーンで書かせ、比べて選びます。

依頼するときの指示は、次のようにします。

上の表のうち、私が「依頼する」と印を付けた行だけを使い、
訂正依頼の文面を3つのトーンで書いてください。
トーン1: 取材でやりとりのあった記者宛て。お礼から始める。
トーン2: 事実を淡々と示す。修正箇所と根拠を箇条書きにする。
トーン3: 媒体の訂正窓口宛て。記事のタイトル・公開日・URLを冒頭に置く。
共通の条件:
- 修正箇所は「段落番号 / 記事の記載 / 正しい記載 / 根拠」の形にする。
- 根拠は、リリースの発表日と該当箇所にする。
- 記者の責任を断定する表現、感情的な表現は入れない。
- 表現や論調の変更依頼は入れない。事実の訂正だけにする。
- 敬体で、前置きは短くする。

文面の例を1つだけ載せます。こちらもClaudeの実出力ではなく、依頼文の形を示す架空の例です。

件名: 【記事内容のご確認】10月18日掲載「サンプルテック、新サービス提供開始」について
 
〇〇様
 
このたびは弊社の新サービスを取り上げていただき、ありがとうございます。
記事を拝見し、次の点について事実関係をご確認いただけないでしょうか。
 
・第2段落
  記載: 2026年10月1日提供開始
  正しい記載: 2026年10月15日提供開始
  根拠: 10月3日付プレスリリース「新サービス提供のお知らせ」本文冒頭
 
お手数をおかけしますが、ご確認のうえ、必要に応じて修正をご検討ください。

件名に日付と記事のタイトルを入れておくと、相手が該当記事をすぐ探せます。

Claudeに書かせると、丁寧すぎて何を直してほしいのか分からない文面になることがあります。そのときは「修正箇所を先頭に置く」「お詫びの表現を減らす」と重ねて指示し、人が最終版に仕上げます。

送る前の確認

依頼は、押し間違えると関係を傷つけます。送信前に、次を人の目で確かめます。

• リリース原本の該当箇所を、自分で開いて読み直したか
• ファクトシートの基準日が、記事の公開日より古くなっていないか
• 「リリース自体の誤りの疑い」の行が、依頼文に紛れていないか
• 記事の評価語や論調の変更が、事実の訂正に混ざっていないか
• 広報責任者や上長に、送信の可否を確認したか
• 法的な争点がありうる内容は、法務や外部の専門家に相談したか

最後の項目には、Claudeの出番はありません。名誉や信用に関わりうる誤りは、依頼文の下書きを作る前に、社内の判断を仰ぎます。

共有範囲の注意

記事自体は公開情報ですが、ファクトシートや社内の根拠資料は未公開です。Team・Enterpriseプランのプロジェクトは組織内で共有でき、「Can view」でも内容と指示を見られます。「Can edit」ではナレッジと指示を変更できます。誰がメンバーかを確認してから資料を入れます。

プロジェクト名や説明にも、資料名や機密の案件名を書かないようにしておくと、共有したときの漏れを減らせます。

依頼の後に残すもの

送信した依頼文と、媒体からの返答は、記録して残します。訂正が反映されたかを、後で確認できるからです。反映の仕方は、記事の末尾の追記、本文の修正、訂正記事の掲載など、媒体によって異なります。

もう一つ残すのは、再発の防止です。誤りが記者の読み違いを誘う書き方だったなら、次のリリースの書き方を直します。数字には基準日と定義を添え、固有名詞の正式表記を1か所にまとめておくと、転記のずれが減ります。ファクトシートの作り方はプレスキットのファクトシートの作り方にまとめています。

リリースの文面そのものを見直すときはプレスリリースの文面を下書きする手順が使えます。同じ誤りが他の媒体に転載されていないかは、メディアクリッピングの手順で掲載記事を一覧にしておくと見渡せます。

自社に非がある場合は、訂正依頼ではなく謝罪の文面が必要になります。その場合はお詫び文と謝罪リリースの初動声明を参照してください。