機械メンテナンス業の業務効率化システム開発

点検が終わってから報告書が客先に届くまでに、何日かかっているでしょうか。現場で点検票に手で書き、事務所に戻ってExcelに打ち直し、撮った写真を貼ってPDFにして送る。作業そのものより、報告書を作る時間のほうが長い日もあります。

段取りも同じです。翌日の案件に持っていく機材を、ベテランの方が過去の記憶から拾い出す。マニュアルとチェックリストは、前回の案件のファイルを探して手直しする。その方が休むと、誰も同じ精度で準備できません。

当社では、機械メンテナンス・設備保全の業務効率化として次の5つを想定しています。すべてを同時に作ることは勧めていません（理由は後半に書きました）。

点検・作業報告書の作成は自動化できますか

できます。現場で入力した内容から、提出用の報告書をその場で組み立てる形にします。

よくうかがう困りごと — 手書きの点検票をExcelに打ち直している。写真の貼り付けと並べ替えに時間がかかる。客先ごとに書式が違い、同じ内容を別の様式で作り直している。差し戻しがあると最初から作り直しになる。

実現できること — 現場のスマートフォンやタブレットで項目を選び、写真を撮った順に紐づけます。事務所に戻る前に下書きが出来上がっている状態にします。客先ごとの様式は、書式と項目の対応を画面から登録・修正できるようにします。書式が増えるたびに開発側へ依頼する形にはしません。

技術的にどう作るか — 現場は電波が弱い場所があるため、ブラウザで動かしつつ端末側に入力を溜める作りにします（PWAとIndexedDB）。電波が戻った時点でまとめて送ります。写真はファイル置き場（Cloudflare R2）、点検の記録はデータベース（同 D1）に分けて持ちます。写真は容量が大きく、記録は検索したいという性質の違いがあるためです。PDFの組版は処理が重いので、Workers の中では完結させず、生成だけ切り離した構成にします。

案件の段取りにかかる時間は減らせますか

減らせます。過去の類似案件から、持っていく機材と手順の候補を先に出す形にします。

よくうかがう困りごと — 機材リストがベテランの頭の中にある。マニュアルとチェックリストを毎回コピーして手直ししている。準備漏れが現場で分かると、取りに戻ることになる。

実現できること — 設備の型式や作業の種類を選ぶと、過去の案件で使った機材と手順を候補として出します。そこから追加・削除して当日分を確定します。チェックリストは確定した内容から作り、現場でそのまま点検票として使えるようにします。

技術的にどう作るか — 過去の案件を検索できる形に貯めるのが先です。型式・作業種別・部位での絞り込みと、文章としての類似検索を組み合わせます。ここは既存データの整い方で難易度が変わります。 型式の表記が揺れている場合は、名寄せが先に必要になります。

見積書と工程表、原価の管理はどこまで作れますか

作業の実績から見積と原価をつなぐところまで作れます。

よくうかがう困りごと — 見積は過去の似た案件を探して作っている。工程表は別のExcelで、見積と数字が合わない。案件ごとの原価が締めたあとにしか分からない。

実現できること — 見積の明細を作業と部材の単位で持ち、そのまま工程表の元データにします。現場から上がってきた作業時間と使った部材を突き合わせ、案件が終わる前に見込みとの差が見えるようにします。

技術的にどう作るか — 会計や販売管理を置き換えるのではなく、そちらへ渡す手前までを担当する構成を想定しています。締めの処理は既存システムに残し、取込形式での出力かAPIで連携します。

現場作業をAIで支援するとは、具体的に何ですか

過去の事例を引いて出すこと、手順を示すこと、写真から所見の下書きを作ることの3つです。

よくうかがう困りごと — 同じ症状を前にどう直したかが、担当者の記憶にしかない。若手が現場で判断に迷ったとき、電話で聞くしかない。所見の書き方が人によって違う。

実現できること — 型式と症状から過去の作業記録を引いて、そのときの処置を出します。撮った写真から所見の下書きを作り、担当の方が直して確定します。

ここははっきりお伝えします。 写真からの所見生成は、人が確認してから提出する運用でのみお受けします。 読み取りは必ず外れるものが出るため、自信のない箇所を目立たせて人が直す画面にします。精度がどの程度出るかは、実際の写真を拝見するまで申し上げられません。読めるかどうかを試すところから始めます。

新しく入った方の教育にも使えますか

使えます。貯まった作業記録を、そのままテストと教材の元にできます。

