各部署から集まるメモ・写真の説明・イベントの記録から毎月の社内報の記事を下書きし、表記ルールと個人情報の載せ方の点検まで済ませる

処理の起点を決める

投稿フォームに回答が届いたときに、1本ずつ動かします。 締切日にまとめて動かす作りにはしません。

3行目の締切の前日の知らせは、点検の結果を使った仕組みです。 「了承の確認待ち」の記事が残っていれば、部署の担当者に1通で知らせます。第3章の（c）の「返事が来ないまま締切」を、締切の前日に一度だけ拾い直します。

再投稿は、題材のIDで同じ行を探して更新します。 新しい行を作ると、同じ記事の下書きが2本並び、古い版の点検の結果を見て判断することになります。

入力データを集める

質を決めるのは、2行目の「掲載の了承の有無」です。 投稿フォームで登場する人を1人ずつ書かせ、了承の有無を選ばせます。ここが空欄だと、点検の結果は「確かめてください」としか言えません。 フォームの設問を必須にします。

個人の情報の決まりは、この構成を始める前に総務部で作ります。 例えば、病気や療養の話、家族の話、出産や育児の話、住所や私生活の話は本人の了承がある場合だけ載せる、取引先の担当者の名前は載せない、退職した人の写真は載せない、です。決まりが無いまま点検させても、AIは基準を持てません。

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

写真のファイルは、部署の担当者が SharePoint の記事ごとのフォルダに置き、フォームにはファイル名を書いてもらいます。 フォームの回答とファイルを、ファイル名で結びます。写真をAIに渡さないのは、コネクタが画像を扱わないことに加え、写った人の顔をAIに読ませる必要がないからです。

過去の記事は、文体と長さの見本として渡します。 渡さないと、AIは新聞記事のような硬い文体か、広告のような明るすぎる文体のどちらかに寄ります。自社の社内報の調子を、例で伝えます。

AIへ渡す前に整形する

1. 必須の欄を確かめる … 題材、日時、メモ、登場する人の了承の有無が空なら、AIに渡さず、部署の担当者に差し戻しのメールを送ります
2. 登場する人の一覧を作る … 了承済み・確認中・了承なしの3つに分け、指示に添えます
3. メモの長さを確かめる … 5,000字を超えるメモ（議事録の全文など）は、そのままではなく要点を書いてもらうよう差し戻します
4. 表記ルールと決まりを差し込む … 毎回、最新の一覧をファイルから読みます
5. 過去の記事を選ぶ … 題材の種類（改善発表、展示会、表彰、地域活動、サークル）で絞ります

1番目の差し戻しが、第3章の（d）への答えです。 メールで届いていた材料は、何が足りないかを広報担当が読んで気づくものでした。フォームの必須の欄と、フローの検査で、足りない材料が下書きの前に戻ります。

2番目の一覧は、AIの点検とは別にフローの規則でも使います。 下書きの本文に「了承なし」の人の名前が入っていたら、AIの点検の結果にかかわらず、フローが印を付けます。 名前の照合は文字列の一致なので、AIに任せる必要がありません。

AIに処理させる

させるのは、下書きを書くことと、3種類の点検の結果を返すことです。

4行目が、この構成でいちばん大事な欄です。 「参加者は熱心に耳を傾けていました」「今後の活躍が期待されます」。AIは材料に無い描写を自然に足します。 社内報では無害に見えますが、「熱心に」と書かれた本人がその場にいなかったら、記事は事実と違います。 補った箇所を返させ、広報担当が残すか消すかを決めます。

表記の指摘は、AIに直させずに挙げさせます。 下書きの本文は、表記ルールに沿って書かせますが、材料の側の表記（部署の担当者が書いた文の引用）は直しません。 引用の中の表記を直すと、誰かの発言を書き換えることになります。

指示内容を固定する

システムメッセージ：

あなたは製造業の総務部で、毎月の社内報の記事を下書きする担当です。
部署から届いた材料だけを使って記事を書き、点検の結果を添えてください。
出力は指定したJSONの形だけにしてください。

【書き方】
- 見出しは25字以内、リード文は60字前後、本文は300〜500字にしてください。
- 文体は【過去の記事】に合わせてください。
- 表記は【表記ルール】に沿って書いてください。
- 部署の担当者や登場する人の言葉をかぎかっこで引用するときは、
  材料に書かれたとおりに写し、表記を直さないでください。

【厳守事項】
- 材料に書かれていない数字・日付・人名・場所を書かないでください。
- 材料に無い描写や評価（雰囲気、気持ち、今後への期待など）を本文に
  書いた場合は、その文を added_content にすべて写してください。
- 材料が足りず記事にできない点は、本文に書かず missing_info に書いてください。
- 【登場する人】で consent が none の人の名前を本文と写真の説明文に
  書かないでください。pending の人は書いてよいですが、personal_checks に
  必ず挙げてください。
- 写真の説明文は、材料の写真の説明に書かれた人の並びだけを使ってください。

【点検】
- notation_issues … 本文と見出しのうち【表記ルール】に合わない箇所を、
  該当の文字列と、ルールに沿った書き方の組で挙げてください。
  ルールに無いものは挙げないでください。引用の中は挙げないでください。
