第3回　自治体システム標準化・ガバメントクラウド勉強会資料

Broadcom Proprietary and Confidential. Copyright © 2024 Broadcom. All Rights
Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. Broadcom Proprietary and Confidential. Copyright © 2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. ガバメントクラウド移行の勘所と課題第3回自治体システム標準化・ガバメントクラウド勉強会中島淳之介

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 見積もりが今までの何倍にもなっているデータ連携の調整がつかないガバクラ関連のドキュメントが多すぎて、全体像が掴めない財政に理由を説明できないなにか相談したいが、誰に相談したらいいかわからない同じレベルで話をできる人がいないそもそも何ができるのかすらわからない原課・自分の上司が危機感がない

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 3 自己紹介 : 中島淳之介 https://x.com/jnakajima1982 2022年末に、ガバメントクラウドについて25記事を執筆 ✓ 公共事業全般の技術取りまとめ（中央省庁・独立行政法人・自治体等） ✓ 2020年頃からガバメントクラウドへの考察を開始 ✓ 自治体及びベンダー・地場業者とのコミュニケーションを継続 ✓ 所属会社の枠を超えて、支援を継続

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 4 「ガバメントクラウド」の最新課題、移行における検討ポイントとは？例：東京都のトレーニングの様子 1回目と2回目

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 5 移行支援のステップと実績トレーニングステップと取り組み数アドバイザー支援 22 依頼 14依頼対応済み＋8実施予定総参加団体数は100を超える AWSハンズオン 30 団体強標準化に伴うガバメントクラウド移行に関連する形での実施個別構成相談アドバイス CIO補佐官依頼複数の自治体グループ（広域がリードするケースも）で、集合型研修でスタートがほとんど（100％）単純な技術説明ではなく、今回の事業に紐づけた形が好評自分の自治体ではどうすればよいかを具体的に相談したいフェーズクラウドに対する興味が大きくなったのは良いことである反面、今のままだと間違った方向に認識されてしまうのはもったいないので、「正しいクラウドの理解と適切な利用の仕方」を学んでほしいと考えています。

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 以下の3つの支援内容を30分でご紹介します。・集合型研修（座学と実践編）・ハンズオントレーニング・個別構成相談注意：本来はそれぞれ半日から1日掛けておこなう内容のため、超ダイジェスト版になることをご承知おきください。必要に応じて、ぜひ個別に依頼していただければと思います。

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 本日の目的正しい情報を認識して、何が大切かを考え、対応策を検討・行動できるようにする

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 標準化に伴うガバメントクラウド移行について”知る”

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 9 地方公共団体の基幹業務システムの統一・標準化が解決する課題と期待 https://www.soumu.go.jp/main_content/000817081.pdf 地方自治体の現状及び課題 • 既存のシステムが自治体ごとに個別にカスタマイズされていることが負担 • 住民サービスを向上させる施策を迅速に全国普及させることが難しくなっている標準化後に期待すること • 人的・財政負担を軽減させることにより、迅速に提供することが可能になる • 職員のリソースを企画立案などに回すことができる • 競争環境による他社業者への移行を容易にする • スタートアップなどの参入を促す • 複数のクラウド事業者からの選択が可能になり、クラウドロックインを回避した競争環境 • 運用経費等については、平成 30 年度（2018 年度）比で少なくとも３割の削減を目指す

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 10 標準化のプラットフォームとしてのガバメントクラウドと期待するメリット https://www.soumu.go.jp/main_content/000758330.pdf - 地方自治体によるガバメントクラウドの活用について（案） - ガバメントクラウドとは? 政府共通のクラウドサービスの利用環境(IaaS/PaaS/SaaS)です。クラウドサービスの利点を最大限に活用することで、迅速、柔軟、かつセキュアでコスト効率の高いシステムを構築可能とし、利用者にとって利便性の高いサービスをいち早く提供し改善していくことを目指します。個別にセキュリティ・運用監視結果としてバラつきがある個別にコスト最適化庁内でのみ共通基盤化都度調達急な需要に応えられない過去理想セキュリティ・運用監視の共通化とにかく利用するだけで良い全自治体で共通SaaS化自治体は選択するだけ柔軟な調達必要に応じて、適切なベンダーからガバメントクラウド

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 11 そもそもガバメントクラウドとは？米国と日本の違い GovCloud 政府専用に立てつけられたパブリッククラウドサービスセキュリティ・クリアランス前提ガバメントクラウド民間企業も利用するパブリッククラウドを政府の契約や統制の仕組みを施したもの

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.

13 ガバメントクラウドの支払い・統制のスキーム関係者相関図と仕組みの概要デジタル庁自治体自治体自治体自治体自治体自治体
自治体自治体自治体クラウド事業者クラウド事業者クラウド事業者支払い支払い統制ボリュームディスカウントガバメントクラウド全てのrootアカウントがデジタル庁地方公共団体の基幹業務システム等が活用するガバメントクラウドの利用料については、クラウド利用料は地方公共団体が現行システムで負担する運用経費に相当するものであること、標準準拠システムを効率的に構築・運用していくための競争環境を適切に確保していく必要があること、ガバメントクラウド上の各種サービスへの円滑な接続など他の環境にはない利点があることを踏まえ、ガバメントクラウドの利用に応じて地方公共団体に負担を求めることについて、業務全体の運用コストや利用料等の見通しの情報を明らかにした上で、デジタル庁、総務省、財務省、地方公共団体等が協議して検討を行う。

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. ガバメントクラウド移行に際して現状と課題を”正しく認識する” 国の言うような見積もりは出てきていない業者のせいにしてOK?

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 15 自治体システム標準化にまつわる動向運用コスト3割削減デジタル社会の実現に向けた重点計画から、標準化事業のKPIである運用コスト削減の期限が消えてしまった 2023年度まで新旧デジタル社会の実現に向けた重点計画 2024年度

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 16 参考）データ連携に関する直近の流れこれは技術ではなく、決め事の問題（技術的な課題は課題で別途存在する）データ連携にあたり、データの持ち方が以下のように異なることが課題・名前が違うが同じ意味・データ型・桁等のルールが異なる・同じ名前だが意味が異なる・連携するデータ項目数に違いがある等々データ連携のための調整の経緯・ベンダー間の連携ルールを事業者間調整に（標準化の意味とは）・ベンダー×ベンダーの連携パターンができてしまうが、ベンダーに改修工数が掛かってしまう・自治体がベンダー間の調整をすることに。データ連携の今後の方針・デジタル庁として、できるだけリファレンス・事例は出しますが、今回の各自治体での調整結果を踏まえて、将来的に標準仕様書に入れる（手戻りが発生するのでは？）第２回共通機能等課題検討会 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/05577db2-dfdd-4d90- b2c1-44d94639f44e/9d5e4d8b/20240904_local-governments-common-features-issue_outline_04.pdf

17 デジタル庁におけるガバメントクラウド整備のためのクラウドサービスの提供 -令和 4 年度募集- ガバメントクラウド先行事業（基幹業務システム）における投資対効果の机上検証について https://www.digital.go.jp/assets/contents/node/info rmation/field_ref_resources/8c953d48-271d-467e- 8e4c-
f7baa8ec018b/4912aad2/20220914_news_local_go vernments_outline_03.pdf https://www.digital.go.jp/procurement/f7a497a7 -1798-4690-abdf-79d3511d1752/

18 投資対効果についての検証結果の概要(追加報告版) 8団体中6団体が、現行継続利用よりもクラウドリフトのほうが費用増加費用が上がった団体 6/8 なぜか??

採択団体地方公共団体の区分及び人口コスト区分コスト(A)：現行利用中のシステムを同規模で入れ替え・継続利用した場合コスト(B)：現行利用中のシステムをガバメントクラウドへリフトし推奨構成等と共同利用の費用按分※を採用した場合増減割合
B-A差額神戸市指定都市ランニングコスト 994,003,000 802,966,234 -19.2% -191,036,766 152万人せとうち3市※ 倉敷市・松山市中核市ランニングコスト 448,107,600 ※507,205,227 13.2% 59,097,627 47万人、51万人盛岡市中核市ランニングコスト 1,170,638,880 987,104,559 -15.7% -183,534,321 28万人佐倉市一般市ランニングコスト 1,059,282,249 1,034,529,751 -2.3% -24,752,498 16.5万人宇和島市一般市ランニングコスト 413,100,000 444,224,757 7.5% 31,124,757 6.5万人須坂市※ 一般市ランニングコスト 462,093,659 ※466,073,415 0.9% 3,979,756 4.8万人美里町・川島町 ※ 町村ランニングコスト 216,428,860 ※263,873,260 21.9% 47,444,400 1万人、1.8万人笠置町※ 町村ランニングコスト 23,610,400 ※83,004,916 251.6％ 59,394,516 0.1万人ランニングコスト合計 4,787,264,648 4,588,982,119 -4.1% -198,282,529 19 令和５年度の採択団体別ランニングコストのサマリ ◦ 検証採択団体別に、「コスト(A)」に対する「コスト(B)」の差額分析を行った。 ◦ 令和４年度の検証事業において「ランニングコストの逓減」が課題となっていた団体においては、地方公共団体側でベンダー選定が進み、システムを共同利用する団体数が増加した結果、費用按分により費用逓減される試算結果となった。 ※共同利用の費用按分の採用は「せとうち3市」「須坂市」「美里町・川島町」「笠置町」の4件に対してのみ【採択団体別のランニングコストと増減】（単位：円）費用減費用増費用減費用減費用増費用増費用増費用増

