Zenn
📌

7桁で住所が分かる時代に！？デジタルアドレスの可能性と限界

に公開
1件
OpenAPI
デジタルアドレス
tech

3秒まとめ

  • デジタルアドレスは日本郵便が提供する7桁のランダムな英数字で住所にマッピングする仕組み
  • 個人・法人利用ではデジタルアドレスと住所保持した場合、どちらが本当の住所なのかを明確にして保管する必要がある。
  • API利用は簡単だが、普及には多くのセキュリティの課題やユースケース上の問題があるので広く取り入れられることは難しそう。

どんな人向けの記事？

  • デジタルアドレスって何？と思っている方
  • 日本郵便のAPIを使ってみたい開発者の方
  • 住所管理の新しい仕組みに興味がある方

はじめに

最近、住所もデジタル化の波が来てるんですね！日本郵便が提供する「デジタルアドレス」って聞いたことありますか？物理的な住所に代わる新しい識別子として注目されているんです。

この記事では、日本郵便が提供する「郵便番号・デジタルアドレスfor Biz API」を実際に触ってみて、デジタルアドレスの概要、APIの使い方、そして正直なところの利便性と課題について、私なりにまとめてみました！

1. デジタルアドレスって何？

デジタルアドレスとは一体何でしょうか？めちゃくちゃシンプルに言うと、ゆうID利用者が登録した住所を置き換えた、ランダムな英数字7桁の文字列なんです！例えば A7E2FK2 みたいな感じですね。

これって、既存の住所システムと比較すると、大口事業所個別番号の空間を拡張したものとして理解するのが良さそうです。つまり、今まであった仕組みをベースに、もっと多くの住所に対応できるように名前空間を広げたって感じですね。

7桁の英数字ということは、 アドレス空間は2^35（約340億通り） もあるので、十分すぎるほどの容量があります！分かりづらい文字（0とOなど）は除外されている可能性もありますが、それでも相当な数のアドレスを生成できそうです。

デジタルアドレスの特徴

デジタルアドレスには、以下の特徴があります。

  • 個人・法人がデジタルアドレスの発行が可能：住所からデジタルアドレスの作成ができます。
  • 正引きが可能：デジタルアドレスから住所の取得ができます。
  • API経由でアクセス可能：API登録すればデジタルアドレスから住所を取得できます
  • ユーザーが管理可能：デジタルアドレスの関連付けを作成したユーザーが、削除や変更をできます
  • 匿名性の解決はしていない：デジタルアドレスから住所を簡単に求められるので、フリマなどで広まりつつある匿名配送のユースケースには使えません。

ただし、この「API経由で住所検索が可能」という特性は、後で説明する運用管理とセキュリティや使い勝手が悪くなる理由になり、重要なポイントになってきます。

2. APIを使ってみよう！

デジタルアドレスの情報は、「郵便番号・デジタルアドレス for Biz API」を通じて取得できます。このAPIは、デジタルアドレスの名前解決だけではなくて7桁の郵便番号の解決もしてくれるのでめちゃくちゃ便利です！
なぜなら、郵便番号から住所の補完を行う際は、このAPIを使っておけば郵便番号からの住所の補完だけでなく、デジタルアドレスからの住所の補完が行えます！

提供される機能には、トークン発行や、デジタルアドレス、郵便番号、事業所個別郵便番号の検索などがあります。APIの仕様はOpenAPI Specificationで書かれているので開発者にとっては馴染みやすいと思います。

API利用開始までのステップ

APIを使い始めるまでの手順はけっこうシンプルです。

  1. ゆうIDで認証：まず有効なゆうIDが必要です
  2. 利用者登録：ゆうIDの会員登録後、本サイト上でゆうID認証を行い、利用者登録をします
  3. API認証キーの発行：利用者登録が完了し、本サービスの利用が承認されると、ダッシュボードからAPI認証キー（クライアントID、シークレットキー）を発行できます

API認証キーは、ダッシュボードでサクッと発行・再発行できます。このキーをリクエストに含めることで、サービスを利用できるようになります！

提供される主なAPI

「郵便番号・デジタルアドレスfor Biz API」で提供される主なAPIは以下の通りです。

  • searchcode API: 郵便番号、事業所個別郵便番号、デジタルアドレスからの共通検索を行うエンドポイントです。いずれかのコードを指定して検索すると、住所情報が返されます。テスト用APIでは、テスト用のデジタルアドレス3種と東京都千代田区の郵便番号、事業所個別郵便番号の検索が可能です。
  • addresszip API: 住所の一部を用いて郵便番号や住所情報を検索するAPIです。テスト用APIでは東京都千代田区に対してのみ検索が可能です。
  • token API: API利用に必要なトークン（JWT形式）を取得するAPIです。OAuth2.0のclient_credentialsに基づいており、クライアントIDとシークレットキーを指定してリクエストします。

