はじめに
everything-claude-code（ECC） は、Claude Code・Codex・Cursor・OpenCode など、複数の AI コーディングエージェントで使える スキル・フック・エージェント・ルールの統合パッケージです。
ざっくり言うと、AI コーディングエージェントに対して、
こういう場面では、このルールで動いてね
この作業では、この手順を守ってね
このツールを使うときは、このコマンドを使ってね
という作業ルールを追加するためのセットです。
ECC には、エージェント、スキル、コマンドシムなどが含まれており、その中の一つに google-workspace-ops というスキルがあります。
ECC で公開されているスキル一覧はこちらで解説しています。
https://qiita.com/shin_takoyaki/items/7b9e41571d67b2dca4b9
google-workspace-ops とは
google-workspace-ops は、Google Drive・Docs・Sheets・Slides を一つのワークフロー面として操作できるようにするスキルです。
スキルの公式説明（概要）
Operate across Google Drive, Docs, Sheets, and Slides as one workflow surface for plans, trackers, decks, and shared documents. Use when the user needs to find, summarize, edit, migrate, or clean up Google Workspace assets without dropping to raw tool calls.
要するに、Google Drive、Google Docs、Google Sheets、Google Slides などをバラバラのサービスとして扱うのではなく、一つの作業場所のように扱えるようにするスキルです。
たとえば、普通に考えると Google Drive のファイル検索、Google Docs の本文確認、Google Sheets の表編集、Google Slides のスライド編集は、それぞれ別々の操作です。
でも google-workspace-ops を使うと、Codex に対して次のように自然な言葉で依頼しやすくなります。
Google Drive の「テスト」フォルダにある
「コーヒーの豆知識」という Google ドキュメントを探して、
500文字で要約して
つまり、やりたいことはこうです。
Codex CLI
↓
google-workspace-ops スキル
↓
gws-cli
↓
Google Drive / Docs / Sheets / Slides
ここで重要なのは、Codex が Google Drive を直接操作しているわけではないという点です。
実際には、gws-cli という CLI ツールを間に挟み、その操作ルールを google-workspace-ops スキルとして Codex に教えます。
google-workspace-ops でできること
| 操作 | 対応サービス |
|---|---|
| ファイルの検索・要約 | Drive |
| ドキュメントの読み取り・編集 | Docs |
| セルの読み書き・フォーマット | Sheets |
| スライドの作成・テキスト挿入 | Slides |
| ファイルの移行・クリーンアップ | Drive |
ただし、最初から編集・削除・送信などの操作を許可するのは危ないです。
この記事では、まず 読み取り専用に近い安全な使い方として、Google Drive 上のファイルを探して、Google Docs の内容を要約するところまでを試します。
この記事でやること
この記事では、次の流れで進めます。
- Codex CLI をインストールする
-
uv/uvxをインストールする -
gws-cliを使える状態にする - Google Cloud Console で OAuth 認証情報を作る
- 認証情報 JSON を
gws-cliに読み込ませる - ECC リポジトリから
google-workspace-opsスキルを用意する - Codex から Google Docs の要約を試す
前提イメージ
先に全体像を押さえておきます。
Codex CLI とは
ターミナル上で使う AI 開発支援ツールです。
VS Code のような画面ではなく、コマンドラインから AI に指示を出して、ファイルの確認・修正・コマンド実行などを進めます。
gws-cli とは
Google Workspace をコマンドラインから操作するためのツールです。
たとえば、Google Drive のファイルを検索したり、Google Docs の内容を読んだりできます。
OAuth とは
外部ツールに Google アカウントのデータへアクセスさせるための許可の仕組みです。
たとえば、Google ログインでよく見るこのような画面です。
このアプリに Google Drive のファイルを表示する権限を許可しますか？
Google は、知らないツールにいきなり Drive や Docs を触らせません。
そのため、Google Cloud Console で「このツールは Google API を使います」と登録し、ユーザー本人が許可する必要があります。
Codex CLI をインストールする
まず Codex CLI をインストールします。
npm install -g @openai/codex
codex --version # バージョンが表示されればOK
codex --version でバージョンが表示されれば、Codex CLI は使える状態です。
uv をインストールする
次に uv をインストールします。
sudo apt update
curl -LsSf https://astral.sh/uv/install.sh | sh
python3 --version # バージョンが表示されればOK
uvx --version # バージョンが表示されればOK
uv / uvx とは
かなりざっくり言うと、Python 製ツールを簡単に実行するためのものです。
今回使う gws-cli は Python 系のツールなので、uvx 経由で実行します。
uvx gws-cli ...
という形で使います。
Google Workspace CLI を使える状態にする
次のコマンドを実行します。
uvx gws-cli account add personal
add personal って何？
結論
personal は、**自分で決めるアカウントの名前（ラベル）**です。
どういう意味？
uvx gws-cli account add personal
これは、ログインする Google アカウントを、ローカル環境では personal という名前で管理する、という意味です。
よくある勘違い
× personal = Google アカウント名
○ personal = 自分のPC内で管理するためのラベル
Google アカウントのメールアドレスそのものではありません。
なぜ必要？
複数の Google アカウントを使い分けるためです。
uvx gws-cli account add work
uvx gws-cli account add personal
たとえば、仕事用は work、個人用は personal のように分けられます。
ポイント
- 名前は自由
-
personalではなくworkやtestでもOK - 後から見てわかる名前にするのが大事
gws-cli の権限状態を確認する
次のコマンドで、Google Workspace の各機能が使える状態か確認できます。
uvx gws-cli config list
実行結果の例です。
{
"status": "success",
"operation": "config.list",
"services": {
"docs": true, # Google Docs を操作できる
"sheets": true, # Google Sheets を操作できる
"slides": true, # Google Slides を操作できる
"drive": true, # Google Drive のファイルを操作できる
"gmail": true, # Gmail を操作できる
"calendar": true, # Google Calendar を操作できる
"contacts": true, # Google Contacts を操作できる
"convert": true # ファイル変換ができる
},
"enabled_count": 8,
"total_count": 8
}
ここで true になっているものが、gws-cli から操作できるサービスです。
uvx gws-cli account set-readonly personal を実行すると、personal アカウントは読み取り専用になります。
お試し段階では、事故防止のために readonly にしておくのがおすすめです。
たとえば、誤ってファイルを編集したり、メールを送ったりするリスクを下げられます。
書き込み操作をしたい場合は、次のように読み取り専用を解除する必要があります。
uvx gws-cli account unset-readonly personal
Google Cloud Console で OAuth 認証情報を作る
ここからは Google Cloud Console 側の設定です。
gws-cli から Google Drive や Google Docs を操作するには、Google 側に「このツールからアクセスします」と登録する必要があります。
参考: OAuth 2.0 を使用して Google API にアクセスする
Google API Console を開く
Google API Console にアクセスします。
左メニューから次の順に進みます。
API とサービス
↓
ライブラリ
次の画面が表示された場合は、2段階認証が必要です。
設定に移動して、2段階認証を有効化してから再度アクセスします。
使いたい API を有効化する
今回は Google Workspace 関連の操作をしたいので、必要な API を検索して有効化します。
Google Drive API
Google Docs API
Google Sheets API
Google Slides API
Gmail API
Google Calendar API
使いたい機能だけ有効化すればOKです。
たとえば Drive と Docs だけ試すなら、最初は Google Drive API と Google Docs API だけでも問題ありません。
OAuth 同意画面を設定する
左メニューから次の順に進みます。
API とサービス
↓
OAuth 同意画面
OAuth 同意画面とは
Google ログインや Google Drive 連携をするときに、次のような画面を見たことがあるはずです。
〇〇 が Google アカウントへのアクセスを求めています
このアプリに以下を許可しますか？
・Google ドライブのファイルを表示する
・Google ドキュメントを表示、編集する
・Google スプレッドシートを表示、編集する
これが OAuth 同意画面です。
要するに、Google アカウントの持ち主に対して、
このツールに、あなたの Google データへのアクセスを許可しますか？
と確認する画面です。
ブランディングを設定する
左メニューから「ブランディング」を選択し、「開始」を押します。
入力する項目は主に次の通りです。
| 項目 | 意味 |
|---|---|
| アプリ情報 | 認証時に表示されるアプリ名 |
| ユーザーサポートメール | 認証画面に表示される問い合わせ先 |
| 対象 | アプリを使えるユーザー範囲 |
| 連絡先情報 | Google から開発者へ連絡するためのメール |
アプリ情報
認証画面で表示される名前です。
〇〇 が Google アカウントへのアクセスを求めています
この 〇〇 に入る名前だと考えるとわかりやすいです。
ユーザーサポートメール
認証画面に表示される問い合わせ先です。
たとえば、ユーザーが「このアプリ怪しいけど、誰に問い合わせればいいの？」となったときに表示されます。
対象
アプリを使えるユーザーの範囲です。
内部: Google Workspace 組織内のユーザーだけが使える
外部: 自分の個人 Google アカウントなど、組織外のユーザーも使える
連絡先情報
Google 側から開発者に連絡するためのメールアドレスです。
公開ステータスについて
今回は個人で試す用途なので、本番環境には公開しません。
テストユーザーを追加する
アプリを本番公開していない場合、誰でも使えるわけではありません。
未公開のアプリを使うには、テストユーザーとして Google アカウントを登録する必要があります。
つまり、gws-cli で認証したい Google アカウントを、テストユーザーに追加します。
公開設定のざっくり整理
| 使い方 | 設定例 | 本番公開は必要？ |
|---|---|---|
| 自分だけで試す | External + Testing + テストユーザー | 不要 |
| 組織内の人だけで使う | Internal / 内部 | 基本不要 |
| 組織外・不特定多数にも使わせる | External + In production | 必要になりやすい |
自分だけで試すなら、External + Testing + テストユーザー で十分です。
逆に、組織外の不特定多数に使わせるなら、本番公開や Google の審査が必要になる可能性があります。
OAuth クライアント ID を作成する
次に OAuth クライアント ID を作成します。
左メニューから次の順に進みます。
API とサービス
↓
認証情報
↓
認証情報を作成
↓
OAuth クライアント ID
OAuth クライアント ID とは
目的
gws-cli から Google Drive / Docs / Sheets などを操作するために使います。
Google は、登録されていない外部ツールに対して、いきなり Drive や Docs を触らせません。
そのため、gws-cli は Google に対して次のように伝える必要があります。
私は Google Cloud Console に登録済みのアプリです。
このユーザー本人にログインしてもらって、
Drive / Docs を使う許可をもらいたいです。
このときに必要なのが OAuth クライアント ID です。
もっと簡単に言うと、Google API を使うための「アプリの身分証明書」のようなものです。
アプリケーションの種類を選ぶ
今回は gws-cli を PC や WSL / Ubuntu 上で動かすので、OAuth クライアントの種類は デスクトップ アプリ を選択します。
名前
認証情報一覧に表示される名前です。
Google Cloud Console 上で自分が管理しやすくするための名前なので、自分が後から見てわかる名前を入力します。
JSON ファイルをダウンロードする
OAuth クライアント ID を作成したら、JSON ファイルをダウンロードします。
この JSON ファイルには、gws-cli が Google API を使うために必要な情報が入っています。
この JSON ファイルは GitHub などに公開しないようにします。
秘密鍵そのものではありませんが、外部ツールが Google API 認証を開始するための情報なので、雑に公開するものではありません。
認証情報 JSON を gws-cli に読み込ませる
ダウンロードした JSON ファイルを gws-cli に読み込ませます。
uvx gws-cli auth import-credentials ~/Downloads/client_secret_xxxxxxxxxxxxx.apps.googleusercontent.com.json
~/Downloads/... の部分は、自分がダウンロードした JSON ファイルのパスに置き換えてください。
ECC リポジトリの取得とスキルのセットアップ
次に、Codex から Google Workspace 操作をしやすくするためのスキルを用意します。
リポジトリをクローンする
git clone git@github.com:affaan-m/everything-claude-code.git
スキルを Codex のスキルディレクトリにコピーする
今回はグローバルで使用できるように ~/.codex/skills/ に配置します。
プロジェクト単位で管理したい場合は、プロジェクト直下に配置します。
### スキルやエージェントルールの読み込み順
global (~/.codex)
↓
project root (.codex / AGENTS.md)
↓
current dir
ざっくり言うと、全体設定 → プロジェクト設定 → 現在の作業ディレクトリ、という順番でルールが適用されます。
Codex を起動し、/skills でスキル一覧に google-workspace-ops が表示されたらOKです。
SKILL.md を調整する
スキルをコピーしただけではうまくいかなかったため、今回は SKILL.md を次のように編集しました。
主な変更点は次の2つです。
- 日本語で理解しやすくした
- Google Workspace 操作では
uvx gws-cliを使うことを明示した
SKILL.md の例
---
name: google-workspace-ops
description: Google Drive、Docs、Sheets、Slides を横断し、計画書・管理表・スライド・共有ドキュメントを検索・確認・要約・整理案作成するためのスキル。read-only 設定時は編集・削除・送信・共有変更を行わない。
origin: ECC
---
# Google Workspace Ops
このスキルは、共有ドキュメント、スプレッドシート、スライドを単体ファイルとして扱うのではなく、業務上の作業システムとして扱うためのものです。
## 使用する場面
- ユーザーがドキュメント、スプレッドシート、スライドを探し、必要に応じてその場で更新したい場合
- Google Drive に保存された計画書、管理表、議事録、顧客リストなどを統合したい場合
- 共有スプレッドシートを整理・再構成したい場合
- Google Slides のデッキをインポート、修復、再フォーマットしたい場合
- Docs、Sheets、Slides の内容をもとに、意思決定に使える要約を作成したい場合
## 優先する操作方針
Google Drive を入口として使用し、その後、対象に応じて適切な専門ツールに切り替えること。
- 文章中心のドキュメントは Google Docs を使う
- 表形式のデータ、数式、グラフは Google Sheets を使う
- スライド、インポート、テンプレート移行、レイアウト調整は Google Slides を使う
ファイル名だけで構造を推測しないこと。必ず先に中身を確認すること。
## 必須コマンドルール
- Google Workspace 操作では必ず `uvx gws-cli` を使うこと
- `gws` を直接呼び出さないこと
- Google Workspace API を直接呼び出さないこと
- コマンド構文を推測しないこと
- 正確な構文が不明な場合は、実行前に必ず `uvx gws-cli ... --help` を確認すること
- アカウントが read-only に設定されている場合、書き込み操作を試みないこと
## 安全ルール
- 最初は必ず読み取り系の操作を優先すること
- メール送信、ファイル削除、共有権限変更、Docs 編集、Sheets 更新、Slides 編集、Calendar 更新、Contacts 更新は、ユーザーの明示的な許可なしに実行しないこと
- 破壊的操作や元に戻しづらい操作を行う前に、必ず現在の状態・予定している変更・影響範囲を説明すること
- 複数ファイルが関係する場合は、正規ファイルと重複ファイルを区別してから作業すること
## ワークフロー
### 1. 対象ファイルを探す
まず Drive の検索機能を使って、以下を特定する。
- 正確な対象ファイル
- 関連する兄弟ファイル
- 重複の可能性があるファイル
- 最近更新されたバージョン
似たようなドキュメントが複数ある場合は、タイトル、所有者、更新日時、フォルダなどを確認して判定すること。
### 2. 編集前に確認する
変更を加える前に、以下を確認する。
- 現在の構造を要約する
- Docs の見出し、Sheets のタブ、Slides の枚数などを確認する
- 依頼内容が局所的な修正なのか、構造全体の整理なのかを判断する
安全に作業できる最小のツールを選ぶこと。
### 3. 精密に編集する
- Docs では、曖昧な全文書き換えではなく、位置や構造を意識した編集を行う
- Sheets では、明確なタブ名とセル範囲に対して操作する
- Slides では、本文編集・見た目の調整・テンプレート移行を区別する
視覚的な調整やレイアウトが重要な作業では、一度に大きく変更せず、確認と検証を挟みながら進めること。
### 4. 作業システムを整理された状態に保つ
対象ファイルが大きな業務フローの一部である場合は、必要に応じて以下も確認する。
- 重複している管理表
- 古くなったスライド
- 古いドキュメントと正規ドキュメントの違い
- アーカイブ、統合、リネームすべきファイルがあるか
## 出力形式
以下の形式で出力すること。
ASSET
- ファイル名
- 種類
- このファイルが正しい対象である理由
CURRENT STATE
- 構造の要約
- 主な問題点または作業上の障害
ACTION
- 実施した編集、または推奨する編集
FOLLOW-UPS
- アーカイブ、統合、重複整理、次に更新すべきファイル
## 良い使用例
* 「現在有効な計画書を探して、内容を短くまとめて」
* 「この顧客管理スプレッドシートを整理して、解約リスクが高い行を出して」
* 「このスライドを Google Slides に取り込んで、発表できる状態に整えて」
* 「古い重複ファイルではなく、現在使われている管理表を探して」
実際に使ってみる
最後に、実際に Codex から Google Docs の要約を試します。
試したこと
文字数が 9922 ある資料を、500文字 で要約してもらいました。
Codex には次のように依頼しました。
$google-workspace-ops 「テスト」フォルダにあるドキュメント「コーヒーの豆知識」を500文字で要約して
認証を求められた場合
初回実行時は、認証用 URL が表示されることがあります。
その場合は、出力された URL にアクセスして Google アカウントで認証します。
「続行」を押します。
認証が成功すると、次のような画面になります。
実行結果
Google Docs の内容を読み取り、指定した文字数で要約してくれました。
つまずきやすいポイント
1. personal は Google アカウント名ではない
personal はローカルで管理するためのラベルです。
uvx gws-cli account add personal
このコマンドは、Google アカウントそのものを personal に変更するわけではありません。
2. 未公開アプリはテストユーザーしか使えない
OAuth 同意画面を Testing にしている場合、テストユーザーに登録していない Google アカウントでは認証できません。
次のようなエラーが出る場合は、テストユーザー設定を確認します。
アクセスをブロック: このアプリは Google の審査プロセスを完了していません
自分だけで試す場合は、認証に使う Google アカウントをテストユーザーに追加すればOKです。
3. 最初は readonly にした方が安全
Google Workspace は、Docs の編集、Sheets の更新、Gmail 送信などもできるため、最初から書き込み可能にしておくと事故りやすいです。
まずは読み取り専用にして、Drive 検索や Docs 要約だけ試すのが安全です。
uvx gws-cli account set-readonly personal
4. JSON ファイルは公開しない
OAuth クライアントの JSON ファイルは、GitHub や Qiita のスクリーンショットにそのまま載せない方がいいです。
ファイル名や中身にクライアント ID が含まれるため、記事に載せる場合はマスクします。
まとめ
この記事では、Codex CLI から Google Workspace を操作するために、次の設定を行いました。
- Codex CLI のインストール
-
uv/uvxのインストール -
gws-cliのアカウント追加 - Google Cloud Console で API を有効化
- OAuth 同意画面の設定
- OAuth クライアント ID の作成
- 認証情報 JSON の読み込み
-
google-workspace-opsスキルのセットアップ - Google Docs の要約実行
全体像としては、Codex が直接 Google Drive を触るのではなく、gws-cli を通して Google Workspace を操作します。
Codex CLI
↓
google-workspace-ops スキル
↓
uvx gws-cli
↓
Google Drive / Docs / Sheets / Slides
最初は読み取り専用で始めて、ファイル検索や Docs 要約のような安全な操作から試すのがよいです。