エステサロンがチラシと Web の告知の原稿を Azure OpenAI で校正し、景品表示法・特定商取引法と医行為に当たる表現の決まりに沿って直しの案を出す

処理の起点を決める

SharePoint の「原稿の確認待ち」フォルダにファイルが作られたことを起点にします。 Power Automate の SharePoint コネクタの「ファイルが作成されたとき（プロパティのみ）」を使い、フォルダを指定します。このトリガーが返すのは列の値だけなので、続けて「ファイル コンテンツの取得」で中身を取ります。

旧来の「フォルダーにファイルが作成されたとき」は非推奨で、サブフォルダにファイルが足されても動かないとされています。店舗ごとにサブフォルダを切りたくなりますが、フォルダは1つにして、店舗のコードはファイルの列で持ちます。

1日1回の定時処理にはしません。店長が原稿を置いてすぐに指摘が返ると、書いた本人がその場で直せます。 まとめて翌朝に返すと、店長は営業に戻っていて、直すのが夜になります。

処理が終わった原稿は「確認済み」に移さず、その場に置いたままにします。 指摘の一覧を同じ名前の横に置き、ファイルの列「状態」を「指摘あり」「指摘なし」に変えます。「確認待ち」のままの列が残っていれば、処理が止まっているということです。

入力データを集める

質を決めるのは、下の2つです。 表現の決まりに言い換えの例が無いと、AIの直しの案は毎回ばらばらになります。根拠の資料の台帳が無いと、「根拠の資料が要る」という指摘が出ても、誰も確かめられません。

掲載の開始日をファイルの列で持たせるのは、料金表の版を選ぶためです。 10月末に書いた11月のチラシの原稿は、11月の料金表と比べなければなりません。

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

料金表は Excel のブックのまま読みます。 月の版を「料金表_2026-11.xlsx」のような名前で保存する決まりにし、Functions がファイル名で選びます。ブックの中身を Azure OpenAI に渡すことはしません。 突き合わせは Functions の側で行い、AIには「食い違いがあった」という結果だけを渡します。

表現の決まりは、全項目をそのままプロンプトに入れます。 約60項目なので量は多くありません。検索で絞り込む仕組みは要らず、絞り込むと、当てはまる項目を取りこぼします。

AIへ渡す前に整形する

1. 文の分割 … 原稿を文ごとに分け、s01、s02 のように番号を付けます。見出し、本文、注記（※の文）を区別して持ちます
2. 料金の抜き出し … 「円」「回」「か月」「日まで」を手がかりに、金額・回数・期間を正規表現で抜き出します
3. 料金表との突き合わせ … 抜き出したコース名と金額を料金表のその月の版と比べ、合わないものに印を付けます
4. 語の照合 … 表現の決まりの「使わない言い方」の語を、文に機械的に当てます。表記ゆれ（ひらがな・カタカナ・全角半角）は先にそろえます
5. 注記の対応付け … 「※個人の感想です」のような注記が、どの文に付いているかを結び付けます
6. 長さの確認 … チラシの原稿でも数百文になることはまずありませんが、200文を超えたら分けて送ります

2番と3番をAIに任せないのが、この前処理の肝です。 金額の読み違いはAIでも起きますが、正規表現と表の突き合わせなら起きません。数字は機械で比べ、言い方だけをAIに見せます。

5番を省くと、注記の指摘が外れます。 「※効果には個人差があります」が原稿の末尾に1回だけあり、どの数字に付いているのか分からない、という原稿は多くあります。どの文に注記が付いていないかを、前処理で先に分かるようにします。

AIに処理させる

させるのは、文ごとに「表現の決まりのどの項目に当たりそうか」を返し、直しの案を書き、根拠の資料が要るかを付けることです。

3行目は、言い換えだけでは済まないことがあります。 原稿に「毛根を破壊」と書かれているとき、問題は言い方ではなく、その店が実際に何をしているかかもしれません。そこでこの指摘には needs_service_check の印を付け、言い換えの案を出したうえで、施術の内容を店舗統括のマネージャーが確かめる流れに回します。

4行目がいちばん起きやすい失敗です。 「1回で−5kg」を直させると、「1回で体が軽く感じられ、引き締まった印象に」のように、別の効果を足した案を返すことがあります。 直しの案は、削る・弱める・条件を足す、のどれかに限らせます。

指示内容を固定する

あなたはエステサロンの本部で、広告の原稿を出す前に校正する担当です。
社内の「表現の決まり」に照らして、文ごとに当たる項目を返してください。

【物差し】
- A：景品表示法・特定商取引法（効果の言い方、料金・特典の言い方）
- B：医行為と読める施術の説明
- C：体験談と注記
料金の正誤は見ません。料金表との突き合わせは別の処理で済んでいます。

【判定のしかた】
- 文ごとに、表現の決まりのどの項目に当たりそうかを rule_ids に入れる
- どの項目にも当たらなければ status を none にする
- 当たりそうだが決まりの言葉と完全には一致しないときは likely にする
- 決まりに無いが気になる言い方は rule_gap にし、rule_ids は空にする
迷ったときに none を選ばないでください。

