是正処置報告書が出されたときに、原因の掘り下げ・対策・効果の確認の記載が社内基準を満たすかを判定し、差し戻しの指摘を作る

処理の起点を決める

提出ライブラリにファイルが作成されたことを起点にします。 SharePoint コネクタの「ファイルの作成時 (プロパティのみ)」を使い、対象のライブラリを指定します。「作成または変更されたとき」は使いません。 品証が列を書き換えるたびにフローが動き、同じ報告書を何度も判定することになるからです。

再提出は、新しいファイルとして置いてもらいます（ファイル名の末尾に版の番号を付ける）。上書きにすると作成のトリガーが動かず、修正版が判定されません。

提出のときに入力してもらう列は2つだけです。CAPA番号（台帳の行と結びつける）と版（初回か再提出か）です。CAPA番号が空のまま置かれたものは判定せず、提出者に入力を求める連絡を返します。

入力データを集める

質を決めるのは、いちばん下の判定基準です。 「原因が十分に掘り下げられていること」と書くだけでは、AIも人も同じように判断できません。「なぜの最後が『人が注意を怠った』『教育不足』で終わっていないこと。終わっている場合は、なぜ注意を怠れる仕組みだったのかまで書かれていること」のように、足りない例を一緒に書きます。

元の不適合の内容を渡すのは、報告書の「問題の記述」と照らすためです。 品証が登録した数量や品番と、報告書に書かれた内容が食い違っていることがあり、報告書だけを読んでいては気づけません。

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

判定基準はプロンプトの本文に直接書かず、ファイルから読み込んで入力として渡します。 基準を直すたびにプロンプトを作り直さなくて済み、どの版の基準で判定したかをログに残せます（第7章「保存・ログ」）。

台帳の行は、CAPA番号で1件に絞れたときだけ先へ進めます。 0件や2件以上のときは判定せず、品証に知らせます（第7章「例外処理」）。

AIへ渡す前に整形する

1. ファイル形式の確認 … PDFであることを確かめます。Word のまま置かれたものは提出者にPDFでの再提出を求めます
2. サイズとページ数の確認 … プロンプトに渡すファイルは合計が 25 MB 未満、ドキュメントは 50 ページ未満である必要があります。是正処置報告書は数ページなので通常は収まりますが、写真や測定データを大量に貼った報告書は超えることがあります
3. 添付資料の分離 … 測定データやグラフを本体に貼り込まず、別ファイルにしてもらいます。大きなドキュメントから抽出された情報が不正確または不完全である可能性があり、特にテーブル行の場合とされているため、本体を短く保ちます
4. 版の確認 … 版が2以上なら、前の版の判定と指摘文を台帳から読み込みます
5. 重大度の確認 … 台帳の重大度が最も高い区分（顧客に流出した安全関連など）のものは、判定はしても needs_expert を必ず付けます

2番目と3番目は、提出の様式の側で直します。 判定の精度を上げようとするより、報告書の本体を8つの欄に絞り、証拠の資料は別に添付するルールにするほうが確実です。

AIに処理させる

させるのは、8項目それぞれについて、判定基準に照らした状態と、根拠にした報告書の文を返すことだけです。

状態は4つです。sufficient（足りている）、insufficient（書かれているが基準に届かない）、missing（書かれていない）、cannot_judge（技術的な内容で、記載の形式からは判断できない）です。

cannot_judge を置くのが要点です。 「熱処理の条件が原因」と書かれていても、それが正しいかは記載からは分かりません。AIに原因の正しさを判断させると、もっともらしい書き方の報告書が通り、正しくても書き方の素朴な報告書が返されます。 正しさの判断が要る項目は、迷わず専門家へ回させます。

3行目がいちばん起きやすい失敗です。 指摘文の案を作らせると、「たとえば治具の位置決めピンを追加するなど」と対策そのものを提案し始めます。 製造課はそれをそのまま書き写し、調べていない対策が報告書に載ります。指摘文は「何が足りないか」までにとどめさせます。

指示内容を固定する

あなたは品質保証部で、製造課から提出された是正処置報告書を受理する前に、
記載が社内の判定基準を満たしているかを下読みする担当です。
受理か差し戻しかは決めません。項目ごとの状態だけを返してください。

【判定する8項目】
1. problem（問題の記述） 2. containment（暫定処置）
3. root_cause（発生原因） 4. escape_cause（流出原因）
5. countermeasure（恒久対策と原因の対応） 6. horizontal（水平展開）
7. effectiveness（効果の確認） 8. standards（標準類の改訂）
各項目の「足りている」の目安は、【判定基準】に書かれたものだけを使ってください。

【status の選び方】
- sufficient .... 判定基準の目安を満たす記載がある
- insufficient .. 記載はあるが目安に届かない
- missing ....... その項目の記載がない、または「特になし」「別途」だけ
- cannot_judge .. 技術的な正しさの判断が要り、記載の形式からは決められない
迷ったときに sufficient を選ばないでください。

【厳守事項】
- 報告書に書かれていないことを補わないでください。記載がなければ missing です。
- 原因や対策が技術的に正しいかを評価しないでください。
- 「教育を実施」「注意喚起」「周知徹底」だけの対策は、目安に照らして判定してください。
- countermeasure では、root_cause と escape_cause に挙がった原因を1つずつ並べ、
  それぞれに対応する対策の文があるかを書いてください。
