0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

[AWS re:Invent 2025] Opening Keynote - 後編: AIエージェントとDevOpsの未来

Posted at

はじめに

前編では、AWS re:Invent 2025 Opening Keynoteで発表された生成AIモデルとAI開発ツールについてまとめました。後編では、AIエージェント開発の新しいアプローチと、DevOps・Security領域でのAI活用について取り上げます。

この後編では、Amazon Bedrock AgentCore、AWS DevOps Agent、AWS Security Agent、そしてCloudWatchの統合について、技術者としての視点で考察していきます。

前編をまだご覧になっていない方は、こちらからどうぞ。

AIエージェント開発の新時代

Amazon Bedrock AgentCore: エージェント開発の基盤

Keynoteの後半で、Matt Garmanはソフトウェア開発の新しい時代について語り始めました。その中心にあるのが、Amazon Bedrock AgentCoreです。

Amazon Bedrock AgentCore

AgentCoreは、AIエージェントを構築するための包括的なプラットフォームで、以下の特徴が強調されていました:

  • 任意のフレームワーク・モデルから選択可能
  • サービスのミックス&マッチ
  • Amazon VPCサポート
  • ゼロから数千のセッションまでスケール
  • 1分以内にエージェントをデプロイ

視聴していて感じたのは、AgentCoreが単なるAI推論の仕組みではなく、複雑なワークフローを持つエージェントを「プロダクションレベル」で運用するための基盤を提供しようとしている点です。

特に、Amazon VPCサポートは企業での利用を考えると重要な要素だと思いました。AIエージェントが社内システムと連携する場合、ネットワークセキュリティは避けて通れない課題です。VPC内でエージェントを実行できることで、セキュリティ要件の厳しいエンタープライズ環境でも採用しやすくなりそうです。

開発パラダイムの転換: "Baby-sitting" から "Directing" へ

Keynoteで特に印象に残ったのが、AIエージェントとの関わり方についての考え方の転換です。

従来のアプローチでは、開発者がAIの出力を細かくチェックし、修正し、管理する「Baby-sitting(子守)」のような関係でした。しかし、エージェントが進化することで、開発者は高レベルの指示を出し、エージェントが自律的にタスクを実行する「Directing(指揮)」の関係に移行していくという考え方です。

この図を見て、実際の開発現場での変化を想像してみました。例えば、従来はAIにコードを生成させても、それを一行ずつレビューして修正する必要がありました。しかし、エージェントが進化すれば、「この機能を実装して、テストも書いて、ドキュメントも更新して」という高レベルの指示で、一連のタスクを任せられる可能性があります。

ただし、これは「AIに全て任せられる」という意味ではないと思います。むしろ、開発者の役割が「コードを書く」から「アーキテクチャを設計し、方向性を示す」という、より戦略的なものにシフトするのかなと感じました。

AgentCore Policy: エージェントの行動制御

AgentCoreで特に興味深かったのが、Policy機能です。

この機能は、エージェントの行動に明確な境界を設定するためのものです。具体的には:

  • 自然言語でCedarへのポリシー作成と管理を簡素化
  • インスタントポリシーチェックでエージェントワークフローを高速かつレスポンシブに保つ
  • エージェントコードベースの外でポリシーを強制し、エージェントを境界内に保つ

実装を考えると、エージェントに自律性を持たせる一方で、制御可能性を確保することは非常に重要です。例えば、DevOpsエージェントが本番環境のリソースを削除してしまうような事故を防ぐには、ポリシーレベルでの制約が必要です。

Cedarは、AWSが開発したポリシー言語で、Amazon Verified Permissionsでも使用されています。これを自然言語で記述できるようにすることで、セキュリティの専門知識がなくても、適切なガードレールを設定できるようになる可能性があります。

個人的には、このポリシー機能がどこまで細かく制御できるのか気になります。例えば、時間帯による制限、特定のAPIエンドポイントへのアクセス制限、データサイズの制限など、実用的なシナリオでどの程度柔軟に対応できるか、実際に試してみたいと思いました。

専門特化型エージェント: DevOps と Security

AWS DevOps Agent: 運用の自動化

次に発表されたのが、AWS DevOps Agentです。

AWS DevOps Agent

DevOps Agentは、「The frontier agent for operational excellence. Fewer alerts, more sleep for your team.」というキャッチフレーズで紹介されました。これは運用チームにとって非常に魅力的なメッセージだと思います。

視聴していて理解したのは、DevOps Agentが単なるアラート対応の自動化ツールではなく、問題の根本原因を分析し、修復アクションまで実行できる可能性があるということです。

