(この記事は、 Enable zero-copy access to AWS services on Amazon FSx for NetApp ONTAP with Amazon S3 Access Points を翻訳したものです。) 半導体の検証チームは EDA（Electronic Design Automation）ツールを使い、毎晩数千件のシミュレーションジョブを実行しています。大規模な検証環境では 1 晩に 10 万件以上のテスト実行のログが生成されることもあります。1 回のリグレッションテストではシミュレーションログ、コンパイルログ、ジョブスケジューラーのログが出力されます。失敗が数十件に及ぶリグレッションテストでは手作業によるトリアージ（失敗原因の切り分け）に通常 45～60 分を要します。多数の失敗に共通する根本原因の特定には数日を要することもあります。現状ではエンジニアが SSH で接続し、grep でシミュレーション結果を検索して、複数のターミナルでジョブスケジューラーのログと照合しています。独自のスクリプトを開発するチームもありますが、継続的な保守が必要なうえ、ほかのテストスイート（リグレッションテストで実行するテスト群）への展開も困難です。ログファイルは高性能な共有 NFS ストレージにすでに格納されています。課題はこれらのログを、複数のファイルを読み込んで内容を突き合わせられる AI サービスから参照可能にすることです。そのためには取り込み用のパイプラインを構築するか、データを Amazon Simple Storage Service（Amazon S3） にコピーする必要があります。 本記事では既存のワークフローを妨げず、データも移動せずに、EDA の検証ワークフローと AI による分析を連携させるアーキテクチャを紹介します。このアーキテクチャでは Amazon FSx for NetApp ONTAP 、 Amazon S3 Access Points 、 Amazon Bedrock AgentCore 、 Amazon Quick を使用します。 FSx for ONTAP の S3 アクセスポイントを使うと、AWS のサービスから S3 API で検証ログにアクセスできます。データはファイルシステム上に保持されたままです。AgentCore はツールを利用できる AI エージェントをデプロイするマネージドサービスです。Amazon Quick は自然言語による問い合わせやワークフローの自動化を AI で実現する分析サービスです。エンジニアが Amazon Quick で「昨夜の失敗の原因は何か」と質問すると、シミュレーション、コンパイル、ジョブスケジューラー（LSF）の各ログを突き合わせた分析結果が数分以内に返されます。根本原因の分析が迅速になれば、エンジニアは手作業のトリアージに費やしていた時間を削減してバグの修正に注力でき、テープアウトまでの期間も短縮できます。 ソリューションの概要 図 1 にソリューションのアーキテクチャを示します。EDA ツールは NFS 経由で FSx for ONTAP にログデータを書き込みます。ログデータには S3 アクセスポイントを介して S3 API でもアクセスできます。エンジニアがログファイルを参照する経路は 2 つです。要約を素早く得るためのナレッジベースの経路と、複数のファイルを横断して詳しく調査するためのエージェントの経路です。 図 1: EDA ツールは NFS 経由で FSx for ONTAP にログを書き込みます。ログには S3 アクセスポイントを介して S3 API でアクセスできます（ゼロコピー、読み取り専用）。エンジニアはナレッジベースの経路か、エージェントの経路（MCP ゲートウェイ）でログを参照します。 訳注 ナレッジベースの経路（RAG）: ログデータから事前に作成したインデックスを基に回答する経路です。 エージェントの経路: AI エージェントがログファイルを直接読み込み、複数のファイルを横断して調査する経路です。 MCP（Model Context Protocol）: AI エージェントが外部のツールやデータを利用するための標準プロトコルです。 FSx for ONTAP に保存されるログファイル EDA ツールは計算クラスター上でシミュレーションやコンパイルのジョブを実行します。各ジョブは NFS 経由で FSx for ONTAP のボリュームにログファイルを書き込みます。この既存のワークフローを変更する必要はありません。ログデータは FSx for ONTAP に集約され、ここが正本（Single Source of Truth）となります。ログは共有ストレージ上の /mnt/fsx/logs/ のようなプロジェクトディレクトリ配下に格納されます。 FSx for ONTAP の S3 アクセスポイント ログを格納したボリュームに S3 アクセスポイントをアタッチすると、S3 API によるアクセスが可能になります。アクセスポイントには読み取り権限のみを持つファイルシステムユーザーを関連付け、アクセスポイント経由の操作を読み取りに限定します。EDA ツールは従来どおり NFS 経由で書き込みを続けます。同時に、AWS のサービスは S3 API 経由でデータを読み込みます。S3 アクセスポイントは AWS CLI の create-and-attach-s3-access-point コマンドで作成します。 ナレッジベースの経路（RAG） Amazon Quick は自然言語による問い合わせ、ビジュアルダッシュボード、ワークフローの自動化を単一のインターフェイスでエンジニアに提供します。検索拡張生成（RAG: Retrieval Augmented Generation）を用いるこの経路では、Amazon Quick が S3 アクセスポイントからログデータを同期してインデックスを作成し、ナレッジベースに格納します。Quick のチャットエージェントはリクエストのたびにログファイルを読み込むのではなく、作成済みのインデックスから回答します。そのため、「昨夜はいくつのシミュレーションが失敗したか」のように、要約を素早く得たい質問に適しています。 エージェントの経路（MCP ゲートウェイ） AgentCore は MCP ゲートウェイをホストします。ゲートウェイに登録した AWS Lambda 関数は S3 アクセスポイントを介して FSx for ONTAP のファイルを問い合わせのたびに読み込みます。MCP ゲートウェイはエージェントに次の 3 つのツールを提供します。 List – ディレクトリの一覧を取得する Read – S3 のファイルを読み込む Search – S3 のファイルを横断して検索する シミュレーションログの読み込み時は、Lambda 関数が S3 アクセスポイントに対して GetObject（ファイルの取得）を呼び出します。実行済みのリグレッションテストを一覧で確認する際は、ボリューム上のパスに対して ListObjects（ファイルとディレクトリの一覧の取得）を呼び出します。エージェントは自律的にディレクトリをたどって複数のログを読み込み、詳細なトリアージレポートを生成します。この経路は「AXI タイムアウトによる失敗の根本原因は何か」のように、複数のファイルにまたがる、より詳細な分析が必要な質問に適しています。 仕組み たとえば、エンジニアが Amazon Quick で「昨夜はいくつのシミュレーションが失敗したか。最も多いエラーは何か」と質問したとします。Amazon Quick はこの質問を AgentCore 上の MCP エージェントに渡します。エージェントはツールを使い、リグレッションテストの結果を格納したディレクトリの一覧を取得します。続いて、終了コードが 0 以外のログファイルを特定し、関連するシミュレーションログと LSF のログを読み込みます。複数のファイルにわたるエラーのパターンを突き合わせ、失敗の種類ごとに件数と影響を受けたモジュールをまとめて返します。エージェントはさらなる質問にも回答できます。この経路では事前に作成したインデックスではなく、問い合わせの時点で S3 アクセスポイントを介して FSx for ONTAP のファイルを読み込みます。そのため、回答には問い合わせ時点のファイルシステム上のデータが反映されます（ 図 2 ）。 図 2: トリアージに関する質問例と、AI が生成した回答を表示した Amazon Quick のチャット画面 すべてのコンポーネントはお客様の仮想プライベートクラウド（VPC）内で動作します。S3 アクセスポイントは AWS Identity and Access Management（IAM） のポリシーと、ファイルシステムのアクセス権限の両方を適用します。ログデータを読み取れるのは許可されたサービスに限られます。この構成では、書き込みは NFS 経由に限定されます。 S3 アクセスポイントにより、AWS の分析サービスや AI サービスから S3 API でログデータにアクセスできます。AgentCore と Amazon Quick はこのパターンの実装例の一つです。 Amazon Athena 、 AWS Glue 、独自に開発した Lambda 関数などのサービスも、同じアクセスポイントを介して同じデータにアクセスできます。 ダッシュボードとワークフローの自動化 エージェントによるログ分析に用いる S3 アクセスポイントは、ダッシュボードによる可視化とワークフローのスケジュール実行にも利用できます。 リグレッションテストの状況を可視化するダッシュボード Amazon Quick Sight は S3 アクセスポイントを介して、FSx for ONTAP から構造化された集計データを読み込めます。検証チームのマネージャーは毎朝ブラウザでダッシュボードを開くだけで、スクリプトを実行せずに夜間のリグレッションテストの現状を把握できます。ダッシュボードにはモジュールごとのパス／フェイル率、失敗の種類の内訳、カバレッジのヒートマップ、リソース使用率の推移が表示されます。ファイルシステムに新しいリグレッションテストのデータが追加されると、ダッシュボードは自動的に更新されます。 図 3: モジュールごとのパス／フェイルと失敗の種類の内訳を表示した Amazon Quick Sight のリグレッションテストのダッシュボード ワークフローのスケジュール実行 Amazon Quick Automate を使うと、毎晩のリグレッションテストの完了後にワークフローをスケジュール実行できます。たとえば、毎日のトリアージを自動化するワークフロー（ 図 4 ）では、チームの始業前に失敗の概要をまとめてメールで送信可能です。カバレッジを監視するワークフローでは、モジュールのカバレッジが設定したしきい値を下回った時点でアラートを送信可能です。ライセンスを監視するワークフローでは、繰り返されるチェックアウトの失敗を検知し、インフラチームに通知可能です。 これらのワークフローも S3 アクセスポイントを介して FSx for ONTAP から同じログデータを読み込みます。エンジニアは独自のスクリプトの開発や cron ジョブの保守を行う必要がありません。 図 4: 朝のトリアージレポートを自動生成する Amazon Quick Flows のフロー 検証のトリアージ以外のユースケース 同じアーキテクチャは NFS ストレージにログデータを出力するほかの EDA ワークフローにも適用できます。たとえば、論理合成のタイミングレポートの分析、物理検証（DRC/LVS）の結果、電力解析の出力、設計ドキュメントの生成です。構造化または半構造化されたログを FSx for ONTAP に書き込むワークフローであれば、このパターンを活用できます。 まとめ EDA の検証チームは毎晩大量のログデータを生成します。このデータは高性能な NFS ストレージに格納されていますが、分析は手作業のままでした。FSx for ONTAP の S3 アクセスポイントを使えば、AI サービスから S3 API で同じデータにアクセスできます。データのコピーや移動は不要です。AgentCore と Amazon Quick を組み合わせると、エンジニアはリグレッションテストについて自然言語で質問できます。回答はシミュレーション、コンパイル、ジョブスケジューラーの各ログを突き合わせて分析したものです。これまで 45～60 分を要していた毎日のトリアージは、数分以内での完了が可能になります。ログデータは FSx for ONTAP に保持したまま、NFS と S3 API の両方から同時にアクセスできます。S3 アクセスポイントは AI サービスが同じデータを活用して有益な知見を得るための、独立した読み取り専用の経路となります。その結果、検証クロージャーの短縮とエンジニアの生産性向上につながります。チームは何時間もかけてバグのトリアージを行うのではなく、バグの修正から 1 日を始められます。 このアーキテクチャを実際に試すには、FSx for ONTAP と S3 アクセスポイントを扱う ワークショップ について AWS のアカウントチームにお問い合わせください。このソリューションで使用するサービスの詳細は、次の資料を参照してください。 Amazon S3 アクセスポイントを介したデータへのアクセス Enabling AI-powered analytics on enterprise file data: Configuring S3 Access Points for Amazon FSx for NetApp ONTAP with Active Directory Amazon Bedrock AgentCore 開発者ガイド Amazon Quick ユーザーガイド Vinayak Datar Vinayak Datar 氏はサンフランシスコ・ベイエリアを拠点とする AWS の Senior Customer Solutions Manager です。半導体業界のお客様が AWS のサービスを使って EDA ワークロードを移行し、モダナイズする取り組みを支援しています。「GenAI Ambassador」として、Amazon Quick や Amazon Bedrock をはじめとする AWS の生成 AI サービスを使ったソリューションの導入を推進しています。 Ratna Dasari Ratna Dasari 氏は AWS の Senior Solutions Architect です。半導体業界のお客様と密に連携し、クラウド活用とデジタルトランスフォーメーションの戦略の策定と実行を支援しています。半導体業界で 20 年以上の経験を持ち、その深い業界知見をお客様の支援に生かしています。革新的なソリューションを主導・設計し、大規模に提供することでビジネス価値を創出してきた豊富な経験を有しています。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。

