こんにちは。CData Software Japan の色川です。

先日公開した「こちらの記事」では、CData Arc 2026.Q2（26.2）アップデートの主な新機能をご紹介しました。中でも特に関心をいただくことが多いのが、26.2 で正式リリース（GA）となった「AI コネクタ」です。

AI コネクタは、データ連携フローの中にLLM（大規模言語モデル）を呼び出すステップを組み込むことができる、待望の新機能です。AI コネクタを活用すると、これまでは難しかった自動化、たとえば「非定型のデータを、決定論的なデータ連携フローに流し込む」ことに手が届くようになります。「非定型のデータ」として分かりやすい代表的な例の1つが「電子メールでの受発注データ」かも知れません。

電子メールの本文からデータを定型化して取り出す話は、以前に「こちらの記事」でもご紹介しました。ただし、このアプローチには「ロジック化できる規則で書かれていること」という前提があります。規則さえ読み解ければ、ルールベースの処理で確実に、繰り返し同じ結果を得られます。

一方で、人がその都度書く文章には規則がありません。パースのロジックを書きようがなく、これまではオートメーションの対象外でした。AI コネクタが扱えるようにするのは、まさにこの領域です。ルールで書けるものはルールで、書けないものはLLM の判断で。この使い分けが1つのフローの中でできるようになったことが、26.2 のアップデートの大きな価値の1つです。

非定型データの多い業務の1つが受注業務かも知れません。「大口の取引先とはEDI でつながっているが、それ以外の取引先からの注文は今もメールとFAX のまま。そこだけ人手の転記が残っている」というご相談はよくいただきます。この記事では、CData Arc の「AI コネクタ」を使って、メールで届く非定型の注文データをフローの入口で構造化し、基幹システムへの連携につなぐ構成パターンをご紹介します。

この記事の狙い（背景）

こちらの東京商工会議所の調査によると、中小企業の受発注手段は「EDI（電子データ交換）による受発注システムを導入」が13.6% にとどまり、「電話・FAX」が24.6%、「メール・ホームページ等オンライン」が48.8% を占めています。

参考: 東京商工会議所「中小企業のデジタルシフト・DX実態調査」

また、経済産業省の調査でも、2024年のBtoB-EC 化率は43.1% です（この「EC」には従来型EDI も含まれます）。マクロでみても、企業間取引の半分以上は電子取引に乗っていないのが日本の受発注の実態と言えるでしょう。

これを「数百社の取引先から注文を受ける側」から見ると、おなじみの構図がみえてきます。大口の取引先とは標準EDI やWeb-EDI でつながっている。しかし残りの多数は、取引量に対してEDI 接続のコストが見合わず、今もメールやFAX で注文が届き、受注担当が基幹システムへ目視で転記している。いわば「受注のロングテール」だけが、自動化から取り残されている構図です。

実際の業務の中で届く「メールでの注文」とは、たとえば以下のような本文でのやりとりも多いのではないかと思います。

いつものM10のボルトを5箱と、あとベアリングも在庫があれば2つお願いします。
なるべく早めにもらえると助かります。

受注担当の方であれば、このメールの送信元である取引先の顔を思い浮かべながら適切に判断できるでしょう。しかし、この文章から品番や納期を取り出すルールを書くことは困難です。ルールベースで取り出せないから、自動化フローに乗せられない。これが「取り残されている」ことの正体だと思います。

EDI・CSV・XML といった構造化データの変換やマッピングは、これまでのArc でも得意とするところでした。ただし、決定論的なマッピングはスキーマの分かっているデータが前提です。26.1 で強化された「AI アシストマッピング」も、設計時（マッピング定義作成）の支援機能でした。26.2 のAI コネクタは、実行時にデータそのものを処理します。LLM による判断をフローに組み込めることで「これまで自動化フローに入れられなかった種類のデータを扱えるようになる」ことが、AI コネクタの大きな価値の1つだと思います。

CData Arc

CData Arc は、CData 製品の中で「自動化/Automate」を担うデータ連携ツールです。「B2B 連携をもっとシンプルに」をコンセプトに、ファイル連携 & DB 連携 & API 連携といったB2B 連携に必要なすべてをノーコード・ローコードでつなぐことができるプラットフォームです。

Arc のAI コネクタ

