Make.com Googleカレンダー連携の使い方　予定を自動で回す 2026

Googleカレンダーの自動化で本当に効くのは、予定を作る側ではありません。予定をきっかけに他のものを動かす側です。

カレンダーの通知は、目覚まし時計に似ています。時間になったら鳴る。でも、鳴っているだけで何もしてくれない。起きるかどうかは自分次第です。

Makeをつなぐと、ここが「起こしに来てくれる人」に変わります。時間になったら資料を用意して、関係者に連絡して、記録も残しておく。鳴らすだけの装置と、動いてくれる係の差。

この記事では、その仕組みの作り方と、つまずきやすい場所を整理します。

Make × Googleカレンダーで何ができるのか

大きく2方向あります。カレンダーを見張る側と、カレンダーに書き込む側です。

見張る側の例。

• 明日の予定を毎朝Slackにまとめて流す
• 会議の30分前にリマインドを飛ばす
• 新しい予定が入ったら、内容をシートに記録する
• 特定のキーワードを含む予定だけを別カレンダーに複製する

書き込む側の例。

• フォームの申し込みから予定を自動作成する
• スプレッドシートの行をまとめてカレンダーに反映する
• メールの内容をAIに読ませて、日程を抽出して予定にする
• タスク管理ツールの締切をカレンダーに同期する

乱暴にまとめると、カレンダーを「予定表」から「起点」に変える作業です。書いてあるだけの情報が、何かを動かすトリガーになる。

モジュールの選び方

Googleカレンダーのアプリには、イベント関連だけで7つほどのモジュールがあります。最初に押さえるのは3つです。

ここで最初の分かれ道が来ます。Watch EventsとSearch Eventsのどちらを使うか。

Watchは「予定が追加されたら動く」型です。カレンダーに何か入った瞬間に反応してほしい場合はこちら。

Searchは「決まった時刻に、対象の予定を取りに行く」型です。毎朝8時に今日の予定を一覧で流したい、といった用途はこちらになります。

「毎朝の予定通知を作りたい」と思ってWatchを選び、朝になっても何も来ない。予定は昨日のうちに入れてあるので、朝の時点では何も”追加”されていない。よくある失敗です。

実際の作り方：毎朝の予定をSlackに流す

一番使う頻度が高いであろう構成で説明します。モジュールは3つ。

1. スケジュール設定を先に決める

この構成ではトリガーがカレンダー側ではなく時刻です。シナリオのスケジュール設定で「毎日8時」のように指定します。

先にここを決めておくと、後の設計が楽になります。

2. Search Eventsで今日の予定を取る

Googleカレンダーの「Search Events」を置き、Googleアカウントで接続を作成します。対象カレンダーを選び、取得する期間を指定。

今日1日分を取るなら、開始と終了にMakeの日付関数を使います。

開始：{{formatDate(now; “YYYY-MM-DD”)}}T00:00:00
終了：{{formatDate(now; “YYYY-MM-DD”)}}T23:59:59

Limitの値は10前後にしておくと安全です。大きくしすぎると処理が重くなります。

3. まとめてから通知する

ここがコツです。Search Eventsは予定を1件ずつ返すので、そのままSlackにつなぐと予定の数だけメッセージが飛びます。5件の予定があれば5通。

これを避けるには、間に「Text aggregator」を挟みます。複数の結果を1つのテキストにまとめてくれるモジュールで、これを通してからSlackに送ると、1通にきれいに収まります。

集約モジュールの存在を知らないまま組んで、朝から通知が連射される。自動化を始めた人がだいたい一度は通る道というオチです。

4. Slackにつなぐ

Slackの「Create a Message」を追加して、集約したテキストをマッピング。あとはシナリオをONにするだけです。

つまずきやすいポイント

タイムゾーン

カレンダー連携で最大の落とし穴がこれです。

Makeのシナリオには、アカウント設定に基づくタイムゾーンがあります。Googleカレンダー側にもタイムゾーンがある。この2つがずれていると、予定の時刻が9時間ずれるという分かりやすい事故が起きます。

対処は単純で、Makeの組織設定でタイムゾーンをAsia/Tokyoにしておくこと。設定を変えたあとは、既存のシナリオも一度動かして確認してください。

