【Office Scripts×PAD】クラウドPower AutomateなしでWeb版ExcelからPADのフローを実行する方法

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

2026年9月12日

クラウドPower AutomateなしでWeb版ExcelからPADを起動する仕組み解説｜Office Scripts

はじめに

第7回では、PADの「ブラウザーの自動化」からExcel on the webのスクリプト実行ボタンをクリックし、PAD→Office Scriptsの方向で起動する方法を検証しました。第10回の次回予告で触れたとおり、このシリーズの仕上げとして残っていたのが、その逆方向（Excel→PAD）です。すなわち「Web版Excelのシート上を操作画面にして、そこからWindows上のPADのフローを起動する」という構成です。

今回は、Microsoft公式ドキュメントで確認できた「実行URL」という仕組みを軸に、クラウド版Power Automateを一切使わずに実現する設計をまとめます。実際に手を動かして検証したところ、途中でExcel for the web独自の壁に当たりましたが、最終的にWeb版Excelのセルのリンクをクリックして、実際にPADのフローを起動するところまで実機で成功しました。 検証の過程でつまずいた点も含め、そのまま解説します。なお、Excelのセルの値をPADのフロー入力（inputArguments）として動的に渡す方法は、記事のボリュームの都合で次回に分けて解説します。

前提とする環境： Windows Home／Web版Excel／Office Scripts／PAD（Power Automate for desktop）／クラウドPower Automateは不使用

今回の設計方針（先に結論）

項目	採用する方式	状態
PAD起動のトリガー	Microsoft公式の「実行URL」（`ms-powerautomate:` から始まる専用URL）	実機で成功。 Web版Excelのセルのリンク→中継ページ→実行URL→PAD起動まで確認済み
「Excel上のボタン」の実体	Office Scriptsのボタンではなく、セルに置いたハイパーリンク（`HYPERLINK`関数、`https://`の中継ページ経由）	実機で成功（理由・詳細は次章以降）
Office Scriptsの役割	PADに渡す値（ファイル名・日付・モードなど）をセルへ書き込む前処理のみ	設計方針として確定（活用は次回）
クラウドPower Automate	不使用	確定
最大のリスク	実行URL機能は公式に「Power Automate Premiumプラン、または従量課金制環境へのアクセス権が必要」と明記されている	解消。ライセンスは「Power Automate for Office 365」＋「Power Automate 無料版」のみ（Premium・従量課金制は含まれない）にもかかわらず、デスクトップショートカット経由の起動には成功した

なぜ「Office Scriptsボタン」ではなくセルのハイパーリンクなのか

第7回・第9回までの検証で、Office Scriptsには次のような制約があることが分かっています。

Office Scriptsは Excel のブックを操作するための TypeScript であり、window.open() のようにブラウザのウィンドウやタブを直接操作する仕組みは持っていません
ローカルにインストールされたアプリケーション（PADを含む）を直接起動する命令も存在しません

つまり、「Office Scriptsのボタンを押した『中』でPADを起動する」という発想自体が成立しません。実際にPADを起動できるのは、あくまで「ブラウザがリンクをクリックされて、OS（Windows）に対してms-powerautomate:という未知のプロトコルを開くよう要求する」という、ブラウザ標準の仕組みです。

したがって今回の設計では、シート上のセルにHYPERLINK関数で実行URLへのリンクを設置し、それをクリックしてもらうという形を「Excel上のボタン」の実体とします。Office Scriptsは、このリンク先URLに含める値（次回解説するinputArguments）を、クリックされる前に整えておく前処理役に徹します。

実行URLの仕様（Microsoft公式ドキュメントより）

URL またはデスクトップショートカットでデスクトップフローを実行する（Microsoft Learn）の内容を整理します。

前提条件

Power Automate for desktop が、使用しているマシンにインストールされていること
ユーザーがサインインしていること
ユーザーが、Power Automate Premiumプラン、または従量課金制環境へのアクセス権を持っていること

3つ目の条件が今回もっとも重要です。「クラウドフローを作らない・使わない」としても、実行URLという機能自体がPremiumプラン（または従量課金制）に紐づいている可能性があります。無料プランのアカウントで実際に動作するかは、公式ドキュメントの記載だけでは断定できません。

→ 実機検証の結果、この前提条件どおりではないことが分かりました。 詳細は次章で解説します。

URLの形式

ms-powerautomate:/console/flow/run?workflowName=[workflowName]
ms-powerautomate:/console/flow/run?workflowId=[workflowId]
ms-powerautomate:/console/flow/run?environmentId=[environmentId]&workflowId=[workflowId]

