AppSheetでアプリを作っていると、「アプリが開かない」「同期できない」「式が正しいはずなのにエラーになる」「Botが動かない」といった問題に直面することがあります。英語のエラーメッセージだけでは原因を判断しにくく、設定を何度も変更して、かえって状況を複雑にしてしまうケースも少なくありません。AppSheetのエラーは、データ構造、列設定、キー、数式、同期、自動化のどこで発生しているかを切り分けると解決しやすくなります。代表的なAppSheetエラー一覧と対処法を、初心者でも確認できる順番に整理します。
👑突然、赤いエラーがたくさん表示されましたの。どこから直せばよいのか、まったく分かりませんわ。
🤖エラー文を一つずつ追う前に、発生場所を確認しましょう。データ、式、同期、自動化のどこかを特定すると早く解決できます。
👑慌てて設定を全部変更するのではなく、原因を絞り込むのですね。
🤖はい。変更前の状態を残し、一つ直すたびに保存と動作確認を行うのが基本です。
AppSheetでエラーが出たときの基本的な確認手順
AppSheetでエラーが発生したときは、思いついた設定を手当たり次第に変更してはいけません。複数の設定を同時に変更すると、どの修正が有効だったのか分からなくなり、新しい不具合を生む可能性があります。
次の順番で確認すると、原因を効率よく切り分けられます。
- エラーが表示された画面と操作を記録する
- エラーメッセージの全文を保存する
- 全ユーザーで起きるのか、特定ユーザーだけなのか確認する
- 直前に変更した列、式、テーブル、Botを確認する
- エディタを保存して警告表示を確認する
- 同期、再読み込み、別端末での確認を行う
- Audit HistoryやAutomation Monitorを確認する
- 修正は一項目ずつ行い、その都度テストする
最初に記録しておきたい情報
- 発生日時
- 利用者のメールアドレス
- 利用端末とブラウザ
- 操作したテーブルや画面
- 入力した値
- 表示されたエラー文
- 直前に変更した設定
利用者から「動きません」とだけ連絡を受けても、管理者は原因を特定できません。画面のスクリーンショットに加え、「どのボタンを押したか」「保存前か保存後か」「同期したか」まで記録してもらうと調査時間を短縮できます。
👑エラー画面を閉じる前に、メッセージと操作手順を残しておきましょう。再現条件が分かれば、修正箇所も見つけやすくなりますわ。
AppSheetの主なエラー一覧
AppSheetのエラーは、大きく分けると「データ構造」「キーとRef」「式」「同期」「自動化」「権限」の6種類です。表示された英文を完全に理解できなくても、どの分類に当てはまるかを判断できれば対処しやすくなります。
| 症状・メッセージ | 主な原因 | 最初に確認する場所 |
|---|---|---|
| App is not runnable | 列構造の変更、データソースへのアクセス不能 | Dataのテーブル設定 |
| Unable to find column | 列名の間違い、式の評価対象の誤り | Expression Assistant |
| Duplicate key | キー列に同じ値が存在する | キー列と元データ |
| Key column is empty | 新規行のキーが生成されていない | KeyとInitial value |
| Cannot convert value to type | 列型と保存する値が一致していない | 列のTypeと元データ |
| Column structure mismatch | スプレッドシートとAppSheetの列構成が不一致 | Regenerate structure |
| Unable to add or update row | 入力制限、権限、キー、列型の問題 | Valid Ifと更新権限 |
| Sync failed | 通信、データ、権限、式の問題 | 同期エラー詳細 |
| Duplicate request is already in progress | 同じ同期処理が重複して実行された | 同期完了を待って再実行 |
| Bot did not run | イベント条件、配備状態、プラン、権限の問題 | Automation Monitor |
| Task failed | 宛先、テンプレート、ファイル、Webhookの問題 | Audit History |
| 401 Unauthorized | データソースへの認証や権限が失われている | アカウントと接続設定 |
| No notification device token | 通知先端末がAppSheetに登録されていない | 利用者のログイン状況 |
| Action blocked by policy violation | 組織の管理ポリシーによって処理が制限された | 管理者のセキュリティ設定 |
同じエラーメッセージでも、原因が一つとは限りません。例えば「Sync failed」は通信不良だけでなく、重複キー、不正な値、アクセス権限の失効、スプレッドシートの構造変更でも発生します。メッセージだけで決めつけず、直前に行った変更とログを組み合わせて判断してください。
データソースと列構造に関するエラー
AppSheet初心者が特につまずきやすいのが、GoogleスプレッドシートやExcelの列構造を変更した後に発生するエラーです。元データの列を追加、削除、移動、改名しても、AppSheet側のテーブル構造は自動的に完全更新されない場合があります。
App is not runnableと表示される
「App is not runnable」は、現在のアプリ定義では正常に実行できない状態を示します。よくある原因は、元データの列を削除したのに、AppSheetのビュー、式、アクション、Botが削除済みの列を参照していることです。
次の順番で確認します。
- Dataから対象テーブルを開く
- 元のスプレッドシートが開けるか確認する
- 列名と列数が一致しているか確認する
- Regenerate structureを実行する
- 保存後に表示されるエラーを確認する
- 削除した列を参照する式やビューを修正する
Regenerate structureを実行すると、列型や設定が再判定されることがあります。実行前にKey、Label、Type、Initial value、App formula、Valid Ifなどの設定を記録しておくと安全です。
Column structure mismatchと表示される
元データとAppSheetが認識している列構造が一致していない状態です。スプレッドシートで列を追加しただけでは、AppSheetのフォームに新しい項目が表示されないことがあります。
元データの見出し行を整えたうえで、対象テーブルの列構造を再生成します。見出し行の上にタイトル、画像、結合セル、説明文などがあると、列名を正しく認識できない場合があります。
列名を変更した後にエラーが増えた
業務で運用中のアプリでは、列名の変更が広い範囲に影響します。ビュー、Slice、Format rule、Action、Bot、テンプレート、仮想列などが古い列名を参照している可能性があるためです。
表示名だけを変えたい場合は、元データの列名ではなく、AppSheet側のDisplay nameを利用する方法があります。内部で参照する列名を維持できるため、既存の式への影響を減らせます。
401 Unauthorizedと表示される
AppSheetがGoogleスプレッドシートや外部データソースへアクセスできない状態です。ファイルの所有者変更、共有解除、アカウントの認証切れ、組織のポリシー変更などが考えられます。
- アプリ所有者が元ファイルを開けるか確認する
- データソースの接続アカウントを確認する
- AppSheetから一度ログアウトして再ログインする
- 共有ドライブや組織外共有の制限を確認する
- ファイルが削除、移動されていないか確認する
会社のGoogle Workspaceを利用している場合は、利用者だけでなく管理者側の設定変更が影響していることもあります。本人の操作だけで解決しない場合は、社内管理者へ確認してください。
👑元データの列を気軽に削除すると、アプリ全体に影響が広がりますの。運用開始後は、変更前のバックアップを残しておくと安心ですわ。
キーとRefに関するエラー
AppSheetでは、各行を一意に識別するためにKey列を使用します。キー設計に問題があると、別の行が更新されたり、同期時にデータが上書きされたりするため、見た目以上に深刻なトラブルへつながります。
Duplicate keyが発生する
キー列に同じ値が2件以上存在すると、AppSheetは行を正しく区別できません。社員番号、商品コード、日付などをキーにしている場合、重複や空欄がないか確認してください。
新規登録するデータのキーには、Initial valueへUNIQUEID()を設定する方法が一般的です。App formulaではなくInitial valueを使用することで、行の作成時に値を生成し、その後も同じキーを維持できます。
RowNumberをキーにしている
行番号は、行の追加、削除、並べ替えによって変わる可能性があります。運用中のテーブルでRowNumberをキーにすると、意図しない行が更新される原因になります。
専用のID列を追加し、既存行にも重複しない値を設定したうえで、その列をKeyに変更してください。切り替え前には、Ref列や関連テーブルへの影響も確認します。
Key column is emptyと表示される
新しい行を追加するときに、キー値が作成されていない状態です。Key列のInitial valueが空欄になっていないか、Editableの設定によって値が消されていないかを確認します。
APIやBotから行を追加する場合は、キー値を明示的に渡すか、Initial valueで生成できる設定が必要です。
Refの候補が表示されない
Ref列は、参照先テーブルのキー値を保存します。参照先に同じ名前の商品があっても、実際に保存されるのはLabelではなくKeyです。
- Ref列の参照先テーブルが正しいか
- 参照先テーブルのKeyに空欄や重複がないか
- Valid Ifで候補を絞り込みすぎていないか
- Security filterで参照先の行が除外されていないか
- Sliceの条件で必要な行が消えていないか
Refエラーを防ぐには、画面に表示する名称と内部で使うIDを分ける設計が有効です。商品名をLabel、商品IDをKeyにすると、同名商品や商品名変更にも対応しやすくなります。
式と関数に関するエラー
AppSheetの式はExcelやGoogleスプレッドシートの関数と似ていますが、行の評価範囲やデータ型の扱いが異なります。式そのものの入力ミスだけでなく、参照している列のTypeが原因になることもあります。
Unable to find columnと表示される
指定した列が現在の評価対象に存在しないときに表示されます。単純な列名の誤入力だけでなく、SELECTやFILTERなどの条件式で、別テーブルの列を直接参照した場合にも発生します。
例えば、外側の行にある値を条件式で使う場合は、[_THISROW].[列名]のように現在行を明示する必要があります。
誤りやすい考え方
SELECTの条件内にある[担当者]は、基本的に検索対象テーブルの各行として評価されます。
外側のフォームや現在行の[担当者]を使いたい場合は、[_THISROW].[担当者]として区別します。
式の結果と列型が一致しない
Text列にListを返す式を設定したり、Yes/Noを求めるShow Ifに文字列を返したりすると、型の不一致が発生します。
| 設定場所 | 求められる主な結果 | よくある間違い |
|---|---|---|
| Show If | TRUEまたはFALSE | メールアドレスや文字列をそのまま返す |
| Valid If | TRUE・FALSEまたは候補リスト | 列型と異なる候補を返す |
| Text列のApp formula | 単一の文字列 | SELECTでListを返す |
| Ref列 | 参照先のキー値 | 表示名やLabelを返す |
| EnumList列 | 複数値のList | 単一値とListを条件分岐で混在させる |
式を直すときは、Expression Assistantに表示される結果型を確認してください。列のTypeを無理に変更するのではなく、「その設定場所が何を返すべきか」から考えると修正しやすくなります。
SELECTで1件だけ取得したいのにエラーになる
SELECTは複数件を含むListを返します。TextやNumberなど単一値を求める列へそのまま設定すると、型が合いません。
該当行が必ず1件に決まる場合はANYを組み合わせる方法があります。ただし、候補が複数存在すると、どの値が選ばれるか分かりにくくなります。業務データでは、キーや条件を見直して1件に絞れる構造を作ることが先です。
Invalid dereferenceが発生する
[商品ID].[単価]のような参照は、左側の列がRef型であることが前提です。[商品ID]がText型の場合、参照先の行を特定できません。
列のTypeをRefに変更し、Source tableに正しい参照先を設定します。ただし、既存データに保存されている値が参照先のKeyと一致していない場合は、型を変更するだけでは解決しません。
Valid Ifで入力を保存できない
Valid Ifは入力値を制限する設定です。条件を厳しくしすぎると、既存データの編集やBotによる更新まで拒否されることがあります。
- 新規登録時と編集時で条件を分ける
- 空欄を許可する列では空欄条件も考慮する
- EnumやRefでは候補値の型を一致させる
- エラー文を利用者が理解できる日本語にする
- Security filterとValid Ifの役割を混同しない
式の警告には、括弧の不足、カンマの不足、評価されない余分な文字などもあります。自動修正が表示されても、そのまま適用するのではなく、修正後の結果型と条件を確認してください。
👑式が緑色になれば、すべて正しいと思っていましたわ。
🤖構文が正しくても、業務上の結果が正しいとは限りません。正常データ、空欄、例外データでテストする必要があります。
👑保存できるかだけでなく、間違った値を返さないかも確認するのですね。
🤖その通りです。特にSELECTやANYは、候補が0件、1件、複数件の場合を分けて確認しましょう。
同期とオフラインに関するエラー
同期エラーが発生すると、利用者が入力したデータが保存されていないように見えたり、別の端末へ反映されなかったりします。ただし、同期の失敗と入力データの消失は同じではありません。端末内に変更が残っている場合は、アプリの削除やキャッシュ消去を急いで行わないでください。
Sync failedと表示される
最初に通信環境を確認し、安定した回線で再度同期します。それでも失敗する場合は、エラーメッセージの詳細を開き、対象テーブルや行を特定します。
- キー値の重複や空欄
- 必須列の未入力
- 列型に合わない値
- Valid Ifに反する値
- データソースへのアクセス権限
- 元データの列構造変更
- 同じ行を複数端末で編集した競合
Duplicate request is already in progressと表示される
同期ボタンを連続して押した場合や、同じ同期要求が処理中の場合に発生します。同期中に何度も操作せず、処理完了を待ってから再試行します。
頻繁に発生する場合は、同期時間が長くなっていないか確認してください。仮想列、大量のSELECT、スプレッドシート関数、大量画像、不要なテーブルなどが同期処理を重くしている可能性があります。
入力した内容がスプレッドシートに反映されない
同期が完了しているか、入力先のテーブルが正しいかを確認します。スプレッドシート内に大量の空行があると、かなり下の行へ追加され、見つけられないこともあります。
また、Sliceを表示している場合でも、実際の保存先はSliceの元テーブルです。画面名だけで判断せず、ViewのFor this dataで保存先を確認してください。
同期が遅い
同期時間を改善するには、端末や回線だけでなく、アプリが同期時に読み込むデータ量と計算量を減らします。
- 不要なテーブルをアプリから外す
- Security filterで端末へ送る行を絞る
- 負荷の高い仮想列を減らす
- 同じSELECT計算を複数列で繰り返さない
- スプレッドシート関数の範囲を必要最小限にする
- 画像サイズを適切に圧縮する
- 自動同期の設定を業務に合わせて調整する
Sliceは画面上の表示を絞る機能であり、端末へ転送されるデータ量を減らす目的ではSecurity filterを検討します。ただし、設定を誤ると必要なデータまで取得できなくなるため、複数ユーザーで十分にテストしてください。
👑同期に失敗した直後にアプリを削除すると、端末内に残っていた未送信データまで失う恐れがありますの。まずエラー内容を確認しましょう。
BotとAutomationに関するエラー
Botが動かない場合は、Bot本体だけでなく、Event、Process、Step、Taskのどこまで実行されたかを確認します。画面上の設定を眺めるより、Automation MonitorとAudit Historyを確認したほうが早く原因を特定できます。
Botがまったく実行されない
- Botが有効になっているか
- Eventの対象テーブルが正しいか
- 追加、更新、削除のイベント種別が合っているか
- ConditionがFALSEになっていないか
- アプリ経由の変更として認識されているか
- スケジュール実行に必要な配備状態やプランを満たしているか
スプレッドシートを直接編集した変更は、通常のアプリ内データ変更イベントとして処理されない場合があります。どこからデータが変更される業務なのかを整理し、イベント方式を選択してください。
テストでは動くのに利用者へメールが届かない
アプリがテスト状態のときは、メールや通知の送信先がアプリ作成者に限定されることがあります。Automation Monitorで処理が成功している場合は、配備状態と送信先を確認します。
宛先メールアドレスを式で生成している場合は、空欄、余分な空白、無効な形式が含まれていないかも確認してください。
Task failedと表示される
Taskが失敗した場合は、Audit Historyの詳細から、失敗したStepとエラーメッセージを確認します。
| Taskの種類 | 主な確認項目 |
|---|---|
| メール送信 | 宛先、件名、本文テンプレート、添付ファイル |
| ファイル作成 | 保存先、ファイル名、テンプレートへのアクセス権 |
| Webhook | URL、認証、HTTPメソッド、本文形式、応答コード |
| データ更新 | 対象行、キー、更新権限、Valid If |
| 通知 | 利用者のログイン、端末登録、通知許可 |
通知先にDevice Tokenがない
プッシュ通知を受け取るには、対象ユーザーが対応端末でAppSheetへログインし、アプリを利用している必要があります。ブラウザだけで利用している人や、通知権限を許可していない人には送れない場合があります。
Action blocked by policy violationと表示される
組織の管理者が設定したセキュリティポリシーによって、メール送信、外部接続、データ共有などが制限されている可能性があります。アプリ作成者だけでは解除できないため、エラー文、アプリ名、実行日時、対象処理を添えて管理者へ相談してください。
Audit Historyでは、同期、データ追加、更新、削除、Bot、APIなどの実行履歴を確認できます。ログの保存期間や利用できる監視機能は契約内容によって異なるため、最新の仕様は公式サイトで確認してください。
画面、フォーム、アクションが動かないときの対処法
ビューが表示されない
ViewのPositionがrefになっている場合、通常のメニューには表示されません。また、Show ifがFALSEになっている、参照するSliceに行がない、利用者ごとの条件に一致していない可能性もあります。
- ViewのPosition
- ViewのShow if
- For this dataに設定したテーブルやSlice
- USEREMAILを使った条件
- Security filterによるデータ除外
アクションボタンが表示されない
Only if this condition is trueがFALSEになっていないか、対象ビューでProminenceが適切に設定されているかを確認します。更新系アクションでは、テーブルが読み取り専用になっていると表示されない場合があります。
フォームを保存できない
赤く表示されている列だけでなく、非表示列、必須列、キー列、App formula、Valid Ifも確認します。Show Ifで非表示にした列でも、Required設定との組み合わせによって保存を妨げることがあります。
利用者によって結果が異なる
USEREMAIL、Security filter、Slice、Show if、更新権限が利用者ごとに異なる可能性があります。管理者アカウントだけでテストすると、一般利用者の問題を見逃します。
管理者、一般社員、閲覧専用など、実際の権限ごとにテストアカウントを用意してください。実データを使う前に、テスト用のテーブルとアプリコピーで確認すると安全です。
👑管理者には見えているのに、現場の方には見えないこともありますの。権限別のテストは、公開前に欠かせませんわ。
エラーを再発させない運用ルール
AppSheetのエラー対策は、発生後の修正だけでは不十分です。誰がどの設定を変更したか分からない運用では、同じ問題が繰り返されます。
変更履歴を残す
変更日、変更者、対象機能、変更理由、テスト結果を記録します。大がかりな管理表でなくても、共有スプレッドシートに残すだけで原因調査が楽になります。
本番アプリを直接変更しない
業務で利用中のアプリに大きな変更を加える場合は、アプリをコピーして検証します。列削除、キー変更、Security filter、Bot条件の変更は、特に影響範囲が広いため注意が必要です。
テストデータを3種類用意する
- 通常どおり入力された正常データ
- 空欄や0を含む境界データ
- 重複や形式違いを含む異常データ
正常データだけでテストすると、実際の運用で発生する空欄、入力ミス、同時編集を見逃します。
AIに任せてよい部分と人間が確認する部分を分ける
生成AIは、英文エラーの要約、式の括弧確認、調査項目の整理、テストケース作成に役立ちます。一方で、実際の列型、権限、キーの重複、ログの実行結果は人間がAppSheet上で確認しなければなりません。
機密情報を含むログやメールアドレスをAIへ入力する場合は、会社の情報管理ルールを確認し、必要に応じて匿名化してください。
自分で直すべき範囲を判断する
列名の入力ミスや単純な式の修正は、バックアップを取ったうえで対応できます。一方、次のような問題は、管理者や経験者への相談が適しています。
- 本番データのキーを変更する
- 大量の重複データを修正する
- 組織ポリシーによるアクセス拒否
- 複数テーブルにまたがるRefの再設計
- APIやWebhookの認証エラー
- 未同期データが残った端末の初期化
AppSheetエラー調査チェックリスト
- エラー画面と全文を保存したか
- 同じ操作で再現できるか
- 特定ユーザーだけの問題か確認したか
- 直前の変更内容を確認したか
- 元データの列名と列数を確認したか
- Key列に空欄や重複がないか確認したか
- 列のTypeと入力値が一致しているか
- 式が返す値の型を確認したか
- 同期エラーの詳細を開いたか
- Automation Monitorを確認したか
- Audit Historyを確認したか
- 一項目ずつ修正して再テストしたか
- 管理者以外のアカウントでも確認したか
- 本番反映前にバックアップを作成したか
よくある質問
AppSheetの赤いエラーはすべて直す必要がありますか？
アプリを実行できなくするエラーは修正が必要です。警告は直ちに停止原因にならない場合もありますが、将来の不具合や性能低下につながる可能性があるため、内容を確認してください。
エラー文が英語で意味が分かりません
エラー全文をコピーし、対象テーブル、列、操作と一緒に整理してください。単語だけを翻訳するより、「保存時」「同期時」「Bot実行時」など発生場面を含めて判断すると原因を絞りやすくなります。
Regenerate structureを押せばエラーは直りますか？
元データと列構造の不一致には有効ですが、キーの重複、式の間違い、権限エラーまでは直りません。また、列型が再判定される場合があるため、実行後に各列設定を確認してください。
同期エラーが出たらアプリを再インストールしてもよいですか？
未同期の入力が端末に残っている可能性があるため、すぐに再インストールするのは避けてください。エラー詳細と通信環境を確認し、必要に応じて管理者へ相談します。
Botが成功と表示されるのにメールが届きません
テスト状態、送信先、迷惑メール、宛先を作る式を確認してください。Botの処理成功と、受信者のメールボックスへの到達は分けて調査します。
式が正しい表示なのに期待した結果になりません
構文が正しくても、評価対象の行や返り値の型が想定と異なる場合があります。空欄、1件、複数件など、条件の異なるテストデータで結果を確認してください。
AppSheetのエラーをChatGPTに相談してもよいですか？
エラーの意味や確認手順の整理には利用できます。ただし、顧客名、メールアドレス、APIキー、社内URLなどは伏せ、最終的な設定変更はAppSheetの実画面と公式情報を確認して判断してください。
エラーが直らない場合は何を伝えて相談すればよいですか？
アプリ名、発生日時、利用者、操作手順、エラー全文、対象テーブル、直前の変更、再現性、試した対処法をまとめると、管理者やサポートが調査しやすくなります。
おすすめAIツール
AppSheetの英文エラーや長いログを整理するときは、ChatGPTなどの生成AIを補助的に利用できます。エラー文から考えられる原因を分類したり、確認手順をチェックリスト化したり、複雑な式を読みやすく分解したりする用途に向いています。
ただし、AIへエラー文だけを渡すと、実際のテーブル構造を知らないまま一般的な回答を返すことがあります。利用する際は、列のType、式を設定した場所、期待する結果、実際の結果を個人情報を除いて伝えてください。
AIの提案をそのまま本番アプリへ反映せず、コピーしたアプリやテストデータで確認することも欠かせません。権限設定、Security filter、キー変更など、データ消失につながる可能性がある修正は人間が慎重に判断します。
関連記事
まとめ
- AppSheetエラーは、データ構造、キー、式、同期、自動化、権限に分けて調査する
- 列構造を変更した後は、元データを確認してからRegenerate structureを実行する
- 同期やBotの問題は、エラー詳細、Automation Monitor、Audit Historyで実行結果を確認する
- 修正前にバックアップを取り、一項目ずつ変更して権限別にテストする
AppSheetのエラーは、表示された英文だけを見て判断するより、「どの操作で」「どのテーブルに」「どのユーザーが」問題を起こしたのかを整理したほうが早く解決できます。まずはエラー画面を記録し、直前の変更、キー、列型、式、ログの順に確認してください。焦って複数の設定を変更せず、小さく修正してテストすることが、業務データを守りながら復旧する近道です。
