AppSheetアプリは、作るところまでは比較的早く進められます。 Googleスプレッドシートや既存データをもとに、入力画面、一覧画面、検索、簡単な承認フローまで形にしやすいからです。
ただし、納品や社内共有の直前になると、別の問題が出てきます。
「この人にはどこまで見せてよいのか」 「現場担当は編集できるが、削除はできないようにしたい」 「管理者は全件見たいが、担当者は自分の分だけでよい」 「アプリは開けるのに、元データ側の権限が足りない」 「納品後、誰が直すのか決まっていない」
AppSheetは便利な一方で、共有、サインイン、Security Filter、データ元の権限、利用者ごとの操作範囲をまとめて考える必要があります。 アプリが動くことと、業務で安全に回ることは別です。
この記事では、AppSheetアプリを納品・共有する前に確認したい権限と運用ルールを、実務目線で整理します。 共有されたアプリをコピーする手順そのものを知りたい場合は、既存記事の AppSheetの共有方法 を先に確認してください。
1. 2026年のAppSheet納品前チェックで見るべき7項目
AppSheetの納品前チェックで最初に見るべきなのは、「アプリが開けるか」だけではありません。 本当に見るべきなのは、次の7項目です。
| 項目 | 確認すること |
|---|---|
| 共有範囲 | 誰に、どこまで共有するか |
| サインイン | どの認証プロバイダで使うか |
| ユーザー台帳 | 管理者、現場担当、閲覧者を整理したか |
| データ制限 | ユーザーごとに見える行や列を分けたか |
| 操作権限 | 追加、編集、削除、閲覧の範囲を分けたか |
| 役割別テスト | 実利用者の立場で画面を確認したか |
| 引き継ぎ | 担当者、変更ルール、バックアップ、問い合わせ先を残したか |
この7項目は、特別に難しいセキュリティ文書を作るという話ではありません。 納品後に「見えてはいけないデータが見える」「操作できると思った人が操作できない」「誰が直せばよいか分からない」とならないための最低限の確認です。
私が実務でAppSheetや業務システムの相談を受ける時も、最後に詰まりやすいのは機能そのものより運用です。 特に、管理者と現場担当で画面の見え方が違う場合、作成者のアカウントだけで確認しても不具合に気づけません。
AppSheetは「共有して終わり」ではなく、「誰が、何を、どこまでできるか」を決めて初めて業務で使える状態になります。
2. 共有範囲とサインインは納品前に決める
AppSheet公式ヘルプの Share: The Essentials では、アプリ共有時に「誰でも使える公開共有」か「制限された対象へ共有するか」を決める必要があると説明されています。 内部業務や機密データを扱うアプリでは、公開共有は避け、制限された対象に共有する前提で考えるのが基本です。
納品前には、まず次を決めます。
- 個人メールアドレス単位で共有するのか
- ドメイン単位で共有するのか
- Googleグループなどのグループ単位で管理するのか
- 社外のGoogleアカウントも使うのか
- 退職者や担当変更時に誰が共有解除するのか
次にサインインです。 AppSheet公式の Require sign-in では、機密データがある場合やユーザーを安全に識別する必要がある場合、サインインを要求する考え方が整理されています。
ここで注意したいのは、アプリのURLを知っている人が開ける状態にしないことです。 URL共有は便利ですが、業務アプリでは「リンクを転送された人がどこまで見えるのか」を必ず確認する必要があります。
納品前に作るべきなのは、難しい権限表ではありません。 最低限、次のようなユーザー台帳です。
| 役割 | 例 | 主な権限 |
|---|---|---|
| 管理者 | 責任者、管理部門 | 全体閲覧、編集、設定確認 |
| 現場担当 | 入力担当、配送担当、営業担当 | 自分の担当データの入力・更新 |
| 閲覧者 | 確認だけの人 | 閲覧のみ |
| 未共有ユーザー | 対象外の人 | アクセス不可 |
この台帳がないまま共有を始めると、後から個別対応が増えます。 「この人は見えてよいのか」「この人は編集してよいのか」を毎回判断することになり、運用が不安定になります。
3. Security Filterだけで安心せず、データ元の権限も確認する
AppSheetで権限の話をすると、Security Filterが出てきます。 公式ヘルプの セキュリティ フィルタ: 基本情報 では、Security Filterはテーブル内の各行をYes/No式で評価し、条件に合う行だけをアプリに含める機能として説明されています。
たとえば、担当者ごとに自分の案件だけを見せたい場合、Security Filterは有効です。 部署、担当者、ステータス、公開可否などを条件にして、アプリ側で見える範囲を絞れます。
ただし、ここで重要なのは、Security Filterだけで完全に安心しないことです。 公式ヘルプでも、Security Filterはデータアクセスを制限するが完全なセキュリティ対策ではなく、データソース側で機密データ操作を保護する必要があると説明されています。
納品前には、次の2層で確認します。
1. アプリ側で見える範囲
- 誰がどの行を見られるか
- 誰がどの列を見られるか
- 管理者だけが見る画面は分かれているか
- 担当者が他人の案件を検索できないか
- 削除や承認などのアクションが出すぎていないか
2. データ元側の保護
- 元のスプレッドシートやDriveフォルダを誰が開けるか
- アプリ利用者に元データを直接見せる必要があるか
- バックアップや履歴が残るか
- 個人情報や機密情報が不要に含まれていないか
- 共有解除や担当変更時の手順があるか
アプリ画面で見えないようにしたから大丈夫、で止めない方がよいです。 元データ、アプリ、共有設定、運用担当の4つを合わせて見ることで、納品後のトラブルを減らせます。
また、他社や別アカウントへアプリをコピーさせる場合はさらに注意が必要です。 AppSheet公式の Let another user copy your app では、コピー時にアプリ定義だけでなく、アプリデータ、画像・ファイルデータ、テンプレートなども含まれ得ることが説明されています。 サンプルアプリとして共有する場合は、本番データを含まない検証用コピーを作る方が安全です。
4. 管理者・現場担当・閲覧者で実利用テストをする
AppSheetの納品前テストでよくある落とし穴は、作成者のアカウントだけで確認してしまうことです。 作成者はほとんどの情報が見えるため、現場担当者の画面で何が起きるかを見落とします。
納品前には、最低でも次の4パターンで確認します。
| テスト対象 | 見るポイント |
|---|---|
| 管理者 | 全件確認、設定、メンバー管理、集計ができるか |
| 現場担当 | 必要な入力だけできるか、不要な削除ができないか |
| 閲覧者 | 見るだけの画面になっているか |
| 未共有ユーザー | アクセスできないことを確認したか |
AppSheet公式の Limit users to particular tables, views, and actions でも、ユーザー種別ごとに表示や機能を変える考え方が整理されています。 特に、管理者と通常ユーザーで機能差がある場合は、同じアプリ内で制御するのか、別アプリとして分けるのかも検討対象になります。
実利用テストでは、画面が開くかだけでなく、次を確認します。
- 新規登録できるか
- 編集してよい項目だけ編集できるか
- 削除ボタンが不要に出ていないか
- 他人のデータが検索結果に出ないか
- スマホでボタンや文字が見切れないか
- 通知や自動処理が想定通り動くか
- オフラインや通信不安定時の扱いを説明できるか
複数人が同じデータを更新する業務では、更新タイミングのルールも必要です。 AppSheet公式の Concurrent usage with multiple users では、複数ユーザーが同時に追加・更新・削除する場面の考え方が説明されています。 現場で同じレコードを複数人が触る可能性があるなら、誰が最終更新するのか、どこで確認するのかも運用ルールに入れておくべきです。
5. 引き継ぎは操作マニュアルではなく運用ルールまで残す
納品時に操作マニュアルだけ渡しても、運用は安定しません。 現場で困るのは、ボタンの押し方よりも「この場合は誰が判断するのか」です。
引き継ぎで残すべきなのは、次の4つです。
1. 担当者
- アプリの管理者は誰か
- 現場の問い合わせ先は誰か
- 退職、異動、担当変更時に誰が共有を見直すか
- CodeClimbなど外部支援者に相談する条件は何か
2. 変更ルール
- 項目追加は誰が判断するか
- 選択肢を増やす時に誰へ確認するか
- 画面変更をすぐ反映してよいか
- 本番データで試さず、検証用データで確認する流れがあるか
3. バックアップ
- 元データのバックアップ頻度
- 誤削除時の戻し方
- 重要な変更前に何を保存するか
- 過去履歴をどこまで残すか
4. 問い合わせ先
- 操作に困った時の連絡先
- 不具合時に伝えるべき情報
- 対応時間や優先順位
- よくある質問の置き場所
この4つがあると、納品後に担当者が変わっても運用が止まりにくくなります。 逆に、マニュアルだけで運用ルールがないと、少し例外が出ただけで誰も判断できなくなります。
AppSheetを使うか、kintoneを使うか、独自Webアプリにするか以前に、業務フローが整理されているかが重要です。 Excelやスプレッドシートの運用そのものが限界に近い場合は、Excel管理が限界になった会社の見直し手順 も合わせて確認してください。
6. AppSheetを業務で回すなら、運用設計込みで相談する
AppSheetは、業務アプリを小さく始めるには有効な選択肢です。 特に、既存のスプレッドシート運用があり、入力・一覧・検索・簡単な通知を早く形にしたい場合は、検討する価値があります。
一方で、長期的な保守、複雑な権限制御、AI処理との連携、コード管理、テスト自動化、外部システム連携まで見据えるなら、AppSheetだけで進めるべきかは一度比較した方がよいです。 CodeClimbでも、既存AppSheetの改善が合うケースと、Next.jsやSupabaseなどでWebアプリ化した方がよいケースは分けて考えます。
判断基準は、ツール名ではありません。
- 誰が入力するか
- 誰が承認するか
- 誰が全件を見られるか
- 誰が削除できるか
- データはどこに残すか
- 納品後に誰が直すか
- AIや自動化をどこまで入れるか
この整理ができていれば、AppSheetでもWebアプリでも、設計の質が上がります。 逆に、業務フローが曖昧なままツールだけ選ぶと、どの方法でも後から手戻りします。
CodeClimbでは、AppSheetの運用見直し、既存アプリの権限確認、業務フロー整理、Webアプリ化の比較までまとめて相談できます。 まずは1業務だけを対象に、今の運用、使っているデータ、困っている権限、納品後に直したい点を整理するのが現実的です。
システム開発ページ では、CodeClimbが対応する業務システム開発の考え方をまとめています。 また、AI活用と一緒に考える場合は 中小企業のAI導入は何から始めるべきか も参考になります。
AppSheetを「とりあえず作った」状態から「業務で回る」状態にしたい場合は、無料相談 から現在のアプリ構成や困っている点を送ってください。
FAQ
Q1. AppSheetの納品前チェックは開発者だけで行えばよいですか
開発者だけでは不十分です。 作成者の画面では問題が見えなくても、現場担当、閲覧者、未共有ユーザーの画面では別の問題が出ることがあります。 最低限、役割別に表示、入力、編集、削除、アクセス拒否を確認してください。
Q2. Security Filterを設定すれば安全ですか
Security Filterは重要ですが、それだけで完全に安全とは言えません。 公式ヘルプでも、Security Filterはデータアクセスを制限する機能であり、データソース側の保護も必要だと説明されています。 アプリ画面の見え方と、元データの共有範囲を分けて確認するのが安全です。
Q3. 社外のGoogleアカウントにも共有できますか
共有自体は可能なケースがあります。 ただし、Google WorkspaceやAppSheet側の管理者設定、共有方針、サインイン方式によって制限される場合があります。 納品前に、実際に使うメールアドレスでログイン確認まで行うのが確実です。
Q4. AppSheetと独自Webアプリはどちらがよいですか
小さく始めたい、既存のスプレッドシートを活かしたい、短期間で現場に試してもらいたい場合はAppSheetが合うことがあります。 一方で、複雑な権限制御、AI連携、コード管理、継続的な改修、テスト自動化まで必要な場合は、独自Webアプリも比較対象にした方がよいです。 先に決めるべきなのはツール名ではなく、業務フローと運用ルールです。
まとめ
AppSheetアプリの納品前に見るべきなのは、アプリが開けるかどうかだけではありません。
共有範囲、サインイン、ユーザー台帳、Security Filter、操作権限、役割別テスト、引き継ぎ。 この7項目を先に確認しておくと、納品後の「見えない」「見えすぎる」「誰が直すか分からない」を減らせます。
AppSheetは便利なツールですが、業務で使い続けるには運用設計が必要です。 小さく作り、実利用者で確認し、使いながら直せる仕組みまで残す。 その状態まで設計して初めて、社内アプリとして機能します。
AppSheetの共有や権限で不安がある場合は、まず既存のアプリ、元データ、利用者の役割を整理してください。 そのうえで、AppSheetで続けるべきか、Webアプリ化すべきか、AI活用まで含めるべきかを一緒に判断できます。
