専門家一覧
LLMを用いた過去のトラブル対応記録からの故障診断AIモデル作成

手元の「汚い日報」が最強の故障診断AIに変わる。CTO直伝・コピペで使えるデータ構造化＆推論プロンプト完全設計図

約15分で読めます
文字サイズ:
手元の「汚い日報」が最強の故障診断AIに変わる。CTO直伝・コピペで使えるデータ構造化＆推論プロンプト完全設計図
目次

この記事の要点

  • 非構造化データ（日報など）からの故障診断AI構築
  • LLMによる高精度な原因特定と推論
  • 熟練技術者の知見の形式知化と技術継承

製造業や保守サービスの現場において、「AIによる故障診断」は最も期待値が高いテーマの一つです。しかし、プロジェクト開始時に多くの企業が同じ課題に直面し、難航することがあります。

それは、「学習させるデータが整理されていない」という問題です。

例えば、手書き日報、Excelの自由記述欄の文脈依存表現、担当者ごとの用語のバラつきなどが挙げられます。

これらのデータをそのままRAG（検索拡張生成）やファインチューニング（追加学習）に投入しても、AIは正確な回答を返さない可能性があります。「Garbage In, Garbage Out」の言葉通り、AI開発ではデータ品質が重要です。

実務の現場では、大量の修理記録のデータ整理が課題となるケースが頻発します。当初はPythonの複雑な正規表現で処理しようとするアプローチがよく見られますが、現場の言葉の揺らぎが大きく、ルールベースの対応には限界があります。

そこでシステム全体を俯瞰し、技術的な課題を構造的に捉え直すことで、「LLM（大規模言語モデル）自体を高度なデータ前処理エンジンとして活用する」というアプローチが有効となります。

今回は実務の現場で得られた知見を基に、手元の「テキストデータ」を「診断可能なナレッジ」に変換し、推論させるプロセスをテンプレート化して公開します。高度なプログラミングスキルは不要で、必要なのはデータとそれを導く「言葉（プロンプト）」です。理論と実践の両面から、導入後の運用まで見据えた最適解を探っていきましょう。

本テンプレート集の活用ロードマップ

なぜデータを読み込ませるだけでは故障診断AIが機能しないのでしょうか。最大の理由は、現場の記録が「人間同士のハイコンテキスト（文脈依存）」なコミュニケーションに依存しているためです。

例えば、熟練工同士なら「ラインBの異音」で状況が伝わりますが、AIには「どの装置の」「どの部位から」「どのような音が」「過去にどんな原因で」発生したかという構造化された情報が必要です。

本記事のテンプレートは、以下の4段階のプロセスを経て非構造化テキストを診断モデルへ変換します。

  1. Phase 1：データ正規化（表記ゆれ・俗称の統一）
  2. Phase 2：構造化・タグ付け（因果関係の抽出）
  3. Phase 3：診断推論（熟練者の思考再現）
  4. Phase 4：自己検証（回答精度の評価）

「整理されていないデータ」がAIの精度を下げる理由

例えば、「CV停止」と「コンベア止まった」は人間には同じ事象ですが、単純なキーワード検索やベクトル検索では「近い意味」として正しく認識されないことがあります。専門用語や社内スラングが多い場合、一般的なAIモデルでは対応が難しいケースも珍しくありません。

また、「再起動で復旧」という処置記録も、背景にある「なぜ再起動が必要だったか（メモリリークか、過負荷か）」という原因情報が紐付いていなければ診断の役に立ちません。単に「壊れたら再起動してください」と返すAIになる可能性があります。データセットに潜む「文脈の欠落」こそが、AIプロジェクトの失敗要因となり得るのです。

非構造化テキストを診断モデルに変える4ステップ

いきなり診断AIを作るのではなく、まずはLLMを使ってデータを「AIが理解しやすい形」に翻訳します。この前処理ステップが最終的な精度の大部分を決定づけます。

