本ブログは株式会社サンブリッジ様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの杉山です。 生成 AI の活用シーンが急激に増えてきており、今この瞬間に時代が変化しているのだと感じる毎日です。本日は、社内の業務効率化における生成 AI の活用事例として、株式会社サンブリッジ様 (以下、サンブリッジ様) の取り組みをご紹介します。わずか 2 週間という短期間で構築された社内向け AI チャットボットが、どのように業務改革を実現したのか、その導入プロセスから具体的な成果までをお伝えしていきます。 株式会社サンブリッジ 様は、企業のビジネスモデルに合わせて AWS や Salesforce をはじめとした、お客様の課題解決において最適なクラウドサービスを用いてビジネス分析や導入、運用までをワンストップでトータルコーディネートし、お客様のビジネス拡大・業務改善を支援する企業です。今回、サンブリッジ様は AWS Japan が主催する「生成 AI コンテスト」に参加したことをきっかけに、Amazon Bedrockや Amazon Kendra といった AWS のサービスを組み合わせて、わずか 2 週間で社内向けの AI チャットボットを構築しました。Slack とのシームレスな連携によって問い合わせ対応を集約し、1 週間で累計 1,750 分もの業務時間削減を実現しています。 背景と課題 サンブリッジ様では、企業成長とともに社員数および社内ドキュメントの量が増大してきました。ドキュメントはクラウドストレージやファイルサーバなどに分散しており、アクセス方法も保管場所も統一されていない状態が続いていました。このため、必要な文書へアクセスするだけで大きな手間が発生し、対応に時間がかかる場面が日常的に見受けられました。さらに、部署やプロジェクトによってチャットツールが異なるなど、問い合わせチャネルが複数存在していたことも問題となり、同じような質問が部署ごとに何度も繰り返されるケースが生じていました。結果として特定の社員に問い合わせが集中し、問い合わせを受ける側は「同じ回答を繰り返す」「一貫した回答をするために最新の資料を探す」などの作業に時間を費やす状況になっていました。 ソリューション構築のアプローチ こうした課題を解消するため、サンブリッジ様は AWS Japan 主催の「生成 AI コンテスト」に参加し、社内向けの AI チャットボットを構築するプロジェクトに取り組みました。プロジェクトの進め方としては、まずコンテスト期間という明確な締め切りがあるため、短期間で検証から実装・運用開始まで走り切ることを目標に設定しました。チャットボットには Amazon Bedrock を活用し、大規模言語モデル (LLM) が柔軟かつ安全に応答を生成できるようにしています。さらに Amazon Kendra を組み合わせることで、高精度な検索結果を得られる仕組みも導入されました。これによりチャットボットが回答を生成する際に、質問と関連性の高い文書やナレッジを素早く検索し、根拠のある回答を提示できるようになりました。 接続されるチャットツールとしては Slack を採用し、既に社員が日常的に使っている環境へスムーズに組み込みました。短期間のプロジェクトであることからスコープは最小限に絞り、PoC (概念実証) レベルで AI チャットボットのコア機能を作り込んだうえで、本番環境でのクローズドテストを実施して精度向上や機能追加を行う手法を採用しました。社内文書はおよそ 9,000 件をKendra に登録し、Retrieval-Augmented Generation (RAG) の手法で回答と一次情報 (文書ソース) を紐付ける仕組みも取り入れることで、回答の信頼性を高めています。 導入後の成果 この AI チャットボットは約 80 名の従業員を対象に早期からテスト稼働が行われました。稼働開始から 1 週間で、250 回以上の問い合わせと回答が Slack 内でやりとりされ、従来の問い合わせ対応が抱えていた課題の大部分が解消されています。 1 回の問い合わせに要していた時間は平均 7 分程度であると計算されており、チャットボットを導入して 1 週間の間に対応業務が累計 1,750 分 (約 29 時間) 削減できたという試算が得られました。これは、以前は担当者がドキュメントを探したり他部門と連携を図ったりして回答していた手間を省けるようになったことが大きく寄与しています。回答の根拠となる文書 URL も自動で提示されるため、回答の信頼性が向上しただけでなく、「どこを参照すればよいのか」が明示されることで、社員の情報リテラシー向上や文書の管理意識の再確認といった副次的効果も生まれています。 今後は AWS Glue を活用したコンテンツ収集・登録の自動化を視野に入れており、より多くの社内文書を継続的に Kendra へ取り込むことで、回答の網羅性を高める計画です。サンブリッジ様はこれによって、累計で 50,000 分 (5人月以上) に相当する工数を削減できる可能性を見込んでいます。 今後の展望とまとめ サンブリッジ様は生成 AI コンテストという外部イベントに参加することで、AI チャットボット導入のアイデアを短期間で具体化し、さらに実際の業務上の課題を解決する段階まで速やかに移行できました。今回導入したチャットボットは、すでに問い合わせ集約と回答の一元化による効果を示しており、その成功を踏まえて今後はさらなる機能拡張に着手する方針です。 例えば社内で利用する他のチャットツールや CRM (Salesforceなど) とも連携し、問い合わせの履歴や回答内容をスムーズに共有するなどのアイデアが検討されています。RAG の高度化やユーザーインターフェイスの改善によって、回答の精度向上や使い勝手の向上を追求していく計画です。 サンブリッジ様の取り組みは、わずか 2 週間でチャットボットを立ち上げ、1 週間で 1,750 分の業務効率化を実現するという成果をあげています。こうした成功の背景には、Amazon Bedrock やAmazon Kendra といった AWS のサービスを柔軟に組み合わせ、既存のコミュニケーション基盤である Slack と連携させるという、精度・実用性・導入ハードルを両立する設計上の工夫があります。 「AWS が主催する生成 AI コンテストに参加することで、ユースケース選定からサービス実装までを短期間で実現することができました」と語るのは、株式会社サンブリッジ 執行役員の山﨑 秀樹氏です。その言葉の通り、本事例は生成 AI を業務改善に役立てたいと考えている企業にとって、多くの示唆を与えるものと言えるでしょう。 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

この記事は2025 年 3 月 7 日に公開された「 Introducing an enhanced local IDE experience for AWS Step Functions 」を翻訳したものとなります。 本記事は、シニアソリューションアーキテクトの Ben Freiberg が執筆しました。 AWS Step Functions は、ステートマシンの構築をより簡単にするために、ローカル IDE 機能がより強化されました。これにより、Workflow Studio が AWS Toolkit 拡張機能を通じて Visual Studio Code (VS Code) で利用できるようになりました。 開発者は AWS コンソールと同じ強力な視覚的な編集機能を使用して、ローカル IDE でステートマシンを作成および編集できます。 Step Functions は、開発者が AWS サービスを使用して分散アプリケーションの構築、プロセスの自動化、マイクロサービスのオーケストレーション、データや機械学習 (ML) パイプラインの作成を支援するビジュアルワークフローサービスです。 お客様は、 AWS Lambda 、 AWS Fargate 、 Amazon Bedrock 、 HTTP API 統合 など、複数のサービスを含むワークフローを構築するために Step Functions を選択しています。開発者は、 Workflow Studio を使用して AWS コンソールから、または JSON ベースのドメイン固有言語である Amazon States Language (ASL) を使用してコードとして、これらのワークフローをステートマシンとして作成します。開発者は、アプリケーションやインフラストラクチャ (IaC) コードと共にワークフローの定義を管理します。今や、開発者は AWS コンソールと同じ体験で、VS Code でワークフローを構築およびテストするためのさらなる機能を利用できるようになりました。 ローカルワークフロー開発の簡素化 統合された Workflow Studio により、開発者は自身のローカル IDE 内で Step Functions ワークフローを円滑に構築できます。開発者は AWS コンソールで使用するのと同じキャンバスを使用して、ステートをドラッグ＆ドロップしてワークフローを構築できます。ワークフローを視覚的に修正すると、ASL 定義が自動的に更新されるため、構文ではなくビジネスロジックに集中できます。 Workflow Studio の統合により、作業環境を切り替えることなく、AWS コンソールと同じ直感的で視覚的なステートマシンの設計アプローチを提供します。 はじめに 更新された IDE の操作性を使用するには、VS Code 拡張機能として AWS Toolkit のバージョン 3.49.0 以上がインストールされていることを確認してください。 図 1: AWS Toolkit の更新 AWS Toolkit 拡張機能をインストールした後、ステートマシン定義を開いて Workflow Studio でビルドを開始できます。 ローカルワークスペースの定義ファイルを使用するか、 AWS Explorer を使用してクラウドから既存のステートマシン定義をダウンロードできます。 VS Code の統合機能は、JSON 形式と YAML 形式の ASL 定義をサポートしています。 (注: Workflow Studio が自動的にファイルを開くためには、ファイルの拡張子が .asl.json 、 .asl.yml 、または .asl.yaml である必要があります。) YAML ファイルを使用する場合、Workflow Studio は編集のために定義を JSON に変換し、保存前に YAML に再変換します。 図 2: Workflow Studio のデザインモード VS Code の Workflow Studio は、デザインモードとコードモードの両方をサポートしています。デザインモードでは、ワークフローの構築と確認のためのグラフィカルインターフェイスを提供します。 コードモードでは、統合されたコードエディタを使用して、ワークフローの Amazon States Language (ASL) 定義を表示および編集できます。 次の画面に示すように、Workflow Studio の右上にある Return to Default Editor リンクを選択することで、いつでもテキストベースの編集に戻ることができます。 図 3: Workflow Studio のコードモード VS Code で Workflow Studio を手動で開くには、ワークフロー定義ファイルの上部にある「 Open with Workflow Studio 」アクションを使用するか、エディターペインの右上にあるアイコンを使用します。 以下の画面では、両方のオプションが強調表示されています。 また、ファイルエクスプローラーペインからファイルのコンテキストメニューを使用して Workflow Studio を開くこともできます。 図 4: エディターへの Workflow Studio の統合 Workflow Studio で行った編集は、未保存の変更として元の ASL ファイルに自動的に同期されます。 変更を保存するには、Workflow Studio またはファイルエディタから変更を保存する必要があります。 同様に、ローカルファイルに加えた変更は、保存時に Workflow Studio に同期されます。 Workflow Studio は Definition Substitutions に対応しているため、 AWS CloudFormation や AWS Cloud Development Kit (CDK) などの IaC ツールと統合されたワークフローも編集できます。 Definition Substitutions は CloudFormation の機能で、IaC テンプレートで提供する値への動的な参照をワークフロー定義に追加できます。 AWSTemplateFormatVersion: "2010-09-09" Description: "State machine with Definition Substitutions" Resources: MyStateMachine: Type: AWS::StepFunctions::StateMachine Properties: StateMachineName: HelloWorld-StateMachine DefinitionS3Location: Bucket: amzn-s3-demo-bucket Key: state-machine-definition.json DefinitionSubstitutions: TableName: DemoTable その後、ステートマシンの定義で定義の代替を使用できます。 "Write message to DynamoDB": { "Type": "Task", "Resource": "arn:aws:states:::dynamodb:putItem", "Next": "Remove message from SQS queue", "Arguments": { "TableName": "${TableName}", "Item": { ... omitted for brevity ... } }, "Output": "{% $states.input %}" } このコードは、putItem オペレーションを使用して DynamoDB にメッセージを書き込む Step Functions のタスクステートを定義しています。 ${TableName} という置換構文により、ステートマシンの実行時にパラメータとして渡される動的な DynamoDB テーブル名を使用できます。 テストとデプロイ Workflow Studio の統合により、Step Functions の TestState API を使用して単一のステートをテストできます。 TestState API を使用すると、ステートマシンを作成したり、既存のステートマシンを更新したりすることなく、ローカルの IDE からクラウド上のステートをテストできます。 このにより、ステートマシン全体を呼び出すことなく、個々のステートの変更の作成とデバッグができます。 たとえば、IDE を離れることなく、入出力の処理を改善したり、Choice ステートの条件ロジックを更新したりできます。 状態のテスト Workflow Studio で任意のステートマシン定義ファイルを開きます キャンバスまたはコードタブから State （日本語: 状態）を選択します 右側のインスペクターパネルが開いていない場合は開きます 図 5 ：個別のステートの引数 上部の Test state ボタン（日本語: テスト状態）を選択します IAM ロールを選択し、入力を追加します。 TestState API を使用するために必要な権限 がロールに付与されていることを確認してください。 ステートに Definition Substitutions が含まれている場合、特定の値に置き換えることができる追加セクションが表示されます Start Test （日本語: テストを開始）を選択します 図 6: 定義の置換を含むテストステートの設定 テストが成功したら、AWS Toolkit を使用して IDE からワークフローを公開 できます。 また、 AWS Serverless Application Model 、AWS CDK、CloudFormation などのインフラストラクチャーをコードで管理するためのツールを使用してステートマシンをデプロイすることもできます。 まとめ Step Functions は、VS Code IDE と AWS Toolkit を使用したワークフローの開発を簡素化するため、強化されたローカル IDE 環境を導入しています。 これにより、コーディング、テスト、デプロイ、デバッグのサイクルが効率化され、開発者は Workflow Studio をスムーズに統合できます。 ビジュアルなワークフローデザインと充実した機能を備えた IDE のパワーを組み合わせることで、開発者はより効率的に Step Functions のワークフローを構築できるようになりました。 まず、 AWS Toolkit for Visual Studio Code をインストールし、Workflow Studio の統合に関する ユーザーガイド をご覧ください。 AWS サーバーレスに関する実践的な例、ベストプラクティス、有用なリソースは Serverless Land でご覧いただけます。 翻訳は技術統括本部 ソリューションアーキテクトの 菅原太樹 が担当し、一部を加筆修正しました。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 さて、今年のAWS Summit Japanは6月25日、26日に予定されていますが、 Webサイト がすでにオープンしています。申し込みはまだ先ですが、イベント情報のお知らせ登録もできるので是非ご活用ください。 また、直近で4月に「Tokyo NoSQL Day 2025」というイベントが開催されます。DynamoDBをはじめとする多くのNoSQLデータベースソリューションを学べる機会なのでご活用ください。 — Tokyo NoSQL Day 2025 ～デベロッパーのためのNoSQL入門と実践～ 2025年 4月 9日（水）9:30 – 18:00 場所：目黒セントラルスクエア 21F 申し込みは こちら — それでは、先週の主なアップデートについて振り返っていきましょう。 2025年3月17日週の主要なアップデート 3/17(月) Amazon RDS Custom for SQL Server supports new minor version in February 2025 Amazon RDS Custom for SQL ServerでMicrosoft SQL ServerのDeveloper、Web、Standard、Enterprise の各エディションの最新マイナーバージョンが利用可能になりました。新しいマイナーバージョンは SQL Server 2022 CU17 16.0.4175.1 で、パフォーマンスの向上とセキュリティの修正が提供されます。このマイナーバージョンは、Amazon RDS Custom for SQL Server データベースが利用可能なすべてのAWS商用リージョンで利用可能です。 Amazon Redshift Serverless now supports Current and Trailing Tracks for release updates Amazon Redshift ServerlessがCurrent TrackとTrailing Trackという２つの異なるリリースサイクルでの利用をサポートしました。Current Trackは最新の機能、セキュリティアップデート、パフォーマンス強化を含む最新の認定バージョンが提供され、Trailing Trackは以前の認定リリースを利用します。例えば開発・評価環境はCurrent Trackにより最新版を利用し、ミッションクリティカルなワークロードが動く本番環境はTrailing Trackを使い評価検証を行ってから適用することが可能になります。この機能はAmazon Redshift Serverlessが利用可能なすべての商用AWSリージョンおよびAWS GovCloud（US）リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Configure Amazon Q in Connect directly from Connect Admin Website コンタクトセンターの為のAI支援アシスタントであるAmazon Q in ConnectのAIエージェントの設定やカスタムプロンプトの作成、編集をAmazon Connect管理者ウェブサイト内から実行できるようになりました。Amazon Q in Connectは東京を含む9つのリージョンで利用可能です。具体的なリージョンに関しては こちら をご確認ください。 Salesforce Contact Center with Amazon Connect is now generally available Salesforce Contact Center with Amazon ConnectがGAしました。この統合によりSalesforceをご利用するお客様はService Cloudの機能を通じてAmazon Connectの音声、デジタルチャネル、ルーティング機能とシームレスに連携が可能です。この機能はAmazon Connectが利用可能なすべてのAWSリージョンで利用可能です。詳細については Salesforce Contact Center with Amazon Connect のドキュメント をご確認ください。 3/18(火) AWS announces the next generation of Amazon Connect where powerful AI improves every customer interaction 強力なAIによってすべての顧客接点を向上させる、次世代のAmazon Connectが発表されました。Amazon Connectではこれまでも25言語以上に対応したAI搭載のセルフサービス応答や、エージェント支援、会話分析と品質管理、キャパシティプランニングなどAmazon Q in Connectを始めAIを活用したソリューションを提供していますが、全てのチャネルに対して将来のAI機能の継続的なサポートと、”定額制AI価格”の料金体系がこのアップデートのポイントです。この次世代のAmazon Connectは東京を含む９つのリージョンでワンクリックで有効化でき、 新しい料金の選択肢(現時点では英語のみ反映) にはAI機能の無制限使用が含まれています。機能や料金体系に関してローンチブログが出ているので、 こちら をご確認ください。 AWS WAF now supports URI fragment field matching AWS WAFがこれまでサポートされていたURIパスに加えて、URIフラグメントに対するマッチングをサポートしました。URIフラグメントマッチングは「#」記号の後にあるURLの一部で、例えば、「foo://login.aspx#myFragment」のような動的フラグメントを持つログインページがある場合、「myFragment」フラグメントを持つリクエストのみを許可し、他をすべて拒否するルールを作成できます。これにより、機密領域へのアクセスのブロック、不正アクセスの試みの検出、悪意のある行為者が使用するフラグメントパターンの分析による強化されたボット検出の実装など、対象を絞ったセキュリティ制御が可能になります。この機能に追加の費用はかかりませんが、標準のWAF料金が引き続き適用されます。詳細については ドキュメント をご確認ください。 Amazon Bedrock Guardrails announces policy based enforcement for responsible AI Amazon Bedrock GuardrailsがIAMポリシーベースを強制する機能を発表しました。IAMポリシーで使用できる新しい条件キー bedrock:GuardrailIdentifier をすべてのBedrock Invoke および Converse APIに適用し、モデル推論呼び出しに特定のガードレールを適用することが可能です。Bedrock Guardrailsは、望ましくないコンテンツを検出・フィルタリングする設定可能な保護機能、特定のトピックを定義・禁止するトピックフィルター、個人識別情報（PII）を編集する機密情報フィルター、特定の単語をブロックする単語フィルター 他多様なガードレールを設定できる機能で、これを強制できることでより安全な生成AIアプリケーションを構築することが可能です。この機能はBedrock GuardrailsがサポートされているすべてのAWSリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon CloudWatch RUM now supports monitoring multiple domains with a single App Monitor Amazon CloudWatch RUMで単一のApp Monitorを使用して複数のトップレベルドメイン(TLD)とセカンドレベルドメイン(SLD)を監視できるようになりました。これまでは、例えばexample.comとanother.comなど各ドメインに対して個別のモニターを作成する必要がありました。今回のアップデートによりこれらを1つのApp Monitorで監視でき、複数のドメインからアクセスされるアプリケーションの可観測性の仕組みを簡素化することができます。この機能はCloudWatch RUM が利用可能なすべてのAWS商用リージョンで利用できます。詳細については ドキュメント をご確認ください。また、CloudWatch RUMの使い方を学びたい方は、 One Observability ワークショップ をご活用ください！ 3/19(水) Amazon Nova expands Tool Choice options for Converse API Converse APIの Tool Choice オプションはモデルがどのようなツールを呼び出すかを決定する方法を指定できるものです。Amazon Novaではこれまでツールを呼び出すかテキストを返すかモデルに判断を委ねる「Auto」モードしか選択できませんでした。今回、ツールを少なくとも１つ呼び出す「Any」と特定のツールを呼び出す「Tool」の２つのモードもサポートされました。詳細は ドキュメント もご確認ください。 3/20(木) AWS Network Firewall introduces new flow management feature AWS Network Firewallの新しいフロー管理機能が発表されました。アクティブなフローのpoint-in-time スナップショットを可能にする「フローキャプチャ」と特定の接続を選択し終了できる「フローフラッシュ」という２つの主要機能が追加され、送信元/送信先IPアドレス、ポート、プロトコルなどの基準に基づいてアクティブなフローを表示および管理できるようになりました。この新機能は、AWS Network Firewallがサポートされているすべてのリージョンで追加の費用なしで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Bedrock Model Evaluation LLM-as-a-judge is now generally available Amazon Bedrock Model EvaluationのLLM-as-a-judge機能がGAしました。この機能はAmazon Bedrockで利用可能な複数のLLMから審判を選択し評価を行うことで、より短い時間で、人が行うより低コストに、人間よる判断に近い評価を行うことを可能にします。GAにあたり、評価ジョブの入力プロンプトデータセットに既に取得済みの推論レスポンスを取り込むことで、Amazon Bedrock外でホストされている任意のモデルやアプリケーションでも評価できるようになりました。詳細については ドキュメント をご確認ください。 Amazon Bedrock now supports RAG Evaluation (generally available) Amazon Bedrock RAG 評価がGAしました。この機能では、情報検索のみ、または検索と回答生成の両方を評価することができます。評価は LLM-as-a-Judge テクノロジーによって実行され、開発者は評価モデルを選択することができます。検索評価では、コンテキストの関連性やカバレッジなどの指標、検索と回答生成の評価では、正確性、忠実性（ハルシネーション検出）などの品質指標や、有害性、回答拒否などの責任ある AI 指標から選択ができます。また、GAに際してAmazon Bedrock Knowledge Basesに加え、個別に構築したRAGシステムも評価が可能になりました。詳細についてはこちらの ドキュメント をご確認ください。 IonQ Forte Enterprise now available on Amazon Braket Amazon BraketにIonQの最新の36-qubit Forte Enterprise quantum processing unit (QPU)が追加されました。この新しいデバイスは物理的にスイスに設置されていますが、すべての顧客トラフィックは米国東部（バージニア北部）リージョンを経由してBraket SDKとAPIを経由してアクセス、評価が可能です。Amazon Braketの詳細は ドキュメント をご確認ください。 3/21(金) Amazon SES announces Vade advanced email security Add On for Mail Manager Amazon SES Mail Managerに送受信メッセージに対して高度なコンテンツフィルターを提供するVade Add Onの機能が追加されました。HornetSecurityの協力により開発されたこのAdd Onは行動分析、ヒューリスティック、機械学習を組み合わせてスパムやフィッシング攻撃、マルウェアなどの脅威に対する保護が可能です。この機能は東京、大阪を含む16のリージョンで利用可能です。詳細については ドキュメント をご確認ください。 最後に、以前「 週刊AWS – 2024/11/25週 」で紹介したBedrock EngineerがAWSのサンプルプログラムを紹介するGithubリポジトリの aws-samples に正式に公開されました。生成AIの活用方法のアイディアとしてぜひご活用ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 最近はコーディングする際に AI エージェントがもう手放せなくなってきています。 さて、6 月 25 日（水）、26 日（木）に開催される AWS Summit Japan 2025 の ウェブサイト がオープンしました！最新情報を受け取る登録ができるので是非ご覧ください。 それでは、3 月 17 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Amazon Q Developer CLI での超高速な新しいエージェント型のコーディング体験」を公開 Amazon Q Developer は、インタラクティブなコーディング環境を提供する新しい CLI エージェントを 3 月 6 日に発表しました。本記事では、アプリの構築と Git への commit をエージェントに実行させるデモを通じて、CLI エージェントの使い方を解説しています。開発スタイルが大きく変わるような便利機能です。ぜひお試しください！ ブログ記事「Amazon Q Developer は Java 21 へのアップグレード対応を発表」を公開 Amazon Q Developer は、2 月 14 日に Java 21 へのアップグレード対応を発表 しました。本記事では、Java アプリケーションを Java 21 に簡単にアップグレードする様子を紹介しています。アップグレード後には、変更内容の詳細なサマリーとさらなる改善に向けた推奨事項も提供されるようになっています。 ブログ記事「一般提供が開始された Amazon SageMaker Unified Studio でのより迅速なコラボレーションと構築」を公開 これまでプレビューだった Amazon SageMaker Unified Studio の一般提供が 3 月 13 日に発表されました。Amazon SageMaker Unified Studio は、データ管理やモデル開発を 1 つの環境で実現する統合プラットフォームです。Amazon Bedrock や Amazon Q Developer との統合機能といった新機能について主に紹介をしています。 ブログ記事「Amazon OpenSearch Service による検索ワークショップ(日本語版)のご紹介」を公開 Amazon OpenSearch Service の新しいハンズオンコンテンツ「 Amazon OpenSearch Service 検索ワークショップ 」が公開されました。生成 AI の文脈だと RAG (検索拡張生成) で使われることが多い Amazon OpenSearch Service ですが、ベクトル検索、スパース検索、ハイブリッド検索、リランキングなど複数の検索手法が体験できる内容となっています。 サービスアップデート サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション Amazon Q Business ブラウザ拡張機能の新機能を発表 Amazon Q Business ブラウザ拡張機能に関する複数の新機能を発表しました。新機能では、企業ナレッジへのアクセスや、画像などのマルチモーダルファイルの添付がサポートされ、幅広いデータソースからの質問に対応できるようになりました。また、コンテキストウィンドウが拡大し、より大きなウェブページやファイルを受け取ることができるようになりました。 Amazon Q Business が AWS ヨーロッパ（アイルランド）リージョンで利用可能に Amazon Q Business が AWS ヨーロッパリージョン（アイルランド）で利用可能になりました。 Amazon Connect 管理者ウェブサイトから直接 Amazon Q in Connect を設定可能に カスタマーサービス向けの生成 AI 搭載アシスタントである Amazon Q in Connect を、Amazon Connect 管理者ウェブサイトから簡単に設定できるようになりました。これにより、コンタクトセンター管理者が新製品発売時に AI プロンプトを更新したりすることがより容易にできるようになりました。 サービスアップデート – アプリケーション開発のためのツール  Amazon Bedrock Guardrailsが、責任あるAIのためのポリシーベースの強制機能を発表 Amazon Bedrock Guardrails にて、Identity and Access Management (IAM) ポリシーベースの強制機能が発表されました。IAM ポリシーの新しい条件キー bedrock:GuardrailIdentifier を設定することで Amazon Bedrock のモデル呼び出し時に Amazon Bedrock Guardrails の利用を強制することができます。これにより大規模に安全な生成 AI アプリケーションを構築しやすくなりました。現在 Bedrock Guardrails がサポートされているすべてのリージョンで利用可能です。 Amazon NovaにてConverse APIのToolChoiceオプションを拡張 Amazon Nova は、Converse API における ToolChoice パラメータのオプションを拡張しました。ToolChoice とは Tool Use (Function Calling) にて Tool の選択方法を制御するためのパラメータです。既存の「Auto」モードに加えて、いずれかのToolが呼び出される「Any」モードと、特定のツールを指定する「Tool」モードがサポートされています。システム間の連携時に出力形式を強制するのに特に役に立つアップデートとなっています。 Amazon Bedrock Model Evaluation LLM-as-a-judge 機能が一般提供開始 ユースケースに適したモデルの評価を行う Amazon Bedrock Model Evaluation にて、LLM-as-a-judge 機能が一般提供開始されました。LLM-as-a-judge 機能は、 人間の代わりに LLM がモデル評価を行うことで、モデル評価にかかるコストと時間を削減する機能です。また今回の一般提供開始に伴い「独自の推論レスポンスの持ち込み (bring your own inference responses)」に対応し、Amazon Bedrock 以外のモデルの評価もできるようになりました。 Amazon Bedrock が RAG Evaluation 機能を一般提供開始 RAG の評価を行う RAG Evaluation 機能が一般提供開始されました。RAG Evaluation 機能では、Amazon Bedrock Knowledge Bases やその他の RAG に対し正確性や忠実性（ハルシネーション検出）などの評価が可能です。また前述した LLM-as-a-judge 機能と同様に「独自の推論レスポンスの持ち込み (bring your own inference responses)」にも対応しており、Bedrock Knowledge Base の呼び出しをせずとも評価ができるようになりました。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

