手書きの作業日報を、写真からスプレッドシートに流し込む仕組みを作った
弊社で、手書きの作業日報を撮影した写真をAIに読ませ、中身をスプレッドシートに1行ずつ記録するツールを作りました。動画では、Googleドライブに入れた3枚の写真を、スプレッドシートのメニューから一括で取り込んでいます。記入者もペンも紙の向きも撮影場所も違う3枚ですが、日付、現場名、天候、記入者名、作業内容、作業人数、作業時間などの項目が、それぞれの行に収まります。
使ったのはGoogleドライブ、Google Apps Script、生成AI（Gemini）のAPI、スプレッドシートの4つだけです。
動画はこちら
手書き日報をAIに読ませる前に、紙のほうを先に作り直した
この仕組みで最初に手を入れたのは、じつはプログラムではなく日報の用紙でした。
きっかけは、既存の用紙をそのまま撮って読ませてみたときの結果です。文字自体はきれいに拾えているのに、日付欄が「4/7」とだけ書いてあって年がない。天候欄は人によって「晴」「晴れ」「はれ」「○」と割れている。作業時間は「8:00〜17:00 休1h」と書く人もいれば「8h」と書く人もいる。AIは書いてあるとおりに読むので、シートには書いてあるとおりのばらつきが並びます。読み取り精度の問題ではなく、紙の上で情報が確定していなかったわけです。
そこで、読み取りを前提にしたA4一枚の作業日報を作り直しました。
工夫したのは次のようなところです。日付と作業人数と作業時間は、一文字ずつ入れるマス目にしました。数字は続けて書かれると1と7、0と6の区別がつきにくいのですが、枠が切ってあるとこれがほとんど起きません。年は西暦で書くよう、欄の中に小さく注記を入れています。天候は晴／曇／雨／雪／その他のチェックボックスにして、表記の割れごとなくしました。作業内容と備考の自由記入欄には薄い罫線を引いています。行が波打つと、行の切れ目をAIが取り違えることがあるためです。用紙の下部には確認・承認の押印欄と、撮影時の注意書き（濃いペンで書く、影を入れない、用紙の四隅を入れて撮る）を印刷しました。
用紙を作り直すのに、印刷代を別にすれば費用はかかりません。プログラム側で表記ゆれを吸収する処理を書くより、はるかに安い。AIで業務改善をするとき、AIの手前にある紙や運用をどう整えるかで、あとでおこなう作りこみの量が変わります。
手書き日報をAIに読ませる仕組みは、Googleの中で完結する
Googleドライブの指定フォルダに日報の写真を入れておくと、スプレッドシートのメニューから起動したGoogle Apps Scriptが1枚ずつ拾い、Geminiに画像ごと渡します。Geminiには「この8項目の決まった形（JSONと言います）で返す」という構造を指定してあるので、返ってくるのは決まった形のデータです。それをスプレッドシートに1行ずつ書き、済んだ画像は済フォルダへ移します。動画で「フォルダ内の日報画像を取り込み」というメニューを押しているのが、この起動部分です。
今回もサーバーは立てていません。新しいSaaSも契約していません。Google Workspaceを使っている会社なら、追加で払うのはGeminiのAPI利用料だけです。月数百枚なら数十円から数百円の範囲に収まります。
手書き日報をAIに読ませて詰まったのは、文字の読み取りではなかった
動画に出てくる3枚の写真は、記入者もペンも向きも撮影場所も違います。傾いた写真も、蛍光灯の影が落ちた写真も、一発で読めました。ここは正直、拍子抜けするくらい何もしていません。
手こずったのはその周辺です。
まず、Google Apps Scriptには1回の実行が6分までという制限があります。Geminiに画像を1枚投げて返るまでに数秒かかるので、写真が50枚あると平気で超えます。途中で強制終了されると、どこまで書けたのか分からない状態になります。そこで1回の実行を15ファイルまでとし、開始から4.5分を過ぎたら打ち切って「続きは次回」と記録する形にしました。50枚あるならメニューを4回押してもらう運用です。かっこよくはないのですが、確実です。
それからスマホで撮影した写真の形式です。iPhoneで撮った写真は初期設定だとHEICという形式で保存されます。読めるかどうかは生成AIのモデル側の対応次第で、確実とは言い切れません。今はドライブに入れる前にJPEGにしてもらう運用で避けています。
手書き日報は、全件を「要確認」で書き出す設計にした
弊社が別に作った注文書PDFの取り込みでは、怪しい行にだけ「要確認」を立てました。手書き日報は逆にして、初期設定では全件に「要確認」が立つようにしています。
全件に印がついているなら印の意味がない、という意見はもっともだと思います。それでもこうしたのは、手書きでは数字より固有名詞のほうが危ないからです。作業人数や時間はマス目のおかげでまず間違えません。危ないのは現場名と記入者名です。「斉藤」「齊藤」「齋藤」は書き手の崩し方次第で入れ替わりますし、現場名を略して書いてあると、AIが前後の文脈からそれらしく補ってくることがあります。「◯◯ビル改修」と書いてある欄に「◯◯ビル改修工事」と入っている。人が見ればすぐ気づくのに、機械的な検算にはまったく引っかかりません。金額のような検算の効く項目がない帳票では、「怪しい行を自動で立てる」という発想自体が効きにくいわけです。
導入から最初の1か月は、全件を目で通してもらいます。その間に、どの現場名がどう化けるか、誰の字で何が起きるかを溜める。癖が見えたところで、信頼度の高い行を自動で確定させる設定に切り替えられるよう運用を変えていくというやりかたです。
同じ写真を二度入れても、行は増えない
現場では「あれ、送ったっけ」でもう一度送られてくることが日常的に起きます。二重登録の防止は、ドライブのファイルIDをキーにした上書き、処理ログでの重複判定、済フォルダへの移動の三段構えにしました。レコードIDはRPT-20260804-001のような形式で、日付と連番から作っています。
手書き日報の取り込みで実際に詰まるのは、写真を誰が入れるか
プログラムより時間がかかると想定されるのは、写真がドライブに入るまでの段取りです。
紙の日報は現場から事務所に戻ってきます。それを事務所でまとめてスキャンするのか、職長が現場でスマホから上げるのか。ここをまずルール決めする必要があるでしょう。
今回は、職長が一括して特定のフォルダに写真をアップすることを想定しました。共有フォルダを職長のスマホのGoogleドライブに入れてもらい、その日のうちに撮って上げてもらう。操作としては撮って共有ボタンを押すだけで、教えることはほとんどないでしょう。かといって、スマホに慣れていない人の場合には、それでもうまくいかないケースが出てくる可能性はあります。うまくいかないというのは、操作方法が原因なのではなく、思い込みでアップロード先を間違える、というようなことです。マイドライブの直下に入ってしまったり、選択画面が前回の場所を覚えているとは限らないためです。
対応として、共有フォルダのショートカットをホーム画面に置いてもらい、そこを開いてから追加する順番にマニュアル化しておくようなことも手でしょう。ファイル名は触らせる必要はありません。
複合機のスキャン先をドライブに向ける方法もあります。事務所で完結するぶん、こちらのほうが確実です。ただし日報がシートに載るのは、紙が事務所に戻った翌日以降になります。どちらを選ぶかは、締めをどれだけ早めたいか次第です。
この仕組みが向かない手書き日報もある
一方で、どの日報でも今回つくったシステムが有効なわけではありません。
図やスケッチが主体のものは不向きでしょう。配管の位置を手描きして「ここ」「この部分」と書き込んであるような日報は、テキストとして取り出した時点で意味が失われます。この場合は無理に構造化せず、写真へのリンクだけシートに残すほうが実用的です。
1日100枚を超える規模も、今の作りのままでは苦しいと思います。1回15ファイル、呼び出しの間に5秒待ちという設定なので、100枚だとメニューを7回押すことになります。ここまで来ると、Google Apps Scriptではなく別の実行環境に移す前提になり、手元のGoogle Workspaceだけで完結するという利点が消えます。そうなると、市販のOCRサービスと費用を比べ直したほうがいいでしょう。
記入者が入れ替わり続ける現場についてもこのシステムがどこまで有効なのか懐疑的な部分もあります。今は数人分の筆跡しか通していないので、癖の強い字がどれくらいの割合で混じると読み取りが崩れるのか、実測できていないからです。手書きは印字より難しいのです！
まとめ
手書きの日報をAIで読み込む仕組みは、専用のOCRパッケージを買わなくても作れます。今回使ったのはGoogleドライブ、Google Apps Script、GeminiのAPI、スプレッドシート。すでに手元にあるものの組み合わせで動きます。
ただし、効いているのは半分がプログラムで、もう半分は紙です。マス目とチェックボックスに変えた用紙から入ってくるデータは、最初から形が揃っています。AIを入れる前に紙を直す。弊社としては、この作業が先だと考えています。
同じ考え方は、日報だけでなく点検表でも検収書でも作業指示書でも通ります。自社のどの帳票から手をつけるべきか整理したい会社は、AI業務改善診断をお試しください。