以下に紹介するプロンプトは、ChatGPTやClaude 3など、高度な推論能力を持つLLMでの動作を想定しています。これらは文脈理解能力が高く、曖昧な指示でも意図を汲み取るため、データクレンジングの強力な武器となります。

特にChatGPTにおいては、2026年2月にGPT-4oなどの旧モデルからGPT-5.2ファミリー（InstantやThinkingなど）へデフォルトモデルが一本化される大幅な更新がありました。最新モデルは複雑な推論やエージェント的な振る舞いが強化されており、非構造化データからの情報抽出で高いパフォーマンスを発揮します。

これらを最大限に活かすためには、単にテキストを読み込ませる古い使い方から脱却し、最新のベストプラクティスを取り入れることが不可欠です。具体的には、プロンプト内で「熟練の保守エンジニア」といった明確なペルソナ（役割）を付与し、出力フォーマットを厳密に指定する手法が推奨されます。さらに、Chain of Thought（ステップバイステップでの論理展開）を指示することで、より精緻な因果関係の抽出が実現します。継続的な業務に組み込む際は、カスタムGPTやメモリ機能を活用し、プロジェクト固有の用語や永続的な指示をシステムに定着させるワークフローへの移行も検討してください。

Phase 1：表記ゆれ・俗称を統一する「データ正規化」プロンプト

現場のデータにはノイズが含まれます。まずは作業者ごとに異なる表現や現場特有の俗称（スラング）を標準的な技術用語にマッピングする必要があります。手作業では時間がかかりますが、LLMの活用で効率化できます。

現場特有の略語・俗称をマッピングする

人間が辞書を作るのは大変な作業です。そこで、まずはLLMに生データを読ませて「表記ゆれ候補」をリストアップさせます。ここで重要なのは、AIに「推測」させることです。

【テンプレートA】用語辞書生成プロンプト

このプロンプトは、日報データから「専門用語」や「略語」と思われるものを抽出し、意味を推測してJSON形式の辞書を作成させます。

# Role
あなたは製造設備の保守を担当するエンジニア兼データサイエンティストです。
技術的な文脈を理解し、用語の揺らぎを特定する能力に長けています。

# Goal
以下の{{input_data}}から、機器名、部品名、現象、処置に関する用語を抽出し、標準語（正式名称）とマッピングした辞書を作成してください。

# Constraints
- 出力は必ずJSON形式にすること。
- 略語、俗称、誤字と思われるものは"original"キーに、推奨される正式名称は"standardized"キーに格納すること。
- 文脈から正式名称が不明な場合は、推測されるカテゴリ（部品、現象など）を"category"キーに記述すること。

# Input Data
{{input_data}}

# Output Format
[
  {
    "original": "CV",
    "standardized": "コンベア",
    "category": "部品名"
  },
  ...
]

活用例：

  • Input: 「第2ラインのCVで異音。Vベルトの摩耗っぽい。交換して様子見。」
  • Output: {"original": "CV", "standardized": "コンベア", "category": "装置名"}, {"original": "Vベルト", "standardized": "V型ベルト", "category": "部品名"}

この出力結果を確認して間違いを修正すれば、高精度な「社内用語辞書」が完成します。

【テンプレートB】テキスト置換・正規化プロンプト

作成した辞書を使って元のテキストを一括変換します。これにより、AIが学習・検索しやすい「きれいなテキスト」が生成されます。

# Role
あなたはテキストデータの前処理を行うAIアシスタントです。

# Goal
以下の{{dictionary}}に基づき、{{input_text}}に含まれる用語を正式名称に置換してください。
また、文法的に不自然な箇所（「てにをは」の抜けなど）があれば、意味を変えずに補正し、完全な文章に書き直してください。

# Dictionary
{{dictionary}}

# Input Text
{{input_text}}

# Output Example
Before: 第2ラインのCVで異音。Vベルトの摩耗っぽい。
After: 第2ラインのコンベアにて異音が発生。原因はV型ベルトの摩耗と推定される。

