Googleカレンダーの同期: what the free tier covers

Looking for the price of Google Calendar sync produces a pricing page with no line item for sync on it. The absence is the answer. Reading and writing Google Calendar events from another application costs nothing, on a free personal account, with no cap that a payment would lift.

That leaves a more useful question. Money does turn up in conversations about calendar sync, repeatedly, and it turns up in four distinct places that have nothing to do with each other. Treating them as one budget is why the decision feels unresolvable. Separating them takes a few minutes and usually reveals that only one of the four is relevant to the situation at hand.

The connection itself is free, with no meter on it

Google publishes an interface for other applications to read and write its calendars, and there is no charge for using it. A free Google account is sufficient. Signing in from a calendar application on the Mac establishes a two-way connection, and events can be created and edited from either side.

The free tier is wider than people expect. It includes creating multiple calendars and selecting each one individually for sync, publishing any calendar as a read-only address in iCal format for other applications to subscribe to, pulling down calendars that other people have shared, and connecting the same account to a Mac, a phone and a tablet at the same time.

There is no device limit that a payment removes, and no calendar count that a payment raises. Connecting one machine and connecting five produce the same bill, which is none.

This is worth stating plainly because of how often a stalled sync gets treated as a billing problem. It never is. A calendar that will not appear, a change that will not propagate, an event that shows up twice: all of those are configuration, and a subscription changes none of them.

Place one: Google Workspace

A business subscription costs money, but what it buys is an administrator, not a connection.

The prices published for Japan are per user per month, before tax: 800 yen for Business Starter, 1,600 yen for Business Standard and 2,500 yen for Business Plus, with Enterprise quoted on request. An annual commitment is listed as saving 16 percent. As of September 2026 a limited promotional discount on the first three months is also shown, running until 25 December 2026.

What that adds, in calendar terms, is control and Google-specific systems. An administrator can cap how far calendars may be shared outside the organisation and set the default for sharing inside it. Meeting rooms and equipment become bookable resource calendars, which do not exist on the free side at all.

What it does not add is more important for this question. Sync does not get faster. The number of calendars that reach the Mac does not change. The inability to create a Google calendar from a desktop client does not change, because that is a limitation of the protocol implementation rather than of the plan. For an individual whose sync is slow or incomplete, this monthly figure buys nothing that addresses it.

Place two: two-way sync between separate accounts

There is one genuine gap in the free tier, and it is narrow.

Google's own tools cover sharing a calendar with someone and letting them view or edit it. What they do not cover is continuously copying events from a calendar in one account into a different calendar in another account. The common case is a person with a work account and a personal account who wants work commitments to appear as busy time on the personal side, as real events rather than as a shared calendar.

Third-party services exist for this, and they charge, generally monthly. Pricing varies enough that a single figure would be misleading, but two things are worth checking before the price. The first is that these services see the contents of the calendars they connect, which means meeting titles pass through a third party's servers. That alone ends the discussion under some employers' policies. The second is how the service is tiered, since limits are often set by number of connected accounts or events, and adding one more account can move the cost to the next step.

There is also a free approximation worth trying first. Subscribing to one calendar read-only from the other application overlays its busy time without any payment. If the real requirement is seeing the conflict rather than editing from both sides, that is enough, and the subscription costs nothing. How many accounts a single view can hold is set out under Features.

Place three: the application on the Mac

This is the place where a payment is most often actually warranted, and it is worth being precise about what is being bought.

Calendar applications for the Mac are sold two ways: a recurring subscription, or a single purchase that keeps working. Which is cheaper depends on how many years the tool stays in use, and the crossover typically falls somewhere between the second and third year. Planning to switch within a year favours a subscription. Expecting to use the same tool for five favours a purchase.

The thing being paid for is not sync. Every application here reads the same events through the same interface, so the connection is identical across all of them. The differences are downstream: how a day is laid out, how many steps it takes to enter one event, whether several accounts fit in one view, whether travel between locations has any representation.

