「読める」と「書ける」は別 — API があるシステムで、項目まで開けて確かめる

調査の詳細

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

調べた範囲と、調べていないこと

本文の数は、編集部が API オブジェクトの一覧まで採取できたシステム の中で数えた値です（対象・確認時期は下に書きます）。個々の数の元になった行は、各システムの製品のページに欄ごとの原文と調査日つきで置いてあります — IT連携マップのシステム一覧から辿れます。 対象は、編集部が API オブジェクトの一覧まで採取できたシステムです。数えたのは API が扱う対象 747 件と、画面側の様式 12,500 項目あまり。「日本の業務システム全体の 78%」ではありません — この採取できた分母の中での割合です。確認時期は 2026 年 7 月 28 日〜9 月 6 日で、記事の数字は 2026-09-06 の測定値で凍結しています（出典 URL と調査日は 1 行ずつ EVIDENCE.md に）。調べていないのは、API ドキュメントに一覧が無いシステムと、画面項目を全件そろえられなかったシステムです。

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

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

上の図は、APIを持つ41システムにおいて、「読むだけの対象」と「書ける対象」がどのように混在しているかを示したものです。調査記録を数えた結果、41システムのうち実に 32システム（78.0%）が、「読むだけの対象」と「書ける対象」を同時に抱えていることが分かりました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

公開82システムのうち、回数の上限を具体的な数字で明記しているのは 23システム でした。しかし、その制限単位は以下のように完全にバラバラです。

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

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

② プランによる API の遮断

さらに、API利用が契約プランに縛られているケースがあります。調査記録のうちプランに関する記述を含む18行を精査すると、以下の実態が分かります。

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

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

調査記録から: 経理・会計／人事・労務の「API の対象と仕様」を横に並べる

下の表は RenkeiMap の調査記録 から機械で描いています（記号や札をクリックすると総結と原文・出典）。

経理・会計

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

人事・労務

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

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

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

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

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

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

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

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

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