※QRコードは株式会社 デンソー ウェーブ の登録商標です
前回の記事では、Re:Linkの匿名チャットシステムでWebSocketを採用した理由について紹介しました。
しかし、ペット支援システムを作る上で最初に考えたのは、通信方式ではありません。
「発見者が、どうやって支援ネットワークへたどり着くのか。」
この”入口”こそが、最も重要な設計ポイントでした。
QRコードの選択
Re:Linkを開発するにあたり、まず考えたのは「迷子札に何を持たせるべきか」でした。
第一の要件は、迷子のペットを見つけられること。
そして、もう一つ重要視したのは、地域全体で支援の輪を広げられる仕組みであることです。
迷子のペットを見つけることだけを考えれば、GPSトラッカーやAirTagのような位置情報を活用する仕組みが有力な選択肢になります。
実際に、これらのデバイスも検討しました。
しかし、検討を進める中で、いくつかの課題が見えてきました。
- デバイス自体にある程度の大きさ・重量があること
- 定期的な充電や電池交換が必要になること
- 正確な位置情報の確認には専用アプリや対応端末が必要になること
もちろん、GPSやAirTagは「現在地を把握する」という点では非常に優れた仕組みです。
一方で、Re:Linkが目指したのは「位置を知ること」だけではありません。「ペットを見つけた人が、その場で迷わず飼い主へ連絡できること」
そして、その先にある地域や第三者による支援へとつなげられることを重視しました。
その考えから、私たちは「位置情報を取得するデバイス」ではなく、「人と人をつなぐ入口」としてQRコードを採用することにしました。
QRコード中身は「APIへの入口」
Re:LinkのQRコードには、ペットの情報や飼い主の情報は保存されていません。
保存されているのは、APIのエンドポイントとなるURLだけです。
例えば、次のようなURLです。
https://xxx.jp/?r=nnnnnn の部分が識別子になります。
この識別子は、単純な連番ではなく、独自のアルゴリズムによって生成しています。そのため、第三者が推測や総当たりで有効なURLを作成することは非常に困難なものになっています。
サーバー側で識別子を検証
QRコードが読み取られると、サーバーではまず識別子の妥当性を検証します。
- 識別子が生成ルールに従っているか
- 実際に登録されている迷子札か
- 利用可能な状態か
これらの条件を満たした場合のみ、処理を続行します。
チャットルームの生成
識別子の検証が完了すると、サーバーはその識別子に紐付く情報を取得します。
- ペット情報
- ペット画像
- 飼い主情報（内部管理）
- チャットルーム情報
チャットルームが存在しない場合は、このタイミングで新しく生成します。
これにより、QRコードを読み取るだけで、発見者は迷子札に対応したチャットへ直接アクセスできる仕組みになっています。
不正な識別子への対応
識別子が存在しない場合や、不正な形式の識別子が指定された場合でも、サーバーは「存在しない」と明示するような応答は返しません。
また、チャットルームの生成や迷子札情報の取得などの処理は一切行わず、あらかじめ定義した通常の応答を返す設計としています。あたかも、通常通り動いているかのように。
このような実装にすることで、
- 存在する識別子と存在しない識別子を応答内容から判別されにくくする
- 総当たりによる識別子の探索（Enumeration Attack）を困難にする
- 不要なサーバー処理を発生させない
ことを目的としています。
Re:Linkでは、「存在しない識別子だからエラーを返す」のではなく、攻撃者に余計な情報を与えないことを意識して設計しています。
QRコードの複製について
QRコードは画像である以上、複製することは技術的に可能です。
一般的なシステムでは、QRコードの複製はセキュリティ上の問題として扱われることがあります。しかし、Re:Linkでは迷子札というサービスの性質上、この点を前提とした設計を採用しています。
Re:Linkの目的は、できるだけ多くの人が迷子のペットを発見し、飼い主とつながれることです。そのため、QRコードへアクセスできる人は、特定の利用者に限定していません。
QRコードを読み取れる人は、誰でも「発見者」としてチャットへ参加できることを基本方針としています。
つまり、QRコードが複製されたとしても、それ自体が重大なセキュリティリスクになる設計ではありません。
もちろん、QRコードから取得できるのは必要最小限の情報のみであり、飼い主の個人情報や非公開情報が直接取得できることはありません。
Re:Linkでは、「QRコードを守る」のではなく、誰でも安心して支援に参加できることを優先した設計としています。
もちろん、「誰でも発見者として参加できる」という設計には、いたずらや不適切な投稿といった課題もあります。
Re:Linkでは、こうしたリスクを認識したうえで、サービス全体の設計を行っています。
その詳細については、別の記事で紹介するAIを活用した投稿監視・モデレーション機能で解説したいと思います。
まとめ
Re:Linkでは、QRコードを「迷子札に情報を保存する仕組み」ではなく、「支援ネットワークへ接続するための入口」として設計しました。
QRコードには識別子だけを持たせ、実際のデータ管理やチャットルームの生成はサーバー側で制御しています。また、不正な識別子に対しても情報を与えない応答を返すことで、総当たり攻撃などへの耐性も考慮しています。
さらに、QRコードは複製されることを前提とし、そのこと自体をセキュリティ上の問題と捉えない設計を採用しました。重要なのは「QRコードを守ること」ではなく、「誰でも迷子のペットを見つけた瞬間に、迷わず飼い主へつながれること」だからです。
Re:Linkでは、利便性とセキュリティは相反するものではなく、サービスの目的に合わせてバランスを取りながら設計しています。
「誰でも発見者として参加できる」という設計だからこそ必要になる、不適切な投稿やいたずらへの対策については別の記事で紹介します。AIを活用した投稿監視・モデレーションの仕組みや、その設計思想について詳しく解説していきます。
