“おはよう”だけで街が動く──都市サービスが統合される未来

毎朝のアプリ巡回、まだ続けますか？

朝、出かける前の10分間を思い出してみてください。

天気予報アプリを開いて、傘がいるかどうか確認する。

ゴミ出しアプリに切り替えて、今日が燃えるゴミの日か資源ゴミの日かを見る。

交通情報アプリで最寄りバスの遅延状況をチェックする。

子どもを保育園に送る日なら、園の連絡アプリで今日の持ち物を確認する。

自治会やPTAからの連絡がないか、メールボックスを念のため確認する。

全部バラバラのアプリで、全部自分から見に行かなければならない。
一つひとつは些細なことです。でも、これを毎朝繰り返していることに、ふと違和感を覚えたことはないでしょうか。天気も、ゴミ収集日も、バスの運行も、保育園の連絡も、すべて「自分が暮らす街」に関する情報です。それなのに、その情報はバラバラのアプリに散らばっていて、こちらから一つずつ取りに行かなければ手に入らない。

これが現在の「スマートシティ」の実態です。都市の側はたしかにデジタル化を進めています。でも、その恩恵を受けるために、市民の側がアプリをインストールし、それぞれに会員登録をし、毎朝それらを巡回するという作業を引き受けている。便利になったのは街であって、住民ではないのです。

第1回で取り上げた、ECサイトで買い物するたびに住所を入力し直す煩わしさを覚えているでしょうか。あれと同じ構造が、実は都市のサービス全体に広がっています。ECでは「サイトごとに会員登録」が問題でした。スマートシティでは「部署ごとにアプリ」が問題です。住所を何度も打ち込むか、アプリを何個も開くかの違いだけで、「システム側が統合されていないコストを、利用者が負担している」という構造はまったく同じです。

もし、この朝の10分間が変わったらどうでしょう。

起きて「おはよう」と声をかけるだけで、今日必要な情報が一つの声でまとめて届く。
傘が要ること、今日は資源ゴミの日であること、バスが5分遅れていること、保育園に替えの着替えを持っていく必要があること。自分から取りに行かなくても、街のほうがあなたに合わせて、必要な情報をちょうどいいタイミングで届けてくれる。

これは絵空事ではありません。必要な技術はすでに存在しています。足りないのは、それらをつなぐ「設計思想」のほうです。

なぜ、こんなにバラバラなのか

原因はシンプルです。
街のデジタルサービスは、提供する側の組織構造がそのまま反映されているからです。

ゴミ収集は環境局が担当するから、環境局がアプリを発注する。コミュニティバスは交通課だから、交通課がシステムを調達する。保育園の連絡は子育て支援課、防災情報は危機管理課。それぞれが独立した予算で、独立したベンダーに発注し、独立したシステムとして運用している。

この「縦割り」は行政に限った話ではありません。民間のサービスでも同じことが起きています。商店街のポイントカード、地域の見守りサービス、シェアサイクルの予約──提供者ごとにアカウントを作り、それぞれのアプリを入れるのが「当たり前」になっています。

結果として、市民のスマートフォンには街に関するアプリがいくつも並びますが、それらの間につながりはありません。ゴミ収集アプリは天気予報を知らないし、バスの運行アプリは保育園の場所を知らない。「今日は雨だからバスが混むかもしれない。10分早く出て、途中でゴミを出そう」──そういう、人間なら自然にやっている判断の統合を、どのアプリも代わりにやってくれません。

「デジタル化」はされたけれど、「スマート」にはなっていない。
この状態を変えるには、個々のアプリを改善するのではなく、都市のデータとサービスを横断的に結びつける仕組みが必要です。

ある朝の「統合された体験」を想像する

ここで、少しだけ未来の朝を想像してみましょう。

あなたが朝6時半に起きると、リビングのスマートスピーカーが静かに話しかけます。

「おはようございます。今日の天気は午後から雨、傘をお持ちください。今日は資源ゴミの日です。8時までに出せば間に合います。バスは通常通り運行していますが、駅前で水道工事があるため、保育園まではいつもより3分ほど余計にかかりそうです。保育園からの連絡で、今日はプール遊びがあるため水着セットが必要とのことです。」

30秒で、必要な情報がすべて揃いました。あなたはアプリを一つも開いていません。

この体験は、技術的にはどうすれば実現できるのでしょうか。ここからは、いま聞いた朝の音声が裏側でどうやって組み立てられているのかを、一つずつたどっていきます。

朝の30秒が生まれるまで

「今日は資源ゴミの日です」
──バラバラのデータをつなぐ

まず、「今日は資源ゴミの日」という情報はどこから来るのでしょうか。

ゴミ収集スケジュールは環境局のシステムに、天気予報は気象サービスに、バスの運行情報は交通事業者のシステムにあります。道路工事の情報は建設課が持っていて、保育園の連絡は園の管理システムに入っています。
ここで最初に必要なのは、バラバラの場所にあるデータを、共通の形式で取り出せるようにすることです。ポイントは、データを一カ所に集約する必要はないということ。各システムにデータを置いたまま、必要なときに必要な情報だけを参照できるようにする。第3回の製造業のデータ取引で触れた「データを囲い込まず流通させる」考え方が、ここでも活きています。

「8時までに出せば間に合います」
──時間と場所を結びつける

「資源ゴミの日」という情報だけでは、まだ足りません。「あなたの住むエリアでは8時が収集時刻」という、場所と時間の文脈が加わって初めて、「8時までに出せば間に合います」というメッセージになります。

次に必要なのは、すべてのデータに「どこで」「いつ」という座標を与えることです。ゴミの収集スケジュールに住所が紐づき、バスの遅延情報に路線と時刻が紐づき、道路工事に場所と期間が紐づく。これにより、「あなたにとって、今日、関係のある情報」だけを絞り込むことが可能になります。

