はじめに
NTT西日本の服部です。本記事はNTT WEST Engineers' Blog 開設にむけて投稿記事レビューのワークフローを爆速で構築した話の第6回の記事となります。
前回までの記事も読んでいただけるとありがたいです。
最終回の第６回となる本記事ではPower Automateによるレビューフロー後編として差戻による修正依頼と記事公開後の通知フローについてご紹介します。
本記事は2025年9月時点の情報に基づきます。
- ①~概要編~
- ②~Microsoft Forms/Microsoft Lists編~
- ③~Power AutomateによるMicrosoft Listsへの自動登録編~
- ④~Power Automateによるレビューフロー前編~
- ⑤~Power Automateによるレビューフロー中編~
- ⑥~Power Automateによるレビューフロー後編~(本記事)
第1回の記事でご紹介したワークフローの全体像のうち、以下の図にあたる内容となります。
修正依頼フロー
投稿完了通知フロー
対象読者
本記事が想定する対象読者は以下の通りです。
- 自動化に興味がある人
- 繰り返しの定常的な作業に困っている人
- Microsoft Forms/Microsoft Lists/Power Automateを使ってみたい人
背景
NTT WEST Engineers' Blog に向けて、ブログ記事のレビュープロセスを効率化したいという要望を受けて執筆者が検討・構築しました。
SaaSの新規サービスを導入する予算はありませんでしたが、幸い全社的にMicrosoft Forms、Microsoft Lists、Power Automateが利用できる環境だったため、これらを用いてブログ記事レビューのワークフローを構築しました。
本記事ではPower Automateを用いた1.差戻による修正依頼フローと2.記事公開後の通知フローについてご紹介します。
アダプティブカードについて
本記事でご紹介するフローにはアダプティブカードを使った処理が含まれています。
アダプティブカードの詳細については前回の記事で紹介しておりますのでぜひそちらの記事も読んでみてください。
1.修正依頼フロー
修正依頼フローの全体像は以下の通りです。
ここで冒頭でご紹介したフローのイメージ図ではレビュー結果通知および修正依頼から始まっているにも関わらず上記のフローではアイテムが作成または変更されたときから始まっている点が気になる方がいらっしゃるかもしれません。
元々構築したフローでは前回ご紹介したレビューフローと今回の修正依頼フローは一つのフローにまとめていたためイメージ図通りの処理内容でした。しかしブログ執筆にあたり分割したほうが読みやすい記事にできると判断しフローを二つに分けた結果、ここでは差分が発生しています。
以下で各ステップの詳細についてご紹介します。
1-1. アイテムが作成または変更されたとき
このフローが実行されるトリガーです。
前回/前々回の記事でも紹介しましたがMicrosoft Listsにおける一行ごとのデータ（レコード）のことをアイテムといい、本記事においては1アイテム=1件分のレビュー依頼に相当します。
トリガーの条件として以下を指定しました。
@equals(triggerBody()['OData__x30b9__x30c6__x30fc__x30bf__x30/Value'],'差し戻し(修正待ち)')
上記は作成または更新されたアイテムのステータスが差し戻し(修正待ち)のときにこのフローが実行されることを意味しています。
前回ご紹介したレビューフローで差し戻しとなったときの処理としてステータスが差し戻し(修正待ち)に更新されたことをトリガーとして本フローが実行されます。
トリガーの条件の書き方については第３回の記事で詳しく解説しているため、そちらを参照ください。
1-2. 変数を初期化する
レビュアーコメントの一部を置換した内容をcommentという文字列変数に代入しています。
値の部分には以下の評価式が入っています。
replace(replace(triggerOutputs()?['body/OData__x30ec__x30d3__x30e5__x30fc__x30'],'"','”'),'\','￥')
ここではレビュアーコメントの列の値について、半角のバックスラッシュ\を全角の円マーク￥に置換するという処理と半角のダブルクォート"を全角のダブルクォート”に置換するという処理を実行しています。
半角のダブルクォートやバックスラッシュが残っていると次のアダプティブカードの投稿処理でJSON形式が崩れることでエラーが発生してしまうため、それを回避するためにこのような処理を挟んでいます。
1-3. アダプティブ カードを投稿して応答を待機する(修正依頼)
投稿者宛に修正依頼のためのアダプティブカードを送る処理です。
省略されているメッセージ部分には以下のJSONが記載されています。
{ "type": "AdaptiveCard", "body": [ { "type": "TextBlock", "size": "Medium", "weight": "Bolder", "text": "ブログ記事の修正依頼" }, { "type": "TextBlock", "text": "タイトル：@{triggerOutputs()?['body/Title']}の記事についてレビューの結果、差し戻しとなりました。 \nレビューコメントを参照して記事を修正してください。 \n\nレビューコメント：\n\n@{variables('comment')}", "wrap": true }, { "type": "ActionSet", "actions": [ { "type": "Action.OpenUrl", "title": "下書きプレビューURL", "url": "@{triggerOutputs()?['body/OData__x4e0b__x66f8__x304d__x30d7__x30']}" } ] }, { "type": "ActionSet", "actions": [ { "type": "Action.Submit", "title": "完了", "id": "complete" }, { "type": "Action.Submit", "title": "キャンセル", "id": "cancel" } ], "horizontalAlignment": "Center", "spacing": "Medium" }, { "type": "TextBlock", "text": "・完了：再度レビュー依頼をあげます。 \n・キャンセル：投稿依頼を取り下げます。", "wrap": true } ], "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "version": "1.5" }
上記のアダプティブカードが送信されるとMicrosoft TeamsでWorkflowsという対象から以下のようなメッセージがレビュアーの個人チャット宛に届きます。
このアダプティブカードの内容を参照して投稿者は記事の修正対応を実施し、再度レビュー依頼をあげるために完了をクリックするか、投稿依頼を取り下げるとしてキャンセルをクリックすることで次の処理に進めることができます。
こちらのアダプティブカードの処理はタイムアウトを7日間(P7D)に設定しています。
タイムアウト設定については前回の記事を参照ください。
1-4. スイッチ(修正対応の結果)
アダプティブカードの結果によって処理が分岐します。
分岐処理の判定には以下の値を使用しています。
outputs('アダプティブ カードを投稿して応答を待機する(修正依頼)')?['body/submitActionId']
ここには直前に処理されたアダプティブカードでクリックされたボタンのIDが入ります。
つまりアダプティブカードのメッセージで定義された以下のボタンに割り当てられたIDであるcomplete,cancelのいずれかが入ります。
"type": "ActionSet", "actions": [ { "type": "Action.Submit", "title": "完了", "id": "complete" }, { "type": "Action.Submit", "title": "キャンセル", "id": "cancel" } ],
1-4-1. ケース1(完了)
アダプティブカードで完了がクリックされたときの処理です。
完了の場合はステータスをレビュー完了に変更する処理が実行されます。
ここの処理ではレビュアーの値は特に指定していないため、これまでに設定されたレビュアーの値が残ったままになっています。
これによって前回と同じレビュアー宛に再度レビュー依頼を送るフローが実行されます。
レビュー依頼のフローについては前回の記事を参照ください。
1-4-2. ケース2(キャンセル)
アダプティブカードでキャンセルがクリックされたときの処理です。
キャンセルの場合はステータスを却下/消滅に変更する処理が実行されます。
ステータスが却下/消滅に変更された場合は他のフローは実行されないため、ここで処理が終了となります。
投稿者都合で修正対応をする時間が取れない場合等を想定しています。
1-5.項目の更新(タイムアウトに伴う消滅)
アダプティブカードがタイムアウトしたときの処理です。
ここではレビュー依頼をクローズするためにステータスを却下/消滅に更新しています。
タイムアウト時の並列分岐の追加方法については前回の記事を参照ください。
2.記事公開後の通知フロー
事務局によって記事が公開された後、事務局の担当者はリストのステータスを投稿完了に手動で変更します。
ステータスが投稿完了になったことをトリガーとして投稿者に通知を送るためのフローの全体像は以下の通りです。
以下で各ステップの詳細についてご紹介します。
2-1. アイテムが作成または変更されたとき
このフローが実行されるトリガーです。
トリガーの条件として以下を指定しました。
@equals(triggerBody()['OData__x30b9__x30c6__x30fc__x30bf__x30/Value'],'投稿完了')
上記は作成または更新されたアイテムのステータスが投稿完了のときにこのフローが実行されることを意味しています。
トリガーの条件の書き方については第３回の記事で詳しく解説しているため、そちらを参照ください。
2-2. チャットまたはチャネルでメッセージを投稿する
投稿者宛に記事が公開されたことを通知します。
上記の処理によってMicrosoft TeamsでWorkflowsという対象から投稿者の個人チャット宛にメッセージが投稿されます。
注意事項
今回ご紹介したPower Automateのフローは意図的にフローの実行結果から別のフローを呼び出すという設計にしていますが、設定値を誤ると無限ループが発生する可能性があります。
本記事の内容を流用される場合には無限ループが発生しないように十分に注意して設計/構築してください。
無限ループへの対処法については以下の日本マイクロソフトのブログ記事も参照ください。
Power Automate のフローで無限トリガーループが起きる際の対処法 | Japan Dynamics CRM & Power Platform Support Blog
最後に
NTT WEST Engineers' Blog 開設にむけて投稿記事レビューのワークフローを爆速で構築した話と題して第6回までお送りしました。
本記事で紹介した内容の各要素は他のブログ等でも紹介されており、特別難しいことをしているわけではありません。
ただ私自身がこのフローを作る中で調べものをしているときに各要素を紹介したものはあるがこれらを組み合わせて構築してみたといった内容の記事は数が多くないように感じました。
なければ自分で作ればいいじゃないということで今回執筆してみましたがいかがでしたでしょうか。
需要がないから誰も書いていない可能性はあるかも・・・と思いつつ執筆しましたが少しでも参考になる部分があれば幸いです。
ここでご紹介したフロー自体は3,4日程度で執筆者自身が単独で構成検討/構築したもので運用も始まったばかりでこれから様々なブラッシュアップが入ることが想定されます。
ブラッシュアップしていく中で参考になりそうな内容が出てきた際には本ブログにて改めてご紹介できればと思います。
ここまで読んでいただきありがとうございます。
執筆者
服部 真智(NTT西日本 ビジネス営業本部所属)
普段はAWS案件の提案、設計、構築等の支援を行っています。
自業務の効率化のためにPython,Power Automate,生成AI等を使って日々試行錯誤しています。
2025 Japan AWS Top Engineers (Services)
商標
Microsoft (Microsoft Entra 、 Microsoft Teams 、 Power Automate 、 Microsoft Lists 、 Microsoft Forms)及び関連する名称並びにそれぞれのロゴは、米国 Microsoft Corporation の米国およびその他の国における商標または登録商標です。
