API・外部サービス連携の規約：誰が接続し、何を渡し、止まったら誰が負うか

結論：連携の規約は「4つの流れ」に分け、流れごとに設定する人・渡すデータ・止まったときの扱いを決める

SaaSの規約には、「外部サービス連携」の条が一つだけ置かれ、免責、認証情報の管理、データの扱いまでが詰め込まれていることが少なくありません。つなぎ方が増えると、誰が設定し、何が行き来し、止まったときに誰が何を負うのかが、条文の中で混ざります。結論から言うと、連携は次の4つの流れに分けると整理できます。流れごとに、設定する人、データの向き、止まる原因が違うので、条項で決める中心も違います。

OAuth（オーオース）で許可する範囲を「スコープ」、許可の結果として発行される通行証のような文字列を「アクセストークン」といいます。レート制限は、一定の時間内に受け付ける要求の回数の上限です。

外部の生成AIにデータを送る機能の論点は生成AI機能付きSaaSの契約条項、外部サービスが止まったときの稼働水準はSLAを約束しないSaaSの提供条件で扱っています。消費者向けアプリのAIサービス・APIの一般論は、姉妹サイトのAIサービス・APIの利用規約のページをご覧ください。

よくある失敗と直し方：「外部サービス連携」の条を一つ置いただけの規約

実務で見られる法人向けSaaSの利用規約に、「第三者サービスとの連携」の条と「API連携・外部ツール利用時の責任範囲」の条が、離れた位置に二つあるものがあります。どちらも外部サービスの仕様変更や停止を免責する条ですが、用語も書き方もそろっていません。継ぎ足しを重ねた規約で起きやすい形で、問題は次のように分けられます。

• 同じ趣旨の条が二つあり、定義語が二組ある。「第三者サービス」と「外部サービス」、「連携データ」と「API連携情報」のように言葉が違うと、片方にしかない免責が他方と食い違ったとき、解釈で争いになります。
• 免責の書き方が条ごとに違う。一方は「一切の責任を負わない」とだけ書き、他方は「故意又は重大な過失がある場合を除き」と書く。故意や重大な過失まで免責する書き方は効力を制限される余地があるため、除外を置くのが通常で、除外のない条を根拠にすると食い違いを突かれます。
• 「API連携情報」の一語に、性質の違うものが入っている。API、データフィード、Webhook、認証キー、ログイン情報を一括りにしていますが、発行する人も、保管する人も、漏えいしたときに起きることも違います。
• 人のログインの条項が、API連携の条の中に入っている。ID・パスワードの管理義務や、一致すれば本人とみなす条項が連携の条の項にあると、アカウントの条を改訂するときに漏れます（利用者アカウントとセキュリティのページ）。
• 条の追加で参照がずれる。条を足すと後ろの番号が動き、秘密保持の条を指すはずの参照が別の条を指したままになる誤りが見られます。完成版で全ての参照を照合します。

OAuthで顧客が外部アカウントを接続するとき：誰が許可し、何を取り、解除したらどうなるか

顧客の担当者が画面の「連携する」ボタンから外部サービスのアカウントを接続すると、外部サービスの許可画面が出て、承諾するとパスワードは渡らずアクセストークンがSaaSに渡ります。規約で決めるのは、接続できる人の権限、許可の範囲と取得する情報の説明、解除したあとのデータの扱いです。

接続する人に、許可を与える権限があるか

接続を実行した担当者が個人のアカウントで許可してしまう、接続した担当者が退職して連携が止まる、といったことが起きます。許可を与えたのは担当者個人です。契約では、接続を実行する者がそのアカウントにつき顧客のために許可を与える権限を持つことを顧客が表明し、権限のない接続で生じた問題は顧客の責任とします。接続の担当者を顧客の側で管理することも義務にします。

許可の範囲（スコープ）と、規約・プライバシーポリシーの記載を合わせる

実務で多いのは、機能を追加するたびに要求する許可の範囲が広がり、規約やプライバシーポリシーの「取得する情報」の記載が追いついていない状態です。許可画面の表示、規約、プライバシーポリシーの三つが同じ範囲を指していないと、取得の根拠の説明が崩れます。個人情報にあたる情報を取得するなら、利用目的をできる限り特定し（個人情報保護法17条1項）、取得したら速やかに本人に通知し又は公表する（同法21条1項）必要があります。予定表に載る参加者の氏名のように他人の情報が入り得る連携は、目的を連携ごとに書き分けます。機能に必要な最小の範囲だけを要求し、範囲を広げるときは顧客の再許可と記載の更新をセットにします。

アクセストークンは、顧客の外部アカウントの鍵

アクセストークンを持つ者は、許可された範囲で顧客の外部アカウントを操作できます。規約には、提供者側の保管の措置、漏えいのおそれを知ったときの顧客への通知、トークンを失効させて再接続する手順を入れます。安全管理の記載が「APIキーの管理」だけのプライバシーポリシーには、組織的・人的・物理的・技術的な措置とアクセス制限、委託先の管理まで書くべきだという指摘がされます。個人データを扱うなら安全管理措置の義務があるからです（同法23条）。

