AppSheetでスプレッドシートをアプリにする手順と列の型の決め方

先に知っておきたいこと:AppSheetが見ているもの

AppSheetの公式ガイドでは、既存データから作る場合、表の1行目に列見出しを置くことが前提として案内されています(How to create an app)。データ元にはGoogleスプレッドシートのほか、Excelなども選べます(公式ガイド)。

アプリ作成後、AppSheetは各列に「列構造(カラムの定義)」を持ちます。公式のエラー一覧には、キーに関する次のような項目があります(AppSheet Errors and Warnings)。

• 「Your table does not have a key.」:表にキーがない。エディタの列構造でキー列を追加・指定する
• 「AppSheet cannot deduce the key column.」:キー列を推定できない。データ画面の列構造から主キーを手動で選ぶ(複合キーは一覧の下の方にある)
• 「An unexpected number of columns have been found in the spreadsheet.」:シートの見出しを変えたあとに列構造を再生成していないと起きる

つまり、シートの列を増やしたり名前を変えたりしたら、アプリ側の列構造も更新が必要です。型とキーは「最初に決めて、あとから大きく変えない」のが安全です。

手順1:シートを「アプリ向け」に整える

アプリ化の前に、シート側で次の点を確認します。これは公式の仕様というより、編集上の準備チェックです。

1. 1行目に見出しを置き、見出しは重複させない(重複した列名は公式エラー一覧でも「duplicate field names」として扱われます)
2. 1列に入れるデータの種類をそろえる(「日付」列に「未定」と書かない)
3. 空行や、表の外に置いたメモ、結合セルをなくす
4. 1行が1件(1回の貸出、1件の注文など)になる形にする

説明用の例:備品貸出シート

以降の説明では、次の架空のシートを例にします。実在のデータや実行結果ではありません。

• L001、備品名：延長コード、借りた人：山田、貸出日：2026/10/01、返却予定日：2026/10/08、返却済み：TRUE、状態：良好、備考：
• L002、備品名：プロジェクター、借りた人：佐藤、貸出日：2026/10/03、返却予定日：2026/10/05、返却済み：FALSE、状態：要点検、備考：レンズに汚れ

手順2:シートからアプリを作る

1. AppSheetにログインし、「My Apps」を開きます。
2. 「Create」から「App」→「Start with existing data」を選び、アプリ名を設定します(操作順は公式ヘルプに基づきます)。
3. 「Choose your data」からGoogleスプレッドシートを選び、対象のファイルを指定して「Select」を押します。
4. アプリが作成されたら、「Customize your app」でエディタを開きます。
5. エディタでデータ(Data)の列構造を開き、次の節の確認表で全列を点検します。

ここでAppSheetはデータから列の型を推定し、キーも自動で選びます。自動の結果を正解とみなさず、必ず一列ずつ見ます。

手順3:キー列を決める

キー列は「その行を他の行と区別する列」です。決めるときの基準は次のとおりです。

• 重複しない(同じ備品を2回貸すなら、備品名はキーに向きません)
• 空にならない
• 作ったあとで書き換えない(借りた人や状態のように変わる列は避ける)
• 人が毎回入力しなくても作られる

例では「貸出ID」が候補です。アプリから行を追加する運用なら、列のKey設定を「貸出ID」に切り替え、その列の編集画面でInitial Value(初期値)にUNIQUEID()を設定する方法があります。UNIQUEID()は連番ではなく、ランダムな英数字のIDを生成します。行の更新時に再計算されるApp Formulaには設定しません(公式ヘルプ)。

また、LongTextなど、キーに選べない型もあります(公式ヘルプ)。キーに選べない・警告が出る場合は、その列を無理に使わず、別にID列を設けます。AppSheetが行番号の「_RowNumber」をキーにする場合もありますが、公式エラー一覧には「このデータ元ではRowNumberをキーにできない」場合があると記載されています。行番号に頼るのは避けるのが無難です。

