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

CData Arc は、CData 製品の中でデータ連携の自動化を担う製品です。SaaS や基幹システムをつなぐアプリケーション連携に加えて、Box やSharePoint、Amazon S3 といったクラウドストレージとの連携や、SFTP やAS2 などの企業間のファイル転送プロトコルに対応したマネージドファイル転送（MFT）の機能も、Arc の大きな特徴の1 つです。

ファイル連携と一口に言っても、これまでの主な用途は、取引先との受発注データのやり取りのような企業間の連携や、Box やSharePoint のように人が使うコンテンツ管理の基盤との連携でした。最近はここに、AI に使わせる、AI に渡す、という用途が加わってきています。「Copilot やGemini が参照できる場所にファイルを届けたい」「届いた注文書をAI に読ませて、業務システムに登録したい」といったご相談をいただく場面も増え、ファイル連携に求められる役割が少しずつ広がってきている印象です。

こうしたご相談にあわせて、AI 活用に関連したファイル連携の機能やシナリオをご紹介する記事を、いくつか公開してきました。それぞれ切り口が少しずつ違い、ご紹介できるシナリオのバリエーションもだいぶ揃ってきました。

この記事では、AI の活用にも広がってきた CData Arc のファイル連携（MFT）のシナリオを、データ連携フローの「入口」「途中」「出口」の3 つに分けて、参考記事とあわせてご紹介します。

CData Arc

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

この記事でご紹介するシナリオの多くは、MFT コネクタとアプリケーションコネクタを同じフローの中で組み合わせることで成り立っています。kintone やSalesforce、データベース、HCL Domino などのデータも、ファイルと同じ流れで扱うことができます。

この記事の狙い（背景）

ファイルとAI の組み合わせについてご相談をいただくとき、実際に出てくる困りごとは、たとえば次のようなものです。

・取引先が毎週SFTP サーバーに置いてくれる販売実績が、Copilot からは見えない

・ファイルサーバーにはAI に見せたくない資料も混ざっていて、丸ごと同期するわけにはいかない

・見積書や仕様書が、Domino やkintone の添付ファイルのまま眠っている

・メールで届く注文書は書式が取引先ごとにバラバラで、結局人が読んで基幹システムに打ち込んでいる

もちろん、SharePoint やGoogle Drive の中にあるファイルをAI に読ませるだけであれば、AI サービス側の標準機能で十分なケースも多いと思います。ストレージやドキュメントを取り込む機能も、AI サービスの側で年々充実してきています。しかし上のような例を見ていただくと、困りごとの多くは「その手前」にあることが分かります。ファイルがどこかから届き、選り分けたり、変換したり、業務システムに登録したりしてから、AI が読める場所に置かれる。この「届いてから置くまで」の部分が、Arc の守備範囲です。

この記事では、こうした連携を「メッセージ指向のファイル連携」として整理してみます。

メッセージ指向のファイル連携

ここで言う「メッセージ指向」とは、1 つのファイルを1 通のメッセージとして扱い、届いたことをきっかけに、そのファイルの中身や属性を見て行き先と処理を決める、という考え方です。ストレージ全体をミラーリングのように同期するのではなく、「届いた1 件をどう扱うか」を積み重ねていくもの、と考えるとイメージいただきやすいかも知れません。

Arc でこの考え方を支えている要素は、主に次のとおりです。

・届いたら動く : SFTP での受信、メールの受信、Webhook、ストレージやファイルサーバーの定期的な取得など、ファイルが届いたことを起点にフローが動きます

・1 件ずつ判断する : Branch コネクタで、ファイル名やメタデータ、中身の値を見て後続の処理を振り分けることができます

・1 件ずつ追える : すべてのファイルがトランザクションとして記録され、失敗したファイルの再送やエラー時の通知も1 件単位で扱えます

・業務システムと同じフローで扱う : kintone やSalesforce、データベース、Domino などのアプリケーションコネクタと、ファイルの受け渡しを1 本のフローに組むことができます

・安心して運用できる : SLA（期待する件数と時間枠）の監視やアラート、OpenPGP による暗号化、保存時の暗号化など、MFT として求められる運用・セキュリティの機能を備えています

たとえば「アクティビティ」の「メッセージ」タブでは、どのファイルがどのコネクタから入り、どのコネクタまで処理されたのか、成功したのか失敗したのかを1 件ずつ確認できます。各コネクタの「トランザクション」タブからは、失敗したファイルだけを選んで再送することもできます。

ファイルが届いてから置かれるまでの流れを、入口・途中・出口に分けて図にすると次のようになります。

AI はこの流れの「出口」にも「途中」にも置くことができます。出口に置けば、AI が読める場所へファイルを「届ける」連携になります。途中に置けば、届いたファイルをAI に「読ませる」連携になり、その結果を業務システムに流すことができます。

