この記事は、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日に確認している時点)ではすべての機能が移管しきれていないので、もうしばらくはクラシックデザイナーが残りそうです。

トラブルの原因や発生条件はわからないのですが、とりあえず、Power Platform 環境で起きたトラブルシューティングの顛末を記録しておきます。

----------------------------------

弊社ではPower Apps の研修を定期的にしているのですけれど、受講者の方には最近は専用の開発者環境を事前に作成しておいてそこでアプリ作成をしてもらうようにしています。

そのため、研修の度にリセットして利用しています。

いつものように昨日の午前中に受講者用の環境をリセットしたわけです。で、今日はその環境でアプリ作成をあれこれとしてもらうことにしました。

まず起きたのが午前中にそれぞれに作成した開発者環境が環境の切り替えに現れなくなったというもの。それぞれの開発者環境でのアプリ開発をする前に、たまたま、新機能のキャンバスアプリの同時編集を試していました。その直後だったので、それが何かしら影響しているのかも知れない気もしなくもありません。同時編集のリンクにアクセスしようと、全員が何かしらアクセスできないエラーが起きていたためです。しかも、各アカウントに私のPC上からアクセスすると環境切り替えに目的の環境は出てきていました。そうなると各PC側の問題かと考えます。受講者の方々のPC側の問題かも? ととりあえず、キャッシュクリアをお願いしたのですが状況は改善せず。

今考えると、トラブルの最初はここだったような気がします。

仕方がないので、テナントの管理者である私のアカウントであれば全員の開発者環境はアクセスできるため、各環境のURLをそれぞれに渡して、直接環境へのリンクにアクセスしてもらいました。まずはこれで問題なくアプリが作れるようになったのです。

しかし、午後過ぎに突然、アプリが作成できなくなりました。リセットしていない他の環境では起きなかったので、共通項としては「開発者環境」&「最近リセットした」くらいなんですね。あっ、そういえば、もう一つ、リセットしていないけれど昨日新規に作成した開発環境でも同じ現象が発生していました。

キャンパスアプリを作成しようとすると下記のようにエラーが表示されるのです。

つい、さきほどまで作成できていましたし、だれも何も設定変更などしていないので、これは明らかにおかしい。ちなみに、こうなると既存のアプリも編集できないし、エクスポートもできません。

ということで、まずは問題が起きているユーザーアカウントに切り替えて、Power Platform 管理センターにアクセスするのですが、本来、ユーザー自身が環境管理者となっているはずの「開発者環境」がそもそも全く表示されません。表示されているのは唯一、既定の環境のみ。

仕方がないので、またまたPower Platform管理者である私が Power Platform 管理センターから問題の生じている各開発者環境にアクセスします。すると環境ハブにはアクセスできるのですが、アクセス権限に問題が生じているのだろうと「設定」画面やセキュリティロール画面にアクセスしようとすると、次のエラーが表示されてしまい何もできなくなってしまう。

「RetrievePriviledgeForUser: The user id xxxxx-xxxxx-xxxxx has not been assined any roles. They need a role with the prvReadOrganization priviledge. ～」

まぁ、権限がないということなんですが、私がテナント管理者だしPower Platform 管理者だし、これ以上誰も特権は持っていないわけです。さてさて、、、セキュリティ情報がどこか壊れた? 

と、途方に暮れかけていたのですが、一つだけ利用できる設定がありました! 環境ハブのコマンドバーにある「メンバーシップ」メニューです。これが開ける! が、

「現在、管理者を表示できません。再試行する前に[自分を追加する]をクリックして、システム管理者ロールに自分のアカウントを追加してください」

と表示されます。ということで急ぎ、「自分を追加する」をクリックすると自分自身ともともと指定していたユーザーも自動的に追加されました! 

これでどうやら復活した模様。無事に設定画面にもアクセスできるようになり、アプリの作成、編集、エクスポートもできるように。また、各ユーザーアカウントからも Power Platform 管理センター上の「環境」に各管理者となっている環境も現れるようになりました。

原因は全く持って不明ですが、今後、もし似たような問題に直面することがあれば、自分を含めほかの方にも対処療法として知っておくとよいかなと思ったので、ここに書き留めておくことにしました。

ご参考まで。

p.s. ちなみに、アプリが突如作成できなくなった時には、とりあえず問題の起きていない環境もしくは受講者それぞれの組織のテナントでアプリ作成をしてもらい、研修後にあらためて(落ち着いて) 環境の確認をしていたところ、上記の「メンバーシップ」の追加での修正にたどりつきました。

p.s. おいしみ（@ksgiksg）さん / X)さんからの追加情報で、「メンバーシップ」の追加に関しては↓が関係しているのではということでした。

PowerPlatform管理者が環境の管理者に自動割り当てされなくなった #Microsoft - Qiita

確かに、管理者が環境の設定にアクセスできなかったのはこれのようですね。ですが、解せないのはこれを追加することで、環境の管理者として設定していたユーザーがこれまで通り、環境にアクセスできるようになったということですね。管理者の私はともかく、ユーザーは直接関係ないはずで。うーん、たぶん小さいバグでも踏んだ気がします。。。ですが、おいしみさん、この情報はちゃんと読んでいなかったので、情報提供をありがとうございました!!!