一色政彦の技術ノート

AI、開発、データを中心に、試したこと・調べたこと・分かったことをまとめる個人技術ブログです。

Windowsの「~」とMacの「〜」は違う? 2つの記号の違いと使い分け

Windowsでよく見かける「~」と、Macや生成AIの文章で見かけることがある「〜」。見た目はよく似ていますが、実は別の文字です。私はこの違いを以前からかなり意識していました。というのも、現在でもShift_JIS系で原稿を扱う媒体があり、私が使っている編集環境では「〜」が混ざっていると、そのまま保存できないことがあるからです。

ただ、フォントによっては2文字の違いがほとんど分かりません。そこでこの記事では、どちらの文字について説明しているのか分かりやすいように、次のマークを付けることにします。

  • 🟦 「~」:U+FF5E
  • 🟧 「〜」:U+301C

私は普段、🟧「〜」を見つけると🟦「~」へ置き換えています。今回は、この2文字がなぜ存在するのか、実際にはどちらを使えばよいのかを簡単に整理します。

「~」と「〜」は別の文字

2文字には、それぞれ別のUnicode番号があります。

区別 文字 Unicode Unicode上の名前 JIS文字との対応
🟦 U+FF5E FULLWIDTH TILDE(全角チルダ) Windows-31J/CP932ではJISの「波ダッシュ」相当の0x8160に対応
🟧 U+301C WAVE DASH(波ダッシュ) UnicodeがJISの区点1-33「波ダッシュ」に対応させた文字

ここが少しややこしいところです。Unicode上では🟦「~」の名前は「全角チルダ」ですが、WindowsではJISの「波ダッシュ」に相当する文字として長く使われてきました。

そのため、例えばWindows版ATOKで変換候補に「波ダッシュ」と表示されたものを選んでも、実際に入力されるのは🟦「~」(U+FF5E)ということがあります。「波ダッシュ」という変換候補の名前と、Unicode上の正式な文字名が必ずしも一致するわけではありません。

なお、半角の「~」(U+007E)や、「〰」(U+3030 WAVY DASH)という、さらに別の似た文字もあります。見た目だけで判断すると、思った以上にややこしい文字です。

実際に「から」で変換してみた

手元の環境で「から」と入力し、実際にどのUnicode文字が入力されるのか確認してみました。

環境 今回確認できた文字
Windows 11 + ATOK 🟦 U+FF5E
Windows 10 + Microsoft IME 🟦 U+FF5E
Mac + ATOK 🟦 U+FF5E
Mac標準日本語入力 🟧 U+301C

Windows 11などのOS種別/バージョンやIMEのバージョンや辞書、設定によって候補が変わる可能性があるため、この表はあくまで今回の環境で確認した結果です。

興味深いのは、Macだから必ず🟧「〜」になるわけではないことです。今回の確認では、Mac版ATOKで「から」と変換するとWindows版ATOKと同じ🟦「~」(U+FF5E)が入力されました。一方、Mac標準日本語入力では🟧「〜」(U+301C)が入力されました。

つまり、WindowsとMacというOSの違いだけで決まるのではなく、どの日本語入力システムを使っているかによっても結果が変わるようです。

さらにMac標準日本語入力で「ちるだ」「なみだっしゅ」などを試していると、「〰」というさらに別の文字が出てくることもありました。「ニョロニョロっぽいものを選べば同じ」というわけではありません。

結局、私は🟦「~」を使う

では、「1から10まで」を表す場合、

🟦 1~10
🟧 1〜10

のどちらを使えばよいのでしょうか。

規格上、JISの波ダッシュに対応するUnicode文字は🟧「〜」(U+301C)です。一方、Windowsでは長年、🟦「~」(U+FF5E)が同じ用途で広く使われてきました。Unicode Standardでも、この2文字について、実装上の対応の違いが長く存在してきたことが説明されています。

私の場合は、🟦「~」(U+FF5E)に統一して使います。大きな理由は、現在でもShift_JIS系で原稿を扱う媒体があり、私の編集環境では🟧「〜」(U+301C)が混ざっていると、そのまま保存できないことがあるためです。HTMLの文字数値参照などを使って回避することもできますが、そこまでして🟧「〜」を使う必要性は感じません。

また、Windows上ではフォントによって🟧「〜」の形がかなり不自然に見えることがあります。私が使っているWindowsの音声読み上げでも、🟦「~」は問題なく扱われる一方、🟧「〜」の部分が読み飛ばされることがありました。こうした実用面まで考えると、少なくとも私の環境では🟦「~」の方が扱いやすいという結論になりました。

入力環境によって結果が違う

今回試してみて分かったのは、同じ「から」という読みから変換しても、使っているIMEによって入力される文字が違うことです。

Windows 11のATOKとWindows 10のMicrosoft IME、さらにMac版ATOKでは、今回の環境ではいずれも🟦「~」(U+FF5E)が入力されました。一方、Mac標準日本語入力では🟧「〜」(U+301C)が入力されました。

特に見た目だけでは判別しにくい環境もあるため、「Windowsだから~」「Macだから〜」と単純に覚えるより、必要なら一度Unicode番号を確認しておく方が確実です。

また、普段とは逆の文字を入力したい場合、普通の変換候補だけでは簡単に出せないことがあります。その場合は文字パレットからUnicode番号を指定したり、頻繁に使うなら単語登録したりする方法がありますが、そこまでして使い分ける必要があるかは用途次第でしょう。

なぜ2種類あるの?

原因は、昔の日本語文字コードとUnicodeの対応方法にあります。JISの波ダッシュに相当する文字をUnicodeへ対応させる際、Unicodeでは🟧「〜」(U+301C)が割り当てられました。

一方、Windowsで広く使われたWindows-31J/CP932では、同じ0x8160の文字が🟦「~」(U+FF5E)へ対応付けられています。Microsoft CP932のUnicode対応表でも、この対応を確認できます。

そのため、「🟧の方が正しくて🟦は間違い」、あるいはその逆という単純な話ではありません。昔の日本語文字コードをUnicodeへ対応させる際の違いによって、非常によく似た2文字が現在まで共存していると考えると分かりやすいでしょう。

まとめ

🟦「~」(U+FF5E)と🟧「〜」(U+301C)は別の文字ですが、UTF-8のWebページなどで普通に文章を書く分には、どちらを使っても大きな問題になることは少ないでしょう。すでに使っている方があるなら、無理に変更する必要もないと思います。

ただし、Shift_JIS系のデータを扱う場合や、検索・置換、音声読み上げなどでは違いが問題になることがあります。そうした環境では、自分の用途で問題の起きにくい方を選ぶのがよさそうです。私の場合は、Shift_JIS系の原稿との互換性やWindowsでの使い勝手を考えて、🟦「~」(U+FF5E)を使っています。

参考資料

Claude Desktopが常に最前面になる問題の直し方【Windows】

Windows版のClaude Desktopを使っていると、アップデート後の自動再起動をきっかけに、Claudeのメインウィンドウがほかのアプリより常に手前に表示される状態になることがあります。

この状態になると、ChromeやVS Codeなど別のアプリに切り替えても、そのウィンドウをClaude Desktopの上に重ねられません。別のアプリにはフォーカスが移っているのにClaudeだけが画面の手前に残り続けるため、Claudeを最小化しないとほかのアプリを普通に使えなくなります。

私のWindows環境でも実際にこの現象が発生しました。Claude Desktopの設定を探してみても、「常に最前面」を解除するための項目は見当たりません。

GitHubに寄せられている報告を調べると、特にClaude Desktopがバックグラウンドで更新され、その後に自動的に再起動する処理をきっかけとして発生するケースが詳しく報告されています。2026年9月15日時点では根本的な修正は確認できていないため、この記事では私の環境で直った方法と、現在分かっていることをまとめます。

Claude Desktopを完全終了して起動し直す

まず試したいのは、Claude Desktopを完全に終了してから起動し直す方法です。私の環境では、この方法で通常のウィンドウ表示に戻りました。

ポイントは、Claude Desktopのウィンドウを閉じるだけではなく、Windowsの通知領域(タスクトレイ)に残っているClaudeも終了することです。

  1. Claude Desktopのウィンドウを閉じる
  2. Windowsのタスクバー右側にある通知領域を開く
  3. Claudeのアイコンを右クリックする
  4. Claudeを終了する
  5. Claude Desktopをもう一度起動する

私の場合、ウィンドウを閉じただけでは最前面の状態が解消されませんでしたが、通知領域に残っているClaudeまで終了してから再起動すると、通常どおりほかのウィンドウをClaudeの上に重ねられるようになりました。

GitHubのIssueでも、Claude関連のプロセスをすべて終了してから起動し直すことで解消したという報告があります。Claude Desktopはウィンドウを閉じてもプロセスがそのまま残る場合があるため、単にウィンドウを閉じて開き直すのではなく、いったん完全に終了することがポイントになりそうです。

PowerToysを使っているなら「Always On Top」も試せる

Microsoft PowerToysをインストールしている場合は、「Always On Top」機能を使って解除する方法もあります。

Claude Desktopをアクティブにした状態で、Win + Ctrl + Tを押します。一度で通常の状態に戻らない場合は、いったんPowerToys側で「常に手前に表示」を有効にしてから、もう一度同じショートカットを押して解除するという使い方になります。

GitHubでは、この操作によって実際にClaude Desktopの最前面状態を解除できたという報告が出ています。ただし、その後の自動更新などをきっかけに再発したという報告もあるため、恒久的な修正ではなく、その場で使える回避策と考えた方がよさそうです。

私自身もPowerToysをインストールしているので、次にこの問題が発生したときはこちらの方法も試してみる予定です。実際に確認できたら、この記事にも追記します。

それでも直らない場合

上の2つの方法でも直らない場合は、ひとまずClaude Desktopを最小化して使うのが安全です。実際、GitHubでも最小化が簡単な回避策として挙げられています。