2024 年 12月 13 日（金）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #6 （2024 年 12 月 13 日開催） VMware ESXi サーバー環境の棚卸しと最適化：クラウド移⾏とオンプレ活⽤の戦略 株式会社毎⽇放送 経営戦略局 DX推進部 主事 ⽥中 淳史 氏 株式会社毎⽇放送 コンテンツ戦略局 ITビジネス部 主事 村⽥ 博司 氏 株式会社毎日放送では、2019年に購入した VMware ESXi の基盤サーバ上のワークロードの AWS への移行を進めています。移行の対象となるサーバは4ノード構成で、イントラネットワークの管理サーバ、ファイルサーバ、Web サーバ、会議システム、ログ管理サーバ、メールサーバなどをホスティングしていました。AWS が推奨する 7R（7つの移行戦略） を参考に、コストと効果のバランスを考慮して移行作業を進めています。 具体的な移行手法として、DNS サーバを BIND から Amazon Route 53 へと切り替えたり、Web サーバを Amazon EC2 、 Amazon RDS 、 Amazon Aurora など用いて再構築したりするなどの、オンプレミスから AWS への移行と、クラウドネイティブ化、一部ワークロードのオンプレミス間の移行、不要なサーバの廃止などを行っています。また、AWS とオンプレミスとの間に専用線の AWS Direct Connect を導入したり、 AWS Security Hub 、 AWS CloudTrail などを用いてセキュリティの強化などしたりすることも同時に行われました。コスト削減のためには、 AWS Cost Explorer  や AWS Compute Optimizer を活用しています。なお AWS への移行により、柔軟にリソースを用意できるようになったり、ログの管理や収集がしやすくなったりするなどのメリットを感じられています。今後は、 AWS Systems Manager の活用、セキュリティ管理機能の強化、運用監視の一元化などを目指しています。 資料のダウンロードは こちら ⽣成 AI 失敗してみた 東海テレビ放送株式会社 デジタルビジネス局 コンテンツ事業部 プロデューサー ⽇髙 丈尚 氏 東海テレビ放送株式会社では、生成 AI の導入に向けた取り組みを行っています。当初作成した AI チャットに対してのスタッフからの反応が芳しくなかったため、 Generative AI Use Cases JP を導入するなど、実用的なユースケースを見つけるための試行錯誤を繰り返しました。結果、一部の社員がドラマや見逃し配信の PR 制作に活用していることが分かりました。例えば、過去のシーズンの台本を読み込ませて名ゼリフをピックアップすることで、新しいシーズンのPRを作成したり、放送中に X で投稿された感想を読み込んで要約することで、見逃し配信の PR 動画に活用するなどの取り組みです。この方法により、当該動画の再生回数は大幅に増加しました。 この取り組みの中で、生成AIの基盤モデルは妥協しないことが重要であるとの知見も得られました。 Amazon Bedrock にて、Claude 3 Sonnet から Claude 3.5 Sonnet に変更したところ正確性が大幅に向上し、スタッフからの反応が大きく変わりました。今回の取り組みでは、現場のニーズを想像してツールを作るのではなく、生成 AI などの新しいツールを積極的に活用しようとする各部署のキーパーソンを見つけ、各部署の課題に沿ったユースケースを特定することが重要であるという知見も得ることができました 資料のダウンロードは こちら ねったまくんじゃんけんをサーバーレス化！機器制約に直⾯した苦悩と学びの記録 朝⽇放送グループホールディングス株式会社 DXMD 局 橋本 隼佑 氏 朝⽇放送テレビ株式会社 放送技術センター放送実施グループ 宮川 陸 氏 「ねったまくんじゃんけん」は、高校野球中継にて視聴者がリモコンの色ボタンでじゃんけんの手を選ぶと、ランキングが生成され、商品がもらえるというデータ放送のコンテンツです。しかし、毎年、新しい担当者に運用が引き継がれその度に担当者が試行錯誤を繰り返すことや、PHP を用いたレガシーな構成を長年使用していたために処理速度が遅いなどの問題がありました。また、高校野球中継が無い時間帯にもシステムが稼働し続けていたために、コストが掛かり続けるとの課題もありました。 そこで AWS Site-to-Site VPN と Amazon VPC を用いてプライベートな通信を確立するとの従来の構成は維持したまま、 AWS Lambda と Amazon DynamoDB を組み合わせたサーバレスアーキテクチャに移行しました。さらに、PHP から Python へのコードの移行も行っています。データ放送コンテンツからの通信には HTTP を用いていますが、AWS で処理できる HTTPS へと変換をするために、 Amazon API Gateway と Amazon CloudFront を使用しています。今回のシステムの再構築により費用は 83% も削減され、処理速度も10秒程度まで改善されました。今後は、 AWS CloudFormation 等を用いたサービスの一括立ち上げを検討しています。 資料のダウンロードは こちら 動画の視聴は こちら 報道素材クラウドアーカイブシステムの構築 株式会社毎⽇放送 報道情報局 報道業務部⻑ 寺下 智 氏 株式会社毎⽇放送 総合技術局 制作技術センター 部次長 伊藤 亮介 氏 株式会社毎日放送は、保管するメディアの増加による本社ライブラリーの不足、茨木市の倉庫からの取り寄せに時間がかかること、テープメディアのリスク、メディアのマイグレーションの必要性などの従来の報道ライブラリーの課題を解決すべく、AWS 上に報道素材クラウドアーカイブシステムを構築しました。このシステムでは、素材は NV センターのサーバーに一度収録され、マザー素材とオンエア素材の両方がオンプレミス上のニアラインサーバに一定期間保存されるとともに、 AWS 上の Amazon S3 Glacier Deep Archive にこれらの素材が無期限に保存されます。AWS 上でオンエア素材は XDCAM MPEG HD 422（映像レート 50Mbps）で保存され、マザー素材は XAVC（25Mbps）で保存されます。システムの構築時点では 1.5 PB の過去素材が存在し、2026年9月にはこれらの AWS への移行が全て完了する予定です。利用者は、報道支援システムを使用して素材を検索し、低解像度の映像を見ながら必要な部分を選択することが可能です。システムは選択した素材をニアラインサーバー、もしくは Amazon S3 Glacier Deep Archive から取得します。 本システムの特徴としては、日本国外の 米国東部 (バージニア北部)リージョン を利用することで、東京や大阪のリージョンと比べて約半分の利用料を実現している点です。また、データアーカイブ専用に設計されている Amazon S3 Glacier Deep Archive を利用することも、コスト圧縮に一役買っています。また、 AWS Elemental MediaConvert を用いて必要な素材のみを切り出すことで、ダウンロードコストの圧縮も実現しています。今後の予定としては、承認フローのオンライン化を検討しており、一部残っている紙ベースによる申請を廃止します。また、素材を取り出せるライブラリー端末を社内各所に配布することも検討しています。 在阪局で⼀緒に取り組めることを考えてみた 讀賣テレビ放送株式会社 技術局 制作技術担当 番組編集 藤井 一也 氏 株式会社毎⽇放送 総合技術局 制作技術センター 部次長 伊藤 亮介 氏 朝日放送テレビ株式会社 技術局 放送技術センター 放送情報グループ チーフ 兼 技術戦略部 荒木 優 氏 テレビ大阪株式会社 技術局 システム開発部 部長 野口 新一 氏 関西テレビ放送株式会社 DX推進局 DX戦略部 主任 石井 克典 氏 クラウドサービス等の普及によって、同一のシステムを複数の放送局で共用することのできる環境が整ってきたことから、在阪5局の担当者が集まり AWS の提案に乗る形で共通のシステムの検討やガイドラインの策定を試みました。例えば、放送番組や CM を正確に送出するためのマスターシステムを現在は各局が保有していますが、個別にシステムを構築していくことは運用コストやメンテナンスの負担が大きいとの課題があり、本検討会でも共用利用についての検討を行いました。また、これらのシステムをクラウドに移行するにあたっては、セキュリティに関する検討も重要となります。 そこで本プロジェクトでは、3つの試みにチャレンジしました。1つ目は共通のセキュリティガイドラインの策定です。AWS をはじめとするクラウドを共通で利用するにあたっては、各放送局が同程度の水準のセキュリティ対策を講じることが不可欠です。このため、AWS が用意したセキュリティリファレンスを基に作成したガイドラインにより、各放送局が AWS を利用する際の最低限のセキュリティ対策を統一し、コストの削減とセキュリティの強化が図れることが期待されています。2つ目のチャレンジは Amazon GuardDuty の導入です。先述のセキュリティリファレンスにも記載されている Amazon GuardDuty は、不正アクセスやマルウェアの検出が可能で、これを有効化することにより各放送局のセキュリティをより強化することが可能です。最後はシステムの共用化の検討です。システムの共用化は、同一地域の放送局同士で行う場合と系列局の枠組みで行う場合が考えられます。 本プロジェクトは今後も活動を継続予定で、クラウドを利用する際のセキュリティに関する検討と並行して、2025年はクラウドマスターに関する取り組みを本格化させる予定です。 資料のダウンロードは こちら 動画の視聴は こちら まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

