サービスプラットフォーム事業部の加藤雅俊です。

2026 年 6 月に開催された AWS Summit Japan 2026 に今回初めて参加しました。

部署柄お客様環境の実機での作業を行なっていくことがあります。完全非定型であったり運用保守のルーティンに収まりきらない個別作業やスポット対応は今後も生じてくることでしょう。しかし、テンプレートに収まるような作業、冪等性の高い作業、人間がもはや手動で行わなくてよく機械的に対応できる作業、無意味なコードモジュールの時間のかかる分析と数十箇所に及ぶコード修正手順の手動作成、緊迫感があり人間の目検ではどうしても限界のあるログ調査といった労働構造をどこかで変えたいと思っていました。

そのため今回は、新サービスの発表よりも「調査や作業の主役が AI に移ったとき、自分たちに何が残るのか、何ができるのか」という視点でセッション・展示を拝見していきました。

現に、もはや AI を使うかどうかなどの前提ではなく、「調査と作業は、すでに AI エージェントが主役となり、AI エージェントを使う / 導入する / 活用する具体事例が、百花繚乱のグラデーションをなしている、それが企業の生産活動の最前線になるのではないか」。それが今回の AWS サミットより受けた強い印象でした。われわれ人間のエンジニアに残っているのは、何をどう任せるかを決める仕事と、最後に承認する仕事の軸であり、そしてジョブの重心が「実行」から「設計・判断」へずれていき、さらに今後の数年の短いスパンでも状況はどんどん流動的になるだろうな、というのが率直な実感です。繰り返しますが、もはやかつては名人芸的にも見られた迅速精緻な調査をもとにした視野が広く抜け目ない分析、ソリューション、設計提案といったことへの生身エンジニアのコミットは、目の前で確実に、良きにしろ悪しきにしろ変貌を遂げている印象です。

本記事では、その移動と、残ったものが見えた 4 つのセッション・展示を紹介します。

※ セッションの内容および記事中の数値は、当日の筆者の記録に基づく再構成です。正確性を保証するものではないため、検討にあたっては最新の公式情報をご確認ください。

1. 調査は、どこまでエージェントに移るのか

まず「移る側」から。スペシャルセッションで、調査の自動化に直結するデモが 2 つありました。

AWS DevOps Agent は「いつでも利用可能な運用チームメンバー」という位置づけのサービスです。アラートを受けた瞬間から自律的に調査を開始し、オブザーバビリティツール・ランブック・コードリポジトリ・CI/CD を横断して原因を特定します。AWS だけでなくマルチクラウドやオンプレミスも対象です。

AI エージェントで変わるクラウド運用

展示ホール AWS Village のブース（A111）。左のディスプレイは「AWS DevOps Agent × Kiro 運用デモ」のスライド、右が実際のデモコンソールで、CloudWatch のグラフと DevOps Agent の調査結果が並んでいる

デモが具体的でした。Lambda 関数で認証エラー率が上昇 → エージェントが調査開始 → 直近のデプロイに起因すると特定 → オンコール担当者がログインした時点で、原因と緩和策・ロールバック案がレビュー待ちで揃っている。

同じ方向のものは展示ホールでも体験できました。下は Kiro CLI が S3 の ACL 設定ミスを調査しているところです。

Kiro CLI による調査の実行画面

ブース A109 のハンズオン。原因（security.png にパブリック読み取り ACL が未設定）→ 対処（public-read ACL を設定）→ 確認（HTTP 200）→「解決しました」まで自走している。画面下部に実行時間 1 分 37 秒と表示されている

原因の特定から対処、確認までを 1 分半で終えている。私が手でやると、まずどこを見るかを思い出すところから始まります。

もう一つが AWS Continuum。「Security at machine speed」を掲げ、脆弱性のライフサイクル全体を自律処理します。

発見・優先順位付け・検証・修復の 4 段階を自律で回します。注目したのは優先順位付けです。「脆弱性がある」ではなく「デプロイされていて、到達可能で、本番経路にあって、事業影響が大きい」という条件で絞る。検証段階では偽陽性を炙り出し、サンドボックスで動く exploit の実例まで構成します。

