会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準

会計ソフトのAPIは、「APIが公開されているか」だけでは選べません。自動化したい業務を一件に絞り、必要な記録を必要な権限で読み書きできるか、契約・追加費用と処理上限が想定件数に合うか、書き込み後の結果を対象endpointの仕様に沿った方法で確認できるかを確かめます。比較の単位を製品名から業務へ置き換えると、APIの存在と自社の工程で使えることを分けて判断できます。

見る基準は、利用条件、対象データと操作、費用と制限、書き込み後の検証の四つです。製品ごとに「全プラン」「追加料金なし」「同時実行数」といった表示の意味が異なるため、同じ業務を同じ条件で照合します。

一つの業務を四つの基準で比べる

基準	照合する内容	判断につなげる方法
利用条件	契約中の製品・プラン、認証方式、接続する事業所やアカウント、実行ユーザーの権限	必要なユーザー権限や契約条件を満たせなければ、その業務はAPIで進められると判断しない
対象データと操作	APIが扱う記録の種類（resource・record）と項目、個別のendpoint（呼び出し先）で必要な取得・作成・更新・削除操作	別のrecordの対応状況や製品全体の機能一覧から、対象recordの操作を推測しない
費用と制限	製品契約料とAPI追加料金、プラン上の登録件数、1リクエストの明細数、endpoint別の呼び出し頻度、アカウント同時実行枠	それぞれの単位を分け、通常時とピーク時に必要な件数・並列数へ当てはめる
書き込み後の検証	対象endpointが応答でIDを返すか、そのIDで取得できるか、期待値との照合、結果が分からない場合に人へ戻す条件	成功コードだけで完了にせず、ID指定で取得できる場合は保存内容を照合します。別の確認方法も確かめられない処理は自動完了にしません

処理上限に出てくる数字は、同じ意味ではありません。1リクエストに含められる明細行数は一回の送信データの大きさ、rateは時間当たりの呼び出し数、同時実行枠は並行して処理できる数です。プランごとの仕訳登録上限は製品内の登録条件です。単位を分けておけば、別の機能やアカウントの数字を自分の業務へ流用せずに済みます。

実業務一件を通して確認する

製品を並べる前に、対象の業務で何が読まれ、何が書き込まれ、どの状態なら完了とするかを決めます。たとえば仕訳の登録を候補にするなら、必要な記録と項目、作成後に照合する値、例外時に承認する人を先に定めます。仕訳APIがあるという表示だけでは、その項目や利用者の権限まで確かめたことになりません。

対象の業務を一件選び、入力、出力、完了の判定、人の承認が残る場所を決めます。業務名だけでなく、どの記録が変われば完了かを書きます。
必要な記録の種類・項目と操作を特定し、その呼び出し先が対応しているか確認します。機能一覧に似た名称があるだけでは、必要な項目の読み書きができるとは限りません。
接続に使うアプリとユーザーで認証し、対象アカウントに必要な権限を確かめます。読み取りは必要な項目をread-onlyの範囲で確認します。書き込み検証を行う場合は、提供元が用意するsandboxまたは本番データから隔離した検証用アカウントを使います。どちらも使えない場合は会計recordを作成・更新せず、書き込み検証は未確認として残します。アカウント管理者または提供元が認める方法を確認できるまでは、書き込みを完了扱いにしません。必要な権限は対象操作に絞ります。
製品契約料、APIの追加費用、プラン内の登録条件、1回の送信量、endpointごとの呼び出し頻度、アカウント同時実行数を別々に記録し、見込む通常量とピーク量に照らします。公開資料に値がなければ、無制限とは扱わず未確認として残します。
手順3で確認したsandboxまたは隔離した検証用アカウントだけで、最小限のテストデータを一件作成または更新します。ID指定で再取得するのは、選んだendpointが応答でIDを返し、そのIDを指定した取得操作にも対応すると現行仕様で確認できる場合に限ります。再取得できた場合は必要な項目を期待値と照合します。マネーフォワードでは、選択したAPIの現行仕様で応答IDとID指定GETの両方に対応しているか確かめます。ID指定で再取得できない場合の書き込み結果は、アカウント管理者または提供元が認める方法が決まるまで未確認として残します。
429や照合不一致が起きた場合の停止条件と担当者を決めます。再試行は、該当するendpointまたはアカウントの公式仕様に示された条件に従い、別のAPIのstatusや待機時間を流用しません。再試行前に前回の書き込み結果を確認し、結果が分からない場合は処理を止めて人の確認へ戻します。

