2026年3月、Google は Google カレンダーのセカンダリカレンダー（ユーザーが所有する追加カレンダー）のライフサイクル変更について追報しました。非個人の Google Workspace 向けには適用が 2026年10月5日 に延期され、それまでの間は一定の自動オーナー割り当てが続きます。個人の Google アカウント向けの変更は 2026年4月27日 からの説明です。
この記事では、公式が述べている範囲で、情シスが押さえるべき期限・対象・運用上の手順を整理します。
この記事を読んだほうが良い人
- Google Workspace を運用し、退職・組織変更に伴うカレンダー管理を担当している方
- 共有チームカレンダーなどセカンダリカレンダーの所在を、オーナーのユーザーアカウントとセットで管理したい方
- 2026年のカレンダーまわりのポリシー変更を、プライマリカレンダーと混同せずに確認したい方
何が変わるのか（対象はセカンダリカレンダー）
今回の一連の説明の中心は、セカンダリカレンダーです。各ユーザーに紐づく プライマリカレンダー（通常はメールアドレスと同じ ID のカレンダー）と、ユーザーが作成・所有する 追加のカレンダー（セカンダリ） は別物です。公式のライフサイクル変更が主に扱っているのは後者です。
ポイントは次のとおりです。
- オーナーのユーザーが組織から削除されたあと、オーファン（所有者不在）になったセカンダリカレンダーが、方針どおり整理・削除の対象になります。
- **Google Workspace（非個人アカウント）**では、この厳格なライフサイクル変更の適用が 2026年10月5日 にずれ込みました。それまでの間、すでに「変更と共有の管理」権限を持つユーザーがいる場合など、自動でオーナーが割り当てられるプロセスが続く、という説明です（詳細は Workspace Updates の本文に従います）。
- 個人の Google アカウント向けには、従来どおり 2026年4月27日 から変更が進む、という整理です。
情シス向けの公式ヘルプでも、ユーザー削除前にイベントやセカンダリカレンダーをどう扱うかがまとまっており、削除後に追加の移管ができない旨が書かれています。つまり「退職処理でユーザーを消したあとから、あとからセカンダリのオーナーだけ直す」は基本として想定されていません。削除前の設計が本線です。
なぜ情シスは早めに手を付ける必要があるのか
ポリシーが読みやすい言葉で要約されると、「オーナーがいなくなった共有カレンダーは、組織のデータとして残し続けない」方向に寄っています。情シスから見ると、次の理由で影響が大きいです。
- 共有のチームカレンダーや設備・プロジェクト用カレンダーが、実質的に「退職者アカウントの所有物」になっていると、イベントや予約の履歴ごと失われるリスクがあります。
- 監査や引き継ぎで、カレンダー上の予定や説明欄に残した情報を参照する必要がある場合、消えたあとでは復旧できません。
- Workspace では期限が延びた分、「10月5日まで自動割り当てがあるから安心」だけに寄せると、権限設計が曖昧なカレンダーが棚上げされ、結局そのまま失われる、という落とし穴があります。
情シスが取るべき対応の考え方
ユーザー削除前が主戦場である
管理コンソールとヘルプの流れは、ユーザーがまだ削除されていないうちに、必要なセカンダリカレンダーを同じ組織内の別ユーザーへ移す、という前提です。実際のメニュー名や画面は変更されうるため、手順の詳細は Google Workspace 管理コンソールのヘルプ（ユーザー削除前のイベント／セカンダリカレンダーの取り消し・転送）に沿って確認してください。
すでにオーナーが削除済みのカレンダー
Workspace では、2026年10月5日までの間、公式が説明する オーファン・セカンダリへの自動オーナー割り当てが動く期間があります。ここで重要なのは、「変更と共有の管理」に相当する権限を、継続利用者側に付けておくなど、自動割り当ての前提を満たす設計にしておくことです。権限が誰にもなく、関係者も把握していないカレンダーは、期限後に消えるリスクが高まります。
プログラムでの一括移管について
Workspace Updates では、組織内でセカンダリカレンダーの所有権をプログラムで移すための Calendar API の新しいエンドポイントが 2026年6月末ごろまでに用意される、という説明があります。公開時点ではエンドポイント名やリクエスト形式をドキュメントで確認する必要があります。Calendar API の calendars リソースを patch して owner を書き換える、といった話は公式のリソース定義と一致しません。 自動化を計画する場合は、新エンドポイントのリファレンスが出てから設計するのが安全です。
洗い出しの現実的な進め方
すべてを API で一覧する前に、**「部門ごとの共有カレンダー一覧」「退職フローで誰がオーナーか」**をヒアリングで固めると、漏れが減ります。監査ログやレポートで補助し、オーナーのメールアドレスがディレクトリに存在するかを突き合わせる、というやり方も取れます。ここで用いるツール名や略称は、公式に存在するものだけを使い、存在しない製品略称を記事に書かないようにします。
運用フローに組み込むべきこと
退職・異動のチェックリストに、次を入れておくと再発を防げます。
- 共有セカンダリカレンダーのオーナーが誰かを記録し、退職者だけがオーナーになっていないか確認する
- 引き継ぎ先に「変更と共有の管理」相当の権限を付与する（自動割り当て期間中の前提を満たす）
- アカウント削除の前に、必要なカレンダーをヘルプの手順に従って移管する
- 2026年6月以降、新 API が利用可能になったら、大量移管をスクリプト化するかを検討する
まとめ
今回の変更は、プライマリカレンダー全体が4月27日に一斉削除されるといった話ではなく、セカンダリカレンダーの所有権とライフサイクルを厳密にする、という理解が起点です。Workspace 向けの実効は 2026年10月5日 に寄せて計画し、2026年4月27日 は主に個人アカウント側のスケジュールとして切り分けます。
だから情シス側では、共有カレンダーのオーナーを「人」ではなく「ロール」に寄せる、削除前に必ず移管する、権限のないオーファンを残さない、の3点を運用に埋め込むのが現実的です。公式の追報やヘルプは今後も更新されるため、実装に入る直前に Workspace Updates と管理コンソールのヘルプを再度当たり、日付と対象を自分のテナントの契約形態に照らして確認してください。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。
「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
※ この記事は DRASENAS Blog の転載です。オリジナルではコードや設定手順が随時アップデートされています。