AIに書かせて、プラットフォームで縛る ― EKSプラットフォームで実践した責任境界と権限設計

Transcript

1. Platform Engineering Kaigi 2026 AIに書かせて、プラットフォームで縛る ― EKSプラットフォームで実践した責任境界と権限設計 2026年9⽉26⽇ 株式会社ログラス 中井 綾⼀
2. ⾃⼰紹介 中井 綾⼀ Ryoichi Nakai 株式会社ログラス SRE 株式会社ログラス 技術基盤部 クラウド基盤チームに所属。 前職では合同会社DMM.comで、Platform Engineeringに取り組んでいた。 2024年よりログラスのクラウド基盤チームに参画。 © 2026 Loglass Inc. 2
6. 本セッションで話すこと ログラスでは1年前から事業拡⼤に備えて Platform Engineering を推進してきた • EKS を基盤にしたプラットフォームを整備し、運⽤開始から 1 年で 6 チーム‧約 25 サービスまで展開した • 開発チームは Coding Agent とともに、セルフサービスで安全かつ⾼速にサービスを構築‧運⽤できる状態になった • この状態を実現できた要因は、SRE と開発チームの責任境界を明確にし、それに沿った統制を実現してきたこと 本セッションで話すこと • AI 時代における Platform Engineering の価値がどう変わったか • その中で、プラットフォームとして提供するべきものは何か • 開発チームとの責任境界をどのように引き、どのような統制を実現したか © 2026 Loglass Inc. 6
7. AI 時代における Platform Engineering の価値の変化 © 2026 Loglass Inc. 7
8. AI 時代における Platform Engineering の価値の変化 Coding Agent で、開発者は必要なものを⾃⾝で作れるようになった 以前は認知負荷が⾼く、⼿が出しにくかったインフラや CI/CD 等の構築‧運⽤を専⾨知識がなくても、 開発者が Coding Agent と共に⾃⾝で進められるようになった ただし、Coding Agent は「動くもの」を出すのであって、「信頼性の⾼いもの」を出すとは限らない その場しのぎのワークアラウンドや、セキュリティに不備のある設定も、出てきやすくなる 作れる量が増えた分、そうしたアウトプットが問題を起こす場⾯も増えていく © 2026 Loglass Inc. 8
9. AI 時代における Platform Engineering の価値の変化 認知負荷の削減から、安全に⾃律できる環境の提供へ これまで: 開発者の認知負荷の削減 • 開発者が直⾯する共通の課題を⾃⾝で解決できるよう これから: Coding Agent が安全に⾃律できる環境 • Coding Agent を使う開発者に向けて、⼈間のレビュー に、UI での抽象化やドキュメントを丁寧に揃えること に頼らずに品質と信頼性を担保できるガードレールを が重要 整えることが重要 認知負荷の削減だけではなく、統制そのものをプラットフォームとして提供していく必要がある © 2026 Loglass Inc. 9
10. AI 時代における Platform Engineering の価値の変化 プラットフォームが⽤意すべき 5 つの統制 観点 何をするか 具体例 安全な標準構成を提供する 開発者の共通の課題を標準構成で解決し、 そこから外れたものが出ないようにする ゴールデンパスになるような共通テンプレート、CIでの構成検証 必要最⼩限の権限で実⾏する ⼈間と Coding Agent が実⾏できる操作を、役割に 必要な範囲だけにする 役割ごとの RBAC、⼀時的な資格情報の付与 外部からの侵⼊を防ぐ 信頼できないものを組織の環境にデプロイさせない イメージの脆弱性スキャン、イメージ署名検証 信頼できない外部への経路を絞る 組織の情報が外に出ていく経路を絞る 外向き通信の許可リスト、サンドボックス環境の分離 誰が何をしたかを監査する ⼈間と Coding Agent の操作を後から追えるように する Git の履歴、Argo CD の履歴、CloudTrail などの証跡 5 つとも以前から⼤事だったが、AI 時代では今まで以上に重要になった © 2026 Loglass Inc. 10
11. AI 時代における Platform Engineering の価値の変化 本セッションで扱う 2 つの統制 観点 何をするか 具体例 安全な標準構成を提供する 開発者の共通の課題を標準構成で解決し、 そこから外れたものが出ないようにする ゴールデンパスになるような共通テンプレート、CIでの構成検証 必要最⼩限の権限で実⾏する ⼈間と Coding Agent が実⾏できる操作を、役割に 必要な範囲だけにする 役割ごとの RBAC、⼀時的な資格情報の付与 外部からの侵⼊を防ぐ 信頼できないものを組織の環境にデプロイさせない イメージの脆弱性スキャン、イメージ署名検証 信頼できない外部への経路を絞る 組織の情報が外に出ていく経路を絞る 外向き通信の許可リスト、サンドボックス環境の分離 誰が何をしたかを監査する ⼈間と Coding Agent の操作を後から追えるように する Git の履歴、Argo CD の履歴、CloudTrail などの証跡 この2つの統制を実現するには、開発者が何に責務を持つべきかを決め、その責務に合わせて、形にしていくことが重要 なので、まずは開発者との責任境界をどこに引くかを考えていく必要がある © 2026 Loglass Inc. 11
12. ログラスのプラットフォームにおける責任境界と統制 © 2026 Loglass Inc. 12
13. ログラスのプラットフォームにおける責任境界と統制 EKS プラットフォームの全体像と、SRE と開発チームの責任境界 SRE チーム 全チーム共通の基盤や OSS の運⽤に責務を持つ • EKS クラスタ本体の管理 • 各種 Operators の管理 • Transit Gateway 等のネットワーク周りの管理 開発チーム ⾃チームのサービス運⽤に責務を持つ • ⾃チームの namespace のリソース管理 • ⾃チームの AWS アカウントのリソース管理 開発チームは⾃チームの範囲を⾃由に変更でき、クラスタ本体や他チームのリソースには影響を及ぼさないようにしている © 2026 Loglass Inc. 13
14. ログラスのプラットフォームにおける責任境界と統制 なぜこの責任境界なのか ー 以前の開発体制とその限界 開発チームがプロダクト価値の創出に集中できるよう、運⽤周りの部分は SRE が対応していた 依頼‧相談 ⇄ 都度対応 開発チーム A 開発チーム B • • • • • • 機能開発 テスト 問い合わせ対応‧バグ修正 機能開発 テスト 問い合わせ対応‧バグ修正 SRE • ECS でのインフラの構築‧運⽤ • リリースパイプラインの構築‧運⽤ • 可観測性‧監視‧アラートの整備 • セキュリティ‧脆弱性対応 ‧‧‧ 開発チーム N • • • 機能開発 テスト 問い合わせ対応‧バグ修正 新サービス構築やトラブルが発⽣するたびに、コミュニケーションを取って対応する必要があった → プロダクトやチームの増加に対し、SRE が組織のボトルネックになりやすい体制だった © 2026 Loglass Inc. 14
15. ログラスのプラットフォームにおける責任境界と統制 なぜこの責任境界なのか ー 開発チームの責務の⾒直しとその理由 これまでの開発チームの責務 • プロダクト価値に直接関わる領域のみ ⽬指すべき開発チームの責務 • プロダクト価値に直接関わる領域 • 加えて、SREが担っていた ⾃チームのサービス運⽤に関わる領域 責務を広げた理由 • 運⽤を SRE に頼る形のままだと、チームが増えるほど SRE がボトルネックになりやすい • SRE への依頼や相談をせずに、⾃分たちで進められるので、コミュニケーションコストが発⽣しない • 仕様も変更の経緯も分かっている開発チームが運⽤を担うほうが、変更の影響を正しく判断できる ⾃チームのサービスは⾃⾝で運⽤した⽅が、中⻑期でスケールしやすく、開発効率と品質を両⽴しやすい © 2026 Loglass Inc. 15
16. ログラスのプラットフォームにおける責任境界と統制 開発チームに、責務をそのまま移譲するのは難しい ログラスは、運⽤周りのことは SRE に依頼する⽂化だったので、 ⾃チームのサービスの運⽤のために、いきなりリソース管理に責務を持ってもらうのは難しい そのまま渡すと、SRE が担っていた領域まで意識することになり、 プロダクト価値の創出に使っていた時間を、運⽤の整備に⼀定割くことになる 加えて、専⾨知識がないまま Coding Agent を使うと、とりあえず動くが、信頼性の低いものが出てきやすくなり、 運⽤に⽀障が出る設定や事故が起きやすくなる なので、開発者が意識することはなるべく⼩さくしつつ、責務を持ちやすくする必要がある © 2026 Loglass Inc. 16
17. ログラスのプラットフォームにおける責任境界と統制 責務を持ちやすくしつつ、Condig Agentをより安全に扱えるようにする 安全な標準構成を提供する SRE が整備した共通 Helm Charts • 開発者は共通 Helm Charts で公開された値のみを 設定できるようにして、SREにとって意図しない 必要最⼩限の権限で実⾏する 開発者の責務に合わせた権限設計 • ⾃チームの範囲かつ必要最低限の操作のみを 許可し、事故を起きにくくする 設定を防ぐ仕組み これらの統制を導⼊することで、 開発チームがCoding Agent を使って開発速度をあげつつ、品質‧信頼性を⼀定に保つことができている © 2026 Loglass Inc. 17
18. SRE が整備した共通 Helm Charts © 2026 Loglass Inc. 18
19. SRE が整備した共通 Helm Charts 共通 Helm Charts の仕組み SRE チーム • Helm Template Repo を管理 • Kubernetes を知らない開発者でも簡単 に構築できるように抽象化する 開発チーム • Services Repo の⾃チームのリソースを 管理 • Helm Template Repo で公開された values のみを編集できる Argo CD の Multi Source for an Application を利⽤し、 1つの Application に対して、複数のリポジトリの設定を掛け合わせ、クラスタに k8s リソースをデプロイしている © 2026 Loglass Inc. 19
20. SRE が整備した共通 Helm Charts 役割ごとに分けた 5 つの Helm Chart Helm Chart 役割 base 環境や Service などグローバルな設定を管理 stateless Deployment など、Stateless な Workload の設定 events SQS などのイベントを Argo Events に連携 workflow Argo Workflows の設定を管理。Argo Events との連携も可能 migration Argo CD の PreSync で Migration を実⾏できる Workflow を管理 Services Repo のディレクトリ構成 開発者が書くのは、サービスごとのディレクトリにある各 Chart の values.yaml だけ © 2026 Loglass Inc. 20
21. SRE が整備した共通 Helm Charts 開発チームが書く設定と、書かなくてよい設定 開発チームが書く設定 • ⾃分のサービスに必要な値だけ • イメージ、レプリカ数、環境変数、公開するポートなど Template 側にあるので、書かなくてよい設定 • Datadog 等の可観測性の設定 • PSA/PSS、SecurityContextなどのセキュリティ設定 書く設定と書かなくてもよい設定の粒度は、必要に応じて開発者と議論しながら落とし所を決めているが、 全 Charts でできるだけ開発者にとって意識することが少なくなるようにしている © 2026 Loglass Inc. 21
22. SRE が整備した共通 Helm Charts アーキテクチャパターンごとのサンプル定義 stateless単体の定義を書くのは簡単だが、それ以外のアーキテクチャはどの Charts を組み合わせればいいかがわかりにくい 開発チームが使いそうなアーキテクチャパターンごとに、values のサンプルと実現するためのドキュメントを揃えている パターン 利⽤する Chart どのような状況で利⽤するか Web App stateless 単純な Web アプリケーションを動かす 単発実⾏ Job workflow 初期データ投⼊や不整合の解消のような⼀回きりの実⾏ 定期実⾏ Job events + workflow 定期的に必要なジョブの実⾏ SQS + Worker base + stateless 短時間向けの⾮同期処理。KEDA で SQS のメッセージ数に応じてスケー ル SQS + Event + Workflow base + events + workflow ⻑時間向けの⾮同期処理。SQS → Argo Events → Argo Workflows © 2026 Loglass Inc. 22
23. SRE が整備した共通 Helm Charts サンプル定義と values.schema.json での values の検証 アーキテクチャパターンごとのサンプル定義に加え、 Helm 標準の values.schema.json を完備し、開発者が定義した values の型や取りうる値を厳密にチェックしている SRE が⽤意した Services RepoのSkills 通る そのままマージしてデプロイ アーキテクチャパターンごとの サンプル定義とドキュメント 読ませる values.schema.json で 型と取りうる値を定義 Coding Agent が values を記載する PR を出す Services Repo の CI helm lint で schemaと照合 CIが落ちる 定義にないキー‧必須パラメータの不⾜等 が原因なので再修正 この 2 つを Coding Agent に読ませれば、組織固有の正しい形を知らなくても、正しい values が最初から出てくるため、 開発者が何度もデバッグを繰り返さずに済むようになっている © 2026 Loglass Inc. 23
24. SRE が整備した共通 Helm Charts Admission Controller での値の検証 共通 Helm Charts では防げない設定は、Admission Controller で防ぐようにする 共通 Helm Charts の schema で防ぐ Admission Controller で防ぐ ‧意図しないリソースの作成 ‧数値データの妥当性 ‧型違い、enumで定義していないパラメータ ‧例: 以下の設定に極端に⼤きい値を⼊れる ‧resources の requests / limits ‧terminationGracePeriodSeconds CI や Admission Webhook に組み込み、運⽤時の負担になるような設定は事前に検知できるようにする これを防ぐためにはどうすればいいかを開発者と会話できるようにする © 2026 Loglass Inc. 24
25. 開発者の責務に合わせた権限設計 © 2026 Loglass Inc. 25
26. 開発者の責務に合わせた権限設計 開発者が利⽤するリソース全てが権限設計の対象 基盤 Kubernetes / AWS Operators Argo CD / Argo Workflows / Vault リポジトリ GitHub Kubernetes（EKS） AWS Argo CD Argo Workflows HashiCorp Vault Services Repo コンテナ基盤。 DB や SQS などの Git のマニフェストを ジョブやバッチを secret を保管し、 values を管理する 各サービスの リソースを扱う クラスタに反映 クラスタ上で実⾏ k8s Secret に同期 GitHub リポジトリ namespace が並ぶ Coding Agent はローカルにて⼈間と同じ権限で動作する。 ⼈間にできないことは Coding Agent にもできない。 Coding Agent に統制をかけつつ開発効率を上げられるかは、これらの権限の設計で決まる © 2026 Loglass Inc. 26
27. 開発者の責務に合わせた権限設計 基盤である Kubernetes と AWS の権限制御 Kubernetes と AWS のリソースは、ローカルの CLI から確認することはできても、直接変更することはできない。 閲覧 ローカル CLI kubectl / aws 開発者 直接変更 kubectl apply コンソールでの変更 Coding Agent どちらも同じ資格情報 閲覧だけ（get / logs / describe）。 apply や delete はできない ✕ Kubernetes 経路そのものが無い 変更 PR Helm values / Terraform AWS CI が検証 Argo CD / Terraform が反映 開発者が SRE に頼らず⾃分でトラブルシューティングできるようにするために、閲覧は許可している © 2026 Loglass Inc. 27
28. 開発者の責務に合わせた権限設計 GitHub Team を起点にした、Operators とリポジトリの権限制御 各 Operators の権限も、Services Repo の CODEOWNERS も、GitHub Team を基準に設定しており、 ⾃チームが管理するリソースに対して必要最低限の操作/変更のみを許可している。 Operators とリポジトリ Argo CD GitHub Team チーム A チーム B Argo Workflows Team 名で 権限を紐づけ HashiCorp Vault チーム C … Services Repo（CODEOWNERS） Team への⼊退場や移動のみで、プラットフォームで利⽤する全てのツールの権限制御が可能 © 2026 Loglass Inc. 28
29. 開発者の責務に合わせた権限設計 各 Operator がどのように GitHub Team の情報をもとに権限制御しているか 3 つの Operator はいずれも OIDC でログインする機構を持っているが、GitHub ⾃体は OIDC の IdP ではない。 そこで間に Dex を挟み、GitHub の OAuth 2.0 ログインを OIDC に変換している。 Argo CD ① ログインを押す 開発者 ⑥ Team ごとの 権限で操作が可能 ③ GitHub にリダイレクト ログインと同意 ② Dex に⾶ぶ Argo Workflows ⑤ 所属 Team の ⼀覧を返す Dex （GitHub connector） ④ 所属 Team の⼀覧を取得 （API） GitHub HashiCorp Vault 各 Operator はユーザーもパスワードも持たず、GitHub アカウントでのみログインが可能 どの GitHub Team に所属しているかで権限が決まるようにしている © 2026 Loglass Inc. 29
30. 開発者の責務に合わせた権限設計 ⾃チームの管理リソースにだけ与える権限設計の詳細 ツール 権限制御の実装 (SREが管理) 開発者ができること Argo CD AppProject 操作する Application と GitHub Team を紐付ける ⾃チームのApplicationの sync や restart などの action Argo Workflows namespace ごとに ServiceAccount ServiceAccount に GitHub Teamを定義し、 同じ Namespace 内の Workflowに対し、操作権限を付与 登録済みの WorkflowTemplate から Workflow を起動 アドホックに Workflow を作って実⾏することはできない HashiCorp Vault kv（secret の置き場）の policy サービスごとにパスを分け、パス単位で権限を付与 ⾃チームのサービスの kv を UI で閲覧、編集 Services Repo CODEOWNERS CODEOWNERSにて、サービスのディレクトリごとに GitHub Teamを指定 ⾃チームのサービスの values をレビューしてマージ © 2026 Loglass Inc. 30
31. 開発者の責務に合わせた権限設計 Vault は Secret を扱うので、さらに厳しい統制をかけている ⼊⼝ 経路 配布 正社員のみログイン可能 UI からのみ操作可能 同期された Secret を kubectl で⾒ に⾏くこともできない GitHub Team の正社員専⽤のチームに所属 Vault CLI からの操作を禁⽌し、Coding UI で登録した値は Vault Secrets Operator していないとログインできない Agent 経由で Secret 値を読めないようにし が Kubernetes Secret に同期する。 ている 開発者と Coding Agent の kubectl では、そ の中⾝を読めない Coding Agent 等から Secret が漏れる可能性を、可能な限り排除していく⽅針にしている © 2026 Loglass Inc. 31
32. まとめ © 2026 Loglass Inc. 32
33. まとめ 今⽇話した 2 つの統制の振り返り プラットフォームが⽤意すべき 5 つ 1 2 3 今⽇話した 2 つで、ログラスが実施したこと 安全な標準構成を提供する 必要最⼩限の権限で実⾏する 1．安全な標準構成 ＝ SRE が整備した共通 Helm Charts • 開発者と Coding Agent が書けるのは、公開された values だけ • 可観測性やセキュリティの設定は Charts 側にあり、開発者は書かなくてよい • アーキテクチャパターンを完備しており、開発者が即座に⾃⾝で構築‧変更できる 外部からの侵⼊を防ぐ 4 信頼できない外部への経路を防ぐ 5 誰が何をしたかを監査する 2．必要最⼩限の権限 ＝ 開発者の責務に合わせた権限設計 • 基盤の Kubernetes と AWS は閲覧のみ。リソースの変更は PR を通ったものだけ • Operators とリポジトリは GitHub Team を起点に、⾃チームの管理リソースに対して、 必要最⼩権限での操作を可能にしている 開発チームが⾃チームのサービスにオーナーシップを持つことができ、SRE の想定外の設定や操作はほとんど起きていない © 2026 Loglass Inc. 33
34. まとめ やること⾃体は変わらないが、やらなかったときの代償が⼤きくなった 今⽇話したことは、AI 時代でなくても⼤切だったことである ただ、Coding Agent の圧倒的な速さで、品質と信頼性は以前より揺らぎやすくなった だからこそ、統制にこれまで以上に時間をかけて、 Coding Agent の価値を最⼤限に引き出せる状態を作ることが重要になっている そして、その統制を作るには、開発者との責任境界を適切に決めて、 組織に合った形を地道に積み上げていくしかない そうして積み上げた先で、開発者は Coding Agent の⼒を最⼤限に活かし、プロダクト価値の創出に集中できる © 2026 Loglass Inc. 34
35. © 2026 Loglass Inc. 35