夕方、調査がひと段落したところで「明日の8時にこの確認やるって、カレンダーに入れといて」と AI エージェントに言いました。
数秒後、Google カレンダーの7月24日に予定が入っていました。タイトルも説明文も、こちらが話した内容そのままで。
その場は「便利だな」で終わったのですが、あとで考え直しました。これ、毎回やらせるならどう仕組み化するのがいいんだろう。
最初に思いつくのは MCP。でも一度止まった
AI にカレンダーを触らせる、と聞いて真っ先に浮かぶのは MCP（Model Context Protocol）でしょう。Google Calendar の MCP サーバーを繋げば、予定の作成も検索も変更も削除もできます。
繋ぎたくなりました。正直、繋ぎかけました。
止まったのは、やりたいことを数えたときです。
- 予定を1件入れる
- ときどき通知の分数を変えたい
以上でした。既存の予定を検索したいわけでも、空き時間を探させたいわけでもない。1件入れるためだけに OAuth を通して、クライアントIDを発行して、トークンの保管場所を決めて、失効したときの再認証を考える。釣り合っていない気がしました。
しかも MCP は、設定した CLI でしか使えません。手元では Claude Code のほかに codex や cursor-agent も動かしていて、その日の作業で使い分けています。カレンダーだけ Claude でしか触れない、というのは地味に不便です。
実際にやったことを分解してみたら、2段階しかなかった
そこで、その日 AI が実際にやった手順を見直しました。
- Google カレンダーの予定作成 URL を組み立てる
- その URL を開いて「保存」を押す
これだけでした。
1段目が肝心なところです。URL を組み立てるのに、認証もライブラリもいりません。文字列を作っているだけです。
https://calendar.google.com/calendar/render
?action=TEMPLATE
&text=作業の確認
&dates=20260724T080000/20260724T083000
&ctz=Asia/Tokyo
&details=説明文をここに
このURLを開くと、入力欄が全部埋まった状態の予定作成画面が出ます。あとは保存を押すだけ。
つまり、ブラウザ自動化を持っていない AI でも、URL を出すところまでは同じ結果を出せるということです。押すのが人になるだけ。
これに気づいた時点で、方針が決まりました。
図にすると、1段目と2段目で担当が変わるだけの構造です。ブラウザ自動化を持っている環境では保存まで進み、持っていない環境では1段目で止まってユーザーにバトンが渡る。使えない機能が増えるのではなく、段が1つ下がるだけ、という形にできます。
3つの案を並べてみる
3つの選択肢を前に、どれが自分の用途に釣り合うかを量りにかけている場面です。比べたのは次の3つでした。
A案: グローバル skill にする
URL の組み立て方を skill として書いておく。実行環境に応じて2段構えにします。
- 第1段（全AI共通）: URL を組み立てて提示する。ユーザーはクリックして保存を押す
- 第2段（ブラウザ自動化がある場合）: 開いて保存まで自動で押す
B案: MCP を繋ぐ
API を直接叩く。読み書き双方向。
C案: 他のエージェントから Claude を呼ぶ
カレンダー機能を1箇所に集約して、他は依頼する形にする。
横に並べると、判断はわりとあっさり付きました。
| 観点 | A案 skill | B案 MCP | C案 委譲 |
|---|---|---|---|
| 初期コスト | 小 | 中〜大 | 大 |
| 秘匿情報が増えるか | 増えない | 増える | 増える |
| 他のAIから使えるか | 使える | 使えない | 経由が必要 |
| 予定を読む・変える | できない | できる | できる |
| 壊れやすさ | 低い | 中 | 高い |
C案は、そもそも単独で成立しないことに書きながら気づきました。委譲先の Claude 側に A か B の実装が要るので、これは「A か B を作ったあとの配り方」の話です。選択肢のふりをした後工程でした。
認証を抱えないことの価値を、最近わりと重く見ている
A案を選んだ理由は、機能の多さではありません。持ち物が増えないことです。
MCP を入れると、トークンという秘匿情報が1つ増えます。保管場所を決めて、うっかりコミットしないようにして、失効したら気づいて直す。一度きりの設定に見えて、実際は薄く長く効いてくるコストです。
そのわりに、増える機能は今のところ使いません。「今週の空きに入れて」と言いたくなったら、そのとき考えればいい。
もう一つ、他のエージェントでも動くのは想像以上に効きます。skill の置き場はジャンクションで各 CLI から同じ棚を見るようにしてあるので、置いた時点で全部に配られます。その日たまたま codex を使っていても、同じ言い方でカレンダーに入る。この揃い方は、機能が1つ多いことより効用が大きいと感じています。
落とし穴は1個だけあった
実装してみて、詰まる場所は1つでした。ctz です。
&ctz=Asia/Tokyo
これを省くと UTC として解釈されて、9時間ずれます。「明日の8時」が「明日の17時」になる。
その日はたまたま付けていたので気づかなかったのですが、あとで仕様を確認していて「あ、これ付けなかったら事故ってたな」と背筋が寒くなりました。こういうのを毎回思い出せる自信はないので、skill に「省略禁止」と書いておきました。
日本語のURLエンコードも要ります。生のまま渡しても通ることが多いのですが、エンコードしておくほうが安全です。
通知だけは、環境で差が出た
「開始10分前に通知」をやりたかったのですが、予定作成URLに通知を指定するパラメータがありません。
なので、こうなりました。
| 環境 | 通知の指定 |
|---|---|
| ブラウザ自動化あり | URLで開いたあと、編集画面の通知欄を書き換えてから保存する |
| ブラウザ自動化なし | カレンダー側の既定通知が適用される |
| MCP | APIで直接指定できる |
ここは B案が明確に有利です。素直に負けを認めて、skill には「分数を指定されたら通知欄を書き換える」手順を書きました。ブラウザ自動化がない環境では、カレンダー側の既定通知を普段使う値に設定しておけば実用上は困りません。
skill に何を書いたか
中身は3つです。
-
URL の組み立て規則。パラメータ表と、
ctz省略禁止の注意 - 日時の決め方。終了は常に開始+30分固定。曖昧でも聞き返さず既定で登録して結果を伝える
- 実行手段の分岐。ブラウザ自動化があれば保存まで、なければURL提示まで
2番目は自分で決めたルールです。「30分でいい。厳密な時間が必要なときはこっちで直す」という判断で、AI に確認させないことを優先しました。毎回「所要時間はどうしますか」と聞かれるほうが煩わしい。間違っていたら直せばいいので。
あと、実際にやってハマった点も書き残しました。保存ボタンを座標でクリックしたら1回目が空振りして、要素を取り直してから押したら通った、という話です。次の自分は絶対に忘れます。
MCP を入れる条件を、先に決めておいた
A案とB案は排他ではありません。skill の手順の先頭に「MCP が使えるならそれを使う」を差し込めば、二段構えが三段構えになるだけです。
なので、いつMCPを入れるかの条件だけ先に書いておきました。
- 「今週の空いている時間に入れて」と言いたくなったとき
- 「さっきの予定を30分ずらして」が必要になったとき
- 「重複してたら入れないで」が必要になったとき
このどれかが出てきたら、そのとき繋ぎます。出てこなければ繋がない。
先に決めておくと、あとで「やっぱりMCPのほうが良かったのでは」と揺れずに済みます。揺れる時間がいちばんもったいない。
おわりに
最初に MCP に手が伸びかけたのは、たぶん「ちゃんとした方法でやりたい」という気持ちだったと思います。APIを正しく叩くほうが、URLを組み立ててブラウザで開くより、なんとなく上等な感じがする。
でも、やりたいことは予定を1件入れることでした。それ以上でも以下でもない。
大きい仕組みに寄せる前に、実際にやった手順を分解してみる。今回はそれで、認証を1つ抱えずに済みました。
小さく。使う道具は、必要になってから増やしていきます。
※ ヘッダー画像とインフォグラフィックは AI（画像生成）で作成しています。
※ 本文の挿絵も AI（画像生成）で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。