AppSheetのBot（Automation）完全ガイド｜基本設定から実践例まで解説

AppSheetで申請アプリや在庫管理アプリを作ったものの、「登録後のメール送信まで手作業になっている」「在庫が減っても担当者が気づけない」「毎日の確認作業がなくならない」と悩んでいないでしょうか。こうした定型業務を自動化できる機能が、AppSheetのBotを中心としたAutomationです。Botは、データの追加や更新、指定時刻などをきっかけに、通知、メール送信、データ更新、ファイル作成といった処理を自動実行できます。ただし、条件式や対象行の設計が曖昧なまま設定すると、処理されない、同じメールが何度も届くといった問題も起こります。基本構造から設定手順、実務例、失敗を防ぐ考え方まで、初心者にもわかる形で整理します。

AppSheetのBotとは

AppSheetのBotとは、アプリ内で特定の出来事が発生したときに、あらかじめ設定した処理を自動実行する仕組みです。たとえば、経費申請が登録されたら上司へメールを送る、在庫数が発注点を下回ったら担当者へ通知する、毎朝未提出の日報を抽出するといった業務に使えます。

BotはAutomationを構成する中心的な機能です。単独で処理を行うのではなく、「いつ動かすか」と「何を実行するか」を組み合わせて自動化を作ります。

Botを構成する主な要素

要素	役割	具体例
Bot	自動化全体を管理する	経費申請の承認依頼を自動送信する
Event	処理を開始する条件を決める	申請データが追加されたとき
Process	実行する処理の流れを決める	条件判定後にメールを送信する
Step	プロセス内の処理単位を作る	タスク実行、条件分岐、待機
Task	具体的な作業を実行する	メール送信、通知、ファイル作成
Action	アプリのデータを変更する	処理済みフラグを更新する

公式ヘルプでも、EventがBotを開始するきっかけ、Processが実行するステップの集合、Taskがメール送信などの具体的な処理として整理されています。Processには条件分岐、待機、別プロセスの呼び出し、データアクションなども設定できます。

なお、Botは基本的に作成した1つのAppSheetアプリ内で動作します。同じスプレッドシートを利用していても、別アプリのBotを直接動かす仕組みではありません。複数アプリにまたがる業務では、共有テーブル、Apps Script、外部サービスなどを含めた設計が必要です。

Botを作る前に整理すること

Automationの設定画面を開く前に、自動化したい業務を紙や表に書き出しておくと失敗が減ります。最初から画面上で試行錯誤すると、イベント条件とタスク条件が重なり、どこで処理が止まっているのかわからなくなりがちです。

自動化の設計に必要な5項目

• 何をきっかけに処理を開始するか
• どのテーブルのどの行を対象にするか
• どの条件を満たしたときだけ実行するか
• 誰に対して何を通知または更新するか
• 実行済みかどうかをどこに記録するか

たとえば「申請が登録されたら上司へメールを送る」という要望だけでは不十分です。新規登録時だけなのか、修正時にも送るのか、上司のメールアドレスをどこから取得するのか、送信後に処理済みフラグを付けるのかまで決めます。

元データに用意したい列

列名の例	用途
申請ID	各行を一意に識別するキー
登録日時	処理が発生した時刻を確認する
申請者メール	申請者への通知先に使う
承認者メール	承認依頼の送信先に使う
ステータス	申請中、承認、差し戻しなどを判定する
通知済み	同じ通知の重複送信を防ぐ
通知日時	処理履歴を確認する

特に「通知済み」「処理済み」「最終処理日時」といった管理列は、実務で安定運用するために役立ちます。Botを動かすだけでなく、実行結果をデータとして残す設計が大切です。

AppSheetでBotを設定する基本手順

基本的なBotは、Event、Process、Taskの順に設定すると理解しやすくなります。画面構成や名称はアップデートによって変わる可能性がありますが、設定の考え方は共通しています。

Botを作成する流れ

1. AppSheetエディタで対象アプリを開く
2. Automationの設定画面を開く
3. 新しいBotを作成してわかりやすい名前を付ける
4. Eventで対象テーブルと開始条件を設定する
5. Processを作成して実行順序を決める
6. TaskまたはActionで具体的な処理を設定する
7. 保存後にテストデータを登録して実行結果を確認する

Eventで処理のきっかけを決める