Windowsのウィンドウ属性をPowerShellなどから直接変更する方法も報告されていますが、通常のトラブルシューティングとして紹介するには少し踏み込みすぎだと思うので、この記事では扱いません。そこまで必要になった場合は、WindowsやClaude Desktopのバージョン、現在の症状などを生成AIに伝え、個別に相談するのがよいでしょう。

この問題はほかのユーザーにも発生している

この現象は、私のPCだけで起きているものではありません。Anthropicのanthropics/claude-codeリポジトリには、Claude Desktopのウィンドウが常に最前面になるという報告が複数投稿されています。

現在、Windows版の問題として中心的に追跡されているのが次のIssueです。

2026年9月15日時点では、このIssueはOpenのままです。bughas reproplatform:windowsarea:desktopといったラベルが付けられており、Windows版Claude Desktopで再現する不具合として多数の報告や検証結果が集まっています。

これ以前にも、同じ問題について複数のIssueが作られています。

macOSでも、同様の問題が次のIssueで報告されています。

一部のIssueは、Claude Codeそのものの問題ではないとしてinvalid扱いになったり、別のIssueとの重複として閉じられたりしています。Claude Desktopの問題がClaude CodeのIssueトラッカーに投稿されていることもあり、これまでのIssueの扱いにはやや混乱が見られます。

一方で、現在Openになっている#89467にはWindowsでの再現報告が多数集まっており、単に特定のPCだけで起きている現象ではなさそうです。

2026年9月15日時点では未修正

2026年9月15日時点では、この問題が根本的に修正されたことは確認できていません。9月13日に公開されたClaude Desktop 1.52386.6でも、同じ問題が発生したという報告があります。

Claude Desktopの公式Changelogも確認しましたが、always on top、topmost、z-order、stealth relaunchなど、この問題の修正と判断できる記載は見つかりませんでした。

Anthropicの公式サポートでも、現時点ではこの問題の原因や対処方法を説明した記事は確認できていません。そのため、現在のところは「ユーザーから継続的に報告されているものの、まだ公式な修正は確認できていない不具合」と考えるのがよさそうです。

原因についてはかなり詳しい分析が出ている

Anthropic自身から、この問題の原因について公式な説明が出ているわけではありません。ただしGitHubでは、Claude DesktopのログやWindowsのウィンドウ属性まで調べたかなり詳しい分析が報告されています。

特に#87084では、Claude Desktop 1.30096.x系で確認されたバックグラウンド更新後の自動再起動処理について調査されています。この処理はログ上でstealth-relaunchと呼ばれており、アップデート前のウィンドウの表示順を記録し、自動再起動した後にClaudeのウィンドウを元の位置へ戻そうとします。

このとき基準として記録されたウィンドウがWindows上の「常に最前面」のウィンドウだった場合、Claude DesktopにもWS_EX_TOPMOSTというWindowsの最前面属性が付いてしまう、というのが現在報告されている原因分析です。

最初の詳細な調査ではWindowsのタスクバーが基準になっていましたが、その後の#89467の調査では、セカンダリモニターのタスクバーだけでなく、WindowsのIME関連ウィンドウやRazer Synapseの補助ウィンドウなど、別の最前面ウィンドウを基準にした場合にも同じ現象が確認されています。

そのため、単純に「Windowsのタスクバーが原因」というより、Claude Desktopが自動再起動後にウィンドウの表示順を復元する際、最前面属性を持ったウィンドウを基準にしてしまうことが問題ではないか、という分析が現在は有力です。

この分析であれば、アップデート後の自動再起動をきっかけとして発生することや、毎回必ず発生するわけではないことも説明できます。また、いったんClaude Desktopを完全終了してウィンドウを作り直すことで正常な状態に戻るケースがあることとも整合します。

ただし、ここまでの内容はあくまでGitHub上のユーザーによる技術的な調査結果です。ログやWindows APIを使って複数の環境で検証されているためかなり具体的な分析ではありますが、Anthropicが公式に「これが原因」と認めた情報ではありません。

とりあえず完全終了を覚えておけばよさそう

現時点では根本的な修正を待つ必要がありますが、WindowsでClaude Desktopが突然ほかのアプリの上に居座るようになった場合は、まず通知領域からClaude Desktopを完全終了して、もう一度起動する方法を覚えておけばよさそうです。少なくとも私の環境では、この方法で正常な状態に戻せています。

PowerToysを使っている人であれば、Win + Ctrl + Tによる解除も手軽な選択肢です。それでも直らなければ、ひとまずClaudeを最小化してしのぐのが安全でしょう。

この問題については、GitHub IssueやClaude DesktopのChangelogを引き続き確認しています。Anthropicによる正式な修正や、新しい回避策などが分かった場合は、この記事にも追記していこうと思います。

更新履歴

  • 2026年9月15日:初版。Claude Desktopを完全終了して再起動する回避策、PowerToysによる解除方法、GitHubで報告されている原因分析を掲載

位置情報データはどうプライバシーを守る? 匿名化・集計・秘匿化を整理する

自分用の備忘メモ。ここまで、人流データの種類や、位置情報に含まれる「時間」をどう扱うかについて整理してきました。「人流データの種類を整理する:位置点・滞在・OD(出発地・到着地)・人口集計は何が違う?」では人流データの形を、「人流データは時間をどう扱う? 観測間隔・滞在判定・時間集計を整理する」では、位置情報を時間軸で扱うときの考え方を見てきました。

位置情報を扱っていると、次に気になるのがプライバシーをどう守るのかという問題です。「個人情報だから保護しなければならない」「位置履歴をそのまま公開してはいけない」というところまでは感覚的にも分かりますが、実際のデータ処理では何をすればよいのでしょうか。氏名を削除すれば十分なのか、位置をメッシュにまとめればよいのか、人数が少ないデータはどう扱えばよいのか、と考えていくと意外と複雑です。

今回は法律の細かな解説というより、位置情報を安全に利用するために、データを実際にどのように加工・集計・秘匿するのかというところから整理してみます。

なお、位置情報が常に個人情報に該当するわけではありません。特定の個人を識別できる場合には個人情報となり得ますし、個人情報には該当しなくても、ある個人に関係する位置情報は「個人関連情報」に当たる場合があります。個人情報保護委員会のQ&Aでも、個人関連情報の例として位置情報が挙げられています。

(1)名前を消しただけでは十分とは限らない

位置情報の保護というと、まず氏名やメールアドレス、会員番号などを削除することを思い浮かべます。例えば、

氏名:Aさん

を、

ID:user_12345

へ置き換えれば、一見すると誰のデータなのか分からなくなります。

しかし、位置履歴そのものが細かく残っている場合は事情が変わります。毎晩同じ場所にいるなら自宅、平日の昼間に長時間滞在する場所なら勤務先、といった推測ができる可能性があるからです。名前や直接的な識別子を消しても、位置と時間の組み合わせが詳細に残っていれば、別の情報と照らし合わせて人物を推測できる余地が残ります。

図1:氏名を削除・置換しても、詳細な位置履歴や移動パターンそのものは残る。

個人情報保護委員会の「仮名加工情報・匿名加工情報編」でも、移動履歴に自宅や職場を推定できる緯度・経度が含まれ、それが個人の識別や元情報の復元につながるおそれがある場合には、該当する位置情報を削除する加工例が示されています。

つまり、「名前を消すこと」と「個人を推測できなくすること」は同じではありません

店舗や駅などのPOIデータそのものは「場所についての情報」ですが、「ある人がその場所を訪れた」という情報になると、人に関係する位置情報になります。位置情報のプライバシーを考えるときには、単独の地点だけでなく、時間を含んだ履歴や、ほかのデータとの組み合わせまで考える必要があります。

(2)個人単位ではなく、集団として見る

位置情報を保護する方法として分かりやすいのが、個人単位のデータをそのまま使わず、地域や時間帯ごとに集計することです。

例えば元のデータが、

Aさん 12:03 新宿駅周辺
Bさん 12:04 新宿駅周辺
Cさん 12:06 新宿駅周辺
Dさん 12:11 新宿駅周辺
...

だったとしても、分析の目的が「12時台の新宿駅周辺に何人いたか」を知ることなら、一人ひとりの履歴を利用者に見せる必要はありません。そこで、

新宿駅周辺
12:00~13:00
1,250人

のような集計値へ変換できます。

図2:個票をそのまま提供するのではなく、場所・時間などの単位でまとめて集計データにする。図中の人数は説明用の架空例。

こうすると、分析対象は「Aさんがどこへ行ったか」ではなく、「この地域に何人いたか」という集団の傾向になります。以前の記事で整理した「個票」と「集計データ」の違いは、プライバシー保護という意味でも重要です。人流データを利用する側が必要としているのが地域全体の傾向であれば、そもそも個人単位の履歴を提供しない、という設計ができます。

ただし、集計すれば必ず安全になるわけではありません。人数が極端に少ないグループや、細かすぎる場所・時間で集計したデータでは、個人を推測できる可能性が残ります。NISTの差分プライバシーの解説でも、単純な集計だけでは、グループが十分に大きくない場合などにプライバシー保護が十分とは限らないことが説明されています。

そこで、集計するだけでなく、場所や時間の粒度も調整していきます。

(3)場所を細かくしすぎない

位置情報には、緯度・経度のような非常に細かな情報があります。しかし、分析の目的によっては、その精度が必ずしも必要とは限りません。例えば、

緯度・経度
↓
100mメッシュ
↓
500mメッシュ
↓
市区町村

のように、細かな地点をより大きな地域単位へまとめることができます。

図3:位置や時刻を、分析目的に必要な範囲まで粗い単位にまとめる。

例えば「東京駅周辺の人流」を分析するだけなら、利用者一人ひとりの緯度・経度をそのまま残す必要はなく、500mメッシュなどへまとめても目的を達成できる場合があります。このように、細かな位置をより大きな空間単位へまとめることで、個人の具体的な行動を追いにくくできます。