20 【参考】令和５年度の検証における費目別合計 ◦ 経費項目別に、「コスト(A)」に対する「コスト(B)」の差額分析を行った。 ◦ ランニングコストの比較においては、推奨構成等を採用し、更に一部団体で共同利用方式の費用按分試算を採用した結果、全団体の合計値では、「コスト(B)」が「コスト(A)」と比較して費用逓減される試算結果となった。分類カテ
ゴリ経費項目コスト(A)：現行利用中のシステムを同規模で入れ替え・継続利用した場合（全団体の合計値）コスト(B)：現行利用中のシステムをガバメントクラウドへリフトし推奨構成等と共同利用の費用按分※を採用した場合（全団体の合計値）構成割合 B-A差額ランニングコスト 5 年分作業費システム運用作業 1,168,629,200 ※1,136,220,600 24.76% -32,408,600 ハードウェア保守作業 23,858,400 22,948,400 0.50% -910,000 その他外部委託費 156,735,750 154,487,000 3.37% -2,248,750 物品費ハードウェア借料 821,553,665 144,749,440 3.15% -676,804,225 ハードウェア保守費 45,588,800 16,176,000 0.35% -29,412,800 ソフトウェア借料 1,659,827,300 1,235,749,457 26.93% -424,077,843 ソフトウェア保守費 519,263,599 ※555,795,591 12.11% 36,531,992 データセンター利用費 189,201,315 6,270,850 0.14% -182,930,465 通信回線費 83,540,360 ※294,083,938 6.41% 210,543,578 クラウド利用経費＊119,066,259 ※、＊1,022,500,843 22.28% 903,434,584 ランニングコスト合計 4,787,264,648 4,588,982,119 100.00% -198,282,529 ※ 共同利用の費用按分の採用は「せとうち3市」「須坂市」「美里町・川島町」「笠置町」の4件に対してのみ＊クラウド利用経費において為替の影響を受けるのは、コスト(A)の場合は須坂市のみ、コスト(B)の場合は全ての検証団体＊① 令和5年12月26日付の出納管理事務規定に定める為替レート１米ドル=139円で試算した場合、クラウド利用経費は (A)120,499,217円、(B)1,235,892,323円＊② 令和6年7月の為替レートを参考として１米ドル=160円で試算した場合、クラウド利用経費は (A)121,753,056円、(B)1,422,609,869円【採択団体の経費項目ごとの増減】（単位：円） $1 = 139円 11.2億(+2.2億) $1 = 160円 13億(+4億) 大規模の神戸市・盛岡市の3.9億費用減を利用して全体のランニングコストが下がっているとしている為替を加味すると、神戸市・盛岡市を加味しても全体で費用減と言えるか。そもそも全体で下がることの意味は国側の論理。

デジタル庁の試算による中期的対策後の推計値 ※2 ◦ 現行システムからガバメントクラウドへリフト(推奨構成等を採用した構成)した場合の増減率について、「検証事業報告値コストＢ」とデジタル庁試算による「令和８年度以降に実施する中期的対策後」の推計値を以下に示す。 ◦ 検証事業では費用削減効果が見られなかった宇和島市、須坂市、せとうち３市、美里町・川島町においても、検証事業報告値（見直し）から最適化（モダン化）等を図ることによりランニングコストの削減が見込まれる。データセンター(単独) 佐倉市は一部庁内環境からリフト
データセンター(ハード共用) 自治体クラウド(ハード・アプリ共用) せとうち3市、笠置町は一部庁内環境からリフトガバメントクラウドへ移行前の現行環境 -19.2% -15.7% -2.3% 7.5% 0.9% 13.2% 21.9% -43.8% -42.7% -34.7% -27.5% -32.1% -26.5% -16.6% -100% -80% -60% -40% -20% 0% 20% 40% 60% 80% 100% 神戸市盛岡市佐倉市宇和島市須坂市せとうち 3 市美里町・川島町笠置町ランニングコストの増減率※2を可視化増えている減っている増減率検証事業報告値の増減率中期的対応後の増減率～～ 251.6% 160.1% 21 【当庁が想定した中期的対策の内容】 ※２前頁の「当庁が想定した当面の対策※１」に加えてシステム最適化等として以下を適用し試算したもの〇令和６年度予算の政府情報システムにおける運用等経費コスト削減率31％で試算〇 ※１で計上した長期継続契約割引率を戻すとともに国の利用状況調査による長期継続割引が適用可能なシステム構成要素の割合15.9％に対し、長期継続割引3年、 WINDOWS R1 33%を適用して試算〇標準化に伴うパッケージ料金等の増については現存データがないため反映していない笠置町の現行環境は、京都府自治体情報化推進協議会が運営する自治体クラウドにてシステム基盤及び通信回線を一体として安価に提供を受けていることから、当庁による中長期的対策後の試算でも費用増加となる

【参考】デジタル庁の試算による当面・中期対策後の増減率内訳 ◦ 更なるランニングコスト逓減に向けて、令和７年度末までに当面対応する「当面の対策」及び令和８年度以降に実施する「中期的対策」の対策後の増減率を以下の通り推計した。 ◦ 後述頁では、コストBとそれぞれの対策後の比較結果を示す。現行環境団体名検証事業報告値
（コストBとコストAの差分（増減率））コストBに対する当面の対策後の増減率 ※1 最適化及び長期継続契約（3年）増減率コストBに対する中期的対策後の増減率 ※2 データセンター（単独）神戸市 △19.2％ △25.9％ △19.1% △43.8% 盛岡市 △15.7% △19.1% △24.2% △42.7% 佐倉市 △2.3% △8.2% △27.5% △34.7% データセンター（ハード共用）宇和島市 7.5％ △1.1％ △28.0% △27.5% 須坂市 0.9% △4.8% △28.4% △32.1% 自治体クラウド（ハード・アプリ共用）せとうち３市 13.2% △1.2% △27.6% △26.5% 美里町・川島町 21.9％ 14.7％ △31.6% △16.6% 笠置町 251.6％ 222.3％ △67.5% 160.1% 計 △4.1% △10.8% △35.1％【削減内容】 ※１検証事業において、「コストAとコストBの差分（増減率）」からの削減要素として以下を適用し試算したもの ◦通信回線について地方公共団体が合理的と判断する通信回線サービスに見直す ◦大口割引：AWSが目指す上限20%を適用〇長期継続割引：地方公共団体のシステム構成要素のうち長期継続割引が適用可能な割合57.2％に対し、長期継続割引1年間、WINDOWS R1 21%を適用して試算 ※２システム最適化等として以下を適用し試算したもの〇令和6年度予算の政府情報システムにおける運用等経費コスト削減率31％で試算〇 ※１で計上した長期継続契約割引率を戻すとともに国の利用状況調査による長期継続割引が適用可能なシステム構成要素の割合15.9％に対し、長期継続割引3年、 WINDOWS R1 33%を適用して試算〇標準化に伴うパッケージ料金等の増については現存データがないため反映していない【令和５年度検証事業の報告値と当面の対策・中期的対策後の増減率（推計値）】 22 なぜ特性もシステム規模も違うものを一律で適用するのか

23 トータルコストメリットが出なかった要因の分析と解決策 3つの原因により、ガバメントクラウドの目的の1つであるコストについて現時点では限定的な効果に留まるとしているクラウドへの回線・複数拠点の統合運用庁舎既存DC ガバメントクラウド 20業務以外
運用業者 20業務以外 20業務 20業務運用業者追加回線統合運用業者 20業務 20業務 20業務 … … … … 同一ASP 自治体A 自治体B 自治体C 按分効果が出ていないクラウドネイティブになっていない今までのアプリケーションクラウドネイティブ多くの関連システムをリフト多くの団体がリフトクラウドネイティブ化

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 24 自治体システム標準化及びガバメントクラウド移行における現状と課題クラウドを利用する本来の目的が薄れてしまいかねない事態番号利用事務系システム 20業務以外 ASP① ASP② 複数の技術（クラウド）が高いレベルで求められる複数の場所へのネットワーク敷設システムが1箇所から複数箇所へ：20業務+20業務以外 ASPがクラウドを選択できるため、マルチクラウド化が複雑化の一因 IBM Cloudやプライベートクラウドなどベンダーや自治体の都合によるクラウド選択が更に進む… 今までのシステム全体像今後想定されるシステム全体像運用管理補助者複数の技術と場所を考慮した高度な運用人材の確保及び定義と価格高騰自治体規模に依らない非機能要件の遵守のためのコスト増

