【Power Automate】オンプレミスデータゲートウェイで困った時の入力値と条件分岐の直し方

Power Automateを使ってオンプレミスデータゲートウェイを経由したフローを実行する際、入力値が正しく渡らない、条件分岐が想定通りに動かないといったトラブルは頻繁に発生します。ゲートウェイ経由ではデータ型やnullの扱いがクラウド上のサービスと異なるため、原因を正確に見極めないと修正に時間がかかります。この記事では、実際のエラー例やよくある失敗パターンを交えながら、原因の切り分け方から具体的な修正手順までを解説します。

なぜ入力値や条件分岐で問題が起きるのか

オンプレミスデータゲートウェイは、オンプレミスのデータベースやファイルサーバーとPower Automateを仲介します。この通信ではデータのシリアライズ・デシリアライズが行われるため、以下のような要因で値の解釈が変わることがあります。

データ型の自動変換の影響

たとえば、SQL Serverのint型の値「1」がゲートウェイ経由でPower Automateに渡されると、文字列の「”1″」として扱われることがあります。この状態で数値として条件分岐(value = 1)を書いても一致しないため、意図しない結果になります。

nullと空文字の違い

ゲートウェイを経由した場合、データベースのNULL値はそのままnullとして渡されますが、空文字列は空の文字列として渡されます。多くの初心者はこの2つを混同し、条件式で「empty(変数)」や「変数 != ”」などの判定を正しく設定できません。

ゲートウェイのタイムアウト

大量データを扱うクエリや処理時間のかかるストアドプロシージャを呼び出すと、ゲートウェイの既定のタイムアウト(通常30秒～2分)に引っかかり、途中でデータが欠損したりアクション自体が失敗したりします。この場合、入力値が不完全になるため条件分岐がおかしくなります。

トラブルシューティングの基本手順

問題を切り分けるためには、以下の手順を順に実施してください。各ステップで具体的な確認ポイントを説明します。

ステップ1: ゲートウェイ接続とデータソースの状態を確認

Power Automateの管理センターから、対象のゲートウェイがオンラインであること、データソースの認証が有効であることを確認します。もしゲートウェイがオフラインであれば、すべてのフローがエラーになります。

ステップ2: フローの実行履歴を確認

Power Automateのフロー詳細画面で「実行履歴」を開き、エラーが出た実行をクリックします。その際、各アクションの「入力」と「出力」を必ず確認してください。特に、ゲートウェイを呼び出すアクション(例えば「SQL Serverに接続して行を取得する」)で生成された値が期待通りかどうかが重要です。

ステップ3: 入力値の型と内容をチェック

出力された値が文字列なのか数値なのか、nullなのか空文字なのかを実際に見ます。たとえば出力が「”0″」なら文字列、出力が「0」なら数値です。ここでの誤認がその後の条件分岐の誤動作に直結します。

ステップ4: 条件分岐の式を見直す

条件式に使っている関数や演算子が正しいか確認します。特に「@equals()」「@empty()」「@coalesce()」などの式関数の使い方に注意してください。

1. フローの編集画面を開き、問題のアクションを選択する。
2. アクションの設定画面で「動的なコンテンツの追加」をクリックし、ゲートウェイから取得した項目を挿入する。
3. その項目に対して「式」タブから適切な変換関数(例:int(), string(), concat())を適用する。
4. 条件アクションの「値」欄に式を直接入力するか、動的コンテンツと組み合わせる。
5. 保存してテスト実行し、結果を実行履歴で確認する。
6. 想定どおりの分岐にならなければ、再度条件式を調整する。

よくある失敗パターンと具体的な修正テクニック

ここでは、実際の現場でよく遭遇するパターンを3つ取り上げ、修正例を示します。

パターン1: NULLと空文字の区別ができない

データベースでNULLの列を取得した場合、Power Automateにはnullとして渡されます。一方、空文字列は空の文字列です。条件分岐で「値が空かどうか」を判定するには、@empty(variables('item'))を使いますが、この関数はnullも空文字もtrueと判定します。もし「空文字列のときだけ処理を変えたい」場合、次のような式を使います。
@equals(variables('item'), '')と@equals(variables('item'), null)を組み合わせてください。

