都市が抱える課題は、交通渋滞や防災、上下水道の老朽化まで、分野ごとに個別で対応されてきました。それぞれの分野で情報システムが育ち、業務そのものは回るようになっています。ところが分野をまたいで人やモノの動きを捉えようとすると、システム同士がつながっていないことに気づきます。この壁を崩す仕組みとして、都市OSとデジタルツインの構想が具体化し始めています。

1. なぜいまスマートシティ・都市OSの案件が増えているのか

分野ごとに閉じたシステムが残ってきた理由

交通データと防災データを重ねて見ようとしても、形式や粒度が違い、そのままでは突き合わせられません。分野ごとのシステムはそれぞれの業務には最適化されていても、街全体の課題を横断して捉える設計にはなっていないためです。この分断を崩す動きとして、都市OSやデジタルツインの構想が具体化し始めており、実装を担うエンジニアの案件が増えています。

従来の国内データ連携基盤は、分野ごとにデータを公開・共有する仕組みが中心でした。ここに、分野間のデータを統合して運用できるようにする発想が加わった点が、これまでの取り組みと違うところです²。分野を一覧にまとめるだけでなく、分野をまたいだ需要をひとつの基盤の上でとらえ直す視点が求められています。

個別分野のシステムを深掘りする専門性よりも、分野をまたいでデータをつなぎ直す設計力のほうが、都市OSの現場では重みを増しています。Web開発やデータ連携の実務を積んできたエンジニアにとって、参入の余地がある領域といえます。

現場でよく起きるのは、交通データはCSVや専用フォーマット、防災データはGISレイヤー、上下水道データは台帳システムというように、同じ「データ」という言葉の中身がまったく違う状態です。この違いを吸収してつなぐAPIやスキーマの設計は、特定の業種知識よりも、データ連携そのものの設計経験に支えられています。項目の名前や単位を細かく確認しながら型を揃えていく地道な作業ですが、ここを丁寧にこなせるかどうかが、後工程の重ね合わせや可視化の精度を左右します。

下の図は、分野ごとに閉じたシステムが並んでいるだけでは、街全体の課題に手が届かない状態を整理したものです。

図の作成：Remogu編集部。分野ごとのデータが分断されている状態を整理したもので、統計データではありません

次の章では、この分断を崩す仕組みである都市OSそのものの姿を見ていきます。

2. 都市OSとは何か

分野を横断する統合運用という定義

「都市OS」という言葉を聞くと、特定の自治体だけが導入する専用ソフトウェアを思い浮かべるかもしれません。名前だけが先行して、実態がつかみにくい領域です。内閣府が示す整理では、都市OSは各分野に分断されていたデータを統合して運用できるようにする統合運用システムと位置づけられています¹。特定の業務アプリケーションではなく、分野をまたぐデータを流通させる基盤そのものを指しています。

この定義を踏まえると、都市OSの実装は「1つのシステムを作る仕事」ではなく「複数のシステムの間をつなぐ仕事」に近いことが見えてきます。都市OSの内側では、データ管理・統合の役割として、分野間のデータの統一フォーマット化が位置づけられています⁶。交通・防災・上下水道といった分野ごとに異なる形式で持っていたデータを、共通の形に整えたうえでやり取りできるようにする層です。ここでの実装は、API設計やデータモデリングの経験がそのまま活きる部分です。

このフォーマット統一の作業は、地味に見えて実装の負荷が大きい部分です。分野ごとに項目名や単位、更新の周期が異なるデータを、同じ意味を保ったまま共通のスキーマに落とし込む必要があるためです。データベース設計やETL処理の実務経験は、この工程でそのまま評価されるスキルになります。既存のシステムを作り替えるのではなく、間に立って変換する層を新しく設計する仕事になる点も、通常のシステム開発とは少し違う感覚です。

出典：内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）をもとに作成

従来のデータ連携基盤と都市OSの違い

都市OSと、これまでの国内データ連携基盤は、複数のデータを扱うという点では共通しています。ただし対象とする範囲や、データを統合する深さには違いがあります。従来の基盤が分野ごとの公開・共有を中心としていたのに対し、都市OSは分野間のデータを統合して運用することを前提に設計されています²。次の表は、この違いを観点ごとに整理したものです。実装を担ううえで意識しておきたい境目になります。

観点	従来のデータ連携基盤	都市OS
対象範囲	分野ごとの公開・共有が中心	分野間のデータを統合して運用2
データ形式	分野ごとに異なる形式が残りやすい	統一フォーマット化を志向6
担う役割の例	データ公開の窓口整備	分野横断のAPI設計・データ統合

都市OSが目指す先には、分野を横断したデータの重ね合わせから始まる、デジタルツインという発想があります。次の章では、この重ね合わせの仕組みを見ていきます。

3. 地理空間データ連携基盤とデジタルツイン

重ね合わせから始まるデジタルツイン

