こんにちは、AWS ソリューションアーキテクトの梅田です。 2024年 05 月 29 日に 「生成 AI で教育を加速 ! 最新トレンドと実践ガイド」 というタイトルでウェビナーを開催しました。 開催報告として、ウェビナーの内容と当日の収録映像を紹介します。 開催の背景 生成AIが普及し始めて1年以上が経過し、さまざまな業界で活用事例が出てきました。教育分野においては、「どのように活用したらよいかわからない」「導入を検討しているがハードルが高い」という声を聞くことも増えました。 本ウェビナーでは、以下の2点を中心にご紹介しました。 AWSが提供する生成AI の最新アップデート情報 クラスメソッド社のクラウドソリューション導入・運用サポートサービス EdTech企業様や教育機関様がお抱えの課題に対し、生成AIの活用方法や、クラウド基盤の構築・運用をデモを交えながらワンストップでお応えする内容となっていました。 セミナー内容紹介 / 収録録画 タイトル : 生成 AI で教育を加速 ! 最新トレンドと実践ガイド 開催日 : 2024 年 05 月 29 日 (水) 動画視聴は こちら 資料は こちら Amazon Bedrock で Claude 3 を使いこなそう！(アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 技術統括本部 シニアソリューションアーキテクト　松井佑馬) Amazon Bedrock で Claude 3 を使いこなそう！ このセッションでは、高速で高性能な注目の最新基盤モデルである Anthropic 社の Claude 3 を、AWS の生成 AI サービスである Amazon Bedrock で使いこなす方法として、 Amazon Bedrock および Claude の特徴やユースケース、セキュリティ、プロンプトエンジニアリングなどを紹介しました。 まずセッションの初めに、教育分野におけるAIの活用について説明しました。まず、教育のDXを加速するため、個別最適な学びと協働的な学びの実現、および先生の働き方改革を実現することを課題としました。そこで、生成AIを活用することで、これらの課題解決を加速できると考えています。 続いて、 Amazon Bedrock では、様々な基盤モデルを単一のAPIで利用できること、セキュリティとプライバシーにも配慮されていることを説明しました。 そして Amazon Bedrock の基盤モデルの中でも Anthropic 社の Claude 3 について紹介しました。 Claude 3 には 3 つのモデル (Opus、Sonnet、Haiku) があり、精度・速度・コストに応じて選択できること、また特徴としてHaikuの高速性やマルチモーダル対応を挙げました。最後により望ましい結果を得るためのプロンプトの工夫 (プロンプトエンジニアリング) について説明しました。 これらの情報が生成AIの教育でのユースケースを検討したり、実際に Amazon Bedrock で生成AIを使い始めたりする際の参考になれば幸いです。 (参考情報) 公共機関における生成 AI の活用案 Generative AI Use Cases JP – すぐに業務活用できるビジネスユースケース集付きの安全な生成AIアプリ実装 生成AIをお客様のアプリに組み込む(アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 技術統括本部 ソリューションアーキテクト　梅田昌太) 生成AIをお客様のアプリに組み込む このセッションでは、以下のトピックが取り上げられました 生成AIをお客様アプリへ組み込むヒント RAG(Retrieved Augmented Generation) というアプローチ Knowledge bases for Amazon Bedrock の紹介 RAG というアプローチを通して生成AIをどのようにお客様のアプリケーションに組み込むかについて説明しています。 RAG(Retrieved Augmented Generation)とは RAGは、Retrieve(検索)とGeneration(生成)の2つのステージを組み合わせるアプローチです。外部データを元に作成されたナレッジベースから質問に関連する情報を検索し、その情報と入力クエリを組み合わせて高品質な回答を生成します。 このアプローチにより、生成AIの「幻覚(hallucination)」問題を抑制し、回答の精度と一貫性を向上させることができます。AWSでは Knowledge bases for Amazon Bedrock を用いることで、 簡単にRAGが実装できることを紹介しています。 また、実際にお客様のアプリケーションへ生成AIを組み込むためには、生成AI機能だけでなく、アプリケーションを実行する基盤やデータの蓄積、収集の重要性についても触れられています。 AWSはすでにご利用いただいてるお客様にも、これからご利用いただくお客様にも、簡単にRAGを試せる環境があります。是非RAGを試して回答の品質を高められるか検証してみてください。 生成AIの信頼性を上げてビジネスを加速させるためのデータ活用術（クラスメソッド株式会社 新規事業部 ソリューションセールス 熊谷 敏宏 氏） 生成AIの信頼性を上げてビジネスを加速させるためのデータ活用 本セミナーでは、企業における生成AIの活用方法を、データ活用という視点から解説しています。 まず、企業が持つデータの90%が非構造化データであると指摘し、これらの活用が競争優位性につながる可能性に言及していて、非構造化データの活用が、生成AIの登場により加速度的に進み、業務効率化・意思決定の質向上・顧客理解の深化といったメリットをもたらすことを紹介しています。 生成AI活用の具体的な手法として、RAG（Retrieval-Augmented Generation）が紹介されています。 RAGは、大規模言語モデル（LLM）に追加情報を与えて回答を生成する方法で、自社データを活用した独自のAIシステムを構築できます。 しかし、RAGの実装には幾つかの課題があることも指摘されています。 例えば、CSVファイルの途中が抽出されてしまう問題や、似たようなドキュメントの内容が混同される問題などです。 これらの課題に対して、ファイルの分割やタグ付け・フィルタリングなどの具体的な解決策が提案されています。 最後に、クラスメソッド社が提供する「らくらくRAG導入パック」というサービスが紹介されています。 このサービスは、企業が短期間で自社データを活用したAIチャットボットを導入できるソリューションです。 セミナー資料全体を通して、生成AIの活用が企業の非構造化データ活用の敷居を下げ、ビジネス課題解決に大きな可能性をもたらすことが強調されています。 同時に、効果的な活用のためにはデータの前処理や加工が重要であることも指摘されており、企業が生成AIを導入する際の具体的なポイントが示されています。 おわりに 本セミナーの内容が、生成AI導入の一助になれば幸いです。 AWSの活用やご提案に関するご相談、ご要望がありましたら、担当営業、もしくは公式サイトの お問い合わせ までお問い合わせください。 このブログは、2024 年 06 月 18 日時点の情報に基づいてソリューションアーキテクト 梅田が執筆いたしました。

本ブログは株式会社サルソニード様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの小林大樹です。 昨今、生成 AI を活用して業務効率化を図るお客様が増えています。特に、大量のテキストデータを扱うマーケティング業務では、記事作成や校正、リライトなどのタスクを生成 AI に任せることで、人的リソースを削減し、本来のマーケティング活動に注力できるようになってきました。 今回は、Web マーケティングのワンストップソリューションを提供されている 株式会社サルソニード様 が、 Amazon Bedrock と Amazon Kendra を活用して法律関連オウンドメディアの記事作成を効率化し、記事のリライト業務にかける時間を 70 % 削減された事例をご紹介します。 お客様の状況と検証に至る経緯 サルソニード様のマーケーターはマーケティング業務だけでなく、記事執筆業務や WEB サイト制作業務も一貫して担当しています。業務拡大にマーケティングチームの増員が追いつかず、マーケティングチームのリソース不足が続いていました。 そこで、生成 AI を活用した業務効率化基盤の構築を検討していましたが、1名のエンジニアのみで社内システムや複数の自社サービスの開発・運用を担当していたため、生成AIの環境構築に充分なリソースを割くことが困難な状況でした。その一方で、機微情報を扱っていることから、社員の方々が外部の生成 AI ツールを各々契約して勝手に利用する、いわゆるシャドー IT を防ぐためにも喫緊の対応が必要となっていました。 こうした課題を解決するため、Amazon Bedrock と Amazon Kendra を活用した RAG（検索拡張生成; Retrieval Augmented Generation) チャット環境を社内マーケター向けに提供し、記事のリライト業務を生成AIによってサポートする取り組みを始めました。 ソリューション／構成内容 環境構築にあまりリソースを割けない状況の中、セキュリティを担保した生成 AI 環境を構築するために、AWS が OSS (オープンソースソフトウェア) として提供している「 GenU (Generative AI Use Cases JP) 」を活用しました。GenU は以下のようなアーキテクチャで構成されており、生成 AI を用いたチャットボットや、要約や文章構成、画像生成など様々なユースケースを体験することができるアプリケーションとなっております。また、上記のユースケースに加え、RAG による社内情報に基づいた AI チャットボットなども利用することができます。 RAG について少し補足します。RAG では、ユーザーが知りたい内容に対してまず Amazon Kendara に対して検索を行い、得られた検索結果を参考情報として生成 AI が回答を生成します。RAG を利用することで、生成 AI モデルが知らない社内のマニュアルや規定といった情報についても回答を生成することができます。Amazon Kendra は Amazon S3 やウェブサイトなど、複数のデータソースからデータを簡単に取り込み、検索に適したインデックスを作成してくれます。今回の実装では、社内の過去の記事データやマニュアル類を Amazon Kendra に同期するために ECS Scheduled Task を利用し、以下のような処理を定期実行するジョブを作成しています。 ECS Scheduled Task でジョブを実行 1-1. 自社プロダクトのDB (Amazon Aurora PostgreSQL) から対象データを抽出 1-2. データをプレーンテキストに整形 1-3. AWS SDK で S3 にアップロード 1-4. Amazon Kendra の S3 Connector を利用してインデックスを同期 上記の実装を行うことで、自社 DB やその他のデータソースから検索対象データを柔軟に抽出し、RAG のデータソースとして利用することが可能となっています。加えて、GenU では生成 AI ツールを社内展開する際に便利な以下の機能を備えています。 Amazon Cognito を利用したユーザー認証機能 AWS WAF を利用した IP 制限等のアクセス制御機能 サルソニード様では、社内に生成 AI ツールを展開するにあたって、セキュリティを確保するために上記機能を有効化していただき、ユーザー認証やアクセス制限機能を備えたセキュアな環境を短期間で構築することができました。このように、GenU を利用することで、簡単かつ迅速に環境構築を行うことができたため、1 名のエンジニアがわずか 2 日で環境構築から社内リリースを行うことができました。 導入効果 前述の通り、サルソニード様は GenU を活用した生成 AI ツールを社内ユーザー向けにリリースされました。具体的には、Web メディア記事の制作や校正に Amazon Bedrock から利用可能なモデルを使った通常の生成 AI チャットを利用し、社内情報や専門知識が必要なマーケターの質問への回答には Amazon Bedrock と Amazon Kendra を組み合わせた RAG チャットを利用しています。この生成 AI ツールの導入により、サルソニード様では以下のような効果が得られました。 記事のリライト業務にかける時間を70%削減でき、マーケターはマーケティング業務に集中できるようになった 会社公認の生成 AI ツールを使える環境を GenU で提供することで、生成 AI のシャドー IT 利用の防止につながり、AWS 内で稼働する環境のため、情報漏洩のリスクもコントロールできるようになった 今回は「マーケターの記事執筆業務の効率化」という切り口で導入いただきましたが、「従業員が利用できるセキュアな生成 AI ツールを会社として提供したい」といったお客様や、「社内の知見と生成 AI を組み合わせて利用したい」というお客様にもおすすめできるソリューションとなっています。 まとめ 今回は、Amazon Bedrock と Amazon Kendra を活用した生成 AI ツールを活用し、記事執筆業務を効率化する、というサルソニード様の挑戦についてご紹介いたしました。 生成 AI は単体でも便利なツールですが、今回のように社内の過去の知見やマニュアル、規定類といった情報と、生成AIを組み合わせることで、業務効率化を実現しているお客様も多くいらっしゃいます。 セキュアかつプライバシー保護されたソリューションを簡単に構築・運用できる GenU を利用して、生成AIの社内活用を推進してみるのはいかがでしょうか。 AWS を利用した生成 AI の活用にご興味をお持ちのお客様は、お気軽にご相談いただければと思います。 ソリューションアーキテクト 小林 大樹 (X – @kobayasd )

本記事は、以下 4 名による共著です。 株式会社オルツ 経営管理部 技術本部付アシスタント 高橋 亜美 株式会社オルツ AI Solutions 事業部 PoC エンジニア 竹内 慎修 株式会社オルツ 経営企画部 マネージャー 西澤 美紗子 アマゾン ウェブ サービス ジャパン合同会社 機械学習パートナーソリューションアーキテクト 本橋 和貴 大規模パラメータを持つ大規模言語モデル (LLM) によるビジネスの変革が期待される一方で、その利用には膨大な計算リソースとエネルギーを必要とするため、環境に対する負荷の増大が懸念されています。そのため、軽量でありながら大規模モデルと同等の精度を実現するための小規模パラメータモデルの研究が活発化しています。その流れで、 P.A.I.®️ (パーソナル人工知能) をはじめ、AI クローン技術でつくり出すパーソナル AI の開発および実用化を行う 株式会社オルツ は、軽量型大規模言語モデル LHTM-OPT (ラートム・オプト) を 2023 年 10 月にリリースしました。また、LHTM-OPT は、2024 年 3 月に、 AWS Marketplace 上における世界初の日本語 LLM として公開されました。AWS Marketplace からモデルを購入することで、利用者は大規模言語モデルや機械学習の専門知識がなくても、簡単に LHTM-OPT を活用したアプリケーションやサービスを構築できます。 以下では、AWS Marketplace に出品されている LHTM-OPT を Amazon SageMaker にデプロイして推論を実行する方法を紹介します。 LHTM-OPT とは LHTM-OPT (ラートム・オプト) とは、オルツが開発した、日本語専用のプライベートな軽量型大規模言語モデルです。LHTM-OPT はオープンデータの学習だけでなく、オルツの独自の指示データや対話データのデータセットも利用し、高い回答精度を達成しています。2023 年 10 月のリリース以降、日本国内の様々なアプリケーションで利用されています。パラメータ数が最適化された LLM であるため、小規模 GPU マシンでも高速の推論、回答生成が可能です。 2023 年 10 月にリリースした時点では、 alt Developer API 利用とオンプレミスの場合のみデプロイが可能でした。今回、 AWS Marketplace に公開 することにより、AWS の機械学習開発運用プラットフォームである Amazon SageMaker に簡単にデプロイできるようになりました。 本記事では 7B パラメータの LHTM-OPT バージョン 1.0 について解説します。このモデルは、2023 年 10 月リリース時点では、日本語 LLM を評価する Rakuda ベンチマークにおいて、日本語商用プライベート LLM として最高性能を記録しました。また、日本語言語理解ベンチマーク「 JGLUE (Japanese General Language Understanding Evaluation) 」の 8 タスク平均においても、商用モデルとして国内最高スコア 56.12 を記録しました (LHTM-OPT の JGLUE 主要 4 タスク平均のスコアは 75.08 です)。これは同じサイズの競合モデルに比べて高い数値となっています。 AWS Marketplace とは AWS Marketplace は、アマゾン ウェブ サービス (AWS) 上で動作する多種多様なサードパーティ製ソフトウェア、データ、サービスを見つけ、購入し、デプロイ、管理するためのデジタルカタログです。セキュリティ、ネットワーキング、ストレージ、機械学習、IoT、ビジネスインテリジェンス、データベース、DevOps など、幅広いカテゴリーの製品が掲載されています。ユーザーは AMI (Amazon Machine Image) や SaaS など様々な形式で提供される製品を選択し、数回のクリックでこれらのソリューションを簡単に起動できます。無料トライアル、時間単位、月単位、年単位、複数年、ライセンス持ち込み (BYOL) モデルなど、柔軟な料金オプションもあり、すべて AWS のひとつの請求書で一括して支払いができます。AWS Marketplace を利用することで、ビジネスソリューションの構築や運用に必要なソフトウェアの調達にかかる時間と手間を大幅に削減できます。 AWS Marketplace には機械学習製品も豊富に取り揃えられています。すぐ利用できる事前学習済みモデルパッケージや、独自のデータセットを用いてファインチューニング可能なアルゴリズムといった機械学習ソリューションが提供されており、機械学習の専門知識がなくても、簡単に機械学習を活用したアプリケーションやサービスを構築できます。画像認識、自然言語処理、予測分析、異常検知などの機能を持つ製品が用意されており、ユーザーは自社のビジネスニーズに合わせてそれらを選択し、Amazon SageMaker 上でモデルを学習、デプロイすることができます。近年では LLM の出品も増えており、AWS Marketplace の機械学習製品を活用することで、機械学習の導入にかかる時間とコストを大幅に削減でき、迅速にインテリジェントなアプリケーションを構築できるようになります。 AWS Marketplace で LHTM-OPT をサブスクライブする AWS Marketplace に掲載されている LHTM-OPT を利用するには、初めに製品をサブスクライブします。 LHTM-OPT の製品ページ から製品の特徴などを確認した上で、サブスクライブしていきましょう。例えば、料金情報欄は以下の通りです。 図 1 : AWS Marketplace における LHTM-OPT の料金情報 AWS Marketplace の機械学習モデルパッケージ製品の料金欄にはソフトウェア料金 (Software Pricing) とインフラ料金 (Infrasstructure Pricing) が記載されています。LHTM-OPT は時間課金の料金設定になっており、ソフトウェア自体の料金としては 1 時間あたり 1.20 USD でご利用いただけます。それだけでなく、推論を実行する基盤としての SageMaker の利用料金もかかる点にはご注意ください。 料金などが確認できたら製品をサブスクライブしていきましょう。 LHTM-OPT を利用する AWS アカウントにログインする。 LHTM-OPT の製品ページ を開き、右上の「Continue to Sucscribe」ボタンをクリックする。 図 2 : LHTM-OPT の製品ページからサブスクライブに進む 料金や EULA (End User License Agreement) を確認し、「Accept offer」ボタンをクリックする。 図 3 : 料金や EULA の確認 サブスクライブが完了したら “Thank you for subscribing. You can now use your product” と表示されます。これで製品を利用する準備ができました。次に、「Continue to configuration」ボタンをクリックし、お客様の AWS 環境内に LHTM-OPT をデプロイしていきます。 LHTM-OPT のサブスクライブが完了した様子 サブスクライブした LHTM-OPT のデプロイ 「Continue to configuration」ボタンをクリックすると Configure and launch ページが開きます。ここでは、「Avalidable launch methods」に「SageMaker console」を指定します。「Region」では、デプロイ対象のリージョンを選択します。ここでは「Asia Pacific (Tokyo)」を選択しています。「Amazon SageMaker options」ではリアルタイム推論エンドポイントを作成するか、バッチ変換ジョブを実行するか選択できます。ここでは「Create a real-time inference endpoint」を選択しています。また、以降のコード内で使用するので、「Product Arn」をコピーし、メモしておいてください。 図 5 : Amazon SageMaker におけるデプロイオプションの指定 このまま GUI ベースでデプロイを進めることもできますが、以降では Python コードでモデルをデプロイする手順を紹介します。 まず、上記の製品の ARN (Amazon Resource Name) を変数に格納します。合わせて、必要なモジュールや SageMaker ランタイムのクライアントなどをセットアップします。 import json import boto3 import sagemaker from sagemaker import ModelPackage, get_execution_role role = get_execution_role() region = “ap-northeast-1” sagemaker_session = sagemaker.Session() sagemaker_runtime = boto3.client("runtime.sagemaker", region_name=region) model_package_arn = ( "<コピーした ARN に置き換えてください>" ) 次に、モデルのデプロイと推論エンドポイントの作成をします。デプロイするモデル名と SageMaker インスタンスタイプは必要に応じて変更することができます。ただし、インスタンスタイプは こちらの製品ページ で推奨しているインスタンスタイプ一覧から選ぶ必要があります。 推論エンドポイントを作成するために 10 分ほど待ちます。 model_name = "lhtmopt" real_time_inference_instance_type = "ml.p3.2xlarge" # Create a deployable model from the model package. model = ModelPackage( role=role, model_package_arn=model_package_arn, sagemaker_session=sagemaker_session, ) # Deploy the model predictor = model.deploy( initial_instance_count=1, instance_type=real_time_inference_instance_type, endpoint_name=model_name, ) モデルのデプロイが終わるとリアルタイム推論エンドポイントの利用準備が完了し、推論を実行できるようになります。 LHTM-OPT で推論を実行する LHTM-OPT で推論を実行する際、インプットは以下の 3 つの形式で渡すことができます。 方法 1 : デフォルトパラメータと質問 これは最もシンプルな形式です。ペイロードには質問を含むプロンプトのみを渡します。推論パラメータはデフォルトで設定されているものが利用されます。 payload = { "prompt": "質問：世界で最も高い山はなんですか？\n答え：", } 方法 2 : 推論パラメータと質問 推論パラメータは任意の値を設定することもできます。ペイロードに推論パラメータのキーと値を含めることでパラメータをセットし、アウトプットをコントロールすることができます。 payload = { "prompt": "質問：世界で最も高い山はなんですか？\n答え：", "max_new_tokens": 50, "temperature": 0.7, "top_k": 40, "top_p": 0.9, "do_sample": True, "repetition_penalty": 1.2, "skip_prompt": True, } 方法 3 : Llama 2 テンプレートでインプット プロンプトは Llama 2 テンプレートの形式に構造化することも可能です。これにより、システムプロンプトを明示的に指定することができます。 payload = { "prompt": """[INST] <<SYS>> あなたは優秀な日本人のアシスタントです。 <</SYS>> 世界で最も高い山はなんですか？ [/INST]""", "temperature": 0.7, “top_k": 40, } 推論を実行 上記のペイロードを用いて推論を実行するためには、次のような Python 関数を使用してください。 # real-time inference def invoke_endpoint(endpoint_name, payload): response = sagemaker_runtime.invoke_endpoint( EndpointName=endpoint_name, ContentType=”application/json”, Body=json.dumps(payload), ) return json.loads(response["Body"].read().decode("utf-8")) 次のコードで推論を実施し、結果を出力します。 result = invoke_endpoint(model_name, payload) print(f"Result: {result}") 応答結果は次のようになります。 Result: {'message': 'OK', 'text': '世界で最も高い山は、ヒマラヤ山脈にあるエベレストです。標高8,848メートル（29,029フィート）です。チベット自治区とネパールの国境付近に位置します。1953年5月29日に英国隊が初登頂に成功したそうです。'} LHTM-OPT の応用的なユースケース LHTM-OPT は様々なユースケースに対応することができます。 例えば、LHTM-OPT は LangChain、LlamaIndex などのフレームワークと組み合わせることによって RAG、文章要約、文章生成などに応用することができます。LHTM-OPT のファインチューニングを実行するための API は公開していませんが、今後、提供する予定です。 オルツは現在、プライベート LLM の開発に関するコンサルティングや、企業独自のニーズに合わせたカスタマイズ、特定の業務に特化した LLM の開発支援も行っております。引き続き、日本社会における真の DX の実現に向けて、大規模言語モデルや生成 AI を活用したサービスの開発・提供に邁進し、社会に新たな価値を提供してまいります。 生成 AI の受託開発および LLM を活用した DX プロジェクト については、株式会社オルツ AI Solutions 事業部 (gptsolutions@alt.ai) にお問い合わせください。 あと片付け 無駄な費用が発生しないよう、推論エンドポイントを利用しなくなった場合、次のコードで削除してください。 sagemaker_client = boto3.client(“sagemaker”, region_name=region) sagemaker_client.delete_endpoint(model_name) sagemaker_client.delete_endpoint_config(model_name) まとめ 本記事では、AWS Marketplace から利用可能な軽量型大規模言語モデル LHTM-OPT 1.0 について紹介しました。LHTM-OPT の SageMaker におけるデプロイ方法と推論の実行方法についても解説しました。LHTM-OPT は小規模 GPU マシンでも実用的に動作する、パラメータ数が最適化された大規模言語モデルであり、様々なアプリケーションに適用可能です。ぜひ、 LHTM-OPT 1.0 を AWS Marketplace からお試しください 。 オルツは、今後も継続して様々なベンチマークで評価を行い、モデルをブラッシュアップし、LHTM-OPT 2.0 や LHTM-3 などをリリースする予定です。また、本モデルを基盤として自動質問応答、議事録自動要約、情報抽出、会話理解、予測分析のデータ整理・作成などの高度な処理が必要な問題に対応可能な多くのアプリケーションを実装していきます。 著者について 本橋 和貴 (Kazuki Motohashi / @kmotohas ) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。

