連携の手段の選び方 — 純正・CSV・API・iPaaS・RPA を 6 つの物差しで比べる

調査の詳細

このページの答えは、以下の調べで出しました。対象・確認時期・出典を並べます。

一マスずつ見る：「壊れ方」が一番違う

総論の記事では、この軸を**「安定性」**という一語で書きました。ただ、比較表で「安定性 △」と書かれても何も分かりません。 **安定性の中身が「壊れ方」**です。つまり、何がきっかけで止まるのか。ここが5つの手段で一番はっきり違います。

CSVは「列がずれる」「文字が化ける」で止まる

CSVは、決められた順番に項目が並んだテキストファイルです。だから順番が変わると壊れます。

どのくらい細かく決まっているのか、数字で見てみます。編集部が12システムについて数えたところ、様式（あらかじめ項目の並びが決まっている入力面）は187件、定義された項目は合計12,542項目ありました。

内訳はこうです。

ここで扱うCSVは、上の17件・669項目のほうです。 残りはe-Gov電子申請の申請書XML構造定義やjGrantsの様式集から抜き出した項目定義で、CSVではありません。ただし**「システム間で受け渡すために、項目の並びがあらかじめ決められている」という点は同じ**です。

669項目が固定の順番で並んでいる、と考えてください。1つ挿入されれば、それ以降が全部ずれます。壊れたことにはすぐ気づきます（エラーになるか、明らかにおかしい値が入る）。そして直せます。Excelで開いて列を入れ替えれば済むからです。

文字化けも同じ種類の問題です。日本の業務システムのCSVは Shift_JIS 系のことがあり、UTF-8 を前提にすると一面が化けます。これも気づくし、直せます。

RPAは「画面が変わる」と止まる

RPAは人の操作を再生します。ボタンの位置や画面の構造が変わると、再生できなくなります。

厄介なのは、相手が業務システムのバージョンアップをしただけで起きることです。しかも予告されません。 「画面を改善しました」というお知らせは、RPAにとっては仕様変更です。

そして直すのは自分です。ベンダーは、あなたがRPAを使っていることを知りません。

APIは「相手の仕様が変わる」と止まる

APIは画面より安定しています。ただし変わらないわけではありません。

告知の仕方はシステムごとに違います。編集部が調べた範囲では、次の3通りがありました。

• 日付でバージョンを切り、旧版の提供終了日を明示する — HubSpot は2026年3月版から日付ベースのバージョニングに移り、エンドポイントは /api-name/2026-03/resource の形になっています
• 最低サポート期間を約束する — Salesforce Sales Cloud
• 予告なく変更する場合があると書く

3番目に当たった場合、止まってから気づくことになります。

なお、仕様変更の告知について公開資料から読み取れたのは56件中38件でした。残りは書かれていないか、確認できていません。

純正連携は「ベンダーが直す」

これが最大の利点です。相手の仕様が変わっても、ベンダーが自分で追随します。 あなたは何もしません。

そのかわり、できることはベンダーが決めた範囲だけです。

iPaaSは「コネクタが追随しない」ことがある

iPaaSは、AとBをつなぐ部品（コネクタ）を提供元が用意しています。相手の仕様が変われば、提供元がコネクタを直します。そこは純正連携に近いです。

ただし、コネクタがあるかどうかは組み合わせ次第です。そしてマイナーな業務システムのコネクタは、無いことのほうが多いです。

一マスずつ見る：「前提条件」で半分が消える

5つの手段のうち、どれが使えるかは前提条件で決まります。そして、この前提を満たさないケースがかなりあります。

APIの前提：「APIがあります」だけでは足りない

編集部が56システムのAPI公開状況を2つの軸で分類したところ、こうなりました。

さらに、「公開APIあり」の27件のうち5件は、特定の契約プランでないと使えません。 例としてSalesforce Sales Cloudは上位プラン限定です。

つまりそのまま使えるのは22件。半分以下です。

もう1つ。契約条件が公開資料から読めなかったのが28件ありました。これは編集部の調査不足ではなく、公開情報の側の状態です。

純正連携の前提：相手が用意していること

こちらは意外と有望です。56件中54件に、純正の連携機能についての記述がありました。

たとえばboardの公式まとめページには28件が掲載されています（編集部が数えた値・2026年8月24日再点検）。内訳はboard提供が17件、他社提供が11件で、freee会計とはAPI、マネーフォワード クラウド会計とはAPI/CSV、弥生会計とはCSV、という具合に相手ごとに手段が違うことまで書かれています。

ツールを買う前に読むべきページが、公式サイトに存在するということです。

CSVの前提：出力と取込ができること

CSV出力はほとんどのシステムにあります。問題は取込側です。取り込める様式が決まっているので、出力側の並びと一致しないと、間に変換が要ります。

RPAの前提：画面を操作できること

これはほぼ常に満たされます。RPAが最後の手段として機能するのは、前提条件がほとんど無いからです。 そのかわり壊れやすい。

一マスずつ見る：費用

費用については、公開価格がある層と無い層があります。

編集部の調査記録には、つなぎ役のツールが42件（iPaaS 20件・RPA 12件・ベンダー純正 7件・第三者提供 2件・画面操作 1件）入っています。このうち公開価格を確認できたのは36件でした。

具体的な価格は別の記事で扱いますが、ここで押さえておきたいのは構造です。

• ①と②は自分で調べられます
• ③だけが調べられません

つまり見積もりの何割が③なのかは、①と②を自分で調べれば逆算できます。

つなぎ役の価格について、いま言えることは3つです。