パターン2: 数値と文字列の不一致

ゲートウェイ経由で取得した値が必ず文字列として扱われるとは限りません。データベースの型によっては自動変換されます。例えば、SQL Serverのint型の「5」はPower Automateで整数「5」として認識されることがあります。しかし、トリガーの種類やフロー内での加工によって文字列になることもあります。このような場合、条件式で@equals(outputs('SQL')?['value']?[0]?['id'], 5)と書くと、型が違うため一致しません。安全な方法は、数値変換を明示的に行うことです:@equals(int(outputs('SQL')?['value']?[0]?['id']), 5)。

パターン3: ゲートウェイのタイムアウトによるデータ欠損

大量データを扱うクエリや複雑なストアドプロシージャを呼び出すと、ゲートウェイがタイムアウトしてデータが途中までしか返らないことがあります。この場合、条件分岐に使うべき値が欠落して予期しない動作になります。対策として、ゲートウェイのタイムアウト設定を変更するか(管理者権限が必要)、クエリを分割して複数回の呼び出しに変更します。

状況	症状	主な原因	推奨される対策
値が常にfalseになる	条件分岐で「等しい」判定が成立しない	データ型の不一致	明示的にint()やstring()で変換する
空チェックが効かない	nullと空文字を混同している	nullの存在を考慮しない条件式	@coalesce()でデフォルト値を設定する
フローが途中で停止する	ゲートウェイアクションがタイムアウト	クエリの処理時間超過	クエリを最適化するかタイムアウト値を調整

管理者へ確認すべき設定項目

フロー作成者だけでは解決できない設定がいくつかあります。以下の点を管理者に確認してください。

ゲートウェイのタイムアウト設定

ゲートウェイの既定のタイムアウトは1分です。管理者はPower Platform管理センターでゲートウェイの「詳細設定」からタイムアウトを延長できます。ただし、あまり長くするとゲートウェイサーバーに負荷がかかるため、適切な値(例:3分)に設定してもらいます。

データソースの認証情報

データソースの接続に使っているWindows認証やSQL Server認証のアカウントに、必要なテーブルやビューへのアクセス権があるか確認します。権限不足だと値がNULLで返されることがあります。

ゲートウェイのクラスタ設定

複数のゲートウェイをクラスタ化している場合、ロードバランシングによって同じフローでも異なるゲートウェイ経由になることがあります。その場合、各ゲートウェイでデータソースの設定が統一されているか確認が必要です。

よくある質問

Q1: ゲートウェイ経由の値がすべてNULLで返ってくる

認証情報の問題か、クエリにエラーがある可能性が高いです。まずはデータベース管理ツールで同じクエリを実行できるか確認し、その後ゲートウェイのデータソース設定を見直してください。管理者にデータソースのテストを依頼することも有効です。

Q2: 条件分岐で「@greater()」がうまく動かない

@greater()関数は数値同士の比較にしか使えません。値が文字列として渡されている場合、@greater(int(variable), 100)のように変換してから比較する必要があります。また、比較対象の100も文字列ではなく数値として書いてください。

Q3: フローは成功するが条件分岐が常に同じ結果になる

これは多くの場合、条件式で固定値(例:’Yes’)と動的コンテンツが正しく比較できていないことが原因です。実行履歴でアクションの出力値を確認し、期待する値と実際の値を照らし合わせてください。また、式の中で引用符の使い方(シングルクォートとダブルクォート)にも注意が必要です。

まとめ

オンプレミスデータゲートウェイを使ったPower Automateフローで入力値や条件分岐に問題が発生した場合、まずは実行履歴で実際のデータを確認することが第一歩です。データ型とnull/空文字の扱いを意識して条件式を書き直すことで、多くの問題は解決できます。管理者に確認すべき設定としては、タイムアウト値や認証情報があります。この記事で紹介した手順を参考に、一つひとつ原因を切り分けて、安定したフローを構築してください。