こんにちは！アマゾンウェブサービスジャパン合同会社で製造業のお客様を支援しているシニア事業開発マネージャーの川又です。 2024 年 3 月 14 日に製造業向けオンラインセミナー「データ活用による製造業のトランスフォーメーション」を開催いたしました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開いたします。 はじめに 今回のセミナーは、製造業の皆様や、製造業のお客様を持つパートナーの皆様から、よくご要望をいただく、「製造業におけるデータ活用やお客様での事例」を単にプレゼンテーションでご紹介するだけではなく、実際に視聴者の皆さまにより具体的にイメージを持っていただけるようデモも交えながらお伝えさせていただきました。それぞれのセッションの内容を本ブログと動画でお届けいたします。 オープニングセッション：製造業におけるデータジャーニーとベストプラクティス 登壇者: AWS エンタープライズ技術本部 ハイテク・製造・自動車産業グループ 製造第一ソリューション部・部長 河村 聖悟 資料リンク 私達の暮らしの中では、天気や交通状況など、日常生活の様々な場面でデータに基づいた判断が行われています。製造現場においてもデータの力を活用できれば、生産効率・最適化など多くのメリットがありますが、現場には課題が山積みです。デジタル化されていない情報が多数存在して、可視化は部分的であり、オペレーションが分断されているなどの課題が挙げられます。課題対策の指針として「製造業におけるデータジャーニー」というロードマップをご紹介します。 製造業におけるデータジャーニー 「製造業におけるデータジャーニー」は、データ運用の成熟度によって4つのエリアに分かれています。エリア1は「局所的なリアルタイムの可視化」、エリア2は「全社的な可視性」、エリア3は「予測的オペレーション」、エリア4は「コスト最適化オペレーション」です。必ずしもすべてのエリアを順番に進む必要はなく、現在の成熟度から次のステップを知ることが重要です。 エリア１：局所的なリアルタイムの可視化 エリア 1「局所的なリアルタイムの可視性」では、パイロット施設や重要要素を特定し、優先ワークロードにソリューションやダッシュボードを導入します。既存設備からデータを取り出すことが重要で、現場ノウハウから生産管理者への情報伝達を円滑にします。大きな投資は不要ですが、全体最適化を見据えたロードマップを意識しつつ、将来的な展開を見越した取り組みが求められます。 エリア２：全社的な可視性 エリア 2「全社的な可視性」では、全社的なデータレイク戦略の構築が求められます。企業全体のデータレイクと OT / IT 接続戦略が必要不可欠です。リアルタイムなデータは、意味のあるコンテキストを持った状態での可視化が分析に必要であり、優先順位を付けたユースケースについて、丁寧に複数の場所で段階的に実施していくことが重要です。現場にとってインセンティブが少ないため、中期的な視点で各現場・部門との調整を行い、PoC を実施して小さな成功体験を積み重ねていく必要があります。 エリア３：予測的オペレーション エリア 3「予測的オペレーション」では、アナリティクスや AI、機械学習を活用して工場の財務計画や生産能力計画でリソースの最適化を図ります。過去のデータだけでなく、仮説に基づいた予測を行う仕組みが必要不可欠です。標準のモデルなどを活用した予測データ・グラフから新たな気づきを得ることで、これまでにない観点や改善や、判定条件を設ける事で機械同士の連携や自動化が可能になり、フィードバックループを作り出せます。現場では手戻りや重複作業の削減、多品種少量生産への対応など、エリア3のメリットを享受できるようになります。 エリア４：コスト最適化オペレーション エリア 4「コスト最適化オペレーション」では、企業がビジネスプロセス全体を最適化する能力を獲得します。アナリティクスに基づく最適化がモデルと意思決定プロセスに統合されることで、真のコスト削減と、統一されたインターフェイスにより工場・工程を横断した全体最適化が実現できます。設計・デザイン・スマートファクトリー・スマートプロダクトがデータでつながり、製品やプロセスの継続的な改善につながります。エリア4に至るには、企業全体のデータ統合と、新しいデータ駆動型の企業運営モデルへの関係者全員のコミットメントが必須条件となります。 モダンデータ戦略の成功要因としての３本の柱 製造におけるデータジャーニーを支える大切な3つの柱をご紹介します。1 つ目は「マインドセット」の柱です。データドリブンなカルチャーを取り入れてデータ活用を進めるためには、意識改革が不可欠であり、経営層からの強いコミットメントが求められます。2 つ目は「人材とプロセス」の柱です。イノベーションを最も促進できる組織構造・役割・プロセスを定義してコミュニケーションを密にし、データ活用の舞台・教育体制を提供することを指します。最後に「テクノロジー」の柱があります。パフォーマンス、費用対効果、安全性、スケーラビリティに優れた、クラウドデータアーキテクチャの活用に代表されます。これら 3 つの柱が、データ活用を企業文化に根付かせる鍵となります。 製造業における AWS の幅広いケイパビリティ 講演の中では、製造業のデータジャーニーを力強くサポートする AWS の幅広いサービスとケイパビリティをご紹介しました。AWS は、工場のエッジ、オンプレミス、既存システムとの連携を強くサポートします。エッジでは、エンドツーエンドのセキュリティ、開発、デプロイ、管理の機能を提供します。様々なデータフォーマット・転送形式に対応したデータ収集機能や、柔軟なデータレイクのインフラ、データ管理に関するセキュリティ、アクセス権限管理機能を提供しています。目的別のデータベース、豊富な分析手段、機械学習のツール、リアルタイム分析の可視化機能が、データジャーニーのジャンプスタートを可能にします。 製造におけるデータジャーニーでは誰もが主役 データジャーニーを推進するには、経営層、生産管理者、現場の全ての関係者がコミットし、同じ歩幅でなくとも、同じ方向を向いて小さな一歩を踏み出す必要があることをお伝えしました。完全なデータ利活用は一朝一夕にはできませんが、クラウドの力を借りてすぐに開始可能であり、製造業のデータ活用の可能性を身近に感じていただけたら嬉しいです。AWS は、お客様とともに製造業のデータジャーニーを歩んでいく所存です。 ここからは、製造業におけるデータジャーニーのいくつかのエリアについて、詳細な説明やデモをご紹介します。 デモ１：業務改善につながる生産関連データ活用 登壇者: AWS ソリューションアーキテクト 山田 航司 資料リンク このセッションでは、データジャーニーのフェーズ1「ローカライズされたリアルタイムの可視性」における、既存の設備からデータを取り出す方法がイメージできるように、ミニチュアスマートファクトリーデモをご覧いただきました。スマートファクトリーデモでは、受注に応じた加工を施して出荷する 「多品種少量の受注生産品」の生産ストーリーを設定しました。 このような複雑化したオペレーションに生じやすい課題として、「人手に頼った生産によりヒューマンエラーが起こりやすくなる」や「生産の不安定化」といった課題が挙げられます。対応策として、設備装置から発生するデータを AWS IoT SiteWise や AWS IoT Core に集め、生産稼働状況をニアリアルタイムで可視化することで、異常やイレギュラーが発生してからアクションに移るまでの時間を短縮し、稼働率を高める方法をご説明しました。 既存設備を新しい機能をもった設備に入れ替える必要はなく、PLC などまずはできるところから可視化していくが重要であり、ミニチュア工場の中のどの部分が既存設備にあたるかや、 AWS IoT Greengrass をインストールした産業用 PC を新規で設置すれば生産データ活用のためにクラウドにデータを送れるようになることをビジュアルで解説しました。 デモ２：予測的オペレーションを実現する AWS Supply Chain 登壇者: AWS ソリューションアーキテクト 水野 貴博 資料リンク このセッションでは、サプライチェーン領域においてデータジャーニーのフェーズ3「予測的オペレーション」を実現する AWS Supply Chain をご紹介しました。サプライチェーンの領域では、エンタープライズリソースプランニング (ERP)、倉庫管理システム (WMS)、注文管理システム (OMS)、輸送管理システム (TMS) など、システムがサイロ化されているケースが多く、サプライチェーンのデータを統合し、エンドツーエンドのプロセスの可視化を実現し、予測的なオペレーションを実現することが難しいとされてきました。 AWS Supply Chain は、サプライチェーンデータレイクによる統合データ管理を提供し、既存のプロセスを最適化することができます。統合されたデータを活用し、予測精度の向上、過剰在庫の削減、サイクルタイムの短縮を可能にします。 AWS Supply Chain の「データ取込み」「在庫可視化」「デマンドプランニング」そして、2024 年にリリースされたばかりの「サプライプランニング」「N – Tier 可視化」について、デモを交えてご紹介しました。最後に 2024 年後半リリース予定の生成 AI アシスタント「Amazon Q」をご紹介しました。自然言語インターフェースによるサプライチェーンデータに対して「何が」「なぜ」「もし～だったら」という問い合わせを行う様子をご覧頂きました。 デモ３：クラウドネイティブ BI Amazon QuickSight 登壇者: AWS ソリューションアーキテクト 岩根 義忠 資料リンク このセッションでは、データジャーニーのフェーズ2「全社的な可視性」に至ることの価値と、その一例としてのデモをご覧いただきました。データドリブンな意思決定を一貫した KPI に基づいて素早く行えるようになると、意思決定サイクルが組織の各階層で頻繁になり、結果として組織・工場のアジリティを高めることができます。 こうしたアジリティを高めるための、一貫した KPI に基づくデータドリブンな意思決定の一例として、 Amazon QuickSight を用いた製造ダッシュボードのデモをご紹介しました。また、BI ツールによる可視化や分析レポートのために必要とされる専門知識のハードルを下げ、「データ分析の民主化」を成し遂げるために、自然言語による直感的なダッシュボード作成や、ダッシュボードから得られる洞察を自然言語でレポート化できる Amazon Q in QuickSight (Preview) によるダッシュボード作成とレポート作成のデモをご紹介しました。 部門や工程の壁を超えたクラウドへのデータ集約と、強力な可視化ツール、生成AIの組み合わせにより、「現場に可視化のパワーを与える」ことが可能となり、さらに次の段階の「予測的オペレーション」に向け、改善活動の志向が全体最適に向かうことが期待されます。 終わりに 本セミナーでは、 製造業におけるデータジャーニーとベストプラクティスをご紹介するプレゼンテーションから、工場の可視化‐複数工場の現在の稼働状況を遠隔地から把握するデモ、サプライチェーンに関わるデータ活用とデモ、製造現場のデータ活用における思想設計やユースケース設定に立ち戻ったデータ活用推進のアイディアやデモや AWS の提供する新機能活用などを通して、AWS がご支援する製造業におけるデータ活用を紹介しました。 本ブログは、事業開発マネージャーの川又俊一、ソリューションアーキテクトの 河村聖悟、山田航司、水野貴博 、岩根義忠が執筆しました。

こんにちは。ソリューションアーキテクト (以下 SA) の津和崎です。 2023 年 11月 7日に「AWS Media Road Show 2023 – AWSメディアサービスを使ったコンテンツ配信の最前線」と題したイベントを開催しました。AWS Media Serviceの最新情報をAWS Elemental R&DのProduct Managerが直接解説するLoft Eventです。ご参加いただきました皆様には、改めて御礼申し上げます。 当日の様子と実施内容 セッションの紹介 MediaLive/MediaConnect最新動向 AWS Elemental R&D Head of Product, Live Services Mike Cronk 資料ダウンロード クラウドベースのライブ制作と UHD OTTストリーミングによって、業界をリードする品質・拡張性・回復力をどのように実現しAWSユーザーのお客様が収益を最大化しているか、Paramount Global、National Hockey League（NHL）、ロレックス・パリ・マスターズ（テニストーナメント）、Sky Sports、PGAツアー、Stan. の事例を紹介し、数多くのスポーツやイベント会場からクラウドを活用してライブ制作する利点を紹介しています。多くのVODサービスで最高品質がUHDにシフトするなかで、エンコードに必要な分散処理の課題を解決するMediaLiveの内部的改善、エンコーダーまでのMediaConnectを活用した伝送、パッケージング・配信まで、クラウドをフル活用したアーキテクチャをご紹介しています。Media Live/Media Connectは現在、東京・大阪リージョンでの展開も進んでおり、コンテンツを国外に出すことなく2つのリージョンによるDRが実現できます。 MediaTailor Channel Assembly最新動向 AWS Elemental R&D Senior Prod Manager Phil Harrison 資料ダウンロード Live・VOD問わずパーソナライズされた広告挿入およびチャネルアセンブリを可能にするAWS Elemental MediaTailor について、本セッションではVODとLive to VODへの広告挿入についての基本機能の紹介と利点、ユースケース、それがどのような技術で動いているかをご紹介し、Case StudyとしてSeven West Mediaでの活用事例をご紹介しています。Media Tailorで広告挿入する場合のレファレンスとして、手動でスケジュールしたタイミングで広告を挿入するアーキテクチャ・AIによるユーザーごとにパーソナライズされた広告挿入に対応できるアーキテクチャをそれぞれ紹介し、直近の機能リリース（Liveソースへの対応・Channel Assemblyで迅速なスケジュール更新等）についても紹介しています。 MediaTailor SSAI (Server Side Ad Insertion)最新動向 AWS Elemental R&D Senior Product Manager Peter Henning 資料ダウンロード AWS Elemental MediaTailorにてサーバーサイド広告挿入をする場合のアーキテクチャとして、ライブ・VODそれぞれに対しての広告挿入のレファレンスアーキテクチャを紹介し、広告のトランスコーディングやレポート、オブザーバビリティ、AWS 以外の多様なAdサーバーへの対応、大阪リージョンの対応など深掘りして機能の紹介をしています。 特に、オーバーレイ広告についてはPeacockの事例・IBCにてデモが行われたスクィーズ/フレーム広告などもご紹介し、コンテンツと合成された形で広告を表示し、視聴者は広告中もコンテンツを見続ける視聴体験が可能になる利点・機能をご紹介しています。加えて、マニュフェストによるCreative IDシグナリングにより、広告再生のコントロールをどのようにして実現するか、HLS インタースティシャルへの対応予定についても詳しく紹介しています。 MediaConvert最新動向 AWS Elemental R&D Principal Product Manager Max Denton 資料ダウンロード AWS Elemental MediaConvertを活用したトランスコーディングについて、東京に加え大阪リージョンでも活用できるようになった状況やSony LIV・Slackでの活用事例をご紹介しております。 最新機能の紹介としては、取得できるメトリクスの追加や動画の品質を向上するための機能として、圧縮効率の向上・AI Human Vision System を使用した知覚できないほどの微細なノイズの除去・シャープネスの調整機能など、 Bandwidthを低く保ったまま動画品質を向上させる方法を紹介しております。トランスコードのためのワークフローを改善する機能として、ビデオソースの置き換え機能、コンテナ・オーディオ・キャプションはそのままでビデオエッセンスのみをパススルーできる「トランスマックス」機能、出力先のS3 Tierを変更できる機能など、さまざまな変更に対応している点を詳しく紹介しています。 まとめ 今回は、U.S.から来日したMedia サービスのProduct ManagerよりAWS メディアサービスを使ったコンテンツ配信の最新情報をご紹介いたしました。本イベントが、より高品質でスケーラブルな配信がより短期間に数多く、収益性も伴う形で実現するためのきっかけになれば幸いです。 AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 津和崎美希

3月18日週はストレージの話題からお届けします。 3月11日週、 Amazon Simple Storage Service (Amazon S3) の 18 年にわたるイノベーションを祝うイベントが AWS Pi Day 2024 で開催されました。Amazon S3 のマスコットである Buckets も参加して、非常に楽しいイベントとなりました。 4 時間にわたるライブストリームでは、ユーモアを交えながら、 PartyRock を使用した パイのレシピ 、デモ、コード、そして生成 AI と Amazon S3 に関するディスカッションが紹介されました。 AWS Pi Day 2024 — 2024 年 3 月 14 日の Twitch ライブストリーム ライブストリームを見逃した場合は、 録画 を見ることができます。今週、 community.aws の AWS Pi Day 2024 に関する投稿 も更新して、ショーのメモとセッションクリップを追加する予定です。 3月11日週のリリース 私が注目したいくつかのリリースをご紹介します。 Anthropic の Claude 3 Haiku モデルが Amazon Bedrock で利用可能に — 最近、 Anthropic が基盤モデル (FM) の Claude 3 ファミリー (Claude 3 Haiku、Claude 3 Sonnet、Claude 3 Opus) を発表しました。このファミリーの中で最も高速でコンパクトな Claude 3 Haiku が Amazon Bedrock で利用できるようになりました。詳細については、 Channy の投稿 を参照してください。さらに、同僚の Mike が、 Amazon Bedrock での Haiku の使用を開始する方法を紹介する動画 を community.aws で公開しています。 AWS CloudFormation で最大 40% 速くスタックを作成  — AWS CloudFormation の CONFIGURATION_COMPLETE という新しいイベントでスタックを最大 40% 速く作成できるようになりました。このイベントを使用すると、CloudFormation はスタック内の依存リソースの並行作成を開始し、プロセス全体がスピードアップします。この新しいイベントでは、リソースの一貫性チェックが不要なシナリオでも、ユーザーはスタック作成プロセスをより細かく制御することもできます。詳細については、 この AWS DevOps ブログ記事 を参照してください。 Amazon SageMaker Canvas がモデルレジストリ統合を拡張 — SageMaker Canvas のモデルレジストリ統合が拡張され、時系列予測モデルに加えて、 SageMaker JumpStart で微調整されたモデルが含まれるようになりました。ユーザーは、これらのモデルをワンクリックで SageMaker モデルレジストリに登録できるようになりました。この機能強化により、モデルレジストリの統合が、リグレッション/分類表モデルや CV/NLP モデルなど、Canvas でサポートされているすべての問題タイプに拡張されます。その結果、機械学習 (ML) モデルの本番環境へのデプロイが効率化されます。 詳細については、デベロッパーガイドを参照してください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のニュース記事、オープンソースプロジェクト、Twitch ショーを紹介します。 Build On Generative AI — 生成 AI のすべてを網羅する人気の ウィークリー Twitch ショー のシーズン 3 が盛り上がりを見せています。 私の同僚の Tiffany と Darko が、毎週月曜日 9:00 US PT のストリーミングで生成 AI のさまざまな側面についてディスカッションし、ゲストスピーカーのデモを紹介しています。 今日のエピソード では、ゲストの Martyn Kilbryde が、Amazon Bedrock を使用して JIRA エージェントを構築する方法を紹介しています。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 PyTorch 用の Amazon S3 コネクタ — PyTorch Lightning のユーザーは、 PyTorch 用 の Amazon S3 コネクタ を使用してモデルチェックポイントを Amazon S3 に直接保存できるようになりました。PyTorch 用の Amazon S3 コネクタを使用すると、Connector for than writing to Amazon Elastic Compute Cloud (Amazon EC2) インスタンスストレージに書き込むよりも 40% 速く PyTorch Lightning モデルチェックポイントを保存できます。PyTorch Lightning トレーニングジョブから Amazon S3 でチェックポイントを直接保存、読み込み、削除することも可能になりました。  GitHub のオープンソースプロジェクトをチェックしてください。 AWS のオープンソースに関するニュースと最新情報 — 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた Open Source Newsletter を毎週 執筆しています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS at NVIDIA GTC 2024 — NVIDIA GTC 2024 開発者カンファレンスが今週 (3 月 18 日～21 日) にカリフォルニア州サンノゼで開催されます。お近くの方は、ブース #708 の AWS で生成 AI のデモを確認し、ブース内のシアターで生成 AI、ロボティクス、アドバンストコンピューティングの最新製品について、AWS、AWS パートナー、エキスパートのお客様からインスピレーションを得てください。  AWS セッションをチェックして、1 対 1 のミーティングをリクエストしてください。 AWS Summit — AWS Summit シーズンの到来です! 最初の開催地である パリ (4 月 3 日) を皮切りに、 アムステルダム (4 月 9 日)、 シドニー (4 月 10 日～11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15 日～16 日)、そして ソウル (5 月 16 日～17 日) での開催が予定されています。AWS Summit は、クラウドコンピューティングコミュニティが一堂に集まって交流し、コラボレートして、AWS について学ぶことができる無料のオンラインおよび対面イベントです。 AWS re:Inforce — ペンシルバニア州フィラデルフィアで開始される AWS re:Inforce (6 月 10 日～12 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながり、AWS のお客様のセキュリティジャーニーについて学ぶことができます。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 今週はここまでです。3月25日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