フローID・フロー名のどちらかを指定します。環境IDを省略すると、PADコンソールで現在選択中の環境が使われます。

値を渡す（inputArguments）

inputArgumentsパラメータを使うと、JSON形式でPADのフロー入力に値を渡せます（サポートされる型はテキスト・数値・ブール値のみ）。Excelのセルの値を動的に渡す具体的な方法は、次回の記事で扱います。

そのほかの注意点

既定では、実行URL・デスクトップショートカット経由の起動時に確認ダイアログが表示される仕様です（無効化も可能だが、公式に「悪意のあるフローを気付かず実行する危険性がある」と警告あり。今回は無効化しない前提で設計します）。

実機検証：デスクトップショートカットでの起動確認

まず手始めに、PADコンソールで既存のデスクトップフロー（「PAD×PythonScriptでExcelデータ取得」、第9回で作成したフロー）を右クリックし、「デスクトップショートカットを作成」で生成した.urlファイルを実際にダブルクリックして試しました。

生成されたショートカットの中身は次のような.urlファイルでした。

[InternetShortcut]
URL=ms-powerautomate:/console/flow/run?environmentid=Default-c24aa004-e333-4d48-94f4-ef009b79545e&workflowid=f310acca-c97f-4dae-b4f3-015679868321&source=Shortcut

結果：成功。 クリックすると、公式ドキュメントに記載の通り「フローを実行外部ソースが次のフローの実行を試みています：PAD×PythonScriptでExcelデータ取得このソースを信頼できる場合にのみ続行してください。」という確認ダイアログが表示され、「続行」をクリックすると実際にフローが実行されました。

実行URL（ms-powerautomate:）による起動そのものは、この環境（Windows Home）で問題なく機能することが確認できました。また、生成されたURLのパラメータ名はenvironmentid・workflowidとすべて小文字（公式ドキュメントのサンプルはenvironmentId・workflowIdとキャメルケース）で、source=Shortcutというドキュメントに記載のないパラメータも自動付与されていました。パラメータ名の大文字・小文字は区別されない可能性があります。ただしこの時点では、無料プランでも動作するか、Web版Excelのセル上のハイパーリンクからでも動くかは、まだ確認できていません。

ライセンスを確認：Premiumではなく無料相当のプランだった

公式ドキュメントの前提条件（「Power Automate Premiumプラン、または従量課金制環境へのアクセス権が必要」）を踏まえ、実際のライセンスを確認していただいたところ、結果は次の通りでした。

あなたのライセンス：Power Automate for Office 365／Power Automate 無料版／Power Automate 無料版

「Power Automate for Office 365」（Microsoft 365に付属するプラン）と「Power Automate 無料版」のみで、Premiumプランや従量課金制環境は含まれていません。 それにもかかわらず、前章のデスクトップショートカットからの起動は問題なく成功しています。

つまり、少なくとも「デスクトップショートカットから、手動でボタンをクリックして確認ダイアログを通過させ、ローカルの既存フローを実行する」という使い方に限っては、公式ドキュメントに記載の前提条件（Premium／従量課金制）を満たしていなくても動作することが実機で確認できました。ドキュメントの記載と実際の挙動に食い違いがある可能性がある、記事化する価値のある発見です（無効化した確認ダイアログでの無人実行など、他の使い方でも同様とは限りません）。

実機検証：Web版Excelのハイパーリンクからの起動（失敗）

デスクトップショートカットでの成功を受け、次はいよいよ本命の「Web版Excelのセルに置いたハイパーリンクから同じことができるか」を試しました。セルに次の数式を入力し、生成されたリンクをブラウザ上でクリックしました。

=HYPERLINK("ms-powerautomate:/console/flow/run?environmentid=Default-c24aa004-e333-4d48-94f4-ef009b79545e&workflowid=f310acca-c97f-4dae-b4f3-015679868321","▶ PAD実行")

結果：失敗。 PADの確認ダイアログではなく、Excel for the web自体が次のダイアログを表示し、その場でブロックしました。

Excel for the webがms-powerautomate:リンクをブロックして表示する「リンクを開けません」エラーダイアログ

分かったこと

