スキップしてメイン コンテンツに移動

Google Calendar 所有権モデル変更 - オーナー不在の共有カレンダーは削除へ(2026年4月)

■ 共有カレンダー管理モデル変更の記録として


Google Workspace 管理者向けに、  

Google Calendar の「予備カレンダー(共有カレンダー)」に関する  

所有権管理モデルの変更通知が配信されました。


本変更は、データガバナンスおよびライフサイクル管理強化の一環として実施され、  

2026 年 4 月 27 日よりクリーンアッププロセスが開始されます。


---


■ 予備カレンダーとは


本通知で対象となる「予備カレンダー」とは、  

ユーザーのメインカレンダー以外に作成されたすべての共有カレンダーを指します。


例:


- 会議室予約カレンダー

- プロジェクト共有カレンダー

- 当番表・シフト管理

- チームスケジュール

- イベント管理カレンダー

    


---


■ 変更の背景


これまでの Google Calendar では、


- カレンダー作成者不明

- 退職者所有

- 外部ユーザー所有


といった「オーナー不在」状態が放置可能でした。


この状態は、


- 管理責任の不明確化

- データ保持ポリシー違反

- 不要データ蓄積

    

といったガバナンス上の課題を生んでいました。


---


■ 主な変更ポイント


---


### ① 専任オーナー制の導入


今後すべての予備カレンダーには、  

必ず 1 名のオーナーが割り当てられます。


このオーナーが属する組織ポリシーが、  

当該カレンダーに自動適用されます。


---


### ② ライフサイクルの統合


予備カレンダーは今後、  

オーナーアカウントのライフサイクルに従います。


つまり:


- ユーザー削除 → カレンダー削除

- 組織移行 → カレンダー削除

    

メインカレンダーと同様の扱いとなります。


---


### ③ オーナー不在カレンダーの削除


以下の条件に該当するカレンダーは、  

2026 年 4 月 27 日より削除対象となります。


- オーナー不明

- 退職者所有

- 外部ユーザー所有

- 組織外帰属カレンダー

    

Google からは対象一覧が添付ファイルとして通知されます。


---


■ 管理者が取るべき対応


---


### ① 削除対象リストの確認


まずは通知に添付された  

削除予定カレンダー一覧を確認します。


確認ポイント:


- 現在も使用中か

- 会議室予約用途か

- 業務運用に影響がないか


---


### ② オーナー権限の譲渡


保持したい場合は、  

2026 年 4 月 20 日までに以下対応を実施します。


方法:


- 「予定の変更および共有の管理」権限付与

- 組織内アクティブユーザー指定

    

移行時に当該ユーザーが 新オーナーとして設定されます。


---


### ③ データエクスポート


保持しないが記録が必要な場合は:


- Data Export

- Google Takeout

- API 取得

    

によるバックアップが推奨されます。


---


■ 今後の運用上の注意点


今回の変更により、  

共有カレンダーは「個人依存資産」から  

「所有者責任資産」へと位置づけが変わります。


そのため今後は:


- 管理者アカウント所有

- 機能専用アカウント所有

- Offboarding時の移管

    

といった運用整備が重要になります。


---


■ 所感


今回の変更は単なるカレンダー仕様更新ではなく、  

Google Workspace 全体で進行している


```

Ownershipベース管理

データライフサイクル統合

```


の一環と考えられます。


Drive における権限モデル刷新と同様、  

データの責任主体を明確化する流れが強まっています。


今後はカレンダーも含め、  

「誰の資産か」を前提とした管理設計が求められるでしょう。

(EOF)

コメント

このブログの人気の投稿

M365 マイグレーションのためのコネクション設定

完璧。 画面ショットでわかる通り、 Endpoint EWS Teams Chat Graph API 全てOK。 ここまで整うと、気持ち良い。 M365 Connection サクセス

トライアルは成功したのに進まない? 本番移行で起きた “落とし穴”

  1. **結論**         - トライアルと本番は、原則「同一ドメイン」で行うのが安全          2. **問題が起きやすいケース**     - トライアル:旧ドメイン     - 本番:新ドメイン     - 発注者と実行者が異なる場合          3. **実際に起きた挙動**     - ドメインは見える     - でもライセンスが使えない     - UI では解決できない          4. **対処法**     - 事前にドメイン設計を揃える     - もし異なる場合は、サポート介入を前提にスケジュールする          5. **まとめ**     - ツールの問題ではなく「設計の問題」     - 事前に知っていれば防げる          (EOF)