2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

歩留まり予測に機械学習を入れたら精度99%でも現場は使わなかった

2
Posted at

歩留まり予測に機械学習を入れたら精度99%でも現場は使わなかった

半導体FAB(fabrication facility、ウェーハ製造工場)の歩留まり予測にML(機械学習)を導入する話は、ここ2年で急増している。ArXivを掘ると、異常予測にN-BEATS+GNN、SPCの予兆検知にTransformer、欠陥セグメンテーションに半教師あり学習、装置マッチングに統計的差分スコア——手法は山ほど出てくる。

どの論文もテストデータでの精度は高い。論文によってはF1スコア0.9超え、AUC 0.99、分類精度99%台を報告している。数字だけ見れば「もう解けた問題」に見える。

だが現場は使わない。

精度が足りないからではない。精度の出し方が現場の運用と噛み合わないからだ。この記事では、ArXiv論文5本を素材にして、MLが半導体歩留まり改善に入り込めない3つの構造的理由と、それでも攻略可能な突破口を整理する。


論文5本の概要: 何が提案されているのか

まず今回の素材を並べる。

1. N-BEATS + GNN による異常予測

Unsupervised Anomaly Prediction with N-BEATS and Graph Neural Network in Multi-variate Semiconductor Process Time Series (Sorensen et al., 2025)

N-BEATS(Neural Basis Expansion Analysis for Time Series)は時系列予測向けのディープラーニングアーキテクチャで、GNN(Graph Neural Network)はセンサー間の依存関係をグラフ構造で表現する。

数千パラメータの多変量時系列から、異常の予兆を検出する。教師なしなのでラベル不要。論文は2つのアプローチを比較検証している:

アプローチA: N-BEATS(各センサー独立)
  センサー群 → N-BEATSで正常パターン学習 → 残差 > 閾値 → アラート

アプローチB: GNN(センサー間依存を考慮)
  センサー群 → GNNで因果関係グラフ構築 → グラフ異常スコア → アラート

ポイントは事後の異常検出ではなく、異常が起きる前の予測を狙っていること。FABでは装置異常からウェーハ廃棄まで数時間のタイムラグがあるため、予兆段階で捕まえればウェーハの廃棄を減らせる。

2. AI駆動プロアクティブSPC

Proactive Statistical Process Control Using AI (Seeam, 2025)

従来のSPCは管理限界を超えてから対応する reactive な仕組み。この論文はFacebook Prophetで時系列予測を行い、次の測定値が管理限界を超えそうかどうかを事前に判断する。(注: 本論文はArXivから取り下げ済みだが、アプローチ自体の分析価値はあるため取り上げる。)

従来SPCとの違い:

従来SPC AI-SPC
検知タイミング 逸脱後 逸脱前
対応 停止→原因調査 予防保全→継続稼働
データ 単変量 多変量可
更新 管理限界固定 モデル再学習で適応

3. CdZnTe半導体の欠陥セグメンテーション

Harnessing Group-Oriented Consistency Constraints for Semi-Supervised Semantic Segmentation (Li et al., 2025)

CdZnTe(カドミウム亜鉛テルル)のウェーハ画像から欠陥をセグメンテーションする。低コントラストな欠陥境界が課題で、アノテーターは複数視点を照合して判断する。

この論文のアプローチは、複数視点から1つの正解を導くという特殊な構造(many-to-one)を活用した半教師あり学習。ラベルなし画像も学習に使えるため、アノテーションコストを下げられる。

4. 装置マッチング分析

Tool-to-Tool Matching Analysis Based Difference Score Computation (Bharadwaja et al., 2025)

同じ工程を担う複数装置間で、処理結果にどれだけ差があるかを定量化する。FABではA号機で処理したウェーハは歩留まりが良いがB号機は悪い、という装置間バラツキが常に存在する。

従来はゴールデンリファレンス(理想的な装置状態の基準値)と比較するが、量産ラインでゴールデンリファレンスを維持するのは困難。この論文は差分スコアという相対比較手法を提案し、異種装置(別メーカーの装置同士)にも適用可能にした。

5. TSMC向けLSTM+感情分析による業界トレンド予測

Semiconductor Industry Trend Prediction with Event Intervention Based on LSTM Model (Yen & Chen, 2025)

