AppSheetで共有範囲と編集権限を決める：閲覧だけの人を作る考え方

「共有」と「権限」を分けて考える

混乱の原因は、次の3つが別々の設定なのに一つのものに見えることです。

• ① アプリの共有、決めること：誰がアプリを開けるか、主な設定の場所：アプリの共有・ユーザー管理
• ② アプリ内の権限、決めること：誰がどのテーブルで追加・更新・削除できるか、どの行が見えるか、主な設定の場所：テーブルの更新設定、セキュリティフィルタ
• ③ データの置き場所の共有、決めること：誰がスプレッドシート等を直接開けるか、主な設定の場所：Googleドライブ等の共有設定

①の共有は、誰がアプリを使えるかを決める設定です。アプリの編集者として共有する設定は、アプリを使う権限とは別です。③のデータソース側の権限も別に確認してください。AppSheetのヘルプも、セキュリティフィルタは完全なセキュリティ対策ではなく、機密データの操作はデータソース側で保護するよう案内しています（Security filters）。

手順1：役割と対象テーブルを紙に書き出す

画面を開く前に、次の2つを書きます。

• 役割：例）管理者、担当者、閲覧のみ
• テーブル：例）備品一覧、貸出記録、メンバー（役割を持つ表）

AIに下書きを頼む場合は、実名やメールアドレスを入れず、次のように依頼します（ダミーで十分です）。

AppSheetで備品貸出アプリを作ります。
役割は「管理者」「担当者」「閲覧のみ」の3つです。
テーブルは「備品一覧」「貸出記録」「メンバー」です。
役割ごとに、各テーブルで「見える行」「追加」「更新」「削除」を
表にしてください。迷う箇所は、判断が必要な点として別に挙げてください。

AIの返答は下書きです。「閲覧のみの人に貸出記録の本人分だけ見せるか全件見せるか」のような運用判断は、AIではなく人が決めます。

手順2：権限マトリクスを作る

以下は説明用の例です。○は可、×は不可、「自分の行」はその人のメールアドレスに一致する行だけを指します。

• 備品一覧、管理者：見える／追加○ 更新○ 削除○、担当者：見える／追加× 更新× 削除×、閲覧のみ：見える／すべて×
• 貸出記録、管理者：全件見える／追加○ 更新○ 削除○、担当者：全件見える／追加○ 更新○（自分の行） 削除×、閲覧のみ：自分の行のみ見える／すべて×
• メンバー（役割表）、管理者：全件見える／更新○、担当者：見えない、閲覧のみ：見えない

作るときのコツは3つです。

• 「閲覧のみ」の列は、基本的に「更新設定は読み取り専用」と書けるかを確認します。
• 役割を持つメンバー表は、管理者以外に見せないのが無難です。誰が管理者かを知られる必要はありません。
• 迷った箇所は、先に厳しく（見せない・編集させない）してから、必要が出たら緩めます。

手順3：テーブルの更新設定で「閲覧のみ」を作る

AppSheetのヘルプでは、テーブルごとに「Updates」「Adds」「Deletes」を選んで許可でき、「Read-only」を選べば読み取り専用になると説明されています（Control add, update, and delete operations）。固定の選択のほか、式で動的に決めることもできます。

役割で切り替えたいときの考え方の例を示します（説明用の例で、実際のアプリでは未実行です）。メンバー表から呼び出し元のメールアドレスの役割を引き、その結果で更新モードを返します。

IF(
  LOOKUP(USEREMAIL(), "メンバー", "メール", "役割") = "管理者",
  "ALL_CHANGES",
  "READ_ONLY"
)

式で返す更新モードは、ALL_CHANGESやREAD_ONLYなどヘルプに記載された値を使います（更新モードの一覧）。ただし、この例のLOOKUP()式は説明用で、役割の列を使うには、ユーザーがその役割を設定・変更できないようにするなど、表自体の保護も設計してください。組み込みのUSERROLE()が返す役割はAdminとUserだけで、独自の役割は追加できません（USERROLE()）。そのため、「閲覧のみ」のような独自ロールはメンバー表などで管理し、式やデータへのアクセスを適切に制限します。

手順4：行の絞り込みは「セキュリティフィルタ」で考える

「閲覧のみの人には自分の貸出記録だけ見せたい」場合は、更新設定ではなく行の絞り込みの話です。AppSheetのセキュリティフィルタは、ユーザーが自分のデータだけを使えるようにするための機能で、ビューの見た目を変えるだけのものとは区別されています。利用にはサインインが必要です（Limit users to their own data using security filters）。

貸出記録テーブルに「借りた人のメール」列がある想定なら、考え方は「その列の値が現在のユーザーのメールと等しい行だけ」を残す条件です。管理者には全件、他の人には自分の行、という分岐も、役割を引く式と組み合わせて作れます。

ビューを隠す設定だけで、データへのアクセスを制限したことにはなりません。行の閲覧範囲を制限するにはセキュリティフィルタを検討します。ただし、フィルタも完全なセキュリティ対策ではないため、機密データはデータソース側でも保護してください（セキュリティフィルタ、テーブル・ビュー・アクションの制限）。

設定後に人が確認すること

設定はAIや画面の見た目に任せず、役割ごとに実際に確認します。

1. テスト用アカウントを役割ごとに用意し（本番の人を使わない）、アプリを開く
2. 閲覧のみの人で、追加ボタン・編集ボタン・削除が出ないことを確認する
3. 閲覧のみの人で、見えてはいけない行や表が見えないことを確認する
4. 閲覧のみの人が、データの置き場所を直接開けないことを確認する（手順の③）
5. 管理者を一人だけ外した場合でも、運用が止まらないか考える

マトリクスの「×」と実際の画面が1か所でも食い違っていたら、公開前に直します。UI上で編集を無効にすることと、データを守ることは同じではない点は、更新設定のヘルプでも注意点として扱われています。

迷ったときの判断表

• 全員が全データを見るが、編集はごく一部、選ぶ方法：役割で更新設定を切り替える
• 人によって見える行が違う、選ぶ方法：セキュリティフィルタ
• 見せたくない表がある、選ぶ方法：その役割に表自体を見せない設計＋データ側の共有も絞る
• 機密性が高い、選ぶ方法：アプリ側の設定だけに頼らず、データ側の権限も絞る

まずは役割を3つ以内、表を3つ以内に絞って作ると、確認の手間が現実的な範囲に収まります。