スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会 最終報告書

令和2年 9⽉
スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会⽬次＜スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会＞ メンバー

3

＜スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会＞ 開催⽇

3

1. はじめに4

1.1 スーパーシティのあるべき姿

4

1.2 語句の定義

6

1.3 本報告書の位置づけと使い⽅

8

1.4 意義と効果

8

1.5 相互運⽤性に関する基本原則（プリンシプル）

10

1.6 スマートシティの業務ドメインと主体

11

2. スマートシティにおける連携レイヤー

12

2.1 各連携レイヤーにおいて考慮すべき相互運⽤性

132.2 “ビルディングブロック”⽅式によるシステムの構築

142.3 各層における必要実施事項

16

戦略・政策層における実施事項

16

ルール層における実施事項

18

組織層における実施事項

18

ビジネス層における実施事項

19

機能層における実施事項

20

データ層における実施事項

22

データ連携層における実施事項

23

アセット層における実施事項

24

セキュリティ基軸における実施事項

25

3. APIについて

27

3.1 APIの定義と意義

27

3.2 APIの開放性設計指針

29

3.3 APIカタログの実装について

30

3.4 データモデルおよびAPIに関する情報の公開⽅法

30

追補: Society 5.0定義レイヤとの対応

32

スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会 概要

33

1

＜別添＞
スーパーシティ／スマートシティの進め⽅における留意点等に関する検討メンバーの意⾒

1

相互運⽤性確保のための進捗度の把握

1

提供するデータの信頼性と品質担保

1

データ連携を促す取組

3

2

＜スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会＞

メンバー

座⻑

越塚 登

東京⼤学⼤学院 情報学環⻑・教授

委員

磯総務省 情報流通⾏政局地域通信振興課⻑

同

奥井 規晶

⼀般社団法⼈ 官⺠データ活⽤共通プラットフォーム協議会 代表理事

同

坂下 哲也

⼀般財団法⼈ ⽇本情報経済社会推進協会（JIPDEC） 常務理事

同
授

櫻井美穂⼦

国際⼤学グローバル・コミュニケーション・センター 主任研究員/准教

同

重⽥ 裕彦

国⼟交通省 総合政策局モビリティサービス推進課⻑

同関

⼀般社団法⼈ Code for Japan代表理事

同

⽥丸健三郎

⽇本マイクロソフト株式会社 業務執⾏役員

同

平本 健⼆

政府CIO 上席補佐官

同

⽔野 宏治

国⼟交通省 道路局企画課評価室⻑

寿⽣

治之（肩書は令和2年3⽉31⽇現在）＜スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会＞
l

第⼀回: 令和元年9⽉17⽇（⽕）10時〜12時

l

第⼆回: 令和元年10⽉18⽇（⾦）10時〜12時

l

第三回: 令和元年12⽉4⽇（⽔）16時〜18時

l

第四回: 令和2年2⽉20⽇（⽊）15時〜16時30分

開催⽇

31. はじめにスマートシティの概念は時代と共に変遷しています。2000年代以降に進められてきたスマー
トシティは主にエネルギーマネジメントを⽬的としたスマートコミュニティでした。これに対して、近年ではセンシング技術の進化やデバイスの低価格化、無線通信やAI技術等の急速な進歩を背景とした、都市インフラ・施設運営全体の最適化や、企業や⽣活者の利便性・快適性向
上を⽬指す、より幅広い分野のスマートシティの実現が期待されています。
少⼦⾼齢化に対応し、持続的な経済成⻑や社会課題解決を⽬指すという我が国のSociety5.0の考え⽅においても、上記のスマートシティの実現が⽬指されており、政府・⺠間通じて様々な取組が展開されています。
特に2018年には、スーパーシティ構想が打ち出されました。そこではゴール逆算型のアプロ
ーチ、ビッグデータの分野横断的な活⽤、国家戦略特区制度を活⽤した規制改⾰を⽤いた技術
実装といった考え⽅・制度活⽤により第四次産業⾰命を体現する最先端技術の都市への実装を⽬指すという内容が掲げられています。

1.1 スーパーシティのあるべき姿
未来の⽣活を前倒し実現するスーパーシティでは、様々な⽣活サービスを展開するプレイヤ
ーの協業が不可⽋です。住⺠の抱える各種の社会課題・ニーズに対して、複数の⽣活サービス
が、AIやビックデータなど、最先端の技術を活⽤して住⺠の暮らしを⽀えるためには、様々なプレイヤーが協調と競争を重ねあわせる中で、創発的にサービスを⽣み出し、利⽤者の意⾒のもとに改善・改良を重ねていく、いわゆるエコシステム環境の構築が重要となります。
この際には、政府が特定の技術を決めて推進するのではなく、できるだけ多様性を許容しながら、異なるサービス間相互の相乗効果をできる限り追求するための、データ連携を、柔軟かつ効果的に進めていく必要があります。
例えば、あるスーパーシティが、その街のデータ連携基盤の基に、⾏政、交通事業者や病院、⾒守り、福祉などのサービスが連携されている場合、最適な通院、最適な介護、緊急時の搬送など、各種サービスと交通サービスを如何に効果的に連携させるかなど、異なるサービス
間で相乗効果を追求するためには、それぞれのサービスが、どのような仕様のどのような技術を⽤いる場合であっても、⽐較的容易に、相互にデータを連携・共有できるようなデータ連携基盤の構築が重要となります。
まさに、スーパーシティでは、官⺠が提供する様々な暮らしのサービスが、健全に競争しつ
つも、サービス間相互で、必要なときに、必要なデータを連携・共有できるよう、オープンに相互接続できるデータ連携基盤を構築することが必要となります。
このため、スーパーシティでは、広く官⺠を超えて、常にオープンな連携を可能にするためのAPI（Application Programming Interface：この場合は都市インフラの持つさまざまな機能を利⽤するための電⼦的な⼿続き群）の設計と、そこでやり取りされるデータモデルの策定を、どのように進めていくかが、重要な要素となります。このガイドラインは、こうしたデー
4

都市プラットフォーム事業

・国が⽰す⼀定の基準をクリアすることで、⾃治体に対し者ても導⼊に対する抵抗感を減らすことができる（プラットフォーマー）・サービス事業者が参⼊しやすくなり、プラットフォーム
上のサービスの数や質が向上する
・他の都市プラットフォームとのデータ交換や横⽐較ができることにより、サービスに対する評価や改善がしやすくなる

国・国内の⺠間プラットフォーマーを健全な競争環境で育成できる・特定都市だけでは⼩さくなってしまう市場規模を拡⼤でき、スーパーシティ/スマートシティ市場を活性化できる・特定の予算のある地域だけでなく、⼩規模⾃治体などに対してもサービスを普及しやすくなる
・データが標準化されることにより、都市間の⽐較が容易になり、アセスメントがしやすくなる

1.2 語句の定義
オープン: 誰もがデータや活動にアクセスして利⽤する機会があり、関連する活動に参加するための⾨⼾が広く開かれていること
相互運⽤性 (interoperability) : 中⻑期にわたって、静的および動的なデータをAPI等を通じて相互にやりとりしながら、特定の施策を運⽤できること
互換性 (compatibility) : 2つあるいはそれ以上のシステムあるいはコンポーネントが情報を交換でき、かつ交換した情報を利⽤できる能⼒（IEEEにおける相互運⽤性の定義1と同義）
API: あるサービスやアプリケーションにおいて、その機能や管理するデータ等を他のサービス
やアプリケーションから呼び出して利⽤するための接続仕様等
狭義のオープンAPI: 厳格な要件や契約などを必要とせず、外部から誰でもアクセス可能なAPIのこと

1

IEEEにおける原⽂は “the ability of two or more systems or components to exchange information andto use the information that has been exchanged”. - 『IEEE Standard Computer Dictionary: A Compila
tion of IEEE Standard Computer Glossaries』

6

広義のオープンAPI: 特定の団体が外部に公開するAPIのこと。アクセスする際に契約⾏為などが交わされるケースも含む
スマートシティ: ⾃治体⾏政および都市が有するサービスや機能をデジタル化し、住⺠とともにイノベーションを起こすことによって、住⺠の⽣活の質を向上するとともに、より効果的な都市機能を提供する状態
スーパーシティ: 2018年に内閣府が打ち出したスマートシティの⼀類型。課題思考のアプロー
チ、ビッグデータの分野横断的な活⽤、国家戦略特区制度を活⽤した規制改⾰を⽤いた技術実装といった考え⽅・制度活⽤により第四次産業⾰命を体現する最先端技術の都市への実装を⽬指すもの。なお、スーパーシティにおいては、異なるスーパーシティ同⼠あるいはスーパーシ
ティ内の複数システム間をAPIで接続し、より広域な情報集約と提供を可能とすることを必須
要件とする

7

1.3 本報告書の位置づけと使い⽅
本ガイドラインは、都市の有する機能をスマートシティ化し、さらにスーパーシティを構築するにあたり、都市間・都市プラットフォーム間・サービス主体との情報連携を⾏うために必要となるAPIと、APIを通じて⽣み出されるサービスとその運⽤に関与する主体において具備するべき事柄について、スーパーシティやスマートシティの企画・実装・運営を⾏うそれぞれの参加者に向けてガイドラインとして記載するものです。

1.4 意義と効果
オープンの意義と効果
オープンであることは、スーパーシティおよびスマートシティにおいて⾮常に重要な概念となります。本ガイドラインにおいて、オープンとは、参加のための間⼝が広く公開され、そして実際に参加可能であることです。オープンな状況の元では、誰もが未来に対して意⾒を述べ、⾃分たちの未来に対して⾃分の影響を⾏使する機会が与えられます。
住⺠は誰しも、⽣きてゆくにあたって多くの課題に直⾯します。それは個⼈に起因する課題
かもしれませんし、その地域の社会構造や組織に起因するものかもしれません。スーパーシテ
ィはそれらひとつひとつの課題にフォーカスし、解決を試みるものです。その活動において、サービスの利⽤者は誰かから与えられたお仕着せの結果をただ享受するだけではなく、サービスに対して声を上げ、活動に参加し、時には⾃分でサービスを⽴ち上げることもできるようになっている必要があります。そのようにして積み上げたサービスは地域住⺠の⽣活に溶け込
み、その⼟地の住⺠に浸透した、無くてはならないものとなり得ます。
そのようなサービスを⽣み出し、運営するため、スーパーシティで実践される取り組みは、
可能な限りオープンで開かれたものである必要があります。選挙によってその⼟地の⽴法に対して声をあげることができるように、その⼟地で提供されるサービスに対しても、住⺠が声を上げ、参加を⾏う機会が確保されなくてはなりません。