このブログは‘“ Revolutionizing Generative Biology with AWS and EvolutionaryScale ”を翻訳したものです。 本日、AWS は EvolutionaryScale と提携し、同社の新しいバイオロジー向け最先端言語モデルを、創薬からカーボンキャプチャまで、さまざまなアプリケーションを推進する科学者や研究者に提供することを発表する運びとなり、大変興奮しています。 この発表により、EvolutionaryScale の最先端で最高水準の言語モデルファミリー ESM3 を AWS で利用可能になります。この提携により、生成的で多様な ESM3 モデルファミリーを含む EvolutionaryScale の最先端モデルを、業界をリードする AWS のインフラストラクチャ、エンタープライズグレードのセキュリティ、プライバシー対策、ヘルスケア・ライフサイエンス業界および生成 AI 向けの特化したサービス、生成 AI の機能(ファインチューニング、ガードレール等)と組み合わせることができます。これらは現在、製薬企業やバイオテックにより研究が行われている分野です。これには、生成 AI および機械学習に AWS を既に利用している、数十万人の AI /機械学習を利用する顧客と、上位 10 社のグローバル製薬企業 9 社が含まれ、この分野のさらなる民主化が促進されます。 ESM3 のような基盤モデルを使えば、研究者は複雑なマルチドメインタンパク質を一から生成したり、タンパク質設計のワークフローを作成したり、機能的な理解を組み込むことができます。ESM3 の強力な機能により、自然界には存在しない全く新しいタンパク質の創造が可能になり、科学者や研究者は革新的な「プログラム可能なバイオロジー」のアプローチを取ることができます。これにより、新薬の市場投入までの時間とコストを数年間と数十億ドルコストダウンできる可能性があります。 お客様は Amazon SageMaker を通じて ESM3 を簡単に利用開始でき、後にリリースされる Amazon Bedrock のサポートにより、 AWS HealthOmics を使ってエンドツーエンドの創薬ワークフローを完全自動化することができます。 Amazon Bedrock は、基盤モデルを使った生成 AI アプリケーションを構築・スケーリングする最も簡単な方法です。 ライフサイエンス業界での生成 AI の大きな機運: AWS は、さまざまな業界で生成 AI のイノベーションを加速する最前線にあり、大規模言語モデル (LLM) や基盤モデル (FM) の力を活用できるよう組織を支援しています。 Amazon Bedrock を利用して高性能の生成 AI モデルに簡単にアクセスできる数万社のお客様、 Amazon SageMaker で数百のプリトレーニングモデルを提供している AWS は、生成 AI アプリケーションの構築とスケーリングを簡素化しています。ライフサイエンス業界では生成 AI への熱気と機運が非常に高く、プロセスの自動化から研究や発見の仕方を根本的に変革するまで、お客様がビジネスを変革しています。例えば、 アストラゼネカ はゲノミクスを活用して創薬と精密医療の変革を加速し、研究者が洞察を迅速に科学的知見に変えられるようにしています。ギリアドは、企業全体のさまざまなソースからの非構造化情報の大量を迅速に分析できるよう、主要データセットから洞察を生成しています。 ファイザー は Bedrock や SageMaker などのサービスを使い、医学/科学コンテンツや特許出願を作成する AI ソリューションを展開し、画期的な成果を早期に患者に届けられるようにしながら、年間最大10億ドルのコスト削減も可能にしています。 そこで本日、EvolutionaryScale との、ライフサイエンス業界の研究開発を変革することを目指す共同イニシアティブと、 Go-To-Market での提携を発表する運びとなり、大変喜ばしく思います。 EvolutionaryScale は、バイオロジー向けの最先端言語モデルのトレーニングと適用を主導するリーディングチームで、バイオロジーデータへの大規模言語モデリングの最初の適用例の1つである Evolutionary Scale Modeling (ESM) モデルファミリーの開拓者です。彼らはバイオロジーへの生成 AI の適用で、バイオロジー特化の最初のトランスフォーマー言語モデル、スケーリング則、生物学的配列の構造予測手法の開発など、主要なマイルストーンを達成しています。本日、EvolutionaryScale は、この重要な分野で全く新しい地平を切り開く、初の生成的で多様な言語モデルファミリー ESM3 の発表を行いました。 生成 AI がバイオロジーを変える可能性: 生物学的配列を「生命の言語」と捉えることで、タンパク質工学やデザインの分野に生成 AI の手法を適用する可能性が広がります。大規模言語モデルが膨大なテキストデータセットで学習することで言語理解を示す有用なアシスタントになるのと同様に、ジェネレーティブ・バイオロジーモデルは大量のタンパク質配列データから「タンパク質の言語」を学習できます。これらのモデルはこれらの配列内のパターンや関係性を理解することで、創薬設計、酵素工学、合成生物学などの用途に合わせて機能的な新規タンパク質配列を生成できるのです。タンパク質はテキストとは 3 次元構造が異なりますが、これは生命の基本単位に関わる分野で生成 AI の力を活用して発見やイノベーションを加速する可能性を示唆しています。この技術は、進化、分子生物学、人工知能、医療、人々の健康をつなぐ変革の中心にあります。 ESM3: ジェネレーティブ・バイオロジーの画期的成果 EvolutionaryScale の ESM3 は、配列、構造、機能を同時に推論できるバイオロジー向けの画期的で最先端の生成モデルで、従来のタンパク質言語モデルには無い機能です。38 億年の進化を経た数十億のタンパク質配列で複数のモダリティを学習した ESM3 は、さまざまなソースからの複雑なバイオロジーデータを理解し、自然界には存在しない全く新しいタンパク質を生成できます。ESM3 モデルファミリーには、3 つの独自モデル(パラメータ数 98B、7B、1.4B)と 1 つのオープンソースモデル(パラメータ数 14 億)が含まれ、オープンソースバージョンは本日から Amazon SageMaker と AWS HealthOmics で、2024 年後半に Amazon Bedrock でも利用可能になる見込みです。 ESM3 モデルを使えば、お客様は以下のことが可能になります。 配列、構造、機能の「言語」を理解した ESM3 を使い、複雑なマルチドメインタンパク質を一から生成できる。 異なるモダリティに基づいて個々のドメインを設計し、それらを組み合わせて新規タンパク質を作れるタンパク質設計ワークフローを作成できる。 抗体の理解を組み込める: ESM3 は抗体配列と構造を非常に良く理解しているため、in silico で多様化、最適化、進化工学などの操作が可能。 ESM3 で作られた蛍光タンパク質 esmGFP バイオロジー基盤モデル (biological Foundation Models: bFM) を安全に民主化: 汎用の LLM や FM と同様に、AWS の包括的なヘルスケア・ライフサイエンス業界および生成 AI 向け特化サービスポートフォリオ (Amazon SageMaker 、 AWS HealthOmics、 AWS HealthScribe、 Amazon Bedrock など)を通じて、研究者は ESM3 のような bFM に簡単にアクセスできるようになります。Amazon SageMaker と AWS HealthOmics から始まり、お客様はEvolutionaryScale の最新オープンソースモデルバージョンを活用できるようになり、独自の ESM3 モデルファミリーもすぐにこれらのサービスと Amazon Bedrock で利用可能になります。フルマネージドなAWSサービスにより、研究者は ESM3 のようなパワフルな bFM を創薬ワークフローにカスタマイズしてシームレスに統合する最も簡単な方法をご利用いただけます。 この発表により、お客様は独自データセットで ESM3 をファインチューニングでき、独自データをプライベートに保ちながら、医薬品開発での画期的な発見を可能にし、イノベーションを加速できます。また、お客様はAWSの業界をリードする生成 AI インフラ (高性能 GPU インスタンスや AWS Trainium のトレーニング向け機械学習専用アクセラレータ、AWS Inferentia の推論向け機械学習専用アクセラレータなど) を活用してこれらのイノベーションをスケーリングできます。AWS の並外れた計算能力により、お客様は ESM3 のトレーニング、構築、実行を効率的に行えます。ESM3 のようなジェネレーティブ bFM を AWS サービスと統合することで、デプロイが簡素化され、データの暗号化処理、プライベートネットワーキング、HIPAA および GDPR コンプライアンスによる強固なセキュリティが確保されます。責任あるモデルの挙動をガイドするため、ガードレールが多層で組み込まれています。EvolutionaryScale の ESM3 は、有害なタンパク質の生成などの安全性リスクを軽減するよう設計されています。Amazon Bedrock のガードレールにより、お客様は倫理的 AI ポリシーに沿った入出力へのカスタムフィルタを実装できます。この公平性、安全性、透明性へのコミットメントにより、bFM の驚くべき可能性が責任を持って実現されます。 バイオロジーにおける生成 AI の未来 このマイルストーンは、バイオロジーアプリケーション向けにカスタマイズされた生成 AI 搭載モデルの新時代の幕開けを告げるものです。飛躍的な前進であるESM3は、AWSの生成 AI 機能とEvolutionaryScale の革新的 AI モデルが、計算パワーとデータスケールの最前線で相乗効果を発揮することで、創薬のタイムラインを大幅に短縮する可能性を秘めています。この提携により、プログラム可能なバイオロジーを可能にし、ライフサイエンス企業は責任ある生成 AI の力を活用して創薬の境界を押し広げ、プロセスを合理化し、最終的には新しい治療薬をより早く患者に届けられるようになります。ターゲット特定の合理化、イノベーションの促進、開発時間とコストの削減、創薬の成功確率向上につながります。 著者について Matt Wood: Matt は AWS の AI 関連プロダクトの Vice President です。この役割において、彼は顧客、パートナー、内部の AWS チームと緊密に連携し、あらゆる業界における AI の効果的な活用を推進しています。 Matt はアマゾンに 14 年間在籍しており、クラウドビジネス全般 (Lambda、Kinesis、SageMaker、DeepRacer、Athena、EMRの立ち上げ支援を含む) に携わってきました。特に、データ、分析、機械学習、人工知能に重点を置いてきました。彼の情熱は、NFL、Cerner、Intuit、Pinterest、GE、FINRA、Celgene、NASA などの AWS 顧客と協力し、彼らのアイデアを実現することにあります。アマゾン入社前は、英国で医学を学び、機械学習の博士号を取得し、コーネル大学で博士研究員を務めていました。 このブログはヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー 片岡 が翻訳しました。

本記事は、2024年5月15日に公開された Data migration strategies to Amazon RDS for Db2 を翻訳したものです。 AWS は re:Invent 2023 で Amazon Relational Database (Amazon RDS) for Db2 を発表しました。RDS for Db2 は、 Amazon RDS に新しく追加されたデータベースエンジンです。 最適なパフォーマンスを実現するスケーラブルなハードウェアで、数分で Db2 データベースを展開できます。 また、Multi-AZ デプロイメントを使えば、別の Availability Zone にあるスタンバイデータベースインスタンスにデータを同期レプリケーションする、高可用性データベースを構築できます。 このブログでは、Amazon RDS for Db2 の組み込み機能と AWS Database Migration Service (AWS DMS) または Db2 Migration Tooling (Db2MT) を使用して、セルフマネージド型の Db2 データベースを RDS for Db2 に移行する手順を説明します。 まず、採用できる様々な移行戦略の概要を示し、次に移行方法について説明し、最後に移行の計画のためのベストプラクティスを紹介します。 マイグレーション戦略 マイグレーション戦略は、セルフホスティングの Db2 データベースのオペレーティングシステムによって異なります。 ソースデータベースとターゲットデータベースのオペレーティングシステムが同じ場合 (例えば Linux から Linux へ) 、そのマイグレーションは リホスト と呼ばれます。 ソースデータベースのオペレーティングシステムが宛先データベースとは異なる場合 (例えば z/OS から Linux へ) 、そのマイグレーションは リプラットフォーム と呼ばれます。 次の表は、ソースデータベースの基盤となるオペレーティングシステムに基づく リホスト と リプラットフォーム の詳細をまとめたものです。 マイグレーション戦略 リホスト リプラットフォーム 備考 オペレーティングシステム Linux Linux 以外 (z/OS、AIX、Windows など) ネイティブの IBM Db2 マイグレーションツール、DMS、サードパーティ製品を使用できます。 マイグレーションのスピード 高速 低速 リホストの方が変換が不要なので高速です。 リプラットフォームは変換が必要で時間がかかります。 Db2 オフライン リストア はい いいえ Db2 のバックアップとリストアを使用します。リストアが完了するまでダウンタイムが発生します。 Db2 オンライン リストア はい いいえ Db2 のバックアップとロールフォワードリストアを使用します。短時間のダウンタイムですが、完了までに時間がかかる場合があります。 Db2 エクスポートまたはインポート はい はい 論理マイグレーションには Db2 のエクスポートとインポートを使用します。リプラットフォームの場合は変換のために時間がかかります。 クライアントからのロード はい はい Db2 を使用します。 Amazon S3 からのロード はい はい リプラットフォームの場合は高速です。 AWS DMS はい はい レプリケーション IBM CDC レプリケーション はい はい レプリケーション IBM Q レプリケーション はい はい レプリケーション メタデータの忠実性(+) 高い 中程度 リプラットフォームの場合は忠実性に特に注意が必要です。 データの品質 高い 中程度 リプラットフォームの場合は品質に特に注意が必要です。 使いやすさ 簡単 複雑 リホストの方が簡単です。 導入のワークロード 低い 高い リプラットフォームには大きなワークロードが必要です。 (+)ソースからターゲットに移行される際、データベーススキーマの再構築方法によっては、メタデータが正確に再現されないことがあります。例えば、自動インクリメントの開始点、シーケンス、隠し列、チェック制約、外部キー制約の適用などが正しく適用されない事があります。 Amazon RDS へのリホスト (同一オペレーティングシステムへの移行) セルフ運用している Db2 データベースが、リトルエンディアンの 64 bit Linux プラットフォーム上で実行されている場合、Amazon RDS for Db2 へリホストできます。 たとえば、Linux on Intel、AMD、Linux POWER LE (リトルエンディアン) 上のセルフ運用している Db2 データベースはリホストできますが、AIX、zLinux、Windows 上のものはリホストできません。 Amazon RDS へのリプラットフォーム (異なるオペレーティングシステムへの移行) セルフ運用している Db2 のオペレーティングシステムが Linux (リトルエンディアン) 以外の場合、ソースの Db2 データベースを Amazon RDS for Db2 にリプラットフォームする必要があります。 セルフ運用の Db2 データベースが AIX、Windows、zLinux などのオペレーティングシステム上で実行されている場合、Amazon RDS for Db2 でリプラットフォームできます。 再プラットフォームは、より広範な移行プロセスの第一段階と見なされ、組織はデータベースを迅速にAmazon RDS for Db2に移行し、その後、徐々に最適化や再アーキテクチャを検討することができます。 Amazon RDS for Db2 を使用して DB をリホストおよびリプラットフォームする移行方法 移行方法の選択は、ソースDb2のオペレーティングシステムの種類と許容できるダウンタイムによります。移行速度を確認するために、適切なサイズのデータベースを使ったテスト移行を行い、エンドツーエンドの移行時間を把握することをお勧めします。許容できるダウンタイムに応じて、一回限りの移行またはログレプリケーションを用いた移行のいずれかを選択できます。ビジネスニーズに基づいて適切なレプリケーション方法を選択するために、次の意思決定ツリーを参照してください。 Amazon RDS によるリホスト セルフ運用の Db2 データベースが、Linux 上で実行されている場合は、Amazon RDS for Db2 にリホストできます。Linux からの移行はデータ変換を必要としないため、再プラットフォームよりも簡単かつ短時間で完了します。移行には Db2 のネイティブツールを使用し、複雑なデータ構造の変更や最適化を避けます。 ワンタイムマイグレーション データベースのバックアップ、リストア、および切り替えを行う全体的な時間が許容できるダウンタイム内であれば、ワンタイム移行を利用できます。 セルフ運用の Db2 Linux データベースのバックアップを直接 Amazon Simple Storage Service (Amazon S3) にコピーし、Amazon RDS for Db2 でリストアするために、 Db2 Migration Tooling (Db2MT) を使用します。 Db2MT は、移行を完了するために必要なスクリプトを作成し、バックアップとリストアの両方を並列化して移行を高速化します。 次の図はそのソリューションアーキテクチャーを示しています。 手動でデータ移行を行う場合は、Amazon S3 からオフラインバックアップを復元するため、RDS for Db2 のストアードプロシージャ restore_database を呼び出すことができます。 ログレプリケーションを使用した移行 初期テスト移行によって測定された移行時間が許容できるダウンタイムよりも長い場合、A/Bデプロイメントアプローチを使用して、Linux上のセルフ運用のDb2からAmazon RDS for Db2へのログレプリケーションを使用した移行を実行できます。このアプローチでは、新しいRDS for Db2データベース（A）を旧データベース（B）と並行して使用し、準備が整った時点で切り替えを行います。 Db2MT は、前のセクションで説明したように、ユーザーが管理する Linux の Db2 のオンラインデータベースバックアップを直接 Amazon S3 に取得し、次に Amazon RDS for Db2 で復元するための手順を提供しています。Db2MT はまた、定期的にログを直接 Amazon S3 にアーカイブし、データベースをロールフォワードペンディングモードに維持して、ログを RDS for Db2 に適用する手順も提供します。 ロールフォワード 操作を完了することで、最終的に切り替えを行うことができます。 次の図は、このソリューションのアーキテクチャを示しています。 Amazon RDS for Db2 のストアードプロシージャ restore_database  を使用して、 backup_type  を  ONLINE に設定することで、オンラインバックアップイメージを復元できます。 Amazon RDS for Db2 のストアードプロシージャ rollforward_database  を使用して、アーカイブログを適用できます。 切り替え準備ができたら、ストアードプロシージャ  complete_rollforward を実行して、データベースの復旧を完了し、Amazon RDS for Db2 データベースを接続可能な状態にできます。 Amazon RDS へのリプラットフォーム もう 1 つの主要な課題は、AIX、Windows、メインフレー上の Db2 on Linux (ビッグエンディアン) から、スピーディかつダウンタイムをほぼゼロに抑えてデータを移行することです。 Amazon RDS へのリプラットフォームは、リホストに比べてより時間がかかります。 これは、AIX、Windows、メインフレーム上の Db2 on Linux から Db2 バックアップイメージを復元できないためです。 これは、リトルエンディアンとビッグエンディアンの違いが原因です。 ソースの Db2 データベースからメタデータを抽出し、Amazon RDS for Db2 に適用する必要があります。 最良の方法は、他のサードパーティツールが使用するリバースエンジニアリング方法と比較して、メタデータの再現度が最も高いネイティブツールである  db2look  を使用することです。 Db2 のネイティブツールである  export  を使用して、データをアンロードし、ネイティブツールである  import  または  load  を使用して、ソースから RDS for Db2 データベースに移行できます。 移行の相対的な速度については、次の図を参照してください。 AWS DMS は、セルフ運用されている Db2 データベースから Amazon RDS for Db2 に移行する処理を簡素化するマネージドサービスです。AWS DMS は Db2 を ターゲットエンドポイント としてサポートし、Amazon RDS for Db2へのフル ロードとChange Data Capture (CDC) の両方の移行方法に対応しています。 別の方法として、Db2MT を使えば、メタデータを抽出し、データをアンロードすることができます。抽出したメタデータを使用してデータベースオブジェクトを作成し、その後 Db2MT を利用して Amazon S3 から直接 Amazon RDS for Db2 にデータをロードできます。 これらのタスクは自動化されており、簡単なDb2MTコマンドを使用して各タスクを開始できるため、抽出および並列化の複雑なプロセスに取り組む必要はありません。 データベースの移行速度は、適度な量のデータを使ったサンプル移行を行って判断することをお勧めします。これにより、一括の移行か、ログレプリケーションによる移行のどちらを使うべきかが判断できます。 ワンタイム移行 カットオーバー時間を含めた合計時間がダウンタイムの許容範囲内であれば、ワンタイム移行を選択できます。AIX または Windows から移行し、データを Amazon RDS for Db2 にロードする場合は、Db2MT の利用をおすすめします。次の図に、このソリューションのアーキテクチャを示します。 Amazon RDS for Db2 は、Amazon S3 から直接データを読み込む機能をネイティブでサポートしています。Db2MTは  DB2REMOTE ID  を使用し、Amazon S3への ストレージアクセス を利用して、Amazon RDS for Db2に接続されたDb2クライアントを通じてAmazon S3から直接データをロードします。 ログレプリケーションによる移行 初期テスト移行を通じて測定された移行時間が停止時間の範囲を超える場合、AIX または Windows 上のセルフ運用の Db2 から Amazon RDS for Db2 への移行にログ レプリケーションを使用することができます。 前述の Db2MT を使用して ワンタイム移行を完了するステップに従います。次のいずれかの方法を使用してダウンタイムがほぼゼロの移行を実現できます。 AWS DMS  – AWS では、Db2 をソースとターゲットとしてサポートしています。AWS DMS の レプリケーションインスタンス を使用することで、ソースの Db2 データベースから Amazon RDS for Db2 に変更を同期できます。 IBM Q Replication  –  IBM Q Replication を使用して、AIX、Windows、メインフレーム上のLinux (ビッグエンディアン) で実行されている Db2 からのダウンタイムをほとんどなくす移行を実現できます。 次の図は、このソリューションのアーキテクチャを示しています。 移行プロジェクトの計画 データ移行プロセスでは、メタデータの忠実性の確保、データの整合性と品質の確保、AWS DMS などの既存の Amazon RDS サービスを使用したパフォーマンス上の懸念、コスト管理、統合への対処、レガシーアプリケーションのサポート、ネットワーク帯域幅、事業継続、災害対策、安全なアクセスのための入念な計画が必要であり、次のフェーズを含みます。 準備と計画: データベースサイズと複雑性の分析  – データベースのサイズとデータの複雑さを理解する。これは移行に必要な時間とリソースを見積もるのに役立ちます。 ピークとオフピーク時間の特定  – ユーザへの影響を最小限に抑えるため、オフピーク時にデータ移行を行うようにスケジューリングします。 テスト: 移行プロセスのテスト  – ステージング環境で徹底的なテストを実施し、潜在的な問題を特定し、移行プロセスを洗練します。 パフォーマンステスト  -実際のデータ転送を効率的に処理できるかを確認するために、負荷をかけて移行プロセスをテストします。 段階的な移行: 段階的なデータ移行  – 一度にすべてのデータを移行するのではなく、小さなチャンクに分割して移行することを検討します。このアプローチはリスクを低減し、移行スピードの改善に役立ちます。 レプリケーション  – 最終的な切り替えまで、新しいデータベースが古いデータベースと同期する状態を維持するために、データベースレプリケーションを使用します。 監視とバックアップ: 継続的な監視  – 問題やパフォーマンスのボトルネックがないか、移行プロセスを注意深く監視します。 バックアップ  – 万が一の場合に備えて、元のデータベースのバックアップを必ず取っておきます。 最終的な切り替えと検証: 切り替え  – すべてのデータが正確に転送され、新しいシステムの準備が整ったことを確認した後、最終的な切り替えを行います。 移行後の検証  – 新しいシステムのデータの整合性とパフォーマンスを確実に確認するため、徹底的なチェックを実施します。 データベースの移行はそれぞれ固有のものであり、前述の戦略は、個々の状況と要件に合わせてカスタマイズする必要があります。さらに、経験豊富なデータベース管理者や技術者のチームを巻き込むことで、スムーズかつ効率的な移行プロセスを実現できます。 まとめ このブログでは、Db2 から Amazon RDS for Db2 へ移行するためのリホストとリプラットフォームの戦略を示しました。リホストは、Db2MT を使用して既存システムへの変更を最小限に抑えながら Amazon RDS for Db2 に移行することを目指す組織にとって、簡単で効率の良いアプローチとなります。リプラットフォームは、フルロードと CDC を利用可能なAWS DMS または IBM Q Replication を利用可能な Db2MT を使用します。 どちらのアプローチも、アーキテクチャやアプリケーションの機能を変更する複雑さを伴わずに、Amazon RDS for Db2の強化されたスケーラビリティや潜在的なコスト削減などの即時の利点を提供します。また、Amazon RDS によるリホストまたはリプラットフォームは、AWS への移行の足がかりとなり、将来のモダナイゼーションおよび最適化の取り組みの基盤を築きます。 このブログにコメントをお寄せいただき、Db2 用 Amazon RDS に関する今後の投稿についてご要望をお聞かせください。 サービスの詳細は、 Amazon RDS for Db2 ユーザーガイド をご覧ください。 著者について Vikram S Khatri は Amazon RDS for Db2のシニアプロダクトマネージャーです。VikramはDb2に関して20年以上の経験を持っています。彼はゼロから新しい製品を開発することを楽しんでいます。余暇には瞑想やポッドキャストを聞くことを楽しんでいます。 翻訳は、Solution Architect の 野間が担当しました。 原文 はこちらです。

