製造業のDXを加速する「AI Skill」とは？
ERP/MES/PLM開発を高速・高品質化する実践ガイド

製造業の現場で「速く、ムダなく、品質を落とさず」に成果を出すには、属人的なやり方を“使える標準”に変え、AI Skillとして社内に内製化・定着させることが近道です。本記事では、言葉とルールの統一から始めて、小さく作って試し、資産化して横展開・自動化へ広げる4ステップの実践ロードマップと、よくある課題への具体的な対処（MRPの着手順、既存ベンダーとの併走、データ品質是正、セキュリティ/ガバナンス）を、ビジネス視点でわかりやすく解説します。今日から着手できる“最初の一歩”まで落とし込み、次の案件ほど速く安心して立ち上げられる状態づくりを支援します。

1 なぜ今、製造業のDXは“専門性”がボトルネックになるのか

製造業のシステム開発は、一般的な業務アプリ開発とは根本的に異なります。BOMやMRP、工程能力、ロット・WIP、品質・原価、変更管理など、現場固有の概念と制約が密接に結びつき、さらにERP/PLM/MESといった基幹が複雑に連携します。結果として、ドメイン知識が不足した“汎用チーム”では、要件定義からテストまでの各工程でギャップが連鎖しがちです。本章では、その背景と失敗パターン、そして事業インパクトを明確にします。

1.1 市場背景：人材不足 × SC再編 × DX需要増

• 日本
  IT人材 79万人不足（2030年予測）。この構造的な人材ギャップが、基幹刷新や新規立上げに必要な「ドメイン×基幹×開発」人材の充足を難しくし、要件確定・設計判断のスピードを鈍化させます。
• 製造業
  DX需要増加／基幹刷新・工場立上げ。老朽化したERPや周辺システムのリプレースに加え、新拠点の立上げが重なり、要件の不確実性と連携難易度が上昇しています。
• SC再編
  サプライチェーン多元化・拠点分散・関税対応。E-BOMからM-BOMへの変換、代替部品管理、在庫・仕掛・手配の整合、関税・原産地規則対応など、PLM-ERP-MES間のデータ連携要件が複雑化しています。
• ベトナム
  IT人材供給力↑／国策による育成。供給力の伸長はポジティブですが、製造業ドメインや基幹の前提を横断できる“専門人材”の育成・アサインがボトルネック化しやすい状況です。

以上の背景が重なり、「人材不足 × SC再編 × DX需要増 → 専門人材がボトルネック化」という構図が顕在化しています（数値・キーワードはご提供のスライドに準拠）。

1.2 よくある失敗パターン：用語の壁／定義の壁／基幹の壁

失敗パターン

• 用語の壁
  同じ言葉でも、現場とITで意味がズレます（例：OEE、ロット/シリアル、段取り、実績・仕掛WIP）。ズレたまま基本設計に入ると、画面・API・ERの粒度が噛み合わず、後工程で仕様差分が噴出。
  対策：現場の“共通言語”を整備し、要件→画面→IF→テスト観点へ一貫マッピング。
• 定義の壁
  「在庫」「原価」「出来高」などの定義が部門/システムで不一致。たとえば現場原価の計算（標準/実際/配賦）や、BOMの有効期間・代替・ファントムの扱いが曖昧だと、テストで“正しさ”を判定できない。
  対策：業務定義とデータ定義（ER/コード体系/有効期限）を先に固定し、判断基準を一本化。
• 基幹の壁
  ERP/PLM/MESの前提や反パターンを知らないと、誤った分割・トランザクション設計に陥る。典型は「ERP指図＝MESオーダー1:1固定」という思い込み。実情は設備停止や段取り替えで「指図分割（1:N）」が頻発し、戻し・合算時の在庫/原価整合が破綻。
  対策：PLM=設計BOM、ERP=計画/手配/在庫、MES=実行/実績という責務境界を明確化し、状態遷移・積上げ・戻し処理を設計パターンとして標準化。

1.3 影響：立上げ長期化、テストで仕様差分噴出、品質・納期の再現性崩壊

• 立上げ長期化とコスト超過
  共通言語を固めないまま進行すると、追加ヒアリングと設計リワークが連発。WBS/クリティカルパスが延伸し、見積り精度・ガバナンスが低下。
• テスト段階での“仕様差分”大量発生
  MOQ丸め、LTオフセット、代替BOM、有効期間、ECR/ECO切替日などの境界条件で不整合が露呈。IF粒度やコード体系の違いにより、システム突合・トレーサビリティが崩れ、欠陥修正がスパイラル化。
• 品質・納期の再現性が崩壊
  属人化が進むと、レビュー観点・非機能・命名/例外/監査のばらつきが拡大。欠陥密度と手戻り率が安定せず、納期と品質の再現性が失われる。
