本記事は 2026 年 5 月 28 日 に公開された「 Introducing the next generation of Amazon OpenSearch Serverless for building your agentic AI applications 」を翻訳したものです。 本日、AI エージェントを構築するお客様向けに設計されたフルマネージドの検索およびベクトルエンジン、次世代 Amazon OpenSearch Serverless を発表します。次世代 OpenSearch Serverless は、コンピューティングリソースをゼロから 1 秒あたり数千リクエストを処理できる規模までスケールアップし、アイドル時にはゼロまでスケールダウンします。ピーク時の容量に合わせてプロビジョニングした OpenSearch Service クラスターと比べて、最大 60% のコストを削減できます。 次世代 OpenSearch Serverless は数秒でリソースを作成し、容量のスケールアップは前世代の最大 20 倍高速です。即時のリソース作成と、 Vercel や Kiro といった AI 開発プラットフォームとのネイティブ統合により、AI エージェント向けの本番環境対応の検索およびベクトルバックエンドを、インフラを管理せずに数分でデプロイできます。 次世代 OpenSearch Serverless の使い方 次世代 OpenSearch Serverless を使い始めるには、 Amazon OpenSearch Service コンソール の Serverless メニューで Create collection を選択します。 瞬時にオートスケーリングし、コスト最適化のためゼロまでスケールダウンする NextGen コレクションを作成します。リリース時点では、コレクションタイプとして全文検索とベクトル検索のみをサポートしています。既存の OpenSearch Serverless インフラを使う場合は、 Switch to Classic を選択してください。 コレクションを最速で作成するには、 Express create を選択します。設定は不要で、デフォルト設定と一致するセキュリティポリシーが自動で適用されます。一部の設定項目は後から変更できます。 Create collection を選択すると、OpenSearch Serverless は数秒でリソースをプロビジョニングします。 AWS Command Line Interface (AWS CLI) や AWS SDK でも OpenSearch Serverless のコレクションを作成できます。コレクショングループを作成する CLI コマンドの例を示します。 aws opensearchserverless create-collection-group \ --name channy-nextgen-group \ --standby-replicas ENABLED \ --generation NEXTGEN \ --description "My NextGen collection group" \ --capacity-limits '{ "maxIndexingCapacityInOCU": 10, "maxSearchCapacityInOCU": 10, "minIndexingCapacityInOCU": 0, "minSearchCapacityInOCU": 0 }' \ --region "us-east-1" 続いて、親のコレクショングループから世代を継承するコレクションを作成できます。サポートされるコレクションタイプは SEARCH と VECTORSEARCH です。 aws opensearchserverless create-collection \ --name channy-nextgen-collection \ --type SEARCH \ --collection-group-name channy-nextgen-group \ --standby-replicas ENABLED \ --description "My collection in NextGen group" \ --region "us-east-1" 次世代 OpenSearch Serverless の管理について詳しくは、 Amazon OpenSearch Serverless のドキュメント をご覧ください。 OpenSearch Serverless でエージェント開発を加速する Vercel での本番環境対応エージェントアプリケーションの構築をサポートするため、Vercel コンソール内で新しい OpenSearch コレクションを作成したり、既存の OpenSearch Serverless コレクションに接続したりできるようになりました。検索バックエンドを数秒で作成し、アプリケーションの成長に合わせてオンデマンドで機能を追加できます。詳しくは、 AWS for Vercel をご覧ください。 Claude Code、Cursor、Kiro を使えば、アイデアから動作するプロトタイプまで数分で到達できます。 OpenSearch Agent Skills は、OpenSearch のインテリジェンスをエージェントに直接組み込むスキルのリポジトリです。各スキルには特定のワークフローのドメイン知識、ベストプラクティス、複数ステップの実行ロジックがカプセル化されています。そのためエージェントは、結果を得るだけでなく、その結果に至った過程まで理解できます。 Kiro Powers の OpenSearch Launchpad を使えば、ガイド付きでエンドツーエンドにアーキテクチャを設計し、検索アプリケーションを高速に開発できます。 提供開始 次世代 Amazon OpenSearch Serverless は本日より一般提供を開始し、Amazon OpenSearch Serverless が現在利用可能なすべての AWS 商用リージョンで利用できます。 次世代 OpenSearch Serverless では、インデックス作成、検索、 GPU アクセラレーション に使用する OpenSearch Compute Unit (OCU) ベースのコンピューティングに対して課金されます。ストレージは GB 月単位で別途課金されます。詳しくは、 Amazon OpenSearch Service の料金 をご覧ください。 ぜひお試しいただき、 AWS re:Post for Amazon OpenSearch Service または通常の AWS Support 窓口からフィードバックをお寄せください。 — Channy 著者について Channy Yun (윤석찬) Channy は AWS News Blog のリードブロガーであり、AWS Cloud のプリンシパルデベロッパーアドボケイトです。オープンウェブの愛好家でブロガーでもあり、コミュニティ主導の学習と技術の共有を大切にしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