以前取り上げたH3のような地理空間インデックスも、位置情報をセル単位にそろえて集計するために利用できます。

一方で、位置を粗くすればするほど分析できる内容も減ります。店舗単位の来訪分析をしたいのに、市区町村単位までしか分からなければ目的を達成できません。ここには、プライバシーを守ることと、データの分析価値を残すことのバランスがあります。

(4)時間も細かくしすぎない

位置と同じように、時刻についても必要以上に細かくしないという考え方があります。

例えば、

12:03:24
↓
12時台
↓
昼間
↓
1日

のように時間単位をまとめられます。12時03分24秒にどこにいたのかまで分かれば、個人の移動をかなり細かく追うことができます。一方、「12時台にこの地域に何人いたか」という集計であれば、一人ひとりの動きは見えにくくなります。

前回の人流データは時間をどう扱う?では、5分、1時間、1日など、時間の区切り方によって分析結果が変わることを整理しました。プライバシーという観点から見ると、この時間集計には、細かな行動履歴を追いにくくするという意味もあります。

もちろん、ここでも粗くすればよいというものではありません。駅の混雑を5分単位で把握したい場合に1日単位までまとめてしまっては役に立たないため、空間と同じように目的を達成できる範囲で必要な粒度を選ぶことになります。

(5)人数が少なすぎるデータを出さない

位置と時間を集計しても、人数が非常に少ない場合には注意が必要です。例えば、

ある地域
12時台
1人

というデータがあった場合、その地域や時間帯を知っている人から見れば、「おそらくこの人ではないか」と推測しやすくなる可能性があります。

そこで、一定人数より少ない区画を表示しない、あるいは周囲の地域とまとめる、といった方法が使われることがあります。

図4:少人数の区画を非表示にするイメージ。人数や基準値は説明用の架空例で、実際の閾値はデータやサービスによって異なる。

こうした処理は「少数セルの抑制」などと呼ばれます。ただし、重要なのは「○人未満なら安全」という共通の数字があるわけではないことです。位置や時間の細かさ、データの性質、ほかの情報との組み合わせによってリスクは変わるため、実際の基準はサービスや利用目的によって異なります。

個人情報保護委員会のガイドラインでも、珍しい情報や、ほかの個人との差異が大きい「特異な記述等」は、個人の識別や元情報の復元につながるおそれがあるため、削除や一般化などの加工が必要になる場合があるとされています。

(6)数字にノイズを加える方法もある

さらに高度な方法として、統計値へ意図的にノイズを加える考え方もあります。例えば実際の集計結果が、

1,000人

だったとしても、公開する値を、

997人
1,006人

のように少し変化させるイメージです。

もちろん、単に適当な乱数を加えれば安全になるわけではありません。重要なのは、個々人の情報を推測しにくくしながら、全体としての統計的な傾向は利用できるようにすることです。

この考え方を数学的に定義した代表的なものが差分プライバシー(Differential Privacy)です。NISTの解説では、ある個人のデータが分析対象に含まれている場合と含まれていない場合で、出力結果からその違いを判別しにくくする考え方として説明されています。

差分プライバシーは、それだけで一つの記事になるほど奥の深いテーマです。ここでは、集計値をそのまま公開する以外にも、統計的にプライバシーを保護する方法があると理解する程度でよさそうです。

(7)「仮名化」「匿名化」「統計情報」は同じではない

ここまで、技術的にデータをどう加工するかを見てきました。一方、日本の個人情報保護法には、似ているようで意味の異なる用語があります。特に混同しやすいのが、仮名加工情報、匿名加工情報、統計情報です。

大まかな違いを整理すると、次のようになります。

用語 大まかな意味
個人情報 氏名などにより、または他の情報と容易に照合することで、特定の個人を識別できる情報など
個人関連情報 個人に関係する情報だが、個人情報・仮名加工情報・匿名加工情報には当たらないもの。位置情報などが該当する場合がある
仮名加工情報 他の情報と照合しない限り個人を識別できないよう加工した情報
匿名加工情報 特定の個人を識別できず、元の個人情報を復元できないよう、法令上の基準に従って加工した情報
統計情報 複数人の情報を集計し、特定の個人との対応関係が排除された情報

特に注意したいのが、IDを別の文字列へ置き換えただけで、法律上の「匿名加工情報」になるわけではないという点です。

個人情報保護委員会のQ&Aでは、仮名加工情報は「他の情報と照合しない限り特定の個人を識別できないように加工した情報」と整理されています。一方、匿名加工情報は、特定の個人を識別できず、元の個人情報を復元できないようにしたうえで、法令上の加工基準を満たす必要があります。

また、統計情報も匿名加工情報とは別のものです。複数人の情報を集計し、特定の個人との対応関係が排除されている場合には、「個人に関する情報」に該当しないものとして扱われます。

そのため、日常的に使う「匿名化」という言葉と、法律上の「匿名加工情報」は分けて考えた方がよさそうです。

(8)結局、位置情報をどう守ればいいのか

ここまで見てきたように、位置情報の保護は「匿名化ボタン」のような一つの処理で終わるものではありません。

図5:位置情報を保護するための代表的な考え方。実際にはデータの性質や利用目的に応じて必要な方法を組み合わせる。

大まかには、

  1. 氏名や直接識別子を削除・置換する
  2. 個票を地域・時間ごとに集計する
  3. 位置や時刻の粒度を必要な範囲まで粗くする
  4. 人数が少ない区画や特異な情報を抑制する
  5. 必要に応じてノイズ付加などの追加保護を行う

といった複数の方法を組み合わせます。

実際にデータを設計するときには、「どこまで細かい情報を残せるか」から考えるより、まず何を知るためにデータが必要なのかを考える方が分かりやすそうです。例えば出店候補エリアの人流を比較したいだけなら、秒単位の個人の移動履歴は必要ないかもしれません。500mメッシュ、1時間単位の集計人口で十分なら、それ以上細かなデータを扱わないことでプライバシーリスクも減らせます。

位置情報を扱うときには、少なくとも次の点を確認しておくとよさそうです。

確認したいこと 考え方
個人単位の履歴が本当に必要か 不要なら最初から集計する
位置はどこまで細かく必要か 店舗、100m、500m、市区町村など目的に合わせる
時刻はどこまで細かく必要か 秒単位ではなく1時間単位で十分な場合もある
人数が少なすぎないか 少人数なら非表示や地域統合を検討する
他の情報と組み合わせると個人を推測できないか 位置情報だけで判断しない
必要以上のデータを残していないか 利用目的に必要な粒度までにする

結局のところ、位置情報のプライバシー保護は、できるだけ多くの情報を残したまま後から匿名化することだけを考えるのではなく、最初から目的に必要な範囲へデータを絞ることが重要なのだと思います。

まとめ

位置情報のプライバシーを守るというと、最初に思い浮かぶのは氏名やIDの削除かもしれません。しかし、位置情報では移動履歴そのものから自宅や勤務先などを推測できる可能性があるため、それだけでは十分とは限りません。

実際には、個票を集計し、空間や時間の粒度を粗くし、人数が少ないデータを抑制し、必要に応じてノイズを加えるなど、複数の方法を組み合わせて個人を推測しにくくしていきます。一方で、データを粗くすればするほど分析できる内容も減ります。

そのため重要なのは、「最も細かなデータをどう匿名化するか」ではなく、「目的を達成するために、どこまで細かなデータが本当に必要なのか」から考えることなのだと思います。

位置情報を安全に利用するというのは、情報を完全に消すことではなく、分析に必要な価値を残しながら、個人を追える細かさを必要以上に残さないように設計することなのだと理解しました。

※本稿は位置情報データとプライバシーに関する一般的な技術・制度の整理を目的としたもので、法的助言ではありません。また、本稿は筆者個人の調査・見解に基づくものであり、所属組織を代表するものではありません。

参考資料

人流データは時間をどう扱う? 観測間隔・滞在判定・時間集計を整理する

自分用の備忘メモ。前回の人流データの種類を整理する:位置点・滞在・OD(出発地・到着地)・人口集計は何が違う?では、人流データを「位置点」「軌跡・移動区間」「滞在・訪問イベント」「人口・滞在人口」「来訪者集計」「OD」などに分けて整理しました。そのときあらためて気になったのが、位置情報に含まれる「時間」をどのように扱うのかという点です。

位置情報は緯度・経度だけでできているわけではなく、通常は「いつ観測されたか」というタイムスタンプとセットになっています。ところが、観測は必ずしも1分おき、5分おきのように一定間隔で行われるわけではありません。さらに、その位置点から「10分間滞在した」「今日この店舗を訪れた」「12時台には500人いた」といった人流データを作るには、どこまでを一続きの行動とみなすか、何分以上を滞在とするか、何分・何時間単位で集計するかなど、時間についてさまざまなルールを決める必要があります。

そこで今回は、位置情報を時間軸で見たときに出てくる観測間隔、滞在判定、時間集計などの基本的な考え方を整理してみます。

位置情報は一定間隔で取得されるとは限らない

まず前提として、位置情報の観測時刻は必ずしも等間隔ではありません。例えば、ある端末から次のような位置情報が得られたとします。

12:01
12:03
12:05
12:17
12:24

最初の3点は2分間隔ですが、その後は12分、7分と間が空いています。GPSやアプリなどから得られる位置情報では、このように観測間隔にばらつきが生じることがあります。

図1:位置情報の観測間隔の例。位置情報は必ずしも一定間隔で取得されるとは限らない。

この違いは、人流を分析するときに意外と重要です。12:05と12:17に同じ場所で観測されていたとしても、その12分間ずっとそこにいたとは限りません。一度別の場所へ移動して戻ってきた可能性もあります。逆に、その間に位置情報が取得されなかっただけで、実際にはずっと同じ場所に滞在していた可能性もあります。

