ワークフロー作成における「警告」防止 フィールドガイド

[clmc9601]

Claire McCollough著、Akimasa Kajitani日本語訳、原文は英語で書かれています。

---

ワークフローの実行が成功すると、警告、変換エラー、エラーなしで完了すべきです。つまり、ワークフローが意図したとおりに実行され、すべての検証に合格した場合、「実行完了」の行は、黄色やオレンジ、赤色ではなく、黒色になるべきです。

警告や変換エラーが発生するたびに、データが失われたり、不正確な計算が行われたりしていることをご存知ですか？これらのメッセージは多くの場合、値がNullで置き換えられていることを意味します。

警告だらけのワークフローは、日々のワークフローでメンテナンスを行うときの障害になります。結果ログが乱雑だと、どのようにして出力の品質を信用し、ワークフローが正常に実行されていることを知ることができるのでしょうか？

私は、警告やフィールドの変換エラーを無視したり隠したりするのではなく、未然に防ぐことを推奨します。この記事の残りの部分で、いくつかの一般的な警告に対するお気に入りの防止策をご紹介します。

索引

もしくは、ワークフロー警告種の分類

科：データの組み合わせ

• 索引
• 科: データの組み合わせ
• 和名：フィールドが存在しない
• 数値によるグループ化
• フィールドの欠落
• フィールド名の複製
• 16以上のレコード
• データ型
• 切り捨て
• データフォーマットの問題
• ワイド文字列の変換
• 値とデータ型の不適合：既存の値
• 計算
• 値とデータ型の不適合：計算した値
• 値とデータ型の不適合：計算した値（違和感のあるバージョン）
• 0で除算
• データパースの問題
• 変換で情報が失われる
• データ入力
• コードページの問題
• CSVの引用符の問題
• まとめ

画像：Look out for those warnings!（あの警告に注意しろ！）

科: データの組み合わせ

和名：フィールドが存在しない

学名： agrum non praesens

属名：警告

生息地：ユニオン

例文：ユニオン (55): フィールド "Field7" すべての入力には存在しません。

防止策： 全体的として、データ入力時に不必要なフィールドは即座に削除することを推奨します。具体的には、データ入力ツールのあとにセレクトツールを追加し、すぐに必要ではないフィールドはすべて選択を解除します。また、「動的または不明な列」（Unknown）の選択も必ず外してください。

これにより、データの整理、ワークフローの実行速度の向上、監査とデータプライバシーの保護が促進され、すべての必須フィールドが存在するかどうかの検証を容易にし、最終的にユニオンツールから発生する多くの警告を防ぐことができます。不要なフィールドをすべて取り除いたら、残りのユニオンの警告を評価できるようになります。

残りのユニオンの警告を評価する：

ユニオンツールの入力の違いが１～６つのフィールドしかない場合、事前にそれらのフィールドを削除するか、ユニオンする前にそれらのフィールドをNull（もしくは0か他の値）で追加し「初期化」してください。これらのフィールドが変更された場合、ユニオンツールから意味のある警告を受け取ることができるようになります。いずれにせよ、ユニオンツールは欠落しているフィールドにNullを挿入するため、出力するデータセットを変更することはありません。

これらのフィールドを初期化するために、CReW Macroの「Ensure Fields」マクロを使用したり、ユニオンにテキスト入力ツールを追加したり、以下に示すようなフォーミュラツールにNull値を設定して追加したり、その他動的なデザインパターンを使用することができます。

ユニオンの入力において、大幅かつ定期的な変更が予想される場合、フィールドが異なるときのユニオンツールの挙動を「無視」に設定することを許容する場合もあります。列内の制御されていないNull値が本当に問題にならない場合にのみ、最後の手段としてこれを使用することをお勧めします。

私は本番のワークフローでは「手動でフィールドを設定」や「位置による自動設定」の設定を使用することは全くお勧めしません。

数値によるグループ化

学名：coetus numero

属名：警告

生息地：集計、結合

例文：集計 (65): DoubleまたはFloatのGroup Bysは、丸め誤差のために推奨されません。

結合 (83): 丸め誤差のため、Double または Float の結合は推奨されません。

防止策：結合キーやグループ化の項目に数値フィールドを指定する場合、グループ化や結合を行う前にセレクトツールを用いてデータ型をInt64（整数の場合）やFixedDecimal（小数の場合）にします。FixedDecimalのサイズの設定にある「小数点以下」の部分は「スケール」と呼ばれますが、これはデータに含まれる小数点以下の桁数を示します。このスケールは完全にカスタム可能なので、実際のデータに合わせて選択してください。さらなる情報はこちら。

フィールドの欠落

学名：absentis columna

属名：警告

