API連携の保守費用は1本いくらが妥当か｜仕様変更・監視・障害調査で見る

保守の見積書に「API連携保守　3本　月額◯万円」と書かれている。API連携の保守費用が本数で決まっているように見えるけれど、それが妥当なのかどうかは判断できない。稼働してからこの1年、連携が止まったという話は聞いていないのに、毎月同じ金額が請求されている——この記事は、その状態から一歩進むための手順書です。

先に立場を書いておきます。「本数で課金するのは間違いだ」とは書きません。 本数が費用の実態とよく対応しているケースは実在します。ただし対応するのは「つないだ本数」そのものではなく、その本数の内訳に含まれている4つの作業です。相手側の仕様変更に追従すること。失敗を見つけること（監視）。止まったときにどちら側の問題かを判定すること（切り分け）。そして、止まった分を追いつかせること（再送）。この4つの範囲が同じなら本数比例は説明がつき、違うなら「3本」という数字は金額の根拠になりません。

以降では、この4つを見積書と一次資料の両方から確認していきます。

TL;DR｜「1本いくら」の妥当性は、本数ではなく4つの作業で決まる

• 「1本」の数え方が書かれていない見積書は、比較も交渉もできません。 連携先の会社名で1本なのか、エンドポイント単位なのか、送る方向ごとなのか。同じ「3本」が、別の会社の見積書では「7本」になっていることがあります
• 相手側の仕様変更は、あなたの都合とは無関係に、公表されたスケジュールで来ます。 Shopifyはバージョン管理の対象と明示したAPIについて各安定版を最低12か月サポートし、Google Ads APIは「年に最大2回のアップグレードが必要」と明記しています。一方でSalesforceのREST APIは最低3年です（いずれも2026年8月24日取得）。同じ「3本」でも、どこにつないでいるかで強制対応の回数は変わります。回数は連携先ごとに調べれば分かります
• 監視のツール費は公開されています。公開されていないのは、失敗を見つけたあとに人が動く部分です。 Mackerelは外形監視20件まで月2,180円（税込・月単位の契約）の最低利用料金に含めており、Datadogの外形監視（Synthetic Testing & Monitoring）の「APIテスト」は最小価格でテスト実行1万回あたり月6.25 USD（年額請求時）です（いずれも2026年8月24日取得）。見積額とこの差額が、何の対価なのかを聞いてください
• いちばん揉めるのは「どちら側が壊れたか」の判定です。 「当社起因の障害に限り対応」と書かれた契約は、起因を誰が判定するかが書かれていなければ、実質的に範囲が決まっていません
• 止まったあとの「再送」は、業務上のリスクを持ち込むことがあります。 Stripeの公式APIリファレンスは、二重実行を防ぐ冪等キー（同じ処理を1回だけにするための識別子）が「作成から24時間以上経過すると自動的に削除されうる」と記載しています。翌日以降に人手で流し直す運用は、この保護の外側です
• 金額の高い・安いより先に決めることがあります。 本数の定義に加えて、追従・監視・切り分け・再送の4つがどこまで含まれるかを書面に落とせば、他社の見積書と同じ土俵に並びます。並べたあとで初めて、金額を比べる意味が出ます

この記事は保守側の話です。まだ発注前で「連携1本あたりいくらで作れるのか」を判断したい場合は、API連携の開発費用と見積もり内訳の見方を先に読んでください。「本数・件数・台数で単価が決まる見積もり」全般の判断枠組みは数量課金の見積もりをどう判断するかにまとめています。

見積書では、API連携の保守がどう書かれているか

まず、実際の書かれ方を並べます。それぞれの表記から何が決まらないのかと、後述する4つの作業のどこに当たるのかを並記しました。

保守見積書全般の分解手順はシステム保守費用の相場と妥当性で扱っています。ここではAPI連携に固有の部分だけを見ます。

「1本」の数え方は、たいてい書かれていない

自社ECと会計SaaSと広告媒体をつないでいる、という前提で考えてみます。同じ連携について、次のどの数え方をしても「本数」は成立します。

