はじめに ─ Gmail / Calendar / Docs 往復で1日が溶ける問題
個人事業やスモールチームで仕事をしていると、朝からやることが似通ってきます。Gmail を開く、Calendar を確認する、Drive 上の議事録を開く、Sheets の請求一覧を眺める、Docs で提案書の続きを書く。やること自体は大した量ではないのに、アプリを行き来するだけで午前中が溶けます。
しばらく前から、この「往復の時間」を Claude Code に権限を絞って半自動化できないかを試していました。結論から言うと、Claude Code と以下の 2 つの経路を組み合わせると、秘書業務の大半はコマンドから動かせます。
- gog CLI ─ Gmail / Calendar / Drive などを素早く叩く軽量 CLI。Docs / Sheets / Slides / Chat / Tasks など他の Workspace サービスにも対応
-
Google Workspace MCP（
gemini-cli-extensions/workspaceなど）─ Docs / Sheets など構造データを扱う MCP サーバー
この記事では、両者の使い分けと、実際に運用している 3 つの Skill を実物ベースで紹介します。対象読者は「Claude Code をある程度使っていて、バックオフィスの作業を減らしたい人」です。
なお、本稿で扱うのは筆者個人のセットアップです。クライアント名や契約金額などの機密情報は一切含みません。
1. アーキテクチャ概観
全体像は次のようになります。Claude Code が司令塔、Skill が定型作業のテンプレート、gog CLI と Google Workspace MCP が Google Workspace への手足、という位置付けです。
ポイントは「Claude Code から見て経路が 2 本ある」ことです。1 本は gog CLI、もう 1 本は Google Workspace MCP。どちらも Google Workspace を触る点は同じですが、得意分野が違います。
なぜ経路を 2 本に分けるのか
最初は Google Workspace MCP だけで組もうとしました。しかし、Gmail のラベル検索や Calendar の直近予定取得のような「短文を何度も叩く」用途だと、MCP サーバーの初期化オーバーヘッドが体感で気になりました。一方、Docs のセクション編集や Sheets のセル範囲更新は、構造化されたツール呼び出しが前提の MCP が圧倒的に楽です。
そこで「よく叩くものは CLI、構造データは MCP」に役割分担しました。
2. gog CLI と Google Workspace MCP の使い分け
使い分けの原則は、以下の表にまとめた 3 点に集約されます。
| 観点 | gog CLI | Google Workspace MCP |
|---|---|---|
| 得意領域 | Gmail / Calendar / Drive の素早い操作 | Docs / Sheets の構造データ操作 |
| 呼び出し形態 | サブプロセスで一発 | MCP サーバー経由（常駐） |
| レイテンシ | 低（プロセス起動のみ） | 中（MCP セッション維持） |
| 実装の厚み | Gmail・Calendar・Drive を中心に Docs / Sheets / Slides / Chat / Tasks 等にも対応 | Docs / Sheets 含む広範囲 |
| 権限管理 | OAuth トークンをローカル保存 | MCP サーバー経由で再認証 |
| 典型ユース | 「今日の未読をラベル別に 20 件だけ取りたい」 | 「Docs のセクション 3 に追記したい」 |
一言で言うと、以下の原則に落ちました。
gog CLI を第一選択にし、gog CLI で足りない領域だけ Google Workspace MCP で補完する。
この順番を逆にすると、MCP のセッション維持コストが効いてきて、軽いタスクの応答が鈍くなります。実際、Skill の中で「まず gog、次に MCP」に統一してから、朝のトリアージの所要時間が体感で 5〜10 分程度から 1〜2 分程度に縮まりました。
gog CLI の位置付け
gog CLI（https://github.com/steipete/gogcli）は、Google Workspace を CLI から叩くためのツールです。日常操作の中心は gog gmail / gog calendar（gog cal エイリアス可）/ gog drive ですが、Docs / Sheets / Slides / Chat / Tasks などその他の Workspace サービスにも対応しています。
たとえば Gmail の未読取得は次の 1 行です。list は search のエイリアスなのでクエリが必須である点と、JSON 出力は --json である点に注意してください。
gog gmail search 'is:unread' --max 20 --json
Calendar の今日の予定はこうです。
gog calendar events --today --json
出力が JSON で素直に返ってくるので、Claude Code 側で jq を挟む必要もほぼありません。Skill から呼ぶと、そのままレポートの素材として使えます。
Google Workspace MCP の位置付け
Google Workspace MCP は、Docs・Sheets のように「構造を壊さずに編集する」必要がある領域で頼りになります。gog CLI でもダウンロード・アップロードはできますが、「Docs の特定セクションに追記」「Sheets のセル範囲に行を挿入」のような操作は、MCP のツール呼び出しの方が素直に書けます。
実装は公式の gemini-cli-extensions/workspace をはじめ、非公式のものが複数存在します。筆者は Docs / Sheets 操作が充実しているものを使っています。初回認証とトークン切れ時の再認証は、使っている MCP サーバーが用意している OAuth 再認証フローに統一しておくと運用が安定します。
3. Skill の設計例 3 つ
ここからは、実際に .claude/commands/ に置いている Skill のうち、秘書業務で稼働率が高い 3 つを紹介します。いずれも CLAUDE.md のトリガーワード表から呼び出される形です。なお本文中に出てくる .secretary-workspace/ は本記事での呼称で、プロジェクトごとに好みのディレクトリ名に読み替えて構いません（docs/secretary/ や .agent-secretary/ などでも同じ運用が成立します）。
3.1 朝の工程表（daily-schedule）
朝の 1 発目に「おはよう」と打つと、Claude Code が以下をまとめて返してくれる Skill です。
- 今日の Calendar 予定（開始時刻順、空き時間も明示）
- 未読 Gmail の重要度トリアージ（返信必要 / 情報共有 / あとで / ノイズ）
- 前日の積み残しタスク（
.secretary-workspace/todos/から取得） - 午前／午後のおすすめ集中ブロック
Skill の Markdown は、ざっくり以下のような形です。
---
name: daily-schedule
description: 朝の工程表を作成する。Calendar・Gmail 未読・todos を統合して1枚にまとめる
argument-hint: "[日付（省略時は今日）]"
allowed-tools:
- Bash
- Read
- Write
disable-model-invocation: false
---
# daily-schedule
## 目的
今日一日の工程表を、Calendar・未読 Gmail・積み残し todos から自動生成する。
## 実行手順
1. Calendar の今日の予定を取得
`gog calendar events --today --json`
2. 未読メールを取得（上位 30 件）
`gog gmail search 'is:unread' --max 30 --json`
3. `.secretary-workspace/todos/YYYY-MM-DD.md` があれば読み込む
4. 以下の観点で整理
- 予定と予定の間の空きブロックを計算
- 未読メールを「返信必要 / 情報共有 / あとで / ノイズ」に分類
- 積み残し todos を空きブロックに差し込む
5. `output/digest/schedule-YYYY-MM-DD.md` に保存し、要点を表示
## 出力フォーマット
- 予定一覧（テーブル）
- メール分類サマリ（カテゴリ別件数＋要返信 3 件のみ抜粋）
- おすすめ集中ブロック 2 本
- 所要時間の目安
コツは「判断を Claude に任せる部分」と「必ず機械的に実行する部分」を明確に分けることです。メールの分類は Claude に任せる一方、Calendar 取得は gog CLI にガッチリ固定しておくと、出力がブレません。
3.2 受信箱トリアージ（issue-triage）
「Issue にして」「タスク登録して」と打つと、メール・Slack のスクリーンショット・自分のメモを解析して、GitHub Issue や .secretary-workspace/todos/ に振り分ける Skill です。
内部では次の手順で動きます。
- 直近 1 時間の未読 Gmail を gog CLI で取得
- アクション項目かどうかを Claude Code が判定
- 該当するものは GitHub Issue（
gh issue create）を発行 - 軽いものは
.secretary-workspace/todos/YYYY-MM-DD.mdに追記 - 判定ログを
.secretary-workspace/inbox/に残す
判定ロジックは完璧を狙わず、迷ったら人間判断待ちに落とす方針にしました。自動化しすぎると Issue が散らかります。曖昧ケースは「要確認」タグを付けて、朝の工程表で拾う流れに統合しています。
3.3 週次活動レポート（weekly-activity-report）
金曜夕方に「今週のまとめ」と打つと、以下を統合した週報が出てきます。
- 各プロジェクトの
git log（7 日分） - Calendar の打ち合わせ時間合計
- 完了 todos の一覧
- Docs で更新した提案書のサマリ
ここは Docs の要約 が入るので、Google Workspace MCP の出番です。Docs の直近更新分を MCP 経由で取り出し、Claude Code に要約させて週報に混ぜ込みます。Sheets の請求管理タブに行が増えていれば、その差分も拾います。
gog CLI だけで組もうとするとダウンロード → 再パースの手数が増えますが、MCP に任せると「セクション単位で取ってくる」ができるので、Skill のコードが薄くなります。
4. gog vs MCP の判断フロー
「どちらで叩くか」を毎回考えると疲れます。Skill を書くときは次のフローで機械的に決めています。
原則は 3 つだけです。
- Docs / Sheets の構造編集 → 迷わず MCP
- Gmail / Calendar / Drive の「取得して判断」→ gog CLI
- gog CLI の守備範囲外 → MCP で補完
迷ったら gog CLI から試して、制約にぶつかった箇所だけ MCP に逃がす、くらいの割り切りで十分でした。
5. 運用 1 ヶ月で感じたこと
効果測定は簡単にしか取っていませんが、筆者の肌感で以下の変化がありました。いずれも 1 人分の目安なので、参考程度に読んでください。
| 項目 | Before | After | 変化 |
|---|---|---|---|
| 朝のメール・カレンダー確認 | 20〜30 分程度 | 5〜10 分程度 | 体感で短縮 |
| 週次レポート作成 | 60 分前後 | 15〜25 分程度 | 体感で短縮 |
| 返信取りこぼし（月） | 2〜3 件程度 | 0〜1 件程度 | 減少傾向 |
| 予定の二重ブッキング | 月 1 回程度 | 目立った発生なし | 減少傾向 |
数字が派手に見えそうな部分こそ注意で、実際には「Claude が振り分けたタスクを人間が確認する時間」が別途必要です。合計時間で見れば、作業量が半分になるというより、「細かい意思決定の負荷が目に見えて減る」という感覚が近いです。
ミスの傾向も変わりました。以前は「気付かず放置」が多かったのに対し、いまは「判断迷いで保留」が増えています。見えないミスが見えるミスに変わっただけとも言えますが、個人的にはこの方が健全だと感じています。
6. セキュリティと権限設計
Google Workspace に広範な権限を渡す以上、ここは手を抜かないようにしています。
OAuth スコープの最小化
gog CLI も Google Workspace MCP も、OAuth スコープは「業務で本当に必要な範囲だけ」に絞っています。ただし Google の OAuth スコープは「特定フォルダ subtree だけ」「特定のシート ID だけ」といった粒度には落とせない点は前提として押さえておきます（たとえば drive.file はアプリが作成・ユーザーが明示的に開いたファイルのみを対象とするスコープで、任意フォルダ配下の制限とは別物です）。ファイル単位の絞り込みはスコープではなく運用側で担保する前提です。
- Gmail: 読み取りとラベル操作のみ（送信は明示操作でのみ許可）
- Calendar: 読み取りとイベント作成
- Drive: 読み取りは必要最小限、書き込みは
drive.fileを基本とし、アプリ経由で作成・選択したファイルに限定する運用にする - Docs / Sheets: スコープでファイル単位の制限はできないため、編集対象のファイル ID を Skill 側でホワイトリスト化して運用で縛る
「読む」と「書く」を分けて、書き込み系は Skill を呼ぶ前に Plan mode で 1 回挟むルールにしてあります。暴走を防ぐためです。
シークレットの取扱い
OAuth トークンや API キーはローカルの ~/.config 配下、または 1Password CLI 経由で注入しています。.env を Git 管理下に置かない、.claude/settings.local.json に書く値はスコープを限定する、という基本を徹底するだけでも事故は減ります。
また、Claude Code に渡す Skill の中に 生トークンを埋め込まない ことは厳守しています。必要なら環境変数経由で渡す形にとどめて、Skill 自体は Git に入れても安全な状態を保っています。
操作ログ
.secretary-workspace/inbox/ 以下に、Skill が実行した操作の記録を日次で追記しています。何を送信したか、どのファイルを更新したかが後から辿れるようにするためです。Claude Code に任せるからこそ、「いつ・どこで・何を変えたか」の足跡は自分で握る必要があります。
7. 次の一手
この仕組みは、いくつかの拡張余地があります。直近で試したい候補を挙げておきます。
Routines との組み合わせ
4 月に出た Routines を絡めると、daily-schedule を毎朝 7:30 に自動実行して、前日の未処理メールを事前にトリアージしておく、といった運用ができます。朝起きたときには工程表ができあがっている状態です。ただし、Routines は回数制限と課金影響があるので、事故対策（暴走時の停止手順）を先に整える必要があります。
独自プラグイン化
本稿で書いた Skill は、いずれ 1 つのプラグインにまとめて再配布できる形にしたいと考えています。個人用にチューニングした Skill をチーム共有する際に、設定ファイルだけ差し替えれば使えるようにする、という発想です。CLAUDE.md のトリガーワード表をそのままプラグインの仕様書にする、くらいの軽さで運用できそうです。
Docs / Sheets 起点のワークフロー化
いまは Gmail・Calendar 起点ですが、Sheets の請求一覧を起点に「入金があれば対応 Issue を閉じる」といった逆流ワークフローも試したい領域です。MCP 側の強みが効くところなので、年後半の宿題にしています。
8. まとめ
- 秘書業務を Claude Code に任せるときは、gog CLI と Google Workspace MCP を 役割分担 させると落ち着きます。
- 原則は「gog CLI を第一選択、Docs / Sheets の構造編集だけ MCP」です。
- Skill は
daily-schedule/issue-triage/weekly-activity-reportの 3 つから始めると、効果が見えやすいです。 - 効果測定は数字だけでなく「ミスの質の変化」も見ると、運用の手応えを掴みやすくなります。
- 暴走対策として、OAuth スコープ最小化と操作ログを先に整えるのがおすすめです。
最初から完全自動化を狙うより、人間の判断ポイントをどこに残すか を決めることが設計の肝でした。Claude Code と gog CLI、Google Workspace MCP は、そのための手足をまとめて貸してくれる存在だと感じています。この記事が、同じように「往復の時間」を減らしたい方の参考になれば嬉しいです。