そして、ここに最初の「残るもの」が出てきます。信頼の預け方が段階的だったことです。最初は推奨を人間が承認し、信頼が積み上がったら自律範囲を広げる。コントロールを手放さずにマシンスピードを得る、という設計でした。

一次調査と優先度付けはエージェントへ。承認の判断は人に残る。この節の写真はスペシャルセッションのスライドではなく展示ホールのデモですが（セッション中の写真が残っていないため）、示していた方向は同じでした。

2. 移したあとに残ったもの ── NTT ドコモ：構築の 80% を AI に

従来の構築プロセス

マニュアル確認 → パラメータ設計 → レビュー → 構築。従来は約 4〜6 ヶ月

5G コアネットワーク（5GC）をパブリッククラウド上に構築する取り組みです。従来の構築プロセスは約 4〜6 ヶ月を要し、人手も時間もかかるうえ、人為ミスによる手戻りや需要増への追従にも課題がありました。

AI × GitOps のアーキテクチャ

オーケストレータが 3 層のエージェントに振り分け、Git を経て CI/CD でデプロイ

ここに AI と GitOps を投入します。構成は 3 層です。

  • コンフィグ担当 ── IF 仕様書を参照して 5GC コンフィグを生成
  • アプリ担当 ── アドレス設計を参照して Helm を生成
  • インフラ担当 ── 構築マニュアルを参照して CloudFormation を生成

オペレータが「AWS 上に 5GC を構築してください」と指示すると、オーケストレータが振り分け、各エージェントが自分のナレッジベースを参照して設定ファイルを生成。Git に格納後、人のレビューと承認を経て ArgoCD 等がデプロイします。実装には Amazon Bedrock AgentCore が使われていました。

AI × GitOps の活用による効果

約 4〜6 ヶ月 → 約 1 ヶ月未満。約 80% 短縮

結果は 約 80% 短縮。

ただ、このセッションで一番重要だと思ったのは短縮率ではなく、何が残ったかでした。残ったのは 2 つです。

  1. オーケストレータのチューニング ──「どの処理をどのエージェントに依頼するかを、ある程度の制約をもって指示しないとちゃんと動かない」
  2. 人によるレビュー ── 「現時点では外せない」と明言されていました

80% が自動化されても、この 2 つは人の側に残りました。手を動かす仕事が、エージェントに何をどう任せるかを決める仕事に置き換わったという言い方の方が近いと思います。

3. 役割そのものが変わった事例 ── ログラス：SRE の人海戦術からの脱却

マルチプロダクト戦略の開始

最初の数プロダクトは SRE が人海戦術で ECS ベースのインフラを構築していた

この日、自分の問題意識に一番近かったセッションです。

経営管理領域の BtoB SaaS を提供する同社は、マルチプロダクト戦略を始めた当初、SRE が人海戦術でインフラ構築を担っていました。そしてその体制が限界を迎えます。

そこから Platform Engineering へ舵を切った、という話でした。

EKS モードの判断 ── EKS on EC2 を採用

DaemonSet と Security Group for Pod の対応可否が決め手

技術選定も参考になりました。EKS の実行モードは EKS on EC2 を採用。理由が明確です。

  • EKS on AWS Fargate ── DaemonSet が使えず、o11y・セキュリティ設定を一括適用したい要件と合わない
  • EKS Auto Mode ── シングルクラスタ構成では複数アカウントの RDS への経路が共存するため Security Group for Pod が必須。Auto Mode は非対応

マネージドの度合いが高いほど良いわけではなく、自分たちの要件から逆算して決める。当たり前のようでいて、選定時につい「新しい方」「楽な方」に流れがちなところです。

まとめ

「今の規模にあうか」ではなく「数年後の事業にフィットするか」で判断する

まとめのスライドが刺さりました。

  • 「今の規模にあうか」で判断すると、EKS はまだ早いのでは？となってしまう
  • そうではなく「数年後の事業にフィットするか」で判断する
  • EKS プラットフォームの構築には時間を要する。必要な時期から逆算して取り組むべき

結果として EKS + Helm + ACK + ArgoCD で「開発者が自走でき、統制も効く」プラットフォームを構築し、1 年間で約 20 のサービスが稼働。「トラブルシューティングのしやすさ等、課題は多いが、徐々に組織の構造が変わりつつある」という現在地も、誇張なく示されていました。

