Alteryxワークフローを移行する

PlaidCloudは、Alteryxのワークフロー、分析アプリ、マクロを、PlaidCloudでレビュー、スケジュール、パラメーター化、実行できる高度なワークフローに変換します。インポーターは、ワークフローのグラフを保持し、参照されているファイルをドキュメントにアップロードし、必要に応じてマクロワークフローを作成し、ツールをネイティブのワークフローステップまたはマネージドジョブエグゼキューターにマッピングします。

このガイドは、単一のワークフロー、関連するワークフローのグループ、またはAlteryxの大規模なポートフォリオ全体をPlaidCloudに移行する際にご利用ください。

PlaidCloudが作成するもの

PlaidCloudは、Alteryxの設計から実行可能な高度なワークフローを作成します。

ワークフローのツールは、元の上流と下流の関係が維持されたPlaidCloudのワークフローステップになります。
Alteryxのマクロは、明示的なマクロ入力とマクロ出力を持つPlaidCloudのマクロワークフローになります。
分析アプリの質問は、実行前にユーザーが設定できる管理された変数になります。
入力ファイル、出力ファイル、空間データのサイドカーファイル、画像、PDF、生成された成果物は、インポート時に選択したパスのドキュメントに保存されます。
アシストモデリング（機械学習）のパイプラインは、ネイティブのML: モデルの学習およびML: スコアリングのワークフローステップになります。
あいまい一致、空間処理、PDF抽出、OCR、NLP、レポート作成などの高度な操作は、ネイティブのSQLやワークフロー操作が最適でない場合に、PlaidCloudのマネージドジョブエグゼキューターで実行されます。
コメントボックスとツールコンテナーは、ワークフローキャンバス上にノート、ハイライトボックス、グループとして取り込まれます。元のワークフローで果たしていた説明の役割をそのまま果たし、実行時の処理は追加されません。
Browseなどの表示専用オブジェクトは、ステップではなくキャンバスの一部として取り込まれるため、実行時の処理は追加されません。すべてのステップの出力テーブルは、すでに確認できる状態にあります。

始める前に

インポートする前に、ワークフローファイルと依存関係をまとめて用意します。

Alteryxのワークフロー、アプリ、マクロのファイル（.yxmd、.yxwz、.yxmc）を含めます。
CSV、Excel、Access、YXDB、XML、JSON、データベース抽出などの入力データファイルを含めます。
空間データのサイドカーファイルをまとめて含めます。たとえば、シェープファイルのグループとMapInfoファイルは同じフォルダーに置いてください。
画像、PDF、マップレイヤー、テンプレートなどのレポート用アセットを含めます。
変換したワークフローを作成するPlaidCloudプロジェクトを選択します。
PlaidCloudがインポートしたファイルをアップロードするドキュメントアカウントとフォルダーを選択します。
この移行に必要なのが構造の検証のみか、出力パリティの検証かを決めます。

ワークフローをインポートする

PlaidCloudでターゲットのプロジェクトを開きます。
Tools → Alteryxワークフローをインポートを開きます。
ターゲットのプロジェクトを選択し、インポートする.yxmd、.yxwz、または.yxmcファイルを選択します。
必要に応じて、ワークフロー、ステップ、テーブル名のプレフィックスを設定します。テーブル名にはすでにワークフロー自身の名前がプレフィックスとして付いています。以下の変換後のワークフローのテーブル名を参照してください。
インポートしたファイルを保存するドキュメントアカウントとフォルダーを選択します。
ワークフローが実行時に必要とする、参照されるファイルまたはフォルダーを追加します。
インポートを開始します。
問題なくインポートされた場合、ウィンドウは自動的に閉じ、生成された高度なワークフローが開きます。手動で閉じる必要はありません。確認が必要な項目は、インポートを妨げることなく、後からトースト通知として表示されます。
変換されなかったステップがある場合、ワークフローが読み取るファイルが見つからない場合、またはその他の確認が必要な問題がある場合は、ウィンドウが開いたままになり、続行する前に確認できるよう変換レポートが表示されます。

確認が必要なステップ（削除された、または変換されなかったツール）がある場合、インポートウィンドウはフォームの代わりに変換レポートを表示します。レポートには、高い信頼度でマッピングされたステップ数と確認が必要なステップ数の概要、および信頼度の低いステップや注意事項のあるステップを、ステップ名、操作、信頼度、メモとともに一覧にしたテーブルが含まれます。ワークフローを実行する前に、確認すべきステップへすぐに移動できます。これらのステップには、キャンバス上のステップメモにも同じ信頼度のメモが付きます。

PlaidCloudは、インポート時に選択したドキュメントの場所にインポートした依存関係を保存します。変換されたステップはそれらのドキュメントのパスを参照するため、ワークフローはデスクトップのファイルシステムに依存せずに繰り返し実行できます。

見つからないファイル

ワークフローが読み取るファイルが見つからない（たとえば、アップロードされなかったネットワーク共有のパス）場合でも、インポートが失敗することはなくなりました。ワークフローは引き続き変換され、変換レポートには見つからないファイルごとに次の情報が一覧表示されます。

ファイルのアップロード先となるドキュメントのパス。
ファイルの読み取り元だった元のAlteryxのパス。
ワークフローがそのファイルに期待するシート。
そのファイルを読み取るAlteryxのツール。

ほとんどのファイルは、レポートに記載されたパスにアップロードしてワークフローを再実行するだけで済み、再インポートは不要です。ごく一部の種類の見つからないファイルは、実行時ではなく変換時に読み取られるため、ファイルを配置した後にワークフローを再度インポートするようレポートに表示されます。AlteryxのフラットASCIIレイアウトファイル、ワイルドカード入力、Dynamic Inputのテンプレート、FirstRowのリネーム元がこのグループに該当します。

