ChatGPT の定期タスクが Gmail / Slack / GitHub のイベントで起動 — 時刻起動からイベント駆動へ、共有と Free 枠3件も同時に

要約

2026-08-25、ChatGPT Work の定期タスク（Scheduled tasks）が、時刻ではなくアプリ側のイベントで起動できるようになりました。地味な機能追加に見えますが、ChatGPT が「呼んだら動くもの」から「何かが起きたら動くもの」へ変わったという意味では、性質が違う変更です。

対応するトリガーは3つです。Gmail の新着メッセージ（送信者や件名でフィルタできる）、Slack チャンネルへの投稿（監視するチャンネルを選択）、GitHub のプルリクエスト活動（レビュー、コメント、コミット更新、マージといった動き）。公式が挙げる例は、登録開始を知らせるメールが届いたら要約させる、クライアントが Slack でフィードバックを共有したら次のステップを起草させる、といったものです。

作成できるのは Plus / Pro ユーザーで、web・iOS・Android から利用します。前提条件がいくつかあります。対象アプリを接続してアクセスを承認しておくこと。Slack については、監視する各チャンネルに ChatGPT アプリ（@ChatGPT）をメンバーとして追加しておくこと。GitHub については、接続したアプリが対象リポジトリへアクセスできる状態にしておくこと。承認が必要なアクションは、利用者が確認するまで停止します。

制約も明示されています。 イベント起動タスクは時刻ベースのスケジュールと併用できません。「毎朝9時に、かつ新着があったら」という書き方はできず、どちらか一方です。また、該当するイベントが短時間に連続した場合、ChatGPT が1回の実行にまとめることがあります。保留中のイベントは Scheduled 画面で確認でき、Run now で即時実行もできます。

同日、タスクの共有も追加されました。こちらは Free / Go / Plus / Pro のすべてで使えます。共有を受け取った側は、指示内容と（該当する場合は）スケジュールを確認・変更し、自分のアプリを接続して独立したコピーを作ります。元のタスクとは切り離されるので、共有元の変更が伝播することはありません。ただし共有された webhook 起動タスクを実際に動かすには、受け取った側にも Work へのアクセスと自分の接続アプリが必要です。

Free ユーザーにも定期タスクが開放されました。 最大3件まで、単発または1日1回までの繰り返しで、柔軟なスケジュールウィンドウを使えます。Free / Go はイベント起動タスクを作成できません。

何が変わったか

• Gmail の新着 / Slack チャンネル投稿 / GitHub の PR 活動をトリガーに定期タスクが起動（Plus / Pro）
• Gmail は送信者・件名でフィルタ可能。GitHub はレビュー・コメント・コミット更新・マージに反応
• 前提: 対象アプリの接続とアクセス承認、Slack は監視チャンネルへの ChatGPT アプリ追加、GitHub は接続アプリの対象リポジトリアクセス
• イベント起動タスクは時刻ベースのスケジュールと併用不可
• 短時間に連続したイベントは1回の実行にまとめられることがある。保留中のイベントは Scheduled 画面で確認、Run now で即時実行
• 承認が必要なアクションは、利用者が確認するまで停止
• タスクの共有（Free / Go / Plus / Pro）。受け取り側は指示・スケジュールを変更し、自分のアプリを接続して独立したコピーを作成
• Free ユーザーは定期タスクを最大3件（単発または1日1回まで）。Free / Go はイベント起動タスクを作成不可

業務インパクト（一般企業向け）

まず押さえるべきは、この機能が情シスの承認なしには成立しないという点です。 Slack で使うなら、監視対象のチャンネルに ChatGPT アプリをメンバーとして追加する必要があります。GitHub なら、接続アプリに対象リポジトリへのアクセス権を与える必要があります。**つまり、個人が勝手に始められる範囲を超えています。**これは制約であると同時に、統制の効く設計でもあります。前の記事で触れたクラウドブラウザのサインインがシャドー IT の入り口になりうるのとは、対照的な構造です。