Arc の「AI コネクタ」は、データ連携フローの中にAI モデルによる推論や判断を組み込むことができるコネクタです。26.1 でベータ版として搭載され、26.2 で正式リリース（GA）となりました。LLM プロバイダーはOpenAI、Anthropic Claude、Gemini、xAI Grok、Ollama、DeepSeek、OpenAI 互換と幅広く、データプライバシーやワークロードの要件にあわせて選択できます。

システムプロンプトとユーザープロンプトで処理内容を指示し、設定タブの「Output In JSON」を有効化してJSON スキーマを指定すると、後続のフローで扱いやすいJSON として結果を受け取ることができます。具体的な使い方や動作イメージは「こちらの記事」で詳しくご紹介しています。あわせてごらんください。

Arc の「AI コネクタ」は豊富なLLM プロバイダーに対応していますが、どのプロバイダーを選んでも、フローの中での扱い方は変わりません。まずは手軽なクラウドのモデルで試して、後からローカルホストのモデルへ寄せる、といった進め方もできます。

AI コネクタ利用時の留意点

LLM の出力は確率的であり、同じ入力に対して、常に同じ出力が保証されるわけではありません。この記事では、AI コネクタに任せる範囲を「分類と構造化」に限定し、業務的な正しさの判定（マスタ照合・妥当性検証）は従来どおりの決定論的なルールで行っています。このような役割分担は、本番用途の業務フローで活用いただく際に重要な考え方だと思います。

もう1つ、AI コネクタは入力メッセージを変換して出力するため、AI が返した内容でメッセージ（コネクタにおける処理対象データ）が置き換わります。後続のステップで元のデータも参照したい場合は、それを見越した設計が必要です。この記事では、JSON スキーマへ元のメール本文を含めることで対応しています。

この記事のシナリオ

この記事のシナリオは「取引先からメールで届く注文を、AI コネクタで分類・構造化し、マスタ照合を通過したものは基幹データベースへ自動登録、曖昧なものは担当者の確認に回す」ことをイメージしています。

まず、連携フローで扱う対象として性格の異なる3通のメールを用意しています。実際の受注業務におけるメールボックスにも、こうした記載内容のメール（非定型のデータ）が混在している場面が多いのではないでしょうか。

1通目は、品番・数量・単位・納期がすべて明記された注文。2通目は「いつものM10のボルト」「なるべく早めに」で、品番も納期も文面からはルールベースで確定することができない内容です。3通目は品番も数量も書かれていますが、新規注文ではなく納期の相談です。キーワードで振り分けようとすれば3通目も注文として処理されてしまうことが想定されます。文面の意図、すなわちデータの文脈を読まなければ区別できないのが、この領域の難しさです。この記事では、この3通が、それぞれ違う出口へとフローをたどるところまでを見ていきたいと思います。

もう1つのポイントは、この非定型受注のフローが、既存のEDI やファイル連携と「同じArc の基盤上」に載ることです。非定型データの処理に特化した専用の仕組みを別に立てるのではなく、運用中の受注基盤にもう1つの入口（非定型データ用のフロー）を足す構成になるので、基幹側への連携・エラー処理・ログはすべて共通の運用に乗せることができます。まさに、あらゆるB2B 連携をワンプラットフォームでつなぐことを志向するArc にふさわしい新機能と言えます。

この記事の連携フローは次の構成です。

実際のフローイメージとしては次のとおりです。

AI に任せる範囲、ルールで守る範囲

このシナリオでの基本的な設計思想は、各処理を「AI に任せる範囲」と「ルールで守る範囲」に分けることにあります。

「AI コネクタ」は従来のマッピング（XML Map）を置き換える機能ではなく「XML Map の手前の一段（非構造データから構造データへ）を埋める機能」と捉えるとイメージしやすいかも知れません。構造化さえできれば、後段はこれまでどおりの決定論的なデータ連携フローの領域です。

もう1つ、この記事でポイントとして置いた原則は「読み取れない項目はnull にさせ、推測で埋めさせない」ことです。LLM は空欄をもっともらしい値で埋めようとしますが、実際の企業における受注業務では「分からないことが分かる」ほうが重要です。曖昧なデータは後続の照合で弾くようにフローを設計し、人の確認に回します。いわゆる「Human-in-the-loop」の考え方です。

フロー各ステップのポイント

1. 受信（Email Receive コネクタ）

受注用メールボックスを監視するEmail Receive コネクタを設定します。26.2 で刷新された新バージョンのコネクタでは、認証情報を「共有接続」として複数のフローで再利用できます。

