「API連携に対応しています」

SaaSの製品カタログや営業資料で、この言葉を見かけない日はありません。

しかし、いざ導入されたあと、情シスや社内SEが現場から突きつけられるのは、こんなクレームです。

「APIで自動化したはずなのに、毎月画面を開いて手入力する作業がどうしても消えない」

なぜ「APIがある」のに、手作業が残ってしまうのか。現場の業務は、APIでいったい何パーセント救われるのか。

その答えは、カタログの抽象的な「連携」という言葉の奥にある、**「項目名1つ1つの突き合わせ」**をしてみなければ分かりません。

編集部では、一次調査済みの公開82システムを対象に、APIが扱う対象922件のCRUD比率から、マネーフォワードクラウド請求書（450項目）および会計（890項目）の全画面項目×APIリクエストスキーマの逐項対照、さらには通信制限やプラン制約に至るまで、一次データから徹底的な実測を行いました。

そこから見えてきたのは、現場の前に3枚の壁が順に立っている、という構図でした。「APIがある」も「連携できる」も、「業務で使える」とは別の話なのです。

1枚目を越えても2枚目が、2枚目を越えても3枚目が残ります。そして3枚を越えた先にも、レート制限とプラン制約という運用を止める2つの障壁が待っています。本稿はこの3＋2を順に見ていきます。

先に結論を言っておきます。「APIで何パーセント救われるか」に、製品単位の答えはありません。 同じベンダーの製品でも、後で見るとおり請求書は72.2%、会計は17.5%と桁が違い、しかも会計もAPIが狙っている「仕訳」まわりに絞れば81.5%まで跳ね上がります。効くのは製品名ではなく、自分が自動化したい業務が、そのAPIの対象オブジェクトの内側にあるかどうかです。

上の図を見てください。販売管理システムから会計システムへ売上データを渡そうとしたとき、現場で起きる「4つの不一致」を表しています。

「得意先名」と「取引先名称」のように名前が違うだけならプログラムで変換できます。しかし、「顧客ID」と「取引先コード」のように採番ルールが違ったり、「税込」と「税抜」の計算が必要だったり、最悪の場合は「担当者」のように受け側のシステムに項目そのものが存在しないケースがあります。

「APIがある」と聞いて安心した現場が、なぜ手入力の罠に落ちるのか。大方向のストーリーを、実測データと図をもとに順を追って解き明かしていきます。

1. 「APIがある」の現実 — 読めるかは確かめられる。書けるかは確かめられない

第1の壁は、「APIがある」という言葉そのものの実態です。

上の図は、公開82システム〔v2 §0〕のうちAPI仕様が確認できる41系統・合計922のデータ対象（オブジェクト）について、CRUD（取得・作成・更新・削除）の操作ごとに「対応している」件数と割合を集計したものです〔v2 §1〕。

棒グラフが一目で示しているとおり、**「APIでできること」の91.6%（845件）は、一覧や詳細データを読み出す「Read（取得）」**です〔v2 §1〕。外部からデータを取り出して集計レポートやダッシュボードを作る用途であれば、大半のシステムでAPIが期待どおりに機能します。

ところが、現場がデータ連携に最も期待する**「他システムからデータを入れて（Create）、ステータスを更新し消込を行う（Update）」**という業務に目を向けると、状況は一変します。

外部から新しくレコードを作れるCreateは 56.7%（523件） と半数強に落ち込み、既存データを書き換えるUpdateに至っては 41.8%（385件） まで下がります〔v2 §1〕。

ここは正確に書きます。残りが「書けない」と確認できたわけではありません。 編集部の台帳では、Createが確認できなかった399件、Updateが確認できなかった537件は、いずれも**「公開仕様からは判定できなかった」**という記録です〔v2 §1〕。ベンダーが「書き込みは提供しない」と明言している対象は、調べた範囲では1件もありませんでした。

つまりこういうことです。「読める」は公開仕様から確かめられるのに、「書ける」は仕様書を読んでも確かめられない対象が半数以上ある。 「API公開」とうたわれていても、そこから読み取れるのは取り出す口（GET）が開いていることまでで、自分が入れたい対象に書き込む口が開いているかは、多くの場合ベンダーに聞くまで分かりません。稟議の段階で自力判定できない——これが第1の壁です。

2. 「連携できる」の非対称性 — 78.0%のシステムが抱える「読むだけ」と「書ける」の落とし穴

第2の壁は、システム内部における「連携方向の非対称性」です。

