Workspace のセカンダリカレンダーが所有者と連動して消える — 退職者処理の手順が変わる
Google が 2026-10-05、Workspace アカウントのセカンダリカレンダーが所有者アカウントのライフサイクルに追従するよう挙動を変更したと告知した。所有者のアカウントを削除するとその所有するセカンダリカレンダーも削除され、所有者を停止するとカレンダーも停止される。プライマリカレンダーと同じ挙動に揃える変更で、公式はデータガバナンス上の理由を挙げている。残したいカレンダーは、所有者の削除・停止の前に別ユーザーへ所有権を移管する必要がある。管理者は管理コンソールまたは Calendar API の transferOwnership、利用者は Calendar の設定画面から移管できる。全エディションと Workspace Individual が対象。
ニュース原文を読む ↗要約
Google は 2026-10-05、Workspace アカウントのセカンダリカレンダー（個人用以外のカレンダー）が、所有者アカウントのライフサイクルに追従するよう挙動を変更したと告知しました。
変更の内容は単純です。所有者のアカウントが削除されると、その所有するセカンダリカレンダーも削除されます。所有者が停止（suspend）されると、セカンダリカレンダーも停止されます。 プライマリカレンダーと同じ挙動に揃えた、という位置づけです。
公式が挙げている理由はデータガバナンスで、「すべてのセカンダリカレンダーが、そのデータに適用される組織の設定とポリシーを決める有効な所有者に紐づく」状態にするためと説明しています。所有者のいないカレンダーが組織内に浮いている状態を解消するという趣旨で、ガバナンスの考え方としては筋が通っています。
問題は、セカンダリカレンダーが実際には「個人のもの」として使われていないことです。
セカンダリカレンダーは、組織内でだいたい共有リソースとして使われています。 会議室や備品の予約用、プロジェクトのマイルストーン用、チームの当番表、イベントスケジュール、採用面接枠。どれも「作った人のもの」ではなく「チームのもの」として運用されています。 それでも Google の仕組みの上では、作成したアカウントが所有者です。
つまりこの変更は、「数年前にカレンダーを作った担当者が退職したら、チームの予約表が消える」という挙動になります。
そして復旧の方法は事前の移管だけです。 公式は「所有者の削除・停止の前に、別ユーザーへ所有権を移管する必要がある」と明記しています。削除された後に気付いても、記事の時点で公式に示されている手段はありません。
移管の方法は3つ用意されています。管理者は管理コンソールまたは Calendar API の transferOwnership、利用者は Calendar の設定画面からです。API が使えるということは、棚卸しと移管を一括処理できることを意味します。
ロールアウトは 2026-10-05 開始の extended rollout で、公式は「全機能が見えるまで15日を超える可能性がある」と明記しています。通常の段階展開より長いタイプです。
何が変わったか
- 所有者アカウントの削除で、その所有するセカンダリカレンダーも削除される
- 所有者の停止（suspend）で、セカンダリカレンダーも停止される
- プライマリカレンダーと同じ挙動に揃える変更
- 公式の理由はデータガバナンス（すべてのカレンダーを有効な所有者に紐づける）
- 残したいカレンダーは、削除・停止の「前に」所有権を移管する必要がある
- 移管経路は3つ: 管理コンソール / Calendar API
transferOwnership/ 利用者の Calendar 設定 - 対象は全 Google Workspace エディション + Workspace Individual
- ロールアウトは 2026-10-05 開始の extended rollout（15日を超える可能性あり）
- 対象は「個人用以外（non-personal）」の Workspace アカウント
業務インパクト
最初にやることは、オフボーディング手順書の修正です。機能の評価より先です。
退職者・異動者のアカウント削除手順に、**「本人が所有するセカンダリカレンダーの確認と移管」**を追加してください。順序が重要です。 削除してから気付いても戻せないため、手順書を直す前にアカウント削除を進めると、そのぶんだけ消えます。 人事異動が多い時期なら、手順書の修正を最優先にする判断は妥当です。
同時に、既存の「所有者が既に不在のカレンダー」を洗い出してください。 今回の変更は今後の削除に効くものですが、既に停止済み（suspend 状態）のアカウントが所有するカレンダーがある場合、その扱いがどうなるかは告知からは読み取れません。Calendar API で所有者ごとのカレンダー一覧を取れるので、所有者が停止・不在のカレンダーを機械的に抽出して移管しておくのが安全側の対応です。
「誰に移管するか」の方針も先に決めておく必要があります。 個人へ移管すると同じ問題が繰り越されるだけです。サービスアカウントや、部門の代表アカウントのような、人の異動で消えない所有者へ寄せるのが本来の解です。これは今回の変更をきっかけにカレンダーの所有構造を一度整理するという話になります。手間はかかりますが、一度やれば同じ問題は起きません。
停止（suspend）の扱いにも注意が必要です。 削除と違い、停止は休職や調査期間中に使われる一時的な状態です。その期間中にチームの予約表が止まると、業務が直接影響を受けます。「一時停止だから大丈夫」と考えていると、カレンダーが止まって問い合わせが来ます。 停止を運用で使っている組織は、停止前の移管を手順に含めてください。
AI / エージェント関連の変更ではありませんが、情シスの作業が発生する点では今週の更新の中で最も実害が出やすい部類です。 機能追加は使わなければ影響しませんが、この種の挙動変更は何もしなくても影響します。
副業・個人活用視点
Workspace Individual も対象なので、ひとり法人やフリーランスの Workspace 契約にも適用されます。
ただし、ひとりで使っている場合の実害はほぼありません。 自分のアカウントが削除されるときは契約自体を解約するときなので、カレンダーが消えても問題になりません。実質的に関係するのは、人を雇っている・業務委託と共有している場合です。
効いてくるのは、クライアントの Workspace 管理を請け負っている場合です。
情シス業務を受託している、あるいは AI 導入支援の延長で Workspace の設定を見ている立場なら、これは今週連絡すべき内容です。 「Google の仕様変更で、退職者処理の手順を変える必要があります」という連絡は、言われる前に出せると評価が変わる類の情報です。逆に、実際にカレンダーが消えてから「仕様変更でした」と説明するのは最悪の順序です。
移管作業自体が小さな受託案件になります。 Calendar API の transferOwnership で棚卸しと一括移管ができるため、所有者が不在・停止のカレンダーを抽出して、部門アカウントへ寄せるという作業はスクリプトで組めます。規模の大きい組織なら手作業では現実的でないので、提案として成立します。
そして、この種の「挙動変更」を拾えるかどうかが差になります。 新機能の発表はニュースで流れてきますが、ライフサイクル挙動の変更のような地味な告知は、Workspace Updates を自分で読まないと拾えません。 AI ツールの新機能ばかり追っていると、顧客に実害が出るのはこういう変更の方だという事実を見落とします。Workspace Updates Blog を巡回対象に入れておく価値は、この一点で十分あります。