はじめに
AWS re:Invent 2025 に現地参加させていただきました。
re:InventはAWSが年に一度開催する大規模な学習型カンファレンスで、新サービスの発表に加え、様々な形式のセッションやワークショップが展開され、AWSや関連企業が今どのような考え方をしているのかをまとめて感じ取れるイベントとなっています。
re:Invent全体の話や昨年度のレポートについては以下記事も併せてご覧ください。
著者は変わりますが、2025年分についても随時記事がアップされる予定です！
本記事では、私自身が参加した1つのChalk Talkセッションにフォーカスし、議論の内容や特に印象に残った考え方についてご紹介します。
Chalk Talk形式のセッション
Chalk Talkは、登壇者が一方的に話す講演形式ではなく、説明のためのスライドや議論のためのホワイトボードを使い、複数の話題について聴衆との対話や質疑、議論を重ねながらテーマについて深堀していくスタイルです。
そのため本記事では、発言の主体を厳密には明記せず、セッション全体で共有されていた考え方やメッセージにフォーカスして内容をまとめていきます。
TL;DR
- DevSecOpsやPlatform Engineeringのあり方について議論するChalk Talkに参加した
- 価値を実装するのは開発者(Dev)なので、共通の複雑性はPlatformに沈める(Shift Down)
- 楽をした結果、速くなるという手段を提供(Golden Path)し、その価値を証明する
紹介するセッション
今回ご紹介するのは
SEC204-R1 - Rethinking DevSecOps with Platform Engineering That Actually Works
というセッションです。
Catalog概要：
Many DevSecOps initiatives create bottlenecks despite promising faster, more secure delivery. In this interactive chalk talk, we'll collaboratively design a scalable DevSecOps blueprint that moves beyond checkbox compliance to enhance both security and velocity. Using real-world examples, we'll explore the DevOps-to-DevSecOps evolution, examine AWS's internal approach to security requirements, and uncover effective platform engineering patterns. You'll leave with a practical roadmap for making security a "paved road" and clear steps to launch your security platform initiatives—without getting bogged down in unnecessary complexity.
多くのDevSecOpsイニシアチブは、より迅速で安全なデリバリーを約束しながらもボトルネックを生み出しています。このChalk Talkでは、チェックリスト的なコンプライアンスを超え、セキュリティと速度の両方を高めるスケーラブルなDevSecOps設計図を共同で構築します。実例を用いてDevOpsからDevSecOpsへの進化を探り、AWSの内部セキュリティ要件へのアプローチを検証し、効果的なプラットフォームエンジニアリングパターンを明らかにします。参加後は、セキュリティを「舗装された道」とする実践的なロードマップと、不要な複雑さに足を取られることなくセキュリティプラットフォーム構想を立ち上げる明確な手順を持ち帰れます。
登壇者はAWSでヘルスケア、自動車、金融など規制の厳しい業界で大企業のセキュリティ支援をしているセキュリティソリューションアーキテクトのCameron Smith氏です。
DevSecOpsや自身の役割(Sec)を皮肉するところから入り、プラットフォームエンジニアリングのあるべき姿やセキュリティと開発者(Dev)とのかかわり方、またプラットフォームを構築することでどのようにDevの負荷を下げられるか、といった内容についてマインドセットだけでなく具体的なステップまで説明するセッションでした。
なぜこのセッションを選んだのか
セッションカタログを "Platform Engineering" で検索していた際に目に留まりました。
普段から、Dev <何とか> Opsや、Platform Engineeringについて、
「本当にこの形で機能しているのか？」
「あるべき姿は何か？」
と考えることが多く、タイトルに含まれる "Rethinking" にも強く惹かれました。
またせっかく現地で参加するので、あとから動画で視聴できるタイプのセッションよりも、その場でしか体験できないセッションを優先したいという想いもありました。
DevSecOpsとは何だったのか？
ここからセッションの内容に入っていきます。
まずはアイスブレイクとして、
- Dev(開発者)の人？
- Sec(セキュリティ)の人？
- Ops(運用)の人？
- それ以外の人？
と、問いかけて人数分布を取ります。記憶ベースですが、おおよそDevが半分弱、Secがそれより少し少ないくらい、Opsは数人くらいでした(あとは手を挙げていない人)。また「それ以外の人」の質問に対して、Biz系やMarketingの方もいて、多様なバックグラウンドの参加者が集まっているようでした。
次に登壇者から、「DevSecOpsとは何だと思いますか？親戚に説明するつもりで」と投げかけられ会場からは、
- つくるまえからセキュリティを考慮すること！
- DevとSecとOpsを一人で全部やるエンジニアのこと！
といった回答が挙がりました。手を挙げて当てられる人もいれば手を挙げながら勝手に発言するような方もおり、かなり活発だった印象です。
2つ目について登壇者は、「Dev・Sec・Opsエンジニアを一人分の給料で雇えるってことだね！お得だ！」などと反応して、もっと発言しやすい空気になっていたようにも感じます。
なお会場ではこちらのスライドが掲示されていました(が、特に触れられていませんでした)。
(ざっくり要約) DevSecOpsとは、文化的哲学、プラクティス、及びツールの組み合わせであり、予防的・検知的・対応的なセキュリティ制御の自動化された適用により達成される。
上記のやり取りを起点に「DevSecOpsが現場でどのように受け止められてきたのか」というテーマへと話を進めていきます。
DevSecOpsの誤解と現実
登壇者は、「DevSecOps神話」と題して現実で起こりがちな誤解を指摘しました。
- Cultureを変えるのはコストがかからないし、簡単である
- 「鍵を失くすな」と言われて、本当に失くさなくなる人はいない
- 現実世界における摩擦はもっと難しい
- 何かしらツールを導入すれば解決する
- 「If you build it, they will come」(作れば使われる) なんてことはない
- ツールの導入が目的になっていないか？逆に摩擦を生んでいないだろうか？
- SecやOpsに関する厄介ごとをLeft(前工程の担当者や大抵の場合Dev)にぶん投げればOK
- 要件やチェック項目を増やすだけ増やして「NO」というだけになっていないか？
- 宿題を増やして答えのありかを教えないようなもの
- 開発者はセキュリティの専門家であるべきだ
- Devはただでさえ新言語、AI、クラウド...と常に新しいことを学ぶ必要がある
- インシデントレスポンス、脆弱性管理、ガバナンスなど含めると認知負荷が高すぎる
DevSecOps自体はいい考え方だが、「人(特にDev)」に頑張らせすぎる受け止められ方があったのではないか、としました。
人ではなく仕組みに責任を持たせるべきであるという流れで、自然とPlatform Engineeringの話に入っていきました。
Platform Engineeringを考える ― Shift DownとGolden Path
登壇者は、ここで議論されるPlatform Engineeringは、「銀の弾丸」やバズワードとしてではなく、DevSecOpsがDevに多くの責務や判断を委ねていたのに対し、その前提自体を作り直すための設計思想であると前置きしました。
そしてその中核(Core Principles)とされていたのが、Shift DownとGolden Pathでした。
Shift Down
DevSecOpsに限らず「Shift Left」がよく語られますが、そこでは前述のぶん投げ(Devにとりあえず任せる)が起こっているという問題意識が改めて共有されました。
Shift Downとは、セキュリティや運用の複雑さをDevに理解・判断させるのではなく、プラットフォーム側に沈めてしまうという発想です。
人の注意力や善意に依存せず、自然と事故率が下がる方向に設計する、という考え方です。
"Shift Down"という表現は初めて聞きましたが、とても腑に落ちました。
軽くGoogleトレンドやWebでShift Downを調べてみたところ、"Shifting Down"というキーワードでいくらかの技術ブログが見つかりましたが、案外少なめでした。
シフトダウンでトルクを上げる(=加速するためのパワーを稼ぐ)みたいな捉え方もできそう...
Golden Path
もう一つの重要な概念がGolden Pathです。
Golden Pathとは、「正しくて安全な方法が、最速で簡単な方法である状態」を指します。
登壇者の以下の説明が印象的でした。
The right thing becomes the easy thing, stops being a thing. Starts being the standard.
正しいことが簡単なことになったら、それが標準になる
また、Golden Pathは強制されてはいけない、ということも強調されていました。
- Golden Pathを使うかどうかはあくまでチームの選択
- 使う場合は設計の理由などの説明責任がいくらか免除される
- 使わない場合は、その分の説明責任及び追加で必要となるコストをチームが引き受ける
楽な方に流れたほうが結果としてセキュアな状態になるという設計です。
「良いものを作れば勝手に使われる」という考え方は成立しない、という点もセッションでは繰り返し触れられており、「"良い設計"であるだけでなく、"選ばれ続ける設計"である必要がある」という現実的な視点も語られていました。
Platform Engineeringの実践と考え方
さて、これらをどのように適用するとよいでしょうか？
セッション後半では実践編としてシンプルなプラクティスが紹介されました。
前提として、Platform Engineeringは完成させるものではなく、継続的なプロセスであるとされました。
ここでも、印象的でとても共感したフレーズがあります。
Getting started is the hardest part.
始めるのが一番難しい
Platform Engineeringではセキュリティ、運用、コスト、可観測性、AIなど...やりたいことが非常にたくさんありますが、すべてやろうとすると何も始まらないので、登壇者はまずは一つ、実際に価値を出す事例を作ることを強く勧めていました。
実際に「速く」なったり「楽に」なったチームを一つでも生み出せるかどうかが、その後の広がりに大きく影響するということです。納得です。
セッションでは以下の4ステップが説明されました。
-
Pick something (対象を1つに絞る)
まずはシンプルでインパクトのある対象を1つ決めよう -
Create a template (再現可能な形にする)
どこで、どう、なにができるのか を明らかにして、他のチームが真似できる形にしよう -
Get in their hands (実際に使ってもらう)
CI/CDへの組み込み、配布するなどして、実際に触れる状態にしておこう -
Metrify & Iterate (計測し、改善する)
使われているか、どこで詰まったか、なぜ使われないか を観測して学び、改善し続けよう
列挙してみると様々な文脈でよく語られているような、MVPであったりQuick Winであったりの考え方ではありますが、改めて意識して実践していきたいと思いました。
事例紹介
"Cool"なPlatform Engineeringの事例としてAWS含む3社が紹介されました。技術的な事例というよりも、設計思想の例という感じでした。
それぞれの事例についてはぜひ個別に調査したいところですが、本記事ではあくまでもセッションで触れられていた概要だけ記載します。
Netflix: Paved Road
登壇者は、これこそがPlatform Engineeringの実践そのものであると紹介していました。
プロダクトをセキュアにするための仕組みとして、専門家の知識をプラットフォームに埋め込み、開発者が簡単に使えるようになっているイメージとのことです。
例えば、レジリエンス(耐障害性)テストを行いたいとします。これはSREの専門領域であり、Opsが知っていてもDevは知らないことが多いです。そこで、SREがプラットフォームチームに対してレジリエンステストの自動化ツールを提供し、Devはそれを簡単に利用できる、というようなかたちのようです。
また、レジリエンステストの難しさを本当にわかっているのは専門家でもあるという説明も印象的でした。(正しく実装できるという意味だと解釈しています)
Spotify: Backstage
200以上の乱立したCIをプラットフォームに統合した例として紹介されました。
モノレポ化や単一パイプライン化ではなく、各チームが自由にCI実行できる環境は維持しつつ、統一された"やり方"を提供するプラットフォームを作ったのがBackstageとのことです。
BackstageにはまさにGolden Pathを体現するようなSoftware Templateという機能があり、過去に利用する機会があったので、やはり来たか！という感じでした。
(たまたま前列の方が映ってしまい、他に画像がありませんでした...)
AWS内部: AI Security Testing with FAST
最後に紹介されていたのが、AWS内部で使われている FAST というツールです。
AIセキュリティは専門性が高く、Devに追加で学習を求めるのは非現実的です。
そこでFASTでは、AIアプリケーションに対するセキュリティテストをワンコマンドで実行可能な形として提供しています。
$ fast ./ # こんな感じらしいです
セキュリティチェック能力をプラットフォームに託すという、Shift Downの例です。
FASTフレームワークについては、re:Inforce 2025で紹介されているようです。
まとめ
本セッションでは、DevSecOpsの文脈においてDevに過剰な負荷がかかっている風潮や、セキュリティ担当が「NO」を突きつけるだけになってしまう捉え方や文化に対する警鐘が鳴らされていました。
そこで提示されたのが、「Shift Left」だけに頼るのではなく、Shift Down によって複雑さをプラットフォーム側に沈めていく、という考え方です。
実際に価値を創出するのはDevであり、その認知負荷を下げることが、結果としてスピードや品質、セキュリティの向上につながる。
そのために、プラットフォーム側が"楽な道"を整備し、セキュリティや信頼性といった守りたいものを持つ専門家は、Devを直接コントロールするのではなく、プラットフォームと協力して道を整える側に回ることが重要だ、というメッセージでまとめられました。
Q&Aピックアップ
セッションの本筋で含めきれなかったQ&Aを掲載しておきます。
- Q：プラットフォームの構築は時間がかかるが、どう経営層を説得するか？
A：最初時間がかかるのは当然なので、短期の痛みを長期の利益と交換していると理解 - Q：とても優秀なチームが独自に開発を進め、プラットフォームを使わない場合は？
A：彼らはプラットフォームの主対象ではない。強制はせず、Golden Pathを選ばない理由を聞き出す。一方で、組織の大多数を支えるのがプラットフォームの役割である - Q：プラットフォームの境界線はどこか？どこまでサポートすべきか？
A：チーム数、影響範囲、ビジネス価値から判断する。あるチームがKotlinを使いたいと言ってきたら、これらの指標をヒアリングして決めればよい。1%未満のケースのためにプラットフォーム全体は変えない
おわりに
全体を通して登壇者の方のジョークや言い回しが面白く、皮肉交じりでDev/Sec/Ops/その他の認識のギャップや開発における「あるある」のようなものが散りばめられており、1時間があっという間に感じるセッションでした。
セッションのテーマとしてもDevSecOpsからPlatform Engineeringのあるべき姿への変遷、「Shift Down」や「Easy thing」といった言い回しが印象的で、これまで何となくこうした方が良いと感じていた考え方が綺麗に言語化されたようでした。
Golden PathやShift Downの考え方は、「ルールで縛る」のでも「善意に頼る」のでもなく、楽な方に流れた結果、あるべき姿になる、という点がとても合理的だと感じました。個人的に自然淘汰的な設計思想が好きで、この考え方には強く共感しました。
一方で、「良いものを作れば勝手に使われる」わけではない、という指摘は耳が痛い部分でもありました。道を用意するだけでなく、その道を選ぶと楽になるところまで設計し、実際に価値を出すところまで持っていく必要があるということを肝に銘じたいと思います。
また、ジョークについていけないところがあっただけでなく、せっかくChalk Talkに参加したのに発言せずに終わってしまいました。自身の英語力と言語化能力の課題も見えた非常に学びの多いセッションでした！
余談
現在、社内でInnerSource の取り組みが進んでおり、自分自身も携わっています。
Developer Experienceを高めること、セキュアで再利用しやすい基盤を整えること、そしてコードや知見が自然と共有されていく環境を作るためにはどうすればよいか、ということを最近よく考えていたということも、このセッションに惹かれた理由の一つだったりします。