この一連の確認を、各社の公式資料にある条件へ当てはめます。そこで比べるのは機能の数ではなく、対象業務の必要条件がどこまで公開資料と実際のアカウントで確かめられるかです。

freee会計はプラン対応とendpointの範囲を分ける

freee会計のPublic APIは、公式のプラン一覧で「全プラン」が利用可能とされています。ただし、この表示が示すのはPublic APIの利用可能プランです。必要なendpoint・項目・操作がすべてのプランで同じことや、API利用の追加料金がないことまでは保証しません。対象endpointを現行リファレンスで確かめ、契約中のプランと費用は別に確認します（freee「提供するPublic API」）。

OAuthの認可では、利用者がfreeeへログインし、接続する事業所とアプリに与えるアクセスを選んで許可します。アプリ種別の接続事業所数は、private applicationが最大5、public applicationが初期値20と案内されています。公開審査や申請で変更される場合があります。これは接続できる事業所数であり、APIを何回呼べるかという上限ではありません（認可コード、アプリケーションタイプ）。

取引（deals）のAPIには、一覧・個別取得のGET、作成のPOST、更新のPUTが掲載されています。この例から言えるのは取引resourceの取得・作成・更新までで、他のrecordに同じ操作が揃っているとは限りません。さらに、取引の作成・更新では一取引あたりの明細行上限が100件です。これは一回の取引データに含める行数で、共通の呼び出し回数上限ではありません（取引APIの一覧、取引APIの明細行数変更）。

個別endpointの値を製品全体へ広げないことも必要です。公式告知で確認できる毎分300件は、ファイルボックスの証憑アップロードAPIに対する事業所単位の制限です。上限を超えた場合の一時制限もこのendpointについての案内であり、freee会計全体のstatus codeや再試行間隔を示すものではありません。ほかの会計APIに共通する日次・時間・分間の呼び出し上限や一般的な同時実行数は、今回確認した資料では確定できません。証憑を扱う業務でも、アップロードendpointの制限と仕訳endpointの制限を分けて確認します（証憑アップロードAPIの変更告知）。

書き込み後の確認例として、振替伝票のPOST応答では2026年7月1日からtxn_numberが返らなくなり、応答のIDを使ってGETで必要な番号を取得する方法が案内されています。作成応答に欲しい項目が含まれないときは、IDを保持して再取得する設計にします。freee会計Public APIの追加料金は確認資料に価格の記載がないため、利用可否と費用を同じ質問にまとめず、契約時点の条件を確認してください（振替伝票APIの仕様変更告知）。

マネーフォワードは製品契約・API料金・rateを分ける

マネーフォワードクラウド会計の機能ページには、仕訳の一覧・個別取得・作成・更新・削除、証憑、貸借対照表・損益計算書・月次推移、一部のマスター取得などが掲載されています。取引明細の登録は最大1,000件／リクエストです。この件数は一回に送る明細数であり、月間API呼び出し数や実行速度の上限ではありません。掲載機能は全endpointのpermissionやpayload仕様を代わりに示すものではないため、必要な操作のAPIリファレンスも照合します（マネーフォワードクラウド会計のAPI連携）。

クラウド会計・確定申告を契約しているユーザーにはAPIの追加料金がないと案内されています。これは会計製品自体の契約料が不要という意味ではありません。基礎となる製品プランと契約費用を含めて判断します。同じFAQには、ひとり法人プランで年度内の仕訳が500件を超えると新規登録できず、再開にはスモールビジネス以上へのアップグレードが必要という説明があります。これは特定プランの年間仕訳登録条件でありAPI呼び出し数の上限ではありません。FAQから上位プランの件数を推測することもできません（クラウド会計のFAQ）。

