APIとは何か調べてみた｜REST・SOAP・JSON・XML・CRUD…用語を業務の言葉に置き換える

Last updated at 2026-08-22Posted at 2026-08-22

API連携の説明を読むと、10行目くらいで用語に当たります。REST、SOAP、JSON、XML、CRUD、エンドポイント、Webhook。

「REST とか JSON とか、業務の判断に関係あるのか」

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

このうち業務の判断に関係するのは、実は4つだけです。残りは知らなくても困りません。

この記事では、①4つの質問に落とし、②日本の業務システム56件で実際にどの形式が使われているかを数えます。

先に数字を出します。

形式まで公開資料で確かめられたのは28件（56件中）。 REST/JSON が26件、ファイル受け渡しが2件。
11件は「APIはあるが、形式の明記が読めない」、16件は公開APIの案内自体が見つかりません。
SOAPは3件、GraphQLは1件でした。

つまり日本の業務システムでは、REST/JSON がほぼ唯一の選択肢です。用語をいくつも覚える必要はありません。

総論の記事では、APIを「決められた受付窓口」と説明するところまで書きました。この記事は、その窓口をどう見分けるかまで降ります。

1. APIを4つの質問に落とす

APIを一言でいうと、外部のシステムから、決められた手順でデータや機能を使うための窓口です。

窓口である以上、決まっているのは4つだけです。

質問	業務の言葉で	技術の言葉で
どこに頼むのか	住所	エンドポイント（URL）
何をするのか	取る・入れる・直す・消す	CRUD（GET/POST/PUT/DELETE）
どんな形で返るのか	書式	JSON／XML
いつ動くのか	こちらから聞くか、向こうから来るか	ポーリング／Webhook

この4つに落とすと、ベンダーの資料が読めるようになります。逆に言うと、この4つ以外は読み飛ばして構いません。

1-1. 実際の形

たとえば https://example.com/customers/123 という住所に対して「取る」と頼むと、決められた形式（多くはJSON）で顧客123の情報が返ってきます。

これだけです。人が画面を開いて検索する代わりに、システムが直接聞きに行っている、というだけの話です。

この「住所と頼み方」の決まりは、IETF の RFC 9110という標準文書で定められています。HTTPにおいて、要求の対象を resource、やり取りの取り決めを interface と呼んでいます。

2. 「取る・入れる・直す・消す」— CRUD

APIでできる操作は、突き詰めると4つです。

操作	業務の言葉	例
取得	取る	顧客一覧を読む
登録	入れる	新しい取引先を追加する
更新	直す	住所を書き換える
削除	消す	誤登録を削除する

この4つの頭文字が CRUD（クラッド）です。用語自体はどうでもいいのですが、この4つを分けて聞くことが重要です。

2-1. 「読み取りだけ」のAPIがあります

これが実務で効きます。APIがあっても、書き込みができないことがあります。

編集部が調べた範囲では、次のような例がありました。

ジョブカン会計：ログイン不要で公開されているOpenAPI仕様書のエンドポイントは8本で、いずれもGET（取得）のみ。会計データ・年度一覧の取得と、仕訳日記帳・試算表のCSVダウンロード用で、書き込み系の操作はありません
jGrants：補助金情報の読み取りが中心

一方、どっと原価は対象ごとに読み書きの別が公開されています。業者・発注者・社員・機械のマスターや工事の基本情報は書き込みまでできる一方、費目・工種・種別といった区分は取得だけ、という具合です。

「APIはありますか」ではなく「登録・更新もできますか」と聞く必要があるのは、このためです。

3. REST と SOAP — 新旧ではなく「相手が決めた形」

ここが一番、誤解されている箇所だと思います。

	REST	SOAP
何をやり取りするか	多くは JSON	XML
呼び方	URLに対して取る・入れる・直す・消す	決められた封筒に包んで送る
いま新しく作るなら	こちら	まず選ばれない

「RESTが新しくてSOAPが古い」という説明をよく見ますが、実務ではそう単純ではありません。 SOAPが残っているのは、相手がそう決めているからです。

編集部が56件の仕様記述を読んだ範囲では、SOAPに言及があったのは3件でした。

