目次
AppSheetは、スプレッドシートの上に業務アプリを載せられるノーコードツールです。現場の点検記録や日報、案件管理などを短期間で形にできるため、中小企業の最初の業務アプリとして選ばれることが多くあります。
ただ、いざ運用が始まると、必ず次の壁が来ます。**「動いているアプリを、止めずに直したい」**という壁です。
AppSheetには、開発環境と本番環境を分ける仕組みが標準で用意されていません。つまり「テスト用で試して、問題なければ本番に反映」というボタンはありません。ここを知らないまま修正を始めると、現場が使っている本番アプリを直接いじることになり、営業時間中にアプリが止まる、という事故が起こります。
この記事では、私たちが実案件（匿名）で確立した「世代交代モデル」と、その際に必ず確認するポイントを整理します。
まず誤解を1つ解く：コピーアプリの変更は本番に反映されない
実案件（匿名）で、運用事故につながりかけた誤解がありました。
「修正中のコピーアプリで設定を直せば、本番アプリにも自動で同期されるはず」——これは間違いです。
AppSheetのCopy Appで作ったアプリは、元のアプリとは別のアプリです。画面設定や自動化のルールを直しても、本番アプリには一切反映されません。逆に、本番側で直した設定もコピー側には来ません。設定は完全に独立しています。
一方で、データソース（スプレッドシート）は共有されていることが多いという点が厄介です。コピー元と同じシートを参照する設定なら、コピーアプリで入力したデータは本番のシートに書き込まれます。
つまり、こうなります。
| コピーアプリで変更 | 本番アプリへの影響 | |
|---|---|---|
| 画面・自動化などの設定 | 独立している | 反映されない |
| データソース（シート）の中身 | 共有されている | 反映される |
| シートの列構成（スキーマ） | 共有されている | 影響が出る |
「設定は届かないのに、データと列構成は届く」。この非対称を理解していないと、「テストしていたつもりが本番データを触っていた」あるいは「直したはずなのに現場のアプリは変わらない」という混乱が生まれます。
なお、AppSheetの仕様は変わるため、最新の挙動は必ず公式ドキュメントで確認してください。
確立した運用：世代交代モデル
ステージング環境がないなら、アプリそのものを世代で入れ替えるという考え方に切り替えます。私たちが標準としている流れは次の3ステップです。
1. 本番アプリは触らない
原則として、現場が使っているアプリには手を入れません。小さな修正でも同じです。「1箇所だけだから」で直接触った結果、業務時間中に画面が崩れる——これが最も多い事故パターンです。
2. Copy Appで作った「修正中アプリ」で改修する
Copy Appで複製し、そこで設計を変えます。名前は「〇〇（修正中）」のように、誰が見ても本番でないと分かる形にしておきます。テスト時にデータを汚したくない場合は、データソースをテスト用のシートに切り替えて検証します。
3. 完成したらリネームで昇格、旧本番はバックアップ
検証が終わったら、修正中アプリの名前を本番の名前に変更して昇格させます。旧本番アプリは削除せずバックアップとして残します。問題が出たときに、旧世代へ戻せる状態を保っておくのが要点です。
この「昇格」のタイミングで、現場が使う入口（アプリのリンクやショートカット）を新しいアプリに切り替える必要があります。切り替えの連絡と作業は、業務が止まっている時間帯にまとめて行います。
つまずきやすい2つの落とし穴
世代交代モデルを回すうえで、実際に踏んだ注意点が2つあります。どちらもデータソースが共有されていることに起因します。
落とし穴1：カラム追加で、本番側にRequired列エラーが出る
修正中アプリで新しい項目を追加するとき、当然スプレッドシートに列を足します。ところがそのシートは本番アプリも参照しています。
このとき、追加した列を**入力必須（Required）**にしていると、過渡期に本番アプリ側で「必須項目が埋まっていない」というエラーが起き、現場の入力が止まる可能性があります。本番アプリの画面にはその入力欄がないため、現場は埋めようがありません。
対策はシンプルで、列を足すタイミングと順序を先に決めておくことです。
- 検証中は必須にせず、任意項目として追加しておく
- 必須に切り替えるのは、新世代を本番へ昇格させた後にする
- 列の追加自体も、できるだけ業務時間外に行う
「後で必須にする」を段取りに組み込むだけで、この事故はほぼ防げます。
落とし穴2：スキーマ変更後は、各アプリでRegenerate Schemaが必要
もう1つは、同じスプレッドシートを複数のアプリが参照している構成のときです。
シートの列構成（スキーマ）を変えても、各アプリは自動で追従しません。アプリごとにRegenerate Schemaを実行して、列の変更を読み込ませる必要があります。これを忘れると、「新しい列が選べない」「保存されない」といった原因の分かりにくい不具合になります。
したがって、列を追加・変更したらそのシートを参照している全アプリを洗い出して、順番にRegenerate Schemaを実行する——これを手順書に書いておきます。アプリが2つ3つに増えた段階で、この一覧がないと必ず抜けます。
中小企業向けの現実的な進め方
ここまでを、実際の段取りに落とすと次のようになります。
| 段階 | やること | 目的 |
|---|---|---|
| 準備 | 参照シートと関連アプリを一覧化 | 変更の影響範囲を把握 |
| 改修 | Copy Appで修正中アプリを作る | 本番を守る |
| 検証 | テスト用シートで動作確認 | 本番データを汚さない |
| 列追加 | 業務時間外に、まず任意項目で追加 | 必須エラーを回避 |
| 昇格 | リネームで世代交代、入口を切替 | 現場の切り替えを一度で済ませる |
| 後処理 | 各アプリでRegenerate Schema／旧本番を保持 | 不具合防止と切り戻し確保 |
ポイントは、手順を人の記憶に置かないことです。担当者が1人しかいない会社ほど、その人が休んだ日に改修が必要になったときに詰まります。上の表を1枚の手順書にしておくだけで、引き継ぎができる状態になります。
教訓：ノーコードでも「本番をどう守るか」は自分で設計する
ノーコードツールは、開発の手間を大きく下げてくれます。しかし下げてくれるのは作る手間であって、運用の設計は肩代わりしてくれません。
- 誰が本番を変更してよいのか
- 変更はどのタイミングで反映するのか
- 問題が出たとき、どこに戻すのか
この3つは、ツールが与えてくれるものではなく、会社側で決めるものです。AppSheetにステージング環境がないという事実は、逆に言えば「本番の守り方は使う側の責任」ということを示しています。
そして、これはAppSheetに限った話ではありません。ノーコードで小さく作れるからこそ、アプリの数は増えていきます。増えたときに崩れないよう、最初の1本目から世代交代の型を決めておくのが、あとから効いてきます。
まとめ
- AppSheetには開発環境と本番環境を分ける機能が標準でない（仕様は変わるため最新は公式で確認）
Copy Appで作ったアプリの設定は本番に同期されないが、データソースと列構成は共有される- 安全な進め方は世代交代モデル：本番は触らない → 修正中アプリで直す → リネームで昇格 → 旧本番はバックアップ保持
- 落とし穴は2つ。列追加時のRequiredエラー（順序とタイミングを決める）と、複数アプリでのRegenerate Schema漏れ
- ノーコードでも「本番をどう守るか」の運用設計は必要で、それはツールが与えてくれない
RENOYでは、AppSheetを含む業務アプリの設計・開発から、社内で安全に更新を回せる運用ルールづくりまで伴走しています。「作ったアプリが直せなくなってきた」「担当者1人に依存していて不安」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。