3月14日は AWS Pi Day です ! 太平洋標準時の午後 1 時から始まる Twitch のライブ配信にご参加ください 。 18 年前のこの日、西海岸のある小売企業が オブジェクトストレージサービスを開始し 、 Amazon Simple Storage Service (Amazon S3) を世界に発表しました。世界中の企業のデータ管理方法が変わるとは思いもしませんでした。2024 年に進むと、 現代のビジネスはすべてデータビジネスです 。私たちは、 データがどのようにしてデジタルトランスフォーメーションを推進するのに役立つか 、そして 生成人工知能 (AI) がどのようにしてビジネスに予想外の有益な新しい機会をもたらすのかについて、数え切れないほどの時間を費やしてきました。私たちの対話は進化し、差別化された生成 AI アプリケーションの作成において、独自のデータがどのような役割を果たすかについての議論を取り入れるようになりました。 Amazon S3 は、実質的にどんなユースケースにも対応できる 350 兆以上のオブジェクトとエクサバイト規模のデータを保存し、1 秒あたり平均 1 億回以上のリクエストを処理していることから、皆様の生成 AI の旅の出発点になる可能性があります。しかし、最も重要なのはデータの量や保存場所ではなく、その品質です。質が高いデータでモデル応答の精度と信頼性を向上させることができます。 最高データ責任者 (CDO) を対象とした最近の調査では 、CDO のほぼ半数 (46%) が、生成 AI の実施における最大の課題の 1 つがデータ品質だと考えています。 今年の AWS Pi Day では、Amazon S3 の誕生日にあたり、データレイクから高性能ストレージまで、 AWS Storage がどのようにデータ戦略を変革し、生成 AI プロジェクトの出発点となるかを観察していきます。 このライブオンラインイベントは、 AWS Innovate: Generative AI + Data edition の終了直後の本日 (2024 年 3 月 14 日) 午後 1 時 (太平洋標準時) に始まります。 Twitch の AWS OnAir チャンネル でライブ配信され、AWS の専門家による 4 時間の新しい教育コンテンツが取り上げられます。データと既存のデータアーキテクチャを使用してカスタマイズされた生成 AI アプリケーションを構築および監査する方法を学ぶだけでなく、最新の AWS ストレージイノベーションについても学ぶことができます。通常通り、このショーでは実践的なデモは満載、皆様がこれらのテクノロジーを直ちに使い始める方法を実際に見ることができます。 生成 AI のデータ 消費者活動、ビジネス分析、IoT センサー、コールセンターの記録、地理空間データ、メディアコンテンツ、またその他の要因によるデータは驚異的な速度で増加しています。このようなデータの増加は、生成 AI のすさまじい成長の原動力です。基盤モデル (FM) は、インターネットからのペタバイト規模のウェブページデータを含むオープンリポジトリである Common Crawl などのソースから提供される大量のデータセットに基づいてトレーニングされます。FM からの応答をさらにカスタマイズするために、組織はより小規模なプライベートデータセットを使用しています。これらのカスタマイズされたモデルは、次に、更に多くの生成 AI アプリケーションを促進し、お客様とのインタラクションを通じて、データフライホイールのためにさらに多くのデータを生成します。 業界、ユースケース、地域に関係なく、今すぐ始められるデータイニシアティブは 3 つあります。 まず、 既存のデータを使用して AI システムを差別化します 。ほとんどの組織の基盤は大量のデータです。このデータを使用して、特定のニーズに合わせて基盤モデルをカスタマイズおよびパーソナライズできます。パーソナライゼーション技術には、構造化されたデータが必要なものもあれば、そうでないものもあります。その他には、ラベル付きのデータまたは未加工データが必要なものもあります。 Amazon Bedrock と Amazon SageMaker には、さまざまな既存の基盤モデルを微調整または事前トレーニングするための複数の解決策が用意されています。また、お客様や協力者のために ビジネスのエキスパートである Amazon Q をデプロイし、 すぐに使用可能な 43 のサポートされるデータソース 内の 1 つ以上を標的として指定することも可能です。 しかし、AI 利用の拡大に役立つ新しいデータインフラストラクチャの構築は望んでいないでしょう。生成 AI は、既存のアプリケーションと同じように組織のデータを消費します。 その次に、 既存のデータアーキテクチャとデータパイプラインを生成 AI と連携させ 、データアクセス、コンプライアンス、およびガバナンスに関する既存のルールを引き続き遵守することを望んでいます。当社のお客様は、AWS に 1,000,000 を超えるデータレイクをデプロイしていました。データレイク、Amazon S3、および既存のデータベースは、生成 AI アプリケーションを構築するための優れた出発点です。 検索拡張生成 (RAG) をサポートするために、複数のデータベースシステムでベクターストレージと検索へのサポートを追加しました。 Amazon OpenSearch Service は論理的な出発点かもしれません。ただし、 pgvector を PostgreSQL 用の Amazon Aurora 、および PostgreSQL 用の Amazon Relational Database Service (Amazon RDS) と一緒に使用することもできます。また最近、 Amazon MemoryDB for Redis 、 Amazon Neptune 、 Amazon DocumentDB (MongoDB 互換) 用の ベクターストレージと検索 を発表しました。 また、現在既に導入されているデータパイプラインを再利用または拡張することも可能です。皆様の多くは、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 、 Amazon Managed Service for Apache Flink 、 Amazon Kinesis などの AWS ストリーミングテクノロジーを使用して、伝統的な機械学習 (ML) や AI でリアルタイムのデータ準備を行っています。これらのワークフローを拡張してデータの変更を捕捉して、ベクトルデータベースの更新によりほぼリアルタイムで大規模言語モデル (LLM) に変更を反映させたり、MSK のネイティブストリーミングインジェストを用いて Amazon OpenSearch Service にナレッジベースの変更を反映させたり、 Amazon Kinesis Data Firehose を通じて Amazon S3 の統合データストリームで微調整データセットを更新したりすることができます。 LLM のトレーニングにおいて、スピードが重要です。データパイプラインは、トレーニングクラスター内の多くのノードにデータをフィードできる必要があります。Amazon S3 にデータレイクを持つお客様は、パフォーマンス要件を満たすために、 Amazon S3 Express One Zone のようなオブジェクトストレージクラスや、 Amazon FSx for Lustre のようなファイルストレージサービスを利用しています。 FSx for Lustre は緊密な統合を実現し、使い慣れた高性能ファイルインターフェイスを利用することで、オブジェクトデータ処理の高速化を可能にします。 幸いなことに、データインフラストラクチャが AWS サービスで構築されている場合、生成 AI のデータを拡張する方向に既に大きな進歩を遂げました。 第 3 に、 自分自身の最高の監査人にならなければなりません。 すべてのデータ組織には、生成 AI のために定められた規制、コンプライアンス、コンテンツ管理に対して、事前に備える必要があります。トレーニングやカスタマイズにどのデータセットが使用されているか、また、モデルがどのように意思決定を行ったかを知っておく必要があります。生成 AI のような急速に変化している分野では、未来を予測する必要があります。AI システムをスケールする間、完全に自動化されている方法ですぐにそれを実行する必要があります。 データアーキテクチャでは、 AWS CloudTrail 、 Amazon DataZone 、 Amazon CloudWatch 、 OpenSearch など、さまざまな AWS サービスを監査に使用され、データ使用量が管理および監視されています。これは AI システムへ簡単に拡張できます。生成 AI に AWS Managed Services を使用している場合は、組み込まれたデータの透明性を高める機能を利用できます。CloudTrail サポート付きの生成 AI 機能を発表するのは、企業からのお客様には、AI システムの監査証跡を持つことがいかに重要であるかを理解しているからです。Amazon Q でデータソースを作成すると、そのデータソースは CloudTrail に記録されます。CloudTrail イベントを使用して、 Amazon CodeWhisperer によって作られた API コールをリストで表示することもできます。 Amazon Bedrock には 80 を超える CloudTrail イベントがあり、これらを使用してファンデーションモデルの使用方法を監査するのが可能です。 前回の AWS re:Invent カンファレンスでは 、 Amazon Bedrock 向けのガードレール についても紹介しました。これにより、避けるべきトピックを指定できます。また、 Bedrock は、制限されたカテゴリーに該当する質問に対し、承認済みの回答のみをユーザーに提供します リリースされたばかりの新機能 Pi Day は、AWS ストレージとデータサービスの革新を祝う機会でもあります。ここでは、今回発表された新機能の一部を紹介します。 PyTorch 用 Amazon S3 コネクタ は今、 PyTorch Lightning のモデルチェックポイントを Amazon S3 に直接保存することをサポートするようになりました。モデルチェックポイントは通常、トレーニングジョブを一時停止する必要があるため、チェックポイントの保存に必要な時間は、エンドツーエンドのモデルトレーニング時間を直接に影響します。PyTorch Lightning はオープンソースのフレームワークで、PyTorch で行われるトレーニングやチェックポイントの作成にレベルの高いインターフェースを提供します。 この新しい統合の詳細については、「最新情報」の投稿を参照してください 。 Amazon S3 on Outposts 認証キャッシュ – この新機能は、Amazon S3 のアイデンティティ認証および承認データをローカルの Outposts ラックに安全にキャッシュすることで、リクエストのたびに親 AWS リージョンへの往復する必要をなくして、ネットワークでの往復によって生じるレイテンシーの変動を減少します。 Amazon S3 on Outposts 認証キャッシュの詳細については、「最新情報」の投稿 、および AWS ストレージブログチャネルで発表されたこの新規投稿を参照してください 。 Mountpoint for Amazon S3 Container Storage Interface (CSI) ドライバー は Bottlerocket で使用できます。Bottlerocket は Linux に基づき、コンテナーのホストを目的とするオープンソースの無料オペレーティングシステムです。 Mountpoint for Amazon S3 に基づいて構築された CSI ドライバーは、 Amazon Elastic Kubernetes Service (Amazon EKS) と自己管理型 Kubernetes クラスター内のコンテナによって、S3 バケットをアクセス可能なボリュームとして表示します。これにより、アプリケーションがファイルシステムインターフェイスを介して S3 オブジェクトにアクセスできるため、アプリケーションコードを変更せずに高い集計スループットを実現します。 「最新情報」の投稿には、Bottlerocket 用の CSI ドライバーに関する詳細が記載されています 。 Amazon Elastic File System (Amazon EFS) は、ファイルシステムあたりのスループットを 2 倍向上させました。当社は Elastic Throughput の制限について 、読み取りオペレーションでは最大 20 GB/秒、書き込みでは最大 5 GB/秒までに引き上げました。つまり、機械学習、ゲノミクス、データ分析アプリケーションなど、スループットをさらに重視するワークロードに EFS を使用できるようになりました。 EFS でのスループットの向上についての詳細は、「最新情報」の投稿を参照してください 。 今月初めに実行した重要な変更は、他にもあります。 Amazon S3 Express One Zone ストレージ クラスと Amazon SageMaker の統合 – トレーニングデータ、チェックポイント、およびモデルアウトプットの読み込み時間を短縮することで、Amazon SageMaker モデルのトレーニングを加速できるようになります。 この新しい統合の詳細については、「新機能」の投稿を参照してください 。 Amazon FSx for NetApp ONTAP は、ファイルシステムあたりの最大スループットキャパシティを 2 倍 (36 GB/秒から 72 GB/秒まで) に増加し、ONTAP のデータ管理機能をさらに幅広いパフォーマンスを重視するワークロードに使用できるようになりました。 Amazon FSx for NetApp ONTAP の詳細については、「最新情報」の投稿を参照してください 。 ライブ配信中に期待できること 本日において開催された 4 時間のライブショーでは、これらの新機能のいくつかについて説明する予定です。私の同僚の Darko さんが、AWS の専門家を多数招いて実践的なデモンストレーションを行います。皆様が生成 AI プロジェクトでデータを活用する方法を探すのに手伝いをします。こちらは当日のスケジュールです。すべての時間は太平洋標準時 (PT) タイムゾーン (GMT-8) で表記されます。 既存のデータアーキテクチャを生成 AI までに拡張 (午後 1 時～午後 2 時)。 AWS のデータレイク上で分析を行っているなら、生成 AI のためのデータ戦略に向けて、既に大きく前進していると言えます。 生成 AI のコンピューティングへのデータパスを加速 (午後 2 時～午後 3 時)。 モデルトレーニングと推論のコンピューティングデータパスには、速度が大事です。それを実現するさまざまな方法をご覧ください。 RAG と微調整でカスタマイズ (午後 3 時～午後 4 時)。 基本的な基盤モデルをカスタマイズする最新の技術をご覧ください。 GenAI の最高のオーディターになりましょう (午後 4 時～午後 5 時)。 コンプライアンスの目標を達成するために、既存の AWS サービスを活用しましょう。 AWS Pi Day ライブストリーム に今すぐご参加ください。 お会いできるのを願っています! — seb 原文は こちら です。

このブログ記事は、AWS エンタープライズサポート担当テクニカルアカウントマネージャーの Tanya Pahuja と Sumit Bhardwaj 、および AWS シニアソリューションアーキテクトの Karan Desai によって書かれました。 消費者向けのウェブサイトやモバイルアプリでは、ユーザーの画面にコンテンツが読み込まれるスピードが、ユーザーのブラウジング体験やビジネスの成功に直接影響します。コンテンツの読み込みに時間がかかると、ユーザーはトランザクションを完了する前にページを放棄する可能性があり、収益に影響します。 Amazon CloudFront のようなコンテンツ配信ネットワーク（CDN）を利用すれば、データ、動画、アプリケーション、API を低遅延かつ高速で世界中のユーザーに安全に配信し、ウェブサイトのパフォーマンスを向上させることができます。HTML 、画像、スタイルシート、JavaScript ファイルなどのウェブサイトの静的コンテンツは、CloudFront の エッジロケーション やリージョン別エッジキャッシュにキャッシュされたコピーから提供できます。新しく更新されたコンテンツや API コールなど、キャッシュできない動的コンテンツは、CloudFront によってオリジンサーバーからフェッチされ、 AWS グローバルネットワーク を使用して高速かつ最適化された経路で配信されます。 パフォーマンスを向上させるには、CloudFront ディストリビューションを設定することで、ウェブサイトのトラフィックが CloudFront のグローバルに分散されたエッジネットワーク経由で配信されるように設定するだけです。CloudFront を使用してコンテンツを配信するように設定したら、ウェブサイトのパフォーマンスを監視して、得られるメリットを理解し、パフォーマンスをさらに最適化するために設定を変更する必要があるかどうかを確認する必要があります。この投稿では、 Amazon CloudWatch Real User Monitoring (RUM) を使用してウェブサイトのパフォーマンスを監視し、CloudFront を使用してコンテンツを配信した場合と使用しない場合のユーザーエクスペリエンスの違いに関する洞察を得る方法を紹介します。 CloudFront に対する模擬モニタリングとリアルユーザーモニタリング（RUM） 通常、ウェブサイトのパフォーマンスを測定するために、2 つの異なるタイプのモニタリングを使用することができます。 模擬モニタリング： ユーザーのウェブサイトへのジャーニーとインタラクションのシミュレーションを使用して、ウェブサイトのパフォーマンスを監視する方法です。これは、地域、ネットワーク、デバイス、およびブラウザなどの変数が事前に決定され、変更されない制御された環境で行われます。外部変数を制御することは、バックエンドのインフラおよびアプリケーション側にパフォーマンスのボトルネックが存在する場所を理解し、パフォーマンスの問題の原因を特定するのに役立ちます。しかし、これは必ずしもユーザーが実世界で経験することを表すものではありません。 リアルユーザーモニタリング： パッシブ・モニタリングの一種で、実際のユーザーとウェブサイトとのやり取りを分析するものです。通常、アプリケーション内にコードの一部を挿入することで、ユーザーのブラウジング体験に影響を与えることなく、クライアントやブラウザからのフィードバックを収集します。これにより、顧客がウェブサイトとどのようにやり取りしているか、また、特定のデバイス、ブラウザ、およびネットワーク上でのウェブサイトのパフォーマンスに関する顧客の経験について洞察することができます。 アーキテクチャー概要 まず、 Application Load Balancer（ALB） の背後にある Amazon Elastic Compute Cloud（Amazon EC2） インスタンス上にウェブアプリケーションをデプロイすることから始めます。既存のウェブアプリケーションを使用するか、この チュートリアル に従ってサンプルの 3 層ウェブアプリケーションをデプロイすることができます。公開 ALB エンドポイント URL を使って、ブラウザからこのウェブサイトにアクセスします。これは CloudFront を実装する前のユーザーのベースライン体験を表しています。 十分なデータが得られたら、このディストリビューションの「オリジン」として先ほど使用したのと同じ ALB を指す CloudFront ディストリビューション を構成します。CloudFront は各ディストリビューションに一意のドメイン名を提供します。それでは、ブラウザからウェブサイトにアクセスしますが、今回は CloudFront の URL を使用します。これは CloudFront が実装された後のユーザーエクスペリエンスを表しています。2 つのテストから取得したデータを比較することで、コンテンツ配信のために CloudFront を使用することでユーザーが得られるパフォーマンスの向上を理解することができます。次の図はテストのアーキテクチャーを示しています。 図 1：ソリューションのアーキテクチャー図 CloudFront に対する CloudWatch モニタリング RUM の利用に入る前に、CloudWatch と直接統合されている CloudFront の運用メトリクスを調べることができます。これらのメトリクスは CloudWatch コンソール で利用でき、追加コスト無しで利用できます。以下のスクリーンショットにあるように、CloudFront ディストリビューションによって提供された HTTP リクエストの数、ユーザーによってダウンロードおよびアップロードされたバイト数、4XX および 5XX エラーの数を監視することができます。また、CloudFront ディストリビューションのキャッシュヒット率や、キャッシュされていないコンテンツを提供する際のオリジンレイテンシなど、追加コストで追加のメトリクスをオンにすることもできます。 図 2：CloudWatch 上の CloudFront モニタリングメトリクス このデータは、ウェブサイトの健全性を判断したり、ウェブサイトへのユーザートラフィックの概要を把握したりするのに役立ちます。しかし、ウェブサイトのパフォーマンスに関するユーザー・エクスペリエンスについての洞察は得られません。そこで RUM を活用します。 RUM を使ってウェブサイトのパフォーマンスを検証する 次に、同じウェブアプリケーションの RUM を使って計測しましょう。このためには、まず CloudWatch RUM でアプリケーションモニター を作成し、それによって生成された コードスニペット を、パフォーマンスをモニターしたいウェブサイトの HTML ページに挿入する必要があります。※CloudWatch RUM のアプリケーションモニターはドメイン毎に作成します。CloudFront 独自のドメインを使用して比較を行う場合は、CloudFront を使用する場合と使用しない場合でドメインが異なることがあります。その場合は検証を行う毎にコードスニペットをドメイン毎に入れ替えて検証してください。 1) CloudFront を使用しない場合の RUM CloudWatch RUM ウェブクライアントを埋め込みスクリプトとしてインストールするには、RUM ウェブクライアント設定コードスニペットをアプリケーションの <head> 要素内、他の <script> タグの上に貼り付ける必要があることに注意してください。 図 3：HTML ページに挿入された CloudWatch RUM スクリプトの例 パフォーマンスタブには、ページのロード時間やユーザーが遭遇したエラーなど、ウェブページのバイタルサインが表示されます。バイタルサインは 3 つのレベル ([Positive] (良好)、[Tolerable] (許容範囲)、[Frustrating] (不良)) に分けられます。 図 4：ページのロード時間を示す CloudWatch Performance タブ また、ユーザーのブラウザ上でウェブページを完全にロードするために必要な各ステップにかかる時間も確認できます。これには、初期接続の確立にかかる時間、SSL ハンドシェイク、コンテンツの最初のバイトをロードする時間、完全なロード時間などが含まれます。 図 5：ウェブページの読み込みにかかる各ステップの時間の内訳の例 この図の例では、この特定のユーザーがウェブページをロードするのにかかる平均時間は 764ms で、最初の接続に 278ms、最初のバイトに 280ms かかっていることがわかります。これをベースラインとして、CloudFront を使って同じウェブページを配信したときのパフォーマンスを比較することができます。 2) CloudFront を使用する場合の RUM AWS コンソールで先ほど作成した CloudFront ディストリビューションにアクセスし、CloudFront ドメインの URL を取得することができます。そして、ブラウザでこの URL を使ってウェブサイトにアクセスすることができます。これで再びCloudWatch RUM に新しいデータポイントが送信され、CloudFront を使用してコンテンツが配信されたときのユーザーエクスペリエンスが表示されます。パフォーマンスメトリクスを再び見てみましょう。 図 6: CloudFront を使用した場合のページのロード時間を示す CloudWatch Performance タブ 図 7：CloudFrontを使用したウェブページのロードにかかる各ステップの時間の内訳 先の例では、同じユーザーがウェブページをロードするのにかかった時間の合計が 447ms になったことがわかります。最初の接続には 17.5ms しかかかっていません。ALB の前に CloudFront をデプロイすることで、ページのロード時間がほぼ 40% 短縮され、ユーザーエクスペリエンスが向上していることがわかります。 CloudWatch RUM は、CloudFront を使用して配信されるウェブサイトについて、いくつかの追加の洞察を提供します。以下のスクリーンショットに見られるように、異なる地域のユーザーに対するウェブサイトのパフォーマンスを確認し、どのユーザーが良いエクスペリエンスを得ているか、またはページのロード時間が長いためにフラストレーションのたまるエクスペリエンスを得ているかを比較することができます。 図 8：CloudWatch RUM が提供する、ユーザーの地理的位置によるページロードパフォーマンスの例 また、以下のスクリーンショットのように、異なるブラウザやデバイスタイプを使用してウェブサイトにアクセスしたユーザーの閲覧体験の詳細を取得することもできます。 図 9：CloudWatch RUMが提供する、ユーザーのブラウザ別のページロードパフォーマンスの例 さらに、以下のスクリーンショットに見られるように、RUM が監視しているすべてのイベントのオリジナルログエントリや、ウェブサイトをナビゲートするユーザージャーニーにアクセスすることができます。 図 10 : クラウドウォッチ RUM の raw イベントログの例 また、以下のスクリーンショットのように、ランディングページからウェブサイト、その後のインタラクションまでのユーザージャーニー全体を追跡することもできます。 図 11 : CloudWatch RUM を使用してトラッキングされたユーザージャーニーの例 まとめ この投稿では、RUM を使用してエンドユーザーのウェブサイトのパフォーマンスに関する洞察を得る方法と、CloudFront を活用することで得られる改善を監視する方法について学びました。このデータが得られれば、アプリケーションのどの部分をさらに最適化すればユーザーエクスペリエンスが向上するかを特定でき、 CloudFront が提供する様々な機能 を設定することでウェブサイトのパフォーマンスをさらに向上させることができます。 本記事は、「 Prepare and run performance tests for Amazon Cloudfront with Real User Monitoring 」と題された記事の翻訳となります。 翻訳は Solutions Architect の長谷川 純也が担当しました。

IBM Db2は、ミッションクリティカルなシステムで信頼されているデータベースとして知られています。最近では、そのポテンシャルをクラウドでさらに活かそうとする企業が増えています。そこで、クラウドでのDb2活用方法とオンプレミスからのスムーズな移行戦略を解説する特別オンラインセミナーを企画いたしました。 本セミナーは、AWSをこれから始める方を対象に、初歩から専門知識まで段階的に解説します。 最初のセッションでは、AWSの概要、そしてAWSがどのようにしてリレーショナルデータベースの運用課題（パフォーマンス、運用効率、コスト効率、可用性、災害復旧）を解決できるかをご紹介します。 続いて、AWSのマネージドデータベースサービスであるAmazon RDS for Db2に焦点を当て、オンプレミス環境からクラウドへの移行がもたらす変化とそのメリットを、具体的かつ詳細に解説します。さらに、AWSへの移行プロセスを、実践的なステップに分けてご説明し、参加者の皆様が直面するかもしれない疑問や課題に対する答えを提供します。 AWSの基礎からAmazon RDS for Db2の活用法、効率的な移行プロセスまでを網羅し、参加者の皆様が直面する疑問や不安を解消する内容を2時間のセミナーにコンパクトにまとめました。 Db2のクラウド活用を始めるための貴重な洞察を得る絶好の機会です。ぜひお申し込みください！ 4月11日(木) オンラインセミナー 「IBM Db2 の試算を AWS で活用する」アジェンダ 時間 セッション 10:00 – 10:35 リレーショナルデータベースの課題と AWS による解決 Amazon RDS for Db2 の紹介を行う前に、AWS の特徴及び AWS が性能や運用、コスト最適化、および可用性と DR などリレーショナルデータベースにつきまとう課題をどのように解決できるか説明します。IBM Db2 に関する知識があっても AWS に関して知識が足りない、という方には欠かせないこの後のセッションを理解する上での AWS の前提知識について短時間で学ぶことができます。 AWS 技術統括本部 エンタープライズ技術本部 シニアソリューションアーキテクト 野間 愛一郎 10:35 – 11:15 Amazon RDS for Db2 紹介 AWS が提供するマネージド型のデータベースサービスである Amazon RDS for Db2 に関して Amazon RDS の基本から説明します。RDSの概要や特徴といった基本から説明しますので、Amazon RDS についての知識がなくとも Amazon RDS for Db2 のメリットや特徴を短時間で学ぶことができます。加えて、オンプレミスの IBM Db2 との違いについても説明します。 AWS サービス & テクノロジー事業統括本部 Data & AI ソリューション本部 シニアアナリティクススペシャリストソリューションアーキテクト 下佐粉 昭 11:15 – 12:00 AWS へのマイグレーション方法と支援サービス AWS ではお客様が移行先のデータベースを選択するために Database Freedom Workshop を提供しています。お客様環境の Db2 のアセスメントを含むこのプログラムでは、アセスメント結果を基に適切な移行先を決定する上でのガイドを提供します。今回のセッションでは、この Database Freedom Workshop の紹介のみならず、パートナー各社の移行支援サービスや、実際に移行を行ったお客様の事例紹介を通じて、現在利用している Db2 の今後に関して誰に相談すればいいのか、AWS からどのような支援が提供されるのか、どのようなステップで検討を進めればよいのかを学ぶことができます。 AWS データ事業本部 スペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 矢木 覚 ※当日の進行により、時間割が若干変更となる場合がございます。 参加費：無料 参加登録： こちらのページよりお申し込みください スピーカー紹介 スピーカーはオンプレミスのDb2利用経験のあるAWSメンバーが担当します。 野間 愛一郎 AWS 技術統括本部 エンタープライズ技術本部 シニアソリューションアーキテクト 主に製造業のお客様を担当するソリューションアーキテクトとして活動。お客様の多種多様な要件に合わせてAWS上にソリューションを構成するため幅広く技術支援を行っている。前職ではIBM Db2の製品担当として大規模データベースやミッションクリティカルシステムを支援、データベースコミュニティの立ち上げなどにも貢献した。 下佐粉 昭 AWS サービス & テクノロジー事業統括本部 Data & AI ソリューション本部 シニアアナリティクススペシャリストソリューションアーキテクト 前職では、IBM Db2のプリセールスエンジニアとして活動。著書に「即戦力のDB2管理術」。 現職ではソリューションアーキテクトとしてRDS for Db2の技術支援をお客様・パートナーに提供している。 矢木 覚 AWS データ事業本部 スペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 前職では、Oracle Databaseのプリセールスエンジニアとして活動。商用データベースに関する多数のwebコンテンツを作成。現職ではソリューションアーキテクトとしてRDS for Oracle, RDS for Db2を担当。 今回のウェビナー完了後、開催レポート及びQ＆Aは Amazon Web Servicesブログ に掲載予定となります。