6月11日、 AWS CloudTrail Lake での生成人工知能 (生成 AI) を活用した自然言語クエリ生成のプレビュー版を発表できることを嬉しく思います。AWS CloudTrail Lake は、 AWS CloudTrail アクティビティログを取得、保存、アクセス、分析し、コンプライアンス、セキュリティ、運用上のニーズを満たすためのマネージドデータレイクです。CloudTrail Lake に保存されているこれらのアクティビティログ (管理イベントとデータイベント) について、自然言語を使用して質問できます。SQL クエリを作成する技術的な専門知識がなくても、またアクティビティイベントの正確な構造を解読するために時間を消費しなくてもかまいません。例えば、「スナップショットなしで削除されたデータベースインスタンスの数を教えてください」と尋ねると、機能によりその質問が CloudTrail Lake クエリに変換されます。このクエリは、そのまま実行することも、変更してリクエストしたイベント情報を取得することもできます。自然言語によるクエリ生成により、AWS アクティビティログの探索プロセスが簡単になります。 それでは、自然言語クエリ生成を使い始める方法を説明しましょう。 自然言語クエリ生成の開始方法 自然言語クエリジェネレーターは、生成 AI を使用してプロンプトからすぐに使用できる SQL クエリを生成します。このクエリは、CloudTrail Lake のクエリエディタで実行することを選択できます。 AWS CloudTrail コンソール では、 [Lake] (レイク) の下にある [Query] (クエリ) を選択します。クエリジェネレーターは、CloudTrail 管理イベントとデータイベントを収集するイベントデータストアのクエリのみを生成できます。CloudTrail Lake クエリのイベントデータストアを、 [Event data store] (イベントデータストア) のドロップダウンリストから選択します。 クエリジェネレーター では、自然言語を使用して [プロンプト] フィールドに次のプロンプトを入力します。 過去 1 か月間に記録されたエラーの数はどれくらいですか? 次に、 [Generate query] (クエリを生成) を選択します。次の SQL クエリが自動的に生成されます。 SELECT COUNT(*) AS error_count FROM 8a6*** WHERE eventtime >= '2024-04-21 00:00:00' AND eventtime <= '2024-05-21 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) [Run] (実行) を選択して結果を確認します。 これは面白く、もっと詳しく知りたいです。どのサービスで最もエラーが多かったか、なぜこれらのアクションがエラーになったのかを知りたいです。そこで、次のプロンプトを入力して追加の詳細をリクエストします。 過去 1 か月間に各サービスで記録されたエラーの数と、各エラーの原因は何でしたか? [Generate query] (クエリを生成) を選択すると、次の SQL クエリが生成されます。 SELECT eventsource, errorcode, errormessage, COUNT(*) AS errorCount FROM 8a6*** WHERE eventtime >= '2024-04-21 00:00:00' AND eventtime <= '2024-05-21 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) GROUP BY 1, 2, 3 ORDER BY 4 DESC; [Run] (実行) を選択して結果を確認します。 結果から、私のアカウントでは Amazon S3 に関連するエラーが最も多く、最も多いエラーは CORS とオブジェクトレベルの設定に関連していることがわかりました。さらに質問をすることで、さらに深く掘り下げて詳細を確認できます。しかし、今度は自然言語クエリジェネレーターに別の命令を与えましょう。 [Prompt] (プロンプト) フィールドに次のプロンプトを入力します。 過去 1 か月に使用した AWS サービスのトップ 10 はどれですか? イベント名も含めてください。 [Generate query] (クエリを生成) を選択すると、次の SQL クエリが生成されます。この SQL ステートメントは、フィールド名 ( eventSource 、 eventName 、 COUNT(*) AS event_count ) を取得し、 WHERE 句で過去 1 か月の日付間隔の行を制限し、行を eventSource と eventName でグループ化し、使用回数でソートし、自然言語で要求したように、結果を 10 行に制限します。 SELECT eventSource, eventName, COUNT(*) AS event_count FROM 8a6*** WHERE eventTime >= timestamp '2024-04-21 00:00:00' AND eventTime <= timestamp '2024-05-21 23:59:59' GROUP BY 1, 2 ORDER BY 3 DESC LIMIT 10; [Run] (実行) を選択して結果を確認します。 これで、過去 1 か月間に記録されたエラーの数、エラーの対象となったサービス、およびエラーの原因についての理解が深まりました。わかりやすい言葉で質問してみて、生成されたクエリをログに対して実行して、この機能がデータでどのように機能するかを確認できます。 プレビューをお試しください 自然言語クエリ生成は、 CloudTrail Lake の一部として米国東部 (バージニア北部) リージョンでプレビュー版として提供されています。 自然言語クエリ生成は、追加費用なしでプレビューで使用できます。CloudTrail Lake のクエリ料金は、クエリを実行して結果を生成する場合に適用されます。詳細については、 AWS CloudTrail の料金 をご覧ください。 自然言語クエリ生成の詳細と開始方法については、 AWS CloudTrail Lake ユーザーガイド をご覧ください。 — Esra 原文は こちら です。

6月11日、 Amazon Simple Storage Service (Amazon S3) 向け Amazon GuardDuty Malware Protection の一般提供についてお知らせします。これは、特定の S3 バケットへの悪意のあるファイルのアップロードを検出するための GuardDuty Malware Protection の拡張機能です。これまで、GuardDuty Malware Protection にはエージェントレススキャン機能があり、 Amazon Elastic Compute Cloud (Amazon EC2) とコンテナワークロードにアタッチされている Amazon Elastic Block Store (Amazon EBS) ボリューム上の悪質なファイルを特定していました。 これで、S3 バケットにアップロードされた新しいオブジェクトにマルウェアがないか継続的に評価し、見つかったマルウェアを隔離または排除するためのアクションを実行できます。Amazon GuardDuty Malware Protection は、 Amazon Web Services (AWS) が開発した、業界をリードする複数のサードパーティーマルウェアスキャンエンジンを使用して、Amazon S3 のスケール、レイテンシー、耐障害性を低下させることなくマルウェアを検出します。 GuardDuty Malware Protection for Amazon S3 では、指定した S3 バケットに組み込みのマルウェアとウイルス対策を使用できるため、悪意のあるファイルの評価を大規模に自動化することに伴う運用の複雑さとコストオーバーヘッドを排除できます。マルウェア分析に使用される既存の多くのツールとは異なり、GuardDuty のこのマネージドソリューションでは、マルウェア分析を実行したい各 AWS アカウントと AWS リージョンで、分離された独自のデータパイプラインやコンピューティングインフラストラクチャを管理する必要はありません。 開発チームとセキュリティチームが協力して、信頼できないエンティティから新たにアップロードされたデータをマルウェアスキャンする必要がある特定のバケットに対して、組織全体でマルウェア対策を設定して監視することができます。GuardDuty でオブジェクトのタグ付けなどのスキャン後のアクションを設定してダウンストリーム処理に役立てたり、 Amazon EventBridge から提供されたスキャンステータス情報を利用してアップロードされた悪意のあるオブジェクトを隔離したりできます。 S3 バケット向けの GuardDuty Malware Protection の開始方法 はじめに、 GuardDuty コンソール で [Malware Protection for S3] を選択し、 [Enable] (有効化) を選択します。 S3 バケット名を入力するか、 [Browse S3] (S3 を参照) をクリックして、現在選択されているリージョンに属するバケットのリストから S3 バケット名を選択します。選択したバケットに新しくアップロードされたすべてのオブジェクトを GuardDuty にスキャンさせたい場合は、 [All the objects in the S3 bucket] (S3 バケット内のすべてのオブジェクト) を選択できます。または、特定のプレフィックスに属する新しくアップロードされたオブジェクトをスキャンする場合は、 [Objects beginning with a specific prefix] (特定のプレフィックスで始まるオブジェクト) を選択することもできます。 新しくアップロードされた S3 オブジェクトをスキャンした後、GuardDuty は GuardDutyMalwareScanStatus というキーと以下のスキャンステータスの値を含む定義済みのタグを追加できます。 NO_THREATS_FOUND – スキャンされたオブジェクトに脅威は見つかりませんでした。 THREATS_FOUND – スキャン中に潜在的な脅威が検出されました。 UNSUPPORTED – このオブジェクトのサイズが原因で GuardDuty はスキャンできません。 ACCESS_DENIED – GuardDuty はオブジェクトにアクセスできません。許可を確認してください。 FAILED – GuardDuty はオブジェクトをスキャンできませんでした。 GuardDuty でスキャンした S3 オブジェクトにタグを追加したい場合は、 [Tag objects] (オブジェクトにタグ付け) を選択します。タグを使用すると、不正プログラム検索が完了する前にオブジェクトにアクセスされないようにするポリシーを作成し、アプリケーションが悪意のあるオブジェクトにアクセスするのを防ぐことができます。 次に、以下の必要な許可を含む AWS Identity and Access Management (IAM) ロールを先ず作成してアタッチする必要があります。 EventBridge アクションは、Malware Protection for S3 が S3 Event Notifications をリッスンできるように、EventBridge マネージドルールを作成および管理します。 Amazon S3 と EventBridge アクションは、このバケット内のすべてのイベントについて S3 Event Notifications を EventBridge に送信します。 Amazon S3 アクションは、アップロードされた S3 オブジェクトにアクセスし、スキャンされた S3 オブジェクトに定義済みのタグを追加します。 AWS Key Management Service (AWS KMS) キーアクションは、サポートされている DSSE-KMS と SSE-KMS を使用してテストオブジェクトをバケットにスキャンして配置する前に、オブジェクトにアクセスします。 これらの許可を追加するには、 [View permissions] (許可を表示) を選択し、ポリシーテンプレートと信頼関係テンプレートをコピーします。これらのテンプレートにはプレースホルダー値が含まれており、バケットと AWS アカウントに関連する適切な値に置き換える必要があります。AWS KMS キー ID のプレースホルダー値を置き換える必要もあります。 次に、 [Attach permissions] (許可をアタッチ) を選択すると、IAM コンソールが新しいタブに表示されます。新しい IAM ロールを作成するか、コピーしたテンプレートの許可で既存の IAM ロールを更新するかを選択できます。IAM ロールを事前に作成または更新したい場合は、AWS ドキュメントの「 前提条件 – IAM PassRole ポリシーの追加 」をご覧ください。 最後に、IAM コンソールが開いている GuardDuty ブラウザタブに戻り、作成または更新した IAM ロールを選択して、 [Enable] (有効化) を選択します。 これで、この保護されたバケットの保護 [Status] (ステータス) 列に「 Active 」と表示されます。 [View all S3 malware findings] (すべての S3 マルウェア検出結果を表示) を選択すると、スキャンされた S3 バケットに関連して生成された GuardDuty の検出結果が表示されます。「S3Object:S3/MaliciousFile」という検出結果タイプが返された場合、GuardDuty はリストに表示されている S3 オブジェクトを悪意のあるオブジェクトとして検出しました。 [Findings] (検出結果) の詳細パネルで [Threats detected] (検出された脅威) セクションを選択し、推奨される修復手順に従います。詳細については、AWS ドキュメントの「 Malware Protection for S3 の検出結果の修復 」をご覧ください。 知っておくべきこと AWS アカウントで GuardDuty が有効になっていなくても、S3 バケットに GuardDuty Malware Protection を設定できます。ただし、アカウントで GuardDuty を有効にすると、マルウェア保護機能を利用できるだけでなく、 AWS CloudTrail 管理イベント、 Amazon Virtual Private Cloud (Amazon VPC) フローログ、DNS クエリログなどの 基本的なソース を完全に監視できます。セキュリティの検出結果を AWS Security Hub と Amazon Detective に送信して、さらに調査することもできます。 GuardDuty は、S3 Standard、S3 Intelligent-Tiering、S3 Standard-IA、S3 One Zone-IA、および Amazon S3 Glacier Instant Retrieval という同期 Amazon S3 ストレージクラス に属するファイルをスキャンできます。マルウェアの拡散や封じ込めに使用されていることが知られているファイル形式をスキャンします。リリース時点では、この機能は最大 5 GB のファイルサイズをサポートします。これには、最大 5 レベルのアーカイブファイルと、解凍後 1 レベルあたり 1,000 ファイルが含まれます。 既に述べたように、GuardDuty は保護されている S3 バケットごとに EventBridge にスキャンメトリクスを送信します。アラームを設定し、オブジェクトにタグを付けたり、悪意のあるオブジェクトを検疫バケットに移動したりするなどのスキャン後のアクションを定義できます。 Amazon CloudWatch メトリクスや S3 オブジェクトのタグ付けなど、その他のモニタリングオプションの詳細については、AWS ドキュメントの「 マルウェアスキャンステータスのモニタリング 」をご覧ください。 今すぐご利用いただけます Amazon GuardDuty Malware Protection for Amazon S3 は、中国リージョンと GovCloud (米国) リージョンを除き、GuardDuty が利用可能な すべての AWS リージョン で現在一般的にご利用いただけます。 料金は、スキャンされたオブジェクトの GB ボリュームと 1 か月あたりに評価されたオブジェクトの数に基づいています。この機能では、新しい AWS アカウントの場合はアカウント作成の最初の 12 か月間、既存の AWS アカウントの場合は 2025 年 6 月 11 日までの条件に従って、毎月 1,000 件のリクエストと 1 GB の制限付きの AWS 無料利用枠をご利用いただけます。詳細については、「 Amazon GuardDuty の料金 」ページにアクセスしてください。 GuardDuty コンソール で GuardDuty Malware Protection for Amazon S3 をお試しください。詳細については、「 Amazon GuardDuty ユーザーガイド 」をご覧ください。また、 AWS re:Post for Amazon GuardDuty 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 先週は幕張メッセで AWS Summit Japan を開催しました。ご参加頂けた方は楽しめたでしょうか？ 私は GenU (Generative AI Use Cases JP) の展示ブースに立ちながら、多くのお客様と直接お話しする機会がありました。その中で、お客様の AWS や生成 AI への関心の高さ、そして技術への情熱を肌で感じることができ、私自身も大いに刺激を受けました。 AWS Summit Japan の各セッションについて、 オンデマンド配信 がすでに開始されています。7/5 まで動画閲覧や資料ダウンロードができますので、ぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年6月17日週の主要なアップデート 6/17(月) Amazon EC2 C7i-flex instances are now available in US East (Ohio) Region Amazon EC2 で C7i-Flex インスタンスがオハイオリージョンで利用可能になりました。C6i インスタンスと比べて、最大 19 % のコストパフォーマンス向上を実現するタイプです。Flex インスタンス (M7i-Flex, C7i-Flex) は、従来のインスタンス (M7i, C7i) の低価格タイプとなっています。EC2 インスタンスを利用する際に、CPU 利用率は、低い時期と高い時期があるのが一般的だと考えられます。Flex インスタンスは、そういった常時 100 % の力を発揮しなくても良いような利用方法に適しているインスタンスタイプです。CPU 性能の 40 % はベースラインとして、常時提供します。ベースラインの 40 % を超える場合、95 % の確率で 100 % までスケールアップする仕組みを提供します。Web アプリケーションサーバー、データベース、仮想デスクトップ、バッチ処理、マイクロサービス、キャッシュといったユースケースでご検討いただけます。Flex インスタンスの特徴の詳細は、こちらの FAQ の「Flex instances」章もご覧ください。 AWS CodeBuild now supports organization and global GitHub webhooks AWS CodeBuild で、GitHub と GitHub Enterprise Server のグローバル Webhook がサポートされるようになりました。これにより個別のリポジトリごとに Webhook を設定することなく、単一の Code Build Webhook を設定するだけで組織内のすべてのリポジトリからイベントを受信できるようになりました。これらのイベントには、GitHub Actions のワークフロー実行、コミットのプッシュ、リリース、プルリクエストが含まれます。 AWS Systems Manager now supports additional Rocky, Oracle, and Alma Linux versions AWS Systems Manager で Rocky Linux、Alma Linux、Oracle Linux のバージョン 8.8 および 8.9 を実行しているインスタンスをサポートするようになりました。これにより、より多様な環境で Systems Manager を利用できるようになりました。Systems Manager は運用を支援するサービスであり、例えばインベントリ管理や、パッチ管理、遠隔アクセスの Session Manager などの機能が利用できます。 6/18(火) Amazon Connect Cases is now available in additional Asia Pacific regions Amazon Connect Cases が東京とソウルリージョンで利用できるようになりました。Amazon Connect Cases は電話を受けた担当者が、問い合わせケースを作成、共同作業のアサインなど、問い合わせを素早く解決するための管理機能を提供します。例えば、お客様から Amazon Connect に電話がかかってきた際に、担当者がお客様と会話しながら「問い合わせ概要」、「状況」、「問い合わせの詳細」を入力する機能を提供します。また、作成した問い合わせケースは、お客様名や電話番号で検索ができ、過去の対応履歴を検索、閲覧することも可能です。 CodeCatalyst allows customers to use Amazon Q Developer to choose a blueprint Amazon Q Developer in Amazon CodeCatalyst の一般提供を開始しました。CodeCatalyst にはブループリントと呼ばれる、Project テンプレートを管理、作成、利用する機能があります。ソースコードや CI/CD ワークフローを組織の形に合わせてテンプレート化しておくことで、新しい開発作業を始める際にテンプレートを流用できるメリットがあります。このアップデートで、自然言語を使って「お客様の実現したい内容」を記載すると、それに基づいたブループリントをガイドしてくれるようになりました。 Introducing Maven, Python, and NuGet support in Amazon CodeCatalyst package repositories Amazon CodeCatalyst のパッケージリポジトリで、Maven、Python、NuGet パッケージをサポートしました。パッケージリポジトリは、社内独自のライブラリなどをパッケージ化することで、社内に限定した公開や管理ができるようになります。 Amazon Redshift announces support for VARBYTE 16MB data type Amazon Redshift の VARBYTE 型のデータサイズ上限が、1 MB から 16 MB に増えました。VARBYTE は可変長バイナリ文字列を格納および表現するための可変サイズのデータ型です。例えば、画像データを直接バイナリデータとして Redshift に格納することで、アプリケーションから見ると実装がシンプルになるメリットが考えられます。 6/19(水) Amazon CodeCatalyst now supports GitHub Cloud and Bitbucket Cloud with Amazon Q Amazon CodeCatalyst は、Amazon Q と連携することで、課題 (Issue) を解決する Pull Request を自動生成する機能があります。今回のアップデートで、CodeCatalyst でリンク設定した GitHub Cloud および Bitbucket Cloud 上のリポジトリに対して、Amazon Q の連携機能が提供されました。CodeCatalyst 上で GitHub や Bitbucket のリポジトリと連携する機能が、Amazon Q によって強化された形になります。 AWS Glue adds additional 13 new transforms including flag duplicates AWS Glue で新たに 13 個の組み込み変換機能が追加されました。重複している列や行をフラグ付け、電話番号の書式設定、大文字小文字の書式設定、最頻値で埋める、重複を削除、月名、偶数かどうか、暗号化ハッシュ、復号化、暗号化、数値を IP アドレスに変換、などがあります。データを加工したい方が変換フローを作り上げるときに、より多くのアクションを利用できるようになり、素早く構築しやすくなりました。 Amazon SageMaker now offers a fully managed MLflow Capability Amazon SageMaker で MLflow をフルマネージドな形で提供開始しました。Mlflow は機械学習の実験管理を支援するポピュラーなオープンソースツールです。データサイエンティストは、馴染みのある MLflow を利用して、ML実験を整理、追跡、分析できます。また、SageMaker 上で利用することで、高いスケーラビリティ、可用性、セキュリティ向上、といったメリットがあります。詳細は こちらの Blog をご覧ください。MLflow 機能は追加料金が設定されております。 Price ページ の「MLflow」タブもご覧ください。 6/20(木) Anthropic’s Claude 3.5 Sonnet model now available in Amazon Bedrock Amazon Bedrock で Anthropic 社の最新モデル Claude 3.5 Sonnet を一般提供開始しました。Anthropic で一番知能の高いモデルとなっており、Claude 3 Opus を上回る性能を発揮しながら、Opus の 1/5 のコストでご利用いただけます。Claude 3.5 Sonnet の主な特徴は、画像を利用したときの処理や理解能力の向上、より自然で人間らしい雰囲気の高品質な文章生成、文脈を理解しながらマルチステップの処理能力の向上などがあります。バージニア北部リージョンでご利用いただけます。詳細はこちらの リリースブログ をご覧ください。 Amazon Bedrock now supports compressed embeddings from Cohere Embed Amazon Bedrock で Cohere Embed モデルを利用してベクトルを生成する際に、圧縮された埋め込み (int8, binary) をサポートしました。この圧縮された埋め込みを使用することで、ベクトル検索エンジンに埋め込みを保存して利用する際に、パフォーマンスの向上、ストレージコストの削減といったメリットがあります。一般的に利用される FP32 精度形式に比べて大幅に小さいサイズですが、精度の低下は最小限に抑えられています。ユースケースの一つとして、マルチテナント SaaS の裏側で大規模なベクトルデータを構成する際に、より高速なパフォーマンスを提供しやすくなる使い方が考えられます。 6/21(金) Amazon SageMaker JumpStart now provides granular access control for foundation models Amazon SageMaker JumpStart で数百の基盤モデルを素早くデプロイするための機能が提供されています。この基盤モデルに対して、きめ細かいアクセス制御を簡単に設定できるようになりました。ユースケースを挙げると、Apache 2.0 のライセンスモデルのみ組織内で利用可能にしたいときなどがあります。現在は、オハイオリージョンでご利用いただけます。詳細はこちらの Blog をご覧ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

