毎朝のCSV作業、全部RPAにする？Power Query・GAS・RPAの使い分け

たとえば、毎朝CSVを開き、列を直して合計し、別のシステムへ転記する。この一連の仕事を、すべてRPAで操作すべきでしょうか。先に決めたいのは製品名より、どの工程を機械へ渡し、どこで人が確かめるかです。

Power Queryは取込み・整形、GASは処理を書くための基盤、RPAは主に画面操作、APIはシステム間の接続手段です。役割が違うため、単純な四択にはできません。GASからAPIを呼ぶ、RPAが保存したCSVをPower Queryで集計する、といった併用も候補です。集計した数字を報告書や請求書の形で出すところまで自動化するなら、帳票レイアウトとデータの整理方法も役立ちます。

「定型業務」は手順や判断ルールが決まる仕事。「定例業務」は一定の時期に繰り返す仕事です。毎月行っていても判断が毎回異なる作業は、同じ手順だけでは自動化できません。

まず、必要なところまでで候補を絞ります。

自分の業務で確かめること	最初に試す構成
集計表ができれば仕事が終わるか	CSVの取込み・整形・照合をPower Queryで行う
別システムへの登録も必要か	既存のCSV取込みや登録・照会APIを調べる。GASなどの処理と組み合わせる
必要な取得・登録は画面操作でしかできないか	その工程にRPAを使い、整形や照合は別の方法も比べる

集計・転記・画面操作を分ける

「受注集計を自動化したい」を、まず次の4工程に書き換えます。集計だけでよいのか、販売システムへの登録まで必要なのかで、選択は変わります。

工程	入力・対象	処理後の状態
①取込み	同じ列構造のCSV 2ファイル	6明細を取得。元ファイルと入力行IDを保存
②整形	受注ID＋明細番号で比較	有効4明細、重複1明細を除外、不足1明細を保留
③登録	有効4明細を登録先へ渡す	受付番号や登録先IDを記録。結果不明を成功にしない
④照合	登録先から同じ受注ID・明細番号で結果を取得	数量・単価・金額まで一致した明細だけ照合済み

2026年9月14日の受注を、営業日1回まとめて処理する例です（想定例）。担当者が起動する運用を考えます。2つのCSVに計6明細があり、数量は個、金額は税計算を省いた「数量×単価（円）」です。各製品や登録先での実機試験は行っていません。

登録単位は受注ID＋明細番号です。同じ受注明細が2回届き、別の1明細は商品コードが空欄です。後から届いた同一内容の1明細を重複として除外し、商品コード不足の1明細を保留すると、有効な登録候補は4明細・8個・11,000円になります。商品別合計と、登録する明細一覧は分けて残します。

4,000円の登録結果が不明になったら

有効4明細のうち、4,000円分の1明細で、09:05に登録結果が分からなくなったとします。照合済みは3明細・7,000円で、残る1明細・4,000円を成功扱いしません。09:10に登録先を照会して同じ受注ID・明細番号・数量・単価の登録を確認できれば、再送せず照合済みにできます。この時刻は説明用で、処理時間の実測ではありません。

照会できない場合は保留し、担当者が調べます。再送は未登録と分かった場合や、相手APIに重複防止機能がある場合に、その仕様に従って行います。複数の処理が同時に同じ明細を送らないよう、実行の重なりと登録先の重複防止も確認します。

既存機能でできる範囲を調べる

担わせる工程から方法を選ぶ

Power Queryでは、同じ構造のファイルを結合し、サンプルに定義した変換を各ファイルへ適用できます。毎日のCSVで列構造がそろい、欲しい成果がExcel上の集計表なら、取込み・整形を中心に組む案が候補です。外部システムへの登録や、登録済み明細の確認は別に用意します（出典：Microsoftのファイル結合の説明）。