Eventには、データの追加、更新、削除などをきっかけにするデータ変更イベントと、指定した日時に動かすスケジュールイベントがあります。現在のAppSheetでは、アプリ変更、AppSheetデータベース変更、スケジュール、Googleフォームの回答など、複数のイベントソースが用意されています。

初心者が最初に試すなら、特定テーブルへの新規追加をきっかけにする設定がわかりやすいでしょう。更新イベントは、Bot自身が行った更新によって再び条件を満たし、処理が繰り返される可能性があるため注意が必要です。

条件式で実行対象を絞り込む

すべての登録や更新でBotを動かす必要がない場合は、EventまたはProcessに条件式を設定します。たとえば、ステータスが「承認待ち」で、金額が10万円以上の場合だけ実行するなら、次のような考え方になります。

AND([ステータス]=”承認待ち”,[金額]>=100000)

最初は条件を1つだけにして動作確認し、正常に実行できてから条件を追加する方法が安全です。複雑な式を最初から入れると、Botの設定ミスなのか、条件式がFALSEになっているのかを判断しにくくなります。

Processで処理の順番を設定する

Processには、Taskの実行、データアクションの実行、条件分岐、待機などを追加できます。たとえば承認依頼では、次の順序が考えられます。

1. 承認者メールが入力されているか確認する
2. 承認者へ申請内容をメール送信する
3. 通知済み列をTRUEに更新する
4. 通知日時に現在時刻を記録する

先に通知済みへ更新してからメールを送ると、メール送信が失敗しても処理済みとして残る場合があります。何を成功とみなすかを決め、処理順序を組み立ててください。

Taskで実行内容を設定する

メール送信タスクでは、送信先、件名、本文などを設定します。送信先を固定アドレスにする方法だけでなく、対象行の列を参照して動的に変更することも可能です。

• 送信先の例：[承認者メール]
• 件名の例：経費申請の承認依頼
• 本文の例：申請者、申請日、金額、内容、確認用リンク

本文に必要な情報を詰め込みすぎるより、判断に必要な項目とアプリへの導線を簡潔にまとめた方が、実務では確認しやすくなります。

実践例1：申請登録後に承認依頼メールを送る

経費申請、休暇申請、購入申請などでは、申請データの登録後に承認者へ連絡する作業を自動化できます。

設定例

設定項目	内容
Event	申請テーブルに新しい行が追加されたとき
条件	ステータスが承認待ち、承認者メールが空欄ではない
Process	承認依頼メールを送り、通知情報を更新する
Task	承認者メール列の宛先へ申請内容を送信する
Action	通知済みと通知日時を更新する

実務での改善ポイント

承認者メールを申請テーブルへ直接入力させると、入力ミスや表記揺れが起こります。社員マスタに社員メール、部署、承認者メールを登録し、申請者を選ぶと承認者情報が参照される仕組みにすると管理しやすくなります。

また、申請内容を修正するたびに承認依頼が再送される設定では、承認者へ同じメールが何度も届きます。新規登録時のみ動かすか、通知済みがFALSEの場合だけ送信する条件を加えてください。

実践例2：在庫数が発注点を下回ったら通知する

在庫管理アプリでは、現在庫が発注点以下になった商品だけを担当者へ通知できます。目視で在庫一覧を確認する作業を減らせる一方、入出庫のたびに通知すると大量のメールが発生するため、通知条件の設計が欠かせません。

基本となる条件

AND([現在庫]<=[発注点],[発注通知済み]=FALSE)

この条件では、現在庫が発注点以下で、まだ通知していない商品だけが対象になります。通知後に発注通知済みをTRUEへ更新します。

再通知の仕組みも決める

商品が入荷して在庫が回復したら、発注通知済みをFALSEへ戻す処理も必要です。これがないと、次回再び在庫が減っても通知されません。

• 在庫が発注点以下になったら通知済みをTRUEにする
• 入荷後に在庫が発注点を上回ったらFALSEへ戻す
• 緊急度が高い商品だけ即時通知する
• 通常商品は1日1回の一覧メールにまとめる

即時通知と定期集計を使い分けることで、担当者が通知に慣れて見落とす問題を防げます。

実践例3：毎朝、未提出の日報を確認する

スケジュールイベントを使うと、毎日や毎週の決まった時刻にBotを実行できます。日報の未提出確認、契約期限の通知、点検予定日のリマインドなどに向いています。

