Power Apps/Power Automate for Office 365 で できる SharePoint リストを使ったアプリの構築 2020/12/8 篠原 敬志 (@karamem0)

自己紹介 Name 篠原 敬志 (Takashi Shinohara) Company アバナード株式会社 シニアコンサルタント Award Microsoft MVP for Office Development (2018-) Twitter @karamem0 Facebook t.shinohara.56 LinkedIn tshino56 Blog https://blog.karamem0.jp Community Japan M365 Dev User Group

本日のゴール システム開発として Power Platform を採用するときに、Power Apps/Power Automate for Office 365 を使うこと「何ができるのか」「何ができないのか」 を理解し、アーキテクチャを決定するときの見極めの一助となればと思います。

最近よく言われること Microsoft 365 と Power Platform を使ってお客 様にシステムを導入したい！ノーコード・ローコー ドで工数を削減したい！ やりましょう！ じゃあまず Power Platform のライセンスを買って もらってください！ いや、ライセンス買ってもらうのはちょっと… タダでできないの？

最近とても言いたいこと Power Platform のライセンスを買え。 話はそれからだ。

とはいえ お客様にライセンスを買ってもらうのってハードルが高い 契約外のところになるので提案しづらい 固定費で費用が発生するということに対する不安がある システム開発を依頼する部署とライセンスを管理する部署が異なる お金の出どころが違うと調整が面倒 システム開発費用に対してライセンス費用が高い (ように見える) 100 ユーザーに 5 人月のシステムを使ってもらうとして (耐用年数 5 年) システム開発: ¥1,000,000 x 5 (人) = ¥5,000,000 ライセンス: ¥5,980 x 100 (人) x 12 (ヶ月) x 5 (年) = ¥35,880,000 Power Apps/Power Automate for Office 365 の範囲でもある程度はなんと かできてしまう

結局のところ タダでやりましょう！ (血涙)

Power Apps/Power Automate for Office 365 Power Apps/Power Automate は単体としてライセンス販売されている製品です。 ただし、Microsoft 365/Office 365 のライセンスがあるユーザーに対しては、 Office 365 製品に接続するアプリ/フローを作成または実行することが可能になり ます。

Power Apps/Power Automate のプラン比較 Power Apps Power Automate プラン名 for Office 365 per apps plan per user plan for Office 365 per flow plan per user plan 価格 ¥0 ¥1,090 /ユーザー/月 ¥4,350 /ユーザー/月 ¥0 ¥54,350 /月 ¥1,630 /ユーザー/月 アプリ/フロー数 無制限 2 無制限 無制限 5 無制限 Dataverse ○ ○ ○ ○ 標準コネクタ ○ ○ ○ ○ ○ ○ プレミアム コネクタ ○ ○ ○ ○ カスタム コネクタ ○ ○ ○ ○ 環境の作成 ○ ○ ○ ○ API コール回数 2,000 回 /ユーザー 1,000 回 /ユーザーパス 5,000 回 /ユーザー 2,000 回 /ユーザー 15,000 回 /フロー 5,000 回 /ユーザー 2020/12/8 時点の情報です。最新の情報は公式の URL を確認してください。 https://powerapps.microsoft.com/ja-jp/pricing/ https://japan.flow.microsoft.com/ja-jp/pricing/

Power Apps/Power Automate のアーキテクチャ プレゼンテーション ビジネス ロジック データ ストア

Power Apps + SharePoint における 2 つの問題 500 件問題 5,000 件問題 Power Apps から SharePoint への操作には "委任" できない関数があり、そのような関数を使った場合に 500 件までしか取得することができません。 しきい値は 2,000 件まで上げることができるので、 リスト アイテムがその範囲で収まることが予想される 場合には有効な対応方法となります。それ以外の場合 は "委任" できない関数を使用しないことでしか回避 できません。 SharePoint のリスト アイテムが 5,000 件を超える 場合に並べ替えやフィルターをするとエラーが発生し ます。 並べ替えやフィルターをする列に対してインデックス を貼ることが有効な対応方法となります。リスト アイ テムが 20,000 件までの場合はインデックスの自動管 理によってインデックスが作成されるため対応が不要 な場合があります。

Power Apps の委任について 委任できる場合 委任できない場合 委任できる操作の場合、データ ソース 側で実行され、クライアントにはその結 果が返却されます。 委任できない操作の場合、データ ソー スはすべてのデータを返却し、クライア ントで実行されます。

