PowerAutomateでキャンセル済みの予定を自動削除しよう

みなさんこんにちは。
今回はOutlookを使う上で面倒なアレを自動でやってしまおうというお話です。

Outlookの予定とキャンセル

普段、私の職場ではOutlookで予定管理しています。
リモートメインのため、ちょっとした打ち合わせなども全てオンライン会議として予定に追加する運用です。
そうなると面倒だなぁと思うのが、

このキャンセル済み予定の削除。
Outlookのありがた迷惑仕様というか、キャンセルされた後も予定表から消えずに↑のように残り続けてしまうんですよね。
放っておくとどんどん予定表がごちゃごちゃしてくるので、これまでは逐一削除していました。
これをどうにかしよう、ということでPowerAutomateで自動的に削除するフローを作成します。

フローの骨子

作成するフローの概要は以下となります。

・予定が変更された時にフローを起動する
・キャンセル済みの予定だったら削除する

至ってシンプルですね。
これをもとにフローを設計していきます。

フローの作成（作成〜条件分岐まで）

PowerAutomateの作成メニューから、「自動化したクラウドフロー」を選択します。

フロー名をつけ、「イベントが変更されたとき」を選択して作成します。
（V3）などの数字が大きいほど新しいアクションになるので、特に理由がなければ新しいものを選びましょう。

予定表IDの欄で自分のメインで使用している予定表を選択します。

続いて「現在の時刻」「時間への追加」のステップを追加します。
これらの値は後々使います。
「時間への追加」はひとまず１ヶ月としておきましょう。これでフロー実行時の日時とその１ヶ月後の日時が取得できます。

フローの作成（条件分岐その１）

ここからが肝心のロジックの部分になります。
コントロールの「条件」を追加し、トリガーイベントの繰り返しの値が”none”かどうか判定します。noneはテキスト直打ちです。
何故この判定が必要かというと、これにはOutlookの繰り返しイベントの仕様が関係しています。

Outlookで繰り返しイベントを作成すると、イベントの大元となるイベント情報（↑でいうところの定期的なイベントの全て）と、個別のイベント情報（このイベント）の２種類が作成されます。
説明の都合上、前者を親イベント、後者を子イベントと呼ぶことにします。
関係性としては、親イベントを編集すると全ての子イベントに波及します。一方、子イベントを編集しても親イベントには影響しません。

話を戻しますと、今回のトリガーである「イベントが変更されたとき（V3）」は、子イベントが変更された場合でも親イベントの情報を取得してくるという仕様になっているのです。そのため、子イベントが変更された場合にどの子イベントが変更されたのかがフロー上わかりません。
そういうわけで繰り返しイベントの対応ためにそれ以外と分けて処理することにしています。
では、まず繰り返しの値がnone（＝普通のイベント）の処理をやっていきましょう。

条件分岐の「はい」の方に更に条件を追加します。
トリガーイベントの件名に「キャンセル済み」「Canceled」が含まれるかを判定します。これはキャンセル時にOutlookが自動で追加する文字列です。
はいの場合に「イベントの削除」アクションを使用して予定表から削除します。
IDというのはイベントの一意識別子とのこと。（長ったらしい英数字記号の羅列です）
トリガーイベントのIDを指定すればOK。

いいえの場合は何もする必要が無いので、アクションはありません。
「終了」コントロールを追加してもいいですが、今回は後続アクションが無いのでブランクでも問題ありません。

フローの作成（条件分岐その２）

続いていいえの方（繰り返し予定）を作り込みます。
こちらもはいの場合と同じく、件名からキャンセル済みイベントを判定します。
条件に一致したイベントを削除します。

さて、先ほど”子イベントが変更された場合でも親イベントの情報を取得してくる”というお話をしました。
つまりこの条件３で判定されるのは親イベントということです。
そのため、トリガーイベントが親イベントであればここで終了して問題ないのですが、子イベントだった場合はいいえの方に進んでしまいます。
なので子イベントのキャンセル対応をやっていきます。

「イベントのカレンダービューの取得」を使用して予定表からイベントを取得します。
このアクションは指定した日時の範囲内のイベントを一括取得します。複数のイベントを配列として取得してくるイメージです。
ここで前段の現在の時刻と、その１ヶ月後の時刻を使用します。
これで直近１ヶ月のイベントが取得できます。

Apply to eachのコントロールを使用して、取得したアイテムそれぞれにキャンセル済みのチェックをかけます。
valueを使用すると全ての項目を対象に条件式の評価をすることができます。（ここでは件名しか評価しないので件名でもいいと思います）

変更された子イベントがわからないので、１ヶ月分イベントを取ってきてキャンセルされたものを消してしまうという力技です。

これで直近１ヶ月以内の子イベントであれば削除することができます。
勿論「時間への追加」アクションの値を変更すれば調整できますので、必要に応じて変更してください。

ちなみに１ヶ月に設定した理由は、

・取得範囲を広くし過ぎると大量の予定を取得してしまい、フローが正常に動作しなかったり、APIコール数を無駄に消費する懸念がある
・１ヶ月より先の予定を事前にキャンセルする場面はほぼ無い

というところです。

これで条件分岐式の作成が終わりました。
あんまり綺麗ではないですが、今回の条件分岐をまとめるとこのような感じになります。

まとめ

最後に、フローの全体像を見るとこのような形になります。

繰り返しイベントの処理が若干中途半端であることは否めないですが、とりあえず用途は満たせるのでよしとしましょう。
GUIベースのツールは使いやすい反面妥協しなければならない場面も多いですからね。

以上ご参考になれば幸いです。

おまけ

子イベントを取得するための試行錯誤の結果を載せておきます。
（上手くいかなかったものたち）

「イベントのカレンダービューの取得」の他に「イベントの取得」というアクションがあります。
一見これを使えば特定の子イベントが取得できそうに見えますが、どうやら繰り返しイベントに関しては最初の１回しか取得できないようです。
実際フィルタークエリを使って色々試しましたが、上手くいきませんでした。
特にイベントのIDでクエリを作成すると処理に異常に時間がかかる現象が起きました。ひょっとすると文字数の上限などが仕様上あるのかもしれません。（ODATAフィルタークエリは情報が断片的で正直よくわからない）

「イベントのカレンダービューの取得」の範囲を動的に設定できないものかと考えたのですが、”繰り返し予定は終了日を決めずに作成することができる”点が厄介でした。
下手にトリガーイベントから開始終了日を持ってくると最悪無限ループに陥ります。
そのため仕方なく期間を決め打ちして処理する方式にしました。

この辺りは今後アクションの仕様がアップデートされて改善できる部分も出てくるかもしれません。