キーノート/生成AI主導の開発組織の構築（途中から参加）

スピーカー: Jeff Barr（AWS）

気になった内容

• AIが書いたコードと人間が書いたコードは遜色がなかった。
  速度も10倍～20倍で開発が進んでいったが、
  これはバグも10倍～20倍の速度で生み出されるということを意味する

Changing How Software is Built

• シニアエンジニアの価値・知識がなくなる訳ではない。時にシニアエンジニアのみが発揮できる瞬発力もも必要になる場合がある
• プロンプトの作成力はエンジニア力とは直結しない。一方、自動化を進めていくことはさらに重要となっている

Blockers and Challenges

• 成果物が10倍～20倍になるということは、コードの品質確認プロセスも10倍～20倍にしなければならないということ。
  CI/CDのプロセスももっと早い頻度で求められることとなる。
  製造からリリースまでを10倍～20倍の速度で実施していかなければならない

Illustrating Amdahl's Law

• あるアイデアから並列でエージェントを動かし実現しようとしたとき、自ずとレビュー以降の作業がボトルネックとなる

[BMWのCI/CD 活用事例]（https://aws.amazon.com/jp/blogs/migration-and-modernization/an-engine-of-efficiency-bmw-groups-ci-cd-modernization-journey-with-aws/）

Teams and Processes Must Change

• Hacker Houseという考え方。開発チームのすべての人が衣食住をともにしながら一同に会し仕事をする。速度という意味ではこの考え方を提唱している人もいる。
  （筆者感：リーンもそんな感じでしたね）
• 今まで人数も2枚のピザを配れるぐらいの人数が望ましいとされていたが、AIが一部の作業を代替できるのならば1枚のピザを配れるぐらいにしたほうがバランスがいいのかもしれないと考える。
• しかし、それはすなわち、1人のエンジニアがより多くのことを判断しなければならないことを意味する

Some Thoughts

• 今まではリファレンスを読み込んでエンジニアが理解して作業をする。知識が言語に紐づいき、伝えるために型ができていた
• これからは、型が存在しなくなるであろうと考える。まずやってみて、意のままに沿って動くかどうかが大事なのではないか
• アプリケーションの開発の仕方も、寿命が長く、大きな投資が必要だった今までの形が、再構築が容易になることでスクラップビルドの傾向が鮮明になると予想。
  このような形に切り替えるためには、マイクロサービスによる管理も重要。
• コンテキストとしてデータとスキーマの概念もより重要になる
• 今までもそうであったように、エンジニアはジェネラリスト化しながら新しい概念に適用していく必要があるし、今回もそうなるであろう。
• 重要な概念
  • Observation
    • ユーザーの課題を観測する
  • Communication
    • プロンプトによりコードを生成する時代では、コンテキストを伝えるためのコミュニケーション能力が必要
    • もはや生成されたコードを人間のエンジニアがレビューすることをしないエンジニアも存在する。
      その代わりに他のエンジニアや他のステークホルダーと話すコミュニケーション力を上げていくことも必要。
  • Cooperation
    • 近い距離でチームメンバーと協力して働く必要性
  • Concentration
    • 高い負荷に耐え、意思決定が行える精神力
  • Daily Learning
    • 新しい知識を毎日学び続けること。少しでもいいので毎日時間をとって新しい知識に触れるべき。

CCoEはAI指揮官へ

石井 拓也

• 検知の自動化はできても対処の自動化はまだ進んでいないのでは。どこまでをAIにやらせてどこまでをエンジニアに判断させたかの話
• 最初はLLMで全部自動化できるのではという考えを持っていたが、甘くはなかった。それっぽいが混ざり続けた結果数字が合わず本番適用できない結果となった
• この知見から、どこまでを任せるかが重要だということに気づくことができた
• 判断に至る思考を知識層・判断層・事実層に分類
  • 知識層
    • 人間が厳密にコンテキストを定義することが必要
  • 判断層
    • AIと人間が協調する領域
  • 事実層
    • AIの主戦場