オフになっているツールコンテナー内のツールだけが読み取るファイルは、この一覧には表示されず、ドキュメントにコピーされることもありません。そのようなツールはそもそもインポートされないため（キャンバス上のコメントとツールコンテナーを参照）、変換後のワークフローにはそのファイルを必要とするステップがありません。そのファイルも取り込むには、Alteryxでコンテナーをオンにするか、オフのコンテナー内のツールを通常のステップとして取り込むオプションを指定してインポートしてください。

ワークフロー内のその他の問題（PlaidCloudが読み取れないマクロやフラットファイルのレイアウト、ターゲットパスに異なる内容ですでに存在するファイル、変換できないツールなど）は、インポート全体を失敗させるのではなく、該当する1つのステップに警告を付けます。そのため、ワークフローの残りの部分は引き続き取り込まれます。

インポートが拒否される場合

アップロードしたファイルをまったく変換できない場合、部分的な結果を出力せず、インポートは即座に拒否され、エラーメッセージで対処方法が示されます。これは、ファイルがAlteryxのワークフローではない場合、Alteryxパッケージ（.yxzp）の場合（この場合はAlteryx Designerから.yxmdワークフローをエクスポートし、使用するファイルとともにアップロードしてください）、ワークフローファイルが見つからないか読み取り権限がない場合、または必要なテーブル名がインポートだけでは解決できない形で衝突する場合に発生します。

コンバーター自体がワークフローの処理中に内部の不具合に遭遇した場合、不具合を示すメッセージとともにインポートが拒否されます。「PlaidCloud could not convert this workflow because of a converter defect (<error>). It has been logged for the PlaidCloud team; include the request ID when you contact support.」この場合、お客様のファイルに問題はありません。メッセージに記載されたリクエストIDを添えてサポートにお問い合わせください。ログに記録された障害をチームが確認します。

変換後のワークフローのテーブル名

変換された各ステップは、元になったAlteryxのツールにちなんだ名前（ツール4であればtool_4_out）の専用テーブルに書き込みます。Alteryxではツールの番号がファイルごとに付けられるため、これらの名前はワークフロー間で重複し、PlaidCloudのプロジェクトは単一のテーブル名前空間です。そのため、インポートのたびに、テーブルにはワークフロー自身の名前がプレフィックスとして付き、03_measure_the_quality_of_data_tool_4_outのような名前になります。これにより、Alteryxのワークフローが入ったフォルダー全体を、互いの結果を上書きすることなく1つのプロジェクトにインポートできます。

2つのインポートを区別できるのは、ワークフロー名だけです。同じ名前のファイル、または句読点やスペースだけが異なる名前（Sales ReportとSales-Reportなど）のファイルは同じプレフィックスになります。名前を持たないファイルも同様です。これらをインポートするときは、テーブル名のプレフィックスを自分で設定するか、別々のプロジェクトにインポートしてください。

これらのインポートが互いに上書きし合うことはなくなりました。プロジェクトにすでに存在するテーブル名を要求したインポートには、-duplicate-のサフィックスが付いた専用のテーブルが作成され、そのステップはそのテーブルを使用します。各インポートはそれぞれの結果を保持しますが、2つ目のインポートのテーブル名は読みにくくなるため、独自のプレフィックスを設定することをお勧めします。

同じワークフローを2回インポートした場合（最初のインポートの修正が必要になったときなど）も同様に動作します。2回目のインポートでは、最初のテーブルを上書きするのではなく、独自のテーブルセットが作成されます。新しいインポートに問題がなければ、以前のインポートのワークフローとテーブルを削除してください。

インポート時に独自のテーブル名のプレフィックスを設定するとデフォルトを上書きでき、何も設定しない場合は、プレフィックスなしのtool_4_out形式の名前に戻ります。変換されたステップ自体を除き、これらの名前に依存するものはありません。そのため、後でテーブルの名前を変更した場合は、そのテーブルを読み取るステップの参照先を設定し直す必要があります。

Parquetとして書き込まれる出力

.parquetまたは.avroに書き込むOutput Dataツールは、その形式のエクスポートステップに変換されます。.yxdb、.hyper、.dbfに書き込むものはParquetとして書き込まれます。.yxdb出力の場合、ファイルは同じフォルダー内の同名の.parquetになります。

その.yxdbファイルを読み取る変換後のワークフローは、自動的に.parquetを読み取ります。Alteryx YXDBのインポートステップは、.yxdbが存在しない場合に同名の.parquetにフォールバックし、その旨を示す警告を表示します。

キャンバス上のコメントとツールコンテナー

Alteryxの作成者が作業の周囲に描いたノートとグループも、そのまま取り込まれます。

テキストを含むコメントボックスは、描かれた位置とサイズのまま、キャンバス上のノートになります。
ツールのまとまりを囲む空のアウトラインとして描かれたコメントボックスは、ハイライトボックスになります。これはAlteryxで果たしていた役割そのものです。
リンクされたドキュメントを表示するコメントボックスは、リンクをテキストとして保持します。
ツールコンテナーは、その内側に描かれていたステップを含むグループになり、キャプション、折りたたまれていたかどうか、オフになっていたかどうかが保持されます。入れ子のコンテナーは入れ子のグループとして取り込まれ、両方に含まれるステップは両方のグループに属します。

これらは、自分で描いたものと同じ方法で、移動、編集、色変更、削除ができます。

元のワークフローとは動作が異なる点が2つあります。