数え方が書かれていない見積書は、本数を比較できません。 A社の「3本」とB社の「7本」を並べても、それが範囲の違いなのか数え方の違いなのかが分からないためです。相見積もりを取るなら、金額を聞く前に「この一覧を、御社の数え方で何本と数えますか」と全社に同じ表を送るほうが早く進みます。

API連携の保守費を実際に生む4つの作業

ここからが本題です。保守費を動かしているのは本数ではなく、次の4つの作業量です。

なお、保守費全体を「待機・人の作業・システムの作業・実費」という4区分に分けて読む方法がシステム保守費用の相場と妥当性にありますが、これから見る4つの作業とは別の切り口です。 前者は見積書の行を費目で分ける枠組み、後者はAPI連携で人と機械が実際に何をしているかの分類です。以降で「4つの作業」と書いたときは後者を指します。

①相手側の仕様変更に追従する｜提供期間は公式に決まっている

API連携でいちばん誤解されているのは、「作ったあと、こちらが何も変えなければ動き続ける」という前提です。相手が外部のサービスである以上、相手側の都合で期限が来ます。そして多くの提供元は、その期限を公開しています。

以下は主要な提供元の公式ドキュメントに書かれている方針です（いずれも2026年8月24日取得）。

この表から読み取ってほしいのは、単価でも相場でもなく、回数です。

Google Ads APIは自ら「年に最大2回のアップグレードが必要」と書いています。Shopifyの各安定版は最低12か月なので、少なくとも年1回は版を上げる前提になります。一方でSalesforceは最低3年のサポートを掲げ、廃止予定のバージョンを使っている顧客へはサポート終了の少なくとも1年前に通知すると明記しています。同じ「連携3本」でも、前者3本と後者3本では、数年の間に強制的に発生する対応作業の回数が、最大で数倍の差になりえます。

したがって、本数だけを見た比較には意味がありません。手元の見積書に対して確認すべきなのは、次の一覧です。

「うちが使っているバージョンが何で、いつまで使えるのか答えられない」という回答が返ってきた場合、それ自体が判断材料です。 金額の妥当性の話ではなく、期限管理が誰の担当にもなっていない状態を示しています。

予告なく入る変更もある

版を上げるタイミングだけが仕様変更ではありません。提供元によっては、後方互換性があると判断した変更を通知なく入れることを明記しています。

freeeの開発者向けリファレンスは「後方互換性ありの変更」として、次の6項目を通知なく入れることがあると記載しています（2026年8月24日取得）。

1. 新しいAPIリソース・エンドポイントの追加
2. 既存のAPIに対して必須ではない新しいリクエストパラメータの追加
3. 既存のAPIレスポンスに対する新しいプロパティの追加
4. 既存のAPIレスポンスに対するプロパティの順番の入れ変え
5. keyとなっているidやcodeの長さの変更（長くする）
6. エラーメッセージの変更

同ページには、後方互換性のない変更についての事前告知期間の記載は確認できませんでした（記載が無いことと、告知が行われないことは別です。実際の運用は提供元に確認してください）。

経営側にとって重要なのは6項目の技術的な中身ではなく、この6つはいずれも「相手は仕様どおりに動いている」のに自社側が止まりうる変更だという点です。たとえば5番目は、受け取る側で桁数を固定していれば入らなくなります。6番目は、エラーの文面で処理を分けていれば分岐が狂います。

これが保守費の中身の1つです。予告なく入る変更に耐えるように作ってあるかどうかは、開発時の設計で決まり、保守費の水準に跳ね返ります。 見積書に「仕様変更対応」という行があるとき、それが「壊れてから直す」費用なのか「壊れないように追従する」費用なのかを聞き分けてください。前者は件数が読めず、後者は計画に載せられます。

②監視する｜ツール費は公開されている、その外側は公開されていない

API連携の障害には、サーバーが落ちる障害と違う性質があります。画面は普通に動いているのに、裏側でデータだけが流れていないという壊れ方をします。誰も気づかないまま数日が過ぎ、月末の突合で発覚する。この「気づくまでの時間」を短くする作業が監視です。

