設計変更の影響範囲を、部品表と図面と手配の状況から洗い出す

処理の起点を決める

設計変更の起票ではなく、変更が確定した時点を起点にします。 起票の段階では対象の部品が絞り込まれておらず、検討の途中で入れ替わります。確定していない番号で洗い出すと、確定後にやり直しになります。

入力は変更対象の部品番号、図面番号、変更の要旨の3つです。製品の型式や員数は部品表から引けるため、人に入力させません。番号が空、または書式が合わない起票では起動せず、起票者に差し戻します。

定時実行にはしません。 確定は日に1件から数件で、まとめて夜間に回すと当日に手配を止められません。発注残の扱いは、確定した日に決めるほど選択肢が多く残ります。

入力データを集める

この構成の質を決めるのは、部品表の親子関係が最新かどうかと、文書に部品番号が書かれているかどうかの2点です。 前者が古ければ、いちばん確実なはずの一段目が崩れます。後者が欠けた文書は三段目でしか拾えず、取扱説明書と客先仕様書は、多くの現場でその側に入ります。

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

探し方を三段に分け、それぞれの取りこぼしへの備えを別に用意します。

一段目は生産管理システムへの読み取り専用の照会です。 部品番号を渡すと、それを直接の子として持つユニットを返し、さらに上位へたどって製品の型式まで展開します。有効期間の切れた構成も含めて返させます。 サービス部品の問い合わせは、生産を終えた型式にも来るためです。

二段目と三段目は検索基盤に対して掛けます。 押さえておくべき仕様が2つあります。1つは、インデックス作成はJSONドキュメントに対してのみ行えることです。プッシュメソッドでJSONを直接アップロードするか、プルメソッド（インデクサーまたはロジックアプリ）でデータを取得してJSONにシリアル化します。図面管理システムやファイルサーバーの文書は、そのままでは索引に載りません。

もう1つは、データソースの選び方です。Azure Blob Storage、Azure Cosmos DB、Microsoft SharePoint、Microsoft OneLake などからデータにアクセスでき、鮮度・待機時間・コンプライアンスのニーズに基づいて、インデックス付きアクセスまたはリモートアクセスを選びます。 図面と取扱説明書はインデックス付きで構いませんが、客先仕様書のように見せる範囲を絞りたいものは、置き場所ごと選び直す判断が要ります。

内部的には、受信テキストはトークン化されて反転インデックスに、受信ベクターはベクターインデックスに格納されます。 二段目は前者、三段目は後者を引いています。両方で出た文書は、重複を除いたうえで found_by を両方残します。

AIへ渡す前に整形する

1. 部品番号の正規化 … ハイフン、空白、全角と半角の違いを1つの規則に寄せます。索引を作るときと検索するときで、同じ規則を使います
2. 検索語の展開 … 旧図番、社内の通称、客先の呼称を対応表から引き、二段目の検索語に足します。この対応表はシノニムマッピングとして検索基盤側に持たせます
3. 文書の取り込み … 図面、取扱説明書、サービス文書、客先仕様書、治具の図面、検査手順書をJSONにし、索引へ入れます
4. チャンクとベクター化 … AIエンリッチメントにより、チャンク、ベクター化、その他の方法で生コンテンツを検索できるようにします。 分解図の説明文や注記のように、番号が書かれていない記述がここで三段目の対象になります
5. 区分の付与 … 製品・図面・取扱説明書・サービス文書・客先仕様書・治具・検査手順書のどれかを属性として持たせます。後で区分ごとの件数を数えるために要ります
6. 索引の更新時刻の取得 … 各区分の索引が最後に更新された時刻を取り、結果に添えます

4番目で、すべてをベクター化しようとしないでください。 出典は、ベクターは必須ではなく、類似性検索が必要な場合、またはベクターに均一化できるコンテンツがある場合にのみ使うとしています。図番と型番の検索は、フルテキストのほうが確実です。

AIに処理させる

させるのは、集まった検索結果を区分ごとに整理し、根拠を引用し、見つからなかった区分を明示することです。 探すこと自体は検索基盤の仕事で、生成AIは結果の読み取りと整理、そして影響先ごとの対応案の文面を担います。

1行目を軽く見ないでください。 三段のうち一段目だけは取りこぼしがありません。そこに「これは関係が薄そうだ」という判断を混ぜると、確実だった結果が候補に変わります。

指示内容を固定する

あなたは産業用機械の製造業で、設計変更の影響範囲の洗い出しを支援する立場です。
渡された検索結果だけを根拠に、影響を受ける可能性のある対象を並べてください。

【前提】
変更対象は部品番号 {part_no}（図面番号 {drawing_no}）です。
変更の要旨は {change_summary} です。

【やること】
1. 部品表の展開結果（bom_hits）に載っている製品とユニットは、
   1件も落とさずすべて affected に入れてください。
   found_by は bom、confidence は high としてください。
   関係が薄いと思っても、一覧から外さないでください。
2. 全文検索の結果（keyword_hits）は、その文書のどこに部品番号または
   図面番号が書かれていたかを evidence に原文のまま引用したうえで
   affected に入れてください。found_by は keyword です。
3. ベクター検索の結果（semantic_hits）は候補です。
   変更対象の部品を指していると読める記述があるものだけを affected に入れ、
   found_by を semantic、confidence を low としてください。
   指しているかどうか判断できないものは affected に入れず、
   unresolved に区分と理由を書いてください。
