都市OSとは

都市OSの前提

2023年に発布された国土計画である「第三次国土形成計画」では以下の記述があります。

人口減少が決定的になった現代日本では、大都市型の発展を望める地方は限定され、それでも行政サービスを維持し、成長を続けるためにこれまでとは違ったモデルの構築が必要となります。当研究所では、このような現状に対応できるまちづくりに必要な理論、技術、ノウハウを調査研究することが使命ですが、バラバラに進めるのではなく、全分野に共通する基盤コンセプトとして都市OSを据えています。また、都市OS自身も理論の深化や調査や実装により得られた成果によりバージョンアップしていくものとして位置付けています。

block-beta
  columns 1
  block:g1:1
    %% columns auto (default)
    研究A 研究B 研究C 研究D 研究E 研究F ... 
  end
  d["都市OS Ver.X.X"]:1
    

加えて我々は、斉藤賢爾によるこの都市OSの記述に同意します。計算機用語でいえばカーネル、アプリケーションサービス、インターフェイス(外殻/シェル)層それぞれが統一されたコンセプトで設計されていなければなりません。しかし計算機界の外では用語も違いますし、理解の難度が高いと思われます。そこで我々のOSの定義をなるべく平易な言葉で以下に示してみます。

なぜ "OS" なのか

都市＝社会は人間活動の集まりです。その大きさは人口規模によって当然変わります。人間活動をどのような解像度で捉えるかにも依存します。10万人規模の人間活動はデータとして捉えてみるとどのようなサイズになるのでしょうか。何をデータ化するかに依りますがいずれにしても大きなデータであることは間違いないでしょう。日本社会の法人組織では目標としてDXが掲げられて久しいですが「デジタル化」は単なる過程であって、デジタル化されたデータをどのように取り扱うか、活用するかについて踏み込んで考えなければなりません。

そこで膨大なデータを扱うには同じく膨大な何かを扱う為に数十年洗練されてきた方法論を当てはめるとうまくいく仮説を立て、無限ともいえる数のファイルを扱うコンピュータの仕組みを都市に応用することを我々は考えています。その仕組みとは基本ソフトウェアである "OS" です。

まとめると、我々の定義する都市OSの基礎部分は、計算機上のOSがそうするように、まちの要素を極力シンプルに捉えることでどのような状況にも応じられるようにするデータ基盤として捉えていくという考え方です。

都市OSの役割

都市OSはデータ基盤であると同時に、都市における人・制度・コミュニティの関係を調整する "媒介装置" でもあります。すなわち、情報を単に流通させるだけではなく、申請・審査・承認・利用といった社会的プロセスのつながり(連関)を支える役割を持ちます。

この連関を表現するためのデータ単位をACTORとし、ACTORを基礎とした情報処理システムは、都市全体の交通、エネルギー、防災、環境、医療、行政サービスなど多岐に渡る分野へと応用可能です。それぞれをリアルタイムで管理・統合し、分野を跨いだデータ活用も可能で、分散協調があらかじめ前提として組み込まれたマネジメントシステムを構築できるでしょう。従来は各分野ごとに独立したシステムが運用されていましたが、都市OSではそれらを統合し、都市全体の調和が実現することを目指します。

10万人規模の都市では、住民やコミュニティが持つ自生的秩序が都市の機能を支えているという現状があります。都市OSは、この自然な秩序を尊重しつつ、デジタル技術を活用して持続可能性と効率性を向上させることを目的としています。さらに10万人では維持することが困難なインフラストラクチャー、例えば医療ヘリの運用などについては、都市OS間協調によって都市の互助関係が成立します。計算機間の協調動作、クライアント・サーバアーキテクチャ、インターネットによる疎結合など、これまでIT分野で得られたあらゆる概念や成果を都市に応用可能です。

忘れてはならないのは、都市の運営では、標準化されたルールよりもむしろ「例外」こそが日常的に発生することです。都市OSは、例外に対して柔軟に応答し、その応答の履歴を蓄積して次の改善につなげる仕組みを備えることで、自生的秩序を損なわずに都市の運用品質を高めていくことができます。

