GAS×LLM APIで社内業務を自動化する設計手順

Google Apps Script（GAS）は、スプレッドシート・Gmail・ドライブを追加費用なしで自動化できる実行環境です。ここにLLMのAPIを組み合わせると、「判断を伴う繰り返し作業」まで自動化の対象に入ります。問い合わせメールの分類、見積書からの項目抽出、日報の要約といった、これまで人が読んで決めていた作業です。

ただし、自動化が失敗する原因のほとんどは技術ではなく順序です。コードを書き始める前に決めておくことが4つあり、それを飛ばすと、動くけれども誰も使わない仕組みができあがります。以下では、社内業務にGASとLLMを載せる際の設計順序と、詰まりやすい箇所を実務の粒度で整理します。

前提として、対象にすべき業務は「毎日〜毎週発生し、手順が言葉で説明できるもの」です。年に数回の作業は、自動化より手順書のほうが費用対効果が高くなります。

自動化の順序を間違えない

最初にコードを書き始めると、ほぼ失敗します。順序はこうです。

1. 手作業のまま、手順を文章に書き出す
2. 判断が入る箇所に印をつける
3. 判断のない箇所だけを先に自動化する
4. 残った判断をLLMに渡す

最初から全部をLLMに任せると、出力が安定せず、結局人が全件チェックすることになります。自動化されていない確認作業が残るなら、それは自動化ではありません。

手順の書き出しは、箇条書きで15行前後になれば十分です。このとき「開く」「探す」「コピーする」といった動作の単位まで割ってください。粒度が粗いと、自動化できる部分とできない部分の境目が見えません。

自動化して回収できる業務の見分け方

すべての手作業を自動化する必要はありません。回収できるかどうかは、次の式で概算できます。

年間の削減時間 ＝（1回あたりの所要分数 × 年間の発生回数）÷ 60

これに自社の時間単価を掛けた額が、開発にかけられる上限の目安になります。

判断基準は次の3つです。1つでも欠けていれば、自動化は後回しにしたほうが安全です。

• 入力の形が毎回ほぼ同じ：フォーム、定型メール、同じ書式の請求書など。入力が毎回違う業務は、前処理のほうが重くなります
• 間違えたときに取り返しがつく：社内向けの下書き生成は失敗しても戻せます。対外送信や入金処理は、自動化の前に承認を挟む設計が必要です
• 判断の基準が言葉で書ける：「急ぎかどうか」を分ける基準が文章にできないなら、LLMにも渡せません

認証情報の置き場所

APIキーをコードに直接書くのは避けてください。GASでは PropertiesService のスクリプトプロパティに保存し、コードからは名前で読み出します。const key = PropertiesService.getScriptProperties().getProperty('API_KEY'); の形です。

理由は3つあります。第一に、コードを他の担当者と共有したり、外部の支援者に見せる場面でキーが漏れます。第二に、キーを更新する際にコードを書き換える必要がなくなります。第三に、GitHubなどにコードを控えた場合、キーが外部に出ます。

加えて、スクリプトの実行権限とスプレッドシートの共有範囲は別物です。スクリプトを含むファイルを「リンクを知っている全員」で共有すると、意図しない相手がスクリプトエディタを開ける状態になります。自動化を載せたファイルは、共有範囲を担当者のみに絞ってください。

LLMに渡す仕事は3種類に絞る

LLMが安定して処理できるのは、分類・抽出・整形の3つです。この3つに収まるように業務を切り分けると、出力のばらつきが大きく減ります。

逆に任せにくいのは、計算、正確な日付の算出、社内ルールの当てはめです。計算はスプレッドシートの関数側で行い、日付は Utilities.formatDate のような機能で確定させてください。数えられるものはコードに、読み取るものはLLMにという分担が、最も壊れにくくなります。

出力を安定させる3つの手当て

LLMの出力が揺れる問題は、プロンプトの言い回しを工夫するより、受け取り方の設計で解決します。具体的には次の3点です。

1. 出力の形をJSONで指定する：項目名とデータ型を明示し、余計な説明文を付けないよう指示します。多くのAPIには出力形式を構造で指定する機能があり、対応状況は提供元のドキュメントで確認してください
2. 選択肢を固定する：分類は自由記述にせず、許可する値を列挙します。想定外の値が返った場合は「その他」に寄せ、後で人が見るシートへ落とします
3. 受け取った直後に検証する：必須項目が空でないか、選択肢に含まれる値かを、コード側で確認します。検証を通らなかったものだけを人の確認に回せば、確認件数が全件から数件に減ります

指示文そのものも、曖昧さを削るだけで精度が変わります。分類を依頼する場合の違いは次のとおりです。

書き換え前：このメールがどんな問い合わせか判断してください。

書き換え後：次のメールを「見積依頼／採用応募／営業提案／その他」の4つのいずれか1つに分類し、分類名のみを出力してください。判断できない場合は「その他」としてください。理由や前置きは書かないでください。

違いは、選択肢を閉じていること、出力形式を限定していること、迷った場合の行き先を指定していることの3点です。この3点を満たすと、後段のコード側で値を検証できるようになります。

プロンプトはコード内に直書きせず、スプレッドシートの1つのセルか、スクリプトプロパティに置く方法が扱いやすくなります。文言の調整に、毎回コードの編集とデプロイが必要な状態は避けてください。調整を担当者が自分でできるかどうかで、運用が続くかが変わります。

シートの列設計が仕組みの寿命を決める

