「システムをつなぎたい」と相談すると、まずAPIの話になります。でも実際に業務が回るようになった事例を聞いてみると、CSVの受け渡しで終わっていたり、そもそもベンダーの標準機能で足りていたりします。

「結局、うちの場合はどれで繋ぐのが一番ラクで、いくらかかるのか」

これが、この記事で答えたい問いです。

つなぐ手段は5つあります。API、CSV、RPA、iPaaS、そしてベンダー純正の連携機能です。

この5つを、公開されている価格と仕様の範囲で比べてみました。ランキングを付けるためではありません。「うちの場合はどれか」を、自分で判定できるようにするためです。

先に結論を書きます。

調べる順番は、純正 → CSV → API → iPaaS → RPA です。
APIから調べ始めると、たいてい遠回りになります。

総論の記事では、5つの手段を ◎○△ の一覧にするところまで書きました。この記事は、その一マスずつに何が入っているのかを、実際のシステム名で開いていきます。

1. 「ラク」を6つの物差しに割る

「どれが一番ラクですか」という質問には答えられません。何がラクなのかが人によって違うからです。そこで6つに割ります。

物差し	何を聞いているのか
前提条件	それを使うために、何が揃っている必要があるか
自動化の程度	人が何回触るか
壊れ方	止まるとき、何がきっかけで止まるか
誰が直すか	止まったとき、直すのは誰か
費用	初期にいくら、毎月いくら
できる範囲	どこまでできて、どこからできないか

このうち、見積書に出てくるのは「費用」だけです。残りの5つは自分で確認する必要があります。

2. 5つの手段を並べる

	前提条件	自動化	壊れ方	誰が直すか	費用
ベンダー純正	相手が用意していること	設定するだけ	ベンダーが直す	ベンダー	無料〜定額オプション
CSV（ファイル）	出力と取込ができること	人かバッチ	列がずれる／文字が化ける	自分（Excelで直せる）	ほぼ無料
API	双方にAPIがあり、契約条件を満たすこと	完全自動	相手の仕様が変わる	作った人	開発費（個別見積もり）
iPaaS	双方に対応コネクタがあること	完全自動	コネクタが追随しない	提供元＋自分	月額（公開価格あり）
RPA（画面操作）	画面を操作できること	画面が開いていれば自動	画面が変わると止まる	自分	ツール料＋シナリオ作成

この表は記事の入口です。ここから、一マスずつ中身を見ます。

用語を開いておきます。

API：外部のシステムから、決められた手順でデータや機能を使うための受付窓口（総論の記事の言い方。以降は「窓口」）。
iPaaS（アイパース）：クラウド上に置く、システム同士のつなぎ役。ブラウザで設定します。
EAI：iPaaSの前からある同種の仕組みで、自社の中に置くタイプ。
RPA：人がパソコンを操作する手順を、そのまま自動で再生する仕組み。
バッチ処理：決まった時刻にまとめて処理すること。
純正連携：ベンダー自身が用意している、特定の相手先とつなぐ機能。

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

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

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

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

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

内訳はこうです。

種類	件数	項目数
CSV の取込・出力	17	669
申請様式・API の構造定義（XML・PDF・xlsx など）	170	11,873

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

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

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

3-2. RPAは「画面が変わる」と止まる

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

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

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

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

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

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

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

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

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

3-4. 純正連携は「ベンダーが直す」

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

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

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

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

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

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

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

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

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

誰に開かれているか	件数
第三者に公開されている	27
申込・審査・NDA が必要	12
シリーズ内・パートナー等に限定	7
明示的に不可	1
公開情報の範囲で確認できない	8
その他の理由で確認できず	1

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

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

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

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

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

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

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

4-3. CSVの前提：出力と取込ができること

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

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

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

5. 一マスずつ見る：費用

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

層	何に対する費用か	公開価格
① API そのもの	APIを使う権利	追加料金なしのことが多い（上位プランへの変更が要る場合あり）
② つなぎ役	iPaaS・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台要ります。夜間に動かすなら電源は切れません。「ツールの利用料は月○円」という見積もりに、そのパソコンの費用が入っているとは限りません。

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

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

