【2026年8月調査】OpenAPIって何ができる？日本の業務システム56件の「設計図」公開率を調べてみた

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

「APIはあります」と言われて安心したあと、開発会社から「仕様書をもらってください」と言われて詰まったことはないでしょうか。

APIがあることと、その設計図が読める形で配られていることは別の話です。そして設計図が無いと、作る前に見積もりが立ちません。

その設計図の書き方の標準が OpenAPI です。日本の業務システム56件について、設計図をどう配っているかを1件ずつ調べました。

結論から書きます。

機械が読める設計図（OpenAPI / Swagger のファイル）を配っているのは、56件中10件。約6分の1です。

この記事では、①OpenAPIとは何かを規格の一文で示し、②56件の内訳を出し、③検討時に何が変わるのかを書きます。

1. OpenAPI とは何か

OpenAPI Specification は、HTTP APIのインターフェースを記述するための標準です。仕様書の冒頭にはこう書かれています。

The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs.

言い換えると、「このAPIには、どんな窓口があって、何を渡すと何が返るのか」を、決められた書式で書いたファイルです。拡張子は .json か .yaml です。

以前は Swagger という名前でした。いまも Swagger 2.0 形式のファイルが現役で使われています。

1-1. 何が「機械可読」なのか

ここが一番大事なところです。人が読むHTMLのドキュメントと、OpenAPIのファイルは、書いてある内容が同じでも扱いが違います。

	人が読むHTML	OpenAPIファイル
人が読む	できる	できる（読みにくいが）
プログラムが読む	できない	できる
一覧を機械的に数える	人が数える	自動で数えられる
クライアントを自動生成する	できない	できる
変更点を差分で見る	目視	ファイル比較で分かる

つまりOpenAPIファイルがあると、「このAPIで何ができるのか」を、人が読む前に把握できます。

実際、この記事の数字も同じ方法で作りました。たとえばkintoneの公式OpenAPIは128パス（Apache-2.0ライセンスでGitHub公開）、freee会計は96パス・151オペレーション（MITライセンス）と、ファイルを機械的に数えた値です。HTMLしか無ければ、この数字は出せません。

2. 56件の内訳

編集部が56件の「API仕様」欄を1件ずつ読み、設計図の出し方を5つに分類しました。

設計図の出し方	件数	割合
OpenAPI / Swagger のファイルを配布（機械可読）	10	17.9%
機械可読だが OpenAPI ではない（JSON Schema 等）	1	1.8%
人が読むドキュメントのみ（HTML・PDF・Word 等）	22	39.3%
申込・NDA・規約同意を経て開示（一般公開ではない）	5	8.9%
仕様書そのものが無い／公開を確認できない	18	32.1%
合計	56	100%

2-1. OpenAPI ファイルを配っている10件

システム	確認できた内容
kintone	OpenAPI 3.1.0・128パス（公式GitHub、Apache-2.0）
freee会計	OpenAPI 3.0.1・96パス / 151オペレーション（公式GitHub、MIT）
freee人事労務	OpenAPI 3.0.1・68パス / 109オペレーション / 177スキーマ
ジンジャー	OpenAPI 3.1.0・177パス / 155タグ
SmartHR	Swagger 2.0・60パス / 120オペレーション（無認証で取得可）
マネーフォワードクラウド経費	Swagger 2.0・88パス / 117オペレーション / 106定義
board	OpenAPI 3.1.0・53パス / 89オペレーション / 139スキーマ
ジョブカン会計	OpenAPI 3.0準拠・8パス、いずれもGETのみ
invox	OpenAPI 仕様がダウンロード可（ドキュメント 1.35.0）
jGrants	OpenAPI 3.1.0（jgrants-api.yaml・39.0KB・2024年10月7日公開）

行政システムである jGrants が入っているのは注目に値します。項目ごとに説明と取りうる値が書かれ、業種・地域・利用目的は選択肢まで明記されています。

もう1件、マネーフォワードクラウド給与は OpenAPI ではありませんが、リソース定義を JSON Schema（JSON Hyper-Schema） で提供しています。機械可読という意味では同じ効果があるため、別分類にしました。