AWS Config は、AWS アカウント内または AWS Organizations 全体の AWS リソースの設定変更を追跡するサービスです。AWS Config は設定レコーダーを使用してリソースの変更を検出し、それらを設定項目 (CI) として追跡します。クラウドインフラストラクチャの複雑さが増すにつれ、CI の数は指数関数的に増加しています。ワークロードは、短い間隔でリソースを作成、更新、削除することが必要であり、従来の静的なものではなく動的なものになりつつあります。過去には、設定レコーダーは継続的な記録のみをサポートしており、本番環境でない場合でも、追跡対象のリソースへの変更が発生したタイミングでそれをすべてキャプチャしていました。 この度、AWS Config の定期的な記録機能の提供を発表できることを大変嬉しく思います。この新機能により、設定レコーダーの記録頻度を日次に設定することが可能になりました。これまでの継続的な記録や設定項目の更新に代わり、過去 24 時間で変更があった場合に、リソースの最新の状態を表す設定項目が記録されるようになります。24 時間の周期内で、そのリソースタイプの定期的な記録が有効になっているリソースを作成および削除した場合は、設定項目は生成されません。定期的な記録を使用することで、すべてのリソースタイプのデフォルトの記録頻度を日次にしつつ、特定のリソースタイプをカスタマイズする設定が可能です。または、リソースタイプごとに設定することもできます。これにより、コンプライアンスやセキュリティ上の重要なリソースタイプの場合は従来の継続的な記録を使用して連続的に追跡し、本番以外のアカウント内の Amazon EC2 インスタンスなどは日次で定期的に追跡するように指定することが可能です。 定期的な記録のメリットには以下が含まれます: コスト効率 : 日次での記録により構成変更の記録頻度が下がることで、関連コストを削減できます。定期的な記録は継続的な記録とは異なる課金体系であることに注意が必要です。詳細は AWS Config の料金ページ をご確認ください。 混乱の最小化 : 定期的な記録による日次での記録は、過去 24 時間で変更があった際に設定項目が記録されるため、通知の頻度を下げてアラート疲れの回避に適した情報フローを提供します。 リソースタイプに対して定期的な記録または継続的な記録を使用するかどうかの決定にあたっては、セキュリティとコンプライアンスの要件を考慮することが重要です。リソースタイプのリアルタイムモニタリングや詳細な分析が必要な場合は、継続的な記録を使用することをおすすめします。詳細は 記録頻度 のページをご覧ください。 この投稿では、AWS Config の定期的な記録を開始する方法を紹介します。既存の設定レコーダーを AWS コンソールで更新して、継続的な記録ではなく定期的な記録を利用するようにします。さらに、AWS コンソールでカスタマイズ可能なオーバーライドを使用した定期的な記録のデモも行います。次に、 AWS CLI を使用して、定期的な記録用に設定レコーダーを設定する例を紹介します。AWS Config を初めて設定する場合は、 ワンクリックセットアップ から開始してください。 AWS Config での定期的な記録の設定 既存の AWS Config ユーザーが、特定のリソースタイプで定期的な記録を利用するように設定レコーダーの設定を更新したいシナリオについて説明します。デフォルトでは、記録範囲内のすべてのリソースタイプは、定期的な記録を明示的に選択しない限り、継続的な記録が採用されます。 設定レコーダーの記録方法における記録戦略には次の 2 つのオプションがあります: カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ : AWS Config はオーバーライドの設定で 記録から除外 に指定したリソースタイプを除く、すべての現在および将来のサポートされているリソースタイプの設定変更を記録します。AWS Config の設定レコーダーを初めて設定する場合、これがデフォルトのオプションです。 特定のリソースタイプ : AWS Config は、指定したリソースタイプの設定変更のみを記録します。リソースタイプの記録を停止することを選択した場合でも、すでに記録されている設定項目は変更されません。 既存の設定レコーダーを定期的な記録に変更するには、次の手順を参照してください。 AWS Config コンソール に移動します。 ナビゲーションペインで、 設定 を選択します。 編集 を選択します。現在の記録戦略に応じて、ステップ 4 の「カスタマイズ可能なオーバーライドのあるすべてのリソースタイプの場合」またはステップ 5 の「特定のリソースタイプの場合」に進んでください。 記録戦略として カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ が設定されている場合は以下のとおりです。 すべての現在および将来のリソースのデフォルトの記録頻度として、 継続的な記録 または 日次記録 を選択できます。デフォルトの記録頻度は継続的な記録に設定されています。 特定の リソースタイプ の記録頻度を変更したり、特定のリソースタイプを 記録から除外 に指定するために、任意のオーバーライドを追加できます。 注意 : グローバルリソースタイプの IAM リソースタイプを除外するには、このバンドルタイプをリストから選択し、記録から除外することを選択してください。バンドルの詳細については、AWS Config 記録方法の 設定 を参照してください。 図 1 AWS Config 記録方法 – カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ 現在、 特定のリソースタイプ が記録戦略として設定されている場合は以下のとおりです。 ドロップダウンを使用して、記録するリソースタイプを追加または削除できます。 頻度では、リソースタイプごとに 連続 または 日次 を選択できます。 図 2 AWS Config 記録方法 – 特定のリソースタイプ 記録戦略を更新したら、 保存 を選択してください。 設定 の下部で、更新された設定レコーダーの設定を確認できます。 図 3 AWS Config 設定 AWS CLI を使用した既存の設定レコーダーの更新 このセクションでは、 AWS CLI を使用した定期的な記録の設定 の例をいくつか示します。 前提条件 AWS CLI を使用して既存の設定レコーダーを更新するには、既存の設定レコーダーの roleARN と name の情報が必要です。 describe-configuration-recorders コマンドを使用して、現在の設定レコーダーの name と roleARN を調べることができます。 $ aws configservice describe-configuration-recorders { "ConfigurationRecorders": [ { "roleARN": "arn:aws:iam::123456789012:role/config-role", "name": "default" } ] } すべてのリソースタイプへの定期的な記録の適用 put-configuration-recorder コマンドを使用して、設定レコーダーに設定を行うことができます。この例では、更新対象のレコーダーを識別するために、前提条件のステップでメモした設定レコーダーの name と roleARN を指定しています。 recording-group をすべてのサポートされているリソースに設定し、すべてのグローバルリソースタイプを true に設定しています。最後に、 recording-mode において記録頻度として recordingFrequency を DAILY に設定しています。 すべてのリソースタイプに定期的な記録を適用するには、ターミナルに以下のコマンドを入力します。 注意 : name と roleARN の値を、ご利用する AWS Config の設定レコーダーの値に置き換えてください。 aws configservice put-configuration-recorder --configuration-recorder name= default ,roleARN= arn:aws:iam::123456789012:role/config-role --recording-group allSupported=true,includeGlobalResourceTypes=true --recording-mode recordingFrequency=DAILY カスタマイズ可能なオーバーライドのあるすべてのリソースタイプを使用した定期的な記録の適用 すべてのリソースタイプに対して継続的な記録を行いたいが、カスタマイズ可能なオーバーライドを使用して特定のリソースタイプを定期的に記録したい場合は、 recording-mode オプションを使用する際に JSON ファイルを利用して設定することができます。 注意 : name と roleARN の値を、ご利用する AWS Config の設定レコーダーの値に置き換えてください。 aws configservice put-configuration-recorder --configuration-recorder name= default ,roleARN= arn:aws:iam::123456789012:role/config-role --recording-group allSupported=true,includeGlobalResourceTypes=true -- recording-mode file://recordingMode.json 以下は recording-mode で指定している JSON ファイル file://recordingMode.json の例です。 { "RecordingFrequency": "CONTINUOUS", "RecordingModeOverrides": [ { "RecordingFrequency": "DAILY", "ResourceTypes": [ "AWS::EC2::Instance", "AWS::DynamoDB::Table" ] } ] } JSON の例では、 RecordingFrequency が CONTINUOUS に設定され、継続的な記録がすべてのリソースタイプに指定されていることがわかります。しかし、EC2 インスタンスと DynamoDB テーブルの 2 つに関してはオーバーライドが定義されていて、定期的な記録が指定されています。 RecordingModeOverrides を利用することで、どのリソースタイプを継続的な記録の対象外とするか指定することが可能です。 コマンドオプションの詳細については、 AWS CLI コマンドリファレンス を参照してください。 まとめ このブログ記事では、AWS Config の定期的な記録を使用して、日次でリソースの最新の構成変更をキャプチャする方法について学びました。これにより、AWS Config によって検出される変更の数を削減できます。次に、AWS マネジメントコンソールと AWS CLI を使用して定期的な記録を設定する方法を学びました。AWS Config の設定レコーダーの詳細については、 設定レコーダーの管理 を参照してください。 著者について Abraham Musa Abraham は AWS の Cloud Foundations チームの Cloud Operations Specialist Solutions Architect でニューヨークを拠点に働いています。彼は AWS Control Tower、AWS Organizations、AWS Service Catalog や AWS Config に詳しいです。Abraham は元軍人で旅行が好きです。 Megan Velez Rivera Megan は公共領域のお客様を支援している Solutions Architect です。12 年以上の米国政府との協働経験から、Megan はお客様に複雑なクラウドインフラストラクチャの設計、実装、支援を行っています。彼女はお客様のクラウドオペレーションとオブザーバビリティ向上にも熱心に取り組んでいます。 Chris Sordan Chris はニューヨークを拠点にする Solutions Architect です。彼はエンタープライズのお客様に対し、設計上のベストプラクティスを使用してお客様の AWS 利用促進を支援しています。彼は革新的なソリューションを通じてお客様の技術的な目標を達成することに喜びを感じています。彼はジャズやスポーツイベントに参加することが趣味です。 Craig Edwards Craig Edwards はボストンを拠点とする AWS の Cloud Foundations チームと働く Cloud Operations Specialist Solutions Architect です。彼は AWS Config、AWS CloudTrail、AWS Audit Manager や AWS Systems Manager に詳しいです。Craig は元軍人で、父で、自転車に乗ることが好きです。 原文は こちら です。翻訳は SA 桂井が行いました。

NFTにおける画像生成 NFT(Non-Fungible Token)市場では、プログラムによって自動生成されたデジタルアート作品が多数取引されています。これらの作品はジェネラティブアートと呼ばれ、アルゴリズムを用いて無数のバリエーションの作品を生成することができます。 代表的な手法として、CryptoKittiesのようにキャラクターのパーツ(体、目、耳、尾など)を予め用意し、それらをランダムに組み合わせることで新しいキャラクターを生成する方法があります。この方法ではアーティストがルールを決めた上で、そのルールに基づいてさまざまなバリエーションの新しい画像をプログラムで作り出すことができます。最近では、DALL・EやStable Diffusionなどの生成AIを活用し、テキストのプロンプトからNFT用の画像を自動生成する試みも増えています。 NFT(Non-Fungible Token)は1点モノのデジタルアートであることが多く、多数のNFTを作成する場合は素材となる多様な画像が必要です。しかしアーティストにとって多数の画像を手作業で作成することは大きな負担です。 そこで注目されているのが、生成AIを活用した自動画像生成です。 本記事では、生成AIを使ったNFT用の大量画像生成の方法を解説します。 生成AIが持つ創造性を活用することで、効率的かつ魅力的なバリエーション豊かなNFT用の画像生成が期待できます。 Amazon Bedrockを用いたNFT用の画像生成 NFT用の向けに大量の画像を効率よく生成する手法としてお勧めするのが、Amazon Web Services が提供する Amazon Bedrock の生成AIを使用する方法です。 Amazon Bedrockはクラウド上で動作する生成AIの基盤モデルで、大規模言語モデルや画像生成モデルをAPI通じて呼び出せます。基盤モデルに対してテキストのプロンプトを入力することで高品質な画像を生成してくれます。NFT用の場合、コンセプトなどのテキストを入力することで、作品の世界観を反映した多様なバリエーション画像を大量生成できます。 Amazon BedrockとStable Diffusionを使用して生成した画像 Amazon Bedrockを使ってNFT用の画像を生成するには、まずコンセプトとなる入力画像を用意します。作品のイメージを決め、その世界観や構成を示した代表的な画像です。 この入力画像をbase64形式にエンコードし、テキスト形式のプロンプトと合わせてAmazon Bedrockに入力することで、画像の持つ特徴を生成AIに伝えられます。その結果、入力画像の世界観や構図を保ちつつ、プロンプトで指定した要素を含んだ新しい画像を生成できます。 AWS Step Functions Distributed MapとAmazon Bedrockを使用した大量生成 AWS Step FunctionsのDistributed Mapを使うと、Amazon Bedrockによる画像生成を並列で実行できます。これにより大量のバリエーション画像を効率的に生成できます。ただし、Amazon Bedrockにクオータの制限があるため、並列実行数は低めに設定しましょう。 Distributed Mapは、CSVやJSON等で定義された入力データを並列のブランチに分割して処理し、結果をまとめる機能です。NFT用画像を生成する場合、入力値であるプロンプト定義をJSON形式で事前に用意しておきます。プロンプト定義はプログラムを用いて、例えば「髪型をショートカットにする」「髪色を金色にする」「背景色を金屏風にする」などさまざまな要素を事前に用意し、乱数に基づいて選択すると思いもよらない組み合わせができて面白いかもしれません。 このようにプロンプトとAWS Step FunctionsとAmazon Bedrockを組み合わせることで、大量のバリエーションに富んだNFT用の画像を効率よく生成できます。 AWS Step Functionsに渡す入力値の例です. 使用する生成AIのモデルや入力画像を保存しているAmazon Simple Storage Service(Amazon S3)の情報も一緒に渡します。 id や rank といった情報を生成AIのseed値に変換して用いることでバリエーションを増やすこともできます。 [ { "id":"A1", "rank":"nomal","inputBucketName":"111122223333-aa-example-1-input-image-bucket", "inputKeyName":"image.jpeg", "model":"stability.stable-diffusion-xl-v0", "prompt":"hair color is brown, backglound color is white" }, { "id":"A2", "rank":"vip","inputBucketName":"111122223333-aa-example-1-input-image-bucket", "inputKeyName":"image.jpeg", "model":"stability.stable-diffusion-xl-v0", "prompt":"hair color is gold, backglound color is red" }, ] 大量に生成する場合、再現性を確保するためにプロンプトの管理や保存が必要となります。また、並列実行数の制御やエラーハンドリングなど、細かな制御を実装する必要が出てきます。AWS Step Functionsの Distributed Map を使用することで、プロンプトや入力値等のパラメータの管理は事前に作成したJSONファイルに、並列実行数の制御やエラーハンドリングはAWS Step Functionsに任せることができるため、エンジニアが実装する箇所を減らすことができます。 サンプルコード aws-samplesの nft-image-generator でサンプルコードを公開しています。これを使用することにより、AWS Step FunctionsとAmazon Bedrockを組み合わせたNFT用画像生成の仕組みを体験することができます。 環境構築の方法や使用方法についてはGithubのドキュメントを参照してください。 実際に生成した画像 冒頭で作成した画像を入力画像として使用し、複数のバリエーションを生成しました。キャラクターのイメージやコンセプト、世界観などを維持しながら、髪色や髪型、メガネの色や形などが少しずつ異なる画像に仕上がったと思います。 Amazon Bedrockを使用して入力画像をベースに生成した画像 まとめ NFT用の画像生成には、生成AIを活用することで効率的に多様なバリエーションを作り出すことができます。 今回使用したアセットはaws-samplesのnft-image-generatorで公開しています。NFT用の画像生成についてチャレンジしたい方はご活用ください。 深津 颯騎 Amazon Web Service JapanのBlockchain Prototyping Engineer. Blockchain, Web3に関わるお客様を中心に技術支援を行っています。

はじめに AWS CloudFormation を利用するお客様から、リソースプロビジョニングの内部処理や、 AWS マネジメントコンソール や AWS Command Line Interface(AWS CLI) と比べてリソースまたはスタックのプロビジョニングに時間がかかる理由について質問をいただくことがあります。 そこで、この記事ではCloudFormation におけるリソースのプロビジョニングに影響する様々な要因について述べます。記事では特に、 CloudFormation やその他のInfrastructure as Code (IaC) ツールが信頼性の高いデプロイを確実に行うためのリソースの安定化について詳しく説明します。 また、CloudFormation スタックのデプロイ時間を最大 40 % 短縮し、新しい CONFIGURATION_COMPLETE ステータスを通じてリソースのプロビジョニングの可視性を高める、新しい楽観的な安定化方式についても紹介します。 AWS CloudFormation は、テンプレートファイルで AWS リソースやサードパーティリソースをモデル化できる IaC サービスです。CloudFormation スタックを作成することで、AWS CLI、マネジメントコンソール、 AWS SAM を介して手動で、または AWS CodePipeline を介して自動的にテンプレートで定義したリソースをプロビジョニングし、ライフサイクルを管理できます (CLI と SAM も活用可能)。あるいは Git sync を介して自動化することも可能です。 また、 AWS Cloud Development Kit (AWS CDK) を使用して、使い慣れたプログラミング言語でクラウドインフラストラクチャを定義し、CloudFormation 経由でプロビジョニングすることも可能です。または、 AWS Application Composer を活用して、アプリケーションアーキテクチャを設計、依存関係を可視化し、CloudFormation スタックを作成するためのテンプレートを生成することもできます。 CloudFormation スタックのデプロイ AWS CloudFormation を使用したコンテナ化されたアプリケーションのデプロイを確認して、CloudFormation のリソースプロビジョニングを理解しましょう。 図 1. ECSサービスをデプロイするためのサンプルアーキテクチャ コンテナ化されたアプリケーションをデプロイするには、 Amazon ECS サービスを作成する必要があります。 ECS サービスを設定するには、ECS クラスター、 Amazon ECR リポジトリ、タスク定義、セキュリティグループやサブネットなどの関連する Amazon VPC インフラストラクチャが最初に存在する必要があります。 インフラストラクチャとアプリケーションのデプロイの両方を AWS CloudFormation で管理したいため、最初に以下を含む CloudFormation テンプレートを定義します。 ECS クラスターリソース ( AWS::ECS::Cluster )、タスク定義 ( AWS::ECS::TaskDefinition )、ECR リポジトリ ( AWS::ECR::Repository )、サブネット ( AWS::EC2::Subnet ) やセキュリティグループ ( AWS::EC2::SecurityGroup ) などの必要な VPC リソース。 そして最終的に ECS サービス ( AWS::ECS::Service ) 自体です。 このテンプレートを使用して CloudFormation スタックを作成すると、ECS サービス ( AWS::ECS::Service ) は、他のリソースの作成が完了するのを待つため最後に作成されます。このように、リソースには依存関係があります。 リソースの依存関係: CloudFormation では、リソースが先に作成される他のリソースと依存関係を持つことがあります。リソースの依存関係には 2 種類あります。 暗黙的: CloudFormation は、リソースが別のリソースを参照するために 組み込み関数 を使用する場合、依存関係を自動的に推測します。これらの暗黙の依存関係により、リソースが適切な順序で作成されます。 明示的: 依存関係は、 DependsOn 属性を使用してテンプレートに明示的に定義することができます。これにより、リソースの作成順序を調整できます。 次のテンプレートスニペットでは、ECS サービスの依存関係を依存関係グラフで可視化しています: テンプレートスニペット: ECSService: DependsOn: [PublicRoute] #明示的な依存関係 Type: 'AWS::ECS::Service' Properties: ServiceName: cfn-service Cluster: ! Ref ECSCluster #暗黙的な依存関係 DesiredCount: 2 LaunchType: FARGATE NetworkConfiguration: AwsvpcConfiguration: AssignPublicIp: ENABLED SecurityGroups: - ! Ref SecurityGroup #暗黙的な依存関係 Subnets: - ! Ref PublicSubnet #暗黙的な依存関係 TaskDefinition: ! Ref TaskDefinition #暗黙的な依存関係 依存関係グラフ: 図 2. コンテナ化されたアプリケーションのCloudFormationにおける依存関係グラフ 注: 上図の VPC リソースには、PublicSubnet ( AWS::EC2::Subnet )、SecurityGroup ( AWS::EC2::SecurityGroup )、PublicRoute ( AWS::EC2::Route ) が含まれています。 上のテンプレートスニペットでは、ECS サービス ( AWS::ECS::Service ) リソースは、DependsOn 属性を使用して PublicRoute リソースに対する明示的な依存関係を持っています。 ECS サービスには、ECSCluster、SecurityGroup、PublicSubnet、TaskDefinition リソースに対する暗黙的な依存関係もあります。 明示的な DependsOn がなくても、CloudFormation はこれらのリソースが ECS サービスから参照される前に作成される必要があるとわかります。これはサービスが Ref 組み込み関数を使用してこれらのリソースを参照しているためです。 テンプレートファイルの定義に基づいて CloudFormation がリソースを特定の順序で作成する方法を理解したので、これらのリソースをプロビジョニングするのにかかる時間を見てみましょう。 リソースプロビジョニング時間: CloudFormation がスタックをプロビジョニングするための総時間は、テンプレートで定義された各リソースを作成するのにかかる時間に依存します。リソースごとのプロビジョニング時間は、次のいくつかの時間要素によって決まります。 エンジン時間: CloudFormation エンジン時間とは、リソースに関連するデータの読み取りと保存にサービスが費やした時間を指します。これには、CloudFormation テンプレートの解析と解釈の時間、 Fn::GetAtt や Ref などの 組み込み関数 の解決にかかる時間が含まれます。 リソース作成時間: リソースを作成し構成するために AWS サービスが実際に必要とする時間です。これは、サービスがプロビジョニングするリソースの種類によって異なります。 リソース安定化時間: リソースが作成された後、利用可能な状態に達するまでに必要な時間です。 リソース安定化とは AWS リソースをプロビジョニングする際、CloudFormation は基盤となるサービスに必要な API 呼び出しを行い、リソースを作成します。作成後、CloudFormation はリソース安定化プロセスとして、リソースがトラフィックを処理する準備ができていることを確認するための最終的なチェックを実行します。例えば、アプリケーションで ECS サービスを作成した場合、作成完了直後 (作成時) にサービスをすぐに利用できるわけではありません。CloudFormation は、ECS サービスのリソースに特化した追加の検証チェックを実行することで、ECS サービスが利用可能であることを確認します。リソース安定化は CloudFormation に限った話ではなく、あらゆる IaC ツールで、ある程度の対応が必要になります。 安定化基準と安定化タイムアウト CloudFormation がリソースを CREATE_COMPLETE とマークするためには、そのリソースが 特定の安定化基準を満たす必要があります。この確認により、リソースが作成されただけでなく、使用可能な状態であることが検証されます。 リソースが許容される安定化タイムアウト期間内に、安定化基準を満たせない場合、CloudFormation はリソースの状態を CREATE_FAILED としてマークし、オペレーションをロールバックします。 安定化の基準とタイムアウトは、CloudFormation でサポートされている各 AWS リソースごとに、サービスによって独自に定義されており、リソースの作成と更新のワークフローの両方に適用されます。 AWS CloudFormation と AWS CLI によるリソースのプロビジョニング 次に、 AWS CLI を使って同様の ECS サービスを作成します。 以前 CloudFormation で作成したタスク定義、ECS クラスター、VPC リソースを使って、次の AWS CLI コマンドを実行すると ECS サービスをデプロイできます。 コマンド: aws ecs create-service \     --cluster CFNCluster \     --service-name service-cli \     --task-definition task-definition-cfn:1 \     --desired-count 2 \     --launch-type FARGATE \     --network-configuration "awsvpcConfiguration ={ subnets = [subnet-xxx],securityGroups = [sg-yyy],assignPublicIp = ENABLED }" \     --region us-east-1 以下の出力結果は、上記のコマンドによってECS サービスが正常に作成され、ステータスが ACTIVE になっていることを示しています。 図 3. ECSサービスに対するコマンド実行結果 しかし、ECS コンソールに移動しサービスを確認すると、タスクは Pending 状態のままで、アプリケーションにアクセスできません。 図 4. ECSコンソールの表示 サービスが安定した状態に至るのを待ってから、アプリケーションにアクセスする必要があります。 図 5. ECSサービスのイベント AWS CloudFormation を使用して同じ ECS サービスを作成する場合、リソースがスタックの CREATE_COMPLETE ステータスに達すると、すぐにサービスにアクセスできます。この確実な可用性は、CloudFormation のリソース安定化プロセスによるものです。 ECS サービスを初期作成した後、CloudFormation は待機し、サービスが安定するまでECS の DescribeServices API アクションを継続的に呼び出します。 ECS サービスがチェックに合格して使用準備が整ったら、そのときはじめて CloudFormation がスタックのリソース状態を CREATE_COMPLETE とマークします。 このような作成と安定化のオーケストレーションにより、遅延なくサービスにアクセスできるようになります。 次の出力は、 CloudFormation が安定化の間に DescribeServices API 呼び出しを行っていることを示す AWS CloudTrail のイベント履歴です。 図 6. AWS CloudTrailのイベント履歴 CloudFormationは、リソース安定化の処理を行うことで、リソース作成後のカスタムステータスチェックや可用性のポーリングロジックの実装に伴う余分なコーディング作業と複雑さを避けることが出来ます。この機能が無いと、AWS CLIやAPIなどのツールを使って、すべてのインフラストラクチャとアプリケーションリソースに対して追加のロジックを開発する必要があります。CloudFormationに組み込まれた安定化オーケストレーションを使えば、テンプレートを一度デプロイするだけで、作成後にサービスが完全に準備できていることを信頼できるため、アプリケーション機能の開発に集中できます。 安定化戦略の進化 CloudFormation の安定化戦略では、リソース作成と安定化プロセスが連動しているため、リソースのプロビジョニングが完了したと見なされるのは、安定化が完了した場合のみです。 従来の安定化戦略 相互に依存関係のないリソースについては、CloudFormation は同時並行でプロビジョニングを開始します。しかし、あるリソースが他のリソースに依存している場合、CloudFormation は依存先リソースのプロビジョニング操作が完全に終了するまで待ってから、依存リソースのプロビジョニングを開始します。 図 7. CloudFormationの従来の安定化戦略 上の図は、AWS CloudFormation を使用してデプロイする一部の ECS アプリケーションリソースのデプロイを示しています。Task Definition (AWS::ECS::TaskDefinition) リソースは ECR Repository (AWS::ECR::Repository) リソースに依存しています。また、ECS Service (AWS::ECS:Service) リソースは Task Definition と ECS Cluster (AWS::ECS::Cluster) の両方のリソースに依存しています。ECS Cluster リソースには依存関係は定義されていません。CloudFormation は ECR Repository と ECS Cluster リソースの作成を並列で開始します。その後、Task Definition リソースのプロビジョニングを開始する前に、ECR Repository が整合性チェックを完了するのを待ちます。同様に、ECS Service リソースの作成は、Task Definition と ECS Cluster リソースが作成され、準備ができた後にのみ開始されます。この順次的なアプローチは安全性と安定性を確保しますが、遅延が発生します。CloudFormation は厳密に依存するリソースを順番に 1 つずつデプロイするため、全体のスタックのデプロイが遅くなります。相互に依存するリソースの数が増えると、全体のスタックデプロイ時間が長くなり、ボトルネックが発生し、スタック全体の操作が遅くなります。 新しい楽観的な安定化戦略 スタックのプロビジョニング時間とデプロイのパフォーマンスを改善するため、AWS CloudFormation は最近、新しい楽観的な安定化戦略を導入しました。 この戦略により、お客様のスタックデプロイ時間を最大40%短縮できます。依存リソースを並列に作成できるようになり、これによりデプロイ速度が大幅に向上します。 図 8. CloudFormationの新しい楽観的な安定化戦略 上の図は、過去の戦略で説明した同じ 4 つのリソースのデプロイを示しています。Task Definition (AWS::ECS::TaskDefinition) リソースは ECR Repository (AWS::ECR::Repository) リソースに依存し、ECS Service (AWS::ECS::Service) リソースは Task Definition と ECS Cluster (AWS::ECS::Cluster) の両方のリソースに依存しています。 ECS Cluster リソースには依存関係の定義がありません。 CloudFormation は、ECR Repository と ECS Cluster リソースの作成を並列で開始します。 その後、ECR Repository が安定化するのを待たずに、ECR Repository の作成が完了したら Task Definition の作成を開始します。 同様にECS Service リソースの作成は、Task Definition と ECS Cluster の作成が完了した後に開始されます。 この変更は、すべてのリソースが依存リソースの安定化を待つ必要がないためです。 もしTask Definition または ECS Cluster リソースの安定化が完了していないことで ECS Service のプロビジョニングが失敗した場合は、CloudFormation がその依存関係の安定化を待ってから、ECS Service の作成を再試行します。 図 9. CloudFormationの新しい安定化戦略での再試行 暗黙的な依存関係を持つリソースの作成ワークフローでは、この依存リソースの並列作成と自動再試行機能により、従来の直列リソースプロビジョニング戦略に比べてデプロイ時間が短縮されます。 なお明示的な依存関係を持つリソースについては、CloudFormation が従来の戦略を利用してリソースをデプロイします。 リソースプロビジョニングの可視性向上 CloudFormation スタックを作成するとき、リソースのプロビジョニングに時間がかかり、IN_PROGRESS 状態が継続しているように見える場合があります。これは、CloudFormation がリソースの安定化を待機しているためです。 リソースのプロビジョニング状況の可視性を改善するために、CloudFormation は新しい CONFIGURATION_COMPLETE イベントを導入しました。 このイベントは、作成ワークフローの中でリソースの作成または設定が完了したが、安定化プロセスがまだ進行中のときに、個々のリソースレベルと全体のスタックレベルの両方で発行されます。 図 10. ECSアプリケーションのCloudFormationスタックイベント 上の図は、ECSApplication という名前の ECS アプリケーションの CloudFormation スタックについて、スタックイベントの出力結果を示しています。 イベントを下から上へ確認してみましょう。 10:46:08 UTC-0600 – ECSService (AWS::ECS::Service) リソースの作成が開始されました。 10:46:09 UTC-0600 – ECSService はステータスタブで CREATE_IN_PROGRESS ステータス、詳細ステータスタブで CONFIGURATION_COMPLETE ステータスとなり、リソースが正常に作成され、整合性チェックが開始されました。 10:46:09 UTC-0600 – スタック ECSApplication はステータスタブで CREATE_IN_PROGRESS ステータス、詳細ステータスタブで CONFIGURATION_COMPLETE ステータスとなり、ECSApplication スタック内のすべてのリソースが正常に作成され、安定化処理が行われていることを意味します。 このスタックレベルの CONFIGURATION_COMPLETE ステータスは、スタックの概要タブでも表示できます。 図 11. ECSApplicationスタックの概要 10:47:09 UTC-0600 – ECSService のステータスタブに CREATE_COMPLETE ステータスが表示されており、サービスが作成され、整合性チェックが完了したことを意味します。 10:47:10 UTC-0600 – ECSApplication のステータスタブに CREATE_COMPLETE ステータスが表示されており、すべてのリソースが正常に作成され、整合性チェックが完了したことを意味します。 結論: この記事では、CloudFormationがリソースをデプロイする方法と、スタックおよびそのリソースの作成に影響する様々な時間要因について理解を深めていただけたと思います。また、リソース安定化のために CloudFormation が内部で行っていることと、可用性の高い本番インフラストラクチャのデプロイメントで、リソースを安全かつ確実にプロビジョニングする方法について詳しく見てきました。最後に、スタックのデプロイ時間を短縮し、リソースのプロビジョニングの可視性を向上させる新しい楽観的な安定化戦略についても解説しました。 本記事は、Bhavani Kanneganti と Idriss Laouali Abdou による How we sped up AWS CloudFormation deployments with optimistic stabilization を翻訳したものです。翻訳はソリューションアーキテクトの木村友則 ( @tkimurz ) が担当しました。