GAS（Google Apps Script）は、JavaScriptでGoogle Workspaceを使う処理を書く基盤です。「スプレッドシートを読む→条件で分ける→結果を書き込む」といった処理を設計します。UrlFetchAppはHTTP・HTTPSの要求と応答を扱えます。相手が必要なAPIを提供し、権限や契約条件を満たせば、GASから外部APIを呼ぶ構成を検討できます（出典：Google Apps Scriptの概要、UrlFetchAppの説明）。担当者が作ったGASやExcelマクロを引き継ぐときに最初に見る項目は、Excelマクロ・GASの引き継ぎ方にまとめています。

RPAは画面操作を中心に使う案で比較します。Microsoftのデスクトップフローは、画面要素・画像・座標などを使った操作や、ルールに基づく作業を扱います。RPA製品には画面操作以外の機能もあります。ファイル出力や標準の接続が使える部分まで、画面で処理する必要はありません（出典：Microsoftのデスクトップフローの説明）。

APIは、それ自体が定時に動く自動化ツールではありません。相手の仕様に従って登録要求を送り、結果を受け取る接続口です。実行するプログラムや標準の連携機能が別に必要です。必要な明細を登録・照会できるか、更新や取消をどう扱うかまで調べます。

いまある取込み・出力・接続を調べる

登録先にCSV一括取込みがあり、人が結果を確認する運用で間に合うなら、Power Queryで整形し、既存の取込みを使う案から試せます。Google Sheets内で完結するならGAS中心の案も考えられます。画面からしか取得できない範囲にはRPA、許可された登録・照会APIがある範囲にはデータ連携を置く、という分担です。機能の有無は自社の版・権限・契約で確認します。

Power Automateのクラウドフローには、イベント、ボタン、スケジュールを起点にする区分があります。起動方法の選択と、画面を操作するかどうかは別の論点です。標準の連携が必要な項目と例外処理を満たすなら、追加開発をしない案も残します（出典：Microsoftのクラウドフローの説明）。

集計・処理・画面操作の3方式を比較する

同じ受注データで、担当させる工程を比べます。自動化できる範囲は案によって異なります。登録先のAPI・CSV取込みは比較のための仮定です。

Power Query中心

取込み・整形・照合用集計。外部登録は別手段

Power Query中心の起動・利用条件・再開方法を見る

項目	内容
既存の機能	Excelの取得と変換
組み合わせ	取得にRPA、登録にCSV取込み
起動	営業日1回、担当者が更新
想定する問題	列変更・型不一致・重複
アカウントの担当	更新者と代行者。接続に使うアカウントを確認
再開方法	元CSVを保持し、変換を修正して再更新

GAS中心

取込み・整形・照合を処理。Google Sheets内への登録も設計

GAS中心の起動・利用条件・再開方法を見る

項目	内容
既存の機能	Google WorkspaceとGAS
組み合わせ	外部登録が必要ならAPI
起動	営業日1回、担当者が起動
想定する問題	利用上限・権限失効・同時実行
アカウントの担当	手動実行者。定期化する場合はトリガー作成者も確認
再開方法	履歴と登録先を照合し、未反映分だけ再処理

RPA中心

取得と登録を画面操作。整形と照合にもルールを作る

RPA中心の起動・利用条件・再開方法を見る

項目	内容
既存の機能	対象画面の検索・CSV出力
組み合わせ	集計をPower Queryなどへ分離
起動	営業日1回、有人起動を想定
想定する問題	画面変更・認証待ち・結果不明
アカウントの担当	実行端末の利用者と接続先アカウント、保守担当
再開方法	画面と登録結果を確認し、未反映分から再開

外部登録が必要なら、APIを組み合わせる

API連携

登録と結果取得の接続。処理を実行するプログラム等が別途必要

API連携中心の起動・利用条件・再開方法を見る

項目	内容
既存の機能	相手の登録・照会API（存在を仮定）
組み合わせ	標準の連携機能、GASなどのプログラム
起動	営業日1回、起動基盤で制御
想定する問題	仕様変更・認証失効・部分失敗
アカウントの担当	API認証の管理担当と実行基盤の管理担当
再開方法	結果を照会し、仕様に沿って未反映分だけ再送

