日本郵便が「デジタルアドレス」というものを始めたそうです。
いろいろ確認すると、なんと、これに合わせて公式APIがリリースされていました。
どうやら、郵便番号の自動入力も、公式APIに置き換えることが可能になり、同時に、デジタルアドレスの自動入力も可能になるようです。
そこでさっそく、当店の入力フォームに実装してみました。
こちらは現在本番環境で稼働しております。(再生ボタンを押すと動画が再生されます)
この記事では、具体的な実装の方法と、デジタルアドレスを使用する意味、意義、気づいた注意点などを書いていきます。
郵便番号・デジタルアドレスAPIの利用を開始する
まず、公式APIを使用する準備をします。
こちらのサイトの中にある「APIのご利用はこちらから」をクリックして、APIのトップに行きます。
APIのユーザー登録は、「ゆうID」登録→API利用登録 の2段階になっています。
「新規登録」を押すと、中に「ゆうID新規登録」と「ゆうIDでログイン」があります。
「ログイン」を押すと、「ゆうIDでログイン」になります。
登録を開始する際の「ゆうID」は、これまで郵便物の再配達などの折に登録しているものがあれば、それでも結構です。
いずれにしても、ゆうIDのログインが済むと、APIの初期利用登録に進みます。
「組織」を登録→各ユーザーが「組織」に招待・参加という管理方法
「郵便番号・デジタルアドレス for Biz」登録後のトップ画面はこんな感じになっています。
API利用登録時に「組織の登録」を行います。
最初に登録作業を行った「ゆうID」は、
登録完了後は、組織の一参加済みユーザーという扱いになります。
最初に登録作業を行った「ゆうID」も、別の管理者を招待して登録すれば、そちらから削除可能な仕様になっています。
「所有者」といった固定的な役割とはならないため、担当者間の引継ぎなどが必要なケースでも、柔軟に対応可能になっています。
「組織の登録」→法人・個人事業主とも可能
「組織の登録」では、法人も個人事業主も登録可能になっています。
いずれの場合も「コーポレートサイトのURL」が必須となっており、これが事実上の審査の役割を果たしているように思われます。
とはいえ、当店の場合は個人事業主としての利用ですが、登録後、審査完了まで待たされた感じはなく、すぐに利用可能になった印象です。
「デジタルアドレス」の建付けとして、個人と住所が紐づいて出てくるものではないため、個人情報を取り扱うような厳格なユーザー登録ではなく、あくまでもAPI利用者としての登録、という意味合いが強いようです。
とはいえ、登録後に表示される「利用ガイドライン」においては
不正利用を回避するため、特定の利用者に対して、事前の予告なくゆうIDの強制退会措置の実施、又は本サービスの提供を停止することがあります。
とありますので、総当たり的なリクエストの送信や、シークレットキーの公開・流用など、おかしな使い方をしたユーザーはBANされると思われます。
「システムリスト」に実装環境を登録する
APIの利用開始ができたら、「システムリスト」に実装環境を登録します。
(下のスクショではすでに登録されている状態です)
「システム名」「URL」「利用システムの固定IPアドレス」を設定します。
・システム名
自分であとから区別できる任意の名前でよい
・URL
直接リクエストを送出するURLの意味ではなく、ウェブサイトのアドレス程度のものでよい(サポート確認済み)
・固定IPアドレス
ここで登録したIPアドレス以外からのリクエストははじかれるため、厳密に設定する必要がある。複数設定はできるが、例えば不特定のWebクライアントから直接リクエストしたりは認められない仕様
またipv6アドレスは不可で、ipv4アドレスである必要がある
クライアントシークレットは必ず控えをとってください
登録完了後に、クライアントシークレットが一度だけ画面に表示されますので、必ず控えをとってください。
クライアントIDは、あとからいつでも見ることができます。
※もし控えを取り忘れたら、システムを削除して再度登録する必要があります
APIリクエストと自動入力をコーディングする
ここまでできたら、あとはコーディングして実装するだけです。
当店の場合は、APIリファレンスをダウンロードしてGemini Proに読み込ませ、Canvasでコーディングを行いました。
Geminiが長足の進歩を遂げており、すさまじいスピードと精度でコーディングしてくれましたが、書かれたコードがまるっきり分からない状態では、これだけではやはり実装は完了できませんので、ある程度知識が必要です。
いくつか補足のプロンプトを与えたり、意図と異なる動作をする部分のコードを手直ししたりはしています。実物のシークレットキーを入れたり、仕様書に書かれていないヘッダを追加したりする作業も行っています。
一応、基本になるコードをサンプル形式にしたものをGitHubに上げています。
※クライアントID、シークレットをご自身で発行し、環境変数に読み込ませてください。
※このコードは一時的なテスト用やサンプルとしての利用にとどめ、このまま本番では利用しないことをおすすめします。当店で実際に稼働しているコードは、外部からの不正なリクエストを防ぐため複数の対策を追加しています。
それで、最終的にいま動作しているようすが、冒頭でご紹介した動画です。
デジタルアドレスは、結局なんの役に立つのか。あぶなくないのか。
それで、実装してはみましたが、まだ実際に使っている方はほとんどいないと思われ、実際はほぼ、日本郵便の純正APIで置き換えた郵便番号からの自動入力システムとして機能している状態ではあります。
はたして、デジタルアドレス、普及するんでしようか?
どんな意味・意義があるんでしょうか?
住所が正確に入力できる
番地表記・建物表記まで自動入力できるため、入力のぶれがなくなります。住所が正確に入力できます。
例えば、会社の名刺を作る際に、デジタルアドレスを併記すれば、文字数の多い住所でも簡単に入力して利用してもらえるという利点はあると思います。
(前提として、デジタルアドレスが使える場面が増える必要がありますが)
デジタルアドレスは変わらないまま、対応する住所だけ変えられる
デジタルアドレスは「ゆうID」と紐づいており、「ゆうID」の登録住所を変えれば、デジタルアドレスで入力される住所も変わります。
引っ越した場合でも、入力するデジタルアドレスは引っ越し前と同じで、自動入力される住所は新居になります。
メリットとしては
通販サイトにデジタルアドレスを登録すると、以後の住所変更手続きが不要になるかもしれない、という点はあるようです。
デメリットとしては
デジタルアドレスそのものを他人に教えると、教えられた人は、引っ越し先の住所まで追跡可能になります。
このため、個人の自宅を登録したデジタルアドレスは、基本的には他人に教えることなく、自分だけが知っていて自動入力に使用する、という使い方がおすすめです。
引っ越し先を知られたくない相手に、デジタルアドレスを知られてしまっている場合は
「デジタルアドレスの削除」という操作で、知られないようにすることができます。
事業者によるデジタルアドレスの取得・保存は厳格な管理が求められる
デジタルアドレスの入力を受けた事業者が、そのデータを取り扱うについては、API利用規約にこのように定められています。
小さくて見づらい場合は、二本指でひろげる操作で拡大できます。
事業者がデジタルアドレスを保存すること自体を禁止するのではなく、取得したデジタルアドレスの管理と、漏洩時の対応が規定されているにとどまります。
このため、デジタルアドレスそのものは氏名などと紐づいているわけではないといっても、取得した事業者からデジタルアドレスが漏洩した場合には、氏名等のデータと紐づけ可能な、「個人情報」として漏洩する可能性がある、ということになるわけです。
その場合には、将来の住所をも含めた漏洩となってしまうわけであり、管理する事業者の責任はより重大だといえるでしょう。
このため、当店のWebフォームでは、入力されたデジタルアドレスを保存することはなく、自動入力された住所だけを、個人情報の利用許諾が得られた範囲内で保存するにとどめています。
APIの実装も結構気を使いました
今回、AIの力を借りて結構はやくにコードが書けたので、さっさと実装して稼動していたのですが、
いろいろと考えていくうちに、このままじゃだめだな、と思い、不正なリクエストの対策をいろいろと実施することとなりました。
ただの郵便番号照会だったらここまで気は使いません
もしこれが、ただ郵便番号の照会をするAPIだったら、ここまで気を使わないと思うのです。
誰でも入手できる公開の一覧表に従って、結果を自動入力するだけなので。
仮に、当店の作った自動入力フォームや、自前のWebAPIエンドポイントを、外部から利用されたとしても、ちょっとトラフィックが増えて負荷がかかるだけです。
べつに、うちじゃなくても、世の中にいっぱいありますので、うちのサーバーを落とそうとしてやるのでないかぎり、そんなに大きな問題にはなりません。
デジタルアドレス照会はいろいろとやっぱり特別です
ところが、デジタルアドレスの照会ができるとなると、いろいろな要素を考えないといけません。
・氏名+デジタルアドレスを入手した者が、住所を入手するためにアクセスしてくる
・うちのWebAPIを勝手に呼び出して自動入力するサイトが現れる
・デジタルアドレスの一覧データを作成しようとして、総当たりのアクセスをする者がでる
しかも、こうした者たちに利用された場合、日本郵便側からすれば、当店のシークレットキーでアクセスしているわけですから、当店が大量の照会リクエストを送り付けたことになってしまいます。
度を超せば、アカウント停止の要因にもなりかねません。
このため、さきほどサンプルとしてご提供したコードのあと、AIや手作業でいろいろやって、ガードを固めることにしました。
何をやったかここに書かなくても、分かる人にはある程度分かっちゃうと思いますし、バレてもガードできるようには書いたつもりなんですけど、やっぱり詳しくは書かないことにします。
特にWebAPIは、悪意ある攻撃者に発見されると、とんでもない数のリクエストが飛んでくるので、日本郵便さんとしても、何らかの、不正なリクエストを防ぐための指針なり、サンプルは示していただいてもいいのかなと思ってます。
コメント