サーバー監視全般（台数・メトリック数での課金、有人対応の判断）はサーバー監視費用の内訳で扱っています。ここでは外形監視（外部から実際にAPIへアクセスして、応答が返るかを確認する監視）のように、監視の対象数や実行回数で課金される部分だけを見ます。API連携の見積書が「本数」で書かれるとき、ツールの実費が発生しているのはここだからです。ただし、どちらのタイプも「1本増えたら一定額増える」という単純な形にはなりません。 監視対象数で課金するタイプは一定件数ごとの階段状で、区切りの内側では本数が増えてもツール費が動きません。実行回数で課金するタイプは、エンドポイント数にも監視間隔にもロケーション数にも比例します。

いずれも2026年8月24日に公式料金ページから取得しました。ここから、API 1本を常時監視するのにツール側でいくらかかるかを計算してみます。以下は公開単価をもとにした筆者の計算で、各社が公表している単価ではありません。Datadogの行は年額請求時の最小価格6.25 USDを基準にしており、オンデマンド価格9 USDの場合はおよそ1.44倍になります。

Mackerelの2,180円は最低利用料金なので、ホスト監視を併用していてすでにその額を超えている場合、20件までの外形監視はその中に収まり、追加費用が発生しないことがあります。上表の「1件あたり月109円」は、外形監視だけを使う場合の上限側の数字です。

桁を確認してください。 ツールの実費にあたる部分は、Mackerelの外形監視なら20件まで合計で月2,180円（税込。ホスト監視を併用していて最低利用料金を超えていれば追加費用ゼロのこともあります）、Datadogの「APIテスト」なら1エンドポイントあたり監視の間隔とロケーション数に応じて月5.4〜81 USDです。通貨も課金方式も違うので横に並べては読めませんが、5分間隔・1ロケーションのような一般的な条件なら、どちらで見ても「1本あたり月数万円」という見積額とは桁が違います。1分間隔・3ロケーションまで詰めれば差は縮まりますが、それでも見積額の主要部分をツール費で説明することはできません。 これはベンダーが不当に上乗せしているという話ではありません。残りの金額が何の対価なのかを、見積書が説明できているかという話です。

残りの部分の候補は3つあります。①失敗を検知したあと、人が見て切り分けること。②その人を、決められた時間帯に確保しておくこと（待機）。③検知の設計そのもの（何を、どの間隔で、何回連続で失敗したら発報するか）を作り、変え続けること。この3つのうちどれが含まれているかを聞くのが、金額の妥当性を確かめる最短の質問です。

なお、有人での監視・対応そのものの相場レンジは本記事では提示しません。同じ税区分・同じ対応時間帯・同じ一次対応範囲へそろえられる複数社の公式料金表を確認できておらず、数字を出せば推測になるためです。

「監視しています」が指しうる3つの検知対象

API連携の監視には、サーバー監視には無い落とし穴があります。

1. エンドポイントが応答すること。 APIが正常応答を返すかを見る監視です。ただし応答が返っていても、中身が空だったり、こちら側の取り込みが止まっていたりすれば、業務は止まっています
2. 業務データが実際に流れていること。 件数や金額を突合して初めて分かります。とくにバッチ連携は「動かなかったこと」の検知が難しく、毎朝5時に動く処理がそもそも起動しなければ、エラーは出ません。何も起きないだけです
3. 相手側サービスが動いていること。 相手側の障害は、こちらの監視には映らないことがあります。相手のステータスページを誰が見るのか、見ていないなら何で気づくのかが、決まっていないことがあります

見積書に「API監視」と書かれていたら、上の3つのうちどれを見ているのかを確認してください。

③障害の切り分け｜「どちら側が壊れたか」を決める作業に誰が責任を持つか

API連携の障害対応で、実際に時間を使うのは修理ではなく切り分けです。連携が止まったとき、原因の候補は少なくとも5つあります。

