Googleカレンダーの権限: what it does and where it breaks down

A calendar gets shared with a colleague, and a week later they say the week looks empty. Or the opposite happens: everything is visible, they were asked to move one meeting, and the meeting will not move. Both of those are the same kind of problem, and neither is a bug.

Google Calendar permission is not a switch with an on position and an off position. It is five named levels, applied at the calendar level, sitting underneath a second and completely separate set of controls applied at the event level, sitting underneath an organization-wide ceiling that a person cannot see from their own settings screen. Three layers, and the symptom rarely announces which one produced it. What follows is what each layer actually controls, and how to work backwards from what is on screen to the setting responsible for it.

Permission is a list of five settings, not a switch

When a calendar is shared with a specific person or group, Google's help documentation names five options, and the exact wording matters because each phrase describes a real boundary.

Level	What the other person can do
See only free/busy (hide details)	Find out when the calendar is busy. Names and details of events and tasks stay hidden
See event details	Find all details: event names, times, places, descriptions
Make changes (see private events as free/busy)	Edit non-private events. Private events stay opaque
Make changes and see event details	Edit events, and find who else the calendar is shared with
Make changes and manage sharing	Full control of events and tasks that have a start and end time, plus the ability to share the calendar with other people

Read down that list and a pattern appears. The first two levels answer a question about reading. The last three answer a question about writing. The jump between the second and the third is the largest single step in the entire system, because it is the point where another person gains the ability to change what is on the calendar.

The lowest level deserves more use than it gets. For a person whose real question is "is this hour open", free/busy is the complete answer, and it leaks nothing: no client names in meeting titles, no addresses, no notes typed into the description field two years ago. The level above it gets selected instead because scheduling conversations feel easier when details are visible, and that convenience is then granted permanently, retroactively, across every event the calendar has ever held.

The third level is where most of the confusion sits

"Make changes (see private events as free/busy)" is the level that produces support questions, because it behaves in two different ways depending on the event.

For an ordinary event, this level works exactly as expected. The other person opens it, changes the time, saves, and the change appears everywhere. For an event marked private, the same person sees a block with no details, and cannot edit it. Google's documentation adds one more detail that is easy to miss: if a private event is set to Busy, it shows as a busy block with no event details, and if a private event is set to Free, it does not appear on the calendar at all.

That second case is worth sitting with. An event can be present on a calendar, granted to someone at an editing level, and still be invisible to them. Nothing on screen indicates that anything is being hidden. A colleague who has been asked to keep a week clear can do so honestly and still schedule over something.

This is the mechanism behind the most common scheduling failure in a shared calendar: an assistant or a teammate has been given editing access, moves what they can find, and leaves a handful of blocks untouched because those blocks were never visible. The fix is not more permission. It is deciding whether those particular events should be private at all, given that somebody has been asked to manage the calendar around them.

Calendar permission and event permission are two separate systems

The five levels above apply to a calendar. There is a second set of controls that applies to a single event, set when the event is created, and the two do not talk to each other.

On an individual event, guests can be allowed to modify the event, to invite others, and to see the guest list. Each is a separate toggle. These grants belong to the event and travel with it, regardless of how the underlying calendar has been shared.

The practical consequence is that contradictory-looking states are normal rather than broken:

• A calendar shared at free/busy still shows full detail of one specific meeting to somebody invited to it as a guest
• A calendar shared at "See event details" still hides the guest list of a meeting the viewer was never invited to
• A person removed from a calendar's sharing list still sees every meeting they were individually invited to

Knowing that the layers are independent converts a vague problem into a specific one. If every event on a calendar behaves a certain way, the calendar-level setting is responsible. If one event behaves differently from the rest, the event is responsible, and the calendar setting can be left alone.

An administrator ceiling sits above whatever a person chooses

On a Google Workspace account, a third layer exists that is invisible from a personal settings screen. An administrator sets how far calendars may be shared outside the organization, choosing one of four ceilings: only free/busy information with event details hidden, share all information but outsiders cannot change calendars, share all information and outsiders can change calendars, or share all information and allow managing of calendars.

