「このシステムとkintoneを連携できませんか？」

そう聞いたところ、

「API連携が必要になりますので、○百万円ぐらいです」

と言われたことを、今でも覚えています。

「APIって、そんなに高いものなの？」

これが、私が改めて 「システム連携」 について調べ始めたきっかけでした。

この記事では、技術者向けにAPIのプログラムを書く話ではなく、

「そもそも、なぜシステムをつなぐのか？」
「APIは本当に必要なのか？」

という実務者の視点から、システム連携の構造を解き明かしていきます。

まず結論

APIについて調べる前に、私は次の4つを書き出すことをおすすめします。

確認すること	例
何のデータを	得意先情報、商品、請求書、勤怠など
どちら向きに	販売システム → 会計システム
連携頻度とデータ量	1日1回かリアルタイム、大量か少量
データ編集と確認方法	データ編集不要、後で人が確認できる

これら4点が分からないまま「APIを利用したい」と相談すると、不必要に大規模なシステム構築を提案される可能性が高いです。逆に言えば、

毎日1回の処理で足りる
データ量が少ない
CSVで入出力が可能である
途中で人が編集・確認する余地があってよい

という条件であれば、APIではなくCSVで十分かもしれません。
一方で、人が触らずに一日に何度も流したいのであれば、そこで初めてAPIが必要になります。
APIは「高度な技術だから使う」のではなく、業務上の必要条件を満たす最適な手段として選ぶべきものです。

1. なぜ「システム連携」が必要になるのか

近年の業務環境では、一つのシステムですべての業務を処理することは少なくなりました。
見積・受注は販売管理、請求は請求書システム、会計は会計ソフト、勤怠は勤怠管理など、特化型のシステムを利用します。

システムが独立して動いていると、次のような問題が生じます。

販売管理「顧客A・売上100万円」
       ↓ 手入力による転記
会計ソフト「顧客A・売上100万円」

このように、人間がデータを運ばなければならない状態となります。これが「システム連携」が求められる背景です。

総務省の「令和7年版情報通信白書」によれば、2024年のクラウド利用率は80.6%に達しています。しかし、東京商工会議所の2025年の調査によると、ITを「導入した」とする企業は約8割に達する一方で、「活用している」企業は約5割にとどまります。さらに、DXに向けた課題として最も多く挙げられたのが**「コスト負担」（31.9%）**です。
つまり、「システムは導入したが、システム同士が円滑に連携できない、しかしお金がかかる」という問題は、多くの企業が直面している現実的な課題です。

2. 「連携していない」状態

「システム連携していない」状態とは、データのやり取りが一切行われていないのではなく、人手でデータを運んでいる状態です。

AシステムからCSVを出力する
Excelで開き、必要な列を編集し確認する
Bシステムに取り込む、あるいは手入力する
転記ミスがないか確認する

これは立派な「データ連携」であり、連携処理を人間が担当している状態と言えます。

システム間で受け渡すことを想定して設計されたデータ項目は、皆さんが思っている以上に多く存在します。筆者が主要なシステムの「受け渡しの様式」を公式資料から調査したところ、以下の12システムだけでも187件の様式があり、そこで定義されている項目は合計12,542項目に上りました。

ここでいう「様式」とは、1種類ぶんの項目の並び順の定義です。画面の数でも、ファイルの実物の数でもありません。

なお、この187件のうちCSVの取込・出力は17件・669項目で、残りはe-Govの申請書XML構造定義やjGrantsの様式集（PDF）から抜き出した項目定義です。CSVであれXMLであれ申請様式であれ、「システム間で受け渡すために、あらかじめ項目の並びが決められている」という点は同じです。

漠然とした「二重入力の苦労」ではなく、これだけ多くの項目がシステム間を行き来する前提で作られているのです。

3. まず確認したい「動作環境」

APIやCSVを検討する前に、システムが動いている「動作環境」を確認することが大切です。動作環境は、大きく次の3通りに分かれます。

動作環境	サーバーの置き場所	手元に必要なもの
クラウド	相手（提供元）の建物	ブラウザ、またはスマートフォン
オンプレミス	自社の建物	社内のパソコン（社外から使えるかは別途確認）
手元のパソコン	そのパソコンの中（データも一緒）	そのパソコンにソフトを入れる