GASを使った自動化では、スプレッドシートがそのままデータベースになります。列の設計を先に決めておくと、仕組みの寿命が伸びます。なぜなら、後から列を挿入すると、列番号で位置を指定しているコードが一斉に壊れるためです。

最低限、次の列を最初から用意してください。使わない列があっても構いません。空けておくほうが後の改修が楽になります。

• 受信日時と処理日時：いつ来て、いつ処理したかを分けて持ちます。障害の切り分けが速くなります
• 処理状態：未処理／処理済／要確認／失敗の4値で管理します。空欄を「未処理」の意味にすると、誤って消したときに二重処理が起きます
• LLMの出力そのまま：整形前の生の応答を残す列です。おかしな結果が出たときに、原因がプロンプトか検証かを判別できます
• 担当者の修正後：人が直した内容を別列に置きます。この差分が、プロンプト改善の材料になります

列の位置は、コード内で名前から番号を引く形にしてください。1行目の見出し文字列を読んで列番号を求める書き方にしておくと、列の追加や並べ替えでコードを直す必要がなくなります。列番号の直書きは、半年後の改修コストとして返ってきます。

実行時間とトリガーの制約

GASには1回の実行時間や1日の実行回数に上限が設けられています。上限値はアカウントの種別によって異なり、変更されることもあるため、公式のQuotasの記載を実装前に必ず確認してください。執筆時点では、無料のGoogleアカウントの1回あたり実行時間は数分程度で、これがLLM連携では最初の壁になります。

LLMのAPIは1件あたりの応答に数秒かかるため、100件を1回の実行で処理しようとすると上限に当たります。対処は次の設計です。

• 未処理の行に印を付けて管理する：処理済み列を用意し、空の行だけを対象にします
• 1回の実行で処理する件数に上限を設ける：例えば20件で止め、残りは次回に回します
• 時間主導型トリガーで小刻みに回す：5分おきに20件、という形にすれば、上限に当たらずに処理が進みます
• 実行開始時刻を記録し、残り時間で打ち切る：経過時間を見て、上限に近づいたら安全に中断します

エラーを検知できる状態を先に作る

自動化で最も危険なのは、止まったことに誰も気づかない状態です。エラー通知の仕組みは、機能の実装よりも先に作ってください。理由は、通知がなければ「動いていない期間」がそのまま業務の抜けになるからです。

最低限、次の3つを用意します。

1. 処理ログのシート：日時、対象、結果、エラー内容を1行ずつ追記します
2. 失敗時のメール通知：例外を捕まえて担当者へ送ります。件名に業務名を入れると埋もれません
3. 「今日1件も処理しなかった」ことの検知：これが最も見落とされます。1日1回、処理件数が0だった場合に通知する仕組みを別に置いてください

また、API呼び出しは一時的に失敗することがあります。1回失敗したら即エラーにせず、数秒待って2〜3回だけ再試行する処理を入れると、通知の空振りが減ります。ただし無制限の再試行は、課金と実行時間の両方を食います。回数の上限は必ず決めてください。

費用の読み方と、上限の置き方

LLMのAPIは、扱う文字量に応じた従量課金が一般的です。単価は提供元と機種で異なり、改定もあるため、金額は必ず提供元の料金ページで確認してください。実務で押さえるのは金額そのものより、1件あたりの文字量と、月間の件数です。

費用が想定外に膨らむのは、次の場面です。

• メール本文をまるごと渡している（署名や引用部分を除去すれば量が減ります）
• 再試行が無制限になっている
• テスト中のトリガーを止め忘れ、本番と二重に回っている
• 処理済みの判定を作っておらず、同じ行を毎回処理している

提供元の管理画面で利用上限や通知を設定できる場合は、開発の初日に設定してください。上限の設定は、コードのどの改善よりも先に効きます。

人の確認をどこに残すか

「全自動」を目指すと、かえって運用が止まります。現実的な設計は、自動で下書きまで作り、送信や確定だけを人が押す形です。判断の重さで分けると、次のような線引きになります。

実装前チェックリスト

着手前に、次の項目を1枚の紙に埋めてください。ここが埋まらない状態で書き始めた仕組みは、たいてい作り直しになります。

最後の「引き継ぎ」は、社外に依頼する場合も自社で作る場合も同じです。スクリプトの所有者アカウント、トリガーの設定内容、プロンプトの置き場所、APIキーの取得元の4点を書き残してください。この4点がないと、担当者の異動や退職で仕組みが止まります。

まず何から手を付けるか

最初の1本は、効果の大きい業務ではなく、失敗しても困らない業務を選んでください。自動化の勝ち筋は、社内に「動いた実例」を1つ作ることにあります。

1. 毎週やっている集計作業を1つ選ぶ。対外送信を含まないものにします
2. 手順を箇条書きにし、判断が入る行に印を付ける。この紙が仕様書になります
3. 判断のない部分だけをGASで自動化する。この段階ではLLMを使いません。ここまでで効果が出る業務も珍しくありません
4. 残った判断を1か所だけLLMに渡す。分類か抽出のどちらかから始めます
5. 出力を人が確認するシートに落とし、2週間は全件を目で見る。誤りの傾向が分かってから、確認範囲を狭めます
6. 通知と処理ログを整えてから、次の業務へ広げる

2週間の全件確認は省略したくなる工程ですが、ここで誤りの傾向をつかんでおくと、その後の運用で確認件数を安心して減らせます。自動化の信頼は、最初に人が見た記録の量で決まります。