「Google WorkspaceからMicrosoft 365への全社移行が決まったので、Google Apps Scriptのツール群をこちらで作り直してほしい」と言われ、何から手をつけていいか分からずに固まっていないでしょうか。
社内にPower Platformの経験者がいない状態でこの指示だけ渡されると、スクリプトを1行ずつ読み替えれば済むのか、それとも作り直しになるのか判断がつきません。
この記事では、実際の移行案件で使っている進め方をもとに、移行前の棚卸しから機能対応表、検証、切り替えまでの手順を整理しています。
移行の全体像：コードの翻訳ではなく作り直し
最初に押さえておきたいのは、Google Apps Scriptのコードをそのまま翻訳してもPower Automateのフローにはならないということです。
Google Apps Scriptは1つのスクリプトの中で条件分岐やループを自由に書けますが、Power Automateはトリガーとアクションを積み上げて処理の流れを作る仕組みで、構造そのものが違います。
そのため、既存コードを関数単位で置き換えていく発想ではなく、業務の入口（何が起きたら動くか）と出口（何をどこに書き込むか）だけを抜き出し、フローとして組み直す発想に切り替える必要があります。
そもそもどちらのツールで新しく作るべきかを迷っている段階であれば、判定基準を先に確認しておくと後戻りが減ります。
移行前の棚卸しで確認する3点
作り直しに着手する前に、既存のGoogle Apps Scriptを3つの観点で棚卸しします。
この棚卸しを飛ばすと、移行の途中で想定外の依存関係が見つかり、手戻りが発生しやすくなります。
何本のスクリプトがどのトリガーで動いているか
まず社内に存在するスクリプトの本数を数え、それぞれがどのトリガーで起動しているかを一覧化します。
時間主導型のトリガー、スプレッドシート編集時に動くonEdit、フォーム送信時に動くonFormSubmitでは、Power Automate側で用意する仕組みが変わるため、この段階で分類しておく必要があります。
どのサービスに読み書きしているか
次に、各スクリプトがどの外部サービスとやり取りしているかを確認します。
Gmail送信だけで完結するものもあれば、スプレッドシートとカレンダーの両方を操作するもの、外部APIをUrlFetchAppで呼び出しているものもあります。
外部API呼び出しがあるスクリプトは、後述するPremiumライセンスの要否に直結するため、ここで洗い出しておくと後の判断が早くなります。
誰がいつ使っているか（使われていないものは移行しない）
最後に、実行ログやトリガーの発火履歴から、実際にどれだけ使われているかを確認します。
作成した本人しか存在を知らず、数年間動いていないだけのスクリプトが見つかることも珍しくありません。
使われていないものまで移行対象に含めると、検証の手間だけが増えて費用対効果が下がるため、この段階で棚卸しリストから外します。
機能対応表：Google Apps Scriptの処理はPower Automateの何になるか
棚卸しが終わったら、Google Apps Scriptの処理を何に置き換えるかを対応表で確認します。
Premium要否は公式ドキュメントで確認した内容です（確認日：2026年7月）。
| Google Apps Scriptの処理 | Power Automateでの対応 | Premium要否 |
|---|---|---|
| GmailApp.sendEmailによるメール送信 | Office 365 Outlookコネクタの「メールの送信」アクション | 不要（Standard） |
| SpreadsheetAppによるスプレッドシートの読み書き | Excel Online (Business)コネクタの「テーブルに行を追加する」「行を取得する」等のアクション | 不要（Standard） |
| 複雑な文字列処理・数値計算・データ加工 | Office Scripts（Excel Online (Business)コネクタの「スクリプトの実行」アクション経由で呼び出す） | 不要（Standard） |
| ScriptAppの時間主導型トリガー | スケジュール済みクラウドフロー（繰り返しトリガー） | 不要（Power Automateの組み込み機能） |
| onEdit（スプレッドシート編集の検知） | 直接の代替なし | 該当なし（つまずきやすいポイントで後述） |
| UrlFetchAppによる外部API呼び出し | HTTPコネクタ | 必要（Premium） |
表の中でとくに注意したいのがHTTPコネクタです。
外部APIと連携しているスクリプトが1本でもあると、そのフローだけPremiumライセンスが必要になります。
棚卸しの段階で「外部APIを呼んでいるかどうか」を確認しておく理由はここにあります。
Google Apps ScriptでできてもPower Automateでは代替が難しい処理については、別記事で個別に整理しています。
移行手順
対応表で置き換え先が見えたら、実際の移行は次の4ステップで進めます。
Step1. 移行対象の優先順位を決める
棚卸しリストの中から、使用頻度が高く、かつ依存している外部サービスが少ないスクリプトを優先します。
利用頻度が低いものや、複数のスクリプトから呼び出されている共通処理は後回しにした方が、途中で行き詰まったときの影響範囲を小さく保てます。
Step2. 1本だけ先に移行して検証する
優先順位が決まっても、全部を同時に移行しようとしないことです。
まず影響範囲の小さい1本だけを先にPower Automateへ移行し、動作を確認してから次に進みます。
実際の移行案件でも、検証を先行させてから残りを横展開する進め方が最も手戻りが少なく、これは外部に検証だけを依頼する場合でも変わらない実務標準です。
Step3. 同じ入力で同じ出力になるか確認する
移行したフローに、既存のGoogle Apps Scriptと同じ入力データを与え、出力が一致するかを確認します。
見た目の動作だけでなく、メールの文面、書き込まれるセルの位置、日付の表記形式まで突き合わせるのが望ましいです。
ここで差分が見つかった場合は、対応表の選択が間違っているか、Google Apps Script側に把握できていない処理が隠れている可能性があります。
Step4. 並行稼働期間を置いて切り替える
検証が済んでも、いきなりGoogle Apps Script側を止めないようにします。
一定期間は両方を並行稼働させ、実運用のデータでも問題が出ないことを確認したうえで、Google Apps Script側のトリガーを無効化して切り替えます。
自動化の始め方そのものを見直したい場合は、以下の記事もあわせて参考にしてください。
つまずきやすいポイント
移行作業を進める中で、とくにつまずきやすいポイントが2つあります。
Excel OnlineにはonEdit相当のトリガーがない
Excel Online（Business）コネクタには「選択した行の場合」というトリガーが用意されていますが、これは名前のとおり利用者がセルを選択してボタンを押す操作が必要な手動トリガーです。
スプレッドシートが編集された瞬間に自動で発火するonEdit相当の仕組みは、Power Automate側には存在しません。
編集検知が必須の業務であれば、一定間隔で内容をチェックするスケジュール済みクラウドフローに置き換えるか、編集操作自体をPower Automateの手動フロー経由で行う運用に変える必要があります。
複雑なデータ加工はOffice Scriptsに寄せる
Power Automateの標準アクションだけで複雑な文字列処理や配列操作を組み立てると、フローの見た目が条件分岐だらけになり、後から追いかけるのが難しくなります。
このような処理は、TypeScriptでロジックを書けるOffice Scriptsに寄せた方が、Google Apps Scriptに近い書き方のまま保守しやすい形に収まります。
Power Automate側は「Office Scriptsを呼び出して結果を受け取るだけ」の役割に絞ると、フロー全体の見通しがよくなります。
この移行、1本目の検証だけ先に任せてみませんか？
対象の業務フローを3本まで、5万円固定で検証を依頼できます。
小さく始める前提のため、1本だけの検証からでも構いません。
納品するのは、フローごとの移行可否判定と概算の実装工数、対応表だけでは見えない移行時のつまずきポイントをまとめたレポートです。
検証の結果、そのフローの移行が難しいと分かった場合も、その理由と代替案をレポートに明記してお渡しします。
よくある質問
Q. Google Apps ScriptとPower Automateは1対1で置き換えられますか？
置き換えられない場合があります。
Google Apps Scriptは1つのスクリプトに複数の処理をまとめて書けますが、Power Automateは処理の単位でフローを分けた方が管理しやすいため、1本のスクリプトが複数のフローに分割されることがあります。
対応表で処理単位を洗い出したうえで、フローの分割方針を先に決めておくと迷いにくくなります。
Q. 移行にどれくらいの期間がかかりますか？
スクリプトの本数と依存する外部サービスの数によって大きく変わるため、一律の期間は決まりません。
1本あたりの目安としては、棚卸しから並行稼働開始までを含めて数日から2週間程度かかるケースが多いです。
複数本を同時並行で進めるより、1本ずつ確実に検証して積み上げた方が、結果的に全体の期間が短くなります。
Q. Premiumライセンスがどれくらい必要になるか事前に分かりますか？
棚卸しの段階で、外部API呼び出しやプレミアムコネクタが必要な処理を洗い出せば、必要な範囲はおおむね事前に把握できます。
ただし、対応表を作る過程で想定していなかった外部連携が見つかることもあるため、最終的なライセンス構成は棚卸しと対応表の両方が完成した時点で確定させるのが確実です。
Q. 移行を外部に依頼する場合、何を渡せば見積もりが取れますか？
棚卸しで作成したスクリプト一覧（本数、トリガー種別、連携先サービス、利用状況）があれば、見積もりの精度が大きく上がります。
逆にこの一覧がない状態で依頼すると、依頼先が現地調査から始めることになり、期間も費用も膨らみやすくなります。
1本だけ先に移行して検証する進め方も、外部依頼と自社対応のどちらでも共通して有効です。