ここで技術基盤として重要なのが、NGSI-LDと呼ばれるリンクトデータの標準規格です。従来のIoTデータは、センサーの値をただ記録するだけでした。NGSI-LDは、データとデータの「関係性」をグラフ構造で表現します。「バス路線A」→「経由地: 駅前」→「駅前: 工事中」→「工事期間: 今日まで」という関係のつながりを、AIが自動的にたどれるようになるのです。

「保育園まで3分余計にかかりそうです」
──意味を読み取る

「駅前で道路工事がある」と「保育園まで3分余計にかかる」の間には、人間にとっては当たり前でも、機械にとっては簡単ではない推論があります。あなたがバスで保育園に向かうこと、そのバス路線が駅前を経由すること、工事があると渋滞する可能性があること──これらを結びつけて初めて、「3分余計にかかりそう」という判断が生まれます。

ここで活躍するのが、ナレッジグラフと呼ばれる技術です。データ同士の意味的な関係を解釈し、「バス路線A」と「保育園」と「あなたの通勤経路」が関連づけられているから、道路工事の情報が「あなたの朝の移動時間に影響がある」と理解できる。個々のデータを「関係性」で結びつけて全体像を描くこの仕組みは、第3回で紹介したサプライチェーンのデータ連携と同じ原理です。

「あなたに必要な情報だけ」
──誰に何を見せるか

ここで大事な問いが出てきます。あなたの住所、通勤ルート、子どもが通う保育園──これらは個人情報です。都市のシステムがこうした情報を「知っている」とすれば、それは誰がどこまでアクセスできるのでしょうか

第1回で紹介したDID（分散型ID）とVC（検証可能なクレデンシャル）の考え方がここで重要になります。あなたのデータはあなた自身が管理し、「この情報はこのサービスにだけ開示する」と選択的に共有する。バスの遅延通知のために通勤ルートを共有しても、それが商業目的で利用されることはない。

さらに、ここではReBAC（関係性ベースのアクセス制御）と呼ばれる仕組みが機能します。従来の「管理者ならすべて見える、一般ユーザーなら何も見えない」という大雑把な権限管理ではなく、「この人はこの子の保護者だから、この子に関する保育園の連絡にはアクセスできる」という、関係性に基づいたきめ細かな制御です。

ReBACはGoogle社がZanzibarという大規模システム向けに設計したモデルに基づいています。DID/VCが「自分が何者かを証明する仕組み」だとすれば、ReBACは「証明された関係性に基づいて、何にアクセスできるかを決める仕組み」です。この二つが組み合わさることで、利便性とプライバシーを両立できます。

「おはようございます」
──人と街をつなぐ

後に、ここまでの仕組みで整理・統合された情報を、あなたに届ける段階です。

あなたが「おはよう」と言っただけで、背後ではこんなことが起きています。LLM（大規模言語モデル）があなたの発話を受け取り、「朝の出発準備に必要な情報を求めている」と意図を理解する。ここまでの仕組みを通じて必要なデータを集め、あなたに関係のある情報だけを抽出し、自然な日本語の音声として30秒にまとめて返す。

ここで重要な技術が、MCP（Model Context Protocol）です。MCPは、LLMが外部のデータソースやツールに安全にアクセスするための標準化されたプロトコルです。ゴミ収集システム、交通情報、気象データ、保育園の連絡──これらがMCPを介して「ツール」としてLLMに提供されます。LLMが直接データベースに接続するのではなく、整理されたインターフェースを経由することで、誤った情報を生成してしまう「ハルシネーション」のリスクも抑えられます。

第2回で紹介した、AIエージェントがユーザーに代わって情報収集や決済を行う仕組みを思い出してください。あのときは「AIが自分の代わりに動く」未来を描きましたが、ここではそのAIが都市のインターフェースそのものになっています。画面の中のチャットボットではなく、街と住民の間に立つ「通訳」として機能している。

そして注目すべきは、この「人と街をつなぐ」仕組みがあるからこそ、デバイスの制約から解放されるという点です。スマートスピーカーに話しかけても、スマートフォンの画面で読んでも、あるいは固定電話で聞いても、届く情報は同じです。高齢者がスマートフォンを使いこなせなくても、視覚に障害がある人が画面を見られなくても、同じ都市サービスにアクセスできる。アプリの操作方法を覚えるのではなく、ただ「話しかける」だけでいい。

もう一つの朝──この仕組みが「命を守る」とき

ここまで描いた「統合された朝」は、穏やかな日常を前提にしています。ゴミの日を教えてくれて、バスの遅延を知らせてくれる、便利で快適な仕組みです。

でも、もしある朝、状況がまったく違ったら。

「おはようございます。午前3時に震度4の地震がありました。現在、ガスの供給が一部停止しています。お住まいのエリアは安全が確認されていますが、通園ルート上の橋梁は現在点検中です。保育園は本日、臨時休園です。最寄りの一時避難所は徒歩5分の〇〇小学校です。」

同じスマートスピーカーが、同じ声で、まったく違う情報を届けています。

実は、ここまで紹介した仕組みは、日常の便利さのためだけに設計されているわけではありません。平時に「ゴミの日」を届けていた仕組みが、有事には「避難経路」を届ける仕組みに切り替わる。普段は匿名化されていたあなたの位置情報が、緊急時には家族や救助機関に共有される。アクセス制御の仕組みが、状況に応じて動的に権限を変えるからこそ可能になることです。

平時の利便性と、有事の安全。この両方を同じインフラでどう実現するのか──次回は、この「フェーズフリー」という考え方に踏み込みます。

まとめ

関連コンテンツ