25 自治体規模・既存システムの状況によって、効果が異なっていることも認識全てに一律で有効な手順は存在せず、自分たちで有用な選択をしなければならない既存データセンター利用方式オンプレミス・データセンターパッケージで利用のミドルウェアクラウド持ち込み料自治体クラウド利用有無共同クラウド化済み対象とする業務
関連システム・密接連携システム自治体規模政令市・中核市・市・町・村それが故に、自治体職員の方々に、高いレベルでクラウド知識の習得が求められている

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 26 参考）東京都宮坂副知事のシステム標準化・ガバメントクラウドの課題感 0.現状に対する情報不足・理解不足補助金での対応、移行困難同時期実施、制度改正、標準仕書の確定同時期実施、スキル・リソース不足、情報不足による方向性の不透明さと変動・クラウド利用のアンマッチング・システムの複雑化(運用・NW) ・SaaS化のインセンティブがない・為替レート/非機能要件への適合・期限・安定性・主権リスク・ガバクラ利用のメリット不足・ASP先行投資国・地方デジタル共通基盤推進連絡協議会ワーキングチームによるヒアリング令和6年10月7日東京都副知事宮坂学

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 27 自治体自治体自治体自治体ガバメントクラウドのスキームサービス提供と支払いのしくみデジタル庁自治体自治体自治体 ASP 自治体自治体自治体 CSP クラウド費用請求クラウド費用支払パッケージ利用費支払いパッケージ利用費請求自治体ごとのクラウド利用費報告クラウド利用費一括支払いガバメントクラウドクラウド統制（テンプレート）保守サービスボリュームディスカウントクラウドサービス提供予算取得の課題（ASP）按分方式のしくみの構築（NW量、アクセス量等）自治体規模だけでは測れない（＝不公平）契約団体数がわからなければ按分金額が出せないクラウド費用に利益及び代行手数料を請求してはいけないインシデント対応の課題今までは、ASPがインフラも含めて一括保守だったものが、クラウドは自治体、パッケージはASPが保守となり、障害対応のスキームが複雑化する競争原理とビジネスの課題 ASPはインフラも含めて売上計上できていたものが、クラウド費用が一切売上にならなくなるため、競争環境が働かない中では、クラウド費用低減のモチベーションが成立しない選択肢の課題ガバメントクラウドであるため、3 年契約などの長期契約が利用できない通常のパブリッククラウドのほうが自由度が高く、ガバメントクラウドである理由が難しい投資対効果課題為替レートが、計画当初の 115円→160円(1.39倍)となり、KPI3割削減以上を食ってしまっている(現在は約150 円？) 予算取得の課題按分の件で、いつ費用が確定できるか為替レートをどう定義すべきか不明 GCAS GCIM 自治体-CSP契約の必要性? 支払いだけデジタル庁経由になり、自治体とCSP間でも契約を結ぶ可能性が出てきている?

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 【参考】ガバメントクラウドへの移行の必要性〇少子高齢化社会が進み、急速な人口減社会に突入する中で、質の高い公共サービスを維持し、国民のニーズの多様化に柔軟に対応していくためには、国と地方のデジタル基盤の共通化を推進することが重要である。〇地方公共団体の基幹業務の標準化及びガバメントクラウドへの移行は、まさにこの観点から取り組んでいるものであり、これにより、地方公共団体情報システム全体のセキュリティレベルの高度化及び大規模災害対策（ディザスタリカバリ）が実現する他、従来システムに発生していた事務の効率化にも資する。（注）１．セキュリティ向上の例・デジタル庁が用意したセキュリティテンプレートの活用によるヒューマンエラーの回避・高度なセキュリティ対策をすべてのシステムに適用できることによるセキュリティレベルの均一化・高度化等２．大規模災害対策の例複数のリージョンにシステムとデータを保管し、大規模災害の発生を想定したシステムの可用性と業務継続性を保持等３．事務の効率化の例・テンプレートを用いた環境構築による複数環境の効率的構築、リソースの有効活用・システム更改の都度発生していた調達・契約関連事務の削減等〇システム経費については、ガバメントクラウド移行初期において、ランニングコストが一時的に上昇する可能性は否定できないが、いわゆるクラウド最適化を行うことにより、中長期的には、ほとんどのケースにおいてコスト削減が見込まれている。（注）コスト削減方策・移行経費に係る財政支援。・デジタル庁がクラウドサービス提供事業者と交渉したことによる大口割引、長期継続割引の適用。・回線に関して、地方公共団体が合理的と判断する通信回線サービスの検討。・サーバ構成、パッケージソフトの見直し等〇ガバメントクラウドについては、海外クラウドサービス提供事業者が多くを占めているが、この点についてもデジタル庁がしっかり管理している。（注）ガバメントクラウドに関するデジタル庁の管理・ISMAPリストに登録されたクラウドサービスから選定するとともに、機能要件を設定。・データセンターは国内立地。・米国政府・裁判所から米国法に基づきデータ開示を求められた際は、速やかに日本政府に通知するとともに、クラウドサービス提供事業者が異議を申し立てること、主権免除の対象となることを米国政府に通知することを仕様書及び契約書に明記。等 28

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 29 パブリッククラウドサービスの利用にまつわる経済安全保障の観点からの状況と懸念現在、AIにおいては学習させない設定にしたとしても機密データの入力不可の方針 Cloud ACTに対して国内配置・国内法準拠や主権免除にて対応不安定な世界情勢においてクラウドサービスの停止やネットワーク切り離しが現実のものにデータを見られるリスク”だけ”が問題なのではなくシステムの制御権が自分たちにないこともリスクデータレジデンシー ≠ 主権

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 30 確保すべき3つの主権の特徴と、影響及び確保手段法律や倫理を超えた情勢においての「主権」を考える必要性データ主権運営主権テクノロジー主権データへのアクセスメタデータによる動向把握システムのシャットダウンデータへのアクセス遮断寡占市場での円安・値上げソフトウェア・ハードウェア生産サポート・パッチ提供停止主権 - ソブリンティ - システムへの即時影響が大きい中長期的な影響に留まるシステムの稼働場所の「選択」により回避可能国産OS・ハードウェアへの長期的な開発に投資が必要ガバメントクラウドにおけるクラウド暗号鍵管理に関する調査研究業務

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 31 ソブリンクラウドについての正しい理解とユースケースの策定自らが持つデータとシステムの特性を判断して対策をしなければならない領域ソブリンクラウドの整備 ≠国産クラウドソブリンクラウドの利用ケースの想定有事の際に、自国で制御可能な自律的なクラウドサービスの整備例：ドイツはGCPを、フランスはAzureを自国の企業で運営 ※AWSさんも欧州でソブリンクラウドの整備を表明システム・データの機密分類と影響度を踏まえたクラウドのマッピングヨーロッパでは、自動車産業やヘルスケアといった重要産業とソブリンクラウドをマッピング重要情報とはなにか? 正しい理解どこに適用するか?

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 32 情報分類とパブリッククラウド利用令和３年度重要技術管理体制強化事業 (クラウドを活用した重要情報管理体制強化に向けた調査事業) 調査報告書 https://www.meti.go.jp/meti_lib/report/2021FY/000682.pdf

33 自治体が保持する機密情報の分類とパブリッククラウドの利用について地方公共団体における情報セキュリティポリシーに関するガイドライン(令和６年 X 月版) パブリックコメントより自治体機密性という国と異なる分類が定義された
3A/3B/3Cという更に分割された分類となった 20業務は3Bと想定 3Bをパブリッククラウドサービスで利用する場合は、 ISMAPであればOKと整理あくまで”パブリッククラウド”である場合の整理のため、プライベートクラウドやオンプレミスはその限りではないと思われる https://public-comment.e-gov.go.jp/pcm/download?seqNo=0000279959

34 主権免除は、Wikipedia によると「国際民事訴訟において、被告が国または下部の行政組織の場合、外国の裁判権から免除される、というもの。国際慣習法の一つ。」とされています。従って、こちらは国際慣習法であり、拘束力はないものとなり、対象は国際民事訴訟だけであり、刑事訴訟は対象外となります。なお、慣習法ではなく条約化されたものとして「国連裁判権免除条約」がありますが、日本は批准していますが、批准国が足りず、まだ発効していない上に、米国は批准していませんので、この件には適用されません。この条約中では、民事訴訟であっても主権免除を主張できない場合が広く定められており、実質的には、クラウド上のデータについては保護されにくいと考えられます。また、上記は全て、データ主権に関する視点だけです。ロシア-ウクライナ戦争やアリババの台湾からの撤退に見
られるように、運用主権については、一切、対象になりません。政府機関等からの開示請求に際しては、速やかに当庁に通知するとともに協議に応じること。また、当該請求に対して必要に応じて異議申し立て等の適切な対応を取るとともに、国内法以外に基づく開示請求であった場合は主権免除の適用について当該外国政府機関等に通知すること。ガバメントクラウド要件への追加文言：主権免除についての見解

