はじめに
東京エレクトロンデバイス様主催の Microsoft Agent Hackathon に、Data Impact の Delivery Team として参加させていただきました。(https://zenn.dev/hackathons/microsoft-agent-hackathon-2026)
本記事では、私たちが提案したソリューション 「越見波（エツミナミ）エージェント」 について、課題背景からアーキテクチャ、AIモデルの設計、エージェント層の実装まで、技術的な観点で詳しくご紹介します。
チーム紹介
会社について
Data Impact Joint Stock Company は、データを起点に企業の意思決定とDXを支援するベトナム拠点のテクノロジー企業です。株式会社ヘッドウォータースの子会社です。
Microsoft Solutions Partner として、Azure / Databricks / NVIDIA Omniverse / Snowflake などのクラウド・データ基盤上で、AI・データ分析・IoTを組み合わせたソリューション開発を行っています。
メンバー
今回のハッカソンには、Delivery Team から以下の4名で参加しました。
- Nguyen Quang Huy ― データサイエンティスト（AI / Azure / GCP）
- Le Minh Triet ― AIエンジニア（バックエンド / 数理モデル得意）
- Nguyen Duc Long ― データエンジニア（Databricks / Multi-language）
- Le Quang Huy ― クラウドインフラエンジニア（Azure / Network）
データサイエンス、AIモデリング、データ基盤、クラウドインフラと、エンドツーエンドで設計・実装できる構成のチームでハッカソンに臨みました。
課題提起：半導体における設備異常検知
私たちが取り組んだのは、半導体製造における装置の異常検知 という現場課題です。
半導体工場では、装置1台が停止すると 1分あたり数万〜数十万ドル の損失が発生し、年間では数億円規模の機会損失につながります。にもかかわらず、現場では今なお以下のような課題が残っています。
業界レポート（McKinsey, Deloitte 等）では、突発故障に起因するダウンタイム比率や、予知保全により削減可能な保全コストが大きいことが示されており、「閾値監視からAIによる予知保全へ」 のシフトが強く求められています。
ソリューション概要：越見波エージェント
ソリューション名 「越見波（エツミナミ）」 には、
データの波を越え、故障の先を見通す
という意味を込めました。膨大なセンサーデータの「波」を越えて、装置の異常を早期に検知し、自律的に対応する保全エージェントを目指しています。
ソリューションは Detect → Diagnose → Act の3ステップで構成されています。
1. DETECT（異常予兆検知）
Transformerモデルによるセンサーデータのリアルタイム異常検出。閾値ベースでは見落とす微細な劣化パターンも捕捉します。
2. DIAGNOSE（自律判断・診断）
Azure OpenAI ベースのエージェントが異常原因を自動分析。RAGで過去の保全ナレッジを参照し、根本原因を特定します。
3. ACT（自動アクション）
作業指示の自動生成、Teams通知、スペアパーツ手配提案までを自動化。エンジニアは確認・承認するだけで対応が完了します。
このサイクルを自動化することで、保全エンジニアの意思決定を強力に支援するのが越見波エージェントです。
ソリューションアーキテクチャ
ソリューション全体は エッジ層 → データ層 → AI層 → エージェント層 の4階層で構成しています。
| 層 | 主要コンポーネント | 役割 |
|---|---|---|
| エッジ層 | IoT Sensors → Azure IoT Hub → Data Ingestion | 装置センサーからリアルタイムでデータ収集 |
| データ層 | Databricks → Medallion Architecture → Feature Store | Streaming処理、特徴量生成、データレイク管理 |
| AI層 | Transformer Model → Azure OpenAI (Agent) | 異常検知推論 & LLMエージェント診断 |
| エージェント層 | Teams通知 → 作業指示書生成 → HITL承認フロー | 自動アクション実行、Human-in-the-Loop |
主な利用技術スタックは以下の通りです。
- Azure IoT Hub ― センサーデータ取り込み
- Databricks ― データ基盤・MLパイプライン
- Azure OpenAI / Semantic Kernel ― エージェント実装
- Cosmos DB ― ナレッジ・ベクトル検索
- Azure Functions ― イベント駆動処理
- Teams / Copilot Studio ― エンジニアとのインターフェース
エッジ層：センサーデータ
データソースは、半導体製造ロボットのリアルタイムセンサー（温度・圧力など） です。
AIによりセンサーのデータを予測で生成して、生成したデータとセンサーからのデータを合わせて比較する。実際のデータは予測のデータと大きく違うとエラーと判定する。
データ仕様
- 1サンプル = 1ウィンドウ
- メタデータ：ロボットコード、プログラム番号、開始時刻、ウィンドウ通し番号
- センサー行列：6 × 32（6チャネル × 32時系列ステップ）
- ラベルなしデータ → 教師なし学習（Unsupervised Learning） を採用
ラベル付け工数を抑えつつ、装置の「正常状態」を学習させ、そこからの逸脱を異常として検出するアプローチを採用しています。
データ層：Databricks 上のデータ基盤
なぜ Databricks か
データ基盤として Databricks を選定した理由は2点です。
強力なエコシステム
Databricks はビッグデータの処理とライフサイクル全体の管理を行う強力なプラットフォームで、AI 向けのデータ準備・供給を効率的にサポートします。
オールインワン統合
データ取り込みから AI 推論まで、本ソリューションのほぼ全コンポーネントを単一プラットフォーム上で展開・管理できる点が大きなメリットです。
インフラ全体構成
Microsoft Azureにデモのインフラを構築しました。
Ingestion & Streaming 処理
Ingestion 層
- 技術：Azure Databricks Volumes API によるデータ取り込み自動化
- 課題：一部ファイルが約 10GB と大容量で、直接アップロードの制限を超過
- 解決策：Automated Chunking（自動分割） と Timeout 強化 で安定的な取り込みを実現
Streaming & Medallion Architecture
Spark Structured Streaming ベースのリアルタイム処理を採用し、以下を実装しています。
- 重複排除（Deduplication）
- 遅延データ処理（Late-arriving data）
- スキーマ自動進化（Schema Evolution）
- チェックポイント管理（Checkpointing）
データは Bronze → Silver → Gold のメダリオンアーキテクチャで段階的に整備し、AIモデル推論に適した形に変換していきます。Window Functions による Sliding Window Aggregation で、複雑な配列・行列データの処理にも対応しています。
Databricks データベース構成
以下のアーキテクチャの通りにデータ処理基盤をDatabricksで構築しました。（ダミーデータを利用するアーキテクチャ）
実際の案件にソリューションを適用する際のアーキテクチャ
AI層：モデル設計
- 教師なし学習で「正常」状態を学習し、正常パターンからの逸脱を異常として検出
-
メリット：
- 全ロボット・プログラムへ汎用適用が可能
- ラベルなしデータで学習可能
- 新規装置にも自動適応
- 微細な劣化も高精度で検出
ベースモデルは段階的に改善を加え、最終的に Transformer 構造 へと到達しました。
AIモデル全体アーキテクチャ。
最終的に採用したアーキテクチャは GLC-MAE V9（Asymmetric MAE with LogScaler + GlobalSeqNorm） です。Masked Autoencoder の考え方を時系列センサーデータに適用し、「正常パターン」を教師なしで学習します。
入力は [B, C=3, T=256] のマクロウィンドウで、robot_idx / program_idx を文脈として与えることで装置間の個体差を吸収。前処理は LogScaler（符号保持の対数スケーリング）と GlobalSeqNorm（BatchNorm1d + EMA） を採用し、熱ドリフトを保ったまま正規化できる点がポイントです。Tokenizer は学習・推論で完全共有し、Train/Serve Skew を排除しています。
学習時は 45% のトークンをマスク し、エンコーダは可視トークンのみを処理する Asymmetric 構造で計算量を削減。損失はマスク位置のみで MSE を計算します。推論時はマスクなしで全トークンを通し、トークン単位の再構成誤差を [B, C, P] のヒートマップに整形して MAD ベースの閾値 で異常判定。スカラスコアに加えてヒートマップを返すことで、エージェント層がどのセンサーのどの区間で異常が出たかを直接参照できる設計です。
AI層：推論フロー
学習時の運用時の 推論（Inference）フロー は対称に設計しています。
- 入力：新規ロボットデータ（6 sensors）
- 窓分割：同一パラメータで分割
- 再構成：学習済みモデルで再構成し、Reconstruction Error を算出
- 結合：Gaussian Stitching を適用
- 検出：各 step のエラーを閾値と比較し、超過した場合は 異常 と判定
学習時と推論時で同じ前処理・後処理を通すことで、Train/Serve Skew を最小化しています。
検出精度
- F1 ≈ 0.95
残課題
- グローバル異常（局所的ではなく時系列全体に広がるドリフト等）の検出精度向上は引き続きの改善テーマです。
設計の核心：2層を分離する
設計において特に意識したのは、信号異常と製品（溶接）欠陥を別々の層として扱うことです。
Layer 1 — Signal Layer： 溶接センサーの信号レベル（ワイヤ送給速度、ワイヤ温度、溶接電流）で検出される異常。
Layer 2 — Weld Quality Layer： 実際の溶接欠陥は、エージェントが能動的に品質検証ステップを実行して初めて判明します — スパッタ、コールドジョイント（融合不良）、ブローホール（気孔）、熱影響部（HAZ）の割れといったリスクを評価します。
誤検知を減らす鍵：Layer 2 の検証ステップは条件付きです — Layer 1 の診断が十分に高い深刻度を確認し、かつ異常グループが実際の欠陥を引き起こす可能性がある場合に限り実行されます。
エージェント層：信号異常 → 製品影響 監視
以下はAI Agentのアーキテクチャになります。
最終層は Azure OpenAI + Semantic Kernel で構築した 自律型エージェント です。AI 層が検出した異常を起点に、原因の診断・作業指示の生成・Teams への通知・HITL（Human-in-the-Loop）承認までを自動で実行します。
スキルベースの診断フロー
エージェントは自由に診断するのではなく、先に計画し、後で実行するという原則に従って動作します。最初の必須ステップはタスクのロードマップを作成することであり、その後にようやく各ステップを順番に実行します。
診断スキルは、適切なタイミングで適切な業務に応じてロードされます：
| スキル | 使用するタイミング |
|---|---|
| 計画立案 | 各インシデントの冒頭で、実施すべきステップのロードマップを構築する |
| 診断 | センサーデータを分析し、保守履歴を参照し、根本原因を特定する |
| 溶接品質の検証 | 診断後、実際の欠陥リスクを評価する（Layer 2） |
| FMEA 照合 | 最終的なアクションを提案する前に、故障モード解析データベースとクロスチェックする |
| 履歴照合 | 過去の類似インシデントや保守記録を参照する |
ダッシュボードの主な指標
- 本日の信号異常： 件数と前日比、異常グループ別の内訳
- 溶接リスク確定済み： Layer 2 の検証を経て高リスクと判定されたインシデント数
- 承認待ち： オペレーターの確認を待っているアクション数
- アクティブ・セッション： 同時に実行中の分析ケース数
- 分析の深さ： 1インシデントあたりエージェントが使用したスキルの平均数
イベントキューと運用フロー
各信号異常は、以下の処理フローを通過します。
- 一次振り分け： 低レベルのノイズは自動で解決し、しきい値を満たすインシデントは診断キューへ投入する
- 計画立案： 分析を開始する前に、エージェントがタスクのロードマップを構築する
- 診断： 主要センサーの特定、履歴の参照、原因の絞り込み、深刻度の評価
- 品質検証（必要に応じて）： 実際の溶接欠陥リスクを評価する
- 承認待ち： 高リスクなアクションを実行する前に、エージェントは停止してオペレーターの確認を待つ
-
完了： 計画内の全タスクが完了 → 診断結論を確定する
このように、エージェントは自動で済むところは自動化し、判断が必要なところは人が承認するというバランスの取れた設計になっています。
デモ動画
まとめ
本記事では、Microsoft Agent Hackathon 向けに Data Impact Delivery Team が開発した 越見波（エツミナミ）エージェント をご紹介しました。
ポイントを振り返ると、
- 課題：半導体工場の閾値ベース監視の限界と、保全エンジニアの属人化
- アプローチ：Detect → Diagnose → Act の自律型エージェントサイクル
- データ基盤：Databricks + Medallion Architecture によるストリーミング処理
- AIモデル：Transformer による教師なし異常検知（F1 ≈ 0.95）と Gaussian Stitching
- エージェント：Azure OpenAI + Semantic Kernel による Signal / Product の2層分離設計と HITL フロー
「データの波を越え、故障の先を見通す」という越見波の名の通り、現場のエンジニアを支える自律型 AI 保全エージェントとして、引き続き精度と運用性の向上に取り組んでいきます。
最後までお読みいただきありがとうございました 🙌
Discussion