AppSheetの権限設計入門：ユーザーごとに見せるデータ・できる操作を分ける4つの方法

結論：AppSheetの権限設計は「見せるデータ」「できる操作」「見せる画面」の3つに分けて考えると迷いません。行単位でデータを絞るのはセキュリティフィルタ、追加・編集・削除の可否はテーブルの「Are updates allowed?」、列ごとの編集可否はEditable_If、画面やボタンの出し分けはビューの「Show if」とアクションの「Only if this condition is true」で行います。すべての土台になるのは「ユーザーのサインインを必須にし、USEREMAIL()で誰が使っているかを判定する」ことです。なお、画面やボタンを隠すだけでは公式ヘルプ上も「セキュリティ対策ではない」とされているため、見せてはいけないデータは必ずセキュリティフィルタ（AppSheet Core以上）で絞り込んでください。

「権限を分けたい」は3種類に分解できる

AppSheetで業務アプリを作って部署や取引先に配り始めると、ほぼ確実に次のような要望が出てきます。

• 「営業担当には自分の顧客だけを見せたい。ほかの担当の顧客リストは見せたくない」

• 「現場スタッフは日報を入力するだけでよく、過去の記録を削除できないようにしたい」

• 「承認ボタンは上長にだけ表示したい」

これらはひとまとめに「権限」と呼ばれがちですが、AppSheetの設定上は次の3つに分解して考えると、どこを触ればよいかがはっきりします。

• 見せるデータを分ける：どの行（レコード）をそのユーザーの端末に送るか

• できる操作を分ける：追加・編集・削除のどれを許可するか。特定の列だけ編集不可にするか

• 見せる画面・ボタンを分ける：どのビュー（画面）やアクション（ボタン）をメニューに出すか

本記事では、この3つそれぞれに対応するAppSheetの機能を、公式ヘルプの記述を引用しながら順番に解説します。

前提：ユーザーのサインインを必須にし、誰が使っているかを判定できるようにする

ユーザーごとに出し分けるには、まず「今アプリを使っているのが誰か」をAppSheetが把握できる必要があります。公式ヘルプ「Require sign-in: The Essentials」によると、エディタのSecurity > Require sign-inでRequire user signinを有効にし、Google・Microsoftなどの認証プロバイダを選びます。サインインを要求しないアプリは、公式ヘルプ上でも「本質的に安全ではない（inherently insecure）」とされています。

サインインしたユーザーのメールアドレスは、USEREMAIL()関数で取得できます。公式の説明では「現在サインインしているユーザーのメールアドレスを返し、サインインしていない場合は空になる」関数です。以降で紹介する式のほとんどは、このUSEREMAIL()を起点にしています。

アプリを使えるユーザーの範囲は、エディタ上部の共有（Share）アイコンから設定します（Share: The Essentials）。ユーザー個別に「Use app（使うだけ）」「View/copy app」「Edit app」を指定できるほか、自社ドメイン全体に共有する設定もあります。注意点として、公式ヘルプには「gmail.comのような広く使われているドメイン名へのアプリ共有はセキュリティ上の理由で防止される」と明記されています。個人のGmailアカウントで使うメンバーがいる場合は、ドメイン単位ではなく個別にメールアドレスを追加する運用になります。

「役割」をどう判定するか：USERROLE()とユーザーマスタの2通り

「管理者」「一般ユーザー」のような役割で分岐させる方法は2つあります。

• USERROLE()を使う：USERROLE()は、サインインしているユーザーに割り当てられた役割を返す関数で、公式ヘルプいわく「有効な役割はAdminまたはUserのみで、役割を追加・削除することはできない」というシンプルな仕組みです。役割は共有ダイアログでユーザーごとに「Advanced」を開き、in-app roleをUser（既定）またはAdminに切り替えて設定します。管理者かそれ以外か、の2段階で足りる小規模なアプリなら、この方法が最も手軽です。