連携を解除したとき、取得済みのデータはどうなるか

解除には、顧客が画面で行う場合と、外部サービスの側で許可を取り消す場合があります。後者では同期の失敗が続くため、顧客への通知も決めます。取得済みのデータは、次の3つの型から選びます。

• 解除と同時に削除。単純ですが、顧客がデータを取り戻す機会がありません。
• 一定期間後に削除。「【　】日以内に削除」と期限で約束します。バックアップに残る期間は別に開示します（解約時のデータ返還・削除のページ）。
• 顧客が選ぶ。解除の画面で削除か保持かを選びます。実装が要り、放置された場合の期限も決めます。

提供者が外部サービスの側に書き込んだデータは、連携を解除しても外部サービスに残ります。解除後は顧客が管理する、と書いておきます。

連携先の利用条件を、顧客にどこまで及ぼすか

外部サービスの開発者向けの利用条件には、取得したデータの保存期間、用途、第三者への提供、表示方法の制限を置くものがあります。顧客が条件に反する使い方（再販など）をすると、提供者が連携を止められるおそれがあるため、顧客が連携の利用に関係する範囲で条件を守ること、守らないときは提供者が連携を停止できることを書きます。

ただし、「外部サービスの利用に起因する法的責任、損害、第三者からの請求等について、一切の責任を負わない」と広く書くと、提供者自身が開発者として負う義務の違反まで顧客に負わせる書き方になり、条項全体の合理性を疑われます。顧客の利用に起因するものと、連携機能の作り方に起因するものを分けます。顧客のIDとパスワードを預かって代わりにログインする方式は別物で、外部サービスの条件が預託を禁じている場合があるため、OAuthが使えるなら使います。

提供者のAPI・Webhookを顧客に使わせるとき：許諾の範囲、上限、廃止、再送の扱い

顧客のシステムからAPIを呼び出させる、Webhookで通知を送るという機能を加えるときは、画面から使うことだけを想定した規約を、機械同士のやり取りに合わせて直します。

「BOT・自動化ツールの禁止」と、API利用が衝突する

機能を自動化ツールやBOT、外部のスクリプトで機械的に、または過剰に利用する行為を禁止するのは、画面から使うSaaSでは標準的です。ところがAPIの利用は、定義上、顧客のプログラムによる機械的なアクセスなので、禁止事項をそのままにすると、API利用そのものが規約違反とも読めます。「当社の意図に反する方法でのAPI利用」という書き方も、意図の中身がなく線が引けません。「提供者が定める仕様に従ってAPIを利用する場合を除く」と例外を置き、禁止する行為は、仕様書の認証方法に従わない利用、利用上限の回避、取得したデータの再提供、競合するサービスの開発のための利用のように具体化します。

許諾の範囲とキーの管理

APIの許諾は、顧客が自社の業務のために使う場合と、顧客が作ったアプリを第三者に提供する場合とでリスクが違います。企業間のデータ連携の仕様書には、受け取ったデータの利用目的を特定し、目的外の利用と相手方の承諾のない第三者提供を禁じ、権利は提供した側に残すとする例があり、SaaSのAPIでも同じ設計がとれます。キーは、発行は提供者、管理は顧客、利用は許可された担当者に限り、第三者への開示・貸与・共有を禁じ、漏えいや不正利用があれば速やかに通知して被害の拡大を防ぐ、と定めます。担当者のメールアドレスとパスワードで認証する例もありますが、退職でAPI連携も止まるので、システム用の認証情報を別に発行できるようにします。

レート制限は、「瞬間」と「累計」を別に書く

利用上限には、一定時間内の回数（例：1分あたり60回）と、期間内の累計（例：月10万回）があります。両方が要る理由は、次の計算で分かります。

1分あたりの上限だけだと、範囲内で続けるだけで外部APIの使用料などの原価が際限なく膨らみます。月間の累計だけだと、1日余りで枠を使い切る集中的なアクセスができ、他の顧客に影響します。超えた要求は拒否する、枠を超えた分は追加料金にする、繰り返せば停止する、のどれにするかも決めます（SaaSの料金条項のページ）。

仕様の変更と廃止：規約に書くか、仕様書に出すか

変更のたびに規約本体を改定するのは重いので、仕様を別紙の仕様書に出し、変更は書面または電子メールなどの合意で足りるとする設計があります（SaaS利用規約・契約書の組み立て方のページ）。提供者が一方的に変更する規約型では、重要な変更は【　】日前、セキュリティ上の緊急の対応は即時、と分けます。規約が定型約款に当たる場合は、変更後の効力発生時期を定めて周知し、その時期が到来するまでに周知しなければ変更は効力を生じません（民法548条の4第2項・3項）。開発者向けの文書を随時書き換えるだけの運用では、この周知を満たしにくい点に注意します。

Webhook：届かない・重複する・順番が変わる、を前提に書く

Webhookは通信の問題や顧客側の停止で届かないことがあり、再送する仕組みでは、同じ通知が複数回届いたり順番が前後したりします。「一度だけ、順序どおり、即時に届ける」と約束すると、仕組み上できないことを約束することになります。