相互運⽤性の意義と効果
住⺠は移動します。仕事や⼦育て、教育やスポーツ等、その理由は様々ですが、住⺠の⽣活は1つの⾃治体の中にとどまるものではなく、線的、⾯的な広がりをもつものです。また、近年頻発化・甚⼤化する災害においては、広域に複数の⾃治体が影響を受けます。
そしてまた、住⺠は⽣活する上で、⾏政だけではなく、複数のサービスを利⽤します。それらのサービスにおいて収集されるデータはそれぞれのサービスごとに最適化された形式と意味を持ちます。
そしてさらに、サービスもまた、移動します。学校の統廃合や、病院のようなインフラサー
ビスは常にそこにあり続けるわけではありません。⼈が成⻑し姿を変えるように、地域もまたその姿を変遷させます。相互運⽤性を実現することにより、住⺠は1つの事業者やサービスに8

依存することなく、同様あるいは類似のサービスを⽣活に取り⼊れ、⽣活への悪影響を防ぐことができるようになります。
都市間、都市プラットフォーム間、サービス間、そして将来の⾃分たちに対してデータを相互利⽤するにあたっては、まずはそこでやり取りされるデータのもつ意味について、データの提供者と利⽤者の間で共通の理解をもち、機械が正しくデータの持つ意味を解釈する、すなわ
ち互換性を担保する必要があります。
そのようなデータの互換性は、スーパーシティを⽀える機能の相互運⽤性の基礎となります。しかしながら、その互換性を担保するにあたっては、その都市やサービスを運営する主体
がさまざまなレイヤーにおいて、互換性を保つことに同意し、共通理解を構築し、環境を整える必要があります。こうした組織間の活動こそが、スマートシティの相互運⽤性を⾼めるために必要となります。
スマートシティは都市や地域の持つリソースを最⼤化し、効果的に利⽤します。スーパーシ
ティはそれらを分野横断的につなげ、そこで活動する住⺠の持つリソースをいかなる場所、いかなる時間においても最⼤化するものです。
スマートシティの相互運⽤性を担保するにあたって、究極的には、データ提供者とデータ利⽤者の間でデータに対して同⼀の理解をもつことによって、データを利⽤し、多様なサービス
を⽣み出すること⾃体は可能となります。しかしながら、サービス提供開始までのハードルを下げ、より多くのサービス提供者の参⼊を促すことによって、都市において新しい試みを⽣み出し、住⺠の参加を促し、よりよい品質のサービスを住⺠に提供し、質の低いサービスを競争によって淘汰することが可能となります。
そしてその競争は、未来においても起こりえます。スマートシティに関して、優れた取り組
みは世界中に⽣まれつつあり、住⺠に対して新しい価値を提供し始めています。住⺠からのフィードバックを得ず、改善の無い取り組みは、技術の陳腐化も相まって、国内外の別の事業者
によって容易に駆逐されるでしょう。しかしながら逆に、フィードバックのプロセスを獲得し、周囲の主体との相互運⽤性を⾼めることによって住⺠に浸透した取り組みは逆に、その改善プロセスを以って他地域や海外にも浸透を試みることができるようになるでしょう。
スマートシティでは、企業や団体、地⽅⾃治体だけではなく、個⼈を含め、数多くの⼈々が参画し、イノベーションを加速させます。そうした数多くの主体が相互にデータの互換性を保ち、スマートシティの相互運⽤性を担保してゆくために、本ガイドラインで定める指針を考慮することが望まれます。

91.5 相互運⽤性に関する基本原則（プリンシプル）
スーパーシティにおける取り組みの相互運⽤性を担保するにあたって、それぞれの層において考慮するべき事柄の前提として、それらのどの層においても考慮するべき、3つの基本原則が存在します。
1.

住⺠が抱える課題を解決し、便益がもたらされているかどうかを重視する

2.

データ連携では、相乗効果の追求を徹底する

3.

データの管理に透明性を持つ

1. 住⺠が抱える課題を解決し、便益がもたらされているかどうかを重視する
スマートシティにおいて利⽤されるデータは、その地域に居住する住⺠の活動によって⽣成されます。スマートシティにおいては、それら住⺠のデータが住⺠に還元され、住⺠の⽣活を改善するために利⽤されるべきです。
スーパーシティにおいても、スマートシティと同様、⽣成されるデータはそれぞれの地域において活動する住⺠の⽣活を向上させるために活⽤される必要があります。スーパーシティの取り組みによって住⺠の課題が解決され、便益がもたらされるかどうかを常に念頭に置いてください。

2. データ連携では、相乗効果の追求を徹底する
スーパーシティにおけるデータは、元来そのデータを保有している主体を離れ、異なる主体において活⽤され、住⺠に利⽤され、価値を⽣み出します。他主体のデータを活⽤する際には、そこで⽣み出される取り組みが、オープンなイノベーションとして相乗効果を発⽣させているかどうかが重要です。
データをただ取得できればよい、というような姿勢は無意味であり、時には有害でさえあります。具体的には、収集されるデータは課題を解決するための必要最⼩限であることが必要です。特に個⼈情報あるいはプライバシーに関連するデータについて、サービスの実施に不要なデータの取得または蓄積は避けるべきです。しかしながら、スマートシティにおける多様なユースケースを考えるときに、何が必要最⼩限なのかというのは難しい課題で、そこに正解はありません。そのため、何を何のためにどのように収集、共有、防護されていくのかという情報を広く公開し、透明性をあげ、住⺠の理解とフィードバックによる変更ができることが必須となります。
取り組みを検討するにあたって、何が必要なデータであるかを⼗分に吟味し、最⼩限のデー
タ連携のもとで最⼤限の価値を発揮できるかどうかを追求してください。

10

3. データの管理に透明性を持つ
スマートシティ・スーパーシティにおいて流通するデータの多くは、住⺠を由来とするものです。つまり、データの主体は住⺠であり、その利⽤に対しては各個⼈がその権利を⾏使することができるようになっていることが重要です。
個⼈を由来として発⽣する情報については、その個⼈がデータの流通をコントロール可能であるべきであり、そのデータがどのように扱われているかを適切に開⽰することができ、住⺠に対して透明性を持った運⽤が可能かどうかを念頭に置いてください。
データの管理においては、適切な同意のもと、個⼈のデータがどのように利⽤されているかが確認できるようになっていること、そして必要に応じてその利⽤について適切なオプトアウ
ト⼿段が提供されている必要があります。

1.6 スマートシティの業務ドメインと主体
スマートシティを形成する都市には、多くの業務ドメインが存在します。例えばISO 37120:
2019では、スマートシティにおいて17の業務ドメインを指定しています2。
都市の中に存在するそれぞれの業務ドメインは、その領域のなかにおいて、住⺠にサービスを提供します。スーパーシティにおいては、住⺠に対してサービスを提供する主体と、データを管理しAPIによって機能を提供する主体が概念的に分離されます。スーパーシティにおいて、サービスを提供する主体はAPI等を利⽤することによって複数の業務ドメインを分野横断し、その相乗効果によってより⾼品質のサービスを⽴ち上げ、住⺠に対してより⾼い価値を提
供します。

2

1. 経済, 2. 教育, 3. エネルギー, 4. 環境, 5. ファイナンス, 6. 消防と緊急時応答, 7. ガバナンス, 8. 健康・医療, 9. レクリエーション, 10. セーフティ, 11. シェルター, 12. 廃棄物, 13. 通信, 14. 交通, 15. 都市計画,
16. 下⽔処理, 17. 上⽔・公衆衛⽣

11

2. スマートシティにおける連携レイヤー
スマートシティにおいて主体間がデータを連結することとは、単に異なる主体間でデータのやりとりを⾏う、という意味だけではありません。異なる主体間において1つのデータを利⽤するためには、その前提条件としていくつかの観点について共通の理解を持つことが必要です。
スマートシティにおけるデータの相互運⽤のためには、データの⽣成と流通に対し、レイヤー（層）構造を想定し、レイヤー内での適切な連携活動やデータ流通が⾏われるようにします。レイヤーとはスマートシティを構成する論理的な層のことです。スマートシティにおける相互運⽤性は観点の違いにより、いくつかの層に分割することが可能です。異なる主体であっても、同じ層同⼠での連携活動やデータ流通を考えていくことで、違った観点での話が混ざるような混乱を避けることが出来るのです。層は重なり合っており、上の層は下の層をより抽象化したものだと考えます。

図表1 - スマートシティにおける連携レイヤー3

3『スマートシティリファレンスアーキテクチャ』 - "図 2.1-1 スマートシティリファレンスアーキテク
チャにおいて定義すべき事項"より引⽤

12

2.2 “ビルディングブロック”⽅式によるシステムの構築
短時間で技術⾰新が進む現代では、都市プラットフォームもその恩恵を受けるために機能毎に更新できる構成となっている必要があります。スマートシティを構成する⼀要素であるシス
テムでは、ある程度まとまった機能ごとのかたまりを”ビルディングブロック”と呼びます。ビルディングブロックの概念に沿ってシステムを実装し、ブロック間での情報のやり取りをAPIとして統⼀することにより、他のビルディングブロックや、住⺠に提供されるサービス⾃体には影響を与えることなく⼀部のブロックのみを更新できるのです。
ビルディングブロック構成は技術⾰新に対応するだけではなく、各地の事情に応じた実装が可能になる、サービス停⽌、ハッキングなどによる障害の範囲を限定することができるなどの利点もあります。また、各ビルディングブロックが独⽴していることで、新しいビルディング
ブロックを追加し都市システム全体の機能をアップグレードすることも可能です。
⼀⽅、都市システム全体をひとつのプログラムとして構成するようなプラットフォームは、
確かに⼀時的には効率が良くなるなども利点があるものの、ビルディングブロック構成で得られる多くのメリットが無くなります。公的個⼈認証等、原理的に⼊れ替えが不可能なシステム
を除き、都市プラットフォームのような巨⼤なシステムでは採⽤を控えるべきです。