「デジタルツイン」という言葉には、街をそのままCGで再現するような、大がかりな仕組みを想像しがちです。実装の入口を探すと、どこから手をつけていいのか分かりにくく感じます。整理を見ると、デジタルツインはまず、分野を横断したデータの重ね合わせを地図上（仮想空間）で実現することから始まります³。3D CGの精巧さよりも、地理空間データ連携基盤の上でどれだけ多くの分野のデータを重ねられるかが起点になっています。

地図というありふれた基盤の上に、交通・防災・上下水道といった分野のデータを重ねていく設計こそが、デジタルツインの実装で最初に問われる仕事です。重ね合わせの次の段階として、3D化が位置づけられています。これは空間IDを用いて、地図を高さ方向に拡張したものです⁴。建物や設備の高さ方向の情報を扱えるようにすることで、地上だけでは見えない混雑や日照、電波の届き方といった課題も検討しやすくなります。

平面の地図を作り込む作業よりも、空間IDのような共通の位置の指標に沿ってデータを整理する設計のほうが、複数の分野をまたぐ場面では扱いやすくなります。地理空間データの扱いに慣れたエンジニアであれば、この設計に関わる余地は十分にあります。

実装の場面では、道路や建物、センサーの位置といった異なる出どころのデータを同じ座標系に載せ、レイヤーとして重ねられる形に整えることが土台になります。地図データや衛星測位を扱った経験があれば、この座標系の統一という工程に強みを発揮しやすくなります。重ね合わせた後の見え方を左右するのは、3D CGの精巧さではなく、どの分野のデータをどの高さの層に置くかという設計の一貫性です。

出典：内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）をもとに作成

地図と空間IDで重ね合わせと3D化の土台ができても、街の「今」は映りません。次の章では、刻々と変わるデータをどうつなぐかを見ていきます。

4. FIWAREなどで動的データをつなぐ

動的データはIoT Agentの機能で取得する

地図の重ね合わせだけでは、街は「今」を映しません。交通量や人の流れ、設備の稼働状況といった、刻々と変わるデータをどう取り込むかが次の壁になります。この動的なデータの取得については、FIWARE等のIoT Agentの機能による直接的な取得が位置づけられています⁵。センサーや機器から届くデータを、決まった形式で受け取り、都市OSの側へつないでいく役割です。

静的な地図データと違い、ここでは接続の安定性やデータの粒度をどう揃えるかという、運用に近い設計判断が求められます。仮想空間の中を作り込む設計よりも、外の世界と絶えずつながり続ける設計のほうが、この工程では重みを持ちます。

具体的には、センサー側の通信が一時的に途切れても取りこぼしなく再取得できる設計や、大量の機器から届く小さなデータを効率よく受け止める設計が求められます。IoT機器との連携や非同期処理の実装経験は、この工程で直接活きてきます。取得したデータをそのまま都市OS側に流すのではなく、異常値や欠損をどう扱うかという運用の判断も、あわせて設計しておきたい部分です。

出典：内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）をもとに作成

静的データと動的データの取り込み方の違い

都市OSが扱うデータには、地図や台帳のようにあまり変化しない静的データと、交通量や環境の値のように刻々と変わる動的データがあります。両者は更新の頻度も取り込み方も異なるため、実装で使う技術も分かれます。次の表は、この違いを整理したものです。

データ種別	具体例	取り込み方
静的データ	地図・台帳・施設情報	まとめて登録・更新
動的データ	交通量・環境の値・設備の稼働状況	FIWARE等のIoT Agentによる直接取得5

データをつなぐ土台が整ってはじめて、エンジニアが実際にどの部分を担当することになるのかが見えてきます。次の章では、案件としての関わり方を具体的に見ていきます。

5. リモート・フリーランス案件でどう関わるか

どの工程に強みを活かせるか

ここまでの仕組みを読むと、自治体や大規模なシステムインテグレーターの仕事に見え、フリーランスの案件とは縁遠く感じるかもしれません。実際の実装作業を分解すると、データ統合基盤の設計、地理空間データの連携、IoT側の接続、可視化の実装など、Web開発やデータ連携で培ってきたスキルがそのまま生きる工程に分かれています。まちづくりの専門知識を一から学ぶよりも、手元のスキルをどの工程に当てはめられるかを見極めるほうが、参画への近道になります。

例えば、これまでAPI連携やデータ基盤の構築を担当してきたエンジニアであれば、都市OS側のデータ統合の工程にそのまま関わりやすくなります。地図データや位置情報を扱ってきたエンジニアであれば、地理空間データ連携基盤の実装が近い工程です。IoT機器の接続やセンサーデータの処理に慣れているエンジニアであれば、FIWARE等の動的データ連携の工程がなじみやすい領域になります。得意な工程を起点に関わり方を組み立てる考え方が現実的です。

都市OS・デジタルツイン案件で活きるスキル領域

都市OS・デジタルツインの案件は、ひとつの職種だけで完結するものではありません。データ統合、地理空間データの連携、IoTとの接続、可視化といった工程ごとに、活きる経験が分かれています。次の表は、工程とそこで活きるスキルの対応を整理したものです。