オフになっているツールコンテナー内のツールは、まったくインポートされません。 Alteryxでも実行されないため、インポートすると何もしないステップがワークフローに加わってしまいます。コンテナー自体は、キャプションを持つハイライトボックスとして取り込まれるため、何があったかを確認できます。そのツールを取り込むには、Alteryxでコンテナーをオンにして、もう一度インポートしてください。（APIまたはAIエージェント経由でのインポートでは、無効なコンテナー内のツールを実行可能な通常のステップとして取り込むオプションも指定できます。すべてがオフの状態で提供されるサンプルワークフローに便利です。）
ボックスの色は引き継がれません。 キャンバスで使用できる色は6色の固定セットであり、Alteryxのボックスはほとんどが白かグレーのため、すべてが同じ色合いで取り込まれてしまいます。代わりにキャンバスのデフォルトで取り込まれるため、右クリックメニューから好みの色を設定してください。

ノートのテキストは、ニュートラルなグレーで表示されるようになりました。以前は、暗いキャンバス上でアンバー（オレンジ）色で表示されていました。Alteryxからそのまま取り込まれた何の変哲もないコメントであっても、警告のように見える色でした。

ステップをまったく含まないツールコンテナー（オフになっていた、またはコメントしか含まれていなかったなど）も、消えることなく、キャプションを持つハイライトボックスとして表示されます。

コメントだけで構成されたワークフロー（ツールがなく、ドキュメントだけのページ）は、それらのコメントを含むキャンバスとしてインポートされ、実行可能なステップには変換されなかったことが示されます。実行するものがなかったことを正確に示す結果であり、失敗ではありません。

Control Container

AlteryxのControl Containerは、Control入力に接続されたストリームにレコードがある場合にのみ、内部のツールを実行します。このゲートは、コンテナーのアウトラインだけでなく、コンテナーとともに取り込まれます。

コンテナーは、他のコンテナーと同様にキャンバス上のグループになり、キャプションと内容が保持されます。
内部にあったすべてのステップは、ゲートされたデータに行がある場合にのみ実行され、ない場合はスキップされるように設定された状態でインポートされます。内部に入れ子になったコンテナー内のステップにも同様にゲートが設定されます。条件を自分で接続する必要はありません。
Control入力に何も接続されていないControl Containerは、視覚的なグループ化にすぎなかったため、Tool Containerとまったく同じように変換されます。
何も囲んでいないControl Containerは、ハイライトボックスとしてキャプションがキャンバス上に保持されます。

Control入力に接続されたツールがテスト対象となるデータを生成せず、ゲートを構築する元がない場合があります。インポートは、これを黙って見過ごすことはなくなりました。コンテナーは変換されなかったステップとして取り込まれ、内部のツールがそのままでは毎回実行されることを示すメモが付きます。また、対処が必要なステップとして変換レポートに一覧表示されます。このステップはワークフローがそこに到達した時点で失敗するため、何も問題がないかのように変換結果をそのまま実行することはできません。

以前は、内部が無条件に実行されるようにインポートされ、キャンバス上でそれを示すものは何もありませんでした。これは同じ問題の目立たない形でした。

解決するには、Control入力がデータを生成するツールから接続されるようにAlteryxのワークフローを変更して、もう一度インポートするか、フラグが付いたステップを削除して、コンテナー内にあったステップにゲートを自分で設定してください。ステップの条件を参照してください。

Browseツール

AlteryxのBrowseは表示用のツールです。到達したレコードを表示するだけで、何も変更せず、出力コネクターもありません。PlaidCloudでは、すべてのステップの出力テーブルをそのまま開けるため、作成者がBrowseを置いた目的は、上流のステップからワンクリックで実現できます。そのステップを選択して、テーブルを確認してください。

そのため、Browseはステップではなくキャンバスの一部として取り込まれます。ステップは作成されず、テーブルも確保されず、コンバーターが処理できなかったツールとしても数えられません。

Browseのためのテーブルは作成されません。 以前は、各Browseが何もしないステップになり、ワークフローの構築時に破棄されていましたが、何も書き込まず、何も読み取らない専用のウェアハウステーブルを確保していました。179件のAlteryxリファレンスワークフローセット全体で、これは152個のテーブルに相当しました。
壊れたブランチは、問題の原因となったツールに対して1回だけ報告されます。 以前は、Browseに入力を供給するツールが変換に失敗するたびに、そのBrowseも変換に失敗したツールとして変換レポートに表示されていたため、同じ問題が2回、つまり実際に修正が必要なツールと、実行できるはずのない表示ツールの両方に対して表示されていました。このリファレンスセットで報告された失敗のうち14件がこの種のものでした。これらのエントリはなくなり、実際に原因となったツールは引き続き報告されます。

これにより、変換レポートから誤解を招くエントリが削除されますが、その背後にある失敗が削除されるわけではありません。すべてのツールが変換されて変換されるワークフローの数は、以前と同じです。

これまで実行されていたのに停止するようになったワークフローの形が1つあります。これは新たな不具合ではなく、修正の結果です。

マクロ内のツールの番号が、それを呼び出すキャンバス上のツールと同じ番号になっているワークフローでは、マクロの下のステップが、マクロ自身の出力ではなくBrowseのテーブル名に解決されていました。そのようなワークフローを再インポートすると、そのステップは存在しないテーブルを名指しして停止するようになります。

そのステップがBrowseのレコードを読み取ったことはありませんでした。そのテーブルはインポート時に作成された後、何にも書き込まれませんでした（Browse自体はワークフローの構築前に削除されていました）。そのため、ステップは空のテーブルを読み取り、実行はレコードを1件も処理しないまま成功と報告していました。生成された数値は何もないところから出たものであり、それを示すものは何もありませんでした。テーブルが作成されなくなったため、ステップはそのことを明示するようになりました。

