API連携の開発費用は「1本いくら」で比較できるか｜認証・例外・相手側調整の見方

見積書に「API連携開発　3本　◯◯万円」と書かれている。API連携の開発費用が本数で決まっているように見えるけれど、この単価が高いのか安いのか判断できない。他社の見積書には「外部システム連携　一式」としか書いていないので、そもそも比べようがない——この記事は、その状態から一歩進むための手順書です。

先に立場を書いておきます。「1本いくら」という単価の出し方が間違っている、とは書きません。 本数が費用の実態とよく対応しているケースは実在します。ただし対応するのは「つなぐ本数」そのものではなく、その1本に含まれている作業の範囲です。相手側の仕様を調べること。認証をつなぐこと。データの項目を対応づけること。うまくいかなかったときの動きを決めること。試すこと。そして、相手側の担当者や窓口と話をすること。この範囲が同じなら本数比例は説明がつき、違うなら「3本」という数字は金額の根拠になりません。

以降では、この範囲を見積書と一次資料の両方から確認していきます。稼働後の話——つないだあとに毎月かかる費用のほうを知りたい場合は、API連携の保守費用は1本いくらが妥当かが対応する記事です。

TL;DR｜「1本いくら」が比較できる条件と、できない条件

• 「1本」の数え方が書かれていない見積書は、他社と比較できません。 連携先の会社名で1本なのか、システム単位なのか、呼び出すエンドポイント（連携先のAPIに用意された呼び出し先の入口。「取引先を登録する」「残高を取得する」がそれぞれ1つ）単位なのか、データの流れる方向ごとなのか。同じつなぎ方が、別の会社の見積書では「7本」になっていることがあります
• 認証は「つなぐ」の一言では決まりません。 たとえばkintoneのREST APIは、パスワード認証・APIトークン認証・セッション認証・OAuthクライアントを利用した認証の4方式を公式ドキュメントに列挙し、適用の優先順位まで定めています（2026年8月24日取得）。どれを選ぶかは、こちらの都合だけでなく相手側の設定でも決まります
• 相手側のセキュリティ設定が、そのまま実装項目になります。 同ドキュメントは、IPアドレス制限を設定している環境でAPIを実行する方法として、実行環境のIPを許可する／Basic認証のヘッダーを付与する／有効期限内のクライアント証明書を付与する、の3つを挙げています。クライアント証明書を使う場合はURLのサブドメインの後に .s を付ける必要があるとも明記されています。これは「1本」の内側で起きる差です
• テスト環境は「ある・ない」ではなく「何がテストできないか」で工数が変わります。 Shopifyの開発ストア（dev store）は公式ドキュメントで本番利用不可とされ、実際の決済プロバイダを通した本物の取引はできません。Stripeのサンドボックスにも、一部の決済料金体系（IC+料金）をテストできないなどの制限が明記されています（いずれも2026年8月24日取得）
• 「Webhookを受け取る」は1行の作業ではありません。 Webhookとは、相手側で何かが起きたときに相手側からこちらへ自動で送られてくる通知のことです。Shopifyの公式ドキュメントは、アプリが5秒以内に応答しなければ配信は失敗すること、失敗した配信は最大8回まで再送されること、失敗が続くと購読自体が削除されることを記載しています（2026年8月24日取得）。署名の検証、5秒以内に返すための処理の切り分け、取りこぼしたデータの復旧まで含めて、はじめて「受け取れる」状態になります
• 片側だけ成功する事態は、公的なガイドブックも想定しています。 デジタル庁のAPIテクニカルガイドブック（2024年9月30日改定）は、手続を扱うAPI（原典の定義は「一連の処理を通じ、手続に関する機能を提供するもの」）について呼び出し先と呼び出し元の整合を取る必要があるとしたうえで、「場合によってはマニュアルでの対処を許容するなど、整合性に対する割り切りを考慮した簡易な設計を目指すこと」を推奨しています。どこまで自動で守り、どこから人が直すのかは、技術ではなく発注側の判断です
• 連携を動かす基盤側の公開料金は、本数では課金していません。 Amazon AppFlowは「実行するフローの数と処理されるデータの量に対してのみ」課金すると明記し、Azure Logic Appsの従量課金はトリガーとアクションの実行回数で課金されます（いずれも2026年8月24日取得）。これは開発費の相場ではありませんが、本数以外の課金軸が実在することの確認にはなります
• 金額の高い・安いより先に決めることがあります。 本数の数え方に加えて、調査・認証・データ対応づけ・例外処理・テスト・相手側調整の6つがどこまで含まれるかを書面に落とせば、他社の見積書と同じ土俵に並びます。並べたあとで初めて、金額を比べる意味が出ます