2-2. 「人が読むドキュメントのみ」が22件

一番多い層です。ドキュメントはあります。ただしファイルは配られていません。

マネーフォワードクラウド会計：OpenAPIの配布なし、HTMLドキュメントのみ
Garoon：開発者サイトのHTMLドキュメント（エンドポイントごとのページ）。同じサイボウズでも kintone はGitHubでOpenAPIを公開しているのに、Garoon には見当たりません
KING OF TIME：HTML形式の公開仕様書（API Blueprint系）。メソッド＋パスの組を41件確認
Zoho CRM：HTMLドキュメント（6系統）。英語のみ
Yahoo!ショッピングストアクリエイターPro：11系統のAPIがHTMLとPDFで公開、サンプルコードはPHP
Jotform：ドキュメントはあるがエンドポイントの一覧が無い

**この層は「調べられるが、手間がかかる」**という位置づけです。人がページを開いて数える必要があります。

2-3. 「申込・NDA を経て開示」が5件

eLTAX / PCdesk、ジョブカン勤怠管理、formrun、MOVO Berth、楽楽精算の5件です。

見積もりを取る前に仕様が読めない、という状態です。手戻りのリスクがここにあります。

3. なぜこの分類を手でやったのか

数え方について、正直に書いておきます。

最初、編集部はキーワード照合でこれを数えようとしました。台帳の記述に「OpenAPI」という語が入っていれば配布あり、という判定です。

これは間違いです。 実際に32.1%という値が出て、正しい17.9%のほぼ倍になりました。

原因は単純で、台帳の記述には**「OpenAPIファイルの配布は確認できていない」**という文が入っているからです。語だけを見ると、無いと言っているのに有ると数えてしまいます。

実際に取り違えたのは Garoon、Misoca、マネーフォワードクラウド会計でした。いずれも「OpenAPIの配布は確認できていない」と書かれている系統です。

そこで56件すべてを人が読んで分類し直しました。 判断の元にした記述と出典URLは全件公開しています。読者が検算できる形にしてあります。

4. 設計図があると、検討で何が変わるか

「機械可読だと便利」では業務の判断になりません。検討のどの段階で、何が変わるのかを書きます。

段階	OpenAPIファイルあり	HTMLのみ	申込制
できることの把握	ファイルを開けば一覧できる	ページを人が読む	読めない
見積もり	対象と操作が確定した状態で出せる	概算になる	前提が置けない
開発	クライアントを自動生成できる	手で書く	—
仕様変更の検知	新旧ファイルの差分で分かる	お知らせを読む	—

一番効くのは見積もりの段階です。

「顧客情報を連携したい」という要件に対して、OpenAPIファイルがあれば「顧客オブジェクトはこの項目を持っていて、登録と更新ができる」とその場で確定します。HTMLしかなければ、開発会社が読む工数がかかります。申込制なら、申込が通るまで見積もりが出せません。

4-1. APIが扱う「もの」の件数

設計図があると、APIが扱う対象（オブジェクト）を機械的に数えられます。編集部は公開済み28系統について、合計747件のオブジェクト定義を採取しました。

ただし件数の多い順に優劣を付けることはできません。 粒度が製品ごとに違うからです。ある製品が「請求書」を1オブジェクトとして持ち、別の製品が「請求書ヘッダ」「請求書明細」に分けていれば、後者のほうが件数は多くなります。多いほうが優れているわけではありません。

4-2. ★パスの数を、優劣として読まないでください★

上の表に「128パス」「96パス / 151オペレーション」といった数字が並んでいます。この数字の意味を書いておきます。

パス＝窓口の住所の数（/companies /deals のような単位）
オペレーション ＝その住所に対してできる操作の数（同じ住所に「取得」と「登録」があれば2）
スキーマ／定義 ＝やり取りするデータの形の定義数

つまりオペレーションがパスより多いのは自然です。1つの窓口で複数の操作ができるからです。

そして数が多い＝機能が豊富、とは限りません。 設計の粒度の問題です。1つの窓口に操作をまとめる設計と、窓口を細かく分ける設計では、同じ機能でも数が変わります。

