問題の概要
ジオプロセシングフレームワークはArcGIS Proの最大の強みの一つであり、サードパーティ開発者は正当にそこに導かれます。スクリプトツールやPythonツールボックスとして構築されたツールは、ジオプロセシング履歴、環境設定、進行状況とメッセージ報告、バッチモード、ModelBuilderの組み合わせ、そしてarcpyスクリプティングという、どんなカスタムダイアログでも再現できないエコシステムを得られます。
しかし、そのエコシステムには正確に一つのユーザーインターフェイスが付属しています：自動生成されるジオプロセシングペインです。サードパーティツールが他のUIを表示しながら本物のジオプロセシングツールであり続けるためのサポートされた方法はありません。単純なツールには生成されたペインで十分ですが、対話的でフィードバック豊富なワークフローには非常に制限があり、開発者は不必要な二者択一に直面します：
- GPツールのままでいるそして生成されたペインの制限（カスタムウィジェットなし、ライブプレビューなし、レイアウト制御が限定的、検証動作の長い尾の問題）を受け入れるか、
- カスタムドックペイン／ウィンドウを構築することで正確に望むUIを実現しつつ、ジオプロセシング履歴、環境設定、ModelBuilder、バッチ処理、およびスクリプティングを完全に失うかです。
Esri自身の代表的な対話型ワークフローはこの問題を示しています：Suitability Modeler、image Classification Wizard、およびGeoreferencingはすべてカスタムペインであり、生成されたジオプロセシングダイアログではありません。リッチな対話が重要な場合、EsriはGPペインを迂回します。サードパーティ開発者には同じことを行うためのサポートされた方法がなく、ジオプロセシングフレームワークを放棄せずに.
要望されている改善点
ツールUIをツールから切り離すこと。どちらも大きな前進となる2段階：
Tier 1 — カスタムツールダイアログ（完全な要望）。アドインが特定のジオプロセシングツール（スクリプトツール、.pyt, または .atbx)用のPro UIとしてWPFダイアログ／ペインを登録できるようにします。ツールは他のすべての点で第一級のGPツールとして残ります：
- カスタムダイアログはパラメーターを収集・検証し、その後標準的なパラメーター配列を通常のGP実行パイプラインに渡します。そのため実行はジオプロセシング履歴に記録され、環境設定を尊重し、進行状況やメッセージを報告し、メタデータも今日と同様に刻印されます。
- カスタムダイアログをホストできないコンテキスト—ModelBuilder、バッチモード、スケジュール実行、サーバーパブリッシング、
arcpy— は自動的に自動生成ペインと既存のパラメーターオブジェクトにフォールバックします。何も壊れません。 - カスタムダイアログが登録されていない場合は動作が今日と全く同じ（完全な後方互換性）です。
Tier 2 — カスタムパラメーターコントロール（より小さいが依然として変革的な要望）。開発者が生成されたペイン内で個々のパラメーター（またはカスタムパラメーターデータ型）用のカスタムWPFコントロールを登録できるようにします。これだけでもほとんどの問題が解消されます：値テーブルはライブフィードバック付きの本物のグリッドになり得ます；リマップパラメーターは入力ラスターのヒストグラムを表示でき；閾値は選択するセルを示せます。
なぜ重要か
カスタムPythonツールボックスはArcGIS Proにおける第一級の拡張手段であり、多くの組織やサードパーティがそれら上に真剣で商用グレードの解析スイートを構築しています。ユーザーが目にする品質は開発者の努力ではなく生成されたペインによって制限されています。ユーザー体験を重視する開発者はジオプロセシングフレームワークを放棄せざるを得ず、その結果として由来性、再現性、およびスクリプト化可能性というProツールを信頼できるものにしている要素を失います。サポートされたUI拡張ポイントがあればそのトレードオフは終わり、サードパーティエコシステム全体の品質基準が向上し、後方互換性にも全く影響しません。
