Googleカレンダーの権限 alternatives: what you can drop

When a calendar needs to be shared with a colleague, the option at the bottom of the list gets picked more often than any other. It is the one that makes sure the other person will not be blocked by anything. It also hands them the right to share that calendar onward to people who were never part of the conversation.

The same pattern repeats one layer down. A calendar app asks for access, the consent screen appears, and the button gets pressed without reading which of the available scopes was actually requested. And one layer below that, macOS asks whether the app may touch calendars at all, and that answer is stored separately from the Google one.

Three layers, three separate grants, and in most cases the top option in each is more than the job requires. What follows is what can be handed over instead at each layer, and where substitution stops working.

Five levels, and no sixth

Google Calendar offers five sharing levels for a person: see only free/busy with details hidden, see event details, make changes with private events shown as free/busy, make changes and see event details, and make changes plus manage sharing. Five levels still means there is no level that matches any particular job exactly. Every choice is a rounding decision, and the question is which direction to round.

The third one is the substitute most people never notice, because its name describes a mechanism rather than a use. It grants editing while keeping anything marked private out of view: a private event marked Busy appears as a block with no details, and a private event marked Free does not appear at all. For the common case of handing scheduling work to somebody without handing over the contents of a calendar, that level is the substitution, and it sits in the list already.

The lightest level is more useful than its position at the bottom of the list suggests. Google's help text describes it as showing the time blocks where something exists, without the name or the details of what that something is. For a person whose actual question is "can this hour be booked", that is the complete answer. The reason the level above it gets chosen instead is usually unstated: details make the scheduling conversation easier, so details get granted, permanently, for every event that has ever existed on that calendar.

The second thing worth knowing about sharing levels is where the grant lives afterwards. It appears in the other person's calendar list and stays there until somebody removes it. Projects end, people change teams, contractors finish, and the grant persists through all of it because removing it is nobody's job. Choosing a lower level is partly a decision about what happens on the day everyone forgets.

What replaces the top sharing level

The highest level is genuinely required in two situations: when somebody is acting as the owner of that calendar, and when a calendar is being handed over permanently. Everything else that gets described as "they need full access" turns out to be the level below.

The difference between the top two levels is two capabilities, not a general sense of power. The top level can add other people to the calendar, and can open the sharing settings. Creating events, moving them, editing details, deleting them: all of that exists one level down. If the request was "please book meetings for me", the level below is the whole answer.

There is a narrower substitute again. When the work concerns specific meetings rather than a calendar, the person can be added to those events as a guest, and the per event guest permissions decide what they may do: modify the event, invite others, see the guest list. Each toggles independently. Calendar level sharing answers what a person may do in general. Guest permissions answer what a person may do about one meeting, and they expire on their own when the meeting is over.

The actual need	What usually gets granted	What is enough
Know when the hours are free	See all event details	See only free/busy
Book meetings on someone's behalf	Make changes and manage sharing	Make changes to events
Fix the time on one meeting	Make changes to events	Guest permission on that event
Publish a schedule as a reference	See all event details	A public or secret calendar URL

What replaces full detail visibility

Granting detail visibility is not a decision about this week. It opens every event that exists on the calendar, in both directions in time. The request was about the next ten days. The grant covers the medical appointment from last March.

Three substitutes cover most of it. The first is the free/busy level already described. The second is per event visibility: individual events can be marked private, and a private event stays hidden even from someone who has detail access to the calendar. That keeps the sharing level where it is and removes specific events from it, which suits a calendar that is mostly work with a few entries that are not.

The third is an appointment page. Google Calendar can expose free slots as bookable time, and the person picks a slot without seeing the calendar at all. No sharing grant is created, so nothing needs to be revoked later. For anyone outside the organisation, this is usually the lightest thing that still solves the scheduling problem.

