みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 10 月に入り、朝晩はすっかり涼しくなってきました。1 週間で Kiro の使い方を学ぶオンラインチャレンジ Kiro University Challenge は、最終課題の締切が日本時間 10 月 6 日 15:59 に迫っています。最大 5,250 の Kiro クレジットを獲得できるチャンスなので、まだ提出していない方は最後のひと頑張りをどうぞ。 お昼休みの 30 分で最新情報を知れる「 もぐもぐAWS 」では、AI をテーマにした会が 10 月に予定されていますので是非ご参加ください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、9 月 28 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「REST API を Amazon Bedrock AgentCore Gateway で MCP サーバー化する ― オリックス「PATPOST」での取り組み」を公開 オリックス株式会社様は、生成 AI を活用したビジネス文書管理サービス「PATPOST」を約 2,300 社に提供しています。利用者ごとにデータを出し分ける既存 API を、どう AI エージェントに開放するかが課題でした。そこで、 Amazon Bedrock AgentCore Gateway で REST API を改修せずに MCP サーバー化し、 Interceptor 機能で利用者ごとの API キーを引き渡す構成を PoC で検証しました。その結果、データの境界を保ったまま MCP 化でき、Lambda Target でツールを集約すると消費トークンも大幅に減ることを確認しています。 ブログ記事「【開催報告】組み込みソフトウェア開発でも AI エージェントは活用できる ─ 日立産業制御ソリューションズ様とのワークショップ」を公開 株式会社日立産業制御ソリューションズ様の組み込みソフトウェアエンジニア 102 名に、 Kiro を開発ライフサイクル全体に適用するハンズオンワークショップ を実施した開催報告です。HVAC 制御システムを題材に、既存コードの読み解きから仕様化、実装、テストまでを体験し、GitLab の Issue に指示を書いて経過を残す進め方も紹介しています。AI エージェントが実装を速くするだけの道具ではないことが伝わる内容です。 ブログ記事「OCC が AWS 上に構築したエージェンティック AI 調査ソリューションでセキュリティオペレーションを強化」を公開 世界最大の株式デリバティブ清算機関である The Options Clearing Corporation (OCC) が、Amazon Bedrock で構築したセキュリティ調査エージェント「SOC エージェント」の導入を発表しました。この記事では、SIEM のデータに対して調査方針の立案から証拠の取得、評価までをエージェンティックループで進め、説明可能かつ監査可能な結果を返す仕組みを紹介しています。規制業界の方に参考になる設計です。 ブログ記事「Kiro workflows のご紹介」を公開 少ない監督で、人が見守る手間を減らしながら複雑なタスクを最後までやり遂げる Kiro workflows が発表されました。この記事では、エージェントステップやループ、並列ブランチで構成されるグラフをモデルが定義し、Kiro ランタイムが各ステップを独立したセッションで確実に実行する仕組みとレシピの書き方を紹介しています。Kiro チーム自身が数千回の workflow を回して Kiro を開発しているという話も興味深いです。 ブログ記事「Claude Opus 5.5 が Kiro で利用可能になりました」を公開 Anthropic 社の Claude Opus 5.5 が、2026 年 9 月 28 日より Kiro IDE、CLI、Crew、Web のすべてで利用可能になりました。この記事では、変更前に根本原因を突き止め、作業しながら自身の仕事を検証する Opus 5.5 の特徴と提供状況を紹介しています。Amazon 社内のベンチマークでは Opus 5 よりツール呼び出しを約 40% 減らし、トークン消費を半分に抑えたとのことです。 ブログ記事「Kiro で SAP モダナイゼーションを加速」を公開 SAP ABAP、SAP BW、SAP PI/PO のモダナイゼーションを単一のプロンプトで一括実行できる、Kiro ベースのサンプルエージェントが公開されました。この記事では、SAP S/4HANA 準拠への変換やクリーンコア化、仕様書生成、単体テスト自動化といったユースケースと、80 以上のルールを備えたステアリングファイルなどのセーフガードを紹介しています。2027 年 12 月の標準サポート終了を控えた SAP ユーザーは要チェックです。 ブログ記事「Kiro で SAP モダナイゼーションを加速 – ベンチマークとユースケース」を公開 上記のサンプルエージェントについて、社内ベンチマークとパートナー・お客様の成果を詳しく紹介する続編です。88 オブジェクトの ABAP コードを 4.5 時間で SAP S/4HANA 準拠に変換して工数を 87% 削減したほか、22 の SAP PI/PO インターフェースを約 2 時間で SAP BTP Integration Suite に変換した結果などが、使用した Kiro クレジット数とともに公開されています。移行計画の見積もりにも役立ちます。 ブログ記事「AWS と SAP、SAP Business AI Platform の提供拡大に向け協業を強化」を公開 AWS は SAP Sapphire 2026 で、SAP との 5 年間の戦略的協業契約を発表しました。この記事では、SAP Business AI Platform のプラットフォームサービスと SAP Business Data Cloud を、日本を含む 7 つの新しい AWS リージョンに 2026 年 12 月から段階的に展開する計画などを紹介しています。データレジデンシー要件のある国内の SAP ユーザーには嬉しいニュースです。 ブログ記事「Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1」を公開 Amazon Bedrock Guardrails の自動推論チェックは、形式的検証の技術を使って AI の出力がビジネスルールに準拠しているかを数学的に検証する機能です。この記事では、自然言語のドキュメントから自動推論ポリシーを作成・改善する方法や、テストケースの設計、注釈によるポリシー改善など、技術的な基礎と実装方法を解説しています。規制産業でハルシネーション対策を検討している方におすすめです。 ブログ記事「自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装」を公開 自動推論チェックのフィードバックを使って LLM の回答を反復的に書き換え、必要に応じてユーザーに確認の質問を行うオープンソースのチャットボットが公開されています。この記事では、検証結果の種類ごとに書き換えや質問を判断するループの仕組みと、監査ログを含むバックエンドの構成を詳しく解説しています。規制のある環境で生成 AI を使いたい方は、上のパート 1 とあわせて読むと理解が深まります。 ブログ記事「Amazon S3 Vectors がメタデータの pre-filtering に対応し、フィルター付き検索の再現率が向上」を公開 Amazon S3 Vectors で、類似性検索の前にメタデータフィルターを評価する pre-filtering が利用可能になりました。この記事では、絞り込みの強いフィルターで取得できる一致ベクトルが最大 5 倍に増える仕組みや、前方一致の演算子 $startsWith、CLI を使った始め方を紹介しています。マルチテナントの RAG やエージェントの検索精度に悩んでいる方は要チェックです。 ブログ記事「HR Open Standardsを活用したHRデータ統合のためのオントロジー設計」を公開 「子会社を全部挙げる」「空席のポジションを探す」といった質問は、ベクトル類似検索ベースの RAG が苦手とするものです。この記事では、 HR Open Standards をもとに共通オントロジーを設計し、Amazon Neptune Serverless と SPARQL テンプレートで検索した結果を Amazon Bedrock で回答文に整形する構成を解説しています。構造化データに強い質問応答を作りたい方の参考になります。 ブログ記事「AWS DevOps Agent Skills を作成するためのベストプラクティス」を公開 AWS DevOps Agent の Skills は、チームの調査ノウハウを再利用可能なプレイブックとして蓄積し、誰がオンコールでも一貫した調査を行えるようにする仕組みです。この記事では、エージェント指示との使い分けや起動を左右する description の書き方、複数 Skills の組み合わせ方、見落としやすい失敗パターンまでを紹介しています。Skills を書いたのに使われない、と悩んでいる方に読んでほしい内容です。 ブログ記事「今月の AWS オブザーバビリティ: 2026 年 8 月と 9 月」を公開 8 月と 9 月のオブザーバビリティ関連のアップデートをまとめた記事です。AI ファーストのオブザーバビリティを提供する Amazon CloudWatch Omni の一般提供開始をはじめ、AWS CloudTrail と Amazon Q Console の統合による自然言語でのアクティビティ調査、アラームのウォームアップ期間などが紹介されています。AWS DevOps Agent 関連の記事もまとまっているので、運用に AI を取り入れたい方はぜひ。 ブログ記事「【開催報告】AI ペルソナワークショップ — 自社だけの AI ペルソナを作って、試してみよう」を公開 2026 年 9 月 15 日に、マーケティングや事業企画に携わる 7 社 19 名の皆様と、自社データから AI ペルソナを作って試すワークショップを開催しました。この記事では、GitHub で公開しているサンプル実装 sample-ai-persona を使い、ペルソナへのインタビューやペルソナ同士の議論、評価からネクストアクションまでを半日で体験した様子をレポートしています。顧客調査を素早く回したい方はサンプルを試してみてください。 ブログ記事「【開催報告】AWS Future of Money ～AI × ブロックチェーンが創る新金融エコシステム～」を公開 2026 年 8 月 19 日に、金融業界のお客様約 45 名を対象としたイベント「AWS Future of Money」を開催しました。この記事では、野村ホールディングス様や JPYC 様のご講演に加え、AI エージェントが購買まで完結する「エージェンティック・コマース」や AI エージェント向け決済規格への対応など、AI とブロックチェーンが変える決済の未来についての議論をレポートしています。 ブログ記事「送配電事業におけるクラウド活用と AI 技術の最前線 ― T&D エグゼクティブ・ラウンドテーブル 開催報告」を公開 2026 年 8 月 7 日に、送配電事業者 32 社・組織から 61 名にご参加いただいた T&D エグゼクティブ・ラウンドテーブルの開催報告です。量子時代のセキュリティに加え、100 万台超のネットワーク機器の障害対応を AI エージェントで自律化した NTT ドコモ様の取り組みなど、通信業界の AI 活用事例が紹介されています。業界をまたいだ「自律運用」の考え方が参考になります。 ブログ記事「【開催報告】KubeCon + CloudNativeCon Japan 2026 – AWS ブース：Amazon EKS の最新ソリューションに関するデモセッションを実施」を公開 2026 年 7 月 29 日から 2 日間開催された KubeCon + CloudNativeCon Japan 2026 の AWS ブースで実施した、12 のデモセッションの資料が公開されました。Amazon EKS Auto Mode での LLM 駆動エージェントの運用やモデルロードの高速化、AWS DevOps Agent によるインシデント対応、EKS 向け Agent Skills など、AI 関連のテーマも多く含まれています。 サービスアップデート Claude Sonnet 5.5 が AWS で利用可能に Anthropic 社の Claude Sonnet 5.5 が、Amazon Bedrock と Claude Platform on AWS で利用可能になりました。Sonnet 5 からコーディングとナレッジワークの性能が大きく向上し、多くの作業でタスクあたりのコストを抑えつつ高速に応答します。1 枚資料や図、スライドの作成、スプレッドシートの整理など、そのまま共有できるアウトプットも得意です。同日に AWS GovCloud (US) でも提供が始まっています。詳細は こちらのドキュメント をご参照ください。 OpenAI GPT-6.1 Sol が Amazon Bedrock で一般提供開始 OpenAI 社の GPT-6.1 Sol が Amazon Bedrock で一般提供開始されました。GPT-6 Sol のアップグレード版で、エージェント型コーディングやコンピュータ操作、プロフェッショナルな業務で高い性能を発揮します。OpenAI 社によると、GPT-6 Astra に迫る性能をおよそ 5 分の 1 のコストで実現しており、明示的なプロンプトキャッシュにも対応しているため、コンテキストを繰り返し使うエージェントを低コストで動かせます。 Amazon Bedrock Managed Agents, powered by OpenAI がプレビュー開始 AWS と OpenAI 社が共同開発した Amazon Bedrock Managed Agents (BMA) がプレビューで利用可能になりました。OpenAI の Agents API をベースに AWS ネイティブに作られており、状態の保持やツールの選択・実行、コード実行、複数ステップの調整をマネージドで任せられます。各エージェントは独自の IAM ロールで動作し、重要なアクションの前の人による承認や AWS CloudTrail への記録にも対応しています。詳細は こちらのドキュメント をご参照ください。 OpenAI GPT-6 Astra が Amazon Bedrock で UltraFast モードをサポート Amazon Bedrock の GPT-6 Astra で、速度を重視するワークロード向けのプレミアムな速度ティア UltraFast モードが利用可能になりました。OpenAI 社によると、API での推論が最大 6 倍高速になり、最大で毎秒 300 トークンを出力します。リアルタイムのコーディングアシスタントや対話型エージェント、顧客向けのチャット体験など、応答の速さと品質の両方が求められる用途に向いています。 Grok 4.7 が Amazon Bedrock で利用可能に SpaceXAI の Grok 4.7 が Amazon Bedrock で利用可能になりました。コーディングやエージェントタスク、ナレッジワーク向けのフロンティアモデルで、Grok 4.6 から複数形式が混在するドキュメントの扱いや、計画とエラー回復を伴うリポジトリ規模のコーディングが改善されています。フォーム入力やポータル操作をこなすブラウザ操作エージェントも強化されており、US Geo とグローバルのクロスリージョン推論で利用できます。 Amazon Bedrock の Claude モデルがインド、韓国、シンガポールで利用可能に Amazon Bedrock で、インドでは Claude Opus 5、Claude Sonnet 5、Claude Haiku 4.5、韓国では Claude Opus 5 と Claude Sonnet 5、シンガポールでは Claude Sonnet 5 が利用可能になりました。インドではムンバイとハイデラバードにまたがる地理的クロスリージョン推論、韓国とシンガポールではリージョン内推論で提供されます。 Amazon Bedrock が英国 (ロンドン) リージョンで Claude モデルのリージョン内推論をサポート Amazon Bedrock のロンドンリージョンで、Claude Opus 5.5 と Claude Sonnet 5 のリージョン内推論が利用可能になりました。推論リクエストとデータは呼び出したリージョン内で処理され、リージョン外に出ることはありません。英国内でのデータ処理が求められる金融サービスや医療、公共部門のお客様が、最新の Claude モデルを大規模に活用しやすくなります。 Amazon Bedrock AgentCore Gateway が VPC エンドポイント向けにプライベート TLS 証明書をサポート Amazon Bedrock AgentCore Gateway で、プライベート認証局が署名した TLS 証明書を使うターゲットに接続できるようになりました。MCP サーバー、OpenAPI、HTTP プロキシの各ターゲットで利用でき、Amazon VPC Lattice を使った VPC 内のプライベートエンドポイントに、中間の Application Load Balancer なしで直接接続できます。社内の私設 CA で運用しているシステムをエージェントにつなぎたい場合に便利です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Unified Studio が Iceberg REST Catalog 接続と Amazon DocumentDB の IAM 認証をサポート Amazon SageMaker Unified Studio で、Snowflake Open Catalog や Databricks Unity Catalog など Iceberg REST 仕様に準拠した外部カタログへの接続と、Amazon DocumentDB への IAM 認証による接続がサポートされました。外部カタログのテーブルを Visual ETL やノートブックから読み書きでき、DocumentDB にはパスワードを保存せずに接続できます。ML や生成 AI の開発で使うデータへのアクセスがシンプルになります。 AWS MCP Server が東京を含む 6 つのリージョンで新たに利用可能に AI コーディングエージェントに AWS API への単一のインターフェースを提供するマネージド MCP サーバー、AWS MCP Server が東京、シンガポール、シドニー、アイルランド、ロンドン、オレゴンの 6 リージョンで新たに利用可能になりました。開発者に近いリージョンで低レイテンシに使えるほか、リクエストデータをリージョン内にとどめられるため、データレジデンシーの要件にも対応しやすくなります。国内のお客様には待望の東京リージョン対応です。詳細は こちらのドキュメント をご参照ください。 AWS CLI が Agent Toolkit for AWS のスキルの一括更新とバージョン確認をサポート AWS CLI の Agent Toolkit for AWS 向けコマンドに、インストール済みのスキルを最新版と比較する check-skill-updates と、古くなったスキルをまとめて更新する update-skill --all が追加されました。これまでスキルを 1 つずつ確認・更新する必要がありましたが、Kiro や Claude Code などのコーディングエージェントが常に最新のガイダンスで動くよう、1 コマンドで揃えられます。AWS CLI 2.37.0 以降で利用できます。 AWS Well-Architected Agent がプレビュー開始 AWS Trusted Advisor と AWS Well-Architected Tool の次世代版となる AI 搭載サービス、AWS Well-Architected Agent がプレビューで利用可能になりました。コスト、セキュリティ、パフォーマンス、信頼性の観点で AWS インフラを分析し、ビジネス目標に応じて優先度付けした推奨事項を SSM ランブックや CLI スクリプトとともに提示します。IaC テンプレートもレビューし、修正案まで返してくれます。詳細は こちらのドキュメント をご参照ください。 Amazon S3 Vectors がメタデータの pre-filtering に対応し、フィルター付き検索の再現率が最大 5 倍に Amazon S3 Vectors で、類似性検索の前にメタデータフィルターを評価する pre-filtering がサポートされ、絞り込みの強いフィルターで一致するベクトルを最大 5 倍多く返せるようになりました。パスや URL の前方一致に使える $startsWith 演算子も追加されています。新しいベクトルバケットのインデックスではデフォルトで有効になり、既存のインデックスも API で切り替えられます。追加料金はかからず、RAG やエージェントの検索結果がより網羅的になります。 Amazon Quick のアプリでデータセットのライブデータを利用可能に Amazon Quick で、Quick のデータセットのライブデータを直接使うアプリケーションを構築できるようになりました。アプリビルダーのチャットエージェントにデータセット名と作りたいものを自然言語で伝えるだけで、常に最新の KPI やグラフを表示し、申請や承認といった業務アクションまでこなせるアプリを作れます。アプリの利用者には各自の権限が適用され、設定済みの行・列レベルのセキュリティもそのまま有効です。 Amazon Aurora Serverless がエージェント型 AI などのバースト性の高いワークロード向けにより高速にスケール Amazon Aurora Serverless が、1 秒以内に最大 16 ACU を追加し、ワークロードの増加に合わせて最大 256 ACU までスケールできるようになりました。処理が終われば自動的にゼロまでスケールダウンするため、アクティビティの急増と長いアイドル時間を繰り返すエージェント型 AI アプリケーションのデータベースに特に向いています。プラットフォームバージョン 3 または 4 のクラスターではデフォルトで有効で、設定変更は不要です。 AWS Marketplace が従量課金メータリング統合向けの AI エージェントスキルを提供開始 AWS Marketplace の出品者向けに、従量課金型 SaaS のメータリング統合を AI コーディングアシスタントの中で構築・デプロイ・検証できるエージェントスキルが一般提供されました。料金モデルのヒアリングから適切な API の推奨、統合コードと CloudFormation スタックの生成、本番前のエンドツーエンドテストまでをガイドしてくれます。後から請求漏れとして発覚しがちなミスを事前に防げ、AWS MCP Server 経由で Kiro などから利用できます。 AWS Continuum for Penetration Testing が 6 つのリージョンで新たに利用可能に Web アプリケーションや API に対するペネトレーションテストを実施できるマネージドサービス、AWS Continuum for Penetration Testing (AWS Security Agent) が、ソウル、カナダ (モントリオール)、ロンドン、米国東部 (オハイオ)、パリ、ストックホルムの 6 リージョンで新たに利用可能になりました。本番環境に近いリージョンでテストを実行でき、データレジデンシーの要件を満たしながらセキュリティテストを継続できます。 Kiro CLI 2.25 がチャットからの Powers 管理と V3 の出力スタイル選択に対応 Kiro CLI 2.25 がリリースされました。V3 セッションで /powers install や /powers uninstall を使い、チャットの中から Powers を追加・削除できるようになり、追加した Powers はそのまま現在のセッションで使えます。また、/settings から V3 の応答の出力スタイルを選べるようになったほか、セッション終了時に実行される SessionEnd フックが追加され、後片付けの自動化もしやすくなりました。 Kiro IDE 1.2 がバックグラウンドで動く Workflows と信頼されていないワークスペースの保護強化に対応 Kiro IDE 1.2 がリリースされました。複数ステップの計画をバックグラウンドで実行する Workflows が追加され、チャット上部の Workflows エリアから進捗の確認や一時停止、再開ができます。また、エージェントがエージェント設定やフック、Powers、Workflow レシピを変更する前に必ず確認するようになり、信頼されていないワークスペースではコマンドの実行ごとに確認を求めるなど、安全性も強化されています。 Kiro CLI 2.26 / 2.27 で Workflows とステアリングのライブコンテキスト参照に対応 2.26 では V3 セッションで Workflows を有効化し、/workflow run でレシピを実行できるようになったほか、信頼されていないワークスペースでの MCP ツールやシェルの承認チェックが強化されました。2.27 では、ステアリングから行範囲の指定や #[[folder:…]] でファイルやフォルダの内容を読み込めるようになり、保存したプロンプトをスラッシュコマンドとして呼び出せます。Classic モードには非推奨の通知が出るようになったので、利用中の方は移行をご検討ください。 Kiro Web のクラウドセッションで Workflows が利用可能に Kiro Web のクラウドセッションで、複数ステップのエージェント計画をバックグラウンドで実行する Workflows がオプトインで利用可能になりました。会話で目的を伝えると Kiro が Workflow を提案して起動し、サイドパネルから各ステップの状態確認や方向修正、途中の質問への回答ができます。investigate、feature-pipeline、publish-pr の 3 つのレシピが同梱されており、自作のレシピもアップロードできます。 Claude Sonnet 5.5 が Kiro で利用可能に Anthropic 社の Claude Sonnet 5.5 が、Kiro IDE、CLI、Crew、Web で実験的サポートとして利用可能になりました。Sonnet 5 より出力が 30% 以上高速になり、実際のナレッジワークでは Opus 5.5 に迫る性能を発揮します。100 万トークンのコンテキストウィンドウに対応し、クレジット乗数は 1.3 倍です。Pro 以上のプランで、us-east-1 と eu-central-1 から利用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

2026 年 10 月 1 日、 AWS Well-Architected Agent のパブリックプレビューを発表しました。これは、AWS 環境を分析して、アプリケーションのコスト、セキュリティ、パフォーマンス、およびレジリエンスを向上させるための、対象を絞った、状況に応じた推奨事項を提供する AI を活用したサービスです。AWS Well-Architected Agent はお客様のインフラストラクチャを分析し、独自のビジネス目標を理解し、すぐに実装できる修正を含む状況に応じた推奨事項を提供します。手動の監査や一般的なチェックリストに頼ることなく、状況に応じた最適化を実現します。 エージェントは、経験豊富なクラウドアーキテクトが行うように環境を評価します。使用率メトリクス、リソース構成、アプリケーショントポロジを自動的に相関させ、65 以上の AWS のサービス全体で Well-Architected ベストプラクティスと照合して分析します。宣言されたビジネス目標に沿った推奨事項を生成し、すべての検出結果を含む実装パッケージを提供し、複数の柱にまたがるトレードオフを明らかにするため、検出結果の修正が容易になります。 このサービスの主な特徴は以下の 3 つです: 目標に沿ったインテリジェンス : AWS Well-Architected Agent は、単調で差別化されていない検出結果を、状況に応じた、優先順位付けされた推奨事項に置き換えます。お客様はビジネス目標を宣言し、アプリケーションのコンテキストを共有します。エージェントは、それらの目標に対する影響と労力に基づいて推奨事項を自動的に生成し、優先順位を付けます。 3 段階の推奨事項 : AWS Well-Architected Agent は、特定の費用的影響 (該当する場合) と段階を追った改善を伴う個別のリソース調査結果、お客様のアプリケーションを対象とする複数のリソースにわたる検出結果、および Well-Architected のベストプラクティスに合わせるために必要な Infrastructure as Code (IaC) のコード変更を含む幅広いアーキテクチャパターンと設計を提供します。 修復でのオプション性 : コンソールのチュートリアル、アーキテクチャレベルの推奨事項に合わせた最新の IaC の変更、 AWS コマンドラインインターフェイス (AWS CLI) コマンドなど、環境に合わせた完全な実装手順により、修正方法を選択できます。 AWS Well-Architected Agent の実行 開始するには、エージェントプロファイルを作成して、Well-Architected Agent がアクセスできる範囲を定義して推奨事項を提供し、リソースにアクセスするための IAMロール のセットアップを完了し、アーキテクチャレビューを実施し、推奨事項を修正します。 エージェントプロファイルの作成 AWS Well-Architected コンソール で、[ Well-Architected Agent の使用を開始する ] を選択します。監視する AWS アカウントとアプリケーション、重点的に取り組む最適化の柱、および必要なアクセス許可を指定するエージェントプロファイルを定義できます。 AWS アカウントまたは AWS リージョンを選択して、ビジネスにとって最も重要な柱を監視および最適化できます。また、コストの最適化、パフォーマンス、レジリエンス、セキュリティといった各柱の目標を設定することもできます。 AWS 環境のエージェントにアクセスできるようにするには、エージェントがリソース構成、使用率メトリクス、アプリケーショントポロジを読み取るために使用するカスタマーマネージド IAM ロールをプロビジョニングします。詳細については、 AWS Well-Architected Agent の IAM 前提条件 をご覧ください。 [ 使用を開始する ] を選択すると、エージェントはエージェントプロファイルを作成します。リソースとアプリケーションの推奨事項は、プロファイル作成後 24 時間以内に生成されます。 分析対象の Terraform 、 AWS CloudFormation 、または AWS Cloud Development Kit (CDK) に IaC プロジェクトをアップロードすることで、デプロイ前のワークロードのアーキテクチャレビューを実施することができます。ダッシュボードで [ アーキテクチャレビューの実施 ] を選択し、IaC プロジェクトまたはリポジトリファイルを含む a.zip ファイルをアップロードし、インフラストラクチャのレビューに使用する Well-Architected レンズを選択します。 アプリケーションを定義して、関連性を高めるコンテキストを追加し、推奨事項をさらにコンテキスト化できます。特定のリソースやアプリケーションの詳細に範囲を絞り込みたい場合は、ダッシュボードで [ アプリケーションコンテキストの追加 ] を選択し、AWS アカウント、AWS リージョン、AWS のサービス、タグを使用してアプリケーションを追加します。 優先順位が付けられた推奨事項をレビューして修正を開始する これで、リソースやアプリケーション全体でエージェントが生成した優先順位付けされた推奨事項、選択された柱、宣言された目標に対するランク付け、自動化対応の修復などを確認できます。 特定の推奨事項を選択すると、詳細、エージェントが推奨を提案している理由に関する洞察、影響とトレードオフ、および影響を受けた AWS リソース全体での推奨される修正を確認できます。 [ 修復を開始 ] を選択して、推奨される修正に対処します。コンソール、更新された IaC テンプレート、修正する CLI コマンドを解決タイプ別に選択できます。詳細な段階を追った手順が説明されているので、この手順を実行して結果を確認できます。 更新された IaC テンプレートの使用 を選択すると、上記の CDK 関数など、既存の IaC テンプレートの更新に必要なコード変更がエージェントから提供され、コードベースに直接コピーできます。 API アクセスを設定して、推奨事項を既存の開発および運用のワークフローに直接統合することもできます。API の呼び出しやドキュメントの検索など、エージェントをプログラムで操作するには、お好みの AI コーディングツールで AWS MCP サーバー と プラグイン を試してください。 詳細については、 AWS Well-Architected エージェントのドキュメント をご覧ください。 知っておくべきこと ここでは、Well-Architected Agent について知っておくべきことをいくつか紹介します。 自動化 : 修正に必要な正確な IaC コード変更や柱ごとに特定したリスクを含む推奨事項を受け取ることができるため、本番環境に到達する前に問題を特定できます。推奨事項はコンソールと API を通じて提供されるため、コンテキストを切り替えることなく行動できます。また、推奨事項は定期的に更新されるため、チームは定期的に追跡するための新しい推奨事項を利用できます。 評価 : 生成 AI 機能によってこの推奨事項が生成されますが、エラーや不完全な情報が含まれている場合があります。お客様には、特定の状況において推奨事項を評価し、適切な監督および保護措置を講じる責任があります。 AWS 責任ある AI プラクティス の詳細をご覧ください。 既存の AWS Well-Architected Tool を引き続き使用して、独自のベストプラクティスを使用してワークロードを測定する ユーザー定義のレンズ を使用してクラウドアーキテクチャを手動で評価できます。 プレビューが公開中 AWS Well-Architected Agent とその推奨事項は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン) で利用できます。どの AWS 商用リージョンからでもワークロードをオンボーディングできます。AWS Well-Architected Agent は AWS サポートによって提供され、 AWS サポートプラン をお持ちの AWS のお客様にご利用いただけます。 ぜひ AWS Well-Architected コンソール で今すぐ試してみて、通常の AWS サポート窓口を通じてフィードバックをお寄せください。 – Channy 原文は こちら です。

