社内向けのお知らせ文を、決まったことのメモから体裁の整った通知にする

処理の起点を決める

社内に知らせるべきことが決まった時点が起点です。システム上のトリガーはありません。

ただし、通知が必要なことに気づく仕組みは作れます。

• 定例会議の議事録に「社内通知の要否」の欄を作る。 決定事項ごとに、通知が要るかを書く
• システム保守の予定表から逆算する。 保守の2週間前に通知を出す、と決めておく

入力データを集める

「決まったことのメモ」は整える必要がありません。 箇条書き、言い切らない文、順序がばらばらでも構いません。整えようとする時間が、まさに削ろうとしている時間です。

データの取得方法を決める

通知の型： 総務が作ります。種類ごとに、どの順序で何を書くかを決めます。たとえば次のようにします。

「問い合わせ先」がすべての型の末尾にあるのは意図的です。 これが抜けた通知は、総務への個別の問い合わせを増やします。

過去の通知文： ポータルから、種類ごとに評判のよかったものを2件ずつ選びます。多く入れすぎないでください。 10件入れると、下書きの構成が過去の文章の平均に寄り、型が効かなくなります。

必須項目リスト： 型とは別に、どの通知にも共通して必要な項目を挙げます。発信部署、発信日、対象者、いつから、何をすべきか、問い合わせ先。

AIへ渡す前に整形する

担当者が特別な前処理をする必要はありません。総務がプロジェクトを作るときの準備が、実質的な前処理です。

1. 型を4〜5種に絞る … 通知の種類を細かく分けすぎないでください。10種類あると、どれを使うか判断する時間が発生します
2. 過去の通知から社名・個人名を除く … 知識として入れる過去の通知に、取引先名や個人名が入っていれば伏せます
3. 呼称ルールを書く … 「営業本部」なのか「営業部」なのか、「勤怠システム」なのか正式名称なのか。ここを決めておかないと、下書きに揺れた呼称が出ます
4. 使わない表現を挙げる … 「鋭意」「善処」「順次」のような、時期が特定できない表現。「なるべく」「可能な限り」のように、必須かどうかが分からない表現。これらを禁止するだけで、通知の質が変わります
5. 必須項目を決める … 6項目程度に絞ります

AIに処理させる

「不足の指摘」を出力の最後に必ず置かせてください。 下書きが整った文章で出てくると、不足があることに気づきにくくなります。空欄にして質問として残す形にします。

指示内容を固定する

プロジェクトの指示（すべてのチャットに適用される）に、次を設定します。

あなたは総務部の担当者として、社内向けのお知らせ文を作ります。
決まったことのメモを渡すので、添付した型に沿って本文を作ってください。

【厳守事項】
- メモに書かれていない日付、人数、金額、部署名を
  書かないでください。書かれていない項目は
  【要確認：対象者の範囲】のように、記入欄として残してください。
- 時期を「順次」「なるべく早く」「追ってご連絡」と書かないでください。
  日付が決まっていなければ【要確認：開始日】として残してください。
- 背景や経緯を長く書かないでください。
  読み手が知る必要のある範囲（なぜ変わるのか）を2文までにしてください。
- 「ご理解とご協力をお願いいたします」で終わらせないでください。
  末尾は必ず、問い合わせ先と、読み手がすべきことで終えてください。
- 部署名・役職名・システム名は、添付の呼称ルールの表記を使ってください。
- 本文のあとに、次の2つを線で区切って必ず出してください。
  （1）決まっていない項目の一覧（関係部署に確認すべきこと）
  （2）件名の候補3案

【型】添付ファイルのとおり
【過去の通知例】添付ファイルのとおり
【呼称ルール】添付ファイルのとおり
【必須項目リスト】添付ファイルのとおり
【使わない表現のリスト】添付ファイルのとおり

「順次」「なるべく早く」を禁止する指示が、この構成で一番効きます。 これらの語は、書き手が日付を確認していないときに出ます。禁止すると、決まっていないことが【要確認】として表に出ます。

「ご理解とご協力をお願いいたします」で終わらせない指示も同じ意図です。 この一文は、読み手が何をすべきかを書かずに終わるときの締めくくりとして使われます。

出力形式を固定する

自由文で構いませんが、構成を固定します。

【件名】（下の候補から選んでください）

【本文】

────────────────
確認が必要な項目
- 
- 

────────────────
件名の候補
1. 
2. 
3. 

線で区切った2ブロックを本文の後に置くのは、ポータルに貼り付けるときに消し忘れないためです。

システムへ連携する

システム連携はありません。 担当者が本文をコピーして、ポータルの投稿画面とメールに貼り付けます。

自動投稿の仕組みを作りたくなりますが、この構成では作りません。理由は2つあります。ひとつは、誤った内容が全社に届く事故を避けるため。 もうひとつは、宛先の判断が毎回違うためです。全社なのか、特定拠点なのか、管理職だけなのか。ここは型では決まりません。

人が確認する

下書きは全件、担当者が読んで直します。上長の確認もこれまでどおり行います。

確認すべき点を、下書きの末尾の【確認が必要な項目】で示させます。加えて、担当者が必ず見る点を運用で決めます。

• 【要確認】が残っていないか
• 日付、人数、金額が、メモに書かれたとおりか
• 対象者の範囲が正確か（「全社員」と「正社員のみ」は別です）
• 問い合わせ先が実在する窓口か

「対象者の範囲」は特に注意してください。 生成AIは「全社員の皆様へ」と書きがちです。派遣社員やパートタイマーが対象外の制度変更で「全社員」と書くと、誤った通知になります。

例外に対処する

記録を残す

特別なログは不要です。 通知そのものはポータルとメールに残ります。

残すとよいのは次の2つです。

• 通知の種類ごとの件数（月次で数える）
• 【要確認】として挙がった項目のうち、多いもの

2つ目が運用の改善につながります。「経過措置の有無」が毎回【要確認】に挙がるなら、決定の段階でそれを決める習慣がないということです。会議の決定事項の様式に項目を足せば、通知を書く前に決まります。これは通知文を速く書くことより効果があります。