見積書では、API連携の開発費がどう書かれているか

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

「一式」という表記そのものの読み解き方は、見積書の「一式」を工程・成果物・工数へ分けるにまとめています。ここでは、API連携に固有の分解だけを扱います。

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

最初に確認すべきなのは金額ではなく、数え方です。同じつなぎ方でも、数え方を変えると本数が変わります。

この5つのどれで数えているかを書いていない見積書は、他社の見積書と本数を並べても意味がありません。 「A社は3本で◯◯万円、B社は7本で◯◯万円」という比較は、A社が会社単位で数え、B社がエンドポイント単位で数えているだけかもしれません。

相見積もりを取る予定があるなら、先にこちらから一覧を作って全社に同じものを渡すのが確実です。列は「連携先／こちらのシステム／データの流れる方向／実行の契機／扱うデータの種類」の5つで足ります（上の数え方5分類とは別物です。この5列は、どの数え方をする会社にも同じ情報を渡すための項目です）。この一覧は、そのまま条件をそろえるシートになります。

API連携1本の開発費を実際に生む6つの作業

ここからが本題です。「1本◯万円」の中身を、実際に工数が発生する単位へ分解します。この6つのうち、見積書に行として現れるのはたいてい2つか3つです。

以降、APIを提供している会社・サービスを「提供元」、こちらがつなぐ相手のシステム全般を「連携先」と呼び分けます。前掲の数え方の表でいう「連携先の会社・サービス単位」が提供元です。

①相手側の仕様を調べる｜ドキュメントの質が工数を決める

つなぐ相手のAPIが、どこまで整備されているかで調査の重さが変わります。仕様書が機械可読な形式（OpenAPI仕様など）で公開され、サンプルとFAQが揃っている相手なら、調査は短く済みます。逆に、PDFの仕様書1本しかない、あるいは「担当者に聞いてください」という状態なら、読み解きと問い合わせの往復がそのまま工数になります。

デジタル庁のAPIテクニカルガイドブック（デジタル社会推進実践ガイドブック DS-464-2、2024年〈令和6年〉9月30日改定）は、APIを提供する側が用意すべきものとして、ドキュメントの公開、テストフォーム及びテスト環境、サンプルプログラムの提供、開発者コミュニティ、FAQを章立てで挙げています。

この資料の適用範囲には注意が必要です。 同ガイドブックは適用対象を「APIを提供する政府情報システム」と定め、地方公共団体や民間の情報システムについては「政府情報システムとAPI連携する際の参考としてください」と書いています。つまり民間SaaS同士の連携に直接適用される規範ではありません。ここでは「提供側にこれだけの準備項目がある」＝「準備されていない相手とつなぐと、その分がこちら側の工数になる」という読み方に限って使います。

発注側が確認すること（3点）

1. 連携先の開発者向けドキュメントのURLを、見積書を出した会社に挙げてもらう。 URLが出てこない連携先は、調査工数が読めていない可能性があります
2. そのドキュメントに、サンプルとエラー一覧があるかを見る。 技術的な内容を読む必要はありません。「例が載っているか」「失敗したときの説明があるか」だけで判断できます
3. 調査の結果で本体の金額が動くのかを聞く。 「調査は別途見積もり」となっている場合、調査後に本体が再見積もりになるのかどうかは、契約前に決めておく論点です

②認証をつなぐ｜方式は1つではなく、相手側の設定でも決まる

「認証・認可対応　含む」と書かれた1行の裏側を見ます。認証は方式が複数あり、選択によって実装も運用も変わります。