A separate setting governs the default inside the organization: no sharing, only free/busy information, or share all information. That internal default is why a new hire can find that colleagues already see the contents of a calendar nobody deliberately shared. It was never a personal choice. It was the default the organization was set up with.

The ceiling is the part that produces the most frustrating symptom, because personal settings appear to accept a change that then has no effect. A person selects "Make changes and see event details" for an external client, saves, and the client still reports seeing gray blocks. Nothing is wrong with the personal setting. It is simply being clipped by the organization's external sharing level on its way out.

There is a timing element too. Google notes that administrator-side changes can take up to 24 hours to apply, though they usually take effect much faster. Personal settings changed during that window make it genuinely hard to tell which adjustment produced the eventual result.

The secret address is outside the permission model entirely

The calendar settings screen offers a secret address in iCal format, and it is tempting to treat it as a sixth, easier sharing option. It is not part of the same system.

The five levels are grants to identified accounts, which means each one can be withdrawn individually. The secret address is a link, and a link has no idea who is holding it. Google's guidance on this is direct: do not share the secret address with other people. Anyone who has the address can read the calendar, and the only way to withdraw access from one holder is to reset the address, which withdraws it from everyone at once and requires redistributing the new one.

It is also read only. Nothing subscribed through that address can write back. That makes it genuinely useful for publishing a schedule to an audience that has no account, and genuinely unsuitable for anything involving a person who might later leave a project.

The format itself, iCalendar, is defined in a public specification and carries no concept of permission at all. It describes events and their times. Every access decision is made by Google before the file is served, which is exactly why the link, once copied, is no longer under anyone's control.

Reading a symptom back to the layer that caused it

Most calendar permission troubleshooting can be resolved by asking one question first: does this affect everything, or one thing?

What is happening	Where to look
Every event appears as a blank block	Calendar level is free/busy, or the organization's external ceiling
Everything is visible, nothing can be edited	Calendar level stopped at "See event details"
Most events are editable, a few are not	Calendar level three, and those events are private
One event shows full detail on an otherwise hidden calendar	That person is a guest on that event
A person nobody remembers adding has access	Somebody with the top level shared it onward
The setting saved but nothing changed externally	The administrator ceiling, or the 24 hour propagation window

Two rows on that table deserve particular attention. The one about onward sharing is the reason the top level should be treated as a transfer of judgment rather than a generous version of the level below it: granting it hands over the decision of who else may see the calendar. The row about propagation is the reason a setting should be changed once and then left alone for a while, rather than adjusted repeatedly during the window where nothing would have appeared to change anyway.

Where five levels stop being enough

The five levels are coarse by design, and some perfectly reasonable requests have no matching setting.

"Let this person edit one specific project's meetings" has no calendar-level answer. The workable approach is a separate calendar for that project, shared at an editing level, with everything else left where it is. Splitting by how public a set of events needs to be, rather than by who is asking this week, keeps the number of calendars from growing every time a new person appears.

"Let this person see the free hours but not the meeting titles, except for client meetings" also has no single setting. It is two calendars again.

The pattern is consistent: when a permission requirement cannot be expressed in one level, the requirement is really about a subset of events, and subsets are expressed as calendars rather than as finer permissions. A desktop client that keeps several calendars legible side by side matters more once this split has happened, since the number of calendars in play goes up rather than down. Which accounts and calendars a Mac client can hold at once is covered under Features, and the differences between the available approaches are laid out in Compared with other calendars.

Permission also has nothing to say about the cost of entering an event in the first place. A correctly shared calendar still takes the same number of steps to add a meeting to, and picking the right calendar from a list is one of those steps. Entering events covers how that step can be shortened.

What to change first

Open the sharing list on whichever calendar has the most names on it, and move anyone whose real question is availability down to free/busy. Then check whether any event somebody has been asked to manage is marked private, because that single flag explains more scheduling failures than any other setting. What is left after those two passes is a speed problem rather than an access problem, and Caltimate is built around the speed side.