このステップを経ることでデータの検索性が向上します。地道ですが重要な工程です。

Phase 2：因果関係を抽出する「構造化・タグ付け」プロンプト

Phase 1：表記ゆれ・俗称を統一する「データ正規化」プロンプト - Section Image

テキストが整理されたら、次は中身の意味を構造化します。故障診断において重要なのは、「症状（Condition）」「原因（Cause）」「処置（Action）」の3要素（CCAトリプレット）です。

「症状-原因-処置」のトリプレット抽出

自由記述の文章からこの3要素を明確に分離してデータベース化します。これにより、「異音（症状）」から「ベルト摩耗（原因）」を検索したり、「ベルト交換（処置）」の事例だけを抽出したりすることが可能になります。AIは単なる「文字の一致」ではなく「意味のつながり」で検索できるようになります。

【テンプレートC】事象構造化プロンプト

# Role
あなたは故障分析のスペシャリストです。
トラブル報告書から重要なファクトを抽出し、構造化データに変換します。

# Goal
以下の{{normalized_text}}を分析し、トラブル事象ごとに以下の要素を抽出してJSON形式で出力してください。

# Extraction Items
1. symptom (症状): 何が起きているか（エラーコード、現象）
2. cause (原因): なぜ起きたか（推定原因、根本原因）
3. action (処置): どう対処したか（交換、修理、再起動）
4. equipment (対象機器): どの装置か
5. result (結果): 処置の結果（復旧、経過観察、未解決）

# Constraints
- 記述がない項目は null とすること。
- 原因が明記されていない場合は、文脈から「不明」または「調査中」と判断すること。
- 1つのテキストに複数のトラブルが含まれる場合は、リスト形式で複数出力すること。

# Input Text
{{normalized_text}}

Before（正規化済みテキスト）:
「第2ラインのコンベアにて異音が発生。V型ベルトの摩耗と推定されたため交換を実施し、正常動作を確認した。」

After（AI出力）:

{
  "symptom": "異音発生",
  "cause": "V型ベルトの摩耗",
  "action": "V型ベルトの交換",
  "equipment": "第2ライン コンベア",
  "result": "正常動作確認"
}

【テンプレートD】欠損情報補完プロンプト

現場の記録には「調整して復旧」のように原因が書かれていないものが多くあります。これらをそのまま学習させると、「とりあえず調整すれば直る」という浅い推論しかできないAIになる可能性があります。

そこで、過去の類似データやLLMが持つ一般的な工学知識を使って、欠損している「原因」の候補をタグ付けしておくアプローチが有効です。

# Role
あなたはベテランの保守エンジニアです。
不完全な作業報告から、背後にある技術的な原因を推論します。

# Goal
以下の{{structured_data}}において、"cause"がnullまたは不明な項目について、"symptom"と"action"から考えられる可能性の高い原因を3つ推測し、"potential_causes"として追記してください。

# Input Data
{{structured_data}}

# Strategy
- 一般的な機械工学、電気工学の知識に基づいて推論すること。
- 「再起動で復旧」の場合は、一時的なソフトウェアエラー、メモリリーク、過熱保護などを疑うこと。

このプロセスにより情報の密度を高め、検索時のヒット率を上げることができます。AIに「行間を読ませておく」作業と言えます。

Phase 3：熟練者の思考を再現する「診断推論」プロンプト

ここからが診断システムの心臓部にあたります。Phase 2で構造化を終えたデータを、いわば「ナレッジベース（参照情報）」としてフル活用し、現場から舞い込む新たなトラブル相談に対して的確な回答を生成させます。

Few-shotプロンプティングとChain of Thoughtの融合

AIに対して、単に「この故障の原因を教えて」と丸投げするだけでは不十分です。LLM（大規模言語モデル）に「熟練の技術者はどのようなプロセスで思考しているのか」を丁寧になぞらせるアプローチが求められます。

