第2回 では、AppSheet の概要やデータモデリングの重要性、そしてビジネスサイドが押さえるべきポイントについて整理しました。本記事（第3回）では、いよいよ UI/UX 構築 に焦点を当て、スプレッドシートと連携して AppSheet 上で画面を作る手順 を具体的にご紹介します。
- 本記事の概要
- ステップ1：Google スプレッドシートの準備
- ステップ2：AppSheet でテーブルを読み込み、カラム設定を行う
- ステップ3：ステータス変更アクションの設定（AppSheet エディタ > サイドメニュー > Actions）
- ステップ4：View（画面）の設定（AppSheet エディタ > サイドメニュー > Views）
- まとめ：UI/UX 構築のポイント
補足
- 第1回 … お手伝い申請アプリの全体像・アーキテクチャ
- 第2回 … AppSheet と データモデリング、ビジネスサイドの役割
- 第3回（本記事） … AppSheet での UI/UX 構築
- 第4回・第5回（今後） … Cloud Run 関数・Gemini 2.0 Flash との連携やオートメーション Bot の活用
本記事の概要
今回取り上げるアプリは、「お手伝い申請アプリ」 です。（※本アプリの全体像・アーキテクチャ などの概要については、第1回 をご参照ください。）
Google スプレッドシートにデータを保存し、AppSheet で以下のステップを踏むことで、「お小遣い申請 → 親の承認 → 支給」のフローを簡単に実装できます。
- テーブル定義（Key 列、Ref 列などのカラム設定）
- リレーション設定（複数テーブルを紐づける）
- 画面（View）とアクションを用いた UI/UX の設計
また、「お手伝いマスタ」から報酬金額を自動参照したり、ステータス変更時に承認日・支給日を自動入力する方法なども扱います。
次回（第4回・第5回）では、Cloud Run 関数 や Gemini 2.0 Flash を活用して画像解析を自動化し、AppSheet の Bot（オートメーション機能）と連動させる応用編を解説予定です。
ステップ1：Google スプレッドシートの準備
1. 各テーブル用のシートを作成
まず、ユーザ (ユーザテーブル)、お手伝いマスタ (お手伝いマスタテーブル)、申請履歴 (申請履歴テーブル) の3シートを用意します。
表の設計例は以下のとおりです（最小限）。
ユーザ
ユーザーID ユーザー名 メールアドレス ユーザー種別 1 はるか(仮名) haruka@example.com 子 2 そうた(仮名) 子 10 じょーじ george@example.com 親 お手伝いマスタ
お手伝いID お手伝い名 報酬金額 AI じょーじのチェック観点 3 朝ご飯づくり 150 - 日付のプレートが写っている
- すべての朝ご飯メニューが1枚に写っている
- Webから拾った画像ではない4 玄関掃除 20 （必要に応じてメモを書く） 申請履歴
申請ID ユーザーID お手伝いID お手伝いした日 申請金額 申請/承認ステータス 支給ステータス 申請日 承認日 支給日 承認者ID 証明写真 AI じょーじの判定 備考 3b6ff58a 3 2024/12/24 150 2024/12/24 申請履歴_Images/3b6ff58a.証明写真.095818.jpg
2. シートの共有設定
AppSheet からデータを読み書きするために、Google スプレッドシートを編集可能な権限 を対象ユーザーやサービス アカウントへ付与しておきます。
ステップ2：AppSheet でテーブルを読み込み、カラム設定を行う
2-1. AppSheet による新規アプリの作成
AppSheet にアクセスし、
- 「Create > App > Start with existing data」を選択
- 対象となる Google スプレッドシートを指定
- アプリ名を入力（例：「お手伝い申請アプリ」）
続いて、AppSheet がスプレッドシートをスキャンし、自動的にテーブルを検出します。
もし一部シートが追加されない場合は、左サイドメニュー「Data > Add new Data」から「Add Table」を用いて手動でシートを追加します。
ここで、ユーザ・お手伝いマスタ・申請履歴 の3テーブルがすべて取り込まれていることを確認してください（Are updates allowed?は初期値のままでOK）。
2-2. お手伝いマスタテーブルの設定例
「Data > Columns」 から、まずは「お手伝いマスタ」テーブルのカラムを設定します。
具体的には、以下のように設定する例です。
| Name | Type | Key? | Label? | Formula | Show? | Editable? | Require? | Initial Value | Display Name | Description | Search? |
|---|---|---|---|---|---|---|---|---|---|---|---|
| _RowNumber | Number | (自動生成) | AppSheet が自動生成する行番号 | ||||||||
| お手伝いID | Text | ✓ | ✓ | ✓ | UNIQUEID() |
お手伝いID | 一意の ID（Key 列） | ✓ | |||
| お手伝い名 | Text | ✓ | ✓ | ✓ | ✓ | お手伝い名 | 例：朝ご飯づくり、玄関掃除など | ✓ | |||
| 報酬金額 | Number | ✓ | ✓ | 報酬金額 | 例：150 円 | ✓ | |||||
| AI じょーじのチェック観点 | LongText | ✓ | ✓ | AI じょーじのチェック観点 | 画像判定時の注意点やメモ | ||||||
| Related 申請履歴s | List (Ref) | REF_ROWS("申請履歴", "お手伝いID") |
✓ | (自動生成) | Ref 設定に基づき自動生成される仮想カラム |
ポイント
- Key 列 には
UNIQUEID()を使う Related 申請履歴sは自動生成されるため削除しない
2-3. ユーザテーブルの設定例
同様に「ユーザテーブル」も設定を確認・修正します。「ユーザーID」を Key 列 (Type=Text) に設定すると良いでしょう。
| Name | Type | Key? | Label? | Formula | Show? | Editable? | Require? | Initial Value | Display Name | Description | Search? |
|---|---|---|---|---|---|---|---|---|---|---|---|
| _RowNumber | Number | (自動生成) | AppSheet が自動生成する行番号 | ||||||||
| ユーザーID | Text | ✓ | ✓ | ✓ | UNIQUEID() |
ユーザーID | Key 列として扱う | ✓ | |||
| ユーザー名 | Text | ✓ | ✓ | ✓ | ✓ | ユーザー名 | 画面表示用の名前 | ✓ | |||
| メールアドレス | ✓ | ✓ | メールアドレス | Type=Email でメール送信機能などを利用可能 | ✓ | ||||||
| ユーザー種別 | Text | ✓ | ✓ | ユーザー種別 | 「子」「親」などを区別 | ||||||
| Related 申請履歴s | List (Ref) | REF_ROWS("申請履歴","ユーザーID") |
✓ | (自動生成) | 申請履歴 entries that reference this entry... | ||||||
| Related 申請履歴s By 承認者ID | List (Ref) | REF_ROWS("申請履歴","承認者ID") |
✓ | (自動生成) | 申請履歴 entries that reference this entry... |
2-4. 申請履歴テーブルの設定と Ref・Formula
最後に、「申請履歴」テーブルを設定します。「お手伝いID」 や 「ユーザーID」 を Ref 型とし、申請金額 をマスタ連動させるなど調整します。
2-4-1. Ref によるテーブル間の関連付け
下図のように、AppSheet のカラム設定画面で Type=Ref / Source table を指定すると、 他テーブルへの参照（リレーション）が成立します。
これにより、他テーブルの情報を簡単に参照できるようになります（後述の Formula で活用）。
2-4-2. キーで紐づく他テーブルの値を連動表示
たとえば、「お手伝いID」 からマスタの「報酬金額」を引っ張る際、以下のように表示・利用できます。
2-4-3. カラム例：名前・タイプ・式など
最終的に「申請履歴」テーブルは、下記のようにカラムを設定できます。
| # | Name | Type | Key? | Label? | Formula | Show? | Editable? | Require? | Initial Value | Display Name | Description |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | _RowNumber | Number | (自動生成) | AppSheet が自動生成する行番号 | |||||||
| 2 | 申請ID | Text | ✓ | UNIQUEID() |
✓ | ✓ | 申請ID | 申請ごとに一意となる ID（Key列） | |||
| 3 | ユーザーID | Ref | LOOKUP(USEREMAIL(),"ユーザ","メールアドレス","ユーザーID") |
✓ | ✓ | ユーザー選択 | 「ユーザ」テーブルへの参照。ログイン中ユーザーを自動セット | ||||
| 4 | お手伝いID | Ref | ✓ | ✓ | ✓ | お手伝いID | 「お手伝いマスタ」への参照 | ||||
| 5 | お手伝いした日 | Date | ✓ | ✓ | TODAY() |
お手伝い日 | 日付を当日に自動設定 | ||||
| 6 | 申請金額 | Number | [お手伝いID].[報酬金額] |
✓ | 申請金額 | マスタ連動で報酬額を自動参照 | |||||
| 7 | 申請/承認ステータス | Text | ✓ | ✓ | ステータス | 申請／承認の状態。後述アクションで更新 | |||||
| 8 | 支給ステータス | Text | ✓ | ✓ | 支給ステータス | 「支給済み」操作用のステータス列 | |||||
| 9 | 申請日 | Date | ✓ | TODAY() |
申請日 | フォーム保存時に自動入力 | |||||
| 10 | 承認日 | Date | ✓ | ✓ | 承認日 | 後述のアクションで TODAY() をセット |
|||||
| 11 | 支給日 | Date | ✓ | ✓ | 支給日 | 後述のアクションで TODAY() をセット |
|||||
| 12 | 承認者ID | Ref | LOOKUP(USEREMAIL(),"ユーザ","メールアドレス","ユーザーID") |
✓ | ✓ | 承認者 | 「ユーザ」テーブルへの参照。誰が承認したか記録 | ||||
| 13 | 証明写真 | Drawing | ✓ | ✓ | 証明写真 | 画像アップ後、ペンツール等で注釈可能 | |||||
| 14 | AI じょーじの判定 | Text | ✓ | AI じょーじの判定 | 後の Cloud Run 関数で解析結果を書き戻す | ||||||
| 15 | 備考 | Text | ✓ | ✓ | 備考 | 任意のメモや補足用 |
2-4-4. Formula と Initial Value の使い分け
ステップ3：ステータス変更アクションの設定（AppSheet エディタ > サイドメニュー > Actions）
AppSheet エディタ では、左側サイドメニュー「Actions」からテーブルごとのアクションを管理します。
3-1. アクション設定の流れ
例として、「承認」 ボタンを新規に作る方法は下記です。
- AppSheet エディタ > サイドメニュー > Actions を選択
- 対象テーブル（例: 「申請履歴 (7)」）を開く
- 「Add Action」でアクションを追加
- Do this＝Data: set the values of some columns in this row
- Set these columns で「ステータス＝"承認済み"」「承認日＝TODAY()」などを指定
- 「Position」でボタン位置（Primary / Prominent / Inline / Hide）を選択
- 「Display name」を編集
- Behavior タブの Only if this condition is true に条件式（後述）を設定
- 必要があれば「Needs confirmation?」を ON にして確認ダイアログを表示
3-2. ステータス変更アクション例：承認・支給
- 「承認」ボタン
- 「申請/承認ステータス ＝ "承認済み"」
- 「承認日 ＝ TODAY()」
- 「支給」ボタン
- 「支給ステータス ＝ "支給済み"」
- 「支給日 ＝ TODAY()」
3-3. 子どもと親の権限制御（ユーザー種別を活用）
ここでは、子どもユーザ（ユーザー種別="子"）のみが新規申請できる 一方、「承認」や「支給」は親（"親"）しか実行できない という想定を例に挙げます。
3-3-1. ユーザー種別からロール判定
「ユーザテーブル」の 「ユーザー種別」 カラム（「子」「親」）を参照し、
LOOKUP(USEREMAIL(), "ユーザ", "メールアドレス", "ユーザー種別")
を使うことで、現在ログイン中のユーザー種別 を判定します。
どこで設定すべき？
- テーブルの「Are updates allowed?」やアクションの「Only if this condition is true」など、 ユーザー種別で動作を変えたい箇所でこの式を利用します。
- 例：「Add」操作を子ユーザだけ許可したい → テーブルのセキュリティ設定（Are updates allowed?）か、アクションの実行条件に式を入れる。
- 例：「承認」ボタンを親だけ表示したい → アクションの Behavior タブに
LOOKUP(USEREMAIL()...)= "親"を設定。
3-3-2. 新規追加（Add）を子ユーザだけ許可する例（セキュリティ設定）
Are updates allowed? と Security Filter の違い
AppSheet には「Security」タブの中に Security filter という機能がありますが、 これは主に 「ユーザーによって見せたくないレコードを完全に排除（非ダウンロード化）する」ための「行レベルの制限」です。一方、ここで説明している「Are updates allowed?」は、「このテーブル（またはユーザー）に対して、追加/更新/削除が可能かどうか？」を設定する項目です。
- Are updates allowed? … データの追加・編集・削除を許可/不許可にする（権限周り）
- Security filter … 指定条件に合わない行をサーバーから取得させない（閲覧自体を制限する）
混同しがちですが、別の機能 なので注意してください。
具体的な設定手順
「Data > [対象テーブル] > Table settings > Are updates allowed?」の欄で式を設定することで、 ユーザーごとの操作権限（追加・更新・削除） をコントロールできます。
たとえば、子ユーザだけ新規追加（Add）を許可し、それ以外を閲覧のみにする例として:
IF( LOOKUP(USEREMAIL(), "ユーザ", "メールアドレス", "ユーザー種別") = "子", "ALL_CHANGES", "READ_ONLY" )
を指定します。
あるいは、特定のユーザー メールアドレス ごとに詳細設定したいなら、SWITCH() 関数を使うことも可能です。 以下のように記述すると、ユーザー単位で「更新のみ」「すべて変更可能」「読み取り専用」など細かく分けられます。
SWITCH( USEREMAIL(), "user1@mydomain.com", "UPDATES_ONLY", "user2@mydomain.com", "ALL_CHANGES", "READ_ONLY" )
補足 「ALL_CHANGES」「UPDATES_ONLY」「READ_ONLY」など、AppSheet の Are updates allowed? で指定できる値の詳細はドキュメントを参照。
3-3-3. 親のみ「承認」「支給」操作を表示
「承認」や「支給」ボタンを 「親」ユーザーだけ操作可能にする場合、 アクションの Behavior > Only if this condition is true へ
LOOKUP(USEREMAIL(), "ユーザ", "メールアドレス", "ユーザー種別") = "親"
を設定してください。
ステップ4：View（画面）の設定（AppSheet エディタ > サイドメニュー > Views）
最後に、AppSheet エディタ > サイドメニュー > Views からアプリの画面デザインを整えます。
4-1. View 名・対象テーブル・表示形式
例として、下記のように設定可能です。
| 項目 | 設定値例 | 補足説明 |
|---|---|---|
| View name | ユーザ一覧 | 例：ユーザ一覧 / お手伝いリスト / 申請履歴 など画面ごとの名称 |
| For this data | ユーザテーブル | 表示させたいテーブルやスライスを指定 |
| View type | deck | 一覧の見せ方（table / deck / detail / gallery / calendar / chart / dashboard など） |
| Position | menu | 配置場所（下部タブ / ハンバーガーメニュー / リファレンスビューなど） |
| Sort by | ユーザー名, 昇順 | レコードのソート条件 |
| Group by | ユーザー種別 | グループ化したい列 |
| Group aggregate | NONE | グループごとに合計値などを表示するなら SUM / AVERAGE などを指定 |
| Main image | auto | 行アイコンとして表示する画像カラム |
| Image shape | Square Image | 画像表示の形状（Square / Round / Full など） |
| Primary header | ユーザー名 | 一覧表示の1行目（タイトル） |
| Secondary header | メールアドレス | 2行目（サブタイトル） |
| Summary column | (auto) | 右上に表示する数値項目。合計金額やステータスなど |
| Show action bar | ON (✓) | レコードごとのアクションボタンを表示するか |
| Actions | Automatic | アクションバーを自動（Automatic）でボタンを並べるか、手動（Manual）で指定するか |
4-2. Show_If でビュー自体を制御
- 親専用ビューを作る（例：承認管理画面） 「Show_If」に
LOOKUP(USEREMAIL(), "ユーザ", "メールアドレス","ユーザー種別")="親"
を設定すると、子ユーザには表示されません。
- 子専用ビューを同様に作成し、親ユーザから見えなくすることも可能です。
まとめ：UI/UX 構築のポイント
ここまでの手順で、お手伝い申請アプリの基本的な UI/UX を実装できます。
-
- 3シート（ユーザ / お手伝いマスタ / 申請履歴）を作成
- 編集権限を設定
AppSheet でスプレッドシートを読み込み
- 自動検出されたテーブルを確認
- 足りなければ「Add Table」で追加
カラム定義（Key列、Ref列など）
- Key列 に
UNIQUEID() - Ref 型でテーブルを紐づける →
Related ○○sが自動生成
- Key列 に
お手伝いマスタの報酬金額を申請金額に自動反映
- 申請履歴テーブルの「申請金額」で Formula =
[お手伝いID].[報酬金額]
- 申請履歴テーブルの「申請金額」で Formula =
日付・ステータス列の扱い
TODAY()で自動入力- 日本時間 (YYYY/MM/DD) にするにはロケールを日本に
アクション（Actions）によるステータス変更ボタン
- 「Data: set the value of some columns in this row」でステータスなどを自動更新
- Behaviorタブの条件式でユーザー種別ごとに表示・非表示制御
子どもだけ新規申請、親のみ承認・支給
LOOKUP(USEREMAIL(), "ユーザ", "メールアドレス", "ユーザー種別")を組み込み、操作制限- テーブルの「Are updates allowed?」設定 で制御する例や、 アクションの Only if this condition is true へ式を入れる例など、場面に応じて使い分け
View（画面）の設定（AppSheet エディタ > サイドメニュー > Views）
- 一覧・フォーム・カレンダーなどを切り替え
- Show_If でビュー自体の表示/非表示を条件制御
これだけで、子どもが写真付き申請 → 親が承認 → お小遣い管理 の流れを AppSheet ＋ スプレッドシート で運用可能です。
次回（第4回）では、Cloud Run 関数 と Gemini 2.0 Flash を組み合わせ、 画像や証明写真をサーバレスで解析し、結果を AppSheet へ書き戻す仕組みを解説します。 Bot（オートメーション） での自動連携も含めてご紹介予定ですので、ぜひご期待ください！