例えば、本番環境でメモリ不足のアラートが発生した場合:

  1. 従来: オンコール担当者が起こされ、ログを確認し、原因を特定し、手動で対処
  2. DevOps Agent: エージェントがアラートを検知し、関連ログを分析し、適切なアクションを実行(またはアクション候補を提示)

実装面で気になるのは、エージェントがどこまで自動的にアクションを実行するかという点です。完全自動化は効率的ですが、誤った判断による障害拡大のリスクもあります。おそらく、重要度や影響範囲に応じて、自動実行と人間の承認を組み合わせる仕組みが必要になるのかなと思います。

AWS Security Agent: セキュリティの自動化

DevOps Agentと並んで発表されたのが、AWS Security Agentです。

3つの新エージェント
この画像では、3つの新しいエージェントが並んでいます:

  • Kiro autonomous agent: 開発フローを拡張するフロンティア開発エージェント
  • AWS Security Agent: より安全なアプリのためのフロンティアエージェント
  • AWS DevOps Agent: 運用の卓越性のためのフロンティアエージェント

Security Agentは、「Ship with confidence. The frontier agent for more secure apps.」というメッセージで紹介されています。

セキュリティは、開発プロセスの中で常に考慮すべき要素ですが、実際には後回しにされがちです。Security Agentが開発プロセスに統合されることで、コードレビュー時点でセキュリティの問題を検出したり、デプロイ前に脆弱性スキャンを自動実行したり、といったことが容易になる可能性があります。

個人的には、Security Agentがどのような種類のセキュリティ問題を検出できるのか、また、誤検知(False Positive)の率がどの程度なのかが気になります。セキュリティツールは、誤検知が多すぎると開発者に無視されてしまう傾向があるため、精度が重要だと感じます。

Amazon Quick: AIを活用した分析とワークフロー

前編でも触れましたが、後編ではAmazon Quickのより実践的な側面を見ていきます。

Amazon Quick - 3つの機能

Quick Research、Quick Sight、Quick Flowsの3つのコンポーネントは、それぞれが独立して使えるだけでなく、組み合わせることでより強力なワークフローを構築できそうです。

例えば:

  1. Quick Researchで社内文書から必要な情報を抽出
  2. Quick Sightでデータを可視化し、インサイトを得る
  3. Quick Flowsで定期的なレポート生成を自動化

このようなノーコード/ローコードツールは、非エンジニアのビジネスユーザーがAIを活用する際の障壁を下げる効果があります。一方で、開発者の視点からは、これらのツールがどこまでカスタマイズ可能で、どのようにAPIと統合できるかが重要です。

個人的には、Quick FlowsとAgentCoreの関係性が気になります。Quick Flowsで構築したワークフローを、より高度なエージェントに発展させるパスがあるのか、それとも完全に別のツールとして位置づけられているのか、今後の情報に注目したいと思います。

CloudWatch Unified Data Store: オブザーバビリティの統合

Keynoteの最後の方で発表されたのが、CloudWatch Unified Data Storeです。

CloudWatch Unified Data Store

これは、運用、セキュリティ、コンプライアンスのデータを一箇所に統合することで、問題の調査、根本原因の特定、新しいインサイトの発見を可能にする機能です。

オブザーバビリティは、現代のクラウドアプリケーション開発において非常に重要です。しかし、実際にはログ、メトリクス、トレースが別々のツールに分散していることが多く、障害時の調査に時間がかかります。

Unified Data Storeは、これらのデータを統合することで、相関分析を容易にします。例えば、アプリケーションのエラーログと、その時点でのCPU使用率、ネットワークトラフィック、セキュリティイベントを一つのビューで確認できれば、原因の特定が格段に速くなります。

実装面で考えると、データの取り込み方法、保存期間、クエリのパフォーマンス、コストなどが気になります。特に、大量のログデータを長期間保存する場合、ストレージコストは無視できません。CloudWatchがどのようなデータ圧縮やアーカイブの仕組みを提供するのか、詳細を確認したいと思います。

また、このUnified Data StoreとDevOps Agentの連携も興味深いポイントです。エージェントがこの統合データストアにアクセスすることで、より文脈を理解した上での問題診断が可能になるはずです。

ソフトウェア開発の新しい時代

Keynoteでは、Matt Garmanは「A new era in software development」というメッセージを示しました。

A new era in software development

AIエージェントが開発プロセスに深く統合されることで、開発者の役割が変わっていく様子が感じられます。

視聴していて感じたのは、これは単なる「コーディング支援ツール」の話ではなく、ソフトウェア開発のライフサイクル全体(設計、実装、テスト、デプロイ、運用)をAIが支援する世界観だということです。

個人的には、この変化に対して期待と同時に慎重さも感じています。AIエージェントが多くのタスクを自動化できるようになったとしても、アーキテクチャの設計、トレードオフの判断、ユーザー体験の向上といった「創造的な部分」は、引き続き人間の開発者が担う必要があると思います。

