n8nでXMLデータをJSONに変換！XMLノードを使ったレガシーシステム連携テクニック

「社内の基幹システムから出力されるデータがXML形式で、最新のSaaSと連携できずに困っている…」。

「手動でのデータ変換作業に、毎月多くの時間を奪われている」。

多くの企業でDXが進む現代（2026年1月時点）においても、このようなレガシーシステムとのデータ連携は、依然として大きな課題です。

特に、長年使われてきたシステムではXML形式でデータが出力されることが多く、JSON形式が主流のモダンなAPIやSaaSとの間には、大きな壁が存在します。

しかし、ご安心ください。

本記事で紹介するiPaaSツール「n8n（エヌエイトエヌ）」を使えば、この課題を驚くほど簡単に、そしてコーディングの知識がほとんどなくても解決できるのです。

この記事では、n8nの強力な「XMLノード」に焦点を当て、レガシーなXMLデータをモダンなJSONデータに変換し、システム連携を自動化する具体的なテクニックを徹底的に解説します。

この記事を読み終える頃には、あなたは「負の資産」だと思っていたレガシーシステムのデータを、「価値ある資産」へと変えるための強力な武器を手に入れていることでしょう。

なぜ今、XMLからJSONへの変換が重要なのか？レガシーシステム連携の課題

多くの企業がクラウドサービスやSaaSを導入し、業務効率化を進める一方で、なぜXMLからJSONへのデータ変換がこれほどまでに重要視されるのでしょうか。その背景には、レガシーシステムとモダンなシステムの間に存在する、根深い「データ形式の壁」があります。

レガシーシステムの現状とXMLの役割

企業活動の根幹を支える基幹システムや業務システムの中には、10年、20年以上も稼働し続けているものが少なくありません。これらの「レガシーシステム」は、構築された当時に主流だった技術を基盤としており、データの交換形式としてXML（eXtensible Markup Language）が広く採用されてきました。XMLは、タグを使ってデータの構造を人間にも機械にも分かりやすく定義できるという利点があり、厳格なデータ構造が求められる業務システム間での連携において、長らく標準的な役割を果たしてきました。請求書データ、在庫データ、顧客情報など、今なお多くの重要なビジネスデータがXML形式で日々生成・交換されています。

モダンなAPIとJSONの台頭

一方で、WebサービスやSaaS、スマートフォンアプリなどの世界では、JSON（JavaScript Object Notation）がデータ交換の主流となっています。JSONは、JavaScriptのオブジェクト記法をベースにしており、軽量で構造がシンプルです。特に、Webブラウザで動作するアプリケーションとの親和性が非常に高く、サーバーとクライアント間の非同期通信（Ajax）で爆発的に普及しました。結果として、現在公開されているほとんどのWeb APIは、JSON形式でのデータ入出力を前提として設計されています。この流れは、企業の利用するSaaSにおいても同様で、外部システムとの連携APIは、その多くがJSONを標準形式としています。

データ形式の違いが引き起こす「分断」とビジネスへの影響

ここに、システム連携における「分断」が生じます。一方にはXMLでしかデータを話せないレガシーシステム、もう一方にはJSONでしかデータを理解できないモダンなSaaS。この両者を繋ごうとすると、データ形式の壁が立ちはだかります。この問題を解決するために、多くの現場では以下のような対応を迫られています。

手作業による変換: 担当者がXMLファイルを開き、手動でデータをコピー＆ペーストしてJSON形式のファイルを作成したり、SaaSの管理画面に直接入力したりする方法です。非常に時間がかかり、入力ミスのリスクも高く、何より属人化しやすいという大きな問題を抱えています。
変換スクリプトの開発: PythonやJavaなどのプログラミング言語を使って、XMLをJSONに変換する独自のスクリプトを開発する方法です。一度作れば自動化できますが、開発・保守に専門的な知識を持つエンジニアが必要となり、コストがかかります。また、連携先のAPI仕様が変更されるたびに、スクリプトの改修が必要になることも少なくありません。

このような「分断」は、単なる技術的な課題にとどまりません。データ連携がスムーズに行えないことで、リアルタイムな情報活用が阻害され、結果としてビジネスの意思決定の遅れや機会損失に繋がる可能性すらあるのです。この課題を解決し、DXを加速させる鍵こそが、n8nのようなiPaaS（Integration Platform as a Service）なのです。

n8nの「XMLノード」徹底解説！基本的な使い方と設定項目

