取引先監査の提出資料を読み込んで、当日に聞くべき論点を先にまとめる

処理の起点を決める

SharePoint の取引先フォルダに資料が保存されたときを起点にします。

資料は複数回に分けて届きます。 「まず品質マニュアルを送り、検査記録は後日」という形が普通です。1ファイルごとに処理し、揃った時点で整理シートを作る形にしてください。

「揃った」の判定が要ります。 チェックリストの必須の資料が揃ったら、整理シートを作ります。揃わないまま監査の1週間前になったら、不足している資料を知らせます。

この「不足の通知」だけでも価値があります。 現状、資料が揃っていないことに気づくのが監査の直前になることがあります。1週間前に分かれば、取引先へ催促できます。

再処理の入口も用意してください。 資料が差し替えられることがあります。差し替え後に整理シートを作り直せる形にしてください。

入力データを集める

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

監査チェックリスト： ここがこの構成の質を決めます。「ある／ない」の二択ではなく、次の形で持ってください。

「薄いとみなす状態」の列が、この構成でもっとも効きます。 記載があるかないかだけなら、目次を見れば分かります。価値があるのは、「書いてあるが中身がない」を拾うことです。

「確認すべき点」の列は、当日の質問に直結します。 記載が薄い項目について、何を聞けばよいかをあらかじめ書いておけば、経験の浅い担当者でも質問できます。ベテランの頭の中にあるものを、ここへ移す作業です。

前回の監査報告書： 指摘事項を、次の形で構造化してください。

この構造化が、前回指摘の突き合わせを可能にします。 報告書がWordの文章のままだと、指摘を取り出す処理が毎回必要になります。過去3年分を一度構造化しておけば、以後は監査のたびに1行足すだけです。

過去の品質事象： 受入検査での不適合やクレームの記録は、監査の論点に直結します。「直近1年で寸法の不適合が3件」という情報があれば、その工程を重点的に見ることになります。

この情報は、品質保証部が別に持っていることがほとんどです。 購買部の監査準備で使うには、部門をまたいだ共有が要ります。「監査の準備のために、その取引先の直近1年の不適合を教えてほしい」という依頼を、監査のたびに出す形でも構いません。 自動連携は後からでよく、情報が準備の材料になることのほうが重要です。

チェックリストの整備には、品質保証部を巻き込んでください。 監査の観点は品質保証部が持っています。購買部だけで作ると、「何が書かれているべきか」の水準が定まりません。 合同で監査を行っているなら、チェックリストも合同で作るのが自然です。

「薄いとみなす状態」の例は、実際の資料から拾ってください。 想像で書くと、現実の資料と噛み合いません。過去に「書いてあるが中身がなかった」例を、品質保証部の担当者に10件挙げてもらうのが、いちばん早い方法です。「手順書がある、とだけ書かれていて改訂の管理に触れていない」といった具体例が集まります。

AIへ渡す前に整形する

1. ファイル形式の判別 … PDF（文字あり）／PDF（スキャン画像）／Excel／Word を判別します
2. 文字と構造の取り出し … Document Intelligence のレイアウトモデルで、文字・表・見出しをページ番号付きで取り出します
3. 文書の種類の判定 … 品質マニュアル／工程図／検査記録／是正処置報告／認証の写しのどれかを判定します
4. チェックリスト項目への割り当て … どの文書のどのページが、チェックリストのどの項目に対応するかを対応づけます
5. 前回資料との対応づけ … 同じ種類の文書を、前回の資料と対応させます
6. 個人情報の確認 … 検査記録に担当者の氏名や印影が含まれることがあります。扱いを決めてください

4の対応づけが、この構成の要です。 取引先ごとに文書の構成が違うため、「この項目はこの文書のここに書かれている」という対応を作る必要があります。見出しの言葉が違うことも多いので、ここは生成AIで対応づけます。

2のOCRは、スキャン画像がなければ省けます。 ただし、文字ありのPDFでも、表の構造は取り出しにくいことがあります。検査記録のような表形式の文書は、レイアウトモデルを通したほうが安定します。

AIに処理させる

4つの処理をさせます。

（1）記載の有無と厚みの判定

（2）前回指摘への対応の確認

前回の指摘事項ごとに、今回の資料に是正の記載があるかを確認します。「記載がある」と「是正されている」は別です。 この構成が言えるのは前者までです。