いずれもRESTと併存しています。Salesforceの場合、REST APIを中心に、SOAP・Bulk 2.0・Metadata・Connect REST など用途別のAPI群を公開しています。古いものを消していないのです。長く使われている製品ほど、こうなります。

判断としては、こうなります。

新しくつなぐなら REST を選ぶ。SOAPしかない相手なら、扱える人を確保する必要がある。

SOAPは書き方が固いので、対応できる開発者が限られます。これは費用の話です。

4. JSON と XML — 見た目が違うだけ

やり取りする中身の書き方です。同じ「顧客1件」を、こう書きます。

JSON

{ "id": 123, "name": "山田商事", "tel": "022-000-0000" }

XML

<customer><id>123</id><name>山田商事</name><tel>022-000-0000</tel></customer>

業務の判断は、どちらでも変わりません。 同じ情報が入っています。

変わるのは扱える人です。いまの開発者はJSONに慣れています。XMLは書式が厳密なぶん、行政の様式のように構造をきっちり決めたい場面で使われ続けています。

4-1. 行政系はXMLが残っています

e-Gov電子申請：REST/JSONのAPIですが、様式の構造仕様はXMLで定義されています
eLTAX / PCdesk：開発者向けのXML構造仕様が地方税共同機構への申込制で開示されます。一方、給与支払報告書等のCSVレイアウト仕様書は一般公開されています

外側の通信はREST/JSONでも、中身の様式はXML、という組み合わせがあることは知っておくと混乱しません。

5. いつ動くのか — Webhook

4つ目の質問です。「リアルタイム連携」という言葉の正体は、たいていこれです。

方式	動き	例え
こちらから聞く（ポーリング）	5分ごとに「新しいデータある？」と聞きに行く	郵便受けを定期的に見に行く
向こうから来る（Webhook）	相手側で何か起きたら、こちらに通知が飛ぶ	届いたら電話がかかってくる

Webhookがあると、聞きに行く仕組みを作らなくて済みます。 そして無駄な呼び出しが減るので、回数制限にも当たりにくくなります。

編集部が調べた範囲では、56件中7件でWebhookに言及がありました（boardは仕様書上には存在しないと確認、SlackはEvents APIで購読、SmartHR、Jotform、Zoho CRM、formrun、ANDPAD など）。

「リアルタイムで連携したい」という要望が出たときは、まずWebhookがあるかを確認してください。無ければポーリングになり、回数制限との相談になります。

6. GraphQL は1件

新しい方式として名前を聞くことがあります。ほしい項目をこちらから指定する書き方です。

編集部が調べた56件のうち、GraphQLに言及があったのは1件だけでした。Shopifyです。Admin APIはRESTとGraphQLの2系統で、REST Admin APIは2024年以降 legacy 扱い、2025年4月以降の新規公開アプリはGraphQL Admin APIのみで構築する決まりになっています。

1件では傾向は語れません。ただし「新しい方式に切り替える製品がある」という事実は、バージョン管理の話として知っておく価値があります（後述）。

7. 実態：56件を数えるとこうなった

用語の説明はここまでです。実際にどれだけ使われているのかを見ます。

編集部が56件の「API仕様」欄の記述を読み、通信の作法で分類しました。

分類	件数
REST / JSON	26
ファイル受け渡し（API ではなくCSV・テキスト）	2
「APIはあるが、形式の明記が読めない」	11
公開APIの案内自体が見つからない	16
その他の理由で確認できず	1

さらに、但し書きも数えました。

但し書き	件数
機械可読な仕様ファイル（OpenAPI等）の配布が無い（人が読むHTML／PDFのみ）	8
Webhook がある	7
SOAP を併用	3
中身が XML	2
公式の MCP サーバーがある	2
読み取り専用	2
GraphQL	1

7-1. 読み方

26件がREST/JSON。ここは素直です。用語を1つ覚えるなら REST/JSON でいい、ということになります。

問題は11件の「形式が読めない」です。 APIがあると書いてあるのに、REST なのか SOAP なのか、公開資料からは分かりません。理由はさまざまで、仕様書が申込制だったり（GビズID、ジョブカン勤怠管理）、規約同意後にしか読めなかったり（formrun）、仕様書がWord・Excelで配られていたり（e-Tax）します。

この11件は、見積もりを取る前に「形式は何ですか」と聞く必要があります。