Excel for the webのハイパーリンク機能自体が、クリックされたリンク先のURLを独自に検証しており、http://・https://以外の未知のスキームを「ローカルファイルを参照している可能性がある」とみなしてブロックしているらしいということが分かりました。ブラウザ自体の制限ではなく、Excel for the webというアプリケーション側が独自に行っているチェックと考えられます（デスクトップショートカットでは同じURLが問題なく動作したため、OS・ブラウザレベルではms-powerautomate:スキームは正しく認識されています）。ダイアログの選択肢「デスクトップアプリで開く」は、PADではなくデスクトップ版Excelでこのブックを開くという意味で、今回の目的とは無関係でした。

つまり、「Web版Excelのセルにハイパーリンクを置いて、それをクリックしてPADを起動する」という、当初想定していた最もシンプルな経路は、Excel for the web自身のガードによって塞がれていることが実機で確認できました。

回避策：中継ページを挟む

Excel for the webが弾いているのが「http/https以外のスキーム」だとすれば、一度はhttps://から始まる通常のWebページを経由させ、そのページ側でJavaScriptを使ってms-powerautomate:へリダイレクトさせる、という2段階の構成にすれば回避できるはずだと考えました。この中継ページはPower Automateのクラウドフローとは無関係の、単なる静的なリダイレクト用ページ（kurumico.com上に1ページ用意）で構成できるため、「クラウドPower Automateを使わない」という今回の方針とは矛盾しません。結論から言うと、この回避策は実機検証で成功しました。

中継ページの実装

実行URLを?url=パラメータとして受け取り、自動的にms-powerautomate:へリダイレクトする、汎用的な中継ページを用意しました（officescripts-11-pad-launch.html）。特定のフローに固定せず、どの実行URLでも同じページを使い回せます。中身は次のようなJavaScriptで、パラメータをデコードしてそのままリダイレクトするだけのシンプルなものです。

var params = new URLSearchParams(window.location.search);
var decoded = decodeURIComponent(params.get('url'));
window.location.href = decoded; // ms-powerautomate: へリダイレクト

重要な訂正： 当初はこのページに渡すURLを、Excel側でHYPERLINK関数＋ENCODEURL関数を使って組み立てる想定でした。ところがENCODEURL関数はExcel for the webでは使用できないことが、後のinputArguments検証中にMicrosoft公式ドキュメントで判明しました（ENCODEURL 関数 | Microsoft Supportに「Excel for the web または Excel for Mac では使用できません」と明記）。次章の成功事例で実際に使っていたのは、ENCODEURLをその場で計算させた数式ではなく、あらかじめエンコード計算しておいた結果の文字列を、そのまま数式に埋め込んだものでした。

実機検証：中継ページ経由での起動（成功）

中継ページ（officescripts-11-pad-launch.html）をkurumico.comへアップロードし、Excelのセルにこの中継ページへのリンクを設置して、Web版Excel上でクリックしました。

結果：成功。 一連の流れは次の通りです。

Excelのセルのリンクをクリック → 中継ページが正常に開いた（直接ms-powerautomate:を指定したときのような「リンクを開けません」エラーは発生しなかった）
中継ページ内のJavaScriptが自動的にms-powerautomate:へリダイレクト
PADの「フローを実行」確認ダイアログが表示された
「続行」をクリック → 実際にPADのフローが起動した

比較のため、同じタイミングでローカルファイル（file://）への直接リンクもシート上で試しましたが、こちらは開けませんでした。これは、以前の「リンクを開けません」ダイアログの文言（「ローカルファイルを参照している可能性があります」）と一致する結果で、Excel for the webがhttp/https以外の参照先を独自にブロックしているという仮説を裏付けています。

この結果により、当初の目的だった「Web版Excelを操作画面にして、Excel上のリンクを押したら、クラウドPower Automateを使わずにWindows上のPADを起動する」という構成が、実機で成立することが確認できました。

実務上の課題：起動後にフォーカスが中継ページに残ってしまう（自動タブクローズで対応、経過観察中）

起動自体は成功したものの、実際に既存フロー（第9回・第10回で組んだ、フォルダー選択からExcel Onlineへの書き込みまで行うフロー）を最後まで動かすと、新しい問題が見つかりました。

Excelのリンクをクリックすると、ブラウザ上では中継ページ（新しいタブ）にフォーカスが移ります。 「フォルダーの選択ダイアログを表示」までは問題なく動作しますが、その後にExcel Online側のウィンドウを操作しようとする段階（第10回で組んだ、名前ボックスへのジャンプやキーの送信など）になってもフォーカスが中継ページのタブに残ったままで、対象のExcelインスタンスに切り替わりません。第10回までのフローは「操作対象のExcelウィンドウがすでにアクティブ」であることを前提に組まれていたため、この方式特有の新しい制約です。