「Download Type」の設定で、メール本文を後続のフローに流すか、添付ファイルを流すかを選択することができます。この記事ではメール本文に注文が書かれているケースを想定していますので、本文を対象として設定しています。「メール本文は挨拶だけで、中身は添付の注文書」というケースは、記事後半の「その他（応用と代替アプローチ）」が参考にしていただけると思います。

2. 分類（AI コネクタ）

最初のAI コネクタで、受信したメールを「新規注文 / 変更 / キャンセル / 問い合わせ」の4種類に分類します。「AI Config」タブでプロバイダーとモデルを選び、プロンプトを設定します。

システムプロンプトには以下のように設定しました。

あなたは受注業務のアシスタントです。入力されるメールを次の4種類に分類してください。

- new_order: 新規の注文
- change: 既存注文の変更依頼
- cancel: 既存注文のキャンセル依頼
- inquiry: 問い合わせ・それ以外

判断に迷う場合は inquiry に分類してください。
出力はJSON で、category（分類）、reason（判断理由・日本語で簡潔に）、original_text（入力メールの全文）の3項目としてください。
original_text には入力されたメールの本文を、要約・省略をせず原文のまま含めてください。

ユーザープロンプトに [_message.body] を指定することで、受信メッセージがそのまま渡ります。「判断に迷う場合はinquiry」という指示は、誤って注文として処理するより、人の目に触れる側へと倒す（Human-in-the-loop にする）ための設計です。スキーマに original_text（メール原文）を含めているのは前述（AI コネクタ利用時の留意点）の振舞いを想定した対応で、この考慮によって次の構造化ステップにも元のメール本文が渡ります。

「Output In JSON」とJSON スキーマは「設定」タブで指定します。

{
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": [
        "new_order",
        "change",
        "cancel",
        "inquiry"
      ]
    },
    "reason": {
      "type": "string"
    },
    "original_text": {
      "type": "string"
    }
  },
  "required": [
    "category",
    "reason",
    "original_text"
  ],
  "additionalProperties": false
}

3. 分類による分岐（Branch コネクタ）

AI コネクタの出力はJSON なので、JSON コネクタでXML に変換してから、Branch コネクタでXPath による判定を行います。

「最初に一致するXPath」に /json/category を指定しnew_order は構造化ステップへ、それ以外は担当者へ転送する設定としています。条件と出力先がUI 上にそのまま並びますので、分岐のルールは設定画面で分かりやすく確認することができます。

4. 構造化（AI コネクタ）

2つ目のAI コネクタでは「注文メールから注文明細を抽出」します。プロンプトの要点は「推測させない」ことに重きを置いています。

あなたは受注データの抽出アシスタントです。入力データのoriginal_text 要素に含まれる注文メールの本文から、注文明細を抽出してください。

ルール:
- メールに書かれていない項目は推測せず null にしてください。
- ITEM_CODE は、メールに品番（例: P-1024）が明記されている場合のみ設定してください。品名だけで品番が書かれていない場合は null にしてください。
- ITEM_AS_WRITTEN には、品目のメールでの記載文字列をそのまま設定してください。
- CUSTOMER_NAME は、メールに記載された得意先の会社名を記載どおりに設定してください。
- QUANTITY は数値、UNIT は単位（箱・袋・個など）です。
- DELIVERY_DATE は YYYY-MM-DD 形式にしてください。「なるべく早く」など日付として読み取れない場合は null にしてください。
- 1つの注文明細（品目×数量）ごとに T_ORDER 配列の1要素としてください。

JSON スキーマは、すべての項目でnull を許容していることがポイントです。

{
  "type": "object",
  "properties": {
    "T_ORDER": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "CUSTOMER_NAME": {
            "type": [
              "string",
              "null"
            ]
          },
          "ITEM_CODE": {
            "type": [
              "string",
              "null"
            ]
          },
          "ITEM_AS_WRITTEN": {
            "type": [
              "string",
              "null"
            ]
          },
          "QUANTITY": {
            "type": [
              "number",
              "null"
            ]
          },
          "UNIT": {
            "type": [
              "string",
              "null"
            ]
          },
          "DELIVERY_DATE": {
            "type": [
              "string",
              "null"
            ]
          }
        },
        "required": [
          "CUSTOMER_NAME",
          "ITEM_CODE",
          "ITEM_AS_WRITTEN",
          "QUANTITY",
          "UNIT",
          "DELIVERY_DATE"
        ],
        "additionalProperties": false
      }
    }
  },
  "required": [
    "T_ORDER"
  ],
  "additionalProperties": false
}