ファイル受け渡しの2件も重要です。弥生は公開API仕様書がなく、代替として帳簿・伝票のテキスト出力とインポートの記述形式が公式サポートページで公開されています。楽楽精算は、公開ページから読み取れる仕様の輪郭が「仕訳データの自動出力」と「CSV自動取込」の2機能です。

つまりこの2件では、CSVが公式の連携手段です。 APIを探しても見つかりません。

8. バージョンという概念

最後にもう1つだけ。APIには版があります。これが保守費の話に直結します。

告知の仕方は3通りありました。

型	例
日付でバージョンを切り、旧版の提供終了日を明示	HubSpot（2026-03版から `/api-name/2026-03/resource` の形）
年4回など定期的にリリースし、URLにバージョンを指定	Shopify
最低サポート期間を約束	Salesforce Sales Cloud

版が切られるということは、いつか旧版が止まるということです。止まる前に直す必要があります。これが「作って終わりではない」と言われる理由の1つです。

8.5 4つの質問は、仕様書のどこを見れば答えが出るか

最後に、実際の手順に落とします。開発者向けページを開いて、上から順にこの4つを探してください。

質問	仕様書のどこを見るか	見つかる言葉
① 何ができるのか	エンドポイント一覧・リファレンス	`GET` `POST` `PUT` `DELETE`、「取得」「登録」「更新」「削除」
② どんな形か	「はじめに」「概要」「Getting Started」	`REST` `RESTful` `SOAP` `GraphQL`
③ 何で書くか	同上、またはサンプルの中身	`application/json`、`Content-Type`、`<?xml`
④ いつ動くか	「Webhook」「通知」「イベント」の項	`Webhook`、「コールバック」、「通知先URL」

①が一番大事です。 エンドポイント一覧を開いて、POST や PUT が並んでいるかを見てください。GET しか無ければ読み取り専用です。編集部が調べた範囲では、読み取り専用と明記されているものが2件ありました。

そして「一覧が長い＝優秀」ではありません。 見るのは、自分が動かしたい対象がその一覧にあるかの1点です。

④は忘れられがちです。 Webhook が無い場合、こちらから定期的に聞きに行くことになります。すると「どのくらいの間隔で聞くか」が設計事項になり、それが呼び出し回数の上限（別の回で扱います）に効いてきます。「すぐ反映されてほしい」という要望は、ここで費用に変わります。

この4つが埋まらないときは、埋まらないと書いて先へ進んでください。 「調べたが公開資料からは分からなかった」は、聞くべきことのリストになります。問い合わせ窓口は、編集部が調べた56件のうち55件で公開されていました。

9. まとめ

覚える用語は4つで足ります。

エンドポイント＝どこに頼むか（住所）
CRUD＝取る・入れる・直す・消す。「読み取りだけ」があります
JSON / XML＝返ってくる形。業務判断は変わりません
Webhook＝向こうから通知が来る仕組み。「リアルタイム」の正体

そして実態はこうです。

REST/JSON が26件。日本の業務システムでは事実上これ一択
SOAPは3件、いずれもRESTと併存。GraphQLは1件
11件は形式の明記が公開資料から読めない。聞く必要があります
2件はAPIではなくファイル受け渡しが公式の手段

ベンダーに聞くときは、こう聞けます。

「APIの形式は REST でしょうか。返ってくるのは JSON ですか。
顧客情報について、取得だけでなく登録・更新もできますか。
変更があったときに通知を受け取る仕組み（Webhook）はありますか。」

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

対象は、編集部が一次調査を終えて公開している56システムです。日本の業務システム全体ではありません。「56件中26件」を「日本の○%」と読み替えることはできません。
確認時期は2026年7月28日〜8月19日です。仕様は変わります。
分類は編集部が手で割り当てました。 本文検索で語を数えると、「RESTではない」「OpenAPIの配布は確認できていない」といった否定の文でも語が出るため、逆に読んでしまいます。判断の元にした記述と出典URLは全件公開しています。
「公開情報を確認した範囲では見つからなかった」と「機能が無い」は区別しています。

規格そのものの出典は RFC 9110（HTTP Semantics）、RFC 8259（JSON）、OpenAPI Specification です。各システムの「API仕様」欄は RenkeiMap で1件ずつ公開しています。

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

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

※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up