Claude Sonnet 5.5 が 2026 年 10 月 2 日より Kiro IDE 、 CLI 、 Crew 、 Web のすべてで利用可能になりました。Anthropic のこれまでで最も高速な Sonnet モデルであり、Claude Sonnet 5 から明確に進化しています。社内のベンチマークでは、Sonnet 5.5 は Sonnet 5 を上回る結果を示し、トークン消費と速度の両面でも効率が向上しました。Sonnet 5.5 は、 Opus 5.5 に続く Claude 5.5 ファミリーの 2 番目のモデルです。 より速く、より賢く、より明快に Anthropic のデータ によると、Sonnet 5.5 は Sonnet 5 より 30% 以上高速に出力を生成し、Anthropic の Sonnet として最速です。性能も向上しています。エージェント的なコーディングを測る Terminal-Bench 4.0 では、Sonnet 5 の 10.3% から 70.6% にスコアを伸ばしました。実務的なナレッジワークのベンチマークである GDPval-AA では、Opus 5.5 とほぼ同等のスコアを記録しています。Opus 5.5 と同様に、従来のモデルより明快な文章を書き、早期テスターからは Sonnet 5 より協働しやすいパートナーだという評価を得ています。 日常的な開発作業に適したモデル Sonnet 5.5 は、範囲が明確なコーディングや、機能の実装、バグ修正、コードレビューといった日常的な作業向けに設計されています。変更を完了とする前に、自分の作業を確認することが多いモデルです。エージェントワークフローでも高い性能を発揮します。早期テスターによる比較では、複数ステップのツール操作を Sonnet 5 より少ないステップで完了しました。そのため、Opus 5.5 と組み合わせて、より高速で低コストなサブエージェントとして使う構成に向いています。 調整可能な effort と長いコンテキスト Sonnet 5.5 は Adaptive Thinking を備えており、effort 設定で思考の深さとコストを調整できます。設定は low から max までの 5 段階です。また、1M トークンのコンテキストウィンドウと最大 128K の出力トークンに対応し、長いコンテキストを使っても追加料金はかかりません。 安心して使うためのセーフガード Sonnet 5.5 のサイバーセキュリティ能力は Anthropic の最上位である Opus シリーズに匹敵するため、Opus シリーズ向けに開発されたサイバー関連のセーフガードとフォールバックも備えています。自分のコードのバグを見つけて修正するといった日常的なソフトウェア開発のほとんどはこれまでどおり機能しますが、リスクの高い一部のリクエストはブロックされる場合があります。その場合は Sonnet 5 で再実行できます。生物学関連のセーフガードは Sonnet 5 と同じであるため、ライフサイエンス分野の作業のほとんどは影響を受けません。 提供状況 Claude Sonnet 5.5 は、us-east-1 (IAD) および eu-central-1 (FRA) の Kiro Pro、Pro+、Pro Max、Power をご利用のお客様に対して、 実験的サポート として段階的に展開されています。 1M のフルコンテキストウィンドウと 1.3 倍のクレジット乗数 で提供されます。 この記事は Kiro ブログの Claude Sonnet 5.5 is now available in Kiro を翻訳したものです。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 10 月 27 日 (火) 14:00 から、オンラインハンズオンワークショップ 「ハンズオンワークショップ：Amazon EKS で Platform Engineering を加速する」 を開催します。開発者が自分でアプリをデプロイできるセルフサービス型の仕組みは、リリースを速くできます。一方で、複数のツールを組み合わせる必要があり、インフラも複雑になります。前半の座学では、Platform Engineering の全体像と、社内の開発者向けに基盤を用意する内部開発者プラットフォーム (IDP) の考え方を整理します。後半のハンズオンでは、Backstage、Argo CD、ACK、kro を使って実際に IDP を構築します。Kubernetes の導入を進めたい方や、それを支援する SI 企業の方はぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年9月28日週の主要なアップデート 9/28(月) Amazon SageMaker Unified Studio が 2 つの新しい接続機能をサポート: Iceberg REST Catalog 接続と Amazon DocumentDB の IAM 認証 Amazon SageMaker Unified Studio に 2 つの接続機能が追加されました。1 つ目は Iceberg REST Catalog (IRC) 接続で、Snowflake Open Catalog (Polaris) や Databricks Unity Catalog など、Iceberg REST 仕様に準拠した外部 Apache Iceberg カタログへ接続できます。2 つ目は Amazon DocumentDB の IAM 認証で、ユーザー名・パスワードを保存せずに接続の IAM ロールで認証できます。どちらも SageMaker Unified Studio が利用可能なすべての AWS リージョンで、追加料金なしで利用できます。 AWS Backup が Amazon FSx for NetApp ONTAP の論理的エアギャップボールトサポートを追加 AWS Backup の論理的エアギャップボールトが Amazon FSx for NetApp ONTAP に対応しました。FSx for ONTAP ボリュームのバックアップを、コンプライアンスモードの Vault Lock で保護された領域に保存できます。保護された領域は AWS RAM で他アカウントと共有でき、共有先アカウントからコピーせずに直接リストアできるため、ランサムウェア被害やアカウント侵害時の復旧時間を短縮できます。Multi-party approval という機能と組み合わせることで、保護された領域を持つ AWS アカウントにアクセスできない状況でも､別の AWS アカウントで復旧する仕組みがあります｡東京リージョンと大阪リージョンを含む、両機能が利用可能なすべてのリージョンで使用できます。 Amazon EC2 Future-dated Capacity Reservations が開始日の延期に対応 Amazon EC2 Future-dated Capacity Reservations (FDCR) は、必要なキャパシティ、開始日、コミット期間を指定して最大 120 日先のキャパシティを事前に確保できる機能です。今回のアップデートで、キャパシティが配信される前であれば、予約の開始日を後ろ倒しできるようになりました。変更時には EC2 が新しい開始日と必要なコミット期間を示す見積もりを提示し、内容を確認して承諾すると予約が更新されます。開始日の 2 週間以内に変更する場合はコミット期間が増加します。従来は計画変更時にキャンセルと再作成しか選択肢がなく、キャンセル料が発生する場合がありました｡ 9/29(火) Amazon Route 53 Resolver DNS Firewall が Palo Alto Networks Advanced DNS Security のサポートを一般提供開始 Amazon Route 53 Resolver DNS Firewall で Palo Alto Networks (PANW) Advanced DNS Security のルールが利用できるようになり、32 の AWS リージョンで一般提供が開始されました。DNS Firewall のルールグループに PANW の脅威カテゴリ (C2、マルウェア、フィッシング、新規登録ドメインなど 30 種類以上) を直接設定し、VPC およびハイブリッド環境からの悪意ある DNS クエリを検出・ブロックできます。PANW のファイアウォール製品を別途デプロイしたり、VPC のルーティング設定を変更したりする必要はありません。2026 年 6 月の AWS Summit New York City でのプレビュー発表 (当初 8 リージョン) を経て、DNS Firewall が提供されるすべての商用リージョンに拡大されました。 Amazon CloudWatch Logs が頻繁にクエリされるフィールドを自動的にインデックス化 Amazon CloudWatch Logs が、CloudWatch Logs Insights クエリで頻繁に使われるフィールドを自動的にインデックス化するようになりました。対象は = および IN 演算子によるフィルタで使用されるフィールドで、手動設定は不要です。自動インデックスされたフィールドはロググループあたり 20 フィールドのポリシー上限にカウントされず、30 日間保持されます。クエリパターンの変化に応じて対象フィールドは自動的に更新され、恒久的に維持したい場合はフィールドインデックスポリシーへ昇格できます。追加料金はなく、フィールドインデックスがサポートされるすべてのリージョンで利用できます。 Amazon CloudWatch Logs Insights がクエリ実行前のスキャンバイト数の見積もりに対応 Amazon CloudWatch Logs Insights で、クエリを実行せずにスキャン対象となるログデータ量 (バイト数) を見積もれるようになりました。CloudWatch コンソールでは、ロググループの選択・時間範囲・クエリテキストを変更すると、クエリエディタに見積もり値が自動表示されます。AWS CLI や API では、クエリの末尾に estimate コマンドを追加して明示的に見積もりを取得します。estimate コマンドの実行に Logs Insights のクエリ課金は発生しません。全 AWS 商用リージョンで利用できます。 OpenAI GPT-6.1 Sol が Amazon Bedrock で一般提供開始 AWS は、OpenAI の GPT-6.1 Sol を Amazon Bedrock で一般提供開始しました。GPT-6.1 Sol は 2026 年 9 月 22 日に提供開始された GPT-6 Sol の後継モデルで、エージェンティックコーディング、computer use、業務ドキュメント作業に向けたモデルです。OpenAI によると、コーディングベンチマーク DeepSWE v1.1 では最上位モデル GPT-6 Astra と同等のスコアを、タスクあたり約 5 分の 1 のコストで達成します。Bedrock 上では explicit prompt caching に対応しており、コンテキストを繰り返し再利用するエージェントワークロードに適しています。料金は GPT-6 Sol と同水準 (Global CRIS で入力 $2.00 / 出力 $10.00 per 1M トークン) のまま性能が向上しています。 9/30(水) Amazon S3 Tables が Apache Iceberg V3 の全データ型をサポート Amazon S3 Tables が、Apache Iceberg Version 3 仕様で定義された geometry、geography、unknown、ナノ秒精度タイムスタンプの各データ型と、列デフォルト値に対応しました。既存対応の variant 型、deletion vectors、row lineage と合わせ、S3 Tables は V3 で導入された全データ型をサポートするサービスとなります。位置情報を文字列や緯度経度のペアで、イベント時刻を整数でエンコードする従来の回避策が不要になり、クエリ時のフィルタリングとストレージ効率が改善されます。今回追加された機能は、S3 Tables が利用可能なすべてのリージョンで使用できます。 AWS アカウントが電話番号の検証をサポート AWS アカウントのプライマリ連絡先電話番号を、SMS のワンタイムパスコード (OTP) で検証できるようになりました。従来は電話番号の形式チェックのみで、番号が実在するか、本人が受信できるかは確認されていませんでした。新しい SendPhoneNumberVerification API と VerifyPhoneNumber API、またはマネジメントコンソールから検証を実行でき、GetContactInformation API で検証ステータスを確認できます。AWS Organizations では、管理アカウントで検証済みの番号をメンバーアカウントに適用すると検証済みステータスが継承されるため、多数のアカウントで個別に SMS を受信する必要がありません。全 AWS 商用リージョンで利用できます。 Amazon Quick がダッシュボードのドリルダウンをガイドする階層フィルターを追加 Amazon Quick (旧 Amazon QuickSight) に階層フィルターが追加されました。Region → Country → City のような親子関係を持つディメンションを、最大 5 階層まで 1 つのドロップダウンコントロールにまとめられます。従来は階層ごとに個別のフィルターコントロールを並べる必要がありましたが、1 つのコントロールに置き換えることで画面上のコントロール数を減らし、読者は少ないクリック数で目的のデータに到達できます。本機能は Amazon Quick がサポートされるすべてのリージョン (東京リージョンを含む 26 リージョン) で利用できます。 Aurora PostgreSQL が Apache Iceberg および Parquet データのクエリに対応 Aurora PostgreSQL から、Amazon S3、Amazon S3 Tables、AWS Glue Data Catalog 上の Apache Iceberg / Parquet 形式のデータを、ETL パイプラインやデータ複製なしに直接クエリできるようになりました。PostgreSQL の外部テーブルとしてデータレイクを参照し、クエリ実行は PostgreSQL サーバーに組み込まれた DuckDB エンジンが担当します。既存のアプリケーション、ドライバー、BI ツールは同じ PostgreSQL エンドポイントをそのまま使えます。Aurora PostgreSQL 17.11 以降および 18.6 以降 (Aurora Serverless v2 を含む) で、全商用リージョンと GovCloud (US) リージョンにて追加料金なしで利用できます。 Amazon RDS が AMD ベースの M8a インスタンスをサポート Amazon RDS for PostgreSQL、MySQL、MariaDB が第 5 世代 AMD EPYC プロセッサ (開発コード名 Turin) を搭載した M8a データベースインスタンスに対応しました。各 vCPU が物理 CPU コアに 1 対 1 で対応するため、SMT によるスレッド競合がなく、コアあたりの性能が安定します。最大サイズの db.m8a.48xlarge では 192 vCPU、768 GiB メモリ、75 Gbps のネットワーク帯域、60 Gbps の EBS 帯域を利用できます。RDS ではこれまで M7a や M6a といった AMD ベースの汎用クラスが提供されていなかったため、オープンソースエンジン向けの AMD 汎用インスタンスとしては最新世代からの導入となります。提供リージョンはバージニア北部、オハイオ、オレゴン、ムンバイ、東京、ハイデラバード、アイルランド、フランクフルト、スペインの 9 リージョンです。 Amazon Aurora serverless がエージェント型 AI などのバースト性ワークロード向けにスケーリングを高速化 アップデート前は､現在の ACU 容量が大きいほど大きくスケールする仕組みとなっており、低容量時のスケールアップは小刻みでした。今回の強化で 1 秒以内に最大 16 ACU を追加できるようになり、最大 256 ACU まで到達する時間が短縮されました。最小刻み 0.5 ACU での細かい調整は従来どおりです。ワークロード終了後は 0 ACU まで自動でスケールダウンするため、使用した分だけの課金になります。バースト的なアクセス、長いアイドル期間、予測不能なトラフィックという特性を持つエージェント型 AI アプリケーションに適しています。 10/1(木) AWS IAM Identity Center がマルチリージョンサポートの対象リージョンを拡大 AWS IAM Identity Center のマルチリージョンサポートが、オプトインリージョン、AWS GovCloud (US) リージョン間、AWS 中国リージョン間に拡大されました。従来はデフォルトで有効な商用リージョンのみが対象でした。マルチリージョンサポートを有効にすると、ID、許可セット、割り当てなどがプライマリリージョンから追加リージョンへ自動レプリケートされ、プライマリリージョン障害時もユーザーはプロビジョニング済みの権限で AWS アカウントにアクセスを継続できます。利用には組織インスタンスとマルチリージョンのカスタマーマネージド KMS キー (CMK) が必要で、IAM Identity Center 自体は追加料金なしで利用できます。 10/2(金) Amazon Aurora DSQL がパーシャルインデックスをサポート Amazon Aurora DSQL で、テーブルの特定の行サブセットだけを対象とするパーシャルインデックスを作成できるようになりました。CREATE INDEX ASYNC に WHERE 句を追加すると、条件を満たす行だけがインデックスに格納されます。数年分の完了済み注文の中に少数の未処理注文が混在するような、小さなワーキングセットと大きな履歴データが同居するテーブルで、インデックスサイズとストレージコストを抑えながらクエリ性能を改善できます。本機能は Aurora DSQL が提供されているすべてのリージョンで利用できます。 AWS Health がソフトウェアライフサイクル管理のための version catalog を発表 AWS Health に、AWS サービス全体のソフトウェアバージョンのライフサイクル情報を一元的に確認できる version catalog が追加されました。Amazon RDS のエンジンバージョン、Amazon EKS の Kubernetes バージョン、AWS Lambda のランタイムなどについて、サポート終了日や推奨バージョンをサービス横断で確認できます。AWS Health Dashboard から参照できるほか、Business Support+、Enterprise Support、Unified Operations のいずれかのサポートプランを契約している場合は、新しい DescribeServiceLifecycle API で運用ワークフローに組み込めます。アカウント固有の Planned Lifecycle Events を受け取る前の段階で、アップグレード計画やガバナンス統制を構築できるようになります。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

(この記事は、 AWS 기반 EDA 환경으로 Rebellions의 차세대 AI NPU 개발 가속화하기 を翻訳したものです。) 先端半導体の開発においては数多くの Logic Simulation を繰り返し、DFT（Design for Test）や Physical Design のように高いコンピューティング性能を必要とする EDA（Electronic Design Automation）作業を実行する必要があります。設計規模と検証範囲が大きくなるほど、必要な CPU コアやメモリ、共有ストレージのスループットもあわせて増加します。必要な時点で十分なインフラを確保できなければ、EDA ツールの実行時間やジョブの待ち行列が長くなり、開発スケジュール全体に影響を及ぼす可能性があります。 AI 推論用 NPU を開発する Rebellions は半導体設計プロセスの Design Verification（DV）と Physical Design（PD）業務に AI Transformation（AX）を適用し、エンジニアの生産性を約 3 倍に向上させました。しかし、エンジニアリング業務の生産性が高まった後も相対的に長い EDA ツールの実行時間が全体の開発速度を制約し、新たなボトルネックとして浮き彫りになりました。 Rebellions はこのボトルネックを解消して設計開発全般の生産性をさらに高めるため、実際の NPU 開発ワークロードに基づいて AWS 環境における EDA の性能と拡張性を検証しました。 本記事では AWS ParallelCluster と Amazon FSx を活用した EDA 環境の構成とともに、Logic Simulation、DFT、Physical Design の各ワークロードで確認した性能改善の結果を紹介します。 Rebellions の紹介 Rebellions は AI 推論用の NPU チップからコンパイラを含むソフトウェアまでを自社で開発する、 AI 推論専用のフルスタック・ファブレス・スタートアップです 。大韓民国政府が設立した 国民成長ファンドの第 1 号投資企業 として国家のソブリン AI インフラエコシステムを先導しており、APAC、中東、欧州などのグローバル市場へ事業を拡大しています。 データセンターインフラ向けの第 1 世代 NPU である ATOM の商用化に成功しました。ATOM は大規模なトラフィックが発生する SKT の「エイダット」通話要約サービスなどに採用されています。また、 大韓民国初の NPU-as-a-Service を構築しました。 第 2 世代 NPU である Rebel100 （以下 R100）は最高の performance-per-watt と 韓国初のペタフロップス級の性能 を基盤に、エージェンティック AI の時代に求められる CPU–NPU 統合最適化と、サーバー単位からトークンファクトリー単位まで拡張可能なアーキテクチャを提供します。これにより多様な次世代 AI ワークロードに柔軟に対応できます。2026 年初めに量産に着手し、2026 年下半期から多様な顧客環境へ本格的に適用される予定です。 今後はより多様で複雑化する AI ワークロードに最適化された性能を提供するため、次世代のメモリ中心構造（memory-centric architecture）と HW–SW co-design を中心に、技術および製品アーキテクチャの発展の方向性を継続的に模索していく計画です。 NPU 開発の次のボトルネック、EDA 実行時間 EDA ワークロードは作業によって必要とするリソースの特性が異なります。Logic Simulation は機能や設定、乱数 seed に応じて生成される多数の独立したジョブを限られた時間内に処理しなければなりません。DFT と Physical Design は高い CPU 性能だけでなく、大容量メモリと高速なファイルアクセス性能を必要とします。 こうした作業を固定されたオンプレミスインフラで実行すると、2 つの問題が生じます。まず、プロジェクトのピーク需要を基準に機器を購入すると、平常時にはリソースが余ります。逆に、平均需要に合わせて機器を構成すると、regression や設計マイルストーンのように作業が集中する時期に待ち時間が長くなります。 高性能サーバーを 1 台追加するだけではすべての問題を解決することはできません。Logic Simulation のように独立したジョブが多いワークロードでは並列処理能力が重要であり、Physical Design には高いクロックと十分なメモリを備えたインスタンスが必要です。複数のジョブが共通の設計データやライブラリに同時にアクセスするため、共有ストレージとネットワークの性能もあわせて確保する必要があります。 Rebellions は EDA 作業ごとに適したコンピューティングリソースを選択し、regression や設計マイルストーンのように作業が集中する時点で大規模な実行容量を確保できるかを確認するため、AWS ベースの EDA 環境を検証しました。 図 1. AX と EDA 実行環境の改善による NPU 開発期間の短縮 EDA ワークロードで AWS が提供するメリット オンプレミスの EDA ファームではプロジェクトの開始前にコンピューティングとストレージの需要を予測して機器を購入する必要があります。Rebellions が新規の高性能サーバーを検討した際には、発注後に最低 20 週のリードタイムが必要で、設置と実際の利用開始までを考慮すると 6 か月から 8 か月待たなければなりませんでした。また、EDA の需要は full regression、DFT、Physical Design など特定の時期に集中するため、ピークを基準に機器を購入すると平常時にリソースが余り、平均需要に合わせると重要な時期にジョブの待ち時間が長くなります。 AWS ではプロセッサアーキテクチャや CPU 性能、メモリ、ローカルストレージ、ネットワーク構成がそれぞれ異なる Amazon EC2 インスタンスの中から、EDA 作業に適した構成を選択できます。たとえば r8i は Intel Xeon 6 プロセッサと大容量メモリを必要とする x86 ベースの EDA 作業に活用できます。c8g は AWS Graviton4 プロセッサを搭載した Arm ベースのインスタンスで、使用している EDA ソフトウェアと関連ライブラリが Arm64 をサポートしていれば、よりコスト効率を高める選択肢として検討できます。x8aedz は高いシングルコア性能と大容量メモリ、ローカル NVMe ストレージを必要とする Physical Design や大規模な EDA 作業に適した選択肢です。これらのインスタンスを作業の特性に応じて選択し、必要な時点で拡張することで、サーバーの購入・設置にかかる時間を短縮し、必要なタイミングに合わせて実行環境を構成できます。 図 2. AWS ParallelCluster と Amazon FSx を活用した EDA リファレンスアーキテクチャ AWS ParallelCluster は Slurm ベースの EDA クラスターの構築と管理を簡素化します。ユーザーが従来と同じ方法でジョブを投入すると、待機中のジョブに合わせて Amazon EC2 のコンピューティングノードを作成し、ジョブの完了後に使われなくなったノードを減らします。Logic Simulation、DFT、Physical Design のように要求仕様が異なる作業をそれぞれ別の Slurm キューと EC2 構成に紐づけることもできます。最小コンピューティングノード数を 0 に設定すれば、full regression や設計マイルストーンのときだけ多くのコンピューティングリソースを使用し、平常時はすべてのコンピューティングノードを終了できます。 EDA ツールは多数のソースファイルやライブラリを読み込み、ログ、waveform、中間結果を繰り返し書き込みます。複数のコンピューティングノードが同じデータに同時にアクセスするため、共有ストレージのスループットだけでなくアクセスレイテンシーも重要です。AWS では EDA ワークロードの特性に適した Amazon FSx for OpenZFS と Amazon FSx for NetApp ONTAP という高性能ストレージの選択肢を利用できます。 半導体の設計ファイルは企業の中核的な資産であるため、クラウド環境でも外部への流出を防止できる統制が必要です。EDA 環境をお客様が管理する AWS アカウントと VPC のプライベートサブネットに配置し、データセンターからは AWS Site-to-Site VPN を介してのみアクセスするように構成すれば、設計ファイルとコンピューティング環境をインターネットに公開しません。IAM とセキュリティグループによって許可されたユーザーとシステムのみがアクセスできるように制限し、保存データを暗号化するとともに、AWS CloudTrail でユーザーのアクティビティを監査し、Amazon CloudWatch Logs でシステムとジョブのログをモニタリングできます。これにより、設計ファイルを統制されたネットワークと権限の境界内で管理し、外部流出に対する懸念を軽減できます。 Rebellions が適用した EDA on AWS アーキテクチャ Rebellions は前述した AWS のコンピューティングとストレージの選択肢のうち、AWS ParallelCluster、Amazon EC2 x8aedz および c8g インスタンス、そして Amazon FSx for OpenZFS ストレージを使用して検証環境を構成しました。Rebellions のデータセンターと AWS VPC は AWS Site-to-Site VPN で接続しました。 図 3. Rebellions EDA on AWS 検証アーキテクチャ EDA エンジニアは Site-to-Site VPN を介して AWS ParallelCluster の Slurm スケジューラーにジョブを投入し、データセンターの RTL 設計ファイルを Amazon FSx for OpenZFS にアップロードします。待機中のジョブが発生すると、必要な Amazon EC2 x8aedz コンピューティングノードが作成され、Logic Simulation、DFT、Physical Design のジョブを実行します。ジョブが完了してアイドル状態になると、すべてのコンピューティングノードは終了し、ヘッドノードと Amazon FSx for OpenZFS、EDA ライセンスサーバーは維持されます。コンピューティングノードでは FSx for OpenZFS の高性能ストレージをマウントして EDA ツールや設計データ、作業領域、結果を共有し、クラスターとジョブのログは Amazon CloudWatch Logs で確認できます。 ファイルアクセス性能の比較 EDA 作業はソースコードやライブラリだけでなく、大量のログ、waveform、中間成果物に繰り返しアクセスします。特に多くのジョブが同時に実行される場合、共有ファイルシステムとネットワークのスループットおよびレイテンシーが全体のスループットを制約する可能性があります。 Rebellions は実際の EDA 作業を実行する前に、オンプレミスの NFS と AWS のストレージシステムのファイルアクセス性能を比較しました。 項目 Rebellions オンプレミス NetApp C400A, 40G Ethernet AWS EC2 FSx for OpenZFS, 75G Ethernet 性能改善倍率 シーケンシャル書き込み 108MB/s 855MB/s 約 7.9 倍 シーケンシャル読み込み 67MB/s 1,229MB/s 約 18.3 倍 並列書き込み（4 ストリーム同時） 112MB/s 1,134MB/s 約 10.1 倍 4KB ランダムアクセスのレイテンシー 2.98ms 0.10ms 約 29.8 倍 AWS 環境はシーケンシャル書き込みで約 7.9 倍、シーケンシャル読み込みで約 18.3 倍、4 ストリームの並列書き込みで約 10.1 倍高いスループットを示しました。4KB ランダムアクセスのレイテンシーは約 30 分の 1 と測定されました。 こうした差にはストレージ自体の性能だけでなく、ネットワーク帯域幅とリソースの割り当て方式も影響しました。オンプレミス環境では 10Gbps イーサネット 4 回線を複数のコンピューティングサーバーで共有し、個々のサーバーは最大 10Gbps の帯域幅を使用していた一方、AWS 環境では個々の Amazon EC2 インスタンスに最大 75Gbps のネットワーク帯域幅が提供され、7 倍以上の帯域幅を活用できました。また、オンプレミスのストレージは全社で共有するリソースでしたが、Amazon FSx for OpenZFS は今回の EDA ワークロード専用に割り当てられ、他のワークロードの I/O の影響を受けませんでした。 単一の Logic Simulation ジョブで CPU 処理が中心であれば、ストレージのスループットが 10 倍に増えても、アプリケーションの実行時間が同じ比率で短縮されるわけではありません。共有ストレージのメリットは多数のジョブが同時にデータを読み込み、ログや結果を書き込む際により明確に表れます。 Logic Simulation 性能の比較 Logic Simulation は半導体を製造する前に、RTL（Register Transfer Level）で記述した回路が意図したとおりに動作することをソフトウェアで検証する作業です。検証対象の RTL（回路設計）ごとに 1 回あたり数分から数十時間かかるテストを数万件、それぞれ数十回繰り返す必要があります。 今回の比較では EDA ツールとして Synopsys VCS を使用し、Rebellions が保有するオンプレミスサーバー（Intel Xeon Processor ベース）の物理コア数に合わせて、最大 64 個のジョブを同時に実行しました。EC2 では多様な CPU とメモリ構成のインスタンスが提供されているため、ワークロードの特性に合った構成を選択できます。今回の実験では多数の物理コアと高いシングルコア性能に加えて、大容量メモリをあわせ持つ x8aedz コンピューティングノード（AMD EPYC 9R45 ベース）と、コスト効率の高い c8g コンピューティングノード（AWS Graviton4 ベース）の結果を比較しました。 テストした UCIe IP と Network-on-Chip の両ワークロードにおいて、AWS 環境はオンプレミス環境よりも一貫して短い実行時間を示しました。同時ジョブ数が 1 個、16 個、32 個、64 個と増加する間、AWS x8aedz コンピューティングノードでのシミュレーションはオンプレミス比で 2.3 倍から 2.6 倍速く完了し、AWS c8g コンピューティングノードでも約 1.3 倍速く完了しました。 図 4. UCIe IP と Network-on-Chip の Logic Simulation 性能比較 Logic Simulation には Synopsys VCS® のような商用シミュレーターのライセンスが必要なため、コンピューティングリソースとライセンス数量のバランスを取ることが重要です。韓国内外の大企業のように Site Licensing を結んでいる場合は、サーバー（CPU core）の数を多く増やして Simulation スループットを確保するのも一つの方法ですが、限られた数のライセンスを運用するスタートアップには、高いシングルコア性能によって個々のジョブ時間を短縮し、保有するライセンスを効率的に活用するアプローチが必要です。 したがって Logic Simulation 環境ではライセンス数量と作業の特性に合わせてコンピューティングリソースを選択する必要があります。AWS では高いシングルコア性能、多数の CPU コア、大容量メモリ、ローカル NVMe ストレージなど、それぞれ異なる特性を持つ多様な Amazon EC2 インスタンスを選択できます。これにより、個々のシミュレーションの実行速度と大規模並列ジョブのスループットを考慮して適切なコンピューティング構成を使用し、必要な時点でのみ拡張できます。 Design for Test（DFT）設計性能の比較 DFT は製造されたチップの欠陥を検査できるよう、診断回路を設計に挿入するプロセスです。数多くの回路で発生しうる多様な欠陥を短時間で検出しつつ、チップの機能と性能への影響を最小限に抑える必要があるため、高い CPU 負荷とストレージ I/O が発生します。 今回の実験では R100 の Neural Core と Shared Memory を対象として、Synopsys TestMAX を使用しました。ジョブ全体の実行時間を合計すると、オンプレミスでは 11 時間 51 分、AWS x8aedz コンピューティングノードでは 4 時間 41 分かかりました。同一のジョブセットを基準に、AWS 環境が約 2.5 倍速く完了しました。 DFT 対象 作業種別 オンプレミス AWS x8aedz 性能倍率 Neural Core Memory Built-in Self Test 4 時間 44 分 1 時間 54 分 約 2.5 倍 Neural Core Scan Insertion 1 時間 40 分 38 分 約 2.6 倍 Shared Memory Memory Built-in Self Test 2 時間 26 分 1 時間 16 分 約 1.9 倍 Shared Memory Scan Insertion 3 時間 1 分 53 分 約 3.4 倍 Physical Design 性能の比較 Physical Design はコードで記述された半導体の設計図である RTL から、ファウンドリで製造する物理的な回路レイアウトデータである GDSII を作成するプロセスです。論理合成（RTL Synthesis）、Floor Planning と Placement、Clock Tree Synthesis、Routing、Timing および Power Optimization など、非常に複雑な段階で構成されます。 Physical Design は CPU 負荷とメモリ要求量の大きい作業であり、そこで使用される EDA ツールのライセンスは設計インフラの中で最も比重の大きい投資項目です。したがって EDA ツールを効率的に活用して 1 回あたりの実行時間を短縮するためには、高性能 CPU を確保することが非常に重要です。今回の実験においても R100 の Neural Core を対象に Synopsys Fusion Compiler を使用して性能を比較しました。 作業種別 オンプレミス AWS x8aedz 性能倍率 Logic Synthesis 101 時間 54 時間 約 1.9 倍 Clock Tree Synthesis 75 時間 34 時間 約 2.2 倍 Route 90 時間 41 時間 約 2.2 倍 合計 266 時間 129 時間 約 2.1 倍 オンプレミス環境では上表の全作業に 266 時間かかりましたが、AWS 環境では 129 時間で完了しました。約 11 日かかっていた 1 回の実行を約 5.4 日に短縮し、全体の時間を約 2.1 分の 1 に短縮しました。 今回の結果は、高性能 CPU と大容量メモリを備えた AWS のコンピューティング環境の活用により、長時間実行される Physical Design の反復サイクルを短縮し、EDA ツールをより効率的に活用できることを示しています。 検証結果が示すもの 今回のテストでは次の結果を確認しました。 ファイルアクセス性能は項目に応じて 約 7.9 倍から 18.3 倍高いスループット を示し、4KB ランダムアクセスのレイテンシーは約 30 分の 1 と測定されました。 Logic Simulation は 1 個から 64 個の同時ジョブの条件で 2.3 倍から 2.6 倍速く 完了しました。AWS Graviton Processor によってコスト効率を高めた c8g インスタンスでは 1.2～1.4 倍速く 完了しました。 DFT 作業は 11 時間 51 分から 4 時間 41 分に短縮され、 約 2.5 倍速く 完了しました。 Physical Design は 266 時間から 129 時間に短縮され、 約 2.1 倍速く 完了しました。 この結果は最新のプロセッサと大容量メモリ、高帯域ネットワーク、独立して割り当てた共有ストレージが組み合わさったテスト環境の効果です。いずれか 1 つのサービスだけで全体の改善を説明することはできません。 より重要な変化は開発需要が発生した時点で多くのコンピューティングリソースを集中的に投入できる点です。Logic Simulation の大量の待ちジョブに対しては複数のコンピューティングノードを同時に拡張し、Physical Design に対しては高いクロックと大容量メモリを備えたインスタンスを割り当てることができます。ジョブの終了後に動的コンピューティングノードを減らすことで、短いピーク需要のために同じ規模のサーバーを常時保有する必要性も低下します。 コストを評価する 3 つの観点 クラウドとオンプレミスのコストは時期や契約、運用方式によって異なるため、単純なサーバー価格だけで比較するのは困難です。ここでは具体的なコストの数値を断定するのではなく、Rebellions が EDA 環境を検討する中で考慮した 3 つの基準を見ていきます。 まず、開発開始の時点に合わせて最上位のサーバーを導入するのは容易ではありません。新規サーバーを選定して発注すると最低 20 週のリードタイムが必要で、配送と設置を経て実際に使用できるようになるまで 6 か月から 8 か月待たなければなりません。開発スケジュールに間に合わせるには、少なくとも 6 か月前に機器を発注しなければならないということです。機器が予定どおり導入されたとしても、開発の開始が 6 か月遅れたらどうなるでしょうか。実際の開発においては、1 世代前のサーバーを使うことになる可能性があります。AWS では開発が始まる時点で利用可能な最新世代の高性能 CPU を選択し、必要な規模のコンピューティングリソースをプロジェクトに合わせて構成できます。 次に、スタートアップがオンプレミスを導入するにあたっては、すべてのワークロードの最大要求量を考慮して CPU 性能、メモリサイズ、ストレージを選定することになるため、個々の EDA ジョブにとっては不要なリソースを使用する非効率が生じます。オンプレミス環境では複数の EDA ワークロードの最大要求仕様を考慮してサーバーを導入しなければならないため、作業によってはリソースが非効率に使われる可能性があります。たとえば、Physical Design 作業には約 400GB～1TB の大容量メモリが必要です。Rebellions が導入したオンプレミスサーバーはすべて 3TB のメモリを搭載しており、開発の前半には Simulation に、後半には Physical Design に活用しています。一方 Simulation ジョブの場合、IP は 2GB～30GB 程度のメモリしか必要としないため、開発の前半ではリソースを非効率に活用していることになります。ストレージのコストも考慮する必要があります。Rebellions が検討した最新型の 500TB 級ストレージは 10 億ウォンから 20 億ウォンの水準でした。ストレージは平均使用量とピーク使用量の差が大きいものの、オンプレミスではピークを基準に高性能・大容量のシステムをあらかじめ構築しておく必要があります。想定したピークの容量や性能を超えると、実行中の EDA ジョブが中断されるという深刻な問題が発生するおそれもあります。一方 AWS ベースのコンピューティングクラスターでは、ストレージへの大規模な初期投資を抑え、実際の使用パターンに合わせて適切な CPU と必要なストレージ容量を構成できます。 最後に EDA ツールの活用度もあわせて評価する必要があります。高性能な EDA ツールを低性能のサーバーで長時間実行すると、ライセンスを十分に活用することは困難です。したがって EDA 環境のコストは、コンピューティングリソースの時間あたり単価だけでなく、高性能なコンピューティング環境で完了したジョブ数や短縮した実行時間、ライセンスの活用効率を基準に評価すべきです。 おわりに – 真の開発の加速 AX によってテスト生成や分析など、エンジニアの業務効率を大きく高めたとしても、EDA ツールの実行時間がボトルネックとして残っていれば、開発期間全体の短縮には限界があります。ソフトウェア開発手法の革新と、それを支えるコンピューティングインフラがともに改善されなければならないのは、このためです。 Rebellions は実際の NPU 開発ワークロードを AWS で検証し、Logic Simulation、DFT、Physical Design の実行時間を短縮し、共有ストレージのファイルアクセス性能を高められることを確認しました。また、最新のクラウドコンピューティングインフラがサーバー調達リードタイムの長さやピーク需要に合わせたストレージへの過剰投資など、オンプレミス環境の限界を補うことのできる現実的な代替手段であることを確認しました。 AWS ベースの EDA 環境の価値は単により高速なサーバーを 1 台使うことにあるのではありません。作業の特性に合ったコンピューティングとストレージを選択し、regression や設計マイルストーンに大規模なリソースを集中的に投入した後、作業が終われば再び縮小できる点にあります。これにより、固定されたインフラ容量が原因で生じるジョブの待ち時間を短縮し、設計の反復結果をより早く得ることができます。 Rebellions は AX によるソフトウェアの革新と AWS の弾力的なコンピューティングインフラが生み出すシナジーを基盤に、次世代 AI NPU の開発をさらに加速し、グローバル市場に競争力のある AI 推論ソリューションを迅速に送り出してまいります。 参考資料 Rebellions Rebellions – R100 AWS ParallelCluster Amazon FSx for OpenZFS Amazon FSx for NetApp ONTAP Amazon EC2 x8aedz Instance Amazon Graviton Processor 著者について パク・サンギュ（박상규） パク・サンギュ氏は Rebellions で Design Verification 分野をリードしており、ATOM MAX、R100、R100s のプロジェクトに参加しました。最近は Rebellions の開発戦略に沿った Agentic Verification Framework をチームメンバーとともに開発しており、この挑戦の一環として AWS の Parallel Computing Service の導入を検討しました。 ジェ・サンウン（제상은） ジェ・サンウン氏は Rebellions で IP/System レベルの検証はもちろん、Architecture evaluation から Silicon Validation まで、多方面にわたってチームに貢献する Multi-role player です。最近は Agentic Verification の基盤となる EDA Orchestration ソリューションである dv-flow を開発し、AWS の Cloud Service をチームの開発業務に適用するための技術評価を主導しました。 ペク・スンミン（백승민） ペク・スンミン氏は Rebellions で Global Strategy および Partnership 業務を担当しています。最近は Next Silicon 戦略とパートナーシップの方向性の策定に参画しており、開発環境の高度化に向けた AWS Cloud および EDA インフラの導入検討と、主要な技術パートナーとの協業に心血を注いでいます。 チェ・チョルウ（최철우） チェ・チョルウ氏は AWS の Senior Frontier AI SA です。主にスタートアップの AI/ML、Physical AI、EDA 分野におけるアーキテクチャ設計と最適化を支援しています。 チョ・ミンス（조민수） チョ・ミンス氏は Amazon Web Services で Frontier AI APJ Sales を担当しており、Physical AI や AI 半導体など高い成長ポテンシャルを持つ AI スタートアップの AWS 導入と Go-to-Market 戦略の実行を支援しています。スタートアップが Zero to One の道のりで直面する技術的・事業的な課題を経営陣の Thinking Partner としてともに考え、実質的な結論を導き出せるよう支援しています。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。