• AIは検索・整理・文脈化。人間は正確なデータの用意・閾値の定義・決定。人間がAIに正しく判断してもらうためのサポートをする。こういった責任境界に辿り着いた。
• どう設計したか
  • 設計レビュー「知識アクセス」
    • AWS Knowledge MCPサーバーをベースとした知識参照基盤を用意するようにした。
    • この基盤に構成図を投げたりIaCのテンプレート案を投げることで、AIがレビューしてくれる基盤を構築することができた
    • ここでは、人が正確なデータの用意と決定を行い、AIはそのデータに対して仕様検索と照合、根拠・論点提示を行う役割分担
  • コスト診断
    • チームが予算を知らない・使っているコストを知らない・月額いくらか即答できないということが多い。
    • AIに丸投げした結果、計算ミス・別アカウントのコスト混入・架空の改善案を出すといった結果になり使い物にならなかった。
    • LLMにコスト計算をさせず、人間がスキルのような発想でコストを確定。事実層はこの形で固定し、AIは確定値の分析に徹しさせるようにした
    • 実例では、1つのシステムの本番・テスト環境のレポートを分析させる形式
    • 人間は分析すべきデータの範囲、データの確定、アクション定義といった前処理を行い、AIが実際に動くようなAIを従える考え方
  • セキュリティ：Security Hub一次調査の自律化
    • 現在構築中。Security HubのFinding情報を固定コンテキストとしてAIに渡し、そのコンテキストの中から状況調査を行う構想。
    • データの整理までは人間が行い、実際の分析はAIに行う考え方
• AIへのガードレール
  • Amazon Bedrock Guardrailsにより機密ワードの抑止など一定のガードレールを引けるが、完全に防ぎきれる訳ではない。ここは人間による運用でのカバーも必要。
• AIを指揮下において、協調することがAIネイティブCCoEであると考える

AWS DevOps Agent vs SRE俺 by 加我 貴志

スピーカー：しめじ/Kaga

• SRE：本番環境の運用にフォーカスしインシデント対応やリリースプロセスの改善等を行う業務
  （筆者感：なんとなくで理解していたがちゃんと役割を認識できていなかったかもしれない）
• フロンティアエージェント：対応チームの一員としてDevOpsを支えるAWSサービスとしてのエージェント
  • Kiro Autonomonus Agent
    • 仮想的な開発者
  • AWS Security Agent
    • 仮想的なセキュリティエンジニア
  • AWS DevOps Agent
    • 仮想的な運用者・SRE 今日はここの話
• AWS DevOps Agentとは
  • オペレーションエクセレンスを担保可能なエージェントを目指したもの
  • オペレーションエクセレンス：優れた顧客体験を安定して届けるために、ソフトウェアを正しく作り、運用を継続的に改善し続けること。Well-Architectedに定義されている。
  • 常時稼働のインシデントトリアージ、ガイド付きの解決支援
  • 事前事後の火消し・運用対応等
  • アラート起因でインシデント調査を即座に実施
  • テレメトリ・アプリケーションコードからインシデントの原因分析と現象の緩和策を提示する
  • 対応が完了すると再発防止策を作成。これを自動で実施してくれる
• DevOps Agent vs SRE俺
  • ケーススタディ：インシデント調査
    • SRE俺の場合n=1でオンコール検知、データ調査、コード調査、ドキュメント調査を直列に実施する
    • あちこちアクセスして迷子になりがち。人間はマルチタスクが苦手
    • DevOps Agentの場合、これら作業を並列して行い始め、インシデントの原因や緩和策を即座に提案可能
    • 初動はDevOps Agentが優位。インシデントの後始末もAWS DevOps Agentがやや優位（ポストモーテムをまとめる際のサマライズの部分にて）
    • ただし、まだプレビューサービス。事前・事後のモニタリング対応やチャットメッセージ数は決まっている。日本リージョン・日本語未対応。ファイルへの直接アクセスは不可。デプロイに関連する変更ファイルや差分にしかアクセスできない。この範囲でしか問題点を見つけられない
    • 初動ではAgentの完勝。ただ、まだSREの知見は不可欠。でも、SREがいないような組織では助けになる。今後のアップデートでさらに改善を期待。

