半導体業界は現在、構造的な転換期を迎えています。ある業界分析が最近指摘したように、「半導体の性能向上の主な原動力は、プロセスノードの微細化から先進パッケージングへと移行した」のです。この変化は、設計や組立にとどまりません。それは、テストおよびテストによって生成されるデータに直接影響を及ぼしています。
モノリシックな世界では、テストの最適化は困難ではあったものの、その範囲は限定されていました。単一の統合ダイが検証され、データや意思決定の境界も比較的限定された範囲にとどまっていました。しかし、チップレットベースのアーキテクチャは、その限定性を打ち破ります。これにより、パッケージ内のコンポーネント数、プロセスステップ間の遷移数、そしてテスト情報を収集してそれに基づいて対応する機会の数が、それぞれ増大することになります。
その結果、核心となる問いが変わってきています。もはや、1つのフローがどれだけのテストデータを生成できるかということではありません。重要なのは、そのデータが分散型サプライチェーン全体を横断して、適切なタイミングで適切な場所に届き、実際の生産上の意思決定に活用できるかどうかです。これこそが、Data Feed Forward（DFF）が解決するために構築された課題なのです。
このブログ記事では、チップレットベースのパッケージングが従来のテストモデルを覆す理由、データ・フィード・フォワード（DFF）とは何か、そのアーキテクチャ、そして生産グレードのプラットフォーム上で構築されたDFFが、効率性、品質、パフォーマンスの面でどのように測定可能な価値をもたらすかについて解説します。
ここで、「上流」とは、ファブ工程やウェーハ選別などの初期段階の工程を指し、「下流」とは、パッケージテスト、最終テスト、システムレベルテスト（SLT）などの後工程を指します。
1. なぜチップレットはテストの課題を変えるのか？
チプレットベースのデバイスは、一度だけ検証されるわけではありません。複数のダイ、組み立ておよび統合の複数の段階、そして複数のテスト工程にわたって評価が行われます。現在、代表的なフローは、ファブ工程、PCM → ウェーハ選別 → 組み立ておよびボンディング → パッケージテスト → 最終テスト → バーンイン／SLT に及びます。各工程では有用な信号が得られますが、それらはすべて、上流工程での結果に基づく進展でもあります。
これに伴い、以下の2つの構造上の変更が行われます：
- ダイの数が増え、インターフェースも増える。各チップレットには独自のテスト要件があり、インターフェースが増えることで、故障モードとカバレッジ要件の両方が増大する。
- 相互に依存する決定。ウェーハ選別での結果は、パッケージテスト、最終テスト、あるいはSLTでの処理内容に直接影響を及ぼす可能性があります。修正されなかったエラーは、プロセス全体を通じて累積していきます。
従来の段階的なモデルでは、各挿入工程が独自のローカルデータに基づいて処理される傾向があるため、この問題への対応が不十分です。ウェーハ選別段階で重要な知見が得られたとしても、その知見を後工程で活用できる仕組みはほとんど存在しません。したがって、課題は単にデータ量が増えたということだけではありません。下流工程での効果的な意思決定において、上流工程のコンテキストをますます活用できるようになるべきであるにもかかわらず、現状ではそれがほとんど行われていないという点にあります。
2. なぜ分散型サプライチェーンこそが真の障壁となるのか？
より根本的な課題は構造的なものです。半導体の製造とテストは、設計会社→ウェハーファブ→OSAT/ATMP→最終OEM→現場というように、異なる工場、国、組織にまたがり、高度に分散しています。各拠点では、独自のデータスタックが運用されています。
原則として、ほとんどのチームは上流のデータに価値があることを理解しています。しかし実際には、下流で意思決定を行わなければならない時点で、そのデータが断片化されていたり、遅延していたり、あるいは単にアクセスできない状態にあることがよくあります。そうなると、エンジニアはより単純で孤立した意思決定モデルに頼らざるを得なくなり、その結果、次の3つの点が同時に悪化してしまいます：
- 下流のチームにはデバイスの完全な履歴が不足しているため、可視性が低下してしまう。
- 最終的な結果とそれ以前のテストサイクルとの関連付けが難しくなるため、トレーサビリティが低下する。
- エッジモデルは、実行されているその場ですぐに利用可能なデータしか参照できないため、AI/MLの導入には制約があります。
したがって、適応型テスト、最適化、あるいは高度なモデリングが価値を生み出す前に、より基本的な運用上の課題に答えを出す必要があります。それは、分散したサプライチェーン全体において、適切なデータを適切な場所に、適切なタイミングで届けるにはどうすればよいか、ということです。
3. データ・フィード・フォワード（DFF）とは何か？
その問いに対する答えが「データ・フィード・フォワード（DFF）」であり、その最大の違いはここにあります。DFFはストレージの概念ではなく、運用上の概念です。その目的は、後の分析のためにデータを保存することではありません。その目的は、上流のデータを、下流でのリアルタイムな意思決定に役立てることにあります。
実際には、ウェーハ選別などの初期工程での結果は、後続の工程で処理可能な形式に変換されます。具体的には、設計上の特徴、推定されたデバイス属性、モデル予測、品質指標、あるいは配線推奨事項などです。これらの出力結果は、遠隔地の施設や外部サプライチェーンの拠点にある下流工程へと送られます。
これにより、上流のテスト結果を下流のプロセスインテリジェンスへと転換し、本来なら断絶していた各段階の間に連続性が生まれます。この連続性が確立されれば、はるかに高度で適応性の高いテスト手法が可能になります。
4. データフィードフォワードアーキテクチャはどのように構成されているか？
DFFのベストプラクティスに基づく導入は、生データから閉ループ型インテリジェンスへと至る5つの運用層として理解することができます：
- 収集。ウェーハソート、プローブ、および初期テストの各段階から、パラメトリックデータ、検査結果、ビニングデータ、波形シグネチャ、およびプロセスコンテキストなどのデータを取得する。
- 変換。特徴量エンジニアリング、ルール生成、モデル推論、あるいは決定閾値を通じて、生データを実用的な形に変換します。生データは通常、容量が大きすぎたり構造化されていなかったりするため、下流工程で直接利用することは困難です。そのため、この層はオプションではなく、不可欠なものです。
- 転送。変換された出力を、拠点間やパートナー間で安全に転送します。分散環境においては、信頼性が高く安全な転送が必須要件となります。
- 適用する。出力結果を下流の処理に反映させ、具体的なアクションを促進する。具体的には、よりスマートなスクリーニング、適応型閾値設定、トリム目標値の予測、ルーティング、あるいはテストスイートの選択などである。実際には、これは「ビン分け」「スキップ」「調整」「フラグ設定」といった判断に帰着する。
- 結果を記録してください。システムが追跡可能であり、継続的に改善できるよう、結果を記録します。そうすることで、予測値と実際の結果を比較し、それに基づいてアルゴリズムを改良し、モデルを再学習させることができます。
その最終的な閉ループこそが、DFFの拡張性と運用上の意義を生み出している。インテリジェンスは一度だけ適用されるのではなく、システムが学習していくのだ。
5. DFFを実運用可能な状態にするには、どのようなインフラが必要か？
フレームワークには、データの移動とモデルのデプロイの両方において、本番環境レベルの基盤インフラが必要です。DFFを実現する2つの機能は以下の通りです：
- Exensio Test Operationsは、安全なデータ収集、データ管理、プロセス監視、品質管理、エッジ展開、およびサプライチェーンとの連携を扱います。通常、試験装置と直接連携するため、最高精度かつ最もタイムリーな試験データを取得でき、ルールを適用してプロセスを監視し、データ品質を損なう可能性のある逸脱を検知することができます。
- Exensio StudioAIは、機械学習のライフサイクル全体（モデルの構築、学習、展開、ガバナンス）にわたる包括的なモデル運用（ModelOps）機能を備えており、オープンソースのアルゴリズムの利用や自社開発アルゴリズムの導入も可能です。Exensio システムにすでに存在する、整合性が取れて信頼性の高い製造データを活用するため、データサイエンティストはデータの収集や展開パスの設計に時間を割くことなく、モデリング作業に集中することができます。
インテルのある顧客が指摘したように、StudioAI を使えば、データサイエンティストはオープンソースやカスタムアルゴリズムを活用でき、継続的インテグレーションとデプロイメントもサポートされるため、チームは実際に必要なソリューションを構築することができます。この 2 つの製品を組み合わせることで、DFF は単なるアイデアから、エッジ環境での実運用へと発展します。
6. DFFはどこで価値を生み出すのか？
その見返りは3つのカテゴリーにまたがっています。
効率性。下流工程でのテストの多くは、上流工程で得られた知見を下流工程では把握できないため、一律の対応を余儀なくされ、保守的な設計となる。その知見を確実に前工程に反映させれば、デバイスごとに適切なテストカバレッジを設定できるようになる。 よく引用される例として、選択的なバーンイン回避が挙げられます。予測の信頼性が高く、プロセスが適切に管理されている場合、予測上良好なデバイスは不要なストレス工程をスキップできます。これにより、製品目標を維持しつつ時間とコストを削減し、早期故障のリスクが実際に高いデバイス向けにバーンインのキャパシティを解放できます。リスクのない手法としては、Vminなどの特性検索範囲を、上流工程ですでに特定された境界値に絞り込むことが挙げられます。これにより、リスクを追加することなくテスト時間を短縮できます。 ここでの効率化とは、単にコストを削減することではなく、適切なデバイスに対して適切なタイミングで適切なテストを実行することにあります。
品質。これは効率性以上に重要であるかもしれません。各工程の実行前にトリム目標値を予測することで、トリム誤差を減らすことができます。これは、上流の情報が下流の作業を直接改善する典型的な例です。挿入箇所やサイト全体にわたる特性信号を監視することで、ドリフトを早期に検出できます。これにより、テストの不安定性を指摘できるほか、さらに深刻なケースでは、早期劣化やストレスによるデバイスの変化を検知し、長期的な信頼性リスクを指摘することが可能です。施設やパートナー間で閾値を統一することで、より一貫性のある結果が得られ、上流でのスクリーニング精度を高めることで、不良品の流出を防ぐことができます。 より広い視点で見れば、全体的な品質は単一のテスト結果ではなく、サプライチェーン全体の特性であり、DFFこそがこれをエンドツーエンドで対処可能にし、品質管理を事後対応型から予測型へと転換させるものです。
パフォーマンス。ここが、DFFがAI駆動型の手法と最も直接的に結びつく部分であり、ここでいう「パフォーマンス」とは、単にデバイスの処理速度が速いということではなく、より高性能な意思決定を意味します。最先端のインラインモデルは、多くの場合、直近のステップのデータしか把握できないため、その能力に制限があります。ウェーハ選別時のシグネチャとパッケージレベルの観測結果を組み合わせたり、プロセス履歴とテスト測定値を統合したりして、上流工程や過去のコンテキストをモデルに組み込むことで、予測の精度が向上し、コンテキストをより適切に反映できるようになります。 これにより、高価な先進パッケージに対するよりスマートな格付けとルーティングが可能になります。こうしたパッケージは、そのコストの性質上、単純に廃棄することはできず、特性評価を行い、適切な用途に合わせて格付けする必要があります。SLTにもメリットがあります。フィードフォワードされたデータにより、SLTスイートを特定のデバイス機能に動的に絞り込むことができるのです。同様の論理はアセンブリの最適化にも適用され、サブコンポーネントの性能をターゲットアプリケーションに適合させることで、完成品のコストパフォーマンスを最大化します。
7. 主なポイントは何か？
- チップレットベースのパッケージングには、サプライチェーン全体にわたるデータの連携が不可欠です。データに関する課題は、もはや単一の組み込み工程に限定されたものではありません。
- DFFは、AIを活用した大規模テストの運用上の基盤です。これにより、上流の情報が下流の意思決定支援へとつながる道筋が築かれます。
- 真の価値は、上流のデータを下流で活用できるようにすることから生まれ、そのメリットは効率性、品質、パフォーマンスのあらゆる面に及びます。
- データの移動は、試験測定と同じくらい重要になりつつあります。高度なパッケージングの時代において、競争優位性は、どれだけ多くのデータを収集できるかではなく、得られた知見をいかに効果的に前線に伝え、重要な場面で活用できるかにますます左右されるようになっています。
これは、結局のところ、生産のプロセスに沿った形で、データの蓄積からデータの活用への転換である。
参考文献
- Exensio Analytics Platform：概要
- Exensio アドバンスト・テスト・ソリューション
- Exensio StudioAI
- EE Times ウェビナー：2026年に向けたチップレットのスケーラビリティへの道――AIを活用したデータフィードフォワード