IAM Access Analyzer をさらに強力にし、カスタムポリシーチェックを拡張し、IAM ポリシーの微調整に役立つガイダンスに簡単にアクセスできるようにしました。これらの新機能はどちらも、re:Invent 2023 で開始された カスタムポリシーチェックと未使用アクセス分析 に基づいています。こちらが弊社が立ち上げるものです。 新しいカスタムポリシーチェック – 自動推論の力を利用した新しいチェックは、特定の重要な AWS リソースへのアクセスを許可するポリシー、またはあらゆる種類のパブリックアクセスを許可するポリシーを検出するのに役立ちます。どちらのチェックも、デプロイ前に、おそらく CI/CD パイプラインの一部として使用するように設計されており、組織のセキュリティ慣行やポリシーに準拠していない更新を積極的に検出するのに役立ちます。 ガイド付き取り消し – IAM Access Analyzer では、実際には必要のないアクセス権を付与する許可を取り消せるようガイダンスを提供し、デベロッパーと共有できるようになりました。これには、未使用のロール、未使用の許可を持つロール、IAM ユーザーの未使用のアクセスキー、IAM ユーザーの未使用のパスワードが含まれます。ガイダンスには、余分な項目を削除するか、より制限の厳しい項目に置き換えるために必要な手順が含まれています。 新しいカスタムポリシーチェック 新しいポリシーチェックは、コマンドラインから、または API 関数を呼び出すことで呼び出すことができます。チェックは、リクエストの一部として提供されたポリシードキュメントを検証し、 PASS または FAIL の値を返します。いずれの場合も、 PASS はポリシー文書が特定のアクセスを適切に拒否していることを示し、 FAIL はポリシーが許可の一部またはすべてを許可している可能性があることを示します。新しいチェックは次のとおりです。 パブリックアクセスがないことのチェック – このチェックはリソースポリシーに対して実行され、ポリシーが指定されたリソースタイプへのパブリックアクセスを許可しているかどうかを確認します。例えば、 AWS::S3::Bucket リソースタイプを指定することで、ポリシーで S3 バケットへのパブリックアクセスが許可されているかどうかを確認できます。有効なリソースタイプには、DynamoDB テーブルとストリーム、EFS ファイルシステム、OpenSearch ドメイン、Kinesis ストリームとストリームコンシューマー、KMS キー、Lambda 関数、S3 バケットとアクセスポイント、S3 Express ディレクトリバケット、S3 Outposts バケットとアクセスポイント、Glacier、Secrets Manager シークレット、SNS トピックとキュー、ロールを引き受ける IAM ポリシードキュメントなどがあります。有効なリソースタイプのリストは、時間が経つにつれて拡大していく予定で、 CheckNoPublicAccess のドキュメントに記載されています。 Amazon Simple Queue Service (Amazon SQS) キューへのパブリックアクセスを誤って許可するポリシーがあるとします。確認方法は次のとおりです。 $ aws accessanalyzer check-no-public-access --policy-document file://resource.json \ --resource-type AWS::SQS::Queue --output json 結果は、次のとおりです。 { "result": "FAIL", "message": "The resource policy grants public access for the given resource type.", "reasons": [ { "description": "Public access granted in the following statement with sid: SqsResourcePolicy.", "statementIndex": 0, "statementId": "SqsResourcePolicy" } ] } ポリシーを編集して付与したアクセス権を削除して再試行すると、今度はチェックに合格しました。 { "result": "PASS", "message": "The resource policy does not grant public access for the given resource type." } アクセス権が付与されていないことのチェック – このチェックは、一度に 1 つのリソースポリシーまたは ID ポリシーに対して実行されます。また、アクションとリソースのリストも受け付けます。いずれも IAM ポリシーの一部として受け入れられる形式です。このチェックでは、ポリシーが、リスト内のリソースへの意図しないアクセスを、リスト内のアクションによって許可していないかどうかを確認します。例えば、このチェックを使用して、ポリシーで重要な CloudTrail 証跡の削除が許可されていないことを確認できます。 $ aws accessanalyzer check-access-not-granted --policy-document file://ct.json \ --access resources="arn:aws:cloudtrail:us-east-1:123456789012:trail/MySensitiveTrail" \ --policy-type IDENTITY_POLICY --output json IAM Access Analyzer は、次のように、チェックが失敗したことを示しています。 { "result": "FAIL", "message": "The policy document grants access to perform one or more of the listed actions or resources.", "reasons": [ { "description": "One or more of the listed actions or resources in the statement with index: 0.", "statementIndex": 0 } ] } ポリシーを修正して再試行すると、今度はチェックに合格します。このことから、ポリシーがリストされたリソースへのアクセスを許可していないことがわかります。 { "result": "PASS", "message": "The policy document does not grant access to perform the listed actions or resources." } ガイド付き取り消し 以前の記事では、IAM Access Analyzer が、実際には必要のないアクセス権を付与する IAM 項目を検出して一覧表示する方法を説明しました。本日のリリースにより、ユーザー (または開発チーム) がこのような検出結果を解決するのに役立つガイダンスを得られます。私の AWS アカウントの最新の検出結果は次のとおりです。 これらの中には、あるサービスへの早期アクセス権を与えられ、そのサービスを利用してブログを書いたときの残り物もあれば、私がクラウド管理者として一般的に無能だったことが原因のものもあります。 どちらにせよ、これらをクリーンアップしないといけません。2 つ目の「 未使用のアクセスキー 」から始めましょう。項目をクリックすると、下部に新しい [Recommendations] (レコメンデーション) セクションが表示されます。 手順に従ってアクセスキーを削除することも、 [Archive] (アーカイブ) をクリックして検出結果をアクティブな結果のリストから削除し、アーカイブされた検出結果のリストに加えることもできます。今後似たような検出結果に対して同じことをするアーカイブルールを作成することもできます。未使用の IAM ユーザー、IAM ロール、およびパスワードについても同様のレコメンデーションが提供されています。 それでは、 未使用の許可 の検出結果について見てみましょう。 レコメンデーションは既存のポリシーを新しいポリシーに置き換えることです。次のように、新しいポリシーを既存のポリシーと並べてプレビューできます。 最初の例のように、手順に従うことも、検出結果をアーカイブすることもできます。 検出結果とレコメンデーションは、コマンドラインからも確認できます。次のように、アナライザーとその検出結果を指定してレコメンデーションを生成します。 $ aws accessanalyzer generate-finding-recommendation \ --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer \ --id 67110f3e-05a1-4562-b6c2-4b009e67c38e 次に、レコメンデーションを取得します。この例では、JSON 出力全体がかなり充実しているので、ステップのみを表示するように出力をフィルタリングしています。 $ aws accessanalyzer get-finding-recommendation \ --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer \ --id 67110f3e-05a1-4562-b6c2-4b009e67c38e --output json | \ jq .recommendedSteps[].unusedPermissionsRecommendedStep.recommendedAction "CREATE_POLICY" "DETACH_POLICY" これらのコマンド (または同等の API コール) を使用して、レコメンデーションを独自のツールやシステムに統合できます。 今すぐご利用いただけます 新しいチェックと解決手順がご利用いただけるようになり、すべてのパブリック AWS リージョンで今すぐ利用を開始できます。 – Jeff ; 原文は こちら です。

セキュリティは Amazon Web Services (AWS) の最優先事項であり、6月11日、お客様の AWS アカウントのセキュリティ体制を強化するのに役立つ 2 つの機能をリリースします。 まず、ルートユーザーと AWS Identity and Access Management (IAM) ユーザー向けに、サポート対象の 多要素認証 (MFA) のリストに パスキー を追加します。 次に、ルートユーザーに MFA を適用 し始めました。最も機密性の高いユーザー、つまり AWS Organization の 管理アカウント のルートユーザーから始めました。2024年の残りの期間中に、この変更を他のアカウントにも引き続き適用します。 MFA は、アカウントのセキュリティを強化する最も簡単で効果的な方法の 1 つであり、保護層をさらに強化して権限のない個人がシステムやデータにアクセスするのを防ぎます。 ルートユーザーと IAM ユーザー用のパスキー付きの MFA パスキーは、 FIDO2 認証用に作成された認証情報に使用される一般的な用語です。 パスキーは、サービスまたはウェブサイトに登録したときにクライアントデバイス上で生成される一組の暗号化キーです。キーペアはウェブサービスドメインにバインドされ、それぞれ一意です。 キーのパブリック部分はサービスに送信され、サービス側に保存されます。キーのプライベート部分は、 セキュリティキー などの安全なデバイスに保存されるか、 iCloud キーチェーン 、 Google アカウント 、または 1Password などのパスワードマネージャーといったクラウドサービスを使用するときに、ユーザーアカウントに接続されたデバイス間で安全に共有されます 。 通常、キーのプライベート部分へのアクセスは、デバイスに応じて、PIN コードまたは生体認証 (Apple Face ID 、 Touch ID 、 Microsoft Hello などの生体認証) によって保護されます。 パスキーで保護されているサービスで認証しようとすると、サービスがブラウザに課題を送信します。その後、ブラウザは私のデバイスにプライベートキーを使って課題に署名するように要求します。これにより、PIN または生体認証がトリガーされ、プライベートキーが保存されている安全なストレージにアクセスします。ブラウザは署名をサービスに戻します。署名が有効であれば、サービスに保存されているパブリックキーと一致するプライベートキーを所有していることが確認され、認証が成功します。 このプロセスと現在使われているさまざまな標準 ( FIDO2 、 CTAP 、 WebAuthn ) の詳細については、 2020 年 11 月に AWS IAM アイデンティティセンターでパスキーのサポートを開始したときに私が書いた記事 を参照してください。 パスキーはパスワードの代わりに使用できます。ただし、今回の初回リリースでは、パスワードに加えてパスキーを第二要素認証として使用することにしました。パスワードは知っているもので、パスキーは持っているものです。 パスキーはパスワードよりもフィッシング攻撃に対する耐性が高くなります。まず、指紋、顔、または PIN コードで保護されたプライベートキーにアクセスするのがはるかに困難です。次に、パスキーは特定のウェブドメインにバインドされるため、意図せず開示された場合の範囲が狭まります。 エンドユーザーは、使い勝手が良く、簡単に復元できるというメリットがあります。携帯電話やノートパソコンに組み込まれている認証システムを使用して、暗号化で保護された認証情報をロック解除して AWS サインインを行うことができます。また、クラウドサービス (iCloud キーチェーン、Google アカウント、1Password など) を使用してパスキーを保存すると、パスキープロバイダーのアカウントに接続されているどのデバイスからでもパスキーにアクセスできます。これにより、不幸にもデバイスを紛失した場合に、パスキーを回復できます。 IAM ユーザーのパスキー MFA を有効にする方法 パスキー MFA を有効にするには、コンソールの AWS Identity and Access Management (IAM) セクションに移動します。ユーザーを選択し、ページを下にスクロールして [Multi-factor authentication (MFA)] (多要素認証 (MFA)) セクションに移動します。次に、 [Assign MFA device] (MFA デバイスの割り当て) を選択します。 耐障害性とアカウントの回復を強化するために、 1 人のユーザーに対して複数の MFA デバイスを有効にできます 。 次のページで [MFA device name] (MFA デバイス名) を入力し、 [Passkey or security key] (パスキーまたはセキュリティキー) を選択します。その後、[Next] (次へ) を選択します。 パスキーをサポートするパスワードマネージャーアプリケーションを使用すると、ポップアップが表示され、そのアプリケーションを使用してパスキーを生成して保存するかどうかを尋ねてきます。そうしない場合、ブラウザにいくつかのオプションが表示されます。画面の正確なレイアウトは、オペレーティングシステム (macOS または Windows) と使用するブラウザによって異なります。これは、Chromium ベースのブラウザを搭載した macOS で表示される画面です。 残りの操作は、選択内容によって異なります。 iCloud キーチェーン は、パスキーを生成して保存するための Touch ID の入力を促します。 このデモでは、電話などの別のデバイスでパスキーをブートストラップする方法を説明します。そこで、代わりに [Use a phone, tablet, or security key] (スマートフォン、タブレット、またはセキュリティキーを使用する) を選択します。ブラウザに QR コードが表示されます。次に、携帯電話を使用して QR コードをスキャンします。電話が Face ID で私を認証し、パスキーを生成して保存します。 この QR コードベースのフローでは、あるデバイスのパスキーを使用して別のデバイス (デモでは電話とノートパソコン) にサインインできます。これは FIDO 仕様で定義されており、 クロスデバイス認証 (CDA) として知られています。 すべてがうまくいけば、IAM ユーザーのパスキーが登録されます。 IAM ユーザーを使って AWS コンソールで人を認証することはお勧めしません。代わりに AWS IAM アイデンティティセンター でシングルサインオン (SSO) を設定することをお勧めします。 サインインエクスペリエンスはどのようなものですか? MFA を有効にしてパスキーを設定したら、アカウントにサインインしてみます。 ユーザーエクスペリエンスは、使用するオペレーティングシステム、ブラウザ、およびデバイスによって異なります。 例えば、iCloud キーチェーンが有効になっている macOS では、Touch ID キーをタッチするようにシステムから求められます。このデモでは、CDA を使用して携帯電話にパスキーを登録しました。そのため、携帯電話で QR コードをスキャンするようにシステムから求められます。スキャンが完了すると、電話の Face ID で認証してパスキーのロックを解除し、AWS コンソールによりサインイン手順が終了します。 ルートユーザーに MFA の使用を強制する 6月11日 2 つ目の発表は、一部の AWS アカウントのルートユーザーに MFA の使用を強制し始めたことです。この変更は昨年、 Amazon の最高セキュリティ責任者である Stephen Schmidt のブログ記事 で発表されました。 Schmidt の言葉を引用すると: AWS で最も権限のあるユーザーが MFA で保護されていることを確認することは、AWS のお客様のセキュリティ体制を継続的に強化するという当社の取り組みの新たな一手に過ぎません。 まず、最も機密性の高いアカウントである AWS Organizations の管理アカウントから始めました。ポリシーの導入は段階的に行われ、一度に数千のアカウントに対してしか行えません。今後数か月にわたって、大部分の AWS アカウントのルートユーザーに MFA 強制ポリシーを段階的に導入する予定です。 ルートユーザーアカウントで MFA を有効にしていない状態でアカウントが更新されると、サインイン時に MFA を有効にするように求める新しいメッセージがポップアップで表示されます。猶予期間があり、その後は MFA が必須になります。 中国を除くすべての AWS リージョンで、今日からパスキーを多要素認証に使用できるようになりました。 中国の 2 つのリージョン (北京、寧夏) と AWS GovCloud (米国) を除くすべての AWS リージョンで多要素認証の使用を強制します。これらのリージョンの AWS アカウントにはルートユーザーがいないためです。 次に、 アカウントのルートユーザーのためにパスキー MFA を有効にします 。 — seb 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 6月20日から21日にかけて AWS Summit Japan が開催されました！たくさんの方にご来場頂き、本当にありがとうございました。初日の基調講演では生成AIに関するニュースをお届けしました。お客様事例登壇も大変興味深いものでしたので、ご覧になっていない方は7/5までオンデマンドで配信中の動画をぜひご覧ください。ここではサービス関係のお知らせをまとめていきましょう。 7月中に、東京リージョンのAmazon BedrockでAnthropic Claude 3をご利用可能に 2024年中に、Amazon Q Businessの日本語正式サポートと東京リージョン対応を実施 生成AI実用化推進プログラムを発表。基盤モデル自体を開発・カスタマイズする方と、既存のモデルを活用してプロダクトやソリューションの機能や価値を高めたい方の両方を支援（詳細は近日発表） また、日本時間の6月20日から21日にかけて、 AnthropicからClaude 3.5 Sonnetが発表 されました。このモデルはバージニアリージョンのAmazon Bedrockを介してご利用頂けるようになっていますので、こちらもご注目ください。 それでは、6 月 17 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Anthropic’s Claude 3.5 Sonnet model now available in Amazon Bedrock: Even more intelligence than Claude 3 Opus at one-fifth the cost」を公開 冒頭でも書きましたが、 AnthropicのClaude 3.5 Sonnetが発表 され、バージニアリージョンの Amazon Bedrock にてご利用頂けるようになっています。Claude 3.5 SonnetはClaude 3 Opusよりも高いベンチマークスコアを記録する高い能力を発揮すると同時に、Opusよりも80%安価にご利用頂けるとされています。用途に応じて適したモデルを選べるのがAmazon Bedrockの価値のひとつですので、Anthropicのモデルもそうですが他の多言語対応をうたっているモデル、例えばCohere Command R/R+などと比較し、最適なものを選択しましょう。 AWS生成AI国内事例ブログ: 株式会社ナウキャスト様、決算短信データ抽出業務にLLMを適用 株式会社ナウキャスト様は、POSデータやクレジットカードの決済データを解析し、生活者の消費行動や企業活動をより早く正確に捉えるデータソリューションの提供に取り組んでいます。そのためにはデータが必要不可欠ですが、膨大な適時開示資料から人力でデータ抽出を行っており、作業負担が課題になっていました。ナウキャスト様はLLM(大規模言語モデル)を自然言語の処理技術として捉え、適したタスクの見極めを行うことを考え、「セグメント別売り上げ情報抽出」が適したタスクのひとつだと判断、Amazon Bedrockを介したClaude 2で処理を行うこととしました。それによって抽出精度90%を達成、作業工数を50%削減という結果を達成しています。またローコード開発ツールStreamlitとAWSのマネージドサービスを活用し、担当者1名という限られたリソースで短時間の開発と検証を実施したそうです。今後は対象業務と銘柄の拡大を行い、データ単体のマネタイズやオペレーション自体の顧客への提供を考えているとのことです ブログ記事「非構造化金融データに隠された関連性を Amazon Bedrock と Amazon Neptune で発見する」を公開 先週公開されたブログですが、ピックアップ漏れがあったので今回紹介します。生成AIの適用が期待される領域に、データから新たな洞察（インサイト）を得るというものがあります。このブログ記事では、フルマネージドなグラフDBのサービスである Amazon Neptune と、 Amazon Bedrock の生成AIモデルを活用することにより、金融データに隠れたデータ間の関連性を見いだす方法を解説するものです。 サービスアップデート AnthropicのClaude 3.5 SonnetがAmazon Bedrockで利用可能に 既にお知らせしているように、AnthropicのClaude 3.5 SonnetがバージニアリージョンのAmazon Bedrockでご利用頂けるようになりました。 Amazon BedrockがCohere EmbedモデルによるCompressed Embeddingsをサポート Amazon BedrockでCohereのEmbedを利用したCompressed Embeddingsに対応しました。これは検索拡張生成(RAG)やセマンティック検索で利用されるケースが多い機能で、生成AIを組み込んだアプリケーションを効率化します。一般的にはEmbeddings形式のデータは、FP32(32ビット浮動小数点数)で表現されますが、Compressed EmbeddingsはINT8(8ビット整数)またはバイナリで表現します。これらのデータはFP32よりもサイズが小さく、ベクトルデータベースへの負荷や検索の時間的・費用的コストを抑えることが可能です。生成AIアプリケーションの大規模展開を考えるとベクトルデータベースへの負荷が課題になるケースがあり、そういった場合に検討できる対策のひとつといえます。 Amazon SageMakerでフルマネージドなMLflow機能を提供開始 MLflowは機械学習のライフサイクル管理で利用されるオープンソースツールのひとつです。今回、SageMakerでフルマネージドなMLflowのトラッキングサーバーを利用できるようになりました。MLflowへのアクセスはAWS IAMによって制御可能で、開発者の方は使い慣れたMLflowを利用した実験・分析を容易に実行できます。 Amazon SageMaker HyperPodがクラスタストレージのカスタマイズに対応 Amazon SageMaker Hyperpod はモデルの分散トレーニングのためのインフラストラクチャの構築と最適化を容易にする仕組みです。今回、SageMaker Hyperpodで構築されるクラスタのストレージがカスタマイズ可能になり、一般的なユースケースよりも大容量のストレージを必要とする場合にも対応できるようになりました。 Amazon SageMaker JumpStartで基盤モデルに対する詳細なアクセス制御が可能に Amazon SageMaker JumpStartは生成AIを支える基盤モデルをなど学習済みのモデルをすぐに起動できる枠組みで、機械学習に関するタスクを素早く始めることを可能にするハブとして機能します。今回、管理者が組織内のユーザに対して利用できる基盤モデルを細かく制御できるようになりました。SageMaker SDKを利用してSageMaker JumpStartにプライベートなハブを作成し、ユーザが利用してよいモデルだけを登録できるようになりました。これによって、例えばApahce 2.0ライセンスのもののみ触って良い、といったルールを適用することが容易になります。 Amazon CodeCatalystでブループリントの選択にAmazon Qを活用可能に Amazon CodeCatalyst はAWSで稼働するシステムの構築・開発を迅速化する統合ソフトウェア開発サービスです。CodeCatalystを利用して開発を開始する方法のひとつが、プロジェクトのひな形のようなブループリントを利用する方法です。これまではブループリントの説明文を読んで適しているものを判断する必要がありましたが、Amazon Qとの統合により自然言語でプロジェクトの概要を説明することで、適したブループリントを提案してくれるようになりました。 Amazon CodeCatalystがAmazon Qによる問題分析と推奨されるタスク分割の出力に対応 Amazon CodeCatalystがAmazon Qとの統合を強化し、問題の分析と推奨されるタスク分割を提案することが可能になりました。従来、プロジェクトにおけるタスクは主導で作成する必要がありましたが、今回のアップデートで問題の複雑さをAmazon Qに分析させ、作業を詳細タスクに分割するアイデアを提示してもらうことが可能になりました。 Amazon CodeCatalystがGitHub CloudとBitbucket CloudとAmazon Qの連携に対応 Amazon CodeCatalystで、GitHub CloudやBitbucket Cloudに保存されたソースコードレポジトリに対してAmazon Qによる開発支援が可能になりました。CodeCatalystで管理されるタスクをAmazon Qに割り当てることによって、これらのサービスで保存されるコードを分析し、対応計画を作成し、プルリクエストを生成できます。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

