公開前の商品をマスタに登録するときは表示側を先に用意する｜有効フラグだけでは画面に出てしまう経路と、伏せたまま準備する順番

スプレッドシートで商品マスタやメニュー表を持ち、その内容を発注フォームや予約画面、ホームページの料金表に自動で反映させている店舗は増えています。シートに1行足せば画面に出る。便利な作りですが、裏を返すと「まだ出したくないもの」を足した瞬間にも画面に出る、ということです。来月から扱う商品、一部の店舗だけで扱う商品、価格が確定していないメニュー。こうしたものを準備のつもりで先に登録して、意図しない相手に見せてしまう事故は、仕組みを知っていれば防げます。

先に結論を書きます。公開前の商品や限定商品を登録するときは、「①列を足す（値は空のまま）→②表示側のプログラムを更新する→③値を入れる」の順番を守ります。どうしても先に行を入れておきたい場合は、有効フラグをOFFにした状態で入れます。「対象店舗」「公開開始日」のような制約を表す列は、その列を読めるプログラムが本番に載るまでは、書いてあっても存在しないのと同じだからです。

弊社は名古屋でホームページ制作と店舗向けの業務自動化を行っています。この記事では、名古屋の美容サロンFC（25店舗）の発注フォームに、12店舗だけで扱う商品を追加したときの実例をもとに、画面に出てしまう経路と、伏せたまま準備する順番を整理します。

【この記事でわかること】

• 商品マスタに書いた「限定」や「公開前」の指定が効かないのはどんなときか
• 正しい作業順と、先に行を入れたいときの伏せ方
• 画面に出てしまう4つの経路（列の未対応・キャッシュ・送信側の素通し・既存の自動判定への混入）
• 公開前に確かめる項目と、出てしまったときの止め方

結論：順番は「列を足す→表示側を更新→値を入れる」

データを書き換えるだけで画面が変わる作りを、ここでは「データ駆動」と呼びます。商品マスタのシートに行を足せば、フォームに商品が増える。プログラムを触らなくてよいので、運用担当者が自分で更新できるのが利点です。

この作りで新しい条件を足すとき、作業は3つに分かれます。

手順	やること	この時点の画面
① 列を足す	商品マスタに「対象店舗」などの列を追加する。値は全行とも空のまま	変化なし（空欄＝従来どおり全店に表示）
② 表示側を更新する	新しい列を読めるプログラムを本番に反映する	変化なし（全行が空欄なので、結果は従来と同じ）
③ 値を入れる	新商品の行を追加し、対象店舗を書き込む	指定した店舗にだけ商品が出る

ポイントは、①と②が終わった時点では画面に何も変化が起きないことです。「空欄なら従来どおり」という後方互換の仕様にしておけば、列の追加もプログラムの更新も、営業時間中に安全に行えます。変化が起きるのは③だけで、その③は②の後にしか行いません。

逆の順番、つまり③を②より先にやると何が起こるか。次の章で説明します。

なぜ有効フラグと限定の列だけでは伏せられないのか

商品マスタには、たいてい「有効フラグ」の列があります。TRUEなら表示、FALSEなら非表示。ここに「対象店舗」列を足して、特定の店舗コードだけを書いたとします。担当者の頭の中では「有効だが、対象店舗にしか出ない商品」です。

ところが、本番で動いているプログラムがまだ古い版だと、「対象店舗」という列そのものを読みません。古いプログラムから見たその行は、「有効フラグがTRUEの、普通の商品」でしかありません。結果として全店舗の画面に出ます。

ここで押さえておきたいのは、制約を表す列ほど危険な方向に外れる、という性質です。

列の種類	例	古いプログラムでの扱い
表示に使うだけの列	商品説明、備考	読まれないので出ないだけ。害はない
制約を表す列	対象店舗、除外店舗、公開開始日、購入上限	読まれない＝制約なしとして扱われる

説明文の列が読まれなくても、説明が出ないだけで済みます。しかし「この店だけ」「この日から」「ここまで」という制約の列が読まれないと、制約のない状態、つまり最も広く出る状態に倒れます。限定のつもりで書いた行が、書いた瞬間から全員に見える。データ駆動の「シートに書けばすぐ動く」という利点が、そのまま裏目に出る形です。

実例：25店舗の発注フォームに12店限定の商品を足す

実際の構成で説明します。名古屋の美容サロンFCでは、各店舗が消耗品を本部へ発注するフォームを運用しています。構成は次のとおりです。

• 商品マスタ：スプレッドシート。品番・商品名・単位・価格・仕入先・有効フラグなどを持つ（既存38品）
• 表示と受付：Google Apps Script（GAS）がマスタを読み、店舗別の発注画面を返す。送信された発注を記録し、仕入先別にメールを出す
• 入口：店舗ごとの固定URL（自社ドメイン経由）。全25店舗