お盆ど真ん中に100人超！社内イベント「Codex祭り Sol Ultra」を開催！ Codex a ...

数字の中には、しばらく向き合ってみないと想像しにくいものもあります。2026 年 10 月 5 日週、プライムデー 2026 のメトリクスを公開しましたが、私が心に残ったのは 2.3 京件です。これは、イベント中に Amazon ElastiCache がピークに達した毎日のリクエスト数です。プライムデーは6月に開催されたため、この投稿はいつも振り返りとして公開されており、その時間差が読む価値を生む要因の1つです。数字があなたのもとに届く頃には、それが実際に起きたという唯一の証拠は、何も問題が起きなかったということだけです。 その週の残りは別の方向に進みました。より小さく、より安く、より制約のある方向です。Claude Haiku 5.5 が Amazon Bedrock で利用可能になり、Haiku 4.5 と比べて約 75 パーセントのコスト削減を実現しました。Amazon Nova 2.5 Sonic は音声エージェントの応答をより素早くし、Strands Box はエージェントが実行できることに対して明確な境界を設けるために登場しました。それでは、10 月 13 日週の AWS ニュースを見ていきましょう… 主なトピック All the numbers: Amazon Prime Day 2026 powered by AWS は、2016 年まで遡る伝統の最新版であり、その規模は依然として頭の中に収めるのが難しいものです。Prime Day の 4 日間で、 Amazon DynamoDB は 59 兆件を超えるリクエストを処理し、ピーク時には 1 秒あたり 1 億 9,200 万件のリクエストに達しましたが、一桁ミリ秒のレスポンスを維持しました。 AWS Lambda は 1 日あたり 2.3 兆件を超える呼び出しを処理しました。 Amazon EBS は 24.8 兆回を超える I/O 操作のピークに達し、毎日 1 エクサバイト以上のデータを転送しました。 Amazon ECS は AWS Fargate 上で 1 日平均 1 億 5,830 万タスクを起動し、前年比 47.7 パーセント増となり、 AWS Graviton は Amazon.com が使用した Amazon EC2 コンピューティングの最大 49 パーセントを支えました。 ただし、私が何度も立ち返ってしまう数字は、スループットの記録ではありません。チームはイベントに先立ち、44,000 件を超える AWS Fault Injection Service 実験を実施しました。これは 2025 年に実施した数の 6 倍以上です。これらは意図的に注入された障害であり、数か月前から仕込まれることで、上記の何兆件ものリクエストが普通の買い物の午後に変わるのです。自社のピークタイムに備えているなら、 AWS Countdown Premium はまさにそのような計画のために作られています。 10 月 5 日週のリリース 10 月 5 日週のリリースのうち、私が注目したものをいくつかご紹介します。 Claude Haiku 5.5 が AWS で利用できるようになりました — Amazon Bedrock と Claude Platform on AWS で、Claude 5.5 ファミリーの最速モデルを利用できるようになりました。ほとんどのタスクで、Claude Haiku 4.5 よりも約 75% 少なくてすみます。effort コントロールを備えた初の Haiku であり、ワークロード全体で 1 つの設定を固定するのではなく、タスクごとにコストと知能のバランスを調整できます。Claude Opus 5.5 と自然に組み合わせられます。Opus が計画を立てて判断を下し、Haiku は高速で安価なため、ルーティング、分類、多数のファイルにまたがる小さなコード変更のために、多くの Haiku サブエージェントを並列で実行できます。 音声エージェント用 Amazon Nova 2.5 Sonic — 音声から音声への Amazon Nova モデルでリアルタイム音声エージェントを構築できるようになりました。これにより、推論、指示の追跡、ツール呼び出しの精度が向上し、レイテンシーも低くなります。この組み合わせはマルチステップの作業に重要です。サポートエージェントは 1 つの会話の中で注文を検索し、返品資格を確認し、返品を開始できます。7 言語での表現力豊かな音声、制御可能なターンテイキング、256K のコンテキストウィンドウを維持し、 now generally available となった Strands Bidi Agents と組み合わせることで、数行のコードで本番用の音声エージェントを起動できます。 Amazon GuardDuty RDS Protection now detects data exfiltration and destruction – Amazon GuardDuty は、 Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL において、ログインの異常を超えてクエリ自体を監視するようになりました。データアクティビティ向け RDS Protection は行動ベースラインを構築し、ML ベースの異常検知と脅威インテリジェンスを組み合わせて異常なデータアクセスを検出します。エージェント、追加インフラストラクチャ、データベース設定の変更は不要です。これにより実際のギャップが埋まります。攻撃者がフィッシングや設定ミスにより有効な認証情報を入手すると、そのクエリはあなたのアプリケーションのクエリと見分けがつかなくなる可能性があります。 AWS Lambda supports OAuth for self-managed Apache Kafka event sources – Amazon Cognito や Okta などのエンタープライズ ID プロバイダーを通じて Lambda Kafka コンシューマーを認証できるようになりました。イベントソースマッピングは以前、SASL/PLAIN、SASL/SCRAM、mTLS のみをサポートしていたため、規制業界のチームは Kafka ESM をまったく使用できませんでした。これにより、Kafka ESM の自動スケーリング、バッチ処理、エラー処理、イベントフィルタリングを、他のあらゆる場所で適用しているのと同じ ID ガバナンスとともに利用できます。セルフホスト型クラスターおよび Confluent Cloud、Aiven、Redpanda などのマネージドサービスで動作します。 Amazon Redshift adds Apache Iceberg materialized views – 高コストな結合と集計を Amazon Redshift で一度事前計算し、その結果を Amazon S3 に Iceberg テーブルとして保存し、 AWS Glue Data Catalog に登録できるようになりました。使い慣れた SQL で作成でき、結果は Amazon Athena 、Apache Spark、Trino、Snowflake など、Iceberg 互換のあらゆるエンジンからすぐにクエリできます。Redshift は変更された部分のみを再計算することで、これらを最新の状態に保ちます。詳細を知りたい場合は、 AWS Big Data ブログの優れた深掘り記事 をご覧ください。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんが興味を持つと思われるその他の記事とリソースをいくつかご紹介します。 Introducing Strands Box: AI agent sandboxes powered by Dogwood – より多くの人が、すべてのステップを承認することなくエージェントにシェルコマンドを実行させたり API を呼び出させたりするようになると、分離だけでは十分ではなくなります。 Strands Box は、OS レベルの封じ込めと Dogwood で記述されたきめ細かいポリシーを組み合わせたオープンソースサンドボックス (Apache 2.0、開発者プレビュー) であり、権限をエージェントがすでに行った内容に依存させることができます。「エージェントにインシデントチャンネルへの投稿を許可するが、10 分間に 3 回まで」と指定し、それをエージェントのプロセス外から強制できます。また、実際の認証情報をエグレスゲートウェイで付与することで、エージェントの環境から認証情報を排除します。 AWS Continuum は、自律型コードセキュリティの新しい標準を打ち立てました – このテーマに関連して、AWS Continuum for Penetration Testing がパブリックプレビューで CI/CD パイプラインに統合されるようになりました 。これにより、ペネトレーションテストは外部で起こることではなく、デプロイ時のイベントに変わりました。開発者は、重大度、影響を受けるエンドポイント、修復ガイダンスを含む検出結果をパイプラインの出力で直接受け取り、パイプラインが修正を検証するために再テストします。 How Postman runs Agent Mode for 40 million developers on Amazon Bedrock – 非常に大規模な開発者オーディエンスにサービスを提供する機能の背後にあるアーキテクチャの紹介です。エージェント機能をデモから実際のトラフィックに耐えうるものへ移行する予定なら、読む価値があります。 ICYMI: 2026 年 9 月に AI ビルダー向けに登場したもの – 数多くのモデルリリースがあった月を見逃した方は、これが一か所でまとめてキャッチアップできる tidy な記事です。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – re:Invent が 11 月 30 日から 12 月 4 日までラスベガスに戻って開催され、予約席が現在受付中です。セッションカタログが公開されたので、 登録 して、チャークトーク、ワークショップ、ビルダーセッションの席が埋まる前に確保しましょう。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンスですが、今はまさに多忙な時期を迎えています。今後の開催地には、 サンフランシスコ (10 月 13 日)、 マイアミ (10 月 14 日)、 ブリスベン (10 月 16 日)、 ケープタウン (10 月 16 日)、 マルタ (10 月 16 日)、 ムンバイ (10 月 17 日) が含まれます。ここブラジルでは、 コミュニティカレンダー に年末までにさらに多くの開催回が追加される予定です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 10 月 13 日週のニュースは以上です。10 月 19 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。