本ブログは、株式会社ココペリと Amazon Web Services Japan が共同で執筆しました。 株式会社ココペリ は「中小企業にテクノロジーを届けよう」というビジョンのもとサービスを提供しています。より多くの価値提供を行うための活動が実施されており、提供サービスの一つである 中小企業 DX 支援プラットフォーム「Big Advance」 の体験向上を狙う施策も期待されていました。 Big Advance にはビジネスマッチング機能やホームページ作成など複数の機能が搭載されています。これらの機能が有効に活用されることで、利用者のビジネス課題が効率よく解決されることに寄与します。ココペリ社は、利用者がより効率よく機能を活用できるように AI/ML 技術を使った施策を検討し価値提供を試みていました。一方で、AI/ML の活用は技術的な側面のみならずビジネス視点での成長戦略が必要です。Big Advance 利用者への価値提供とともにココペリ社の成長が行えるような AI/ML の活用施策の考案が求められていました。 ML Enablement Workshop による生成 AI のユースケースの特定 このような背景から、ココペリ社は AWS とともに  ML Enablement Workshop (MLEW) を実施しました。MLEW は AWS が開発しメンテナンスしているワークショップです。このワークショップは、プロダクトを AI/ML によって成長させるロードマップの作成を支援します。MLEW では、技術者だけでなくプロダクトマネージャーに代表される企画・ビジネス側の役職も交えた議論が行われます。ココペリ社は、データサイエンティスト、エンジニアやプロダクトマネージャーに加えて、カスタマーサクセスも参加し議論を行いました。 ココペリ社は MLEW での顧客体験分析を通じて、Big Advance のビジネスマッチング機能に着目し、生成 AI のユースケースを特定しました。ビジネスマッチング機能は、自社のビジネス上の要望を「ニーズ」として登録し、Big Advance 上に公開することができるものです。公開すると、6万を超える全国の会員企業がそのニーズを閲覧し商談を申し込むことができるため、販路拡大や新規取引先の開拓が期待できます。 効率の良いビジネスマッチングを行うには各企業が自社の特徴を捉えたニーズを作成することが重要ですが、一からニーズの文章を書き上げるのはハードルが高いことが示唆されました。 このことからニーズ作成のハードルの高さを解消することを目標とし、生成 AI によるニーズ自動作成を重要度の高い施策として検証を開始しました。 役職を横断した連携が可能にした生成 AI の検証 生成 AI による課題解決の検証では、成果物の評価が重要になります。今回の検証の評価は、MLEW に参加したカスタマーサクセスとの強固な連携によって実施されました。 生成 AI によるニーズの自動作成では、出力されたニーズの文章が登録する企業の特徴を捉えたものであるかが評価軸になります。これらの評価には顧客の実務に基づいた評価が必要になります。ココペリ社においてはカスタマーサクセスが顧客の実務を深く理解しているため、カスタマーサクセスが成果物を評価することが有効な判断軸であると言えました。今回の MLEW においてはカスタマーサクセスが参加したことで、これらの連携が円滑に行えています。 ニーズ作成の精度向上を行うために、処理の追加や複数の大規模言語モデルの比較などを行いました。最終的に、生成 AI への入力データとして事前のスクレイピングなどを行い（下図参照）、また Amazon Bedrock で利用可能な Anthropic 社 が提供する大規模言語モデル (LLM) Claude 2.1 を利用することで、社内の評価で 97.9% の採択率となりました。 このワークフローによって出力された結果は以下のようになっており、企業の特徴を捉えた具体的な内容を出力することができているとの評価となりました。 [詳細] 【事業の詳細】 金融機関が連携し、都道府県や金融機関の垣根を超えたビジネスネットワークで、中小企業の経営課題の解決を支援いたします。ビジネスマッチング、ビジネスチャット、ホームページ作成等の機能を月額定額で提供しております。 【キャッチコピー】 ビジネスをもっとシンプルに、楽に #ITサービス #中小企業 #金融 [対象] 中小企業 [ひとことメッセージ] 【事業の強み】 全国の金融機関との連携 【事業への思い】 中小企業の成長支援に情熱を注いでおります 【価格目安】 月額3,300円(税込) 以上の試みは ビジネスマッチングでの Claude による文章生成 に、より詳しく記載されています。 上記のワークフローは複数の処理が実行されますが、 AWS Step Functions や AWS Lambda といった AWS のサービスと Amazon Bedrock の連携によって、ワークフローの自動化を実現しています。 今後の展望 検証結果を受けてニーズ生成機能の社内利用を開始しており、今後はワークフローを洗練した上でプロダクトへの機能実装を計画しています。この技術を活用、改善していくことで精度の高いニーズを容易に作成できるようになり、Big Advance のビジネスマッチングにおける顧客体験をより向上させることを目指していきます。 まとめ 以上のようにココペリ社は MLEW での分析を通じ、Big Advance の顧客に最もインパクトのある生成 AI のユースケースを特定し、その検証を行いました。同社からは「MLEW での顧客体験分析を通じ、Big Advance の顧客に最もインパクトのある生成 AI の用途を特定しタスクと効果測定 KPI を決めることができました」との言葉を頂いています。 検証では、MLEW を通して技術・ビジネスの双方の領域の参加者が強固に連携し、顧客体験に寄り添った精度評価を行うことができました。ココペリ社では、今後も役職を横断した連携と AI/ML 技術、 AWS のテクノロジーを活用し、中小企業のビジネス支援を推し進めていく考えです。

本記事は 2023年11月26日に AWS DevOps Blog で公開された ” Automate safe AWS CloudFormation deployments from GitHub ” を翻訳したものです。翻訳は Partner Sales Solutions Architect の 福井 敦 が担当しました。 AWS CloudFormation は、Infrastructure as Code (IaC) サービスで、AWS およびサードパーティのリソースをモデル化、プロビジョニング、管理できます。新しくトラッキングしている Git リポジトリが更新されるたびに、 Git 同期 によって自動的にデプロイメントがトリガーされるようになりました。 これにより、開発者は Git ワークフローに統合し、コンテキストの切り替えによる時間の浪費を減らすことで、CloudFormation の開発サイクルを大幅に高速化できます。この新しい Git 同期は、 GitHub 、 GitHub Enterprise 、 GitLab 、 Bitbucket に対応しています。 この投稿では、GitHub のネイティブツールと CloudFormation の Git 同期を使った最新の開発体験について説明します。 GitHub CodeSpaces を使用してクラウド開発環境を作成し、 GitHub Actions と CloudFormation Linter を使用して プルリクエスト に直接フィードバックし、安全なデプロイを自動化します。 要件 AWS アカウントを所有していること。 Amazon Virtual Private Cloud (Amazon VPC) リソースをデプロイします。AWS アカウントには通常リージョン毎に 5 つまでの VPC が作成できますが、制限を引き上げることが可能です。 GitHub アカウントと、 Codespaces 、 Actions を利用できること。これらは無料利用枠がありますが、制限を超えると課金される可能性があります。 デベロッパーツールで GitHub への接続を作成 しておくこと。 空のリポジトリの作成 今回は、新しい GitHub リポジトリから始めます。GitHub では無料で新しい Git リポジトリを作成できます。この例では、 git-sync という名前のリポジトリを作成します。 Codespace の設定 リポジトリを作成すると、Codespace を作成するオプションが表示されます。Codespace は GitHub が管理するリモートの開発環境で、設定済の仮想マシン環境でどこからでも開発できます。 Codespaces は、 Visual Studio Code を選択したコードエディターとして利用します。Visual Studio Code は拡張機能をインストールできるため、非常に柔軟で拡張性に優れたオープンソースのコードエディターです。 作成が完了したら、ローカルの開発環境と同様に環境を設定できます。テンプレート開発時に、エディタ内で即座にフィードバックを得られるよう CloudFormation Linter 拡張機能を追加します。 これにより、検証のためテンプレートを CloudFormation に送信する必要はなく、送信する前にテンプレートが有効であることを確認できます。コマンドラインと Visual Studio Code 拡張機能の両方でインストールを行います。ターミナルで次のコマンドを実行してください。 pip3 install cfn-lint インストールされたら、拡張機能パネルで CloudFormation Linter をインストールできます。 次に、ベースディレクトリに vpc.yaml という名前のテンプレートを作成します。 入力を始めると、 CloudFormation Linter が推奨事項とオートコンプリート機能を提供します。 次のテンプレートを新しく作成した vpc.yaml ファイルにコピーしてください: AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 このテンプレートは、CIDR ブロック 10.0.0.0/16 の VPC を作成します。 テンプレートにエラーがないことを確認するには、ターミナルで cfn-lint を実行し、エラーが返されないことを確認します。 cfn-lint -t vpc.yaml デプロイファイルの追加 Git 同期では多様なデプロイメントをサポートするため、Git リポジトリから CloudFormation スタックを管理するための柔軟性を提供する スタックデプロイファイル をサポートしています。 この設定ファイルは、テンプレートファイルの場所、使用したいパラメータやタグの管理を行います。 パラメータやタグの管理には、このスタックデプロイファイルを使うことを強くお勧めします。監査や決定論的なデプロイメントが容易になるためです。 リポジトリ内に deployment-file.yaml という新しいファイルを作成します。このスタックにはパラメータやタグがないため、シンプルです。 template-file-path: ./vpc.yaml 後からコンソールでこのファイルを追加することもできます。 Pull Request アクションの追加 これで開発環境の設定が完了しました。次はプルリクエストを送るだれもが、ローカルで受けているのと同じようなフィードバックを受け取れるようにしたいと思います。 GitHub Actions を使えば、これが可能になります。GitHub Actions は、プルリクエストフィードバックと CI ビルドを自動化する、カスタマイズ可能なワークフローツールです。 次のようなディレクトリとファイルを作成します。 .github/workflows/pull-request.yaml このファイルの内容は以下のとおりです。 name: Pull Request workflow on: - pull_request jobs: cloudformation-linter: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Linter install uses: scottbrenner/cfn-lint-action@v2 with: command: cfn-lint -t ./vpc.yaml この設定により、プルリクエストに対して linter の結果がフィードバックされるようになります。作業内容をリモートブランチにプッシュしてください。 git add -A git commit -m "add pull request linting workflow, add base vpc template" git push origin main これから VPC にサブネットを追加しますが、 VpcId ではなく VpcName という無効なプロパティを意図的に追加します。 AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcName: ! Ref VPC CidrBlock: 10.0.0.1/16 ローカルの linter は、これが無効であることをすぐに指摘します: これらは今のところ無視してかまいません。プルリクエストを作成するには、新しいブランチを作成し、ローカルの変更をコミットする必要があります。以下のコマンドを実行してください。 git switch -c add-subnet git add -A git commit -m "add subnet" git push origin add-subnet これらのコミットをプッシュすると、GitHub から main ブランチに対するプルリクエストを作成できるようになります。 ただし、プルリクエストを作成すると、GitHub Actions の実行が終わったときにチェックが失敗したことがわかります。 「Files changed」タブを確認すると、どこが間違っているかがわかります。Linter アクションはプルリクエスト上で直接フィードバックを提供し、 ブランチ保護 を設定した場合はマージのアクションをブロックします。 このリポジトリでは、少なくとも 1 人のレビュアーと全てのチェックの成功が必要なので、これら両方の失敗を解決しなければなりません。 フィードバックと問題があった行番号を取得できたので、テンプレートに戻り、 VpcName を VpcId に修正しましょう。 AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcId: ! Ref VPC CidrBlock: 10.0.0.1/16 ローカルの linter は問題ありません。コミットしなおすと、リモートの linter も同様に問題がないことを確認できます。レビュアーからの承認を得た後、コミットを main ブランチにマージできます。 Git 同期の有効化 開発環境が整い、プルリクエストの過程でテンプレートがマージ前に Lint されるようになりました。 main ブランチに到達した CloudFormation テンプレートはデプロイの準備ができています。 次に、新しく公開された CloudFormation の Git 同期を利用して、デプロイされたスタックを新しいテンプレートに自動的に同期させます。 まず、CloudFormation がスタックをデプロイするために必要な IAM ロール を作成します。このロールは、CloudFormation がデプロイするリソースを制御します。ロールの名前は後の手順で使用するので控えておきましょう。この例ではロール名を vpc-example-cloudformation-deployment-role とし、次の許可ポリシーを設定します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpc", "ec2:CreateSubnet", "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DeleteVpc", "ec2:DeleteSubnet", "ec2:ModifySubnetAttribute", "ec2:ModifyVpcAttribute" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": ["cloudformation.amazonaws.com"] } } } ] } ロールを作成したら、次はスタックを新しく作成します。 こちらでは、新しいオプション Sync from Git を選びテンプレートのソースを設定します。既にスタックデプロイファイルを作成済みのため、 I am providing my own file in my repository. を選択します。 次に、Git 統合を設定してリポジトリを選択します。あらかじめ作成したデベロッパーツールの Github への接続を使用し、リポジトリを選択する必要があります。 GitHub 、 接続 、 リポジトリ 、 ブランチ 、 デプロイファイルのパス を選択してください。 最後に 新しい IAM ロール を選択して、サービスマネージドロールを作成します。このロールにより、Git 同期がリポジトリに接続できるようになります。この作業は 1 回限りで、今後はここで作成する既存のロールを使用できます。 次のページでは、このスタックをデプロイするために必要な作成済の IAM ロール vpc-example-cloudformation-deployment-role を選択します。このロールは、CloudFormation がデプロイするリソースを制御します。このように、Git 同期によってスタックを管理するには、事前にロールを作成しておく必要があります。 最後に、「Git と同期」タブで、設定内容、同期のステータス、プロビジョニングのステータス、そして必要に応じて同期の再試行や接続解除が可能であることを確認できます。 結論 この投稿では、CloudFormation テンプレートの作成および更新時にフィードバックを得るためのリモート開発環境を設定しました。プルリクエストを作成する際も同様に、フィードバックを得られます。テンプレートが main ブランチにマージされると、自動的にスタックにデプロイされます。このように、AWS リソースを Infrastructure as Code として管理するための、堅牢で拡張性のある CI/CD システムが構築されました。この Git 同期についてのフィードバックをお待ちしています！ 著者について Dan Blanco Dan is a senior AWS Developer Advocate based in Atlanta for the AWS IaC team. When he ’ s not advocating for IaC tools, you can either find him in the kitchen whipping up something delicious or flying in the Georgia sky. Find him on twitter (@ TheDanBlanco) or in the AWS CloudFormation Discord .

