Workspaceアドオンで「毎日の手作業」を消す方法

ミドリ： タツヤさん、Gmailとスプレッドシートとカレンダーをいったりきたりしながら手動で転記する作業が多すぎて、気が狂いそうなんですけど……。

タツヤ： わかる。Google Workspaceを使ってる企業あるあるだね。でも実は、そういう手作業を自動化する「アドオン」を自分で作れるって知ってた？

ミドリ： アドオンって、Marketplace にあるやつですか？ あれって企業が作ってるんだと思ってました。

タツヤ： もちろん企業が作ってるものも多いけど、GASを使えば特別なインフラなしに自前で開発できる。実際、Workspaceアドオンを導入した企業では、メール処理時間が平均45%削減、データ入力のヒューマンエラーが72%減少したっていう調査結果がある。

ミドリ： 45%削減！ それは作りたくなりますね。

タツヤ(nodding)： ちなみにGoogle Workspace Marketplaceに公開されてるアドオンは5,000を超えてて、日々増加してる。需要がそれだけあるってことだ。

アドオンの種類を知ろう

ミドリ： アドオンにも種類があるんですか？

タツヤ： 大きく2つある。開発前にどちらを選ぶか決めておくのが重要だ。

エディターアドオン

タツヤ： 1つ目がエディターアドオン。Googleスプレッドシート、ドキュメント、スライド、フォームに機能を追加するやつだ。

• HTML/CSSで自由度の高いUIを構築可能
• スプレッドシートのデータ加工や分析に強い
• ドキュメントのテンプレート生成やフォーマット変換に適している

ミドリ： 活用例でいうと？

タツヤ： たとえば、スプレッドシートの売上データを自動でグラフ化して、Googleスライドのレポートテンプレートに差し込むアドオン、とかね。

統合型アドオン

タツヤ： 2つ目が統合型。Gmail、カレンダー、ドライブなど複数のサービスにまたがって動作するアドオンだ。

• 1つのアドオンがGmail、カレンダー、ドライブなど複数のホストアプリで動作
• Card Serviceによる統一的なUI（各サービスで一貫した操作感）
• コンテキストトリガーで、メール内容やカレンダーイベントの情報をリアルタイム取得可能

ミドリ： さっき言ってた「Gmailとカレンダーの間の転記」を解決するなら、こっちですね。

タツヤ： 正解。特定のエディターに特化した機能ならエディターアドオン、複数サービスを横断するなら統合型、と覚えておこう。

開発環境のセットアップ

ミドリ： 実際に作るには何が必要ですか？

タツヤ： 4つ準備すればOK。

1. Googleアカウント — テスト用を別途用意するのがおすすめ
2. Node.js（バージョン18以上推奨） — 後述するclaspの実行に必要
3. clasp — ローカル開発環境でGASプロジェクトを管理する公式CLIツール。npm install -g @google/clasp でインストール
4. コードエディタ — VS Code推奨。GAS/TypeScript用のエクステンションを追加すると補完が効く

claspを使う理由

ミドリ： claspって使わなきゃダメですか？ GASのWebエディタでいいような……。

タツヤ： 小さなスクリプトならWebエディタでもいいけど、アドオン開発ではclaspを強く推奨する。最大のメリットはローカルのエディタで開発し、Gitでバージョン管理できること。

• お気に入りのエディタのショートカットや拡張機能が使える
• Gitによる変更履歴の管理とチーム開発が可能
• TypeScriptでの開発がサポートされ、型安全なコードが書ける
• CI/CDパイプラインとの連携が可能

ミドリ： 基本的なワークフローは？

タツヤ： こんな感じだ。

1. clasp login でGoogleアカウントと連携
2. clasp create --type webapp で新規プロジェクト作成（既存なら clasp clone <スクリプトID>）
3. ローカルでコード編集
4. clasp push でGASプロジェクトにアップロード
5. clasp deploy でデプロイ

TypeScriptでの開発

ミドリ： TypeScriptも使えるんですか？

タツヤ： 使える。型定義ファイル @types/google-apps-script をインストールすれば、GAS固有のAPIにも型補完が効くようになる。規模の大きなアドオンやチーム開発では、バグの早期発見に貢献するから必須と言っていい。

Card ServiceでUIを作る