製造業の様々なお客様は、デジタル変革のジャーニーのそれぞれに異なる段階にあるため、変革プロセスにどのように取り組むかについても異なった志向を持っています。 製造業のお客様はデジタル変革を加速するため、データから洞察を引き出しビジネス成果を実現することに注目してますが、こうしたことは、データレイク、IoT(モノのインターネット)、機械学習(ML)、人工知能(AI)などのテクノロジーによって、これまでになく簡単になりました。製造業のお客様は、データから洞察を引き出し、ビジネス成果を実現することで、デジタル変革を加速したいと考えています。さらに、生成AI、デジタルツイン、デジタルエンジニアリングなどのテクノロジーは、昨今、製造業界を席巻しています。 このブログでは、2024 年の製造業イノベーションの 3 つのトレンドである、生成 AI、デジタルツイン、デジタルエンジニアリングと、これらのテクノロジーをクラウドで活用することが、製造業のお客様のイノベーションを推進するのにどう役立つかを紹介します。 １：製造業における生成AI Precedence Research によると、2032 年までに製造業界で AI に費やされる金額は 684 億ドルに達すると推定されています。これは今後 9 年間で約 33.5 %の投資の増加に相当します。このような投資の増加には、企業全体で生成 AI 技術が採用されつつあることが影響しています。生成 AI は、製造企業がより効率的に事業を運営できるようにし、製品開発と生産を加速し、設備の寿命を延ばし、装置のダウンタイムを短縮し、生産設備の効率を向上させます。例えば製造業における 3 つの一般的な生成 AI アプリケーションには、設備マニュアルや各種社内文書の要約、自然言語による製品検索、設備の異常の解決などがあります。 設備マニュアルや各種社内文書の要約 Retrieval Augmented Generation(RAG) などの技術を使用することで、企業は社内文書や設備マニュアルへのアクセスを大規模言語モデル(LLM)に提供できるようになり、従業員が会社の方針、設備の構成、故障の解決手順に関する情報をより迅速に見つけるのに役立ち、生産性が向上します。 さらにRAG は、これまで手動で作成されていたドキュメントを企業の内部情報を使用して自動的に作成する機能を提供します。 従業員はさまざまなコンテキストにわたる質問をすることができます。 たとえば、「溶接機の空気圧ゲージが壊れました。どう修理したらよいでしょうか?」という質問は、溶接機のマニュアルから生成した修理手順の説明を返します。 「次の 20 個の製品の部品表(BOM)を生成してください」というリクエストを入力すると、内部データベースから各製品の価格が引用されたBOMが生成されます。「近々休暇があるのですが、会社の有給休暇の方針は何ですか?」と言えば、企業の文書を元にした回答が得られます。 このRAGアプリケーションは、1 週間以内にセットアップでき、生産性にすぐに良い影響を与えるため、企業が最初に実施するケースであることが多いです。 このソリューションを構築するための例となるアーキテクチャは、 AWS ソリューションライブラリ の Generative AI Application Builder on AWS ソリューションの「Text Use Case」セクションにあります。ビジネスとテクニカルなユースケースのために検証されたソリューションとガイダンスです。訳者補足：日本語で利用可能ですぐにデプロイできるリソースとして、 Generative AI Usecases JP があります。 自然言語による製品検索 自然言語による製品検索を使うと、企業の従業員や顧客が、会社の製品に関する情報を検索できるようになり、顧客体験が向上し、一度の検索で正しい製品を見つけることができます。「2010 年型のダッジ・チャージャーを持っています。取り付け労力が最も低く、現在在庫がある部品で馬力を上げるにはどうしたらいいですか?」「X 冷蔵庫を持っています。どのような間仕切りが中に収まりますか?」「配電盤 X 用の遮断器が必要です。現在の在庫にはどのようなものがありますか?」といった質問に、今ではすぐに答えることができます。この情報へのアクセス向上により、製品の返品率が下がり、顧客一人ひとりのニーズに合った最適な製品を受け取れるため、製品の評価が上がる傾向があります。情報が様々な場所に保存されている場合、LangChain などのツールやライブラリを使用して、様々なソースから情報をクエリすることができます。詳細なソリューションは、AWS Machine Learning ブログの投稿「 Reinventing the data experience: Use generative AI and modern data architecture to unlock insights. 」で見つけることができます。 設備の異常の解決 最近では、設備をモニタリングするためにセンサーを使用している製造企業は、エラーをより迅速に修復し、ダウンタイムを短縮するために生成 AI を利用し始めています。 センサーが設備のエラーを予測または検出した場合、エラーメッセージが LLM に送信され、LLM は設備の保守マニュアルにアクセスできるようにし、エラーを修正または防止するために必要な手順を生成し、この情報をオンサイトのエンジニアに送信して修復を促します。 ダウンタイムの短縮により、すべての製造プロセスが予定通りに進行し、顧客への出荷遅延の影響を最小化します。 設備の異常の解決ソリューションは、マニュアル要約ソリューションと同様のアーキテクチャを利用する一方で、デバイスをクラウドに簡単かつ安全に接続できるサービスである AWS IoT Core も利用します。 ２：デジタル設計による製品開発の効率化 現代の製品設計には、高度なデータ保存、コンピューティング、コラボレーションが必要です。多くの製造企業が、研究開発コストの削減、市場投入までの時間短縮、生産効率の最適化、サステナビリティ目標の達成、新たな収益源の創出のために、デジタルエンジニアリングの活用を検討しています。AWSのお客様がデジタルエンジニアリングを活用している主な 4 つの分野は、計算機援用工学(CAE)、製品データおよび製品ライフサイクル管理(PLM)、コンピュータ支援設計(CAD)、電子設計自動化(EDA)です。 計算機援用工学(CAE) CAE は、製品設計の改善や幅広い産業分野における工学的問題の解決を支援する目的で、コンピューターソフトウェアを使用して性能をシミュレーションします。 CAE が対応するプロセスには、製品、プロセス、製造装置のシミュレーション、検証、最適化が含まれます。 製造業のお客様は、ますます複雑な設計や検証における課題に直面しています。 製造や設計で使用されるアプリケーションには、数値流体力学(CFD)、有限要素法(FEM)、電磁気および熱シミュレーション、設計最適化/ジェネレーティブデザイン設計、衝突/マルチフィジックス/マルチボディシミュレーションなどがあります。 これらの問題を解決し、ユースケースをサポートするために、多くのお客様は、 AWS Batch などのAWSサービスの助けを借りて、AWS クラウドでコンピューティングを大規模に利用しています。AWS Batch は、あらゆる規模のバッチ処理・MLモデルトレーニング・分析を提供し、 AWS ParallelCluster は、AWS上に高性能コンピューティング(HPC)クラスタを簡単にデプロイ・管理できるオープンソースのクラスタ管理ツールです。たとえば、主要な医薬品の製造販売企業である Amgen は、これらのソリューションを通じて、計算流体力学シミュレーションを実行するためのプラットフォームを提供し、科学者・エンジニアの利用とデータの量の大幅な急増を目の当たりにしました。 Amgen のプリンシパルデータエンジニア(情報システム部のシニアマネージャー)の Justin Porth と、Amgen の情報システム部のディレクターである Venki Anantharam は、「このイニシアチブの一環として Amgen の HPC の能力向上は、情報システム整備計画と設計標準に完全に合致したものです 」と述べています。CAE の AWS ソリューションの詳細については、AWSソリューションライブラリの Scale-Out Computing on AWS ソリューションをご覧ください。 製品ライフサイクル管理(PLM) PLM は、製品開発に関連するコスト、時間を削減し、リスクを低減するのに役立ちます。AWS 上の製品ライフサイクル管理(PLM)ソリューションは、可用性性とコンプライアンスの要件を満たしながら、PLM パフォーマンスを向上させ、データサイロ化を脱却するのに役立ちます。製造業のお客様は、この分野でしばしば3つの大きな課題に直面します。性能・拡張性、データの不適合、グローバルでの協働です。 これらの課題を解決するために AWS ソリューションを利用する顧客は、次のようなメリットが期待できます。(1)意図せぬ開発工程の繰り返しを避け、市場投入までの時間を改善する。(2)イノベーションや検証のためのエンジニアリングに費やす時間が短縮される。(3)作業のやり直しを減らして品質が向上する。 Rivian の CIO である Madhavi Isanaka は、「AWS とパートナーシップを結ぶことで、Rivian は ITではなく、持続可能な製品データとライフサイクル管理、デリバリーに集中できるようになりました。そして私たちは AWS上では、重要な開発アプリケーションをオンプレミスよりも高速で実行しています。Elements は 56 %高速、Siemens は 35 %高速、Ansys は 20 %高速です」と述べています。 PLM を効率化するために AWS サービスの利用を開始するには、AWS ソリューションライブラリの PLM ソリューション をご覧ください。 コンピュータ支援設計(CAD) コンピュータ支援設計(CAD) とは、コンピュータを使用して設計情報の作成、変更、分析、最適化を支援することです。製造業の顧客は、リモートワークが研究開発者や研究開発チームの恒久的なソリューションになったことで、協調作業に関する課題が増加し、設計がますます複雑になる問題に直面することがよくあります。同時に、産業界の顧客は、製品をより速く市場に出すプレッシャーにさらされ、設計の再利用性を高めながらコストを削減する必要があります。 研究開発チームが新製品の導入に伴うコスト、時間を減らし、リスクを低減するのを助けるために、多くのお客様が Amazon AppStream 2.0 のようなアプリケーションストリーミング、 Amazon WorkSpaces のようなデスクトップのストリーミングの AWS マネージドサービスを使用しています。AppSteam2.0 は、アプリケーションへの安全で信頼できるスケーラブルなアクセスをどの場所からでも提供します。また、WorkSpaces は、あらゆる設計者のための包括的な機能を持ち、永続的に利用可能な仮想デスクトップです。 Onshape の技術運用担当副社長の John Rousseau は、「Onshapeは2013年からAWSを使用してCADサービスを提供してきました。その間ずっと、AWS を選択したことを疑ったことは一度もありません。AWSのサービスのグローバルな信頼性により、私のチームは Onshape の顧客体験の改善に集中することができます。AWSの セキュリティインフラとツールは、顧客のデータを保護するのに大いに役立ちます」詳細は、AWS ソリューションライブラリの エンジニアリングデザインアプリケーションとデスクトップのソリューション をご覧ください。 電子設計自動化(EDA) 電子設計自動化(EDA) は、集積回路やプリント回路基板などの電子システムを設計するためのソフトウェアツールのカテゴリーです。ますます複雑化するチップとシステム・オン・チップ(SoC)製品は、より大きな処理能力、メモリ、ストレージを必要としています。これは HPC の必需であることを意味します。AWS クラウド上に導入された EDA は、半導体サプライチェーン全体にまたがったこうした課題に対処するのに役立っています。 Arm のデザインイネーブルメント担当副社長 Philippe Moyer は、「AWS を使用することで、EDA ワークロード特性分析の実行時間は数ヶ月から数週間に短縮された」と述べています。 AWS 上の EDA ソリューションの詳細については、AWS ソリューションライブラリの ハイテクエレクトロニクスと半導体のソリューション をご覧ください。 3：デジタルツインによるパフォーマンスの最適化 製造業の顧客がイノベーションを起こしているもう 1 つの方法は、デジタルツインを使用して製造環境をモデル化することです。デジタルツインへの投資は引き続き増加しています。 MarketsandMarkets のレポートによると、デジタルツインの市場規模は 2023 年から 2028 年の間に年率61.3%で成長し、最終的には 1,101 億ドルの価値になると予測されています。これは、組織が運用効率の向上、ダウンタイムの削減、メンテナンスの改善などの可能性を認識しているため、製造業を含むさまざまな業種におけるデジタルツインの採用が増加していることを示してしています。 デジタルツインは、実世界の装置をその機能、特徴、動作とともに仮想環境でデジタル的に再現します。これは、リアルタイムで収集したスマートセンサーからのデータを使用して、物体の動作をシミュレートし、運用を監視することによって実現されます。デジタルツインは、個々の機械、生産ライン、エンドツーエンドの製造環境を再現できます。ユーザーはこれらの環境とのやりとりがリアルタイムで可能です。対象をリアルタイムでデジタル的にモデリングすることで、ビジネス価値を引き出す機会が開かれます。例えば、予測機能、パフォーマンスの微調整、遠隔監視とチューニング、効率性の向上などが含まれます。 製造業の企業は、イノベーションを推進し、運用能力を強化するためにデジタルツインに投資しています。例えば、 Siemens はデジタルツイン技術の可能性を認識し、その開発に多額の資金を注いでいます。物理的な設備のデジタル上の複製を作成することで、Siemens はその資産のパフォーマンスをシミュレートおよび最適化でき、品質と効率の向上につながります。例えば、 General Electric(GE) は、風力タービンのデジタルツインを使用しています。この技術は、予知保全機能とリアルタイムのパフォーマンス監視を実現しています。風速、発電量、温度、コンポーネントのストレスなどの情報が継続的に収集され、ほぼどこからでも監視できます。これにより、風の条件に基づく発電量など、さまざまなシナリオを関連チームが検討できるようになり、現場のエンジニアがタービンをより効率的に操作できるようになります。また、タービンと風車の群の生産性の追跡、予知保全の実施も容易になります。Siemens や GE による注目すべきこのような投資は、デジタルツインが製造業における運用上の優秀性を推進する戦略的ツールとして活用する重要性が高まっていることを浮き彫りにしています。 設計から生産準備までのプロセス最適化 データを連続的に取得することで、パフォーマンスと効率に関連するツール、在庫、データに関するリアルタイムに近い洞察を提供します。 最新のデータを手元に置くことで、ユーザーはパフォーマンスを最適化するのに役立つ意思決定を迅速に下すことができます。 これはまた、問題がより早く検出され、対処されることを意味します。その結果、設備と生産ラインのダウンタイムを短縮できます。 さらに、最新のデータにアクセスできることで、企業はリスクをより適切に評価し、より良い情報に基づいた運用上の意思決定を下すことができます。 例えば、上述のように、GE は 物理センサーからAWS 上でのデータの収集と分析を容易にするために、風力タービンのデジタルツインを使用しています。これにより、タービンの運用をリアルタイムに近い状態で分析して効率を上げることができます。 デジタルツインは「もし起こったら」というシナリオを実行し、出力、効率、ビジネスの結果にかかわるKPI の変更をモデル化するためにも使用できます。 GE は、発電出力に風がどのように影響するかなど、さまざまな「もしも」シナリオを検討するためにデジタルツインを使用しています。これにより、エンジニアはタービンをより効率的に運用できます。 例えば、今日の自動車業界では、新しい車の開発はほとんどが仮想環境で行われており、多くの企業がプロトタイプのデジタルツインを使用して設計を精緻化しています。ツインは通常、車のソフトウェア、機構、電装、物理的な動作を含む車両全体を対象とします。このモデリングにより、実際の部品を製造する前に、開発の各段階で問題を特定し、不具合の可能性を発見するシミュレーションや検証が可能になります。 たとえば物質の振る舞い、空気の流れ、熱の発生と蓄積を最適化することで、車の 3D データを使用して物理的な動作を模倣できます。 この方法を適用することで、企業は原寸大の試作車の数を減らすことができ、時間と費用を節約できます。 加えて、異なる分野の個人が同じプロジェクトで同時に作業できるようになり、異なる製品バージョンの構成が簡略化されます。 最後に、必要な設備を選択し、生産セルをデジタルで設計することで、すべての部品が製造セルでどのように組み合わさるかをシミュレートできます。 予知保全 デジタルツインは、機器のパフォーマンスに関するリアルタイムに近い洞察を提供することにより、製造業における設備保全を革新しており、コストのかかるダウンタイムを防ぐための予防保全を促進しています。 物理的な設備の仮想レプリカを作成することにより、企業は設備の運用を監視して、悪化する前に問題を特定し、操業の中断を最小限に抑えるために最適な時期にメンテナンスをスケジュールすることができます。 この予知保全アプローチは、設備の寿命を延ばすだけでなく、全体的な保守コストを削減して、運用効率と生産性を向上させます。 遠隔監視 デジタルツインは、遠隔監視を容易にします。これにより、製造業の企業は世界のほぼあらゆるところから資産を監視できるようになります。リアルタイムに近いデータの収集と分析により、企業は機器のパフォーマンスを評価し、非効率な箇所を特定し、生産プロセスを最適化するためにデータドリブンな意思決定を行うことができます。 さらに、リモートモニタリングにより、チームは問題に迅速に対応するツールを手に入れ、現地での調査の必要性を減らし、製造現場の全体的な安全性を向上させます。 結果として、デジタルツインを用いた予知保全とリモートモニタリングの採用が大幅に増加しており、企業はこのテクノロジーによる大幅なコスト削減と運用上のメリットを認識しています。 化学メーカーの INVISTA は、 AWS IoT TwinMaker を使用して製造環境をリモートで監視しています。INVISTA のオペレーション・トランスフォーメーション担当副社長 Jerry Grunewald は、「INVISTA は AWS IoT TwinMaker を利用して、複数の分散した場所の工場フロアからの運用に伴う通知と警告に、現地作業員が効率的に対処できるようにしています。 AWS IoT TwinMaker を使用することで、製造運用のデジタルツインを早く簡単に構築して、現地作業員に資産と運用データの統合ビューを提供できます。 このようにすることで、INVISTA の運用は、変革努力の結果としての『コネクテッドワーカー』のビジョンに向けて大きな進歩を遂げています。 たとえば、現地作業員は機器の異常の原因を特定し、適切な修正措置を特定することができます」 AWS IoT TwinMaker により、既存のデータソースを使用して、物理的な環境の仮想表現を作成できるため、お客様はデジタルツインのメリットを活用できます。 結論 製造業のイノベーションは、生成AI、デジタルツイン、デジタルエンジニアリングなどの技術の進歩によって加速しています。企業は、より速く効率的な製品開発、運用効率の向上、コストとリスクの削減などのメリットを享受しています。これらの分野への投資と採用は引き続き増加し続けていますが、製造企業はこれらのテクノロジーを活用して、業務をさらに革新させていくでしょう。全体として、製造業はクラウドを活用したイノベーションによって生産性、サステナビリティ、競争優位性を推進することができるのです。 AWS が製造業のお客様のイノベーションをどのように支援しているかをもっと知りたい場合は、AWS ソリューションライブラリの 製造および産業向けソリューション をご覧ください。また、これらのトレンドの実装にご興味がある場合は、AWS アカウントチームにお問い合わせください。 この投稿は「 Three trends in manufacturing innovation for 2024 」をAWS Japan SAの河村 聖悟、岩根 義忠が翻訳しました。 著者紹介 Brendan Jenkins Brendan Jenkins はソリューションアーキテクトであり、AWS の大企業のお客様を対象に、技術的なガイダンスを提供し、お客様のビジネス目標の達成を支援しています。専門は DevOps と機械学習テクノロジーです。 Andrew Walko Andrew Walko は AWS のソリューションアーキテクトで、自動車および製造業界の企業顧客を担当しています。データ分析、機械学習、人工知能の経験を持つ Andrew は、データを活用して顧客がビジネスを近代化できるよう支援しています Kait Healy Kait Healy は AWS のソリューションアーキテクトです。彼女は製造企業のお客様との連携を専門としており、主要なビジネス成果を促進するための機械学習と人工知能ソリューションの構築経験があります。 Michel Ngando Michel Ngando はソリューションアーキテクトであり、AWS の大企業のお客様を支援して技術ガイダンスを提供し、ビジネス目標の達成を支援しています。  

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 2週前から、 週刊AWS のOGP（SNSでシェアされたときや、ブログ一覧画面で表示される写真）がメンバー4名のものに更新されているのに気づいていただけたでしょうか？去年の夏ごろから4名体制になっていたのですが、先日ようやく4名で写真を撮ることができました。色々な面白い（？）OGPを用意していますので、こちらもお楽しみに。 さて、以前にQuickSightのコミュニティサイトで 日本語でディスカッションできるタグができたこと はお知らせしましたが、合わせてQLS(QuickSight Learning Series)と呼ばれる新機能等を解説するオンライン勉強会も日本語版が提供されることになりました。4月にその第一回が開催されます。QuickSightを利用中の方はぜひチェックしてみてください。 – QLS:新機能とデモ：バックアップとリストア機能でアセットを効率的に管理する それでは、先週の主なアップデートについて振り返っていきましょう。 2024年3月11日週の主要なアップデート 3/11(月) Amazon RDS for Db2 expands support for X2iedn instances in additional regions Amazon RDS for Db2 で X2iedn インスタンスが利用可能なリージョンが拡大され、東京・大阪両リージョンでも利用可能になりました。X2iednは高いコンピューティング能力(最大128 vCPU)、大容量メモリ(最大4 TB)、高いストレージスループット(最大256K IOPS)、32:1のメモリ対vCPU比を提供するように設計された、大規模DB用途に向いたインスタンスです。 Amazon Verified Permissions increases default quotas for authorization APIs Amazon Verified Permissions で、IsAuthorized APIとIsAuthorizedWithToken APIのデフォルトの処理能力クオーター(TPS)が30から200に引き上げられました。これらのAPIは名前の通りユーザーの認証とアクションの承認するために呼び出されるもので、より大規模な環境でも利用しやすくなりました。 CloudWatch Container Insights now delivers observability for NVIDIA GPUs on EKS Amazon CloudWatch Container Insights with Enhanced Observability for EKS がクラスター上のNVIDIA GPUに対して、observability (観測性)を提供するようになりました。この機能はCloudWatch Observability Add-on をクラスター上に導入することで利用可能です。これにより、GPU利用率やメモリの使用率の観測が容易になり、分散トレーニング時にリソースが効率的に利用されているかを確認しやすくなります。 Experience up to 40% faster stack creation with AWS CloudFormation AWS CloudFormation でスタック作成のスピードが最大40%速くなる改善が行われました。これまでスタックのイベントとしては CREATE_IN_PROGRESS と CREATE_COMPLETE のみでしたが、新たに CONFIGURATION_COMPLETE が導入されました。これはAWSサービスとの整合性チェックが完了するのを待ち始めたことを表すものですが、これを利用して CREATE_COMPLETE を待たずに依存するリソースのプロビジョニングを開始することができるようになりました。これにより待ち時間が減り、スタック作成が高速化されます。 3/12(火) Operationalize forecasting models and Fine-tuned FMs with SageMaker Canvas Amazon SageMaker Canvas と SageMaker Model Registry との統合が拡張され、時系列予測モデルと SageMaker JumpStart を利用したファインチューニングされた基盤モデル(FM)を利用するよう拡張されました。これによりワンクリックで、Amazon SageMaker Canvas で構築されたこれらの ML モデルを SageMaker Model Registry 登録することができ、本番環境へのデプロイを簡素化します。 AWS Backup now supports restore testing for Amazon Elastic Block Store (EBS) Snapshots Archive AWS Backup が Amazon EBS Snapshotからのリストアのテストをサポートしました。これにより、AWS Backup でバックアップ対象のAWSリソースに対し、容易にリストアのテストをしたり、テストの自動化が可能になります。 3/13(水) Amazon S3 Connector for PyTorch now supports writing checkpoints with PyTorch Lightning Amazon S3 Connector for PyTorch で、PyTorch Lightning モデルのチェックポイントをAmazon S3に直接保存することをサポートしました。これによりトレーニングジョブのコストとパフォーマンスを改善します。PyTorch Lightningは、PyTorchによるトレーニングのためのハイレベルなインターフェースを提供するOSSのフレームワークです。これまでのように、Amazon EC2インスタンスストレージにいったん保存する方式よりも最大40%高速になることが期待できます。 Amazon EFS now supports up to 20 GiB/s of throughput Amazon Elastic File System（Amazon EFS）は、フルマネージドのNFSサービスです。今回ファイルシステムあたりのスループットを、読みとりを最大 20 GiB/sに、書き込みを最大 5 GiB/sにそれぞれ性能向上させました（以前はそれぞれ10 GiB/sと、3 GiB/sでした）。先日、 EFSの機能解説動画と資料が公開された ので、こちらも合わせてご覧ください。 3/14(木) Anthropic’s Claude 3 Haiku Model now available on Amazon Bedrock Anthropic の基盤モデル(FM)である Claude 3 Haiku が Amazon Bedrock で利用可能になりました。Claude 3 ファミリー（Claude 3 Opus、Claude 3 Sonnet、Claude 3 Haiku）は、Anthropic の次世代の最先端モデルであり、その中でも Haiku は高速なレスポンスを提供するのが特徴です。詳細は こちらのブログをご覧ください 。これにより、Cloud 3 ファミリーのうち、SonnetとHaikuがBedrock上で利用可能になりました。なおOpusも近日の提供開始が予告されています。 Application Load Balancer enables configuring HTTP client keepalive duration Application Load Balancer (ALB)で、クライアントとロードバランサー間の通信における HTTP Client Keepalive の時間を設定できるようになりました。HTTP Client keepaliveはALBがクライアントとのHTTP接続を維持する最大時間を指定するもので、最小60秒から最大7日間の値を設定できるようになりました（デフォルトは3600秒です）。 3/15(金) Amazon Timestream for InfluxDB is now generally available Amazon Timestream for InfluxDB が一般提供開始(GA)になりました。東京リージョンでもすでに利用可能です。フルマネージドのInfluxDBサービスであり、InfluxData社とAWSとのパートナーシップにより実現しました。また、これまでのAmazon Timestreamは、Timestream for LiveAnalyticsという名前になり、InfluxDBと平行して選択可能になっています。詳細は こちらのブログをご覧ください 。 Amazon CloudWatch Synthetics now supports 30-day historical data on canary runs Amazon CloudWatch Synthetis はWeb アプリケーションやAPI を簡単に監視できるようにするサービスで、エンドポイントの継続的なテストを実現します。今回そのテスト(Canary run)の結果を履歴として最大30日間保存可能に拡張しました（以前は最大7日間でした。この履歴には実行時のスクリーンショット、HARファイル、ログファイルなどが含まれます。 最後に2つ紹介させてください。1つ目は株式会社明治が、30年基幹システムで使ってきたメインフレームのワークロードをAWSにマイグレーションしたという事例です。 AWS Mainframe Modernization というメインフレームのモダナイゼーションを支援するための仕組みを活用されたもので、食品業界だけでなく、多くの日本企業に参考になる事例ではないかと思います。 – 株式会社 明治、老朽化した基幹システムをクラウドで近代化　AWS Mainframe Modernizationを活用した日本国内初のお客様に もう1つは、IBM Db2 をAWSにマイグレーションを検討される方向けのオンラインセミナーです。私も久しぶりにセミナー講師をやる予定です。オンプレミス上でDb2を利用している方はぜひご参加ください。AWSの基本的な部分からご説明する内容になっています。4月11日午前10時～12時の予定です。 – IBM Db2 の資産を AWS で活用する ~ Amazon RDS for Db2 の概要とマイグレーション支援サービス ~ それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

