【Office Scripts×PAD】Power Automate for Desktopのブラウザ操作でExcel on the webのスクリプトを起動する

記事内には広告が含まれます

2026年7月26日

PADのブラウザ操作でOffice Scriptsを起動する仕組み解説｜Office Scripts

はじめに

第5回では、クラウド版Power Automateの「Excel Online (Business)」コネクタにある「スクリプトの実行」アクションを使い、Office Scriptsをフローから呼び出す方法を解説しました。この方法は非常に便利ですが、1つ大きな制約があります。「スクリプトの実行」アクションはクラウドフロー専用であり、デスクトップフロー（Power Automate for Desktop、以下PAD）には存在しないという点です。

すでにPAD中心で業務フローを組んでいる方（デスクトップアプリの操作、ローカルフォルダの監視、メール添付ファイルの取得などと組み合わせている方）にとっては、「この処理だけクラウドフローに切り出す」のは構成が分断されて扱いにくいことがあります。

今回は、PADの「ブラウザーの自動化」アクションを使い、Excel on the web上に設置したスクリプト実行ボタン（第4回で設置したもの）を実際にクリックさせることで、PADのフロー内からOffice Scriptsを起動する方法を解説します。あわせて、この方式ならではの制約や、実運用に乗せる前に必ず検証しておくべきポイントも整理します。

注意： 本記事は実際にPAD環境で手を動かして検証しています。うまくいった部分だけでなく、つまずいた点・最終的に解決できなかった点もそのまま掲載しています。特にStep 4の完了検知は今回の検証では実用的な方法を確立できませんでした。MFA環境でのサインイン維持（Step 2）は未検証です。PADのバージョンやテナントの設定によって挙動が変わりやすい領域のため、実際に組み込む前にご自身の環境で動作確認を行ってください。

今回の検証結果（先に結論）

項目	結果
ブラウザでExcel on the webのファイルを開く	△ アドレスバーのURLをそのまま使うと構文エラー。共有リンクを使えば起動できた（Step 1）
スクリプト実行ボタンのクリック	✅ 成功。ボタンクリックによるスクリプトの起動は実現できた（Step 3）
制御シートのセル値を読み取って完了を検知する	❌ 今回の検証では実用的な方法を確立できなかった（Step 4）
MFA環境でのサインイン維持	未検証

要点： 「ボタンを押してスクリプトを起動させる」ところまではPADから実現できました。しかし「起動した結果をPAD側で受け取って後続処理に使う」部分は、今回の検証ではうまくいきませんでした。この結果を踏まえ、以下では実際に試した手順とつまずいたポイントをそのまま解説します。

前回までのおさらい

実行方法	起動元	進捗確認	キャンセル	主な用途
ワークシートのボタン（第4回）	Excel on the web（手動操作）	制御シート＋実行状態バー	停止ボタンで即時可能（第6回）	都度・手動での実行
Excel Online (Business) コネクタ「スクリプトの実行」（第5回）	クラウドフロー	制御シート（反映に遅延あり）	不可（実行状態バーが表示されない）	スケジュール実行・他システム連携
PADのブラウザ操作（今回）	デスクトップフロー	制御シート（PADからポーリング）	停止ボタンは使えない（後述の代替あり）	既存のPAD業務フローへの組み込み

先に結論を言うと： PADのブラウザ操作は「クラウドフローが使えない・使いたくない場合の代替手段」という位置づけです。UI操作を経由するぶん、クラウドフローの「スクリプトの実行」アクションより不安定要素が多く、実行時間も長くなります。PADでなければならない理由（既存フローとの統合、デスクトップ側の前後処理との連携など）がある場合に選ぶ方式と考えてください。

なぜPADから直接「スクリプトの実行」を呼べないのか

ここで整理しておきたいのが、PADの「Excel」アクショングループとOffice Scriptsは別物という点です。これは混同しやすいポイントです。

PADのアクショングループ	操作対象	Office Scriptsとの関係
Excel（Excelの起動・Excelワークシートから読み取る等）	ローカルにインストールされたデスクトップ版ExcelをCOM経由で操作	関係なし。Office ScriptsはExcel on the web専用の機能のため、このアクショングループからは呼び出せない
ブラウザーの自動化（新しいMicrosoft Edgeを起動する等）	ブラウザ上のWebページ（Excel on the webを含む）	✅ こちらを使えば、Excel on the web上のUI（スクリプト実行ボタンなど）を操作できる

PADの「Excel」アクションは、デスクトップ版Excelをバックグラウンドで起動してセルを読み書きする用途のものであり、クラウド上のスクリプトライブラリにはアクセスできません。Office Scriptsを起動したい場合は、必ず「ブラウザーの自動化」アクションで実際のWebページ（Excel on the web）を操作する必要がある、というのが今回の前提です。

