圏外で「要再点検」、事務所では「再点検不要」。現場入力の同期で食い違う記録の扱い

たとえば、地下の設備室で「要再点検」と入力し、写真2枚を端末に保存した点検員A。その間に、事務所側の担当者Bは同じ記録を「再点検不要」へ更新していました。Aが再接続したら、両方の訂正を並べ、責任者が残す内容を決める必要があります（想定例）。

場面	届いているもの	まだ終わっていないこと
Aが圏外で保存	Aの端末内に記録と写真2枚	事務所への送信
Bが先に更新	Bの訂正本文がサーバーへ到着	Aの変更と写真は未受信
Aが再接続	二つの訂正を比較する段階	採用内容の決定、写真の受信、両端末の再取得

端末に保存できたこと、サーバーに本文が届いたこと、点検の提出が終わったことは別です。出発前の準備から、この違いを確かめます。

Microsoftの「Work with canvas apps offline」には、初回取得、圏外での利用、再接続後の同期状況を区別する説明があります。本稿では、その概念を参考に、現場で確かめる項目を整理します。

出発前に、対象の設備と点検項目を開く

最初に、圏外で使う端末、アプリの版、利用者の権限、対象設備、入力様式をそろえます。設備一覧だけ取得できても、点検項目の選択肢や前回の記録がなければ必要な入力を終えられません。対象設備を実際に開き、担当範囲の情報が端末にあることを確認します。

Microsoftの説明では、オフライン利用の前に必要データを初回同期で取得します。初回同期が終わっていない場合は、次にアプリを開いたときも取得が試みられます。現場で初めて起動する前提にせず、通信できる場所で完了を確かめます。

Power Appsのオフライン利用は、端末と保存方式によって対応範囲が異なります。Microsoftは、キャンバスアプリのオフライン利用をPower Apps Mobileのネイティブプレーヤーで説明し、Webブラウザー上ではオフライン実行できないとしています。また、Dataverseを使う組み込みの方式と、LoadData／SaveDataで端末保存を作る方式は別です。利用する製品ごとに、対応する端末と保存方法を確かめてください。

通し例では、9月10日8時30分にA・Bの両端末へ同じ点検記録を取得してから出発します。出発前の準備は、後掲の表1の①に対応します。

圏外で保存した記録は、まだ提出されていない

「保存した場所」と「提出状況」を分ける

点検結果、メモ、写真のうち、現場で残す必要がある項目を決めます。オンラインの台帳照会や承認処理が必要な項目は、圏外で記入できる部分と、帰社後に確定する部分を分けてください。保存を押した後に、何を見れば端末に残ったと判断できるかも決めます。

本稿では、端末に残った状態を「端末保存済み」、まだ送れていない状態を「同期待ち」と呼びます。通信が戻っても、処理中なら「同期中」、確認が必要なら「要確認」、失敗したなら「同期失敗」と表示する設計を考えます。「反映済み」は、対象の変更と必須写真をサーバー側で確認できた状態です。これらは業務向けの表示案です。製品の画面表示と照らし合わせて使います。Microsoftの資料でも、接続の有無、処理中、未送信の変更、エラー・警告は区別されています。

表1の②では、Aが10時10分に圏外で点検結果を「要再点検」に変え、仮版v1-Aとして保存した状態を置きます。これは未送信の変更です。試すときは機内モードに加えてWi-Fiなどの通信も切り、保存後にアプリを閉じる、端末を再起動する、といった条件を試します。保存に失敗した場合に、担当者へ知らせず入力画面だけ消える運用は避けます。

さらに、反映済みと業務上の提出完了も分けます。責任者の承認が必要な点検なら、サーバーへ届いただけで承認済みにしません。入力担当は端末保存、確認担当は受信内容、責任者は採用する訂正と提出完了を確認する、という役割分担にします。圏外で書いた日報をまとめて集計する場合も、この状態の分け方が役立ちます（日報の回収・集計を楽にする方法）。