この投稿はアクセンチュア株式会社 テクノロジーコンサルティング本部所属の金　敬源氏と、マネージャー 竹内 誠一 氏に、Amazon Connect と Amazon Bedrock を活用したチャットボット構成におけるタイムアウトの制約とその回避策について寄稿いただいたものです。 はじめに このブログでは、Amazon Connect と Amazon Bedrock を活用したチャットボットの構成におけるタイムアウトの制約とその回避案について紹介します。 以下は、このブログの構成です： 背景 チャットボット構成と制約 タイムアウト回避のアプローチ タイムアウトの回避策 結論 背景 あるクライアントから、「Amazon Bedrock を活用してチャットボット回答の作成・メンテナンスの手間を減らしたい」「Amazon Bedrock の回答に納得できない場合はコンタクトセンターのオペレータとリアルタイムでチャットしたい」という要件をいただき、新たなチャットボットのプロトタイプを作成しました。 このプロトタイプの特徴は以下の通りです: Amazon Bedrock を活用してチャットボット回答の作成・メンテナンスの手間削減 検索拡張生成 (RAG、Retrieval Augmented Generation) と呼ばれる手法を採用 データストア として Amazon Kendra を活用 Amazon Bedrock のモデルとして Anthropic Claude 2 を活用 Amazon Bedrock の回答に納得できない場合はコンタクトセンターのオペレータとリアルタイムでチャット コンタクトセンター・ソリューションとして Amazon Connect を活用 チャットボットからオペレータへの引き継ぎを Amazon Connect のコンタクトフローで実装 データストアとして Amazon Kendra を採用した検索拡張生成(RAG)である点が大きな特徴ですが、その技術的な要点についてはこちらの AWS ブログを始めとして多くの解説記事がありますので、本ブログでは省略します。 [ 高精度な生成系 AI アプリケーションを Amazon Kendra、LangChain、大規模言語モデルを使って作る ] このプロトタイプではチャットボットの応答のタイムアウトが課題となったのですが、Amazon Connect 固有の制約によるものなので一般にはあまり知られていないと思います。本ブログではこの課題と回避策に焦点をあてて私たちの知見を紹介します。 チャットボットの構成と制約 今回のチャットボットのアーキテクチャは以下の通りです。 図1. Amazon Connect と Amazon Bedrock を活用したチャットボットのアーキテクチャ（タイムアウト回避策実装前） 質問者からの入力テキストは一旦 Amazon Connect が受信し、状況に応じてチャットボットやオペレータに転送します。Amazon Connect では、電話やチャットの着信があった時、その処理の流れを定義するコンタクトフローがあります。コンタクトフローのブロックの1つに「顧客の入力を取得する」があり、入力テキストを受け取って条件によって Amazon Lex や他のブロックに分岐することができます。 ただし、このブロックの Amazon Lex 呼び出しには、 「Amazon Connect の機能仕様」の「チャットの機能仕様」 に記述されているように、Amazon Connect から Amazon Lex チャットを呼び出した場合には、6秒以内に応答がないとタイムアウトになる、という制約があります。 この制約は、上限緩和の申請をしても変更することができません。ただし、これはチャット限定の制約で、電話から音声で呼び出された場合には該当しません。ちなみに今回のコンタクトフローでは、「顧客の入力を取得する」ブロックがタイムアウトを検知するとエラーに分岐され、「切断」ブロックに遷移し、チャット UI に”Chat has ended!”を返してフローを終了します。 図2. タイムアウト検知時のチャット UI 画面 （Amazon Connect のチャットウィジェットを使用） タイムアウト回避のアプローチ FAQ を検索して結果を応答するという従来型のチャットボットであれば、6秒というタイムアウトは厳しい制約ではありません。しかし、大規模言語モデルを使った Amazon Bedrock のようなサービスは応答時間が6秒を超えることがあるため、Amazon Connect チャットから呼び出す場合にはタイムアウトも想定して設計する必要があります。 このタイムアウトの回避策として、2つのアプローチを考えられます。 6秒以内に回答を生成できるようにAmazon Kendra と Amazon Bedrock を最適化 Amazon Lex は Amazon Bedrock を呼び出したら直ちに「顧客の入力を取得する」ブロックにリターンし、非同期の処理で Amazon Bedrock の応答をチャット UI に送付 チャットボットの場合、質問内容、つまり Amazon Bedrock に引き渡されるプロンプトのチューニングがしづらく、1は PoV (Proof of Value) の期間内に実現できない可能性が高いと判断し、今回は2を追求することにしました。 タイムアウトの回避策 以下は、2つ目の方法のアーキテクチャを示しています。 図3. タイムアウト回避策実装後のチャットボットのアーキテクチャ 最初のアーキテクチャと同様に、質問者の入力をコンタクトフローの「顧客の入力を取得する」ブロックにて受け取り、Amazon Lex に送信します。Amazon Lex から呼び出された AWS Lambda 関数(以下、Lambda 関数)は、別の Lambda 関数を非同期に呼び出し、「AI 検索中」のメッセージを返して、直ちに終了します。これにより「顧客の入力を取得する」ブロックのタイムアウトを回避します。 非同期に呼び出された Lambda 関数は、質問者の入力で Amazon Kendra を検索し、質問と検索結果を Amazon Bedrock に渡して回答文を生成させ、生成した回答文を Amazon DynamoDB に保存します。 この仕組みにより、タイムアウトの制約を回避しながら Amazon Bedrock を呼び出すことができるようになりました。 次に、Amazon DynamoDB に保存された回答文をチャット UI に届ける仕組みを説明します。上図のループの部分に Amazon Connect が Lambda 関数を介して回答文を入手していることを示しましたが、仕組みの大部分は Amazon Connect のコンタクトフローで実装されているので、ここからはコンタクトフローを参照しながら説明することにします。 非同期に実行する処理の完了を検知したい時の常とう手段として、「処理完了時にイベントを発行させる方法」と、「定期的に処理の状態をチェックする方法」がありますが、今回は後者を採用しました。前者はイベントを発行する仕組みと受け取る仕組みが必要で、Amazon DynamoDB はテーブル更新時に Amazon EventBridge イベントを発行できるのですが、コンタクトフロー側にこのイベントを受け取る手段がありませんでした。 後者の方式はコンタクトフローでも簡単に実装できます。以下に今回実装した仕組みを紹介します。 まずコンタクトフローを示します。 図4. タイムアウト回避策を実装した Amazon Connect コンタクトフロー 次に、このコンタクトフローの処理の流れを順に説明します。 1.「顧客の入力を取得する」ブロック 質問者からの入力を受け取り、Amazon Lex を内部で呼び出します。Amazon Lex は Amazon Bedrock の応答を待たずにリターンするので、タイムアウトすることはありません。Amazon Lex から正常応答を受け取ったら２に遷移します。 2.「待機」ブロック 2～5でループを構成し、そのループを1秒間隔で20回繰り返すことにしました。その1秒間隔をここで定義しています。 3.「AWS Lambda 関数を呼び出す」ブロック Amazon DynamoDB に保存された回答文を取りに行く Lambda 関数を呼び出します。 4.「コンタクト属性を確認する」ブロック 3の Lambda 関数の戻り値を確認し、条件分岐します。「回答文待機中」の場合は5に遷移し、「回答文有」の場合は6-Bに遷移します。 5.「ループ」ブロック ループ回数をカウントして条件分岐します。回数上限は20としました（最大100でセット可能）。ループ回数が20回に到達するまでは2に遷移し、20回に到達したら6-Aに遷移します。 6-A.「プロンプトの再生」ブロック チャット UI への応答にタイムアウトメッセージをセットして1に戻ります。 6-B.「プロンプトの再生」ブロック チャット UI への応答に、Amazon DynamoDB から Lambda 関数経由で 受け取った回答文をセットして、1に戻ります。 チャットボットの実行例 最後に、今回紹介した方法を組み込んだチャットボットの実行例を紹介します。質問をチャット UI に入力すると、Amazon Connect コンタクトフローが Lambda 関数を呼び出し、Lambda 関数が Amazon Kendra の検索とジェネレーティブ AI による回答文の生成を実行し、ループしながら待機していたコンタクトフローが回答文を受け取って、タイムアウトすることなくチャット UI に回答文を表示できました。Amazon Kendra にはあらかじめ本ブログのドラフトが保存してあり、これを要約したものが回答文として生成されました。 図5. タイムアウトを回避して応答を返した時のチャット UI 画面 （Amazon Connect のチャットウィジェットを使用） 結論 本ブログでは、Amazon Connect のチャットボットから Amazon Bedrock を呼び出す場合に、Amazon Lex 呼び出しが6秒でタイムアウトするという制約が課題になることを指摘し、Lambda 関数の非同期化とコンタクトフローの工夫による現実的なタイムアウト回避策を提示しました。一般的にはチャットボットを実装する際にわざわざ Amazon Connect を経由させたりしませんが、コンタクトセンターのオムニチャネル戦略構想では電話とチャットの併用はよくあることですし、電話やチャットへの自動応答への期待も Amazon Bedrock の普及により益々高まっています。 今後の新たなモデルの登場・サービスの改善により今回指摘した制約が回避できるようになる可能性も期待していますが、今回あげたケースのようにタイムアウトの可能性が排除できない時には、本ブログで紹介した方法が参考になれば幸いです。 著者について 金　敬源 アクセンチュア株式会社　テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属 竹内 誠一 アクセンチュア株式会社 マネジャー　テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属

セキュリティは AWS 、そしてすべてのお客様にとって最優先事項です。ＡＷＳではセキュリティに特化した教育型のカンファレンスである AWS re:Inforce を開催し、お客様とともにセキュリティを学びセキュリティの文化を広める場を提供しています。2024年は、6月10日～12日にペンシルベニア州フィラデルフィアで開催されますが、本カンファレンスの登録開始とともに 日本語の紹介ページが開設されました のでご案内です。 AWS re:Inforce とは 「AWS re:Inforce」は、 AWS のセキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに特化したグローバルな学習型カンファレンスです。 AWS セキュリティのエキスパートやパートナーとともに、最先端のセキュリティ情報を短時間で効率的に収集できます。 2024年は、会場をペンシルベニア州フィラデルフィアに移し、開催期間も2日半に拡大し、コンテンツをさらに充実いたしました。最新情報の共有やクラウドセキュリティやコンプライアンスに関する学びの場を提供するとともに、コミュニティのさらなる拡大を図ります。 re:Inforce に参加することで、 AWS のセキュリティサービスとソリューションを使用したクラウドセキュリティの改善方法を、より深く、より包括的に理解することができます。また、 AWS のエキスパートから、より安全なシステムの構築方法を学び、組織のセキュリティ体制を改善するための実用的なソリューションを得ることが可能です。また、日本のお客様が、初心者から熟練者まで、参加者がより学習に集中できる環境を提供するために、公認ツアーを用意しています。ツアーに関しては こちらのページから確認 いただければ幸いです。  見どころ：基調講演や様々なセッション AWS の CISO (最高情報セキュリティ責任者) である Chris Betz が、クラウドセキュリティの最新動向や AWS のセキュリティカルチャーについて、また AWS がどのように生成AI のセキュリティに対する対策を行なっているかについて知見を共有します。AWS re:Inforce は、 AWS イベントの中で最も幅広いレベルのセキュリティに関する学習型セッションとコンテンツを提供しており、様々な形式のセッションを幅広く用意しています。ぜひ会場でご参加ください。 見どころ：生成AIにおけるセキュリティ AWS re:Inforce 2024 のコンテンツは、セキュリティ専門家が生成AI時代の課題と需要に備えることができるように設計されています。どのトラックやセッションタイプを選択しても、セキュリティの視点を通して生成AIについて学ぶことができます。AWS上の生成AIのパワーを安全に活用するための実践的なソリューションをご覧ください。AIワークロードのデータ保護、基盤モデル（FM）とAIアプリケーションの制御とガードレールの実装、セキュリティ運用とインシデント対応を強化するための生成AIの活用に関する洞察を得ることで、生成AIの旅を安全に加速することができます。 All Builders Welcome Grant AWSは、次世代の技術リーダーを育成することに専念しています。 All Builders Welcome Grant は、現状とクラウドの未来とのギャップを埋め、代表とアクセスに関する針を動かし、技術において代表的でないグループが含まれる環境を構築します。本プログラムの助成金には、re:Inforce 2024に参加するためのフルカンファレンスパス、ペンシルバニア州フィラデルフィアまでの航空券、3泊分のホテル宿泊費が含まれます。参加者は、2日半に及ぶre:Inforceのコンテンツやアクティビティに参加できるほか、ウェルカムイベント、基調講演の指定席、ミートアップ、AWSセキュリティリーダーとのメンタリングイベントなど、学習、キャリア成長、コミュニティ形成の機会を創出するようデザインされたプログラムを利用できます。 募集は現在開始 されており、2024年4月1日（月）午後5時（米国東部時間）に締め切られます。詳細については、 All Builders Welcome Grant の利用規約 をご覧ください。 セキュリティは技術者だけではなく経営幹部や監査、またサイバーセキュリティに関連する公共部門の担当者など、多くの皆様にとっての関心事項となります。このような機会を通じて、安全なサイバー空間の実現を一緒にご支援できれば幸いです。 この記事は セキュリティ アシュアランス本部 本部長 松本照吾が担当しました。