データの三層構成

2023年11月時点でのSVI構想に "データスフィアData Sphere" として描かれていたアイディアがより進化したものを総称して我々は都市OSと呼んでいます。かいつまんで言えば「データの塊にアクセスすると行政や住民やデバイス(i.e. 交通信号など)にとって必要なデータが取得でき、必要に応じて書き戻すことができる」というデータサービスです。「データの塊」が上に書いたセンサーデータおよび加工されたデータ群で都市OSの基盤です。これから説明するAPIを通じてデータ群に「アクセス」し、データ群を活用します。アクセスの方法は様々で「インターフェイス」として後述します。このような複数の層をOSに応じて整理をすると、以下のような構造を持つことになります。

都市OSで直接収集できるデータは上図のような構造をもち、これに Plateau のような外部データを併せることで、拡張性の高いアプリケーション開発が可能になると想定しています。

block
  columns 2
  a["アプリケーションレイヤー
"]:2
  blockArrowId3<["APIApplication Programming Interface"]>(up):2
  p["プラットフォームレイヤー
"]:2
block:g1:2
  columns 2
  blockArrowId5<["RAW DATA API"]>(up)
  blockArrowId4<["EXTERNAL API"]>(up)
  d["データレイヤー
"]  
  e["外部データレイヤー"]  
end
block:g2:1
    %% columns auto (default)
    センサーA センサーB センサーC センサーD センサーE ...
end
    

最下層のセンサーで収集できる生のデータを可能な限り "生" のまま記録しておき、データレイヤーでは生データと必要に応じて加工し編集されたデータを適切に使用します。加工データは生データの質や量が増えるなどした場合、再生成できるようなつくりを想定しています。重要なのは生データを保存しておくことで後々の開発、発展に対応できる状態を維持することです。

実際の都市では、上図のデータ・プラットフォーム・アプリケーションという技術的な三層に加え、申請・審査・承認・説明責任といった制度的レイヤー、コミュニティ参加や共創といった社会的レイヤーが常に重なり合っています。都市OSはこれらを切り離さずに扱い、技術と制度と社会の連関を一体として設計する点が重要です。

利点(アプリケーション開発アイディア)

都市OSは、行政視点での利便性を主眼に置いたシステムだと説明されがちですが、あらゆるデータを可能な限り保存しておき必要な時に「取って出し」できる仕組みは行政限定ではなく、居住者や非居住者の様々な立場に合わせたデータ利用が可能だということを意味し、以下のような利点を産みます。

自生的秩序を尊重した都市管理ができる

住民の自主性を活かし、データ駆動型の都市運営を最適化できる

リアルタイムのデータ共有で迅速な意思決定ができる

異分野システムの統合と調和が可能

交通・医療・エネルギー・防災などを横断的に統合し、効率性を向上させる

例: 交通データと気象データを統合し、最適な移動ルートのリアルタイム提供が可能

デジタルツイン技術を活用し、都市のシミュレーションが実施できる

より具体的には、以下のようなアプリケーション開発(一部)が可能となります。

MaaS(スマート交通)

エネルギー消費を最適化し、持続可能な都市運営を支援する

センサーネットワークからのデータを統合し防災通知

デジタルIDによる行政の効率化と市民サービスの向上

糸島の季節や時間によって最適な観光ルートを示す

個人のデータ登録でこれまでに訪れた場所は一定期間出てこない、観光地設備が新しくなったことで再び出てくるなどの設計が可能

どのような応用が為されるにしても、人間によって最終的な意思決定が行われるべきで、都市OSはその決定をあらゆる面で支援し、新たな「善きまち」を形成するためのシステムです。

都市OSにおける善について

都市OSを構想するにあたり「善」をどのように扱うかは中心的で哲学的な課題となります。しかしここでいう善は、特定の主体があらかじめ定義して与える価値ではなく、むしろ、都市を構成する規則・制度・手続き・関係の運用を通じて、後から立ち上ってくるエマージェントな性質として理解すべきものです。

その際この都市OS、とりわけSVIにおける実証の枠組みとして重要なのが「科学的である」という態度です。ここで科学的とは、単に技術を利用するという意味ではなく、再現性と因果関係に基づいて現象を記述し、介入と結果を検証可能にすることを指します。

都市OSが扱う多様なプロセス(たとえば交通・相談・申請・承認・通知・救済)が、どのような条件のもとでどのような振る舞いを示すかを記録し、同じ条件なら同じ結果が期待できるようにします。この態度によって、制度運用の透明性と説明可能性が担保されます。

しかし、科学的記述だけでは都市における善は十全には説明できません。都市の実際の運用では、標準化された手続きや想定されたデータでは扱えない、多様な例外・逸脱・特殊事情が必然的に生じます。都市OSが「善き」ものであり続けるためには、こうした例外を切り捨てるのではなく、例外への応答が制度やルールの更新へとつながる構造を備える必要があります。

すなわち、都市OSにおける善とは、固定的な規範でも数値化された指標でもなく、社会的規則・制度・運用が、例外や異議申し立てに応答し続けることによって形成されるプロセスそのものです。このプロセスを支えるのが、手続きの透明性、ログ、再審・救済のルート、アクセス権と記録の管理、説明責任の枠組みなど、都市OSに組み込まれた制度的・技術的な連関Relation(=媒介Mediation)の設計です。これは特定のKPIで善を測るという発想ではなく、更新されうる構造を設計するという発想です。

graph TD
    %% 都市OSにおける科学的循環と善の生成

    subgraph A[科学的な記述と検証の層]
        I[介入/政策・制度の実行] --> O[観測/データ収集]
        O --> R[記録/ログ・メタデータ]
        R --> AN[分析/因果関係の検討]
        AN --> EV[評価/効果とバイアスの検証]
    end

    subgraph B[ 運用構造から立ち上る善の層 ]
        EV --> NORM[運用ルール・規則の修正案]
        NORM --> WF[ワークフロー・手続きの更新]
        WF --> OP[日常運用/現場での実行]
        OP --> EXC[例外・逸脱・異議の発生]
        EXC --> FB[フィードバック/相談・苦情・異議申立て]
        FB --> R
    end

    %% ループの閉じ方
    OP --> O
    

科学的態度は、この連関の正しさ・偏り・効果を検証し、必要に応じて修正するための基盤を提供します。一方で、例外や異議に対する応答可能性は、制度を硬直化させず、都市の善が運用を通じて更新され続けるための「ゆとり」をつくります。両者が組み合わさったとき、都市OSは善を外部から定めるのではなく、都市の構造と運用の中から善が生まれ続ける条件そのものを実装したシステムとなるはずです。

graph TD
    %% 例外と異議から立ち上る善の構造

    CASE[個々の事例/ケース] --> PROC[標準手続きの適用]
    PROC -->|うまく収まる| DONE[完了/想定内の処理]

    PROC -->|収まらない| EXC[例外・逸脱・困難]
    EXC --> CH[相談・異議申立て・苦情]
    CH --> HAND[担当者・調整会議による判断]
    HAND --> LOG[判断過程と理由の記録]
    LOG --> REV[ルール・基準の見直し検討]
    REV -->|採用| RULEUPD[ルール/ガイドラインの更新]
    RULEUPD --> PROC

    REV -->|不採用/保留| MON[モニタリング継続]

    %% 善の所在
    classDef good fill:#e0f7e9,stroke:#2e7d32,color:#1b5e20;
    RULEUPD:::good
    LOG:::good
    

この図で示されているのは、善が"どこかの誰かの頭の中にある値"ではなく、"ログ・見直し・ルール更新の構造"として実装されるという概念です。

奥出直人による「都市OSにおける善は運用条件であるという論考」をご覧ください。例外だらけのイベントに対して応答し続ける機能と、その応答の蓄積がノウハウ・ルールとして運用されることそのものが善き仕組み(都市OS)なのだということがアリストテレスを参照しながら明確に述べられています。

インターフェイスについて

都市OSが人間社会に実装される以上、インターフェイスは最重要課題だと思われます。2022年以降、ChatGPTのおかげで我々はシステムとのやりとりはまず自然言語が良いということに気付かされ、その言語はすごい速度で洗練されていっています。また、マルチモーダルと呼ばれているさまざまな感覚、具体的には聴覚や視覚、おそらく将来的には嗅覚や触覚の入力が都市OS(まずロボットが受け取ることになるのでしょうか)に取り込まれ、それぞれの人にとって自然で快適なインターフェイスとなるはずです。技術発達を予想しながらその時その時の最適なインターフェイスを使っていくということが我々のスタンスです。これらのインターフェイスは、単に利便性のためだけではなく、市民と制度の間の媒介を円滑にし、多様な利用者が手続きにアクセスできるようにすることを目的として設計されます。都市OSのUIは、技術だけでなく社会的公平性Fairnessを支える仕組みでもあります。

セキュリティ

都市OSでは生データの蓄積がシステムの基盤となるということは繰り返し述べて来ました。しかし言うまでもなくプライバシー情報は守られなければなりません。個人が特定できないはずのデータの解像度を上げていくと個人が特定できてしまうというような例も存在します。ここでは「どのようなデータが集められるか」ということと「集められたデータがどのように管理されるか」に分けて解説します。

どのようなデータが集められるか

現在糸島SVIでは始まりの地に於いて農地の地中温度の時系列データを集める実験をしています。温度センサーは埋設されている位置を深度(高さ)情報を含めて記録し、"とにかく蓄積"していきます。また同じ始まりの地でセンサーポールというセンサーが多数埋め込まれた電柱のようなものが設置されていて、気温や周辺音声情報が記録でき、カメラが付いているポールではビデオ情報も取得できる状況になっています。通常、センサーは防犯や防災の目的で設置されることが多いですが、SVIではデータ群をそのような防犯防災に役立てるだけでなく、住民の利便性やまちの価値を高めるための、あらゆる応用を検討します。その時その時で記録媒体の限界や処理速度の限界があるので、切り詰めるタイミングやその方法も検討します。

集められたデータがどのように管理されるか

初期にはコンピュータ上のOSに習い、あらゆるデータはオーナー、グループ、それ以外からのアクセス(公開)に対して、読み、書き、実施の可能、不可能の権限を設定します。このような仕組みのことをパーミッションと呼びます。実際のユースケースに応じてグループ権限の粒度やコンピュータの世界でも拡張されている「実施」パーミッションなどについて、実社会の使用に耐えるかどうかを検討し、改良の余地がないか探究していきます。発展するパーミッションの仕組みが基になって、例えばイチ居住者が公開情報へのアクセスで今の出かけ先の気温がわかるのはもちろん、個人情報の中の"ワードローブの中のこのコート"(システムも含めて他の誰もこの情報にはデフォルトではアクセスできない)を着ていくと快適ですよ、といった情報提供が可能になります。ワードローブの中のような個人情報は些細なことでもどこまでも守られるべきで、この例では居住者自身が「公開」パーミッションをコートに与えることで、都市OSが「読める」ようになり、提案できるようになります。

つまり、アクセス権の設定は単なる技術的制御ではなく、「誰がどの情報にアクセスし、どの判断を行うのか」という制度的責任のデザインでもあります。都市OSはアクセス権の操作履歴を記録し、説明責任やガバナンスの基盤として活用できるようにする必要があります。

まとめ

都市OSとは、単にデータの流通を効率化する基盤ではなく、都市における多様な行為者と制度をつなぎ、そのつながり(連関)を運用可能な形に整えるための "媒介のOS" なのです。

最終更新: 2026年01月07日 23時45分