4. 同じ文書が複数の段で出た場合は1件にまとめ、
   found_by にはその文書が出たすべての段を残してください。

【厳守事項】
- 検索結果に無い製品番号・図面番号・文書名を書かないでください。
  自分の知識から補ってはいけません。
- evidence は検索結果の本文からそのまま引用してください。
  要約も、言い換えも、途中の省略もしないでください。
- 区分（type）が検索結果の属性から判断できない場合は、
  推測せず unknown としてください。
- 手配状況（open_orders）は照会結果の数値をそのまま載せてください。
  記載がなければ status を unknown とし、「不明」として扱ってください。
  照会できなかったことを 0 件と書いてはいけません。
- 検索したが1件も見つからなかった区分は、必ず unresolved に書いてください。
  「該当なし」と「探していない」を同じ扱いにしないでください。
- 対応の期限、変更の可否、影響の大小の評価を書かないでください。
  suggested_owners は担当部門の候補であり、割り当てではありません。

【検索結果】
bom_hits: {bom_hits}
keyword_hits: {keyword_hits}
semantic_hits: {semantic_hits}
open_orders: {open_orders}
index_updated_at: {index_updated_at}

「判断できないものは unresolved に書く」を明示しているのは、空にして返されると困るからです。 何も言わないと、確信が持てない候補は静かに落ちます。落ちたことは出力から分かりません。 落とすなら、理由が残る場所に落とさせます。

「0 件と書いてはいけない」も同じです。 照会が失敗したときに 0 が入ると、発注残が無いように見えます。無いことと、確かめられなかったことは意味が違います。

出力形式を固定する

次のJSONスキーマに従わせます。

{
  "change_id": "",
  "part_no": "",
  "drawing_no": "",
  "affected": [
    {
      "type": "product | drawing | manual | service_doc | customer_spec | jig | inspection | unknown",
      "id": "",
      "title": "",
      "found_by": ["bom | keyword | semantic"],
      "evidence": "",
      "confidence": "high | medium | low",
      "source": ""
    }
  ],
  "open_orders": {
    "purchase_open": { "count": 0, "quantity": 0, "status": "ok | unknown", "source": "" },
    "stock": { "count": 0, "quantity": 0, "status": "ok | unknown", "source": "" },
    "wip": { "count": 0, "quantity": 0, "status": "ok | unknown", "source": "" }
  },
  "unresolved": [
    { "type": "", "searched_by": "", "reason": "" }
  ],
  "suggested_owners": [
    { "type": "", "department": "", "reason": "" }
  ],
  "index_updated_at": ""
}

構造化する第一の理由は、found_by を残すためです。ここがこの設計の中心です。 どの段で見つかったかが分かると、担当者は semantic だけで見つかったものを重点的に確認できます。すべてを同じ形で並べた文章では、この読み分けができません。

第二の理由は、辞書を育てる材料になることです。 semantic だけで出た文書は、番号が書かれていない文書です。人がそれを影響先と認めたら、その文書での呼び方を二段目のシノニムマッピングに足します。次の設計変更では、同じ文書が keyword で出ます。 三段目の件数が減ることが、この構成が育っている証拠です。

第三の理由は、unresolved を一覧の一部として扱えることです。 自由文の報告では、見つからなかった区分は書き忘れられます。スキーマに欄があれば、空の配列かどうかを機械で判定でき、 空でない限り画面の上部に出せます。

evidence に引用を入れるのは、確認を速くするためです。担当者が文書を開かずに「この記述なら影響する」「これは別の部品だ」と判断できれば、確認は数分で終わります。 引用が無いと、結局すべての文書を開くことになります。

システムへ連携する

照会はすべて読み取り専用にします。 この構成は一覧を作るところまでで、部品表も設計変更の記録も書き換えません。記録へ戻すのは、人が確定した後です。

人が確認する

全件、人が確認します。確認せずに割り当てを出す設計にしません。

1. 根拠の引用を見る … evidence を読み、影響先かどうかを区分ごとに判断します。found_by が semantic だけのものから先に見ます
2. 一覧に無い影響先を足す … 知っている影響先が一覧に無ければ追加し、そのとき何という言葉でたどり着いたかを記録します
3. unresolved を1行ずつ埋める … 本当に影響が無いのか、探し方が足りなかったのかを書きます
4. 手配状況の扱いを決める … 発注残の変更連絡、在庫の使い切り、仕掛品の工程をどうするかを決めます
5. 対応する部門と期限を確定する … suggested_owners は候補です。決めるのは人です

確認の目標は1件20分です。 それ以上かかるなら、evidence の引用が短すぎるか、三段目の候補が多すぎます。多い場合は区分と時期でフィルターを掛けて絞ります。プロンプトで減らさせるのではありません。

例外に対処する

上から4行目を軽く見ないでください。 索引の更新が止まっていても、検索は何ごともなく結果を返します。静かに古い結果が出ることが、いちばん危ない壊れ方です。

記録を残す

• 実行日時、変更対象の部品番号と図面番号、変更の要旨
• 二段目に使った検索語の一覧（シノニムで展開された語も含む）
• 各段が返した件数と、区分ごとの索引の更新時刻
• 人が追加した影響先と、そのときたどり着いた言葉
• 人が候補から外した対象と、外した理由
• 確定した割り当て、期限、完了の記録

4つ目と5つ目が、この構成を育てる材料です。 追加された言葉はシノニムマッピングに足し、外された候補が繰り返し出るなら、三段目の検索対象を見直します。