足りない工程を組み合わせる

GASとAPIの組合せでは、GASが整形とAPI呼出しを受け持ちます。RPAとPower Queryの組合せでは、RPAがCSVを保存し、Power Queryが整形します。登録は、人が既存CSV取込みを操作する想定です。登録先にも画面操作しかなければ、その工程にRPAを追加する余地があります。

GAS＋API

GASで取込み・整形 → APIで登録 → GASと人が照合

GAS＋APIの起動・利用条件・再開方法を見る

項目	内容
既存の機能	Drive・Sheets・相手の登録／照会API（仮定）
組み合わせ	GASが外部APIを呼ぶ
起動	営業日1回、担当者が起動
想定する問題	GAS上限・相手側制限・結果不明
アカウントの担当	GAS実行者とAPI認証管理者を分けて確認
再開方法	ORD-005/001を照会。既登録なら再送しない

RPA＋Power Query

RPAでCSV保存 → Power Queryで整形 → 人がCSV取込み → 結果を照合

RPA＋Power Queryの起動・利用条件・再開方法を見る

項目	内容
既存の機能	画面のCSV出力・Excel・登録先のCSV取込み（仮定）
組み合わせ	③は既存CSV取込みを人が操作
起動	営業日1回、有人起動を想定
想定する問題	保存途中・列変更・取込み結果不明
アカウントの担当	RPA実行者・Excel更新者・登録担当
再開方法	保存完了を確認→再集計→登録先を照会し再開

表の起動頻度と担当は、この例の設定です。分担・想定する問題・再開方法は、公式資料の機能を踏まえた運用案です。

同じ受注データを工程ごとに受け渡し、保留と登録結果不明を完了から分けます（想定例）。

頻度と例外の数を調べる

選択表には、通常と繁忙時の明細数、起動回数、締切までに許される待ち時間、訂正や不足の件数を書きます。6明細の例が成立しても、月末の件数で間に合うとは限りません。候補を試すときは、同じ入力・同じ締切・同じ確認範囲で比べます。

GASにはアカウント種別などに応じた利用上限があり、超過すると例外が発生して実行が止まります。公式表（2026年9月15日時点）では、通常のスクリプト実行時間は個人向け・Google Workspaceとも1回6分です。カスタム関数などは別上限で、外部呼出しやトリガーの上限もあります。値は変わるため、実際のアカウントと呼出先双方の条件を確認します（出典：Googleの利用上限）。

この例の例外2明細は、同一内容の再送1明細と商品コード不足1明細です。前者は決めたルールで重複除外できますが、後者は担当者の確認が要ります。再実行で直る通信障害と、人の判断が要る訂正は分けて数えます。判断の待ち時間が長いなら、起動回数を増やすより、保留一覧と担当者への引継ぎを整える方が先です。

費用は作成、利用権、実行端末・基盤、アカウントの管理、停止後の調査、変更後の保守を、同じ対象期間で比べます。既存機能で必要な確認まで済み、残る手作業が許容できるなら、全工程の自動化を急がない判断もできます。

止まったときに直せるか比較する

再開方法には、どこまで反映したかを誰が調べるかまで書きます。Power Queryなら元ファイルと変換手順、RPAなら変更された画面と停止した明細、API連携なら要求・応答と登録先IDをたどれるようにします。列変更や画面変更はテスト用データで再確認してから戻し、読み飛ばした行がある状態を全件完了にしません。

GASのインストール型トリガーは、作成者のアカウントで動きます。担当者の退職・異動前に、管理者、実行者、トリガー作成者、接続先の認証管理者を洗い出し、後任の環境で再認証と試験を行う段取りを決めます。パスワードなどの認証情報そのものは選択表に書かず、担当者だけを記録します（出典：Googleのインストール型トリガーの説明）。

