「軸受けから異音。点検後に交換」「モーターが熱いので止めた」「再起動で復帰」。工場の保全作業票には、こうした短い自由記述が蓄積します。作業の様子は伝わっても、設備別の故障件数や再発箇所を比較しようとすると、同じ現象が異なる名前で記録され、原因と処置が混ざりがちです。製造業の保全履歴と故障コードをAIで標準化する導入では、文章を一括で分類する前に、設備台帳、コード体系、記録時点、人が確定する範囲を決める必要があります。本稿はタイ工場を想定し、自由記述から「問題・損傷」「原因」「処置」の候補を出し、保全担当者の確認を経てCMMSへ登録する設計を解説します。
まず決めるべき成果物は「分類済み履歴」ではなく「再利用できる判断」
故障コードを入力させる目的は、コード欄を埋めることではありません。似た停止が何度起きたか、どの設備群に偏るか、同じ症状でも原因が違うか、どの処置後に再発したかを、担当者が後で確かめられる状態にすることです。自由記述は現場の状況を豊かに伝えます。一方、表記、言語、略語、書く順番が揃わないため、集計キーには使いにくい。構造化コードと原文を併存させれば、比較可能性と現場の文脈を両立できます。
たとえば「搬送モーターが止まり、熱い。端子を締め直して復帰」と書かれた票から、問題として「停止」を候補にし、損傷として「過熱」を候補にし、処置として「端子締付」を候補にすることはできます。しかし「端子の緩みが根本原因だった」と断定するには、測定値、点検所見、再発確認など追加の根拠が要ります。AIが文中の因果らしいつながりを読んでも、作業者が見ていない事実まで発見したことにはなりません。原因欄は「未確認」を許し、確認後に追記する運用が必要です。
この用途は、故障後の根本原因分析そのものとも異なります。根本原因分析は事象の時系列、設備設計、運転条件、人の作業、管理上の要因を掘り下げます。本稿のAIは既存記録を検索・比較しやすくする入力支援です。コードが付いたから分析が終わったわけではありません。
既存の保全AIと境界を分ける
「保全AI」と一括りにすると、評価する場面がずれます。保全依頼の振分けは、依頼をどの担当や優先度に回すかを決める入口の機能です。作業報告書のAI下書きは、実施した作業を読みやすい文にまとめる機能です。金型履歴のOCRは、紙や画像の文字を読み取る機能です。故障後の根本原因分析は、原因仮説を検証する調査です。今回扱うのは、作業票に記録された事実を、設備に適したコード候補へ写像する工程です。入力形式、正解の作り方、受入試験がそれぞれ違います。
保全依頼をCMMSへ入れる経路と台帳の粒度を決める段階なら、先に設備保全システムの選び方を参照してください。報告本文の作成・承認を整えたい場合は保全作業報告書のAI下書きが隣接するテーマです。両方を導入する場合でも、文章生成の合否とコード選択の合否は別に検収します。
故障コードは設備と文脈に結び付けて設計する
SAPの保全通知では、損傷、原因、作業、タスクをコードで記録し、技術的な所見を標準化して評価できるようにします。カタログプロファイルは参照対象や通知タイプに適切なコード群を絞る考え方です。IBM Maximoは、故障クラスの下に問題、原因、処置の階層を構成し、設備や場所と結び付けて選択します。両製品の用語と実装は同一ではありません。本稿では両者の共通する設計原則、すなわち「設備に適した候補だけを出す」「問題、原因、処置を混同しない」を使います。SAPの通知コード、IBMの故障階層で製品固有の仕様を確認できます。
ISO 14224は、石油・石油化学・天然ガス産業の設備信頼性と保全データの収集・交換を対象とする規格です。設備、故障、保全の情報を分けて記録する参照例として有用ですが、一般の製造工場へそのまま義務として適用されるわけではありません。食品、樹脂成形、組立工場などでは、自社の工程・設備・CMMSの仕様を優先して語彙を設計します。ISO 14224の適用範囲を確認したうえで、参考にする層だけを選びます。
最初に全工場共通の巨大なコード表を作ると、選択肢が増えすぎます。ポンプの「漏れ」、搬送機の「蛇行」、成形機の「型締め不良」は同じ意味の箱へ押し込められません。設備階層を工場、ライン、設備、必要ならユニットまで定義し、どの階層で記録するかを決めます。故障クラスやカタログプロファイルで候補を絞り、共通コードと設備固有コードを分けます。コード名は現場語と管理語を並記し、別名辞書でタイ語、英語、日本語の言い換えを吸収します。
「問題・損傷」「原因」「処置」を別々に確定する
問題は現れている状態や機能の喪失、損傷は対象部位に認めた状態、原因はその状態が生じた理由、処置は実施した作業です。工場のCMMSによって項目名は異なります。大切なのは、観察したこと、推測したこと、実施したことを同じ欄へ押し込めないことです。「異音」は観察された問題、「ベアリング摩耗」は分解・測定で確認した損傷または原因、「ベアリング交換」は処置です。「交換したから摩耗していたはず」という逆推論をAIの確定値にしません。
一枚の票に複数の現象がある場合もあります。ポンプの振動が増え、シールから漏れ、停止したなら、どれが主事象で、どれが結果かを人が決めるべきです。コード体系が一票一コードしか許さないなら、主問題だけをコード化し、副次現象は原文・追加属性へ残します。複数行を許すなら、イベントIDで関連付けて二重件数にならない集計規則を作ります。この規則がなければ「1故障が3件」に増えることがあります。
原因が未確認の票を無理に「その他」へ集めると、後で原因不明率を測れません。「未調査」「調査中」「判定不能」「該当コードなし」は意味が違います。未調査はまだ着手していない状態、調査中は結論待ち、判定不能は必要資料が得られなかった状態、該当コードなしはマスタ改訂の候補です。この区別はAIを導入した後の改善を支えます。
処置は「交換」「調整」のような動詞だけでは粗すぎます。部品、対象ユニット、復旧確認を別属性として残し、コードは比較したい粒度へ合わせます。一方、使った工具の型番までコードに含めると数が膨らみます。部品番号や作業時間は別フィールドへ入れます。コード表の設計会議では、月次で見たいグラフを先に描き、そのグラフに必要な区別だけをコード化します。
自由記述をAIへ渡す前のデータ点検
入力票を少数サンプルで読めば、自由記述が本当に分類に足りるか分かります。設備ID、設備種類、発生日時、作業開始・終了、作業者、症状、確認した損傷、原因根拠、処置、復旧確認がどの欄にあるかを点検します。票が「完了」だけなら、AIの性能以前に記録設計を直す必要があります。過去記録を一律に補完したように見せず、根拠が欠けた行は未確定のまま移します。
文字の前処理では、改行、日付表記、全半角、設備の別名、タイ語と英語の混在を扱います。略語は現場で一義的な場合だけ辞書化します。たとえば「BRG」が軸受けを指す工場でも、別拠点の別略語まで同一視しません。原文、正規化後の文、辞書バージョンを残すと、誤分類の原因を後から追えます。個人名や連絡先など分類に不要な情報は入力から除くかマスクし、データ利用範囲を決めます。
故障コードの過去値を教師データとして使う前に、入力時期を確認します。古いコード表に属する行、担当者によって意味が違った行、暫定コードを入れた行を「正解」として混ぜると、AIが旧運用を学び直します。設備とコードの対応関係を確認し、複数の保全担当者で曖昧な票を再ラベルします。意見が割れる行は正解を無理に一つへ決めず、争点を記録します。人でも決まらない票はAIにも確定させません。
タイ工場ではタイ語の作業票に英語の部品名、日本語の設備呼称、メーカーのアラーム表示が混在することがあります。まず原文言語を残し、翻訳を通すなら原文へ戻って照合できるようにします。コード名の多言語訳は、直訳より設備の意味が通る現場用語を優先します。同じ語が異なる設備では別の故障を指す場合があるため、単語単位の辞書だけで設備文脈を消さないことが重要です。
AIの入力と出力を小さく設計する
試行段階のAIには、作業票の自由記述だけでなく、設備IDから解決した設備クラス、候補として許されたコード表、必要な作業時点を渡します。関連しない工場の履歴まで広く検索すると、似た文章でも異なる設備のコードを提案しかねません。参照する過去票は設備クラス、設備型式、故障箇所などで絞り、古い承認済み履歴か暫定履歴かを区別します。
出力は、問題または損傷コードの候補、原因コードの候補、処置コードの候補、原文の根拠箇所、候補にできなかった理由、確認が必要な質問を分けます。コードIDは許可リストからのみ選ばせ、存在しないコードを作らせません。候補と原文根拠を同じ画面で見せ、担当者が「採用」「別コードへ変更」「未確定」「マスタ改訂依頼」を選べるようにします。AIの自信らしい数値だけで自動確定する設計は避けます。数値の校正を確認する前には、しきい値へ安全上の意味を持たせられないからです。
「原因は端子緩み」と書かれた報告と、「端子を締めたら動いた」だけの報告は違います。前者にも測定や再現の根拠が要る場合がありますが、後者は処置結果から原因を推測しているだけです。AIは確度に応じて「原因候補」「未確認」と示し、点検者に質問を返すべきです。入力不足を文章生成で隠すより、何が欠けるかを可視化した方が保全データは良くなります。
人が確認する画面と責任の分け方
確認画面は、原文、設備階層、故障クラス、許可されたコード候補、候補理由、採用後のCMMS項目を一画面で比べられる形にします。原文を隠して提案コードだけ示すと、担当者は見落としを確認できません。設備名が似ていても設備IDが異なる場合、AIが過去票を取り違えた場合、コードの意味が更新された場合を人が見抜けるようにします。作業者が現場で選ぶのか、班長が承認するのか、信頼性担当が月次に見直すのかを明確にします。
人が毎回最初からプルダウンを探すなら負担は減りません。AIが上位候補を提示し、コードの短い定義と典型例、対象設備を表示します。反対に「採用」ボタンだけが大きいと惰性承認が起きます。主要な見落としがないかを確認するチェック項目と、未確定を選べる導線が必要です。作業終了直後に確定できるのは問題と処置までで、原因は後日の解析で確定する運用でも構いません。
コードの最終責任は保全組織に残します。AIモデルや外部ベンダーを使用しても、コード表の所有者、改訂承認者、誤登録の訂正者、監査ログの保管者を決めます。NIST AI Risk Management FrameworkのCoreは、AIリスクをGovern、Map、Measure、Manageで扱い、導入前後の評価と文脈に沿った解釈を求めます。これを特定製品の認証要件だと誤読せず、候補提示と人の確認をどう評価・監視するかの設計材料として使います。NIST AI RMF Core
CMMSへの連携はコードID・版・監査証跡まで決める
候補が正しくても、CMMSへの書込みで別の設備や旧コードに紐付けば使えません。連携仕様には、作業票ID、設備ID、イベント日時、問題・損傷・原因・処置のコードID、コード表バージョン、承認者、承認時刻、原文への参照を含めます。人が承認する前は下書き領域へ保持し、本番履歴へ自動書込みしない方式を基本とします。CMMSが原文、コード、複数事象、未確定値をどう扱うかを先に確認します。
SAPでは通知の損傷、原因、作業などのカタログと、参照対象に応じたカタログプロファイルの設定が関わります。IBM Maximoでは故障クラスとその問題・原因・処置階層が選択肢を制約します。製品間のコードIDを単純に同じ文字列へ変換できるとは限りません。たとえばSAPの「作業コード」をMaximoの「処置」に移す場合、意味、粒度、対象設備を人が対応付ける必要があります。導入前にサンプル票を使って、画面上の候補から実際のCMMSフィールドまで通しで確認します。
失敗した書込みは再試行できるようにし、作業票IDと承認版を冪等キーにします。同じ承認結果を二回送って二つの故障イベントを作らないためです。後からコードを訂正した場合は、元値、訂正値、理由、担当者、時刻を残します。コード表を改訂しても過去の報告書の意味が変わらないよう、発生当時の版か履歴化したマッピングを参照できる設計が必要です。連携停止時に現場がどう入力を継続するかも決めます。
小規模なパイロットをどう切るか
全工場の過去票を一度にAIへ投入するより、設備群を一つ選び、代表的な故障と長尾の例を含む期間を決めます。対象設備の故障クラスが整っているか、作業票に原因と処置が別々に残っているか、担当者がレビュー時間を確保できるかを確認します。初期パイロットの範囲は「設備の種類」「票の言語」「入力経路」「CMMSの対象フィールド」で明記します。異なる設備を混ぜて平均値を出すと、どの設備で使えるか分かりません。
人手で作った評価用データは、開発に見せる例と検収用に伏せる例を分けます。最近の票だけでなく、季節、シフト、設備更新前後、故障が少ない型式を含めます。特定の故障が多すぎると「全部同じコード」を選ぶモデルが見かけ上よく見えるため、希少だが重要な事象を別集計します。低頻度で重大な故障は、分類率ではなく見逃し時の確認手順を重点的に決めます。
最初の運用は「AI候補を表示するが、書込みは人が承認する」に固定します。承認画面で、提示された候補が使われたか、訂正されたか、未確定へ戻されたか、設備外コードが出たかを記録します。モデル改善を急ぐ前に、コード表の欠陥、元票の不足、連携設定の誤りを分けます。たとえば「原因候補が当たらない」の背景が、現場で原因欄を書かない運用なら、モデルだけを替えても改善しません。
受入基準は正答率一つにしない
検収では、問題・損傷、原因、処置を別々に採点します。設備クラス外のコード提案件数、存在しないコードの提案件数、原因未確認なのに断定した件数、必要情報が欠けた際に保留できた割合を見ます。作業者が訂正に要する時間と、原文確認に要する時間も測ります。「上位3候補に正解がある」だけでは、画面が使いにくければ実際の入力は速くなりません。事前に合意した正解と採点規則で、設備別・言語別・作業種別に結果を出します。
たとえば評価用に100票を用意し、そのうち20票は原因を判断する根拠が不足しているとします。この20票で原因を推測して付けた割合と、正しく未確定へ回した割合を別々に報告します。数字は試験設計の例であり、製品の実績値ではありません。残る80票も、担当者の合意があるコードだけを正解とします。複数の妥当なコードがあるなら、コード表の粒度を見直すか、許容集合を事前に決めます。検収の途中で正解をモデルに合わせて変更しません。
導入後は、採用率だけを成果にしないことが重要です。承認者が全件そのまま採用すれば採用率は高くても、誤分類が残る可能性があります。月次でサンプル監査を行い、設備別の訂正率、未確定率、原因断定ミス、コード表にない事象の件数を追います。設備や製品構成が変わったときは、古い評価結果を再利用せず再検証します。NISTが示す導入前の検証と運用中の監視という考え方を、この現場の作業フローへ落とし込みます。
RFPに書くべき質問
ベンダーへ依頼する際は「AIで保全履歴を自動分類」とだけ書かず、以下を提示します。対象設備群と設備階層、既存のコード表と改訂履歴、入力票のサンプルと言語、データ品質上の欠損、CMMS製品と連携方法、誰がどの時点で承認するか、受入試験で使う伏せた票の条件、運用後の訂正・再学習の責任分界です。外部へ渡せない情報があるなら、設備名や作業者名のマスキング方法と評価環境を指定します。
見積の比較では、モデル利用料だけでなく、設備台帳の整備、コード表設計、既存票のクリーニング、アノテーション、CMMS API連携、承認画面、多言語辞書、監査ログ、運用サポートを分けて見ます。同じ「AI導入費」でも、どこまでをベンダーが実施するかによって成果物は変わります。候補提示の精度を保証する条件も、入力の欠損率、対象設備、評価票の構成と一緒に記述してもらいます。
提案デモでは、きれいな一文だけでなく、「設備ID誤り」「原因不明」「タイ語と英語混在」「複数の症状」「旧コードが本文に書かれている」「処置はあるが復旧確認がない」といった票を見せます。想定外の票に対して、AIが別の設備クラスのコードを自信満々に出すか、保留と確認事項を示すかが重要です。デモの結果をそのまま本番性能とみなさず、伏せた評価票で再現します。
導入後の運用でコード表を育てる
コード表は一度作って終わりではありません。新しい設備、部品、故障モードが入れば、既存コードに無理に合わせず改訂の要否を審査します。改訂の提案者、承認者、適用日、旧コードとの対応、過去履歴の見せ方を決めます。表記ゆれの辞書は現場から提案を受け、同義語と似て非なる語を区別します。辞書を無制限に増やすと、別の設備の用語が誤って結び付くので、設備クラスと工場の適用範囲を持たせます。
保全担当者の訂正結果をそのまま次の教師データへ流す前に、訂正の理由を見ます。コードを押し間違えたのか、元票を読み違えたのか、コード表に正しい選択肢がなかったのかで対策が違います。理由を月次で確認し、票の入力フォーム、コード表、AIの候補順位、CMMSマッピングのどこを変えるか決めます。新しいモデルやプロンプトを投入するときも、同じ伏せた評価票で比較し、悪化した設備群を見落とさないようにします。
原因コードの品質は、保全組織の調査習慣に依存します。原因を毎回記入させるために推測を固定化するより、未確認を明示し、後日の点検や再発調査で更新できる運用にします。故障件数の集計では、未確認とその他を分けて示します。未確認が増えたならAIの失敗とは限らず、以前は推測で埋めていた欄が正直になった可能性もあります。数値の変化はサンプル票を読んで解釈します。
現場票をコードへ変える具体例
架空の搬送ラインを例に、実際の画面遷移を考えます。設備台帳には「ライン三の搬送モーター」と「ライン四の排出モーター」が別IDで登録され、前者にだけ軸受け、ベルト、端子台の候補が紐付きます。作業票の原文は「朝番でキュルキュル音。軸受け周りが熱い。止めて給脂、試運転で音は低下。午後も様子を見る」だとします。AIは設備IDを先に確認し、その設備に許された問題コード「異音」、観察状態「温度上昇」、実施処置「給脂」を候補にします。「軸受け摩耗」はあり得ても、原文に測定や分解の結果がないため、確定原因としては登録しません。画面には「原因未確認。軸受けの点検結果はありますか」と表示します。
作業者は音が低下した事実を見て、問題と処置を承認します。点検前なら原因は未確認のままにします。翌日、点検で軸受けに損傷が見つかれば、承認履歴を持つ保全責任者が原因欄を更新します。この流れなら最初の報告を待たせず、後から調査結果を付けられます。反対に、AIが「給脂で改善したから潤滑不良が原因」と自動記入すると、軸受け損傷や芯ずれを調べる契機を失うかもしれません。人の確認は単なる形式ではなく、観察と推測の境界を守るためにあります。
別の票で「ライン四の排出が遅い。センサー清掃、復旧」と書かれていれば、同じ「遅い」という語でもライン三のモーター用コードを候補にしません。設備IDが欠けていたら、設備を推測して登録するより、作業者に設備選択を求めます。複数設備にまたがる停止では、停止を生んだ設備と影響を受けた設備を分け、イベントIDで関連付けます。設備台帳を通らない文章分類は、ここでの誤りに気づきにくいのです。
データ移行時に起こりやすい三つのずれ
一つ目は時点のずれです。保全依頼を出した時の症状、現場到着時の観察、修理後の処置、後日の原因調査は、同じ作業票に追記されることがあります。最終版だけをAIへ渡すと、故障発生時点では分からなかった原因を、当初から分かっていたように扱う恐れがあります。元票の作成・更新履歴を保持し、コードの確定時刻を記録します。時系列を失った古い票は、原因の確定評価から除外する判断も必要です。
二つ目は設備粒度のずれです。紙の票には「包装ライン」とだけ書かれていても、CMMSにはラベラー、コンベヤ、シーラーが別設備として登録されているかもしれません。行を一括でラベラーへ寄せると、ラベラーの故障件数が膨らみます。設備IDが決められない票はラインレベルへ置くか、移行対象から外し、曖昧さを可視化します。後から分析する人が粒度の違いを知らなければ、同じグラフで比較してしまいます。
三つ目はコード意味のずれです。以前は「電気故障」という広いコードに端子緩みもインバータ異常も入れていたのに、新体系では二つを分ける場合があります。原文が十分なら新体系へ再分類できますが、証拠がない行を新コードへ機械的に割り当てることはできません。旧コードのまま保持し、集計では旧新の対応表と不明分を示します。過去と現在の件数をつなぐために、根拠のない細分化をしないことが大切です。
数値で見るなら分母と除外条件を揃える
導入効果を測る前に、比較対象の票を決めます。たとえば月に三百件の保全票があり、そのうち設備IDが明確で、対象設備群に属し、本文がある票が二百件なら、候補提示率の分母はまず二百件です。残り百件を黙って除くと全工場で使えるように見えます。逆に、対象外設備まで分母に入れるとパイロットの評価が不当に低くなります。この三百件、二百件は計算方法を示す仮定の数字であり、TOMAS TECH製品や他社製品の実績ではありません。
人の確認にかかる時間も、コード選択だけで測りません。票を開き、設備と原文を確認し、候補を選び、原因を保留し、CMMSへ保存するまでの一連の時間を測ります。従来の入力が紙に後書きだった場合は、紙の転記と訂正の時間も含めます。時間削減だけを狙って確認を省くと、後日の分析や是正に余計な時間を使う可能性があります。初期の評価では「省力化」と「履歴の信頼性」を別の指標として扱います。
正答率を出す場合は、問題、原因、処置それぞれの分母を示します。問題コードを付けられる票でも、原因が分からない票はあります。原因の正答率から未確認票を除いたなら、その件数と理由を報告します。未確認票で適切に保留できた割合は別に測ります。言語別の結果では、タイ語で記録された票を英語へ翻訳して評価したのか、タイ語のまま評価したのかを明記します。この条件が変われば、数字の横比較はできません。
現場への説明と教育を設計に含める
現場に新しいコード入力をお願いするとき、「AIが正しいコードを決める」と説明すると、判断責任が曖昧になります。作業者には、AIが原文から候補を探すこと、候補は間違うこと、観察していない原因は確定しないことを具体例で示します。班長には、未確定を残す判断が悪い評価にならないことを共有します。管理者には、コードの増減が記録方法の変化でも起こることを説明します。教育資料には、良い作業票と悪い作業票の抽象例だけでなく、自社設備に似た許諾済みの例を入れます。
多言語環境では、画面を翻訳しただけで理解が一致するとは限りません。「損傷」「原因」「処置」の意味と入力時点を、タイ語、日本語、英語で同じ作業例に沿って確認します。作業者がある語を機械の症状として使い、管理者が部品損傷として使っているなら、まずコード定義を合わせます。翻訳の精度をAIだけの問題にせず、現場の語彙を持つ保全担当者に確認してもらいます。
パイロット後の振り返りでは、採用された候補だけでなく、候補が役に立たなかった票を読む時間を取ります。情報不足で保留した票が増えれば、入力フォームの設問を変える方がモデル変更より効くかもしれません。設備外コードが多ければ、設備台帳や故障クラスの関連付けが原因かもしれません。作業者が候補理由を読まずに承認しているなら、画面配置と承認権限を直します。現場の行動まで観察して初めて、コード標準化の運用が定着します。
設備の分類を細かくしすぎないことも教育の一部です。現場が迷う選択肢を放置したままAIだけに判定させると、担当者は提案を承認するしかなくなります。よく迷う二つのコードについては、境界条件と代表例を短く書き、票の原文から判断できないときは保留を選ぶ規則を共有します。正しい保留は品質の低い記録ではなく、未確認の事実を守る記録です。
原因が後から判明する作業票の扱い
保全記録は一度の入力で完成するとは限りません。夜間に設備が止まり、当直者が「異音と停止」を記録し、朝の担当者が部品を交換し、数日後の分解で摩耗原因が分かることがあります。この三つの時点を一つの完成文へまとめてしまうと、初動で把握できた情報と後日の調査結果を区別できません。問題コードは観察時、処置コードは作業完了時、原因コードは調査の承認時に確定する設計が適切です。原因が分からない間は未確認の状態を残し、AIにもっともらしい原因を埋めさせません。
作業票が再開されたとき、AIは既存の承認値を勝手に上書きせず、追加された文章だけを差分として示します。担当者は新しい点検結果が以前の原因候補を裏付けるか、別の原因へ変えるべきかを判断します。変更画面には、元のコード、提案コード、原文の追加箇所、変更理由、承認者を並べます。こうしておけば、後日の分析で「いつ何を知っていたか」を再現できます。原因の確定日と設備停止日を混同しないため、集計時にはどちらの日付を使ったかも明記します。
別の作業票で同じ設備の停止が再発した場合、それを前の票への追記にするか、新しい故障イベントにするかを決める必要があります。試運転中の再停止と、いったん復旧し数週間後に生じた停止では扱いが異なります。イベントを分ける規則は運転再開の確認、停止間隔、作業票の締結状態などに基づいて現場が合意します。AIが文章の類似だけで二件を一件にまとめると、再発回数が見えなくなります。逆に一件の継続作業を二件に割れば、故障頻度を大きく見せてしまいます。
コード表の改訂後も、この履歴は残します。旧コードを新コードへ読み替える場合には、単純な一対一対応なのか、旧コードを複数の新コードへ分割したのかを区別します。後者は原文に根拠がない限り自動変換できません。過去の票を確定済みの新コードであるかのように表示せず、元のコードと現在の集計用対応を分けて保持します。こうした時点と版の管理は地味ですが、保全履歴を改善活動へ使う際の信頼性を左右します。
よくある質問
保全履歴の故障コードをAIで完全自動登録できますか？
コード候補の作成と形式チェックは自動化できます。ただし設備の取り違え、元票の欠損、原因を裏付ける情報の不足があるため、本稿の推奨は人が原文と候補を確認してからCMMSへ確定登録する方式です。低リスクの定型票を将来さらに自動化する場合も、対象を限定し、誤登録の訂正経路と監査を用意してから判断します。
既存のコード表がない場合、AIから始められますか？
自由記述を眺めて候補語を抽出する補助には使えます。しかし最終的なコードの定義、設備ごとの適用範囲、原因と処置の区別は保全担当者が決めます。まず一つの設備群で現場票と月次集計の目的を照合し、小さいコード表を作ります。AIはその表へ写像する役割を担います。
タイ語、日本語、英語が混在する票にも対応できますか？
可能性はありますが、対象言語を明記した試験が必要です。原文を保持し、設備略語、部品名、翻訳で意味が変わる語を評価票に含めます。言語別に正答と保留を集計し、英語だけの試験結果をタイ語票へ外挿しません。多言語のコード表示も現場の担当者に確認してもらいます。
保全AIの費用は何で変わりますか？
対象設備の種類と件数、コード表の状態、過去票の品質と件数、必要な多言語対応、CMMSとの連携方式、承認画面、評価・運用体制で変わります。モデルの単価だけで比較せず、台帳とコードの整備、正解データ作成、実運用の訂正まで含めた見積範囲を揃えてください。
ISO 14224に準拠すれば製造業の故障コードは完成しますか？
ISO 14224の対象は石油・石油化学・天然ガス産業です。設備、故障、保全情報を分ける考え方は参考になりますが、一般製造業にそのまま適用する義務や、個々の工場に完成済みのコード表を与えるものではありません。自社設備とCMMSの構造を優先し、必要な部分だけ参照します。
まとめ
保全履歴のAI標準化は、自由記述を機械的に置き換える作業ではありません。設備別のコード体系、問題・原因・処置の意味、未確認を残す規則、人の承認、CMMSへの版付き連携、設備・言語別の検収を一つの流れにします。その土台があれば、現場の言葉を失わずに、再発や設備群の傾向を比較できる履歴へ近づけられます。
タイ工場で既存の作業票とCMMSコード表を照合し、どの設備群から試すべきか検討中であれば、TOMAS TECHへご相談ください。導入前の対象整理や評価票の設計段階から相談できます。