修復方法: そのステップの参照先を、本来読み取るはずだったテーブル（上にあるマクロステップの出力）に設定し直して、ワークフローをもう一度実行してください。

このリリース以前にインポートしたワークフローは、テーブルを含め、それまでの変換結果のまま残ります。この変更を反映するには、もう一度インポートしてください。

Calgaryデータベース

AlteryxのCalgaryデータベース（.cydbファイル）は、独自形式のインデックス付きストアです。PlaidCloudにはこのファイル形式を読み取る方法がなく、公開された仕様もありません。そのため、それに触れるツールをすべて拒否するのではなく、変換では各.cydbパスを、インポートが適用するテーブルプレフィックスの下のcalgary_<database name>という名前の、PlaidCloudの通常のテーブル1つに対応するものとして扱います。データベースが通常のテーブルになると、それを中心に構築されたツールは通常の操作になります。保存されたクエリはフィルター、クロスカウントのバケットは条件付きカウント、ローダーのフィールドリストは列のセットになります。

変換されたCalgary Loaderは、その入力からそのテーブルを書き込みます。宣言されたインデックスタイプは変換時に削除されますが（ウェアハウスが独自にインデックスを作成するため）、フィールドリストは引き継がれます。
変換されたCalgary Inputは、保存されたクエリをフィルターとして適用してテーブルを読み戻します。ワークフローファイルにはデータベースの内容が記録されていないため、テーブル自体の列はステップの実行時に解決されます。
変換されたCalgary Input (Count Only)またはCalgary Cross Countは、テーブルを集計として読み取ります。通常のインデックス付きフィールドが行をグループ化し、カスタムフィールドの名前付き値のそれぞれが1つのカウント列になります。
変換されたCalgary Joinは、受信する各レコードをテーブルと照合し、一致したレコードを保持して、入力自身の列を引き継ぎます。受信フィールドが空間ではない通常の値である場合に変換されます。そうでない場合については、以下のCalgary JoinとCross Count Appendを参照してください。
変換されたCalgary Cross Count Appendは、同様に受信する各レコードをテーブルと照合し、一致したデータベースレコードの数を入力に追加して報告します。こちらも、受信フィールドが空間ではない通常の値である場合に変換されます。

自分で構築していないデータベースを読み取るワークフローでは、テーブルを名指しして停止するステップが作成されます。 Alteryxが提供する人口統計や参照用の.cydbファイルが典型的な例です。ワークフロー内にそれらを書き込むものがないため、読み取れるPlaidCloudのテーブルはまだありません。そのテーブルが存在するまで、変換されたステップは、何も読み取らずに成功と報告するのではなく、停止してそのテーブルを名指しします。ワークフローを実行する前に、元の.cydbから（読み取れるAlteryxが利用できる場合）、またはデータが実際にある場所から、指定されたテーブルにソースデータをエクスポートしてください。

Calgaryクエリにおけるor、and、not

Calgaryクエリは、データベースのインデックス付きフィールドに対するAnd、Or、Notのツリーであり、このツリーは記述されたとおりに変換されるようになりました。ツリー内のどこにあるOrも、複数の条件を囲むNotも変換されます。contains（含む）またはstarts-with（で始まる）の条件も変換され、カウントパスではSQLのLIKE、レコードの読み取りでは部分文字列一致になります。これは、Calgary Inputのレコード読み取り、カウントのみの読み取り、Calgary Cross Count、およびCross Countのカスタムフィールド内のバケットに適用されます。

一部のクエリ形式は引き続き変換されず、それぞれが変換レポートとステップ上で自らを示します。

列の比較ではなく空間検索（または否定のcontains/starts-with）を使用するクエリ。列レベルに相当するものがないインデックス操作です。
Skip RecordsまたはMax Recordsで制限された読み取り。代替テーブルにはスキップや上限の基準となるレコード順序がありません。
複数のカスタムフィールドでグループ化されたCross Count。カウントは実際にはデータベース全体に対する1つの集計ですが、Alteryxは結果の列の名前や順序を文書化しておらず、確認できる例もありません。
カウント対象の列が指定されていないカウントのみの読み取り。データベース自身の列は、ワークフローファイルから読み取れないためです。
データフィールドを1つも保存しないCalgary Loader。列のないテーブルが書き込まれてしまいます。
データベースをまったく指定していないCalgaryツール。

Calgary JoinとCross Count Append

Calgary JoinとCalgary Cross Count Appendは、受信するすべてのレコードをデータベースのインデックスを通じて照合しますが、ワークフローファイルにはインデックスの名前は記録されていても種類は記録されていません。同じ設定が、インデックスが通常の値を保持している場合は等価結合を意味し、空間ジオメトリを保持している場合は「どのポイントがこの図形の内側にあるか」という照合を意味します。ファイルからは、どちらかを判別する方法がありません。

変換は、受信フィールド自身の宣言された型を使って判断します。空間インデックスは空間フィールドとしか組み合わされ得ないためです。

空間オブジェクトとして型指定された受信フィールドは停止し、フィールド名、導き出された解釈、Spatial Matchステップとして照合を再構築する際の代替テーブルを示します。
型を判別できなかった受信フィールドは停止し、その理由を示します。推測することはありません。
空間ではない通常の受信フィールドは変換され、代替テーブルと照合されます。

どの結果になる場合でも、ステップには採用した解釈と、その解釈の根拠としたフィールドの型が記録されるため、納得できない変換でも、推測する必要はなく、その過程を確認できます。