ブローカー機能について
スマートシティやスーパーシティにおいては、センサー等に代表されるIoT機器から収集されるデータや、地理データ等の都市共通インフラ、その他様々な主体からそれぞれの確認・承認の下で提供される固有データ等、様々なデータが活⽤されます。
それらのデータはそれぞれの機器の管理主体によって管理・公表されていますが、そのままの⽣データは多くが正規化されていなかったり、インターネットを経由した外部向けAPIが設けられていなかったりするため、スーパーシティとして多くの主体に対して静的なデータを提供したり、APIを経由したデータ提供を⾏ったりすることが困難なことがしばしば発⽣します。
スーパーシティにおいてはそれらの課題を解決するため、原則として、ブローカー若しく
は、ブローカーと同等の機能を⽤いて対応します。ブローカーは様々な主体が提供するデータを集約し、適切な処理を経た上で公開する仕組みです。

データ連携基盤について
スーパーシティでは、ビルディングブロック⽅式を⽤いて構成され、公開されたAPIを通じてデータの集積や配信を⾏う機能をデータ連携基盤と呼称します。データ連携基盤は、様々な主体から提供されるデータを集約し、適切な形式に変換し、APIを通じて配信します。
具体的な役割については、後述するデータ連携層における実施事項を参照ください。

14

図表3 ‒ 分散型のデータ連携について

ブローカー機能利⽤時におけるデータ蓄積について
ブローカー機能あるいはそれと同等のデータ集積機能を利⽤する場合、データの仲介には⼤きく分類して2つの⽅式があります。
l データ蓄積⽅式: ブローカー内にデータを蓄積し、⼀元的に管理
l データ分散⽅式: ブローカー内にデータを蓄積せず、データが必要となる際に都度データ
提供者へのアクセスを⾏う
どちらの⽅式にも⼀⻑⼀短がありますが、スーパーシティにおいてはリアルタイム性を重視
し、かつプライバシーインパクトが懸念されるデータや個⼈情報等をブローカー機能において集積してしまう可能性を加味し、ブローカー機能あるいはそれと同等の機能においては、原則として、データ分散⽅式を利⽤します。
しかしながら、例えば地理空間情報等では、データの蓄積を⾏うことで解析等の価値が⾼くなったり、提供者から都度データを取得することによってレスポンスに課題が発⽣したりする
15

ケース等もあり、ブローカー機能としてデータの蓄積を⾏うことが必要な場合も考えられます。この場合は、匿名化、仮名化などの処理により、個⼈情報の保護に万全を期する他、セキュリティ基軸における実施事項を参考に、政府が採⽤しているガイドラインや基準を踏まえ、
リスクアセスメントおよびデータのセキュリティ対策を⼗分に⾏う必要があります。

2.3 各層における必要実施事項
本項では、スーパーシティの各層においてどのような事項を実施する必要があるかを定めます。評価にあたっては、施策およびプロジェクトとしての評価（戦略・政策層、ルール層、組織層、ビジネス層）と、システムとしての評価（機能層、データ層、データ連携層）を分離します。
スーパーシティの活動を開始するにあたって、開始時にすべての施策およびプロジェクトとしての評価⽅法等が確定している必要はありませんが、中⻑期に試みを進展させるにあたっては評価⽅法を確定させ、継続的に測定と評価を実施してゆくことが⾮常に重要となります。

戦略・政策
ルール
組織

社会的インパクト評価に基づいた、事業のインパクト測定および評価

ビジネス
機能

組織内外での情報共有、従来の都市機能と⽐較した改善度等を中⼼に測定お
よび評価

データ

採⽤する仕様に基づくデータ正規化率や、データモデルに対するフィードバ
ックプロセスの実施状況を中⼼に測定および評価

データ連携

APIに対する継続的なエラー検出や、フィードバックプロセスの実施状況を中⼼に測定および評価

アセット

本ガイドラインの範囲外
図表4 - 各層における評価⽅針の概要

戦略・政策層における実施事項
戦略・政策層は、スーパーシティにおいて都市プラットフォームから提供されるAPI、およびAPIを利⽤して提供されるサービスについて全体統括を⾏い、施策に対する最終的な責任を16

負います。この層では全体的な⽅向性とビジョンを定め、国やより広域の地域、様々な業務ドメインの⽬指す⽅向性との調整を⾏います。
スーパーシティでは、住⺠をはじめ、関与するステークホルダーが無数に存在します。それらのステークホルダーを⾒極め、サービスが提供する価値とビジョンを明確にし、⽅向性を定めることが⾮常に重要となります。この層において定めるビジョンに対してステークホルダー間の合意が得られない場合、施策の運営を続けるにあたって関係者間に認識や利害に関する齟
齬が発⽣し、⽅向性に拠り所を失います。そうした施策においては、最終的に住⺠へ提供する価値に偏りが⽣じ、不健全な状態となり得ます。
また、スーパーシティにおいては、多数のステークホルダーが関係しており、施策から直接もたらされる結果（アウトプット）から、住⺠への価値の提供という成果（アウトカム）が発⽣するまで、それなりの⻑期間を必要とすることがあります。そうしたなかで、将来⽬指すべきビジョンを掲げ、必要に応じて実施継続や⽅向修正の判断を⾏いながらも、失ってはならな
い価値を守りきることが重要です。
戦略・政策層における実施事項リスト
l “スーパーシティで実現される状態” のビジョンを定め、現状の市⺠の⾏動をどのように変容させたいのか、定義しますl

市⺠の⾏動が変容していることを測定するために利⽤する指標や統計を定義しますl

関係するステークホルダーが定める中⻑期な計画と、スーパーシティで策定するロジッ
クモデルについて整合をとりますl施策が提供する住⺠への価値について、ステークホルダー間にて合意を得る必要がありますØ

4

特に、利⽤するデータの⽣成元が住⺠である場合、住⺠への説明を⾏わなくてはいけませんl

施策の変更を⾏う際は、ビジョンの達成への影響を測定し、必要に応じて新しい指標を
適⽤します

l

施策によって発⽣する社会的なインパクトを定義し、ロジックモデルおよびインパクト
マップ4を作成するとともに、指標に関するデータの各層に取得⽅法を定めます

ロジックモデルおよびインパクトマップについては、以下2つの資料を主に参照

内閣府『社会的インパクト評価ツールキット』 https://www.npo-homepage.go.jp/uploads/h28-socialimpact-chousa-report-03.pdf
内閣府, PwCあらた有限責任監査法⼈『社会的インパクト評価実践研修 ロジック・モデル作成の⼿引き』https://www.npo-homepage.go.jp/uploads/h28-social-impact-sokushin-chousa-02.pdf

17

ルール層における実施事項
ルール層はスーパーシティに関連する法律や条例を始めとする各種ルール、規定を定め、多様な主体間の規定を定める層です。
スーパーシティは突然に完成形としての姿が発⽣するものではなく、かつ既存の都市や活動をその基盤とします。それぞれの都市はその機能を定めるために条例を定めており、時には既存のプレイヤーも多く存在します。
ルール層では、スーパーシティにおいて発⽣する既存のプレイヤーと新しいプレイヤー、あるいは既存の価値観と新しい価値観の調整を⾏い、ステークホルダー間の規約の定めや、必要に応じた既存のルールの変更、新しいルールの取り決めを⾏います。特に施策において個⼈情報を取り扱い、⾃治体間でデータの授受が発⽣する際には、各地⽅⾃治体が定める個⼈情報保護条例に都市間で差異が認められる場合が存在し、施策の開始前に精緻な議論と状況の開⽰が求められます。
加えて、取り組みの運⽤にあたって既存の法解釈の変更や古いルールの⾒直しなどが必要となるケースも起こりえます。そうしたケースに適切に対処することが可能となるよう、適切な意思決定プロセスを構築することが重要です。スーパーシティに関するルールづくりにおいては多くのステークホルダーが参加することが必須となることから、コンセンサスに基づくエリア内での⾃主的な規制によるルール設定も現実的な選択肢となりえます。
ルール層における実施事項リスト
l 実施する取り組みの適法性について、既存法令・条例との整合性を整理しますl

必要に応じて、新しい法令・条例の策定を⾏うことが推奨されますl

必要に応じて、既存の規制を緩和することが推奨されますl

また、スーパーシティの場合、実施するサービスが他都市で展開可能かどうか、他都市で定められる関連条例との互換性の確保が推奨されます

組織層における実施事項
組織層は、スーパーシティの取り組みにおいて、戦略・政策層で定められたビジョンやルール層で定められた規定を実現するため、関与する組織やコミュニティ、個⼈といった主体を表す層です。
組織層に定められる組織は、スーパーシティの取り組みを担うサービス主体や都市プラット
フォームに関与する主体だけではありません。組織層には、スーパーシティに関連するサービスの対象者となる住⺠を含む、すべてのステークホルダーが含まれるべきです。
スーパーシティの施策を開始する際には、どのような主体がステークホルダーとして参加し、それらがどのように関わり合っているかを整理してください。また、そこに含まれていな
い、将来含まれているべきステークホルダーについて検討します。
スーパーシティの取り組みに関与するデータ提供主体は、それぞれが既に保有するデータについて異なる⽬的で利⽤可能とするため、データの内容と状況に関する検討を⾏い、データが18多⽬的に利⽤可能となるよう配慮してください。また、流通させるデータについてすべてを1から作成することは避け、なるべく既存のデータを活⽤することを⼼がけてください。
なお、スーパーシティの活動に参画するにあたっては、個⼈が活動に参加することも視野に⼊れてください。特にスーパーシティの活動⾃体をオープンに⾏っていたり、オープンソース
ソフトウェアを取り⼊れた場合には、特定の組織による活動ではなく、熱意のある個⼈が参画してくることも⼗分に考えられます。スーパーシティに特化した協議会の設⽴を選択することも可能ですが、そこで必要となる役割については⼗分に検討を⾏い、設⽴する場合もその活動内容についてストラクチャー評価を⾏うことが要求されます。
また、各層における評価を⾏うためには、第三者によって構成される評価委員会を設け、中⽴的な観点から評価が⾏われることもあります。特に、結果の公開が不可能な指標を策定している場合や公共性の⾼い取り組みである場合は、こうした第三者による評価委員会を設置することを検討してください。
組織層における実施事項リスト
l スーパーシティに関係するステークホルダーの洗い出しと、ステークホルダーマップを作成しますl

