Googleカレンダーの共有: what it does and where it breaks down

Sharing a Google Calendar does not send anything. It grants a reference. The calendar stays where it is, keeps filling up on the owner's side, and the person it was shared with sees each new event appear without anything being sent again. Revoking the access removes the calendar from their list, and no residue stays behind on their machine.

That single property explains most of what surprises people later. A file, once sent, is gone. A shared calendar is a live window that can be widened, narrowed or closed at any time, and that also means the thing being granted is not "the events currently in it" but "whatever ends up in it". The distinction becomes concrete the first time a personal appointment lands on a calendar that was shared for work reasons.

What a share actually creates

After sharing, a new entry appears in the recipient's calendar list. They can turn it on or off, give it a colour, and overlay it on their own week. Ownership does not move. Events added by the owner show up for them, events deleted by the owner disappear for them, and nothing about their copy is independent, because there is no copy.

Access can be withdrawn. Removing someone from the sharing list removes the calendar from their list too, along with everything it contained. There is no cached version left to worry about.

One exception is worth stating plainly. If the recipient had edit rights and used them, the edits stay. Revoking access stops further changes, it does not reverse changes already made. Anyone who has watched a recurring meeting get dragged two hours later by someone with edit rights has met this distinction the hard way.

The five levels, and what each one withholds

Google offers five access levels, and the relevant question about each is not what it reveals but what it keeps back.

Level	What the recipient gets
See only free/busy	Occupied time blocks, no titles or details
See all event details	Titles, times, places, descriptions
Make changes to events	Editing, with private events shown as free/busy
Make changes and see details	Editing, plus visibility of who else it is shared with
Make changes and manage sharing	Full control, including granting access to others

The bottom level is the one most often misread. Google describes it as: "People can only find out when you're busy on your calendar." Busy means the block is occupied. The title, the location, the attendees and the description do not travel. What the recipient sees is a coloured rectangle with nothing written in it.

Reading that correctly changes how the levels get chosen. For the purpose of finding a time when two people are both free, free/busy is sufficient and nothing above it adds anything. Detail access is for a different job: someone acting on the calendar's behalf, or two people running the same project. Starting at the bottom and moving up only when something is genuinely missing is the habit that prevents over-sharing.

Primary calendars behave differently from the ones added later

Every Google account arrives with one primary calendar, named after the address itself. Additional calendars can be created alongside it for whatever purposes make sense.

The two are not interchangeable when it comes to sharing. A primary calendar cannot be deleted and cannot be handed to someone else, because it is bound to the account. A calendar created later can be given away entirely, including the right to manage its sharing, and it can be deleted when the project it served is over.

The practical consequence is worth acting on early. Anything meant to be shared belongs on a separate calendar from the start. Sharing a primary calendar means sharing everything that address ever receives, dental appointments included, and the usual response to that discovery is a long afternoon of moving events between calendars one at a time.

Hiding a single event on a shared calendar

Sharing a whole calendar eventually produces the situation where one event on it should not be visible. A medical appointment, an interview, something at home. Lowering the access level for the whole calendar to solve one event is the wrong size of fix, and the actual control sits on the event rather than on the calendar.

Each event carries a visibility setting: keep the calendar's default, or mark the event private. A private event on a shared calendar shows the recipient that the time is occupied while withholding what it is. The access level named "make changes, with private events shown as free/busy" exists precisely to describe this behaviour.

So the design has two layers. The calendar level sets the general rule, and individual events can drop below it as exceptions. Using both layers removes most of the pressure to lower a whole calendar because of one entry, which is how calendars end up shared at a level too low to be useful for anything.

The failure mode runs the other way too. An event that was never marked private is visible at whatever level the calendar was shared at, and nobody is notified that it became visible. For anyone who genuinely mixes personal entries into a work calendar, deciding visibility at the moment of creation is the only approach that scales. Auditing months of history afterwards is not a task that gets finished.

Failure one: the invitation nobody accepted