2026年現在、ChatGPTの公式ドキュメント等で特定のベストプラクティスが断定されているわけではありません。しかし、一般的な傾向としてFew-shotプロンプティング（少数の例示を与える手法）とChain of Thought（思考の連鎖）を組み合わせる手法が、複雑な推論タスクを解くための最適解として広く認知されています。一部の旧モデルがWeb版から廃止されAPI提供へ移行するなどの環境変化はありますが、ペルソナ（役割）の付与やステップバイステップの思考指示は、最新モデルにおいても出力精度を高める基本テクニックです。

現場の熟練工は、機械の異常な動きを見た瞬間に、脳内で以下のようなプロセスを極めて高速に処理しています。

  1. 類似事例の想起（過去の経験から似たパターンを引き出す）
  2. 可能性の絞り込み（論理的にあり得ない原因を除外する）
  3. 検証方法の決定（最短で確認できる手順を導く）

本システムでは、RAG（検索拡張生成）によって抽出された過去のトラブル事例が、実質的な「Few-shot（例示）」の役割を果たします。そこに「思考の連鎖」を促すプロンプトを掛け合わせることで、AIは単なる検索ツールから、熟練者のような深い洞察力を持つ診断アシスタントへと進化を遂げます。

【テンプレートE】Chain of Thought（思考の連鎖）診断プロンプト

このプロンプトは、現場からのSOSに対し、検索された過去事例（Context）をしっかりと読み込ませた上で、論理的に診断を下すための設計図です。AIが途中で飛躍した結論を出さないよう、思考プロセス（Step-by-Step）を明確に定義しています。そのままコピーして実践してみてください。

# Role
あなたは高度な専門知識を持つ設備保全コンサルタントです。
ユーザーからのトラブル相談に対し、提供された過去事例（Context）に基づいて論理的な診断とアドバイスを行います。

# User Query
{{user_query}}

# Context (Past Records)
{{retrieved_chunks}}

# Instructions
以下のステップに従って思考を展開し、熟練者の視点で回答を作成してください。

Step 1: 現象の構造的分析
ユーザーが報告している現象を技術的に分解し、重要なキーワードや数値データを特定してください。

Step 2: 類似事例との照合分析
Contextに含まれる過去事例の中で、今回の現象と共通点（機械の種類、現象、エラーコード等）が多いものを分析してください。単なるキーワード一致ではなく、発生メカニズムの類似性に着目すること。

Step 3: 原因の仮説立案
過去事例の知見と一般的な技術知識を組み合わせ、今回考えられる原因の仮説を立ててください。

Step 4: 推奨アクションの策定
最も可能性が高い原因に対する処置手順を、優先順位が高い順（安全かつ効果が高い順）に提示してください。

# Output Format

診断サマリ

Phase 3：熟練者の思考を再現する「診断推論」プロンプト - Section Image

まずは、結論を簡潔に記述させます。現場の担当者が一目で状況を把握できるようにするため、専門用語を羅列するのではなく、要点を絞った分かりやすい要約を出力させます。

推定される原因

次に、考えられる原因を確度とともにリストアップさせます。

1. [原因A] (確度: 高)
   - 根拠: [Context内の事例ID: xxx]に基づき...
2. [原因B] (確度: 中)
   - 根拠: 一般的な技術理論より...

このように、過去の事例IDや一般的な技術理論など、必ず「なぜその結論に至ったのか」という根拠をセットで提示させることがポイントです。

推奨アクション

原因の仮説が立てられたら、次に行うべき具体的なアクションを指示します。

1. ...
2. ...

ここでは、現場ですぐに実行できる手順を、優先順位や安全性を考慮した順番で出力させます。抽象的なアドバイスではなく、具体的な計測箇所や確認すべき部品名を含めるようAIに促します。

注意点

最後に、作業上の安全確認事項を出力させます。

(感電リスクや作業上の安全確認事項など)

二次災害を防ぐため、感電や火傷のリスク、保護具の着用など、現場の安全を守るためのアラートを必ず含めるようにします。