InfluxDB を Amazon Timestream のデータベース エンジンとして使用できるようになりました。本サポートにより、InfluxDB や、時系列データを収集するオープンソース Telegraf エージェント等のオープンソース API を使用して、ほぼリアルタイムの時系列アプリケーションを簡単に実行できるようになります。 Timestream では、Timestream for LiveAnalytics と Timestream for InfluxDB の 2 つのデータベースエンジンを選択できるようになりました。 ほぼリアルタイムの時系列クエリまたは InfluxDB の特定の機能 (Flux クエリ等) が必要なユースケースの場合は、InfluxDB エンジンの Timestream を使用する必要があります。 もう 1 つのオプションは、LiveAnalytics エンジンの既存の Timestream です。これは、1 分あたり数十ギガバイトを超える時系列データを取り込み、ペタバイトの時系列データに対して SQL クエリを数秒で実行するような場合に適しています。 Timestream の InfluxDB サポートにより、最適なパフォーマンスと可用性が得られるように自動的に構成されたマネージドインスタンスを使用できます。また、InfluxDB データベースのマルチアベイラビリティゾーン構成を取る事で、復元力を高めることができます。 InfluxDB の Timestream と LiveAnalytics の Timestream は相互に補完し、時系列データの低レイテンシおよび大規模な取り込みを実現します。 Timestream for InfluxDB を開始 早速始めてみましょう。 まず、InfluxDB インスタンスを作成しましょう。 Amazon Timestream コンソールを開き、 InfluxDB databases に移動して、 Create Influx database を選択します。 次のページで、InfluxDB インスタンスの database credentials を指定します。 また、 Instance configuration でインスタンスクラスを指定し、ニーズに合わせてストレージのタイプとボリュームも指定します。 次のパートでは、マルチ AZ デプロイメントを選択可能です。この設定により、別のアベイラビリティーゾーンにあるスタンバイデータベースにデータが同期的にレプリケートされます。もしも、障害が検出された場合、Timestream for InfluxDB はデータを失うことなくスタンバイインスタンスに自動的にフェイルオーバーします。 次に、 Connectivity configuration で InfluxDB インスタンスに接続する方法を構成します。ここでは、ネットワークタイプ、VPC、サブネット、データベースポートを定義します。また、パブリックサブネットを指定し、 InfluxDB インスタンスの public access を Publicly Accessible と設定する事も可能で、Amazon Timestream がパブリック IP アドレスを InfluxDB インスタンスに割り当てることができます。もしも、このオプションを選択する場合は、InfluxDB インスタンスを保護するための適切なセキュリティ対策が講じられていることを確認してください。 このデモでは、InfluxDB インスタンスを Not publicly accessible に設定した為、このセクションで定義した VPC とサブネットを介してのみアクセス可能となります。 データベース接続を構成したら、データベースのパラメーターグループとログ配信設定を定義します。 Parameter group では、InfluxDB データベースに使用する特定の構成可能なパラメーターを定義できます。 log delivery settings では、システムログをエクスポートする Amazon Simple Storage Service (Amazon S3) バケットを定義することもできます。 Amazon S3 バケットに必要な AWS Identity and Access Management (IAM) ポリシーの詳細については こちら を参照してください。 設定が完了したら、 Create Influx database を選択します。 InfluxDB インスタンスが作成されると、詳細ページで内容を確認できます。 InfluxDB インスタンスを作成すると、InfluxDB ユーザー インターフェイス (UI) にアクセス可能です。 InfluxDB をパブリックにアクセスできるように構成すると、 InfluxDB UI を選択してコンソールを使用して UI にアクセスできます。セットアップに示されているように、今回は InfluxDB インスタンスをパブリックにアクセスできないように構成しました。この場合、InfluxDB インスタンスと同じ VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを介して SSH トンネリングを使用して InfluxDB UI にアクセスする必要があります。 詳細ページの URL エンドポイントを使用して、InfluxDB UI に移動し、作成時に設定したユーザー名とパスワードを使用します。 InfluxDB UI で、InfluxDB インスタンスと対話するためのトークンを作成できるようになりました。 Influx CLI を使用してトークンを作成することもできます。トークンを作成する前に、InfluxDB インスタンスと対話するための設定を行います。以下は、設定するサンプルコマンドです。 influx config create --config-name demo \ --host-url https://<TIMESTREAM for INFLUX DB ENDPOINT> \ --org demo-org --username-password [USERNAME] \ --active InfluxDB の設定後、オペレーター、オールアクセス、または読み取り/書き込みトークンを作成できるようになりました。以下は、定義した組織内のすべてのリソースにアクセス許可を付与するためのトークンを作成する例です。 influx auth create --org demo-org --all-access 対象のユースケースで必要なトークンがあれば、Influx CLI、Telegraf エージェント、 InfluxDB クライアントライブラリ 等のツールを使ってデータ取り込みを開始出来ます。ここでは Influx CLI を使ってサンプルのホームセンサーデータをラインプロトコル形式で書き込みます。これは、 InfluxDB ドキュメントページ からも参照出来ます。 influx write \ --bucket demo-bucket \ --precision s " home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1641024000 home,room=Kitchen temp=21.0,hum=35.9,co=0i 1641024000 home,room=Living\ Room temp=21.4,hum=35.9,co=0i 1641027600 home,room=Kitchen temp=23.0,hum=36.2,co=0i 1641027600 home,room=Living\ Room temp=21.8,hum=36.0,co=0i 1641031200 home,room=Kitchen temp=22.7,hum=36.1,co=0i 1641031200 home,room=Living\ Room temp=22.2,hum=36.0,co=0i 1641034800 home,room=Kitchen temp=22.4,hum=36.0,co=0i 1641034800 home,room=Living\ Room temp=22.2,hum=35.9,co=0i 1641038400 home,room=Kitchen temp=22.5,hum=36.0,co=0i 1641038400 home,room=Living\ Room temp=22.4,hum=36.0,co=0i 1641042000 home,room=Kitchen temp=22.8,hum=36.5,co=1i 1641042000 home,room=Living\ Room temp=22.3,hum=36.1,co=0i 1641045600 home,room=Kitchen temp=22.8,hum=36.3,co=1i 1641045600 home,room=Living\ Room temp=22.3,hum=36.1,co=1i 1641049200 home,room=Kitchen temp=22.7,hum=36.2,co=3i 1641049200 home,room=Living\ Room temp=22.4,hum=36.0,co=4i 1641052800 home,room=Kitchen temp=22.4,hum=36.0,co=7i 1641052800 home,room=Living\ Room temp=22.6,hum=35.9,co=5i 1641056400 home,room=Kitchen temp=22.7,hum=36.0,co=9i 1641056400 home,room=Living\ Room temp=22.8,hum=36.2,co=9i 1641060000 home,room=Kitchen temp=23.3,hum=36.9,co=18i 1641060000 home,room=Living\ Room temp=22.5,hum=36.3,co=14i 1641063600 home,room=Kitchen temp=23.1,hum=36.6,co=22i 1641063600 home,room=Living\ Room temp=22.2,hum=36.4,co=17i 1641067200 home,room=Kitchen temp=22.7,hum=36.5,co=26i 1641067200 " 最後に、InfluxDB UI を使用してデータをクエリしてみましょう。 InfluxDB UI の Data Explorer ページに移動し、簡単な Flux スクリプトを作成して、 Submit を選択します。 Timestream for InfluxDB を使用すると、既存のツールを引き続き使用してデータベースと対話しながら、InfluxDB を利用したアプリケーションの開発が容易になります。マルチ AZ 構成を利用すると、基盤となるインフラストラクチャを気にすることなく、InfluxDB データの可用性を高めることが可能です。 AWS と InfluxDB のパートナーシップ Amazon Timestream for InfluxDB の一般提供開始を祝って、InfluxData の創設者兼最高技術責任者である Paul Dix がこのパートナーシップについて次のように述べています。 “オープンソースの未来はパブリッククラウドによって推進され、シンプルなエントリポイントと実用的なユーザーエクスペリエンスを通じて広範なコミュニティに浸透しています。Amazon Timestream for InfluxDB はそのビジョンを具現化したものです。AWS とのパートナーシップにより、InfluxDB が時系列データに関するリアルタイムの洞察を実現する力を倍増するツールとなり、開発者が AWS 上で時系列ワークロードを構築および拡張が簡単に実現出来ます。” 知っておくべき事 その他の追加情報を以下に示します。 利用可能な AWS リージョン – オハイオ、バージニア北部、オレゴン、ムンバイ、シンガポール、シドニー、東京、フランクフルト、アイルランド、ストックホルムリージョンで利用できます 移行シナリオ – 自身で運用されている InfluxDB インスタンスから移行するには、既存の InfluxDB データベースから Timestream for InfluxDB にバックアップを復元するだけです。既存の Timestream LiveAnalytics エンジンから InfluxDB 用の Timestream に移行する必要がある場合は、Amazon S3 を利用できます。さまざまなユースケースにおいて移行を実施する方法の詳細については、「 Migrating data from self-managed InfluxDB to Timestream for InfluxDB 」ページを参照してください。 サポート対象バージョン – Timestream for InfluxDB は現在、InfluxDB のオープンソース 2.7.5 バージョンをサポートしています。 利用料 – 料金の詳細については、 Amazon Timestream pricing をご覧ください。 デモ – Timestream for InfluxDB の動作を確認するには、同僚の Derek が作成したこの デモ をご覧ください。 Timestream for InfluxDB を使用して、ミリ秒の応答時間を持つ時系列アプリケーションとダッシュボードの構築をします。詳細については、 Amazon Timestream for InfluxDB ページをご覧ください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

3月4日週、Anthropic は Claude 3 基礎モデルファミリー を発表しました。このファミリーには、ほぼ瞬時の応答性を実現する最速かつ最もコンパクトな Claude 3 Haiku 、スキルとスピードの理想的なバランスを実現した Claude 3 Sonnet 、および高度に複雑なタスクでトップレベルのパフォーマンスを実現する高度なインテリジェンスを備えた Claude 3 Opus という 3 つのモデルが含まれています。AWS はまた、 Amazon Bedrock での Claude 3 Sonnet の一般提供の開始 も発表しました。 本日は、 Claude 3 Haiku が Amazon Bedrock で利用可能になったことをお知らせします。Claude 3 Haiku 基盤モデルは、Claude 3 ファミリーの中で最速かつ最もコンパクトなモデルであり、ほぼ瞬時の応答性と、人間の対話を模倣したシームレスな生成人工知能 (AI) エクスペリエンスを実現するように設計されています。例えば、チャートやグラフを含む arXiv のデータ密度の高い研究論文 (～10,000 トークン) を 3 秒以内に読み取ることができます。 Claude 3 Haiku が Amazon Bedrock で利用可能になったことで、迅速かつ正確な目標パフォーマンスを必要とする企業向けに、ほぼ瞬時に応答する生成 AI アプリケーションを構築できます。Sonnet や Opus と同様、Haiku は画像からテキストに変換するためのビジョン機能を備えているほか、英語のほかにも複数の言語を理解でき、200k コンテキストウィンドウでの高い操作性を誇っています。 Claude 3 Haiku のユースケース Claude 3 Haiku は、インテリジェンスカテゴリの他のモデルよりも賢く、高速で、より手頃な料金でご利用いただけます。単純なクエリやリクエストに対して、比類のない速度で応答します。高速で、高い操縦性を備えているため、人間のやり取りをシームレスに模倣する AI エクスペリエンスを生み出すことができます。 Claude 3 Haiku のユースケースを以下にいくつか示します。 顧客とのやり取り: ライブでのやり取りや翻訳における迅速かつ正確なサポート コンテンツモデレーション: 危険な行為や顧客のリクエストを把握 コスト削減タスク: 最適化された物流、在庫管理、非構造化データからの知識の迅速な抽出 Claude 3 Haiku の特徴や機能の詳細については、AWS ドキュメントの「 Amazon Bedrock での Anthropic Claude 」および「 Anthropic Claude モデル 」にアクセスしてください。 Claude 3 Haiku の動作 Anthropic モデルを初めて使用する場合は、 Amazon Bedrock コンソール に移動し、左下のペインで [モデルアクセス] を選択します。 Claude 3 Haiku へのアクセスを別途リクエストします。 コンソールで Claude 3 Haiku をテストするには、左側のメニューペインの [プレイグラウンド] で [テキスト] または [チャット] を選択します。その後、 [モデルを選択] を選択し、カテゴリとして [Anthropic] を選択して、モデルとして [Claude 3 Haiku] を選択します。 Claude プロンプトの例をさらにテストするには、 [例をロード] を選択します。引用を含む高度な質疑応答、デザインブリーフィングの作成、英語以外のコンテンツの生成など、Claude 3 Haiku に固有の例を表示および実行できます。 [比較モード] では、顧客の質問に対応するためのパーソナライズされた E メール応答を生成するサンプルプロンプトを使用して、Claude 3 Haiku と Claude 2.1 モデルの速度とインテリジェンスを比較することもできます。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id anthropic.claude-3-haiku-20240307-v1:0 \ --body "{\"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"text\",\"text\":\"Write the test case for uploading the image to Amazon S3 bucket\\nCertainly! Here's an example of a test case for uploading an image to an Amazon S3 bucket using a testing framework like JUnit or TestNG for Java:\\n\\n...."}]}],\"anthropic_version\":\"bedrock-2023-05-31\",\"max_tokens\":2000}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt Claude 3 で API リクエストを実行するには、新しい Anthropic Claude Messages API 形式 を使用します。これにより、画像処理などのより複雑なやり取りが可能になります。 Anthropic Claude Text Completions API を使用する場合は、 Text Completions API からアップグレード する必要があります。 画像ファイルを記述する Message API リクエストを送信するサンプル Python コードを次に示します。 def call_claude_haiku(base64_string): prompt_config = { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 4096, "messages": [ { "role": "user", "content": [ { "type": "image", "source": { "type": "base64", "media_type": "image/png", "data": base64_string, }, }, {"type": "text", "text": "Provide a caption for this image"}, ], } ], } body = json.dumps(prompt_config) modelId = "anthropic.claude-3-haiku-20240307-v1:0" accept = "application/json" contentType = "application/json" response = bedrock_runtime.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get("body").read()) results = response_body.get("content")[0].get("text") return results Claude 3 でのサンプルコードの詳細については、Community.aws の「 Get Started with Claude 3 on Amazon Bedrock 」、「 Diagrams to CDK/Terraform using Claude 3 on Amazon Bedrock 」、および「 Cricket Match Winner Prediction with Amazon Bedrock’s Anthropic Claude 3 Sonnet 」をご覧ください。 今すぐご利用いただけます Claude 3 Haiku は現在、米国西部 (オレゴン) リージョンで利用可能であり、さらに多くのリージョンで間もなく利用可能になる予定です。今後の更新については、 リージョンの詳細なリスト をご確認ください。 Claude 3 Haiku は最もコスト効率の高い選択肢です。例えば、Claude 3 Haiku は、Claude Instant と比較して、1,000 入力/出力トークンあたりの料金が最大 68% 低く、より高いレベルのインテリジェンスを備えています。詳細については、「 Amazon Bedrock の料金 」をご覧ください。 Amazon Bedrock コンソール で Claude 3 Haiku を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock まで、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

Amazon Transcribe は、アプリケーションに音声認識機能を簡単に追加できる、フルマネージドの自動音声認識 (Automatic Speech Recognition; ASR) サービスです。この度、数十億パラメータから構成される次世代の音声基盤モデルに基づいた、 100 言語 以上に対応する音声認識システムを発表できることを嬉しく思います。この記事では、このシステムのメリット、企業がそれをどのように活用しているか、そして利用開始方法を紹介します。また、本記事の下部には音声認識結果の例も記載しています。 Amazon Transcribe の音声基盤モデルは、自己教師あり (self-supervised) アルゴリズムを用いて学習されています。これにより、人間の音声の普遍的なパターンを言語やアクセントを越えて学習できます。本モデルは 1 億時間以上、100 言語以上のラベルなし音声データを使用して学習されています。言語間の学習データのバランスを取るように最適化された学習方法を用いているため、従来対応できていなかった言語でも高い精度が得られます。 Carbyne は、緊急通報対応者のための、クラウドベースでミッションクリティカルなコンタクトセンターソリューションを開発するソフトウェア会社です。Carbyne のミッションは緊急対応者による救命の支援であり、言語の壁がその妨げになってはいけません。このミッション達成のため、Carbyne では Amazon Transcribe を以下の通りに活用しています: 「AI を活用している Carbyne ライブオーディオ翻訳は、家庭で英語以外の言語を話す 6,800 万人のアメリカ人と、年間最大 7,900 万人の外国人観光客の緊急対応の改善に直接役立つことを目的としています。Amazon Transcribe の新しい多言語基盤モデルに基づく音声認識機能を利用することで、Carbyne は 誰もが等しく大切な存在である という理念のもと、生命救助の緊急サービスをより多くの人々に提供できるようになるでしょう。」 – Alex Dizengof, Carbyne 共同設立者兼 CTO Amazon Transcribe の音声基盤モデルを活用することで、ほとんどの言語において認識精度が 20%-50% 向上しました。また、電話音声は認識の難易度が高くデータが不足しがちな領域ですが、こちらでも 30%-70% の精度向上を実現しました。大幅に向上した認識精度に加え、この大規模音声認識モデルは、句読点や大文字小文字をより正確に認識できるので、書き起こしの可読性も向上させます。生成 AI の登場により、数千もの企業が Amazon Transcribe を利用して、音声コンテンツから豊富なインサイトを引き出しています。精度が向上し 100 言語以上のサポートを実現した Amazon Transcribe を利用することで、このようなあらゆるユースケースで良い効果が期待できます。バッチモードで Amazon Transcribe を利用している全ての既存および新規のお客様は、API エンドポイントや入力パラメータを変更することなく、音声基盤モデルに基づく音声認識を利用できます。 新しい音声認識システムは、100 以上の全言語において、使いやすい利用形態、カスタマイズ性、ユーザーの安全性、プライバシーなどの主要な機能を提供します。句読点の自動付与、カスタム辞書、自動言語識別、話者識別、単語レベルの信頼度スコア表示、カスタム辞書フィルタなどもこれらの機能に含まれます。異なるアクセント、ノイズ環境、音響条件への対応の拡大により、より正確な文字起こしができるようになり、音声認識技術をお客様のアプリケーションに効率的に導入できます。 さまざまなアクセントやノイズ条件下での Amazon Transcribe の精度向上、対応言語の拡大、付加価値をもたらす機能の充実により、数千もの企業が音声コンテンツからのインサイトを抽出し、音声やビデオコンテンツの可視性や見つけやすさを向上できます。例えば、コンタクトセンターは顧客との通話を文字起こししてインサイトを得た上で、顧客満足度やエージェントの生産性向上に活用しています。また、コンテンツ制作者やメディア配信事業者は、Amazon Transcribe による自動字幕作成を利用してコンテンツのアクセシビリティを向上させています。 Amazon Transcribe の利用開始方法 AWS コマンドラインインターフェース (AWS CLI)、 AWS マネジメントコンソール 、および AWS SDK を使用してバッチ文字起こしを行うことができます。従来と同じ StartTranscriptionJob API を使用して、コードやパラメータの変更をすることなく、性能が強化された自動音声認識モデルを利用できます。AWS CLI とコンソールの使用方法の詳細については、 AWS CLI による文字起こし と AWS マネジメントコンソールでの文字起こし をそれぞれ参照してください。 最初のステップは、メディアファイルを Amazon Simple Storage Service (Amazon S3) バケットにアップロードすることです。S3 は、あらゆる量のデータをどこからでも保存および取得するために構築されたオブジェクトストレージサービスです。S3 は極めて低コストで、業界をリードする耐久性、可用性、パフォーマンス、セキュリティ、ほぼ無制限のスケーラビリティを提供します。書き起こしを独自の S3 バケットに保存するか、Amazon Transcribe に安全なデフォルトのバケットを使用させるか選択できます。S3 バケットの使用方法の詳細については、 Amazon S3 バケットの作成、設定、操作 をご覧ください。 音声認識の出力結果 Amazon Transcribe の出力は JSON 形式です。書き起こしの結果は、テキスト形式とアイテム形式の 2 つの異なる形式で出力されます。API エンドポイントや入力パラメータに違いはありません。 テキスト形式は、まとまったテキストとして書き起こしを提供します。一方で、アイテム形式は時系列で順序付けされた 1 つ以上の書き起こしアイテムの形式で、各アイテムごとの追加のメタデータとともに提供されます。書き起こし結果のファイルではこれらの 2 つの形式が両方出力されます。 書き起こしジョブの作成時に選択するオプションに応じて、Amazon Transcribe は書き起こしを作成します。次の出力結果を参照してください: { "jobName": "2x-speakers_2x-channels", "accountId": "************", "results": { "transcripts": [ { "transcript": "Hi, welcome." } ], "speaker_labels": [ { "channel_label": "ch_0", "speakers": 2, "segments": [ ] }, { "channel_label": "ch_1", "speakers": 2, "segments": [ ] } ], "channel_labels": { "channels": [ ], "number_of_channels": 2 }, "items": [ ], "segments": [ ] }, "status": "COMPLETED" } 各項目の説明は以下の通りです。 書き起こし – transcripts 要素で表され、書き起こしのテキスト形式のみが含まれます。複数話者、マルチチャネルの場合は、すべての書き起こしが 1 つのブロックとして連結されています。 話者 – speaker_labels 要素で表され、話者ごとにグループ化された書き起こしのテキスト形式とアイテム化された形式が含まれます。この項目は、 話者識別 (Speaker partitioning/diarization) 機能 が有効になっている場合にのみ利用できます。 チャネル – channel_labels 要素で表され、チャネルごとにグループ化された書き起こしのテキスト形式とアイテム化された形式が含まれます。この機能は、 マルチチャネル機能 が有効になっている場合にのみ利用できます。 アイテム – items 要素で表され、書き起こしのアイテム化された形式のみが含まれます。複数話者、マルチチャネルの場合は、アイテムには話者やチャネルを示す追加のプロパティが含まれます。 セグメント – segments 要素で表され、書き起こしのテキスト形式とアイテム化された形式が含まれます。代替書き起こしのまとまりでグループ化されており、代替文字起こし機能が有効になっている場合に限りこの機能が利用できます。 訳註: 例えば日本語の書き起こしデータ ( transcripts ) は以下のように出力されます。( こちら の動画の 1:55- 以降) えではですね、あ、こんにちは。ではですね。あの私の方からま、今回のイベントのですね。あのジェネラルセッションということで、あのAWS、こんなこと考えてますとか、ま、こんなことができますっていうですね、概要をご紹介させていただいて、後続のですね。あのより深掘りをする楽しいセッションに繋いでいくというお話をしていきたいなという風に思っていますので、よろしくお願いいたします。あ、よろしくお願いします。はいえーではですね。まもしかしたらご存じない方もいらっしゃるかもしれないので、ま、そもそもAWSって何ぞやって話をですね、ちょっとだけしたいなという風に思っています。で、AWSまアマゾンウェブサービスということで、ま、アマゾンの仲間の一員ということになるんですけれども、あのアマゾンとですねま、AWSえ、我々はですねま、地球上で最もお客様を大切にする企業でありたいという風に考えています。で、アマゾンのビジネスモデルなんですけれども、あのより多くのお客様にですね、満足をいただくとで、そうすると、さらにたくさんのお客様がいらっしゃって。で、その場を使ってですね、ビジネスをやりたい人も増えるだろうと。そうすると、品揃えが増えて満足につながるよね。ま、これをぐるぐる回しましょうっていうところが一つと。あと、あのだんだん大きくなってくるにつれて、まオペレーションのコストとかも発生してくると思うんですけれども。ま、それを低コストでですね、回していくことで、え？お客様にですねえ、低価格という形で還元をするということをアマゾン全体では考えていて。で、AWSもですね、あの、その同じ考え方が、あの息づいているサービスということになっています。 まとめ AWS では、お客様のために絶えずイノベーションを起こしています。Amazon Transcribe の対応言語を 100 言語以上に拡張することで、多様な言語背景を持つユーザーへのサービス提供が可能になりました。これはアクセシビリティの向上や、世界規模でのコミュニケーションと情報交換の新たな機会の創出にも繋がります。この投稿で議論した機能の詳細は、 機能紹介ページ と 新機能のお知らせ (What’s new) をご覧ください。 本記事の執筆者紹介 Sumit Kumar は AWS の 言語系 AI サービスチームでプリンシパルプロダクトマネージャーを務めています。様々な分野において 10 年のプロダクトマネジメントの経験があり、AI/ML に情熱を持っています。趣味は旅行と、クリケットやローンテニスです。 Vivek Singh は AWS の 言語系 AI サービスチームでプロダクトマネジメントのシニアマネージャーを務めており、Amazon Transcribe 製品チームのリーダーです。AWS に入社する前は、コンシューマーペイメントや小売など、Amazon の他の組織でプロダクトマネジメントを行っていました。Vivek はシアトルに住んでいて、趣味はランニングやハイキングです。 本記事の翻訳は Solutions Architect 安藤が担当しました。原文は こちら です。