実務で効くのは、数ではなく次の2つです。

自分が動かしたい対象が、そのパスの一覧にあるか
その対象に対して、POST（登録）や PUT（更新）があるか

ジョブカン会計の「8パス、いずれもGETのみ」が、この2つを一度に示す例です。パス数が少ないことより、GETしかないことのほうが効きます。

boardの「139スキーマ・日本語ラベル付きフィールド455件」も見ておく価値があります。フィールドに日本語のラベルが付いているということは、仕様書を読む人が項目の意味を推測しなくて済む、ということです。これは変換の作業量を直接減らします。

4-3. 設計図が無くても、作れないわけではありません

念のため書いておきます。人が読むドキュメントしかない22件でも、連携は作れます。

違うのは作る前に確定できることの量です。

	設計図あり	人が読むドキュメントのみ
作れるか	○	○
窓口の数を数えられるか	○	人が数える
契約前に試せるか	ツールで試せることがある	ドキュメントを読んで想像する
見積もりの前提	置ける	置いて、外れたら追加費用

この記事は「設計図が無いベンダーは劣っている」と言っているのではありません。 稟議を通す前に、どちらなのかを知っておくと見積もりの幅が読める、という話です。

5. 国際比較は成り立ちません

「日本はOpenAPIの普及が遅れている」と書きたくなるところですが、書けません。

比べようとすると、こうなります。

出どころ	何を数えた値か	分母
この記事	日本の業務システム56件のうち、OpenAPIファイルを配布	56（編集部が選んだ）
開発者アンケート	「OpenAPIを使っている」と回答した開発者の割合	回答者数
公開APIディレクトリ	登録されているAPI仕様の数	登録されたものだけ

3つとも分母が違います。 17.9%と、他所の何%かを並べても、意味のある比較になりません。だから**「日本は遅れている」とも「進んでいる」とも書きません。**

6. 読者の行動：3つ見るだけ

検討中のシステムについて、開発者向けページを開いて、次の3つを順に見てください。

1. OpenAPI / Swagger のファイルへのリンクがあるか

.json か .yaml のダウンロードリンク、あるいはGitHubへのリンクを探します。あれば最良です。

2. HTMLのドキュメントだけか

エンドポイントの一覧ページがあるかを見ます。一覧が無いドキュメントは、全体像が掴めません（Jotform がこの例です）。

3. 申込やNDAが要るか

「APIのご利用には申込が必要です」と書かれていたら、見積もりの前に申込を出す必要があります。ここを見落とすと手戻りになります。

7. まとめ

機械が読める設計図を配っているのは、56件中10件（17.9%）
人が読むドキュメントのみが22件（39.3%）、仕様書そのものが確認できないのが18件（32.1%）
申込・NDA が要るのが5件。見積もり前に読めません
設計図の有無が一番効くのは見積もりの段階
分母が違うので国際比較はできません

「APIはありますか」の次に聞くべきなのは、こうなります。

「API仕様書は公開されていますか。OpenAPI などのファイルで配布されていますか。
それとも申込が必要ですか。」

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

対象は、編集部が一次調査を終えて公開している56システムです。日本の業務システム全体ではありません。「17.9%」は56件に対する割合であって、日本全体の値ではありません。
「17.9%しかAPIが無い」ではありません。 APIの有無と、設計図の配り方は別の話です。APIの公開状況は別の回で扱っています。
確認時期は2026年7月28日〜8月19日です。
分類は編集部が手で割り当てました。 キーワード照合では逆に読むためです（§3）。
OpenAPI は ISO や JIS の規格ではありません。「業界標準」という書き方は避けています。

規格の出典は OpenAPI Specification、OpenAPI Initiative です。各システムの「API仕様」欄は RenkeiMap で1件ずつ、出典URLと調査日つきで公開しています。

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

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

7-1. あわせて読む

APIとは何か（総論） — 「つながる」の正体を、56 件の実物で確かめた
API の用語 — REST・SOAP・JSON・CRUD を業務の言葉に置き換えた
「APIあります」の実態 — 公開度 × 契約条件の 2 軸で 56 件を分類した

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

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

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

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