ServiceNow Flow Designerで値が取れない理由データピルの落とし穴と解決手順

はじめに：データピルが取れないのは構造の問題が多い
原因の全体像：データピルの正体は入力出力実行コンテキスト
典型原因：レコード参照権限タイミング型のズレ
切り分け手順：実行詳細から逆算して原因を絞る
実務での対処パターン：ケース別の直し方と再発防止
まとめ：データピルが取れない原因は出力と実行コンテキストに集約される

はじめに：データピルが取れないのは構造の問題が多い

Flow Designerを触り始めてしばらくすると、だいたい一度はこうなります。

データピルを選んだのに実行結果が空
そもそも欲しいフィールドがデータピルに出てこない
参照の先の値を取るつもりが違う値になっている
カタログ変数は見えているのに、レコードのフィールドが取れない

この手の悩みは、コードのバグというより、フローの中でその値が存在していないか、存在していても見える状態になっていないことが原因になりがちです。

試験対策としても実務としても大切なのは、データピルを「便利な差し込み機能」として暗記するのではなく、入力と出力がどうつながっているかで理解することです。
データピルは突然どこからでも値を引っ張ってこれる魔法ではなく、基本的には「その時点で手元にある情報」しか持てません。

この記事では、データピルが取れない典型原因をパターン化して、確認順と直し方を具体例つきで整理します。初学者が迷子にならないように、なるべく言葉で追える形にしました。

本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇

UdemyでServiceNow模擬問題集を人気順で見る

原因の全体像：データピルの正体は入力出力実行コンテキスト

データピルは出どころが決まっている

Flow Designerのデータピルは、主に次の3つから出てきます。

トリガーの情報
例：レコードが更新された、カタログが提出された、などの起点に付随する値
各アクションの出力
例：レコード取得アクションの結果、ユーザー取得の結果、サブフローの出力
フロー内で作ったデータ
例：セットした変数、計算した値、スクリプトで組み立てたJSONなど

つまり、データピルが空になる時は、だいたい次のどれかです。

そもそも起点のデータが存在していない
アクションが想定したレコードを返していない
返してはいるが、参照や型の扱いを間違えている
実行時の権限やスコープの影響で見えていない
取得できるタイミングより早い段階で読もうとしている

よくある誤解：見えているデータピルは常に値を持つ

Flow Designerの画面上でデータピルが選べると、「この値は取れるはず」と思ってしまいがちです。
でも実際は、選べることと値が入ることは別です。

例として、アクションで「レコードを取得」したつもりでも、条件に合うレコードが0件なら、出力は空になります。画面ではデータピルとして見えていても、実行時には何も入っていません。

もう一つのカギ：実行コンテキスト

同じフローでも「誰として実行されるか」で結果が変わります。
権限の影響で「値が空に見える」「レコードが取れない」ケースは、現場でもわりとあります。

ユーザーに読み取り権限がないフィールドは、取得できないか空に見えることがある
参照先テーブルにアクセスできず、参照フィールドの表示値が取れないことがある
フローがシステム権限寄りで動くのか、起点のユーザー権限寄りで動くのかで結果が変わる

ここを一言で言うと、データピルはデータの問題と権限の問題の両方で空になるということです。

典型原因：レコード参照権限タイミング型のズレ

ここからは、実際に「取れない」時に多い原因を、現場の感覚に寄せて並べます。

レコードがそもそも存在しない

一番多いのはこれです。
特に「レコードを取得」「レコードを検索」系のアクションで、条件が厳しすぎて0件になっているケース。

状態が想定と違う
テーブルを取り違えている
参照を sys_id ではなく表示名で探している
実行時点ではまだ作成されていないレコードを探している

見た目のフローは正しくても、返ってくるデータが0なら、以降のデータピルは全部空になります。

参照フィールドの扱いを誤解している

参照フィールドは特につまずきやすいです。
「表示名が欲しい」のか「sys_idが欲しい」のかで扱いが変わります。

参照フィールドのデータピルを入れたつもりが、実際は sys_id が入っている
逆に表示値を使いたいのに sys_id のまま文章に差し込んでしまい、人間が読めない
参照先のさらに参照先を取りたいのに、途中をレコードとして展開できていない

対策としては、参照は次の順で考えると整理できます。

まず参照元フィールドは「参照先レコードを指すもの」
参照先のフィールド値が欲しいなら「参照先レコードを取得」してから、その出力から取る
表示値が欲しいなら、表示値を返す方法を意識する

権限やフィールドレベルの制御で見えていない

フローの実行履歴を見ると「アクションは成功」になっているのに、値が空に見える。
こういう時は権限やフィールドレベルの制御が絡んでいることがあります。

対象フィールドの読み取り権限がない
参照先レコードにアクセスできず、表示値が取れない
特定ロールがないと見えないフィールドで空になる

学習段階では見落としやすいですが、仕組みとしては自然です。
「そのユーザーが普段UI上で見えているか」を基準に考えると、当たりを付けやすいです。

タイミングが早いまだ確定していない値を読んでいる

カタログ系でよくあるのがこれです。
例えば、リクエストやタスクを後続で作る設計なのに、作成前にその値を取ろうとして空になる、など。