サイボウズがkintone REST APIの公式ドキュメントで公開している認証方式は、次の4つです（2026年8月24日取得）。

同ページは、この4方式に適用の優先順位（パスワード認証→APIトークン認証→OAuthクライアントを利用した認証→セッション認証）が定められていることも記載しています。

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

1つ目は、方式によって「誰の権限で動くか」が変わることです。 ID・パスワードを外部システムに預ける方式と、預けない方式では、退職者が出たときや監査を受けたときの扱いが変わります。これは技術の話ではなく、社内規程と情報システム管理の話です。

2つ目は、管理対象の数が本数と一致しないことです。 kintoneのAPIトークンは「アプリごとに生成する」と明記されています。連携先が1社でも、対象アプリが5つあればトークンは5つになります。同ドキュメントは、複数のトークンをまとめて指定する方法も示したうえで、「1回のリクエストで指定できるAPIトークンは9個までです。10個以上指定すると、エラーになります」と上限を明記しています。「連携1本」という単位は、この種の上限を表現できません。

3つ目は、相手側のセキュリティ設定がそのまま実装項目になることです。 同ドキュメントは、IPアドレス制限を設定している環境でREST APIを実行する場合、次のいずれかの方法で実行すると記載しています。

• 「IPアドレス制限」の設定で、REST APIを実行する環境のIPアドレスを許可する
• Basic認証を設定している場合は、リクエストヘッダーに「Authorization」ヘッダーを付与する
• 有効期限の過ぎていないクライアント証明書を付与する

さらに、クライアント証明書を使って実行する場合はURLのサブドメインの後に .s を付ける必要がある（例: sample.cybozu.com → sample.s.cybozu.com）と明記され、SAML認証を設定している環境で「ログイン時にSAML認証だけを使うように制限する設定」が有効な場合は、パスワード認証で実行できるユーザーがcybozu.com共通管理者のみに制限されるとも書かれています。

これらはすべて「kintone連携1本」の内側で起きる差です。 同じ「1本」でも、相手側がIPアドレス制限とSAML認証を入れているかどうかで、設計も、社内の調整も、運用開始後の手続きも変わります。見積もりを取る前に、自社（または連携先）のこれらの設定を確認しておくと、見積もりの前提を先にそろえられます。

なお、上の内容はkintoneの仕様です。他のSaaSが同じ選択肢と制約を持つとは限りません。ここで確認したいのは個別の仕様ではなく、「認証方式が決まっていない見積書は、工数の前提が決まっていない」という一点です。

発注側が確認すること（3点）

1. 連携先ごとの認証方式が、見積書または前提条件に書かれているか。 「認証対応　含む」だけでは方式が特定できません
2. 認証情報（ID・トークン・証明書）を保持するのがどちら側で、更新を誰が行うか。 期限切れで連携が止まったときの責任の所在に直結します
3. 連携先側のIPアドレス制限・クライアント証明書・SAML認証などの設定を、見積もり時点で確認済みか。 未確認なら、判明したときに金額が動くのかを先に決めておきます

③データの項目を対応づける｜件数ではなく、項目数と変換規則で増える

こちらの「取引先」と、相手側の「取引先」は、同じ意味の項目とは限りません。桁数が違う、必須項目が違う、区分の値が違う、日付の形式が違う——この対応づけを1項目ずつ決めていく作業が、見積書ではほとんど行として現れません。

前掲のデジタル庁のガイドブックも、節の1つを「個別データの各パラメータについて」に充て、項目名・入力規約・コード（分類体系）・構造化といった設計指針を扱っています。つまり、この作業は省略できる工程ではなく、設計として明示的に扱われる対象です。

発注側が確認すること（2点）

1. 対応づける項目の数と、変換規則が必要な項目の数。 「取引先を連携する」ではなく「取引先の12項目のうち3項目に変換規則が要る」まで分解されているか
2. 突き合わせが失敗したときにどうするか。 相手側に存在しないコードが来たら、止めるのか、既定値に寄せるのか、保留して人が判断するのか。これは業務ルールなので、発注側が決める論点です

