序
SharePoint リストの「通知」機能（従来のアラート）に廃止の動きが示される中、従来は「設定して終わり」で済んでいた更新通知を、別の形で担保する必要が出てきました。
一方、アラートの代替案は要件に応じて最適解が大きく変わってきます。とりあえず通知だけが来ればいい場合は SharePoint ルール を活用すれば問題ありません。ノーコード（主にマウス操作と値の入力）で実装可能です。
しかし、特定の列が空の場合は通知しなくても良い場合であったり、特定のステータスに変わった時だけ通知したい場合であったりした時、Power Automate を活用する場面が今後増えていくと予想しています。
基本的には、上に引いた動画や以下のサンプルのように、単に「アイテムが作成または変更されたとき」トリガーでメールを飛ばすだけで問題ないと考えています。もちろん、このトリガーに条件を加えることも可能です（参考記事）
本記事では、より拡張したフローとして、過去値（変更前データ）の取得、通知対象項目の絞り込み、バージョン情報の扱い、アイテムへの直リンク生成、そして「新規登録」と「更新」でメール内容を出し分ける方法を扱います。
通知のみに留める実装ではなく、通知があった後のアクションをシステム化する方が大切だと考えています。この辺り、業務内容次第で議論の余地がありそうですが、急な変化に戸惑う人は決して少ないと考えたので記事化しています。
0. SharePoint アラートの代替案（2026年1月5日追記分）
アラート廃止への対応としては、概ね次の選択肢があります。先に「自分がどこまで必要か」を決めると、作るべきものが定まるかと思います。
0.1. SharePoint ルール
アラート機能の代替案は、SharePoint ルール を活用した通知機能の実装です。しかし、１つのリスト（ライブラリ）につき、15個までという制限があったり、設定に使用できる列の種類も限定されていたりするため、その場合は、Power Automate を活用して拡張した通知フローの実装が求められます。委細は以下の記事をご覧ください。
0.2. Power Automate を活用した通知フロー
ルールより柔軟に「この列が空なら通知しない」であったり「特定の状態に変わった時だけ通知する」であったり等を実現できます。
ただし、この段階では「通知する／しない」の制御が主であり、変更前後の差分そのものまで整形して通知するには追加設計が必要になります（※本記事の対象者です）
1. フロー概要
今回作成するフローの全体図です。トリガーには 「アイテムが作成または変更されたとき」 を設定し、対象のリストを接続しておきます。以下、順を追って説明していきます。
2. 過去のデータも遡って取得する
2.1. SharePoint に HTTP 要求を送信する
まず、更新されたデータだけでなく、過去のデータも取得するために 「SharePoint に HTTP 要求を送信します」 アクションを配置します。配置したら、次の画像を参考に設定を行います（※ URI は、各自のリスト名に読み替えて設定してください）
getbytitle('') には、リスト名を、items('') には、トリガーで得られた動的なコンテンツの中から ID を選択して配置します。
_api/web/lists/getbytitle('リスト名')/items('アイテムID')/versions
このアクションを活用して得られたデータは JSON という一種の「配列」の形式で戻って来ます。配列とは、表形式でまとめられたデータのことです。委細は以下の記事をご覧ください。
こちらのアクションの設定が完了したら、一度、フローをテスト実行し、実行結果をメモ帳やテキストエディタに控えておくと便利です。
3. 通知したい項目を抽出する
「SharePoint に HTTP 要求を送信します」アクションで得られた JSON から必要な情報を取得する手順です。ここでは「選択」アクションを配置し、過去のデータの中から欲しい情報だけを取得します。この時、選択アクションの名前を「選択：通知内容抽出」に変更しておきます。
後続アクションに影響するので、名前の変更は忘れないようにしておきましょう
3.1. 開始 の設定
先ほど「SharePoint に HTTP 要求を送信する」を実行して控えておいたデータの中から、自分の欲しい情報が含まれている箇所を指定し、１つの「アレイ」の形に整えていきます。
控えておいた JSON を確認すると、欲しい情報は "d" → "results" と辿ることで得られます。したがって、選択アクションの「開始」には、次の数式を入力します。
body('SharePoint_に_HTTP_要求を送信します')['d']?['results']
body() は、( ) で括ったアクションの実行結果から "body": {...} に該当する部分だけを抽出する関数なので、本来であれば body → d → results という手順を踏んで情報を取得する必要があるのを、d → results という手順で情報を得られるようになります。
なお、数式を入力するので、以下の画像のように、数式を入力する場所に設定を加えます。
3.2. マップ の設定
「マップ」の設定が今回の鬼門です。左側の枠は、データテーブルでいう「列名」に該当する箇所なので、自由に文字を入力して大丈夫です（が、分かりやすいようにリストと同じようにしておくと良いです）
右側の枠には、先ほど取得したリストのデータ（内容）を取得する数式を入力していきます。自分自身を参照するための item() を使用します。数式を入力するタブに切り替えて、上から順に、次のように設定しています（階段を降りていくようにして JSON データをゆっくりと眺め、数式を書いていきます：参考記事）
item()['VersionLabel']
item()['Editor']?['LookupValue']
item()['Editor']?['Email']
item()['Author']?['LookupValue']
item()['Author']?['Email']
item()['Code']
item()['Merchandise']
item()['Volume']
今回は、商品マスタに新しいデータが登録されたり、登録内容に変更があったりした時に通知することを想定しているので、製品コード、商品名、生産数といった情報を取ってきています。読者の皆さまと異なる部分はココだけです。リストの内部列名を ['ここに入力'] すれば OK です。
4. バージョン情報を抽出する
今度は、SharePoint の更新があった時のバージョン（何回目の更新か）を確認できるようにする設定を施します。この設定は、データが新規登録なのか更新なのかを後続アクションで判断するための材料となります。
作成アクションを配置し、名前を「作成：バージョン抽出」に変更したら、次の数式を入力します。直前の選択アクションから最新のバージョン情報を取得できます。
first(body('選択：通知内容抽出'))['バージョン']
SharePoint リストのバージョンは、新規登録であれば、1.0、更新があれば都度 2.0、3.0...と、値が増えていきます。つまり、1.0 であれば新規登録、それ以外なら更新…という分岐を設定できるようになります。
5. リストへの URL を作成する
登録・更新のあったデータにすぐアクセスできるように、SharePoint リストへの URL もあらかじめ作成しておきます。メール本文にリンクを設定する場合、直接、動的なコンテンツとして「アイテムへのリンク」を入力しても安定しない傾向があるので、作成アクションを挟んでいます。
なお、今回は「アイテムへのリンク」を２つ入れていますが、アンカーテキスト（＝URL化された文字列）を設定することも可能です。「確認する」や「アイテムへのリンク」といったように、好きな文字列を置くことも可能です。
<a href="アイテムへのリンク">アンカーテキスト</a>
6. 条件分岐
あとは、条件に応じたメール通知を残すのみです。条件アクションを配置し、左辺には抽出したバージョン情報を動的なコンテンツとして入力します。
右辺には、バージョン情報を入力すれば良いのですが、普通に 1.0 と入力すると数値データとして扱われてしまい適切に分岐しないため、文字列型にデータ型を変更する必要があります（バージョン抽出の段階で数値化してもOKでしょうね）
string('1.0')
7. 新規登録の場合のメール設定
新規登録時は、トリガーで得られた情報をそのまま動的なコンテンツとして設定します。以下の画像を参考にしてもらえるとほぼ大丈夫です。
一点、懸念すべき点があるとすると、添付ファイルや複数選択可のユーザー列の情報をメール本文に添付する場合かもしれません。この場合は、Apply to each（繰り返し処理）が自動的に入ってきます。
つまり、SharePoint リストに登録されたユーザーの数だけ、添付ファイルの数だけメールが送信されることになります。この場合の回避策としては、first 関数や、選択 / 結合アクションを組み合わせた文字列化をしていくことなどが挙げられます。委細は、以下の記事をご一読ください。
8. 更新の場合のメール設定
最後に、更新があった場合のメール設定で作業完了です。
単純に、更新後のデータが閲覧できるだけでなく、何のデータが誰によって変更されたのかといった「差分」が知りたいという問い合わせも想定して、変更前のデータもメール本文に掲載する準備を行います。
8.1. 更新の直前のデータも知りたい
作成アクションを配置し、名称を「作成：変更前のデータ」と改めます。その後、次の数式を入力し、最新データの１つ前（＝２行目）のデータを取得します。
body('選択：通知内容抽出')[1]
HTTP リクエストによって、過去のデータも含めた全ての履歴が取得されいるため、２行目のデータが更新直前のデータとなっています。Power Automate は１行目のデータを [0]、２行目のデータを [1] で表現するためこのように数式を入力します。
body('選択：通知内容抽出')[0]
first(body('選択：通知内容抽出'))
余談ながら、最新のバージョンを取得する際、first() ではなく、上のように [0] を指定することでも同様の設定となります。お好きな方で設定すると良いでしょう。
8.2. 更新通知メールの設定
最後に、取得した更新前のデータと更新後のデータをメール本文に記載していきます。更新後のデータに関しては 「7. 新規登録の場合のメール設定」 と同様に、トリガーで取得してきた動的なコンテンツを配置するのみです。
しかし、更新直前のデータの取得方法ですが、先ほど設定した「作成：変更前のデータ」は、オブジェクト型（データ行）なので、そのまま動的なコンテンツの「出力」を配置しても上手くメール本文に掲載できない問題が生じます。そのため、以下の数式を各項目分入力する必要があります。
上に引いた画像では、変更前の「商品名」をメール本文に記載する方法を紹介しています。
outputs('作成：変更前のデータ')['商品名']
一応、スキーマ化しておくと以下のとおりです。なお、['列名'] には、選択アクションで抽出した時に自分で設定した列名である点に要注意です。
outputs('作成：変更前のデータ')['列名']
こういった設定を今回は以下の箇所に施しています。
以上で作業完了です。お疲れさまでした。
結
当フローの実装には、JSON への理解が進んでいないと難しいため、記事を公開するかどうか相当悩みましたが、通知機能の廃止に戸惑う声が多く寄せられたことから公開いたしました。
できればコピー＆ペーストで実装するのではなく「なぜ」を大切にして、フローの内容を熟知した上で運用していただけると幸いです。
また、冒頭でも述べましたが、通知のみに留めるのではなく、通知があった後のアクションをシステム化する方が大切です。この点にまで目を届かせられるようになると、本当の意味での業務効率化に繋がってくると考えています。
本稿が、アラート廃止の穴埋めとしてではなく、運用設計の一部として通知フローを整備することに繋がり、関係者の安心感を支えられるものとなれば幸いです。