Calgary Cross Count Appendは、空間ではない通常の受信フィールドで変換されます（Calgary Joinと同様）。Joinが一致したレコードを保持するのに対し、Appendは各入力レコードが一致したデータベースレコードの数を報告します。入力レコードごとに一致数を数え、そのカウントを入力に追加します。何にも一致しなかった入力レコードは、除外されずにカウント0になり、同一の入力レコードが2つあっても、それぞれが専用の行を保持します。カウントは値の異なる組み合わせごとではなく、レコードごとです。単一の通常のクロスカウントフィールドはこのように変換されますが、名前付きのカスタム値のグリッドは変換されません。値ごとに1つのカウント列が追加されることになり、Alteryxはその列数も名前も文書化していないためです。

Count Onlyモードのcalgary Joinも同様に変換されます。一致したレコードを保持するのではなく、入力レコードごとに一致したデータベースレコードの数を数え、何にも一致しないレコードは0とします。

Calgary JoinまたはCross Count Appendは、単一のインデックス値ではなく値の範囲で照合する場合、一致しなかったレコードの出力が下流に接続されている場合、データベースと照合するフィールドが指定されていない場合、および照合するレコードの入力元として何も接続されていない場合にも、自らを示して停止します。

変換されたLoaderと、それが書き込んだものを読み取るリーダーは相互に接続されているため、リーダーは自分のテーブルを埋める書き込みと並行して実行されることはありません。

Calgary Inputの列はテキストとして取り込まれます。代替テーブルが提供するのは列の名前であり、データベース自身の型ではありません。

インデータベースツール

インデータベースのワークフローは、Alteryxエンジンではなくウェアハウスに処理を渡します。PlaidCloudのステップはもともとウェアハウスのSQLなので、インデータベースの操作ツールは、メモリ内の対応するツールとまったく同じステップに変換されます。Filter In-DBはフィルター、Formula In-DBは式、Summarize In-DBは集計になり、Join、Select、Sample、Sort、Union、Browseも同様です。

変換されないのは、チェーンの両端にある2つのツールです。Connect In-DBとWrite Data In-DBは、間のツールが保持してSQLを送るライブのウェアハウス接続を開きますが、PlaidCloudにはその保持された接続に相当するものがありません。それぞれ、ツール名と代替手段（PlaidCloud接続にバインドされたSQLのインポートまたはエクスポートステップ）を示す、確認用のフラグが付いたステップとして取り込まれます。2つの端点をそれらのステップに置き換えれば、間の操作ツールはそのまま変換されます。

Data Stream In、Data Stream Out、Dynamic Input In-DB、Dynamic Output In-DB、およびIn-Database Macro Input/Outputも、同じ理由で名前を示して拒否されます。

位置ベースのJoinまたはMulti-Row Formulaが供給するUnion

レコードの位置で照合するJoinやMulti-Row Formulaから読み取るUnionを含むワークフローは、問題なく変換されても、実行すると失敗することがありました。解決できない列が原因で途中で停止していました。変換は問題なく見えましたが、ワークフローを実行して初めて問題が発覚しました。

これは修正されました。このようなワークフローは、正しい結果で実行されるようになりました。以前にインポートしたワークフローでこのエラーが発生した場合は、再インポートせずに、そのまま再実行してください。

Join Multipleの出力列

Join Multipleが選択タブのすべてのフィールドを一覧にすると、Alteryx DesignerはそれぞれにInput_#1_<field>、Input_#2_<field>といった名前を付けます。変換された複数テーブル結合では、それらの列が通常の出力名で保持され、タブでの名前の変更や選択解除が適用されます。この修正前に変換されたJoin Multipleは出力列がない状態で取り込まれ、実行時にステップが失敗していました。修正を反映するには、そのワークフローをもう一度インポートしてください。

Cross Tabのパーセントと合計の列

派生メソッドのPercent Row、Percent Column、Total Column、Total Rowのいずれかを持つCross Tabは、以前は変換を停止させ、その下のすべてのステップに影響していました。4つすべてが変換されるようになりました。

Percent RowとPercent Columnは、セルの値が、データフィールドの行の合計、または列の合計に占める割合です。
Total Columnは、その行の合計で、ツールが記録した名前で出力されます。
Total Rowは、合計を保持する追加のレコードで、グループ化フィールドには値がありません。

ツールがセルごとにどのメソッドを計算する場合でも、すべての合計はデータフィールドの合計です。

2つの形式は、変換されずに確認用のフラグが付けられたままです。グループ化フィールドを持たないCross TabのTotal Row（区別する手段のないまま同じレコードが2回出力されます）と、ツールが名前を記録しなかったTotal Column（出力から完全に欠落してしまいます）です。

AlteryxのDouble列は完全な精度を保持する

AlteryxのDouble（倍精度浮動小数点数）列は、Alteryx自体が計算に使用する精度に合わせて、64ビットの数値列に変換されるようになりました。以前は32ビットの列（有効桁数約7桁）に変換されていたため、それ以上の桁数を持つ値は読み取り時に黙って丸められ、それに基づくすべての計算に誤差が引き継がれました。実際の例として、16,862,441.27が16,862,442.00として返されていました。

変換されたマクロ内で、マクロ入力として渡されたDouble列は、以前はテキストとして届いていましたが、数値として届くようになりました。マクロのロジックが以前のテキストとしての動作（文字列の連結、先頭のゼロの書式設定、テキストパターンの一致）に依存していた場合は、実際の数値が渡されると動作が変わることがあるため、再変換後に確認してください。

この修正前に変換されたワークフローは、変換時の列の型のまま残ります。この修正を反映するには、もう一度インポートしてください。

変換後のワークフローのマクロ

