保全作業報告 AI 作成 導入｜タイ工場の設計と受入基準

設備の修理は終わったのに、保全作業報告書の入力が翌日に持ち越される。交代勤務で口頭の引き継ぎが先に進み、使った部品や停止時間の根拠が曖昧になる。タイの製造現場で「保全作業報告 AI 作成 導入」を検討するなら、文章を流暢に書く機能だけを比較しても、こうした問題は解決しません。設計すべき対象は、現場の音声・写真・部品使用・時刻を、設備と作業指示に結び付け、人が確認したうえでCMMS/EAMへ登録する一連の業務です。

本記事は、保全責任者、生産技術、工場IT、購買担当者がRFPを準備するための実務ガイドです。設備点検報告 AI、保全報告書 自動作成、音声入力 CMMS 連携を一つのシステムとして捉えます。故障を予測するAIや部品在庫の最適化は別の課題です。ここでは「現場で実施した作業を、再利用できる記録として正しく残す」ことに絞ります。掲載する数値例は、明記した仮定を使う設計例であり、実測値や一般的な改善率ではありません。

最初に決めること：完成文ではなく、承認可能な記録

記録の自動作成で危険なのは、読みやすい文章ができると、事実も確認済みだと思い込むことです。「軸受を交換した」という一文には、対象設備、部品番号、交換数量、作業時刻、実施者、承認者、根拠写真が結び付いていなければなりません。音声だけに「モーターのベアリングを替えた」と残っていても、交換した型番をAIが推測して埋めてはいけません。型番は部品スキャンやCMMSの出庫記録から照合し、合わなければ未確認として止めます。

導入時の完成条件は「AIが報告文を作った」ではなく、次の五つを満たすことです。①元の証拠を追跡できる、②必須欄の不明値を不明のまま表示できる、③担当者が訂正して承認できる、④承認後だけCMMS/EAMへ反映する、⑤後から誰が何を変えたか再現できる。これらを満たすまでは、生成文を正式な保全履歴と見なさない運用にします。

ISO 55001:2024は資産マネジメントシステムの要求事項を定め、データ・情報や知識、意思決定の扱いを重視します。ただし、この規格が特定のAI製品や音声入力を要求しているわけではありません。ISO 14224:2016は石油・天然ガス・石油化学産業の信頼性・保全データの収集と交換が対象です。設備分類、故障、保全作業、停止時間などの項目設計には参考になりますが、一般の製造工場に一律に適用義務があると説明してはいけません。自社の顧客要求・契約・法令・監査方針を別途確認したうえで、必要な項目を選びます。

四つの入力を同じ作業IDへ束ねる

現場から集める材料は、音声、写真、部品、時間の四つです。入力手段は別々でも、同じ作業指示IDと設備IDへ結び付けます。報告書を一枚の作文として作る前に、これらの原データを識別できる状態にするのが先です。

同じ「停止時間」でも、設備が止まった時刻、保全者が着手した時刻、生産が再開した時刻は異なります。RFPには少なくともこの三つを分けて定義し、どれを報告書に載せるかを書きます。交代勤務をまたぐ場合はタイムゾーン、日付またぎ、手入力修正理由も残します。PLCのイベントを無条件に唯一の正解にすると、通信断や手動運転の例外を落とします。逆に、作業者の記憶だけで後から入力すると停止時間が曖昧になります。両方の出所を残し、差異を人が確認できる画面が必要です。

写真は画像認識で数値を読める可能性があっても、撮影条件が悪いと誤読します。数値を正式欄へ転記するなら、計器の種別、単位、読取位置、画像の鮮明さを確認します。部品も「使用した」と「出庫した」を混同しません。未使用返品や同等品への交換があるため、出庫履歴だけで報告を確定できないからです。

音声は「証拠」であって命令ではない