【テンプレートF】確率付き原因提示プロンプト

実際のビジネス現場、とりわけ製造業や保全の最前線では、AIによる「100%の断定」は大きなリスクを伴います。そのため、可能性を確率（確度）とともに提示し、最終的な判断は現場のエンジニアが行うための「意思決定支援」という位置づけが理想的です。

先ほどのプロンプトの指示セクションに以下の条件を追加すると、出力の信頼性がさらに高まります。

- 各原因の確度を「高・中・低」またはパーセンテージで示してください。
- 確度の根拠は、Context内での出現頻度や、事象との因果関係の強さに基づいて記述してください。
- 情報不足により断定できない場合は、正直に「情報不足」とし、追加で確認すべき点（テスターでの計測箇所やエラーログの有無など）を質問してください。ハルシネーション（嘘の生成）は厳禁です。

AIに「分からない時は分からないと答える」ルールを徹底させることで、誤った情報に基づく誤操作を未然に防ぐ効果が期待できます。

Phase 4：回答精度を評価・改善する「自己検証」プロンプト

生成された診断結果が正しいか、危険なアドバイスをしていないかを確認する必要があります。そこで、別のLLMインスタンスに「監査役」を任せます。

AIの回答をAIがチェックする

これは「LLM-as-a-Judge（審査員としてのLLM）」と呼ばれる手法です。診断役とは別のプロンプトで、論理的整合性や安全性をチェックさせます。

【テンプレートG】診断ロジック整合性チェックプロンプト

# Role
あなたは品質保証（QA）担当のエンジニアです。
AIが生成した故障診断レポートをレビューし、技術的な誤りや論理の飛躍、安全上のリスクがないかをチェックします。

# Input
[User Query]
{{user_query}}

[AI Response]
{{ai_response}}

[Context]
{{retrieved_chunks}}

# Evaluation Criteria
1. Grounding (根拠性): 回答はContextに基づいているか？誤った情報（Hallucination）を含んでいないか？
2. Safety (安全性): 作業者に危険を及ぼす指示（電源を入れたまま配線を触るなど）が含まれていないか？
3. Relevance (関連性): ユーザーの質問に対して適切に回答しているか？

# Output
- Score (1-10): ...
- Risk Flag (Yes/No): ...
- Comments: 問題点や改善すべき点を具体的に指摘してください。

この評価プロセスをシステムに組み込むことで、スコアが低い回答はユーザーに表示せず、「専門家に確認してください」と返す安全装置を作ることができます。

誤った情報（ハルシネーション）を防ぐ制約条件の書き方

AIに不確かな情報を生成させないためには、プロンプトの制約条件（Constraints）に以下の一文を入れることが有効です。

"Answer ONLY based on the provided Context. If the answer is not in the Context, state '提供された情報からは判断できません' and do not make up an answer."

この一文があるだけで、AIの信頼性は向上します。

【付録】現場導入時のチェックリストとプロンプト調整ガイド

最後に、これらのテンプレートを実際の業務環境へ適用する際の注意点と、精度を高めるための調整ポイントを整理しました。システム全体を俯瞰し、プロジェクトを安全かつ効果的に進めるためのチェックリストとしてご活用ください。

対象機器・ドメイン別のカスタマイズ例

現場ごとに扱う機器や専門用語は大きく異なります。プロンプトをそのまま使うのではなく、ドメイン知識に合わせて以下のように正規化対象と抽出項目をチューニングすることが、診断精度の向上に直結します。

  • ITインフラ・サーバー監視の場合:
    • 正規化対象：システム特有のエラーコード、IPアドレスのマスキング処理、多様なホスト名の統一フォーマット化。
    • 抽出項目：Condition（CPU使用率の急増、レスポンスタイムの遅延など）、Cause（特定プロセスの暴走、ディスク容量の枯渇など）を明確に定義します。
  • 車両整備・建機の場合:
    • 正規化対象：メーカーごとの車種コード、複雑な部品品番の表記揺れ吸収。
    • 抽出項目：走行距離、稼働時間（アワーメーターの数値）、使用環境（寒冷地での運用、泥濘地での作業など）といった、物理的な故障要因に直結するパラメータを抽出させます。