• ビジネス面のダメージ
  設計変更（ECR/ECO）の反映遅延で旧部品の発注・製造が発生し、在庫・原価の乖離、納期遅延、トレーサビリティ不全によるコンプライアンス課題が顕在化。

注：上記のうち、1.1の見出し構成と「IT人材 79万人不足（2030年予測）」「サプライチェーン多元化・拠点分散・関税対応」「IT人材供給力↑／国策による育成」等は、いただいたスライドの表現・数値に準拠しています。他の具体例・対策は、スライドのメッセージを補強するための実務的な拡張解説です。

2 解決策の骨子：共通言語 × 基幹理解 × AI駆動 × 資産化

“専門性のボトルネック”を解消するには、現場とITの思考を同じ土俵に乗せ、基幹の責務境界で迷わず設計判断し、AIで作業を構造化し、得られた知見を資産として再利用可能にすることが要点です。本章では、その4本柱を実装レベルで示します。

2.1 現場と同じ“共通言語”で要件を定義する

最初に整えるのは「言葉」です。用語が揃えば、画面やAPI、ER、テスト観点の粒度が自動的に揃います。

• 用語・定義・例外をひとまとめにする
  • 用語定義：用語の意味、計算式、単位、桁数、丸め規則。
  • 運用前提：いつ・誰が・どの頻度で使うのか（例：ロット付番は工程開始時に自動採番）。
  • 例外/境界：有効期限/切替日、代替BOM条件、在庫ゼロ時の処理など。
• “現場フロー”と“データ”を同時に描く
  • 現場業務の状態遷移（例：計画→指図→実行→実績→在庫/原価反映）を、一意な状態コードで管理。
  • 各状態で増減するデータ（在庫、WIP、原価項目）を紐づける。
• 最初に作る最低限アセット
  • 共通語彙集（Glossary）と判定ルール（Do/Dont）。
  • 状態遷移図と状態コード表。
  • データ契約（フィールド定義・必須/任意・バリデーション・エラー方針）。
  • テスト観点リスト（正常・境界・例外・横断：性能/セキュリティ/監査）。

例：在庫の“引当”を定義する際、「どの優先順位で」「どの単位で」「どの例外時にスキップ/分割するか」までGlossaryで明文化し、同じ粒度で画面仕様・API仕様・テストケースへ展開します。

2.2 ERP/PLM/MESの前提を押さえた設計判断

基幹システムは“できること/やらないこと”が明確です。責務を越境させない設計が、後工程の不整合を激減させます。

• 責務境界の原則
  • PLM：設計ソース・E-BOM・変更管理（ECR/ECO）。M-BOM/手配に波及させるトリガーを担保。
  • ERP：計画・所要量計算（MRP）・購買/在庫・原価。コード体系・有効期限・会計整合性が主眼。
  • MES：実行・実績・現場制御。1:Nの指図分割、途中中断、合算戻し、トレーサビリティを担保。
• よくある設計判断の勘所
  • 指図分割（1:N）：分割のトリガー（能力・不良・段取り）と“ERPへの戻し方（合算/明細維持）”を先に決定。
  • BOM運用：代替・ファントム・有効期間をPLM/ERPどちらで主導するかを明示し、MRPと整合。
  • 原価：標準/実際/差異の責務をERPに集約し、MESは実績粒度とタイミングを保証。
  • 変更管理：ECR/ECO切替日に伴うBOM・手配・在庫の境界を、切替カレンダとジョブ順序で統制。
• 反パターン回避のチェック
  • “ERP指図＝MES指図1:1固定”の思い込みを排除。
  • “PLMがM-BOMも全管理”でERPと二重管理にならないようにする。
  • “在庫・原価の一時計上”をMESで持ち過ぎない（会計・監査の単一責務を守る）。

この段階の成果物は、責務境界マトリクス、システム間インターフェースの責務表、状態遷移とトランザクション整合のシナリオ図です。以降の開発では、これを“設計の憲法”として使います。

2.3 AI Skillによる開発の構造化

AI Skillは、ドメイン知識を「再現可能な手順・ルール・テンプレート」に落とし込み、設計～テストまでの生産性と品質を底上げします。重要なのは“3層構造”で管理することです。

• 層1：ドメイン・コンテキスト
  • 業務フロー、Glossary、例外パターン、状態遷移、データ契約。
  • 目的：AIが“現場の文脈”を誤解しない土台を作る。
• 層2：設計・参照アーキテクチャ
  • 代表ER、API設計テンプレ、UI/帳票テンプレ、連携パターン、非機能ガイド（可用性・性能・セキュリティ）。
  • 目的：要件から設計成果物を半自動で生成し、レビュー観点を標準化。