音声入力は、両手がふさがる現場で有効な入力手段になり得ます。しかし、騒音、保護具、略語、タイ語・日本語・英語の混在、設備の俗称などで文字起こしは揺れます。録音ファイル、文字起こし、修正版の三つを分けて保持し、誰がいつ修正したかを残します。音声から抽出した文に「異音なし」とあるのか「異音あり」とあるのかは、小さな認識差で判断が逆転します。重要語は画面上で強調し、承認者に原音を再生できるようにします。

Microsoftのバッチ文字起こしの資料は、大量音声を非同期で処理する方式と、その処理時間が音声長、話者分離や言語識別、キューなどに左右されることを説明しています。これは技術的な選択肢の例です。現場で即時確認が要る場合にバッチ処理をそのまま採用できるとは限りません。RFPでは、録音から下書きが表示されるまでの許容時間、オフライン時の入力、音声データの保管場所と削除条件を、製品名より先に指定します。

写真と部品を報告文へ結び付ける

写真は「修理前」「修理後」「銘板」「測定結果」などの役割を選んで撮り、AIが自由に写真の意味を作り直さない設計にします。たとえば一枚の修理後写真だけでは、修理前の破損状態を証明できません。写真がないときは「写真なし」と明示し、存在しない画像や測定値を文章で補いません。写真の撮影端末、時刻、作業指示ID、アップロード後のハッシュを保持すると、後から差し替えや取り違えを調査できます。ハッシュの保存は一つの実装例であり、採用時は既存の文書管理方針に合わせます。

部品記録では、品番、ロットまたはシリアル、数量、単位、使用設備、出庫伝票、返品・廃棄の状態を分けます。すべての部品にロット追跡が必要とは限りません。重要設備や品質影響のある部品から要求水準を決めます。CMMSとERPの部品マスタが一致しない場合は、AIに名称を推測させず、マッピング表を管理します。未登録の代替品は例外キューに送り、マスタ管理者が承認してから登録します。

AI下書きのデータ契約：空欄と確信度を見せる

音声の文字起こしをそのまま生成モデルへ渡して、完成文だけ返す設計は監査しにくくなります。まず作業ID、設備ID、症状、観察事実、作業内容、交換部品、測定値、停止時刻、復旧時刻、未解決事項、添付証拠を構造化してから、表示用の文章を組み立てます。各フィールドには値と同時に、その根拠の種類と参照IDを持たせます。音声から取った「軸受交換」と部品スキャンから取った「品番ABC」は別の根拠です。

OpenAIのStructured Outputsは、指定したJSON Schemaに沿う出力を得る仕組みを提供します。ただし、形式が正しいことは事実が正しいことを保証しません。スキーマで必須項目・型・列挙値を制限しつつ、値の根拠照合と人間承認を別に設計します。また、APIの拒否応答や出力の途中終了を扱う分岐が必要です。システム側は、生成できないときに勝手な補完をせず、元データを保持して手入力に切り替えます。

たとえばデータ契約を次のようにします。asset_id はCMMSマスタに存在するIDだけ、work_order_id は開いている作業指示だけを受け付けます。part_number が音声だけに出てくるなら unverified とし、スキャンまたは人手で照合します。downtime_start と downtime_end はタイムゾーン付き時刻で保存し、前後が逆なら登録を止めます。finding と action_taken は自由文を残しながら、故障モード候補のコードを別欄に置きます。confidence を使うなら、モデルが自己申告した値だけで自動承認せず、項目別の検証結果と分けて扱います。

「原因不明」を「モーター故障」と書き換えるのは文章の改善ではなく事実の改変です。症状、推定原因、確定原因を別フィールドにするだけで、この誤りは減らせます。何が分からないかを明示できる設計の方が、空欄を自然文で覆い隠す設計より、後の分析に使えます。

承認フローを業務と権限に合わせる