生息地：セレクト機能のインターフェースを持つツール（セレクト、結合、フィールド付加など）と「グループ化」機能を持つツール（転置、クロスタブ、サンプリング、複数フィールドフォーミュラなど）

例文：セレクト (91): フィールド "Field5" が欠落しています。入力ストリームとツール設定を比較してください。

防止策：ベストプラクティスとしては、データを読み込む際は、入力されたフィールドを本当に必要なものにすぐに絞り込むことです。具体的には、データ入力ツールのあとにセレクトツールを配置し、すぐに必要ではないフィールドはすべて選択を解除します。また、動的または不明な列である「Unknown」も必ず選択を解除してください。

これが不可能なときは、動的セレクトツールを使って動的にフィールドを削除または含めることができます。例えば、フィールド名が「Right_」や「Field_」で始まるものを削除できます。もしくは、データクレンジングツールで、中身がすべて空のフィールドを削除することを検討してください。

警告が発生した場合、それらを消去するには：

• セレクトもしくはセレクトのインターフェースを持つツール：「オプション」→「すべての欠落している列を忘れる」

• 「グループ化」機能：警告が表示されたら各ツールをクリックします。ツールをクリックすることで、現在のメタデータで設定がリセットされます。列のメタデータが流れていることを確認するように注意してください、そうしないとツール内の設定が誤って消去されてしまいます。

フィールド名の複製

学名：duplicata nomina

属名：警告

生息地：セレクト、結合、データ入力、列分割、日時など、フィールド名を変更するその他のツール

例文：セレクト (73): "Field6" という名前が付いた複数のフィールドがありました。複製の名前が変更されました。

防止策：できるだけ早い段階で、競合するフィールドの選択を解除するか、データとして必要であれば名前を変更します。

以下のスクリーンショットでは、「Field6 v2」を「Field6」にリネームすると、もともとあった「Field6」と競合が発生しました。これを修正するためには、もともとあった「Field6」の選択を解除するか、もしくは「Field6 v2」を「Field6」以外の別の名前に変更します。

16以上のレコード

学名：tot ordines

属名：警告

生息地：フィールド付加、複数結合

例文：フィールド付加 (105): ソースに16以上のレコードがありました。

防止策：ターゲットアンカー（Tアンカー）に接続されたデータの行数が、Sアンカーに接続されたデータの行数より大きいことを確認します。私がフィールド付加ツールを使う場合は、1～3の新しい行を「乗算」するときだけです。この場合のように、ソースアンカー（Sアンカー）に接続したデータが16レコード以下であれば、このエラーは起きません。

あるいは、どうしてもデータをかけ合わせたいときは、フィールド付加ツールの設定を「すべての付加を許可する」にしてください。

似たようなオプションは複数結合ツールにもありますが、多次元結合を使う時は最新の注意を払うことを推奨します。これはコンピュータやデータベース、Alteryx Serverを簡単にクラッシュさせる方法です。正直なところ、私は追加の結合キーとして、単純な連続した整数のフィールド（Record IDのような）を割り当てることを好みます。これは、より制御されたクロス結合を実行することができます。

つまり、自分が行おうとしていることを理解し、適切な制限を設け、問題が発生したときに対処する意思を持つときだけすべての多次元結合を許可してください。

データ型

切り捨て

学名：truncatum

属名：フィールド変換エラー

生息地：データ入力、セレクト、その他フィールドサイズを変更するツール

例文：データ入力 (1): フィールド "Field1" はレコード#3で切り捨てられました

セレクト (119): Field1: "3.1415926535 8979323846 2643383279 5028841971 6939937510 5820974944 5923078164 0628620899 8628034825..." は切り捨てられました

防止策：­セレクトツールもしくはデータ入力ツールでフィールド長（サイズ）を増やします。

データ入力ツールではオプションの７番目にある「フィールド長」を変更します。

セレクトツールでは「サイズ」を変更します。

データフォーマットの問題

学名：non validum diem

属名：フィールド変換エラー

生息地：セレクト、その他フィールド型を変更するツール

例文：セレクト (38): Field8: "9/2/2024" は有効な Date ではありません

防止策：フィールド型を日時型に変更する前に、日時ツールや数式のDateTimeParse()関数を使い、日時の文字列を適切なISO-8601（YYYY-MM-DD）の形式に変更します。複数フィールドフォーミュラツールを使えば、この一連の手順を一つのツールで実行可能です。私は日時ツールの代わりにDateTimeParse()関数を使うことを好むため、DateTimeの仕様のドキュメントのページをブックマークしています。

ワイド文字列の変換

学名：mores conversionem

属名：フィールド変換エラー

生息地：データ入力、動的入力、セレクト、その他フィールド型を変更するツール