つまり、位置点と位置点の間には「観測されていない時間」が存在します。人流データでは観測できた点だけを見るのではなく、その間の空白をどう扱うかによって、移動や滞在についての解釈も変わってきます。

(1)バラバラな観測時刻をどう扱うか

時系列データでは、異なる観測間隔のデータを一定の時間単位にそろえて扱う処理を「リサンプリング(resampling)」と呼びます。例えば、不規則な時刻で得られた位置情報を5分単位で分析したい場合を考えてみます。

実際の観測
12:01
12:03
12:05
12:17
12:24

これを分析側では、

分析したい時間軸
12:00
12:05
12:10
12:15
12:20
12:25

のような一定間隔の時間軸で扱いたいことがあります。

ただし、ここで注意したいのは、時間軸をそろえることと、観測されていない位置を推測することは別の処理だという点です。例えば12:05と12:17の位置が分かっているからといって、その間を直線で補間すれば実際の移動経路になるとは限りません。道路や鉄道に沿って移動したかもしれませんし、途中でどこかに立ち寄っていた可能性もあります。

そのため、人流データでは単純に欠けた値を埋めればよいわけではありません。何を分析したいのかに応じて、観測値だけを使うのか、一定時間ごとにまとめるのか、何らかの補間を行うのかを判断する必要があります。

(2)どこまでを一続きの行動と考えるか

観測時刻の間が大きく空いた場合には、それを一続きの行動として扱ってよいのかという問題も出てきます。例えば、次のようなデータがあったとします。

12:01
12:03
12:05

──── 3時間観測なし ────

15:08
15:10

12時台の位置点と15時台の位置点を単純につないで、「3時間かけて移動した」と考えるのは不自然です。観測されなかった3時間の間に一度行動が終了し、その後に別の移動や滞在が始まっている可能性があります。

そこで、一定時間以上観測が途切れた場合には、前後のデータを別のまとまりとして扱うことがあります。このように一連の観測を時間的なまとまりに分ける考え方は、セッション化などと呼ばれます。ただし、「30分空いたら別セッション」「1時間空いたら別セッション」といった共通の正解があるわけではありません。徒歩移動を分析するのか、1日の観光行動を見るのか、店舗への来訪を見るのかによって、意味のある時間の区切りは変わります。

つまり、どこまでを一続きの行動として扱うか自体が、人流データを作るためのルールの一つになります。

(3)位置点から「滞在」をどう判定するか

時間情報が特に重要になるのが、「滞在」や「来訪」を判定するときです。位置情報として直接得られるのは基本的に「ある時刻にある場所で観測された」という位置点ですが、人流分析ではそこから「この場所に滞在した」「この店舗を訪れた」という意味のあるイベントへ変換することがあります。

図2:位置点を時間軸で並べ、移動と滞在として解釈するイメージ。実際の滞在・来訪判定の条件はデータやサービスによって異なる。

例えば店舗の近くで位置情報が1点だけ観測された場合、単に店の前を通過しただけかもしれません。一方、同じ場所の周辺で一定時間にわたって複数の位置点が観測されていれば、「その場所に滞在していた」と判断できる可能性が高くなります。ここでは位置だけでなく、どのくらいの時間そこにいたかが重要になります。

実際の判定では、滞在時間だけでなく、位置点同士の距離、対象施設の範囲、位置精度、観測間隔なども関係します。そのため、「5分以上いれば必ず来訪」といった単純なルールがすべてのデータに共通して存在するわけではありません。

重要なのは、「来訪者数」という数字が、単に店舗付近で取得されたGPS点を数えただけで作られているとは限らないということです。位置情報に時間や距離などの条件を加え、一定のルールで意味付けすることで、滞在や来訪というデータが作られます。

(4)5分、1時間、1日で見え方が変わる

位置情報を人数などに集計するときには、「何分単位で集計するか」も結果を大きく左右します。例えば駅前の滞在人口を5分単位で集計すれば、電車の到着直後に人が急増するといった短時間の変化まで見えるかもしれません。一方、1時間単位にまとめると短いピークは平均化されますが、朝、昼、夕方といった大きな傾向は見やすくなります。

図3:同じ架空の人流データを5分単位と1時間平均で表示した例。時間粒度を粗くすると短時間の変動が平滑化される。

さらに、「どの時間幅で区切るか」だけでなく、その時間内の値をどうまとめるかも重要です。滞在人口なら平均値を使う場合もあれば、ピーク時の混雑を見るために最大値を使うこともあります。来訪イベントなら、その時間内の来訪回数を合計するのか、重複を除いたユニーク来訪者数を数えるのかでも意味が変わります。

つまり、「1時間集計」という言葉だけでは十分ではありません。

どの時間幅で区切ったか
+
その時間内のデータをどう集計したか

という2つを確認する必要があります。細かな時間単位は変化を詳しく捉えられる一方で、短期的な揺れやノイズも目立ちやすくなります。逆に時間単位を大きくすると全体の傾向は見やすくなりますが、短時間のピークは見えにくくなります。どの時間粒度が適切かは、分析の目的によって変わります。

(5)ユニーク人数と延べ来訪回数は違う

時間集計では、「同じ人を何回数えるか」という問題もあります。例えばAさんが、同じ日に午前10時と午後3時の2回、同じ店舗を訪れたとします。

図4:同じ利用者が同じ店舗を2回訪れた場合、ユニーク来訪者数では1人、延べ来訪回数では2回となる。

この場合、1日単位のユニーク来訪者数として数えれば1人ですが、延べ来訪回数として数えれば2回です。さらに集計期間を変えると意味も変わります。例えば「1時間ごとのユニーク人数」を足し合わせても、それがそのまま「1日のユニーク人数」にはなりません。同じ人が複数の時間帯に登場している可能性があるからです。

そのため、人流データで「来訪者数1万人」と書かれていたとしても、それがユニーク人数なのか延べ来訪回数なのか、さらに何時間・何日・何カ月を単位として重複を除いているのかによって数字の意味は変わります。第3回の記事でも来訪者集計の例として unique_visitorstotal_visits を挙げましたが、この違いはまさに時間の扱いと密接に関係しています。

(6)朝・昼・夜、平日・休日にまとめる

実際の人流分析では、1時間ごとのデータをそのまま見るだけでなく、時間帯や曜日のグループにまとめることもよくあります。例えば飲食店であればランチとディナー、小売店であれば平日と休日、鉄道であれば朝夕の通勤時間帯というように、分析対象によって意味のある時間区分が異なります。

朝
昼
夕方
夜

平日
土日祝

こうした分類は分かりやすい一方で、「朝は何時から何時までか」「土曜日を平日と同じ扱いにするか」といった定義は自動的に決まるものではありません。分析者やサービス提供者が目的に応じて決める必要があります。

つまり、「平日平均」「昼間」「夜間」といった分かりやすい名前が付いているデータでも、その裏には時間をどのように区切ったかという定義があります。異なるデータやサービスを比較するときには、名称だけを見て同じものだと判断せず、具体的な時間帯や曜日の定義まで確認した方が安全です。

(7)平均すると見えなくなるものもある

複数の日をまとめて人流を見るときには、平均値がよく使われます。例えば月曜日から金曜日までの同じ時刻の人流を平均すれば、「典型的な平日」の人流パターンを作ることができます。日ごとのばらつきを抑えて全体傾向を把握したい場合には便利な方法です。

一方で、平均化すると特殊な日の特徴が消えてしまうことがあります。イベントで急激に人が増えた日、大雨で人出が減った日、祝日やセールの日などもまとめて平均すれば、その日の特徴は目立たなくなります。

そのため、分析目的に応じて集計方法を変える必要があります。

通常の平日を知りたい
→ 平日平均

最大混雑を知りたい
→ 最大値・上位値

イベント効果を知りたい
→ 通常日とイベント日を分けて比較

外れ値の影響を小さくしたい場合には中央値を使うこともありますし、曜日別に分けて比較した方がよい場合もあります。「平均を取れば代表的な人流になる」とは限らないという点には注意が必要です。

(8)固定した時間帯と「直近60分」は別物

時間集計には、もう一つ「時間窓(time window)」という考え方があります。分かりやすいのは、次のように固定された時間帯にデータを区切る方法です。

12:00~13:00
13:00~14:00
14:00~15:00

この方法なら、12時台と13時台を比較するといった分析が簡単です。

一方、リアルタイムに近い分析では、「現在時刻から直近60分」のように、時間とともに集計範囲が移動する方法もあります。これはローリングウィンドウやスライディングウィンドウなどと呼ばれます。例えば13時20分時点では12時20分~13時20分、13時25分になれば12時25分~13時25分を集計する、といった形です。

固定された時間帯は過去の時間帯同士を比較しやすく、移動する時間窓は現在の混雑や直近の傾向を見るのに向いています。どの時間窓を使うかによっても、同じ元データから得られる指標の意味は変わります。

人流データの時間を見るときに確認したいこと

ここまで見てきたように、人流データの時間に関する条件は一つではありません。観測時刻の間隔から、滞在の判定、集計時間、重複の扱い、複数日のまとめ方まで、いくつものルールが最終的な数字に影響します。

確認項目 主に影響するもの
観測間隔 数秒、数分、不規則 軌跡・滞在判定
長い観測空白の扱い 一定時間で行動を区切る 移動・セッション
滞在・来訪判定 滞在時間、距離、施設範囲など 来訪者数
集計時間 5分、1時間、1日 ピークや変動の見え方
集計方法 平均、合計、最大、ユニーク 指標の意味
重複の扱い ユニーク人数、延べ回数 来訪者数
時間帯 朝、昼、夜など 時間帯別比較
曜日区分 平日、休日、曜日別 典型的な人流パターン
複数日のまとめ方 平均、中央値、最大など 特殊日の影響
時間窓 固定1時間、直近60分など リアルタイム指標

同じ「人流データ」でも、これらの条件が違えば最終的に表示される数字は変わります。特に複数サービスの人流を比較するときには、データの取得元だけでなく、どの時間単位で、どのルールによって集計されたデータなのかまで確認する必要があります。