AI下書きの承認者は、現場の実施者、班長、保全責任者の誰かを、重要度と作業種別で決めます。すべての報告を一人の管理者へ回すと滞留します。一方、安全や品質へ影響する処置を作業者だけで確定する設計も避けます。RFPには、設備重要度、交換部品の種類、停止時間、品質への影響、未解決事項の有無で承認経路を変える条件を書きます。これは一般論ではなく、自社の権限表に合わせて決める項目です。

承認画面にはAIの要約だけでなく、原音の該当箇所、写真、部品スキャン、時刻ソース、前回履歴を並べます。承認者が一つの画面で事実を直せること、修正前後が残ること、却下理由を記録できることが重要です。AIが提案した故障モードコードを採用する際は、その根拠が足りなければ「分類保留」を選べるようにします。承認済みの報告書を後から修正するときは、元の版を消さず、訂正版と理由を残します。

NIST AI RMFのCoreはGovern、Map、Measure、Manageの四つの機能でAIリスクを扱います。この枠組みは任意利用であり、個別の保全報告システムに法的な認証を与えるものではありません。実務上は、誰が下書き品質を監視するか、どの設備群へ適用するか、何を合格率として測るか、誤登録をどう止めるかを定期的に見直すために使えます。とくに現場の言語混在や設備固有語は、導入後に変化するため、初回テストの合格だけで運用監視を終えない設計が必要です。

CMMS/EAM連携は「二重入力をなくす」だけでは足りない

CMMS/EAMへ登録する対象を、作業指示の本文、作業実績、資材消費、故障コード、添付ファイル、承認履歴に分けます。既存システムによっては一つのAPIで全件を書けません。連携仕様書には、項目の対応、作成か更新か、更新可能な状態、添付の格納先、失敗時の再送方法を明記します。AI下書きの保存とCMMSの正式登録を同じステータス名にしないことも大切です。画面では「入力中」「AI下書き」「承認待ち」「承認済み」「CMMS登録済み」「連携失敗」を区別します。

同じ報告を通信再試行で二回登録しないため、作業指示IDと報告版の組を冪等キーとして使う方法があります。登録APIがタイムアウトしても、再送前にCMMS側の登録結果を照会します。更新処理が部分成功した場合は、本文だけが入って部品消費が未反映の状態を見えるようにします。作業者に「完了」とだけ表示すると、後工程が誤った在庫や履歴に基づいて動く可能性があります。必要に応じて補正キューと担当者を設けます。

AI製品のデモは、きれいな音声と一枚の写真から文章を作るところで終わりがちです。実際の価値は、交代勤務、通信断、代替部品、未解決故障、承認差戻し、CMMS側の必須欄不足を扱えるかで決まります。IBM Maximoなどの既存EAMを使用する場合でも、利用中の版・設定・API権限・ワークフローを現物で確認してください。特定製品にAI推奨機能があることと、自社の作業指示連携が直ちに動くことは別です。

タイ工場で見落としやすいローカライズ

タイ語での音声記録、英語の設備タグ、日本語の社内呼称が混在する工場では、表示言語を一つ選ぶだけでは足りません。設備IDと部品番号は翻訳しない固定値にし、症状や処置の自然文は原語と確認済み訳を分けます。危険を示す否定文、単位、数値、方向、左右を機械翻訳のまま確定しないルールを設けます。通訳・保全担当者が監修した用語辞書を使い、現場で新しい略語が出たら辞書更新の申請へ送ります。

タイムゾーンはAsia/Bangkokを業務画面に表示し、システム間連携ではオフセット付き日時を保持する方法が安全です。夜勤の報告日を勤務開始日で扱うか暦日で扱うかも、工場の帳票運用に合わせて固定します。多拠点展開なら、同じUTC時刻でも各工場の報告日が違うことを試験します。個人の音声を扱う場合は、録音同意、閲覧権限、保存期間、委託先への送信範囲を現地の社内方針と適用法令に照らして決めます。本記事だけで法令適合を判断しないでください。

RFPに入れるべき要求と、ベンダーへの質問

