処理の流れと項目の対応
- 確定した予約
- 時刻と状態を検査
- 予定を作成・更新
- 予定IDを保存
単発予約の一方向連携です。予約枠の確保や二重予約防止は予約側で別に設計します。
| 項目 | 用途・保存先 |
|---|---|
| booking_id | 予約と予定IDを対応させる |
| start / end / timezone | 開始・終了の瞬間を確定 |
| calendar_id + event_id | 変更・取消の対象を識別 |
予約の受付表を正本に決める
例では予約ID、状態、開始日時、終了日時、タイムゾーンを持つ表を正本とし、カレンダーを表示先にします。予定を作るだけでは予約枠の二重販売を防げません。空き枠の排他制御が必要なら予約サービス側で確定させ、確定済みの予約だけをMakeへ渡します。練習では参加者を付けず専用カレンダーを使います。
予定を作る前に時刻を検査する
入力例はBOOK-301、2026-11-02T10:00:00+09:00から11:00:00+09:00です。文字列に時差がある場合はそれを尊重し、時差のない日時には元のタイムゾーンを明示します。終了が開始より後か、必須項目がそろうかを確認し、形式不明の値を現在時刻に置き換えて進めないようにします。
対象カレンダーを固定して作成する
Google Calendarへの接続を設定し、練習用カレンダーを固定します。予定作成の詳細設定で件名、開始、終了を割り当て、件名には予約IDを含めて照合しやすくします。参加者や通知の設定は別に確認してください。設定確認中に顧客への招待メールが出ないよう、最初はテスト用の自分だけで扱います。
返された予定IDを保存する
作成結果のイベントIDとcalendar_idを予約IDにひも付けます。後の変更では件名検索から最初の予定を選ばず、この組合せを使います。予定作成が成功してID保存が失敗した場合には、もう一度作る前に対象カレンダーで照合します。ID未保存を理由に無条件で新規作成すると予定が増えます。
日時変更と取消を分けて反映する
変更は保存済みイベントIDを使って予定を更新します。取消は予約の状態を確認してから対象の予定を取り消し、記録には元のIDと取消日時を残します。カレンダー側で手動削除された場合に再作成するか、担当者の確認へ回すかも決めます。繰り返し予定は別の扱いが必要なので、この例では単発予約に限定します。
境界時刻と再送を確認する
同じ予約の再送、日付をまたぐ予約、日時変更、取消の順で試します。期待する結果は同じ予定の更新で、複数の予定が増えないことです。日本時間の画面だけでなく、元データとカレンダー側の時刻設定も照合します。招待先へ通知する運用では、更新・取消の際にメールが出る条件を本人用アドレスで確認します。
二方向同期を追加する前に責任を決める
人がカレンダーを変更した結果を表へ戻すなら、どちらを優先し、古い更新をどう見分けるかが必要です。最初は表からカレンダーへの一方向に絞ると確認範囲を抑えられます。検索・作成・更新・ID保存・再試行を費用へ数え、作成件数だけで利用量を見積もらないようにします。
Makeで小さな自動化から始める
まず練習用データで必要な処理を確認し、利用量と機能に合うプランを選んでください。登録時の料金・特典・適用条件は公式画面で確認できます。
Make公式サイトで登録する広告リンク利用量から費用を確かめる
月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。
費用を試算する参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- Google Calendar — Make情報確認日: 2026-10-30
- Date and time functions — Make情報確認日: 2026-10-30
- Make pricing — Core at 10,000 monthly credits情報確認日: 2026-10-28
- Make credits情報確認日: 2026-10-26
- Make scenario settings情報確認日: 2026-10-26