SharePoint で委任可能な関数と演算子 関数/演算子 数値 テキスト 真偽値 日付 複合型 Filter ○ ○ ○ ○ ○ Sort ○ ○ ○ ○ SortByColumns ○ ○ ○ ○ Lookup ○ ○ ○ ○ ○ = ○ ○ ○ ○ ○ <, <=, <>, >, >= ○ ○ ○ StartsWith ○ ○ 以下の関数が委任 "できません" Search 関数 in 句/EndsWith 関数 Sum/Average/Min/Max などの集計関数

複合型での委任の制約 参照列は Value のみ委任できます。ID では委任できません。 ユーザーまたはグループ列は Email または DisplayName のみ委任できます。 複数選択可能な選択肢列/参照列/ユーザーまたはグループ列を委任することはでき ません。

参照列を使った他リストの参照 1:N (単一の参照列) N:N (複数選択可能な参照列) 子から親への参照 〇 ID から LookUp で参照可能 〇 ID から LookUp で参照可能 親から子への参照 △ Value でフィルターが可能 ✕ 委任なしでのフィルターは不可能

参照列は使ったほうがいい？ 参照列の Value は一意であるべきですが一意であることは保証されません。ID が 委任できない以上、Value をキーにするのはリスクがあります。Power Apps を UI として使うのであれば、参照列を使わないことをお勧めします。 ただし、ID を数値で格納してしまうと、参照関係を追うのが難しくなってしまう ため、SharePoint の標準の UI も合わせて使うときなど、参照列にしたほうがい い場合もあります。また、データ移行をする必要がある場合も、参照関係の扱いに は注意が必要です。 リストに定義できる参照列/ユーザーまたはグループ列は 12 が上限です。うち 2 はシステムで使用しているため、ユーザーが追加できるのは 10 までになります。

Power Apps での 5,000 件問題 SharePoint REST API では、インデックスを作成した列でも、結果が 5,000 件 を超えるとエラーになるという制限があります。ただし Power Apps は SharePoint REST API を使用していないため、そのような問題は発生しません。 SharePoint に設定できるインデックスの数は最大 20 個です。インデックスを設 定できる列の種類にも制限があるため注意が必要です。

SharePoint でインデックスを作成できる列 インデックスを作成できる列 インデックスを作成できない列 1 行テキスト 複数行テキスト 選択肢 選択肢（複数選択） 数値 集計値 通貨 ハイパーリンクまたは画像 日付と時刻 ユーザーまたはグループ（複数選択） ユーザーまたはグループ 外部データ 管理されたメタデータ カスタム列 はい/いいえ 参照

DEMO SharePoint リストを使った Power Apps アプリ サンプル

Power Automate の SharePoint コネクタ Power Automate の SharePoint コネクタは用意されているものだけでも多くの 作業を行うことができます。アクションが用意されていない場合でも "SharePoint に HTTP 要求を送信します" を使って SharePoint REST API を実行できます。 13 トリガー 47 アクション

Power Automate + SharePoint における問題 Power Apps から Power Automate を呼び出す場合、アクションは Power Apps を実行しているアカウントで実行されます。そのため、いわゆる "権限の昇格" を 行うことができません。 有償プランであれば汎用の HTTP アクションを使ってアプリケーションのアクセ ス許可で SharePoint REST API を呼び出すという回避策が取れます。しかし Office 365 のプランでは HTTP アクションを使用できません。

Power Apps と Power Automate を分離する SharePoint の "アイテムが作成または変更されたとき" のトリガーを使用すること で、Power Apps と Power Automate の実行ユーザーを分けることができます。 トリガーの条件を指定することで、任意の値が設定されたときのみに Power Automate を実行することが可能です。

Power Automate の API 要求の制限について Power Automate はユーザーが 24 時間以内に実行できる API 要求の数に制限が あります。Office 365 の場合は 2,000 が上限です。 API 要求としてカウントされるのは以下の操作です。 コネクタへのすべての API リクエスト HTTP アクション 変数の初期化や合成などの組み込みアクション ただし制限を超えたからすぐにブロックされるわけではありません。また超過して いるかどうかを確認する方法は現時点では提供されていません。(まだ？) SharePoint コネクタには 60 秒間に 600 回までという制限があります。

まとめ あれ？意外にいろいろできちゃうんじゃない？

だが待ってほしい いわゆる市民開発者として社内のアプリを作る程度であれば Power Apps/Power Automate/SharePoint の組み合わせは十分に使えます。しかしシステム開発とし て顧客にアプリを提供するには機能以外にも考えることがたくさんあります。 アプリの開発方法 アプリのテスト方法 アプリの運用方法 全体として本当にそれが最適解なのか？ということを考えてほしいと思います。

ご清聴ありがとうございました。 質問はありますか？