むしろ、反復的なタスクや運用作業をエージェントに任せることで、開発者がより創造的な仕事に集中できるようになる、というのが理想的なシナリオかなと考えています。

実装を考えてみて

実際の適用シーン

これらの新しいエージェント技術を、実際のプロジェクトにどう適用できるか考えてみました。

DevOps Agentの活用例:

  • 本番環境の異常検知と自動対応(スケーリング、再起動、ロールバック)
  • デプロイパイプラインの自動最適化(テスト実行時間の短縮、並列化の最適化)
  • インフラのドリフト検出と修正(Terraform/CloudFormationの状態管理)

Security Agentの活用例:

  • プルリクエスト時点での自動セキュリティレビュー
  • 依存関係の脆弱性スキャンと自動パッチ適用の提案
  • コンプライアンス要件の継続的チェック(GDPR、SOC2等)

AgentCoreを使ったカスタムエージェント:

  • カスタマーサポートエージェント(問い合わせ対応、チケット作成、エスカレーション)
  • データパイプライン監視エージェント(データ品質チェック、異常検知、修復)
  • ドキュメント管理エージェント(APIドキュメントの自動生成、更新チェック)

実装時の考慮点

これらのエージェント技術を実装する際、いくつか重要な考慮点があると感じました。

信頼性と可観測性:
エージェントが自律的に動作する場合、その判断プロセスや実行したアクションを追跡可能にする必要があります。ログ、メトリクス、トレースを適切に設計し、「エージェントが何をしたか」を後から確認できる仕組みが重要です。

段階的な導入:
いきなり重要なタスクをエージェントに任せるのはリスクが高いため、段階的なアプローチが必要です。最初は「推奨アクションの提示」から始め、精度が向上したら「自動実行(承認付き)」に移行し、最終的に「完全自動化」に到達する、というステップを踏むのが良さそうです。

コストとパフォーマンスのバランス:
エージェントは複数のAI推論を組み合わせることが多いため、コストが増加する可能性があります。どのタスクをエージェント化すべきか、ROI(投資対効果)を考慮して判断する必要があります。

セキュリティとガバナンス:
エージェントにどこまでの権限を与えるかは重要な判断です。AgentCoreのPolicy機能を活用して、適切なガードレールを設定することが不可欠です。特に、本番環境へのアクセスやデータの変更を伴うアクションには、慎重な設計が必要です。

チームへの教育:
エージェント技術の導入は、チームの働き方を変える可能性があります。開発者やオペレーターが、エージェントとどう協働するか、どのように監視・管理するかを理解する必要があります。

Next.js + Pythonでのエージェント実装

私が普段使用しているNext.jsとPythonのスタックで、これらのエージェント技術をどう統合できるか考えてみました。

アーキテクチャ例:

[Next.js Frontend]
  ↓ (REST API / WebSocket)
[FastAPI Backend]
  ↓ (Boto3 SDK)
[Amazon Bedrock AgentCore]
  ├─ Nova 2 Pro (推論)
  ├─ Knowledge Base (RAG)
  ├─ Tools (Lambda関数など)
  └─ Policy (行動制御)

このアーキテクチャでは:

  1. Next.jsがユーザーインターフェースを提供
  2. FastAPIがビジネスロジックとエージェントの呼び出しを管理
  3. AgentCoreが実際のエージェント処理を実行

リアルタイム性が必要な場合(例: チャットボット)、WebSocketを使ってエージェントの処理状況や思考プロセスをストリーミングで表示することも可能です。

PythonのLangChainやLangGraphといったフレームワークと、AgentCoreをどう組み合わせるかも興味深いポイントです。既存のエージェントフレームワークで構築したロジックを、AgentCoreのインフラ上で実行する、というハイブリッドアプローチもあり得そうです。

まとめ

後編では、AWS re:Invent 2025 Opening Keynoteで発表されたAIエージェント技術とDevOps/Securityの自動化について、視聴して得られた気づきをまとめました。

主なポイント:

  • Amazon Bedrock AgentCoreにより、エージェント開発がプロダクションレベルで実用的に
  • DevOps AgentとSecurity Agentによる専門領域の自動化で、運用負荷の軽減が期待できる
  • AgentCoreのPolicy機能により、エージェントの行動を制御しながら自律性を確保
  • CloudWatch Unified Data Storeによるオブザーバビリティの統合で、問題解決が迅速に
  • ソフトウェア開発の新しい時代として、開発者とAIの協働が加速

特に、エージェントが「Baby-sitting」から「Directing」へと進化するという考え方は、今後の開発スタイルを考える上で重要な視点だと感じました。

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?