まとめ

位置情報には緯度・経度だけでなく「いつ観測されたか」という時間情報があり、人流データを作るには、その時間をどのように扱うかを決める必要があります。位置情報は必ずしも一定間隔で観測されるわけではなく、不規則な位置点から一連の移動を考え、滞在や来訪を判定し、さらに5分、1時間、1日といった時間単位へまとめることで、私たちが普段見る「滞在人口」や「来訪者数」といった指標になっていきます。

その過程では、何分を滞在とみなすか、何時間単位で集計するか、同じ人を何回数えるか、平均を取るのか最大値を見るのか、といったルールが結果を左右します。つまり、人流データを見るときには「どこに何人いたのか」だけではなく、「いつを、どのように区切り、どのようなルールで人数として数えたのか」まで見ることが重要です。

同じ位置情報をもとにしたデータであっても、時間の扱いが違えば、そこから見えてくる「人流」も変わるのだと思います。

※本稿は筆者個人の調査・見解に基づくものであり、所属組織を代表するものではありません。

丸数字「①②③」は今でも使ってはいけない? 機種依存文字とUnicodeの現在

昔からパソコンを使っている人なら、「①②③のような丸数字は機種依存文字なので使ってはいけない」と、一度は聞いたことがあるのではないでしょうか。私も長らくその認識で、特に仕事の文章などでは、できるだけ「(1)(2)(3)」に置き換えるようにしてきました。

ところが最近は、WebサイトやSNSでも①②③を普通に見かけますし、ChatGPTなどの生成AIに文章を整理してもらうと、丸数字を結構な頻度で使ってきます。よく考えると、私自身も以前書いた「Windows 11でのエンダッシュとエムダッシュの入力方法」の記事で、比較表の番号として①~⑧を普通に使っていました。

では、「丸数字は使ってはいけない」という昔の常識は、もう気にしなくてよいのでしょうか? 気になったので、丸数字が機種依存文字と呼ばれるようになった理由と、Unicodeが普及した現在ではどう考えればよいのかを整理してみました。

図1:昔は「機種依存文字」として警戒された丸数字ですが、Unicode/UTF-8が一般化した現在は状況がかなり変わっています。ただし、入力先や連携先の仕様は別問題です。

1. 結論:普通のWebや文書なら、①②③は基本的に使える

先に結論を書くと、Unicodeを扱える現在の一般的なWebサイトや文書で、①②③を使うこと自体は基本的に問題ありません。①②③にはUnicodeでそれぞれ固有のコードポイントが割り当てられており、昔のように「Windowsでは①なのに、別の環境では別の文字になる」という問題は起きにくくなっています。

一方で、現在でも丸数字を入力できないWebサービスや業務システムは存在します。そのため、「丸数字=絶対に使ってはいけない」ではなく、普通の文章では使えるが、データ交換や入力先の仕様によっては避ける必要がある文字と考えるのが、現在では実態に近そうです。

用途 ①②③の使用 考え方
UTF-8のWebページ 基本的に問題なし Unicodeとして扱える
ブログ、SNS、チャット 基本的に問題なし 現在の一般的な環境なら表示できる
Word、Googleドキュメント、PDF 通常は問題なし 一般的なフォント・環境なら扱える
一般的なメール 通常は問題なし 現代的なメール環境ではUnicodeを扱える
CSV、TSV、テキストファイル 仕様次第 ファイル形式より文字コードと受け側の仕様が重要
業務システムへの入力 要確認 使用可能文字が限定されている場合がある
電子申請・入力フォーム 要確認 現在でも丸数字を禁止しているサービスがある
不特定環境へのデータ納品 (1)(2)(3)が無難 互換性を最優先するなら代替表記が安全

つまり、丸数字そのものが危険な文字というより、「その文字を最終的に誰が、どのシステムで扱うのか」が重要になったということですね。

2. そもそも、なぜ①②③は「機種依存文字」だったのか

昔の日本語環境では、Shift_JIS系をはじめとする従来の文字コードが広く使われていました。しかし、その中にはWindowsやMacなどが独自に拡張した領域もあり、環境によって文字の割り当てが異なるケースがありました。

そのため、ある環境で①として保存した文字が、別の環境では違う記号になったり、正しく表示できなかったりすることがありました。こうした事情から、①②③や㈱、ローマ数字などは「機種依存文字」と呼ばれ、メールやWebでは避けるのが定番になっていったわけです。

図2:機種依存文字問題のイメージ。実際には「WindowsとMacがまったく別の文字コードを使っていた」という単純な話ではなく、Shift_JIS系の拡張領域や変換対応の違いなどが原因でした。

当時は、どの環境でも確実に読める表記として、①を(1)、②を(2)のように置き換える方法がよく使われました。「丸数字は使わない」というルールは、当時の事情を考えればかなり合理的だったと思います。

3. Unicodeでは①②③も正式な文字になっている

現在は事情が大きく変わっています。Unicodeでは①②③がそれぞれ独立した文字として定義されており、①はU+2460 CIRCLED DIGIT ONE、②はU+2461、③はU+2462です。

①~⑳は「Enclosed Alphanumerics」というブロックに収録されており、Unicodeの仕様でも番号付きリストなどで使う文字として説明されています。つまりUnicodeの世界では、①②③はWindowsだけが勝手に持っている文字ではなく、共通の文字として扱われています。

文字 Unicode Unicode名
U+2460 CIRCLED DIGIT ONE
U+2461 CIRCLED DIGIT TWO
U+2462 CIRCLED DIGIT THREE
U+2469 CIRCLED NUMBER TEN
U+2473 CIRCLED NUMBER TWENTY

ここでUnicodeとUTF-8を混同しやすいのですが、ざっくり言えばUnicodeが「文字に共通の番号を割り当てる仕組み」で、UTF-8はその文字をファイルや通信データとして保存・送受信するための符号化方式です。現在のWebではUTF-8が基本になっているため、①をU+2460として共通に扱いやすくなりました。

4. それでも今なお「環境依存文字」と呼ばれることがある

では、もう①②③を「機種依存文字」と呼ぶ必要はないのでは? と思うところですが、ここが少しややこしいところです。Windows 11のMicrosoft IMEでも、丸数字などは現在でも「環境依存文字」として変換候補に表示される場合があります。

NECのWindows 11向けFAQでも、環境依存文字を含むメールやファイルは受信側の環境によって正常に表示されない場合があると説明されています。その一方で、同じページには丸数字など「正常に表示できる文字も含まれている」とも書かれており、まさに現在の微妙な立ち位置が表れています。

つまり現在の「環境依存文字」という表示は、「この文字は現代の環境では使えない」という意味ではなく、「相手側の環境まで含めて完全な互換性を保証できるとは限らない」くらいに受け取るのがよさそうです。

5. 「Unicodeにある」と「そのサービスで入力できる」は別問題

ここが今回、一番重要なポイントかもしれません。Unicodeに①が正式に存在することと、個別のサービスや業務システムが①を入力可能文字として受け付けることは、まったく別の話です。

例えばe-Gov電子申請では、現在でも①~⑳を「使用できない文字の例」として明示しています。Unicodeで問題なく表現できる文字であっても、システム側が受け付ける文字集合を限定していれば入力できません。

図3:現在の使い分けの目安。CSVだから丸数字が使えないわけではなく、文字コードや取り込み先の仕様を確認する必要があります。

この意味では、昔と現在で注意する理由が少し変わっています。昔は「機種が違うと同じ文字として表示されない」ことが大きな問題でしたが、現在は「Unicodeでは扱えても、相手のシステム仕様で禁止されている」ことの方が実務上は気になります。

6. CSVは危険? 実は「CSVだからNG」ではない

ここも誤解しやすいところなので補足しておきます。CSVは単なるテキスト形式なので、UTF-8で保存し、読み込み側もUTF-8として正しく扱うのであれば、①②③を保存すること自体に問題はありません。

逆に、CSVを古いシステムへ取り込んだり、文字コードを変換したり、入力可能文字を制限したデータベースへ渡したりすると問題になることがあります。つまり注意すべきなのはCSVというファイル形式そのものではなく、その後ろにある文字コード変換やシステム間連携です。

7. 「Shift_JISなら丸数字は使えない」とも単純には言えない

さらにややこしいのが、「Shift_JIS」という言葉です。Windowsで長く使われてきたWindows-31J(CP932)はShift_JIS系の文字コードですが、Microsoft独自の拡張を含んでおり、CP932では①~⑳にもコードが割り当てられています。

例えばMicrosoftのCP932対応表では、①は0x8740からUnicodeのU+2460へ対応付けられています。そのため、「Shift_JIS系だから丸数字は必ず扱えない」と覚えてしまうのも正確ではなく、どのShift_JIS系実装なのかまで確認しないと判断できないという、なかなか面倒な話になります。

実務では「Shift_JIS」と書かれていても、実際にはWindows-31J(CP932)を意味していることが珍しくありません。このあたりは別の記事にしてもよいくらい深い話なので、今回は「Shift_JISという名前だけで安全・危険を決めない」と覚えておけば十分だと思います。

8. ChatGPTなどの生成AIが普通に①②③を使う時代

今回このことが気になったきっかけの一つが、生成AIです。ChatGPTなどに文章を整理してもらっていると、①②③を見出しや箇条書きの番号として普通に使ってくることがあります。

昔から「丸数字は使わない」と意識していた身としては少し違和感があるのですが、Unicodeを前提に考えれば、AIが①②③を通常の文字として出力すること自体は特におかしくありません。ただし、AIはその文章を後でe-Govへ貼り付けるのか、業務システムへ流し込むのかまでは、こちらが伝えなければ分かりません。

業務上「機種依存文字を使わない」というルールがあるなら、AIにも「丸数字は使わず、(1)(2)(3)を使ってください」と指示しておくのが確実です。逆にブログなどで読みやすさを優先するなら、①②③を使っても現在はほとんど困らないでしょう。

