設計図（OpenAPI）は配られているか — 3 つ見るだけ

調査の詳細

このページの答えは、以下の調べで出しました。対象・確認時期・出典を並べます。

56件の内訳

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

OpenAPI ファイルを配っている10件

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

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

「人が読むドキュメントのみ」が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：ドキュメントはあるがエンドポイントの一覧が無い

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

「申込・NDA を経て開示」が5件

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

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

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

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

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

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

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

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

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

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

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

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

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

APIが扱う「もの」の件数

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

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

パスの数を、優劣として読まないでください

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここでの調査範囲について

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

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