はじめに
今回は、Power Automateを使用して、SharePointリストのステータス変更履歴を別のSharePointリストへ自動保存する仕組みを検証しました。
今回の検証では、単純に「アイテムが更新されたら履歴を残す」のではなく、ステータス列が実際に変更された場合だけ処理を行い、変更前と変更後のステータスを履歴として保存することを目標としました。
SharePointには標準でバージョン履歴を保存する機能があります。しかし、ステータス以外の列を変更した場合にもバージョンが増加するため、バージョン履歴をそのまま利用するだけでは、必要なステータス変更履歴を正確に扱いにくい場合があります。
そこで今回は、
- Power AutomateによるSharePointリストの更新検知
- 変更された列の判定
- SharePoint REST APIによるバージョン履歴取得
- JSONから変更前ステータスを取得
- 別のSharePointリストへの履歴保存
を組み合わせて検証しました。
なぜこの検証を始めたのか
今回の検証は、Power Platformを活用した業務自動化の技術検証の一環として実施しました。
要件は、SharePointリストのステータス列が変更された際、その履歴を取得し、別のリストへ保存する仕組みを検証するというものです。
たとえば、備品管理リストでPCの状態を管理している場合、
- 利用可
- 貸出中
- 停止中
のようにステータスが変化します。
現在のステータスだけを確認するのであれば、元のSharePointリストだけで問題ありません。
しかし、
「いつ利用可から貸出中になったのか」
「その前はどのステータスだったのか」
「ステータスがどのように変化してきたのか」
といった情報を後から確認したい場合には、変更履歴を別途保存しておくと扱いやすくなります。
特に今回重要だったのが、変更後の値だけではなく、変更前の値も取得することです。
今回実現したいこと
今回目指した処理は、次のような流れです。
- SharePointリストのアイテムが更新される
- 今回の更新でステータス列が変更されたか確認する
- ステータスが変更された場合のみ後続処理を実行する
- 対象アイテムのバージョン履歴を取得する
- 1つ前のバージョンから変更前ステータスを取得する
- 現在のステータスを変更後ステータスとして取得する
- 変更前・変更後のステータスを履歴保存用リストへ追加する
最終的には、履歴保存用リストへ次のような情報が追加される状態を目指しました。
| 項目 | 例 |
|---|---|
| タイトル | PC001 |
| 元アイテムID | 1 |
| 変更前ステータス | 貸出中 |
| 変更後ステータス | 停止中 |
| 変更日時 | 2026/08/26 |
| 変更者 | ○○ ○○ |
2. 検証環境とSharePointリストの準備
今回は、動作確認をしやすくするために検証専用のSharePointリストを作成しました。
用意したのは、
- 元データを管理するリスト
- 変更履歴を保存するリスト
の2つです。
元データ用リスト
元データ用のリストには、以下の列を作成しました。
- タイトル
- ステータス
- 利用者
- 場所
- メモ
ステータス列は「選択肢」として作成し、
- 利用可
- 貸出中
- 停止中
などの値を設定しました。
また、Power Automateの動作を確認するため、
- PC001
- PC002
- PC003
といったダミーデータを作成しました。
たとえば以下のような状態です。
| タイトル | ステータス | 利用者 | 場所 | メモ |
| PC001 | 利用可 | A | 東京 | 検証用 |
| PC002 | 貸出中 | B | 千葉 | 検証用 |
| PC003 | 停止中 | C | 東京 | 検証用 |
このリストのステータスを実際に変更しながら、Power Automateがどのように動作するか確認しました。
履歴保存用リスト
次に、変更履歴を保存するための別リストを作成しました。
主な列は以下です。
- タイトル
- 元アイテムID
- 変更前ステータス
- 変更後ステータス
- 変更日時
- 変更者
Power Automateがステータス変更を検知すると、この履歴保存用リストへ新しいアイテムを作成します。
元データ用リストは「現在の状態」を保持し、履歴保存用リストは「過去の変化」を蓄積する役割になります。
3. Power Automateフローの全体構成
今回作成したPower Automateのフローは、以下のような構成です。
アイテムが作成または変更されたとき
↓
アイテムやファイルの変更を取得する
（プロパティのみ）
↓
条件：ステータス列が変更されたか
↓
True
↓
SharePointにHTTP要求を送信
↓
作成①：1つ前のバージョンを取得
↓
作成②：変更前ステータスを取得
↓
項目の作成
↓
履歴保存用リストへ追加フローを考える際には、
- いつ処理を開始するのか
- 何を調べるのか
- どの条件で処理を続けるのか
- 最後に何をするのか
という順番で考えると整理しやすくなります。
今回であれば、
いつ？
→ SharePointのアイテムが更新されたとき
何を調べる？
→ どの列が変更されたのか
条件は？
→ ステータス列が変更されたか
何をする？
→ 変更前後のステータスを履歴リストへ保存という構成です。
アイテムの変更をトリガーにする
最初のトリガーには、SharePointの
「アイテムが作成または変更されたとき」
を使用しました。
これにより、対象のSharePointリストでアイテムが作成または更新されると、自動的にフローが開始されます。
ただし、このトリガーだけでは、
- ステータスを変更した
- 場所を変更した
- メモを変更した
といった違いまでは判断できません。
いずれの場合でも「アイテムが更新された」としてフローが開始されます。
今回保存したいのはステータスの変更履歴のみなので、次の処理で「何が変更されたのか」を確認します。
ステータス列が変更されたか確認する
次に、
「アイテムやファイルの変更を取得する（プロパティのみ）」
を使用しました。
このアクションを使用すると、今回の更新で各列が変更されたかどうかを確認できます。
その結果を利用して、条件アクションで、
ステータス列が変更された = trueかどうかを判定します。
ステータスが変更されていればTrue側へ進みます。
一方で、
- メモだけ変更した
- 場所だけ変更した
- 利用者だけ変更した
といった場合にはFalse側へ進み、その後の処理を実行しません。
この条件を入れることで、不要な更新までステータス変更履歴として保存されることを防げます。
4. 変更前ステータスを取得する仕組み
今回の検証で最も重要だったのが、変更前ステータスを取得する処理です。
Power Automateから現在のSharePointアイテムを取得すること自体は比較的簡単です。
しかし、アイテムがすでに更新された後では、通常の「項目の取得」を使用しても変更後の現在値しか取得できません。
たとえば、
利用可
↓
貸出中へ変更
↓
Power Automate起動という場合、Power Automateがアイテムを取得する時点では、すでに現在値は「貸出中」です。
そこで、変更前の「利用可」を取得するためにSharePointのバージョン履歴を利用しました。
SharePointのバージョン履歴をHTTPで取得する
今回はPower Automateの
「SharePoint に HTTP 要求を送信します」
を使用しました。
HTTPを利用することで、Power Automateに標準で用意されているアクションだけでは取得しにくいSharePointの情報を、REST APIから取得できます。
今回使用したメソッドはGETです。
GETは、
「データを取得する」
ためのHTTPメソッドです。
URIは以下のような構造にしました。
_api/web/lists/GetByTitle('対象リスト名')/items(アイテムID)/versionsそれぞれ、
_api
→ SharePointのAPIを利用する
/web/lists
→ サイト内のリストを対象にする
/GetByTitle('対象リスト名')
→ 対象リストを指定する
/items(アイテムID)
→ 対象のアイテムを指定する
/versions
→ そのアイテムのバージョン履歴を取得するという意味です。
アイテムIDには固定値ではなく、トリガーから取得した動的コンテンツのIDを使用します。
たとえば実行対象のIDが1であれば、実行時には以下のようなURIになります。
_api/web/lists/GetByTitle('PowerAutomate_ステータス変更検証')/items(1)/versionsこれによって、対象アイテムのバージョン履歴がJSON形式で返されます。
JSONから1つ前のバージョンを取得する
HTTPから返ってきたデータには、複数のバージョンが配列として格納されています。
今回取得できたデータは、概念的には次のような構造でした。
d
└─ results
├─ [0] 現在のバージョン
├─ [1] 1つ前のバージョン
├─ [2] さらに1つ前のバージョン
└─ ...プログラムの配列では0から数えるため、
results[0]が1件目、
results[1]が2件目です。
今回はresults[1]を使用して、1つ前のバージョンを取得しました。
Power Automateの「作成（Compose）」アクションを使用し、以下のような式で取得しています。
body('SharePoint_に_HTTP_要求を送信します')?['d']?['results']?[1]この時点では、ステータスだけではなく、
- タイトル
- ステータス
- 場所
- メモ
- 更新日時
- 更新者
など、そのバージョン時点のデータがまとめて取得されています。
変更前ステータスだけを取り出す
1つ目の「作成」で取得したのは、1つ前のバージョン全体です。
履歴保存用リストに必要なのは、その中のステータス値だけなので、さらにもう1つ「作成」を追加しました。
処理としては、
全バージョン履歴
↓
作成①
1つ前のバージョン全体
↓
作成②
ステータスの値だけ取得
↓
「貸出中」という流れです。
SharePointでは、日本語で作成した列名がREST API上では内部名へ変換されます。
たとえば画面上では「ステータス」と表示されていても、HTTPから返されるJSON上では、
OData__x005f_x30b9...のような内部名になっている場合があります。
そのため、HTTPアクションの実行結果を確認し、ステータス列に対応する内部名を指定して値を取得しました。
内部名は実際のリスト構成によって異なる可能性があるため、実装する際には自身の環境でHTTPの実行結果を確認する必要があります。
「作成（Compose）」を2回使用した理由
今回のフローでは、「作成」が2つ連続しています。
「作成」という名前から、SharePointへ何かを作成する処理のようにも見えますが、Composeはデータを保存するアクションではありません。
取得したデータを一時的に取り出したり、加工したりするためのアクションです。
今回の場合、1つ目の作成では、
全バージョン履歴
↓
1つ前のバージョンという処理を行いました。
2つ目の作成では、
1つ前のバージョン全体
↓
ステータスだけという処理を行っています。
つまり、
作成①
= 必要なバージョンを選ぶ
作成②
= 必要な列の値を選ぶという役割分担です。
慣れれば式をまとめることもできますが、検証時には処理を分けることで、それぞれの段階で正しい値が取得できているか確認しやすくなります。
5. 取得した変更履歴をSharePointへ保存する
変更前ステータスを取得できたら、最後に変更後の現在値と合わせて、履歴保存用SharePointリストへ追加します。
履歴保存用リストへ追加する
SharePointの
「項目の作成」
アクションを使用しました。
ここで「作成（Compose）」と「項目の作成」の役割は異なります。
作成（Compose）
→ データを加工・抽出する
項目の作成
→ SharePointリストへ実際に保存するという違いがあります。
履歴保存用リストの各列には、以下のような値を設定しました。
タイトル
→ 元アイテムのタイトル
元アイテムID
→ 元アイテムのID
変更前ステータス
→ 作成②の出力
変更後ステータス
→ 現在のステータス
変更日時
→ 更新日時
変更者
→ 更新者これにより、たとえば、
変更前：貸出中
変更後：停止中というステータス変更履歴を別のSharePointリストへ保存できます。
保存されるデータ
実際の履歴保存用リストでは、以下のような形でデータを確認できました。
| タイトル | 元アイテムID | 変更前ステータス | 変更後ステータス |
| PC001 | 1 | 貸出中 | 停止中 |
これによって、元データ用リストには現在の状態を保持したまま、別のリストで状態変化を時系列に蓄積できるようになります。
6. バージョン履歴を扱う際の課題と対応
今回の検証で特に注意したのが、SharePointのバージョン履歴の扱いです。
バージョン履歴をそのまま利用する際の問題
SharePointではステータスを変更した場合だけでなく、
- 場所を変更した
- メモを変更した
- 利用者を変更した
- その他の列を更新した
といった場合にもバージョンが増加します。
つまり、
バージョンが増えた
=
ステータスが変更されたとは限りません。
実際の検証でも、
Version 6.0：停止中
Version 7.0：停止中のように、バージョン番号は変わっているものの、ステータスが変わっていないケースを確認できました。
例えば、グリッドビューでの操作などによって、意図したステータス変更以外でもバージョンが増える可能性があり、「単純に1つ前のバージョンを利用してよいのか」という点が課題として挙げられていました。
今回はどのように対応したか
今回のフローでは、バージョン履歴を取得する前に、
「今回ステータス列が変更されたか」
を判定しています。
そのため、たとえばメモだけを変更した場合には、
メモ変更
↓
SharePointのバージョンは増える
↓
ステータス列変更 = false
↓
後続処理を実行しないとなります。
一方で、ステータスを変更した場合には、
ステータス変更
↓
ステータス列変更 = true
↓
HTTPでバージョン履歴取得
↓
直前バージョンのステータスを取得
↓
履歴保存という流れになります。
つまり、バージョン番号だけを見てステータス変更を判断するのではなく、先に「今回ステータスが変更された」という事実を確認したうえでバージョン履歴を利用する構成にしました。
これによって、ステータス以外の更新が発生した際に、不要な履歴データを保存することを防いでいます。
7. 検証結果と発生したエラー
検証結果
実際に検証用SharePointリストのステータスを変更し、フローを実行しました。
たとえば現在のステータスを、
貸出中
↓
停止中へ変更した場合、SharePointのバージョン履歴から1つ前のバージョンを取得すると、そのステータスが「貸出中」であることを確認できました。
現在のSharePointリストでは「停止中」になっているため、
変更前ステータス：貸出中
変更後ステータス：停止中という形で履歴保存用リストへ登録することができました。
また、ステータス以外の列を変更した場合には、条件判定がFalseとなり、履歴保存処理が実行されないことも確認しました。
以上から、今回の検証範囲では、
「ステータス列が変更された場合のみ、変更前と変更後のステータスを別リストへ自動保存する」
という目的を実現できました。
URIに固定文字列のIDを指定してしまった
HTTP要求を作成した当初、
items(ID)のように、IDという文字列をURIへ直接入力していました。
しかし、実際にはアイテムごとにIDは異なります。
PC001がID=1であれば、
items(1)PC003がID=3であれば、
items(3)とする必要があります。
そのため、固定文字列ではなく、トリガーから取得した動的コンテンツのIDを使用しました。
このエラーから、
毎回同じ値は固定値として入力し、実行ごとに変わる値は動的コンテンツを使用する
というPower Automateの基本的な考え方を確認できました。
Composeの式が文字列として扱われた
Composeに以下のような式を入力した際、式として実行されず、その文字列自体が出力されることがありました。
body('SharePoint_に_HTTP_要求を送信します')?['d']?['results']?[1]原因は、式を通常の文字列として入力していたことでした。
Power Automateで式を利用する場合には、「式（Expression）」から入力する必要があります。
式として正しく設定すると、文字列そのものではなく、HTTPから返されたJSONの対象部分が取得されました。
変更者のデータが255文字を超えた
履歴保存用リストの変更者列へSharePointのユーザー情報をそのまま渡したところ、エラーが発生しました。
原因は、履歴保存用リストの列を「1行テキスト」として作成しており、255文字の上限を超えていたためです。
SharePointの人物情報には、
- 表示名
- メールアドレス
- ID
- その他のユーザー情報
などが含まれている場合があります。
そのため、人物データ全体を保存するのではなく、必要な表示名などだけを取得して保存する必要があります。
このことから、Power Automateでは単に値を取得するだけでなく、取得したデータがどのような型・構造を持っているかを意識する必要があることも分かりました。
8. 今後の改善点
今回の検証では基本的なステータス変更履歴の取得に成功しましたが、実運用を想定すると、いくつか改善できる点があります。
バージョン取得件数の削減
現在のHTTP要求では、対象アイテムのバージョン履歴を取得し、その中から必要なバージョンを選択しています。
今回実際に必要なのは、基本的に、
現在のバージョン
1つ前のバージョンです。
そのため、バージョン履歴が数百件、数千件と増えていった場合、すべての履歴を取得してから必要な1件だけを選択する方式は効率的とはいえません。
今後は、SharePoint REST API側で取得件数を制限し、必要なバージョンだけを取得する方法を検討できます。
基本的には、
Power Automate側で大量のデータを取得してから絞り込むよりも、取得元の時点で必要なデータだけ取得する
方が、通信量や処理量を抑えることができます。
新規アイテム作成時の扱い
現在使用しているトリガーは、
「アイテムが作成または変更されたとき」
です。
そのため、新しくアイテムを作成した場合にもフロー自体は起動します。
今回の検証では既存アイテムのステータス変更を中心に確認しているため、新規作成時の初期ステータスを履歴として保存するかどうかについては、必要に応じて追加で制御する必要があります。
短時間に連続更新された場合
現在の仕組みでは、ステータス変更を検知した後にバージョン履歴を取得し、その時点での1つ前のバージョンを変更前として利用しています。
通常の利用では問題なく動作しましたが、同一アイテムが非常に短時間に連続して更新された場合については、追加で検証する余地があります。
本番運用を想定する場合には、複数ユーザーによる同時更新や連続更新についても確認しておくと、より安定したフローになると考えられます。
9. 今回の検証を通して学んだこと
今回の検証を通して、Power Automateは単純に用意されたアクションを順番に並べるだけではなく、
- トリガー
- データ取得
- 条件分岐
- HTTP
- REST API
- JSON
- 配列
- データ加工
- SharePointへの保存
といった複数の仕組みを組み合わせることで、柔軟な業務自動化ができることが分かりました。
特に理解が深まったのが、「作成（Compose）」の役割です。
Compose自体が何かをSharePointへ保存するわけではなく、
前の処理から受け取ったデータを、次の処理で使いやすい形へ加工する
ために利用できます。
今回の場合、
HTTPで大量のJSONを取得
↓
必要なバージョンだけ取り出す
↓
その中のステータスだけ取り出す
↓
SharePointへ保存という段階的なデータ処理を行いました。
また、通常のPower Automateアクションだけでは取得しにくい情報についても、HTTPを利用してSharePoint REST APIへ直接リクエストすることで取得できることが分かりました。
Power Automateを利用する際には、
何をきっかけに動くのか
↓
どのデータが必要なのか
↓
どの条件で処理を分けるのか
↓
データをどのように加工するのか
↓
最終的に何を実行するのかという流れで考えると、フロー全体を整理しやすくなります。
10. まとめ
今回は、Power Automateを利用して、SharePointリストのステータス変更履歴を別のSharePointリストへ自動保存する仕組みを検証しました。
最終的なフローは、
アイテム更新
↓
変更された列を確認
↓
ステータス変更の場合のみ処理
↓
HTTPでバージョン履歴を取得
↓
1つ前のバージョンを取得
↓
変更前ステータスを抽出
↓
現在のステータスとあわせて履歴リストへ保存という構成になりました。
SharePointでは、ステータス以外の列を変更した場合にもバージョンが増加します。
そこで今回は、最初に、
「今回ステータス列が変更されたか」
を判定し、ステータス変更が確認できた場合のみバージョン履歴を利用することで、不要な更新をステータス変更履歴として保存しないようにしました。
検証の結果、
- ステータス変更の検知
- 変更前ステータスの取得
- 変更後ステータスの取得
- 別リストへの履歴保存
まで正常に動作することを確認できました。
今回の検証を通して、Power Automateの標準アクションだけでなく、SharePoint REST APIやJSONのデータ処理を組み合わせることで、標準機能だけでは扱いにくい情報についても自動化できることを確認できました。
