【Power Automate】退職者作成フローが急に動かない時の入力値と条件分岐の直し方

退職者作成フローが突然動作しなくなった場合、多くのユーザーは原因が分からず混乱します。しかし、原因は入力値の変更や条件分岐の不備など限られたパターンに絞られることが多く、適切な切り分けを行えば自分で修正できるケースも少なくありません。本記事では、退職者作成フローが動かなくなる代表的な原因として、入力値の変化と条件分岐の誤りに焦点を当て、具体的な確認手順と修正方法を解説します。実際の事例を交えながら、フローを復旧するための実践的なノウハウを提供します。

1. 退職者作成フローが動かない原因を整理する

退職者作成フローは、人事データベースやSharePointリストの退職者情報をトリガーに、アカウント無効化やメール転送設定などを自動実行するフローです。突然動かなくなる原因は、大きく分けて以下の3つに分類できます。

1.1 入力値の変化

フローが参照しているデータソース(SharePointリスト、Excel、SQLなど)の列名や値の形式が変更された場合、フロー内の動的コンテンツが解決できずエラーになります。例えば、退職日列が「退職日付」から「退職日」に名称変更された、日付形式が「2025/01/15」から「2025-01-15」に変わったなどが該当します。

1.2 条件分岐の誤り

フロー内の条件アクション(条件、スイッチ、またはApply to each内の条件)が正しく評価されず、処理がスキップされるケースです。特に、複数条件を組み合わせた際の論理演算子の誤用(AND/ORの混在)、値の比較演算子(等しい/含む)の選択ミスが原因になります。

1.3 権限・接続設定の変更

フローが使用するコネクタの認証が期限切れになった、対象のSharePointサイトやリストのアクセス権が変更された、Power Automateのライセンスが失効したなどの理由でフローが実行できない場合もあります。ただし、本記事では主に1と2の入力値・条件分岐に焦点を当てます。

2. 最初に確認すべき場所:実行履歴とアクション詳細

フローが動かないと気づいたら、まず実行履歴を確認します。Power Automateは各実行の記録を残しており、どのアクションで失敗したか、エラーメッセージは何かが分かります。

実行履歴を確認する手順

1. Power Automateポータルにアクセスする(make.powerautomate.com)
2. 左メニュー「マイフロー」をクリックし、対象のフローを選択する
3. フロー詳細画面で「実行履歴」タブを開く(28日間の実行が表示される)
4. 失敗した実行をクリックして展開する(成功した実行と比較すると変化点が分かりやすい)
5. 失敗したアクションの「入力」と「出力」を確認する(入力値が正しく取得できているか、エラーメッセージは何か)
6. エラーメッセージをコピーし、必要に応じて管理者に共有する

特に重要なのは、失敗したアクションの「入力」セクションです。ここに表示される値が想定と異なる場合、データソース側で変更があった可能性が高いです。

3. 入力値の変化を見つけて修正する方法

実行履歴で入力値を確認したら、次にその値が正しいかどうかを検証します。

3.1 チェックすべき入力値のポイント

• 列名の一致: フローで使用している動的コンテンツの列名が、実際のデータソースの列名と完全に一致しているか。大文字小文字、スペース、全角半角も厳密にチェックします。
• 値の型と形式: 日付、数値、文字列の形式が期待通りか。例えば「退職日」列が日付型からテキスト型に変更されていないか確認します。
• NULLや空文字の扱い: 条件分岐で「空でない」や「値が存在する」をチェックしている場合、入力がNULLになっていないか確認します。

3.2 実際の修正例:SharePointリストの列名変更

例えば、以前は「退職日」列を使用していたが、リスト管理者が列名を「退職日付」に変更した場合、フロー内の動的コンテンツは「退職日」を参照したままになるため、空の値が渡されます。修正手順は以下の通りです。

1. フロー編集画面を開く(「編集」アイコンをクリック)
2. 失敗したアクションを見つけ、動的コンテンツを削除する
3. 動的コンテンツ追加画面で新しい列名「退職日付」を選択する(検索ボックスで絞り込み可能)
4. 変更を保存し、テスト実行を行う
5. 成功を確認したら、フローを公開する(自動実行されるように戻す)

同様に、値の形式が変わった場合は、式を使って変換するか、条件分岐で複数の形式に対応する必要があります。

4. 条件分岐の誤りをデバッグする方法

条件分岐が正しく動作しているかを確認するには、実際の値を出力して検証します。

4.1 条件式の実際の値を確認する