逆に言えば、承認プロセスを整えないと機能が使えないままになります。 「Slack チャンネルに ChatGPT を入れていいか」という申請が上がってきたとき、判断基準を持っていない組織は止まります。チャンネルに入るということは、そのチャンネルの投稿が ChatGPT に渡るということです。全社チャンネルと、機微な議論をするチャンネルは、当然扱いが変わります。チャンネル単位でホワイトリストを作る運用が、現実的な落とし所になります。

GitHub の PR 活動をトリガーにできる点は、開発現場で実際に使える機能です。 レビューコメントが付いたら要約させる、マージされたら関連ドキュメントの更新要否を確認させる、といった使い方が組めます。ただし、接続アプリに与えるリポジトリアクセスの範囲は最小にしてください。 「全リポジトリ」で接続するのは楽ですが、監視したいのが1リポジトリなら、その1つに絞るべきです。後から絞るのは、最初から絞るより難しい——これは AI に限った話ではありません。

「時刻起動と併用できない」という制約は、設計に効きます。 「毎朝まとめて処理する」形と「起きたら即座に処理する」形は、運用として別物です。前者は件数が読めて処理が安定し、後者は反応が速いかわりに実行回数が読めません。**コストと反応速度のどちらを取るかを、タスクごとに決める必要があります。加えて、短時間に連続したイベントがまとめられる挙動は、「1イベント1実行」を前提にした設計を壊します。**通知の取りこぼしを許容できない用途には、この機能を使わないでください。

タスク共有は、社内展開の速度を上げる機能です。 誰か一人がうまく動く定期タスクを組んだら、それをチームへ配れます。受け取り側で独立したコピーになるため、各自が自分の接続アプリで動かします。これは「便利な使い方が個人の中で閉じる」という、社内 AI 活用の典型的な停滞を崩す仕組みです。社内でタスクを共有する場が用意されているか——たとえば Slack のチャンネルや社内 Wiki に共有リンクを集める——が、実際の普及率を左右します。

Free ユーザーへの3件開放は、社内でのお試し導入の障壁を下げます。 有償契約の前に「定期タスクとは何か」を体験してもらえます。ただし1日1回までの繰り返しという制約があるので、業務で本格的に使うには足りません。評価用と割り切って渡すのが正しい使い方です。

副業・個人活用視点

個人事業でいちばん効くのは、Gmail の送信者・件名フィルタでしょう。 クライアントからのメールを受け取ったら要約して次のアクションを整理させる、請求関連のメールが来たら記録用にまとめさせる。メールを開く前に、何が来たかが分かっている状態を作れます。フィルタが送信者と件名で切れるので、特定顧客だけを対象にするといった絞り込みも素直に書けます。

GitHub の PR トリガーは、受託開発をしている人には実用的です。 クライアントのリポジトリでレビューが付いたら通知して要約させる、というのは、複数案件を並行しているときほど効きます。ただし、接続アプリに与えるリポジトリアクセスの範囲は、顧客との合意の範囲内にしてください。 「便利だから全リポジトリ接続」は、後で説明できません。案件ごとに接続範囲を記録しておくだけで、いざというときの説明が成立します。

Slack トリガーは、コミュニティ運営や情報収集で使えます。 参加している技術系 Slack の特定チャンネルを監視して、重要そうな投稿だけをまとめさせる、といった使い方です。**ただし、他人のワークスペースに ChatGPT アプリを入れるには、そのワークスペースの管理者の許可が要ります。**自分の裁量で入れられるのは自分が管理しているワークスペースだけです。この前提を忘れると、申請して断られるところで止まります。

タスク共有は、そのまま「売れる形」になりえます。 よく効く定期タスクの構成を作って、支援先や講座の受講者へ共有する。受け取った側は自分のアプリを接続して独立したコピーを作れるので、渡し方として無理がありません。「AI 活用の型を配る」という提供形態が、技術的な障壁なしに成立します。プロンプトを文章で渡すのと、動くタスクを渡すのとでは、受け取った側の実行率がまるで違います。

Free 枠3件は、講座やセミナーの実習に使えます。 受講者に課金を求めずに、定期タスクの体験まで持っていけます。1日1回までという制約があるので、実習では「毎朝の情報整理」のような日次のものを題材にするのが素直です。有償プランとの差分を体験の中で自然に伝えられるので、次のステップの提案にもつながります。