ここに「12店舗だけで扱う新商品」を足すことになりました。設計は、商品マスタに「対象店舗」列を1本足すだけのシンプルなものです。

セルの値	動き
空欄	全店に表示（既存38品はこのまま＝完全に後方互換）
店舗コードをカンマ区切りで列挙	書いた店舗にだけ表示
先頭にマイナスを付けた店舗コード	その店舗にだけ非表示

プログラムに店舗名を書き込まず、シートの値だけで出し分ける。店舗が増えても商品が増えても、プログラムの修正は要りません。

この構成で気をつけるのが、先ほどの順番です。新しい版のGASを本番に反映する前にマスタへ行を足すと、その時点の本番は「対象店舗」列を読まない旧版なので、12店限定のはずの商品が25店すべての発注画面に出ます。実際、この順番で作業すると、対象外の店舗のURLを開いて確認した時点で、限定商品が通常商品と同じ扱いで表示される状態になります。対処は単純で、その行の有効フラグをFALSEにして伏せ、表示側の更新が済んでからTRUEに戻すだけです。ただし後述のとおり、伏せてもすぐには消えません。

最終的には、表示側の更新→有効フラグをTRUEの順で公開し、全25店舗のURLを1つずつ開いて「12店で表示・13店で非表示」を実測で確認しています。

画面に出てしまう経路は4つある

「有効フラグをOFFにしておけば安心」と考えがちですが、公開前の商品が外に出る経路は1つではありません。設計と確認の段階で、次の4つを順に潰します。

経路1：表示側が新しい列を読めない

前章のとおりです。制約の列を足したら、その列を読むプログラムが本番に載っているかを先に確認します。GASの場合、エディタ上のコードを保存しただけでは本番は変わりません。「デプロイを管理」から既存のデプロイを新しいバージョンに更新して、はじめて本番に反映されます。このとき「新しいデプロイ」を選ぶとURLが変わり、店舗に配ったリンクが使えなくなるので注意が必要です（詳しくはGASで「新しいデプロイ」を押してしまったときの正しい戻し方にまとめています）。

経路2：キャッシュが残っている

表示を速くするために、マスタの内容を数分間キャッシュしている構成は珍しくありません。今回の発注フォームは5分です。この場合、有効フラグをFALSEにしても、最大5分間は古い内容が出続けます。「止めた」と「消えた」は同じではありません。

逆方向でも同じことが起きます。公開のためにフラグをTRUEへ戻した直後に画面を見ると、まだ商品が出ていない店舗があります。実際に、25店舗を順に確認している途中で1店舗だけ古い画面を返し、数分後に正しく表示された例がありました。公開直後の「うちの店に出ていない」という問い合わせは、多くの場合この待ち時間です。反映までの時間は、あらかじめ関係者に伝えておきます。

経路3：画面で隠しただけで、送信側が素通し

出し分けを「画面に出さない」だけで実装すると、もう一つ穴が残ります。フォームの送信先に、対象外の店舗から直接データを送れば、注文が通ってしまう作りです。通常の操作では起きませんが、古い画面を開いたままの端末や、ブラウザに残った入力内容から送信されることはありえます。

今回の実装では、表示の絞り込みと同じ判定を、注文を受け付ける側にも入れています。対象外の店舗からその商品を含む注文が届いたら、「取り扱いのない商品」として弾く。これは自動テストにも含めており、「対象店舗からは通る／対象外の店舗からは弾かれる」の両方を確認しています。

経路4：既存の自動判定に混ざる

見落としやすいのがこれです。新しい商品は、画面に出るだけでなく、既存の計算や通知にも流れ込みます。

今回の例では、発注フォームに「仕入先ごとの配送グループ」があり、あるグループは税抜3万円以上で送料無料、という判定を画面に出していました。旧版の判定は「仕入先がA社ならグループ1、それ以外は全部グループ2」の二択です。ここに第三の仕入先の商品を足すと、自動的にグループ2に入り、別の仕入先の商品なのに、送料無料の判定金額に合算されてしまいます。店舗は「3万円を超えたから送料無料」と判断して発注し、実際には送料がかかる、という食い違いが起こりえます。

そこで、配送グループを「A社／B社／それ以外」の3つに分け、「それ以外」は送料判定に含めない形に直しました。既存の仕入先へ渡す発注データ（CSV）に新商品が混ざらないことも、あわせて確認しています。新商品を足すときは、表示だけでなく「この商品が流れ込む先」を一覧にするのが安全です。送料、合計金額、集計表、通知メールの宛先、外部へ渡すデータ。どれも「それ以外はこちら」という二択の分岐が潜みやすい場所です。

