保全記録を
予防保全スケジュールに変える方法

ログにはすでにスケジュールが含まれている

予防保全スケジュールに必要なデータ — 設備ID、作業日、作業内容、発見された状態、交換部品 — は、すでに保全記録の中にあります。不足しているのは、それをバインダーから取り出してスプレッドシートに入れるというステップだけです。

PMスケジュールが各設備に実際に必要とするものを考えてみてください。識別情報、必要な作業、そして頻度です。保全記録はその3つすべてに答えています。設備名とシリアル番号はページの上部に書かれています。各作業日は前回のサイクルのタイムスタンプです。作業内容の説明 — 「ベアリングにグリースを塗布」「駆動ベルトを交換」「トルクを校正」「1,250時間でオイル交換」 — は、まさに次の作業指示書に記載されるべき作業です。保全記録は過去の記録ではありません。それはまだ読まれていない未来のスケジュールなのです。

これが、スプレッドシートのテンプレート方式がほとんどのチームで失敗する理由です。メンテナンス管理の検索結果の上位にあるものは、ほぼすべてダウンロード可能なテンプレート — データを待つ、よく設計された列を持つ空白のシートです。テンプレートは間違っていません。ただ、間違った問題を対象にしています。つまり、今日から入力を始めて、今後数か月かけて履歴を蓄積することを前提としているのです。ほとんどの施設には数か月の猶予がありません。彼らには、2年間2か月周期で故障し続けている機械があり、その周期の証拠はデータソースとして一度も開かれたことのない記録簿の中にあるのです。

r/manufacturing の「みなさんは実際にどうやってメンテナンス作業を追跡していますか？（Excelは壊れている気がします）」というスレッドで、ある工場経営者がまさにこの状況を説明していました。「共有コンピュータのExcelシートに作業を記録することになっているのですが、実際にはかなり混乱しています。半分の確率で、修理しても記録されないか、誰かが紙に走り書きして、それがシートに反映されることはありません。機械が再び故障したとき、彼らは基本的に記憶を頼りに前回何をしたかを思い出そうとしています。」別のユーザーからの返信は、構造的な問題を突いていました。「Excelの混乱は経験済みです。導入の問題は現実的です — 人が記録しなければ、どのシステムでも解決できません。」どちらの発言も真実であり、合わせて実際のボトルネックを表しています：システムの不足ではなく、未転記の記録という壁です。

紙の記録が予防保全を妨げる理由

紙の保全記録は、3つの具体的な方法でPMプログラムを失敗させます。そして、その3つすべてに共通する根本原因があります。それは、データが存在しても、誰も行動に移せる情報にならないということです。

これらの失敗の背後にあるリスクは理論上の話ではありません。SiemensのTrue Cost of Downtime 2024レポートによると、計画外のダウンタイムはFortune Global 500に年間約$1.4 trillion（総収益の11%）のコストをもたらしており、2019年の8%から増加しています。自動車セクターでは、アイドル状態の生産ラインは現在、1時間あたり最大$2.3 millionのコストがかかります。計画外ダウンタイムの大部分は、特殊な故障が原因ではありません。スケジュール通りに行われなかった保全が原因です。これはスケジューリングの問題であり、データの問題なのです。

米国における2つの規制動向により、これまで保全記録を任意扱いできた施設でも、この対応が必須となりました。2023年版のNFPA 70Bは「推奨慣行」から必須の電気設備保全規格に格上げされ、リスクベースの電気保全プログラムの確立と文書化が義務付けられました。保全間隔の定義（状態の良い設備は点検間隔を最大60か月に延長可能、劣化した設備は12か月に短縮）と、記録へのアクセスが求められます。また、OSHA 29 CFR 1910.147(c)(6)では、ロックアウト/タグアウトのエネルギー制御手順を少なくとも年1回点検し、設備、日付、関与した従業員、点検実施者を記録して認定することが義務付けられています。どちらの要件も、保全記録が検索可能であることを前提としています。紙の記録ではこの前提を満たせません。

保全記録がスケジュールになるために必要なこと

保全記録は、行が「何を対象にするか」「最後に作業したのはいつか」「次回の期限はいつか」の3点を計算できる構造になっていれば、PMスケジュールに変わります。そのためには、少なくとも固定された一連のフィールドが必要です。既存の記録のほとんどには、すでにこれらの情報が含まれていますが、自由形式のメモに埋もれているだけです。

