Claude Code×GASで実現するGoogle Workspace自動化の全体像

Google Workspaceの自動化は2軸で切る。1軸目は対象データ(メール／予定／表計算／ファイル／フォーム)、2軸目は処理タイプ(分類・通知／作成・転記／連携・横断)。本記事の7レシピはこの交点から、副業・本業の両方で投資対効果が高い組み合わせを抽出した。

ムラサキ

レシピ集の中には、すでに本サイトで実装記録を公開しているものと、Claude Codeへの投げ方だけ示す構想中のものが混在している。順序通り読まなくても、刺さるレシピから着手して問題ない。

なぜ今Claude CodeとGASの組み合わせが最強なのか

GASは無料で動く、Googleの中で完結する、認証は自分のGoogleアカウントで済む。副業エンジニア向けの3拍子がそろっている。一方で「書きはじめるまでが面倒」が長年のネック。Apps Scriptエディタを開いて空のmain関数を眺めて閉じる、を何度繰り返したか分からない。

そこにClaude Code Max 5xが噛み合う。仕様だけプロンプトで投げれば、claspで同期して動くコードまで生やしてくれる。試運転→修正→本番デプロイをローカルから一気通貫で回せる。エディタUIを開く頻度が一気に下がる。

事前準備：clasp導入とAPI認証の最短セットアップ

Claude CodeでGASを書く前提として、claspをローカルに通しておく。ここを省くとClaude Codeが書いたコードをコピペで運ぶハメになり、結局スピードが落ちる。

これで Claude Code が書いたコードを clasp push するだけで反映される。

レシピ1〜2：Gmail自動仕分け＆下書き生成で受信箱ゼロ運用

受信箱が日々パンクするなら、最初に攻めるのはここ。判定とラベリングをGASに任せれば、人間の判断は重要メールへの対応だけに集中できる。

レシピ1：重要メールをAI判定してラベル＆通知振り分け

GmailApp.search() で未処理メールを引いて、件名と本文の冒頭500字をGemini APIまたはClaude APIに渡す。判定値は「至急 / 重要 / 通常 / 不要 / 営業」の5値固定。結果に応じてGmailラベル付与とSlack通知を発火させる。

Claude Codeに投げるプロンプト例:

