<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel>
<title>MFG-AI データ基盤・MES連携</title>
<link>https://mfg-ai.com/</link>
<atom:link href="https://mfg-ai.com/data/feed.xml" rel="self" type="application/rss+xml"/>
<description>製造業のAI活用（外観検査・予知保全・需要予測・生成AI・フィジカルAI）を、導入の判断に必要な粒度で届ける専門メディア。欧米・中国の一次情報、製品・サービス比較データベース、導入事例データベース、日英中の用語集を収録。MESとデータ基盤の実装経験を持つ実務者が書いています。</description>
<language>ja</language>
<lastBuildDate>Sun, 11 Oct 2026 15:00:00 GMT</lastBuildDate>
<item>
  <title>アセット管理シェル（AAS）とは：IEC 63278と製造業のデジタルツイン連携</title>
  <link>https://mfg-ai.com/data/aas-asset-administration-shell</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/aas-asset-administration-shell</guid>
  <description>アセット管理シェル（AAS）は、設備や製品などの資産をサブモデルの集まりとして標準的に表す仕組みで、IEC 63278-1（2023年12月）で国際規格になりました。装置メーカーとのデータ受け渡しや、製品単位のデータ提出に備える基盤として効きます。</description>
  <content:encoded><![CDATA[<p>ドイツのインダストリー4.0から生まれたアセット管理シェル（AAS）は、日本では名前は知られていても、自社の工場で何に使うのかが見えにくい技術です。この記事では、AASの構造、OPC UAやMESとの役割の違い、日本の製造業が使いどころを判断するための基準を示します。</p><p>アセット管理シェル（Asset Administration Shell、AAS）は、設備・部品・製品といった資産（アセット）の情報を、決まった構造でデジタルに表すための仕組みです。Industrial Digital Twin Association（IDTA）の仕様では、AASを「資産の標準化されたデジタル表現」と位置付けています。</p><p>AASの構造は、次の3つの考え方でできています。</p><p>規格としては、IEC 63278-1 Ed.1.0（2023年12月、IEC TC65）がAASの構造を定める国際規格として発行されています。</p><p><a href="https://mfg-ai.com/data/aas-asset-administration-shell">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>デジタルツイン</category>
  <category>欧米動向</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>検査記録のAI-OCR：手書きチェックシートの読取精度と運用の注意点5つ</title>
  <link>https://mfg-ai.com/data/ai-ocr-inspection-records</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/ai-ocr-inspection-records</guid>
  <description>手書きの検査記録をAI-OCRで読む場合、数値の誤読は品質記録の改ざんと同じリスクになります。評価は文字単位の認識率ではなく「項目単位で修正が要らない率」で行い、信頼度による確認フロー・原本保管・修正履歴の5つの運用を決めてから使います。</description>
  <content:encoded><![CDATA[<p>手書きのチェックシートをAI-OCRで読み取れば入力の手間は減りますが、検査記録は品質保証の証拠でもあります。この記事では、検査記録にAI-OCRを使うときの精度の測り方と、誤読を品質事故にしないための運用上の注意点5つを示します。</p><p>AI-OCR（AIを使った文字認識）を経理の請求書処理で使う場合、誤読は後工程の照合で見つかることが多く、影響も金額の修正で済みます。検査記録は事情が違います。外径の測定値「12.38」を「12.88」と読めば、合格品が規格外として記録され、逆の誤読なら不合格品が合格の記録になります。後者は、結果として品質記録の改ざんと区別できない状態を作ります。</p><p>検査記録にAI-OCRを使うときの前提は次のとおりです。</p><p>紙の帳票全体をどう減らしていくかは紙の帳票から脱却する3段階で扱っています。ここでは、紙が残る期間にAI-OCRを安全に使う方法に絞ります。</p><p><a href="https://mfg-ai.com/data/ai-ocr-inspection-records">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>品質管理</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>AIの推論結果をMESに書き戻す：ホールド・作業指示・アンドンにつなぐ3つの設計</title>
  <link>https://mfg-ai.com/data/ai-result-writeback-mes</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/ai-result-writeback-mes</guid>
  <description>AIの判定を画面で見るだけでは工程は変わりません。MESのロットホールド、再検査・作業指示、アンドン表示の3つに推論結果をつなぐ設計パターンと、書き戻すデータ項目、誤判定時の解除手順、モデル版数の記録方法を実装の観点から示します。</description>
  <content:encoded><![CDATA[<p>外観検査や品質予測のAIが本番で使われ続けるかは、結果が業務の動きに変わるかで決まります。この記事では、AIの推論結果をMESに書き戻す3つの設計（ロットホールド、作業指示、アンドン）と、それぞれで決めておくべき項目を示します。</p><p>PoCの成果物は、多くの場合ダッシュボードです。不良の予兆や異常スコアがグラフで表示され、担当者が見て判断します。ところが本番では、担当者が常に画面を見ているわけではなく、見たとしても「このロットを止めるか」を判断する権限や手順がなければ、何も変わりません。結果として、AIが不良を予測しても、そのロットは後工程に流れていきます。</p><p>AIの判定を工程に効かせるには、結果を業務の仕組みに戻す必要があります。工場でその仕組みを持っているのがMESです。</p><p><a href="https://mfg-ai.com/data/ai-result-writeback-mes">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>MES連携</category>
  <category>データ基盤</category>
  <category>品質管理</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>AWS IoT SiteWiseとは：設備データのモデル化と生成AI保全アシスタントの構成</title>
  <link>https://mfg-ai.com/data/aws-iot-sitewise</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/aws-iot-sitewise</guid>
  <description>AWS IoT SiteWiseは、設備データを収集し、設備の型と階層でモデル化するAWSのサービスです。AWSがHannover Messe 2024で示したBedrockとの組合せによる保全アシスタントの構成を軸に、アセットモデル設計の考え方と導入前の確認点を整理します。</description>
  <content:encoded><![CDATA[<p>AWSで工場のデータ基盤を作るとき、設備データの入口として名前が挙がるのがAWS IoT SiteWiseです。この記事では、公表情報で確認できる範囲から、SiteWiseの役割、生成AIの保全アシスタントとの組合せ方、そしてどの製品を使っても自社で設計が必要になるアセットモデルの考え方を整理します。</p><p>AWS IoT SiteWiseは、産業設備のデータを集め、設備の種類と階層に沿ってモデル化するためのAWSのサービスです。データ基盤全体の中では、設備から上がってくるタグの時系列に「どの工場のどのラインのどの設備の、何の値か」という構造を与える層にあたります。</p><p>製造業のデータ基盤を層で分けると、SiteWiseの位置は次のように整理できます。</p><p>SiteWiseは、データ基盤のすべてを担う製品ではありません。MESのロットや作業指示、品質判定との結合や、長期の分析は、別のサービスや既存システムと組み合わせて作ります。</p><p><a href="https://mfg-ai.com/data/aws-iot-sitewise">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>ベンダー選定</category>
  <category>IoT・エッジ</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>製造業のデータ基盤はクラウドかオンプレか：3つの比較軸とハイブリッド案</title>
  <link>https://mfg-ai.com/data/cloud-vs-onprem-mfg</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/cloud-vs-onprem-mfg</guid>
  <description>機密性と可用性を求める処理はオンプレミス、分析と学習はクラウドに寄せるハイブリッドが製造業では多数派です。データの機密性・工場の可用性要求・運用体制の3軸で比べる方法と、AWS AI Factoriesなど主権型の新しい選択肢を整理します。</description>
  <content:encoded><![CDATA[<p>データ基盤をクラウドで作るか、社内のサーバで作るか。製造業ではこの議論が「図面や画像を社外に出せるか」で止まることがよくあります。この記事では、判断の3つの軸と、工場で多いハイブリッドの構成例、欧米の大手が打ち出している主権型の選択肢を整理します。</p><p>製造業のデータ基盤は、「全部クラウド」か「全部オンプレミス」かの二択で考えると決まりません。データ基盤の中には、性質の違う処理が混ざっているからです。</p><p>この3種類を分けて考えると、多くの工場で「収集と推論はオンプレミス／エッジ、蓄積・分析・学習はクラウド、機密データはオンプレミスか専用環境」というハイブリッドの形に落ち着きます。</p><p>製造業でクラウドの採用を止める最大の要因は、データの機密性です。ただし、すべてのデータが同じ機密度ではありません。設備の稼働状況やエネルギー使用量と、製品の図面やレシピでは、扱いが違って当然です。</p><p><a href="https://mfg-ai.com/data/cloud-vs-onprem-mfg">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>セキュリティ</category>
  <category>ROI・コスト</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>Cognite Data Fusionとは：産業ナレッジグラフとSchneider買収後の行方</title>
  <link>https://mfg-ai.com/data/cognite-data-fusion</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/cognite-data-fusion</guid>
  <description>Cognite Data Fusionは、設備・時系列・図面・文書を産業ナレッジグラフで結ぶDataOps基盤です。2026年6月にSchneider Electricが約31億ドルでの買収を発表し、AVEVA CONNECTへの統合が計画されています。強みと選定時の注意点を整理します。</description>
  <content:encoded><![CDATA[<p>Cogniteは、プラントや工場のデータを「文脈付け」することに特化したノルウェー発のデータ基盤企業です。2026年6月にSchneider Electricによる買収が発表され、製品の行方に注目が集まっています。この記事では、Cognite Data Fusionの考え方と強み、AIエージェント機能、買収後の選定で確認すべき点を整理します。</p><p>Cognite Data Fusion（CDF）は、設備の時系列データ、保全記録、P&amp;ID（配管計装図）などの図面、文書、3Dモデルといった、形式の違う産業データを集め、それらの関係を産業ナレッジグラフとして結び付ける基盤です。製品群の位置づけは「産業DataOps」と呼ばれ、データを集めるだけでなく、データ同士を意味のある形でつなぐ「コンテキスト化（文脈付け）」に重点を置いています。</p><p>工場のAIで問題になるのは、データがあっても「このセンサはどのポンプのもので、そのポンプの図面と保全履歴はどこにあるか」がつながっていないことです。</p><p><a href="https://mfg-ai.com/data/cognite-data-fusion">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>ベンダー選定</category>
  <category>欧米動向</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>製造データのガバナンス：所有者・品質責任・アクセス権を決める5つのルール</title>
  <link>https://mfg-ai.com/data/data-governance-mfg</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-governance-mfg</guid>
  <description>製造データのガバナンスは、データごとに所有部門と品質責任者を決めることから始まります。決めないと、AI用データの修正依頼が宙に浮き、誤った値で学習が続きます。所有者・品質ルール・変更管理・アクセス権・保持期間の5つのルールを、台帳1枚で管理する方法を示します。</description>
  <content:encoded><![CDATA[<p>「このタグの値はおかしいので直してほしい」とAIの担当者が言っても、誰に頼めばよいか分からない。製造データのガバナンス（管理の取り決め）がない工場で起きる典型的な問題です。この記事では、大がかりな規程を作る前に決めておくべき5つのルールと、それを1枚の台帳で回す方法を示します。</p><p>製造データのガバナンスは、データを誰が持ち、誰が品質に責任を持ち、誰が使ってよいかの取り決めです。AIを使い始めると、これが決まっていないことによる問題が表に出ます。</p><p>IPAの「DX動向2026」では、データ整備・管理・流通の課題として「データの標準化が難しい」が36.8%、「管理システムが整備されていない」が32.6%でした（全産業）。標準化や管理の仕組みの前提として、誰が決めるかを決める必要があります。</p><p>最初に決めるルールは、次の5つで足ります。</p><p>1の所有者は、データを作る部門が持つのが原則です。</p><p><a href="https://mfg-ai.com/data/data-governance-mfg">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>セキュリティ</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>製造業のデータレイク・レイクハウス：ブロンズ・シルバー・ゴールド3層の設計</title>
  <link>https://mfg-ai.com/data/data-lake-lakehouse</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-lake-lakehouse</guid>
  <description>レイクハウスはオープンな形式のデータの上にDWHの管理機能と機械学習の支援を組み合わせた構成です。製造業ではシルバー層でISA-95の文脈（ロット・品番・設備）を付与するのが固有の設計です。3層それぞれに置くデータ、品質ルール、AIとの接続を具体例で示します。</description>
  <content:encoded><![CDATA[<p>データレイクを作ったものの、生データの置き場になって誰も使っていない、という状態は珍しくありません。この記事では、レイクハウスのブロンズ・シルバー・ゴールドの3層構成を製造業向けに具体化し、どの層で何をすればAIが使えるデータになるかを示します。</p><p>レイクハウスは、データレイクの低コストで柔軟な保存と、データウェアハウス（DWH）の管理機能を組み合わせたアーキテクチャです。Armbrustらによる論文（CIDR 2021）は、レイクハウスを「Parquetなどのオープンで直接アクセスできる形式の上に、DWHの管理機能と機械学習への一級のサポートを組み合わせたもの」と定義し、データの鮮度・信頼性・TCO・ベンダーロックインといったDWHの課題に対処するものと位置づけています。著者らは、ベンチマーク（TPC-DS）でクラウドDWHと同等の性能を報告しています。</p><p><a href="https://mfg-ai.com/data/data-lake-lakehouse">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>AI基礎</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>製造業データ基盤の費用：収集・蓄積・連携・運用の4区分で見る相場と試算方法</title>
  <link>https://mfg-ai.com/data/data-platform-cost</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-platform-cost</guid>
  <description>製造業のデータ基盤の費用は、収集・蓄積・連携・運用の4区分で見積もると漏れが減ります。大きいのは初期の設備接続とMES連携の開発、毎年の運用人件費で、クラウドの利用料は思ったより小さいことが多い。ライン数に比例する費用と比例しない費用を分けて試算します。</description>
  <content:encoded><![CDATA[<p>データ基盤の見積もりを取ると、提案ごとに費用の区切り方が違い、比べられないことがよくあります。この記事では、製造業のデータ基盤の費用を4つの区分に分け、それぞれの費用が何で決まるのか、ライン数を増やしたときにどう増えるのか、社内で試算するための計算の型を示します。</p><p>製造業のデータ基盤の費用は、次の4区分に分けると、見積もりの比較と社内の予算説明がしやすくなります。</p><p>これにAIのモデル開発や運用の費用が別に乗ります。AIそのものの費用の考え方は製造業AIの導入費用の内訳で扱っています。</p><p>見積もりで目立つのはクラウドのライセンスやサーバーですが、実際に大きくなりやすいのは、3の連携と4の運用です。</p><p>連携の費用が大きくなるのは、MESや基幹システムとの接続が工場ごと、システムごとの個別開発になりやすいためです。MESにAPIがなくDBを直接読む構成にすると、初期は安くても、バージョンアップのたびに改修費がかかります。</p><p><a href="https://mfg-ai.com/data/data-platform-cost">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>ROI・コスト</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>データ基盤の段階的導入ロードマップ：ユースケースから逆算する8ステップ</title>
  <link>https://mfg-ai.com/data/data-platform-roadmap</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-platform-roadmap</guid>
  <description>製造業のデータ基盤は、KPI決定→タグ棚卸し→収集→MES連携→蓄積→MLOps→セキュリティ→結果の戻し、の8段階で進めます。最初のユースケースに必要な範囲だけを各段階で作り、2つ目以降で再利用できる共通部分を残すのが、PoC止まりを避ける進め方です。</description>
  <content:encoded><![CDATA[<p>「まずデータ基盤を作ってから、AIのテーマを考える」という進め方は、目的が曖昧なまま費用と時間を使う原因になります。この記事では、最初のユースケースから逆算してデータ基盤を段階的に作る8つのステップと、各ステップの成果物、次のユースケースに引き継ぐべき共通部分を示します。</p><p>データ基盤の進め方には、よくある2つの失敗があります。1つは、全工場の全データを集める基盤を先に作り、使い道が決まらないまま運用費だけがかかる「基盤先行」です。もう1つは、AIのPoCごとにデータを個別に集め、PoCが終わるとデータの集め方も捨てられる「AI先行」です。後者は、PoCが成功しても横展開のたびに同じ作業をやり直すことになります。</p><p>McKinseyの2018年調査（7市場・700社超）では、デジタル製造ソリューションを全社展開できた企業は約30%でした。</p><p><a href="https://mfg-ai.com/data/data-platform-roadmap">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>導入戦略</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>データ基盤を誰が持つか：データエンジニア・生技・情シスの3者の役割分担</title>
  <link>https://mfg-ai.com/data/data-platform-team</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-platform-team</guid>
  <description>製造業のデータ基盤は、ツールより「保守する人がいない」ことで止まります。データエンジニア・生産技術・情報システムの3者の役割を分け、最小体制（兼任を含め3〜4人）と外部委託の線引きを決めておくと、PoC後の運用で行き詰まりにくくなります。</description>
  <content:encoded><![CDATA[<p>データ基盤を作ったものの、センサの故障やタグの追加、MESの変更に誰も対応できず、半年でデータが欠けだす。製造業ではよくある話です。この記事では、データ基盤の運用に必要な役割と、生産技術・情報システム・データエンジニアの分担、少人数で回す最小体制と外部委託の線引きを示します。</p><p>データ基盤が止まる典型的な経緯は次のとおりです。PoCでは外部のベンダーやプロジェクトチームが基盤を作り、AIの精度も確認できた。プロジェクトが終わると、基盤の運用は「情報システム部門か生産技術のどちらか」に曖昧に引き継がれる。設備の更新でタグが変わり、データが欠け始めても、誰が直すのか決まっていない。数か月後、AIの精度が落ちていることに気付いたときには、原因を調べられる人がいない。</p><p><a href="https://mfg-ai.com/data/data-platform-team">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>人材育成</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>製造データ品質の10の問題：時刻ずれ・欠損・単位不統一をAI投入前に潰す方法</title>
  <link>https://mfg-ai.com/data/data-quality-manufacturing</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-quality-manufacturing</guid>
  <description>製造データには、タグ不統一・時刻ずれ・欠損・圧縮による損失・ラベル揺れなど10の典型的な品質問題があります。IPA「DX動向2026」でもデータ標準化の難しさを挙げた企業は36.8%。各問題の検出ルールと、品質ルールを基盤側に実装する方法を示します。</description>
  <content:encoded><![CDATA[<p>AIの精度が出ない原因を調べると、モデルではなくデータの問題だったということがよくあります。この記事では、製造データで頻出する10の品質問題を「設備データ」「MESデータ」「両者の結合」に分けて整理し、それぞれの検出ルールと、AI投入前に潰すための実装方法を示します。</p><p>AIの精度は、学習に使うデータの品質を超えられません。データサイエンティストの作業時間のうち、データ準備とクレンジングが約38%を占め、モデルの選択・学習・デプロイは約26%にとどまるという調査があります（Anaconda「2022 State of Data Science」、133か国・3,493人、2022年4〜5月）。製造業ではこの比率がさらに高いという実感を持つ担当者が多いはずです。</p><p>日本企業全体でも、データの整備は大きな課題です。</p><p><a href="https://mfg-ai.com/data/data-quality-manufacturing">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>品質管理</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>サプライチェーンのデータ連携：Catena-X・ウラノス・エコシステムと工場データ</title>
  <link>https://mfg-ai.com/data/data-sharing-supply-chain</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-sharing-supply-chain</guid>
  <description>日本企業の75.1%は他社とのデータ連携・提供を行っていません（IPA、米国19.8%・ドイツ27.0%）。Catena-Xやウラノス・エコシステムのような企業間連携は、自社の工場データが製品・ロット単位で整理されていることが前提で、CO2とトレーサビリティから始まります。</description>
  <content:encoded><![CDATA[<p>取引先からCO2排出量や部品のトレーサビリティのデータを求められる場面が増えています。この記事では、企業間データ連携の仕組みの考え方と、日本の製造業の現状、Catena-Xやウラノス・エコシステムに参加する前に、自社の工場データで何を準備しておくべきかを整理します。</p><p>企業間のデータ連携は、日本の製造業がAIやDXで欧米と差が開いている領域の1つです。IPAの「DX動向2025」によると、日本企業の75.1%は他社とのデータ連携・提供を行っていません。米国は19.8%、ドイツは27.0%でした。2026年版ものづくり白書も、企業間のデータ連携が2年前からほとんど進んでいないと指摘しています。</p><p><a href="https://mfg-ai.com/data/data-sharing-supply-chain">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>調達・SCM</category>
  <category>自動車</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>データウェアハウス・データレイク・レイクハウスの違い：工場データで選ぶ3つの基準</title>
  <link>https://mfg-ai.com/data/data-warehouse-vs-lake</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/data-warehouse-vs-lake</guid>
  <description>構造化されたKPIや実績の集計はDWH、画像・振動波形など非構造データの保存はデータレイク、機械学習を前提にするならレイクハウスが向きます。工場データの種類・利用者・AIの有無の3基準で選び方を示し、規模より用途で決める理由を説明します。</description>
  <content:encoded><![CDATA[<p>データ基盤の検討で必ず出てくるのが、DWH・データレイク・レイクハウスのどれを選ぶかという問いです。この記事では、3つの違いを工場のデータに当てはめて整理し、データの種類・利用者・AIの有無の3つの基準で選ぶ方法を示します。</p><p>DWHは、あらかじめ決めた構造（スキーマ）に合わせてデータを整えてから入れます。集計は速く正確ですが、構造に合わないデータ（画像や波形）は扱いにくく、構造の変更にも手間がかかります。</p><p>データレイクは、データを元の形式のまま安価に保存します。何でも入れられる反面、データの管理（どのデータが最新か、誰が更新したか、品質はどうか）が弱く、管理されないまま放置されると使えないデータの山になります。</p><p><a href="https://mfg-ai.com/data/data-warehouse-vs-lake">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>AI基礎</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>不良コード・停止理由コードの設計：AIで分析できる粒度に直す6つの原則</title>
  <link>https://mfg-ai.com/data/defect-code-design</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/defect-code-design</guid>
  <description>「その他」が2〜3割を占めるコード体系では、AIは不良や停止の要因を学べません。現象・部位・原因を分けた階層化、選択肢の数の上限、入力UIと入力タイミングの見直しなど6原則で、分析できる粒度に直す方法を示します。</description>
  <content:encoded><![CDATA[<p>停止理由の集計を出したら、最大の項目が「その他」だった。不良コードが工場ごとに違い、横並びで比較できない。こうしたコード体系のままでは、AIを入れても要因分析はできません。この記事では、不良コードと停止理由コードをAIで使える粒度に設計し直す6つの原則を示します。</p><p>不良コードと停止理由コードは、品質AIや稼働分析AIにとっての「正解ラベル」です。センサの時系列をいくら細かく取っても、ラベルが「その他」や「調整」のような曖昧な分類なら、モデルはその曖昧さ以上の区別を学べません。つまり、コード体系の粒度がAIの精度の上限を決めます。</p><p>現場でよく見るのは、次のような状態です。</p><p>これらは入力する人の怠慢ではなく、体系と入力方法の設計の問題です。</p><p>コード体系を作り直しても、入力の仕方が変わらなければ記録は良くなりません。効くのは次の3点です。</p><p><a href="https://mfg-ai.com/data/defect-code-design">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>品質管理</category>
  <category>MES連携</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>DELMIA Apriso×AIの現実：MES実装者が見る連携方式・できること・制約</title>
  <link>https://mfg-ai.com/data/delmia-apriso-ai</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/delmia-apriso-ai</guid>
  <description>DELMIA AprisoをAIとつなぐ現実的な構成は、Aprisoのデータを外部のデータ基盤に出し、AIの結果をAprisoの業務フローに戻す形です。製品単体のAI機能に期待しすぎず、連携方式3つの長所と制約、カスタマイズとバージョンアップの工数を最初に見積もります。</description>
  <content:encoded><![CDATA[<p>DELMIA Aprisoを使っている、または導入を検討している工場で、AIとどうつなぐかを考えるときの論点を整理します。MESを実装する立場から、現実的な連携の構成、Aprisoのデータで何ができるか、導入前に知っておくべき制約と工数を、製品を持ち上げず正直に書きます。</p><p>DELMIA Aprisoは、Dassault SystèmesのDELMIAブランドで提供されるMES・MOM（製造オペレーション管理）製品です。作業指示、ロット・シリアルの系譜、品質記録、設備状態、作業者の実績を1つのデータモデルで持ち、複数の工場で同じ業務プロセスを展開するグローバル展開の用途で使われることが多い製品です。</p><p>AIとの関係で見ると、Aprisoに限らずMESは次の2つの役割を果たします。</p><p>Aprisoを使っている工場の強みは、この2つが既にシステムとして存在することです。</p><p><a href="https://mfg-ai.com/data/delmia-apriso-ai">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>MES連携</category>
  <category>データ基盤</category>
  <category>ベンダー選定</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>デジタル製品パスポート（DPP）と工場データ：EU規制に備えるデータ基盤の準備</title>
  <link>https://mfg-ai.com/data/digital-product-passport</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/digital-product-passport</guid>
  <description>EUのデジタル製品パスポート（DPP）は、製品単位で材料・工程・環境データの提出を求める仕組みです。工場側の準備は、トレーサビリティ基盤とAASの延長で進められます。対象品目と時期は規制ごとに違うため、一次情報で確認しつつ、製品とロットの紐付けから整えます。</description>
  <content:encoded><![CDATA[<p>欧州向けに製品を出荷する製造業にとって、デジタル製品パスポート（DPP）は「いつか来る規制」から「準備を始める規制」になりつつあります。この記事では、DPPが工場データに何を求めるのか、既存のトレーサビリティやMESのデータで何が賄えて何が足りないのか、データ基盤側で今から準備できることを整理します。</p><p>デジタル製品パスポート（Digital Product Passport、DPP）は、製品ごとに、その材料・製造・環境負荷・修理やリサイクルに関する情報をデジタルで記録し、QRコードなどを通じて関係者が参照できるようにする仕組みです。EUが循環経済と製品の持続可能性の政策の一環として導入を進めています。</p><p>対象となる製品群、記載が必要な項目、適用の時期は、製品分野ごとの規則や委任法令で決まり、分野によって大きく異なります。この記事では個別の期限には触れず、工場のデータ基盤の側で共通して必要になる準備に絞ります。</p><p><a href="https://mfg-ai.com/data/digital-product-passport">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>規制対応</category>
  <category>データ基盤</category>
  <category>欧米動向</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>エッジAIとは：工場で推論をエッジに置く4つの理由とJetson等の機器選定</title>
  <link>https://mfg-ai.com/data/edge-ai-basics</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/edge-ai-basics</guid>
  <description>工場で推論をエッジに置く理由は、遅延・帯域・可用性・機密性の4つです。Jetson Orinの性能（最大275 TOPS、NVIDIA公表）やCPU推論の選択肢を整理し、導入後に問題になる多数台のモデル配布・版管理・監視の設計まで示します。</description>
  <content:encoded><![CDATA[<p>外観検査や設備監視のAIを、クラウドではなくライン横の小型機で動かす「エッジAI」が工場の標準的な構成になりつつあります。この記事では、エッジに推論を置く4つの理由、機器の選び方、そして台数が増えたときに必ず問題になる運用の設計を整理します。</p><p>エッジAIとは、AIの推論（学習済みモデルで判定すること）を、クラウドやデータセンターではなく、設備の近くに置いた計算機で行う構成です。工場でエッジを選ぶ理由は、次の4つに整理できます。</p><p>逆に、ライン横断の分析、モデルの再学習、長期間のデータ蓄積は、計算資源と全体のデータが集まるクラウドやデータセンター側が向いています。実務では「推論はエッジ、学習と横断分析はクラウド」というハイブリッドが標準的です。どちらに置くかの判断は推論はエッジかクラウドかで詳しく扱います。</p><p>エッジ機器は、モデルの種類と処理量で選びます。</p><p><a href="https://mfg-ai.com/data/edge-ai-basics">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>IoT・エッジ</category>
  <category>データ基盤</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>推論はエッジかクラウドか：タクト・画像サイズ・台数の3軸で決める判断フロー</title>
  <link>https://mfg-ai.com/data/edge-vs-cloud-inference</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/edge-vs-cloud-inference</guid>
  <description>タクト内に判定を返す必要があればエッジ、ライン横断の分析と再学習はクラウドが基本です。タクト・データ量・台数の3軸で置き場所を決める判断フローと、ハイブリッド構成の役割分担、費用比較で見落としやすい項目を示します。</description>
  <content:encoded><![CDATA[<p>AIの推論をライン横のエッジ機で動かすか、クラウドで動かすか。ベンダーによって提案が分かれ、判断に迷う論点です。この記事では、タクト・データ量・台数の3軸で置き場所を決める判断フローと、実務で標準的なハイブリッド構成の役割分担を示します。</p><p>製造業のAIでは、「その場で判定を返す推論」と「データを集めて考える処理」で、置き場所の最適解が違います。</p><p>この役割分担を前提に、個々のユースケースを3つの軸で判定します。エッジを選ぶ一般的な理由（遅延・帯域・可用性・機密性）はエッジAIとはで整理しています。</p><p>判定結果を、排出機構・停止信号・作業者への指示として設備側に返す必要があるかを最初に確認します。タクトが数秒以下で、判定が次のワークに間に合わなければならない用途は、ネットワーク越しの往復と、その時間のばらつきを許容できません。外観検査のインライン判定はほぼこれに当たります。</p><p><a href="https://mfg-ai.com/data/edge-vs-cloud-inference">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>IoT・エッジ</category>
  <category>データ基盤</category>
  <category>ROI・コスト</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
<item>
  <title>製造業の特徴量ストア：品番・設備・時間窓の3軸で特徴量を共有し横展開を速くする</title>
  <link>https://mfg-ai.com/data/feature-store-mfg</link>
  <guid isPermaLink="true">https://mfg-ai.com/data/feature-store-mfg</guid>
  <description>特徴量ストアは、AIの入力に使う加工済みの値（特徴量）を定義ごと共有する仕組みです。製造業では品番・設備・時間窓の3軸で特徴量を管理すると、2ライン目以降のAI開発で同じ計算を作り直さずに済みます。導入すべき規模の目安と、小さく始める方法を示します。</description>
  <content:encoded><![CDATA[<p>1ライン目の予知保全AIで作った「直近1時間の振動RMSの平均」を、2ライン目でまた別の人が別の書き方で作り直している。AIの横展開が遅い工場でよく見られる状況です。この記事では、特徴量を共有する仕組みである特徴量ストアを、製造業のデータに合わせてどう設計するか、どの規模から必要になるかを示します。</p><p>特徴量（feature）は、生のデータをAIの入力に使える形に加工した値です。製造業では、例えば次のようなものが特徴量になります。</p><p>特徴量ストアは、こうした特徴量の定義（何から、どう計算するか）と計算結果を一か所で管理し、複数のAIモデルや担当者が再利用できるようにする仕組みです。Googleの研究者による論文「Hidden Technical Debt in Machine Learning Systems」（NeurIPS 2015）は、実際の機械学習システムのうち機械学習のコードはごく一部で、周辺のデータ処理などのインフラの方がはるかに大きく複雑だ…</p><p><a href="https://mfg-ai.com/data/feature-store-mfg">続きをサイトで読む（データ基盤・MES連携）</a></p>]]></content:encoded>
  <category>データ基盤・MES連携</category>
  <category>データ基盤</category>
  <category>PoC</category>
  <pubDate>Sun, 11 Oct 2026 15:00:00 GMT</pubDate>
</item>
</channel></rss>