本記事は 2024 年 5 月 9 日に公開された ” How Can You Build a Culture of Experimentation? ” を翻訳したものです。 世界中の何百人もの企業幹部と話をしたところ、彼らは迅速に行動してイノベーションを起こすというアイデアは気に入っているものの、企業のレガシーシステムや制約の中でそれを実現するのは難しいと感じていることがわかりました。生成 AI の可能性を考えると、迅速なイノベーションは急務です。しかし、イノベーションを促進するには、実験が容認されるだけでなく、当たり前の文化を築く必要があります。 この記事では、低コスト、低リスク、低摩擦で、企業に大きな利益をもたらす実験を奨励する文化を徐々に築いていく効果的な方法を説明します。私が NASA のジェット推進研究所 (Jet Propulsion Laboratory: JPL) の IT 最高技術・イノベーション責任者を務めていたときに、この方法がうまくいっていました。JPL の実験文化のおかげで、チームは現在の宇宙ミッションにクラウドを利用するようになりました。これにより、より迅速な意思決定が可能になり、必要に応じて方向転換できるようになりました。迅速な実験は、拡張現実、3D プリント、データ視覚化、大規模な機械学習の民主化など、多くの新しいテクノロジーの導入にもつながりました。既存の従業員、インターン、新入社員がこれらのイノベーションを迅速かつ安価に導入できたことは、組織全体の助けとなり、実験者のキャリアに大きな利益をもたらしました。 実験の文化を築くために、最初に組織で実施する実験と実施しない実験を定義します。これにより、期待値を定め、十分な開発と管理を行わずに提案した実験が、本番環境に移行してしまう恐れを軽減できます。 次に、2 週間以内に解決できる可能性の高いビジネス上の問題を選びます。テクノロジーや特定のソリューションではなく、お客様のニーズから逆算して、実際のビジネス上の問題に集中します。ソリューションは時間とともに進化します。洞察につながる成功指標を決定するには、実験者に希望する結果を説明した 1 ページまたは 2 ページの資料を渡してもらい、各実験後の結果をもとに更新してもらいます。これらのビジネス上の問題を、将来の実験者がトレーニングやイテレーションのためにアクセスできるユースケースのライブラリに保存してください。これは、従業員が小さいながらも実際のビジネス上の問題を解決しながら新しいスキルを学ぶ素晴らしい方法です。 第三に、ビジネス組織と機能組織全体にわたる実験者を見つけましょう。多くの組織は、関心と知識が豊富な人材がいることに驚きます。新しいことに挑戦するには、承認と激励が必要です。たとえば、処方的分析の専門家は、AI、機械学習、生成AIを簡単に導入できます。 第四に、部門横断的なアプローチをとりましょう。少なくとも 1 人の IT 従業員、関心のある事業部門のエンドユーザー 1 人、またアドバイスや啓発を行うサイバーセキュリティ専門家で構成される 2 人から 4 人のチームを選任します。 第五に、実験の成功を測定します。投資利益率 (Return On Investment: ROI) の測定に固執しないでください。ROI 文書の作成には、実験の実施にかかる時間よりも多くの時間と費用がかかります (そして勢いを失います)。エンドユーザーコミュニティからの Return On Attention (ROA)、つまり影響を受けるエンドユーザーからの関心度を測定します。ROA を 1 ～ 10 の範囲で評価します。10 は 100% 積極的でポジティブな関心であることを示します。JPL では、少なくとも 2 つのエンドユーザーコミュニティから 8 ポイントを獲得すれば、投資資金が得られることが分かっていました。それから、ROI を測定し、完璧 (またはそれに近い) に向けて繰り返すことができるのです。私は他の企業と協力して同様のアプローチを開発することに成功しました。このようにすることが、問題に最も近い人、そしてしばしば解決策を持っている人がいるような組織の端から創造性を解き放つことに役立ちます。 第六に、実験の話をします。新しいテクノロジーでビジネス上の問題を解決したら、対面デモを行い、複数のデモを紹介するオープンハウスを開催することを検討してください。注釈付きのデモを録画して、セルフサービスの視聴機能を作成します。自分の取り組みが金メッキの科学実験だという批判を避けるために、自分がプロのビデオグラファーではないという期待値を設定することが重要です。特に他のエンドユーザーコミュニティが彼らの意見を受け入れる可能性が最も高いので、エンドユーザー (ビジネス) 参加者の功績を称えることを忘れないでください。そうすれば、将来の実験への参加に対する需要が高まります。ソーシャルメディアやアワードプログラムを利用して、参加者に利益をもたらしましょう。 このアプローチに従えば、始めるのに多額の予算は必要ありません。予算が多すぎると、ソリューションが複雑になりすぎます。時間をかけすぎると、新たに発生するビジネスクリティカルな問題が原因で主要な実装担当者を失うことになります。高い結束力と集中力を確立するために、2 週間 2 ～ 4 人だけで始めましょう。最も成功している企業では、許可を求めることなく利用できる少額の予算を CIO/CTO や事業部門が設定しています。大胆な人には、10 倍の ROI を約束してください。予算を得るのに役立ちます。JPL ではその目標を達成するのに何の問題もありませんでした！ また、エリート主義や反感を助長する可能性があるため、「唯一無二」のイノベーショングループを設立することも避けてください。エンドユーザーと一緒にイノベーションを起こし、自由に賞賛を贈ってください。自社で考えるべきことを外部に委託することは避け、特定の技術の専門家と手を組み、自分でビジョンを維持しましょう。コンプライアンスコントロールを含む自動化により、実験をより簡単かつ迅速に行うことができます。気づかれないように実験を行い、成功してから公開することを検討してください。そうすれば、実験への恐れが減ります。事業を変革できる可能性のある、潜在的に無限の利益をもたらす低リスク、低コストの実験を行っていることを関係者に思い出させましょう。 実験の文化で成功するには、ビジネスの成果がすべてです。 各実験はストーリーを伝え、簡単に元に戻せるものでなければなりません。これにより、リスクと反対意見が減ります。実験における唯一の本当の失敗は、あなたの組織が何も学ばないことであり、私たちはそれが起こるのを見たことがありません。上記の手順は、組織全体のすべてを一度に変更する必要がないため、既存の企業でかなり簡単に試すことができます。ビジネスプロセスを何度も 10% 改善できれば、会社に大きな変化をもたらすことができます。組織は楽しく働ける職場となり、社内のアイデア形成や人材の採用、再教育、定着に役立ちます。そして、それはたしかに価値のある目標です。 ご意見、結果、アイデアをお聞かせください。 Live long and experiment! この記事は、カスタマーソリューションマネージャーの仁科 みなみが翻訳を担当しました。原文は こちら です。

本記事は 2024 年 4 月 11 日に公開された ” KPIs – Enterprise Journey from Technology to Business ” を翻訳したものです。 以前の ブログ記事 で説明したように、AWS は、KPI (Key Performance Indicators: 主要業績評価指標) が明確に定義され、追跡され、調整された組織が、クラウドトランスフォーメーションのジャーニーで成功していると理解しています。しかし、KPI を定義して追跡することは難しい課題です。組織が連携して成果を追跡し、そうすることに価値があるとしても、最初から KPI に注目することが難しい組織もあります。 このブログ記事では、架空の企業 (AnyCompany) が KPI を導入するまでのジャーニーを、複数の顧客とともに取り組んだ実際の経験に基づいて説明します。大規模な企業組織である AnyCompany は、営業利益と売上の向上を目指していました。まず、コストの最適化、総所有コストの削減、技術的負債の回収、将来の機能のための基盤構築を実現するために、オンプレミスのデータセンターを廃止し、アプリケーションをクラウドに移行することから始めました。彼らが採用した未来が、ビジネスの成長と変革を後押ししました。 ビジネス KPI を使ってクラウド導入の効果を追跡する AnyCompany のビジネス目標と現在の文化、プロセス、ガバナンスを理解した上で、ビジネス KPI の導入を促進するために Crawl (ハイハイ)、Walk (歩く)、Run (走る) のアプローチを推奨しました。最初の Crawl フェーズでは技術 KPI から始めて、次の Walk フェーズでビジネス KPI を導入して初期の摩擦を乗り越え、最後の Run フェーズでは徐々にすべてのビジネス KPI に移行します。Crawl フェーズの焦点は、ワークロードをクラウドに移行することで技術的負債を軽減することです。戦術的な KPI は、ワークロードのリプラットフォームとリアーキテクチャの効果的な追跡と進捗報告を確実にします。Walk フェーズでは、クラウド導入技術とコスト削減の成果をビジネス部門のビジネス成果に結び付けます。Run フェーズでは、組織が社内のマーケティングと社内のビジネスアプリケーション開発チームからの肯定的なフィードバックを通じて成功を収めた後、外部のクライアント対応チームは、クライアントにも同様の結果をもたらすという見通しを持ってモチベーションを高めます。これにより、人、プロセス、テクノロジー、ビジネスの観点から組織全体の変革を促進するプラスのフライホイール効果が生まれます。 Crawl フェーズ — 技術 KPI を追跡し、測定する このフェーズでの主な焦点はテクノロジー、つまり技術的負債を減らし、クラウドの導入を増やすことです。このフェーズの KPI は、次の表に示すように、コスト削減、トレーニングを受けたスタッフの数、移行されたアプリケーションの数、運用上の優秀性などのメリットの測定に重点を置いています (表 1)。組織はこの段階では社内の KPI に重点を置き、IT 以外の社員に進捗状況をすぐに伝えます。これにより、KPI の測定、追跡、共有というマッスルメモリー (条件反射的に意識せずに行動できること) が生まれます。KPI は、完了までの期間が複数の四半期または数年にわたる場合に有効です。サイロ化された構造のため、AnyCompany ではこのステップが必要でしたが、他の組織では次の段階にすばやく移行し、勢いをつけるために Crawl フェーズを必要としない場合があります。 表1　Crawl フェーズの KPI と影響 メリット 目的 測定 影響 コスト削減 データセンターの廃止 マネージドサービスプロバイダー (MSP) のデータセンターから廃止されたサーバー数 IT 支出を詳細に確認することによる的を絞った最適化の取り組みが可能 インフラストラクチャ支出のより正確な予測 オンプレミスとクラウドのコスト削減 (ビジネスケース) オンプレミスとクラウドのサーバー数 オンプレミスとクラウドのコスト コストの前年比 (YoY) ダウンタイムの削減 使用されていないアプリケーションを廃止することでアプリケーションフットプリント (リソース使用量やシステムに与える影響など) を簡素化 廃止されたアプリケーションの割合 技術的な問題が顧客に影響を与える前にプロアクティブに解決 ピークアプリケーション使用時のパフォーマンス低下なし (オートスケーリング) アプリケーション停止回数の減少 技術的負債の除去 サポートされた OS 上で稼働するアプリケーションの割合 サポートされたデータベース上で稼働するアプリケーションの割合 運用上のメトリクスの改善 オンプレミスとクラウドの平均検出時間 (MTTD) の基準 プラットフォームやリホストの性能改善 オンプレミスとクラウドのピーク負荷時におけるアプリケーション性能の基準 計画外のシステム停止回数の削減 オンプレミスとクラウドのシステム停止回数の基準 AnyCompany は、Crawl フェーズ中に前の表 1 の KPI を使用して、オンプレミスアプリケーションの約 25％、コストのかかるレガシーデータベースとサーバーの約 50％ を廃止しました。さらに、複数のデータセンターを閉鎖し、セキュリティとオブザーバビリティを向上させ、モダンアプリケーション開発プラットフォームを構築しました。 Walk フェーズ — ビジネス KPI を徐々に導入する この段階では、組織はビジネス成果をテクノロジードライバーに結び付けます。Crawl フェーズで確立された KPI を拡大するにつれて、徐々に変化していきます。目標は Crawl フェーズですべての KPI を完成させることではなく、チームがメトリクスを活用し、継続的な改善とステークホルダーとの透明性を維持できる状態に移行する能力に注目することが目標であることに注意してください。次の表 2 に示すように、初期の KPI セットを取りこんで、自動化された環境プロビジョニングを追加するなど、それらを拡張することになります。これにより、開発者はインフラストラクチャの管理から解放され、デプロイの失敗が減り、機能の強化やより価値のあるタスクに集中できるようになります。ここでは、副次的な目標としてビジネスインパクトの測定から始めたいと思います。初期の KPI には完了までの明確な道筋があり、チームにこれらの新しい KPI を意思決定プロセスで使用してもらうために、チームに KPI を導入する機会を探してください。 AnyCompany は現在、クラウドへの移行を順調に進めており、このフェーズの一環として移行の先を見据えています。彼らは、クラウド移行の過程ですでに測定されていた技術 KPI にビジネス成果を追加しました。企業全体とのコミュニケーションを継続することで、企業のステークホルダーは、移行によって自社のビジネスがどのようにプラスの影響を受けているかを理解できるようになりました。表 2 は、追跡対象の技術 KPI がビジネスに与える影響を示しています。 表2 Walk フェーズの KPI と影響 メリット 目的 測定 影響 ダウンタイムの削減 コードで運用されるアーキテクチャの増加 自動化された環境プロビジョニング数 開発者が機能強化に費やせる時間の増加 デプロイ失敗の減少、つまり、同じ作業を繰り返すことの減少 報告された問題に対するより早いレスポンスタイム デプロイの効率性 自動化されたアプリケーションのデプロイ数 デプロイ成功率 デプロイガバナンスの合理化 デプロイガバナンスプロセスの評価 テスト自動化の割合 オンプレミス、クラウド、クラウドネイティブプラットフォームのデプロイ時間 コスト削減 クラウドネイティブプラットフォームに移行することでリプラットフォームやリファクタリングの準備ができているアプリケーションのモダナイズ クラウドネイティブプラットフォームのアプリケーションの割合 本番環境で報告された不具合に対するレスポンスの増加 本番環境での不具合数の減少 顧客へのプロダクト強化提供数の増加 デプロイ中のダウンタイムの排除 アプリケーションセキュリティの改善 (自動化されたセキュリティスキャン) AWS のマネージドデータベースの割合 機能のサイクルタイム (機能リクエストを本番環境に実装するまでの時間) デプロイ数の前年比 (YoY) 本番環境で報告された不具合数 Run フェーズ — 時間とともにビジネス KPI を追跡、測定、発展させる この段階では、長期的なビジネス上のメリットが実現されつつあり、移行の最初の部分も終わりに近づいています。この時点で、組織はクラウドで成熟しています。初期の戦術的な測定 は、次の表 3 に示すように、組織のビジネスに直接影響する KPI に置き換えられています。これには、売上増加、業務オペレーションの競争上の優位性確保と効率化、営業利益の増加、市場シェアの増加、新しい収益セグメントが含まれます。組織は機能リリースなどのアウトプットとビジネスを推進する成果の関係を理解しています。また、成果を測定すると同時に、その実現のためにどのような機能を追加する必要があるかを調べます。 表 3 Run フェーズの KPI と影響 メリット 目的 測定 影響 効率化 開発者の請求対象外時間 (直接的には収益を生まない時間) の削減 デモや概念実証の労力を軽減し、プリセールス時間を追跡 従業員の生産性向上 AWS CloudFormation テンプレートのような再利用可能なアセットがチームを横断して共通的なワークロードに活用され、チームは付加価値のある作業と差別化されない作業に注目 タグ付けされたアセットやアクセスの追跡 アジリティ (俊敏性) より強いガードレールや舗装された道を提供して、プロジェクト内でジュニアレベルとシニアレベルのエンジニアが一緒に取り組むことができる。経験の浅いスタッフをより迅速に増員できる。 Amazon CodeWhisperer (2024 年 6 月現在では、Amazon Q Developer) のような新しいツールの導入とアウトプットの測定 新人のオンボーディングプロセスの迅速化 イノベーション クラウドネイティブソリューションに基づくクライアントオファリングへの新しい機能追加 (グローバル化、レジリエンシー、サステナビリティ) 顧客による新しい機能のフィードバックスコア 新しい収益源 この段階で、AnyCompany はテクノロジーの観点からクラウドトランスフォーメーションについてある程度の成熟度を達成し、現在は、完了しようとしている作業に関連するビジネス KPI との結び付けと測定に注力しています。ビジネスの変革を可能にする機能や特徴に焦点を当てながら、技術的負債が野放しにならないようにするためのメカニズムとガバナンスが整っています。このフェーズは継続的な道のりであり、ビジネス戦略と IT 戦略を結びつけることで、AnyCompany がマーケットリーダーとしての地位を確立し、コラボレーションを改善できるようになります。 結論 このブログ記事では、AnyCompany がトランスフォーメーションのジャーニーの初期から採用しているアプローチを紹介しています。現在の状況にかかわらず、これらの手順に従うことで、勢いを維持または回復し、一貫した進歩を遂げることができます。KPI を継続的に強化することを目標に、徐々にビジネス KPI に置き換えることができる技術 KPI を測定して共有するメカニズムを構築するための段階的アプローチについて説明しました。 この記事は、カスタマーソリューションマネージャーの仁科 みなみが翻訳を担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、 Microsoft SQL Server データベースの運用と管理を簡素化する AWS マネージドデータベースサービスです。Amazon RDS for SQL Server は、SQL Server データベースのプロビジョニング、管理、モニタリングを行うことで価値をもたらします。このような運用上の俊敏性は価値がありますが、データベースを物理データセンターの外部に移行するリスクを考慮すると、データ保護とセキュリティはさらに重要になります。Amazon RDS では、SQL Server の 透過的データ暗号化 (TDE) 機能を採用できます。この機能は保存中のデータを保護し、アクセスを許可されたユーザーに制限しますが、転送中または使用中のデータは暗号化されません。 複数の AWS アカウントを使用することは、環境を論理的に分離するための一般的なベストプラクティスです。TDE 対応の SQL Server データベースを AWS アカウント間で管理する場合、データ保護を確実にするためのいくつかの重要な手順があります。この記事では、AWS アカウントをまたいで Amazon RDS for SQL Server インスタンス間で TDE 対応データベースを移行する手順について説明します。 前提条件 ここでは、お客様が Amazon RDS for SQL Server と SQL Server の TDE について事前に知識があることを前提としています。この記事では SQL Server 2019 エンタープライズエディションを使用しています。 この記事では、次の前提条件が必要です。 アカウント A とアカウント B の AWS アカウント で Amazon RDS for SQL Server の TDE オプショングループが有効になっていて、リソースを操作するための適切な権限があること AWS KMS キーを使用して作業するためのアクセス権 アカウント A とアカウント B の S3 バケット ソリューション概要 このソリューションでは、AWS アカウント A の Amazon RDS for SQL Server にある TDE 対応データベースをバックアップし、それをアカウント B の別のインスタンスに復元する必要があります。 AWS Key Management Service (AWS KMS) キーで暗号化された TDE 証明書も、ターゲットのインスタンスに復元する必要があります。ソースデータベースの TDE 証明書をバックアップするために使用される秘密鍵の暗号文は、アカウント A の KMS キーで復号化され、アカウント B の KMS キーで再度暗号化されます。 ソリューションを実装する大まかな手順は、アカウント A では以下の流れになります。 存在しない場合は、新しい対称暗号化 KMS キーを作成します。 AWS KMS キーを使用して TDE 証明書を Amazon Simple Storage Service (Amazon S3) バケットにバックアップします。 RDS for SQL Server データベースを S3 バケットにバックアップします。 プライベートキーファイルの S3 メタデータから ciphertext-blob を抽出します。 AWS KMS キーを共有します。 アカウント B で、次の手順を実行します。 アカウント A の暗号文を復号化し、平文のパスワードを抽出します。 アカウント B で新しい対称暗号化 KMS キーを作成し、そのキーでプレーンテキストのパスワードを暗号化します。 データベースをリストアする前に、アカウント B のターゲットインスタンスで TDE 証明書をリストアする必要があります。 アカウント B の Amazon RDS for SQL Server に対してデータベースをリストアし、AWS KMS キーを暗号化します。 次の図は、TDE 対応の SQL Server データベースをアカウント間で移行するためのソリューションアーキテクチャを示しています。 アカウント A の TDE 証明書と RDS for SQL Server データベースを S3 バケットにバックアップ AWS KMS キーを使用して RDS インスタンスの rds_backup_tde_certificate ストアドプロシージャを使用して、アカウント A の TDE 証明書をバックアップします。アカウント A の Amazon RDS for SQL Server では、次のサンプルコードを実行します。 以下は、アカウント A で実行されるステートメントの例です。 まず、sys.certificates システムビューにクエリを実行して TDE 証明書名を取得します。 USE [ master ] GO SELECT * FROM sys . certificates WHERE name LIKE 'RDSTDECertificate%' GO SQL 次に、KMS キーを使用して Amazon RDS TDE 証明書をバックアップします。 EXECUTE msdb . dbo . rds_b ackup_tde_certificate @certificate_name = 'RDSTDECertificate20230323T215533' , @certificate_file_s3_arn = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/mssql-inst02.cer’, @private_key_file_s3_arn = ’arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/mssql-inst02.pvk' , @kms_password_key_arn = 'arn:aws:kms:us-east-1:<ACCOUNTA-ID>:key/mrk-<Key ID>' , @overwrite_s3_files = 1 ; SQL 最後に、暗号化されたデータベースを Amazon S3 にネイティブバックアップします。 exec msdb . dbo . rds_backup_database @source_db_name = 'tpcc' , @s3_arn_to_backup_to = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/tpcc-native-backup.bak' , @overwrite_s3_backup_file = 1 , @type = 'FULL' , @number_of_files = 4 ; SQL 詳細については、「 SQL サーバーの透過的なデータの暗号化サポート 」を参照してください。 プライベートキーファイルの S3 メタデータから ciphertext-blobを抽出 以下のステップを完了します。 前のステップの S3 バケットに移動し、プライベートキーファイルのメタデータから ciphertext-blob をコピーします。これは x-amz-meta-rds-tde-pwd タグの下にあります。 暗号化操作を実行するアカウント B の root ユーザー、他のユーザーまたはロールと (TDE 証明書のバックアップに使用される) KMS キーを共有します 。 root ユーザーを使用する IAM ポリシーの例を以下に示します。 { "Sid" : "Allow an external account to use this KMS key" , "Effect" : "Allow" , "Principal" : { "AWS" : [ "arn:aws:iam::444455556666:root" ] } , "Action" : [ "kms:Encrypt" , "kms:Decrypt" , "kms:ReEncrypt*" , "kms:GenerateDataKey*" , "kms:DescribeKey" ] , "Resource" : “<ARN - FOR - KMS - KEY > ” } YAML 以下は、ロールを使用した IAM ポリシーの例です。 { "Sid" : "Allow an external account to use this KMS key" , "Effect" : "Allow" , "Principal" : { "AWS" : "arn:aws:iam::444455556666:role/ExampleRole" } , "Action" : [ "kms:Encrypt" , "kms:Decrypt" , "kms:ReEncrypt*" , "kms:GenerateDataKey*" , "kms:DescribeKey" ] , "Resource" : “<ARN - FOR - KMS - KEY > ” } YAML TDE 証明書 (.cer) とプライベートキー (.pvk) のバックアップファイルをアカウント A の S3 バケットからアカウント B の S3 バケットにコピーします。 アカウント A の暗号文を復号化して平文のパスワードを抽出 TDE 証明書のバックアップに使用した AWS KMS キー ID を使用して、アカウント A から受け取った暗号文を復号化します。以下は、暗号文を復号化してプレーンテキストのパスワードを取得する AWS Command Line Interface (AWS CLI) コマンドの例です。 AWS kms decrypt —key - id —ciphertext - blob —output text —query Plaintext —region YAML 復号化の詳細については、「 Decrypt 」を参照してください。 アカウント B で新しい AWS KMS キーを作成、そのキーをプレーンテキストのパスワードで暗号化 次のステップでは、アカウント B で新しい対称 AWS KMS キーを作成し、アカウント B の AWS KMS キーを使用して前のステップで復号化されたプレーンテキストのパスワードを暗号化します。AWS KMS キーに対するアクセス権限を持つ認証情報を使用します。次のコマンドは、前に復号化したこのプレーンテキストパスワードの暗号文を提供します。 aws kms encrypt —key - id <Provide KMS KeyID from Account - B > —plaintext "The output from the decrypt step" —output text —region <AWS Region > YAML 詳細については、「 対称暗号化 KMS キーの作成 」を参照してください。 次に、証明書とプライベートキーが保存されているアカウント B の S3 バケットに移動します。プライベートキーファイル (.pvk) を選択し、オブジェクトアクションに移動してメタデータを編集します。「ユーザー定義」タイプで x-amz-meta-rds-tde-pwd というタグを付けて暗号文の値を更新します。 データベースをリストア、アカウント B の Amazon RDS for SQL Server に対して AWS KMS キーを暗号化 データベースをリストアする前に、アカウント B の RDS for SQL Server インスタンスに TDE とネイティブバックアップとリストアが有効になっているオプショングループがあることを確認します。 以下のサンプルコードを使用して、新しく作成された AWS KMS キーを使用して更新された TDE 証明書をアカウント B の Amazon RDS for SQL Server にリストアします。 EXECUTE msdb . dbo . rds_restore_tde_certificate @certificate_name = 'UserTDECertificate_FromAcct1' , @certificate_file_s3_arn = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTB>/mssql-inst02.cer' , @private_key_file_s3_arn = 'arn:aws:s3::: <BUCKET-NAME-ACCOUNTB>/mssql-inst02.pvk' , @kms_password_key_arn = 'arn:aws:kms:us-east-1:<ACCOUNTB-ID>:key/mrk-<Key ID>' ; SQL ユーザー証明書に次のコードがロードされているかどうかを確認します。 SELECT * FROM msdb . dbo . rds_fn_list_user_tde_certificates ( ) ; SQL TDE 証明書が正常にリストアされ、Amazon RDS for SQL Server で検証されたら、データベースバックアップのリストアに進むことができます。以下は、アカウント B の S3 バケットから TDE 対応のバックアップをリストアする例です。 exec msdb . dbo . rds_ restore_database @ restore_db_name = 'tpcc' , @s3_arn_to_restore_from = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTB>/tpcc' , @with_norecovery = 0 , @type = 'FULL' ; SQL 後片付け 検証で作成した AWS リソースを削除するには、次の手順を実行します。 AWS マネジメントコンソール にサインインします。 RDS for SQL Server インスタンスが存在するリージョンを選択します。 Amazon RDS コンソールのナビゲーションペインで [データベース] を選択します。 作成された RDS インスタンスを選択します。 [アクション] メニューで [削除] を選択します。 Amazon S3 コンソールで、作成されたバケットを選択します。 [アクション] メニューで [削除] を選択します。 AWS KMS コンソールで、作成した KMS キーを選択します。 [スケジュールキー削除] を選択し、7 ～ 30 日間の期間を入力して、[スケジュール削除] を選択します。 結論 透過的データ暗号化は、データを保護するために SQL Server で一般的に使用されている組み込みの暗号化メカニズムです。この記事では、RDS for SQL Server インスタンスにある TDE 対応のデータベースを別のアカウントにある RDS for SQL Server インスタンスにリストアするためのソリューションを紹介しました。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Alvaro Costa-Neto は、AWS のデータベーススペシャリストソリューションアーキテクトで、お客様のクラウドでのデータベースソリューションの設計と実装を支援しています。彼はデータベーステクノロジーに長けており、19 年以上にわたり主に Microsoft SQL Server でデータベーステクノロジーに携わってきました。彼はフロリダ州クレルモンに妻と 2 人の子供と一緒に住んでおり、飛行機と旅行が好きです。仕事がないときは、家族や友人と BBQ を主催したり、新しい場所を探索したりしています。 Gopakumar Gopalakrishna Pillai は、アマゾンウェブサービスのデータベースエンジニアです。16 年間データベースに関わってきて複数のデータベーステクノロジーに取り組み、さまざまなお客様の問題に対するソリューションを提供してきました。RDS SQL Server のお客様に最適なデータベースソリューションを提供することに注力しており、その経験を活かしてお客様がサーバーレスアプリケーションを構築できるよう支援しています。自由時間には、新しい場所を探索するのが好きです。 Jeril Jose は、Microsoft SQL Server やその他のデータベーステクノロジーで 14 年以上の経験を持つデータベーススペシャリストコンサルタントです。お客様の AWS へのデータベースソリューションの設計、移行、最適化を支援しています。AWS に入社する前は、金融および小売部門にわたる生産およびミッションクリティカルなデータベースの実装をサポートしていました。

