AppSheet Database 情シス向け設計・運用ガイド：スプレッドシートとの選択基準とRLS設計

AppSheet Databaseが2024年4月11日に一般提供（GA）されました。これまでAppSheetアプリのデータソースとしてスプレッドシートが主流でしたが、Googleマネージドのリレーショナルデータベースをノーコードで利用できるようになり、データ管理の選択肢が広がっています。

この記事を読んだほうが良い人

• AppSheetアプリのデータソースとしてスプレッドシートを多用しており、管理に課題を感じている情シス担当者
• 機器台帳、インシデント管理、申請管理などをスプレッドシートで運用しており、データ品質やアクセス制御に限界を感じている方
• ノーコードで社内データベース基盤を整備し、データガバナンスを強化したいと考えている方
• AppSheet Databaseの具体的な機能や制約、スプレッドシートとの違いを知りたい方

AppSheet Databaseとは？なぜ情シスが注目すべきか

AppSheet Databaseは、Googleが提供するAppSheetのデータソースとして利用できる、フルマネージドのノーコードデータベースです。リレーショナルデータベースとしての機能を持つため、複数のテーブルを関連付けたり、厳密なデータ型を定義したりできます。

これまでAppSheetアプリのデータソースとしてGoogleスプレッドシートが広く使われてきましたが、大規模なデータや複雑なリレーションシップを扱う際には、パフォーマンスの低下や管理の複雑さという課題がありました。AppSheet Databaseは、これらの課題を解決し、より堅牢なデータ基盤をノーコードで構築できる点が情シスにとって大きなメリットとなります。

AppSheet DatabaseはAppSheet Core、Enterprise Standard、Enterprise Plusのエディションで利用できます。

AppSheet Databaseで解決できる課題

• データ乱立と品質低下: 各部署で個別にスプレッドシートが作成・管理され、データの重複や不整合が発生している状況を改善します。AppSheet Databaseで中央集権的なデータソースを構築することで、データの一貫性を保てます。
• アクセス制御の複雑化: スプレッドシート単位でのアクセス権限管理では、細かい粒度での制御が難しく、情報漏洩のリスクを高める可能性があります。AppSheet Databaseの行レベルセキュリティ（RLS）により、より厳密なアクセス制御が可能です。
• パフォーマンスとスケーラビリティの限界: 大量のデータ行や複雑な計算式を含むスプレッドシートでは、AppSheetアプリの動作が遅くなることがあります。AppSheet Databaseは、より高速なデータ処理と高いスケーラビリティを提供します。

AppSheet Databaseとスプレッドシート、データソース選択の判断基準

AppSheetアプリのデータソースとして、AppSheet Databaseとスプレッドシートのどちらを選ぶべきか、それぞれの特徴を比較します。

項目	AppSheet Database	Google スプレッドシート
データ構造	リレーショナルデータベース、厳密なデータ型、リレーションシップ	フラットな表形式、柔軟なデータ入力（型指定は弱い）
スケーラビリティ	1テーブル最大20万行、1DB最大2GB、組織全体で100DB	1シート最大1,000万セル、パフォーマンスはデータ量に依存
パフォーマンス	大規模データでも高速なデータ処理と同期	大規模データでは処理が遅延する可能性あり
アクセス制御	行レベルセキュリティ（RLS・行単位でアクセス範囲を限定する機能）による詳細な制御	ファイル単位、シート単位のアクセス権限
データガバナンス	組み込みのデータ検証、監査ログ	ユーザーによるルール設定が必要、監査ログは限定的
共同編集	AppSheetアプリ経由でのデータ操作	複数ユーザーによる同時編集が可能
操作性	ノーコードでデータベース設計、AppSheetと密接連携	Excelライクな操作性、関数やマクロによる柔軟な処理
バックアップ	過去7日間の日次自動バックアップ、手動リストア不可	Google Driveのバージョン履歴、手動コピーによるバックアップ
料金	AppSheetサブスクリプションに含まれる	Google Workspaceサブスクリプションに含まれる
推奨ユースケース	構造化された基幹データ、機密情報を含む管理台帳、大規模なデータセット	小規模なデータ管理、一時的なデータ共有、自由な分析、簡易的な申請フォーム

AppSheet Databaseは、特に以下のようなケースが主な検討対象です。

• 機器台帳、顧客情報、従業員マスターなどの基幹データ
• インシデント管理、備品申請、契約管理など、構造化された申請・管理ワークフロー
• 行レベルでのアクセス制御が必要な機密性の高いデータ
• 既存のスプレッドシートが2万行を超えるような大規模データセット

AppSheet Databaseの設計と権限管理のポイント

AppSheet Databaseを活用する上で、情シスとして考慮すべき設計と権限管理のポイントを解説します。

1. データモデル設計

リレーショナルデータベースの基本的な考え方に基づき、データモデルを設計します。