関連するステークホルダーに対し、スーパーシティでどのようなインパクトとアウトカムを達成するか、ビジョンの統⼀を⾏いますl

ステークホルダー間において、データモデルの意味する内容に共通の理解をもたせますl

必要となるデータを既に保持している主体があるかどうか、⾃治体、⺠間団体、市⺠、他⾃治体も含めて調査検討を⾏い、必要に応じてデータ連携が可能か検討が推奨されますl

スーパーシティに特化した協議会を設⽴してもよいでしょうØ

ただし、その役割は⼗分検討し、活動内容と貢献実体についてストラクチャー評価を⾏うことが推奨されます

ビジネス層における実施事項
ビジネス層は、スーパーシティにおいて都市プラットフォームから提供されるAPIの提供、
およびそのAPIを利⽤したビジネスエコシステムを司り、エコシステムが持続可能な形で継続するために必要となることを⽰します。エコシステムには、都市プラットフォームから提供されるAPIだけではなく、APIを利⽤して成り⽴つ⾃⾝、あるいは第三者によるサービスの運営も含みます。
エコシステムの運⽤にあたっては、都市プラットフォームによるAPIおよびそれを利⽤するサービス群がそれ⾃体で成⻑し、持続可能となるよう、キャッシュフロー等についても検討を
⾏い、施策⾃体が将来的に経済的に⾃⽴できるようになるよう、想定を⾏ってください。その際は、公的機関等からの助成⾦や補助⾦頼りではなく、施策が可能な限り⾃⽴するビジネスであることが望ましくはあります。ただ、⾃治体も関与するスキームとして、例えば社会的イン
パクト投資（Social Impact Bond, SIB）のような⾃治体も関与する外部団体の利⽤や、ビジネ
19

ス改善地区（Business Improvement District, BID）のような資⾦調達、PPP/PFIで定める公⺠連携の仕組み等を元にしたビジネスモデルも許容されます。
また、スーパーシティのサービス受益者は、⽇本語話者および定住者だけであるとは限りません。観光などを含めた⼀時的な滞在者がサービス受益者となることも考えられます。そうした際に利⽤される表現は、ピクトグラムや多⾔語も念頭に置いた情報提供も助けとなります。
滋賀県の定める『滋賀県翻訳・多⾔語対応ガイドライン』5等も参考になるでしょう。
ビジネス層における実施事項リスト
l スーパーシティのエコシステムが将来的に持続可能となることを⽬指す、ブループリントを作成しますl

エコシステムに含まれるAPIやサービスがどのように住⺠の⽣活に寄与し、価値を⽣み出すかを明瞭化しますl

すべてのデータや機能、アセットを1から作成せず、可能であれば既存資源の利⽤を検討することが推奨されますlアセット層やデータ層等に既に存在するデータが多⽬的に利⽤可能か、検討することが推奨されます機能層における実施事項
機能層は、スーパーシティとして⾏う事業の具体的な内容に対し、取り組みにおいて対象となる事業ドメインや、その取り組みを⽀えるために必要となるステークホルダーの事業ドメインを特定し、そのサービスあるいはサービス群を定義します。機能層では、データ層で定める
データモデルと、データ連携層で定めるAPIをまとめて、1つの具体的なAPI提供サービスとして概念化します。
なお、事業ドメインは取り組みが展開される地域や事業ドメインごとに細かな相違が存在するため、同じ達成⽬的を持つ機能を異なる地域や事業ドメインに導⼊しても、全く異なった反応や評価を受けることがあります。
サービスの対象地域や事業ドメインを拡張する際、どこまで新しいステークホルダーにあわせて機能を変更するかは、スーパーシティにおけるビジネス的なエコシステムの観点が多く関与します。ただし、その際においても、取り組みを通して住⺠に対して価値が提供できているかを念頭に置き、効果を測定するようにしてください。既存の事業や規制によって実施されていたからという理由ですべての既存機能を残すことをせず、必要に応じて、既存の業務フローや⼿続きを⾒直し、ルール層へのフィードバックを⾏うなど、過度のカスタマイズを施さないことが重要です。

5

滋賀県翻訳・多⾔語対応ガイドライン: https://www.pref.shiga.lg.jp/file/attachment/18597.pdf

20機能層における実施事項リスト
l それぞれのステークホルダーが活動する事業ドメインやサービスの特定を⾏いますlAPI設計およびデータモデルに関するドキュメントやソースコードを、デベロッパーサイ
ト等を通じて組織の内外に共有しますl

業務ドメイン内の既存の取組で⾏われていた業務フローや⼿続きについて、必要性を再確認し、必要に応じてルール層へフィードバックすることが推奨されますlAPI設計およびデータモデルの、別事業ドメインにおける再利⽤性を検討することが推奨されますlAPI設計およびデータモデルから、サービス仕様およびSLA（Service Level Agreement）等の提供品質を定めることが推奨されますØ

l

開発を外部と協⼒して⾏う場合、それらを元に調達・発注仕様や、インセプションデ
ッキにおける”やらないことリスト”や”トレードオフスライダー”の内容を定めてもよいでしょう

APIサービスとして提供するデータやAPI構造が、他ドメインや地域で活⽤できるか、検討を⾏ってもよいでしょう

⾏政におけるサービスデザインの考え⽅
スーパーシティが提供する事業ドメインが⾏政サービスに関係する領域である場合は特に、以下のガイドブックが参考となります。
l

内閣官房 情報通信技術（IT）総合戦略室
Ø

サービスデザイン実践ガイドブック（β版）6

機能層における評価
機能層における評価は、組織内外に対するAPI設計やデータモデルに関する情報や実際のデータの共有度合い測定や、既存のアプローチと⽐してスーパーシティが提供する機能が改善されているかどうか、等で測定します。
具体的な指標の設定は様々ですが、例えば以下のような評価設定が⼀例として考えられま
す。

6

l

住⺠および機能利⽤者を対象とした、サービスの認知度や満⾜度、理解度等の調査

l

組織内におけるサービスの認知度や理解度等の調査

l

機能提供における費⽤対効果測定

l

サービスデザインやUXに基づいた、都市機能利⽤者の利便性向上調査（例: スーパーシティ導⼊前後でタスク達成に要した時間の⽐較や、利⽤時ドロップアウト率の測定等）

https://cio.go.jp/sites/default/files/uploads/documents/guidebook_servicedesign.pdf
21データ層における実施事項
データ層においては、データがセマンティックに利⽤可能となるよう、アセット層から提供されるIoTデータや、⾏政等の主体から提供されるベースレジストリ、様々な事業者によるサー
ビスからAPIとして公開されるデータの持つ意味を明確化し、異なる主体間においても互換性の⾼いモデルを構築することが鍵となります。
スーパーシティに関与する主体は各々、既存のデータモデルの洗い出しとそれらの関係整理
を⾏い、各モデルの持つ意味を明確化し、可能な限り公開します。また、APIを構築し、データを配布するにあたって新しくデータモデルを構築する必要がある場合は、既存のオープンな標準を可能な限り利⽤し、その利⽤者を含めてモデルの策定を⾏った上で、策定した結果を公開してください。また、独⾃にデータモデルを作成する際は必ず、利⽤者によるフィードバッ
クおよび利⽤状況をもとにモデルの⾒直しを⾏うプロセスを構築してください。
また、利⽤する標準については、デファクト標準あるいはデジュール標準のどちらを制限するものではありませんが、オープンな標準を優先的に利⽤し、やむなく新しいデータモデルを策定する場合は、既存の標準との整合性を考慮し、可能な限りデータモデルの公開を⾏ってください。特に、公的な機関からの補助や助成等が⾏われている場合は、データモデルの公開を必ず⾏うようにしてください。
なお、これらの対応の範囲や深さなど、その詳細については、実際に選定された事業者と個別によく検討を重ねた上で決定してまいります。
データ層における実施事項リスト
l 他主体とのデータ互換性を保つ必要がありますl

関連する既存データモデルの洗い出しと関係整理を⾏いますl

既存のオープンな標準（デファクト・デジュール）を可能な限り活⽤することが推奨さ
れます

l

Ø

例えば既存のオープンな標準としては、情報処理推進機構（IPA）の定める共通語彙基
盤7やEUの定めるSynchronicity8等が挙げられますØ

情報処理推進機構 社会基盤センターより発⾏されている『データの相互運⽤性向上のためのガイド - 官⺠データ活⽤社会の実現へ向けた取組みの⼿順と実例』9も参考にな
ります

APIを通じたデータモデルの定義が必要となる範囲の明確化を、それぞれのサービス事業者の実情や実態を踏まえつつ⾏いますØ

利⽤しているデータモデルの公開を⾏います

7https://imi.go.jp/goi/8

https://gitlab.com/synchronicity-iot/synchronicity-data-models

9https://imi.go.jp/info/info0015

22

Ø

l

既存データモデルに存在せず、新しく作成するデータモデルの策定と公開の場合、以下を⾏います²

最初期あるいは初期実装後など、ステークホルダーからのフィードバックをどのタイミングから受け⼊れ開始するかを検討することが推奨されます²

データモデルの議論および決定プロセスを公開し、新規参加者が改善作業に参加可能とする必要があります

データモデルに関する解説などを含むメタデータの公開を⾏います