ただし、「クラウド」が決めているのは置き場所だけです。
「クラウド」と名乗っていても、ブラウザやスマートフォンからアクセスできるシステムもあれば、KING OF TIMEのようにクラウドサービスでありながら打刻用の専用アプリ・専用端末が必要なもの、e-Gov電子申請のように専用アプリの導入が必要なもの、弥生のようにWindowsのデスクトップアプリとして動くものなど様々です。

手元に何が要るかは、製品ごとの「動作環境」ページで確認するしかありません。
ここが分かれると、後段の選択肢（API・CSV・画面操作など）が丸ごと変わってきます。

この章をもっと詳しく: 56 件の動作環境を 1 件ずつ数え、「ブラウザだけでは完結しない」のが何件かまで出しました → うちは何を買うのか — 動作環境の 5 つの問い

4. システム連携には、API以外にも方法がある

「システムをつなぐ」手段はAPIだけではありません。主に以下の5つの方法があります。

方法	自動化	安定性	初期費用	保守	向いているケース
ベンダー純正	スイッチ一つで自動	ベンダーが保守するため安定	無料〜定額オプション	構築・保守はベンダー任せ	ベンダーが用意している場合
CSV(ファイル)	人の手やバッチ処理が必要	列がずれるとエラーになる	ほぼ無料（標準機能・構築なし）	都度の手間はあるが、人がExcelで柔軟に対応できる	定期的なデータ交換
API連携	完全自動化が可能	仕様変更がない限り安定	開発が必要で、構築が重い	仕様変更のたびに再開発が必要	高頻度・リアルタイム連携
iPaaS	完全自動化が可能	コネクタが対応していれば安定	月額利用料（公開価格あり）・開発は不要	コネクタの更新は提供元、設定は自分	APIはあるが、自分で作りたくない
RPA画面操作	画面が開いていれば自動	画面のUIが変わると止まる	ツール利用料＋シナリオ作成	画面が変わるたびにシナリオの修正が必要	APIがない画面操作

ここで一つ、混同しやすい点を先に整理しておきます。iPaaSはAPIの代わりではなく、「APIを呼ぶ人」の代わりです。
iPaaS（Integration Platform as a Service）はクラウド上のつなぎ役で、相手のAPIをブラウザの設定画面から呼び出します。つまりiPaaSを使う場合も相手側にAPIは必要で、違いは「そのAPIを呼ぶプログラムを、自分で書くかどうか」だけです。この「誰が作るか」という論点は、第8章（費用）と第11章（手順）で改めて扱います。

これらは優劣をつけるためのランキングではありません。要件を満たせる最もシンプルな手段を選択するという原則が何より重要です。表の並び順（ベンダー純正 → CSV → API → iPaaS → RPA）は、費用が安く、壊れにくく、自分で直さなくてよいものから確かめるという順番になっています。

この章をもっと詳しく: 5 つの手段を 6 つの物差し（自動化・安定性・初期費用・保守ほか）で並べ、月 80 件の請求データという具体例で選び方をたどりました → 連携の手段の選び方 — 純正・CSV・API・iPaaS・RPA を 6 つの物差しで比べる

5. APIとは「住所と方法」の決まりごと

API（Application Programming Interface）を簡潔に定義するならば、**外部システムから、規定された手順でデータや機能を利用するための「窓口」**です。

Web APIの多くはHTTPという通信規格で動作します。IETFのRFC 9110では、HTTPにおいてリクエストの対象を resource と定義し、やり取りするための interface を定めています。
実務の言葉に置き換えると、どこに要求するか（住所）と、どのように要求するか（方法）が規定されているということになります。

たとえば、https://example.com/customers/123 という場所に対して GET メソッドで「顧客123の情報を取得せよ」と要求すると、規定された形式（JSONなど）で応答が返ってきます。

この規定が存在するからこそ、人間が画面を操作しなくともシステム間で自動的にデータの受け渡しが可能となります。

この章をもっと詳しく: REST・SOAP・JSON・XML・CRUD といった用語を業務の言葉に置き換え、56 件で実際にどの形式が使われているかを数えました → APIとは何か調べてみた