得意先名や品目は「記載どおりの文字列」で抽出させ、この段階では正規化（マスタのコードへの変換）についてはまだ実施させていません。コードの確定は、次のステップで決定論的に行います。

5. 検証（Database コネクタのLookup アクション）

抽出された得意先名を得意先マスタと照合し、得意先コードへ確定させるステップです。Database コネクタの「Lookup」アクションは、メッセージの値をパラメータにSQL を実行し、結果を同じメッセージに書き戻すことができます。

設定は「デザイナー」タブのGUI で組み立てられます。「サンプルファイル」に前ステップとなるコネクタの出力データを設定しておくと、Arc がデータ構造を把握できて設定しやすくなります。この記事の例では次のクエリを構成しています。

SELECT CUSTOMER_CODE FROM APP.M_CUSTOMER WHERE (CUSTOMER_NAME = ${XPATH:/Items/T_ORDER/CUSTOMER_NAME})

メッセージ内の値を参照するパラメータは ${XPATH:/絶対パス} という記法です。デザイナーで組み立ててから「クエリ」タブで確認すると、記法を意識せずに設定することができます。「アウトプットデスティネーション」には、書き戻し先を（カラム名まで含めた）XPath で指定します。

この記事のフローにおいて、このステップが「AI の答えをそのまま信じない」ためのポイントとも言えます。マスタと突合して確定できなければ先のステップへと進めないようにする。この決定論的な検証ステップがあるからこそ、前ステップにおいてAI（LLM）の能力を安心して業務に組み込めるようになっています。

6. 照合結果による分岐と通知

2つ目のBranch コネクタでは「すべての項目が埋まっているか」を判定します。

