業務自動化ツールの選び方｜RPA・iPaaS・GASの違いと使い分け

RPA、iPaaS、GAS（Google Apps Script）は、どれも業務の自動化に使えますが、仕組みが違います。RPAは人が画面を操作する代わりにパソコンを動かし、iPaaSはサービス同士をAPIでつなぎ、GASはGoogleのサービスの上で動く小さなプログラムです。迷ったときは、対象の業務が「APIでつなげるか」「Googleのサービスの中で完結するか」「画面を操作するしかないか」の順に見ると、多くの場合は決まります。

この記事では、3つの仕組みの違い、向く業務、費用の考え方、壊れやすさと保守、選ぶ順番をまとめます。Nexlyは、n8nやGASを使った自動化を自社でも運用し、お客さまにも組んでいます。その中で、ツールの機能より「保守を誰が続けるか」で選んだほうが長持ちしやすいので、その視点を強めに書きます。

3つの違い｜操作する場所が「画面」「API」「Googleの中」で分かれる

先に全体像です。3つは、自動化が「どこに触るか」で分けると整理できます。

種類	触る場所	代表的な使い方	主な担い手
RPA	画面（人が触る操作画面）	APIのない古いシステムへの入力、画面からのデータ転記	業務担当者、情報システム担当
iPaaS	各サービスのAPI	フォームからCRMへの登録、チャット通知、定時のレポート	業務担当者、運用の担当者
GAS	Googleのサービス（スプレッドシート、Gmail、カレンダーなど）	シートの集計、メール送信、フォーム回答の加工	スクリプトを読める人

iPaaS（Integration Platform as a Service）には、公的な定義や標準の定義があるわけではありません。ベンダー各社の説明では、サービス同士の連携をクラウド上の部品で作れるようにしたものを指して使われます。この記事でも、ZapierやMake、n8nのような「画面で部品をつないで連携を作る」ツールを指す言葉として使います。

ここで大事なのは、3つは優劣ではなく、役割が違うということです。同じ会社の中でも、古い基幹システムの入力はRPA、問い合わせの連携はiPaaS、営業部門のシート集計はGAS、と混在するのが普通です。

RPAとは｜画面の操作を人の代わりに行う

RPAは「ロボティック・プロセス・オートメーション」の略で、人がマウスやキーボードで行う操作を、ソフトウェアが代わりに行います。Microsoft Power Automateの公式ドキュメントでは、デスクトップフローを「繰り返しのデスクトップ作業を自動化する」ものと説明し、古いアプリケーション（ターミナルエミュレーターなど）、新しいWeb・デスクトップアプリ、Excelファイルやフォルダーを対象にできるとしています。操作の対象は、画面上の部品、画像、座標で指定します。

RPAの強みは、APIがないシステムでも動かせることです。仕入先の専用画面からデータを取り出す、古い基幹システムに入力する、といった「人が画面でやるしかない」作業に届きます。反対に、画面に依存するので、画面が変わると止まりやすい点が弱みです。

上の図のように、RPAは「ブラウザを開く、ログインする、この欄に入力する、このボタンを押す」という操作を順に並べて作ります。公式ドキュメントでも、画面の部品を指定するための「セレクター」を使うと説明されています。セレクターは、ボタンや入力欄を画面上で見分けるための目印です。複数のセレクターを登録しておくと、1つが失敗したときに次の目印が使われる仕組みもあります。ただ、これは「画面の作りが変わる可能性がある」ことを前提にした機能で、画面が変わる前提で組む必要があることを示しています。

RPAを入れる前に決めておくこと

RPAは、ソフトを入れれば動くものではなく、動かす場所と権限を決める作業が先に要ります。実務では、次の4点を先に詰めます。

• どのパソコン（または仮想環境）で動かすか。実行中はそのパソコンの電源が入っていて、画面操作のできる状態である必要がある製品が多い
• ログインのIDとパスワードを、誰のものにするか。個人のアカウントで動かすと、異動や退職、パスワード変更のたびに止まる。専用のアカウントを発行できるかを確認する
• 対象のサイトやシステムの利用規約で、自動操作が認められているか。特に外部の会員サイトは、利用規約に自動化の禁止が書かれていないか読む
• 相手の画面が変わるときに、事前に連絡が来るか。連絡が来ない相手なら、実行結果を毎日見る前提にする

