利用者モデルとAPI利用形態
要約: この文書では、利用規約やプライバシーポリシーに記載の概念と、ケンオールのAPIの仕組みの関係性、また、API利用形態と遵守事項がどのように関連するのかを説明します。
ケンオールの概要 で見たとおり、ケンオールは郵便番号・法人番号・銀行・祝日といった公開データを、常に最新の状態でREST APIとして提供するサービスです。そこから、お客様のサービスの部品として組み込まれて、はじめて価値が出ます。単独で完結するサービスではありません。
ケンオールは部品として組み込まれるこの見出しへのリンク
住所入力フォームの自動補完も、法人名の検索も、営業日の計算も、エンドユーザーから見ればお客様のサービスの機能です。その裏でケンオールが呼ばれていることを、エンドユーザーから意識することは基本的にありません。
この「部品として組み込まれる」という前提から、ケンオールを使う上で押さえておきたい性質が3つ導かれます。
- 利用者が二段になります。 ケンオールと契約してAPIキーを持つお客様と、お客様のサービスの利用者は、内製システムなどの場合を除いて、別の存在です。規約もプライバシーポリシーも、この二段を区別して書かれています。
- APIキーの置き場所が設計事項になります。 部品はブラウザの中にも、自社サーバーの中にも置けます。どちらに置くかでキーが誰の目に触れるかが変わるため、ケンオールはAPIキーを2種類に分け、種類ごとに守り方を変えています。
- 責務も二段になります。 ケンオールと契約関係にあるのは、APIキーを持つ側だけです。その先の利用者に関わる部分は、契約している側が引き受けることになります。
以下では、まずこの二段の利用者を規約の言葉で整理し、次にAPIキーの2種類と2つの構成 (a) (b) を見たうえで、最後にそこから生じる責務と、間接的利用者への通知義務を扱います。
登場する三者この見出しへのリンク
ケンオールの利用規約とプライバシーポリシーでは、サービスに関わる主体を次のように呼び分けています。
- 当社: ケンオール株式会社。APIを提供します。
- 直接的利用者: 当社と契約し、直接的に本サービスを利用する、あるいは利用する予定のある者。主体に個人・法人の両方を含みます。APIキーを発行され、料金を負担するのはこの直接的利用者です。
- 間接的利用者: 直接的利用者が本サービスを用いて提供する情報サービスの利用者。主体に法人は含みません。たとえば、直接的利用者のECサイトで住所を入力するお客様がこれにあたります。
直接的利用者と間接的利用者の両者を指してサービス利用者といいます。定義の原文は 利用規約 第3条・利用規約 第4条、および プライバシーポリシー を参照してください。
三者の関係。当社が契約しAPIキーを発行する相手は直接的利用者のみで、サービスの提供は破線の経路で間接的利用者にも及ぶ。
間接的利用者にはケンオールとの直接契約はありませんし、ケンオールのアカウントもありません。それでも間接的利用者のブラウザからAPIが呼ばれることがあるのは、直接的利用者が自社の情報サービスの構成要素としてケンオールを組み込み、その機能の利用を間接的利用者に許諾しているためです (利用規約 第3条第2項)。図1 の破線は、この関係を通じて当社のサービスが間接的利用者にも及ぶことを表しています。
APIをどこから呼ぶかによって、この関係の現れ方は変わります。本文では ブラウザから直接呼び出す構成 と 中継サーバーを挟む構成 の2つに分けて説明します。
二種類のAPIキーこの見出しへのリンク
APIキーには公開キーとシークレットキーの2種類があります。これらの違いは端的に言えば どこに置かれ、誰の目に触れるか です。
| キーの種類 | 置き場所 | 誰の目に触れるか | 保護の仕組み | 主な用途 |
|---|---|---|---|---|
| 公開キー | 間接的利用者のブラウザ (フロントエンドのJavaScript) | 間接的利用者に見えて差し支えありません | ダッシュボードで登録した許可ドメイン (Originヘッダー) による利用元の制限 | 住所入力フォームの自動補完、フロントエンドからの単発検索 |
| シークレットキー | 直接的利用者のサーバー内部 | 直接的利用者の担当者のみ | 値の秘匿そのもの (Origin制限はありません) | バッチ処理、データダウンロード、Webhook・レーダー登録、秘匿が必要な処理 |
用途ごとに複数のキーを発行でき、種類は作成時に選択します。
詳細は APIキー・認証 を参照してください。
(a) ブラウザから直接呼び出す構成この見出しへのリンク
もっとも素直な構成は、直接的利用者が自社サイトやアプリに公開キーを埋め込み、間接的利用者のユーザーエージェント (ブラウザ・アプリ等) からケンオールのAPIサーバーを直接呼び出すものです。
ブラウザから直接呼び出す構成。公開キーは②で間接的利用者のユーザーエージェントに渡り、③のAPIリクエストに付与される。
- 間接的利用者のユーザーエージェントが、直接的利用者のWebサーバーにリクエストします。
- 直接的利用者のWebサーバーは、公開キーを含んだページやスクリプトを返します。この時点で、公開キーは間接的利用者の手元に渡ります。
- ユーザーエージェントが、その公開キーを
Authorization: Token ...ヘッダーに付けて、ケンオールのAPIサーバーを直接呼び出します。 - ケンオールのAPIサーバーが、ユーザーエージェントへ直接レスポンスを返します。
住所入力フォームの自動補完のように、入力のたびに低遅延で応答したい用途に向いた構成です。この構成では、間接的利用者がケンオールの機能を直接利用することになる点に注意してください (→ 直接的利用者の責務)。
なぜ公開キーは知られてもいいのかこの見出しへのリンク
図2 の②のとおり、公開キーは間接的利用者の環境 (ブラウザ) で動くコードに埋め込まれて配布されます。ブラウザに配られた値は、開発者ツールを開けば誰でも読めます。つまり公開キーについては値の秘匿が原理的に成立しません。
そこでケンオールは、公開キーを「秘密であること」ではなく「利用元が限られていること」で守ります。ダッシュボードで許可ドメインを登録すると、Originヘッダーが一致しないリクエストは拒否されるため、第三者が値を知っても自分のサイトからは使えません。値が間接的利用者に見えても差し支えないのはこのためです。
一方、シークレットキーにはOrigin制限がありません。値を知っている誰でも、どこからでも使えてしまいますので、取扱いには十分注意してください。
許可ドメインは通常のプランでは完全一致です (サブドメインのワイルドカードは有償オプション)。公開キーをブラウザに置く場合は、許可ドメインの登録を必ず行ってください。未登録のまま配布すると、どのサイトからでも使えるキーになります。
万一シークレットキーが漏洩した、あるいはその疑いがある場合は、ただちにダッシュボードから該当キーを失効させ、新しいキーを発行してください (→ APIキーが漏洩したらどうすればいいですか？)。
シークレットキーが必須になるAPIこの見出しへのリンク
以下のAPIは、間接的利用者の環境から呼ばれることを想定していないため、公開キーでは呼び出せず 401 Unauthorized が返ります。
- 住所→郵便番号API のバッチ検索: 複数クエリをまとめて処理する重い操作のため
- 郵便番号データダウンロード: データ本体を取得するため
- 法人番号レーダー / Webhook: サーバー間連携のため
APIリファレンスに特に記載がない場合は、そのAPIを公開キーとシークレットキーの両方で利用できます。
(b) 中継サーバーを挟む構成この見出しへのリンク
もう一つの構成は、直接的利用者が自ら管理する中継サーバー (リバースプロキシやCDN等) を経路に置き、ケンオールのAPIキーはその中継サーバーから外に出さないというものです。ユーザーエージェントは自社ドメインの中継エンドポイントだけを呼び、ケンオールのAPIキーを一切受け取りません。
中継サーバーを挟む構成。ケンオールのAPIキーは④の区間だけで使われ、間接的利用者のユーザーエージェントには渡らない。
- 間接的利用者のユーザーエージェントが、直接的利用者のWebサーバーにリクエストします。
- 直接的利用者のWebサーバーは、ケンオールのAPIキーを含まないページやスクリプトを返します。
- ユーザーエージェントは、ケンオールのAPIキーを伴わないリクエストを、直接的利用者の中継サーバーへ送ります。
- 中継サーバーが、シークレットキーを付けてケンオールのAPIサーバーを呼び出します。
- ケンオールのAPIサーバーが、中継サーバーへレスポンスを返します。
- 中継サーバーが、そのレスポンスをユーザーエージェントへ返します。
この構成では、次の2点が変わります。
- 公開キーの露出が不要になります。 ケンオールAPIを呼ぶのは直接的利用者のサーバーだけなので、シークレットキーだけで完結します。ブラウザにキーを配る必要も、許可ドメイン (Origin) を登録・管理する必要もありません。
- 間接的利用者がケンオールの機能を直接利用する関係ではなくなります。 ユーザーエージェントが呼ぶのは自社の中継エンドポイントだけなので、利用規約 第3条第2項 にいう「機能の利用の許諾」にあたる関係は生じません。
一方で、第3条第3項 の通知義務はこの構成でも生じます。「間接的利用者」は 同条第2項 の定義のとおり「直接的利用者が本サービスを用いて提供する情報サービスの利用者」であり、ケンオールのAPIを直接呼ぶかどうかを問いません。中継サーバーを挟んでも自社サービスの利用者が間接的利用者であることは変わらず、その濫用を抑止しておく必要も変わりません (→ 間接的利用者への通知と濫用の抑止)。むしろこの構成では、規約による抑止に加えて中継サーバー側での技術的な抑止も自社の責任範囲に入ります。
また、中継サーバー自体が自社の責任範囲になります。次の点にご留意ください。
- 誰でも叩けるエンドポイントとして公開すると濫用の入口になります。自社側でのレート制御・認証・入力値の検証は自前で実装する必要があります (→ 直接的利用者の責務)。
- 経路が1段増えるぶん、応答時間と自社サーバーの負荷が増えます。住所入力フォームの補完のように、入力のたびに呼ぶ用途では特に影響が出ます。
どちらの構成を採るかは、キーと許可ドメインの管理を減らしたいか、自社サーバーを経路から外して構成を単純にしたいかのトレードオフです。バッチAPI・データダウンロードAPIのようにシークレットキーが必須のAPIを使う場合は、いずれにせよサーバー側の実装が必要になります。
直接的利用者の責務この見出しへのリンク
ケンオールとの契約関係にあるのは直接的利用者だけです。そのため、ケンオールの利用に伴う責務はすべて直接的利用者が負います。ただし、構成によって負う責務の範囲が変わります。
どちらの構成でも負う責務この見出しへのリンク
- サービス利用資格情報の管理: APIキーを含むサービス利用資格情報は、各直接的利用者に個別に発行されるものであり、本サービスの合理的な利用の範囲を超えて第三者に譲渡・貸与・共用することはできません (利用規約 第5条)。シークレットキーを間接的利用者に渡すこと、また別契約の第三者と共用することはできません。開発を外部に委託する場合も、キーは直接的利用者の管理下に置き、用途ごとに別のキーを発行してください。
- 利用範囲の遵守: APIレスポンスをそのまま第三者へ再配布する用途 (データセット販売など) は 利用規約 第7条 で禁止されています。自社サービスの画面表示に用いることは問題ありません。
- 間接的利用者への通知と濫用の抑止: 間接的利用者に対し、利用規約 第4条 (情報の取扱い) および 第7条 (禁止事項) の内容を遅延なく通知しなければなりません (利用規約 第3条第3項)。構成を問わず生じる義務です。詳しくは 間接的利用者への通知と濫用の抑止 を参照してください。
ブラウザから直接呼び出す構成 (a) でのみ負う責務この見出しへのリンク
この構成では、間接的利用者がケンオールの機能を直接利用することになります (利用規約 第3条第2項)。そのため次が加わります。
- 許可ドメインの設定: ブラウザに配る公開キーには、必ず許可ドメイン (Origin) を登録してください。Origin制限を設定した公開キーを自社サイトに埋め込み、間接的利用者のブラウザから呼ばせること自体は、想定された利用形態です。
中継サーバーを挟む構成 (b) でのみ負う責務この見出しへのリンク
前節のとおり、この構成では許可ドメインの管理は生じません。一方、間接的利用者への通知義務は共通に残り (→ 間接的利用者への通知と濫用の抑止)、加えて中継エンドポイントが自社の責任範囲になります。
- 中継エンドポイントの保護: レート制御・認証・入力値の検証を自前で実装してください。ケンオールへのリクエストは中継サーバーのIPアドレスからまとめて発行されるため、濫用が起きても間接的利用者ごとの切り分けは自社側でしか行えません。
間接的利用者への通知と濫用の抑止この見出しへのリンク
通知の必要がある箇所と、その対象この見出しへのリンク
直接的利用者は、間接的利用者に対し、書面もしくはその他の法的効力のある手段を通じて、利用規約 第4条 (情報の取扱い) および 第7条 (禁止事項) の内容を遅延なく通知するものとされています (利用規約 第3条第3項)。実務上は、自社サービスの利用規約に第7条の禁止事項に相当する条項を取り込み、情報の取扱いを自社のプライバシーポリシーに反映する形になります。これが条文にいう「法的効力のある手段」にあたります。
通知の主旨この見出しへのリンク
この規定の主旨は周知それ自体ではなく、間接的利用者による濫用を直接的利用者の側で抑止できる状態にしておくことにあります。
間接的利用者はケンオールと契約していないため、当社が間接的利用者を直接拘束することはできません。そこで、直接的利用者が自社との契約関係を通じて間接的利用者を拘束します。上記のとおり自社の規約に取り込んでおけば、間接的利用者が禁止事項にあたる行為 (自動化された大量アクセス、取得した情報の再配布など) に及んだ場合に、直接的利用者は自社の規約に基づいて利用停止などの措置を取れます。
濫用が起きたときに措置を取る主体この見出しへのリンク
措置を取りうるのは直接的利用者だけではありません。第7条 の名宛人は直接的利用者であるため、間接的利用者の行為であっても、当社との関係では直接的利用者自身の規約違反として扱われます。つまり、措置は二段構えになります。
- 直接的利用者 → 間接的利用者: 自社の規約に基づく利用停止など。
- 当社 → 直接的利用者: 本規約のいずれかの条項に違反した直接的利用者に対し、事前の通知なく本サービスの利用を制限し、または登録を抹消することがあります (利用規約 第9条第1項)。
第3条第3項 の通知は、この責任を果たすための前提です。通知を怠ったまま間接的利用者に濫用されると、その結果は直接的利用者に及びます。
構成による違いこの見出しへのリンク
通知義務そのものは構成によりません。中継サーバーを挟む構成でも、自社サービスの利用者が間接的利用者であることに変わりはないためです。変わるのは次の2点です。
- 抑止の手立て: (a) ブラウザから直接呼び出す構成 では規約による拘束が事実上唯一の手段ですが、(b) 中継サーバーを挟む構成 では規約に加えてレート制御・認証といった技術的な抑止を併用できます (→ 中継エンドポイントの保護)。
- 第4条 の重み: ブラウザから直接呼び出す構成では、間接的利用者のユーザーエージェントがケンオールへ直接アクセスするため、第4条第2項 の「当社が間接的利用者に対し個人識別符号の提供を求めることがある」場面が実際に生じます。自社のプライバシーポリシーに反映する際は、この点を織り込んでください。
次に読むこの見出しへのリンク
- クイックスタート: APIキーの取得から最初のリクエストまで
- API共通仕様: Token認証・CORS・レート制限
- JavaScript SDK: ブラウザから公開キーで呼び出す
- APIキー・認証 (ヘルプ): キーの発行・編集・失効、許可ドメインの設定
- 利用規約 / プライバシーポリシー: 用語の定義の原文
最終更新: 2026-10-06