「一致するすべてのXPath」に /Items/T_ORDER/* を指定し、すべての要素が空でなければ基幹データベースへの登録（Upsert）へ。1つでも空（AI がnull を返した、または照合がマッチしなかった）なら担当者の確認キューへと通知します。なお、26.2 のEmail Send コネクタではSendGrid も新たにサポートされています。

担当者が確認・修正した注文を再度フローに戻す運用まで含めて、Human-in-the-loop の受注プロセスが完成しました。本番業務への導入を想定した場合、導入当初は確認キュー側へと倒す比率を高めにして、実行結果の傾向を見ながら自動登録の範囲を広げる、という段階的な導入が現実的かも知れません。

連携フローの実行

それでは作成したフローを実行して確認してみましょう。シナリオで挙げた3通、「明確な注文」「曖昧な注文」「（注文ではない）納期相談」を、順に受注メールボックスから処理していきます。

実行した後、AI コネクタのトランザクションタブでは、メールごとに分類結果のJSON が生成されていることが確認できます。

1通目の「明確な注文」メールに対する分類結果は以下のようになりました。

{
  "category": "new_order",
  "reason": "\u5177\u4F53\u7684\u306A\u54C1\u756A\u30FB\u6570\u91CF\u30FB\u5E0C\u671B\u7D0D\u671F\u30FB\u5C4A\u3051\u5148\u304C\u8A18\u8F09\u3055\u308C\u305F\u65B0\u898F\u6CE8\u6587\u306E\u305F\u3081\u3002",
  "original_text": "..."
}

後続である構造化ステップの出力結果は以下の通りです。品番・数量・単位・納期が、正しく項目に収まっていることが分かります。この注文はマスタ照合を通過し、期待通りに基幹データベースへ自動登録されました。

{
  "T_ORDER": [
    {
      "CUSTOMER_NAME": "\u682A\u5F0F\u4F1A\u793E\u5C71\u5DDD\u91D1\u5C5E\u5DE5\u696D",
      "ITEM_CODE": "P-1024",
      "ITEM_AS_WRITTEN": "\u54C1\u756A P-1024 \u516D\u89D2\u30DC\u30EB\u30C8 M10\u00D730 \u30B9\u30C6\u30F3\u30EC\u30B9",
      "QUANTITY": 20,
      "UNIT": "\u7BB1",
      "DELIVERY_DATE": "2026-08-07"
    },
    {
      "CUSTOMER_NAME": "\u682A\u5F0F\u4F1A\u793E\u5C71\u5DDD\u91D1\u5C5E\u5DE5\u696D",
      "ITEM_CODE": "P-2088",
      "ITEM_AS_WRITTEN": "\u54C1\u756A P-2088 \u30D5\u30E9\u30F3\u30B8\u30CA\u30C3\u30C8 M8",
      "QUANTITY": 10,
      "UNIT": "\u888B",
      "DELIVERY_DATE": "2026-08-07"
    }
  ]
}

2通目の「曖昧な注文」メールでは、出力は次のようになりました。

{
  "T_ORDER": [
    {
      "CUSTOMER_NAME": "\u4F50\u91CE\u5546\u5E97",
      "ITEM_CODE": null,
      "ITEM_AS_WRITTEN": "\u3044\u3064\u3082\u306EM10\u306E\u30DC\u30EB\u30C8",
      "QUANTITY": 5,
      "UNIT": "\u7BB1",
      "DELIVERY_DATE": null
    },
    {
      "CUSTOMER_NAME": "\u4F50\u91CE\u5546\u5E97",
      "ITEM_CODE": null,
      "ITEM_AS_WRITTEN": "\u30D9\u30A2\u30EA\u30F3\u30B0",
      "QUANTITY": 2,
      "UNIT": "\u3064",
      "DELIVERY_DATE": null
    }
  ]
}

品番が書かれていないので ITEM_CODE はnull、納期が読み取れないので DELIVERY_DATE もnull です。「いつものM10のボルト」から品番を推測せず、読み取れないことを読み取れないまま返していることが分かります。このメッセージはBranch コネクタで弾かれて、担当者の確認キューへ回りました。

3通目の「（注文ではない）納期相談」は change（既存注文の変更依頼）と分類され、基幹登録の経路には乗らずに担当者へ転送されました。判断理由も「先日注文した商品の納期を1週間前倒しできるかという、既存注文の変更依頼のため。」と出力され、分類の根拠まで確認できます。

そして3通の行き先は、フロー画面の処理件数がそのまま示してくれています。

受信メールの分類ステップ（ClassifyMail）で処理したのは3件です。注文の2件だけがExtractOrder へ進み、1件が基幹登録へ、1件が確認キューへ、問い合わせ（変更依頼）の1件は担当者への転送へと進んでいます。フロー設計での期待通りに、3通がそれぞれの経路へ振り分けられていることが確認できます。

その他（応用と代替アプローチ）

実際の受注業務においては「メール本文は挨拶だけで、注文の中身は添付の注文書」というケースも多いはずです。この場合はEmail Receive の「Download Type」で添付ファイルを取得・処理する設定にして、AI コネクタの「入力メッセージをリクエストに添付する」を有効にします。メッセージが添付ファイルとしてLLM へのリクエストに追加されますので、PDF や画像を直接渡すための設定として有効です。

実際、この記事の執筆時点（2026/07）のモダンなLLM に渡してどのくらい実用になるのか、テキスト層を持たない画像のみのPDF（スキャンした注文書に相当するイメージ）で試してみました。

これをAI コネクタに添付として渡した結果です。

{
  "T_ORDER": [
    {
      "CUSTOMER_NAME": "\u682A\u5F0F\u4F1A\u793E\u5C71\u5DDD\u91D1\u5C5E\u5DE5\u696D",
      "ITEM_CODE": "P-1030",
      "ITEM_AS_WRITTEN": "\u516D\u89D2\u30DC\u30EB\u30C8 M12\u00D740 \u30B9\u30C6\u30F3\u30EC\u30B9",
      "QUANTITY": 15,
      "UNIT": "\u7BB1",
      "DELIVERY_DATE": "2026-08-20"
    },
    {
      "CUSTOMER_NAME": "\u682A\u5F0F\u4F1A\u793E\u5C71\u5DDD\u91D1\u5C5E\u5DE5\u696D",
      "ITEM_CODE": "S-5010",
      "ITEM_AS_WRITTEN": "\u5E73\u30EF\u30C3\u30B7\u30E3\u30FC M10",
      "QUANTITY": 8,
      "UNIT": "\u888B",
      "DELIVERY_DATE": "2026-08-20"
    },
    {
      "CUSTOMER_NAME": "\u682A\u5F0F\u4F1A\u793E\u5C71\u5DDD\u91D1\u5C5E\u5DE5\u696D",
      "ITEM_CODE": "A-3350",
      "ITEM_AS_WRITTEN": "\u30D9\u30A2\u30EA\u30F3\u30B0\u30E6\u30CB\u30C3\u30C8 UCP205",
      "QUANTITY": 4,
      "UNIT": "\u500B",
      "DELIVERY_DATE": "2026-09-04"
    }
  ]
}

明細ごとに正しく分解され、3行目だけ納期が異なる点まで読み取れています。AI-OCR によるテキスト化を前処理として設けなくても、添付するだけで構造化まで到達できる期待が持てることが分かります。

ただし、プロバイダーとモデルがそのファイル形式を読めることが前提です。ローカルホストのモデルなどファイル入力に対応しないケースや、Excel（.xlsx）のようにファイル入力でサポートされないことが多い形式では、「Excel コネクタ」でXML 等のデータ形式に変換してから渡す構成が確実かも知れません。なお、後続のステップである照合・分岐・登録については、記事本編のフローと同じ構成で実現いただけるでしょう。前述のとおり、フローの入口における構造化部分だけを差し替えれば、同じ受注基盤に載せられることが大きなメリットの1つだと思います。

この記事では、非定型データの分かりやすい代表例として「メール本文」を扱いました。しかし、フォーマットの定まらないデータが流れてくる連携インタフェースは、電子メールだけではありません。例えば、以下のようなインタフェースで連携されるファイルも代表的な例でしょう。

・FAX 由来のスキャンファイル: 複合機やFAX サーバがファイルサーバ・SFTP サーバに出力するファイルを、File コネクタやSFTP コネクタで取り込む

・Web-EDI ポータルからのダウンロードファイル: 取引先ごとにレイアウトの違うCSV・Excel を、同じAI 構造化ステップへ流し込む

いずれの場合も、入口となるコネクタが変わるだけで、本質はその直後にある「AI による構造化」のステップです。非定型データの多い連携インタフェースであれば、この記事と同じ構成パターンで対応を検討いただけると思います。どのアプローチがフィットするかは、それぞれのシナリオにあわせて選択してください。

なお、関連する領域での近年のトピックとして、デジタル庁がJapan Peppol Authority として管理する「デジタルインボイスの標準仕様（JP PINT）」は国際標準仕様である「Peppol」をベースにしており、メッセージ交換は「AS4 プロトコル」で規定されています。国内の企業間取引にも、国際標準ベースの構造化されたデータ交換の波が届き始めている状況と言えるでしょう。AS2/AS4 やEDI フォーマットのデータマッピングにフィットする機能性を持つArc であれば、「今の非定型受注の構造化」と「将来の標準化されたデータ交換」を、同じ基盤の延長線上で考えていただくことができます。

まとめ

この記事では、CData Arc の「AI コネクタ」を使って、メールで届く非定型の注文データをフローの入口で構造化し、基幹システムへの連携につなぐ構成パターンをご紹介しました。

ルールで書けるものはルールで、ルールで書けないものはLLM の判断で。この記事で取り上げた「メールとFAX の受注」は、AI コネクタによって自動化できるようになるシナリオの分かりやすい一例です。人がその都度書いた文章、取引先ごとに形の違うファイル。規則を書けないために連携基盤の外側に残っていたデータは、業種・業態を問わず存在していると思います。CData Arc 26.2 でGA となった「AI コネクタ」は、そうした領域を「自動化できる連携基盤」へと取り込む、画期的な新機能と言えます。

もちろん、リトライ・エラー処理・トランザクションログ・監査といった既存の連携業務においても重宝いただいているガバナンス機能は、AI コネクタによって新しく実現できる自動化業務においても従来同様に機能します。逆に「AI の部分だけをスクリプトで内製するアプローチ」では、このような運用まわりへの考慮も自作する必要が出てくるでしょう。「業務データ連携の基盤にAI（LLM の知能）を挟める」ことこそ、Arc の「AI コネクタの実務的な価値」だと思います。皆さんの現場に残る「規則を書けないデータ」でも、検討いただく価値があるのではないでしょうか。

CData Arc はシンプルで拡張性の高いコアフレームワークに、豊富なMFT・EDI・エンタープライズコネクタを備えたパワフルな製品です。業界最多級のコネクタにより、業種業界を問わず、企業のデータ連携自動化で幅広く活用いただけます。

皆さんのつなぎたいシナリオでぜひ CData Arc を試してみてください。
CData Arc | データ連携、EAI、マネージドファイル転送（MFT）、電子データ交換（EDI）のオールインワンツール

製品を試していただく中で何かご不明な点があれば、テクニカルサポートへお気軽にお問い合わせください。
CData - サポートフォーム

この記事では CData Arc™ 2026 - 26.2.9686.0 を利用しています