[C6]こたつから始まったプロダクトは、どう育ち続けているのか ── 技術・人・プロダクトの“判断”がつないできたもの

スピーカー：波多野 謙介

• 「コラボフロー」というSaaSサービスの話。タイトル通りこたつの上で生まれた
• 22年間維持し続けてきたプロダクト。オンプレで10年。クラウドで10年。新しいアーキテクチャを取り入れながら革新してきた。
• 2015年 クラウド化
  • SaaSという概念が知られていなかった時代
  • クラウドに触るお題目として、お手軽版サービスとして別エディションとしてリリースした
  • コラボフローは仮想環境に切り出せる機能を備えており、同じような形をクラウド上（EC2ベース）でできるようにすることで実現しやすい環境にあった。
  • 2018年頃からクラウド型を積極的に採用する顧客が登場。しばらくして損益分岐点を超え計画的・積極的な投資が可能となった
• 2020年 サーバーレス採用
  • コラボフォームというサービスをサーバーレスで構築。外部からの申請書受領サービス。Lambda・DynamoDB・Auth0・React
• 2023年 レガシーコード改善・マイクロサービス化
  • 構造を解きほぐしカテゴライズ。その後API化しインターフェースを統一。（Javaベース・EC2で受ける形）
  • その後、Rustでコードを置き換えながらサーバーレス化。まだまだ取り組み途上。
• これから AIによる開発の変革
  • AI-DLCを取り入れ始めている。会話に重きを置いた開発スタイルは会社のカルチャーにもフィットし、チーム内への知識の継承にも役立っている。
  • リモートでもこれができればかなりフィットできる
  • レガシーコードがあったとしても、依存関係やドメイン知識をAIが読み取りながら開発ができる。レガシーコードがあったとしても、概念検証の速度が速くなってきている。
  • モノシリックな構成がコンテキストを与えやすい側面も見られる。AI活用をあきらめる必要はないが、複雑な依存関係によりコンテキストが大きすぎるとAIが混乱するため、適切な粒度で情報を渡しながら協調していく必要がある
• 変わってはならないこと
  • 顧客とドメインに向き合うこと。長く一緒に戦ってきたからこそこの共通認識を分かち合いながら仕事ができている。そのために営業部と開発部の相互理解も重要。
  • 変化を恐れずポジティブに

ランチセッション：

AI で実現する AWS Well-Architected レビューの効率化 ～ ナレッジベースと生成AIを活用した設計レビュー実践 ～

• 主な内容
  • 5つの壁。必要性の浸透、知識量、リソース、継続的改善の難しさなど
  • 人間によるレビューからGithub Copilotによるリアルタイムレビューに切り替えた
  • マークダウンによる設計書と各Architectedのそれぞれの項目（ピラー）を冗長性等を排除しyaml化。これをレビューのための知識材料とする
  • コンソールでのWell-Architectedツールでのツールも自動化した（項目のダウンロード・入力はCLIを通じ）
  • ワークフロー型とエージェント型の使い分けでは、今回のような手順が明確ならワークフロー型が有利。また、すべてをコンテキスト化しているがコンテキストウィンドウの大きさによりどこまでの知識を読み込めるかが変わる
  • 作業時間の削減効果については8～16h →2～6h
  • 属人化しない評価基準によるレビューツールの生成と、AI活用をカルチャーにできたのが一番のレガシー

[B7]クラウド × シリコンの Mashup - AWS チップ開発で広がる AI 基盤の選択肢

スピーカー：常世 大史