API利用においては、利用範囲・仕様、アクセス回数、アクセス時間、情報更新頻度、送信データ容量などに制約が設けられる場合があります。ダッシュボードに掲載される最新の利用ガイドを参照することが推奨されています。

APIの仕様に関する注意点

実際にAPIを使ってみて気づいた点がいくつかあります：

  • 送信元IPアドレスの登録: API利用時に送信元IPアドレスの入力が必須になっていますが、実際にはそのIPアドレス以外からでもアクセス可能でした。システム上での制約は特にないようです
  • IPv4のみ対応: 送信元IPアドレスはIPv4のみ指定可能で、ネットワークアドレスの指定やIPv6には対応していません
  • x-forwarded-forヘッダー: APIドキュメントでは必須とされていますが、実際には指定しなくても正常にレスポンスが返ってきます
  • 本番APIのホスト名: この記事ではテスト用API（stub-qz73x.da.pf.japanpost.jp）を使用していますが、本番環境のAPIホスト名はOpenAPIの仕様書に記載されています。(エンドポイントURLを展開すると見られる)

これらの点は、実際の運用時に知っておくと便利だと思います！

API呼び出し例とレスポンス

APIを利用する際には、まずtoken APIでトークンを取得し、そのトークンをAuthorizationヘッダーに含めて他のAPIを呼び出します。

API利用トークン取得例

テスト用API認証情報として提供されているクライアントID Biz_DaPfJapanpost_MockAPI_j3QKS とシークレットキー uXuN0ejHG7nAn89Afxxxxx を使用してトークンを取得するcurlコマンドの例です。

curl -X POST "https://stub-qz73x.da.pf.japanpost.jp/api/v1/j/token" \
-H "Content-Type: application/json" \
-H "x-forwarded-for: 192.0.2.0" \ # 送信元IPアドレスは必須
-d '{
  "grant_type": "client_credentials",
  "client_id": "Biz_DaPfJapanpost_MockAPI_xxxxx", # テスト用クライアントID
  "secret_key": "uXuN0ejHG7nAn89Afxxxxx" # テスト用シークレットキー
}'

成功すると、JWT形式のアクセストークンを含むレスポンスが返されます。このトークンを Bearer スキームで使用します。

{
  "scope": "J1",
  "token_type": "Bearer",
  "expires_in": 123456,
  "token": "{アクセストークン}" # ここに実際のトークンが入る
}

searchcode APIでの検索例

取得したトークンを使用してsearchcode APIを呼び出します。

デジタルアドレスにハイフンが含まれている場合（誤った形式）

テスト用デジタルアドレス A7E-2FK2 をハイフン付きで検索した場合の例です。

curl -X GET "https://stub-qz73x.da.pf.japanpost.jp/api/v1/searchcode/A7E-2FK2" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." # 取得したトークンを指定

この場合、エラーが返されます。

{"request_id":"e6219453-ce21-45df-8369-8c9bf5411111","error_code":"400-1029-0002","message":"デジアドの形式が正しくありません"}

メッセージは「デジアドの形式が正しくありません」となっており、ハイフンは不要であることがわかります。

デジタルアドレスにハイフンがない場合（正しい形式）

テスト用デジタルアドレス A7E2FK2 をハイフンなしで検索した場合の例です。

curl -X GET "https://stub-qz73x.da.pf.japanpost.jp/api/v1/searchcode/A7E2FK2" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." # 取得したトークンを指定

成功すると、紐づく住所情報を含むレスポンスが返されます。

{
  "page": 1,
  "limit": 1000,
  "count": 1,
  "searchtype": "dgacode",
  "addresses": [
    {
      "dgacode": "A7E2FK2",
      "zip_code": "100-0005",
      "pref_code": "13",
      "pref_name": "東京都",
      "pref_kana": null,
      "pref_roma": null,
      "city_code": "13101",
      "city_name": "千代田区",
      "city_kana": null,
      "city_roma": null,
      "town_name": "丸の内",
      "town_kana": null,
      "town_roma": null,
      "biz_name": null,
      "biz_kana": null,
      "biz_roma": null,
      "block_name": "２丁目７−２",
      "other_name": "部屋番号：サンプル１",
      "address": "東京都千代田区丸の内２丁目７−２部屋番号：サンプル１",
      "longitude": null,
      "latitude": null
    }
  ]
}