RPAが向く業務

• APIが提供されていない、または使えない契約になっている業務システムへの入力・取得
• 仕様の決まった画面を、毎回同じ順で操作する作業（画面の変更が少ないもの）
• ほかの方法が使えるようになるまでの「つなぎ」の自動化

iPaaS（API連携）とは｜サービス同士を部品でつなぐ

iPaaSは、サービスが外に公開しているAPIを使って、データを直接やりとりします。人が画面を見る必要がないので、画面の見た目が変わっても動き続けやすい点が特徴です。ZapierやMake、n8nなど、画面上で部品をつないで作るタイプが代表例です。

数え方や仕様はツールで違います。たとえばZapierのヘルプでは、成功したアクションを1タスクと数え、トリガーやフィルターは数えないと説明されています。Makeの公式アカデミーでは、多くのモジュールが1操作で1クレジットを使い、AI関連のモジュールは使用量で変わると説明されています。n8nは料金ページで、複雑さに関係なくワークフローの実行回数で数えるとしています（2026年10月時点）。n8nの仕組みはn8nとはで詳しく書いています。

iPaaSの弱みは、つなぐ相手がAPIを用意していなければ使えないことと、連携の長さや量に応じて費用や設計の手間が増えることです。また、認証（連携先へのログインの許可）の期限切れや、相手のAPIの仕様変更で止まることがあります。止まりにくさは、画面を操作するRPAより高いことが多いものの、ゼロではありません。

つなぐ前にAPIで確認すること

iPaaSは「つなげるはず」と思って選ぶと、あとから行き詰まることがあります。連携先のAPIの資料（公式のドキュメント）で、次の点を先に確認します。

• 必要な項目が、APIで取れる・書き込めるか（画面には出ているが、APIには出てこない項目がある）
• 自社の契約プランで、APIが使えるか
• 認証の方式と、トークンの有効期限。期限が切れたときに自動で更新されるか、人が更新するか
• 一定時間あたりの呼び出し回数に制限があるか。件数が多い処理は、制限に当たらない設計にする

iPaaSが向く業務

• フォームの受信、CRMへの登録、チャット通知のように、サービス間でデータを渡す流れ
• 毎日・毎週など決まった時刻に動く定時のレポート
• メールや問い合わせをAIで分類して振り分ける流れ（問い合わせ・メールの自動振り分けで設計を扱っています）

GAS（Google Apps Script）とは｜Googleのサービスの中で動く小さなプログラム

GASは、Googleが提供するプログラム実行の仕組みです。公式ドキュメントでは、Google Workspaceと連携する業務アプリを素早く作るための開発プラットフォームと説明されていて、JavaScriptで書き、インストールは要らず、スクリプトはドライブに保存されてGoogleのサーバー上で動きます。スプレッドシートやドキュメントのメニューやサイドバーを作る、シートのカスタム関数を作る、Gmail・カレンダー・ドライブを操作する、といったことができます。

GASが動き出すきっかけは「トリガー」です。公式ドキュメントによると、インストール可能なトリガーには、時間主導（最短で毎分から月1回まで）、スプレッドシートの編集や変更、フォームの送信、カレンダーの予定の変更などがあります。外部のAPIを呼ぶにはUrlFetchApp（外部へのHTTPリクエスト）を使います。ただし、OAuthの仕組みは標準では用意されておらず、ライブラリを使う必要があると書かれています。

GASには、使う前に知っておきたい制限があります。公式のクォータ（上限）のページには、1回の実行の上限が6分であること、トリガーが1日に動ける合計時間が、一般ユーザー向けのアカウントでは90分、Google Workspaceのアカウントでは6時間であることが書かれています（2026年10月時点）。長い処理を1回で回し切ろうとすると、途中で止まります。件数が多い処理は、分割して回す設計にします。

