Googleカレンダーの同期: how to decide what you need

Deciding how to sync a Google calendar looks like a question about which app to install. It is not. The conditions settle first, and once they are written down the list of workable mechanisms narrows on its own, usually to one or two.

Doing it the other way round costs time twice. An app gets chosen, the arrangement gets built, and then a condition that was never stated turns out to rule it out, and the whole thing gets rebuilt. Four conditions do almost all of the work here: whether writing is required, how much delay is acceptable, which calendars need to arrive locally, and whether an administrator sits above the account. What follows is each condition, what its answer eliminates, and how to record the result so the reasoning survives.

Condition one: is writing required

This is the heaviest of the four and it goes first. If events have to be created on a calendar from the local app, the only mechanism available is an account connection. If reading is enough, two mechanisms stay on the table.

The fastest way to answer it is to look at each calendar and recall whether anything was typed into it during the past 30 days. Calendars with nothing in that window will not acquire new entries later. Even among calendars a person created themselves, the ones receiving actual input are usually one or two, with the rest existing as labels for sorting.

Writing covers more than creating events. Replying to an invitation, shifting the time of a meeting, adding a guest: all of these write back to somebody else's calendar, and none of them travel over a read only route. Anyone whose week is mostly meetings has this condition answered for them by invitations alone.

Condition two: how much delay is acceptable

Google Calendar sync on a Mac is a pull, not a push. The local app asks the server for changes on a schedule it was given, which means the worst case delay is exactly that interval and nothing else.

In Apple Calendar the setting sits in the account preferences, where the refresh frequency for the account is chosen. Left at one hour, an event entered on a phone can take that long to appear on the Mac. In a workplace where meeting times move shortly before they start, this single value decides how usable the arrangement feels.

Shorter intervals cost battery and network, which is irrelevant on a desktop and mildly relevant on a laptop carried all day. Somewhere between 5 and 15 minutes suits most portable setups. The deciding factor is how often last minute changes actually happen, not how fast it would be nice for things to be.

A subscription adds a second layer of delay on top, because the publisher has its own update cycle. Anything that has to be visible to another person the same day rules subscriptions out.

Condition three: which calendars come down

Connecting an account does not bring everything. What arrives automatically is defined.

自動的に同期されるカレンダー: パソコン上の Google カレンダーの [マイカレンダー] セクションに表示されているすべてのカレンダー、誕生日 出典: support.google.com

Calendars shared by other people, and calendars subscribed to from outside sources, are not in that set. Bringing them down requires opening the calendar sync page on the Google side, enabling the ones that are wanted, and saving.

Answering this condition in advance is worth the minute it takes. Enable everything and the sidebar grows to a dozen rows, which turns every morning into an exercise in choosing what to hide. Enable almost nothing and the sidebar stays quiet, at the price of opening the web interface whenever somebody else's schedule needs checking. Which is cheaper depends entirely on how often other people's calendars get consulted: several times a week argues for bringing them down, a few times a month argues against.

Condition four: who administers the account

Personal accounts and accounts issued by an organisation do not offer the same menu. On a managed account, mechanisms can be removed before any choice is made.

The private address is the common casualty. When the integration section of the calendar settings contains no private address, an administrator has disabled it, and the subscription route is simply unavailable.

External sharing has an administrative ceiling as well, with four settings: only free/busy information with details hidden, share all information but outsiders cannot change calendars, share all information and outsiders can change calendars, and share all information with calendar management allowed. If an organisation stops at the second, no arrangement that depends on an outside party editing anything is going to work, regardless of what the sharing dialog offers.

Authentication is constrained too. Connecting an app with nothing but a password no longer functions. For Google Workspace accounts, CalDAV and IMAP access using legacy passwords stopped working on 14 March 2025. Every route in service now runs through a Google sign in screen where access is granted explicitly, which is why instructions written before that date fail at the password prompt.

What each mechanism answers

Condition	Account connection	Private address subscription	Export and import	Web interface only
Create events locally	Yes	No	Yes, but disconnected	Yes
Reply to invitations	Yes	No	No	Yes
Floor on delay	The chosen interval	Interval plus publisher cycle	No updates at all	None
Calendars shared by others	Yes, once enabled	Yes, with the address	Manual	Visible already
Subject to org restrictions	Yes	Yes	Rarely	Rarely