35 • 米国政府のデータ取得行動の有無とは別に、住民のプライバシー情報を米国系CSPに保存することが住民・議員から憲法違反であると指摘され、訴えられる可能性があり、それを負わされるのは地方自治体となってしまう（国は訴えられない仕組みになっている/ガバメントクラウドは努力義務）ので、地方自治体の人たちは住基ネットの最高裁判決と同様に自分事として真剣に考えねばならなくなっている • それが起きてしまった場合、住民のデータをその影響から隔離するため（＝元の環境に戻す）には膨大なコストがかかってしまうことが想定される •
Cloud ACTによるデータ提供命令があった場合、日本政府が異議申し立てをしたところで、確実なものではないし、覆すことは事実上困難とされ、日本法に準拠していても、データを取得された事実すら把握できないかもしれない。また、ガバメントクラウドの主権免除においても民事上の問題にしか適用されない状態になっている • ガバメントクラウドの当初要件に主権免除がなかったため、主権免除への考慮があったはずだが、なぜ民事だけでもOKとしたのか、これらのリスクの議論がし尽くされたのかわからないまま、リスクを包含したまま、移行に取り組む必要が出てきてしまっている • 実際に国側での機密情報を扱う場合はオンプレミスもしくはハイブリッドクラウドを採用している実情も。住民データのガバメントクラウド利用が孕むリスクと議論の不完全性避けては通れないリスク管理に今後直面する可能性がある本件について、どう結論づけるか

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 36 自治体の今までの情報システムとの比較と”現実” 【AWS】ガバメントクラウド勉強会に向けたおさらい：https://qiita.com/kaburagi_/items/521c1143dcae674ae490 個別にセキュリティ・運用監視結果としてバラつきがある個別にコスト最適化庁内でのみ共通基盤化都度調達急な需要に応えられない過去理想現実セキュリティ・運用監視の一部共通化 OS以上部分は個別に対策が必要個別にコスト最適化自治体ごとの環境構築・レンタル費用の増加自治体クラウドで既に共同化済み都度調達基幹系については複数年に渡る計画が必要変化するコストに追従する予算化セキュリティ・運用監視の共通化とにかく利用するだけで良い全自治体で共通SaaS化自治体は選択するだけ柔軟な調達必要に応じて、適切なベンダーからガバメントクラウドガバメントクラウド可搬性・ロックインとのトレードオフ既に最適化済み基幹系に必要か

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 37 参考）紀尾井町と霞が関のシステム標準化事務に従事する中央省庁職員に伝えたい事 https://note.com/techniczna/n/nd8f0be368f44 ガバメントクラウド上に共同利用方式の標準準拠システムがたくさんあり、自治体はその中から好きなものを選んで SaaSのように利用できるレゴブロックのようにシステムを入れ替えることができるため、ベンダロックインが解消され、競争性が働いて運用保守費が安くなる自治体職員はシステム運用保守の業務から解放され、住民サービス等の本来業務に専念できるようになる標準化の結果、先進事例の横展開が容易になる標準化されたシステムから国の情報連携基盤に連動して、新規のシステムを１週間で立ち上げることが出来るようになり、国民は諸々の手続きをスマホで60秒で完了できるようになる標準準拠システムの調達にあたっては、データ連携の詳細について従来どおり自治体が調整する必要があり、またネットワークアカウントを介した接続もあり、SaaSのように簡単に利用できるわけではない協議や調整により構築された自治体ごとに独自プロダクトがロックイン要素になり、ベンダロックインは解消されない自治体職員は従来通りシステム調達の際に仕様作成や調整を行う必要があり、負担は軽減されない連携の仕組みが個別調整になるため、外付けシステムで実現する先進事例の横展開は容易ではない履歴管理等の仕様が統一されていないため、国の情報連携基盤に連動する際も都度データパッチが必要となり、新規システム１週間や手続きスマホ60秒の実現も怪しい

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. クラウドのアンマッチング  複数拠点(ASP間、20業務以外)のネットワーク、運用管理  非機能要件と既存環境との差異 / モダン化するには規模が大きく、時間も掛かる  システム特性が静的のため、自治体クラウド・共通基盤化の取り組みなどの買い切りの場合に比較して価値が出るか方向性と制度設計  当初のSaaS提供という形態から、各自治体でシステムを引き続き構築するという取り組みに変わってしまっている  クラウド利用料負担、クラウド接続費用負担、クラウド間接続費用負担等、実現されていないことが多い  先行事業の結果、ベストプラクティスが整備されていない（運用管理補助者、ネットワーク整備、クラウド間連携）  ASP側へのインセンティブがないスキーム（地場DCビジネス / クラウドを自治体が選べない）  本事業に関する、情報提供が非常に少ない / 仕様が固まらない / 多くの法改正  期限に基づき、業者間の競争が働かない / 職員負担を軽減するはずの取り組みが、実際には負担増になっている

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. ガバメントクラウド移行に向けてどうしたらよいかを”考える” <実践編>

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 40 ベンダー間ネットワーク構成の検討オンプレミス Private VIF DXGW VGW VGW オンプレミス Private VIF VPC-1 VPC-N VPC-1 VGW VPC間通信オンプレミス Transit VIF DXGW TGW VPC-1 VPC-N オンプレミス Private VIF VGW VPC-X VPC-1 VPC-N Direct Connect 不可不可不可 PrivateLink 可能複数 VPC 不可可能可能可能双方向通信可能可能不可可能 IP 重複不可不可可能不可拡張性 ✗ ◯ △ ◎ オールインワン構成※VPC1つオールインワン構成※VPC複数マルチベンダー構成 VPC間連携はオブジェクトストレージAPI連携 NW アカウント不要必要必要必要マルチベンダー構成 VPC間連携はオブジェクトストレージAPI連携のみオールインワン構成※VPC複数マルチベンダー構成 VPC間連携がオブジェクトストレージ・ファイルなど対応可能構成パターン ① ② ③ ④ 庁内へのネットワーク通信要件の整理中間サーバー・プリントサーバー等データ連携の要件と実現可否の整理データ連携方式の動向が技術要件に跳ね返ってくる技術的な理想がそのまま実現できるわけではない運用上の制約条件がある

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 41 参考）SaaS運用の制約受容の課題標準化移行タイミングのステップも含む標準準拠システムのシフト検証検証結果よりベンダーによってシステムの切替時期が異なる。その場合、標準準拠システムと現行システムが混在する形となり、つまりは連携方式について標準準拠した連携と現行連携が混在することとなる。現行連携が残る場合、ベンダー間の調整および連携プログラムの開発等、標準化の趣旨にそぐわない対応が必要となってしまう。かつ現行連携の切替時期が到来した際には、再度、標準準拠方式への切替を実施しなければならず、体制やリソースの確保が別途必要となる。自治体① 業務A 1.0 自治体① 業務B 1.0 自治体① 業務B 1.1 共通SaaS 業務A 1.0 共通SaaS 業務B 1.0 自治体① 業務A 1.1 自治体ごとにシステムが構築されているので、同一タイミングでバージョンアップ可能共通SaaS 業務B 1.1 共通SaaS 業務A 1.1 12月末一斉バージョンアップ 3月末一斉バージョンアップ 3月末まで待ってくれない不整合自治体① 業務A 現行自治体① 業務B 現行自治体① 業務B 標準準拠自治体① 業務A 標準準拠 12月末標準化 3月末標準化標準準拠システムの完成時期やリソースなどの観点でずれてしまうケース不整合各ベンダーの切り替え時期を統一せよとの指示今までのシステム形態とバージョンアップ時期調整 SaaS形式の場合のバージョンアップ時期調整の難度標準化移行タイミングでの現行システムとの切り替え時期調整の必要性

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 42 ネットワーク運用管理の単独利用方式環境の必要性と構成の柔軟性もしネットワーク運用管理環境が必要であれば、予算や申請などが求められる VPC 早期移行業務庁内 TGW VPC 2025年度末移行業務各ベンダー間の接続も早期移行業務担当ベンダーの範疇になり、柔軟な構成が難しくなる。 ※責任分界点の不明瞭さから敬遠される可能性もある早期移行業務のことだけ考えて構成してしまった場合早期移行後に移行される標準準拠システムを事前に考慮する場合 VPC 早期移行業務庁内 VPC 2025年度末移行業務 VPC ネットワーク運用管理用 TGW 別途ネットワーク運用管理事業者を立てることで、責任分界点やロックインを回避し、柔軟な構成を取ることができるようになる ※共通機能の構築場所としても利用可能単独利用方式のアカウントを自治体が申請する必要がある

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 43 自治体側での統合管理はベンダー間調整と交渉になり、どこまでポリシーを受け入れてくれるかが難しい。共同利用方式のデータをどこまで見せてくれるかも懐疑的。費用は共同利用の利用範囲を GCASで管理・按分されたものが合算されて請求される。利用方式に伴うアカウント管理と統合的な運用への影響単一アカウントベンダーＡ領域ベンダーＢ領域ベンダーＣ領域ログ・通知等の統合運用が可能単独利用方式複数アカウントベンダーＡ領域ベンダーＢ領域ベンダーＣ領域共同利用方式共同利用方式共同利用方式データを収集して統合化する必要があるデータがもらえるかデータ粒度が同じか運用ポリシーの策定と統制が可能個別ポリシー個別ポリシー個別ポリシー名前解決 SLA バックアップ頻度 BCP セキュリティ構成・権限管理ログ管理証明書・暗号化性能監視障害監視時刻同期連携方式以下のような運用ポリシーをベンダー間調整する必要がある命名規則やタグ、運用ポリシーを作ってベンダーに遵守させられる（そもそも単独利用に賛同してくれるベンダーがどれくらいいるかだが…）。費用は単一アカウントからのそのままの料金。複数クラウドでの運用となると統合運用管理レベルが急激に上がる

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 44 参考）地方公共団体情報システム非機能要件の標準 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5- 095b7c45100c/4eded239/20220831_local_governments_05.pdf 指標と達成レベル分けと最低条件が記載されている本基準を遵守することが補助金受給条件となる以下が指標の例・RPO：目標復旧地点・RTO：目標復旧時間・システム再開目標・稼働率規模によらず、全自治体が同一基準

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 45 99.5%で14.5時間？政府が定義する基幹業務システムに対する許容ダウンタイム時間原因：平日業務時間のみを対象とした計算 12時間×20日× 12ヶ月× 0.005＝約14.4時間地方公共団体情報システム非機能要件の標準【第 1.1 版】（本体）（令和 4 年 8 月）地方公共団体情報システム非機能要件の標準【第1.1版】（本体）（令和4年8月）

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 46 許容可能ダウンタイム時間の差 SLA 年間許容停止時間 99.99% 5.26分 99.95% 4.38時間 99.90% 8.76時間 99.5% 44.6時間 99% 3.65日 95% 18.3日一般的なSLA定義 SLA 年間日中許容停止時間 99.99% 17分レベル５ 99.9% 2.9時間レベル４ 99.5% 14.5時間レベル３ 99% 29時間レベル２ 95% 145時間レベル１基幹業務システムのSLA 定義 ←通常の SLA99.997% 相当 ←通常の SLA99.966% 相当 ←通常の SLA99.84% 相当 ←通常の SLA99.67% 相当 ←通常の SLA98.34% 相当一般的なクラウドサービス想定時 99.9%以上のSLAが本当は適切な要件？シングルAZ (SLA:99.5%) ・単一障害対応マルチAZ (SLA:99.99%) ・DC障害対応・二重化・アプリ改修が必要 ※AZ Availability Zone(データセンタ)

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 47 必要運用管理の範囲と、担当者の定義パッケージ運用管理ガバメントクラウド運用管理通信回線クラウドへのネットワーク運用管理共通機能構築ベンダー間共通機能調整非機能要件、ダッシュボード、構成最適化、障害対応データ連携・ルーティング・名前解決・時刻同期・認証ログ管理・遠隔保守・パッチ配信等 20業務外との統合運用管理 ASP ASP ガバメントクラウド運用管理補助者通信回線事業者ネットワーク運用管理補助者統合運用管理補助者統合運用管理補助者統合運用管理補助者ネットワーク運用管理補助者ネットワーク運用管理補助者 ASPが兼任するケースも、地場ベンダーがここに介在しないと個別対応が難しくなるケースも。世の中のネットワーク運用管理補助者のサービス提供範囲がどこまでなのかを言葉に依らず確認する必要があるそもそもどの範囲まで必要かと予算・適合業者を検討する必要があるガバメントクラウドだけでなく、自治体業務間の調整ごとなども対応が必要になってくる

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 48 予算確保における変動要素のバッファ化とその影響クラウド利用料年 1年 2年 3年 4年 5年トータルコストバッファ従量課金・為替レート・按分変動一括固定実際年払い年払いバッファ込実際の年払いの金額予算取得のバッファ金額時間為替レート円建てドル建て = 常に値上げ・値下げしている = 期限付きレート固定のため、レート見直しタイミングで値上げと見なされるケースが有る為替レートと値引き・値上げの仕組みの違い 1月 2月 3月 4月 5月 6月総額 100 160 180 180 170 170 契約団体数 10 20 30 30 28 28 按分結果 10 8 6 6 6.1 6.1 契約月・団体数・総額によって年間予算想定額が異なることに… ※こんな単純ではありません（あくまでイメージ） • 構成自治体となる条件は「当該月に1日以上ガバクラを利用していた団体」である。つまり申請時点で構成団体となり、頭数に入れられることになる。 • 端数寄せをする団体を運用管理補助者で指定しなければならない。自治体に納得してもらえるか。 • 翌年度の予算請求に向けて、按分方法がこの時期に決定していない

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 49 モダン化アプローチの前提条件の違いから来る認識差異要は適正に利用の仕方を判断しなければならないということ＝本来は競争で自発的に起きるべきことモダン化されたアプリケーション既存の制約が最小既存アプリケーション SoR 新規アプリケーション SoE 既存の技術制約が大きい自社開発でない改修コスト・期間が掛かる安定稼働にリスク共同利用方式規模がスモールスタートアジャイル開発しやすいマルチステークホルダー非機能要件クラウドフィット静的なシステムでレンタルが所有に優るか自治体規模に応じた要件のセットが求められるネットワーク・運用管理ベンダー間調整の必要性金太郎飴方式から個別最適へ

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 50 費用試算サマリ（まとめ） ◦ ランニングコストの大きな割合を占める項目のうち、「システム運用作業」はマネージドサービスの利用や推奨構成の適用などのクラウド最適化を推進することで、また、「クラウド利用経費」は大口割引や長期利用契約を活用することで、それぞれ費用を逓減することが考えられる。分類カテゴリ経費項目説明ガバメントクラウドリフト後全団体合計割合イニシャルコスト作業費カスタマイズ費業務アプリケーションパッケージのカスタマイズ作業経費 ¥11,220,000 1.34% 環境構築費ハードウェア、ソフトウェア、回線等のインフラ設計・構築作業経費 ¥523,091,630 62.38% データ移行費現行システムのデータ移行作業経費 ¥59,335,500 7.08% 他システム連携機能構築作業費システム連携基盤等共通基盤の設計・構築作業経費 ¥38,143,000 4.55% 操作マニュアル作成・職員研修費マニュアル等のドキュメントの作成、職員向け操作研修に要する経費 ¥5,612,500 0.67% プロジェクト管理費プロジェクト管理に関する経費 ¥201,096,220 23.98% イニシャル小計 ¥838,498,850 100.00% ランニングコスト 5 年分作業費システム運用作業システム稼働監視、ジョブ管理、ヘルプデスク、障害対応、バックアップ等 ¥1,260,735,600 25.06% ハードウェア保守作業ハードウェアに関する保守作業費 ¥22,948,400 0.46% その他外部委託費大量帳票出力等、定常運用以外で定期的に外部事業者に委託する業務に関する作業費 ¥154,487,000 3.07% 物品費ハードウェア借料ハードウェア等の使用に関する借料 ¥146,633,560 2.91% ハードウェア保守費ハードウェア保守費 ¥17,076,000 0.34% ソフトウェア借料業務パッケージソフトウェア、ミドルウェアの借料 ¥1,244,895,672 24.75% ソフトウェア保守費業務パッケージソフトウェア、ミドルウェアの保守費 ¥560,416,765 11.14% データセンター利用費データセンター経費 ¥6,306,850 0.12% 通信回線費回線、コロケーション経費 ¥430,428,790 8.56% クラウド利用経費 CSP（クラウドサービスプロバイダー）の利用料 ¥1,186,833,715 23.59% ランニング小計 ¥5,030,762,352 100.00% ※ガバメントクラウド利用費は「クラウド利用費」のカテゴリに該当 ※上記はすべての採択団体を対象としたイニシャルコストとランニングコストの合計と構成割合を示す。モダン化による削減可能箇所が赤字部分になるが、ここがモダン化によって減ったとしても、元々の3割削減のためには、モダン化で7割削減しなければならないモダン化すること自体にもお金がかかるが、クラウドロックインに拍車がかかり、根本的な解決の方向性に向かえないだけでなく、そのお金をかけただけの削減目標の効果が得られるかどうかをよく検討する必要がある

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 51 結局増えた項目は何で、どれくらい低減の可能性があるか議会対応に向けた方向性の検討通信回線費複数拠点管理相互運用費クラウド利用為替変動単純リフト 20業務外・関連システムの拠点集約による解消 2025年度以降にモダン化今後も要検討課題今後も要検討課題 20業務外・関連システムの拠点集約による解消長期割引・大口契約パッケージ改修投資回収 2025年度以降にモダン化も実現性や効果が限定的・未知数拠点集約は難しいモダン化は間に合わない個別最適は効果とのトレードオフバッファを確保するバッファを確保する拠点集約は難しい長期割引は利用できない？利用できても効果は限定的期限とリソースの問題から下がることはあり得ない 20業務指定ガバメントクラウド標準化原点引き起こされた状況対応が必要なコスト増項目 2025年度末までのコスト増回避策(案) 2026年度以降のコスト増回避策(案)

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. ガバメントクラウド移行に向けて自治体・事業者に求められること

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 53 自治体の職員の方々が意識をしなければならないこと ASP・CSP・地場ベンダーとのコミュニケーション自分たちで（もしくは誰かと）何が大切かを考えて行動する (残念ながら)今回はクラウドの知識を踏まえてどうするか考える

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 54 現時点での関係者の状況の認識自治体 CSP デジタル庁 ASP 地場ベンダー業務アプリケーションを作っていないのでこの状況がほとんど理解できていない状況不確定なことが多いので、確かな見積もりが出せない ASPの範囲内の提供事業者間調整対応余力が難しい ASP現場情報が落ちてこない複雑で説明できないそもそも状況が理解できていない理解できたとしても選択の余地がない全体観点から会話できる人がいない期限や構造的な見直しは難しそうインセンティブ設計が厳しい自分たちの範囲に留まる NW運用管理補助者解像度がそれほど高くない自らの範囲を提供コストが掛かっても他の事業を潰して取り組み調整事項がコストや期限を理由に断られ難航する

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 55 標準化・ガバメントクラウド移行を改めて考える必要性現在の標準化・ガバメントクラウド移行の現状を踏まえて、コストや安定稼働を含めて何が重要なのかを、自らが主体的に考えなくてはいけなくなっている ASP=悪なわけではない。この状況の中でもがいていることは忘れてはならない。お互いを踏まえたコミュニケーションが求められている。ガバメントクラウドは努力義務 • だからこそ、ガバクラを選んでも選ばなくても自治体側に責任があるということ • 疎明資料を提出すれば補助金は受給可能 • ASPとの折衝（ガバクラ以外の対応可否）が必要 • 以上が考慮できれば、拠点集約ができ、回線費・相互運用費・高効率化による集約費用・為替・変動費といった構造的なコスト増箇所を一気に低減させることが可能ではあるが、ベンダー側が対応してくれるかどうかは別問題。 • 現在のままでは、非常に複雑な調整事項をやり切る必要がある。そのために、クラウドの知識について高いレベルで自治体職員が学んで調整する必要がある。

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. まとめ理想とスケジュールについては、その妥当性を踏まえるフェーズ構造的課題が解決された将来へのステップを考えなければ、現状への適切な手が打てない

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. ガバメントクラウド移行に向けて私が支援できること

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 座学形式：ガバメントクラウド移行における必要基礎知識パブリッククラウドによって今までと何が変わるか

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 59 モダン化のステップと分離方式のマッピング自治体① システム 20業務自治体② システム 20業務自治体N システム 20業務 … 自治体① システム 20業務自治体② システム 20業務自治体N システム 20業務 … 共通の運用環境自治体共通システム 20業務共通の運用環境アカウント分離ネットワーク分離アプリケーション分離モダン(SaaS)化例：Office365 単純移行・自治体クラウド現行構成運用環境の共通化システム全体の共通化自治体① システム 20業務外自治体② システム 20業務外自治体N システム 20業務外自治体① システム 20業務外自治体② システム 20業務外自治体N システム 20業務外 … … 自治体① システム 20業務外自治体② システム 20業務外自治体N システム 20業務外 … モダン化の効果の実証課題既に共通基盤化・自治体クラウドなどで最適化されており、モダン化でコスト増の根本的な解決がされるかどうかに懐疑的（増えるコストのほうが多い）実際に先行事業の報告では安くなっていないリソース逼迫と競争原理の課題標準化の期限が逼迫しており、改修リソースにより消極的。既存ベンダー踏襲しか選択肢がなく、競争が働かない制度整備と明確化の課題自治体情報セキュリティポリシーの中で、暗号化の件でアプリケーション分離の実現に不透明な部分の存在→暗号化キーの問題は解決？も 2025年度末には間に合わないモダン化と根本解決の相反アプリケーション分離の実現方法がクラウドロックインになってしまい、根本的な解決方法の見込みであるマルチクラウド対応がしにくくなるおそれ SaaS運用の制約受容の課題マルチベンダー間のバージョン整合性が仕組み的に取りにくくなってしまう安定性とそれに伴う人材不足基幹システムにただでさえ標準化という不確定要素があることに加え、更に変更を加えることの技術面・人材面の難易度とリスクシステムの複雑化の課題 ASPがクラウドを選択できるため、システムがネットワーク・運用・人材の面で複雑化 20業務外による複雑化の課題 20業務と20業務外の分断で、マイナンバー系システム全体が、これだけでも複雑化多くのシステム開発ベンダーは「アカウント分離」「ネットワーク分離」を採用する想定となると言われています。つまり「共同利用」と言いつつ実態は自治体ごとにサーバーとDBが構築されてしまう状態で2025年度末を迎えることになります。個別最適と共同利用のトレードオフの課題共通化のメリットを個別最適化により、失われてしまう可能性。共同利用で個別対応は難しいので、単独利用への転換が必要。 20業務外の課題解決ハードルの課題 20業務外のガバメントクラウド対応はリソース逼迫や法的に定義されていないことから、ASPは消極的

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 60 運用管理補助者の存在の必要性今回の複雑な関係者間調整と、確認事項の多角化で本当に職員の業務負担減とできているか? 20業務以外 ASP① ASP② 運用管理補助者複数の技術と場所を考慮した高度な運用人材の確保及び定義と価格高騰以下を複数のクラウド（20業務内も20業務外も）技術者で提供されることを期待されている  認証認可方式を決定  クラウド環境の全体設計（庁内とのNW設計）・アカウントの払い出し・ネットワークの接続調整・コスト管理等  アカウント管理、性能・キャパシティ・コスト管理、セキュリティ管理、障害管理、構成管理、ログ管理  ベンダー間におけるヒアリングシートの作成  職員・ASPなどへの研修とマニュアル作成  問い合わせが集中した場合に十分に対応できる大勢を確保すること  暗号化・ファイアウォール・不正侵入対策・マルウェア対策・脆弱性対策・名前解決  システムやリソースの監視  災害対策によるDRサイトへの切り替え  オブジェクトストレージの管理・権限設定  各コンポーネントのメンテナンス  バックアップ等のイベントジョブのスケジュール管理  障害対応時のCSPへの連絡  プロジェクト管理  「進捗管理」、「課題・リスク管理」、「品質管理」、「資料授受管理」、「構成管理」、「変更管理」、「コミュニケーション管理」、「セキュリティ管理」  月次進捗報告などの会議体参考）大分市運用管理補助者のRFIより https://www.city.oita.oita.jp/o015/gabakura/gabakura.html

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 61 2024 2019 2016 米国政府及び他国でのクラウド利用における変遷と、日本の比較 2010 FDCCI Federal Data Center Consolidation Initiative 2015年までにデータセンターを800個閉鎖を目標 Cloud First クラウド移行を前提 DCOI Data Center Optimization Initiative 大規模DCの25％の閉鎖が義務付けられた Cloud Smart クラウドを適切に選択していく。そのための人材育成に投資をする。老朽化したレガシーシステムが多くあり、効率性、セキュリティの問題はあれど、変革には技術的困難を抱えており、これらを解消するには多大な費用がかかる根強いデータ保護とプライバシーに対する懸念から、クラウド移行の障害として、セキュリティが首位におり、移行が困難ハイブリッド元年パブリッククラウドの浸透が遅いため、オンプレミス/ プライベートクラウドを併用する指針に舵が切られた。できるところからパブリッククラウドにすることを想定している。 Cloud One(JWCC) マルチクラウドを前提とした、クラウド管理コントロールプレーンの必要性とクラウドロックインの回避の仕組み（外販もされている） Multi-Cloud Innovation and Advancement Act 連邦政府機関全体でマルチクラウド技術を採用し、導入と実装のベストプラクティスの障害となるものを特定するよう求めている。また、政府機関向けのガイダンスを作成し、運用ロードマップの概要を説明する責任も負う。コストを削減し、業務効率を高め、サイバーセキュリティを向上させる革新的なクラウド技術について意思決定を行えるようになることを想定。米国も英国も基本的には機密情報や個人情報はパブリッククラウドの利用が許可されていない GovCloudリージョン及びオンプレミスとのハイブリッドクラウドが、機密情報・個人情報を扱う際のユースケース。 GovCloudは民間クラウドから1.5年は新技術が遅れるかつ、セキュリティクリアランスのため、通常のパブリッククラウドより割高。日本外資パブリッククラウド（共有領域） A社 B社 C社専用リージョンクラウドプライベートクラウド国内パブリッククラウド（共有領域） EU 米国公開情報等個人情報機密情報等域内事業者（ソブリンクラウド）外資パブリッククラウド（共有領域）外資パブリッククラウド（共有領域）ハイブリッドモデル ※機密性3情報は機密クラウドに保管全て外資パブリッククラウドハイブリッドモデル他国の状況 ▪韓国そもそも行政機関でパブリッククラウドを利用許可されていないため、国が自前のDCを3箇所運用 ▪タイ政府共通クラウド基盤で、国家デジタル経済社会委員会事務局により構築運用クラウドスマート(2022) モダン技術を賢く適切に利用してクラウド移行する機密情報・個人情報の取扱まだまだ議論し尽くされておらず、リスクを包含した状態(特に自治体における訴訟リスク) クラウドバイデフォルト(2018) 政府情報システムの導入をする際の第一候補としてクラウドサービスを検討する財務省財政制度分科会(2024) 投資対効果の検証と可視化をすべき

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 62 金融機関のクラウド移行レポートに見る自治体のクラウドジャーニー成功に向けて今なすべきこと by pwc https://www.pwc.com/jp/ja/knowledge/column/digital-government/government-cloud01.html クラウド利用状況 • 非重要領域では、SLA等の要件が低い、サービスが充実している、システムの拡張縮小が求められる • 重要領域では、既存資産を放棄してクラウド化するインセンティブに乏しい。地域銀行では共同利用が進められてきて全体意思決定が難しい • 今後3年で重要領域、将来的に最重要領域をクラウド化が検討されているコスト削減に対する期待と評価 • コスト削減効果に最も期待（開発導入コストの削減72.3%、保守運用コストの削減64.1%が効果があったとしている）※最重要領域はコスト削減効果が評価されていない • 重要領域は、安定運用体制・可用性の観点で入念な検討のために導入コストが嵩んだ。違いを認識する中で効果が実感できなかった。金融機関・ベンダーの双方でクラウド活用ノウハウが蓄積されておらず、想定以上にコストが掛かった。今後ノウハウの蓄積によって、最適化が進められるのではないかと期待されているクラウド化の課題 • 非重要領域では、セキュリティログ、モニタリング、体制確率 • 重要領域では、可用性、サービス変更時の対応、データ所在地（レジリエンス） • 非重要領域から利用を開始し、体制や経験習熟を進めた後、重要領域への適用日本銀行金融機構局は以下のとおり警鐘を鳴らしています。「クラウドへの習熟度が低い状況にもかかわらず、『クラウド利用ありき』との発想の下で十分な事前検討や体制整備を行わないままクラウドへの移行を進めると、クラウドのメリットを十分に享受できない可能性が高い」自治体での移行については、移行期限と移行対象がネック • 移行期限：2025年度末 • 移行対象：基幹系システム

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. AWSハンズオン講座 VPC/EC2/S3/RDS/Lambda/コンテナ/TGW/PrivateLink等クラウドを見たこともないと調整イメージがわかない事業者側と会話ができない通常のクラウド知識とガバクラ標準化の紐づけ