保守契約に「当社起因の障害に限り対応」と書かれている場合、起因を誰が判定するかが書かれていなければ、対応範囲は実質的に決まっていません。 調べてみないと起因は分からないのに、調べる作業そのものが範囲外に置かれうるためです。

契約書の書かれ方ごとに、何が決まって何が決まらないかを並べます。

見積書と契約書で確認する順番は3つです。

1. 一次切り分け（どちら側の問題かを判定するところまで）が保守に含まれるか。含まれるなら、それは無償なのか、時間の上限があるのか
2. 相手側が原因だったと判明した場合の扱い。調査時間は請求されるのか。相手への問い合わせは誰が行うのか
3. 相手側と直接やり取りする窓口の権限。SaaSによっては、契約者アカウントからでなければサポートへ問い合わせできないことがあります

3番目は費用より先に効きます。契約しているのは発注側で、実際に調べたいのはベンダー、という組み合わせが起こりえます。 誰のアカウントで問い合わせるかを決めていないと、障害のたびに社内調整から始まります。

④再試行と再送｜止まったあとに追いつく作業

連携が数時間止まると、その間のデータが送られていない状態が残ります。復旧とは「またつながること」ではなく、止まっていた間の分が正しく反映されることです。ここが保守費の中で、いちばん軽く見られている部分です。

確認すべきことは4つあります。

4番目は、経営側に直接返ってくるリスクです。決済や受注の連携では、再送が業務事故になりえます。

この点について、Stripeの公式APIリファレンスは仕組みを明記しています（2026年8月24日取得）。同社のAPIは冪等キー（クライアント側が発行する識別子で、同じ処理の再送をサーバー側が見分けるためのもの）を受け付け、同じキーでの後続リクエストには最初のリクエストと同じ結果を返します。これにより、通信エラー時の再送で二重に処理されることを避けられる、と書かれています。

同時に、限界も書かれています。キーは「作成から24時間以上経過したものは自動的に削除されうる」とされ、削除後に同じキーを再利用した場合は新しいリクエストとして扱われると明記されています。また冪等キーが効くのはPOSTリクエストで、GETとDELETEには効果がないとも書かれています。

ここから、経営側が持ち帰るべき論点は1つです。「翌営業日に、担当者が手作業で同じデータを流し直す」という運用は、この保護の外側になりえます。 障害の翌朝にリカバリするという説明を受けたら、二重実行が起きない仕組みになっているか、なっていないなら誰がどう突合するのかを確認してください。これは技術の話ではなく、二重請求が起きたときに誰が説明するのかという話です。

なお、この仕組みは連携先が対応していて、かつ自社側の実装がそれを使っている場合にのみ効きます。「うちの連携は冪等になっていますか」は、そのまま質問として使えます。

4つの作業のまとめ｜このうち2つは、止まらなかった月にも発生する

ここまでの4つのうち、①追従と②監視は、連携が一度も止まらなかった月にも発生します。 冒頭で挙げた「この1年止まっていないのに毎月同じ金額」という状態は、それだけでは費用が無駄だった証拠になりません。むしろ①②が行われているから止まっていない、という関係もありえます。

なお、以降の表に出てくる認証情報・証明書の更新管理は、①追従の一部として扱っています。相手側が決めた期限が来て、こちらが対応しなければ止まるという点で、バージョンの提供終了と同じ性格の作業だからです。

したがって確認すべきなのは「今月は何もしていないのでは」ではなく、その月額に対応する行が契約書のどこにあるかです。行が特定できないなら、次に見る「本数比例が説明できるか」の判定にも進めません。

その料金体系が合理的といえる条件｜「本数」で課金してよいとき

ここまでを踏まえると、本数比例が説明のつく条件が見えてきます。ベンダー側の言い分が正当だと言えるのは、次のいずれかに当てはまるときです。

逆に、次の場合は本数比例の説明が足りていません。

