書き手が人でもAIでも正しくなる道、 SREを埋め込んだDeveloper Platform / tech drivers day8

Transcript

1. 書き⼿が⼈でもAIでも正しくなる道、 SREを埋め込んだDeveloper Platform 2026年10⽉26⽇ 株式会社ログラス TECH DRIVERS Day8 AI時代のPlatform Engineering
2. ⾃⼰紹介 ⾒形 親久（みかた ちかひさ） 株式会社ログラス 技術基盤部 クラウド基盤チーム リードエンジニア • SIer 3 社でアプリケーションエンジニアを経験 • BtoB SaaS ⼤⼿で約 10 年、プロダクト開発‧運⽤を経て SRE チームの⽴ち上げ‧推進‧マネジメント • 2024 年 10 ⽉ログラスへ。SRE の推進と Kubernetes を中⼼としたプラットフォームの構築を担当 • テーマは「SRE の⺠主化」。皆が SRE をするために、“努⼒”から“仕組み”へ © 2026 Loglass Inc. 2
5. 目次 01 なぜプラットフォームなのか 02 プラットフォームが提供するもの 03 ⼈向けの⾃由と、AI 向けの⾃由 04 ⾃由と統制のバランスの取り⽅ 05 現在地とこれから © 2026 Loglass Inc. 5
6. 01．なぜプラットフォームなのか © 2026 Loglass Inc. 6
7. 01．なぜプラットフォームなのか 運⽤の仕事はプロダクトの数だけ必要になる。だから共通化し、プラットフォームとして提供する 1 信頼性 2 セキュリティ 3 統制 • 監視 • 脆弱性対応 • 権限管理 • 可⽤性 • イメージの改ざん防⽌ • 変更管理 • インシデント対応 • 依存の更新 • シークレット管理 © 2026 Loglass Inc. 7
8. 01．なぜプラットフォームなのか ただし、誰が何に責任を持つかを決めないと、プラットフォームはうまくいかない SRE が全部抱えると 開発チームに任せると • プロダクトが増えるたびに依頼が積まれる • 専⾨知識がないと判断できない • 依頼待ちが常態化する • チームごとに⽔準がばらつく • 「インフラは SRE の仕事」という認識が固まる • AI で速くなるほど、ばらつきも速く広がる © 2026 Loglass Inc. 8
9. 02．プラットフォームが提供するもの © 2026 Loglass Inc. 9
10. 02．プラットフォームが提供するもの 開発から監視まで、各⼯程の型をプラットフォームが提供する © 2026 Loglass Inc. 10
11. 02．プラットフォームが提供するもの イメージは共通のワークフローでしかビルドできず、来歴を検証してから各環境へ昇格する © 2026 Loglass Inc. 11
12. 02．プラットフォームが提供するもの 共通 chart と各サービスの設定を GitOps で反映し、起動する前に署名と来歴を確かめる © 2026 Loglass Inc. 12
13. 03．⼈向けの⾃由と、AI 向けの⾃由 © 2026 Loglass Inc. 13
14. 03．⼈向けの⾃由と、AI 向けの⾃由 書き⼿に AI が加わり、プラットフォームに求められるものが変わった ⼈が書き⼿だったとき AI が書き⼿に加わってから • 設定の幅を広く持たせた • 設定変更の⼤半が AI 共著に（15% → 92% ※） • ⼈の意志で判断できるようにした • なんとしてでも成⽴させる。⽳を突くことも厭わない • 説明ドキュメントやサンプルを⽤意した • 例があれば、それを繰り返す • 推論なので、同じ依頼でも判断が揺れる ⼈の意志と⾃由度を尊重した AI の判断に任せない仕組みが要る ※ 2026-03 → 2026-09。サービス設定リポジトリの main に⼊った設定変更の commit のうち、AI が共著者として記録されているものの割合（⽉別。マージと bot は除く） © 2026 Loglass Inc. 14
15. 03．⼈向けの⾃由と、AI 向けの⾃由 AI の判断に任せない。書ける選択肢そのものを減らした SRE が持つ設定 開発者が書く設定 機能と権限 以前は 開発者が上書きできた 以前は 細かく全部書かせていた 以前は 「使うかも」で許可していた 開発者は変更できない 書くのは最低限だけ 使うかも、では作らない 監視‧セキュリティの既定値をロック 推測できるものはプラットフォームが 今使うものだけ許可し、 ⾃動で⽣成する 必要になった時点で⾜す © 2026 Loglass Inc. 15
16. 04．⾃由と統制のバランスの取り⽅ © 2026 Loglass Inc. 16
17. 04．⾃由と統制のバランスの取り⽅ ⾃由と統制は、4 つの仕組みで両⽴させる 仕組み 責務の分離 責務範囲の明確化 権限の移譲 仕組みでのガード 具体的にやっていること 共通の Helm chart は基盤チーム、各サービスの設定値は開発チーム と、リポジトリごと分ける どのサービスを誰が⾒るかを CODEOWNERS で宣⾔する。それ以外は基 盤チーム。登録漏れは CI で落ちる ⾃分たちのサービスの範囲に限った権限を、チームの定義から⽣成して 渡す。環境ごとに広さを変える スキーマ検証‧ポリシー検査‧署名の確認など、決定論的なチェックで ⽌める AI が書いても効く理由 触れる場所が最初から限られる ⾒る⼈が決まっている 任された範囲の外に出られない ⼈や AI の判断に頼らない © 2026 Loglass Inc. 17
18. 04．⾃由と統制のバランスの取り⽅｜責務の分離‧範囲の明確化 基盤チームと開発チームで、持つ設定をリポジトリと項⽬の単位で分けた 基盤チームが持つ（テンプレート⽤リポジトリ） 開発チームが持つ（サービス⽤リポジトリ） • 共通の Helm chart • 使うイメージとリソース量 • セキュリティ設定の既定値 • アプリの環境変数‧設定ファイル • 監視‧ログ収集の設定（ロック） • 「OpenTelemetry を使う」などの 1 ⾏の宣⾔ • シークレットの配布 • 実⾏中のセキュリティ検知 • Kubernetes リソースの細かな設定 © 2026 Loglass Inc. 18
19. 04．⾃由と統制のバランスの取り⽅｜権限の移譲 任せる範囲を⾃分たちのサービスに限り、その内側は任せきる © 2026 Loglass Inc. 19
20. 04．⾃由と統制のバランスの取り⽅｜仕組みでのガード 線の外に出る変更は、⼈のレビューではなく道の上の関⾨が⽌める © 2026 Loglass Inc. 20
21. 05．現在地とこれから 狭めた道で⽔準は揃った。次は関⾨を増やし、道そのものの信頼性を上げる 揃ったもの これから • 監視の標準設定 • ポリシーチェックの整備 • 可⽤性の既定値 • 署名‧アテステーションの確認を全アプリ‧全環境へ • ビルドと反映の統制 • 共通のビルド経路を全アプリへ • チーム単位の権限 • プラットフォーム⾃体の信頼性 道を狭めるほど、道を敷く側の責任は重くなる © 2026 Loglass Inc. 21
22. まとめ 書き⼿が⼈でも AI でも、任された範囲の内側では迷わず進める 責任の線を引く AI の判断に任せない 道に埋め込む 責務を分け、範囲を⽰し、 選択肢を減らし、 ビルドから監視まで、 権限を渡す チェックとルートを絞る 型と関⾨を⽤意する SRE が抱えず、丸投げもしない 読まれなくても外れない 使えば⾃然に守られる © 2026 Loglass Inc. 22
23. 最後に 新しい技術を⾜すのではなく、 当たり前のことを、書き⼿を問わず守れる形にする © 2026 Loglass Inc. 23