全体の仕組み

PADフロー開始
↓
「新しい Microsoft Edge を起動する」→ Excel on the webのファイルURLを開く
↓
（初回のみ／セッション切れ時のみ）サインイン状態を確認する
↓
「UI要素の詳細を使用してクリックする」→ シート上のスクリプト実行ボタンをクリック
↓
「Webページからデータを抽出する」でループ監視
→ 制御シートのA1セルの表示が「完了」を含むまでポーリング
↓
完了を検知したらブラウザを閉じる／後続のPAD処理へ続ける

ポイントは、第6回で作った「制御シートのA1セルに進捗・完了メッセージを書き込む」仕組みを、今回はキャンセル判定ではなく「完了検知」に転用するという発想です。PAD側にはOffice Scriptsの実行完了を直接検知するAPIがないため、ブラウザ越しにセルの表示内容を読み取ってポーリングする、間接的な方法を試みました。ただし、結論から言うとこの部分（完了検知）は今回の検証ではうまく機能させられませんでした。 詳細と、つまずいたポイントはStep 4で解説します。

準備

今回のフローを組む前提として、以下がすでに用意されていることを確認してください。

前提	参照回
転記エンジンのOffice Scriptsが動作していること	第4回
ワークシートにスクリプト実行ボタンが設置されていること	第4回・第6回
「制御」シートのA1セルに進捗・完了メッセージが書き込まれる状態になっていること	第6回

また、PADからExcel on the webを操作する都合上、フローを実行する端末・アカウントで対象ファイルにアクセスできるサインイン状態を維持しておく必要があります。この点は次のStep 2で詳しく扱います。

Step 1：ブラウザを起動してファイルを開く

アクションペインから「ブラウザーの自動化」→「Webフォームの入力」グループ内の「新しい Microsoft Edge を起動する」（または使用しているブラウザに応じたアクション）をフローに追加します
「初期URL」に、対象ファイルのExcel on the webのURL（ブラウザで開いたときのアドレスバーのURL）を指定します
「起動モード」は、既存の（サインイン済みの）ブラウザーウィンドウを使うか、専用のプロファイルを指定するかを環境に応じて選択します
生成されたブラウザーインスタンス変数を、以降のアクションで参照します

実際に検証してわかったこと：アドレスバーのURLはそのまま使えない

Excel on the webを開いたときにアドレスバーに表示されるURLを「初期URL」へそのまま貼り付けると、構文エラーで起動に失敗しました。原因は、アドレスバーのURLに付与される大量のクエリパラメータ（長い英数字の識別子や&区切りのパラメータ）を、PADのアクションが正しく処理できないためと考えられます。

「初期URL」にabout:blankを指定してブラウザだけ先に起動し、その後「Webページに移動する」アクションで改めて対象URLへ遷移させる方法も試しましたが、こちらも同様に失敗しました。

解決できた方法：ファイルの「共有」リンクを使う

最終的に、Excel on the webでファイルを開いた状態で「共有」→リンクの取得から得られる共有リンク（SharePointの個人用共有URL）を「初期URL」に指定したところ、問題なく起動できました。共有リンクは次のような形式です。

https://[テナント名]-my.sharepoint.com/:x:/g/personal/[ユーザー識別子]/[ファイルID]?e=[共有コード]

アドレスバーのURLに比べてパラメータの構成がシンプルなため、PADのアクションで問題なく処理できたと考えられます。「初期URL」には、アドレスバーのURLではなく、必ずファイルの「共有」機能から取得したリンクを指定してください。

注意点： PADの「新しいインスタンスを起動する」（毎回まっさらなブラウザを開く）モードでは、サインイン情報が引き継がれずログイン画面から始まってしまうことがあります。安定した無人実行を目指す場合は、専用のブラウザプロファイルにあらかじめサインインしておき、そのプロファイルを毎回使い回す設定が現実的です。

Step 2：サインイン状態を確保する

これが今回の方式でもっとも詰まりやすいポイントです。

多要素認証（MFA）がある環境の場合

組織のポリシーでMFAが必須になっている場合、PADから完全に無人でサインインを突破するのは困難です。現実的な対応は次のいずれかになります。

対応方針	内容
ブラウザプロファイルの再利用	一度手動でサインインし、そのままセッション（Cookie）を保持したプロファイルをPADから毎回起動する。サインイン画面自体をスキップできる
条件付きアクセス・信頼できる場所の設定	実行元の端末・ネットワークをMFA対象外に設定できないか、社内のIT/情報システム部門に相談する（テナントのセキュリティポリシーに関わるため、個人の判断だけでは変更できないケースが大半）
サービスアカウントの利用	自動化専用のアカウントを用意し、MFA除外や制限付きの条件付きアクセスポリシーを個別に設定する