RFPを「音声から報告書を作れること」と一行で書くと、受注側はもっとも簡単なデモを満たすだけになります。まず業務シナリオとデータの境界を指定します。対象設備群、月間の作業指示件数、現場の端末、騒音環境、ネットワーク可用性、現在のCMMS/EAM、ERP・MESとの接続条件は、自社の実数を埋めて提示します。実数が未収集なら空欄を埋めるための現地調査をRFPの前段に置きます。AIの平均精度といった一つの数値だけで判断しません。

ベンダーには、成功例だけでなく失敗例を見せてもらいます。「わからない」と返す条件、誤字を人が直したときの履歴、CMMSが拒否したときの通知、モデル更新後の回帰試験を実演してもらうと、実運用の差が出ます。データの学習利用の有無、国外送信、再委託、テナント分離は契約と運用の両面で確認します。ここは各社の情報セキュリティ方針により判断が変わるため、RFPに現行ポリシーと例外承認の責任者を書きます。

費用比較はライセンス単価だけで終わらせない

費用は、音声処理と生成AIの従量課金、端末、通信、画像保存、CMMS連携、マスタ整備、現場教育、承認工数、運用監視を分けて見積もります。工場での時間削減は、作業者の入力時間だけでなく、承認者の照合作業や連携エラーの再処理を含めて測ります。AI下書きが早くても、承認画面で証拠が見にくければ全体の時間は短くなりません。複数ベンダーの提案比較には、同じ実データ・同じシナリオ・同じ測定開始点を使います。

以下は仮定の算定例です。ある工場で月300件の報告があり、現状の入力と確認に一件あたり合計20分、導入後に同じ範囲で合計15分かかったと仮定すれば、差は月1,500分、25時間です。これは一般的な削減効果ではありません。音声の取り直し、承認待ち、CMMS連携失敗、例外案件の時間を含む実測で置き換える必要があります。費用対効果を示す際は、5分という差の出所と、対象外の作業を明記します。

FATとSAT：何を合格とするか

FAT（工場受入試験）では、ベンダー環境で仕様とデータ契約を確認します。SAT（現地受入試験）では、実際の現場端末、騒音、通信、言語、CMMS権限で業務を通します。両試験の合格条件は契約前に数値と判定方法を決め、後から「概ね良好」と解釈しないようにします。閾値は設備・安全・品質リスクで変わるため、本記事では一律の合格率を提示しません。

FATで用意するのは、正常な定期点検だけではありません。少なくとも、①音声の否定を誤る可能性がある記録、②品番を言い間違えた記録、③写真と音声が食い違う記録、④停止時刻の前後が逆になる記録、⑤二つの設備名が似た記録、⑥タイ語・英語が混在する記録、⑦CMMS必須欄が欠けた記録、⑧APIがタイムアウトする記録を用意します。実際の評価セットは、個人情報や機密情報を除いたうえで自社の過去データから作ります。AIが不正確な内容を流暢にまとめたケースを、合格扱いしないルールが必要です。

SATでは現場の作業者が実際の導線で入力し、班長が承認し、CMMSに結果が一度だけ登録されたことまで確認します。端末の手袋操作、通信が切れたときの保存、夜勤の日付またぎ、写真アップロードの待ち時間、タイ語表示と日本語管理画面の整合を見ます。試験ごとに入力データ、期待結果、実結果、差異、承認者、再試験日を残します。再試験では、修正した問題だけでなく、既に合格した代表シナリオが壊れていないかも確認します。

例外を先に設計する：現場の「困った」を標準フローに

日々の保全には、予定外の作業が必ず混じります。設備IDのラベルが剥がれている、音声が機械音で聞こえない、写真を撮れない場所がある、部品が臨時調達、故障原因が確定しない、同じ停止に複数の作業が紐づく。これらを「現場に注意してもらう」で済ませると、作業者は空欄を埋めるために推測値を入れます。システム側に「一時保存」「要確認」「理由付きで進める」「承認者へ回す」の選択肢を持たせます。