9. 単なる番号付きリストなら、HTMLの<ol>を使う方法もある

なお、Webページで単純な番号付きリストを作るだけなら、①②③という文字を直接本文に書く必要はありません。HTMLなら<ol><li>を使って「これは順序のあるリストです」という構造自体を表現できます。

一方、図の中で①と②を対応させたり、本文中で「図の①を参照」のように番号そのものを記号として使いたい場合には、丸数字を直接使う方が分かりやすいこともあります。私のブログで使うとすれば、こういった用途が中心になりそうです。

10. 結局、私はどう使うことにするか

調べてみた結果、個人的には、ブログの記事や通常の文書では①②③を無理に避ける必要はもうないと考えることにしました。特に図表の中で「①→②→③」のように手順や対応関係をコンパクトに示したい場合は、丸数字の方が分かりやすいこともあります。

一方で、CSVなどのデータファイルを別システムへ渡す場合や、業務システム、電子申請などに入力する場合は別です。その場合は「Unicodeだから大丈夫」と判断せず、相手側の仕様を確認し、よく分からなければ(1)(2)(3)へ置き換えるのが安全でしょう。

図4:丸数字を使うか迷ったときの目安。公開文章では①②③を普通に使い、システム連携では入力先の仕様を確認する、くらいの使い分けが現実的です。

まとめ

「①②③は機種依存文字だから使ってはいけない」という話は、決して間違いだったわけではありません。従来の文字コードとベンダー独自拡張が混在していた時代には、実際に文字化けや別文字への変換を引き起こす可能性がありました。

しかしUnicodeとUTF-8が広く使われるようになった現在、①②③は共通のコードポイントを持つ普通の文字として扱えます。現代のWebや一般的な文書で使う分には、昔ほど神経質になる必要はなさそうです。

その一方で、e-Govのように現在でも丸数字を受け付けないシステムは存在します。「絶対に使ってはいけない」から「用途と相手の仕様を見て使い分ける」へと考え方が変わった、というのが一番しっくりくる整理だと思います。

私自身もこれまで何となく避けてきましたが、今後はブログなどでは必要に応じて使っていこうと思います。ただし、システム間でデータをやり取りするときは今まで通り少し警戒するといった感じの付き合い方が、現在の①②③にはちょうどよさそうです。

参考資料

人流データの種類を整理する:位置点・滞在・OD(出発地・到着地)・人口集計は何が違う?

自分用の備忘メモ。「人流データ」という言葉はよく使われますが、その中身は必ずしも同じではありません。GPSから取得した位置情報を指して「人流データ」と呼ぶこともあれば、駅や地域の滞在人口、店舗への来訪者数、地域間の移動を表すOD(Origin-Destination:出発地・到着地)データなども、同じように人流データと呼ばれます。

以前、日本で使える人流データまとめ(無料/研究申請/商用) という記事で、人流データをどこから入手できるのかを整理しました。また、日本で使えるロケーションインテリジェンス製品・サービスを整理してみた【2026年版】 では、携帯電話ネットワーク、GPS、アプリSDKなど、人流データを取得する方法の違いにも触れています。

今回は「どこから入手するか」「どのように取得するか」ではなく、人流データとして実際にはどのような種類のデータが存在するのかを整理してみます。

この違いを考えるうえで特に重要なのが、「GPSデータ」と「ODデータ」のような言葉を同じ分類軸で捉えないことです。GPSは位置情報をどう取得したかを表す言葉ですが、ODは取得した位置情報などを加工・集計してどのような形のデータにしたかを表しています。人流データを理解するには、まずこの2つを切り分けて考える必要があります。

人流データには少なくとも3つの軸がある

人流データを整理するときには、少なくとも3つの異なる軸があると考えると分かりやすくなります。

1つ目は取得方式です。携帯電話ネットワーク、GPS、アプリSDK、Wi-Fi、ビーコンなど、「現実世界にいる人の位置や行動をどのような仕組みで観測したか」という違いです。

2つ目が、今回の中心テーマとなるデータ種別です。取得した位置情報を位置点として扱うのか、軌跡・移動区間にするのか、滞在や来訪というイベントに変換するのか、あるいは地域別人口やODとして集計するのか、という違いがあります。

3つ目が人数の表し方です。観測できたサンプル数をそのまま扱う場合もあれば、そのサンプルから母集団全体の人数を推計する場合もあります。同じ「この地域には1万人いる」という数字でも、観測されたサンプル数なのか、母集団へ拡大推計した人数なのかでは意味が異なります。

この記事では、このうち特に2つ目の「データ種別」を中心に整理し、最後に3つ目の「拡大推計」についても触れます。

図1:人流データでは、「どう取得したか」と「どのようなデータとして表現・加工・集計したか」を分けて考える必要がある。

たとえばGPSから取得した位置情報をもとに、移動軌跡を作ることもできますし、店舗への来訪を判定したり、地域間のODデータへ集計したりすることもできます。逆にODデータはGPSだけから作られるとは限らず、携帯電話ネットワークなど別の取得方式をもとに作られる場合もあります。

つまり、「GPSか携帯電話ネットワークか」という話と、「ODか滞在人口か」という話は別の軸なのです。

「個票」と「集計データ」を分けて考える

データ種別をさらに整理すると、大きく「個票レベルのデータ」と「集計データ」に分けることができます。

個票レベルとは、ユーザーや端末を単位として位置や行動を記録したデータです。ある時刻の位置を表す「位置点」、それらを時系列に扱った「軌跡・移動区間」、そこから判定した「滞在・訪問イベント」などが該当します。

一方、集計データは、こうした個票レベルの情報を地域や施設、時間帯などの単位にまとめたものです。「この125mメッシュには何人いたか」「この店舗には1カ月間で何人が来訪したか」「新宿から渋谷へ何人移動したか」といったデータはこちらに当たります。

図2:個票レベルでは位置点から軌跡・移動区間、滞在・訪問イベントなどが作られる。そこから用途に応じて、人口・滞在人口、来訪者集計、OD(出発地・到着地)などの集計データへ変換される。

この区別は実務上かなり重要です。人流データの仕組みを理解するためには、位置点や軌跡といった個票レベルの存在を知っておく必要があります。一方、一般的な商用人流サービスで企業ユーザーに提供されるのは、ユーザー・端末単位の個票そのものではなく、加工・集計されたデータであることが多いです。

そのため、人流データを利用する立場では、「どのような位置情報を取得しているのか」だけでなく、その位置情報がどの段階まで加工され、どの単位に集計されて提供されているのかを見る必要があります。

(1)位置点データ

人流データの最も基本的な形が、ある時刻における位置を記録した「位置点」です。概念的には、次のようなデータをイメージすると分かりやすいでしょう。

user_id | timestamp           | latitude | longitude
A001    | 2026-09-03 12:01:05 | 35.68950 | 139.69171
A001    | 2026-09-03 12:03:18 | 35.68962 | 139.69210
A002    | 2026-09-03 12:03:44 | 35.65810 | 139.70120

この段階で分かるのは、「ある端末が、ある時刻に、ある位置で観測された」ということです。その人が歩いていたのか、電車に乗っていたのか、店に滞在していたのか、といった意味までは位置点だけでは直接分かりません。

また、実際の位置情報には観測間隔のばらつきや位置誤差があります。そのため、位置点は人流分析の出発点ではありますが、通常は目的に応じてさらに加工して利用します。

なお、ここで示しているのはデータ構造を理解するための概念例です。実際のデータでは、識別子の扱いや前処理、プライバシー保護などがサービスによって異なります。

(2)軌跡・移動区間データ

同じユーザーの位置点を時間順に扱うことで、どのように移動したのかを表す「軌跡」や「移動区間」を作ることができます。

位置点が「ある瞬間にどこにいたか」を表すのに対し、軌跡・移動区間には「どこからどこへ動いたか」という時間的な連続性が加わります。そのため、移動経路や回遊、移動距離などを分析する際には、位置点よりも扱いやすい形式になります。

ただし、観測された点を単純に線で結べば正確な移動経路になるわけではありません。たとえば10分間位置情報が取得できなかった場合、その間にどの道を通ったかは分かりませんし、GPSなどの位置情報自体にも誤差があります。

したがって、軌跡・移動区間は単なる「点の集合」ではなく、位置点を時間順序も含めて移動として解釈できる形へ加工したデータと考えるのがよさそうです。

(3)滞在・訪問イベント

位置点や軌跡からさらに意味を抽出すると、「ある場所に滞在した」「ある施設を訪れた」というイベントとして表現できます。

たとえば概念的には、次のようなデータです。

user_id | place_id | arrival_time        | departure_time      | stay_minutes
A001    | SHOP123  | 2026-09-03 12:05:10 | 2026-09-03 12:27:30 | 22

この段階になると、単なる緯度・経度ではなく、「SHOP123という場所に22分滞在した」という意味が付加されています。

ここで注意したいのは、店舗付近で位置情報が観測されたことと、その店舗へ「来訪した」と判定することは同じではないという点です。店の前を通過しただけかもしれませんし、位置誤差によって実際とは少し違う場所に記録されている可能性もあります。

そのため実際には、対象施設との距離や滞在時間、施設の形状、位置精度などを考慮して「滞在」や「来訪」を判定する必要があります。滞在・訪問イベントは位置情報そのものではなく、一定のルールによって位置情報に意味を付けた加工データということになります。

ここから先は「集計データ」

ここまで挙げた位置点、軌跡・移動区間、滞在・訪問イベントは、基本的にはユーザーや端末を単位として考えるデータでした。これらを複数のユーザーについて地域や施設などの単位にまとめると、企業や研究者が一般的に「人流データ」として利用することの多い集計データになります。

