目次
「AppSheetでアプリを作ったが、データが増えたら明らかに重くなった」——ノーコードで業務アプリを作った会社から、よくいただくご相談です。
原因を調べると、アプリの作り方が悪いというより、集計の設計そのものに理由があることがほとんどです。とくに多いのが、SUM(SELECT())のような入れ子の集計式を、一覧に並ぶ行の数だけ動かしてしまっているケースです。
この記事では、実案件（匿名）で踏んだこの問題と、集計を「毎回数える」から「確定値として持つ」へ作り替えた設計の考え方を整理します。
この記事の結論
- 遅さの原因は式の巧拙ではなく、参照範囲×行数の掛け算にある
SUM(SELECT())の入れ子は、行ごとに全表走査を起こす- 増え続けるデータは、都度計算せず確定値として書き込んで持つ
SUM(SELECT())が遅くなる原因とは
SELECT()は「条件に合う行を探す」関数です。探すためには、対象テーブルを先頭から最後まで見る必要があります。1回だけなら一瞬でも、これが一覧に表示される行ごとに動くとどうなるか。
100行の一覧を表示するために、100回の全表走査が起きます。明細が1,000行あれば、単純計算で10万行分の処理です。データが増えるほど、行数の増加と走査範囲の増加が同時に効いてくるため、体感速度は加速度的に落ちていきます。
やっかいなのは、開発中は速いことです。テストデータが数十行の段階では問題が見えません。運用が始まり、伝票や明細が積み上がった半年後に「なんだか遅い」となって初めて表面化します。
ノーコードだから軽い、コードを書いたから重い、という話ではありません。重さは「参照範囲×行数」で決まる——ここが最初に押さえるべき判断軸です。
対策：集計を「数える」から「持つ」へ変える
私たちが実案件（匿名）で採った対策は、集計式のチューニングではなく、構造の作り替えでした。
考え方はシンプルです。残数を表示のたびに数え直すのをやめ、明細を登録・更新したその瞬間に、残数を直接書き込む。この形を「明細駆動の集計」と呼んでいます。
| 都度計算（従来） | 明細駆動（作り替え後） | |
|---|---|---|
| 残数の求め方 | 表示時に全明細を集計 | 登録時に前行の残数から増減 |
| 処理の重さ | 行数×全表走査 | 1行あたり1回の計算 |
| データ増加の影響 | 増えるほど遅くなる | ほぼ影響なし |
| 過去の値 | 毎回再計算される | 確定値として残る |
副次的な効果として、過去時点の残数が記録として残るという利点もあります。都度計算では「いま集計するとこうなる」しか分かりませんが、明細駆動なら各行に当時の残数が刻まれます。棚卸しや遡っての確認がしやすくなります。
明細駆動の作り方：[_THISROW-1]で前行を引き継ぐ
実装の核になるのが、[_THISROW-1]です。これは「いま処理している行の1つ前の行」を指す書き方で、直前の残数を引き継ぐために使います。
処理の流れは次のとおりです。
Upsert（登録または更新）のアクションの中で、前行の有無によって分岐させます。前行があればその残数を起点に、なければ初期値を起点に増減し、結果を自分の行に書き込む。これだけで、表示時の計算は不要になります。
ポイントは、計算のタイミングを「見るとき」から「書くとき」へ移したことです。見る回数は多く、書く回数は少ない。ならば、少ない方に処理を寄せるのが道理です。
なお、AppSheetの関数仕様や挙動は更新されることがあるため、最新の記述方法は公式ドキュメントで確認してください。
明細駆動を選ぶ前に確認すること
万能ではありません。作り替える前に、次の点を確認します。
- 明細の順序が定まっているか：
[_THISROW-1]は前後関係が前提です。順序が揺れる設計では成立しません - 過去行の修正が起きるか：途中の行を後から直すと、それ以降の残数がずれます。修正を許すなら再計算の手当てが要ります
- 同時登録が起きるか：複数人が同じタイミングで登録する業務では、前行の取り違えに注意が必要です
- そもそも遅いのか：データが増えない小規模なマスタなら、都度計算のままで十分です
判断のコツ：**「今後も増え続けるデータか」**が分かれ目です。増え続けるなら持つ、増えないなら数える。この一点で決められます。
AppSheetが遅いときの確認手順
原因の切り分けは、次の順序で進めます。
- どの画面が遅いか特定する：アプリ全体ではなく、特定の一覧やダッシュボードだけ遅いことが多いです
- その画面の仮想列・式を洗い出す：
SELECT()やFILTER()が入れ子になっている箇所を探します - 参照範囲×行数を見積もる：表示行数と、参照先テーブルの行数を掛けます。ここが大きければ原因はほぼ確定です
- 持つか数えるかを決める：増え続けるデータなら明細駆動へ。そうでなければ参照範囲を絞る方向で調整します
式を短く書き直す前に、そもそも何回動いているかを見る。これが遠回りに見えて一番速い進め方です。
ノーコードでも「設計」は要る
AppSheetのようなノーコードツールは、画面を作るところまでは誰でも早く進めます。ただ、データが増えたときにどう振る舞うかは、作った人の設計判断で決まります。
集計式は書きやすく、動いているうちは正しく見えます。だからこそ、運用が始まってから静かに重くなる。ノーコードだから設計が不要になるのではなく、設計の責任がツールから作った人へ移っていると考えるのが正確です。
「増え続けるデータは、毎回数えず確定値として持つ」——この向きさえ押さえておけば、ツールが変わっても応用が効きます。
よくある質問
Q. AppSheetでSUM(SELECT())を使うと遅くなるのはなぜですか？ SELECTは条件に合う行を探すため対象テーブル全体を走査します。表示する行ごとにこの式が動くと、行数×全表分の計算が発生し、データが増えるほど体感速度が落ちます。
Q. AppSheetの動作が遅いとき、まず何を確認すればいいですか？ 式の書き方より先に、集計式が何行に対して動いているかを確認します。重さは「参照範囲×行数」で決まるため、リスト表示や仮想列の中の入れ子集計が最初の疑い先です。
Q. 在庫の残数は毎回計算するのと保存するのと、どちらがよいですか？ データが増え続ける業務では保存が有利です。明細の登録・更新時に前行の残数から増減を反映して確定値として書き込めば、表示のたびに数え直す必要がなくなります。
まとめ
- AppSheetが遅くなる原因の多くは、
SUM(SELECT())の入れ子による行ごとの全表走査 - 重さは参照範囲×行数で決まる。ノーコードかどうかは関係ない
- 対策は式の調整ではなく、明細の登録時に残数を書き込む明細駆動への作り替え
[_THISROW-1]で前行の残数を引き継ぎ、計算を「見るとき」から「書くとき」へ移す- 判断軸は「今後も増え続けるデータか」。増えるなら持つ、増えないなら数える
RENOYでは、AppSheetで作ったアプリが重くなった場合の原因診断と、増えても遅くならないデータ構造への作り替えをご支援しています。「動いてはいるが、この先が不安」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。