伏せたまま準備する手順

以上を踏まえた、実務での手順です。

1. 流れ込む先を洗い出す：新商品が影響する計算・通知・出力を一覧にする（送料判定、仕入先別メール、集計など）
2. 列を足す：制約の列を追加する。全行とも空欄のまま。空欄＝従来どおり、の仕様にしておく
3. 表示側と受付側を更新する：新しい列を読む版を本番に反映する。この時点で既存商品の表示が変わっていないことを、数店舗のURLで確認する
4. 行を伏せて入れる：新商品の行を、有効フラグFALSEで登録する。品番・価格・対象店舗を入れ、対象店舗のコードがマスタに実在するかを突き合わせる
5. 公開する：有効フラグをTRUEにする。キャッシュの時間だけ待つ
6. 実測する：対象の店舗で出ていること、対象外の店舗で出ていないことを、実際のURLで確認する。1店舗だけ見て済ませず、対象と対象外の両方を見る

手順3より前に行を入れる必要があるなら、必ず手順4の「伏せた状態」で入れます。有効フラグが無いマスタなら、先にフラグ列を作るところから始めます。

確認を「画面を見た印象」で終わらせないことも大切です。設定が保存されたつもりで反映されていない、という事態は別の場面でも起こります（管理画面の設定変更が保存されていないことがある）。店舗数と商品数のように、数で答え合わせできる確認方法を用意しておくと確実です。今回は、対象店舗の画面には新商品の品番の行があり、対象外店舗の画面には無いことを、25店舗すべてで確かめています。

出てしまったときの止め方

順番を間違えて公開前の商品が出てしまった場合は、次の順で対処します。

1. 有効フラグをFALSEにする：最も早く確実な止め方です。行を削除するより、フラグで伏せるほうが後で戻しやすく、入力内容も残ります
2. キャッシュが切れるまで待つ：待ち時間を把握しておく。すぐ消えなくても慌てて別の変更を重ねない
3. 実害を実測する：「たぶん誰も見ていない」で済ませず、対象外の店舗のURLを開いて表示の有無を確かめ、その間に注文が入っていないかを発注ログで確認する
4. 表示側を更新してから戻す：正しい順番に戻し、フラグをTRUEにする

止める手段が「有効フラグ1つ」で済むのは、データ駆動の利点でもあります。プログラムを巻き戻す必要がなく、シートの1セルで止まります。だからこそ、有効フラグの列は最初から用意しておく価値があります。

よくある質問

Q. シートをコピーしたテスト環境で確認してから本番に入れれば防げますか？

テスト環境は有効ですが、それだけでは防げません。テスト環境で動いた新しいプログラムが、本番にはまだ反映されていない、という状態が今回の経路1です。本番のプログラムの版を確認してからマスタに書く、という順番の問題は、テストの有無とは別に残ります。

Q. ホームページの料金表や予約メニューでも同じことが起きますか？

起きます。スプレッドシートやCMSの項目をもとに料金表を自動表示している場合、「公開開始日」「対象店舗」のような項目を足しても、表示側がその項目を見ていなければ無視されます。新メニューを先に登録して準備したいときは、下書き状態や非公開フラグが表示側で実際に効いているかを、先に確かめてください。メニューを売り始める前の段取りは新メニューを増やすと現場が止まるでも扱っています。

Q. 店舗ごとに別のフォームを作れば安全ではないですか？

店舗数が少ないうちは成り立ちますが、25店舗分のフォームを別々に持つと、価格を1つ変えるだけで25回の修正が必要になり、修正漏れという別の事故を生みます。マスタを1つにして列で出し分け、順番を守る運用のほうが、長く続けやすい構成です。

まとめ

• データ駆動の仕組みでは、シートに書いた瞬間に画面へ反映される。公開前・限定の商品ほど、書く順番が重要になる
• 「対象店舗」「公開開始日」のような制約の列は、読めるプログラムが本番に載るまで「制約なし」として扱われる
• 順番は「列を足す（空のまま）→表示側を更新→値を入れる」。先に行を入れるなら有効フラグOFFで伏せる
• 出てしまう経路は4つ。列の未対応、キャッシュ、送信側の素通し、既存の自動判定への混入
• 公開後は、対象と対象外の両方の店舗で実測する。キャッシュの待ち時間は先に伝えておく

弊社では、スプレッドシートとGASを使った発注フォームや集計の仕組みづくり、既存の仕組みの見直しを承っています。「シートを直したら意図しないところまで変わってしまった」「店舗ごとの出し分けをしたいが、今の作りでできるか分からない」といった段階からご相談いただけます。