Society for Maintenance and Reliability Professionals (SMRP)が公開する保全メトリクスフレームワーク（標準的な保全KPIを定義する業界団体）は、これらのフィールドが重要である理由を明確にしています。SMRPの作業管理の柱では、計画保全率（PMP）を測定します。これは、保全時間全体に占める計画保全の割合であり、ワールドクラスの目標は85%超です。もう1つのSMRPメトリクスであるPM遵守率は、計画されたPM作業指示書が期日どおりに完了しているかを追跡します。どちらのメトリクスも、どの資産に、いつ、何を実施したかという信頼できる記録がなければ計算できません。記録は、これらのすべての数値の原材料です。

保全記録を抽出する際、行をスケジュールに変えるフィールドは次のとおりです。

既存の記録が山のようにある方にとっての良い知らせは、これらの項目が記録から欠落することはほとんどないということです。欠落しているのは構造です。点検記録の1ページにはこう書かれているかもしれません。「7/14 – ポンプベアリング3箇所すべてに給脂、ベルト交換、モーターカップリングにガタつきを確認」。スケジュールに必要なすべての項目がこの1文に含まれています。日付、作業内容、部品、状態です。欠けているのは、その文を列に変換することです。

ステップバイステップ：ログページからスプレッドシートの行へ

これは、既存の保全記録を構造化されたスプレッドシートに変換するワークフローです。印刷されたページ、手書きの記入、電話で撮影したログブックの写真など、記録の形式を問わず処理できるAI抽出アプローチを使用します。以下の5つのステップで、紙の束からスケジュール対応のテーブルへと導きます。

抽出自体は1ページあたり数秒で完了します。ImageToTable.aiの効率ベースラインは1ページあたり5〜10秒で、手入力の約3分と比較すると「18倍高速」という数字になります。印刷された表データでは最大99%の精度に達します。手書きの精度は読みやすさに依存するため、まさにそのために検証ステップが存在します。ご自身のログブックの1ページでお試しください：

抽出した行を作業スケジュールに変換する

ログエントリがスプレッドシートの行になれば、スケジュールはすでに使い慣れたExcelスキルだけで自動的に構築できます。さらに、最も手間のかかる部分を省くショートカットもあります。それは、各行の次回期限日を抽出時に計算しておくことです。後から計算する必要はありません。

追加する最も有用な列は、次回期限日です。エクスポート後に行ごとに計算するのではなく、抽出時に計算列を定義します。「次回期限（作業日+90日）」という名前を付けると、AIが抽出中に計算を実行し、各行に作業日と間隔を加えた値を自動入力します。計算列は抽出ステップ自体の一部です。ツールがドキュメントを読み取り、計算を実行し、結果を出力するため、生の日付と手動のスプレッドシート計算ではなく、「次回期限」の日付を受け取ることができます。使用量ベースの間隔の場合も、メーター値から同じ仕組みが機能します。「次回点検（メーター稼働時間+250）」のように指定します。

スケジュールを完成させるには、スプレッドシートで3つの操作を行います：

これこそ、紙の記録が意思決定ツールに変わる瞬間です。過去を記録していた同じ行が、どの資産がいつ期限を迎えるのか、そして繰り返し発生する故障が何を示唆しているのかを、今まさに教えてくれます。抽出されたスプレッドシートは、記録にすでにあったすべての履歴を引き継ぎます。ただ、その履歴を計算可能にするだけです。

複数の拠点で測定値や点検記録を収集しているチーム（メーター検針員のルートと同じように保全技術者が巡回する現場）では、同じ抽出パイプラインがそれらの記録も処理します：現場データは写真からスプレッドシートへ入力作業なしで変換され、現場の写真は同じ列駆動のワークフローでスプレッドシートの行になります。保全巡回に付随する点検チェックリストや状態記録フォームについては、印刷フィールドと同じパスでチェックボックスや手書きの所見も抽出されます。

スプレッドシートでは足りなくなる時

スプレッドシートは、現実的で把握可能な規模までは保全記録に適したツールです。その境界線がどこにあるのかを正直に見極める価値があります。なぜなら、すべての保全チームは、いずれその境界線に到達するからです。

保全作業の記録に関するRedditのスレッドで、r/PLCのベテランから定番の回答が寄せられました。「あなたが探している用語はCMMSです。たとえシフト間で引き継がれるペンと紙のログブックでも、何もないよりはましです。」別のコメント投稿者は、一般的な成長経路を説明しました。「スプレッドシートは小規模な運用には十分です。機械の台数が増えるにつれて、Maximoのような商用CMMSに切り替えることができます。事業がさらに成長すれば、保全管理モジュールを組み込んだSAPのようなERPシステムを検討するかもしれません。」実務者が実際に挙げるツール — IBM Maximo、SAP PM、Fiix（現在はRockwell）、UpKeep、Limble、eMaint（現在はFluke）— はすべて、そのより大規模な領域に位置しています。数十台の設備を持つ単一サイトでは、スプレッドシートは依然として主力であり、抽出機能はCMMSに供給するのと同じ方法でスプレッドシートにデータを供給します。