TSMCの四半期報告からテキストデータ(感情分析)と数値データ(財務指標)を組み合わせてLSTMで業界トレンドを予測。歩留まりの直接予測ではないが、この論文が示すのは「テキスト+数値のマルチモーダル入力」という方向性だ。プロセスエンジニアのログや設備保全記録をテキストデータとして活用する発想は、壁3(組織の壁)の突破口になりうる。


壁1: 精度のパラドックス——99%が役に立たない理由

5本の論文を読んで最初に感じるのは、どれも精度は出ている、ということだ。問題は、その精度が現場の意思決定を変えるかどうか。

半導体歩留まり予測で精度99%とは何を意味するか。ウェーハ1枚に数千のダイがある。歩留まり95%のプロセスなら、1000ダイ中50個が不良。ここで単純化のために感度(sensitivity)と特異度(specificity)がともに99%と仮定すると、50個中49.5個を当てて、正常950個中9.5個を誤検出する。

問題は、この9.5個の誤検出にある。

# 精度99%のモデルで歩留まり95%ラインを予測
total_die = 1000
defective = 50      # 実不良
normal = 950        # 実正常
accuracy = 0.99

true_positive = defective * accuracy    # 49.5 (正しく不良検出)
false_positive = normal * (1 - accuracy) # 9.5 (正常を不良と誤判定)
false_negative = defective * (1 - accuracy) # 0.5 (不良を見逃し)

precision = true_positive / (true_positive + false_positive)
# 49.5 / 59.0 = 83.9%

# 現場の反応: 「10個に1個は嘘じゃないか。じゃあ全部信用できない」

precision 83.9%。これはMLの世界では十分高い数字だ。だが半導体の現場では17%が偽陽性という結果は許容できない。不良疑いのダイを全数再検査するコストは、不良を最初からスクリーニングするコストと大差ない。さらに現場が嫌がる本当の理由はコスト非対称性だ。見逃し(偽陰性)のコストは数百万円のウェーハ廃棄で済むが、過検出による全ライン停止は時間あたり数千万円の機会損失になる。

論文1のN-BEATS+GNNは教師なし手法でこの問題を避けようとしている。閾値ベースの異常検知なら、閾値を調整して偽陽性率をコントロールできる。だが閾値を上げれば見逃しが増える。この見逃しが歩留まりロスに直結するのだから、結局は同じトレードオフに戻る。

本質: 半導体FABが求めているのは「不良を予測する」ことではなく「歩留まりロスの原因を特定して排除する」ことだ。予測はゴールではなく手段。論文の多くがこの区別を曖昧にしている。


壁2: データの壁——論文が軽く流す前処理が実は最重い

5本全てに共通する前提がある。構造化されたデータが存在すること。

N-BEATS+GNN論文は数千パラメータの時系列を入力とする。Proactive SPC論文は測定値の時系列を前提にする。装置マッチング論文は装置ごとのプロセスデータが手に入ることを仮定する。

実際のFABでは:

  1. データが散在している: 装置ログはCSV、検査結果はOracle DB、ロット情報はMES、物理解析はExcelとPDF。統合されていない
  2. サンプリングが不均一: 全数検査する工程と抜き取り検査する工程が混在。モデルが期待する全ウェーハの全パラメータなど存在しない
  3. ラベルが曖昧: 歩留まりロスの原因帰属は人間のエンジニアの判断。同じ不良モードでもエンジニアによって原因分類が違う
  4. 時系列がずれている: 装置Aのタイムスタンプ精度は1秒、装置Bは1分、MESは工程完了時刻のみ。結合するだけで一苦労

論文3のCdZnTe欠陥検出が面白いのは、この問題を正面から認めている点だ。「アノテーターは複数視点を照合して判断する」——つまり、正解ラベルの生成自体がドメイン専門知識を要求する。半教師あり学習でラベルなしデータを活用するのは、ラベル作成コストが高すぎるという現実への対処であり、「データが豊富にある」という前提が成り立たないことの裏返しだ。

論文の前提:
  クリーンなデータセット → モデル学習 → 高精度予測

現場の現実:
  散在データ → ETLパイプライン構築(数ヶ月) → データ品質改善(数ヶ月)
  → ようやくモデル学習 → 精度出ない → データ追加収集(さらに数ヶ月)
  → 再学習 → やっと精度が出る → その間にプロセス変更
  → モデル再学習が必要 → 振り出しに戻る