レガシーシステム連携の課題を解決する強力な一手、それがn8nの「XMLノード」です。このノードは、その名の通りXMLデータを解析し、n8nのワークフロー全体で統一的に扱えるJSON形式のデータに変換する機能を持っています。プログラミングで言えば、XMLパーサーの役割を担う部分です。しかし、n8nではそれをGUI上の簡単な設定だけで実現できてしまいます。ここでは、XMLノードの基本的な使い方と、知っておくべき重要な設定項目について詳しく見ていきましょう。

ワークフロー作成の第一歩：XMLデータソースの準備

XMLノードを使う前に、まずは変換したいXMLデータをn8nのワークフローに取り込む必要があります。データソースは様々ですが、代表的なのは以下の2つのパターンです。

HTTP Requestノード: 外部のAPIやサーバーからXMLデータを取得する場合に使います。特定のURLにアクセスするとXMLを返すようなレガシーシステムのAPIと連携する際に最適です。
Read Binary Fileノード: サーバー上の特定のディレクトリに配置されたXMLファイルを読み込む場合に使います。バッチ処理で定期的に出力されるXMLファイルを取り込むようなケースで活躍します。

これらのノードを使ってXMLデータを取得すると、n8nの内部データとして次のノードに渡す準備が整います。

XMLノードの基本設定と重要なオプション

データソースの次にXMLノードを接続し、設定画面を開きます。設定は非常にシンプルですが、挙動を正しく理解するためにいくつかの重要なオプションを把握しておくことが大切です。

n8nのXMLノード設定画面

Source Key: どの入力データをXMLとしてパース（解析）するかを指定します。通常、前のノード（HTTP Requestなど）から渡されたデータは「data」というキーに格納されているため、デフォルトのままで問題ないことが多いです。
Options（オプション）: ここでの設定が、変換後のJSONの構造を大きく左右します。
- Parse Attributes: XMLの「属性」をパースするかどうかを決めます。例えば <item id="123"> のようなタグがある場合、このオプションを有効にすると "id": "123" のようなキーと値のペアがJSONに含まれるようになります。属性情報が重要なデータを持つ場合は、必ず有効にしましょう。
- Explicit Array: XMLでは同じ名前のタグが複数回出現することがよくあります。このオプションを無効にしていると、タグが1つしかない場合はオブジェクト、複数ある場合は配列、というように変換後のJSONの型が変わってしまいます。これを防ぎ、常に配列として扱いたい場合にこのオプションを有効にします。後のデータ処理を安定させるために、非常に重要な設定です。
- Merge Attributes: Parse Attributesが有効な場合、属性と子要素を同じ階層にマージします。これにより、JSONの階層を一段浅くすることができますが、名前が衝突する可能性もあるため、元のXML構造をよく理解した上で使用する必要があります。

例えば、以下のようなシンプルなXMLデータを考えてみましょう。

<?xml version="1.0" encoding="UTF-8"?>
<order>
  <item id="A-001">
    <name>商品A</name>
    <price>1000</price>
  </item>
</order>

これをXMLノードで「Parse Attributes」と「Explicit Array」を有効にして変換すると、以下のような構造のJSONデータが得られます。itemが一つしかなくても、しっかり配列（[]）で囲まれているのが分かりますね。これにより、後続の処理で「itemは必ず配列である」という前提でループ処理などを組むことができ、ワークフローの安定性が格段に向上するのです。

{
  "order": {
    "item": [
      {
        "$": {
          "id": "A-001"
        },
        "name": [
          "商品A"
        ],
        "price": [
          "1000"
        ]
      }
    ]
  }
}

実践！n8nワークフロー構築 – XMLデータを変換してSaaSに連携する

理論を学んだところで、次はいよいよ実践です。ここでは、より具体的なシナリオを通して、n8nでXMLデータを変換し、実際に外部のSaaSと連携させるまでの一連のワークフローを構築してみましょう。

シナリオ: 古いオンプレミスの在庫管理システムが、毎日深夜にFTPサーバーへXML形式の在庫リストを出力する。このXMLデータを取得し、ECサイト（Shopifyなど）のAPIに連携して、商品ごとの在庫数を自動で更新する。

ステップ1: 在庫XMLデータの取得 (Read Binary File / FTPノード)

まず、ワークフローの起点となるトリガーを設定します。毎日決まった時間に実行したいので「Cron」ノードを配置し、実行スケジュール（例: 毎日深夜2時）を設定します。

