公開前チェックをAIに任せる。機密混入・炎上・顧客視点の事前検知

プレスリリース、SNSの投稿、提案書、採用ページ。
社外に出た後に問題が見つかるものには共通点があり、出す前に本人以外の目がまったく入っていません。

多くの場合、担当者のほうに落ち度はありません。
締切があり、確認できる人が不在で、自分の文章の粗は自分では見えないからです。
組織として工程が用意されていない点のほうが、原因としては大きいはずです。

ということで、公開前の炎上チェックをAIに任せて工程として組み込む方法を整理していきます。
成果物の品質を組織でそろえる話の全体像はAIアウトプットの品質を組織でそろえる。標準化とレビュー体制にまとめてあります。

「出してから気づく」は工程を足すしかない

対策として真っ先に出てくるのが注意喚起と研修ですが、ほとんど効きません。

なぜ、ここまで効かないのでしょうか？
気をつけている人でも見落とすのは、自分が書いた文章を客観的に読むのが能力ではなく立場の問題で、書いた本人には意図のほうが見えてしまうからです。
もう1つ、チェックできる人の時間がそもそも空いておらず、広報や法務に事前確認を回す運用でも繁忙期には滞留します。

滞留すれば、締切に間に合わせるために確認を飛ばす判断が現場で起きます。
つまり必要なのは、人の時間を使わずに1回通せる工程です。

ここが、AIの使いどころになります。

チェック観点は3種類に分け、厳しさを変える

公開前に見るべきことは性質の違う3つに整理でき、まとめて1つのチェックにすると精度が落ちるので、最初から分けておきます。

「機密混入」は、取引先の実名や未公表の数値、社内でしか使わない用語、個人が特定できる記述が混ざっていないかを見る観点です。
文書の作成中に参考資料から引き写した部分に、とくに混ざりやすくなります。
何が該当するかの線引きは生成AIに入れてはいけない情報とは。社内ルールを3段階で線引きするにまとめてあります。

「炎上リスク」は、属性への言及や断定的な優劣の表現、時事的な話題との距離など、読み手によって不快に受け取られる表現がないかを見る観点です。
書いた側に悪意がない場合が大半で、自己点検では見つかりません。
スコアの形で見る方法は炎上リスクを公開前にスコアで見る。広報リスク管理の実装で扱っています。

「顧客視点の粗さ」は、前提の説明がないまま専門用語で書かれていないか、根拠の示されていない主張がないかを見る観点です。
炎上ではなく、単純に伝わらない問題になります。
複数の目を通す工程は公開前レビューを複数の目で行う。ペルソナ別レビューを工程に入れるにまとめてあります。

3つを1回のチェックで済ませようとすると、どれかが必ず甘くなるので、観点ごとに分けて3回通すのが確実です。
分けたうえで、見方のほうも変えます。

機密混入は機械的に見て、「社外に出せない情報が含まれていないか、該当箇所を列挙してください」と、判断ではなく抽出のほうを求めます。
判断させると「文脈上問題ない」という結論が混ざり、そこから見落としが生まれます。

炎上リスクは厳しい読み手を想定させ、「この文章に不快感を持つ可能性のある読み手を想定して、該当箇所と理由を挙げてください」と頼みます。
指摘が多すぎると使いにくくなるので、上位3件に絞らせると実用になります。

顧客視点は知識のない読み手を想定させ、「業界を知らない読み手が読んで、分からない箇所と根拠が示されていない箇所を挙げてください」と頼みます。
この観点は、リスク対策というより品質向上のほうに効きます。
3つとも共通して、修正案までは出させず、指摘だけを受け取って直すのは人がやる形にします。

修正案をそのまま採用すると、文章の一貫性が崩れてしまいます。

この作業に使える業務ツール「炎上リスクチェック」は、詳しいページでできることと使い方を紹介しています。

導入は担当者の自主運用から、全社の公開フローへ3段階で進める

導入はここでも段階を踏みます。
最初から全社の公開フローに組み込もうとすると、合意形成のところで止まってしまうからです。

まずは担当者が自分の判断で回す段階で、3つの依頼文を用意して、社外に出す文書を書いたら自分で通すというだけです。
誰の承認も要らずに明日から始められ、この段階で重要なのは指摘が当たった事例を記録する点です。

「この投稿でこの表現を指摘され、直して出した」という実例が3件たまると、次の段階に進む材料になります。
効果は数字ではなく事例で示すほうが、この施策では効きます。

事例がたまってきたら、次は部門の中で工程として定着させます。
やることは2つあります。
依頼文を部門で共有することと、チェックを通したかどうかを提出時に確認する項目にすることです。