（3）前回資料との差分

（4）当日の論点の整理

記載が薄い項目、前回指摘に触れていない項目、削除された記述、品質事象に関係する工程。これらを、確認すべき優先度とともに並べます。 各論点には、根拠となるページ番号を付けます。

取引先の評価はさせません。 「品質管理体制が不十分」「取引の継続は再検討が必要」といった記述を禁じてください。資料に書かれているかどうかと、実際にできているかどうかは別の話です。

是正の完了も判定させません。 「前回の指摘は是正済み」と書かせないでください。資料に是正の記載があることと、是正されていることは違います。 確認は現地で行います。

指示内容を固定する

あなたは購買部で取引先監査の準備を担当する者です。
取引先から提出された資料について、監査当日に確認すべき論点を整理してください。

【厳守事項】
- 取引先を評価しないでください。
  「品質管理体制が不十分」「信頼性が低い」「取引の継続は再検討が必要」
  と書かないでください。
- 是正の完了を判定しないでください。
  「前回の指摘は是正済み」と書かないでください。
  「前回の指摘に対応する記載が18ページにある」という事実までにしてください。
- 監査の合否に関わる判断をしないでください。
  合否は現地で見て人が決めます。
- 資料に書かれていないことを推測で補わないでください。
  「一般的にはこうしているはず」と書かないでください。
  記載が見当たらない場合は「記載なし」としてください。
- すべての指摘に、根拠となるページ番号を付けてください。
  ページ番号を示せない指摘は書かないでください。
- 記載の厚みは、下の「何が書かれているべきか」に照らして判定してください。
  一般的な品質管理の教科書に照らさないでください。
- 「記載あり・薄い」と判定した場合、何が足りないのかを具体的に書いてください。
  「記載が不十分」ではなく「手順は示されているが、記録の保存期間に触れていない」
  と書いてください。
- 前回資料から削除された記述は、必ず論点に挙げてください。
  削除には理由があるはずで、それを聞くことが監査です。

【監査の種類】
{audit_type}

【取引先の供給品目と重要度】
{supplier_profile}

【監査チェックリスト（項目／必須か／何が書かれているべきか／薄いとみなす状態／確認すべき点）】
{checklist}

【今回の提出資料（文書ごと、ページ番号付き）】
{documents}

【前回の提出資料（差分の比較用）】
{previous_documents}

【前回の監査の指摘事項（内容／区分／要求した是正／期限）】
{previous_findings}

【この取引先に関する直近1年の品質事象】
{quality_events}

「すべての指摘に根拠ページを付ける」の指示が、この構成の使い勝手を決めます。 ページが示せない指摘は、担当者が確かめられません。確かめられない指摘は、当日の質問に使えません。

「削除された記述を必ず挙げる」も外せません。 追加された記述は目に付きますが、消えた記述は気づきにくいものです。工程が1つ消えている、検査項目が減っている。これらは監査で聞くべきことです。

「一般的にはこうしているはず、と書かない」の指示が要ります。 生成AIは、資料に書かれていない一般論で埋めようとします。監査の準備でこれをされると、書かれていないことが書かれているように見えてしまいます。

出力形式を固定する

{
  "supplier": "",
  "audit_date": "",
  "audit_type": "new | periodic | special",
  "documents_received": [
    { "file_name": "", "doc_type": "", "pages": 0, "received_date": "" }
  ],
  "documents_missing": [],
  "checklist_results": [
    {
      "item": "",
      "required": true,
      "status": "sufficient | thin | not_found | not_applicable",
      "evidence": [ { "file_name": "", "page": 0, "excerpt": "" } ],
      "what_is_missing": ""
    }
  ],
  "previous_findings_status": [
    {
      "finding": "",
      "severity": "major | minor | observation",
      "mentioned_in_current": false,
      "evidence": [ { "file_name": "", "page": 0 } ],
      "note": ""
    }
  ],
  "changes_from_previous": {
    "added": [],
    "removed": [],
    "value_changed": [],
    "organization_changed": []
  },
  "audit_points": [
    {
      "point": "",
      "reason": "",
      "related_checklist_item": "",
      "evidence": [ { "file_name": "", "page": 0 } ],
      "priority": "high | medium | low",
      "suggested_question": ""
    }
  ]
}

