APIを外部に公開する場合、サービス本体の利用規約とは別で「API利用規約」を公開して、ユーザーに同意の元で利用してもらうのが一般的です。

API利用規約にどのような情報を載せるかはベンダーによって様々ですが多くのベンダーが共通してAPI利用規約に載せている項目もあるため、本記事では国内の事例をもとにAPI利用規約で明記しておくべき項目の一例を紹介します。

サービスの特質に関わらず言及が望ましい項目

API利用者の禁止項目や不正行為、保証・補償、API利用状況モニタリングなどについての項目はどのベンダーでもほとんど同様のニュアンスで利用規約に明記しています。

以下ではその代表的な例をピックアップして紹介します。

API利用者の禁止項目や不正行為

大きく分類すると、以下のようなパターンに分けられます。

サービスそのもの利用規約でも記載している利用規約と重複する部分も多くありますが、サービス利用規約とAPI利用規約の両方に禁止項目を記載しているベンダーも多いようです。

保証・補償について

多くのAPI利用規約では、API利用者が自らの行為によって発生した問題（第三者からのクレーム、権利侵害、法的トラブルなど）について、API提供者側を免責し、逆にAPI利用者側が補償する（いわゆる「インデムニフィケーション」条項）ことが明記されています。

これは、API利用者が自社の開発したアプリケーションやサービスを通じて発生した損害や紛争について、API提供者が巻き込まれないようにするための規定です。

以下は、そのような補償に関する例示的な記載となります。

当社は、事前に通知することなく、当社のシステムメンテナンス、通信回線の不具合等やむを得ない事情により当社APIサービスの提供を中断または停止することができます。API接続先は、当該中断または停止に関し、当社に対し補償を求めないものとします。

（中略）

API接続先は、本規約等の違反により当社、利用者または第三者に損害が発生した場合、当該損害の全額（弁護士費用を含みます）を補償するものとします。
freee API利用規約

１．リクルートは、本APIまたは本APIによって得られる情報について、誤り、エラー、バグまたは提供の中断が無いことならびに信頼性、正確性、有用性および完全性について一切の保証をしません。

２．利用者は、本APIの利用もしくは参照、またはこれに関連して利用者が開発するアプリケーションに関して生じうるあらゆる損害、責任、およびクレームに関しリクルートを免責することとします。

Air Wait利用規約

当社は当社APIサービスおよび第三者のシステム等にエラー、バグ、不具合、中断その他の瑕疵がないこと、当社APIサービスにコンピューターウィルス等の有害情報が含まれないこと、ならびに当社APIサービスの正確性、信頼性、完全性、適法性、非侵害性、有効性、目的適合性等につき一切の保証をしないものとします。また、当社は、当社APIサービスに関する事象に起因してAPI接続先に生じた一切の損害につき責任を負わないものとします。

（中略）

API接続先は、本規約の違反により当社、利用者または第三者に損害が発生した場合、当該損害の全額（弁護士費用を含みます）を補償するものとします。

SmartHR API利用規約

1. 当社は、Sansan APIを現状有姿で提供するものとし、Sansan APIの内容の追加、変更、又はSansan APIの停止、終了によってお客様に生じたいかなる損害についても、一切の責任を負いません。

2. 当社は、Sansan APIの完全性、正確性、確実性、有用性、適法性、可用性等明示的か黙示的かに関わらず、いかなる種類の保証も行わないものとします。

3. 当社は、Sansan APIへのアクセス過多、その他予期せぬ要因で表示速度の低下や障害等が生じた場合の責任を一切負わないものとします。

4. 当社は、連携アプリケーション又は第三者サービス上（お客様側のサーバー等含む）で発生した情報の漏えい等の責任について一切責任を負わないものとし、当社が、第三者から当該理由を原因として請求された場合、お客様はその一切の費用を当社に補償するものとします。

Sansan API利用規約

APIの仕様変更

多くのAPI提供者は、APIの仕様や機能を事前予告なく変更・廃止する可能性を明示しています。これは、技術的な改良やセキュリティ対策、サービス戦略の変更など様々な理由によるものです。利用者は、これらの変更に対し常に追随できるよう備え、また必要に応じて自社サービスへの影響を最小化するための計画やテストを行うことが求められます。

以下は、API提供者が仕様変更に関する権利を保持し、また利用者に対してその対応責任を明確化している記載例です。

Slack はまだ進化しており、後進的な互換性のない変更を含む API に対し時々変更を行う柔軟性が必要です。当社はこれらの変更を通知することを試みますが、最新情報については、Twitter アカウント（@slackapi）をフォローすること、または当社の 変更履歴 を閲覧することをご検討ください。また、特定のメソッド、イベント、プロパティなどを含め、API の一部は文書化されていません。これらの文書化されていない API の側面はいつでも変更される可能性があるため、これらの動作は信頼すべきではありません。

Slack API サービス利用規約

もちろんAPI仕様を変更する場合は事前通知やバージョニングなどAPI利用者の体験や連携システムへの影響度を最大限考慮すべきですが、やむを得ない事情でAPI仕様を変更するリスクやケースは事前に想定しておくべきでしょう。