依頼文を各自が自分で書く状態だと精度がばらつくので、3観点の依頼文を部門の標準として1組決めて、それを使ってもらいます。
また、自社固有の観点も追記します。
自社の商標の表記、使ってはいけない表現、業界の規制に関わる言い回しなど、汎用の依頼文に自社の事情を足すと精度が上がります。

提出フォームやテンプレートには「3観点のチェックを通した」という欄を置きます。
個人の心がけにしないための工程化が、ここで進みます。

最後に全社の公開手続きのほうに組み込み、この段階で決めることは4つあり、まず対象の範囲からです。
すべての社外文書を対象にすると回らないので、プレスリリース、公式SNS、Webサイトの掲載文、採用関連、官公庁や大口取引先への提出物の5種類に絞ると運用できます。

次に、人の確認をどこに残すかを決めておきます。
AIのチェックはあくまで一次スクリーニングであって、最終判断ではないからです。
上の5種類のうちプレスリリースと採用関連は、人の確認を必須にする線を引きます。
対外文章そのものの基準は「AIが書いた感」を組織として許容しない。対外文章の品質基準を決めるで扱っています。

3つ目に、例外運用として緊急で出す必要がある場合の手順を決めておきます。
ここを決めていないと、緊急時にフロー全体が無視されて、その後も戻りません。
「事後に必ず通して記録する」という形にしておくと、抜け道のほうが制度に載ります。
経営のリスク管理として位置づける話は事前チェックを経営リスク管理に組み込む。炎上・法的問題の早期検知にまとめてあります。

4つ目に、指摘を通す基準も決めておきます。
チェックを通せば当然指摘が出ますが、そのすべてに対応するのかを決めていないと現場が判断できません。
現実的な線引きは「機密混入の指摘は必ず対応、炎上リスクは判断、顧客視点は任意」で、機密については例外を作りません。

炎上リスクは指摘の理由を読んで担当が判断し、迷ったら上に上げます。
顧客視点は品質向上なので、時間があるときに直します。

この3段階を明示しておけば、指摘が多く出ても工程は止まりません。
全部直そうとすると工程が重くなり、結果として飛ばされます。

例外の扱いや指摘への対応基準を社内ルールとして書き残すときは、生成AIの社内ルールの作り方。ガイドラインの項目サンプルと守れる環境と書き方をそろえておくと迷いません。

同じ失敗が、毎回同じ順番で起きる

1つのチェックで全部を見ようとすると、3観点を混ぜてどれかが必ず甘くなるので、分けたうえで3回通します。

修正案をそのまま採用するのも失敗のもとで、指摘の受け取りと修正の工程を分けておかないと文章の一貫性が崩れます。
全社導入から始めるのも危険で、合意形成に時間がかかり、その間に事故が起きます。
担当者の自主運用から始めて、事例で示すほうが早く進みます。

例外運用を決めないままにするのも、よくある失敗です。
緊急時に一度飛ばされてしまうと、その後も元には戻ってきません。

同じチェックを全社で共有できるか

ここまで書いてきたとおり、この施策の中身は3つの依頼文と工程の設計だけで、作ること自体は難しくありません。
分かれ目は、その3つを全社で同じものとして使える状態にできるかというところです。
各自が自分で書いた依頼文を使っている状態だと部門ごとに精度が違い、事故は精度の低いところで起きます。
自社固有の観点を追記した最新版が、全員の手元にある状態が必要です。

こうしたチェック用の依頼文をAIボットにしておけば、私たちの組織のAIポータル「AI Portalize」に登録して全社に公開でき、部門をまたいで同じものを使えるようになります。
作った依頼文が部門に閉じている場合は、考え方の参考になるかもしれません。

1回通す工程を足すことが、注意喚起より確実に効く

公開後になって気づく事故は、注意喚起では防げません。
人の時間を使わずに1回通せる工程を足すほうが、現実的な対策になります。

観点は「機密混入・炎上リスク・顧客視点」の3つに分けて、それぞれ厳しさを変えたうえで別々に通します。
修正案は出させず、指摘だけを受け取ります。

導入は担当者の自主運用から部門の標準工程、全社の公開フローへと3段階で進めます。
対象は5種類に絞り、例外運用は最初に決めておきます。

通す基準は「機密混入は必ず対応・炎上リスクは判断・顧客視点は任意」の3段階です。
全部直そうとすると工程が重くなり、結局そのまま飛ばされます。
3観点の依頼文を1組作り、社外に出す文書で実際に通してみると、足りない観点が分かります。