Claude API の structured outputs では、出力にスキーマを指定すると、そのスキーマに沿ったJSONが返ります。 根拠ページの記載漏れを防げます。

evidence を配列にしていることが重要です。 1つの項目について、複数の文書の複数のページに記載が散っていることがあります。すべてを示せる形にしてください。

what_is_missing の列が、「薄い」判定を使えるものにします。 「記載が不十分」では担当者が動けません。「手順は示されているが、記録の保存期間に触れていない」と書かれていれば、そのまま質問になります。

suggested_question は、当日の質問の下書きです。 チェックリストの「確認すべき点」をもとに作ります。そのまま使うのではなく、担当者が取捨選択して使います。

documents_missing は、監査の1週間前に効きます。 必須の資料が届いていないことを、早い段階で知らせます。

システムへ連携する

出力は事前整理シートとして作るだけで、他のシステムへの書き込みは行いません。

当日そのまま持っていける形にすることが大事です。 画面で見るための形ではなく、印刷して書き込める形にしてください。現地では、紙のほうが扱いやすい場面が多くあります。

取引先へ自動で連絡しないでください。 「資料が不足しています」という連絡が自動で飛ぶと、取引先との関係に響きます。担当者が内容を見て、必要なら連絡します。

購買システムへの書き戻しも行いません。 取引先の評価情報を自動で更新する構成にしないでください。評価は監査の結果を見て人が決めます。

人が確認する

担当者の確認は必ず残します。

1つ目が最重要です。 「記載なし」が誤りだった場合、監査当日に「ここに書いてあります」と言われることになります。信頼を損ないます。 必ず該当する文書を開いて確かめてください。

確認を速くするための設計が効きます。

• 該当ページへのリンクを、整理シートから直接張る
• 「記載なし」の項目を上に並べる
• 前回の指摘と、今回の記載を左右に並べる
• 論点ごとに、根拠の抜粋を数行載せる
• 当日の確認結果を書き込む欄を右端に置く

5つ目が、次回の準備につながります。 当日の確認結果を書き込んでおけば、それが次回の「前回の指摘」になります。報告書とは別に、この欄を必ず埋めてください。

確認の記録には、「聞いたが問題なかった」も残してください。 論点として挙がったが、現地で確認したら十分だった——という結果です。これが残っていれば、次回は同じ論点の優先度を下げられます。 報告書には書かれない情報なので、整理シートの側で拾う必要があります。

品質保証部との分担も、整理シートの上で決めてください。 論点ごとに「誰が聞くか」の欄を置きます。打ち合わせの時間が短くなり、当日の重複や漏れも減ります。 現地では別行動になることもあるため、事前の割り振りが効きます。

「記載なし」の確認は、必ず整理シートの該当リンクから行ってください。 記憶で「たしか書いてあった気がする」と判断すると、誤りが残ります。リンクをたどって該当ページを開き、実際に見当たらないことを確かめる。 この一手間が、当日の信頼を守ります。

例外に対処する

「論点が多すぎる」問題は必ず起きます。 チェックリストの項目が40あれば、薄い項目は20出ます。当日に聞けるのは10件程度です。 優先度を付けて絞る処理を、必ず入れてください。

記録を残す

この記録は、次回の監査の準備に直接使われます。

• 処理した資料の一覧と、受領日
• チェックリストの判定結果
• 前回指摘への対応状況
• 前回資料との差分
• 整理された論点と、優先度
• 担当者が実際に選んだ論点
• 当日の確認結果
• 判定が誤っていた事例（記載を見落とした、あるはずのないものを指摘した）

「担当者が実際に選んだ論点」の記録が効きます。 出した論点のうち、どれが使われたかが分かれば、優先度の付け方を直せます。毎回使われない種類の論点は、出す必要がありません。

「判定が誤っていた事例」は必ず記録してください。 特に「記載なし」としたのに実際は書かれていた事例は、対応づけの問題です。見出しの言葉の違いを、チェックリストへ反映してください。

取引先の資料には、工程や設備の情報が含まれます。 取引先にとっての機密情報です。外部のAIサービスへ渡してよいかを、取引先との秘密保持契約に照らして確認してください。 契約によっては、第三者への開示にあたる可能性があります。

保管場所と閲覧範囲を限定してください。 他の取引先の情報が混ざらないよう、フォルダの権限を取引先ごとに分けることも検討してください。