認証はOAuth 2.0とAPIキーが案内されていますが、どちらを使えるかはendpointによって異なります。対象APIの認証方式を先に確認し、認証に使う操作の制限を仕訳などの業務endpointのrateと混同しないようにします。rate limitはendpointごとに独立し、許容回数はendpointや状況で変化します。超過時は429 RATE_LIMIT_EXCEEDEDとなり、待ってから再試行する案内があります。固定の全会計API呼び出し数や共通同時実行数は、この資料からは確定できません（認証・認可方式、API共通仕様のレート制限）。

この条件を業務へ当てはめると、「APIの追加料金なし」だけで比較を終えず、契約中の製品プランに必要な仕訳登録が許されるか、使うendpointの認証方式とrateが合うかを別々に確かめられます。仕訳登録件数とAPI呼び出し数は単位が違うため、実際に使うendpointの案内を確認します。

NetSuiteは対応recordとアカウント全体の同時実行枠を見る

NetSuite REST Web Servicesが示す操作はget・search・add・update・deleteですが、対象はRESTに対応するrecordに限られます。利用にはアカウントでREST Web Servicesを有効にし、SuiteCloud Termsを受諾し、roleに必要なpermissionを設定します。Oracleのrecord matrixや対象アカウントのREST API Browserでrecordとfieldを確認してから、必要な操作ができるかを決めます（REST Web Servicesの対応操作、REST利用の前提条件、対応record一覧）。

RESTの認証はOAuth 2.0またはTBAに対応し、OracleはOAuth 2.0を推奨しています。ユーザーIDとパスワードでログインする方式は対応していません。連携用のintegration recordやuser tokenなど設定条件があるため、対象アカウントの認証方式とroleを担当者に確認します。通常の連携をadmin roleで動かすことは推奨されていません（NetSuite RESTの認証設定、REST Web Servicesのrole設定）。

同時実行数の公式表は、SuiteCloud Plusのライセンス数を含む階層別の参考値です。Plusなしの値から各階層で許可される最大ライセンス数までを示します。SuiteCloud Plusはどのservice tierにも含まれない別購入で、Oracle Helpには価格が掲載されていません（SuiteCloud Plusの参考表）。

Service tier	SuiteCloud Plusなし	階層内の最大ライセンス時の参考値
Standard	5	15
Premium	15	45
Enterprise	20	80
Ultimate	20	140

この表の値を対象アカウントの確定枠として使わず、実際のIntegration Concurrency LimitをNetSuite管理者に確認します。RESTのrequestはWeb ServicesとRESTletでアカウント共通の枠を消費するため、他の連携も含めて実アカウントの値を見る必要があります。integration別の枠を返すgovernanceLimitsの照会自体はadministrator roleが必要ですが、これは通常の連携をadminで動かす根拠ではありません（governanceLimitsの説明、同時実行枠の共有）。

同時実行枠を超えると429 CONCURRENCY_LIMIT_EXCEEDEDが返り、Oracleはretry logicを案内していますが、固定の待機時間は示していません。運用する並列数は実アカウント枠をNetSuite管理者に確認して決め、429時は再試行前に前回処理の結果を照合します。Oracleのcontact更新例ではPOSTやPATCHの成功が204 No Contentとなり、別の例ではrecordをID指定でGETできます。自社で使うrecordでも、成功応答の有無と保存後の値を別々に確かめてください（REST Web Servicesの429処理、OAuth 2.0のcontact例、ID指定のGET例）。

確認できない条件を残して採否を決める

比較の結果は、「APIがあるから自動化できる」ではなく、選んだ業務が契約中のプランと実際の権限で動き、想定量を処理し、書き込み後に照合できるかで決めます。freee会計の一般的なendpoint quotaやPublic API追加料金、マネーフォワードの共通同時実行数や上位プランの仕訳件数、NetSuiteのアカウント別同時実行枠とSuiteCloud Plusの価格など、資料から確定できない条件は未確認として残ります。未確認を無制限や一律の料金へ読み替えず、予定量で問題になるものを契約担当者や製品の現行資料で確認してください。

対象endpointの読み書き、認証、制限を確かめられない場合は、その工程に人の確認を残すか、別の方法を検討します。保存後の照合にIDを使うのは、対象endpointが応答IDを返し、そのIDを指定した取得に対応する場合に限ります。書き込み結果の確認方法が決まらない工程は未確認として残し、必要な項目の保存結果、例外時の停止、人への引き渡しを確かめてから自動化候補にします。