2026年8月31日をもって Power Automate の iOS および Android 向けのモバイルアプリが廃止されました。Apple ストアや Google Play ストアからアプリを削除しています。

既存のクラウドフローには影響はありません。

しばらく前から Notification コネクターでモバイルへの通知機能が事前通知なく削除されていたんですが、この前触れだったんですね。

[参考]

Important changes (deprecations) coming in Power Platform - Power Platform | Microsoft Learn

この記事は、Microsoft 365 Advent Calendar 2025 に参加しています。※公開が予定より少し遅れてすみません💦

🎄 Microsoft 365 Advent Calendar 2025 - Adventar ⛄

SharePoint のリストやライブラリのURLは、新規作成時にリスト名やライブラリ名を日本語で指定すると、List, List1, List2,  や DocLib, DocLib1, DocLib2,,,, というようなパスを見ても一見よくわからないURLが生成されます。マルチバイトだと対応できないのが原因で、英語だとリスト名やライブラリ名がそのままパスとして利用されます。ですから、URLをわかりやすくしたければ、そもそも最初から英語表記で書いておくのが無難ではあります。

さて、こんな時にパスを、リストやライブラリ作成後に意味のある名称に変えることができるのですが、これには SharePoint のAPIを使う必要があります。PowerShellでも設定できますが、Power Automate を使うほうが慣れている人も多いでしょうから、SharePoint REST APIを使った変更方法をご紹介しましょぅ。

⚠️注意

ちなみに、当然ではありますが、後からURLを変更するとすでにそのURLを告知している人はリンク切れになるので注意してください。

⚙️Power Automate クラウド フローの実装

さて、Power Automate のクラウドフローで例えば、「フローを手動でトリガーする」アクションから始めてみましょう。つづいて SharePointコネクターの 「SharePointにHTTP要求を送信します」アクションを追加します。

このアクションでパラメーターを次のように指定していきます。

パスの指定はリストとライブラリで異なります。

• リスト… Lists/<新しいパス> ※リストは Lists というパスの配下に各リストのが作られる
• ライブラリ…<新しいパス> ※ライブラリはサイトの直下に作られる

あとはフローを保存して、テスト実行してみるとURLパスが変わることが確認できます。

🧪実際に試そう!

たとえば、次のようにリストのURLを変更してみましょう。

変更前

https://officeilearning.sharepoint.com/sites/Training-PowerAutomate-Advanced/Lists/DemoList

変更後

https://officeilearning.sharepoint.com/sites/Training-PowerAutomate-Advanced/Lists/
MerryChristmas

実際の画面の例は次の通りです。

実行後は元のURLにアクセスすると 404 Not Found エラーになります。URLを変更したためそのページは存在しないといわれるのです。

改めて新しいパスにアクセスするとパスが変更されたことが確認できます。

まとめ

SharePoint のリストやライブラリのパスは一度作成したら変更できないと思い込んでいる方も少なくないと思いますが、こうやって比較的手軽に変更できるんですよ。

以上、オンプレミスの SharePoint時代からある REST API の Tips でした。

では皆様、素敵な🎅🏻 Happy Holidays 🎄をお過ごしください。

研修の紹介

弊社では Power Automate の入門者向け研修から、JSONや関数の使い方を体系立てて身に着ける上位研修までご用意しています。Copilot Studio によるAIエージェント構築では、エージェントフローが利用ができるようになっていますが、Power Automate が基盤となっており基礎知識は欠かせません。

体系立てた知識やスキルを身に着けたい方はぜひご受講もご検討ください。

• Microsoft 365 - Power Automate 入門  (初心者向け)
• Microsoft 365 - Power Automate 実践演習 (上位研修)

Power Automate の環境が新しいアーキテクチャーに自動的に移行されます。移行先の環境はSelfHost & Multitenantというもので、エクスプレスモードのような新機能も利用できるようになるとのこと。

Power Automate environments move to new architecture - Power Automate | Microsoft Learn

移行がされたかどうかを確認するには目的の環境にアクセスして、Ctrl+Alt+A を押下します。表示されるデバッグモードの画面からenvironmentFlowHostingType という値を探します。