上の図は、APIを持つ41系統において、「読むだけの対象」と「書ける対象」がどのように混在しているかを示したものです。実測の結果、41系統のうち実に 32系統（78.0%）が、「読むだけの対象」と「書ける対象」を同時に抱えていることが分かりました〔v2 §2〕。

図の各システムの帯グラフが表すように、同じ製品のAPIであっても、対象ごとにできる操作がまったく異なります。

ジンジャー: 全156対象のうち、従業員情報や履歴など「読むだけ」が98件を占め、「書ける」のは58件にとどまります〔v2 §2〕。
KING OF TIME: 全24対象中、打刻など「書ける」のは6件だけで、残り18件は「読むだけ」です〔v2 §2〕。
マネーフォワードクラウド経費: 全34対象中、設定やマスタなど19件は「読むだけ」で、経費申請など「書ける」のは15件です〔v2 §2〕。
ジョブカン会計: 公開APIの4対象のすべてが「読むだけ」であり、外部から仕訳を書き込む口は公開仕様の範囲では見つかりません〔v2 §2〕。

このように、多くの業務システムは**「マスタや履歴は読めるが、伝票は外部から投入できない」あるいは「伝票は入れられるが、前提となるマスタはAPIで登録できず手作業が必須」**という片肺飛行の構造を持っています。

自社が自動化したい業務が「書く側」にあるのか「読む側」にあるのかを確認しないまま「連携可能」という言葉を信じると、開発の設計段階で確実に壁にぶつかります。

3. 「業務で使える」の検証① — マネーフォワードクラウド請求書（450項目中、業務入力79項目の真実）

そして最大の核心が、第3の壁である「業務で使えるか」という項目の粒度です。

編集部では、国内代表的SaaSである「マネーフォワードクラウド請求書」の全画面項目とAPI仕様を1行ずつ突き合わせました。

公式ガイドに掲載されている全450の画面項目を精査すると、図の上部に示した5つの区分に分かれます〔v2 §4〕。
小計や消費税額などの自動計算（Cat-2: 97件）、ボタンや検索などのUI操作（Cat-3: 62件）、自社口座などの初期設定（Cat-4: 126件）、別画面への重複再掲（Cat-5: 86件）を除外すると、外部システムから都度受け渡すべき「Cat-1 業務入力項目」は 79項目（全体の17.6%） です〔v2 §4〕。

この79項目をOpenAPI仕様書（raw/mf_invoice_openapi_v3.yaml）と照合した結果が、図の中段です〔v2 §4〕。

○ 完全（そのままAPIで書き込める）: 43 項目（54.4%）〔v2 §4〕
△ 制限（内部IDの事前取得等が必要）: 14 項目（17.7%）〔v2 §4〕
× 渡せない（APIに書込プロパティが無い）: 22 項目（27.8%）〔v2 §4〕

APIによるカバー率は、完全に渡せる○のみで 54.4%、制限つきの△を含めても 72.2% となります〔v2 §4〕。

ここで重要な事実を補足しておきます。components.schemas だけを読むと「取引先の送付先メールアドレスやCC、担当者、顧客コードがAPIで登録できない」と誤読しやすく、編集部も初期の調査でそう読み違えたことがありました。しかしOpenAPI原本の requestBodies を精査すると、DepartmentCreateRequest（部門作成）に email, cc_emails, person_name, peppol_id 等が網羅されており、PartnerCreateRequest にも code（顧客コード）が存在します〔v2 §4〕。取引先担当者情報はAPI経由で正しく登録できます。

では、図の下部に赤で示した「渡せない22項目（27.8%）」の正体は何でしょうか。
実測台帳の全件調査により、そのうち15項目が「販売管理台帳」画面の項目であることが判明しました〔v2 §4〕。請求書画面とは別に用意されている台帳機能ですが、API側にはこの台帳取引に相当するオブジェクト自体が存在しません。さらに、電子インボイス（Peppol）固有の通貨コードや買い手参照（5項目）、領収書の但し書き（1項目）、郵送コメント（1項目）もAPIでは書き込めません〔v2 §4〕。

画面には機能があっても、APIに対応するオブジェクトやプロパティがなければ、その業務は手作業として現場に残らざるを得ないのです。

4. 「業務で使える」の検証② — マネーフォワードクラウド会計（890項目中、業務入力126項目の壁）

続いて、バックオフィスの要である「マネーフォワードクラウド会計」の全890画面項目を突合した結果を見てみましょう。