一方で、ファイル連携と一口に言っても、Arc がフィットしない場面もあります。ファイルを扱う代表的な手段とあわせて、この記事での使い分けを整理すると次のようになります（以下の整理は、この記事独自の観点です）。

ストレージ全体を常に同期し続けたい、削除やアクセス権の変更までAI 側に追従させたい、といった要件では、AI サービス側の取り込み機能やファイル同期の専用ツールがフィットするケースもあります。また、動画や設計データのような大容量ファイルを一度に大量に転送する用途などは、それ専用に特化した転送ツールの得意とするところだと思います。Arc が価値を発揮するのは、業務のファイルを1 件ずつ受け取り、判断して、正しい場所へ届けるところです。

ここからは、この考え方に沿って「出口」「入口」「途中」の順にシナリオと参考記事をご紹介します。ご相談の多い「出口」からみていきましょう。

出口: AI が読める場所へ届ける

A. AI アシスタントの参照範囲へ、見せたいものだけを届ける

Microsoft 365 Copilot は主にSharePoint やOneDrive、Teams にあるファイルを、Gemini はGoogle Drive にあるファイルを参照して回答します。裏を返せば、AI に使わせたいファイルをその場所に届けてしまえば、AI 側に特別な設定をしなくても使い始めることができます。

ここでのポイントは「選んで届ける」ことです。ファイルサーバーの中身をすべてAI に見せたいわけではありませんし、取引先から届くファイルも、必要なものだけを部署のフォルダに置ければ十分なことがほとんどです。ファイル名やフォルダで対象を絞り、届いたものだけを届け先に置く、という連携はArc の得意とするところです。

この分類の参考記事は次の2 本です。

・SFTP に届く販売実績をCData Arc を利用してCopilot で分析できる場所へ：取引先がSFTP サーバーに置く販売実績ファイルを、Teams（SharePoint）のフォルダへ届けてCopilot で分析します。アクセス権やファイルの蓄積など、運用時の注意点にも触れています

・Gemini に見せたい資料だけを、CData Arc で Google Drive に届ける方法：各拠点がファイルサーバーに置く売上実績のExcel のうち、AI に見せたいものだけを共有ドライブに集め、Gemini に分析レポートとスライドを作ってもらいます

B. 社内ナレッジRAG のストレージへ集約する

社内ナレッジのRAG を構築する場合は、RAG の基盤が読み込むストレージを1 か所に決めて、そこへファイルを集めるのが基本の形です。実際の社内のファイルは、ファイルサーバー、Box、SharePoint、FTP サーバー、Dropbox と、あちこちに散らばっていることがほとんどです。

この形での役割分担は、Arc が「集めて整える」まで、インデックスの作成と検索はRAG の基盤が担う、というものです。Arc 側では、散らばった置き場所からファイルを集め、必要に応じて形式の変換や命名、振り分けを行ってから集約先に置きます。kintone の問い合わせ履歴のような業務アプリケーションのデータも、ファイルと同じフローで集約先に届けられるのは、アプリケーションコネクタを持つArc ならではの部分です。

[ex. Amazon Bedrock 編のフロー]

各クラウドサービスごとの参考記事が揃っています。普段お使いのクラウドサービスにあわせて選んでいただくのが良さそうです。Microsoft 365 を中心に業務が回っている企業であればAzure AI Search 編が、Google Workspace を利用されている企業であればAgent Search 編がイメージいただきやすいと思います。

入口: 閉じた場所からファイルを取り出す

AI に届けたいファイルが、いつも取引先からSFTP やメールで届くとは限りません。業務システムやストレージの中に閉じたまま、AI からも人からも使いにくくなっているファイルも少なくありません。こうしたファイルを取り出して出口へつなぐのは、CData Drivers 由来のアプリケーションコネクタを持つArc ならではの領域です。

A. 業務システムの添付ファイルを取り出す

長年使われてきたHCL Domino / Notes のデータベースには、案件情報や申請文書とともに、見積書や仕様書、構成図といった添付ファイルが大量に蓄積されています。これらはDomino の文書の中に埋め込まれているため、Domino クライアントを開かないと参照できません。

こちらの記事（CData Arc で HCL Domino/Notes の添付ファイルを Amazon S3 へ自動転送する）では、CData Domino コネクタで文書を取得し、Script コネクタで添付ファイルを復元して、案件ごとにAmazon S3 へ転送しています。S3 に届いた後は、先ほどのAmazon Bedrock 編につなげてRAG のナレッジにすることもできます。「入口」と「出口」の記事を組み合わせて読んでいただくと、1 本のシナリオとしてイメージいただけると思います。

[ex. Domino 編のフロー]

kintone の添付ファイルやレコードについても、考え方は同じです。前述のBedrock 編、Azure AI Search 編では、kintone のデータもRAG の集約先に届けています。