64 AWS全体像とガバメントクラウド利用時のコンポーネントマッピングリージョン Availability Zone VPC(Virtual Private Cloud) 仮想マシン EC2
ストレージ EBS オブジェクトストレージ S3 サーバレスコンピューティング Lambda データベース RDS モニタリング CloudWatch 管理コンソールマネジメントコンソールユーザー管理 IAM インターネットからのアクセス要MFA 庁舎等からのアクセス Direct Connect IaC CloudFormation アカウント分離の分離単位ネットワーク分離の分離単位アプリケーション分離の分離単位 LGWAN/専用線環境間接続 TGW AZ VPC EC2 EBS RDS Multi-AZ構成共同利用方式の ASPカバー範囲単独利用方式の自治体カバー範囲連携方式の一つ 1つの仮想マシンを切り替えるという発想から、 2つを用意しておくという発想に。

65 ハンズオン 1. S3にあるハンズオン環境のダウンロード 2. マネジメントコンソールへのログイン(IAM) 3. VPCの作成 4. EC2インスタンスの作成
5. リモートからのアクセス 6. S3を作成して、ファイルをアップロード（重複確認）

66 ハンズオン IaCによる手作業環境の一括構築 1. AWS CLIのPCへのインストール・初期設定 2. S3からCloudFormationのyamlダウンロード 3. IaCをカスタマイズ
4. CloudFormationを使って環境の一括構築