写真2枚も、事務所で開けるまで確かめる

本文と写真は、同じ記録IDに結び付いていても、見る項目を分けます。Aは、同じ点検記録に写真を2枚添付します。端末で縮小画像が見えることを、サーバーに元の写真が届いた証拠にはしません。受信側で2枚を開けるか、別の記録へ付いていないかを確かめます。

写真については、1枚の容量、1回の作業の最大枚数、圏外で作業する期間、端末の空き容量を試す条件に記入します。容量はMBなど単位をそろえ、圧縮前か後かも明示してください。製品の上限を確認したうえで、実際の端末と想定最大量で保存・再送を試します。

本文が先に届いて写真が後になる場合や、写真の1枚だけが届く場合も確かめます。送信順を指定できるかは、製品ごとに調べます。順序そのものより、途中で何が残っているかと、どの条件で提出完了にするかを決めます。写真必須の記録は、片方が未送信なら完了にしません。

再送時は、本文の記録IDに加えて写真IDも照合します。二重に添付されないか、再撮影した写真が古い写真へ戻らないかを試してください。部分的な失敗は、記入用チェック表のT04、容量不足はT05で扱います。

再接続したら、先に届いた訂正と比べる

同じ変更の再送と、別の訂正を見分ける

再接続して通信マークが戻っただけでは試験を終えません。送信後の応答が途切れた場面を作り、同じ変更を送り直しても二重登録しないかを試します。受信側で記録が一件のままか、写真が増えていないかを確認します。

Bの本文がサーバーへ届いても、Aの写真2枚は届いていません。記入表の「本文受信済み・写真未受信」は、記録全体の完了を意味しません。

もう一つは、同じ記録を複数端末で変更した場合です。表1の③では、Aが未送信の間にBが10時20分に点検結果を「再点検不要」へ訂正し、サーバー側をv2にした状態を置きます。Aが11時に再接続したら、Aの「要再点検」とBの「再点検不要」を両方表示し、どちらを採用するか責任者が確認できるようにします。後から保存されたという理由だけで上書きしません。

ここで求めるのは、両方の内容を残して「要確認」とし、責任者が採用内容を決められることです。ただし、これをPower Appsの標準挙動とはみなしません。Microsoftの別資料には、Dataverseでは各列の最後の更新が保存され、競合する変更だけでは同期が失敗しないという説明があります。同資料の競合解決設定はキャンバスアプリには適用されないとの注意もあります。

したがって「自動同期できる」と「業務上必要な訂正確認ができる」は別の評価です。保留や変更履歴の比較ができない製品なら、同じ記録を同時編集しない、端末ごとに作業記録を分けて責任者が統合する、といった運用で足りるかを判断します。それでも必要な内容を守れない場合に追加設計を検討します。

開発担当者へ：再送と訂正を区別する

確認表では記録IDをINSP-060、端末IDをDEV-A・DEV-B、出発時の版をv1としています。同じ変更を送り直す際は送信操作ID「OP-A-01」を維持し、別の訂正には別の操作IDを付けます。Aが編集した元版v1と、Bが先に保存したv2を比較して競合を検出する設計です。識別方法や版の表示は採用製品に合わせます。

図1　圏外保存から別端末訂正、再接続後の照合まで。④では訂正を保留し、⑤で責任者が内容を確定します。

責任者は、解決者、採用した内容と理由を残し、確定版v3をサーバーとA・Bで照合します。写真2枚が届いたことも見てから提出完了にします。変更が同じ項目へ重なる場合だけでなく、別項目の訂正や取消・削除も別の条件として試してください。

再接続時は、アプリが前面にあるか、画面がロックされていないかも記録します。Microsoftのキャンバスアプリ向け制限資料では、定期的な同期について前面起動と画面ロック解除の条件が説明されています。放置すれば終わると決めず、採用環境の条件を確かめます。

再試行の仕組みや二重実行の防止、障害後の突合を詳しく整理する場合は、API連携の要件｜待ち時間・再送・二重実行が参考になります。

