ハクソク

世界を動かす技術を、日本語で。

Google Workspace CLIのコマンドラインインターフェース

45日前原文(github.com)

概要

gwsはGoogle Workspaceの全APIを統一CLIで操作可能にするツール。
人間とAIエージェント双方に最適化された設計。
認証方法や自動コマンド生成、JSON出力など多機能。
Gemini CLI拡張やMCPサーバーによる連携もサポート。
開発中のため今後大きな仕様変更の可能性あり。

gws：Google Workspace統合CLI

  • Google Workspace（Drive, Gmail, Calendar等）全APIをCLIから操作可能なツール
  • npm install -g @googleworkspace/cliでインストール
  • コマンド一覧はGoogle Discovery Serviceから動的生成、API追加時も自動対応
  • ゼロボイラープレート設計、全出力が構造化JSON形式
  • 40以上のAIエージェントスキルを標準搭載

主な特徴

  • 人間向け機能
    • curl不要、タブ補完・--help・--dry-run・自動ページネーションなどCLI操作性向上
  • AIエージェント向け機能
    • すべてのレスポンスがJSON、エージェントスキル連携でLLMから直接操作可能
  • APIスキーマのインスペクションやNDJSON形式のストリーム出力も対応

代表的なコマンド例

  • 最新10件のファイル一覧取得
    • gws drive files list --params '{"pageSize": 10}'
  • スプレッドシート作成
    • gws sheets spreadsheets create --json '{"properties": {"title": "Q1 Budget"}}'
  • Chatメッセージ送信（dry-run付き）
    • gws chat spaces messages create --params '{"parent": "spaces/xyz"}' --json '{"text": "Deploy complete."}' --dry-run
  • 任意APIメソッドのスキーマ確認
    • gws schema drive.files.list

認証方法

  • 複数の認証ワークフローに対応（ローカル・CI・サーバー等）
  • 認証情報はAES-256-GCMで暗号化、OSキーチェーンに保存
  • gws auth setupで初回設定（Cloudプロジェクト作成・API有効化・OAuthログイン）
  • gcloud CLI連携による認証も可能
  • 手動OAuth設定（Google Cloud Consoleでクライアント作成・JSON配置）
  • ブラウザアシスト認証（人間orエージェント操作両対応）
  • ヘッドレス/CI用途：認証済みJSONをエクスポートし環境変数で指定
  • サービスアカウント認証、事前取得アクセストークンにも対応
  • 認証優先順位：アクセストークン＞認証ファイル＞暗号化認証＞平文認証

AIエージェントスキルとOpenClaw連携

  • 100以上のエージェントスキル（APIごと＋汎用ワークフロー・レシピ50本以上）
  • 全スキル一括インストール
    • npx skills add https://github.com/googleworkspace/cli
  • 必要なスキルのみ選択インストール
    • npx skills add https://github.com/googleworkspace/cli/tree/main/skills/gws-drive
  • OpenClaw用スキル配置（シンボリックリンクまたはコピーで同期）
  • gws-sharedスキルでCLI自動インストールにも対応

Gemini CLI拡張

  • gws認証後、Gemini CLIに拡張機能をインストール
    • gemini extensions install https://github.com/googleworkspace/cli
  • Gemini CLIエージェントがgwsコマンド・スキルを直接利用可能
  • 一度認証すれば拡張側も自動で認証継承

MCPサーバー連携

  • gws mcpコマンドでModel Context Protocolサーバー起動
  • Drive/Gmail/Calendar等のAPIツールをMCPクライアント（Claude Desktop, Gemini CLI, VS Code等）に提供
  • サービスごとに10～80ツール追加、必要なサービスのみ選択可能
  • MCPクライアント設定例
    • "command": "gws", "args": ["mcp", "-s", "drive,gmail,calendar"]

高度な使い方

  • マルチパートアップロード
    • gws drive files create --json '{"name": "report.pdf"}' --upload ./report.pdf
  • ページネーション制御
    • --page-all（全ページ自動取得）、--page-limit、--page-delay
  • Model Armor連携によるレスポンスのプロンプトインジェクション対策
    • gws gmail users messages get --params '...' --sanitize "projects/P/locations/L/templates/T"

アーキテクチャ・開発

  • 2段階パース戦略
    • 引数からサービス判別→Discovery Document取得→コマンドツリー生成→再パース
  • 全出力が構造化JSON
  • API未有効時のエラーと対処法
    • 403エラー時に有効化URLを案内
    • gws auth setupで自動有効化可能
  • 開発用コマンド
    • cargo build、cargo clippy -- -D warnings、cargo test、./scripts/coverage.sh