代表的なのが、「人口・滞在人口」「来訪者集計」「OD(出発地・到着地)」です。ただし図2にも示したように、これらがすべて「位置点→軌跡→滞在・訪問イベント」という同じ一本道を経て作られるわけではありません。人口・滞在人口は位置情報から地域単位に集計できますし、ODは軌跡や移動区間から作ることができます。どの加工工程を経るかは、作りたいデータによって異なります。

(4)人口・滞在人口データ

人口・滞在人口データは、ある空間に、ある時間帯に、何人いたのかを集計したものです。概念的には、次のような形になります。

time             | area_id    | people
2026-09-03 12:00 | mesh_125_1 | 3250
2026-09-03 13:00 | mesh_125_1 | 3012

このデータでは、個々の人がどのような経路を通ってきたのかではなく、「この地域に何人いるのか」が主な関心になります。そのため、都市の混雑状況、商圏、観光地の人出、イベント前後の人口変化などを見るのに向いています。

集計単位には、市区町村のような行政区域だけでなく、500mメッシュや125mメッシュなどの格子、独自のポリゴンなど、さまざまなものがあります。最近では、六角形セルによって地球上の位置を扱うH3のような地理空間インデックスを分析単位として使うこともできます。

この「位置情報をどの空間単位にまとめるか」という問題については、H3とは? 地球を六角形で区切る地理空間インデックスを調べてみた でも整理しました。同じ位置情報でも、どの大きさ・形の空間へ集計するかによって見える特徴は変わります。

(5)来訪者集計データ

人口・滞在人口が「地域」を単位として集計するのに対し、「店舗」「駅」「商業施設」など特定のPOIを単位として来訪イベントを集計したものが、来訪者集計データです。

たとえば、次のような形を考えられます。

poi_id  | period  | unique_visitors | total_visits
SHOP123 | 2026-09 | 18240           | 26310

ここでは、「地域に何人いたか」ではなく、「その施設を何人が訪れたか」に焦点が移ります。さらに、居住地域や来訪頻度、曜日・時間帯などの情報と組み合わせれば、商圏や顧客行動をより詳しく分析できます。

なお、unique_visitors のようなユニーク来訪者数と、total_visits のような延べ来訪回数では意味が異なります。同じ人が1カ月に何度も訪れれば、ユニーク人数は1人でも来訪回数は複数になります。このような時間方向の集計方法によっても人流データの意味は変わります。

(6)OD(出発地・到着地)データ

ODは「Origin-Destination」の略で、出発地と到着地の組み合わせごとに、人やトリップなどの移動量を集計したデータです。

たとえば人数を集計する場合は、次のような形式になります。

origin | destination | people
新宿区 | 渋谷区      | 1250
新宿区 | 豊島区      | 870

個票レベルで「A地点からB地点へ移動した」という情報は移動区間やトリップとして扱えますが、それらを地域単位などでまとめ、「新宿区から渋谷区へ何人移動したか」といった形にしたものがODデータです。

そのため、ODはそれ自体がすでに集計された人の流れを表しています。なお、「出発地」「到着地」が何を意味するかはデータによって異なり、実際のトリップの起終点の場合もあれば、居住地と来訪地などを組み合わせた集計の場合もあります。ODデータを利用するときには、OriginとDestinationがどのように定義されているかを確認する必要があります。

ODデータは、鉄道や道路などの交通分析、都市間・地域間の移動、観光客の周遊、居住地域から商業地域への流れなど、単純な人口分布だけでは分からない「どこからどこへ」という方向性を見るのに役立ちます。

同じ「人数」でも、観測値と推計値は違う

ここまで説明してきたのは主にデータの「形」の違いでした。しかし、人流データを扱うときには、これとは別にもう一つ重要な軸があります。それが、表示されている人数が観測サンプルなのか、母集団へ拡大推計した値なのかという違いです。

図3:同じ「人数」でも、実際に観測されたサンプル数と、母集団へ拡大推計した人数では意味が異なる。図中の数値は仕組みを説明するための架空例。

たとえば、ある地域について3000人分の位置情報を観測できたとします。これはあくまで、そのデータソースで観測できた3000人であり、現実世界でその地域にいた人が3000人しかいなかったという意味ではありません。

そこでサービスによっては、属性や地域ごとの偏り、携帯電話やアプリの利用状況などを考慮し、観測したサンプルから母集団全体の人数を推計します。図3では説明のため、3000人の観測サンプルから3万人という推計人口を算出する架空例を示しています。

ここで重要なのは、「人口・滞在人口」というデータ種別と、「観測サンプルか推計人口か」という違いは別の軸であることです。同じように「この地域には1万人いた」と表示されていても、一方は観測されたサンプル数、もう一方は母集団へ拡大推計された人数かもしれません。数字だけを横に並べても、同じ意味の数字を比較しているとは限らないわけです。

人流データの種類を整理すると

ここまでの内容を表にまとめると、次のようになります。

データ種別 階層 主な単位 主に分かること 商用サービスでの扱いの傾向 拡大推計
位置点 個票 ユーザー×時刻×位置 ある時刻にどこにいたか 提供は限定的 集計時に適用する場合あり
軌跡・移動区間 個票・加工 ユーザー×時系列位置 どう移動したか 提供は限定的 集計時に適用する場合あり
滞在・訪問イベント 個票・加工 ユーザー×場所×時間 どこに滞在・来訪したか 提供は限定的 集計時に適用する場合あり
人口・滞在人口 集計 空間×時間×人数 その場所に何人いたか 比較的一般的 あり/なし
来訪者集計 集計 POI×期間×人数 施設への来訪状況 比較的一般的 あり/なし
OD 集計 出発地×到着地×移動量 地域間の移動 比較的一般的 あり/なし

この表はあくまで大まかな整理です。実際のサービスでは複数のデータ種別を組み合わせて提供する場合もありますし、元になる位置情報から独自の指標や属性を推定している場合もあります。また、どの粒度まで提供されるか、拡大推計を行うかどうかもサービスや用途によって異なります。

それでも、「人流データ」という言葉を見たときに、この表のどの段階に近いデータなのかを考えるだけで、そのデータで何ができるのかをかなり理解しやすくなります。

人流データを見るときに確認したいこと

人流データを比較するときには、いきなり「何人いるか」「サンプルが何万人あるか」と数字を見るよりも、その数字がどのように作られているかを先に確認した方がよさそうです。

まず、それがGPSや携帯電話ネットワークといった取得方式の話なのか、ODや滞在人口といったデータ種別の話なのかを区別します。そのうえで、個票なのか集計済みなのか、地域単位なのか施設単位なのか、人数は観測サンプルなのか拡大推計値なのか、と順番に確認していくとデータの性格が見えてきます。

たとえば「500mメッシュ単位で1時間ごとの滞在人口を提供するデータ」と「店舗単位で月間ユニーク来訪者数を提供するデータ」は、どちらも人流データですが、できる分析はかなり違います。同じOD形式でも、どのような元データから作られ、OriginとDestinationをどう定義し、どのように集計・推計したのかによって数字の意味は変わります。

つまり「人流データ」という名前だけで比較するのではなく、取得方式、加工段階、集計単位、人数の意味を確認することが重要です。

まとめ

「人流データ」という言葉の中には、位置点、軌跡・移動区間、滞在・訪問イベント、人口・滞在人口、来訪者集計、ODなど、異なる種類のデータが含まれています。

まず分けて考えたいのが、GPSや携帯電話ネットワークなどの取得方式と、ODや滞在人口などのデータ種別です。さらにデータ種別の中でも、ユーザーや端末を単位として扱う個票レベルと、地域や施設などの単位にまとめた集計レベルがあります。

そして集計された「人数」についても、それが実際に観測されたサンプルなのか、母集団へ拡大推計した人数なのかを確認する必要があります。同じ「1万人」という数字であっても、データが作られる過程が違えば、その意味は同じとは限りません。

つまり、人流データを見るときには、「どこの会社のデータなのか」だけではなく、何を観測し、それをどのような単位に加工・集計し、最終的にどんな数字として提供しているのかを見ることが重要です。

人流データを理解する第一歩は、「人流」という一種類のデータがあると考えるのではなく、位置情報が加工されていく過程で、目的の異なる複数のデータ種別が作られていると捉えることなのだと思います。

※本稿は筆者個人の調査・見解に基づくものであり、所属組織を代表するものではありません。

H3とは? 地球を六角形で区切る地理空間インデックスを調べてみた

自分用の備忘メモ。最近、CARTOの「PlacePulse」という地理空間AIについて調べていたところ、「H3 Resolution 7」という言葉が出てきました。最初はCARTO独自の地域区分なのかと思ったのですが、調べてみると、H3はUberが開発したオープンソースの地理空間インデックスシステムでした。

位置情報や地理空間データを扱っていると今後も目にする機会がありそうなので、H3とは何なのか、成り立ちから基本的な仕組みまで備忘メモとして整理しておきます。

H3とは

