2025 年 12 月 2 日、 Amazon Nova 2 Lite をリリースしました。これは、日常のワークロードに対応する高速で費用対効果の高い推論モデルです。 Amazon Bedrock で利用できるこのモデルは、業界トップクラスの価格パフォーマンスを提供し、企業や開発者が高性能で信頼性が高く効率的なエージェンティック AI アプリケーションを構築するのに役立ちます。自社の領域を真に理解する AI を必要とする組織にとって、Nova 2 Liteは Nova Forge と併用 して独自のフロンティアインテリジェンスを構築するのに最適なモデルです。 Nova 2 Lite は、応答したり行動を起こしたりする前に、段階的な推論やタスクの分解など、拡張的な思考をサポートします。拡張思考 (Extended Thinking) は初期設定ではオフになっていますが、より詳細な分析が必要な場合は、これをオンにして、「低」、「中」、「高」の 3 つの思考予算レベルから選択して、スピード、インテリジェンス、コストのトレードオフを制御できます。 Nova 2 Lite は、テキスト、画像、ビデオ、ドキュメントを入力としてサポートし、100 万トークンのコンテキストウィンドウを提供することで、推論の幅を広げ、より豊かなコンテキスト学習を可能にします。さらに、Nova 2 Lite は特定のビジネスニーズに合わせてカスタマイズできます。このモデルには、ウェブグラウンディングとコードインタープリターという 2 つの組み込みツールへのアクセスも含まれています。ウェブグラウンディングは引用を含む公開情報を取得し、コードインタープリターはモデルが同じワークフロー内でコードを実行して評価できるようにします。 Amazon Nova 2 Lite は、さまざまな評価ベンチマークで優れたパフォーマンスを示しています。このモデルは、時間的推論による指示の追従や数学、動画の理解など、複数の領域にわたるコアインテリジェンスの点で優れています。エージェント型ワークフローの場合、Nova 2 Lite はタスクの自動化と正確な UI インタラクション機能を呼び出す信頼性の高い機能を備えています。このモデルは、強力なコード生成能力と実践的なソフトウェアエンジニアリング問題解決能力も示しています。 Nova 2 Lite は貴社のニーズを満たすように構築されています Nova 2 Lite は日常の幅広い AI タスクに使用できます。価格、パフォーマンス、速度の最適な組み合わせを提供します。初期の顧客は、カスタマーサービスのチャットボット、文書処理、ビジネスプロセスの自動化に Nova 2 Lite を使用しています。 Nova 2 Lite は、さまざまなユースケースのワークロードをサポートするのに役立ちます。 ビジネスアプリケーション — ビジネスプロセスワークフロー、インテリジェントドキュメント処理 (IDP)、カスタマーサポート、ウェブ検索を自動化して、生産性と成果を向上させます ソフトウェアエンジニアリング — コードの生成、デバッグ、リファクタリング、およびシステムの移行により、開発を加速し、効率を高めます ビジネスインテリジェンスとリサーチ — 長期的な推論とウェブグラウンディングを活用して社内外の情報源を分析し、インサイトを導き出し、情報に基づいた意思決定を行います。 特定の要件については、Nova 2 Lite を Amazon Bedrock と Amazon SageMaker AI の両方でカスタマイズすることもできます。 Amazon Nova 2 Lite の使用 Amazon Bedrock コンソール では、 チャット/テキストプレイグラウンド を使用して、プロンプトを使用して新しいモデルをすばやくテストできます。モデルをアプリケーションに統合するには、Amazon Bedrock InvokeModel と Converse API を備えた任意の AWS SDK を使用できます。 AWS SDK for Python (Boto3) を使用した呼び出しのサンプルを次に示します。 import boto3 AWS_REGION="us-east-1" MODEL_ID="global.amazon.nova-2-lite-v1:0" MAX_REASONING_EFFORT="low" # low, medium, high bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) # 複雑な問題解決のための拡張思考を有効化 response = bedrock_runtime.converse( modelId=MODEL_ID, messages=[{ "role": "user", "content": [{"text": "5 つの倉庫、12 の配送センター、200 の小売店舗からなる物流ネットワークを最適化する必要があります。目標は、配送センターから 50 マイル以上離れていない場所がないようにしながら、総輸送コストを最小限に抑えることです。どのようなアプローチを取るべきか?"}] }], additionalModelRequestFields={ "reasoningConfig": { "type": "enabled", # enabled, disabled (default) "maxReasoningEffort": MAX_REASONING_EFFORT } } ) # 応答には推論ブロックが含まれ、その後に最終回答が続きます for block in response["output"]["message"]["content"]: if "reasoningContent" in block: reasoning_text = block["reasoningContent"]["reasoningText"]["text"] print(f"Nova's thinking process:\n{reasoning_text}\n") elif "text" in block: print(f"Final recommendation:\n{block['text']}") また、これらのモデルは、Amazon Bedrock をサポートする任意のエージェンティックフレームワークで使用でき、 Amazon Bedrock AgentCore を利用してエージェントをデプロイできます。この方法では、幅広いタスクに対応するエージェントを構築できます。 Strands Agents SDK を使用したインタラクティブなマルチエージェントシステムのサンプルコードは次のとおりです。エージェントは、ファイルの読み取り/書き込みアクセスやシェルコマンドの実行など、複数のツールにアクセスできます。 from strands import Agent from strands.models import BedrockModel from strands_tools import calculator, editor, file_read, file_write, shell, http_request, graph, swarm, use_agent, think AWS_REGION="us-east-1" MODEL_ID="global.amazon.nova-2-lite-v1:0" MAX_REASONING_EFFORT="low" # low, medium, high SYSTEM_PROMPT = ( "You are a helpful assistant. " "ユーザーからの指示に従ってください。" "タスクを支援するために、専用のエージェントを動的に作成し、複雑なワークフローを調整できます。" ) bedrock_model = BedrockModel( region_name=AWS_REGION, model_id=MODEL_ID, additional_request_fields={ "reasoningConfig": { "type": "enabled", # enabled, disabled (default) "maxReasoningEffort": MAX_REASONING_EFFORT } } ) agent = Agent( model=bedrock_model, system_prompt=SYSTEM_PROMPT, tools=[calculator, editor, file_read, file_write, shell, http_request, graph, swarm, use_agent, think] ) while True: try: prompt = input("\nEnter your question (or 'quit' to exit): ").strip() if prompt.lower() in ['quit', 'exit', 'q']: break if len(prompt) > 0: agent(prompt) except KeyboardInterrupt: break except EOFError: break print("\nGoodbye!") 知っておくべきこと Amazon Nova 2 Lite は、複数のロケーションでのグローバルな クロスリージョン推論 により Amazon Bedrock で利用できるようになりました。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 Nova 2 Lite には、 責任ある AI の使用を促進するための安全コントロールが組み込まれており、幅広いアプリケーションで適切な出力を維持するのに役立つコンテンツモデレーションも備わっています。 費用については、 Amazon Bedrock の料金表 をご覧ください。詳細については、「 Amazon Nova ユーザーガイド 」をご覧ください。 今すぐ Nova 2 Lite で構築を開始しましょう。新しいモデルを試すには、 Amazon Novaインタラクティブウェブサイト にアクセスしてください。 Amazon Bedrock コンソール でモデルを試し、 AWS re:Post でフィードバックを共有 してください。 – Danilo 原文は こちら です。

2025 年 12 月 2 日、 AWS Security Hub が一般公開され、セキュリティチームが AWS 環境全体で重大なセキュリティリスクを特定して対応する方法が変わりました。これらの新機能は、 AWS re:Inforce 2025 の プレビュー で初めて発表されました。Security Hub は、お客様の重大なセキュリティ問題に優先順位を付け、セキュリティ運用を統合して、複数の AWS セキュリティサービスにわたるシグナルを相互に関連付けて強化することで、大規模な対応を支援します。Security Hub は、ほぼリアルタイムのリスク分析、トレンド、統合支援、合理化された価格設定、およびセキュリティシグナルを実用的なインサイトに変換する自動相関を提供します。 複数のセキュリティツールを導入している組織は、さまざまなコンソール間でシグナルを手動で相関させる必要があり、運用上のオーバーヘッドが発生し、検出と応答の時間が遅れる可能性があります。セキュリティチームは、脅威検出、脆弱性管理、セキュリティ体制のモニタリング、機密データの発見にさまざまなツールを使用していますが、これらのツールが生成する検出結果から価値を引き出すには、関係を理解して優先順位を決定するための多大な労力を手動で行う必要があります。 Security Hub は、クラウドセキュリティ運用を統合する組み込み統合によってこれらの課題に対処します。Security Hub は、個々のアカウントまたは AWS Organizations アカウント全体で利用でき、 Amazon GuardDuty 、 Amazon Inspector 、 AWS Secutiry Hub クラウドセキュリティ体制管理 (AWS Security Hub CSPM) 、および Amazon Macie からのシグナルを自動的に集計して相関させ、脅威、暴露、リソース、セキュリティカバレッジ別に整理します。この統一されたアプローチにより、手作業による関連付け作業が減り、重大な問題を迅速に特定し、補償範囲のギャップを理解し、重大度と影響に基づいて修正の優先順位を付けることができます。 一般提供の新着情報 プレビューの発表以降、Security Hub にはいくつかの新機能が追加されています。 歴史的傾向 Security Hub には、 概要 ダッシュボードのトレンド機能が含まれており、組織全体の検出結果やリソースに関する最大 1 年間の履歴データが表示されます。概要ダッシュボードには、運用上のニーズに基づいて追加、削除、調整できるカスタマイズ可能なウィジェットを通じて、リスク範囲、脅威、リソース、およびセキュリティカバレッジの概要が表示されます。 ダッシュボードには、前日比、前週比、前月比の比較を示す トレンド概要 ウィジェットが含まれており、セキュリティ体制が改善しているのか低下しているのかを追跡するのに役立ちます。 アクティブ脅威検出結果 、 アクティブエクスポージャー結果 、 リソーストレンド のトレンドウィジェットは、5 日間、30 日、90 日、6 か月、1 年などの選択可能な期間の平均数を視覚化します。これらの視覚化を、クリティカル、高、中、低などの重大度レベルでフィルタリングし、特定の時点にカーソルを合わせると詳細なカウントを確認できます。 概要 ダッシュボードには、現在のリスクの概要を重大度順に並べて表示するウィジェット、悪意のあるアクティビティまたは疑わしいアクティビティを示す脅威概要、タイプ別および関連する検出結果別に整理されたリソースインベントリを表示するウィジェットも含まれています。 セキュリティカバレッジ ウィジェットは、組織全体のセキュリティサービスデプロイにおけるギャップを特定するのに役立ちます。このウィジェットは、どの AWS アカウントとリージョンでセキュリティサービスが有効になっているかを追跡し、脅威、脆弱性、設定ミス、機密データを可視化できない場所を特定するのに役立ちます。このウィジェットには、Amazon Inspector による脆弱性管理、GuardDuty による脅威検出、Amazon Macie による機密データ検出、AWS Security Hub CSPM による体制管理など、さまざまなセキュリティ機能のアカウントカバレッジが表示されます。カバレッジパーセンテージは、Security Hub が有効になっている AWS アカウントとリージョン全体で、どのセキュリティチェックに合格または不合格になったかを示します。 すべてのウィジェットに適用される共有フィルターを使用してウィジェットにフィルターを適用したり、エクスポージャーデータや脅威データのフィルターを検索したり、インベントリデータのリソースフィルターを適用したりできます。and/or 演算子を使用してフィルターセットを作成して保存し、セキュリティ分析の特定の基準を定義できます。保存されたフィルターセットやウィジェットレイアウトを含むダッシュボードのカスタマイズは自動的に保存され、セッションをまたいで保持されます。 クロスリージョン集約を設定すると、 概要 ダッシュボードにホームリージョンから表示すると、リンクされたすべてのリージョンの検出結果が表示されます。AWS Organizations の委任管理者アカウントの場合、データには管理者アカウントとメンバーアカウントの両方の検出結果が含まれます。Security Hub は、検出結果が生成された日から 1 年間トレンドデータを保持します。1 年後、トレンドデータは自動的に削除されます。 ほぼリアルタイムのリスク分析 Security Hub はほぼリアルタイムでリスクを計算し、既存の脆弱性や設定ミスの分析に加えて、GuardDuty からの脅威の相関関係を含めるようになりました。GuardDuty が脅威を検出したり、Amazon Inspector が脆弱性を特定したり、AWS Security Hub CSPM が設定ミスを検出したりすると、Security Hub はこれらの検出結果を自動的に関連付け、関連するリスクエクスポージャーを更新します。この進歩により、セキュリティ体制に関するフィードバックが即座に得られるため、新たなリスクを迅速に特定し、是正措置によって予想どおりにリスクが軽減されたことを確認できます。 Secutiry Hub は、AWS Security Hub CSPM、Amazon Inspector、Amazon Macie、Amazon GuardDuty、およびその他のセキュリティサービスにわたる検出結果を相互に関連付け、セキュリティインシデントにつながる可能性のあるリスクを特定します。この相関関係は、複数のセキュリティ問題が組み合わさって重大なリスクが生じる場合を理解するのに役立ちます。Security Hub は、リソースの関連性、潜在的な影響、シグナル間の関係を分析することで、セキュリティシグナルにコンテキストを付加します。たとえば、Security Hub が、バージョニングが無効で、Object Lockが無効で、MFA 削除が無効になっている機密データを含む Amazon Simple Storage Service (Amazon S3) バケットを特定した場合、いずれかのコンポーネントを修正すると自動計算がトリガーされ、スケジュールされた評価を待たずに修正の有効性を検証できます。 [エクスポージャー] ページでは、検出結果がタイトルと重大度別に整理されているため、重要な問題に最初に焦点を当てることができます。このページには、過去 90 日間のエクスポージャー検出結果の平均数を重大度別に表示する傾向グラフを含む [概要] セクションがあります。この視覚化は、時間の経過に伴うリスク状況の変化を追跡し、セキュリティリスクのパターンを特定するのに役立ちます。 エクスポージャー検出結果はタイトルごとにグループ化され、展開可能な行には影響を受けたリソースの数と全体的な重大度が表示されます。各エクスポージャーのタイトルには、「Potential Data Destruction: S3 bucket with versioning, Object Lock, and MFA delete disabled (データ破壊の可能性: バージョニング、Object Lock、MFA 削除が無効になっている S3 バケット)」や「Potential Remote Execution: EC2 instance is reachable from VPC and has software vulnerabilities (リモート実行の可能性: EC2 インスタンスは VPC からアクセス可能で、ソフトウェアの脆弱性がある)」など、潜在的なセキュリティ上の影響について説明しています。 保存済みのフィルターセットまたはクイックフィルターを使用して、クリティカル、高、中、低などの重大度レベルに基づいてエクスポージャーをフィルタリングできます。このインターフェイスでは、アカウント ID、リソースタイプ、およびアカウントによるフィルタリングも可能なため、インフラストラクチャの特定の部分に関連するリスクをすばやく絞り込むことができます。 Security Hub は、検出結果が出るとすぐにエクスポージャーを生成します。たとえば、パブリックにアクセス可能な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをデプロイし、Amazon Inspector が悪用されやすい脆弱性を検出したときに、AWS Security Hub CSPM がパブリックアクセシビリティの設定を識別している間に、Secutiry Hub はこれらの検出結果を自動的に相互に関連付けてリスクを発生させ、予定された評価を待たずにリスクを発生させます。このほぼリアルタイムの相関関係により、新たに導入されたリソースにおける重大なリスクを特定し、悪用される前に対策を講じることができます。 エクスポージャー検出結果を選択すると、詳細ページにエクスポージャータイプ、プライマリリソース、地域、アカウント、年齢、作成時間が表示されます。 [概要] セクションには、リスクにさらされるシナリオに直接影響するセキュリティ問題を表す原因となる特性が表示されます。これらの特性は、「 到達可能性 」、「 脆弱性 」、「 機密データ 」、「 設定ミス 」、「 想定可能性 」などのカテゴリー別に整理されています。 詳細ページには [潜在的な攻撃パス] タブがあり、潜在的な攻撃者がどのようにリソースにアクセスして制御できるかを視覚的に示すグラフが表示されます。この視覚化には、プライマリリソース (EC2 インスタンスなど)、関連するリソース (VPC、サブネット、ネットワークインターフェイス、セキュリティグループ、 AWS Identity and Access Management (IAM) インスタンスプロファイル、IAM ロール、IAM ポリシー、ボリュームなど)、および寄与する特性間の関係が表示されます。このグラフは、アタックサーフェス全体を把握し、調整が必要なセキュリティコントロールを特定するのに役立ちます。 [特性] タブには、リスクにさらされる原因となっているすべてのセキュリティ問題が一覧表示され、 [リソース] タブには影響を受けるすべてのリソースが表示されます。 [修復] セクションでは、優先順位付けされたガイダンスとドキュメントへのリンクが提供され、リスクを最も効果的に軽減するために最初に対処すべき特性が推奨されます。この包括的なビューを使用することで、チームが環境全体の脆弱性、構成ミス、その他のセキュリティギャップに対処する際に、特定のリスクを調査し、セキュリティリスクの全体像を把握し、修正の進捗状況を追跡できます。 パートナー統合の拡大 Secutiry Hub は、インシデント管理ワークフローのために Jira および ServiceNow との統合をサポートしています。結果を表示する場合、 AWS Security Hub コンソール から任意のシステムでチケットを直接作成できます。チケットには、検出結果の詳細、重大度、推奨修復手順が自動的に入力されます。Security Hub では、重大度レベル、リソースタイプ、検出結果タイプなど、指定した条件に基づいてアトラシアンの Jira Service Management と ServiceNow でチケットを自動的に作成する 自動化ルール を定義することもできます。これにより、人手を介さずに重大なセキュリティ問題をインシデント対応チームに振り分けることができます。 Security Hub の検出結果は、セキュリティツールがデータをシームレスに共有できるようにするオープンソース標準である Open Cybersecurity Schema Framework (OCSF) スキーマでフォーマットされています。Secutiry Hub で OCSF 形式との統合を構築したパートナーには、Cribl、CrowdStrike、DataDog、Dynatrace、Expel、Graylog、Netskope、Securonix、SentinelOne、Cisco 傘下の Splunk、Sumo Logic、Tines、Upwind Security、Varonis、DTEX、Zscaler などがあります。さらに、Accenture、Caylent、Deloitte、Optiv、PwC、Wipro などのサービスパートナーが、Secutiry Hubと OCSF スキーマの導入を支援できます。 Secutiry Hub は、 Amazon EventBridge による自動応答ワークフローもサポートしています。指定した基準に基づいて検出結果を識別する EventBridge ルール を作成し、それらを AWS Lambda 関数 や AWS Systems Manager Automation ランブックなどのターゲットにルーティングして処理と修正を行うことができます。これにより、手動で操作しなくてもプログラム的に検出結果に基づいて行動できます。 今すぐご利用いただけます 現在 AWS Secutiry Hub CSPM、Amazon GuardDuty、Amazon Inspector、または Amazon Macie を使用している場合は、 AWS Security Hubコンソール に移動することでこれらの機能にアクセスできます。新規のお客様は、 AWS マネジメントコンソール から Security Hub を有効にし、ワークロードに適したセキュリティサービスを設定できます。Security Hub は、有効になっているサービスからの検出結果を自動的に利用して、統合コンソールで確認できるようにし、取り込まれたセキュリティデータに基づいて相関関係のあるエクスポージャー検出結果を作成します。 リージョンの提供状況については、 リージョン別の AWS サービス のページをご覧ください。ほぼリアルタイムのエクスポージャー計算とトレンド機能は追加料金なしで含まれています。Security Hub は、合理化されたリソースベースの価格モデルを使用しており、統合された AWS セキュリティサービス全体の料金を統合しています。コンソールには、デプロイ前に AWS アカウントとリージョン全体のセキュリティ投資を計画および予測するのに役立つコスト見積もりツールが含まれています。機能、サポートされている統合、価格の詳細については、AWS Security Hub の 製品ページ と 技術文書 をご覧ください。 – Esra 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの田中豊洋です。月刊 AWS 製造の 12 月号をお届けします。先月号は こちら です。本号では、BMW 様、Bayer 様、Rio Tinto 様、三菱電機様の先進的な成功事例をはじめ、製造企業における AWS サービスの活用記事を纏めています。製造企業に有用な AWS サービスのアップデート情報も含め、最新のトレンドをご確認ください。 ピックアップトピック 12/1から5 にかけて、ラスベガスにて AWS re:Invent 2025 が開催されました。本年は、エージェントAIの強化と、様々なユースケースにおける活用例が示されました。EXPOでは生産工程ロボットの監視や問題の分析、AIを使った設計支援から3Dプリンターへの仮想工場といった展示を提供し、日本でのツアーも実施し、数多くのお客様に最新のユースケースをお伝えすることができました。パートナー、AWS からも Physical AIに関連した展示が登場しています。本年は、日本からも複数の展示やセッション登壇を行いました。来月の月刊 AWS製造でより詳細にお届けるする予定ですので、ぜひご期待ください。 re:Invent セッション動画は、こちらの AWS Events の Youtube チャネルから視聴いただけます。 https://www.youtube.com/@AWSEventsChannel 直近で開催予定のイベント 01/06 – 09 CES 2026 世界最大級のテクノロジー見本市である CES がラスベガスで開催されます。CES 2025 で AWS は、NVIDIA や Siemens などのパートナーとともに、自動運転や SDV 、デジタルツインなどのソリューション展示を行いました。AWS は今年も出展し、現地には日本人スタッフも常駐していますので、是非お立ち寄りください。 01/26 – 29 SCA/HPCAsia2026 HPC ( High Performance Computing ) 関連の国際カンファレンス 「 SCA/HPCAsia2026 」 が日本 ( 大阪 ) で初めて開催されます。AWS もブース出展しますので、大規模な CAE や EDA 環境の改善をご検討中の方や、R&D 部門などで HPC に関わる方、最新動向を掴みたい方は、是非お越しください。12 / 21 までに先行登録すると、参加費が割引になります。 登録ページは こちら です。 製造関連ブログのご紹介 11/03 AWS Professional Services and BMW collaborate to optimize petabyte-scale storage costs for automated driving data このブログは、BMW と AWS Professional Services が自動運転データのペタバイト規模ストレージコストを最適化した事例を紹介しています。自動運転開発では膨大なデータが生成され、1 台のテスト車両が 1 日に数十テラバイトのデータを生成するため、効率的なストレージ管理が課題となっていました。AWS は Amazon S3 の機能 ( S3 Storage Lens、S3 Intelligent-Tiering、S3 Server Access Logging ) を活用し、大幅なコスト削減を実現しました。 11/10 Implement Zero-Training Visual Defect Detection in Manufacturing with Amazon Nova Pro このブログでは、製造業における品質検査に Amazon Nova Pro を活用し、学習データ不要 ( ゼロトレーニング ) で外観検査を行う方法について紹介しています。AWS サービスと数行のプロンプトを記述する方法により、AI / ML の専門知識を必要とせず、従来型に匹敵する性能を実現しています。 Modernizing laboratory networks: How Bayer centralizes LIMS on AWS Cloud このブログは、グローバルに分散した拠点を持つ Bayer が、LIMS ( ラボ情報管理システム ) を AWS クラウド上に集約した事例を紹介しています。Bayer では、オンプレミスの通信ドメインを企業ネットワーク ( IT ) 、工場ネットワーク ( OT ) 、研究所ネットワークの 3 つに分離し、セキュリティとガバナンスに対応しています。そこで Bayer は各種規制要件や運用負担抑制を満たしつつ LIMS の集約に成功しました。 11/11 三菱電機グループエンジニアコミュニティの新たな地平 – MAWS-UG が生み出す実務への好循環と次世代への継承 このブログでは、三菱電機グループの AWS ユーザーコミュニティ「MAWS-UG」が、前回記事公開から1年間で単なる技術交流の場から組織変革を牽引するコミュニティへと進化した成果を紹介しています。社外コミュニティとの連携拡大、他の製造業企業との交流、実際のビジネスプロジェクトでの活用など、2025年1月の三菱電機と AWS の戦略的協業においても重要な役割を担うことになった軌跡を、メンバーの生の声とともに詳しく解説しています。 11/20 Transforming Smart Product Companies into Digital Service Leaders: A Data-Driven Marketing Architecture on AWS このブログは、スマート製品メーカーが AWS を活用してデジタルサービスリーダーへと変革する方法を解説しています。Gartner によると、2027 年までに AI モデルの 80% が業界特化型になると予測されています。AWS のサービスを利用した包括的なデータ駆動型アーキテクチャにより、継続的な顧客接点、予測保守機能、データ駆動型の製品革新サイクルを実現します。Siemens や Stanley Black & Decker などの成功事例も紹介されています。 11/21 Managing Sustainability Data for Digital Product Passports with Agentic AI 2024 年に EU で ESPR ( エコデザイン規制 ) が施行されました。これに伴い、2027 年から段階的に Digital Product Passport ( DPP ) の実装が義務化されます。このブログでは、DPP の実現におけるグローバルサプライヤーからのデータ収集・標準化、レガシーシステム統合、データ検証などの課題に対し、AI エージェントによる解決方法を解説しています。 11/25 Top-performing supply chains: When AI meets energy industry experience このブログでは、エネルギー業界のサプライチェーンにおいて、AI 活用によって変革するストーリーを紹介しています。製造業に通ずる部分が多く、Amazon SageMaker と Amazon Bedrock を中心とした AWS サービスを利活用することで、需要予測とスペアパーツ在庫の最適化提案、リスクシミュレーション、製品トレース機能によるコスト削減の価値を訴求しています。 イベント動画のご紹介 11/06 Reimagining Manufacturing: Clariant’s SAP RISE Journey with AWS 大手化学メーカーの Clariant が SAP with RISE を選んだ理由とその効果、IoT や AI の活用で可視化や予測機能の活用について述べています。 11/10 How to Modernize your Existing GenAI Manufacturing Solutions | How to build like AWS 空調機器製造大手の Carrier のコールセンターで、通話内容の自動要約システムを構築した事例です。オペレーターは手動で要約を書く負担から解放され、生産性が大きく向上しました。 11/13 Rio Tinto unlocks potential of generative AI 世界的な総合資源企業である Rio Tinto では、バリューチェーン全体で戦略的に AI を実装推進しています。同社の社内では、生成 AI に関する最大のリスクは回答精度の低さであると位置づけました。これに対し、ベクトル DB だけでなく、ドメイン知識を持たせたグラフ DB とのハイブリッド RAG で精度を大幅に向上させました。 製造関連の主要なアップデート 10/30 AWS IoT Greengrass のデベロッパー向け AI エージェントコンテキストパックが提供開始 AI エージェントに AWS IoT Greengrass 構築・開発方法を教え込むためのコンテキストパックが提供開始となりました。 11/11 AWS Parallel Computing Service (PCS) が Slurm CLI Filter プラグインのサポートを開始 一般的なスパコンや AWS PCS のような HPC ( High Performance Computing ) クラスタでは、ジョブスケジューラーとして Slurm が広く使われています。ユーザーは Slurm にジョブ実行を依頼することで、Slurm が計算リソースを確保し、ジョブの優先順位を確定させて処理を流します。今回の Slurm CLI Filter は、ジョブ制御に関する運用負担軽減と俊敏性向上に寄与します。 11/17 Deploying an MES in the AWS Cloud and at the edge on Outposts この記事では、製造実行システム ( MES ) である Siemens Opcenter Execution を AWS クラウドと AWS Outposts の両方に展開する方法を詳細に解説しています。高可用性と低レイテンシーを両立させる構成における考慮事項を説明しています。 11/24 AWS IoT Core now supports IoT thing registry data retrieval from IoT rules AWS IoT Core の IoT rule で、デバイス固有の情報を参照できるようになりました。これにより、例えば本番デバイスからの送信データとテストデバイスからの送信データを区別をノンコーディングで実装することが可能となりました。 11/25 Guidance for Physical AI for Robotics on AWS フィジカル AI のガイダンスが公開されました。Amazon SageMaker AI で学習した AI モデルをロボット上の AWS IoT Greengrass にデプロイし、エッジ推論を行うとともに、ロボットのセンサーデータを AWS クラウドに収集して AI モデルを再学習するものです。 11/26 Amazon Quick Suite introduces scheduling for Quick Flows Amazon Quick Suite の Quick Flows にスケジューリング機能が備わりました。様々なデータソースを参照する AI エージェントによるレポート作成等を、定期実行することが可能となりました。 Amazon Kinesis Video Streams now supports a new cost effective warm storage tier Amazon Kinesis Video Streams に、コスト効率の高いウォームストレージ層がサポートされました。監視カメラやVSaaS等の録画データを長期間保存する用途において、コスト削減が見込めます。 いかがでしたでしょうか。 皆様の情報キャッチアップのご支援になりましたら幸いです。 では、また来月も本ブログにお付き合いください。 著者について 田中　豊洋 AWS Japan のソリューションアーキテクトとして、製造業のお客様の技術支援を担当しています。製造業の IT 部門を計 24 年経験してきたことで、製造業視点で AWS 利活用を考えています。