深夜 2 時にインシデントが発生したとき、オンコール担当者がどれだけ的確に対応できるかは、そのシステムについてどのような知識を持っているかに左右されます。最初に見るべきメトリクスはどれか、このサービスの「平常時」はどんな状態か、デプロイ履歴はどこを見ればわかるのか。こうした知識は、ランブックや社内 Wiki、そしてシステムを作ったシニアエンジニアの頭の中にあることが少なくありません。そのため、調査の質は「誰が呼び出されたか」で変わってしまいます。サービスを作った本人が対応すれば、根本原因の分析にかかる時間は大幅に短くなります。そうでなければ、同じ調査に何時間もかかったり、根本原因にたどり着けないまま終わったりします。 AWS DevOps Agent の Skills は、このギャップを埋める仕組みです。チームの優れた調査手順を、再利用しやすい単位に分けた一連の指示としてまとめておくと、エージェントがインシデント対応中に必要なものを自動で読み込みます。オンコール担当者が正しい手順を知っているかどうかに頼る必要はありません。Skills は、そのノウハウを 24 時間 365 日エージェントが使える状態にします。誰が呼び出されても変わらず、一貫して繰り返せる調査になります。 うまく書けた Skill は属人的なノウハウを再利用可能な調査プレイブックに変えますが、書き方が悪い Skill はまったく使われません。この記事では、確実に起動し、構造化された調査フローに沿って動き、他の Skills と組み合わさって MTTR（平均解決時間）を短縮できる Skill の書き方を紹介します。 私たちが支援した、グローバルに事業を展開するある金融サービス企業では、チームの調査ノウハウを Skills に落とし込んだ結果、エージェントの位置づけが「面白いデモ」から「P1 インシデントの一次対応者」に変わりました。エージェントは、根本原因の候補を提示するようになったのです。これまでは、その候補を見つけるために、シニアエンジニアが多くのログを手作業で突き合わせる必要がありました。この企業が得た結論は、私たちの考えと一致していました。Skills の品質が、調査の品質を決めます。 背景：Skill とは何か Skill は、必須の SKILL.md と任意の参考資料（アーキテクチャ図、メトリクスのしきい値表、トラブルシューティングのフローチャートなど）をまとめた、自己完結型のディレクトリです。オープンな Agent Skills specification のサブセットに準拠しており、Markdown、PDF、画像、データファイルといった、実行を伴わない文書を扱えます。 SKILL.md の先頭には、フロントマター（メタデータブロック）として name と description を書く必要があります。エージェントは description を見て、その Skill が今の作業に関係するかどうかを判断します。ファイルの残りの部分が、調査手順そのものです。 my-skill/ ├── SKILL.md # 必須: フロントマター + 調査手順 ├── references/ # 任意: メトリクス表、エラーコード対応表など └── assets/ # 任意: 図、フローチャート、データファイル AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス に沿って Agent Space を導入済みであれば、Skills はその次のステップです。Skills を使うと、Agent Space 内でエージェントの振る舞いを特定の用途に合わせられます。 Skills がなくても、エージェントは AWS サービスに関する一般的な知識を使って調査できます。メトリクスを照会したり、ログやデプロイを確認したりすることもできます。しかし、チーム固有の調査のコツ、環境固有のしきい値、そのサービスで本当に重要なメトリクスは知りません。Skills はその差を埋めます。確認すべき項目を確認すべき順番で直接示すことで、調査の立ち上がりが速くなり、エージェントは汎用的な調査にありがちな試行錯誤を省けます。 Skill とエージェント指示の使い分け エージェントの振る舞いを変える手段は、Skills だけではありません。もう一つの手段がエージェント指示です。 AGENTS.md というファイルに保存し、Operator Web App の Knowledge ページで設定します。この 2 つは解決する問題が異なります。正しく使い分けると、エージェントは目の前の作業に集中でき、限られた作業メモリ（コンテキストウィンドウ）も効率よく使えます。 違いは「いつ読み込まれるか」です。 エージェント指示 ：常に有効。エージェントが何を扱っていても、セッション開始時にシステムプロンプトへ必ず組み込まれる Skills ：必要なときだけ有効。 description が目の前のタスクに合致したときにだけ読み込まれる つまり、エージェント指示は すべてのセッション での振る舞いを決め、Skill は 特定の状況 向けの専門的なプレイブックを与えます。この違いから、判断基準はシンプルになります。 すべての調査に適用する必要がある内容は、エージェント指示に書きます。たとえば、回答のフォーマット、「シークレットを平文で表示しない」といったセキュリティポリシー、「根本原因を提示する前に必ず直近のデプロイを確認する」といったチームのルールです。エージェント指示に書けば、これらが毎回読み込まれることを保証できます。一方、特定のシナリオだけで使う手順は、Skill に書きます。たとえば、RDS のコネクション枯渇や ECS のクラッシュループを調べる手順です。Skill は必要なときだけ読み込まれ、それ以外のときはコンテキストウィンドウを使いません。 実務上の違いを整理すると、次のとおりです。 観点 エージェント指示（ AGENTS.md ） Skills 読み込まれるタイミング 毎セッション、無条件 必要なとき（ description がタスクに合致したとき） 向いている用途 常に守るべきポリシー（フォーマット、セキュリティ、毎回行う確認） シナリオ別の手順（調査プレイブック） 適用範囲の決まり方 全エージェント、または特定のエージェントタイプを指定する 実行時にエージェントが description と照合する 数 エージェントごとに 1 つ（全体共通、またはマネージドエージェント単位） Agent Space ごとに複数 追加ファイル Markdown のみ（添付不可） Markdown に加えて参考ファイル、画像、データ サイズの考え方 固定上限 25 KB（変更不可）。できるだけ短く保つ（120 行程度を推奨） 必要なときだけ読み込まれるので、1 つひとつのテーマを絞る 見分け方のコツ：エージェントが「何を調査するのか」を知る前から目の前に置いておきたい内容ならエージェント指示です。「RDS のレイテンシ問題だ」とわかって初めて意味を持つ内容なら Skill です。 サイズには注意が必要です。エージェント指示は毎セッション読み込まれるため、その分、ユーザーの質問やログ、エージェント自身の推論に使える作業メモリが少なくなります。サービス側のガイダンスでも、エージェント指示は短く保ち、専門的な手順は Skills に移すことが推奨されています。あらゆる調査手順を詰め込んで肥大化した AGENTS.md はアンチパターンです。その内容は、テーマを絞った Skills に分割しましょう。 なお、エージェントを拡張する手段は他にもあります。カスタムエージェントを使うと、システムプロンプト・ツール・Skills を 1 つにまとめて、「定期ヘルスレポート」のような専用のワークフローを作れます。MCP サーバーを使うと、独自の診断ツールを追加できます。オープンソースの AWS DevOps Agent Tools リポジトリには、Skills、カスタムエージェント、MCP サーバーのすぐに使えるサンプルがあり、そのまま取り込むことも、自分用に作り変える出発点にすることもできます。 確実に起動する description を書く フロントマターの description が、Skill を読み込むかどうかを決めます。ここが最も効果の大きいポイントです。 description があいまいだと、中の手順がどれほど優れていても、エージェントは Skill を読み飛ばします。 description は「エージェントの視点」で書きます。その Skill を使うべきサービス、エラーの種類、症状、シナリオを具体的に書いてください。 あいまいすぎる例： --- name: database-skill description: データベースの問題に対応する。 --- 具体的で実用的な例： --- name: rds-connection-exhaustion description: Amazon RDS および Amazon Aurora のコネクション枯渇に関する調査手順。 max_connections の上限到達、コネクションプールの設定ミス、アイドルコネクションの 蓄積を扱う。DatabaseConnections アラーム、接続タイムアウトエラー、 "too many connections" というアプリケーションエラーを調査するときに使用する。 --- インシデントの最中にオンコール担当者が検索しそうな言葉を考えてみてください。アラーム名、エラーメッセージ、症状などです。こうした言葉こそ description に入れるべきものです。 セルフチェック： description を読んで、「インシデントのトリアージ中だったら、この説明だけでこの Skill が当てはまるかどうか判断できるか？」と自問してください。答えが「いいえ」なら、説明をさらに具体的にしてください。 私たちも、これを実際に経験しました。 db-health という Skill に「データベースの健全性を監視する」という意味の description を付けていたところ、本番の RDS インスタンスが午前 3 時に max_connections の上限に達しても、エージェントはこの Skill を読み込みませんでした。インシデントで発火していたアラーム RDS-DatabaseConnections-Critical と、「データベースの健全性を監視する」という説明に、一致する言葉がなかったからです。 そこで description を「RDS のコネクション枯渇、 max_connections の超過、 DatabaseConnections アラームの急増に関する調査手順」という内容に書き換えました。Skill も中の手順も、まったく同じままです。それでも、以後はそのアラームが発火するたびに、エージェントが必ずこの Skill を読み込むようになりました。 指示を調査ステップとして構成する Skill は、事実を並べたリストではなく、シニアエンジニアの調査プレイブックのように読めるものにします。各ステップでは、何を確認し、何に注目し、結果に応じて次に何をするかをエージェントに伝えます。 機能する Skill と機能しない Skill の差は、多くの場合、判断ロジックが入っているかどうかです。まず、うまく機能しない例を示し、続いてうまく機能する例を示します。 うまく機能しない例 — あいまいで、受動的で、判断ロジックがない： --- name: ecs-skill description: ECS の問題の調査を支援する。 --- # ECS の調査 ECS タスクの状態を確認する。CPU とメモリのメトリクスを見る。 直近のデプロイを確認する。ロードバランサーを確認する。 何かおかしければ、さらに調べる。 この例には 2 つの問題があります。1 つ目は、 description が広すぎるため、Skill が安定して起動しないことです。「ECS の問題」はあらゆる状況に当てはまるようで、実際にはどれにも当てはまりません。2 つ目は、指示が調査ワークフローではなく、確認対象を並べたチェックリストになっていることです。順序もしきい値もなく、「おかしい」とは何か、次に何をすべきかを示す判断ポイントもありません。 うまく機能する Skill には、具体的な起動条件、構造化されたロジック、判断に応じた明確な分岐があります。 --- name: ecs-task-crash-loop description: ECS タスクがクラッシュループ（0 以外の終了コードで STOPPED を 繰り返す状態）に陥った場合の調査手順。OOM kill（メモリ不足による強制終了）、 ヘルスチェックの失敗、コンテナ間の依存関係の問題を扱う。 ECS-TaskFailure アラームが発火したとき、またはタスクが PENDING と STOPPED を 繰り返しているときに使用する。 --- # Step 1: 障害のパターンを特定する 対象サービスで停止したタスクを過去 2 時間分照会する。停止理由ごとに次のように分類する。 - 終了コード 137 → OOM kill。Step 2 へ進む。 - 終了コード 1 かつ "essential container exited" → 依存関係の障害。Step 3 へ進む。 - 終了コードなし + "health check failed" → コンテナは稼働しているが応答がない。 Step 4 へ進む。 # Step 2: メモリ不足を調査する 対象のタスク定義について、CloudWatch Container Insights のメモリ使用率を取得し、 タスクのハードメモリ上限と比較する。障害が起きる前の 30 分間、使用率が上限の 90% を継続して超えていた場合は、メモリ割り当ての増加を推奨する。あわせて、 メモリ使用量に影響する変更が含まれていないか、直近のデプロイを優先的な 調査対象として挙げる。 # Step 3: 依存関係の障害を調査する タスクの状態が変化したタイムスタンプを比較して、最初に終了したコンテナを特定する。 そのコンテナのログで起動時のエラーを確認する。よくある原因は、環境変数の不足、 依存先サービスのヘルスチェック失敗、レジストリ障害によるイメージ取得の失敗である。 # Step 4: ヘルスチェックのタイムアウトを調査する ヘルスチェックの設定（interval、timeout、retries）を、コンテナが実際に起動するまでの 時間と比較する。ヘルスチェックが許容する時間よりも初期化に時間がかかる場合、 コンテナは正常になる前に停止させられる。直近のデプロイで起動時間が延びていないか （新しい依存関係の追加、読み込むモデルの大型化、起動時のデータベースマイグレーションなど） を確認する。 パターンに注目してください。各ステップには、明確なアクション、注目すべき具体的なポイント、そして次のステップを決める判断ポイントがあります。エージェントはこれを、ただ読むだけの一覧としてではなくフローチャートのようにたどります。 事実やメトリクスを並べるだけで、それを使って何をするかを書かない Skill は避けてください。Amazon CloudWatch のメトリクスのしきい値表は参考ファイルとしては役立ちますが、 SKILL.md 本体には、そのしきい値を使う調査ロジックを書きます。 適切なエージェントタイプに絞る すべての Skills が、調査のすべてのフェーズに関係するわけではありません。AWS DevOps Agent には複数のエージェントタイプがあり、Skill を作成・アップロードするときの Agent Type 設定で、どのエージェントタイプに使わせるかを指定できます。 デフォルトは Generic で、すべてのエージェントタイプがその Skill を使えます。使い始めはこれが適切な選択です。その他のエージェントタイプは、調査や対応のライフサイクルの各フェーズに対応しています。 エージェントタイプ 実行されるタイミング 役割 Skill の例 Incident Triage インシデントの受信直後 新しいインシデントを進行中の調査と関連付け、重大度を分類し、調査するかスキップするかを判断する 計画メンテナンス中のスキップ条件、影響を受けたサービスのティアに基づく重大度の分類 Incident RCA トリアージで「調査する」と判断された後 メトリクス、ログ、トレース、デプロイを照会し、根本原因を深く調査する RDS コネクション枯渇のプレイブック、ECS クラッシュループの分析 Incident Mitigation 根本原因が特定された後 当面の対処と長期的な再発防止策を含む、段階的な対応プランを作る デプロイのロールバック手順、コネクションプールのスケーリングに関する指針 On-demand チャットで明示的に呼び出されたとき インシデント対応以外の、その場の質問や作業に応える アーキテクチャドキュメントへの問い合わせ、キャパシティプランニングの計算 Evaluation 定期的、またはスケジュールに従って インフラの健全性、構成ドリフト、オブザーバビリティのギャップを事前に評価する 毎月のオブザーバビリティギャップ分析、セキュリティ態勢のチェック Skill は読み込まれるたびにコンテキストを消費します。最初のトリアージの段階で詳細な対処プレイブックを読み込むと、まだ必要のない指示にコンテキストを使ってしまいます。エージェントタイプを絞ると、この無駄が減り、エージェントは今のフェーズに集中できます。 実践的な進め方として、まずはすべての Skills を Generic で作成します。何回か調査を実行したら、各 Skill がどのフェーズで最も役立ったかを振り返り、対象を絞り込みます。デプロイのロールバック手順は Incident Mitigation に適しています。トリアージ中に読み込んでも、エージェントはまだその手順を実行できず、コンテキストを無駄にするだけです。オブザーバビリティギャップ分析は Evaluation に適しています。これはインシデント対応ではなく、事前に行う作業です。重大度の分類ガイドは Incident Triage に適しています。アラームの発火直後に使う必要があり、エージェントが 20 分調査したあとでは遅すぎます。 On-demand と Generic の違いは重要です。On-demand の Skill は、誰かがチャットでエージェントに明示的に質問したときにだけ起動します。その場の問い合わせに答えるためにチームのアーキテクチャをまとめた Skill は、On-demand に置きます。インシデント中に自動で起動してほしい Skill は、インシデント系のタイプか Generic に置きます。 AWS DevOps Agent が Directed actions に対応したことで、Incident Mitigation 向けの Skills は見直す価値が出てきました。Directed actions とは、接続済みのサービスや AWS アカウントに対して、エージェントに明示的に実行を依頼する操作のことです。 読み取り専用のアクションはデフォルトで利用できます。リソースを作成・変更するアクションはデフォルトで無効になっており、使うには明示的に有効化する必要があります。承認の操作と、承認後に実行されたアクションは、どのオペレーターが承認したかがわかる形で AWS CloudTrail に記録されます。 Directed actions を有効にすると、Incident Mitigation の Skill は「対処方法を説明する」だけでなく、「承認された対処を実行するまでエージェントを導く」ことができるようになります。こうした Skills も、他の Skills と同じ規律で書いてください。明確な前提条件、はっきりした停止ポイント、そして実行する前にプランを示して承認を求める指示を入れます。 私たちが Skills を特定のエージェントタイプに絞り込んだところ、エージェントの調査結果は焦点がはっきりしたものになりました。トリアージの回答は、根本原因を早まって推測するのではなく、簡潔な重大度の評価になりました。RCA のフェーズでは、まだ必要のない対処手順にコンテキストウィンドウを使わずに済むぶん、より深く調査できるようになりました。 参考資料を含める Skill に参考ファイルを添えておくと、エージェントが調査中に推論の材料として使える構造化データを渡せます。 SKILL.md には調査ロジックを、参考ファイルにはそのロジックが使うドメイン知識を置きます。 メトリクスのしきい値表は、その環境における「正常」と「要注意」の基準を定めます。エージェントは調査中、現在のメトリクスをこの基準と比較できます。 # references/rds-metrics-reference.md | メトリクス | 正常な範囲 | 調査を始めるしきい値 | |---------------------|-----------------------------|---------------------------| | DatabaseConnections | max_connections の 70% 未満 | max_connections の 80% 超 | | ReadLatency | 5 ms 未満 | 20 ms 超 | | WriteLatency | 5 ms 未満 | 20 ms 超 | | FreeStorageSpace | ストレージ全体の 30% 超 | ストレージ全体の 20% 未満 | | CPUUtilization | 70% 未満 | 85% 超 | エラーコードの対応表は、わかりにくいエラーコードを調査の進め方に結び付けます。たとえば、 ORA-12519 の意味をエージェントに推測させる代わりに、「リスナーの接続数の上限に到達。コネクションプールの設定を確認する」と直接対応付けられます。 アーキテクチャの情報には、その環境固有のサービス間の依存関係、データの流れ、障害ドメインを記録します。インフラ構成を見ただけでは障害の影響範囲がわかりにくいマイクロサービス構成で、特に役立ちます。 エスカレーション手順は、他のチームを巻き込むべきタイミングと方法をエージェントに伝えます。正式なドキュメントにはほとんど残っていないものの、インシデント対応では欠かせない運用知識です。 参考資料を含む Skill のディレクトリ構成は、次のようになります。 ecs-deployment-investigation/ ├── SKILL.md ├── references/ │ ├── ecs-error-codes.md │ ├── deployment-strategies.md │ └── healthy-thresholds.md └── assets/ └── ecs-investigation-flow.png Skills を組み合わせてエンドツーエンドのワークフローを作る 個々の Skill は単独でも役立ちますが、本当の価値は Skills を組み合わせたときに生まれます。AWS DevOps Agent は 1 回の調査で複数の Skills を読み込むため、内容が重複せず、互いを補完するように Skills を設計できます。 たとえば、デプロイ後に Amazon ECS のサービスが失敗し始めたケースを考えます。この場合、3 つの Skills を連携させられます。1 つ目は CI/CD システムから直近のデプロイを取得する Skill、2 つ目はコードリポジトリから関連する変更を探す Skill、3 つ目は ECS タスクの失敗とスケーリングの挙動を調査する Skill です。 エージェントはこの 3 つをすべて読み込み、デプロイのタイミングとコードの変更、サービスの健全性を突き合わせます。シニアエンジニアが行うのと同じワークフローを、自動で実行するわけです。 設計の原則はシンプルです。各 Skill は単独でも役立ち、かつ他の Skills と組み合わせられるようにします。たとえば CI/CD パイプラインの Skill は、コードリポジトリの Skill も読み込まれていることを前提にしてはいけません。単独でも意味のある調査結果を出し、他の Skills の結果と組み合わさるとさらに価値が高まる、という形にします。 これは、調査全体を 1 つで網羅しようとする巨大な Skill を作るべきではない、ということでもあります。「ECS に関するすべて」を扱う Skill は、 description を十分に具体的にできないため安定して起動せず、サイズも大きすぎて効率よく読み込めません。「ECS のデプロイの問題」「ECS のスケーリングの問題」「ECS のネットワークの問題」のようにテーマを絞った Skills に分け、必要に応じてエージェントに組み合わせさせましょう。 カスタム MCP ツールの使い方をエージェントに示す AWS DevOps Agent にカスタムの MCP サーバーを接続している場合、そのツールを効果的に使う方法を Skill に書いておけます。Skill がないと、エージェントはツールがあることはわかっていても、その環境に合ったパラメーターや結果の読み解き方まではわからない場合があります。 --- name: custom-deployment-tracker-investigation description: 社内のデプロイ追跡用 MCP 連携を使って、直近のデプロイに関連する インシデントを調査する手順。インシデントが、サービスのデプロイや CI/CD パイプライン経由の設定変更と関連していそうなときに使用する。 --- # デプロイとの関連を調べる 直近のデプロイが関係していそうなインシデントを調査するときは、次の手順に従う。 ## Step 1: 直近のデプロイを照会する `deployment-tracker-get-changes` ツールを、次のパラメーターで使う。 - `environment`: 影響を受けている環境に合わせる（production、staging） - `timeRange`: インシデント開始時刻の 4 時間前を指定する - `service`: 影響を受けているサービスの識別子 ## Step 2: デプロイとインシデントの時系列を突き合わせる デプロイの時刻とインシデントの開始時刻を比較する。インシデント開始の直前 30 分間に 行われたデプロイは、疑わしい候補として優先的に調べる。そのデプロイに設定変更や 依存関係の更新が含まれていたかを確認する。これらは、デプロイ後にトラフィックが 増えてから表面化するレイテンシ関連のインシデントでよくある原因である。 このパターンでは、いつツールを使うか、シナリオごとにどのパラメーターを使うか、結果をどう読み解くかを書いています。これによってエージェントは、「デプロイ追跡ツールにアクセスできる」状態から、「この環境でデプロイ起因のインシデントを調査するとき、このツールをどう使えばよいかわかっている」状態になります。 Skills とメモリは補い合う Skills は、ユーザーが書く指示です。一方、メモリは、エージェントが蓄積し、ユーザーが整理して活用できる運用知識です。AWS DevOps Agent は、環境のトポロジー、コードの依存関係、パイプラインの構成、ツールの使い方のパターンなど、学習した知識をメモリとして保持するようになりました。また、チーム、サービス、繰り返し発生する問題ごとに運用知識をまとめる独自のメモリストアも作成できます。この 2 つは互いに補い合います。Skill は調査のワークフローを記述し、メモリストアはそのワークフローが参照する環境固有の事実を保持します。 実践的な分担としては、長く使える再利用可能な手順は Skill に書き、変化の速い環境固有の事実はメモリに置きます。メモリは Skill を編集せずに更新できます。こうすると Skills が安定し、次のセクションで説明する「Skill の陳腐化」も起きにくくなります。変わりやすい情報を、あらかじめメモリに移しているからです。 見落としやすい失敗パターン 具体的な description を書く、判断の分岐を入れる、巨大な Skill を作らない、といった基本はここまでで説明しました。以下の失敗はもっとわかりにくく、本番で Skills を数週間から数か月運用したあとに表面化します。 組み合わせると矛盾する Skills。 2 つの Skills が同時に読み込まれ、相反する指示を出す場合があります。たとえば「データベースのコネクション数を増やす」Skill と「コネクションプールのサイズを減らす」Skill が同じ RDS のインシデントで両方起動すると、エージェントは矛盾する推奨を受け取ることになります。新しい Skill を公開する前に、同じアラームや症状を対象にしている既存の Skills を確認しましょう。同時に読み込まれる可能性がある場合は、判断の境界をはっきり書いてください。たとえば「コネクション数が多くても CPU 使用率が正常なら、コネクションプールのリークと判断してコネクション数を減らす。コネクション数が多く、CPU 使用率も上限に張り付いているなら、データベースの容量を増やす」のように書きます。 インフラの変化に追いつかず、陳腐化する Skills。 半年前に ECS クラスター向けに書いた Skill は、すでに存在しないタスク定義、サービス名、メトリクスのしきい値を参照しているかもしれません。コードと違い、Skills が古いインフラを参照しても、その問題は明確なエラーとして表れません。エージェントは古い手順にそのまま従い、的外れな調査結果を出してしまいます。Skills はランブックと同じように扱い、四半期ごとに見直して、変更管理のプロセスに組み込みましょう。 SKILL.md には last_verified のコメントを入れて、調査手順を実際のインフラで最後に検証した時期がレビュー担当者にわかるようにしてください。しきい値、リソース名、依存関係の図など、変わりやすい情報はメモリストアに移し、Skill とは別に更新できるようにすることも検討しましょう。 エージェントが臨機応変に動けない、厳格すぎる手順。 「メトリクス X を確認し、次に Y、次に Z を確認する」と厳密な順序を決めた Skill は、実際のインシデントが想定したパターンと違ったときに、エージェントを一本道に閉じ込めてしまいかねません。抜け道がないと、エージェントは全ステップを律儀にこなして「問題なし」と報告します。その間も、本当の根本原因は、Skill が一度も触れていないシステムに潜んだままです。抜け道となる分岐を用意してください。Step 1 の結果が正常だったときに備えて、「Step 4 に進む」や「この Skill は当てはまらない可能性がある。ここまでの結果を報告し、一般的な調査に任せる」といった指示を入れておきます。 意図せず対象範囲が重複する Skills。 時間がたつと、別々のメンバーが書いた Skills の対象範囲が重なってきます。たとえば「API レイテンシの調査」Skill と「サービスのタイムアウトの調査」Skill が、同じ CloudWatch メトリクスを確認し、同じ呼び出し経路をたどっている、といったケースです。エージェントは両方を読み込んで同じ作業を繰り返し、重複した調査結果にコンテキストを使ってしまいます。Skills の一覧表を管理しましょう。Skills と、それが対象とするアラームやサービスを対応付けた簡単なスプレッドシートでも構いません。新しい Skill を追加するときに、重複がないかを確認してください。 はじめ方 まずは、直近の四半期のインシデントのカテゴリーから上位 3 つを選んでください。これらは、Skill の効果を最も早く実感できるシナリオです。 それぞれについて、普段その種類のインシデントに対応しているシニアエンジニアに話を聞きます。「このインシデントで呼び出されたら、最初に何を確認しますか？」と尋ねてください。その答えが、Skill の Step 1 になります。続けて「次に何を確認しますか？ X と Y のどちらなのかは、何で見分けますか？」と尋ねれば、調査のワークフローができあがります。 明確で具体的な手順を書いた 20 行の SKILL.md は、あいまいな内容の 200 行のドキュメントよりも効果があります。シンプルに始めて実際に調査を実行し、エージェントがうまくできたところ、つまずいたところをもとに改善していきましょう。Skills が増えてきたら、Skills やその他のアセットを Infrastructure as Code として宣言的に管理し、他のインフラと同じようにパイプラインを通じて複数の Agent Space にデプロイできるようになります。 ゼロから書き始めたくない場合は、オープンソースの AWS DevOps Agent Tools リポジトリに、コミュニティが作成した Skills、カスタムエージェント、MCP サーバーがあります。そのまま取り込むことも、手を加えて使うこともできます。 Skill の構成と作成方法の詳細は AWS DevOps Agent Skills のドキュメント を、Agent Space のセットアップについては AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス を参照してください。 Skills は、エンジニアがチームを異動しても、組織の知識が失われないようにする仕組みです。チームがうまく調査できたインシデントは、どれも「まだ書かれていない Skill」です。 最初の Skill は、チームで最も経験豊富なエンジニアが、普段ほとんど意識せずに行っている調査から始めましょう。どのダッシュボードを開き、どのロググループを検索し、どのメトリクスがどのしきい値を超えたら「すぐにロールバック」なのかを、その人はすでに知っています。それを書き出せば、深夜 2 時に誰が呼び出されても、その専門知識が活かされるようになります。 Nisha Notani Nisha Notani は、AWS ロンドンのシニアテクニカルアカウントマネージャーです。エンタープライズのお客様を対象に、AWS 環境全体のオブザーバビリティ、オペレーショナルエクセレンス、レジリエンスの強化を支援しています。メンターやコーチとしても積極的に活動しており、学校やカレッジでボランティアとして学生のキャリア形成を手助けしています。 Damini Kumar Damini Kumar は、AWS シドニーのテクニカルアカウントマネージャーです。エンタープライズのお客様とともに、AWS 環境でのクラウド活用、オペレーショナルエクセレンス、イノベーションを推進しています。AI、オブザーバビリティ、自動化に強い関心を持ち、お客様向けのワークショップやイネーブルメントセッション、ナレッジ共有の取り組みを通じて、AWS の技術コミュニティにも積極的に貢献しています。また、新しいクラウド技術や AI 技術を、お客様や幅広い技術コミュニティにとって実用的で身近なものにすることに力を注いでいます。 本ブログは 2026 年 9 月 30 日に公開された Best practices for writing AWS DevOps Agent Skills の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