次に、FTPサーバーからXMLファイルを取得するために「FTP」ノードを使用します。「Operation」を「Read」に設定し、FTPサーバーの接続情報（ホスト名、ユーザー名、パスワード）と、対象となるXMLファイルのパスを指定します。これにより、ワークフローが実行されるたびに最新の在庫リストXMLがダウンロードされます。

ステップ2: XMLノードでJSONに変換

FTPノードの次に「XML」ノードを接続します。前のセクションで学んだ通り、ここでXMLからJSONへの変換を行います。在庫リストのXMLでは、商品アイテムが複数含まれることが想定されるため、後々の処理を安定させるために、オプションの「Explicit Array」は必ず有効にしておきましょう。また、商品コードなどが属性として含まれている場合は「Parse Attributes」も有効にします。この時点で、複雑なXMLデータはn8nで扱いやすいJSON形式の配列データに変換されました。

ステップ3: データ整形 (Item Listsノード / Edit Fieldsノード)

XMLから変換しただけのJSONデータが、連携先であるECサイトのAPIが要求する形式と完全に一致することは稀です。多くの場合、ここから「データの整形」作業が必要になります。

キー名の変更: 例えば、XMLでは <product_code> だったものが、APIでは "sku" というキー名を要求されるかもしれません。このような場合、「Edit Fields (formerly Set)」ノードを使い、キー名を簡単に変更できます。「Keep Only Set」を有効にすれば、必要なデータ項目だけを残すことも可能です。
データ構造の組み換え: APIが特定の階層構造（ネスト）を要求する場合もあります。例えば、在庫数とロケーションをまとめて "inventory": {"stock": 10, "location": "warehouse-A"} のようなオブジェクトにする必要があるかもしれません。単純な整形であればEdit Fieldsノードで対応できますが、より複雑なロジックが必要な場合は「Function」ノードが役立ちます。このノードではJavaScriptを記述できるため、Low-codeの範囲で柔軟なデータ加工が可能です。
ループ処理: JSONに変換されたデータは商品アイテムの「配列」になっています。ECサイトのAPIが商品ごとの更新を要求する場合、この配列をループさせて、1件ずつAPIリクエストを送信する必要があります。このループ処理は「Item Lists (formerly Split in Batches)」ノードの「Batch Size」を1に設定することで、アイテムを1つずつ分割して後続のノードに渡す、という形で実現できます。

このデータ整形は、システム連携の肝となる部分です。n8nが持つ多彩なデータ操作ノードを組み合わせることで、ほとんどの要求に応えることができます。n8nの基本的な使い方や、より多くのSaaSとの連携パターンについて詳しく知りたい方は、データ連携の基礎から応用までを網羅した「n8n完全ガイド記事」もぜひご覧ください。あなたの自動化の可能性をさらに広げるヒントが見つかるはずです。

ステップ4: ECサイトAPIへデータを送信 (HTTP Requestノード)

ループ処理で1件ずつに分割・整形された商品データの準備が整ったら、いよいよECサイトのAPIを呼び出します。再び「HTTP Request」ノードの登場です。

「Request Method」をAPIの仕様に合わせて「POST」や「PUT」に設定します。URLには、更新対象の商品を特定するための情報（商品IDなど）を前のノードから動的に埋め込みます。「Body Content Type」を「JSON」にし、「Body」フィールドに整形したJSONデータを指定します。また、APIが認証を要求する場合は、「Authentication」設定でAPIキーなどを安全に設定することができます。これで、商品アイテムの数だけループが回り、1件ずつ在庫データがECサイトに反映されていくワークフローが完成しました。

失敗しないための応用テクニックとエラーハンドリング

基本的なワークフローを構築できるようになったら、次はそれをさらに堅牢で信頼性の高いものへと進化させましょう。実際の業務で自動化ワークフローを運用する上では、予期せぬデータ形式やエラーへの備えが不可欠です。ここでは、より実践的な応用テクニックと、安定稼働の鍵となるエラーハンドリングについて解説します。

複雑なXML構造への対応（ネスト、名前空間）

実世界のXMLデータは、サンプルで見るような単純なものばかりではありません。