この値が✅SelfHostMultiTenant だったら新しい環境で、✅LogicAppsだと従来の環境です。

今年の2月ごろ、Power Apps の研修でいつものようにモバイルアプリにカメラ機能を搭載してそこからPower Automate 経由で SharePoint に画像を保存するという演習をやろうとするとうまくいかないというトラブルが。

結果的には、一時的な不具合だったようで現在は修正されていますが、それだけでなく画像の取り扱いの仕様が少し変わったところもあるようなので改めて画像についての取り扱いを整理しておきたいと思います。
※あくまでも2025年7月現在の話であり、今後はまた変更されることもあると思いますのでご注意ください

Power Apps での画像の取り扱い

Power Apps では画像データは Base64形式で保持します。ですから、Power Automate に渡して画像を SharePoint や OneDrive(Business)にファイルとして保存する場合、Base64であることを考慮した処理が必要となります。

さて、Power Apps のカメラコントロールの Photo プロパティでは撮影した画像が直接 Base64でエンコードされます。ラベルなどに Photo プロパティを割り当てると値を簡単に確認できます。

ちなみに、Base64 には次の2つの形式があります。

• Data URI
• プレーン Base64

Data URI は接頭辞に "data:image/png;base64;iVBORw0..." のように実データ以外にファイルの種類などを示す文字列が追加されます。先ほどのカメラコントロールの Photo プロパティは Data URI です。

Power Automate にData URIを渡すと自動的にこの接頭辞は除去されプレーンな Base64 が渡されるようになっています。←これは実は、以前とは仕様が異なっているところ

ちなみに、画像コントロールや画像の追加コントロールに含まれるUploadedImageコントロールのImage プロパティはユーザーが画面に画像を追加すると Data URI ではなく appres://... という形式の値が格納されます。

appres:// で始まるのは Power Apps 内の内部リソース参照となっていて、「埋め込み画像」または「一時参照URI」などと呼ばれたりもします。各形式の意味と用途は次の通りです。

と、ここまでは PC ブラウザー上の話で、Power Apps のモバイルアプリの場合は異なります。埋め込み画像以外のカメラコントロールや画像の追加コントロールの画像は格納先のパスが表示され、それぞれ "/SessionStorage/" 配下に格納されているのがわかります。

冒頭でご紹介したトラブルは、このモバイルアプリを使っているときに本来だと参照しているリソースから実データであるBase64をフローに渡すべきところが、参照リソースのパスのみが渡されてしまい実際にファイルとしてデータを渡すことができないという現象でした。現在は参照元からBase64でエンコードされた画像データがきちんと渡されるようになっています。

Power Automate との連携

Power Automate のクラウドフローに画像を渡す場合は、 Power Apps V2 コネクターのトリガーの引数として「ファイル」を追加しておきます。

このパラメーターは、コードビューで確認すると次のように contentBytes と name の2つのパラメーターを必要とすることがわかります。

Power Apps 側ではカメラコントロールで撮影した画像をプレビューするために画像コントロールのImageプロパティに割り当てることがよくあります。そのため、この場合の画像コントロールの Image プロパティにはData URIの Base 64 が格納されます。

そしてこのImageプロパティを Power Automate のフローに渡す場合は次のようにcontentBytes と name を指定します。

ところで、画像の拡張子はカメラコントロールのPhotoプロパティから取得する場合は PNG形式ですが、その他の画像形式などもあり得ます。汎用的に拡張子を判定するためには次のように式を構成することも可能です。これをフローの呼び出し時などに使うといいでしょう。

//PCブラウザーかモバイル化の判定
Set(_IsMobile,If(Host.OSType="Android" || Host.OSType="iOS",true,false));

//Base64の先頭からmime typeを抽出する
Set(_mimeType,
//PCブラウザーの場合
If(!_IsMobile,Mid(Camera1.Photo,6,Find(";",Camera1.Photo)-6),
//モバイルの場合
Right(Camera1.Photo,4)
));