人海戦術で支える組織から、仕組みで支える組織へ。ここで残ったのは、数年後を見据えて技術を選ぶ判断と、開発者が自走できる形に整える設計でした。人数で支えていた頃には存在しなかった種類の仕事です。

4. そもそも渡せない仕事 ── 電通グループ：統制を設計する

ガバナンスはブレーキではなく、アクセルの前提条件

スライド見出しは「ガバナンスが生きているから、アクセルを踏める」。下段に「『何をやってはいけないか』が明確だから、『何をやっていいか』…」と続く

調査も作業もエージェントに渡せるとして、では渡せないものは何か。その答えの一つがこのセッションにありました。

同グループが 2021 年から構築してきた統制済み AWS アカウント払い出し基盤（DGCP）では、払い出し時点で ID・アクセス統制、ネットワーク統制、監査ログの改竄防止、コスト一元管理が効いている状態になります。

『遅い・高い』── 現場の反発にどう向き合ったか

ガバナンスを緩めず、リスクに応じて設計を変えた

ただ、最も参考になったのは現場の反発への向き合い方でした。移管開始当初、評判はとても悪かったと率直に語られています。

現場の声 対応
IT 審査の待ち時間が 1 ヶ月。リリースが間に合わない リスクベースの審査分岐 ── インフラ変更なしの機能改修はレビュー省略可
統制が厳しすぎて開発がスピーディーにできない 重要度に応じた統制の段階化
サーバー費が 5 倍になった 共通コストはグループ本社が一括負担 ── 現場は変動費のみ

統制の水準を下げるのではなく、統制のかけ方を設計し直したという整理です。

この「設計し直す」判断は、エージェントには渡せません。何を守り、どこを緩め、コストを誰が持つか ── リスクと事業のバランスを取る仕事は人に残ります。

なお登壇者は「AI Agent 時代の管理アーキテクチャ構想」も示しつつ、エージェントの一元管理については「正直これは難しいかもしれない」と本音を漏らしていました。一方で AI/LLM ゲートウェイによる API コール集約は「絶対にやるべき」と明言。できることとできないことを分けて話す姿勢に、かえって信頼感がありました。

さいごに

今回持ち帰ったのは、新サービスの知識よりも 仕事の重心が移っているという実感でした。

4 つのセッションで見えたものを、移る側と残る側で並べてみます。

エージェントに移る エンジニアに残る
一次調査・原因の切り分け どこまで任せ、どこで承認するかの線引き
脆弱性の発見と優先度付け エージェントに何をどう任せるかの設計
設定ファイルの作成・手作業のインフラ構築 最終レビューと承認
人数でこなしていた運用 数年後を見据えた技術選定
── 統制のかけ方の設計

右側を眺めて気づくのは、どれも「基準を決める」仕事だということです。どこまで任せるか、何を優先するか、何年後に何が必要か、どこを緩めてどこを守るか。エージェントが速く正確になるほど、この基準を与える役割の比重が上がります。

そして基準を与えるには、自分が何を基準に判断しているかを言語化できている必要があります。ドコモがオーケストレータのチューニングに苦労したのも、電通グループが統制を段階化できたのも、判断基準を外に出せたからでした。逆に言えば、言語化できていない判断はエージェントに渡せず、渡せないものを抱えたままでは自分の手も空きません。

少し話がそれますが、エンジニアが自身の将来像を語る時に、マネジメント・セールス・技術テックリードの軸で語られることがあるなとよく感じています。表面的にこの区分けは正しいのですが、安易な立場性の表明に内実を伴わず用いられることがあるなと思っていました。しかし、今回のような AI エージェント活用の最前線を見ることで、エンジニアの既存の役割認識が悪く言えば崩壊するとともに、うまくいけばマネジメントもセールスも、技術にも関わりながらポテンシャルを伸ばしていくこともできるかもと淡い希望も持ちました。不安と希望が混ざっていますが、AI エージェントが土台を変えていっているから、そこにバランスよくライドできるといいのかなと思っています。

最後までお読みいただき、ありがとうございました。