訂正の競合と写真の受領を、小さな模型で分けて試す

2026年10月26日、上のA・Bの訂正と写真IDの受領を、再現教材（Python）で追いました。端末・通信・Power Appsを動かした試験ではなく、メモリー内の状態遷移だけを確認する教材です。

模型へ入れた条件	確認できた状態
Bがv2へ更新した後、元版v1のAが送る	Bの「再点検不要」を残し、Aの「要再点検」を要確認として別に保持
責任者が採用したv3に、P01だけ届く	必須のP02がないので写真の受領は未完了
P02が届き、同じP02を再送	写真IDは2件のまま。受領条件を満たす

これにより「訂正の決定待ち」と「写真の到着待ち」は別の状態だと確かめられます。実端末では写真の実体を開けること、アプリを閉じた後の保存、権限・容量・同期条件も試します。模型で写真IDが2件そろったことを、実際の写真2枚が端末間で保存・転送できた結果へ読み替えないでください。

端末を失くしたら、未送信の記録はどうなるか

持ち出す範囲と、消してよい条件を先に決める

必要な情報を端末に置くことは、持ち出す情報を決めることでもあります。対象現場、設備、利用期間を絞り、業務に不要な個人情報や過去記録まで取得しない運用を検討します。端末のロック、保存データの保護、利用者の交代時の扱いは、端末管理者と確認してください。

Aの端末を未送信のまま紛失した場合、端末にしかない変更と写真は、サーバーから復元する対象がありません。端末ID、最後に反映が分かった記録、未提出の対象を照合し、現場責任者が再点検の要否を判断します。連絡先、アカウント・端末の利用停止手順、対応の記録方法も事前に決めます。遠隔削除を使う場合も、圏外端末へ直ちに届く前提にはしません。

端末が戻ってきたときは、すぐに初期化せず、未送信分の扱いを管理者と決めます。削除は、サーバーの内容と写真、必要な保管、業務上の提出完了を確かめた後に行う手順とします。ただし、漏えい対応などで先に利用停止・削除が必要な場合は、自社の対応方針を優先し、復元できない記録を別に確認します。共有端末では、次の利用者が前の担当者の記録を見られないかも試します。

自分の端末で確かめる

試験に使う資料として、確認表（Excel）と配布用チェック表（PDF・8ページ）を利用できます。Excelには記入例・空欄版と12の確認ケースがあります。

確認表は「期待」と「実際」を別々に書く

表1の⑤は、試験後に目指す状態です。「期待される判断」と「実測結果」を分け、試していない実測欄は空欄のまま残しています。確認条件に対象端末・OS・アプリ版・通信条件を追記し、実施日を入れてから実機の結果を記入してください。

表1　圏外保存から再同期までの5場面の確認表（確認条件の記入例）。

① 事前同期

項目	① 事前同期（記入例）
記録ID	INSP-060
端末ID	DEV-A／DEV-B
保存時刻	2026-09-10 08:30 JST（想定）
同期状態	事前同期済み
写真状態	写真は未追加
元版	v1
変更版	変更なし（v1）
競合理由	なし
解決者	対象外
期待される判断	両端末で同じ設備・様式・権限とv1を確認してから出発する。
実測結果（未実施は空欄）
確認条件・実施日（未実施と区別）	未実施／条件：両端末をオンラインで初回同期／実施日：

② Aの圏外保存

項目	② Aの圏外保存（記入例）
記録ID	INSP-060
端末ID	DEV-A
保存時刻	2026-09-10 10:10 JST（想定）
同期状態	同期待ち
写真状態	P01・P02の2枚は端末内のみ
元版	v1
変更版	v1-A（要再点検／端末内の仮版）
競合理由	この時点ではサーバーの変更を未確認
解決者	未解決（点検責任者へ引継ぎ）
期待される判断	端末保存を確認しても提出完了にしない。圏外で再起動した後も記録と写真を開けるか試す。
実測結果（未実施は空欄）
確認条件・実施日（未実施と区別）	未実施／条件：Aの通信を切断。送信操作IDはOP-A-01／実施日：