この作業量は、データの件数ではなく項目数と例外の数で決まります。 「1万件のデータを連携する」と「10万件のデータを連携する」の差は、この工程ではほとんど出ません（性能試験や移行では別の話になります）。件数課金で見積もられている場合は、何が件数に比例するのかを確認してください。

④うまくいかなかったときの動きを決める｜見積書にいちばん現れない工程

API連携は、片側だけが成功する形で壊れます。デジタル庁のAPIテクニカルガイドブックは、この問題を「API呼び出し先と呼び出し元の処理における整合性担保」として扱っています。同書がここで整合を取る必要があるとしているのは手続を扱うAPI（原典の定義では「一連の処理を通じ、手続に関する機能を提供するもの」）についてですが、書かれている事象そのものは、業務データをやり取りする連携でも起こります。

例えば、API呼び出し先が正常に処理を終了することができたとしても、呼び出し元の処理がその後、異常終了した場合には、互いのデータの整合が取れない事態が発生する可能性があります。申請完了の通知を受けたにも関わらず実際は申請ができていないケース、申請途中でエラーになったはずなのに正常に申請ができている事態などが発生し得ます。

そして、対処についてはこう書かれています（原文の限定表現をそのまま引用します）。

このような事態を避けるため、通常は一貫性の確保できるトランザクション処理を構築して対処する必要がありますが、APIを介したトランザクション処理の管理は複雑となる場合が多く、場合によってはマニュアルでの対処を許容するなど、整合性に対する割り切りを考慮した簡易な設計を目指すことを推奨します。

ここが、発注側が判断すべき最大の分岐です。 自動で完全に守る設計は高くつきます。人が確認して直す運用を許容すれば安く済みますが、そのぶん毎月の手作業が発生します。どちらを選ぶかは、業務上その不整合がどれだけ痛いかで決まります。「受注が二重に立つ」と「社内の集計値が1日ずれる」では、許容できる割り切りの幅が違います。

見積書を見るときは、この判断が誰かによって既に下されていないかを確認してください。安い見積もりは、しばしば「割り切る」側を無言で選んでいます。それ自体は悪いことではありません。問題は、割り切った先の手作業が誰の担当にもなっていないことです。

具体的な実装項目としてどれだけの分量になるかは、相手側からの通知（Webhook）を受け取る場合の例で見えます。Shopifyの公式ドキュメントは、Webhookの配信について次の点を記載しています（2026年8月24日取得）。

「Webhookで受け取ります」という1行の裏側には、上表の6点が控えています。そのうち3行目（再送間隔）を除く5点は、そのまま実装項目になります。（この「6点」は、本記事の①〜⑥の作業区分とは別の数え方です。）上表はShopifyの仕様であり、他のサービスは再送回数も応答時間の条件も異なります。ここで確認したいのは、「相手側から通知を受け取る」形の連携では、この種の項目が必ず発生するという点です。

見積書に「例外処理」「エラー処理」「リトライ」に対応する行がまったく無い場合、それは工程が安いのではなく、含まれていない可能性があります。

発注側が確認すること（3点）

1. 自動で復旧する範囲と、人が確認・修正する範囲の線引きが書面にあるか。 口頭の「エラーが出ないように作ります」は線引きではありません
2. 人が直す範囲になった作業の担当が決まっているか。 割り切った先の手作業が、稼働後に誰の仕事になるのかを開発時点で決めます
3. 再実行したときに、同じ処理が二重に行われない作りになっているか。 受注や請求の連携では、二重処理がそのまま業務の損害になります

⑤試す｜テスト環境は「ある・ない」ではなく「何ができないか」

連携のテストは、相手側の環境に依存します。テスト環境が提供されていれば安く済み、提供されていなければ模擬（モック）を自分で作るか、本番で慎重に試すことになります。どちらもタダではありません。

前掲のデジタル庁のガイドブックは、手続を扱うAPIについて「実サービスへ影響を与えないように、テストすることが求められ」るとし、「検証環境、テスト用データによる本番環境でのテスト実施等の検討が必要となります」と記載しています。あわせて、実際のAPIが完成する前に動作をシミュレートするAPIモックサービスの活用を推奨しています。モックは工数を減らす手段であって、ゼロにする手段ではありません。