データ層における評価
データ層における評価は、⼊⼒されているデータが利⽤する仕様や標準に基づいて正規化されていることや、データが誤っていた際にフィードバックを受ける体制があるかどうか、⾃⾝の取組を外部に公開し、広める活動によって⾏われます。
l

主に既存のオープンな標準で定められたデータモデルの場合、当該の標準に基づくことを検知するバリデータを利⽤し、データの正規化率を測定

l

データモデルの策定と改善に関するフィードバックプロセスの策定と実施lØ

APIを通じて利⽤されているデータの特定と定量的なフィードバックプロセスの状況

ØAPI利⽤者へのヒアリング、アンケート等、定性的なフィードバックプロセスの状況

ØIssue⼀覧の公開等による利⽤者からのフィードバック窓⼝の利⽤状況

新規データモデルの作成、および既存データモデルの改良に関する標準化作業への参加有無

データ連携層における実施事項
データ連携層は、APIを通じたデータの送受信に関する規定を定めます。スーパーシティに
おいては、データ連携基盤が、まさにこの役割を担うこととなります。データ連携基盤でやりとりされるデータには、データ層において規格化される、静的データセットからのデータや、IoT機器等のアセットにおいて⽣成される動的データが含まれます。
データ連携基盤に⽤いるAPIを構築するにあたっては、送受信に伴うデータの適切な変換が実施可能となるよう、採⽤しているメタデータについてはデベロッパーサイトにて必ず公開してください。
また、APIを新規に構築する場合には内閣官房情報通信技術（IT）総合戦略室より、⾏政がA
PIを公開する際の留意事項等が標準ガイドラインとして公開されています。適宜参照を⾏って
ください。
l

10

API導⼊実践ガイドブック10

https://cio.go.jp/sites/default/files/uploads/documents/1019_api_guidebook.pdf

23lAPIテクニカルガイドブック11

データ連携基盤における実施事項リスト
l APIに対する適切なセキュリティ実装（セキュリティ基軸を参照）を⾏いますl

オープンな標準（デファクト・デジュール）の活⽤
Ø

接続⽅式（例: RESTやRPC等）については、世界的な傾向を鑑み、ウェブ経由のデー
タ接続に適した形式とします。『APIテクニカルガイドブック』も参照してください

データ連携基盤における評価
データ連携基盤における評価は、採⽤する接続⽅式と仕様に基づいてエラーの無いAPIが構築されていることや、そのAPIに対して継続的なエラー検出や改善が⾏われているかどうか等
によって⾏われます。
l

実装するAPIに対して、継続的なエラー検出と改善を⾏いますØl

詳細な評価と検出⽅針については『APIテクニカルガイドブック』を参照し、利⽤する接続⽅式に沿った評価と改善を⾏います

APIの策定と改善に関するフィードバックプロセスの策定と実施を⾏いますØ

APIに対して⾏われたリクエスト種別（例: 呼び出されているパラメータ等）および呼び出し回数について集計を⾏い、利便性やセキュリティの改善に利⽤することが推奨されますØ

API利⽤者へのヒアリング、アンケート等、定性的なフィードバックプロセスの構築が推奨されますØIssue⼀覧の公開等による利⽤者からのフィードバック窓⼝の設置が推奨されますØ

データ変換のオーバーヘッド等、処理速度とシステム負荷の測定を⾏うことが推奨されます

アセット層における実施事項
アセット層は、IoT機器から収集されるセンサーデータや、別主体によるサービスあるいは
既存主体によって収集されているデータセット、⾏政等が保有するベースレジストリ等を規定します。
アセット層におけるデータセットはスーパーシティの各種サービスに広く活⽤される基礎データとなりますが、その具体的なデータモデル等については、既存の機器やサービス等において定義されているため、本ガイドラインでその詳細を定めるものではありません。
また、スーパーシティの構成によっては、主体間でデータの転送を⾏う場合、データ連携層のAPIではなく、アセット層同⼠を直接結合してデータを受け渡すケースも存在します。主に

11https://cio.go.jp/sites/default/files/uploads/documents/1020_api_tecnical_guidebook.pdf

24そうしたケースは契約に基づいた連携となり、規格化されていないデータのやりとりとなることから、本ガイドラインでの解説は割愛します。
アセット層における実施事項リスト
l 本ガイドラインの範囲外
アセット層における評価
l 本ガイドラインの範囲外

セキュリティ基軸における実施事項
スマートシティおよびスーパーシティで流通するデータには、その地域で活動する個⼈に関する情報が含まれるケースが存在します。また、スーパーシティではAPIを通じて半⾃動的に様々なサービスが連結するため、データ改ざん等のインシデントは、スーパーシティの都市プ
ラットフォームが提供するAPIとデータ、そこから派⽣する各種サービス、そして住⺠に対して破滅的な打撃をもたらしかねません。
セキュリティはすべての層において考慮されるべきであり、データ管理における透明性とセキュリティ・バイ・デザインが実践されている必要があります。本邦においてはこれまでも様々な業務ドメインにおいて、セキュリティに関するガイドラインや取り決めが公開されています。それらの⽂書を参考に、サービスにおけるセキュリティ・デザインおよびセキュリティ
実装を定めてください。
また、個⼈情報の保護と利⽤およびプライバシーインパクトへの影響の観点から、世界各地
域において施⾏される個⼈情報保護法やサイバーセキュリティ法との協調を検討し、適切な管理と保護施策を検討することが重要です。
セキュリティ基軸における実施事項リスト
l 経済産業省『サイバー・フィジカル・セキュリティ対策フレームワーク』を主に参照
し、利⽤するデータの種類と内容、セキュリティインパクトを定義しますl

適切なデータフローを設計し、システム全体としてセキュリティ・バイ・デザインに基づいたデータ保護を⾏いますl

APIの接続先については、可能な限りオープンなAPIをなることを前提として、接続可能な主体について検討を⾏いますl

世界各地域で施⾏される個⼈情報保護法やサイバーセキュリティ法等との協調が推奨されます25セキュリティおよびプライバシーに関する代表的な既存ガイドライン
l 経済産業省Øll

サイバー・フィジカル・セキュリティ対策フレームワーク12

NIST (National Institute of Standards and Technology)Ø

Cybersecurity Framework Version 1.1 13

ØPrivacy Framework: An Enterprise Risk Management Tool

Smart Factory - European UnionØ

Secure cross-company communication 14

セキュリティ基軸における評価
l Cybersecurity Framework Version 1.1l『サイバー・フィジカル・セキュリティ対策フレームワーク』
Ø

特に「第II部 ポリシー：リスク源の洗い出しと対策要件の特定」において、リスクア
セスメントの⼀環として⾏うリスクの特定、リスク分析およびリスク評価

Ø

ただし、APIがオープンAPIとして構築されている場合、そこで配布する情報については、そのデータが本来的にオープンであることを加味したリスク分析を⾏うことが重要です12https://www.meti.go.jp/press/2019/04/20190418002/20190418002-2.pdf

13

https://www.nist.gov/cyberframework/framework14

http://sf-eu.net/wp-content/uploads/2016/08/bmwi-2016-plattform-industrie-4.0-secure-cross-c
ompany-communication-en.pdf

26

3. APIについて
3.1 APIの定義と意義
APIとは前述のとおり、あるサービスの機能や管理するデータ等を他のサービスやアプリケーションから呼び出して利⽤するための接続仕様等を指し、その中でも、厳格な要件や契約などを必要とせず、外部から誰でもアクセス可能なAPIのことをオープンAPIと呼称します。
スーパーシティの基盤を作るデータ連携基盤のAPIは、都市が保有する機能を公開し、他都
市・他ドメインなどの外部主体から利⽤可能とするための重要な⼿段です。そのAPIが公開され、利⽤されることによって、データを活⽤する多様な主体が有機的に連結され、住⺠の⽣活に⾯的な、そして多様なドメインをまたがった便益を提供することが可能となります。
本ガイドラインでは、APIを、その開放度（誰がデータを利⽤可能か）の観点から、5つの種類と2つの類型に分類します。

図表5 - オープンAPIの類型 - 全銀協資料を参照し、事務局にて改変して作成
l

狭義のオープンAPI: ”Public”と”Acquaitance”の2つl

広義のオープンAPI: ”Public”と”Acquaitance”に加えて”Member”と”Partner”を含めた4
つ27

スーパーシティにおいては、サービスに関与する各主体間にてデータを転送するにあたり、
主に”データ連携層”を活⽤しデータ連携基盤を構築します。データ連携基盤では、スーパーシ
ティ間や他の主体等の外部、および都市内部や外部に存在するアセット層等との間でデータを交換するために複数の種類のAPIを配置し、それらAPIを通じた動的なデータの交換や、静的なデータの転送、標準規格に基づいたデータの適切な変換も⾏います。
データ連携基盤で活⽤するAPIは、そのAPIの接続先によって異なる接続ポリシーを求めることを許容します。データ連携基盤で活⽤するAPIは、可能な限り狭義のオープンAPIとして設置
してください。ただし、APIの接続先が、同じ管理主体の内部や、同じ事業者が展開するサービスとのAPIデータ連携である場合、必ずしも狭義のオープンAPIである必要はありません。これも含めて、詳細は、個々のデータ連携基盤を構築する際に、個別の事情も踏まえ、判断してまいります。

図表6 ‒ データ連携基盤とオープンAPIの考え⽅
他主体へのデータを転送する際には、ブローカー機能を活⽤したデータの互換性が適切に保たれる必要があり、データ層で定められる適切な標準、あるいは適切な標準規格への変換が重要となります。
28ただし、これらは、データ連携基盤を通じて、異なるサービスの間やアセット層とのデータのやりとりを⾏う場合の対応であって、各サービス事業者内部でデータを取り扱う場合や、アセット層で取得され、アセット層内のサーバに格納された⽣データなどに適⽤されるものではありません。
システム外部とのデータ連携については、『スマートシティリファレンスアーキテクチャ』における記述16も参照ください。

15