一つの仕事で、合計と明細を確かめる

最初の試験では本番の顧客データを使わず、期待する結果を先に置きます。正常に動くことだけでなく、止めるべき行を止め、同じデータを再処理しても登録済み明細を増やさないことを確かめます。

区分	明細数	数量（個）	金額（円）
入力全体	6	12	15,500
重複として除外	1	3	3,000
商品コード不足で保留	1	1	1,500
有効な登録候補	4	8	11,000

有効な商品別集計はP01が5個・5,000円、P02が3個・6,000円です。15,500円のうち重複3,000円と保留1,500円を除いた11,000円が一致することに加え、受注ID・明細番号・数量・単価を明細ごとに照合します。合計だけでは、別の明細への取り違えを見落とすためです。

試験には、通常入力、同一内容の再送、必須項目不足、同じ受注ID・明細番号で内容が異なる訂正、登録結果不明、同一バッチの再処理を含めます。たとえば重複行の数量だけを3個から4個へ変えて、再び取り込みます。元の行と数量が違うため、その明細を止めて担当者へ確かめることが期待する結果です。Excel選択表には追加試験の期待結果と、実行時に埋める結果欄があります。

有効4明細の照合が終わっても、商品コード不足の1明細は残ります。「有効4明細は照合済み／保留1明細あり」とし、バッチ全体を完了にしません。保留の担当者と訂正後の再処理を決め、次の勤務者にも同じ状態が伝わることを確認します。

選択表とチェック表を使う

Excelには記入例・空欄版・合成受注・期待値照合・登録と再開の例・試験チェックがあります。6明細の説明例です。

• 選択表・記入例・合成例の照合（Excel）
• 記入例と空欄のチェック表（PDF）
• 合成受注データA（CSV）
• 合成受注データB（CSV）

状況に応じた手順や判断自体をAIへ任せる場合は、AIエージェント・RPA・自動処理の使い分けで、任せる範囲と人が確定する条件を説明しています。

受渡しと訂正経路を整理して相談する

更新元や訂正経路がまだ決まらない場合は、二重入力を減らす｜更新元と訂正の決め方で、元データ・確認者・受渡しの順番から整理できます。システム間の登録と反映確認が課題なら、ツール・API連携の開発も参考になります。

選択表には認証情報や実データを貼らず、工程・件数・例外・困る停止箇所をまとめておきます。一業務の範囲と方法から整理すれば、既存機能で足りる部分と追加対応が必要な部分を分けて検討できます。

月次の取込みと件数・金額の照合例は、Power Queryの月次CSV集計｜欠落と重複の点検を参照してください。

事務作業の自動化を相談する

小さな一回で、何を確認してから方式を決めるか

受注6明細の例では、次の順で一回を追います。方式ごとの速さはまだ測っていないため、完成した範囲と残る人の操作を先に比べます。

試す段階	比較するもの
CSVの取込み・整形	6明細から対象4明細を選んだ理由。列を直す準備と、出力明細
登録	同じ受注ID・明細番号・数量・単価で登録できた範囲
応答が失われた後	登録先を調べ、登録済みの1明細を再送せずに確かめられるか
翌日の繰返し	同じ入力で二重登録せず、訂正がある場合は別に扱えるか

Power Queryの入力側は月次CSVの配布データと独立検算、登録側は注文連携のローカル教材で一部を試せます。両教材は別の見本で、RPA・GAS・Power Queryの速度や製品の優劣を測定したものではありません。自社の入力と登録先で同じ仕事を終える試験へ置き換えます。

参考出典

• Microsoft：Combine files overview
• Google：Google Apps Script overview
• Google：Class UrlFetchApp
• Microsoft：Introduction to desktop flows
• Microsoft：Overview of cloud flows
• Google：Quotas for Google Services
• Google：Installable Triggers

画面操作が残り、シナリオの作成や止まった処理の見直しが必要な場合は、RPAの作成・保守で対象業務と再開方法を相談できます。