対応として、中継ページに、ms-powerautomate:への遷移を試みた0.9秒後にwindow.close()を呼ぶ処理を追加しました。 スクリプトで開かれていないタブは閉じられないブラウザが多いため「試みる」だけの対応でしたが、実機ではこの自動タブクローズだけで問題なく動作しています（経過観察中）。

もう1つの対応案「PAD側で対象のExcelウィンドウを明示的にアクティブ化するアクション」も試しましたが、こちらは失敗しました。ウィンドウタイトル指定・UI要素ピッカー・Browserインスタンス変数指定の3通りを試しても「ウィンドウが見つからない」というエラーになります。この現象はデスクトップショートカットからの起動でも同様に発生するため、ブラウザ経由という起動方法固有の話ではなく、実行URL方式でPADのフローをトリガーした場合全般に共通する制約と考えられます。第9回・第10回のフローは、PAD自身が「新しい Chromeを起動する」でブラウザを起動しBrowser変数へ参照を保持する前提でしたが、実行URLでの起動では対象のExcelウィンドウをPADが自分で起動・アタッチしていないため、そもそも参照するウィンドウが存在せず「見つからない」結果になったと考えられます。

この制約を踏まえ、PAD側でのアクティブ化は断念し、運用でカバーする方針に落ち着きました。 起動時点で対象のExcelウィンドウがすでにアクティブな状態を保つか、フォルダー選択ダイアログ（ユーザー操作が必須のタイミング）で選択前に手動でアクティブにしておく、という考え方です。Web版Excelのリンク経由の場合は、前述の自動タブクローズによってすでにこの状態が実現できているため、実用上はこの制約の影響を受けずに済んでいます。

全体の仕組み（設計図）

Web版Excel
  │
  └─ セルのハイパーリンク（＝「Excel上のボタン」の実体、https://の中継ページへ）
        │  ユーザーがクリック
        ▼
   中継ページ（静的HTML、JavaScriptで即リダイレクト）
        │
        ▼
   ms-powerautomate: 実行URL（ローカル完結、クラウドPower Automateなし）
        │
        ▼
   Windows上のPAD（デスクトップフロー）
        │
        ▼
   ローカルファイル操作・Windowsアプリ操作など

クラウド版Power Automateはどの段階にも登場しません。中継ページも静的なHTML1枚であり、クラウドフローではありません。トリガーからPAD起動までが実質的にローカル（ブラウザ→OS→PAD）で完結する設計です。

まとめ

Web版Excelのセルのリンクをクリックして、クラウドPower Automateを使わずにWindows上のPADのフローを起動することに、実機検証で成功した
Office Scriptsには外部URLを開く・ローカルアプリを起動する仕組みがないため、「Excel上のボタンからPADを起動する」の実体は、Office Scriptsのボタンではなくセルのハイパーリンクになる
PAD起動には、Microsoft公式の「実行URL」（ms-powerautomate:）を使用。実行URLの前提条件には「Power Automate Premiumプラン、または従量課金制環境へのアクセス権が必要」と明記されているが、実際のライセンスは「Power Automate for Office 365」＋「Power Automate 無料版」のみでも動作した。ドキュメントの前提条件どおりではないことが実機で確認できた
Web版Excelのセルに直接ms-powerautomate:のリンクを置くと、Excel for the web自身が「リンクを開けません」と表示してブロックする。 OS・ブラウザレベルでは認識できるスキームでも、Excel for the webはhttp/https以外を独自に弾いている
回避策として、https://から始まる中継ページ（静的HTML1枚、JavaScriptで即リダイレクト）を経由させたところ、Excel for the webのブロックを回避でき、PADの起動まで成功した
Windows Home環境でも、デスクトップショートカット・中継ページどちらの経路でも問題なく動作した
生成されたURLのパラメータ名は小文字（environmentid・workflowid）で、ドキュメントにないsource=Shortcutパラメータも自動付与されていた
実際に既存フローを最後まで動かすと、リンククリック後にフォーカスが中継ページ（新しいタブ）に残ったままになり、フォルダー選択後のExcel操作が対象のExcelウィンドウに届かないという課題が見つかった。中継ページにwindow.close()による自動タブクローズを追加したところ、実機で問題なく動作している（経過観察中）

次回予告

起動そのものはできるようになりましたが、これだけでは「毎回同じフローを起動する」ことしかできません。次回は、Excelのセルの値（対象ファイル名やモードなど）を、PADのフロー入力として動的に渡す方法を解説します。ここでも、Excel for the webの意外な制約につまずくことになります。