日付関数で時刻を組み立てる場合も同じです。nowが返すのはシナリオのタイムゾーン基準の現在時刻なので、ここが狂っていると全部狂います。

繰り返し予定の扱い

毎週の定例会議のような繰り返し予定は、内部的には「繰り返しのルール」と「個別の予定」に分かれています。

Searchで取得すると個別の予定として返ってきますが、Watchで更新を検知しようとすると、繰り返し全体の変更なのか1回分の変更なのか判別しづらい場面が出てきます。

正直、ここは私も設計に迷うところです。繰り返し予定を細かく扱いたい場合は、Watchではなく毎日Searchで取り直す構成のほうが、結果的に安定する印象があります。

接続時のアクセスモード

Googleカレンダーの接続を作るとき、モジュールが実行できる操作の範囲を選ぶ設定があります。読み取りのみに制限するモードから、削除まで含めて実行できるモードまで。

通知だけが目的なら、書き込み権限を渡す必要はありません。事故で予定が消える可能性を、設定の段階で潰しておけます。

クレジット消費

忘れがちですが、Search Eventsは取得した件数分のクレジットを消費します。予定が10件あれば、後続の処理もそのぶん動く。

Makeの無料プランは月1,000クレジット。毎朝1回、予定10件を処理する構成なら月に数百クレジット程度で収まりますが、これを1時間ごとに回すと確実に足りません。

私がこのブログの記事生成をMakeで回していた頃も、結局は「頻度を落として何とかする」の繰り返しでした。カレンダー連携は特に、リアルタイム性を求めた瞬間にコストが跳ね上がります。

予定の説明欄に何を書くか

自動化を前提にするなら、予定のタイトルや説明欄の書き方を先に決めておくと後が楽です。「【外出】」のような目印を頭につけておけば、フィルターで簡単に振り分けられます。

仕組み側を賢くするより、入力側を揃えるほうが安上がりで確実。これはカレンダーに限らず、自動化全般に言えることだと思います。

他の方法との違い

Googleカレンダーには標準の通知機能があります。単に「予定の10分前に知らせてほしい」だけなら、そちらで足ります。わざわざMakeを挟む必要はありません。

Makeが効くのは、通知の先に処理があるときです。予定の内容をシートに書く、AIに要約させる、他のツールに転記する。カレンダーの外に出ていく処理が1つでも入った瞬間、標準機能では届かなくなります。

Google Apps Scriptでも同じことはできて、しかも無料です。ただしコードを書く必要がある。Slackや外部サービスとつなぐ部分の実装量を考えると、Makeのほうが早いことが多い。

Makeの気になるところも書いておきます。Googleとの接続は、権限の有効期限や設定変更で切れることがあります。ある朝、通知が来ないと思ったら認証が切れていた、という事態は起こり得る。エラー通知の設定は入れておいてください。

よくある質問

無料プランでもカレンダー連携はできますか

できます。アクティブなシナリオ2本まで、月1,000クレジットまでという制限内であれば十分実用になります。1日1回の予定通知程度なら余裕です。

複数のカレンダーをまとめて扱えますか

1つのモジュールで指定できるカレンダーは1つです。複数扱うならモジュールを並べて、集約する構成になります。処理量は増えます。

予定の参加者情報も取れますか

取れます。参加者のメールアドレスや出欠状況も返ってくるので、それを条件に処理を分岐させることも可能です。ただし他人の情報を扱うことになるので、記録先の管理には注意してください。

Googleカレンダー以外でも同じことができますか

OutlookカレンダーのモジュールもMakeにはあります。考え方は同じで、監視するか取りに行くかの選択から始まります。

まとめ

カレンダー連携でつまずく場所は、だいたい3つです。WatchとSearchの取り違え、タイムゾーンのずれ、そして集約モジュールを知らずに通知を連射すること。

この3つを避けるだけで、大半の構成は素直に動きます。

※本リンクはアフィリエイトリンクです。

無料プランでも、毎朝1回の予定通知くらいなら十分作れます。まずはそこから → Make.com（※アフィリエイトリンクです）

作るかどうかの判断材料を1つ渡すなら、その予定を見たあとに毎回やっている作業があるかです。見て終わりなら標準の通知で十分。見たあとに必ず何かをしているなら、そこが自動化の入口。答えは機能一覧ではなく、あなたのカレンダーの隣で毎回起きていることの中にあります。