このレスポンスから、テスト用デジタルアドレス A7E2FK2 は、東京都千代田区丸の内２丁目７−２部屋番号：サンプル１に紐づいていることがわかります。

該当するデジタルアドレスが存在しない場合

存在しないデジタルアドレスで検索した場合の例です。

curl -X GET "https://stub-qz73x.da.pf.japanpost.jp/api/v1/searchcode/XXXXXXX" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." # 取得したトークンを指定

この場合、404 Not Foundエラーが返されます。

{"request_id":"105f833a-4982-47b9-9f61-a564dcf5d846","error_code":"404-1029-0001","message":"該当するデジアドがありませんでした"}

メッセージは「該当するデジアドがありませんでした」となっています。

addresszip APIでの検索例

addresszip APIはPOSTメソッドでリクエストボディに検索条件を指定します。テスト用APIでは東京都千代田区に対してのみ検索可能です。

curl -X POST "https://stub-qz73x.da.pf.japanpost.jp/api/v1/addresszip" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." \ # 取得したトークンを指定
-d '{
  "pref_code": "13", # 都道府県コードを指定
  "city_code": "13101", # 市区町村コードを指定
  "page": 1,
  "limit": 1000 # 取得最大レコード数。デフォルト1000
}'

成功すると、指定した条件にマッチする住所情報や郵便番号を含むレスポンスが返されます。レスポンスにはマッチングレベルも含まれます。

{
  "addresses": [
    ... # 該当する住所情報がリストで含まれる
  ],
  "level": 2, # マッチングレベル
  "limit": 1000,
  "count": 1,
  "page": 1
}

この例では、都道府県コードと市区町村コードで検索しているため、マッチングレベルは2（市区町村レベルで一致）となることが想定されます。

3. 正直なところ、どうなの？（考察）

デジタルアドレスって物理的な住所の代替として期待されてるんですが、実際に調べてみると利便性と課題の両面が見えてきました。

セキュリティ面での気になるポイント

一番気になったのは、匿名性の課題ですね。デジタルアドレスと住所の紐づけ自体は公開されていませんが、API登録すれば誰でもデジタルアドレスから住所を検索できるんです。

つまり、第三者に匿名性を確保したいからデジタルアドレスを教えても、実際には住所を教えたのと同じことになってしまいます。

また、デジタルアドレスがランダムな文字列とはいえ、総当たり攻撃（ブルートフォースアタック）に対して脆弱という問題もあります。総当たり攻撃への対策については、現在のところAPIの利用規約でNGとしている程度で、技術的な対策がどの程度講じられているかは、私が調べた範囲では読み取れませんでした。

利用規約では、API認証キーは自己の費用と責任において厳重に管理する必要があると明記されており、管理不備や不正使用による損害はユーザーが一切の責任を負うとしています。また、APIで取得した情報は、デジタルアドレスを作成したユーザーの同意なしに外部へ公開してはならないという重要な注意点もあります。

実際のユースケースってどうなの？

個人レベルではECサイトで買い物する際に住所補完に使える可能性がありますね。例えば、Webサイトの入力フォームでデジタルアドレスを入力すると、パパっと住所が入力されるような機能です。

でも、これが普及するためには、どれくらいのサイトが対応してくれるか、そしてブラウザ自体がデジタルアドレスの補完に対応するかが疑問なんですよね。もし単なる住所補完のユースケースだけであれば、ブラウザの機能である程度は要求を満たせてしまうかもしれません。

法人（企業）がデジタルアドレスを利用する場合、物理住所とデジタルアドレスの両方を管理する必要が生じて、めちゃくちゃ大変になる可能性があります。

また、デジタルアドレスは作成したユーザーが削除や変更をできるので、もしデジタルアドレスだけをIDとして持っていると、ユーザーがデジタルアドレスを削除した場合に困ることになります。そのため、住所のIDとしてデジタルアドレスのみを使用するのは難しそうです。

これらの点から、正直なところ、デジタルアドレスを普及させることによるメリットがあまり多くないと感じる人もいるかもしれません。一方で、法人のユースケースにおいては、正引き機能があることはなかなか良い点だと思います！

利用規約から見る重要な注意点

