PowerShell から XML への変換ツール
PowerShell オブジェクトやハッシュテーブルを貼り付けるだけ。きれいな XML が返ってきます。
このツールでできること
PowerShell の設定を XML ファイルに落とす必要があったことがあるなら — DSC リソース、MSBuild タスク、app.config テンプレート、SoapUI のフィクスチャなど — いつもの流れはご存じでしょう。ConvertTo-Xml を実行して醜い <Object Type="..."> ラッパーを手で削るか、Export-CliXml を使って PowerShell 以外では誰も読めない CLIXML を受け取るか、のどちらかです。PowerShell をここに貼り付ければ、普通の XML パーサーが受け入れる整形式の XML が返ってきます — <Property Name="..."> のノイズも、CLIXML の型タグもなし、データだけです。
PowerShell コードが実際に使う形を理解します。PSCustomObject は、各プロパティ名を持つ子要素を備えた要素になります。ハッシュテーブル @{ Name = "Ava" } も同じ挙動です。@(...) で作られた配列は、要素ごとに子を持つコンテナ要素になります。親オブジェクト内のネストされた [PSCustomObject] の値は、文字列化された塊ではなくネストされた要素として通ります。真偽値 ($true、$false) と数値は出力でネイティブ型を維持します。$null はフィールドが静かに消える代わりに、空の自己終了要素になり、形が予測可能なままになります。
言語特有のクセも人間が期待するように処理されます。二重引用符の文字列は $var のような補間マーカーが展開されないまま通ります — 貼り付けた内容をそのまま保持します。ヒアストリング (@" ... "@) は複数行のテキストコンテンツとして扱われます。[datetime]"2026-04-21" のように書かれた日付は ISO-8601 文字列として出力されます。ハイフンを含むプロパティ名には安全な要素名が与えられます (PowerShell ではハッシュテーブルに "User-Agent" = "..." と書けますが、素の XML タグとしては不正です — 出力が解析可能なままになるよう変換します)。形は入力に忠実なまま、XML は使える状態で出てきます。
使い方
3 ステップ。ハッシュテーブル 1 つを貼り付けても、設定スクリプト丸ごとを貼り付けても、動作は同じです。
PowerShell を貼り付ける（またはサンプルを試す）
左のエディタにスクリプトを入れます。単一の [PSCustomObject]@{...}、ネストされたハッシュテーブル、オブジェクトの @(...) 配列、あるいは設定ブロック丸ごと — どれでも大丈夫です。まずリアルな Order ペイロードで試したいなら サンプルを読み込む をクリックしてください。
コメントを削ったり param() ブロックを外したり、事前にスクリプトをきれいにする必要はありません。手元のものを貼り付けてください。オブジェクトリテラルだけを読み、ほかは無視します。
変換を押す
緑の 変換 ボタンをクリック。ツールは PowerShell の構造を歩き、すべてのプロパティと配列要素を保持して、一発で XML を組み立てます。実行中は短いローディングインジケータが表示されます。
XML をコピーする
右側のパネルには、標準準拠のパーサーが受け入れるインデント付き XML が入ります。DSC 設定、MSBuild ファイル、その他必要な場所に入れてください。
実際に役立つ場面
DSC 設定ペイロードの作成
ノード設定を記述した PowerShell ハッシュテーブルがあり、DSC 以外のコンシューマーやドキュメント用に XML 版が必要なとき。貼って、変換、完了 — ConvertTo-Xml の出力を面倒見る作業はもう不要です。
Azure DevOps パイプラインの変数ファイル
パイプラインが変数グループを XML で期待することがあります。すでに管理している PowerShell ハッシュテーブルを貼り付ければ、<code>variables.xml</code> にそのまま入る XML が返ってきます — 手編集なし。
Windows イベントログのペイロード書き出し
PowerShell でイベントレコードを PSCustomObject として組み立てて、XML を取り込むロギングパイプラインに渡す必要があるとき、カスタムシリアライザを書かずに済みます。ネストされた形はそのまま通ります。
app.config / web.config の雛形テンプレート
PowerShell 設定ハッシュテーブルを、手で編集できる出発点の <code>app.config</code> に変換します。ゼロから作るより速く、キーをスクリプトと同期させやすくなります。
よくある質問
オブジェクトに ConvertTo-Xml をかけるのと何が違いますか？
ConvertTo-Xml はすべてを汎用の <Object Type="..."><Property Name="..."> エンベロープで包みます — PowerShell からは読めても、ほかの場所では醜いです。このツールはプロパティ名を実際の XML 要素として出力するので、人が手書きした XML のように見えます。<Property Name> の中間層も、型属性のごちゃごちゃもありません。
Export-CliXml のように CLIXML を生成しますか？
しません — それが狙いです。Export-CliXml は CLIXML を出力します。これは PowerShell に戻すためのラウンドトリップ用に設計された PowerShell 固有の形式です。XML を PowerShell 以外のシステム (Java サービス、設定リーダー、XSD 検証パイプラインなど) に渡す必要がある場合、CLIXML は形が合いません。このツールは代わりに、素直で読める XML を返します。
.ps1 ファイル全体を貼り付けられますか？ それともオブジェクトリテラルだけですか？
手元のものを貼ってください。変数に代入された単一のオブジェクトリテラルがスクリプトに含まれていれば、それが出力されます。トップレベルに複数のハッシュテーブルや PSCustomObject があれば、それぞれが独自の要素として出力されます。関数本体、param() ブロック、import、Write-Host の行は無視されます — データの形だけが重要です。
$null、$true、$false、空の配列はどう扱われますか？
$null は空の自己終了要素になり、形の一貫性が保たれます (フィールドが消えることはありません)。$true と $false はリテラル文字列 true と false になります。空の @() は空のコンテナ要素になります。こうすることで、一部のフィールドが未設定でも、下流のツールは常に同じ構造を見られます。
有効な XML 名でないハッシュテーブルのキー — ハイフン、スペース、数字始まりなど — はどうなりますか？
"User-Agent" や "2024-Q1" のようなキーは PowerShell ハッシュテーブルでは合法ですが、素の XML 要素名としては不正です。安全な形に書き換え (意味があれば元の名前を属性として保持) 、出力が解析可能なままになるようにします。コンシューマー側で重要なら、生成されたタグを先に確認してください。
コードは保存されますか？
コードは変換のためにバックエンドに送られますが、保持はしません — ペイロードをログに残さないということです。スクリプトが本当に機密 (本番の認証情報、内部パスなど) なら、オンラインツール一般と同じように、貼る前に除去してください。
他にも役立つツール
PowerShell から XML はパズルの一部。これらのツールと相性が良いです：