はじめに
2026年7月3日、Ragateの社内LT会（Lightning Talk）が開催されました。
今回の中心テーマは、AWS Summitで得た知見。
会場で実際に聞いたセッション、企業ブースで得た気づき、AWS社員から直接聞いたベストプラクティス、そして今後の活かせる視点まで、全10本のセッションを通じて、各メンバーの学びが持ち寄られました。
AIエージェント、コスト最適化、セキュリティ、サステナビリティ、サーバーレスの新しい形など、どの発表も「明日からどう使うか」まで踏み込んだ内容でした。
Talk 1: AWS Summit初日参加レポートとAIモブワーク
最初のセッションは、AWS Summit初日のリアルな参加レポートから始まりました。
特に印象的だったのは、初日の混雑です。2日目と比べても入場待ちが長く、1時間半以上並ぶほどの状況だったとのこと。初日に参加する場合は、早めの移動と余裕のあるスケジュールが必要だと感じられる共有でした。
一方で、基調講演に間に合わない場合でも、AWSイベントアプリを利用すればライブ配信を視聴できます。アプリはセッション予約や当日の案内確認にも便利で、人気セッションは事前予約が推奨されます。見逃したセッションも、後日オンデマンド配信で視聴可能です。
後半では、上流工程のコミュニケーションに関する「AIモブワーク」が紹介されました。企画、法務、開発者など関係者が一堂に集まり、AIの出力をリアルタイムで見ながら、その場で承認や意思決定を進めていく手法です。
実践する際は、数時間の会議や開発合宿のように、まとまった時間を確保して集中して進めることが推奨されていました。紹介されていた事例では、作業速度が見積もりの約3倍に向上し、満足度も54.8%と成果が示されていました。
上流工程では、関係者がばらばらに確認するよりも、AIを囲んで一気に決める方が効果的な場面があります。マルチタスクによるコンテキストスイッチが集中力を下げるという観点からも、重要な意思決定者が同じ時間に集まる意味を感じるセッションでした。
Talk 2: Continuumで進むセキュリティ修復とDevOps支援
次のセッションでは、AWS Summit NYで発表された新サービス「Continuum」と、DevOpsエージェントによる運用支援が共有されました。
Continuumは、AIがセキュリティの脆弱性を見つけるサービスです。現在は限定プレビュー段階とされており、脆弱性の発見、優先順位付け、検証、そして修復までを自動化・支援する仕組みとして紹介されました。
従来、セキュリティ領域では誤検知によるシステム停止を避けるため、検知後の修復までは人が慎重に判断する必要がありました。Continuumでは、サンドボックスなどの切り離された環境で実際に攻撃を再現・検証し、問題が正しいと確認できた場合のみ自動修復へ進む考え方が採用されています。
いきなりすべてを全自動で直すのではなく、人間が判断・承認したものを学習しながら、段階的に自動対応の範囲を広げていく点も特徴です。将来的には、既存のセキュリティ関連サービスとも共存しながら統合されていく予定とのことでした。
あわせて、DevOpsエージェントによる運用支援も紹介されました。アラート発報後のログ調査から修正案の提示までを一括で支援するため、人間は最終的な実行やチェックに集中しやすくなります。
紹介されていた事例では、対応時間が2時間から28分に短縮された実績もありました。運用で大変なのは、原因調査だけではなく、短時間で状況を把握し、報告し、復旧まで進めることです。AIエージェントは、その初動を大きく変える可能性があると感じられる発表でした。
Talk 3: AI導入提案で大切なコストとセキュリティの視点
続く発表では、AI導入提案における反省と気づきが共有されました。
AI活用への関心は高まっていますが、提案の場では「どのモデルを使うか」よりも先に、「どれくらい費用がかかるのか」「セキュリティはどう守るのか」を示すことが重要です。
特に、用途別のコスト試算や、閉域網・プライベートネットワークでの利用を前提とした構成を、早い段階で提示しておくべきだったという振り返りがありました。モデル選定の話に入る前に、利用コストとセキュリティの前提を整理することが、AI導入提案では欠かせません。
また、今後深掘りしたいテーマとして、FinOpsも挙げられました。AWS Budgetsのような予算管理にAIを組み合わせ、コスト監視を補助していく仕組みは、AI導入後の運用にもつながる重要な観点です。
AI導入を前向きに進めるには、技術の魅力だけでは足りません。お客様が不安に感じるポイントを先回りして解消することが、提案の第一歩になるという学びがありました。
Talk 4: マルチクラウド接続の新しい選択肢
次のセッションでは、AWSと他クラウドを接続するネットワークサービスが取り上げられました。
これまでクラウド同士を接続する場合、Site-to-Site VPNなどを個別に設計・設定する必要がありました。構成が複雑になりやすく、拡張性や運用管理の面でも課題が出やすい領域です。
今回紹介された仕組みでは、マネージドな形でクラウド間を接続できるため、ネットワーク設計やアクセス設定をよりシンプルにできます。現在はGCPのみ利用可能ですが、今後はAzureやOracleへの対応プレビューも予定されています。500Mbpsベースの枠などの話もあり、今後のマルチクラウド構成で重要な選択肢になりそうです。
マルチクラウド構成は、今後さらに扱う機会が増えていくと考えられます。VPCピアリングの代わりになる選択肢としても期待でき、クラウド間接続を個別に作り込むのではなく、マネージドサービスとして扱えるようになることで、設計の選択肢が広がる内容でした。
- 関連資料：Talk4 LT会資料.pdf
Talk 5: セキュリティエージェントとDevOpsエージェントの使い分け
続いて、セキュリティエージェントとDevOpsエージェントを、開発ライフサイクルの中でどう使い分けるかが共有されました。
Talk 2が「新サービスと自動修復の考え方」に焦点を当てた内容だったのに対し、この発表では、より実務に近い使い分けが整理されました。
設計・開発中、つまりデプロイ前の段階では、セキュリティエージェントを活用します。設計レビュー、脅威モデリング、コードレビュー、脆弱性検証などを通じて、リリース前にリスクを洗い出す役割です。
一方で、リリース後の本番運用では、DevOpsエージェントを活用します。インシデント調査、リリース準備レビュー、運用リスクの確認、外部ツールとの連携などを通じて、安定運用を支援します。
紹介されていた事例では、対応時間が2時間から28分へ短縮されるなど、77%前後の改善が示されていました。ほかにも、複数の事例で60%台以上の改善が見られたとのことです。
ポイントは、両者を競合するものとして見るのではなく、フェーズごとに役割を分けて使うことです。AIに任せられる範囲が広がっても、最終的な評価や判断は人間が行う。AIに任せる部分と、人が責任を持つ部分を切り分けることが、実務導入では重要になりそうです。
- 関連資料：Talk5 LT会資料.pdf
Talk 6: Agents for Amazon BedrockとSageMakerの進化
次のセッションでは、Agents for Amazon BedrockとSageMakerの進化が紹介されました。
中心となったのは、エージェントコアハーネスです。これは、AIモデルがツールを選択し、実行し、結果を確認する「エージェントループ」を簡単に構築できる機能です。
インフラ管理やランタイムコードを自分で書かなくても、モデル、システムプロンプト、利用するツールをGUI上で定義するだけで、エージェントとして動作する仕組みを作れる点が特徴です。
従来であれば、エージェントの実行基盤やランタイムを自分たちで実装する必要がありました。しかし、まずはハーネスを使って簡単に構築し、要件を満たせない場合にランタイムを自分で書くという進め方が推奨されています。
ガードレール機能も強化されています。アカウントレベルでガードレールを設定できるようになり、プロキシを挟むような構成を取らなくても、生成AI利用時の安全対策を組み込みやすくなりました。
SageMakerについても、機械学習やファインチューニングだけでなく、ETL処理などさまざまな機能が統合され、より広範なAI・データ基盤として進化していることが共有されました。
エージェントを作るハードルは下がりつつあります。だからこそ、どこまで標準機能で作り、どこから自分たちで作り込むのかを見極める力が重要になりそうです。
Talk 7: AWS Cost Anomaly Detectionで異常課金を防ぐ
次のセッションでは、AWS Cost Anomaly Detectionによるコスト異常検出が取り上げられました。
AWS Budgetsは、設定した予算に近づいたタイミングで段階的にアラートを出す機能です。一方、Cost Anomaly Detectionは、通常の利用傾向から外れた異常なコスト増加を検知するための機能です。
たとえば、不要なリソースの消し忘れ、想定外の通信量増加、ヘルスチェックのループなどにより、気づかないうちに費用が増え続けるケースがあります。こうした異常を早期に検知できれば、大きなコスト被害を防ぐことにつながります。
コスト異常検出は、単なる費用管理ではありません。セキュリティや運用品質にも関わる重要な仕組みです。想定外のアクセス増加などによる課金増加を把握する観点でも有効です。
AWS環境を安全に運用するには、予算設定だけでなく、通常利用から外れた変化を検知する仕組みも必要です。「設定しておくべき」ではなく、「設定していないと危ない」と感じられる発表でした。
Talk 8: Lambda MicroVMsが示すサーバーレスの新しい形
次の発表は、「サーバーレスが“記憶”を持った日」という印象的なテーマでした。
これまでのサーバーレスは、呼び出されるたびに起動し、処理が終わると破棄されるステートレスな仕組みでした。そのため、状態を保持したい場合は、外部データベースなどに都度保存する必要がありました。
Lambda MicroVMsでは、MicroVMを起動したまま一定時間保持し、同じVMを指定して呼び出すことができます。スナップショットから復元することで、毎回ブートや初期化をやり直すのではなく、初期化済みの状態から素早く再開できる点が特徴です。
ユースケースとしては、生成AIが作成したコードを安全に実行するサンドボックス、対話型AIアシスタントの状態保持、顧客データを扱う分析処理などが挙げられます。軽量なローカルLLMをMicroVM内で動かし、重い生成処理だけを外部の大規模モデルに任せる構成も考えられます。
一方で、コストは使い方によって大きく変わります。アイドル時間が長く、実働時間が短い用途では安く使える可能性がありますが、長時間高負荷で動き続ける用途では別の実行基盤の方が適している場合があります。
「サーバーレスは記憶を持てない」という前提が変わると、AIエージェントの実行基盤も変わります。状態保持、隔離、コストのバランスをどう取るかが、今後の設計ポイントになりそうです。
- 関連資料：Talk8 LT会資料.pdf
Talk 9: NovaForgeで独自データに基づくモデルを構築する
次のセッションでは、NovaForgeによるモデル構築が取り上げられました。
生成AI活用では、RAGによって社内ナレッジや外部データを参照させる方法がよく使われます。しかし、専門知識や独自データをより深くモデルに反映したい場合、RAGだけでは十分でないケースもあります。
一方で、ゼロからモデルを構築するには、時間、コスト、専門性の壁があります。NovaForgeは、未学習、事前学習済み、中間学習済みなど、さまざまな段階のチェックポイントから学習を再開できる点が特徴です。
これにより、汎用的な能力を維持しながら、特定領域の専門性を高めたモデル構築を進めやすくなります。また、学習レシピも用意されているため、モデル構築のハードルを下げられる可能性があります。
RAGで外部知識を参照させるのか、モデル自体に専門性を持たせるのか。AI提案では、この選択肢を持てることが重要です。専門領域や独自データが重要な業務に対して、より踏み込んだ提案につながる内容でした。
- 関連資料：Talk9 LT会資料.pdf
Talk 10: サステナビリティはAWS提案の話だった
最後のセッションでは、サステナビリティとAWS提案の関係が共有されました。
サステナビリティ、ESG、Scope 1・2・3といった言葉は、環境部門だけのテーマに見えるかもしれません。しかし実際には、投資家、行政、取引先、社員など、さまざまな関係者に対して説明責任が求められるテーマです。
企業開示の流れも変化しており、今後は対象企業を中心に、温室効果ガス排出量やサプライチェーンを含めた情報開示への対応が求められていきます。直接の対象外であっても、取引先からクラウド利用に伴う排出量や改善状況について説明を求められる可能性があります。
AWSでは、データセンターの効率化や水資源への取り組み、カーボンフットプリントの可視化など、環境負荷低減に関する取り組みが進められています。オンプレミスからクラウドへ移行することで、排出量削減につながる可能性を示せる点も、提案時の重要な観点です。
また、コスト最適化は環境負荷の低減にもつながります。Rightsizing、Auto Scaling、不要リソース削除、S3ライフサイクル、リージョン選定、Graviton、Well-Architectedといった取り組みは、費用削減だけでなく、無駄なリソース利用を減らすことにもつながります。
AWS提案において、サステナビリティは特別な追加テーマではありません。コスト、運用、説明責任とつながる実務的な観点です。まずは現状を測り、改善し、その成果を伝えることから始める。そんな提案の広げ方が見えた締めくくりのセッションでした。
- 関連資料：Talk10 LT会資料.pdf
おわりに
今回のLT会では、AWS Summitで得た現地の一次情報をもとに、AIエージェント、セキュリティ、DevOps、マルチクラウド、サステナビリティまで、幅広いテーマが共有されました。
「AIが脆弱性を検証して修復する」「運用調査をエージェントが短時間で支援する」「Lambdaが状態を持つ」「AWS提案に脱炭素の視点を加える」など、どのトピックも今後の実務に直結する内容でした。
共通していたのは、AIやAWSの新機能をただ追いかけるのではなく、人が最終的に判断し、提案価値に変えていくことの重要性です。
次回のLT会もお楽しみに！