//ファイルの拡張子を決める
Set(_fileExtension,
    If(_IsMobile,
        _mimeType,
        Switch(_mimeType,
            "image/jpeg", ".jpg",
            "image/png", ".png",
            "image/gif", ".gif",
            "image/bmp", ".bmp",
            // Default case (optional)
            Blank()
        )
    )
);

さて、先述した通りPower Automateに送信するときにはData URI(data:image/xxx;base64,) のヘッダー部分を自動的に除去し、contentBytes にはプレーンBase64のみが格納されます。実際のフローの実行結果からもcontentBytesのフィールドで確認できます。

そのため、SharePoint にファイルを保存する場合は、SharePoint コネクターの「ファイルの作成」アクションのファイルコンテンツ プロパティでは base64ToBinary 関数を使い、次のように式を指定します。以上で SharePoint に画像をファイルとして保存することができます。

base64ToBinary(triggerBody()?['file']?['contentBytes'])

従来からの仕様変更の注意点

長らく(昨年の2024年のおそらく後半までは) Power Apps のカメラコントロールから Power Automate に渡した画像はData Uri 形式であったため、Power Automate 側で画像を受け取った後は dataUriToBinary() を使っていました。ですが、内部的な使用変更があったようでプレーンなBase64が渡されるようになっているため base64ToBinary() を使う必要があるので注意しましょう。

クラウドフローのトリガーにはプッシュトリガーとポーリングトリガーがあることをご存じの方も多いと思います。今回はこのポーリングトリガーがモダンデザイナーとクラシックデザイナーを使う場合とで違いがあるという話です。

が、トリガーの種類を知らない方もいるでしょうから、少し整理しておきましょう。

軽くおさらい

プッシュトリガーは、人の手で直接フローを開始するのでフローの開始のタイミングがはっきりしています。こうしたフローは即時実行されます。Forms コネクターのトリガはブッシュトリガーです。

一方のポーリングトリガーは、「ファイルが更新されたとき」や「アイテムが追加されたとき」など、人の手で直接はフローを開始しないタイプのトリガーです。Power Automate のフローは、これらのトリガーが利用されている場合、指定されたライブラリやリストを定期的にチェックし、変更が見つかったときにフローを開始します。

ポーリングトリガーはもともと実行間隔がライセンスによって違っていました。

クラシックデザイナーとモダンデザイナーでの挙動の違い

モダンデザイナーで自動開始のトリガーを利用する場合は、ポーリングトリガータイプのものはユーザーのライセンスに関わらず、既定では実行間隔が1分になっています。たとえば、SharePoint コネクターの「項目が作成されたとき」のトリガーを確認してみると、次の通り1分です。

ですが、クラシックデザイナーの場合は最初からクラシックデザイナーに切り替えて、同じトリガーを配置してみるとコードビュー上では interval が5分となっているのがわかります。ちなみに、プレミアムプランを持っているユーザーが作成するとクラシックでも1分です。

つまり、プレミアムライセンスを持たないユーザーは、モダンデザイナーを使ってフローを作った方が実行が早まるということです。

ということで実験してみました。同じリストに対して2つのフローを作成します。どちらも「項目が作成されたら」フローが動作するようにトリガーをしかけて、メールを送信します。違うのは最初からモダンデザイナーで作成しているのか、クラシックデザイナーで作成しているのかです。

アイテムを新規に追加してみます。すると、先に動いたのはやはりモダンデザイナーで作成した方で、アイテム作成日時とメールの受信日時を比較してみると確かに1分ほどになっています。

しばらくするとクラッシクデザイナーで作成したフローが動きメールが送信されます。メールの受信日時を見るとおよそ5分違います。

ちなみに、このブログではモダンデザイナーと呼んでいますが、Microsoft Learn をもとにすると単に「クラウドフロー デザイナー」と呼んでいて、古いデザイナーを「クラッシク デザイナー」と呼んで区別しています。※新しいデザイナー画面になったときには、最新のものを便宜的にモダンデザイナーと呼んでいたようです。

将来的にはこのモダンデザイナーのみになる予定で、クラシックデザイナーは廃止される予定ですが、現時点(2024年2月13日に確認している時点)ではすべての機能が移管しきれていないので、もうしばらくはクラシックデザイナーが残りそうです。