上限に当たるかどうかは、簡単な計算で見当がつきます（計算例です）。1回の処理に30秒かかるスクリプトを、時間主導のトリガーで繰り返し動かす場合、一般ユーザー向けアカウントの1日の合計90分は5,400秒なので、30秒で割ると1日180回までです。Google Workspaceの6時間は21,600秒なので、同じ処理で720回までです。5分おきに動かすと1日288回になるので、一般ユーザー向けアカウントでは上限を超える計算になります。動かす間隔を延ばすか、処理を軽くする必要があります。実際は処理時間がばらつくので、余裕を持って見てください。

もう1つ、運用で効いてくる仕様があります。インストール可能なトリガーは、作った人のアカウントで動きます。たとえばトリガーから送られたメールは、作った人のアドレスから出ます。作った人が退職してアカウントが無効になったとき、自動化も止まる可能性があるということです。GASは手軽に作れる分、「誰のアカウントで動いているか」が見えにくくなります。

GASを引き継げる形にする

GASは、作った人しか知らない自動化になりやすい仕組みです。次の工夫で、引き継ぎやすくなります。

• トリガーを、個人のアカウントではなく、業務用の共用アカウントで作る。作成者のアカウントで動く仕様なので、退職や異動の影響を避けられる
• 通知先のアドレスや、対象のフォルダの名前などの設定値は、コードの中に書かず、シートの設定タブにまとめる
• 何のためのスクリプトかを、シートの先頭やコードの冒頭に書いておく
• スクリプトの置き場所と、動いているトリガーの一覧を、台帳に書く

GASが向く業務

• スプレッドシートの集計・整形・自動入力、Gmailの下書きや送信
• Googleフォームの回答を加工して通知する
• Google Workspaceの中で完結する、小さな定型作業

費用の考え方｜作る費用と、直し続ける費用に分ける

「どれが安いか」は、ツール代だけでは決まりません。自動化の費用は、次の4つに分けて考えるとずれにくくなります。

費用の項目	RPA	iPaaS	GAS
使う権利・実行量	製品のライセンス。実行するパソコンや仮想環境の用意が要ることもある	プランごとの実行量（回数・タスク・クレジット）	無料の範囲で使えるが、Googleの上限がある
作る手間	操作の記録と調整	部品をつなぐ。接続先の認証設定が要る	コードを書く。書ける人が必要
直す手間	画面の変更のたびに修正が必要になりやすい	APIの変更や認証の期限切れへの対応	Google側の仕様変更や、制限への対応
引き継ぎの手間	操作の意図を残さないと読めない	画面で見えるので比較的読みやすい	コードを読める人にしか引き継げない

この表のうち、後ろの2行（直す手間、引き継ぎの手間）は、導入の見積もりに入っていないことが多い項目です。実務では、作った直後より、半年後・1年後に効いてきます。

数字で考えるなら、「直す手間」を時間に直します。次は計算例です（数字は説明用の仮のものです）。

たとえば、作るのに20時間かかり、1か月に2回、1回あたり1時間ずつ直す必要がある自動化があるとします。1年間の作業時間は20時間＋2回×1時間×12か月＝44時間です。時間単価を5,000円と置くと、年間22万円相当の作業です。作る時間は同じでも、直す回数が月4回になれば、年間の作業時間は68時間に増えます。つまり、直す頻度が倍になると、全体の費用は大きく動きます。どのツールが直す頻度を下げられるかを見るのが、選ぶときの本当の比較になります。

壊れやすさと保守｜何が変わると止まるのか

自動化が止まる原因は、種類ごとに違います。止まりやすい場所を先に知っていれば、見張る場所を絞れます。

種類	止まりやすい原因	備える方法
RPA	操作先の画面の変更（ボタンの位置や名前）、ログイン方法の変更、パソコンの状態	画面の変更の連絡を受ける、複数の目印を登録する、失敗時に通知する
iPaaS	認証の期限切れ、APIの仕様変更、連携先の障害、使用量の上限	エラー通知を設定する、使用量を月次で見る、認証の更新日を台帳に書く
GAS	1回の実行時間の上限、1日の合計実行時間の上限、作成者アカウントの停止、Google側の仕様変更	処理を分割する、共用のアカウントで運用する、失敗時の通知を設定する