装置マッチング論文4がゴールデンリファレンスは量産ラインでは維持困難と述べているのは正直だ。だが提案する差分スコア手法も、装置間のデータフォーマットが統一されていることを前提にしている。異種装置対応を謳いながら、データ統合の泥臭さには触れていない。


壁3: 組織の壁——MLエンジニアとプロセスエンジニアは別の言語を話す

技術論文が完全にスルーしている最大の壁がこれだ。

半導体FABでは、プロセスエンジニアが歩留まりに責任を持つ。彼らはMLモデルのF1スコアに興味がない。知りたいのは、どの装置の、どのパラメータが、どういう物理メカニズムで不良を引き起こしているのか、だ。

N-BEATS+GNNが「異常予兆を検出しました」と言っても、プロセスエンジニアの次の質問は「で、何が原因?」だ。GNNがセンサー間の依存関係グラフを構築したとして、そのグラフのエッジに物理的意味を付与できるのか。できなければ、アラートの度にエンジニアが手動で原因を追い込む必要があり、それは今と変わらない。

Proactive SPC論文は管理限界を超える前に対応できることを売りにするが、現場のプロセスエンジニアには別の懸念がある。SPCチャートは品質保証の監査対象であり、規格に沿った統計手法で管理されている。AIが予測したから装置を止めました——これは監査で説明できない。

プロセスエンジニアの思考回路:
  「このML、なんで異常って言ってるの?」
  → 説明できない → 信用できない → 使わない

MLエンジニアの思考回路:
  「AUC 0.99なのになんで使ってくれないの?」
  → 説明性を追加 → SHAP値を出す → 「SHAPのこの数字何?」
  → また説明できない → 振り出し

CdZnTe論文3が比較的マシなのは、出力がセグメンテーションマップ——つまり画像上のどこが欠陥かを可視化できるから。プロセスエンジニアは画像を見て物理的解釈ができる。GNNの抽象的なグラフ構造よりも、人間の判断プロセスに近い出力形式であることが、現場導入のハードルを下げる。


突破口: それでもMLが歩留まりに効く3つの条件

3つの壁を並べたが、全否定するつもりはない。以下の条件が揃えば、MLは歩留まり改善に実際に貢献できる。

条件1: 予測ではなく異常の絞り込みに使う

精度99%の分類器を不良/正常の最終判定に使うのではなく、検査対象の優先順位付けに使う。

# NG: 分類器として使う
if model.predict(wafer) == "defective":
    scrap(wafer)  # 誤判定リスク大

# OK: ランキングとして使う
risk_scores = model.predict_proba(wafers)
high_risk = wafers[risk_scores > threshold]
# high_risk だけを優先検査 → 全数検査より検査コストを削減

N-BEATS+GNN論文のアプローチはこの方向に近い。異常スコアの高い装置から優先的にメンテナンスするだけでも、ダウンタイムの削減効果は大きい。全自動化を目指さず、人間の意思決定を補助するツールに留める。

条件2: 可視化できる出力形式にする

CdZnTe論文のセグメンテーションが比較的受け入れられやすいのは、出力が画像だからだ。同じ発想で、異常検知の結果をダッシュボードに可視化し、プロセスエンジニアが直感的に理解できる形で提示する。

装置マッチング論文4の差分スコアも可視化との相性がいい。装置間の差異をヒートマップで表示すれば、A号機の温度制御がB号機より0.3℃ずれている——これを一目で把握できる。

条件3: プロセス変更に追従するMLOps基盤を先に作る

データの壁で書いたプロセス変更で振り出しに戻る問題は、継続的な再学習パイプラインで対処する。

装置データ → リアルタイムETL → 特徴量ストア
                                    ↓
                               モデルサービング ← 定期再学習(週次)
                                    ↓
                              異常スコアAPI → ダッシュボード
                                              → SPC連携

このMLOps基盤を先に構築して、その上でモデルを入れ替え可能にする。N-BEATSが良ければN-BEATS、Transformerが良ければTransformerに差し替える。モデルの精度よりも、データパイプラインの堅牢性のほうが投資対効果は高い。


個人スケールで歩留まりMLに触れる方法

「FABなんて持ってない」という読者向けに。

SECOM Dataset で始める

UCIリポジトリに公開されているSECOM Datasetは、実際の半導体製造ラインから収集されたセンサーデータだ。590特徴量、1567サンプル、二値分類(合格/不合格)。

import pandas as pd
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.model_selection import cross_val_score
from sklearn.impute import SimpleImputer
from sklearn.pipeline import Pipeline

