AppSheet

解決する課題

現場の業務には、紙やスプレッドシートで回している小さな手作業がたくさんあります。点検記録、在庫の棚卸し、申請の受付、訪問報告などです。これらを正式なアプリにしたくても、開発者を確保してフルスクラッチで作るのはコストも時間もかかります。AppSheet は、すでにあるスプレッドシートやデータベースをそのままデータ源にして、コードを書かずに業務アプリを組み立てられるようにします。

• スプレッドシートで回している業務を、入力ミスや二重入力を防ぐアプリに置き換えたい
• アプリ開発の専任エンジニアがいなくても、現場の担当者が自分で内製したい
• スマホからの写真撮影・位置情報・署名・バーコードなどをフォームに取り込みたい
• 申請や承認、通知メールといった定型の自動化をノーコードで組みたい
• IT 部門はデータ接続と権限を管理しつつ、作成は現場に任せる分業をしたい

主要概念と用語

• アプリ（App）: AppSheet で作る業務アプリの単位。データ源・画面（ビュー）・自動化・権限をまとめて持つ
• データ源（Data Source）: アプリの土台となるデータ。Google スプレッドシート、Cloud SQL などのデータベース、各種クラウドストレージや表計算サービスを接続できる
• テーブル（Table）: データ源の中の表。列の型（テキスト、数値、日付、画像、位置情報など）を定義して扱う
• ビュー（View）: データを表示・操作する画面。一覧、詳細、フォーム、地図、カレンダー、ダッシュボードなどの形式がある
• 式（Expression）: 列の計算や表示条件、入力検証などを記述する数式。アプリの挙動をノーコードで制御する中心要素
• アクション（Action）: 行の更新、別ビューへの遷移、外部リンクの起動など、ユーザー操作に紐づく振る舞い
• オートメーション（Automation）: イベント（行の追加・更新など）をきっかけに、メール送信・通知・データ更新などを自動で実行する仕組み
• セキュリティフィルタ（Security Filter）: ユーザーごとに見える行を絞り込む式。手元の端末に同期するデータ範囲を制限する
• オフライン同期: ネットワークが切れていても操作でき、再接続時にデータ源と同期する仕組み

仕様・制限・クォータ

• ノーコード前提: アプリの大半は式と設定で構成する。一般的なプログラミング言語のコードは書かない
• データ源は外部接続: AppSheet 自体は専用のデータベースを持たず、スプレッドシートやデータベースなど接続したデータ源を読み書きする形が基本
• 対応プラットフォーム: 生成したアプリはブラウザと iOS / Android の両方で動作する
• 同期モデル: 端末はデータ源と同期して動作する。扱う行数や列数、画像などの容量が大きすぎると同期が重くなるため、データ規模には実用上の上限がある
• 行数・テーブル規模の目安: 大量データには不向きで、適度な規模の業務データに向く。大規模・高頻度の処理はデータベース側や別サービスに寄せる
• プランによる差: 利用できる接続先、ユーザー数、自動化や API の利用範囲は契約プランで変わる。具体的な上限値や本数はプランや時期で変動するため、最新は公式情報で確認する

内部の仕組み

AppSheet は、接続したデータ源を読み取って列の型や関係を推定し、初期のアプリ（ビューやフォーム）を自動生成します。作成者はそこに式・アクション・自動化を加えて挙動を整えます。実行時は、各ユーザーの端末がデータ源と同期し、許可された範囲のデータをローカルに持って動作します。

• データ源のテーブルとカラムを読み取り、型推論でフォームや一覧の初期形を作る
• 列の表示条件・入力検証・計算は式で定義し、サーバー側ではなくアプリの定義として評価される
• ユーザー操作や行の変更をイベントとして捉え、オートメーションがメール・通知・データ更新などを実行する
• セキュリティフィルタで、各ユーザーに同期する行をサーバー側で絞り込む
• オフライン時はローカルの変更を保持し、再接続時にデータ源へ反映して整合を取る

設計パターン / ベストプラクティス

• データ源を先に整える: 1 行 1 レコード、列ごとに型を統一し、一意キーを用意してから接続する
• 業務規模に合わせて選ぶ: 大量・高頻度のデータはスプレッドシートではなく**データベース（Cloud SQL など）**を源にして同期負荷を抑える
• セキュリティフィルタで範囲を絞る: 全行を全員に配らず、担当者やチーム単位で見える行を制限し、同期も軽くする
• 自動化はシンプルに保つ: 1 つのオートメーションに処理を詰め込みすぎず、イベントと処理を分けて見通しよく組む
• 式は読みやすく: 複雑な条件は仮想列や名前付きの中間列に分けて、保守しやすくする
• 現場内製とガバナンスを両立: 作成は現場、データ接続・権限・公開の管理は IT 部門、という分業で野良アプリ化を防ぐ

運用・監視

• 管理者向けの画面で、組織内に作られたアプリの一覧・利用状況・データ接続を把握する
• どのデータ源に誰が接続しているかを点検し、承認されていない接続や共有がないかを確認する
• アプリのバージョン管理を使い、本番に反映する前に変更を検証してから公開する
• オートメーションの実行履歴やエラーを確認し、メール送信や通知が想定どおり動いているかを追う
• 利用が少ない・放置されたアプリを棚卸しし、ライセンスとデータアクセスを整理する

コスト

課金は主に**アプリを使うユーザー数（プラン単位）**に基づきます。利用できる接続先や自動化、API、ユーザー管理の範囲がプランごとに異なり、個人検証向けの無償利用と、組織向けの有償プランに分かれます。データ源側（スプレッドシートやデータベース）の費用は別に発生します。

セキュリティ

• アプリ利用者はサインインで認証し、データ源やアプリへのアクセスを ID に紐づけて制御する
• セキュリティフィルタで、各ユーザーに見せる行をサーバー側で絞り込み、不要なデータを端末へ配らない
• データ源（スプレッドシートやデータベース）側の共有設定とアクセス権を最小限に保ち、AppSheet 経由の権限と二重で管理しない
• 機密データを扱うアプリは、接続先の選定・共有範囲・公開方法を IT 部門のガバナンス下に置く
• 組織管理機能で、作成できるユーザーや接続できるデータ源をポリシーで制限し、野良利用を防ぐ

関連サービス・比較

データの保管先として Google スプレッドシートや Cloud SQL と組み合わせるのが基本構成です。小規模・少人数ならスプレッドシートを源に手早く始め、データ量や同時利用が増えるなら Cloud SQL などのデータベースに移すと、同期の安定性と性能が高まります。他クラウドの相当サービスとしては Microsoft Power Apps が近い位置づけです。

ハンズオン / CLI例

AppSheet のアプリ作成は基本的にブラウザ上のエディタで行うため、専用の gcloud コマンドはありません。ここでは、データ源として使う Cloud SQL インスタンスを gcloud で用意する例を示します。

# データ源にする Cloud SQL (MySQL) インスタンスを作成
gcloud sql instances create appsheet-data \
  --database-version=MYSQL_8_0 \
  --tier=db-f1-micro \
  --region=asia-northeast1

# アプリ用のデータベースを作成
gcloud sql databases create fieldwork \
  --instance=appsheet-data

# 接続用ユーザーを作成（パスワードは Secret Manager 等で管理する想定）
gcloud sql users create appsheet-user \
  --instance=appsheet-data \
  --password=REPLACE_WITH_SECRET

# 作成したインスタンスの接続情報を確認
gcloud sql instances describe appsheet-data \
  --format="value(connectionName, ipAddresses[0].ipAddress)"