GASの失敗通知については、公式ドキュメントに、トリガーが失敗するとApps Scriptがトリガーの所有者にメールで失敗の概要を送ると書かれています。ただし、その通知が個人のメールに届くだけでは、担当者が不在のときに気づけません。チームで見ているチャットなどにも通知が届く形にしておくことをおすすめします。

選び方のフロー｜条件を順番に見ていく

選ぶときの判断は、次の順で見ると迷いにくくなります。上から当てはめて、最初に「はい」になったところで考えます。

1. 対象のシステムが、Googleのサービス（スプレッドシート、Gmail、フォームなど）の中で完結するか。はいならGASを検討する
2. 対象のシステムが、APIを公開していて、契約上も使えるか。はいならiPaaSを検討する
3. APIがなく、人が画面で操作するしかないか。はいならRPAを検討する
4. いずれも当てはまるなら、保守を続けられる人と、止まったときの影響で選ぶ

この順にしている理由は、画面を操作するRPAは、ほかの手段が使えないときの手段として置くほうが、保守の手間が増えにくいためです。同じ作業にRPAとiPaaSの両方が使えるなら、APIをたどるiPaaSのほうが、画面の変更の影響を受けにくいことが多いです。ただし、APIが使える契約（プラン）になっているか、API経由で必要な項目が取れるかは、事前に確かめてください。

業務別の当てはめ例

業務	向きやすい方式	理由
問い合わせフォームの内容をCRMに登録し、担当者に通知する	iPaaS	両方のサービスがAPIを持つことが多く、データを直接渡せる
スプレッドシートの売上を毎朝集計してメールで送る	GAS	Googleのサービスの中で完結する
古い基幹システムの画面から、毎日データを取り出してExcelに貼る	RPA	APIがなく、画面の操作でしか取り出せない
取引先の専用サイトから、請求書をダウンロードして保存する	RPA（規約を確認）	画面操作が前提。相手のサイトの利用規約での自動操作の扱いを確認する
CRMの商談の更新を、チャットとシートに同時に反映する	iPaaS	複数の出口へ分岐させる流れが作りやすい

CRMとの連携を前提にするなら、CRM側が持つ機能も確認します。たとえばkintoneでできることには、通知やプロセス管理といった標準機能があり、自動化ツールを足す前に標準機能で足りることもあります。

組み合わせて使う：1つに決めなくてよい

3つのどれか1つに決める必要はありません。実務では、次のような組み合わせがよくあります。

• iPaaSを幹にして、Googleシートの細かい加工だけGASに任せる
• RPAで画面から取り出したデータをシートに置き、そこから先はiPaaSでCRMへ流す
• GASで始めた小さな自動化が増えてきたら、管理しやすいiPaaSへ順に移す

この組み合わせで気をつけたいのは、「どの自動化が、どのシステムに、何を書き込んでいるか」を1枚の台帳にまとめておくことです。複数の仕組みが混在すると、同じデータを別々の自動化が書き換える事故が起きやすくなります。台帳には、自動化の名前、目的、方式、動く時刻、書き込み先、担当者、通知先を書いておきます。

導入の進め方｜小さく始めて、止まる前提で組む

方式が決まったら、次の順で進めます。

1. 対象の業務を1つ選ぶ。頻度が高く、手順が決まっていて、間違えても戻せるものから始める（選び方は業務の棚卸しのやり方に書いています）
2. 今の手作業の手順を、入力・判断・出力に分けて書き出す
3. 手順の中で、APIやGoogleのサービスで済む部分と、画面操作が必要な部分を分ける
4. テスト用のデータで動かし、結果を人の目で確認する
5. 通知先と担当者を決めてから、本番に切り替える
6. 公開後の数日は、毎日実行の結果を見る

全体の進め方の中でどこに位置づけるかは、中小企業のDXの進め方で扱っています。自動化は単体で考えるより、業務の整理とデータの置き場所とセットで考えたほうが、後から作り直す手間が減ります。

よくある失敗：選び方より、運用で起きやすいこと

ツールの選び方を間違えて失敗するより、運用の決めごとが無くて止まるほうが多いと感じます。支援の現場でよく見るのは、次の4つです。