作成前のレコードをデータピルで参照している
更新がコミットされる前提で値を読んでいる
ループや条件分岐で、特定ルートではまだ値がセットされていない

フローは上から順に動くので、単純ですが「値をセットした後に読む」が鉄則です。
特に、分岐の片方だけで値をセットしていると、もう片方のルートでは空になります。

型が違う文字列とレコードを混同している

Flow Designerは見た目がやさしい分、型の感覚が薄れます。
でも実際は「これはレコードなのか」「ただの文字列なのか」でできることが変わります。

文字列に対して参照先フィールドのように掘ろうとして取れない
レコード型のはずが、どこかで文字列として扱ってしまい空になる
JSONを組み立てたけど、パースせずに参照しようとして空になる

このあたりは、後述する切り分け手順で「どの段階の出力が何なのか」を確認すると一気に解決します。

切り分け手順：実行詳細から逆算して原因を絞る

「取れない」問題は、当てずっぽうで直すと沼ります。おすすめは、次の順番で淡々と切り分けることです。

実行結果で空になった地点を特定する

まずはフローの実行履歴で、どのアクション出力から空になったかを確認します。

トリガーのデータはあるか
レコード取得の結果は1件以上か
その後のアクション出力は想定の型か

ここで「最初に空になった地点」を特定できると、原因はほぼそこにあります。
後ろのアクションをいじっても直らないのは、たいていこのパターンです。

レコード取得系は条件を簡単にして検証する

レコードが取れない時は、いきなり複雑な条件でやらないのがコツです。

まず sys_id 固定で1件取る
次に条件を1個だけにする
最後に本来の条件に戻す

これで「条件が悪いのか」「テーブルが違うのか」「そもそも存在しないのか」を切り分けできます。

参照は一段階ずつ展開する

参照先のさらに参照先を取りたいとき、いきなり深く掘ると失敗しやすいです。

まず参照先レコードが取れているかを確認
次に参照先の欲しいフィールドを出力で確認
さらに必要なら、次の参照先を取得する

一段階ずつ実行結果で追えるようにすると、迷子になりません。

実行ユーザーの違いを疑う

同じフローが「管理者では動くのに一般ユーザーだと空」なら、権限が濃厚です。

一般ユーザーがUI上でそのフィールドを見えるか
参照先テーブルにアクセスできるか
フィールド権限やACLの影響がないか

この確認は、フロー側をいじる前にやった方が早いです。
特に、表示値が取れない系は参照先の権限不足で起きやすいです。

テスト用に値を固定してフローの構造だけ検証する

最終的に、外部条件で揺れる値をいったん固定して、フローの構造が正しいかだけを見ると安定します。

入力を固定する
取得対象を固定する
出力を固定して後続を検証する

こうすると「データの問題」と「フローの書き方の問題」が分離できます。

実務での対処パターン：ケース別の直し方と再発防止

最後に、よくある症状別に「どう直すか」をまとめます。読者が自分の状況に当てはめられるように、少し具体めで書きます。

欲しいフィールドがデータピルに出てこない

対処の方向性はだいたい2つです。

そのフィールドを含むレコードを、フローのどこかで取得していない
取得はしているが、参照として展開できる形になっていない

よくある解決策は、レコード取得アクションを追加して「レコード型の出力」を作ることです。
データピルは出力からしか増えないので、出力を増やす設計にします。

データピルは選べるのに実行結果が空

多いのは次のどれかです。

レコード取得が0件
条件分岐のルートによっては値をセットしていない
参照先の権限がなくて空に見える
タイミングが早い

この場合は、実行履歴で「最初に空になった地点」を探すのが近道です。
そこがレコード取得なら条件を簡単に、分岐なら両ルートで値を持つように、権限なら読み取り設計を見直します。

参照先のフィールド値が取れない

参照は、いきなり深掘りせず、次の形に戻すと直しやすいです。

参照先レコードを明示的に取得する
取得したレコードのフィールドをデータピルで取る

「参照フィールドから直接取りたい」という気持ちは分かるのですが、初学者のうちは明示的に取得した方がトラブルが減ります。フローの読みやすさも上がります。

カタログ系で値がずれる取れない

カタログは、レコードフォームより登場人物が多いです。

変数
RITM
依頼
タスク

どの段階の何を取りたいのかを言語化してから、必要なレコードを取得するのがコツです。
「変数を取りたい」のにRITMのフィールドを探していた、のようなズレが起きやすいので、起点と目的地を整理します。

再発防止のコツ：データピルを設計図として扱う

慣れてくると、データピルは単なる差し込みではなく、フローの設計図になります。

このアクションは何を出力するのか
後続はその出力を食べているのか
出力が空になる条件は何か

この視点でフローを見ると、トラブル対応も速くなりますし、フロー自体の品質も上がります。

もしFlow Designerの学習が点の理解になっていて、毎回同じところで止まってしまうなら、体系立てて学べる教材を一つ挟むのもおすすめです。Udemyには、フローの考え方、レコード取得、参照の扱い、デバッグの手順まで一連で整理している講座があるので、必要な章だけ拾って「理解の穴」を埋める使い方だと自然に役立ちます。