主要サービスの公開ドキュメントを見ると、テスト環境は存在しても制限があることが分かります（いずれも2026年8月24日取得）。

Stripeのサンドボックスには、実装パートナーなど外部のユーザーを招待できることも明記されています。 本番データへのアクセス権を渡さずに開発会社を入れられるかどうかは、契約とセキュリティ審査の手間に直結します。

発注側が確認すること（3点）

1. 連携先ごとにテスト環境があるか、無いか。 無い連携先は、テスト工数が上がるか、テストが浅くなるかのどちらかです
2. テスト環境で試せないことは何か。 上表のように、決済や課金の一部は本番でしか確認できないことがあります。そこを誰がどう検証するのかが、見積書のどこに入っているか
3. テスト用のデータを誰が用意するか。 相手側の本物のデータを使うのか、こちらで作るのか。個人情報を含む場合は、この判断自体が社内手続きを伴います

テスト費用そのものの読み方は、テスト費用が高い・書かれていないときの判断にまとめています。

⑥相手側と調整する｜こちらの工数にならないが、日程になる

最後は、見積書にほぼ現れない工程です。相手側のサービスにつなぐには、利用申請、審査、キーの発行、権限の付与といった手続きが要ることがあります。Shopifyの開発ストアも、作成には「Shopifyパートナーアカウント、または開発者権限を持つマーチャントストア」と、組織内で開発ストアを作成する権限が必要だと明記されています（2026年8月24日取得）。

相手が社内の別部門である場合はさらに厄介です。基幹システムを持つ情報システム部門、連携先企業の担当者、既存ベンダー——この人たちの回答待ち時間は、開発会社の工数にはなりませんが、プロジェクトの日程にはなります。

この工程が厄介なのは、待ち時間が誰の工数にも計上されないまま、日程だけを押し出すことです。相手側の審査に数週間かかっても、開発会社の作業時間は増えません。しかし、その待ち時間のあいだ連携の実装に着手できなければ、後続のテストと本番切り替えがそのまま後ろへずれます。固定納期の案件では、このずれが最後にテスト期間の圧縮として現れます。

しかも、待ち時間の長さは発注前に読みにくいものです。前掲のShopifyのように、必要なアカウントの種類と権限が公開ドキュメントに明記されている提供元もあれば、担当者どうしの調整でしか進まない相手もあります。提供元ごとに「手続きが公開されているか」を確認しておくと、日程の読みが変わります。

発注側が確認すること（3点）

1. 提供元ごとに、利用申請や審査が要るかどうか。 要る場合は、公開された手続きなのか、個別の調整なのか
2. 相手側との窓口を誰が持つか。 発注側が持つのか、開発会社が代行するのか。代行する場合はその工数が見積書のどこに入っているか
3. 相手側の回答が遅れたときに、日程と費用がどう動くか。 待機が発生した場合の扱いが契約に書かれているか

6つの作業を一覧にする

下表の「何の数に比例するか」は、提供元を1本と数えた場合を基準にしています。手元の見積書が別の数え方をしているなら、まず前掲の5分類のどれに当たるかを確認してください。

この表が、本数課金を評価するときの物差しになります。 ①②⑥は提供元の数に比例しやすく、③④は比例しません。⑤は中間です。つまり、本数比例が説明できるかどうかは「増える2本目が、新しい提供元なのか、同じ提供元の中の追加なのか」でほぼ決まります。

本数ごとの段階料金は妥当か

ここまでを踏まえて、「連携1本につき◯万円」「3本まで◯万円、以降1本ごとに◯万円」という段階料金の妥当性を判定します。結論を先に固定はしません。合理的なケースと、確認が必要なケースを分けます。

段階料金が合理的といえる条件

最後の行が重要です。 ①〜⑥のどれか1つに属するのではなく、すべての連携が共有する部分（連携の土台、ログ、エラー時の通知の仕組み）は1本目に入るので、2本目以降が1本目より安くなる階段は、合理的な形の1つです。 逆に、すべての本が同じ単価で並んでいる見積書は、共通部分がどこに入っているのかを聞く価値があります。

