Tech Blog
ChatGPTは製造現場で何ができて、何ができないのか— LLM実装の現場から
はじめに：LLM実装への壁
株式会社羽石産業知能研究所（HIII）の田中です。
「OpenAIのAPIを契約して、手順書をアップロードしてみたんですが、正確な回答が全然返ってこなくて」——最近、こういった悩みを抱えているDX担当者は少なくありません
LLMは、単純にAPIに文書を投げ込むだけでは動きません。どのデータを、どう構造化して、どう問いかけるかという設計が、「試したけど使えなかった」と「現場で毎日使われている」を分けます。本記事では、HIIIがこれまで蓄積してきた知見をもとに、LLMを現場に実装するための具体的な設計思考をお伝えします。
コードの説明はしませんが、設計レベルの話を具体的に掘り下げます。「ChatGPTは知っているが、RAGは聞いたことがある程度」という方を想定しています。
LLMの守備範囲を最初に決める
LLMは「言語処理の専門家」であり、センサーデータや画像は本来の守備範囲ではありません。製造現場のAI全体の中で、LLMが担当するスコープを最初に絞ることが設計の全ての出発点です。
| データの種類 | 正しいAIの担当 | LLMで代替できるか |
|---|---|---|
| 手順書・報告書・マニュアル | LLM（RAG） | 得意領域 |
| 外観・傷・欠陥の画像判定 | 画像認識AI | 専用AIが必要 |
| センサー時系列の異常検知 | 異常検知AI | 本質的に苦手 |
| 予測・検知の結果を文章で説明 | LLM | 橋渡し役として有効 |
| ERPやDBからの情報取得・整形 | LLM（Function Calling） | 読み取りに限定すれば有効 |
本当に使える3つの領域
領域 1. 社内ドキュメントのQ&Aエージェント（RAG）
設備マニュアル・作業手順書・過去のトラブル対応記録——これらが共有フォルダに散在し、毎回ベテランに聞かないと動けない状態は多くの現場で共通課題です。
RAG（Retrieval-Augmented Generation）は、社内ドキュメントをベクトルデータベースに蓄積し、質問文と意味的に近い箇所を検索してLLMが回答する仕組みです。チャンクサイズの設計が意外と効いて、製造マニュアルでは**1チャンクあたり300〜500トークン（日本語で200〜350文字程度）**が目安です。大きすぎると無関係な情報が混入し、小さすぎると文脈が途切れて誤回答が増えます。セキュリティ要件が厳しい製造現場では、オンプレミスで完結するFAISS＋LangChainの構成が多くなります。
領域 2. 品質トラブル報告書のナレッジ化
不具合報告書や是正処置記録は毎日生成されますが、多くは書きっぱなしで過去データが活用されることはほとんどありません。LLMはこの非構造化テキストからパターンを抽出し、再利用可能な知識として再構成することが得意です。
ポイントは、LLMに「回答を作らせる」のではなく「証拠を引用させる」こと。システムプロンプトに「必ず参照元の報告書番号と該当箇所を明記すること」という制約を入れるだけで、ハルシネーション（事実でない回答の生成）を大幅に抑制できます。
領域 3. ERPと連携した自然言語ダッシュボード
「今週の第3ラインの稼働率は？」「この部品の在庫残と次回入荷予定は？」——こうした問いに答えるには、通常は複数のシステムを横断して情報を手動で集める必要があります。LLMエージェントをERPや生産管理システムのAPIと接続すると、自然言語の問いに対してシステムから情報を取得・整形して返す対話型のインターフェースを構築できます。これをLLMの「Function Calling（ツール呼び出し）」と呼びます。
注意点として、LLMに直接SQL文を生成・実行させる構成は本番環境では推奨しません。「LLMが呼び出せる関数の種類」をあらかじめ限定・定義した設計が前提です。呼び出せる関数を「在庫照会」「稼働率取得」などの読み取り専用に絞ることで、誤った命令がシステムに流れるリスクを排除できます。
LLMが本質的に苦手なこと
LLMの限界を把握せずに導入すると、大きな落とし穴にはまります。代表的な3点を整理します。
| 苦手な領域 | 具体的なリスク | 正しい対処 |
|---|---|---|
| 数値計算・統計処理 | 見た目は正しいが誤った計算結果を返すことがある | 計算は専用ツールに任せ、結果の説明にLLMを使う |
| リアルタイム制御 | APIの応答が1〜5秒かかり、ライン制御には不適 | 制御系とは切り離し、判断補助に限定する |
| 根拠なき回答（ハルシネーション） | 存在しないトルク値や架空の規格番号を自信を持って返す | RAGで参照先を社内DBに限定し、構造で防ぐ |
特に3点目は製造現場で深刻です。ある金属加工メーカーの検証で、汎用ChatGPTに「この設備の適正締付トルクは？」と質問したところ、実際のマニュアルとは異なる数値が自信を持って返ってきました。プロンプトへのお願いだけでは防げません。後述する設計原則で構造的に対処することが不可欠です。
設計で外せない3つの原則
1.ハルシネーションは「構造で防ぐ」
HIIIが採用している設計は3層です。まずチャンクに文書名・改訂日などのメタデータを付与し、回答時に「参照元：〇〇マニュアル 第3章」を必ず表示させます。次に、ベクトル検索で類似度が低いチャンクは取得しない設定を入れ、関連情報がない場合は「確認できません」と返すようにします。最後に、複数チャンクが取得された場合はRerankerで再スコアリングし、質問との関連度が高い上位のみをLLMに渡します。この3層の設計で「根拠なき回答」の発生率を大幅に下げることができます。
2.製造現場の「言語」をLLMに覚えさせる
「チョコ停」「ポカヨケ」「段取り換え」はLLMが正確に扱えないことがあります。社内の機種コード・ライン名・工程コードは当然未学習です。対策は2段階で行います。まずシステムプロンプトに製造用語の定義を埋め込みます（例：「チョコ停とは数分以内に自己復旧する短時間の設備停止を指す」）。次に、機種コード一覧・ライン名・工程コード体系などの「会社固有の辞書」をドキュメントとしてRAGに追加します。この2段階で、社内用語が飛び交う質問にも正確に答えられるようになります。
3.LLMを「最終意思決定者」にしない
製造現場ではAIの判断ミスが品質事故や設備破損に直結します。LLMはあくまで判断を補助するアシスタントであり、最終確認は人間が行う構造を維持することが基本です。特にLLMが社内システムに対して書き込み・更新を行う場合は、必ず人間の承認ステップを1段挟む設計にします。「LLMが生産指示を直接発行する」ような構造は現時点では推奨しません。読み取りと説明に特化させることが、安全と信頼を両立する現実的な選択です。
おわりに
「LLMを入れた」という報告が目標になった瞬間に、このプロジェクトは方向を誤ります。第3回・第9回で書いてきたことと同じように、「誰の、どの作業が、どう変わるか」を起点に逆算して設計すること——それだけで「試したけど使われなかった」との差が生まれます。
社内RAGの構築や品質ナレッジ化に具体的な課題をお持ちであれば、ぜひ一度お話しさせてください。データ前処理から実装・現場検証まで一気通貫でお手伝いします。