Googleカレンダーの共有: how to decide what you need

There is no single thing called calendar sharing in Google Calendar. There are at least five mechanisms wearing the same name: granting access to a named address, publishing a public link, exposing a secret iCal address for subscription, embedding a calendar in a page, and handing out a booking page. Every one of them delivers a calendar to somebody else, and every one of them behaves differently the moment something needs to change.

Comparing them feature by feature does not settle anything, because the differences do not live in a feature list. They live in what happens six months later. Starting from the conditions instead of the mechanisms narrows five options to one in about a minute.

Six conditions, in the order that decides

The conditions are not equally weighted and they are not independent. Two of them determine whether a mechanism is available at all, and the remaining four determine whether living with it will be tolerable.

1. Does the recipient have a Google account
2. Will one individual ever need to be cut off separately
3. Does the recipient need to write, or only read
4. How fast does a change need to reach them
5. Is there an organizational ceiling in the way
6. What will they receive it on

Work top to bottom and stop as soon as the answer is forced. Conditions one and two eliminate mechanisms outright, and eliminating before comparing avoids the common failure of evaluating five options thoroughly and then discovering the chosen one was never viable.

One clarification before running the list. These conditions describe the arrangement, not the person. The same colleague can sit in two different answers at once: address based sharing for the project calendar they help run, and a plain subscription link for the duty roster they only read. Deciding once per person, rather than once per calendar, is what produces the over-granted access that shows up later as a long sharing list.

The value of writing the conditions down is that they can be re-checked later. A decision recorded as "public link, because the contractor has no Google account" can be revisited the moment the contractor gets one. A decision recorded as nothing at all becomes permanent by default.

Conditions one and two do most of the work

Address based sharing is built on the recipient having a Google account, because the grant is made to an email address that resolves to one. No account, no grant. That single fact removes the most controllable mechanism from play for a large share of external contacts.

What remains for accountless recipients is the public URL, the secret iCal address, the embed code, and the booking page. All four work for anyone who can open a link, which is also the reason all four share the same weakness.

That weakness is condition two. With address based sharing, ending one person's access means deleting one row. With any link based mechanism, there is no row. Ending one person's access means resetting the link and reissuing it to everyone else who had it.

Conditions	What is left
Has an account, needs individual revocation	Share with a specific person
No account, revocation can be collective	Secret iCal address, embed code
No account, content is not sensitive	Public URL
Recipient picks their own time	Appointment schedule
Only a handful of events are involved	Guest invitation on the event

A useful test when the table does not obviously resolve: imagine cancelling this arrangement in six months. If the cancellation is deleting a name, take the controllable option. If it is redistributing a new link to everyone, understand that the cost grows with the audience. Below a handful of holders it is trivial. Past twenty, reissuing is something people quietly avoid doing, which means access is never actually withdrawn.

Condition three is a hard fork

If the recipient has to change anything, every link based mechanism is out. Both the secret iCal address and the public URL are read only. A subscriber cannot move an event, cannot accept on the owner's behalf, and cannot add anything. Write access exists in exactly two places: address based sharing, and guest permissions on an individual event.

Within address based sharing, three of the five levels permit writing. The lowest of the three is "Make changes (see private events as free/busy)", and it behaves differently depending on the event: anything marked private stays opaque and immovable even though the level is nominally an editing level.

Your administrator decides if you can share it. Source: support.google.com

The top level, "Make changes and manage sharing", is a different kind of decision from the other four. It carries the ability to share the calendar onward to other people. Granting it means granting the judgement about who else gets access, and once two or three people hold it, reconstructing who granted what becomes guesswork. It belongs with people authorized to make that call, not with people who simply need to be efficient.

When the write requirement covers a countable set of events rather than a calendar, guest permissions on those events are the smaller instrument. Ticking "Modify event" on a recurring meeting hands over that meeting and nothing else.

Recurring events add a wrinkle to that. When a guest with edit rights moves one occurrence, the client asks whether the change applies to this event or to all following events, and the answer sometimes gets chosen quickly and wrongly. A single misclick shifts a standing meeting for everyone on it. Saying explicitly which scope is intended, at the point of handing over the event, costs one sentence and prevents a class of correction that is tedious to undo.