はじめに 8 月と 9 月は、 Amazon CloudWatch Omni が一般提供 (GA) となりました。Omni は AI ファーストかつアプリケーション中心のオブザーバビリティを提供し、AWS アカウント、リージョン、Azure のワークロードをまたいだテレメトリを 1 つのスペースに集約します。アラームにはウォームアップ期間 (アラーム作成後、一定時間だけ評価を遅延させる機能) とウォールクロック評価ウィンドウ (毎時 0 分や深夜 0 時といった暦の境界に評価を揃える機能) が追加され、起動時のデータの欠落やスライディングウィンドウ (時間の経過とともに対象範囲がずれていく従来の評価ウィンドウ) 特有のエッジケースから生じるノイズを削減できるようになりました。データベースのオブザーバビリティは Amazon EC2 上に自前で構築・運用する自己管理型 PostgreSQL と Amazon Aurora DSQL にも対応し、デプロイ形態を問わずデータベースフリート全体を 1 つのコンソールでモニタリングできます。AWS CloudTrail には AI による調査機能が加わり、アカウント内で誰が何をしたのかを Amazon Q Console にふだんの言葉で質問できるようになりました。ログ収集は対応範囲を拡大し、journald のネイティブサポート、GeoIP・Amazon RDS・XML 用の新しいパイプラインプロセッサ、一元化されたログへのタグの伝播に対応しました。そして AWS HealthOmics から Amazon WorkSpaces、Amazon MSK まで、ポートフォリオ全体のサービスがより充実したテレメトリを CloudWatch に発行し始めており、その多くは OpenTelemetry を使って構築されています。 それでは、Amazon CloudWatch と AWS DevOps Agent の最新情報をご紹介します。 これらのローンチのライブデモをご覧になりたい方は、2026 年 10 月 13 日 11:00〜12:00 (ET、日本時間 10 月 14 日 0:00〜1:00) 開催の「 I didn’t know Amazon CloudWatch could do that! 」ウェビナー (英語開催) にご登録ください。過去のまとめを見逃した方は、「 今月の AWS オブザーバビリティ 」の 2026 年 1 月〜5 月 、 2026 年 6 月 、 2026 年 7 月 のブログをご覧ください。 Amazon CloudWatch Omni のご紹介: エージェントとアプリケーションのための AI ファーストなオブザーバビリティ この期間で最も大きなローンチは、一般提供が開始された Amazon CloudWatch Omni です。Omni は、チームとそのチームが運用するアプリケーションを軸に構成し直し、Amazon CloudWatch を AI 駆動のオブザーバビリティへと進化させたものです。中央アカウントにスペースを作成すると、AWS アカウントやリージョンをまたいだテレメトリに加えて、Azure のワークロードを含む他のクラウドのテレメトリも確認できます。Omni はサービスを自動的に検出し、依存関係をマッピングし、ゴールデンメトリクスを提示することで、運用ワークフローを効率化します。 図 1: アプリケーションと AI エージェントが 1 つのビューを共有します。CloudWatch Omni はインフラストラクチャとエージェントのオブザーバビリティを単一の体験に統合し、IDE または Omni の Web UI 上でエンタープライズ SSO とともに提供します。 Omni の特徴は、テレメトリとの関わり方そのものです。自然言語でチャットすれば、Omni が関連するシグナルを見つけ出し、動的なビューを構築し、AWS DevOps Agent を活用して根本原因の特定を支援します。自分で操作したい場合は、重要なシグナルをクリックしながら辿っていくこともできます。パフォーマンスが劣化しているアプリケーションを調査する場合でも、トレースや評価を深掘りする場合でも同様です。 Omni は、LangGraph、CrewAI、OpenAI Agents SDK、Vercel AI SDK、Strands といったフレームワークにわたって、評価駆動の開発ワークフローによるエージェントのオブザーバビリティを提供します。プロンプト、モデル呼び出し、ツール呼び出しのそれぞれについて品質を評価し、実験を実行できます。VS Code、Cursor、Kiro 用の CloudWatch Omni 拡張機能は無料で利用でき、ローカル環境でのエージェントの計装、デバッグ、評価が可能です。 CloudWatch Omni について詳しくは、以下のウェビナーをご覧ください。 10 月 7 日 14:00〜15:00 ET (GMT-4)、日本時間 10 月 8 日 3:00〜4:00 、 10 月 7 日 9:00〜10:00 シンガポール時間 (GMT+8)、日本時間 10 月 7 日 10:00〜11:00 、 10 月 8 日 14:30〜15:30 BST (GMT+1)、日本時間 10 月 8 日 22:30〜23:30 。 よりスマートなアラームの構築: ノイズの削減と整合性の向上 今回のアラーム関連のローンチで最も明確なテーマは、アラームが「いつ、どのように評価するか」をより賢く判断できるようにすることです。 Amazon CloudWatch で、 メトリクスアラームとログアラームにウォームアップ期間を設定 できるようになりました。アラームを作成した後、設定した時間だけ評価を遅延させる機能です。これにより、新しいリソースやサービスが起動してメトリクスの発行を開始するまでの間に発生する、データの欠落に起因するノイズを削減できます。たとえば、CI/CD パイプラインで新しいマイクロサービスとそのアラームを同時にプロビジョニングするチームは、ウォームアップ期間を設定しておくことで、サービスの起動中にアラームがオンコールエンジニアを呼び出してしまうことを防げます。モードは 2 つあり、指定した固定時間だけ待機するモードと、メトリクスのデータが評価ウィンドウを満たした時点で CloudWatch が自動的に評価を開始するモードがあります。ウォームアップ期間は 1〜2,880 分の範囲で設定でき、標準の CloudWatch アラーム料金以外の追加料金はかかりません。 CloudWatch アラームは、 ウォールクロック評価ウィンドウもサポート するようになりました。毎時 0 分、深夜 0 時、週の開始時点といった固定のカレンダー境界にアラームの評価を揃えられます。これは既存のスライディングウィンドウの動作を補完するもので、定期実行のワークロードやビジネスサイクルに沿ったワークロードを想定した機能です。スライディングウィンドウを使った日次バックアップのアラームは、連続するバックアップの間隔が 24 時間をわずかに超えただけで、暦日ごとにはバックアップが成功しているにもかかわらず誤って状態が変化することがあります。ウォールクロックウィンドウは暦日ごとに独立して評価するため、この問題が解消されます。タイムゾーンを指定できるため日次アラームを自社の営業日に合わせられ、夏時間への移行も自動的に処理されます。 データベースオブザーバビリティの拡大: 対応エンジンとデプロイ形態の拡充 Database Insights は対応エンジンを拡大し続けており、この 2 か月で 2 つの重要なマイルストーンに到達しました。 Amazon CloudWatch Database Insights が、Amazon EC2 上で稼働する 自己管理型 PostgreSQL データベースをサポート しました。CloudWatch エージェントを使って自己管理型インスタンスからヘルスとパフォーマンスのデータを収集すると、それらが Database Insights のフリートビューに表示され、データベース負荷、待機イベントの分析、クエリレベルの統計、ホストメトリクスといったライブのパフォーマンスデータを確認できます。AWS マネージドのデータベースですでに使っているものと同じコンソールとワークフローでモニタリングとトラブルシューティングができるため、PostgreSQL フリート全体を 1 か所でモニタリングできます。 Amazon Aurora DSQL に、ステートメント単位・クラスターレベルのパフォーマンスモニタリングを提供する 新しい Database Insights メトリクス が追加されました。アクティブなすべてのクラスターセッションについて、サンプリングされた待機状態と正規化された SQL ステートメントを取得するため、パフォーマンスの問題を診断し、最もリソースを消費しているクエリを特定できます。このメトリクスは Database Insights、PromQL、および Aurora DSQL のシステム診断 AI スキルからクエリでき、デフォルトで追加費用なしに利用できます。 AI による自然言語での調査 AWS CloudTrail が Amazon Q Console と統合 され、自然言語で AWS アカウントのアクティビティを調査できるようになりました。Amazon Q Console に CloudTrail の設定について質問したり、セキュリティ調査のために記録済みのイベントをクエリしたり、クエリの記述やログファイルの手動でのパースをせずに運用上の問題をトラブルシューティングしたりできます。 この統合により、トレイルが適切に設定されているかの確認、ログ記録範囲の抜け漏れの特定、追跡しているデータイベントソースの確認が可能になります。セキュリティ上の懸念については、特定の IAM ロールに誰がアクセスしたか、VPC 設定にどのような変更が加えられたか、過去 1 週間に不正なアクセス試行がなかったかといった質問ができます。運用のトラブルシューティングでは、特定のリソースを作成または削除したのは誰か、どの API 呼び出しがエラーを発生させているか、特定の IP アドレスからのアクティビティの追跡、請求額が急増した理由の特定などを Q Console に尋ねられます。Q Console はお客様に代わってトレイル、関連する CloudWatch ロググループ、イベントデータストアをクエリし、一般的なドキュメントの内容ではなく実際のアカウントのアクティビティに基づいた回答を提供します。 大規模なログの収集とエンリッチメント クエリやダッシュボードに届く前の段階で、収集できる対象とエンリッチできる方法を拡張するローンチが複数ありました。 Amazon CloudWatch エージェントが、Linux インスタンス上の systemd journal (journald) ログをネイティブに収集 できるようになりました。ログをいったんディスク上のファイルに書き出す必要はありません。Amazon Linux 2023 を含む多くの最新の Linux ディストリビューションは systemd journal を主要なロギングシステムとして採用しており、デフォルトでは従来のテキストログファイルを出力しません。エージェントは journald のエントリをネイティブに読み取り、systemd ユニット、優先度、プロセス情報といった journald が取得する構造化メタデータを保持します。systemd ユニット、ジャーナルの優先度レベル、ジャーナルフィールドの一致条件でログエントリをフィルタリングしたり、発行前に正規表現フィルターを適用したりできるため、ノイズを削減し、ログの量とコストをコントロールできます。 Amazon CloudWatch Pipelines に、取り込み時にログデータをパースおよびエンリッチする 3 つの新しいプロセッサ が追加されました。Amazon RDS プロセッサは、コンプライアンスレポート向けに Aurora の監査ログとエラーログを構造化フィールドにパースします。XML パーサーは、XML 文字列を含むフィールドを JSON に変換します。GeoIP プロセッサは、セキュリティ分析のために任意の IP アドレスフィールドに都市、国、座標といった地理的コンテキストを付加します。これらのプロセッサは個別にも、1 つのパイプライン内で組み合わせても利用でき、追加費用はかかりません。 CloudWatch Centralization が、一元化ルールによって作成された送信先ロググループに、ソースアカウントのロググループのタグをコピー し、同期を維持するようになりました。プラットフォームチームは、一元化されたロググループで Application タグや CostCenter タグを保持しておくことで、それらのタグを使って IAM 条件でアクセス範囲を限定したり、AWS Cost Explorer でチームごとに一元化されたログのコストをレポートしたりできます。 Transit Gateway ピアリングをまたぐネットワークヘルスのモニタリング CloudWatch Network Monitoring が、AWS Transit Gateway のリージョン間ピアリング接続を経由するパスまで ネットワークヘルスインジケーターを拡張 しました。これまで合成モニターがカバーしていたのは、AWS Direct Connect 経由で接続するパスのみでした。今回から、Transit Gateway のリージョン間ピアリングを経由してピアリング先リージョンの送信先に到達するパスについて、ピアリング接続までの AWS ネットワークパスのヘルス状態がインジケーターに反映されます。これにより、ネットワーク運用者やアプリケーション開発者が、これらのパスで発生した劣化の原因を切り分けるのに費やす時間を短縮できます。 AWS サービスのオブザーバビリティ統合の深化 この 2 か月で、ポートフォリオ全体の AWS サービスが CloudWatch との統合を深めました。 AWS HealthOmics が、 14 個のリアルタイムの実行メトリクスを CloudWatch に発行 するようになりました。CPU と GPU の使用率、メモリ使用量、ファイルシステムの使用量と I/O、ネットワークスループット、エフェメラルストレージをカバーします。メトリクスは CloudWatch の OpenTelemetry 標準で出力されるため、ネイティブの CloudWatch ダッシュボードやアラームに加えて、サードパーティのオブザーバビリティツールと統合することもできます。実際の使用量と割り当て済みリソースを比較することで、バイオインフォマティクスワークフローのコンピューティングとストレージを過不足のないサイズに見直せます。 Amazon WorkSpaces と Amazon WorkSpaces Applications が、いずれも パフォーマンスとセッションヘルスに関する追加のメトリクス を CloudWatch に発行するようになりました。ネットワークパフォーマンス (TCP 再送率、輻輳ウィンドウ)、コンピューティングリソースの使用率 (GPU 使用率、CPU キュー長)、ストレージメトリクス (ディスク I/O キュー長、メモリページのハードフォールト)、セッションのライフサイクルイベントをカバーします。 Amazon ECS が Amazon EC2 G6f インスタンスでの GPU の分割スケジューリングをサポートし、NVIDIA L4 Tensor Core GPU の 8 分の 1 という小さな GPU パーティション上でワークロードを実行できるようになりました。 GPU メトリクスは CloudWatch Container Insights から利用でき 、自動ヘルスモニタリングが GPU のハードウェア障害を検出して異常なインスタンスを置き換えることで、ワークロードへの影響を最小限に抑えます。 AWS Cloud Operations Blog の関連記事 (2026 年 8 月〜9 月) 2026 年 8 月〜9 月に AWS Cloud Operations Blog で公開された記事は以下のとおりです。 Introducing Amazon CloudWatch Omni: Observability for the AI era – Mukul Karnik Root cause analysis with Amazon Managed Service for Prometheus and AWS DevOps Agent – Mohamed Sherif Investigate your AWS account activity in plain language with Amazon Q – Rizwan Mohammed, Parijat Protim Bezbaruah, Samir Behara Reduce MTTR with AI-Driven RCA Using AWS DevOps Agent and Splunk – Amandeep Singh, Aakash Tanwani Amazon CloudWatch Logs で Application Load Balancer のログを分析する – Raviteja Sunkavalli, Siva Guruvareddiar Multi-cloud observability with Amazon CloudWatch using bearer token auth and OpenTelemetry – Imaya Kumar Jagannathan, Stephen McCurry Use CloudWatch syslog and log alarms to give AWS DevOps Agent on-premises visibility – Salman Ahmed まとめ 8 月と 9 月のローンチのハイライトは、AI ワークロードとエージェントのための AI ファーストかつアプリケーション中心のオブザーバビリティソリューションである CloudWatch Omni です。アラームはウォームアップ期間とウォールクロックウィンドウによってより賢くなり、ノイズを削減しつつ現実のスケジュールに合わせられるようになりました。データベースのオブザーバビリティは、Aurora DSQL から自己管理型 PostgreSQL までフリート全体をカバーします。AI による調査機能によって、CloudTrail をふだんの言葉でクエリできるようになりました。ログ収集は journald、より大きな API Gateway の実行ログ、新しいパイプラインプロセッサへと広がりました。そしてポートフォリオ全体の AWS サービスがより充実したテレメトリを CloudWatch に発行しており、いずれも OpenTelemetry ファーストという方向性を継続しています。 これらの機能を使い始めるにあたっての要点を以下に挙げます。 CloudWatch Omni のスペースを作成 してチーム用に SSO を設定し、VS Code、Cursor、または Kiro 用の CloudWatch Omni 拡張機能をインストールして、ローカル環境でエージェントを計装・評価する。 新しいアラームに ウォームアップ期間を設定 して起動時のノイズを解消し、定期実行のワークロードやビジネスサイクルに沿ったワークロードにはウォールクロック評価ウィンドウを追加する。 Amazon EC2 上で稼働する自己管理型 PostgreSQL インスタンスで Database Insights を有効化 する。 CloudTrail の設定 やアカウントのアクティビティについて、Amazon Q Console に質問する。 CloudWatch エージェントの設定 に journald のセクションを追加し、CloudWatch Pipelines に GeoIP、Amazon RDS、XML のプロセッサを追加する。 最近のローンチの一覧については、Amazon CloudWatch で絞り込んだ AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 2026 年 10 月 13 日 11:00〜12:00 (ET、日本時間 10 月 14 日 0:00〜1:00) 開催の「 I Didn’t Know Amazon CloudWatch Could Do That! 」ウェビナー (英語開催) にご参加ください。これらの新機能の実際の動作をご覧いただき、トラブルシューティングにお役立てください。 著者について Dot Ho Dot は AWS オブザーバビリティのシニアテクニカルプロダクトマーケティングマネージャーです。WCA 3×3 多面目隠し解きの記録更新を目指して練習中です。 Erik Weber Erik Weber は AWS Cloud Operations サービスのシニアワールドワイドスペシャリストソリューションアーキテクトです。AWS Systems Manager、AWS Config、AWS CloudTrail、AWS Audit Manager を専門としています。仕事以外では、ハイキング、料理、サイクリングを楽しんでいます。 Kevin Lewin Kevin は Amazon Web Services のクラウドオペレーションスペシャリストソリューションアーキテクトです。オブザーバビリティと自動化を通じて、お客様が運用上の目標を達成できるよう支援することに注力しています。 本ブログは 2026 年 9 月 25 日に公開された This Month in AWS Observability: August – September 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