確認が必要なケース

• 同じ提供元の同じAPIに対して、エンドポイントを増やしただけの場合。調査も認証も窓口も共通なので、2本目以降の増分は1本目より小さいはずです。同額なら根拠を聞いてください
• データの流れる方向が違うものが同じ単価になっている場合。こちらから送る連携と、相手側から通知を受け取る連携（前掲のWebhookの例）では、実装項目の数が違います
• リアルタイム連携と夜間一括連携が同じ単価になっている場合。求められる応答時間と、失敗したときの復旧手順が違います
• 例外処理・テストが本数単価に溶けている場合。前掲の③④は本数に比例しない作業です。すべてが本数単価に含まれていると、1本減らしても金額がほとんど下がりません
• 本数を減らしたときに減額されない場合。増やすと有償で、減らしても戻らない条件になっていないか
• 相手側の仕様がまだ確認できていないのに、本数だけで単価が決まっている場合。①が終わる前に②〜⑤の見積もりは確定できません。「調査後に再見積もり」となるのか、この金額で固定なのかを契約前に決めてください

参考｜連携を動かす基盤の公開料金は、本数で課金していない

段階料金を評価する材料として、開発費ではなく「連携を動かす基盤」の公開料金を見ておきます。クラウド事業者が提供する連携サービスは、料金体系を公開しています（いずれも2026年8月24日取得）。

この2つは開発費の相場ではありません。 つないだあとに動かすための基盤の料金であり、開発会社の見積もりと直接比べるものではありません。ここから読み取れるのは1点だけです——連携の費用を測る軸として、公開された料金体系では「本数」ではなく「実行回数」と「データ量」が使われているということ。

これは「本数課金が間違い」という意味ではありません。開発費（1回きりの作り込み）と、運用費（毎回動くたびのコスト）で、費用が伸びる軸が違うということです。開発費は①〜⑥の作業量で伸び、運用費は実行回数とデータ量で伸びます。見積書でこの2つが1つの単価に混ざっている場合は、分けてもらってください。

なお、AppFlowの実際の料金は、リージョンと宛先の条件で変わります。

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

手元の見積書を、次の表と照らしてください。「高すぎる／安すぎる」で判断せず、書かれているか・書かれていないかで仕分けます。 観点の先頭にある①〜⑥は、前掲の6つの作業のどれに対応するかを示しています。番号のない4行は、6つの作業のどれか1つではなく、見積書全体にかかる観点です。

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

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

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

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

A社の見積書

B社の見積書

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

A社が高いとは限りません。 分解されていないだけで、実際には異常系のテストや例外設計までB社より手厚く積んでいることもあります。ここで言えるのは「A社の見積書では、①〜⑥のどれが入っているかを検証できない」という一点です。分解を依頼して断られた場合は、その理由まで含めて判断材料になります。

「安い」API連携見積もりのほうが危険なとき

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

• 異常系のテストが入っていない。 正常に動く経路だけを確認した連携は、相手側が遅い日、相手側が落ちた日、想定外の値が来た日に初めて壊れます
• 不整合が起きたときの手順が無い。 前掲のとおり、割り切って人が直す設計は正当な選択です。ただし手順書と担当が無ければ、割り切ったのではなく放置しただけになります
• 通知を受け取る連携なのに、二重処理の防止に触れていない。 再送は仕様として存在します（前掲のShopifyの例では最大8回）。同じデータが二重に処理されると、受注や請求として業務側に出ます
• テスト環境が無い連携先について、テスト工数が積まれていない。 本番で試すか、モックを作るかのどちらかしかありません。どちらも工数です
• インターフェース設計書が納品物に入っていない。 稼働後に保守会社を変える、あるいは自社で改修する選択肢が失われます
• 相手側の調整工数がゼロで積まれている。 相手が社外・別部門である以上、往復はゼロになりません
• 稼働後の保守が見積もりに一切登場しない。 相手側のAPIは、こちらの都合とは無関係に変わります。開発費だけを比べて安いほうを選ぶと、稼働後に差が出ます