深い階層構造（ネスト）: データが何層にもわたってネストしている場合、目的のデータにアクセスするには、JSONのパスを正しく指定する必要があります。n8nでは、{{ $('XMLノード名').item.json.order.items[0].details.color }} のように、ドット（.）で繋いで深い階層のデータも直感的に取得できます。
名前空間（Namespaces）: 業界標準のXMLフォーマットなどでは、<ns1:item xmlns:ns1="http://example.com/ns"> のように「名前空間」が使われることがあります。これが含まれていると、通常のパースではうまくデータを取得できないことがあります。XMLノードのオプションには「Remove Namespace Prefixes」という設定があり、これを有効にすることで、名前空間の接頭辞（この例では ns1:）を取り除き、よりシンプルなJSONとして扱うことが可能になります。

巨大なXMLファイルを扱う際の注意点

数万件の商品リストなど、非常にサイズの大きなXMLファイルを扱う場合、ワークフローを実行するサーバーのメモリを大量に消費し、パフォーマンスの低下やエラーの原因となる可能性があります。このような場合は、一度にすべてのデータを処理しようとせず、データを小さな塊（バッチ）に分割して処理するアプローチが有効です。

「Item Lists」ノードは、まさにこのために存在します。XMLをJSONに変換した後、このノードを使って例えば「100件ごと」にデータを分割します。そして、分割されたバッチ単位でループ処理を行うことで、一度にメモリにロードするデータ量を抑え、安定した処理を実現できます。これは、データベースの大量レコードを扱う際などにも応用できる、n8nのパフォーマンスチューニングにおける基本的なテクニックです。

「守りの自動化」を実装するエラーハンドリング

自動化ワークフローは、一度設定すれば終わりではありません。XMLの形式がいつもと違っていた、連携先のAPIがメンテナンスでダウンしていた、など予期せぬエラーは必ず発生します。問題は、エラーが発生したことに気づけるかどうかです。

n8nには、この「守りの自動化」を実装するための強力な仕組みとして「Error Trigger」ノードがあります。これは、同じワークフロー内のいずれかのノードでエラーが発生したときに、自動的に起動する特別なトリガーです。通常ルートの処理とは別に、エラー処理専用のルートを定義できます。

例えば、XMLノードでのパースに失敗したり、HTTP RequestノードがAPIエラーを返したりした場合、Error Triggerを起点として次のような処理を実行させます。

Slackノード: 運用担当者のSlackチャンネルに、エラーが発生したワークフロー名、ノード名、エラー内容を即座に通知する。
Emailノード: 関係者にエラー発生を知らせるメールを送信する。
Google Sheetsノード: 処理に失敗したデータを、後で確認・再処理できるようスプレッドシートに記録しておく。

このようにエラーハンドリングをしっかり組んでおくことで、「ワークフローが知らないうちに止まっていた」という最悪の事態を防ぎ、システムの信頼性を飛躍的に高めることができるのです。

まとめ：レガシーデータをn8nで価値ある資産へ

この記事では、多くの企業が抱えるレガシーシステム連携の課題に対し、iPaaSツール「n8n」がいかに強力な解決策となるかを見てきました。特に、古くから使われているXML形式のデータを、モダンなシステム標準であるJSON形式へといかにスムーズに変換できるか、その具体的なステップとテクニックに焦点を当てて解説しました。

要点を振り返ってみましょう。

レガシーなXMLとモダンなJSONの「データ形式の壁」がシステム連携の大きな障壁となっている。
n8nの「XMLノード」を使えば、コーディングなしで簡単にXMLをJSONに変換できる。
「Item Lists」や「Edit Fields」などのデータ操作ノードを組み合わせることで、連携先の要求に合わせた柔軟なデータ整形が可能になる。
実運用では、巨大ファイルへの対応や「Error Trigger」を使ったエラーハンドリングの実装が、ワークフローの安定性を左右する。

これまで「負の資産」と見なされがちだったレガシーシステムのデータも、n8nという強力なツールを使えば、ビジネスを加速させるための「価値ある資産」へと生まれ変わらせることができます。手作業でのデータ移行や、高コストな変換スクリプトの開発に悩んでいた日々は、もう過去のものです。

n8nの真価は、実際に触れてみることで最もよく理解できます。クラウド版には無料で始められるプランも用意されています。ぜひ、この記事で学んだテクニックを試しながら、そのパワフルな機能と直感的な操作性を体験してみてください。

＞＞まずは無料でn8nを試してみる

また、n8nの導入手順から基本的な使い方、さらに多様なユースケースまでを網羅的に解説した「n8n完全ガイド記事」もご用意しています。今日から始めるあなたの業務自動化への第一歩として、ぜひお役立てください。