不具合報告書が表記揺れと番号記法の不統一で検索できない。不良モード同義語辞書と、製品番号×金型番号×工程×不良モードの複合キー設計、検索失敗ログの運用サイクルを、樹脂成形Tier2の品質保証部門向けに整理します。
客先から「前回の是正処置と同じ不良ではないか」と問われる。回答期限は数日。ところが手元にあるのは年度別フォルダに分かれたExcelの不具合一覧と、スキャンしただけのPDFの不具合報告書、別系統で保管されている是正処置報告書。ファイルサーバの全文検索に不良モード名を打ち込んでも、出てくるのは直近の数件だけ——この記事が扱うのは、この一点だけです。樹脂射出成形のTier2で品質保証を担う方が、「再発かどうか」を客先の回答期限内に自社の記録で言い切れる状態に近づくために、データの側で何を整えるかを書きます。
再発判定は、本来は記録の照合作業です。しかし実務では「あの不良、たしか3年前にもあった気がする」という個人の記憶が入口になりやすく、その記憶を持つ人が不在だと照合そのものが始まらない、という状態が生じ得ます。ここで問われているのは知識の継承以前の話で、記録が引ける形で残っているかという一点です。引ければ記憶に頼る必要は減り、引けなければ何年在籍していても毎回探し直しになります。
検索が外れる場面を分解すると、原因の多くはデータの書式側に寄っていると考えられます。同じ現象を指す言葉が複数併存している。識別子の書き方が票ごとに違う。PDFに文字情報が入っていない。一件の事象が複数の文書種別に分かれている。これらはいずれも、検索エンジンを高性能なものに入れ替えても自動的には解消しません。文字列が違うものは違うものとして扱われるためです。
範囲を明示しておきます。扱うのは、不具合票という自由記述データの前処理、不良モード同義語辞書の作り方と運用、製品番号×金型番号×工程×不良モードの複合キー設計、検索失敗ログを辞書改善に回す運用サイクル。扱わないのは、暗黙知・属人化そのものの経営リスク論、規程・マニュアルを対象としたRAG一般論、製品機能紹介や導入実績、そして検査工程の自動化・画像検査の話です。
既存の熟練者の暗黙知とAI、検査の属人化という経営リスクは、いずれも“人に知識が貼り付いている状態そのもの”を扱う経営リスクの構造論であり、打ち手の粒度は方針レベルにとどまります。社内文書をAIに答えさせる仕組み（RAG）とはは規程・マニュアルという“あらかじめ整った正文書”を対象にした仕組み解説であり、書式が統一され改訂管理もされている文書群を前提にしています。/ai-agent-platform/ のCASE01・CASE08は機能の紹介レベルで、どう作るかの設計判断には踏み込んでいません。本記事はこれらのいずれにも属さない層、すなわち“現場が都度書いた自由記述の不具合票”という最も汚いデータ一種類に対象を絞り、不良モードの同義語辞書をどう起こすか、製品番号・金型番号・工程・不良モードをどう複合キーにするか、検索が外れたときにその失敗をどう辞書へ戻すかという前処理・キー設計の実装論だけを扱います。構造論（なぜ失われるか）ではなく、正規化スキーマ（どう引けるようにするか）を書く点で、役割が重なりません。
ここは公開されている技術文書で広く共有されている事実の整理です。以降のNsight VIEWセクションと区別して読んでください。
一般的なキーワード検索は、入力された語と索引上の語の一致を基本にしています。したがって「シンクマーク」で検索したとき、票に「ヒケ」とだけ書かれていれば、その票は一致対象になりません。同義語辞書を用意しない限り未登録の言い換えはヒットしない、という挙動はElasticsearchでの同義語を利用した検索などの技術解説でも説明されています。
日本語の索引づくりでは、文章を語に分割する処理（形態素解析）が入りますが、その分割単位は解析器と辞書の設定に依存します。kuromojiのような日本語向けプラグインを使う構成が一般的で、複合語を含む同義語定義では分割のされ方に起因して期待どおりに展開されない、あるいは定義投入時にエラーになるといった挙動差が知られています（Elasticsearchのkuromoji tokenizerと同義語辞書の挙動）。「銀条」と「シルバーストリーク」のように、漢語とカタカナ語が併存し、かつ複合語になりやすい語が多い領域では、この点が実装上の論点になり得ます。
同義語の扱いは、検索エンジン側の標準機能として用意されています。Elasticsearchにはsynonym token filter、および複合語を含む同義語をグラフとして扱うsynonym_graph token filterがあり、インデックス作成時または検索時に同義語を展開できます（Elasticsearchで日本語を同義語展開する）。つまり「仕組みがない」わけではなく、どの語を同義語として定義するかという中身を誰が作るかが残る課題だという整理になります。
一方で、同義語辞書を大規模にすると索引作成側の負荷や性能に影響が出る場合があることが実務報告として共有されています（大規模同義語辞書でElasticsearchのIndex作成が重くなる問題とその対策 — Sansan Tech Blog）。これは単一事例の報告であり、環境や構成の異なる他社にそのまま当てはまるとは限りませんが、少なくとも辞書は多ければ多いほど良いという単純な話ではない可能性を示す材料として参照できます。
ベクトル検索（意味検索）だけでは、型式番号やエラーコードのような固有の記号列の一致を取りこぼしやすいことが指摘されています。Anthropicは、チャンクに文脈を付与するContextual Embeddingsとキーワード検索（BM25）の併用によって検索失敗率が下がると報告しており、埋め込み検索は「TS-999」のような特定のエラーコード文字列の一致を外す一方、BM25はその文字列を捉えられると説明しています（Contextual Retrieval in AI Systems — Anthropic）。ここで示されている改善幅の数値は提供元が公表している値であり、測定条件が異なる自社環境での再現を保証するものではありません。本記事では数値を自社の見込みとして転用せず、「固有記号はキーワード一致が要る」「自由記述は意味検索が効きうる」という構成上の示唆としてのみ受け取ります。金型番号やロット番号は、まさにこの「固有記号」に該当する種類のデータだと考えられます。
本記事では樹脂成形の不良モード名をいくつか例示しますが、JIS等の公的な不良モード分類は本記事執筆時点で未確認です。列挙する語はあくまで現場で使われうる呼称の例であり、業界標準用語であると断定するものではありません。標準側の用語体系に合わせる必要がある場合は、客先要求仕様や適用規格を個別にご確認ください。
検索しにくいデータにも度合いがあります。不具合票は、社内文書の中でもかなり難しい側に位置すると整理できます。以下は特定の企業の実態ではなく、一般に起こりうる状態の列挙です。
不具合票で最も情報量が多いのは、「現象」「発生状況」といった自由記述欄になりやすいと考えられます。ここに書かれる語は、書いた人が普段口にしている表現に引かれます。同じ現象でも、検査担当が書けば見え方の語、成形技術者が書けば原因寄りの語になることがあり、票ごとに語彙の層が変わり得ます。こうした口頭語彙がどこに蓄積しているかという点は、熟練者の暗黙知とAIで扱った論点と接続します。辞書に載せるべき語の出所は、結局のところ現場の担当者の語彙です。
表記揺れは、単なる誤記ではなく複数の正しい呼び名の併存として現れます。例えば樹脂成形の収縮による表面のくぼみは、「ヒケ」「凹み」「ヘコミ」「シンクマーク」「sink mark」といった形で票に現れ得ます。漢字・カタカナ・英字・送り仮名の違いが重なるため、文字列一致では系統的に取りこぼしが起きやすい構造です。
識別子は本来もっとも安定しているべき部分ですが、実務では揺れが入りやすい箇所です。全角と半角の混在、ハイフンの有無、枝番の書き方（-1／_1／A）、先頭ゼロの脱落、Excelのセル書式によって数値として解釈され桁が変わる、といった現象が重なります。人の目には同じ番号に見えても、検索上は別の文字列として扱われます。
紙で運用していた期間の不具合報告書をスキャンして保管している場合、そのPDFに文字情報（テキスト層）が含まれていないことがあります。この状態では、内容が何であれ全文検索の対象になりません。検索でヒットしないのではなく、検索の射程に入っていない、という状態です。
一つの不良が、不具合報告書・是正処置報告書・4M変更届といった別々の様式に分かれて記録されることがあります。それぞれに採番があり、相互参照が本文中の手書きや備考欄にしか書かれていない場合、横串で1件の履歴として辿ることが難しくなります。再発判定で見たいのは「その後どう処置され、水平展開はどこまでされたか」まで含む一連の履歴であるため、この分散は効きます。
参考までに、規程・マニュアルのような正文書を対象にしたRAG（社内文書をAIに答えさせる仕組み（RAG）とは）と比べると、前処理の難易度の所在が違います。正文書は書式が統一され改訂管理もされているため、課題は版の混在や網羅範囲に寄ります。不具合票はそれ以前に、語彙も識別子も票ごとに違うという地点から始まります。同じ「社内文書をAIで引く」という枠に見えても、手を入れる層が異なる、という理解が設計時に役立つと考えられます。
ここからはNsightの見解（VIEW）です。外部の出典に基づく事実ではなく、設計上の判断として読んでください。断定できる性質の話ではないため、条件付きの表現で書きます。
いきなり同義語辞書の空欄を埋めようとすると、実際には使われていない語を並べてしまいがちです。取りやすいのは逆順で、過去票の自由記述欄から実際に使われた表現を抜き出すところから始める進め方だと考えられます。対象年度を絞り、現象欄のテキストを一覧にして、出現する呼称を並べる。この時点では整理せず、生の語をそのまま集めます。
集めた語は、代表語に寄せて整理します。1行に「代表語／別名／英字表記／現場の俗称」を並べる構成にしておくと、後で検索エンジン側の同義語定義へ機械的に写しやすくなります。代表語をどれにするかは、客先とのやり取りで使っている語に合わせておくほうが、再発報告の文面と整合が取りやすい場合があります。
骨格として置きやすいのは、自社で頻出する不良モードです。例として挙げるなら、ヒケ／ショートショット／バリ／ウェルドライン／フローマーク／ジェッティング／ボイド／反り／黒点・異物／銀条・シルバーストリーク／焼け、といった呼称が票に現れ得ます。これらはあくまで例示であり、前述のとおり公的な標準分類との対応は本記事執筆時点で未確認です。自社の票で実際に使われている語を優先してください。
辞書設計で効きやすいのが、この区別だと考えられます。「ヒケ」は見え方、「保圧不足」は原因です。これを同じ列に混ぜると、原因語で検索したときに原因が別の票まで巻き込まれ、再発判定の精度が落ちる可能性があります。辞書は見え方側に置き、原因は別項目（推定原因欄）として持つほうが、後の集計でも扱いやすくなると考えられます。
「不良」「NG」「傷」のような粒度の粗い語は、同義語として展開するとヒット結果がノイズだらけになりやすいと考えられます。こうした語は辞書本体に入れず、保留リストへ回して判断を残しておく。後述の月次の見直しで、文脈付きで扱うか（例：「傷」＋工程の組み合わせでのみ扱う）を議論する対象にします。
辞書を検索エンジンの設定ファイルとしてだけ持つと、編集のたびに情報システム側の作業になり、現場の呼び名が反映されにくくなります。表形式の台帳として品質保証部門が編集でき、そこから設定へ機械的に反映する形にしておくほうが、運用が続きやすいと考えられます。
辞書づくりを情報システム側の作業として切り出すと、現場の呼び名が落ちやすくなります。語彙の供給源は検査・成形の担当者であり、編集権限を品質保証部門側に置いておく設計のほうが運用が続きやすいと考えられます。また、最初から網羅を狙うより、客先から再発を問われる頻度が高い上位十数モードに絞って着手するほうが、効果を確認しながら広げられる可能性が高いと考えます。なお、AIが辞書を自動生成するので人手が不要になる、という整理は現実的ではありません。現場の俗称は一般的な言語モデルが知らない語である場合があり、候補語の抽出をAIに手伝わせるとしても、採否の判断は人が持つ前提で設計するのが安全だと考えられます。
辞書だけでは「同じ言葉の票」は集まっても、「同じ条件の票」は集まりません。再発判定で必要なのは後者です。ここではキー設計の考え方を整理します。
品番だけで引くと、同じ製品でも金型違い・成形号機違い・工程違いの票が一緒に出てきます。逆に不良モードだけで引くと、別製品の同名不良まで混ざります。再発と呼べるかどうかの判断は、どの軸が一致しているかで変わるため、単一キーでは判定材料が足りなくなる場合が多いと考えられます。
軸として置きやすいのは次の4つだと考えます。製品番号（自社品番・図番・客先品番の対応表を持つ）、金型番号（枝番・取り数・入れ子まで識別できる粒度）、工程（成形・二次加工・組立・検査のどこで検出したか）、不良モード（辞書で代表語に正規化済みのもの）。この4軸が揃っていると、「同一品番・同一金型・同一工程・同一モード」から「品番だけ一致」まで、一致の強さを段階的に見られるようになります。
キーを作る前に、識別子の書き換えルールを決めて文書化しておくほうが手戻りが少ないと考えられます。半角統一、ハイフンや空白の除去、先頭ゼロの保持、文字列型での固定（Excelで数値化させない）、そして元の表記を別欄に残すこと。ルールを後から変えると、過去に作った索引との整合が崩れる場合があります。
正規化値だけを持つと、なぜその票がヒットしたのかを説明できなくなります。客先説明や内部監査の場面では、「原文にはこう書かれており、正規化ルールによりこのキーに寄せた」と辿れることが求められる場合があります。正規化値と原文の両方を持たせる構成が扱いやすいと考えられます。
| キー項目 | 正規化ルール（例） | 原文保持 | 再発判定での使い方 |
|---|---|---|---|
| 製品番号（品番・図番） | 半角統一・ハイフン除去・先頭ゼロ保持・文字列型固定。客先品番は対応表経由で自社品番に寄せる | 保持する | 一致の起点。客先品番での問い合わせを自社品番に変換して引く |
| 金型番号 | 半角統一・枝番の書式を1通りに統一・取り数／入れ子は別欄に分離 | 保持する | 同一品番でも金型が違えば別事象として扱うかの判断に使う |
| 工程 | 成形／二次加工／組立／検査などの区分コードに寄せる。工程名の自由記述は別欄 | 保持する | 検出工程が同じか、流出か工程内かの切り分けに使う |
| 不良モード | 辞書の代表語に正規化。別名・英字・俗称は辞書側に置く | 保持する（原記述をそのまま） | 同一モードかの判定。原記述は客先説明時の根拠として提示 |
| ロット／材料ロット・グレード | 半角統一・採番規則の年度差を別欄に記録 | 保持する | 材料起因の疑いがある場合の絞り込み（副次キー） |
| 成形号機 | 号機番号の表記を統一 | 保持する | 設備起因の再発かの切り分け（副次キー） |
| 発生日・客先通知日 | 日付型に統一（和暦・スラッシュ表記を吸収） | 保持する | 時系列での再発間隔の確認（副次キー） |
| 是正処置番号・水平展開先 | 採番の書式統一。水平展開先は品番／金型番号の配列として持つ | 保持する | 前回処置の有効性と展開漏れの確認（副次キー） |
| 事象ID | 関連文書を束ねる内部IDを新規付与 | ―（新規項目） | 不具合報告書・是正処置報告書・4M変更届を1件の履歴として引く |
4軸のほかに、ロット／材料ロット・グレード／成形号機／発生日・客先通知日／是正処置番号・水平展開先／流出か工程内か、といった項目を副次キーとして持たせておくと、絞り込みの角度が増えると考えられます。これらは一致条件としてではなく、候補が出たあとの切り分け材料として使う想定です。
複数様式への分散に対しては、内部的な事象IDを1つ付与して束ねる方法が扱いやすいと考えられます。不具合報告書・是正処置報告書・4M変更届を同一の事象IDで紐づけ、1件の履歴として引けるようにする。既存の採番体系を変えずに、対応表として持つ形でも成立します。
実装面では、識別子はキーワード一致（完全一致・前方一致）で引き、自由記述は同義語展開＋意味検索で引く、という二層の併用が現実的だと考えられます。前述のFACTで触れたように、固有の記号列を意味的な近さで引くのは不利になりやすい一方、口語的な現象の記述は意味検索が効きうるためです。
「検索できるようにする」作業の中心は、検索エンジンの選定ではなく、どの4軸で同一性を判定するかという定義合意である可能性が高いと考えます。定義が曖昧なままツールを入れても、ヒットした件が再発かどうかの判断は人に戻ってきます。また、客先品番と自社品番の対応表が整っていない場合、検索改善より先にこの対応表の整備のほうが効くことがあります。なぜ再発判定が個人依存になりやすいのかという背景は、検査の属人化という経営リスクで扱った構造とも重なります。
辞書とキーを一度作れば終わり、という前提の計画は崩れやすいと考えられます。ここでは維持のための運用を扱います。
新しい不良モード、新しい客先固有の用語、新しい材料や工法に伴う呼称は、年度が変わるごとに増えていきます。辞書v1は「現時点で分かっている範囲」であり、不完全であることを前提に運用設計を置くほうが現実的だと考えられます。
改善の材料になるのは、成功ではなく失敗のログです。拾う対象として挙げられるのは、（1）0件ヒットになった検索語、（2）ヒットしたが結果を開かれなかった検索語、（3）再検索で言い換えられた語、（4）人手で見つけた過去票が検索では出てこなかったケース。とくに（4）は自動では取れないため、再発確認の作業手順の中に「検索で出なかったものを1行書き残す」動作を組み込んでおく必要があると考えられます。
運用イメージとしては、品質保証＋成形技術＋検査の担当者で月に一度、短時間（15〜30分程度）の枠を取り、追加候補語と保留語の判断だけを行う形が挙げられます。議題を「候補語の採否」に絞っておくと、会議が設計論に流れずに済むと考えられます。
変更の種類を分けておくことが重要だと考えます。別名の追加は影響範囲が限定されますが、新しい代表語の追加はモードの粒度を変えるため、過去データとの比較可能性に影響します。新代表語の追加は慎重に扱い、既存モードの別名として吸収できないかを先に検討する、という順序が安全だと考えられます。
いつの辞書で引いた結果かを示せるようにしておくと、客先説明や監査対応で扱いやすくなります。版番号、変更日、追加・削除した語、判断者を残す。検索結果を報告書に載せる際に、どの版で検索したかを併記できる状態が望ましいと考えられます。
ヒット率そのものを追うと、ノイズの多い辞書のほうが高く出てしまう場合があります。現場の実感に近い指標としては、「再発確認の回答に要した工数」「0件ヒットの推移」のほうが扱いやすくなりうると考えます。いずれも自社で基準値を取ってから比較する前提で、他社の改善幅を目標値として置くことはおすすめしません。
検索精度を一度で上げ切る前提の計画は崩れやすいと考えられます。0件ヒット語を毎月数語ずつ辞書へ戻す運用のほうが、辞書の当たり幅は安定して広がると考えます。また、客先監査・内部監査の観点では、検索できること以上に「どの版の辞書で・どの範囲を・どう探したか」を示せることが問われる場面があります。探索の再現性が説明できる状態を、最初から運用に含めておく価値があると考えられます。
以下は着手前に決めておくと手戻りが減ると考えられる項目です。いずれも技術選定より前の、範囲と定義の話です。
「過去の不良が検索でヒットしない」という症状に対して、検索ツールの性能を上げる方向で手を打っても、文字列が違うものは違うものとして扱われるという構造は変わりません。扱う対象は探し方ではなく、引くためのキーと語彙の側だと捉えるほうが、打ち手が具体になると考えられます。
辞書だけを整えると、同じ言葉の票は集まっても条件が違う票が混ざります。キーだけを整えると、条件で絞れても現象の呼び名が違う票が落ちます。どちらか片方では「前に同じことが起きたか」は引けない、という理解が出発点になると考えられます。
始めやすいのは、上位不良モード20語程度の棚卸しと、識別子の正規化ルールを1枚にまとめることだと考えます。どちらも検索システムの導入を待たずに着手でき、仮にツールを入れない判断になったとしても、台帳の整備として価値が残る範囲です。この2枚があれば、その後の設計判断はかなり具体的に議論できるようになると考えられます。
意味の近い表現をまとめる用途では意味検索が働く場面があります。一方で、金型番号やロット番号のような固有の記号列は、意味的な近さでは区別がつきにくく取りこぼしが起こりうることが公開されている技術解説でも指摘されています（例：Anthropicは埋め込み検索が特定のエラーコード文字列の一致を外す一方、キーワード検索（BM25）はそれを捉えられると説明しています）。このため識別子はキーワード一致、自由記述は同義語展開＋意味検索という二層構成で設計するのが現実的と考えます。辞書が不要になるわけではなく、現場の俗称のように一般的な言語モデルが知らない語ほど辞書側で明示する必要が残ります。
網羅は必須条件ではないと考えます。客先から再発を問われる頻度が高い不良モードは限られる場合があり、上位十数モード程度の代表語と別名を整えるところから始めても、再発確認の当たりやすさは変わり得ます。加えて、大規模な同義語辞書はインデックス側の負荷に影響する場合があることが実務報告として共有されており、最初から巨大な辞書を積む設計は必ずしも有利ではありません。まず小さく作り、0件ヒットのログを見ながら追加していく進め方を推奨します。
テキスト層がないPDFは、そのままでは全文検索の対象になりません。文字認識を通す前処理が別途必要になります。ただし手書き欄や捺印、劣化したコピーが混ざる場合は認識精度が一定しないため、全件を機械処理で揃えることを前提にしないほうが安全です。現実的には、（1）まずテキスト層の有無を棚卸しし、（2）金型番号・品番・不良モード・発生日といった検索キーだけを表紙情報として人手またはAI補助で台帳化し、（3）本文は原本PDFへのリンクで辿れるようにする、という段階的な進め方が取りやすいと考えます。全文が検索できなくても、4軸のキーが台帳にあれば再発確認の入口は作れます。
必ずしも入れ替えを前提にしないほうがよいと考えます。この記事で扱っているのは、既存システムやExcel・PDFに入っている記録を横断して引けるようにするための正規化ルールと辞書、そして検索用の索引側の設計です。原本の保管場所や記録の様式は現状のまま残し、検索用の台帳・索引を別に持つ構成でも成立します。既存の業務フローと承認ルートを変えずに始められる範囲から着手するほうが、現場の負荷と監査対応の観点でも扱いやすいと考えられます。
短縮幅を一般化して示せる数値は持っていません。効果は対象年数、文書の形式、識別子の記法の乱れ方、既存台帳の整備度によって大きく変わるため、他社の削減率をそのまま当てはめることはおすすめしません。代わりに、着手前に自社で測れる基準値を取っておく方法を提案します。直近の再発確認依頼をいくつか選び、（1）該当する過去票を見つけるまでの実作業時間、（2）検索で0件になった語、（3）結局人の記憶に頼った案件を記録しておけば、辞書v1導入後に同じ指標で比較できます。公開されている技術ベンチマーク（例：Anthropicが公表している検索失敗率の改善値）は手法の傾向を示すもので、自社の業務時間削減量を保証するものではない点にも留意が必要です。
過去の不良を検索で引けるようにする作業の中心は、ツール選定ではなく不良モード辞書と複合キーの定義合意にあると考えられます。貴社の不具合票の実態を見ながら、どこから小さく始められるかを一緒に検討します。AI導入・業務自動化・内製化支援について、検討段階からお気軽にご相談ください。
AI導入・内製化について相談する