ミドリ(thinking)： 統合型アドオンのUIって、どうやって作るんですか？

タツヤ： Card Serviceっていうフレームワークを使う。カード、セクション、ウィジェットの階層構造でインターフェースを定義するのが基本。主要なコンポーネントをまとめるとこうなる。

UIデザインの4原則

ミドリ： UIを作るときのコツってありますか？

タツヤ： 4つの原則を守ろう。

• 情報の階層を明確に — 最重要な情報をカードの上部に配置し、詳細はセクションで段階的に展開
• アクションを分かりやすく — ボタンのラベルは「実行する」「保存する」のように動詞で始める。「OK」みたいな曖昧なラベルはNG
• フィードバックを即座に返す — 処理中はローディング表示、完了後は結果を明確に表示
• エラーメッセージは具体的に — 「エラーが発生しました」ではなく「メールの送信先アドレスが入力されていません」

マニフェストファイルの設定

ミドリ： 設定ファイルも必要なんですよね？

タツヤ(nodding)： うん、appsscript.json がアドオン開発の要だ。特に重要な設定項目は3つ。

• oauthScopes — アドオンが必要とするGoogleサービスへのアクセス権限。最小権限の原則に従って、必要最低限だけ指定する
• addOns — 各ホストアプリ（Gmail、カレンダーなど）でのトリガー設定
• urlFetchWhitelist — 外部APIへのアクセスを許可するURL一覧

ミドリ： 「最小権限の原則」って？

タツヤ： 必要ない権限は設定しない、ってこと。よくある失敗が「とりあえず広い権限を設定しておく」パターン。セキュリティリスクが上がるだけじゃなくて、ユーザーがインストール時に過剰な権限要求を見て離脱する原因にもなる。

実践例1：Gmailメール分類・自動ラベリングアドオン

ミドリ： 具体的なアドオンの例を見たいです。

タツヤ(nodding)： まずはGmailのメール分類アドオン。受信メールの内容を分析して、自動的にラベルを付与するやつだ。

実装する機能：

• メール本文の自然言語処理による分類（問い合わせ、見積依頼、請求関連、社内連絡など）
• カスタムルールに基づくラベル付与
• 優先度の自動判定（高・中・低の3段階）
• 日次サマリーレポートの自動生成とSlack通知

アーキテクチャ

タツヤ： 構成はこの5つのコンポーネントだ。

1. コンテキストトリガー — メール開封時に起動し、メール情報を取得
2. 分類ロジック — メール本文とヘッダー情報をもとにカテゴリと優先度を判定
3. ラベル管理 — Gmailのラベルを自動作成・付与
4. UI表示 — 分類結果をカード形式で表示し、手動でのカテゴリ変更も可能に
5. タイムトリガー — 毎日定時にサマリーレポートを生成・送信

導入効果

ミドリ： 効果はどのくらいですか？

タツヤ： このタイプのアドオンを実装した企業のデータがある。

• メール仕分けにかかる時間：1日あたり平均45分 → 8分（82%削減）
• 重要メールの見落とし件数：月平均12件 → 2件以下
• 対応優先度の判断ミス：月平均8件 → 1件以下

ミドリ： メール仕分けだけで1日37分の節約……月間で12時間以上ですね。

実践例2：カレンダー連携スケジュール管理アドオン

ミドリ： カレンダー連携の例も知りたいです。

タツヤ： メール内のスケジュール情報を自動検出して、カレンダーイベントとして登録するアドオンだ。

実装する機能：

• メール本文から日時・場所・参加者の情報を自動抽出
• カレンダーイベントのプレビュー表示と確認後の自動登録
• 競合する予定がある場合のアラート表示
• リマインダーの自動設定

ミドリ： 「来週の水曜午後」みたいな自然言語も解析できるんですか？

タツヤ： そこが技術的なポイント。正規表現による定型パターンのマッチング（「2026年4月15日 14:00」など）と、自然言語解析による柔軟な解釈（「来週の水曜午後」など）を組み合わせる。「再来週の月曜」「今月末」みたいな日本語特有の表現にも対応するパターンライブラリが必要になるけどね。

テストとデバッグ

ミドリ： 開発したアドオンのテストってどうやるんですか？

タツヤ： 「テストデプロイメント」機能を使う。本番環境に影響を与えずに、実際のWorkspace環境でテストできるよ。

