インフラとアプリの境界線と委譲の設計 2026-09-26 Platform Engineering Kaigi 2026 スポンサーセッション すずきまさし Copyright © 3-shake, Inc. All Rights Reserved. 

おまえだれよ ● ● ● すずきまさし/masasuzu/@masasuz 株式会社スリーシェイクSreake事業部シニアアーキテクト クラウドインフラなんでも屋さんをしてます ○ お客様の外部から ■ 設計、運用、構築等の技術支援を行います。 ○ お客様の内部から ■ インフラチームの一員として内製化支援も行います。 ● 得意領域 ○ AWS ■ AWS Community Builder Cloud Operation Since 2024~2026 ■ 2026 Japan All AWS Certifications Engineers ○ Google Cloud ■ Google Cloud Partner Top Engineer 2026 ○ Terraform Copyright © 3-shake, Inc. All Rights Reserved. 2 

Mission / Vision インフラをシンプルにして イノベーションが起こりやすい世界を作る 本来実現したかった『技術が生み出す価値の享受』『イノベーション』、 その前に立ちはだかる『複雑化・巨大化し続ける技術やプロセス』。 スリーシェイクはこれを社会の課題と捉え、私たちの持つ技術力によって 解決できるよう活動しています。 労苦（Toil）を無くすサービスを 適正な価格で提供し続ける 私たちが考える本当に必要なものは『適切なカルチャー』、 『適切なエンジニア供給と育成』、『適切なITソリューション』。 これらを、あらゆるレイヤーで誰もが恩恵を受けられる適正な価格で 提供し続け、私たちが社会の根幹を担っていくことを使命とします。 Copyright © 3-shake, Inc. All Rights Reserved. 3 

Business 日本のSREをリードする あらゆるサービスを 連携するハブになる インフラ・アプリ・データ・セキュリティ・AI 全方位で顧客の内製化を推進する伴走支援 あらゆるSaaSをノーコードで連携する クラウド型ETL/データパイプラインSaaS 事業者が抱える セキュリティリスクをゼロに 「いいエンジニア」を あなたのチームに セキュリティ対策をワンストップで 実現する脆弱性診断SaaS ハイスキル人材の紹介とHR戦略支援の両輪で エンジニア組織の課題に併走 Copyright © 3-shake, Inc. All Rights Reserved. 4 

Sreakeの事業 SREの思想・技術をベースに、4つの領域でプロフェッショナルサービスを提供しています ・アプリケーションモダナイゼーション ・プラットフォーム構築 / 運用高度化 Google Cloud / AWS / Kubernetes / IaC API / マイクロサービス / リファクタリング ・信頼性 / 生産性 / DevEx向上 ・開発プロセス改善・高度化 SRE / o11y / CI/CD / Platform Engineering SRE / DevOps ・セキュリティ強化 アセスメント / SIEM / WAF / CSIRT AI駆動開発 / 開発環境 / CI/CD Application Modernization ・組織組成・強化 アジャイル / スクラム / チームトポロジー ・生成AI導入 / 活用 ワークショップ / RAG ・データベース構築 / 移行 / 性能改善 ・AIエージェント開発 PostgreSQL / MySQL / Spanner / TiDB MCP / A2A / 既存システム連携 AI / ML ・モデル開発環境構築 MLOps / データフライホイール ・データ基盤構築 Looker / Snowflake / BigQuery / Redshift DBRE ※記載されている会社名、製品名、サービス名等は、各社の登録商標または商標です Copyright © 3-shake, Inc. All Rights Reserved. 5 

目次 1. 2. 3. 4. 5. 境界線は2つある 機能の境界 - 一つのリソースの中に線を引く 役割の境界 - チームが決める 片方を動かすと、もう片方も動きます まとめ Copyright © 3-shake, Inc. All Rights Reserved. 6 

01 境界線は2つある Copyright © 3-shake, Inc. All Rights Reserved. 7 

インフラとアプリの境界線をどこに引いてますか 引き方 良いところ 困ること 全部インフラが持つ 安全 インフラのデプロイ待ちで開発が止まる 全部アプリに渡す 早い 野良運用が広がり、作り直せない構成が残る どちらに寄せすぎても不都合があるのでどこかに線を引くことになります Copyright © 3-shake, Inc. All Rights Reserved. 8 

