はじめに
こんにちは！ ドコモ・テクノロジの奥田です。
クリスマスイブですね🌲 みなさんのところにはサンタさんは来ましたか？ 私はしばらく会えていません…🎅
私が所属するドコモ・テクノロジという会社を聞いたことはありますか？
ドコモ・テクノロジは移動通信システムを構成するネットワーク装置や携帯端末の開発、移動通信システムを保守・監視する装置の開発、先進技術を活用したスマートライフ・法人領域でのサービス・ソリューション開発などを行っているドコモグループR&Dの機能分担会社です。
私はその中の「サービスインテグレーション事業部」という組織に所属していて、クラウドコンピューティングやデータサイエンスなど、最新スキルの習得を進めつつ、日々様々なことに取り組んでいます。
パブリッククラウドへの更なる知見を深め、世界でも通用するエンジニアとしての価値を高めるべく、サービスインテグレーション事業部の社員4名が12/1〜12/5にラスベガスで開催されたAWS re:Invent 2025に参加して来ました。今回の記事では現地の熱気やそれぞれが参加したセッションについてご紹介します！
AWS re:Invent とは
AWS re:InventはAmazon Web Services（AWS）が毎年開催している、世界最大級のクラウドコンピューティングカンファレンスです。世界各国から数万人もの技術者やビジネスリーダーが集結します。ただ参加するだけではなく、「学習型カンファレンス」です。
膨大な数のコンテンツが用意されているので、re:Inventに参加する人はそれぞれの専門領域に関連しそうな興味があるものをピックアップし、参加することになります。ドコモ・テクノロジから参加した4人がそれぞれどのようなセッションに参加して来たのかをここからご紹介させていただきます！
参加したセッション
自己紹介①（奥田）
改めまして、ドコモのCCoE（Cloud Center of Excellence）として、パブリッククラウドコスト最適化推進やクラウド共通基盤としてドコモグループへ提供している複数のSaaS製品の管理運用、docomo R&D OPEN LAB ODAIBAという施設の企画運用を行っている奥田です！ 今回はパブリッククラウドコスト最適化をさらに推し進めるための知見を得るべく、re:Inventへ参加してきました。
DEV318 | Optimize AWS Costs: Developer Tools and Techniques
「金曜日の朝、平穏な週末を迎えるはずが『予算超過アラート』のメールでパニックになる…」 そんな経験はありませんか？ から始まるこのセッションでは、Betsson社のコスト最適化事例、AIの活用、将来の無駄の防ぎ方が解説されました。特にBetsson社のコスト最適化事例は基本的な部分から高度な部分までとても参考になったので、そこにフォーカスして紹介します。セッション動画はこちらで公開されているので、興味のある方は是非ご覧ください。
「基本的な」コスト最適化
知っていればすぐにできるけど、放置しているとチリツモでコストが肥大化する原因になり得るポイントについて解説がありました。
- Trails：CloudTrailの1つ目の証跡は無料だが、2つ目以降は有料。今回の事例では組織の証跡を利用し、各アカウントに存在する不要な証跡を削除
- Volumes：アタッチされていないEBSボリュームを削除。コンプライアンス上、必要なものはスナップショットを取得した上で削除
- Network：Elastic IPとElastic Load Balancerの両方でコストが発生する場合がある。不要なものは削除
- Rightsizing：リソースの適切なサイズ設定
- Storage：S3内の不要なデータを削除。必要なデータはGlacierに移行Intelligent-Tieringも活用
- Graviton：EC2だけでなく、様々なサービスでGravitonを利用
- Database：PostgreSQL、MySQL、MariaDBをIntelベースからGravitonベースのインスタンスに移行
「高度な」コスト最適化
- CloudWatch：不要なロググループの削除、有効期限なしのロググループを作成しない。Infrequent Accessの活用
- Config：EKSは負荷に応じてオートスケーリングする。Configの設定が継続的になっている場合スケーリングのたびにイベントが記録される。Configの設定を日次に変更
- Data Transfer：AZ間のトラフィックを減らす。プライベートサブネットからS3へのアクセスにはNAT Gatewayを使わず、無料のS3 Gateway Endpointを使う。
- Lambda：Gravitonへ移行。コードを最適化することで実行時間を減らす。
- NAT Gateway：外向き通信専用のVPC（Engress VPC）を作成し、Transit Gatewayで集約。小規模では割高になることもあるが、10個以上VPCがある場合はTransit Gatewayで集約した方がコストメリットが出やすい。
- WAF：標準機能で大半をブロックし、Bot Controlなどのプレミアム機能へのヒット数を減らす。CAPTCHA（パズル）は高いので、安価なChallenge（サイレント認証）を優先。
- DMS：データ転送を行う際に直接転送するよりも利用料が安価なリージョンをうまく使うと良い。DMSはインスタンスをバージニア北部に置いただけで大幅なコスト削減になった。
今回紹介されたコスト最適化事例はすぐに取り組むことができるものもあり、とても有用だなと感じました。自身で利用しているアカウントに関しても一度、上記項目に則って問題ない状態か確認することをおすすめします。ドコモのCCoEとしてコスト最適化を推進している中で、コストはチリツモだなと思っています。少しだから...と無駄なコストを放っておいて、気付いたら手がつけられない状態になってしまった、ということもあります。チリツモなので、日々少しずつ意識して片付ける必要があります。改めて今回得たTipsを生かし、コスト最適化をさらに推進していければと思いました。また、今回は詳しく触れませんでしたがセッションの中でKiro CLIなどの生成AIの活用についても語られていたので、これらのノウハウを生かしつつ、生成AIも活用することでさらにコスト最適化を推進していけるよう精進したいです。
ARC308-R1 | Rapid prototyping with Kiro CLI
生成AIによるコーディングが当たり前になる中、「爆速でコードは書けるが、間違ったものを爆速で作ってしまう」という課題にどう向き合うか。このワークショップでは、AWSのPrototyping & Cloud Engineering（PACE）チームが実践している、「Kiro CLI」を用いたSpec-Driven Development（仕様駆動開発）のアプローチが解説されました。とても実践的で今後の開発で参考になる部分の多いワークショップだったのでご紹介します。
セッションの冒頭では「人間の意図（Human Intent）」の重要性が強調されていました。
爆速でコードが書ける一方で、1つの悪い意図（Bad Intent）を与えると、AIは何千行もの「機能はするが、使い物にならないコード」を生成してしまいます。
Amazon CTOのWerner Vogels氏がTech predictions for 2026 and beyondで書かれていた「Generative AI lets us generate code in seconds, but if you put garbage in, you get really convincing garbage out.」が引用され、改めてAIに指示を出す前の「構造化された意図」の重要性が説かれました。
これを解決するのがSpec-Driven Development（仕様駆動開発）です。AIに「何を作るか」を決めさせるのではなく、人間が戦略的なフォーマットで意図を明確にし、それをコンテキストとしてAIに与えるアプローチです。
このアプローチを実装するためのフレームワークとしてAI-DLC（AI-Driven Development Lifecycle）が紹介されました。
AIは単に支援するだけでなくワークフロー全体（計画、仕様作成、アーキテクチャ提案、コード生成）をオーケストレーションする存在で、人間は検証、レビュー、独自のコンテキスト提供を行う「責任者」であり続けることです。
このワークショップで使用するツールとしてKiro CLIが紹介されました。ご存じの方、使ったことのある方も多いと思いますが、ターミナルベースのAIコーディングエージェントです。今回のワークショップでは1つだけのエージェントを使用するのではなく、それぞれ役割を持った5つのカスタムエージェントを作成しました。
- Product Owner：要件定義、ユーザーストーリーの作成。
- Domain Modeler：ビジネスルール、エンティティ、リレーションシップを定義。
- Technical Architect：システム設計、AWSサービスへのマッピング、APIスキーマの作成。
- Full Stack Engineer：フロントエンド、バックエンド、IaC（Infrastructure as a Code）のコード生成。
- Deployment Engineer：デプロイ、エンドポイントの検証、フロントエンドの動作確認。
各エージェントは前のエージェントの出力を入力として受け取り、開発を進めていきます。その中で人間はQuality Gateとして、各ステップごとに検証、レビューを行い、必要に応じて修正させます。
今回のお題として貯金箱Webアプリを作りましたが、ログイン画面からうまくログインできず困っているところで時間切れになってしまいました...。私の責任者としての検証、レビュー不足です...。
生成AIでコーディングが簡単にできるようになった今、これまで以上に人間の意図と何を作るのかが重要になっていると感じました。また、生成AIから思っていたような返答が得られないと感じる時がありますが、それは私が生成AIに構造化した意図を適切に伝えられていないだけだったんだなと改めて思いました。なんとなく生成AIに投げるだけでそれっぽくなってしまう世の中なので、これまで以上に意識してgarbageのようなコードを作らないようにしていこうと思います。
自己紹介②（千葉）
ドコモで提供するコンシューマー向けサービスの開発部門で、AWSを活用したインフラストラクチャーの開発や保守運用を実施している千葉です。最近は主にコスト最適化やアーキテクチャ改善、セキュリティ検討などを実施しており、この知見を深めるべく今回AWS re:Inventに参加しました。通算2回目の参加であり、今回はワークショップセッションに積極的に参加してきたため、印象的だったものを2件ご紹介します。
MAM306-R | Application modernization challenge
サーバアプリケーションのモダナイゼーションに関する10個の課題をチームで協力して解決していき、解決に応じて与えられるスコアをチーム単位で競うという内容のワークショップです。（AWS GameDayに近いかもしれません）
まずは冒頭にアプリケーションのモダナイズがなぜ必要とされるのか？という解説が行われました。その理由は、市場投入までの期間を48%削減し、技術的負債を50%削減、さらにセキュリティも強化できるため必要なのだとのことでした。
冒頭の解説が終わるとチーム作業が開始となります。ここで(個人的に)課題となってくるのは言語の壁ですが、基本的にAWSマネジメントコンソールを操作しながら課題を解決していくので、画面を見せながらコミュニケーションを取ることで、なんとなくチーム同士で指差しながら役割分担や進捗等のコミュニケーションを取ることができましたが、分担しながら約100分程度で10個の課題を解決しなければならないため、だいぶタイトな内容でした。
課題はjavaバージョンのアップグレードやコンテナ化等のよくあるトピックだけでなく、生成AIやマルチエージェントといった近年のトピックも織り込まれており幅広い知識が求められる内容です。
結果、「DBをマイグレーションせよ」や「CI/CD環境を構築せよ」といった課題を3件ほど解決できましたが、三十数チーム居る中で17位となんともいえない順位でした。
このワークショップに参加してみて、業務上考える機会の多い内容ではあるものの、実際は手を動かすことができていない箇所についても自分の論理に基づいて対応し正解できたため、自身のスキルにもちょっとだけ自信をつけることができました。また、最初は現地の方とのコミュニケーションに不安を感じていましたが、AWSという共通言語に基づいて意思疎通をしながら進めることができたため、こちらに関してもほんのちょっとだけ自信をつけることができました。自分の理解力を試すうえでは非常にオススメのワークショップです。
DVT317 | The Kiro coding challenge
コーディングエージェント「Kiro」に関するセッションで、設問を解きながらVibe Codingでアプリケーションを開発する過程を学びつつスコアを競っていきましょうという、個人種目ですがこちらも競技性のあるワークショップです。「Kiro」にプロンプトを投入しながら開発環境の構築・設定変更とコーディングをしてもらうという内容で、前述のセッションを乗り越えちょっと調子に乗った状態で参加しました。
まず冒頭の解説ですが、AI駆動開発における課題は「小さなタスクには有効だが複雑なプロジェクトには不向き」「既存ツールとの連携や管理が困難」「生成されるコードの品質管理が困難」といったものがありました。自然言語からプログラムを生成することから大規模かつ高品質のプログラムを開発していくことには課題がありました。
それらの解決策として、仕様駆動開発という新しいAIコーディングの考え方が最近では主流になってきています。まず最初に仕様書を定義してその仕様に基づいてコーディングをするというもので、一周回ってこれまでの開発方式に戻ってきたようなものです。ただ大きな違いとして、コーディング方法がVibe Codingであるという点があります。仕様書を通じて自然言語で対話をしながらAIコーディングを実施することで高品質なプログラム開発を実現する、という思想です。
このワークショップでは仕様駆動開発を実施する手段として、AWSが提供する「Kiro」を活用しながら、出題される課題を解決していくという内容なのですが、言語の違い（日本語で対話しているがヒントのプロンプトは英語）など様々な面で翻弄され設定作業やコーディングをろくに進めることができず、最終的な順位は百中数人中78位というこれまた残念な結果でした。
コーディングエージェントやVibe Codingは今年に入ってからさらに急激に進化を遂げていることを体感でき、課題解決はうまくいかなかったもののそのポテンシャルの高さには驚くばかりでした。今後のシステム開発においてはこのスキルをモノにしていくことがきわめて重要なのだということを体感することができ、こちらもまたオススメのワークショップでした。機会があったら再チャレンジしたいですね！
他にもDDoS対策のためのセキュリティ強化や「Kiro」に関するワークショップに参加してきましたが、全体を通して本年のre:Invent2025を振り返ってみると、今年も生成AIやAIエージェントに関連するトピックが多く、EC2インスタンスやネットワークの進化などに関するセッションにおいても、「AIに利用するために」という観点で語られることが非常に多かった印象があります。個人的にはkeynoteで新たに発表された「Kiro Autonomous Agent」「AWS Security Agent」「AWS DevOps Agent」に関しては出来ることの幅を広げることができそうで楽しみなのですが、今年も非常にワクワクする5日間だったと思います。
自己紹介③（岡戸）
ドコモが提供するサービスの開発部⾨で、開発・保守運⽤に従事している岡⼾です。主にサービス⽴ち上げ時の内製開発やアーキテクチャの改善、作成した環境の保守運⽤を担当しており、これらの業務のなかでAWSを活⽤しています。今回は「保守運⽤における負担を軽減する⽅法はないか」「既存のアプリケーションにGenAIエージェントを組み込む⽅法はあるか」という観点を中⼼に知⾒を得るべく、re:Inventへ参加してきました。
COP403-R1 | Automate cloud operations with AI agents [REPEAT]
このワークショップは、障害発生時の「手動対応」「対応品質の属人化」などを課題と捉え、Amazon Bedrock AgentCoreやAmazon CloudWatch Investigationsを利用して、障害発生時のトラブルシューティング機能を作成・利用するワークショップです。
ワークショップの流れは以下の通りです。
- Amazon Bedrock AgentCoreを利用した、ユーザとのチャットによりトラブルシューティング（原因究明と対処）をするトラブルシューティングエージェントの作成
- AWS Lambdaで呼び出しをおこなうツール（例：VPC Reachability Analyzer）を利用するトラブルシューティングエージェントの作成
- Long term memoryによる過去のセッションの記憶と、Short term memoryによる会話の履歴を活用したパーソナライズ機能の追加
- トラブルシューティングエージェントをオーケストレーションエージェントとした、専門家エージェント呼び出し（=A2A）機能の追加
- Amazon CloudWatch Investigationsによる、テレメトリデータ（例：Amazon CloudWatch logsに集積されたログ）を元にしたトラブルシューティングおよびレポート作成
※ オーケストレーションエージェント：他のエージェントへの出力指示や他ツールを利用し、それらの出力結果を統合することで、ツールの目的を果たすエージェント。
上記のいずれのトラブルシューティングにおいても、以下のプロセスを経て原因解消のテストをしています。
- 意図的な障害を発生させる（例：Security Groupのデータベース接続に必要なインバウンドルールを削除）
- トラブルシューティングエージェントまたはAmazon CloudWatch Investigationsが、それぞれの方法で原因を解析
- トラブルシューティングエージェントまたはAmazon CloudWatch Investigationsが解析した原因をユーザに示し、提案する解決方法を実行して良いか尋ねる
- ユーザからの許可がでれば、トラブルシューティングエージェントまたはAmazon CloudWatch InvestigationsがAWSリソースを操作して解決
2つの方法の違いとしては、障害原因の調査のための参照先が違うと、私は解釈をしています。
- トラブルシューティングエージェントは、カスタマイズされた任意のツール（他エージェントを含む）を利用
- Amazon CloudWatch Investigationsは、テレメトリデータを利用
トラブルシューティングエージェントの場合も、テレメトリデータを参照できるツールを提供すれば、Amazon CloudWatch Investigationsと同様の情報を参照した出力が可能でしょう。 また、いずれの手法でも正確な出力を得るには十分な情報量が不可欠ですが、特にエージェントが利用可能なツールを増やすことは、精度の向上に直結しそうです。ただし、その場合トラブルシューティングエージェントは、他エージェントやツールの利用コストのことは度外視で利用してしまうと考えられるため、最終的なランニングコストを試算することは難しそうです。「一定値以上のコストを利用しない」という条件づけもできそうですが、それではエージェントの自律性という良さが活かしきれないと考えられます。そのため、コストを制限するのではなく、エージェントに渡すツール自体を厳選・最適化する方向で調整した方が良いと思いました。
Amazon CloudWatch Investigationsは、コンプライアンス要件に応じてデータの参照範囲や利用の可否を検討する必要はありますが、すぐに利用できそうで便利なツールだと感じました。アラートをトリガーとすることもできるようなので、利用コストについては調べる必要がありますが、積極的に導入したいと感じます。
一方で、トラブルシューティングエージェントを導入するためには、私のAmazon Bedrock AgentCoreに関する知識が不足しており、実務レベルのエージェントを素早く導入することは難しいと感じました。このワークショップ以外でも多くのアプリケーションとエージェントの統合において、Amazon Bedrock AgentCoreが利用されていたため、Amazon Bedrock AgentCoreを学習しようというモチベーションを得ることができました。
また、いずれの方法においても障害対応の最終的な判断を人間がしていることから、「責任をだれが取るか」という観点で、最終的に人間が承認する必要がある点は納得できるものの、エンジニアとしては「なんとかそこまで自動化できないものか」と考えさせられる部分でした。
NTA302-R1 | IAM Analytics: Automate & Visualize
このワークショップは、AWS環境の拡大により増えていく、各リソースの「付与された権限」と「本来必要な権限」の差分、そしてそれらを把握する手間を課題と捉え、AWS CloudTrail LakeやAmazon Bedrock、Amazon Quick Suiteを利用して、過剰な権限の検知と可視化を自動でおこなうシステムを構築するワークショップです。
ワークショップでは、以下の方法によりIAMの過剰権限の検知と可視化をするシステムを作成しました。
- 現在使われている権限を把握するためのイベントを、AWS CloudTrailからAWS CloudTrail Lakeに取り込む
- 任意のタイミングでAmazon EventBridgeがAWS Lambdaを実行し、AWS CloudTrail Lakeにクエリをかけて、実行されたアクションを取得
- AWS Lambdaが検査対象のリソースに付与されている権限のリストを取得
- 2,3のデータとAmazon Bedrockを利用して、付与された権限と使用された権限を比較し、脅威スコアを生成
- 4の結果をAmazon DynamoDBに格納 & 脅威スコアの高いものはSESで通知
- DynamoDBのデータをAmazon Quick Suiteで可視化
開発をする中で、「とりあえず過剰な権限をつけておく」というのはやりがちな方法であるため、このワークショップのシステムを開発段階から導入することで、商用環境に同環境を構築する際の権限の適正化が容易におこなえるようになると考えられ、導入価値があると感じました。一方で、導入においては以下3点を考慮する必要があるとも感じました。
- 開発環境において、このシステムが提案する権限削除を受け入れるかどうか
- AWS CloudTrail Lakeの利用料金を、チームが受け入れることができるか
- Amazon Quick Suiteの要否
1点目については、開発スピードの観点です。多くの開発環境で「過剰な権限」が発生している背景には、IAMによって可能な操作が制限されることによる、「開発スピードの低下」があると考えています。そのため、以下のような段階的な導入が必要となるかもしれません。
- システムの初期開発：あくまで商用環境に開発対象のシステムを移す際の過剰権限を避ける目的で利用。開発環境では、このシステムの提案を受け付けない。
- システムの成熟後：開発環境でも、このシステムの提案を受け入れる。
2点目については、セキュリティのために必要な料金であることを考えれば、受け入れるべきものであるとは思いつつも、現実問題としてシステムやチームの規模によっては、「手動対応」に任せた方が良いこともあるかもしれないと感じました。
AWS CloudTrail Lakeは、データの取り込み・保存に加え、クエリ実行時にスキャンされたデータ量にも応じて料金が変動します。イベントを適切に取り込まなければ正しく「必要な権限」を把握することはできませんが、取り込みすぎればその分余計な料金が発生します。同様に、クエリを実行する際には、スキャンするデータ量が可能な限り少なくなるようにしなければ、本来必要な料金よりも多くの料金が発生してしまいそうです。実際に利用する際には、AWS CloudTrail Lakeに取り込むイベントや、クエリの実行方法について、正しく設計しなければならないと感じました。
3点目は、個人的に「やりたいのは可視化ではない」と感じたため、考慮するべき点としてあげました。私としては、可視化をするのではなく自動で是正をしてほしいと感じてしまいます。
「COP403-R1 Automate cloud operations with AI agents」では、Amazon Bedrock AgentCoreを利用して、障害発生時に「人間が許可をだせば、自動で解決してくれる」状態にしていました。AWS Lambdaが呼び出す先をAmazon Bedrock AgentCoreで構築したエージェントにすれば、同様のことができるのではないかと考えているため、自身が導入する際にはこの方法を検討したいと思いました。
ただし、その場合エージェントがIAMを操作する権限を手に入れることになるため、これを良しとするかどうかは、十分に議論する必要があると考えます。
自己紹介④（宮本）
ドコモのR&D部門で、システムの研究開発を実施している宮本です。最近はAIエージェントに携わり、社内資料検索機能の開発を担当しました。社内展開へ向けたAWSのエコシステムについて知見を深めるとともに、最新動向を肌に感じるため、AWS re:Inventに参加してきました。
AIM-428 | Building intelligent multimodal applications with Amazon Nova 2.0
Amazon Nova 2 Omniによるマルチモーダル性能の実践ワークショップに参加してきました。
Nova 2 シリーズとして4つのモデルを発表しています。
- Amazon Nova 2：全モデルで100万トークンのコンテキストウィンドウを備えたモデルシリーズ。
- Nova 2 Lite：高速かつ低コストな、推論モデル
- 主な用途：チャットボット、コード生成、日常的なAIタスク
- Nova 2 Pro：複雑なユースケースに対応した、シリーズ最高性能なマルチモーダルモデル。
- 主な用途：エージェント型コーディング、複雑なAIタスク
- Nova 2 Omni（本ワークショップの主役）：業界初のテキスト、画像、動画、音声入力を処理しながらテキストと画像の両方を生成できる統合型マルチモーダル推論・生成モデル
- 主な用途：画像生成、マルチモーダル理解
- Nova 2 Sonic：音声対話に特化した、会話型AIのためのモデル
- 主な用途：カスタマーサポート、音声対話パーソナルアシスタント
ワークショップは下記のタスクを行い、Nova 2 Omniの性能を体験するものです。
Lab 1. Text & Image Generation：文字数制御やJSON出力を含むテキスト生成と、高品質な画像生成を行う。
Lab 2. Image Editing：画像の高度な操作やスタイル変換、自動編集ワークフローを実装する。
Lab 3. Meeting Workshop：会議の文字起こし、分析、要約、アクションアイテムの抽出を行う。
Lab 4. Video Understanding：動画コンテンツの分析、シーン検出、内容理解を行う。
Lab 5. System Tools：モデルが外部ツールやシステム機能を活用する仕組みを学ぶ。
Lab 6. Multimodal RAG：テキストや画像を対象としたマルチモーダルな検索拡張生成システムを構築する。
Lab 7. Smart Real Estate Assistant：Strandsフレームワークを用いた不動産特化型のマルチエージェントシステムを開発する。
実行環境はAmazon SageMaker AI Studioによる、JupyterLabを利用しました。内容についてはGitHubにて公開されていますので、こちらもご参照ください。
ワークショップのタスクを通じて、Nova 2 Omniを体験しましたが、大きく性能が劣るシーンは感じず、オールインワンモデルの便利さを実感しました。特に、各タスクにおいてモデルを置き換える必要がない、という点がかなり便利であり、プレビュー版から、GA(General Availability)された際には、各種特化モデルとの比較を実施してみたいと思います。
おまけに、Lab 5にて、Webグラウンディングの機能がありましたので、ソースを編集し、日本語でAWS re:Invent 2025の紹介をいただきました。（12/2時点での実施結果のため、情報の誤差はあります。)
AWS re:Invent 2025は、Amazon Web Services（AWS）が毎年開催するグローバルクラウドコンピューティングカンファレンスで、**2025年12月1日から5日まで**、ラスベガスのシーザーズフォーラム、ザ・ベネチアン、マンダレイベイ、MGMグランドなどの会場で開催されます[1][2][3][4]。このイベントでは、AI、サステナビリティ、インフラストラクチャの進歩を含むクラウドイノベーションに焦点を当てた基調講演、分科会、ワークショップ、ネットワーキングの機会が提供されます[5][6][7]。 ### 主なハイライト: 1. **基調講演とテーマ**: - **オープニング基調講演（12月2日）**：AWS CEOのマット・ガーマン氏は、**Amazon Nova 2**（推論およびマルチモーダルモデル）とスケーラブルなAIトレーニングのための**EC2 Trn3 UltraServers**を含む主要なアップデートを発表しました[8][9]。 - **Agentic AI基調講演（12月3日）**：Agentic AI担当副社長のSwami Sivasubramanian氏が、AWS上で安全なAIエージェントを構築するためのフレームワークについて詳しく説明しました[10][11]。 - **インフラストラクチャ基調講演（12月4日）**：サービスイノベーション、持続可能性イニシアチブ、グローバルインフラストラクチャの拡張に焦点を当てました[12][13]。 （中略） このイベントでは、遠隔地の参加者向けに基調講演のライブストリーミングも提供されており、世界的なアクセスが確保されています[22]。 --- **出典:** - **[1]** [awsevents.com]( https://reinvent.awsevents.com/agenda ) - **[2、5、12]** [cbtnuggets.com]( https://www.cbtnuggets.com/blog/career/getting-experience/aws-re-invent-what-you-should-know ) - **[3, 20]** [spacelift.io]( https://spacelift.io/blog/aws-reinvent-guide ) - **[4]** [b2brain.com]( https://www.b2brain.com/tradeshows/aws-reinvent-2025 ) - **[6、7、13、19、21]** [gadgetsfarms.com]( https://www.gadgetsfarms.com/aws-reinvent-2025-cloud-innovations-and-networking-opportunities/ ) - **[8、11、14]** [pluralsight.com]( https://www.pluralsight.com/resources/blog/cloud/aws-reinvent-2025-day-one ) - **[9, 16]** [aboutamazon.com]( https://www.aboutamazon.com/news/aws/aws-re-invent-2025-ai-news-updates ) - **[10]** [cxtoday.com]( https://www.cxtoday.com/contact-center/aws-reinvent-2025-event-guide/ ) - **[22]** [thenasguy.com]( https://www.thenasguy.com/2025/11/24/aws-weekly-roundup-how-to-join-aws-reinvent-2025-plus-kiro-ga-and-lots-of-launches-nov-24-2025/ )
DVT-403 | Create your own AI sidekick: a hands-on agent building workshop
Kiroを用いたバイブコーディングによるマルチエージェント構築のワークショップに参加してきました。
Kiroとは、AWSが開発した、次世代の「AIネイティブ・統合開発環境（IDE）」です。仕様駆動開発を搭載しており、AIがまず「要件定義書」「設計書」「タスクリスト」を作成し、人間がそれを承認してから実装を始めることで、手戻りを少なくする開発仕様です。
ワークショップではStrands Agentsをもちいたエージェント構築をAgentic AI IDEである、Kiroを用いた構築により、Strands AgentsとKiroの実践的な利用をします。
ワークショップの流れは下記です。
Part 1：最初の会話型AIエージェントを作成する
Part 2：アクションを実行できるエージェントを作成するために、ツールを追加する
Part 3：ビジネスシナリオに基づき動作するマルチエージェントシステムの作成
Part 4：Kiroを使用して、独自のマルチエージェントシステムの仕様を構築する
ワークショップにて、Kiroの助けを借りつつ、マルチエージェントシステムの作成まで実施してきました。Strands Agentsとは何かを聞いたり、IDEで実行した結果発生したエラー内容を分析してもらったり、仕様駆動のためのplanningを実施してもらったりと様々な対応をKiroに任せてみました。
requirementsやdesign、planningを作成したのちに、ソースコードの作成に取り掛かるため、ソースコードが長くなったことでエラーとなった場合においても、即座にリトライされる様子がかなり面白かったです。 利用者はシステムアーキテクチャとして、Kiroの成果物に対して、修正依頼を出したり、Goを出す役割として存在しており、開発についてはほぼほぼKiro任せな状況でした。 一方、Part 1の実践中に、AWS認証情報の不足エラーが起きた際には、会場全てのKiroが解決できずにいるなど、完璧ではない様子も見られ、まだ人間は必要…！と思っていました。
最後に
4名とも5日間のre:Invent参加を経て、それぞれの専門領域やそれ以外の領域についてもこれまで以上に深く学ぶことができました。また、セッションやハンズオンで学んだことも有意義でしたが、現地では多数のネットワーキングイベントが開催されており、そこでたくさんの方とお話しできたこともとても刺激になりました。現地でお話しした方、ありがとうございました！ またお会いしましょう！ 最後まで読んでいただきありがとうございました！