MYCOM OSI このブログは 2023 年 12 月 4 日に Dirk Michel（MYCOM OSI, SVP SaaS and Digital Technology）、Josh Hart（Senior Solutions Architect）、Chris Williams（Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 “Kubernetes 上のデータ”は、パフォーマンス、回復力、信頼性、総所有コスト（TCO）を最適化する、クラウドネイティブなマイクロサービスベースのソフトウェアソリューションを構築するために不可欠な、急速に進化する革新的分野です。Kubernetes アプリケーションの多くは、ブロックストレージ、共有ファイルシステム、オブジェクトストレージなどの永続ストレージとデータサービスへのアクセスを必要とします。 このブログでは、 MYCOM OSI が Amazon FSx for NetApp ONTAP を採用することで、どのようにコストパフォーマンスを改善したかについて説明します。また、大規模で複雑な通信事業者の通信ネットワークについて品質やパフォーマンスを監視するための、アシュアランスデータセットの処理を最適化するソリューションを特定するために、ストレージオプションをどのように評価したかを探ります。 MYCOM OSI はデジタル時代の通信サービスプロバイダー（CSP）向けに保証、自動化、分析の Software-as-a-Service （SaaS）アプリケーションを提供する AWS Specialization Partner です。 MYCOM OSI の アシュアランス・クラウド・サービス （ACS）は、重要なネットワーク・パフォーマンス、障害、サービス品質の管理を提供します。このサービスは、SaaS モデルおよび自社クラウド（BYOC）モデルのあらゆる領域において、ハイブリッド、物理、および仮想化ネットワークに対して、AI および ML技術を活用した自動化された包括的なアシュアランスをサポートしています。 データマネジメントの課題 通信事業者のアシュアランスデータセットは大きく、時には 10～100 テラバイト（TB）単位になります。昨今の通信ネットワークを構成する機器やネットワーク機能は、様々なプロトコルやフォーマットで大量のテレメトリデータを送信します。アシュアランスアプリケーションはこのデータストリームを取り込みます。このデータストリームは通常、情報量の多い時系列数値データ、イベントデータ、ログフォーマットデータ、設定データで構成されています。 通信事業者は、受信するアシュアランスデータストリームのほぼリアルタイムの性質を利用して、監視センターとオペレーションセンター内で、時間的制約のあるトリアージとインシデント対応活動に情報を提供しています。また通信事業者では、受信データを長期にわたって保持・蓄積し、ネットワーク分析や ML ワークロードに不可欠な貴重な履歴データリポジトリを構築します。 重要なことは、多くの時間的制約のあるアシュアランスのユースケースは、中程度の範囲の履歴データへの低レイテンシーアクセスに依存していることです。また、より長い範囲の履歴データは、ネットワークのキャパシティプランニングやエンタープライズ・リソース・プランニング（ERP）など、他の領域における意思決定のためのバッチプロセスを駆動します。 ペタバイト（PB）スケールのデータセットは、高品質、高粒度である可能性がありますが、多大なコストがかかるため、扱うのが難しいです。主なコスト要因のひとつはストレージであり、特に大規模なアクセスネットワークと長期間のデータ保持を必要とする通信事業者にとっては尚更です。データセットのサイズが大きくなるにつれて、必要なストレージ容量を取得、維持し、低レイテンシのパフォーマンス要件を満たすためのコストは大幅に増大します。 直接的なストレージリソースのコストに加え、システムや AWS のアベイラビリティゾーン（AZ）間で大規模なデータセットを転送したりアクセスしたりするのにもコストがかかります。このような大量のデータをネットワーク経由で移動させる場合、高い帯域幅が要求されることが多く、データ転送コストが高くなる可能性があります。 MYCOM OSI のクラウドベースの SaaS ソリューションは、Kubernetes 上にマイクロサービスアプリケーションとしてデプロイされ、数値データストアにはネットワークファイルシステム（NFS）ストレージを多用しています。 Amazon Elastic Kubernetes Service （Amazon EKS）はコアコンピュートプラットフォームであり、AWS 上の Kubernetes クラスタとシームレスに動作するように特別に設計された複数のストレージオプションを提供しています。 EKS の NFS ストレージのオプションとして長年人気があるのは、 Amazon Elastic File System （Amazon EFS）です。Amazon EFS は、完全に管理され、弾力性があり、可用性が高く、スケーラブルな NFS ファイルシステムサービスです。その弾力性とサーバーレス実装により、Amazon EFS はファイルシステムを自動的に拡大・縮小するため、キャパシティプランニングを行う必要はありません。 EFS のインテリジェント階層化機能はもう一つの重要な側面であり、アクセスパターンに基づいて EFS Standard と EFS Infrequent Access のストレージクラス間で動的にファイルを移動させます。 Amazon EKS チームは、Kubernetes コンテナストレージインターフェースのアドオンである EFS CSI Driver を提供しており、EKS が Amazon EFS ファイルシステムと効率的かつ安全に統合し、ライフサイクルを管理できるようにしています。ワーカーノードや AZ に分散された Kubernetes Pod は、EFS によってバックアップされた RWM（Read-Write-Many）永続ボリューム（PV）を同時に使用することができます。 MYCOM OSI のクラウドベースの SaaS ソリューションは、下図に示すように EFS を広範囲に使用しています。 図1 – Kubernetes の永続ボリュームに Amazon EFS を使用したアーキテクチャ。 通信事業者の顧客は、より広範なアシュアランスとテレメトリデータリポジトリを構築し、履歴データをより長く保持しようとしているため、増大する NFS ストレージの使用量について対策する必要性が明らかになりました。その結果、データ効率化機能をアプリケーション側で実装することを避けるために、 Amazon FSx ポートフォリオを評価するイニシアティブが生まれました。 さらに、このイニシアチブは、さまざまな可用性構成を検討する機会にもなりました。そのため、チームは代替のマネージド NFS ストレージソリューションの検討を開始しました。 提案されたソリューション 初期の決断の一つは、マネージド NFS ファイルシステムを求めてAmazon FSx ファミリーにフォーカスすることでした。Amazon FSx は時間の経過とともに拡張され、FSx for ONTAP のような新しいマネージドファイルシステムのサポートが開始されました。MYCOM OSI クラウド開発チームは FSx for ONTAP を使用した経験があり、パフォーマンスと効率性に特に焦点を当て、様々な側面から実装を評価し始めました。 評価された主な機能は以下の通りです： 柔軟なパフォーマンス構成オプション ： スループットキャパシティと IOPS を個別にプロビジョニングすることで、MYCOM OSI はデータ取り込み速度を最大 260% 高速化。 データ圧縮と重複排除機能 ： これらの機能により、MYCOM OSI はストレージ要件を平均 80% 削減。 “プライマリストレージ“と”キャパシティプールストレージ“の二つのストレージ階層 ： データアクセスパターンに基づいてデータをより低コストのストレージメディアに移動させることで、コスト効率を向上。 スナップショットベースのバックアップやリストアなどのデータ保護機能 ： AWS Backup で NFS ファイルシステムからバックアップを取ったりリストアを開始したりするのは、コストと時間がかかる。この課題をスナップショットで回避することで、データ損失やアプリケーションの障害時に迅速かつ効率的なリカバリが可能。 次の図は、ハイレベルの構成図です： 図2 – Kubernetes の永続ボリュームに Amazon FSx を使用したアーキテクチャ チームは、複数のストレージオプションをサポートし、必要に応じて個々の顧客のニーズに基づいた実装の選択肢を提供したいと考えていました。 通信事業者の顧客には様々な形態や規模があり、万能なソリューションが存在することは稀です。SaaS ソリューションの一部として柔軟なストレージソリューションオプションをサポートすることで、MYCOM OSI は大規模な履歴データセットを持つ顧客に最高の価値を提供することができました。 結果 初期の検証フェーズの一環として、チームはファイルシステムボリュームのライフサイクルを管理する FSx for ONTAP 提供の Kubernetes CSI Driver をレビューしました。FSx for ONTAP は、Kubernetes クラスタ内で永続ボリューム（PV）と永続ボリュームクレーム（PVC）のシームレスな統合を可能にします。 発生した課題： FSx for ONTAP は、 AstraTrident CSI Driver for Kubernetes の使用を推奨しています。このドライバには NFS ライブラリが含まれておらず、実際、関連する NFS ライブラリが Kubernetes ワーカーノードで利用可能であることを前提としています。これは、 BottlerocketOS のような最新のコンテナに最適化された Linux オペレーティングシステムでは必ずしも利用できるとはいえません。これらは専用に構築され、軽量で、セキュリティが強化されており、NFS ライブラリも含まれていません。 MYCOM チームと AWS ソリューションアーキテクトは協力して代替の CSI ドライバを特定し、標準の nfs-csi-driver と FSx for ONTAP の互換性を検証しました。チームは BottlerocketOS と FSx for ONTAP のセキュリティ上の利点をストレージソリューションとして利用することを決めました。 パフォーマンス ファイルシステムのパフォーマンス検証作業は、MYCOM OSI ラボのテストハーネス上で実行され、ストレージ効率化機能を有効にした FSx for ONTAP ファイルシステムを採用した SaaS テナント環境を使用しました。 選択されたベンチマークは、二つの特定領域を検証：ファイルシステムに書き込み優位の負荷を与えるデータ取り込みパフォーマンスと、読み取りに集約されるデータ分析パフォーマンスです。結果は以下のように、両方のベンチマークで改善が見られました。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データ取り込み 1B のレコード変換と書き込み 110% – 260% 高速化 データ分析 1B のレコード読み取りと計算 10% – 23% 高速化 この結果は、FSx for ONTAP を導入したパターンでは、十分に低いレイテンシが実現されることを示します。 効率性 このソリューションの費用対効果を検証するためには、データ圧縮率を証明する必要がありました。通常、FSx for ONTAP のコンパクト化、圧縮、重複排除機能を使用した場合、AWS はストレージ容量を 65% 削減できることを確認しています。 複数のテストを実施した結果、システム側で圧縮を行わない NFS ファイルシステムと比較して、ストレージ容量が平均 80% 削減されました。非圧縮ファイルシステムサイズと圧縮ファイルシステムサイズの差は約 10TB/2TB で、圧縮率は 5:1 となりました。達成される圧縮率はさまざまで、データセットの構成や疎性（スパース性）などの複数の要因によって異なります。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データセットタイプ1 合成された通信事業データセット 85% 圧縮 データセットタイプ2 合成された通信事業データセット 75% 圧縮 可用性 FSx for ONTAP のもう一つの特徴は、AZ 間接続性です： アクティブストレージシステムは、どのアベイラビリティゾーンからでも分散アプリケーションによってアクセスできます。これは EFS One Zone の場合とは異なり、EFS One Zone のデプロイメントは、それが存在する同じ AZ 内からのみ EFS CSI ドライバによってマウント可能です。 マルチ AZ の EKS トポロジーを維持するには、EFS ファイルシステムを複数の AZ に分散する EFS Standard で展開する必要があります。これは、回復力と可用性を高めますが、コストの増加というトレードオフを伴います。 FSx for ONTAP では、single-AZ 展開タイプのファイルシステムは、どのアベイラビリティゾーンからでも NFS でマウント可能です。これは、EKS クラスタが可用性と標準の展開テンプレートを維持する一方で、NFS ストレージは可用性を下げて提供されることを意味します。これは、オンプレミスとクラウドを比較する場合など、クラウド移行プロジェクトにとって重要です。詳細については、ブログ記事 Amazon FSx for NetApp ONTAP のシングルアベイラビリティーゾーン デプロイメント利用による VMware Cloud on AWS のストレージコストの削減 を参照してください。 クラウドへの移行をめぐる話題は、コストから始まることがあります。そのため、同等の条件で比較することが重要になります。オンプレミスにマルチサイトレプリケーションがない場合、One Zone ファイルシステムがそれに相当します。もう一つの重要な考慮点は、特定のアプリケーションの要件です。ここでのトレードオフ対象は、可用性、コスト、持続可能性です。 One Zone の導入パターンでストレージの容量を削減すれば、基盤となるインフラが削減されるため、ソリューションのカーボンフットプリントも削減されます。 まとめ MYCOM OSI は、データ集約的な通信事業者のアシュアランスにおいてストレージソリューションを進化させ、顧客固有のニーズに最適なストレージソリューションを採用することができました。進化したストレージアーキテクチャは、特に大規模な履歴データセットを持つ通信事業者の顧客にとって、パフォーマンスの向上とコスト削減を同時に実現しました。Amazon EFS と Amazon FSx for ONTAP の両方をサポートすることで、適切な業務に適切なツールを選択する柔軟性を提供します。 MYCOM OSI は、一貫した SaaS アーキテクチャを維持するための標準的なパターンセットを提供しながらも、特定の要件を満たす柔軟なテナントオプションを提供する能力を高めました。MYCOM OSI は、通信事業者の顧客全体の過去のデータサイズと可用性要件を評価することで、その顧客ベースに対して可能な限り最高のコストパフォーマンスと投資収益率（ROI）を提供することができました。 通信事業者は、MYCOM OSI のアシュアランスクラウドサービス（ACS）プラットフォームのようなクラウドネイティブな SaaS ソリューションを採用することで、アシュアランスアプリケーションの総所有コスト（TCO）を改善することができます。 翻訳はネットアップ合同会社の榎本様、監修はエンタープライズサポートの岡田が担当しました。 . . MYCOM OSI – AWS Partner Spotlight MYCOM OSI は、デジタル時代の通信サービスプロバイダ向けにアシュアランス、オートメーション、アナリティクスの SaaS アプリケーションを提供する AWS パートナーです。 MYCOM OSIへのお問い合わせ | Partner 概要