• 作った担当者が異動して、何が動いているか誰も分からなくなる
• 失敗の通知が個人のメールに届くだけで、数日間、誰も気づかない
• ツールを増やしすぎて、同じデータを複数の自動化が別々に書き換える
• 最初に簡単に作った自動化に、あとから条件を足し続けて、誰も触れない複雑さになる

どれもツールの機能では防げず、台帳、通知先、担当者の3つを決めておくことで防げます。作る前に決めておくほうが、作ったあとに足すより、楽です。

選ぶ前のチェックリスト：確認する8項目

ツールを決める前に、次の8項目を確認してください。1つでも「分からない」があれば、先にそこを調べます。

• 対象のシステムは、APIを公開しているか。自社の契約で使えるか
• Googleのサービスの中で完結する作業か
• 画面操作が必要な場合、その画面はどのくらいの頻度で変わるか
• 1か月あたりの実行量はどのくらいか（回数、件数、処理の長さ）
• 止まったとき、誰がいつまでに気づく必要があるか
• 直す人は誰か。その人が不在のときの代わりは決まっているか
• 失敗の通知先は、チームが見る場所になっているか
• 連携用のIDやパスワード、APIキーを、誰がどこで管理するか

よくある質問

Q. RPAとiPaaSは、どちらを先に検討すべきですか。

対象のシステムがAPIを使えるなら、iPaaSを先に検討するのが無難です。画面の変更の影響を受けにくいことが多いからです。APIがない、またはAPIで必要な項目が取れない場合に、RPAを検討します。

Q. GASは無料で使えますか。

GASは追加のインストールなしに使えますが、公式のクォータで1回の実行時間や1日の合計実行時間に上限があります。一般ユーザー向けアカウントとGoogle Workspaceのアカウントでは、1日の合計実行時間の上限が違います（2026年10月時点）。大量の処理を回すときは、上限に収まるかを先に確認してください。

Q. エンジニアがいなくても自動化できますか。

iPaaSは、画面で部品をつなぐ形で、最初の1本を作れることが多いです。RPAも画面の操作を記録して作れる製品があります。GASはコードを書く前提なので、読める人が必要です。ただ、どの方式でも、認証や失敗時の扱いの設計は、少しの技術知識があるほうが安全です。

Q. 自動化が増えたあと、管理が大変になりませんか。

なります。方式を問わず、台帳（名前、目的、方式、動く時刻、書き込み先、担当者、通知先）を作り、増えるたびに更新してください。台帳が無いと、担当者が変わったときに、何が動いているか分からなくなります。

Q. 生成AIを使った自動化は、この3つのどれに入りますか。

AIは、3つの方式の中の「処理の1つ」として組み込めます。たとえばiPaaSの流れの途中で、問い合わせの種類をAIで分類する、といった使い方です。AIを入れても、動かす土台が必要なので、選び方は同じ順で考えられます。

Q. 外部に頼むのと、社内で作るのはどう分けますか。

小さな転記や通知は社内で始めやすく、認証、エラー処理、権限の設計が絡む部分は、最初の設計だけ外部の力を借りると進めやすくなります。Nexlyでも、設計と構築を支援し、その後を社内で回せる形にする進め方を取っています。

まとめ：選ぶ順番は「Googleの中か、APIか、画面か」

RPA、iPaaS、GASは、触る場所が違う別の道具です。Googleのサービスの中で完結するならGAS、APIが使えるならiPaaS、画面操作しかないならRPA、という順に当てはめると、多くの場合は決まります。決めるときは、ツール代より、直し続ける手間と、止まったときに気づける仕組みを見てください。

• 3つの違いは、触る場所（画面・API・Googleの中）で整理できる
• 費用は、作る手間と直す手間に分けて、直す頻度で比べる
• RPAは画面の変更に弱く、GASは実行時間の上限と作成者アカウントに注意する
• どの方式でも、通知先と保守の担当者を、公開前に決める
• 自動化が増えたら、名前・目的・方式・書き込み先・担当者を台帳にまとめる

関連記事

• DXが失敗する原因｜よくある7つのパターンと立て直し方
• デジタル化・AI導入補助金2026（旧IT導入補助金）｜対象・補助額・申請の流れ
• CRM・SFA・MAの違い｜役割と、中小企業が導入する順番