ライセンス・免責事項

  • Apache-2.0ライセンス
  • Google公式製品ではないことに注意

参考リンク

  • GitHubリポジトリ：https://github.com/googleworkspace/cli
  • Google Cloud Console：https://console.cloud.google.com/
  • API有効化例：https://console.developers.google.com/apis/api/gmail.googleapis.com/overview?project=＜プロジェクトID＞

Hackerたちの意見

ハハ、AI/MCPの世界では、急に企業がちゃんとAPIやCLIツールを作るように推進されてるね。
└
AI競争から得られた数少ない良いことの一つは、みんながようやくデータAPIをオープンに公開して、CLI（または拡張可能なAPI）を通じてツールを使えるようにしていることだね。
└
MCPがただの劣化版APIだって気づくのにこんなに時間がかかるなんて。
└
そうだよね、需要がめっちゃ増えてるし、同時に企業が作ってメンテナンスするのも（AIの助けを借りて）ずっと楽になってる。いいことだね！
└
でも、彼らはまだそれをやってないよ。少なくとも今はね。これは発見ツールから生成されてて、既存のAPIの仕様に相当するものなんだ。もし彼らが高機能なCLIを望むなら、Google Workspaceの裏にあるサーバーを掘り下げる必要があるよ。ウェブアプリを改善した時みたいにね。
└
ずっと言ってるけど、開発者に対してやってることをエージェントにやってたら、世界はもっと良い場所になってたと思う。
└
「LLMsのためにコードベースを良くする」って言ってることの90%は、昔ながらの良いエンジニアリングで、人間にも良いことなんだよね。
└
数週間前に似たようなことに気づいたよ。企業がやっとAPIを必要なものに対して出してきたね、何年も前からAPIが必要だったのに！
└
でも一方で、（ちょっと暗い）パターンが出てきてる気がする。企業がMCPにアクセスするために、より高いプランにアップグレードするよう求めてくるんだよね。
これって基本的に[1]のCLI版ってこと？そうなら、Googleが開発者がアプリをどう使いたいかをちゃんと考えてるのが嬉しい。Googleのダッシュボードや適当に作ったサードパーティのライブラリより全然いいよね。Googleはサポートしないって言ってるけど、Google外の誰かよりはサポートしてくれると思うよ。[1] https://workspaceupdates.googleblog.com/2025/12/workspace-st...
└
それは関係ないと思う。
`rust`のバイナリをインストールするのに`npm`を使うのはなんでだろう？
└
それも変だと思った。僕の予想では、`npm`が一番多くの人がすでにインストールしてるパッケージマネージャーだから、こうすることで簡単にできるんじゃないかな。Cargoをインストールさせるのは手間がかかりすぎると思ってるかも。npmを使ってノード以外のツールをインストールするパターンがもっと広がるかどうか気になるね。
└
NPMはクロスプラットフォームのパッケージ配布システムとしてすごくうまく機能してる。インストールスクリプトがOSとアーキテクチャをチェックして、適切なRustのバイナリを引っ張ってくるんだ。それに、アップグレード機能も自動でついてるし、アンインストール機能もある。今やNPMはどんなソフトウェアをインストールするための事実上のスタンダードになってるよ、だってどのOSにもあるからね。
└
ここではそうしてないけど、npmでWASI APIを使ったwasmコンパイル済みバイナリを出荷するのは、クロスプラットフォームのCLIユーティリティを出すのにすごく簡単な方法だよ。引数やファイルシステムをセットアップするために、約20行のJSラッピングが必要なだけ。
└
パッケージの元の言語が重要なのは何で？apt-getを使う時、パッケージがどの言語で書かれてるかなんて全然分からないよ。
└
面白い事実だけど、cargoはダウンロードしたツールをすべてビルドするから、Googleのノートパソコンでは内部でcargo installを実行できないんだ。
これ、メインの投稿者からの面白い投稿だね（少なくとも彼が言ってるのはこれだと思うけど） https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
└
すごく面白いね。コードの形について似たようなことを考えてたんだ。エージェントに静的解析を極限まで推奨するのは全然気にしないけど、ほとんどの人には面倒かもしれないね。
Claude Opus 4.6は、Googleシートに書き込む方法が分からなかったみたい（！をエスケープするのに関係してるのかな？）で、gcloud authを使ってシートAPIを直接呼び出すことにしたみたい。
Workspace APIを使っていくつかの内部ツールを作ったことがあるけど、強力だけど、Drive APIのレート制限は大量操作をする時には厳しいことがあるよ。このリポジトリは自動バックオフやリトライを処理してくれるの？それとも自分たちでラップしなきゃいけないの？
MCP/AIの話は本当に面白いよね。ここ1年で書かれたAPIドキュメントの量は、過去5年分を合わせたよりも多いんだ。最初は「AIエージェントと連携させる」って感じだったけど、今は企業が人間もプログラム的に使えるものを作らざるを得なくなってる。エージェントの推進のいい副産物だね。
└
本当にそうだよね。今日も話してたんだけど、何年もドキュメントが不足してて人間が苦しむのはOKだったのに、いざ機械が必要になると、みんな必死になってツールを使いやすく、よくドキュメント化しようとしてるのが面白いよね。
└
まあ、今はLLMにドキュメントを書く仕事を任せられるからね。
└
これだね。最初からMCPに本当にワクワクしてたのは、手動でも使えるからなんだ。
└
FacebookがグループにアクセスするためのAPIを戻してくれることを願ってる。家族の写真がそこに入ってるからね。OpenClawの作者を買収できなかったから、ちょっと不安になってる。
└
このコメント、AIが生成したの？人を疑うのは好きじゃないけど、君のコメント履歴を見ると、ほとんどが「LLM-isms」の単一段落パターンに当てはまってるよね。これもそうだし（例えば「ここでのXの角度は本物だ -」みたいな）。
└
GoogleはAIゲームで徐々に勝つと思う。彼らはすべてを整えてて、無料で使えるし、オープンAIみたいにハイプに乗っかってるわけじゃないから、リアルを保ってる。
自分のプロダクトスイートのAPIをAIに公開するのは、ジェットコースターみたいな感じだったよ。最初はツール呼び出しのフック、次はMCP、そして後になってAIがコーディングが得意だって分かって、MCPが急にコードモードになった。で、みんながスキルはコンテキストに強いって気づいて、今やGoogleがCLIアプローチを始めた。覚えておいて、これはエージェントじゃないよ。ただG Suiteのドキュメントを操作するためのCLIツールで、MCPコマンドといくつかのスキルがあらかじめバンドルされてるだけ。新しい試みだね。エージェントがCLIをナビゲートするのが得意で、Microsoftのエコシステムに縛られずに誰でも使えるようになればいいなって思ってる。
Pipedreamみたいな統合ベンダーは、今やどの企業もMCPサーバーやCLIを出してAIブームに乗ってるから、やばいんじゃないかな？TwitterやRedditのAPIの問題があったから、どの企業も自分の庭の壁を壊して、大事なユーザーデータに簡単にアクセスさせるなんて考えられないよ。 rug pullが来るのを待ってる。
うわ、これはひどい。デフォルトに従って45分もかけてこれを動かそうとしてるのに、いろいろなエラーや問題が出てきた。今は`gws auth login`にいて、oAuthのスコープを選ぼうとしてるんだけど、デフォルトを信じて`recommended`を選んだら、スコープが多すぎてエラーになるって警告が出た（じゃあなんでこれが推奨設定なの？？）。で、ブラウザで認証しようとしたらエラーになる。エラーはアプリを確認する必要があるって言ってるから、クラウドコンソールのアプリ設定に行って確認しようとしたけど、スムーズな方法がない。どうやら、推奨リストにある85のスコープを一つずつ手動で追加して、実際の確認を通過しなきゃいけないみたい。これを作った人たちは、自分たちのハッピーパスに従って、実際にインストールして動かしてみたことあるの？
└
前回、Google SheetsでちょっとJSをやろうとしたときも、全部それをやらなきゃいけなかった。クイックスタートがgcloudの設定を必要としてるのを見たとき、試すのはやめようと思った。なんでGoogleは、15秒で終わるはずのこと（oAuthポップアップで「ok」をクリックするだけ）が、数十分から数時間の頭を抱える時間になるんだろう。
└
Googleの製品は、消費者向けの生産性ツール（Gmail、カレンダー、Meet）以外はほとんど不満だらけだよ。Google Cloudに飛び込むのは、すごく不満足だった。
└
同じようなイライラがあるよね。数年前に作った古いプロジェクト用のGoogleアプリを使って認証できたんだけど、たまたま必要な部分が揃ってたんだ。こんなにプロセスが難しいままでいるのは本当に驚きだよ。自分のアカウントにアクセスするためだけに使えるアプリのアイデンティティを安全に簡単に設定できる方法が絶対あるはずなんだ。俺の予想だと、Googleの中で開発者アプリの認証プロセスには多くのチームが関わってるんだろうし、外部のステークホルダーもたくさんいると思う。一つの統一されたチームがこの混乱や複雑さを担当してるわけじゃないんだろうね。理由は分かるけど…悪用するやつが多いからね。でも、もっと良い方法があるはずだよ。