mac カレンダーサーバエラーの原因と切り分け手順

mac カレンダーサーバエラーで検索する状況は、たいてい最悪のタイミングで起きます。打ち合わせが動いてMacのカレンダーで時間を直した直後に、「サーバがエラーを返しました」という灰色の枠が出る。アカウント名が書いてあることもあれば、何も書いていないこともあります。画面上は保存されたように見えるのに、招待した相手にその変更が届いたのかどうかが分からない。これが一番困る点です。

この記事では、このメッセージが何を伝えているのか、どのアカウントが失敗しているのかを短時間で特定する順番、そして直したあとに再発する対処と再発しない対処の違いを整理します。読み終えたときに、次に何を変えればよいかが1つに絞れる状態を目指します。

Macのカレンダーは予定の持ち主ではない

前提を1つ押さえると、この症状の見え方が変わります。macOS標準のカレンダーも、他のMac用のカレンダーアプリも、予定そのものを持っていません。予定の実体はGoogle、iCloud、Exchange、あるいは別のCalDAVサーバの側にあり、Mac側はその写しを手元に置いて同期しているだけです。

手元で予定を直すと、アプリはその変更を相手のサーバへ送ります。サーバが拒否したり、想定外の応答を返したりしたとき、アプリはそれを利用者に伝えなければなりません。そのときの文言が「サーバがエラーを返しました」です。中身がどれだけ違っても、表示は同じ1文になります。

このデータの持ち方は、標準規格として定義されているものです。

This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. 出典: rfc-editor.org

ここから2つのことが言えます。1つは、アプリを消して入れ直しても予定は消えないということ。もう1つは、Mac側だけをいくら直しても、原因がサーバ側にあるなら必ず再発するということです。この2点を先に理解しておくと、無駄な作業をかなり削れます。

表示は同じでも、原因は4種類に分かれる

同じ文言の裏にある原因は、アカウントの種類ごとにはっきり傾向が分かれます。

アカウントの種類	よくある原因	直せる場所
Google	認可トークンの失効、管理者によるポリシー変更	システム設定のインターネットアカウント
iCloud	サービス側の一時的な不調、サインアウト状態	Appleアカウントの状態とサービス状況
Exchange	パスワード変更、代理アクセスや権限の変更	メールサーバの管理者
購読カレンダー	配信元のURL変更や公開停止	配信元の提供者

もっとも件数が多いのはGoogleアカウントです。理由は仕組みにあります。Googleの連携はパスワードを保存する方式ではなく、認可トークンを渡す方式です。パスワードを変えた、2段階認証の設定を変えた、勤務先の管理者がアプリからの接続範囲を絞った、あるいは長期間その連携を使っていなかった。こうしたときにトークンは失効します。Mac側は壊れていません。許可証が取り上げられ、その拒否をそのまま表示しているだけです。

Exchangeは傾向が違い、トークンより権限で詰まります。共有カレンダーが読み取り専用に変わった、代理アクセスの設定が外れた、メールボックスが別のサーバへ移ったのにMac側は古い接続先を見ている。これらはMacの操作では直りません。

見落とされやすいのが購読カレンダーです。祝日カレンダーや同僚が公開している空き状況のように、URLから引いてくる読み取り専用の予定は、そのURLが移動したり公開が止まったりした瞬間からエラーを返し続けます。画面には最後に取得できた内容が残るため、何週間も気づかないことがあります。

10分で切り分ける順番

この症状は、当てずっぽうで直そうとすると高くつきます。候補の対処のうちいくつかは設定を消すからです。順番に消し込むほうが早く終わります。

• どのカレンダーが訴えているかを見る。左側のカレンダー一覧で、失敗しているアカウントの名前の横に警告の印が出ます。押すと、警告枠より詳しい説明が読めます。印が見当たらないときは、アプリを一度終了して開き直すと同期がやり直され、失敗しているアカウントが名乗り出ます。
• 別の場所で同じ予定を見る。ブラウザでそのアカウントを開き、失敗した変更が反映されているかを確認します。反映されていれば、書き込みは通っていて応答だけが失われた状態です。反映されていなければ書き込み自体が失敗しています。この確認だけで、入力し直す必要があるかどうかが決まります。所要時間は1分ほどです。
• アカウントの許可が生きているかを見る。システム設定のインターネットアカウントで対象のアカウントを選び、カレンダーが有効のままか、再認証を求める表示が出ていないかを確認します。Googleアカウントなら、いったんサインアウトして入り直すだけでトークンが再発行され、多くの事例はここで解決します。
• 環境側の原因を外す。ホテルや会場の認証が必要な無線LAN、外向きの通信を絞っているVPN、大きくずれた時計。いずれもサーバが正常でもこのエラーを出します。サービス側の状況はAppleサポートやGoogleカレンダーヘルプで確認できます。

再発する直し方と、再発しない直し方

対処の重さは、原因が資格情報なのか、権限なのか、手元の写しなのかで変わります。

インターネットアカウントからアカウントを削除して追加し直す方法は、汎用の対処としてはもっとも強く効きます。保存された資格情報と手元の写しの両方が作り直されるためです。予定の実体はサーバ側にあるので消えません。ただし無料ではありません。カレンダーごとの色、通知の既定値、新規予定の既定カレンダーといった設定は初期状態に戻り、すべてを取得し直す時間もかかります。

