【AppSheet】開発でハマる罠と解決策

ノーコードツールAppSheetは、驚くほどの速さで高機能な業務アプリを構築できる非常に強力なプラットフォームです。しかし、その手軽さゆえに、少し凝った機能や、ユーザーごとに異なる挙動を実装しようとすると、予期せぬ「壁」に突き当たることがあります。
この記事では、実際の開発現場で特に頻発する「あるある」な2つの問題を取り上げ、その根本原因と解決策を、AppSheetの基本的な概念や用語を詳しく解説しながら、具体的な実装パターンとしてご紹介します。
Contents
Toggleパターン1:ユーザー権限によって表示が変わる?「ユーザー別設定」の実装
問題の現象:「あのユーザーだけフィルターが表示されない!」
アプリ開発でよく遭遇するのが、「管理者アカウントでは絞り込み用のメニューが表示されるのに、新しく追加した一般ユーザーのアカウントで見ると、その部分だけが空っぽで何も表示されない」という現象です。これは、ユーザーの権限や役割に応じて、アプリの見た目や機能をパーソナライズしたい場合に必ずと言っていいほど直面する課題です。
原因の深掘り:「ユーザー設定テーブル」という考え方
この問題の根本原因は、「フィルター条件などを保存しておくためのテーブルに、そのユーザー専用の行が存在しない」ことにあります。
AppSheetは、各ユーザーが「今、どんな絞り込み条件を選んでいるか」といった一人ひとり異なる状態を、どこかに記録しておく必要があります。その「記録場所」として、物件情報などのマスターデータとは別に、「ユーザー設定テーブル」という専用のテーブルを用意するのが一般的な設計手法です。
この仕組みは、主に以下の3つの要素で成り立っています。
- 「ユーザー設定テーブル」を用意する これは、ユーザーごとの設定を保存するための、いわば「個人用のメモ帳」です。最低でも、「誰のメモか」を識別するための列(通常、ユーザーのメールアドレスを保存)と、「どんな設定か」を保存する列(例:「選択中のエリア」列)で構成されます。
- スライス (Slice) で自分の行だけを抽出する 次に、この「ユーザー設定テーブル」の中から、現在ログインしているユーザーの行だけをリアルタイムで抜き出す必要があります。ここで活躍するのがスライス機能です。
- 用語解説:スライス (Slice) スライスとは、元のテーブルにフィルターをかけた「仮想的なテーブル」です。データそのものをコピーするわけではなく、条件に合う行だけを切り取って見せる窓のような役割を果たします。
Row filter condition
(行の絞り込み条件)に、[Email] = USEREMAIL()
という式を設定します。- 用語解説:USEREMAIL() USEREMAIL()は、AppSheetが提供する特別な関数で、現在アプリにログインしているユーザーのメールアドレスを自動で返してくれます。この関数のおかげで、「今見ている人」を特定できます。
- ビュー (View) で表示する 最後に、アプリ上のフィルター設定画面(ビュー)は、このスライスをデータソースとして作成します。
以上の仕組みを理解すると、原因は明確です。新しく追加されたユーザーは、まだこの「ユーザー設定テーブル」に自分専用の行(メモ)が一行も存在しません。そのため、スライスが抜き出すデータは0件となり、結果としてビューには何も表示されない、というわけです。
解決策:ユーザー行を自動で作成・同期する
この問題を解決するには、ユーザーが初めてアプリを使う際に、そのユーザー専用の行を「ユーザー設定テーブル」に自動で作成してあげる仕組みが必要です。
【全プラン対応】GASの時間ベーストリガーで定期同期
AppSheetの無料プランでも利用できる、最も確実で安定した方法です。
- 用語解説:Google Apps Script (GAS) GASは、Googleが提供するプログラミング言語(中身はJavaScript)で、スプレッドシートやGmailといったGoogleのサービスを自動化・連携させることができます。
このGASを使い、「ユーザー情報が格納されたマスターテーブル」と「ユーザー設定テーブル」の内容を定期的に見比べて、差分を自動で同期するスクリプトを組みます。
- ポイント① – メイン関数を一つ作る: 「新規ユーザーの追加」と「マスターから削除されたユーザーのクリーンアップ」の両方を行う関数を用意すると、管理がシンプルになります。
- ポイント② – 時間ベースのトリガー: GASには、特定の時間や間隔で関数を自動実行する「トリガー」機能があります。これを「10分おき」や「1時間おき」に設定すれば、ユーザーの増減が定期的に設定テーブルへ反映されます。
- ポイント③ – 重複登録の防止: スクリプト内では、行を追加する前に「既に追加済みでないか?」を必ずチェックするロジックを入れ、不要な処理を防ぎます。
【有料プラン向け】AutomationとWebhookでリアルタイム同期
有料プランをご利用の場合、よりリアルタイムな同期が可能です。
- 用語解説:AppSheet Automation と Webhook Automationは、AppSheet内で「データが追加されたら」といったイベントをトリガーに、一連の処理(メール送信、データ更新など)を自動実行する機能です。 Webhookは、その処理の一つで、外部のWebサービスに対して「今、こんなことが起きたよ!」とリアルタイムで通知を送る仕組みです。
これらを使い、「ユーザーテーブルに行が追加されたら、Webhookを使ってGASのプログラムを呼び出す」という設定をすれば、ユーザー追加の瞬間にリアルタイムで設定行を作成できます。
パターン2:フォームを賢く動かす!条件に応じた入力制御の鉄則
問題の現象:「自動入力」と「手動入力」を両立させたい
「フォームで『物件種別』が『土地』の時は、『建物種別』に自動で『土地のみ』と入力したい。でも、『土地・建物』を選んだ時は、ユーザーが自由に『建物種別』を選択できるようにしたい」
このような、条件に応じた柔軟な入力フォームの作成は、アプリの使いやすさを劇的に向上させる一方で、多くの開発者がつまずくポイントでもあります。
原因の深掘り:「App Formula」の強力すぎる特性
この問題のよくある間違いが、「条件によって値が変わるならIF()
関数だ!」と考え、App Formula
に式を設定してしまうことです。これは自然な発想ですが、App Formula
の「特性」を誤解していると、意図しない挙動を引き起こします。
- 用語解説:App Formula この欄に設定された数式は、その列の値を常に計算し続けます。スプレッドシートの数式のように、一度計算された後に手で値を上書きすることはできません。App Formulaが設定された列は、事実上の「読み取り専用」となり、ユーザーによる手動入力は一切受け付けなくなります。
「物件種別」が「土地・建物」の場合、App Formula
内のIF()
式が返す値がないと、その列は「空っぽ」かつ「編集不可」になります。AppSheetは「表示しても意味がない」と判断し、フォーム上からそのフィールド自体を非表示にしてしまうのです。
解決策:「Initial Value」と「Editable?」の黄金コンビ
「条件によって自動入力しつつ、別の条件では手動入力させたい」という要望を叶えるための正解は、App Formula
を使わず、以下の3つの設定を組み合わせることにあります。
鉄則①:Initial Value
で「初期値」を決める
- 用語解説:Initial Value その名の通り、これは列の「初期値」を設定する機能です。新しい行が作成された時や、他の列の値が変更された時に、一度だけ値をセットします。重要なのは、App Formulaとは異なり、ここで設定された値は後からユーザーが手動で上書き可能であるという点です。
- 設定例(「建物種別」列の
Initial Value
に設定):IF( [物件種別] = "土地", ANY(SELECT(建物種別[Category], [Category] = "土地のみ")), "" )
この式は、「もし[物件種別]が”土地”なら、『土地のみ』という値のキーを初期値としてセットし、そうでなければ空にする」という意味です。
- 設定例(「建物種別」列の
鉄則②:Reset on edit?
スイッチを絶対にONにする
Initial Value
とセットで使う、非常に重要なスイッチです。このスイッチをONにすると、このフォーム内のいずれかの値が編集されるたびに、Initial Value
の式が再評価されるようになります。これにより、「物件種別」を「土地」から「土地・建物」に変更した瞬間に、「建物種別」の初期値がリセットされ、動的なフォームが実現します。
鉄則③:Editable?
で「編集できるか」をコントロールする
- 用語解説:Editable? この設定項目には、結果がYesかNo(TrueかFalse)になる数式を入力します。Yesを返した時だけ、そのフィールドは編集可能になります。
- 設定例(「建物種別」列の
Editable?
に設定):[物件種別] = "土地・建物"
このシンプルな式だけで、「[物件種別]が”土地・建物”の時だけ、このフィールドの編集を許可する」という完璧な制御が実現できます。
- 設定例(「建物種別」列の
おわりに
AppSheetで一歩進んだアプリを作るには、各設定項目の「特性」を正しく理解し、それらを適切に組み合わせることが不可欠です。
- ユーザー別データ: 「ユーザー設定テーブル」という概念を理解し、「自動同期の仕組み」とセットで考える。
- 動的フォーム:
App Formula
(常に計算・編集不可)とInitial Value
(初期値のみ・編集可)の役割の違いを明確に使い分ける。
今回ご紹介したパターンは、多くの応用が効く非常に重要な考え方です。これらの知識が、あなたのアプリ開発の助けになれば幸いです。

北海道紋別市出身。旭川・富良野を経て2025年5月に故郷へ。金融・デザイン・Web・不動産の多様な経験を活かし、個人事業でホームページ制作やAI活用支援を提供。宅建士資格保有。地方でのデジタル活用と地域貢献をテーマに活動中。