• 層3：生成ルール・品質基準
  • 命名規約、エラー/例外ポリシー、テスト観点→テストケース自動展開、ソースコードスキャナのルール。
  • 目的：実装とテストの“ばらつき”を抑え、初日から合格水準を満たす。

運用イメージ：

• 要件を入力（例：“MRPで代替BOMを有効期間優先で展開、MOQ丸め、LTオフセット適用”）。
• AI Skillが出力：ERの差分、API I/F案、境界テスト、非機能チェック、ログ/監査設計の雛形。
• 人がレビュー：現場とアーキが速いサイクルで赤入れ→Skillへフィードバックし精度を上げる。

小さく始めるなら、1サブドメイン（例：MRP、指図分割、ECR/ECO）に絞ってSkill初版を作成し、パイロットで学習→横展開します。

2.4 仕様データとSkillの“資産化”で再現性を高める

“作って終わり”にしないために、仕様とSkillをバージョン管理し、案件を跨いで学習・再利用できる状態にします。

• 管理単位とリポジトリ戦略
  • 管理単位：Glossary、状態遷移、データ契約、連携パターン、テスト観点、コード規約、生成プロンプト。
  • バージョニング：ECR/ECOの切替日と連動する“仕様タグ”と、ソフトウェアの“リリースタグ”を分離。
  • トレーサビリティ：要件→設計→実装→テスト→運用ログまでIDで紐づけ、差分の根拠が追えるようにする。
• 品質ゲートとメトリクス
  • ゲート例：Glossary未定義語のブロック、データ契約とAPI定義の不一致検知、状態遷移の未定義パス検出。
  • メトリクス：立上げ期間短縮率、仕様差分件数、欠陥密度、テスト自動化率、リードタイム短縮率。
• 継続的学習（Closed Loop）
  • プロジェクトで発見した例外や改善点をSkillへ“PR”として取り込み、レビューして採番・公開。
  • ベストプラクティスはテンプレ化し、次案件の初期スコープに自動提案。
• ガバナンスとアクセス制御
  • 機密度に応じたアクセスレベル（閲覧・提案・承認・配布）。
  • 外部ベンダーやオフショア拠点とは“実行物は共有、学習素材は匿名化/合成データ化”で安全に流通。

成果イメージ：

• 新規案件のキックオフ時点で、用語・状態・連携・非機能・テストの雛形が即時に展開され、初週から設計とPoCを並列始動。
• 回を重ねるほどSkillが賢くなり、品質と納期の“再現性”が高まる。属人化から脱却し、チームの総合力が逓増する。

この4本柱を揃えることで、現場の知見が“使い回せる設計力”へと転化し、ERP/PLM/MES開発のスピードと品質を同時に伸ばせます。次章では、サプライチェーン全体を見渡したAI Skillの適用マップと、具体ユースケースでの設計・テスト観点を示します。

3 「AI Skill」とは何か：人の知見をAIが実行できる形式へ

AI Skillは、現場の暗黙知（判断基準・手順・例外処理）を機械可読な文脈と生成・検証ルールに変換し、要件→設計→実装→テスト→運用を同一前提で貫通させる運用資産です。ポイントは、用語や業務フローなどの“意味”を先に固定し、その意味に整合する設計テンプレとコード生成ルールを束ねて、毎回ゼロから考えない状態を作ることにあります。

これにより、担当者や拠点が変わっても同じ条件なら同じ成果物が出る“再現性”を担保し、レビューは差分判断に集中できます。

4つの柱で「再現性」を構造的に作る

3.1 従来資産（用語集・設計テンプレ・参照アーキ・テスト観点・コーディング規約）の限界

従来の資産はドキュメント依存で断片化しがちで、読む人の解釈に品質が左右されます。用語集は定義を示せても「どの状態で、どの例外時に、何を優先するか」という運用前提が外部に散在し、設計テンプレや参照ERも“利用前提”が欠落すると誤用（例：有効期限や代替BOM条件の取り違え）を招きます。

テスト観点は網羅性を高めても、要件差分に応じた自動展開が弱く、更新がコードやI/F定義へ同時反映されません。静的解析やCIは形式的整合（型・命名・複雑度）には強い一方、在庫・原価・トレーサビリティといったドメイン整合の検証には不十分です。結果として、属人対応とレビュー負荷が増え、変更時の影響把握も人手に頼り、速度と品質の両立が崩れます。

3.2 AI Skillの3層構造

AI Skillは「ドメインコンテキスト」「設計パターン・参照アーキ」「コード生成ルール・品質基準」の三層で構成し、層ごとにバージョン管理して差分を可視化・検証可能にします。鍵は、上位層の文脈を下位層へ強制適用する“拘束力”で、解釈余地を意図的に減らすことです。