対象のアカウントだけカレンダーの同期をいったん切って入れ直す方法は、同じ考え方の軽い版です。失効したトークンが原因の事例は、これだけで直ることが少なくありません。

手元の写しを消す対処はさらに重く、片方のアカウントは正常なのにもう片方だけがどうしても直らないときや、起動そのものが引っかかるときに限って意味を持ちます。最初に試す手ではありません。

逆に、効かないのに繰り返しがちなのが「同じ操作をもう一度やる」です。書き込みを一度拒否されたなら、送り直しても同じ理由で拒否され、警告の枠が増えるだけです。サーバ側に原因があるときも同じで、管理者が権限を変えたことが原因なら、Mac側をどう直しても数時間のうちに戻ってきます。

警告枠が省いている情報をどこで読むか

1文の警告の裏には、たいていサーバからのもっと詳しい返答があります。そこまで見に行くと、当てずっぽうが判断に変わります。

最初に見る場所はカレンダー一覧です。失敗しているアカウントの名前の横に出る小さな警告の印を押すと、警告枠より長い説明が読めます。対象のカレンダー名が入っていることが多く、書き込みに失敗した操作まで書かれていることもあります。

次に見る場所はシステムのログです。macOSのカレンダー同期は、目に見えるアプリではなく裏で動く処理が担当していて、その処理は自分が何をしたかを記録しています。コンソールを開いて対象の処理名で絞り込み、同じ操作をやり直すと、要約される前の応答が読めます。毎回やる必要はありませんが、たまにしか起きない失敗の理由を突き止めるときは決定打になります。

どちらの場所で読む場合も、見るべきは「どの系統の拒否か」です。系統が分かれば、対処は自動的に決まります。

• 認証の拒否。資格情報が受け付けられていない状態で、直し方はアカウントの認証をやり直すことです。
• 権限の拒否。資格情報は有効で、その操作だけが許されていない状態です。これはMacの操作では直らず、管理者や共有元への確認になります。
• サーバ側の不調。拒否ではなくホスト側が失敗した状態で、Mac側を変える必要はありません。時間を置いて試すのが正解です。
• 応答が返らない。両端ではなく途中の通信が原因で、ネットワークを変えると解決します。

対処は4通りあるのに、画面に出る文言は1つです。この差が、この症状を「面倒」ではなく「腹立たしい」ものにしています。

共有・代理・購読のカレンダーは別枠で考える

このエラーの相当な割合は、自分のものではないカレンダーで起きます。持ち主が別にいるカレンダーは挙動が違うため、分けて考えたほうが早く片付きます。

共有カレンダーの権限にはいくつかの段階があります。閲覧のみなら予定は全部見えますが変更はすべて拒否されます。編集可なら書き込めます。管理者権限ならカレンダー自体を消せます。実際によくあるのは、持ち主が共有設定を整理した結果、いつの間にか閲覧のみに下がっていたケースです。Mac側には事前の合図が出ません。予定は編集できるように見え、手元では編集が通り、その直後にサーバが拒否します。

Exchangeの代理アクセスも同じ形で、層が1つ増えます。代理の権限はメールボックスごとに付与され、役割の変更や退職、メールボックスの移設で外れます。権限が外れても一覧からカレンダーが消えるわけではないため、最初の兆候は「消えた」ではなく「エラーが出た」になります。

もっとも静かに壊れるのが購読カレンダーです。購読はURLから定期的に取得するだけで、こちらから書き込むことはできません。配信元がアドレスを変えた、別のツールに移った、公開をやめた。そのいずれでも、同期のたびに失敗しながら、画面には最後に取得できた内容が残り続けます。古い祝日情報を何か月も見ていたのに、気づく手がかりは見慣れて無視するようになった警告だけ、ということが起こります。

ここから導ける原則は単純です。失敗しているカレンダーの持ち主が自分でないなら、直すべきは設定ではなく確認の連絡です。権限の段階を持ち主に確かめる前に、Mac側で消す操作をしないでください。

同期の失敗を「見せ方」の問題として捉え直す

ここまでの切り分けをしても、そもそも警告が出る回数自体が多すぎる、という状態があります。これは故障ではなく設計の相性です。接続しているアカウントが多いほど、失敗する場所は増えます。誰も見ていない購読カレンダーが5本ぶら下がっていれば、それは壊れうる場所が5か所あるということです。

判断の軸は2つです。1つ目は、このMacにつないでいるカレンダーが本当に全部必要かどうか。使っていない購読を外すだけで、警告の枠は目に見えて減ります。2つ目は、エラーが出たときにアプリが「どのアカウントで何が起きたか」を書いてくれるかどうかです。アカウント名と理由が出るアプリなら、10分かかっていた切り分けが10秒で終わります。この差は機能一覧には出にくく、他のカレンダーとの比較のように並べて見て初めて気づく種類の違いです。

もう1つ、復旧したあとの入力コストも見ておく価値があります。同期が戻ったときに予定を入れ直す作業が重いほど、エラーの実害は大きくなります。話し言葉と音声で予定を入れられる入力方式なら、日付や時刻を項目ごとに埋め直す手間がなくなります。入力の考え方は予定の入れ方に整理されています。会議の前後に移動が挟まる働き方なら、移動時間を予定として確保する仕組みの有無も同時に見ておくと選び直しの回数が減ります。こちらは移動時間で扱っています。