手段	直す人	直るまでの間
ベンダー純正	ベンダー	自分の手は要らない。ただし直る時期も相手次第
CSV	自分（Excelで開いて直せる）	その場で直せることが多い
API	作った人（開発会社）	保守契約の範囲内かどうかで変わる
iPaaS	提供元＋自分	コネクタの追随は提供元待ち。設定の直しは自分
RPA	自分	画面を見ながら手順を録り直す

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

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

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

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

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

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

手段	できる範囲
ベンダー純正	ベンダーが決めた項目・決めた相手だけ。条件分岐や加工は基本できない
CSV	様式に定義された列だけ
API	仕様書に載っている対象だけ。読み取り専用のことがある
iPaaS	コネクタが対応している操作だけ
RPA	画面でできることは、原則すべて

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

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

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

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

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

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

8. どこで動くのか

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

手段	処理が動く場所	手元に要るもの
純正連携	相手のサーバー	ブラウザだけ
API連携	相手のサーバーと、呼び出す側のどこか	呼び出す仕組みを置く場所
iPaaS	提供元のクラウド	ブラウザだけ
RPA	自分のパソコン、または仮想パソコン	パソコン1台
CSV	人のパソコン	表計算ソフト

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

9. 調べる順番

以上を踏まえると、調べる順番は決まります。費用が安く、壊れにくく、自分で直さなくていいものから見ます。

1. ベンダー純正の連携機能を調べる

公式サイトの「連携できる外部サービス一覧」を開きます。56件中54件に記述がありました。 ここで終われば、費用も保守もほぼゼロです。

2. CSVを調べる

月1回や日1回で足りるなら、CSVで十分なことが多いです。両システムの出力様式と取込様式を並べて、項目が一致するかを見ます。

3. APIを調べる

ここで初めてAPIです。確認するのは、対象データ・読み書きの別・認証方式・回数制限・契約条件・仕様変更の告知の6点です。

4. iPaaSを調べる

APIはあるが自分で作りたくない、という場合の選択肢です。両方のコネクタがあるかを先に確認してください。

5. RPAを検討する

APIも純正連携もCSVもない場合の最後の手段です。壊れやすさと、パソコン1台を占有することを承知のうえで選びます。

9.5 実際に1件やってみる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. 「一番ラク」は無い

この記事では優劣を付けていません。理由は2つあります。

1つ目。要件によって答えが変わるからです。 月1回の連携にiPaaSを入れるのは過剰ですし、1日500件の連携をCSVでやるのは無理があります。

2つ目。壊れやすさの「頻度」を測っていないからです。 編集部が調べたのは壊れ方の種類であって、何ヶ月に一度壊れるかではありません。「RPAは壊れやすい」と書けるだけの実測データは持っていません。

代わりに言えるのはこうです。

要件を満たせる、最もシンプルな手段を選ぶ。
シンプルさの順番は、純正 → CSV → API → iPaaS → RPA。

この記事の調査範囲について

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

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

10-1. あわせて読む

APIとは何か（総論） — 「つながる」の正体を、56 件の実物で確かめた
純正連携と iPaaS — 「両方に API があれば繋がる」は本当か
AI・自動化ツールの全体像（総論） — 66 製品を工場の 6 役に例えた図解

読者アンケート実施中
このテーマをもっと深掘りしてほしい方は、記事に「いいね」をお願いします。「いいね」の多いテーマから順に追加調査し、結果は新着記事でお知らせします（フォローしていただくと通知が届きます）。

【転載OK】本記事の転載について

本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として renkeimap.jp もしくは本記事へのリンクをお願いします。事前の連絡は不要です。

※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。文中の「編集部」は、筆者が所属する IT連携マップ編集部のことです。誤りを見つけられましたら訂正窓口（無料・アカウント不要）へお願いします。訂正履歴も公開しています。