• ユーザーマスタ（自作テーブル）で管理する：「営業」「経理」「拠点責任者」のように役割を3つ以上に分けたい場合は、メールアドレスと役割を並べた「ユーザー」シートを1枚作り、LOOKUP(USEREMAIL(), ユーザー, メール, 役割)のように参照する方法が現実的です。公式ヘルプ「Limit users to their own data using security filters」でも、IN(LOOKUP(USEREMAIL(), Employees, Email, Department), LIST("Payroll", "Personnel"))のように従業員テーブルから部署を引いて判定する例や、IN(USEREMAIL(), Managers[Email])のように管理者一覧に含まれるかで判定する例が紹介されています。役割の追加・変更をスプレッドシートの編集だけで完結できるのが利点です。

なお、Googleグループなどのドメイングループを独自の役割名としてUSERROLE()で返す機能もありますが、こちらは公式ヘルプで「AppSheet Enterprise Plusアカウントのみ」と明記されています。

方法1：見せるデータを分ける——セキュリティフィルタ

「自分の担当分だけを見せる」を実現する本命の機能がセキュリティフィルタです。公式ヘルプ「Security filters: The Essentials」によると、セキュリティフィルタは「テーブルの各行に対して評価される任意のYes/No式」で、式がTRUEになる行だけがユーザーに渡されます。設定場所はエディタのSecurity > Security filters（またはテーブル設定内のSecurity filter欄）です。

もっとも基本的な形は、レコードに「担当者のメールアドレス」列を持たせておき、それとUSEREMAIL()を突き合わせる式です。

[担当者メール] = USEREMAIL()

「管理者は全件、それ以外は自分の分だけ」なら、USERROLE()と組み合わせて次のように書けます。これは公式ヘルプに載っている例そのままです。

OR((USEREMAIL() = [Email]), (USERROLE() = "Admin"))

取引先ごとに担当営業が複数いる、といった多対多の関係なら、対応表テーブルから該当する顧客IDを引く形になります（公式の例を日本語の列名に置き換えたものです）。

IN([顧客ID], SELECT(担当割当[顧客ID], [営業メール] = USEREMAIL()))

スライスで絞るのとは何が違うのか

「一覧画面にスライス（Slice）で条件を付ければ同じでは？」と思われがちですが、公式ヘルプ「Scale using security filters」は両者の違いをはっきり書いています。要約すると、スライスは全データを端末にダウンロードしてから絞り込むのに対し、セキュリティフィルタは条件を満たすレコードだけを取得し、端末に送る内容そのものを制限するという違いです。つまりスライスで隠しても、他人のデータは端末の中に届いてしまっています。見せてはいけないデータを扱うなら、スライスではなくセキュリティフィルタを使わなければなりません。

副次的な効果として、端末に送るデータ量が減るぶん同期が速くなり、データが増えたときのメモリ不足エラーも起きにくくなります。スプレッドシートがデータソースの場合は「シート全体をいったん取得してからフィルタを適用する」ため取得自体は速くなりませんが、端末への送信と端末内での保存が軽くなる、と公式ヘルプは説明しています。

注意点：プランと「万能ではない」こと

• 利用できるプラン：公式ヘルプには「この機能はAppSheet Coreアカウント以上で利用できる」とあり、プラン比較表（How to choose a subscription）でもStarterは非対応、Core／Enterprise Plusは対応となっています。権限設計が必要な業務アプリを本番運用するなら、Core以上を前提に考えるのが安全です。

• 完全なセキュリティ対策ではない：公式ヘルプ自身が「セキュリティフィルタはデータアクセスを制限するが、完全なセキュリティソリューションではない。機密性の高いデータ操作はデータソース側で保護すべき」と注意しています。裏側のスプレッドシート自体の共有範囲（誰がシートを直接開けるか）も合わせて見直してください。

方法2：できる操作を分ける——テーブルの「Are updates allowed?」

「見ることはできるが、追加や削除はさせない」といった操作の制限は、テーブル設定のAre updates allowed?で行います。公式ヘルプ「Control add, update, and delete operations」によると、この設定は「Updates」「Adds」「Deletes」「Read-only」の組み合わせを固定で選ぶだけでなく、フラスコのアイコンをクリックして式で動的に決めることができます。式が返す値として認められているのは、公式ヘルプに列挙されている次の8種類です。

ALL_CHANGES
ADDS_ONLY
ADDS_AND_UPDATES
ADDS_AND_DELETES
UPDATES_ONLY
UPDATES_AND_DELETES
DELETES_ONLY
READ_ONLY