多くのお客様がSAP のソースデータと SAP 以外のソースデータを組み合わせて活用したいと考えています。このようなデータ分析のユースケースは、データウェアハウスやデータレイクを構築することで実現できます。お客様は AWS Glue の SAP OData コネクタを使用して、SAP からデータを抽出できます。SAP OData コネクタは、オンプレミス又はクラウド (ネイティブと SAP RISE) で稼働しているシステムの両方をサポートしています。 AWS Glue の SAP OData コネクタを使用すると、AWS Glue と Apache Spark で効率的な処理のためにデータをシームレスに分散処理できます。AWS Glue は、サーバーレスのデータ統合サービスで、分析、機械学習 (ML)、アプリケーション開発などに対し、複数のソースからデータを検索、準備、移動、結合することが簡単になります。 AWS Glue の SAP OData コネクタは、データ抽出のために SAP ODP フレームワークと OData プロトコルを使用します。このフレームワークは、プロバイダ・サブスクライバモデルで動作し、SAP システムと SAP 以外のターゲット間のデータ転送を実現しています。ODP フレームワークは、Operational Delta Queues (ODQ) メカニズムを通じて、フルデータ抽出と差分データキャプチャをサポートしています。SAP のデータ抽出のソースとして、SAP データエクストラクタ、ABAP CDS ビュー、SAP BW・BW/4 HANA ソース、SAP ABAP ソースの HANA Information ビュー、または ODP 対応の他のデータソースを使用できます。 SAP のソースシステムには履歴データが保持されており、常に更新があります。このため、ソースの変更を増分処理できるようにすることが必要です。このブログでは、SAP からデータを抽出し、SAP ODP フレームワークとデルタトークンを使用して SAP ソースからの増分データ抽出を実現する方法を説明します。 ソリューションの概要 SAP ソース システムに保存されている製品データを分析したいと考えている例になります。お客様は、現在提供している製品ラインナップ、特に各品目グループに含まれる製品の数を把握したいと考えています。それには、SAP 品目マスターと SAP システムの品目グループ データ ソースからのデータを結合する必要があります。SAP 品目マスター データは増分抽出で使用できますが、SAP 品目グループはフル ロードでのみ使用できます。これらのデータ ソースを結合し、分析のためにクエリできるようにする必要があります。 前提条件 このブログで紹介したソリューションを実装するには、まず次の前提条件のステップを実施してください。 SAP システムの SAP Gateway で、ODP データソースを使って SAP OData サービスを設定します。 SAP データを保存するための Amazon Simple Storage Service (Amazon S3) バケットを作成します。 AWS Glue Data Catalog で、 sapgluedatabase という名前のデータベースを作成します。 AWS Glue の抽出、変換、ロード (ETL) ジョブで使用する AWS Identity and Access Management (IAM) ロールを作成します。このロールには、Amazon S3 と AWS Secrets Manager を含むすべての必要なリソースへのアクセス権限を付与する必要があります。このブログのソリューションでは、このロールを GlueServiceRoleforSAP と名付けます。以下のポリシーを使用します。 AWS 管理ポリシー: AWSGlueServiceRole SecretsManagerReadWrite インラインポリシー: { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObjectAcl", "s3:GetObject", "s3:GetObjectAttributes", "s3:ListBucket", "s3:DeleteObject", "s3:PutObjectAcl"], "Resource": [ "arn:aws:s3:::<S3-BUCKET-NAME>", "arn:aws:s3:::<S3-BUCKET-NAME>/*" ] } ] } SAP 用の AWS Glue 接続先の作成 SAP コネクタは、CUSTOM ( SAP BASIC 認証) と OAUTH の両方の認証方式をサポートしています。この例では、BASIC 認証で接続します。 AWS マネジメントコンソール で AWS Secrets Manager サービスを開いて、 ODataGlueSecret という名前のシークレットを作成します。AWS Secrets Manager の詳細には、次のコードを含める必要があります。 <your SAP username> の部分にあなたの SAP システムのユーザー名を、 <your SAP username password> の部分にそのパスワードを入力します。 { "basicAuthUsername": " <your SAP username> ", "basicAuthPassword": " <your SAP username password> ", "basicAuthDisableSSO": "True", "customAuthenticationType": "CustomBasicAuth" } SAP OData データソースを選択して、AWS Glue で SAP への接続先 GlueSAPOdata を作成します。 SAP ソースの適切な値を使用して接続を構成します。 アプリケーションホスト URL : ホストには、SAP ホスト名を認証するための SSL 証明書が必要 アプリケーションサービスパス: /sap/opu/odata/iwfnd/catalogservice;v=2; ポート番号 : SAP ソースシステムのポート番号 クライアント番号 : SAP ソースシステムのクライアント番号 ログオン言語 : SAP ソースシステムのログオン言語 認証 セクションで、 認証タイプ に CUSTOM を選択します。 前の手順で作成した シークレット SAPODataSecret を選択します。 ネットワークオプション セクションで、SAP システムへ接続するための VPC 、 サブネット 、 セキュリティグループ を入力します。SAP システムへの接続の詳細については、 ETL ジョブ用の VPC を構成する を参照してください。 SAP からデータを取り込むための ETL ジョブの作成 AWS Glue コンソールで、新しいビジュアルエディターでジョブを作成します。 AWS Glue コンソールにアクセスします。 ナビゲーションペインの ETL ジョブ の下にある Visual ETL を選択します。 Visual ETL を選択して、ビジュアルエディターでジョブを作成します。 ジョブ名をデフォルトの名称から Material Master Job に編集し、 保存 を選択します。 ビジュアルエディターキャンバス上で、SAP ソースを選択します。 Visual タブを選択し、プラス記号をクリックして Add nodes メニューを開きます。SAP を検索し、SAP OData Source を追加します。 追加したノードの名前を Material Master Attributes に設定します。 SAP OData connection では、 GlueSAPOData 接続先を選択します。 SAP ソースから製品マスタ、サービス、エンティティセットを選択します。 Entity Name と Sub Entity Name では、SAP ソースの SAP OData エンティティを選択します。 Fields から、 Material、Created on、Material Group、Material Type、Old Matl number、GLUE_FETCH_SQ、DELTA_TOKEN、DML_STATUS を選択します。 フィルターに limit 100 と入力し、プレビューの表示にかかる時間を制限します。 この OData サービスは差分抽出をサポートしているため、 増分転送 オプションがデフォルトで選択されています。 AWS Glue サービスロールの詳細を選択した後、データプレビューが使用可能になります。プレビューで表示されるように、次の 3 つの新しいフィールドを含めることができます。各フィールドの意味は下記の通りです。 glue_fetch_sq : これはシーケンスフィールドで、レコードが受信された順序の EPOC タイムスタンプから生成され、各レコードで持つユニークの値です。ソースシステムの変更順序を確認する必要がある場合に使用できます。 delta_token : 最後に抽出されたレコードのみに値が含まれ、それ以外のすべてのレコードには空白になります。これは変更されたレコード (CDC) をキャプチャするための ODQ トークン値です。このレコードはソースからのトランザクションデータレコードではなく、デルタトークン値を渡す目的だけで存在します。 dml_status : これは、ソースから新規挿入および更新されたレコードに対して UPDATED、ソースから削除されたレコードに対して DELETED と表示されます。 デルタ対応の抽出では、最後に抽出されたレコードに DELTA_TOKEN の値が含まれ、上記のように delta_token フィールドが埋められます。 ビジュアルキャンバスに別の SAP ODATA ソース接続を追加し、このノードを Material Group Text と名付けてください。 SAP ソースから製品グループの OData サービスとエンティティセットを選択します Entity Name と Sub Entity Name については、SAP ソースの SAP OData エンティティを選択します この サービスはフル抽出のみをサポートしているため、 完全転送オプション がデフォルトで選択されています。また、このデータセットをプレビュー表示することもできます。 データをプレビューで表示するときは、 language key に注目してください。フィルタがなければ SAP はすべての言語を渡すようになるため、 SPRAS = 'E' というフィルターを追加して、英語のみを抽出します。ここのフィルタ―の値はフィールドの SAP 内部書式の値を使います。 Material Group Text の後に、キャンバスに Change Schema 変換ノードを追加します。 target key で、製品グループフィールドの名前を matkl2 に変更します。これにより、最初のソースとは異なる名前になります。 Drop チェックボックスで、 spras 、 odq_changemode 、 odq_entitycntr 、 dml_status、delta_token 、 glue_fetch_sq を選択します。 キャンバスに Join 変換ノードを追加し、両方のソースデータセットを結合します。 Node parents で Material Master Attributes と Change Schema 両方が選択します。 Join type として Left join を選択します。 各ソースのキーフィールドを Join conditions として設定します。 Material Master Attributes では matkl を選択します Change Schema では matkl2 を選択します 出力をプレビューして、正しくデータが読み込まれていることを確認できます。これで結果を保存する準備ができました。 キャンバスにターゲットの S3 バケットを追加します。 ノードの親が Join に指定します。 フォーマット では、 Parquet を選択します。 S3 ターゲットロケーション では、前提条件の章で作成した S3 バケットを参照し、 materialmaster/ を S3 ターゲットロケーション に追加します。 データカタログ更新オプション では、 Create a table in the Data Catalog and on subsequent runs, update the schema and add new partitions を選択します。 データベース では、前に作成した AWS Glue データベース sapgluedatabase の名前を選択します。 テーブル名 には materialmaster と入力します。 保存ボタン をクリックしてジョブを保存します。ジョブは次の図のようになります。 ETL ジョブのクローンして差分対応実施 ETL ジョブを作成したら、デルタトークンを使用してインクリメンタルデータ処理を含めるためのクローンの準備が整います。 これを行うには、ジョブスクリプトを直接修正する必要があります。スクリプトを修正して、最後のデルタトークン (ジョブタグに格納される) を取得するステートメントを追加し、デルタトークン値をリクエスト (またはジョブの実行) に追加します。これにより、次回のジョブ実行時にデータを取得する際に、デルタ対応の SAP OData サービスが有効になります。 最初のジョブの実行では、タグにデルタトークン値がないため、呼び出しは初回実行となり、その後デルタトークンがタグに格納されて、将来の実行に使用されます。 AWS Glue コンソールに移動します。 ナビゲーションペインの ETL Jobs の下にある Visual ETL を選択します。 Material Master Job を選択し、 Actions を選んで Clone job を選択します。 ジョブの名前を Material Master Job Delta に変更し、 Script タブを選択します。 各ジョブ実行時のデルタトークンの保存と取得を行うための追加の Python ライブラリを追加する必要があります。これを行うには、 Job Details タブに移動し、下にスクロールして Advanced Properties セクションを展開します。 Python library path に次のパスを追加します。 s3://aws-blogs-artifacts-public/artifacts/BDB-4789/sap_odata_state_management.zip 次に Script タブを選択し、右上の Edit script を選択します。Confirm を選択して、ジョブがスクリプトのみであることを確認します。 デルタトークンを有効にするには、スクリプトに次の変更を加えてください。 ステップ 5 で追加した SAP OData ステート管理ライブラリクラスをインポートするため、次のコードを 8 行目に追加します。 from sap_odata_state_management.state_manager import StateManagerFactory, StateManagerType, StateType 次の数ステップでは、デルタトークンをジョブタグに取得して永続化し、後続のジョブ実行からアクセスできるようにします。デルタトークンは SAP ソースへの要求に追加され、増分変更が抽出されます。 トークンが渡されない場合、ロードは初回ロードとして実行され、トークンが次回の実行用に永続化されます。その次の実行はデルタロードになります。 sap_odata_state_management ライブラリを初期化するため、接続オプションを変数で定義して、ステートマネージャーでその変数の値を定義します。これを行うには、 job.init ステートメントの後 16 行目に次のコードを追加します。 <key of MaterialMasterAttributes node>  と  <entityName for Material Attribute> は、既存の生成されたスクリプトの # Script generated for node Material Master Attributes コードに値が入っているのでそこからコピーできます。適切な値に置き換えてください。 key = "<key of MaterialMasterAttributes node>" state_manager = StateManagerFactory.create_manager( manager_type=StateManagerType.JOB_TAG, state_type=StateType.DELTA_TOKEN, options={"job_name": args['JOB_NAME'], "logger": glueContext.get_logger()} ) options = { "connectionName": "GlueSAPOData", "entityName": "<entityName for Material Attribute>", "ENABLE_CDC": "true" } connector_options = state_manager.get_connector_options(key) options.update(connector_options) Material Master Attributes ノードに生成された既存のスクリプトの前に # を付け加えてコメントアウトし、次の置換スニペットを追加します。 <key of MaterialMasterAttributes node> = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options=options, transformation_ctx="<key of MaterialMasterAttributes node>") ダイナミックフレームからデルタトークンを読み取って、ジョブのタグに保存するには、スクリプトの最後の行 job.commit() の前に次のコードスニペットを追加します。 state_manager.update_state(key, <key of MaterialMasterAttributes node>.toDF()) 最終的にスクリプトは次のようにになるイメージです。 import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.dynamicframe import DynamicFrame from sap_odata_state_management.state_manager import StateManagerFactory, StateManagerType, StateType args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) key = "MaterialMasterAttributes_node1730873953236" state_manager = StateManagerFactory.create_manager( manager_type=StateManagerType.JOB_TAG, state_type=StateType.DELTA_TOKEN, options={"job_name": args['JOB_NAME'], "logger": glueContext.get_logger()} ) options = { "connectionName": "GlueSAPOData", "entityName": "/sap/opu/odata/sap/ZMATERIAL_ATTR_SRV/EntityOf0MATERIAL_ATTR", "ENABLE_CDC": "true" } # Script generated for node Material Group Text MaterialGroupText_node1730874412841 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options={"ENABLE_CDC": "false", "connectionName": "GlueSAPOData", "FILTER_PREDICATE": "SPRAS = 'E'", "ENTITY_NAME": "/sap/opu/odata/sap/ZMATL_GROUP_SRV/EntityOf0MATL_GROUP_TEXT"}, transformation_ctx="MaterialGroupText_node1730874412841") # Script generated for node Material Master Attributes #MaterialMasterAttributes_node1730873953236 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options={"ENABLE_CDC": "true", "connectionName": "GlueSAPOdata", "FILTER_PREDICATE": "limit 100", "SELECTED_FIELDS": "MATNR,MTART,MATKL,BISMT,ERSDA,DML_STATUS,DELTA_TOKEN,GLUE_FETCH_SQ", "ENTITY_NAME": "/sap/opu/odata/sap/ZMATERIAL_ATTR_SRV/EntityOf0MATERIAL_ATTR"}, transformation_ctx="MaterialMasterAttributes_node1732755261264") MaterialMasterAttributes_node1730873953236 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options=options, transformation_ctx="MaterialMasterAttributes_node1730873953236") # Script generated for node Change Schema ChangeSchema_node1730875214894 = ApplyMapping.apply(frame=MaterialGroupText_node1730874412841, mappings=[("matkl", "string", "matkl2", "string"), ("txtsh", "string", "txtsh", "string")], transformation_ctx="ChangeSchema_node1730875214894") # Script generated for node Join MaterialMasterAttributes_node1730873953236DF = MaterialMasterAttributes_node1730873953236.toDF() ChangeSchema_node1730875214894DF = ChangeSchema_node1730875214894.toDF() Join_node1730874996674 = DynamicFrame.fromDF(MaterialMasterAttributes_node1730873953236DF.join(ChangeSchema_node1730875214894DF, (MaterialMasterAttributes_node1730873953236DF['matkl'] == ChangeSchema_node1730875214894DF['matkl2']), "left"), glueContext, "Join_node1730874996674") # Script generated for node Amazon S3 AmazonS3_node1730875848117 = glueContext.write_dynamic_frame.from_options(frame=Join_node1730874996674, connection_type="s3", format="json", connection_options={"path": "s3://sapglueodatabucket", "compression": "snappy", "partitionKeys": []}, transformation_ctx="AmazonS3_node1730875848117") state_manager.update_state(key, MaterialMasterAttributes_node1730873953236.toDF()) job.commit() 変更を保存するには、 保存 ボタンを選択します。 実行 をクリックしてジョブを実行します。この時点は、ジョブの詳細タブにはタグがありません。 ジョブの実行が正常に完了するまで待ちます。ステータスは 実行 タブで確認できます。 ジョブの実行が完了すると、 ジョブの詳細の タブでタグが追加されたことがわかります。次のジョブの実行では、このトークンを読み取り、デルタロードが実行されます。 SAP からのデータに対するクエリ AWS Glue ジョブの実行により、Data Catalog にエントリが作成されたので、すぐにデータをクエリすることができます。 Amazon Athena コンソールを開きます。 Launch Query Editor を選択します。 適切なワークグループが割り当てられていることを確認するか、必要に応じて ワークグループを作成 します。 sapgluedatabase を選択し、次のようなクエリを実行してデータの分析を開始します。 select matkl, txtsh, count(*) from materialmaster group by 1, 2 order by 1, 2 ; クリーンアップ 追加料金が発生しないよう、このブログで使用した AWS リソースを削除します。削除するリソースは、AWS Glue ジョブ、SAP OData 接続先、Glue データカタログエントリ、Secrets Manager のシークレット、IAM ロール、S3 バケットに保存しているファイル、S3 バケットです。 結論 このブログでは、サーバーレスで複数の SAP データソースからのデータ抽出と差分抽出プロセスを作成する方法を説明しました。この方法では、AWS Glue を使用して SAP ODP デルタトークンを利用し、SAP ソースからデータを差分で抽出し、Amazon S3 にデータをロードしました。 AWS Glue はサーバーレスのサービスなので、インフラストラクチャの管理は不要で、ジョブの実行中に使用されたリソースに料金が発生します (データ保存先のストレージコストも発生します)。組織がますますデータドリブンになるにつれ、この SAP コネクタは、SAP ソースデータをビッグデータの分析やコストに効果的で高性能、且つセキュアに取り込むことができます。詳細は AWS Glue をご覧ください。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。 著者について Allison Quinn はメルボルン (オーストラリア) に拠点を置く Sr. ANZ Analytics Specialist Solutions Architect で、同地域の金融サービス顧客と密接に協力しています。Allison は SAP 製品で 15 年以上の経験があり、現在は AWS ネイティブサービスに分析技術の専門性を集中させています。データに関するすべてのことに情熱を持ち、あらゆる種類の顧客がビジネス上の利益を得られるようデータの民主化を目指しています。 Pavol は、AWS のイノベーションソリューションアーキテクトで、EMEA 地域における SAP クラウド導入を専門としています。20 年以上の経験を持ち、グローバル顧客の AWS への SAP システムの移行と最適化を支援しています。Pavol は、AWS のアジリティ、レジリエンシー、パフォーマンスを活用して、SAP 環境をクラウドに移行するための戦略を立案しています。顧客に対して、AWS の AI/ML、データ分析、アプリケーションサービスを利用して SAP ランドスケープを近代化し、インテリジェンス、自動化、パフォーマンスを向上させるのを支援しています。 Partha Pratim Sanyal は、カナダのバンクーバーにある AWS Glue のソフトウェア開発エンジニアで、データ統合、分析、接続に特化しています。豊富なバックエンド開発の専門知識を持ち、顧客中心のインパクトのある優れたソリューションを作ることに尽力しています。ユーザーがデータを簡単に分析・理解できるような機能を構築することに重点を置いています。Partha は、複雑なユーザーニーズに対処し、データのアクセシビリティと洞察力を高めるための直感的で価値のある体験を創出することに熱心です。 Diego は、SAP テクノロジーに 20 年以上の経験を持つエンタープライズソリューションアーキテクトで、SAP のイノベーション、データ分析に特化しています。パートナーとしても顧客としても働いた経験があり、システムと組織を販売、実装、運用するために必要なことを完全に理解しています。テクノロジーとイノベーションに情熱を持ち、顧客の成果とビジネス価値の提供に重点を置いています。 Luis Alberto Herrera Gomez は、バンクーバーの AWS Glue でソフトウェア開発エンジニアを務めています。バックエンドエンジニアリング、マイクロサービス、クラウドコンピューティングに特化しています。Amazon と AWS に入社する前に複数のスタートアップでバックエンドおよびフルスタック開発者を経験し、7 〜 8 年の経験があります。Luis は、スケーラブルで効率的なクラウドベースのアプリケーションの開発に注力しています。AWS テクノロジーに関する専門知識を活かし、複雑なデータ処理タスクを処理できる高性能システムを設計しています。Luis は、クラウドコンピューティングを活用して、難しいビジネス課題を解決することに情熱を持っています。

この記事は Build a Unified Patient Index Using AWS Entity Resolution (記事公開日: 2025 年 2 月 14 日) を翻訳したものです。 医療機関や公衆衛生機関は、膨大な量の患者データを扱っています。複数の、場合によっては接続されていないデータソースにわたって機密性の高い患者情報を正確に管理し、リンクすることは、医療の連携、研究、そして公衆衛生活動にとって極めて重要です。正確な統合患者インデックスを構築することで、医療提供者は包括的な患者履歴にアクセスでき、研究者は堅牢なデータセットを構築でき、公衆衛生当局は疾病の傾向や結果について洞察を得ることができます。 しかし、データ入力の不整合は、正確な患者識別に重大な課題をもたらす可能性があります。これらの問題は、名前の綴りやフォーマットの違いだけでなく、ニックネームや敬称の使用、複数の接点における連絡先情報の不一致、住所の項目や略語の標準化の不一致にまで及びます。様々なデータ入力の不整合は、患者レコードの断片化につながり、潜在的に医療の質や患者の安全性を損なう可能性があります。これらの課題は以下のような結果をもたらす可能性があります： 不完全な患者レコード 患者ケアにおける、データに基づかない意思決定 公衆衛生の課題への対応の困難さ 効果的な研究の障壁 非効率な医療連携 医療費の増加 患者満足度の低下 マスター患者インデックス (MPI) の構築は、これらの課題の解決にも役立ちます。なぜなら、MPI は個人に関連するレコードに割り当てられた個人ベースの永続的な識別子を持つ、一元化されたレジストリとして機能するためです。インデックス化された患者レコードに部分的なレコードをマッチングすることで、統合され、継続的に進化する患者のビューを作成することができ、これによってダウンストリームの消費者アプリケーション間での効果的な医療連携と研究が可能になります。 HIPAA に適格な AWS サービスを使用することで、医療機関は AWS Entity Resolution で患者レコードを処理し、 Amazon Connect Customer Profiles でメンバー情報を統合し、 Amazon Q in Connect の機能を活用して、パーソナライズされたタイムリーな患者ケアを提供することができます。 AWS Entity Resolution を使用することで、企業や組織は、複数のアプリケーション、チャネル、データストアに存在する関連する顧客または医療記録を照合、リンク、および強化することができます。このサービスは、ルールベース、機械学習 (ML) 駆動、およびデータサービスプロバイダーによる柔軟で設定可能なマッチング技術を提供し、データの正確性を向上させ、顧客のビジネスニーズに基づいて関連レコードを強化するのに役立ちます。AWS Entity Resolution を使用すると、顧客はエンティティマッチング技術を設定でき、手動データ入力や低品質データに関連する課題を組織が克服するのに役立ちます。このサービスは、データの移動を最小限に抑えることで、医療データアーキテクチャのセキュリティ体制を改善します。Amazon Simple Storage Service (Amazon S3) や AWS Glue など、広く普及している AWS サービスを活用することで、既存の医療データアーキテクチャパターンとシームレスに統合されます。 AWS Entity Resolution を使用して患者レコードを処理した後、ヘルスケア企業は Amazon Connect の機能を活用して、プロアクティブなサービスを提供し、患者ケアのニーズを予測することができます。 Amazon Connect Customer Profiles を使用することで、医療機関は必要な患者の同意を得た上で、複数のソースからメンバーや患者の情報を統合することができます。 Amazon Q in Connect を Amazon Connect Customer Profiles と統合することで、ヘルスケア企業はリアルタイムで患者のニーズを検出し、タイムリーでパーソナライズされた患者ケアを提供することができます。 このブログでは、独立系ソフトウェアベンダー (ISV) 、医療提供者、および保険支払機関が、一般に公開されている人工的に生成されたデータセットを使用して、AWS Entity Resolution を活用して関連する患者レコードを特定、およびマッチングする方法をデモンストレーションします。 図 1 – ハイレベルアーキテクチャ図 患者データセット このソリューション例では、 小児肥満データイニシアチブ (CODI) プロジェクト用に作成された合成データセットを使用しています。合成患者の医療履歴をモデル化するオープンソースの合成患者生成ツールである Synthea を使用して、一部の個人について複数の分割レコードを生成しました。これらの分割レコードでは、実際のシステムで想定されるように、人口統計情報が様々な形で変化する可能性があります。例えば、あるレコードでは名前が「John」であり、別のレコードでは「Johnny」というように表記が異なる場合があります。 患者データセットの構造 この例で使用している患者データは、分析のために FHIR フォーマットから CSV に変換されています。このデータセットには約 6,300 件のレコードが含まれており、データセット全体で患者のマッチングに必要な個人識別情報 (PII) を含む列があります。 以下の表は、患者データの構造を説明しています。データには、州名 (statename) 、郵便番号 (postalcode) 、住所 (address) 、国名 (countryname) 、市区町村名 (cityname) 、生年月日 (birthdate) 、固有 ID (uniqueid) 、名 (firstname) 、ミドルネーム (middlename) 、姓 (surname) 、リソースタイプ (resourcetype) 、電話番号 (phonenumber) などのフィールドが含まれています。これらのフィールドは、同一人物を参照するレコードをリンクするエンティティ解決プロセスで一般的に使用されます。データに含まれるフィールドの規模と多様性は、潜在的なエンティティマッチング技術を実証するのに適しています。 図 2 – 合成データセットのサンプルデータ AWS Entity Resolution ワークフローを実行するために、与えられた患者データを Amazon S3 バケットにアップロードしました。その後、AWS Glue クローラーがファイルを処理して、自動的にスキーマを判断し、AWS Glue Data Catalog のテーブルとしてメタデータを更新します。次に、AWS Entity Resolution コンソール画面に移動します。 AWS Entity Resolution コンソール で、メニューから「スキーママッピング」オプションを選択し、「スキーママッピングの作成」をクリックします。スキーママッピングは、解決に使用される元データとそれに含まれる属性について、サービスに情報を提供します。 図 3 – AWS Entity Resolution のスキーママッピング作成画面 「スキーママッピングの作成」画面で、ソースデータを表す AWS Glue データベースとテーブルを選択します。この記事では、患者データを含む「patientdata」テーブルを持つ、「demodb」という名前のデータベースを使用しました。このデータベースは、患者データを格納した Amazon S3 バケットで AWS Glue クローラーを実行した際に作成されました。 図 4 – AWS Entity Resolution のスキーママッピング設定画面 次に、ドロップダウンからユニーク ID (Unique ID) を選択します。ユニーク ID カラムは、データの各行を一意に参照するものでなければなりません – これはデータベースの主キーカラムのようなものと考えてください。この場合、CSV ファイルの「uniqueid」がそれに該当します。 図 5 – AWS Entity Resolution スキーママッピングの作成、ユニークID選択 次に、下にスクロールして解決 (マッチング、リンク) に必要な入力フィールドを選択します (図 6 参照) 。この場合、firstname (名) 、middlename (ミドルネーム) 、surname (姓) 、statename (州名) 、countryname (国名) 、homeaddress (自宅住所) など、患者の人口統計情報を示す列が選択されています。 図 6 – AWS Entity Resolution スキーママッピング、マッチング列の選択 さらに、解決には必要ないものの、最終的な出力ファイルに必要な列は、パススルーフィールドセクションで選択できます。この例では、birthdate (生年月日) 、cityname (市区町村名) 、contactemailaddress (連絡先メールアドレス) 、contactfamilyname (連絡先姓) 、contactname (連絡先名) 、gender (性別) 、linkid (リンク ID) 、maritalstatus (婚姻状態) 、phonenumber (電話番号) 、postalcode (郵便番号) 、resourceid (リソース ID) を選択しました。これらの列はマッチングプロセスには参加しませんが、出力の一部として表示されます。 図 7 – AWS Entity Resolution スキーママッピング、パススルー列の選択 スキーママッピング作成の次のステップでは、選択した入力フィールドを適切なデータタイプとマッチキーにマッピングします。入力タイプ (名前、メール、住所など) を指定することで、AWS Entity Resolution は各列のデータをどのように解釈するか、そして必要に応じて特定の列にどの正規化ルールを適用できるかを理解します。 マッチキー は、どのフィールドが類似しており、マッチングプロセス中に単一のユニットとして考慮する必要があるかを決定します。 注 ：個人識別情報 (PII) ではないフィールドを解決に使用する必要がある場合、それらのフィールドを「入力フィールド」として選択することができます。入力タイプとして「Custom String」を選択し、適切なマッチキー名を設定してください。Custom String のサポートは、ルールベースのマッチング技術でのみ利用可能で、機械学習ベースのマッチングでは無視されます。 図 8 – AWS Entity Resolution スキーママッピング、入力フィールドを入力タイプへマッピング 「次へ」をクリックしてグループを作成します。グループとは、First Name (名) 、Middle Name (ミドルネーム) 、Last Name (姓) のような関連する入力フィールドを単一の「Name (氏名) 」列にまとめたセットです。これにより、AWS Entity Resolution は、マッチングと類似性の計算の際に、個々のフィールドを個別に比較するのではなく、まとめて比較することができ、より正確なマッチングが可能になります。 図 9 – AWS Entity Resolution スキーママッピング、名前のグループ定義 名前フィールドのグループ化と同様に、「住所」フィールドのグループも作成し、入力フィールドとして statename (州名) 、countryname (国名) 、homeaddress (自宅住所) を選択します (図 10 参照) 。 図 10 – AWS Entity Resolution スキーママッピング、住所のグループ定義 グループ設定が完了したら、「次へ」をクリックして、確認と作成画面に進みます。すべての設定を確認し、「スキーママッピングの作成」をクリックします。これによりスキーママッピングが作成されます。 スキーママッピングが作成されたら、次のステップはマッチングワークフローの作成です。マッチングワークフローは、ソース間でレコードをマッチングおよびリンクするために必要な、関連するマッチング技術、ルール、または機械学習の入力を定義するのに役立ちます。マッチングワークフローを作成するには、左側のメニューのワークフローのドロップダウンから「マッチング」を選択し、「マッチングワークフローの作成」ボタンをクリックします (図 11 参照) 。 図 11 – AWS Entity Resolution マッチングワークフローの作成 マッチングワークフロー画面で、名前と説明を入力してワークフローの作成を開始します。この例では、「patient-data-matching-workflow」という名前を付けました。 図 12 – AWS Entity Resolution マッチングワークフロー作成：名前と説明の定義 次に、適切な AWS Glue データベース、AWS Glue テーブル、および先ほど作成した対応するスキーママッピングを選択します。このステップにより、AWS Entity Resolution サービスにソースデータの場所を知らせ、スキーママッピング定義を使用してデータを解析し理解する方法を指示します。 図 13 – AWS Entity Resolution マッチングワークフロー作成：入力ソースの定義 AWS Entity Resolution に必要なアクセス権限を提供します。このサービスを初めて実行する場合は、「新しいサービスロールの作成と使用」を選択します。このオプションにより、サービスは自動的に IAM ロールを作成し、入出力用に指定された Amazon S3 バケットと、生データの入力ソースである AWS Glue データベース / テーブルへのアクセス権限を付与します。サービスロール名は自動生成されますが、必要に応じて編集することができます。IAM ロールの作成に関する詳細は、 ユーザーガイド で確認できます。 図 14 – AWS Entity Resolution マッチングワークフロー作成：IAMロールの選択 最適な IAM ロールオプションを選択した後、「次へ」をクリックして次のページに進みます。このページでは、ソースデータの解決を実行するために、ルールベースと機械学習ベースのマッチングの間から適切なマッチング技術を選択します。この場合、同一患者に属するレコードを確定的に識別するために、ルールベースのマッチング技術を選択します。 図 15 – AWS Entity Resolution マッチングワークフロー作成：ルールベースマッチング技術の選択 マッチングルール では、 ルール名 を入力し、そのルールの マッチキー を選択します。最大 15 個のルールを作成でき、ルール全体で最大 15 個の異なるマッチキーを適用してマッチング基準を定義できます。 比較タイプ については、「 複数入力フィールド 」オプションを選択します。これにより、データが同じ入力フィールドにあるか異なる入力フィールドにあるかに関係なく、複数の入力フィールドに保存されているデータをマッチングすることができます。 「次へ」をクリックして次のページに進みます。このページでは、サービスが結果を書き込む出力用 Amazon S3 バケットの場所を設定します。出力データ形式として「正規化データ」を選択します。このオプションでは、ダウンストリームでの迅速な利用のために、特殊文字や余分なスペースを削除し、すべての値を小文字に整形することでレコードを正規化します。必要に応じて、「 AWS Entity Resolution 向け正規化ライブラリのカスタマイズガイダンス 」に従って、正規化ライブラリをカスタマイズすることができます。 図 16 – AWS Entity Resolution マッチングワークフロー作成：出力設定 ワークフローを作成する前の最終ステップとして、すべての設定内容を確認し、マッチング要件を正確に反映していることを確認してから、「作成して実行」をクリックします。これによりマッチングワークフローが作成され、最初のジョブが実行されます。 ジョブの完了を待つと (図 17 参照) 、ジョブメトリクスに入力レコード数と生成された一意のマッチング ID 数が表示されます。出力は設定された Amazon S3 バケットに書き込まれます。指定された出力用 Amazon S3 バケットへ移動し、出力ファイルをダウンロードして結果を分析することができます。 図 17 – AWS Entity Resolution マッチングワークフロー実行統計 出力データ (図 18 参照) では、各レコードに元の一意の ID (uniqueid カラム) と新しく割り当てられた matchid が含まれています。同じ患者に関連するマッチングレコードには、同じ matchid が付与されています。matchrule フィールドは、マッチしたレコードセットを生成した際に適用されたルールを説明しています。 図 18 – AWS Entity Resolution マッチング済みデータ出力 このマッチング済みデータは、医療機関や公衆衛生機関にとって貴重な資産となり得ます。予防接種情報システム (IIS) 、疾病監視プラットフォーム、人口動態記録システムなどの医療システムに、AWS Entity Resolution の出力から特定されたマッチを取り込むことができます。これらのシステムは、マッチング済みデータを活用して潜在的なマッチを特定し、ユーザーに提示することができます。これにより、医療スタッフは潜在的なマッチを確認、統合、解決することができ、患者データの正確性と完全性を向上させることができます。 マッチング済みデータを活用することで、組織はより良い介入を促進し、健康状態の改善につながる分析を強化することができます。例えば、異なるデータセット間でデータをリンクすることで、予防接種データ、病院の退院データ、疾病監視データを連携させ、重症 COVID-19 のリスク要因をより良く特定することができます。 まとめ AWS Entity Resolution は、断片化されたレコード、データに基づかない意思決定、研究の障壁、不正確なデータによるケア連携の不一致、コスト増加といった課題の解決に役立ちます。この例で示されたように、医療機関や研究者は、AWS Entity Resolution を使用して、複数の多様なデータソースから患者レコードを効果的にリンクおよびマッチングすることができます。これにより、個人の健康履歴と結果について包括的で長期的なビューを作成することが可能になり、結果としてより良い全体的なケアにつながる可能性があります。 貴社のビジネスの加速にどのように貢献できるか、 AWS の担当者 にお問い合わせください。 参考文献 AWS Entity Resolution Resources ヘルスデータのための AWS Entity Resolution AWS Entity Resolution: 複数のアプリケーションとデータストアからの関連レコードを照合してリンクする AWS Entity Resolution Workshops 著者について Venkata Kampana Venkata は、カリフォルニアを拠点とする Amazon Web Services (AWS) 健康・福祉サービスチームのシニアソリューションアーキテクトです。彼は AWS 上の優れたアーキテクチャのソリューションを通じて、公共部門の顧客がミッション目標を達成できるよう支援しています。 Jim Daniel Jim は、Amazon Web Services (AWS) の公衆衛生部門のリーダーです。それ以前は、米国保健福祉省 (HHS) で約 10 年間、公衆衛生イノベーション部長や公衆衛生コーディネーターなどの職務を歴任しました。政府での勤務以前は、マサチューセッツ州公衆衛生局の最高情報責任者 (CIO) を務めていました。 Punit Shah Punit は、Amazon Web Services のシニアソリューションアーキテクトで、顧客のクラウド上でのデータ分析戦略の構築支援に注力しています。現在の役割では、AWS Entity Resolution や Amazon Connect などの AWS サービスを使用して、強固なデータ基盤層の構築を顧客に助言しています。大規模なデータレイクの構築において 15 年以上の業界経験を持っています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

このブログは 2025 年 1 月 25 日に Matt Williams と Felix Guglielmi によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 AWS では、可能な限り環境に配慮した方法で事業を運営することに尽力しています。また、お客様がクラウドの利点を活用して、IT インフラストラクチャをより効果的に監視し最適化できるよう支援しています。「 Amazon Web Services への移行による炭素削減の機会 」で報告されているように、AWS のインフラストラクチャは、米国の一般的な企業データセンターの中央値と比較して 3.6 倍のエネルギー効率を誇ります。さらに、AWS に移行することで、同じタスクに対するワークロードの炭素排出量を 88% 削減することができます。 持続可能性は、AWS とお客様の間で共有される責任です。AWS は、クラウドの持続可能性を最適化する責任を負っています。これには、効率的な共有インフラストラクチャの提供、水資源の管理、再生可能エネルギーの調達が含まれます。一方、お客様は、クラウド内の持続可能性に責任を負います。これには、ワークロードとリソース利用の最適化、およびワークロードに必要な総リソースの最小化が含まれます。 お客様の持続可能性目標の達成を支援するため、AWS は様々なツールを提供しています。その中には、AWS 使用量から生成される炭素排出量を追跡・測定する AWS Customer Carbon Footprint Tool が含まれます。AWS は、 AWS Well-Architected Framework の持続可能性の柱 を作成し、ワークロードの持続可能性目標達成に使用できる設計原則、運用ガイダンス、ベストプラクティスを提供しています。また、AWS は、アーキテクチャにおける持続可能性の改善を可能にするサービスの提供を続けています。例えば、Amazon EC2 でのエネルギー使用のワットあたり最高のパフォーマンスを提供するように設計された AWS Graviton インスタンス などがあります。 Amazon EC2 スポットインスタンス を使用すると、大幅なコスト削減の恩恵を受けながら、AWS のデータセンター利用率の向上にも貢献できます。 このブログでは、お客様が AWS Config を使用して、AWS Well-Architected Framework の 持続可能性の柱 のベストプラクティスに照らした AWS リソースの大規模に評価、監査、評価する方法について説明します。 AWS Config AWS Config はマネージドルールとカスタムルールを作成する機能を提供し、両方ともクラウドリソースの構成をプロビジョニングの前後で評価することができます。さらに、Config コンフォーマンスパック を使用すると、お客様は Config ルールとその修復アクションのコレクションを単一のユニットにパッケージ化することができます。コンフォーマンスパックは AWS Organizations とも統合されています。これにより、お客様は組織全体にわたってコンフォーマンスパックをデプロイでき、AWS アカウントやワークロード全体でリソースのコンプライアンスを確保するためのスケーラブルで効率的な方法を提供します。 持続可能性のベストプラクティスの評価 AWS Well-Architected Framework の持続可能性の柱は、クラウドにおける持続可能性の ベストプラクティス に関するガイダンスを提供します。これらのベストプラクティスは、リソースの使用率を高め、必要なリソースの総数を減らすことにより、お客様のワークロードを最適化するのに役立ちます。 持続可能性の柱を利用することで、お客様は改善の目標を特定し、推奨されるベストプラクティスを実行して持続可能性の目標を達成できます。 この例では、持続可能性の柱のベストプラクティスをいくつか選択し、AWS Config ルールを使用してお客様がこれらのベストプラクティスを組織全体に確実に実装できるようにする方法を示します。私たちは、データライフサイクル管理、コードの最適化、ネットワークパフォーマンスといった多くのアーキテクチャに共通するベストプラクティスを意図的に選択しました。このアプローチは、リソースの消費量を削減し、節約効果を得る機会を提供するのに役立ちます。ベストプラクティスの例は次の通りです。 SUS04-BP03 : ポリシーを使用してデータセットのライフサイクルを管理する SUS03-BP03 : 時間やリソースを最も多く消費するコード領域を最適化する SUS04-BP07 : ネットワーク間でのデータ移動を最小限に抑える 持続可能性のための AWS Config ルール SUS04-BP03: ポリシーを使用してデータセットのライフサイクルを管理する このベストプラクティスでは、ストレージ全体の使用量を最小限に抑えるために、未使用のデータを自動削除することをお勧めします。ビジネス要件を満たすためにデータ保持のニーズは組織全体で異なる場合があり、データを削除するために手動のアプローチを採用することはすぐに非現実的になる可能性があります。 Amazon S3 などの AWS のサービスを使用すると、ライフサイクル設定によって S3 オブジェクトを低コストのストレージへ移行、そして最終的にはオブジェクトの削除を自動化することができます。 AWS Config 内でルールを使用すると、ライフサイクル設定が Amazon S3 バケット全体に確実に適用されます。 # Rule-intent: Rule checks that lifecycle policies are configured for Amazon S3 bucket # # Expectations: # a) COMPLIANT when S3 bucket lifecycle is configured # b) NONCOMPLIANT when S3 bucket lifecycle is not configured # c) NOTAPPLICABLE when there is no S3 bucket rule checkBucketVersioningEnabled { supplementaryConfiguration.BucketLifecycleConfiguration exists <<Amazon S3 bucket lifecycle is not configured.>> } Plain text SUS03-BP03: 時間やリソースを最も多く消費するコード領域を最適化する 効率的なコードを使用すると、リソースの使用量が最小限に抑えられ、パフォーマンスが向上します。環境を監視して、改善の機会を特定し、バグやアンチパターンを除去する必要があります。 Amazon RDS の場合、 Performance Insights を使用してデータベースの負荷の原因を特定できるため、SQL クエリの影響を判断し、パフォーマンスを向上させるためにクエリを調整できます。Performance Insights は、 無料利用枠と有料利用枠の両方のオプション が提供されています。 以下の AWS Config ルールは、Performance Insights が RDS データベースに対して有効であることをチェックするため、データベースを監視して継続的な改善を図ることができます。 # Rule-intent: Rule checks that performance insights are enabled # # Expectations: # a) COMPLIANT when performance insights is enabled for RDS DBCluster or RDS DBInstance # b) NONCOMPLIANT when performance insights is not enabled for RDS DBCluster or RDS DBInstance ##Check whether performance Insights is enabled. rule rds_cluster_iam_authentication_enabled { configuration.performanceInsightsEnabled == true << Database cluster does not have performance insight enabled >> } Plain text SUS04-BP07: ネットワーク間でのデータ移動を最小限に抑える ネットワーク全体のデータ移動を最適化することで、ワークロードに必要なネットワークリソースの総量を削減し、環境への影響を軽減できます。このベストプラクティスを実装する際の考慮事項の 1 つは、API のデータ圧縮機能を有効にすることです。これにより、各リクエストで送信されるデータが削減され、ネットワーク全体でのデータの移動が削減されます。（データ圧縮によりデータの移動は最小限に抑えられますが、その代償としてデータを解凍するためにより多くのコンピューティング能力が必要になる可能性があることに注意してください。企業ではベストプラクティスの推奨事項をテストして、コンピューティングのトレードオフと比較したネットワーク使用量のレベルを判断し、どのアプローチが最も持続的に有益であるかを特定することをお勧めします。） このサンプルルールは、 Amazon API Gateway Rest API に対して圧縮機能が有効になっているかどうかをチェックします。 # Rule-intent: Rule checks compression is enabled for a Rest API # # Expectations: # a) COMPLIANT when compression is enabled # b) NONCOMPLIANT when compression is not enabled rule rest_api_compression_exists { configuration.minimumCompressionSize exists } Plain text 持続可能性ルールを大規模に導入する お客様は適合パックを使用して、上記の例のような AWS Config ルールを組織全体にデプロイし、持続可能性の目標に向けて取り組むことができます。Config ルールの使用を高速化するために、 適合パックの例 を作成しました。このパックには、持続可能性の柱の多くのベストプラクティスをサポートする次の 9 つの Config ルールが含まれており、 AWS Config コンソール または AWS コマンドラインインターフェイス を通じてデプロイできます。 サービス Config ルールの説明 持続可能性の柱のベストプラクティス API Gateway REST API の圧縮が有効になっているかをチェックします SUS04-BP07 CloudFront 圧縮が有効になっているかをチェックします (このルールは us-east-1 にデプロイする必要があることに注意してください) SUS04-BP07 EBS インスタンス終了時の EBS 削除が有効になっているかをチェックします SUS02-BP03 EC2 EC2 セキュリティグループに SSH 用のポート 22 が開いていないことをチェックし、代わりにセッションマネージャーを使用します SUS05-BP03 EFS EFS ライフサイクル管理が有効になっているかをチェックします SUS04-BP03 Lambda Lambda 関数が AWS Graviton ベースのプロセッサを使用しているかをチェックします SUS05-BP01 RDS RDS インスタンスが AWS Graviton ベースのプロセッサを使用しているかをチェックします SUS05-BP02 RDS Performance Insights が有効になっているかをチェックします SUS03-BP03 S3 Amazon S3 バケットのライフサイクル設定が存在するかをチェックします SUS04-BP03 * 上記の Config ルールは、実装手順とともに ここ にある適合パックに含まれています。 お客様は、この一連のサンプルルールを拡張して改善目標に合わせた追加の 持続可能性のベストプラクティス と照らし合わせてワークロードを評価することができます。お客様はこれらのルールを適応させて、環境内のリソースに対して Config カスタムルールを作成 できます。その後、適合パックを使用して組織全体に新しいルールを適用することができます。 まとめ このブログでは、 AWS Well-Architected Pillar for Sustainability に沿った AWS Config ルールを実装する方法を示し、そこには開始するための サンプル適合パック も含まれています。企業固有の持続可能性ポリシーに従ってこれらのルールを拡張または調整して持続可能性の目標を達成するために、さらにルールを追加できます。適合パックを介してこれらのルールを実装すると、リソースを効率的かつ大規模に評価できます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 TAGS: aws config custom conformance packs , AWS Config Rules , AWS Well Architected Framework

概要 AWS PrivateLink は、複数の VPC やアカウント間でサービスを安全かつ簡単に共有・アクセスする方法を提供します。すべてのトラフィックはパブリックインターネットを経由せずに AWS ネットワーク上に留まります。これまで、プロバイダーとコンシューマーは同じ AWS リージョン内に存在する必要がありましたが、 AWS PrivateLink のネイティブなクロスリージョン接続のサポート開始 により、異なるリージョン間で VPC エンドポイントサービスを共有・アクセスできるようになりました。これにより、サービスプロバイダーは単一のリージョンから世界中の顧客に SaaS ソリューションをプライベートに提供できるようになります。コンシューマーは、同一リージョン内のサービスと同じように、インターフェースエンドポイントを使用してクロスリージョン対応のサービスに簡単に接続できます。PrivateLink を介したクロスリージョン接続は、シンプルで安全であり、さまざまなユースケースに合わせてカスタマイズ可能です。 本ブログでは、AWS PrivateLink を介したクロスリージョン接続の仕組みと、グローバルデータの境界線を保護するための制御方法を紹介します。その後、エンドツーエンドの接続を確立する方法を示し、アーキテクチャの選択に役立つ考慮事項とベストプラクティスについて詳しく説明します。以降、本ブログでは簡潔さのため、VPC エンドポイントサービスを「サービス」、インターフェイス VPC エンドポイントを「エンドポイント」、AWS リージョンを「リージョン」と呼びます。 クロスリージョンアーキテクチャ 今日、多くのプロバイダーは特定のリージョンでサービスを提供していますが、世界中にコンシューマーを抱えています。 この新機能のリリース 前は、コンシューマーが別リージョンのサービスにアクセスしたい場合、リージョン間の VPC ピアリングや Transit Gateway (TGW) ピアリングを設定する必要がありました。彼らは自分のネットワークに CIDR 重複がないことを確認し、ネットワークの信頼境界を保護するためのガードレールを確立する必要がありました。あるいは、プロバイダーが拠点を他のリージョンに拡大したい場合、各リージョンに追加のインフラストラクチャをプロビジョニングする必要がありました。これにより、サービスプロバイダーとコンシューマーの両方にコストと複雑さが増していました。 図1. 新機能以前のネイティブなクロスリージョンサポートがないトポロジー図 図1 は、これまでコンシューマーがリージョン外でホストされているサービスにどのようにアクセスしていたかを示しています。ネットワークの信頼境界は、プロバイダーとコンシューマー間の分離を示しています。これは VPC やアカウント、または組織の境界である場合があります。サービスにアクセスするために、コンシューマーはプロバイダーのリージョンのトランジット VPC へのリージョン間の VPC ピアリングまたは TGW ピアリング接続を確立する必要がありました。そして、トランジット VPC 内の Availability Zones (AZ) をプロバイダーと一致させる必要がありました。 この新機能リリースにより、PrivateLink はこれらの複雑さをすべて抽象化し、コンシューマーとプロバイダーに対してシンプルでネイティブなリージョン間接続体験を提供します。プロバイダーは、クロスリージョン接続を有効にするだけで、任意のリージョンのコンシューマーがそのサービスにアクセスできるようになります。コンシューマーは、リージョン内のサービスに接続するのと同じように、エンドポイントを使用してこれらのリモートサービスに接続できるようになります。 図2 は、クロスリージョン PrivateLink のアーキテクチャ例を示しています。図1 で示した、リージョン内のエンドポイントパスによる連鎖的なピアリングとは対照的に、クロスリージョン接続ではサービスプロバイダーとコンシューマー間の AZ の整合性は必要ありません。プロバイダーは、サービスリージョンで AWS Network Load Balancer (NLB) を固定するために最低 2 つの AZ を使用する必要があります。コンシューマーは必要に応じて、複数 AZ にインターフェースエンドポイントを作成することができますが、高可用性のために 2 つ以上の AZ を使用することを推奨してます。これにより、いずれかのリージョンで AZ 障害イベントが発生した場合、PrivateLink はプロバイダーとコンシューマーに対して透過的に、正常な AZ へトラフィックを動的に振り分けることができます。 図2. クロスリージョン PrivateLink を使用して簡略化されたアーキテクチャ例 クロスリージョンのアクセス制御 PrivateLink のクロスリージョン接続は、セキュリティを最優先に設計されており、多層防御を提供します。コンシューマー側とプロバイダー側の両方が、クロスリージョンでサービスを共有およびアクセスするための適切な権限が設定されていることを確認する必要があります。 クロスリージョン PrivateLink 接続をオプトイン: これまでのすべての PrivateLink アクションは ec2 名前空間に含まれていましたが、クロスリージョンのアクションは新しい vpce:AllowMultiRegion (アクセス許可のみ) アクションで制御されます。この許可をオプトインしないと、リージョン内の PrivateLink 接続は中断されずに維持されますが、リージョン間でのサービスの共有やアクセスは失敗します。 サービスとエンドポイントのクロスリージョンアクセスを制御: サービスプロバイダーまたはコンシューマーとして、ec2:VpceMultiRegion boolean 型キーは、サービスがリージョン間接続を有効にしているか、または VPC エンドポイントが別のリージョンの PrivateLink サービスに接続されているかを示します。例えば、このステートメントはローカルリージョンでのサービスの共有とアクセスを許可します。また、サービスへのリージョン間アクセスを有効にすることも可能ですが、リモートサービスへのエンドポイントの作成は拒否します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowserviceshareandcreateendpoint", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:ModifyVpcEndpointServiceConfiguration", "vpce:AllowMultiRegion", "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint" ], "Effect": "Allow", "Resource": "*" }, { "Sid": "denycrossregionendpoint", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint" ], "Effect": "Deny", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringEquals": { "ec2:VpceMultiRegion": "true" } } } ] } JSON プロバイダー側でサービスにアクセスできるリージョンを定義: サービスプロバイダーとして、 ec2:VpceSupportedRegion キーは、リモートアクセスを有効にできるリージョンを制限するのに役立ちます。例えば、このステートメントは、バージニア北部とアイルランドリージョン以外でのサービス共有を防ぎます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "limitserviceshare", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:ModifyVpcEndpointServiceConfiguration", "vpce:AllowMultiRegion" ], "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:vpc-endpoint-service/*", "Condition": { "ForAllValues:StringLike": { "ec2:VpceSupportedRegion": [ "us-east-1", "eu-west-1" ] } } } ] } JSON コンシューマー側でサービスにアクセスできるリージョンを定義: コンシューマーとして、 ec2:VpceServiceRegion キーは、エンドポイントを介してアクセスできるリモートサービスリージョンを定義するのに役立ちます。例えば、このステートメントは東京やアイルランドでホストされているサービスへのアクセスをブロックします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowcrossregionendpoints", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint", "vpce:AllowMultiRegion" ], "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Effect": "Allow" }, { "Sid": "denyselectedregions", "Action": [ "ec2:CreateVpcEndpoint" ], "Effect": "Deny", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringLike": { "ec2:VpceServiceRegion": [ "ap-northeast-1", "eu-west-1" ] } } } ] } JSON オプトインリージョン: ほとんどのリージョンはデフォルトで AWS アカウントにおいてアクティブですが、2019年3月20日以降にローンチされたリージョンは、手動で選択した場合にのみアクティブ化されます。これらは オプトインリージョン と呼ばれます。オプトインリージョンからサービスへのアクセスを有効にする際、サービスプロバイダーはこれらのリージョンをオプトインする必要があります。同様に、コンシューマーがオプトインリージョンでホストされているサービスにアクセスしたい場合、まずそのリージョンをオプトインする必要があります。このガードレールは、アカウントで許可されていないリージョンへの、またはリージョンからの不測のアクセスを防ぐのに役立ちます。 これらの制御を組み合わせることで、あなたや組織は強固なセキュリティ境界を確立することができます。既存のリージョン内の PrivateLink 操作に影響を与えることなく、クロスリージョン間接続を選択したり、選択解除したりすることができます。これにより、管理された方法で機能を展開でき、データローカライゼーションに関する法的およびビジネス上のニーズに対応できます。 ステップバイステップのセットアップ このセクションでは、バージニア北部リージョンでサービスを作成し、オレゴンリージョンからアクセスする手順を説明します。これらの手順は、ポリシーにて vpce:AllowMultiRegion と必要な AWS PrivateLink アクション が許可されていることを前提としています。 サービスプロバイダーのセットアップ ステップ1: PrivateLink サービスの作成 新規または既存の NLB ベースのサービスに対して、クロスリージョンアクセスを有効にすることができます。この設定では、NLB と NLB ターゲットがすでに稼働していることを前提としています。バージニア北部リージョンの AWS VPC コンソールで、エンドポイントサービスを選択し、「エンドポイントサービスの作成」をクリックします。NLB のロードバランサータイプとして「ネットワーク」を選択します。利用可能なロードバランサーの中から、適切な NLB を選択します。ここでの「my-xrpl-svc」は、バージニア北部リージョンの4つのアベイラビリティーゾーンにわたって作成されています。 ステップ2: サポートリージョンの設定 サポートリージョンのドロップダウンを使用して、コンシューマーがサービスにアクセスできるリージョンを選択してください。オレゴン、シンガポール、アイルランドのリージョンからこのサービスへのアクセスを有効にします。この例では、簡略化のため、追加設定で「承認が必要」の選択を解除し、「IPv4」を選択しています。NLB と VPC の構成によって選択項目が異なる場合があります。 ステップ3: サービスの共有 サービスが作成されると、各サポートリージョンの状態が「保留中」から「利用可能」に変わるまで数分かかる場合があります。ここで生成されたサービス名をコンシューマーと共有して、サービスの発見を支援してください。PrivateLink サービスのセットアップおよび共有の残りの手順は、 このブログ で説明されているものと同じです。Application Load Balancer (ALB) を使用してサービスを構築している場合は、 こちら に手順が用意されています。 サービスコンシューマーのセットアップ ステップ1: PrivateLink サービスの発見 コンシューマーとして、サポートされているどのリージョンからでも、共有されたサービスにアクセスできます。AWS. VPC コンソールで、オレゴンリージョンに切り替えます。次に、PrivateLink and Lattice の下で、エンドポイントをクリックし、「エンドポイントの作成」を選択します。「NLB と GWLB を使用するエンドポイントサービス」を選択します。なお、クロスリージョン接続は現在、NLB ベースのサービスのみをサポートしており、AWS や Marketplace のサービスはサポートしていません。 サービスリージョンの下のボックスにチェックを入れて「クロスリージョンエンドポイントを有効にする」を選択し、サービスがホストされているバージニア北部リージョンを指定します。上記のサービスプロバイダーのセットアップ内のステップ3で生成されたサービス名を入力し、「サービスの検証」をクリックします。指定されたリージョンに提供された名前のサービスが存在し、アクセスが許可されている場合、「サービス名が検証されました」というメッセージが表示されます。ここでは、バージニア北部リージョンのサービスに接続するために、オレゴンリージョンに「my-xrpl-consumer」とタグ付けされた VPC エンドポイントが作成されます。 ステップ2: インターフェイスエンドポイントの作成 VPC エンドポイントを作成する VPC とサブネットを選択する必要があります。リージョン内の PrivateLink では、コンシューマーがサービスプロバイダーがサポートする AZ にのみエンドポイントを作成できますが、クロスリージョン接続では、AZ の整合性は必要ありません。必要な信頼性に応じて任意の数の AZ を選択でき、ニーズに最も適したサブネットを選択できます。 エンドポイントが作成され、「利用可能」状態になると、クロスリージョン接続が正常に確立されます。以下のように設定の詳細を確認することができます。 複数のエンドポイント DNS 名が生成されていることに注目してください。最初の DNS エントリはリージョナル DNS 名で、その後に各エンドポイントの AZ の DNS 名のエントリが続きます。この例では2つの AZ を使用しているため、合計3つの DNS 名があります。アプリケーションにはより高い可用性と回復性のため、リージョナル DNS 名の使用が推奨されます。また、エンドポイントでプライベート DNS 名を有効にすることで、プロバイダーのサービスにアクセスするためのカスタム名を使用することもできます。プライベート DNS　やサブネット、AZ に関する詳細については、 AWS PrivateLink ユーザーガイド を参照してください。 考慮事項 プロバイダー サービスへのアクセスを有効にできるリージョン数に制限はありません。ただし、同じ パーティション 内のリージョンからのアクセスのみを有効にすることができます。 クロスリージョンアクセスを有効にできるのは、NLB ベースのサービスのみです。現時点では、AWS サービスや Marketplace サービスはサポートされていません。 サポートリージョンのリストからリモートリージョンを削除することで、そのリージョンからのサービスへのアクセスを取り消すことができます。これにより、削除されたリージョンから新しいエンドポイントがサービスにアクセスすることを防げますが、既存のエンドポイントは維持されます。必要に応じて、これらのエンドポイントを手動で拒否する必要があります。 コンシューマー クロスリージョン接続は、インターフェイスタイプの VPC エンドポイントでのみサポートされています。 ローカルリージョンまたはリモートリージョンのサービスへの VPC エンドポイントは、いずれも「VPC ごとのインターフェイス VPC エンドポイント」クォータにカウントされます。詳細の確認とクォータ引き上げの申請は こちら で行えます。 まとめ AWS のグローバル展開に伴い、AWS PrivateLink のクロスリージョンサポートにより、SaaS サービスを1つのリージョンから世界中のカスタマーへシームレスに接続することができます。プロバイダーとコンシューマーの両方が、同じリージョンにインフラを設置することなく、互いにプライベートにアクセスすることを選択できます。 VPC コンソールのエンドポイントサービスとエンドポイントのオプションを使用して、AWS PrivateLink の利用を始めましょう。詳細については、 AWS PrivateLink ユーザーガイド とホワイトペーパー「 AWS PrivateLink を介したサービスへの安全なアクセス 」を参照してください。 本稿は、2024年12月11日に Networking & Content Delivery で公開された “ Introducing Cross-Region Connectivity for AWS PrivateLink ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

Amazon OpenSearch Service は、オープンソースの全文検索エンジン OpenSearch および可視化・分析ツールの OpenSearch Dashboards を、安全かつスケーラブルな形で提供するマネージドサービスです。 この度、日本語で検索技術について学べる Amazon OpenSearch Service のハンズオンコンテンツ「 Amazon OpenSearch Service 検索ワークショップ 」を公開したことをお知らせいたします。 ワークショップの概要 検索ワークショップは、OpenSearch の基本から最新の検索機能まで、段階的に学習することが可能なコンテンツです。Jupyter Notebook 形式で提供される「ラボ」を実行していくことで、OpenSearch を使用した検索機能の使い方を無理なく身に付けることができます。 日本語にフォーカスしたワークショップであることも大きなポイントです。ラボのコンテンツは日本語の特性を考慮した内容になっており、使用するデータや ML モデルも全て日本語に対応しています。 ワークショップに必要な AWS リソースは AWS CloudFormation を利用して素早く展開することが可能です。 ラボの紹介 ワークショップ内に現在実装されているラボは以下の通りです。ラボは随時追加、アップデートを行っていきます。 事前にラボの詳しい内容を確認したい場合は、「 JupyterLab のセットアップ 」ページ内の 「ワークショップアセットのダウンロードと展開」セクションに記載された URL を参考に、ノートブックのアーカイブファイルをローカル環境にダウンロードしてください。ローカル環境上の JupyterLab や Visual Studio Code といった .ipynb ファイルに対応したツールより、実行コードも含めたワークショップの内容をご確認いただけます。 OpenSearch の基本概念・検索の基礎 OpenSearch をはじめとした検索エンジンに初めて触れる方をターゲットとしたラボです。リレーショナルデータベースと検索エンジンとの違いを知りたい方にも最適です。本ラボでは、検索エンジン固有の概念の解説に始まり、データの管理方法や基本的な検索クエリを網羅的に試すことができます。本ラボで獲得したスキルは、システムにおける検索エンジンの採用要否の判断、使用するクエリの選定に役立ちます。 日本語全文検索の実装 日本語テキストの全文検索の実装を検討されている方、精度改善を検討されている方をターゲットとしたラボです。本ラボでは、表記ゆれといった日本語検索固有の課題を解消するための OpenSearch の機能や、日本語の形態素解析器である Kuromoji および Sudachi の利用方法を解説しています。本ラボで獲得したスキルは、日本語検索のチューニングに役立てることができます。 サジェスト機能の実装 サジェストは、ユーザーが検索窓に入力した文字列を元に適切なクエリの候補を返却する機能です。オートコンプリートなどとも呼ばれており、ユーザー体験向上や、ゼロ件ヒット削減に役立ちます。本ラボでは、日本の住所サンプルデータを使用し、プレフィクスベースのサジェスト機能を実装していきます。またサジェストを実装する上で、日本語固有の考慮事項についてもフォローしています。本ラボで獲得したスキルは、サジェストの実装に役立てることができます。 AI-powered search 本ラボは、従来型の全文検索では対応が難しい曖昧な文章による意味的検索や、文書の類似検索といった高度な検索要件を実現する手がかりを探している方をターゲットとしています。また、ベクトル検索などの最新の検索技術に興味がある方にも適しています。ベクトル検索をはじめとした機械学習モデルと連携した検索機能の実装方法を、手を動かしながら学習することができます。このラボは、以下のサブモジュールから構成されています。 ベクトル検索 ベクトル検索は、ある意味的に類似性のあるアイテムを検索する際に有用です。「暖かい服」で検索して 「セーター」の結果を得たいようなケースで役に立ちます。また、テキストだけではなく、画像や音声といった非構造データも扱うことが可能です。本モジュールでは、従来の全文検索では解決できない課題を、ベクトル検索を使って解決することを通してベクトル検索の有用性を確認していきます。また、OpenSearch のコネクタと呼ばれる機能についても学習します。コネクタを使用することで、テキストベースのクエリを機械学習モデルと連携してベクトルベースのクエリに変換し検索を行う、ニューラル検索を実装することができます。類似検索の実装方法を知りたい方にとって有用です。 スパース検索 スパース検索は、スパースエンコーディングモデル (単語の出現頻度に基づく疎なベクトル表現を生成するモデル) を活用した検索です。従来のベクトル検索と比較して、少ないリソースで類似検索を実装することができます。本ラボでは日本語に対応した SPLADE モデル (Sparse Lexical and Expansion Model) を用いて、ベクトル検索とは異なるアプローチで類似検索を実装していきます。ベクトル検索に加えて、異なる選択肢も検討したい方にお勧めです。 ハイブリッド検索 ハイブリッド検索は、複数の検索クエリの結果を組み合わせて、より精度の高い検索結果を提供するための機能です。テキスト検索・ベクトル検索のどちらが精度が出るかは対象のデータだけでなく、検索クエリにも依存します。ハイブリッド検索でベクトル検索と全文検索の組み合わせ検索を行うことで、様々な検索クエリに対して適切な結果を返すことが可能となります。本ラボでは、OpenSearch のハイブリッド検索機能を実際に試すことができます。ハイブリッド検索の実装を検討されている方にお勧めです。 リランキング リランキングは、一段階目の検索結果に対して、特定のロジックに基づき並べ替えを行うアプローチです。本ラボでは、ドキュメントとクエリ間の類似度を計算するクロスエンコーダーモデルを使用した、意味的類似度に基づくリランキングの実装方法を学ぶことができます。モデルによるリランキングの効果を確かめたい方にお勧めです。 ワークショップの開始方法 本ワークショップは AWS がホストするイベントでの提供の他、ご自身の AWS アカウントを利用して実行することもできます。AWS CloudFormation 用のテンプレートを使用することで、ワークショップに必要な以下のリソース群を素早く作成し、ラボを開始することができます。 詳しい始め方については、ワークショップ内の 準備作業 をご確認ください。 ご自身の AWS アカウントでワークショップを実行する場合、デプロイされたリソースに応じて料金が発生します。不要な料金発生を抑制するために、必ずワークショップ終了後は クリーンアップ 手順に沿ってワークショップリソースの削除を行ってください。 まとめ OpenSearch は柔軟性の高い強力な検索エンジンです。基本的なテキスト検索から最新のベクトル検索、ハイブリッド検索まで幅広い検索機能を提供しています。ワークショップを通して、OpenSearch の可能性を探ってみてください。 Amazon OpenSearch Service について更に詳しく知りたい方は、 Amazon OpenSearch Service 開発者ガイド および AWS Black Belt 資料をご覧ください。 ソリューションアーキテクト 榎本 貴之 (X: @tkykenmt )

毎年 3 月 14 日 (3.14) に開催される AWS Pi Day では、データの管理と利用に役立つ AWS のイノベーションを重点的に取り上げます 。2021 年に Amazon Simple Storage Service (Amazon S3) のリリース 15 周年を記念して始まったこのイベントは、現在ではクラウドテクノロジーがデータ管理、分析、AI をどのように変革しているのかに重点を置くイベントに成長しました。 2025 年の AWS Pi Day は、AWS 上の統合データ基盤を使用した分析と AI のイノベーションの加速に焦点を当てて開催されます。ほとんどのエンタープライズ戦略で AI が登場し、分析と AI のワークロードがますます相互に関連し、多くの同じデータとワークフローを使用するようになる中で、データ環境は大きな変革を遂げています。すべてのデータにアクセスし、単一の統合エクスペリエンスですべてのお好みの分析および AI ツールを使用するための簡単な方法が求められています。2025 年の AWS Pi Day では、統合データエクスペリエンスの構築に役立つ一連の新機能をご紹介します。 次世代の Amazon SageMaker: すべてのデータ、分析、AI の中心 re:Invent 2024 では、すべてのデータ、分析、AI の中心となる 次世代の Amazon SageMaker を発表しました 。 SageMaker には、データの探索、準備、統合、ビッグデータ処理、高速 SQL 分析、 機械学習 (ML) モデルの開発とトレーニング、 生成 AI アプリケーション開発に必要なほぼすべてのコンポーネントが含まれています。この新世代の Amazon SageMaker では、 SageMaker Lakehouse がデータへの統合アクセスを提供し、 SageMaker Catalog がガバナンスとセキュリティの要件を満たすのをサポートします。詳細については、同僚の Antje が書いた リリースに関するブログ記事 をお読みください。 次世代の Amazon SageMaker の中核となるのは、 SageMaker Unified Studio です。これは、分析と AI のためにすべてのデータとツールを使用できる単一のデータおよび AI 開発環境です。 SageMaker Unified Studio の一般提供が開始されました 。 SageMaker Unified Studio は、データ、分析、AI ワークフロー、およびアプリケーションに取り組むデータサイエンティスト、アナリスト、エンジニア、およびデベロッパー間のコラボレーションを容易にします。データ処理、SQL 分析、ML モデル開発、生成 AI アプリケーション開発など、AWS の分析および 人工知能と機械学習 (AI/ML) サービスの使い慣れたツールを単一のユーザーエクスペリエンスで使用できるようにします。 また、 SageMaker Unified Studio は、 Amazon Bedrock からの特定の機能を SageMaker で使用できるようにします。。 基盤モデル (FM) と、 Amazon Bedrock のナレッジベース 、 Amazon Bedrock ガードレール 、 Amazon Bedrock エージェント 、 Amazon Bedrock Flows などの高度な機能を使用して、迅速に生成 AI アプリケーションのプロトタイプを作成したり、生成 AI アプリケーションをカスタマイズおよび共有したりして、お客様の要件と、責任ある AI ガイドラインに整合する、カスタマイズされたソリューションを、すべて SageMaker 内で作成できるようになりました。 最後に、 Amazon Q Developer の 一般提供が SageMaker Unified Studio で開始されました 。Amazon Q Developer は、データと AI 開発のために、生成 AI を活用したサポートを提供します。SQL クエリの記述、抽出、変換、ロード (ETL) ジョブの構築、トラブルシューティングなどのタスクでお客様をサポートし、既存のサブスクライバーは 無料の階層と Pro の階層 で利用できます。 同僚の Donnie が最近書いたブログ記事で、 SageMaker Unified Studio の詳細をご覧いただけます。 re:Invent 2024 では、次世代の SageMaker の一部として Amazon SageMaker Lakehouse もリリースしました。SageMaker Lakehouse は、Amazon S3 データレイク、 Amazon Redshift データウェアハウス、サードパーティーおよびフェデレーテッドデータソース全体ですべてのデータを統合します。データの単一コピーを使用して強力な分析および AI/ML アプリケーションを構築するのに役立ちます。SageMaker Lakehouse は、 Apache Iceberg 互換のツールとエンジンを使用して、データにインプレースでアクセスしてクエリを実行する柔軟性を提供します。さらに、ゼロ ETL 統合により、 Amazon Aurora および Amazon DynamoDB などの AWS データソースや、 Salesforce 、 Facebook Ads 、 Instagram Ads 、 ServiceNow 、 SAP 、 Zendesk 、 Zoho CRM などのアプリケーションから SageMaker Lakehouse にデータを取り込むプロセスが自動化されます。 統合の詳細なリストは、「SageMaker Lakehouse に関するよくある質問」でご覧いただけます 。 Amazon S3 を利用したデータ基盤の構築 データ基盤の構築は、分析と AI ワークロードを加速するための基礎であり、組織があらゆる規模でデータアセットをシームレスに管理、検出、活用できるようにします。Amazon S3 は、事実上無制限の規模でデータレイクを構築するのに最適な場所であり、この変革に不可欠な基盤を提供します。 私は Amazon S3 の運用規模を知るたびに驚かされます。現在、Amazon S3 は 400 兆を超えるオブジェクト、エクサバイト規模のデータを保持しており、1 秒あたり 1 億 5,000 万件という驚異的な数のリクエストを処理しています。わずか 10 年前は、S3 に 1 ペタバイト (PB) を超えるデータを保存しているお客様の数は 100 にも届いていませんでした。今日では、何千ものお客様が 1 PB のマイルストーンを超えています。 Amazon S3 はエクサバイト規模の表形式データを保存し、1 秒あたり平均 1,500 万件を超える、表形式データに対するリクエストを処理しています。S3 バケットで表形式データを管理する際の、付加価値を生まない手間のかかる作業を軽減するのに役立つよう、 当社は AWS re:Invent 2024 で Amazon S3 Tables を発表しました 。S3 Tables は、Apache Iceberg のサポートが組み込まれた初のクラウドオブジェクトストアです。S3 テーブルは分析ワークロード向けに特別に最適化されており、セルフマネージドテーブルと比較して、クエリスループットが最大 3 倍高速になり、1 秒あたりのトランザクション数が最大 10 倍になります。 3 月 14 日、 弊社は、 Amazon S3 Tables と Amazon SageMaker Lakehouse の統合の 一般提供の開始 を発表しました。 Amazon S3 Tables が Amazon SageMaker Lakehouse と統合するようになったため、Amazon Redshift、 Amazon Athena 、 Amazon EMR 、 AWS Glue などの AWS の分析サービスや、Apache Spark や PyIceberg などの Apache Iceberg 互換エンジンから S3 Tables に簡単にアクセスできるようになりました。SageMaker Lakehouse を利用すると、S3 Tables や他のソースについてのきめ細かなデータアクセス許可を一元的に管理し、すべてのエンジンで一貫して適用できます。 サードパーティーのカタログを使用しているお客様、カスタムカタログ実装があるお客様、または単一のテーブルバケット内の表形式データに対する基本的な読み取りおよび書き込みアクセスのみを必要とするお客様のために、 当社は、 Iceberg REST Catalog 標準 と互換性のある 新しい API を追加しました 。これにより、Iceberg 互換のアプリケーションは、S3 テーブルバケット内のテーブルをシームレスに作成、更新、一覧表示、削除できます。すべての表形式データ、データガバナンス、およびきめ細かなアクセスコントロールにわたる統合データ管理のために、SageMaker Lakehouse で S3 Tables を使用することもできます。 S3 Tables にアクセスしやすくするために、 AWS マネジメントコンソール で更新の提供を開始しました 。Amazon Athena を利用して、テーブルを作成し、データを入力して、S3 コンソールから直接クエリを実行できるようになりました。これにより、使用を開始して、S3 テーブルバケット内のデータを分析するのがより簡単になりました。 次のスクリーンショットは、S3 コンソールから直接 Athena にアクセスする方法を示しています。 [Athena を利用してテーブルをクエリ] または [Athena を利用してテーブルを作成] を選択すると、適切なデータソース、カタログ、データベースで Athena コンソールが開きます。 re:Invent 2024 以降、当社は速いペースで S3 Tables に新しい機能を追加し続けています。例えば、 CreateTable API にスキーマ定義のサポートを追加 しました。これにより、 S3 テーブルバケットに最大 10,000 個のテーブルを作成できるようになりました 。また、S3 Tables は 8 つの追加の AWS リージョン でもリリースされました。最新のリリースは 3 月 4 日のアジアパシフィック (ソウル、シンガポール、シドニー) であり、今後も他のリージョンでリリースされる予定です。現在 S3 Tables が利用可能な 11 のリージョンのリストについては、ドキュメントの S3 Tables の AWS リージョン のページをご覧ください。 Amazon S3 Metadata ( re:Invent 2024 で発表 ) は、 1 月 27 日から一般提供が開始 されています。これは、ほぼリアルタイムで更新される、自動化された簡単にクエリできるメタデータを使用して、S3 データを検出して理解するのに役立つ極めて迅速かつ簡単な方法です。S3 Metadata は S3 オブジェクトタグと連携して機能します。タグは、IAM ポリシーを適用してきめ細かなアクセスを提供したり、タグベースのフィルターを指定してオブジェクトのライフサイクルルールを管理したり、データを別のリージョンに選択的にレプリケートしたりするなど、さまざまな理由でデータを論理的にグループ化するのに役立ちます。S3 Metadata が利用可能なリージョンでは、オブジェクトタグとして保存されているカスタムメタデータをキャプチャしてクエリできます。S3 Metadata を使用する際にオブジェクトタグに関連して発生するコストを削減するために、 Amazon S3 は、すべてのリージョンで S3 オブジェクトタグ付けの料金を 35% 引き下げました 。これにより、カスタムメタデータの使用コストが削減されます。 AWS Pi Day 2025 長年にわたって、AWS Pi Day では、クラウドストレージとデータ分析における主要なマイルストーンをご紹介してきました。2025 年の AWS Pi Day 仮想イベントでは、デベロッパーや技術的な領域における意思決定者、データエンジニア、AI/ML 実践者、IT リーダー向けに設計されたさまざまなトピックを取り上げます。主なハイライトには、この記事で説明したすべてのサービスと機能に関する詳細な説明、ライブデモ、エキスパートによるセッションが含まれます。 このイベントに参加することで、分析と AI のイノベーションを加速する方法を学ぶことができます。ネイティブの Apache Iceberg サポートおよび S3 Metadata とともに S3 Tables を使用して、従来の分析と新しい AI/ML ワークロードの両方に対応するスケーラブルなデータレイクを構築する方法を学びます。また、すべてのデータ、分析、AI の中心となる次世代の Amazon SageMaker についても学びます。これは、データレイク、データウェアハウス、サードパーティーまたはフェデレーテッドデータソースに保存されているすべてのデータにアクセスできる使い慣れた AWS ツールを使用して、チームが統合スタジオからコラボレーションし、より迅速に構築するのに役立ちます。 クラウドに関する最新のトレンドを先取りしたいお客様にとって、 AWS Pi Day 2025 は見逃せないイベントです 。データレイクハウスの構築、AI モデルのトレーニング、生成 AI アプリケーションの構築、分析ワークロードの最適化など、進めている取り組みがどのようなものであっても、共有されたインサイトはデータの価値を最大化するのに役立ちます。 今すぐ視聴 して、クラウドデータイノベーションに関する最新情報をご覧ください。データ、分析、AI の未来を形作る AWS のエキスパート、パートナー、お客様とつながる機会をお見逃しなく。 3 月 14 日のバーチャルイベントを見逃したお客様もご安心ください。いつでも イベントページ にアクセスして、すべてのコンテンツをオンデマンドでご視聴いただけます! – seb ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

本記事は 2025 年 3 月 6 日に公開された “ Announcing support for upgrades to Java 21 in Amazon Q Developer ” を翻訳したものです。 2 月 14 日、Amazon Q Developer は Java 21 へのアップグレード対応を発表 しました。Java 開発者として、この新機能にはとても興奮しています。これにより、アプリケーションを最新の状態に保ち、最新の言語機能やパフォーマンス向上を活用しやすくなります。さらに、最新バージョンの Amazon Q Developer は、アップグレードプロセスを簡素化し、結果に対する信頼性を高めるために、要約と推奨機能が改善されています。 Amazon Q Developer は、エンタープライズアプリケーションのモダナイゼーションを加速させるのに役立つ生成 AI を活用したアシスタントです。レガシーコードの分析、依存関係のマッピング、移行・モダナイゼーションワークフローの実行など、複雑なタスクを処理できます。Amazon Q Developer により、チームは Java アプリケーションのアップグレードといった手間のかかる作業に追われることなく、より戦略的な取り組みに集中できるようになります。 新しいリリースごとに、重要なセキュリティ修正、パフォーマンスの強化、新しいフレームワークやライブラリのサポートが行われるため、Java のバージョンを最新の状態に保つことは非常に重要です。しかし、大規模な Java コードベースを手動で移行するのは非常に負担の大きい作業です。そこで Amazon Q Developer が大きな役割を果たします。退屈で労力のかかるアップグレード作業をオフロードすることで、チームはより迅速に重要な更新を提供でき、システムへの影響も最小限に抑えることが可能になります。 Java 21 の利点 Java 21 へのアップグレード機能の追加により、Amazon Q Developer は Java 8、11、17 から Java 17 または 21 へのアプリケーションのアップグレードをサポートするようになりました。私が特に期待している Java 21 の主な利点には以下があります。 仮想スレッド: 仮想スレッド は Java 19 で導入された新しい並行処理の仕組みであり、高スループットな並行アプリケーションの開発、保守、デバッグの負担を軽減します。これにより、アプリケーションのパフォーマンスが大幅に向上します。 パフォーマンスの改善: Java 21 では、 Sequenced Collections 、 Record Patterns 、 Pattern Matching などのさまざまな言語機能が強化されており、処理速度と効率性の向上が期待できます。 メモリ管理の向上: Java 21 の Z Garbage Collector の強化により、ガベージコレクションの一時停止時間がより予測しやすくなり、メモリ使用量も削減されます。これにより、アプリケーションの安定性と応答性が向上します。 Amazon Q Developer を活用してチームの Java アプリケーションを Java 21 にアップグレードすることは、大きな変革となります。これにより、すべての Java コンポーネントを手作業で移行するために必要だった膨大な時間を節約できます。 Amazon Q Developer によるアップグレードプロセスの簡略化 Amazon Q Developer を使用すれば、Java アプリケーションを Java 21 に簡単にアップグレードできます。プロジェクトの設定を行い、必要な 前提条件 を満たしたら、統合開発環境 (IDE) の Amazon Q Developer チャットウィンドウで /transform コマンドを 実行 するだけです。以下のスクリーンショットは VS Code のものですが、Q Developer は IntelliJ IDEA を含む JetBrains の IDE や qct コマンドライン にも対応しています。 Amazon Q Developer はコードベースを分析し、Java 21 へのアップグレードに必要な変更を特定します。その後、詳細な差分を提供するため、変更内容をレビューし、適用することができます。これにより、時間を節約できるだけでなく、すべての Java アプリケーションに対して一貫性のある高品質なアップグレードを実現できます。 最新バージョンの Amazon Q Developer では、Java 21 へのアップグレード対応に加えて、変換完了後に提供される要約と推奨事項も強化されています。Java 21 へのアップグレードが完了すると、Amazon Q Developer は非推奨 API の削除や、新しい Java 機能を活用するためのコードのリファクタリングなど、変更内容の詳細なサマリーを生成します。さらに、Java 21 の機能を最大限に活用するためのカスタマイズされた推奨事項も提供されます。たとえば、Amazon Q Developer はロギングフレームワークのアップグレードや、パターンマッチングの導入によるコードの簡潔化を提案しました。これらの要約と推奨の機能により、スムーズで包括的なアップグレードプロセスを実現できます。 最後に、Q は Java 21 へのアップグレードにとどまらず、アプリケーションのさらなる改善に向けた推奨事項も提供します。たとえば、Q は以下のような推奨を行いました。 要約と推奨の機能により、スムーズで包括的なアップグレードを実現できます。開発者は詳細な変更内容をレビューし、その背景を理解した上で、提案された最適化を選択的に適用することができます。これにより、Java 21 の利点を最大限に活用できるようになります。Amazon Q Developer の透明性とガイダンスにより、アップグレードプロセスが大幅に簡素化され、最終的なコードベースに対する信頼性も向上します。 まとめ まとめると、Amazon Q Developer の新しい変換機能により、Java 21 へのアップグレード作業の負担が大幅に軽減されます。Amazon Q Developer が提供する詳細なサマリーとカスタマイズされた推奨事項により、スムーズかつ包括的なアップグレードが可能になり、プロセス全体が効率化されます。この機能を活用し、チームの時間をより価値の高い業務に充てられることを楽しみにしています。Java 開発者の方には、ぜひ Amazon Q Developer を試してみることをおすすめします。始めるには、 Amazon Q Developer の使用を開始するページ をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。

3 月 13 日、 Amazon SageMaker Unified Studio の一般提供について発表します。Amazon SageMaker Unified Studio は、組織内のすべてのデータを検索してアクセスし、ほとんどすべてのユースケースの業務で適切なツールを使用してデータを利用できる単一のデータおよび AI 開発環境です。AWS re:Invent 2024 で プレビューとして紹介 され、私の同僚の Antje は次のように記しています。 SageMaker Unified Studio (プレビュー) は単一のデータおよび AI 開発環境です。現在の Amazon Athena 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA )、既存の SageMaker Studio の幅広いスタンドアロンの「スタジオ」、クエリエディタ、ビジュアルツールの機能とツールがまとめられています。 Amazon SageMaker Unified Studio の機能を示す動画を以下に紹介します。 SageMaker Unified Studio は、データやツールのサイロを解消し、データエンジニア、データサイエンティスト、データアナリスト、ML 開発者、その他のデータプラクティショナーに単一の開発エクスペリエンスを提供します。開発時間が節約され、アクセス制御管理が簡素化されるため、データプラクティショナーは自分にとって本当に重要なタスクであるデータ製品と AI アプリケーションの構築に集中することができるようになります。 この投稿では、私たちが共有できることを嬉しく思っているいくつかの重要な発表にフォーカスします。 SageMaker Unified Studio 内の Amazon Bedrock の新機能 – 今回の統合により、Anthropic の Claude 3.7 Sonnet や DeepSeek-R1 などの新しい基盤モデル (FM) のサポート、ナレッジベースの作成を目的としたプロジェクト内の Amazon Simple Storage Service (Amazon S3) フォルダからのデータソーシング、そしてフローへのガードレール機能の拡張が実現し、複数の Amazon Web Services (AWS) アカウントにわたるモデルガバナンスを管理するドメイン管理者向けの合理化されたユーザー管理インターフェイスが提供されます。 SageMaker Unified Studio 内での Amazon Q Developer の一般提供開始 – ソフトウェア開発用の最も高機能な生成 AI アシスタントである Amazon Q Developer は、SQL クエリの記述、ETL ジョブの構築、トラブルシューティング、リアルタイムでのコード提案の生成などのタスクを簡素化する自然言語での会話型インターフェイスを提供することで Amazon SageMaker Unified Studio での開発を能率化します。 使用を開始するには、 Amazon SageMaker コンソール にアクセスして SageMaker Unified Studio ドメインを作成します。詳細については、AWS ドキュメントの「 Create a Amazon SageMaker Unified Studio domain 」を参照してください。 SageMaker Unified Studio 内の Amazon Bedrock の新機能 Amazon SageMaker Unified Studio 内の Amazon Bedrock の機能は、開発者が生成 AI アプリケーションを迅速に作成してカスタマイズするための統制されたコラボレーション環境を提供します。この直感的なインターフェイスは、あらゆるスキルレベルの開発者に対応しており、Amazon Bedrock で提供される高性能 FM や、カスタマイズされた生成 AI アプリケーションを共同開発するための高度なカスタマイズツールにシームレスにアクセスできます。 プレビュー版のリリース以降、Amazon Bedrock で利用できるようになった Anthropic の Claude 3.7 Sonnet や DeepSeek-R1 などの新しい FM は SageMaker Unified Studio と完全に統合されています。これらのモデルは、生成 AI アプリの構築と SageMaker Unified Studio のプレイグラウンドでのチャットに使用できます。 プロジェクトでのモデル選択で Anthropic の Claude 3.7 Sonnet を選択する方法を以下に示します。 ナレッジベースを作成する際に、プロジェクト内の S3 フォルダからデータまたはドキュメントを指定し、特定の FM を選択することもできます。 ユースケースと責任ある AI ポリシーに基づいて Amazon Bedrock アプリケーションのセーフガードを実装 できるよう、プレビュー中に Amazon Bedrock ガードレールが導入されました。現在、この一般提供のリリースにより、Amazon Bedrock ガードレールが Amazon Bedrock Flows に拡張されました。 さらに、関連付けられたアカウントの生成 AI セットアップが SageMaker Unified Studio の新しいユーザー管理インターフェイスによって合理化さるので、ドメイン管理者は、関連付けられたアカウント管理者にモデルガバナンスプロジェクトへのアクセス許可を簡単に付与できるようになりました。この機能強化により、コマンドラインの操作が不要になり、複数の AWS アカウントにわたる生成 AI 機能の設定プロセスが能率化されます。 これらの新機能により、生成 AI 開発プロセスにおけるデータ、ツール、ビルダーの間の障壁が排除されます。Amazon Bedrock の強力なすべての生成 AI 機能を同じワークスペースに組み込むことで、チームは統合された開発エクスペリエンスを利用できます。 SageMaker Unified Studio 内での Amazon Q Developer の一般提供開始 Amazon SageMaker Unified Studio 内での Amazon Q Developer の一般提供が開始され、データプロフェッショナルは、データと AI 開発ライフサイクル全体にわたって生成 AI を活用したアシスタンスを利用できるようになりました。 Amazon Q Developer は、データ処理、SQL 分析、機械学習モデル開発、生成 AI アプリケーション開発を始めとする SageMaker Unified Studio 内の AWS 分析と AI/ML ツールとサービスの完全なスイートと統合し、コラボレーションを促進して、チームがデータおよび AI 製品をより迅速に構築することを可能にします。使用を開始するには、Amazon Q Developer のアイコンを選択します。 SageMaker Unified Studio の新規ユーザーにとって、Amazon Q Developer は非常に貴重なオンボーディングアシスタントとしての役割を果たします。ドメインやプロジェクトなどのコアコンセプトの説明や環境の設定に関するガイダンスに加えて、ユーザーの質問に対する回答が提供されます。 Amazon Q Developer では、自然言語による SageMaker Catalog との強力な対話を介したデータの検出と理解が可能になります。この実装は、Amazon Q Developer が AWS 分析と AI/ML サービスに関する幅広い知識をユーザーのコンテキストと組み合わせてパーソナライズされたガイダンスを提供することによって強力な機能を提供します。 会話型インターフェイスからデータ資産に関するチャットを行って「支払いに関連するすべてのデータセットを表示してください」などの質問をすることができます。複雑なメタデータ構造をナビゲートする必要はありません。 Amazon Q Developer では、SageMaker Unified Studio で使用可能な組み込みのクエリエディタとの統合を介して SQL クエリを生成できます。さまざまなスキルレベルのデータプロフェッショナルが自然言語で分析ニーズを表現し、適切な形式の SQL クエリを受け取ることができるようになりました。 例えば、「年齢層と地域ごとの支払い方法の好みを分析してください」と依頼すると、Amazon Q Developer は複数のテーブルにわたる適切な結合を含む適切な SQL を生成します。 さらに、Amazon Q Developer は、ETL ジョブの構築に加えて、SageMaker Unified Studio Jupyter Notebook でのトラブルシューティングとリアルタイムでのコード提案の生成で開発者を支援することもできます。 今すぐご利用いただけます 利用可能なリージョン – Amazon SageMaker Unified Studio は現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック(ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン)、南米 (サンパウロ) の AWS リージョンでご利用いただけます。これらの機能の可用性の詳細については、 サポートされているリージョンのドキュメント ページを参照してください。 Amazon Q Developer サブスクリプション – Amazon Q Developer の無料利用枠はデフォルトで SageMaker Unified Studio で使用できます。追加のセットアップや設定は必要ありません。既に Amazon Q Developer Pro ティアのサブスクリプションをお持ちの場合は、これらの機能強化を SageMaker Unified Studio 環境で使用できます。詳細については、 ドキュメントのページ を参照してください。 Amazon Bedrock の機能 – Amazon SageMaker Unified Studio 内の Amazon Bedrock の機能の詳細については、 ドキュメントページ を参照してください。 Amazon SageMaker Unified Studio での構築を今すぐ開始してください。詳細については、 Amazon SageMaker Unified Studio のページを参照してください。 構築がうまくいきますように。 – Donnie Prakoso – ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

re:Invent 2024 では、表形式データの保存を大規模に効率化する組み込みの Apache Iceberg サポートを備えた初のクラウドオブジェクトストアである Amazon S3 Tables と、オープンで安全な統合データレイクハウスで分析と AI を簡素化する Amazon SageMaker Lakehouse をリリースしました。また、 Amazon Athena 、 Amazon Data Firehose 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon QuickSight を利用して S3 Tables データをストリーミング、クエリ、視覚化できるように、 Amazon Web Services (AWS) 分析サービスとの S3 Tables の統合もプレビューしました。 お客様は、Apache Iceberg ストレージの管理と最適化を簡素化したいと考えており、それが S3 Tables の開発につながりました。お客様は同時に、SageMaker Lakehouse を利用して、分析のコラボレーションとインサイトの生成を妨げるデータサイロを解消することに取り組んでいました。AWS の分析サービスとの組み込み統合に加えて、S3 Tables と SageMaker Lakehouse を組み合わせると、分析と機械学習 (ML) ワークフローの両方を可能にする複数のデータソースへのアクセスを統合する包括的なプラットフォームが得られます。 3 月 13 日、さまざまな分析エンジンとツールで S3 Tables の統合データアクセスを提供する Amazon S3 Tables と Amazon SageMaker Lakehouse の統合 の一般提供の開始をお知らせします。SageMaker Lakehouse には、AWS の分析および AI/ML サービスの機能とツールを統合した単一のデータおよび AI 開発環境である Amazon SageMaker Unified Studio からアクセスできます。SageMaker Lakehouse と統合されたすべての S3 テーブルデータは、SageMaker Unified Studio や、Amazon Athena、Amazon EMR、Amazon Redshift、Apache Iceberg 互換エンジン ( Apache Spark や PyIceberg など) などのエンジンからクエリできます。 この統合により、S3 Tables を読み書きしたり、Amazon Redshift データウェアハウスやサードパーティーおよびフェデレーテッドデータソース ( Amazon DynamoDB や PostgreSQL など) のデータと結合したりできる、安全な分析ワークフローの構築を簡素化できます。 また、S3 Tables のデータと SageMaker Lakehouse の他のデータに対するきめ細かいアクセス許可を一元的に設定および管理し、すべての分析エンジンとクエリエンジンに一貫して適用することもできます。 S3 Tables と SageMaker Lakehouse の統合の実際の動作 開始するには、 Amazon S3 コンソール に移動して、ナビゲーションペインから [テーブルバケット] を選択し、 [統合を有効にする] を選択して、AWS の分析サービスからテーブルバケットにアクセスします。 これで、SageMaker Lakehouse と統合するテーブルバケットを作成できます。詳細については、AWS ドキュメントの「 S3 Tables の開始方法 」にアクセスしてください。 1.Amazon S3 コンソールで Amazon Athena を利用してテーブルを作成する Amazon Athena を利用して、わずか数ステップでテーブルを作成し、データを入力して、Amazon S3 コンソールから直接クエリできます。テーブルバケットを選択して [Athena でテーブルを作成] を選択するか、または既存のテーブルを選択して [Athena でテーブルをクエリ] を選択します。 Athena を利用してテーブルを作成する場合は、まずテーブルの 名前空間 を指定する必要があります。S3 テーブルバケット内の名前空間は AWS Glue のデータベースに相当し、テーブルの名前空間を Athena クエリのデータベースとして使用します。 名前空間を選択し、 [Athena でテーブルを作成] を選択します。Athena コンソールの [クエリエディタ] に移動します。S3 テーブルバケット内にテーブルを作成したり、テーブル内のデータをクエリしたりできます。 2.SageMaker Unified Studio で SageMaker Lakehouse を利用してクエリする SageMaker Unified Studio から直接、S3 データレイク、Redshift データウェアハウス、SageMaker Lakehouse 内のサードパーティーおよびフェデレーテッドデータソース全体の統合データにアクセスできるようになりました。 開始するには、 SageMaker コンソール に移動し、サンプルプロジェクトプロファイル Data Analytics and AI-ML model development を私用して、SageMaker Unified Studio ドメインとプロジェクトを作成します。詳細については、AWS ドキュメントの「 Create an Amazon SageMaker Unified Studio domain 」にアクセスしてください。 プロジェクトが作成されたら、プロジェクトの概要に移動し、プロジェクトの詳細まで下方向にスクロールして、プロジェクトロールの Amazon リソース名 (ARN) を書き留めます。 AWS Lake Formation コンソール に移動し、 AWS Identity and Access Management (IAM) ユーザーとロールに許可を付与します。 [プリンシパル] セクションで、前の段落で書き留めた <project role ARN> を選択します。 [LF タグまたはカタログリソース] セクションで [名前付きデータカタログリソース] を選択し、 [カタログ] のために作成したテーブルバケット名を選択します。詳細については、AWS ドキュメントの「 Overview of Lake Formation permissions 」にアクセスしてください。 SageMaker Unified Studio に戻ると、プロジェクトページの左側のナビゲーションペインにある [データ] メニューの [Lakehouse] の下にテーブルバケットプロジェクトが表示されます。 [アクション] を選択すると、Amazon Athena、Amazon Redshift、または JupyterLab Notebook でテーブルバケットデータをクエリする方法を選択できます。 [Athena でクエリ] を選択すると、自動的に [クエリエディタ] に移動し、Athena を利用して S3 テーブルに対してデータクエリ言語 (DQL) およびデータ操作言語 (DML) クエリを実行します。 Athena を利用したサンプルクエリを次に示します: select * from "s3tablecatalog/s3tables-integblog-bucket”.”proddb"."customer" limit 10; Amazon Redshift を利用してクエリするには、データクエリ分析のために Amazon Redshift Serverless コンピューティングリソースを設定する必要があります。その後、 [Redshift でクエリ] を選択し、 [クエリエディタ] で SQL を実行します。JupyterLab Notebook を利用する場合は、 Amazon EMR Serverless で新しい JupyterLab スペースを作成する必要があります。 3.他のソースのデータと S3 Tables データを結合する SageMaker Lakehouse で S3 Tables データを利用できるようになったことで、データウェアハウス、リレーショナルまたは非リレーショナルデータベースなどのオンライントランザクション処理 (OLTP) ソース、Iceberg テーブル、他のサードパーティーソースのデータと結合して、より包括的で深いインサイトを得ることができるようになりました。 例えば、 Amazon DocumentDB 、Amazon DynamoDB、Amazon Redshift、PostgreSQL、MySQL、Google BigQuery、Snowflake などのデータソースへの接続を追加し、抽出、変換、ロード (ETL) スクリプトを使用せずに SQL を使用してデータを結合できます。 クエリエディタで SQL クエリを実行して、S3 Tables のデータと DynamoDB のデータを結合できるようになりました。 Athena と DynamoDB を結合するサンプルクエリを次に示します: select * from "s3tablescatalog/s3tables-integblog-bucket"."blogdb"."customer", "dynamodb1"."default"."customer_ddb" where cust_id=pid limit 10; この統合の詳細については、AWS ドキュメントの「 Amazon S3 Tables integration with Amazon SageMaker Lakehouse 」にアクセスしてください。 今すぐご利用いただけます S3 Tables と SageMaker Lakehouse の統合は、 S3 Tables が利用可能な すべての AWS リージョンで一般提供が開始されました。詳細については、 S3 Tables の製品ページ と SageMaker Lakehouse のページ にアクセスしてください。 今すぐ SageMaker Unified Studio で S3 Tables をお試しいただき、 AWS re:Post for Amazon S3 および AWS re:Post for Amazon SageMaker に、または通常の AWS サポートの連絡先を通じて、フィードバックをぜひお寄せください。 Amazon S3 のリリース の毎年恒例のお祝いとして、Amazon S3 と Amazon SageMaker のすばらしいリリースをさらにご紹介する予定です。詳細については、 3 月 14 日に開催される AWS Pi Day イベント にご参加ください。 – Channy – ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

本記事は、2025/1/21 に公開された Generate vector embeddings for your data using AWS Lambda as a processor for Amazon OpenSearch Ingestion を翻訳したものです。翻訳は Solutions Architect の山下一樹が担当しました。 2024 年 11 月 22 日、Amazon OpenSearch Ingestion が AWS Lambda プロセッサのサポートを開始しました 。 この新機能の提供により、OpenSearch Ingestion パイプラインでログ、メトリクス、トレースデータを加工・変換する柔軟性が高まりました。 例えば、基盤モデル (FM) を使用してデータから埋め込みベクトルを生成したり、 Amazon DynamoDB などの外部データソースを参照してデータをエンリッチできます。 Amazon OpenSearch Ingestion は、ログ、メトリクス、トレースデータをリアルタイムで Amazon OpenSearch Service ドメインと Amazon OpenSearch Serverless コレクションに配信する、完全マネージド型のサーバーレスデータパイプラインです。 プロセッサ は、OpenSearch Ingestion パイプラインのコンポーネントで、目的の形式に変換した上で、指定した出力先にイベントを出力する前に、イベントをフィルタリング、変換、エンリッチできます。 パイプライン構成でプロセッサが定義されていない場合、イベントはソースコンポーネントで指定された形式で公開されます。 単一のパイプラインに複数のプロセッサを組み込むことができ、パイプライン構成で定義された順序で順次実行されます。 OpenSearch Ingestion では、データを変換する際に、ビルトインのネイティブプロセッサと共に Lambda 関数をプロセッサとして使用するオプションがあります。 イベントカウントまたはサイズに基づいて、イベントをまとめてバッチ的に Lambda を呼び出すことで、パフォーマンスとコストを最適化できます。 Lambda を使用すると、サーバーをプロビジョニングまたは管理する必要がなくなり、ワークロード量に応じてクラスターのサイズを変更するためのロジック、イベント統合の保守、ランタイムの管理が不要になります。 この投稿では、OpenSearch Ingestion の Lambda プロセッサを使用して、ソースデータの埋め込みを生成し、 OpenSearch Serverless ベクトルコレクション に取り込む方法を示します。 このソリューションは、OpenSearch Ingestion パイプラインの柔軟性と Lambda プロセッサを組み合わせて、動的に埋め込みを生成します。 Lambda 関数は、 Amazon Bedrock でホストされている Amazon Titan Text Embeddings Model を呼び出すため、効率的かつスケーラブルな埋め込み作成が可能です。 このアーキテクチャにより、レコメンデーションエンジン、パーソナライズされたチャットボット、不正検知システムなど、さまざまなユースケースの実装を簡単にします。 OpenSearch Ingestion、Lambda、OpenSearch Serverless を統合すると、文書埋め込み生成と検索のためのサーバーレスアプローチが提供されます。 この組み合わせにより、ワークロードの需要に合わせて自動的にスケーリングする、従量課金モデルが提供されます。 AWS がインフラストラクチャ、アップデート、メンテナンスを管理するため、運用が簡素化されます。 このサーバーレスアプローチにより、インフラストラクチャの管理ではなく、検索とアナリティクスソリューションの開発に集中できます。 Amazon OpenSearch Service は、 ニューラル検索 も提供しており、テキストをベクトル表現に変換し、テキストを取り込む際と検索時の両方でベクトル検索を容易にします。 テキストを取り込む際に、ニューラル検索はドキュメントテキストをベクトル表現に変換し、テキストとそのベクトル表現の両方をベクトルインデックスにインデックス化します。 バージョン 2.9 以上を実行するマネージドクラスターでは ニューラル検索を利用できます 。 ソリューションの概要 このソリューションは、 Amazon Simple Storage Service (Amazon S3) に保存されているデータセットから埋め込みベクトルを生成します。 OpenSearch Ingestion によって配信されたペイロードに対して、Amazon Titan モデルを適用するために Lambda 関数を使用します。 前提条件 Lambda 関数と Amazon Bedrock モデルを呼び出し、OpenSearch Serverless コレクションに書き込む適切な権限を持つロールが必要です。 コレクションにアクセスするには、コレクションへのアクセスを許可するアクセス許可ポリシーを持つ AWS Identity and Access Management (IAM) パイプラインロールを構成する必要があります。詳細については、 Amazon OpenSearch Ingestion パイプラインにコレクションへのアクセスを許可する を参照してください。以下はコードの例です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowinvokeFunction", "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": "arn:aws:lambda:{{region}}:{{account-id}}:function:{{function-name}}" } ] } このロールには、OpenSearch Ingestion がロールを引き受けることを許可する以下の信頼関係が必要です : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "osis-pipelines.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } OpenSearch Ingestion パイプラインの作成 ブループリントを使用してパイプラインを作成できます。この投稿では、 AWS Lambda カスタム エンリッチメント ブループリントを選択します。 データセットには、 IMDB title basics dataset を使用します。このデータには、 originalTitle 、 runtimeMinutes 、ジャンルなどの映画情報が含まれています。 OpenSearch の取り込みパイプラインは、Lambda プロセッサを使用して original_title フィールドの埋め込みを作成し、その埋め込みを original_title_embeddings として他のデータと共に保存します。 次のパイプラインコードを参照してください : version: "2" s3-log-pipeline: source: s3: acknowledgments: true compression: "none" codec: csv: aws: # Provide the region to use for aws credentials region: "us-west-2" # Provide the role to assume for requests to SQS and S3 sts_role_arn: "<<arn:aws:iam::123456789012:role/ Example-Role>>" scan: buckets: - bucket: name: "lambdaprocessorblog" processor: - aws_lambda: function_name: "generate_embeddings_bedrock" response_events_match: true tags_on_failure: ["lambda_failure"] batch: key_name: "documents" threshold: event_count: 4 aws: region: us-west-2 sts_role_arn: "<<arn:aws:iam::123456789012:role/Example-Role>>" sink: - opensearch: hosts: - 'https://myserverlesscollection.us-region.aoss.amazonaws.com' index: imdb-data-embeddings aws: sts_role_arn: "<<arn:aws:iam::123456789012:role/Example-Role>>" region: us-west-2 serverless : true OpenSearch Ingestion パイプラインの Lambda プロセッサをより詳しく見てみましょう。 key_name パラメータに注目してください。key_name には任意の値を指定できますが、Lambda 関数では OpenSearch 取り込みからのペイロードを処理する際にこのキーを参照する必要があります。ペイロードのサイズはバッチ設定によって決まります。Lambda プロセッサでバッチ処理が有効になっている場合、OpenSearch 取り込みは複数のイベントをまとめて 1 つのペイロードにし、Lambda 関数を呼び出します。以下のいずれかの条件を満たすと、バッチが Lambda に送信されます。 event_count – イベント数が指定された制限に達した時 maximum_size – バッチの合計サイズが指定されたサイズ (例えば 5MB) に達した時。最大 6MB (AWS Lambda の呼び出し時のペイロードサイズの上限) まで設定可能 Lambda 関数 Lambda 関数は OpenSearch Ingestion からデータを受け取り、Amazon Bedrock を呼び出してベクトル埋め込み表現を生成し、ソースレコードにそれを追加します。 documents は OpenSearch Ingestion から入ってくるイベントを参照するために使用され、パイプラインで宣言された key_name と一致します。Lambda 関数は、Amazon Bedrock からの埋め込みベクトルを元のレコードに追加します。この埋め込みベクトルが追加された新しいレコードは、OpenSearch Ingestion によって OpenSearch Serverless に出力されます。 次のコードを参照してください : import json import boto3 import os # Initialize Bedrock client bedrock = boto3.client('bedrock-runtime') def generate_embedding(text): """Generate embedding for the given text using Bedrock.""" response = bedrock.invoke_model( modelId="amazon.titan-embed-text-v1", contentType="application/json", accept="application/json", body=json.dumps({"inputText": text}) ) embedding = json.loads(response['body'].read())['embedding'] return embedding def lambda_handler(event, context): # Assuming the input is a list of JSON documents documents = event['documents'] processed_documents = [] for doc in documents: if 'originalTitle' in doc: # Generate embedding for the 'originalTitle' field embedding = generate_embedding(doc['originalTitle']) # Add the embedding to the document doc['originalTitle_embeddings'] = embedding processed_documents.append(doc) # Return the processed documents return processed_documents Lambda プロセッサを使用中に例外が発生した場合、バッチ内のすべてのドキュメントは失敗したイベントとみなされ、後続の処理フローがある場合はそちらに、なければ失敗と分かるように付与されたタグを付けて sink に転送されます。 このタグは、パイプラインの tags_on_failure パラメータで構成でき、エラーは CloudWatch ログにも送信されるため、さらなるアクションが可能です。 パイプラインの実行後、埋め込みが作成され、 k-NN インデックス である imdb-data-embeddings 内のドキュメントに originalTitle_embeddings として格納されます。 次のスクリーンショットは、その例を示しています。 まとめ この投稿では、OpenSearch Ingestion パイプラインの一部として Lambda を使用して、データの複雑な変換とエンリッチを可能にする方法を示しました。 この機能の詳細については、 AWS Lambda を使用した OpenSearch Ingestion パイプラインの利用 を参照してください。 著者について Jagadish Kumar (Jag) は、Amazon OpenSearch Service に特化した AWS のシニアスペシャリストソリューションアーキテクトです。データアーキテクチャに情熱を持ち、AWS 上でアナリティクスソリューションを大規模に構築するお客様をサポートしています。 Sam Selvan は、Amazon OpenSearch Service の主任スペシャリストソリューションアーキテクトです。 Srikanth Govindarajan は、Amazon OpenSearch Service のソフトウェア開発エンジニアです。Srikanth は、検索、分析、セキュリティ、AI、機械学習ベースのユースケースのためのインフラストラクチャを設計し、スケーラブルなソリューションを構築することに情熱を持っています。

概要 SAP RISE を介した SAP S/4HANA の実装や AWS 上でのネイティブな実装は、長期にわたるタイムラインと複雑さを伴うため、企業にとって大規模な取り組みとなります。SAP 導入プロジェクトの成功要因は、シンプルなビジネスプロセスの検討と主要業務課題の整理であり、適切に管理されたシステム環境において調整作業や徹底したテスト、そして包括的な研修プログラムを通して組織変化を繰り返す必要があります。 本番環境の実装が始まるずっと前から、お客様やパートナー企業は、AWS 上に非運用 SAP S/4HANA システムを展開して、パフォーマンスと機能を評価したいとお考えかもしれません。この事前準備を行う事で、Fit&Gap 分析の実施や、本番ワークロードを移行する前に AWS サービスがビジネスプロセスをどのようにモダナイズできるかを検討できるようになり、結果的に強力なビジネスケースを確立する支えとなります。 このような評価用に、SAP では「Fully-Activated Appliance (FAA)」と呼ばれる、サンドボックス、概念実証、範囲決定、Fit&Gap 分析などの非運用環境向けにプリパッケージ化された SAP S/4HANA システムを提供しています。 このシステムには、SAP Best Practices に基づくデモシナリオが既に用意されており、利用可能な全ローカライズに対して SAP Best Practices のグリーンフィールドアクティベーション用にクライアントが別途用意されています。 SAP S/4HANA FAA は、主に 2 つの方法でデプロイできます。 SAP Cloud Appliance Library (SAP CAL) の操作 最速で最も簡単な方法は、次のとおりです。SAP CAL を使用すれば、AWS 上にアプライアンスを約 1 時間から 2 時間で展開できます。SAP CAL には、すぐに使用できる事前に構成済みのシステムテンプレートが用意されています。ただし、SAP CAL を利用する場合、展開された SAP 製品の SAP ライセンスが必要であることにご注意ください。アプライアンスを 30 日以上使い続ける予定の場合は、次の 2 点を考慮する必要があります。 アプライアンスに組み込まれた SAP 製品のライセンスが必要です SAP Cloud Appliance Library のサブスクリプションが必要です SAP Cloud Appliance Library システムは、アプライアンス作成を開始した S-User に関連付けられた組織のライセンスとサブスクリプションのステータスを検証します。 最初の 30 日間を過ぎた後のアプライアンスの有効化には、必要なライセンスの正常な検証と、有効な SAP Cloud Appliance Library サブスクリプションが条件となります。 詳細については、 SAP Cloud Appliance Library FAQ および ライセンスの FAQ を参照してください。 カスタムインストール 既に SAP のライセンスをお持ちで、インフラストラクチャにより細かい制御が必要な場合や、特定の AWS アカウント構造に合わせる必要がある場合は、自身の AWS 環境にアプライアンスを手動でセットアップするオプションがあります。 この方法では柔軟性が高まりますが、より高度な技術力と時間を要し、通常、セットアップには数日を要します。 SAP の業務アプリケーションソフトウェア SAP S/4HANA Finance Accounting and Analytics (FAA) のインストールプロセスは、標準の SAP インストールとは異なり、「評価版を使った段階」でユーザーが機能面で難しいと感じる複数の技術的ステップが含まれています。しかし、このブログではより効率的な代替手順を紹介します。 ここでは、 AWS Launch Wizard を使用した自動化インストール方法について説明し、デプロイ時間と手間を 2 時間以内に短縮する方法を概説します。 このブログの目的は、このストリームライン化されたアプローチが、SAP S/4HANA の初期探索段階と導入を加速する方法を説明し、組織が AWS での RISE with SAP またはネイティブな SAP S/4HANA ジャーニーを進める手助けをすることです。 主要な検討事項 カスタムインストールオプションでは、特定の AWS アカウントの構造と管理コントロールに合わせて設定をカスタマイズできます。 この方法では、システムに対する完全な管理権と包括的な構成制御を与えられます。 この方法は、データガバナンスポリシーが厳格な組織や、固有のインフラストラクチャニーズのある組織に適しています。 どの方法を選んでも、事前にベストプラクティスが設定された SAP S/4HANA 環境と、評価、テスト、概念実証用のサンプルデータやデモシナリオを提供します。 AWS Launch Wizard を活用すれば、SAP S/4HANA FAA のセットアップ時間を数日から 2 時間以内に短縮できます。 前提条件 SAP S/4HANA FAA インストールメディアと SWPM (Software Provisioning Manager)を、 Amazon S3 バケットに格納します。 自動インストールパッケージとドキュメントを提供する SAP on AWS Automation GitHub リポジトリ へのアクセスが必要です。現在、インストールパッケージは SAP S/4HANA 2023 FPS00 Fully-Activated Appliance のインストールのみをサポートしています。 SAP S/4HANA トライアルライセンス (30 日間有効、AWS サービスの料金のみ適用) が必要です。詳細については、SAP KBA:  2041140 – オンプレミスデプロイ用の SAP S/4HANA の完全にアクティブ化されたアプライアンスの注文 を参照してください。 SAP S/4HANA FAA をデプロイするには、 Amazon Virtual Private Cloud (VPC) と Amazon EC2 キーペア を適切に設定する必要があります。この ネットワーク設定は、AWS 内で SAP 環境をセキュアに保ち、アクセスするために不可欠です。 アーキテクチャ このストリームラインされたインストールアプローチを実現するため、必要なデプロイメントファイルが含まれる GitHub リポジトリを積極的に管理しています。サポートされるバージョンや詳細なインストール手順については、 こちら を参照してください。 図 1: SAP S/4HANA FAA 自動デプロイのGitHub リポジトリ 図 2: アーキテクチャの概要 インストール手順 SAP S/4HANA FAA をインストールするには、次の手順に従ってください。 まず、SAP Software Download Center から SAP S/4HANA FAA インストール メディアと SWPM をダウンロードしてください。次に、これらのファイルを Amazon S3 バケットにアップロードします。Amazon S3 バケットの名前は “launchwizard-” で始まる必要があります。 図 3: SAP S/4HANA FAA エクスポートファイル 図 4: SAP Software Provisioning Manager (SWPM) ファイル 図 5: 必要なインストールファイルのディレクトリ構造 次に、 この 場所から post_deploy_s4h_faa.sh スクリプトをダウンロードします。 このスクリプトを開いて、次の 3 つの重要なパラメーターを設定してください。 s4h_faa_exports : SAP S/4HANA FAA の .ZIP ファイルを保管した S3 URI パスを設定します。 s4h_swpm : Software Update Manager の.SAR ファイルを置いた S3 URI パスを設定します。 s4h_version : インストールする SAP S/4HANA FAA のバージョンを選択するために設定します (現在は 2023_FPS00 のみサポート対象です) 図 6: 調整が必要な変数が強調表示された post_deploy_s4h_faa.sh ファイル これらの変更が完了したら、post_deploy_s4h_faa.sh スクリプトを SAP インストールメディアが入った同じ S3 バケットにアップロードします。ファイルは post_deploy ディレクトリに格納してください。 これで AWS コンソールにアクセスし、 SAP S/4HANA システムをデプロイしたいリージョンを選択 します。 図 7: AWS リージョンを選択する AWS Launch Wizard サービスに移動し、 単一インスタンスのデプロイのみの AWS インフラストラクチャ のセットアップを開始してください。SAP S/4HANA をホストするのに十分なメモリとストレージを確保するために、少なくとも R[5 | 6 | 7]i.8xl の EC2 インスタンスサイズを選択してください。 詳細については、 AWS Launch Wizard User Guide を参照してください。SAP S/4HANA のインストールパッケージは、コンソールと AWS CLI の両方でデプロイをサポートしています。AWS CLI を使用する場合は、デプロイ前に サンプル JSON 仕様ファイル をダウンロードし、お客様のニーズに合わせてカスタマイズすることができます。 この処理の際、post_deploy_s4h_faa.sh スクリプトを、デプロイ後の設定スクリプトとして指定してください。 図 8: 配置後の構成スクリプトフォーム 図 9: SAP アプリケーションソフトウェアのインストールフォーム デプロイプロセスが正常に完了すると、指定されたホスト上で SAP S/4HANA FAA 2023 FPS00 にアクセスできるようになります。 デプロイには約 60 分から 90 分かかる見込みです。進捗状況は “/root/install/post_deploy.log” のデプロイログを確認してモニタリングできます。 デプロイが完了すると、ログにパスワードを含む SAP システムの詳細が表示されます。 図 10: post_deploy.log 内の SAP S/4HANA システム詳細 参考費用 AWS Launch Wizard は、SAP デプロイの動的なコスト見積もりを提供します。 EC2 インスタンスタイプを選択した後、EC2 やストレージなどのコアサービスの概算の月額料金の内訳を確認できます。 構成を変更するたびに、この見積もりはリアルタイムで更新されるので、デプロイ前にコストを最適化できます。 以下の表は、米国東部 (バージニア北部) リージョンで推奨されるインスタンスサイズに基づく概算価格を示しています。 SAP S/4HANA FAA デプロイメントの参考費用 リソース 説明 金額 (USD/月) コンピューティングインスタンス インスタンスタイプ: r6i.8xlarge 1471.68 USD ストレージボリューム ボリュームタイプ: gp3 124.16 USD ボリュームタイプ: st1 51.20 USD 月額費用 1647.04 USD EC2 インスタンスを夜間や週末など使用しない時間に非アクティブ化することで、さらにコストを削減することができます。これは、 AWS Systems Manager for SAP により実現できます。 まとめ AWS Launch Wizard を使用して SAP S/4HANA の評価と実装プロセスを効率化するには、次のステップを実行できます。 GitHub リポジトリ にアクセスして、自動化パッケージを確認する AWS コンソール に移動して、Launch Wizard を開始する 説明された自動化された方法を使って、SAP S/4HANA FAA のデプロイを開始する この手順に従うことで、SAP S/4HANA FAA と AWS が提供する幅広い機会を探索できる環境が、すぐに構築できます。 このようにすれば、組織は適切な判断を下すことができ、RISE on AWS と Native SAP on AWS の導入を加速できるでしょう。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

はじめに 現代の競争の激しい産業環境において、風力タービン、ロボット、鉱業機械などの産業機械メーカーは、自社製品の能力を最大限に活用する革新的な方法を常に模索しています。これらの機械を接続することで、前例のない可視性を獲得し、新たな収益源を開拓し、顧客に向上したサービスを提供することができ、設備や操業をより賢いものに変えます。しかし、機械からクラウドまでを接続する包括的なソリューションをゼロから構築するのは、複雑で時間のかかる作業になりがちです。これには、ローカル計算能力の確立、データの収集と統合、リアルタイムでデータのカタログ化と変換、アクセスインターフェースの開発、AI、機械学習、生成 AI ユースケースを可能にする高度な分析の実行が必要です。ここで AWS の IoT 関連マネージドサービスが役立ちます。 AWS のモノのインターネット (IoT) および 人工知能 (AI) のサービス群は、産業機械メーカーが複雑なインフラストラクチャ構築やエンジニアリングに多額の投資をせずに、スマートで安全かつスケーラブルなソリューションを迅速に開発できるように特別に設計されています。AWS の堅牢なインフラストラクチャと先進技術を活用すれば、メーカーは運用の効率化、データ分析による深い洞察の獲得、さらには最先端の機械学習ソリューションの実装が可能になります。これにより、高品質な製品の設計・生産に集中できるだけでなく、製品機能の継続的な強化、追加サービスの提供、そして新たな収益源の創出も可能になります。これらすべては、AWS が信頼性と安全性の高いプラットフォームで技術管理とスケーラビリティの複雑さを処理する中で達成されます。このブログ投稿では、AWS IoT マネージドサービスが産業変革をどのように加速できるかを探り、さまざまな AWS IoT 顧客からのベストプラクティスを共有します。 スマート産業機械の構築、展開、保守における課題 産業機械メーカーがスマートで接続された企業へと変革する道のりには、大きな課題が待ち構えています。この分野の先進企業は製品と業界に関する深い専門知識を持つ一方で、複雑なエッジコンピューティングやクラウドベースのアプリケーションを迅速かつ大規模に展開するための内製能力に欠けることがあります。数千台の価値ある産業機械の接続、適切なサイバーセキュリティ標準の維持、総所有コストの管理、などといったロジスティクスを調整することは、すぐに企業にとって非常に大きな負担となります。その結果、産業機械メーカーは、コアビジネスイノベーションに集中できず、差別化されていない作業に多くの時間とリソースを費やすことがよくあります。産業機械のユーザーは、より高機能で効率的な機械と、新しいデジタルサービスの提供を期待しています。競争力を維持するために、産業機械メーカーはこれらの新機能を迅速に開発および展開し、同時にソフトウェアの開発、品質保証プロセスの実行、IT インフラストラクチャの監視と運用など、これらの産業機械の維持に必要なリソースを削減する必要があります。しかし、必要な技術基盤をゼロから構築すると、市場投入までの時間が大幅に遅れ、進化する市場需要への対応力が損なわれる可能性があります。産業界のリーダーが求めているのは、実証済みでスケーラブル、かつコスト効果の高いソリューションです。それにより、コア製品のイノベーションと顧客価値の提供に集中しながら、新しい AI/ML 機能を搭載したスマートで接続された機械を迅速に開発・展開できるようになります。 AWS IoT マネージドサービスによるイノベーションの加速 ゼロからソリューションを構築し維持することは、もはやどの産業機器メーカーにも必要ありません。デジタル変革に着手したばかりの企業も、すでにスマートマシン化に取り組んでいる企業も、AWS IoT マネージドサービスの恩恵を受けることができます。これらのサービスを活用することで、メーカーはリソースをビジネスイノベーションに集中させ、コストを削減し、市場投入までの時間を短縮できます。すべての企業は、技術基盤をゼロから構築する代わりに、AWS マネージドサービスの API を活用することで、機器のデータ処理とデバイス管理のニーズを簡単に満たせます。これにより、新規顧客の獲得や新たな収益源の創出などのコアコンピテンシーに集中しながら、より迅速かつコスト効果的にソリューションを開発することができます。さらに、すでに IoT ソリューションを導入済みの企業でも、デジタルツインや AI/ML などの高度な機能を統合することで、システム保守の簡素化、コスト削減、そしてデジタルサービスの強化が可能になります。 また、 AWS 上のデジタルツインフレームワークに関するガイダンス にアクセスして、産業用モノのインターネット (IoT)、空間コンピューティング、シミュレーションのユースケース向けにデジタルツインを作成するための AWS サービスの活用方法をご覧ください。  AWS IoT との統合の全体像 産業機械をクラウドに接続するには、安全なデバイス接続、リモート管理、高度なデータ処理と分析など、さまざまな技術をシームレスに統合する必要があります。AWS の IoT サービスポートフォリオは、これらの課題に対処する包括的なエンドツーエンドの機能を提供し、産業機械メーカーが迅速かつ効率的にスマートなエッジからクラウドに接続された機械を構築し維持できるようにします。これらの機能は、メーカーが新しいサービスや収益源を創出するために機械から得られる産業データを活用する際にも役立ちます。 AWS IoT Core は、産業機械とクラウドの間の安全な双方向通信を提供するマネージドサービスであり、産業機械と AWS クラウドの間の安全な接続ブローカーとして機能します。AWS IoT Core は、デバイスから送信されるデータが到着した際に、安全な受信と処理を確保します。このサービスは MQTT、HTTPS、WebSocket 経由の MQTT をサポートし、信頼性の高い常時接続を確保すると同時に、重要な ID およびメッセージルーティング機能も処理します。 AWS IoT Core で利用可能な接続された産業機械からのテレメトリデータ、または産業機械から直接発信されるデータは、 AWS IoT SiteWise を使用して簡単に取り込み、処理できます。この産業部門向けに特別に構築されたサービスは、データの収集と分析を効率化し、メーカーが貴重な洞察を得て、スマート製品の運用を最適化できるようにします。 AWS IoT SiteWise は時系列データを収集して保存するだけでなく、このデータをコンテキスト化、モデル化し、柔軟なインターフェースと事前構築されたAWS サービスとの統合を通じてアクセスするための高度なエッジ・クラウド機能も提供します。これらの統合には、実世界システム用のデジタルツイン作成を簡素化する AWS IoT TwinMaker や、異常な機器の動作を自動的に検出して予知保全を支援しダウンタイムを削減する Amazon Lookout for Equipment  あるいは Amazon SageMaker AI  、  Asset Maintenance & Reliability ソリューション が含まれます。これらの事前構築された統合機能と柔軟な API により、企業は複雑な統合作業を自ら行うことなく、貴重な洞察を得られます。 AWS IoT Device Defender は、産業機械のセキュリティ強化のための堅牢なフレームワークを提供します。このサービスは、セキュリティのベストプラクティスに対する機器群のコンプライアンスを定期的に監査し、異常な動作を検出して、潜在的な問題を通知します。これにより、産業機械メーカーの一般的なセキュリティ懸念に対処できます。 最後に、マネージドサービスを利用することで総所有コストを抑制できます。AWS の IoT サービスポートフォリオを活用することで、産業メーカーはスマート産業機械 (Smart Industrial Machine) をサポートするデジタルインフラストラクチャを開発および維持するための大規模な社内 IT チームを維持する必要性を減らすことができます。これにより、リソースをより効率的に配分し、日常的な IT タスクの管理ではなく、市場差別化と顧客価値の向上のため、コア製品のイノベーションに集中することができます。 スマート産業機械向け AWS アーキテクチャガイダンスの概要 現代の産業環境では、運用効率と製品イノベーションを向上させるために先進技術を活用することが重要です。以下の図は、AWS IoT サービスを使用したスマート産業機械のための包括的なアーキテクチャを示しています。このアーキテクチャは、安全なデバイス接続やエッジコンピューティングから、堅牢なデータ管理や高度な分析まで、様々な AWS IoT サービスを統合しています。これにより、スケーラブルで安全、かつ効率的なソリューションを実現します。それは、産業機械メーカーの機械がクラウドに接続し、データを管理し、セキュリティを確保し、AI/ML 機能を活用する方法を示し、これによりこれらのメーカーは AWS が複雑な技術インフラストラクチャを処理するすることで、製品の中核部分の革新と顧客価値の提供に集中できるようにします。 図 1 – スマート産業機械の接続と管理 産業機械は、 AWS IoT Greengrass が提供するマネージドエッジランタイム、MQTT 準拠のクライアント、または AWS IoT Device SDK などのさまざまなエッジソフトウェアオプションを使用して、産業機械は AWS IoT Core に接続できます。テレメトリデータは AWS IoT Core で利用可能になるとすぐにどのバックエンドにもシームレスに取り込まれ、IoT Core ルールを使用して AWS IoT SiteWise に直接ルーティングできます。さらに、AWS IoT SiteWise はサービスに直接データを取り込むための REST API を提供しています。 AWS IoT SiteWise は、データの取り込み、リアルタイムデータ処理、高度なデータストレージ、堅牢なデータアクセス機能を提供します。直接インターネット接続がない環境に設置された産業機械の場合、エッジゲートウェイが実行中のプロセス、接続性、ローカルデータ処理を管理できます。エッジゲートウェイは産業機械からデータを収集し、処理・保存を行い、AWS IoT Greengrass 上で実行される エッジコンポーネントである AWS IoT SiteWise Edge を使用してリモート管理され、データをコスト効率よく AWS IoT SiteWise に転送します。さらに、このマネージドランタイムを活用して、ローカル処理や AI/ML 推論をサポートするための追加コンポーネントをエッジに展開することができます。 AWS IoT Core は産業機械をクラウドに安全に接続する方法を提供します。このマネージドサービスには、 ID とアクセス管理、メッセージブローカー機能、メッセージルーティング機能が含まれており、これらはすべて TCPまたは WebSocket 経由の MQTT プロトコルによる常時接続の双方向通信によってサポートされています。さらに、このサービスはメッセージ発行のための HTTPS もサポートしています。 AWS IoT Device Management を活用することで、産業機械やゲートウェイをリモートでプロビジョニング、監視、更新、トラブルシューティングを大規模に行うことができます。このサービスにより、ユーザーはデバイス情報と構成をアップロードして表示し、デバイスインベントリを整理し、デバイスフリートを監視し、個々のデバイスのトラブルシューティングを行い、オーバージエア (OTA) ソフトウェアアップデートを含む様々な場所に展開されたデバイスをリモートで管理することができます。 AWS IoT Device Defender は、セキュリティのベストプラクティスに対するフリートのコンプライアンスを監査し、フリートを継続的に監視し、異常な動作を検出し、セキュリティの発見事項を警告します。これらの発見事項は AWS Security Hub にも送信され、さまざまな AWS サービス全体のすべてのセキュリティ問題の集中ビューを提供します。 AWS IoT SiteWise を使って、産業用機械からの運用データを取り込み、データストリーム、アセットモデル、アセットカタログを通じて、効果的に収集し、整理することができます。プラットフォームを活用して、パフォーマンスメトリクスを計算し、利用可能な３つのストレージ階層にわたって時系列データを保存し、アラームを定義します。このサービスは、 Amazon S3 上のホットストレージとウォームストレージ、SQL ライクなクエリインターフェース、ユーザーフレンドリーな API、AWS IoT Core に機械データの更新をシームレスに公開するためのプロパティ通知など、複数のインターフェースを通じて外部アプリケーション向けの柔軟なデータアクセスを提供します。 図 2 – スマート産業機械のための産業データ基盤の構築 AWS IoT SiteWise が提供するコンテキストデータを使用して産業データレイクを構築します。 AWS Lake Formation を使用してこのデータを統制、保護、共有し、高度な分析を行います。 AWS Glue や Amazon Athena などの AWS 分析サービスを使用してデータをカタログ化し分析します。 AWS IoT SiteWise Monitor または Amazon Managed Grafana を使用して、リアルタイムに近い形で産業機械をリモートで監視し、豊富なコンテキストダッシュボードを作成します。 AWS IoT TwinMaker でデジタルツインを構築するか、 AWS Amplify を含む好みのフレームワークを使用してカスタムアプリケーションを開発します。これは AWS IoT Application Kit を活用しています。 高度なアラームしきい値を使用して異常を検出し、 AWS IoT Events と Amazon SNS を使用して機械の健全性について運用担当者に通知します。さらに、AWS IoT Events のディテクターモデルを活用して、ステートマシンと複雑なイベント監視アプリケーションを作成します。 AWS SageMaker や Amazon Bedrock などのサービスを使用してカスタム AI/ML ソリューションを開発します。さらに、 Amazon Lookout for Vision あるいは Computer Vision for Quality Insights や Amazon SageMaker JumpStart が提供する組み込みの computer vision algorithms と pre-trained defect detection models  を活用してコンピュータビジョンを使用した欠陥検出を行います。 Amazon QuickSight やお好みのBIツールを使って、クラウドデータウェアハウスを構築し、データに基づいた意思決定やインサイトの生成を行うことができます。Amazon QuickSight の Amazon Q 機能を使えば、ビジネスユーザーが自然言語で質問をし、数秒で分析結果を得ることができます。さらに、 Amazon Q Business という生成AIベースのエンタープライズアシスタントを活用すれば、企業ユーザーが企業システムのデータに基づいて質問に答えたり、セキュアにタスクを完了したりすることができます。 Amazon API Gateway と AWS AppSync を使用してサーバーレス API を構築し、何百万ものユーザーに拡張できる履歴データとリアルタイムに近い製品データを顧客に提供します。 構成管理には Amazon DynamoDB 、アーティファクトストレージには Amazon S3 、CI/CD プロセスの自動化には AWS CodePipeline 、エッジデバイスのライフサイクル管理には AWS IoT Greengrass を活用します。これらのサービスを統合することで、クラウドとエッジの両方のアプリケーションの展開、管理、更新を効果的に効率化できます。 Amazon Connect を使えば、顧客サービスのニーズに対応でき、エージェントに製品情報や問題解決のための提案といった文脈情報を提供することができます。これにより、より迅速な問題解決が可能になります。 AWS ソリューションライブラリの AWS 上のスマート産業機械の展開に関するガイダンス からアーキテクチャ図をダウンロードしてください。 産業機械のリーダーが AWS IoT を採用 世界中の産業機械メーカーは、AWS IoT および AI マネージドサービスを使用して、AWS やパートナーのエッジ・クラウド機能を活用することで、より良い、より安全な産業用スマート製品を、素早く、構築しています。例えば、これらのメーカーには Amazon Robotics 、Heidelberger Druckmaschinen AG (HEIDELBERG)、Deere、Philips、Kraus Maffei、ENVEA 、Martin Engineering 、KEMPPI 、Techno Brazing 、Pentair などがあります。以下に AWS IoT と連携する 4 つの主要な機械メーカーのハイライトをお読みいただけます。詳細については、それぞれのストーリー全体をお読みください。 KONE はエレベーターとエスカレーター業界のグローバルリーダーで、リモート監視と保守を強化するために KONE のメンテナンスベースにある 160 万台の機器すべてをクラウドに接続するという課題に直面していました。彼らは AWS IoT Core、 AWS IoT Device Management 、 AWS IoT Twin Maker を活用してスケーラブルで信頼性の高い IoT プラットフォームを構築することでこの課題を解決しました。この移行により、KONE は保守対応を 40% 以上削減し、障害の 70% 以上を事前に特定し、ほぼ 100% のプロビジョニング成功率を達成することができました。その結果、KONE はスマートエレベーターとエスカレーターの運用効率を向上させ、コストを削減しました。さらに、より信頼性の高いスマートな都市モビリティソリューションにより、顧客満足度も向上しました。全ストーリー： KONE が AWS IoT を使用して新たな効率化を実現 Frontmatec は食肉産業における主要な機械製造会社です。彼らは予知保全と機械ソリューションのグローバルパフォーマンス管理のための多様なデータストリームの統合とデータのコンテキスト化を確保するという課題に直面していました。 Frontmatec は、 Siemens Industrial Edge プラットフォーム上で AWS IoT SiteWise Edge を活用することで、自社の顧客サービスポータルの開発を加速しました。このポータルでは、機械のグローバルなパフォーマンス管理や予防保守のためのサービスを提供しています。これにより、 Frontmatec は機械の健康状態をリアルタイムに監視し、迅速な運用調整を行えるようになりました。このソリューションにより、デプロイ時間が数時間から１５分に短縮され、効率的な機械健全性モニタリングとリアルタイムの運用調整が可能になりました。その結果、 Frontmatec は、よりスマートで効率的な自動化ソリューションをお客様に提供することで、サービスラインナップを強化することができました。全ストーリー：製造業におけるエッジからクラウドへの統合のパワー： Frontmatec が Siemens と AWS で機械デジタルサービスの価値実現時間を加速する方法 Castrol は船舶、産業、自動車産業向けの潤滑油とサービスを提供する BP の子会社です。 Castrol は使用済みオイル分析 (Used Oil Analysis: UOA) プロセスの改善と自動化という課題に直面していました。このプロセスは従来、時間のかかる手作業で行われ、メンテナンス対応の遅れや古いデータに基づく分析判断につながっていました。解決策は、AWS IoT SiteWise や AWS IoT Core などの AWS IoT サービスを使用して Castrol SmartMonitor を開発し、オイル品質のほぼリアルタイムの監視と分析を可能にすることでした。この実装により、最大 3~8 週間待つ必要がなくなり、データの正確性と準リアルタイムのモニタリングが向上しました。その結果、お客様は操業停止時間、無駄、メンテナンスコストを削減できました。試験期間中には１０万ドルの修繕費用節減にもつながり、早期の問題検知と予防保守によって、操業効率も改善されました。全ストーリー： AWS IoT SiteWise を使用した Castrol SmartMonitor による潤滑剤分析の自動化 Schenck Process Group は B2B の計測・プロセス技術のグローバルマーケットリーダーで、予測的でデータ駆動型の保守サービスを顧客に提供するために、多くの異なるセンサーからの多様で膨大なデータポイントを統合し分析するという課題に直面していました。これらのセンサーは世界中の機械に設置され、しばしば遠隔地に配置されています。 AWS プレミアコンサルティングパートナーのStorm Replyが実装したソリューションでは、 AWS IoT サービスを活用しています。具体的には、エッジ処理には AWS IoT Greengrass を、安全なデバイス管理とデータ取り込みには AWS IoT Core を組み合わせ、スケーラブルで信頼性の高い IoT プラットフォームを構築しました。その結果、Schenck Processは、B2B 顧客向けの機械監視と予防保守の機能を強化することができました。これにより、同社のサービスラインナップと運用効率が向上しました。全ストーリー： Storm Reply が AWS IoT で Schenck Process Group の産業 IoT と予測メンテナンスを実現する方法 AWS は 2024 年 Gartner のグローバル産業用 IoT プラットフォームのマジッククアドラントでリーダーに選出され、産業接続とイノベーションのための最先端ソリューションを示しています。 詳細はこちら。 おわりに まとめると、 AWS IoT および AI のマネージドサービスを活用することで、メーカーは、スマートで効率的かつ安全な産業製品を構築するための革新的なアプローチを実現できます。エッジコンピューティング、データ統合、セキュリティ、運用効率といった共通の課題に対応して、これらのサービスはメーカーが自社の中核的なイノベーションと顧客価値の向上に集中できるようサポートします。 KKONE、Frontmatec、Castrol、Schenck Processなどの実例が示すように、遠隔監視、予防保守、全体的な操業パフォーマンスの大幅な改善し、新しいビジネスモデルや収益源の創出につながっています。これらの技術を取り入れることで、メーカーは市場での競争力を維持し、将来の成長を牽引することができます。 産業運用を変革する準備はできていますか？スマートで効率的、データ駆動型、そして安全な産業製品を構築するための AWS IoT および AI マネージドサービスのパワーを探求してください。機械監視の強化、予測メンテナンスの実装、またはデータ処理の効率化をお考えの場合でも、AWS にはあなたのニーズを満たすソリューションがあります。今日から旅を始めて、業界のリーダーがどのように素晴らしい結果を達成しているかをご覧ください。詳細情報の取得や始め方については、 AWS IoT ポートフォリオのホームページにアクセスしてください。 https://aws.amazon.com/iot/ Dimitrios Spiliopoulos Dimitrios Spiliopoulos は AWS のワールドワイドプリンシパル産業 IoT Go-To-Market (GTM) スペシャリストで、スマート産業機械向けの産業 IoT (IIoT) Go-To-Market 戦略を世界規模で担当しています。彼は LinkedIn のトップボイスであり、産業用 IoT とスマート製造を専門とする著者およびスピーカーとして、グローバルな産業顧客とパートナーと協力しています。彼は AWS で 4 年間、IoT と製造に関連するさまざまな役割を担当してきました。彼は IoT 分野と製造部門での仕事に対して、 Manufacturer.com  の『製造業アドボケートトップ 100 』賞や Onalytica による “Who is who in IoT” など、複数の賞を受賞しています。また、2018 年から IE ビジネススクールで IoT の客員教授を務めています。彼はエッジ、IoT、スマートマシン、デジタルツイン、AI、持続可能性、インダストリー 4.0 に関する洞察を共有することを好んでいます。LinkedIn での彼のフォローや接続は自由に行えます ： https://www.linkedin.com/in/spiliopoulosdimitrios/ Paco Gonzalez Paco Gonzalez はアイルランドを拠点とするシニア IoT ソリューションアーキテクトです。彼は EMEA 地域全体の OEM、産業企業、テレコプロバイダーと協力して、AWS の顧客が安全で回復力のある IoT ソリューションを構築できるよう支援しています。セキュリティに焦点を当て、Paco は IoT インフラストラクチャが脆弱性とサイバー脅威から保護されるよう確保しています。空き時間には、SF ショーを楽しんだり、家族と時間を過ごしたり、天気が許す場合には屋外でグリル料理を楽しんでいます。 Adamu Haruna Adamu Haruna は Amazon Web Services (AWS) のシニアソリューションアーキテクトで、クラウドと IoT ソリューションを専門としています。テレコムシステムと IoT における 20 年以上のエンジニアリング経験を持ち、通信、ヘルスケア、製造、産業 IoT などの業界全体でデジタル変革を推進する重要な役割を果たしてきました。Adamu の専門知識には、技術戦略、クラウドネイティブソリューション、モバイル通信、IoT エコシステムが含まれ、技術的ソリューションとビジネス目標の整合に強い焦点を当てています。Adamu はさまざまな業界での継続的な学習、知識、経験の共有に情熱を持っています。 このブログは “ Building Smart Industrial Machines with AWS: A Comprehensive Guide ” (著者:  Paco Gonzalez, Dimitrios Spiliopoulos, and Adamu Haruna) をAWS Japan SA 吉川 が翻訳し一部サービス・ソリューションのアップデートを追記しました。

AWS にとってセキュリティは最優先事項です。お客様がビジネスを安心して加速できるよう、AWSはセキュリティ対策に取り組んでいますが、お客様側でもセキュリティ対策は必要です。 今回、AWS が開催するセキュリティに特化したカンファレンスである AWS re:Inforce の登録が開始するとともに、 日本語の紹介ページ および AWS re:Inforce 2025 Japan Tour をご案内できることになりましたのでご紹介いたします。 AWS re:Inforce について 「AWS re:Inforce」は、 AWS のセキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに特化したグローバルな学習型カンファレンスです。 AWS セキュリティのエキスパートやパートナーとともに、最先端のセキュリティ情報を短時間で効率的に収集できます。 2025年は、6月16日から18日までの３日間、ペンシルベニア州フィラデルフィアにて開催。最新情報の共有やクラウドセキュリティやコンプライアンスに関する学びの場を提供するとともに、コミュニティのさらなる拡大を図ります。 re:Inforce に参加することで、 AWS のセキュリティサービスとソリューションを使用したクラウドセキュリティの改善方法を、より深く、より包括的に理解することができます。また、 AWS のエキスパートから、より安全なシステムの構築方法を学び、組織のセキュリティ体制を改善するための実用的なソリューションを得ることが可能です。 基調講演 2025年の基調講演では、AWS CISO（最高情報セキュリティ責任者）の Chris Betz が、AWSがどのようにセキュリティを大規模に、かつシンプルに実現しているかを紹介します。お客様の事例やアーキテクチャパターンを通じて、最新の脅威に備え、ビジネスに合わせて拡張できる、本質的なレジリエンシーを高めたアプリケーションを構築する方法をご紹介します。AWS のセキュリティ機能とセキュリティのベストプラクティスを活用し、ビジネスに役立つ強固なセキュリティ戦略を構築する方法を学びましょう。 また、Chris Betz から AWS re:Inforce についてご紹介するブログ “AWS re:Inforce 2025 で始まるセキュアなクラウドイノベーション” も公開されています。併せてご参照ください。 様々なセッション 250 以上のセッションが用意されている AWS re:Inforce は、今日のお客様を取り巻くセキュリティの環境下において、迅速に行動し、対応するために必要な体験型の学習を提供する場であり、AWS のセキュリティソリューション、サービス、機能のみに焦点を当てた唯一のイベントです。お客様の組織が活用するサービスやプロダクトを開発している AWS セキュリティエクスパートから直接学ぶことができます。 公式サイトで公開されている セッション情報 を御覧いただき、ぜひ会場でご参加ください。 フォーカスエリア DevSecOps 開発工程のあらゆる段階にセキュリティを統合することで、セキュアなコーディング、脆弱性管理、CI/CDパイプラインでのセキュリティテスト、自動テスト、サプライチェーンセキュリティツールを使ってソフトウェア開発サイクルを高速化する方法を学ぶことができます。 Culture of security 組織全体にセキュリティを根付かせる方法を探ります。開発者からCxOまで、セキュリティファーストの発想を取り入れる様々な戦略を研究します。セキュリティチャンピオンプログラムを構築・育成し、セキュリティの責任を各チームに分散させながら、包括的な実践とトレーニングによってすべての社員がセキュリティに取り組めるようにする方法を学びます。セキュリティを専門部門の業務から、事業価値を生み出し、イノベーションを後押しする共有課題に転換する実践的な枠組みを習得します。 Generative AI 明確な戦略、現実的なソリューションなど、生成 AI の時代において大切なものを守るための実践的で経験に基づいたセッションをお届けします。企業規模でセキュアなAIシステムを実装した実務者、リーダー、お客様から学び、AIシステムのあらゆる側面にセキュリティを組み込むための、独自の実行可能な戦略を立てる方法を習得します。 Japan Tour とは 日本のお客様が AWS re:Inforce により簡単に参加し、貴重な学習の機会に一層効果的かつ集中していただくことを目的とし、航空券や現地での移動・宿泊、加えて AWS re:Inforce を楽しんでいただくための特別コンテンツをパッケージングした Japan Tour の企画に AWS は協力しています。今回、 AWS re:Inforce 2025 Japan Tour (AWS re:Inforce 2025 日本語ページにてご案内）を旅行会社からご提供できることになりましたので、AWS re:Inforce 2025 に参加する方法の選択肢としてご検討ください。 おわりに 本ブログでは、AWS セキュリティ最大規模のカンファレンスである AWS re:Inforce 2025 および Japan Tour についてご紹介してきました。ご覧いただいた方が、AWS re:Inforce およびセキュリティへの興味・関心を持っていただければ幸いです。 セキュリティは技術者だけではなく経営幹部や監査、またサイバーセキュリティに関連する公共部門の担当者など、多くのみなさまにとっての関心事項となります。このような機会を通じて、安全なサイバー空間の実現を一緒にご支援できれば幸いです。 参考：昨年の AWS re:Inforce 2024 および Japan Tour 開催報告 【開催報告】AWS re:Inforce 2024 および re:Cap イベント この記事は シニア セキュリティ ソリューションアーキテクト勝原達也が担当しました。

本記事は 2025 年 3 月 6 日に公開された “ A lightning fast, new agentic coding experience within the Amazon Q Developer CLI ” を翻訳したものです。 本日、 Amazon Q Developer は Amazon Q コマンドラインインターフェース (CLI) において 強化された CLI エージェント を発表しました。今回の発表により、Q Developer は最新のエージェント型体験を CLI に導入し、より動的でインタラクティブなコーディング環境を提供します。これにより、開発者と対話しながらフィードバックに基づいて変更を加えていくことが可能になります。Amazon Q Developer は、CLI 環境内の情報を活用し、ローカルファイルの読み書き、AWS リソースのクエリ、コードの作成、さらには自動デバッグまで支援できるようになりました。 はじめに 開発者として、私は統合開発環境 (IDE) を活用し、組み込みのリンターやオートコンプリート機能によってワークフローを効率化しています。さらに、Amazon Q Developer のような AI アシスタントの登場により、開発の進め方が大きく変わりました。チャットで Amazon Q Developer にベストプラクティスについて相談したり、複雑なメソッドのリファクタリングを数秒で依頼したりすることができます。最近では、新機能の開発、ドキュメントの作成、ユニットテストの生成、コードレビューの自動化など、Amazon Q Developer のエージェントをますます活用するようになりました。これらの強力なエージェント機能により、日々の開発業務のアプローチがさらに変革されています。 しかし、開発者として、統合開発環境 (IDE) と同じくらい、あるいはそれ以上にコマンドラインインターフェース (CLI) を使用する時間が長いと感じていました。 AWS CLI 、Git、パッケージマネージャー、リンターといったツールは、インフラ管理、反復作業の自動化、チームとのコラボレーションの方法を大きく変革しました。Docker や Kubernetes などのツールは、アプリケーションの開発やデプロイの進め方を大きく変えました。私の IDE の拡張機能タブを見ると、Maven、Docker、Vue の拡張機能をインストールしていますが、ほとんど使用していません。CLI の柔軟性とパワーを優先しているためです。 Amazon Q Developer は、1 年以上前から CLI で利用可能になっており、今では私の日々の開発ルーチンに欠かせない存在になっています。インテリジェントなコマンド補完機能により、Git ブランチや Amazon S3 バケットの一覧を簡単に取得できるため、多くの時間を節約できました。また、チャット機能を使って自然言語で Q Developer と対話し、特定のタスクを実行する方法を学ぶこともできます。さらに、変換機能を利用すれば、シンプルな言葉で入力したプロンプトを対応するシェルコマンドに変換できます。 Amazon Q Developer の CLI 機能は非常に便利ですが、IDE で利用できるエージェントの強力な機能が CLI にはないことが少し残念に感じていました。そんな中、本日、Amazon Q Developer は強化した CLI のエージェントを発表しました。Amazon Bedrock によって強化されたこの新しいエージェントにより、CLI は Claude 3.7 Sonnet の段階的推論機能 を活用できるようになりました。さらに、新しい CLI エージェントは、 システムにインストールされたツール 、例えばコンパイラ、パッケージマネージャー、 AWS CLI などを活用することができます。加えて、強化された CLI は マルチターンの会話 をサポートし、エージェントと動的な対話を行いながら作業を進められるようになりました。これにより、CLI 環境の快適さを損なうことなく、より多くの作業をより速く完了できるようになります。 IDE の機能やワークフローに縛られるのではなく、CLI エージェントを利用することで、作業に必要なツールやコマンドに直接アクセスできます。それでは、具体的な例を見ていきましょう。 ウォークスルー CLI エージェントの機能がどのように動作するのかを確認するために、具体的な例を紹介します。私は、4 月に開催される社内の開発者コミュニティサミットに向けて準備を進めています。このイベントでは、参加者が発表するトピックを提案できる Call for Content アプリケーションが必要になります。このアプリケーションの構築に Amazon Q Developer CLI を活用します。 すでに CLI はインストール済み なので、まず q chat を実行し、新しい会話を開始します。その後、Q Developer に対して、「scaffold a new application named call-for-content using React and Vite, and then commit it to Git.（日本語訳: React と Vite を使用して call-for-content という名前の新しいアプリケーションを初期生成し、それを Git にコミットしてほしい）」 と指示します。以下の動画のとおり、エージェントは私の意図を正しく理解し、アプリケーションの構築に必要な処理を実行します。これまでの Q Developer CLI は、私が実行すべき手順を提示する形で支援していました。しかし、この新しく強化されたバージョンでは、CLI エージェントが私のローカル環境にインストールされているツールを活用し、各ステップを自動で実行してくれます。 なお、私は確認プロンプトを無効にしていますが、Q Developer は各アクションの前に確認を求めるよう設定できます。 エージェントは動画内で非常に高速に動作しており、そのスピードについていくのが難しいほどです。そこで、以下の画像で各ステップを詳細に分解しました。エージェントはまず npm create を実行し、新しいアプリケーションを作成します。次に、 npm install を実行して、すべての依存関係を追加します。その後、一連の git コマンドを実行し、新しいリポジトリを作成し、ファイルを追加し、説明付きのコミットメッセージとともに変更をコミットします。 エージェントは単にファイルを生成しているわけではなく、私自身が実行するであろうコマンドをそのまま実行しています。しかし、CLI エージェントは私が手動で行うよりもはるかに速く、正確に処理を進めています。強化された Amazon Q Developer CLI は、システムにインストールされている他のコマンドラインツールを活用しながら作業を完了させます。Q Developer の処理が完了すると、実行した作業の概要を提供し、次のステップを提案してくれます。以下の画像では、Q Developer が開発サーバーを起動して変更をプレビューするよう推奨していることがわかります。これは非常に適切な提案なので、Q Developer に開発サーバーを起動するよう依頼し、正常に動作しているかを確認します。 アプリケーションのテンプレートが実行され、Call for Content アプリケーションの開発を開始する準備が整いました。CLI エージェントはマルチターンの会話をサポートしているため、前回の続きから作業を再開できます。コマンドライン上で要件を説明するだけで、エージェントがコードの生成を開始します。これはまさに Amazon Q Developer の最も得意なことです。この例では、エージェントが App.jsx と App.css ファイルを更新する必要があります。 エージェントは、前の例で見たようにコマンドを実行するだけでなく、ローカルシステム上のファイルを読み書きできることに注目してください。そのため、Q Developer がコードを生成すると、エージェントはそれを適切な場所に配置します。処理が完了すると、エージェントは npm run dev を実行して開発サーバーを起動します。前回、私がサーバーの起動を指示したので、今回も進捗を確認するだろうと正しく推測しました。前回のように、エージェントは行った変更の概要を提示してくれます。個人的に、この定期的なサマリーは非常にありがたく、Q Developer の作業に対する信頼感を高めるのに役立っています。表示結果を見ましたが、タイトルの色が気に入りません。Q Developer に変更を依頼することもできますが、今回は自分で直接ファイルを編集することにします。CLI を使用している間も手動でファイルを編集できる点は重要です。エージェントは編集を加える前にファイルを読み取り、手動での変更があるかを確認してくれます。 アプリケーションは素晴らしい仕上がりです！しかし、現在の出力はコンソールに書き出されるだけで、データの処理方法についてエージェントに指示していませんでした。アプリケーションの出力を DynamoDB テーブルに書き込むようにしたいと思います。実はすでにテーブルを作成済みなのですが、どのリージョンにあるのか思い出せません。 以下の画像では、エージェントに テーブルのリージョンを特定するよう依頼しています。どのように応答するのか見てみましょう。 前の画像でわかるように、エージェントは私の曖昧なリクエストを理解し、適切な対応を行いました。まず us-east-1 でテーブルを探し、見つからなかったため us-west-2 へ移動し、再試行しました。テーブルは us-west-2 にありましたが、もしそこにもなければ、エージェントはさらに検索を続けていたでしょう。Q Developer は AWS のリソースをリストアップし、詳細を取得する方法を理解しています。一度テーブルを見つけたら、エージェントは npm を使用して DynamoDB SDK をインストールし、アプリケーションのファイルを更新しました。実際には複数のファイルが変更されましたが、画像ではシンプルにまとめています。 いくつかの簡単なプロンプトを入力するだけで、強化された CLI エージェントを活用し、Q Developer と協力しながら開発プロセス全体を進めることができました。今後は認証の追加など、さらなる機能拡張を行う予定ですが、Q Developer CLI の使い方は十分に理解できたと思います。それでは、ここで一区切りとしましょう。 まとめ Amazon Q Developer の新しい CLI エージェントは、私のソフトウェア開発のアプローチを完全に変革しました。高度な AI アシスタントのパワーが、普段使い慣れたコマンドライン環境に直接統合されたことで、これまで以上に素早く複雑なタスクをこなせるようになりました。Q Developer の自然言語理解とコンテキスト認識、CLI エージェントの推論能力と多様な開発ツールの活用が組み合わさることで、日々のワークフローに欠かせない存在になっています。最後に、マルチターンの会話機能により、エージェントと協力しながら作業を進めることで、より多くのタスクを素早く完了できます。 もしあなたが CLI を頻繁に使用する開発者ならば、Amazon Q Developer の CLI エージェントをぜひ試してみてください。 Amazon Q Developer ユーザーガイド を参考に、CLI をインストールし、新しいエージェント機能を無料ですぐに活用できます。きっと、私と同じように開発スタイルが大きく変わるはずです。ぜひ試してみて、感想を聞かせてください！ 翻訳はApp Dev Consultantの宇賀神が担当しました。

優れたレジリエンス戦略には、高可用性での運用とビジネス継続性の計画が不可欠です。また、地震や洪水などの自然災害、停電やネットワーク接続の障害などの技術的な障害の発生の考慮も必要です。AWS は、高可用性にはマルチ AZ 戦略を、ディザスタリカバリにはマルチリージョン戦略を 推奨しています 。このブログでは、米国を拠点とする保険会社であるお客様の事例を通じて、クラウドネイティブサービスを使用して 3 層アプリケーションのディザスタリカバリを実装する方法を説明します。 この保険会社では、かなりの数の重要なアプリケーションが 3 層構造の Java または .Net アプリケーションです。これらのアプリケーションは、 Amazon EC2 インスタンス 上で動作する IBM Db2、Oracle、または Microsoft SQLServer データベースへのアクセスを必要とします。要件は、 パイロットライトまたはウォームスタンバイシナリオ を実装するディザスタリカバリ戦略を作成することでした。この設計はコストを最小限に抑え、障害検知とリソースの手動フェイルオーバーを可能にする必要があります。さらに、目標復旧時間 (RTO) と目標復旧時点 (RPO) を 15 分以内に抑える必要があります。最後に、このソリューションではインターネット上のリソースを利用できず、すべてプライベートネットワーク内に構築する必要がありました。 ソリューション Amazon Application Recovery Controller  は、複数の AWS リージョンやオンプレミス環境にまたがるアプリケーションのフェイルオーバーとリカバリの管理とオーケストレーションを支援します。これは主にフェイルオーバーとリカバリ操作中の DNS ルーティングとトラフィック管理に焦点を当てていますが、一部のお客様はアプリケーション復旧のために独自の戦略を実装しています。このブログでは、ある金融サービスのお客様がどのように実装しているかを見ていきます。 Well-Architected フレームワーク では、優れたディザスタリカバリ計画には構成ドリフトを管理する必要があると説明しています。両方のリージョンにデリバリーパイプラインを使用してデプロイし、定期的にリカバリパターンをテストすることがベストプラクティスです。さらに一歩進んで、一定期間セカンダリリージョンで運用することを選択するお客様もいます。 当社の大手保険会社のお客様が選択したソリューションには、フェイルオーバーとフェイルバックという 2 つの異なるシナリオが含まれています。フェイルオーバーシナリオでは、プライマリリージョンからセカンダリリージョンへアプリケーションをフェイルオーバーするための一連のステップを網羅しています。フェイルバックプロセスは、運用をプライマリリージョンへ戻す処理です。 フェイルオーバー お客様はパイロットライトシナリオのテストを実施することを決定しました。このシナリオでは、プライマリリージョンとセカンダリリージョンの両方にアプリケーションとデータベースをデプロイすることを前提としています。 15 分の RPO を達成するための要件として、プライマリリージョンにデプロイされたアプリケーションは、セカンダリリージョンにデータをレプリケーションする必要があります。この非同期レプリケーションは、データベース固有のツールを使用して、企業の各データベースエンジン (Db2、SQLServer、Oracle) に実装されています。各データベース独自のツールの活用は以前から行っていたやり方であり、これを採用することで運用上の影響を最小限に抑えることができます。 障害検出とフェイルオーバーの仕組みがセカンダリリージョンに作成されることは重要なポイントです。これにより、プライマリリージョンが利用できなくなった場合でも、これらのコンポーネントは利用可能な状態を維持できます。もう 1 つの重要な点は、2 つのネットワーク間の接続を確立することです。これは、データベースのレプリケーションを可能にするために必要です。 図 1. アプリケーションサーバーとデータベースを 2 つのリージョンにデプロイした 3 層アプリケーションのパイロットライトシナリオ 障害検出とフェイルオーバーは、以下の手順で実行されます。 Amazon EventBridge スケジューラーが 60 秒ごとに AWS Lambda 関数を実行します。 Lambda 関数はアプリケーションのエンドポイントをテストし、 Amazon CloudWatch にカスタムメトリクスを追加します。アプリケーションが利用できない場合、CloudWatch アラームがフェイルオーバーを開始する Lambda 関数を起動します。 Lambda 関数は Jenkins パイプラインを起動してフェイルオーバーを開始します。このパイプラインは、アプリケーションとデータベースをセカンダリリージョンにフェイルオーバーします。Jenkins パイプラインは手動承認ステップから開始され、フェイルオーバープロセスが自動的に開始されないようにします。 承認者がフェイルオーバーの必要性を確認した後、ワークフローを承認し、パイプラインは次のステージに進みます。 パイプラインはデータベースをフェイルオーバーし、セカンダリリージョンのデータベースをプライマリ状態に昇格させ、書き込み操作を有効にします。 次に、EC2 インスタンスまたはコンテナで実行されているアプリケーションサーバーを起動またはスケールアウトします。これは、フェイルオーバー完了後にセカンダリリージョンで増加した負荷に対応できるようにするために重要です。 この時点で、データベースとアプリケーションサーバーは負荷を受け入れる準備ができています。次に、Application Load Balancer (ALB) をセカンダリリージョンにフェイルオーバーする必要があります。Route 53 フェイルオーバールーティングポリシーは自動的にリージョン間でフェイルオーバーしますが、このお客様はヘルスチェックを使用してこのステップを手動で制御したいと考えていました。ALB の手動フェイルオーバーを実装するために、パイプラインは指定の S3 バケットにファイルを作成します。Lambda 関数は定期的にこのファイルが所定の場所に存在するかを確認します。ファイルが存在する場合、CloudWatch アラームをトリガーし、Route 53 ヘルスチェックが失敗します。この時点で、Route 53 はトラフィックをセカンダリリージョンの ALB にリダイレクトし、これが新しいアクティブエンドポイントとなります。 フェイルバック フェイルバックシナリオは、プライマリリージョンで必要なすべてのサービスがオンラインになったときに開始されます。サービスの状態を確認するには、AWS Personal Health Dashboard を使用することをお勧めします。図 2 は、フェイルバックプロセスの詳細を示しています。フェイルバック手順の開始から最終的な DNS の切り替えまでの詳細な手順を示し、各段階で重要な構成要素とその連携を強調しています。この視覚的な表現により、プライマリリージョンへの運用復帰という複雑なプロセスが明確になります。 図 2. フェイルバックプロセスの図 フェイルバック手順は、以下の 6 つのステップで実装されます。 クラウドオペレーターまたは Site Reliability Engineer (SRE) が HTML ページのフォームを送信することでフェイルバック手順を開始します。Lambda 関数が Jenkins パイプラインを起動します。 パイプラインはデータベースの差分同期レプリケーションを開始します。これにより、セカンダリリージョンで行われたデータ変更がプライマリリージョンにレプリケートされます。 次のステージは、プライマリリージョンへの復旧のための手動承認ステージとなり、SRE はデータベースが同期されていること、および必要なすべてのサービスがプライマリリージョンでオンラインになっていることを確認します。 承認後、パイプラインはプライマリリージョンでアプリケーションサーバーを起動します。 次に、プライマリリージョンのデータベースが書き込み操作のために昇格されます。セカンダリリージョンのデータベースエンドポイントが、プライマリリージョンのデータベースを指すように更新されます。 フェイルオーバーセクションで説明したように、DNS の切り替えは S3 に存在するファイルに依存します。このファイルはフェイルオーバーイベントのために作成されたため、パイプラインはここでこのファイルを削除します。Lambda 関数が変更を検知して CloudWatch アラームの状態を更新し、Route 53 ヘルスチェックが状態を変更します。この時点で、プライマリリージョンの ALB がアクティブになり、フェイルバックが正常に完了します。 利点 このお客様は、この設計を実装することで以下の利点を見出しました。 会社の内部プロセス、運用モデル、使用中の技術に合わせてカスタマイズ可能なソリューション データベース、EC2 上で実行される Windows および Linux アプリケーションなど、異なる技術を使用するアプリケーションに対して、組織全体で適用可能な標準化されたパターン 15 分未満の目標復旧時点 (RPO) と目標復旧時間 (RTO) 障害検知とフェイルオーバーシナリオを実装するためにクラウドネイティブサービスを使用したコスト最適化ソリューション まとめ 3 層アプリケーションのディザスタリカバリソリューションは、この金融サービス企業のビジネス継続性とレジリエンスに対する取り組みを示しています。このアーキテクチャ設計は、企業が特定の要件に合わせてアーキテクチャをカスタマイズできることを示しています。重要なアプリケーションの RPO と RTO を 15 分未満に抑えることは、素晴らしい成果です。これにより、リージョン障害時のビジネスオペレーションの中断を最小限に抑えることができます。 さらに、このソリューションは企業内の既存の技術とプロセスを活用しており、組織全体でシームレスな統合と導入を可能にします。様々な技術を使用するアプリケーションに対してこのパターンを標準化できることで、運用の効率化と負担軽減に役立ちます。 もしあなたが重要なアプリケーションの回復性を向上させたいとお考えの場合、当社のお客様によるディザスタリカバリソリューションは参考になる事例です。AWS でのディザスタリカバリ戦略とベストプラクティスについて、さらに詳しく知りたい場合は、以下のリソースをご覧ください。 Disaster Recovery of Workloads on AWS: Recovery in the Cloud : AWS におけるディザスタリカバリの概念と戦略について包括的な概要を提供します。 Creating a Multi-Region Application with AWS Services : 3 部構成のブログ記事で、耐障害性を向上させるために複数の AWS リージョンにまたがるアプリケーションの設計に関する洞察を提供します。 AWS Well-Architected Framework – Reliability Pillar : AWS 上で信頼性が高く耐障害性の高いシステムを構築するためのベストプラクティスについて説明します。 Disaster Recovery Architectures on AWS : さまざまなディザスタリカバリシナリオのリファレンスアーキテクチャを集めた 4 部構成のブログ記事です。   Amit Narang AWS シニアソリューションアーキテクトとして、Amit Narang はお客様が Well-Architected なソリューションを設計・運用できるよう支援する役割を担っています。テクノロジーへの情熱に突き動かされ、彼の仕事はAWSクラウドの可能性を最大限に活用したソリューションの構築と実装をお客様がスムーズに行えるようサポートすることです。 Luiz Decaro Luiz は Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトです。金融サービス業界のお客様がクラウドで成功するための支援に注力しています。Luiz はソフトウェアエンジニアリングの修士号を持ち、2005 年に初めての継続的デプロイメントパイプラインを立ち上げました。 翻訳はソリューションアーキテクト 渡部 拓実 が担当しました。原文は こちら です。