例文：セレクト (15): Field1: "羅 馬 書 5:8" は完全にはWStringからStringに変換できませんでした。

防止策：フィールドがV_WStringかWStringのいずれかのWタイプ文字列のままであることを確認してください。「W」は「Wide」の略で、Unicode文字列に適合することを意味します。詳細についてはこちらをごらんください。

「強制」オプションが表示される場合は、すでにフィールドが「V_WString」であることを意味します。「V_WString：強制」は、入力されたデータが別のデータ型に自動的に構成された場合でもV_WString設定を維持します。これが頻繁にクリックされるセレクトツールの場合、データ型が変更されるときに注意してください。メタデータが更新されたあとにツールをクリックすると、「強制」に設定したデータ型などの特定の設定が元に戻ることがあります。

値とデータ型の不適合：既存の値

学名：valorem non congruit

属名：フィールド変換エラー

生息地：セレクト、複数フィールドフォーミュラ、その他フィールド型を変更するツール

例文：セレクト (40): Field3: N/A 数字ではありません。

複数フィールドフォーミュラ (100): Field4: $44 有効な番号ではありません。

防止策：数式を使って問題のある値を修正してからデータ型を変更します。Replace()関数やIF文、正規表現やその他の様々な関数が使えます。それぞれの方法には長所と短所があります。

計算

値とデータ型の不適合：計算した値

学名：calculus non congruit

属名：警告、エラー

生息地：フォーミュラ、複数行フォーミュラ、複数フィールドフォーミュラ

例文：複数フィールドフォーミュラ (97): 式"Field4" は文字列になりましたが、フィールドは数値です。これが正しい場合は、ToNumber(...) を使用します。

防止策：既存の数式をToNumber()関数やToString()関数などの変換関数で囲みます。

もしくは、複数フィールドフォーミュラツールを使っている場合は、出力データ型を互換性のある型に変更します。この例では、Double型のような数値型の代わりにV_Stringなどの文字列型を使っています。

値とデータ型の不適合：計算した値（違和感のあるバージョン）

学名：versio subdola

属名：警告

生息地：複数フィールドフォーミュラ、複数行フォーミュラ

例文：複数フィールドフォーミュラ (111): 式 "Field4" はintegerとなりましたがフィールドは数値です。

防止策：理論的には、整数は当然数値です。だから私はこの警告に違和感を覚えます。小数値と整数値を考慮すると、Designerにとっては明らかに根本的な違いがあるということなのでしょう。

この警告を抑制するためには、整数値を小数に変換します。私はたいてい最終的な値を1.00でかけ算するか、Round([Column], 0.01)という数式を使います。

0で除算

学名：divide a nulla

属名：警告*

生息地：フォーミュラ、複数フィールドフォーミュラ、複数行フォーミュラ、フィルターなど数式エディタを持つツール

*フィルターツールでは、警告ではなくエラーになります

例文：フォーミュラ (23): フィールドのレコード#1で0で割るエラー Result

防止策：問題のある式をIF文で囲み、分母が0ではないときのみ割り算を行うようにします。これでエラーが回避できます。

データパースの問題

学名：errat identitatis

属名：フィールド変換エラー

生息地：DateTimeParse() 関数

例文：フォーミュラ (25): DateTimeParse: "N/A" を "%m/%d/%Y" の日時形式および言語 "English" に変換できません: 月 で予期された番号: 'N/A'

フォーミュラ (25): DateTimeParse: "2024-09-08" を "%m/%d/%Y" の日時形式および言語 "English" に変換できません: 月の数値が1..12の範囲外です: '2024-09-08'

フォーミュラ (25): DateTimeParse: "09/01/0000" を "%m/%d/%Y" の日時形式および言語 "English" に変換できません: 年番号が1400..9999の範囲外です: '0000'

防止策：上の例文では、設定した日時の指定子とデータの文字列の実際の形式が一致していないということです。指定子「%m/%d/%Y」は「10/12/2024」のようなデータを想定しています。このため、エラーメッセージではメッセージの最後に文字列全体が表示されます。単純なケースでは、できることは指定子と入力文字列が一致しているか確認することだけです。

複数のパターンが混在するような複雑な場合でも、予防は可能です。最も良いシナリオでは、ソースデータまたはデータ入力システムでデータ検証プロセスを作成し、データが到着した時にはすでに標準化されているようにします。

ソースレベルでの防止が不可能な場合は、正規表現を使ったIF文でDateTimeParse()関数を囲み、パースを適用する前にパターンを評価することができます。

これはmm/dd/yyyyかdd/mm/yyyyのどちらが良いか、パターンを評価する例です：\d{1,2}\/\d{1,2}\/\d{4}