Condition four depends on the receiving side, not the sending side

Propagation speed is not a property of the calendar. It is a property of the mechanism.

Address based sharing puts the same underlying data in front of the other person, so a change is visible essentially at once. A subscription through the secret iCal address works by the recipient's application fetching the feed on a schedule it chooses. Until the next fetch, the recipient is looking at an older copy, and the publisher has no control over the interval. Apple's Calendar on Mac, for example, exposes an auto-refresh setting on subscribed calendars, and whatever is selected there governs how stale the view gets.

This is the condition that decides same day scheduling. Moving a morning meeting by thirty minutes and expecting a subscriber to see it is a poor bet. For anyone who needs to track changes on the day they happen, either grant address based access or put them on the event as a guest so the change reaches them as an update.

Administrator changes are slower still. Google's documentation states that changes can take up to 24 hours, though they typically happen more quickly. That number is worth remembering because it produces false bug reports: an admin adjusts a setting, the affected person checks immediately, sees no difference, and a support thread starts over a change that simply has not landed yet.

Condition five is invisible from the personal settings screen

Google Workspace administrators set an external sharing ceiling before any individual touches anything. Four options exist: only free/busy information with event details hidden, share all information but outsiders cannot change calendars, share all information and outsiders can change calendars, and share all information and allow managing of calendars.

The personal sharing screen does not reflect this. Higher levels remain visible and selectable, and selecting one produces no warning. The result reaches external recipients capped at whatever the ceiling permits, which is why the symptom shows up as a recipient complaint rather than an error message.

For choosing purposes this reorders the process: check the ceiling before designing anything external. The fastest check is empirical. Share a calendar with one address outside the organization and look at what actually arrives. If detail is stripped, the ceiling is set to free/busy, and no external mechanism based on address sharing will ever deliver more.

Under a low ceiling, the realistic external options are the ones that do not run through calendar sharing at all: a separate calendar published by link, or a booking page exposing only the hours meant to be exposed.

Condition six is about their screen, not yours

The last condition is the recipient's environment, and it is the one most often skipped because it is not visible from the sender's side.

A recipient on Google Calendar receives address based sharing most cleanly. A recipient on Outlook or Apple Calendar is usually better served by the secret iCal address, since subscription is the native path on those clients. A recipient who only ever uses a phone will find a long list of shared calendars unusable regardless of mechanism.

Notifications belong here too. Shared calendars can generate alerts on the recipient's side as events are added, and a high churn calendar granted this way produces a stream of notifications that gets muted within a week. A read only subscription is quieter and therefore tends to survive longer in actual use.

There is also a volume question nobody asks. Every calendar shared with a person lengthens their sidebar. Sharing four calendars with one colleague means four entries competing with their own. Sharing only what they need to see daily, and handing over a link for the rest, keeps the arrangement usable.

How many accounts and calendars a Mac client can hold legibly in one view, and how it distinguishes writable calendars from read only subscriptions, is covered under Features. The practical differences between the available approaches are laid out in Compared with other calendars.

Conditions change, and the choice changes with them

The six conditions are not permanent facts. A contractor opens a Google account. A project grows to the point where somebody else has to move the meetings. An administrator adjusts the external ceiling after a security review. Any one of those flips a condition, and a mechanism chosen correctly last year can be the wrong one today without anybody noticing, because nothing about it will visibly break.

This is the argument for recording the reason rather than only the result. A note in the calendar description saying which condition forced the choice turns a future review into a single comparison: is that condition still true. Without it, revisiting the decision means reconstructing the whole analysis from scratch, which in practice means it never gets revisited at all.

Two moments are worth treating as automatic triggers. One is anybody joining or leaving the group of recipients, since that is when revocation cost becomes real rather than theoretical. The other is a change of tooling on the receiving side, since condition six is the only one that lives entirely on somebody else's machine and therefore never announces itself.

What to change first

Take the one arrangement causing the most friction right now and run it down the six conditions in order, stopping at the first one that forces an answer. Record the reason in the calendar's description field so the decision can be revisited when the condition changes. Whatever remains after that is entry speed rather than access, which is the side Caltimate is built around.