Google Workspace CLIの新顔「gws」と、既存ツール「gog」をどう使い分けるか

imds

2026年3月5日 09:59

Google Workspaceをターミナルで扱えるツールとして従来gogがあって、私もそれを使用していた。主としてClaude Code内のエージェントに使用させる用途である。

で、Google Workspace CLIというズバリな名前のツールが出てて、瞠目したのだけどこれもまた、アンオフィシャルな様子。

ではそのgwsにのりかえればいいのか、gogで十分なのか、比較してみた。

Claudeに比較させたところ、AIエージェントに使わせるならgwsで、人間がターミナルで使うなら、gogで併用せよ、ということだった。

また、Rustで作っていて、関連するSkillsを同梱しているところなど面白いかと思います。

私の場合、正直言ってAIエージェント経由で使うことがあきらかに多いので導入を考えているところです。

そうですまだ使ってません。

結局公式orgから出してても非公式なんだよな。在職中に公式Google Drive CLIが2回も開発中止になったから今回も期待してない https://t.co/holeBpmQJb
— Yoshi Yamaguchi (@ymotongpoo) March 4, 2026

オフィシャル感出してるけど大丈夫？と思ってましたが、こういうことのようです。

以下Claude4.6で生成した文章をお送りします。

ここまでが人間でした。

gwsとは何か

gwsは、Google Workspace APIを統一的に操作するためのCLIツールだ。Rust製で、npmパッケージ（@googleworkspace/cli）として配布されている。現在v0.3.3で、v1.0に向けて開発が進んでいる段階にある。リポジトリはgoogleworkspace org配下にあるが、「Googleの公式サポート製品ではない」と明記されている点は留意しておきたい。

npm install -g @googleworkspace/cli
gws auth setup
gws drive files list --params '{"pageSize": 5}'

最大の特徴：Discovery Serviceによる動的コマンド生成

gwsの設計で最も特徴的なのは、コマンド体系がハードコードされていないことだ。

GoogleはすべてのAPIの仕様をDiscovery Serviceとして公開している。gwsはこのDiscovery JSONをランタイムで読み込み、clap（RustのCLIフレームワーク）のコマンドツリーを動的に構築する。つまり、GoogleがAPIエンドポイントを追加すれば、gwsは何も変更しなくても自動的にそのエンドポイントを使えるようになる。

これにより、Drive、Gmail、Calendar、Sheets、Docs、Slides、Chat、Meet、Forms、Tasks、Keep、Admin、Cloud Identity、Classroom、Vault、Apps Scriptなど、ほぼ全てのGoogle Workspace APIが単一のCLIでカバーされている。

一方で、この設計にはトレードオフがある。コマンドの実行にはJSONを直接記述する必要があり、各サービスに特化した便利なショートカットは基本的にない。

# gwsでのCalendarイベント作成
gws calendar events insert \
  --params '{"calendarId":"primary"}' \
  --json '{"summary":"Meeting","start":{"dateTime":"2025-01-15T10:00:00Z"},"end":{"dateTime":"2025-01-15T11:00:00Z"}}'

スキーマがわからないときはgws schemaで確認できるので、Discovery Serviceの仕様書を直接ブラウザで開く必要はない。

gws schema calendar.events.insert

AIエージェント連携に振り切った設計

gwsがgogと最も大きく異なるのは、AIエージェントとの連携を前提に設計されている点だ。

MCPサーバーとして動作できる。gws mcp -s drive,gmail,calendarを実行すると、Model Context Protocolに準拠したstdioサーバーが立ち上がり、Claude Desktop、Gemini CLI、VS Codeなど、MCP対応クライアントからGoogle Workspace APIをツールとして直接呼び出せるようになる。

{
  "mcpServers": {
    "gws": {
      "command": "gws",
      "args": ["mcp", "-s", "drive,gmail,calendar"]
    }
  }
}

100以上のAgent Skills（SKILL.mdファイル）が同梱されている。これらは3つのカテゴリに分かれている。

API Skills：各Google Workspace APIの操作ガイド（gws-drive、gws-gmailなど）
Personas：exec-assistant、project-manager、sales-opsなど10種類の役割別スキルセット
Recipes：メール一括返信、Drive整理、シートからイベント作成など50以上の定型ワークフロー

OpenClawとの連携もサポートされており、~/.openclaw/skills/にシンボリックリンクで追加できる。Gemini CLIのExtensionとしても利用可能だ。

さらに、Google Cloud Model Armorとの統合により、APIレスポンスをAIエージェントに渡す前にプロンプトインジェクションのスキャンを実行できる。メール本文など外部由来のテキストをエージェントが処理する場合の安全策として設計されている。

gws gmail users messages get --params '...' \
  --sanitize "projects/P/locations/L/templates/T"

gogとの比較

gogはPeter Steinberger氏が開発しているGo製のCLIツールで、gwsより先に存在している。12万行を超えるコードベースを持ち、各サービスのコマンドが静的に実装されている。

設計思想の違い

gws / gog 比較