※バージョニングに関しては別記事で解説しています。

サービスモニタリングの許諾

API提供者は、APIの利用状況を把握し、サービスの品質確保や不正利用を防ぐため、利用者のAPI呼び出しやデータアクセスの内容をモニタリングする権利を有することを明示する場合があります。このモニタリングには、アクセスログの確認、利用頻度の測定、異常なリクエストの検出などが含まれ、これらは主にサービスの安定性維持やセキュリティ確保のために行われます。

API接続先は、当社が当社APIサービスおよび関連するサービスの信頼性を確保する目的で、API接続先が接続先提供サービスにおいて当該サービスの利用者（以下、接続先提供サービスの利用者を単に「利用者」といいます。）に提供するアプリケーションおよびAPI接続先が制作したウェブサイトを、クロールその他の方法でモニターすることがあること、およびこのようなモニターを妨害しないことに同意します。

当社はAPI接続先のセキュリティ、利用者保護、接続先提供サービスの提供もしくは経営状況が当社の定める基準を満たしていない可能性があるまたは本規約の違反があると客観的かつ合理的な事由により判断する場合、API接続先に対し、報告、資料提出もしくは立入監査を求めまたは当社APIサービスの利用の制限もしくは停止を求めることができるものとします。

SmartHR API利用規約

上記の例のように、モニタリングの結果によってはサービス利用を停止したり報告を求める旨を平気するパターンが多いです。

API提供の終了について

API提供者は、ビジネス上の判断、技術的な理由、法的な要請など、様々な事情からAPIの提供を終了する権限を保持していることが多く明記されています。これは、サービスの方向転換やコスト削減、セキュリティ上の懸念などを背景としたものです。API利用者は、このような終了に対して異議を述べたり、補償を請求したりすることはできない旨が規約に示されることが一般的です。

またAPI提供を終了する場合に、事前通知を行うかどうかについても明記しておく必要があるでしょう。

サービスによって検討が必要な項目

サービス名称・ロゴの利用規定

API利用者が提供者のサービス名やロゴを利用してもよいか、また利用する場合はどのような基準で利用する必要があるかなどの明記が必要な場合があります。

実際に以下のような事例はトラブルに繋がりやすいため、API提供者のブランドガイドラインに基づいてサービス名称やロゴの利用ルールについては利用規約でしっかりと明記しておくのが望ましいでしょう。

• APIを利用しているサービスが「〇〇公式アプリ」と記載してサービスリリースしてしまう

• API提供者のロゴをサービス利用者が意図しない形で編集・改変して公開してブランド毀損してしまう

下記の例のようにAPI提供者を明示することを義務付ける例もあれば、任意で利用可能としつつ利用する場合はガイドライン準拠を義務付けるケースがあります。

１．利用者は、リクルートが別途定める場合には、利用者のアプリケーション上またはアプリケーション内に表示される本サービスの情報が、リクルートより提供されたものである旨を表示することとします。

２．リクルートは、利用者に対し、本規約および別途定めるガイドラインで定める範囲で、リクルートの社名およびサービス名称の標章・ロゴ・画像（以下「クレジット」といいます）の利用を許諾します。

３．利用者は、クレジットの要素（HTMLソースを含みます）の一部または全部を除去、改変、改竄その他外観に対する変更を一切できないこととします。

４．利用者は、クレジットを、リクルートのイメージを汚損したりする態様、アプリケーションの閲覧者に対してリクルートと利用者がなんらかの提携関係にあるかのような印象を与える態様、リクルートと利用者の提供するサービスが同一のサービスであると誤認混同するような態様での利用はできないこととします。

Air Wait利用規約

1　API接続先は、当社APIサービスの使用またはアプリケーションの制作およびこれに関するサービスの提供にあたり、当社所定の方法によってのみ、当社の商標および商号等（類似のものを含みます）を使用することができるものとします。

2　API接続先が前項に従い当社の商標を使用する場合、API接続先は商標使用ガイドラインその他当社の指定する基準に従うものとします。

3　API接続先は、当社が求める場合には、当社が別途定めるところにより、アプリケーションに表示されるサービスが当社によって提供されたものであることを表示するものとします。

freee API利用規約

データの二次利用・再販・再配布

APIで取得したデータの二次利用を許可すべきかどうかについても、サービスの特質に即して利用規約で定義しておく必要があります。大きく分けると、以下のようなパターンが存在します。

• 二次利用はNG

• 二次利用は可能だが、再販・再配布はNG

• 再販・再配布を含めてOK

特にAPI提供者のデータの取得元が外部だった場合、データ取得元のポリシーも踏まえて二次利用のルールを厳密に定める必要があるため注意が必要です

まとめ

国内SaaSの実際の利用規約の記述を参考に、サービスの性質にかかわらず載せておくべき事項、サービスの内容に応じて記述を検討すべき事項をご紹介しました。公開APIは利用するエンドユーザーやベンダー、そのベンダーが提供するサービスの利用者など、関連するステークホルダーが多岐にわたるため、リスク軽減のためにあらかじめAPI用の利用規約を準備しておくことをお勧めします。