【イベントレポート】事業者だけの標準化・ガバクラ勉強会
2024年6月11日に「事業者だけの標準化・ガバクラ勉強会」が開催されました。
事業および参加者の特性により本勉強会は匿名およびチャタムハウスルールでの実施となりました。一部実名の方もいらっしゃいましたが本記事ではチャタムハウスルールに則り発言者がわからないようにしてお届けいたします。
※なお、本記事の内容は2024年6月11日時点のものであり、以後アップデートされた情報もありますので業務で参照される際には最新情報をご確認されるようご留意ください。
事業者だけの標準化・ガバクラ勉強会の概要
主催者から以下の主旨説明がありました。お互いに協力しあえることがあるのではないか。課題の共通認識を持つことで課題解決が少しでも進められるのではないか。
本編は大きく2部構成とし、
テーマ①「ベンダー間データ連携の調整事項や課題」
テーマ②「ネットワーク（LGWAN/LGCS）、マルチクラウド」
の２テーマでそれぞれ異なる登壇者でパネルディスカッションを行いました。
本記事ではテーマごとのトピックを紹介してまいります。
テーマ①「ベンダー間データ連携の調整事項や課題」
①-1：全体バージョンが事業者間で揃わない・・・？
全体バージョンをどの版で進めるのか？という問題提起がされました。
バージョンをとりまく状況は以下のようなものとなっているようです。
デジタル庁が出している全体バージョンの最新（2024年6月11日時点）は「4.0版」
適合日基準日を基準に考えると、令和8年4月1日の時点では令和4年度末の仕様に準拠していればよいということになる。つまり「1.1版」がベースとなるはず
ところがデジタル庁が出している適合確認ツールでは「1.1版」は選択不可となっており（2.0版以上が選択肢になっている）、公式文書が矛盾している
そのため現状は各事業者がバラバラのバージョンで実装している状況となっているのではないか
あたり前ですがバージョンが異なるとシステム連携ができません。
登壇者の中でも「ウチは1.1版で開発を進めている」「3.0版で進めている」「1.1版をベースに特定業務のみ2.0版」とバラつきがありました。
いくつか発言も掲載します。
正直、ここまで改版されるとは思っていなかった。さらに今後も半期に1度の改定が行われることが想定されている。どうやって足並みを揃えるのか。
モデレーター：誰が決めるべきなのか？
登壇者A：決めなければ接続試験自体が進められないので今年の年末あたりには決まっていないと厳しい。デジタル庁が決めるのが筋だと思う。
登壇者B：決められるなら決めてほしい。標準仕様は制度所管省庁、データ要件・連携要件がデジタル庁という管理体制となっているのでデジタル庁だけでは決められないのが厳しいところ。
モデレーター：自治体職員ができることはあるのか？
登壇者：ないと思う。事業者は複数の自治体をまたいだパッケージとしているので自治体内部で調整できる話ではない。
そもそも同じ版同士でもシステム連携がちゃんとできるのかは実際にテストしてみないとわからないのではないか。
①-2：テストの時期とデータ調整事項について
次に実際のシステム連携のテストの話です。どういう手順・工程で実施するつもりなのか。
このテーマではまず前提として、
適合性確認をとったからといってシステムが動くわけではない。あくまでフォーマットチェックでありしかるべきシステム連携テストが必要であるということが話題となりました。
ただデジタル庁が示す手順にはテスト工程の詳細な記載はないこともあり、自治体職員がその必要性に気づいておらず（もしくは気づいていても主導することが難しく）、各事業者がバラバラに計画している状況のようです。事業者同士のコミュニケーションが求められつつもハブとなる契約主体は自治体であり、現状ではうまく整理できていない、と。
適合確認はフォーマットのチェックだけがなされるという認識。認定を得たからといって、連携できるとは考えていない。
可能であれば、自治体を通して、パッケージベンダーと会話ができれば理想的だが、実情時間も人も足りない。ベンダー同士だけでもできることがあればと思う。
こういったコミュニティーや事業者協議会などを通じて、必要な作業などにおける標準スケジュールやサポートポリシー、改版ポリシーなどを決めるべき。
モデレーター：連携テストの工程はどのようなものが想定される？
登壇者：従来のオンプレミスだと同じネットワーク内にサーバーがあり接続自体は難しくなかった。マルチベンダー・マルチクラウドとなる場合は大変だと思う。
まずはネットワークの疎通（同じCSPでもアカウントやVPCが異なれば説特設定が必要だし、接続方法も複数ある）、次に認証・認可（認証が通るか、権限設定が適切か）、そしてやっとアプリケーションのインターフェース確認、その後に業務的な連携テスト、移行データのバリエーション網羅などのテストを行うこととなる。これだけの工程を複数の事業者間で調整・準備し、手戻りも含めてスケジュールを組むのは容易ではない。もちろんテストなので想定通りいくわけがない。リスク・バッファも考慮して管理していく必要がある。これを自治体職員にやれというのは酷ではないか。
①-3：オブジェクトストレージ、認証基盤
テーマ①最後はシステム連携の推奨方法としてデジタル庁より示されているオブジェクトストレージと認証基盤について。各社どのように考えているのか。
ここでの大きな話題は以下の２つでした。推奨構成通りにするとコストもシステムの複雑性も大きくなってしまうのではないかという懸念です。
マルチクラウドの場合、認証基盤が必要となるがコストが大きくなってしまうのではないか
オブジェクトストレージのAPIを使うのではなくSFTPでの連携が適切なのではないか
オブジェクトストレージと連携するためだけのために認証認可サーバーがいるのかというのは疑問。
連携元で1つのバケットを共有するような形で、１対１でつながるのが前提になっている。実質ほぼクローズドの連携をしているのにわざわざ認証がいるのか？と思っている。
おそらく大規模自治体や政令指定都市については、2社の連携基盤のようなものはほぼ導入されている。かつ共通基盤ベンダーのような事業者がいて統合運用みたいなことをしているのでそれほど難しくなくオブジェクトストレージのファイル連携を実現できると思う。
一方で、中小規模の自治体に関しては、連携基盤がない自治体も結構あると推測される。
事実上、住基ベンダーが連携基盤の作業をするのが必須になっていて、標準化対象の20業務などについても同様に、オブジェクトストレージを経由した連携をさせるとなると仮の払い出しやバケットポリシーの設定のためにIAMロールをヒアリングしたりなどと様々な作業をやらねばならなくなる。
標準的な認証の基盤モデルを作られてしまうとコストが大幅に跳ね上がる。
改めて、オブジェクトストレージでやる必要があるのかというのは疑問。
さらには、この要項は23年度3月に滑り込みで入ってきた。その点も含めて大きな課題ではないかと思っている。
テーマ②「ネットワーク・マルチクラウド」
登壇者を入れ替えて２つめのテーマです。
②-1：ネットワーク運用アカウント
まずは「ネットワーク運用アカウントの是非」について。
CSPによっては必須ではないがあったほうが運用がシンプルになるものなので準備はしておいたほうが良さそうだが、各事業者から出てくるシステム構成には必要性の記載にバラつきがあり、自治体によっては必要性を認識していないのではないか、という話がでました。
そもそも、ネットワーク運用管理補助者が必要かどうか自治体だけでは判断できない状況。ASPベンダーに個別に聞いてもASPベンダーが判断するものではないので自治体職員は決めきれないのではないか。
ネットワーク運用はASPベンダーが持っているというパターンもある。ただASPベンダーが他の事業者と調整しながらというのは大変。そのため、現実解として自治体に本番用のネットワーク運用アカウントを持ってもらって、各社で運用しようという形になると思う。
ネットワークアカウントは各自治体で持っている方がいいと考えている。
最大20業務ベンダーが分かれる可能性もある上に、オンプレとの接続もある。その上でネットワークアカウントを自治体自身で持つべきか、運用管理補助者に委託するのかを考えるべき。
②-2：データ移行用のルート
仮にシステム構築が進んだとして、リリース時のデータ移行はどうするのか、という話題です。リリース時のことなので緊急の課題ではないかもしれませんが検討・準備しておかないとリリース失敗という結果になりかねません。
データ移行を行う回線の帯域が問題となるのでは、という懸念です。
個別に専用線を敷設している団体はある程度キャパシティ計算も可能でしょう。（とはいえ他団体や民間の会社と共用している機器や回線もあると思うので懸念は残りますが）
問題はLGWAN（LGCS：LGWANガバメントクラウド接続サービス）を使ってガバメントクラウドへの接続を想定している団体です。令和7年度の後半、おそらく令和7年の秋ごろから1月にかけて全国の自治体が移行を計画していると思います。ほとんどの団体が週末や年末年始などの連休でのデータ移行を考えているはずです。
LGWAN（LGCS）の回線は複数団体のデータ移行に耐えられる帯域なのか
事前のデータ移行検証ができず本番一発勝負になってしまうのではないか
その結果、リリース当日にデータ移行が失敗することも十分考えられるのではないか
データ移行に必要な帯域がどれほど必要か、検討もつかない。
データ移行の時だけ、通常の運用時の帯域よりも太くしたいと言われる。
メインとサブでわけて、冗長性を担保するだけではなく、サブ回線にも流すことで経路の優先度をうまく利用し、メインとサブでロードバランスをとれないか？という相談が来ることもある。
特にLGWAN（LGCS）使ってデータ移行を考えるとLGWANと共有しているので、いつデータ移行をするのか、タイミングを見なければ支障が出るのではないか。
モデレーター：データのサイジングから回線のキャパシティなどを計算するといったことは理論上はできるだろうが、現実的なのか？
登壇者：１番混み合うのは2025年〜2026年の年末年始の時。その際を計算で出すのは、理論上はできなくはない。ただしベンダーに時間単位で移行スケジュールを提出させ、全てとりまとめて、それらを必ず守るという風にするのであれば…。となると現実的ではない、ということになる。
例えば、ある週末に10団体分程度の帯域を確保しようとしている。自社に閉じた専用線利用の前提だと1団体につき必要な帯域については計算が可能だし事前検証もできる。ただ全国で共有するLGCSなどになると想像がつかない。
②-3：マルチCSPの諸々
最後はマルチCSPでの問題について。
ここではテーマ①と同じくマルチクラウドでのファイル連携の課題が話題になりました。OCIでのオブジェクトストレージ連携はカスタムアプリの作成が必要となることから、SFTPでのファイル連携が良いのではという声が参加者のチャット欄で多く出ました。
オブジェクトストレージをどうするか。先ほどの議論で認証認可サーバーは不要なのではという議論があった。私の認識では、オンプレのシステムも残るので、認証認可サーバーが必要だと考えている。
したがって、認証認可サーバーをどこに立てるかについては、注意しなければならず、そもそも誰が決めるか。誰が立てるのか。という問題があるのではないか。
一番大きな問題は、自治体側の負担が大きいこと。
出てくるドキュメントはCSPごとに異なるものになる。それぞれで管理して、自治体が見なければならない。統合は自治体がしなければならず、自治体負担が単純に倍になると考える。
OCIでは一時的なクレデンシャルを発行できないので、認証用のカスタムアプリケーションを作成することが、デジタル庁から5月に出たリファレンスアーキに書かれている。この中で、一次クレデンシャルの代わりに署名つきURLを発行することが方法だというのが許容されている。
最後に
事業者の方々からリアルな問題提起がされた場となりました。
ここから事業者の方々、自治体の方々、デジタル庁の方々も含めて少しでも問題が解消していくアクションが起きれば幸いです。