「郵便番号・デジタルアドレスfor Biz利用規約」には、API利用者（ユーザー）が遵守すべき重要な事項が多数記載されています。特に注意すべき点をいくつか挙げます。

  • エンドユーザーから取得したデジタルアドレス等の情報管理責任：ユーザーは、エンドユーザーから取得・収集したデジタルアドレス及び登録住所に関する情報を自己の費用と責任において厳重に管理する責任を負います。管理不備、使用上の過誤、第三者の不正使用等による損害は全てユーザーの責任となります。
  • 同意なき第三者への開示・提供の禁止：エンドユーザーから取得したデジタルアドレス等について、デジタルアドレスにより特定される本人の同意のない限り、ユーザーアプリケーションの利用に必要な範囲を超えて、第三者への開示、貸与、売買等を行うことはできません。APIで取得した情報をデジタルアドレスを作成したユーザーの同意なしに外部へ公開してはならない、という点は特に重要です。
  • API認証キーの厳重管理：API認証キー（クライアントID及びシークレットキー）は、自己の費用と責任において厳重に管理する必要があり、管理不備や第三者の不正使用等による損害はユーザーが一切の責任を負います。業務委託関係のない第三者への開示、譲渡、使用させることは禁止されています。
  • 当社による無保証と責任の限定：当社（日本郵便株式会社）は、本サービスの提供に関していかなる種類の保証も行いません。サービスの継続性、タイムリーな提供、エラーの有無、情報の有益性・正確性・信頼性、特定の目的への適合性などについて一切保証していません。また、ユーザーによる本サービスの利用に起因する損害、通信障害やシステム障害による不具合や損害、コンピューター・ウイルスなどによる損害、サービスの遅延・変更・中断・中止・廃止などに関し、一切の責任を負わないと明記されています。
  • 禁止事項：利用規約には、APIのリバースエンジニアリング、許可なきスクレイピングやクローリング、サービスへの過剰な負荷、競合または競合するおそれのあるサービスの提供など、多数の禁止事項が定められています。これらの禁止事項に違反した場合、サービスの利用停止や利用許諾の取り消しが行われる可能性があり、それによりユーザーに生じた不利益や損害について当社は一切責任を負いません。
  • 個人情報の取扱い：本サービスで取り扱う個人情報（登録情報やエンドユーザーの個人情報）は、プライバシーポリシー等及び本規約に従って取り扱われます。リクエストされたデジタルアドレスに対応する登録住所の提供は、当社において本人の同意に基づく個人データの第三者提供として行われ、ユーザーが提供された登録住所を個人データとして取得する場合には、個人情報保護法に基づき適切な管理措置を講じる責任があります。

これらの利用規約の内容は、APIを利用してサービスを開発・提供するユーザーにとって非常に重要です。

まとめ

この記事では、日本郵便が提供するデジタルアドレスについて、実際にAPIを触りながら調べてみました！

デジタルアドレスは7桁のランダムな英数字文字列で住所を置き換える仕組みで、大口事業所個別番号の空間を拡張したと考えると簡単に理解できます。

ただし、利用規約にはけっこう厳しい管理責任や個人情報保護、禁止事項などが詳細に定められているので、利用者はこれらをしっかり守る必要があります。

正直なところの課題として、以下のような点が気になりました：

  • 総当たり攻撃への脆弱性や情報漏洩リスク
  • 普及には多くのサイト対応とブラウザ対応が必要
  • 法人では物理住所との二重管理が負担になる可能性

デジタルアドレスが今後どのように活用され、普及していくのか、そのメリットが明確になって、利便性とセキュリティのバランスが取れるかが鍵になりそうですね！

おまけ

デジタルアドレスについて調べてみて、新しい技術の導入って本当に難しいなと改めて思いました。技術的には面白いアプローチだと思うんですが、実際の普及を考えるとエコシステム全体での対応が必要になってくるんですよね。

実は、私が運営しているポストくん で、デジタルアドレスの付随機能を提供しようと思って検討してみたんです。でも、利用規約を詳しく読んでみると、便利なサービスを提供するのは無理そうでした。単純に、APIの問い合わせに対してデジタルアドレスの正引きをproxyするような感じにすればすでにポストくんを利用してくれているユーザにはシームレスにサービス提供をできそうな気はします。

Discussion

dog_cat_foxdog_cat_fox

匿名性に関しては課題というよりも、そのように作られたもの感がある。
荷物の送り状に住所書いたら住所がバレた、みたいなことは流石に想定してなさそう。