設定の考え方

1. スケジュールイベントを毎営業日の朝に設定する
2. 対象日の日報が存在しない社員を抽出する
3. 未提出者本人または管理者へ通知する
4. 休日や休暇者を対象外にする
5. 実行日時と対象件数を履歴へ記録する

スケジュール設定ではタイムゾーンを確認してください。海外拠点の設定やアプリ所有者の環境によっては、想定した日本時間とずれる可能性があります。また、無料利用やプロトタイプ状態では、メール送信やスケジュールイベントなど一部機能が想定どおり実行されない場合があります。利用中のプランで対応している機能を公式情報で確認してください。

Botで実行できる代表的な処理

処理	使用例	注意点
メール送信	承認依頼、期限通知、日次報告	宛先の空欄と重複送信を確認する
プッシュ通知	担当者への緊急連絡	利用者の端末や通知設定に影響される
データ更新	ステータス、処理日時、通知済みの更新	更新によるBotの再実行に注意する
ファイル作成	見積書、請求書、報告書のPDF作成	テンプレートと保存先を管理する
条件分岐	金額やステータスによる処理変更	条件が複雑になるほどテストが必要になる
待機処理	一定時間後の再通知	長期間の待機や大量実行を避ける
Apps Script連携	複雑な集計やGoogleサービスとの連携	スクリプト側の権限と実行制限も確認する

最初から多機能なBotを作る必要はありません。メール送信だけで始め、安定してからデータ更新、条件分岐、ファイル作成を追加すると管理しやすくなります。

Botが動かないときの確認ポイント

Botのトラブルは、Event、条件式、対象行、Task、契約プランのどこで止まっているかを順番に切り分けることが基本です。

データを登録しても実行されない

• Botが有効になっているか確認する
• Eventの対象テーブルが正しいか確認する
• 追加、更新、削除の選択が目的と合っているか確認する
• 条件式がTRUEになっているか確認する
• アプリの同期が完了しているか確認する
• 利用プランで対象機能が実行可能か確認する

同じメールが何度も送信される

Botがデータを更新した結果、その更新が新たなEventとして判定され、再び処理が始まっている可能性があります。通知済み列を追加し、「通知済みがFALSEの場合だけ実行する」と設定すると重複を防ぎやすくなります。

宛先が空欄になる

Taskが参照しているメール列と、Eventの対象行が一致しているか確認します。親テーブルと子テーブルをまたいで参照する場合は、Ref列の関係や参照式も見直してください。

条件式は正しいのに対象にならない

数値に見える値がText型になっている、日付とDateTimeを比較している、空欄と0を混同しているといったデータ型の違いが原因になることがあります。式だけでなく、Data設定の列型も確認します。

実行履歴を確認する

Automation Monitorでは、Botが成功したか、エラーになったか、処理中かを確認できます。動作しないときは設定を何度も変更する前に、実行履歴とエラーメッセージを確認してください。

安定運用するための設計ポイント

Botの役割を小さく分ける

1つのBotに通知、PDF作成、データ更新、複数部署への連絡を詰め込むと、失敗した箇所を見つけにくくなります。処理の目的が異なる場合はBotやProcessを分け、名前から役割がわかるようにします。

• 申請登録時_承認依頼送信
• 申請承認時_申請者通知
• 毎朝_未処理申請確認
• 月末_申請一覧ファイル作成

処理済みを記録する

自動化では、「処理したかどうか」を人間が確認できる状態にします。通知済み、最終実行日時、エラー内容、処理担当Botなどを保存すると、問い合わせ対応や再実行がしやすくなります。

大量データを一度に処理しない

対象行を絞らずに全データを毎回処理すると、実行時間が長くなり、外部サービスの制限にも影響します。条件やSliceを使って未処理行だけを対象にしてください。

AppSheetにはAutomationの実行数や処理時間などの上限があります。公式情報では、スケジュールイベントの最大実行時間は5分、アプリイベントは2分、展開済みアプリのFor Each Row in Tableは最大1万行、Botの実行データの保存期間は最大55日とされています。上限は変更される可能性があるため、大規模運用では最新情報を確認してください。

人間による確認を残す

金額の大きい支払い、顧客への正式文書、契約に関わる処理まで完全自動化すると、誤登録の影響が大きくなります。データ収集や担当者への連絡はBotに任せ、最終承認や外部送信は人間が確認する設計も有効です。

