関数・Apps Script・生成AIを、同じ条件で比べる
ここではGoogleスプレッドシートを例に、表計算の中での選び方を説明します。「関数」はSUMIFSなどの通常の計算関数、「生成AI」はAI関数などで分類・文章生成を行う方法です。AI関数もセルに入力しますが、決まった式による計算とは分けて考えます。
次の表は選定の目安です。特定の方法が常に優れているという比較ではありません。
| 判断する点 | 関数 | Apps Script | 生成AI |
|---|---|---|---|
| 同じ入力で同じ結果が必要か | 固定した式・参照範囲で計算する処理が候補 | 固定したルールをプログラムで処理する場合が候補 | 出力は毎回同じとは限らない。確定計算を任せない |
| 集計ルールが決まっているか | 日付・部門などの条件を式で表せる | 条件分岐や複数の処理手順を明文化できる | 自由記述から分類候補や説明文を作り、人が判断する |
| 元データの形がそろうか | 列・数値・日付の形式がそろうと扱いやすい | 決まった形式の読み取り・変換・転記が候補 | 文章の違いを扱えるが、欠けた金額や日付を推測で埋めない |
| 人が確かめる手間 | 式、対象範囲、元データの抜け・重複を見る | 処理対象、重複、途中停止、書き込み先を見る | 分類や文章を原文と照合し、数値も別途確認する |
| 維持する担当 | 式と集計ルールを直せる人 | コード・権限・実行条件を直せる人 | 指示文と分類基準を管理し、出力を確認する人 |
関数やApps Scriptでも、参照範囲や元データが違えば結果は変わります。日時や外部データに依存する処理まで「いつも同じ」とは言えません。対象の月、元データの版、式や処理のルールをそろえて比較します。
関数：決まった条件で計算する
SUMIFSは、複数の条件に合う範囲の合計を求める関数です。月と部門を条件にした売上集計のように、列とルールが決まっている仕事が候補になります。公式ヘルプの構文と条件を確認して、対象範囲を決めます。
行が増えたときの範囲漏れ、数値に見える文字列、日付の形式の違いは人が確認します。式だけで収まるなら、スクリプトを作る前に入力の形と式の管理を整える方法があります。
Apps Script：読み取り・転記・定期実行をつなぐ
Apps Scriptには、スプレッドシートを読み取り、編集する機能があります。毎月同じ列を別の集計シートへ移すなど、式の前後に繰り返し操作があるときに候補になります。集計自体は関数に残し、転記だけをスクリプトにすることもできます。
インストール可能な時間主導型トリガーは定期実行に使えますが、作成者のアカウントで動き、指定した時刻から実行時刻がずれる場合があります。担当者の交代、権限の変更、締め処理との順序まで決める必要があります。「定期実行できる」だけで、締め時刻に集計が完了すると保証しないようにします。
生成AI：分類候補や説明の下書きを作る
GoogleスプレッドシートのAI関数は、テキストの生成・要約・分類などに使えます。自由記述の経費メモから社内の管理用カテゴリの候補を作る、確定済みの集計表をもとに報告文を下書きする、といった役割が候補です。税務上の科目判断や金額の確定を任せる説明ではありません。
AIに式やスクリプトの案を作らせる場合も、生成した案をそのまま本番に使わず、参照範囲・計算条件・書き込み先を人が確認します。開発の補助にAIを使うことと、毎月の集計でAIに数値を判断させることは別です。
この違いを示すのが、架空の請求書PDFからCSV候補を作った検証ラボの記録です。2026年10月8日、同じ配置の架空の1ページPDF5件を使い、AIが試作コードの作成・修正を補助しました。実行時の文字抽出、保留の判定、CSV候補の出力は、Pythonと pdftotext を使い、決めた条件で動く通常の処理でした。抽出結果と原本項目の照合にはAIを使い、人による照合や会計ソフトへの登録は行っていません。
hirostaはこの観察から、「誰が処理を作るか」と「実行時に何が判断するか」を分けて選ぶ必要があると考えます。AIがコード作成を補助しても、実行時にAIが金額を判断する仕組みになるとは限りません。表計算でも、開発の補助にAIを使い、集計は確認した式やプログラムで行う分担を提案します。ただし、この検証ラボで関数・Apps Script・GoogleスプレッドシートのAI関数を試したわけではありません。それらでの同じ誤り方や、表計算の集計での精度・所要時間は未検証です。
自社の集計方法を選ぶ手順
- 集計の答えを決める。 売上日と入金日のどちらで月を区切るか、税抜と税込のどちらか、返品や取消をどう扱うかを言葉にします。ルールが未確定なら、先に業務担当者が決めます。
- 元データの形を見る。 日付・金額・部門・明細の識別子などの列が毎回そろうかを確認します。列の不足や見出しの変更は、推測して処理せず確認待ちにします。
- 計算と周辺作業を分ける。 式で表せる合計は関数、毎月の読み取り・転記はApps Script、自由記述の解釈や説明文は生成AIの候補にします。AIに式やスクリプトを作らせる前に、使う列・金額と、該当する値がなければ保留にする条件を業務担当者が決めます。開発をAIに補助させても、集計ルールを決める役割は人に残します。
- 確認方法を先に決める。 答えが分かっている少数のデータで、指定した値が使われ、値がないときに保留になるかを照合してから対象を広げます。元データの件数、対象月、合計と部門別内訳の一致、除外・保留した明細も確認します。総額が合っていても部門の分類が誤っている場合があるため、明細も照合します。
- 維持できる範囲から始める。 業務データを直接上書きせず、許可されたデータのコピーで手動集計と比べます。実行・確認・修正を誰が担当するか決めてから、必要な工程だけをつなぎます。
使う値と保留条件を先に決める理由は、検証ラボでの金額の取り違えと修正にあります。最初のコードは「金額」に続く数字を探して先に現れる税抜金額を採用し、税込合計の記載がない書類まで候補に入れました。最初は5行・保留0件でしたが、「税込合計」を指定し、なければ推測で埋めず保留にする修正などを経て、候補2行・保留3件になりました。この件数には再送・対象外の税率構成の保留も含まれます。
hirostaは、コードが動いて出力が得られても、使う値が業務の意図に合うとは限らないと捉えています。自社の集計でも、AIへの指示に列名・金額の意味・保留条件を含め、既知のデータと照合する進め方を提案します。これは請求書PDFの試作からの応用で、表計算で同じ失敗を観察した結果ではありません。
選定では「処理が速いか」だけでなく、結果を確認して直す手間と、担当者が引き継げるかも見ます。実際の削減時間や精度は、自社の条件で確かめるまで断定できません。
組み合わせ方：月次の売上・経費集計の想定シナリオ
以下は架空の会社を想定した、未実施のシナリオです。hirostaの導入実績や検証結果ではありません。
月次集計の元表には日付・部門・金額・経費メモがあり、担当者が毎月、対象月の行をコピーして部門別に合計しているとします。この場合、次のように分担できます。
- 関数： 対象月・部門の条件で売上や経費を合計する。計算のためだけに生成AIを呼び出さない。
- Apps Script： 決まった元表から対象の行を集計用シートへ移す。列の不足や処理済みの明細があれば保留し、同じ月を再実行しても二重に加算しない仕組みを用意する。
- 生成AI： 入力を許可した経費メモから管理用カテゴリの候補と理由を別列に出す。不明なものは確認待ちにし、元のメモを残す。
- 人： 原文と分類候補を照合してカテゴリを確定し、その列を使って関数で再集計する。報告文の数値も確定済みの表と照合してから使う。
最初からすべてを組み合わせる必要はありません。元表が整い、分類も決まっているなら関数だけで始めます。転記が残るならApps Scriptを検討し、文章の分類が必要な部分だけに生成AIを使います。
業務全体の画面操作との使い分けはRPA・通常の自動化・生成AIの比較、表計算を続けるか業務ソフトへ移るかはSaaSと個別自動化の比較で説明しています。AIを画面で手動利用するかシステムへ組み込むかはChatGPTの手動利用とAPI連携をご覧ください。
限界と、処理を止めて人が確認する場面
機能の提供条件と実行上限
2026年10月11日に確認したGoogleの公式比較表では、AI関数の対象にBusiness Standard・Business Plus、Enterprise Standard・Enterprise Plus、個人向けのGoogle AI Pro・Google AI Ultraが掲載されています。公式の言語一覧には日本語も掲載されています。ただし、提供地域や個別アカウントの利用可否は本記事では確認していません。提供条件は公式ヘルプで確認が必要です。 管理者設定と利用するアカウントの条件も導入前に照合してください。
AI関数の回答はテキストで、シート全体や他のDriveファイルを自動的に参照するものではありません。必要なデータの範囲を指定し、生成上限を確認します。プロンプト内で連結したセルの値が変わっても、更新を促す表示が出ない場合があるため、入力と出力が同じ版かを確認します。AI関数をSUMIFSと同じように再計算される確定集計として扱わないことが大切です。
Apps Scriptにも実行時間や利用量の上限があり、超えると処理が停止します。途中まで転記した結果を完成済みとしないよう、完了・保留・失敗を区別し、再実行の前に処理済みの明細を確認する方法を用意します。
不明なデータと未承認の情報を流さない
元データの列が変わった、日付や金額が読めない、重複の判断がつかない、分類の根拠がない場合は、人の確認に戻します。AIが自然な文章を返しても、数値の集計結果は人が対象範囲・除外した行・元の金額と照合する必要があります。
顧客名や口座情報など、集計や分類に不要な情報はAIへ渡す項目から外します。契約・設定・社内ルールで入力可否が確かめられない情報は入力を保留してください。顧客情報を生成AIに入力する前の確認も参考になります。
元データを残し、集計ルールと修正担当を決め、確認できない結果を確定しない。この運用が用意できる範囲で、自動化を進めます。