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

調査の詳細

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

56件の内訳

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

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

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

jGrants API 仕様 原文

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

マネーフォワード クラウド給与 API 仕様 原文

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

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

マネーフォワード クラウド会計 API 仕様 原文 KING OF TIME API 仕様 原文 Zoho CRM API 仕様 原文 Yahoo!ショッピング API 仕様 原文

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

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

このうち 3 件は、読む前に何が要るかを提供元自身が書いています。eLTAX / PCdesk は、仕様の開示を希望する場合は地方税共同機構へ申し込むよう案内しています。eLTAX / PCdesk API 仕様 原文 ジョブカン勤怠管理は、有料プランの契約とNDA の締結を条件に開発者向けに公開すると書いています。ジョブカン勤怠管理 API 仕様 原文 formrun は、API キーの取得と仕様書へのアクセスの前に規約への同意を求めています。formrun API 仕様 原文

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

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

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

最初、編集部はキーワード照合でこれを数えようとしました。調査記録の記述に「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と調査日つきで公開しています。