第2章の最後で、残りの課題としてGoogle Docs、Slack、カレンダーを挙げた。その3つすべてを1回のセッションで解決した。そして、Claudeが15人の空き状況を確認し、カレンダー招待を作成し、公開中のGoogle Docの価格エラーを修正し、Sheetsでマルチタブのダッシュボードを構築する様子を見ている途中で - すべてブラウザを開くことなく - このセットアップが閾値を超えたことに気づいた。これはもうAIアシスタントではない。コントロールルームだ。
Google Workspace: gws CLI#
Googleのエコシステムは、他のものとの接続が常に最も難しかった。あらゆるAPIが存在するが、認証が面倒でカバー範囲が膨大だ。そこにGoogleがすべてを変えるものを投入した - Workspace全体の公式CLIをリリースしたのだ。3月2日に発表、Rustで書かれ、Apache 2.0でオープンソース化された。GoogleのDiscovery Serviceから動的に構築される、Google Workspace API全体をラップしている。Gmail、Calendar、Drive、Docs、Sheets、Slides、Tasks、Chat、Admin - すべてが1つのコマンドラインツールで利用可能だ。MCPサーバーサポートと100以上のビルド済みエージェントスキルも同梱されている。
セットアップ#
インストールはnpm経由（プリビルド済みネイティブバイナリが同梱されており、Rustツールチェーンは不要）か、GitHub Releasesからバイナリを取得するか、Cargoでソースからビルドできる：
npm install -g @googleworkspace/cli次に、GCPプロジェクトの設定をガイドするセットアップコマンドがある：
gws auth setup # walks you through Google Cloud project config
gws auth login # subsequent OAuth loginつまずきやすい前提条件がある：OAuthが設定されたGoogle Cloudプロジェクトが必要だ。gws CLIはGCP経由で認証するため、プロジェクトとOAuth同意画面がセットアップされていないと先に進めない。幸い、私のチームには既に使用できる社内GCPプロジェクトがあったので、ゼロから作成する必要はなかった。OAuth同意画面を設定し、使用したい特定のAPI - Calendar、Gmail、Drive、Docs、Sheets - をGoogle Cloud Consoleで有効にするだけだった。ゼロから始める場合は、GCPセットアップ画面をクリックする追加の15分が必要だ。難しくはないが、面倒ではある。
OAuthの設定が完了すると、認証フローはGoogleサインイン用にブラウザを開く。セッションはその後も維持される。ただし、使用予定のすべてのAPIを有効にしておくこと - 1つでも漏れると、何が足りないのか明確に教えてくれない不可解なパーミッションエラーが発生する。
ステップゼロ：Claudeにツールを学習させる#
これらを使い始める前に、後々何時間も節約することになることを1つ行った。Claudeに自分でgws CLIを探索するよう指示した - gws --helpを実行し、サブコマンドを調べ、いろいろ試してみて - 学んだことをすべてCLAUDE.mdに記録するよう指示した。Claudeはコマンドツリーを辿り、各サービス（Calendar、Docs、Sheets、Drive、Gmail）のパターンを把握し、共通のフラグやパラメータ形式をメモし、すべてを書き留めた。
これは新しいツール統合のたびに行うステップゼロだ。CLI を自分で手動でドキュメント化しようとしないこと。チートシートを書かないこと。Claudeに向けて「これを学んで、見つけたことを書き留めて」と言うだけだ。結果として得られるリファレンスは、Claudeが実際にツールをどう使うかに完璧に合わせたものになる - Claudeが自分自身のために書いたからだ。
その探索の後、Claudeは次のようなコマンドを把握していた：
# Check today's calendar
gws calendar +agenda --today --format table
# Read a Google Doc
gws docs documents get --params '{"documentId": "DOC_ID"}'
# Update a Google Doc
gws docs documents batchUpdate ...
# Push data to a Google Sheet
gws sheets spreadsheets values update ...
# Create a calendar event
gws calendar events insert ...第2章のSnowflakeと同じパターン。第1章のGitHubと同じパターン。パターンこそが重要だ：ツールをインストールし、Claudeに探索させ、発見をCLAUDE.mdに記録し、以降のすべてのセッションはフルコンテキストで始まる。
今や私のCLAUDE.mdは本格的なリファレンスドキュメントに成長した。これは座って書いたものではない - Claudeが各ツールを探索し、私が途中でコンテキストを追加する中で有機的に蓄積されたものだ。データウェアハウスのテーブルスキーマ（カラムの説明と計算値の数式付き）がある。エピックやタスク用のGraphQLクエリパターンを含むGitHubリポジトリ構造がある。URLを探し回ることなくClaudeが正しいプロダクト仕様を取得できるNotionページインデックスがある。カレンダー招待から取得したチームリストがある。統合されたすべてのツールのCLIコマンドリファレンスがある。接続設定と認証メモがある。
これは誰も手書きで書こうとは思わない運用マニュアルのように読める。しかし、Claudeが進みながら自分自身のために書くので、マニュアルは自動的に構築される。そして新しい会話はすべて、そのコンテキストがロードされた状態で始まる。Claudeは「データウェアハウスのスキーマは？」や「プロダクト仕様はどこにある？」と聞かない - 既に知っているからだ。
Slack: ビルトインプラグイン#
Slackは予想より簡単だった。Claude Codeにはメッセージの検索、閲覧、送信のためのMCPツールを提供するビルトインのSlackプラグインがある。
/install-slack-app # Install the Slack app
# Complete authorization in browser
/mcp # Connect to the plugin (may need a second attempt)接続すると、Slackの主要な操作をカバーするツールセットが利用可能になる：パブリックチャンネル全体のメッセージ検索、スレッド閲覧、日付範囲指定のチャンネル履歴閲覧、メッセージ送信、ユーザー検索、プロフィール表示。完全なSlack APIではないが、PMが実際に必要とする操作範囲を的確にカバーしている。
ユースケース1：カレンダーからチームメンバーを特定#
常に発生するシナリオがある。チームリストが必要だが、組織図のバージョンではなく、定例会議に実際に参加している人間のリスト。その場にいる人々だ。
Claudeに毎週のチームシンク定例会議を調べて参加者を抽出するよう頼んだ。Calendar APIにクエリを投げ、イベントを見つけ、15人のメールアドレスを抽出した。その後、CLAUDE.mdにリストを保存させたので、以降のすべてのセッションで改めて説明することなくチームメンバーを把握できるようになった。
これは小さなことだが、複利的に効いてくる。Claudeがスケジュール調整、空き状況確認、チームメイトへの言及が必要になるたび、相手が誰かを既に知っている。
ユースケース2：会議のスケジューリング#
これはスムーズさに驚いた。
チーム全員（15人）で戦略ドキュメントをレビューするため、月曜午後の会議をスケジューリングする必要があった。通常のワークフローでは、Google Calendarを開き、午後の空きスロットを目視で確認し、重要な人が空いているか手動でチェックし、15人全員を確認するのは諦め、妥当に見える時間を選び、うまくいくことを祈る。
代わりに、Claudeにチーム全員の月曜午後の空きスロットを見つけるよう指示した。Claudeは：
- 月曜午後のカレンダーをリストアップし、空きスロットを特定した
- 15人全員のfreebusy APIを同時にクエリした
- 希望のスロットで4人にコンフリクトがあることを特定した
- 誰がいつ忙しいかを報告した
events insertで説明欄にドキュメントリンクを含む招待を作成した
招待は自動的に送信された。全体で30秒ほどだった。freebusy確認だけでも、個々のカレンダーをクリックして回って10分はかかっただろう - そして5人確認した時点でおそらく諦めていただろう。
ユースケース3：公開中のGoogle Docを編集#
これはドキュメントワークフローに対する考え方を変えた。
レビューが必要な価格提案のGoogle Docがあった。ブラウザで開いて読んで手動で編集する代わりに、Claudeに取得してレビューするよう頼んだ。
Claudeはdocs documents getでドキュメント全体を取得し、段落やテーブルを含むすべてのコンテンツを解析して読み込んだ。そして不整合を指摘した：価格テーブルに現行プラン価格と一致しない古い数値があった。流し読みしていると見落としやすいが、ステークホルダーに指摘されると恥ずかしい類のエラーだ。
重要なのはここだ：ClaudeはbatchUpdateのreplaceAllTextを使って、公開中のGoogle Docを直接修正した。ダウンロードも、ローカル編集も、再アップロードもなし。修正は他の全員が既に見ている正規のドキュメント上で行われた。
これにより、ドキュメント管理の摩擦のクラス全体が排除される。ドキュメントはチームが期待する場所であるGoogle Docsに留まる。Claudeがその場で読み書きする。
まだ試す必要があることが1つある：コメントのレビューと返信だ。Google Docsのコメントは実際のコラボレーションの半分が行われる場所 - 提案、質問、フィードバックスレッド。Claudeがそれらを読み、未解決のコメントを要約し、返信のドラフトを書けるなら、さらにもう1つのループが閉じる。これが次の課題リストの項目だ。
ユースケース4：Google Sheetsでダッシュボードを構築#
これは純粋にテストだった。Snowflakeからデータを取得し、完全なGoogle Sheetを自動で構築できるかどうかを確認したかった - エンドツーエンド、手動ステップなし。通常なら午後いっぱいかかる類のこと：クエリ実行、CSVエクスポート、シート作成、タブ作成、データ貼り付け、ヘッダーフォーマット、チャート作成。
いくつかのデータセットを指定して「Sheetsでダッシュボードを作って」と指示した。Claudeは：
- Snowflakeから6つのデータセットを取得 - 週次トレンド、日次メトリクス、プラン別内訳、機能採用率、セグメント別利用状況など
- Google Sheetに6つのタブを作成 -
spreadsheets batchUpdate経由 - すべてのデータを正しいタブにプッシュ -
spreadsheets values update経由 - すべてをフォーマット - 太字ヘッダー、グレー背景、先頭行の固定、列幅の自動調整
- タブ全体に9つのチャートを追加 - トレンド用の折れ線グラフ、比較用の棒グラフ、累積メトリクス用のエリアチャート、内訳用の積み上げ棒グラフ
すべてプログラムで実行。手動のシート作業なし。ツール間のコピー＆ペーストなし。第2章のSnowflake CLIとこの章のgws CLIが1つのセッションで連携した。テストに過ぎなかったが、実際のステークホルダー向けダッシュボードにも使えると思えるほどうまくいった。
これが複合効果の実践的な姿だ。追加してきた各統合 - GitHub、Notion、Snowflake、Google Workspace、Slack - は単に1つの機能を追加するだけではない。他のすべての機能を乗算する。SnowflakeのデータがGoogle Sheetsに流れ込む。Calendarのチームリストがミーティングスケジューリングに活用される。Slackのディスカッションがドキュメントレビューのコンテキストを提供する。
ユースケース5：Slack検索#
最後のピースはコミュニケーション履歴だった。Slack検索を使って、チャンネル全体で価格提案に関連するディスカッションを見つけた。Claudeは#product-launchesと#pricing-strategyで関連するスレッドを見つけ、完全な会話を読み、既にレビュー済みの価格ドキュメントと照合するために必要なコンテキストを得た。
これで情報のループが閉じた。以前なら、ドキュメントをレビューし、3週間前にSlackで誰かが懸念を提起したことを思い出し、そのスレッドを探そうとし、スクロールして10分を失い、おそらく諦めていた。今はClaudeが検索し、見つけ、読み、同じ会話の中で統合する。
フルスタック#
現在のワークスペースの全体像：
pm-workspace/
├── CLAUDE.md # Everything: schemas, team lists, tool docs
├── .claude/
│ └── settings.local.json # Permissions for all CLIs and MCPs
├── docs/ # Fallback for docs that can't live in Google/Notion
├── data_reports/ # Fallback for datasets too large for live queries
└── roadmap.md # Living roadmap document統合一覧：
| ツール | 方法 | 機能 |
|---|---|---|
| GitHub | gh CLI | Issue、エピック、プロジェクト管理 |
| Notion | MCP | プロダクト仕様とドキュメンテーション |
| Snowflake | snow CLI | データウェアハウスクエリ |
| Google Workspace | gws CLI | Calendar、Docs、Sheets、Gmail |
| Slack | MCP Plugin | メッセージの検索、閲覧、送信 |
5つの統合。5つの異なるデータソース。すべて1つのターミナルからアクセス可能で、すべてが1つの会話を通じてコンテキストを共有している。
セットアップ時のヒント#
苦労して学んだことをいくつか：
- すべてを
CLAUDE.mdにドキュメント化する。 Claudeは知らないツールを使えない。統合を追加するたびに、どのコマンドが利用可能でどう使うかをClaudeに伝えること。さらに良いのは、Claudeにツールを探索させて自分でドキュメント化させることだ。 - Slackプラグインは再接続が必要な場合がある。
/install-slack-appの後、/mcpを実行して接続する。初回で動かない場合は、もう一度試すこと。初期セットアップ時は不安定だが、一度安定すればその後は問題ない。 - 複雑なSheet操作にはraw APIを使う。 マルチタブ操作でフォーマットやチャートを扱う場合、
spreadsheets values updateコマンドの方が上位レベルのヘルパーよりうまく機能する。 - チームリストと統合の詳細を
CLAUDE.mdに保存する。 セッション間で永続化される。会話が始まった瞬間からClaudeがチーム、スキーマ、ツールを知っていることが、チャットボットではなくコントロールルームのように感じさせるポイントだ。
何が変わったか#
第1章の後、接続されたワークスペースができた。第2章の後、データアクセスが加わった。この章の後、すべてが揃った。カレンダー、ドキュメント、スプレッドシート、コミュニケーション履歴、データウェアハウス、プロジェクト管理、デザインコンテキスト - すべてが1つの場所にある。
ワークフローの変化は本物だ。会議のスケジューリングにGoogle Calendarを開かない。ドキュメントのレビューにGoogle Docsを開かない。ダッシュボード作成にGoogle Sheetsを開かない。過去のディスカッションを探すためにSlackをスクロールしない。必要なことを説明すれば、それが実行される。
完璧か？いいえ。認証セットアップは気まぐれだ。gws CLIはまだ若く、エラーメッセージが常に役立つわけではない。シェルエスケープの問題を回避するためにPythonのsubprocess呼び出しが必要な操作もある。しかし、セットアップの摩擦は一度きりのコストだ。節約される時間は毎日のことだ。
3章を経て、テーゼは持ちこたえている：新しい統合を追加するたびに、既存のすべての統合の価値が乗算される。「質問がある」から「5つの異なるソースからの裏付けデータを含む回答がある」までのギャップが、数時間から数秒に縮小した。
これがゴッドモードだ。