There is also a read only route for distribution. Each calendar has a secret address in iCal format, and handing that out lets someone subscribe in their own calendar app without any account level relationship. The useful property is the reset button: regenerating the address revokes it for everyone who ever received it, in one action, without needing to remember who they were.

The consent screen is the scope, in plain words

The layer below people is applications. The sentence on the Google consent screen is the scope description, rewritten for a human reader, and reading it tells you exactly what was requested.

The widest one reads "See, edit, share, and permanently delete all the calendars you can access". That is the full calendar scope. An app whose job is to display a week on a Mac screen does not need permanent deletion rights on every calendar in the account, and narrower scopes exist for almost every real purpose.

What the app does	The wide scope	The narrow one
Read events and display them	calendar	calendar.readonly
Create and edit events	calendar	calendar.events
Check availability only	calendar.readonly	calendar.freebusy
Manage only calendars it created	calendar	calendar.app.created
Read sharing settings	calendar	calendar.acls.readonly

The choice belongs to whoever built the app, not to the person installing it, but the consent screen makes the choice visible before it is accepted. Afterwards, the Third party apps and services section of a Google Account lists every connected app and what each one holds, and it is also where a connection gets cut.

One route that used to exist has closed. Connecting a calendar app with a plain account password over CalDAV stopped being possible: new connections were blocked during 2024 and the remaining ones were turned off on 14 March 2025. Every working calendar app now goes through OAuth, which means scope control and the connections list are the only two places where app access is decided.

The macOS layer nobody adjusts

The third grant has nothing to do with Google. On a Mac, an app that reads or writes calendar data needs permission from the system, and that permission is listed under Privacy and Security in System Settings, in the Calendars section.

Since macOS 14 there are two settings rather than one. Opening Options next to an app lets you give it full access to calendars, or allow it only to add events. An app in the second state can write a new event and cannot read anything that is already there.

That substitution works for a whole category of tools: anything that turns something else into an event. A mail client that extracts a meeting, a task manager that drops work onto a schedule, a script that logs time. None of them need to read the calendar. Anything that displays a day, finds a free slot, or reconciles two sources does need to read, and add only access stops it dead.

These two layers are independent. A narrow Google scope with full macOS access still means the app can reach calendars belonging to other accounts configured on that Mac. Tightening one does not tighten the other, and the settings live in two applications that never mention each other.

Where substitution stops

Some grants cannot be traded down, and knowing which ones saves an afternoon of debugging a permission choice that was working as designed.

Two way sync needs read and write together. Editing an event on the Mac and having that change reach Google is a write, and knowing what to edit is a read. Add only access breaks the return trip. Responding to a meeting invitation is the same shape: an RSVP modifies the event, so it needs write access even though it feels like a reply.

Travel time calculation needs read access to the events on either side of a gap. There is no configuration that produces a departure estimate from a calendar the app cannot see. This is the clearest case where a feature and a permission are the same thing described twice.

Room and resource calendars are a third exception. Their behaviour is set by the organisation's administrator, and adjusting a personal sharing level often changes nothing, because the personal setting was never the one in effect. When something does not behave as configured, separating a personal setting from an organisation setting is the fastest first move.

Administrator ceilings work the same way on ordinary calendars, which is worth knowing before concluding that a substitution failed. An organisation that caps external sharing at free/busy leaves individually shared events showing as busy no matter what level was selected, and Google's administrator documentation notes that such changes can take up to 24 hours to take effect. Super administrators and administrators holding the calendar management privilege also retain visibility into all event details regardless of sharing. Trading a level down protects information from colleagues and external contacts. It is not a control over the organisation itself, and treating it as one leads to substitutions that appear to have been ignored.

What to change first

Start at the sharing level, because it is the layer with the longest memory: open the sharing settings on the calendar most people have access to, and drop anyone whose real question is availability down to free/busy. Then check the connections list in your Google Account and cut anything that has not been opened in a month. What remains after that is not a permissions problem but a speed problem, and Caltimate is built around how fast an event goes in rather than who else can see it.