Application Design Centerとは？ Google Cloudの設計をテンプレート化する新しい方法
Google Cloudの環境を作るとき、毎回ゼロから構成を考えていないでしょうか。
ネットワーク、実行環境、データベース、権限を決め、その内容をTerraformへ落とし込み、レビューしてからデプロイする。IaCを使っていても「どんな構成にするか」は案件ごとに考えている、という現場は少なくないと思います。
Application Design Center（以下、App Design Center）は、この順番を変えます。よく使う構成をテンプレートとして先に用意し、開発者はそこから自分のアプリケーションを作ります。設計した内容からTerraformが生成されるので、構成図とコードを別々に作る手間もなくなります。
この記事では画面の操作方法ではなく、これを使うとGoogle Cloudの設計がどう変わるのかを見ていきます。App Design Center自体は2025年12月にGAになりましたが、機能ごとに提供段階が違うため、本文でも区別して書きます。
- 1. 毎回ゼロから設計しない
- 2. プラットフォームチームと開発者の役割を分ける
- 3. Terraformが不要になるわけではない
- 4. 「リソース」ではなく「アプリケーション」で見る
- 5. 設計段階でルールを入れる
- 6. まとめ
1. 毎回ゼロから設計しない
社内向けのWebアプリケーションを作るたびに、ネットワークをどう切るか、実行環境に何を使うか、データベースは何にするかを一から決めていたとします。
似たようなシステムでも担当者ごとに構成が変わり、レビューする側は毎回はじめから確認することになります。判断の質が担当者の経験に左右され、うまく作れた構成もその人の中に残るだけで終わります。
困るのは、後から見たときです。似ているのに少しずつ違う環境が並ぶと、どれが正しいのか分からなくなり、改善しようにも一つずつ直すしかありません。
図1 出発点が白紙から標準テンプレートに変わる
App Design Centerでは、プラットフォームチームが標準的な構成をApplication Templateとして作ります。開発者はカタログからテンプレートを選び、アプリケーション名やリージョンといった値を設定してデプロイします。
テンプレートに置く部品は、Googleが用意したコンポーネントから選びます。ワークロードとしてCloud RunやCompute Engine（GCE）、サービスとしてGoogle Kubernetes Engine（GKE）のクラスタやCloud SQL、そのほかサービスアカウントのようなアセットが並びます。コンポーネントごとにGAとプレビューが分かれているので、使う前に対応状況を見ておくと安心です。
出発点が白紙から「会社として使ってほしい構成」に変わる。ここが一番の違いです。
2. プラットフォームチームと開発者の役割を分ける
この仕組みで分かりやすいのは、標準を作る人と使う人を分けられることです。
App Design Centerでは、チームごとにスペースという作業領域を持ちます。プラットフォームチームはこのスペースでテンプレートを設計し、試作中のものが他のチームへ影響しないようにできます。
出来上がったテンプレートは、スペースのカタログへ公開します。カタログは共有でき、別のフォルダやプロジェクトで作業しているチームからも同じテンプレートを見られます。
図2 標準を作るチームと、そこからアプリケーションを作る開発者
開発者は共有されたテンプレートを選び、必要な値を入れてアプリケーションを作ります。ここで効いてくるのが、標準テンプレートから作った場合、開発者は各コンポーネントの設定は変えられても、コンポーネントを足したり外したりはできないという点です。
自由に作ってからレビューで直してもらう流れではなく、決まった形の中で必要な調整をする流れになります。
ガードレールという言葉を使うと禁止事項を並べる仕組みに聞こえますが、実際は選べる部品と組み合わせを先に決めておく、という方が近い感覚です。
Google Cloudを使うチームが増えるほど、この差は効いてきます。
3. Terraformが不要になるわけではない
画面で構成を組めると聞くと、Terraformを書かなくてよくなるのかと思うかもしれません。そうではありません。
App Design Centerは、設計した内容からTerraformを生成します。生成されるのはmain.tf、variables.tf、outputs.tf、providers.tf、input.tfvarsといったファイルです。生成されたコードは編集でき、ダウンロードして使うことも、コードリポジトリへエクスポートして既存のCI/CDに乗せることもできます。
生成されたコードをそのままリポジトリへ出せるということは、今のレビューやパイプラインを組み替えずに済むということでもあります。設計の入り口だけを変えて、その後ろは今のやり方を続けられます。
逆向きの取り込みもあります。すでに持っているTerraformモジュールをコンポーネントとして読み込み、テンプレートの部品として使えます。こちらはプレビューで、GitHubリポジトリへのDeveloper Connect接続を用意しておく前提です。今あるモジュール資産を捨てる話ではない、と分かるところだと思います。
Terraformの代わりではなく、Terraformを書く前の設計と標準化を置く場所。そう考えると位置付けがはっきりします。
4. 「リソース」ではなく「アプリケーション」で見る
もう一つの特徴が、扱う単位です。
App Design Centerからデプロイすると、そのアプリケーションはApp Hubへ自動的に登録されます。Cloud Run、データベース、ネットワークが別々に並ぶのではなく、「この業務アプリケーションは何でできているか」という形で見られるようになります。
図3 設計からTerraform、デプロイ、App Hubまでが一続きになる
リソース単位の一覧は、数が増えてくると誰の何なのか分からなくなります。障害が起きたときにどのシステムの部品なのかを追う場面や、使われていない環境を棚卸しする場面で、この差が出ます。アプリケーション単位でまとまっていれば、変更の影響範囲や担当の当たりを付けやすくなります。
設計、デプロイ、その後の管理が同じ単位でつながる。App Design Centerを作図ツールと考えない方がよい理由が、ここにあります。
5. 設計段階でルールを入れる
テンプレートを決めるだけでも、構成のばらつきは減ります。もう一歩進めて、設計している段階でチェックを入れる仕組みもあります。
テンプレートにセキュリティフレームワークをひも付けると、アプリケーションを組んだ段階で評価でき、ポリシー違反を示すスコアカードが出ます。この評価はプレビューです。
デプロイした後に指摘を受けて直すより、作っている途中で気づける方が手戻りは小さくなります。公開範囲や暗号化の設定のように、後から変えると影響が広がるものほど、この差は大きくなります。
テンプレート側を整えておけば、そもそも違反が起きにくい構成から始められます。個々のアプリケーションで毎回チェックするより、標準側を直す方が全体に効きます。
提供段階は変わっていくので、導入を検討する時点で公式ドキュメントの最新の状態を確認してください。
6. まとめ
App Design Centerは、Google Cloudの構成を画面で描くためのツールではありません。
プラットフォームチームが標準構成をテンプレートにし、開発者はそこからアプリケーションを作る。設計内容はTerraformにつながり、デプロイするとApp Hubでアプリケーション単位に管理できる。設計から運用までを一つの流れにする仕組みです。
要点は、毎回正しい構成を考えるのではなく、あらかじめ決めた正しい構成から始めるという考え方です。
チームもシステムも増えていくほど、設計を個人の経験だけに任せず、再利用できる形にしておく意味は大きくなります。