1. Apps Scriptエディタで「デプロイ」→「テスト デプロイメント」を選択
2. テスト対象のアプリケーション（Gmail、カレンダーなど）を指定
3. テスト用アカウントでアドオンの動作を確認
4. 問題があればコードを修正し、再テスト

デバッグのコツ

ミドリ： デバッグで気をつけることは？

タツヤ： 3つある。

• Card Serviceの構築エラーは実行時にしか検出されないから、UIのテストは特に入念にやること
• 外部APIとの通信エラーは、UrlFetchApp.fetch() のレスポンスコードとボディを必ずログ出力する
• タイムトリガーで起動する処理は、手動実行でも同じ結果になることを先に確認する

ミドリ： ログ出力は Logger.log() でいいんですか？

タツヤ： 開発中の簡易デバッグなら Logger.log() でOK。本番環境のエラー監視には console.log()（Google Cloud Loggingに出力される）を使おう。あとclaspとTypeScriptを使う場合は、ビジネスロジック部分を分離してJest等でユニットテストも実行可能だ。

公開とデプロイ

社内限定公開

ミドリ： 作ったアドオンを社内で共有するにはどうすれば？

タツヤ： Google Workspace管理者が組織内限定で公開できる。Marketplace審査は不要で、比較的短時間でデプロイ可能。まず社内限定で公開してフィードバックを収集し、十分にブラッシュアップしてからMarketplace公開を検討するのがセオリーだ。

Marketplace公開

ミドリ： 外部にも公開したい場合は？

タツヤ： Marketplaceへの申請が必要で、審査には通常1〜2週間かかる。公開前のチェックリストをまとめておこう。

• セキュリティレビューの完了（OAuth同意画面の検証を含む）
• プライバシーポリシーの準備と公開URL
• ユーザーガイド/ヘルプドキュメントの作成
• OAuth同意画面の設定と承認
• スクリーンショット（最低3枚）とアイコンの準備
• サポート連絡先の設定
• 利用規約の準備

パフォーマンスとコスト管理

ミドリ(confused)： GASの制限ってアドオン開発でも関係しますよね？

タツヤ(smiling)： めちゃくちゃ関係する。制限を意識した設計が重要だ。

パフォーマンス最適化

ミドリ： 制限に引っかからないようにする方法は？

タツヤ： 4つのポイントを押さえよう。

• バッチ処理の活用 — メールやスプレッドシートの操作は個別ではなく一括で行う
• キャッシュサービスの利用 — CacheService で外部API呼び出しの結果をキャッシュ
• PropertiesServiceの活用 — 設定値や状態情報を永続化し、毎回の再計算を避ける
• UrlFetchApp.fetchAll() — 複数の外部APIを呼び出す場合は、並列リクエストで実行時間を短縮

まとめ

ミドリ： 今日の話をまとめると？

タツヤ： Workspaceアドオンは、日常的に使うビジネスツールに直接カスタム機能を組み込める非常に強力な仕組みだということ。GASの基本とCard Serviceの構造を押さえれば、チームの生産性を大幅に向上させるアドオンを比較的短期間で開発できる。

ミドリ： ポイントを振り返ると？

タツヤ： 5つだ。

• アドオンの種類選択を正しく行い、目的に合った開発アプローチを選ぶ
• claspとTypeScriptを活用して、保守性の高い開発環境を構築する
• 最小権限の原則を守り、セキュリティとユーザー信頼を確保する
• テストデプロイメントを活用して、本番環境に影響を与えない開発サイクルを回す
• GASの実行制限を理解し、パフォーマンスを意識した設計を行う

次のアクション

ミドリ： これからアドオン開発を始める人は、まず何をすれば？

タツヤ： 3ステップだ。

1. 業務課題の特定 — チームが日常的にやってる手作業の中から、自動化のインパクトが大きいものを1つ選ぶ
2. プロトタイプの作成 — claspをセットアップして、選んだ課題を解決する最小限のアドオンを開発する
3. チームでのテスト — テストデプロイメントでチームメンバーに試用してもらい、フィードバックを収集する

Shimanto AI Solutionsでは、Google Workspace環境の業務効率化をGASアドオン開発で支援しています。「こんな作業を自動化できないか」という段階からのご相談も歓迎しています。