顧客からの不具合報告を原因区分で分類して再発防止の台帳にする

処理の起点を決める

受付フォームへの回答、または専用メールアドレスへの着信を起点にします。

Microsoft Forms コネクタには「When a new response is submitted（新しい応答が送信されたとき）」トリガーがあります。ただしこのトリガーが返すのは応答IDだけなので、続けて「Get response details（応答の詳細を取得する）」アクションを呼んで中身を取ります。この2段構えを知らないと、最初のトリガーの出力を見て「回答内容が取れない」と詰まります。

このコネクタは組織アカウントでのみ動きます。顧客に直接フォームを開いてもらう構成にはできないため、顧客からの申告は営業が受けてフォームに入力するか、専用メールアドレスで受ける設計にします。

メールで受ける場合は、Office 365 Outlook コネクタの「When a new email arrives（新しいメールが届いたとき）」トリガーを使い、宛先アドレスで絞り込みます。

入力データを集める

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

報告の本文： フォーム回答は「Get response details」アクションで取得します。メールの場合は本文のHTMLからテキストを取り出します。

製品マスタ： 生産管理システムから日次でエクスポートしたCSVを、SharePoint リストに持たせます。リアルタイム連携は不要です。型式は数百から数千件なので、この規模なら照合をLLMに任せず、プログラム側で文字列照合したほうが確実です。

原因区分の定義： 社内の区分表をそのままプロンプトに埋め込みます。区分名だけでなく、その区分に入る具体例を3つずつ添えてください。 「材料」という区分名だけを渡しても、AIは社内の運用に合った判断をしません。

過去の不具合台帳： SharePoint リストから取得します。件数が数百件までなら、現象の列だけを抜き出してプロンプトに渡します。数千件を超えたら、検索基盤に載せます。Azure AI Search はベクトル検索とキーワード検索を同じリクエストで実行するハイブリッド検索に対応していて、両方の結果を統合して返します。「異音」と「音がする」のような言い換えはベクトル検索が拾い、型式のような固有の文字列はキーワード検索が拾います。この業務では、どちらか片方では取りこぼします。

AIへ渡す前に整形する

1. 引用部分の除去 … 転送メールには過去のやり取りが全部ぶら下がっています。区切り行から下を落とさないと、古い不具合の内容を拾います
2. 署名の除去 … 営業の署名に含まれる社名を、顧客名として拾ってしまうことがあります
3. 写真の扱いを決める … 写真は抽出の対象にせず、台帳に添付するだけにします。写真から原因を判定させる構成は、この難易度では組みません
4. 重複の検出 … 営業と顧客の両方から同じ件が届くことがあります。「顧客名＋型式＋発生時期」が近いものを既存台帳から探し、候補として出します

AIに処理させる

原因の確定はさせません。 AIが出すのは「この現象なら、過去の例からするとこの区分に入ることが多い」という候補までです。現物を見ていないAIに原因を決めさせる構成にはしません。

指示内容を固定する

あなたは製造業の品質保証部を支援する担当者です。
顧客から届いた不具合報告の文面を読み、台帳に登録する項目を取り出してください。

【厳守事項】
- 文面に書かれていない項目は、推測せずに null にしてください。
  型式が書かれていなければ null です。似た型式を当てはめないでください。
- 原因区分は、下の【原因区分の定義】にある区分からのみ選んでください。
  新しい区分を作らないでください。
- 原因区分は「候補」です。断定する書き方をしないでください。
  根拠にした文面の箇所を evidence に引用してください。
- 現象は、顧客の言葉をそのまま phenomenon_raw に、
  台帳用に言い換えたものを phenomenon_normalized に入れてください。
  言い換えは【現象の用語集】にある表現から選んでください。
- 顧客名、型式、日付を書き換えないでください。
- 営業に確認すべき不足情報があれば missing_info に列挙してください。

【原因区分の定義】
{cause_categories}

【現象の用語集】
{phenomenon_terms}

【不具合報告の本文】
{report_body}

「書かれていない項目は推測せずに null」の1行が要です。 これを入れないと、AIは型式らしい文字列を文面から作ってしまいます。品質の台帳に架空の型式が入ると、集計が壊れます。

出力形式を固定する

{
  "customer_name": "",
  "product_model": "",
  "product_name": "",
  "phenomenon_raw": "",
  "phenomenon_normalized": "",
  "occurred_process": "",
  "occurred_date": "",
  "customer_impact": "停止 | 手直しで使用可 | 影響なし | 不明",
  "customer_request": "",
  "cause_category_candidates": [
    { "category": "", "confidence": "high | medium | low", "evidence": "" }
  ],
  "urgency_candidate": "高 | 中 | 低",
  "missing_info": [],
  "duplicate_candidates": []
}

JSONの形が毎回同じであることが、後段の自動登録の前提になります。Claude API には structured outputs があり、output_config.format に type: "json_schema" とスキーマを渡すと、制約付きデコードによってスキーマに沿った出力が返ります。公式ドキュメントは「Always valid（JSONのパースエラーが起きない）」「Type safe（型と必須項目が保証される）」と説明しています。形式違反のリトライ処理を書かずに済むので、ノーコードのワークフローで組むときほど効きます。

原因区分を配列で返させているのは、1つに決めさせないためです。候補が2つ並んでいれば、人はそのどちらかを選ぶだけで済みます。

システムへ連携する

確定後、SharePoint リストの不具合台帳に登録します。SharePoint コネクタには「Create item（SharePointリストに新しいアイテムを作成します）」アクションがあり、リストの各列に値を入れられます。更新は「Update item（SharePointリストのアイテムを更新します）」です。

受付番号の採番は、SharePoint リストの採番列を使うか、「年度＋連番」を別途採ります。ワークフローの中で採番すると、処理が途中で失敗したときに番号が飛びます。 登録が成功した後に採番する順序にします。

期限管理は、「When an item is created or modified（アイテムが作成されたとき、および変更されるたびにトリガーします）」で是正処置の期限列を見張るのではなく、日次で動く別のフローで「期限が3日以内かつ未完了」の行を拾って通知するほうが単純です。

人が確認する

全件、人が確認します。

確認するのは次の3点です。

• 抽出された型式と顧客名が、原文と合っているか
• 原因区分の候補が妥当か（違えば選び直す）
• 是正処置が必要か

確認を速くするための設計が重要です。報告の原文と抽出結果を左右に並べて表示してください。 原文を別ウィンドウで開き直す作りにすると、確認に7分以上かかり、削減効果が消えます。

確信度が low の原因区分、missing_info に入った項目は色を変えて目立たせます。duplicate_candidates に候補が入っていれば、その過去事例へのリンクを出します。

例外に対処する

記録を残す

• 報告の原文（メール本文またはフォーム回答の全文）
• 添付写真
• AIが抽出した結果と、原因区分の候補・確信度
• 人が修正した項目と、修正前後の値
• 確定者、確定日時
• 是正処置の依頼先、期限、完了日

人が修正した項目の記録が、この構成の精度を測る唯一の材料になります。 「型式はほぼそのまま通るが、原因区分は半分修正されている」と分かれば、区分の定義か用語集のどちらを直すべきかが決まります。