目次
「AppSheetなら社内で作れる」——ノーコードツールとして、AppSheetはそう紹介されることが多いサービスです。実際、Googleスプレッドシートを土台に、プログラムを書かずに現場アプリを作れるのは大きな魅力です。
ただ、私たちが複数の案件でAppSheetの内製を進めてきた中では、作り始めてから気づく壁がいくつもありました。途中で作り直しになったもの、運用ルールで回避したもの、AppSheetの外に切り出したものもあります。
この記事では、実案件（匿名）で踏んだ6つの壁を紹介し、そこから導いた「AppSheetで内製する業務・しない業務」の線引きを整理します。
この記事の結論
- 画面の自由度が要る業務はAppSheetの外に出す
- 大量集計と同時実行は、作る前に設計を決める
- 保存先と環境運用は着手前に決めておく
AppSheetの集計が重くなる原因と対策
最初の壁は集計の重さです。
ある案件では、親テーブルの合計を出すために、明細テーブルから該当行を探して合計する式（SUM(SELECT())）を使い、さらにそれを入れ子にしていました。データが少ないうちは問題なく動きますが、データが増えるほど重くなり、最終的に作り替えが必要になりました。
原因は、表示や更新のたびに、他テーブルの行を探して合計し直す計算が走ることです。入れ子になるほど、その計算は掛け算で増えていきます。
対策として、明細駆動の直接加減算に作り替えました。明細が追加・変更・削除されたときに、その差分だけを親の合計に足し引きする方式です。毎回全体を数え直さないため、データが増えても重くなりにくくなります。
最初から「件数が増えたらどうなるか」を考えて集計方式を選ぶことが、後の作り直しを防ぎます。
Botの多重発火・二重処理の原因
次の壁は、自動処理（Bot）まわりの同時実行です。
Grouped Actionで Bot が多重発火する
複数の操作をまとめて実行するGrouped Actionを使ったところ、中の各サブアクションが別々のイベント扱いになり、それぞれをきっかけにBotが発火しました。1回のボタン操作のつもりが、裏で自動処理が何度も走る状態です。
「処理中」表示を一時レコードで持つと崩れる
処理中であることを画面に出すため、一時的なレコードを作って表示する方式を試しました。すると、表示が途中で消える、何も起きないまま空振りする、同じ処理が二重に走る、といった問題が起きました。
どちらも、「いつ・何回・どの順で処理が走るか」を先に設計していないことが根本原因です。自動処理が絡む業務では、発火のきっかけと二重実行の防ぎ方を、画面より先に決める必要があります。
運用で効く壁：ステージングがなく、保存先も変えられない
作った後の運用でも、AppSheet特有の壁がありました。
ステージング環境がない
本番とは別に試験用の環境（ステージング）を持てなかったため、修正中のアプリを別に用意し、完成したらリネームして本番に昇格させるという世代交代の運用が必要になりました。利用者が使っているアプリを直接いじらないための工夫ですが、手順を決めておかないと混乱のもとになります。
保存先は後から変更できない
データの保存先は後から切り替えられず、Copy Appでアプリを複製するのが唯一の移行手段でした。「最初はスプレッドシートで、あとで別のデータベースに」という計画は、そのままでは成り立ちません。
いずれも、着手前に決めておけば避けられる壁です。なお、AppSheetの仕様は変わるため、最新の条件は必ず公式で確認してください。
画面の自由度が必要ならAppSheetの外に出す
最後の壁は画面レイアウトの自由度です。
ある案件では、手書き帳票のような入力画面が求められました。しかしAppSheetの画面は、一覧・フォームなど決まった型を組み合わせる作りで、帳票そのままの自由な配置は実現できませんでした。
そこで、その入力部分だけをGAS WebAppに切り出しました。データの管理や他の画面はAppSheetに残し、自由度が必要なところだけ別の手段で作る構成です。
「全部をAppSheetで」とこだわるより、得意な部分だけを任せるほうが、結果的に早く、現場に合ったものになります。
AppSheetで内製する業務の選び方
6つの壁を整理すると、着手前に確認すべき観点は3つに絞れます。
| 観点 | 内製しやすい業務 | 設計・別手段が先の業務 |
|---|---|---|
| 画面 | 一覧・フォームの標準画面で足りる | 帳票のような自由な配置が必要 |
| 集計 | 件数が少ない／集計が軽い | データが増え続け、集計が多い |
| 同時実行 | 自動処理が少ない | Botや一括操作が重なる |
| 運用 | 保存先・環境が固まっている | 保存先を後で変える予定がある |
判断の流れは次のとおりです。
ポイントは、「できない」から諦めるのではなく、どこで立ち止まって設計するかを知っておくことです。3つの観点に当てはまらない業務は、AppSheetで素直に内製できます。当てはまる業務も、設計を先に決めるか、一部を別手段に切り出せば形にできます。
まとめ
- 集計は明細駆動の直接加減算で、データが増えても重くならない形にする
- Grouped ActionやBotは、発火の回数と順序を先に設計する
- ステージングがないため、世代交代の運用手順を決めておく
- 保存先は後から変えられず、移行はCopy Appのみ。着手前に確定させる
- 画面の自由度が必要な部分は、GAS WebApp等に切り出す
よくある質問
Q. AppSheetで内製に向いている業務は何ですか？ 入力項目が決まっていて標準的な一覧・フォーム画面で足り、集計が軽く、同時に処理が走りにくい業務が向いています。逆に、画面の自由度・大量集計・同時実行が絡む業務は、作り始める前に設計や別手段の検討を済ませておくのが安全です。
Q. AppSheetの集計が遅くなるのはなぜですか？ SUM(SELECT())のように、他テーブルの行を探して合計する式を入れ子で使うと、データが増えるほど計算量が膨らむためです。明細が増減したときに親の合計を直接加減算する、明細駆動の設計に作り替えると改善します。
Q. AppSheetのデータ保存先は後から変更できますか？ 実案件では保存先を後から切り替えることはできず、Copy Appでアプリを複製して新しい保存先に載せ替えるのが唯一の移行手段でした。保存先は着手前に決めておくのが安全です。仕様は変わるため最新は公式で確認してください。
RENOYでは、AppSheetでの内製を始める前に「この業務はAppSheetで作れるか、どこを設計・切り出すべきか」を整理するところから、無料相談で承っています。「作り始めたけれど重くなってきた」「どこまで内製できるか分からない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。