たとえば「管理者はすべて可、それ以外は編集のみ（削除・追加は不可）」なら、公式ヘルプの例のとおり次のように書きます。

IF((USERROLE() = "Admin"), "ALL_CHANGES", "UPDATES_ONLY")

ユーザーマスタで役割を管理している場合は、SWITCH()で役割ごとに振り分けるのが読みやすい書き方です。

SWITCH(LOOKUP(USEREMAIL(), ユーザー, メール, 役割),
  "管理者", "ALL_CHANGES",
  "現場", "ADDS_ONLY",
  "READ_ONLY")

この例では、現場スタッフは日報を「追加」することだけができ、過去の記録の書き換えや削除はできません。役割が登録されていないユーザーは閲覧のみになります。

もうひとつ覚えておきたいのが、スライスにも個別に更新権限を設定できるものの、公式ヘルプいわく「元のテーブルの権限と同等かそれより厳しいものでなければならない」という点です。テーブルは読み取り専用にしておいて、スライスだけ編集可能にする、という抜け道は作れません。

方法3：列単位で分ける——Editable_IfとShow_If

「担当者は日報の本文は直せるが、承認欄は上長しか触れない」のように、行ではなく特定の列だけを制御したい場合は、列の設定を使います。

• Editable_If（編集可否）：公式ヘルプ「Editable_If」によると、Data > Columnsで対象の列を開き、Update BehaviorのEditable?横のフラスコアイコンから式を設定します。公式の例には("Admin" = USERROLE())、IN(USEREMAIL(), LIST("[email protected]", "[email protected]"))、(USEREMAIL() = [Email])が挙げられており、そのまま流用できます。

• Show_If（表示可否）：「Show_If」は、列の値を条件に応じて表示・非表示にする設定です。既定ではフォーム画面にのみ効きますが、「Apply show-if constraints universally」を有効にするとアプリ全体で適用されます。

ここで必ず押さえておきたいのが、公式ヘルプのShow_Ifページにある次の一文です。「列の制約はUIの機能であり、セキュリティ制御ではない。ユーザーがデータにアクセスすることを防ぐものではない」。つまりShow_Ifで列を隠しても、その値は端末に届いています。給与や原価のように見られてはいけない値であれば、そもそもその列を含むテーブルを分け、セキュリティフィルタで行ごと制限する設計にしてください。

また、Editable_Ifは「アプリ内のフォームで編集できるか」を制御するだけで、公式ヘルプいわく「App formulaや初期値の適用、アクションの実行などほかの動作には影響しない」点も覚えておきましょう。アクション経由で値を書き換える経路があるなら、そちらはアクション側で制御します（次の方法4）。

方法4：見せる画面・ボタンを分ける——ビューのShow ifとアクションの条件

最後は、メニューに出す画面（ビュー）と、押せるボタン（アクション）の出し分けです。

• ビューの「Show if」：公式ヘルプ「Views: The Essentials」によると、各ビューのDisplayセクションにあるShow ifに、そのビューをナビゲーションに含めるかどうかを決めるYes/No式を設定します。「管理者専用の集計画面」ならUSERROLE() = "Admin"のような式になります。

• アクションの「Only if this condition is true」：「Actions: The Essentials」によると、各アクションのBehaviorセクションにあるOnly if this condition is trueで、どの行にそのアクションを表示するかを式で決めます。「承認」ボタンを上長にだけ出すならIN(USEREMAIL(), 上長[メール])のように書きます。誤操作が怖い操作は、同じ場所にあるNeeds confirmation?を有効にして確認ダイアログを挟むのもおすすめです。

こちらも公式ヘルプが明確に釘を刺しています。ビューのShow ifについて「Show ifはセキュリティ対策ではない。ナビゲーションからビューを隠すだけで、ユーザーがそのビューにアクセスする正当な手段はほかにもある」と書かれています。画面やボタンの出し分けは「使いやすさのため」であって、「守るため」の機能は方法1と方法2だと割り切ってください。公式ヘルプ「Limit users to particular tables, views, and actions」も、テーブルの更新権限・列のShow?／Editable?・ビューのShow if・アクションの条件を組み合わせて設計するよう案内しています。

組み合わせ例：営業日報アプリを「担当者」「上長」「管理者」で分ける