3.2 APIの開放性設計指針
スーパーシティにおけるAPIは、そのAPIが他のスーパーシティやサービス利⽤者等の外部と接続する場合、可能な限り開放性をPublicに近づけ、オープンAPI（狭義のオープンAPI）とす
るようにしてください。APIの利⽤に関する敷居をなるべく下げ、より広く利⽤者を広げることは、より住⺠の関与を引き出し、オープンなイノベーションを⽣み出すことでサービスの質を⾼めることになります。
しかしながら、個⼈情報に代表されるセンシティブなデータ等、APIで取り扱うデータの種類によっては適切なパーミッション管理やセキュリティ対策を施す必要も存在します。詳しい指針については、”セキュリティ基軸の実施事項”の項⽬を参照してください。

APIアクセストークンの利⽤について
APIの実装を⾏う際には、PublicやAcquaitanceなど狭義のオープンAPIの実装であったとしても、必要に応じてアクセストークンの実装が必要になることがあります。逆に、実証実験な
どで接続の利便性を⾼める等の理由をもとに、例えばサービスの⼀時停⽌を許容する場合や、配布するデータの完全性を低く設定している場合等、実装が不要である場合もあります。
アクセストークンを利⽤することによって、個々のユーザを適切に識別し、ユーザのもつ権限を正しく割り当てると共に、万が⼀悪意があるユーザからの攻撃が発⽣したとしても、適切な対処を（API総体としてではなく）個々に⾏うことが容易になります。また、アクセストークンによるステート管理等はAPI利⽤者側にとってもメリットの⼤きい機能であり、利⽤者の利便性を⾼めます。

15

https://www8.cao.go.jp/cstp/stmain/20200318siparchitecture.html

16『スマートシティリファレンスアーキテクチャ』における主な参照先は以下となります

7.2.1 サービス連携
7.2.6 外部データ連携
7.3. 外部連携293.3 APIカタログの実装について
スーパーシティは新しい取り組みであり、どのような技術実装や取り組みが正しいか、常に⽐較と評価が必要です。また、APIは利⽤され、利⽤者へのフィードバックが⾏われることで改善が⾏われるものです。
スーパーシティでは各取組で実装されるAPIに関して、情報の⾒つけやすさを向上させ、公開されている様々なAPIへの接続をより容易とするために、APIに関するメタデータやデベロッ
パーサイトの情報をまとめたカタログサイトの実装を⾏います。
スーパーシティの取り組みを⾏う主体は、カタログサイトから常に最新の状態を提供するため、そしてカタログサイトへの情報登録を省⼒化するため、APIに関するメタデータ等を記載
する設定ファイルの配布や、それらの情報を提供するAPIを実装しなくてはなりません。

3.4 データモデルおよびAPIに関する情報の公開⽅法
⾃治体を含む複数の主体間でデータの転送を⾏うにあたっては、そのAPIおよびデータに関する情報が、利⽤者にわかりやすい形で公開されていることが重要です。
特に、オープンAPIのうち、個⼈情報やプライバシーが関与しないデータ項⽬については可能な限りAPIに関する情報を公開し、より広い利⽤者層を受け⼊れることが求められます。
データの管理主体がAPI、静的データおよびその付帯情報（メタデータ）を公開するにあたっては、以下の観点に留意しなくてはなりません。

データの公開主体の明確化
スマートシティの実装にあたっては、⾃治体だけではなく、様々な企業や組織等の主体が活動に参加します。それぞれのプロジェクトや活動等、適切な単位をもとにAPIおよびデータの公開主体を定めなくてはなりません。市町村⾏政とは別に事務局となる主体が存在する場合、その事務局が望ましいでしょう。

APIおよび静的データの公開場所
APIおよびデータの公開主体は、インターネット上の⾃団体ウェブサイト、あるいは信頼性の⾼いソースコードリポジトリ等、利⽤する技術者にわかりやすい場所においてデベロッパー
サイト（開発者サイト）を作成し、そこでAPIに関する情報を、技術者にわかりやすい場所と形式で公開しなくてはなりません。
デベロッパーサイトにおける具体的な記述⽅法などについては、内閣官房による『API導⼊
実践ガイドブック』等も参照してください。また、APIに関する情報は可能な限り、当該デベ
ロッパーサイトに集約することが推奨されます。

30

APIに関する情報へのアクセスについて
オープンAPIのうち、開放性がPublicなAPIについては特に、より多くのオープンイノベーシ
ョンを喚起するためにも、APIに関連する情報（メタデータ等）は広く⼀般に公開し、利⽤可能としなくてはなりません。また、公⾦を利⽤した実証実験等、公共性が⾼い取組について
は、情報の公開および報告を⾏わなくてはなりません。
その他の種類（”Acquaitance”、”Member”、”Partner”）のAPIに関する情報も、必要となる
情報が過度に保護されることのないよう留意し、開発者にわかりやすい場所と形式で、なるべ
く⼀箇所に集約して情報を提供することが推奨されます。

公開するメタデータ
スーパーシティの取組を⾏う主体は、APIに関するメタデータとして、最低限、以下の情報を公開しなくてはなりません。
lAPIエンドポイント、あるいは静的データの配布URLlAPIあるいはデータの利⽤条件（例: 利⽤規約、契約の要否、利⽤制限、データ形式、データモデル解説）Ø

メタデータ⾃体を配布するAPIあるいはその情報を記述したファイルの配布を必ず有することØ

メタデータの伝送においては、原則として、設計様式としてREST、データ形式としてJSONを利⽤する。やむを得ない事由がある場合にはその理由を説明すること（なお、設計様式とデータ形式については、技術の進歩等の状況を鑑み、適宜⾒直しを実施する）

フィードバック体制の構築
利⽤者からのフィードバックをもとに、APIおよびその付帯情報を随時あるいは定期的に⾒直す窓⼝および体制を構築しなくてはなりません。

31

追補: Society 5.0定義レイヤとの対応
本ガイドラインで定めている各レイヤー構造は、他の関連する取組を参考に設定しております。
例えば、内閣府の主催したSociety 5.0重要課題ワーキンググループ・データ連携基盤サブワ
ーキンググループ17や、戦略的イノベーション創造プログラム（SIP）第2期のスマートシティ
分野アーキテクチャ構築において作成された『スマートシティリファレンスアーキテクチャ』
18
においても類似のレイヤー定義なされております。
それぞれのレイヤーの対応関係は以下のとおりです。

図表7 - Society 5.0定義レイヤとの対応

17

https://www8.cao.go.jp/cstp/tyousakai/datarenkei/1kai/siryo3.pdf

18

https://www8.cao.go.jp/cstp/stmain/a-whitepaper1_200318.pdf

https://www8.cao.go.jp/cstp/stmain/a-whitepaper2_200318.pdf

32

スーパーシティ／スマートシティの相互運⽤性の確保等に関する検討会

概要

33

34

35

別添

（参考資料）
スーパーシティ／スマートシティの進め⽅における留意点等に関する検討メンバーの意⾒

本資料は、スーパーシティ／スマートシティの進め方等に関し、政府、地方公共団体
等の関係者における今後の検討の参考として、検討メンバーから出た意見をまとめたものである。

別添

スーパーシティ／スマートシティの進め⽅における留意点
等に関する検討メンバーの意⾒
スーパーシティやスマートシティの取組はまだ新しく、また、参加するステークホルダーや地域・業務ドメインによってもベストなアプローチ⼿法は変わってきます。しかしながら、地域住⺠を含むより多くのステークホルダーの参加を促し、取組をより効果的なものとするために、いくつかの観点から必要となるであろう留意点が挙げられています。
本項⽬は、参考情報として、それらの留意点等に関する検討会メンバーの意⾒をとりまとめたものです。

相互運⽤性確保のための進捗度の把握
スーパーシティやスマートシティの相互運⽤性を保ち、より効果的にデータの互換性を保つには、各レイヤーにおいて留意すべき実施事項と、その活動に対する進捗の把握を⾏うことが望ましいと考えられます。
直接的な結果や、中⻑期的な成果の進捗を把握する⼿法の例としては、『社会的インパクト
評価ツールキット』19のようなツール集や、社会的インパクト・マネジメント・イニシアチブ（SIMI）のまとめるツールセット20、そして定量的・定性的な指標を組み合わせた成熟度評価の⼿法など、参考となる指標が公開されています。⻑期的視点においては、SDGsグローバル
指標 21やISO22、ITU-T23等が参考になる場合もあります。また、成果の範囲や計測⼿法などを検討するにあたっては、ロジックモデルやインパクトマップのようなツールも研究が進められています。

提供するデータの信頼性と品質担保
スーパーシティやスマートシティにおいて提供されるAPIや静的データの品質は、そこで提供されるサービスの品質を⼤きく左右する⾮常に重要な要素です。ただし翻って、データの品19

内閣府: 社会的インパクト評価ツールキット: https://www.npo-homepage.go.jp/uploads/h28-socialimpact-chousa-report-03.pdf
20

2020年3⽉現在、SIMIでは以下のツールキットを配布している。教育、就労⽀援、地域まちづくり、
環境教育、⽂化芸術、介護予防、⼦育て、防災、ホームレス⽀援、スポーツ、ヘルスケア、ソーシャ
ル・キャピタル21

https://www.mofa.go.jp/mofaj/gaiko/oda/sdgs/statistics/index.html

22

ISO 37122:2019 Sustainable cities and communities ̶ Indicators for smart cities: https://www.iso.org/standard/69050.html
23