アプローチ: gws = Discovery Serviceから動的生成 / gog = サービスごとに静的実装
言語: gws = Rust（約19,000行） / gog = Go（約120,000行）
コマンド体系: gws = 汎用的（JSON指定） / gog = 各サービスに特化したフラグ
主な対象: gws = AIエージェント＋人間 / gog = 人間＋スクリプト

人間にとっての使いやすさ

日常のターミナル操作では、gogの方が明らかに快適だ。同じCalendarのイベント作成を比較するとわかりやすい。

# gog
gog calendar create primary \
  --summary "Meeting" \
  --from 2025-01-15T10:00:00Z \
  --to 2025-01-15T11:00:00Z \
  --attendees "alice@example.com"

# gws
gws calendar events insert \
  --params '{"calendarId":"primary"}' \
  --json '{"summary":"Meeting","start":{"dateTime":"2025-01-15T10:00:00Z"},"end":{"dateTime":"2025-01-15T11:00:00Z"},"attendees":[{"email":"alice@example.com"}]}'

gogには--today、--tomorrow、--week、--days 3といった日付の自然言語的なフラグがあり、テーブル形式のデフォルト出力も見やすい。freebusy、conflicts検出、チームカレンダー表示といった高レベルなコマンドも揃っている。

対応サービスとカバレッジ

gwsはDiscovery経由で全APIメソッドに対応するため、網羅性ではgwsが上になる。Admin、Vault、Reseller、Licensingなど、gogが対応していないサービスもカバーしている。

一方でgogには、gwsにない独自機能がいくつかある。

sedmat：sed風のDSLでGoogle Docsのフォーマットを直接編集できる。太字、色、見出し、画像、テーブルなどをコマンドラインから操作できるのは他に類を見ない
メール開封トラッキング：Cloudflare Worker連携で--trackフラグ一つで実現
Slides create-from-markdown：MarkdownファイルからGoogleスライドを生成
複数アカウント管理：エイリアス、ドメインマッピング、OAuthクライアント単位のトークン分離など、マルチアカウント運用が充実
最小権限認証：--readonly、--drive-scope file、--gmail-scope readonlyでスコープを細かく制御可能

AIエージェント連携

gws / gog AIエージェント機能比較

MCPサーバー: gws = 対応 / gog = なし
Agent Skills: gws = 100以上同梱 / gog = なし
Personas / Recipes: gws = 10 Personas + 50 Recipes / gog = なし
OpenClaw / Gemini CLI: gws = 対応 / gog = なし
Model Armor: gws = 対応 / gog = なし
コマンド制限（サンドボックス）: gws = なし / gog = --enable-commandsで制限可能

AIエージェント基盤としてはgwsが明確にリードしている。gogの--enable-commandsによるサンドボックスもエージェント向けだが、あくまで「制限」のための機能であり、gwsのようにエージェントが自律的にWorkspaceを操作するための設計とは方向性が異なる。

認証

両者ともOAuth（デスクトップ）、サービスアカウント（Domain-Wide Delegation）、ヘッドレス/CIでの利用に対応している。

gwsはgws auth setupでGCPプロジェクトの作成からAPI有効化、ログインまでを一括で行える（gcloud CLI依存）。アクセストークンの直接指定（GOOGLE_WORKSPACE_CLI_TOKEN）にも対応しており、他のツールが発行したトークンを流用しやすい。

gogは複数OAuthクライアントの管理が強力で、アカウントごとにクライアントを切り替えたり、ドメインマッピングで自動選択したりできる。複数のGoogleアカウントを日常的に使い分ける場合はgogの方が楽だろう。

使い分けの考え方

結論としては、両方入れておいて用途で使い分けるのが現実的だと思う。

gogを使う場面：自分がターミナルで直接操作するとき。Gmailの検索、Calendar確認、Driveのファイル操作、Sheetsの読み書きなど、日常的なWorkspace操作はgogの方が打鍵量が少なく、出力も読みやすい。sedmatでのDocs編集やメール開封トラッキングなど、gogにしかない機能を使いたいときも当然gogになる。複数アカウントを頻繁に切り替える運用でもgogが向いている。

gwsを使う場面：AIエージェントにWorkspaceを操作させたいとき。MCPサーバーとしてClaude DesktopやVS Codeと連携したり、OpenClawのSkillsとして組み込んだりする場合はgwsの一択になる。Model Armorによるセキュリティ対策も、エージェントが外部由来のテキストを扱う場合には有用だ。また、Admin APIやVault APIなどgogが対応していないサービスを使いたい場合もgws経由になる。

スクリプト・自動化：JSON出力を前提としたパイプライン処理はどちらでも対応できる。gwsはデフォルトがJSON出力なのでそのままjqに渡せる。gogも--jsonフラグで同様のことができる。Discovery Serviceのスキーマをそのまま使いたい場合はgws、人間が読みやすいフラグ構成でスクリプトの可読性を優先したい場合はgogという選び方になるだろう。

Google Workspace CLIの世界は、人間向けの操作性を追求してきたgogに対して、AIエージェント時代を見据えたgwsが登場したことで、選択肢が広がった。どちらが優れているという話ではなく、それぞれの設計思想に沿った使い方をすればいい。

https://github.com/googleworkspace/cli
https://github.com/steipete/gogcli