例外キューは件数だけでは不十分です。作業指示ID、設備ID、発生日時、止まったステップ、担当者、期限、原データへのリンク、再開操作を一覧にします。安全や品質に直結する例外は、単なる報告書遅延と分けて通知します。写真がないこと自体で作業を停止させるかどうかは、作業種別に応じて決めます。現場にとって合理的な代替手段がなければ、例外フローは使われません。

監査証跡は「ログがあります」という宣伝文句で終わらせません。少なくとも、原音・写真等の識別子と取得時刻、AIモデルと設定の版、生成時刻、項目ごとの根拠、ユーザーの修正差分、承認・却下、CMMSへの送信と応答、再送や取消を関連付けます。個人情報を無制限に保存することが目的ではないため、保持期間とアクセス権は法務・情報セキュリティ・現場の要件から決めます。監査担当者が一件を実際に再現できるかをSATで試します。

まず一つの設備群で小さく検証する

導入対象は、作業件数があり、設備IDと作業指示が整理され、担当者が試験に参加できる設備群から選びます。高リスク設備を最初から全面自動化する必要はありません。まず過去の報告を使って、どの項目が抜けやすいか、音声と写真がどの程度残っているか、CMMSの必須欄が現場の実態に合うかを確認します。データが足りない場合は、AI選定より記録様式の整備が先です。

実証の順序は、①現状の報告経路を描く、②必須フィールドと根拠を決める、③少数の実データでFAT、④承認画面を現場で試す、⑤CMMSへの限定連携でSAT、⑥例外と監査ログを確認する、⑦対象設備を増やす、です。各段階で次へ進む条件を文書に残します。たとえば「音声で入力した報告の何割をAIが完成できたか」だけでは不足です。必須項目の欠落、誤登録の防止、承認所要時間、差戻し、例外の解決時間を合わせて見ます。

評価期間中は、モデルやプロンプト、設備マスタ、用語辞書を勝手に変えないよう版管理します。変更した場合は再試験の範囲を決めます。導入後は、月次など自社で決めた頻度で、誤抽出の種類、未確認の滞留、言語別の品質、CMMSエラー、利用率を確認します。保全記録が後の分析に使えるかは、入力時の品質だけでなく、設備分類や故障コードの継続的な整備にも左右されます。

関連記事：故障診断と部品在庫は別の判断

AIを使って故障原因の調査を支援する設計は、保全トラブルシューティングAIの導入で扱っています。原因候補を提示することと、実施した処置を正式な作業履歴に残すことは別の承認点です。また、品番マスタや出庫・返品の精度は、保全部品の在庫管理の運用とつながります。本記事のAIが部品を「使った」と書く前に、在庫側の事実を照合してください。

よくある質問：保全作業報告のAI作成をどう導入するか？

保全作業報告 AI 作成 導入では、最初に何を用意するべきですか？

まず、対象設備のID体系、作業指示ID、現行報告書の必須欄、承認者、CMMS/EAM側の入力条件を集めます。過去の報告が文章だけで設備や部品と結び付いていなければ、AIを先に選んでも試験の正解を作れません。現場の保全担当者に、実際の作業を一件選び、発見、処置、部品使用、復旧確認、報告承認までを時刻付きで再現してもらいます。音声や写真の取得可否は作業場所ごとに異なるため、通信がない区域や撮影禁止の設備も一覧化します。そのうえで必須項目の根拠をどの入力から得るか決め、根拠がない欄を空欄で残せることをRFPへ入れます。初期の資料集めを省くと、流暢な下書きと正しい記録を取り違えます。

設備点検報告 AI と保全報告書 自動作成は同じ仕組みで扱えますか？