インフラとアプリの境界線には2つの意味があります Copyright © 3-shake, Inc. All Rights Reserved. 9 

どこに引くかには、答え方が二通りあります 何を分けるか 判断軸 機能の境界 プロビジョニング (IaC) と アプリケーションデプロイ 技術的な性質 一つのリソースの中の設定値をインフラ側とデ プロイ側のどちらが管理するか 役割の境界 共通プラットフォームを挟んで 開発チームがどこまで自分で動けるか チームの状態 IaC 習熟度、逸脱要求 判断軸が違うので分けて考えます Copyright © 3-shake, Inc. All Rights Reserved. 10 

そして、一度引いたら終わりではありません 1. まず「機能の境界」から定義する 2. 状況に応じて「境界線を引き直す」 技術的な性質が先に定まる チームの変化に合わせて柔軟に更新 変更頻度や影響範囲といった技術的特性 は比較的早 期に明確にします。 IaCの習熟度や開発チームの規模・状態の変化に伴 い、役割の境界も変化します。 そのため、まずはインフラプロビジョニングとアプリデプ ロイの機能的な切り分けから着手します。 境界線は一度引いたら終わりではなく、継続的な見直 しと再設計 が必要です。 境界線は固定せず、技術と組織の成長に合わせて引き直していきます Copyright © 3-shake, Inc. All Rights Reserved. 11 

今日のスタンス 今日の話は、公式ドキュメントで裏が取れている部分と、 私がクライアントワークを通して見てきた範囲での見立てが混ざっています。 お客様ごとに技術スタックや構成が大きく異なるので、 どの構成にも出てくる、インフラのプロビジョニングとアプリのデプロイを題材にします。 IaC ツールは Terraform、デプロイ先は ECS と Cloud Run を想定しています。 Kubernetes は扱いません。 Copyright © 3-shake, Inc. All Rights Reserved. 12 

02 機能の境界 — 一つのリソースの中に線を引く Copyright © 3-shake, Inc. All Rights Reserved. 13 

ECS も Cloud Run もインフラでもありアプリでもあります 同じリソースなので Terraform側でもデプロイ側でも変更ができてしまい競合します Copyright © 3-shake, Inc. All Rights Reserved. 14 

よくある事故 前提 ● TerraformではCloud Runのリソースを管理 ● デプロイ側ではイメージや環境変数などアプリケーションで責任を持つ値を管理 ○ gcloud run deployを使用 出来事 ● Terraform側でCloud RunのService Accountを変更したら、初期設定時のイメージに巻き戻った 原因 ● Terraform側でimageをignore_changesに設定していなかった ○ そのためimageの差分を検知して上書いた ● どの値をどこで責任を持つか明確になっていなかった ○ 境界線を定めていなかった Copyright © 3-shake, Inc. All Rights Reserved. 15 

インフラ、デプロイどちらでアプリリソースの値を管理するか 管理の仕方 懸念 Terraform が全部持つ イメージを変えるたびに apply が要る Terraform が持ち一部を ignore_changes で外す その値に関して、 Terraformのコードが実態を表 さなくなります リソース定義はデプロイ側が持つ インフラ由来の値を渡す必要が出る アプリとインフラはライフサイクルが異なるので、可能ならリソース自体を分けたほうが望ましいです。 アプリのリリースと一緒に変わる値は、デプロイ側に寄せるとライフサイクルを分離しやすいです。 ただし、Cloud Run を ALB の後ろに置くときなど、 Cloud Runが存在することを前提とするので、二つ目を選ぶ しかない場面もあります。 Copyright © 3-shake, Inc. All Rights Reserved. 16 