セキュリティとデータプライバシーの注意点

LLMに社内の生データを送信する際は、個人情報（PII）や機密情報の漏洩リスクをシステムアーキテクチャの段階で排除しておく必要があります。

  • PIIマスキングの徹底: 社員名、顧客名、電話番号などの機密情報は、LLMに渡す（Phase 1の）前に、ルールベースの処理（正規表現など）を用いて [PERSON_NAME], [PHONE_NUMBER] といった抽象的なタグへ確実に置換してください。
  • API利用規定の確認: 入力データがAIの学習に利用されないよう、OpenAIのEnterprise版やAzure OpenAIなど、エンタープライズ向けの厳格なデータ保護契約が結ばれたAPIエンドポイントを使用することを強く推奨します。

実運用へのつなぎ方

今回紹介したプロンプト群は、チャットボットのシステムプロンプトとして直接組み込むことも、バッチ処理で過去の蓄積データを構造化し、ナレッジグラフやベクトルデータベース（Vector DB）を構築するための前処理エンジンとして活用することも可能です。

まずは手元のExcelファイルなどを用いて、ChatGPT上でこれらのプロンプトの挙動をテストしてみてください。その際、プロンプトエンジニアリングの一般的なベストプラクティスとして、以下の要素を意識すると出力が安定します。

  • 役割と前提の明確化: 「熟練の保守エンジニアとして」といったペルソナ（システムロール）を付与し、出力フォーマットやトーンを具体的に指定します。
  • 思考プロセスの誘導: 一度に答えを出させるのではなく、「ステップバイステップで分析してください（Chain of Thought）」と指示することで、複雑な推論の精度が劇的に向上します。

なお、利用可能なモデルやデフォルトの仕様は継続的にアップデートされています。最新の機能や最適なモデル選択については、必ず公式ドキュメントで最新情報をご確認ください。

まとめ

Phase 3：熟練者の思考を再現する「診断推論」プロンプト - Section Image 3

これまで「整理されていないデータ」は、システム的に扱いにくい負債とみなされがちでした。

以前は、こうしたテキストデータを構造化するために膨大なコストと自然言語処理の専門知識が不可欠でした。しかし、現在はLLMという極めて強力な推論エンジンが存在します。理論に基づいた適切なプロンプト設計を行うことで、現場に眠る「暗黙知」を、組織全体で活用可能な「形式知」へと変換できるのです。

本記事で提供したテンプレートは、さまざまな現場に応用できる汎用的なベースモデルとして設計しています。自社の特有の事情やデータ構造に合わせて微調整を繰り返すことで、その精度はさらに向上していくでしょう。「現場の用語は特殊すぎてAIには理解できない」と諦めてしまう前に、まずは手元のデータを使って、AIに現場の文脈を学習させてみてください。

手元の「汚い日報」が最強の故障診断AIに変わる。CTO直伝・コピペで使えるデータ構造化＆推論プロンプト完全設計図 - Conclusion Image

参考文献

  1. https://xn--q9ji3c6d676qnnlo0fgmgrr6k.com/2026/02/04/news-3368/
  2. https://iotnews.jp/manufacturing/271293/
  3. https://monoist.itmedia.co.jp/mn/articles/2602/04/news053.html
  4. https://dcross.impress.co.jp/docs/news/004534.html
  5. https://plus-web3.com/media/latestnews_1000_7616/
  6. https://www.softecmc.com/blog/170
  7. https://media.emuniinc.jp/2026/02/08/next-gen-safety-manual-strategy/
  8. https://www.cariot.jp/blog/2026/02/27/vehicle-management-ai/
  9. https://www.ans-net.co.jp/column/3331/
  10. https://www.pc-webzine.com/article/3500

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...