[ex. Amazon Bedrock 編のフロー（kintone の部分）]

B. ストレージのメタデータを見て扱いを変える

Box を全社のコンテンツ基盤としてお使いのお客さまからは、「Box に置かれたファイルを、付けているメタデータに応じて別々の届け先に渡したい」というご相談をいただくことがあります。メッセージ指向の「1 件ずつ判断する」がそのまま当てはまる例です。

こちらの記事（CData Arc の Box 連携 - Box コネクタ（MFT）の特徴と CData Box コネクタの使いどころ）では、フォルダ単位のファイルの出入口を担う「Box コネクタ（MFT）」と、メタデータも含めてBox のデータを扱える「CData Box コネクタ（Driver）」の使い分けをご紹介しています。Box API のコール数を気にされるお客さま向けの観点にも触れていますので、あわせてごらんください。

途中: 届いたファイルをAI に読ませて業務へ

ここまでのシナリオでは、AI は「出口」の先にいました。最後のパターンは、AI をフローの「途中」に置くものです。この場合、出口はAI の置き場所ではなく、基幹システムや業務アプリケーションになります。

こちらの記事（CData Arc -「AI コネクタ」で非定型データを構造化する）では、メールで届く書式バラバラの注文書を題材にしています。Email Receive コネクタで受信したメールをAI コネクタで分類・構造化し、Database コネクタのLookup アクションで得意先マスタと照合し、照合を通過したものは基幹データベースへ登録、曖昧なものは担当者の確認に回すフローです。

[ex. AI コネクタ編のフロー]

この記事でのポイントは「AI に任せる範囲、ルールで守る範囲」の線引きです。非定型の文面を読み取る部分はAI に任せ、その結果が正しいかどうかはマスタとの照合というルールで確かめる。決定論的なフローの中にAI を1 つのステップとして入れられることが、メッセージ指向のファイル連携とAI コネクタの相性が良い理由だと考えています。

「出口」との組み合わせも考えられます。たとえば、構造化した注文データは基幹システムへ登録し、元のPDF やメールは案件ごとのフォルダに保管してAI から参照できるようにする、といった連携も1 本のフローで組むことができます。

AI コネクタについては、こちらの記事（CData Arc - AI 機能の強化とAI コネクタの追加）や、2026.Q2（26.2）アップデートの記事でもご紹介しています。

その他

この記事では「届いたファイルをどこかへ置く」方向を中心にご紹介しましたが、逆方向の連携も同じ考え方で組むことができます。基幹システムや業務アプリケーションのデータからファイルを作り、取引先のSFTP サーバーやAI が読める場所へ届ける、といったシナリオです。

また、AI の側からArc のフローを呼び出す方向もあります。2026 Q3 のアップデートでは「組み込みMCP サーバ」が追加されていますので、興味のある方はあわせてごらんください。

ファイルとAI の組み合わせと言っても、要件や制約はさまざまです。どのようなアプローチがよりフィットするかは、それぞれのシナリオにあわせて選択してください。具体的なシナリオでの検討は、こちらからお気軽にご相談ください。

まとめ

この記事では、AI の活用にも広がってきた CData Arc のファイル連携（MFT）のシナリオを、データ連携フローの「入口」「途中」「出口」の3 つに分けて、参考記事とあわせてご紹介しました。

ファイルをAI のために集めること自体は、AI サービスの側でもできるようになってきています。Arc が役に立つのは、取引先や業務システムから届くファイルを1 件ずつ受け取り、判断して、正しい場所へ届けるところです。AI はその流れの出口にも途中にも置くことができ、出口ならAI に「届ける」、途中ならAI に「読ませる」連携になる、というのがこの記事での整理です。

この記事でご紹介した参考記事を、分類ごとにあらためて並べておきます。

出口: AI が読める場所へ届ける

・SFTP に届く販売実績をCData Arc を利用してCopilot で分析できる場所へ

・Gemini に見せたい資料だけを、CData Arc で Google Drive に届ける方法

・CData Arc × Amazon Bedrock で社内ナレッジ RAG を構築する

・CData Arc × Azure AI Search で社内ナレッジ RAG を構築する

・CData Arc × Agent Searchで、散在するファイルを自社のナレッジへ

入口: 閉じた場所からファイルを取り出す

・CData Arc で HCL Domino/Notes の添付ファイルを Amazon S3 へ自動転送する

・CData Arc の Box 連携 - Box コネクタ（MFT）の特徴と CData Box コネクタの使いどころ

途中: 届いたファイルをAI に読ませて業務へ

・CData Arc -「AI コネクタ」で非定型データを構造化する

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

皆さんのつなぎたいシナリオでぜひ CData Arc を試してみてください。

CData Arc - セキュアなデータ連携とマネージドファイル転送（MFT）

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

この記事は、2026/10/20 時点の情報をもとにしています。