• RPAの価格は、月1万円台から買い切り100万円超まで幅があります。 同じ「RPA」という言葉の中に2桁の開きがあります
• 価格を公開していないベンダーがあります。 iPaaS 20件のうち7件は要問合せ・申込書に記載でした
• したがって**「RPAは安い」「iPaaSは高い」という一般化は成り立ちません**

比べるなら、自分の要件（連携の本数・1日のデータ量・繋ぎたい相手）を先に決めてからです。それが決まらないうちは、どのプランが必要かが決まらず、価格を並べても意味がありません。

RPAの費用については、もう1つ注意点があります。RPAは画面を操作するので、操作される画面がどこかに開いている必要があります。 つまりパソコンが1台要ります。夜間に動かすなら電源は切れません。「ツールの利用料は月○円」という見積もりに、そのパソコンの費用が入っているとは限りません。

一マスずつ見る：誰が直すか

止まったあと、誰が電話を受けるのかという話です。ここは稟議に書ける形にできます。

一番差が出るのはAPIです。 作った開発会社との関係が切れていると、直せる人がいなくなります。

だから契約前に、この3つを決めておいてください。

1. 保守は誰が持ちますか。 月額に含まれますか、その都度の見積もりですか
2. 止まったとき、どこに連絡しますか。 ベンダーですか、開発会社ですか
3. 直るまでの間、手作業に戻せますか。 戻せないなら、業務が止まります

3番目が抜けやすいです。自動化すると、元の手順を誰も覚えていない状態になります。手順書だけは残しておいてください。

一マスずつ見る：できる範囲

最後の物差しです。ここまで読むと、RPAは費用も壊れやすさも一番不利に見えます。それでも最後の手段として残る理由が、この列にあります。

CSVの範囲は具体的な数字で見られます。freee会計は出力161項目・取込89項目、ジョブカン勤怠管理は出力184項目・取込59項目です。

注目してほしいのは、出力より取込のほうが少ないことです。 渡せるのは受け取る側の様式が上限になります。「184項目出せます」と言われても、相手が59項目しか受け取らないなら、渡るのは59項目です。

APIも同じです。編集部が数えた範囲で、公開済み28システムのAPIが扱う対象は747件でした。その一覧に自分が動かしたいものが載っていなければ、APIがあっても届きません。 ジョブカン会計の公開APIは8本すべてGET（取得）で、書き込みはできません。

そしてRPAだけが、この制約を受けません。 画面から入力できることは、全部できます。他社の古い業務システムでも、社内の独自システムでも、画面があれば操作できます。

これがRPAが消えない理由です。壊れやすく、パソコンを1台占有し、直すのは自分。それでも**「他に手段が無い」場面が実際にある**からです。

だから調べる順番は、RPAを最後に置くのが正しい。先に4つを潰して、それでも残ったものにRPAを当てる、という順番です。

どこで動くのか

もう1つ、比較表に載らない違いがあります。その処理はどこで動くのかです。

ここが、費用と安全の話に直結します。RPAは機械が要ります。iPaaSはデータが一度提供元のクラウドを通ります。

実際に1件やってみる

手順だけだと分かりにくいので、よくある要件を1つ通してみます。

要件：請求管理システムで作った請求データを、会計ソフトに毎月流したい。件数は月80件。

手順1｜ベンダー純正を調べる

請求管理側の公式サイトで「連携」を検索します。board を使っているなら、公式のまとめページに27件が載っていて、相手ごとに手段まで書かれています。

• 会計ソフトが freee会計 → API。設定するだけ
• 会計ソフトが マネーフォワード クラウド会計 → API / CSV。どちらでもいい
• 会計ソフトが弥生会計・勘定奉行 → CSV

ここで多くの場合は終わります。 前の2つなら、この時点で費用ゼロ、保守もベンダー持ちです。

手順2｜CSVを調べる（純正が無かった場合）

出す側と受ける側の両方で、CSVの様式を確認します。出力と取込では項目数が違うので、両方見ます。

月80件なら、人が月1回操作しても15分程度です。この規模で自動化の開発費を出す理由は、たいていありません。

自動化するとしても、CSVの出力と取込をパソコンに定期実行させるだけで足ります。

手順3｜APIを調べる（件数が多い、または毎日流したい場合）

ここで初めてAPIです。確認するのは4つ。

1. 双方に公開APIがあるか
2. いまの契約プランで使えるか
3. 「入れる」ができるか（取得だけではないか）
4. 呼び出し回数の上限は足りるか

月80件なら、上限で困ることはまずありません。 上限が問題になるのは、1日数千件を流すような規模です。

手順4｜iPaaSを調べる（自分で作りたくない場合）

両方のコネクタがあるかを確認します。片方でも無ければ、その1つのために別の手段が要ります。

月額は3,000円から48万円まで幅があるので、**月に何回動かすか（80件×処理数）**を先に決めてから料金表を見ます。

手順5｜RPAを検討する（ここまで全部だめだった場合）

パソコンを1台用意することになります。月80件のために1台占有するのは、たいてい割に合いません。

この要件なら、手順1か2で終わります。 そしてそれが正しい結論です。

ここでの調査範囲について

• 対象は、編集部が一次調査を終えて公開している56システムと、調査記録に収録した42ツールです。日本の業務システム全体ではありません。
• 確認時期は2026年7月28日〜8月19日です。仕様も価格も変わります。
• 「公開情報を確認した範囲では見つからなかった」と「機能が無い」は区別しています。
• 壊れやすさの頻度、ツール個社の優劣、市場シェアは調べていません。

各システムの「純正連携」「API」「価格」の欄は、RenkeiMapで1件ずつ公開しています。主な参照先はboard、freee会計、マネーフォワード クラウド会計、弥生、kintone、HubSpot、Salesforce Sales Cloud、e-Gov電子申請、jGrants、楽楽精算 です。つなぎ役のツールはこちら。