シリコンファブ検査パイプライン

弊社のクライアントは日本国内（今里・久原）に3か所のシリコン製造サイトを運営する大手半導体メーカーです。先端電子機器に使用される高精度ウェーハ基板を製造しており、すべての生産段階を統括する厳格な品質規程のもとで運営されています。3サイト合計で月間数万件のウェーハ検査が処理されており、品質レビュープロセスにおけるわずかな不一致でも廃棄、手直し、または下流の歩留まり損失に直結します。

10年以上にわたって構築された成熟したIBM DB2 MES環境である同社の製造実行システムは、ファブの運営の根幹でした。すべてのロット、サブロット、ウェーハをすべての生産段階にわたって追跡していました。安定しており、よく理解され、あらゆることの中心にありましたが、それが同時に制約でもありました。新しい機能はこのシステムに統合するのではなく、その周囲で機能しなければなりませんでした。

DSPキャリアスクラッチ検査ステップは、ファブの生産フローにおける重要な分岐点に位置しています。このチェックポイントを誤って通過するウェーハ（エラーで承認された真の欠陥品、または不必要に保留された良品）はどちらの方向でもコストをもたらします。偽陰性は欠陥品が次の段階に進むことを意味し、偽陽性は歩留まり損失と生産遅延を意味します。

3サイトにわたって検査量が増加するにつれ、手動レビュープロセスは目に見えるボトルネックになっていきました。品質保留を処理するチームは最終判定に責任を持つ同じチームであり、ピーク時にはキューが滞積していました。経営陣はヘッドカウントを増やさずにスループットを改善することにコミットしており、手動レビュープロセスが最も明確な改善機会でした。

以前から自動化についての議論はありましたが、MESチームからの標準的な回答は常に同じでした。検査ワークフローへのあらゆる変更は、ダウンタイムを許容できないシステムでの稼働中の生産を中断させるリスクがあるというものでした。課題は自動化する意志の欠如ではなく、MESにまったく触れることなく実現するアプローチを見つけることでした。

大規模での手動検査

DSP検査ステージに入るすべてのロットで、作業員は検査記録を開き、最大25スロットのウェーハグリッドをナビゲートし、各ウェーハの画像セット（通常は異なる焦点面にわたって1ウェーハあたり4〜6枚）をレビューする必要がありました。このレビューには、許容可能な表面変化と真のスクラッチ欠陥を区別するための訓練された判断力が求められました。3サイト合計で1日数百ロットにわたり、このプロセスは1ロットあたり約45分の作業員時間を消費していました。

システムレベルの一貫性の欠如

3つのファブサイトは共通の最終判定ロジックを持たない個別の検査ワークフローで運営されていました。今里で行われた欠陥分類の決定は久原のQCチームには見えませんでした。時間とともに、保留率と欠陥コード使用のサイト間のばらつきは、品質監査で目に見えるほど大きくなりましたが、すべてがMES内に存在するため、MESプロジェクト全体なしに標準化する実用的な方法はありませんでした。

トレーサビリティの欠如

最終判定の決定はMESに記録されていましたが、記録には結果（承認、保留、またはエスカレーション）のみが含まれ、理由、レビューされた画像、または決定を下した作業員の識別情報は含まれていませんでした。最終判定後に品質問題がエスカレーションされた場合、調査はゼロから開始しなければなりませんでした。「誰が何を見て、何を決定したか」という質問に答えられる監査証跡は存在しませんでした。

“

「オペレーターはAIやデータベースに触れません — ロット、ウェーハ、画像を見て、承認ボタンを押すだけです。」

原則：置き換えるのではなく、拡張する

決定的な制約は、既存のMES（IBM DB2、SONAR検査ツール、NASファイルストア、ロット/ウェーハ/保留ワークフロー）を再構築できないことでした。アーリャ・グローバルはソリューション全体を非侵襲型の層として設計しました。MESは既存のDB2ビュー（DOPEHIS、DLOT、DSUBLOT、DWAFER）から読み取られ、AIパイプライン、ステージングデータベース、オペレーターUIはすべてMESの傍らに配置され、内側ではありません。構築と展開の全期間を通じて本番稼働は継続されました。

5ステージパイプライン

• 01ETL取り込み — .NET 8バックグラウンドワーカーが定期的にDB2 MESをポーリングし、チェックポイントマーカーとPollyベースのリトライロジックを使用して差分変更を取得します。新規ロットとウェーハレコードは、パイプライン全体の中央ステートハブとして機能するOracleデータベースにステージングされます。
• 02SONAR統合 — 検査画像はXMLテンプレートとCSV取り込みを介してYDC SONARから取得されます。ワーカーは画像パスをロットメタデータと共にOracleにシリアライズしてステージングし、AI推論ステップの準備を整えます。
• 03AI推論 — 専用NVIDIA H100 GPU上で動作するPythonワーカーがステージングされたロットを取得し、CUDA加速を使ったONNX Runtimeで実行されるONNX形式にエクスポートされたYOLOv8モデルにウェーハ画像を通します。推論後のビジネスロジックが欠陥クラスゲーティング、最小面積閾値、端面オーバーラップマスキングを適用してから結果をOracleに書き戻します。ワーカーはPodmanでコンテナ化され、cronスタイルのバックグラウンドプロセスとして継続的に実行されます。
• 04手動QC — AIがHOLDまたはNGとマークしたロットは人的レビューのためオペレーターUIに表示されます。約70%のロットはオペレーターの介入なしにAIでクリアされます。QCステップは人的判断が適用される場所ですが、それは本当に必要な場合のみです。
• 05最終判定とレポート — 承認されたロットはOracleステージング層を通じて書き戻されます。すべての決定（AI結果、オペレーターによるオーバーライド、欠陥コード、タイムスタンプ、ユーザーID、ファブサイト）が記録されます。QCリーダーは完全な最終判定ログをExcelにエクスポートでき、管理者はサイトごとのリアルタイム稼働/停止ステータスとキュー深度を示すダッシュボードを持っています。