よくうかがう困りごと — 教育がベテランへの同行頼みで、人によって教わる内容が違う。理解度を測る手段がない。

実現できること — 実際の事例をもとにした設問を作り、回答と正誤を記録します。どの設備・どの作業で間違いが多いかが分かるので、教育の重点を決められます。

技術的にどう作るか — 上の4つで貯まったデータを使い回す形なので、これを第1弾に選ぶことは勧めません。 元になる記録が無い状態では、設問を手で作ることになり、Excelで作るのと変わりません。

承っていないもの

• 計測機器・センサー・タブレットなど機器そのものの販売や設置
• お使いのパッケージソフト本体の不具合対応（提供元での対応になります）
• 写真からの所見を、人の確認を挟まずにそのまま客先へ提出する運用

第1弾に何を選ぶべきですか

いちばん多く発生していて、いちばん手戻りが多い業務を1つ選びます。多くの場合は点検・作業報告書の作成です。

理由は3つあります。毎日発生するので効果が早く見えること。紙とExcelという出所がはっきりしていて、作る範囲を切りやすいこと。そしてここで貯まった記録が、案件準備・原価・AI支援・教育のすべての元データになることです。順番を逆にすると、元データが無いまま作ることになります。

全機能を同時に開発することは勧めていません。 理由は次のとおりです。

• 全部そろえてから使い始めると、使ってみて分かる直しが最後にまとめて出ます。1つだけ先に動かせば、その直しを早い段階で見つけられます
• 現場で使う画面は、実際に手袋をした手で触ってみるまで適切な大きさや押しやすさが決まりません。これは机上の設計では詰め切れません
• 同時に作るほど、1つの仕様変更が他に波及します

進め方の全体はご相談から着手までの流れに書いています。社内にシステムの担当がいない場合に何を決めていただくかは、初めてシステム開発を外注するとき何を決めるかをご覧ください。

まず現状をうかがうところから始められます。お問い合わせからご連絡ください。

開発体制と技術の選び方

AI駆動開発で何が変わりますか

当社は Claude Code を使った開発を標準の進め方に組み込んでいます。変わるのは主に3つです。

見積の前に動かして確かめられること。 不確実な部分（既存システムとの連携、写真の読み取り、現場端末での動き）を、見積の段階で小さく試せます。「分からないまま」見積に残す範囲が減ります。 精度が何割上がるという数字は申し上げられません。確かめてから出せる範囲が広がる、という意味です。

最初に見ていただくまでが早いこと。 画面の形を早く出せるので、机上の仕様書ではなく動くもので確認していただけます。

仕様変更に追従しやすいこと。 ただしこれは、変更してよい範囲を先に決めてある場合に限ります。 何でも早く変えられるわけではありません。

要件定義には、開発経験のある営業が最初から入ります。現場の手順をうかがう場と、作りに落とす場を分けないためです。

Cloudflare のどこを使い、どこで使わないか

この領域では Cloudflare の構成（Workers / D1 / R2 / Pages）を候補に挙げます。現場から使う仕組みと相性がよいためです。

• 全国どこの現場からでも近い場所から応答する
• 写真の置き場（R2）と記録のデータベース（D1）を同じ仕組みの中で扱える
• サーバーの面倒を見る担当を社内に置かなくて済む

適さないケースも申し上げます。

• 基幹システムが閉域網の中にあり、外部から接続できない場合。 この構成は外から届くことが前提なので向きません。オンプレでの構成をご提案します
• 既存のデータベースにストアドプロシージャの資産が大きくある場合。 D1 へ移すと書き直しの量が大きくなります。既存のまま残して連携する形を選びます

技術は先に決めません。いまの手順と既存システムの状況をうかがってから決めます。

稼働したあとはどうなりますか

同じ担当が保守を続けます。相談から設計・開発・稼働後の対応までを一気通貫で受ける体制です。

現場で使う仕組みは、稼働してからのほうが直す箇所が出ます。 客先の書式が増える、点検項目が変わる、端末が入れ替わる。こうした変更を開発した担当がそのまま受けるので、経緯を調べ直す手間が出ません。

打ち合わせは往訪できますか

できます。静岡市駿河区に本社があり、県内はご訪問しています。名古屋方面は新幹線でおよそ1時間なので、東海圏の往訪にも対応します。オンラインのみでも進められますが、現場を見せていただくと画面の作りが具体的に決まります。