- problem では、【元の不適合】の品番・数量・発生日と食い違う記載があれば挙げてください。
- evidence には、判定の根拠にした報告書の文をそのまま写してください。要約しないでください。
- comment_draft には、何が足りないかだけを書いてください。
  対策や原因の候補を提案しないでください。
- 前の版の指摘がある場合は、各指摘が今回の版で解消したかを resolved に書いてください。
- 回答に JSON マークダウンを含めないでください。

【元の不適合】{nc_record}
【判定基準】{criteria}
【前の版の指摘】{previous_findings}
【報告書】（ドキュメント入力）

「対策や原因の候補を提案しない」を明記しないと、指摘文が助言になります。 助言は親切に見えますが、調査していない原因が報告書に入る経路になります。

「回答に JSON マークダウンを含めない」は、Microsoft のページにある対処をそのまま入れたものです。 JSON出力のプロンプトで「JSON を生成できませんでした」と出るとき、モデルが JSON をメタデータで囲んでいる可能性があり、この指示を足すよう案内されています。

出力形式を固定する

プロンプトの出力を JSON にし、形式を「カスタム」で固定します。 既定の「自動検出」は、テストのたびに形式が更新されます。JSON の例を編集すると形式は Custom になり、プロンプトを保存すると形式がロックされ、フローで使うときはその形式が使われるとされています。

{
  "capa_no": "",
  "revision": 1,
  "items": [
    { "item": "root_cause", "status": "sufficient | insufficient | missing | cannot_judge",
      "evidence": "", "comment_draft": "" }
  ],
  "cause_countermeasure_map": [
    { "cause": "", "countermeasure_evidence": "", "covered": "yes | no" }
  ],
  "record_mismatch": [ { "field": "", "record": "", "report": "" } ],
  "previous_findings": [ { "item": "", "resolved": "yes | no | partly" } ]
}

items には8項目を並べます。フィールド キーのない配列（["abc","def"] のような形）は JSON 形式の定義としてサポートされていないとされているため、配列の要素は必ずキーを持つオブジェクトにします。

1つ目の理由は、判定と結論を別の層に置けることです。 フローは items を読み、次の規則で結論を決めます。

③⑤⑦を重く扱うのは、品証の方針の例です。 原因・対策・効果の確認の3つが欠けた報告書を受理すると、後で効果の判定ができなくなります。どの項目を重く扱うかは、この表を変えるだけで変えられます。

2つ目は、cause_countermeasure_map で原因と対策の対応が一覧になることです。 第3章の（b）は、欄ごとに読むと見落とす問題でした。原因を1行ずつ並べ、対策の文が付いているかを表にすれば、no の行が一目で分かります。

システムへ連携する

人の確認には、承認アクションの「推奨テキスト」を使います。 Microsoft のページでは、プロンプトの後に「開始してテキストの承認を待機」を置き、推奨テキストに生成されたテキストを入れると、割り当てられたレビュー担当者が Power Automate の承認の画面でテキストを確認し、必要に応じて編集して応答できる手順が示されています。指摘文を直したうえで差し戻しを選べるので、この業務にそのまま合います。

台帳への書き込みは、承認の後だけです。 AIの判定が出た時点では、台帳の「AI判定」列に下読みの結果を書くだけにし、状態（受理／差し戻し）は人の応答を受けてから変えます。

人が確認する

全件を人が確認します。 AIの判定だけで受理する経路は作りません。そのうえで、確認の重さを結論ごとに変えます。

1. needs_expert を先に見る … 技術的な判断が要る項目があるもの。品証の担当者だけで決めず、生産技術や設計の担当に見てもらいます
2. return_candidate の根拠を確かめる … evidence の文を報告書の該当箇所と並べて読みます。missing の項目が本当に書かれていないかを確かめます
3. 指摘文を直す … 案は「何が足りないか」までなので、製造課の事情を知る担当者が、伝わる言い方に直します
4. accept_candidate も報告書を通して読む … 下読みで抜けがないと出ていても、受理の判断は人がします

4番目を省かないでください。 AIは書かれたことしか見ないので、報告書全体がもっともらしく書かれていても中身が薄いものを見抜けません。下読みで時間が浮くのは、欄の間を行き来する作業です。読むこと自体は残ります。

目標は、1件をならして15分です。 抜けを探す作業が下読みに置き換わり、指摘文は直すだけになるという想定です。

例外に対処する

いちばん下から2つ目が大事です。 AIの呼び出しが失敗しても、報告書の受付と品証への通知は必ず行います。 下読みが無い報告書は、今までどおり人が読めば済みます。AIが止まったせいで報告書が誰にも届かない、という状態だけは作りません。

記録を残す

• 提出された報告書のPDF（版ごと。上書きしない）
• プロンプトが返したJSONの全文と、そのとき使った判定基準の文書の版
• フローが規則で決めた結論（accept_candidate など）
• 人の応答 … 受理か差し戻しか、指摘文をどう直したか
• 差し戻しの回数と、再提出で解消した項目
• AIの判定と人の判断が食い違った件 … どの項目で、どちらに変えたか

2つ目で判定基準の版を残すのは、基準が後から変わるためです。 「教育だけの対策は不可」と基準を厳しくした月の前後で、判定の意味が変わります。

最後の行は、判定基準を直す材料になります。 人が sufficient を insufficient に変えることが続く項目は、基準の文書の目安が甘いか、足りない例が書かれていません。 毎月の集計で見て、基準のほうを直します。