# SECOM データ読み込み
data = pd.read_csv("secom.data", sep=r"\s+", header=None)
labels = pd.read_csv("secom_labels.data", sep=r"\s+", header=None)[0]

# 欠損値が多い(現実のFABデータと同じ)
print(f"欠損率: {data.isnull().sum().sum() / data.size * 100:.1f}%")
# → 約4.5% — 現場ではこれでもかなり綺麗なほう

pipe = Pipeline([
    ("imputer", SimpleImputer(strategy="median")),
    ("clf", GradientBoostingClassifier(n_estimators=200))
])

scores = cross_val_score(pipe, data, labels, cv=5, scoring="f1")
print(f"F1: {scores.mean():.3f} ± {scores.std():.3f}")
# → 精度は出る。だが現場で使えるかは別問題

このデータセットで経験できるのは、壁1の「精度のパラドックス」そのものだ。F1スコアはそこそこ出るが、precision/recallのトレードオフをどう設定すべきかは、製造プロセスの知識なしには判断できない。

RTX 4060 8GBでGNN異常検知を動かす

N-BEATS+GNN論文のアプローチをローカルで再現するなら、PyTorch Geometricが使える。SECOM Dataset程度のサイズなら、RTX 4060 8GBで十分動く。

import torch
from torch_geometric.nn import GCNConv
from torch_geometric.data import Data

class SensorGNN(torch.nn.Module):
    def __init__(self, num_features, hidden=64):
        super().__init__()
        self.conv1 = GCNConv(num_features, hidden)
        self.conv2 = GCNConv(hidden, 32)
        self.classifier = torch.nn.Linear(32, 2)

    def forward(self, data):
        x, edge_index = data.x, data.edge_index
        x = self.conv1(x, edge_index).relu()
        x = self.conv2(x, edge_index).relu()
        return self.classifier(x)

# センサー間の相関行列からグラフを構築
correlation = data.corr().abs()
threshold = 0.7
edges = (correlation > threshold).values
edge_index = torch.tensor(
    [[i, j] for i in range(edges.shape[0])
            for j in range(edges.shape[1]) if edges[i][j] and i != j],
    dtype=torch.long
).t()

# VRAM使用量: ~200MB(590ノード、相関グラフ)
# RTX 4060で学習可能なサイズ(590ノード程度のグラフ)

590個のセンサーをノードとし、相関の強いセンサー間にエッジを張る。このグラフ構造が、プロセスの物理的な依存関係を反映しているかどうかを確認するのが、個人レベルでの良い練習になる。


FAB記事との差分: 今回見えたこと

前回の記事では、FABにLLMを持ち込む広い視点で5本を読んだ。今回は歩留まり予測に絞って深掘りした結果、見えたことがある。

MLの半導体製造への導入は、モデルの問題ではなくインテグレーションの問題だということ。

N-BEATSもGNNもTransformerも、技術的には動く。精度も出る。だが動くことと使われることの間に、データパイプライン、可視化、説明性、組織の意思決定プロセスという巨大なギャップがある。

このギャップを埋めるのは、MLエンジニアでもプロセスエンジニアでもなく、両方の言語を話せる人間だ。半導体の物理とMLのアーキテクチャの両方を理解した上で、モデルの出力を現場のどの意思決定にどう接続するかを設計できる人間。

論文はモデルを提案する。現場は答えを求める。その間を埋める翻訳者が、今一番足りていない。


参照論文

  1. Sorensen, Dey, Hwang, Halder. "Unsupervised Anomaly Prediction with N-BEATS and Graph Neural Network in Multi-variate Semiconductor Process Time Series" (2025)
  2. Seeam. "Proactive Statistical Process Control Using AI: A Time Series Forecasting Approach for Semiconductor Manufacturing" (2025) [ArXivから取り下げ済み]
  3. Li, Fang, Liu et al. "Harnessing Group-Oriented Consistency Constraints for Semi-Supervised Semantic Segmentation in CdZnTe Semiconductors" (2025)
  4. Bharadwaja, Jandial, Agashe et al. "Tool-to-Tool Matching Analysis Based Difference Score Computation Methods for Semiconductor Manufacturing" (2025)
  5. Yen & Chen. "Semiconductor Industry Trend Prediction with Event Intervention Based on LSTM Model in Sentiment-Enhanced Time Series Data" (2025)
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?