• 同じ提供元の同じAPIに対して、エンドポイントを増やしただけの場合。バージョン管理も認証情報も窓口も共通なので、2本目以降の増分は1本目より小さいはずです
• 監視も切り分けも再送も含まれていないのに、本数で単価が決まっている場合。何が本数に比例しているのかを説明できるかを確認してください
• 本数に依存しない固定費（連携基盤の維持、待機体制、報告作業）が別行になっていない場合。すべてが本数単価に溶けていると、連携を1本止めても費用がほとんど下がりません

本数より効く軸がある｜呼び出し量と、相手側のプラン

もう1つ、見積書にはまず書かれていない軸があります。同じ「1本」でも、相手側の契約プランによって使える速度が違うということです。

Shopifyは、APIごとのレート制限を公式ドキュメントで公開しています（2026年8月24日取得）。

同ページには、制限を超えると一時的に受付を止められ（スロットル）、上限の空きが戻るまで待つ必要があると書かれています。また「Shopifyはプラットフォームの安定性を守るため、一時的にレート制限を引き下げることがある」とも明記されています。

経営判断として押さえるのは、次の3点です。

1. 同じ連携でも、相手側のプランが上位か下位かで、処理しきれる量が桁で変わります。 「1本」という単位はこの差を表現できません
2. こちらの事業が伸びると、連携の負荷も伸びます。 商品数・受注数が増えたときに現行の制限で足りるのかは、いま確認できます
3. 相手側がプランを変えると、こちら側の設計の前提も変わります。 ダウングレードは、こちらの連携にとっては仕様変更と同じ意味を持ちます

数量が増えたときに費用が比例するのかしないのかという論点は、この記事の連携以外にも共通します。判断枠組みは数量課金の見積もりをどう判断するかにまとめました。

4状態で仕分ける｜説明済み・要確認・高リスク・判断不能

手元の見積書と契約書を、次の表と照らしてください。「高すぎる／安すぎる」で判断せず、書かれているか・書かれていないかで仕分けます。

「判断不能」の欄に印が集中したなら、価格交渉より先にやることがあります。 書かれていない項目を書いてもらうことです。この段階では金額の議論に入れません。

手元に見積書のPDFやテキストがある場合は、見積書の登録不要レビューで行項目の分解と確認質問の生成を試せます。見積書のテキストはブラウザ内で識別情報をマスクしたうえで診断にかけられ、結果を見るまでメールアドレスの入力は不要です。返ってくるのは「高い／安い」の判定ではなく、上表と同じく確認すべき項目とベンダーへの質問です。

同じ「3本・月◯万円」でも、中身は同じではない

金額が同じ2社の見積書を並べたときに、何が違って見えるかを整理します。以下は実在の見積書ではなく、書き方の違いを見るために作った対比です。

A社の見積書

B社の見積書

合計金額が同じでも、この2枚から得られる情報量は違います。

A社が高いとは限りません。 分解されていないだけで、実際にはB社より手厚いこともあります。ここで言えるのは「A社の見積書では検証できない」という一点です。分解を依頼して断られた場合は、その理由まで含めて判断材料になります。

「安い」API連携保守のほうが危険なとき

過大な見積もりだけを警戒していると、逆側を見落とします。API連携で、金額が小さいことがリスクになるのは次の場合です。

• 監視が入っていない。 連携は静かに壊れます。壊れてから気づくまでの日数が、そのまま業務影響の大きさになります
• バージョンの提供終了日を誰も管理していない。 前掲のとおり、期限は公開されています。期限当日に止まってから対応すると、緊急対応の単価と業務停止が同時に発生します
• 再送の設計が無い。 止まった分を追いつかせる手段が「人が手で入れ直す」しかない場合、障害の規模がそのまま人件費と入力ミスのリスクになります
• 相手側の障害を検知する手段が無い。 こちらが正常でも業務は止まります
• テスト環境が無い、または相手側のテスト環境を用意していない。 バージョンを上げるとき、本番でいきなり試すことになります
• 設計書と接続情報が引き継げる形になっていない。 保守会社を変える選択肢そのものが失われます

このうち上3つは、見積書の行を見れば判定できます。 「監視」「バージョン管理」「再送」に対応する行がどこにも無い保守見積書は、安いのではなく、その作業を含んでいません。