連携先が仕様変更・停止・終了したとき：全面免責、追従、終了、料金調整を組み合わせる

外部サービスは、提供者の意思と関係なく仕様を変え、提供を終えます。規約に「責任を負わない」と書くのは通常ですが、問題はその中身と、どこまで通るかです。

「一切の責任を負わない」の効き目は、連携の位置づけで変わる

損害賠償と料金を分けて考えます。債務不履行による損害賠償は、契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるときは免れます（民法415条1項ただし書）。外部サービスの停止がこれに当たるかは契約の内容と取引の実情で判断され、提供者が依存を開示し、顧客が了承していたかが材料になり得ます。

損害賠償を免れても、料金の問題は残ります。当事者双方の責めに帰することができない事由で債務を履行できなくなったときは、顧客は反対給付（料金の支払）を拒めます（民法536条1項）。連携が使えなくなっても料金は全額、調整もしない、とだけ書く条項は、規約が定型約款に当たる場合、相手方の利益を一方的に害する条項として合意しなかったものとみなされるおそれがあります（民法548条の2第2項）。目安は、連携が付随機能か、その連携が使えなければ契約の目的を果たせない中核の機能かです。連携が売り物なら全面免責だけでは足りず、料金調整を決めたほうが提供者の負担の上限も確定します。

減額の計算例

「外部サービスを原因として主要な連携が連続して【5】日を超えて使えないときは、超えた日数分の日割額の【50】%を翌月の料金から減額する」と定めた場合です。月額30,000円、30日の月に、連携が9日間使えなかったとします。

「5日」と「50%」は、連携が料金の中で占める比重で決める仮の数字です。月の実日数で割るか30日で固定するかも決めておきます（31日の月に実日数で割ると日割額は約968円）。減額を唯一の救済とし、故意又は重大な過失による場合を除いて損害賠償に代えれば、負担の上限が見通せます（SLAのページ）。

上流の停止に挟まれる：再販・協業・OEMの場合

他社のSaaSを再販する、協業する構造では、顧客に対する責任と、上流から得られる補償が食い違います。上流の製品が外部の生成AIやメッセージアプリのAPIに依存し、その仕様変更で主要機能が止まると、顧客には販売する側が責任を問われ得るのに、上流との契約には外部依存の免責も代替措置の義務もない。この構図は、実務上、重大なリスクとして指摘される点です。上流の依存先を聞き取り、顧客との契約に同じ範囲の免責と開示を書き、上流との契約に停止時の通知と対応の義務を入れて、料金調整の範囲をそろえます（SaaSの販売代理店・再販・協業の契約のページ）。外部サイトの公開画面に依拠する機能は、画面の変更で突然止まるので、その旨を開示します。

消費者が混じるときは、書き方が変わる

個人事業者や消費者が申し込めるなら、消費者契約法の規律が及びます。債務不履行による賠償責任の全部を免除する条項は無効で（消費者契約法8条1項1号）、履行に際しての不法行為による賠償責任の全部を免除する条項も無効です（同項3号）。「故意又は重大な過失による場合を除き責任を負わない」も、軽い過失の場合の全部免除なので同様です。上限を設けるなら、「当社、その代表者又はその使用する者の故意又は重大な過失による場合を除き」を、上限を定めるその一文の中に書きます（同条3項。SaaS利用規約の責任制限のページ）。

連携で出入りするデータとプライバシーポリシー：「保存しない」で済ませない

連携で入る情報も外部へ出る情報も、プライバシーポリシーに具体的に書きます。顧客の個人データを、提供者が顧客の委託を受けて取り扱うなら、顧客から提供者への提供は第三者提供に当たらず（個人情報保護法27条5項1号）、顧客は提供者を監督する義務を負います（同法25条）。提供者がさらに外部サービスへ送るなら再委託の整理が要り、送り先が外国にある第三者なら28条の整理が要ります（SaaS事業者は個人情報の委託先かのページ）。漏えい等では、委託を受けた事業者は、規則の定めにより委託元へ通知すれば委員会への報告をしなくてよいとされています（同法26条1項ただし書）。委託元が報告と本人への通知をするには提供者の通知が早くなければ間に合わないので、規約に接続情報の漏えいを含む事故の通知の期限を書きます。

連携ごとに取得する項目、利用目的、解除の方法を書き、外部へ送る先は別紙に一覧にすると、連携を追加するたびに本文を改訂せずに済みます。取得項目や利用目的が増えるときは、連携の公開より前に改訂と周知を済ませます（クラウドサービス利用規約の顧客データ条項のページ）。

ヒヤリングで確認すること：連携の条を書く前に聞くこと

起きがちなこと

よくあるご質問

あわせて読みたいページ

本ページは一般的な情報提供です。個別の取引への当てはめは、サービスの仕組みや契約の経緯によって異なることがあります。書き方の例として紹介している内容は、一般に見られる書き方を整理した例で、特定の事業者や案件を示すものではありません。条文は e-Gov法令検索（法令API）で確認しています（最終確認日：2026年10月22日）。参考: e-Gov法令検索 / 個人情報保護委員会 / 経済産業省 / 国税庁