基幹連携など重要用途で個別に締結するAPI契約書。可用性保証と障害時の責任範囲を定め、個人情報保護法第27条の提供・委託の区分を契約上明確にする。
⚠ 本書式は弁護士監修前の草稿である。監修完了まで販売・配布・公開を禁止する。 本書式は一般的な情報提供を目的としたものであり、個別・具体的な法律相談に代わるものではない。
API利用契約書
第1部: 書式本文
〇〇〇〇(以下「甲」という。API提供者)と〇〇〇〇(以下「乙」という。利用企業)とは、甲が提供するAPI(以下「本API」という。)を乙の基幹システムに連携させるにあたり、次のとおりAPI利用契約(以下「本契約」という。)を締結する。
第1条(目的) 本契約は、乙が本APIを継続的かつ重要な業務用途で利用するにあたり、甲乙間の責任範囲、可用性の水準及び障害発生時の対応手続を明確にすることを目的とする。
第2条(利用範囲) 甲は乙に対し、別紙に定める用途、接続環境及び最大トランザクション量の範囲内で、本APIを利用することを許諾する。
第3条(可用性の保証水準) 1. 甲は、本APIの月間稼働率が別紙に定める水準(以下「SLA」という。)を満たすよう合理的な努力を払う。 2. SLAが未達となった月がある場合、甲は乙に対し、別紙に定める算定方法によるサービスクレジットを付与する。 3. 前項のサービスクレジットは、天災地変、通信事業者の障害その他甲の責に帰すことができない事由による停止時間を算定の基礎から除く。
第4条(障害発生時の対応) 1. 甲は、本APIに障害が発生したことを認知した場合、遅滞なく乙に対しその旨を通知し、復旧見込みを共有する。 2. 甲は、障害発生後、別紙に定める期限内に原因及び再発防止策をまとめた報告書を乙に提出する。
第5条(データの取扱いと個人情報保護法上の区分) 1. 本API連携を通じて甲乙間で授受されるデータに個人データが含まれる場合、甲乙は当該データの提供が個人情報保護法第27条に定める第三者提供に該当するか、又は同法第27条第5項に定める委託に伴う提供に該当するかを別紙において明確にする。 2. 委託に伴う提供に該当する場合、甲は乙の指示の範囲内でのみ当該データを取り扱い、目的外利用を行わない。 3. 第三者提供に該当する場合、甲乙はそれぞれ自らの責任において個人情報保護法上必要な同意取得その他の手続を履行する。
第6条(セキュリティ対策) 甲は、本APIの提供にあたり、通信の暗号化、アクセスログの記録及び不正アクセス検知の仕組みを整備し、乙の求めに応じて対策状況を報告する。
第7条(対価) 乙は、本APIの利用の対価として、別紙に定める料金を別紙に定める支払条件に従い甲に支払う。
第8条(接続仕様の変更管理) 甲は、本APIの接続仕様(エンドポイント、認証方式、データ形式等)を変更する場合、乙のシステム改修に要する期間を考慮し、原則として90日前までに書面で通知する。
第9条(責任制限) 1. 甲は、甲の故意又は重過失に起因する場合を除き、本APIの利用又は利用不能により乙に生じた損害について、直近12か月間に乙が甲に支払った利用料金の総額を上限として賠償責任を負う。 2. 前項の規定は、甲の故意又は重過失による場合には適用しない。
第10条(秘密保持) 甲及び乙は、本契約の履行の過程で知り得た相手方の技術情報、業務情報及び顧客情報を、相手方の事前の書面による承諾なく第三者に開示してはならない。
第11条(監査) 乙は、甲のセキュリティ対策の状況につき、年1回を上限として、甲の事前の同意を得たうえで監査又は資料開示要求を行うことができる。
第12条(契約期間及び終了時の対応) 1. 本契約の有効期間は〇年間とし、期間満了の3か月前までにいずれかの当事者から書面による終了の申出がない限り、同一条件で1年間自動更新される。 2. 本契約が終了する場合、甲は乙が代替システムへ移行するために必要な合理的な期間、本APIの利用を継続させるよう努める。
第13条(反社会的勢力の排除) 甲及び乙は、自己が暴力団その他の反社会的勢力に該当せず、これらと関係を有しないことを表明し、保証する。
第14条(合意管轄) 本契約に関する紛争については、〇〇地方裁判所を第一審の専属的合意管轄裁判所とする。
第2部: 立場別・場面別の書き換えパターン
A. API提供者向けの修正
A-1. サービスクレジットの上限設定
修正後:「本条に基づくサービスクレジットの累計額は、当該月の利用料金の30%を上限とする。」 一言解説: SLA未達時の補償を利用料金の枠内に収め、提供者の損失を予測可能な範囲に限定する修正である。
A-2. 責任制限額の引下げ
修正後:「甲の賠償責任は、直近3か月間の利用料金の総額を上限とする。」 一言解説: 基幹連携における障害の影響は大きくなりがちであるため、提供者は責任上限をより短い期間で算定することを望む傾向がある。
B. 利用企業向けの修正
B-1. SLA未達時の解除権の追加
追加条文例:「SLAが3か月連続で未達となった場合、乙は催告を要せず本契約を解除することができる。」 一言解説: 基幹業務に使用するAPIの品質低下が続く場合に、乙が代替手段へ迅速に切り替えられるようにする修正である。
B-2. 責任制限の適用除外事由の拡大
修正後:「第9条の責任制限は、甲の故意又は重過失による場合のほか、本契約上の秘密保持義務違反及び個人情報保護法上の義務違反による場合には適用しない。」 一言解説: 情報漏えい等、利用企業にとって影響が特に大きい事由については、責任制限の対象から外すことを求める修正である。
第3部: 書き方と法的ポイント解説
使う場面/使ってはいけない場面 本書式は、決済連携、在庫連携、認証基盤との連携など、事業の基幹システムに組み込む重要用途でAPIを継続利用する場面において、可用性保証や責任分担を個別交渉のうえ締結する契約書として用いる。他方、不特定多数の開発者に画一的な条件でAPIを無償公開する場面には適さず、定型約款としてのAPI利用規約を用いるべきである。
根拠法令 本契約の中核は、個人情報の授受に関する個人情報保護法第27条の整理である。同条第1項は、個人データを第三者に提供するにあたり原則として本人の同意を要する旨を定める一方、同条第5項第1号は、委託に伴って個人データを提供する場合には第三者提供に該当しない旨を定めている。API連携が単なるデータ処理の委託(乙の指示のもとでの取扱い)なのか、甲が自らの目的のために取得したデータを乙に独自に提供する第三者提供なのかによって、必要な手続(委託先の監督義務か、本人同意か)が異なるため、契約上区分を明確にすることが実務上重要である。また、SLAや責任制限条項は法律上の要求事項ではないが、システム障害が事業継続に与える影響の大きさに応じて交渉される点で、通常のAPI利用規約とは異なる実務上の位置づけを持つ。
実務でよくある失敗と対策 第一に、個人データの授受が第三者提供か委託に伴う提供かを契約上明確にしないまま連携を開始し、後日、個人情報保護委員会への対応や本人からの開示請求の場面で整理に窮する失敗がある。第5条のように類型を明記し、委託の場合は監督義務の内容も具体化することが対策となる。第二に、SLAを定めたものの、天災地変等の免責事由が曖昧で、稼働率算定を巡って紛争になる失敗がある。第3条第3項のように免責対象となる停止時間を明記することが望ましい。第三に、責任制限条項の上限額が低く抑えられているにもかかわらず、乙が基幹業務全体をAPI連携に依存する設計としてしまい、障害発生時の実損害と補償額に大きな乖離が生じる失敗がある。B-1のような解除権の設定や、重要度に応じた冗長構成(フォールバック手段の確保)をシステム設計段階から検討することが対策となる。
可用性保証の水準や責任制限額の妥当性は業界慣行や取引規模によって異なるため、個別事案は専門家に確認することが望ましい。
第4部: 使用前チェックリスト
- [ ] 個人データの授受が第三者提供か委託に伴う提供かを別紙で明確にしたか
- [ ] SLAの数値及びサービスクレジットの算定方法を具体的に定めたか
- [ ] SLA算定から除外する免責事由(天災地変等)を明記したか
- [ ] 障害発生時の通知期限及び報告書提出期限を定めたか
- [ ] セキュリティ対策の内容と監査権の行使頻度・手続を確認したか
- [ ] 接続仕様変更の予告期間がシステム改修に十分な長さか確認したか
- [ ] 責任制限条項の上限額と適用除外事由(故意・重過失等)を確認したか
- [ ] 契約終了時の移行支援・利用継続期間について定めたか
- [ ] 委託先の監督義務(個人情報保護法上)の履行方法を具体化したか
- [ ] 秘密保持義務の対象情報の範囲を確認したか