デジタル庁が口にしないクラウド利用料削減方法

デジタル庁ガバメントクラウドチームが言及しない^*1が、大きな効果が期待できるガバメントクラウドのクラウド利用料（≠TCO）削減方法がある。プログラミング言語の変更だ。

多くの自治体のシステムはJavaかC#を用いていると思うが、GoかRustに変更することでクラウド利用料を下げることができる^*2。

Javaで書かれていたアプリケーションを、CTOの気の迷いでGoで書き直した事例のレポートがある^*3。認証と認可、データベースアクセスがあり、CRUDなのだがセッション管理もあるマイクロベンチマークよりは複雑なマイクロサービスのアプリケーションで、ユーザー数が多く高負荷な環境で実際に利用するものだ。クラウド利用料は月額250ドルから月額75ドルと、三分の一以下になったそうだ。AWSのEC2での金額で、FargateやLambdaを使った場合ではないが、リソース消費量が格段に抑えられたのは間違いない。開発効率や高負荷時のパフォーマンスはJavaの方が良いが、ディスク容量や利用メモリー量はGoはJavaの数分の一で済む^*4。

Javaだとディスクに180MB必要だったDockerイメージがGoだと15MBで済み、Javaだと400MB〜800MB必要だった主記憶装置がGoだと60MBから200MBで済んだ。今どきのサーバー（とPC）からすれば、ディスク165MBと主記憶装置600MBの差は無視できる差なのだが、パブリッククラウドにリフトした瞬間にコストに差が出てくる。オートスケールを考えると、Javaの起動8秒とGoの起動0.3秒も意味がある差異だ。オンプレミスやプライベートクラウドでの稼働と、パブリッククラウドでの稼働は、突き詰めるとプログラミング言語の選択にまで影響を及ぼしてくる。昨年11月にAWS Lambdaが（Goより僅かだが省リソースと期待できる）Rustサポートを追加した後、Web APIであればRustでも開発は苦にならないのではないかと注目されている。

デジタル庁ガバメントクラウドチームがプログラミング言語の変更を口にしないのは何故であろうか。クラウド利用料削減に、かなりの確度で効果が期待できる手段だ。デジタル庁はクラウド利用料削減のために、アプリケーションをFaaS（i.e. AWS Lambda）で動くように書き直せと言っている。そこまで書き換えるのであれば、プログラミング言語をGoかRustに絞るのも射程に入る手段だ。少なくとも、新規に書くプログラムであれば、GoかRustを選択することを推奨すべき。開発者から見てかなりの問題を抱え込むことになる^*5が、パブリッククラウドを徹底して安く利用するのであれば、それぐらいの覚悟は必要だ。狂気に思えるデジタル庁のパブリッククラウド推進なのだが、意外に日和っている。

なお、クラウド利用料削減のためにプログラミング言語を変えるよりは、VPSやベアメタルに移行する方が現実的である。

*1「ガバメントクラウドでのコスト削減の考え方｜デジタル庁」では言及されていなかった。

*2PythonかサーバーサイドJavaScript（Node.js）に変更すると十中八九で上がる。

*3Go vs Java for Microservices: We Tried Both, Here’s What Happened | by CodePulse | Dec, 2025 | Stackademic

*4Goが一概に優れていると言うわけではない。Javaの方が総合的な開発期間が短く、プロダクトの品質は上になる。Goの方が低負荷時のパフォーマンスは良いが、高負荷時のパフォーマンスはJavaの方がよい。GCの性能差と、JVMの実行時最適化が優秀であるからだ。全体のコード量はGoの方が少ないが、JavaのSpring Frameworkなどが提供する機能は、Goのフレームワークでは提供されていないことがあり、そのため認証やデータベースへのクエリーやセキュリティー対策などはJavaの方が簡潔に書ける。GoではJavaでは気にしなくて済むところまで注意しなければならない。また、Javaは（高負荷時に生じるバグの追跡に役立つ）アプリケーションサーバーのモニタリングやプロファイリングの機能が充実しているが、Goに同等のものはない。統合開発環境の機能も、Javaの方が高度だ。最初のリリースまではGoの方が早く書けたそうだが、あらかたバグを潰すまでを含めた開発期間はJavaの方が短かった。レポートでは触れられていなかったが、Javaに対してのGoの利点であった仮想スレッドはJava 21で、型推論はJava 10で追加され、null安全性もJava 8のOptionlで改善できるようになってもいる。

*5動いているアプリケーションは（改修しながら）使い続けるのが無難だ。開発費用や開発期間がかかり、それが費用削減効果を上回る蓋然性が高い。二重投資になる上、仕様落ちや障害の発生源になる。地方自治体のシステムのアプリケーションは、上の事例のアプリケーションよりも複雑。なおさら、リスクが大きい。