手順4:列の型を決める確認表

次の表が、この記事の確認表です。左から順に、列の用途、型の候補、確認する内容を示します。型名と用途は公式の型一覧に基づきます。実際の選択肢はエディタで確認してください。

• 行を特定するID、型の候補：Text、確認すること：キー列にする。重複・空欄がないか。自動採番にするか
• 短い名前(備品名など)、型の候補：Text / Name、確認すること：1行で収まるか。人名や地名中心なら Name も候補
• 日付(貸出日など)、型の候補：Date、確認すること：シート側の値が日付として入っているか。文字列の混在がないか
• はい/いいえ(返却済み)、型の候補：Yes/No、確認すること：TRUE/FALSEで入っているか
• 選択肢が決まっている列(状態)、型の候補：Enum、確認すること：許可する値の一覧を必ず設定する
• 長い自由記述(備考)、型の候補：LongText、確認すること：空でもよいか。キーにしない
• 数量・金額、型の候補：Number / Decimal / Price、確認すること：小数が必要か。単位を列名に入れるか
• 写真、型の候補：Image、確認すること：保存先(シート上は画像ファイルの場所を示す文字列になる)を理解しているか

Enum型については、公式のエラー一覧に「許可する値のリストが指定されていない」場合のエラー(ERROR ALLOWED VALUES REQUIRED)があります。選択肢列を作るなら、値の一覧を先に決めておきます。

各列で最後に問う3点は、次のとおりです。

1. この列の値は将来も同じ種類か(日付列に文字を入れる運用がないか)
2. 入力者が自由に打つか、選ぶか(選ぶならEnum)
3. 空欄を許すか(許さないなら入力必須の設定を検討)

手順5:AIに型の案を出させる(依頼文と人の確認)

型の判断に迷う列は、生成AIに案を出させると速くなります。AIに任せるのは「候補と理由の提案」まで、人が確認するのは「実データに合うか」と「キーの安定性」です。実際の個人情報や社内データは貼らず、架空のサンプルに置き換えてください。

次の依頼文は、説明用の例です。

AppSheetでスプレッドシートをアプリ化します。
以下の列見出しとサンプル行(架空データ)を見て、列ごとに
(1) AppSheetの型の候補、(2) その理由、(3) キー列にすべきか
を表で出してください。
最後に、キー列の候補を1つ選び、重複や変更のリスクを指摘してください。
分からない列は推測せず「要確認」としてください。

見出し:貸出ID, 備品名, 借りた人, 貸出日, 返却予定日, 返却済み, 状態, 備考
サンプル:
L001, 延長コード, 山田, 2026/10/01, 2026/10/08, TRUE, 良好,
L002, プロジェクター, 佐藤, 2026/10/03, 2026/10/05, FALSE, 要点検, レンズに汚れ

返ってきた案は、そのまま採用せず、手順4の確認表と見比べます。AIは存在しない型名を出すことがあるため、型名はAppSheetの型の選択肢にあるかを必ず確かめます。

手順6:シートを変えたときの更新

作成後にシートの列を追加したり見出しを変えたりしたら、アプリ側で列構造を再生成します。Dataで対象のテーブルを選び、テーブル見出しの「Regenerate schema」を押し、「Regenerate」で確認して保存します(公式ヘルプ)。これを忘れると、前述の「列数が想定と違う」というエラーが出ることがあります。

運用を始めたあとに型やキーを変えるのは影響が大きいので、最初のテスト用に数行のダミー行を追加し、アプリから登録・編集して、シートに意図した形で値が入るかを確かめてから本番のデータに移ります。

最初の1本の確認リスト

• [ ] 1行目に重複しない見出しがある
• [ ] キー列は重複せず、空にならず、変わらない
• [ ] 日付・はい/いいえ・選択肢の列が、シートで型どおりの値になっている
• [ ] Enum列に許可する値が設定されている
• [ ] 列を足したら列構造を再生成した