On the owner's side, adding someone to the sharing list looks like completion. Their name is there, the level is set, the dialog closes. On the recipient's side, nothing has happened yet. Google states the remaining step directly: the recipient receives an email, and "to add your calendar, they need to click the link in the email."

Nothing in the owner's interface distinguishes "shared and accepted" from "shared and ignored", which is why this failure survives so long. Asking the recipient is faster than any amount of re-checking settings. Invitation mail landing in a spam folder is common enough to be the first thing to rule out.

A near relative of this problem is the wrong address. Plenty of people hold a work account and a personal one and are signed into whichever they used last. A calendar shared to one address will never appear while they are looking at the other, and saying which address it went to removes the ambiguity immediately.

Failure two: an organizational ceiling clipping the result

In a Google Workspace organization, an administrator can cap what leaves the company. There are four settings, running from free/busy only with event details hidden, through allowing full information without outside edits, through allowing outside edits, to allowing outside management.

The cap outranks the individual. Someone can select "see all event details" for an external partner, see the setting saved, and the partner will still see only free/busy if that is where the ceiling sits. The owner's screen reports success, because the owner's setting was in fact stored. It is simply being clipped on the way out.

When an external recipient reports that a calendar looks empty, the organization's own sharing policy is the place to look first. No amount of inspection inside a personal settings page will explain it.

Failure three: group membership drifting

Sharing to a group instead of to individuals is the lighter option for teams with turnover. A new hire added to the group gains the calendar without anyone touching the sharing list.

The same mechanism runs in the other direction. Access expands whenever the group expands, whether or not anyone considered that calendar at the time. Groups that were created for one purpose and reused for another carry their new members along with them. The sharing list, meanwhile, shows one line with a group name on it, so the list stops describing who actually has access.

Group sharing is worth using. It just needs to come with the habit of opening the membership occasionally, because the calendar's own screens will not show the drift.

Departures make the same point from the other side. Access granted to a named person is removed from the calendar's own sharing screen. Access granted through a group is removed in the group, and the calendar screen never changes at all. A calendar whose sharing list mixes individual names and group names is the one where somebody eventually keeps access after leaving, not because anyone decided it, but because the two removal paths live in different places.

Failure four: a subscribed URL treated as a share

There is a second mechanism that also gets called sharing. Under the calendar's integration settings sits a secret address in iCal format, and handing that address over lets someone subscribe from their own application.

What arrives on the other end is read only. It cannot be written to, it refreshes on whatever schedule the subscribing application uses rather than instantly, and anyone holding the address can read the calendar. Google's instruction on that last point is blunt: "Only you should know the Secret Address for your calendar. Do not share this address with other people." A Reset control issues a new address when one gets loose.

Most reports of "the shared calendar is out of date on their side" turn out to be subscriptions rather than shares. Access-level sharing propagates immediately. A subscription propagates on the subscriber's interval. Establishing which of the two is in play should precede any attempt to fix it, since one of them has nothing to fix.

What this looks like on a Mac

Once several calendars are shared inward, the next problem is not permissions but density. Three personal calendars, four shared ones and two subscriptions produce a week view where the colours stop meaning anything.

The lever here is how quickly visibility can be changed: team calendars visible before a meeting, personal work visible after it. That round trip, done twenty times a day, is what separates a workable setup from an unreadable one, and it is the part Features is organised around. Comparing how different applications handle the overlay is covered in Compared with other calendars.

Duplicate events belong in the same category. Being a guest on a meeting while also having the organizer's calendar shared produces two bars for one event. Nothing is broken; the same event is arriving by two routes. Hiding one of the two calendars resolves it, and Entering events covers the input side of keeping a calendar tidy in the first place.

What to change first

Work through the four failure points in order before touching any access level: acceptance, organizational ceiling, group membership, and whether the thing in question is a share or a subscription. That sequence accounts for the large majority of cases.

What remains after that is a display problem rather than a permission one, which is a question of what the calendar sits in: see Caltimate.