条件アクションの直前に「Compose」アクションを挿入し、比較対象の値を出力するとデバッグしやすいです。例えば、条件で「退職日が今日より前か」をチェックする場合、Composeアクションに「formatDateTime(utcNow(), ‘yyyy-MM-dd’)」と「退職日」をそれぞれ出力して、期待値と実際の値の差異を確認します。

1. 条件アクションの上に「Compose」アクションを追加する
2. Composeの入力に、条件で使われる値を設定する(例:式「@outputs(‘Get_items’)?[‘body/退職日’]」)
3. フローをテスト実行し、Composeの出力を確認する
4. 出力が期待と異なる場合、データソースまたは式を修正する
5. デバッグが終わったらComposeアクションを削除する(忘れると余計な処理が残る)

4.2 複数条件の組み合わせミス

「退職日が今日以降 かつ 退職区分が自己都退」のようにAND条件を使う場合、Power Automateの条件アクションでは「かつ(AND)」と「または(OR)」をグループ化できます。よくある間違いは、OR条件をANDで結合してしまうことです。例えば「退職区分が自己都退 OR 会社都退」を意図して、条件1「退職区分 が 自己都退」、条件2「退職区分 が 会社都退」とし、グループ化を「すべて(AND)」に設定してしまうと、両方同時に成立するはずがないため常に偽になります。

修正方法は、条件アクションの「詳細モード」でグループ化を「いずれか(OR)」に変更するか、条件アクションを分割してから後続で統合します。

5. 管理者に確認すべき設定

自力で修正できない場合や、権限不足が疑われる場合は管理者に以下の情報を共有してください。

• コネクタの認証状態: フローが使用しているSharePoint、Outlook、Teamsなどのコネクタの認証が期限切れになっていないか確認を依頼する。管理者はコネクタの「接続」画面で認証を更新できます。
• データ損失防止(DLP)ポリシー: 組織のDLPポリシーが変更され、フローで使用しているコネクタがブロックされていないか確認する。特に新しいコネクタを追加した場合に影響します。
• Power Automateライセンスの有効期限: フロー作成者または実行アカウントのライセンスが切れていないか確認する。ライセンスがない場合はフローが実行されません。
• SharePointリストの変更履歴: データソースのリストで列の追加・削除・名前変更が行われていないか、リストのアクセス権限が変更されていないかを確認する。

6. 状況別のトラブルシューティング

状況	考えられる原因	対処方法
フローが全く実行されない	トリガー条件を満たさない、ライセンス切れ	実行履歴を確認。トリガー条件式を見直す。管理者にライセンス確認
一部のユーザーのみ動かない	ユーザーのデータに特殊文字やNULLが含まれる	該当ユーザーのデータを確認し、条件分岐で特殊ケースを処理する
特定の条件で動かない	条件式のロジックミス、値の形式不一致	Composeアクションで値を確認し、条件式を修正
フローは実行されるがエラーになる	後続アクションで権限不足、列名不一致	エラーメッセージを読み、該当アクションの入出力をチェック

7. よくある質問と失敗パターン

Q1: エラーメッセージが表示されず、フローが成功しているのに退職者作成が行われていない

→ 条件分岐の結果、退職者作成アクションがスキップされている可能性があります。実行履歴で各アクションの「スキップ」状態を確認し、条件が正しいか検証してください。特に、条件の評価結果が期待と異なる場合、前述のComposeデバッグが有効です。

Q2: 入力値が空になっているが、データソースには値がある

→ 動的コンテンツが正しい列を参照していない可能性が高いです。列名が変更されたか、スペルミスがあります。データソースの列名を再確認し、動的コンテンツを入れ直してください。

Q3: 条件分岐で「等しい」を使っているのに合致しない

→ 値の前後にスペースが含まれていたり、大文字小文字が異なる場合があります。Power Automateの条件はデフォルトで大文字小文字を区別するため、比較の前に「trim」や「toLower」関数を使って正規化することを検討してください。

まとめ

退職者作成フローが急に動かなくなった場合、まず実行履歴を確認し、失敗したアクションの入力値とエラーメッセージを調べてください。多くのケースは、データソースの列名変更や値の形式変化、条件分岐のロジック誤りで発生します。これらの原因を特定するには、Composeアクションを使ったデバッグや、管理者との情報共有が有効です。安易にフロー全体を作り直す前に、本記事の手順で一点ずつ確認し、必要最小限の修正で復旧できるようにしてください。再発防止のため、変更管理プロセスを導入し、データソースの変更があった場合はフローに影響がないか事前にテストすることをお勧めします。