前提：本ブログは既存システムの改修や更新に携わるエンジニアの方が既存プログラムの概要を把握する手段の選択肢の一つとして、LLMの可能性を提示したものです。実際に稼働しているシステムのプログラムは、本ブログで用いたプログラムよりも規模・複雑度ともに大きく、紹介した方法だけでは十分な結果が得られない可能性があります。後述する「改善ポイント」も参考に、カスタマイズしてご利用ください。 本ブログでは、既存システム更新に関わる課題解決のために、AWS の生成 AI サービスである Amazon Bedrock を使って COBOL ソースコードからプログラム概要資料を作成する活用例を解説します。実際に使用したプロンプトも紹介していきますので参考にしやすい構成になっています。また、COBOL 言語初心者の筆者が生成 AI を活用しながら COBOL 言語を学び、成果物品質を向上させていった方法についても解説します。今回紹介する方法が、既存システムの理解促進と将来の発展のための参考になれば幸いです！ はじめに 2018年、経済産業省から「 DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～ 」が公開されました。あらゆる産業において、デジタルトランスフォーメーションのスピーディーな実現が求められている一方で、企業が抱える多くの問題についても言及されました。その一つが既存システムの老朽化・複雑化・ブラックボックス化している現状でした。レポートには調査結果が引用されており、既存システムの抱える問題のインパクトの大きさが伺えます。 『JUASのアンケート調査によると、約8割の企業が「レガシーシステム」を抱えており、約7割が「レガシーシステム」が自社のデジタル化の足かせになっていると回答している。』 レポートではこの既存システムが DX の足かせとなっている理由についても言及されており、「ドキュメントが整備されていないため調査に時間を要する」というものが一番多くの企業で挙げられていました。 そのような既存システムで使われているプログラミング言語の一つが COBOL 言語です。COBOL 言語は1959年に事務処理用に開発されたプログラミング言語であり、現在も多くの企業、システムで稼働しています。一方で既存システムを開発したエンジニアが離職などにより減ってきている他、現在は新たに COBOL を学ぶエンジニアが減ってきており COBOL エンジニアの絶対数が不足している現状があります。 そんな中で近年最も注目を集めているのが生成 AI です。生成 AI はテキストの理解力や表現力が非常に高く、テキスト生成や、コード生成を得意としています。AWS は昨年の re:Invent にて生成 AI を活用し情報検索を簡単にする Amazon Q というサービスや、生成 AIを用いて対話的にETLジョブのコードを生成する機能などをリリースしています。 本ブログでは、AWS の生成 AI サービスである Amazon Bedrock （サービスについての詳細は こちら をご覧ください）を用いて、COBOL のドキュメント（今回はプログラム概要資料）を作成する活用例を解説します。 なお、エンタープライズ企業におけるメインフレームモダナイゼーションの全体像は大規模で、そのマイグレーションプロセスも複雑です。限られた時間とコストでビジネスゴールを達成するために、業界のベストプラクティスをご参照ください。詳細はこちら「 Mainframe Modernizationへのアプローチ（前編） 」。 生成 AI の出力を組み込んだプログラム概要資料 『論より証拠』、まずは実際に生成 AIの出力を組み込んだプログラム概要資料をご紹介します。 対象とした COBOL プログラムには、AWS が公開している CardDemo というカード会社のシステムを模したものを使いました。CardDemo は画面を備えたアプリで、いくつかのバッチプログラムもあり、実際に環境を整えれば実行することもできます。 CardDemo の画面イメージは以下のようになっています。 図1-1：CardDemo の画面の一例 バッチプログラムの一覧はこちらです。 図1-2：CardDemo のバッチプログラムの一覧 実際に生成 AI の出力を組み込んだプログラム概要資料は以下のとおりです。 図1-3：生成 AI の出力を組み込んだプログラム概要資料 以降では、プログラム本体のファイルと画面定義のファイルについて詳細を示します。 プログラム本体のファイル（ファイル拡張子.cbl） 図2-1：CardDemo のプログラム本体のファイル、右が作成したプログラム概要資料 プログラム概要資料にはプログラム名、プログラム説明のほか、使用する入力ファイル、出力ファイル、変数であるデータ項目、プロシジャーの処理概要、プロシジャーの一覧、プロシジャーから呼び出されプロシジャーの一部として実行される COPYBOOK というファイルの一覧を出力しています。 画面定義のファイル（ファイル拡張子.bms） 図2-2：CardDemo の画面定義のファイル、右が作成したプログラム概要資料 プログラム概要資料には画面名、画面説明のほか、画面イメージ、画面項目の一覧を出力しています。 いかがでしょうか？ プログラム本体や画面定義について、人が比較的に読みやすい形でドキュメント化できたことが分かりますね。 以降では、このドキュメントを Amazon Bedrock  を用いてどのように作成したのかを解説していきます。 Amazon Bedrock を用いたプログラム概要資料作成 概要資料作成プログラムの構成 今回作成した概要資料作成プログラム全体の構成は以下の通りです。 図3-1：プログラム概要資料作成プログラムの構成 全体は Python でプログラミングしています。Amazon Bedrock は COBOL ソースコードの解析部分に利用しています。 Amazon Bedrock から利用する LLM（Large Language Model） には Anthropic Claude v2.1 を使いました。選定理由は、1/日本語での出力が必要なことと、2/後述する通り XML や JSON などが取り扱え、高品質なアウトプットが期待できたためです。 概要資料作成プログラム詳細 概要資料作成プログラムの処理は以下の通りです。 ファイルの情報（ファイル名、ファイルパス、サイズ、ファイル拡張子、ファイル行数）を取得する 各ファイルについて Amazon Bedrock を使って仕様情報を取得する 上述の情報をプログラム概要資料（Word 形式）に書き出す １は概要資料にファイルの一覧を出力する目的のためファイルを列挙し、さらに生成 AI では難しいが Python で可能な処理（例：行数を数える）を行ないます。 ２ではファイル種別毎にプロンプトを切り替えて仕様情報を取得します。 ３では１、２で取得した情報をプログラム概要資料に書き出します。例えば1の結果をもとに画面一覧を出力したり、2の結果をもとに画面詳細仕様を出力したり、と言った感じです。 このブログでは Amazon Bedrock にフォーカスして説明するため Python 部分のコードについての説明は割愛しますが、サンプルプログラムの公開を検討中ですので後続のブログをお待ちいただけると幸いです。 以降、２の Amazon Bedrock の使い方について解説していきます。 Amazon Bedrock タスク ここからは成果物イメージでお見せした、COBOL プログラムのプログラム本体と画面定義について具体的なプロンプトをご紹介します。 COBOL プログラムのプログラム本体から概要資料生成に必要な情報を取得するために使用したプロンプトは以下のとおりです。 コードは <inputText> XML タグの中に Python で埋め込んで Amazon Bedrock の API を呼び出しました。 Human: あなたはCOBOLプログラムの設計、実装、試験のスペシャリストです。 <inputText></inputText>XMLタグ内のプログラムはCOBOLプログラムです。 このCOBOLプログラムを読んで、COBOLプログラム仕様書を作成してください。 COBOLプログラム仕様書のテンプレートを<template></template>XMLタグ内に記載しました。COBOLプログラム仕様書を作成する際には、テンプレートに沿う必要があります。 またCOBOLプログラム仕様書を作成する際には<condition></condition>XMLタグ内に記載した条件を満たして作成してください。 COBOLプログラム仕様書の説明文は日本語で記述する必要があります。ただし、ファイル名称は変数名、関数名などのCOBOLプログラムに記述されている単語はCOBOLプログラム中の記載を優先することが必要です。 <condition> 1.COBOLプログラム仕様書の説明文は日本語で記述してください。文体はですます調で統一してください。 2.出力は<template></template>XMLタグ内に示したJSON形式のテキスト部分だけを記述してください。 3.出力するJSON形式のテキストの前後にこのタスクに関する説明を付加しないでください。 4.<template>タグ、</template>タグそのものを出力しないでください。 5.JSON形式は厳密に守ってください。 </condition> <template> [{"programtitle":"ここにCOBOLプログラムのPROGRAM-IDの内容を記述してください", "processdescription":"ここにCOBOLプログラムの処理概要を400文字以内で記述してください。", "inputfile":[{"inputfilename":"ここに入力ファイル名を記述してください","inputfiledescription":"ここに入力ファイルの概要を40文字以内で記述してください”}], "outputfile":[{"outputfilename":"ここに出力ファイル名を記述してください","outputfiledescription":"ここに出力ファイルの概要を40文字以内で記述してください”}], "dataitem":[{"dataitemname":"ここにCOBOLプログラムのDATAディビジョンのWORKING-STORAGEセクションのデータ項目を記述してください","dataitemdescription":"ここにCOBOLプログラムのDATAディビジョンのWORKING-STORAGEセクションのデータ項目の概要を40文字以内で記述してください”}], "procedureitem":[{"procedurename":"ここにCOBOLプログラムのプロシジャー名を記述してください","proceduredescription":"ここにCOBOLプログラムのプロシジャーの概要を40文字以内で記述してください”}], "workflow":[{"workflowstep":"ここにCOBOLプログラムのPROCEDURE DIVISION. の中身のワークフローの処理ステップ数を1から順にインクリメントしながら記述してください。","workflowdescription":"ここにCOBOLプログラムのPROCEDURE DIVISION. の中身のワークフローの概要を40文字以内で記述してください”}], "copyfile":[{"copyfilename":"ここにCOBOLプログラムがCOPYしているファイルの名前を記述してください。COPYしているファイルというのはCOPY命令の後に示されるモジュールの名前です。","outputfiledescription":"ここにCOBOLプログラムがCOPYしているファイルの概要を40文字以内で記述してください”}] }] </template> <inputText> --filecontent-- </inputText> それでは、<inputText></inputText>XMLタグ内のCOBOLプログラムを読んで、<template></template>に記載したCOBOLプログラム仕様書のテンプレートに従って、COBOLプログラム仕様書を生成してください。 Assistant:[ Outputの一例（COCRDLIC.cblを入力とした場合） { "programtitle":"COCRDLIC", "processdescription":"COCRDLICプログラムは、クレジットカードの一覧表示を行うビジネスロジック層のプログラムです。管理者ユーザーの場合は、コンテキストが渡されなければ、すべてのカードを一覧表示します。管理者以外のユーザーの場合は、COMMAREAで渡されたACCTに関連付けられたカードのみを一覧表示します。", "inputfile":[ {"inputfilename":"COMMAREA","inputfiledescription":"前画面から渡されるコンテキスト情報が格納されている"} ], "outputfile":[ {"outputfilename":"画面","outputfiledescription":"クレジットカードの一覧を表示"} ], "dataitem":[ {"dataitemname":"WS-COMMAREA","dataitemdescription":"前画面から受け取ったコンテキスト情報"}, {"dataitemname":"WS-SCREEN-DATA","dataitemdescription":"画面に表示するカード情報"} ], "procedureitem":[ {"procedurename":"0000-MAIN","proceduredescription":"メイン処理"}, {"procedurename":"1000-SEND-MAP","proceduredescription":"画面送信"}, {"procedurename":"2000-RECEIVE-MAP","proceduredescription":"画面受信"} ], "copyfile":[ {"copyfilename":"DFHAID","outputfiledescription":"AID条件名"}, {"copyfilename":"DFHBMSCA","outputfiledescription":"BMSマップ定義"} ] }] COBOL プログラムの画面定義に対して使用したプロンプトは以下のとおりです。 コードは同じく <inputText> XML タグの中に記載して Amazon Bedrock の API を呼び出します。 Human: あなたはCOBOLプログラムの設計、実装、試験のスペシャリストです。 <inputText></inputText>XMLタグ内のプログラムはBMSマップです。 このBMSマップを読んで、BMSマップ仕様書を作成してください。 BMSマップ仕様書のテンプレートを<template></template>XMLタグ内に記載しました。BMSマップ仕様書を作成する際には、テンプレートに沿う必要があります。 またBMSマップ仕様書を作成する際には<condition></condition>XMLタグ内に記載した条件を満たして作成してください。 BMSマップ仕様書の説明文は日本語で記述する必要があります。ただし、ファイル名称は変数名、関数名などのBMSマップに記述されている単語はBMSマップ中の記載を優先することが必要です。 <condition> 1.BMSマップ仕様書の説明文は日本語で記述してください。文体はですます調で統一してください。 2.出力は<template></template>XMLタグ内に示したJSON形式のテキスト部分だけを記述してください。 3.出力するJSON形式のテキストの前後にこのタスクに関する説明を付加しないでください。 4.<template>タグ、</template>タグそのものを出力しないでください。 5.JSON形式は厳密に守ってください。 </condition> <template> [{"programtitle":"ここにBMSマップのTITLEを記述してください", "processdescription":"ここにBMSマップの概要を400文字以内で記述してください。", "displayimage":"ここにBMSマップの画面イメージをアスキーアートで記述してください。画面イメージはコンソールに出力されるイメージになるべく近づけてください。BMSマップ内のフィールド名称などは表示しないでください。", "fieldnames":[{"fieldname":"ここにBMSマップの画面フィールド名称を記載してください","fielddefaultvalue":"ここにBMSマップの画面フィールドの初期値をBMSマップの記載通りに日本語に変更せず記載してください "}]}] </template> <inputText> --filecontent-- </inputText> それでは、<inputText></inputText>XMLタグ内のBMSマップを読んで、<template></template>に記載したBMSマップ仕様書のテンプレートに従って、BMSマップ仕様書を生成してください。 Assistant:[ Outputの一例（COBIL00.bmsを入力とした場合） {"programtitle":"CardDemo - Main Menu Screen", "processdescription":"CardDemoはメインメニュー画面プログラムです。ユーザーはアカウントIDを入力し、現在の残高を確認した後、残高の支払いを実行するかどうかを選択することができます。", "displayimage":" Tran:____ Bill Payment Date:__/__/__ Prog:________ Time:__:__:__ ------------------------------------------------------------ Enter Acct ID:_________ ------------------------------------------------------------ Your current balance is: __________ Do you want to pay your balance now. Please con- firm: _ (Y/N) ", "fieldnames":[{"fieldname":"TRNNAME","fielddefaultvalue":"____"}, {"fieldname":"TITLE01","fielddefaultvalue":"Bill Payment"}, {"fieldname":"CURDATE","fielddefaultvalue":"__/__/__"}, {"fieldname":"PGMNAME","fielddefaultvalue":"________"}, {"fieldname":"TITLE02","fielddefaultvalue":""}, {"fieldname":"CURTIME","fielddefaultvalue":"__:__:__"}, {"fieldname":"ACTIDIN","fielddefaultvalue":"_________"}, {"fieldname":"CURBAL","fielddefaultvalue":"__________"}, {"fieldname":"CONFIRM","fielddefaultvalue":"_"}, {"fieldname":"ERRMSG","fielddefaultvalue":""}]}] プロンプトは1ファイルにつき1回の Amazon Bedrock API の呼び出しで複数の必要な情報を得られるように工夫しました。1)1回の呼び出しで複数の回答を同時に得られることでプログラム全体の実行時間の短縮とコストの削減が見込める、2)同一コードに対しての複数の項目を別々に取得する場合に比べて出力内容間の整合性がとれる可能性がある、と仮定しています。 今回のプロンプトで利用した Anthropic Claude のプロンプトテクニックについて、 Anthropic のプロンプトガイド を引用して列挙します。 テクニック１： Mark different parts of the prompt/プロンプトのさまざまな部分にマークを付ける Claude は XML タグを認識できるように微調整されています。XML タグを使用することで、プロンプトをサブセクションに区切ることができます。また JSON や YAML などの他の構造化形式も認識できます。今回のサンプルでは、指示を明確にするために XML タグを使いました。また、1回の API 呼び出しで複数の情報を得られるように JSON 形式で応答するように指示しました。 テクニック２： Put words in Claude’s mouth/クロードの口に言葉を入れる 生成 AI は回答の冒頭に、「○○○について、以下に説明します。」のような言葉を加えることがあります。これは概要資料に記載する項目としては不要です。上記プロンプトでは出力の形式を JSON にし、指示中の Condition に不要な説明を含めないように制限を示し、Assistant: の直後に JSON の“[”を指定することで、JSON のみの出力を得られるよう工夫しました。 ＊このプロンプトは概ねうまくいきますが、完全ではありませんでした。今回の事例では正しい出力を得るため再実行が必要なことがありました。 テクニック３： Documents before instructions/指示前にドキュメントを入れる Claude は大きなコンテキストウィンドウがあり、大規模な COBOL プログラムもプロンプトに含めて渡すことができます。プロンプトの構造として、最初に指示を書き、次に入力となる COBOL コードを示した上で、最後に再度指示を書きました。これにより指示が守られやすくなります。 Amazon Bedrock の使い方として、使用したプロンプトは以上です。このプロンプトを使って得られた JSON 形式の応答を Python で受け取り、プログラム概要資料に出力しました。 次にこの概要資料作成プログラムを作るにあたり、どのように進めたのか説明していきます。 COBOL 初心者の私が COBOL 概要資料作成の生成 AI デモを開発した道のり 私は COBOL 言語を使ったことがありませんでしたので、当然文法についての知識もありませんでした。そのため生成 AI を使って COBOL 言語や COBOL ソースコードを理解しながら、概要資料作成プログラムを徐々に良くしていくという方法を取りました。 だいたい次のような流れで進めました。 おおまかに質問して、全体感を把握する。 具体的にしたい部分に絞った質問をして、より詳細な情報を得る。 キーワードをたまに Web 検索して、生成 AI の出力結果が正しいのか事実確認をする。 以降、１から３を繰り返す Amazon Bedrock には生成 AI とインタラクティブに対話しながら  LLM  の出力をチェックし、質問応答を行うことができる チャットプレイグラウンド が用意されています。以下では、私がチャットプレイグラウンドを利用して COBOL 言語を学んでいった際のイメージを示します。 どのようなファイルがあるのかを質問したり、ファイルの仕様を質問したり、言語仕様の調査を行なっている様子です。 図5-1：COBOL 言語のファイル種別を質問した場合の回答 図5-2：COBOL 言語のプログラム本体のファイル構成を質問した場合の回答 図5-3：COBOL 言語の MOVE 命令について質問した場合の回答 図5-4：COBOL 言語の COPYBOOK について質問した場合の回答 ソースコードを調査した際のイメージを以下に示します。 プログラム全体の概要を説明させたり、ソースコードを少しずつ説明させたりしてソースコード調査を行なっている様子です。 図5-5：CardDemo のあるプログラム本体をすべて引用して質問したところ 図5-6：CardDemo のあるプログラム本体について引用して質問した場合の回答 図5-7：CardDemo のプログラム本体の数行について質問をしたところ 図5-8：CardDemo のプログラム本体の数行について質問した場合の回答 Python で概要資料作成した際のイメージを以下に示します。 Python から Word 形式のプログラム概要資料を作成するためのライブラリ調査を行なっている様子です。 図5-9：Python から Word を処理するために必要なライブラリを質問した場合の回答 図5-10：Python-docx というライブラリについて使用方法を質問した場合の回答 このように、生成 AI との対話を通して、COBOL 言語、CardDemo に関する知識を徐々に広げながら、プロンプトを工夫したり Python 実装を行なったりして進めていきました。 本概要資料作成プログラムの作成に要した期間ですが、著者の場合で約１週間でした。 本デモ開発を通じたラーニングのシェア 本取り組みを通して得られた学びをシェアします。 1. 未知の言語、未知のシステムであっても生成 AI を使うことで、簡単に短時間で学ぶことができた 始める前は、生成 AI が COBOL 言語の情報を持っているか分からなかったが、質問することで目的に十分な知識があることが確認できました。生成 AI を使うことで、一般的な言語仕様の説明を得られる上に、目の前のソースコードについても解説が得られるので、システムが何をしているのかより早く理解することができました。 ＊LLM が十分に学習していない言語だった場合でも、その言語の知識を持ち込むこと（プロンプトや、RAG 等）で対応可能な可能性があります。 2. 学びを概要資料作成に活かすことで、成果物の品質がどんどん向上した 学んだ言語仕様を前提としてプロンプトを改良することで、目的に合致する情報を確実に得られるようになりました。 生成 AI では得ることが難しい情報だと分かった場合は、Python で取得するように変更しました（例：プログラム行数の取得）。その際も生成 AI を使って Python コードを生成することで、短時間で目的を達成することができました。（このブログでは割愛しましたが、Python コードの作成には Amazon CodeWhisperer を使っています。） 3. 生成 AI が出力する“本当かどうか分からない”出力も、それっぽいのでうまく使うと便利 生成 AI はソースコード内の変数名やプロシジャー名からそれっぽい説明を生成します。（例：”TRNXFILE” というファイル名の説明を「トランザクションデータを含む入力ファイル」と出力しました。）正しいかどうかは調査を進めないと分かりませんが、事前情報なくそれっぽく説明してくれるので、一旦構成を理解するのに役立ちました。 ＊調査が進み、生成 AI の出力が正しくないと感じたら、プロンプトでファイル名の命名ルールを与えるなどすれば、より正確な出力が得られる可能性があります。 改善ポイント 今回限られた時間の中で、意味のありそうなプログラム概要資料を得られるところまで作り込むことができました。 ここではこの方法を実際のプロジェクトで活用しようと思った時に、考えられる改善のポイントをあげておきます。 プロンプトはまだまだ改善ができます。指示を改良する、例を示すなどすることで出力をわかりやすく、かつ安定させることができるはずです。 概要資料のプロシジャーの説明は、今回は表形式での説明としましたが、フローチャートなど図化を行なった方がより直観的にわかりやすくなります。Python ではグラフ構造をテキストで指示してフローチャートなどの図を出力できる Graphviz が使えます。生成 AI の出力としてこの Graphviz で使えるグラフ構造のテキストを生成させることができます。改善の一つとしてこのような改修を入れるのは有効です。 生成 AI の出力は時には最善とは言えないものとなる可能性があります。今回は生成 AI の出力を目視で確認し、リトライを行なっていましたが、生成 AI で出力した成果を生成 AI によって回答品質を判断し、品質が低い場合は自動でリトライさせる方法が考えられます。生成 AI の出力品質チェック用のツール（例：https://github.com/citadel-ai/langcheck）も出てきていますので、用途に合ったものを使うのも良いやり方です。 生成 AI で出力された情報をさらに統合的に解析し、生成 AI を通すことでより高度な情報を概要資料に含めることができます。例えば、各プログラムから使用している COPYBOOK 名を取得済みですが、逆に COPYBOOK の修正により影響を受けるファイルの一覧を出力することができます。また、各プログラムファイルから生成された説明を元に、生成 AI を使って再度プログラム全体の説明を作成することで、ボトムアップで正確な説明ができる可能性があります。 まとめ 本ブログでは、AWS の生成 AI サービスである Amazon Bedrock を使い、COBOL ソースコードのプログラム概要資料を作る方法の解説を行いました。Anthropic Claude のプロンプト例を具体的に提示し、効率的に正しい回答を得るためのプロンプトテクニックについて解説しました。 本内容はCOBOL以外のプログラム言語でも応用できる可能性があります。 プログラム概要資料作成のための概要資料作成プログラムを作ることで、解析対象のシステムをより手軽に早く理解することができるようになります。また概要資料を読んだ結果、新たな観点で調査を行いたいとなったときも、この概要資料作成プログラムに手を加えることで、短時間で調査を完了することができます。この概要資料作成プログラムは既存システム理解のための重要なツールとなると実感しました。 今回紹介した方法が、既存システムの理解促進と将来の発展のための参考になれば幸いです！ 著者について 勝本 秀之(Hideyuki Katsumoto) 勝本 秀之(Hideyuki Katsumoto) は AWS Japan のパートナーソリューションアーキテクトとして、パートナーの AWS ビジネスの推進や個別案件の技術支援を担当しています。好きなサービスは Amazon Bedrock です。2024年の活動ポリシーは「手を動かす！」なので、いろんなサンプルコードを作っていきたいと思います。ご質問、ご要望あればご連絡ください！ 本橋 和貴 (Kazuki Motohashi) 本橋 和貴 (Kazuki Motohashi) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。

AWS Config の 高度なクエリ 機能は、AWS リソースの設定状態を示すメタデータを取得し、リソースのコンプライアンス状態を特定するための SQL ベースのクエリインターフェースを提供します。AWS Config の高度なクエリは、単一の AWS アカウントおよびリージョン、または AWS Config の アグリゲータ を使用して設定されたマルチアカウントとクロスリージョンにおいても使用できます。しかしながら、クエリの作成には SQL の知識および、リソースの設定プロパティとリソース間の関係性の理解が必要であり、お客様のAWS 環境の規模と複雑さが増すにつれ、SQL の作成はより複雑で時間のかかる作業になりがちでした。 そこでこの度、AWS Config では自然言語で書かれたシンプルな命令や質問を使用して AWS リソース、設定、コンプライアンス状態を問い合わせることができる生成 AI を活用した自然言語クエリ (プレビュー提供) 機能をリリースしました。クエリを自然言語の文章、命令、質問として記述できるため、SQL を学習したり、リソースの設定プロパティやリソース間の関係性を理解するための負荷が低減します。 本ブログでは、AWS Config の高度なクエリ機能で自然言語クエリを利用する方法を解説します。シンプルな文から始めて、求める回答を得るためにどのように改善していけば良いかも併せて解説します。 前提条件 本ブログでは、AWS Config の 高度なクエリ 機能と AWS Config アグリゲータ 機能に関する説明は省いています。それらについてはドキュメントをご確認ください。また、本ブログの手順を実施するには、事前にお客様の AWS アカウントにおいて最低 2 つのリージョンで AWS Config の有効化、1 つのリージョンでアグリゲータの設定が必要です。手順中に生成されるクエリをテストするには、AWS Config を有効化およびアグリゲータで集約対象としている各リージョンに、暗号化された Amazon Elastic Block Store (Amazon EBS) ボリュームと暗号化されていない Amazon EBS ボリュームが必要です。Amazon EBS ボリュームを作成するには こちら のドキュメントを参照してください。 手順 本手順のゴールは、「AWS アカウント内のすべての Amazon EBS ボリュームの暗号化の状態を確認すること」とします。まずは、対象となるすべての Amazon EBS ボリュームを確認し、次に、暗号化された Amazon EBS ボリュームを抽出するためのフィルタリングを行っていきます。 1. AWS マネジメントコンソールから AWS Config の画面に遷移し、左側のナビゲーションペインで、 [高度なクエリ] を選択します(図 1) （訳者注）自然言語クエリプロセッサ機能は、2024 年 3 月現在東京リージョンで提供されていないため、バージニア北部 (us-east-1) もしくはオレゴン (us-west-2) リージョンを選択してください。 図 1 AWS Config – 高度なクエリ 2. [新しいクエリ] を選択します。 [クエリスコープ] を [このアカウントとリージョンのみ] ではなく、アグリゲータ名に変更します。自然言語クエリプロセッサに「List volumes」と入力し、 [生成] を選択します。すると右側にクエリが自動的に生成されます。その後、 [エディタに移動] を選択します。(図 2) 図 2 自然言語クエリプロセッサ機能による Amazon EBS ボリュームの一覧を出力するクエリ生成 3. [新しいクエリ] に生成されたクエリがコピーされているので [実行] を選択します。クエリの結果には Amazon EBS ボリュームのリストが含まれていますが、resourceId と resourceType フィールドのみが含まれており、暗号化ステータスは含まれていないことが分かります(図 3)。次のステップでプロンプトを少し改善してみましょう。 図 3 Amazon EBS ボリュームの一覧を出力するクエリの実行結果 4. [自然言語クエリプロセッサ] に戻り、「List EBS volumes. show volume ID, AZ, resource type and encryption status」と入力し、 [生成] を再度選択します。(図 4) 図 4 Amazon EBS ボリュームの一覧（AZ と暗号化ステータスの情報を含む）を出力するクエリ生成 5. 生成されたクエリには、暗号化ステータスを表す configuration.encrypted フィールドが含まれていることを確認してください。 6. エディタに入力してクエリを実行するには、 [エディタに移動] を選択します。 7. クエリを実行すると Amazon EBS ボリュームと暗号化ステータスがリスト表示されます。(図 5) 図 5 Amazon EBS ボリュームの一覧（AZ と暗号化ステータスの情報を含む）を出力するクエリの実行結果 8. 他にも試してみましょう。 [自然言語クエリプロセッサ] に戻り、「List encrypted EBS volumes. show volume ID, AZ, resource type and encryption status」と入力し、 [生成] を選択してください。(図 6) 図 6 暗号化された Amazon EBS ボリュームの一覧を出力するクエリ生成 9. [エディタに入力] を選択し、生成されたクエリを実行して、次の結果を確認してください。(図 7) 図 7 暗号化された Amazon EBS ボリュームの一覧を出力するクエリの実行結果 他の生成 AI アプリケーションと同様に、想定の結果が得られる SQL を生成するためには、少し試行錯誤が必要な場合があります。そのため、ぜひニーズに合ったプロンプトを自由に試してみてください。 まとめ 本ブログ記事では、AWS Config で生成 AI ベースの自然言語クエリを活用する方法を紹介しました。この機能は、バージニア北部およびオレゴンリージョンでプレビュー版として利用できます。AWS マネジメントコンソールから AWS Config の高度なクエリよりご利用いただけます。 著者について Faraz Rehman Faraz Rehman は、サンフランシスコベイエリアを拠点とする AWS のシニアソリューションアーキテクトです。過去数年間、ISV のお客様が AWS 上でビジネスクリティカルな本番規模のワークロードを構築して運用できるよう支援することに注力してきました。彼の専門分野には、クラウド運用、管理、ガバナンスが含まれます。 Avi Harari Avi Harari は AWS のシニアテクニカルアカウントマネージャーで、エンタープライズ顧客の AWS サービスの導入と利用をサポートしています。AWS Cloud Operations コミュニティの一員であり、AWS での設定、コンプライアンス、監査を専門としています。仕事以外では、家族と過ごす時間やミクソロジーを楽しんでいます。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。

この記事は、2024 年 3 月 12 日に Andre Zoutte によって投稿された Is the AWS Certified Data Engineer – Associate certification right for you? を翻訳し、日本語リソースに関する情報を加筆したものです。 新認定である AWS Certified Data Engineer – Associate (DEA) の予約と受験が開始されました。この認定では、データ関連の AWS サービスに関するスキルと知識、データパイプラインを実装する能力、モニタリングとトラブルシューティングを行う能力、コストとパフォーマンスを最適化する能力を検証します。私は AWS トレーニングおよび認定チームの AWS ソリューションアーキテクトとして、AWS 認定試験の技術的な監督を行っています。私はこの試験の主任認定テクニカルアーキテクトでした。つまり、すべての内容をレビューし、試験の問題が技術的に正確で、当社の品質基準を満たしていることを確認しました。 このブログでは、この新しい試験の概要、利用できる受験準備リソース、および準備中のその他のリソースを紹介します。 AWS がデータエンジニア向けの認定資格を新設した理由 データエンジニアリングは急速な成長を遂げています。世界中のデータエンジニアの求人情報は 2021 年から 2023 年にかけて 45% 増加し、今後 10 年間でさらに 28% 増加すると予想されています (Draup)。この新しい AWS 認定は、受験者がデータエンジニアリングの需要が高い職種に就くための手段となります。 データエンジニアリングは、もう 1 つの主要なトレンドである人工知能 (AI) や機械学習 (ML) にとっても不可欠です。ほとんどの ML アルゴリズムでは、学習と評価にはクリーンなデータが必要とされます。データエンジニアは、データのソースと、それを活用するオペレーションを結びつけます。また、特徴量を設計してデータをサニタイズすることで、モデルの精度を改善します。 専門的に成長する機会を探している人にとって、データエンジニアリングは素晴らしいキャリアの選択肢の一つです。データエンジニアには、開発者としてのプログラミング能力と、データ関連の AWS サービスに関する理解が必要です。データエンジニアの中には、データエンジニアリングの役割に特化したトレーニングを受けている人もいれば、状況に応じてそのような役割を担うことになる人もいます。 AWS Certified Data Engineer – Associate の受験準備 この試験の受験準備に役立つように、オンラインラーニングセンターである AWS Skill Builder に 受験準備リソース を用意しています。試験当日に自信を持って取り組むことができるように、準備プロセスを 4 つのステップにまとめました。これらのリソースを活用して、試験の概要を理解し、試験のトピックについて学び、試験の準備をし、準備状況を評価してください。 （訳注：上記の受験準備リソースページは、執筆時点では英語でのみの提供ですが、各コースを選択後に、そのコンテンツを日本語に切り替えることができます） 他の AWS 認定との比較 皆さんのこれまでの経歴によっては、AWS Certified Data Engineer – Associate の方が、他の Associate 分野の AWS 認定よりも難しいと感じるかもしれません。それは、データエンジニアはエントリーレベルの職種ではなく、ソフトウェア開発者、データサイエンティスト、ソリューションアーキテクトなど、隣接するいくつかの職種に関するスキルが必要となるためです。そのため、 試験ガイド では、AWS Certified Data Engineer – Associate の対象者を、データエンジニアリングに関する 2~3 年の実務経験、AWS に関する 1~2 年の実務経験と定義しています。これは、他の Associate 分野のものよりも複雑です。 AWS 認定の今後の進化 私たちは、Foundational、Associate、Professional 分野の AWS 認定の強化に積極的に取り組んでいます。これらの分野に重点を置いている理由は、需要の高まりにあり、これらの試験には受験者と雇用者の両方から多くの関心が寄せられています。さらに、過去 10 年間でテクノロジー環境は大きく変化しており、認定試験にもこれらの変化を反映させたいと考えています。今後のさらなる情報にご期待ください。 他の学習者がどのように AWS 認定の受験準備をしたのかや、専門家からアドバイスを確認したい場合は、以下のブログをチェックしてください。 Steps to start your AWS Certification journey Learner journey: From zero cloud knowledge to achieving three AWS Certifications in one year AWS ソリューションアーキテクトによる AWS 認定試験の 5 つのヒント AWS 認定の受験準備に役立つ日本語ブログには以下もありますので、合わせてご参照ください。 AWS 認定試験を受けるときのコツ AWS Certified Cloud Practitioner と AWS Certified Solutions Architect – Associate を同時に受験準備するための 10 のヒント この記事の翻訳および追加情報の加筆は Sr. Technical Instructor の生出拓馬が担当しました。