朝、Macの前で「おはよう、アイリス」と言います。
時刻と天気と今日の予定とリマインダーを、まとめて読み上げてくれる機能です。自作のAI秘書に入れました。
便利です。便利なんですが、返事が来ない。
話しかけて、沈黙がある。そのまま待つ朝が続きました。
この秘書を1日で作った話は係員、プログラミング知識ゼロでAI秘書を作る｜渡したのはインスタの画像1枚だけでしたに書きました。作るところまでは、わりと楽しかったんです。
で、遅い。
こういうとき、たいていは原因を推測して終わりにします。AIが重いんだろう、Macのせいだろう、と。
今回はそれをやめて、測りました。 そうしたらカレンダーの読み取りだけで8秒から32秒かかっていました。
そして原因は、AIでもMacでもネットでもありませんでした。自分が選んだ、許可ダイアログの選択肢でした。
この記事は、その測定と犯人探しの記録です。macOSのカレンダー権限が「書き込みのみ」になっていると何が起きるのか、どう確認するのか、どう直すのかを書きます。
連載5本はぜんぶ物語でしたが、これは初めての実用記事です。同じ症状で検索してきた方は、⑤まで飛んでも大丈夫です。
こんな人に読んでほしい
- Macのカレンダーを自作ツールやスクリプトから読もうとして、異常に遅い方
- EventKit を使っているはずなのに速くならない、という方
- AI秘書やアシスタントの応答が遅くて、原因の見当がついていない方
- 「遅い」の原因を体感で決めてしまって、あとで違ったことがある方
この記事でわかること
- 「おはよう」の返事が遅いとき、どこを測れば原因が分かるか
- カレンダーの権限が「書き込みのみ」だと、読み取りが何秒になるか
- EventKit と AppleScript で、実測どれだけ差がついたか
- 権限の状態を1行のコマンドで確認する方法と、直し方
- 権限を直せない／直さない場合に、何を仕込んでおけば実害が消えるか
①「おはよう」と言うと、返事がなかなか来ませんでした
まず、何をやらせているかを書きます。
「おはよう、アイリス」と話しかけると、AI秘書が時刻・天気・今日の予定・リマインダーを1回でまとめて報告してくれます。
画面に出る形はこうです。予定とリマインダーの中身は、家の事情が丸出しになるので隠しました。
《告。》おはようございます、マスター
05:52 9月21日（月）
天気 （地域） 強い霧雨 23℃（最高32 / 最低23 / 降水94%）
予定 （今日のカレンダーの予定）
リマインダー （今日のリマインダー）朝に見たいものが、これで全部そろいます。天気はiPhoneのウィジェットを開いて見ていたので、その手間がなくなりました。
「まとめて」なので、1つ遅いと全部遅い
この4つは同時に取りにいく作りにしています。順番に待つのではなく、並べて走らせる。
だから理屈のうえでは、待ち時間は「4つのうち一番遅いやつ」で決まります。
ここが落とし穴でした。4つのうち1つが極端に遅いと、その1つのせいで全体が止まるんですよね。
症状は「何秒」ではなく「遅い」としか分かっていませんでした
ここで正直に書いておきます。
私がこの時点で持っていた情報は、「返事が遅い」という体感だけでした。
何秒かかっているかも、4つのうちどれが遅いのかも、分かっていません。
係員：おはよう、アイリス。
毎朝これを言って、沈黙を待つ。それだけでは、犯人の名前は出てこないんですよね。
体感というのは「遅い」までは教えてくれますが、「どこが遅い」は絶対に教えてくれない。ここを混同すると、だいたい見当違いの場所をいじることになります。
私はこのとき、AIのせいだと思っていました
犯人の見当はついていました。AIが遅いんだろう、と思っていたんです。
消去法でした。パソコンは割と新しいですし、ネット環境も整っています。重そうなものといえば、あとはAIしか残らない。
いま振り返ると、この消去法が間違っていました。「ハードが新しい」「回線が速い」で消せるのは、ハードと回線だけなんですよね。残ったものが犯人だとは限らない。
実際の犯人は、候補リストにすら入っていませんでした。macOSの権限設定なんて、遅さの原因として思い浮かべたこともなかったからです。
というわけで、測りました。
②測ってみたら、カレンダーだけで8〜32秒でした
やったことは単純です。4つの取得を別々に時間を測っただけです。
結果がこれでした。
| 取得するもの | かかった時間 |
|---|---|
| リマインダーの読み取り | 6ミリ秒 |
| カレンダーの予定の読み取り | 8〜32秒 |
いや、これは。
同じ機械の、隣り合った機能で4000倍
数字を並べて初めて気づいたんですが、これ同じMacの中の話です。
リマインダーとカレンダーって、ユーザーから見ればほぼ兄弟みたいな機能ですよね。どちらもApple純正で、どちらも同じiCloudに乗っている。
その兄弟で、6ミリ秒と8〜32秒。
6ミリ秒は0.006秒です。32秒と比べると、ざっくり4000倍の差があります。
ここまで極端な差が出ると、もう「性能」の話ではありません。違う道を通っていると考えるしかない。
「全体が遅い」ではなく「1つだけ異常」だった
測って一番よかったのは、容疑者が1人に絞れたことです。
- リマインダー → 無罪（6ミリ秒）
- 天気 → 遅くない
- 時刻 → そもそも計算するだけ
- カレンダー → 真っ黒
もし測らずに「全体的に遅いんだろう」と思ったままだったら、私はきっと読み上げの仕組みか、AIのモデルのあたりをいじっていました。
そこには何もなかったんですよね。全体が遅いのではなく、1つだけ異常だった。
8秒と32秒の幅が、ヒントでした
もう1つ、数字の形そのものが変です。8秒から32秒という幅。
一定ではありません。4倍も揺れています。
「計算が重いから遅い」なら、ここまでは揺れないはずなんですよね。幅があるということは、計算しているのではなく、何かを待っているということになります。
ただ、この時点では何を待っているのかは分かっていません。分かったのは次の段階です。
③犯人は、カレンダー権限の「書き込みのみ」でした
答えを書きます。
カレンダーの権限が「書き込みのみ」になっていました。
macOSは、アプリがカレンダーを触ろうとすると許可を求めてきます。そのときの選択肢に「フルアクセス」と「書き込みのみ」があって、私のMacは「書き込みのみ」が選ばれた状態になっていた。
書き込みはできる。だから「声でカレンダーに予定を登録する」機能は、ちゃんと動いていたんです。
読み取り権限だけが、無かった。
読めないのではなく、遅い道に落ちていました
ここが分かりにくいところで、読み取り権限がないとエラーで止まるわけではないんです。
予定は出てきます。出てくるけれど、8〜32秒かかる。
理由はこうです。IRISはカレンダーとリマインダーを読むのに、macOS純正の EventKit という仕組みを使っています。これが速い。
でもEventKitで読むには読み取り権限が必要で、権限がないと使えません。使えないので、AppleScript経由の別ルートに自動で切り替わる作りになっていました。
| ルート | 速さ | 必要な権限 |
|---|---|---|
| EventKit | 速い | 読み取り（フルアクセス） |
| AppleScript | 遅い | 書き込みのみでも通る |
つまり、止まらずに動いてしまったのが一番たちが悪かった。
動かなければ「権限だ」とすぐ気づきます。動くけど遅いと、性能の問題だと思い込みます。
権限で速度が変わる、という発想がなかった
権限って、ふだん「できる／できない」のスイッチだと思っていませんか。
私は思っていました。許可したら使える、しなかったら使えない。それだけだと。
今回のは「できるけど、遅い道で」という3つめの状態でした。
権限の設定が、速度に化けた。これは完全に予想外でした。
数字で並べると、こうです
| カレンダーの権限 | 予定の読み取り |
|---|---|
| フルアクセス | 0.01秒 |
| 書き込みのみ | 8〜32秒 |
同じコード、同じMac、同じカレンダー。変えたのは設定1か所だけで、この差です。
そして、リマインダーのほうは最初からフルアクセスになっていました。だから6ミリ秒だった。
許可を求められたときにどちらを選んだか、私はもう覚えていません。覚えていない選択が、毎朝の30秒になっていました。
④同じ差を、他の人も測っていました（約3000倍）
ここで1つ、気になったことがあります。
4000倍って、測り方を間違えていないか。
自分の計測だけだと、こういう極端な数字は怖いんですよね。測る場所がずれていたり、1回だけ異常に遅い回を拾っていたりする可能性があります。
GitHubに、同じ比較をしている人がいました
調べたら、go-eventkit というプロジェクトがありました。Go言語からmacOSのカレンダーとリマインダーを触るためのライブラリです。
そのREADMEの冒頭に、こう書いてあります。
3000x faster than AppleScript.
（AppleScriptより3000倍速い）
ベンチマークの表も載っていて、カレンダーの取得で 0.2ミリ秒 対 620ミリ秒、速度差は3101倍とありました。
| EventKit | AppleScript | 差 | |
|---|---|---|---|
| カレンダーの取得 | 0.2ミリ秒 | 620ミリ秒 | 3101倍 |
※ go-eventkit のREADMEより（2026年10月時点）
「約3000倍」と「約4000倍」が並んだ
私の実測は4000倍でした。向こうは3101倍です。
絶対の秒数はぜんぜん違います。向こうは620ミリ秒、私は最悪32秒。環境もカレンダーの件数も違うので、ここは揃いません。
でも桁が揃いました。
これで何が分かったかというと、私の測り方が大きく外れていなかったということです。
ここは強調しすぎないように書きます。他人の計測が自分の数字を証明してくれるわけではありません。
ただ、「EventKitとAppleScriptの差は3桁オーダーで出るもの」という前提が自分だけの思い込みではなかった、というのは確認できました。
自分の実測に、他人の計測を1つ当ててみる。 これは測ったあとにやる価値のある作業だと思います。
⑤直し方は1分。システム設定から権限を変えるだけです
ここが、検索で来た方への本題です。
手順
システム設定 → プライバシーとセキュリティ → カレンダー
ここにアプリの一覧が出ます。該当のアプリ（私の場合は「IRIS起動」というアプリです）を探して、「フルアクセス」に変更します。
ポップアップで選ぶ形になっています。「書き込みのみ」になっていたら、そこを切り替えるだけです。
以上です。これで0.01秒になります。
いまの状態を1行で確認する
変更したつもりで変わっていないことがあるので、確認の方法も書いておきます。
IRISの場合は、サーバーが権限の状態を返すAPIを持たせてあるので、これで見られます。
curl -s http://localhost:8000/api/permissions返ってくるのはこういうJSONです。これは私のMacの、いまの実際の出力です。
{"eventkit": true,
"reminder": {"code": 3, "label": "フルアクセス"},
"calendar": {"code": 4, "label": "書き込みのみ"}}読み方はこうです。
| 表示 | 意味 |
|---|---|
"code": 3（フルアクセス） | 直っています。待ち時間はほぼゼロ |
"code": 4（書き込みのみ） | まだ変わっていません |
リマインダーは code: 3 で、カレンダーは code: 4。
さっきの「6ミリ秒と8〜32秒」が、そのままこの2行に出ています。数字の差が、設定の差とぴったり対応しているのが見える形です。
ブラウザでも見られます
コマンドが苦手な方は、ブラウザで http://localhost:8000/api/permissions を開いても同じものが出ます。
自作ツールにこういう「自分の権限状態を返す口」を1つ付けておくと、こういう時に一発で分かるのでおすすめです。
今回いちばん役に立ったのは、速くなる工夫ではなく、状態が見える窓でした。
⑥権限を直さない場合の保険を、2つ入れました
ここからは、設定ではなく道具の話です。
権限を直せば0.01秒になります。それは分かっています。
でも私は、権限が直っていない前提の仕組みをIRIS側に作り込みました。2つあります。
保険①：裏で先に取っておく（先読み）
「おはよう」と言われてから予定を取りにいくと、32秒待たされます。
なので、聞かれる前に取っておくようにしました。
- IRISの画面を開いたタイミングで、裏で予定を取得する
- そのあとも5分おきに裏で取り直す
- 取れた内容はサーバー側が覚えておく
こうすると、「おはよう」と言った瞬間にはもう手元に予定がある状態になります。取りにいく時間がゼロになるわけです。
朝のまとめって、1分前の予定表と今の予定表で中身が変わることはほぼありません。だから先に取っておいても困らない。
保険②：3秒で打ち切る
それでも間に合わないことがあります。画面を開いた直後に話しかけた場合などです。
その場合は、3秒で予定の取得を打ち切ります。
打ち切ったら、残り（時刻・天気・リマインダー）を先に報告します。予定の欄はこうなります。
予定 取得中（もう一度聞くと出ます）で、次に聞いたときには出ています。裏の取得が終わっているからです。
全部そろうまで黙っているのをやめた、という変更でした。
結果：32秒 → 0.28秒
この2つを入れた結果が、こうです。
| 「おはよう」の返事 | |
|---|---|
| 入れる前 | 最悪 32秒 |
| 入れたあと（普段） | 0.28秒 |
普段は0.28秒で返ってきます。体感でいうと、待っている感覚はもうありません。
でも、速くなったのは「見かけ」です
ここは正直に書きます。
カレンダーの読み取り自体は、いまも8〜32秒かかっています。 何も速くなっていません。
私がやったのは、その32秒を朝の外に追い出しただけです。5分おきに裏で32秒かけていて、ユーザー（私）がそれを見ていない、というだけの話。
マシンの時間は使い続けているんですよね。
| 実際の読み取り | 私が待つ時間 | |
|---|---|---|
| 権限を直す | 0.01秒 | 0.01秒 |
| 保険でしのぐ | 8〜32秒（裏で） | 0.28秒 |
左の列を見ると、どっちが正解かは明らかです。
⑦で、私はその権限を直したのか
直していません。
原因を特定したのは2026年9月23日です。この記事を書いている2026年10月8日の時点で、15日経っています。
さっき貼ったJSONが証拠です。あれは今日の出力です。
"calendar": {"code": 4, "label": "書き込みのみ"}code: 4。書き込みのみのままです。
意図して放置したわけでもありませんでした
「保険を作ったから、もう直さなくていいか」と判断した、という話だったら、まだ格好がついたんですよね。
実際はそうではありませんでした。
この記事を書くにあたって「権限は結局どうしたのか」と確認されたとき、私の答えはこれでした。
係員：権限？ わからない。Claude Code に何を指示したか覚えていない。
覚えていないんです。直したつもりでいた、というのが一番近い。
それで今日あらためてAPIを叩いたら、code: 4 が返ってきました。
これが一番、自分の性質が出ている部分です
整理するとこうです。
| 項目 | 状態 |
|---|---|
| 原因 | 分かっている |
| 直し方 | 分かっている（システム設定を1回） |
| 所要時間 | 1分 |
| 実際にやったか | やっていない |
| 代わりにやったこと | 先読み＋5分おきの再取得＋3秒打ち切りを実装 |
設定を1回変えれば0.01秒になるのに、私は道具のほうを作りました。
並べると分かりますが、保険を作るほうが明らかに手間がかかっています。 実装して、動作を確かめて、打ち切りの秒数を決めて。
システム設定を開いてポップアップを1回押す、のほうが圧倒的に早い。
この連載でずっと出てくる癖なので、ここでは1回だけ書いて終わりにします。私は、設定を直すより道具を作るほうを選びがちです。
直し方は書きました。直したかは別の話です
というわけで、この記事は自分が実行していない解決策を人に勧めている記事です。
ただ、⑤の手順は正しいです。権限をフルアクセスにすれば0.01秒になります。それは測ってあります。
私が直したら、たぶん連載のどこかで報告します。
⑧「遅い」と感じたものを、測る習慣について
この件で持ち帰ったものを書きます。秘書名簿に自分で書いたメモが、そのまま結論でした。
係員：「遅い」と感じたものを測ったら、犯人が設定だった。
体感は「遅い」までしか教えてくれません
①にも書きましたが、ここが核心だと思っています。
体感が教えてくれるのは「遅い」という事実だけです。「どこが」「何秒」は一切教えてくれません。
にもかかわらず、人間は体感から原因まで一気に飛びます。AIが重いんだろう、ネットが遅いんだろう、Macが古いんだろう、と。
今回の犯人は、そのどれでもありませんでした。許可ダイアログの選択肢です。
測らずに直そうとしたら、まず当たらない場所です。
分けて測ると、犯人が1人になります
やったことは高度ではありません。4つをまとめて測るのをやめて、1つずつ測っただけです。
それだけで、6ミリ秒の無罪と、32秒の真っ黒が分かれました。
- まとめて測る → 「全体が遅い」としか分からない
- 分けて測る → どれが遅いかが分かる
遅さの調査って、たぶんこの「分ける」が8割です。
設定は「できる／できない」だけではありません
もう1つの収穫がこれです。
権限の設定が、速度に化けることがある。
動かなくなれば気づきます。でも今回のように「動くけど遅い道に落ちる」実装は、世の中にけっこうあると思うんですよね。親切な自動フォールバックが、問題を隠してしまう。
自作のツールが妙に遅いときは、まず権限を見る。 これは今後ずっと使うチェック項目にします。
ついでに、計測は記事になります
これは余談です。
測った数字は、そのまま記事になりました。6ミリ秒、8〜32秒、0.01秒、0.28秒、4000倍。
秘書を作る話は係員、作るのをやめる｜メールの振り分けボタンを諦めたら、フォルダ分け自体が要りませんでしたのように判断の記録にもなりますが、測った数字が残っていると記録が強くなります。
体感で「速くなった気がする」と書く記事と、「32秒が0.28秒になった」と書く記事は、別物になります。
よくある質問
Q. システム設定を見ても、アプリの名前が出てきません
A. そのアプリが一度もカレンダーを触っていないと、一覧に出てこないことがあります。先にアプリを起動して予定を読む動作をさせてから、もう一度システム設定を開いてみてください。IRISの場合は許可を求めるポップアップがそこで出ます。
Q. ターミナルから起動したときだけ遅いのですが
A. 権限は起動したアプリに対して与えられます。IRISでは「IRIS起動」というアプリに許可を出しているので、ターミナルから手動で立ち上げると許可を持っていない扱いになり、遅い方式に切り替わります。私の環境では、アプリから起動すれば0.01秒、ターミナルからだと約10〜30秒でした。普段はアプリから起動してください。
Q. 「フルアクセス」にするのは怖いのですが
A. その気持ちは分かります。カレンダーの中身を読める権限なので、渡す相手は選ぶべきだと思います。私の場合は自分で作ったツールが自分のMacの中だけで動いているので許可していますが、出所の分からないアプリに出す必要はありません。 その場合は、この記事の⑥に書いた「先読み＋打ち切り」のような逃げ道を作るほうが現実的です。
Q. リマインダーだけフルアクセスになっていたのはなぜですか
A. 分かりません。許可ダイアログで何を押したか覚えていないので、再現できません。同じ日に作った同じ機能なのに、片方だけフルアクセスになっていたというのが実際の状態です。こういうズレが起きうる、という事例として読んでください。
Q. 保険を入れたなら、もう権限は直さなくてよいのでは？
A. 読み取り自体は今も8〜32秒かかっていて、それを5分おきに裏で走らせています。無駄なので、直したほうがいいです。……と書きながら私は直していません。ここは胸を張れる部分ではありません。
Q. EventKit を使えば必ず速くなるのですか
A. 私が言えるのは「自分の環境では、権限が揃っているときに速かった」までです。公開されているベンチマークでも約3000倍の差が出ていますが、カレンダーの件数や同期の状態で変わるはずです。自分の環境で測ってくださいというのが、この記事でいちばん伝えたいことでもあります。
まとめ：遅さの原因は、だいたい外ではなく手元にあります
朝、Macの前で「おはよう、アイリス」と言って、黙って待っていた時間。
あれは、AIが考えていた時間でもネットが混んでいた時間でもありませんでした。私が選んだ設定が、遅い道を通らせていた時間でした。
分かったことを整理します。
- 体感は「遅い」までしか教えてくれず、「どこが遅いか」は教えてくれない
- まとめて測るのをやめて1つずつ測ると、犯人が1人に絞れる
- macOSのカレンダー権限が「書き込みのみ」だと、読み取りでEventKitが使えずAppleScriptに落ちる
- その差は私の実測で約4000倍、公開ベンチマークでも約3000倍だった
- 権限をフルアクセスにすれば0.01秒。直し方はシステム設定を1回触るだけ
- 権限を直さなくても「先読み＋3秒打ち切り」で体感は0.28秒になるが、裏では32秒かかり続けている
最後に、もう一段だけ本音を書きます。
この記事でいちばん不都合な事実は、私が今もまだ直していないことです。
原因も直し方も所要時間も分かっていて、15日間やっていない。代わりに保険のコードを書いた。設定を1回押すより、明らかに手間のかかる道を選んでいます。
それでも書くことにしました。直った話より、直し方が分かっているのに直っていない話のほうが、たぶん読んでいる方の現実に近いと思ったからです。
もし今、自作のツールや秘書が妙に遅いと感じているなら、明日の朝いちばんに原因を当てる前に、1つずつ時間を測ってみてください。 犯人が自分の設定である可能性は、思っているより高いです。
この記事のチェックリスト
□ 「遅い」の原因を決める前に、処理を分けて1つずつ時間を測った □ 一番遅い処理を1つに特定した（全体のせいにしていない） □ システム設定 → プライバシーとセキュリティ → カレンダーを開いて、権限の表示を確認した □ 「書き込みのみ」になっていないか目で見た □ curl -s http://localhost:8000/api/permissions などで、状態を数字で確認できるようにした □ 権限をフルアクセスにできない場合の逃げ道（先読み・打ち切り）を決めた □ 直す前と直したあとの時間を、両方記録した
あわせて読みたい
- 係員、プログラミング知識ゼロでAI秘書を作る｜渡したのはインスタの画像1枚だけでした
- 係員、作るのをやめる｜メールの振り分けボタンを諦めたら、フォルダ分け自体が要りませんでした
- 係員、職場に秘書を置く｜Outlookが開くまでの5〜10分を、7回の作り直しで埋めました
※本記事は個人の環境での実測に基づくものです。macOSのバージョンやカレンダーの件数、同期の状態によって結果は変わります。設定の変更はご自身の判断でお願いします。
