「営業部の予定」「採用面接」「社用車の予約」のように、Googleカレンダーで個人の予定とは別に作ったカレンダー（セカンダリカレンダー）は、作った人のアカウントにひも付いています。作成者が異動や退職をするとき、ほかのメンバーに「オーナー」の権限を付けておけば引き継げる、と考えていないでしょうか。
Calendar APIの定義では、共有設定の「オーナー」と、カレンダーの「データオーナー」は別のものとして書かれています。この記事は、部署のカレンダーを管理する情シス担当者や、カレンダーを自動で作る社内ツールの開発者に向けて、2026年10月14日に取得したCalendar APIのDiscoveryドキュメント（APIの機械可読な定義。revision 20261009）と、10月16日に確認したCalendar APIのリリースノート、Google Workspace Updates（Googleの公式ブログ）、ヘルプの記述をもとに整理します。
「オーナー」が何人いても、データオーナーは1人
カレンダーの共有設定で付ける権限（ACLのロール）のうち、owner は「予定の閲覧・編集に加え、他の人のアクセス権を変更できる」権限です。APIの説明には、次の注意書きがあります。
Important: the owner role is different from the calendar’s data owner. A calendar has a single data owner, but can have multiple users with owner role.
オーナー権限は複数の人に付けられますが、データオーナーは常に1人です。誰がデータオーナーかは、カレンダーの情報（calendars.get）とカレンダーリスト（calendarList.list）の dataOwner で確認できます。項目の説明は「カレンダーのオーナーのメールアドレス。セカンダリカレンダーにのみ設定される。読み取り専用」です。
つまり「共有設定でオーナーを足したから安心」とは言えません。データオーナーを別の人に移す操作は、共有設定とは別に用意されています。
2026年10月5日から、データオーナーの削除・停止がカレンダーに及ぶ
Google Workspace Updatesの2026年10月5日の告知によると、仕事用のGoogle Workspaceアカウントでは、セカンダリカレンダーがデータオーナーのアカウントと同じ扱いになりました（10月5日から段階的に展開）。
- データオーナーのアカウントを削除すると、そのカレンダーも予定ごと削除される
- データオーナーのアカウントを停止すると、そのカレンダーも停止される
- カレンダーを残すには、アカウントの削除・停止より前にデータオーナーを移す必要がある
管理者向けヘルプも「カレンダーのオーナーが削除されると、セカンダリカレンダーは予定も含めて削除され、そのあとは移管もできない」と説明しています。それまでは、オーナーのいなくなったカレンダーを「変更および共有の管理権限」を持つ人に自動で割り当てる処理がありましたが、この処理は10月5日で終わると3月30日の告知に書かれています。
データオーナーを移す方法は、告知とヘルプによると次の3つです。
| 方法 | 誰が | 特徴 |
|---|---|---|
| カレンダーの設定画面 | データオーナー本人 | 同じ組織内の人に移す。受け取る人が60日以内に承諾するまでは元の人がオーナーのまま |
| 管理コンソール | 「Manage Calendars」権限を持つ管理者 | ユーザーの持つセカンダリカレンダーをまとめて別の人に移す。受け取る人の承諾は不要 |
Calendar API（calendars.transferOwnership） | 同上 | カレンダーを1つずつ選んで移せる。受け取る人の承諾は不要 |
本人が退職の前に移すのがいちばん手軽ですが、受け取る人の承諾待ちが残ります。以下では、件数が多いときや社内ツールに組み込むときに使うAPIの条件を詳しく見ます。
管理者がAPIでデータオーナーを移す
データオーナーの変更には、calendars.transferOwnership というメソッドが使えます。説明は「Google Workspaceの組織内で、ユーザー間でセカンダリカレンダーを移す」です。条件はDiscoveryドキュメントに次のように書かれています。
| 項目 | 定義に書かれている条件 |
|---|---|
| 実行する人 | 「Manage Calendars」（カレンダーの管理）の権限を持つGoogle Workspaceの管理者。ユーザー認証が必要 |
| 必須の指定 | calendarId、newDataOwner（新しいデータオーナーのメールアドレス）、useAdminAccess（true のみ受け付ける） |
| スコープ | https://www.googleapis.com/auth/calendar または https://www.googleapis.com/auth/calendar.calendars |
| 移せるカレンダー | 有効な（active）セカンダリカレンダー。無効化・削除されたカレンダーの移管は対象外 |
| 移せる範囲 | 同じGoogle Workspace組織内のユーザー間 |
Calendar APIのリリースノートは、このメソッドを2026年6月18日に一般提供（GA）としています。Workspace Updatesの同日の告知では、6月18日から最大15日かけて段階的に展開するとしています。npmで公開されているGoogle公式のNode.jsクライアント（googleapis）では、8月3日公開の174.0.0から型定義に含まれています。
Node.jsクライアントで呼ぶ場合は、次の形になります（型定義から組み立てた例で、編集部は実行していません）。
import { google } from 'googleapis';
// 「カレンダーの管理」権限を持つ管理者としてユーザー認証したクライアント
const calendar = google.calendar({ version: 'v3', auth });
await calendar.calendars.transferOwnership({
calendarId: 'c_xxxxxxxx@group.calendar.google.com', // 移すカレンダーのID
newDataOwner: 'successor@example.co.jp', // 新しいデータオーナー
useAdminAccess: true, // true 以外は受け付けない
});戻り値は空です。移せたかどうかは、あとで calendars.get を呼び、dataOwner が新しい人に変わったかで確かめます。
サービスアカウントで作ったカレンダーは移せない
社内ツールやバッチ処理でカレンダーを自動で作っている場合は、特に注意が必要です。カレンダーを作る calendars.insert の説明には、次の注意書きがあります。
Don’t use a service account for authentication. If you use a service account for authentication, the service account is the data owner, which can lead to unexpected behavior. For example, if a service account is the data owner, data ownership cannot be transferred.
リクエストを認証したユーザーが新しいカレンダーのデータオーナーになります。サービスアカウントで作るとサービスアカウント自身がデータオーナーになり、データオーナーを移せません。公式の推奨は、データオーナーにしたい人として認証することです。アプリから特定のユーザーとして動かす場合は、ドメイン全体の委任（管理者が許可した範囲で、アプリがユーザーの代わりに操作する仕組み）を使うよう案内しています。
案件ごと・部署ごとにカレンダーを自動で作る仕組みがあれば、作成時の認証がサービスアカウントそのものになっていないか、コードと設定を見直す価値があります。すでに作られたカレンダーは dataOwner を見れば、サービスアカウントのアドレスかどうかを判別できます。
退職・異動の手順に組み込むなら
ここからは編集部の提案です。退職者のアカウントを閉じる全体の順番は退職者のアカウントを閉じる順番で整理しています。その中に、カレンダーの確認を次のように加えます。
- データオーナーのカレンダーを洗い出す。 対象者として認証し（ドメイン全体の委任を使うなど）、
calendarList.listの結果からdataOwnerが本人のものを抜き出す。2026年7月14日に一般提供となったshowOwnOrganizationOnlyをtrueにすると、自組織のカレンダーだけに絞れる - 引き継ぐ人を決める。 部署で使い続けるカレンダーか、役目を終えたカレンダーかを、利用している部署と確かめる
- アカウントの停止・削除より前に移す。 2026年10月5日からは、アカウントを停止するとカレンダーも停止され、削除するとカレンダーも消えます。APIの説明も、無効化・削除されたカレンダーは移せないとしています。退職者のアカウントを閉じる順番で「まず停止」としている場合も、カレンダーの移管はその前に済ませます
- 移したあとに
dataOwnerを確かめる。 共有設定（ACL）は移管の前後で比べ、意図しない変化がないかも確認する
会議室や設備のカレンダー（リソースカレンダー）で予約が残り続ける問題は会議室の幽霊予約を片付けるを、代理の権限で非公開の予定がどう見えるかは非公開の予定を見せない代理権限を参考にしてください。
確認した範囲
2026年10月14日に、Calendar API v3のDiscoveryドキュメント（revision 20261009）を取得し、
calendars.insert・calendars.transferOwnership・dataOwner・ACLのロールの説明を原文で確認しました。10月16日に、revision 20261012で同じ記述であること、Calendar APIのリリースノート（6月18日のGA）、Google Workspace Updatesの告知（2026年3月30日・6月18日・10月5日）、管理者向けヘルプとカレンダーのヘルプを確認しました（資料調査）。APIの呼び出し、管理コンソールやカレンダーの設定画面での移管の操作、ユーザーを停止・削除したときの実際の挙動は、編集部では試していません。
部署のカレンダーや共有ドライブの引き継ぎを、退職・異動の手順にどう組み込むか迷う場合は、IT・Google Workspace 無料相談からお問い合わせください。
参考資料
- Google Calendar API v3 Discovery document
- Calendars: transferOwnership（Calendar API リファレンス）
- Google Calendar API release notes
- Secondary calendars will now follow the lifecycle of their owner（Google Workspace Updates、2026年10月5日）
- Improved management of secondary calendars via the Calendar API（Google Workspace Updates、2026年6月18日）
- An update on secondary calendar lifecycle changes and a new API（Google Workspace Updates、2026年3月30日）
- Cancel or transfer events or secondary calendars before deleting a user（Google Workspace 管理者ヘルプ）
- Transfer calendars or events in Google Calendar（Google カレンダー ヘルプ）
- googleapis（npm）174.0.0
- @googleapis/calendar（npm）16.0.0