なぜクラウドではなくオンプレミスGPU推論なのか

これはコストの決定ではなく、データ主権の決定でした。半導体ファブは厳格な情報セキュリティ要件のもとで運営されています。ウェーハ画像とMESロットデータは独自の製造インテリジェンスとして扱われます。それらをクラウド推論APIに送信することはクライアントが検討する選択肢ではありませんでした。H100はファブネットワーク内に設置されており、推論結果がそこから出ることはありません。

オンプレミスモデルはまた、クラウド推論が引き起こすSLA依存性も排除しました。検査は生産にとって重要なステップです。チームはファブが稼働しているときにAIが利用可能であることを必要とし、その可用性はサードパーティのアップタイム保証ではなく、ローカルインフラによって管理される必要がありました。

オペレーターインターフェース

WinForms UIは一つの目的のために構築されました。作業員が手順上のミスを犯すことを不可能にするためです。役割ベースのアクセス（オペレーター、QC、管理者）により、各担当者は自分の業務に関連する画面のみを見ることができます。ロットツリーはフォルダ階層のようにナビゲートします。ウェーハグリッドはAI結果（OK、HOLD、またはNG）が事前入力された状態で25スロットを一目で表示し、画像サムネイルはクリックでNASから読み込まれます。

バリデーションはすべての重要なアクションに組み込まれています。作業員は欠陥コードを選択せずにNGを保存することができません。AI結果は文書化された理由なしにOKにオーバーライドすることができません。これらのガードレールは作業員を遅らせるためではなく、追跡不可能な品質問題を生み出すエラーのクラスを排除するために設計されました。

複数ファブへの展開

3つのサイト（今里2、久原1、久原2）はすべて、サイトごとの設定ファイルを持つ単一のコードベースから運行されています。サイトレベルのデータ分離はOracleで実施されており、久原1のレコードが今里2のキューに表示されることはありません。同じAIモデルとビジネスルールが3つのサイト全体に適用され、これにより品質チームは初めて業務全体で一貫した欠陥分類基準を持つことができました。

導入前と導入後

手動レビュー時間

Before1ロットあたり約45分

→

After約12分（73%削減）

AI自動化率

約70%のロットが作業員の介入なしにクリア

サイト間の一貫性

3ファブすべてで単一の欠陥分類基準

トレーサビリティ

Before監査証跡ゼロ

→

After100% — すべての決定をユーザー、タイムスタンプ、サイトとともに記録

クラウド・外部依存

完全に排除 — すべての推論とデータはファブネットワーク内に留まる

オペレーター研修

新人オペレーターは1シフトで習熟。CLIやデータベースアクセスは不要

MESへの影響

なし — 構築と展開の全期間を通じて生産は中断なく稼働

当初の要件を超えた成果

サイト間の一貫性効果は当初のプロジェクトスコープに含まれていませんでした。これは3つのファブ全体でAIモデルとビジネスルールを標準化した副産物として生まれました。品質チームは、長らく未解決の問題であったサイト間の保留率のばらつきが、3つのサイトすべてが同じ推論ロジックを実行するようになると自然に解消されたと指摘しました。

トレーサビリティの改善は最終判定後の調査ワークフローにも価値をもたらしました。完全な監査証跡が利用可能になったことで、以前は作業員へのインタビューと記憶からの決定の再構築を必要としていた品質調査が、Oracleログから数分で完了できるようになりました。

3つのファブサイト全体への展開後、アーリャ・グローバルはサポートと継続的改善の立場で引き続き関与しています。モデル再学習のスケジュール、新しい欠陥パターンが識別された際のビジネスルールの改善、追加のレポート機能が次フェーズのスコープに含まれています。再利用可能なパイプラインアーキテクチャ（ETL、AIワーカー、Oracleステートマシン、オペレーターUI）は、生産フローの他の検査ポイントへの適用についても評価中です。

再利用可能な機能

このエンゲージメントのために構築されたアーキテクチャ（非侵襲型MES統合、オンプレミスGPU AI、ガードレール付き人間参加型QC、単一コードベースからの複数サイト展開）は、レガシーMESインフラを運用してシステム全体の再構築なしにAI強化の品質管理を必要とする他のファブや製造環境に直接再利用可能です。

レガシーMESでの検査自動化、エアギャップまたは管理された環境でのAI展開、複数の生産サイトにわたる品質決定の標準化など、同様の課題に直面している場合、私たちのアプローチと同様のモデルが貴社の状況に適用できるかどうかを喜んでご共有いたします。