ここまでの4つの方法を、営業日報アプリを例に1つの設計にまとめてみます。テーブルは「日報（担当者メール、日付、訪問先、本文、承認、承認者メール）」「ユーザー（メール、役割、上長メール）」の2つとします。

• サインイン：Require user signinを有効化し、共有はメンバーのメールアドレスを個別に追加（Use app）

• 見せるデータ（日報テーブルのセキュリティフィルタ）：担当者は自分の日報、上長は部下の日報、管理者は全件

OR(
  [担当者メール] = USEREMAIL(),
  LOOKUP([担当者メール], ユーザー, メール, 上長メール) = USEREMAIL(),
  LOOKUP(USEREMAIL(), ユーザー, メール, 役割) = "管理者"
)

• できる操作（日報テーブルのAre updates allowed?）：管理者はALL_CHANGES、担当者はADDS_AND_UPDATES（削除不可）、上長はUPDATES_ONLY（承認欄の更新のみ）

• 列単位（承認・承認者メール列のEditable_If）：LOOKUP(USEREMAIL(), ユーザー, メール, 役割) <> "担当者"で、担当者本人は承認欄を触れないようにする

• 画面・ボタン：「承認待ち一覧」ビューのShow ifを上長・管理者のみTRUEに。「承認する」アクションはOnly if this condition is trueで[承認] <> TRUEかつ上長・管理者のときだけ表示

ポイントは、「担当者に自分の日報しか見せない」という守りの部分をセキュリティフィルタと更新権限で担保したうえで、画面やボタンの出し分けは使いやすさのために重ねている、という構造です。

やりがちな失敗と対処

• スライスやShow ifで「隠したつもり」になる：前述のとおり、どちらも公式にセキュリティ対策ではないとされています。他人に見せてはいけない行はセキュリティフィルタで、列はテーブル分割で対処してください。

• 担当者メール列の値がサインインのメールと一致しない：USEREMAIL()との照合はメールアドレスの文字列一致です。マスタに登録したアドレスの表記ゆれや、会社アドレスと個人Gmailの混在で「自分のデータが1件も出ない」トラブルがよく起きます。ユーザーマスタのメール列は、実際にサインインに使うアドレスをコピー＆ペーストで登録するのが確実です。

• 無料枠・Starterのままセキュリティフィルタを使おうとする：公式ヘルプの記載はCore以上です。試作段階で動かないときは、まずプランを確認してください。プランや料金の最新条件はご自身のアカウントの管理画面と公式サイトで確認することをおすすめします（当社の別記事「AppSheetで10人より多くのユーザーを無料で使う方法はある？」もあわせてどうぞ）。

• 裏側のスプレッドシートが全員に共有されている：アプリ側でどれだけ絞っても、データソースのシートそのものを全員が開ける状態では意味がありません。シートの共有はアプリの所有者（と必要最小限の管理者）に限定し、メンバーはアプリ経由でのみ触れるようにします。

• 複数人で同じ端末・同じアカウントを共有している：権限設計は「1人1アカウント」が前提です。共用アカウントではUSEREMAIL()による出し分けが成立しません。

まとめ

AppSheetの権限設計は、「見せるデータ」「できる操作」「見せる画面」の3つに分解し、それぞれセキュリティフィルタ、テーブルのAre updates allowed?（＋列のEditable_If）、ビューのShow if／アクションの条件で実現します。土台はサインインの必須化とUSEREMAIL()による判定、役割の管理は小規模ならUSERROLE()のAdmin／User、3つ以上に分けるならユーザーマスタ＋LOOKUP()が扱いやすい構成です。そして、画面やボタンを隠すだけでは守れないこと、セキュリティフィルタはCore以上のプランで利用できることの2点は、設計を始める前に押さえておいてください。

「部署や取引先ごとに見せる範囲を分けた業務アプリをAppSheetで作りたい」「今のアプリの権限設定に不安がある」という場合は、当社（Kirakuna）にご相談いただければ、業務の流れに合わせて一緒に設計いたします。

※本記事の内容は執筆時点（2026年9月）のAppSheet公式ヘルプおよび実際の開発で得た知見に基づきます。AppSheetの仕様・プラン条件は変更される場合があるため、最新情報は公式ヘルプでご確認ください。