Amazon S3 テーブルは 、Apache アイスバーグ V3 仕様のすべてのデータタイプをサポートするようになりました。V3 テーブルを作成するか、既存の V2 テーブルをアップグレードして、削除ベクトル、行系列、バリアント、ナノ秒タイムスタンプ、不明、ジオメトリ、地理などの新しいデータタイプなどの V3 機能 を活用できます。 Apache Iceberg は、大規模な分析データセットを管理するためのオープンスタンダードになりました。 Amazon S3 などのオブジェクトストレージのデータレイクにある開いている Parquet ファイルにデータを保存したまま、スキーマの進化、隠しパーティショニング、タイムトラベルクエリなどの機能を使用してペタバイト規模のテーブルを管理できます。Amazon S3 Tables は、自動コンパクション、メンテナンス、レプリケーション、インテリジェント階層化などのフルマネージド機能を備え、アイスバーグテーブルが拡大してもパフォーマンスと費用対効果を維持できるように設計されたストレージを提供します。 Apache Iceberg V2 テーブルで分析を実行しているチームは、データが増えるにつれて同じ制限に達することがよくあります。20億行のテーブルから50,000件のユーザーレコードを削除するというコンプライアンス要求があると、位置削除ファイルが残り、コンパクションが実行されるまでクエリが遅くなります。半構造化イベントは JSON 文字列として生成され、すべてのクエリで解析する必要があります。地理空間座標とナノ秒精度のタイムスタンプは、文字列または整数としてエンコードされます。回避策を実行するたびに、ストレージコスト、クエリレイテンシー、パイプラインコードが追加されます。V3では、Iceberg が半構造化データや地理空間データのネイティブサポート、より高速な行レベルの操作、データガバナンスのための組み込み行リネージを提供することで、これらの課題を解決しています。 2026 年 9 月 30 日より、Amazon S3 テーブルは、バリアント、ナノ秒タイムスタンプ、ジオメトリ、ジオグラフィー、unknown を含むすべての V3 データタイプをサポートし、削除ベクトルや行リネージもサポートします。新しい V3 テーブルを作成したり、既存の V2 テーブルをその場でアップグレードしたりしても、S3 テーブルは引き続きコンパクションとメンテナンスを実行します。 Apache Iceberg V3 V3 は Iceberg仕様 の最新バージョンです。多くの改良点の中でも、V3 には V2 で最も一般的な問題点に対処する機能が導入されています。これには以下が含まれます。 削除ベクトルは 、V2 の位置削除ファイルをコンパクトなバイナリ形式に置き換えます。この50,000行のコンプライアンス削除では、数千の小さな削除ではなく、1つの削除ベクタファイルが書き込まれるようになり、圧縮時間と削除ファイルのオーバーヘッドが大幅に削減されました。 行系統は _row_id と _last_updated_sequence_number を各レコードに自動的に追加します。ダウンストリームのパイプラインでは、テーブル全体をスキャンしなくても、これらのフィールドをクエリして変更された行を見つけることができます。 新しいデータタイプ では、半構造化データ、地理空間データ、ナノ秒精度データを文字列や整数としてエンコードする代わりにネイティブに保存できます。 ナノ秒タイムスタンプ (tz) （ナノ秒精度のタイムスタンプ用） 地理空間データ用の ジオメトリ と ジオグラフィー 既知の型がない列向けの Unknown バリアントデータタイプ は、半構造化データを列指向形式で格納します。書き込み中、エンジンはバリアントデータを非表示の列に細断し、統計を収集します。クエリ時には、これらの統計情報によってファイルプルーニングが可能になり、JSON 文字列を解析する場合と比較して I/O が大幅に削減されます。 以下のセクションでは、これらの V3 機能を実際に使用する方法を例を挙げて説明し、テーブルを作成する方法、新しいデータ型を操作する方法、およびデータを大規模に管理する方法を例を挙げて説明します。 使用の開始 小売分析チームは、ウェブアプリとモバイルアプリ全体でユーザーの行動を追跡します。各イベントの構造は異なります。ページビューには URL と期間、購入にはアイテムと金額、検索にはクエリ用語と結果数が含まれます。V3 のバリアントタイプでは、事前定義済みのスキーマなしで、すべてのイベントシェイプを 1 つのテーブルに格納できます。 CREATE TABLE my_catalog.namespace.clickstream ( event_id bigint, event_time TIMESTAMP, user_id string, payload variant ) USING iceberg TBLPROPERTIES (『format-version』 = 『3』) スキーマの進化を気にすることなく、さまざまなペイロード形状のイベントを挿入できます。 INSERT INTO my_catalog.namespace.clickstream VALUES (1, current_timestamp(), 『user-42』, PARSE_JSON(『{「action」: 「purchase」, 「amount」: 99.99, 「items」: [「laptop_stand」]}』)), (2, current_timestamp(), 『user-17』, PARSE_JSON ('{"action」:「page_view」,「url」:「/products/webcam」,「duration_ms」: 4200}'); 次に、読み取り時に PARSE_JSON を使用せずに、バリアント列を直接クエリします。Amazon EMR Spark では、 variant_get を使用してください: SELECT event_id, user_id, variant_get(payload, 『$.action』, 『string』) AS action, variant_get(payload, 『$.amount』, 『double』) AS amount my_catalog.namespace.clickstream から WHERE variant_get (ペイロード、』$.action』、』文字列』) = 『purchase』 AND variant_get(ペイロード, 『$.amount』, 『double』) > 50.00ペイロード 書き込み操作の削除ベクタを有効にするには、マージオン読み取りモードを設定します。 ALTER TABLE my_catalog.namespace.clickstream SET TBLPROPERTIES ( 『write.delete.mode』 = 『merge-on-read』, 『write.update.mode』 = 『merge-on-read』, 『write.merge.mode』 = 『merge-on-read』 ) これで、コンプライアンス削除を実行すると、V3 はデータファイルを書き換える代わりに小さな削除ベクタを書き込むようになりました。 DELETE FROM my_catalog.namespace.clickstream WHERE user_id = 『user-42』 S3 Tables Compaction は、次のメンテナンスサイクルでこれらの削除ベクターファイルを自動的に処理します。 V2 からのアップグレード AWS では、V3 への移行中の中断を最小限に抑えるために、両方のバージョンに下位互換性を提供しています。既存の V2 リーダーは、V3 機能を完全に採用する準備ができるまで、アップグレードされたテーブルで引き続き機能します。詳細については、 S3 テーブル Iceberg V3 ドキュメントを参照してください。 データを書き換えることなく、既存のテーブルをアトミックにアップグレードします。 ALTER TABLE my_catalog.namespace.existing_table SET TBLPROPERTIES (『format-version』 = 『3』) 次の圧縮サイクルで、S3 テーブルは古い V2 削除ファイルを削除します。新しい修正では削除ベクトルが自動的に使用されます。行系統フィールドは、アップグレード後の最初のデータ変更時に初期化されます。 これは一方向の操作です。Apache Iceberg 仕様は、V3 から V2 へのダウングレードをサポートしていません。アップグレードする前に、テーブルにアクセスするすべてのエンジンが V3 をサポートしていることを確認してください。 インクリメンタルパイプラインに行系統を使用する テーブルに V3 データが含まれたら、行系統を使用して効率的なインクリメンタルパイプラインを構築します。 SELECT *, _row_id, _last_updated_sequence_number my_catalog.namespace.clickstream から WHERE _last_updated_sequence_number > 42 これにより、シーケンス番号 42 以降に変更された行のみが返されます。ダウンストリームジョブでは、テーブル全体をスキャンする代わりに、この値を確認して、実行のたびに新しい変更のみを処理できます。 AWS 分析サービス間の互換性 AWS は、主要なクラウドプロバイダーの中で最も幅広いネイティブ Apache Iceberg サポートを提供しており、データスタックのすべてのレイヤー（取り込み、ストレージ、カタログ、分析）で Iceberg 互換サービスを提供しています。Amazon S3 テーブルに V3 テーブルを保存して自動的に最適化したり、 Amazon EMR Spark でデータを書き込んだり、 AWS Glue を使用してデータを統合および管理したり、 Amazon Redshift で分析を実行したりすることができます。V3 の AWS アナリティクスサポートの詳細については、 Apache Iceberg on AWS 規範的ガイダンスを参照してください。 S3 テーブルと AWS Glue データカタログはどちらも Iceberg REST Catalog (IRC) API をサポートしているため、カタログエンドポイントに関係なくエンジン間の相互運用が可能になります。 知っておくべきこと S3 Tables Compactionは、V3削除ベクターファイルを完全にサポートし、行系統メタデータを保持します。 新しい V3 データタイプ (バリアント、ナノ秒タイムスタンプ、ジオメトリ、地理、不明) には、Apache Spark 4.0 以降 (AWS Glue 6.0 以降) または Amazon EMR リリース 8.1 以降で構築されたエンジンが必要です。 V3 テーブルは、 Amazon S3 コンソール 、 AWS CLI 、またはアイスバーグ REST カタログ API をサポートする任意のエンジンから作成できます。 新しい V3 データ型は、Parquet ファイル形式を使用するテーブルでのみサポートされます (ORC や Avro はサポートされません)。 variant、geometry、geography、またはナノ秒タイムスタンプ型の列は、コンパクションのためのテーブルのソート順に含めることはできません。これらの列を含むテーブルは、ソート順序で他のタイプの列が使用されている場合でも、ソート方式と Z 順序方式ではコンパクトになります。 今すぐご利用いただけます すべての Apache Iceberg V3 データタイプの Amazon S3 テーブルサポートが、S3 テーブルがサポートされているすべての AWS リージョンで利用できるようになりました。Apache Iceberg V3 サポートは追加料金なしでご利用いただけます。標準の S3 テーブル料金が適用されます。 開始するには、 Amazon S3 テーブルのドキュメント を参照するか、 Amazon S3 コンソール からテーブルバケットを作成します。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。フィードバックは、 AWS re:Post 宛てに、または通常の AWS サポート 担当者を通じてお寄せください。 – Daniel Abib 原文は こちら です。

2026年8月19日（水）、「AWS Future of Money」を開催しました。銀行・証券・決済など金融業界から約45名のお客様にご参加いただき、オンチェーン金融の最前線とAI×ブロックチェーンが変える決済の未来について、活発な議論と交流が行われました。本記事では、イベントの模様をレポートします。 企画の背景 ― オンチェーン金融が「実装フェーズ」に入る今 AWSは金融業界のお客様に向けて、インフラ提供にとどまらない、ベストプラクティスの展開やイベントでの業界横断の事例共有、コミュニティ醸成に取り組んでいます。これにより、金融機関・フィンテック企業・システムベンダーなどがAWSを通じてシステム・ビジネス両面でつながることで、業界全体のデジタル変革が加速することを目指しています。 近年で、金融・決済市場のデジタル化は構想から実装へと大きくフェーズが動きました。ステーブルコインやトークン化預金といったプログラマブルな通貨の制度整備が各国で加速し、国内でも金融機関やフィンテック企業による商用化の動きが本格化しています。一方でこのような動向は、従来の金融システムの縮小リスクを示唆するものでもあります。クロスボーダー送金の即時化やデジタル通貨を前提とした新たな市場インフラ構築をすることは、日本の金融業界が次のステージへ進み、持続的成長を果たすための極めて重要な鍵となります。 この大きな転換点において、金融機関・決済企業・パートナー企業の皆様と業界の垣根を越えて実践知を交換し、オンチェーン金融の「次の一手」を共に描く場として、「AWS Future of Money」を企画しました。   イベント概要 日時 : 2026年8月19日（水）15:00 – 19:00 会場 : 渋谷外部会場 参加者 : 金融関連事業会社、サービサーなど 約45名 AWS Session「AWSから見えるデジタル通貨の最新動向」 AWS坂口より、国内外の業界動向と180回を超えるお客様対話から見えてきたデジタル通貨の最新シグナルを共有しました。今年、金商法改正成立が話題にあがりましたが、実業と規制がバランスよく並走しています。また、ユースケースも銀行業界を中心とした発行の議論から、流通・決済といった実務での活用へ各業界で広がりを見せています。 証券業界については、デジタルアセット投資領域のポイントから成功事例に共通するレイヤードアプローチ（既存システムとの共存・段階的導入）の重要性を強調しました。100%置換を試みて失敗した教訓にも触れ、既存インフラとの補完関係が鍵であると述べました。さらに、決済業界ではAIエージェントが購買行動まで完結する「エージェンティック・コマース」による市場の変化と、決済体験を変える可能性を示しました。 本セッションを通じ、デジタル通貨が着実に広がっていることと、事業の構想段階からAWSが相談できるパートナーであることをご参加者にお届けしました。 AWS Session「デジタル通貨に関するAWSサービスの活用」 AWS松原より、デジタル通貨基盤を支えるAWSサービスを技術面から解説しました。直近のニュースとして、米国の20行を超えるトークン化ネットワーク構築、国内3行によるステーブルコイン共同発行協議会の設立、SWIFTのブロックチェーンベースの共有台帳を紹介し、グローバル含めたトレンドの強さを示しました。合わせて、クロスボーダー決済・国内決済のユースケースで解決する課題やアーキテクチャの例を紹介しました。 AWSについては、商用稼働している事例でも採用されている、EC2サービスの AWS Nitro Enclaves をピックアップして紹介しました。AWS Nitro EnclavesはEC2インスタンス内に簡単にセキュアな分離環境を作り、機密データを保護します。Fireblocks等のパートナーソリューションにも組み込まれており、お客様が意識せずともその恩恵を受けられるケースも紹介されました。 以上から、デジタル通貨における領域でもAWSのサービスは既に多くご利用頂いており、パートナーソリューションを通じても活用いただけることをお伝えしました。 Customer Session 野村ホールディングス株式会社「オンチェーン金融による資本市場の拡張」 Speaker: 佐々木 俊典 様（野村ホールディングス株式会社 デジタルアセット戦略推進部長） 野村ホールディングスの佐々木様からは、オンチェーン金融の本質と将来の市場インフラ像についてご発表しました。まず、トークン化の本質を「仲介者不要の権利移転」と定義し、短期的な24時間稼働・即時取引だけでなく、手数料構造を根本から変える構造変革が本質であると指摘しました。有価証券のトークン化は数十兆〜数百兆円規模のユースケースであり、ステーブルコインよりも大きなインパクトがあると強調。不動産セキュリティトークン（ST）は2025年度に1,400億円程度発行され、J-REIT比で半分超に成長しているなど、国内でも着実に実績が積み上がっています。 経済安全保障の観点では、「決済インフラを海外に奪われると取り返せない」と警鐘を鳴らし、自民党の「次世代AI・オンチェーン金融構想」プロジェクトにも言及。金融庁・日本銀行も参画しており、官民一体での取り組みが加速していることを示しました。 将来像としては、パーミッションド・プライベートチェーン（機関投資家向け）とパブリックチェーン（RWA: Real World Assetsのトークン化）が相互接続する世界を描き、AIエージェントが自律的に取引を最適化する「金融を意識しない世界観」を展望しました。   JPYC株式会社「ステーブルコイン活用の最前線：事業者の活用事例とそれを支えるAWS」 Speaker: 松岡 慧 様（JPYC株式会社 執行役員・計画情報部長） JPYCの松岡様からは、日本円ステーブルコインJPYCの事業展開とAWS基盤について紹介しました。2025年10月のサービス開始から9か月で、口座22,500、ホルダー71,000、累計発行71.4億円、1日あたり2〜30億円の取引を処理するまでに成長。事業者にとっての4つの価値として、(1) 送金コスト0.01円以下、(2) 24/365即時着金、(3) スマートコントラクトから直接操作可能、(4) 許可不要の公開インフラを挙げました。 具体的な活用事例として、国内初のローソン店頭POS連動ステーブルコイン決済実証（2026年8月）、物流×決済DX（配送1件完了ごとの即時報酬支払い）、AIエージェント向け決済規格X402への対応をご紹介。AWS採用理由として、インフラをコードで即座に構築できるスピード、AWS CloudTrailによる改ざん不可能な監査ログ、FISC実務基準300項目以上への対応実績を挙げました。 Customer Panel Session パネル1: オンチェーン時代に求められる暗号資産交換業のテクノロジー パネリスト: 三浦 和夫 様（シンプレクス株式会社 エグゼクティブプリンシパル）、井上 大悠 様（Japan Financial Elan Technologies株式会社 代表取締役社長） モデレーター: 坂口 宏太（AWS） Japan Financial Elan Technologiesの井上様は、ステーブルコイン市場が3,000億ドルから5,000億ドルへ成長する中、実経済での決済利用はまだ5%程度であり伸びしろが大きいこと、StripeやCircleのAIエージェント決済への取り組みなどブロックチェーンの低コスト性が新たなユースケースを生み出している現状を示しました。 シンプレクスの三浦様は、FXから暗号資産交換業・トークン化証券まで展開してきた経験から、交換業に必要な5つの技術領域（口座管理、秘密鍵管理、AML、トランザクション管理、ステーキング運用）を整理しました。マネタイズの鍵として資金効率向上（リアルタイム担保移転）、業態横断のシームレス体験、社会インフラとしてのポジションを挙げ、日本の課題である個別開発コストの高さに対しては共同インフラ活用が不可欠との共通認識が示されました。 パネル2: トークン化預金×クロスボーダー決済 — DCJPYが描く国際送金の未来 パネリスト: 田子島 敬 様（株式会社DCP 執行役員 営業戦略本部 副本部長 経営管理本部 地域社会PJ責任者）、瓦田 宗大 様（株式会社SBI新生銀行 次世代金融部長）、ハンフリー・ヴァレンブレダー 様（Partior Pte Ltd. Chief Executive Officer） モデレーター: 山﨑 夕莉子（AWS） 株式会社SBI新生銀行における、株式会社DCPとPartiorのトークン化預金プラットフォームを活用したクロスボーダー決済の革新（年内商用化予定）を紹介しました。ハンフリー・ヴァレンブレダー様からは、日本-アメリカおよび日本-ブラジルの送金ルートが商業レベルで運用を開始しており、これらのユースケースはすでに確立されつつあると共有しました。 そのうえで、田子島様が「日本が取り残されないための最後のチャンス。様々な方々と協働していきたい」と呼びかけ、瓦田様は「採用する金融機関・事業者を増やすことが重要。AIとブロックチェーンの組み合わせで自動化・最適運用が実現する世界はすぐそこにある」と述べました。3社に共通していたのは、技術的にはすでに実用段階に入っており、この価値を実現するためには多くのプレイヤーがエコシステムに参画することこそが次のハードルであるというメッセージでした。 まとめ クロージングではAWS佐藤から、ブロックチェーン×AIの実用化に向けたAWSのご支援とパートナーエコシステムの活用を紹介しました。イベント全体で、なぜデジタル通貨のビジネスに取り組むべきなのか、どこから着手すればよいのか、業界全体で考えるべきことは何かといった、これからビジネスを本格化するための知見や生の声をお届けしました。 参加者からは「クローズドならではの密度の濃い情報が得られた」「レベルの高いスピーカーで効率的に知識をアップデートできた」「登壇者と直接会話できる懇親会が大変勉強になった」等の声をいただきました。また、お客様事例の進捗状況への驚きや、紹介されたAWSサービスへの関心も多く寄せられました。 本イベントを通じて、各業界で導入効果のあるユースケースが確立されてきていることと、デジタル通貨のビジネスを発展させるためにはユーザビリティを向上させ、利用者をいかに増やしていくかが重要になると実感しました。AWS金融チームでは、オンチェーンを支えるクラウドサービスの提供と、お客様同士の共創を支える場づくりを通じて、金融業界全体への発展に貢献してまいります。 最後に、ご登壇いただいたお客様、そしてご参加いただいたすべてのお客様に心より感謝申し上げます。

2026 年 9 月 30 日は、皆さんに AWS ヒーロープログラム の最新メンバーをご紹介できることをとても嬉しく思っています。AWS ヒーローは、知識を共有し、他の人々のメンターとなり、活気に満ちたコミュニティを構築するために人並み以上の力を注いできた AWS エキスパートたちの活力あふれる世界的グループです。これらのヒーローたちは、開発者や組織が AWS で成功を収めるための支援において真の違いを生み出しています。 今月は、世界各地から 3 人の卓越したコミュニティリーダーをヒーローとしてお迎えします。それぞれが、独自の専門知識を持ち、世界中のビルダーたちのエンパワーメントに真摯に取り組むリーダーです。 Avinash Shashikant Dalvi 氏 – ベンガルール、インド サーバーレスヒーローである Avinash Shashikant Dalvi 氏はテクノロジー アーキテクトであり、AWS User Group Bengaluru の共同主催者でもあります。Dalvi 氏の焦点は AWS 上のサーバーレス、コンテナ、および本番環境対応アプリケーションです。コミュニティトークを 40 回以上行い、AWS for Product Builders ニュースレターを発行するとともに、Amazon ECS、AWS Fargate、AWS Lambda、AWS Amplify を対象とした技術的コンテンツも作成しています。 Joanne Skiles 氏 – オーランド、米国 サーバーレスヒーローである Joanne Skiles 氏は、AWS でのサーバーレスアーキテクチャと AI システムを含めたフルスタックシステムの構築で 16 年を超える経験を積んできたエンジニアリングリーダー兼教育者です。Orlando AWS User Group を主催する Skiles 氏は、YouTube チャンネル、カンファレンストーク、「Chaotic Commits」と「Her Career Unplugged」の 2 つのポッドキャストを通じてクラウドと AI の概念を教えています。Rollins College コンピューターサイエンス学部の教授でもあり、当大学で Transparent Systems 研究室を運営しています。 Xiaofei Li 氏 – 上海、中国 コミュニティヒーローである Xiaofei Li 氏は AWS ゴールデンジャケットの所有者であり、中華圏のアクティブなコミュニティリーダーとして Kiro、Amazon Quick、Tokyo Chinese AWS の各コミュニティを先導しています。Li 氏は Kiro Chinese User Community (メンバー 5,000 人以上) を設立し、15 都市にまたがる 3,000 人以上の参加者を集めた AWS BuilderCards の中国語版ローカライゼーションを立ち上げました。支援が行き届いていない学生のメンターでもあり、Women in Tech イニシアチブをサポートしています。 詳細 AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。AWS コミュニティに参加する方法の詳細については、 AWS Builder Center をご覧ください。 – Taylor 原文は こちら です。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの辻林です。2026 年 9 月 15 日に、「AI ペルソナワークショップ — 自社だけの AI ペルソナを作って、試してみよう」を開催しました。マーケティングや事業企画、DX推進に携わる皆様と、自社のデータから AI ペルソナを作り、実際のビジネス課題をぶつけてみる半日のワークショップです。ご参加くださった皆様に、改めて御礼申し上げます。 本ブログでは、ワークショップと当日の様子、参加者の皆様の声をお届けします。 はじめに 新商品のコンセプトは刺さるのか、どのチャネルで届けるべきか、このサービスを続けるべきか。マーケティングの現場では、顧客の反応を確かめたい問いが次々に生まれます。一方で、インタビューやアンケートを毎回実施するには時間もコストもかかり、「聞いてみたいけれど、そこまでの予算はない」という問いも少なくありません。 そこで注目されているのが、1 人の仮想的な顧客を再現する 「AI ペルソナ」です。年齢や職業といった属性に加えて、自社のインタビュー、アンケートや購買データなどをもとに AI ペルソナを構築することで、汎用の LLM にはない「自社顧客のコンテキスト」を持ったペルソナと対話したり、複数のペルソナ同士で議論させたりできます。 AWS では、この AI ペルソナをすぐに試せるサンプル実装 aws-samples/sample-ai-persona を GitHub で公開しています。今回のワークショップは、このサンプルソリューションを使って「デモを見る」のではなく「自社のデータで作って、自社の問いで試す」ところまでを体験していただきました。 イベント概要 項目 内容 日時 2026 年 9 月 15 日（火）14:00〜18:00 場所 アマゾン ウェブ サービス ジャパン 東京オフィス 参加者 7 社 19 名 満足度 4.69 / 5 タイムテーブル 時間 内容 14:00〜14:05 オープニング 14:05〜14:25 Agentic AI 時代のマーケティング 14:25〜15:25 ワークショップ ハンズオン編 15:25〜15:40 休憩 15:40〜17:40 ワークショップ 実践編 17:40〜17:55 AI ペルソナを活用するために 〜ペルソナの育て方〜 17:55〜18:00 クロージング 当日の様子 Agentic AI 時代のマーケティング 発表資料： Agentic AI 時代のマーケティング 最初のセッションは、アマゾン ウェブサービス ジャパン合同会社 戦略事業開発本部 プリンシパル事業開発マネジャーの松本より、AI によってマーケティングの前提がどう変わりつつあるかを、Amazon の事例を交えてお話ししました。 Alexa for Shopping（旧称 Rufus）のように、AI が候補を絞って商品を勧める買い方が広がり、ブランドはお客様だけでなく「AI にどう認識されるか」も意識する必要が出てきています。広告の分野においては、Amazon の広告事業を担う Amazon Ads が、会話するだけで広告を作れる Amazon Ads Creative Agent や、画像と見出しの組み合わせから AI が一番合うものを選んで出す Amazon Ads Responsive eCommerce Creative を発表しました。米国では、小売企業が自社の EC サイトにメーカーの商品広告を載せられる Amazon Retail Ad Service も始まっており、その裏側では、生データを共有せずに企業同士のデータをつなぐ AWS Clean Rooms が使われています。 こうした変化の中で、今回焦点を当てたのが「AI による顧客理解の変化」です。これまで消費者の声を聞くには、フォーカスグループインタビューのように数週間の準備とまとまった費用をかけ、限られた人数から意見を集める必要がありました。AI ペルソナを使えば、「なぜこの商品を選ぶのか」を問いかけて初期のインサイトを数時間で得たり、新商品のアイデアやパッケージデザインを評価させたり、異なるペルソナの反応を比べてターゲット別の戦略を考えたりできます。 一方で、AI ペルソナは実際のお客様への調査を置き換えるものではありません。AI ペルソナで仮説を素早く幅広く検証し、絞り込んだ論点を少数の実際のお客様で確かめる — この組み合わせが、これからの顧客理解のかたちです。 セッションの最後には、AI 活用を進めるステップとして「知る・試す・実装する」の 3 つを紹介しました。今回のワークショップは、このうち「試す」にあたります。ワークショップで使う AI ペルソナも Amazon Bedrock 上で動いていることに触れ、「次は自社のデータで実際に体験してみましょう」とワークショップへ進みます。 ワークショップ ハンズオン編 ワークショップはハンズオン編と実践編の２部構成で実施しました。ハンズオン編では 今回活用する AI ペルソナ のサンプルソリューションの概要を紹介した後、「Z 世代向けサステナブルコスメの新商品企画」という模擬シナリオで AI ペルソナを体験していただきました。 ハンズオンでは EC の購買ログと SNS アンケートの 2 つのサンプルデータをアップロードし、サステナ志向・コスパ重視・トレンド志向などの価値観の異なる 3 体のペルソナを生成しました。そして、その AI ペルソナを活用して 1 対 1 のインタビューで購買のきっかけを深掘りしたり、 異なる価値観のAI ペルソナ同士で新商品のコンセプト評価や購入チャネルと情報接点などをテーマに議論をさせ、セグメント毎にペルソナの意見が割れる様子も確認いただきました。議論のあとには自動抽出された顧客ニーズやマーケティングに関するインサイトの確認および推奨アクションを含むレポート生成機能を試し、ペルソナ生成から施策やアクションへの転換までを体験していただきました。 あわせて次の実践編への評価観点として AI ペルソナやインサイトを「具体性」「差別化」「予測力」「施策接続性」の 4 つの軸で評価する考え方を紹介しました。 ワークショップ 実践編 実践編は ご参加頂いた各社が自社のデータと自社のビジネスの問いで AI ペルソナを実際に試す時間です。上記のワークシートに沿って、次の 3 ステップで進めました。 STEP 1 — ユースケース設計：何の意思決定に使うか（何を問うか）、誰に問うか、そのために今使えるデータは何か STEP 2 — 検証と評価：ペルソナを生成し、インタビューや議論で問いを投げ、4 つの軸で評価する STEP 3 — ネクストアクション：いつまでに、誰が、何を、どのデータを足して試すかを決める ユースケースは、新規サービスの概念実証に進むかどうかの判断、広告クリエイティブや CRM 配信の設計、LP や価格の見せ方の改善、既存サービスを続けるかどうかの判断など、実に多様でした。中には、顧客ではなく社内の意思決定者のペルソナを作り、提案前の壁打ち相手にするという使い方もありました。 各チームでは、生成されたペルソナの発言を見ながら「この答えは自社の顧客らしいか」「このデータだけでは足りないのでは」といった議論が活発に交わされていました。評価の結果、共通して見えてきたのは、ペルソナの出来を左右するのはデータの量ではなく、検証の目的に合ったデータかどうかという点です。顧客の生の声や行動データを入れ、問いを具体的に立てるほど、「次に何をすべきか」につながるアウトプットが得られていました。最後は各社で、次に与えるデータと再検証の段取りをネクストアクションとして書き出していただきました。 AI ペルソナを活用するために 〜ペルソナの育て方〜 発表資料： AI ペルソナを活用するために 〜ペルソナの育て方〜 最後のセッションでは、ソリューションアーキテクトの髙橋より、実践編で見えた課題を次の一手につなげる「ペルソナの育て方」を紹介しました。 実践編で「弱い」と感じた評価軸が、そのまま次のアクションのヒントになります。たとえば具体性が足りなければ行動の詳細データを、予測力を上げたければ施策と反応のデータを追加し、施策接続性に課題があればプロンプトで目的を明確にする、といった具合です。そのうえで、ペルソナを育てるステップを 3 段階で整理しました。 データを足す — 購買データや閲覧ログなど自社の 1st Party Data を追加する。Clickstream Analytics on AWS や、自然言語で自社データに問い合わせる Discovery 360 も活用できる データを広げる — 市場調査レポートなどの公開データや、AWS Clean Rooms を使ったパートナーとのデータ連携に加え、Amazon 上の購買・広告シグナルも取り込み、自社の外の行動を補う ソリューションを使い倒す — データセット連携、ナレッジベース、長期記憶を活用し、アウトプットを広告・企画・調査の業務フローに乗せる ペルソナは一度作って終わりではなく、「評価する → 育てる → 使い倒す」のサイクルで精度が上がっていくものです。この日作ったペルソナは、各社にとってのスタート地点になりました。 参加者の声 アンケートでは、特に手を動かす実践編とハンズオン編を有益だったと挙げる方が多く、参加者の方からは次のような声が寄せられました。 「マーケティングの観点において、時間・費用の面で効率が非常に上がると感じる」 「実際のインタビューとあわせながら、難しいシチュエーションなどは AI ペルソナを活用したり、使い分けしたい」 「データを使って育てながら仮説を深めたい」 「実際に使う際の課題や注意点も色々とイメージできてよかった」 また、「様々に議論できたことが大変有意義であった」という声もありました。AI ペルソナを囲んで、自社のお客様について改めて議論する時間そのものにも価値を感じていただけたようです。 まとめ 今回のワークショップでは、自社のデータで AI ペルソナを作り、自社の問いで試し、次に足すデータを決めるところまでを半日で体験していただきました。AI ペルソナは、データを足しながら育てていくことで、仮説検証や意思決定の心強いパートナーになります。 今回使用したサンプル実装は aws-samples/sample-ai-persona でGithub上に公開しており、自社の AWS 環境に展開してすぐに試すことができます。AI ペルソナの活用や、次の一手となるデータの整備にご関心のある方は、ぜひ担当のアカウントチームまでお気軽にご相談ください。 本ブログは、ソリューションアーキテクトの辻林、小川、髙橋、平本が執筆いたしました。 筆者について 辻林 侑 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 西日本の小売・消費財業界のお客様を中心にクラウド活用の技術支援を行っています。好きな AWS サービスは Amazon CloudWatch と、AWS DevOps Agent です。

本ブログでは、 ローンチブログ で紹介した各ユースケースをさらに詳しく掘り下げます。パートナーやお客様が SAP モダナイゼーションプロジェクトにおいて Kiro ベースのサンプルエージェントを使って達成した成果の一部もご紹介します。これらのサンプルエージェントは こちら からダウンロードできます。ローンチブログで取り上げた主なユースケースを振り返ります。 SAP S/4HANA 準拠に向けた ABAP コードのアップグレード クリーンコアに向けた ABAP のリファクタリング SAP PI/PO から SAP BTP へのモダナイゼーション SAP Business Warehouse（BW）から Business Data Cloud（BDC）の SAP Datasphere へのモダナイゼーション 機能仕様書と技術仕様書の生成 単体テストの自動化 本ドキュメントに記載するベンチマークは、すべて AWS の社内開発環境で実施したものです。ベンチマークで使用した Kiro クレジットは、 Kiro Pro サブスクリプションの範囲内に十分収まっています。 1. SAP S/4HANA 準拠に向けた ABAP コードのアップグレード 最初のユースケースは、レガシーなカスタム SAP ECC ABAP コードを SAP S/4HANA に準拠した標準コードに変換することです。数千（あるいは数万）のカスタム ABAP プログラムを持つエンタープライズにとって、このエージェントは最も労働集約的な改修作業を自動化します。コードを変換する前に、エージェントは機能仕様書、技術設計書、単体テストクラスを作成します。変換中には、定義されたエンタープライズ標準に準拠するようコードを改善します。これを実現するため、パフォーマンス標準、コーディング標準、セキュリティ標準、ドキュメント標準、コードの重複回避をカバーする、80を超えるサンプルルールとベストプラクティスを完全に構成可能なセットとして提供しています。変換後、エージェントは単体テストを実行してビジネスロジックの整合性を確認します。 ベンチマーク： AWS の社内ベンチマークでは、88オブジェクト（5,854行のコード）からなる SAP ECC パッケージ全体を4.5時間で完全に SAP S/4HANA 準拠のコードに変換し、生成されたすべての単体テストに合格して、工数を87%削減しました。このベンチマークで使用した Kiro クレジットは377でした。 NTT Data Global Solutions（GSL）は、お客様の SAP S/4HANA への移行を加速するために ABAP エージェントを活用しています。GSL の新しい移行サービス Neo i-KOU! は、ABAP の改修フェーズを最大95%短縮します。製品テストでは、従来は変換に4人月以上を要していた ABAP コードを、わずか0.21人月の工数で変換しました。 2. クリーンコアに向けた ABAP のリファクタリング このユースケースでは、Clean Core Extensibility Model への準拠に向けてカスタム ABAP コードを評価・改修します。このモデルでは、各カスタマイズが SAP S/4HANA のコアシステムの外側にどれだけクリーンに配置されているかに基づき、A から D の等級で評価します。カスタマイズを最高レベルの A と B に保つことで、お客様はカスタムコードを壊すことなく迅速にアップグレードして SAP の新しいコア機能を採用できるため、より速くモダナイズしてコストを削減できます。AWS は、既存の ABAP カスタマイズをこれらの基準に照らして評価し、基準に満たないコードを改修することで、お客様がそこに到達できるよう支援します。 ベンチマーク： 社内ベンチマークでは、エージェントが143オブジェクト（10,200行のコード）にわたって116件の「Extensibility Level D」の ABAP 指摘事項を特定しました。55分の実行時間で、Level D の指摘事項を100%改修しました。エージェントは、非標準のコードを適切な SAP リリース済みオブジェクトに置き換えるか、クリーンコアの原則に従ってそれらを拡張しました。重要な点として、クリーンコアの自動改修は、SAP が標準オブジェクトをリリースしているオブジェクトに限定されます。ほとんどのお客様では、リリース済みオブジェクトが利用できないカスタムコードが一定の割合で存在すると想定しておくべきです。それらのオブジェクトについては、手作業でのレビューと、クリーンコアの選択肢（サイドバイサイドへの変換、現状維持、Fit-to-Standard の採用など）に関する判断が必要です。ベストプラクティスとして、まずエージェントを使ってすべてのカスタムコードを分析し、ABAP オブジェクトごとの現在の Extensibility Level（A、B、C、D）を示すレポートを作成して、自動改修の対象となるものを特定することをお勧めします。 3. SAP PI/PO から SAP BTP Integration Suite への移行 このユースケースでは、SAP PI/PO のインターフェースを SAP Business Technology Platform Integration Suite（BTP IS）に変換することに焦点を当てます。SAP のミドルウェアプラットフォームである SAP PI/PO は、2027年12月に標準メンテナンスの終了を迎えます。お客様は数十から数百のインターフェースを BTP IS に移行する必要があり、単一のインターフェースを手作業で変換するには、その複雑さに応じて数日から数週間かかることがあります。この課題に対処するため、私たちはモダナイゼーションエージェントを開発しました。単一のプロンプトで、エージェントは既存の PI/PO 構成を調査し、機能仕様書と技術設計書を作成し、PI/PO のアーティファクトを BTP 対応の形式に変換し、その結果を BTP IS にデプロイすることで、大幅な時間とコストの削減を実現します。SAP PI/PO の移行に加えて、エージェントは要件定義書から直接、新規の BTP IS インターフェースを開発することもできます。 ベンチマーク： 社内ベンチマークでは、エージェントが22の SAP PI/PO インターフェースを約2時間で SAP BTP Integration Suite に変換しました。これらのインターフェースには25のメッセージマッピングが含まれており、IDOC、SOAP、REST、同期・非同期など、さまざまなインターフェースタイプにまたがっていました。エージェントは、ソースの通信チャネル、アグリーメント、共有関数ライブラリを読み取り、各ターゲットアダプターを決定してマッピングロジックを再現しました。その後、SAP BTP IS のインターフェースを作成し、稼働中のテナントにデプロイし、ソースのルールに照らして単体レベルのデータで各マッピングをテストしました。エージェントは、ルーティング、ファンアウト、マルチキャスト、値マッピング、IDOC セグメントマップ、ステートフルなオーケストレーション（ccBPM）といった複雑な要件にも対応しました。セキュリティ上の理由から、パスワードや証明書などの認証情報は移行しないため、エンドツーエンドのテストの前に手作業のステップが必要です。このベンチマークで使用した Kiro クレジットは約220でした。 4. SAP BW から Datasphere へのモダナイゼーションエージェント このユースケースは、SAP BW のモダナイゼーションを加速し、作業をエンドツーエンドで自動化するものです。エージェントはまず既存のすべての SAP BW のデータパイプラインとデータモデルを読み取り、それぞれについて機能仕様書と技術仕様書を作成し、クラウドネイティブな SAP Datasphere の同等物に変換します。SAP BW Private Cloud Edition（PCE）の道を選ぶお客様は、エージェントを Data Product Generator や Query Template Generator などの SAP ツールと組み合わせて使用できます。 これは、同じ期限を迎えるもう1つのワークロードに対処するものです。数千の企業が利用するエンタープライズデータウェアハウスプラットフォームである SAP BW も、2027年12月に標準メンテナンスの終了を迎えます。SAP はお客様に SAP Datasphere への移行を推奨しており、そこに至る道は2つあります。SAP Datasphere に直接移行するか、まず暫定的なプラットフォームである SAP BW Private Cloud Edition（PCE）に移行するかです。後者の場合、2027年以降も SAP BW を稼働させ続け、自社のペースで Datasphere を採用できます。 SAP BW 向けのエージェントは Kiro Specs 上に構築されたガイド付きワークフローであり、アーキテクトや開発者があらゆるステップで主導権を保てます。データフローを発見し、それらを SAP BDC の Data Products にマッピングし、設計書を作成し、変換済みの Datasphere オブジェクトを生成・デプロイします。その過程で、組織独自のベストプラクティスとデータ戦略が適用されます。 ベンチマーク： 社内ベンチマークでは、このエージェントが販売管理（Sales and Distribution）のコンテンツを含むレガシーな SAP BW 環境を2.2時間で SAP Datasphere に変換しました。SAP BW 環境は Layered Scalable Architecture（LSA++）アーキテクチャに基づいており、32の Data Store Object、13の Transformation、6つの Composite Provider、1,273のフィールドで構成されていました。最終的な SAP Datasphere 環境には、32の Local Table、13の Data Flow、6つの Analytic Model が含まれていました。このベンチマークで使用した Kiro クレジットは856でした。 AWS パートナーである DXC と Kyndryl は、お客様の SAP BDC へのジャーニーを加速するために SAP BW エージェントを活用しています。DXC は、Kiro と Modernization Agents を「DXC Fast BDC」と組み合わせることで、複雑なアセスメントを自動化し、AI を活用したビジネスインサイトを実現し、最短10週間でビジネス価値を提供するデジタルトランスフォーメーションを加速しています。Kyndryl の SAP US Data Lead である Poshan Ponnamreddy 氏は次のように述べています。「 AWS の Modernization Agents、Kiro、そして Kyndryl の Agentic AI Framework の組み合わせは、お客様の SAP モダナイゼーションの期間短縮に貢献しています。AI を活用した変換機能がコードの分析と変換を自動化し、品質を向上させながら手作業の工数を最大80%削減します。これらのイノベーションが一体となって移行の成果を加速し、価値実現までの時間を大幅に短縮します。 」 5. 機能仕様書と技術仕様書の生成 「何十年も前に」書かれたコードにドキュメントがなく、業務の専門家もとうの昔に組織を去ってしまった、という話をよく耳にします。AI を使ってコードを分析しドキュメントを生成することは、SAP ABAP、PI/PO、BW など幅広い SAP プラットフォームで効果が実証されたユースケースです。多くの SAP プロジェクトの最初のステップは、レガシーコードを分析・文書化して、現状（As-Is）の機能仕様と技術仕様を理解することから始まります。 Kiro のサンプルコードを使って構築したモダナイゼーションエージェントは、希望する形式で、かつ自社のドキュメント標準に従ってドキュメントを生成するための機能を提供できます。また、未使用のコードを特定することもでき、不要なコードのモダナイゼーション作業を回避できます。 Toyota Chile は SAP ECC から SAP S/4HANA への移行を進めていますが、数百のレガシー SAP ABAP オブジェクトについてドキュメントや理解が不足していました。シニアソフトウェアエンジニアの Rolando Sabatino 氏は、次のように体験を語っています。「 Kiro と AWS の Modernization Agents for SAP on AWS により、プロジェクトの工数を簡素化・削減できています。Kiro を使って未使用のコードや陳腐化したテーブルを特定し、移行範囲から除外しました。また、ビジネスユーザー向けの機能ドキュメントと開発者向けの技術仕様書も生成しました。ドキュメントは数時間で生成され、数か月分の手作業を回避できました。 」 6. 単体テストの自動化 単体テストは、あまり知られてはいないものの機能を確認するうえで効果の大きいアプローチであり、AI によるコード変換を高精度で信頼性の高いものにしている要因です。コードのモダナイゼーション中の AI のハルシネーションを大幅に最小化するため、結果が信頼できるものになります。ベストプラクティスとして、AWS はモダナイズの前にレガシーコードの単体テストを生成することを推奨しています。これにより、AI エージェントは変換後のコードを検証するための明確な成功基準を得られます。 これがなぜそれほど重要なのか、もう少し詳しく説明します。Kiro や Claude Code などの AI コーディングツールは、よりエージェント的な機能を備えるよう成熟するにつれて、人間の作業方法を模倣するかたちで自律的に反復しながら問題を解決するようになりました。人間がコードを書いてバグを見つけると、バグが解決されるまで分析・編集・再テストのサイクルを続けます。エージェント型ツールはこれと同じループを実行し、問題が修正されたことを確認するために単体テストを使用します。言い換えれば、単体テストは成功がどのようなものかをエージェントに伝え、エラーがなくなるまで分析・編集・再テストを繰り返せるようにします。自動単体テストを組み込んでいることは、私たちのモダナイゼーションエージェントが前述の高品質なベンチマークを達成できた主な理由の1つです。 正確で高品質なコードのためのセーフガード 業界でよく聞かれる正当な懸念の1つが、AI が生成するコードの正確性と品質です。お客様からは「 エンタープライズは、SAP のような最も重要なワークロードにどうすれば自信を持って AI を適用できるのか？ 」と頻繁に質問されます。ABAP ではコードが他の ABAP オブジェクトに格納されたロジックやライブラリを頻繁に参照するため、正確性と品質のリスクが増幅されます。ほとんどの AI コーディングアシスタントは、そうした外部の依存コードを取得できず、それがしばしばハルシネーションの原因となります。AWS は正確性と品質を重視しており、これらのサンプルエージェントに独自のセーフガードを組み込んでいます。 第一に、これらのサンプルエージェントを活用して構築したエージェントは、依存するすべてのコードとライブラリを取り込み、Kiro が完全なコンテキストを持てるようにします。これは、変換時に正確なコードを生成しビジネスロジックを維持するうえで不可欠です。第二に、カスタマイズ可能なステアリングファイルにより、独自のコーディング・パフォーマンス・セキュリティ・ドキュメントの標準を定義できます。サンプルエージェントには、すぐに始められるよう80以上のルールを含むサンプルのステアリングファイルが付属しています。第三に、単体テストに対する独自のアプローチにより、変換前にコードを作成してテストし、変換後にまったく同じビジネスロジックを再テストすることで、品質を大幅に向上させ、時間を節約します。 監査可能性も重要なセーフガードの1つです。これらの Kiro ベースのサンプルエージェントを使って構築したモダナイゼーションエージェントは、会話履歴を保存し意思決定をログに記録できるため、デバッグや微調整に役立ちます。特筆すべきことに、2社のお客様が自社の AI 自動化のアプローチを内部統制チームおよび監査チームとともにレビューしました。予想に反して、監査担当者は意思決定ログの透明性を好みました。それが、ほとんどの従業員が手作業で維持しているドキュメントを上回っていたためです。 これらのエージェントはソフトウェア開発ライフサイクルの多くの部分を自動化しますが、本番環境に移行する前に、お客様が引き続きエンドツーエンドの徹底したテストとビジネス検証を実施することが重要です。 まとめ SAP のモダナイゼーションは、エンタープライズ IT において今なお最も複雑でリソース集約的な取り組みの1つです。サンプルエージェントを共有することで、私たちはお客様とパートナーに、より速く、より手頃なモダナイゼーションへの道を提供することを目指しています。これらのサンプルエージェントは こちら からダウンロードでき、詳細は こちら でご覧いただけます。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

Kiro は、エンタープライズが本番運用に耐えるソフトウェアを構築できるよう設計された、AWS の AI 搭載エンジニアリングエージェントです。Kiro を使うと、お客様は並列エージェントを用いて大規模なコードベース全体にわたって開発を進めることができ、SAP のモダナイゼーションのような複雑でリソース集約的なプロジェクトに最適です。本日、お客様やパートナーが AWS 上でカスタム SAP Advanced Business Application Programming（SAP ABAP）プログラム、SAP Business Warehouse（SAP BW）、SAP Process Integration および SAP Process Orchestration（SAP PI / PO）のモダナイゼーションとデプロイを加速するために活用できる、Kiro ベースのサンプルエージェントを公開します。SAP は、多くの組織が最も重要なビジネスロジックとデータを格納している場所です。カスタム SAP ABAP プログラムは、財務、受注管理、サプライチェーン業務といった中核プロセスを動かしています。SAP BW は、エンタープライズが計画や意思決定のために頼りにしているレポーティングと分析を支えています。SAP PI / PO は、SAP を数百もの外部システム、取引先、アプリケーションと接続するミドルウェアとして機能しています。これらのワークロードを手作業でモダナイズすることこそが、SAP トランスフォーメーションに多大な時間とリソースを要する理由です。さらに、SAP BW、SAP PI / PO、オンプレミスの SAP ERP Central Component（SAP ECC）の標準サポート終了が近づいているため、お客様は SAP のクラウドネイティブなシステムへのモダナイゼーションが必要になっています。これらのサンプルエージェントを使うことで、お客様は、これまでエンタープライズ IT において最もリソース集約的な取り組みの1つであった SAP のモダナイゼーションを加速できます。単一のプロンプトで、サンプルエージェントは数千行の SAP ABAP コードや、サポート終了を迎える数百の SAP ミドルウェアインターフェースを一括でモダナイズできます。社内ベンチマークにおいて、AWS はこれらのサンプルエージェントがブラウンフィールドの ABAP コードのモダナイゼーション（分析、変換、単体テスト）を自動化し、工数を最大87%削減できることを実証しました。さまざまな業界のお客様が、これらのエージェントを試してその価値を実感しています。 Toyota Chile のシニアソフトウェアエンジニアである Rolando Sabatino 氏は、このエージェントを使って数百のカスタム ABAP オブジェクトを分析・文書化し、陳腐化したコードを特定して移行範囲を簡素化しました。 Adobe の SAP エンタープライズアーキテクトである Alex Kakhanovich 氏は、大規模な RISE への移行に先立って Kiro を評価し、「 これにより、記録的な速さで改修を実施できるでしょう。 」と語っています。パートナーもサンプルエージェントを活用してその恩恵を受けており、意義のある成果を上げています。Accenture、Capgemini、Deloitte、DXC、Kyndryl、NTT Data Global Solutions をはじめとする AWS SAP コンピテンシーパートナーは、お客様のジャーニーを加速するため、サンプルエージェントを自社の移行ツールセットに組み込んでいます。NTT Data Global Solutions は、新しい Neo i-KOU! 移行サービスにおいて ABAP 変換の工数を最大95%削減したと報告しています。Capgemini の Global SAP CTIO である Gianluca Simeone 氏は次のように述べています。「 AWS とともに、私たちは組織が SAP トランスフォーメーションのジャーニーを簡素化・加速し、より早く、より確信を持ってビジネス価値を実現できるよう支援しています。Kiro のサンプルエージェントを活用して構築した新しい Smart Integration AI Agent は、大規模な品質・ガバナンス・信頼性を強化しながら、インテグレーションの分析から構築までのサイクルを40〜60%加速できます。 」Deloitte の Global SAP on AWS Leader である Bhanu Saxena 氏は次のように述べています。「 AWS との協業により、SAP PO/PI から SAP BTP Integration Suite へ移行するエンタープライズに向けて、Kiro を活用したエージェント型の移行アプローチを導入しています。Kiro は将来に備えたインテグレーションアーキテクチャへのモダナイゼーションを加速するアクセラレーターであり、移行工数と提供期間の削減を実証しています。 」 サンプルエージェントのユースケース パートナーとお客様は、サンプルエージェントを活用して SAP のモダナイゼーションと移行の取り組みを加速できます。 SAP S/4HANA 準拠に向けた ABAP コードのアップグレード – SAP ECC システムの ABAP コードを SAP S/4HANA に準拠した ABAP コードに変換します。単一のプロンプトで数百の ABAP オブジェクトを一括変換できます。 クリーンコアに向けた ABAP のリファクタリング – SAP Clean Core Extensibility Model に沿って SAP ABAP コードのリファクタリングを自動化します。こちらも単一のプロンプトで、標準 SAP API を使用するようカスタムコードを一括でモダナイズできます。 SAP PI/PO から SAP BTP へのモダナイゼーション – SAP PI/PO のインターフェースを数分で SAP BTP Integration Suite に変換します。2027年12月の SAP PI/PO 標準サポート終了に先立ち、ミドルウェアインターフェースを迅速にモダナイズできます。 SAP Business Warehouse（BW）から Business Data Cloud（BDC）の SAP Datasphere へのモダナイゼーション – SAP BW から SAP Datasphere への移行を、数か月ではなく数時間で実現します。SAP BW も2027年12月に標準サポート終了を迎えます。 機能仕様書と技術仕様書の生成 – 既存のコードと構成を分析して包括的なドキュメントを生成します。ビジネス要件と技術仕様を作成し、AI を使ってそれらを最新の状態に保ちます。 単体テストの自動化 – 単体テストの作成と実行を自動化し、コード品質を確保してビジネスロジックの整合性を検証します。エージェントはコード変換の前後で単体テストを使用することで、品質を向上させ AI のハルシネーションを低減します。 上記の各ユースケースと、パートナーやお客様がモダナイゼーションエージェントを使って達成した成果について、さらに詳しくご覧いただけます。成果については こちら をクリックしてお読みください。 正確性を確保するためのセーフガード サンプルエージェントには、コードの正確性に対処するための独自のセーフガードが組み込まれています。80以上の事前構築済みルールを備えたカスタマイズ可能なステアリングファイルがコーディング・セキュリティ・ドキュメントの標準を適用し、独自の単体テストアプローチが変換の前後でビジネスロジックを検証して品質を確保します。サンプルエージェントは、依存するすべての ABAP コードとライブラリを評価・取得するよう設計されており、Kiro にビジネスロジックを維持するための完全なコンテキストを与えることで、ハルシネーションを大幅に低減します。また、サンプルエージェントは透明性と監査可能性のために会話履歴と意思決定のログを提供します。複数のお客様の監査チームからは、サンプルエージェントのログが通常手作業で維持されているドキュメントの水準を上回っているとの声が寄せられています。 始め方 これらの Kiro ベースのサンプルエージェントをダウンロードするには、 登録ページ でアクセスを申し込んでください。登録後、サンプルエージェントとドキュメントを含む GitHub リポジトリにアクセスできるようになります。専門家のガイダンスを受けながらモダナイゼーションを計画するには、AWS アカウントチームにお問い合わせいただくか、AWS SAP コンピテンシーパートナーにご相談ください。ベンチマークの続きについては、 Accelerate your SAP modernization with Kiro – Benchmarks and Use-Cases をご参照ください。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

2026 年 9 月 21 日週を表現するテーマが 1 つあるとすれば、「選択」ではないでしょうか。フロンティアモデルが次々と生み出される中、関心はもはや「モデルがどれほど賢いか」だけではなくなり、「このコストで、このレイテンシーで、このステップに合うモデルはどれか」になっています。 その関心に応えるモデルが、ここ数日間にわたって Amazon Bedrock に導入されました。知能と効率の対比曲線に 2 つの新たな選択肢を提供する OpenAI の GPT-6 Sol と GPT-6 Luna 、および Anthropic の Claude 5.5 ファミリー第一弾となる Claude Opus 5.5 です。 GPT-6 Sol は開発と運用における要件の厳しい反復的な作業向けに構築されており、GPT-6 Luna は的を絞った反復可能なタスクの大規模な実行を実用レベルに引き下げます。そして、どちらのモデルも前世代の GPT-5.6 からの大幅な低価格化を実現しています。一方、Claude Opus 5.5 は、Opus 5 よりも少ないトークンでより多くの処理をこなし、エージェンティックコーディングや長時間実行されるタスク向けにチューニングされています。私は、3 つのモデルのすべてが、毎回最も大きなモデルを選択するのではなく、モデルと作業をマッチさせるという同じ考え方に向かっている点がすばらしいと感じています。もう 1 つの話題は、このエージェンティックワールドにオブザーバビリティが追いついてきているということです。これには、私自身が執筆したリリース情報も含まれます。 それでは、9 月 28 日週の AWS ニュースを見ていきましょう… 9 月 21 日週のリリース 9 月 21 日週のリリースのうち、私が注目したものをいくつかご紹介します。 Amazon CloudWatch Omni の導入 – アプリケーションと AI エージェントの両方を単一のコラボレーションエクスペリエンスで観察できるようになりました。 Amazon CloudWatch Omni は OpenTelemetry 上に構築されているため、既存のテレメトリは再設定する必要がない状態で表示されます。また、チーム全体がエンタープライズ SSO を使用して 1 つの URL からアクセスするので、コンソールアクセスは必要ありません。サービスを自動検出し、依存関係をマッピングするとともに、 AWS DevOps エージェント を調査セッションに導入してシグナルを関連付け、根本原因を突き止めます。エージェントオブザーバビリティの側面に関する 関連記事 、AI 時代のオブザーバビリティとはどのようなものかを説明する AWS Cloud Operations ブログの詳しい解説記事 、具体的な詳細に関する 最新情報での発表 をご覧ください。全体像を把握したいなら、正確性を実行レベルで測定しなければならない理由に関する Matt Wood の「 壊れているのではなく、間違っている 」がお勧めです。 Amazon EventBridge の拡張カスタムイベントバス – Amazon EventBridge で、チームやアカウント間でイベント駆動アプリケーションをスケーリングする組織専用に構築された拡張カスタムイベントバスの提供が開始されました。AWS RAM を通じて、組織内のすべてのアカウント間で共有される単一の一元化されたバスをデプロイできるようになりました。これには、オプションのイベント順序付けのほか、フィルタリング、ターゲット、再試行をバンドル化する簡素化されたサブスクライバーリソース、コンテンツベースの重複排除、 AWS Lambda などのターゲットの同期呼び出しといった機能が備わっています。マルチバスセットアップの累積するクロスアカウントルーティング料金が新しいイングレス/エグレス料金モデルに置き換えられ、既存のバスは「クラシック」として引き続き以前と同様に機能します。 Amazon SageMaker HyperPod 推論ゲートウェイ – アプリケーションを一切変更せずに単一の Amazon EKS マネージドアドオンとしてデプロイされる Kubernetes ネイティブの GPU 認識ルーティングレイヤーを使用して、LLM 推論を Amazon SageMaker HyperPod の前段に配置できるようになりました。ラウンドロビン型の負荷分散の代わりに、リアルタイムの推論シグナル (KV キャッシュ使用率、キュー深度、プレフィックスキャッシュヒット、予測レイテンシーなど) に基づいてルーティングすることで、混合ハードウェアシナリオやバーストが発生するシナリオでのファーストトークンレイテンシーを最大 82% 削減します。この推論ゲートウェイは、vLLM と SGLang を含めたすべての OpenAI 互換モデルサーバーで動作します。 AWS End User Messaging と Amazon SES 向けの AI エージェントスキル – 平易な言葉を使って AI コーディングエージェントに指示することで、メッセージを作成して送信できるようになりました。 Amazon SES と AWS End User Messaging は、AWS MCP サーバー用の AI エージェントスキルを公開することで、送信 ID の検証、本番用 E メールの送信、カードとボタンを使用するブランド化された RCS エージェントの作成といったタスクに関する検証済みのステップバイステップガイダンスをエージェントに提供します。これらのスキルは Claude Code、Codex、Cursor、Kiro で動作するため、ドキュメントやコンソール画面を行き来することなくメッセージングワークフローを完了できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんが興味を持つと思われるその他の記事とリソースをいくつかご紹介します。 Strands ハーネスの導入 – Strands Agents チームが Strands ハーネスをリリースしました。このハーネスは、構築済みの汎用エージェントハーネスで、Apache 2.0 に基づいてローカルで実行、または任意の場所にデプロイできます。Python または TypeScript のコードを 1 行記述するだけで、Amazon Bedrock、Anthropic、OpenAI、Google のモデルやローカルの Ollama モデルに接続できます。これは、プロンプトキャッシュとコンテキスト管理 (肥大化したツール結果の切り捨て、コンテキストウィンドウが満杯になったときの圧縮、実行間でのメモリの保持) のための実用的なデフォルト設定が行われた状態で提供されます。チームは、同じモデルの同等のハーネスよりもコストが約 28% 低く、精度も一定に保たれていると報告しています。 2026 年 Gartner Magic Quadrant がコンテナ管理部門のリーダーとして AWS を選出 – Gartner は、4 年連続で AWS をリーダーに認定しました。コンテナが AI エージェントを構築して実行する方法のデフォルト基盤になりつつある中、この記事では、 Amazon ECS Express Mode と Amazon EKS Auto Mode から EKS プロビジョンドコントロールプレーンでの 99.99% の可用性 SLA におよぶ、コンテナに関する今後の見通しがわかりやすく説明されています。 AI に関する新しい AWS Reimagine レポートの発表 – AWS Executive in Residence チームは、9 か月にわたって 27 か国 154 人のリーダーを取材し、AI を価値に変える組織とそうでない組織の違いについてインタビューしました。この レポート は偏見のない内容になっており (Amazon で AI がうまく機能しなかった分野も含まれます)、構築が高速化するとボトルネックが意思決定、資金調達、作業のガバナンスに移行するというインサイトを繰り返し報告しています。チームが実際に AI をどのように導入するかについて考えているなら、一読の価値があります。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – AWS re:Invent がラスベガスに戻ってきます。期間は 11 月 30 日から 12 月 4 日で、セッション時間、場所、講演者が既に公開済みです。指定席の予約は 10 月 6 日に開始されます。 今すぐ登録して 、チョークトーク、ワークショップ、ビルダーズセッションに参加する準備をしましょう。 AWS Summit – re:Invent が間近に迫る中、今年の Summit も終わりに近づいています。最後の Summit は ドバイ (9 月 30 日) の Dubai World Trade Center で開催され、60 以上のセッション、AWS Village、ハンズオンワークショップに参加できます。 AWS Community Day – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンスです。今後のイベントには、 英国の ComSum Manchester (10 月 1 日) と イタリアの AWS Community Day Italy (10 月 2 日) があります。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。9 月 28 日週のニュースは以上です。10 月 5 日週の Weekly Roundup もお楽しみに! – Daniel Abib 原文は こちら です。

本ブログは 2026 年 9 月 29 日に公開された Amazon Press Center “ OCC Strengthens Security Operations with an Agentic AI Investigation Solution Built on AWS ” を翻訳したものです。 米国イリノイ州シカゴ、2026 年 9 月 29 日 – 世界最大の株式デリバティブ清算機関である The Options Clearing Corporation (OCC)® は本日、Amazon Web Services の Amazon Bedrock で構築した AI 搭載のセキュリティ調査エージェント (以下「SOC エージェント」) の導入を発表しました。このソリューションは、OCC のセキュリティオペレーションセンターにおけるセキュリティアラートの調査を自動化し、説明可能かつ監査可能な結果を提供します。さらに、継続的な改善に向けて、ヒューマンインザループによるフィードバックの仕組みを構築します。 「私たちがサービスを提供する市場を守る取り組みは、強固なセキュリティオペレーションから始まります。システム上重要な金融市場インフラである OCC が運用するセキュリティオペレーションセンターでは、絶え間なく発生するセキュリティアラートを、迅速かつ一貫して、妥当性を説明できる水準で調査する必要があります」と、OCC の副最高セキュリティ責任者である Ben Le 氏は述べています。「SOC エージェントは、調査ワークフローを自動化しつつ、プロセスとその結果に対する主導権を OCC のセキュリティ専門家が確実に握り続けられるように設計されています」 SOC エージェントは、OCC の SIEM (Security Information and Event Management) プラットフォーム内のセキュリティデータに対してエージェンティックループを実行し、アナリストと同じように、調査の方針を立て、関連する証拠を取得し、得られた結果を評価し、次に調べる対象を判断しながらアラートの調査を進めます。このエージェントによって手作業の負担や調査のばらつきが軽減され、熟練したアナリストは分析、エスカレーション、そして最も複雑なケースに集中できるようになります。 「OCC が Amazon Bedrock 上で開発した SOC エージェントは、エージェンティック AI が即座にビジネス価値をもたらすことを示す好例です。このアプローチは、AI を活用して既存の調査ワークフローを強化しつつ、セキュリティに不可欠な人間による判断を維持しています」と、AWS の Financial Services Governance, Risk, and Compliance 担当ディレクターである Jeff Axelrad は述べています。 OCC について The Options Clearing Corporation (OCC) は、世界最大の株式デリバティブ清算機関です。1973 年に設立された OCC は、オプション、先物、証券貸借取引の清算および決済サービスを提供することで、市場の安定性と健全性の促進に取り組んでいます。システム上重要な金融市場ユーティリティ (SIFMU) として、OCC は米国証券取引委員会 (SEC)、米国商品先物取引委員会 (CFTC)、連邦準備制度理事会の管轄下で事業を運営しています。OCC には 100 を超える清算会員があり、22 の取引所と取引プラットフォームに中央清算機関 (CCP) としての清算および決済サービスを提供しています。OCC の詳細については、 www.theocc.com をご覧ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2026年7月29日から 2 日間にわたって、 アマゾンウェブサービスジャパン合同会社はパシフィコ横浜で開催された KubeCon + CloudNativeCon Japan 2026 においてスポンサーとしてブースを出展しており、たくさんの方にご来場いただきました。（ご来場いただいた皆様、有難うございました！）   AWS ブースでは、2日間で 12 のデモセッションを行い、多くのご来場者にご視聴いただきました。その際にセッション資料をシェアしてほしいとのご要望をいくつか頂いたことを受け、こちらのブログ で各セッションの資料を公開させて頂きます。デモセッションの内容について、EKS Auto Mode・AI エージェント・セキュリティ・コスト最適化など、Amazon EKS の最新機能と運用自動化を実演する内容となり、詳細は以下に記載させて頂いています。ご参考いただけますと幸いです。   7/29(水) 11:00-11:15 | AWS DevOps Agent による EKS 上のインシデント対応の迅速化 （Japanese） >>> セッション資料 フロンティアエージェントの一つである DevOps Agent は、従来のシステム運用を根本的に変革するサービスです。本セッションでは、DevOps Agent の概要を紹介し、EKS 上で稼働するシステムのインシデントをどのように調査するかをデモします。   [Speaker] Yuya Hirooka – Partner SA   7/29(水) 12:00-12:15 | トレーニングと推論のためのモデルロード高速化 （Japanese） >>> セッション資料 大規模モデルのトレーニングおよび推論ワークロードは、数十〜数百ギガバイトに及ぶコンテナイメージの取得とモデルウェイトの読み込みによるコールドスタートの問題を抱えています。本セッションでは、EKS Auto Mode 上で SOCI パラレルプル、Mountpoint for Amazon S3 によるストリーミング、Run:ai Model Streamer による GPU への直接ロードの 3 つの手法を紹介し、起動時間の短縮と手法の選び方を解説します。   [Speaker] Kosuke Sobue – ISV/SaaS Solutions Architect   7/29(水) 13:00-13:15 | モデルからエージェントへ — Amazon EKS Auto Mode で LLM 駆動 AI アプリケーションを稼働させる （English） >>> セッション資料 AI が推論エンドポイントからエージェント型アプリケーションへと進化する中、Kubernetes 上で LLM を稼働させるには新たな課題が生じます。本セッションでは、Amazon EKS Auto Mode が LLM 駆動のエージェント AI を大規模にデプロイ・運用する方法を、オープンソース LLM のライブデプロイと、推論と外部アクションを連携するエージェントアプリケーションを通じて紹介します。GPU コンピューティングは Ray と vLLM により自動管理されます。   [Speaker] Sai Vennam – Prin. WW Spec. SA, Containers   7/29(水) 13:40-13:55 | EKS セキュリティ：Admin & Advanced Network Policies （Japanese） >>> セッション資料 マイクロサービスが拡大するにつれ、セキュリティと開発スピードの両立が課題となります。本セッションでは、Amazon EKS Network Policies がサービスメッシュなしで多層防御を実現する方法を紹介します。Admin ポリシーがクラスター全体のベースラインを強制し、Advanced ポリシーが L7 FQDN ベースの Egress 制御を追加します。いずれも EKS Auto Mode 上の VPC CNI の eBPF エンジンで動作します。   [Speaker] Toshikazu Ichikawa – Snr Partner SA   7/29(水) 15:25-15:40 | EKS でのプラットフォームエンジニアリング：開発者セルフサービス GitOps ゴールデンパス（ArgoCD、ACK、KRO） （Japanese） >>> セッション資料   マネージド EKS の機能群（ArgoCD、ACK、KRO）を活用した GitOps ベースのプラットフォームで、ワークロードレベルのゴールデンパスを提供します。一例として LLM 推論を取り上げ、開発者が単一の InferenceEndpoint を宣言して git push するだけで、GPU のプロビジョニング、モデル提供（Ray Serve + vLLM）、セルフサービスでの公開までをプラットフォームが自動で行います。   [Speaker] Yuji Matsuoka – Solutions Architect, TELCO   7/29(水) 16:30-16:45 | AWS Neuron による動的リソース割り当て （Japanese） >>> セッション資料 Dynamic Resource Allocation（DRA）が Kubernetes 1.36 で GA となり、GPU などのハードウェアデバイスをより柔軟に割り当てられるようになりました。本デモでは、DRA の仕組みと使い方を説明し、AWS 固有のトピックとして Trainium での DRA 利用についても紹介します。   [Speaker] Kenta Goto – ISV/SaaS Solutions Architect   7/29(水) 17:50-18:05 | Kubernetes 上のマルチテナント AI トレーニングのための DRA ベースカスタム GPU スケジューラー （English）   組織が Kubernetes 上で AI ワークロードをスケールさせる際、チーム間での GPU 管理はフラグメンテーション、リソース競合、マルチノード間の調整失敗といった課題を生みます。本セッションでは、Kubernetes の DRA フレームワーク上に構築したカスタム GPU スケジューラーを紹介します。NVIDIA ResourceSlices を評価して共有モードを考慮した配置を行い、フラグメンテーションのないビンパッキングを適用し、クォータ管理、ギャングスケジューリング、デッドラインを考慮したバックフィルを含むマルチテナントポリシーを強制します。   [Speaker] Youngjoon Jeong – Sr. GTM SSA Containers Korea   7/30(木) 11:00-11:15 | AI によるシフトレフト：PR から本番までの K8s マニフェスト自動レビュー （Japanese） >>> セッション資料 経験豊富なレビュアーでも、特権コンテナ、平文シークレット、リソースリミットの未設定といった Kubernetes マニフェストの重大な問題を見落とすことがあります。本セッションでは、Amazon Bedrock 上の Claude を活用してレビューをシフトレフトする方法を紹介します。プルリクエストごとにセキュリティ、コスト、信頼性を分析し、インラインで修正提案を投稿し、堅牢化された YAML を自動コミットします。マージ後は ArgoCD があるべき状態を強制し、ドリフトを検知します。   [Speaker] Kyosuke Konishi – Associate Solutions Architect   7/30(木) 12:00-12:15 | AI エージェントのためのインフラ：AI エージェントワークロード向け Kro テンプレート （Japanese） >>> セッション資料 Kro と ACK を使い、AI エージェントのインフラ（複数の Kubernetes リソース + AWS リソース）を単一のカスタムリソースとしてテンプレート化します。AI エージェントワークロードを簡単にデプロイする方法をデモします。   [Speaker] Shota Suzuki – Solutions Architect   7/30(木) 13:00-13:15 | Amazon EKS Auto Mode による Kubernetes コスト最適化：Spot、統合、ゼロコンフィグ （English）   Kubernetes のコスト最適化には通常、Spot の専門知識、ノードグループのチューニング、キャパシティプランニングが必要です。EKS Auto Mode は、自動 Spot 統合、インテリジェントなインスタンス選択、低トラフィック時の継続的な統合、サブミニッツのバーストスケーリングにより、この運用負荷を解消します。Karpenter が手動設定なしでコスト効率を実現する様子をご覧ください。   [Speaker] Alex Kestner – Principal PMT-ES, Kubernetes   7/30(木) 13:40-13:55 | もう後戻りできない？そんな時代は終わり — EKS バージョンロールバックと恐れ知らずの Kubernetes アップグレード新時代 （Japanese） >>> セッション資料 Kubernetes のアップグレードは常に一方通行であり、チームはアップグレードを先延ばしにしたり、サポート切れのバージョンを使い続けたりしてきました。2026 年 7 月、Amazon EKS はバージョンロールバックを提供開始し、etcd データとワークロードを保持したまま 7 日以内に前のマイナーバージョンへ戻せるようになりました。本セッションでは、その仕組みと、ロールバックパスがアップグレード戦略をどう変えるかを解説します。   [Speaker] Ryota Yamada – Solutions Architect   7/30(木) 15:25-15:40 | EKS 向け Agent Skills：AI エージェントにスペシャリストレベルのアップグレード＆運用知識を （English） >>> セッション資料 EKS のアップグレードやクラスターヘルスレビューは、専門知識の不足から先送りされがちな Day-2 タスクです。本デモでは、シニア AWS スペシャリストの知見をエンコードしたキュレーション済み Agent Skills を紹介し、Claude Code や Kiro などのコーディングエージェントに読み込ませます。非推奨 API やアドオンの競合をスコア付き Go/No-Go レポートで検出し、優先度付きの運用レビューを実行する様子をご覧ください。オープンソースの APEX コレクションは Agent Skills 標準に準拠し、数分でスペシャリストレベルのアウトプットを提供します。   [Speaker] Eng-Hwa Tan – Prin. GTM SSA Containers ASEAN / Masatoshi Hayashi – Sr. GTM SSA Containers Japan  

数百万件のアイテムに対する強力な検索は、高い関連性を維持しつつ、高速かつ正確で、手軽に実現できるべきです。リレーショナルデータベースは構造化データの保存手段として広く普及しており、多くの組織がコアとなるビジネス情報の格納に活用しています。リレーショナルデータベースは構造化データの保存と取得に優れていますが、大量の非構造化テキストの検索には苦労することが多く、パフォーマンス上の理由から、通常はすべての列にインデックスを付けているわけではありません。 対照的に、OpenSearch などの検索エンジンはすべてのフィールドにインデックスを付けるため、セマンティック検索を含む豊富な検索機能や、数値データを要約・分析するための強力な集計機能を利用できます。従来、組織は検索インデックスをデータベースと最新の状態に保つために、ETL（抽出・変換・ロード）パイプラインを含む、複雑で非効率的、かつコストのかかるデータ同期プロセスを管理してきました。高度な検索機能でアプリケーションを強化したい場合、カスタムデータ同期プロセスを管理するオーバーヘッドなしに、データベースとの検索インデックスの同期を維持できる、よりシンプルなソリューションが求められます。 Amazon OpenSearch Service と Amazon Relational Database Service (Amazon RDS) および Amazon Aurora の統合が一般提供開始されたことを発表できることを嬉しく思います。この新しい統合により、複雑なデータパイプラインが不要になり、Amazon Aurora (Amazon Aurora MySQL 互換エディションおよび Amazon Aurora PostgreSQL 互換エディションを含む) および Amazon RDS データベース (Amazon RDS for MySQL および Amazon RDS for PostgreSQL を含む) と Amazon OpenSearch Service の間でニアリアルタイムのデータ同期が可能になります。トランザクションデータベース上でハイブリッド検索、ランク付き検索、ファセット検索などの高度な検索機能を活用できるようになります。データ同期を管理する代わりに、優れた顧客体験の創出に集中しながら、低レイテンシで高スループットの検索結果、リアルタイムの在庫更新、パーソナライズされたレコメンデーションなどを提供できるようになりました。この統合により、複雑な ETL パイプラインの維持にかかる運用負荷とコストが削減されるとともに、検索データを即座に利用できるようになります。 Amazon OpenSearch Ingestion は、Amazon Aurora または Amazon RDS と OpenSearch Service の間でニアリアルタイムのデータ同期を提供します。Aurora または RDS データベースを選択すれば、残りは OpenSearch Ingestion が処理します。Aurora MySQL または RDS for MySQL (8.0 以降)、Aurora PostgreSQL または RDS for PostgreSQL (16 以降) の両方をサポートします。 これらのサービスがどのように機能するかを以下に示します。 データ取り込み – まず、Aurora または Amazon RDS が初期データを Amazon Simple Storage Service (Amazon S3) にエクスポートし、OpenSearch Ingestion がそのスナップショットを S3 からロードします。次に、Aurora または Amazon RDS の変更データキャプチャ (CDC) ストリームを使用して、以降の変更をニアリアルタイムでレプリケートし、OpenSearch Service にインデックスします。この自動化されたプロセスにより、データは OpenSearch 内で一貫して最新の状態に保たれ、手動による介入なしに検索と分析にすぐに利用できるようになります。 リアルタイムクエリ – OpenSearch Service は、データに対して複雑な検索と集計を実行できる強力な クエリ機能 を提供します。トレンドの分析、異常の検出、あるいはアプリケーションに検索結果を返すクエリの実行など、いずれのユースケースにも OpenSearch Service は必要なツールを提供します。 次の図は、Amazon Aurora をソースとした場合のソリューションアーキテクチャを示しています。 データベースソースの構成 同期を設定する前に、ソースデータベースのロギング設定を行う必要があります。Aurora MySQL の場合は、クラスターパラメータグループで拡張バイナリログ設定を有効にします。Amazon RDS の場合は、インスタンスパラメータグループの設定を通じて、基本的なバイナリロギングまたは論理レプリケーションを有効にします。これらの ロギング設定 により、OpenSearch Ingestion はデータベースからの変更をキャプチャしてレプリケートできるようになります。 Aurora MySQL のサンプル HR データベース は、この統合がどのように機能するかを示す良いサンプルです。 ビューを作成する前に、OpenSearch がこのデータをどのように表現するかを説明します。 OpenSearch マッピング は、ドキュメントとそのフィールドの保存・インデックス方法を定義するもので、データベーススキーマがテーブルと列を定義するのと同様の役割を果たします。OpenSearch Ingestion パイプラインはデフォルトで動的マッピングを使用し、Aurora または Amazon RDS のデータ型を適切な OpenSearch フィールド型に自動的に変換します。例えば、データベースの DATE フィールドは OpenSearch の日付型になり、数値フィールドは対応する OpenSearch の数値型にマッピングされます。 インデックステンプレート を使用してマッピングをカスタマイズすることも可能ですが、デフォルトのマッピングは通常、日付、数値、テキストフィールドなどの一般的なデータ型を正しく処理します。 GET employees/_mapping この統合が複雑なデータリレーションシップを処理できることを示すために、OpenSearch Ingestion が結合されたデータをどのように扱うかを見ていきましょう。サンプル HR データベースにビューを作成し、複数の関連テーブルからの情報を OpenSearch 内の単一の検索可能なドキュメントに統合します。このアプローチは、正規化されたデータベース構造を、検索操作に最適化された非正規化ドキュメントに変換する方法を示しています。 この employee_details ビューは、複数テーブルからのデータを統合し、豊富で非正規化された従業員情報を表現しています。OpenSearch Ingestion パイプラインは、ビュー (MySQL ベースのソースの場合) またはビューとマテリアライズドビュー (PostgreSQL ベースのソースの場合) の取り込みをサポートしていないことに注意してください。論理レプリケーションシステムの制限により、パイプラインは基盤となるベーステーブルからの変更のみを追跡します。したがって、ビュー自体は取り込めないため、ビューで定義したカラム構成を参考に、基盤となるベーステーブルをレプリケートするようにパイプラインを構成します。これにより、OpenSearch 上では各従業員が単一の包括的なドキュメントとして表現されます。この構造により、元々は別々だったテーブルにまたがる高速で複雑なクエリが可能になります。例えば、特定の部門や国の従業員を検索したり、地域間の給与分布を分析したりするなど、正規化されたデータベース構造では複雑で遅くなるクエリを簡単に実行できます。 次のスクリーンショットに示すパイプライン構成では、OpenSearch Ingestion が HR データベースに接続し、ソースデータベースとレプリケート対象のベーステーブルを識別する様子を確認できます。ビュー (および PostgreSQL ベースのソースでのマテリアライズドビュー) は取り込みソースとしてサポートされていないため、パイプラインはビュー自体ではなく、基盤となるベーステーブルからの変更を追跡します。OpenSearch Ingestion はこれらの関係を自動的に維持するため、これらのテーブルへの変更が OpenSearch インデックスに反映され、検索データがソースデータベースと一貫性を保つようになります。 以下に示す GIF では、OpenSearch Ingestion のビジュアルエディタを使用してこの統合を設定するデモを確認できます。 また、インデックスマッピングテンプレートを指定して、Aurora または Amazon RDS のフィールドを OpenSearch Service インデックスの適切なフィールドにマッピングすることもできます。 パイプラインの包括的な設定概要については、 OpenSearch Data Prepper のドキュメント を参照してください。パイプラインには AWS Identity and Access Management (IAM) ロールを設定する必要があります。手順については、 パイプラインロールの構成 を参照してください。 OpenSearch Ingestion で統合を構成すると、パイプラインは OpenSearch Dashboards で表示できるインデックスを自動的に作成します。OpenSearch Ingestion はまず、Aurora または Amazon RDS データベースの Amazon S3 への自動エクスポートをトリガーし、次に S3 からこのスナップショットデータを OpenSearch クラスターにロードして初期インデックスを作成します。この初期ロードの後、OpenSearch Ingestion は MySQL ベースのデータベースの場合はバイナリログ (binlog)、PostgreSQL ベースのデータベースの場合は先行書き込みログ (WAL) を使用して変更を継続的にキャプチャします。これにより、OpenSearch インデックスはソースデータベースとニアリアルタイムで同期された状態を保ちます。以下を呼び出すことで、OpenSearch Dashboards でインデックスを表示できます。 GET _cat/indices レスポンスの例： employee テーブルの最初の 5 つのエントリを考えてみましょう。 データベースに変更を加えると、OpenSearch Ingestion は変更データで Amazon OpenSearch Service を更新します。例えば、次のコードは従業員の給与を更新します。 UPDATE hr.employees SET SALARY = 26000 WHERE EMPLOYEE_ID = 100; Amazon Aurora が変更通知を送信し、OpenSearch Ingestion パイプラインがそれを取得して、OpenSearch Ingestion が変更されたレコードをニアリアルタイムで OpenSearch に送信します。これは OpenSearch クエリで確認できます。 GET employees/_search この機能に関する重要な詳細： モニタリング – CloudWatch メトリクス と OpenSearch Ingestion ダッシュボードを通じて、パイプラインのパフォーマンスとデータ同期を追跡します 制限事項： 同一リージョンおよび同一アカウントでのデプロイが必須で、最適な同期のためにプライマリキーが必要です。現在、データ定義言語 (DDL) ステートメントのサポートはなく、ビュー (MySQL) またはビューとマテリアライズドビュー (PostgreSQL) の取り込みはサポートされていません。論理レプリケーションシステムを通じて追跡されるのはベーステーブルのみです Amazon Aurora または Amazon RDS と Amazon OpenSearch Service の統合は、OpenSearch Ingestion が利用可能なすべての AWS リージョンで一般提供開始されました。 詳細については、Aurora または Amazon RDS と Amazon OpenSearch Service の統合に関する AWS ドキュメントを参照してください。 Using an OpenSearch Ingestion pipeline with Amazon Aurora – Amazon OpenSearch Service Using an OpenSearch Ingestion pipeline with Amazon RDS – Amazon OpenSearch Service About the authors Michael Torio は、カリフォルニア州マウンテンビューを拠点とし、Amazon OpenSearch Service を専門とする AWS のアソシエイトスペシャリストソリューションアーキテクトです。Michael は、お客様がクラウドテクノロジーを活用してビジネス上の課題を解決するためのサポートに取り組んでいます。 Sohaib Katariwala は、イリノイ州シカゴを拠点とし、Amazon OpenSearch Service を専門とする AWS のシニアスペシャリストソリューションアーキテクトです。彼の関心はデータと分析に関するあらゆるものにあります。お客様がデータ戦略の中で AI を活用して現代の課題を解決するためのサポートに喜びを感じています。 Arjun Nambiar は、Amazon OpenSearch Service のプロダクトマネージャーです。彼は、さまざまなソースからのデータを大規模に Amazon OpenSearch Service に取り込むことを可能にする取り込みテクノロジーに注力しています。Arjun は大規模分散システムとクラウドを中心としたテクノロジーに関心があり、ワシントン州シアトルを拠点としています。 原文は こちら です。

本ブログは 2026 年 2 月 9 日に公開された AWS Blog “ Automated Reasoning checks rewriting chatbot reference implementation ” を翻訳したものです。 本日 (2026 年 2 月 9 日)、 新しいオープンソースのサンプルチャットボット を公開します。このサンプルでは、自動推論チェック (Automated Reasoning checks) のフィードバックを使って、生成されたコンテンツを反復的に改善し、確認のための質問を行い、回答の正しさを証明する方法を紹介します。 このチャットボットは、回答の妥当性について数学的に検証可能な説明を含む監査ログを生成します。さらに、裏側で動く反復的な書き換えプロセスを開発者が確認できるユーザーインターフェイスも備えています。Amazon Bedrock Guardrails の自動推論チェックは、論理的な演繹によってある記述が正しいことを自動的に示す仕組みです。大規模言語モデル (LLM) のように正確性を推測したり予測したりするのではなく、数学的な証明によってポリシーへの準拠を検証します。このブログ記事では、自動推論チェックを使った書き換えチャットボットの実装アーキテクチャを詳しく解説します。 自動推論チェックで高める正確性と透明性 LLM は、説得力があるように見えて事実に反する内容を含む応答を生成することがあります。これはハルシネーションと呼ばれる現象です。自動推論チェックは、ユーザーの質問と LLM が生成した回答を検証し、書き換えフィードバックを返します。このフィードバックは、自動推論ポリシー (Automated Reasoning policy) にエンコードされたグラウンドトゥルースの知識に基づいて、あいまいな記述、範囲が広すぎる断定、事実に反する主張を指摘します。 回答をユーザーに提示する前に、自動推論チェックで反復的に改善するチャットボットは、 正確性の 向上 に役立ちます。あいまいさの余地を残さず、「はい/いいえ」形式の質問に明確に答える正確な記述ができるようになるからです。また、 透明性の向上にも役立ちます 。記述が正しい理由を数学的に検証可能な証明として示せるため、規制のある環境でも生成 AI アプリケーションを監査可能かつ説明可能にできます。 メリットを確認したところで、これをご自身のアプリケーションでどのように実装するかを見ていきましょう。 チャットボットのリファレンス実装 この チャットボット は Flask アプリケーションで、質問の送信と回答のステータス確認を行う API を公開しています。システムの内部動作がわかるように、これらの API では各イテレーションのステータス、自動推論チェックからのフィードバック、LLM に送信した書き換えプロンプトも取得できます。 フロントエンドの NodeJS アプリケーションでは、回答生成に使う Amazon Bedrock の LLM を設定し、検証に使う自動推論ポリシーを選択し、回答を修正するイテレーションの最大回数を指定できます。ユーザーインターフェイスでチャットスレッドを選択すると右側にデバッグパネルが開き、コンテンツに対する各イテレーションと検証出力が表示されます。 図 1 – デバッグパネル付きのチャットインターフェイス 自動推論チェックが応答を妥当と判定すると、その妥当性についての検証可能な説明が表示されます。 図 2 – 自動推論チェックによる妥当性の証明 反復的な書き換えループの仕組み この オープンソースのリファレンス実装 は、自動推論チェックからのフィードバックを反復的に処理して応答を書き換えることで、チャットボットの回答を自動的に改善するのに役立ちます。チャットボットの質問と回答 (Q&A) の検証を要求すると、自動推論チェックは検出結果 (finding) のリストを返します。各検出結果は、入力された Q&A の中で特定された、独立した論理的な記述を表します。例えば「S3 ストレージの料金はいくらですか? 米国東部 (バージニア北部) では、S3 の料金は最初の 50 TB について 0.023 USD/GB です。アジアパシフィック (シドニー) では、S3 の料金は最初の 50 TB について 0.025 USD/GB です」という Q&A の場合、自動推論チェックは 2 つの検出結果を生成します。1 つは us-east-1 における S3 の料金が 0.023 USD であることを検証するもの、もう 1 つは ap-southeast-2 に関するものです。 Q&A の検出結果を解析するとき、自動推論チェックは入力を、事実に関する前提 (premise) のリストと、それらの前提に基づく主張 (claim) に分けます。前提には、「私はバージニアの S3 ユーザーです」のようにユーザーの質問に含まれる事実の記述や、「us-east-1 に送信されるリクエストについては…」のように回答内で示された仮定が該当します。主張は、検証対象となる記述です。前の段落の S3 料金の例では、リージョンが前提、価格が主張になります。 各検出結果には、検証結果 ( VALID 、 INVALID 、 SATISFIABLE 、 TRANSLATION_AMBIGUOUS 、 IMPOSSIBLE ) と、回答を VALID にするために必要なフィードバックが含まれます。フィードバックの内容は検証結果によって変わります。例えば、あいまいな検出結果には入力テキストの 2 つの解釈が含まれ、充足可能な検出結果には、主張が真になる場合と偽になる場合をそれぞれ示す 2 つのシナリオが含まれます。想定される検出結果の種類は API ドキュメント でご確認いただけます。 訳注: 2026 年 9 月現在、検証結果には、本文で挙げられている 5 種類に加えて NO_TRANSLATIONS と TOO_COMPLEX があり、全 7 種類が定義されています。最新の一覧は、Amazon Bedrock ユーザーガイドの「 自動推論チェックの概念 」を参照してください。 ここまでの背景を踏まえて、リファレンス実装の仕組みを詳しく見ていきましょう。 初回の応答と検証 ユーザーが UI から質問を送信すると、アプリケーションはまず設定された Amazon Bedrock の LLM を呼び出して回答を生成し、次に ApplyGuardrail API を呼び出して Q&A を検証します。 アプリケーションは ApplyGuardrail 応答に含まれる自動推論チェックの出力を使ってループに入ります。各イテレーションでは、自動推論チェックのフィードバックを確認し、そのフィードバックに基づいて LLM に回答の書き換えを依頼するといったアクションを実行し、その後 ApplyGuardrail を呼び出して更新後のコンテンツを再検証します。 書き換えループ (システムの中核) 初回の検証が終わると、システムは自動推論チェックの出力から次のステップを決定します。まず検出結果を、最も重要なものが先頭になるように優先度順に並べ替えます。優先度は TRANSLATION_AMBIGUOUS 、 IMPOSSIBLE 、 INVALID 、 SATISFIABLE 、 VALID の順です。次に、最も優先度の高い検出結果を選び、以下のロジックで対処します。 VALID はこの並びの最後にあるため、システムは他の検出結果に対処した後にのみ、内容を VALID として受け入れます。 TRANSLATION_AMBIGUOUS の検出結果では、自動推論チェックが入力テキストの 2 つの解釈を返します。 SATISFIABLE の検出結果では、主張を証明するシナリオと反証するシナリオの 2 つを返します。アプリケーションはこのフィードバックを使い、あいまいさを解消するために回答の書き換えを試みるか、不足している情報を集めるためにユーザーへ追加の質問を行うかの判断を LLM に依頼します。例えば SATISFIABLE のフィードバックでは、0.023 USD という料金はリージョンが米国東部 (バージニア北部) の場合にのみ妥当だと示されることがあります。LLM はこの情報を使って、アプリケーションのリージョンをたずねることができます。LLM が追加の質問を行うと判断した場合、ループは一時停止してユーザーの回答を待ちます。その後、LLM は明確になった情報に基づいて回答を再生成し、ループが再開されます。 IMPOSSIBLE の検出結果では、自動推論チェックが前提 (入力コンテンツ内で受け入れられた事実) と矛盾するルールのリストを返します。アプリケーションはこのフィードバックを使い、論理的な矛盾を避けるように回答を書き換えることを LLM に依頼します。 INVALID の検出結果では、自動推論チェックが該当するルールを返します。これらは、前提とポリシールールに基づいて主張を無効と判断する根拠になった、自動推論ポリシー内のルールです。アプリケーションはこのフィードバックを使い、ルールと整合するように回答を書き換えることを LLM に依頼します。 VALID の検出結果では、アプリケーションはループを終了し、回答をユーザーに返します。 回答を書き換えるたびに、システムは Q&A を検証のために ApplyGuardrail API へ送信します。ループの次のイテレーションは、この呼び出しのフィードバックから始まります。各イテレーションは検出結果とプロンプトを完全なコンテキストとともにスレッドのデータ構造に保存し、システムが最終的な回答に至った過程の監査証跡を作成します。 自動推論チェックによる書き換えチャットボットの始め方 このリファレンス実装を試すには、最初のステップとして自動推論ポリシーを作成します。 AWS マネジメントコンソールで Amazon Bedrock に移動します。このとき、米国または欧州の サポートされているリージョン のいずれかを選択します。 左側のナビゲーションから、 Automated Reasoning ページを開きます。このページは Build カテゴリにあります。 [ポリシーを作成] ボタンのドロップダウンメニューから、 [サンプルポリシーを作成] を選択します。 ポリシーの名前を入力し、ページ下部の [ポリシーを作成] を選択します。 ポリシーを作成したら、リファレンス実装をダウンロードして実行できます。 Amazon Bedrock の サンプルリポジトリ をクローンします。 README ファイル の手順に従って、依存関係をインストールし、フロントエンドをビルドして、アプリケーションを起動します。 お好みのブラウザで http://localhost:8080 にアクセスし、テストを開始します。 訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語のため、テストでは英語で質問を入力してください。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 バックエンド実装の詳細 この実装を本番環境向けに応用する予定の方に向けて、以下ではバックエンドアーキテクチャの主要コンポーネントを説明します。これらのコンポーネントは、リポジトリの backend ディレクトリにあります。 ThreadManager: 会話のライフサイクル管理をオーケストレーションします。会話スレッドの作成、取得、ステータス追跡を担い、書き換えプロセス全体で適切な状態を維持します。ThreadManager はロックを使ってスレッドセーフな操作を実装しており、複数の操作が同じ会話を同時に変更しようとしたときの競合状態を防ぐのに役立ちます。また、ユーザー入力を待っているスレッドを追跡し、設定可能なタイムアウトを超えた古いスレッドを特定できます。 ThreadProcessor: ステートマシンパターンで書き換えループを処理し、明確で保守しやすい制御フローを実現します。プロセッサは GENERATE_INITIAL 、 VALIDATE 、 CHECK_QUESTIONS 、 HANDLE_RESULT 、 REWRITING_LOOP といったフェーズ間の状態遷移を管理し、各段階を通じて会話を正しく進行させます。 ValidationService: Amazon Bedrock Guardrails と統合します。LLM が生成した各応答を受け取り、 ApplyGuardrail API を使って検証のために送信します。AWS との通信を担い、一時的な障害に対してエクスポネンシャルバックオフによる再試行ロジックを管理し、検証結果を解析して、構造化された検出結果に変換します。 LLMResponseParser: 書き換えループ中の LLM の意図を解釈します。システムが無効な応答の修正を LLM に依頼すると、モデルは書き換えを試みる ( REWRITE )、確認のための質問を行う ( ASK_QUESTIONS )、前提の矛盾によりタスクが実行不可能だと宣言する ( IMPOSSIBLE ) のいずれかを判断する必要があります。パーサーは LLM の応答から DECISION: 、 ANSWER: 、 QUESTION: といった特定のマーカーを探し、自然言語の出力から構造化された情報を抽出します。Markdown 形式も適切に処理し、質問数の上限 (最大 5 件) を適用します。 AuditLogger: 構造化された JSON ログを専用の監査ログファイルに書き込み、2 種類の主要なイベントを記録します。1 つは応答が検証に合格したときの VALID_RESPONSE 、もう 1 つはシステムが設定された再試行回数を使い切ったときの MAX_ITERATIONS_REACHED です。各監査エントリには、タイムスタンプ、スレッド ID、プロンプト、応答、モデル ID、検証の検出結果が記録されます。さらに、確認のためのイテレーションから Q&A のやり取りを抽出して記録します。その際、ユーザーが質問に回答したかスキップしたかも含めます。 これらのコンポーネントを組み合わせることで、LLM の柔軟性と数学的検証の厳密さを兼ね備えた、信頼できる AI アプリケーションの堅牢な基盤を構築しやすくなります。 自動推論チェックを本番環境で実装する際の詳しいガイダンスは次のとおりです。 ワークショップ : Generative AI Reliability with Automated Reasoning checks 技術ブログ : Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks 訳注: 上記の記事はプレビュー期間中 (2025 年 4 月) に公開されたものです。一般提供開始後の機能に基づいた手順は、日本語版ブログの「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」を参照してください。 ユースケースブログ : Build verifiable explainability into financial services workflows with Automated Reasoning checks for Amazon Bedrock Guardrails ドキュメント : Amazon Bedrock Guardrails ユーザーガイド 著者について Stefano Buliani Stefano は AWS の Automated Reasoning チームの Product Manager です。AWS に 10 年以上在籍し、Serverless Java Container などのオープンソースプロジェクトを含むサーバーレス技術に携わり、数百のアプリケーションを本番環境にデプロイするお客様を支援してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本日、Kiro workflows を発表します。複数のエージェントを使い、少ない監督で複雑なタスクを最初から最後までやり遂げられる機能です。私たちは Kiro 自体の開発にも workflows を使ってきました。新しいクラウド構成、クラウドセッション、そして workflows 体験の大部分がその成果です。 workflows 以前は、エージェントに変更の実装を頼み、戻ってきてから「この変更をコードレビューして」と伝え、さらに後で「レビューの指摘に対応して」と頼んでいました。セッションの大半を監督に費やし、ステップを飛ばせば再度プロンプトを送り、以前の決定事項をエージェントに思い出させていました。セッション内では順序の制御はモデルが担いますが、モデルの注意力には限りがあります。合意した内容はすべて、ツール出力やファイル内容で埋まっていく同じコンテキストウィンドウに置かれているため、まだ残っている作業をエージェントが忘れたときにも私たちが介入していました。この問題を回避するために、作業を別々のセッションに分け、セッションをまたいで残るファイルに計画を書いていましたが、それでも各セッションが何をしているかを覚えておき、セッション間で結果を受け渡す必要がありました。こうした手動のワークフローは良い結果を生むこともありますが、準備に時間がかかります。うまくいくプロセスができたら、手で組み直すことなく、その実行を指して「もう一度やって」と言いたいものです。 Kiro workflows はこれを解決します。workflows では、どのエージェントがどの順序で作業するかをモデルが定義し、Kiro ランタイムがその計画を実行するので、各ステップがリマインドなしで予定どおりに実行されます。workflows は、エージェントステップ、シーケンス、ループ、並列ブランチで構成されるグラフで、人間とエージェントの両方が読み書きできる形式で表現されます。各ステップは新しいコンテキストを持つ独立したセッションで実行されるため、たとえばレビュアーはコーダーの推論を引き継がずに作業を評価できます。Kiro は目の前のタスクに合わせて workflow を生成します。生成された workflow はレシピとして保存して再利用でき、自分で書くこともできます。 workflows はバックグラウンドで実行されるため、委任した作業が進む間もメインの会話で Kiro との作業を続けられます。workflow の各ステップのセッションは実行中も参照でき、一時停止、再開、方向修正ができます。実行後もフォローアップの質問のために戻れます。小さな調査を委任するだけでも、そのツール出力や詳細な推論がメインの会話に入らないため、作業を続けるためのコンテキストを温存できます。 workflows で Kiro を開発する Kiro IDE Kiro CLI Kiro Web ランタイムが動くようになってすぐ、私たちは workflows を使って、workflow ランタイム自体の大部分と Kiro Web との統合全体を開発しました。フロントエンド、API と社内サービス、Kiro のエージェントハーネスにまたがるフルスタックの作業で、それぞれの部分を別々の workflow が並列に担当しました。 実装を担う workflow は、変更を分離するためにそれぞれ別の Git worktree を使いました。エージェントがコンポーネント間の問題を見つけると、メインセッションが影響を受ける workflow のエージェントにそれを伝え、軌道修正できるようにしました。私たちのステアリングファイルでは、 agent-browser CLI を使った自動テストで Web UI を操作し、検証用のスクリーンショットを撮ることを必須にしています。 エージェントは変更をプッシュし、私たちが好む記述スタイルでプルリクエストを作成しました。その後、レビューの指摘にループで対応しながら PR を更新しました。関連する変更がマージされるとブランチをリベースしてマージコンフリクトを解消し、設計に影響する変更、スコープを広げる変更、ユーザー体験を変える変更については私たちに確認しました。 私たちのエージェントは、Kiro の 1 セッションで数十個の workflow を管理することがよくあります。典型的な workflow はカスタムエージェントを使った 5〜10 ステップで構成され、マルチモデルのコードレビューと、ループでの自動修正が含まれます。数週間続くセッションもあり、機能や改善を重ねるにつれて、私たちの決定事項に関するコンテキストが蓄積されていきます。チーム全体では、workflows はほぼ 24 時間 365 日稼働しています。 workflows は私たちの働き方を変えました。各セッション内で並列に実行される作業が増え、エージェントがバックグラウンドで調査を進め、複数の PR にわたって機能を構築します。タスクはより非同期になり、10 分ごとに私たちがプロンプトを送って先へ進めなくても、エージェントが長時間作業を続けます。Kiro は私たちの判断が必要な依頼だけを持ってくるので、私たちは設計上の判断や次に何を作るかにより多くの時間を使えるようになりました。 workflow の中身 次に示すのは、変更を計画し、実装と並列レビューを承認されるまで繰り返し、最後にドラフトのプルリクエストを作成する workflow の短い例です。これはグラフとして表現できます。 同じ workflow を次のレシピで記述できます。 { "name": "deliver-change", "inputs": { "task": "prompt", "workdir": "string" }, "steps": [ { "type": "step", "id": "plan", "agent": "wf-planner", "prompt": "Read the code relevant to {{task}} in {{workdir}} and write an ordered implementation plan to {{workdir}}/plan.md.", "artifacts": { "plan": "{{workdir}}/plan.md" } }, { "type": "repeat", "id": "code-loop", "maxIterations": 3, "onMaxIterations": "abort", "stopCondition": { "fileCheck": { "path": "{{workdir}}/review/verdict.json", "jsonPath": "verdict", "value": "APPROVED" } }, "steps": [ { "type": "step", "id": "implement", "agent": "wf-coder", "prompt": "Implement {{task}} in {{workdir}} following {{artifacts.plan}}. If {{workdir}}/review/verdict.json says CHANGES_REQUESTED, fix every finding in it first. Run the tests and commit." }, { "type": "parallel", "id": "reviews", "joinPolicy": "all", "branches": [ { "type": "step", "id": "review-a", "agent": "semantic_reviewer", "prompt": "Review the change in {{workdir}}. Write your review to {{workdir}}/review/a.md. Do not read the other reviewer's file.", "artifacts": { "review_a": "{{workdir}}/review/a.md" } }, { "type": "step", "id": "review-b", "agent": "semantic_reviewer", "prompt": "Review the change in {{workdir}}. Write your review to {{workdir}}/review/b.md. Do not read the other reviewer's file.", "artifacts": { "review_b": "{{workdir}}/review/b.md" } } ] }, { "type": "step", "id": "aggregate", "agent": "wf-review-aggregator", "prompt": "Read {{artifacts.review_a}} and {{artifacts.review_b}}. Dedupe the findings, then write the verdict to {{workdir}}/review/verdict.json as {\"verdict\": \"APPROVED\" | \"CHANGES_REQUESTED\"}." } ] }, { "type": "step", "id": "draft-pr", "agent": "wf-pr-submitter", "prompt": "Open a draft pull request for the change in {{workdir}}. Base the description on {{artifacts.plan}}." } ] } 各 step は独立したエージェントセッションとして実行されます。依存関係は、必要とする作業の後にステップを置き、その出力を {{...}} 変数で参照することで定義します。グラフのエッジを別途管理する必要はありません。 parallel ノードは独立したステップを同時に実行し、 repeat はレビューの承認などの停止条件を満たすまでステップをループします。workflow を作る最も簡単な方法は、Kiro に頼むことです。 Kiro はレシピを JSON で生成しますが、YAML にも対応しています。 モデル駆動の workflows セッションで説明したタスクは Kiro が分解するので、レシピを書く必要はありません。カスタムエージェント、使いたいモデル、思考の effort レベルなど、作業の組み立て方を指定することもできます。 Kiro は、エージェントが見つけた内容に応じて実行中の workflow を調整できます。たとえば、プランナーが実装を独立したタスクに分割し、並列で動くコーディングエージェントにそれぞれを委任できます。変更はステップの合間に反映されるため、完了した作業はそのまま残り、実行中のステップも変わりません。 同梱の workflow の例 より複雑な例として、同梱の feature-pipeline レシピは、要件の収集、ソリューションの設計とレビュー、実装計画の作成、コードの記述をエージェントに分担させます。その後、独立したコードレビュアーが並列に実行されます。 次のツリーでは、設計ループとコードループがそれぞれ承認を得るまで最大 3 回試行し、それでも承認されなければ実行を停止します。最後の検証では、結果を元の要件と照らし合わせます。 この例は Claude Opus 5 を High effort で使うセッションから起動しています。設計とレビューのエージェントは Extra high を使うようにカスタマイズしています。以下ではモデルと effort の上書き設定のみを示し、省略した設定はセッションのデフォルトを使います。 repeat の下にネストされた行はそのループ本体を構成し、parallel の下にネストされた行は同時に実行されます。トップレベルの行は順番に実行されます。 私たちは Kiro の開発で数千回の workflow を実行してきました。Kiro には組み込みのレシピが同梱されており、その中でも investigate と publish-pr は私たち自身が毎日使っているものです。 investigate は単一エージェントによる読み取り専用の調査をバックグラウンドで実行して結果を報告するので、セッションのコンテキスト使用量を抑えられます。 publish-pr レシピはプルリクエストを作成し、マージまで追跡します。失敗した CI チェックを再試行し、安全に解決できるレビューのフィードバックには対応します。設計を変える、PR のスコープを広げる、ユーザー体験を変えるといった場合は、事前に確認を求めます。これらのレシピは出発点です。そのまま実行することも、タスクを説明して Kiro に workflow を組み立てさせることも、自分で書くこともできます。 セッション間のメッセージング workflow のステップは、進捗の報告、完了や失敗の通知、自分では判断できない決定の依頼のために、メインセッションへメッセージを送ります。こうしたメッセージは Kiro とすでに進めている会話に届くので、各ステップのセッションを開いて確認しなくても、1 か所で作業を追えます。 メッセージングは逆方向にも機能します。メインセッションは、チャットで下した決定をステップを実行中のエージェントにメッセージで伝えられます。ステップの質問への答えがすでに会話の中にある場合は、メインセッションがあなたの代わりに返信するので、ステップは作業を続け、あなたは本当に自分の判断が必要な質問だけを受け取ります。これにより、メインの会話から作業を進めながら、workflows をより自律的に実行できます。 はじめ方 workflows は Kiro IDE、CLI、Web で利用可能になりました。3 つすべての下で 1 つのランタイム が動いているので、どこから起動してもレシピは同じように動作します。 workflows はオプトインで提供を開始しているため、まず設定で有効にする必要があります。 IDE プロジェクトの Workspace Configuration を開きます。 Workflows を選択します。 Workflows を有効にします。 新しいチャットセッションを開始します。すでに開いているセッションに変更を反映するには、Kiro を再起動してください。 対応する設定は kiroAgent.workflows.enabled です。Workflows が表示されない場合は、まだお使いのアカウントでは利用できません。 CLI /settings を実行します。 Features を選択します。 Workflows を有効にします。 Kiro CLI を再起動すると、workflow のコマンドが使えるようになります。 この設定は chat.enableWorkflows として保存されます。Workflows が表示されない場合は、まだお使いのアカウントでは利用できません。 Web Kiro Web で Settings を開きます。 Workflows を選択します。 Enable workflows をオンにします。オフにすると Workflow 関連の画面が非表示になり、新しい起動ができなくなります。 任意: Upload workflow を選択して、レシピを 1 つアップロードします。 .kiro/workflows/ フォルダ全体をインポートするには、 Configuration Sync を使います。 Web では .workflow.json 、 .workflow.yaml 、 .workflow.yml のレシピファイルを受け付けます。 よく使うレシピを Kiro Web の クラウド構成 に保存しておけば、プロジェクトやデバイスをまたいで再利用できます。workflows は Kiro CLI と IDE からの クラウドセッション でも実行できます。クラウドセッションで workflows を有効にし、保存した workflow を管理するには、 workflows の設定ページ を使います。 workflows には、他のエージェント作業と同じ Kiro のクレジットモデルが適用されます。クレジットの使用量は実行するエージェント作業によって決まるため、複雑な workflow ほど多くのクレジットを使う場合があります。特に指示がなければ、Kiro はタスクに必要と判断した内容に基づいて workflow を作成します。プロンプトやステアリングファイルで、Kiro が作業をどう分割し、どの程度レビューを行うかを指示できます。 詳しくは Workflows のドキュメント をご覧ください。 workflows で作ったものをぜひ教えてください。 本記事は 2026 年 9 月 30 日に公開された Introducing Kiro workflows を翻訳したものです。

本記事は 2026 年 9 月 30 日 に公開された「 Amazon Aurora PostgreSQL now supports direct querying of Apache Iceberg and Parquet data in your data lake 」を翻訳したものです。 本日、 Amazon Aurora PostgreSQL の新機能を発表します。既存の PostgreSQL アプリケーションやツールを使って、運用データと、データレイクに Apache Iceberg および Apache Parquet 形式で保存されたデータを組み合わせて直接クエリできるようになりました。データレイクの構造化データを運用データベースに ETL (抽出、変換、ロード) する必要がなくなるため、運用の複雑さを軽減し、アプリケーション開発をシンプルにできます。また、Iceberg REST Catalog (IRC) 互換カタログで管理されているデータレイクのデータも Aurora PostgreSQL からクエリでき、データを移動したり複製したりすることなく、幅広い分析システムのデータにアクセスできます。リアルタイムダッシュボードの提供、過去の履歴情報によるトランザクションデータの補完、ライブデータとアーカイブデータの両方をもとに推論する AI エージェントの構築など、いずれも 1 つの使い慣れたインターフェースから実現できます。 従来、Aurora 上の最新のトランザクションデータと Amazon S3 に保存された過去のレコードをアプリケーションで組み合わせるには、リバース ETL パイプラインを構築するのが一般的でした。リバース ETL パイプラインではデータが重複し、インフラストラクチャコストが増え、すべてを同期させ続けるための継続的なエンジニアリング作業が必要でした。アプリケーションに AI エージェントを組み込む場面が増えるほど、エージェントが必要とする可能性のあるデータセットをすべて事前に予測して複製しておくことは現実的でなくなり、課題はさらに大きくなります。 DuckDB プロジェクトをメンテナンスする DuckLabs のチームが最近 Amazon に加わりました。今回の機能は、DuckDB の効率性を AWS のサービスに統合していく取り組みの一例です。DuckDB が Aurora PostgreSQL に直接組み込まれたことで、ライブの運用データ (コミットされていない書き込みを含む) とデータレイクのデータを 1 つのクエリで横断的にクエリできます。クエリ処理は Aurora 内で完結し、追加のネットワークホップも、データを複製する ETL パイプラインも不要です。AWS Glue Data Catalog で管理されている Apache Iceberg テーブルに加えて、Amazon S3 や S3 Tables に保存されている Parquet および Iceberg データをクエリできます。これらはすべて、使い慣れた PostgreSQL 構文と既存のアプリケーション、ツールで実行できます。 DuckDB の速さとシンプルさを Aurora PostgreSQL に直接取り込むことで、お客様もお客様のエージェントも、既に利用している PostgreSQL アプリケーション、ツール、エンドポイントから運用データと Iceberg データを組み合わせてクエリできます。今回の機能を DuckDB を軸に構築したことで、オープンソースエンジン側の今後の改善が、Aurora やその他の AWS サービスのパフォーマンスと機能の向上に引き続きつながります。 新機能 今回の機能は、Aurora PostgreSQL の 2 つのメジャーバージョン、17 (17.11 以降) と 18 (18.6 以降) でサポートされています。使用するには、Aurora PostgreSQL クラスターを作成し、 AuroraAnalytics 機能用の IAM ロールをアタッチして、 aurora_analytics 拡張機能を有効にします。この IAM ロールによって、Aurora が Amazon S3 と AWS Glue Data Catalog 上のデータにアクセスできるようになります。その後、データレイク内の Iceberg または Parquet データを参照する外部テーブルを作成し、使い慣れた PostgreSQL 構文でクエリします。この設定は Amazon RDS コンソール から、または psql などの任意の PostgreSQL クライアントで実行できます。手順の詳細は Aurora PostgreSQL のドキュメント に記載されています。 AWS Glue Data Catalog のフェデレーションを通じて、外部の IRC 互換カタログのデータもクエリできます。外部カタログを一度 Glue に登録すれば、あとは Glue ネイティブのテーブルと同じ手順で、クエリしたいテーブルに対応する外部テーブルを作成するだけです。1 つのクエリで Aurora に保存されたデータと複数のカタログに登録された Iceberg テーブルを結合できるため、データを移動したり既存のカタログ資産を置き換えたりせずに、アプリケーションから統合されたビューを得られます。 Aurora は述語プッシュダウンやカラムプルーニングといった最適化も適用するため、必要なデータだけが読み取られます。対象データが増えてもクエリの効率は維持されます。頻繁にアクセスされるデータは Aurora インスタンスにキャッシュされるため、同じデータに対する後続のクエリはより速く返されます。クエリごとの動作は aurora_analytics_stat_statements() で確認でき、スキャンした行数、Amazon S3 から読み取ったバイト数、キャッシュヒット数などのメトリクスが報告されます。 直接クエリの動作を確認するため、psql で Aurora PostgreSQL データベースに接続して拡張機能を作成しました。 CREATE EXTENSION aurora_analytics; 今回のウォークスルーでは、シンプルな金融シナリオを用意しました。Aurora には直近 7 日間の顧客トランザクションを格納した recent_transactions テーブルがあり、Amazon S3 には 5 年分の過去のトランザクションデータを含む Parquet ファイルがあります。Aurora から過去データを参照できるようにするため、S3 の Parquet ファイルを指す外部テーブルを作成しました。 CREATE FOREIGN TABLE transaction_history () SERVER aurora_analytics_server OPTIONS ( location 's3://<my-bucket>/finance/transaction_history.parquet', format 'parquet' ); CREATE FOREIGN TABLE 文の括弧が空になっている点に注目してください。Aurora は Parquet ファイルのメタデータからスキーマを自動的に読み取るため、カラムを手動で定義する必要はありません。テーブルが多数あるワークロードでは、1 つずつ作成する代わりに、 IMPORT FOREIGN SCHEMA 文 1 つで AWS Glue Data Catalog のデータベースに含まれるすべての Iceberg または Parquet テーブルに対応する外部テーブルを一括で作成でき、スキーマも自動で推論されます。 両方のテーブルが揃ったところで、Aurora 内の最新の運用データと S3 の過去データを組み合わせる 1 つのクエリを実行しました。 SELECT merchant, category, amount, transaction_date, 'recent' AS source FROM recent_transactions WHERE customer_id = 'C-1001' UNION ALL SELECT merchant, category, amount, transaction_date, 'historical' AS source FROM transaction_history WHERE customer_id = 'C-1001' AND transaction_date >= CURRENT_DATE - INTERVAL '5 years' ORDER BY transaction_date DESC LIMIT 15; 結果には、最新のトランザクションと過去のトランザクションが 1 つの結果セットとして表示されています。直近の 7 行は Aurora から、残りは S3 の Parquet ファイルから直接取得されたものです。内部では DuckDB が Parquet データの分析スキャンを担い、Aurora が運用データを処理しています。従来であれば、この 1 つのクエリを実行するために、まず過去データをデータベースに移動するパイプラインが必要でした。 1 桁ミリ秒のレイテンシーが求められるクエリパターンでは、 CREATE TABLE AS SELECT 、 INSERT INTO ... SELECT 、 MERGE INTO などの使い慣れたコマンドで、データレイクのデータをネイティブの Aurora PostgreSQL テーブルにマテリアライズできます。マテリアライズされたテーブルは Aurora 内に存在し、他の PostgreSQL テーブルと同様にクエリできるため、別途取り込みパイプラインを運用することなく、ホットデータへ低レイテンシーでアクセスする経路を確保できます。読み取りクエリは、ライターでもリードレプリカでも、クラスター内のどの Aurora PostgreSQL インスタンスでも実行できるため、分析スキャンを運用ワークロードからオフロードできます。マテリアライズ用のコマンドは Aurora にデータを書き込むため、ライターインスタンスで実行します。 今すぐ始めましょう Amazon Aurora PostgreSQL からの Apache Iceberg および Parquet データの直接クエリは、すべての商用 AWS リージョンと AWS GovCloud (US) リージョンで本日から追加料金なしで利用できます。課金されるのは、クエリが消費する Aurora コンピューティングの増分と、データレイクファイルの読み取りにかかる Amazon S3 のリクエスト料金 のみです。 詳細は、 Amazon Aurora の機能ページ を参照するか、 Aurora PostgreSQL のドキュメント をお読みいただくか、 Amazon RDS コンソール でお試しください。フィードバックは AWS re:Post または通常の AWS サポート窓口からお寄せください。 — Esra 著者について Esra Kayabali AWS のプリンシパルソリューションアーキテクトで、データウェアハウス、データレイク、ビッグデータ分析、バッチおよびリアルタイムのデータストリーミング、データ統合を含む分析分野を専門としています。ソフトウェア開発とソリューションアーキテクチャの分野で 10 年以上の経験を持ち、共同学習や知識共有、コミュニティのクラウド技術活用の支援に情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。