③ Bのオンライン訂正

項目	③ Bのオンライン訂正（記入例）
記録ID	INSP-060
端末ID	DEV-B
保存時刻	2026-09-10 10:20 JST（想定）
同期状態	本文受信済み・写真未受信
写真状態	追加なし／Aの2枚は未受信
元版	v1
変更版	v2（再点検不要／サーバー側）
競合理由	AとBが同じ「点検結果」を別内容に変更
解決者	未解決（点検責任者へ引継ぎ）
期待される判断	Bの訂正が届いても、Aの未送信変更と写真がそろうまで記録全体を提出完了にしない。
実測結果（未実施は空欄）
確認条件・実施日（未実施と区別）	未実施／条件：Bで同じ記録の点検結果を訂正して送信／実施日：

④ Aの再接続・照合

項目	④ Aの再接続・照合（記入例）
記録ID	INSP-060
端末ID	DEV-A
保存時刻	Aの保存は10:10／再接続は11:00 JST（想定）
同期状態	要確認
写真状態	P01・P02の受信状態を個別に照合
元版	Aの元版v1／サーバー現行v2
変更版	v1-Aは保留／v2と比較
競合理由	元版の相違＋同じ項目への異なる訂正
解決者	点検責任者（確認予定）
期待される判断	両方の内容を残して確認する。同じOP-A-01の再送で二重登録しないかも試す。
実測結果（未実施は空欄）
確認条件・実施日（未実施と区別）	未実施／条件：Aを再接続。版比較・保留の実現可否を確認／実施日：

⑤ 解決・反映確認

項目	⑤ 解決・反映確認（記入例）
記録ID	INSP-060
端末ID	DEV-B（責任者）／DEV-A（再取得）
保存時刻	未定（解決後）
同期状態	反映済み（到達条件）
写真状態	P01・P02の2枚をサーバー側で開けること
元版	v1-Aとv2を比較
変更版	v3（責任者が決めた確定版）
競合理由	解決理由を記録して終了
解決者	点検責任者（担当者名は実施時に記入）
期待される判断	確定内容・写真・理由を確認し、AとBでv3を再取得できてから業務上の提出完了にする。
実測結果（未実施は空欄）
確認条件・実施日（未実施と区別）	未実施／条件：解決、写真受信、両端末の再取得を確認／実施日：

確認表で不足を確かめてから選ぶ

既製の現場アプリで必要項目と写真を扱え、端末・保存量・再起動・再送・競合の試験に合格し、権限と紛失時の運用まで決められるなら、追加開発を前提にする必要はありません。圏外作業が少なく、記録と写真の対応や帰社後の転記漏れを管理できるなら、紙を残す方法も比較対象です。

一方、記録IDと端末IDを対応付ける方法、未送信写真の見せ方、複数端末の訂正を誰が確定するかが既製機能や運用で満たせない場合は、その不足を確認表に残します。対象端末と記録見本を用意し、代表端末で何を試すかを絞って相談すると、必要な対応を具体的に検討できます。

Power Appsを候補にする場合は、導入前に調べる連携・費用・運用の条件も参考になります。

人の入力とセンサー値を合わせる場合は、測定時刻と届いた時刻を区別して使う条件も決めます（センサーデータの使い方｜欠測・遅延・重複を見分ける）。

オフライン現場入力の開発相談へ

参考出典

• Microsoft「Work with canvas apps offline」
• Microsoft「Develop offline-capable canvas apps」
• Microsoft「Resolve sync conflicts with the server」
• Microsoft「Mobile offline limitations for canvas apps」

出典確認日：2026年9月15日。Power Appsの初回取得・同期表示、対応端末・保存方法、列単位の競合処理、同期時の前面起動・ロック解除の条件を参照しています。④の手動保留と⑤の確定は、本稿で提案する業務上の設計です。