ITU-T Y.4900/L.1600, Y.4901/L.1601, Y.4902/L.1602, Y.4903/L.16031別添質に対して無限の要求を⾏い、常に最⾼の可⽤性と最⾼の完全性、そして最⾼の迅速さを要求することもまた不可能です。
データの品質に関しては、それぞれの事業ドメインを中⼼として様々な基準や標準が存在しますが、その多くは、例えば正確さや迅速さ、データ粒度等について求められる基準に対し、⼗分な品質を提供できているかどうかを測定することになります。そのうえで、その品質を担保するにあたって必要となる事柄が定められています。ここで重要なことは、その求められる品質基準が公表され、その基準を満たしていることが継続的に測定されていることです。測定が継続的に⾏われ、基準を満たし続けることがすなわち、データへの信頼につながります。
スーパーシティやスマートシティにおいても、データの品質について無限の品質を担保しようとするのではなく、そこで提供されるデータの質について、メタデータやドキュメンテーシ
ョン等によって解説を⾏い、利⽤者との認識をあわせた上で利⽤してもらうことが重要です。
その上で、もしデータの品質について改善のフィードバックが利⽤者から寄せられたり、データの内容に誤りがあることが指摘された場合、それらの対応は真摯に⾏わなくてはなりません。データの利⽤者はデータを誤って使いたいわけではなく、他に適切なデータが存在しないために、代替策として利⽤していることがしばしばあります。データが品質としてカバーできていない⽤途で利⽤者がデータを使っている、ということは、利⽤者のニーズを掴む最⾼のチャンスとしてとらえられます。
品質に関するフィードバックや指摘、要望に対しては、主にデータ層やデータ連携層に関するフィードバック窓⼝と対象箇所を所管する担当者を通じ、スーパーシティの施策として取り⼊れることが可能か、検討することが推奨されます。
また、もし品質基準の誤差範囲を超えてデータが誤っていた場合、問い合わせから調査、誤りの発⾒と修正までは可能な限りすばやく⾏い、修正を⾏った旨を公表してください。
修正の期限や修正内容の公開⽅法については特に定めるものではありませんが、フィードバ
ックへの応答はコミュニケーションの重要な要素であり、真摯な対応が必要となります。また、データに誤りがあった場合、そのデータの利⽤者に影響が及ぶ可能性もあります。こうした対応の例として、例えば⽶国⾏政管理予算局（Office of Management and Budget）では、施⾏されたInformation Quality Act（Data Quality Act）24に基づいて定めるガイドライン25において、提供するデータの誤りについて指摘を受けた場合、60⽇以内に回答を⾏い、もし誤りが発⾒された場合には適切な修正を⾏うことが定められています。なお、60⽇以内は調査結果の回答であり、⼀時応答ではないことは注意してください。

24

https://www.state.gov/information-quality-act

25

https://www.state.gov/information-quality-guidelines/2

別添

データ連携を促す取組
データの連携を⾏うにあたっては、データの連携をどの単位同⼠で⾏うかを意識することが重要です。データ連携においては、⼤きく以下4つの要素を増やしてゆくことが重要です。
1.

事業ドメイン間連携

2.

活動参加者間の連携

3.

参加する地域間の連携

4.

スマートシティ・レイヤー間の連携

以下では、データ連携を促す仕組みとして、それぞれの軸においてどのような点に留意する
ことが重要であるかを解説します。
なお、以下取組について、スーパーシティの取組を開始する前にすべてを完璧に実践することは求められませんが、その取組の過程においては重要な内容となります。

データ連携を促す取組: 他事業ドメインとの連携促進
これまで触れてきたとおり、既存の都市の中には様々な事業ドメインが既に存在し、都市機能を提供しています。それら、既に存在する他の事業ドメインとの連携を促進し、API等によってつなげてゆくことは、新しいサービスを⽣み出し、オープンイノベーションを加速させる
ために⾮常に重要です。
スマートシティおよびスーパーシティにおいて、都市で元来提供されているすべてのサービスをフルスクラッチで再発明する必要はありません。必要に応じて既存のサービスを利⽤し、都市機能間サービスの相互乗り⼊れを⾏うことを検討してください。
もちろん、既存サービスがAPI提供を新しく開始することは、その既存サービスの事業計画
や組織構成、あるいは法的な枠組みによって⾮常に困難となる場合があります。しかしながら、戦略・政策層で掲げるビジョンを伝え続け、ビジネス層におけるエコシステムの⼀部として既存のサービス主体を取り込んでゆくことは⾮常に重要です。
事業ドメイン間の連携を図る前提として、それぞれの事業ドメイン内の参加者、すなわち⾏政の原課・原局や事業者らを中⼼に、スマートシティ実現に向けた検討や実装を⾃⽴的に⾏うようにしてください。事業ドメイン内で効率的に意思決定や実装を⾏い、成果を⽣むことと、事業ドメイン間で連携して共通部分の実装効率を⾼めることの両⽴が重要です。

データ連携を促す取組: 活動参加者間の連携促進
住⺠との協働環境づくり
スーパーシティやスマートシティの取り組みは、単にハコと機能を構築して終わるものではありません。そこでは、単にAPIを通じたデータを提供するだけではなく、スマートシティが3

別添提供するサービスが住⺠によって利⽤され、運⽤され、住⺠の⽣活の変容を伴う価値とインパクトを⽣み出してゆくことが肝要です。スマートシティの第⼆世代と呼ばれるこれからの社会実装においては、住⺠や⾏政、API提供者、サービス提供者に代表されるステークホルダー間の双⽅向のやりとりは、より住⺠⽣活に根付いたサービスの実現に⽋かせません。
地域での協働環境づくりを⾏うには、⼤きく3つの重要な観点があります。
1.

住⺠⽬線の重要性2.

スモールスタートからの段階的拡⼤とフィードバックプロセス

3.

コミュニケーション設計

1. 住⺠⽬線の重要性
スーパーシティやスマートシティにおいて、住⺠は単なるサービスの受益者ではありません。住⺠は都市を⽀えるデータの⽣成者でもあり、活動を⽀える⽀援者でもあり、取り組みに参加する活動者でもあります。
より多様で主体的な住⺠の参加を引き出し、APIおよびそれを基に住⺠に提供されるサービスをともに作り出してゆくことは、スーパーシティやスマートシティに⽋かせない要素です。
相互運⽤性に関する基本原則「住⺠が抱える課題を解決し、便益がもたらされているかどうかを重視する」にあるとおり、提供するAPIやサービスが住⺠に対して便益をもたらしているかを常に意識し、課題を解決することで住⺠に対する価値が⽣まれているかどうかを意識してください。
住⺠にとって価値のある事業こそが、住⺠からの関⼼を⽣み出し、住⺠による主体的な参加の第⼀歩を促します。
2. スモールスタートからの段階的拡⼤とフィードバックプロセス
スーパーシティやスマートシティに関する取り組みを開始する際には、まず⼩規模な取り組
みからスタートし、取り組みについて理解のある住⺠を増やすことによって、フィードバックを得るプロセスを着実に構築するようにしてください。得られたフィードバックによって、各層における仕様と実施内容を変更し、再度フィードバックを受けてください。
フィードバックによって取り組みが改善できるということが住⺠に⾒えることによって、参加の第⼀歩は継続的な歩みとなり、住⺠と共に先へ進む体制が整います。
もちろん、取り組みの浸透は⼀朝⼀⼣に進むものではありません。取り組みが対象とする利⽤者からのフィードバックを受けてプロセスを改善し、地域あるいは対象ドメインにおけるキーパーソンを巻き込み、地道に利⽤者を増やす必要があります。そのためには地域における活動に対して、スマートシティの各層を司る担当者は積極的に参加し、あるいはそうした場が存在しない場合は⾃ら場を設定し、活動を伝える必要があります。既に地域で存在している活動（例: IT系、まちづくり、NPO活動等）を探し、参加し、彼らからのフィードバックを元に取り組みを改善するプロセスを構築してください。
4

別添

なお浸透の過程において、いきなりすべての住⺠をまきこむことは現実的ではありません。
地域と取り組みに対して関⼼を持つ個⼈や団体と適切に連携し、段階的に関係者を増やすようにしてください。
また、コミュニティマーケティングと呼ばれる活動は、受益者を単なる消費者として扱うのではなく、取り組みを積極的に⽀えるオンラインとオフラインのコミュニティを⽣み出すこと
で取り組みの質を⾼める効果を持ちます。⼩規模な活動の開始については、タクティカル・ア
ーバニズム等の試みも参考となるでしょう。そして、スーパーシティやスマートシティの取り組みを提供する側だけではなく、取り組みに関与する住⺠とともに熱意を⽣み出すことは、その地域だけではなく、遠⽅の関係⼈⼝を⽣み出すことにも繋がります。
3. コミュニケーション設計
活動への参加については、住⺠による主体的な、そして実質的な参加を促すことが必須となります。キーパーソンに対する形式的なヒアリングや、継続的なフィードバックを得ることのできないワークショップ開催等は、市⺠と⾏政、および市⺠間の協働関係を構築することが困難です。結果として、本来必要となる市⺠の参加や、市⺠からのフィードバックを逃す可能性が⾼くなります。
スーパーシティやスマートシティは、⼀時的な取り組みではありません。住⺠との関係性構
築は終わりのないプロセスであり、そのプロセスの過程において、コミュニケーションは常に発⽣します。住⺠からのフィードバックに答えることによって住⺠にフィードバックを返し、次のフィードバックを受けてください。
最初からすべての市⺠の参加と賛同を得ることは不可能ではありますが、それでも中⻑期的
な⽬線をもって市⺠の参加者を増やすことは、結果としてよりよいフィードバックを⽣み出すこととなり、より⽣活に根付き、市⺠にとって無くてはならないサービスを作り出すことに繋がります。
住⺠との協働環境は、スーパーシティやスマートシティに関与する主体が直接住⺠と接する
ことによって⽣まれます。コミュニケーションとは、誰かに委託して買ってくることができる
ようなものではなく、⾏政職員、そして市⺠全員が⾃分ごととして取り組み続けることによって醸成されます。

APIを利⽤したサービス提供者との連携促進
APIを利⽤したサービス提供者と連携することは、官⺠の垣根を超えたAPI連携を通じてデー
タエコノミー（以下、APIエコノミー）を形成するということでもあります。
例えばAPIを使ってウェブサイトに地図を埋め込み、⾃社の場所を表⽰することはもはや当たり前になりつつありますが、こういった機能を全て⾃分たちで開発し、メンテナンスするとなると膨⼤な費⽤と開発期間がかかります。
APIエコノミーが回り始めると、既に開発されたAPIがあれば新規に開発するのではなく、A
PIを利⽤する事で調達コストを引き下げつつ、システム開発⽬的を達成出来る様になります。
調達すべきはAPIの連携と独⾃性を出したいサービスの構築だけ調達を実施すれば良い事にな5