工程	主な作業内容	活きる経験
データ統合基盤	分野間データの統合・API設計	データ連携・バックエンド開発
地理空間データ連携	地図上でのデータ重ね合わせ・空間ID対応	GIS・地理空間データの実装経験
IoT・動的データ連携	FIWARE等のIoT Agent実装・接続維持	IoT連携・API連携の実装経験
可視化・3D表示	デジタルツインの表示・UI実装	フロントエンド・3D表示の実装経験

この4つの工程のうち、どこか1つに強みがあれば十分に案件の入口になります。分野横断のシステム全体を最初から理解しておく必要はなく、担当する工程から関わり始めて、周辺の工程へ理解を広げていく進め方が現実的です。まちづくりの制度を体系立てて学ぶことよりも、担当する工程に必要な設計力を磨くことのほうが、参画までの近道になります。

リモートで進める場合は、担当する工程の入出力の形式さえ明確にしておけば、常駐して確認しなくても連携を組み立てられる場面が多くなります。オンラインでの仕様のすり合わせや、非同期のコミュニケーションに慣れていることも、実務では強みになります。分野をまたぐプロジェクトほど関係者が多くなりやすいため、認識のずれを文書やチケットに残しておく習慣も役立ちます。

Remoguはリモートワーク案件に特化したエンジニアマッチングです。地理空間データやIoT連携の実務は、常駐を前提としない設計と相性がよく、拠点を問わずに関わりやすい領域といえます。次の章で、この記事の要点と、案件を探す際の視点をまとめます。

6. まとめ

都市OSは、分野ごとに分断されていたデータを統合して運用できるようにする仕組みで¹、デジタルツインはその重ね合わせを地図上で実現するところから始まります³。3D化は、空間IDを用いて地図を高さ方向に拡張したものです⁴。動的データの連携は、FIWARE等のIoT Agentが担っています⁵。これらはひとつずつ独立した技術ではなく、データ統合から可視化までひと続きの工程として設計されています。個別の技術を1つずつ積み上げていくことが、そのまま実装力につながります。

分野をまたぐデータを扱ってきた経験も、地図やIoTに触れてきた経験も、都市OS・デジタルツインの案件では不足しているところではなく、活かせるところです。まずはRemoguで自分の経験に近い案件を眺めて、参画の条件を確かめてみましょう。

7. よくある質問

まちづくりの知識がないと難しいですか

都市OSやデジタルツインの実装は、分野ごとのデータを統合し、地図上で重ね合わせて扱う仕組みづくりが中心です¹。まちづくりの制度や政策を体系立てて学んでいなくても、データ統合や地理空間データの実装経験があれば、担当できる工程は十分にあります。自治体の制度知識よりも、複数のデータをどう連携させるかという設計の視点のほうが、実装の入り口では重視されます。用語に慣れていなくても、資料を読みながら実装を進めていくことは十分に可能です。

どんなスキルが活きますか

データ統合基盤の設計、地理空間データの連携、IoT機器とのデータ連携、デジタルツインの可視化といった工程に分かれています。バックエンド開発、GIS、IoT連携、フロントエンドのいずれかで実務経験があれば、対応する工程から関わりを始めやすくなります。工程をまたいで理解を広げたい場合は、まず自分の得意分野から関わり、周辺の技術は案件を通じて少しずつ吸収していく進め方が現実的です。無理に全工程を一度に理解しようとする必要はありません。

FIWAREやGISは必須ですか

動的データの取り込みには、FIWARE等のIoT Agentの機能が位置づけられています⁵。ただし、FIWAREの経験だけが入口とは限りません。地理空間データの重ね合わせや、API連携の実装経験からでも、担当できる工程はあります。GISツールの操作経験があれば、地理空間データの重ね合わせに関する工程にも入りやすくなります。逆にGISの経験がなくても、API連携やデータ変換の実装経験があれば、担当できる工程は残っています。

Web/データ連携の経験は活かせますか

都市OSは、分野間のデータを統合して運用できるようにする基盤で²、内部ではデータの統一フォーマット化も担われています⁶。API設計やデータ連携、データモデリングといったWeb開発の実務は、この基盤づくりのなかでそのまま活きる経験です。普段のWeb開発で培った設計の感覚は、分野をまたぐデータを扱う場面でもそのまま応用できます。新しい分野の知識は、実装を進めながら少しずつ補っていく形で十分です。

案件はフルリモートでもできますか

都市OSやデジタルツインに関わる案件も含め、Remoguでは、案件の90%以上がフルリモート可能です⁷。地理空間データの連携やIoT連携の実装は、常駐を前提としない働き方と相性がよい領域です。案件の内容や条件は時期によって変わるため、気になる案件はこまめに確認しておくと安心です。まずは公開されている案件を眺めて、自分の経験と重なる部分を探してみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）
＊2 内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）
＊3 内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）
＊4 内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）
＊5 内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）
＊6 内閣府「スマートシティリファレンスアーキテクチャ」（2025年5月）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能