【直しの案の決まり】
- 直しの案は、削る・弱める・条件を書き足す、のいずれかにしてください
- 原稿に書かれていない効果や特典を、直しの案に足さないでください
- 数字を言い換えるときは、数字を消すか、表現の決まりの言い換えの例に合わせてください
- 施術の説明（物差しB）に当たる文は、needs_service_check を true にしてください

【厳守事項】
- 違法、違反、問題ない、といった結論を書かないでください
- 根拠の資料があるかどうかを推測しないでください。要るかどうかだけを付けてください
- evidence には、当たったと考えた原稿の語句をそのまま写してください
- 注記（※の文）は、どの文に付いているかの対応表に従って読んでください

【原稿（番号付きの文）】{sentences}
【注記の対応表】{note_links}
【表現の決まり】{rules}
【媒体】{media}

「迷ったときに none を選ばない」を書かないと、指摘が減ります。 AIは「当たる」と言い切れない文を none に寄せがちで、そこに責任者が見たかった文が混ざります。 likely という中間を用意して、迷ったものは人の目に回します。

「違法と書かない」を厳守事項に置くのは、責任者の判断を先回りさせないためです。 一覧に「違法」と書かれていると、店長はその一言で原稿を書き直し、責任者が「この場合は使ってよい」と判断する余地がなくなります。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形の JSON を返させます。 Chat Completions API の response_format に json_schema を渡し、strict を有効にします。

{
  "document_id": "",
  "media": "flyer | web | sns | line",
  "sentences": [
    {
      "sentence_id": "s07",
      "status": "hit | likely | rule_gap | none",
      "axis": "A | B | C | none",
      "rule_ids": ["A-12"],
      "evidence": "1回で−5kg",
      "needs_evidence_doc": true,
      "needs_service_check": false,
      "suggestion": "",
      "note": ""
    }
  ]
}

1つ目の理由は、status と axis で指摘を振り分けられることです。 axis が B のものはマネージャーへ、A で needs_evidence_doc が true のものは根拠の台帳の確認へ、と一覧を開く前に行き先が決まります。

2つ目は、rule_gap を別に集められることです。 決まりに無い言い方が毎月同じように出てくるなら、足すべきなのは決まりの側です。 月末に rule_gap だけを集め、販促責任者が決まりに足すかを決めます。

スキーマの書き方には制約があります。 Azure OpenAI の構造化出力は、すべてのフィールドを required にし、additionalProperties を false にする必要があります。省略したい項目は null との共用体型で表します。文字列の minLength・maxLength・pattern、配列の minItems・maxItems などは使えません。 直しの案の長さや sentence_id の形は、受け取った後に Functions で確かめます。オブジェクトのプロパティは合計100個まで、入れ子は5段までです。

システムへ連携する

原稿そのものには書き込みません。 直しの案は一覧に並べるだけで、原稿を直すのは書いた人です。自動で原稿を書き換えると、店長は自分の原稿のどこが変わったか分からないまま出すことになります。

Responses API ではなく Chat Completions API を使います。 Responses API は会話の履歴を持つためにメッセージの履歴などを保存するとされています。この構成は1回ごとに完結するので、履歴を残す仕組みは要りません。

人が確認する

1. 書いた人が料金の食い違いを直す … 前処理で料金表と合わなかったもの。AIの判定を待たずに直せます
2. 書いた人が語の一覧に当たったものを直す … 決まりの言い換えの例をそのまま使えるもの
3. 販促責任者が axis A の hit と likely を読む … 出すか、直すか、根拠の資料を確かめるかを決めます
4. マネージャーが needs_service_check を確かめる … 原稿の言い方ではなく、その店舗で実際に行っている施術の中身を確かめます
5. 判定を覆したら記録する … 「この項目はこの媒体なら使ってよい」と決めたものは、決まりの側に書き足します

3番で責任者が読むのは、1本あたり数文です。 80本の全文を読んでいたところから、指摘の付いた文だけを読む形に変わります。ただし likely は必ず読みます。 AIが言い切れなかった文こそ、責任者の判断が要る文です。

4番は、広告の校正の範囲を超える確認です。 原稿に光で毛根を壊すと読める言い方があったとき、それが言い方の問題なのか、施術の問題なのかは、原稿だけでは分かりません。 ここは校正の流れから外し、店舗統括の確認事項として扱います。

例外に対処する

1行目は前もって試しておきます。 安全方針の分類器は日本語でも学習・評価されていますが、誤検知はありうるとされています。痩身や脱毛の原稿を数十本流して、止まるものがあるかを導入前に見てください。 止まったものは、プロンプトを変えるより人に回すほうが安全です。

記録を残す

• 元の原稿と、媒体・店舗・掲載の開始日の列の値
• 料金の突き合わせに使った料金表の版の名前と、食い違いの一覧
• Azure OpenAI に送った文と、返ってきた JSON の全文
• そのとき使った表現の決まりの版
• 書いた人が採った直しの案、採らなかった直しの案
• 販促責任者とマネージャーが判定を覆した記録と、その理由
• rule_gap の月ごとの一覧

4つ目で決まりの版を残すのは、決まりが毎月少しずつ変わるためです。 先月は指摘されなかった言い方が今月は指摘される、ということが起きます。どの版で見たかが残っていないと、店長に理由を説明できません。

判定を覆した記録は、決まりを育てる材料です。 半年分を見ると、責任者が毎回通している指摘と、毎回止めている言い方が分かります。