注意： MFA自体を回避する設定変更は、セキュリティポリシーに関わる判断です。個人の裁量で進めず、必ず情報システム部門・管理者と相談のうえで対応してください。

セッションが切れていないか確認する

サインイン済みプロファインを使う場合でも、Cookieの有効期限やテナント側のセッションポリシーにより、久しぶりの実行でサインイン画面に戻されることがあります。フローの先頭に「UI要素の存在を待つ」アクションでサインイン画面特有の要素（メールアドレス入力欄など）をチェックし、検出された場合はエラー終了して通知する、という異常系の分岐を入れておくと、無人実行時の事故（誤った画面のままボタンを探し続けて延々とタイムアウトする、など）を防げます。

Step 3：UI要素をクリックしてスクリプトを起動する

「UI要素の詳細を使用してクリックする」アクションをフローに追加します
UI要素ピッカー（虫眼鏡アイコン）でブラウザ画面を選択し、シート上に設置したスクリプト実行ボタンをクリックして要素を記録します
記録されたUI要素が変数として保存されるので、アクションの「UI要素」欄に指定します

注意点： Excel on the webのシート領域はCanvas（描画）ベースで構成されており、通常のHTML要素のようにテキストやIDで直接特定しづらい場合があります。UI要素の認識が不安定な場合は、以下を試してください。

ピッカーで要素を選び直し、複数回記録して安定するセレクターを探す
「画像認識を使用してクリックする」アクション（座標・画像ベースのクリック）を代替手段として検討する
ウィンドウサイズ・ズーム倍率を固定し、毎回同じレイアウトで開くようにする（Canvas要素は表示サイズの影響を受けやすいため）

Step 4：完了を検知する（今回の検証では未解決）

スクリプト実行ボタンをクリックすると、第6回で確認した「実行状態」バー（停止ボタン付き）がブラウザ上に表示されます。ただし、PADにはこのバーの状態を直接判定するAPIはありません。そこで、制御シートのA1セルに書き込まれる文字列をポーリングして完了を検知する方法を試しましたが、今回の検証では実用的な形にできませんでした。つまずいたポイントと、そこから分かったことを共有します。

セルを直接指定して抽出することはできない

「Webページからデータを抽出する」アクションでA1セルを直接指定しようとしましたが、セル単位でのUI要素指定はできませんでした。Step 3の注意点でも触れたとおり、Excel on the webのシート領域はCanvas（描画）ベースで構成されており、個々のセルが独立したUI要素として認識されないためと考えられます。

数式バーのテキストは取得できたが、判定がうまくいかなかった

回避策として、A1セルを選択した状態で数式バー（フォーミュラーバー）のUI要素を記録し、その詳細情報からOwn Text属性を変数（例：AttributeValue）に取得する方法を試しました。この方法では、以下のようにHTMLタグに包まれた状態でセルの表示内容を取得できることを確認しました。

<div class="ewa-rteLine">完了！【データ更新件数： 1000 件】</div>

ここまでは想定通りでしたが、この先の「取得した文字列に特定の文言が含まれるかどうか」の判定でつまずきました。If条件でAttributeValueが「完了！」を含むかどうかを判定する方法、正規表現を使った判定方法など複数の方法を試しましたが、安定して意図通りに動作させることができませんでした。

現時点での結論

スクリプト実行ボタンをクリックしてOffice Scriptsを起動するところ（Step 1〜3）までは実現できました
一方で、Excel on the webの表示内容をPADから読み取って後続処理に利用する（完了検知・結果の取得）ことは、今回の検証では実用的な方法を確立できませんでした
そのため現状は、PADのブラウザ操作でOffice Scriptsを扱う場合、「起動させるだけ」の一方向の連携と割り切り、完了検知・結果の受け取りはPAD側で行わない、という前提で設計するのが現実的です

代替案（いずれも未検証）

完了検知そのものを諦める場合、以下のような割り切った方法が考えられます。今回は実際に試せていないため、あくまで案として紹介します。

方法	内容	懸念点
固定時間のWait	データ件数から想定される処理時間を見積もり、余裕を持ったWait秒数で待つだけにする	データ量が変動すると見積もりがずれる。確実性は低い
~~実行状態バーの消失を待つ~~	「実行状態」バーというUI要素そのものの存在・非存在を判定する案	検証の結果、不採用。スクリプトの実行が完了しても実行状態バーは消えないため、この方法自体が成立しない。また、このバーからテキストを取得できたとしても、A1セルの数式バーと同様にHTMLタグ付きの文字列になると考えられ、同じ判定の壁にあたる可能性が高い
完了検知を諦め、第5回のクラウドフローと併用する	スクリプトの起動はPADのボタンクリックで行い、完了通知だけは第5回のPower Automateクラウドフロー（別トリガー）に任せる	フローが2系統に分かれ、構成が複雑になる