サービスは Terraform で作りデプロイで変更する項目を無視 resource "google_cloud_run_v2_service" "app" { # ... lifecycle { ignore_changes = [template, client, client_version] } } ● ● ● デプロイ側で管理するパラメータに ignore_changes を設定します これによりサービスの箱は Terraform が持ち、リビジョンの中身はデプロイ側が持ちます ただしその属性について、 Terraformのコードが実態を表さなくなります Copyright © 3-shake, Inc. All Rights Reserved. 17 

インフラとデプロイで分けると必ず受け渡しが発生します 分けた瞬間インフラ由来の値をデプロイ側に渡す必要が生まれます ● ● ● ● Target Group Subnets / VPC Connector Service Account / IAM Role Secret(s) Manager このインタフェースをどこに置くかが機能の境界の設計そのものです Copyright © 3-shake, Inc. All Rights Reserved. 18 

インタフェースの置き方には段階があります 右に行くほど上位という成熟度モデルではありません。 依存関係をどこまで明示的な契約にするかの選択肢です Copyright © 3-shake, Inc. All Rights Reserved. 19 

置き所の四段階 Copyright © 3-shake, Inc. All Rights Reserved. 20 

置き所の四段階 段階 渡し方 壊れ方・負担 手で写す コンソールで値を見て定義に書 き写す コピペミス 連動していないので変更漏れ 名前で引く aws / gcloud でリソース名から 引く 名前の付け方を変えると壊れる。 デプロイ側にクラウドの読み取り権限が要る output を読む terraform output や tfstate-lookup で読む 内部を整理しても壊れない。 state の読み取り権限が要る (専用 state で絞れる) ストアに書き出す Terraform が S3 / Cloud Storage / Parameter Store / Secret(s) Manager に値を書き 出す 管理するインフラリソースが増える Copyright © 3-shake, Inc. All Rights Reserved. 21 

四段階はECS でも Cloud Run でも取れます 段階 ECS Cloud Run 手で写す コンソールの値をタスク定義に書く コンソールの値をマニフェストに書く 名前で引く aws コマンドでリソース名から引く gcloud コマンドでリソース名から引く output を読む tfstate-lookup、ecspresso の tfstate 参照 tfstate-lookup ストアに書き出 す S3 / Parameter Store / Secrets Manager の JSON をデプロイ時にパースする GCS / Secret Manager の JSON をデプロイ時に パースする 道具が違ってもインフラ由来の値をデプロイに渡す問題は残ります Copyright © 3-shake, Inc. All Rights Reserved. 22 

ECS と Cloud Run で見てみます Copyright © 3-shake, Inc. All Rights Reserved. 23 

ECS - ecspresso サービス定義とタスク定義を JSON のファイルで持ち、テンプレートとして tfstate から値をもらって埋めてから デプロイします # ecs-service-def.json "loadBalancers": [{ "targetGroupArn": "{{ tfstate `aws_lb_target_group.app.arn` }}", "containerName": "app", "containerPort": 8080 }] ● ● タスク定義: コンテナのイメージ、 CPU/メモリ、環境変数などの定義 サービス定義 : 何個動かすか、どのロードバランサに繋ぐかなどの定義 Copyright © 3-shake, Inc. All Rights Reserved. 24 

Cloud Run - tfstate-lookup 対応するのは、 tfstate-lookup で引いた値をマニフェストか gcloud のオプションに埋める形です SA=$(tfstate-lookup -s "${STATE}" google_service_account.app.email) # マニフェスト YAML に埋めてから、丸ごと置き換える SA="${SA}" envsubst < service.yaml > rendered.yaml gcloud run services replace rendered.yaml # または、gcloud run deploy のオプションに渡す gcloud run deploy app --image "${IMAGE}" --service-account "${SA}" Copyright © 3-shake, Inc. All Rights Reserved. 25 

03 役割の境界 — チームが決める Copyright © 3-shake, Inc. All Rights Reserved. 26 

ここまでは値と道具の話でした Copyright © 3-shake, Inc. All Rights Reserved. 27 

まず共通プラットフォームの実体 ECS / Cloud Run の文脈では、だいたいこれらの総体かなと思います ● ● ● ● Terraform モジュール群 新しいサービスを作るためのテンプレート ○ リポジトリのテンプレート、定義ファイルからの生成など CI のワークフロー 承認フロー 開発チームを利用者として必要なものから作ります Copyright © 3-shake, Inc. All Rights Reserved. 28 

ゴールデンパスはこれらをつないだ推奨の道筋です Red Hat の定義 > "A golden path is an opinionated, well-documented, and > supported way of building and deploying software within an organization." Copyright © 3-shake, Inc. All Rights Reserved. 29 

ゴールデンパスは強制ではないです Red Hat > "Golden paths should be an optional way of building and deploying. > To allow and foster innovation, there should be flexibility to > drift from the standard workflows." platformengineering.org > "The goal is not to create a 'golden cage,' > but rather to provide a 'golden path'" Copyright © 3-shake, Inc. All Rights Reserved. 30 

標準で足りるチームと外れたいチーム Copyright © 3-shake, Inc. All Rights Reserved. 31 

逃げ道がないと標準そのものが捨てられます ● ● 少しでも合わない要件があると、標準を丸ごと捨てて自前で作られます 部分的に外れる道 (エスケープハッチ = ゴールデンパスから外れたいときの逃げ道 ) が要ります では、開発チームにどこまで渡すのか Copyright © 3-shake, Inc. All Rights Reserved. 32 

どこまで委譲するかには段階があります ※委譲レベルの分類は本発表での整理 3 がゴールデンパス、 4・5 は逃げ道の先です 1 ticket-ops trap (チケットに応え続けるだけの状態 ) です Copyright © 3-shake, Inc. All Rights Reserved. 33 

開発チームに渡っているもの 要素 内容 書く権限 設定ファイルや IaC を編集できる 適用する権限 変更をクラウドに反映できる (IAM、CI の実行権限) 結果への責任 運用、障害対応、コスト、セキュリティ等の結果を引き受ける 書く権限だけ渡すとレビュー待ちが残ります AI で楽になるのは書くところです。 適用する権限と結果への責任は AI を使っても人間が引き続き持ちます。 Copyright © 3-shake, Inc. All Rights Reserved. 34 

委譲を進めることは無条件によいことではありません 軸を右に動かすほど、アプリチームの認知負荷は上がります 右に行くほどよいとは必ずしも言えません Copyright © 3-shake, Inc. All Rights Reserved. 35 

どこが望ましいかは組織単位では決まりません 同じ会社でも、チームごとに違ってよいはずです 以下の2つを見て適切な方法を選んでください ● ● IaC 習熟度 ○ 安全に書くことができ、変更の影響を理解できるか 逸脱要求 ○ 標準からどれだけ外れたいか Copyright © 3-shake, Inc. All Rights Reserved. 36 

04 片方を動かすと、もう片方も動きます Copyright © 3-shake, Inc. All Rights Reserved. 37 

片方を動かすと、もう片方も動きます 役割を動かすと、機能の境界が動く 委譲を進めてアプリチームが自分でデプロイするようになると、インフラチームが値を見て手で写す、という渡し 方は続けられません。インタフェースを output やストアのように、書き出された形に移すことになります 機能の境界を書き出していないと、役割は動かせない どこで分けたかを書き出していないと、委譲した先で事故になります Copyright © 3-shake, Inc. All Rights Reserved. 38 

よくある事故(再掲) 前提 ● TerraformではCloud Runのリソースを管理 ● デプロイ側ではイメージや環境変数などアプリケーションで責任を持つ値を管理 ○ gcloud run deployを使用 出来事 ● Terraform側でCloud RunのService Accountを変更したら、初期設定時のイメージに巻き戻った 原因 ● Terraform側でimageをignore_changesに設定していなかった ○ そのためimageの差分を検知して上書いた ● どの値をどこで責任を持つか明確になっていなかった ○ 境界線を定めていなかった Copyright © 3-shake, Inc. All Rights Reserved. 39 

05 まとめ Copyright © 3-shake, Inc. All Rights Reserved. 40 

まとめ 1. インフラとアプリの境界線は二つある 機能の境界は一つのリソースの中の設定値をインフラ側とデプロイ側のどちらが管理するかです。 役割の境界は開発チームがどこまで自分で動けるかです。 2. 機能の境界はどちらで管理するかと値の渡し方で決める 変更のライフサイクルに合わせて管理主体を分ける。 インフラ由来の値の渡し方には四段階がある 3. 役割の境界に唯一の正解はない 同じ会社でも違ってよい。ゴールデンパスには逃げ道が要ります 4. 二つの境界線は独立していない 委譲を進めると機能の境界も動きます。 チームや道具が変わったら境界線を書き出して引き直します。 境界線は単に責任を分ける線ではなく、依存関係を設計するインターフェースです。 Copyright © 3-shake, Inc. All Rights Reserved. 41 

ありがとうございました Copyright © 3-shake, Inc. All Rights Reserved. 42