コラム仕組みと技術

電波の届かない現場で日報を入力するには?圏外で書いて、つながってから送るオフライン入力を30回試した

• 公開 2026年10月17日
• 更新 2026年10月17日
• 事実の確認 2026年10月17日
• 書いた人 現場のまど 主宰(元AIエンジニア)

オフラインで日報を入力して送る試験を各条件30回したところ、下書きを残さない作りでは10件が消え、5件が二重に届きました。端末に下書きを残して自動で再送すると消えた件数は0件ですが、サーバーが受け取ったのに返事だけが途切れた10回は二重に届きます。入力した時点で番号を付けると、30回とも1件ずつ届きました。現場のまどが試作のリンク入力で、通信を切るタイミングを送信前・送信中・送信直後に分けて数えた結果です。(2026年10月時点)

全体の流れと費用は現場管理アプリの独自開発のページにまとめています。

要点

• 圏外で日報を30回送ると、下書きなしは20件が届き、10件が消え、5件が二重に届きました(試作のフォーム、Chromiumで通信を切った試験)。
• 端末に下書きを残して自動で再送すると、消えた件数は0件になりました。ただし返事だけが途切れた10回は、10件とも二重に届きました。
• 入力した時点で番号を付け、サーバーが同じ番号を1件にまとめると、30回とも1件ずつ届きました。
• 試験は実機の電波ではなくブラウザの通信遮断で、圏外は1〜5秒です。数分以上の圏外や機種ごとの違いは試していません。

圏外で日報を送ると、何件が消えて、何件が二重になりますか?

下書きを残さない作りでは、30回のうち10件が消え、5件が二重に届きました。端末に下書きを残して自動で再送する作りは、消えた件数が0件でした。入力した時点で番号を付けた作りだけが、30回とも1件ずつ届いています。

現場のまどの試作のリンク入力を、通信を切って操作した結果を、条件ごとに数えました。表は各30回の件数です。

下書きを足すと入力は消えなくなりますが、再送が始まるので二重が増えます。二重を止めるのが番号です。同じ報告が2件届くと、所長は出面を二重に数えかねません。

どんな条件で、何回試したのですか?

選ぶだけの日報フォームを、ブラウザ自動操作のPlaywright(Chromium)で動かしました。3つの作りと3つのタイミングを各10回ずつ、計90回です。1回に1件を送り、サーバーに保存された件数を数えています。

切るタイミングは次の3通りです。

1. 送信前:送信ボタンを押す前に通信を切る
2. 送信中:送信が端末を出たあと、サーバーへ着く前に切れる
3. 送信直後:サーバーは受け取って保存したが、返事が端末へ戻る前に切れる

10回のうち奇数回目は、圏外のあいだにページを開き直しました。ブラウザがタブを破棄した場面を想定しています。圏外の長さは1〜5秒です。下書きなしで開き直さなかった回は、職長がエラーを見てもう一度「送信する」を押すと仮定しました。

サーバー側で番号を扱う部分は、次の数行です。台本は実験の台本とデータ(zip)の offline_report.py で、python offline_report.py で同じ試験を動かせます。

key = self.headers.get('idempotency-key')
with LOCK:
    if key and key in SEEN_KEYS:
        pass                       # 同じ番号は保存しない(返事だけ返す)
    else:
        if key: SEEN_KEYS.add(key)
        STORE[body['rid']] = STORE.get(body['rid'], 0) + 1

限界もあります。通信の遮断はブラウザの機能で、実機の電波が揺れる様子とは違います。iPhoneのSafariやAndroidの機種ごとの動きは試していません。乱数を使わない台本なので、結果は確率ではなく「この作りで起きるか」を見たものです。

入力が消えるのは、どんなときですか?

送信ボタンを押す前後で圏外になり、画面を開き直した場面で消えます。下書きなしの30回では、送信前と送信中の各10回で5回ずつ、計10件が消えました。開き直さなかった10回は、画面に残った入力を職長が押し直して届いています。

