見出し画像

【町工場DX奮闘記②】現場の写真がそのまま報告書になる。「パシャレポ」を作った話


(①からの続きです)




最も効果が見込める場所は…


鉄工所で最初に手をつけたところのは、CADではなく「現場記録」の部分でした。理由は単純で、一番すぐに効果が見えそうだったからです。CADの話は、正直なところ自分の中でもまだ構想が固まっていませんでした。まずは小さく作って、実際に使ってもらいながら信頼関係を作っていきたい、という思いもありました。

現場に行って、写真を撮る。事務所に戻って、その写真を見ながら報告書を作る。この「戻ってからの作業」が地味に時間を食っている、という話を聞きました。特に、現地調査(これから何をすべきか判断する段階)と、完工報告(お客様に渡す最終報告)の2つの場面で、それぞれ違う書き方が求められるのも、地味に手間になっているようでした。


スマホで撮るだけ、を目指して

作ったのは、現場でスマホで写真を撮ると、AIが「どこの部位か」「今どういう状態か」「どう対応すべきか」を自動で判定してくれるツールです。GAS(Google Apps Script)とGoogleスプレッドシート、Gemini APIを組み合わせて作りました。裏側の仕組みとしては、スマホから送られた写真をGoogleドライブに保存し、GASがGemini APIに画像を渡して判定結果を受け取り、その結果をスプレッドシートに書き込む、という流れです。

現地調査用と完工報告用の、2つのモードを用意しました。現地調査モードでは、新設なのか補修なのか判断がつかない段階を想定して、中立的な言葉で状況を記述するようにしています。一方、完工報告モードでは、お客様がそのまま読んでも分かるよう、平易な言葉に切り替わるようにしました。同じ「写真を撮る」という行為から出発しても、誰が読むかによって、書くべき言葉は全く違う。これは、実際に作ってみて初めて実感したことでした。



途中のバージョンアップでは、複数枚の写真を連続で撮影して、まとめて処理できるようにしたり、AIが出した判定結果をその場でプレビュー画面から修正できるようにしたりと、少しずつ機能を足していきました。実は、この「パシャレポ」自体、以前別の業種(塗装業)向けに作っていたツールをベースに、鉄工所仕様に作り替えたものです。ゼロから作るのではなく、過去の資産を活かせたのも、開発が早く進んだ理由の一つでした。


一番苦労したのは、AIに「その会社の言葉」を教えること

やってみて分かったのは、汎用のAIにそのまま判定させても、現場特有の言い回しが伝わらない、ということでした。「にがし」のような、その業界・その会社ならではの言葉が、AIには通じないのです。判定結果を読んでもらったところ、「言ってることは合ってるけど、なんかよそよそしい」という感想をもらいました。これは正直、想定していなかった反応でした。

そこで、その会社独自の用語集をGoogleドキュメントにまとめてもらい、それをプロンプトに自動で読み込ませる仕組みを作りました。技術的には、GASからGoogle Docs APIを叩いて用語集の中身を取得し、それをGeminiへのプロンプトの中に埋め込む、というだけの単純な仕組みです。ただ、これで判定結果の言葉づかいが一気に「その会社らしく」なりました。

地味な工夫ですが、これが無いと「なんか他人行儀なAIの言葉」になってしまい、現場の人が使う気になれないだろうな、と思います。AIに何をさせるか以上に、AIに何を渡すか、という部分の設計が大事なんだと、この時に学びました。


実際に見せた時の反応

複数枚の写真をまとめて処理できるようにし、判定結果をその場で修正できるプレビュー機能もつけたバージョンを見せた時、「思ったよりちゃんと使えそうだ」という反応をもらえました。無償のPoC(実証実験)としては、悪くない滑り出しでした。

ここで得た小さな手応えが、次の「CADポン」に取り組む原動力になりました。せっかく現場記録の方で信頼してもらえたのだから、社長の一言だった「ボルトが一瞬で出てくる」というあの話も、本気で実現してみよう、と思ったのです。

ここまでは、比較的スムーズでした。本当に大変だったのは、次の「CADポン」からです。

(③に続きます)



いいなと思ったら応援しよう!