Googleカレンダーの同期: what it does and where it breaks down

Search for why Google Calendar sync is not working and the fixes that come back do not agree with each other. One page says to remove the account and add it again. Another says to tick a box on a settings page nobody has heard of. A third says to change a refresh interval. All three are correct, for different situations, and none of them says which situation is which.

The reason they conflict is that the word sync is doing two jobs. It describes a two-way connection where events can be edited from either side, and it also describes a one-way subscription where events arrive and nothing goes back. Those are separate mechanisms with separate failure modes. Working out which one is in use takes about ten seconds and removes roughly half of the possible fixes.

Two mechanisms, one word

Google documents two ways to get a calendar into another application. The first adds a Google account to the application and signs in. After that, events created on either side appear on the other, and edits travel in both directions. The second copies a calendar address in iCal format and pastes it into the application, which then reads that address on a schedule.

The second one is read-only by design. Apple's Calendar calls this subscribing, and its documentation is direct about the consequence: events in a subscribed calendar are controlled by whoever publishes it, and cannot be edited locally. There is no setting that turns a subscription into a two-way connection.

This distinction explains a common complaint. Someone changes an event on the Mac, reloads Google Calendar in a browser, and finds the old time still there. Nothing is broken. The route they set up only runs one way, so there was never a path for the change to travel back. The fix is not to repair the sync but to replace it with the account-based connection.

The reverse mistake is quieter and worth checking too. Subscribing is the right choice for a calendar that only needs to be watched, such as a team roster or a public schedule. Connecting the whole account instead hands a calendar application read and write access to everything in it, which is more than the situation calls for.

What happens on the wire

The two-way connection runs on CalDAV, a published extension of WebDAV for reading and writing calendars on a remote server. Google operates a CalDAV interface, and most calendar applications on the Mac, including Apple's own, connect through it.

Two conditions are non-negotiable. The connection must use HTTPS, and it must authenticate with OAuth 2.0. An attempt to connect over plain HTTP, or with a username and password sent directly, is refused with a 401. That is why adding a Google account opens a browser window instead of asking for a password in a dialog box.

Once connected, the client does not download everything every time. Each calendar carries a tag that changes whenever anything inside it changes, so the client can check that one value and stop if it matches what it saw last time. After the first pass, only what changed comes across. This is why the initial connection is slow on a busy calendar and every subsequent refresh is nearly instant.

One more detail matters for anyone whose setup used to work and stopped. The address of Google's CalDAV endpoint changed, and the older one is no longer supported. An application configured years ago against the old address, and never updated, has no working route.

What arrives automatically and what does not

Adding the account does not bring everything across. What syncs automatically is the set of calendars under My calendars in Google Calendar, plus the birthdays calendar. Anything under Other calendars, which is where shared and subscribed calendars live, stays behind until it is selected individually on Google's sync settings page and saved.

This single fact accounts for a large share of reports that sync is broken. The account connected correctly, the personal calendar appeared, and the team calendar that was the whole point of the exercise did not. Removing and re-adding the account produces exactly the same result, because the account was never the problem.

Work and school accounts add another layer. An administrator sets a ceiling on how far calendars may be shared outside the organisation, and individual settings are clipped to it. If event details show up as busy blocks with no titles, that ceiling is a more likely explanation than anything in the local configuration.

Features that never cross over

Some things stay on Google's side permanently. Google lists three as unavailable in Apple Calendar: email notifications for events, creating a new Google calendar, and room booking.

These are not oversights. The CalDAV specification includes a method for creating a new calendar collection, and Google's interface does not implement it, so a client cannot create a Google calendar. Room and equipment booking is a Google-specific system that sits outside the shared standard entirely. Email notifications are generated by Google's servers and are not part of what the protocol carries.

Tasks are in the same category. The iCalendar format defines a to-do item alongside events, and Google's CalDAV interface does not serve that type. Anyone running tasks alongside meetings in the browser gets a day on the Mac with the tasks missing. Free/busy lookup is also unimplemented, which is why availability checking across accounts tends to live in the browser rather than in a desktop client.