マクロは、Alteryxのマクロエンジンのエミュレーションではなく、PlaidCloudのネイティブな構成要素に変換されます。マクロのすべての種類がファーストクラスのワークフロー機能にマッピングされるため、変換されたマクロは、元のマクロと同じレコード単位または反復単位の動作で同じロジックを完全な忠実度で実行します。

標準マクロは呼び出し元のワークフローにインライン展開されます。マクロのツールはキャンバス上の通常のステップになるため、信頼するしかないブラックボックスはなく、すべてのステップが可視で、レビューや編集が可能なままです。入れ子の標準マクロは何階層でもインライン展開され、自分自身を呼び出すマクロは、無限ループになることなく検出されて名前が示されます。
バッチマクロは、制御パラメーターのレコードごとに1回実行されるマクロワークフローになり、各パスの出力は1つのストリームにまとめて収集されます。これは、Alteryxが実行するグループごとの実行と同じです。制御パラメーターは、Alteryxでバッチを駆動するのとまったく同じように、パスごとの変数としてバインドされます。
反復マクロは、パス間で状態を引き継ぎ、マクロが収束するまで実行されるネイティブなワークフローループになります。ループのパス上限は、マクロ自身のMaximum Number of Iterationsで、Alteryxがマクロを実行するときの設定と同じです。これがAlteryxの暴走防止用のデフォルトのままの場合、または未設定の場合は、代わりに変換側の上限が適用されます。マクロがその上限でもまだ収束していない場合、実行は到達した上限を示して停止します。部分的な結果を最終的な答えとして報告することはありません。上限より多くのパスを必要とするマクロは、より高い上限で再インポートできます。インポートのiteration_ceilingオプションで設定します。
制御パラメーター、Macro InputおよびMacro Outputのポート、Actionツール、Detour分岐は、すべてネイティブな同等のものに変換されるため、マクロをつなぐ仕組みは近似ではなく、そのまま保持されます。BatchマクロまたはIterativeマクロの内部から呼び出されるマクロは、呼び出し元とともに解決され、変換されます。

2つの構成は変換されず、名前を示して拒否されるため、インポート時にわかります。別のループマクロの中に入れ子になったループマクロと、In-Database Macro Input/Outputツールです。

以前の変換では、各パスが専用の出力テーブルを書き込み、結果を集めるステップがそれらすべてを名前で読み戻していたため、数十件程度のレコードで駆動されるマクロでも、そのテーブル数にまたがる1つのクエリが構築され、データベースがそのクエリを計画できませんでした。ワークフローは途中で停止し、原因を示す有用な情報はありませんでした。

現在は、パスが1つのテーブルに蓄積され、集めるステップがそれを直接読み取ります。そのテーブルは実行の開始時に適切に空にされるため、マクロがパスを生成しなかった実行は、前回の実行の行を再び返すのではなく、空の結果を返します。

バッチマクロのワークフローが途中で停止または失敗していた場合は、再インポートして修正を反映してください。

Location Optimizerマクロは、探索のスコアリングパスにすぎません。候補ロケーションセットの生成、ロケーション数、生成の上限、シードなど、探索自体は、ワークフローファイルではなく、呼び出し元のツールとAlteryxエンジンの内部にあります。上記の線形距離のケース以外（重力カーネル、独自のスコアリングマクロ、値が高いほど良い目的関数、スコアリング前の距離の変換（固定の施設コスト、Summarize、結合など））では、PlaidCloudにはその最適化ループに相当するものがありません。マクロ呼び出しは、マクロの名前、候補セットが届く入力、それらをランク付けする出力、高いスコアと低いスコアのどちらが勝つかを示す、確認用のフラグが付いたステップとして取り込まれるようになりました。

そのようなマクロは、以前は変換されて正常に実行されていましたが、その数値は誤っていました。 通常のマクロとして扱われていたため、スコアリングパスは単一の候補セットに対して1回だけ実行され、実行は成功と報告されていました。答えのように見える結果でしたが、最適化されたものではなく、1回の推測をスコアリングしただけのものでした。このようなワークフローを再インポートして、以前は動作していた箇所で拒否が表示される場合、以前の結果は信頼すべきものではありませんでした。

変換後のワークフローのレポート

レポートレイアウトが参照する画像は、ワークフローとともにパッケージ化されるようになったため、変換されたレポートは、Alteryxのマシン上にしか存在しなかったアセットで失敗するのではなく、ドキュメントでそれを見つけます。これは、固定パスで指定された画像が対象です。バイト列がワークフローに埋め込まれている画像や、パスがレコードごとに列から取得される画像には、取得すべき個別のファイルがありません。

ソースデータを読み取れなかったレポートの部分は、その旨が報告されるようになりました。テーブルの列を読み取れなかった場合、それを元にしたレポートのスニペットはスキップされ、レポートのテーブルセクションは空になっていましたが、どちらも成功と報告された実行で起きていました。ステップは、列情報を読み取れなかったことと、その理由を示して停止するようになりました。以前はセクションが欠けた状態で出力されたレポートが、説明付きで停止することがあります。 詳細は、2026年8月の修正項目を参照してください。

変換されたワークフローを使用する

インポート後は、他のPlaidCloudの高度なワークフローと同じように使用します。

変換されたワークフローのキャンバスを開きます。
生成されたステップとブランチを確認します。
変換されたアプリの質問や実行時パラメーターに対して、ワークフロー変数を設定します。
ワークフローを実行します。
実行履歴、ステップの出力、準備状況に関するメモ、生成された成果物を確認します。
繰り返し運用の準備ができたら、ワークフローをスケジュールします。