67 S3のデータ連携を実際に試してみよう!! エンドポイント経由でのS3への双方からのアクセスするイメージ VPC-XX VPC-YY Subnet Subnet EC2 EC2 10.XX.XX.0/24
10.YY.YY.0/24 S3(共通機能) エンドポイントインタフェース EP-XX-S3 Bucket ???.csv エンドポイントインタフェース EP-YY-S3 10.XX.XX.??? 10.YY.YY.???

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 68 Private Link VPC-XX VPC-YY Subnet Subnet EC2 EC2 VPC エンドポイント VPC エンドポイントサービス NLB ロードバランサ PrivateLink • PrivateLinkは複数VPC間をエンドポイントを通じて接続することができるサービスです • 接続先では、エンドポイントサービスから接続するロードバランサが必要になる（コスト増の懸念も） • VPC-XXとVPC-YYのIPアドレスの重複を考慮する必要がない • VPC-XXからVPC-YYへの通信のみを実現するしくみ（VPC-YYからVPC-XX通信が実現できない） ※両方向から設定すれば可能だが、両方のVPCにロードバランサが必要になる

69 TGWを用いたVPC(共同利用方式環境)間の接続のしくみ VPC-XX VPC-YY Subnet Subnet TGW ルートテーブル EC2 EC2
10.XX.XX.0/24 10.YY.YY.0/24 10.XX.XX.0/24 10.YY.YY.0/24 10.XX.XX.??? 10.YY.YY.??? アタッチ伝搬関連付け UserXX側のEC2のプライベートアドレスを確認 UserYY側のEC2のプライベートアドレスを確認ルートテーブル 10.YY.YY.???へのアクセスはTGWへルートテーブル 10.XX.XX.???へのアクセスはTGWへペア相手のVPCへの通信はTGWへ転送する設定 10.YY.YY.0の通信は VPC-YYへ転送する設定関連付けペア相手のVPCへの通信はTGWへ転送する設定

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 具体的な検討項目・構成相談コスト・クラウド内ネットワーク・クラウド回線・非機能要件・データ連携・主権統合運用管理補助者・役割分担等々検討項目と選択肢の提供予算申請漏れ・作業分担漏れの回避最適化余地・調整事項のリスト化

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 71 自治体環境 XX市ガバクラA環境ネットワーク管理環境今後求められる検討ステップとプロセス概要番号利用事務システム全体像と検討項目のマッピングネットワーク管理環境共同利用環境共同利用環境 GW 運用管理環境運用管理環境 XX市ガバクラB環境共同利用環境運用管理環境 LGWAN 番号利用事務インターネットネットワーク管理環境 GW ASP① ASP② ASP③ 番号利用事務端末 XX市データセンター ASP③ 20業務外共通基盤運用管理補助者ネットワーク運用管理補助者統合運用管理補助者通信回線事業者ガバクラ以外共通基盤管理者 ASP ネットワークネットワークネットワーク専用線 LGWAN 共同回線 LGCS PrivateLink TGW 1. 各ASPの想定する環境を情報収集・整理 2. クラウドへの接続ネットワークの検討 3. ベンダー間ネットワークの検討 4. ガバナンスポリシーと非機能要件準拠の検討 5. 役割分担（運用管理補助者）の検討 6. コスト検討 7. データ連携検討 8. 行政機関としての主権検討 9. 検討項目の整理と対策の検討 10.調達内容の整理クラウド移行の検討ステップ

