Vibes Containers 〜AIで変わるコンテナ設計と運用〜

JAWS SONIC 2026の登壇資料です。
https://jawssonic2026.jaws-ug.jp/

※登壇時に端折ったスライドも複数枚含めています。
※Vibesありません

- AWSコンテナ本 (改訂版) https://www.sbcr.jp/product/4815626044/
- 9/17 ECSサービスチーム来日イベント: https://jawsug-container.connpass.com/event/404836/
- ソフトウェアサプライチェーンの構造的リスクとコンテナ環境の保護 （@kyohmizu） http://speakerdeck.com/kyohmizu/no-kouzouteki-risuku-to-kontena-kankyou-no-hogo

Transcript

1. #jawsug #jawssonic2026 Vibes Containers 〜AIで変わるコンテナ設計と運用〜 コンテナ支部 菊池 哲哉(@t-kikuc) 1
2. 自己紹介 • 菊池 哲哉 (@t-kikuc) • Software Engineer • マラソンやってます • コミュニティ: ◦ JAWS-UG コンテナ支部運営（2026-） ◦ AWS Community Builder — Containers（2025-） ◦ レビュー: 『AWSコンテナ設計・構築[本格]入門 増補改訂版』(2026) https://www.sbcr.jp/product/4815626044/ 2
3. コンテナ支部の紹介 • ECS,EKSなどのコンテナを扱う専門支部 • 運営メンバー募集中 https://jawsug-container.connpass.com/ 3
4. 9/17 ECSサービスチーム来日イベント • 現地枠埋まりました • オンライン枠用意しました！ 目玉: https://jawsug-container.connpass.com/event/404836/ 4
5. 今日の話 5
6. 「コンテナの設計・運用、AIで何が変わった？」 • • 4種で整理 1. ガラッと変わった 2. 重要 → 即決へ 3. 改めてチェックしたい 4. 意外と変わってない どこかで 「AI時代はECSかEKSか？」 話さないこと： ◦ コンテナxAI の片方にしか関わらないこと ◦ LLMアプリをコンテナで動かすケース ◦ 各手法・ツールの詳細 ※2026年9月時点のスナップショットで話します 6
7. 1. ガラッと変わったこと 7
8. 運用時のトラブルシューティングが飛躍的に効率化 • 障害原因分析、対応策検討 • 運用上不可欠なレベル ◦ 特にログ分析は強力 • 実現方法： AWS DevOps Agent、HolmesGPT（CNCF Sandbox） など • 前提： ◦ Agentがアクセスできる情報を増やす ▪ ◦ AWSの各種API、kubectl、コードベース、設計書、ログ、メトリクス、トレース、 ... Agentが安全に情報収集するための権限制御・データ保護 ▪ 稼働中コンテナ内もAIに分析させるのは要注意 （ecs execなど） 8
9. 2. 重要 → 即決へ 9
10. 以前から重要だったが、今は即決で必須になったもの • オブザーバビリティ • Single Source of Truth （IaC、Git管理） • コンテキストを残す • シークレット管理 全てAI活用の前提条件 もはや導入是非の検討・説明コストが無駄かもしれない 10
11. オブザーバビリティ • Agentによる分析精度を上げるために必須 ◦ トラブルシューティング ◦ コスト最適化 ◦ 性能改善 • ログ・メトリクスはアプリとインフラの両方が欲しい • 主な論点： データ量とコストのトレードオフ 11
12. Single Source of Truth • • 実状態とGitがズレると、人間でもAIでも正しさを判断できない ◦ 手動変更・ドリフトが入ると、AIの分析がそこで終了する ◦ Gitに基づいてAIに変更PRを作らせても、Apply時に失敗する やること ◦ IaC + ドリフト検出を組み込む ◦ KubernetesレイヤーのGitOps （Argo CDなど） ◦ 運用で利用したコマンド・ログも履歴を残す 12
13. コンテキストを残す • 「なぜ」が不明なものはAIが手を出せない（人間も同じ） • やること： あらゆるパラメータに、できるだけ経緯・背景を残す ◦ 場所： コードコメント / ドキュメント / PR説明文 など ◦ 特に数値パラメータはマジックナンバーにしない 13
14. シークレット管理 • プロンプトインジェクションを含む、Agentの暴走から防御する • Gitにシークレットがある → そのリポジトリはAgentに読取させられない • やること ◦ ◦ AWS Secrets Manager / Parameter Store（SecureString）を使う ▪ Agentにはそれらへの読取権限も付与しない ▪ EKSならExternal Secrets Operatorも用意 +α） Agentがアクセスできるメモリにシークレット値が露出しない仕組み 14
15. 3. 改めてチェックしたいこと 15
16. 改めてチェックしたいこと 1. 性能改善 2. マニフェストの自動検証 3. サプライチェーンセキュリティ 16
17. 性能改善に手を出しやすくなった • 「計測 → 改善」ループが楽になった • 例 • ◦ Dockerfileの最適化 ◦ コンテナ起動速度の改善（イメージキャッシュ、Lazy Loading等） ◦ メトリクス / トレース / プロファイルからボトルネック特定 → 修正 → 再計測 ◦ スケーリング設定、サイジング 注意: AIを利用しても、大掛かりな負荷試験はコストが高い 17
18. マニフェストの自動検証 • • 課題: AI生成マニフェストの安全性をどう担保するか？ ◦ 人間によるレビューが追いつかないけど、AIレビューに全部任せるのも不安 ◦ ECS/EKSの設定誤りは影響が大きい傾向 対策: PR・デプロイ時に決定論的チェックで補助する ◦ スキャン： Trivy / Hadolint / tfsec … ◦ ポリシー： OPA / Gatekeeper / Kyverno … ▪ ◦ • 例： CPU/メモリの範囲制限、特定ラベルの付与必須 この辺りの機構はECSよりEKSが強い 注意点 ◦ 全ての問題をチェックできるわけではない ◦ 厳しさと柔軟性のトレードオフ 18
19. サプライチェーンセキュリティ • コンテナ関連の保護の例 (全てが必須ではない) 保護 概要 固定する FROM image@sha256:... や lock file 信頼できる依存のみ許可 ベースイメージ / ライブラリ / リポジトリ CIの権限を絞る CIとCDの分離も視野に イメージ署名・検証 イメージ作成元を検証。 ECRマネージド署名もある（検証は自前） SBOMの管理 CVEの影響をすぐに特定 Provenanceの検証 正規のパイプラインで作られたかを検証 Rendered Manifest Pattern Renderとデプロイの分離。Render結果をGit等に格納して固定する デプロイ前のポリシー強制 本番に入れる前にブロックする。 EKSは得意、ECSはパイプラインで 多層防御 Trivy等セキュリティツール自体の侵害にも備える （キリがない） 19
20. サプライチェーンセキュリティ • 正直、キリがない • まずやること： 全体像の把握 + 優先度決め ◦ 参考： ソフトウェアサプライチェーンの構造的リスクとコンテナ環境の保護 （@kyohmizu） http://speakerdeck.com/kyohmizu/no-kouzouteki-risuku-to-kontena-kankyou-no-hogo 20
21. 4. 意外と変わってないこと 21
22. 「ECSかEKSか？」 はあまり変化なし • 「学習・調査コストが大幅に減ったから、EKS圧勝」 ではない • 「この変更で本当に大丈夫か？」の検証/品質保証コストが残っている （特にクラスタアップグレード） ◦ 実際にApply + 運用しないとわからない問題も多い • AIで少人数化 → 尚更インフラのお守りに人間を割けない → マネージドが有利 • EKSが有利になった点もある ◦ マネージドより見えるデータが多い → Agentの分析力 ◦ ポリシー検証を組み込みやすい • 「EKSでなければ叶わないこと」+ 組織形態/人員体制 が引き続き肝 • EKSのマネージド範囲拡大にも注目 （Auto Mode、EKS Capabilities） ◦ というケースも 基本全部マネージドで、好きなとこだけカスタマイズできたら理想 22
23. 決定論的な手段から考える • • • AIで何でも解決しようとすると直面する問題： ◦ レイテンシ ◦ 精度の安定性 ◦ コスト （値上げ) ◦ 育てる手間 ◦ カオス 決定論メインが良い例： ◦ CI： 原則は各種ツールに頼る。それらでカバーできないものはAIを使う ◦ デプロイ、スケーリング： 決まった処理で回す ◦ 障害対応Runbook： 同事象には同じスクリプトで対処する。「同事象か」の判定補助でAIを使う 今までやっていたことをAIと共に強化する 23
24. 「人間でもAIでも難しい問題」を忘れない • • One-Way Door / 後戻りコストが高いもの ◦ 実行基盤の無停止移行 （ECS↔EKSなど） ◦ サービスメッシュの導入 / 撤退 / 乗換 ◦ ステートフルワークロードの移行 回避できない限界・コスト ◦ Quotaによる制限、Node数上限 ◦ マネージドで隠された問題のトラブルシューティング ◦ 負荷試験のコスト → 事前の熟考 + 取捨選択が必要 24
25. Garbage In, Garbage Out • 人間が(不正確な)入力を与える限り、モデルが進化してもAIの出力は不正確 ◦ AIの出力をレビューする動機の一つは、人間による入力が怪しいから ◦ 暗黙の要件・文脈の伝え漏れによって、無駄に複雑な解決策に陥りがち ▪ • 例： 価値を生む機能はどれか、組織の体制・方向性、事業の方向性 要件・コンテキストを与えるセンスは引き続き問われる（今のところ） ◦ AIと格闘する 25
26. 結局、「AWSコンテナ本」から大きく変わってなかった • 今回の発表のために、改めて書籍(2026/01出版)を読んだ ◦ • →「今でも使えるプラクティスばかりだ...」 全然Vibes出せませんでした https://www.sbcr.jp/product/4815626044/ 26
27. まとめ 27
28. まとめ 1. Agentによるトラブルシューティングは極めて強力 2. 設計プロセスは変わったが、設計原則は大きく変わっていない 3. サプライチェーンセキュリティは今後注目 4. しばらく人間がやること： 全体像を把握する + 要件を与える + 取捨選択 28
29. ありがとうございました #jawsug #jawssonic2026