図の上段が示すように、画面890項目のうち、レポート集計（160件）やUI操作（329件）、初期設定（167件）などを除いた業務入力項目（Cat-1）は 126項目（14.2%） です〔v2 §4〕。

この126項目をOpenAPI仕様書（raw/mf_accounting_openapi_v3.yaml）と突き合わせると、中段のグラフのとおり驚くべき偏りが現れます〔v2 §4〕。

○ 完全（そのまま書ける）: 15 項目（11.9%）〔v2 §4〕
△ 制限（内部ID必須など）: 7 項目（5.6%）〔v2 §4〕
× 渡せない（書込口が無い）: 104 項目（82.5%）〔v2 §4〕

会計業務の入力項目のうち、実に8割強（104項目）がAPIで渡せず、カバー率は ○のみで 11.9%、△を含めても 17.5% に留まります〔v2 §4〕。

なぜこれほど渡せないのか。それは、Web画面で多用される機能領域が、APIには丸ごと用意されていないからです。
仕訳辞書（18項目すべて×）、消費税申告（17項目すべて×）、証憑OCR読取情報（ファイル本体のアップロードのみで読取項目の書込APIなし・14項目×）、債務管理まわり（支払先11項目・取引8項目・分類マスタ5項目がすべて×）、勘定科目5項目と補助科目3項目の新規作成（読取専用で作成APIなし）、固定資産台帳（5項目すべて×）など、広大な機能がAPI未提供となっています〔v2 §4〕。

しかし、この数字から「会計APIは使えない」と結論づけるのは早計です。

図の下段に示したとおり、APIが本来対象としている「仕訳」「取引先」「明細」の27項目に絞れば、○15件＋△7件＝22件で、カバー率は 81.5% に達します〔v2 §4〕。日々の仕訳データを他システムから流し込むコア業務に限れば、8割以上の項目がカバーされているのです。

ただし、ここで現場を悩ませるのが「△（制限つき）の7項目」です。
仕訳を投入する際、勘定科目名や部門名などの文字列を直接渡すことはできません。マネーフォワード内部で採番された account_id や department_id といった数値の「内部ID」を事前に取得して指定することが必須となります〔v2 §4〕。マスタ作成APIが存在しないため、未登録の新部門が外部システムで発生した場合は、人間が事前に会計画面で手動登録しなければ、APIはエラーで停止してしまいます。

5. リアルタイム連携を阻む2大障壁 — レート制限とプラン制約

項目の突き合わせをクリアできたとしても、実運用でシステムを止める2つの壁があります。「レート制限（通信頻度の制限）」と「プラン制約」です。

上の図は、公開82システムの台帳調査から見えた実態を整理したものです。

5-1. ① レート制限の単位がバラバラで比較できない

公開82システムのうち、回数の上限が逐語で明記されているのは 23系統 でした〔v2 §7〕。しかし、その制限単位は以下のように完全にバラバラです。

1日あたり: BASE（100,000回/日）、board（3,000回/日）〔v2 §7〕
1時間あたり: freee人事労務（10,000回/時）、カオナビ（3,000回/時）〔v2 §7〕
5分あたり: Chatwork（300回/5分）、KING OF TIME（500回/5分）〔v2 §7〕
1分あたり: Google Workspace（1ユーザーあたり2,400クエリ/分）、LINE WORKS（フリー60回/分・上位240回/分）〔v2 §7・§8〕
1秒あたり: マネーフォワードクラウド請求書（3回/秒・帳票作成POST）〔v2 §7〕

単位が異なるため、数字の大小で緩さを比べることはできません。「1日3,000回」許容されていても「1秒3回」の制限があれば、夜間に売上伝票を一括投入した瞬間にバースト制限を超え、HTTP 429（Too Many Requests）エラーで連携が遮断されます。また、freee会計やマネーフォワードクラウド会計のように、具体的な数値を非公開としつつ「一定頻度以上のアクセスに429を返す」と定めているシステムもあり、リトライ設計が欠かせません〔v2 §7〕。

5-2. ② プランによる API の遮断

さらに、API利用が契約プランに縛られているケースがあります。台帳でプランに関する逐語を含む18行を精査すると、以下の実態が分かります〔v2 §8〕。

