GraphQL→XML コンバーター
GraphQL スキーマやクエリを貼り付けてください。整った XML が返ります。
このツールでできること
XML しか扱わないチームのために GraphQL API をドキュメント化したり、GraphQL スキーマを古い SOAP クライアントに繋いだ経験があるなら、面倒さはよく分かるはずです。GraphQL の型は XML に一対一で置き換えられません。スキーマやクエリをここに貼り付ければ、整形式の XML がワンパスで返ってきます。いくつかの type 定義でも、SDL ファイル一式でも、引数付きの具体的なクエリでも、結果は同じ — データの形を忠実に反映した完全な XML ドキュメントです。
このコンバーターは表面の構文だけでなく GraphQL 仕様 を理解しています。スカラーのデフォルトは期待どおり — String はテキスト、Int と Float は数値テキスト、Boolean は true/false、ID は文字列値になります。非 null マーカー（String!）とリストマーカー（[OrderItem!]!）は尊重されます。必須リストは項目ごとに子要素を持つコンテナ要素として現れ、null 許容で値がないフィールドは空要素として出力されるので、ドキュメントの形が崩れません。
組み込み型だけでなく 型システム の残りも扱えます。input 型はネストした要素になり、enum 値は文字列テキストとして出力、interface と union は背後の具体的な形に解決され、フラグメント（名前付き・インラインとも）はインライン展開されて出力はフラットで自己完結します。DateTime、Date、JSON などのカスタムスカラーは ISO-8601 または文字列化された値として出力されます。引数付きの query を貼り付けると、引数はルート要素の一部として保持され、XML は単なるデータの塊ではなくリクエストを忠実に表したものになります。
使い方
手順は 3 つ。単一の型を貼り付けても、クエリ付きの完全なスキーマを貼り付けても、挙動は同じです。
GraphQL を貼り付ける（またはサンプルを試す）
左のエディタに GraphQL をそのまま貼り付けてください。単一の type、input/enum/interface/union を含む SDL ファイル 一式、変数付きの具体的な クエリ — どれでも大丈夫です。まずは現実的な形で試したいなら サンプルを読み込む を押してください。
コメントを外したり SDL 構文 を整形し直す必要はありません。エディタが書いたままで構いません — 三重引用符のドキュメント文字列もハッシュコメントも問題なく通ります。
「変換」を押す
緑の 変換 ボタンを押します。ツールはスキーマ（またはクエリ）を読み取り、フラグメントとリスト／非 null マーカーを解決して、ワンパスで XML を組み立てます。処理中は短いローディングインジケータが表示されます。
XML をコピーする
右のパネルが、標準準拠の XML パーサー が受け付ける、インデント済みで整形式の XML で埋まります。そのまま SOAP リクエスト、ドキュメント、フィクスチャ、XSD のサンプルに貼り付けられます。
実際に役立つ場面
GraphQL API の XML ベースのドキュメント
社内ドキュメントやパートナー向けドキュメントが XML（DITA、DocBook、XSD ベースのリファレンス）で管理されているケース。スキーマを貼るだけで、実際の型と一致するサンプル XML ペイロードが手に入り、手作業の翻訳が不要です。
スキーマから XML フィクスチャを生成
コントラクトテスト、スナップショットテスト、XML を喋るモックサーバーなど。手元のスキーマを渡すだけで、リスト・null 許容・ネストした型がすべて正しい位置にある一貫したフィクスチャ XML が得られます。
レガシー SOAP クライアントへの橋渡し
パートナー側のシステムが XML ペイロードしか受け付けないのに、バックエンドが GraphQL という状況。クエリとレスポンス型を貼れば、SOAP リクエストに差し込める起点となる XML ボディが手に入ります。
スキーマ移行と分析
GraphQL から XML ベースの API へ移行する（あるいは両方の形を比較する）とき。すべての型の XML 版を並べて見せられるので、SDL を読めないレビュアーも議論についてこられます。
よくある質問
type、input、enum、interface、union はどう扱われますか？
type と input はフィールドごとに子要素を持つコンテナ要素になります。enum 値はプレーンな文字列テキスト（SDL で宣言されたとおりの大文字の名前）として出力されます。interface は具体型が分かっている場合、自身のフィールドに加えて実装型のフィールドへと解決されます。union は一致したメンバーの形に解決されます。詳しい規則は GraphQL 型言語 のリファレンスを参照してください。
String、Int、Float、Boolean、ID のデフォルトは？
String と ID はテキスト内容になります。Int はそのままの整数。Float は末尾のゼロのない小数。Boolean は小文字の true または false。これらは GraphQL 仕様のスカラー定義に一致しているため、出力は XML パーサーを問題なく通ります。
非 null (!) とリスト ([T]) のマーカーはどう扱われますか？
非 null（String!）は必ず現れるフィールドとして扱われ、null 許容で値がないフィールドは空要素として出力されるので、ドキュメントの形は予測可能なまま保たれます。リスト（[OrderItem!]!）は要素型に由来する名前のコンテナ要素となり、項目ごとに子要素を持ちます — 例えば items: [OrderItem!]! は <items><OrderItem/><OrderItem/></items> になります。ネストしたリスト（[[Int]]）も同様にネストします。
フラグメントは解決されますか？
はい。名前付きフラグメント（...OrderFields）とインラインフラグメント（... on Order { ... }）はインライン展開され、XML はフラットで自己完結します。フラグメント定義を別途貼り付ける必要はなく、同じブロックにあればツールが結び付けます。これは、レスポンス構築前にフラグメントが選択セットに展開されるという通常のクエリ実行モデルと一致します。
DateTime のようなカスタムスカラーは？
よく知られたカスタムスカラー（DateTime、Date、Time、UUID、JSON）は慣例どおり ISO-8601 テキストまたは文字列化された値として出力されます — ほとんどのスカラーライブラリの挙動と一致します。未知のカスタムスカラーは文字列テキストにフォールバックするので、黙って捨てられることはありません。特定のフォーマットが必要なら、XML を後処理するかスカラー名を変えてください。
スキーマだけでなく引数付きのクエリを貼れますか？
はい。変数と引数付きの query、例えば query GetOrder($orderId: ID!) { order(id: $orderId) { ... } } を貼り付けると、引数はルート要素の属性として出力されます。選択されたフィールドがどのレスポンス形状をシリアライズするかを決めるので、XML は型全体ではなく、そのクエリが実際に返すものと一致します。
あわせて使えるツール
GraphQL→XML はパズルの一片に過ぎません。以下のツールが相性よく使えます：