コラム ｜ 物流データ収集技術 #7 ｜ 2026年8月20日

「APIで連携します」と言われたら
──CSVとの違いを現場担当者向けに整理する

システム連携の打ち合わせで、こう言われることがあります。

「そこはAPIで連携しましょう」

この一言に対して、その場では「わかりました」と答えたものの、実際に何が行われるのかがつかめないまま話が進んでいく——という経験をお持ちの方は少なくないと思います。

APIそのものを実装するのは技術者の仕事です。しかし、API連携を選んだ場合に何が変わるのかを理解しておくことは、現場の担当者にとっても意味があります。データの鮮度、運用の手間、確認すべき項目——これらがファイル連携とは変わってくるためです。

1. CSVとAPIは何が違うのか

まず、この2つの違いを一つの比喩で整理します。

CSV連携＝荷物を届ける

送る側がファイルを作り、決められた場所に置きます。受け取る側は、決められた時刻にそれを取りに行って処理します。宅配便のように、まとまった量を、決められたタイミングで受け渡す方式です。

▼ ファイル連携のイメージ

API連携＝窓口に問い合わせる

データを持っている側が「窓口」を用意します。欲しい側は、必要なときにその窓口へ「この条件のデータをください」と問い合わせ、その場で答えを受け取ります。

▼ API連携のイメージ

問い合わせた時点で、APIが参照しているデータの状態が返ってきます。ファイルという「モノ」は介在しません。

比較

2. REST APIの基本——何が行き来しているのか

現在、業務システムやクラウドサービスのAPIでは、REST APIと呼ばれる方式が広く使われています。「レスト」と読みます。

REST APIは、Webサイトを見るときと同じ仕組み（HTTP/HTTPS）を使ってデータをやり取りします。ブラウザでURLを開くと画面が返ってくるのと同じように、URLを指定するとデータが返ってくると考えるとイメージしやすくなります。

リクエストとレスポンス

APIのやり取りは、必ず「問い合わせ（リクエスト）」と「応答（レスポンス）」の対になります。

リクエストの例（在庫情報を問い合わせる）

このURLを分解すると、次のような意味になります。

レスポンスの例

返ってくるデータの形式は、#6で扱ったJSONであることが一般的です。JSONの書式もIETFのRFCで定義されています（RFC 8259）。ファイル連携ではなくAPI連携を選んでも、データの中身の話——日時の書式、値なしの表現、コードの桁——は同じように確認が必要になります。

主なHTTPメソッド

「何をしたいか」によって、使うメソッドが変わります。

データ収集の用途では、多くの場合GETを使います。一方、分析結果を相手システムに書き戻すような場合はPOSTやPUTが登場します。

ステータスコード——結果を表す3桁の数字

レスポンスには、処理の結果を示す3桁の「ステータスコード」が含まれます。エラーが起きたときの切り分けで登場するため、代表的なものを知っておくと会話がスムーズになります。

3. 認証——誰からの問い合わせかを確かめる仕組み

APIは、インターネット越しに接続できる「窓口」です。業務システムのデータを扱うAPIでは、誰でも自由にデータを取り出せないよう、正当な相手からの問い合わせであることを確認する仕組みが用意されるのが一般的です。

APIキー方式

最もシンプルな方式です。API提供側から発行された文字列（APIキー）を、問い合わせのたびに一緒に送ります。鍵を持っている人だけが窓口を使える、という考え方です。

導入は容易ですが、キーが流出するとそのまま使われてしまうため、キーの保管方法が重要になります。ファイルに直接書き込んで共有フォルダに置く、メールで平文のまま送る、といった運用は避ける必要があります。

トークン方式

より本格的な連携では、トークンと呼ばれる仕組みが使われます。まず認証用の情報でログインに相当する手続きを行い、一時的に有効なトークンを受け取ります。以降の問い合わせでは、そのトークンを提示します。

トークンには有効期限を設定できる方式もあり、期限が切れたら取り直します。適切に有効期限や権限を設定することで、漏洩時のリスクを抑えやすくなります。企業向けのクラウドサービスでは、OAuth 2.0という枠組みに沿った方式が広く使われています。OAuth 2.0もIETFのRFCとして仕様が公開されています（RFC 6749）。

接続元の制限

認証に加えて、特定のIPアドレスからの問い合わせだけを受け付けるという制限をかけることもあります。社内のシステムからのみ接続を許可する、といった使い方です。

この制限がある場合、接続元となるサーバーのIPアドレスを事前に相手側へ伝えて、許可リストに登録してもらう必要があります。手続きに時間がかかる項目なので、早めに確認しておくと安心です。

4. 通信の暗号化——HTTPSとは何をしているのか

APIのURLは、ほぼ例外なくhttps:// で始まります。この「s」が付いているかどうかで、通信の安全性が大きく変わります。

TLSは、以前SSLと呼ばれていた技術の後継です。現在も「SSL証明書」「SSL通信」という呼び方が慣用的に残っていますが、実際に使われているのはTLSです。TLSもIETFのRFCとして仕様が公開されており、最新のバージョンであるTLS 1.3はRFC 8446で定義されています。

HTTPSが果たす役割は、大きく2つあります。

①通信内容の暗号化。 経路の途中でデータを覗き見られても、内容を読み取れないようにします。認証に使うAPIキーやトークンも、この暗号化に守られています。

②接続先の確認。 サーバー証明書によって、接続しようとしている相手が本物かどうかを確認します。偽のサーバーに誘導されてデータを送ってしまう事態を防ぎます。

5. API連携を検討するときに確認すること

#6でファイル連携の取り決め項目を整理したように、API連携にも事前に確認すべき項目があります。

※ 実際に必要な項目は連携する内容や相手システムによって異なります。上表は確認の出発点として参照してください。

レート制限とページネーションは早めに確認する

この2つは、小規模なテストでは問題にならず、本番データの量になって初めて表面化する項目です。

レート制限は「1分間に60回まで」といった形で設定されます。数件のテストでは気づきませんが、数千件のデータを取得しようとすると上限に達します。

ページネーションも同様です。「1回のレスポンスは最大1000件まで」という制限がある場合、それを超えるデータは複数回に分けて取得する必要があります。テストデータが100件だったために、この対応が漏れたまま本番に進む——という失敗はよくあるパターンです。

6. CSVとAPI、どちらを選ぶか

両方の選択肢がある場合、判断の軸は「どの程度の鮮度が必要か」と「相手システムに何が用意されているか」の2つです。

また、両方を併用する構成も一般的です。過去データはCSVで一括投入し、以降の更新分はAPIで取得する、といった使い分けです。

まとめ：仕組みではなく、判断に必要な範囲を押さえる

API連携の実装は技術者の仕事です。しかし、「APIで連携します」と言われたときに、何が起きるのかを想像できる状態になっておくと、検討の質が変わります。

データがいつの時点のものになるのか。認証情報を誰が管理するのか。相手システムが停止したときにどうなるのか。これらは技術的な詳細ではなく、運用として決めるべき事柄です。

そして、CSVでもAPIでも変わらないことがあります。データの中身——日時の書式、コードの体系、値なしの表現——を揃える作業は、どちらの方式でも同じように必要です。連携方式の議論に注目が集まりがちですが、実務の負荷はむしろそちらにあります。