6. 「APIはありますか？」だけでは質問として足りない

実際のSaaSのAPI公開状況は、サービスごとに大きく異なります。
主要な業務システム56件を調査した結果、外部向けに公開されているAPIだけでなく、次のような条件付きのものが多数存在しました。

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

合計56システムのうち、誰でも仕様を見て自由に使えるものは半分以下です。
さらに、「公開APIあり」の27件のうち、5件は特定の契約プランでなければ使えません（例として、Salesforce Sales Cloud のように上位プラン限定など）。

また、記事執筆にあたり公式資料を調査した結果、28件は契約条件が公式資料から読めない状態でした。これは我々の調査不足ではなく公開情報の側の状態であり、「APIがある」ことと「あなたが今すぐ使える」ことは全く別なのです。

したがって、ベンダーには「APIはありますか？」ではなく、次の表のような観点で確認しなければ実態を把握できません。

確認項目	確認すること
対象データ	顧客・商品・注文など、必要なオブジェクトがあるか
取得	データを読めるか
登録	データを新しく追加できるか
更新	データを変更できるか
削除	データを削除できるか
項目	必要なカラムが網羅されているか
認証	APIキー、OAuthなど、認証方式は何か
利用制限	1分・1日あたりの回数制限などがあるか
契約	無料／有料／上位プラン限定など
仕様変更	バージョン変更・廃止予定などはどう告知されるか

この章をもっと詳しく（2 本あります）

上の「27件」の内訳です。公開されていても、5件は契約プランの壁つきでした。「API連携できます」が実際には8通りに分かれることを、56件を1件ずつ当たって分類しました → 「APIあります」の実態 — 公開度と契約条件の 2 軸で読む

この表を埋めるには仕様書が要ります。機械が読める設計図（OpenAPI）を配っているのが 56 件中何件かを数えました → 設計図（OpenAPI）は配られているか — 3 つ見るだけ

7. 純正連携とデータ変換

API開発を検討する際に見落とされがちなのが「純正連携機能」です。
会計ソフトが銀行とつながるように、公式サイトの「連携可能な外部サービス一覧」を見るだけで課題が解決するケースは少なくありません。

もう一つ、意外と大事なのがデータの違いです。

販売管理システム	会計システム	何が起きるか
得意先名	取引先名称	名前が違う
顧客ID = `A001`	取引先コード = `000123`	採番ルールが違う
売上日	計上日	名前が違う
商品コード	品目コード	名前が違う
請求金額（税込）	金額（税抜）	形の変換が要る
担当者	（項目が無い）	受け側に無いので渡せない

こうした食い違いを吸収する作業をデータ変換と呼びます。そのうち「どの項目をどの項目に結ぶか」を決める部分が項目の対応（マッピング）です。
人間が見れば「同義だ」と直感的に分かっても、システム同士では項目名が一致しなければマッピングできません。採番ルールの違いもあり、A001 と 000123 を対応づける表は自動では作れません。誰かが決める必要があります。
さらに厄介なのが下の2行です。税込と税抜のように形そのものを変換しなければならない項目があり、受け側にそもそも存在しない項目は渡すことができません（捨てるのか、別の欄に入れるのかを決めることになります）。
こうした差異を吸収するための「つなぎ役」として、iPaaS、EAI、RPA等が機能します。システムAとシステムBの双方にAPIが備わっていれば、魔法のようにつながるわけではないのです。

この章をもっと詳しく: 純正連携の一覧が実際にどれだけ整備されているかを数え（kintone 422件、KING OF TIME 61件など）、「相手ごとにAPIかCSVかが違う」ところまで公式ページで確認しました。iPaaS を検討する前に数えることと、純正連携の弱点も書いています → 純正連携か iPaaS か — 「両方に API があれば繋がる」を確かめてから選ぶ

8. 「APIっていくらかかるの？」を分解して考える

ここで冒頭の「○百万円の見積もり」の謎を解き明かします。
API連携に要する費用は、単一のパッケージではなく、3つの層に分解して捉えるべきです。