ドメインコンテキスト（業務フロー／用語辞書／例外パターン）

計画→指図→実行→実績→在庫/原価反映の状態遷移と許可/禁止パス、用語の意味・計算式・単位・丸め・コード体系・有効期限・切替日、在庫引当や代替BOMの優先順位、指図分割のトリガ（能力・不良・段取り）、MOQ丸め・LTオフセットなどの境界条件を機械可読に定義します。これにより、AIは“いつ/何を/どの順に/どの条件で”適用するかを誤解せず、以降の設計生成やテスト展開で同一前提を保証できます。

設計パターン・参照アーキ（ER/API/画面・テスト観点）

品目・BOM・在庫・WIP・原価の代表ER、I/F必須/任意・バリデーション・エラー方針を含むAPIテンプレ、実績収集UIや指図分割/合算の操作パターン、PLM-ERP-MES間のイベント駆動/バッチ連携シナリオ、そして正常/境界/例外/非機能（性能・可用性・セキュリティ・監査）を体系化したテスト観点カタログを持ちます。要件を与えると、ER差分、API案、UI雛形、連携シナリオ、関連テスト観点が一括提示され、レビューは前提整合と差分妥当性に集中できます。

コード生成ルール・品質基準（命名／エラー方針／非機能チェック）

命名規約、例外分類、ロギング/監査キー付与、トレーサビリティIDの付与規則、リトライ/タイムアウト/サーキットブレーカ等の非機能ポリシーを生成時に強制します。品質ゲートでは、未定義用語の使用ブロック、API定義とデータ契約の不整合検知、未定義状態遷移の検出、在庫・原価の整合チェックを自動化し、初回コミットから“可読・可監査・可追跡”な成果物のみを通過させます。

3.3 効果：初日からドメインに沿った設計・実装が可能に

キックオフ当日から、用語・状態・データ契約・連携・テスト観点の雛形が自動展開され、PoCと基本設計を並走で開始できます。同一要件に対して同一の設計・I/F・テストが安定出力されるため、欠陥密度や仕様差分は初期段階で減少し、レビューは“例外判断と受容リスク”に集中してサイクルが短縮します。変更時はECR/ECOやマスタ改訂に応じた影響範囲と追加テストが自動提示され、切替日前後で在庫・原価・トレーサビリティの一貫性を維持できます。

さらに、責務境界に沿った連携シナリオを都度再生成するため、指図分割・合算戻し・会計反映といった難所でもI/Fとログ設計が標準化され、拠点やベンダーが変わっても品質と納期の再現性を確保できます。

4 事例｜SAP PP：MRP所要量計算の開発を高速化

概要

MRPの流れ（作る量と時期を決める → 必要部品を展開 → 手持ち/入荷を差し引く → 発注単位に合わせて数量調整 → 必要日から逆算して前倒し）を“ひとつの型”に整理し、AI Skillに埋め込みます。
初日からSAPのやり方に沿って実装でき、仕様読み込みと擦り合わせの数週間を数日に短縮します。

押さえるポイント

• 代替部品の自動置き換え、有効期間の判定、通過部品（ファントム）の扱いを標準化。
• “納期が厳しい／在庫が多すぎ／リードタイム超過”などのアラートと、次の行動（前倒し・分割・代替）をセットで提示。
• 安全在庫・棚卸差・分納を踏まえて“正味の必要量”を計算。
• 生産能力も同時に確認し、実行不能な計画は出さない。

進め方（シンプル版）

• 用語と運用ルールを辞書化（代替の優先、使える期間、最小発注、リードタイム、在庫の扱いなど）。
• 辞書を前提に、画面・連携・計算ロジックの雛形を自動作成。
• 未定義用語や矛盾をブロックする品質チェックを最初から組み込み。
• 能力不足時の対処（前倒し・分割・代替工程）をパターン化し、再計算へ反映。
• 代表テスト（最小発注の端数、期間の境目、分納、棚差、アラート発火）を自動で用意。

ビジネス効果

• 立ち上げが速い：数週間 → 数日。
• 手戻りが減る：同じ前提なら同じ結果。
• 変更に強い：部品や期間・発注条件が変わっても、影響範囲と追加テストを自動提示。
• 全体最適：必要量・日程・能力が噛み合う計画に収れん。

導入チェック（短く確実に）

• 代替・期間・最小発注・リードタイム・能力の運用ルールが辞書化されているか。
• 在庫前提（安全在庫・棚差・分納）が決まっているか。
• アラートの基準値、担当、取るべき行動が合意済みか。
• 期間またぎ・端数・能力不足など“境目のケース”がテストに入っているか。