このうち上3つは、見積書の行を見れば判定できます。 「異常系」「エラー処理」「再送」に対応する行がどこにも無い連携見積書は、安いのではなく、その作業を含んでいません。

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

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

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

お世話になっております。
ご提示いただいたお見積もりについて、社内で比較検討するため、
以下8点をご回答いただけますでしょうか。

1.【本数の定義】
お見積もりの「API連携　◯本」について、何を1本として数えているか
（連携先の会社単位／システム単位／エンドポイント単位／
データの流れる方向単位／実行の契機単位）をご教示ください。
あわせて、各1本の内訳を「連携先・こちらのシステム・
データの流れる方向・実行の契機・扱うデータ」の列を持つ
一覧でいただけますか。

2.【相手側仕様の確認状況｜①】
連携先ごとに、参照された開発者向けドキュメントのURLと、
現時点で確認済みの範囲・未確認の範囲をご教示ください。
未確認部分が判明した場合、本見積もりの金額は変わりますか。

3.【認証方式｜②】
連携先ごとの認証方式（OAuth／APIキー・トークン／その他）と、
認証情報を保持するのがどちら側か、更新作業をどちらが行うかを
ご教示ください。連携先側にIPアドレス制限・クライアント証明書・
SAML認証などの設定がある場合、その対応は本見積もりに含まれますか。

4.【データの対応づけ｜③】
連携する項目の総数と、そのうち変換規則が必要な項目の数を
ご教示ください。また、想定外の値や存在しないコードが来た場合の
既定の動作（停止／既定値／保留して人が判断）をご教示ください。

5.【不整合時の扱い｜④】
片側だけ処理が成功して整合が取れなくなった場合について、
自動で復旧する範囲と、人が確認・修正する範囲の線引きをご教示ください。
人が対応する範囲については、その手順書が納品物に含まれますか。

6.【再実行と二重処理｜④】
連携が失敗したときの再実行の回数・間隔と、再実行によって
同じ処理が二重に行われないようにする仕組みをご教示ください。
相手側から通知を受け取る形の連携がある場合は、
その通知が重複して届いた場合の扱いもお願いします。

7.【テスト｜⑤】
連携先ごとにテスト環境（サンドボックス等）の有無と、
そこでは検証できない範囲をご教示ください。
また、正常系・異常系それぞれのテストケース数と、
テストデータを誰が用意するかをご教示ください。

8.【相手側との調整と成果物｜⑥】
連携先への利用申請・審査の要否と、その窓口をどちらが担当するかを
ご教示ください。相手側の回答待ちで日程が延びた場合の費用の扱いも
あわせてお願いします。最後に、インターフェース設計書と接続情報の
一覧が納品物に含まれるかをご教示ください。

お手数をおかけしますが、よろしくお願いいたします。

回答をどう読むか

「追加で確認が必要」側の回答が悪いわけではありません。 発注側がまだ連携先を確定していない段階では、開発会社も答えようがないことがあります。その場合は、答えられない項目を「未確定」として見積書に明記してもらい、確定した時点で金額がどう動くかだけを先に合意するのが現実的です。

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

1. 見積書の「◯本」が何を数えているかを、一覧で出してもらう。 ここが決まらないと他社と比較できません
2. 連携先ごとに、①〜⑥のどれが含まれているかを割り振ってもらう。 割り振れない行が、次に聞く場所です
3. 不整合が起きたときに人が直す範囲を、自社として決める。 これは開発会社ではなく発注側の判断です
4. 上の8問を送る。 回答が揃ってから、初めて金額の議論に入ります
5. 稼働後の費用を、開発費と同じ場で確認する。 相手側のAPIは変わり続けます。開発費だけを比べて安いほうを選ぶと、稼働後に差が出ます。保守側の見方はAPI連携の保守費用は1本いくらが妥当かにまとめています

開発費全体の中でこの連携費用がどのあたりに位置するのかを確認したい場合は、システム・アプリ開発費用の相場と見積もり妥当性を先に読むと、規模感の当たりが付けやすくなります。

根拠資料と適用条件

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

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

よくある質問