層	何に対する費用か	公開価格の有無
① APIそのもの	APIを利用する権利	追加料金なし（上位プランへのアップグレードが必要な場合はある）
② つなぎ役	iPaaS・RPA等の利用料	公開価格が存在する（タスク処理回数等で変動）
③ 作る人	開発・テスト・保守を行う人的コスト	★公開価格が存在しない（個別見積もり）★

②については、公式サイトで公開価格を確認できます。たとえばYoom、ASTERIA Warp、Power Automateなどは価格表が存在します。

問題は③です。API仕様の調査、認証方式の実装、データマッピングの実装、エラーハンドリング、運用監視の設計、将来の仕様変更対応など、これらの作業を人件費として積算した結果が「○百万円」となります。
APIを利用する権利そのもの（①）の料金と、システム間をつなぐ個別開発費（③）は全くの別物です。
国もこの負担を認識しており、「デジタル化・AI導入補助金2026」（旧：IT導入補助金）等の支援枠を用意しています。

9. データは安全か？

外部システムとAPIで通信する際、「重要なデータを外部に渡して安全なのか」という懸念が生じるのは当然です。

現代のWeb APIで広く採用されているOAuth 2.0（RFC 6749）という標準規格では、保護されたリソースへのアクセスを許可する主体を resource owner（人間の場合は end-user）と定義しています。

つまり、「データは利用者のもの」というのは単なる理念ではなく、標準規格の用語定義なのです。
なお、resource owner はOAuthにおけるアクセス許可主体を表す規格上の用語であり、法律上の「データ所有権」を一律に定める言葉ではありません。

アクセストークン（許可証）には以下の概念が含まれます。

scope：何を許可するか（アクセス範囲）
duration：いつまで許可するか（有効期間）

そして、鍵の渡し方には大きく2通りあります。

方式	たとえると	渡した後にできること
OAuth	入館証（受付が発行する）	入れる範囲と期限が決まっている。受付で即失効できる。相手にパスワードは渡らない
APIキー	合鍵（扉の鍵の複製）	範囲も期限も基本的にない。無効にするには錠を替える＝その鍵を使っている連携が全部止まる

どちらも「鍵を渡す」ことに変わりはありませんが、渡した後に絞れるか・取り消せるかが違います。 OAuthが使えるシステムではOAuthを選んでおくと、「それだけを取り消せる」ことの価値が、運用に入ってから効いてきます。APIキーしか無い場合は、その文字列の置き場所と持ち主を管理する必要があります。

規格に書いてある当然の質問として、ベンダーや連携ツールの提供者に対して次のように聞くことができます。

「その連携ツールは、何を読めるのですか？」
「何を書き換えられるのですか？」
「そのアクセス権はいつまで有効ですか？」
「利用を停止したい場合、どこから取り消せますか？」

これらの確認は、安全なシステム運用において不可欠です。

10. APIを使えばずっと安定して動くのか？

「一度構築すれば永遠に安定して稼働する」というのも誤解です。連携を作った後に起きることは、大きく3つあります。

1つ目は「回数の壁」です。 APIには利用回数の上限があり、データが増えるとそこに当たります。Google WorkspaceのDirectory APIのようにユーザーあたり毎分2,400クエリと決まっているものや、マネーフォワードクラウド経費のようにプランごとに300回/時間・3,600回/時間と公開されているものがあります。

2つ目は「仕様が変わる」ことです。 「予告なく変更する場合がある」と書いている系統もあれば、HubSpotのようにAPIのバージョンを日付で管理し、旧バージョンの提供終了日を明確に定めている系統や、Salesforce Sales Cloudのように「最低サポート期間」を約束している系統もあります。告知の仕方そのものがベンダーによって違うため、変更を追う手段があるかどうかで手間が変わります。

3つ目は「止まる」ことです。 相手側の障害は必ず起こります。ここで分かれ目になるのは気づけるかどうかで、画面は普通に動いていてもAPIだけが止まっていることもあります。障害情報を知らせるページ（ステータスページ）が公開されているか、通知を受け取れるかを、連携を作る前に確認しておきます。

つまり、連携システムは作って終わりではなく、この3つに気づいて直し続ける必要があるということです。これこそが、前章の③（作る人）にあたる保守費用の正体です。