はじめに Amazon Connect は、組織が大規模に優れた顧客体験を提供することを可能にする、使いやすいエンタープライズクラウドコンタクトセンターです。Amazon Connect の主要なメリットの一つに、Amazon CloudWatch とのネイティブ統合があります。この統合は運用状況を分析し、問題が顧客に影響を及ぼす前にアラートを受けることができる強力な機能を提供します。これにより、オンプレミス展開では実現が困難な規模とスピードでインサイトを提供します。 Model Context Protocol (MCP) を使えば、生成 AI を活用し、コンタクトセンター分析をさらにアクセスしやすく効率的にすることができ、これらの強力な分析機能を強化することができます。MCP により、AI エージェントを Amazon Connect の組み込み監視機能やサードパーティのデータソースと統合し、運用監視準備のための拡張フレームワークを作成できます。Amazon Q Developer などのツールを通じ、組織はかつてないほど簡単かつ迅速にコンタクトセンター運用に関するさらに深いインサイトにアクセスできるようになりました。 Amazon Connect のエンタープライズグレードの機能と MCP の AI による自動化の強力な組み合わせは、日常的な運用タスクを合理化されたインテリジェントなワークフローに変えます。フロー効率の分析、監視設定の最適化、使用パターンの調査などのタスクは、自然言語インタラクションを通じてより直感的になります。このブログでは、MCP が Amazon Connect のオブザーバビリティの強みをどのように増幅し、コンタクトセンター運用準備の次世代アプローチによって、組織がどのような実用的なユースケースを実現できるかを探ります。 ユースケースを通じた MCP の理解 Amazon Connect を運用する組織に参加したばかりのビジネスアナリスト、John を想像してみましょう。彼のタスクは、問い合わせフローの確認と監視設定の最適化です。このユースケースはまさに Amazon Connect の強力な機能を MCP がどのように強化するかを示す完璧な例です。Amazon Connect は包括的な Amazon CloudWatch 統合と監視ツールを標準で提供していますが、MCP は自然言語でのやり取りを通じて、これらの機能をさらにアクセスしやすくします。 Amazon Connect のネイティブなオブザーバビリティ機能により、John は既に詳細なフローログ、パフォーマンスメトリクス、監視機能にアクセス可能です。加えて MCP によって、John はこれらの強力なツールと会話型 AI を通じてやり取りすることができます。この強化された体験は、生産性とインサイトの生成を劇的に向上させます。MCP を生成 AI と組み合わせて使うことで、John は Amazon Connect の堅牢な監視インフラストラクチャをより直感的に活用できます。自然言語で質問し、プラットフォームの既存の強みを基盤とした包括的な分析を受け取ることができるのです。 プロンプト: 'aws-knowledge MCP' を使用してAmazon Connectフローのベストプラクティスを参照し、'aws-api-mcp' を使用して 'xyz' Amazon Connectインスタンスの 'AC-Blog-CallBack-Welcom-1' フローをレビューしてください。フィードバックを提供し、CloudWatchアラームも推奨してください。 分析結果: 図 1: Amazon Connect のフロー分析結果 MCP クライアントのライフサイクル MCP は次のようなライフサイクルで、ユーザープロンプトを実行可能な結果に変換するため、連携するコンポーネントをオーケストレーションします。このプロセスは 5 つの主要段階で構成されます : 検出フェーズ ：通常、個人のラップトップやワークステーション上で実行される MCP クライアントは、最初に利用可能な MCP サーバーと関連ツールを発見します。この初期の処理が、その後のすべてのインタラクションの基盤を確立します ユーザーインタラクション ：ユーザーは MCP クライアントのインターフェース（例：VS Code）を通じてクエリやプロンプトを入力します。これらのプロンプトは、シンプルなリクエストから Amazon Connect 管理のための複雑な運用コマンドまで多岐にわたります LLM 分析 ：Amazon Bedrock を通じてアクセスされるような基盤モデルが、インテリジェントなオーケストレーターとして機能し、3 つの部分からなる分析を実行します ユーザーのプロンプトの評価 利用可能な MCP サーバーの調査 関連ツールとその説明を評価します。この分析に基づいて、LLM はユーザーのリクエストを満たす最適なパスを決定する包括的な実行計画を作成します ツール呼び出し ：MCP クライアントは、LLM の実行計画に基づいて適切なツールの呼び出しを開始します。この段階で、ユーザーの要求が具体的なツール操作に変換されます 実行 ：最終段階で、MCP サーバーが必要なバックエンド API とコードの実行により、要求された操作を実行します。これには、AWS のドキュメントへのアクセス、AWS サービス操作の実行、推奨事項の生成など、さまざまなアクションが含まれる可能性があります このような合理的なライフサイクルにより、実行のチェーン全体を通じ、セキュリティと運用の整合性を維持しながら、ユーザーリクエストの効率的な処理することができます。 Amazon Connect のオブザーバビリティのための Amazon Q Developer を使用した MCP の設定 MCP は、AI アプリケーションを外部データソースやツールと接続するための標準化されたアプローチを提供します。Amazon Connect のオブザーバビリティにおいては、MCP は組織による自然言語クエリを通じた AI による分析を利用可能にし、従来の手動プロセスを自動化されたワークフローに変換できます。 MCP は、 Amazon Q Developer を使用した VS Code、 Amazon Q CLI 、Claude Code、 Kiro 、およびカスタム統合を含む複数のクライアント実装でサポートされています。この投稿では、VS Code と Amazon Q Developer を使って、 AWS MCP サーバー を設定し、会話型 AI を通じて包括的な Amazon Connect の分析を行う方法を説明します。 前提条件とセットアップ MCP による Amazon Connect のオブザーバビリティを設定するためには、以下の環境が必要です。 uv パッケージマネージャーがインストールされた Python 3.10 以上の環境 Amazon Q Developer 拡張機能が設定された Visual Studio Code(VS Code) Amazon Connect 、Amazon CloudWatch 、AWS CloudTrail にアクセス権限をもつ AWS 認証情報 Amazon CloudWatch へのロギングが有効な Amazon Connect インスタンス MCP サーバーの構成 AWS MCP Servers リポジトリ は、Amazon Connect のオブザーバビリティに使用できる複数の MCP サーバーを提供しています： AWS API MCP Server は、Amazon Connect インスタンス管理と設定分析を含む AWS サービスとの直接的なやり取りを可能にします CloudWatch MCP Server は、パフォーマンス分析とトラブルシューティングに不可欠なメトリクス、ログ、監視データへのアクセスを提供します。※注意: このサーバーには、AWS アカウントとリージョンに対して設定された AWS プロファイルが必要です AWS Documentation MCP Server は、AWS のベストプラクティスと実装ガイダンスへのアクセスを提供します MCP サーバーの設定 次のように Amazon Q Developer MCP 設定でこれらのサーバーを設定してください。 MCP サーバーの設定には2つの方法があります。 方法 1：Amazon Q Developer GUI を使用する（推奨） MCP 設定へのアクセス VS Code を開く Amazon Q Developer のパネルを開く Amazon Q Developer 内のチャットパネルを開く 「ツールアイコン」（歯車またはレンチのシンボル）をクリックして MCP 設定にアクセス MCP サーバーの追加または編集 新しいサーバーの追加：プラス（+）マークをクリック 既存のサーバーの編集：リストからサーバーを選択 設定のスコープの選択 グローバル（すべてのプロジェクトに適用）：設定は ~/.aws/amazonq/mcp.json に保存されます ローカル（ワークスペース・現在のプロジェクトのみに適用）：設定は .amazonq/mcp.json に保存されます サーバーの詳細設定 – 各 MCP サーバーのドキュメントガイダンスに従ってください： 名前 ：わかりやすい名前を入力します（例：「aws-api」、「cloudwatch」） トランスポート ：通信プロトコルを選択します（stdio） コマンド ：実行コマンドを提供します（例：uv run aws-api-mcp） 引数 ：必要に応じて必要な引数を追加します 環境変数 ：必要に応じて AWS_REGION、AWS_PROFILE を設定します 「保存」をクリックして変更を適用します 図 2: VS Code 上の Amazon Q Developer の MCP 設定 GUI で、ツール設定・サーバー設定画面を表示している様子 方法 2: JSON ファイルを手動で設定する 手動で設定したいユーザーは、MCP 設定ファイルを直接編集することも可能です。 グローバル設定ファイル ( ~/.aws/amazonq/mcp.json )： { "mcpServers": { "cloudwatch-mcp-server": { "autoApprove": [], "disabled": false, "command": "uvx", "args": [ "awslabs.cloudwatch-mcp-server@latest" ], "env": { "AWS_PROFILE": "connect-observability", "FASTMCP_LOG_LEVEL": "ERROR" }, "transportType": "stdio" }, "aws-documentation-mcp-server": { "command": "uvx", "args": [ "awslabs.aws-documentation-mcp-server@latest" ], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_DOCUMENTATION_PARTITION": "aws" }, "disabled": false, "autoApprove": [] }, "cost-explorer-mcp-server": { "command": "uvx", "args": [ "awslabs.cost-explorer-mcp-server@latest" ], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_PROFILE": "connect-observability" }, "disabled": false, "autoApprove": [] }, "aws-api-mcp-server": { "command": "uvx", "args": [ "awslabs.aws-api-mcp-server@latest" ], "env": { "AWS_REGION": "us-east-1", "AWS_API_MCP_PROFILE_NAME": "connect-observability" }, "timeout": 60000000, "disabled": false } } } ローカル/ワークスペース設定ファイル (プロジェクトルートの .amazonq/mcp.json )：プロジェクト固有の設定が必要な場合、保存先を変えて同じ JSON 構造を使用します。 Amazon Connect とのデータ統合 MCP サーバーは、標準的な AWS API や Amazon CloudWatch との統合を通じて Amazon Connect のデータにアクセスします。主なデータソースには以下が含まれます： コンタクトフローのログ： /aws/connect/contactflow/[instance-id] に含まれる実行の詳細とパフォーマンスメトリクス エージェントイベントログ：リアルタイムのエージェントのアクティビティとステータス変更 AWS CloudTrail イベント：セキュリティ分析のための管理アクションと API 呼び出し Amazon Connect メトリクス：履歴パフォーマンス データと使用パターン 包括的な分析を有効にするため、AWS 認証情報に connect:List*、connect:Describe*、cloudwatch:GetMetricStatistics、および logs:FilterLogEvents の権限が含まれていることを確認してください。 プロンプト例 MCP の強力な点の一つは、よく練られたプロンプトを通じ、役割に応じた複雑なタスクを処理できる点です。以下の例は、組織内の異なる役割の人々が MCP を活用して Amazon Connect の運用を強化する方法を示しています。これらのプロンプトは、セキュリティ監視からパフォーマンス最適化まで、既存の機能を強化する MCP の汎用性を示しています。セキュリティ分析の強化、技術的異常の調査、アラーム設定の最適化、ユーザー管理、使用傾向の分析など、これらのプロンプトは MCP を使った独自の実装のための実用的なテンプレートとしても活用できます。 例 1 (セキュリティ分析者向け) Amazon Connect の CloudTrail logs を解析して、exceptionを報告して 例 2 (開発者向け) Amazon Connect インスタンス xyz のアノマリを CloudWatch のフローログから検索して、解決策を提案して 例 3 (開発者向け) Amazon Connect インスタンス xyz に適したCloudWatch metrics の Alarm を推奨して 例 4 (開発者向け) Amazon Connect インスタンス 'xyz' のユーザーを 'abc' にコピーし、その結果を報告して 例 5 (ビジネスアナリスト向け) Amazon Connect の利用料を 12 か月分分析して。最もコストが高かった月について、顧客の通話パターンを報告して 最適化とベストプラクティス クエリ設計 : 応答精度を最大化し、処理時間を最小化するために、プロンプトを、特定の時間範囲、リソース識別子、分析目標を含んだ構造にします。例えば: 「’xyz’ Amazon Connect インスタンスの CloudWatch ログをスキャンする」の代わりに 「’xyz’ Amazon Connect インスタンスの過去 30 日間のフローログをスキャンする」を使用します リソース管理 : 分析機能を維持しながらコストを管理するため、AWS APIの使用パターンを監視し、適切なサービスクォータを設定します パフォーマンスチューニング : AI によるインサイトの恩恵を受ける複雑な分析タスクには MCP を使用、日常的なメトリクス可視化には従来の監視ダッシュボードを活用します バッチ処理 : 定期的なオブザーバビリティのタスクについては、API クォータへの影響を最小化するために、アクセスが集中しない時間帯に分析を予定することを検討します セキュリティの考慮 : MCP サーバー構成に最小権限アクセスの原則を実装し、セキュリティ体制を維持するため、権限を定期的に監査します クリーンアップとリソースの管理 MCP 設定を削除する際は、Amazon Q Developer 設定からサーバー定義を削除、uv uninstall を使用して関連パッケージをアンインストール、そして実装中に作成された一時的な AWS リソースをクリーンアップします。 まとめ MCP は、自然言語インターフェースを通じた AI を活用した分析を可能にし、Amazon Connect の強力なオブザーバビリティ機能を強化します。この方法によって、Amazon Connect の強力な CloudWatch 統合とエンタープライズグレードの監視機能を基盤にした高度な分析を、あらゆる規模の組織にとってさらにアクセスしやすくします。 Amazon Connect で MCP を活用する組織は、既存の分析機能の強化、インサイト生成の加速、運用監視準備の強化を期待できます。標準化されたプロトコルによって、プラットフォームのスケーラビリティと信頼性を複数のインスタンス間で維持しながら、Amazon Connect のネイティブ機能とシームレスに統合できます。 Amazon Connect の運用準備のため、 MCP の利用を開始するには、強化されたコンタクトフロー分析やインテリジェントなパフォーマンス監視など、既存の CloudWatch データの活用に焦点を絞ったユースケースから始めましょう。プラットフォームへの習熟度が高まったら、Amazon Connect のエンタープライズ基盤を基に構築された包括的なセキュリティ監視、コスト最適化、自動化された運用ワークフローを含む実装に拡張していきましょう。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

2025 年 12 月 2 日、AI エージェントを本番稼働環境から引き離す障壁をさらに取り除くための Amazon Bedrock AgentCore の新機能を発表しました。あらゆる業界の組織が、あらゆる規模で高性能なエージェントを安全に構築、導入、運用するための最先端のプラットフォームである AgentCore をすでに利用しています。プレビューからわずか 5 か月で、 AgentCore SDK は 200 万回以上ダウンロードされました 。例: スポーツのパイオニアでありイノベーションリーダーでもある PGA TOUR は、デジタルプラットフォーム向けの記事を作成するためのマルチエージェントコンテンツ生成システムを構築しました。AgentCore 上に構築されたこの新しいソリューションにより、PGA TOUR はコンテンツの書き込み速度を 1,000 パーセント向上させながらコストを 95％ 削減することで、フィールドのすべてのプレーヤーに包括的なサービスを提供できます。 Workday のような独立系ソフトウェアベンダー (ISV) は、AgentCore で未来のソフトウェアを構築しています。AgentCore Code Interpreter は、Workday Planning Agent に安全なデータ保護と財務データ探索に不可欠な機能を提供します。ユーザーは自然言語クエリを使用して財務データや業務データを分析できるため、財務計画を直感的かつ自発的に行うことができます。この機能により、日常的な計画分析に費やす時間が 30% 短縮され、1 か月あたり約 100 時間を節約できます。 ブラジルのディストリビューター兼小売業者である Grupo Elfa は、エージェントの完全な監査トレーサビリティとリアルタイムメトリクスのために AgentCore Observability を活用し、事後対応型のプロセスをプロアクティブな業務に変えています。この統合プラットフォームを使用することで、営業チームはエージェントの決定を完全に可視化しながら、毎日何千件もの価格見積もりを処理できます。これにより、エージェントの意思決定とやり取りの 100% のトレーサビリティが実現し、問題解決にかかる時間が 50% 短縮されます。 組織がエージェントのデプロイをスケールするにつれ、自信を持ってエージェントを配置するための適切な境界と品質チェックの実施に関する課題に直面します。また、エージェントは自律性が高いため、機密データに不適切にアクセスしたり、不正な決定を下したり、予期せぬ行動を取ったりする可能性があるため、安心して大規模に展開することが難しくなります。開発チームは、エージェントの自律性を実現すると同時に、許容範囲内で業務を遂行し、顧客や従業員の前に配置するために必要な品質とのバランスを取る必要があります。 現在利用可能な新機能により、このプロセスを推測する必要がなくなり、信頼できる AI エージェントを自信を持って構築してデプロイできるようになります。 AgentCore のポリシー (プレビュー) — 詳細な権限を持つポリシーを使用して実行前に AgentCore Gateway ツールの呼び出しをインターセプトすることにより、エージェントアクションの明確な境界を定義します。 AgentCore Evaluations (プレビュー) — 組み込みエバリュエーターを使用して、実際の行動に基づいてエージェントの質をモニタリングします。正確性や有用性などのディメンションについては、組み込みのエバリュエーターと、ビジネス固有の要件に対応するカスタムエバリュエーターを使用します。 また、エージェントができることを拡張する機能も導入しています。 AgentCore Memory のエピソード機能 — エージェントが経験から学び、同様の状況でソリューションを適応させて、将来の同様のタスクの一貫性とパフォーマンスを向上させるのに役立つ新しい長期戦略です。 AgentCore Runtime の双方向ストリーミング — 音声エージェントを導入して、ユーザーとエージェントの両方が自然な会話フローに従って同時に話せるようにします。 エージェントを正確に制御するための AgentCore のポリシー ポリシーにより、エージェントが実行できるアクションやエージェントの推論ループの外部に適用できるアクションを制御できるため、エージェントは、ツール、システム、またはデータに到達する前に決定が検証を必要とする自律的なアクターとして扱われます。AgentCore Gateway と統合することで、ツールの呼び出しを発生時に傍受し、運用速度を維持しながらリクエストを処理できるため、ワークフローの高速性と応答性が維持されます。 自然言語を使用してポリシーを作成することも、 Cedar (きめ細かな権限を持つオープンソースのポリシー言語) を直接使用することもできます。これにより、カスタムコードを記述しなくても、ルールを設定、理解、監査するプロセスが簡素化されます。このアプローチにより、コーディングの専門知識がなくてもルールを作成、理解、監査できる開発、セキュリティ、コンプライアンスチームがポリシーを作成しやすくなります。 ポリシーは、エージェントの構築方法や使用するモデルとは無関係に機能します。API、 AWS Lambda 関数、 モデルコンテキストプロトコル (MCP) サーバー、サードパーティサービスなど、どのツールとデータエージェントがアクセスできるか、どのようなアクションをどのような条件で実行できるかを定義できます。 チームは明確なポリシーを一度定義すれば、それを組織全体に一貫して適用できます。ポリシーが整っていれば、開発者は革新的なエージェント体験を自由に生み出すことができ、組織はエージェントを配置して、定義された境界やコンプライアンス要件の範囲内にとどまることを認識しながら、自律的に行動することができます。 エージェントコアでのポリシーの使用 まず、 AgentCore コンソール の新しい [ポリシー] セクションでポリシーエンジンを作成し、それを 1 つ以上の AgentCore Gateway に関連付けることができます。 ポリシーエンジンは、ゲートウェイエンドポイントで評価されるポリシーの集まりです。ゲートウェイをポリシーエンジンに関連付ける場合、ポリシーの結果を適用する (ツールコールへのアクセスを効果的に許可または拒否する) か、ログのみを出力するかを選択できます。ログは、本番稼働環境で有効にする前にポリシーをテストして検証するのに役立ちます。 次に、適用するポリシーを定義して、関連する AgentCore Gateway が提供するツールへのアクセスをきめ細かく制御できます。 ポリシーを作成するには、自然言語による説明 (使用する認証クレームの情報を含める必要があります) から始めることも、Cedar コードを直接編集することもできます。 自然言語ベースのポリシーオーサリング機能により、きめ細かなポリシーをより簡単に作成できます。正式なポリシーコードを書く代わりに、わかりやすい英語でルールを記述できます。システムはユーザーの意図を解釈し、候補となるポリシーを生成し、ツールスキーマと照合して検証し、自動推論を使用して安全条件をチェックします。つまり、過度に寛容なプロンプト、過度に制限されたプロンプト、または決して満たすことができない条件を含むプロンプトを特定します。 一般的な大規模言語モデル (LLM) による解釈とは異なり、この機能はツールの構造を理解し、適用できないルールにはフラグを立てながら、構文的に正しく、意味的に意図したとおりのポリシーを生成します。 モデルコンテキストプロトコル (MCP) サーバーとしても利用できるため、通常の開発ワークフローの一部として、お好みの AI 支援コーディング環境でポリシーを直接作成して検証できます。このアプローチにより、オンボーディング時間が短縮され、Cedar の専門知識がなくても質の高い承認ルールを作成できます。 次のサンプルポリシーでは、AgentCore Gateway への認証に使用される JWT トークンの OAuth クレームの情報 ( ロール 用) とツール呼び出しに渡される引数 ( context.input ) を使用して、払い戻しを処理するツールへのアクセスを検証します。 refund-agent ロールを持つ認証ユーザーのみがツールにアクセスできますが、金額 ( context.input.amount ) には 200米ドル未満という制限が課せられています。 permit( principal is AgentCore::OAuthUser, action == AgentCore::Action::"RefundTool__process_refund", resource == AgentCore::Gateway::"<GATEWAY_ARN>" ) when { principal.hasTag("role") && principal.getTag("role") == "refund-agent" && context.input.amount < 200 }; 継続的かつリアルタイムの品質インテリジェンスを実現するための AgentCore Evaluations AgentCore Evaluations は、実際の行動に基づいてエージェントのパフォーマンスを継続的にモニタリングおよび分析するのに役立つフルマネージドサービスです。AgentCore Evaluations では、組み込みのエバリュエーターを使用して、正確性、有用性、ツール選択の精度、安全性、目標達成率、コンテキストの関連性などの一般的な品質評価を行うことができます。また、選択したプロンプトとモデルで構成されたカスタムモデルベースのスコアリングシステムを作成して、サービスがエージェントのライブインタラクションをサンプリングして継続的にスコアリングしながら、ビジネスに合わせたスコアリングを行うこともできます。 AgentCore Evaluations の結果はすべて、AgentCore Observability のインサイトとともに Amazon CloudWatch で視覚化されるため、一元的にモニタリングできます。また、評価スコアにアラートやアラームを設定して、エージェントの品質を積極的にモニタリングし、メトリクスが許容範囲を超えたときに対応することもできます。 AgentCore Evaluations は、デプロイ前にエージェントをベースラインと照合して欠陥のあるバージョンがユーザーに届かないようにするテストフェーズで使用できます。また、本番稼働環境ではエージェントの継続的な改善に使用できます。品質メトリクスが定義されたしきい値を下回ると (たとえば、カスタマーサービスエージェントの満足度が 8 時間にわたって低下したり、礼儀正しさのスコアが 8 時間で 10% 以上低下したりした場合)、システムは即座にアラートをトリガーし、品質問題をより迅速に検出して対処するのに役立ちます。 AgentCore Evaluations の使用 AgentCore コンソール の新しい [評価] セクションでオンライン評価を作成できます。データソースとして、AgentCore エージェントエンドポイントまたは外部エージェントが使用する CloudWatch ロググループを使用できます。たとえば、ここでは、 プレビューで AgentCore を導入 したときに共有したのと同じサンプルカスタマーサポートエージェントを使用しています。 次に、既存のテンプレートから定義したり、ゼロから構築したりできるカスタムエバリュエーターを含め、使用するエバリュエーターを選択できます。 たとえば、カスタマーサポートエージェントの場合、次のようなメトリクスを選択できます。 正確性 — エージェントの回答に含まれる情報が事実に基づいて正確かどうかを評価します 忠実性 — 回答の情報が提供されたコンテキスト/ソースによってサポートされているかどうかを評価します 有用性 — エージェントの対応がどれほど有用で価値があるかをユーザーの視点から評価します 有害性 — 応答に有害なコンテンツが含まれているかどうかを評価します ステレオタイプ — 個人やグループについて一般化しているコンテンツを検出します ツール選択とツールパラメータ精度のエバリュエーターは、エージェントがタスクに適したツールを選択し、ユーザークエリから正しいパラメーターを抽出しているかどうかを理解するのに役立ちます。 評価の作成を完了するには、サンプリングレートとオプションのフィルターを選択できます。権限については、新しい AWS Identity and Access Management (IAM) サービスロールを作成するか、既存のサービスロールを渡すことができます。 結果は評価されると、 Amazon CloudWatch の AgentCore Observability ダッシュボードに公開されます。棒グラフのセクションのいずれかを選択すると、対応するトレースが表示され、その特定の評価の背後にある要求と応答についてより深いインサイトを得ることができます。 結果は CloudWatch に保存されるため、そのすべての機能を使用して、たとえばアラームや自動化などを作成できます。 AgentCore Evaluations でのカスタムエバリュエータの作成 カスタムエバリュエーターを使用すると、エージェント固有の要件に合わせたビジネス固有の品質メトリクスを定義できます。カスタムエバリュエーターを作成するには、温度や最大出力トークンなどの推論パラメーターを含むモデルと、判断指示を含むカスタマイズされたプロンプトを用意します。ビルトインのエバリュエーターが使用するプロンプトから開始することも、新しいエバリュエーターを入力することもできます。 次に、出力で生成するスケールを定義します。数値でも、定義したカスタムテキストラベルでもかまいません。最後に、評価がモデルによってシングルトレースで計算されるか、フルセッションで計算されるか、またはツール呼び出しごとに計算されるかを設定します。 体験型学習のための AgentCore Memory エピソード機能 AgentCore Memory は、AI エージェントが過去の対話を記憶できるようにするフルマネージドサービスで、エージェントが過去の経験から学び、その教訓を将来の対話でより役立つ支援を提供できるようにする、新しい 長期記憶戦略 が含まれるようになりました。 エージェントに旅行を予約することを検討してください。エージェントは、時間が経つにつれて、クライアントとのミーティングのために仕事で旅行するときにフライトを後の時間に移動する必要がある場合など、お客様の予約パターンから学習します。クライアントとのミーティングを含む次回の予約を開始すると、エージェントは学習したパターンに基づいて柔軟な返品オプションを積極的に提案します。特定の旅行習慣を学ぶ経験豊富なアシスタントと同じように、エピソード記憶を持つエージェントは、個々のニーズを認識してそれに対応できるようになりました。 新しいエピソード機能を有効にすると、AgentCore Memory は、エージェントとのやり取りのコンテキスト、推論プロセス、実行されたアクション、結果を記録する構造化されたエピソードをキャプチャし、リフレクションエージェントはこれらのエピソードを分析して、より幅広いインサイトとパターンを抽出します。エージェントは、似たようなタスクに直面したときに、学んだことを取り戻して意思決定の一貫性を高め、処理時間を短縮できます。これにより、考えられるすべての提案の長いリストではなく、エージェントがタスクを完了するために必要な特定の学習のみをエージェントコンテキストに含めることができるため、カスタムインストラクションの必要性が減ります。 より自然な会話を実現する AgentCore Runtime 双方向ストリーミング AgentCore Runtime を使用すると、数行のコードでエージェンティックアプリケーションをデプロイできます。自然で応答性の高い会話体験を簡単にデプロイするために、AgentCore Runtime は双方向ストリーミングをサポートするようになりました。この機能により、音声エージェントはユーザが話している間も聞き取って適応できるため、担当者は応答の途中でエージェントの話を中断し、エージェントが現在のアウトプットを完了するのを待たずに、エージェントに新しいコンテキストにすぐに順応させることができます。双方向ストリーミングは、ユーザーが完全な応答を待たなければならない従来のターン制の対話とは異なり、エージェントがユーザーの発言に基づいて応答を動的に変更する、流れるような自然な会話を生み出します。 このような会話体験をゼロから構築するには、同時コミュニケーションの複雑な流れを処理するための多大なエンジニアリング努力が必要です。双方向ストリーミングは、エージェントが入力を処理しながら出力を生成し、中断を正常に処理し、会話が動的に変化してもコンテキストを維持するために必要なインフラストラクチャを管理することで、これを簡素化します。人間の会話の流動的な性質に自然に適応するエージェントを配備できるようになりました。つまり、対話の流れを失うことなく、考えの途中での中断、コンテキストの切り替え、明確化をサポートできます。 知っておくべきこと Amazon Bedrock AgentCore (ポリシーのプレビューを含む) は、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、および欧州 (フランクフルト、アイルランド) の AWS リージョン でご利用いただけます。AgentCore Evaluations のプレビューは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、および欧州 (フランクフルト) リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 AgentCore では、前払いの義務なしで使用した分だけ支払うことができます。料金の詳細については、 Amazon Bedrock の料金ページ にアクセスしてください。AgentCore は AWS 無料利用枠 の一部でもあり、AWS の新規のお客様は無料で利用を開始し、主要な AWS サービスを試すことができます。 これらの新機能は、 CreWAI 、 LangGraph 、 LlamaIndex 、 Strands Agents などのあらゆるオープンソースフレームワークと、あらゆる基盤モデルで動作します。AgentCore サービスは一緒に使用することも、単独で使用することもできます。 AgentCore オープンソース MCP サーバー を使用して、お気に入りの AI 支援開発環境を使い始めることができます。 詳細を確認してすぐに使い始めるには、「 AgentCore デベロッパーガイド 」をご覧ください。 – Danilo 原文は こちら です。

