オンプレミスの HPC 環境からの移行を進める研究チームは、クラウドへのデプロイの複雑さに悩まされることがよくあります。従来のアプローチでは、AWS のネットワーク、ストレージアーキテクチャ、Slurm の構成管理に関する深い専門知識が必要でした。一般的な手動デプロイでは、インフラのプロビジョニング、ネットワークトポロジの設計、スケジューラの構成、パフォーマンスチューニングに数週間を要します。プラットフォームエンジニアリングのリソースが限られている研究チームは、計算能力に対する差し迫ったニーズと、デプロイの技術的な障壁との間で板挟みになってしまいます。 本記事では、業界のベストプラクティスを組み込んだ AWS PCS クラスターを、Kiro CLI を使って自動的にデプロイ・構成する方法をご紹介します。インフラのプロビジョニング、モニタリングのセットアップ、コスト最適化を担いながら、研究チームが特定のワークロードに必要とする柔軟性を維持する「カスタムエージェント」の作成手順を順を追って解説します。 クラウドにおける HPC クラウドベースの HPC は、柔軟なコンピューティングアクセス、幅広いリソースの可用性、そして価値あるインフラの抽象化により、標準的な手法となっています。本記事では、AWS Parallel Computing Service (PCS) と Kiro CLI を活用して、このアプローチを実演します。 AWS PCS : AWS PCS は、自動構成・スケーリング・メンテナンスを備えたマネージドな Slurm スケジューラを提供することで、HPC のデプロイを簡素化します。本サービスはクラスターのライフサイクル管理を担う一方で、コンピューティングリソースとジョブスケジューリングポリシーに対するコントロールはお客様が維持できます。PCS は、共有ストレージ向けの Amazon Elastic File System やモニタリング向けの Amazon CloudWatch といった AWS サービスとネイティブに統合され、HPC のデプロイで通常必要となる統合作業を削減します。 Kiro CLI : Kiro CLI は、特定のユースケースに合わせた専門的なガイダンスを備えた カスタムエージェント を定義することで、非常に強力なものになります。ドメインの専門知識をエージェント定義に直接エンコードすることで、組織のベストプラクティスや要件を理解した専用の自動化を構築できます。例えば本記事では、HPC ワークロード向けの AWS Parallel Computing Service のベストプラクティス（最適なインスタンスの選択、ネットワーク構成、ストレージの最適化など）を組み込んだ PCS デプロイエージェントを作成します。このエージェントは確立されたデプロイパターンを活用することで、複雑なクラスターのプロビジョニングを効率化し、デプロイ時間と構成ミスのリスクの両方を削減します。汎用的な自動化とは異なり、このアプローチは実証済みの方法論を特定のインフラのニーズに適応させる、インテリジェントでコンテキストを理解した支援を提供します。 はじめに 自動化された PCS デプロイのアプローチを実装する前に、3 つの前提条件が必要です。 インストールガイド に従って Kiro CLI をインストールする pcs-kiro デモリポジトリ からデモコードをダウンロードする ローカルの AWS 認証情報があることを確認する。 aws sts get-caller-identity を実行して確認できます （オプション） MCP 構成ガイド に従って AWS Knowledge MCP Server を構成する エージェントを使う まず、エージェントを初期化します。Kiro で TODO リスト設定を有効にしておくとよいでしょう。これによりエージェントのより詳細なプランニングが可能になり、クラスターの作成を進める際にタスクのリストを作成し、ステップごとに処理を進めるようになります。 kiro settings chat.enableTodoList true 対話型の PCS デプロイエージェントを起動します。 kiro chat --agent pcs-interactive-agent ディスカバリーフェーズ ここで、エージェントにクラスターの作成を手伝ってもらいます。 User: I am new to PCS. Help me create my first cluster with best practices. （訳: PCS は初めてです。ベストプラクティスに沿って最初のクラスターを作成するのを手伝ってください。） エージェントはまずアクティブな AWS 認証情報を確認し、詳細が不明な場合はいくつかのディスカバリーのための質問を返します。また、既存の環境を調査し、ベストプラクティスに基づいた推奨事項を提示します。これは、既存の VPC やその他の AWS リソースをエージェントに使ってもらいたい場合に役立ちます。 ここで詳細を調整・指定でき、エージェントは最終的なサマリーを作成して、お客様の AWS アカウント内でインフラの作成を開始します。 インフラの作成 以下はインフラ作成プロセスの抜粋です。環境や要件によって、この出力は変わる可能性があります。 Agent: VPC Created:vpc-█████████████████ (10.3.0.0/16) - Public Subnet:subnet-████████████ (10.3.0.0/20) - ログインノード用 - Private Subnet:subnet-████████████ (10.3.32.0/20) - コンピュートノード用 - Internet Gateway:igw-████████████ - NAT Gateway:nat-████████████ (52.38.92.80) - Route Tables:Public (rtb-████████████), Private (rtb-01484185571aabba1) Security Groups Created: - Cluster SG:sg-████████████ (Slurm ポート 6817-6818) - SSH SG:sg-████████████ (SSH ポート 22) IAM Role Created:AWSPCS-scientific-cluster-role - Instance Profile:AWSPCS-scientific-cluster - Policies:AmazonSSMManagedInstanceCore + PCS registration Cluster Created:pcs_xfzpdypb7z (scientific-cluster) - Status:CREATING → エンドポイント取得中 - Size:SMALL (最大 100 ノード、1000 ジョブ) - Slurm Version:24.11 - Controller Endpoint:10.3.45.99:6817 Launch Templates Created: - Compute:lt-████████████ (c6i.xlarge) - Login:lt-████████████ (c6i.xlarge + SSH key) Compute Node Groups Created: - Login Group:pcs_ndgfaikhwl (パブリックサブネット内に 1 台の c6i.xlarge) - Compute Group:pcs_████████████ (プライベートサブネット内に 0〜10 台の c6i.xlarge) - AMI Used:ami-████████████ (Slurm 24.11) - Status:CREATING (3〜5 分かかります) Queue Created:pcs_bogst8bszr (scientific) - Status:CREATING → ACTIVE - Targets:コンピュートノードグループ (pcs_dficwpzin2) - Purpose:科学計算ワークロード インフラの作成が完了すると、エージェントは詳細を提示します。AWS リソースのデプロイが失敗する場合もあります。エージェントに与えられた指示には、そうした問題のトラブルシューティングを行い、処理を続行する前に修正するように記載されています。また、エージェントは /generated ディレクトリにクラスターのサマリーとドキュメントを作成し、何がどのように構築・構成されたかを正確に示します。 完了すると、エージェントはクラスターへの接続方法とテスト方法を示し、コストの見積もりも提示します。 このわずかなやり取りの中で、完全に機能するネットワーク、コントローラー、キュー、コンピュートノードとログインノード、適切なテンプレートとロールを備えた、相応に複雑なアーキテクチャを作成しました。これらすべてを、一般的なニーズとユースケースを定義するだけで実現できたのです。 図 1: Virtual Private Cloud (VPC) 内での AWS Parallel Computing Service (PCS) クラスターのデプロイを示すアーキテクチャ図。 この図では、VPC の外側に配置された PCS コントローラーが PCS キューに接続されています。VPC の内側には 2 つのサブネットがあります。パブリックサブネットには、静的な起動テンプレートを使用する 1 台の c6i.xlarge インスタンスを含むログインノードグループがあり、プライベートサブネットには、動的な起動テンプレートを使用する c6i.xlarge インスタンス（0〜10 台のキャパシティ）を含むコンピュートノードグループがあります。両方のノードグループにはロールの割り当てが含まれ、コンピュートインスタンスや起動テンプレートのシンボルなどの AWS サービスアイコンで表現されています。 これらすべてのプロセスは、ユーザーとのいくつかのやり取りを含めて約 30 分で完了し、すぐにログインしてジョブの実行を開始できます。このアーキテクチャは、共有ストレージや追加のコンピュートノードグループ・キューなどを含むように拡張できます。 推奨されるベストプラクティス エージェントへの指示は、直接的・具体的・明示的に行う 例えば、本記事のアーキテクチャではファイルシステムを要求しませんでしたが、FSx for Lustre 分散ファイルシステムのセットアップを併せて依頼することも簡単にできる可能性があります デプロイをモニタリングし、混乱しているようであればコマンドをキャンセルする 時折の失敗は許容する — エージェントは回復する傾向があります 特定のユースケースに合わせてエージェントの構成をカスタマイズする ワークロードのコンテキストと要件を包括的に提供する 既知の制限事項 エージェントは詳細を見失うことがある — 必要に応じて指示を再度伝えてください 手動での検証が必要 — 結果が要件に合致しているか確認してください まとめ AWS Parallel Computing Service (PCS) は、Slurm クラスターを大規模に運用する際の運用の複雑さを取り除く、フルマネージドな HPC サービスを研究チームに提供します。Kiro CLI のマルチエージェントアーキテクチャと組み合わせることで、チームは本番環境対応の HPC 環境を数週間ではなく数時間でデプロイできるようになります。このアプローチは、基盤となるインフラの管理にかかるオーバーヘッドなしに計算能力を必要とする研究組織にとって、特に価値があります。 それでは、よい構築を！（Happy Building!） 著者について Markus Adhiwiyogo Markus Adhiwiyogo は、Amazon EC2 インスタンスを担当するシニアプロダクトマーケティングマネージャーであり、AWS Graviton、AWS Inferentia、AWS Trainium を含む AWS カスタムシリコンに注力しています。 Kyle Bush Kyle Bush は、AWS のヘルスケア・ライフサイエンスチームでグローバルなヘルスケア ISV を支援するシニアソリューションアーキテクトです。Kyle は、お客様が最新のテクノロジーを活用してデジタルトランスフォーメーションを推進し、ヘルスケアの提供と成果を近代化できるよう支援することに情熱を注いでいます。 Charunethran Panchalam Govindarajan Charunethran Panchalam Govindarajan は、AWS のシニアプロダクトマーケティングマネージャーであり、ハイパフォーマンスコンピューティングと量子テクノロジーに注力しています。彼は幅広いテクノロジー領域で活躍してきましたが、特に R&D と製品開発の交差点に関心を持っています。Charunethran はスタンフォード大学で電気工学の修士号を取得しています。仕事以外では、スケッチや哲学的な会話を楽しんでいます。 Kareem Abdol-Hamid Kareem は、スタートアップ向けのシニアアクセラレーテッドコンピュートスペシャリストです。アクセラレーテッドコンピュートのスペシャリストとして、Kareem は生成 AI、ハイパフォーマンスコンピューティング、超大規模ワークロードに関する新たな課題に日々取り組んでいます。余暇にはピアノを演奏し、ビデオゲーム『ストリートファイター』で腕を競っています。 翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文は こちら です。

