- はじめに
- 個別最適の限界と、AIによる強制的な標準化
- re:Invent キーノートで示された Frontier Agent という未来
- re:Invent で感じた「コモディティ化」
- SRE はこれから何を担うのか
- おわりに
はじめに
こんにちは、SRE部の小野です。私は、DMM グループで SRE として複数のサービスや基盤に関わっています。日々の業務では、個別サービスの信頼性向上だけでなく、組織横断での可観測性やインシデントの運用プロセスといったテーマに取り組んでいます。
AWS re:Invent 2025（以下、re:Invent）への参加を通じて、AI がもたらす変化は単なる技術トレンドではなく、技術組織の前提そのものを書き換えつつあると強く感じました。このブログでは、そこで見聞きし、実際に試した内容を起点に、AI 時代における開発ロールと SRE のあり方について整理します。
AI を前提としたとき、技術組織はどのように変わっていくのか、その中で SRE はどんな役割を担っていくのか。re:Invent での体験をもとに、考えを整理した私の個人的な整理として読んでいただければと思います。
個別最適の限界と、AIによる強制的な標準化
結論から言えば、これまで正義とされてきた「個別最適」が限界を迎えた最大の理由は、AIによって「人やチームごとのスキル差分」が急速に無効化（コモディティ化）されているからです。
これまで、多くの技術組織では「事業やサービスごとに最適化する」ことで成果を上げてきました。特に弊社のようなコングロマリット型の企業では、各事業のドメイン特性に合わせた独自の技術選定や運用プロセスこそが、スピードと競争力の源泉でした。しかし、re:Invent を通じて明確になったのは、その「独自性」という前提自体がAIによって揺らいでいるという事実です。
かつては「うちのチームは開発力が極めて高い」「このサービスは独自のアーキテクチャで作り込んでいる」といった人間側の習熟度が明確な優位性となっていました。しかし、AIの進化速度は、そうした“人間が積み上げた差分”を容易に追い越していきます。開発スピード、コードの品質、問題の調査能力——これらにおいて、特定個人の「職人芸」に頼るメリットは急速に薄れつつあります。
さらに、社会全体を見渡すと、多くのITサービスはすでに成熟期にあり、直面する課題も共通化しています。DMMにおいても、新しいサービスが次々と生まれる一方で、多くの既存サービスが共通の運用課題に直面するフェーズにあります。その中で浮き彫りになってきたのは、以下のような構造的な課題です。
- 形骸化した情報連携
- 形式的なレポートが飛び交うだけで、実態としての知見が組織に還元されない“ごまかし”の仕組み。
- 無責任な横展開
- 特定チームが局所的に最適化した仕組みを、背景を考慮せず「よかったら使ってね」と放流する、戦略なき横展開。
- 「活動」と「成果」の乖離
- 何か新しいことに取り組んでいる雰囲気はあるものの、組織全体の信頼性や生産性には寄与していない構造。
AIのメリットを最大限に享受するためには、組織全体がAIにとって理解しやすく、介入しやすい「標準化された構造」を持っているかどうかが決定的な差となります。これからの時代、独自性を追求するべきは「課題の解き方（技術構造）」ではなく、その先にある「ビジネス価値の創出」そのものであるべきです。
re:Invent キーノートで示された Frontier Agent という未来
re:Invent のキーノートの中で特に印象に残ったのが、「Frontier Agent（フロンティアエージェント）」という概念でした。
Frontier Agent は、AWS が定義する新しいエージェントの位置づけ（あるいは到達段階）で、単にコード補完や単発のタスクをこなす存在ではありません。数日単位で自律的に稼働し、以下を行います。
- 計画を立て
- 実行し
- 結果を検証し
これらのループを回しながら、最終的なゴールに到達することを前提とした AI です。
この考え方を具体化した例として紹介されていたのが Kiro Autonomous Agent でした。Kiro の中核にあるのは Spec-driven Development（仕様駆動開発） という思想です。人間はコードを書くのではなく、自然言語で「何を作るか（Spec）」を定義し、AI がその仕様を満たす実装を進めていきます。
また、キーノートでは Kiro が社内システムや独自ツールと接続できることにも触れられていました。プロトコルそのものの新しさというよりも、AI エージェントに組織固有の文脈や判断材料を与えられる前提が、すでに当然のものとして語られていた点が印象的でした。これは、AI エージェントを汎用ツールとしてではなく、各社・各組織の中で実際に使われる存在として捉えていることの表れだと感じました。
このキーノートを通じて、AI は「人の作業を早くする道具」から、「長い時間軸で仕事を任せられる存在」へと進化しつつある、という強いメッセージを受け取りました。
re:Invent で実際に試した AI エージェント
今回の re:Invent では、AWS が提供する 2 つの AI エージェントを実際に触って試してみました。その中でも印象に残ったのが AWS DevOps Agent と AWS Security Agent です。
AWS DevOps Agent
AWS DevOps Agent は、AWS 環境上で発生している障害や異常に対して、関連するメトリクスやイベント、ログなどを横断的に参照しながら原因候補を提示してくれるエージェントです。
実際に試してみて感じたのは、AWS 側の障害やインフラ起因のトラブルに対しては非常に有効 だという点です。人がコンソールやメトリクスを行き来しながら調査していた作業を、大幅に短縮してくれます。
一方で、これは重要なポイントですが、DevOps Agent は システム全体を理解してくれる存在ではありません。 アプリケーションのドメイン知識や、サービス間の依存関係、ビジネス上の重要度まで含めて総合的に判断してくれるわけではありません。
そのため現時点では、「これがあればインシデント対応が完結する」というものではなく、強力ではあるが、あくまで部分的なパーツ という印象でした。
だからこそ、我々自身が使っているオブザーバビリティツールと組み合わせ、どの情報を集めるのか、どの文脈で判断させるのかを自分たちで設計する必要があります。
もう一歩踏み込むと、重要なのは オブザーバビリティ単体ではなく、ソフトウェア開発ライフサイクル（SDLC）全体の情報を一元的に集め、分析できる状態を作ること だと考えています。加えて、実際に試した範囲では、入力は英語のみで、かつ一度に渡せる情報量にも制限があり、サービス固有の文脈や判断材料を十分に与えるにはまだ限界があると感じました。
メトリクスやログ、トレースといった運用データだけでなく、ソースコード、デプロイ履歴、変更差分、インシデントの履歴といった情報が分断されたままでは、AI も人も「点」でしか判断できません。
AWS Security Agent
AWS Security Agent は、開発ライフサイクル全体にわたって AI を活用し、プロアクティブにセキュリティを担保することを目的としたエージェント です。DevOps Agent が主に運用フェーズを支援するのに対し、Security Agent は設計・実装・テストといったより上流から関与してくる点が特徴だと感じました。
具体的には、以下のような使われ方が想定されています。
- 実装前の設計レビュー
- コンソール上で一度セキュリティ要件を定義しておくと、設計ドキュメントをその要件に照らして自動的に評価します。アーキテクチャドキュメントをアップロードするだけで、変更コストがもっとも低い段階でセキュリティ上の問題を検出できるため、後工程での大きな手戻りを減らすことができます。
- プルリクエスト単位でのコードレビュー
- 定義したセキュリティ要件や一般的な脆弱性パターンに基づき、プルリクエストの内容を自動的に分析します。開発者は GitHub 上で直接、是正のための具体的なガイダンスを受け取ることができ、AppSec チームはリポジトリ横断で一貫したセキュリティ基準を保ちやすくなります。
- オンデマンドのペネトレーションテスト
- 必要なタイミングでペネトレーションテストをリクエストでき、カスタマイズされた攻撃シナリオを通じて脆弱性を検出・検証します。再現可能なエクスプロイトの情報と、すぐに実装できる修正案が提示される点も実践的だと感じました。
これらを通じて感じたのは、AWS Security Agent は単なるチェックツールではなく、比較的シンプルに導入でき、開発プロセスの中でセキュリティを意識する機会を増やすことで、組織全体のセキュリティレベルを底上げしていくための仕組み だということです。SRE やセキュリティが本来果たすべき Guardian 的な役割を、プロセスとスケールの両面で補強してくれる存在だと感じました。
AWSの方とのディスカッションで深まった AI DLC の現実感
re:Invent の期間中、AWS の方から声をかけていただき、AI DLC（AI Driven Life Cycle）を推進しているリーダーの方とホテルで約 45 分ほどの個別ディスカッションを行う機会がありました。私の拙い英語力もあり完全に理解できたわけではないですが、以下は、その内容を踏まえつつ、私自身の理解として整理したポイントになります。
人のロール（プロジェクト体制）の変化
まず話題になったのは、人のロール（プロジェクト体制）が今後どう変わっていくか、という点でした。 私自身の理解として整理すると、AI によって「エンジニアが不要になる」というよりも、エンジニアリングの担い方そのものが変わっていく、という見方がしっくりきました。
- 短期〜中期
- 人が完全にいなくなる世界ではなく、ビジネス要件を AI を使って実装へ落とし込む役割としての「AI ドリブンエンジニア」が中心になっていく。
- ロールの統合
- フロントエンド、バックエンド、データベースといった細分化された専門ロールは次第に統合され、実装スピードと判断力がより重視されるようになっていく。
「ガードレール」から「ガーディアン（Guardian）」へ
一方で、すべてのロールが置き換わるわけではありません。セキュリティ、SRE といった領域は、機能実装ではなく、全体に対する制約・信頼性・安全性を担保する役割として、今後も重要であり続けると感じました。
いわゆる「ガードレール」という言葉よりも、「ガーディアン（Guardian）」という表現の方が近く、守るべき原則を定め、それが守られているかを継続的に確認し、必要に応じて改善していく。こうした役割は、AI が前提になるほど、むしろ価値が高まっていくように思います。
AI DLC における責任分界点
AI が生成した成果物に対して、人がどこまで理解・承認すべきかは、確かにボトルネックになり得ます。ただし、それを理由に AI を使わないのではなく、「人の関与を前提としたプロセスをどう設計するか」が重要だという点です。
- 現時点では、成果物を細かい単位で区切る。
- 定期的に確認・承認することで負荷を下げていく。
- その積み重ねによって、将来的には人の関与ポイントを減らしていく余地がある。
AI DLC は、人を外すための仕組みではなく、安全に人の役割を変えていくための開発プロセスなのだと理解しました。
re:Invent で感じた「コモディティ化」
re:Invent を通して、AI が多くの技術領域で急速に一般化していく流れを強く感じました。 個々の組織やチームが独自に工夫して解いてきた問題の多くが、AI を前提とすることで「共通の前提条件」として扱えるようになり始めています。
その結果として、これまで差別化要因だった実装力や運用ノウハウが徐々に相対化され、どこに人が価値を出すべきかが、よりシビアに問われるフェーズに入ってきていると感じました。
中期の中心的役割：「AI ドリブンエンジニア」
中期において中心的な役割になっていく可能性があるのは、「AI ドリブンエンジニア」というロールです。 AI ドリブンエンジニアは「何でも屋」ではありません。一方で、従来の実装担当よりもはるかに広い裁量と視野を持ちます。
主なスキル要件
- ドメイン要件を理解し、AI に適切に分解・指示できる
- 実装結果を読み解き、設計として妥当かを判断できる
- フロントエンド／バックエンド／DB といった境界を意識せずに手を動かせる
AI ドリブンエンジニアとは、AI をレバレッジにして実装のスループットを最大化する役割だと考えています。ビジネスアナリストが定義したドメイン要件を、AI を活用しながら実装に落とし込む役割です。
結果として、フロントエンドやサーバーサイドといった細分化されたロールは、今後徐々に統合されていく可能性があります。
SRE はこれから何を担うのか
AI の進化によって開発のスピードや変更量は大きく増えつつあります。こうした状況の中で、SRE に求められる役割は、変化が前提となった開発・運用をどう成立させるかを考え続ける役割へと広がっていくと感じています。
具体的に重要になる点
- 変更が頻発する前提での可観測性の設計
- 想定外の事象が起きることを前提にしたリスクの捉え方
- どこまでを仕組みに任せ、どこで人が判断するのかという境界の整理
SRE は、個別のサービスやチームに閉じた最適化ではなく、横断的な視点でこの問いに向き合い、現実のプロセスとして落とし込んでいく役割を担います。
おわりに
AI の進化によって、これまで当たり前だと思っていた前提が少しずつ崩れ始めています。ただし、それは「人の役割が不要になる」という単純な話ではありません。むしろ、どこで人が判断し、何に責任を持つのかが、これまで以上に問われるようになってくるのではないかと思っています。
この文章が、AI 時代の開発や SRE のあり方について考える際の、ひとつのきっかけになれば幸いです。