ベンダーへそのまま送れる確認質問8問

ここまでの論点を、コピーしてそのまま送れる形にしました。技術的な知識がなくても送れます。

そのまま送れるメール文面

いつもお世話になっております。

現在の保守契約について、社内で内容を整理しております。
API連携の保守費用について、下記8点をご回答いただけますでしょうか。
金額の交渉を目的とした確認ではなく、契約範囲を社内で正確に
把握するためのものです。

1. 現在保守対象となっている連携について、連携先・エンドポイント・
   データの流れる方向・実行の契機（定時／即時など）の一覧を
   ご教示ください。あわせて、見積書の「◯本」が、この一覧の
   どの単位で数えられているかをお知らせください。

2. 各連携について、現在利用しているAPIのバージョンと、提供元が
   公表している提供終了日（サポート終了日）を一覧でご教示ください。
   公表されていない場合は、その旨をご記載ください。

3. 提供元のバージョン更新に伴う改修は、現在の保守費に含まれますか。
   含まれる場合は年間の想定回数と作業時間の上限を、含まれない場合は
   別途見積もりの単価と、これまでの実績回数をご教示ください。

4. 連携の監視について、監視対象としているエンドポイントの一覧と、
   監視間隔をご教示ください。あわせて、(1)エンドポイントの応答、
   (2)データが実際に流れていること、(3)相手側サービスの障害、の
   どれを検知対象としているかをご記載ください。

5. 連携の異常を検知した場合、誰に、どの手段で、何分以内に
   通知されますか。当社側の担当者は通知先に含まれていますか。
   また、通知後に貴社が着手する時間帯（曜日・時間）を
   ご教示ください。

6. 連携が停止した際の一次切り分け（当社側・相手側のどちらに
   起因するかの判定）は、現在の保守費に含まれますか。含まれる
   場合、相手側に起因すると判明したときの調査時間の扱い（無償か、
   請求対象か）をご教示ください。また、起因の判定は誰が行いますか。

7. 連携が停止していた間に送信できなかったデータについて、
   (1)どこに保持されるか、(2)自動での再試行の回数と間隔、
   (3)再試行の上限に達した後の扱い、(4)再送時に同一データが二重に
   処理されない仕組み（同じデータを2回送っても1回しか処理されない
   仕組み。冪等性）の有無、の4点をご教示ください。

8. 相手側サービスへの問い合わせが必要になった場合、どちらの
   アカウントで、どなたが問い合わせを行う想定でしょうか。
   現在の契約で、貴社から直接問い合わせが可能かどうかも
   あわせてご教示ください。

お手数をおかけしますが、ご確認のほどよろしくお願いいたします。

回答をどう読むか

返ってきた内容は、次の基準で仕分けます。

「追加で確認が必要」側の回答が悪いわけではありません。 保守が長く続いている現場では、当初の設計を知る人が残っていないことがあります。その場合、まず現状を書き出す作業自体が必要で、それは有償の作業になりえます。その作業を発注するかどうかも、経営判断の1つです。

この記事のあとに進む順番

1. 見積書の「◯本」が何を数えているかを、一覧で出してもらう。 ここが決まらないと他社と比較できません
2. 各連携のバージョンと提供終了日を出してもらう。 来年度の保守費に強制対応が何回入るかが分かります
3. 見積書の各行を「待機・人の作業・システムの作業・実費」に割り振る。 割り振れない行が、次に聞く場所です。手順はシステム保守費用の相場と妥当性にあります
4. 上の8問を送る。 回答が揃ってから、初めて金額の議論に入ります

まだ発注前で、これから連携を作る段階なら、開発時点で保守しやすい形にできる余地があります。API連携の開発費用と見積もり内訳の見方を先に確認してください。保守費の多くは、開発時の設計で決まります。

根拠資料と適用条件

本記事で使用した資料と、その適用条件です。いずれも2026年8月24日に取得しました。

本記事で提示していないもの、およびその理由です。

よくある質問