みなさん、こんにちは。シニアマイグレーションスペシャリストの富松です。 AWSジャパンでは、AWSへの大規模なシステムの移行を実現し、ひいてはお客様のデジタルトランスフォーメーションをサポートする 「 AWS ITトランスフォーメーションパッケージ（ITX） 」を2021年に、2022年には内容を強化・拡大した「 AWS ITトランスフォーメーションパッケージ2.0（ITX2.0） 」をリリースしました。2023年にはITXパッケージ2.0をより包括的に進化させた「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー（ITX 2023） 」をリリースし、2021年以来220社(2024年6月現在)を超える多くのお客様にご活用頂き、企業のITトランスフォーメーションを支援してきました。 今回のブログでは、ITX 2023を更に包括的に進化させ、2024年6月にリリースした、最新版の「AWS ITトランスフォーメーションパッケージ ファミリー（ITX）」をご紹介します。（ 最新版のITX資料ダウンロードはこちらから ） 生成AIの活用が企業の喫緊の課題に 近年、生成AIが画期的な技術革新をもたらしています。自然言語処理の生成AIから、画像生成AI、さらにはコード生成AIまで、様々な分野でイノベーションが生み出されています。企業においても、業務効率化や新規ビジネス創出に向けて、生成AIの活用が進んでいます。 PwCコンサルティングの「 生成AIに関する実態調査2023 秋 」によると、調査対象企業の87%が「既に生成AIの社内利用あるいは社外活用(その検討)を進めている」と回答。さらに43%が2024年3月までの生成AI本格導入を予定し、約58%は今後1年以内に導入を検討しているなど、導入に向けた動きが加速する見込みです。 しかし一方で、生成AIを実際のビジネスに活用する際には、大きく2つの課題が存在しています。 1つ目の課題は、データ基盤の整備です。AWSのVice President of Data and AIであるDr. Swami Sivasubramanianが「データは生成AIアプリケーション活用における差別化要因である」とre:Invent 2023において述べているように、生成AIモデルの入力データの質が重要になります。しかし、企業の多くではデータのサイロ化が進み、必要なデータが統合されていないのが実情です。 2つ目の課題は、生成AIの活用に必要なスキルやノウハウの不足です。同レポート「 生成AIに関する実態調査2023 秋 」では、生成AI活用において直面した課題の上位2つが「必要なスキルを持った人材がいない」「ノウハウがなく、進め方が分からない」となっています。従来の機械学習とは発想を転換する必要があり、社内人材のリスキリングや専門人材の確保が欠かせません。 企業のDXを支えるパートナー連携の重要性 デジタル変革を推進するうえで、クラウドへの移行はほとんどの企業が直面する大きなチャレンジです。DXに取り組む企業の約6割が上流工程などの内製化を志向していますが、ユーザー企業におけるIT人材不足が阻害要因となっています。依存度の高いシステムインテグレーターや専門コンサルティング会社との協業は必須不可欠です。 しかし単に顧客がパートナー企業に移行を任せるだけでは不十分です。つまり、パートナー企業がITをどのように活用すればお客様のDX推進につながるか、パートナー企業が深く理解する必要があります。「ITを使って何ができるのか」「どのようなアーキテクチャが適切なのか」といった視点から、クラウド上のシステム開発・運用を支援することが求められます。 また、システム開発やシステム運用を支援するパートナー企業は、既存プロジェクトの技術支援だけではなく、AWS環境全体の運用やアカウント管理 (リセール事業)、新規のシステム移行支援などでも顧客に貢献したいと考えています。 AWS ITトランスフォーメーションパッケージ （ITX）の最新版で、包括的な支援を実現 こうした企業の課題と要望を受け、AWSジャパンでは「ITトランスフォーメーションパッケージ(ITX)」の最新版を2024年6月20日にリリースしました。最新版のITXでは、クラウド移行、データ活用、生成AI導入の3つの側面から、デジタル変革の実現をワンストップで支援します。AWSの専門性とソリューション、AWSパートナーネットワークを最大限活用することで、包括的な支援を行います。 また、ITXパッケージはこれまで民間企業のお客様のクラウド移行を支援してきましたが、公共分野特有の要素を固有には取り込んでいませんでした。今回AWSの活用やガバメントクラウドへの移行を考える中央省庁や地方自治体といった公共のお客様と、そうしたお客様を支援する事業者様向けに従来のITXの内容を拡張し、5つめの支援パッケージとして、公共版ITXを近日中にリリース予定です。 最新版のITXでは、生成AI活用に向けた新サービスとして、ITX for Cloud Nativeにおいて、以下の2つを提供します。また、ITX for MCP Partnerにおける、パートナー連携を強化します。 データプラットフォーム検討支援「Data Platform Modernization Assessment(DPMODA)」 データプラットフォーム検討支援「Data Platform Modernization Assessment(DPMODA)」では、データドリブン経営や、自社データを生成AIで最大限活用することを目指すお客様に対して、AWSの専門チームがお客様の現行データ基盤を分析し、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示します。 データプラットフォーム検討支援を通じて、現行データ基盤の成熟度を把握することで、今後の戦略策定に活用できます。また、To-Beアーキテクチャ検討を通して、現行基盤の単純移行にとどまらず、クラウドでの機能強化のヒントが得られます。 生成AI活用ワークショップ「Innovation EBA(Experience-Based Acceleration)」 生成AI活用ワークショップ(Innovation EBA)は、アジャイル型のインタラクティブなアクティビティです。お客様は、組み込みのAWSサービスと規範的なガイダンスを利用して、ビジネス価値向上を達成するためにAI/MLモデルの構築や、生成AIのユースケース実践をすばやく実現できます。 具体的には、約6週間でAI/MLモデルや生成AIユースケースを開発・実行できるようサポートしたり、未活用のデータや技術から新たなビジネス価値を引き出すことができます。技術ではなく主要なビジネス課題の解決に焦点を当て、実践を通してAI/ML、生成AIのスキルを身に付けられます。さらに、お客様ビジネスに合わせたユースケース開発の加速も図ることができます。AI/MLや生成AIを事業戦略の中核に据え、経営陣の強力な後押しと変革への意欲があれば、より効果的です。ビジネスインパクトが大きく本番環境への展開が見込めるユースケース、生産性や顧客体験、成長分野でのAI/ML活用ニーズがあれば適しています。 ITX for MCP Partnerにおけるパートナー連携強化 AWS移行コンピテンシーパートナー（Migration Competency Partner＝MCP）とは、“移行コンピテンシー”を保有されているAWSパートナーの事を指し、基幹システムや業務アプリケーションのAWSへの移行において、調査から計画、移行、運用までのすべてのフェーズにおける専門知識、豊富な実績やソリューションを持つAWSパートナーを認定させていただくものです。そのようなMCPパートナー各社が提供しているプログラムと、ITトランスフォーメーションパッケージが従来より提供していたプログラムを組み合わせたものが、「AWS ITトランスフォーメーションパッケージ for MCPパートナー（ITX for MCP Partner）」になります。 ITX for MCP Partnerをご利用いただく事により、AWSが持つクラウド移行の様々なオファリングに加えて、MCPパートナーが持つビジネスに関する専門知識、移行およびモダナイゼーションのツールやオファリング、教育などのサポートを併用して受けていただくことができます。 MCPごとに提供内容は異なりますが、例えば移行の計画立案から実行、データ分析基盤の構築、AIシステムの開発、運用支援まで、DXの実現に向けた幅広い支援が受けられます。 2024年6月現在、SCSK、Classmethod、富士ソフト、NHNテコラス、TIS、TOKAIコミュニケーションズ、 CTC、サーバーワークス 各社のITX for MCP Partnerがリリース済みで、今後は他のMCP各社のITX for MCP Partnerも追加予定です。多様なパートナーと連携することで、企業のニーズにより適合したソリューションを提供できます。 ITXパッケージ最新版の始め方 ITXパッケージ最新版のご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITXパッケージ最新版にご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 富松卓郎

今回は、 AWS Fault Injection Service (FIS) を使ったアプリケーションのレジリエンス向上をテーマにした新しいワークショップ、Resiliency Quest をご紹介します。このワークショップでは、ゲーミフィケーションの要素を取り入れ、実際に手を動かしながら、AWS FIS の使い方とレジリエンスのベストプラクティスを楽しく学ぶことができます。レジリエンスに関する技術的な経験をお持ちの無い方でも参加できますので、ぜひお試しください。 Resiliency Quest とは？ Resiliency Quest は、ゲーム形式の体験型ワークショップです。参加者はアプリケーションを運用する架空の企業の一員として、AWS FIS を使ってアプリケーションに実際に障害を引き起こし、その対応策を学びます。これにより、インフラストラクチャのレジリエンスを高める方法を体感し、実践的なスキルを習得できるイベントとなっています。 AWS Fault Injection Service (FIS) とは？ AWS FIS は、カオスエンジニアリングを実践するための強力なツールです。カオスエンジニアリングとは、意図的に障害を発生させてシステムの応答を観察し改善を行う手法で、システムの盲点や実装上の問題を明らかにし、運用スキルの向上を通じてリカバリ時間の短縮にも貢献します。 AWS FIS は以下のような特徴があります。 管理された障害実験： 実際の運用環境で発生する可能性のある障害をシミュレートすることで、事前に対策を講じることができます。 多様なリソース対応： AWS FIS は Amazon EC2 (EC2) 、 Amazon Elastic Container Service (ECS) 、 Amazon Elastic Kubernetes Service (EKS) 、 Amazon Relational Database Service (RDS) のほか、多くのAWSサービスをサポートしており、今後も追加のリソースやアクションがサポートされる予定です。 実験の安全性確保： CloudWatch アラームを使用して、特定の条件下で実験を自動的に停止させることができ、重要なビジネスメトリクスへの予期しない影響を防ぎます。 Resiliency Quest で学べること Resiliency Quest では、AWS FIS を通じてどのように障害をシミュレーションし、いかに障害に対する対応を実施するか学ぶことができます。また、アプリケーションの信頼性を高めるためのレジリエンスのベストプラクティスを理解し、レジリエンスの向上を図るための実践的なスキルが身につきます。 Resiliency Quest の内容のご紹介 次は、本ワークショップのより具体的な流れとシナリオをご紹介します。 あなたは MyDigitalWallet という架空のアプリケーションを運用しています。そんなある日、社長からあなた宛に「アプリケーションがダウンしている」との緊急連絡を受けます。顧客や社内からのプレッシャーが高まり、何とかしてアプリケーションを安定させなければなりません。 1 つのシナリオでは、アプリケーションがダウンした理由は MyDigitalWallet のユーザーが増加し、突然トラフィックが増加したといったケースです。この場合、AWS FIS を使ってトラフィック増加シナリオをシミュレーションし、どのように対策を講じるかを学びます。さらに、システムのパフォーマンスを監視し、問題の根本原因を特定するプロセスも体験します。 具体的なワークショップの流れは次のとおりです。 ワークショップの流れ シナリオ紹介： はじめの第一歩！前提となるシステムのアーキテクチャを理解します。 障害シミュレーション： AWS Fault Injection Service を使って実際に障害を引き起こします。 対応策の実装： アーキテクチャを修正し、同じ障害が再発してもシステムを止めない方法を考えます。 スコア表示： システムの稼働状況によってスコアリングされ、ダッシュボードに参加者の点数が表示されます。 ヒントと詳細実装方法： 行き詰まっても大丈夫！ヒントや実装方法を参考に問題をクリアしていきます。 具体的なシナリオのご紹介 ここからは実際にワークショプで体感していただくコンテナタスク障害のシナリオを Dive Deep してご紹介します。 まずは、提供されるワークショップのアーキテクチャを理解します。 ワークショップを開始すると、実験を行うための画面が表示されます。この画面に従って実験を進めていきます。 現在、画面表示は英語をサポートしていますが、近日中での日本語化を目下進めております。 MyDigitalWallet アプリケーションはサポートする ECS タスクに障害が発生しても、システムはアプリケーションがダウンタイムなしで機能し続け、すべての支払いトランザクションが正常に処理されるか、損失を最小限に抑えるように設計されている必要があります。ここでは、このアプリケーションがそのように設計されているという仮説を置きます。 この仮説を検証するために、FIS 実験テンプレートを活用します。FIS 実験テンプレートでは、’aws:ecs:stop-task’ アクションを使用して、1 つの ECS タスクを停止して中断することをシミュレートします。アプリケーションへの影響は 100 秒間監視されます。 Start ボタンをクリックすると、実際に FIS 実験テンプレートが起動され障害を引き起こします。その結果、ダウンタイムが発生しリクエストが失われることがわかりました。スコアは残念ながら 0 点です。 この状況に対応するために、ここからは実際の AWS 環境を操作しアーキテクチャを修正することで、同じ障害が再発しても継続的に稼働する環境を目指します。まずはヒントをみて解決策に関する大まかな推奨事項を把握します。進め方がわからない場合は、ポイントを消費してより詳細なガイダンスを見ることもできます。 ヒントに従って、AWS のマネジメントコンソールで設定を行っていきます。ECS の障害ということで、実際の設定の確認を進めます。ここから先は、ぜひ実際のワークショップでご確認ください。 設定を行った後に再度障害を引き起こしたところ、当初の仮説の通り、ダウンタイムなしで機能し続けることができました。スコアも満点になっています。 ダッシュボードを見ると自身の点数だけではなく参加者の点数も表示されます。競いながら楽しくハイスコアを目指してください！ シナリオのご紹介は以上となります。雰囲気が少しでも伝われば幸いです。 こんな方におすすめ 本ワークショップは、以下の方々に参加をおすすめしております。 AWS ユーザー： すでに AWS のサービスに触れているが、AWS FIS については未経験の方。 開発者： アプリケーションのレジリエンスを高めたいと考えているが、コーディングの経験が少ない方。 運用エンジニア： インフラストラクチャの信頼性を向上させるための実践的なスキルを身につけたい方。 チームリーダーやマネージャー： チーム全体でレジリエンスの重要性を学び、実践的なトレーニングを通じてスキルを高めたいと考えている方。 ワークショップの実施前提 参加に向けて AWS FIS の経験は不要です。また EC2、ECS、RDS の知識があるとより良いスコアを狙うことができますが、必須ではありませんので安心してご参加ください。 また現在本ワークショップは、AWS がホストする形式で開催しております。ワークショップの開催をご希望の際は AWS の担当営業もしくはソリューションアーキテクトにお問い合わせください。 Resiliency Quest まとめ Resiliency Quest は、レジリエンスを高める方法を学ぶための絶好の機会です。ハンズオン形式で学べるこのワークショップに参加して、実践的なスキルを身につけてください。興味を持たれた方は、ぜひ AWS のメンバーにお問い合わせください。一緒にアプリケーションの信頼性を高め、レジリエンスを強化しましょう！ この記事は、ソリューションアーキテクト 渡部 拓実 が執筆いたしました。