AppSheetのBotが向いている業務

• 同じ条件で繰り返す連絡やデータ更新
• 入力後の転記や通知に時間がかかっている業務
• 処理条件をステータスや数値で明確に表せる業務
• 担当者による対応漏れを減らしたい業務
• 少人数の部署から段階的に改善したい業務

Botが向いていないケース

• 担当者の経験や状況判断が大部分を占める業務
• 元データの入力ルールが統一されていない業務
• 例外処理が多く、条件を明確に定義できない業務
• 大量データを短時間で一括処理する必要がある業務
• 複数の外部システムへ複雑な連携を行う業務

自動化に向かない業務を無理にBotへ置き換えると、設定や修正にかかる時間が手作業を上回ることがあります。発生頻度が高く、判断基準が明確で、失敗したときに確認できる業務から始めてください。

導入時におすすめの進め方

1. 毎日または毎週繰り返している作業を洗い出す
2. 1回あたりの時間と発生回数を記録する
3. 条件が明確な作業を1つ選ぶ
4. テスト用アプリまたは少人数でBotを試す
5. 実行履歴と処理済み情報を確認する
6. 問題がなければ対象者や機能を広げる

最初の題材には、「登録されたら自分宛てに確認メールを送る」程度の小さな自動化が適しています。いきなり全社の承認フローを置き換えるより、Botの動作と履歴確認に慣れてから範囲を広げる方が安全です。

よくある質問

AppSheetのBotとAutomationは何が違いますか？

Automationは自動化機能全体の名称で、Botはその中でEventとProcessを組み合わせて実行する中心的な仕組みです。

プログラミングができなくてもBotを作れますか？

基本的な通知やメール送信は画面操作で設定できます。ただし、実行条件を細かく設定する場合は、AppSheetの式を少しずつ覚える必要があります。

Googleスプレッドシートを直接編集してもBotは動きますか？

データソースやイベントの設定によって動作が異なります。アプリ経由の変更と外部からの変更を同じものと考えず、実際の更新方法でテストしてください。

Botが実行されたか確認する方法はありますか？

Automation Monitorで実行履歴を確認できます。成功、エラー、処理中などの状態を確認し、エラーがある場合は対象ステップを調べます。

同じメールが複数回送られるのはなぜですか？

更新イベントが繰り返し発生している可能性があります。通知済み列を用意し、未通知の行だけを対象にする条件を追加してください。

BotからPDFを作成できますか？

テンプレートを使ってPDFなどのファイルを作成できます。レイアウト、保存先、ファイル名の重複、作成数の上限を事前に確認してください。

無料プランでもBotを利用できますか？

設定や試作ができても、メール送信やスケジュールイベントなどが本番と同じように実行されない場合があります。利用目的に必要な機能が対象プランに含まれるか、最新の公式情報を確認してください。

おすすめAIツール

Botの条件式、メール本文、テスト項目を整理するときは、ChatGPTやGeminiなどの生成AIも補助的に使えます。たとえば、業務手順を文章で伝えて自動化の流れを整理したり、条件式のたたき台を作ったり、想定されるエラーケースを洗い出したりできます。

ただし、AIが作成した条件式を確認せずに本番へ設定するのは避けてください。列名、データ型、Ref関係、アプリ固有の設定までは正確に把握できないことがあります。設計案の作成はAIに任せ、実データでのテストと最終判断は人間が行う使い分けが適しています。

関連記事

• AppSheetで在庫管理アプリを作る方法｜初心者向けに手順を解説

まとめ

• BotはEvent、Process、Taskを組み合わせて定型業務を自動化する仕組み
• 設定前に、きっかけ、対象行、実行条件、処理内容、実行済みの記録方法を整理する
• 通知済み列や処理日時を用意すると、重複実行や確認漏れを防ぎやすい
• 小さな自動化からテストし、Automation Monitorで履歴を確認しながら範囲を広げる

AppSheetのBotは、単にメールを自動送信する機能ではありません。入力後の確認、担当者への連絡、ステータス更新、定期的なチェックまでを一つの業務フローとして整えられます。最初は処理を増やしすぎず、1つのEventと1つのTaskから試してください。正常に動作する小さなBotを積み重ねることが、安定した業務自動化への近道です。