目次
AppSheetで業務アプリを作っていると、必ずぶつかるのが「時間のかかる処理」です。ボタンを押してから裏側の処理が終わるまで数秒〜十数秒かかる。その間、画面に何も出ないと、現場は必ずもう一度ボタンを押します。
そこで多くの人が思いつくのが、処理中であることを表す一時レコードを作るという実装です。専用のテーブルに1行足して、その行があるあいだだけ「処理中です」と表示する。発想としては自然ですし、実際に動きます。
ただ、この方式は実案件（匿名）で3つの本番障害を引き起こしました。そして、1つずつ潰しても別の形で再発しました。この記事では、その実録と、最終的に到達した設計の原則を整理します。
この記事の結論
- 処理中表示のための一時レコードは本番で必ず壊れる
- UIの状態は一時データではなく本データの属性で持つ
- フラグ列・時間ベース復帰・書き戻しシグナルの3点セットで解決する
AppSheetの「処理中」表示とは
AppSheetのアプリは、端末側のデータとサーバー側のデータを同期しながら動きます。ボタン操作をきっかけにGASや外部処理を呼ぶ構成では、処理そのものはアプリの外で走るため、アプリ側は「いま処理が走っているかどうか」を自力では知りません。
だから、処理中であることを何らかのデータとして持ち、その有無で表示を切り替える必要があります。ここで持ち方を間違えると、以下のような形で表面化します。
なお、AppSheetの同期や自動化の挙動は仕様変更があり得るため、最新の条件は公式ドキュメントで確認してください。
一時レコード方式で起きた3つの障害の原因
障害1：表示消失
処理が終わっていないのに、画面から「処理中」の表示が消える現象です。原因は同期のタイミングでした。端末側で作った一時レコードが、その後の同期でサーバー側のデータと突き合わされた際に整理され、表示の根拠が先に消えてしまう。ユーザーから見ると「処理が失敗した」ようにしか見えません。
障害2：無言空振り
逆に、ボタンを押しても一時レコードが作られず、画面が何も変わらないケースです。条件式のわずかな不一致や、同期の遅れで表示が追いつかないことが原因でした。裏では処理が走っているのに、現場には何も起きていないように見えるという、最もクレームにつながる状態です。
障害3：二重処理
障害1と2の必然的な帰結として、ユーザーが再度ボタンを押します。結果、同じ処理が2回走る。帳票の二重発行やデータの重複が発生し、後始末に人手がかかりました。
| 障害 | ユーザーから見た症状 | 直接の原因 |
|---|---|---|
| 表示消失 | 処理中の表示が急に消える | 同期で一時レコードが整理される |
| 無言空振り | 押しても何も起きない | 一時レコードが作られない・表示が遅れる |
| 二重処理 | 同じ処理が2回走る | 上記2つによる再操作 |
なぜ個別対策では再発したのか
最初は、それぞれを個別に潰しにいきました。条件式を厳しくする、同期のタイミングを調整する、ボタンの表示条件を追加する——どれも一時的には収まります。しかし、しばらく運用すると別の場所で同じ種類の不整合が出ました。
原因は実装の粗さではなく、設計そのものにありました。一時レコードは「そこにある／ない」で状態を表しますが、AppSheetの同期は行の作成・削除・整理を自律的に行います。つまり、アプリが自由に動かす対象に、人間が見る状態を預けてしまっていたわけです。
ここから導いた原則が1つです。UIの状態を一時データで持たない。状態は、消えたり作られたりしない場所、つまり業務データそのものに持たせます。
正しい設計｜フラグ列＋時間ベース復帰＋書き戻しシグナル
到達した構成は次の3点セットです。
1. 本データのフラグ列
処理の対象となるレコード自体に、処理中かどうかを表す列と、処理を開始した時刻の列を持たせます。行は最初から存在しているので、同期で消えることはありません。ボタン操作では新しい行を作らず、この列を更新するだけにします。
2. 時間ベース復帰
処理が異常終了したり、完了の通知が届かなかった場合に備え、開始時刻から一定時間が過ぎたら処理中とみなさない条件にします。これで「永久に処理中のまま固まる行」がなくなり、担当者が手でフラグを戻す運用も不要になります。
3. GAS側からの書き戻しシグナル
処理を担うGAS側が、完了時に対象行のフラグを落とします。アプリ側で完了を推測するのではなく、処理した本人が終わったと書き込む形にするのが要点です。アプリは書き戻された値を見るだけになり、判断が一箇所に集約されます。
方式の比較
| 観点 | 一時レコード方式 | フラグ列方式 |
|---|---|---|
| 状態の置き場所 | 同期で増減する一時データ | 常に存在する業務データ |
| 表示消失 | 起きる | 起きにくい |
| 異常終了時 | 手動での後始末が必要 | 時間経過で自動復帰 |
| 二重処理の抑止 | 表示に依存し不安定 | フラグでボタン自体を止められる |
| 完了の判定 | アプリ側の推測 | 処理側からの書き戻し |
フラグ列方式では、処理中フラグが立っている行はボタンを非表示または無効にできます。二重処理は表示の工夫ではなく、データの状態で止めるのが本筋です。
同じ失敗を避けるためのチェックポイント
- 処理中・送信済みなどの状態を、専用テーブルの行の有無で表していないか
- 処理が途中で落ちたとき、状態が自動で元に戻る仕組みがあるか
- 完了の判定を、処理を実行した側が書き戻しているか
- 状態が処理中のあいだ、操作ボタンそのものを止めているか
この4つを設計段階で満たしておけば、今回の3障害はまとめて発生しません。逆に、動くものを先に作ってから後付けで対処すると、私たちのように潰しては再発を繰り返すことになります。
よくある質問
Q. AppSheetで処理中の表示を出すにはどうすればいいですか？ 一時レコードではなく、対象データそのものに処理中フラグ列と開始時刻を持たせ、その値で表示を切り替えます。完了時は処理側からフラグを落とし、同時に時間経過での自動復帰も用意します。
Q. 処理中表示のために一時レコードを作るのはなぜ良くないのですか？ 一時レコードは同期のたびに作られたり消えたりするため、表示が突然消える、作られず無反応になるなどの不整合が起きます。UIの状態は一時データではなく本データの属性として持つのが安全です。
Q. 処理が途中で止まったとき、処理中のまま固まらないようにできますか？ 開始時刻を保存し、一定時間を過ぎたら処理中とみなさない条件にします。処理側からの完了シグナルが届かなくても表示が自動で戻るため、担当者が手作業で直す必要がなくなります。
まとめ
- AppSheetの処理中表示を一時レコードで作ると、表示消失・無言空振り・二重処理が起きる
- 原因は実装ではなく設計。UIの状態を一時データで持たないのが原則
- 正解は本データのフラグ列・時間ベース復帰・処理側からの書き戻しの3点セット
- 二重処理は表示の工夫ではなく、データの状態で操作を止めることで防ぐ
RENOYでは、AppSheetやGASで作った業務アプリが「動くけれど現場で事故る」段階のご相談も多くいただきます。作り直しではなく、状態の持ち方だけを見直せば解決するケースも少なくありません。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。