有料プラン必須: 「ジョブカン会計」は有料プラン契約時のみ利用可能。「ジョブカン勤怠管理」は有料プランに加えて**「NDA（秘密保持契約）の締結」**がAPI利用の必須条件です〔v2 §8〕。
プランによる上限の変動: 「LINE WORKS」は無料プランで60回/分、上位プランで240回/分。「BowNow」は無料プランで1,000回/日、通常有料プランで10,000回/日と桁が変わります〔v2 §8〕。
全プラン開放: 一方で「BowNow」のように有料・フリー問わず全プランでAPIを追加料金なしで利用できる例や、「マネーフォワードクラウド会計」のリモートMCPサーバーのように全プランで提供されている例もあります〔v2 §8〕。

自社の契約エディションでそもそもAPIが叩けるのか、大量データを流すために上位プランへの課金が必要ないかは、契約前に確認しなければならない重要事項です。

6. 現場の防衛策 — 契約前・設計前に確認すべき4つのチェックリスト

ここまでの実測から、SaaSの導入稟議を通す前、あるいはAPI連携の開発に着手する前に、社内SEや情シスが取るべき自衛策は明確です。

上の図に示した「3つの基本確認」に運用設計を加えた、**「4つの防衛チェックリスト」**を提案します。

① 自分が動かしたい業務項目（Cat-1）を書き出し、相手の一覧と突き合わせたか？
「請求書が連携できる」「仕訳が入る」という営業言葉を鵜呑みにしてはいけません。画面の入力項目のうち、自社で外部から投入したい項目をリストアップし、相手のAPIリクエストスキーマのプロパティと照合してください。
マネーフォワードクラウド請求書の販売管理台帳（15項目）や会計の仕訳辞書（18項目）のように、画面にあってもAPIオブジェクト自体が存在しない領域であれば、その時点で「手入力が残る」ことが確定します。なお、APIで渡せない項目をCSVインポートで迂回しようとしても、受取側のCSV受入枠が狭ければ渡せない原則は同じです。

② 対象オブジェクトに「C（作成）」と「U（更新）」の口が開いているか？
公開仕様から「読める」と確認できる対象は9割を超えますが、「書ける」と確認できるのはCreate 56.7%・Update 41.8%どまりです〔v2 §1〕。確認できなかった分は「書けない」ではなく「仕様書では分からない」なので、そこは推測せずベンダーに書面で聞いてください。 41系統中32系統（78.0%）で「読むだけ」と「書ける」が混在しているため、製品単位ではなく対象（オブジェクト）単位で聞くのが要点です〔v2 §2〕。

③ 内部IDやマスタの事前取得・解決手順が設計に入っているか？
会計システムの突合で明らかになったとおり、APIで仕訳を投入する場合、勘定科目名などの文字列指定はできず、内部ID（account_id等）の指定が必須となります〔v2 §4〕。マスタ作成APIが無い場合、未登録マスタが発生したときの運用フロー（誰がいつ画面で事前手動登録するか）をあらかじめ決めておく必要があります。

④ レート制限の単位と、自社の契約プランで通信量が収まるか？
自社のデータ量（月間件数・ピーク時のバースト件数）を計算し、相手の秒間・分間・日次制限に達しないかを確認してください〔v2 §7〕。また、API利用に追加料金や上位プランへのアップグレード、NDA締結が必要ないかを、契約前にベンダーへ書面で確認してください〔v2 §8〕。

おわりに

「API連携できるから、業務が自動化される」——それは、システムインフラとして受付窓口が開いているという事実に過ぎません。

冒頭の問い「APIで何パーセント救われるのか」への答えは、実測ではっきりしました。製品を選ぶ問いではなく、自分の業務がそのAPIの対象オブジェクトの内側にあるかを見る問いです。 会計は全画面項目では17.5%でも、APIが狙っている仕訳・取引先・明細に限れば81.5%。同じ製品で数字が4倍以上動くのですから、カタログの「API対応」も、この記事の一つの率も、そのままでは自社の答えになりません。自社が毎日入力している項目を書き出し、相手のリクエストスキーマと1行ずつ突き合わせる——遠回りに見えて、これが最短です。

なお、本稿の数字は編集部が公開仕様から確かめられた範囲のものです。確かめられなかったものを「無い」とは書いていません。「書ける」と確認できなかった対象については、ベンダーへの確認をおすすめします。

「APIがある」の言葉に惑わされず、オブジェクトの方向性、項目の過不足、内部IDの依存関係まで見通した設計を行うこと。それが、導入後の「こんなはずではなかった」を防ぐ唯一の道です。

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

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

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