• テーブルの正規化: データの重複を避け、整合性を保つために、関連するデータを複数のテーブルに分割し、外部キーで関連付けます。
• データ型の定義: 各列に適切なデータ型（テキスト、数値、日付、ブール値など）を設定し、データの入力規則を明確にします。
• 必須項目とデフォルト値: 必須項目やデフォルト値を設定することで、データ入力時のエラーを防ぎ、品質を向上させます。

設計例: 機器台帳

• 機器マスター テーブル: 機器ID (主キー), 機器名, 型番, シリアル番号, 購入日, 保証期間
• 利用者 テーブル: 利用者ID (主キー), 氏名, 所属部署, メールアドレス
• 貸出履歴 テーブル: 履歴ID (主キー), 機器ID (外部キー), 利用者ID (外部キー), 貸出日, 返却日

2. アクセス制御（行レベルセキュリティ）

AppSheet Databaseの大きな特徴の一つが行レベルセキュリティ（RLS）です。これにより、ユーザーの役割や属性に応じて、閲覧・編集できるデータの範囲を細かく制御できます。

例えば、「自分の部署の機器台帳のみ閲覧可能」「自分が担当する案件のインシデントのみ編集可能」といった設定が可能です。

設定の概説:

• データベースの準備: AppSheet Databaseのテーブルに、アクセス制御の基準となる列（例: 担当者メールアドレス、部署名、ロールなど）を追加します。
• RLSルールの作成: AppSheetの管理画面で、対象のデータベースを選択し、「セキュリティ」タブからRLSルールを設定します。ルールはAppSheetの式で記述します。
• 例1: [担当者メールアドレス] = USEREMAIL() （ログインユーザーのメールアドレスと一致する行のみ表示）
• 例2: [部署名] = LOOKUP(USEREMAIL(), "利用者", "メールアドレス", "部署名") （ログインユーザーの部署と一致する行のみ表示）
• AppSheetアプリへの適用: RLSルールを適用するAppSheetアプリのデータソース設定で、RLSを有効にします。

RLSは、情報セキュリティの観点から非常に重要であり、情シスが積極的に活用すべき機能です。

3. AppSheet Databaseの制約と注意点

AppSheet Databaseは強力なツールですが、いくつかの制約があります。

• 手動バックアップ・リストア機能の欠如: Googleによる過去7日間の日次自動バックアップはありますが、ユーザーが手動でバックアップを取得したり、特定の時点にリストアしたりする機能はありません。重要なデータは別途エクスポートするなど、バックアップ戦略を検討する必要があります。
• スケーラビリティの限界: スプレッドシートよりは優れていますが、大規模なエンタープライズ向けデータベース（例: Cloud SQL、BigQuery）と比較すると、行数、テーブル数、ストレージ容量に制限があります（1テーブル最大20万行、1DB最大2GBなど）。将来的なデータ増加を見越した設計が重要です。
• 外部からの直接アクセス不可: AppSheet DatabaseはAppSheetアプリ専用のデータソースであり、SQLクライアントや他のツールから直接アクセスすることはできません。データのエクスポートはAppSheet EditorからCSV形式で行います。

スプレッドシートからの移行時の注意点

既存のスプレッドシートからAppSheet Databaseへの移行を検討する際には、以下の点に注意してください。

• データクレンジング: 移行前にスプレッドシートのデータを整理し、重複や表記ゆれを修正します。AppSheet Databaseで定義する厳密なデータ型に合うように調整が必要です。
• データモデルのマッピング: スプレッドシートの各シートが、AppSheet Databaseのどのテーブルに対応するか、また列がどのようにデータ型にマッピングされるかを計画します。
• リレーションシップの再構築: スプレッドシートでは暗黙的に行っていたデータ間の関連付けを、AppSheet Databaseでは明示的なリレーションシップとして定義し直します。
• 段階的な移行: すべてのデータを一度に移行するのではなく、重要度の高い一部のデータから段階的に移行し、問題がないか検証しながら進めることを推奨します。
• ユーザーへの周知とトレーニング: データソースの変更は、AppSheetアプリの利用者にも影響します。変更内容や新しい操作方法について、事前に周知とトレーニングを実施しましょう。

まとめ：ノーコードDBで情シスのデータガバナンスを強化する

AppSheet Databaseの一般提供は、情シスにとってノーコードで堅牢な社内データ基盤を構築する大きな機会です。スプレッドシートの限界を乗り越え、データ品質の向上、アクセス制御の強化、パフォーマンスの改善を実現できます。

データモデルの適切な設計、行レベルセキュリティの活用、そして制約を理解した上での運用が成功の鍵となります。既存のスプレッドシートからの移行は計画的に行い、段階的なアプローチで進めることで、情シスはデータガバナンスを強化し、より効率的で安全な業務環境を提供できます。

AppSheet Databaseの活用で、情シスのデータガバナンスは具体的に前進する。まずは管理台帳1本のデータソースをAppSheet Databaseに切り替え、RLS設計の感触を実際の運用で確かめるところから始めるのが現実的なアプローチです。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。