変換されたDownloadツールは、RESTリクエストステップになります。このステップは、ステップに埋め込まれたURLではなく、REST接続を通じて外部のエンドポイントに到達します。実行する前に、ステップにREST接続を割り当ててください。コンバーターは、インポート時に準備状況に関するメモでこれを示します。接続の設定方法は、接続を作成するを参照してください。

変換されたマクロは、PlaidCloudのマクロワークフローとして利用できます。Alteryxのマクロを呼び出していたワークフローは、マクロステップを通じて、生成されたPlaidCloudのマクロを呼び出します。マクロの実行は互いに分離されているため、同時に実行される複数のワークフローが同じマクロ定義を安全に使用できます。

変換を検証する

PlaidCloudでは、2つの実用的な検証レベルがサポートされています。

構造の検証

構造の検証では、ワークフローが実行可能なPlaidCloudのDAGに変換されたことを確認します。

すべてのAlteryxのツールにPlaidCloudの変換ルートがある。
必要なマクロが見つかった、または生成された。
必要な入力ファイルがドキュメントにアップロードされた。
マクロ入力とマクロ出力が接続されている。
ユーザーが制御する入力に対してワークフロー変数が作成された。
生成されたワークフローが開き、PlaidCloudで実行できる。

構造の検証は、移行の準備状況、インベントリのレビュー、ポートフォリオの初期段階の変換に役立ちます。

出力パリティの検証

出力パリティの検証では、PlaidCloudの実行結果を、信頼できるAlteryxの出力と比較します。

出力スキーマが一致する。
行数が一致する。
行の値が一致する。
ワークフローが明示的に順序に依存していない限り、行の順序は無視される。

レポート、マップ、PDF、画像、モデルの成果物を作成するワークフローについては、チームが出力を使用する方法に応じて、生成された成果物、またはその元になるデータを検証してください。

詳細な検証チェックリストについては、変換されたAlteryxワークフローを検証するを参照してください。

ランダムサンプリング

行の値については、サンプリングツールが意図的な例外となります。 Create SamplesとRandom % Sampleはどちらもランダムに抽出し、Alteryxはシードが設定されている場合、実行のたびに同じレコードを返します。PlaidCloudは独自のジェネレーターで抽出するため、次のようになります。

サンプルサイズ、パーセンテージ、およびEstimation / Validation / Holdoutの分割比率は、そのまま引き継がれます。
各サンプルに含まれるレコードはAlteryxが選ぶものとは異なり、再実行すると、また別のセットが選ばれます。

変換された各ステップは、変換レポートとステップ自体にその旨を示し、いずれも変換に失敗したツールとしては報告されません。これらは、行の値ではなく、行数と比率で検証してください。

どのレコードがどのサンプルに入るかが実際に重要な場合（正確に再現する必要があるモデルや、すでに結果を公開しているホールドアウトなど）は、列を使ってサンプルを決定してください。サンプルの割り当てを計算するFormulaステップと、サンプルごとのFilterステップを使用します。

機械学習（アシストモデリング）の変換

機械学習ツールファミリーで構築されたAlteryxの機械学習パイプラインは、PlaidCloudのネイティブなMLステップに変換されます。

ClassificationまたはRegressionツールは、上流のアシストモデリングおよび変換ステージ、下流のFitツールとともに、1つのML: モデルの学習ステップに統合されます。このステップは、Alteryxのワークフローから正確なアルゴリズム、目的変数、特徴量の列、ハイパーパラメーターを引き継ぎ、学習したモデルを、学習時のメトリクスを記録した1行のモデルテーブルとして書き込みます。
各Predictツールは、学習済みモデルテーブルとそのデータ入力を読み取るML: スコアリングステップになります。予測列には、目的変数の名前に_predictedサフィックスを付けた名前が付きます。
XGBoost 分類器は近似に関するメモ付きで変換されます。モデルはscikit-learnの勾配ブースティング分類器として学習され、同等のものがないXGBoost固有のツリーパラメーターは、ステップのマッピングメモに一覧表示されます。パリティに頼る前に、モデルのメトリクスをAlteryxの実行結果と照らして検証してください。
Image Recognitionツールは、ワークフロー内で画像分類器を学習し、それを使って新しい画像をスコアリングします。すべてその場で行われ、外部アカウントは不要で、画像データがPlaidCloudの外に出ることはありません。モデルを指す下流のPredictは、それに対してスコアリングします。MLファミリーの他のツールとは引き継がれ方が2点異なるため、パリティに頼る前に検証してください。1つ目は、分類器がAlteryxからコピーされるのではなく、ラベル付けされた画像から再学習されること、およびその学習が非決定的であることです。同じワークフローを2回変換すると、わずかに異なるモデルが作成されるため、予測は忠実な近似であり、ビット単位で一致するものではありません。2つ目は、学習がCPUで実行されるため、数百から数千枚程度の画像セットでは数分かかることです。Image Recognitionはワークスペースごとに有効化されます。変換されたワークフローで有効化されていないと報告された場合は、管理者に有効化を依頼してください。
AutoMLツールは、ClassificationやRegressionと同様に、ML: モデルの学習ステップに統合されます。AutoMLは、Alteryxの実行時に候補のアルゴリズムのうちどれが最終的に選ばれたかを記録しないため、変換では、自動探索を再現するのではなく、ML Trainがサポートする、チェックされた最初のアルゴリズムを選択し、その選択をメモに記録します。変換されたAutoMLステップは、お客様自身のAlteryxの結果と比較してください。
モデルが対話的に選択されたアシストモデリングウィザード（ワークフローファイルには保存されていないもの）は変換できません。インポーターは、回復した目的変数をメモに記録したプレースホルダーステップを保持するため、ML Trainステップを手動で構築できます。
単独のワンホットエンコーディングステージは、変換レポートでフラグが付けられます。統合されたML Trainステップはカテゴリ特徴量を内部でワンホットエンコードするため、通常、単独のステージを置き換える必要はありません。