別添り、利⽤しているAPIについても多くの要望を受けどんどん機能改善、機能追加されていく事になります。また同じような機能を利⽤しているAPI利⽤者には、同じような開発要望がある
かもしれません。そういったAPI利⽤者が共同で調達を実施する事によって、調達予算を引き下げる事が可能になります。⺠間企業はスーパーシティやスマートシティによって提供されるデータを元にAPIを開発し、特定の調達予算や開発期間に拘束される事なく開発を実施できるようになります。
このようにAPIを利⽤したサービス提供者と連携する事は⾮常に⼤きなメリットがあります。APIエコノミーを回す為には、サービス提供者がサービスを提供しやすい環境を整える事が⾮常に重要です。
APIを利⽤したサービス提供者と連携すると⾔うことは、⾃分たちが実施する調達に閉じた話にはならず、サービス提供者と協調してサービスを運⽤する事になります。その為、APIの機能を削除したり、データ仕様を連絡なしに変更したりした場合、連携先のAPI利⽤者は⼤きな影響を受ける事になります。またAPIの連携先にも利⽤者が想定される事から、1つのAPIの仕様変更が連携しているAPI全てに波及する事になります。
その為、APIの仕様（APIの仕様とAPIが取り扱うデータ仕様）をわかりやすい形で明⽰し、継続的にAPIをサービス提供し続ける事が出来る事が⾮常に⼤事です。
APIの仕様は内閣官房による『APIテクニカルガイドブック』でも触れられている通り、業界標準となっているAPI仕様の公開を⾏う事で、API利⽤者に仕様を明確に伝える事ができます。
また、API利⽤者と連携を⾏うにあたり、データにおけるIDやコード体系の活⽤が重要となってきます。API利⽤者はただ1つのAPIを利⽤するわけではなく、複数のAPIやデータをかけ合
わせ、マッシュアップすることでサービス提供を⾏うことがしばしばです。そうしたサービスを提供する際には、IDやコード体系が利⽤されていることで機械的なデータ統合が実施しやす
くなり、さらに、万が⼀、配信するデータに誤データが含まれてしまった際にもその追跡や影
響範囲特定が容易となります。

データ連携を促す取組: 参加する地域間の連携促進
スーパーシティとして複数の市町村をまたいでサービスを⾏う場合、近隣⾃治体との連携は重要な課題となります。特に、町村の住⺠は近隣の中核市までを含めた地域を⽣活圏として、複数の都市インフラを利⽤している場合があり、そうした地域におけるスーパーシティの意義
は⼤きいと⾔えます。
また、災害発⽣時においては、河川の状態等に代表される災害状況の共有や、病院・避難所等のリソース状態共有など、APIによって迅速な情報公開を⾏うことによって関係者間の連携を円滑化にし、対応を効率化することも可能です。
こうした地域間の連携を促進するにあたっては、データの正確性、API負荷、認証基盤の3つが⼤きく課題になると考えられます。ただしそれらの課題へのアプローチは、技術的な観点だ
けが課題ではありません。

6

別添

例えばロジックモデルやインパクトマップで定める⻑期アウトカムやビジョンに対して理解がされているか、提供されるAPIやサービスの品質基準が公開され、合意されているのか等も課題となります。例えば病院等のリソース共有が1⽇1回更新で⾏われているとして、その理解なくAPIを利⽤してしまうことで、不確かな情報を提供する空き情報サービスが提供されてし
まうかもしれません。
データの正確性については、「提供するデータの信頼性と品質担保」においても⾔及したとおり、できる限り正しいデータの提供を⾏うこともさることながら、APIが提供する品質について無限の要求を⾏わないよう、事前にAPIやデータのもつ制限について公開しておくことが重要です。
狭義のオープンAPIにおいては、APIの利⽤にあたって利⽤規約や約款等を結ぶことはあれ
ど、厳格な契約⾏為を介在しないため、利⽤者との明確なSLA（Service Level Agreement）を結ぶことが困難です。こうした場合は、メタデータやデベロッパーサイトにて品質に関する記述を⾏うとともに、開発者コミュニティを通じてAPIやデータを触る機会を増やし、情報に対する認知を広めることが必要です。場合によってはその上で、提供するデータの内容について
フィードバックを得ましょう。APIを利⽤する開発者は間違えたくて間違えるわけではなく、他に正しい情報がないからそのデータを利⽤するのであり、開発者に対して必要なデータを提供すればよいのです。
APIの負荷については、セキュリティ基盤柱の内容を参考に、システムの可⽤性を⾼めるための施策を⾏ってください。例えば具体的には、ITインフラ基盤における⼀時的なシステムリ
ソースの追加や、緊急時における⼀部APIの簡素化などが挙げられます。APIによってサービス間の連携を⾏っている場合、APIの停⽌はより広域の影響を及ぼします。負荷の⾒込まれる状
況が予⾒される場合、事前に対応を⾏うことができるよう、柔軟な運⽤体制を持つことが重要です。
そして認証基盤です。都市間においてデータ連携を⾏う際には、これまで挙げてきたサービスとしてのデータ連携のみならず、公的個⼈認証を含めた本⼈確認も重要な意味合いを持ちます。ただし、すべてのスーパーシティやスマートシティが個⼈情報を扱い、認証基盤機能を有する必要はありません。本⼈確認という観点において、本邦においては公的個⼈認証だけではなく、⺠間による本⼈確認サービスも提供されています26。必要とされる⽤途に応じて既存のサービスを利⽤する等、適宜柔軟な対応を⾏ってください。

26

OpenID ファウンデーション・ジャパン『サービス事業者のための本⼈確認⼿続き（KYC）に関する調査レポート (2020.01.23)』: https://www.openid.or.jp/news/oidfj_kycwg_report_20200123.pdf

7別添

データ連携を促す取組: スマートシティ・レイヤー間の連携
フラットな関係の構築と維持
スーパーシティやスマートシティの取組は多くの主体が参加し、その相互連携も⼤きな課題となります。
特に、戦略・政策層やルール層のレイヤーと、実際のAPIを提供するデータ層・データ連携層などのレイヤーの間は、発注者と受注者の関係になることもあり、バイアスのかかった構造のもとで必要なコミュニケーションがとれなくなることもしばしばです。スーパーシティやス
マートシティの取組は対象となる地域とその住⺠すべてに便益を提供するものであり、もし提供できなかったとすれば、それはその⼟地に関わる関係者すべてに不利益が及んでいることを意味します。
スーパーシティやスマートシティの取組においては、発注者・受注者が発⽣したとしても、その⼒関係に囚われることなく、フラットな関係を構築することが重要です。関係者同⼠が確
約・勇気・集中・公開・尊敬の価値基準を共有し、批判するべき⾏動は批判し、称賛するべき
⾏動は称賛しましょう。スーパーシティやスマートシティの取組は、⻑期アウトカムという共有の⽬的を達成するために⾏われる⼤きな、そして⻑期にわたる活動です。活動は常に、関係者間のフィードバックとコミュニケーションの上に成り⽴っており、そのコミュニケーションにバイアスをかけることは⻑期的な視点において極めて害悪をもたらします。
スクラムを組み、負けるときには全員が負け、であることを意識してください。

既存システム・業務フローの⾒直しスーパーシティやスマートシティの取組を⾏うにあたっては、取組に関与する様々な主体がデータを出し合い、各レイヤーの枠を超えて、改善の対象となる都市機能の実現が⾏われます。
その活動においては、各主体がこれまで活⽤していた既存のシステムや、適⽤していた業務
フローが新しい活動を阻害することがあります。例えばそれは新しいデータモデルに対応することすら不可能な古い設計思想で構築されたシステムの利⽤であったり、データを抽出することすらできない紙ベースの業務であったりします。場合によっては、特に規制産業に属する領域においては、既存の法律や規制、条例が具体的な業務の内容をすら定めていることすらあるでしょう。
スーパーシティやスマートシティの取組を⾏うにあたっては、それらの制限を所与のものとして扱わず、指標によって明らかになった状況を改善するために既存の状況へメスを⼊れることを厭わないでください。デジタルトランスフォーメーションによる成果は、1つの主体が局所最適化として達成するよりも、業務ドメイン全体を通して達成することによって、より⼤きな社会的インパクトを及ぼすことができるようになります。
それらの状況を変⾰するにあたって、状況を把握するためのデータの収集やその活⽤等は⾮常に重要な意味をもちます。事業ドメイン全体を俯瞰し、ボトルネックとなっている箇所やデータが把握できない箇所を洗い出し、その改善を⾏いましょう。データをもとにした協業にお8

別添

いて、既存のシステムや活動がよりよい結果を出⼒しないことが判明したのであれば、それはそのアプローチを変⾰するための機会ととらえられます。

データ連携を促す取組: 組織内外への教育・広報
スーパーシティやスマートシティの活動を⾏うにあたり、適切な教育や広報はすべての連携促進を押し上げる効果を持ちます。
スーパーシティやスマートシティの運営を⾏うにあたっては、取り組みを⾏う主体、特に⾏政組織において、データやAPIの持つ価値を理解し、システムの構築や運⽤に対して正しく意⾒をあげることのできる⼈材や、データに関する組織としてのリテラシーを内部で育成することが肝要です。場合によっては、期間を限定した外部⼈材の登⽤や情報統括の役職等を設置することも検討してください。
また、サービスの利⽤者となる住⺠に対しても、教育や広報は⾮常に重要な意味をもちます。特に、取り組みによってもたらされる価値が新しく馴染みのないものであったり、利⽤法
が⽣活に浸透していなかったり、⻑期アウトカムとのつながりが分かりづらかったりする場合など、住⺠がサービスの価値を理解できない場合がしばしば発⽣します。利⽤者に対して、データが利⽤されることで発⽣する価値を伝え、利⽤者の同意取得と活動への参加を促すことは⾮常に重要な活動となります。
教育は中⻑期的な活動であり、即座に成果の出る活動ではありません。指標を適切に設定し、教育の効果が表れているかの計測を継続的に実施することが望まれます。

9