法務確認で止まらない事例記事をChatGPTで作る手順

1. 初稿を作ったら、法務から差し戻される

事例記事を書きました。顧客にも確認を取り、内容も問題ありません。社内の法務部門に回します。

3日後、赤字だらけで戻ってきます。

「導入効果を断定している」「競合名を明示している」「未確認の数字が入っている」「掲載許可の範囲を超えている」。修正して再提出すると、また別の箇所が指摘されます。

結局、公開まで3週間かかりました。次の事例でも同じことが起きます。

2. なぜ、法務確認で止まるのか

原因1：法務が見る基準を、書く側が知らない

記事を書くときは「顧客の成果を魅力的に見せる」ことを考えます。法務が見るのは「この表現が法的リスクを生まないか」です。

見る視点が違うため、書く側が良いと思った表現が、法務から見るとリスクになります。導入効果を「削減できます」と書くと景品表示法の優良誤認に触れる可能性があり、競合名を出すと不正競争防止法の問題になる可能性があります。

書く側が法務の基準を知らないまま書くと、初稿の段階で既にリスク箇所が複数入っています。

原因2：リスク箇所が構成の段階で埋め込まれている

法務のチェックは、文章が完成した後に回ってきます。しかし、リスクの多くは文章の段階ではなく、構成の段階で埋め込まれています。

「競合との比較」を構成に入れると、競合名を書く必要が出ます。「導入効果」を見出しにすると、効果を断定する文章を書く必要が出ます。構成の段階でリスク箇所を避けておかないと、文章でどう書いても法務が止めます。

原因3：代替表現の引き出しがない

法務から「この表現は使えない」と言われたとき、すぐに代替表現が出てこないと、修正に時間がかかります。

「削減できます」が使えないとき、「削減した事例があります」と書けば事実の記述になります。「競合A社より優れている」が使えないとき、「他社製品と比較して選定基準を満たしていた」と書けばリスクを避けられます。

代替表現のパターンを持っていないと、法務とのやりとりが何往復もします。

3. ChatGPTで法務確認をパスする記事を作る手順

ここからが実践です。法務に回す前に、リスク箇所を洗い出して代替表現に置き換えます。ChatGPTを使い、法務の基準を満たす記事を最初から作ります。

ステップ1：法務が止める表現のパターンをリスト化する

まず、過去に法務から指摘された表現を集めます。自社の事例記事で実際に差し戻された箇所を、Excelやスプレッドシートに記録しておきます。

次のプロンプトで、指摘のパターンを分類します。

以下は、過去に法務から指摘された表現のリストです。

【指摘された表現】
1. 「導入後、コストを30%削減できます」→「削減できる」が断定表現
2. 「競合A社より使いやすい」→ 比較優位の主張
3. 「業界No.1の導入実績」→ 根拠不明の最上級表現
4. 「顧客満足度が向上しました」→ 測定方法が不明
5. 「法令に準拠しています」→ 具体的な法令名がない
<実際に指摘された内容を追加>

このリストを、次の4つのリスクカテゴリに分類してください。
1. 景品表示法リスク（優良誤認、有利誤認）
2. 不正競争防止法リスク（競合の信用毀損）
3. 事実の裏付けリスク（数字の根拠不明）
4. 掲載許可の範囲リスク（顧客の許可を超えている）

各カテゴリごとに、NG表現と推奨表現を対にして表にしてください。

このプロンプトを実行すると、法務が止める表現のパターンが整理されます。

ステップ2：構成の段階でリスク箇所を洗い出す

記事の構成を作った段階で、ChatGPTにリスク箇所を指摘させます。文章を書く前に構成でリスクを潰しておけば、書き直しが最小限になります。

次のプロンプトで、構成をチェックします。

以下の事例記事の構成を、法務リスクの観点でチェックしてください。

【構成】
1. 導入前の課題
2. 選定理由（競合との比較を含む）
3. 導入プロセス
4. 導入後の成果（数値を含む）
5. 今後の展開

【チェック基準】
- 景品表示法リスク: 効果を断定する見出しはないか
- 不正競争防止法リスク: 競合との比較を直接書く構成はないか
- 事実の裏付けリスク: 根拠がない数字を使う構成はないか
- 掲載許可の範囲リスク: 顧客が許可していない情報を含む構成はないか

リスクがある見出しを指摘し、代替の構成案を提示してください。

このプロンプトを実行すると、構成の段階でリスク箇所が洗い出され、修正案が提示されます。

ステップ3：初稿を書く前に、法務NGワードを除外する

構成が固まったら、初稿を書き始めます。このとき、法務がNGとする表現を最初から使わないように指示します。

次のプロンプトで、法務基準を満たす文章を生成します。