Knowing the boundary saves time. No amount of reconfiguring will surface a Google task in a CalDAV client, so the choice is to keep that part of the workflow in the browser or to pick a tool that fetches it another way. What a given application can and cannot reach is worth checking before installing it, and the scope for this one is set out under Features.

Several accounts means several of everything

Anyone keeping work and personal life in separate Google accounts is not running one sync. Each account gets its own connection, and each connection carries its own settings. The refresh interval is per account. The list of calendars selected for sync is per account. Changing one leaves the other exactly as it was.

That structure produces a confusing symptom: some events update promptly and others lag, on the same Mac, in the same window. It reads as an unreliable connection. It is usually a configuration that was only half finished, because the person changed the setting on the account they happened to have selected and assumed it applied to everything. Three connected accounts means three sets of settings to check, not one.

Invitations behave the same way. An invitation arrives at whichever account it was addressed to, so an account that is not connected produces meetings that simply never appear in the day. When something was missed and the calendar looks clean, an unconnected account is a more common explanation than a sync failure.

There is a related trap for people who route several addresses into one inbox. Mail consolidating in one place does not consolidate calendars. The meeting invitation may be readable in the unified inbox while the event itself lives in a calendar the Mac has no connection to, which is why it shows up in mail but never on the grid.

Where it actually stalls

Four causes cover most of it, and checking them in order matters, because the later ones produce no visible change while an earlier one is still in effect.

Symptom	Likely cause	Where to look
Nothing syncs at all	Delegation is still switched on	Calendar settings, Accounts, Delegation
Personal calendar works, shared one missing	Not selected for sync	Google's sync settings page
Changes appear late	Refresh interval too long	Calendar settings, Accounts, Refresh Calendars
Every event appears twice	Two routes to one calendar	Account connection plus a subscription to the same calendar

Delegation is the one people never guess. Apple Calendar has a delegation feature for viewing someone else's calendar on their behalf, and Google states plainly that turning it off is what makes Google sync start working. A setup that predates the account connection can still have it enabled.

The duplicate case deserves its own note, because it does not present as a sync failure. It presents as clutter. Somebody connects the account, then separately subscribes to the same calendar by URL, and every event now has two boxes. The more accounts in play, the easier this is to do without noticing.

The refresh interval is worth touching last for a specific reason. Shortening it changes nothing when the real cause is delegation or an unselected calendar, so tightening it first produces no feedback and invites more changes on top of a setting that was never the issue. Apple's documentation describes choosing an option from a Refresh Calendars menu on each account, including a push option for accounts whose servers support being told about changes rather than being asked. Picking that where it is offered removes interval tuning from the equation.

Removing the account and adding it again sits below all of this. It does help when the stored credentials have genuinely gone stale, and it is the honest last resort. The cost is that reconnecting discards the local copy and triggers a full initial download, which on a calendar with years of history takes long enough that the first few minutes look like a failure. Anyone reaching for it should do so knowing the wait is expected rather than a sign of a second problem.

When sync is fine and the day still falls apart

A correctly synced calendar can still produce a day that does not work. At that point the problem has moved from the connection to the layout.

Two meetings can have accurate start times, accurate notifications, and no way to get from the first to the second. A view that shows only event blocks hides that until the morning it happens. Whether travel appears as something with shape, rather than as an assumption, is what decides if the collision is visible in advance. The approach to that is described under Travel time.

The other cost is entry. Sync routes do not reduce the number of times an event has to be typed. A commitment made verbally at the end of a meeting still has to be opened, dated, titled and saved later, and when that round trip happens several times a day it starts getting deferred and then forgotten. How many steps that takes differs sharply between applications, and the comparison is in Compared with other calendars.

What to change first

Work out which of the two mechanisms is in use, because that alone eliminates half the advice available. If it is the account connection and something is missing, check delegation, then the sync selection page, then the refresh interval, in that order. Once the connection is settled, the remaining friction is in how the day is laid out and how events get entered, which is the part Caltimate is built around.