RevCommの熊谷です。 AIエージェントを使った開発が当たり前になり、コーディングの速度は確かに上がりました。一方で、フロントエンドは自由度が高いぶん、油断するとすぐに 設計がブレる という次の問題も見えてきます。今回は、それをどうやって抑えているかを書いてみます。私たちのチームではルールを文章で書き下すよりも、「参考実装を指す」ことを軸にしています。 困っていたこと 紹介するのは、MiiTel Admin という管理画面での話です。自社サービス「MiiTel（ミーテル）」を支える、Vue 3 + Nuxt 4 + TypeScript で作られた Web アプリケーション。ミーテルの成長とともに機能が増え続け、現在は 92 ページの大規模な管理画面になっています（ここ半年で 8 ページ増えてる...!）。 このプロダクトはフロントエンド専任ではない開発者（バックエンド・モバイル・音声 AI エンジニア）も気軽に機能追加に入ってくれます。それ自体はありがたいのですが、そのぶん設計のブレが起きやすい環境でもあります。 エージェント導入前は、既存のページをコピペして少し直すような書き方が多かったんですよね。コピペにはもちろん問題もあるのですが、結果として構成が大きく外れにくく、書く速度もそこまで速くなかったので、設計のずれはレビューで拾えていました。 ところが、エージェントが入ってから一気に状況が変わりました。 みんな書く速度が一気に上がった 設計のブレがレビューで追いつかない量で発生するようになった 開発者ごとに使うエージェント・モデルが違う（Copilot / Claude / Cursor / Devin、モデルもいろいろ） このまま放っておくとカオスになる、というのが課題感でした。 基本方針 打ち手はいくつかあるのですが、根っこの方針はシンプルです。 エージェント・モデルは開発者の好きなものを使ってOK（強制しない） ただし「何を見て書くか」だけは全エージェント共通にする 人間がレビューで都度直すのではなく、書かれる前に方向を揃える エージェントを「設計のブレ防止装置」として使うイメージです。本業で使い慣れたエージェントをそのまま使える方が、開発者にとっても嬉しいですしね。 やっていること エージェント向けのドキュメント整備は ルールを文章で書き下す アプローチが多いと思いますが、私たちはむしろ 参考実装そのものを指す アプローチを軸にしています。文章のルールはどうしても実装とズレていきますが、コードは常に最新だからです。以下の 3 つは、その方針から派生した工夫です。 1. リファレンス実装と「参考の優先順位」を明示する 1ページを徹底的にリファクタしてお手本にする、というやり方です。 前回のブログ でも書いたパターンですね。 現在は SMS テンプレート機能 src/pages/sms-template/ を参照実装にしていて、エージェントが見る .github/copilot-instructions.md にも明記しています。 ## 作業の進め方（最優先） - 変更行数が合計 20 行を超える場合は必ず守ること。 1. コードを書く前に対応するスキルを呼び出す 2. 使用するスキルが 3 つを超える場合は、作業分割をユーザーに提案する — ユーザーが「そのまま進めて」と回答すれば継続してよい 3. 既存のコンポーネント構造・設計に従う 4. 明示的な指示がない場合は新しい設計パターンの導入はしない 5. 判断に迷った場合は、一般的なベストプラクティスに従うよりも、既存コードの設計・パターンに合わせることを優先する ## 参考実装の優先順位 1. `src/pages/sms-template/`（composable 分離・Pinia Setup Store・vee-validate・i18n が揃ったパターン） 2. `src/pages/softphone-setting/`（Pinia 移行済みの最新実装） 3. 同カテゴリの既存画面（同じユースケース・UI 構成） 4. `src/composables/`、`src/components/organisms/` の既存実装 参考実装の場所さえ明示しておけば、エージェントは常に最新のコードを見にいってくれます。ドキュメントの更新が遅れても、自然と最新パターンに揃っていくというのが、このやり方のいちばん効いている点です。 「既存パターンを優先する」と明文化しておくと、エージェントがプロジェクト側に寄せてくれやすくなります。バックエンドエンジニアもフロントを触る体制なので明示的に書いていますが、フロント専任メンバーで固まっているチームでは、ここまで強く書く必要はないかもしれません。 2. コンテキストに乗せる情報を絞る ドキュメントは育てると肥大化しがちです。とくに先ほどの参考実装アプローチでは、エージェントが skill / instructions に加えて実コードまで読みにいくので、コンテキストはなおさら膨らみやすい。コンテキストが膨らむと、 エージェントの注意がそれて、長いルールほど読み飛ばされやすくなる 。動作そのものも遅くなります。なので、「何を読ませないか」もセットで設計しています。 トピックごとに skill に分割: state-management / i18n-rules / vee-validate-form など。関連する作業のときだけ読み込ませる 小規模変更ではスキップ可能に: 「変更行数が 20 行を超える場合は必ず skill を呼ぶ」のように、軽微な編集では読み込みを省略できる逃げ道を書いておく 人間向けドキュメントと分離: 設計ドキュメント ( docs/architecture.md など) は人間向けに保ち、エージェント向けは簡潔な技術用語の羅列に近い形に 最後の点は試行錯誤がありました。最初は copilot-instructions.md から docs/architecture.md を参照させていたのですが、結局コンテキストが膨らむだけで効果が薄かった。エージェント向けには「読みやすさ」より「短さ」を優先して、技術用語の羅列に近い形に分離したら、必要な情報だけ拾ってもらえるようになりました。 3. ライブラリの標準パターンに素直に乗る 2 はドキュメントを絞る工夫でしたが、もう一歩進めて、 そもそもドキュメントを書かなくて済むようにする こともできます。エージェントがすでに知っている公式パターンに乗せれば、プロジェクト固有のルールを書く必要がありません。 これは、考え方が大きく変わったところです。 以前は「Nuxt/Vue 固有機能をバックエンドエンジニアにまで覚えてもらうのは忍びない」と思っていて、Vanilla 寄りの実装で吸収していました。たとえばページの表示条件は、各ページで router.push を使って書いていました。 // src/pages/sms-templates.vue (抜粋) const router = useRouter(); const { isSmsAvailable } = usePermission(); onMounted(() => { if (!isSmsAvailable.value) router.push('/'); }); 今は Nuxt の definePageMeta + middleware に置き換えました。各ページは宣言を 1 行書くだけです。 // src/pages/sms-templates.vue (抜粋) definePageMeta({ permission: (ctx: TenantContext) => ctx.isSmsAvailable, }); 判定の本体は middleware に集約。全ページぶんが、ざっくりこの数行で完結します。 // middleware/permission.global.ts (抜粋) export default defineNuxtRouteMiddleware(to => { const ctx = usePermission(); if (!to.meta.permission?.(ctx)) return navigateTo('/'); }); この設計は Vue Router 公式の route.meta + navigation guard パターン をほぼそのまま踏襲したもので、プロジェクト固有の語彙も permission / TenantContext の 2 つに絞れているので、エージェントは公式パターンの知識をほぼそのまま使って書けます。 振り返ると、MiiTel Admin は SSR を採用していないこともあり、これまで Nuxt らしい機能を十分に活かせていませんでした。それがエージェントの登場で逆転しました。 エージェントが補完してくれるなら、標準パターンに乗る方がブレない 。学習コストの高い固有機能も気軽に取り入れられるようになり、Nuxt を選んだメリットをようやく実感できているところです。 ルールを長く運用する工夫 一次ソースを 1 箇所に集約する ドキュメントは長く運用すると、コピーが増えてあちこちでずれていく、というのが起きがちです。一次ソースを 1 ヶ所に集約して、各エージェントからは同じファイルを参照させるようにしています。 .github/copilot-instructions.md と .github/instructions/*.instructions.md を起点に、Claude 用 .claude/skills/ や Cursor からも同じファイルを参照。コピーを作らないので更新がずれません。一番制約がきつい Copilot（2026 年 5 月時点では外部ファイルを参照できず、 .instructions.md 自体に内容を直接書く必要があります）に合わせて書いておけば、他のエージェントでも破綻しにくい、というのも分かってきました。 たとえば Claude 用の .claude/skills/i18n-rules/SKILL.md は、 .github/instructions/ 配下の対応するファイルを cat するだけのシンプルな中継ファイルです。 --- name: i18n-rules description: Use this skill when creating or editing i18n files (...). --- !`cat ${CLAUDE_SKILL_DIR}/../../../.github/instructions/i18n-rules.instructions.md` これで Claude も Copilot も結局は同じ .github/instructions/i18n-rules.instructions.md を見ているので、更新は 1 箇所で済みます。 PR レビューでルールを育てる それでも、思ったような PR が出てこないことはあります。レビューで違和感を覚えるときって、実装した本人も「なんか変だな」と感じていることが結構あるんですよね。そんな時は、本人が使っているエージェント環境で、そのまま 「今回どの skill / instructions 読んだ？参考実装は何を見た？」と聞いてもらいます。自分の環境で再現するより速いし、本人もその場で原因を切り分けやすい。ルール自体が足りないのか、ルールへの導線が悪いのか、参考実装が古いのか。「あ、これ参照されてなかったね、書き足しておくね」みたいに、雑談ベースでドキュメント改善を回しています。 原因の切り分けが終わったら、その流れでエージェントに .github/instructions/ の修正 PR まで作ってもらうこともあります。違和感を覚えた人が、その場でルールを直す側に回れるのは、エージェント時代ならではの良さだなと感じています。 おわりに エージェント時代のフロントエンド開発で効いたのは、 「何を見て書くか」を揃えること だなと感じています。エージェントを厳しく縛るのではなく、既存設計に自然に合流できる道を整える。それができれば、速く作りながら長く保守できるプロダクトに近づけるはずです。 「スピードは出るようになったけど、設計がブレ始めた」というフェーズに入ったチームの参考になれば嬉しいです。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今週も様々なアップデートが公開されています。特に、AWS Blogで紹介している AI エージェント対応のデータ基盤は、エージェントをデータに以下に紐づけるのかというイメージの湧くデモになっていますので、ぜひご一読ください。 生成 AI を活用したビジネス変革に取り組むお客様を支援する 生成 AI 実用化推進プログラム は引き続き参加企業を募集しています。ご興味のある方はぜひご覧ください。 それでは、5 月 18 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ:  3 か月で開発スピード 3 倍を達成：キヤノン IT ソリューションズ様が実践した AI Coding Agent 導入・普及の仕組みづくり キヤノン IT ソリューションズ株式会社様（以下、キヤノン ITS 様）は、SIer としての競争力強化と顧客への付加価値提供のため、AI 駆動開発の社内普及を推進しました。生成 AI ツールの導入は進んでいたものの、現場での活用の定着と全社的な広がりが課題でした。これを解決するため、AWS と共同でロードマップを敷き、9 月のキックオフイベント「AI Agent DAY」（参加者 250 名以上）から 3 か月間にわたり、Amazon Q Developer を 57 名で業務適用検証しました。エグゼクティブスポンサーである金澤社長の支援、生成 AI ビジネス推進室による予算負担、ハンズオン・オフィスアワー・Teams コミュニティでの情報共有を組み合わせ、PoC 開発で従来 2 週間かかっていた作業を 3 日で完了するなど、開発スピード 3 倍、工数 67% 削減を達成しています。今後は本検証で得た知見を活かして社内での活用パターンを整理し、AWS と連携してさらなる活用領域の拡大に取り組まれる予定です。 AWS 生成 AI 国内事例ブログ: 富士電機ITソリューションが挑戦する働き方の大変革 〜Amazon Q Developer 活用から Kiro による新しい企業価値創出へ〜 富士電機 IT ソリューション株式会社様（以下、FSL 様）は、製造・流通・金融・建設・公共・文教など幅広い業界向けに IT ソリューションを提供する SIer です。SIer としての競争力強化と顧客への付加価値提供のため、生成 AI による開発生産性向上が重要なテーマでした。FSL 様は 2025 年 12 月から金森 重晴 執行役員の指揮のもと Amazon Q Developer Pro サブスクリプションを 20 ユーザーで展開し、「まず使ってみる」を合言葉にボトムアップ型のアプローチで現場主導の活用文化を育てた結果、現在では 50 ユーザー以上に拡大しています。本記事では、テスト結果報告書の作成や障害情報のインサイト抽出（原田氏）、ソースコードのレビュー支援や既存プログラム理解（久保田氏）、リバースエンジニアリングや見積もりツールの内製開発（前田氏）など現場発の 3 つの活用事例が紹介されています。今後は利用者のさらなる拡大と、仕様駆動開発を実現する Kiro の導入により、SDLC 全体を再設計する取り組みを進めていかれる予定です。 ブログ記事「 AWS における AI エージェント対応のデータ基盤 (1) — ツールを配る時代から、データを返す時代へ 」を公開 AI エージェントに本番データを分析させるには、認可・ビジネスデータカタログ・ドメイン知識の 3 要素を揃える必要があります。本記事ではサンプルリポジトリ  aws-samples/sample-sagemaker-agentic-analyst  を題材に、これら 3 要素が Amazon SageMaker Catalog、Amazon Bedrock AgentCore、AWS Lake Formation、Amazon S3 Access Grants の組み合わせでどう実装されているかを俯瞰し、構造化データと非構造化データを束ねた分析や Subscribe 申請を仲介するデモシナリオを紹介しています。データ分析エージェントを企業データに安全に接続したい方にぜひお読みいただきたい記事です。 ブログ記事「 AWS における AI エージェント対応のデータ基盤 (2) — SageMaker Catalog で行・列レベルのアクセス権を透過的に適用する 」を公開 上記シリーズの第 2 回です。AI エージェント経由のデータアクセスに、SageMaker Catalog で設定した行・列・オブジェクトレベルのアクセス制御をユーザー本人の権限で透過的に効かせるための実装パターンを解説しています。Cognito トークンから Tool Lambda の手元にプロジェクトロールの一時認証情報を運ぶ 5 ステップの認証情報変換フローや、Policy in AgentCore による Cedar ポリシーでのツール単位認可など、AgentCore Gateway を使った認可設計の実装の中身を詳しく追える内容になっています。 ブログ記事「 【開催報告】ガバメントクラウドワークショップ 2026 春 ～ AI で実践する開発・モダナイズ・運用 ～ 」を公開 5 月 19 日に開催された、ガバメントクラウドに携わる事業者向けワークショップの開催報告です。NTT データ様の Step Functions を中核としたフルマネージド・ジョブ基盤の事例、アクロクエストテクノロジー様の Amazon Bedrock を用いたセキュアな生成 AI 構築、NTT 西日本様の  GenU  と Amazon Bedrock AgentCore を活用した自治体向け AI エージェント、デジタル庁様による全府省庁約 18 万人向け生成 AI 利用環境「源内」の構築、AI エージェント開発・モダナイズ・運用の 4 テーマ別ワークショップなど、公共分野で生成 AI を活用するヒントが詰まった内容です。 ブログ記事「 Amazon Bedrock が、新しい高度なプロンプト最適化および移行ツールを導入 」を公開 5 月 14 日に発表された Amazon Bedrock Advanced Prompt Optimization の使い方を解説したブログです。元のプロンプトと最適化されたプロンプトを最大 5 個のモデルで同時に比較しながら最適化を進められるツールで、Lambda 関数によるカスタムスコアリング、LLM-as-a-judge ルーブリック、自然言語による方向性基準の 3 通りの評価方法をサポートしています。新しいモデルへの移行や、既存モデルでの精度改善に取り組まれている方にお勧めの記事です。 ブログ記事「 OpenSearch Agent Skills で agentic IDE に組み込み型のインテリジェンスを 」を公開 Claude、Cursor、Kiro などの agentic IDE の中で OpenSearch の専門知識をそのまま活用できる、オープンで組み合わせ可能なスキル集 OpenSearch Agent Skills の発表ブログです。Search、Logs、Solr から OpenSearch への移行という 3 つの基本スキルにより、自然言語の意図から検索アプリケーションの構築、ログ分析、移行作業を数分で実行できます。npx skills add opensearch-project/opensearch-agent-skills でインストールでき、MCP サーバーや追加コンポーネントは不要です。 ブログ記事「 AWS Security Agent のフルリポジトリコードスキャン機能のプレビュー提供開始 」を公開 AWS Security Agent に追加された、コードベース全体をコンテキスト認識型で分析するフルリポジトリコードレビュー機能の解説ブログです。アプリケーションのプロファイリング、脆弱性の検索、トリアージと重複排除、独立した検証という 4 ステージで動作し、既知のパターンと照合する従来の SAST が見逃すような、検証関数の不整合や設計レベルのギャップも検出します。検出結果は Verified / Could not verify を区別した構造化された証拠付きで提示されます。プレビュー期間中は既存の Security Agent のお客様に追加料金なしで提供されています。 ブログ記事「 Sim-to-Real と Real-to-Sim: 高性能な Physical AI を支える原動力 」を公開 現実世界で知覚・推論・行動するロボット、いわゆる Physical AI システムを支える Sim-to-Real / Real-to-Sim パイプラインを解説した記事です。シミュレーションと現実のギャップを埋めるためのドメインランダム化、現実環境をシミュレーション対応のデジタル表現に変換する Real-to-Sim、合成データ生成とフィルタリングなどを取り上げ、Vision Language Action モデル (VLA) の品質がシミュレーションデータの品質に依存することなどが説明されています。製造業・自動運転・医療・エネルギー・小売などの業界応用にも触れられています。 ブログ記事「 AI、技術的負債、そして AI を使いこなす力への道筋 」を公開 エンタープライズが直面する 3 つの共通課題（自社の技術資産の把握不足、AI 導入の停滞、AI を実践的に使いこなす力のギャップ）に対し、AWS Transform custom のモダナイゼーションエージェントを活用してコードからリアルタイムにドキュメントアーティファクトを自動生成するアプローチを提案しています。技術的負債の可視化と AI を使いこなす力の習得を同時に実現し、ポートフォリオ全アプリケーションへの展開を OKR として組織に定着させる進め方を、元 CTO の視点から実践的に解説した記事です。 サービスアップデート Amazon Bedrock がリクエストレベルの使用量属性のサポートを拡大 これまで Converse / ConverseStream API でサポートされていたリクエストレベルのメタデータ付与が、InvokeModel および InvokeModelWithResponseStream API でも利用できるようになりました。チーム、アプリケーション、環境、実験などの単位でモデル推論の使用量を個別のリクエストレベルでタグ付けし、Bedrock のモデル呼び出しログで分析できます。社内の利用状況を細かく可視化してコストを最適化したり、内部関係者へ利用量を報告したりするのが容易になります。Amazon Bedrock が利用可能な全ての AWS リージョンで利用できます。 Amazon SageMaker AI が推論エンドポイントで OpenAI 互換 API をサポート Amazon SageMaker Inference が OpenAI 互換 API をサポートするようになりました。OpenAI SDK、LangChain、Strands Agents などの既存ツールから、エンドポイント URL を変えるだけで SageMaker エンドポイントに接続できます。カスタム連携コードや SDK ラッパーの書き直しは不要で、独自の GPU インスタンス選択、VPC 内でのデータ保持、任意のオープンソース・ファインチューニング済みモデルの実行といった SageMaker のメリットをそのまま享受できます。東京、ソウル、シンガポール、シドニーなど 14 のリージョンで利用可能です。 AWS Transform に新しいエージェンティック移行アセスメント機能が追加 AWS Transform で、What-if シナリオ、カスタマイズ可能な前提条件、柔軟なファイル形式サポート、複数の TCO（総所有コスト）アセスメント機能を含む高度な移行アセスメント機能が利用できるようになりました。RVTools のエクスポート、CMDB データ、AWS Transform 検出ツール、サードパーティのディスカバリーツールなど、手元にあるあらゆるデータからアセスメントを開始できます。リージョン、リソース使用率、サービスマッピングをカスタマイズした What-if シナリオを作成して比較し、EC2、FSx、S3、SQL Server on EC2、仮想デスクトップのコストモデリングや、人材生産性・運用レジリエンス・ビジネスアジリティ・サステナビリティといった Cloud Value Framework の追加要素も含めて評価できます。 AWS Security Agent がペネトレーションテスト検出結果の検証スクリプトを生成 AWS Security Agent で、ペネトレーションテストで発見された各脆弱性に対して、その場で実行可能な検証スクリプトが自動生成されるようになりました。これまでは検出結果の詳細にある再現手順を手作業でなぞる必要がありましたが、今後はセキュリティチームがスクリプトをダウンロードし、環境変数を設定して対象システムに対して実行するだけで脆弱性を独立して再現・検証できます。スクリプトにはセットアップ手順、ドキュメント化された環境変数、機微な値のリダクションが含まれ、トリアージの効率化と修復の加速につながります。AWS Security Agent がサポートされている全リージョンで利用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。