新しい受注品の生産を検討するときに、過去の試作・量産の加工条件と不良の記録から形状・材質・公差の近い品番を探し、使った条件と起きた問題を生産技術の担当に示す
新しい受注品の工程と条件を検討するときに、過去の試作・量産の記録から材質・寸法・公差・形状の特徴の近い品番を探します。工程ごとに使った工具と条件、起きた不良と対策を、記録の番号付きで生産技術の担当に示します。
- 生成AI
- ChatGPT/Claude/Gemini
- AIサービス
- Azure AI/Google Vertex AI/OpenSearch
- 対象業界
- 医療/製造
- 対象部門
- 品質管理/生産
- 対象業務
- 情報検索
- 主な課題
- 判断に時間がかかる/属人化している/情報が見つからない
- AIで行う処理
- 検索(RAG)
- 主な効果
- 判断支援/属人化解消/検索時間短縮
- 導入難易度
- ★★★★☆
- 実装レベル
- 本格構成
- 費用感
- RAG・個別開発(大)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 図面を受け取り、材質・主な寸法・厳しい公差・形状の特徴(薄肉・深穴・細かい溝など)を読み取る
- 生産管理の仕組みで、同じ材質の品番を一覧にする
- 品番ごとの加工条件のファイルを開き、寸法と公差が近いものを探す
- 見つかった品番の不良と手直しの記録を、品質保証課の記録で探す
- 使えそうな条件と、起きた不良を工程の検討の資料に書き写す
- 工程と工具と条件を決め、試作の指示を出す
- 人担当者が図面を読み、画面に材質・主な寸法・厳しい公差・形状の特徴と、検討したい工程を入れる
- 自動材質の系統で絞り込み、寸法と公差の範囲で近い品番を探す
- 自動品番の中の工程の記録のうち、検討したい工程に合うものだけを取り出す
- 自動見つかった品番について、不良の種類ごとの件数を数える
- 自動工程の記録と不良の記録を生成AIに渡し、工程ごとの工具と条件、起きた不良と対策を記録の番号付きで並べさせる
- 人担当者が、近い品番で多かった不良と、使われた条件を読む
- 人新しい品番の工程と工具と条件を決め、試作で先に確かめる点を指示に書く
- 人試作のあと、使った条件と不良を記録する
各工程の詳しい説明を読む
- 図面を受け取り、材質・主な寸法・厳しい公差・形状の特徴(薄肉・深穴・細かい溝など)を読み取る
- 生産管理の仕組みで、同じ材質の品番を一覧にする
- 品番ごとの加工条件のファイルを開き、寸法と公差が近いものを探す
- 見つかった品番の不良と手直しの記録を、品質保証課の記録で探す
- 使えそうな条件と、起きた不良を工程の検討の資料に書き写す
- 工程と工具と条件を決め、試作の指示を出す
(a)材質で絞っても多すぎる。 SUS304の品番だけで数百あります。寸法と公差は品番ごとのファイルを開かないと分からないので、思い当たる品番から開いていくことになります。
(b)品番として似ていなくても、工程は似ている。 外形がまったく違う部品でも、内径の仕上げだけは同じ条件で削れる、ということがあります。品番の単位で探していると、この工程の前例が見つかりません。
(c)不良の記録が工程で結び付いていない。 品質保証課の記録には「内径寸法外れ」と書かれていても、どの工程のどの条件で起きたかは、報告の本文を読まないと分かりません。 時間が無いと、不良の記録を見ずに条件だけを写します。
(d)聞ける人に時間が集まる。 ベテランの2名は、1日に何度も「これに似た部品はあったか」と聞かれます。2名が不在の日は、検討そのものが止まるか、記録を見ずに条件を決めます。
- 【人】 担当者が図面を読み、画面に材質・主な寸法・厳しい公差・形状の特徴と、検討したい工程を入れる
- 【自動】 材質の系統で絞り込み、寸法と公差の範囲で近い品番を探す
- 【自動】 品番の中の工程の記録のうち、検討したい工程に合うものだけを取り出す
- 【自動】 見つかった品番について、不良の種類ごとの件数を数える
- 【自動】 工程の記録と不良の記録を生成AIに渡し、工程ごとの工具と条件、起きた不良と対策を記録の番号付きで並べさせる
- 【人】 担当者が、近い品番で多かった不良と、使われた条件を読む
- 【人】 新しい品番の工程と工具と条件を決め、試作で先に確かめる点を指示に書く
- 【人】 試作のあと、使った条件と不良を記録する
7番目が、この設計の分かれ目です。 画面に出るのは過去の部品の条件で、新しい部品の条件ではありません。 工具の摩耗の状態、機械の違い、取引先の要求の違いがあり、同じ条件で削れる保証はありません。 条件を決めるのは担当者です。
4番目を、記録を読ませる前に置いているのも意図してのことです。 1件ずつ読む前に、近い品番全体でどの不良が多かったかを見せると、記録を読むときの目の付け所が決まります。
02今回想定するシステム構成
担当者の画面(材質・寸法・公差・形状の特徴・検討したい工程) ▼【トリガー】担当者が「近い品番を探す」を押す AWS Lambda ── 材質を系統に置き換え、寸法と公差の探す範囲を決める ▼ Amazon OpenSearch Service(品番と工程の索引) ├─ term:材質の系統(filter) ├─ range:外径・長さ・最小の公差の範囲 ├─ nested:工程の記録(inner_hits で合う工程だけを返す) └─ terms の集計:近い品番の不良の種類ごとの件数 ▼ Claude(Amazon Bedrock)── 検索結果のブロックで渡し、記録の番号付きで並べる ▼ 担当者の画面(多かった不良 → 工程ごとの条件 → 不良と対策)
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 検索基盤 | Amazon OpenSearch Service(range、nested、terms の集計) | Azure AI Search、Vertex AI Search(Agent Search) |
| 生成AI | Claude(Amazon Bedrock。検索結果のブロックを引用付きで並べる) | OpenAI API、Gemini API |
| 連携 | AWS Lambda(探す範囲の決定、記録の取り込み) | AWS Step Functions |
| 保管 | Amazon S3(条件と不良の記録の写しと、検索の記録) | ― |
生産管理の仕組みと図面の保管の仕組みは、新しく足すものではありません。 この構成は品番と材質を読むだけで、受注も図面も書き換えません。 最初の準備は、加工条件の記録と不良の記録に、同じ「工程の番号」を持たせることです。
寸法と公差は、range で範囲を指定して探します。 公式のドキュメントでは、range は指定した範囲の値を持つ文書を探すもので、gte(以上)・lte(以下)などで範囲を指定します。外径20mmなら16〜24mm、のように、新しい部品の値から上下の幅を決めて探します。
工程の記録は、nested で持たせます。 公式のドキュメントでは、nested の項目は別々の文書として索引に入っているように検索され、 内側の項目が条件に合えば、親の文書が返ります。inner_hits を付けると、条件に合った内側の項目そのものも返ります。品番を返しつつ、合った工程の記録だけを画面に出せます。
03どうやって実装するのか
処理の起点を決める
担当者が画面で「近い品番を探す」を押したことを起点にします。 工程の検討は、図面を受け取って見積を出す前と、受注して試作を指示する前の2回あります。見積の段階で近い品番の加工時間を知りたいこともあるので、どちらの段階でも同じ画面を使います。
索引の更新は、記録が書かれるたびに行います。 加工条件の記録が保存されたとき、不良と手直しの報告が登録されたときに、その品番の文書だけを作り直して索引に入れます。 試作で起きた不良が、翌日の別の品番の検討に出るようにします。
量産で条件が落ち着いたときも、作り直します。 試作の条件と量産の条件は違うことが多く、量産の条件が入ったら、その工程の記録に「量産」の印を付けます。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 新しい部品の指定 | 材質、外径・内径・長さ、最小の公差、形状の特徴(薄肉・深穴・細溝など)、検討したい工程 | 担当者の画面 |
| 品番の情報 | 品番、取引先、材質、外径・内径・長さ、最小の公差、形状の特徴 | 生産管理の仕組みと図面 |
| 工程の記録 | 工程の番号、工程の種類、機械、工具、回転数、送り、切込み、加工時間、試作か量産か | 加工条件の記録 |
| 不良と手直しの記録 | 工程の番号、不良の種類、起きたこと、原因、対策、手直しの有無 | 品質保証課の記録 |
| 材質の系統の表 | 材質の名前と系統(オーステナイト系ステンレス、快削鋼、チタン合金など) | 生産技術課が作る表 |
質を決めるのは、工程の番号です。 工程の記録と不良の記録が工程の番号で結び付いていないと、内径の寸法外れがどの工程のどの条件で起きたのかが分かりません。 番号が無い過去の記録は、品番と日付と報告の本文から工程を割り当て、割り当てられないものは「工程不明」にします。
不良の種類は、決まった言葉で持たせます。 「びびり」「寸法外れ」「面粗さ不良」「バリ」「工具の欠け」のように、品質保証課と生産技術課で一覧を決め、報告のたびにその中から選びます。 第5章の4番目の集計は、この言葉の数を数えるので、自由な書き方のままでは数えられません。
データの取得方法を決める
品番1つを索引の1件にし、工程の記録をその中に nested で持たせます。 不良と手直しの記録は、工程の番号で該当の工程に結び付けて持たせます。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 材質の系統が同じ品番 | term(材質の系統、filter) | 削れ方の近い前例に絞る |
| 寸法と公差の近い品番 | range(外径・長さ・最小の公差) | 大きさと精度の近い前例 |
| 形状の特徴が同じ品番 | terms(薄肉・深穴など、should) | 加工の難しさの近い前例 |
| 検討したい工程の記録 | nested(工程の種類)+inner_hits | 合う工程の条件だけを返す |
| 多かった不良 | terms の集計(不良の種類) | 近い品番で多い不良を先に見せる |
組み合わせると、検索の要求はおおよそ次の形になります。
{
"size": 10,
"query": {
"bool": {
"filter": [
{ "term": { "material_family": "austenitic_stainless" } },
{ "range": { "outer_dia_mm": { "gte": 16, "lte": 24 } } },
{ "range": { "min_tolerance_mm": { "lte": 0.02 } } }
],
"should": [
{ "terms": { "features": ["thin_wall", "deep_hole"] } }
],
"must": [
{
"nested": {
"path": "operations",
"query": { "term": { "operations.type": "inner_finish_turning" } },
"score_mode": "max",
"inner_hits": { "size": 3 }
}
}
]
}
},
"aggs": {
"defects": { "terms": { "field": "defect_types", "size": 10 } }
}
}
最小の公差は「0.02mm以下」と、厳しい側だけで絞ります。 新しい部品より緩い公差の前例は、精度の面では参考になりにくいためです。外径と長さは上下に幅を持たせます。
score_mode は max にしています。 公式のドキュメントでは、nested の内側の項目のスコアを親にどう渡すかを avg(既定)・max・min・sum・none から選べます。合う工程が1つでもよく合えば上に来るよう、max にします。
不良の集計には、注意が一つあります。 公式のドキュメントでは、terms の集計は件数の多い上位の語を返すもので、 返らなかった語の文書の数は sum_other_doc_count に出ます。size の既定は10です。不良の種類が多いときは、画面に「その他○件」と出し、数え漏れが無いように見せます。
AIへ渡す前に整形する
- 材質を系統に置き換える … 材質の名前(SUS304、SUS316L など)を、材質の系統の表で系統に置き換えます。名前のままだと、削れ方の近い材質が別の物として扱われます
- 寸法と公差を数にそろえる … 「φ20 h7」のような図面の書き方を、外径の数と公差の幅の数にします。最小の公差は、図面の中でいちばん厳しいものを取ります
- 形状の特徴を決まった言葉にする … 薄肉・深穴・細溝・ねじ・偏心などを一覧から選びます。肉厚や穴の深さの比のような基準も一緒に決めます
- 工程の種類をそろえる … 「内径仕上」「内仕上げ」「ID finish」のような書き方を、工程の種類の一覧に置き換えます
- 試作と量産を分ける … 同じ品番の条件が試作と量産でシートに分かれていれば、工程ごとに「試作」「量産」の印を付けて両方持たせます
- 不良の種類を割り当てる … 過去の報告の本文から、不良の種類の一覧のどれに当たるかを割り当てます。割り当てられないものは「その他」にします
- 取引先の名前を外す … 索引には取引先のコードだけを入れ、名前は入れません
2番目を軽く見ないでください。 公差の書き方は図面ごとにまちまちで、数にそろえないと range で探せません。 過去の品番は、まず厳しい公差のある部品から数にそろえます。
6番目は、集計を意味のあるものにするためです。 過去の報告を割り当てる作業は手間がかかりますが、この割り当てが済むまでは、集計の数を信用しないでください。
AIに処理させる
探すのと数えるのは検索基盤で、生成AIには見つかった工程の記録と不良の記録を、担当者が工程の検討に使える形に並べさせます。
| させること | 中身 |
|---|---|
| 工程ごとの条件 | 品番ごとに、検討したい工程の工具・回転数・送り・切込み、試作か量産か |
| 起きた不良と対策 | その工程で起きた不良の種類、起きたこと、対策を1〜2文で |
| 新しい部品との違い | 材質・寸法・公差・形状の特徴のうち、新しい部品と違う点 |
| 試作で先に確かめる点の候補 | 近い品番で多かった不良と、その対策に関わる点(決めるのは担当者) |
| させないこと | 理由 |
|---|---|
| 新しい部品の条件の指示 | 条件は機械・工具・要求を見て担当者が決める |
| 条件の平均や中間の値を出すこと | 削れた前例のない条件を作ることになる |
| 記録に無い条件の補完 | 書かれていない値を推測させない |
| 不良の原因の断定 | 報告に書かれた原因をそのまま示す |
| 取引先の推測 | 索引には取引先のコードだけを入れている |
2行目がこの構成でいちばん大事な線引きです。 近い品番が3件あり、回転数がそれぞれ違えば、生成AIは「回転数は○○前後が目安です」と平均をまとめたくなります。 その値で削った前例は、どこにもありません。記録にある条件を、記録のとおりに並べ、まとめる計算はさせません。
4行目は、勧めではなく「確かめる点の候補」です。 近い品番10件のうち6件で内径の寸法外れが出ていれば、試作では内径を先に測る、という程度の指摘です。条件を変えるかどうかには触れさせません。
指示内容を固定する
あなたは生産技術課で、新しい部品の工程を検討する担当者に、
過去の品番の記録を示す立場です。渡した記録だけを根拠にしてください。
【新しい部品】材質 {material}、外径 {od}、内径 {id}、長さ {length}、
最小の公差 {tolerance}、形状の特徴 {features}、検討したい工程 {operation}
【近い品番で多かった不良】{defect_counts}(その他 {other_count} 件)
【過去の記録】品番ごとに、検討したい工程の記録と、その工程の不良の記録を
検索結果として渡します。stage は trial(試作)か production(量産)です。
【やること】
1. 品番ごとに、新しい部品と違う点(材質・寸法・公差・形状)を書く
2. 工程ごとに、工具・回転数・送り・切込みを記録のとおりに書き、
試作か量産かを添える
3. その工程で起きた不良があれば、不良の種類・起きたこと・対策を
1〜2文で書く
4. 多かった不良に関わる点を、試作で先に確かめる点の候補として挙げる
【厳守事項】
- 新しい部品の条件を指示しないでください。
「○○で削るとよい」「目安は○○」と書かないでください。
- 複数の品番の条件を平均したり、間の値を出したりしないでください。
- 記録に無い値を推測で埋めないでください。無いものは「記録なし」です。
- 試作の条件と量産の条件を混ぜないでください。
- 不良の原因は、記録に書かれたとおりに書いてください。
- 取引先に触れないでください。
「平均しない」を明記しないと、親切にまとめます。 条件が品番ごとにばらばらだと、読み手のために一つの目安を出すのが自然な振る舞いだからです。その目安は、削った実績の無い値です。 まとめる行為そのものを禁じます。
「試作と量産を混ぜない」も同じ理由です。 試作で不良が出た条件と、量産で落ち着いた条件を並べずに一つに書くと、不良の出た条件を、量産で使える条件と読み違えます。
記録は、Claude の検索結果のブロックで渡します。 公式のドキュメントでは、検索結果のブロック(source・title・content)で渡すと、自社の内容を引用付きで答えられ、 Amazon Bedrock でも使えます。source に工程の番号を入れ、画面から元の記録を開けるようにします。 公式のドキュメントでは、検索結果の中身は文章だけで、画像は入れられないとされているので、図面は渡しません。
出力形式を固定する
引用付きの文章を受け取り、Lambda が次の形のJSONに組み直して画面に流し込みます。
{
"new_part": { "material_family": "austenitic_stainless", "od_mm": 20.0, "min_tol_mm": 0.01 },
"defect_summary": [{ "type": "寸法外れ", "count": 6 }, { "type": "びびり", "count": 3 }],
"other_defect_docs": 1,
"precedents": [
{
"part_id": "P-23-0871",
"differences": ["材質:SUS316L", "外径:22mm"],
"operations": [
{
"op_id": "OP-23-0871-04",
"type": "inner_finish_turning",
"stage": "trial | production",
"tool": "", "speed_rpm": 0, "feed": "", "depth": "",
"defects": [{ "type": "寸法外れ", "what": "", "countermeasure": "" }],
"citations": ["OP-23-0871-04", "NC-23-0144"]
}
]
}
],
"check_first": [""]
}
1つ目の理由は、defect_summary を画面の最初に置けることです。 近い品番で多かった不良を数で見せ、記録を読む前に目の付け所を決められます。 other_defect_docs で、集計に入らなかった数も見せます。
2つ目は、stage で試作と量産を分けて表示できることです。 量産で落ち着いた条件を上に、試作で不良が出た条件を下に、色を分けて並べられます。
3つ目は、citations で元の記録を開けることです。 条件を写す前に、元の工程の記録と不良の報告を開いて確かめられます。 生成AIの文章だけで条件を決めさせないためです。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 担当者の画面 | 社内の画面 | 新しい部品の指定を受け取り、結果を表示する |
| 生産管理の仕組み | 読み取り | 品番・材質・取引先のコードを引く |
| 加工条件の記録・不良の記録 | 読み取り | 工程の記録と不良の記録を取り込む |
| Amazon OpenSearch Service | 検索の API | 近い品番と工程を探し、不良を数える |
| Claude(Amazon Bedrock) | API呼び出し | 記録を引用付きで並べる |
加工の機械にはつなぎません。 条件をプログラムとして機械に送る連携は作りません。条件をプログラムにするのは、これまでどおり担当者です。 仕組みが条件を機械に送る作りにすると、不良の出た試作の条件がそのまま機械に入る経路ができます。
加工条件の記録と不良の記録にも書き込みません。 試作のあとの記録は、これまでどおり担当者と品質保証課が書きます。
人が確認する
担当者が読み、工程と条件は担当者が決めます。
- 多かった不良を見る …
defect_summaryで、近い品番で多い不良を確かめます。集計の数は、不良の種類の割り当てが済んだ記録の範囲です - 新しい部品との違いを見る …
differencesで、材質・寸法・公差・形状のどこが違うかを確かめます - 試作と量産を分けて読む … 量産の条件を参考にし、試作の条件は不良の記録と一緒に読みます
- 元の記録を開く … 写そうとする条件は、元の工程の記録で確かめます
- 試作で先に確かめる点を指示に書く …
check_firstを参考に、担当者が決めます
4番目を省かないでください。 生成AIは記録を並べ直しているだけですが、単位の付け間違いや、試作と量産の取り違えがあれば、そのまま条件に入ります。 写す数字は、元の記録から写します。
目標は、1件14分です。 多かった不良を見て、近い品番の工程の条件と不良を読み、元の記録を開いて確かめるまでの時間です。品番のファイルを開いて探す時間と、不良の記録を探す時間が、ほぼ無くなります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 近い品番が1件も無い | 寸法の幅を広げて探し直し、それでも無ければ「前例なし」と表示する |
| 材質の系統が同じでも、材質の名前が違う | differences に材質の名前を出し、削れ方の違いを担当者が確かめる |
| 工程の記録が「工程不明」の不良 | 品番の不良としては数えるが、工程には結び付けずに表示する |
| 不良の種類が「その他」ばかり | 集計の数を参考にとどめ、報告の本文を読むよう表示する |
| 試作の条件しか無い | 「量産の条件なし」と表示する |
| 図面の公差を数にそろえられない | その品番は range の対象から外し、材質と形状だけで探す |
| 記録が古く、今は無い機械で削っている | 機械の名前を出し、「現在の設備に無い機械」と印を付ける |
| 検索基盤が応答しない | 「表示できない」と出し、これまでどおりファイルとベテランに聞く手順に戻す |
最初の行で幅を広げたときは、そのことを必ず表示してください。 外径20mmの部品に、外径40mmの前例が出たことに気づかないと、大きさの違いによる削れ方の違いを見落とします。
7行目は、機械を入れ替えた工場で多く起きます。 古い機械の条件は、機械の剛性や主軸の違いで、そのままは使えないことがあります。
記録を残す
- 新しい部品の指定と、検索の条件(寸法の幅を広げたか)
- 返した品番と工程の番号、
defect_summary - 生成AIに渡した記録と、返ってきた文章と引用の全文
- 担当者が開いた元の記録と、参考にした工程の番号
- 新しい品番の試作の結果(不良の有無と種類)
- 前例なしだった部品の指定の一覧
4行目と5行目を結び付けると、効き目が見えます。 参考にした工程があった品番と、無かった品番で、試作の不良の数がどれだけ違うかを比べられます。
最後の行は、新しい加工の領域の地図になります。 前例なしが続く材質と寸法の組は、工場がまだ経験していない領域で、試作の時間を多めに見積もるべきところです。
04実装レベルの3段階
半自動化で、①の18分が6分ほどになります。 材質・寸法・公差で探せるようになりますが、不良の記録は品質保証課の記録で別に探す作業が残ります。 本格構成で、不良を工程に結び付けて数え、一つの画面に並べて1件14分にします。この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化を使うと、公差を数にそろえられていない品番と、工程の書き方のばらつきが見えてきます。それを直し、不良の種類の割り当てを進めてから集計に進むほうが、数の信頼が上がります。
05工数削減シミュレーション
導入後 150件 × 14分 ÷ 60 = 35 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 旋盤・マシニングセンタで多品種の部品を受託で削る工場。試作と量産の加工条件の記録と、不良・手直しの記録が残っているが、品番ごとのファイルに分かれていて、材質や公差で横断して探せない場合。新しい受注のたびに、似た部品を削ったことのあるベテランに聞いて工程を決めている場合。AWS を使っているか、使える場合。
- 同じ品番を長く量産していて、新しい品番の検討が年に数件しかない場合。加工条件を記録しておらず、プログラムの中にしか残っていない場合(先に条件の記録の残し方を決めるのが先です)。なお、新しい品番の工程と条件を決めるのは生産技術の担当で、この構成は過去の記録を示すだけで条件を決めません。
07最小構成で試す方法
- 受注の多い材質の系統を1つ選ぶ(例:オーステナイト系ステンレス)
- その系統の品番を50件ほど選び、寸法・最小の公差・形状の特徴と、工程ごとの条件、不良の記録を書き出す
- 最近の新しい受注品を5件選び、同じ項目を書き出す
- 手元のAIサービスに渡し、「この新しい部品に、材質・寸法・公差・形状の近い品番を挙げ、指定の工程の条件と起きた不良を記録のとおりに書いてください。条件を平均したり勧めたりしないでください」と指示する
- 出てきた内容を、ベテランの生産技術の担当に見てもらう
5件は必ずやってください。 索引を作る前に、「ベテランが思い出す前例が、記録から引けるか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| ベテランが思い出すのと同じ品番が挙がり、不良も結び付いた | 索引と画面の仕組みに進む |
| 品番は挙がるが、不良がどの工程のものか分からない | 工程の番号を結び付けるのが先。構成は有効 |
| ベテランの思い出す品番が挙がらない | 形状の特徴の言葉が足りない。特徴の一覧を先に作る |
3行目が出ることは珍しくありません。 ベテランは、図面の形から「似ている」と判断しています。その判断を形状の特徴の言葉にすることが、この構成の準備のいちばん大事なところです。 ベテランに、似ていると思った理由を言葉で挙げてもらってください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 生成AIが条件を平均して目安を出す | 指示で禁じ、記録にある条件を記録のとおりに並べさせる |
| 試作の条件と量産の条件が混ざる | 工程の記録に stage を持たせ、表示を分ける |
| 品番として似ていないと前例が出ない | 工程を nested で持たせ、工程の単位で探す |
| 品番は出るが合わない工程の記録まで並ぶ | inner_hits で合った工程だけを返す |
| 公差の書き方がばらばらで探せない | 図面の公差を数にそろえ、最小の公差を取る |
| 不良の集計の数が信用できない | 不良の種類を一覧から選ぶ運用にし、過去の報告を割り当てる |
| 集計に入らなかった不良が見えない | sum_other_doc_count を「その他」として表示する |
| 寸法の幅を広げた結果に気づかない | 広げたことを画面に表示する |
| 古い機械の条件をそのまま使う | 現在の設備に無い機械に印を付ける |
上の2行が、この構成の失敗のほとんどです。 どちらも「条件を一つにまとめたい」という読み手の気持ちに、仕組みが応えてしまうことから起きます。前例は前例のまま並べることが、この構成の約束です。
不良の集計の信頼も、同じくらい早く効いてきます。 数が当てにならないと分かると、担当者は画面の最初の行を読まなくなります。 不良の種類の割り当てを、索引を作る前に進めてください。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 加工の条件、不良と手直しの記録、品番の寸法と公差です。加工の条件は工場のノウハウそのもので、寸法と公差は取引先から預かった図面に基づく情報です。
- 加工の条件を外へ出さない … 生成AIのサービスに渡す範囲と、データの扱いの条件を契約で確かめます
- 取引先の図面の情報の扱いを確かめる … 寸法と公差は、取引先との秘密保持の取り決めの対象です。外部のサービスで処理してよいか、取り決めを確かめます。 索引には取引先の名前を入れず、コードだけにします
- 条件を決めない … 画面に出るのは過去の条件です。新しい部品の条件は担当者が決め、 医療機器の部品のように取引先の承認が要る条件の変更は、これまでどおりの手順で行います
- 画面を見られる人を絞る … 取引先ごとの部品の情報を、別の取引先の担当の営業が見られないようにします。営業が前例の条件を見積の根拠として取引先に出す経路を作りません
- 記録を人の評価に使わない … 誰が検討した品番で不良が多かったかが分かる作りにすると、不良が記録されなくなります
誤りが起きた場合のリスクは、不良の出た試作の条件を写すことと、寸法や材質の違う前例を同じものと思い込むことの2つです。 前者は stage の表示と元の記録の確認で、後者は differences の表示で防ぎます。どちらも、条件を決める前に人が読む画面の作り方で守ります。
10まず何から始めるか
1週目:一覧を決める
ベテランの生産技術の担当と、形状の特徴の一覧と、不良の種類の一覧を決めます。今日からの不良の報告では、不良の種類を一覧から選ぶようにします。
2週目:5件で試す
受注の多い材質の系統の品番50件を書き出し、最近の新しい受注品5件で、手元のAIサービスに近い品番と条件と不良を挙げさせます。ベテランに見てもらい、思い出す前例が挙がるかを最優先で確かめます。
3週目:公差と工程をそろえる
その系統の品番について、図面の公差を数にそろえ、工程の書き方を一覧に置き換えます。工程の記録と不良の記録に、工程の番号を振る運用もこのときに決めます。
4週目:索引を作る
その系統の品番と工程を Amazon OpenSearch Service に入れ、担当者が材質・寸法・公差・工程で探せる画面を作ります。この時点では不良の集計をせず、半自動化として使ってもらいます。
2か月目: 不良を工程に結び付けて数え、条件と不良を引用付きで並べます。3か月目以降: 他の材質の系統に広げ、前例なしの件数と、参考にした工程があった品番の試作の不良の数を毎月数えます。1件36分が何分になったかを実測した時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
range が指定した範囲の値を持つ文書を探すこと。gte(以上)・lte(以下)などで範囲を指定すること | OpenSearch Documentation: Range query | 2026-10-08 |
nested の項目が別々の文書として索引に入っているように検索され、内側が合えば親の文書が返ること。inner_hits で合った内側の項目が返ること。score_mode が avg(既定)・max・min・sum・none から選べること | OpenSearch Documentation: Nested query | 2026-10-08 |
terms の集計が語ごとにバケットを作り、上位の語を返すこと。size の既定が10で、返らなかった語の文書の数が sum_other_doc_count に出ること | OpenSearch Documentation: Terms aggregation | 2026-10-08 |
検索結果ブロック(source・title・content)で自社の内容を渡すと引用付きで答えること。Amazon Bedrock でも使えること。中身は文章だけで画像は入れられないこと | Claude Docs: Search results | 2026-10-08 |
加工の条件は、自社の設備と工具、取引先の要求と承認の手順に従って決めてください。 本記事は公開仕様で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0956)についてのご相談はこちらから。
