本記事は /setup と /setup/mcp が完了している前提で書かれています。Google Cloud Console で OAuth クライアントが作成済み、mcp-server-gcal が npm 経由で入っている状態です。
第1章朝、もう一度同じ場所で躓いた
Play 03 で /daily-schedule を組んで、月曜の朝、満を持して打ちました。
出てきた工程表には、ありもしない予定が並んでいました。仮の予定です。Claude は memory と knowledge を読んでいたものの、肝心の 今日のカレンダー を読めていませんでした。
当然です。Claude Code は、まだ Google Calendar とつながっていない。MCP を入れていない状態だった、というだけの話です。
でも、これが見えた瞬間に、もう「対話相手」では足りない と気付きました。本当に業務に組み込むには、AIが 実データに触れる 必要があります。
第2章境界線をまたぐ、ということ
ここまでの Play 01〜03 は、Claude Code に 「自分のこと」を覚えさせる 段階でした。文体・優先度・プロジェクト一覧 ─ すべて手元のテキストファイルの中にある情報です。
Play 04 で扱うのは、その逆。Claude Code が「外の世界」に触れる 段階です。具体的には:
- Google Calendar に並んだ 今日の予定
- Gmail の 未読メール
- Slack の 特定チャネル
- Notion の 議事録
これらに触れる仕組みが MCP（Model Context Protocol）です。境界線を1本またぐと、AIは対話相手から業務システムに変わります。今回はその境界線の上を歩きます。
第3章36行の設定で、つなぐ
具体的にやることは、1ファイルを書くだけ です。Claude Code の MCP 設定ファイルに、Google Calendar 用のエントリを足します。
{
"mcpServers": {
"gcal": {
"command": "mcp-server-gcal",
"env": {
"GCAL_CLIENT_ID": "123...xyz.apps.googleusercontent.com",
"GCAL_CLIENT_SECRET": "GOCSPX-...",
"GCAL_SCOPES": "https://www.googleapis.com/auth/calendar.readonly",
"GCAL_TIMEZONE": "Asia/Tokyo"
}
}
}
}
これだけです。OAuth のクライアントは /setup/mcp で取得済みのものを貼ります。スコープは calendar.readonly（読むだけ）に絞っています。書き込みは後の Play で必要になったら足します。
「設定ファイル36行で済む」のは、難しい仕事を MCP サーバー側がやってくれているからです。読者がやるのは 「どこに繋ぐかを書く」 だけです。
第4章/daily-schedule が、本物で動く
設定後、Claude Code を再起動して、Play 03 で書いた /daily-schedule をそのまま実行します。
$ claude > /daily-schedule # 数秒後、画面に流れ出すのは、もはや仮データではありません。 09:00 ─ Play 04 草稿 (memory/priorities.md から) 10:30 ─ 取引先 A 月次面談 (gcal から ← NEW) 12:00 ─ 昼休み 14:00 ─ 商談準備 ・ B社 (gcal から ← NEW) 16:00 ─ MCP検証 ・ Slack統合 (memory/priorities.md から)
Play 03 の /daily-schedule の手順書（50行）は 1文字も変えていません。MCPを足しただけで、コマンドの中身が「仮想カレンダー」から「本物のカレンダー」に切り替わりました。
これが「設定ファイルとフォルダの組み合わせで動かす」の意味です。AIの動作を変えるために、コードを書き直す必要はありません。繋ぐ先を変えれば、動作が変わる。
第5章月¥0 で動く理由
Google Calendar API は、Google アカウントを持っていれば 無料枠で十分使えます。本誌のような用途（1日数十リクエスト程度）では、無料枠を一切超えません。
MCP サーバー（mcp-server-gcal）も無料の OSS。Claude Code が Pro プランの範囲内で動くのも変わりません。
つまり、Play 04 の追加コストも ¥0。「業務にAIを組み込む」と聞いて、API課金で月数万円取られると思った方には、ここが一番の意外性かもしれません。
第6章2回踏んだ、失敗
OAuth のスコープを広く取りすぎた。
最初は calendar （読み書き両方）を指定しました。Claude にカレンダーへの書き込み権限まで渡る状態。「書き込みは必要になってから足す」が正しい設計です。攻撃面（attack surface）を小さく保つ。
教訓: 初期スコープは readonly のみ。書き込み権限は、書き込みが必要な Play を書いたときに、その Play 専用で追加する。
タイムゾーン指定を忘れた。
初回テストで、午後の予定が早朝に並んでいました。Google API は UTC で返してくるので、日本時間で扱うなら明示的に Asia/Tokyo を指定する必要があります。
教訓: 外部APIをつなぐときは、タイムゾーン・通貨・言語の3つを最初の設定で明示する。「動いたあとに直す」ものではない。
第7章動き出した、本物の朝
翌週の月曜、ターミナルを開いて /daily-schedule。
取引先 A の月次面談、商談準備、すべて本物のスケジュールが流れてきました。コードを書き直すことなく、です。
境界線をまたいだ感覚はここで来ます。「Claude Code を使う」が、「業務システムを動かす」に変わった瞬間。
次の Play からは、ここで開いた MCP の入口に、別のサービス（Gmail・Slack・Notion）を順に繋いでいきます。それぞれが、別の業務の自動化を可能にします。