「重要な問い合わせメールが届いたら教えてほしい」
「Slackに障害報告が投稿されたら、確認事項を整理してほしい」
こうした業務は、毎朝9時に動く定時タスクよりも、出来事が起きた時点で動く仕組みの方が合っています。ChatGPTのイベント連動タスクは、対応するGmail・Slack・GitHubの更新をきっかけに、Workで決めた処理を実行する機能です。
ただし、最初からメール送信やデータ更新まで自動化するのはおすすめしません。まずは「見つける・整理する・通知する」に限定し、人が確認してから次へ進む設計にすると、誤作動の影響を抑えやすくなります。
この記事では、AI初心者でも設定内容を確認できるよう、イベント連動タスクを3つの部品に分けて説明します。
イベント連動タスクと定時タスクの違い
定時タスクは「毎週月曜の9時」「毎日夕方」のように、時間を起点に動きます。一方、イベント連動タスクは「新しいメールが届いた」「指定チャンネルに投稿された」「プルリクエストに動きがあった」といった変化を起点にします。
| 種類 | 起点 | 向いている業務 |
|---|---|---|
| 定時タスク | 日時・曜日 | 週報、定例チェック、毎朝の情報収集 |
| 監視タスク | 条件の変化 | 価格、空き状況、更新有無の確認 |
| イベント連動タスク | Gmail・Slack・GitHubの対応イベント | 問い合わせ整理、社内投稿の要約、PR更新の通知 |
イベント連動タスクはWorkで利用し、対象プランやワークスペース設定によって利用可否が変わります。FreeとGoでは作成できません。管理されたワークスペースでは、管理者による機能・アプリの許可も必要になる場合があります。
設定はTrigger・Condition・Promptに分ける
設定内容は、次の3つを混ぜずに考えると整理しやすくなります。
1.
Trigger：何が起きたら確認するか
- Gmailに新着メールが届いた
- Slackの指定チャンネルに新しい投稿があった
- GitHubの対象リポジトリでプルリクエストに動きがあった
Triggerは入口です。ここでは対象を広げすぎず、監視するアカウント、チャンネル、リポジトリを限定します。Slackでは監視対象チャンネルにChatGPTを追加する必要があります。
2.
Condition：どの場合だけ処理するか
- 件名に「資料請求」を含む
- 送信元が指定ドメイン
- 投稿に「障害」「停止」「エラー」のいずれかを含む
- 指定ラベルのプルリクエストだけを対象にする
Conditionがないと、関係のない更新まで拾い、通知が増えます。最初は条件を狭くし、取りこぼしを確認しながら広げます。
3.
Prompt：見つけた後に何をするか
- 本文から会社名、問い合わせ種別、希望時期を抽出する
- 事実と未確認事項を分けて要約する
- 担当者が確認すべき項目を箇条書きにする
- 返信文は送信せず、下書きだけ作る
「送る」「更新する」など外部状態を変える処理は、承認が必要になり、タスクが一時停止する場合があります。初回は結果の整理までにし、担当者が妥当性を確認できる形にします。
Gmailで問い合わせメールを整理する例
CRM担当者なら、次のような設計から始められます。
Trigger:
Gmailに新しいメールが届いたとき
Condition:
件名に「資料請求」または「お問い合わせ」を含む
Prompt:
本文から次の項目を抽出してください。
・会社名
・氏名
・問い合わせ種別
・希望時期
・担当者が追加確認すべき点
推測で空欄を埋めず、書かれていない項目は「未記載」としてください。
返信や外部システムへの登録は行わず、確認用の要約だけを作成してください。個人情報を扱うため、社内ルール、接続権限、結果の保存先を先に確認します。メール本文をタスク名へ入れる必要はありません。
Slackで顧客の声を週報候補にする例
Slackでは、問い合わせ共有チャンネルなどの投稿を起点にできます。
Trigger:
指定したSlackチャンネルに新しい投稿があったとき
Condition:
投稿に「要望」「不具合」「解約理由」のいずれかを含む
Prompt:
投稿内容を、事実・顧客要望・担当者の仮説に分けて整理してください。
元投稿にない原因は断定しないでください。
外部送信やチャンネルへの投稿はせず、確認用メモを作成してください。同じ話題が連続して投稿される場合は、1件ごとに通知するより、一定期間の候補をまとめる方が運用しやすいことがあります。実行回数には上限があるため、頻度の高いチャンネルを無条件で監視しないことも重要です。
GitHubは非エンジニアにも使える
GitHubのイベント連動は、コードを書く人だけの機能ではありません。マーケティング担当者でも、Webサイト改修のプルリクエストについて、次の確認メモを作れます。
- ページ名と変更目的
- 文言や計測タグへの影響候補
- 公開前に担当者が見るべき点
- 未確認の項目
ただし、コードの安全性や動作を要約だけで保証することはできません。公開判断はレビューと検証を経て行います。
作成前のチェックリスト
- SettingsのAppsで対象アプリを接続できるか確認する
- Workで対象イベントと処理内容を説明する
- Trigger・Condition・Promptを別々に読み直す
- 外部送信・更新が含まれていないか確認する
- 必要な認可だけを与える
- Scheduledで作成後のタスクを確認する
- 最初の数件は人が結果を照合する
共有時はタスク名にも注意する
タスクを共有すると、受け取った人は自分の権限と接続アプリで別のコピーを作成します。共有リンクには作成者名、過去のチャット、メモリ、添付ファイル、接続アプリのデータや認証情報は含まれません。
一方、タスクのタイトルや指示は共有相手から見えます。顧客名、口座情報、パスワードなどをタイトルや指示へ書かない運用が必要です。
期待できる結果
イベント連動タスクで減らしやすいのは、「更新に気づく」「必要箇所を拾う」「確認用に並べる」という作業です。判断、返信、登録、公開までを一度に任せるのではなく、まず情報整理の前段を小さく自動化します。
定時処理より早く気づけることが利点ですが、通知が多すぎれば逆効果です。Triggerを狭くし、Conditionで対象を絞り、Promptで禁止事項まで明記する。この3段階が運用の土台になります。
注意点
- 本記事は2026年8月29日時点の公式仕様に基づき、実アカウントでの作成・実行は検証していません。
- 対応イベント、プラン、実行上限、管理者設定は変更される場合があります。
- プロジェクト内で作成したタスクは、プロジェクトにアップロードしたファイルへアクセスできません。
- 承認が必要な外部操作を含むと、タスクが停止して確認を待つ場合があります。
- 顧客情報や社内情報を扱う前に、自社の利用規程とアプリ権限を確認してください。
次のアクション
まずは「指定件名のメールを見つけ、未記載項目を補完せず、確認用に要約する」タスクを1つ試します。返信やCRM登録は含めず、10件程度の結果を人が照合してから対象範囲を広げてください。
