AppSheetで営業管理や日報、申請アプリを作ったものの、「担当者には自分のデータだけを見せたい」「部署が違う社員に顧客情報を見せたくない」と悩むことがあります。画面をSliceで分けるだけでは、機密データの保護として十分ではありません。ユーザーごとに取得する行そのものを制限するには、AppSheetのセキュリティフィルターを設定します。設定にはログイン必須化、メールアドレス列の準備、管理者用の例外条件、実ユーザーでの動作確認が必要です。基本手順から実務向けの式、失敗しやすいポイント、運用開始後の確認方法まで、初心者にも再現しやすい形で解説します。
👑営業担当者ごとに画面を分けましたのに、ほかの担当者の顧客データまで見える可能性があるのですか？
🤖SliceやShow ifは主に画面表示を整える機能です。データの取得範囲を制限するには、セキュリティフィルターを使います。
👑見えなくする設定と、端末へ送らない設定は別物なのですね。
🤖そのとおりです。ログインしたユーザーを特定し、必要な行だけを取得する設計に整えていきましょう。
AppSheetのセキュリティフィルターとは
AppSheetのセキュリティフィルターは、テーブル内の各行について条件式を評価し、条件を満たす行だけをアプリに含める機能です。たとえば、顧客管理テーブルの担当者メール列とログインユーザーのメールアドレスが一致する行だけを取得できます。
基本となる式は、[担当者メール]=USEREMAIL()です。USEREMAIL()は、現在AppSheetへログインしているユーザーのメールアドレスを返します。AppSheet公式ヘルプでも、ユーザー自身のデータにアクセスを制限する例として、メールアドレス列とUSEREMAIL()を比較する方法が案内されています。
セキュリティフィルターは、行ごとにYesまたはNoを判定します。結果がYesなら端末へ送られ、Noならそのユーザーのアプリには含まれません。
SliceやShow ifとの違い
初心者が特につまずきやすいのが、セキュリティフィルターとSliceの違いです。どちらも画面上ではデータが絞り込まれるため、同じように見えます。しかし、データを扱う場所と目的が異なります。
| 機能 | 主な目的 | データの扱い | 機密データの制限 |
|---|---|---|---|
| セキュリティフィルター | ユーザーごとの行アクセス制限 | 条件に合う行だけをアプリへ送る | 行単位の制限に使用する |
| Slice | 用途別の一覧や入力画面を作る | 取得済みデータから仮想的な表を作る | 単独では代用できない |
| Show if | 画面や項目を表示・非表示にする | 画面上の見え方を切り替える | データ取得の制限にはならない |
| Editable if | 入力や編集を制御する | 編集可能な条件を決める | 閲覧範囲の制限とは別に考える |
Sliceで担当者別の一覧を作っても、元のテーブル全体がアプリへ読み込まれている可能性があります。公式ヘルプでも、Sliceだけではテーブル全体へのアクセスを確実に防げず、行データの制限にはセキュリティフィルターが必要と説明されています。
👑画面から隠れていることと、データを取得していないことは同じではありません。顧客情報や人事情報では、この違いを最初に確認したいですわね。
設定前に準備するデータ構成
セキュリティフィルターを正しく動かすには、式を入力する前のデータ設計が欠かせません。少なくとも、誰のデータなのかを判定できる列と、ユーザーを識別する仕組みを準備します。
ユーザーのログインを必須にする
USEREMAIL()をアクセス制御に使用する場合は、アプリへのログインを必須にします。ログインを必須にしていないアプリでは、利用者の本人確認ができず、USEREMAIL()を安全な判定材料として利用できません。
AppSheet公式ヘルプでは、機密情報を扱う場合やユーザーを安全に区別する必要がある場合に、ログインを必須にするよう案内しています。認証プロバイダや利用可能な契約条件は変更される可能性があるため、導入時は最新情報を公式サイトで確認してください。
業務テーブルに担当者メール列を作る
顧客管理、日報、申請、案件管理などの業務テーブルには、データの所有者を示す列を追加します。
| 列名の例 | 型 | 役割 | 設定例 |
|---|---|---|---|
| 案件ID | Text | 各行を識別するキー | 初期値にUNIQUEID() |
| 担当者メール | データの所有者を判定する | 初期値にUSEREMAIL() | |
| 部署ID | TextまたはRef | 部署単位の閲覧範囲を判定する | ユーザーマスタから取得 |
| 登録日時 | DateTime | 登録履歴を残す | 初期値にNOW() |
| 有効 | YesまたはNo | 削除せず利用対象を切り替える | 初期値をYes |
担当者メール列のInitial valueにUSEREMAIL()を設定すると、新しい行を登録したユーザーのメールアドレスを自動入力できます。利用者が別のメールアドレスへ書き換えないよう、通常ユーザーには編集できない設定にしておくと管理しやすくなります。
ユーザーマスタを作る
管理者、部署責任者、一般担当者で閲覧範囲を変える場合は、ユーザーマスタを用意します。
| メール | 氏名 | 部署ID | 権限 | 有効 |
|---|---|---|---|---|
| user-a@example.com | 担当者A | 営業1課 | 一般 | Yes |
| manager@example.com | 営業責任者 | 営業1課 | 責任者 | Yes |
| admin@example.com | 管理者 | 管理部 | 管理者 | Yes |
メールアドレスは、AppSheetへログインするときの表記と完全に一致させます。前後の空白、全角文字、入力間違い、退職者の古いアドレスが残っていると、必要なデータが表示されません。
セキュリティフィルターを設定する手順
手順1：ログイン必須を有効にする
- AppSheetのアプリエディタを開きます。
- Securityを開きます。
- Require sign-inの設定画面を開きます。
- ユーザーのログインを必須にする項目を有効にします。
- 利用する認証プロバイダを選択します。
- アプリを保存し、対象ユーザーへ共有します。
設定画面の名称や配置はアップデートで変更される場合があります。メニューが見つからないときは、エディタ内の検索またはAppSheet公式ヘルプで現在の手順を確認してください。
手順2：担当者メールを自動記録する
- Dataから対象テーブルの列設定を開きます。
- 担当者メール列を追加または選択します。
- 列の型をEmailにします。
- Initial valueにUSEREMAIL()を設定します。
- 一般ユーザーが担当者を変更できないよう編集条件を調整します。
- テスト行を登録し、メールアドレスが保存されるか確認します。
既存データの担当者メールが空欄の場合、基本式では誰にも表示されなくなります。本番設定前に、既存行へ正しい担当者メールを登録してください。
手順3：対象テーブルへ条件式を設定する
- Securityを開きます。
- Security Filtersを選択します。
- アクセスを制限したいテーブルを開きます。
- Security filter欄へ条件式を入力します。
- 式のエラーがないことを確認します。
- アプリを保存して同期します。
自分が担当する行だけを表示する基本式は、[担当者メール]=USEREMAIL()です。AppSheet公式の基本手順でも、SecurityからSecurity Filtersを開き、対象テーブルにYesまたはNoを返す式を設定する流れが案内されています。
手順4：実際のユーザーアカウントで確認する
作成者のプレビュー画面だけで確認を終えてはいけません。管理者アカウントではすべてのデータが見える条件にしていることが多く、一般ユーザーの設定ミスを発見できないためです。
- 担当者Aでログインし、担当者Aのデータだけが表示されるか確認します。
- 担当者Bでログインし、担当者Aのデータが表示されないか確認します。
- 管理者でログインし、管理対象のデータが表示されるか確認します。
- 新しい行を追加し、担当者メールが自動入力されるか確認します。
- 担当者を変更した場合の表示結果を確認します。
- 退職者や無効ユーザーがアクセスできない状態になっているか確認します。
👑「見えるべきデータが見える」だけでなく、「見えてはいけないデータが見えない」ことも、別アカウントで確かめる必要がありますわ。
実務で使えるセキュリティフィルターの式
自分の担当データだけを表示する
[担当者メール]=USEREMAIL()
営業案件、個人の日報、訪問記録、問い合わせ履歴など、1行につき1人の担当者が決まっている業務に向いています。最も単純で管理しやすいため、初めて設定するときはこの形から始めます。
一般ユーザーは自分だけ、管理者はすべて表示する
OR([担当者メール]=USEREMAIL(),LOOKUP(USEREMAIL(),”ユーザーマスタ”,”メール”,”権限”)=”管理者”)
一般担当者には自分の行だけを表示し、管理者には全行を表示する例です。ユーザーマスタの権限表記は、「管理者」「一般」などに統一してください。「管理者」と「管理」のように表記が混在すると正しく判定されません。
同じ部署のデータを表示する
[部署ID]=LOOKUP(USEREMAIL(),”ユーザーマスタ”,”メール”,”部署ID”)
営業所、店舗、施設、プロジェクトチームなど、所属単位でデータを共有する場合に使えます。業務テーブルとユーザーマスタの部署IDは、名称ではなく変更しにくい固定IDで管理すると安全です。
有効なデータだけを表示する
AND([担当者メール]=USEREMAIL(),[有効]=TRUE)
過去データを削除せず、通常画面から除外したい場合に使います。ただし、法令や社内規程に基づく保存期間があるデータは、単に非表示にするだけでなく、保存・削除ルールを別途定めてください。
本人または同じ部署の責任者に表示する
OR([担当者メール]=USEREMAIL(),AND([部署ID]=LOOKUP(USEREMAIL(),”ユーザーマスタ”,”メール”,”部署ID”),LOOKUP(USEREMAIL(),”ユーザーマスタ”,”メール”,”権限”)=”責任者”))
一般担当者は自分の行だけを閲覧し、責任者は所属部署の行を閲覧する例です。条件が長くなるほど設定ミスを見つけにくくなるため、一般、責任者、管理者のテストアカウントを用意します。
👑複雑な式を一度に作るより、本人だけ、部署責任者、管理者の順に条件を追加すると、どこで判定が崩れたか見つけやすいですわ。
業務別の設定例
営業案件管理
案件テーブルに担当者メールと部署IDを持たせます。担当者には自分の案件だけを表示し、営業責任者には同じ部署の案件を表示します。経営者や管理部門が全社データを確認する場合は、ユーザーマスタの権限を利用して例外条件を追加します。
日報・作業報告
一般社員は自分の日報だけを閲覧し、上司は部下の日報を確認できる構成にします。登録者メールを後から自由に変更できると他人の日報として登録できるため、登録時に自動記録し、一般社員には編集させない運用が適しています。
申請・承認管理
申請者には自分の申請だけを表示し、承認者には自分が承認すべき申請を表示します。承認完了後に経理担当者へ引き継ぐ場合は、申請者、承認者、処理担当者の列を分けて設計します。
店舗別の在庫管理
店舗IDを使い、各店舗には自店舗の在庫だけを表示します。本部担当者には全店舗を表示します。ただし、複数店舗間で商品を移動する場合は、移動元と移動先の両方から必要なデータを確認できる条件が必要です。
顧客・個人情報管理
顧客情報は担当者別に分けるだけでなく、列ごとの表示、編集権限、元データの共有権限も確認します。セキュリティフィルターは行単位の機能であり、同じ行に含まれる一部の機密列だけを完全に分離するものではありません。機密度が大きく異なる情報は、別テーブルや別アプリへ分ける方法も検討します。
よくある失敗と改善方法
Sliceだけでデータを制限している
担当者別Sliceを作り、一覧画面から他人のデータが消えたことで設定完了と判断する失敗です。Sliceは画面設計には役立ちますが、セキュリティフィルターの代わりにはなりません。
改善するには、元テーブルへセキュリティフィルターを設定し、そのうえで用途別のSliceを作ります。セキュリティフィルターで取得範囲を制限し、Sliceで使いやすい画面を作るという役割分担です。
ログイン必須を設定していない
USEREMAIL()を式に使っていても、ログインを必須にしていなければ、本人を安全に識別できません。メールアドレスを利用者自身に入力させる方法も、なりすましを防ぐ認証にはなりません。
機密情報を扱うアプリでは、認証プロバイダによるログイン、アプリの共有対象、退職者のアクセス停止まで一体で管理します。
既存行の担当者メールが空欄になっている
新規行にはUSEREMAIL()が入っていても、設定前から存在する行は空欄のままです。その結果、セキュリティフィルターを有効にした直後に過去データが消えたように見えます。
設定前に空欄件数を集計し、担当者が特定できる行へ正しいメールアドレスを登録します。所有者を判断できないデータは、管理者確認用の一時テーブルへ分ける方法もあります。
管理者自身もデータを見られなくなる
[担当者メール]=USEREMAIL()だけを設定すると、管理者も自分が担当する行しか見られません。管理者に全データを見せる必要がある場合は、ユーザーマスタの権限を使った例外条件を加えます。
ただし、管理者を増やしすぎるとアクセス制限の意味が薄れます。閲覧が必要な担当者だけに権限を付与し、定期的にユーザーマスタを見直してください。
アプリ作成者の画面だけで確認する
作成者は管理者条件に一致していることが多く、一般ユーザーの表示範囲を再現できません。プレビューのユーザー切り替えだけでなく、実際の端末とテストアカウントでも確認します。
条件式を複雑にしすぎる
複数のSELECT、FILTER、LOOKUPを何段も組み合わせると、動作確認が難しくなり、データ量や接続先によっては同期処理にも影響します。単純なメールアドレス比較から始め、必要な条件だけを追加してください。
セキュリティフィルターは端末へ送る行数を減らすため、アプリのデータ量削減にも役立ちます。ただし、Googleスプレッドシートをデータソースにしている場合は、AppSheetサーバーがシートを読み取った後に条件を適用する仕組みです。データベースでは単純な条件をデータ取得側へ反映できる場合があり、接続先によって処理のされ方が異なります。
👑表示トラブルが起きたときは、式だけでなく、ログイン中のメール、担当者列、ユーザーマスタ、同期状態を順番に確認するとよろしいですわ。
セキュリティフィルターだけに頼らない運用設計
セキュリティフィルターはデータアクセスを制限しますが、これだけで情報管理が完了するわけではありません。AppSheet公式ヘルプでも、機密データはデータソース側でも保護する必要があると案内されています。
元データの共有権限を確認する
GoogleスプレッドシートのURLを知っている社員が直接ファイルを開ける状態では、AppSheet側で行を制限しても元データを閲覧できる可能性があります。ファイルの共有相手、共有リンク、編集者、退職者のアカウントを確認します。
表示権限と編集権限を分ける
データが見えることと、変更できることは別の権限です。閲覧だけを許可する担当者、ステータスだけ変更できる承認者、全項目を編集できる管理者を分けます。
必要に応じて、テーブルの更新モード、列のEditable if、画面のShow if、Actionの実行条件を組み合わせます。これらはセキュリティフィルターとは役割が異なるため、置き換えるのではなく併用します。
退職・異動時の手順を決める
退職者をユーザーマスタで無効にしただけでは、アプリの共有設定や認証側のアカウントが残る場合があります。次の項目を退職・異動手順に含めます。
- AppSheetの共有対象から外す
- Google Workspaceなどのアカウントを停止する
- 元データの共有権限を解除する
- 担当中のデータを後任者へ移す
- 管理者や責任者の権限を更新する
- 不要になった端末やショートカットを回収する
監査に必要な情報を記録する
登録者、登録日時、最終更新者、最終更新日時を記録すると、誤更新や問い合わせが発生したときに追跡しやすくなります。アクセス制限を設定するだけでなく、誰が何を変更したか確認できる状態を整えます。
導入に向いているケースと慎重にすべきケース
| 判断 | 業務例 | 理由 |
|---|---|---|
| 向いている | 担当者別の営業案件 | 所有者メールで行を明確に分けられる |
| 向いている | 部署別の日報や点検記録 | 部署IDで閲覧範囲を整理できる |
| 向いている | 本人と承認者が見る申請管理 | 役割別の条件を設計しやすい |
| 慎重に検討 | 給与、医療、評価などの高機密情報 | 行制限以外の対策や専門的な確認が必要 |
| 慎重に検討 | 1行の中に複数部署の機密情報が混在する業務 | 行単位の制限だけでは分離しにくい |
| 慎重に検討 | 複雑な組織階層が頻繁に変わる業務 | 権限マスタの保守負担が大きくなる |
高機密情報や法令対応が必要な業務では、現場担当者だけで判断せず、情報システム担当者、管理責任者、必要に応じて専門家へ確認してください。
作業時間を減らす導入チェックリスト
セキュリティ設定を後から継ぎ足すと、既存データの修正や再テストに時間がかかります。アプリを本番共有する前に、次の順序で進めると手戻りを減らせます。
- 誰がどのデータを見るか、役割ごとの一覧を作ります。
- 業務テーブルに担当者メールまたは部署IDを追加します。
- ユーザーマスタにメール、部署、権限、有効状態を登録します。
- アプリのログインを必須にします。
- 最も単純なセキュリティフィルターを設定します。
- 一般、責任者、管理者のテストアカウントで確認します。
- 元データの共有権限と編集権限を確認します。
- 退職、異動、代理対応時の更新手順を決めます。
- 本番公開後も定期的にユーザーと権限を棚卸しします。
AIに任せやすいのは、権限パターンの整理、テストケースの作成、設定チェックリストの下書きです。一方、誰にどの顧客情報を見せるか、法的にどの情報を分離すべきか、管理者権限を誰へ与えるかは、人間が責任を持って判断します。
👑式を完成させることがゴールではありませんの。異動や退職が起きても権限を更新できるよう、担当者と確認時期まで決めておきましょう。
よくある質問
セキュリティフィルターとSliceは両方必要ですか？
用途によっては両方使います。セキュリティフィルターでユーザーが取得できる行を制限し、Sliceで未対応案件や今月の日報など、業務に合わせた画面を作ります。
USEREMAIL()を設定すればログインは不要ですか？
不要にはなりません。アクセス制御にUSEREMAIL()を使う場合は、ログインを必須にして利用者を認証します。利用者自身にメールアドレスを入力させる方法は、本人確認の代わりにはなりません。
管理者だけ全データを表示できますか？
できます。ユーザーマスタに権限列を作り、管理者の場合は全行を許可する条件を追加します。管理者の人数は必要最小限にし、定期的に見直してください。
担当者を変更したらデータはどうなりますか？
担当者メールを変更して同期すると、旧担当者の条件から外れ、新担当者の条件に含まれます。引き継ぎ前後に両者が閲覧する必要がある場合は、担当者列を複数にするか、引き継ぎ用の状態を設計します。
設定後に過去データが表示されなくなったのはなぜですか？
既存行の担当者メールが空欄、メールアドレスが不一致、ユーザーマスタに利用者が未登録といった原因が考えられます。ログイン中のメールアドレスと各列の値を照合してください。
セキュリティフィルターを使うと同期は速くなりますか？
端末へ送る行数が減るため、データ量削減につながる場合があります。ただし、データソースや条件式によって処理方法が異なります。複雑な式を増やすより、不要な行や列の整理と合わせて確認してください。
無料プランでもセキュリティフィルターを利用できますか？
利用できる機能や契約条件は変更される可能性があります。AppSheet公式ヘルプでは、セキュリティフィルターの対象プランが案内されているため、本番利用前に現在の料金ページと契約内容を確認してください。
おすすめAIツール
ChatGPTなどの生成AIは、セキュリティフィルターの式を考える補助として利用できます。業務テーブルの列名、ユーザーマスタの構成、一般・責任者・管理者の閲覧ルールを整理し、「権限ごとのテストケースを表にして」と依頼すると、確認漏れを減らしやすくなります。
ただし、実際の顧客名、社員のメールアドレス、個人情報、認証情報、社外秘データは入力しないでください。AIが作った式もそのまま本番へ反映せず、AppSheetの式エディタ、公式ヘルプ、テストアカウントで確認します。AIは下書きや整理を担当し、最終的なアクセス権限は業務責任者が判断する使い分けが適切です。
関連記事
- AppSheetの始め方｜Googleスプレッドシートからアプリを作る手順
- AppSheetのオフライン設定と同期エラー対策｜データが反映されない原因と解決方法
- AppSheetで顧客管理（CRM）アプリを作る方法
- AppSheetで在庫管理する方法｜Googleスプレッドシート連携で入出庫・在庫数をアプリ化する手順
- AppSheetでバーコード・QRコード在庫管理を作る方法｜スマホで入出庫を記録する設定手順
まとめ
- セキュリティフィルターは、条件に合う行だけをユーザーのアプリへ送るための設定
- USEREMAIL()をアクセス制御に使う場合は、ログイン必須化と担当者メール列の準備が必要
- SliceやShow ifは画面設計に使い、機密データの行制限とは役割を分ける
- 一般、責任者、管理者の実アカウントで、見えるデータと見えないデータの両方を確認する
AI執事の整理では、最初から複雑な権限式を作る必要はありません。まずは担当者メールとUSEREMAIL()を比較する単純な構成をテストし、その後に部署責任者や管理者の条件を追加します。式の設定と同時に、元データの共有権限、退職者のアクセス停止、定期的な権限確認まで運用手順へ組み込むことで、AppSheetを実務で安全に使いやすくなります。