開き直しで消えるのは、入力が画面の中にしかないからです。下書きを端末のブラウザに保存した2条件では、開き直した30回を含む60回で、消えた入力は0件でした。

下書きにも弱点があります。MDN Web Docsによると、ブラウザの保存は利用者が設定で消すと失われます。Safariは、サイト間の追跡防止が有効なとき、7日間操作のなかったサイトのデータを消します。送る前に履歴を消さない、数日放置しない、という注意は、職人向けの使い方の紙に書いておきます。

もう1つ、試作の限界があります。圏外ではページ自体が開けないので、開き直した回は、通信が戻ってからリンクを開いています。地下やトンネルへ入る前に開いておくか、画面を端末に保存する仕組み(Service Worker)を足します。試作は後者に対応していません。

二重に届くのは、なぜですか?番号をつけると防げますか?

サーバーが受け取ったのに、返事だけが途切れると、端末は失敗と受け取って再送します。そのためサーバーには同じ報告が2件残ります。送信直後に切った10回は、下書き+自動再送(番号なし)で10回とも二重でした。

下書きなしでも、職長がエラーを見て押し直すと同じ形で二重になります。送信直後の10回のうち、開き直さなかった5回が二重でした。開き直した5回は、サーバーに1件届いているのに、職長にはそれが分かりません。

防ぐ方法は、入力した時点で報告に番号(UUID)を付け、再送でも同じ番号で送ることです。サーバーは、同じ番号が来たら2件目を保存しません。IETFのhttpapi作業部会のドラフトも、番号にはUUIDなどの乱数を推奨し(第2.2節)、同じ番号の再送には前回の結果を返すのが望ましいとしています(第2.6節)。期限切れのドラフトで、正式な規格ではありません。

番号を付けた作りは、送信直後の10回も1件のままでした。サーバーには再送が届いていますが、番号が同じなので保存されていません。

電波の表示を見て、送るかどうかを決めてよいですか?

決めないほうがよいです。ブラウザが持つ「オンラインかどうか」の値は、当てになりません。MDN Web Docsは、LANにつながっていれば外へ出られなくてもオンライン扱いになる、と説明しています。この値で機能を止めないことも勧めています。

試作は、電波の表示を見ません。送ってみて返事が着かなければ、下書きを残して待ちます。再送は、通信が戻ったとき(onlineイベント)と、2秒おきの2つで起こします。どちらかが外れても、もう一方が拾います。

職人の画面には、送れていない件数を上に出します。所長の一覧では、「まだ届いていない」と「入力していない」を分けて表示します。この2つが同じ空欄に見えると、所長は職人に確認の電話をかけることになります。

「定着に不安」という声に、この試験は答えになりますか?

一部の不安には答えられますが、調査はその不安の中身を聞いていません。現場TECHは施工管理の情報メディアの運営者で、2026年3月に建設業従事者426人へ調査しました。アプリを導入していない290件の回答で、未導入の理由に「現場定着への不安」を挙げたのは、小規模企業46.4%、中規模47.1%、大規模31.6%です。区分ごとの人数はリリースに出ていません。

この数字から、圏外で入力が消える不安の割合は分かりません。分かるのは、消えない作りと二重にならない作りが、試作で成り立つことまでです。

職人が使い続けるかどうかは、送れたと画面で分かるかにも左右されます。送れていない件数を上に出し、届いたら消すのは、そのための表示です。

関連は次の3つです。協力会社が登録なしで入力する方法は協力会社がアカウントなしで日報アプリに入力するには、入力にかかる時間は協力会社の現場報告はLINEとアプリどちらが早いかにまとめました。作り全体は現場管理アプリの独自開発のガイドにあります。

このサイトで相談するには?

電波の届かない現場の日報をどう受け取るか、という段階のご相談でも構いません。

現場のまどでは、何をどう頼むか決まっていなくても大丈夫です。御社のやり方に合わせて、進め方を一緒に考えます。準備は要りません。無料で相談するからお送りください。