（本稿は、2025年12月8日に公開された “ SAP data ingestion and replication with AWS Glue zero-ETL ” を翻訳したものです） 組織では、複雑なデータパイプラインを維持することなく、SAPシステムからデータを取り込み、インサイトへより迅速にアクセスするニーズが高まっています。 AWS Glue zero-ETL with SAP は、Operational Data Provisioning（ ODP ）管理のSAP Business Warehouse（BW）エクストラクター、Advanced Business Application Programming（ABAP）、Core Data Services（CDS）ビュー、その他の非ODPデータソースなどのSAPデータソースからのデータ取り込みとレプリケーションをサポートしています。Zero-ETLデータレプリケーションとスキーマ同期により、抽出されたデータを Amazon Redshift 、 Amazon SageMaker lakehouse アーキテクチャ 、 Amazon S3 Tables などのAWS環境に保存することを容易にし、手動でのパイプライン開発を減らします。これにより、 Amazon Q 、 Kiro 、 Amazon Quick Suite などのサービスと組み合わせて使用することで、自然言語クエリを使用してSAPデータを分析し、自動化のためのAIエージェントを作成し、エンタープライズデータランドスケープ全体でコンテキストに応じたインサイトを生成できる、AI駆動型インサイトの基盤が構築されます。 この記事では、さまざまなODPおよび非ODP SAPソースとのzero-ETL統合を作成および監視する方法を紹介します。 ソリューション概要 SAPとデータ連携する際の主要コンポーネントは、SAPデータ構造とプロトコルで動作するように設計された AWS Glue SAP ODataコネクタ です。このコネクタは、ABAPベースのSAPシステムへの接続を提供し、SAPのセキュリティとガバナンスフレームワークに準拠しています。AWS SAPコネクタの主な機能は以下の通りです: ODataプロトコルを使用して、さまざまなSAP NetWeaverシステムからデータ抽出 BWエクストラクター（2LIS_02_ITMなど）やCDSビュー（C_PURCHASEORDERITEMDEXなど）などの複雑なSAPデータモデルを、管理された形でレプリケーション SAP変更データキャプチャ（CDC）テクノロジーを使用したODPおよび非ODPエンティティの両方への対応 SAPコネクタは、AWS Glue StudioまたはAWS管理のzero-ETLレプリケーションの両方で動作します。 AWS Glue Studio でのセルフマネージドレプリケーションは、データ処理ユニット、レプリケーション頻度、価格パフォーマンスの調整、ページサイズ、データフィルター、宛先、ファイル形式、データ変換、および選択したランタイムでの独自コードの記述をコントロールできる環境です。zero-ETLでのAWS管理データレプリケーションは、カスタム設定の負担を取り除き、AWS管理の代替手段を提供し、15分から6日間のレプリケーション頻度を可能にします。以下のソリューションアーキテクチャは、さまざまなSAPソースからzero-ETLを使用してODPおよび非ODP SAPデータを取り込み、Amazon Redshift、SageMaker lakehouse、S3 Tablesに書き込むアプローチを示しています。 ODPソースの変更データキャプチャ SAP ODPは、SAPソースシステムからターゲットシステムへの増分データレプリケーションを可能にするデータ抽出フレームワークです。ODPフレームワークは、アプリケーション（サブスクライバー）がBWエクストラクター、CDSビュー、BWオブジェクトなどのサポートされているオブジェクトから増分的にデータを要求できるようにします。 AWS Glue zero-ETLデータ取り込みは、ターゲットシステムでベースラインデータセットを確立するために、エンティティデータの初期フルロードを実行することから始まります。初期フルロードが完了すると、SAPは削除を含むデータ変更をキャプチャするOperational Delta Queue（ODQ）として知られるデルタ（増分）キューをプロビジョニングします。デルタトークンは初期ロード中にサブスクライバーに送信され、zero-ETL内部の状態管理システム内に永続化されます。 増分処理は、状態ストアから最後に保存されたデルタトークンを取得し、ODataプロトコルを使用してこのトークンを使用してSAPにデルタ変更リクエストを送信します。システムは、SAP ODQメカニズムを通じて返されたINSERT/UPDATE/DELETE操作を処理し、レコードが変更されていないシナリオでもSAPから新しいデルタトークンを受信します。この新しいトークンは、取り込みが成功した後、状態管理システムに永続化されます。エラーシナリオでは、システムは既存のデルタトークン状態を保持し、データ損失なしで再試行メカニズムを可能にします。 以下のスクリーンショットは、SAPシステムでの成功した初期ロードとそれに続く4回の増分データ取り込みを示しています。 非ODPソースの変更データキャプチャ 非ODP構造は、ODP対応でないODataサービスです。これらは、ODPフレームワークなしで直接公開されるAPI、関数、ビュー、またはCDSビューです。このメカニズムを使用してデータが抽出されますが、増分データ抽出はオブジェクトの性質に依存します。たとえば、オブジェクトに「最終更新日」フィールドが含まれている場合、それを使用して変更を追跡し、増分データ抽出を提供します。 AWS Glue zero-ETLは、エンティティに変更を追跡するフィールド（最終更新日または時刻）が含まれている場合、非ODP ODataサービスに対してすぐに使える増分データ抽出を提供します。これらのSAPサービスに、zero-ETLはデータ取り込みに2つのアプローチを提供します:タイムスタンプベースの増分処理と完全ロードです。 タイムスタンプベースの増分処理 タイムスタンプベースの増分処理は、zero-ETLでユーザーが設定したタイムスタンプフィールドを使用して、データ抽出プロセスを最適化します。zero-ETLシステムは、後続の増分処理操作の基礎となる開始タイムスタンプを確立します。ウォーターマークとして知られるこのタイムスタンプは、データの一貫性を促進するために重要です。クエリ構築メカニズムは、タイムスタンプ比較に基づいてODataフィルターを構築します。これらのクエリは、最後に成功した処理実行以降に作成または変更されたレコードを抽出します。システムのウォーターマーク管理機能は、各処理サイクルから最高のタイムスタンプ値の追跡を維持し、この情報を後続の実行の開始点として使用します。zero-ETLシステムは、設定されたプライマリキーを使用してターゲットでアップサートを実行します。このアプローチは、データ整合性を維持しながら更新を適切に処理することを促進します。各ターゲットシステム更新が成功した後、ウォーターマークタイムスタンプが進められ、将来の処理サイクルのための信頼できるチェックポイントが作成されます。 ただし、タイムスタンプベースのアプローチには制限があります – SAPシステムは削除タイムスタンプを維持しないため、物理的な削除を追跡できません。タイムスタンプフィールドが利用できないか設定されていないシナリオでは、システムはアップサート処理を伴うフルロードに移行します。 フルロード（完全ロード） フルロードアプローチは、独立した（前後関係のない）処理として、またはタイムスタンプベースの処理が実行可能でない場合のフォールバックメカニズムとして機能します。この方法は、各処理サイクル中に完全なエンティティデータセットを抽出することを含み、変更追跡が利用できないか必要でないシナリオに適しています。抽出されたデータセットは、ターゲットシステムでアップサートされます。アップサート処理ロジックは、新しいレコードの挿入と既存レコードの更新の両方を処理します。 増分ロードまたはフルロードを選択するタイミング タイムスタンプベースの増分処理アプローチは、頻繁に更新される大規模なデータセットに対して最適なパフォーマンスとリソース使用率を提供します。変更されたレコードのみの選択的転送により、データ転送量が削減され、ネットワークトラフィックが削減されます。この最適化は、運用コストの削減に直接つながります。アップサートを伴うフルロードは、増分処理が実行可能でないシナリオでのデータ同期を促進します。 これらのアプローチは、非ODP SAP構造とのzero-ETL統合のための完全なソリューションを形成し、エンタープライズデータ統合シナリオの多様な要件に対応します。これらのアプローチを使用する組織は、2つのアプローチのいずれかを選択する際に、特定のユースケース、データ量、およびパフォーマンス要件を評価する必要があります。 SAP zero-ETL統合の監視 AWS Glueは、 Amazon CloudWatch ログを使用して状態管理、ログ、およびメトリクスを維持します。可観測性を設定する手順については、「 統合の監視 」を参照してください。ログ配信用に AWS Identity and Access Management （IAM）ロールが設定されていることを確認してください。統合は、ソース取り込みと選択したターゲットへの書き込みの両方から監視されます。 ソース取り込みの監視 AWS Glue zero-ETLとCloudWatchの統合により、データ統合プロセスを追跡およびトラブルシューティングするための監視機能が提供されます。CloudWatchを通じて、問題を特定し、パフォーマンスを監視し、SAPデータ統合の運用状態を維持するのに役立つ詳細なログ、メトリクス、およびイベントにアクセスできます。成功とエラーのシナリオのいくつかの例を見てみましょう。 シナリオ1: ロールに権限がない このエラーは、SAPデータへのアクセスを試みる際に、AWS Glueでのデータ統合プロセス中に発生しました。接続は、400 Bad Requestステータスコードを持つCLIENT_ERRORに遭遇し、ロールに権限がないことを示しています。 { "eventTimestamp": 1755031897157, "integrationArn": "arn:aws:glue:us-east-2:012345678901:integration:1da4dccd-96ce-4661-8ef1-bf216623d65f", "sourceArn": "arn:aws:glue:us-east-2:012345678901:connection/SAPOData-sap-glue-dev", "level": "ERROR", "messageType": "IngestionFailed", "details": { "loadType": "", "errorMessage": "You do not have the necessary permissions to access the glue connection. make sure that you have the correct IAM permissions to access AWS Glue resources.", "errorCode": "CLIENT_ERROR" } } シナリオ2: デルタリンクの破損 CloudWatchログは、SAPからAWS Glueへのデータ同期中にデルタトークンが欠落している問題を示しています。エラーは、ODataサービスを通じてSAP販売ドキュメント項目テーブルFactsOfCSDSLSDOCITMDXにアクセスしようとしたときに発生します。増分データロードと変更の追跡に必要なデルタトークンがないため、システムがデータ抽出API RODPS_REPL_ODP_OPENを開こうとしたときにCLIENT_ERROR（400 Bad Request）が発生しました。 { "eventTimestamp": 1760700305466, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:f62e1971-092c-46a3-ba88-d32f4c6cd649", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/SAPOData-sap-glue-dev", "level": "ERROR", "messageType": "IngestionFailed", "details": { "tableName": "/sap/opu/odata/sap/Z_C_SALESDOCUMENTITEMDEX_SRV/FactsOfCSDSLSDOCITMDX", "loadType": "", "errorMessage": "Received an error from SAPOData: Could not open data access via extraction API RODPS_REPL_ODP_OPEN. Status code 400 (Bad Request).", "errorCode": "CLIENT_ERROR" } シナリオ3: SAPデータ取り込みのクライアントエラー このCloudWatchログは、SAPエンティティEntityOf0VENDOR_ATTRがODataサービスを通じて見つからないか、アクセスできないクライアント例外シナリオを明らかにしています。このCLIENT_ERRORは、AWS GlueコネクタがSAPシステムからの応答を解析しようとしたが、エンティティがソースSAPシステムに存在しないか、SAPインスタンスが一時的に利用できないために失敗したときに発生します。 { "eventTimestamp": 1752676327649, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:9f1acbc0-599f-47d2-8e84-e9779976af59", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/SAPOData-sap-glue-dev", "level": "ERROR", "messageType": "IngestionFailed", "details": { "tableName": "/sap/opu/odata/sap/ZVENDOR_ATTR_SRV/EntityOf0VENDOR_ATTR", "loadType": "", "errorMessage": "Data read from source failed for entity /sap/opu/odata/sap/ZVENDOR_ATTR_SRV/EntityOf0VENDOR_ATTR using connector SAPOData; ErrorMessage: Glue connector returned client exception. The response from the connector application couldn't be parsed.", "errorCode": "CLIENT_ERROR" } } ターゲット書き込みの監視 Zero-ETLは、ターゲットシステムに応じた監視メカニズムを採用しています。Amazon Redshiftターゲットの場合、統合ステータス、ジョブ実行、およびデータ移動統計に関する詳細情報を提供するsvv_integrationシステムビューを使用します。SageMaker lakehouseターゲットを使用する場合、zero-ETLはzetl_integration_table_stateテーブルを通じて統合状態を追跡し、同期ステータス、タイムスタンプ、および実行の詳細に関するメタデータを維持します。さらに、CloudWatchログを使用して統合の進行状況を監視し、成功したコミット、メタデータの更新、およびデータ書き込みプロセス中の潜在的な問題に関する情報をキャプチャできます。 シナリオ1: SageMaker lakehouseターゲットでの処理成功 CloudWatchログは、CDCモードを使用したプラントテーブルの成功したデータ同期アクティビティを示しています。最初のログエントリ（IngestionCompleted）は、タイムスタンプ1757221555568での取り込みプロセスの成功した完了を確認し、最後の同期タイムスタンプは1757220991999です。2番目のログ（IngestionTableStatistics）は、データ変更の詳細な統計を提供し、このCDC同期中に300の新しいレコードが挿入され、8つのレコードが更新され、2つのレコードがターゲットデータベースglueetlから削除されたことを示しています。このレベルの詳細は、ターゲットシステムに伝播される変更の量とタイプを監視するのに役立ちます。 { "eventTimestamp": 1757221555568, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:b7a1c69a-e180-4d27-b71d-5fcf196d9d2d", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/mam301", "targetArn": "arn:aws:glue:us-east-1:012345678901:database/gluezetl", "level": "VERBOSE", "messageType": "IngestionCompleted", "details": { "tableName": "plant", "loadType": "CDC", "message": "Successfully completed ingestion", "lastSyncedTimestamp": 1757220991999, "consumedResourceUnits": "10" } } { "eventTimestamp": 1757222506936, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:b7a1c69a-e180-4d27-b71d-5fcf196d9d2d", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/mam301", "targetArn": "arn:aws:glue:us-east-1:012345678901:database/gluezetl", "level": "INFO", "messageType": "IngestionTableStatistics", "details": { "tableName": "plant", "loadType": "CDC", "insertCount": 300, "updateCount": 8, "deleteCount": 2 } } シナリオ2: Amazon SageMaker lakehouse ターゲットのメトリクス SageMaker lakehouseのzetl_integration_table_stateテーブルは、統合ステータスとデータ変更メトリクスのビューを提供します。この例では、テーブルは、testdbデータベースの統合ID 62b1164f-5b85-45e4-b8db-9aa7ab841e98を持つSAP CDSビューテーブルの成功した統合を示しています。レコードは、タイムスタンプ1733000485999で、10の挿入レコードが処理されたことを示しています（recent_insert_record_count: 10）、更新または削除はありません（両方のカウントは0）。このテーブルは監視ツールとして機能し、統合状態とデータ変更に関する詳細な統計の集中ビューを提供し、lakehouseでのデータ同期アクティビティを追跡および検証することを簡単にします。 +---+--------------------------------------+---------------+----------------------------------------------------------+-----------+--------+-----------------+-------------------------------+------------------------------+------------------------------+------------------------------+ | # | integration_id | target_database | table_name | table_state | reason | last_updated_timestamp | recent_ingestion_record_count | recent_insert_record_count | recent_update_record_count | recent_delete_record_count | +---+--------------------------------------+---------------+----------------------------------------------------------+-----------+--------+-----------------+-------------------------------+------------------------------+------------------------------+------------------------------+ | 2 | 62b1164f-5b85-45e4-b8db-9aa7ab841e98 | testdb | _sap_opu_odata_sap_zcds_po_scl_new_srv_factsofzmmpurordsldex | SUCCEEDED | | 1733000485999 | 10 | 0 | 0 | 0 | +---+--------------------------------------+---------------+----------------------------------------------------------+-----------+--------+-----------------+-------------------------------+------------------------------+------------------------------+------------------------------+ シナリオ3: Redshift用監視システムは、zero-ETL統合ステータスを追跡するために2つのビューを使用 svv_integrationは、統合ステータスの高レベルの概要を提供し、統合ID 03218b8a-9c95-4ec2-81ad-dd4d5398e42aが失敗なしで18のテーブルを正常にレプリケートし、最後のチェックポイントがトランザクションシーケンス1761289852999であったことを示しています。 +--------------------------------------+---------------+-----------+-----------------+-------------+----------------------------------------------+-------------------------+-----------------------+---------------+------------------+-----------------+-----------------+------------------+-----------------+-----------------+ | integration_id | target_database | source | state | current_lag | last_replicated_checkpoint | total_tables_replicated | total_tables_failed | creation_time | refresh_interval | source_database | is_history_mode | query_all_states | truncatecolumns | accept_invchars | +--------------------------------------+---------------+-----------+-----------------+-------------+----------------------------------------------+-------------------------+-----------------------+---------------+------------------+-----------------+-----------------+------------------+-----------------+-----------------+ | 03218b8a-9c95-4ec2-81ad-dd4d5398e42a | test_case | GlueSaaS | CdcRefreshState | 771754 | {"txn_seq":"1761289852999","txn_id":"0"} | 18 | 0 | 22:54.7 | 0 | | FALSE | FALSE | FALSE | FALSE | +--------------------------------------+---------------+-----------+-----------------+-------------+----------------------------------------------+-------------------------+-----------------------+---------------+------------------+-----------------+-----------------+------------------+-----------------+-----------------+ svv_integration_table_stateは、統合内の個々のテーブルのステータスを示すテーブルレベルの監視詳細を提供します。この場合、SAP材料グループテキストエンティティテーブルは同期済み状態にあり、最後のレプリケーションチェックポイントは統合チェックポイント（1761289852999）と一致しています。テーブルは現在0行と0サイズを示しており、新しく作成されたことを示唆しています。 +--------------------------------------+---------------+-------------+--------------------------------------------------------------+-------------+----------------------------------------------+--------+-----------------------+------------+------------+-----------------+ | integration_id | target_database | schema_name | table_name | table_state | table_last_replicated_checkpoint | reason | last_updated_timestamp | table_rows | table_size | is_history_mode | +--------------------------------------+---------------+-------------+--------------------------------------------------------------+-------------+----------------------------------------------+--------+-----------------------+------------+------------+-----------------+ | 03218b8a-9c95-4ec2-81ad-dd4d5398e42a | test_case | public | /sap/opu/odata/sap/ZMATL_GRP_1_SRV/EntityOf0MATL_GRP_1_TEXT | Synced | {"txn_seq":"1761289852999","txn_id":"0"} | | 23:03.8 | 0 | 0 | FALSE | +--------------------------------------+---------------+-------------+--------------------------------------------------------------+-------------+----------------------------------------------+--------+-----------------------+------------+------------+-----------------+ これらのビューは、Amazon Redshiftでの全体的な統合の健全性と個々のテーブル同期ステータスの両方を追跡するための包括的な監視ソリューションを提供します。 前提条件 以下のセクションでは、SAP接続を設定し、その接続を使用してzero-ETL統合を作成するために必要な手順を説明します。このソリューションを実装する前に、以下を準備する必要があります: SAPアカウント 管理者アクセス権を持つAWSアカウント S3 Tablesターゲット を作成し、S3バケットsap_demo_table_bucketをデータベースのロケーションとして関連付ける zero-ETLのData Catalogのきめ細かいアクセス制御のために、以下の IAMポリシー を使用して AWS Glue Data Catalog設定 を更新する zero-ETLがSAPアカウントからデータにアクセスするために使用するIAMロール zero_etl_bulk_demo_role を作成する SAP認証情報を保存するためにAWS Secrets Managerでシークレット zero_etl_bulk_demo_secret を作成する SAPインスタンスへの接続を作成 SAPインスタンスへの接続を設定し、アクセスするデータを提供するには、以下の手順を実行します: AWS Glueコンソールで、ナビゲーションペインのData catalogの下で、Connectionsを選択し、Create Connectionを選択します。 Data sourcesで、SAP ODataを選択し、 Next を選択します。 SAPインスタンスのURLを入力します。 IAM service roleで、ロールzero_etl_bulk_demo_role（前提条件として作成）を選択します。 Authentication Typeで、SAPに使用している認証タイプを選択します。 AWS Secretで、シークレットzero_etl_bulk_demo_secret（前提条件として作成）を選択します。 Nextを選択します。 Nameに、sap_demo_connなどの名前を入力します。 Nextを選択します。 zero-ETL統合を作成 zero-ETL統合を作成するには、以下の手順を実行します: AWS Glueコンソールで、ナビゲーションペインのData catalogの下で、Zero-ETL integrationsを選択し、Create zero-ETL integrationを選択します。 Data sourceで、SAP ODataを選択し、Nextを選択します。 前の手順で作成した接続名とIAMロールを選択します。 統合に含めるSAPオブジェクトを選択します。非ODPオブジェクトは完全ロードまたは増分ロード用に設定され、ODPオブジェクトは増分取り込み用に自動的に設定されます。 完全ロードの場合、Incremental update fieldをNo timestamp field selectedのままにします。 増分ロードの場合、Incremental update fieldの編集アイコンを選択し、タイムスタンプフィールドを選択します。 デルタトークンを提供するODPエンティティの場合、増分更新フィールドは事前に選択されており、ユーザーのアクションは必要ありません。 同じSAP接続とエンティティをデータフィルターで使用して新しい統合を作成する場合、最初の統合とは異なる増分更新フィールドを選択することはできません。 Target detailsで、sap_demo_table_bucket（前提条件として作成）を選択します。 Target IAM roleで、sap_demo_role（前提条件として作成）を選択します。 Nextを選択します。 Integration detailsセクションで、Nameにsap-demo-integrationと入力します。 Nextを選択します。 詳細を確認し、Create and launch integrationを選択します。 新しく作成された統合は、約1分でActiveとして表示されます。 クリーンアップ リソースをクリーンアップするには、以下の手順を実行します。このプロセスは、この記事で作成されたリソースを完全に削除します。続行する前に重要なデータをバックアップしてください。 zero-ETL統合 sap-demo-integration を削除します。 S3 Tablesターゲットバケット sap_demo_table_bucket を削除します。 Data Catalog接続 sap_demo_conn を削除します。 Secrets Managerシークレット zero_etl_bulk_demo_secret を削除します。 まとめ ここまでの手順で、従来のようなETL構築の複雑さなしに、SAPデータ分析を大きく改善できるようになりました。AWS Glue zero-ETLを使用すると、S3 Tables、SageMaker lakehouseアーキテクチャ、Amazon Redshiftに、元の構造を維持しながらデータを連携でき、SAPデータに即座にアクセス可能な環境を構築できます。チームは、コスト効率の高いクラウドストレージにデータを保持しながら、Apache Iceberg のタイムトラベル機能、スキーマ進化、および大規模な同時読み取り/書き込みを備えたACID準拠のストレージを使用できます。Amazon QとSageMaker等のAI機能は、ビジネスがオンデマンドデータ製品を作成し、テキストからSQLへのクエリを実行し、Amazon BedrockとQuick Suiteを使用してAIエージェントをデプロイするのに役立ちます。 詳細については、以下のリソースを参照してください: AWS Glue Documentation Zero-ETL integrations Connecting to SAP OData Amazon SageMaker lakehouse アーキテクチャ Amazon S3 tables をターゲットとして設定する Amazon Q Documentation Amazon Quick Suite Documentation SAPデータ戦略を近代化する準備はできていますか？AWS Glue zero-ETLを探索し、組織のデータ分析機能を強化しましょう。 著者について Shashank Sharma Shashank は、エンタープライズ顧客向けのファーストパーティおよびサードパーティのデータベースとSaaSのデータ統合およびレプリケーションソリューションの提供において15年以上の経験を持つエンジニアリングリーダーです。彼はAWS Glue Zero-ETLとAmazon AppFlowのエンジニアリングをリードしています。 Parth Panchal Parth は、10年以上の開発経験を持つ経験豊富なソフトウェアエンジニアで、AWS Glue zero-ETLとSAPデータ統合ソリューションを専門としています。彼は、複雑なデータレプリケーションの課題に深く取り組み、パフォーマンスと信頼性の高い基準を維持しながらスケーラブルなソリューションを提供することに優れています。 Diego Lombardini Diego は、SAPテクノロジー全体で20年以上の経験を持つ経験豊富なエンタープライズアーキテクトで、SAPイノベーションとデータおよび分析を専門としています。彼はパートナーとユーザーの両方として働いてきたため、システムと組織を販売、実装、運用するために必要なことについて完全な視点を持っています。彼はテクノロジーとイノベーションに情熱を持ち、顧客の成果とビジネス価値の提供に焦点を当てています。 Abhijeet Jangam Abhijeet は、複数の業界にわたる戦略と提供をリードする20年のSAP技術機能経験を持つデータおよびAIリーダーです。数十のSAP実装経験により、彼はアプリケーション開発、データエンジニアリング、統合における深い技術的専門知識とともに、幅広い機能プロセス知識をもたらします。 翻訳： 下佐粉 昭 (AWS Japan ソリューションアーキテクト)

AWS re:Invent の翌週は、イベントのエキサイトメントとエネルギーがますます熱くなる週であり、詳細について学び、最新の発表が課題の解決にどのように役立つかを理解するすばらしい機会です。今回も、 AWS re:Invent 2025 の注目の発表 に関する記事をご用意しました。 すべての技術的発表の中でも私にとってとりわけ印象的だったのは、フィリピンの Rafi (Raphael Francis Quisumbing) が ワーナー ヴォゲルス から Now Go Build 賞を受け取った瞬間でした。2015 年に AWS ヒーローになった Rafi は、2013 年から AWS User Group Philippines の共同主導者を務めています。この地域全体でのコミュニティの構築と開発者のエンパワーメントに対する彼の献身は、この賞の真髄を体現するものです。Rafi の詳細については、 The Kernel をお読みください。おめでとう、Rafi! 基調講演のまとめ: エージェント、ルネサンス、開発者の役割 2025 年の AWS re:Invent の基調講演は、私たちが向かっている方向を明確に示していました。 マット ガーマン は、開発者が「AWS の核心」であり、20 年たった今でも「革新する自由」が AWS の中核的使命であることを強調しました。次の変曲点として AI エージェントに焦点を当てたマットは、「AI アシスタントは、ユーザーに代わってタスクを実行したり自動化したりすることができる AI エージェントへと移行し始めています。こうした移行の中で、AI 投資からの実質的なビジネス利益を目の当たりにし始めています」と述べました。 Swami Sivasubramanian  は、私たちが経験している変革的瞬間を強調し、「何を達成したいのかを自然言語で説明できる、これは歴史上初めてのことです。すると、エージェントがプランを生成します。エージェントがコードを記述し、必要なツールを呼び出して、ソリューション全体を実行するのです」と話しました。 AWS は、信頼性が高く、セキュアでスケーラブルな本番環境対応インフラストラクチャを構築しています。これは、エージェントの非決定的な性質に合わせて構築されたものです。 Peter DeSantis と Dave Brown  は、この AI 時代において、AWS が 20 年にわたってこだわり続けてきたコア属性であるセキュリティ、可用性、パフォーマンス、伸縮性、コスト、俊敏性がこれまで以上に重要であることを強調しました。Dave Brown は、これらの属性を大規模に実現する Graviton と AWS のカスタムシリコンイノベーションを紹介しました。 14 年の歴史に終止符を打ち、最後の基調講演を行った ワーナー ヴォゲルス は、好奇心とシステム思考を持ち、効果的にコミュニケーションを取る開発者を表す「ルネサンス開発者」という概念を紹介しました。AI と開発者の進化に関する彼のメッセージは参加者の共感を呼ぶもので、「AI は私の仕事を奪うのか? そうかもしれません。AI は私を陳腐化するのか? 皆さんが進化するのなら、それは絶対にありません」と述べました。 また、開発者は所有者でなければならないことも強調し、「仕事はあなたのものであり、ツールのものではありません。ツールを作り、所有するのはあなたです」と話しました。 基調講演、イノベーショントーク、ブレイクアウトセッションなどは、 オンデマンド動画ページ でもご覧いただけます。 イノベーショントーク Harnessing analytics for humans and AI (INV201) AI agents in action: Architecting the future of applications (INV202) The agent-enabled workplace: Transforming businesses with AI (INV203) Build and scale AI: from reliable agents to transformative systems (INV204) Reinventing software development with AI agents (INV205) Unlocking possibilities with AWS Compute (INV207) Databases made effortless so agents and developers can change the world (INV208) The next frontier: Building the agentic future of Financial Services (INV209) Infrastructure for the impossible: Turning public sector barriers into breakthroughs (INV210) Behind the curtain: How Amazon’s AI innovations are powered by AWS (INV211) Migrate, modernize, and move your business into the AI era (INV212) The power of cloud network innovation (INV213) Intelligent security: Protection at scale from development to production (INV214) AWS storage beyond data boundaries: Building the data foundation (INV215) ブレイクアウトセッション – トピック ブレイクアウトセッション – 分野 分析 アプリケーション統合 アーキテクチャ AI ビジネスアプリケーション クラウド運用 コンピューティング データベース 開発者ツール エンドユーザーコンピューティング ハイブリッドクラウドとマルチクラウド 業界ソリューション 移行とモダナイズ ネットワークとコンテンツ配信 オープンソース セキュリティとアイデンティティ サーバーレスとコンテナ ストレージ 開発者コミュニティ デジタルネイティブビジネス エンタープライズ 独立系ソフトウェアベンダー AWS 初心者 パートナーイネーブルメント 公共部門 シニアリーダー 中堅・中小企業 スタートアップ 2025 年 11 月 30 日週のリリース 以下に、私が注目したリリースで、 AWS re:Invent 2025 の注目の発表 記事ではまだ取り上げていないものをご紹介します。 Kiro Autonomous Agent – AWS は、11 月にチーム機能とともに一般提供が開始された Kiro を基礎とする自律型エージェントを発表しました。このエージェントは、セッション全体でアウェアネスを維持し、プルリクエストとフィードバックから学習して、複数のリポジトリにまたがるバグトリアージとコードカバレッジの改善に対応します。マット ガーマンは、第 1 世代の AI コーディングツールよりも「桁違いに効率的」だと言っています。現在、Kiro は Amazon 社全体での標準 AI 開発環境として使用されています。 Bedrock ナレッジベースのマルチモーダル検索 (一般提供) – テキスト、画像、音声、動画ファイル全体で機能する AI 駆動の検索アプリケーションや質問回答アプリケーションを構築できます。開発者は、解析、チャンク化、埋め込み、ベクトルストレージのオプションを完全に制御しながらマルチモーダルコンテンツを取り込み、テキストクエリまたは画像クエリを送信して、あらゆるメディアタイプから関連するセグメントを取得できるようになりました。 AWS Interconnect – マルチクラウド (プレビュー) – 専用帯域幅と組み込みのレジリエンスを用いて、Amazon VPC やその他のクラウド環境の間にセキュアかつ高速なプライベート接続をすばやく確立します。このプレビューは Google Cloud を最初のローンチパートナーとして開始され、2026 年には Microsoft Azure のサポートが追加される予定です。 この記事で取り上げられていないその他のリリースニュースについては、 AWS の最新情報 をご覧ください。 今週のニュースは以上です。来週月曜日の次回 Weekly Roundup もお楽しみに! ハッピービルディング! – Donnie この記事は、 Weekly Roundup シリーズ の一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本記事は 2025/11/25 に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 5 – How the service uses clocks を翻訳した記事です。 Amazon Aurora DSQL  は、アクティブ-アクティブの分散データベース設計を採用しており、リージョン内およびリージョン間で、 すべてのデータベースリソースが等しく読み取りと書き込みの両方のトラフィックを処理します。この設計により、 シングルおよびマルチリージョンの Aurora DSQL クラスターにおいて 同期データレプリケーションとデータ損失ゼロの自動フェイルオーバーが 可能になります。 Aurora DSQL に関する5部構成の本シリーズでは、これまでに 基本概念 、 機能と注意点 、Aurora DSQL における トランザクションの動作 、そして 個々のコンポーネント について説明しました。今回の投稿では、Amazon Aurora DSQL が  Amazon Time Sync Service  を使用してどのようにハイブリッド論理クロックソリューションを構築しているのかを探ります。 Aurora DSQL がリージョン内およびリージョン間で広範な調整なしにスケーラブルな方法で動作できる能力は、Amazon Time Sync Service の活用とその上に構築されたハイブリッド論理クロックソリューションの構築によるものです。 分散システムにおけるハイブリッド論理クロックの重要性 物理クロックは直感的で私たちの自然な時間認識に合致していますが、分散システムでは同期に課題があります。一方、 Lamport タイムスタンプ のような論理クロックは因果関係の追跡に優れていますが、実世界のタイミング要件を満たすのに苦労します。 ハイブリッド論理クロック（HLC） は、両方のアプローチの利点を調和させる洗練されたソリューションを提供します。Aurora DSQL では、HLC は次のように動作します： システムは物理クロックと論理クロックの両方のコンポーネントを維持します クロック値は各読み取り操作の前に更新されます 物理クロックがより速いペースで動作する場合（典型的なシナリオ）、論理時間が同期するよう進みます 逆に、物理クロックが遅れている場合、論理時間はおおよそ物理クロックのレートで進行します このハイブリッドアプローチにより、物理的な現実との強い結びつきを維持しながら、時間が後退することがないよう保証されます。 CockroachDB  や  MongoDB  などの他の分散データベースも、時間管理のニーズにハイブリッドクロックを採用しており、Aurora DSQL におけるこのアプローチの関連性を示しています。HLC には以下のようないくつかの利点があります： 一貫性の保証 – クライアントが複数のデータベースノードからデータを読み取る場合、HLC はデータの一貫したビューを保証します。これにより、Aurora DSQL は同期の必要なく複数のリージョンにあるストレージノードから読み取ることができます。 トランザクション管理 – 各トランザクションは開始タイムスタンプとコミットタイムスタンプを受け取り、これらの値に基づいて信頼性の高い競合検出を容易にします。 読み取り専用トランザクションの線形化可能性（linearizability） 実際には、クロック同期は完璧ではありません。現代のシステムはこの現実に対処するために洗練されたエラー境界追跡を採用しています。Amazon EC2 の clockbound API からの時間測定には、現在時刻の推定値、上限エラー境界、下限エラー境界が含まれます。これにより 3 つの時間間隔が区別されます：既知の過去（エラー境界以下）、未知の現在（エラー境界内）、そして既知の未来（エラー境界以上）。QP は上限エラー境界を選択することで、ストレージからリクエストするデータにコミット済みのすべてのトランザクションが含まれることを保証します。これが読み取り専用トランザクションが線形化可能である理由です。これにより、オペレーションがシステム内での並列性なしに、一貫したリアルタイム順序で実行されるように見えることが保証されます。 Amazon Aurora DSQL におけるトランザクションタイミングの理解 Aurora DSQL は、トランザクションタイムスタンプの洗練された処理を通じて強力な一貫性保証を提供しています。システムがどのようにトランザクションタイミングを管理して線形化可能性（linearizability）を確保するか ー つまり、トランザクション B がトランザクション A のコミット後に開始される場合、B はつねに A の変更を見ることができるということ ー を探ってみましょう。この概念は読み書きトランザクションのみを対象に探っていきます。なぜなら、このシリーズの第 3 回で説明したように、読み取り専用トランザクションは論理的な時間がゼロであり、このタイプのトランザクションにはこの概念は必要ないからです。 トランザクションが開始されると、QP は未来にあることが保証されている開始タイムスタンプ（τ-start）を割り当てます。トランザクション内のあらゆる読み取りに対して、このタイムスタンプがストレージに渡され、読み取り操作を実行する前にすべての先行トランザクションが処理されていることを確認します。 トランザクションのコミット中： アジュディケータがコミットタイムスタンプ（τ-commit）を割り当てます。 QP は、ユーザーにコミットを確認する前に、このタイムスタンプが検証可能な過去にあることを確認します。 実際の例 2 つの連続するトランザクション、A と B の流れを見てみましょう： トランザクション A が開始： 開始タイムスタンプ τ3 が割り当てられます このトランザクション内のすべてのアクションは、一貫したビューを確保するためにこのタイムスタンプを使用します コミット時に、タイムスタンプ τ5 を受け取ります システムは、コミットを確認する前に τ5 が検証可能な過去になるまで待機します トランザクション B（A のコミット後）が開始： A のコミットタイムスタンプより大きいことが保証される開始タイムスタンプが割り当てられます これにより B は常にAの変更を見ることができます システムは、クロックの不確実性がタイミングの異常を引き起こす可能性があるシナリオを慎重に管理する必要があります。例えば、トランザクション A が広いタイムスタンプウィンドウを取得し、トランザクション B がより狭いウィンドウを取得した場合、B が A のコミット後に開始したにもかかわらず、B の開始タイムスタンプが A のものより小さくなるリスクがあります。 このような異常を防ぐため、Aurora DSQLは追加のセーフガードを実装しています：QP は、τ-start と τ-commit のタイムスタンプ境界が過去にあることが検証されるまでクライアントへの応答を遅らせます。 トランザクションタイミングに対するこの堅牢なアプローチにより、Aurora DSQL は分散環境で高いパフォーマンスを維持しながら、強力な一貫性保証を提供することができます。 Amazon Time Sync Service を使用したタイミング情報の提供 分散システムにおける時間同期は、特に複数のリージョンにまたがる場合、非常に複雑な問題として知られています。Aurora DSQL はこの課題に対して、 Amazon Time Sync Service を使用することで対処しています。このサービスはすべての EC2 インスタンスからアクセス可能で、GPS 衛星と同期した原子時計を使用してマイクロ秒レベルの精度を実現します。この精度レベルは、グローバルに分散したノード間で強力な一貫性を維持するために不可欠です。論理クロックのみに依存する従来のアプローチやNetwork Time Protocol（NTP）などのプロトコルとは異なり、Aurora DSQL のハイブリッドモデルは因果関係と実世界の整合性の両方を提供します。このイノベーションはトランザクションの整合性を向上させるだけでなく、グローバルな書き込み時のレイテンシーも最小化し、Aurora DSQL を業界内で際立たせています。 ユースケースの可能性 ハイブリッド論理クロックシステムは、複数の業界で Aurora DSQL に新たな可能性をもたらします。例えば、金融機関はトランザクションの保証された線形化可能性の恩恵を受け、正確な監査証跡と規制遵守を確保できます。同様に、複数のリージョンにまたがって運営される e コマースプラットフォームは、一貫した在庫管理とリアルタイムの注文処理のために Aurora DSQL に依存することができます。 まとめ この投稿では、Amazon Aurora DSQL におけるハイブリッドクロックモデルの活用について探りました。このモデルは Amazon Time Sync Service を活用してグローバルな強力な一貫性を保証しています。Aurora DSQL についてさらに詳しく知りたい場合は、AWS re:Invent 2024 の 入門 および 詳細解説 の録画、または Marc Brooker の ブログシリーズ をご参照ください。 Katja-Maja Kroedel Katja  は AWS でデータベースと IoT の熱心なアドボケイトです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、および戦略に関するガイダンスをお客様に提供しています。 翻訳はソリューションアーキテクトの伊津野安梨沙が担当しました。原文は こちら です。

本記事は 2025/11/25 に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 4 – DSQL components を翻訳した記事です。 Amazon Aurora DSQL  は、アクティブ-アクティブの分散データベース設計を採用しており、リージョン内およびリージョン間で、 すべてのデータベースリソースが等しく読み取りと書き込みの両方のトラフィックを処理します。この設計により、 シングルおよびマルチリージョンの Aurora DSQL クラスターにおいて 同期データレプリケーションとデータ損失ゼロの自動フェイルオーバーが 可能になります。 この Aurora DSQL に関するブログシリーズでは、 基本的な概念 を説明し、機能と注意点を探り、 トランザクションの動作 を分析してきました。この記事では、 ACID 準拠で強力な一貫性のあるリレーショナルデータベース機能を提供する、マルチリージョン分散データベースの各コンポーネントとその責務について説明します。 5 部構成の本シリーズの 第 2 回のブログ記事 では、Aurora DSQL の基本的なコンポーネントを示す次の図を紹介しました。この記事では、各コンポーネントをより詳細に見ていきます。主題に関して包括的に理解するために、第 2 回の記事の対応セクションを再確認することをお勧めします。以下の図は、Aurora DSQL 内のデータ処理ワークフローを示すシステムアーキテクチャ図です。 Amazon Aurora DSQL 内のデータ処理ワークフローを示すシステムアーキテクチャ図 クエリプロセッサ（QP）は、SQLの実行ライフサイクル全体を統括します。入力された SQL 文を解析し、実行計画を構築し、実行計画の処理を最適化します。QP はデータの取得を管理し、結果をマージし、クライアントに結果セットを返す前に必要な集計を行います。トランザクション処理中、読み取りセットと書き込みセットの両方を追跡し、トランザクションがコミットまたはロールバックするまで一時的に書き込みをスプールします。トランザクション完了時には（前回の記事で説明したように） 、QP は COMMIT プロトコル全体を調整し、他のシステムコンポーネントとの適切な連携を提供します。 QP は一時的で、ソフトステート特性を持つシェアードナッシングのコンポーネントとして 設計されています。したがって、耐久性、一貫性の強制、同時実行制御、耐障害性、スケールアウト操作などの従来のデータベース機能の多くを担当していません。これらの機能は、Aurora DSQL アーキテクチャ内の他のコンポーネントによって処理されます。インフラストラクチャの観点からは、QP は QP ホスト上の Firecracker マイクロ仮想マシン（microVM）内で動作し、各ホストが複数の QP をサポートしています。各トランザクションは単一の専用 QP によって処理されます。データベースごとに専用の QP プーラーが、接続とアクティブな QP のマッピングを管理し、厳密なデータベース分離を維持しながら効率的なリソース使用を提供します。 Aurora DSQL は、データベースカタログとメタデータに対してのみキャッシングを使用し、データキャッシングを完全に避けるという設計上の決定をしています。データベースは通常、次の3つの主要な課題に対処するためにキャッシュを使用することを考えると、この設計上の決定は直感に反するように見えるかもしれません： メモリアクセスと比較して高いストレージレイテンシー BTree などのデータ構造に対する複数のアクセスポイントの必要性 I/O ラッチによるクラッシュ一貫性を維持する要件 しかし、Aurora DSQL はこれらの課題に異なる方法で対処しています。このアーキテクチャは、QP がロックを保持せずに動作し、ストレージフリートの配置とパフォーマンスが最適化され、ラウンドトリップを最小限に抑えるために処理がプッシュダウンされるなど、いくつかの利点を提供します。この革新的なアプローチにより、キャッシングメカニズムを必要とせずに、あらゆる規模で一貫したパフォーマンスを実現しています。 Aurora DSQL の QP は、単一トランザクション処理モデルで動作します。データウェアハウスシステムとは異なり、クエリは複数のプロセッサに分散されるのではなく、単一の QP 内で実行されます。つまり、すべてのクエリ実行は QP で行われ、遅いクライアントがデータベースを遅くしたり、他のクライアントに影響を与えたりすることはありません（ノイジーネイバー問題はありません）。 アジュディケータ Aurora DSQL のアジュディケータシステムは分散コンポーネントとして機能し、複数のアジュディケータがデータベース全体で責任を共有しています。各アジュディケータは特定のキー範囲を所有しています。このシャーディングアプローチにより、単一のアジュディケータがボトルネックになることはなく、システムが複数のリージョンにわたってスケールすることが可能になります。 アジュディケータは、障害やパーティション発生時に一貫性を維持するために、高度な リースベースのシステム を実装しています。アジュディケーターがキー範囲の責任を引き受ける際、ジャーナルに対してリースを取得し、定期的なハートビートを通じてそれを維持します。このリースシステムにより、任意の時点で任意のキーに対して権限を持つアジュディケータは正確に1つだけとなり、障害シナリオ中の競合する決定を防止します。 これらのメカニズムを通じて、アジュディケータシステムは分散データベースシステムのスケーラビリティと信頼性の要件を維持しながら、堅牢な一貫性保証を提供します。 ジャーナル ジャーナルは Aurora DSQL アーキテクチャにおいて重要なコンポーネントとして機能し、データベースの耐久性の実装を根本的に再構築しています。従来のデータベースではストレージ層が耐久性の責任を担っているのに対し、Aurora DSQL ではこのタスクをジャーナルに委任しています。このアーキテクチャの選択により、機能を分離することでデータベースエンジンが大幅に簡素化されています。トランザクションはジャーナルにコミットされるとコミット済みとみなされ、トランザクション処理と耐久性保証の間に明確な境界を確立します。ジャーナルは単に操作や変更をログに記録するのではなく、トランザクションの包括的なポストイメージを保存します。このアプローチは、より大きなストレージ容量を必要とする一方で、いくつかの利点を提供します： 予測可能な回復操作を容易にします。 ストレージノードの処理を最適化します。 レプリケーション中の計算オーバーヘッドを最小限に抑えます。 ジャーナルは、高いスループットを管理するために複数のジャーナルが並列処理を行う洗練されたスケーリングモデルを採用しています。アジュディケータによって保証される順序のおかげで、トランザクションは利用可能な任意のジャーナルに書き込むことができます。コミットするアジュディケータと同じアベイラビリティーゾーン内のジャーナルを選択することで、パフォーマンスを最適化することができます。 ジャーナルはリカバリ機能を提供するために、 Amazon Simple Storage Service （Amazon S3）にスナップショットのデータを保存します。システムは定期的にスナップショットを取得し、ストレージの完全な状態を記録します。リカバリ時には、システムは最新のスナップショットをロードし、その時点からジャーナルを再生します。このアプローチにより、トランザクション履歴全体を再生することなく 耐久性保証を維持することができます。 クロスバー Aurora DSQL のジャーナルコンポーネントは、システム内の仲介役として機能するクロスバーコンポーネントにトランザクションデータを提供します。クロスバーは複数のジャーナルからのデータを完全に順序付けられたシーケンスにマージし、適切なストレージシャードにデータを配布します。重要なのは、クロスバーが操作を開始する前に、特定のタイムスタンプまですべてのジャーナルが処理を完了するのを待つ必要があることです。 クロスバーは高度なファンアウトメカニズムとして機能し、部分的に順序付けられたシステム内のすべての ジャーナルをサブスクライブして、完全に順序付けられ統合 された トランザクションのストリームを生成します。その主な責任は、キー範囲に基づいて原子的なトランザクションを分解し、各ストレージノードに割り当てられたキー空間に該当するデータのみを受け取るようにすることです。このターゲットを絞った配信により、システム効率が大幅に向上し、冗長なデータ転送が最小限に抑えられます。 クロスバーの主要な機能の1つは、ストレージノードへのデータ配信のタイミングを管理することです。監視するすべてのジャーナルで特定のタイムスタンプを確認した後にデータを転送します。この同期メカニズムは一貫性を提供しますが、潜在的なレイテンシーの課題をもたらします。これに対処するため、システムはすべての関連ジャーナルでデータが利用可能になると進む最低水準（low-water mark）を採用しています。 クロスバーは、 イレイジャーコーディングを使用した 革新的なテールレイテンシー削減アプローチを実装しています。このシステムでは、アジュディケータがメッセージを M 個のセグメントに分割し、元のメッセージは任意の k 個のセグメント（ k は M 以下）から再構築できます。これらのセグメントは複数のジャーナルに分散され、クロスバーは任意のメッセージの k 個のセグメントを受信した後に処理を進めることができます。この設計はスケーラビリティと耐障害性の両方を提供します。 これらのメカニズムを通じて、クロスバーはジャーナルとストレージノード間のデータフローを調整するという複雑なタスクを、一貫性とパフォーマンスを維持しながら管理します。この全体設計は Aurora DSQL のスケーラビリティと信頼性に貢献しています。 ストレージ Aurora DSQL のストレージ層は、データの永続性と取得のための基盤として機能し、従来のデータベースストレージシステムとは大きく異なります。その主な機能は、長期的なデータ耐久性の提供とデータクエリの実行であり、すべて複数のコンポーネントにわたって機能を分離するユニークなアーキテクチャフレームワーク内で行われます。 書き込み操作はシステムを通じて独自の経路をたどり、ジャーナルから始まり、データを適切なシャードに分割するクロスバーを経由します。その後、データはストレージノードに到達し、アプライヤーがそれをストレージシステムに取り込みます。対照的に、読み取り操作はより直接的な経路を採用し、効率性を高めるために中間コンポーネントをバイパスして  QP からストレージに直接流れます。 即時の耐久性（これはジャーナルの担当範囲）を処理する代わりに、ストレージ層は Amazon S3 に保存される定期的なスナップショットを通じて長期的な耐久性に焦点を当てています。これらのスナップショットは複数の重要な機能をサポートします： 障害後の回復 スケーリング操作 インデックスの作成 ポイントインタイムリカバリを含むバックアップと復元機能 ストレージシステムは、水平トリムの概念 （ 古いものから時系列順に処理する）に基づくガベージコレクションメカニズムを実装しており、最大トランザクション時間に対応するアジュディケータの 5 分の最低水準に合わせています。このアプローチにより、各コンポーネントはローカル時間に基づいて独自のガベージコレクションを管理でき、複雑な連携の必要性が排除されます。 ストレージノードの障害が発生した場合、システムはパーティションメンバーを他のストレージノードに再分配し、スナップショットを使用してシステムの状態を復元します。このアプローチは、ジャーナルの短期的な耐久性保証と組み合わさることで、高可用性とデータ耐久性の両方を提供します。 ストレージ層の設計は、Aurora DSQL が同時実行制御などの従来のデータベース機能を特化したコンポーネントに委任しながら、堅牢なデータ管理を重視していることを反映しています。 まとめ この記事では、Amazon Aurora DSQL の個々のコンポーネント、その処理メカニズム、そしてユニークな特徴について紹介しました。さらに、システム内での責任の分散についても説明しました。 次の記事 では、Aurora DSQL 内のクロックの概念について説明します。 Katja-Maja Kroedel Katja は AWS でデータベースと IoT の情熱的なアドボケイトです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、および戦略に関するガイダンスをお客様に提供しています。 翻訳はソリューションアーキテクトの伊津野安梨沙が担当しました。原文は こちら です。

本記事は 2025年6月10日 に公開された「 Connect to Amazon RDS for Db2 using AWS CloudShell | AWS Database Blog 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 インスタンスへの接続は、従来 Amazon Elastic Compute Cloud (Amazon EC2) の踏み台ホストを起動するか、ローカルで Db2 クライアントを実行する必要がありました。新しい AWS CloudShell の Virtual Private Cloud (VPC) 統合環境により、Amazon EC2 不要、ローカルインストール不要、通常の Amazon RDS と AWS ネットワーキング以外のコスト不要で、安全に接続できるようになりました。 この記事では、CloudShell を使用して Amazon RDS for Db2 に接続する方法を紹介します。 ソリューション概要 CloudShell には以下のメリットがあります: ゼロコストクライアント – CloudShell は無料で、標準的なネットワークと Amazon RDS の料金のみ発生します 同一サブネット – CloudShell セッションは VPC 内の RDS データベースと同じ場所に配置されるため、レイテンシーが最小限に抑えられます Amazon EC2 不要 – 踏み台ホストのプロビジョニング、パッチ適用、管理が不要です AWS CLI プリインストール – AWS コマンドラインインターフェイス (AWS CLI) は CloudShell にデフォルトで設定されており、CloudShell はカスタム VPC ネットワーキングを完全にサポートしています このソリューションは以下のステップで構成されています: VPC 内で CloudShell を起動する IBM Data Server Driver シンクライアントをダウンロードしてインストールする プレーンテキスト (TCP/IP) と SSL 接続の両方を設定する IBM の Command line processor plus (CLPPlus) で接続をテストする 前提条件 以下の前提条件が必要です: VPC 内で到達可能な既存の RDS for Db2 インスタンス Db2 ポート (デフォルト TCP 50000+ または SSL 50xxx) へのインバウンドアクセスを許可する VPC サブネットとセキュリティグループ Amazon CloudShell へのアクセス VPC 内で CloudShell を起動する 以下の手順で VPC 内で CloudShell を起動します: AWS マネジメントコンソール にサインインし、メニューバーで CloudShell を選択します。 CloudShell ウィンドウで、 Actions を選択し、 Create VPC Environment を選択します。 Name に名前を入力します (例: PRIVATE )。 VPC で、RDS for Db2 データベースをホストしている VPC を選択します。 Subnet で、Amazon RDS for Db2 インスタンスのアベイラビリティーゾーンのサブネット ID を選択します。 Security group(s) で、TCP および SSL ポートのルールを含む最大 5 つを選択します。 Create を選択します。 CloudShell がプライベートサブネット内で再起動します。 CloudShell セッションは 30 分間非アクティブ状態が続くとタイムアウトします。Db2 クライアントは単一のスクリプトインストールなので、再作成できます。 （訳注：この Blog で紹介するスクリプトによる Db2 クライアントは非永続化領域に導入されるため、スクリプトの再実行が必要となります。） Amazon RDS for Db2 用に AWS CloudShell で Db2 クライアントをインストールする方法 直接実行 curl -sL https://bit.ly/getdb2driver | bash ダウンロードして実行 curl -sL https://bit.ly/getdb2driver -o db2-driver.sh chmod +x db2-driver.sh ./db2-driver.sh 注: 上記の短縮 URL は https://aws-blogs-artifacts-public.s3.us-east-1.amazonaws.com/artifacts/DBBLOG-4900/db2-driver.sh を指しています。 上記のスクリプトは、AWS CloudShell を Amazon RDS for Db2 に接続するための準備を行います。 ツールの出力に表示される 2 つのコマンドを実行する必要があります。 DB2 インスタンスに接続するための DSN 作成プロセスを完了します: db2inst1 ユーザーに切り替えます: sudo su - db2inst1 スクリプトを実行します: source db2-driver.sh スクリプトは db2inst1 ユーザーで実行すると以下を行います: Amazon RDS for Db2 インスタンスを一覧表示し、接続したいインスタンスを選択します RDS for Db2 インスタンス内で検出されたデータベースを db2dsdriver.cfg ファイルにカタログ登録します SSL が有効な場合、スクリプトは各データベースの SSL 接続も db2dsdriver.cfg ファイルに登録します これで、db2 コマンドラインプロセッサを使用して RDSADMIN データベースに接続して管理タスクを実行したり、ユーザー定義データベースに接続して通常の Db2 アクティビティを実行したりできます。 Amazon EC2 インスタンスで同じスクリプトを実行して、Amazon RDS for Db2 インスタンスに接続するための Db2 クライアントをインストールすることもできます。Amazon EC2 を使用する利点は、AWS CloudShell とは異なり、クライアントが永続化されることです。 （訳注：AWS CloudShell では、/home/cloudshell-user ディレクトリ以下は永続化されます。この Blog で紹介するスクリプトは、Db2 クライアントを /home/db2inst1 ディレクトリに導入するため、セッション切断後に削除されます。） トラブルシューティング curl コマンドを実行してスクリプトを直接実行し、スクリプトが何も出力しない場合は、VPC がインターネットアクセス用に適切に設定されていないことを示しています。スクリプトを正常に実行するには、インターネットアクセスが利用可能で、適切な IAM 権限があり、適切なサブネット ID を使用し、Db2 のインバウンドトラフィックが有効になっている適切なセキュリティグループが必要です。 スクリプトを実行するユーザーに適切な IAM 権限がない場合、スクリプトが失敗する可能性があります。以下のコマンドを使用して、スクリプトの実行に必要な権限を確認してください: curl -sL https://bit.ly/getdb2driver | bash -s -- --check-permissions または ./db2-driver.sh --check-permissions Amazon Secrets Manager でマスターユーザーパスワードを使用している場合は、 functions.sh で利用可能な get_master_user_password などのヘルパー関数を使用して、 MASTER_USER_PASSWORD 環境変数を設定できます。スクリプト functions.sh は db2inst1 ユーザー用にインストールされ、利用可能になっています。 Amazon RDS for Db2 データベースへの接続に使用する名前がわからない場合は、 CONN_HELP_README.txt ファイルを参照してください。このファイルには、Amazon RDS for Db2 に接続するための db2 コマンド構文が記載されています。 CloudShell は Amazon RDS for Db2 への迅速な接続を提供します。ただし、フルまたは軽量の Db2 クライアントインストールを使用するアプリケーションサーバーや Amazon EC2 インスタンスに必要な標準 Db2 クライアントの代わりにはなりません。 30 分間の非アクティブタイムアウトが発生した場合は、スクリプトを再度実行して RDS for Db2 データベースをインストールおよび登録し、再接続できます。 ツールの機能強化 このツールのソースコードは GitHub リポジトリ で公開されています。機能強化のリクエストは イシューを作成 するか、変更案を プルリクエストで送信 してください。 まとめ この記事では、わずか数コマンドで CloudShell 内で完全に Db2 コマンドラインプロセッサを Amazon RDS for Db2 に対して実行できることを紹介しました。EC2 インスタンスやローカルインストールは不要で、クリーンなサーバーレススタイルのワークフローを実現できます。ぜひご自身のユースケースでこのソリューションをお試しいただき、コメントでご意見をお聞かせください。また、Amazon EC2 インスタンスで同じスクリプトを複製して、Amazon RDS for Db2 インスタンスに接続するための Db2 クライアントをインストールすることもできます。 著者について Vikram S Khatri は Amazon RDS for Db2 のシニア DBE です。Vikram は Db2 で 20 年以上の経験があります。ゼロから新製品を開発することを楽しんでいます。余暇には瞑想を実践し、ポッドキャストを聴くことを楽しんでいます。 Sumit Kumar は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様が AWS クラウド上でワークロードを構築・設計するのを支援してきました。料理、チェス、家族との時間を楽しんでいます。 Rajib Sarkar は Amazon RDS for Db2 のシニアデータベースエンジニアです。Rajib は Db2 で 20 年以上の経験があります。 Ashish Saraswat は Amazon RDS for Db2 のシニアソフトウェア開発エンジニアです。Ashish は 10 年以上のソフトウェア開発経験があります。 この記事は ソリューションアーキテクト の Hidehiko Yamane が翻訳しました。

本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 3 – Transaction processing を翻訳した記事です。 Amazon Aurora DSQL は、アクティブ-アクティブの分散データベース設計を採用しており、すべてのデータベースリソースが対等であり、リージョン内およびリージョン間の読み取りと書き込みトラフィックの両方に対応します。この設計により、同期データレプリケーションと、単一および複数リージョンのAurora DSQLクラスターに対する自動的なゼロデータ損失フェイルオーバーが可能になります。 このシリーズの3番目の投稿では、Aurora DSQLの2種類のトランザクションタイプ（読み取り専用と読み書き）のエンドツーエンド処理について検証します。Amazon Aurora DSQLには書き込み専用トランザクションはありません。なぜなら、各変更においてテーブルスキーマの確認や主キーの一意性を確保することが不可欠であり、その結果としてこれらも読み書きトランザクションとなるからです。 読み取り専用トランザクション 以下は、読み取り専用トランザクションのデータ処理ワークフローを示すシステムアーキテクチャ図です。 読み取り専用トランザクションのデータ処理ワークフローを示すシステムアーキテクチャ図 トランザクションフローの異なるフェーズをより深く理解するために、トランザクション開始から始まる複数のステップに分けて説明します。 トランザクション開始 : トランザクションプロセスは、クライアントが`START TRANSACTION`または`BEGIN`コマンドを発行することから始まります。フロントエンドは専用のクエリプロセッサ（QP）を割り当てます。このQPは、トランザクションのクエリを解析、計画、実行する専用のマイクロ仮想マシン（VM）です。各トランザクションには独自のQPが割り当てられます。この分離は、各トランザクションが他の同時実行トランザクションからの干渉なく独立して動作することを保証するため重要です。ステートメントを実行する前に、QPは Amazon Time Sync Service を使用して同期された現在時刻を読み取り、トランザクション開始時間τ-startを割り当てます。このタイムスタンプは、トランザクション全体の基準点となり、Auroraの分散アーキテクチャ全体での一貫性維持に重要な役割を果たします。 クエリ実行 : 初期化後、QPはSQLステートメントの包括的な解析を実行することでその主要機能を開始します。このフェーズでは、クエリの構文と意味の両方の正確さを検証し、実行計画を作成します。ストレージからデータを読み取るために、QPはシャードマップを参照して、ストレージノード全体で必要なデータの正確な位置を特定します。 ストレージノードからのデータ取得 : ストレージノードがリクエストを受信すると、各ノードは重要な事前取得チェックを実行します。これらのチェックにより、τ-start以前のタイムスタンプを持つすべてのトランザクションが完全に処理されていることを確認します。必要に応じて、ノードは一貫性保証を維持するための待機メカニズムを実装します。ストレージノードはτ-startタイムスタンプに基づくスナップショット分離を採用しています。このメカニズムにより、すべてのノードがトランザクション開始時点でのデータの一貫したビューを提供することが保証されます。このアプローチは、同時実行トランザクションから生じる可能性のある異常を効果的に防止します。その後、ストレージノードは要求されたデータを返します。データを取得した後、QPは複数のノードからの結果を集約します。Aurora DSQLのアーキテクチャはインタラクティブなトランザクションをサポートし、同じトランザクションコンテキスト内で複数のクエリを実行できるため、単一のトランザクション内でクエリプロセスを複数回繰り返すことができます。システムは、セッション全体を通じて一貫したトランザクション状態を維持し、複数の操作全体で分離保証を保持します。 トランザクションのコミット : 読み取り専用トランザクションでは、Aurora DSQLはコミット時間（τ-commit）をトランザクション開始時間（τ-start）に設定するユニークなコミットメカニズムを実装しています。これにより、論理的な観点からは実質的にゼロ期間のトランザクションが作成され、読み取り専用トランザクションが常に一貫したスナップショットを参照し、競合による失敗が発生しないことが保証されます。 読み取り書き込みトランザクション 以下は、Aurora DSQL内のデータ処理ワークフローを示すシステムアーキテクチャ図です。 Amazon Aurora DSQL内のデータ処理ワークフローを示すシステムアーキテクチャ図 トランザクション開始 : 読み書きトランザクションの初期フェーズは、読み取り専用トランザクションと同様です。 クエリ実行と書き込み処理 : 実行フェーズでは、QPは読み取り専用トランザクションと同様の方法でSQLステートメントを処理します。ただし、読み書きトランザクションでは、変更の処理に追加の複雑さが生じます。書き込み操作が発生すると、QPはこれらのデータベース変更の結果をローカルに保存し、トランザクションの期間中、効果的に書き込みをスプールします。ロールバックや切断が発生した場合、QPはスプールされた書き込みを破棄します。内部的には、Amazon Aurora DSQLでのトランザクションの実行は、同時実行メカニズムに基づいて最適化されています。使用されるMVCCの実装により、早期中止（この概念の詳細は論文 MVCCトランザクション間の競合の修復 の章 3.3.1 書き込み-書き込み競合の処理 で確認できます）が可能になり、コミット時に失敗する可能性のある読み書きトランザクションに対応します。QPがストレージから読み取る際、ストレージはデータの最新バージョンを参照しているかどうかを示します。トランザクションがすでに新しいバージョンを持つ行を更新しようとすると、トランザクションは即座に中止されます。 コミット処理 : コミット時に、QPはシャードマップを参照して、変更したキーを所有するアジュディケータを特定します。QPは書き込みセットを構築し、書き込んだ行（新しく作成された行を含む場合もあります）を含め、それらをポストイメージとともにパッケージ化してアジュディケータに送信します。最後に、この完全な書き込みセットを指定されたアジュディケータに送信します。 裁定フェーズ : 各アジュディケータは、トランザクションの開始時間（τ-start）以降に変更された行に書き込みが発生したかどうかを検証します。いずれかのアジュディケータによって競合が検出された場合、コミットは拒否されます。競合が検出されない場合、アジュディケータはコミットフェーズ中に影響を受ける行に対してロックを配置し、排他的アクセスを確保します。これらのロックは、現在のトランザクションが完了するまで他のトランザクションが同じデータを変更することを防止し、コミットされる更新の整合性を保護します。さらに、アジュディケータはτ-startを超え、以前に発行されたτ-commit値よりも大きいコミットタイムスタンプ（τ-commit）を選択します。ポストイメージとタイムスタンプはジャーナルに書き込まれます。ジャーナルがこれらの変更を確認した後、QPはクライアントにそれらを確認応答します。クライアントの観点からはトランザクションは終了しています。DSQLの観点からは、その内容をストレージノードに書き込む必要があります。 ストレージ更新フェーズ : クロスバーコンポーネントはジャーナルからトランザクションの書き込みを受け取り、キースペースの購読部分に基づいて関連する行を適切なストレージノードに転送します。これらのストレージノードはその後、変更を永続化します。 コミットフェーズの動作 データベース内のキースペースはシャード化され、アジュディケータ間で分散されており、アジュディケータの数はキースペースのサイズに比例してスケールします。その結果、各キーはグローバルに見て正確に1つのアジュディケータによって所有されています。読み書きトランザクションのコミット中、各アジュディケータは自身のキースペースがコミット可能かどうかを独立して判断し、その後、同じトランザクションに関与する他のアジュディケータと連携します。ジャーナルへのコミットの書き込みにより、コミットは成功し、永続的に保存されます。逆に、コミットが失敗した場合、関与するすべてのアジュディケータは中止する必要があります。 コミットアルゴリズムについて、このサービスは 2フェーズコミット と ワープスタイルコミット のハイブリッドアプローチを使用して、不要な往復時間を最小化しています。これは以下の図に示されています： アジュディケータが使用するコミットアルゴリズム Aurora DSQLでトランザクションをコミットすると、舞台裏では次のようなことが起こります： QPがトランザクションを担当し、変更されるデータに基づいて、どのアジュディケータが関与する必要があるかを決定します。 次に、関与するアジュディケータのうち1つを除くすべてに対して並行してPREPAREメッセージを送信します。これらのアジュディケータはトランザクションをコミットできるかどうかを確認し、指定された最終アジュディケータに応答を送信します。 最終アジュディケータは意思決定者として機能します：QPからのトランザクションデータと他のアジュディケータからの応答の両方を受け取ります。関与するすべてのアジュディケータによって競合が検出されなかった場合、トランザクションをコミットします。いずれかのアジュディケータが問題を報告した場合、トランザクションを中止し、全員に通知します。 このプロセスは効率的に設計されています – データは一度送信され、応答はシステムを通じて流れ、コミットの決定とリージョン間のデータレプリケーションの両方を1回のパスで処理します。この連携アプローチにより、分散トランザクションはシステム全体で一貫性を維持しながら、不要な往復通信を最小限に抑えることができます。 Amazon Aurora DSQL での SELECT FOR UPDATE の動作 SELECT FOR UPDATE はAmazon Aurora DSQLにおける特殊なSQLステートメントです。読み書きトランザクションでは、Aurora DSQLが読み取りレコードに対して同時実行チェックを実行しないため、 書き込みスキュー を管理するために SELECT FOR UPDATE を利用できます。詳細、例、これらのクエリの処理方法については、 Amazon Aurora DSQLにおける同時実行制御 をご覧ください。 まとめ この投稿では、Amazon Aurora DSQL内のトランザクション管理の複雑さについて探求しました。コミット処理の内部メカニズムを調査しました。 次回の投稿 では、Aurora DSQLを構成するコンポーネント（QP、アジュディケータ、ジャーナル、クロスバー、ストレージ）について包括的な分析を提供します。 著者について Katja-Maja Kroedel Katja はAWSでデータベースとIoTに情熱を持つアドボケイトです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと、IoTおよびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、戦略について顧客にガイダンスを提供しています。 翻訳はクラウドサポートエンジニアの新巻が担当しました。原文は こちら です。

本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 2 – Shallow view を翻訳した記事です。 このブログ記事シリーズ では基本的なデータベースの概念と、それらが  Amazon Aurora DSQL  にどのように適用されるかの概要から始めました。 この第2回の記事では、Aurora DSQL のアーキテクチャを検証し、その設計判断が機能（楽観的ロックや PostgreSQL の機能サポートなど）にどのような影響を与えるかを説明し、アプリケーションとの互換性を評価できるようにします。ユーザーから完全に抽象化されている基盤アーキテクチャの包括的な概要を提供します。リージョンエンドポイントのみを介して操作することで、ユーザーはサービスの機能に直接アクセスできます。サービスのアーキテクチャを理解することで、その潜在能力を戦略的に活用できるようになると私は確信しています。 サービス概要 Aurora DSQL は、 オンライントランザクション処理 （OLTP）ワークロード向けに特別に設計された最新のサーバーレス分散型 SQL データベースです。PostgreSQL 互換性を念頭に置いて構築され、 その機能のサブセット を提供し、リージョン内およびリージョン間の両方で読み取りと書き込みトラフィックを処理できるピアとして、すべてのデータベースリソースが機能するアクティブ-アクティブデプロイメントモデルを採用しています。また、このサービスは実際のリソース消費量とデータストレージ要件に基づく 従量課金制の価格モデル を採用しています。 このサービスは、 同期データレプリケーション により、単一リージョンおよびマルチリージョンクラスターの両方でデータ損失ゼロを実現し、読み取りに対して書き込み後の 強い 読み取り一貫性を提供します。 次の図は、Aurora DSQL インフラストラクチャの高レベルな概要を示しており、単一リージョン（左）とウィットネスリージョンを持つマルチリージョン（右）の同期クラスターのスケーラビリティを示しています。 単一リージョンおよびウィットネスリージョンを持つマルチリージョン同期クラスターのスケーラビリティを示す Aurora DSQL インフラストラクチャの大まかな概要 単一リージョン構成では、コンピュート、トランザクションログ、ストレージの各層が3つのアベイラビリティーゾーンに分散配置された多層処理モデルで構成されており、高可用性を実現しています。アプリケーションは専用のエンドポイント経由でアクセスします。 マルチリージョン構成では、それぞれが単一リージョン構成と同じインフラストラクチャを持つ2つの同期リージョンに加え、ウィットネスリージョンと呼ばれる第3のリージョンで構成されています。ウィットネスリージョンは、トランザクションの合意形成に参加し、ネットワーク障害時におけるタイブレーカーとして機能します。 Aurora DSQL は、単一リージョン構成で 99.99% の可用性を提供し、マルチリージョン構成ではさらに高い可用性（99.999%）を実現できます。この高い信頼性を活用するためには単にサービスを複数のリージョンで稼働させるだけでは不十分で、アプリケーションが必要に応じて自動的にリージョン間を切り替えるよう設計されている必要があります。つまり、1つのリージョンで問題が発生した場合、アプリケーションは自動的に正常なリージョンに接続できることが重要です。これは非常用電源を持つのと似たような考え方で、複数の電源を用意するだけでなく、正常な電源への自動切り替え機能があってこそ真価を発揮します。この設計アプローチによって、1つのリージョンの障害が他に波及する相関障害を防ぎ、アプリケーションが稼働中のリージョンに接続できる限りサービス全体の停止を回避することが可能です。 Aurora DSQL の読み取り処理は実行元のリージョン内で完結するため、リージョン間のレイテンシーは完全に排除されます。書き込み処理では、コミット時にのみリージョン間レイテンシーが発生します。運用面では、Aurora DSQL はデータベース管理の簡素化とスケーラビリティ向上において複数のメリットを提供します。このアーキテクチャによって、コンピュート・コミット・ストレージの各層を独立してスケールできるため、ワークロードの要求に応じた精密なリソース配分が可能となります。これらの処理はすべてバックグラウンドで自動実行され、AWS が完全に管理するため、真のサーバーレス体験を実現しています。結果として、メンテナンスウィンドウが不要となり、運用負荷の軽減とシステムの可用性が向上します。 Aurora DSQL は他の AWS サービスと深く統合されており、アクセス制御のための  AWS Identity and Access Management （IAM）や監査ログのための  AWS CloudTrail  などのサービスとの連携を容易にします。 Aurora DSQL アーキテクチャ Aurora DSQL は、 Firecracker 仮想化 など、多数の Amazon のイノベーションを活用した新しい分散データベースシステムです。DSQL の設計では、コンピュートやストレージなどの単一インスタンスデータベースコンポーネントを、厳密に定義された仕様によって連携を確保しつつ、特定のタスクに集中できる疎結合なマルチテナントフリートとして再構築することで複雑さを削減しています。各コンポーネントは、それぞれのドメインにとって最適な設計判断を行います。これは次の3つの基本的な特性に沿っています： 各コンポーネントが独立して変更と改善を行う コンポーネントは個別にスケールする 各コンポーネントに対して異なるセキュリティ分離の決定が行われる Amazon Aurora DSQL の最も重要なコンポーネントは次の通りです： クエリプロセッサ （QP）は各接続専用の PostgreSQL エンジンとして機能し、SQL の処理のほとんどをローカルで処理し、読み取りに応じてデータを返し、トランザクションがコミットされるまで書き込みデータをスプールします。 アジュディケータ は読み書きトランザクションがコミットされるかどうかを決定し、分離を確保するために他のアジュディケータと通信します。 ジャーナル はコミットされたトランザクションを永続化し、アベイラビリティゾーン間、マルチリージョン構成ではリージョン間で、データを複製する順序付けられたデータストリームです。 クロスバー はジャーナルからのデータストリームをマージし、ストレージにルーティングします。 ストレージノード はデータへのアクセスを提供し、シャードキーに基づいてデータを保存します。また、データの複数の読み取りレプリカも含んでいます。 以下の図は、書き込みパス（実線）と読み取りパス（点線）を明確に示し、異なるアクセスパターンに対してシステムが最適化できる能力を強調しています。 Amazon Aurora DSQL 内のデータ処理ワークフローを示すシステムアーキテクチャ図 フロントエンド はトランザクションとセッションのルーターとして機能し、各接続を独自のクエリプロセッサにルーティングします。QP は SQL クエリを実行し、読み取りに応じて対応するデータを返す責任があり、時間ベースの分離と調整を通じて一貫した処理を提供するために メトロノーム （タイミングコンポーネント）と連携します。QP はローカルの シャードマップ を参照して、どのキーがストレージ（読み取り用）とアジュディケータ（読み書きトランザクションのコミット用）のどこに配置されているかを判断します。また、書き込みに応じてデータをバッファし、トランザクションプロトコルを管理します。Amazon Aurora DSQL のトランザクションは 最大300秒 （ハード制限）で、この期間を超えるトランザクションは拒否されます。特筆すべきは、QP が他の QP と通信することはなく、ディスクページではなく行を要求することです。Amazon Aurora DSQL は、パフォーマンス向上と QP に戻るデータ通信を削減するために述語をストレージにプッシュダウンします。これは、フィルタリング、集約、射影などの重要な処理の多くがストレージレイヤーで実行されることを意味します。各トランザクションは独自の QP を受け取り、水平方向にスケーリングが可能になり、各トランザクションが他のトランザクションに影響を与えたり、影響を受けたりすることなく独自のコンピュートリソースを確保できます。Aurora DSQL 内のコンピュートスタックは QP のみで構成されています。 コミット時に、QP はトランザクションをアジュディケータに提出し、アジュディケータは楽観的同時実行制御プロトコルを実行します。アジュディケータは特定のキー範囲を割り当てられ、複数のキーセットに影響するトランザクションについてピアと調整します。彼らはトランザクションが自分のシャード内でコミットできるかどうかを判断し、必要に応じて協力します。マルチリージョンクラスターでは、アジュディケータはすべてのリージョン間で競合する書き込みを検出します。このアプローチは楽観的同時実行制御を使用し、検証フェーズまでロックを取得せずにトランザクションを進行させます。これは分散システム全体でのデータ一貫性を維持しながら、同時操作を管理します。トランザクションの終わりに競合をチェックすることで、この方法はダーティリードやロストアップデートなどの問題を防ぎ、競合がまれなシナリオに特に適しています。 ジャーナルはコミットされたトランザクションを永続化する順序付けられたデータストリームであり、クライアントに書き込みを確認します。Amazon Aurora DSQL 内のコミットスタックはアジュディケータとジャーナルで構成され、各ジャーナルは単一のアジュディケータに排他的に関連付けられています。 クロスバーはジャーナルストリームを時系列順にマージし（ジャーナルがトランザクション順にコミットを保存するのとは対照的に）、ストレージに書き込みを発行します。 ストレージは複数のストレージノードで構成され、データは主キーに基づくレンジパーティショニングによってノード間に分散されています。ストレージノードは読み取りを提供するために存在し、短期的な耐久性については責任を負いません。ストレージは、ノード上のキーに対する大量の読み取りリクエストに対応するため、そのノードの読み取り専用レプリカを作成する場合があります。 アーキテクチャに基づく Aurora DSQL のメリット概要 以下は、この分散アーキテクチャを通じて得られるメリットの概要です（完全なリストではありません）： Aurora DSQL は、同期データレプリケーション、スナップショット分離、アトミック性、アベイラビリティーゾーン間およびリージョン間の耐久性により、強力な一貫性を持つ 原子性、一貫性、独立性、永続性（ACID）トランザクション を提供します。 Aurora DSQL は snapshot isolation とロックフリーの同時実行制御を実装しています。このアプローチの主な利点の1つは、読み取り専用トランザクションが強力な一貫性を維持しながらも、アベイラビリティーゾーン間やリージョン間のレイテンシーを発生させないことです。 書き込みトランザクションは、コミット時にリージョン間レイテンシーの往復時間（RTT）を2回発生させます。レイテンシーはステートメントごとではなくトランザクションごとに発生するため、ステートメントの数は関係ありません。 コミット前に発生するすべての処理は QP 内でローカルに行われ、各接続が専用のQPリソースを持つことで、処理の遅いクライアントが他のクライアントに影響を与えることはありません。 Aurora DSQL 内の各コンポーネントは、それぞれが受け取る個別のタスクに特化して設計されており、各コンポーネントが独立してスケールし、個別にシャーディングすることができます。これによってデータベースはさまざまな読み取り/書き込み、コンピューティング-読み取り、コンピューティング-読み取りの比率に対して動的に適応します。 コンポーネントは独立してデプロイされ、複数のステートレスホストに分散されています。必要に応じてホスト間で移動を行うため、顧客に影響を与えず、メンテナンスウィンドウを必要としません。 Aurora DSQL を使用する際の考慮事項 Aurora DSQL は PostgreSQL 互換の分散データベースで、事実上無制限のスケールと高可用性を提供します。PostgreSQL 互換ではありますが、Aurora DSQL は現在 PostgreSQL で利用可能なすべての機能を提供しているわけではありません。この機能差異は時間と共に解消されていく予定ですが、Aurora DSQL の分散アーキテクチャの特性上、一部の機能は異なる実装となります。サポートされている PostgreSQL 機能セットについては、 Aurora DSQLのドキュメント で透明性をもって公開されており、アプリケーション要件との適合性を事前に確認することができます。その結果、PostgreSQL の実績ある基盤と先進的な分散コンピューティング機能を組み合わせたデータベースが提供され、アプリケーションの将来の成長とスケール要求に対応できます。 Aurora DSQL のためにワークロードを設計する際は、以下の要素を考慮してください（完全なリストではありません）： Aurora DSQL は楽観的同時実行制御のため、ロックを実装していません。アプリケーションが明示的なデータベースロックを実装するロジックに依存している場合、アプリケーションの一部を再構築する必要があるかもしれません。詳細については、 Amazon Aurora DSQL の同時実行制御 を参照してください。 このサービスは3つ以上の読み書きエンドポイントを持つマルチリージョン構成をサポートしていません。つまり、3つ以上のリージョンでデータを同期的に複製する必要があるユースケースをサポートしていません。 Aurora DSQL は、2つの重要な設計原則に従うことで最も効果を発揮します：ホットキー書き込みとホットキー範囲の回避です。Amazon Aurora DSQL ではテーブルにランダムな主キーを定義することが理想的です。これは UUID に基づく単一キーか、または複数の列を組み合わせた高いカーディナリティを持つ複合キーを意味します。 楽観的同時実行制御を採用しているため、複数のトランザクションが同時に同じデータを変更しようとする場合（ホットキーの書き込み）、1つが成功し、他は再試行しなければならないことを意味します。 同様に、特定のキー範囲内に操作を集中すること（ホットキー範囲）は、DSQL の分散アーキテクチャが損なうことになります。 マルチリージョン構成で読み書き操作の強力な一貫性を保証するため（読み取り専用操作は対象外）、Aurora DSQL はコミット時に2往復分（2 RTT）の追加レイテンシーが発生します。このレイテンシーは選択した2つのリージョン間の物理的距離に比例して増加します。 これらの原則に沿って設計することで、Aurora DSQL の大きなメリットを最大限に活用でき、 データ要件の拡大に対応した成長と安定したパフォーマンスを実現する基盤を築くことができます。 まとめ この投稿では、Amazon Aurora DSQL のアーキテクチャと、そのアーキテクチャへの貢献、メリット、およびサービスを使用する上での考慮事項について探りました。 次回の投稿 では、Aurora DSQL のエンドツーエンドのトランザクション処理機能について詳しく掘り下げていきます。 著者について Katja-Maja Kroedel Katja  は AWS でデータベースと IoT の熱心なアドボケートです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、戦略について顧客にガイダンスを提供しています。 翻訳はソリューションアーキテクトの 永末 健太 が担当しました。原文は こちら です。

本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 1 – Setting the scene を翻訳した記事です。 2014年に発表された  Amazon Aurora  は、高性能な商用データベースのスピードと可用性、オープンソースデータベースのシンプルさとコスト効率を組み合わせたリレーショナルデータベースエンジンで、MySQL と PostgreSQL との互換性や強化されたパフォーマンスを提供しています。re:Invent 2024 において、AWS はさらに顧客中心のイノベーションを進め、 Amazon Aurora DSQL  を発表しました—これはクラウドベースの設計でトランザクション処理に最適化された新しいサーバーレス SQL データベースです。このブログ投稿シリーズでは、Aurora DSQL の技術的詳細を共有し、基盤となるコンポーネントとサービス開発全体で行われた設計上の選択について深く掘り下げていきます。 この投稿では、Aurora DSQL のメリット、機能セット、および基盤となるコンポーネントを理解するために重要な基本概念について詳しく説明します。 Amazon Aurora DSQL  は、マルチリージョン、アクティブ-アクティブ、分散データベースエンジンを実装し、データベースクラスターのすべてのリージョンで読み取りと書き込みのワークロードの両方を容易にします。このサービスはサーバーレスかつ  PostgreSQL 互換  であり、その機能のサブセットを提供しています。あなたが消費するリソースと保存するデータの量に応じて 課金 されます。 クラウドにおける可用性と耐久性 クラウドサービスは、確実性、パフォーマンス、そして信頼性を確保するために、可用性と耐久性といった重要な指標に依存しています。可用性とは、システムやデータへのアクセスのしやすさを指し、多くの場合、稼働率の割合として測定されます。例えば、可用性が 99.99% のデータベースは、年間のダウンタイムが1時間未満となります。耐久性は、データの損失や破損なしに長期的なデータ保存を保証します。 Amazon Web Services (AWS)  では、顧客がインフラストラクチャ管理ではなくイノベーションに集中できるよう、サービスは高可用性と高耐久性を念頭に置いて設計されています。Aurora DSQL は、マルチリージョン構成で 99.999% の可用性を持つサービスレベルアグリーメント（SLA）を提供し、これは 年間5分16秒の許容ダウンタイム に相当します。また、複数のリージョンにデータを保存することでデータの耐久性を提供し、コミットが成功した後にデータが失われないことを保証します。 可用性と耐久性はクラウドサービスにとって不可欠ですが、最適なパフォーマンスを得るためには、データベースが処理するように設計された特定のワークロードのタイプを理解することも同様に重要です。これにより、 オンライントランザクション処理 （OLTP）と オンライン分析処理 （OLAP）システムの 違い について考える必要があります。 OLTP と OLAP OLTP は、高速なクエリ処理による大量の日常的なトランザクション処理に優れています。例えば、顧客の注文を処理する e コマースプラットフォームは、通常 OLTP データベースに依存しています。対照的に、OLAP は複雑なクエリとデータ分析に最適化されており、チームが膨大なデータセットを分析して実用的な洞察を導き出すビジネスインテリジェンス（BI）アプリケーションに理想的です。Aurora DSQL は OLTP ワークロード向けに設計されています。 可用性と耐久性というこれらの基本的な指標を超えて、データベースシステムの成功は、特に OLTP と OLAP の操作 観点から、特定のタイプのワークロードをどれだけうまく処理できるかにも大きく依存しています。 ACID 原子性、一貫性、独立性、永続性（ACID）は、データベースがトランザクションにおけるデータの整合性と信頼性を維持するために必要な一連の特性です。 原子性（Atomicity） は、トランザクションが単一の単位として扱われ、完全に成功するか失敗するかのいずれかになることを保証します。 一貫性（Consistency） は、トランザクションがデータベースを一つの有効な状態から別の有効な状態へ移行させることを意味します。この概念は、書き込み後の読み取り整合性などの他の一貫性モデルとは異なります。後者では「一貫性」とは、クライアントが書き込んだデータを読み取ることへの期待を指し、データベースの状態自体を指すものではありません。 独立性（Isolation） は、並行トランザクションが逐次実行と同じ効果を持つことを保証します。 永続性（Durability） は、コミットされた変更が失われないことを保証します。 Aurora DSQL はインタラクティブな ACID 準拠のトランザクションを提供します。「インタラクティブ」とは、トランザクションを開始し、データを要求、取得し、追加のコードを実行できることを意味します。これらの原則、特に独立性の実装には、高度な同時実行制御メカニズムが必要です。 トランザクション分離レベル トランザクション分離レベルは、1つのトランザクションによって行われた変更が他のトランザクションにどのように見えるかを定義します。標準的な分離レベルには以下が含まれます： Read uncommitted  – トランザクションがまだコミットされていないデータを読み取ることを許可します。 Read committed  – トランザクションがコミットされたデータのみを読み取ることを保証しますが、 ノンリピータブルリード や ファントムリード の可能性があります。ファントムリードは、トランザクションが特定の条件に基づいて行のセットを取得したが、トランザクションが完了する前に、別のトランザクションがその条件に影響する行を挿入または削除した場合に発生します。例えば、トランザクション A が今日の注文をすべてカウントするクエリを実行し、その後トランザクション B が新しい注文を追加してコミットした場合、トランザクション A がカウントクエリを再度実行すると、この新しい「ファントム」行が表示されます。 Repeatable read  – トランザクションが行を読み取ると、同じトランザクション内の後続の読み取りで同じデータを取得することを保証し、ノンリピータブルリードを防止しますが、ファントムリードは依然として許可されます。これは、個々の行にロックをかけますが、新しい行が挿入される可能性のある「ギャップ」をロックしないためです。 Snapshot isolation  – トランザクションに対して、トランザクション開始時点のデータベースの一貫したスナップショットを表示することを許可し、完全な直列化のオーバーヘッドなしに、ダーティリード、ノンリピータブルリード、およびファントムリードを防止します。その背後にある概念は、トランザクション T の開始時間とコミット時間の間にタイムスタンプを持つ T の 書き込みセット に書き込みが受け入れられていない場合、トランザクション T はコミットするというものです。言い換えれば、現在のトランザクションが書き込もうとしている行に変更が加えられている場合、トランザクションは中止されます。 Serializable  – トランザクションを一つずつ実行することで最高の分離レベルを提供し、ダーティリード、ノンリピータブルリード、およびファントムリードを防止します。その背後にある概念は、トランザクション T の開始時間とコミット時間の間にタイムスタンプを持つ T の 読み取りセット に書き込みが受け入れられていない場合、トランザクション T はコミットするというものです。言い換えれば、現在のトランザクションが読み取っている行が変更されている場合、トランザクションは中止されます。 Amazon Aurora DSQL は snapshot isolation レベルで動作しており、トランザクションタイプレベルでの説明は 後のブログ記事 で説明します。 同時実行制御 現代のデータベースはしばしば、より洗練された同時実行制御 メカニズムを実装しており、 マルチバージョン同時実行制御（MVCC） は最も広く採用されているソリューションの1つです。 MVCC はデータベースにおいて、データへの同時アクセスと変更を管理するために使用される技術です。MVCC はデータの異なるバージョンを作成することでロックの必要性を減らし、読み取り側と書き込み側が互いにブロックすることなく同時に操作できるようにします。PostgreSQL では、各行の複数のバージョンを維持することでこれを実現しており、各バージョンには作成（xmin）と削除または更新（xmax）を担当するトランザクションを記録する隠しシステムカラムが含まれています。トランザクションがデータを更新すると、元のバージョンを保持しながら行の新しいバージョンを作成します。これは、古いバージョンに xmax 値をマークし、新しい行は新しい xmin（古いバージョンのxmaxと一致）を取得し、この新しいエントリには xmax 値が設定されないことで行われます。他のトランザクションがデータを読み取る際、これらのトランザクション ID によって決定される開始時に有効だったバージョンを表示し、進行中のトランザクションによって行われた変更は無視されます。これにより、ブロックなしで同時に読み取りと書き込みが可能になり、バックグラウンドプロセスが最終的にどのトランザクションからもアクセスできなくなった古いバージョンの行を削除します。 Amazon Aurora DSQL も MVCC を使用しており、データベース内に複数のデータバージョンを格納することを意味します。 MVCC の実装では、データベースは同時変更を処理するために、悲観的ロックスキームと楽観的ロックスキームという異なる高レベルのアプローチを採用しています：悲観的同時実行制御は、競合を防ぐためにリソースを事前にロックし、現在のトランザクション内ですでに変更またはロックされたデータを同時実行トランザクションによって変更できないようにします。しかし、このアプローチは過剰なリソースロックによりパフォーマンスのボトルネックを引き起こす可能性があります。対照的に、楽観的同時実行制御は競合が稀であると仮定し、トランザクションコミット時にそれらをチェックします。これは3つのフェーズで構成されます： クライアントからのすべての SQL 文が処理され、すべての書き込みはトランザクション内でローカルに記録されます。 クライアントのコミット時に、データベースはトランザクションの読み取りと変更を評価して、コミット能力を判断します。2つの検証方法が可能です：前方検証と後方検証。 前方検証は、現在進行中のトランザクションとの競合をチェックします。 後方検証は、以前にコミットされたトランザクションとの競合をチェックします。 その後、変更はストレージに書き込まれます。競合が検出されなければ、変更はストレージに書き込まれ、そうでなければ中止されます Amazon Aurora DSQL と標準 PostgreSQL はどちらも MVCC を使用していますが、ロックに対するアプローチが異なります。Amazon Aurora DSQL は後方検証による楽観的同時実行制御を採用しているのに対し、標準 PostgreSQL は悲観的アプローチを使用しています。 まとめ この投稿では、基本的なデータベース概念と Amazon Aurora DSQL への適用について探索し、サービスの予備的な概要を提供しました。Aurora DSQL はマルチリージョン構成で 99.999% の可用性を持つサービスレベルアグリーメント（SLA）を提供し、インタラクティブな ACID 準拠のトランザクションを提供し、楽観的同時実行制御を伴う MVCC を使用しながら snapshot isolation  レベルで動作しています。 このシリーズの次の投稿 では、サービス自体の包括的な理解、その利点と制限、および基盤となるアーキテクチャについて説明します。 著者について Katja-Maja Kroedel Katja  は AWS でデータベースと IoT の情熱的なアドボケイトです。彼女は顧客がクラウドテクノロジーの可能性を最大限に活用できるよう支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、および戦略に関するガイダンスを顧客に提供するために働いています。 翻訳はソリューションアーキテクトの 永末 健太 が担当しました。原文は こちら です。

はじめに 株式会社カプコン（以下、カプコン）は、学生を対象としたゲーム開発コンペティション『CAPCOM GAMES COMPETITION』を開催しました。 このイベントでは、PLATINUM SPONSOR である Amazon Web Services (AWS) のクラウドサービスを活用し、カプコンの独自ゲームエンジン『RE ENGINE』を AWS クラウド上で提供することにより、本格的なゲーム開発に取り組む環境を実現しました。 本記事では、AWS がどのようにこのコンペティションを⽀えているかについて、技術的な詳細とともにご紹介します。 図1: CAPCOM GAME COMPETITION ロゴ イベント概要 カプコンは 2025 年 4 月から 9 月にかけて 『CAPCOM GAMES COMPETITION』 を開催しました。 このコンペティションでは参加者が自由に環境を選択できる従来の形式とは異なり、『RE ENGINE』 の使用を必須としました。これはAAAタイトル開発で実績のある『RE ENGINE』でのゲーム制作を、より多くの学生に体験していただくことで、世界水準で活躍できる若手クリエイターの早期創出を目指したものです。一般公開されていない『RE ENGINE』をゲーム制作に活用できる貴重な体験と、半年間の制作期間の間カプコンスタッフによる専門的な技術サポートを受けられるという点が、参加者にとって大きな魅力となり多数の参加応募がありましたが、最終的にその中から選抜された15チームが参加することになりました。 AWS はこのコンペティションにおいて技術的なサポートを包括的に提供し、カプコンはこれを活用して200名以上の学生が、場所を問わず高性能な開発環境にアクセスできる体制を実現しました。 また、AWSのクラウド技術を活用することで、従来は大規模な設備投資が必要だったゲーム開発環境を柔軟かつスケーラブルに提供することが可能となり、次世代のゲーム開発者育成に大きく貢献しています。 アーキテクチャ システム全体像 今回のアーキテクチャは、前年の 近畿⼤学での実習 をベースに、15 チームが同時利⽤できる設計に拡張しています。AWS のクラウドサービスを活⽤することで、セキュアで⾼性能、かつ⼤規模なゲーム開発環境を実現しました。 図2: CAPCOM GAMES COMPETITION 全体アーキテクチャ図 ネットワーク構成 15 チームが異なる拠点から安全にアクセスできるよう、 Amazon Virtual Private Cloud (VPC) を学⽣環境⽤ VPC および共通基盤⽤ VPC の 2 つに分けています。 共通基盤⽤ VPC には、学⽣が利⽤する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動・停⽌するウェブアプリケーション、バージョン管理データを保存する Perforce サーバー、アセットを保存する NAS サーバーなどの共有サービスをホスティングしています。⼀⽅、学⽣が直接利⽤する 『RE ENGINE』 端末は、学⽣環境⽤ VPC に配置しています。 学⽣は、まず⾃分の PC から AWS Client VPN を利⽤して学⽣環境⽤ VPC に接続し、ゲーム開発を⾏います。ゲーム制作に使⽤するアセットやその他のデータのアップロードには、 AWS Transfer Family Web Apps を利⽤しており、これらのファイルは Amazon S3 に保存された後、NAS サーバー経由で 『RE ENGINE』 の EC2 インスタンスから利⽤できる仕組みとなっています。 開発環境 各チームには Visual Studio 開発環境がプリインストールされたワークステーション (Amazon EC2) を最⼤ 8 台まで提供しました。インスタンスタイプは NVIDIA T4 GPU を搭載した g4dn.4xlarge (16 vCPU、64 GB メモリ、20 Gbps ネットワーク) を使⽤しています。東京リージョンと⼤阪リージョンを組み合わせて約 100 台の GPU インスタンスを確保することで、学⽣は⾃宅から Amazon DCV によるリモートデスクトップアクセスを通じて快適にアクセスでき、⾼性能ワークステーションと同等の開発体験を得ることができます。 試遊環境 ゲーム開発環境に加えて、実際にゲームをプレイする試遊環境も提供しました。 Amazon API Gateway および AWS Lambda を利⽤して Web ベースのシステムを構築し、ゲームの本体は Amazon S3 に保存する仕組みとしています。さらに、 Amazon GameLift Streams を活⽤することで、ユーザーはブラウザから直接ゲームコントローラーを利⽤して、低レイテンシーでゲームをプレイできる環境を実現しました。 図3: 試遊環境アーキテクチャ図 スケーラビリティと可⽤性 15 チームが同時に開発できるよう、以下の点を考慮した設計としています。 東京リージョンでは ap-northeast-1a、1c、1d の 3 つの AZ を、⼤阪リージョンでは ap-northeast-3b、3c の 2 つの AZ を活⽤し、キャパシティを分散させることで可⽤性を確保しています。さらに、AWS のクラウドならではの柔軟性を活かし、開発期間中の利⽤状況に応じてリソースを調整しており、特に夏休み期間の利⽤ピークに備えた追加確保など、必要なタイミングで迅速にスケールアップを実現しました。 AWS による⽀援とサポート 本プロジェクトの成功に向けて、AWS は事前準備段階から運⽤期間中まで、包括的な技術⽀援とサポートを提供しました。 事前準備段階からの技術⽀援 プロジェクト開始の数ヶ⽉前（2024 年 11 ⽉〜12 ⽉）から、AWS はカプコンと密に連携を開始しました。⼤規模開発環境の運⽤⽅法、リソース確保の戦略、コスト最適化など、多岐にわたる技術的な課題について、専⾨的な知⾒を提供し、最適なアーキテクチャ設計を⽀援しました。 運⽤期間中の継続的なサポート キャパシティの確保と最適化 開発期間中、特に夏休み期間（7 ⽉〜8 ⽉）には学⽣の利⽤が急増し、東京リージョンと⼤阪リージョンを組み合わせて約 115台のインスタンスを確保する必要がありました。稼働している状態を安定的に維持するため、 EC2 オンデマンドキャパシティ予 約 を活⽤した計画的なキャパシティ確保を提案しました。利⽤ピークに備えた追加確保を迅速に対応することで、学⽣が開発に集中できる環境を提供できました。 技術的な課題解決への協⼒ 半年間の運用では、Windows ライセンス管理や macOS ユーザーのゲームパッド対応など、様々な技術的な課題が発生しました。 AWS はカプコンと協力しながら、これらの課題に対して解決案を提示することで、学生が開発に専念できる環境を維持するための技術支援を提供しました。 結果 ⾼い完⾛率の実現 参加していた 15 チーム中 14 チームが半年間の開発期間を完走し、作品を完成させることができました。完走率 93% という高い数値を達成できた要因として、AWS上に構築した 『RE ENGINE』 開発環境により、学生は自身のPCスペックや使用OSなどの制約を受けることなく、また学校・自宅の双方で制作できる自由度の高さなどにより、創作活動に集中できたことが挙げられます。 さらにカプコンスタッフによるサポートで技術面・進行管理面の両方をカバーし、加えて充実したチュートリアルと学習コンテンツで 『RE ENGINE』 の使い方を段階的に習得できる環境を提供しました。通常、このような難易度の高いコンペティションでは完走率が低くなりがちですが、十分な環境とサポートを提供することで高い完走率を実現しました。 図4: 授賞式の様子(左からAWS 賞、最優秀賞、タートル・ビーチ賞) 『RE ENGINE』 の認知拡⼤ 参加した学生からは、「RE ENGINE の性能の高さに驚いた」「企業で使っているエンジンを触る機会が嬉しい」「実際の現場での使い方や分業等のワークフローが知ることができた」といったポジティブなフィードバックを得られました。 コンペティション開催前の全く 『RE ENGINE』 を使ったことのない状態から、半年間のゲーム開発を通じて 『RE ENGINE』 を実際に使いこなし、作品を完成させる経験を積むことができました。その過程でカプコンの開発環境や技術力を肌で感じることができ、ゲーム業界への就職を目指す学生にとって貴重な経験となりました。カプコンも今回のコンペティションを通じて、 『RE ENGINE』 の認知度向上と利用ハードルの低減という当初の目的を達成することができました。 今後の展望 今回のコンペティションで得られた知見とフィードバックは、『RE ENGINE』 の今後の開発と展開に活かしていきます。外部ユーザーへの提供方法、サポート体制、チュートリアルの充実など様々な改善を進め、将来的により多くの開発者に 『RE ENGINE』 を使っていただける環境を整備していく計画です。今回の成功事例は、その過程において大きな進歩となりました。 カプコンでは、オープンカンファレンスでの技術発信、近畿大学での実習、そして今回の 『CAPCOM GAMES COMPETITION』 の開催と、継続的に外部への情報発信と社会貢献を行っており、このような取り組みを通じて「RE ENGINE開発で培われた技術やカプコンのゲーム開発などの情報を発信することで 面白いことにチャレンジしている企業だと知ってほしい」という思いのもと、来年以降も何らかの形で継続していきたいと考えています。 またAWS のクラウド技術を活用することで、地理的な制約を超えた教育機会の提供が可能となりましたので、今後もより多くの学生がゲーム開発の世界に触れられる環境を整備していきます。 今回の経験を活かし、カプコンは今後も AWS と協力しながら、『RE ENGINE』 の社外活用、産学連携の拡大、そして業界全体の発展に貢献できるよう新しい施策にチャレンジすることで、次世代のゲーム開発者育成と、ゲーム業界全体の持続的な成長に寄与することを目指します。 AWS では多くのゲーム会社様が AWS のクラウドサービスを使ってゲームを開発・運⽤するための技術⽀援をしています。またこのブログを始め、CEDEC や GDC などのゲーム業界イベントや AWS 主催のイベント ( Game Tech Night ) などでゲーム会社様向けの情報を発信しています。私たちの活動がゲーム業界の発展に貢献できる様、今後も技術とビジネスの両⾯から全⼒でお客様をサポートしていく所存です。 著者について 伊集院 勝 株式会社カプコン 基盤技術研究開発部 基盤開発支援室 室長 山田 拓海 株式会社カプコン 基盤技術研究開発部 基盤技術開発室 エンジニア 富澤 淳太 株式会社カプコン 基盤技術研究開発部 業務システム開発室 エンジニア 長田 義広 アマゾン ウェブ サービス ジャパン合同会社 ゲームエンターテイメントソリューション部 ゲームスペシャリスト シニアソリューションアーキテクト Zheng Shao アマゾン ウェブ サービス ジャパン合同会社 ゲームエンターテイメントソリューション部 ソリューションアーキテクト

この記事は「 Consolidate, modernize, transform: Edge computing for modern retail 」（記事公開日：2025 年 9 月 10 日）の翻訳記事です。 現在、小売業者は「計画的な資本投資を維持しながらインフラストラクチャをモダナイズする」という圧力の高まりに直面しています。お客様との対話から、一貫して3つのテーマが浮かび上がってきています。高額な店舗サーバーを統合する必要性、クラウドとエッジ全体で統一されたアーキテクチャを確立したいという要望、そして高度な店舗内アプリケーションをサポートする緊急性です。企業は、店舗を次世代の小売体験を提供できるインテリジェントなハブに変革しようとしていますが、既存のインフラストラクチャでこの取り組みをどのように始めればよいか苦慮していることがよくあります。本記事では、小売業者がエッジコンピューティングを活用して、既存の投資を最大限に活用しながらインフラストラクチャを統合し、統一されたクラウド-エッジアーキテクチャの確立を経て、次世代の店舗アプリケーションを実現する方法について説明します。 エッジコンピューティングのビジネスケース エッジコンピューティングは、クラウドネイティブな機能を店舗に提供することで、小売業者がインフラストラクチャを統合し、コストを削減し、高度なアプリケーションへの変革できるようサポートします。IDC によると、2028 年までに小売業者の 30% が AI チップを搭載した分散エッジコンピューティングを活用することで、店舗の IT コストを 10% 削減し、レイテンシーを低減し、IT 運用パフォーマンスを向上させるとされています。 予測可能な数値を見てみましょう。最新のエッジコンピューティングソリューションを使用することで、小売業者は以下を実現できます： 新しい店舗機能とアプリケーションのデプロイが 70% 高速化 サーバー統合による IT コストの 10% 削減 レイテンシーが 60% 向上し、アプリケーションパフォーマンスが向上 一元管理によるセキュリティとコンプライアンスの強化 レジリエンス、データ管理、ディザスタリカバリの改善 ビジネス価値を推進する主要ユースケース エッジコンピューティングは、実店舗の運営に即座に価値をもたらす 3 つの変革的な機能を実現します： 店舗サーバーの統合 多くの小売業者は、異なるアプリケーション（POS、在庫管理、セキュリティなど）のために、店舗ごとに 3〜5 台の個別サーバーを維持しています。 Amazon EKS Hybrid Nodes を使用することで、小売業者はこれらのワークロードを単一のモダンなエッジプラットフォームに統合できます。例えば、AWS パートナーの Spectro Cloud は、あるグローバルコーヒーチェーンが店舗サーバーのフットプリントを 60% 削減し、アプリケーションパフォーマンスを向上させ、管理の複雑さを軽減することを支援しています。この統合により、通常 10〜15% のコスト削減を実現しながら、将来のイノベーションの基盤を提供します。 モダンな POS（販売時点情報管理）システム 従来の POS システムは、専用ハードウェアと複雑なネットワークを必要とすることが多くありました。エッジコンピューティングを使用することで、小売業者は EKS Hybrid Nodes 上で実行されるコンテナ化されたアプリケーションを使用して、POS インフラストラクチャをモダナイズできます。AWS パートナーの Artisan Studios は、米国のクイックサービスレストランがクラウドネイティブ POS ソリューションをデプロイし、ハードウェアコストを 40% 削減しながら、アップデートの高速化と信頼性の向上を実現することを支援しました。このソリューションは、オフライン運用やリアルタイム在庫更新などの高度な機能もサポートします。 高度な店舗内アプリケーション エッジコンピューティングは、コンピュータビジョン、IoT、AI/ML ワークロードを含む次世代小売アプリケーションの基盤を提供します。小売業者は、クラウドサービスとのシームレスな統合を維持しながら、これらのワークロードをエッジで効率的に実行できます。例えば、小売業者は在庫モニタリングのためにリアルタイムで動画を処理し、IoT センサーで環境制御を行い、パーソナライズされた顧客体験のために AI モデルを実行できます。これらすべてが単一で統一されたコントロールプレーンを通じて管理されます。 Gartner によると、これにより小売業者は、単一のデジタルエクスペリエンスを通じて店舗データ、運用インテリジェンス、アプリケーションを統合した従業員向けの「スーパーアプリ」をデプロイできます。例えば、 GameStop は、すべての店舗、配送センター、本社の拠点にわたってタスクとコミュニケーションを統合する「現場従業員向けのスーパーアプリ」を使用しています。監査作業、ロス削減、従業員エンゲージメントにおいて測定可能な改善を実現し、より良い意思決定のためのリアルタイム分析を可能にしました。 AWS は、小売業者が Amazon EKS Hybrid Nodes に基づいたモダンなエッジコンピューティングプラットフォームを設計、および実装するための詳細な アーキテクチャガイダンス を提供しており、クラウドとエッジ環境全体で Kubernetes ワークロードの統一された管理を可能にします。さらに、軽量モデルとコンテナを使い小売拠点で AI および生成 AI 機能を活用するための ガイダンス も提供しており、お客様が実店舗に高度で革新的な機能をデプロイできるよう支援しています。AWS のリファレンスアーキテクチャと実装パターンは、ネットワーク接続、セキュリティ、可観測性、アプリケーションライフサイクル管理などの重要な考慮事項をカバーしています。各リファレンスアーキテクチャには、POS、在庫管理、コンピュータビジョンアプリケーションなどの小売ワークロード向けの具体的なガイダンスが含まれています。検証済みのパートナーソリューションと AWS Professional Services の専門知識を通じて、既存のアプリケーションと将来の小売イノベーションの両方をサポートできる、スケーラブルでレジリエントなエッジアーキテクチャを作成するための規範的なガイダンスを提供します。 図1 – AWS における小売業向けエッジコンピューティングのガイダンス 図2 – AWS におけるエッジでのAIのガイダンス 戦略的実装の考慮事項 ビジネスリーダーがエッジコンピューティングの導入を開始する際、成功への鍵は、3 つのフェーズを中心とした実用的で体系的なアプローチから始めることです： 評価 ：まず、現在の店舗テクノロジー環境をマッピングし、統合とモダナイゼーションの機会を特定します。Spectro Cloud の評価フレームワークは、小売業者が既存のインフラストラクチャ、アプリケーション要件、運用プロセスを評価し、明確なモダナイゼーションロードマップを作成するのに役立ちます。 実装 ：ニーズに最適なアプローチを選択します。新規店舗の場合、Spectro Cloud は AWS サービスとシームレスに統合される完全なエッジプラットフォームを提供します。既存の店舗の場合、Artisan Studios は、ビジネスの継続性を維持しながら、小売業者がインフラストラクチャを段階的にモダナイズすることを専門としています。多くの成功している顧客は、新規店舗では本格的なソリューションを実装し、既存店舗では段階的にアップグレードするハイブリッドアプローチを選択しています。 投資戦略 ：短期的な価値と長期的な変革目標のバランスを取ります。店舗ごとのデプロイメントモデルにより、組織はそれぞれの店舗での導入から得られる知見を活かしながら、支出を効果的に管理できます。Spectro Cloud と Artisan Studios の両社は、コストと価値実現を一致させる柔軟な消費モデルを提供しています。 AWSとともに進む道 AWS は、エッジコンピューティングへの各組織の道のりが各社により異なることを理解しています。ご紹介したアプローチは、ビジネスリーダーにとって重要な実用的な考慮事項を示しています：すなわち、初期資本要件の最小化、既存投資の最大化、そしてソリューションが効率的にスケールできることの保証、です。 Amazon EKS Hybrid Nodes はエッジコンピューティングにおける画期的な進歩をもたらし、小売業者は既存のオンプレミスのインフラストラクチャを Amazon EKS クラスターのノードとして使用できます。これにより、クラウドとエッジ環境全体で統一された Kubernetes 管理が実現し、その運用が大幅に簡素化されコストが削減されます。 エッジコンピューティングの導入を加速するために、AWS は以下を提供しています： Amazon EKS Hybrid Nodes ：オンプレミスのエッジロケーションと AWS クラウド全体で Kubernetes ワークロードを一貫して実行 AWS Outposts ファミリー ：AWS のサービスと運用モデルをあらゆる施設に提供 AWS Professional Services ：深い技術的専門知識と実装ガイダンス 検証済み パートナーソリューション ：Spectro Cloud や Artisan Studios などのパートナーによる事前構築された小売ソリューション 次のステップ エッジコンピューティングは、イノベーションから必須要素へと進化しました。AWS の包括的なサービスとパートナーソリューションにより、大規模な資本投資や専門知識を必要とせずに、店舗の変革を開始できます。IDC が予測するように、「2026 年までに、小売ツールの 90% が AI アルゴリズムを組み込むようになる」でしょう。こんにち、堅牢なエッジコンピューティングインフラストラクチャを確立する小売業者は、これらの次世代アプリケーションを活用するための独自の立場に立つことができます。 競合他社に先を越されないようにしましょう。今すぐ AWS 担当者に連絡して、ディスカバリーセッションをスケジュールし、店舗でエッジコンピューティングの力を引き出す方法をご確認ください。小売業の未来は、インテリジェントで、レスポンシブで、エッジによって支えられています。変革をリードする準備はできていますか？ その他のリソース: A deep dive into Amazon EKS Hybrid Nodes Use your on-premises infrastructure in Amazon EKS clusters with Amazon EKS Hybrid Nodes 著者について Justin Swagler Justin Swagler は、AWS のワールドワイド実店舗小売責任者として、実店舗小売のグローバル戦略とThought Leadership を統括しています。Justin は、消費財、小売、戦略分野において 15 年以上の経験を持ち、イノベーション戦略、小売オペレーション、製品開発、エグゼクティブリーダーシップにわたる専門知識を有しています。組織が戦略的にイノベーションを起こし、消費者体験を再発明することを支援することに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号を、ケロッグ経営大学院で MBA を取得しています。 Jacob Cravinho Jacob Cravinho は、AWS のエンタープライズソリューションアーキテクトです。小売業界に焦点を当てたソフトウェアエンジニアリングのバックグラウンドを持っています。チャレンジを楽しみ、常に次の素晴らしい食事を探求しています。 Leland Johnson Leland Johnson は、旅行・ホスピタリティ分野を担当する AWS のシニアソリューションアーキテクトです。ソリューションアーキテクトとして、スケーラブルで安全なクラウドソリューションを設計することで、お客様のクラウドジャーニーをガイドする重要な役割を果たしています。仕事以外では、音楽演奏や軽飛行機の操縦を楽しんでいます。 Will Strye Will Strye は、小売・消費財分野を担当する AWS のシニアソリューションアーキテクトです。ソリューションアーキテクトとして、小売業界のリーダーと協力して革新的なクラウドソリューションをアーキテクトし、顧客体験を向上させ、ビジネス変革を推進するスケーラブルでレジリエントな設計を提供するとともに、テクノロジーの未来に関する戦略的ガイダンスを提供しています。仕事以外では、アート、音楽、執筆を楽しんでいます。 本ブログはソリューションアーキテクトの羽生田が翻訳しました。原文は こちら です。

本ブログは エスツーアイ株式会社様 と アマゾン ウェブ サービス ジャパン合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの齋藤です。最近、多くのお客様から「AI コーディングツールをどう活用すればいいのか」「開発効率を向上させたい」というご相談をいただく機会が増えています。特に、生成 AI を活用した開発プロセスの改善への関心が高まっており、実際の導入事例を求める声を多く耳にします。 その一方で、「AI コーディングツールを使いたいが、何から始めればいいのかわからない」「実際にどれくらいの効果があるのか不安」「若手エンジニアへの展開方法が見えない」といった課題をお持ちの方も多いのではないでしょうか？ 今回ご紹介する事例は、エスツーアイ株式会社様が AI IDE（統合開発環境）の「 Kiro 」を活用して、わずか 10 日間で経費精算システムを開発された事例です。ベテランエンジニアが実際の業務の空き時間を活用しながら、AI との協働により効率的な開発を実現された取り組みをご紹介します。 お客様の状況と課題 エスツーアイ株式会社様は、愛知県に本社を置き、製造業向けのシステムインテグレーションサービスを提供されている企業です。同社では、経営層が AI コーディングの重要性を認識し、毎週のように「AI コーディングをやらないと取り残される」という危機感を営業やエンジニアに伝えていました。しかし、現場のエンジニアは日々の業務に追われ、なかなか新しい技術に取り組む余裕がない状況でした。 開発効率面での課題 開発期間の長期化: 従来の開発手法では、小規模なシステムでも相応の期間と工数が必要 人月単価の競争力: 業界標準の 100〜110 万円程度の人月単価から、さらなる付加価値の創出が求められる スキル習得の機会不足: 現場業務が忙しく、新しい技術やツールを学ぶ時間が確保できない 組織的な課題 AI ツール活用のノウハウ不足: 様々な AI ツールを検証していたものの、実プロジェクトでの活用方法が不透明 若手エンジニアへの展開方法: ベテランエンジニアが個人的に試すことはできても、組織全体への展開方法が見えない 開発プロセスの標準化: マニュアルやドキュメントの更新が追いつかず、属人化が進んでいる ソリューション・構成内容 これらの課題を解決するため、エスツーアイ株式会社様は「Kiro」を活用して、出張経費精算システムの開発に取り組まれました。 Kiro を用いた設計画面の様子 申請された内容を確認する画面 申請された内容の月次レポートを確認できる画面 開発アプローチ 10 年選手のベテランエンジニアが、AI IDE の情報収集を行い、Kiro の存在を知ったことがきっかけでした。会社として検証チームを立ち上げ、社内の課題である「出張経費精算の煩雑さ」を解決するアプリケーションを、AI コーディングで開発することを決定されました。 開発プロセスと工夫 1. 初期段階：要件定義の試行錯誤 当初は就業規則の PDF を読み込ませて、概要設計から一気に進めようと試みました。しかし、これだけでは十分なアウトプットが得られないことが判明しました。 課題として感じられた点: PDF を直接読み込めず、テキスト化が必要だった 就業規則だけでは、システムの詳細仕様を生成できなかった 2. Vibe と Spec の使い分けの発見 Kiro には「Vibe」と「Spec」という 2 つの開発モードがあります。 Vibe モードは、チャット形式で AI エージェントに問い合わせができる機能です。コーディングだけでなく、ドキュメント生成など幅広いタスクに対応できます。素早いやり取りで、即座にフィードバックを得ながら開発を進められます。 Spec モードは、Kiro が提唱する「仕様駆動開発」を実現するモードです。Requirements（要件定義）、Design（設計）、Tasks（実装タスク）の 3 フェーズで構造的に開発を進めることができます。仕様と実装の同期を保ちながら開発を進められるため、ドキュメントとコードの整合性を維持しやすいのが特徴です。 お客さまが開発を進める中で、これらの使い分けが重要であることを発見されました。 お客様における Vibe の使いわけ: コードの自動生成に特化 トランザクション的に素早く対応できる ただし、監査ログやドキュメントの更新はされない お客様における Spec の使いわけ: 読み込んだ仕様書を理解・判断してコードを生成 マニュアルやドキュメントへの反映も可能 処理に時間がかかる場合がある 最適な活用方法: 現場業務の合間に Spec で処理を投げておき、本業務を進める その間に Spec が処理を完了させる 細かいコーディング部分は Vibe で素早く対応 マニュアルやドキュメントが必要な箇所は Spec を活用 この使い分けにより、ドキュメントも含めた完成度の高い成果物を効率的に作成できました。 3. 段階的な機能実装 フェーズ 1 で実装した機能: 出張費用と領収書をアップロード 経理担当者による承認・差し戻し機能 基本的なワークフロー管理 今後の展開（フェーズ 2 以降）: 路線検索 API との連携による自動料金計算 AI OCR による領収書の自動読み取り 既存経理システムとの連携 当初は路線検索 API や AI OCR の実装も検討しましたが、開発期間を考慮し、まずは基本機能に絞って完成させる判断をされました。 技術的なポイント セキュリティへの配慮 社内の就業規則を AI に学習させるにあたり、データセキュリティへの懸念がありました。しかし、Kiro はオプトアウトの設定により、顧客データが学習されない仕組みになっていることを ドキュメント で確認し、安心して利用できました。 マニュアルの自動生成 Spec を活用することで、コードだけでなくマニュアルも自動生成されました。完成度は約 70% でしたが、ドキュメント化の工数を大幅に削減できたことは大きなメリットでした。 導入効果 Kiro を活用した開発により、以下の効果を実現されました： 1. 開発期間の大幅短縮 実働約 10 日間で基本機能を実装: 1 日あたり 1〜2 時間の作業時間で完成 ゼロから完全新規開発: 既存システムの改修ではなく、0→1 からの開発を実現 従来手法と比較して、大幅な期間短縮が見込まれる（具体的な比較は困難だが、体感として数倍の効率化） 2. ドキュメント品質の向上 マニュアルの自動生成により、ドキュメント作成工数を削減 監査ログの自動記録により、開発プロセスの透明性が向上 ドキュメントとコードの同期により、メンテナンス性が向上 3. AI コーディングツールの実践的な知見獲得 Vibe と Spec の使い分けノウハウを獲得 現場業務と並行した開発手法の確立 若手エンジニアへの展開に向けた具体的な課題が明確化 4. 今後の展開への足がかり 本格的な AI コーディングツールの導入に向けた実績作り 経営層の期待に応える具体的な成果の提示 他のプロジェクトへの横展開可能性の確認 開発における発見と課題 ポジティブな発見 空き時間での開発が可能: Spec に処理を投げておき、本業務を進める間に処理が完了するため、効率的に開発を進められた ドキュメント管理の自動化: コードとドキュメントが連動して管理される利点を実感 段階的な学習: 実プロジェクトで試しながら、ツールの特性を理解できた 今後の改善課題 テスト自動化の理解深化: 単体テストや結合テストの自動化について、さらなる理解が必要 チーム開発への適用: 今回は一人での検証だったが、チーム開発でどう活用するかの検討が必要 CI/CD との統合: GitLab などのバージョン管理やリリース管理との統合方法の検討 若手への展開方法: 組織としてどのように若手エンジニアに展開していくかが最大の課題 今後の展望 エスツーアイ株式会社様では、今回の成功を踏まえ、さらなる展開を計画されています。 短期的な目標 経費精算システムの機能拡張: 路線検索 API、AI OCR、経理システム連携の実装 他プロジェクトへの適用: 顧客向けシステム開発での Kiro 活用 若手エンジニアへの教育: ベテランの知見を活かした組織的な展開 中長期的なビジョン 開発プロセス全体の改革: CI/CD パイプラインの構築と AI コーディングツールの統合 人月単価の向上: 開発効率化により、130万円、140万円、150万円といった高付加価値サービスの提供 競争力の強化: AI 活用により、2〜3割の工数削減を実現し、市場での競争優位性を確立 特に注目すべきは、AWS 上での総合的な開発環境の構築です。GitHub、 AWS CodeBuild 、 AWS CodeDeploy などを組み合わせた CI/CD 環境に、AI コーディングツールを統合することで、開発から保守運用までを一貫して効率化する構想を持たれています。 お客様の声（エスツーアイ株式会社様） 弊社は、製造業を中心とした IT コンサルティングからアウトソーシングまでシステム開発を行ってきました。そんな中で昨今の AI コーディングツールの進化を目の当たりにしています。そんな中で我々自身も進化すべく、AI IDE として Kiro を試してみることとなりました。 弊社エンジニアの所感として「ツールの利用方法を正しく理解することで開発生産性の向上は見込めそうだ」という感触を得るに至りました。今後は AI IDE の活用範囲を広げていく計画もあり、コンサルティング段階での利用なども視野に入れてお客様へのサービス提供価値向上に向けて取り組んでいきたいと考えております。 お問い合わせ・資料請求 | エスツーアイ株式会社 – S2I – 愛知県 東浦町 まとめ 今回は、Kiro を活用して、わずか 10 日間で経費精算システムを開発されたエスツーアイ株式会社様の事例をご紹介しました。 特に注目すべきは、以下の 3 点です： 現実的なアプローチ: 本業務の空き時間を活用し、無理のない範囲で AI コーディングツールを試せることを実証 実践的な知見の獲得: Vibe と Spec の使い分けなど、実際に使ってみないと分からないノウハウを蓄積 組織展開への示唆: 個人の検証から組織全体への展開に向けた、具体的な課題と方向性の明確化 AI コーディングツールは、適切に活用すれば開発効率を大幅に向上させる可能性を秘めています。しかし、その実現には「まず試してみる」ことが重要です。エスツーアイ株式会社様の事例は、中小企業でも AI コーディングツールを活用して成果を出せることを示す、貴重な先行事例となっています。 同様の課題をお持ちのお客様、特に「AI コーディングツールの導入を検討している」「開発効率を向上させたい」「若手エンジニアのスキルアップに課題を感じている」といったニーズをお持ちの方には、非常に参考になる事例だと思います。 また、AWS では、生成 AI を活用したソリューション開発を支援するさまざまなイベントやプログラムを定期的に開催しております。技術セッションやハンズオンを通じて実際に技術に触れることができますので、ぜひご参加ください。 https://aws.amazon.com/jp/events/ ご関心のあるお客様は、ぜひ AWS までお問い合わせください。本事例の詳細や、AI コーディングツールの導入支援につきましては、AWS ソリューションアーキテクトまでお気軽に お問い合わせ ください。 著者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。

生成 AI の進歩は著しいものの、医療機関における展開はまだ途上にあります。東京慈恵会医科大学が中心になり行った「 医療現場における医療AIの導入状況の把握、及び導入に向けた課題の解決策の検討のための研究 」では、翻訳等の一般的な AI 製品の導入が 2 割前後の一方、看護サマリやケアプラン作成といった業務にかかわる領域での導入率は 1% 未満となっています。本調査における「導入」は買うことが前提であり、「自ら作る」ことは考慮されていません。 医療機関が自ら生成 AI を活用しシステムを作ることは非現実的でしょうか? 非現実的な理由はいくらでも挙げることができます。IT を専門に扱う人材がいないかいても数名であること、システムには医療情報ガイドラインに基づくセキュリティに万全を期す必要がありリスクを冒すことができないこと、電子カルテをはじめとしとした様々なシステムがデータを占有しベンダの許可なしには連携や接続が困難なこと、なにより 2025 年時点で自治体病院の 8~9 割が赤字という予算の問題です。これらの制約の中、内製化を推進できるのは一部の病院のみとみなされています。 しかし、現実は時に予想よりも “非現実的” です。2025 年 10 月に開催された企業の内製化推進を支援する ANGEL Dojo 2025 の頂上決戦、最終選考に残った 4 企業のうち 1 つは 兵庫県立リハビリテーション中央病院 様でした。社会福祉法人の病院であり、必ずしも資金が潤沢で人材が豊富というわけではありません。頂上決戦の場で Well Architected に則ったシステム構成を話すのは、 90 日前には IT 知識ゼロの状態から始めた総務部の方でした。頂上決戦は逃したものの中間発表 1 位に選ばれたのは、 熊本中央病院 様でチームは看護師をはじめとした現場の方で構成されていました。 頂上決戦の様子はこちらから参照できます 。 “DX は夢ではない” と語られていたのが、ANGEL Dojo 2025 で 2 病院のチャレンジを支援する中で私が最も心に残った言葉です。両病院の挑戦が実際に病院の中で実を結ぶにはまだ道のりがありますが、本ブログでは途中経過としてどのように病院様と AWS パートナーが協力し非現実的と思われる地方病院でのシステム内製化を現実にしていったのか紹介します。 ANGEL Dojo とは ANGEL Dojo は企業の内製化を支援するための AWS のプログラムです。本プログラムの特徴として、企業自身による “完全内製化” ではなく内製化支援推進 AWS パートナーが伴走する “ 共創型内製化 ” の実現を目指しています。現場の課題やビジネス知識に造詣が深いユーザー企業が企画を主導し、システム開発に長けた AWS パートナーが開発・運用を主導しつつ、お互いの専門領域に歩み寄り共通言語を醸成することで「阿吽の呼吸」でスピード感のあるシステム開発を行います。 過去参加されたお客様では、 戸田建設様が DX 推進室の取り組みを ANGEL Dojo で担当した Serverless Operations 様と拡大しており 、 エフピコ様では営業担当者の日報作成・分析を行うスマートフォン対応アプリケーションを内製化し 事例化しています。戸田建設様が事例インタビューで 「 予想以上のスピードで、たくさんの内製化プロジェクトが進んでいます。当社の中でも DX 推進室に対して見る目が変わり、いろいろな部署から相談が来るようになっています 」と語っていただいている通り、阿吽の呼吸により必要なものをスピード感もって実装できることが共創型内製化を実現する大きなメリットとなります。 全体のプログラムは次のようになっています。AWS = 開発というイメージがあるかもしれませんが、開始 1 ヵ月ほどの長い時間をかけて「何を作るべきか?」を形にするための講義・実践に当てています。“Working Backwards ワークショップ” は、Amazon の実践するプロダクト開発プロセスである Working Backwards を演習形式で学びます。Working Backwards はお客様の声、病院であれば患者や現場の医師・看護師の声を聴く “Listen” というフェーズから始まり声の裏側にある課題を解決するソリューションを「プレスリリース」という形で具体化する点に特色があります。設計・開発に入る前には AI 開発エージェントのワークショップを行い自然言語から開発を支持する方法、技術的な質問を解決する方法を学んでいただきました。 3 ヵ月の間、お客様 3~4 名と内製化支援推進認定を受けた AWS パートナー 3~4 名が 1 つのチームとなりプログラムの支援を受けながら「 実際の課題 」を解決するためのシステム開発に取り組みます。今回、両病院はスマートフォンによる院内情報の参照など DX に向けた施策を進める中で ANGEL Dojo の存在を知り、院長自身から参加に強い意欲を示して頂いたことから参加頂きました。90 日間という長期のプログラムで、しかも期間中はメンバー全員が週 2 日の全日を活動に費やす必要があります。病院様側の参加メンバーは普段看護師や理学療法士を担当されている方が中心で、患者の方に向かい合う貴重な時間を投資を頂きました。 ANGEL Dojo で参加病院様が取り組んだテーマ ANGEL Dojo では、兵庫県立リハビリテーション中央病院様は 富士ソフト株式会社様 と 株式会社アンチパターン様 とリハビリのスケジュール自動化に取り組まれました。この背景には、休日や休暇・欠勤などによるスケジュールの再作成によりセラピストが本来リハビリに当てるべき時間が奪われ、患者のリハビリ機会及び病院収益の最大化のボトルネックになっていることがあります。兵庫県立様のチームが Working Backwards を通じ作成したプレスリリースを一部抜粋します。 そして、熊本中央病院様は キヤノンITソリューションズ株式会社様 と医療文書作成時間の削減に取り組まれました。この背景には、月 700 名に登る患者様の退院に伴い 月 2,000 件以上の文書作成、時間にして 1,000 時間超の業務が発生しており 80% 以上のスタッフが肉体的・精神的ストレスを感じている ことがありました。熊本中央病院様のチームが Working Backwards を通じ作成したプレスリリースを一部抜粋します。 (ぜひ、両病院のプレスリリースについて冒頭だけでも読んでみてください！) (ぱっと見で情報をつかむのは難しいですが、「読む」とその情報量の密度に驚かれるのではないかと思います) Working Backwards では、パワーポイントの「見た目」で「分かった気になる」ことで失われてしまう細かい数字、背景、厳しい質問への回答など緻密・厳密な情報量を維持するため文書・プレスリリースの形を用いているのが特徴です。2004 年に創業者のジェフ・ベゾスが Power Point を禁止にしたという逸話を聞いたことがある方もいるかもしれませんが、実際に Amazon / AWS 内で今でも用いられているプロセスです (対外発表などでは Power Point も使いますが)。 医療機関ならではの課題の解決 ANGEL Dojo 期間中に病院の実務に使えるシステム構築まで進めるためには、用意されたプログラム以外の対策が必要でした。ANGEL Dojo のプログラムに加え実施した講義や施策を紹介します。 基礎的な IT 知識の獲得 今回、両病院とも IT 知識の獲得から始める状態でした。そのため、ANGEL Dojo 前に事前学習のコンテンツを用意し学習をしていただきました。AWS で開催した過去の講習動画が中心でしたが、開発者向けであったためわかりにくい概念について病院の皆様にイメージしてもらいやすい解説で説明を補足することで皆さんの理解を促しました。こちらは ANGEL Dojo 開始前のランチタイム勉強会として 5~6 回ほど実施しました。 身近な事例でクラウドのコンセプトを理解する より 医療情報ガイドラインの理解と実践 医療機関でのシステム開発においてセキュリティの確保は重要な要件です。一方、セキュリティへの過度な懸念はベンダー依存を招き自主的な情報活用を阻む温床になっています。医療機関のシステムに何が求められているか具体的に理解し、どうすれば要求事項を満たせるのか明確な道筋をつかむことは内製化において必要不可欠なマイルストンとなります。 そこで、ANGEL Dojo 期間内にヘルスケア領域を担当する Solution Architect から総務省・経済産業省、厚生労働省から提示されている「医療情報ガイドライン」について講義を頂きました。これには、支援を行う AWS パートナーの方にも参加いただき知識を揃えて頂きました。 医療情報システム on AWS より こちらの講義の内容は AWS ブログで公開しています。 医療情報ガイドラインの改定から読み解くクラウド化 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 2 医療情報ガイドラインをクラウド上で実践する -概要編- 医療情報ガイドラインをクラウド上で実践する -詳説編- さらに「明確な道筋」をつかむため、リスクの洗い出しと対処を実践するための「脅威モデリング」を演習形式で実践頂きました。脅威モデリングではデータフローを可視化したうえで「何が起こりえるか?」をフレームワークを活用しチームで洗い出しをしていきます。次のスライドのように業務担当者、システム担当者、知見がある人は攻撃側の視点に、と様々な知識を持つチームのメンバーが意見を出し合うことがリスクを洗い出すうえで大きなポイントとなります。 脅威モデリングの理解と実践 より 業務に詳しい現場の方とシステムに詳しい AWS パートナーの共創型チームと脅威モデリングの愛称は非常によく、私達も予想しない効果、役立ったというフィードバックを頂きました。 １つのフローに対して、 短時間でもあれだけのリスクを洗い出せることに驚きました 。作成ばかりで病院側で脅威について考える機会が少なかったので、とても貴重な時間でした。また、意見出しもしやすく、学びにもなり、とても有意義な時間でした。 先週のWAレビューはリスク、AWSサービスについての知識が乏しく、脅威・リスクのイメージが持てず、正直ついていけなかったです。本講義では、 一般用語に落とし込んでご説明、課題提示をしていただけた ので、脅威モデリングの思考過程や、我々の開発、病院環境の課題をよく理解することができ、大変勉強になりました。ありがとうございました。 セキュリティはすごく 自分にとって遠いものだと感じていましたが、今すごく身近なものになっています 実際に意見を出し合って実践できたので次回からも自信をもって行えます！ システムのセキュリティ管理は専門家が知らないところで実装するものではなく、 自分達自身も主体的に加わり関与することではじめて実効性のある・ガイドラインが本来意図するところのセキュリティ対策になる ことを実感頂くことが出来ました。 院内システムとの連携 AWS 上で構築したシステムが院内のデータを扱うには当然連携が必要です。データの取得・ネットワークを通じた連携を実現するには導入を担当したベンダーの方々と調整が必要です。ANGEL Dojo で実装するシステムの要件と設計が固まった 9 月の段階から早めにベンダーとのやり取りを開始し、ANGEL Dojo 期間内のアーキテクチャーレビューに同席いただくなど具体的な連携に向けた議論を進めました。こちらは現在進行形であり、現在も実現に向けた調整を行っています。先に挙げた通り、私達はよく言われる”セキュリティ”が病院における情報活用の真のハードルではないと確信しています。病院様が危機感と熱意を持ち取り組まれる中で、同じ温度感で対応いただくことは大きな課題の一つです。現在、病院単独からユーザー会や地域を通じ総体で声を上げるなど様々な方策を進めています。 内製化できる自信を醸成する 両病院とも初めてのシステム開発に取り組む中で、「本当にできるのか」「自分に役割はあるのか」といった不安は大きかったと思います。実際にキックオフの前に大きな不安があるという話も個別に伺いました。そうした中、ポジティブかつ意欲的に取り組めるよう、内製化支援推進の AWS パートナーである富士ソフト株式会社、株式会社アンチパターン様、キヤノンITソリューションズ株式会社は様々な工夫をされていました。 素早く動くプロトタイピング : まず動くものを作る方針。仕様変更を恐れず、リリースを目指す姿勢を持つ 素直なコミュニケーション : 「わからないことを正直に伝える」ことの大切さ共有、専門用語を排した解説 チーム組成 : クレイジー8 を用いたメンバー全員でのアイデア発案、メンバー独自の専門性・得意分野を確立 チームで動く : 外部からの優先度指示よりもチーム内の方針を優先、プレッシャーがあっても一丸となる姿勢 短いサイクルでのアウトプット : LT形式で頻繁に発表し、考えを固めすぎない 生成 AI の活用 : Generative AI Use Cases を使ったプロンプトエンジニアリングの練習、習熟、 Kiro や Amazon Q Developer を活用した素早いコード解析と画面共有 わからないことをわからないと率直に言える心理的安全性を確立し、動くものをなるべく早く目にすることで不安を解消し、一人一人が役割を見出せるように強みを発見するコミュニケーションを取られていました。富士ソフト様、アンチパターン様、キヤノン IT ソリューションズ様のチームメンバーは医療領域のエキスパートというわけではありませんでした。しかし、 共に学び専門的な IT 知識をもって意欲的に・ポジティブに支援してくれるパートナーの存在が十分すぎるほど内製化を加速させる ことが病院様メンバーの表情的にも、成果的にも証明されたと感じています。 成果 兵庫県立リハビリテーション中央病院様は、生成 AI モデルへ安全にアクセスできる Amazon Bedrock を用いプロンプトを工夫した生成 AI によるスケジュール作成でを実装し、 60% の自動化ができることを確認しました 。これにより 土・日のスケジュール作成に費やす時間・人的コスト (1病棟・1日分あたり) 100 分を 20分と 80% 短縮し人員も 1/3 で済む見込みです 。さらに、空いた時間がリハビリの提供に当てられることで 月当り約36単位 (88,200円) 収益の増加 が得られる見込みで運用保守費用と比べても費用対効果がペイすると試算できています。リハビリ以外のスケジュール業務も多々あり、応用できれば更なる効率化に繋がります。 熊本中央病院様は、退院サマリ等の文書作成に生成 AI を活用することで月 800 時間の文書作成時間の削減ができることを確認しました。より効率化はもちろん診察科の違いを吸収できることを確認されています。整形外科、内分泌科など複数の診療科でそれぞれ要件に応じた文章が作成できることも確認ができています。さらに、脅威モデリングに基づくセキュリティ対策も実装されています。 両病院とも、まだ補完すべき点はあるものの「実際に動く」「効果に確信が持てる」「セキュリティ要件を実装した」システムの実装を 90 日で成し遂げられました。 共創型内製化の効果 病院様、AWS パートナー様にインタビューして得られたエピソードを紹介します。 看護師の方が、画面上にどんなボタンやメニュー、また項目があると医師を含め操作しやすいか検討。さらに、 自ら直接色やレイアウトについて AI 開発エージェントを使いイメージを形にした 病院の事務員の方が、早い段階から病院内のセキュリティルールを調査し 業務フロー上のリスクを洗い出した 。AWS パートナーがそこからセキュリティチェックリストを作成し、脅威モデリングの講義を受けチーム全体でブラッシュアップした 看護師の方が、当初書き方に明確なルールがない診療情報提供書について AWS パートナーと会話することで 必要な条件やゴールの明確化ができるようになり安定して文書生成ができるプロンプトを書けるようになった 理学療法士の方が、データから機微情報をフィルタする機能を AI 開発エージェントで自ら改善し、稼働環境に反映された 院長へのインタビューでは「 本来的にシステムで何が出来て、どの程度のコストでできるのか理解できるようになった 」ことが大きいと回答いただいています。システムの実装という開発スキルに留まらず、ベンターからの仕様やコストについて「 健全に疑い 」、セキュリティを「 健全に怖がる 」ことで自信をもって切り返せるようになった点を評価いただいているということです。病院でのシステム導入や改修は高額かつ長期になることもしばしばあります。その時に、ANGEL Dojo を通じ身に着けた「IT 領域におけるコミュニケーションの取り方」は限られた IT 予算の最適化という具体的な成果につながる可能性があります。ANGEL Dojo の 3 ヵ月という長期間でなくても、この効果を実感頂けるプログラムが検討できるのではないかと考えています。 次のステップ ANGEL Dojo は 10/31 の頂上決戦をもって終了しましたが、病院での実用にむけた活動は続いています。その中で、ANGEL Dojo の中で培った力は必要不可欠なものばかりと考えています。 実現したいことを Working Backwards で考え、プレスリリースという文章にする力は RFI/RFP を書く際に必要な力そのものです 生成 AI のアシスタントにより実現したいものの設計や実装についてより具体的なイメージを得て、実装難易度にあたりをつける力はベンダー等から提示される作業や見積もりを健全に疑う力に繋がります 医療情報ガイドラインについての知識とリスク対策の経験は、情報漏洩や不正アクセスといった時に内製化を拒む脅し文句に対し健全に対処し実現に向けた道を拓く力に繋がります なにより、90 日間という長いようで短い期間、学び形あるものに仕立て発表した経験は「 やってやれないことはない 」という自信につながったのではないかと思います。90 日はシステムの開発を依頼したら要件のヒアリングや見積もりや折衝で簡単に飛んでしまう期間であり、それに比べ本気の内製化に取り組み IT 知識を獲得することが費用対効果的にも一考に値すると感じています。 AWS では、2025 年 11 月に開催された 医療情報学連合大会 にて両病院の取り組みを紹介させて頂きました。AWS の展示ブースでご紹介をしていたところ、グループ全体で参加したいが次はいつ開催か? 数十病院単位で参加したい、など強い関心を頂きました。展示と共に、次に向けた機会創出も行っています。医療情報学連合大会では多くの医療にかかわる企業が参加するため、両病院をお招きし展示の様子を見て頂くと共に “共創型内製化” の次の一手に欠かせないソリューションやパートナー 3~4 社様との引き合わせを実施しました。ispec様の、病院内ネットワークとクラウドサービスをセキュアに接続できる CloudSail には両病院とも AWS で構築したソリューションと院内システムの連携を実現する有効なソリューションとして関心を持たれていました。ispec 様はデジタル庁標準型電子カルテのプロダクトワーキンググループにも参加されています。ANGEL Dojo でに身につけた知見をもとに、取り組みに不可欠なパートナーやサービスを自分達自身で選べるようになったのも効果の一つと考えています。 AWS を使ったシステム開発というと IT 専門家の領分でとても縁遠いと感じられている方もいると思います。しかし、自然言語で開発を進められる Kiro、AWS のリソースを自在に扱える MCP Server の登場により必ずしもシステム開発は経験ある会社の専売特許ではなくなりつつあります。ANGEL Dojo が目指す企業とパートナーによる 共創型内製化 は、改革が喫緊である医療の現場で求められるスピード感を出すための効果的かつ「現実的な」手段になっています。先日、 医療機関自ら 4 日で内製化を実現した例として 春日井市民病院 様の事例が公開されました 。病院内で Amazon Q Developer を活用し病床管理システム、医療文書作成支援アプリを実装されています。 内製化はまさに “夢ではない”ところまで来ています。日本に住む一人として、特に自治体病院の窮状、9 割以上が赤字経営と報道されている現実を理解しています。AWS では 国立大学法人浜松医科大学様との包括連携協定締結  や、先端技術の提供・支援で 神戸大学との包括連携協定締結 を行っています。ANGEL Dojo の取り組み、また共創型内製化に関心がある方は AWS までぜひご連絡ください。 著者プロフィール 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべく機械学習・生成 AI を実用につなげるための支援と情報発信、フィードバックの収集による AWS サービスの改善を行っています。  

本ブログは 明治ホールディングス株式会社様 と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの羽生田です。 昨今、多くのお客様から生成 AI を活用した開発生産性向上についてご相談いただくようになりました。特に企業の DX 推進を担う部門においては、限られたリソースでより多くの価値を創出するため、AI 活用による効率化が重要な課題となっています。明治ホールディングス株式会社様は、食品と医薬品事業を中核とした総合企業として、デジタル変革を通じた事業価値向上に積極的に取り組まれています。今回は、同社グループ DX 推進部 AWS 事務局が Amazon Q Developer を段階的に導入し、複数のチームで 80-90% の生産性向上を実現した事例についてご紹介します。 企業概要とデジタル変革への取り組み 明治ホールディングス株式会社 は「明治」ブランドで親しまれ、毎日の生活に欠かせない食品・医薬品事業を展開し、健康と安心を届ける総合企業です。傘下に株式会社 明治・Meiji Seika ファルマ株式会社、KM バイオロジクス株式会社があり、グローバル展開も積極的に行っています。同社のグループ DX 推進部 AWS 事務局は、明治グループ全体における AWS 基盤の構築、管理と運用を司る CoE 機能を持った組織です。AWS 上での基盤運用チームと社内システム開発支援を通じて全社のデジタル変革を推進する重要な役割を担っており、2025 年 12 月現在で 300 を超える AWS アカウントを 20 名のメンバーで管理しています。 AWS 事務局では社内の複数プロジェクトを横断的に運用・支援しており、効率的な開発と運用プロセスの確立が常に求められていました。 課題：限られたリソースでの開発・運用効率化 グループ DX AWS 事務局では、多数のAWS アカウントを 20 名体制で管理する中で、以下のような構造的な課題に直面していました： ドキュメント整備の負荷と品質のばらつき : 設計書や構成図の作成・更新に多くの時間を要し、コードとの整合性維持が困難。標準化が不十分で成果物の品質が属人的になりがち 開発業務における手作業の非効率性 : 社内標準に準拠したインフラコードの作成やレビューに時間がかかり、本来注力すべき戦略的な企画・設計業務に十分なリソースを割けない 運用業務の属人化 : 障害対応やセキュリティ監視、技術情報の検索において特定メンバーの知識に依存し、組織全体での知識共有が困難 管理業務の煩雑さ : 多数の AWS アカウントやプロジェクトの管理に手作業が多く、定型業務に時間を取られる状況 これらの課題により、本来注力すべき戦略的な企画と設計開発業務に十分なリソースを割けない状況が続いていました。 解決策：Amazon Q Developer の段階的導入 Amazon Q Developer とは Amazon Q Developer は、開発者がAWS上でより効率的に作業できるよう設計された包括的な AI 支援ツールです。自然言語処理、コード生成、セキュリティスキャン、運用支援など多岐にわたる機能により、開発プロセス全体を通じて生産性の向上とエラーの削減を実現します。多様なプラットフォームでの利用可能性と柔軟な料金体系により、個人開発者から大規模チームまで幅広いニーズに対応しています。 Amazon Bedrock を基盤として構築されており、AWS の各種サービスの理解、構築、拡張、運用を支援します。開発者は自然言語を使用して AWS アーキテクチャ、リソース、ベストプラクティス、ドキュメント、サポートに関する質問を行うことができ、利用している AWS アカウントについて文脈に応じた実用的な回答を得ることができます。 統合開発環境（IDE）で使用する場合、Amazon Q Developer はソフトウェア開発支援機能を提供します。コードに関する対話、インラインコード補完、新規コード生成、セキュリティ脆弱性のスキャン、言語アップデート、デバッグ、最適化などのコード改善を行うことができます。 導入アプローチ AWS 事務局は生成 AI コーディングエージェントである Amazon Q Developer の有用性については注目していたものの、大規模な展開の前に AWS アカウントへの接続と権限のコントロールについて懸念を持っていました。ユーザ登録や IAM ロールの定義などを新規に定義する必要があったため、多数のメンバーへのサブスクリプション配布には慎重を期しました。段階的導入によりリスクを最小化しながら効果を最大化する方針を固め、3 段階での導入アプローチを採用しました。 フェーズ 1：AWS 事務局での検証（2025 年 5 月 – 7 月） AWS 事務局の 2 名でパイロット導入 ドキュメント整備と共通プロンプトの作成に注力 社内Gitでの共通プロンプト管理体制を構築 フェーズ 2：限定プロジェクトでの実証（ 2025 年 7 月 – 8 月末） 5 名のプロジェクトチームに展開 既存バッチ見直しと AWS 利用料算出の実プロジェクトで検証 具体的な効果測定と改善点の抽出 フェーズ 3：事務局・部内全体への展開（ 2025 年 8 月末-現在） 申請ベースで事務局だけでなく部内の 35 名超に展開 週次オフィスアワー : AWS ソリューションアーキテクトによる質問対応 このアプローチにより、それぞれのフェーズにおいて懸念事項をひとつずつ解決していきながらユーザ数を増やし、生成 AI コーディングエージェントの利点をそれぞれのメンバーが享受し、共有できる土壌作りも同時に行うことができました。 具体的な活用事例と成果 1. ドキュメント・設計資料の自動化 課題 : 設計書や構成図の作成・更新に多くの時間を要し、コードとの整合性維持が困難 活用例 : AWS CloudFormation テンプレートから設計書を自動生成 AWS 公式アイコンを使用したアーキテクチャ図の自動作成 コード変更時の設計書・構成図の自動更新 AWS を含む各種インフラストラクチャの変更履歴を自動記録 成果 : 生産性向上率: 約 95% 以上向上 品質向上: コードとの整合性 100% 、更新漏れゼロを実現 設計書・構成図作成の大幅な時間短縮により、ドキュメントの鮮度と正確性が向上 2. Infrastructure as Code 開発の効率化 課題 : 社内標準に準拠したコードの作成やレビューに時間がかかる 活用例 : 明治固有の環境構造（ドメイン、ネットワーク構成）を理解した AWS CloudFormation テンプレート自動生成 60 以上の AWS サービスに対応した統一命名規則の自動適用 社内用語（「監査 VPC 」「基幹系」「汎用系」など）の自動反映 成果 : 生産性向上率: 約 95% 以上向上 品質向上: タイプミスゼロ、命名規則違反ゼロ、一貫性 100% を達成 レビュー工数の大幅削減により、開発サイクルが加速 3. 運用・トラブルシューティングの高度化 課題 : 障害対応やセキュリティ監視、技術情報の検索において特定メンバーの知識に依存している 活用例 : エラーメッセージから対象リソースの自動特定と VPC フローログの分析 AWS Security Hub の検出結果を自動分析し、優先度判定と対処方法を提案 社内用語・システム構成の歴史・設計判断の背景を体系化し、自然言語で検索可能に 成果 : 生産性向上率: 約 85-95% 向上 属人化解消: 技術情報へのアクセスが民主化され、特定個人への依存を削減 障害対応時間の大幅短縮と、セキュリティ監視の見落とし削減を実現 4. 組織全体の管理基盤整備 課題 : 多数の AWS アカウントやプロジェクトの管理に手作業が多く、定型業務に時間を取られる 活用例 : 310 の AWS アカウントを SSO 統合管理し、簡易名でのアクセスを実現 プロジェクトの自動分類と番号付きフォルダ管理システムの構築 AWS 利用料のサービス別算出を AWS Lambda 関数で自動化 成果 : 生産性向上率: 約 90% 以上向上 セキュリティ向上: クレデンシャル排除によるリスク削減 毎日の定型作業が完全自動化され、管理工数を大幅に削減 これらを実現していく中で特に重要だったのが Model Context Protocol サーバの利用です。これにより素早く正確な情報へのアクセスと調査、ドキュメント生成を行うことができるようになり、従来多くの時間を要していた作業の大幅な効率化を実現しました。 全体的な成果 AWS事務局が Amazon Q Developer により実現した成果について、明治ホールディングス株式会社様 は以下のようにレポートしています。 定量的効果 80-90% の生産性向上を AWS 事務局全体で実現 30 名超が継続的に活用 多数の定型作業を完全自動化（毎日 1 時間以上/人の時間短縮） 定性的効果 共通プロンプトにより生成 AI を用いた作業品質の平準化 新規参画メンバーの立ち上がり時間の大幅短縮 戦略的業務への人的リソース確保 お客様の声 明治ホールディングス株式会社 グループ DX 戦略部の猪俣 亮様・小林 達也様 は次のように評価されています： 猪俣様のコメント 「AWS 事務局のメンバーは技術者集団として、そして私自身も個の技術者として生成 AI コーディングエージェントを自らの職務の『武器』として手に入れ使いこなしたい、という強い信念がありました。Amazon Q Developer の導入により、これまで時間を要していたドキュメントの整備やコード解析、コード開発が劇的に効率化されました。また、ネットワーク関連の疎通調査において実際の環境の設定値やログを包括的に調査することにより、従来の人手による調査よりも各段に早く問題解決に至ることができるようになりました。 共通プロンプトの活用により、チーム全体で一定の品質と基準を守った成果物を短時間で作成できるようになり、QCD が大幅に向上しました。共通プロンプトにはリソースやドキュメント更新、命名規則等の優先順位付けされたルール、SSO ログインのツールや MCP サーバの設定をしています。これらの活用により正確な情報を取得し、更に高度な自動化が実現できたことで、AWS事務局メンバーが本来注力すべき戦略的な業務により多くの時間を割けるようになりました。」 小林様のコメント 「これまでは戦略的業務や新たな取り組みに取りかかる際、具体的に仕掛かるまでの進め方・事前調査・検討に多くの時間を要していました。Amazon Q Developer の活用により、例えばコスト最適化に関しては、Savings Plans やReserved Instances 購入後の管理・棚卸といった運用面まで見据えた購入計画を Amazon Q Developer に提案させることでコスト削減率の最大化、及び長期的なプラン購入計画の迅速な策定・実践が可能となりました。我々人間自らが思考する・考える範疇の多くを Amazon Q Developer に移譲する中で、結果的に自身では至らなかった多くの見解や気付きを素早く得られるようになりました。今後、より戦略的業務に対する障壁を下げ、効率的に新たな取り組みに挑戦できるようになると期待しています。」 今後の展望 明治ホールディングス株式会社様では、以下の展開を計画されています： 明治グループ全体への展開拡大：成功事例を基に、部内・他部署、各事業会社への展開拡大 PoC、モック作成：新規価値創造の領域で、検証用アプリケーションやモックの作成 さらなる自動化推進：MCP サーバの活用範囲拡大による、より高度な業務自動化 Excel 計算からの脱却加速：いまだ手入力が基本となっている業務をピックアップし AWS 上のアプリケーションに変換 AI エージェント導入：トラブルシュートの一次切り分けエージェントの構築 まとめ 明治ホールディングス株式会社様の事例は、Amazon Q Developer の段階的導入により、大規模な開発チームでも着実に生産性向上を実現できることを示しています。特に、共通プロンプトによる標準化と MCP サーバの高度活用は、他の企業様にとっても参考になる実践的なアプローチです。 生成 AI を活用した開発生産性向上をご検討の際は、ぜひ AWS までお気軽にご相談ください。 Amazon Q Developerについて詳しくは、 こちら をご覧ください。

本記事は 2025 年 11 月 26 日 に公開された「 Introducing catalog federation for Apache Iceberg tables in the AWS Glue Data Catalog | AWS Big Data Blog 」を翻訳したものです。 Apache Iceberg は、大規模で堅牢かつ信頼性の高い分析を求める組織にとって、オープンテーブルフォーマットの標準的な選択肢となっています。しかし、企業は異なるカタログシステムを持つ複雑なマルチベンダー環境をますます多く扱うようになっています。マルチベンダー環境で運用する組織にとって、これらのシステム間でデータを管理することは大きな課題となっています。この断片化は、特にアクセス制御とガバナンスに関して、運用上の複雑さを大幅に増加させます。 Amazon Redshift 、 Amazon EMR 、 Amazon Athena 、 Amazon SageMaker 、 AWS Glue などの AWS 分析サービスを使用して AWS Glue Data Catalog 内の Iceberg テーブルを分析しているお客様は、リモートカタログのワークロードでも同じ価格性能を得たいと考えています。これらのリモートカタログを単純に移行または置き換えることは現実的ではなく、チームはシステム間でメタデータを継続的に複製する同期プロセスを実装・維持する必要があり、運用上のオーバーヘッド、コストの増加、データの不整合のリスクが生じます。 AWS Glue は、Data Catalog でリモート Iceberg テーブルのカタログフェデレーションをサポートするようになりました。カタログフェデレーションを使用すると、 Amazon Simple Storage Service (Amazon S3) に保存され、リモート Iceberg カタログでカタログ化されたリモート Iceberg テーブルを、テーブルを移動または複製することなく、AWS 分析エンジンを使用してクエリできます。リモートカタログが統合されると、AWS Glue は常にバックグラウンドで最新のメタデータを取得するため、お好みの AWS 分析サービスを通じて常に Iceberg メタデータにアクセスできます。この機能は、粗い粒度のアクセス制御と AWS Lake Formation によるきめ細かな粒度の権限の両方をサポートしており、リモート Iceberg テーブルをデータコンシューマーと共有する方法とタイミングを柔軟に選択できます。Snowflake Polaris Catalog、Databricks Unity Catalog、および Iceberg REST 仕様をサポートするその他のカスタムカタログとの統合により、リモートカタログにフェデレートし、データベースとテーブルを検出し、アクセス権限を設定し、リモート Iceberg データのクエリを開始できます。 この記事では、Data Catalog で Iceberg テーブルのカタログフェデレーションを開始する方法について説明します。 ソリューションの概要 カタログフェデレーションは、Data Catalog を使用してリモートカタログシステムと通信し、カタログオブジェクトを検出し、Lake Formation を使用して Amazon S3 内のデータへのアクセスを認可します。リモート Iceberg テーブルをクエリすると、Data Catalog はクエリ実行時にリモートカタログ内の最新のテーブル情報を検出し、テーブルの S3 ロケーション、現在のスキーマ、パーティション情報を取得します。分析エンジン (Athena、Amazon EMR、または Amazon Redshift) は、この情報を使用して Amazon S3 から直接 Iceberg データファイルにアクセスします。Lake Formation は、Amazon S3 に保存されているテーブルデータへのスコープ付き認証情報を発行することでテーブルへのアクセスを管理し、エンジンがフェデレーテッドテーブルにきめ細かな粒度の権限を適用できるようにします。このアプローチにより、メタデータとデータの重複を回避しながら、お好みの AWS 分析エンジンを通じてリモート Iceberg テーブルへのリアルタイムアクセスを提供します。 Data Catalog は、リモートカタログエンドポイントとの AWS Glue 接続を確立することで、Apache Iceberg をサポートするリモートカタログシステムへの接続を容易にします。OAuth2 またはアクセストークンを使用したカスタム認証メカニズムを使用して、Data Catalog をリモート Iceberg REST カタログに接続できます。統合中、管理者はリモートカタログ内のリソースにアクセスするための適切な権限を持つプリンシパル (サービスアカウントまたは ID) を設定します。AWS Glue 接続オブジェクトは、この設定されたプリンシパルの認証情報を使用して、リモートカタログサーバー内のメタデータを認証およびアクセスします。また、ネットワークアクセスを分離および制限するためにプライベートリンクまたはプロキシを使用するリモートカタログに Data Catalog を接続することもできます。接続後、この統合は標準化された Iceberg REST API 仕様を使用して、これらのリモートカタログから最新のテーブルメタデータ情報を取得します。AWS Glue は、これらのリモートカタログを独自のカタログインフラストラクチャ内のフェデレーテッドカタログとしてオンボードし、複数のカタログシステム間で統一されたメタデータアクセスを可能にします。 Lake Formation は、フェデレーテッドカタログリソースへのユーザーアクセスを管理するための一元化された認可レイヤーとして機能します。ユーザーがフェデレーテッドカタログ内のテーブルやデータベースにアクセスしようとすると、Lake Formation は権限を評価し、きめ細かな粒度のアクセス制御ポリシーを適用します。 メタデータの認可に加えて、カタログフェデレーションは実際の基盤となるデータファイルへの安全なアクセスも管理します。これは、一時的でスコープが制限された認証情報を発行する認証情報発行メカニズムによって実現されます。AWS Glue フェデレーテッドカタログは、お好みの AWS 分析エンジンやクエリサービスと連携し、分析ワークロード全体で一貫したメタデータアクセスと統一されたデータガバナンスを実現します。 以下のセクションでは、Data Catalog をリモートカタログサーバーと統合する手順を説明します。 リモートカタログで統合プリンシパルを設定し、このプリンシパルにカタログリソースへの必要なアクセス権を付与します。統合プリンシパルの OAuth ベースの認証を有効にします。 AWS Glue 接続を使用して Data Catalog にフェデレーテッドカタログを作成します。統合プリンシパル (ステップ 1) の認証情報を使用してリモートカタログの Iceberg REST エンドポイントに接続する AWS Glue 接続を作成します。リモートテーブルデータが存在する S3 ロケーションへの権限を持つ AWS Identity and Access Management (IAM) ロールを設定します。クロスアカウントシナリオでは、バケットポリシーがこの IAM ロールに必要なアクセス権を付与していることを確認してください。このフェデレーテッドカタログは、リモートカタログサーバー内のカタログオブジェクトをミラーリングします。 Lake Formation または AWS Glue API を使用して、フェデレーテッドカタログ内の Iceberg テーブルを検出します。AWS 分析エンジンを使用して Iceberg テーブルをクエリします。クエリ操作中、Lake Formation はフェデレーテッドリソースに対するきめ細かな粒度の権限と、エンドユーザーへの基盤データへの認証情報発行を管理します。 前提条件 開始する前に、AWS で以下の設定が完了していることを確認してください。 AWS アカウント AWS Command Line Interface (AWS CLI) バージョン 2.31.38 以降がインストールおよび設定されていること 以下のサービスへの適切な権限を持つ IAM 管理者ロールまたはユーザー IAM AWS Glue Data Catalog Amazon S3 AWS Lake Formation AWS Secrets Manager Amazon Athena データレイク管理者を作成します。手順については、 データレイク管理者の作成 を参照してください。 リモート Iceberg カタログでの認証情報の設定 リモート Iceberg カタログへのカタログフェデレーションは、メタデータアクセス用に設定されたプリンシパルの OAuth2 認証情報を使用します。この認証メカニズムにより、AWS Glue Data Catalog は、プリンシパルに関連付けられた権限に基づいて、リモートカタログ内のさまざまなオブジェクト (データベース、テーブルなど) のメタデータにアクセスできます。適切な機能をサポートするには、これらのオブジェクトのメタデータを読み取るために必要な権限をプリンシパルに付与する必要があります。統合プリンシパルの OAuth ベースの認証を有効にするために、 CLIENT_ID と CLIENT_SECRET を生成します。 リモート Iceberg カタログへの接続を使用した AWS Glue カタログフェデレーションの作成 リモート Iceberg カタログサーバー内のカタログオブジェクトをミラーリングするフェデレーテッドカタログを Data Catalog に作成します。これは、AWS Glue サービスが ListDatabases 、 ListTables 、 GetTable などのメタデータクエリをリモートカタログにフェデレートするために使用されます。データレイク管理者として、AWS Lake Formation に登録された AWS Glue 接続オブジェクトを使用して、Data Catalog にフェデレーテッドカタログを作成できます。 AWS Glue 接続のデータソース接続の設定 カタログフェデレーションは、リモートカタログで認証と Iceberg REST API エンドポイントの設定を提供する際に、メタデータアクセス用の AWS Glue 接続を使用します。AWS Glue 接続は、認証方法として OAuth2 またはカスタムをサポートしています。 OAuth2 認証を使用した接続 OAuth2 認証方法では、クライアントシークレットを直接入力として提供するか、 AWS Secrets Manager に保存して認証時に AWS Glue 接続オブジェクトで使用できます。AWS Glue は、有効期限が切れるとトークンの更新を内部的に管理します。Secrets Manager にクライアントシークレットを保存するには、以下の手順を完了します。 Secrets Manager コンソールで、ナビゲーションペインの Secrets を選択します。 Store a new secret を選択します。 Other type of secret を選択し、キー名として USER_MANAGED_CLIENT_APPLICATION_CLIENT_SECRET を指定し、クライアントシークレットの値を入力します。 Next を選択し、シークレットの名前を指定します。 Next を選択し、 Store を選択してシークレットを保存します。 カスタム認証を使用した接続 カスタム認証では、Secrets Manager を使用してアクセストークンを保存および取得します。このアクセストークンは、お客様のアプリケーションまたはシステムによって作成、更新、管理され、認証プロセスを適切に制御および管理できます。Secrets Manager にアクセストークンを保存するには、以下の手順を完了します。 Secrets Manager コンソールで、ナビゲーションペインの Secrets を選択します。 Store a new secret を選択します。 Other type of secret を選択し、キー名として BEARER_TOKEN を指定し、統合プリンシパルのアクセストークンを値として入力します。 Next を選択し、シークレットの名前を指定します。 Next を選択し、 Store を選択してシークレットを保存します。 AWS Glue 接続の Lake Formation への登録 Lake Formation が認証情報を発行するために使用できる IAM ロールを作成し、Iceberg テーブルが保存されている S3 バケットプレフィックスへの権限をアタッチします。オプションで、Secrets Manager を使用してクライアントシークレットを保存する場合やネットワーク設定を使用する場合は、これらのサービスへの権限をこのロールに追加できます。手順については、 リモート Iceberg カタログへのカタログフェデレーション を参照してください。 接続を登録するには、以下の手順を完了します。 Lake Formation コンソールで、ナビゲーションペインの Catalogs を選択します。 Create catalog を選択し、データソースを選択します。 フェデレーテッドカタログの詳細を入力します。 フェデレーテッドカタログの名前 リモートカタログサーバー内のカタログ名 (リモートカタログの正確なカタログ名と一致する必要があります) AWS Glue 接続の詳細を入力します。既存の接続を再利用するには、 Select existing connection を選択し、再利用する接続を選択します。初回セットアップの場合は、 Input new connection configuration を選択し、以下の情報を入力します。 AWS Glue 接続名を入力します。 リモートカタログの Iceberg REST API エンドポイントを入力します。 カタログオブジェクトの大文字小文字のタイプを指定します。接続は、オブジェクト階層全体で大文字のオブジェクトまたは小文字のオブジェクトをサポートできます。 認証パラメータを設定します。 OAuth2 の場合: クライアント ID とクライアントシークレットを直接入力するか、クライアントシークレットが保存されているシークレット、トークン認可 URL、および認証情報にマッピングされたスコープを選択します。 カスタムの場合: アクセストークンが保存されている Secrets Manager で管理されるシークレットを指定します。 ネットワーク設定: ネットワークやプロキシの設定がある場合は、この情報を入力できます。それ以外の場合は、このセクションをデフォルトのままにします。 リモートテーブルのメタデータとデータが保存されているバケットへのアクセス権を持つ IAM ロールを使用して、接続を Lake Formation に登録します。 Run test を選択して接続を確認します。 テストが成功したら、カタログを作成します。 これで、フェデレーテッドカタログの下にあるリモートオブジェクトを検出できます。同じ外部カタログインスタンスに設定された既存の接続を再利用して、他のリモートカタログをオンボードできます。 AWS 分析エンジンを使用したフェデレーテッドカタログオブジェクトのクエリ データレイク管理者として、AWS Lake Formation を使用してフェデレーテッドカタログ内のデータベースとテーブルのアクセス制御を管理できるようになりました。また、タグベースのアクセス制御を使用して、アクセス制御メカニズムに基づいてリソースにタグを付けることで、権限モデルをスケールすることもできます。 権限が付与されると、IAM プリンシパルまたは IAM ユーザーは、Athena、Amazon Redshift、Amazon EMR、Amazon SageMaker などの AWS 分析サービスを使用してフェデレーテッドテーブルにアクセスできます。以下の例に示すように、Athena を使用してフェデレーテッド Iceberg テーブルをクエリします。 クリーンアップ 継続的な料金の発生を避けるため、以下の手順を完了して、このウォークスルーで作成したリソースをクリーンアップします。 Data Catalog のフェデレーテッドカタログを削除します。 aws glue delete-catalog \ --name <your-federated-catalog-name> Lake Formation から AWS Glue 接続の登録を解除します。 aws lakeformation deregister-resource \ --resource-arn <your-glue-connector-arn> Lake Formation の権限を取り消します (付与されている場合)。 # まず既存の権限を一覧表示 aws lakeformation list-permissions \ --catalog-id <your-account-id> \ --resource '{ "Catalog": {} }' # 必要に応じて権限を取り消し aws lakeformation revoke-permissions \ --principal '{ "DataLakePrincipalIdentifier": " <principal-arn> " }' \ --resource '{ "Database": { "CatalogId": " <catalog-id> ", "Name": "<database-name>" } }' \ --permissions ["SELECT", "DESCRIBE"] AWS Glue 接続を削除します。 aws glue delete-connection \ --connection-name <your-glue-connection-to-snowflake-account> Lake Formation と AWS Glue 接続に関連付けられた IAM ロールとポリシーを削除します。 # ロールからポリシーをデタッチ aws iam detach-role-policy \ --role-name <your-lakeformation-role-name> \ --policy-arn <your-lakeformation-policy-arn> # カスタムポリシーを削除 aws iam delete-policy \ --policy-arn <your-lakeformation-policy-arn> # ロールを削除 aws iam delete-role \ --role-name <your-lakeformation-role-name> # ロールからポリシーをデタッチ aws iam detach-role-policy \ --role-name <your-glue-connection-role-name> \ --policy-arn <your-glue-connection-policy-arn> # カスタムポリシーを削除 aws iam delete-policy \ --policy-arn <your-glue-connection-policy-arn> # ロールを削除 aws iam delete-role \ --role-name <your-glue-connection-role-name> Secrets Manager のシークレットを削除します。 # シークレットの削除をスケジュール (7〜30 日) aws secretsmanager delete-secret \ --secret-id <your-snowflake-secret> このクリーンアップガイドは、リモートカタログサーバー内の実際のメタデータや S3 バケット内のデータには影響しません。Data Catalog と Lake Formation のフェデレーション設定にのみ影響します。リモートカタログサーバー内の対応するサービスプリンシパルや設定は、別途対処する必要があります。 依存関係の競合を避けるため、指定された順序でクリーンアップ手順に従ってください。たとえば、AWS Glue カタログオブジェクトが関連付けられている場合、AWS Glue 接続オブジェクトは削除できません。 また、これらのリソースを削除するために必要な権限があることを確認してください。 まとめ この記事では、カタログフェデレーションがマルチベンダーカタログ環境全体で Iceberg テーブルを管理するという増大する課題にどのように対処するかを探りました。Data Catalog が Snowflake Polaris Catalog、Databricks Unity Catalog、およびカスタム Iceberg REST 準拠カタログを含むリモートカタログシステムと通信し、安全なデータアクセスのための一元化された認可と認証情報発行を行うアーキテクチャを説明しました。認証プリンシパルの設定、AWS Glue 接続を使用したフェデレーテッドカタログの作成から、きめ細かな粒度のアクセス制御の実装、AWS 分析エンジンからのリモート Iceberg テーブルの直接クエリまで、セットアッププロセスを説明しました。 カタログフェデレーションには、いくつかの利点があります。 AWS 分析サービスのセキュリティ、ガバナンス、価格性能の利点を維持しながら、Iceberg データが存在する場所でクエリできます 同期プロセスを維持するための運用上のオーバーヘッドとコストを削減できます データの重複と不整合を回避できます 既存のカタログを移行または置き換えることなく、最新のテーブルスキーマにリアルタイムでアクセスできます 詳細については、 リモート Iceberg カタログへのカタログフェデレーション を参照してください。 著者について Debika D は、Amazon SageMaker のシニアプロダクトマーケティングマネージャーで、レイクハウスアーキテクチャのメッセージングと市場投入戦略を専門としています。データと AI に関するあらゆることに情熱を持っています。 Srividya Parthasarathy は、AWS Lake Formation チームのシニアビッグデータアーキテクトです。プロダクトチームやお客様と協力して、分析データプラットフォーム向けの堅牢な機能とソリューションを構築しています。データメッシュソリューションの構築とコミュニティとの共有を楽しんでいます。 Pratik Das は、AWS Lake Formation のシニアプロダクトマネージャーです。データに関するあらゆることに情熱を持ち、お客様と協力して要件を理解し、素晴らしい体験を構築しています。データ駆動型ソリューションと機械学習システムの構築のバックグラウンドを持っています。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 松岡勝也 がレビューしました。

本稿は、2025 年 11 月 24 日に AWS migration-and-modernization Blog で公開された Introducing the AWS Transform discovery tool を翻訳したものです。 The AWS Transform discovery tool は、VMware インフラストラクチャにデプロイする Open Virtual Appliance（OVA）です。このツールは Application Discovery Service Agentless Collector に代わるものです。 AWS Transform discovery tool は、クラウド接続や外部依存関係を必要とせずにオンプレミスでデプロイできる自己完結型アプリケーションとして動作します。このアーキテクチャにより、厳格に規制された業界や、厳格なデータガバナンス要件を持つ組織に適しています。包括的な検出は、移行計画、正確なコスト見積もり、移行リスクの軽減に不可欠です。AWS Transform discovery tool は、ワークロードからパフォーマンスデータとネットワーク接続データの両方を収集します。パフォーマンスデータを収集することで、AWS Transform がワークロードに最もコスト効率の高いインスタンスタイプを推奨することを可能にします。ネットワーク接続データを収集することで、関連する、すべての仮想マシンを同時に確実に移行を行い、誤ってオンプレミスに依存関係を残してしまうことを防ぎます。 このコレクターは、AWS Migration Portfolio Assessment（MPA）形式でエクスポートし、AWS Transform assessment が取り込んで処理することで、総所有コスト分析とビジネスケースを生成します。MPA 形式は、パートナーが AWS と移行データを交換するために使用されます。すべてのデータは、仮想アプライアンス上で収集し、ローカルに保存されます。ツールからエクスポートされたデータは、ワークステーション上のローカルにダウンロードされます。エクスポートされたデータを AWS にアップロードすることを選択しない限り、データは AWS に送信されません。このツールは、インターネットへのアウトバウンドアクセスを必要としません。 前提条件 VMware vCenter に OVA をデプロイする権限が必要です。 アプライアンスは、4 vCPU、16GB RAM、35GB ハードディスクが必要です。 アプライアンスは、エージェントレスアプローチを使用してデータを収集します。アセスメント対象の VM は、アプライアンスからのインバウンド接続を許可する必要があります: Linux – SSH TCP/22 Windows – TCP/5985 for HTTP, TCP/5986 for HTTPS（デフォルトポート。カスタムポート構成もサポートされています） SNMP – UDP/161 Linux の場合、サーバーに SSH 接続できるユーザーアカウントが必要です。 SSH 検出の場合、ツールは ss -tnap を使用します。SSH ユーザーは、sudo を使用して ss コマンドを実行できる必要があります。 ss が利用できない場合、ツールは netstat を代替手段として利用します。 Windows のアカウント要件については documentation を参照してください。 デプロイ アプライアンス をダウンロードします。 標準の OVA デプロイプロセス を使用してアプライアンスをデプロイします。 図 1. AWS Transform discovery tool アプライアンスのデプロイする、OVF デプロイの最後の画面を表示 初期セットアップ AWS Transform discovery tool の管理インターフェースは、ポート 5000 で実行します。アプライアンス VM の IP が 10.250.1.20 の場合、管理インターフェースにはブラウザで https://10.250.1.20:5000 へアクセスします。 管理インターフェースに初めてアクセスする際に、パスワードを作成します。 図 2. AWS Transform discovery tool のパスワード作成 AWS Transform discovery toolにログインした後 Set up access を選択して vCenter Server に接続します。 図 3. vCenter アクセスのセットアップボタン vCenter の FQDN または IP、ユーザー名、パスワードを入力します。https:// は含めず、FQDN または IP のみを入力してください。Windows 認証を使用する場合、Windows ユーザーネームは DOMAIN\user 形式である必要があります。vCenter には読み取り専用アカウントを使用できます。 図 4. vCenter アクセスのセットアップ AWS Transform discovery tool が vCenter Server にアクセスできる場合、ステータスが Connected に変わり、数分後 Last collection に日付と時間が表示されます。 図 5. vCenter 接続の成功と最新の収集日時 検出収集は 1 時間ごとに実行されます。収集を強制する必要がある場合は、Actions メニューから実行できます。 図 6. 検出収集の強制実行 検出されたインベントリは Discovered inventory ページから表示できます。 図 7. 検出されたすべてのインベントリ OS アクセスの構成 初期構成では Set up OS access ボタンが表示されます。以降の構成では Edit OS access ボタンを使用します。 図 8. Edit OS access ボタン 認証情報画面では、SSH と WinRM の両方の認証情報を入力する例を示しています。Windows 資格情報は、WinRM 経由で Windows サーバー全体の SQL Server インストール環境をリモートで調査・収集するために使用され、バージョン情報、エディション詳細、サービス構成、インスタンス名、起動設定、サービスアカウント、クラスタリングステータスを含む、すべてのSQL Serverコンポーネントに関する詳細なメタデータが収集されます。Kerberos を使用する場合、ユーザー名は username@DOMAIN.TLD &nbsp;形式である必要があります – ユーザー名は小文字、ドメインは大文字です。 Auto-connect ボックスにチェックを入れると、AWS Transform discovery tool はすべての VM に対してその認証情報を使用しようとします。ボックスにチェックを入れない場合は、認証情報を手動で割り当てる必要があります。 図9. OS アクセス認証情報 認証情報を手動で割り当てるには Discovered inventory 画面に移動します。フィルターを入力するオプションがあります。この例では、フィルターに atx-wp と入力しました。これは Enter キーを押すと適用されます。 図10. インベントリフィルターの入力 フィルターは一致する VM を選択します。認証情報を割り当てるには、Hostname の横にあるボックスにチェックを入れます。以下に示すように、すべてを選択できます。次に Manage access credential を選択します。 図 11. フィルタリングされたインベントリリストからサーバーを選択してアクセス認証情報を割り当てる ドロップダウンから認証情報を選択し Save and collect を選択します。 図 12. サーバーのリストに対するアクセス認証情報の選択 約 15 秒後、認証情報の割り当てが成功すると Network status 列に Success が表示されます。 図 13. Linux サーバーの認証情報の成功 以下は、Windows VM の例です。まず、Windows 認証情報を割り当てます。 図 14. Windows VM への WinRM 認証情報の割り当て 成功すると Network status 列が Success に変わります。この Windows VM は SQL Server のインスタンスを実行しているため、 Database status 列も Success に変わりました。 図 15. Windows の認証情報の成功 ダウンロード データを収集した後 Download inventory ボタンを使用してインベントリをダウンロードできます。 図 16. Download inventory ボタン これは MySQL バックエンドを持つ Web サーバーで収集されたネットワークデータの例です。 図 17. ソースとターゲットの IP、ターゲットのポートとプロトコルを含むサンプルネットワークデータ 必要に応じて Download logs を使用してトラブルシューティング用のログをダウンロードできます。 図 18. Download logs ボタン クリーンアップ クリーンアップ手順は vCenter インベントリからアプライアンスを削除することだけです。 AWS Transform discovery tool で使用するために特定の OS 認証情報を作成した場合は、認証情報を無効化する必要がある場合があります。 まとめ AWS Transform discovery tool を使用すると、移行の準備として、組織内のサーバーインベントリ、データベースインスタンス、ネットワーク依存関係を自動的に検出できます。クラウド接続や外部依存関係を必要とせずに自己完結型アプリケーションとして動作するため、セキュリティを最も重視する環境にも適しています。 現在のインフラストラクチャに対する包括的な可視性を提供することで、AWS Transform discovery tool は以下を支援します: 将来の AWS 環境を正確にサイジングしてコスト計算する 移行計画に影響を与えるアプリケーションの依存関係を特定する データ駆動型の TCO 分析とビジネスケースを生成する 移行戦略と優先順位について情報に基づいた意思決定を行う AWS Transform discovery tool からダウンロード可能な出力は、AWS Transform assessment にアップロードでき、移行計画のための詳細な TCO 分析とビジネスケース生成を可能にします。このデータ駆動型アプローチは、移行リスクを軽減し、AWS への移行を加速するのに役立ちます。 次のステップ AWS Transform discovery tool の出力を評価に使用できます。出力ファイルに変更を加える必要はありません。AWS Transform assessment に直接アップロードするだけです。評価の作成について詳しくは、AWS Transform assessment の 製品ドキュメント をご確認ください。 <!-- '"` --> Patrick Kremer Patrick Kremer は、インフラストラクチャの移行とモダナイゼーションに焦点を当てたシニアスペシャリストソリューションアーキテクトです。Patrick は 2022 年に AWS に入社し、20 年の VMware 経験を活かして、お客様が AWS ソリューションに移行するのを支援しています。彼は AWS 認定ソリューションアーキテクトプロフェッショナルであり、教育とブログ執筆に情熱を持っています。 Pedro Calixto Pedro Calixto は、AWS のシニアソリューションアーキテクトで、ワークロードの移行とモダナイゼーションを専門としています。彼の焦点は、企業が AWS 内でオンプレミス環境を拡張、移行、保護するのを支援すること、および AWS サービスを使用してアプリケーションのモダナイゼーションを加速することです。 この投稿の翻訳は Solutions Architect の田澤が担当させていただきました。原文記事は こちら です。