Googleカレンダーの共有 alternatives: what you can drop

Nobody goes looking for an alternative to calendar sharing because sharing stopped working. They go looking because the sharing list got long. A contractor from a project that ended in spring is still on it. Someone who left the company last year is still on it. Two people are on it twice, once by address and once through a subscription URL that was pasted into a chat thread and forgotten.

Calendar sharing has no expiry and no review step. It accumulates. The way out is not a different app, it is noticing that the word sharing is being used for four different jobs, and that three of those jobs have a smaller tool that fits them better.

Sort the list by what each share was actually for

Open the sharing list on the busiest calendar and read down the names. For each one, answer a single question: what was this person supposed to be able to do?

There are only three possible answers. Find out when this calendar is busy. Read what the events say. Change the events. That is the whole range, and the important thing is that Google Calendar expresses all three on one scale rather than three separate controls. The five levels run from "See only free/busy (hide details)" at the bottom, through "See event details", "Make changes (see private events as free/busy)", and "Make changes and see event details", up to "Make changes and manage sharing" at the top.

One scale for three jobs means the settings get rounded up. A person who only ever needed to know whether Thursday afternoon was open ends up at a level where every client name in every meeting title is legible, because that level was easier to reason about at the moment of granting it. Multiply that by a few years of contractors and the list stops being a set of decisions and becomes sediment.

Sorting by intent, rather than by person, is what makes the next four sections usable. Availability goes to a booking page. Visibility goes to a URL. Editing often goes to the event rather than the calendar. And a surprising share of the list goes nowhere at all, because the reason it existed is over.

Availability requests belong on a booking page

The most common reason a calendar gets shared outside a company is a scheduling negotiation: someone needs to find an open hour. Granting standing access to a calendar to settle a single meeting is a large, permanent answer to a small, temporary question.

An appointment schedule answers it instead. It publishes a set of bookable slots as one link. The person opening that link picks a slot. They are not looking at the calendar, so event titles, locations and descriptions never leave. What they see is the title and description written into the booking page itself, and Google's documentation is explicit that this title is visible to anyone holding the link.

The second advantage is that the other side needs no account. Address based sharing requires a Google account on the receiving end, which rules it out for a large share of external contacts before any permission question is even reached. A booking link works for anyone who can open a web page.

The limit worth knowing before committing: Google states that some appointment schedule features require an eligible Google Workspace or Google One subscription. Basic booking works without one. Anyone whose scheduling volume justifies multiple distinct booking pages, payments, or finer confirmation settings will hit the subscription boundary eventually. Building one page first and measuring how much back and forth disappears is the cheaper order to do this in.

Visibility requests belong on a read only URL

If nobody on the other side will ever need to change an event, the sharing list is the wrong mechanism entirely. Near the bottom of a calendar's settings page sit three outputs: a secret address in iCal format, a public URL, and an embed code. Any of them delivers the calendar without adding a person to the sharing list.

The secret address is read only and works for anyone holding it, which makes it the natural fit for contractors, clients on other platforms, and anyone without a Google account. The trade-offs are real and should be stated plainly before choosing it:

• Revocation is all or nothing. A single holder cannot be removed. Cutting off one person means resetting the address and redistributing it to everyone else
• Nothing can be written back. The subscription is one directional
• Updates are not immediate. The receiving application decides how often it re-fetches, and that interval is outside the publisher's control

Those three conditions describe a stable, low churn audience. A rotating duty roster published to a partner company fits. A colleague who might leave the team next quarter does not, because the day they leave is the day the address has to be reset for everyone.

A practical habit: reset the secret address once a year on a fixed date and redistribute. Nobody keeps a record of who received it, so the only way to keep the audience bounded is to expire it on a schedule.

Editing requests sometimes fit on the event, not the calendar

Before granting write access to an entire calendar, count the events that actually need to move. If the answer is "the Monday standup and any travel", the calendar is far more access than the situation calls for.