現時点で自信を持って推奨できる完了検知の方法はありません。この点は今後の検証課題として持ち越します。

できること・できないことの整理

実現したいこと	PADのブラウザ操作
クラウドフローを使わずにOffice Scriptsを起動する	✅ 可能（ブラウザ操作を経由。ただし初期URLは共有リンクを使う必要あり）
既存のPAD業務フローに組み込む	✅ 起動させるだけなら可能。デスクトップ側の前後処理と1つのフローで完結できる
完了・エラーの検知	❌ 今回の検証では実用的な方法を確立できなかった（Step 4参照）
実行状態バーの「停止」ボタンをPADから操作する	❌ 不可。PADからバーの状態は判定できない
MFA環境での完全無人実行	未検証
クラウドフロー（第5回）に対する安定性	❌ 劣る。UI要素の認識に依存するぶん失敗要因が多い

まとめると：PADのブラウザ操作は「スクリプトを起動させる」ところまでは実際に動作を確認できました。しかし「起動した結果をPAD側で受け取って後続処理に使う」部分は、今回の検証では実現できませんでした。完了検知や結果の取得が必要なら第5回のクラウドフロー方式を優先し、PAD経由の起動は「起動させるだけでよい／既存のPAD業務フローに組み込みたい」といった限定的な用途で選ぶのが現実的です。

よくある質問・エラー対処

Q. 「初期URL」にExcel on the webのアドレスバーのURLを指定すると構文エラーになる

→ アドレスバーのURLには大量のクエリパラメータが付与されており、そのままでは「新しい Microsoft Edge を起動する」アクションで処理できませんでした。ファイルの「共有」機能から取得できる共有リンクを使ってください（Step 1参照）。

Q. UI要素ピッカーでボタンをうまく選択できない

→ Excel on the webのシート領域はCanvasベースで描画されているため、要素の境界が認識しにくいことがあります。ズーム倍率100%・ウィンドウサイズを固定した状態で記録し直してみてください。それでも安定しない場合は、座標・画像ベースのクリックアクションを代替手段として検討してください。

Q. サインイン画面で毎回止まってしまう

→ 使用しているブラウザプロファイルのセッションが切れている可能性があります。手動で一度サインインし直し、そのプロファイルをPADの起動アクションで指定してください。MFAが必須の環境での完全無人化については、今回未検証です（Step 2参照）。

Q. 制御シートのA1セルの値をうまく取得・判定できない

→ セルを直接UI要素として指定することはできません。数式バーのOwn Text属性からテキストを取得することはできますが、HTMLタグに包まれた文字列になり、その後の含有判定（If条件・正規表現）を安定して機能させることができませんでした。今回の検証では解決に至っていません（Step 4参照）。完了検知が必須であれば、現状は第5回のクラウドフロー方式を検討してください。

Q. クラウドフロー（第5回）ではなく、あえてPADを使うメリットは？

→ 主なメリットは「既存のPAD業務フローと1つのフローに統合できる」点です。ただし今回の検証で分かったとおり、完了検知や結果の取得はPAD側では確立できていません。「スクリプトを起動させるだけでよい」場合の選択肢と考え、完了通知や結果の利用が必要な場合は第5回のクラウドフロー方式のほうが安定しており、構成もシンプルです。

まとめ

PADの「Excel」アクショングループはデスクトップ版ExcelをCOM操作するものであり、Office Scriptsとは無関係。Office Scriptsを起動するには「ブラウザーの自動化」アクションでExcel on the webを直接操作する必要がある
「初期URL」にはExcel on the webのアドレスバーのURLをそのまま使えない（構文エラーになる）。ファイルの「共有」機能から取得できる共有リンクを使う必要がある（実際に検証して確認）
UI要素のクリックによるスクリプトの起動（Step 1〜3）は、実際に検証して動作を確認できた
一方、制御シートのセル値を読み取って完了を検知する方法（Step 4）は、セルを直接指定できない・数式バーから取得した文字列の判定が安定しないという壁にあたり、今回の検証では実用的な形にできなかった
サインインの維持（特にMFA環境）は今回未検証のまま残っている課題
現状PAD経由でOffice Scriptsを扱う場合は「起動させるだけ」の一方向の連携と割り切るのが現実的。完了検知や結果の取得が必要な場合は、第5回のクラウドフロー方式を優先する