# TPiCS・生産革新 Wun に生成AIを追加する方法

> Source: https://netray.co/ja/tpics-seisan-kakushin-wun-ai
> Language: ja
> Publisher: Netray (netray.co)

TPiCS や生産革新 Wun のような中小製造業向けパッケージは、多くの場合データベースの参照と CSV 出力で外部連携できます。この読み取り経路に社内設置の生成AIをつなげば、納期回答や在庫の問い合わせを日本語で行え、基幹側の改修は最小限で済みます。

従業員数十名から数百名の製造業では、生産管理パッケージが「担当者の頭の中の運用」と一体になっていることが少なくありません。部品表、工程表、所要量計算の結果は画面にありますが、「この受注はいつ出せるか」「この部品が遅れたらどの受注が止まるか」といった問いには、結局ベテランが複数画面を行き来して答えています。

生成AIは、こうした問い合わせと説明の部分に向いています。一方で、所要量計算や在庫引当そのものを置き換えるものではありません。計算はパッケージに任せ、AI は読み取った結果を人に分かる言葉にする役割に絞るのが、中小企業では最も失敗しにくい設計です。

本ページでは TPiCS や生産革新 Wun を使う現場を想定し、どこまでを AI に任せ、どこからを任せないかを具体的に整理します。製品ごとの正確な仕様はバージョンや導入形態で異なるため、実際の接続方式は事前に必ず確認します。

## 中小製造業の生産管理でよくある困りごと

典型的なのは、納期回答の属人化、Excel での補助管理の増殖、そして担当者の退職や高齢化による運用知識の断絶です。パッケージ自体は動いていても、「なぜこの計画になったのか」を説明できる人が限られます。

もう一つは、見たい切り口の帳票が足りないことです。パッケージ標準の帳票では足りず、現場が Excel に出力して加工している例は多く、その加工手順が個人の持ち物になっています。

- 納期回答に複数画面の確認が必要で、特定の担当者に集中する
- 不足部品の影響範囲を調べるのに時間がかかる
- 標準帳票にない切り口を Excel で毎回作り直している
- 運用ルールが文書化されておらず、引き継ぎが難しい

## 生成AIが役立つ具体的な場面

第一は自然言語での問い合わせです。「来週出荷予定で、材料が未入荷の受注を一覧にして」といった質問を、読み取り専用のクエリに変換して結果を表で返します。実行した SQL を併せて表示するため、数字の根拠を後から確認できます。

第二は計画結果の説明です。所要量計算の結果と在庫、発注残を突き合わせ、「この遅れは部品Aの入荷待ちが原因」と文章で要約します。営業が顧客に回答する際の下書きにも使えます。

- 受注、在庫、発注残、工程進捗の日本語での問い合わせ
- 納期遅延リスクの理由の要約
- 週次の生産会議用の資料の下書き
- 作業標準書や過去のトラブル記録の検索

## 接続方式と社内設置の構成

TPiCS や Wun のようなパッケージでは、データベースの参照用アカウントを用意するか、定期的な CSV 出力を取り込むのが現実的です。いずれもパッケージのベンダーが想定する範囲かどうかを、保守契約の観点で事前に確認してください。直接書き込みは行いません。

モデルは Llama、Qwen、Gemma などのオープンウェイトを、自社の GPU サーバーまたは国内のプライベート環境で動かします。vLLM や Ollama で提供し、図面や原価を含む情報が外部の AI サービスに送られない構成にできます。

ERPray は ERP のデータに対する自然言語の問い合わせを、読み取り専用で、実行したクエリを見せながら、ERP の権限に従って提供する製品です。パッケージごとのコネクタは評価時に確認します。

## AI に任せない範囲と人の承認

所要量計算、在庫引当、原価計算は、これまでどおりパッケージが行います。AI が出した数字を鵜呑みにせず、必ず元の画面や帳票で確認できる形にします。

受注登録や発注の変更など、基幹への書き込みを伴う操作は、AI が下書きを作り、担当者が内容を確認して承認してから実行します。承認なしに書き込む構成は推奨しません。

- 計算ロジックはパッケージ側に残す
- 書き込みは人の承認を必須にする
- 回答には根拠となるデータと実行クエリを添える

## ベンダー標準機能で足りる場合

パッケージ側が検索条件の保存や任意項目の帳票出力を十分に備えているなら、まずそれを使い切るほうが安く確実です。生成AIが効くのは、条件が毎回変わる問い合わせや、複数の表をまたぐ質問が多い場合です。

また、マスタの整備が不十分な状態で AI を入れても、誤った回答が増えるだけです。品目コードの重複や工程マスタの不整合は、AI の導入前に直すべき課題です。

## 進め方：評価から小さな実証まで

最初の 2 週間で、利用中のバージョン、データベースの種類、参照可能なテーブルを確認し、現場で最も時間を取られている問い合わせを三つ選びます。ここで AI が向かないと分かれば、その旨を正直にお伝えします。

次に、本番データの複製に対して読み取り専用で接続し、選んだ三つの問い合わせの精度を現場の担当者と一緒に確認します。精度が基準に届いた範囲だけを、権限を絞って本番に広げます。

## FAQ

### TPiCS や Wun のベンダー保守契約に影響しませんか。

読み取り専用の参照や CSV 出力にとどめれば、通常は影響を避けられますが、契約内容はベンダーごとに異なります。事前にベンダーへ参照方式を確認することを推奨します。

### クラウド版の生産管理でも使えますか。

API や出力機能が公開されていれば可能ですが、データの置き場所は別途検討が必要です。オンプレミス運用のデータのほうが、社内設置のモデルとは組み合わせやすい傾向があります。

### 専任の情報システム担当がいなくても導入できますか。

初期の接続と設定は私たちと導入パートナーが行います。運用開始後は、問い合わせの追加や権限の見直しが主な作業で、専任者がいなくても回るよう設計します。

### 回答の間違いはどう防ぎますか。

実行したクエリと元データを必ず併記し、担当者が確認できるようにします。重要な数字は元の帳票との突き合わせを前提とし、書き込みは承認を必須にします。

### GPU サーバーは必ず必要ですか。

モデルの大きさと同時利用人数によります。小規模な問い合わせ用途であれば、比較的小さな GPU 構成から始められます。必要な構成は評価の段階で見積もります。