• アンナプルナ・ラボというベンチャー企業の知見を素地とし、2015年にAWSが買収し一員として自社チップを作り続ける
• 現在のAWSチップ体系
  • Nitro v6まで登場 EC2用 それ以降もありそう
    • DPUとして稼働。特にインターフェース通信速度が初期は10Gbpsだったところ現在400Gbps
    • Nitroではハイパーバイザーとストレージ。ネットワーク機能を分離しPCI Expressで通信させるようにすることでインスタンスサイズを柔軟にできるようになった。
      性能やセキュリティも各部品ごとの性能の引き上げや暗号化の徹底により向上
    • トランスポートプロトコルについて独自に構築（EFA）
  • graviton 5まで登場 クラウドワークロードに最適なチップ
    • 当初16コア→192コア
    • 16nm → 3nm
    • Graviton搭載ラックに対しNitroカードを挿入していき制御していく構造
    • デプロイ形態や環境性能の重視度合いで3や4を使い分け
  • Traniumu / Inferentia 機械学習向けアクセラレータ
• なぜチップに投資を続けるのか
  • 性能・コスト・電力効率を最適化
  • 仕様策定から導入までのスピード向上
  • 市場のニーズに迅速かつ柔軟に対応
  • 複数の選択肢を持つことで可用性を向上
  • 他社チップに比べ40%優れた価格性能
  • 最大60%の消費電力削減
• AI時代に求められるチップとは？
  • Transformers、ニューラルネットワーク層の制御、行列演算、積和演算とAIに求められる演算は突き詰めることができ、いかに効率よく行列演算を行うかが重要であるということはここ数年変わっていない
  • 効率を高めるために、シストリックトレイという考え方を用いている。他部品とのレイテンシが一番の計算上のボトルネックとなる。従ってメモリに計算データを一時的に書き込まず、次の演算ユニットへどんどん計算データを渡していくことでプロセッサ内で計算を完結させることが効率的な計算につながる
• AWSでのAIチップ活用
  • アンソロピックとAWSの協業の中で、AIコンピュータクラスタとして100万個のTraniumを展開している。
  • Tranium 2を利用した計算ユニットは他のAI向け計算ユニットよりも1.4倍多くのtokenを出力できている
  • OpenAIもAWSとの協業契約を2/27に締結。電力量に換算すると2GW、数百万個のチップの利用となる
• Traniumについて
  • Tranium 2は4つのユニットが1チップの中に存在、特化型のインターフェースでつながっている
  • Tranium 3 2.52PFROPS（MXFP8）、144GB HBM3メモリ
    • これをサーバー化し、300個以上のTranium 3を搭載し362PFLOPSの計算性能を誇る。20TBのHBM 3メモリを積載。2TBのネットワーク帯域。
    • Tranium 3ではネットワーク部をチップ内ではなくラック内のSwitchとして格納。モデルの大規模化が進む昨今ではこ形のほうが効率が良い。
    • ケーブルレスのためカードを差し替えるだけで交換可能
    • チップは水冷・風冷両対応
    • Graviton・Nitro・Traniumが協調して動いている
    • 電力あたりの出力トークン数が2に比べ5倍に向上
• Neuron SDK
  • AIモデルの推論・強化に利用可能。
• さらに使いやすい環境を目指して
  • 浮動小数点演算にCUDAを利用してすぐに計算する方式であったが、GPU向けのコードであるため直接互換性がなかった。これをTranium用の演算として直接プログラミングできるようになる（Native PyTorch）
• Neuron Kernel Interface（NKI）
  • 学習用のプログラムインターフェース、ライブラリ、コンパイラを艇庫湯。
  • これらにより高レベルプログラミングしたコードをハードウェアとシームレスに協調できる仕組みを他言語と同様に整える
• デモにて
  • Qwen系のモデルを使った性能比較及び動作概要のデモを実施。
  • モデルの実際の内部構造、呼出命令にかかった時間や内部構造、連携状態を見ることが可能となっている

[A11]クラウドネイティブ時代のウェブセキュリティ再考 ～AWS、コンテナ、CI/CDに潜む死角～

スピーカー：徳丸 浩

※後半中心にメモし切れなかったものがあります