移行の時期を知らせる兆候：数百件を超える稼働資産、集中スケジューリングが必要な複数サイト、承認フローを伴う作業指示ワークフロー、または保全履歴をオンデマンドでエクスポートできることを求める監査人。これらに該当する場合、抽出したログデータは無駄にはなりません。それはCMMS導入に必要な最初のクリーンなデータセットです。既存のCMMS移行ガイドはすべて同じ指示から始まります。移行前に資産と保全履歴を構造化された形式に変換することです。ここで説明する抽出ワークフローはまさにそのステップです。データ入力の苦労ではなく、CMMS展開を可能にするクリーンで構造化された履歴を生成します。

また、スプレッドシートのワークフローを維持しながら、項目ごとの入力を完全に省略したいチームのための中間的な道もあります。保全ログのバッチ抽出は、既存の追跡シートに供給するか、後でCMMSのシードデータになる構造化された履歴を生成します。どちらを選択しても、基本原則は同じです — すでに保有している履歴は、保全運用において最も価値のあるデータセットであり、それを活用するために必要なのは、ページを行に変換することだけです。

FAQ

AI抽出は手書きの保全記録をどの程度正確に読み取れますか？

手書きの記入は、文字が読みやすい場合に読み取れます。ブロック体や文字が分離している場合は確実に抽出でき、印刷と手書きが混在する形式も、AIが印刷されたラベルを基準にして文脈から手書きの値を解釈するため、うまく機能します。筆記体、ひどい汚れ、コントラストが非常に低い写真では精度が低下します。このため検証ステップが存在します。すべての記入を入力するのではなく、フラグが付いた値を確認するだけで済むため、完全な転記よりもはるかに速くなります。

当社の記録は、印刷されたフォーム、手書きのページ、スマホの写真が混在しています。それぞれに異なる設定が必要ですか？

いいえ。カスタム列抽出はレイアウトではなく意味を読み取るため、同じ列定義が印刷されたPMチェックリスト、手書きのログブックページ、設備タグの写真にわたって機能します。これは、レイアウトごとに定義済みの領域を必要とし、形式が変わると機能しなくなるテンプレートベースのOCRとの根本的な違いです。

当社には何年分もの記録、つまり数百ページがあります。その量でバッチ処理は現実的ですか？

はい。バッチ処理はまさにこのために設計されています。すべてのページを1つのバッチでアップロードし、列を一度定義すれば、AIがそれらをまとめて処理し、単一の結合テーブルにします。オフィス側の作業は、数百ページの転記からバッチ出力の確認へと移行し、その時間はほんの一部です。事務員が数週間かけて入力するような2年分のバックログが、午後の作業になります。

これはMaximoやUpKeepのようなCMMSを置き換えるものですか？

いいえ。これはCMMSの前にある問題を解決するものです。すでにCMMSを運用しているチームにとっては、抽出機能がCMMSにデータを供給します。記録の写真や紙の記録が、CMMSが必要とする構造化された履歴に変換されます。CMMSを導入する準備ができていないチームにとっては、抽出機能はタイピング作業をなくしながら、現在使用しているスプレッドシートのワークフローを維持します。どちらの結果も改善であり、どちらも移行を装ったものではありません。

ログページにはどの程度の写真品質が必要ですか？

担当者が記入内容を読み取れる程度の鮮明さが必要です。平らに置いたログブックのページを、明るい場所でスマートフォンで撮影した写真で十分なことがほとんどです。一般的な最新のスマートフォンカメラは、日中であればこの基準を満たします。著しいブレ、文字が歪む極端な角度、影でページの一部が隠れている場合は、信頼性の低い結果になるため、そのようなページは撮り直してください。

既存の保全スプレッドシートとその計算式を引き続き使用できますか？

はい、使用できます。それがこの機能の目的です。抽出処理はデータ列に値を入力するだけで、既存のすべての計算式、条件付き書式、ピボットテーブルは、手入力された行とまったく同じように抽出された行に対して機能し続けます。スプレッドシートは、セルの値がキー入力によるものかAI抽出によるものかを認識せず、気にすることもありません。Google Sheetsで作業しているチームの場合、アドオンは同じワークフローでアクティブなシートに直接抽出します。