その業務、何で自動化するか──VBA・Power Automate・GAS・RPA・AIの使い分け基準
前回の記事「小さく始める業務改善プロジェクトの進め方」では、効果検証しやすいテーマ設定から社内展開までの進め方を紹介しました。本記事はその実行段階で必ず直面する問い、「この業務を、どの手段で自動化するか」の判断基準を整理します。
自動化ツールの選択ミスは、改善どころか新たな保守負債を生みます。「動いてはいるが誰も触れない自動化」は、属人Excelマクロと同じ問題の再生産です。
1. 手段選定の前に確認する2つのこと
(1) そもそも自動化すべき業務か
自動化の前に「廃止できないか」「頻度を減らせないか」を必ず検討します。誰も読んでいない週次レポートを自動化するのは、無駄を高速化しているだけです。自動化は業務の見直しが終わった後の手段です。
(2) その業務は「ルールで書き切れるか」
自動化手段は、業務が完全にルール化できるかで大きく2系統に分かれます。
- ルールで書き切れる（毎月この帳票のこの列を転記する等）→ 従来型自動化（VBA / Power Automate / GAS / RPA）
- 判断・解釈が混ざる（問い合わせ内容を読んで分類する、文書の要点を抽出する等）→ AI活用、または「ルール部分は従来型＋判断部分はAI」のハイブリッド
ここを混同し、判断が混ざる業務を従来型RPAだけで組むと、例外処理の分岐が際限なく増えて破綻します。逆に、単純転記にAIを使うのはコストと不確実性の無駄です。
2. 主要な自動化手段の比較
| 手段 | 得意領域 | 制約・リスク | 向いている組織 |
|---|---|---|---|
| Excel VBA | Excel内で完結する処理 | 属人化しやすい。Excel外との連携が弱い | 既存マクロ資産がある。ただし新規開発は推奨度低 |
| Power Automate | Microsoft 365内の連携（Teams通知、承認フロー、ファイル操作） | ライセンス体系が複雑。複雑なロジックは可読性が落ちる | M365を全社導入済みの企業 |
| GAS (Google Apps Script) | Google Workspace内の連携、フォーム→シート→メールの流れ | 実行時間制限あり。Google環境前提 | Google Workspace利用企業 |
| RPA（デスクトップ型含む） | API・連携機能のないレガシー画面の操作 | 画面変更で壊れる。保守コストが恒常的に発生 | 改修不能な基幹システムが残る企業 |
| AI（API・エージェント） | 文書の読解・分類・要約・生成など判断を含む処理 | 出力の検証工程が必須。コスト管理が必要 | 非定型業務の比率が高い部門 |
選定の原則
原則1: 業務データがある場所のプラットフォーム標準機能を第一候補にする。 M365企業ならPower Automate、Google企業ならGAS。プラットフォーム標準は認証・権限・監査の仕組みに乗れるため、保守と統制のコストが最小になります。
原則2: RPAは「最後の手段」。 RPAは画面操作の模倣であり、対象システムの画面が変わるたびに壊れます。APIや標準連携が存在するならそちらが常に優先です。RPAが正当化されるのは、改修も連携もできないレガシーシステムが相手のときだけです。
原則3: VBAの新規開発は原則避ける。 既存資産の延命は現実解ですが、新規の自動化をVBAで組むのは属人化の再生産です。同じ処理はPower AutomateやGAS、あるいはPython等の管理可能な形で実装すべきです。
3. AIをどこに入れるか──ハイブリッド設計の考え方
2026年現在、現実的な構成は「フローは従来型、判断はAI」のハイブリッドです。
例: 問い合わせメールの一次対応
- メール受信をトリガーにフローが起動（Power Automate / GAS）
- 本文をAIに渡し、カテゴリ分類と回答案を生成（AI API）
- 回答案を担当者に提示し、人が確認して送信（人の承認を挟む）
ポイントは2つです。第一に、AIの出力をそのまま外部に出さないこと。確認工程を挟む前提で設計すれば、AIの誤りは品質事故ではなく「修正の手間」に収まります。第二に、フロー制御をAIに任せないこと。起動条件・分岐・記録は従来型の確実な仕組みで持ち、AIは判断部品として呼び出す構成が、コストも信頼性も安定します。
なお、より長時間・複数段階のタスクをAIエージェントに委任する選択肢も登場していますが（「Claude Fable 5とは何か」参照）、その場合も「どこまで任せ、どこで人が確認するか」の設計が先です。
4. 保守を前提にした実装ルール──作りっぱなしを防ぐ
自動化の失敗の大半は、作った後に起きます。最低限、以下を実装時のルールにします。
- 台帳化: 何が・どこで・何をトリガーに動いているかの一覧を維持する。台帳にない自動化は「ない」のと同じ扱いにする
- エラー通知: 失敗したら誰かに通知が飛ぶ。静かに止まる自動化が最も危険
- 担当の複数化: 作成者以外がもう1人、中身を説明できる状態を維持する
- 撤去基準: 対象業務が変わったら自動化も見直す。使われていないフローは消す
このルールなしに自動化を量産すると、数年後に「動いているが触れないフローの群れ」が残ります。これは冒頭で述べた属人Excelマクロ問題の、ツールを変えた再発です。
まとめ
- 自動化の前に廃止・削減を検討。手段選定は「ルールで書き切れるか」で2系統に分ける
- 第一候補は自社プラットフォームの標準機能（Power Automate / GAS）。RPAは最後の手段、VBA新規開発は原則回避
- AIは判断部品として組み込み、フロー制御と最終確認は従来型と人が持つ
- 台帳・エラー通知・担当複数化・撤去基準をセットで運用しなければ、自動化は負債化する
自社業務の自動化手段の選定、ハイブリッド構成の設計についてのご相談は、お問い合わせフォームからご連絡ください。