この正規表現は、1桁か2桁の0～9の数値、それに続くスラッシュ（/）、次に1桁か2桁の数値、さらにスラッシュ（/）、最後に4桁の数値というパターンに一致します。正規表現のパターンについてさらに詳しく知りたい場合は、AIやLLMが正規表現のパターンをわかりやすい言葉にしてくれます。

変換で情報が失われる

学名：pereunt translatione

属名：フィールド変換エラー

生息地：フォーミュラ、複数行フォーミュラ、複数フィールドフォーミュラ

例文：複数フィールドフォーミュラ (101): TONUMBER: $5550.00 変換で情報を失いました

複数フィールドフォーミュラ (99): Field5: 5,550はコンマの変換を停止しました。無効である可能性があります。

防止策：互換性のない値により、この変換エラーが発生します。これを防止するためには、データ型を変更する前に問題のある値を修正します。Replace()関数、IF文、正規表現、その他の様々な関数を使うことができます。それぞれの方法には長所・短所があります。

数式の途中でデータ型を変更する場合、修正部分（ReplaceChar関数など）は変換関数（ToNumber関数など）内にネストする必要があります。以下の例をごらんください。

データ入力

コードページの問題

学名：ineptias ostendit

属名：エラーとして表示されない破壊的なフィールド変換の問題

生息地：データ入力、動的入力

例文：（エラー・警告などは発生しません）日本語、アクセント付き文字や英語以外の文字の代わりに意味不明な謎の文字が表示されます

防止策：データ入力ツールのコードページを適切なコードページ（日本語Shift-JISもしくはUTF-8など、データソースに応じた適したもの）に変更します。レアケースではありますが（文字コードが日本語Shift-JISのShapeファイルなど）、適合するコードページが選択できない場合は、読み込み後にConvertFromCodePage()関数を使って文字コードの変換を行う必要があります。

CSVの引用符の問題

学名：apostrophe fallor

属名：警告、エラー

生息地：データ入力、動的入力

例文：データ入力 (113): レコード#4: エスケープされていない引用符が見つかりました。

データ入力 (113): レコード#4: CSVファイル: フィールドにレコードの終了引用符がありませんでした 4

防止策：これらはCSVファイルの作成方法に大きく依存するため、扱いが難しい問題です。余分な区切り文字の周りのエスケープ文字の種類を変更するだけで修正できることもあります。こちらの例では、データ入力ツールのオプションの９番目を「引用符」から「一重引用符」に変更することで警告を完全に出ないようにできます。このオプションを実際のCSVで試してみて、これらの構成のどれがうまく動作するか確認してください。

上の方法でうまくいかない場合、警告を抑制する唯一の方法は、CSVを作成するプロセスを修正することです。もし事前のプロセスがAlteryx内のプロセスであれば、データ出力ツールの「出力フィールドを引用」設定が「自動」か「常時」にセットされていることを確認してください。

事前のプロセスがAlteryxではないが、設定やコードにアクセスできる場合、出力フィールドの引用符のオプションや区切り文字のエスケープなど似たような設定を確認します。

もし警告の代わりに「終了引用符がありませんでした」というエラーが出た場合、データ入力ツールのオプションの５番目にある区切り記号を調整する必要があるかもしれません。また、読み取りのみが必要で、データの欠損を気にしない場合、オプションの10番目のチェックボックスをチェックし、エラーを強制的に警告に変更できます。

すべての試みが失敗した場合、私のいつもの最後の手段は、CSVを区切り記号なしのデータとして読み込み、列に分割するか、自力で解析することです。オプションの５番目を「\0」に変更し（これは区切り記号を使わないという意味です）、オプションの６番目の選択を解除します（これは、ヘッダーを列名として扱わず、先頭行を値として扱うということです）。これによりすべての入力データは一つの列として読み込まれるため、読み込み後にその他のツールを使って列に分割することができます。

まとめ

おめでとうございます。これで警告と変換エラーのフィールドガイドを読み終えました。私はこれが現場で遭遇する最も一般的な警告と変換エラーを防止するための力となると信じています。これらの警告を防止することで結果ログが綺麗になり、これによってあなたの作成したデータ処理で新しい問題が発生したとしても、すぐにわかるようになる、ということを覚えておいてください。

より良いワークフロー構築に関心がある場合、ワークフローの最適化テクニック（一般化、スケーラビリティ、保守性）について学び、カスタム検証やワークフローイベントなどのデータ処理アラートの世界に飛び込むことをお勧めします。これらの強力なデザインパターンを使用すると、ワークフローが失敗するタイミングとその理由、そしてワークフローがユーザーに通知する方法を制御できるようになります。

整理された結果ログと、より優れたワークフローを実現しましょう！🥂