アイピー・パワーシステムズは、マンション等に設置されている非常用電源装置のメンテナンスサービス、電力一括受電サービス、受変電設備工事を中心に事業を展開しているJCOMのグループ会社です。アイピー・パワーシステムズでは、オンプレミスの仮想環境上で稼働していた電力管理システム等を 2024 年 1 月に AWS に移行。データベースもオンプレミスの Oracle Database から Amazon RDS for Oracle に移行しました。本ブログでは、アイピー・パワーシステムズが移行した電力管理システムについて、AWS への移行検討から移行までの流れと移行後の効果や課題について、お客様の声をご紹介します。 移行対象のシステム お客様は、オンプレミス上にある仮想環境に複数のシステムを構築しており、その中のメインのシステムである電力管理システムは、1,500 棟以上のマンションに設置されたスマートメーターから定期的に転送されてくる検針データを収集し、集計、料金計算、請求処理などを行うシステムです。このシステムのデータベースは、Oracle Database を採用していて、データ量が多く数億レコードを超えるテーブルが数テーブルあり、その中の一つは約 100 億近いレコードを格納しているような状況でした。このシステムは、1,500 以上のマンションから逐一データが転送されるため、システムが停止してしまうとデータ転送ができず、料金計算などの業務に影響が出てしまうような状況でした。 当該システムにおける課題 当該システムをオンプレミスで運用している中で、いくつかの課題がありました。 ・老朽化による運用負荷 当該システムが含まれる仮想環境とハードウェアは老朽化により、障害対応やメンテナンス作業が頻繁に発生しているような状況で、土日や深夜などの業務時間外対応も発生していたため、運用担当者にとって運用負荷が高い状況でした。また、外部に公開しているサービスでは、データ量が多いテーブルに対する参照処理が集中してしまうとパフォーマンス問題が発生することもあり、その問題の原因調査などの対処にも多くの時間が発生していました。 ・拡張性への懸念 上記パフォーマンス問題への対処や、今後のデータ量や処理量が増えた場合スケールアップする必要がありますが、現状の環境ではデータベースのライセンスをすぐに追加することが難しく、データベースサーバーの拡張でも設定変更などの準備作業が必要であり、このような拡張性への懸念を抱えたまま運用している状況でした。 ・BCP 対策への懸念 BCP対策も重要な課題でした。オンプレミス環境ではバックアップデータの遠隔地への保管は実施していましたが、実際に障害が発生した時にリカバリによる業務停止時間が大きくなる可能性がありました。また、運用に伴う設定変更などでバックアップしていたデータが正常にリカバリできるのか、システムとして正常に稼働できるのか、といった障害発生時の復旧についても懸念を抱えた状態での運用が続いていました。 クラウドへの移行を検討 このような状況から、ハードウェアを保持せず、スケールアップやメンテナンスなどのデータベース運用負荷が削減できるクラウドを前提に移行検討を開始しました。移行先の候補として複数のクラウドを対象にしました。移行に向けた検討項目としては、先の課題を解決可能なアーキテクチャであることはもちろん、コストや移行性などの項目で比較検討しました。一方で、定性的な観点として、事例数、クラウドベンダーやサードパーティが公開しているブログやセッション情報などの技術情報量、サポートの質、障害やメンテナンスによる運用担当者への負担など、現場の運用担当者にとって使いやすいクラウドであることも採用時の重要なポイントになっていました。そして、これらの検討項目を総合的に判断した結果、AWS に移行することに決定しました。データベースは、拡張性やバックアップ、Amazon RDS Performance Insights による運用の効率化、ワンストップでのサポートなどを考慮して RDS for Oracle SE2(License Included) を採用し、データベースの移行はダウンタイムを削減しつつ移行可能な AWS Database Migration Service（DMS） を採用することになりました。 アーキテクチャ AWS 移行後のアーキテクチャは以下の通りです。 AWS 移行準備と移行 AWS への移行は３つのフェーズに分けて実施しました。 ・フェーズ１ 全体の移行設計と、仮想環境上にある小規模システムの AWS への移行を実施。同時に、AWS Direct Connect によるオンプレミスと AWS 間のネットワークを構築。 ・フェーズ２ 電力管理システムの移行を実施。データベースについては並行して電力管理システムの大規模改修プロジェクトが走っており、そのプロジェクト完了後の移行としていたため、データベース以外のアプリケーションを AWS に移行。 ・フェーズ３ オンプレミスの Oracle を RDS for Oracle に移行。Oracle のバージョンアップに伴うアプリケーション側への対応や、RDS for Oracle 採用に伴い SYS ユーザーで実行していたプログラムの修正、DMS によるデータ移行のテストなど、RDS for Oracle 移行に向けた準備作業を実施。2024 年 1 月、RDS for Oracle への移行が完了し、すべてのシステムの AWS への移行を完了。データ移行については、DMS を使うことで、データ移行自体はほぼリアルタイムでの移行。移行時のプログラム切替作業や、アプリケーションテストなどで数時間のダウンタイムは発生しましたが、想定より短いダウンタイムでの移行を実現。 移行後の効果と課題 今回の AWS への移行により、以下のような効果を確認することができました。 ・運用工数を約 25% 削減 ハードウェアの障害対応やメンテナンスなどの対応がなくなり、土日や夜間の緊急対応もほぼゼロになりました。テスト環境の構築も容易になり、オンプレミスの時と比較して運用担当者の工数を約 25% 削減することができました。 ・パフォーマンスの改善 老朽化したハードウェアから RDS for Oracle に移行することで、パフォーマンスが改善しました。顧客計算の処理が 10 秒から 2 秒、データのロード処理も 15 分から 5 分に改善し、その他の処理でも改善が見られました。これにより、オンプレミスで発生していた参照処理の集中によるパフォーマンス問題も発生しなくなりました。さらに、Performance Insights でデータベースのパフォーマンス情報が可視化されたことで、定期的に Performance Insights を確認して効率が悪い SQL をチューニングするなど、より積極的な運用も可能になりました。 ・マネージドによる安定稼働 RDS for Oracle に移行したことで、バックアップや拡張性など、データベース運用にまつわる様々な懸念が解消されました。また、RDSのリージョン間自動バックアップを採用して大阪リージョンにバックアップを転送することで課題だったBCP対策も容易に実現することができています。さらに、データベースで問題が発生した際はサポートにワンストップで問い合わせすることができるなど、運用にまつわる運用担当者の工数だけでなく、データベース運用に関する心理的な負荷を大幅に削減することができたことも、目に見えない AWS 移行の大きな効果となっています。 一方で、AWS への移行時の問題もいくつか発生しました。 ・移行後のパフォーマンス遅延 データを移行してシステム切り替え後にパフォーマンスが大幅に遅延したため、切り戻しが発生しました。これは、移行先の RDS for Oracle のテーブルからインデックスが存在していなかったことで、不要な読み込みが大量に発生するという事象でした。切り戻し後、入念な移行テストを実施し再度移行した際は問題なく移行を完了させることができています。 ・一部パッケージシステムが AWS 未対応 一部のパッケージシステムが EC2 に未対応なものがあり、AWS に移行できず現状もオンプレミスのまま稼働しているシステムがあります。これはパッケージシステム自体の仕様ですが、仮想環境による複数システムでの移行ではこのような可能性があるため、移行評価時に適切に確認する必要があります。 まとめ アイピー・パワーシステムズでは、今回の AWS 移行により運用時の負荷やパフォーマンスを改善することができました。今回の AWS 移行について、アイピー・パワーシステムズ株式会社 カスタマーオペレーション部情報システムチーム長の榎木 卓郎 氏（写真左）は以下のように振り返っています。 「移行にあたり AWS のソリューションアーキテクトを始めとしたアカウントチームからの手厚いサポートで大変助かりました。移行後はパフォーマンスが改善したことでユーザーからのクレームもなくなりました。AWS サポートの質の高さも感じており、AWS に移行して本当に良かったと思っています。」 – アイピー・パワーシステムズ株式会社 カスタマーオペレーション部情報システムチーム長　榎木 卓郎 氏（写真左） – アイピー・パワーシステムズ株式会社 カスタマーオペレーション部情報システムチーム　廣瀬 壱行 氏（写真右） 今後は、AWS 移行で削減できた時間を使って、CI/CD の推進やデータベースエンジンの移行、Lambda やReserved Instance を使ったコスト最適化など、AWS のサービスを有効に使ってシステムの安定化やコスト最適化などをすすめていく予定です。

組み込みシステムは、家電製品や医療機器、空調機、自動車といった特定の機能を提供するために設計されたハードウェア及びソフトウェアを指します。このブログでは、AWS Summit Japan 2024 の製造業ブース内で展示される「仮想化で組み込みソフト開発・改善の高速化」のデモについて説明します。組み込みソフトウェア開発における課題と、AWS クラウドの導入による課題の解決方法とデモを紹介をします。 組み込みソフトウェア開発におけるトレンドと課題 近年、組み込みシステムは、IoT や AI / ML といった最新技術の普及に伴い、複雑化やスマート化が進んでいます。また、組み込みシステムである製品と AWS をはじめとしたクラウド上で構築されたサービスを接続し、お客様に新たな価値を提供する SaaS Plus a Box といったビジネスモデルを採用するケースが増えてきています。このような技術・ビジネスモデルの変化に伴い、製品を売った後も継続的な改善やセキュリティの強化が求められています。そのため、いち早くお客様への価値や安全を提供するために、ソフトウェアリリースサイクルを高速化する必要が出てきます。 クラウド上で構築されるサービスの開発においては、DevOps により高速に改善するアプローチがあります。今後は、組み込みソフトウェア開発でもこのスピード感が求められてきます。しかし、組み込みソフトウェア開発は、DevOps のアプローチが取れず、製品・サービス全体で開発・改善を高速化することが難しくなります。 その主な原因は、ハードウェアが完成することを待たないと開発が進められない点にあります。組み込みソフトウェアは特定のハードウェア上で動作することを前提としているため、開発には特殊な CPU アーキテクチャやペリフェラルを搭載したハードウェアが必要です。 このため、一般的な開発環境とは異なるツールチェーンやドライバーを使用する必要があり、デバッグやテストの際には物理的にデバイスに接続する必要があります。このような環境はサービス開発チームにも影響を及ぼします。製品とサービスをリリースするために欠かせない結合テストを行うためには、ハードウェアの手配や複雑なセットアップを必要とし、組み込みソフトウェア開発チームとのコミュニケーションコストもかかります。 ハードウェアが無いとデバッグやテストも行えないため、開発プロセスが自然とウォーターフォール開発に依存することになります。ウォーターフォール開発では、要件定義、設計、実装といった各段階が明確に区分けされており、前工程でリスクを最小限に抑え、手戻りを少なくするメリットがあります。しかし、ウォーターフォール開発の特性上、動くソフトウェアが後工程でようやくリリースされるため、ユーザーフィードバックが遅れがちになり、ニーズの把握が不十分になることがあります。また、パフォーマンスやサービスとの整合性といった要件に対するリスクの顕在化も遅れる可能性があります。 ソリューション このような課題を解消するためのアプローチとして、組み込みシステムを AWS 上で仮想化し、サービス開発と同じプラットフォームの上で開発を進めることが考えられます。組み込みソフトウェアを仮想化することで以下のメリットが出てきます。 俊敏性: ハードウェアが無くても瞬時に開発環境を提供することができるため、開発チームがすぐに開発業務を始めることができます。 弾力性: 開発者の増減に合わせて、自由にリソースの規模をスケールさせることができます。 コスト最適化: 弾力性の高い仕組みにより、開発・テスト用のハードウェア数を最小限に抑えることができるため、コストの最適化にも繋がります。 イノベーションの加速: サービス開発・組み込みソフトウェア開発の両チームが同じクラウド環境で協業することで、コミュニケーションコストを減らし、付加価値の高い業務に集中することができます。 サービス開発と組み込みソフトウェア開発の環境を AWS 上で構成すると以下のようなリファレンスアーキテクチャとなります。大きく4つの環境に分かれており、各環境に対して AWS IAM Identity Center により共通の認証・認可の仕組みを提供します。 開発環境: CI / CD パイプラインとアーティファクトリポジトリを管理します。サービス開発者は、アーティファクトリポジトリから最新の組み込みソフトウェアをダウンロードし、サービスとの結合テストに活用することができます。 検証環境: 製品とサービスを組み合わせた結合テストを実行します。組み込みソフトウェアは仮想化されているため、クラウド上で動作することも可能となり、ハードウェアのセットアップは不要となります。 本番環境: 製品のユーザーが実際に使用されている物理的な製品をサービスに接続します。この環境に対するアクセスは、製品を使用しているお客様データが含まれているため、データ保護・セキュリティの観点からアクセス許可範囲は限定的にする必要があります。 分析環境: 製品ユーザーの製品・サービス利用動向や CRM ( Customer Relationship Management ) に保存されたカスタマーサポート内容などから、改善点や問題を発見するための洞察を得ることができます。 開発環境を 1 つのプラットフォームで構成することにより、組み込みソフトウェア開発・サービス開発の垣根を無くし、高速にお客様に価値を届けることができます。また、両チームがお客様データに基づいて意思決定を行いやすくなるため、顧客ニーズに迅速に対応し、より良い製品サービスを提供することができます。 デモアプリケーションの紹介 AWS Summit Japan 2024 で展示されたデモをご紹介します。 ストーリー このデモでは、空調機の操作のための空調コントローラーという IoT プロダクトを想定します。空調機は人感センサー省エネ制御という、空調機が人の存在を感知する人感センサーを使用し、誰も部屋にいない時は空調機の動作を停止または低速運転に切り替える省エネ機能を有しています。ビル管理会社がこの機能をあまり有効化していないという課題が、空調機メーカーの BI (Business Inteligence) ダッシュボードによって判明しました。空調機メーカーは、空調コントローラーの UI を改善することで課題を解決できると考え、素早く新バージョンをリリースすることで、ビル管理会社の KPI であるエネルギー消費量の削減に応え顧客満足度の向上を目指します。 アーキテクチャ デモのアーキテクチャは以下のようになっています。 空調コントローラーには、Raspberry Pi を使用しています。ソフトウェアは、 Yocto Project をベースとしたカスタム Linux イメージを作成しています。 1. ユーザ分析 ユーザ分析では、IoT データやサポートケースの情報を BI ダッシュボードを作成して可視化します。BI ダッシュボードは、 Amazon QuickSight を使用して作成しており、人感センサー省エネ制御の利用状況や、サポートケースの情報を可視化しています。現在のユーザーの動線を見ると、多くのユーザは人感センサー省エネ制御の設定から自動制御モード (人感センサー省エネ制御の動作モードの設定画面) への遷移をしています。つまり、多くのユーザーは人感センサー省エネ制御の有効化に興味を示しているということです。しかし、当月の人感センサー省エネ制御の利用率は 23 % と低調になっているため、興味があるにも関わらず実際には設定を有効化していないということになります。一方で、問い合わせ履歴を確認すると、人感センサー省エネ制御に関する UI 操作の問い合わせが多いことが確認できます。データから、UI の操作性が機能の利用率を下げている一因であると推測できます。 2. ソース Push ダッシュボードから得た洞察を基に仮説を立て、組み込みソフトウェア開発チームはユーザーフレンドリーな新 UI を開発しました。旧 UI では、人感センサー省エネ制御の設定ボタンまで到達するためにスクロールが必要であったり、人感センサー省エネ制御を有効化するために制御の動作モードを少なくとも1つ有効化する必要があったりすることで、機能の有効化までに辿りつきづらい UI となっていました。新 UI では、スクロール不要とするようにボタンの間隔を縮小し、動作モードはデフォルト値を自動セットすることでお勧めの設定を促すようになっており、よりユーザーフレンドリーな UI となりました。 新 UI をリリースするため、ソースコードを AWS CodeCommit に Push し、 AWS CodePipeline , AWS CodeBuild による CI / CD パイプラインで新たなソフトウェアをビルド・テストしていきます。 3. リリース 組み込みソフトウェアのアーティファクトをリリースします。このデモでは Raspberry Pi で動作する空調コントローラーアプリケーションと、アプリケーションを動作させる組み込み Linux をビルドします。動作対象は、Raspberry Pi に加えて、オープンソースのエミュレータである QEMU と Amazon Machine Image ( AMI ) となり、イメージをそれぞれ作成します。AMI を作成するために、AWS のソフトウェアをインストールするレシピがまとめられているレイヤーである meta-aws を使用しています。 Yocto Project を使用することにより、稼働させるハードウェア又は仮想マシン特有のレシピを設定で切り替えることができます。 Yocto Project をベースとしたビルドパイプラインは GitHub リポジトリ aws4embeddedlinux-ci で公開されている CDK ライブラリを呼び出して構築しています。 4. テスト デバイスイメージだけでなく、QEMU や AMI をベースとしたアーティファクトを作成することで、デバイスレスでのテストが可能となります。これにより、クラウドで組み込みソフトウェアが動作するため、サービス開発者によってもシームレスに結合テストを実施し、製品・サービス間の連携を確認することが容易となります。下図では、 Amazon WorkSpaces を用いてVDI 上でのタッチパネルのテストを実施しています。 また、製品テストには実機を用いた結合テストも欠かせないので、 AWS Code Pipeline の手動承認アクションを追加し、パイプラインを停止し、承認者が実機テスト結果を確認して承認できるようにします。 5. デプロイ 全てのテストが完了したら、 AWS IoT Greengrass のコンポーネントをダウンロードします。 6. OTA AWS IoT Greengrass が OTA ( Over The Air ) アップデートにより製品に対して新しいコンポーネントをインストールします。 7. データ収集 製品は、 AWS IoT Greengrass のコンポーネントによりお客様から許可を得た上でユーザ行動ログや設定状態を MQTT 通信でクラウドに送信します。今回のデモでは、タッチパネルの画面遷移ログと空調コントローラーの設定を収集しています。また、CRM といった顧客データからも、顧客の行動やフィードバックが収集できます。今回のデモでは、サポートケース情報を収集し、分析対象に含めています。 8. 改善確認 以下のダッシュボードは、ソフトウェアアップデート後の状態です。人感センサー省エネ制御の設定から自動制御モードへの画面遷移数の変化は小さいものの、人感センサー省エネ制御の利用率が 40 % まで伸びました。UI の変更により顧客体験が向上し、より多くのユーザーが本機能を利用していることを、ダッシュボードから確認することができます。このように、異なる立場の開発者が同じ情報から意思決定を行うことで、効果的な機能改善が可能になります。 まとめ 組み込みソフトウェア開発は、要件の複雑化やスマート化に伴い、製品・サービスを使用するお客様へ高い価値を提供し続けるため、素早い市場投入・市場投入後の継続的な改善とセキュリティレベルの維持が求められています。この記事では、組み込みソフトウェアを仮想化し、製品・サービス両方の開発環境を AWS 上に構築しソフトウェアリリースサイクルを高速化するソリューションについて説明しました。また、AWS Summit Japan 2024 で展示された製造向け展示の一つであるスマートプロダクトエリアの「仮想化で組み込みソフト開発・改善の高速化」ブースで展示し、このソリューションの具体化されたストーリーを紹介しました。 村松 謙 (Ken Muramatsu @kenmuu) Amazon Web Services でソリューションアーキテクトとして製造業のお客様を中心にクラウド活用の技術支援を担当しています。AWS 以前は、組み込みソフトウェアエンジニアとして産業システムの開発に従事していました。 宇佐美 雅紀 (Masanori Usami @usamiii) ソリューション・アーキテクトとして、製造業のお客様を中心にご支援しています。AWS 以前は、組み込みソフトウェアのエンジニア、アーキテクトとしてさまざまなシステムの開発に従事していました。ソフトウェア工学の勉強が好きです。 梶山　政伸　(Masanobu Kajiyama @kajikun) 趣味は旅行で19ヶ国に行きました。現在はソリューションアーキテクトとして、製造業のお客様と共にクラウドジャーニーをしています。 中西 貴大 (Takahiro Nakanishi @taknakt) Amazon Web Services でソリューションアーキテクトとしてコングロマリットのお客様にクラウド活用の技術支援を担当しています。趣味はドライブや旅行です。 大久保 裕太 (Yuta Okubo @okyuta) Amazon Web Services でソリューションアーキテクトとして建設・不動産業のお客様を中心にクラウド活用の技術支援を担当しています。趣味はバスケと睡眠です。