目次
AppSheetで現場アプリを運用していると、「項目を1つ増やしたい」という要望は必ず出てきます。スプレッドシートに列を1本足すだけなので、つい気軽に作業してしまいがちです。
ところが、本番アプリと修正中のアプリが同じスプレッドシートを参照している構成では、この「列を1本足す」が本番に影響します。シートは1つしかないため、列を追加した瞬間から両方のアプリがその影響を受けるからです。
ノーコードツールは手軽さが魅力ですが、データの構造（スキーマ）を変える作業には、コードを書く開発と同じく手順が要ります。この記事では、私たちが実案件で決めたルールをもとに、AppSheetで列を追加するときの考え方と進め方を整理します。
この記事の結論
- 共有シートへの列追加は、本番と修正版の両方に即座に影響する
- アプリはRegenerate Schemaを実行するまで新しい列を認識しない
- 後方互換の追加に限り、バックアップと実行順を決めてから反映する
Regenerate Schemaとは
AppSheetのアプリは、参照しているスプレッドシートの列構成を、アプリ側の「テーブルの定義」として持っています。Regenerate Schemaは、この定義をスプレッドシートの現在の状態に合わせて読み直す操作です。
ポイントは、スプレッドシートに列を追加しただけでは、アプリ側はその列を認識しないという点です。アプリが新しい列を扱えるようになるのは、Regenerate Schemaを実行してからです。
つまり列の追加には、次の2段階があります。
| 段階 | 起きること | 影響する範囲 |
|---|---|---|
| スプレッドシートに列を追加 | シートの実態が変わる | そのシートを参照する全アプリ |
| Regenerate Schemaを実行 | アプリが新しい列を認識する | 実行したアプリだけ |
この2段階の間には、シートは変わったがアプリの認識はまだ古いという過渡期が必ず生まれます。なお、AppSheetの仕様は変わるため、最新の挙動は公式ドキュメントで確認してください。
列追加で本番が乱れる原因
本番が乱れる原因は、列を追加したことそのものではありません。過渡期に何が起きるかを決めないまま作業することです。
本番アプリと修正中アプリが同じシートを見ている構成を図にすると、次のようになります。
修正中アプリで新しい項目を試したくて、シートに列を追加したとします。この時点で、本番アプリが参照しているシートも同じように変わっています。そのうえで、どちらのアプリからRegenerate Schemaを実行するか、いつ本番に反映するかを決めていないと、アプリごとに認識している列構成がばらばらになります。
結果として、利用者が普段どおり使っている本番アプリが、作業者の想定していない状態になります。作業者は修正中アプリだけを触っているつもりでも、共有しているシートを通じて本番にも手を入れているのと同じなのです。
特に注意したいのは、既存の列の名前や型を変えるケースです。本番アプリは既存の列を前提に動いているため、その前提が崩れると影響はさらに読みにくくなります。
列追加の対策：後方互換の追加に限る
実案件では、まず列追加は後方互換の追加に限るというルールにしました。具体的には次のとおりです。
- 既存列の名前を変えない
- 既存列の型を変えない
- 変更したい項目があっても、既存列を書き換えず新しい列として追加する
既存の列に一切手を触れなければ、本番アプリが前提にしている構造は保たれます。新しい列は、Regenerate Schemaを実行するまで本番アプリからは見えないだけで、既存の動きを壊しにくくなります。
「列名が分かりにくいから直したい」「型を正しくしたい」という気持ちは自然ですが、本番と共有しているシートでは、その変更の影響範囲が大きすぎます。直したい場合も、まずは新しい列を足す形で吸収するのが安全です。
Regenerate Schemaの手順：バックアップと実行順
もう1つのルールが、旧本番のバックアップを保持したうえで、実行順を決めてからRegenerateすることです。流れは次のようになります。
- 旧本番をバックアップする：何かあったときに戻れる状態を先に作ります。戻り先がないまま作業しないことが大前提です。
- 後方互換で列を追加する：既存列の名前と型は変えず、新しい列を足すだけにします。
- 決めた順にRegenerate Schemaを実行する：どのアプリから、どのタイミングで実行するかを作業前に決めておきます。その場の判断で進めないことが重要です。
- 本番の動作を確認する：反映後、本番アプリが普段どおり使えるかを確かめます。
ここで大切なのは、手順の中身そのものより、過渡期をどう過ごすかを事前に決めておくことです。列の追加からRegenerateまでの間は、どうしても不整合が生まれます。その時間を短く、予測できるものにするのが手順の役割です。
実案件（匿名）で学んだ判断軸
実案件（匿名）では、本番アプリと修正中アプリが同じスプレッドシートを参照する構成で運用していました。改修のたびに列を追加する場面があり、そこで上記の2つのルールに落とし込みました。
- 列追加は、既存列の名前と型を変えない後方互換の追加に限る
- 旧本番のバックアップを保持したうえで、実行順を決めてRegenerateする
判断軸はシンプルで、ノーコードでもスキーマ変更には手順が要るということです。AppSheetは画面操作で多くのことができるため、プログラム開発のような変更管理が不要に見えます。しかし、データの構造を変える作業に限っては、ノーコードかどうかに関係なく、影響範囲と順番を考える必要があります。
中小企業では、アプリを作った人と改修する人が同じで、しかも本番運用中というケースがよくあります。だからこそ、口頭の注意ではなく「ルール」として残しておくことで、担当者が変わっても同じ品質で改修できるようになります。
よくある質問
Q. AppSheetでスプレッドシートに列を追加したのに反映されないのはなぜ？ AppSheetのアプリは、参照先のスプレッドシートに列を追加しても自動では認識しません。アプリ側でRegenerate Schemaを実行し、テーブルの列構成を読み直す必要があります。仕様は変わるため、最新の挙動は公式で確認してください。
Q. AppSheetで本番アプリと開発中アプリが同じシートを使っても大丈夫？ 運用は可能ですが、列を追加した瞬間から両方のアプリが影響を受けます。既存列の名前と型を変えない後方互換の追加に限り、旧本番のバックアップを保持したうえで、Regenerateの実行順を決めてから作業するのが安全です。
Q. AppSheetで既存の列名や型を変更してもいいですか？ 本番と共有しているシートでは避けるのが無難です。列名や型の変更は後方互換を崩し、本番アプリの前提を変えてしまいます。必要な項目は新しい列として追加する形で対応し、反映の手順を決めてから作業します。
まとめ
- 本番と修正版が同じシートを参照していると、列追加は両方のアプリに即座に影響する
- アプリはRegenerate Schemaを実行するまで新しい列を認識しないため、必ず過渡期が生まれる
- 列追加は、既存列の名前と型を変えない後方互換の追加に限る
- 旧本番のバックアップを保持し、実行順を決めてからRegenerateする
- ノーコードでも、スキーマ変更には手順が要る
RENOYでは、AppSheetを使った現場アプリの設計・改修から、本番運用を止めない改修ルールづくりまで伴走しています。「運用中のアプリに項目を足したいが、どう進めれば安全か分からない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。