• CI/CDを回してシステムのデプロイ及び運用を行うアーキテクチャを例にとる
• DAST/SAST/SCA等
  • DAST: 実際に動かしてのセキュリティテスト
  • SAST: コードレベルでのセキュリティテスト
  • SCA: プログラムが使っているコンポーネントレベルの脆弱性テスト。パッケージリストから精度高く診断可能。
  • コンテナイメージスキャン：コンテナが動くOS等のOS/ミドルウェアレベルの脆弱性テスト
  • 最近ではDependsbotでプルリクエストまで作ってくれる機能も存在。ゼロデイ脆弱性の判明後自動テストを走らせた上で運用に供するのがDevSecOpsの流れ
• DevSecOpsの中でのサプライチェーン攻撃リスク
  • hackerbot-claw
    • いくつかのプロジェクトのパブリックリポジトリが突然消失した事案
    • OSSでは誰でもプルリクエストが実施できるが、その際まず自動テストが動作する。この際、動作するコンテナに強い権限が与えられていたとき、プルリクエスト内に攻撃を意図したコードが仕込まれていると実行され、攻撃に必要な情報を入手する。その後リポジトリを制圧することとなる。
    • マルウェア感染はなかった。
  • Codecov
    • カバレッジツール内に不正なコードを紛れ込ませ、不正なコードが紛れ込んだパイプラインを実行させることで攻撃が可能になってしまう事例。
    • ソースコードが盗まれたが、その中に個人情報が紛れており対外公表が必要な事案となった。
      本番環境に影響はなかったが、AWS操作権限が盗まれれば、影響が出てもおかしくない事案。
  • 求められる対策
    • 点検が必要な項目：プルリクエスト、CI/CD権限、依存パッケージ
    • 外部からの文字列の受渡は環境変数を利用。ハードコード利用を前提としない
    • pull_request_targetは極力使わない
    • 依存関係のバージョン固定
    • アクセスキーのような長時間永続する権限ではなくOpenID Connectを使用する
• クラウド時代のアーキテクチャにおけるセキュリティ課題
  • マイクロサービス化・サーバーレス化が進んだとしても、自らの責任範囲の部分では認証・認可部分の整備や脆弱性診断が必要であることには変わらない。（詳細本スクラップ上割愛）
• Capital Oneでの事例
  • https://business.ntt-east.co.jp/content/cloudsolution/column-534.html
  • リバースプロキシの設定に脆弱性があり、EC2を踏み台としてS3から個人情報を窃取できてしまった事件
  • AWSに対する過度な信頼や、あいまいさや複雑さに頼るセキュリティの脆弱さも本事例の研究論文で指摘されている
  • アーキテクチャが変わっても最小権限の原則の順守や自らの責任範囲に対する脅威分析・対策の継続的実施等基本的なことを徹底していく必要がある

[D13]2025年で何が変わった？AWS新ベストプラクティス総まとめ

スピーカー：大畑 一志

• アップデート概況
  • 総Update件数: 2671件
    • AI, Compute, Analytics, Databaseといった基幹機能で200件強～382件のアップデート
  • メキシコ・タイ・ニュージーランド・台北の4リージョンが追加
  • 十数のサービスが新たに登場
• どうやって情報収集するかどうか
  • ベストプラクティスが変わったかどうかが重要では
• AWS Updateの収集方法
  • AWS What's new（RSS取得可能）。英語がおすすめ。日本語だと数日遅い。
  • 原文を読むのは負荷が高いため、whats-new-summary-notifierの利用がおすすめ（aws-samplesに公開されておりCDKでデプロイ可能）
  • X
• ベストプラクティスが変わったサービス
  • DynamoDB
    • Amazon DynamoDB のグローバルセカンダリインデックスにおけるマルチキーサポート | Amazon Web Services
  • NAT Gateway
    • AWS NAT ゲートウェイがリージョン別の可用性をサポート
    • 今まではそれぞれのAZごとにNAT Gatewayを配置する必要があったが、リージョンごとに単一で良くなった。
    • AZ障害時のルートテーブルの差し替えや、パブリックサブネットをAZごとに作ることによるセキュリティリスク懸念があったが、解消または軽減される
    • ただし適用についてはコスト・運用・ダウンタイムを考慮に入れること

[B13]変化に耐える設計、その定義が変わる ～レジリエンスから再生成へ。 AI時代のシステム設計論～