The useful test is frequency rather than feature count. Entering events happens every working day, several times, so a saving of a few seconds per event compounds into something visible within a month, while a feature used twice a year does not. That is the reasoning behind entry methods that accept spoken or typed natural language rather than a form. The approach is described under Entering events, and the terms and pricing structure are under Buy.

Place four: building the connection yourself

Anyone wiring up their own integration against Google Calendar pays nothing today, but the limits are published and a change to how they are billed has been announced.

The documented quotas are 10,000 requests per minute per project and 600 requests per minute per user per project. Separately, a daily threshold of 1,000,000 requests per project defines what a project may use in 24 hours before billing applies, and Google states explicitly that usage below that threshold incurs no additional charge.

The part worth noting is the direction of travel. Google says details on billing will be announced later in 2026, at least 90 days before any change takes effect. Projects created on or after 1 May 2026 fall under the new quotas, while projects that used the API between November 2025 and April 2026 continue on their previous allocation.

For anyone using an off-the-shelf calendar application, this sits with the developer rather than the user, and it will not appear on a personal bill. It is still relevant when choosing a tool intended to last several years, since a cost that arrives upstream eventually arrives downstream.

There is a practical consequence for self-built integrations regardless of billing. The per-minute limits are calculated on a sliding window, and a burst above the allowance is rate-limited in the following window so the average stays inside the quota. That makes naive polling loops expensive in latency even while they remain free in money, and it is the reason the documentation recommends exponential backoff rather than immediate retries. Anything that reads a calendar on a timer should also be using the change tag the protocol provides, which lets a client confirm nothing has changed without downloading events at all.

The same limits explain a behaviour that looks like a fault in finished products. A client that has just been connected pulls the entire history once and is comparatively slow, then becomes near-instant afterwards because it is only asking whether anything changed. That shape is a consequence of the quota design rather than of the application.

Symptoms a payment will not fix

Before pricing anything, rule out the problems that money does not touch. Four account for most of what gets reported as a sync failure.

Symptom	Actual cause	Cost to fix
Shared calendar missing	Not selected on Google's sync settings page	None
Events appear twice	Two routes to the same calendar	None
Changes arrive late	Refresh interval on the client	None
Cannot create a Google calendar locally	Protocol method not implemented	Not purchasable

Only calendars under My calendars, plus birthdays, sync automatically, so anything shared has to be switched on individually regardless of plan. Duplicates come from an account connection plus a subscription to the same calendar. Refresh intervals belong to the client, not to Google. And no edition of anything enables creating a Google calendar from a desktop application.

Work and school accounts add one more. The ceiling on external sharing belongs to an administrator, and paying for something personally does not raise it. Event details arriving as unlabelled busy blocks is an organisational setting, not a tier.

Free changes worth making before spending anything

Two adjustments cost nothing and frequently remove the reason for spending in the first place.

The first is pulling down fewer calendars. Every calendar added to the local view adds another colour, and past a certain density personal commitments stop standing out against holidays, birthdays, team rotas and subscribed feeds. The instinct at that point is to buy a better application, but a crowded view stays crowded after the purchase. Keeping the calendars opened several times a week and leaving monthly ones in the browser changes the density immediately, and anything removed can be added back in seconds.

The second is removing duplicate routes. An account connection plus a subscription to a calendar inside that account puts two boxes on every event in it. Someone in that state reasonably concludes they have too many commitments, when what they have is too many paths to the same commitment. Counting calendars in the sidebar and checking whether any appears twice takes a minute.

There is a third worth naming because it is invisible in the interface. Notifications frequently fire from Google, from the desktop application and from a phone for one meeting. That produces a sense that the calendar is overwhelming, which again reads as a reason to change tools, when the fix is choosing one source and switching off the others.

After those three, whatever friction remains is real, and it is usually one of two things: the day is hard to read, or entering an event takes too many steps. Both are client-side, and both have an honest price attached.

What to change first

Confirm the problem is not in the four rows above, since all of those are free to fix and none of them responds to a subscription. If what remains is that the day is hard to read or that entering events takes too many steps, that is a client-side question with a real price attached, and the comparison sits in Compared with other calendars alongside what Caltimate charges for it.