11. APIを検討するとき、私ならこの順番で調べる

以上の調査を踏まえ、システム連携を検討する際の実践的な手順を8つのステップとしてまとめました。

1. 業務を決める

何を自動化したいのかを具体化します。

2. データを決める

対象となるデータ項目を具体化します。

3. 方向と頻度を決める

AからB、あるいは双方向か。そして、月1回、1日1回、リアルタイムなど必要な頻度を定義します。

4. 純正連携を調べる

標準の連携機能が存在しないか調査します。これが一番簡単な場合があります。（→ 手段の比較）

5. CSVを調べる

バッチ処理で十分な場合、CSV機能のデータ項目を確認します。

6. APIを調べる

ここで初めて、APIの仕様（対象データ、認証、レート制限、プラン等）を調査します。（→ APIの用語／設計図の有無）

7. データマッピングと動作環境を調べる

データ構造の違いを吸収する変換ルールを整理し、その連携処理をどこで動かすかを確認します。（→ 動作環境）

8. 最後に「誰が作るか」を決める

自社開発か、連携ツール（iPaaS）利用か、外部委託かを判断します。ここまでの1〜7で純正連携もCSVもAPIも使えないと分かった場合に、最後の手段としてRPA（画面操作）を検討します。

12. ベンダーとの交渉：「APIはありません」と言われたら

ベンダーに「APIはありません」と回答されても、すぐに諦める必要はありません。「APIがない」にも、いろいろな意味があります。

ベンダーの回答	実際には
APIはありません	本当にない？
公開していません	申請・NDAで使える？（12件）
そのプランでは使えません	上位プランなら使える？（5件）
個別対応です	見積もりで可能？
APIはありません	CSVなら可能？
APIはありません	純正連携なら可能？

聞き方そのものも、返ってくる答えを変えます。

	聞き方	どうなるか
✕	「APIはありますか」	質問がAPIに限定されるので、API以外の道が答えに出てこない
✕	「APIを作ってもらえますか」	開発計画の話になり、時間がかかる
○	「この2つの間でデータを渡す方法は何がありますか」	純正連携やCSVを含めた答えが返ってくる
○	「○○（相手の製品名）との連携実績はありますか」	すでに事例があれば、それが一番早い
○	「エクスポート／インポートはできますか」	CSVで解決できるかどうかが分かる
○	「仕様書の開示に申請は要りますか。何日かかりますか」	使えるようになるまでの期間が読める

相手は嘘をついているわけではありません。こちらの質問が狭いだけです。 目的（何と何を、どのくらいの頻度でつなぎたいのか）を先に伝えると、話が噛み合います。

ベンダーに聞くなら、私はこう聞きます。

「販売管理システムの顧客情報を、会計システムへ1日1回連携したいと考えています。対象は顧客コード、会社名、住所、電話番号です。API、CSV、標準連携など、利用可能な方法はありますか？」

ここまで伝えると、単に「APIありますか？」と聞くより、かなり話が具体的になります。さらにAPIが必要なら、「顧客情報の取得だけでなく、登録・更新も可能ですか？」と確認します。

ベンダーにとってAPIの追加は、恒久的な保守責任を負う重い作業です。「我々のデータなのだから無償で提供して当然だ」という一方的な要求は推奨しません。
また、「取引先に手順を変えてもらう（先方に直接入力してもらう）」といった相手を動かす案は、業務改善ではなく取引リスクになりうるため、最後の手段とすべきです。

13. APIを「使わない」という判断も立派なDX

最後に、最初の「○百万円」の見積もりの話に戻ります。

見積もりを契機として業務フローを整理し直した結果、「販売管理から会計システムへ、月末に1回のみ、人間の確認を経て顧客情報を連携する」という要件であることが判明しました。

その結果、**「月に1回、CSVを出力して取り込む運用で十分である」**という合理的な結論に至りました。

「毎月1回の頻度でCSVを出力し、人間が確認して取り込む」運用で業務が回る要件に対して、連携ミドルウェアを導入し、エラー監視を構築するような重厚な仕組みは全く必要ありません。将来的に業務量が拡大し、リアルタイム連携が不可避になれば、その時点で改めてAPI導入を検討すればよいのです。