スピーカー：下川 賢介 / 加藤 潤一 / 中川 佳希 / 矢部 佑磨

※途中から

• 実装負荷の劇的な低下が解き放つものとは？
  • 人による確認作業がなくなる訳ではない。
  • レビューの目的意識自体の再定義は必要。品質確認ではなくドメイン知識の均等化のため等
• 「いつでも使えるサービス」の再定義をしてみたい
  • レジリエンスが今までシステム開発で問われてきたが、何か意味合いは変わったか？
  • いつでも使える＝即応性＝すぐにレスポンスを返せるシステムとは、レジリエンスとして復旧時間が早いこと。アクセスが伸びても高い負荷に耐えられること。これは今でも必要であるし、これからも変わるものではないと考える。
  • 全体障害ではなく部分障害に落とし込む。隔壁を置いておくことで、船に穴が開いてもダメージコントロールができるような考え方。こういった自己回復力を持つことはクラウド、かつオンラインシステムでは重要な考え方
  • チームがシステムに改善を加えるのはオフラインで実施する行為。
    この活動を担保するためには学習サイクルを回さないといけない。
    今まではかなり時間のかかる行為であったが、
    AIの登場によりこのループも高速化させることができると考える。クローズザループ。
    ワークフローの自動化により。
    そういった流れにも人間は適応していかなければならない。
  • Saasサービスを運営していく中でも、いつでも使えるサービスの重要性や概念は変わるものではないと考える。
    一方で、耐障害性等の非機能要件を追求しすぎると提供する価値のスループットが落ちてしまうため、サービスに応じてバランスをとらなければならない。
  • 障害対応もAIエージェント化。一次調査の品質はエンジニアが担保。バクラクの中でも転換は進んでいる（がまだ途上）
  • AIが直接本番環境に修正を加えることはなく、エンジニアの責任としているパネラーが多数。
  • 静的解析と同様AIも解析ツールとして使いながら、エンジニアはどんどん上澄みだけをレビューしていく必要があるのでは。人間はもはやループの外からレビューする存在になるよう舵が切られていると実感している。
  • モノリスなシステムにおいても、マイクロサービス化の機運が高まっている。AIファーストになれるようなアーキテクトにも変化していく必要があると考える。
• 採用・教育・キャリアがどう変わった？
  • まだ過渡期。AIが書いてきたものをジュニアがレビューし切れる状態ではない。ただ、もはや1年後も分からない。AIが出してくるものをレビューする必要がなくなれば、コードではなく提供する価値等に見るべきレイヤーが変わってくる可能性があると考える。どういった世の中・べスプラになるかの目線を各自がしっかり持つべき。
• 「10年後も動いていること」の価値
  • システムをなぜ動いているかが分からない制御不能な状態になっていればそれはエンジニアの敗北。管理可能な状態を維持し続けることが必要なのではないか。
  • スクラップ & ビルドに切り替えるべきかどうか。それをやるためには、設計や求める価値に対するコンテキストが必要。そのためコードに対する価値はなくなってはいないし筋が通っている必要はあるが下がっているかもしれない。従ってすべてを人間が実施していく必要はもはやないと思うが、AIを手足として従えることができなければ、10年後も動くシステムを維持できないだろうと思う。
  • AI時代の型・クラス・インターフェース、こういったスキーマはどのくらい大切か。
    • 現時点では価値が上がっていると考える。自然言語で表現できないこととプログラミングで表現できないこととそれぞれ存在すると思う。それがコンテキストになっていると考えれば、それが価値なのでは。ただそれが未来永劫続くかもそうとは思わない。
  • Human In the loopは維持されるのかそうではないのか
    • 説明責任が伴う限りは人の役割は存在するのでは。
  • Vibe codingでも品質を保つ開発論
    • AIをオーケストレーションさせるべき。例としてはTAKT
    • Kiroの開発の仕方のようにワークフロー化してしまった後にAIで回すならそうしたほうがいい。ただそれすらもいらなくなるような考え方はしっかり全体で作っていくべきでは。