Adding someone as a guest and ticking "Modify event" on that event gives them exactly that event. It operates independently of calendar level sharing, so the underlying calendar can stay at free/busy or stay unshared entirely, and the guest still sees the title, location and description of the event they were invited to, and can change its time.

Withdrawal is equally narrow. Remove the guest and the access to that event ends. Nothing has to be reset, redistributed, or explained to anyone else.

This stops scaling at some point. Sending individual invitations to a person who fields dozens of schedule changes a month is more work than granting calendar access once. A rough line: past roughly ten invitations a month to the same person, calendar level sharing costs less effort overall.

One detail that gets skipped. The event guest controls include "Invite others" and "See guest list" alongside "Modify event". If the request was only about moving a time, leaving the other two off removes one path by which an attendee list travels somewhere unintended.

Splitting the calendar shrinks the question

Sharing is granted per calendar. When work, personal appointments, interviews and focus blocks all live on one calendar, every possible setting is either too generous or too restrictive, because the unit being shared is wrong.

Carving out a second calendar fixes the unit. A calendar holding only team meetings and deadlines can be shared at full detail without any hesitation, while the main calendar stays private and never needs event by event privacy flags.

This matters most across organizational boundaries. In Google Workspace, an administrator sets a ceiling on external sharing before any individual chooses anything. The four options are: 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.

An individual cannot select above that ceiling. When an external contact reports seeing only busy blocks despite being granted detail access, the ceiling is the explanation and the personal settings screen gives no indication of it. Administrator side changes also take time to propagate: Google's guidance says changes can take up to 24 hours, though usually less. Checking the other person's screen five minutes after an admin change and concluding something is broken leads to a long investigation of a problem that does not exist.

Four tests for a share that can simply be deleted

Some of the list needs no replacement at all. Any entry matching one of these can go:

• The person has left the organization. Departure does not revoke anything automatically
• The project has ended. A share granted for a piece of work outlives the work indefinitely
• The relationship only needs to run one way. Mutual sharing is often set up reflexively when only one direction was ever used
• The same calendar reaches the same person twice, once through the sharing list and once through a subscription URL

The review itself takes minutes. Open each calendar's settings, read the names under the people list, and delete any name whose current relevance cannot be stated out loud. If removing one turns out to be wrong, that person will say so. Silence means it was not being used.

The reason this never happens on its own is that no business process creates an occasion for it. Putting fifteen minutes on the calendar once a quarter is enough to keep the list from becoming unreadable. In organizations with regular turnover, adding one line to the offboarding checklist is more reliable than relying on the review.

When a share is being replaced rather than deleted, hand over the new entrance before closing the old one. Cutting access silently generates a support question that comes straight back.

There is one category that resists all four tests: the share granted to a person who is still around, on a project that is still running, but who has not opened the calendar in a year. Access logs for calendar viewing are not available to an individual account holder, so there is no way to confirm this from the settings screen. The practical substitute is to ask. A short message saying the calendar is being tidied and asking whether the share is still needed resolves it in one exchange, and the answer is no more often than expected.

What is left once the list is short

Reducing what goes out increases what comes in. Work and personal accounts, internal and external calendars, and a handful of read only subscriptions all end up stacked in one view, and the question shifts from who can see this to which of these can be written to. How many accounts a Mac client can hold in a single view, and how read only subscriptions behave inside it, is covered under Features.

Entry speed is a separate cost that survives any amount of sharing cleanup. Choosing the right writable calendar before typing a title is a step that repeats on every single event, and shortening it is covered in Entering events.

Booking pages introduce one thing to watch. Slots are published without regard to what sits on either side of them, so travel has to be built into the slot definition rather than discovered afterwards. Travel time covers how to account for that.

What to change first

Read the sharing list on the calendar with the most names and delete every entry that fails the four tests above. Then move anyone whose real question was availability onto a booking page, and anyone who only reads onto the secret address. What remains is a short list of people who genuinely need write access, and the remaining cost is entry speed rather than access, which is what Caltimate is built around.