業務システムの導入ガイド

設備点検をアプリにする|異常報告と対応確認までの設計

設備点検をアプリに移すなら、点検結果の入力に加えて、異常を見つけた後の担当者、措置、再確認を同じ設備の履歴として追えるようにします。紙の点検表を画面に置き換えても、異常の対応先が口頭や別表のままなら、「点検済み」と「対応完了」を区別できないからです。

設備IDに点検結果を結び付け、異常があれば措置と再確認の記録を追加します。以下の設計例では、措置をしただけなら「確認待ち」とし、再確認で基準への適合を確認して初めて「完了」にします。

外部資料に基づく事実は2026年9月30日時点で確認しています。以下のデータ構成と判断表は、各現場の規程と設備リスクに合わせて調整する架空の条件例です。Cotomuの製品固有仕様や実在する顧客事例を示すものではありません。

設備点検アプリで分けて管理したい6つの記録

異常内容と対応結果を備考欄へ追記し続ける形は、一枚の点検表としては読めます。しかし、担当者未設定の異常だけを取り出したり、措置済みで再確認を待つ記録を一覧にしたりするには、状態の違う情報を分けて結ぶほうが判断しやすくなります。

実際に、サイボウズの設備点検記録サンプルアプリは、点検日、点検項目、状態に加え、異常内容、対応措置、次回点検予定日までを記録し、進捗を一覧やステータスで確認する構成を示しています。点検から異常対応までを一続きにした公式実装例です。

また、総務省消防庁の消防用設備等点検アプリには、建物、消防用設備等、点検者の情報を初期登録し、対象となる消防用設備等の点検基準への適合確認を法令様式の報告書へ反映する設計例があります。設備と点検者を先に識別できることが、繰り返し行う点検記録の土台になります。

架空の設計例では、記録を次のように分けます。

データ主な項目例ほかのデータとの結び方判断に使う場面
設備設備ID、設備名設備IDをほかの記録から参照するどの設備の履歴かを特定する
点検項目点検項目、判定基準設備IDと結び、反復して使う何を基準に確認したかをそろえる
点検結果点検日、点検者、判定設備IDと点検項目を参照する点検を実施した事実を残す
異常異常ID、異常内容、優先度、現在状態発見した点検結果と設備IDへ結ぶ対応対象を未処理のまま保持する
措置担当者、実施日時、内容、状態異常IDへ履歴として追加する誰が何をしたかを追う
再確認確認者、確認日時、判定、根拠異常IDと措置を参照する完了にしてよいかを判定する

設備は履歴の軸、点検項目は繰り返し使う定義、異常は対応すべき対象です。措置と再確認も別にすれば、措置の実施と完了判定を混同せずに済みます。再対応した場合は過去の措置を残し、最新の措置に対する再確認を追加します。

既存のExcel台帳に列やシートが分散している場合は、設備IDを決めてから関係を整理します。移行範囲の切り分けは、Excel管理を業務システムへ移行する進め方も判断材料になります。

異常報告を「完了」にする判断表

対応内容が書かれていても、その措置が有効だったかは別に確認する必要があります。措置の記録と、再確認の判定・根拠を分けて残します。

厚生労働省掲載のゼラチン・コラーゲンペプチド製造の衛生管理手引書では、金属検出機の基準逸脱に対して、報告、原因究明、機器点検、作動確認後の再稼働、是正処置書の発行と対策を一連の手順にしています。実施例にも、異常の発生時刻と作業者、責任者への報告、機器点検、再度の作動確認が記録されています。措置の内容と、その後の確認結果を残す業務例です。

異常対応の進み具合をアプリで管理する架空の条件例が、次の判断表です。

異常の有無担当者措置再確認アプリ上の状態次に必要な処理
なし―――点検完了点検結果を設備履歴へ保存する
あり未設定未実施未実施要割当担当者を設定する
あり設定済み未完了未実施対応中措置の実施内容を記録する
あり設定済み実施済み未実施・未確定確認待ち確認者が判定と根拠を記録する
あり設定済み実施済み基準適合完了完了日時を確定し、履歴へ残す
あり設定済み実施済み不適合再対応異常を閉じず、次の措置へ戻す

「点検完了」は今回の点検を終えた状態です。今回異常がなくても、同じ設備にある別の未完了異常は一覧に残します。

異常を完了にするには、担当者と措置の実施記録を残したうえで、最新の措置を再確認します。確認者・確認日時・判定・根拠がそろい、基準適合と判断できた場合だけ「完了」へ移します。判定や根拠が確定しない間は「確認待ち」に残します。この条件を画面表示と状態の切り替えに使い、「措置済み」と「解消確認済み」を分けて扱います。

ここでの「完了」は、異常対応の記録上の区切りです。設備の再稼働や法定点検の適合は、それぞれの手順と権限に従って判断します。

未対応異常を引き継ぐ一覧

個々の記録を正しく分けても、交代時に未完了の案件が見えなければ対応は続きません。引継ぎでは、完了以外の異常を抽出し、次の列を一つの一覧に並べます。

設備ID設備名異常ID点検日異常内容優先度担当者期限現在状態最終措置再確認予定引継ぎメモ
設備台帳のキー対象設備異常の識別子発見日対応対象現場で定める区分未設定も表示現場で定める期日要割当・対応中・確認待ち・再対応最新の措置内容次の確認予定次担当者が必要とする申し送り

一覧では件数とともに、次の担当と処理が決まっているかを優先して確認します。担当者が空なら割当対象、措置済みで再確認予定が空なら確認手配の対象、再確認が不適合なら再対応の対象と判断できます。優先度や期限は、現場の規程と設備リスクに合わせて定義します。法令上の共通要件を示す項目ではありません。

紙の点検表から移す手順

既存帳票の全項目をそのまま一画面へ移す前に、完了判定から逆算します。

  1. 設備台帳を整理し、履歴を束ねる設備IDを決める
  2. 設備ごとに反復する点検項目と判定基準を分ける
  3. 異常ありの点検結果から異常記録を作る条件を決める
  4. 担当者、措置、再確認の入力項目と、状態を切り替える条件を決める
  5. 完了以外を抽出する引継ぎ一覧を確認する
  6. 再確認で基準適合となった場合だけ完了にできるかを受け入れ確認する

この順序なら、未対応異常を次の行動へ渡すために必要な画面とデータを選べます。紙のレイアウトは、必要な画面とデータが固まった後で検討できます。初期開発と運用保守は個別見積もりとなるため、検討時には連携、移行、権限、データ出力の範囲を契約前に確認します。費用を左右する範囲の整理には、業務システム開発の費用を考えるポイントも参照できます。

措置済み・再確認待ちの異常が一覧に残るか確かめる

点検表を送信し、措置を記録した後も、再確認が済むまでは異常を一覧に残します。未対応異常の引継ぎ一覧で、担当者、最終措置、再確認予定をたどれるか確認してください。再確認が不適合なら「再対応」へ戻し、基準適合を確認した場合だけ閉じられることが、この設計例の受入条件です。

Cotomuでは、自社業務に合わせたWebアプリを、困っている業務ひとつから相談できます。設備点検の入力から異常対応、再確認、引継ぎまでをどこまで同じ履歴に含めるか整理したい場合は、業務アプリの相談をご利用ください。

まずは、ひとつの業務から

その手作業、
仕組みに変えませんか。

まだ仕様書がなくても構いません。
いま困っている作業から、お聞かせください。

業務のシステム化を相談する
設備点検をアプリにする|異常報告と対応確認までの設計 | cotomu オーダーメイドSaaS