すべての変換と同様に、統合されたステップは信頼度とメモを変換レポートとキャンバスに保持するため、再確認する価値のあるパイプラインを簡単に見つけられます。

変換のカバレッジを確認する

Alteryx変換マトリックスには、サポートされている各Alteryxオブジェクト、そのカバレッジレベル、および変換時に使用されるPlaidCloudの操作が一覧表示されています。

マトリックスを使うと、インポーターがツールファミリーごとにどのように処理するかを把握できます。

一般的なデータ準備、結合、フィルター、式、並べ替え、ユニオン、サンプリング、再構成のためのネイティブなDAGステップ。
マクロ入力、マクロ出力、マクロ呼び出し、制御パラメーター、マクロの並行実行のためのマクロステップ。
チェックボックス、ドロップダウン、テキストボックス、ラジオボタン、フォルダー選択、ファイル選択などの分析アプリの質問のための、管理されたワークフロー変数。
入力、出力、ディレクトリ、動的ファイルの動作のための、ドキュメントに基づくファイル操作。
アシストモデリングの機械学習パイプラインのためのネイティブなML TrainおよびML Scoreステップ。
Alteryxの各Calgaryデータベースのための代替テーブル。これにより、Calgary Loader、Input、Cross Count、Joinの各ツールが、完全に拒否されるのではなく通常のテーブルに対して変換されます。Calgaryデータベースを参照してください。
特殊な空間処理、あいまい一致、PDF、OCR、NLP、レポート作成、成果物の処理のためのマネージドジョブエグゼキューター。
AlteryxのデスクトップレンダラーやプロプライエタリなファイルフォーマットをPlaidCloudで再現するのではなく、永続的で共有可能な成果物を作成するクラウドネイティブな同等機能。

Alteryxカバレッジレポート

サインアップする前に、Alteryxのワークフローの内容を確認できます。

https://app.plaidcloud.com/#coverage-reportの公開ページを開きます。タイトルはSee what’s in your Alteryx workflowsです。
Drop an Alteryx workflow hereにファイルをドロップするか、ファイルを選択を選びます。ワークフロー（.yxmd）、マクロ（.yxmc）、パッケージ（.yxzp）を、10 MBまで受け付けます。PlaidCloudがファイルを読み取り、見つかったツールと、最もよく使われているツールを表示します。ファイルに保存されている認証情報は削除されます。
Work emailを入力し、利用規約とプライバシーポリシーに同意して、Email me a verification linkを選びます。

完全なレポートは、お客様自身の無料PlaidCloudワークスペースで作成されます。PlaidCloudはアップロードをAlteryx migrationという名前のプロジェクトに変換し、最初のワークスペース管理者がホームを開くとAlteryx カバレッジレポートが表示されます。各ワークフローについて、PlaidCloudが認識して変換できるツールの数、要確認の数、変換されたワークフローの開くボタンが一覧表示されます。データファイルはレポートに含まれません。ワークフローが読み取るファイルをアップロードしてから、実行してください。レポートのボタンから、自分のウェアハウスを使用すると移行を検証するに進めます。アップロードは7日間保持されます。

すでにPlaidCloudアカウントをお持ちの場合は、入力したメールアドレス宛に、リンク付きのメッセージ「Your coverage report is ready — sign in to view it」が届きます。サインインしてレポートを開き、ワークスペースを選択して、Add the reportを選択します。追加できるのはワークスペースの組織の管理者のみで、レポートは次にワークスペースを開いたときに表示されます。メールを無視しても、ワークスペースには何の変更もありません。無効または期限切れのリンクはその旨が表示され、期限切れのアップロードは再度アップロードする必要があります。

変換後は、Alteryxの出力に対して一致を検証してください。

推奨される移行の進め方

大規模なポートフォリオの場合は、バッチに分けて移行します。

ワークフローとマクロを移行用のプロジェクトにインポートします。
個々の式やビジネスロジックを確認する前に、依存関係のパッケージを完成させます。
バッチ全体で構造の検証を実行します。
本番環境のワークフロー、規制対象のワークフロー、下流の利用者がいるワークフローについて、出力パリティの検証を優先します。
検証済みのワークフローをターゲットの本番プロジェクトに昇格させます。
本番環境の実行をスケジュールし、実行履歴を監視します。

移行ドキュメントセット

大規模な移行では、この移行ガイドとあわせて、次の個別のガイドをご利用ください。

Alteryx移行の準備状況チェックリスト：移行の計画とパッケージのレビュー。
Alteryxの依存関係をパッケージ化する：ファイル、フォルダー、マクロ、空間データのサイドカーファイル、期待される出力。
変換されたAlteryxアプリを使用する：管理されたワークフロー変数とアプリ形式の実行。
MCPでAlteryx移行を統括する：AIエージェントを使ってファイルを整理し、接続された共有ストレージから作業し、PlaidCloudのMCPサーバーを通じて多数の変換を調整する方法。
Alteryxインポートを調整する：依存関係の補完、マクロの解決、変数、検証の比較、エグゼキューターの準備状況に関するメモ。
Alteryxのレポートと成果物を検証する：PDF、画像、マップ、チャート、ダッシュボード、モデルの成果物。
空間データを扱うAlteryxワークフローを移行する：空間ファイル、SQLジオメトリのロジック、マネージド空間エグゼキューター、空間データの検証。