共通の設備ID、作業ID、証拠リンク、承認履歴は共有できます。ただし点検と故障修理では、入力項目と判断権限を分ける必要があります。定期点検は測定値、点検箇所、異常の有無、次回処置が中心です。故障修理では発見した症状、推定原因、確定原因、交換部品、停止区間、復旧確認を別に残します。AIが「異常なし」と補完したり、推定原因を確定原因へ昇格させたりしてはいけません。まず二つの作業種別を別のテンプレートと受入ケースにし、共通部分だけを再利用します。作業種別を一つの自由記述欄へ押し込める方式は、後から故障傾向を集計しにくくします。

音声入力とCMMS連携の受入試験では何を確認しますか？

タイ語、英語、日本語の設備名や部品名が混じる実音声を用意し、騒音、言い直し、番号の読み上げ、通信断を含めて試します。文字起こしの全文一致率だけでは合否を決めません。設備IDと作業IDが正しいか、数量や単位が勝手に変わらないか、否定表現が反転しないか、未確認欄を空欄にできるかを確認します。CMMSへの送信では、同じ報告の再送が重複登録を起こさないこと、途中で失敗した場合に承認済み原稿と登録結果の差を追えることを試します。試験に使った音声、期待値、画面操作、API応答を一組として残せば、モデル更新後の再試験にも使えます。

AIの下書きは人の承認なしで登録できますか？

本記事の対象である保全作業報告では、少なくとも設備、作業内容、交換部品、停止時間、復旧確認など、後の安全・品質・原価判断に使う項目は責任者の確認を通す設計を勧めます。自動で許す範囲は、自社の作業種別とリスク評価から決めるべきです。承認者には完成文章だけでなく、原音・写真・部品記録・時刻と、AIがどの欄へ何を転記したかを見せます。差戻し理由と修正差分を保存し、CMMS登録前後の版を区別します。「人が最後に見る」と契約書に書くだけでは検証できません。FAT/SATで誤った部品番号や未確認の原因を意図的に入れ、登録前に止まることを確認します。

導入判断のチェックリスト

• 対象設備、作業種別、CMMS/EAMの登録先と責任者が決まっている。
• 音声・写真・部品・時刻の原データを作業IDに結び付けられる。
• AIが根拠のない欄を空欄または未確認として扱える。
• 症状、推定原因、確定原因、実施作業を別に記録できる。
• 承認者が原データを見ながら修正・差戻しでき、履歴が残る。
• CMMS連携の重複、部分失敗、再送の扱いが仕様にある。
• タイ語、英語、日本語の用語と設備IDを混同しない試験がある。
• FATとSATで実データの例外、夜勤、通信断、監査再現を確認する。
• 契約にデータ保持、モデル変更、障害対応、終了時の返却を定める。

まとめ

一つでも未決なら、生成AIの製品比較表を増やす前にその欄の業務責任者を決めると、RFPの精度が上がります。保全報告は、文章を短時間で作ることより、次の故障対応に使える履歴へ変えることが目的です。

タイ工場での設備・作業指示・CMMSの現状を整理し、FAT/SATまで含む導入要件を作りたい段階でも、TOMAS TECHへご相談ください。現行帳票と連携先を確認し、対象設備群から設計を始めます。

参考情報

1. ISO 14224:2016 — Petroleum, petrochemical and natural gas industries: collection and exchange of reliability and maintenance data。対象産業と保全データ分類の範囲を確認。
2. ISO 55001:2024 — Asset management system requirements。資産管理システム、データ・情報、知識の位置付けを確認。
3. NIST AI Risk Management Framework Core。Govern、Map、Measure、Manageと継続管理の考え方を確認。
4. OpenAI API — Structured Outputs。JSON Schemaに沿う出力と拒否・中断時の扱いを確認。
5. Microsoft Learn — Batch transcription overview。大量音声の非同期文字起こしと遅延要因を確認。

*編集注：この記事の工程、試験項目、算定例は導入設計の例であり、各製品の性能保証、法令解釈、または個別工場の実績値を示すものではありません。*