- personal_checks … 次に触れた箇所をすべて挙げ、該当する種類を付けてください。
  name（人名）／family（家族）／health（病気・けが・療養・通院）／
  childcare（妊娠・出産・育児・介護）／private（住所・私生活・趣味の詳細）／
  outside（社外の人・取引先・顧客）
  迷ったら挙げてください。
- 掲載してよいかどうかは書かないでください。

【表記ルール】{notation_rules}
【個人の情報の決まり】{personal_rules}
【過去の記事】{examples}

ユーザーメッセージ：

【部署】{department}
【題材の種類】{topic_type}
【日時と場所】{date_place}
【メモ】{memo}
【写真の説明】{photo_captions}
【登場する人】{people_with_consent}
【記事にしたい理由】{reason}

「材料に無い描写を書いたら added_content に写す」は、書くなと禁じるより効きます。 禁じても足されることがあり、足されたことが分からなくなります。書いた場合に申告させると、広報担当は申告された文だけを見れば済みます。

了承の扱いを3つに分けて書くのも同じ理由です。 none は書かせない、pending は書いてよいが必ず挙げさせる。「確認中」の人を一律に外すと、了承が取れた後に下書きを書き直すことになります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "post_id": "",
  "headline": "",
  "lead": "",
  "body": "",
  "photo_captions": [""],
  "missing_info": [""],
  "added_content": [""],
  "notation_issues": [
    { "found": "", "suggested": "", "rule": "" }
  ],
  "personal_checks": [
    { "text": "", "type": "name | family | health | childcare | private | outside", "person": "" }
  ]
}

コネクタの JSON モードは、決めた欄がそろうことまでは保証しません。 そこで Power Automate の「JSON の解析」でこの形を当て、欄が欠けていれば下書きを作り直し、2回続けて欠ければ広報担当に「下書き失敗」として知らせます。

JSONで受ける理由は3つです。 1つ目は、下書きと点検の結果をリストの別の列に入れられることです。広報担当は一覧で personal_checks の件数を見て、確認の順を決められます。2つ目は、added_content の文を本文の中で探して、リストの表示で色を付けられることです。 3つ目は、フローの規則で照らせることです。

1行目は、AIが指示を守ったかを規則で確かめる工程です。 「了承なしの人を書かない」と指示していても、材料のメモにその人の名前が何度も出てくると、本文に入ることがあります。 名前の文字列で照らせば、確実に拾えます。

システムへ連携する

SharePoint のニュースのページには、自動で書き込みません。 下書きはリストに置き、広報担当が直して総務部長が確認したものだけを、人がページに写します。AIの下書きが確認を経ずに全社に出る経路を作りません。

部署への問い合わせのメールは、送る前に広報担当が目を通します。 本人に関わる確認（療養の話を載せてよいか）は、聞き方を誤ると本人の負担になります。文面は下書きまでにして、送るのは人です。

人が確認する

広報担当が、投稿のたびに次の順で見ます。

1. 「掲載不可の名前あり」の印 … その名前を消すか、部署に了承を取り直してもらうかを決めます
2. 「本人確認」の印と personal_checks … 健康・育児・家族の話を載せてよいか、部署の担当者を通じて本人に確かめます。了承が取れなければ、その部分を消します
3. missing_info … 部署への問い合わせを送るか、その点に触れずに記事にするかを決めます
4. added_content … 補われた文を、残すか消すか決めます。事実と確かめられない描写は消します
5. notation_issues … 表記の指摘を受け入れて本文を直します
6. 全体を読む … 見出しとリード文が記事の中身に合っているかを見ます

総務部長の確認は、月に1回、全記事をまとめて行います。 広報担当が直した後の記事と、personal_checks に何が挙がり、どう扱ったかの一覧を並べて見ます。部長が見るのは記事の出来よりも、個人の情報の扱いが決まりどおりだったかです。

目標は、30本をならして1本20分です。 個人の情報に触れない記事（展示会、改善発表）は数分の手直しで済み、本人確認の要る記事は確認のやり取りに時間がかかります。

例外に対処する

4行目のコンテンツのフィルターは、工場の社内報では意外と起きます。 安全活動の記事で、過去の労働災害の描写がメモに書かれていることがあります。フィルターで止まった記事は、AIで書き直そうとせず、広報担当が手で書きます。

記録を残す

• 投稿フォームの回答と、そのときの登場する人と了承の有無
• Azure OpenAI に渡した指示（表記ルールと決まりの版を含む）と、返ってきたJSONの全文
• フローの規則が付けた印（掲載不可の名前、本人確認、社外の人）
• 広報担当が personal_checks と added_content をどう扱ったか（残した・消した・確認した）
• 部署に送った問い合わせと、返ってきた答え
• 掲載した記事の最終版と、下書きとの差分

4つ目の記録が、この構成でいちばん大事なログです。 載った後に本人から申し出があったとき、誰が、いつ、どの了承を根拠に載せたかを示せます。 了承は投稿フォームの回答に残っているので、記事と結んで保存します。

最後の差分は、下書きの質を測るためです。 本文の大半が書き直されている題材の種類があれば、過去の記事の見本か、表記ルールの渡し方を見直します。