Matching four answers against this table usually leaves one or two columns standing. Two columns is not a problem to be resolved: it means different calendars want different mechanisms, and forcing a single mechanism across all of them makes the arrangement worse rather than tidier. Keeping a write path open on a calendar nobody writes to buys nothing and keeps the possibility of an accidental edit alive.

Write the answers down

Held in the head, these conditions never quite resolve. Written as a table with one row per calendar, the mechanism falls out mechanically.

Four columns are enough: the calendar's name, whether events get created there, whether delay causes problems, and whether it gets looked at daily. Rows answering no to the first are subscription candidates. Rows answering no to the second can take a longer interval. Rows answering no to the third do not need to come down locally at all. Rows answering no to all three do not need to be on the Mac in any form.

The pattern that emerges surprises most people: out of 10 rows, perhaps one or two carry a yes in the first column. The mechanism question only has to be taken seriously for those.

The table also pays off later. Six months on, a calendar sitting on a subscription for reasons nobody remembers becomes a setting nobody dares touch. One line of reasoning per row prevents that.

When the conditions need answering again

Conditions decided once stop matching reality when circumstances change. Three situations call for a fresh pass.

The first is acquiring an account issued by an organisation. An arrangement built on a personal account can fail outright under administrative restrictions, and an arrangement resting on private address subscriptions fails completely if that capability is turned off, since the mechanism disappears rather than degrading.

The second is a change in how often other people's schedules matter. Joining a team means more calendars are worth having locally. Leaving one means the sidebar should shrink again, since rows that are never read still cost attention every time the week is scanned.

The third is a change of machine. A short refresh interval that was free on a desktop becomes noticeable on a laptop carried through a full day. Only the timing condition needs revisiting in that case, and the rest of the arrangement can stand.

A fourth trigger is worth mentioning because it is easy to miss: a calendar changing hands. A roster that used to be read only becomes something you maintain when the person who kept it moves on. The condition for that single row flips from no to yes, and the mechanism for that row has to flip with it. Nothing about the rest of the arrangement needs touching.

What choosing badly actually costs

It helps to know which wrong answers are recoverable and which are not, because that determines how much deliberation each condition deserves.

Getting the timing condition wrong is free to correct. Changing a refresh interval takes seconds and nothing is lost. This condition does not need much thought up front: pick something, live with it, adjust.

Getting the scope condition wrong is also cheap. Enabling or disabling a calendar on the sync page is reversible, and the only cost of having been wrong is a period of a cluttered or an over sparse sidebar.

Getting the write condition wrong costs more in one direction than the other. Choosing a subscription where writing was needed shows up quickly, because an edit fails and the mechanism gets changed. Choosing an account connection where reading was enough shows up never, because nothing complains, and the excess access simply persists. That asymmetry is the argument for defaulting to the lighter mechanism and upgrading rows on demand.

Getting the administration condition wrong is the expensive one, because it is usually discovered at the point of setting something up for another person who is now waiting. Checking whether the private address exists, and what the external sharing ceiling is, takes a minute and belongs before anything is promised to anyone.

Multiple accounts

Separate work and personal accounts mean the conditions get answered twice. The usual shape is that the work account needs writing and the personal one only needs to be visible.

Two arrangements deliver that. The personal calendar can be shared to the work account so that everything appears in one place, or both accounts can be connected to the local app. Sharing takes one setup step but fails if the employer blocks external sharing. Connecting both sidesteps the employer's settings entirely but produces duplicate notifications, which then need a decision about which client is allowed to make noise.

Duplicate notification is a guaranteed side effect of adding accounts, not a bug. The same event opened in a browser, a Mac app, and a phone announces itself three times, and the eventual result is that all three get ignored. Deciding which one rings while the mechanism is being chosen saves untangling notification settings afterwards.

One more consideration belongs to the personal side. An administrator can see the contents of calendars on accounts they manage, whether or not those calendars were deliberately shared. Where a personal calendar holds medical or family entries, sharing it into the work account is the wrong direction, and stacking both accounts locally is the one to take.

What to change first

Write the four answers for each calendar before installing or configuring anything, then set the refresh interval to match the answer for delay rather than leaving the default. Once that is settled, the remaining differences between apps come down to how events get entered and how several calendars read when stacked in one view, which is the ground Caltimate is compared on. The entry side is described in entering events, and platform requirements are listed in FAQ.