「APIを使わない」という判断を下すことで、最初の○百万円という無用な投資を回避することができた。
これこそが、システム連携を正しく理解することで得られた最大の成果です。

関連記事 — もっと詳しく調べたもの

各章で足りないと感じたところは、同じ調査から書いた記事があります。

動作環境（第3章） — パソコン・スマホ・専用端末のどれが要るのかを 56 件で数えた
つなぐ手段の比較（第4章） — 純正・CSV・API・iPaaS・RPA を 6 つの物差しで並べた
API の用語（第5章） — REST・SOAP・JSON・XML・CRUD を業務の言葉に置き換えた
第6章 を掘ったものが 2 本あります
- 設計図の有無 — 機械が読める仕様書を配っているのは 56 件中何件か
- 「APIあります」の実態 — 公開度 × 契約条件の 2 軸で 56 件を分類した
純正連携と iPaaS（第7章） — 「両方に API があれば繋がる」は本当かを確かめた

※ この一覧は公開ずみのものだけです（6 本）。残りは公開のたびに足していきます。

おわりに

本稿はAPIという技術に対する疑問から調査を開始しましたが、課題の核心は「APIの知識」そのものではなく、

「自社の業務を、どのシステムと、どのように連動させるべきか」

という業務設計のレイヤーにあるという事実でした。
最初から「APIを使いたい」と考えるのではなく、「何を、どちら向きに、どのくらいの頻度で、どの精度でつなぎたいのか」から始める。
その結果、「純正連携で十分」「CSVで十分」「APIが必要」という答えが出てきます。

筆者は日立系ITベンダー、介護ソフトベンダー、大学病院IT部門など、中堅・中小企業、ベンダー・ユーザーの両方を経験してから独立しました。現在は、API・RPA・AIなど、業務システム間の「つながり」を調べながら、中小企業へのIT・DX支援をしています。今後も実際の業務システムを対象として、公開されている一次資料に基づく検証を継続していきたいと考えています。

「APIが存在するか」ではなく、「どのデータを、どの手段を用いれば、無理なく連携できるか」。

システム連携を設計する際は、常にこの問いから出発すべきであると考えます。

参考にした資料について

本稿の執筆にあたり、以下の公的資料および各サービスの公式APIドキュメント・価格表・連携機能一覧等を参照しました。
また、公開中の56システムについて、APIの開かれ方、契約条件、認証方式、レート制限、CSV仕様などを横断的に調査しています。これらの調査結果はすべて公開情報を基準としており、「公開情報で確認できない」状態と「機能が実際に存在しない」状態は明確に区別して扱っています。

総務省令和7年版情報通信白書
東京商工会議所中小企業のデジタルシフト・DX実態調査
RFC 9110: HTTP Semantics
RFC 6749: The OAuth 2.0 Authorization Framework
デジタル化・AI導入補助金2026（中小機構）
各システムの仕様や価格は、e-Gov電子申請、jGrants、e-Tax、freee会計、ジョブカン勤怠管理、弥生、マネーフォワードクラウド請求書、マネーフォワードクラウド会計、楽楽精算、board、マネーフォワードクラウド経費、kintone、Salesforce Sales Cloud、HubSpot、Google Workspace、KING OF TIME、Yoom、ASTERIA Warp、Power Automate の公開情報に基づきます。

調査対象の56システム（全件・公式ページ）

※ 一次調査を終えて公開している 56 件です。判断の元にした記述・出典URL・調査日は RenkeiMap に1件ずつ載せています。

編集履歴

2026-08-22：手段の比較図を差し替え（◎○△の一覧）。iPaaS を手段の一つとして明記。認証方式（OAuth／APIキー）、連携を作った後に起きること、ベンダーへの聞き方を加筆。

あわせて読む

AI・自動化ツールの全体像（総論） — 66 製品を工場の 6 役に例えた図解

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

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

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

※ 文中の「編集部」は、筆者が所属する IT連携マップ編集部のことです。誤りを見つけられましたら訂正窓口（無料・アカウント不要）へお願いします。訂正履歴も公開しています。