Gmailの未読メールを取得し、本文を500字に切ってGemini APIで5値判定。
判定値に応じてラベル付与とSlack Webhook通知を発火させるGASを、
[main.gs/config.gs/api.gs](http://main.gs/config.gs/api.gs) の3ファイル構成で書いて。APIキーは
PropertiesService経由で参照すること。

ファイル分割と参照経路まで指定すると、Claude Codeが「とりあえず1ファイルに全部」とやらかすのを防げる。

レシピ2：定型問い合わせへの返信下書きを自動生成

このレシピはGAS×Gemini API無料枠でメール返信下書きを自動化した実装記録で5パターン判定＋下書き生成のスプレッドシート設計まで含めて公開済み。コピペで動くコードを起点に、自分の業務パターンに合わせて分類軸を組み替えるのが最短ルート。

レシピ1の判定ロジックと組み合わせると、「通知だけ済ませる」と「下書きまで作る」の出し分けが可能になる。

レシピ3〜4：カレンダーとTo Doを連動させる予定管理レシピ

予定が増えるほど、準備作業まで頭の中で持ち回すコストが膨らむ。それを引き剥がす2レシピ。

レシピ3：会議招待から準備タスクを自動でTo Doに登録

CalendarApp.getEventsForDay() で当日の予定を取り、件名と説明欄をAPIに渡してタスクをN個抽出。Google Tasks API(Apps Scriptの Advanced Service として有効化)で対象日に登録する。

たとえば「営業同行打合せ」なら「先方資料の確認」「ヒアリングシート更新」が当日朝に積まれる。トリガーは平日朝7時の時間ベースで十分。

レシピ4：空き時間を解析して集中作業ブロックを自動確保

カレンダーの空きをスキャンして、90分以上連続するスロットを「集中作業」というイベントで予約してしまう。トリガーは毎週日曜の夜、翌週分をまとめて押さえる方式が運用が楽。

クォータ・スコープ的にも CalendarApp 内で完結するので、追加API登録が要らない。組み込みコストが最も低いレシピで、効果が一番体感しやすい。

レシピ5〜6：スプレッドシート＆ドライブの定型作業を撲滅

表計算とファイル操作はGASの土俵そのもの。Claude Codeに任せれば実装スピードが段違いに上がる。

レシピ5：請求書・領収書PDFをドライブから自動仕訳

DriveAppで指定フォルダ配下のPDFを走査し、Gemini APIのドキュメント読み取りで請求元・金額・支払期日を抽出。スプレッドシートに追記したうえで、年月フォルダへ自動移動させる。

本業／副業／個人の混在ファイルでも、フォルダ命名規則と仕訳タグでまとめて捌ける。確定申告期に「未仕訳の山」を作らないための先行投資として効く。

レシピ6：スプレッドシートの数値変動をSlack/Chatへ即通知

売上、PV、Search Consoleの主要指標などをスプレッドシートにダンプし、前日比・前週比を onOpen() またはトリガーで判定。閾値超過時にSlackやGoogle Chatへ即時通知する。

スプレッドシート操作と通知連携のノウハウはGAS×NotebookLMで本業メール集約を自動化した実践記で扱っているスクリプトと共通基盤。通知部分だけ差し替えればそのまま流用できる。

レシピ7：フォーム回答からドキュメント＆メールまでワンストップ生成

申込・問い合わせフォームは「来た瞬間に処理を始めたい」典型ケース。手動の写経を完全に消す最後のレシピ。

レシピ7：申込フォーム→契約書ドラフト→送信を全自動化

Formsのトリガー onFormSubmit で回答を捕捉。Google Docsのテンプレートを DriveApp.getFileById().makeCopy() で複製し、Body内のプレースホルダを置換して契約書ドラフトを生成。PDF化して GmailApp.sendEmail で関係者に送信する。

副業のクライアント契約、子ども関連の同意書、社内申請書類まで、テンプレートと差し込み項目さえ用意すれば横展開できる。

Claude Codeで”雑な指示”からGASコードを生やすコツ

プロンプトは「画面で見える流れ」を時系列で書くのが効く。雑に投げても Claude Code が補完してくれるが、clasp push で動く前提を成立させるには以下3点だけ最初に明示する。

• 入力：何を／どこから／どのくらいの量
• 処理：使うAPI・必要スコープ・分岐ルール
• 出力：どこに／どの形式で／通知の要否

この型に乗せれば、初手のコードは8割そのまま動く。残り2割は実行ログを見せて修正させればよい。Claude Code の機能を体系的に押さえたいならClaude Code /powerup入門のレッスン7〜8(カスタムコマンドとHooks)を先に通すと、自動化レシピの組み立てそのものが速くなる。

運用時の注意点とトラブルシューティング

動いたの先にある運用フェーズで、これだけは事前に詰めておかないと事故る。

実行制限・権限スコープでハマらないための設計指針

GASにはApps Scriptの割り当て上限(メール送信、トリガー実行時間、外部API呼び出し回数など)がある。一気にバッチ処理を回すと無料アカウントは即上限に到達する。設計時に押さえる3点:

• 件数を分割して走らせる(1回あたり50件など上限を決め打ち)
• ユーザートリガーと時間ベーストリガーを使い分け、同時実行で衝突させない
• スコープは必要最小限。最初から script.external_request 全許可にしない

詳細な数値はGoogle公式のApps Scriptクォータページで確認できる。設計前に1回必ず開く。

個人情報・APIキーを守るセキュリティチェックリスト

副業で動かす場合、本業データとの混在が一番の事故ポイントになる。最低限のラインを固定しておく。

• APIキーは PropertiesService.getScriptProperties() 経由でのみ参照。コード直書き禁止
• Gitに .clasp.json を上げる場合、リポジトリは必ずPrivate
• 本業データを扱うスクリプトは個人GoogleアカウントとWorkspaceアカウントで分離。同居運用は事故の温床
• Webアプリ公開(doGet/doPost)は「自分のみ」「全員」のスコープを必ず明示確認

ここを守れば、運用中に冷や汗をかく場面は激減する。

よくある質問

まとめ

3点に集約する。

1. Google Workspaceの自動化は「対象データ×処理タイプ」の2軸でレシピ化すると見通しが立つ
2. Claude Codeに仕様だけ投げて clasp push まで一気通貫で回すと、書きはじめの腰の重さが消える
3. 制限・スコープ・キー管理は最初に固めないと運用フェーズで事故る

次のアクションは、レシピ2(メール返信下書き)のSE歴20年の業務自動化術で扱っている運用設計を起点に、自分の業務パターンに刺さるレシピから着手するのが最短ルート。

それから約半年後の2026年3月、Claude無料版を使ったバイブコーディングで、音声対話型のAIヒアリングシステムを2週間で開発しました。この記事では、設計から実装、トライアンドエラーの記録、月額$7〜8のコスト内訳まで、開発の全工程を包み隠さず公開します。

ムラサキ

2025年に心が折れた人にこそ読んでほしい記事です。AIのコード生成能力は半年で別物になっています。

バイブコーディングとは？2025年との決定的な違い

バイブコーディングの定義と基本の流れ

バイブコーディング（Vibe Coding）とは、AIに自然言語で「こういうものを作りたい」と指示し、コードを生成させる開発手法です。2025年にOpenAI共同創設者のAndrej Karpathy氏が提唱した概念で、従来のプログラミングのように構文を1行ずつ書くのではなく、AIとの対話を通じてシステムを構築していきます。

基本的な流れは「何を作りたいかを言葉で説明する → AIがコードを生成する → 動作を確認する → 問題があれば修正を指示する」の繰り返しです。使うツールはClaude Code、Cursor、ChatGPTなど複数ありますが、筆者はclaude.aiの無料プランを使いました。

2025年8月の挫折と2026年3月の成功

筆者は2025年8月にGitHub CopilotとChatGPTを使い、VSCodeの拡張機能からSQLフォーマッターを抜き出してWinMergeのプラグインに組み込む開発を試みました。結果は惨敗です。不具合が出るたびにAIが提案する修正が二転三転し、4回5回と方針が変わった末に答えにたどり着けませんでした。

2026年3月、Claude Sonnet 4.6がリリースされたタイミングで再挑戦しました。Anthropicの公式リリースによると、Sonnet 4.6はコーディング能力とエージェント的なタスク遂行能力が大幅に向上しています。実際に使ってみて、コード生成の正確性と文脈保持能力が2025年のツールとは別物だと感じました。半年でここまで変わるのかと驚いた、というのが率直な感想です。

今回作ったもの｜AIヒアリングシステムの概要

システムの全体像と機能

開発したのは、社内の採用業務で使うAI事前ヒアリングシステムです。エンジニア候補者に対して、面接前の事前確認をAIが自動で実施します。候補者はURLにアクセスするだけで音声による対話形式のヒアリングを受けられ、管理者は結果の確認と採否判定を行えます。

graph LR
    A["候補者ブラウザ"] -->|"音声録音"| B["React/Viteフロントエンド"]
    B -->|"API通信"| C["Node.js/Expressバックエンド"]
    C --> D["MongoDB Atlas候補者データ"]
    C --> E["AWS S3音声保存"]
    C --> F["Claude Haiku 4.5AI対話・評価"]
    C --> G["Whisper API音声→テキスト"]
    C --> H["Google TTSテキスト→音声"]
    style A fill:#e8f0fe,stroke:#4a86c8
    style B fill:#e8f0fe,stroke:#4a86c8
    style C fill:#e8f4e8,stroke:#5a9e6f
    style D fill:#f5f0e8,stroke:#c4a96a
    style E fill:#f5f0e8,stroke:#c4a96a
    style F fill:#f0e8f5,stroke:#9a7ab5
    style G fill:#f0e8f5,stroke:#9a7ab5
    style H fill:#f0e8f5,stroke:#9a7ab5

主な機能は、候補者向けのURL発行・音声対話・イニシャル表示による本人確認、管理者向けの候補者一覧・会話履歴確認・音声再生・評価レポート自動生成・採否判定です。AIは「面接官」ではなく「事前ヒアリング担当」として振る舞い、採否判断は一切行わない設計にしました。

技術スタックとコスト

初期費用はほぼ0円です。各サービスの無料枠で開始できました。2026年3月時点のランニングコストは月額約$7〜8で、内訳は以下の通りです。

Renderの料金ページによると、有料プラン（Starter $7/月）に上げるとスリープがなくなり本番運用に適した状態になります。MongoDB Atlasの無料枠（M0）は512MBのストレージを提供しており、開発・検証段階では十分です。Whisper APIは1分あたり$0.006と安価で、ヒアリング1回30分でも約$0.18です。

開発フローの実際｜環境制約でAIを使い分けた経緯

設計フェーズ ── Gemini Proで壁打ち

設計段階は本業の延長で進めていたため、Google WorkspaceのGemini 3.1 Proを使いました。アーキテクチャの検討、技術スタックの選定、コスト試算、開発ロードマップの策定をGeminiとの壁打ちで詰めていきました。

Geminiが得意だったのはアーキテクチャの比較検討です。「ターン制のREST API方式」と「WebSocketによるリアルタイム方式」の2パターンを提示させ、コスト・開発期間・UXのトレードオフを整理してもらいました。結論として、コスト優先でREST API方式を選択しています。

設計からコーディングへの情報の受け渡し

設計が固まった段階で、コーディング用の環境を準備しました。業務で使っているPCはソフトウェアのインストールが制限されており開発環境を構築できないため、別途スタンドアロンの開発用PCを用意しています。この開発用PCからはGoogle Workspaceに接続できないため、ブラウザだけで利用できるclaude.aiの無料プランをコーディング用AIとして選びました。

AIを乗り換える際に重要だったのが、設計フェーズで決めた内容の受け渡しです。Geminiとの長いチャット履歴をそのまま渡しても、過去のボツ案と最終決定をClaude側が混同してしまいます。そこでGeminiに「引き継ぎ用のドキュメントを作って」と依頼し、決定事項・進捗・次のアクションだけを圧縮した要約を作成しました。これをClaudeの最初のメッセージとして投げることで、情報のロスなく実装フェーズに移行できました。

実装フェーズ ── 無料のclaude.aiでバイブコーディング

claude.aiの無料プランでClaude Sonnet 4.6を使い、フロントエンド（React/Vite）・バックエンド（Node.js/Express）・各種API連携のコードを書いていきました。開発期間は2026年3月初旬から3月13日までの約2週間です。

驚いたのは、1つのチャットの中でフロントからバックエンド、API連携まで一貫して対応できたことです。以前のAIコーディングツールでは長いやり取りの中で方針がブレたり、過去の指示を忘れたりすることがありましたが、Claude Sonnet 4.6ではプロジェクト全体の流れを保ったまま開発を進められました。筆者がClaudeをブログ執筆に活用しているワークフローはClaudeでブログ記事を作成する実践ワークフローで公開していますが、記事作成とは異なり、バイブコーディングでは1つの長いチャットで完結できた点が印象的でした。

ぶつかった壁と解決策

開発中にぶつかった問題は10件以上あります。ここでは特に印象的だった3つを紹介します。

音声合成の選定 ── VOICEVOX → Google Cloud TTSへの移行

当初は無料の音声合成エンジンVOICEVOXを使用していましたが、Render環境での動作が不安定でした。ローカルでは問題なく動くのに、サーバー環境との相性が悪かったのです。この問題をClaudeに相談したところ、Google Cloud TTSのNeural2音声（ja-JP-Neural2-B）への移行を提案してきました。その通りに試したところ、自然な日本語音声を安定して生成できるようになりました。原因の切り分けから代替案の提示まで的確で、こいつやるなと感じた場面です。

AIが採否判断を下す問題

テスト中にAIが候補者に「この案件への参画は難しい判断となります」と直接断りを告げた場面がありました。ヒアリングシステムなのにAIが勝手に合否を伝えてしまうのは致命的です。プロンプトに「採否・合否・参画可否の判断は絶対にしないこと」「難しい・厳しいなど断りを示唆する表現は一切使わないこと」を明記して対処しました。バイブコーディングでは機能の実装だけでなく、AIの振る舞いの制御にも注意が必要です。

ムラサキ

AIが「情報収集に徹する」のか「判断まで下す」のかはプロンプト設計で明確に線引きする必要があります。ここをサボると本番で事故が起きます。

個人情報とファイルアップロードの方針転換

当初はスキルシートのPDF/画像をアップロードしてClaude APIで自動解析する機能を実装しました。しかし、外部のクラウドサービスに候補者の個人情報（氏名・住所等）を含むファイルを送信するリスクを考慮し、この機能は削除しました。代わりに、社内のセキュアな環境でスキルシートの個人情報をマスクしたテキストを作成し、システムにはマスク済みの情報のみを登録する運用に変更しています。個人情報を扱う部分は社内の閉じた環境に留め、外部に出るシステムには匿名化された情報だけが渡る設計です。

機能をまるごと削除する判断は一見もったいなく見えますが、むしろこれはバイブコーディングの強みが発揮された場面でした。AIに「この機能を削除して、関連箇所もすべて整合を取って」と指示すれば、一括で対応してくれます。人間がコードを手動で修正すると関連箇所の修正漏れ（デグレード）が起きるのが常ですが、AIはそのリスクを大幅に下げてくれました。AIの出力を検証・判断する力の重要性については生成AI時代に必要なスキルと若手教育の進め方でも解説しています。

バイブコーディングを成功させるコツと注意点

実装速度が上がるほどレビューの抜け漏れリスクも増える。LLMコードレビュー4手法の実測比較で、Claude Code 内蔵レビューを追加コストゼロで回す方法を解説している。

プログラミング経験があると何が有利か

バイブコーディングは「コードを書けなくてもアプリが作れる」と紹介されることがありますが、実際にはIT業界の用語や概念を知っているかどうかで、AIとのやり取りのスムーズさが大きく変わります。筆者自身、今回の開発でReactもNode.jsも手では書けませんし、生成されたコードの中身を読んで理解するというプロセスは一切踏んでいません。修正時にキーワード検索で該当箇所を目にすることはありますが、コードリーディングと呼べるものではありませんでした。

それでも2週間でシステムが完成したのは、S3・React・Node.js・環境変数・Gitといった用語をSEとして実務で利用していなくても知識があったため、AIとのキャッチボールがスムーズだったことが大きいと感じています。エラーが出たときも、エラーメッセージをそのままコピペするかスクリーンショットを貼るだけで、AIが原因を特定して修正案を出してくれました。長年コードレビューを担当してきた中で「ここは壊れやすい」「この設計だと後で困る」といった勘所が自然と身についていたことも、問題の早期発見に役立ったのかもしれません。

一方、これらの用語自体が初めての方は、AIへの質問を組み立てる段階で時間がかかります。バイブコーディング自体が不可能になるわけではありませんが、筆者の2週間という期間はこうした前提知識があっての数字です。筆者が実務で使っている業務自動化テクニックで紹介しているようなWindows標準機能やPowerShellの知識も、開発環境の構築で役立ちました。

経験があるとスケールも早い。Batch APIと組み合わせた3日間・713ページのpSEOサイト構築という規模感がその一例だ。

無料AIの制限との付き合い方

claude.aiの無料プランには数時間ごとのメッセージ上限があり、開発中に何度か上限に達しました。ただし本業の傍らで進めていたため、上限リセットまでの待ち時間は別の業務に充てられ、実質的な問題にはなりませんでした。それでも効率を意識した点が2つあります。

• エラー発生時はエラーメッセージをそのままコピペするかスクリーンショットを貼り付ける。自分で原因を解説しようとするより、生のエラー情報を渡す方がAIの回答が的確で早い
• 上限に達したらChatGPT（GPT-4oの無料枠）で軽い調査を進め、Claudeが復帰したらメインの開発に戻る

無料の範囲でも、今回のシステム規模（フロント1ファイル・バックエンド1ファイル・管理画面1ファイル）なら十分に開発を完了できました。

妥協の判断基準

すべてを理想通りに実装しようとすると、無料枠の制限や開発期間の中では終わりません。筆者は以下の基準で妥協を判断しました。

「8割の精度で動くものを素早く作り、使いながら改善する」のがバイブコーディングの強みです。完璧を目指して動かないより、まず動くものを完成させる方が結果的に早く前に進めます。

よくある質問（FAQ）

まとめ

この記事では、Claude無料版を使ったバイブコーディングで業務システムを2週間で開発した全工程を紹介しました。要点を3つに絞ります。

バイブコーディングは「完璧なコードを一発で書く」ツールではなく、「試行錯誤のサイクルを高速に回す」ツールです。ぶつかった壁は10件以上ありましたが、そのすべてをAIとの対話で解決できました。作りたいものがあるなら、まず小さな機能1つから始めてみてください。

ムラサキ

2025年に心が折れた筆者が、半年後にシステムを完成させられました。AIの進化を待っていた人は、そろそろ動き出すタイミングです。

2026.03.20 更新：コードレビューエージェントの進捗を更新（パイロット運用開始・簡素化の経緯を追記）、自動化テクニック比較表を追加

SEとして20年、同じ会社で働いている。この20年で「自分の仕事を自分で楽にする」ことだけは一貫して続けてきた。

大規模な業務改革ではない。SendToフォルダに自作ツールを入れる、PowerShellでパスを取得する、Seleniumで入力チェックを回す。どれも小さい。しかし小さいものが積み重なると、1日のうち30分から1時間は確実に浮く。年間にすれば200時間になる。

本記事では、筆者が実務で実際に使っている自動化テクニックを紹介する。華やかなツール紹介ではなく、「Windows標準の範囲内で動くこと」「管理者権限がなくても使えること」「Windows 10と11の両方で動くこと」という現場の制約下で生まれたものばかりだ。

本記事で紹介する自動化テクニック一覧

難易度「低」のSendToカスタマイズから順に紹介する。自分の業務で「面倒だ」と感じている作業に近いものから読み進めてほしい。

SendToフォルダのカスタマイズ｜右クリックを自分専用にする

Windowsの「送る」メニューは、ファイルやフォルダを右クリックしたときに表示される。このメニューの実体は「shell:sendto」で開けるフォルダに入っているショートカットだ。ここに自作ツールのショートカットを置けば、右クリックから一発で任意の処理を実行できる。

筆者が登録しているのはパス取得ツールだ。ファイルやフォルダを「送る」だけで、そのフルパスをクリップボードにコピーする。手順書やチャットでパスを共有する場面は毎日ある。エクスプローラーのアドレスバーをクリックしてコピーしてもいいが、ファイル単位のパスが欲しい場面ではこちらの方が早い。

登録方法はシンプルで、Win+Rで「shell:sendto」を実行し、開いたフォルダにショートカットを置くだけだ。特別な権限は不要で、自分のユーザーフォルダ配下なので管理者権限も要らない。

PowerShellでSharePointのパスを一発取得する

SharePointのファイルをローカル同期している環境では、同期フォルダのパスにユーザー名が含まれる。たとえば「C:Usersyamada会社名チーム名ドキュメント」のような構成だ。これをそのままチームに共有しても、他のメンバーの環境ではパスが通らない。

PowerShellでユーザー固有の部分を環境変数に置換するスクリプトを作った。実行すると、ユーザー名の部分が「%USERPROFILE%」に置き換わった汎用パスがクリップボードに入る。これをチャットに貼れば、誰の環境でもそのまま使える。

やっていることは文字列の置換だけだが、毎日5回以上パスを共有する業務では効果が大きい。こうした「1回10秒の手間」を潰すことが、自動化の第一歩だと思っている。

Excel/Accessのモジュールを自動エクスポートする

VBAで業務ツールを開発していると、モジュールのバージョン管理が課題になる。Gitで管理したくても、VBAのコードはExcelファイルの中に格納されているため、そのままではdiffが取れない。

この問題を解決するために、カスタムスクリプトでExcelやAccessからVBAモジュールとシート情報を自動エクスポートする仕組みを作った。エクスポートしたテキストファイルをGit管理すれば、変更履歴が追える。

さらに、SpreadsheetCompareと連携させて2つのExcelファイルの差分を一発で表示する機能も追加した。レビュー時に「どこが変わったのか」を目視で確認する手間がなくなった。EUC（エンドユーザーコンピューティング）の開発では、こうした周辺ツールの整備が品質と保守性に直結する。

ExcelVBAの設計思想や効率化テクニックはこちら

Seleniumでメンバーの入力内容を自動チェックする

チームメンバーがWebシステムに入力したデータの整合性チェックを、Python＋Seleniumで自動化している。以前は目視で確認していたが、件数が増えると見落としが出る。ブラウザを自動操作して入力内容を取得し、ルールに照らしてNGを検出する仕組みだ。

Seleniumを選んだ理由は単純で、チェック対象がブラウザ上のWebアプリケーションだからだ。APIがあればAPIを叩く方が早いが、レガシーなシステムではブラウザ操作しか手段がない場合がある。環境制約のなかで「動くもの」を作ることが現場では重要になる。

導入効果は明確で、月あたり約4時間の確認作業がほぼゼロになった。最初のスクリプト作成に半日かかったが、2ヶ月目で回収できている。

Python×業務自動化の基本から実践例までを体系的に学びたい方には、以下の書籍がおすすめです。筆者もSelenium導入時に参考にしました。

NotebookLMでVBAモジュールをデバッグする

GoogleのNotebookLMにVBAモジュールのソースコードを読み込ませて、不具合の原因調査に活用している。具体的には、エクスポートしたモジュールファイルをそのままアップロードし、「このモジュールで○○の処理が期待通りに動かない。原因を分析してほしい」と質問する。

NotebookLMの強みは、アップロードしたドキュメントの内容に基づいて回答する点だ。一般的な生成AIに長いコードを貼り付けるよりも、文脈を正確に把握してくれる。複数モジュール間の依存関係がある場合でも、関連ファイルをまとめて読み込ませれば横断的に分析してくれる。

ただし万能ではない。VBAの古い記法や、Excel特有のオブジェクトモデルに関しては誤った回答が返ることもある。最終的な判断は自分でやる必要がある。それでも「あたりをつける」速度は格段に上がった。

本業プロジェクトのメールをGASで自動集約し、NotebookLMで思考整理する手順は「GAS×NotebookLM実践記」で解説しています。

▶ 生成AI時代に求められるスキルの変化についてはこちら
【生成AI時代】必要・不要なスキルと若手教育の進め方

コーディング支援エージェントの構想｜環境制約との戦い

現在取り組んでいるのが、コーディング支援エージェントの構築だ。目指しているのは、「VBAやPowerShellのコードを書く際に、環境制約を理解した上でアドバイスしてくれるAI」の実現だ。

環境制約は3つある。Windows標準の範囲内で完結すること、Windows 10と11の両方で動作すること、管理者権限がないこと。これらを満たさないコードは、いくら優れていても現場では使えない。一般的な生成AIにコードを書かせると、この制約を無視した回答が返ってくることが多い。

現時点ではまだ完成していない。プロンプトに制約条件を組み込んだカスタム指示を作成し、テスト中だ。うまくいけば、チームメンバーが自分でツールを作る際のハードルが大幅に下がると考えている。完成したら別記事で詳しく書く予定だ。

AIコーディング支援の活用が広がる中で、使い方次第でスキル形成に3.6倍の差がつくことがAnthropicの研究で示されている。AI時代のキャリア設計と行動指針も参考にしてほしい。

コードレビューエージェント（パイロット運用中）

もう一つ取り組んでいるのが、コードレビューエージェントだ。メンバーが書いたVBAコードを読み込ませて、命名規則の違反、エラーハンドリングの漏れ、モジュール分割の不備などを自動で指摘する仕組みを目指している。

当初はNotebookLMにレビュー観点をまとめたドキュメントとコードを同時に読み込ませる形で運用していたが、レビュー観点の網羅や指摘の完全な抽出がどう調整しても期待通りに動作しなかった。プロジェクト固有のコーディング規約を守らせるのが特に難しく、AIのコンテキスト処理能力の限界を感じた。

そこで方針を切り替え、レビュー観点を絞った簡素版をパイロット運用している。DRY原則や命名規則などに絞り、他の観点は人間のレビュアーが補う分業体制にした。完全自動化は諦めたが、レビュアーが最初に目を通す前の「粗チェック」としては機能し始めている。

やりたいことを完全に実現するには、AIのスペックがもう一段上がる必要があると感じている。2026年3月時点では「要点を絞って使う」のが現実的な落としどころだ。レビューの質を均一化し、レビュアーの負担を減らすという方向性は変わらない。引き続き改善を進める。

よくある質問

Claude Codeにはターミナル内で機能を学べるチュートリアルコマンドも搭載されている。Hooksやヘッドレスモードの使い方を体系的に把握したい方はClaude Code /powerup入門を参照してほしい。

まとめ｜自動化は「面倒くさい」から始まる

紹介した内容を振り返ると、どれも出発点は「面倒くさい」だった。パスをコピーするのが面倒、入力チェックが面倒、コードの差分確認が面倒。その「面倒」を1つずつ潰してきただけだ。

重要なのは、最初から大きな仕組みを作ろうとしないことだ。SendToにショートカットを1つ追加する。PowerShellで10行のスクリプトを書く。そこから始めて、必要に応じて拡張していく。この積み上げが20年の蓄積になった。

環境制約がある中でも、Windows標準機能とPythonだけでかなりのことができる。管理者権限がなくても、外部ライブラリをインストールできなくても、工夫次第で業務は楽になる。「制約があるからできない」ではなく「制約の中で何ができるか」を考える方が、SEとしては生産的だと思っている。

Google Workspace側に特化したレシピはClaude Code×GASでWorkspace自動化7選に集約しているので、Gmail・カレンダー・ドライブの定型作業を撲滅したい場合はそちらを参照。