H3は、地球表面を主に六角形のセル(区画)に分割し、それぞれのセルにIDを割り当てる仕組みです。H3公式では、世界を六角形のセルに分割する「geospatial indexing system(地理空間インデックスシステム)」と説明されています。より専門的には、地球全体を一定のルールでセルに区切る Discrete Global Grid System(離散全球グリッドシステム) の一種です。(参考:H3公式ドキュメント

イメージとしては、次のようなものです。

図1:H3の基本イメージ。緯度・経度の点を、その地点を含むH3セルのIDに変換できる

「セル」というと四角いメッシュを想像しやすいですが、H3では基本的に六角形になっています。ただし、H3は単に「六角形のポリゴンを作る仕組み」ではありません。緯度・経度から、その地点を含むセルのIDを求めたり、逆にセルIDから境界ポリゴンを取得したり、隣接するセルや親子関係を調べたりできます。

緯度・経度
    ↓
H3
    ↓
その地点を含むセルのID

つまり、地球上の場所を共通のセルIDで扱えるようにする仕組みと考えると分かりやすいと思います。(参考:H3公式ドキュメント:Quickstart

H3はUberが開発した

H3という名前の会社や団体が存在するわけではなく、H3はUberが開発したオープンソースプロジェクト/技術の名前です。

Uberは配車サービスの運営で大量の位置情報を扱っています。どこに車がいるのか、どこで利用者が多いのか、どこで需要と供給が不足しているのか、といった情報を都市全体で分析する必要があるため、位置情報を扱いやすいグリッドにまとめる仕組みとしてH3が開発されました。

どこに車がいるのか
どこで利用者が多いのか
どこで需要と供給が不足しているのか

Uberが2018年に公開した技術記事では、H3を料金最適化や配車、地理データの可視化・分析などに利用していると説明しています。同年、H3はオープンソースとして公開されました。(参考:Uber Engineering:H3: Uber’s Hexagonal Hierarchical Spatial Index

現在のH3もApache License 2.0で公開されており、誰でも利用できます。コアライブラリはCで実装されていますが、PythonやJavaScriptなどさまざまな言語から利用できます。(参考:H3公式ドキュメント

なぜ四角形ではなく六角形なのか

ここで最初に疑問に思ったのが、「なぜ普通の四角いメッシュではなく、六角形なのか?」という点です。理由の一つは、周囲のセルとの距離を扱いやすいことにあります。

四角形のグリッドでは、中央のセルから見たとき、上下左右のセルと斜め方向のセルでは中心までの距離が異なります。

□ □ □
□ ■ □
□ □ □

一方、六角形の場合は、中央セルを囲む6つの隣接セルまでの中心間距離が同じになります。

   ⬡ ⬡
 ⬡  ●  ⬡
   ⬡ ⬡

図にすると違いが分かりやすくなります。

図2:四角形グリッドと六角形グリッドの近傍関係

そのため、移動や距離、近隣セルなどを分析するときに六角形は扱いやすいという特徴があります。H3公式でも、三角形や四角形では近隣セルとの距離が複数種類になるのに対し、六角形では6つの隣接セルまでの距離が等しくなることがメリットとして説明されています。(参考:H3公式ドキュメント:Aggregation

Resolution 0〜15でセルの大きさを変えられる

H3にはResolution(解像度)という考え方があります。Resolutionは0から15まであり、数字が大きくなるほどセルが細かくなります。

Resolution 0
粗い、大きなセル

       ↓

Resolution 7

       ↓

Resolution 15
細かい、小さなセル

現行のH3 4.x公式ドキュメントによると、代表的な平均セル面積は次のようになります。なお、ここで示しているのは六角形セルの平均値です。(参考:H3公式ドキュメント:Tables of Cell Statistics Across Resolutions

Resolution 平均六角形セル面積
0 約435万 km²
5 約253 km²
7 約5.16 km²
9 約0.105 km²
12 約307 m²
15 約0.895 m²

Resolution 0では地球全体がわずか122セルに分割されますが、Resolution 15になると平均セル面積は1 m²を下回ります。つまり、H3ではかなり幅広いスケールを同じ仕組みの中で扱えるわけです。

Resolutionと面積の変化をグラフにすると、セルが急速に細かくなっていくことが分かります。

図3:H3のResolutionと平均六角形セル面積。縦軸は対数目盛

今回H3を知るきっかけになったCARTOのPlacePulseでは、Resolution 7が使われています。Resolution 7の平均六角形セル面積は約5.16 km²、平均辺長は約1.41 kmです。(参考:H3公式ドキュメント:Tables of Cell Statistics Across Resolutions

H3は階層構造になっている

H3のもう一つの重要な特徴が階層構造です。粗いResolutionのセルと、より細かいResolutionのセルには親子関係があります。

概念的には、次のような関係です。

Resolution 6
       ⬡
       │
       ↓
Resolution 7
   ⬡ ⬡ ⬡
     ⬡
   ⬡ ⬡ ⬡

一段細かくなるごとに、六角形には論理的に7つの子セルが対応します。この仕組みは「aperture 7」と呼ばれます。(参考:H3公式ドキュメント:Indexing

この階層構造があるため、全国規模では粗いResolutionで集計し、都市を詳しく見るときには細かいResolutionに切り替える、といった使い分けが可能です。

ただし、一つ注意があります。H3では論理的な親子関係は正確ですが、ポリゴンとして見たときに子セルが必ず完全に親セルの内側へ収まるわけではありません。六角形をさらに完全な六角形だけで細分化することができないためです。

H3を通常の集計や分析で使う程度なら強く意識する必要はなさそうですが、「親セルを7つの子セルが完全に分割している」と理解するのは少し違うようです。(参考:H3公式ドキュメント

各セルには固有のH3 IDがある

H3では、それぞれのセルに固有のIDが割り当てられます。例えばPythonでは、次のように緯度・経度からH3セルを取得できます。

import h3

lat = 35.681236
lng = 139.767125

cell = h3.latlng_to_cell(lat, lng, 7)

print(cell)

ここでは東京駅付近の緯度・経度をResolution 7のH3セルへ変換しています。逆に、

boundary = h3.cell_to_boundary(cell)

とすれば、そのH3セルの境界を取得できます。

つまり、H3では次のように、緯度・経度とセルID、セルの境界ポリゴンを相互に扱えます。

緯度・経度
    ↓
H3 ID
    ↓
セルの境界ポリゴン

H3のセルインデックス自体は64bitの値として設計されており、その中にResolutionや基準となるセル、階層情報などが格納されています。(参考:H3公式ドキュメント:QuickstartCell Index

実はすべて六角形ではない

ここまで「H3=六角形」と書いてきましたが、厳密にはすべてのセルが六角形というわけではありません。地球のような球面を六角形だけで完全に覆うことはできないため、H3には各Resolutionで必ず12個の五角形セルが存在します。

Resolution 0の場合は、次のようになります。

六角形 110個
五角形  12個
-------------
合計   122個

Resolutionが上がってセル数が何億、何兆と増えても、五角形は常に12個です。(参考:H3公式ドキュメント:Overview

また、実際のH3セルは地球上の位置によって面積が多少異なります。そのため、「H3は完全に同じ面積の正六角形で地球を敷き詰めている」と理解するのも正確ではありません。

実用上は、「基本的に六角形で地球全体を階層的に区切ったグリッド」と覚えておくのがよさそうです。

H3は何に使えるのか

H3公式では、異なる位置情報データの結合や機械学習への利用なども用途として挙げられています。(参考:H3公式ドキュメント

実際には、例えば次のような用途が考えられます。

  • 人流や位置情報データの集計
  • 店舗・POIの分布分析
  • 商圏分析
  • 配送・物流・移動分析
  • ヒートマップ
  • 気象・環境データの集計
  • 地理空間機械学習
  • 複数の位置情報データセットの結合

中でも便利そうなのが、異なるデータをH3 IDという共通キーに変換できることです。例えば人口、店舗、人流、地価、気象といった別々のデータを同じResolutionのH3セルへ変換すれば、共通のセル単位で集計・結合できます。

人口データ ─┐
店舗データ ─┤
人流データ ─┼→ H3 Resolution 7 → 同じセル単位で集計・結合
地価データ ─┤
気象データ ─┘

緯度・経度をそのまま突き合わせるよりも、分析単位をそろえやすくなるのがH3の大きな利点の一つだと思います。

H3は「世界標準」なのか

H3はかなり汎用的に利用できる仕組みですが、ISOやOGCなどが制定した規格の名前というわけではありません。Uberが開発し、オープンソースとして公開している地理空間インデックスシステムです。

似た考え方の仕組みには、Google由来のS2やGeohashなどもあります。大まかに表すと、次のような違いです。

H3       主に六角形の階層グリッド
S2       四角形ベースの全球グリッド
Geohash  四角形の階層グリッド

そのため、H3を「世界標準のグリッド」と考えるより、「地球をセルに区切る方法はいくつかあり、その中でH3は広く利用されているオープンソース方式の一つ」と理解しておくのがよさそうです。(参考:H3公式ドキュメント

PlacePulseではH3をどう使っているのか

最後に、そもそも今回H3を調べるきっかけになったPlacePulseに戻ります。CARTOとApplied Geographic Solutionsが開発したPlacePulseでは、米国をH3 Resolution 7のセル単位で扱っています。

おおまかな流れは次のようになります。

米国
 ↓
H3 Resolution 7で分割
 ↓
人口の存在する約106万セル
 ↓
人口・所得・企業・POI・通勤・健康・気候など
数千種類の地域データ
 ↓
PlacePulse
 ↓
各セルを256次元のEmbeddingとして表現

つまりH3そのものがAIなのではなく、H3が「どの地域を一単位として扱うか」を決め、そのセルごとのデータをPlacePulseがAIでEmbedding化しているという関係です。(参考:CARTO:PlacePulse Embeddings: a Fingerprint for Every Place in the US

PlacePulseの記事を最初に読んだときには「H3 Resolution 7」がCARTO独自の仕様なのかと思いましたが、実際には次のように役割が分かれていました。

H3
=汎用的な地理空間インデックス

Resolution 7
=H3で定義されているセルの細かさ

PlacePulse
=そのセル単位で地域をEmbedding化するAIモデル

まとめ

H3について今回調べてみて、一番しっくりきたのは、「地球版の階層付き六角形メッシュ」という理解でした。

単に六角形のポリゴンを作るのではなく、地球をセルに分割し、それぞれに共通IDを割り当て、Resolutionによって粒度を変えながら、親子関係や隣接関係まで扱えるところまで含めた仕組みです。

地球をセルに分割する
+
セルに共通IDを付ける
+
Resolutionで粒度を変える
+
親子・隣接関係を扱える

位置情報を大量に分析するときにはかなり便利そうです。PlacePulseのようなGeoAIだけでなく、人口、POI、人流、店舗、地価など複数の地理空間データを共通単位で扱う際にも使えそうなので、今後実際にPythonなどから触ってみたいと思います。

参考資料