72 標準化に伴うガバメントクラウド移行時に整理・検討する項目一覧予算申請をするための予算額の把握をするために、全体構成と要件を整理し、調達物を確定する項目事前決定済み決定が必要選択肢マイナンバー系業務配置場所 ✓ 庁舎/データセンター/ガバメントクラウド
マイナンバー系業務種別 ✓ 20業務/20業務以外/移行困難クラウド接続回線 ✓ 専用線/データセンター共用回線/LGCS ガバメントクラウド内ネットワーク ✓ TransitGateway/PrivateLink ガバメントクラウド間ネットワーク ✓ 必要(GMCN/回線サービス)/不要ネットワーク運用管理アカウント ✓ 必要/不要共通機能 ✓ オブジェクトストレージ/ファイルサーバー/名前解決/時刻同期共通機能配置場所 ✓ ネットワーク運用管理アカウント/住記ベンダー環境内非機能要件 ✓ ✓ 一覧と選択レベル（違いを許容か、統一か）データ連携 ✓ オブジェクトストレージ/ファイルサーバー運用管理補助者 ✓ ✓ ガバメントクラウド/ネットワーク/統合運用管理の役割分担と要件定義ダッシュボード ✓ 要件定義・設計・構築・運用予算取得前提条件 ✓ 為替、従量、按分のバッファ率

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 73 簡易版）標準化に伴うガバメントクラウド移行のための情報収集・事実整理ベンダー整理シート ASPベンダー A社 B社 C社 D社 E社 F社移行予定時期 2025年度末種別本番/検証業務福祉 CSP AWS 利用サービス EC2 RDS 運用管理補助者同一按分方式人口単独/共同共同分離方式アカウント分離システムSLA 99.9% バックアップ週1回 BCP 大阪バックアップ大阪リカバリアンチウィルス・マルウェア GuardDuty 名前解決 Route53 時刻同期 Amazon Time Sync ネットワーク接続 TGW/PrivateLink 連携先住記連携方式オブジェクトストレージ現時点で分かる部分をまとめてみましょう!

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 74 業務間（ベンダー間）のデータ連携方式の技術観点での整理データ連携の方式とネットワーク構成が密接に連動する REST API オブジェクトストレージ API オブジェクトストレージ SFTP/SCP ファイルサーバー連携構成イメージ推奨構成推奨推奨オブジェクトストレージ間での連携が困難な場合のみオブジェクトストレージ間での連携が困難な場合のみマルチクラウド対応しやすい難しい ※CSPごとにオブジェクトストレージの仕様が異なるためしやすい ※特定CSPに合わせた作りにするしやすい推奨ネットワーク接続どんなネットワーク構成でもOK どんなネットワーク構成でもOK ◯ Transit Gateway △ Private Link ※仲介サービスのEndpointをベンダー VPC内に置くかどうかで決まる ◯ Transit Gateway Private Link ※各ベンダーからファイルサーバー置き場までの通信があるため配置場所不要不要共通機能住記ベンダーのCSP 共通機能住記ベンダーのCSP 料金通信費用のみオブジェクトストレージ費用のみオブジェクトストレージ費用例：AWS Transfer Family 5年約184万円ファイルサーバー費用例：EC2 / AWS FSx for Windows File Server / オンプレミス推奨用途 ASPが開発できるのであれば良い方法単一CSP内だけ完結する場合複数CSP間連携が必要な場合複数CSP間連携を想定した複数のケースで統一した方法を利用したい場合複数CSP間連携が必要な場合複数CSP間連携を想定した複数のケースで統一した方法を利用したい場合 20業務以外（移行困難も含む）からの連携もある場合は、認証なども含めた方式の選択をする必要がある

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 75 ガバメントクラウドへの接続ネットワーク検討必要帯域・費用・SLA・冗長化（BCPポリシーによるリージョン冗長など）マルチクラウド回線サービス都道府県 WAN ベンダー共同回線 LGWAN （LGCS）都道府県ノード専用回線セキュリティポリシー要件充足要件充足要件充足※他自治体と論理分割要件充足※他自治体と論理分割要件充足※他自治体及びLGWANと論理分割 IPアドレス重複調整庁内側庁内及びベンダー（クラウド）間庁内及びベンダー（クラウド）間自治体間自治体間※既に割り当て済み? 庁内（番号利用事務とLGWAN）側ベンダー（クラウド）間スケジュール回線敷設時間回線敷設時間回線敷設時間 ※既にデータセンターまでの回線が敷設されていることを前提とするとデータセンターからクラウドへの回線敷設回線準備期間 ※都道府県WANからクラウドへの回線敷設接続の5ヶ月-6ヶ月前 GCASアカウント申請→CSPアカウント払い出し →LGCS申請→LGCS接続 GCASアカウント申請は利用開始の2ヶ月前に申請（払い出されるバッファも加味する必要あり） LGCSパラメータシート申請はCSPアカウントが必要（接続の3ヶ月前）参考)LGCS接続パラメータ設定の躓きポイントを考えてみた（AWSのみ） https://note.com/techniczna/n/n3bd6220e4ad0 参考) 20業務外・マイナンバー系NWとのCIDR重複 https://aws.amazon.com/jp/blogs/news/govcloud-hint-for-network-cidr/ • 都道府県における費用負担有無と接続方式（都道府県経由か、直接接続か）によって、自治体ごとにコスト負担増か否かが変わってくる • マイナンバー系のシステムの移行により、今までより多くの帯域や耐障害性が求められることによって、LGWAN自体のコストが上がってしまわないかに注意する必要がある開通時期や価格に意識が必要（都心から離れれば離れるほど、コスト高及び開通まで時間がかかることが一般的） 20業務と20業務以外の配置の関係で、データセンターからクラウドへの集約回線を引くサービス

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 76 参考）ベンダーデータセンター回線共有パターンの考慮事項ネットワーク接続のあり方検証検証結果： IPアドレス重複回避の実装 VPC 192.168.3.X VPC 192.168.13.X 20業務外 20業務外既存敷設回線既存敷設回線ベンダー共同回線 Transit VIF DXGW TGW 192.168.1.X 192.168.2.X 192.168.12.X 192.168.11.X 自治体間、ベンダー間、オンプレ -クラウド間でのIPアドレス重複回避を調整しなければならないベンダーデータセンター IPSec VPNによる IP重複回避ベンダーデータセンター等で複数自治体の回線を集約する場合、自治体間のIPアドレス重複への考慮が必要だが、ベンダー運用アカウントの Transit Gatewayへ各自治体システムからIPsec VPNで接続することにより、自治体間のIPアドレス重複が可能になる IPSecVPN による遅延（検証結果では 5% 程度）を想定した必要帯域とする必要 VPC 192.168.3.X VPC 192.168.13.X 20業務外 20業務外既存敷設回線既存敷設回線ベンダー共同回線 Transit VIF Transit VIF DXGW DXGW TGW TGW 192.168.1.X 192.168.2.X 192.168.12.X 192.168.11.X ベンダーデータセンター NAT変換での対応も検討されるが、ルール策定が求められるだけでなく、ネットワーク設計の再検討や、ログ上も懸念があることを理解する団体ごとにIPSec VPNをTGWに引く団体ごとにNAT構成にする NAT NAT

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 77 ルータールーター Tokyo Tokyo 非機能要件とネットワーク接続イメージネットワーク運用管理補助者の必要性（TGW・オブジェクトストレージ・DNS等） Transit VIF DXGW TGW AZ① AZ② AZ間の冗長のみとするか EC2/RDS EC2/RDS EC2/RDS EC2/RDS VPC-A VPC-N ネットワーク運用管理 Transit VIF Osaka Transit VIF DXGW TGW AZ③ EC2/RDS EC2/RDS VPC-ZA VPC-ZN ネットワーク運用管理 Transit VIF システム障害のみに備えるか（TGW冗長）リージョン間でシステム冗長するか Backup Backup リージョン間のネットワーク冗長するかリージョン障害リージョン障害リージョン障害 AZ障害データ障害 TGW・共通機能用ネットワーク運用管理アカウントの必要性（拡張性等）ネットワーク運用管理の必要性 S3 Route53 オンプレミス・庁舎リージョンへのネットワーク冗長をするかメインリージョンのみ冗長化をするかリージョン障害 Backup 庁舎内にバックアップもしくは冗長構成 ※一部システムのケースもデータ障害例：統合滞納管理システムを導入予定だがバックアップ用のストレージは業務システム側では用意しないと言われている。全体ジョブ管理・バッチ管理 ※20業務でない共通機能は非機能要件を満たす必要はない早期移行団体の場合、ベンダー環境内にTGW を作ってしまうと、ロックイン要素になりかねないリージョン間バックアップのみとするか

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 78 ガバメントクラウド移行の検討におけるステップとポイント各自治体の状況によって答えが異なるため、自分たちで情報を整理して、最適解が何なのかを決めなくてはならない現在の状況を整理最適解目的と許容の設定移行の情報収集方向性の検討妥当性の確認リスト整理 / 構成イメージ図関係各所との共通理解再検討コスト・安定稼働・国の施策法律／憲法遵守等検討項目に対する選択肢とメリット・デメリットだけでなく、改善の余地があるか、そもそも効果があるか本日のメインテーマ

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. 79 最終イメージ図：今後やらなくてはいけないことの整理予算申請をするための予算額の把握をするために、全体構成と要件を整理し、調達物を確定する庁舎データセンターガバメントクラウド(AWS) 20業務以外 NEC 共同利用VPC ネットワーク運用管理アカウント NEC 運用管理富士通共同利用VPC 富士通運用管理 TGW Transit VIF DXGW ガバメントクラウド(OCI) RKKCS RKKCS 運用管理オブジェクトストレージオブジェクトストレージファイルサーバー DNS 時刻同期 20業務以外専用線専用線

Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. お困りの自治体・事業者の皆様に私が、ご支援可能なことメニュー • クラウド・アプリケーションアーキテクチャ技術の正しい理解トレーニング • クラウド利用指針の策定ワークショップ • 標準化に伴うガバメントクラウド移行に向けたトレーニング • ガバメントクラウド移行に伴うパブリッククラウド勉強会・ハンズオン • ガバメントクラウド移行にあたって構成・検討支援（運用管理補助者も含む）等々、それ以外も必要に応じて対応いたします依頼方法 • 個別に依頼（各自治体での講演依頼スキームやCIO補佐官制度など） • 地方公共団体の経営・財務マネジメント強化事業 https://www.jfm.go.jp/support/development/keieizaimu.html ご依頼はX(@jnakajima1982)のDMか、 [email protected]までお気軽に!! ご相談からでもOKです!!

第3回 自治体システム標準化・ガバメントクラウド勉強会資料

第3回 自治体システム標準化・ガバメントクラウド勉強会資料

Featured

Transcript

第3回　自治体システム標準化・ガバメントクラウド勉強会資料

第3回　自治体システム標準化・ガバメントクラウド勉強会資料