以下の構成で事例記事の初稿を書いてください。

【構成】
<ステップ2で修正した構成を貼り付ける>

【書く際の制約】
1. 導入効果は「〜できる」ではなく「〜した事例がある」と書く（断定を避ける）
2. 競合名は出さず「他社製品と比較検討した結果」と書く
3. 数字は顧客が公開を許可した範囲のみ使う（未確認の数字は書かない）
4. 「業界No.1」「最高」などの最上級表現は使わない
5. 「満足度向上」などの抽象的成果は、具体的な行動変化で書く

この制約を守って、3000字程度で初稿を作成してください。

このプロンプトを実行すると、法務基準を満たした初稿が生成されます。

ステップ4：書き上がった記事を、法務の視点で自己チェックする

初稿が完成したら、法務に回す前に自分でチェックします。法務と同じ視点で見ることで、差し戻しを減らせます。

次のプロンプトで、記事全体をチェックします。

以下の事例記事を、法務チェックの視点で確認してください。

【記事全文】
<初稿の全文を貼り付ける>

【チェック項目】
1. 景品表示法リスク: 「〜できます」「必ず〜」などの断定表現はないか
2. 不正競争防止法リスク: 競合名、競合製品の批判表現はないか
3. 事実の裏付けリスク: 数字の出典が不明な箇所はないか
4. 掲載許可の範囲リスク: 顧客が許可していない情報はないか
5. 表現の曖昧さ: 「向上」「改善」など測定不能な表現はないか

リスクがある箇所を指摘し、修正案を提示してください。

このプロンプトを実行すると、法務が指摘しそうな箇所が事前に洗い出されます。

ステップ5：法務が指摘しやすい箇所に、根拠を先回りして添える

法務がよく指摘する箇所には、指摘される前に根拠を添えておきます。これにより、法務の確認時間が短くなります。

次のプロンプトで、根拠を追加します。

以下の記事の中で、法務が「根拠は？」と聞きそうな箇所を特定してください。

【記事全文】
<チェック済みの記事を貼り付ける>

特定した箇所に、次の形式で根拠を追加してください。
- 数字の場合: （出典: 顧客提供資料、取材時のヒアリング内容）
- 導入効果の場合: （顧客A社の事例。導入時期: 2024年4月）
- 業界動向の場合: （出典: 〇〇調査レポート 2024年版）

根拠を追加した記事を出力してください。

このプロンプトを実行すると、法務が確認しやすい形に記事が整います。

ステップ6：法務からのフィードバックをパターン化する

法務のチェックを受けた後、指摘内容をパターンとして記録します。次の事例で同じ指摘を受けないようにするためです。

次のプロンプトで、フィードバックを整理します。

法務から次のフィードバックを受けました。

【フィードバック】
<実際の指摘内容を貼り付ける>

このフィードバックを、次の形式で整理してください。
1. 指摘された表現（元の文章）
2. 指摘の理由（どの法的リスクに該当するか）
3. 修正後の表現（法務が承認した文章）
4. 今後のチェックリスト（次回から避けるべき表現）

この整理結果を、ステップ1で作ったリスクリストに追加してください。

このプロンプトを実行すると、法務の基準が蓄積され、次の事例で活用できます。

4. それでも残る限界

法務の基準を満たす記事を書けるようになっても、別の問題が出ます。

法務の基準は会社ごとに違います。 他社の事例記事で使われている表現が、自社では使えないこともあります。業種、事業内容、過去の法的トラブルの有無によって、法務が許容する表現の範囲は変わります。

法務の基準は時間とともに変わります。 法改正、業界のガイドライン変更、競合の訴訟事例などにより、法務が厳しくチェックする箇所が変わります。去年は問題なかった表現が、今年はNGになることもあります。

法務とのコミュニケーションコストは残ります。 リスク箇所を減らしても、法務の確認は必要です。修正の往復は減りますが、ゼロにはなりません。

5. 受け渡しごと仕組みにする

sonata は、事例記事の制作工程そのものをプロダクトの構造にしたサービスです。取材先の事前調査、設問の用意、音声のアップロード、構成、初稿までが一連の流れとしてつながっていて、工程間の受け渡しが自動で進みます。この音声から記事化までの一連のワークフローについて特許を出願しています。

構成段階で法務リスクをチェックする工程を組み込んでおけば、初稿の時点で法務基準を満たした記事が生成されます。過去の法務指摘をテンプレートとして保存しておけば、次の事例では同じ指摘を受けません。

生成した記事は Markdown と HTML で書き出せ、法務確認用のPDF、社内共有用のドキュメント、公開用のWebページへそれぞれの形式で展開できます。

詳しくは sonata の導入事例ページ をご覧ください。