1. はじめに 今年、AWS（Amazon Web Services）がAgentic Football Cupを発表しました。これまでにもDeepLens、DeepRacerやAI Leagueなど技術の可能性を体感できるサービスを出してきているAWSらしいサービスとなります。 AWS Summitでブースが出ていたので、担当者の方にいろいろと話を伺ってきましたので、紹介いたします。ただし、本サービスはワークショップは各地域で提供されているようですが、一般公開はされていないため、サービスを体感できるまでにはもう少し待つ必要がありそうです。 なお、本サービスはマルチエージェントで協調

p:has(> img) { width: 100% !important; } はじめに こんにちは、ZOZOMO部FBZブロックの杉田です。普段は Fulfillment by ZOZO が提供するAPIシステムを開発・運用しています。昨年からは、社内における開発者向けAI支援ツールの推進を担う専門チームでも兼務で活動しています。 ZOZOMO部SREブロックの𠮷富です。普段はFulfillment by ZOZOのSREをしています。 2026年6月25日・26日の2日間、幕張メッセにて「 AWS Summit Japan 2026 」が開催されました。本記事では、会場や各ブースの様子に加え、特に印象に残ったセッションについてご紹介します。 目次 はじめに 目次 AWS Summit Japanとは 会場の様子 セッション紹介 AI 駆動開発ライフサイクル (AI-DLC) のご紹介(AIM221) AI生産性のパラドックス 開発手法「AI-DLC」の紹介 実践事例と驚異的な成果 サイバーエージェントにおける AI 推進戦略と変革への取り組み(AIM229) エンジニアの評価制度 全社AI活用を可視化・底上げする「AI番付」の取り組み AIを「楽しむ」文化の醸成 人間がボトルネックにならないための「Human in the Loop」設計 生成 AI ブームのその先へ －AI を使いこなす人材戦略とプラットフォームエンジニアリング－(PRT237-S) 生成AIプロジェクトの成果創出までの「4つの壁」 本番化までの時間と「Governance as code」 生成AI時代の「FinOps」 Amazon S3セキュリティベストプラクティス（STG357） セッションのテーマと背景 S3セキュリティ8つのベストプラクティス 統制の分離とスケール Advanced VPC Networking－知っておきたいAWSネットワークの最新動向：VPC関連サービスのアップデートを総整理－（CDN320） Amazon VPC Latticeのさらなる進化とカスタムDNS対応 AWS Direct Connectとハイブリッド/マルチクラウド接続の強化 ワークフローオーケストレーターにおける複雑性と非決定性のコントロール（CNS454） ワークフローの役割とAWSサービスの紹介 指揮者は歌わない AIエージェントの非決定性を制御するアプローチ まとめ AWS Summit Japanとは AWS Summit Japanは、AWSの最新技術や活用事例を学べる日本最大級のイベントです。2026年も幕張メッセで2日間にわたり開催され、260以上のセッションや展示、ハンズオン、コミュニティ企画など、幅広いコンテンツが用意されていました。AIエージェントやサーバーレス、クラウド活用の最新動向など、今後のシステム設計や運用に関わるテーマが多く取り上げられていました。現地参加だけでなくオンデマンド視聴もできるため、気になるセッションを後から見返すこともできます。 会場の様子 紹介：𠮷富 早い時間から多くの参加者で賑わっていました。基調講演の開始時刻の前後は列が伸び、入場に1時間以上かかることもあったようです。 同僚提供写真 先着5,000名に毎年恒例のクッションとお弁当引換券が配布されました。さらに基調講演の開始前に入場したところ朝食も配布されていました。 いくつかのセッションは入場時に配布されるイヤホンを利用して視聴するサイレントセッションでした。座席に設置されたレシーバーを利用してセッションの音声を視聴できます。 AWS Builders’ FairではAWSサービスを利用したプロジェクトが多数紹介されていました。ゲーム形式のものが多く、楽しく学べました。 「Physical Hands'on Blocks　組んで守れ！　AWSアーキテクチャ」を実際に体験しました。ブロックを動かしアーキテクチャを完成させ、攻撃から守るゲームです。 ELBからEC2を切り離す痛恨のミス Physical AI特設エリアではロボットの実機を体験することができました。 セッション紹介 AI 駆動開発ライフサイクル (AI-DLC) のご紹介(AIM221) 紹介：杉田 AI生産性のパラドックス AIを開発に導入しても速度向上は10〜15％にとどまり、場合によっては「AIを使うと19％遅くなる」というデータが紹介されました。たとえコーディングで時間を節約しても、開発ライフサイクルの他の部分で時間が失われているためです。 AIは決して銀の弾丸ではないので、適材適所で効果的な使い方をしないとかえって状況の悪化を招く場合があると、実感としても強く感じています。この研究結果から、AIに丸投げしたり、逆にAIを単なる補助ツールとして狭く使ったりするだけではダメなのだとあらためて感じました。 開発手法「AI-DLC」の紹介 AIのポテンシャルを最大限に発揮したうえで、ビジネスの意図をソフトウェアシステムとして価値提供できるようにするには、従来の方法の延長線上では限界があります。具体的には、以下のような課題が挙げられます。 人間の関与を最小限またはゼロにした開発は信用が難しく、説明責任も果たすことができない AIによるアジリティは開発ライフサイクル全体では限定的 コーディングで節約した時間は他の部分で失われている これらの課題を解決するためにAWSが再構想したのは「AI-DLC」です。AI-DLCは以下の3つのステップに分かれ、人間の意図伝達、AIによる計画・実行、人間によるレビューや承認という形で進むオペレーティングモデルです。 Inception Construction Operation AI利用を前提とした開発が行われる昨今では、開発プロセス自体をAIネイティブに作り直すというアプローチはとても重要だと思いました。 コンテキストの扱いがポイントとなるAI利用を前提とした開発において、各ステップが次のステップのコンテキストを構築していく流れは、とても理にかなっていると感じました。 実践事例と驚異的な成果 実際の実践事例として、AI-DLCの導入により属人性の高い領域でも開発生産性が200％以上も向上したほか、従来の方法では2か月想定の開発をわずか48時間で達成させた事例が紹介されました。 ここまでの成果を出すには、AI単体の力ではなく、ビジネス、開発、QAなどのチームが垣根を越えて協働する「モブエラボレーション」の体制づくりが不可欠になります。 本セッションを通じて、AIを単なる開発支援のツールとして使う段階は終わったとあらためて痛感しました。適用できそうな領域からAI-DLCの思想を取り入れ、人間とAIが強みを最大化し合う新しい開発プロセスへの移行を検討していきたいと思います。 サイバーエージェントにおける AI 推進戦略と変革への取り組み(AIM229) 紹介：杉田 エンジニアの評価制度 サイバーエージェントでは、2028年の開発プロセス完全自動化を見据え、AIを武器に開発領域からビジネス領域へ越境する「ビジネスリードエンジニア」などを新設していました。技術のみならず課題発見から実装・運用までを一気通貫で担える人材を正当に評価する枠組みです。 詳細については、以下のブログに記載があったので、気になる方はご覧ください。 developers.cyberagent.co.jp AIの台頭により、コーディングそのものの価値が相対的に変化している中で、エンジニアのキャリアパスを組織主導で再定義している点が印象的でした。AI時代においてエンジニアが目指すべき姿を考えるうえで、参考になる評価軸だと感じました。 全社AI活用を可視化・底上げする「AI番付」の取り組み 各事業部におけるAI活用の「成果インパクト」や「カルチャー醸成」などを、相撲の番付表（横綱〜幕下）に見立てて評価・可視化している取り組みが紹介されました。 単にツールを導入して終わるのではなく、組織ごとの成熟度を定量・定性的に測る仕組みを作ったうえで、全社的なナレッジ共有と底上げを図る非常に効果的なアプローチだと感じました。特に、結果を分析レポートとしてまとめ、事業ごとの改善案を提案する仕組みは参考になりました。 AIを「楽しむ」文化の醸成 AIをフル活用して実装速度を競う「AI開発RTA」や、2日間でゼロからプロダクトを作る「AI Agent Arena」を開催した様子が紹介されました。これらのイベントを通じて、エンジニアがAIに楽しく触れる場を提供し、ベストプラクティスの創出・共有を促していました。 利用を強制するのではなく、イベントを通じて「AIフレンドリー化」を推進する姿勢は、組織の熱量を高める取り組みとして参考になりました。 人間がボトルネックにならないための「Human in the Loop」設計 自動化が進むと人間の監視が形骸化する「プロセスの萎縮」というリスクがあります。このリスクに対して、タスクのリスクに応じて「全件レビュー」「スコアベース」「エスカレーション」の3パターンで人間の関与を設計している取り組みが紹介されました。 タスクに関係なく一律でHuman in the Loopを採用するのではなく、リスクや複雑さを加味したうえで段階的にHuman in the Loopを設計している点が参考になりました。 サイバーエージェントの取り組みは、ツールの導入にとどまらず、評価制度、企業文化、そして開発プロセスそのものをAI時代に適合させていくといったものでした。AIと協働する新しい開発組織のあり方については、私の所属組織でも重要なテーマなので、今後の活動の参考になるセッションでした。 生成 AI ブームのその先へ －AI を使いこなす人材戦略とプラットフォームエンジニアリング－(PRT237-S) 紹介：杉田 生成AIプロジェクトの成果創出までの「4つの壁」 同社のアンケートから、2024年から2025年にかけて生成AIの活用率は増加している一方で、DXの成果について「期待通り以上」と回答した割合は減少していることが確認できました。 また、PoCの成功はゴールではなく、その先には「本番化までの時間」「LLMの精度不足」「利用が広がらない」「想定外のコスト増」という4つの壁が存在すると指摘されていました。 本番化までの時間と「Governance as code」 セキュリティやコンプライアンスの都度審査により、本番の開発開始までに数か月を要するケースがあると紹介され、これは組織の規模感が大きくなることでより顕著になる傾向があります。対策として、ガバナンス要件を組み込んだ開発テンプレート（Governance as code）を用意し、事前承認済みの型を開発者に利用させるアプローチが紹介されました。 守りのプロセスを自動化・テンプレート化して、開発者の認知負荷を下げる取り組みはまさにプラットフォームエンジニアリングの真骨頂だと思いました。Governance as codeは、社内での車輪の再発明を回避する手段として、OSSで有名な Backstage をはじめとした開発者向けポータルとの相性が良いと感じました。 生成AI時代の「FinOps」 生成AIの利用拡大に伴い請求額が想定の数倍に膨らむリスクに対し、コストの可視化とプロンプトキャッシング等の対策が紹介されました。 プロンプトキャッシングの仕組みとして、キャッシュは先頭から一致した場合のみヒットするため、プロンプトの上部に変数（可変部）が存在すると効果が薄くなる点について解説されました。 そこで、この性質を活かすために可変部をプロンプトの下部に移動させる構造変更をしたことで、1ワークフローあたり400円かかっていたコストが80円（80％削減）へと劇的に改善した事例が紹介されました。 機能としてキャッシングを有効にするだけでなく、内部の仕組みを理解してキャッシュヒット率を最大化している点は学びでした。生成AIを活用するうえで、それらのコストは切っても切り離せない課題だと思うので、機能を使いこなすことによるコストインパクトに驚きました。 Amazon S3セキュリティベストプラクティス（STG357） 紹介：𠮷富 Amazon S3はシステム構成において、データ保存先、ログ出力先、バックアップ、データ連携基盤など、さまざまな場面で利用されています。利用用途が増えるにつれて、アクセス制御や利用者・アプリケーションごとの権限管理、意図しない公開の防止など、セキュリティ面で考慮すべきポイントも増えていきます。 このセッションでは、Amazon S3のセキュリティを高めるためのベストプラクティスを改めて学べました。 セッションのテーマと背景 パブリックアクセスのブロック（BPA）や全新規オブジェクトの暗号化などがデフォルトで有効になっており、データを安全に活用しやすいデフォルト設定が用意されています。 S3セキュリティ8つのベストプラクティス データ保護を実現するためのプラクティスとして以下が提示されました。 パブリックアクセスをブロックする 。 バケットキーを有効にする ：SSE-KMS利用時のAWS KMSコストを最大99％削減。 統制を分離してスケールする 。 セキュリティ変更をモデル上でテストする 。 AWS Organizationsを活用する ：RCP/SCPによる組織レベルの強力なガードレールを適用。 データ保護をアプリケーションにも広げる ：チェックサムの活用など、アプリケーション側でもデータ保護を考慮する。 ログを有効にする ：異常検知や自動修復などの対応を実装する。 耐久性とリカバリを事前に計画する 。 統制の分離とスケール ビジネスや組織の成長に合わせて、権限管理における統制を分離する必要があります。単一のバケットポリシーだけですべてを管理しようとすると保守が難しくなりやすいため、以下の機能を活用して権限を適切に委譲・分割する考え方が紹介されていました。 S3 Access Points ：ユースケースごとに独自のポリシーを持たせる。 S3 Access Grants ：特定のプリンシパルに対して、バケットやプレフィックスへのアクセス権をプログラムで付与する。 ABAC（属性ベースアクセス制御） ：リソースやプリンシパル名ではなく、タグに基づいてセキュリティポリシーを定義する。 S3のセキュリティはバケットの設定だけで完結するものではなく、組織全体のガバナンスやアプリケーション側も含めて設計する必要があることを再認識しました。紹介されていた内容の中には、パブリックアクセスブロックや暗号化、ログ設定など、既存のバケットでもすぐに確認できる項目が多くあります。S3を利用している環境がある場合は、ぜひこの機会に設定状況を見直してみてください。 Advanced VPC Networking－知っておきたいAWSネットワークの最新動向：VPC関連サービスのアップデートを総整理－（CDN320） 紹介：𠮷富 このセッションでは、VPCやネットワーク関連サービスにおける2025年のアップデートを網羅的にキャッチアップできました。普段VPCを触っている人ほど、こんなにアップデートがあったのかと驚く内容だったと思います。紹介量が多く見応えのある内容だったので、ネットワーク構成に関わる方はぜひチェックしてみてください。特に気になったアップデートを2つ紹介します。 Amazon VPC Latticeのさらなる進化とカスタムDNS対応 VPC Lattice は、複数のVPCやアカウントをまたぐサービス間通信を論理的にグループ化（サービスネットワーク）してつなぐ機能です。これまではサービスやリソースに自動生成された一意のFQDNが割り当てられていましたが、2025年のアップデートとして、カスタムDNS名や設定可能なIPに関する機能強化が紹介されていました。自分で設定したDNS名によるアクセスが可能になり、既存のアプリケーションからのアクセスルーティングがやりやすくなります。 AWS Direct Connectとハイブリッド/マルチクラウド接続の強化 マルチクラウド接続を容易にする「AWS Interconnect Multicloud/Last Mile」が一般提供（GA）を開始しました。Direct Connectを経由してオンプレミス環境や他クラウド、AWS上のアプリケーションを接続しやすくなり、ハイブリッド/マルチクラウド環境におけるネットワーク設計の選択肢が広がりました。 VPC関連サービスでは、2025年だけでも150以上の新機能が追加されたそうです。このセッションはVPC周辺の最新情報をまとめてキャッチアップする良い機会になりました。 2024年のVPC関連サービス 2025年のVPC関連サービス ワークフローオーケストレーターにおける複雑性と非決定性のコントロール（CNS454） 紹介：𠮷富 ワークフローは事業の成長、システムの改修に伴って複雑になってしまうことがあります。さらに障害の監視・管理やリトライ処理といった例外的な処理の整備によりシステムが複雑化したり、それらの解決のためにあらゆるシステムでAI・MLとの結合が求められたりするようになっています。 このセッションでは、複雑化しがちなワークフローの管理手法と、AIエージェント特有の「非決定的」な挙動をどう扱い、どのようにアーキテクチャに組み込むべきかを学べました。 ワークフローの役割とAWSサービスの紹介 ワークフローは、複雑なシステム連携における例外処理・リトライ・並列処理・Map実行などの課題に対応し、可観測性（オブザーバビリティ）を高めるために用います。セッションでは、要件に応じたAWSの主要なワークフローオーケストレーションサービスの使い分けが紹介されました。 AWS Step Functions ：GUI上でワークフローを視覚的に設計できるサービス。JSONataに対応しており、ステートマシン内でデータの変換・抽出・加工を行える。 AWS Lambda durable functions ：JavaScript/TypeScriptやPythonなどで、長時間実行されるワークフローをコードとして記述できる仕組み。最大1年の実行に対応し、リトライや状態管理を扱いやすい。 Amazon MWAA ：Apache AirflowをAWS上で利用できるマネージドサービス。DAG（有向非巡回グラフ）によってタスクの依存関係や実行順序を管理でき、AWS外のシステム連携にも向いている。 指揮者は歌わない 複雑性保存の法則 が示す通り、システムが持つ複雑さを完全に消し去ることはできません。重要なのは「複雑性をどこに置き、どうコントロールするか」であり、その基本方針がワークフローの分割です。そこであげられていたのは「指揮者は歌わない（関心の分離）」という設計原則です。 例えばStep FunctionsのChoice stateに複雑なメール検証のような検証ロジックを書くと、保守が困難になります。オーケストレーターは進行管理に徹し、ビジネスロジックはAWS Lambdaなどのコード側に切り出すべきです。 AIエージェントの非決定性を制御するアプローチ ワークフローにとってAIは、予期せぬ判断や無限ループを引き起こす可能性のある「非決定的」なシステムです。この揺らぎをシステムに組み込む方法として、決定論的ワークフローで包み込むアプローチが紹介されました。 Outer/Inner Loopパターン：AIの非決定論的な推論を、タイムアウトやリトライを備えたワークフローで制御。 Human in the Loop（HITL）パターン：重要な判断はAIに任せきらず人間の承認フローを挟む。 Workflow as Toolsパターン：既存の決定的なワークフローを、AIから安全なツールとして呼び出す。 また、Amazon BedrockなどのAIサービス利用時は、スロットリング対策としてExponential BackoffやJitterの活用が重要です。 Exponential Backoff リトライ間隔を指数関数的に増加させることで、サーバーの負荷を軽減する。 Jitter リトライ間隔にランダムな揺らぎを加えることで、同時リトライを防ぐ。 AIエージェントを利用する場合でも「処理を適切な単位で分割・委譲する」という設計の基本が大切なことを再認識しました。 まとめ 今回のAWS Summit Japan 2026を通じて、AI活用を前提にした開発・運用のあり方を改めて考える機会になりました。 生成AIは単なる開発支援ツールではなく、開発プロセス、組織文化、評価制度、ガバナンス、コスト管理まで含めて向き合うべきテーマになっていると感じました。一方で、AIエージェントのような非決定的な仕組みを安全に扱うためには、Human in the Loopや決定論的なワークフローによる制御など、従来から大切にされてきた設計原則も引き続き重要です。また、S3やVPCといった基盤領域についても、サービスの進化に合わせて継続的に設計や設定を見直す必要性を再認識しました。 今回得た学びを、日々の開発・運用だけでなく、社内でのAI活用推進にも活かしていきたいと思います。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com