AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

3670

本記事は 2024年4月22日に AWS Machine Learning Blog で公開された “ The executive’s guide to generative AI for sustainability ” を翻訳したものです。 組織は、環境、社会、ガバナンス (ESG) の実践に加えて、持続可能性目標に対するますます高くなっていく要求に直面しています。 Gartner 社の調査 によると、87% のビジネスリーダーが今後 2 年間で組織の持続可能性への投資を増やすことを予想しています。この記事は、 生成 AI と サステナビリティ(持続可能性) の融合点を探る経営者のための出発点となります。持続可能性と ESG イニシアチブを加速するための生成 AI の活用事例とベストプラクティスを提供し、持続可能性における生成 AI の主な運用上の課題についての洞察を示しています。このガイドは、組織の目標と調整しながら、生成 AI を効果的にサステナビリティ戦略に統合するためのロードマップとして活用できます。 持続可能性のための生成 AI へのロードマップ 以下のセクションでは、持続可能性イニシアチブへの生成AIの統合に向けたロードマップを示します。 1. 持続可能性における生成 AI の可能性を理解する 生成 AI は、大量のデータを分析し、パターンを特定し、文書を要約し、翻訳を行い、エラーを修正し、質問に答えるなどの幅広い能力を備えており、 ビジネスのあらゆる部分 を変革する力を持っています。これらの能力は、組織のバリューチェーン全体を通じて付加価値を提供するために活用できます。図 1 は、バリューチェーン全体における持続可能性のための生成 AI の活用事例の一部を示しています。 図 1. 生成 AI のバリューチェーン全体でのサステナビリティユースケース例 KPMG の 2024 年 ESG 組織調査 によると、組織が ESG の影響、リスク、機会に関する情報開示の規制圧力に直面する中で、ESG ケイパビリティへの投資は経営陣にとって最優先事項の 1 つとなっています。このような状況において、生成 AI を活用することで、 組織の ESG 目標を推進 することができます。 典型的な ESG のワークフローは、それぞれが独自の課題を抱える複数のフェーズで構成されています。生成 AI はプロセス全体を通じてこれらの課題に対処する解決策を提供し、持続可能性への取り組みに貢献することができます。図 2 は、組織内の ESG ワークフローの各フェーズにおいて、生成 AI がどのような支援ができるかの例を示しています。これらの例には、市場動向分析の高速化、正確なリスク管理とコンプライアンスの確保、データ収集や報告書作成の促進が含まれます。ただし、ESG ワークフローは業種、組織の成熟度、法的枠組みによって異なる可能性があります。業界固有の規制、企業規模、地域の方針などの要因が ESG のワークフロー手順に影響を与えます。したがって、特定のニーズと状況に応じてユースケースを優先順位付けし、成功を測定するための明確な計画を策定することが、最適な効果を上げるために不可欠です。 図 2. ESG ワークフローに対する生成 AI の利点のマッピング 2. 持続可能性における生成 AI の運用上の課題を認識する 組織の持続可能性目標や ESG イニシアチブへの対応に生成 AI の可能性を活用しようとする組織にとって、生成 AI の実装における課題を理解し、適切に対処することが不可欠です。これらの対処方法には、高品質のデータの収集と管理、既存の IT システムへの生成 AI 統合、倫理的懸念への対処、スキルギャップの解消、責任あるシステム構築のため、最高情報セキュリティ責任者 (CISO) や最高財務責任者 (CFO) など主要ステークホルダーを早期に巻き込むことが含まれます。法的課題は、概念実証 (POC) から実稼働への移行を大きく妨げる要因となります。したがって、コンプライアンスを意識して構築するため、法務チームを早期に関与させることが不可欠です。図 3 は、持続可能性における生成AIの主な運用上の課題の概要を示しています。 図 3. 持続可能性における生成 AI の運用上の課題 3. 適切なデータ基盤を構築する 持続可能性の目標達成のために生成 AI を活用しようとする CEO として、 データが差別化の源泉 であることを覚えておく必要があります。高品質のデータにすぐにアクセスできない企業は、自社のデータで生成 AI モデルをカスタマイズできず、生成 AI の本格的なスケーリング可能性を実現し、競争優位を確保することができません。 多様で高品質 なデータセットの取得に投資して、ESG イニシアチブを強化・加速しましょう。 Amazon Sustainability Data Initiative や AWS Data Exchange などのリソースを活用すれば、包括的なデータセットの取得と分析を簡素化・迅速化できます。外部データの取得に加え、生成 AI の可能性を最大化し、組織データの分析と新たな洞察の発見に活用するため、内部データ管理を優先することが重要です。 運用の観点から、 Foundation Model Ops (FMOps) および Large Language Model Ops (LLMOps) を取り入れることで、持続可能性への取り組みがデータ主導かつスケーラブルになります。これには、データリネージの文書化、データのバージョン管理、データ処理の自動化、データ管理コストの監視が含まれます。 4. 高いインパクトが期待できる機会を特定する サステナビリティ戦略の中で、生成 AI が大きな影響を与えられる機会を見つけるために、 Amazon の Working Backwards の原則 を活用できます。組織内の主要分野で即座の改善が見込めるプロジェクトを優先しましょう。ESG は持続可能性の重要な側面ですが、 エネルギー 、 サプライチェーン 、 製造業、運輸、農業 などの業界固有の専門知識を活用することで、ビジネスアプリケーションに合わせた多様な持続可能性のための生成 AI のユースケースを発見できます。さらに、研究開発の改善、顧客自身によるサービス利用の実現、ビルでのエネルギー使用の最適化、 森林破壊の抑制 などの代替手段を探ることで、持続可能なイノベーションのための大きな機会が生まれる可能性があります。 5. 適切なツールを使用する 持続可能性のための生成 AI の活用において、適切なツールを使用しないと、複雑さが増し、セキュリティが損なわれ、効果が低下する可能性があります。適切なツールは、選択肢と柔軟性を提供し、特定のニーズと要件に合わせてソリューションをカスタマイズできるようにすべきです。 図 4 は、2023 年時点での AWS の生成 AI スタック を示しています。これは、すべての層にわたって選択肢、幅広さ、深さを備えた一連の機能を提供しています。さらに、データ中心のアプローチに基づいて構築されており、セキュリティとプライバシーを考慮して設計されています。 持続可能性イニシアチブを推進するために使用できるツールの例は次のとおりです。 Amazon Bedrock – 主要 AI 企業の高性能な基盤モデル (FM) に単一の API を通じてアクセスできる、完全マネージドサービス。持続可能性のユースケースに適したモデルを選択できます。 AWS Trainium2 – FM と LLM の高性能トレーニング向けに設計された専用チップで、Trainium2 は第1世代Trainium チップと比較して最大 2 倍のエネルギー効率(性能/ワット)を実現。 Inferentia2 ベースの Amazon EC2 Inf2 インスタンス – 同等の Amazon EC2 インスタンスと比べて最大 50% の性能/ワット向上。大規模な深層学習モデルを処理するよう設計されており、エネルギー効率の改善により、超大規模モデルを展開しながら持続可能性目標を達成できます。 図 4. AWS の生成 AI スタック 生成 AI は万能の解決策ではありません。持続可能性イニシアチブへの影響を最大化するには、適切なモダリティと最適化戦略を選択し、アプローチをカスタマイズすることが不可欠です。図 5 は、生成 AI モダリティの概要を示しています。 図 5. 生成 AI のモダリティ さらに、図 6 では、 プロンプトエンジニアリング 、 Retrieval Augmented Generation (RAG) 、 ファインチューニングまたは継続的事前トレーニング など、主な生成 AI 最適化戦略を示しています。 図 6. 生成 AI の最適化戦略 7. 生成 AI エージェントを使用してアプリケーション開発を簡素化する 生成 AI エージェント は、データ入力、顧客サポート問い合わせ、コンテンツ生成などの 様々な定型的・反復的タスクを自動化 する高度な機能を備えているため、持続可能性イニシアチブを前進させる独自の機会を提供します。さらに、タスクを小さな管理可能なステップに分割し、さまざまなアクションを調整し、 組織内のプロセスの効率的な実行 を行うことで、複雑な多段階のワークフローを調整できます。例えば、 Amazon Bedrock のエージェント を使って、運用全体のエネルギー使用パターンを監視・分析し、省エネ化の機会を特定するエージェントを構成できます。あるいは、持続可能性規制のコンプライアンスをリアルタイムで監視する専用エージェントを作成することもできます。 8. 評価のための堅牢なフィードバックメカニズムを構築する 生成 AI モデルの調整や目標の再定義を行うなど、戦略的な改善のためにフィードバックから得られる洞察を活用しましょう。これにより、持続可能性の課題への機敏性とアラインメントを確保できます。以下のガイドラインを検討してください。 リアルタイムモニタリングの実装 – 効率性と環境への影響に焦点を当て、持続可能性のベンチマークに対する生成 AI のパフォーマンスを追跡するモニタリングシステムを設定します。生成 AI イニシアチブの持続可能性への貢献に関する洞察を提供する メトリクスパイプライン を構築します。 ヒューマン・イン・ザ・ループ評価のためのステークホルダーの参加 – ヒューマン・イン・ザ・ループ監査 を行って、内部チーム、顧客、パートナーからの定期的なフィードバックを収集し、組織の持続可能性ベンチマークに対する生成 AI プロセスの影響を評価します。これにより、透明性が高まり、持続可能性へのコミットメントに対する信頼が醸成されます。 継続的改善のための自動テストの活用 – RAGAS や LangSmith などのツールを使えば、LLM ベースの評価を活用して不正確さやハルシネーションを特定・修正でき、持続可能性の目標に沿って生成 AI モデルを迅速に最適化できます。 9. 影響を測定し、持続可能性のための生成 AI からの投資対効果を最大化する 炭素排出量の削減などの環境への影響と コスト削減やビジネスの機敏性の向上 などの経済的な利益を捉える明確な主要業績評価指標 (KPI) を確立します。この2つのフォーカスを持つことにより、自組織による投資が環境の持続可能性に関するプログラムに貢献するだけでなく、持続可能性のビジネスケースを強化し、サステナビリティの実践におけるイノベーションと競争力の強化を後押しすることができます。内外に成功事例を共有して他者に刺激を与え、組織の持続可能性リーダーシップへのコミットメントを示しましょう。 10. 生成 AI のライフサイクル全体でリソース使用量を最小限に抑える 場合によっては、生成 AI 自体のエネルギーコストが高くなる可能性があります。最大の影響を与えるために、持続可能性イニシアチブに生成 AI を活用することのメリットと、その技術自体のエネルギー効率のトレードオフを検討する必要があります。反復的な生成 AI のライフサイクルを深く理解し、 各フェーズを環境に配慮して最適化 することが重要です。一般的に、生成 AI への取り組みは、特定のアプリケーション要件の特定から始まります。そこからモデルをゼロから学習させるか、既存のものを使うかを選択できます。ほとんどの場合、既存のモデルを使ってカスタマイズする方が望ましいでしょう。導入前に、この手順に従い、システムの徹底的な評価を行うことが不可欠です。 最後に、継続的な監視により、継続的な改善と調整が可能になります。このライフサイクル全体を通して、AWS Well-Architected Framework のベストプラクティスを実装することが推奨されます。生成 AI のライフサイクルの概要については、図 7 を参照してください。 図 7. 生成 AI のライフサイクル 11. リスクを管理し、責任を持って実装する 生成 AI には、組織の持続可能性目標の達成に大きな可能性がありますが、有害性やハルシネーションなどの 課題 もあります。イノベーションと生成 AI の責任ある使用のバランスを適切に保つことが、リスクを軽減し、責任ある AI イノベーションを可能にするための基本となります。このバランスには、品質、開示、報告などの要因に関する リスクアセスメント を考慮する必要があります。そのためには、特定の ツールと機能 を採用し、セキュリティチームの専門家と協力して セキュリティのベストプラクティス を採用することが必要不可欠です。生成 AI を安全かつ確実に拡大するには、使用事例に合わせてカスタマイズし、責任ある AI ポリシーに沿った ガードレールを設ける 必要があります。 12. チームの教育とトレーニングに投資する チームのスキルを継続的に向上させ、組織の持続可能性目標の達成に向けてイノベーションを起こし、積極的に貢献できるような能力を高めましょう。 持続可能性 と 生成 AI の両分野で必要なスキルを最新の状態に保つため、関連するリソースを特定してください。 まとめ この記事では、持続可能性と ESG の目標の両面に焦点を当て、経営者が生成 AI を持続可能性戦略に統合するためのガイドを提供しました。持続可能性への取り組みにおける生成 AI の採用は、単なる技術的なイノベーションにとどまるものではありません。それは、責任、イノベーション、継続的改善の文化を育むことです。高品質データを優先し、大きな影響が期待できる機会を特定し、関係者の参加を促進することで、企業は生成 AI の変革力を活用して、持続可能性目標を達成するだけでなく、それを上回ることができるのです。 AWS による支援 AWS ソリューションライブラリ を探索し、AWS 上でサステナビリティソリューションを構築する方法を発見してください。 AWS 生成 AI イノベーションセンター では、アイデア出し、戦略的なユースケース特定、実行、本番環境への拡大について、専門家のガイダンスを得ることができます。 Amazonが 2040 年までに温室効果ガス排出実質ゼロを達成するための 気候変動対策に関する誓約 (The Climate Pledge) コミットメントに向けて AI をどのように活用しているかをご覧いただけます。 AI を活用した Amazon の 7 つの持続可能な未来とビジネスの構築方法 をご覧ください。 著者について Dr. Wafae Bakkali は AWS のデータサイエンティストです。生成 AI の専門家として、Wafae は、生成 AI 技術を活用してお客様のビジネス課題を解決し、最大限の効率と持続可能性を確保するミッションの元に、お客様を支援し、生成 AI の力を存分に発揮できるよう尽力しています。 Dr. Mehdi Noori は AWS Generative AI Innovation Centerのシニアサイエンティストです。サステナビリティ分野で技術とイノベーションを橋渡しすることに情熱を持ち、AWS顧客が生成 AI の可能性を解き放ち、潜在的な課題を迅速な実験とイノベーションの機会に変えられるよう支援しています。スケーラブルで測定可能な先進 AI テクノロジーの実用的な活用に焦点を当て、本番環境への道筋を合理化することで、顧客が持続可能性の目標を達成できるよう手助けしています。 Rahul Sareen は AWS のサステナビリティソリューションおよび GTM (Go-to-Market) の GM です。Rahul は、持続可能性戦略家、GTM 専門家、テクノロジーアーキテクトから成る高いパフォーマンスを誇るチームを持っており、顧客の持続可能性目標 (二酸化炭素排出量の追跡、持続可能な包装やオペレーション、循環経済、再生可能エネルギーなど全般)に向けた優れたビジネス成果を生み出しています。Rahul のチームは、機械学習、ジェネレイティブ AI、IoT などの技術的な専門知識を提供し、持続可能性に関するユースケースの解決を支援しています。
はじめに 生成 AI を搭載したチャットボットは、様々なデータソースからの情報への瞬時のアクセスを可能にし、意思決定を加速し、応答時間を短縮することで、業界全体の生産性向上を推進しています。早いペースで変化する産業環境では、プロセスエンジニア、信頼性の専門家、メンテナンス担当者は、情報に基づいた意思決定を行い、最適なパフォーマンスを維持するために、正確なリアルタイムのオペレーションデータに素早くアクセスする必要があります。しかし、SCADA 、ヒストリアン、IoT (Internet of Things) プラットフォームなどの複雑で、しばしばサイロ化された産業用システムにおいてクエリを実行してデータを取得することは、特に、オペレーションデータがどのように構成され、どのようにアクセスできるかについての知識がない人にとっては困難で時間がかかる場合があります。 生成 AI 搭載のチャットボットにより、さまざまな業務システムや企業データソースから、リアルタイムのアセット情報に自然言語を用いてアクセスできるようになります。 対話型のインタラクションによってデータの取得を簡単にすることができ、生成 AI は作業員がデータ収集に費やす時間を減らし、産業の生産性向上のためにこれまでより多くの時間を使うことができるようになります。このユーザーフレンドリーなチャットボットは、業務システムや企業のさまざまなソースに散在する重要な情報へのアクセスを効率化し、作業員に価値のある運用上のインサイトを提供します。 産業分野でチャットボットを実装するには、産業用データストアから構造化データと非構造化データを参照し、関連する情報を取得するために大規模言語モデル (LLM) を支援するツールが必要になります。この役割を果たすのが、生成 AI で動作するエージェントです。エージェントは、問題を理解するために LLM を使用し、その解決策を立案し、API、データベース、その他のリソースを呼び出してその計画を実行する AI システムです。エージェントはユーザーと複雑なデータシステムとの間のインターフェースとなり、ユーザーが詳細のデータ表現を知らなくても自然言語で質問できるようにします。たとえば、作業現場の従業員は、データがどのように構造化されているかを知らなくても、直近の 1 時間でポンプの最高回転数 (RPM) について尋ねることができます。大規模言語モデル(LLM) 自体は複雑な計算を直接実行することはできませんが、エージェントが効率的なデータ処理向けに設計された産業システムにそれらの処理をオフロードすることで、既存のデータプラットフォームを活用しながら、エンドユーザーは自然言語にてレスポンスを受け取ることができます。 このブログ記事では、開発者に向けて、 Amazon Bedrock で AWS IoT SiteWise と対話可能な会話エージェントを作成するプロセスを紹介します。 AWS IoT SiteWise は、産業機器データを大規模に収集、保存、編成、監視するサービスです。 AWS IoT SiteWise の産業データモデリングと処理機能を活用することで、チャットボット開発者は、さまざまな役割のユーザーが自然言語で重要な運用データにアクセスできる強力なソリューションを効率的に提供することができます。 ソリューションの概要 Agents for Amazon Bedrock を活用し、ユーザーのリクエストを AWS IoT SiteWise 向けの検索に分解するエージェントを構築します。 これにより、クエリの構文やデータの格納方法を知らなくても自然言語でオペレーショナルデータにアクセスすることができるようになります。 たとえば、「 Turbine 1 の現在の RPM 値を教えてください」と質問するだけで、特別なツールやコーディングを行う必要はありません。 このエージェントでは、AWS IoT SiteWise のコンテキスト化レイヤーを利用して産業リソースを直感的に表現しています。 リソースのモデリングの詳細については、 AWS IoT SiteWise の仕組み をご覧ください。 チャットボットインターフェースから、ユーザーが産業用アセットデータにアクセスが必要な自然言語の質問をします。エージェントは、必要なデータを取得するための計画を立てるために、 OpenAPI 仕様 (item 1)を参照します。OpenAPI はエージェントが実行できるクエリを定義している アクショングループ (item 2)を使用し、AWS IoT SiteWise の ExecuteQuery API (item3)を使用する AWS Lambda 関数によって処理されます。 エージェントは、必要なデータを取得できるまで、例えばプロパティ名の問い合わせ、一致する名前の選択、最新の測定値の問い合わせなど、複数のアクションを呼び出します。 要求した運用データが提供されると、モデルは元の質問に対する回答を作成します(item4)。 エージェントの構築 前提条件 このソリューションでは Amazon Bedrock のエージェント を活用しています。現在サポートされているリージョンと基盤モデルのリストについては、 サポートされているリージョンとモデル をご参照ください。Anthropic Claude モデルへのアクセスを有効にするには、Amazon Bedrock で モデルアクセス を有効にする必要があります。このブログで説明されているエージェントは、Claude 3 Haiku に対して設計およびテストされています。 このエージェントでは SiteWise SQL エンジンを使用しており、AWS IoT SiteWise と AWS IoT TwinMaker が統合されている必要があります。AWS IoT SiteWise の ExecuteQuery API 用に AWS IoT TwinMaker ワークスペースを作成するには、 これらの手順 に従ってください。 このエージェントのソースコードは GitHub で入手可能です。 リポジトリをクローンするには、次のコマンドを実行します。 git clone&nbsp;https://github.com/aws-samples/aws-iot-sitewise-conversational-agent Step 1: AWS IoT SiteWise アセットのデプロイ このエージェントでは、AWS IoT SiteWise がデータの保存、モデリング、集約を管理し、Amazon Bedrock がユーザーがリクエストした情報を取得するために、複数のステップからなるアクションを調整して実行します。 はじめに、実際の産業アセットもしくはシミュレートされた産業アセットから AWS IoT SiteWise にデータをストリーミングする必要があります。 AWS IoT SiteWise の開始方法 に従って産業データを取り込み、モデル化を行うか、もしくは AWS IoT SiteWise デモ を使用して 4 基の風車のシミュレートされた風力発電所を起動してください。 Step 3 のインストラクションと Step 4 のサンプル質問は、シミュレートされた風力発電所向けに作成されています。もしご自身のアセットを使用する場合には、ご自身で独自のエージェントインストラクションとテスト質問をご用意ください。 Step 2: アクショングループの定義 Amazon Bedrock では、エージェントを作成する前に、エージェントが実行できるアクショングループを定義する必要があります。 このアクショングループでは、必要なデータを収集する際に、エージェントが AWS IoT SiteWise に対して実行できるそれぞれののクエリを指定します。 アクショングループには以下が必要です。 エージェントが呼び出せる API オペレーションを定義する OpenAPI スキーマ API オペレーションを入力とする Lambda 関数 Step 2.1 OpenAPI 仕様の設計 このソリューションでは、直近のオペレーションからデータを取得するために、エージェントが実行することのできるアクションを記述する、定義済みのパスを持つ API オペレーションを提供します。 たとえば、 GET /measurements/{AssetName}/{PropertyName} パスは、 AssetName と PropertyName をパラメータとして受け取ります。 エージェントがいつ、どのようにアクションを呼び出すのかの記述に注目してください。 開発者は、自身のユースケースにあったアクション (クエリ) を含む適切なパスを schema に追加することができます。 "paths": { "/measurements/{AssetName}/{PropertyName}": { "get": { "summary": "Get the latest measurement", "description": "Based on provided asset name and property name, return the latest measurement available", "operationId": "getLatestMeasurement", "parameters": [ { "name": "AssetName", "in": "path", "description": "Asset Name", "required": true, "schema": { "type": "string" } }, { "name": "PropertyName", "in": "path", "description": "Property Name", "required": true, "schema": { "type": "string" } } ] ファイルに含まれる OpenAPI 仕様を Amazon S3 にアップロードします。バケットとパスをコピーしてください。後の ステップ 3 で必要になります。 Step 2.2: AWS Lambda 関数のデプロイ エージェントのアクショングループは AWS Lambda 関数によって定義されます。 このリポジトリには、 Serverless Application Model (SAM) で構築されたサーバーレスアプリケーションを自動的にデプロイするためのテンプレートが付属しています。 ビルドおよびデプロイするには、 GitHub リポジトリ をクローンし、 template.yaml ファイルが格納されているメインディレクトリから以下のコマンドを実行してください。 sam build --use-container sam deploy --guided プロンプトの指示に従ってデプロイを完了してください。 lambda_handler 関数は、呼び出しから API パスを読み取り、リクエストに応じて次の関数のいずれかを呼び出します。 /measurements/{AssetName}/{PropertyName} パスに定義されているアクションの例を次に示します。ここでは get_latest_value 関数が呼び出され、SiteWise の ExecuteQuery API を使用してユーザー定義のプロパティに対する最新の観測値を取得します。 アクションは、成功および失敗の HTTP ステータスコードを返すように定義できること、エージェントがエラーコードを利用して会話を継続し、ユーザーに詳細を求めることができることを確認してください。 def lambda_handler(event, context): responses = [] try: api_path = event['apiPath'] logger.info(f'API Path: {api_path}') body = "" if api_path == "/measurements/{AssetName}/{PropertyName}": asset_name = _get_named_parameter(event, "AssetName") property_name = _get_named_parameter(event, "PropertyName") try: body = get_latest_value(sw_client, asset_name, property_name) except ValueError as e: return { 'statusCode': 404, 'body': json.dumps({'error': str(e)}) } このエージェントを拡張したい場合、Lambda 関数に新しいメソッドを作成して IoT SiteWise の ExecuteQuery API に自分のクエリを投げ、それらのメソッドを新しいパスにマップすることで拡張することができます。 ExecuteQuery API を使えば、開発者は現在のデータと過去のデータを使って複雑な計算 (集計、値のフィルタリング、メタデータのフィルタリングなど) を実行することも可能です。 Step 3: Amazon Bedrock によるエージェントの構築 Amazon Bedrock コンソールに移動し、 Orchestration の下にある Agents をクリックします。その後、 Create Agent をクリックしてください。 エージェントに分かりやすい名前 (例: industrial-agent ) を付け、モデル (例: Anthropic – Claude 3 Haiku) を選択します。 エージェント定義で最も重要なのは、エージェントにそれが何をするべきかと、どのようにユーザーと対話するべきかを指示するエージェントインストラクションです。エージェントインストラクションのベストプラクティスには次のようなものがあります。 事前に目的と機能を明確に定義する。 語調とフォーマリティレベルを指定する。 曖昧または不完全な質問の扱い方を指示する (例: 説明を求める)。 範囲外の質問に上手く対処する方法を指導する。 考慮すべき特定のドメイン知識やコンテキストを言及する。 AWS IoT SiteWise から風力タービンシミュレーションを Step 1 でデプロイした場合は、次のインストラクションに従うことをお勧めします。エージェントインストラクションは 必須 なので忘れずに実行してください。 You are an industrial agent that helps operators get the most recent measurement available from their wind turbines. You are going to give responses in human-readable form, which means spelling out dates. Use clear, concise language in your responses, and ask for clarification if the query is ambiguous or incomplete. If no clear instruction is provided, ask for the name of the asset and the name of the property whose measurement we want to retrieve.&nbsp;If a query falls outside your scope, politely inform the user Action Groups の下で、 Step 3 で作成した Lambda 関数を選択し、 Step 2.1 で作成した API スキーマを指す S3 URL を入力してください。 もしくは、Bedrock コンソールで直接 API スキーマのテキストを入力することも可能です。 Review and create に進んでください。 Step 4: エージェントのテスト Amazon Bedrock コンソールを使用すると、ユーザーは対話形式でエージェントをテストしたり、各インタラクションの考え方を確認したり、 Advanced prompts を利用して前のステップで自動的に生成された前処理およびオーケストレーションテンプレートを変更することができます。 Amazon Bedrock コンソールでエージェントを選択し、 Test ボタンをクリックしてください。 チャットウィンドウがポップアップ表示されます。 以下のような質問をエージェントを試してみてください: どの風車資産が利用可能ですか ? 風車 1 の特性は何ですか ? RPM の現在値は何ですか ? エージェントは SiteWise からのデータとチャット履歴を使用して推定することができ、正確な名前が与えられていなくても、アセットやプロパティを理解することができます。たとえば、 Turbine 1 を Demo Turbine Asset 1 と認識し、 RPM を RotationsPerMinute と認識します。これを実現するために、エージェントはプランを構築します。利用可能なアセットのリストアップ、プロパティのリストアップ、SiteWise に保存されたアセット名とプロパティ名に基づいてクエリを実行し、ユーザーのクエリと完全に一致しなくても対応できるようにしています。 エージェントからの返答は常に調整することが可能です。 Show trace ボタンをクリックすると、意思決定プロセスを分析し、エージェントの理由付けを理解することができます。 さらに、 Advanced prompts を使って、前処理、オーケストレーション、後処理のステップを編集することで、エージェントの動作を変更することも可能です。 エージェントのパフォーマンスに自信が持てたら、Amazon Bedrock コンソールでエイリアスを作成し、ドラフトバージョンをデプロイします。 Agent details で Create alias をクリックすると新しいバージョンを公開することができます。これによりチャットボットアプリケーションは、AWS SDK の InvokeAgent を使用してエージェントを プログラムで呼び出すことができます。 まとめ このブログで解説した生成 AI エージェントは、産業企業が自社の産業アセットからオペレーションデータと対話できるチャットボットを開発することを可能にしています。 AWS IoT SiteWise のデータコネクタとモデルを活用することで、このエージェントはオペレーションデータの取り込みを容易にし、生成 AI を産業向け IoT ワークロードに統合します。 この産業用チャットボットは、企業情報、機械データ、運用・保守マニュアルなどの専門的なエージェントやナレッジベースとあわせて使用することができます。 このインテグレーションにより、適切な情報を持った言語モデルが提供され、単一のユーザーフレンドリーなインターフェイスを通じて、ユーザーが重要なビジネス上の意思決定を行えるように支援することができます。 次のステップ エージェントの準備ができたら、次のステップは産業用チャットボットのユーザーインターフェースを構築することです。この GitHub リポジトリ を参照することで、生成 AI 対応チャットボットのコンポーネントについて学び、サンプルコードを参照することができます。 著者について Gabriel Verreault Gabriel は AWS のシニアマニュファクチュアリングパートナーソリューションアーキテクトです。グローバルな AWS パートナーと協業し、スマートマニュファクチャリング、OT、サステナビリティ、AI/ML に関するソリューションを定義、構築、普及させています。AWS 入社前は、OSIsoft と AVEVA に勤務し、産業用データプラットフォーム、予知保全、AI/ML と産業用ワークロードの組み合わせ方法に精通しています。 Felipe Lopez Felipe は AWS のシニア AI/ML スペシャリストソリューションアーキテクトです。AWS 入社以前は、GE Digital と SLB に勤務し、産業用アプリケーションのモデリングと最適化に従事していました。 Avik Ghosh Avik は AWS Industrial IoT チームのシニアプロダクトマネージャーで、AWS IoT SiteWise サービスを担当しています。技術革新とプロダクトデリバリーにおいて 18 年以上の経験を持ち、産業用IoT、MES、Historian、大規模なインダストリー 4.0 ソリューションを専門としています。Avik はAmazon IoT サービスのコンセプト作成、リサーチ、定義、バリデーションに貢献しています。 この記事は Gabriel Verreault, Avik Ghosh, Felipe Lopez によって書かれた Querying industrial assets using natural language with AWS IoT SiteWise and Agents for Amazon Bedrock の日本語訳です。この記事は プロフェッショナルサービス本部 シニア IoT コンサルタントの小林が翻訳しました。 <!-- '"` -->
2024 年 6 月 20 日、21 日に幕張メッセにて開催された AWS Summit Japan 2024 にご参加いただいた皆様、ありがとうございました。イベントはお楽しみいただけましたでしょうか。 本記事では、Day 2 に開催された、コスト最適化をテーマとした AWS GameDay ~ Frugality Fest(節約祭り!) ~ の開催概要と結果をご報告いたします。 AWS GameDay とは? AWS GameDay は、ある課題に対して AWS サービスで解決するための対応力や実装スキルを試すことができる実践形式のワークショップです。3~4 名でチームを結成し、待ち受けるさまざまなトラブルやクエストをクリアしながら最終ミッションの達成を目指します。各クエストをクリアするごとにポイントが付与され、最も多くのポイントを獲得したチームが勝者となります。ゲーミフィケーションされた安全な環境で、楽しみながらさまざまなことを学ぶことができる機会を得られるワークショップです。 開催概要 今回の GameDay は総勢 32 チーム 128 名の方にご参加頂きました。昨年は 16 チーム 63 名での開催でしたので、今年は規模が 2 倍となり、会場は熱気にあふれておりました。当日のチームは、ご来場いただいた順番に 4 名で構成されるランダムなメンバーで編成されました。GameDay で高スコアを生み出す秘訣としてチームプレイ・連携が重要であることがアナウンスされ、ゲームの開始時間までにチームビルディングとして自己紹介、得意分野や経験領域の共有、名刺交換などが行われていました。 シナリオ概要 今回のゲームシナリオとして採用された “Frugality Fest” では、架空のテクノロジースタートアップであるユニコーンレンタル社(Unicorn.Rentals)が、業界で人気を占めていた競合会社である RentMyUnicorns の買収を完了し、ユニコーン業界で世界最大のユニコーン提供会社になったというアナウンスから始まりました。 図1 : オープニング説明の様子 しかし、買収した RentMyUnicorns は、非常に人気の高いサービスであったため、大量のトラフィックに対応するためにシステムの増強が必要でした。トラフィックが増加するにつれ、インフラコストも増大していきました。このインフラを最適化するためのチームも時間もなく、インフラコストは急激に上昇し、資金が食いつぶされている状況でした。この日、めでたくユニコーンレンタル社の優秀な新入社員としてご入社された参加者の皆様には、 本番環境を円滑に運営しながら総所有コスト(TCO)を削減する というミッションに取り組んでいただきました。 図2: 既存のアーキテクチャ 結果 結果は以下の通りでした。 第 1 位 Kurage(早川 裕志 氏, 福元 駿汰 氏, 白須 光 氏, 須賀 功太 氏) / スコア : 1,042,068 図3 : 第1位 Kurage のみなさま 第 2 位 CFCA(大橋 直弥 氏, 岡部 知樹 氏, 三﨑 和紀 氏, 藤井 皓平 氏) / スコア : 1,022,459 図4 : 第2位 CFCA のみなさま 第 3 位 GOOD TASTE(碇川 和聖 氏, 栗原 舜 氏, 浅見 則彦 氏, 前川 博志 氏) / スコア : 947,777 図5 : 第3位 GOOD TASTE のみなさま 上位に入賞されたチームの皆様、おめでとうございます。上位 3 チームの皆様には、Head of Developer Relations の Kris から、メダルとトロフィーが進呈されました。 図6 : 優勝チームへのトロフィー進呈の様子 今回の GameDay では、比較的よく使われている AWS サービスが多く採用されていたためか、序盤から順調にクエストをクリアしていくチームが目立ち、ランキングが目まぐるしく変わる白熱した対決となりました。残り 30 分の時点で首位に立っていた CFCA チームが逃げ切る展開と思われましたが、最後に Kurage チームが得点を稼ぎ、逆転優勝を遂げました。優勝チームからは、 「今回のゲームを通じて、これまで知らなかったコスト削減の方法を学ぶことができて勉強になった」 とのコメントをいただきました。その他の参加者の方々からも、 「コスト削減というどの組織でも直面するテーマでやりがいがあった」「経験のなかったサービスに触れられる良い機会になった」「今回の GameDay を機に Graviton への移行を検討したい」「Spot インスタンスの活用方法を体験する良い機会となった」 など、具体的な改善に繋げられそうだというコメントもいただき、楽しみながら学んでいただく良い機会になったのではないかと思います。また、 「周りの仲間に助けてもらってよかった」「他社のスーパーエンジニアの操作を見れて刺激になった」 など、当日ランダムで編成されたチームメンバーとのコミュニケーションが刺激になったというコメントも目立ちました。このような交流ができることも GameDay の醍醐味だと思います。ご参加いただいた皆様、ありがとうございました。 今回惜しくも入賞を逃したチームの皆様、もしくは参加してみたい!と思ったエンジニアの皆様、今後もさまざまなイベントで GameDay の開催を予定していますので、機会を見かけましたら奮ってご挑戦ください。 図7 : GameDay 開催中の様子 図8 : GameDay 終了後の集合写真 最後に 当日は、今回実施した GameDay ”Frugality Fest” の開発者である Anthony Kawamoto が来日しており、最後に皆様へメッセージを伝えさせていただききました。 「コスト最適化は皆様の長期的な成功のために重要であるという思いから、このシナリオを開発しました。今日学んだことを会社に持ち帰っていただき、1 つでも適用していただければ嬉しく思います。」 図9 : ”Frugality Fest” の開発者 Anthony Kawamoto それでは、また来年の AWS Summit Japanでお会いできることを楽しみにしています! 著者について 松尾 亮(Ryo Matsuo) Senior Partner Solutions Architect
みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 梅雨のはずですが、連日暑い日が続きますね・・・まだ気温に慣れておらず辛い日々が続きますが。みなさん、体調にお気をつけください。 それでは、先週の主なアップデートについて振り返っていきましょう。 今週は米国の祝日もありアップデートは少なめになっています。 2024年7月1日週の主要なアップデート 7/1(月) AWS Direct Connect announces native 400 Gbps Dedicated Connections at select locations AWS Direct Connectでネイティブ 400Gbpsの専用線接続が提供開始しました。機械学習や大規模言語モデルトレーニング、自動運転車のための先進運転支援システムなど、大規模なデータ転送が必要な場面で400Gbpsの大きな回線は有効です。400Gbpsの接続が可能なロケーションについては こちらの一覧 をご確認ください。 Amazon OpenSearch Ingestion adds support for ingesting data from self-managed sources Amazon OpenSearch Ingestionが自己管理型のOpenSearch, Elasticsearch, Apache Kafkaクラスターをサポートしました。これにより、たとえばLogstashなどの3rd Partyツールを利用せずにAmazon OpenSearch Serviceにデータ移行や複製が可能になります。この機能は、Amazon OpenSearch Ingestion が現在利用できる東京を含む15のリージョンで利用可能です。詳細については、Amazon OpenSearchの ドキュメント をご確認ください。 RDS for PostgreSQL supports PL/Rust crates serde, serde_json, regex, and url Amazon RDS for PostgreSQLのPL/Rust cratesにserdem serde_json, regex(正規表現), urlが追加されました。これらは全てのAWSリージョンでPostgreSQL 16.3-R2以上, 15.7-R2以上, 14.12-R2以上, 13.15-R2以上のRDS インスタンスで利用可能です。これらの追加以外にも、 Trusted Language Extensions for PostgreSQL (pg_tle)を使ってより多くの拡張を行うことも可能です。 Amazon S3 Access Grants now integrate with Amazon SageMaker Studio Amazon S3 Access GrantsがSageMaker Studioと統合されました。Amazon S3 Access GrantsはIdPやIAMなどでS3のデータへのアクセス権をマッピングし、データアクセスやガバナンス向上ができる機能です。今回の統合によりJupyterLab ノートブックからMLのトレーニングなどでアクセス権を管理しつつS3のデータ利用することがより簡易にできるようになります。この機能はSageMaker Studioが使えるすべてのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon S3 Access Grants now integrate with open source Python frameworks 一つ前のアップデートのSageMaker Studioに加え、AWS SDK for Python (Boto3)を使用してオープンソースの Python フレームワークに関してもAmazon S3 Access Grantsと統合されました。アプリケーションやSageMaker以外のJupyterLab ノートブックでDjango、TensorFlow、NumPy、PandasのPythonのオープンソースフレームワークを使う際もこの機能を利用することでより容易に安全を担保しながらS3上のデータを利用可能になります。この機能はIAM Identity Centerが使えるすべてのリージョンで利用可能です。詳細については同じく ドキュメント をご確認ください。 7/2(火) Elastic Fabric Adapter (EFA) now supports cross-subnet communication Elastic Fabric Adapter(EFA)が同じアベイラビリティーゾーン(AZ)内のサブネット間通信をサポートしました。ハイパフォーマンスコンピューティング(HPC)や機械学習など高速なネットワークを必要とするワークロードで、より柔軟なネットワーク設計が可能になります。この機能は、すべての AWS 商用リージョン、AWS GovCloud (米国) リージョン、Sinnet が運営する北京リージョン、および NWCD が運営する寧夏リージョンで利用で利用可能です。EFAの詳細については、 ドキュメント をご確認ください。 Amazon MQ now supports RabbitMQ version 3.13 Amazon MQでRabbitMQのversion 3.13がサポートされました。これまでのversionのバグの修正とパフォーマンスの向上がされているほか、ブローカーのパッチバージョンアップグレードを管理するようになりました。version 3.13以降の全てのブローカーはメンテナンスウィンドウに互換性のある最新の安全なバージョンに自動アップグレードされます。Amazon MQ for RabbitMQのversion 3.8, 3.9, 3.10のサポートはまもなく終了するため、これらのバージョン、またこれら以外のバージョンに限らず早めのアップデートをお勧めします。 RDS for Db2 now supports Private Offers on licensing through AWS Marketplace AWS Marketplace経由でAmazon RDS for Db2のライセンスを利用する際に、プライベートオファーを適用できるようになりました。これまで、AWS Marketplaceの公開価格、もしくはBYOLの二択でしたが、今回のアップデートにより、Marketplaveを通じてIBMに個別見積もりのリクエストが可能になります。AWS Marketplace ライセンスオプションの詳細については、 ドキュメント にアクセスして開始してください。 ※現時点では、日本のAWSアカウントからはまだRDS for Db2のライセンスをマーケットプレイスで購入できるようになっていないためご注意ください。 7/3(水) Amazon Q Developer is now generally available (GA) in the Visual Studio IDE AWS Toolkit extensionとして利用可能なVisual Studio IDEでのAmazon Q Developer利用がGAしました。Amazon Q Developerは技術的な質問への回答、コード生成、コード説明のほか、セキュリティ脆弱性(C#のみサポート)のスキャン等が可能です。使用するにはVisual Studio 2022に無料のAWS Toolkitをダウンロードしてください。詳細は ドキュメント をご確認ください。 AWS Launch Wizard now adds programmatic deployments through APIs and Cloudformation templates AWS Launch WizardがAPIやCloudFormationを使用したプログラムでのデプロイに対応しました。AWS Launch Wizardは、Microsoft SQL Server Always OnやHANAベースのSAPシステムなどのサードパーティアプリケーション用にAWSリソースのサイジング、設定、デプロイをガイド付きで行うことができるサービスです。今回のアップデートではAPI, CloudFormation対応のほか、アプリケーション仕様をプログラムで取得するAPIも導入され、デプロイ作業がより簡単になります。東京を含む29のリージョンで利用可能です。 詳細については Launch Wizard ユーザーガイド と API ページ をご覧ください。 Amazon DataZone introduces fine-grained access control Amazon DataZoneでデータ所有者が行レベル、列レベルでのデータ制御が可能になりました。これにより、地域に応じてアクセスできる行をフィルターすることや、個人を特定できる情報(PII)などの機密性の高いデータをフィルターするなど、subscribersに必要な情報のみアクセスさせることが可能です。この機能はAWS Lake Formation と Amazon Redshift双方に対して制御されます。行・列レベルのきめ細やかな制御は東京を含む14のリージョンで利用可能です。詳細については ドキュメント をご覧ください。 7/4(木) アップデートはありませんでした 7/5(金) アップデートはありませんでした イベント情報がいくつか出ていますが、直近で AWS 初心者向けイベントである AWS Builders Online Series が7/18に開催されます。 「AWS 基礎」「生成 AI」「モダンアプリケーション開発」がテーマになっていますので、ぜひご参加ください。 また、先月開催された AWS re:Inforce 2024のre:Capイベント が7/26に開催されます。 AWS最大のセキュリティカンファレンスを日本語で振り返ることができる機会です。合わせてぜひ参加・ご活用いただけると幸いです。 それでは、また来週! 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています!
本記事は、2024年7月2日に投稿された Improve productivity when processing scanned PDFs using Amazon Q Business を翻訳したものです。翻訳は Hiroaki Hattori が担当しました。 Amazon Q Business は、生成 AI 対話アシスタントであり、企業のデータソースに格納されたデジタルコンテンツだけでなくスキャンした PDF からも、事前のテキスト抽出をせずとも直接質問に答えたり、要約を作成したり、コンテンツを生成したり、インサイトを発見することが可能になりました。 金融、保険、ヘルスケア、ライフサイエンスなど、さまざまな業界の顧客は、領収書、ヘルスケアプラン、税務申告書などのさまざまな種類のドキュメントからインサイトを得る必要がありますが、これらのドキュメントは、 PDF でスキャンし保存していることが多いです。さらにそのドキュメント形式は、半構造化または非構造化されたフォーマットになっているため、Amazon Q Business でインデックス化する前に、ドキュメントからテキストを抽出する処理が必要でした。 Amazon Q Business のスキャンした PDF のサポート開始により、Amazon Q Business が対応する AWS リージョンにおいて、 AWS マネジメントコンソール や API を介し、さまざまな種類のドキュメント形式をシームレスに処理できるようになります。スキャンした PDF を含むドキュメントを、 サポートされるコネクタ を使用してデータソースから取り込み、インデックス化することで、企業のデータを安全に活用し、質問に回答したりコンテンツを生成できます。この機能により、Amazon Q Business とは別で対応が必要であったスキャンした PDF からテキストを抽出するための開発作業が不要となり、Amazon Q Business を使用した生成 AI アシスタントを作成する際の一連のドキュメント処理フローが改善されます。 この記事では、Amazon Q Business を使用し、スキャンした PDF ドキュメントを非同期でインデックス化、リアルタイムでクエリを実行する方法を説明します。 ソリューション概要 スキャンした PDF ドキュメントを Amazon Q Business で使うには、コンソール、 AWS SDK 、または AWS Command Line Interface (AWS CLI) のいずれかが利用できます。 Amazon Q Business は幅広いデータソースと統合できるデータコネクタを提供しており、最小限のセットアップと設定で生成 AI ソリューションを作成できます。詳細については、 生成 AI を使用して従業員の生産性向上を支援する Amazon Q Business の一般提供開始 &nbsp;をご覧ください。 Amazon Q Business アプリケーションを利用する準備ができたら、コンソールまたは API を使用して、スキャンした PDF ファイルを Amazon Q Business のインデックスに直接アップロードできます。Amazon Q Business はマルチデータソースコネクタを提供しており、複数のデータリポジトリのデータを 1 つのインデックスに統合・同期することができます。この記事では、ドキュメントを使用する 2 つのシナリオを例示します。1 つは直接ドキュメントをアップロードする方法、もう 1 つは Amazon Simple Storage Service (Amazon S3) コネクタを使用する方法です。他のデータソースからドキュメントを取り込む必要がある場合は、 サポートするコネクタ を参照して、追加のデータソースを接続する方法の詳細を確認してください。 ドキュメントのインデックス作成 この記事では、スキャンした PDF ドキュメントとして請求書、健康保険の概要、雇用確認書という 3 つのドキュメントといくつかのテキストドキュメントを使用します。 最初のステップは、これらのドキュメントをインデックス化することです。Amazon Q Business の直接アップロードする機能を使用してドキュメントをインデックス化するには、以下の手順を実行してください。この例では、スキャンした PDF ドキュメントをアップロードします。 Amazon Q Business コンソールで、ナビゲーションペインから Applications &nbsp;を選択し、アプリケーションを開きます。 Add data source &nbsp;を選択します。 Upload Files &nbsp;を選択します。 スキャンした PDF ファイルをアップロードします。 アップロードしたファイルは Data Sources タブで確認できます。 Upload Status は、 Received から Processing に変わり、最終的に Indexed または Updated になります。この時点で、ファイルが Amazon Q Business のデータストアに読み込まれたことになります。次のスクリーンショットは、正常に読み込まれた PDF の例を示しています。 以下のステップは、Amazon Q Business で Amazon S3 コネクタを使用してドキュメントを統合・同期する方法を示しています。この例では、テキストドキュメントをインデックス化します。 Amazon Q Business コンソールで、ナビゲーションペインから Applications を選択し、アプリケーションを開きます。 Add data source を選択します。 コネクタとして Amazon S3 を選択します。 Name、VPC 、security group setting、IAM ロール、 Sync mode &nbsp;の情報を入力します。 データソースを Amazon Q Business に接続するため、 Add data source を選択します。 コネクタの詳細ページの Data source details セクションにおいて、 Sync now を選択することで、Amazon Q Business がデータソースからのデータの同期 (クロールと取り込み) を開始できます。 同期ジョブが完了すると、データソースを利用できるようになります。次のスクリーンショットは、5 つのドキュメント (スキャンされた PDF、デジタル PDF、テキストファイル) がすべて正常にインデックス化されたことを示しています。 次のスクリーンショットは、直接アップロードしたドキュメントと、Amazon S3 コネクタを通して取り込まれたドキュメントという2 つのデータソースに関する情報を示しています。 それでは、Amazon Q Business を使って、データソースに対してクエリを実行してみましょう。 スキャンされた PDF の情報量が多く、非構造化であるドキュメントに対するクエリ スキャンした PDF ドキュメントが情報量が多く、構造化されていないとします。Amazon Q Business は、非常に情報が込み入ったテキストであってもドキュメントを認識し情報を抽出します。この例では、先ほどインデックス化した複数ページの健康保険プラン概要の PDF を使用します。次のスクリーンショットは、その 1 ページを示しています。 これは健康保険プラン概要の一例です。 Amazon Q Business Web UI では、「What is the annual total out-of-pocket maximum, mentioned in the health plan summary?(健康保険概要プランに記載されている年間自己負担上限総額はいくらですか?)」と質問しています。 Amazon Q Business はインデックス化されたドキュメントを検索し、関連する情報を検索して回答を生成し、その情報のソースを引用します。次のスクリーンショットにサンプル出力を示します。 スキャンした PDF が構造化されており、表形式であるドキュメントに対するクエリ ドキュメントには表形式の構造化データが要素として含まれる場合もあります。Amazon Q Business はスキャンした PDF から構造化データを自動的に特定、抽出し、ユーザーからの質問に正しく回答することができます。次の例では、事前にインデックス化した請求書 の PDF を使用しており、スクリーンショットはその PDFの 1 ページを示しています。 これは請求書の一例です。 Amazon Q Business Web UI では、「How much were the headphones charged in the invoice?(請求書でヘッドフォンの請求金額はいくらでしたか?)」と質問しています。 Amazon Q Business はインデックス化されたドキュメントを検索し、情報源となるドキュメントを参照して答えを取得します。次のスクリーンショットは、Amazon Q Business が請求書から課金情報を抽出した回答例を示しています。 半構造化されたフォームに対するクエリ ドキュメントには、キーと値のペアといったフォーム形式で半構造化データが含まれている可能性があります。Amazon Q Business では、クエリに関係する特定の項目や属性を取り出すことにより、これらのデータに関連するクエリに正しく回答することができます。次の例では雇用確認書の PDF を使用しており、スクリーンショットは、そのドキュメント例です。 これは雇用確認フォームの一例です。 Amazon Q Business Web UI では、「What is the applicant’s date of employment in the employment verification form?(雇用確認書にある求職者の雇用開始日はいつですか?)」と質問します。Amazon Q Business はインデックス化された雇用確認書を検索し、ソースドキュメントを参照しながら回答します。 AWS CLI を使用したドキュメントのインデックス作成 このセクションでは、AWS CLI を使用して、S3 バケットに格納されている構造化ドキュメントと非構造化ドキュメントを Amazon Q Business インデックスに取り込む方法を説明します。ドキュメントの詳細情報 (ステータスやインデックス作成中のエラーなど) をより早く取得できます。もし、PDF ファイルやその他のサポートされているファイル形式でインデックス化したドキュメントを保持する既存の Amazon Q Business ユーザ であり、スキャンしたドキュメントを再インデックス化したい場合は、以下の手順を実行してください。 それぞれのドキュメントのステータスを確認することで、ステータスが "DOCUMENT_FAILED_TO_INDEX" のような失敗したドキュメントを絞り込むことが出来ます。また、次のエラーメッセージに基づいてドキュメントを絞り込むことも可能です。 "errorMessage": "Document cannot be indexed since it contains no text to index and search on. Document must contain some text." 新しいユーザーでまだドキュメントをインデックスしていない場合は、このステップを省略できます。 以下は、 ListDocuments API を使用して、あるステータスのドキュメントとそのエラーメッセージを絞り込む例です: aws qbusiness list-documents --region &lt;region&gt; \ --application-id &lt;application-id&gt; \ --index-id &lt;index-id&gt; \ --query "documentDetailList[?status=='DOCUMENT_FAILED_TO_INDEX'].{DocumentId:documentId, ErrorMessage:error.errorMessage}" \ --output json 次のスクリーンショットは、AWS CLI の出力を示しており、エラーメッセージとともに失敗したドキュメントの一覧が表示されています。 今度はドキュメントをバッチ処理します。Amazon Q Business では、Amazon Q Business インデックスに 1 つまたは複数のドキュメントを追加できます。 BatchPutDocument API を使用して、S3 バケットに格納されている複数のスキャンされたドキュメントをインデックスに取り込みます。 aws qbusiness batch-put-document --region &lt;region&gt; \ --documents '[{ "id":"s3://&lt;your-bucket-path&gt;/&lt;scanned-pdf-document1&gt;","content":{"s3":{"bucket":"&lt;your-bucket&gt; ","key":"&lt;scanned-pdf-document1&gt;"}}}, { "id":"s3://&lt;your-bucket-path&gt;/&lt;scanned-pdf-document2&gt;","content":{"s3":{"bucket":" &lt;your-bucket&gt;","key":"&lt;scanned-pdf-document2&gt;"}}}]' \ --application-id &lt;application-id&gt; \ --index-id &lt;index-id&gt; \ --endpoint-url &lt;application-endpoint-url&gt; \ --role-arn &lt;role-arn&gt; \ --no-verify-ssl 次のスクリーンショットは、AWS CLI の出力を示しています。失敗したドキュメントのリストが空になっていることがわかります。 最後に、 ListDocuments API を再度使用して、すべてのドキュメントが正しくインデックス化されたかを確認してください: aws qbusiness list-documents --region &lt;region&gt; \ --application-id &lt;application-id&gt; \ --index-id &lt;index-id&gt; \ --endpoint-url &lt;application-endpoint-url&gt; \ --no-verify-ssl 次のスクリーンショットは、ドキュメントがデータソースでインデックス化されていることを示しています。 クリーンアップ 新しい Amazon Q Business アプリケーションを作成した後、それ以上使用する予定がない場合は、アプリケーションから割り当てられたユーザーを削除し、サブスクリプションを解除してアプリケーションを削除することで、AWS アカウントに追加コストが発生するのを防ぎます。また、インデックス化されたデータソースをこれ以上使用する必要がない場合は、 Managing Amazon Q Business data sources を参照し、インデックス化されたデータソースを削除する手順をご確認ください。 まとめ この投稿では、Amazon Q Business でスキャンされた PDF ドキュメントのタイプがサポートされていることを示しました。これによって、生成 AI と Amazon Q Business を使用して、スキャンした PDF を含むサポートするドキュメント形式に対して、同期、インデックス作成、クエリを実施する手順を確認しました。また、Amazon Q Business の Web UI と AWS CLI を使用して、構造化、非構造化、または半構造化の、マルチモーダル化されたスキャン済みドキュメントに対するクエリの例を示しました。 この機能の詳細については、 Amazon Q Business でサポートされるドキュメントの形式 を参照してください。今すぐ Amazon Q Business コンソール で試してみましょう! 詳細については、 Amazon Q Business と Amazon Q Business ユーザーガイド を参照してください。フィードバックは Amazon Q の AWS re:Post または通常の AWS サポート連絡先からお送りいただけます。 著者について Sonali Sahu&nbsp; は、AWS で 生成 AI スペシャリストソリューションアーキテクトチームをリードしています。彼女は著者、思想家、そして情熱的な技術者です。彼女の注力領域は AI と ML であり、世界中の AI と ML の会議やミートアップで頻繁に講演しています。彼女は技術と技術業界の両方で幅広く深い経験を持っており、医療、金融、保険などの業界の専門知識を持っています。 Chinmayee Rane&nbsp; は、AWS で生成 AI スペシャリストソリューションアーキテクトです。彼女は応用数学と機械学習に情熱を注いでいます。彼女は、AWS 顧客向けのインテリジェントドキュメント処理と Generative AI ソリューションの設計に注力しています。仕事以外では、サルサとバチャータダンスを楽しんでいます。 Himesh Kumar は、経験豊かなシニアソフトウェアエンジニアで、現在 AWS のAmazon Q Business に在籍しています。生成 AI および ML 分野の分散システムの構築に情熱を注いでいます。スケーラブルで効率的なシステムを開発し、高い可用性、パフォーマンス、信頼性を確保するのが得意分野です。技術的な能力に加えて、継続的な学習に努め、AI および機械学習における技術の最前線にいることを目指しています。 Qing Wei は、AWS の Amazon Q Business チームのシニアソフトウェア開発者であり、AWS テクノロジーを使用して最新のアプリケーションを構築することに注力しています。彼は、機械学習のホスティングと推論に関連するトピックについて、コミュニティ主導の学習と技術の共有に興味があります。現在は、RAG データ取り込みのためのサーバーレスおよびイベント駆動のアーキテクチャの構築に焦点を当てています。
本ブログは、株式会社セゾンテクノロジー データインテグレーションエンジニア 石原直樹氏 と アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 藤原、田原 が共同で執筆いたしました。 はじめに セゾンテクノロジー は、「世界中のデータをつなぎ、誰もがデータを活用できる社会を作る」というミッションを掲げています。自社製品である「HULFT(ハルフト)」は、国内外で広く活用されるデータ連携製品へと進化し、近年はポートフォリオをさらに拡充させています。昨今急速に進化をしている生成 AI は企業ミッションとも親和性が高く、セゾンテクノロジー内では個人やプロジェクト、チーム単位で活用方法を模索する動きが活発化していました。そこで、各部門に分散していた生成 AI の知見を集約し発展を加速させるため、全社横断的な研究会である LLM Mavericks を設置し、生成 AI の研究や活用に取り組んでいます。 本ブログでは、LLM Mavericks の活動の一環として、 Amazon Bedrock を活用した AI チャットボットを HULFT 製品のテクニカルサポートセンターに導入した事例について解説します。なお、本事例は 2024 年の AWS Summit Japan の基調講演でも取り上げられました。 導入背景 HULFT 製品のテクニカルサポートセンターでは、サポートエンジニアはお客様からの問い合わせに対し、数万ページにも渡るマニュアルや FAQ、及び、膨大な過去の問い合わせ履歴から必要な情報を検索して回答を作成しており、若手のサポートエンジニアのスキル育成や、回答作成時の心理的負担を軽減したいことから、検索の効率化を検討していました。 本課題を解決するために、セゾンテクノロジーは Amazon Bedrock を活用した Retrieval-Augmented Generation (RAG) の仕組みを構築しました。 これにより、RAGシステムが問い合わせ内容から自動的に関連情報を抽出し回答案を生成するため、エンジニアは複数のサイトを横断したり、適切な検索クエリを考えたりする負担が軽減されます。さらに、検索結果の内容を精査し回答を一から作成する必要がなくなるため、業務効率が向上し、エンジニアの心理的負担も軽減されると期待しました。 図1:RAGシステム導入前後のテクニカルサポート業務フロー比較 ソリューション / 開発における工夫 AWS を活用して RAG の仕組みを構築するには、下図に示すように複数のパターンを取ることができます。それぞれの手法で開発の自由度や開発の容易さ、運用の負荷などが変わってきますが、AWS はお客様のユースケースに応じて最適なサービスを選択できるように様々な選択肢を用意しています。 図 2: AWS サービスを活用した RAG の実装アプローチ 開発当初は、 Amazon Kendra や Knowledge Bases for Amazon Bedrock を活用し検証していましたが、サポートエンジニアから「質問への回答に関係のない情報が含まれる」というフィードバックがありました。分析の結果、Knowledge Bases for Amazon Bedrock のベクトル検索では、HULFT製品特有の単語や文章を、正しくベクトル検索できていないことが判明しました。一方、Amazon Kendraでは、日本語の分かち書きの精度が不十分であったり、また、検索結果の取得トークン数の制限により、文脈の断片化が起こるという課題がありました。 これらの問題に対処するため、ベクトル検索だけでなく、日本語の分かち書きが得意なsudachiトークナイザーを利用したキーワード検索も導入しました。さらに、検索対象のドキュメントを階層的にチャンク分割し、検索時には粒度の細かいチャンクを用いて高精度な検索を行い、その後関連する上位階層のチャンクを取得することで、文脈を保持する方式を採用しました。さらに、複雑な質問に対応するため、Large Language Model (LLM)によるクエリ拡張の手法を取り入れました。このように、フィードバックを元に段階的な改善を重ねながら開発を進めていきました。 現在のアーキテクチャは以下の図の通りで、サーバーレスアーキテクチャを採用しています。ドキュメントおよびアプリケーション、ライブラリは、すべてコンテナイメージとして Amazon Elastic Container Registry に格納しています。これらのイメージは AWS Lambda によってPullされ、実行環境として使用されます。 では、お客様からの問い合わせをきっかけに、RAGシステムがどのように回答を生成するかを見ていきましょう。お客様から問い合わせがあった際に、サポートエンジニアが Slack 上で AI チャットボットに質問内容をメンションします。投稿された質問文から、 Anthropic Claude 3 Haiku によりキーワードや類似語が抽出され、複数の検索クエリが生成されます(クエリ拡張)。生成されたクエリを元に、まずキーワード検索を行い、キーワードに関連するドキュメントをN件に絞り込みます。次に、階層化されたチャンク構造のベクトルDB(FAISS)に対して、ベクトル検索を実行し、意味的に関連するドキュメント上位K件に絞り込みます。最後に、絞り込まれたドキュメントを基に、Cohere Command R+ により回答が作成され、Slack で回答が返ってきます。 図 3:RAGシステムのアーキテクチャ図 このように、 Advanced RAG に分類される手法を導入しています。これらの処理の組み合わせにより、検索精度と文脈保持を両立し、Amazon Kendraを活用したRAGと比較して14%、Knowledge Bases for Amazon Bedrockと比較して22%の回答精度向上を達成しました。 複数モデルでの検証の結果、クエリの生成には、日本語の理解と生成に優れており、高速な応答性能を示した Anthropic Claude 3 Haiku を採用しました。回答の生成は、RAG の用途に最適化された機能を持つ Cohere Command R+ を採用したことで、開発時に複雑な処理を必要とせず、説明可能性が高い回答を得られるようになりました。 また、本事例の特徴として、 Guardrails for Amazon Bedrock の機能を組み込んで責任ある AI チャットボットを構築していることが挙げられます。具体的には、製品のシリアル番号などの特定の機密情報の入力を制限するルールを設定することで、AI チャットボットをより安全に活用できる環境を簡単に整備できました。 導入効果 本RAGシステム導入により、サポートエンジニアの回答作成時間は最大で 30 % 短縮されました。若手のサポートエンジニアだけではなく熟練したサポートエンジニアにも導入の効果があり、テクニカルサポートセンター全体でみると、導入前と比較して約 10 % 業務が効率化されています。さらに、サポートエンジニアの半数以上からは、回答作成時の心理的負担が軽減したといったフィードバックも得られています。 また、サーバーレスアーキテクチャを採用したことで、システムの運用負荷を大幅に削減し、かつ、サポートエンジニアからの質問 1,000 件あたり 30 ドル以下の低コストを実現しています。 まとめ 本ブログでは、セゾンテクノロジーによる、Amazon Bedrock を活用したRAGシステムの HULFT 製品のテクニカルサポートセンターへの適用事例について紹介しました。Amazon Bedrock では、複数の基盤モデルを用途に応じて選択できること、Guardrails for Amazon Bedrock でポリシーに基づいたデータの制御ができることなど、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供しています。本事例はそのような Amazon Bedrock のメリットを活かしており、これから生成 AI アプリケーションの構築を検討されるお客様のご参考になれば幸いです。 セゾンテクノロジーは、今後の展開としてAgents for Amazon Bedrockの導入を計画しています。この導入により、利用者からの質問内容を事前に分析して不適切な内容をブロックする機能や、必要に応じて利用者に追加の質問を行う機能を取り入れることで、より安全で正確な回答の生成を目指しています。
みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 7月になりましたので、AWS公式ウェブマガジン” builders.flash “で新しい記事が公開されましたので、今月も生成AIに関連するものをピックアップしてみましょう。 Amazon Bedrockを活用して3Dキャラクターと対話するサービスを構築する(ピクシブ株式会社様) ガーデニングの新時代!Amazon Bedrock で理想の庭を実現してみた ~GreenSnap株式会社による生成AI実装解説~(GreenSnap株式会社様) 生成AIで飲みニケーション対策!無料の生成AIプレイグラウンドPartyRockで新入社員がアプリを作ってみた! ひとつめの記事は ピクシブ株式会社 様に寄稿いただいたものです。ピクシブ株式会社様は3Dキャラクターと対話ができるサービス、「 ChatRoid 」を提供していますが、そのなかで Amazon Bedrock をご利用頂いています。この記事ではアーキテクチャとその選定理由が紹介されています。 ふたつめの記事は GreenSnap株式会社 様によるもので、 Amazon Bedrock を利用した画像加工の新サービス、「 gardenAI 」について紹介しています。このサービスは生成AI技術を利用して庭や外構をリアルにデザインするサービスで、実際の写真を加工することが可能だそうです。 Amazon Titan Image Generator G1 を画像生成に、プロンプト生成にAnthropicのClaude 3 Haikuを利用していますので、この利用例にも注目です。 みっつめの記事は、 PartyRock でアプリを作るというテーマですが、会話形式のストーリーにまとめられているので気軽に読んでいただけます。PartyRockは気軽に生成AIアプリケーションを作る体験ができるツールですが、どう使ったらいいかイメージが湧かないという方もいらっしゃいます。この記事を見ていただくと、PartyRockでアプリケーションを作る流れをつかめるので、ぜひどうぞ。 それでは、7 月 1 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: AI Inside株式会社様、セキュアな生成AI環境で対応可能な帳票の大幅な拡充に成功 AI Inside株式会社 様は、AIエージェント「 Heylix 」やAI-OCRサービス「 DX Suite 」に加え、それを支えるAIインフラ「 AnyData 」「 AI inside Cube 」を提供しています。これまで手入力が必要だった帳票処理をデジタル技術で効率化するのがAI-OCRを提供するDX Suiteですが、書類はフォーマットが統一されていないものも多く、モデル学習が必要になるケースがあり、その対応には約2,000万円の費用と1ヶ月以上の期間が必要という課題がありました。この課題に対してLLM(大規模言語モデル)による解決にチャレンジし、サービス開始から7年間の期間で13種類が提供されるにとどまっていた非定型帳票対応用のプリセットが、3ヶ月間で1,000種類を超えるという成果を上げています。これを支えたのは Amazon Bedrock です。推論データがモデル学習に再利用されない事に加えて、 Amazon EKS(Elastic Kubernetes Service) で稼働するアプリケーションから AWS PrivateLink でよりセキュアな接続が可能な点がポイントとなりました。 ブログ記事「Amazon Bedrock Claude 3.5 Sonnetを活用して大学レベルの専門知識を必要とする工学的問題を解く」を公開 AnthropicのClaude 3.5 Sonnetが発表され、 Amazon Bedrock でも用途に応じて選べるモデル選択肢のひとつとして、米国リージョンでご利用頂けるようになっています。この記事では、機械設計を例にとって機械力学・材料力学・熱力学・流体力学の知識が必要な問題をClaude 3.5 Sonnetを活用して解決することが可能な例をご紹介しています。生成AIは完全ではありませんので、問題が複雑になればなるほど誤答の可能性も高まります。ですがそれを前提に、熟練者に対して手がかりとなる参考情報を素早く与えてくれるという見方をすれば、日々の業務に活用できる部分もかなり存在するのではないでしょうか。 ブログ記事「生成AIを圧要して工場の稼働率低下の原因分析を行う」を公開 6月20日21日に開催した AWS Summit Japan では、生成AIの活用に向けたたくさんのアイデアを展示しました。その中でも人気があったもののひとつが、ミニチュア組立工場を動かしながらスマート工場における生成AIの活用ケースのデモです。このブログ記事では、このデモのなかから「工場の稼働率低下の原因分析を生成AIで実現」というトピックにフォーカスしてご紹介しています。コンセプトやアーキテクチャの詳細な解説をしていますので、みなさんの業務への応用のヒントになるのではないでしょうか。 ブログ記事「スマートシティ向けの早期火災検知設計モデル: AWS IoTおよびMLテクノロジーの活用」を公開 生成AI活用のど真ん中、という訳ではないのですが、生成AIを実生活に取り込む上でのヒントになりそうだなと思ったのでピックアップした記事です。このブログ記事は、AWS IoTを活用してデータを収集し分析することで火災の発生を早期に検知するとともに、データに基づいて機械学習モデルを利用することで火災予測を可能にするアイデアを解説しています。この記事は「スマートシティの火災」に焦点を当てていますが、交通網の改善や環境問題への対策など、同じ考え方を適用できる領域は多岐にわたります。もしかすると、ビルや工場の管理にも応用できるかも知れませんので、ご興味がありましたらぜひご一読ください。 ブログ記事「LLMの埋め込み情報ドリフトをAmazon SageMaker JumpStartから監視する」を公開 多くのお客様が取り組んでいる検索拡張生成(RAG)についての理解を深め、精度向上のための打ち手を考えるヒントに成り得るブログ記事です。RAGではドキュメントを埋め込みベクトル(Embeddings)で表現しデータベースに格納、ユーザからの問い合わせと関連性の高いものを検索します。そのため、埋め込みベクトルの変化(この変化をドリフトと呼びます)の有無を測定することで、より高精度なアプリケーションを実現するための打ち手の要否を判断する事につながります。実際に手元で試せるような構成になっていますので、ぜひ時間を取って試してみてください。 サービスアップデート Visual Studio IDEにおけるAmazon Q Developerが一般利用開始に Visual Studio IDEにおいて Amazon Q Developer が一般利用開始になりました。Amazon Q Developerは技術的な質問に答える、コードを生成する、既存コードを説明する、といった機能を通じてソフトウェア開発をシンプルにします。例えば、「Lambda関数をAWSにデプロイする前にローカルでデバッグする方法は?」「この関数に対するテストケースを生成して」といったリクエストに応えることができます(現時点では英語を正式サポート)。この機能はVisual Studio IDEの拡張機能であるAWS ToolkitにAmazon Q Developerが組み込まれている、という形で提供されます。 Amazon SageMaker StudioがAmazon S3 Access Grantsとの統合が可能に Amazon S3 Access Grants は、Active DirectoryをはじめとするIDプロバイダの情報や、AWS IAMのプリンシパル情報に基づいてAmazon S3のオブジェクトに対するアクセス権を自動的に付与する仕組みで、データアクセスのガバナンス向上に活用できる機能です。今回、Amazon SageMaker StudioからAmazon S3 Access Grantsを利用したデータアクセスができるようになり、データアクセスが容易になるとともに「最小権限の原則」を実装しやすくなります。 Amazon EKSがEC2 capacity blocks for MLをネイティブにサポート マネージド型ノードグループを利用している Amazon EKS のクラスタで、 EC2 capacity blocks for ML で確保されたインスタンスをネイティブに利用できるようになりました。EC2 capacity blocks for MLは機械学習ワークロード向けにGPUインスタンスを予約できる仕組みです。Kubernetesを利用してAI/MLワークロードを実行している方が、リソース確保とその利用をするのが容易になるアップデートです。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。
みなさん、こんにちは!製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田と新澤です。 AWS Summit Tokyo が 2024 年 6 月 20 日(木)、21 日(金)の 2 日間、幕張メッセにて開催されました! 大盛況のまま無事イベントを終えることができました! 製造業向け展示ブースでどのようなデモが披露されたかについては以下の予告ブログもご参照ください。 AWS Summit Japan 製造業向け展示の見どころ紹介! 今回はその中から、「製造現場の IoT データをパートナーとともに 小さく早く製造 DX を実現」というタイトルのブースの一部をご紹介します。このブースでは、ミニチュア組立工場を動かしながら AWS を活用したスマート工場の複数のユースケースのデモを行いました。この中から「 生成 AI を活用して工場の稼働率低下の原因分析を行う 」というユースケースにフォーカスして解説させていただきます。 デモ全体像 図1~3に ミニチュア組立工場 外観図や、全体における生成 AI を活用した工場の稼働率低下原因分析の位置付けを示しました。 図1 ミニチュア組立工場外観図 図2 「製造現場の IoT データをパートナーとともに小さく早く製造 DX を実現」ブースのユースケースオーバービュー 図3 「製造現場の IoT データをパートナーとともに小さく早く製造 DX を実現」ブースのアーキテクチャオーバービュー 生成 AI を活用して工場の稼働率低下の原因分析を行うユースケースシナリオ 図4 には生成AIを活用して工場の稼働率低下原因分析を行う際の想定ユースケースシナリオを示しました。 データを取得することはできているものの、統合的に組み合わせて有効な分析に繋げることができておらず、宝の持ち腐れになってしまっているといった課題はよくあるのではないかと思います。 既に取得できている他の関連データを Amazon S3 に集約して、そういった大量の実データをソースとして、生成 AI の RAG (検索拡張生成) 技術で稼働率の低下原因を分析することで、あるものを活用して小さく早く改善していこうというシナリオになっています。 図4 生成 AI を活用して工場の稼働率低下の原因分析を行う際の構成図とユースケース 図5 には、分析対象となる各種データと Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションのイメージの全体像を示しました。 4M とは、製造業での品質管理において重要な、Man(人)、Machine(機械)、Material(材料)、Method(方法)の4つの要素を指します。 4M 分析のフレームワークは、製造に関わる変更点を洗い出し、把握する手法の一つです。装置が計画外停止した際、その原因が装置そのものの不具合による場合もあれば、材料や部品の投入ミス、急なシフト変更に起因する作業者のオペレーションミス、工程変更が伝わっていなかったなどの情報伝達に起因するミス、厳しすぎる検査規格値など、様々な要因が考えられます。原因分析の際には、これらのどれかに固執することなく、抜け漏れなく要因を検証する必要があります。その際に有効なフレームワークです。 それぞれ、 Man : ERPから取得した作業者情報の csv ファイル Machine : タブレットから取得した日常設備点検簿の excel ファイル Material : 在庫管理システムから取得した csv ファイル Method : 工程管理システムから取得した csv ファイル として Amazon S3 にデータが集約されています。また、 AWS IoT Greengrass 、 AWS IoT SiteWise を介して取得されたデータを ”工場設備の稼働率 CSV” に変換し、それも S3 に格納します。これらの一連の CSV ファイルを RAG の分析対象として扱います。 図5 各種データと Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションイメージ 各種データ 図6~11では各種データの拡大画像およびデータの特徴を示しています。 図6 AWS IoT SiteWise からエクスポートされた raw データを csv に変換した設備稼働率ファイルイメージ 図7 Machine : タブレットから取得した日常設備点検簿の excel ファイル(正常な日)イメージ 図8 Machine : タブレットから取得した日常設備点検簿の excel ファイル(異常な日)イメージ 図9 Material : 在庫管理システムから取得した 4 月分の csv ファイルイメージ 図10 Method : 工程管理システムから取得した 4 月分の csv ファイルイメージ 図11 Man : ERPから取得した 4 月分の作業者情報の csv ファイルイメージ 各種データを見ると、まず設備稼働率 csv ファイルから、4/5 15:00 に稼働率が異常に低下していることがわかります。その日時の少し前に何か異変が見当たらなかったかを 4M ファイルで調べたところ、日常設備点検簿において、該当日時の少し前に空調設備異常があったことがわかります。その他のファイルでは特に異変はありませんでした。 取り扱うデータ量が多いほどこういった様々な事象を人間が分析するのは難しくなります。生成 AI のRAG 技術で効率的に分析してみましょう。 分析 Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションは、AWS が GitHub で提供しているこちらの Generative AI Use Cases JP よりデプロイしました。Generative AI Use Cases JP は、すぐに業務活用できるビジネスユースケース集付きの安全な生成 AI アプリ実装サンプルです。OSS として無償提供しており、生成AIの様々なユースケースを試すことができます。 図12 Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションでの RAG チャットの様子 このアプリケーションを用いて、 Knowledge base for Amazon Bedrock と連携した Agents for Amazon Bedrock で RAG を実行します。 RAG (検索拡張生成) とは、ユーザーからの問い合わせに対して、例えば社内のデータソースなどから関連情報を検索し、取得された関連情報も含めてモデルに入力し回答を得るものになります。信頼できる情報源から知識を取り入れることで、生成される応答の事実性と正確性が向上します。単にモデルの出力に頼るのではなく、根拠となる情報を参照できます。 Knowledge base for Amazon Bedrock は、基盤モデルと自社データソースを組み合わせた RAG をフルマネージドで実現可能にします。Knowledge Bases for Amazon Bedrock の仕組みや操作方法の詳細については こちらのブログ をご参照ください。 あらかじめドキュメントデータ(今回の場合は CSV や EXCEL)を DB に検索可能な形(ベクトル表現)で格納しておきます。そして、ユーザーからの問い合わせから、内容の似たドキュメントを検索し、そのドキュメントの内容に基づいて基盤 Text モデルに回答させます。 図13 Knowledge base Amazon Bedrock の RAG のしくみ Amazon Bedrock は様々な種類・数のモデルを提供しており、お客様はユースケースに適したものを選択いただくことができます。今回はそんなモデルの中から、図13 の③、⑤の Embedding モデルには Amazon Titan Text Embeddings v2 を、Text モデルには Claude 3 Sonnet を選択して RAG を実行しています。 Agents for Amazon Bedrock は、API を呼び出しタスクを実行する Agent 機能をフルマネージドで提供しています。基盤モデルを使ってユーザのクエリを理解し、登録された情報を Knowledge Base から検索したり、タスク完了に必要なアクションを実行することができます。 分析を始めます。まず、図12 における一つ目の質問で稼働率が極端に低くなっている日時を抽出してもらいました。すると、図6 を見ても分かる通り、22.0 % と異常に低下した日時が的確に抽出されました。 次に、その日時よりも少し過去に発生した事象から、稼働率が極端に低くなった原因について考察をしてもらいました。参照するファイルについても明確に指定をしています。生成 AI プロンプトエンジニアリング(モデルに入力・指示する文字列であるプロンプトを工夫して書いて、望ましい出力を得るための工夫)について、なるべく曖昧にならないように、簡潔に、明確に、十分な情報を与えることが重要です。 その際、4M 変換点フレームワークを意識してMan(人)、Machine(機械)、Material(材料)、Method(方法)の4種類のデータを網羅的に参照するように指示をすることで 、より精度の高い返答を得られる可能性が高まります。 すると、日常設備点検簿から空調設備にエラーコード 123 が発生したことが原因だという考察を返してくれました。他に大きな異変が確認できないため、この回答も妥当であることがわかります。 ただし、質問内容や検索対象の情報が複雑になるほど RAG で得られる回答の品質は低下する傾向があります。期待通りの回答が得られない場合は、 こちらのブログ で紹介されているようなRAG のパフォーマンスを改善するための手法を試すなどして応答品質の向上を図りましょう。 まとめ このデモのように装置から生成される稼働情報が示す稼働率低下や、生産現場で日々発生する品質問題というのは、あくまで’結果’です。しかし、再発防止策を検討する際には、それらを引き起こした’原因’を突き止める必要があります。その原因は4M(人、機械、材料、方法)のどこかに含まれているだろうという考え方が、このデモの前提となっています。 一方で、実際の製造現場において、このデモのように綺麗に 1 ファイルごとに 4M のそれぞれの M が情報としてまとめられているケースは少ないかもしれません。それでも従来からのフレームワークである 4M 変化点を意識して、プロンプトに参照先を指定することで、より早く原因に辿り着けるのではないか、というのがこのデモの主旨になります。 生成 AI の RAG 技術を活用すれば、PDF や Word ファイルのような様々なデータを対象に、データに基づいて対話的に分析できます。今回は稼働率が極端に低くなっている日時を手動のプロンプト打ち込みで抽出しましたが、稼働率に閾値を設けて、それを下回った場合に自動的にアラートメールを流すようにして、それをキックに Amazon Bedrock に分析依頼をかけるようなパイプラインを構築して自動分析することも可能です。 AWS の様々なサービスと組み合わせてどんどん機能拡張させていくことが可能ですが、まずは初めの一歩として、本デモブースのテーマである「小さく早く製造 DX を実現」することを目標に、対象を小さく絞って PoC (概念実証)を実施し、小さな成功体験を積み重ねて大きな業務変革に繋げていただけますと幸いです。 著者プロフィール 山田 航司 (Koji Yamada) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。 &nbsp; &nbsp; &nbsp; &nbsp; 新澤 雅治 (Niizawa Masaharu) アマゾン ウェブ サービス ジャパン合同会社 IoT スペシャリスト ソリューションアーキテクト 製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様のIndustrial IoT 関連案件の支援に携わる。
本稿では株式会社NTTドコモにおいて、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 前回の記事は以下です。 第一回 適切なデータストアの選定とアーキテクチャの見直し 第二回 アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜 1.需要予測の難しさとキャッシュ戦略・バックエンドの保護の必要性 システムを設計するにあたり、どの程度リソースを用意するべきか、正確に推測するのは容易なことではありません。ビジネス目標に対応したスケーラビリティを確保しようとするのは通常のことですが、例えば、ある Live 配信のビジネス目標とされる視聴ユーザー数が A人だった場合、それに対応したシステムを作るには何が必要でしょうか? まず、ビジネスの観点での需要予測を、システムを設計するのに十分な粒度に落とし込む必要があります。システムを設計するのに必要な需要予測は機能別の API ごとの最大ピークアクセスが想定されるべきです。例えば、配信開始時間があらかじめ告知されている Live の場合は、配信開始時間の数分前に視聴開始が集中することが想像できます。そうした場合には視聴開始にまつわる API を視聴ユーザー数 A人が数分間、数秒間といった短い間に実行する可能性があり、そのピークに耐える必要があります。配信開始時間が正確にわからない場合、視聴ユーザーA人はまばらにアクセス開始するかもしれません。配信の特性を踏まえて、過去の同様の配信時の実績データなどを踏まえた知見から予測していくことになります。 また、視聴開始以外の API にスパイクアクセスは必ずしもこないことも考慮すべきです。アプリケーションを初回ダウンロードしてユーザー登録をするための API はライブを見たいユーザーのなかで初回にアプリにアクセスするユーザーだけが実行する処理となり、ライブ直前に行う必要がある処理ではありません。事前にアプリをダウンロードし登録を済ませてくれたユーザーが多ければ、その API についての秒単位の需要予測は必ずしも高くないかもしれません。配信を視聴するための契約をする API やアカウントを作成するAPIについても同様です。余剰のリソースを無駄に確保しないためにも本当に高いトランザクションを捌く必要があるAPIはどれか、認識しておくことが重要です。 例)視聴ユーザー数 A人でも視聴開始のアクセス数は分散する どの API がどの程度のスパイクアクセスに耐えるべきか、需要予測を適切に行うには過去の配信時の実績ベースのデータが有用です。過去の配信時の実績データを活かす仕組みが必要になります。これまでに行ったことがない配信を実施する場合、正確に需要予測をする難易度は上がります。 需要予測を正確に行うことができれば、多くのユーザーに最適なシステムリソースでサービス提供が可能になります。しかし、需要予測は必ず当たるとはかぎりません。急にその Live 配信が話題になり、視聴数が一気に跳ね上がる可能性があります。できるだけスケーラブルに、コスト効率よくサービス提供するためにはキャッシュ戦略が必要となり、需要予測が想定を超えた場合にビジネス影響範囲を小さくするためにはバックエンドの保護が必要になります。 2.キャッシュ戦略 キャッシュを活用することはバックエンドに何度も問い合わせることをしないため、より低レイテンシーでコスト効率よく、スパイク時の影響を最小限にすることにつながります。 AWS のサービスを活用するとデータ特性に応じた複数箇所でのCacheを作成することが可能で、Lemino では以下のように使い分けしています。 Amazon CloudFront エッジロケーションというグローバルのネットワークを経由してコンテンツを配信。 応答がユーザー情報に依存しない API はCDN(Contents Delivery Network)でキャッシュすることで負荷及び応答性能を大幅に改善 例)クライアント向けの作品情報の取得 Amazon DynamoDB Accelerator (DAX) 更新頻度が少なく、アプリケーションからの読み込みアクセスが多いレコード 例)アプリケーション内での映像情報の取得 Amazon DynamoDB DynamoDB に RDS と同一のデータを持たせ、キャッシュ用途のように、ユーザーの読み込みリクエストで活用することで、高い秒間の読込み性能が必要なデータをスケーラブルに、運用負荷少なく管理 例)購入情報等 ※RDS の Reader や ElastiCache を活用することも RDS の Read 性能を上げたい場合は選択肢ですが、ライブ配信開始時のような急激なスパイク負荷を想定する場合、インスタンス追加に伴うスケールアウト完了までの時間を許容できませんでした。その点、DynamoDB のオンデマンドキャパシティモードでは、該当テーブルの以前のピーク時のトラフィックの最大 2 倍まで即座にスケールできます。RDS の Reader や ElastiCache のノードの追加が流量の増加に間に合わなかった場合のサービスへの影響と運用の手間などを考慮し、DynamoDB に一部のデータを常に同期することを選択しています。 このほかに、アプリケーション側でも、ユーザに依存せず再利用可能なデータをローカルでキャッシュすることでデータストアの負荷を抑制しています。様々な場所で可能な限りキャッシュを活用することはバックエンドの保護につながっています。 3.バックエンドの保護 需要予測の精緻化とキャッシュの活用をしても、バックエンドに対して予測を上回るリクエストがくる可能性は0にはなりません。一部の API 負荷の想定外の高まりで、バックエンドの使用率が増えることでサービス全体に影響を与えることや、配信以外の共通基盤への影響は避けなければなりません。バックエンドの許容量やボトルネックとなる API の閾値をベースに、想定を超えるリクエストについてはスロットリングするか、待機させることが必要です。現在接続しているユーザーの処理を優先し、新規接続については仮想待合室などでコントロールを行えるようにする、等の工夫によりサービス全体への影響は避け、想定外のアクセス急増にも対応できるようにしておきます。 例えば、1分間でX回処理する性能と、1秒間でX回処理する性能では、当たり前ですが、事前に用意しておくべきシステムリソースが異なります。数秒待たせるだけで、必要なシステムリソースを抑え、スパイクアクセスに耐えきれないことによるサービス障害を抑えることが可能になるケースもあります。 そのアクセスはどの程度ならユーザー体験を損ねずに待たせることが可能か、どの程度時間があればリソースを追加することができるのかも検討しつつ、スパイクアクセスがサービス全面停止に繋がらないようにする必要があります。 Lemino のサービスでは大規模なスパイクアクセスが発生する場合には契約などの一部の導線に仮想待合室を設置しています。 仮想待合室のアーキテクチャは Virtual Waiting Room を参考にスケーラビリティを改良しています。 Lemino のサービスは複数のシステムが連携して動くため、dアカウントの認証などは別の担当チームがあり、自分たちのチームだけではスケールをコントロールできないことがあります。 最後の手段として、他システムも含めたバックエンドを保護するためにスロットリングさせることも選択肢です。 4.まとめ アクセスの急増に対する対応策として、まずは需要予測を精緻化し、事前に必要となるシステムリソースを認識することが大切です。それを上回るスパイクアクセスに備えて、キャッシュ戦略とバックエンドの保護が大切であることをお伝えしました。 アクセスの急増を想定し、想定外に備えるシステムを検討中の皆様の参考にしていただければ幸いです。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当 松原拓也 株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 津和崎美希 通信業界のお客様を担当するソリューション アーキテクト。普段はお客様のAWS活用を支援していますが、ObservabilityについてはAWS社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Serviceのご支援にも手を広げ、幅広いAWS活用をご支援しています。
みなさん、こんにちは。パブリックセクターでビジネス開発、マイグレーションプログラム推進をしている今井です。 アマゾン ウェブ サービス ジャパン(以下、AWS)では、AWSへの大規模なシステムの移行を実現し、ひいてはお客様のデジタルトランスフォーメーションをサポートする 「 AWS ITトランスフォーメーションパッケージ(ITX) 」を2021年に、2022年には内容を強化・拡大した「 AWS ITトランスフォーメーションパッケージ2.0(ITX2.0) 」をリリースしました。2023年にはITXパッケージ2.0をより包括的に進化させた「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー(ITX 2023) 」をリリースし、2021年以来多くのお客様にご活用頂き、企業のITトランスフォーメーションを支援してきました。 今回のブログでは、2024年6月にリリースした最新版の「 AWS ITトランスフォーメーションパッケージファミリー(ITX) 」の中で新たに取り入れられた、公共のお客様に向けて開発されたAWS ITトランスフォーメーションパッケージ 公共版(以下、ITX for PS)についてご紹介します。( 最新版のITX資料ダウンロードはこちらから ) 公共領域におけるITXに対するお客様からのご要望 日本の社会において労働人口の減少や高齢化などが進行する中、デジタル技術の活用による省力化・効率化が不可欠となっています。政府はこうした課題に対応すべく、行政は勿論の事、医療・教育も含め、国民一人ひとりの暮らしを豊かにするデジタル社会の実現を目指すための政策を推進しており、クラウドの活用もそうした目的を達成するための一つの手段として検討が進められています。例えば中央省庁や地方自治体におけるクラウドの検討状況に目を向けると、クラウド・バイ・デフォルト原則のもとに、今後中央省庁において約1100の政府情報システムのクラウド移行の検討が行われ、また地方においても約1700団体が20の標準業務のクラウド移行を2025年度末までに行う方針です。 こうした状況の中、国においてはデジタル庁が「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」(以下基本方針)の中でクラウド利用のメリットを十分に享受するため、システム刷新に伴いマネージドサービスを活用したシステムのモダン化について言及するなど、スマートにクラウドを利用することを勧めています。 今後さらに公共の領域でもシステムのクラウドへの移行が行われていくことが考えられますが、クラウドのメリットを享受するために単純なクラウド移行ではなくシステムのモダン化の検討を効果的に行うことや、公共特有のNW構成といった基盤設計、各種ガイドラインへの準拠の必要性など、公共分野特有の要素に頭を悩ませるお客様の声も聞こえてきます。 今回、AWSへの大規模な移行を考える官公庁や医療、教育、NPOといった公共の分野のお客様向けに従来のITXの内容を拡張し、ITX for PSとしてリリースいたします。 ITX for PSとは? ITX for PSでは公共領域においても求められるシステムのモダン化や公共分野特有の要素への対応を中心に、従来のITXを拡張する形で、1. システムのモダン化支援 、2. 公共専門分野支援 、3.システムをモダン化する際に鍵となる データ・生成AIの活用支援 を提供すると共に、公共分野で見られる調達のプロセスを考慮したパッケージ構成にしています。 1.システムのモダン化を進めるための支援 AWSへの移行に伴いシステムのモダン化を進めるための支援としては大きく3つのカテゴリを用意しています。移行における初期の企画・検討フェーズにおけるアセスメント支援、アセスメント後に要件の定義や仕様を検討する際に机上調査にとどまらないプロトタイプの支援やモダン化の体験をしてもらうモダン化開発支援、そして運用に入ったシステムのクラウド利用を最適化することによるコスト最適化の支援です。 システムのモダン化を進めるためには、次期システム検討の早い段階でモダン化による費用対効果の検証や、実現性の検証を行うことが重要になると考えられます。そうした検証を支援するために、次期システムの企画・移行検討のフェーズでシステムのモダン化を検討するための各種アセスメントを提供します。 運用生産性の向上など単純な利用コスト比較にとどまらないクラウド移行によるTCO分析を行う「クラウドエコノミクス」、特定業務システムのTo Beアーキテクチャーを検討してモダン計画のインプットとする「モダナイゼーションアセスメント」、移行対象システムを俯瞰的に分析しシステム特性に応じたクラウド移行パターンを推奨する「アプリケーションポートフォリオアセスメント」、マネージドなデーターベース移行を行うために必要な検証を支援する「データベースフリーダム」、システム環境を第3者機関により評価し、サードパーティーライセンスを最適化する「ライセンス評価・最適化プログラム」といった モダン化アセスメント を用意しています。 また、こうしたアセスメントを行ったうえで要件定義や仕様検討のフェーズでは、前フェーズで検討されたアーキテクチャーをもとにしたプロトタイプをAWSが開発する「プロトタイピング支援」や、実際にシステムをモダン化するパイロットプロジェクトを体験し開発チームにノウハウと成功体験を得て頂くための「体験型ワークショップ」といった、 モダン化開発支援 も提供いたします。 そしてAWSに移行したシステムに関し、運用・保守のフェーズでは、よりスマートにクラウドを活用することでコストの最適化を図るための コスト最適化支援 を提供します。 2.公共専門の分野に関するクラウド活用支援 公共特有の要素に関するクラウド活用支援では、中央政府、自治体、教育機関、医療機関、研究機関など、公共のお客様の特有の専門知識、技術知識を持った技術チームがお客様の課題を解決支援します。また、公共のお客様の状況を踏まえたクラウド人材育成やクラウド推進組織の立ち上げに関する支援、公共調達のプロセスの中でAWSの提供するクレジット提供プログラムの活用支援といったものを提供します。 ITX for PSではシステムをクラウドに移行する際、公共分野での特有な要素に対する支援も用意しています。公共のお客様で見られる閉域網におけるネットワーク設計支援や、IaCが活用されるガバメントクラウドにおけるテンプレートの利用に対する支援、監督省庁等から出される各種ガイドラインに対応したクラウドの利用方法を検討するための支援など、 公共専門分野支援 を用意しています。 また、クラウドの活用において技術以外の要素で重要となる人材育成・組織の面に関しては、クラウドへの大規模移行に際し、組織的な準備ができているかを評価する「移行準備評価」、AWSに携わる要因のスキルギャップの特定とギャップ解消を支援する「スキルギャップ分析」、そうしたアセスメントの結果をもとに公共のお客様のクラウド推進組織(CCoE)の立ち上げ検討や人材育成の支援を行う 公共クラウド人材・組織育成支援 も提供いたします。 さらにAWSでは、移行時の経済的負担を軽減するMigration Acceleration Program(MAP)と呼ばれるAWSの利用料に対するクレジット提供プログラムを用意していますが、公共の調達プロセスの中でMAPを活用するタイミングを検討したり、分離調達の際にどのようなスキームにするとよいかといったご提案等、 公共調達におけるMAPの活用支援 も提供しております。 3.データ・生成AIの活用支援 モダン化を含むシステムの刷新に際しては、業務改革(ビジネスプロセスリエンジニアリング、BPR)も併せて行うことがデジタル庁の基本方針の中でも推奨されています。業務改革を検討する際、システムの観点からはデータドリブンの意思決定に寄与するデータ基盤や、そのデータを用いた生成AIの活用が求められることも考えられます。 そうした状況にお応えするためにAWSの専門チームがお客様の現行データ基盤を分析し、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示する「データ基盤モダン化支援」、公共分野における生成AIの代表的なユースケースの実装支援テンプレートによる「生成AI活用検討支援」といった データ・生成AIの活用支援 を用意いたします。 ここに挙げたような支援プログラムを公共調達のサイクルの中で活用頂く事で、官公庁や医療、教育、NPOといった公共の分野のお客様は、クラウド移行を検討するための最適なプロセスを効果的に進めることができるようになります。 ITX for PSのリリースに際したお客様やパートナー様の声 デジタル庁 Chief Cloud Officer 山本教仁様 デジタル庁では、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の中でスマートなクラウドの利用を掲げており、マネージドサービスやIaC (Infrastructure as Code)を活用した自動化によるコスト削減等を説明しています。これら施策はガバメントクラウドの技術要件にも含まれ、採用したクラウドサービスプロバイダーにもその推進をご協力いただいています。 その中で、AWSからは、スマートなクラウド利用を支援する内容をわかりやすく1つのパッケージメニュー「ITX for PS」としてまとめていただき、提供いただきます。これを活用することで、スマートなクラウドの利用が促進され、クラウドに関するスキル育成、システム開発の短期間化や継続的な開発・改善の実現、そして、コスト削減とセキュリティの向上につながると考えてます。 日本政府のクラウド・バイ・デフォルト原則に基づいた、中央官庁および地方公共団体におけるクラウド移行の取り組みに対して、このような支援パッケージが用意されることを歓迎します。 PwCコンサルティング合同会社 執行役員 パートナー デジタルガバメント統括 林泰弘様 AWSは、デジタル庁が発足した2021年から、ガバメントクラウドやガバメントソリューションサービスの導入、自治体基盤システムの標準化および共通化を進めてこられました。これらを通じて蓄積されてきた知見、ノウハウが集約された「ITX for PS」は、中央省庁や自治体のデジタルシフトを加速するものと期待しています。PwCコンサルティングは「AWSコンサルティングパートナー」に認定されており、多くのクライアントに「ITトランスフォーメーションパッケージ」の導入を支援してきました。引き続き、AWSとともに、日本全体のデジタルシフトの推進に取り組んでいきたいと考えております。 ITX for PSの始め方 ITX for PSのご利用に向けて、入り口は2つあります。 1) Webフォーム からお問い合わせ頂く。あるいは 2)担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITX for PSにご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 パブリックセクター統括本部 マイグレーション アドバイザー 今井 宏樹 パブリックセクター技術統括本部 CSM・パートナーソリューション本部 本部長 高田 智己 執行役員 パブリックセクター技術統括本部長 瀧澤 与一
本記事は 2024年2月2日に公開された ” Monitor embedding drift for LLMs deployed from Amazon SageMaker JumpStart ” を翻訳したものです。 生成 AI のワークロードで最も有用なアプリケーションパターンの 1 つが Retrieval Augmented Generation (RAG) パターンです。 RAG パターンでは、入力プロンプトに関連する参照コンテンツを探すために、埋め込みベクトル (テキスト文字列の数値表現) に対して類似検索を実行します。埋め込みはテキストの情報内容を捉え、自然言語処理 (NLP) モデルが言語を数値的に処理できるようにします。埋め込みは浮動小数点ベクトルであるため、3 つの重要な質問を用いて分析することができます。参照データは時間とともに変化するか、ユーザーが尋ねる質問は時間とともに変化するか、そして最後に、参照データが尋ねられている質問をどの程度カバーできているかです。 この記事では、埋め込みベクトル分析とドリフト検出の注意点について学びます。埋め込みは一般的な自然言語処理モデルと特に生成 AI ソリューションにおいて重要な入力データとなるため、時間の経過とともに埋め込みが変化 (ドリフト) するかどうかを測定する方法が必要です。このポストでは、 Amazon SageMaker JumpStart からデプロイされた大規模言語モデル (LLM) を用いてクラスタリング手法によりベクトル埋め込みのドリフトを検出する例を示します。また、後述するエンドツーエンドのサンプルアプリケーションを使用するか、あるいはその一部のみを使用して、これらの概念を実際に体験することができます。 RAG の概要 RAG パターン では、PDF ドキュメント、Wiki 記事、通話の書き起こしなどの外部ソースから知識を検索し、その知識を使って LLM に送られる指示のプロンプトを補強できます。これにより、LLM は応答を生成するときに、より関連性の高い情報を参照できます。例えば、LLM にチョコチップクッキーの作り方を尋ねた場合、自分のレシピライブラリから情報を含めることができます。このパターンでは、レシピのテキストが埋め込みモデルを使って埋め込みベクトルに変換され、ベクトルデータベースに保存されます。入力された質問も埋め込みベクトルに変換され、入力された質問と、類似検索で見つかった参照データが、LLM へのプロンプトに含められます。 埋め込みベクトルが生成される仕組みとそのベクトルについてドリフト分析を実行する方法について、詳しく確認していきましょう。 埋め込みベクトルの分析 埋め込みベクトルは、データの数値表現であり、これらのベクトルを分析することで、参照データの洞察が得られます。この洞察は、後にドリフトの兆候を検出するのに利用できます。埋め込みベクトルは、n 次元空間内の項目を表し、n は大きな値になることが多いです。例えば、この記事で使用されている GPT-J 6B モデルは、4096 次元のベクトルを生成します。ドリフトを測定するために、アプリケーションが参照データと入力プロンプトの両方の埋め込みベクトルをキャプチャすると仮定します。 まず主成分分析 (PCA) を使って次元削減を行います。PCA はデータの変動の大部分を残しつつ次元数を減らそうとします。この場合、分散の 95 % を保持する次元数を見つけることで、2 標準偏差の範囲内にあるものがすべて取り込まれるはずです。 次に、K-Means 法を用いてクラスタ中心の集合を同定します。K-Means 法は、各クラスタが密集している、またはまとまりが高くなるようにデータポイントをグループ化し、クラスタ間の距離が可能な限り遠くなるように試みます。 次の図に示されるクラスタリング出力に基づいて、以下の情報を計算します。 95 % の分散を説明する PCA の次元数 各クラスター中心点 (重心) の位置 さらに、次の図に示すように、各クラスタでサンプルの割合が高いか低いかを確認します。 最後に、この分析を使って以下の値を計算します。 慣性 (inertia) &nbsp;– 慣性は、クラスタ中心への 2 乗距離の和で、K-Means でデータがどの程度うまくクラスタリングされたかを測るものです。 シルエットスコア (silhouette score) &nbsp;– シルエットスコアは、クラスタ内の一貫性を検証する尺度で、-1 から 1 の範囲の値をとります。1 に近い値は、クラスタ内のデータポイントが同じクラスタの他のポイントに近く、別のクラスタのポイントから離れていることを意味します。クラスタ内外の集まり具合の指標の視覚的な表現が次の図に示されています。 これらの情報を定期的にキャプチャすれば、参照データとプロンプトの埋め込みスナップショットを得ることができます。この情報をから埋め込みのドリフトの兆候を分析できます。 埋め込みドリフトの検出 参照データの埋め込みとプロンプトの埋め込みを含むデータのスナップショットを通して、定期的に、クラスタリング情報を比較できます。まず、分散の 95 % を説明するのに必要な次元数、慣性、クラスタリングジョブのシルエットスコアを比較できます。次の表に示すように、ベースラインと比較して、最新の埋め込みのスナップショットでは分散を説明するのに 39 次元多くの次元が必要となり、データがより分散していることを示しています。慣性も上がっており、サンプルがクラスタ中心からより離れた位置にあることを示しています。さらに、シルエットスコアが下がっているため、クラスタが明確に定義されていないことを意味しています。プロンプトデータの場合、これはシステムに入ってくる質問の種類がより多くのトピックに及ぶためかもしれません。 次に、次の図では、各クラスターのサンプル割合がどのように経時的に変化したかを確認できます。これにより、新しい参照データが以前のデータとほぼ同様なのか、新しい領域をカバーしているのかがわかります。 最後に、クラスター中心が移動しているかを見ることで、クラスター内の情報がドリフトしているかを確認できます。次の表で示されています。 質問の対象となる参照データの範囲 参照データと受け付けた質問がどの程度整合しているかを評価することもできます。これを行うには、各プロンプトの埋め込みベクトルを参照データのクラスタに割り当てます。次に、各プロンプトからそのクラスタの中心までの距離を計算し、その平均、中央値、標準偏差を求めます。この情報を保存し、時間の経過に伴ってどのように変化するかを確認できます。 次の図は、プロンプトの埋め込みと参照データの中心間の距離を時間の経過とともに分析した例を示しています。 ご覧のとおり、プロンプトの埋め込みと参照データの中心の平均距離、中央値距離、標準偏差距離の統計は、最初のベースラインから最新のスナップショットにかけて減少しています。距離値そのものの意味を解釈するのは難しいものの、トレンドを使って参照データと質問の間の内容の類似性が時間とともに良くなっているのか悪くなっているのかを判断できます。 サンプルアプリケーション 前のセクションで説明した実験結果を収集するために、SageMaker JumpStart からデプロイされた RAG パターンに使われるモデルを使用して、RAG パターンを実装するサンプルアプリケーションを構築しました。 このモデルは、 Amazon SageMaker のリアルタイムエンドポイントでホストされています。 アプリケーションには以下の 3 つのコアコンポーネントがあります。 プロンプトをキャプチャするユーザーインターフェイスと、LangChain を使った RAG オーケストレーション層を含む対話型フローを使用しています。 データ処理フローは、PDF ドキュメントからデータを抽出し、 Amazon OpenSearch Service に保存される埋め込みを作成します。また、これらをアプリケーションの最終的な埋め込み偏差分析コンポーネントでも使用しています。 埋め込みは Amazon Kinesis Data Firehose 経由で Amazon Simple Storage Service (Amazon S3) でキャプチャされ、 AWS Glue の抽出、変換、ロード (ETL) ジョブと Jupyter ノートブックの組み合わせを実行して、埋め込み分析を行います。 次の図は、エンドツーエンドのアーキテクチャを示しています。 完全なサンプルコードは GitHub で公開されています。 提供されているコードは 2 つの異なるパターンで用意されています。 Streamlit フロントエンドを持つフルスタックのサンプルアプリケーション – Amazon Elastic Container Service (Amazon ECS) と AWS Fargate で実行される LangChain を使った RAG の連携層と Streamlit を使ったユーザーインターフェースを持つ、エンドツーエンドのアプリケーションを提供します。 バックエンドアプリケーション – フルアプリケーションスタックをデプロイしたくない場合は、 AWS Cloud Development Kit (AWS CDK) スタックのバックエンドのみをデプロイし、提供された Jupyter ノートブックを使って LangChain を使った Retrieval Augmented Generation (RAG) の連携を実行することができます。 提供されたパターンを作成するには、以下のセクションで説明されている複数の前提条件があり、まず生成モデルとテキストエンベディングモデルをデプロイした後、追加の前提条件に移ります。 SageMaker JumpStart によるモデルのデプロイ 両方のパターンでは、埋め込みモデルと生成モデルをデプロイすることを前提としています。このために、SageMaker JumpStart から 2 つのモデルをデプロイします。最初のモデル GPT-J 6B は埋め込み モデルとして使用し、2 つ目の Falcon-40b はテキスト生成に使用します。 これらのモデルは、 AWS マネジメントコンソール 、 Amazon SageMaker Studio 、またはプログラムによって SageMaker JumpStart からデプロイできます。詳細については、 JumpStart 基盤モデルの使用方法 を参照してください。デプロイを簡素化するために、SageMaker JumpStart によって自動的に作成されたノートブックから派生した 提供されているノートブック を使うことができます。このノートブックは、SageMaker JumpStart の ML ハブからモデルを取得し、2 つの別々の SageMaker リアルタイムエンドポイントとしてデプロイします。 サンプルノートブックには、クリーンアップ用のセクションもありますが、そのセクションは実行しないでください。実行すると今デプロイしたばかりのエンドポイントが削除されます。このハンズオンチュートリアルの最後に、クリーンアップを完了させます。 エンドポイントのデプロイが正常に完了したことを確認したら、サンプルアプリケーション全体をデプロイする準備が整います。ただし、バックエンドと分析用のノートブックのみを探索したい場合は、次のセクションで説明するように、そちらだけをデプロイすることもできます。 オプション 1: バックエンドアプリケーションのみのデプロイ このパターンでは、バックエンド ソリューションのみを展開し、Jupyter ノートブックを使ってソリューションと対話できます。UI の部分を構築したくない場合に、このパターンを使用します。 前提条件 次の前提条件を満たしている必要があります。 SageMaker JumpStart を使ってモデルエンドポイントのデプロイ – 上記で説明したように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントをデプロイします。 デプロイ時のパラメーター設定 – 次の情報を設定します。 テキストモデルエンドポイント名 – SageMaker JumpStart で展開したテキスト生成モデルのエンドポイント名 埋め込みモデルエンドポイント名 – SageMaker JumpStart で展開した埋め込みモデルのエンドポイント名 AWS CDK を使用したリソースのデプロイ 前のセクションで示したデプロイパラメータを使用して、AWS CDK スタックをデプロイしてください。AWS CDK のインストールについて詳しくは、 AWS CDK の概要 を参照してください。 AWS CDK のデプロイに使用するワークステーションで Docker がインストールされ、実行されていることを確認してください。詳しくは Get Docker を参照してください。 $ cd pattern1-rag/cdk $ cdk deploy BackendStack --exclusively -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; または、&nbsp; pattern1-rag/cdk ディレクトリの cdk.context.json というファイルにコンテキスト値を入力し、 cdk deploy BackendStack --exclusively を実行することもできます。 デプロイ時に、ノートブックを実行するために必要な情報が出力されます。次のセクションに示されているように、質問と回答をする前に参照ドキュメントの埋め込みを行う必要があります。 参照ドキュメントの埋め込み この RAG アプローチでは、まず参照ドキュメントをテキストエンベディングモデルで埋め込み、ベクトルデータベースに格納します。 このソリューションでは、PDF ドキュメントを取り込むパイプラインが構築されています。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが作成され、そのインスタンスに Amazon Elastic File System (Amazon EFS) のファイルシステムがマウントされ、PDF ドキュメントを保存するための環境が構築されています。 AWS DataSync タスクが 1 時間ごとに実行され、EFS ファイルシステムパスで見つかった PDF ドキュメントを取得し、テキスト埋め込み処理用の S3 バケットにアップロードします。このプロセスは参照ドキュメントを埋め込み、その埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を通じて埋め込みアーカイブを S3 バケットに保存します。 参照ドキュメントを取り込むには、次の手順を実行します。 作成したサンプルの EC2 インスタンス ID (AWS CDK の出力から JumpHostId の値を参照) を取得し、 AWS Systems Manager の機能である Session Manager を使用して接続してください。手順については、 AWS Systems Manager Session Manager を使用して Linux インスタンスに接続する を参照してください。 EFS ファイルシステムがマウントされているディレクトリ /mnt/efs/fs1 に移って、まず mkdir ingest を実行して ingest というフォルダを作成します。次に cd ingest を実行して作成したフォルダに移動します。 $ cd /mnt/efs/fs1 $ mkdir ingest &amp; cd ingest ingest ディレクトリに参照する PDF ドキュメントを追加します。 DataSync タスクは、この埋め込みプロセスを開始するために、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするように設定されています。 DataSync タスクは 1 時間おきにスケジュールされて実行されます。オプションで、タスクを手動で開始して、追加した PDF ドキュメントの埋め込みプロセスを即座に開始することもできます。 タスクを開始するには、AWS CDK の出力から DataSyncTaskID のタスク ID を特定し、 デフォルト設定でタスクを開始 してください。 埋め込み作成後は、次のセクションで示すように Jupyter ノートブックから RAG の質問に答えることができます。 Jupyter Notebook を使った質問と回答 次の手順を完了してください。 AWS CDK の出力 NotebookInstanceName から SageMaker ノートブックインスタンス名を取得し、SageMaker コンソールから Jupyter Lab に接続します。 ディレクトリ fmops/full-stack/pattern1-rag/notebooks/ に移動します。 ノートブックインスタンス内でノートブック query-llm.ipynb を開き、実行して RAG を使って質問と回答を行います。 ノートブックでは conda_python3 カーネルを使用するようにしてください。 このパターンは、フルスタックアプリケーションに必要な追加の前提条件をプロビジョニングする必要なく、バックエンドのソリューションを検討するのに役立ちます。次のセクションでは、生成 AI アプリケーションとの対話用のユーザー インターフェイスを提供するため、フロントエンド部分も含めたフルスタック アプリケーションの実装について説明します。 オプション 2: Streamlit フロントエンドのフルスタックサンプルアプリケーションのデプロイ この手法により、質問と応答のユーザーフロントエンドインターフェイスを備えたソリューションをデプロイできます。 前提条件 サンプルアプリケーションをデプロイするには、次の前提条件を満たす必要があります。 SageMaker JumpStart を使ってモデルエンドポイントのデプロイ &nbsp;– 提供されたノートブックを使用して、前のセクションで説明されているように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントにデプロイします。 Amazon Route 53 ホストゾーン – このソリューションで使用するために、 Amazon Route 53 の パブリックホストゾーン を作成します。または、 example.com のように既存の Route 53 パブリックホストゾーンを使用することもできます。 AWS Certificate Manager 証明書 – Route 53 ホストゾーンドメイン名および適用対象のサブドメイン ( example.com および *.example.com など) 用に、 AWS Certificate Manager (ACM) の TLS 証明書をプロビジョニングします。手順については、 パブリック証明書のリクエスト を参照してください。この証明書は、 Amazon CloudFront およびロードバランサーのオリジンにおける HTTPS を構成するために使用されます。 デプロイ時のパラメーター設定 &nbsp;– 次の情報を設定します。 フロントエンドアプリケーションのカスタムドメイン名 – フロントエンドのサンプルアプリケーションにアクセスするためのカスタムドメイン名です。指定されたドメイン名は、フロントエンド CloudFront ディストリビューションを参照する Route 53 DNS レコードの作成に使用されます。たとえば、 app.example.com です。 ロードバランサーのオリジンとなるカスタムドメイン名 – CloudFront ディストリビューションのロードバランサーオリジン用のカスタムドメイン名です。指定されたドメイン名は、オリジンロードバランサーを参照する Route 53 DNS レコードの作成に使用されます。たとえば、 app-lb.example.com です。 Route 53 ホストゾーン ID – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン ID です。たとえば、 ZXXXXXXXXYYYYYYYYY です。 Route 53 ホストゾーン名 – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン名です。たとえば、 example.com です。 ACM 証明書 ARN – 指定されたカスタムドメイン名で使用される ACM 証明書の ARN です。 テキストモデルエンドポイント名 – SageMaker JumpStart でデプロイされたテキスト生成モデルのエンドポイント名です。 埋め込みモデルエンドポイント名 – SageMaker JumpStart でデプロイされた埋め込みモデルのエンドポイント名です。 AWS CDK を使用したリソースのデプロイ 前提条件でメモした展開パラメータを使用して、AWS CDK スタックをデプロイしてください。詳細については、 AWS CDK の使用開始 を参照してください。 Docker が AWS CDK のデプロイに使用されるワークステーションにインストールされており、実行中であることを確認してください。 $ cd pattern1-rag/cdk $ cdk deploy --all -c appCustomDomainName=&lt;Enter Custom Domain Name to be used for Frontend App&gt; \ -c loadBalancerOriginCustomDomainName=&lt;Enter Custom Domain Name to be used for Load Balancer Origin&gt; \ -c customDomainRoute53HostedZoneID=&lt;Enter Route53 Hosted Zone ID for the Custom Domain being used&gt; \ -c customDomainRoute53HostedZoneName=&lt;Enter Route53 Hostedzone Name&gt; \ -c customDomainCertificateArn=&lt;Enter ACM Certificate ARN for Custom Domains provided&gt; \ -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; 上の例のコードでは、-c は入力時に指定するコンテキスト情報を表しています。もしくは、 pattern1-rag/cdk ディレクトリにある cdk.context.json ファイルにコンテキスト情報を記述し、 cdk deploy --all を実行することもできます。 bin/cdk.ts ファイルでリージョンを指定していることに注意してください。ALB アクセスログを設定するには、リージョンを指定する必要があります。デプロイする前に、このリージョンを変更することができます。 デプロイ時に、Streamlit アプリケーションにアクセスする URL が出力されます。次のセクションで説明するように、質問に対して回答できるようにする前に、参照ドキュメントを組み込む必要があります。 参照ドキュメントの埋め込み RAG アプローチでは、まず PDF ドキュメントをテキスト埋め込みモデルで処理を行い、ベクトルデータベースに保存します。このソリューションでは、PDF ドキュメントを取り込むためのパイプラインが構築されています。 初回デプロイオプションで説明したように、PDF ドキュメントの取り込み用に EC2 インスタンスが作成され、PDF ドキュメントを保存するために EFS ファイルシステムが EC2 インスタンスにマウントされています。1 時間ごとに DataSync タスクが実行され、EFS ファイルシステムパス内の PDF ドキュメントを取得して、テキスト埋め込みプロセスを開始するために S3 バケットにアップロードされます。このプロセスは参照ドキュメントに埋め込みを行い、埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を介して埋め込みデータのアーカイブを S3 バケットに保存します。 参照ドキュメントを取り込むには、次の手順を実行してください。 作成された EC2 インスタンスのサンプル ID を取得 (AWS CDK の出力 JumpHostId を参照) し、Session Manager を使って接続します。 EFS ファイルシステムがマウントされている /mnt/efs/fs1 ディレクトリに移動し、 ingest というフォルダを作成します。 $ cd /mnt/efs/fs1 $ mkdir ingest &amp;&amp; cd ingest ingest ディレクトリに、参照する PDF ドキュメントを追加します。 DataSync タスクは、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするよう設定されており、これによって埋め込み処理が開始されます。 DataSync タスクは 1 時間ごとに実行されます。追加した PDF ドキュメントの埋め込み処理を即座に開始したい場合は、手動でタスクを開始することもできます。 4. タスクを開始するには、AWS CDK 出力の DataSyncTaskID からタスク ID を特定し、 デフォルトでタスクを開始 します。 質問と回答 参照ドキュメントが埋め込まれた後、Streamlit アプリケーションにアクセスする URL にアクセスすることで、RAG の質問と回答をスタートできます。 Amazon Cognito 認証レイヤーが使用されているため、アプリケーションにはじめてアクセスする際は AWS CDK によってデプロイされた Amazon Cognito ユーザープール (ユーザープール名は AWS CDK の出力を参照) でユーザーアカウントを作成する必要があります。Amazon Cognito ユーザーを作成するための手順については、 AWS マネジメントコンソールで新規ユーザーを作成する を参照してください。 埋め込みドリフトの分析 このセクションでは、参照スデータ埋め込みとプロンプト埋め込みのベースラインを最初に作成してから、時間の経過とともにその埋め込みのスナップショットを作成することで、ドリフト分析を実行する方法を説明します。これにより、ベースラインの埋め込みとスナップショットの埋め込みを比較できます。 参照データとプロンプトの基準となる埋め込みベクトルの作成 参照データの埋め込み表現のベースラインを作成するには、AWS Glue コンソールを開き、ETL ジョブ embedding-drift-analysis を選択します。次のように ETL ジョブのパラメーターを設定し、ジョブを実行してください。 --job_type を BASELINE に設定します。 --out_table を参照埋め込みデータ用の Amazon DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力の DriftTableReference を参照してください。) --centroid_table を参照の重心データ用の DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力の CentroidTableReference を参照してください。) --data_path を S3 バケットとプレフィックスに設定します。例: s3:// &lt;バケット名で置換&gt; /embeddingarchive/ (バケット名は AWS CDK 出力の BucketName を参照してください。) 同様に、ETL ジョブ embedding-drift-analysis を使用して、プロンプト文章のベースラインの特徴ベクトルを作成します。ETL ジョブのパラメータを次のように設定してジョブを実行します。 --job_type を BASELINE に設定する --out_table をプロンプト文データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力 DriftTablePromptsName を参照) --centroid_table をプロンプト分類データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力 CentroidTablePrompts を参照) --data_path を S3 バケットのプレフィックスに設定する 例: s3:// &lt;バケット名で置換&gt; /promptarchive/ (バケット名は AWS CDK の出力 BucketName を参照) 参照データとプロンプトの埋め込みスナップショットの作成 OpenSearch Service に追加情報を取り込んだ後、ETL ジョブ embedding-drift-analysis を再実行して、参照データのベクトルのスナップショットを作成します。前のセクションで示したように、参照データのベクトルを作成するために実行した ETL ジョブと同じパラメータを使用しますが、 --job_type パラメータを SNAPSHOT に設定する点が異なります。 同様に、プロンプトの埋め込みスナップショットを取得するには、ETL ジョブ embedding-drift-analysis を再実行します。前のセクションで示したプロンプトの埋め込みベースラインを作成するために実行した ETL ジョブと同じパラメータを使用しますが、 --job_type パラメータを SNAPSHOT に設定することを除きます。 ベースラインとスナップショットの比較 参照データとプロンプトについて、埋め込みベースラインとスナップショットを比較するには、提供されたノートブック pattern1-rag/notebooks/drift-analysis.ipynb を使用します。 参照データやプロンプトの埋め込みベクトルの比較を行うには、各ノートブックの実行ごとに、ノートブックの DynamoDB テーブル名の変数 ( tbl と c_tbl ) を、適切な DynamoDB テーブルに変更してください。 ノートブックの変数 tbl は、適切なドリフトテーブル名に変更する必要があります。ノートブックでこの変数を設定する場所の例を以下に示します。 テーブル名は以下のように取得できます。 参照埋め込みデータについては、AWS CDK の出力 DriftTableReference からドリフトテーブルの名前を取得します プロンプト埋め込みデータについては、AWS CDK の出力 DriftTablePromptsName からドリフトテーブルの名前を取得します また、ノートブックの変数 c_tbl は適切な重心テーブル名に変更する必要があります。ノートブック内でこの変数を構成する場所の例を以下に示します。 以下のようにしてテーブル名を取得できます。 参照埋め込みデータとは、参照するデータセットを埋め込んだデータのことです。AWS CDK の出力 CentroidTableReference から、参照データセットが格納されたテーブル名を取得します。 プロンプト埋め込みデータとは、質問文(プロンプト)を埋め込んだデータのことです。AWS CDK の出力 CentroidTablePrompts から、プロンプトが埋め込まれたデータが格納されたテーブル名を取得します。 プロンプト文と参照データの類似度分析 まず、AWS Glue ジョブ embedding-distance-analysis を実行します。このジョブは、参照データの埋め込みに対する K-Means 評価からどのクラスターに各プロンプトが属するかを見つけます。次に、各プロンプトが対応するクラスター中心までの距離の平均値、中央値、標準偏差を計算します。 pattern1-rag/notebooks/distance-analysis.ipynb ノートブックを実行すると、時間の経過に伴う距離メトリクスのトレンドを確認できます。これにより、プロンプト埋め込みベクトルの距離分布の全体的なトレンドを把握できます。 ノートブック pattern1-rag/notebooks/prompt-distance-outliers.ipynb では、外れ値を検出する AWS Glue ノートブックです。これは参照データとは無関係のプロンプトが増えていないか特定するのに役立ちます。 類似スコアのモニタリング OpenSearch Service から得られるすべての類似スコアは、 rag 名前空間の下にある Amazon CloudWatch にログ記録されます。 RAG_Scores ダッシュボードは、平均スコアおよび取り込まれたスコアの合計数を表示します。 クリーンアップ 必要以上の料金が発生しないように、作成したすべてのリソースを削除します。 デプロイした SageMaker モデルの削除 デプロイされた SageMaker JumpStart (Amazon の機械学習モデルを素早く構築・デプロイできるサービス) のモデルを削除したい場合は、 提供されている例のノートブック のクリーンアップセクションを参照するか、 Amazon SageMaker (AWS の機械学習サービス) のコンソール上でモデルを削除 することができます。 AWS CDK リソースの削除 cdk.context.json ファイルにパラメータを入力した場合は、次のように内容を消去してください。 $ cd pattern1-rag/cdk $ cdk destroy --all コマンド ライン上でパラメータを入力し、バックエンド アプリケーション (バックエンド AWS CDK スタック) のみをデプロイした場合、次のように削除してください。 $ cd pattern1-rag/cdk $ cdk destroy --all -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; コマンドラインでパラメータを入力し、フロントエンドとバックエンド AWS CDK スタック全体をデプロイした場合は、次のように削除します。 $ cd pattern1-rag/cdk $ cdk destroy --all -c appCustomDomainName=&lt;Enter Custom Domain Name to be used for Frontend App&gt; \ -c loadBalancerOriginCustomDomainName=&lt;Enter Custom Domain Name to be used for Load Balancer Origin&gt; \ -c customDomainRoute53HostedZoneID=&lt;Enter Route53 Hosted Zone ID for the Custom Domain being used&gt; \ -c customDomainRoute53HostedZoneName=&lt;Enter Route53 Hostedzone Name&gt; \ -c customDomainCertificateArn=&lt;Enter ACM Certificate ARN for Custom Domains provided&gt; \ -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; まとめ この記事では、生成 AI の RAG パターンにおける参照データとプロンプトの両方でベクトル埋め込みを取得するアプリケーションの実例を示しました。参照データやプロンプトでドリフトが発生しているかどうかを判断するためのクラスタリング分析の実行方法と、参照データがユーザーの質問の種類をどの程度カバーしているかを示しました。ドリフトを検出できれば、環境が変化し、モデルが最適化されていない新しい入力を受け取っていることを示す兆候となります。これにより、変化する入力に対する現在のモデルの積極的な評価が可能になります。
はじめに 全米消防協会は、毎年 100 万件を超える火災を記録しています。これらの火災は、米国における都市の安全を脅かす最大の危険のひとつと位置づけられています。現在、消防署は主に在宅用の煙探知機、火災通報ボックス、および電話による通報といった従来の火災検知システムによる警報に頼っています。しかしこれらのシステムでは、火災の範囲、規模、場所などの追加情報が不足する可能性があります。モノのインターネット (IoT) は、都市のインフラを合理化し、火災を事前に検知し、公共の安全性を向上させるための重要な技術です。 火災関連の事故を減らし、迅速かつ効果的に火災に対応するため、IoT センサーと高度なデータ分析 (機械学習など) を統合することができます。環境条件と煙レベルを監視する IoT デバイスは、ほぼリアルタイムでデータをクラウドに送信でき、そこでさらに処理が行われ、潜在的な火災の危険性が特定されます。そうすることにより、事態が悪化する前に実用的な対策を講じることができます。 このブログ記事では、早期警告システムを緊急時対応者に構築するためのデータを接続、収集、活用するにあたり、AWS のサービス群をどのように使用するかを学びます。全体のシステムアーキテクチャについて説明し、データを収集するセンサーやデバイス、AWS IoT サービスを使ったデータ処理と分析、 Amazon SageMaker を使ったローコードな ML モデルによる火災予測についても見ていきます。 全体アーキテクチャ このソリューションでは、 AWS IoT Core &nbsp;を使用して、温度、気圧、ガス、湿度、風速、土壌湿度などさまざまなセンサーからデータを大規模にクラウドに安全に取り込みます。使用する IoT デバイスのタイプに応じて、 AWS IoT SDK &nbsp;は、AWS IoT Core とデバイスを安全に接続し、認証するために必要なライブラリと API を提供します。 ただし、一部のデバイスは Wi-Fi やセルラーネットワークが途切れ途切れになるところに配置される可能性があります。そのような場合、 AWS IoT Core for Amazon Sidewalk &nbsp;(注記:2024/06時点で日本国内ではサービス未提供)が優位性を発揮します。 Amazon Sidewalk は、互換性のある Amazon Echo や Ring デバイスなどの Amazon Sidewalk Gateway を使用し、IoT エンドポイントデバイスにクラウド接続を提供するセキュアなコミュニティネットワークです。Amazon Sidewalk は、Bluetooth Low Energy を使った近距離通信と、900MHz の周波数で LoRa および FSK 無線プロトコルを使った長距離通信により、家の中や外でも低帯域幅の長距離接続を実現します。IoT デバイスは、Sidewalk Gateway を介して AWS IoT Core と安全に対話でき、データの発行やコントロールメッセージの受信ができます。この統合により、IoT デバイスの全体的な接続性と機能性が強化されます。Amazon Sidewalk は、接続性のギャップを埋めることで、スマートシティの実装において AWS IoT Core の範囲を広げ、遠隔の地域でも本当に市内全域をカバーするネットワークを可能にします。この通信範囲の拡大により、IoT とエッジコンピューティングがスマートシティのインフラ内でより効果的で信頼性の高いものになります。 AWS IoT Rules Engine &nbsp;は、ストリーミングデータを分析および処理し、AWS IoT Core に到着するメッセージを下流の AWS サービスにルーティングできるようにします。受信データに基づいて条件を指定するルールを作成できます。IoT デバイスからのメッセージがルールの条件に一致すると、ルールエンジンがアクションをトリガーします。このソリューションでは、このアクションによってメッセージが&nbsp; Amazon Simple Notification Service (Amazon SNS) に転送され、指定された通信チャンネルで対応チームに通知されます。 受信データは Amazon Timestream にもルーティングされ、ニアリアルタイムの監視のために保存されます。Amazon Timestream は高速、スケーラブル、完全マネージド型の時系列データベースで、時系列データの保存と分析を簡単に行えます。Timestream の目的別クエリエンジンを使えば、データの場所を指定することなく、最新のデータと過去のデータにアクセスして分析できます。AWS IoT で定義されたルールにより、着信メッセージからのデータが Timestream に直接投入され、AWS IoT Core が SQL リファレンスを使って結果のアクションを解析します。 Amazon Managed Grafana &nbsp;を使用して、何百万ものリアルタイムイベントを監視および分析する動的なダッシュボードを通じて、即座にインサイトを得ることができます。Amazon Managed Grafana は、 Amazon Timestream と統合されたフルマネージドで、安全なデータ可視化サービスです。Amazon Managed Grafana を使用すると、複数のソースからの遠隔測定データを即座に照会、相関、可視化できます。Amazon&nbsp;Timestream と&nbsp;Amazon Managed Grafana&nbsp;を使用すると、ダッシュボードからほぼリアルタイムのインサイトを導き出す運用ダッシュボードを構築し、何百万ものイベントを分析して監視し、警告することができます。これらのダッシュボードは、ステークホルダーや対応チームに、センサーのメトリクスや異常検知に関する即時の可視性を提供します。また、スマートシティ内の火災につながる潜在的な脅威の早期発見にも役立ちます。 長期的な分析と履歴参照のために、すべての生のセンサーデータは Amazon Simple Storage Service (Amazon S3) のデータレイクに配信されます。これは、ストリーミングデータをキャプチャ、変換、ロードする Amazon Data Firehose に渡されます。Amazon S3 に過去データを保存することは、このシステムの機能を高める上で重要な役割を果たします。これがマシンラーニングモデル開発の基盤となり、 Amazon SageMaker によって支援されます。SageMaker を利用すれば、この過去のデータセットを使って効率的にマシンラーニングモデルをトレーニングできます。過去データからのインサイトで強化されたこれらのモデルには、火災リスクを含む環境条件を正確に予測する能力があります。 Amazon Athena を使えば、これらのインサイトを直感的に分析・可視化でき、データ主導の意思決定が容易になります。Athena はサーバーレスかつインタラクティブなクエリサービスで、Amazon S3 に保存されたデータを分析し、結果を Amazon QuickSight で可視化できます。Amazon QuickSight はこの高度なデータを活用し、インタラクティブで分かりやすいダッシュボードを生成します。 ニアリアルタイムの監視、予測分析、高度な可視化を組み合わせることで、変化する環境条件に対して積極的に対応できます。この積極的な対応により、潜在的な脅威の迅速な検知と、タイムリーな緊急対応が可能になります。 他のユースケース 上記のアーキテクチャは、スマートシティにおける火災に関するセンサーデータを収集、分析、表示するための柔軟な基盤として機能します。このアーキテクチャは、山火事のような環境問題への対処にも応用できます。山火事は、人里離れた森林から発生し、郊外や都市部まで到達することが多くあります。森林地帯、公園、緑地帯、都市と山林の境界などで IoT センサーを使用することで、都市は火災を早期に発見し、封じ込めることができます。 このアーキテクチャは火災検知以外にも応用できます。交通、廃棄物管理、エネルギー使用、洪水リスク、大気の質を監視することで、スマートシティの運営を最適化することができます。このアーキテクチャの核となる機能は、センサーデータを市当局、緊急対応者、市民にとって有用な情報に変換し、都市をより安全で住みやすく、持続可能なものにすることにあります。 まとめ このブログでは、スマートシティ向けのスケーラブルな早期火災検知システムを設計するためのリファレンスアーキテクチャについて説明しました。AWS IoT を活用することで、このソリューションは市内の数千ものセンサーからのデータ取り込みと、ほぼリアルタイムの検知および警報をサポートします。このようなデータ取り込みにより、迅速な対応、事前の被害軽減、最適なリソース配分が可能になります。このアーキテクチャの汎用性により、交通管理、大気汚染監視、洪水予測などの他のIoTユースケースにも適用できます。最先端のテクノロジーと賢明な都市設計を組み合わせることで、都市は市民にとってより強靭で安全なものになる大きな一歩を踏み出せるでしょう。 この記事は Ahmed Alkhazraji, Ankur Dang, Marouane Hail&nbsp;によって書かれた Early Fire Detection Design Model for Smart Cities: Using AWS IoT and ML Technologies の日本語訳です。翻訳は、プロフェッショナルサービス本部 IoT コンサルタントの 宮本 篤 が担当しました。 著者について Ahmed Alkhazraji は、AWS で AI/ML および汎用 AI に注力するシニアソリューションアーキテクトです。革新的なソリューションを構築することと、AWS 導入の初期段階にあるお客様とともに働くことに情熱を注いでいます。仕事の合間には、ハイキング、サッカー、旅行を楽しんでいます。 Ankur Dang は Amazon Web Services(AWS) でソリューションアーキテクトを務めています。テクノロジーに情熱を注ぎ、お客様の問題解決とアプリケーションのモダナイゼーションの支援に取り組んでいます。特に AWS IoT サービスを活用したシステム設計に興味があり、モノのインターネット (IoT) ソリューションに熱心に取り組んでいます。仕事以外では、航空宇宙の進歩を研究したり、ドローン写真でユニークな空撮を楽しむなど、趣味を追求しています。 Marouane Hail は、クラウドオペレーションを専門とするソリューションアーキテクトです。お客様のために安全かつスケーラブルなソリューションを構築することに情熱を注いでいます。仕事以外では、サッカーをするのが好きで、テクノロジーについても学習を続けています。 以下のAWS リソースも併せてご確認ください。 [1] Tutorial: Connecting a device to AWS IoT Core by using the AWS IoT Device SDK [2] Tutorial: Connecting Sidewalk devices to AWS IoT Core for Amazon Sidewalk [3] Tutorial: AWS IoT Rule to Send an Amazon SNS notification [4] Tutorial: AWS IoT Rule to send incoming data to Amazon Timestream [5] Tutorial: Visualize your time series data and create alerts using Grafana [6] Blog: Ingesting enriched IoT data into Amazon S3 using Amazon Kinesis Data Firehose [7] Blog: Analyze and visualize nested JSON data with Amazon Athena and Amazon QuickSight <!-- '"` -->
Amazon Timestream for LiveAnalytics は、高速でスケーラブルなサーバーレス時系列データベースであり、1 日に数兆件のイベントを簡単かつコスト効率よく保存および分析する事ができます。Timestream for LiveAnalytics は、数億の IoT デバイス、産業機器の監視や、ゲームセッション、ストリーミングビデオセッション、金融、ログ分析などのユースケースに使用できます。Timestream for LiveAnalytics を使用すると、高可用性を実現しながら、1 分あたり数十ギガバイトの時系列データを取り込み、数秒でテラバイトの時系列データに対する SQL クエリを実行できます。 現在、様々な組織が、時間に敏感なデータのリアルタイムの洞察を提供することで、競争上の優位性を獲得しようとしていますが、データストリームを使用したリアルタイムデータの取り込みをサポートし、それを Timestream for LiveAnalytics で処理して保存するデータパイプラインが必要となります。時系列データをサポートしている AWS ソースから Timestream for LiveAnalytics に転送するには、Apache Flink アダプターなどのすぐに使えるアダプター、またはカスタマイズされた専用のコードが必要になる場合がありました。 時系列データの取り込みを簡素化する為、 Amazon EventBridge Pipes と Timestream for LiveAnalytics の統合機能が今回使えるようになりました。EventBridge Pipes を使用して、 Amazon DynamoDB 、 Amazon Kinesis Data Streams 、 Amazon MQ 、 Amazon Simple Queue Service (Amazon SQS) などのさまざまなソースから Timestream for LiveAnalytics にデータを取り込めるようになりました。本リリースにより、Timestream for LiveAnalytics にデータを取り込むための、柔軟なローコード・ノーコード (LCNC) 構成ベースのソリューションが利用可能となります。 EventBridge Pipes は、サポートされている ソース と ターゲット 間のポイントツーポイント統合を目的としており、高度な 変換 、 エンリッチメント 、 フィルター 処理をサポートしています。EventBridge Pipes は、イベント駆動型アーキテクチャを開発する際の専門知識と統合コードの必要性を軽減し、企業のアプリケーション間の一貫性を促進します。 本投稿では、Timestream for LiveAnalytics が Kinesis Data Streams からデータを取り込めるように EventBridge Pipes を設定する方法を紹介します。 ソリューションの概要 以下の図は、EventBridge Pipes を利用して Kinesis Data Streams からデータを取り込む為のアーキテクチャを示しています。EventBridge Pipes がサポートしているその他の統合を調べるには、 Amazon EventBridge Pipes sources を参照してください。 次の JSON でサンプル車両データを生成し、 Amazon Kinesis Data Generator (KDG) を使用して Kinesis Data Streams にストリーミングします。 Kinesis Data Streams から Timestream for LiveAnalytics にデータを取り込むためのパイプを以下で設定していきます。 { "connectionTime": "{{date.now("YYYY-MM-DD HH:mm:ss.SSS")}}", "vehicle_id": "CAR_{{random.number({"min":1, "max":100})}}", "driver_id": "USER_{{random.number({"min":1, "max":1000})}}", "engine_status": "{{random.number({"min":0, "max":1})}}", "miles": "{{random.number({"min":0, "max":1000})}}.0" } 前提 本投稿では、 データベース VehicleMetricsDB と テーブル VehicleMetrics を作成しました。カーディナリティの高い列を持ち、テーブルのクエリで述語として頻繁に使用されるディメンションに基づいてパーティションキーを選択することをお勧めします。これにより、データがパーティション間で均等に分散され、パフォーマンスに関する問題を回避する事ができます。本投稿では、 顧客定義のパーティションキー として vehicle_id を持つ車両から生成されたデータを使います。またデータストリーム vehicle-metrics-stream についても 作成 しました。 注意: このソリューションでは、アカウントにコストが発生する AWS リソースが作成されます。本投稿の一部として作成したリソースは、完了したら必ず削除して下さい。 EventBridge pipe を作成する EventBridge Pipes のコンソール画面を開く Create pipe を選択 Pipe name として作成するパイプ名を指定する Description として説明を入力する (オプション) Build pipe タブの Source に Kinesis を選択し、適切なストリームを選択する Additional setting で要件に応じて、 バッチサイズや多重度の値 を設定する On partial batch item failure – AUTOMATIC_BISECT を選択する事を推奨します。各バッチは自動的に半分に分割され、すべてのレコードが処理されるか、失敗したメッセージのみがバッチ内に残るまで、半分ずつ再試行されます。 Batch size – デフォルトの 100 を選択しましょう。尚、Amazon SQS がソースの場合は最大のバッチサイズは 10 になります。 Build pipe タブの Target を選択 このデモでは、 フィルタリング と エンリッチメント のオプションは必要ないため、ターゲットを直接設定しますが、要件に基づいてフィルタリングとエンリッチメントの適用を選択できます。エンリッチメントレイヤーを追加すると、 さまざまなサービスがさまざまなレベルのバッチ処理をサポート します。 Details の Target service で、ターゲットとして Timestream for LiveAnalytics を選択し、対象のデータベースとテーブルを選択します。 データが有効な JSON の場合、入力テンプレートまたはターゲットパラメーターの JSON パスは コンテンツを直接参照 できます。たとえば、 &lt;$.data.someKey&gt; を使用して変数を参照できます。 Time field type には、$.data.connectionTime をデフォルトの 時間 として TIMESTAMP_FORMAT ( yyyy-MM-dd HH:mm:ss.SSS ) を使用します。要件によっては、 EPOCH 形式も選択できます。 Version value を指定する事で、最新の値を使用してデータポイントを 更新 できます。各 Kinesis レコードには、 ApproximateArrivalTimestamp という値が含まれており、ストリームがレコードを正常に受信して保存したときに設定されます。本投稿では、更新を処理するためにバージョン値を $.data.approximateArrivalTimestamp に設定しました。そのため、最新の ApproximateArrivalTimestamp でメジャーが変更され、同じディメンションと時間の値が更新されます。 次のステップでは、Timestream for LiveAnalytics のデータモデル ( ディメンション、メジャー、メジャー名 、および必要な列の データ型 ) を構成します。この構成では、ビジュアルビルダーまたは JSON エディターのいずれかを使用できます。 データモデリングのベストプラクティス に従う事で、効果的なデータモデリングを実現します。 JSON エディター を利用して以下の情報を提供します DimensionValue (ディメンジョン)として、 vehicle_id と driver_id を使います。 MeasureValue (メジャー)としては、マイル数と engine_status を使います。 MultiMeasureName (メジャー名) には、’metric’ という固定値を使用します。要件に基づいて特定のソース列をメジャー名として選択できますが、 8,192 個の個別の値 を超えないようにしてください。 { "DimensionMappings": [ { "DimensionValue": "$.data.vehicle_id", "DimensionValueType": "VARCHAR", "DimensionName": "vehicle_id" }, { "DimensionValue": "$.data.driver_id", "DimensionValueType": "VARCHAR", "DimensionName": "driver_id" } ], "MultiMeasureMappings": [ { "MultiMeasureName": "metric", "MultiMeasureAttributeMappings": [ { "MeasureValue": "$.data.miles", "MeasureValueType": "DOUBLE", "MultiMeasureAttributeName": "miles" }, { "MeasureValue": "$.data.engine_status", "MeasureValueType": "BIGINT", "MultiMeasureAttributeName": "engine_status" } ] } ] } Visual Builder を使用してデータモデルをセットアップすることもできます。以下のスクリーンショットは、Visual Builder を使ったディメンションの設定例です。 MULTI_MEASURE_NAME と MULTI_MEASURE_VALUE に対しても同様に設定することができます。 これで、パイプの詳細設定 (アクセス許可、再試行ポリシー、 Amazon CloudWatch logs) ができるようになりました。 Pipe settings タブの Permission セクションで、新しい AWS Identity and Access Management (IAM) ロールを定義するか、既存のロールを使用できます。初めてパイプを作成する場合は、 Create a new role for specific resource を選択します。 Kinesis データストリームまたは DynamoDB ストリームをパイプのソースとして指定した場合は、オプションで再試行ポリシーとデッドレターキュー (DLQ) を設定できます。指定した保存期間より古いレコードを破棄し、失敗した場合の再試行回数を指定できます。 Retry policy では、 イベントの最大経過時間 として、少なくとも 30 分以上を使用することが推奨されます。このデモでは、30 分に設定したため、30 分より古いレコードは処理されず、DLQ に直接移動されます。 Retry attempts は 10 回に設定します。これは、一時的な問題に対処するための推奨値です。永続的な問題の場合は、再試行後にレコードが DLQ に移動され、残りのストリームのブロックが解除されます。 設定ミスによるデータ損失を避けるために、パイプの DLQ を構成することを強くお勧めします。 DLQ で Kinesis イベントのシーケンス番号を参照してレコードを修正し、Timestream に再送信できます。 DLQ を有効にするには、以下の Dead-letter queue の箇所を ON とし、使用するキューまたはトピックを選択します。このデモでは、Amazon SQS を使用し、同じ AWS アカウントと AWS リージョン内のキューを選択します。 Log destination で、ログレコードの配信先を選択します。ここでは、 CloudWatch Logs を選択します。 Log level では、EventBridge がログレコードに含める 情報のレベル を選択します。デフォルトでは、 ERROR ログレベルが選択されています。ここでは、詳細を確認できるように、 Log Level を ERROR から INFO に変更します。 ターゲットが Timestream for LiveAnalytics の場合は、 include execution data オプションを選択することをお勧めします。これにより、EventBridge はイベントのペイロード情報、サービスの要求/応答情報をログレコードに含めることができます。 EventBridge Pipes の実行データは、トラブルシューティングとデバッグに役立ちます。ペイロードフィールドには、バッチに含まれる各イベントの実際のコンテンツが含まれているため、個々のイベントを特定のパイプ実行に関連付けることができます。ただし、受信データには機密情報が含まれている可能性があり、このオプションを有効にすると、実際のイベントデータが選択したすべての宛先に記録されるため、データの機密性に基づいて正しい決定を下すようにしてください。 Create pipe を選択してパイプを作成します。 EventBridge コンソールで作成した特定のパイプに移動し、パイプが Running 状態になるまで待ちます。 ソリューションの検証 サンプルアーキテクチャの箇所で説明したように、KDG を使用してデータをストリーミングしました。この取り込みを検証するには、 Amazon Timestream for LiveAnalytics のクエリエディター を開き、次の SQL クエリを実行します。 SELECT * FROM "VehicleMetricsDB"."VehicleMetrics" limit 5 以下はクエリの結果を示しています。 要件に応じて、Timestream のクエリ言語を使用して様々な クエリ を実行できます。 考慮事項 AWS Command Line Interface (CLI) (AWS CLI)、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) を使用して、EventBridge Pipes のパイプを作成することもできます。 また、 CloudWatch メトリクス を使用して、取り込みの進行状況の監視が可能で、EventBridge コンソールの Monitoring タブでは呼び出しと失敗を視覚化できます。トラブルシューティングについては、 Log Amazon EventBridge Pipes を参照してください。 クリーンアップ 料金の発生を回避するには、 AWS マネジメントコンソール を使用して、このデモの為に作成したリソースを削除します。 Timestream のコンソールで Timestream のデータベースとテーブルを削除 します。 EventBrdige のコンソールで作成したパイプを選択して削除します。 Kinesis Data Streams のコンソールで作成したストリームを削除します。 CloudFormation コンソールで、KDG 用に作成した CloudFormation スタックを削除 します。 結論 本投稿では、EventBridge Pipes を統合して Kinesis Data Streams からデータを Timstream for LiveAnalytics に取り込む方法を説明しました。この新しい統合は、時系列データの取り込みを簡素化するのに役立ちます。 詳細については、次のリソースを参照してください。 Amazon EventBridge Pipes error handling and troubleshooting Data Modeling Best Practices to Unlock the Value of your Time-series Data Monitoring Amazon Kinesis Data Streams 本投稿へのフィードバックについては、 Amazon Timestream の AWS re:Post に送信して下さい。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。
本ブログは、AI inside 株式会社と Amazon Web Services Japan が共同で執筆しました。 AI inside 株式会社 は、生成AI・LLM や自律型 AI をはじめとした最先端テクノロジーの研究開発と社会実装を行うテックカンパニーです。AI エージェント「Heylix」や AI-OCR サービス「DX Suite」に加え、それらを支える AI インフラ「AnyData」と「AI inside Cube」を、政府機関・地方公共団体・民間企業へ広く提供しています。提供する AI サービスは既に、5 万人を超えるお客様に累計 72 億回以上ご利用いただいています。 直面していたビジネス上の課題 AI inside が提供する「 DX Suite 」は、これまで手入力で行っていた帳票のデジタル化を効率的に実現する AI-OCR サービスです。多くのお客様にご利用頂いていますが、OCR 対象の書類はフォーマットが統一されていない非定型帳票も多く、フォーマット毎に AI モデルの学習が必要となるケースがあり、その対応には約 2000 万円というコストと 1 ヵ月以上の時間が発生するというビジネス上の課題がありました。 この課題を解決するために、LLM を活用した「 学習不要であらゆる帳表の読み取りを実現する機能 」の実装を進めていました。本機能を「DX Suite」を利用するユーザーに提供するためには、精度・スループット・人件費含むコスト最適化に加え、エンタープライズのお客様が望む高い水準のセキュリティを満たす LLM 環境が必要でした。 ソリューション Amazon Bedrock は、単一の API を介して AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデルを選択できるフルマネージドサービスです。セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供します。 AI inside は Amazon Bedrock を活用することで、精度・スループット・コストにおいて他社モデルと同等以上の水準を確保しながら、Amazon Bedrock の特徴である豊富なモデルのラインナップや最新モデルへの対応などの高い柔軟性を獲得しました。 また、セキュリティの観点からも Amazon Bedrock を採用することによってメリットがありました。「DX Suite」は Amazon Elastic Kubernetes Service (Amazon EKS) 上で稼働しており、 AWS PrivateLink を活用することで AWS 内に閉じられたネットワークで Amazon Bedrock を利用することが可能です。また Amazon Bedrock は入力情報やトレーニングに使用するデータを学習しないため、推論データの追加学習が行われないセキュアな LLM 環境を実装できます。 導入効果 AI モデルの学習に必要だった約 2000 万円の費用と 1 ヵ月以上の時間が不要になり、「DX Suite」サービス開始から 7 年間で 13 種類だった非定型帳票プリセットが、わずか 3 ヵ月で 1000 種類を超えました。また Amazon Bedrock を活用した LLM 環境を実装することによって、エンタープライズレベルの顧客が求める水準でのサービス提供が出来るようになりました。 まとめ Amazon Bedrock を活用した LLM 環境の実装によって、安価かつ短期間での多様な帳票フォーマットへの対応を実現し、エンタープライズレベルの顧客が求める水準でのサービス提供が出来るようになりました。 AI inside では、生成AIエージェント「Heylix」などの新サービスにおいても AWS の先進的なテクノロジーを活用し、高付加価値かつセキュアなサービス提供を目指します。
みなさん、こんにちは!製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 Anthropic の Claude 3.5 Sonnet が発表され、バージニアリージョンの Amazon Bedrock にてご利用頂けるようになりました。 Claude 3.5 Sonnet は Claude 3 Opus よりも高いベンチマークスコアを記録する高い能力を発揮すると同時に、Opus よりも 80 %安価に、2 倍の動作速度でご利用頂けるとされています。 Claude 3.5 Sonnet は、学部レベルの専門知識 (MMLU)、大学院レベルのエキスパート推論 (GPQA)、数学の問題解決 (MATH) などの新しい業界ベンチマークを記録しました。 このブログでは、製造業で設計開発業務に取り組まれている R&amp;D (Research and Development:研究開発) エンジニアの方を想定ユーザーとして設定させていただき、大学レベルの専門知識が問われる工学的な問題を解く際に、Claude 3.5 Sonnet を活用するポイントについて解説させていただきます。 設計開発業務において工学的な問題を解く際の課題 例えば機械の設計を行う際、この形状で強度的に問題はないかや、適切に放熱できているかなどを計算して確認する業務は頻繁に生じます。その際、機械4大力学と言われる「機械力学」「材料力学」「熱力学」「流体力学」といった専門知識を駆使して、問題の事象を捉えてモデル化し、計算を行うことになりますが、範囲が広く難解なため、何も頼らないで自分の頭だけで解けるケースはそう多くありません。大学の教科書を参照したり、該当分野に詳しい同僚に教えを請うたりしながら解いていくことになります。 しかし、問題は複雑で様々な要素が絡んでいることも多く、教科書の中の該当する箇所を問題から逆引きして見つけ出すことは難しかったり、時間がかかったりします。該当分野に詳しい同僚に教えを請う場合でも、相談にあたって時間を取ってしまいますし、専門分野が細分化されているような問題の場合は複数人に相談する必要がでてきてしまいます。 そこで、冒頭に紹介した、学部レベルの専門知識など様々な新しい業界ベンチマークを記録した Claude 3.5 Sonnet の出番です。高いベンチマークスコアを記録したからといって、万能で全ての問題を解けるというわけではないのですが、本ブログではそういった不完全な部分もある AI との向き合い方のコツについても解説させていただきます。 Claude 3.5 Sonnet を活用した問題解決の実践 Amazon Bedrock で Claude 3.5 Sonnet のような基盤モデルを有効化して、チャットのやり取りを行うための準備手順については、こちらの Amazon Bedrockの生成系AIテクノロジーを活用して設計開発業務を進化させよう というブログをご参照ください。 今回は以下のような大学レベルの流体力学の問題に直面したエンジニアのシナリオで、 プロンプト を打ち込み、どのような回答が返ってくるかを見てみます。 【プロンプト】 あなたは熟練の機械設計エンジニアです。以下の問題を解いてください。 水平に置かれた内径 d1 =20cmの管が内径 d2 = 10 cm の菅に滑らかに接続されています。内径 d1 の管内を空気が毎分 4.71 m^3 の流量で流れています。接続部の内径 d1 側における圧力 p1 は 2.00 気圧でした。接続部の内径 d2 側における流速と圧力を教えてください。ただし、摩擦による損失を無視し、空気の密度を 1.23 kg / m^3とします。 Step by Step で考えてください。 最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください。 【Claude 3.5 Sonnet からの回答】 はい、この問題を Step by Step で解いていきましょう。 Step 1 : 与えられた情報を整理します。 – d1 = 20 cm = 0.2 m – d2 = 10 cm = 0.1 m – Q (流量) = 4.71 m³/min = 0.0785 m³/s – p1 = 2.00 気圧 = 202,650 Pa (1気圧 = 101,325 Pa) – ρ (空気密度) = 1.23 kg/m³ Step 2 : d1 側の流速 v1 を計算します。 A1 = π(d1/2)² = π(0.2/2)² = 0.0314 m² v1 = Q/A1 = 0.0785/0.0314 = 2.5 m/s Step 3 : 連続の式を使用して d2 側の流速 v2 を計算します。 A1v1 = A2v2 v2 = (A1/A2)v1 = (d1/d2)²v1 = (0.2/0.1)² × 2.5 = 10 m/s Step 4 : ベルヌーイの定理を適用します。 p1 + (1/2)ρv1² = p2 + (1/2)ρv2² Step 5 : p2 を解きます。 p2 = p1 + (1/2)ρv1² – (1/2)ρv2² &nbsp; &nbsp;= 202,650 + (1/2)×1.23×2.5² – (1/2)×1.23×10² &nbsp; &nbsp;= 202,650 + 3.84375 – 61.5 &nbsp; &nbsp;= 202,592.34375 Pa ≈ 1.9994 気圧 結果: – d2 側の流速: v2 = 10 m/s – d2 側の圧力: p2 ≈ 1.9994 気圧 自信度評価: 9/10 この計算は基本的な流体力学の原理に基づいており、与えられた条件下で正確であると考えられます。ただし、実際の状況では摩擦や乱流の影響があるため、完全に現実を反映しているわけではありません。そのため、10点満点ではなく9点としました。 チャットやり取りの内容解説 まず Claude 3.5 Sonnet からの回答は正解です(人間の専門家が検証しました。Claude 3.5 Sonnet が最後に言及している通り摩擦や乱流の影響などの細かい要素を無視した場合においてです)。論理立て、計算結果、いずれも流石のベンチマークスコアを感じさせる品質でした。 プロンプトには、良い回答を返してもらうための工夫として、「あなたは熟練の機械設計エンジニアです」や「Step by Stepで考えてください」といった表現が盛り込まれています。こういった Claude へプロンプトを書く際のコツについては こちら もご参照ください。 特に、「最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください」といったような、自信度合いを問うことは、こういった難解な質問を投げかける際には重要になります。例えば以下のような簡単な質問だとどのような回答が返ってくるかを見てみましょう。 【プロンプト】 5 × 10 + 3 – 4 = ? Step by Stepで考えてください。 最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください。 【Claude 3.5 Sonnet からの回答】 分かりました。ステップバイステップで解説し、最後に自信度合いを10段階で評価します。 &nbsp; ステップ 1 : 5 * 10 を計算します 5 * 10 = 50 ステップ 2 : 50 に 3 を足します 50 + 3 = 53 ステップ 3 : 53 から 4 を引きます 53 – 4 = 49 したがって、最終的な答えは 5 * 10 + 3 – 4 = 49 となります。 自信度合い: 10/10 この計算は非常に基本的なものなので、確信を持って正しい答えが出せたと思います。ステップバイステップで丁寧に解いたので、間違いはないはずです。 このような簡単な質問だと満点の10点で回答を返してくれました。しかし問題が難解になるほど、間違えてしまう可能性も増してきます。 そういった100%の正解が返せない場合においても、今回の流体力学の問題の例のように、自信度合いを聞いて、完全に正しいとは限らないと認識した上で、Step by Step でどのように論理立てて問題を解こうとしているかを参考にして思考の検討材料とすることは有益になると考えます。 学校の試験問題などとは異なり、現実の物理現象を扱う工学的な問題では正しい回答はどこにも存在しないケースが多々あります。手掛かりとなる参考情報を素早く与えてくれるだけで、役立つ存在となってくれることでしょう。 まとめ Claude 3.5 Sonnet は今回のケースにおいて、大学レベルの流体力学の問題を正しく解くことができました。問題が難解になるほど、間違えてしまう可能性も増してきますが、完全に正しいとは限らないと認識した上で、参考にできる情報を検討材料としてうまく活用することで、設計開発業務に役立てられるイメージを掴んでいただきました。 著者プロフィール 山田 航司&nbsp;(Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。
このブログは、6月20日と21日に開催された&nbsp;AWS Summit Japan&nbsp;における IoT 関連出展を紹介するものです。「プロダクト IoT 編」と「インダストリアル IoT 編」の二部構成で、今回は「インダストリアル IoT 編」についてお伝えします。(プロダクト IoT 編の記事は こちら です) 今年の AWS Summit Japan では、インダストリアル関連の IoT サービスを活用した多数のブース出展やセッションが行われました。どのコンテンツも、設備からのデータ取得だけでなく、取得したデータを様々なシーンで活用する方法を示しており、現場の課題解決に役立つ実用的な内容となっていました。ブース内で来場者との活発な質疑を交わす場面も多く見られ、実用フェーズに進んでいることが感じられました。このブログはインダストリアル IoT 編として、展示やセッションの一部をご紹介します。 カスタマーセッション 東海旅客鉄道株式会社 基調講演:ビルダーとテクノロジーが加速する次のイノベーション Breakout Session : リニア中央新幹線における設備 IoT 化に向けて~データドリブンによる徹底的な省人化の実現~ 東海旅客鉄道株式会社のリニア開発本部では、リニア中央新幹線の運営に向けてデータ分析プラットフォームを構築しています。山梨リニア実験線での「保守用車リアルタイム状態監視」と「開閉器動作音による異常検知」の2テーマについて、 AWS プロトタイピングプログラムを活用した取り組みを、基調講演とブレイクアウトセッションの2回にわたりご紹介いただきました。 IoT サービスを活用したデータドリブン運営に向けたステップがよくわかり、リニア中央新幹線開通への期待感がますます高まる内容となっていました。 基調講演: 東海旅客鉄道株式会社 中央新幹線推進本部 リニア開発本部 副本部長&nbsp;水津 亨 氏( オンデマンド配信 ) Breakout Session:東海旅客鉄道株式会社 中央新幹線推進本部 リニア開発本部&nbsp;宮本 真樹 氏 と藤原 海渡 氏( オンデマンド配信 )  株式会社 竹中工務店、日本タタ・コンサルタンシー・サービシズ株式会社 「建設デジタルプラットフォーム」によるデジタルデータと最新技術活用の取組み&nbsp; 日本タタ・コンサルタンシー・サービシズ株式会社 長谷川 隆一 氏と、株式会社 竹中工務店 デジタル室 先進デジタル技術グループ グループ長 丘本 道彦 氏により「「建設デジタルプラットフォーム」によるデジタルデータと最新技術活用の取組み&nbsp;」というタイトルで発表頂きました。 Building4.0 の取り組みとして、 AWS IoT TwinMaker を活用したデジタルツインの検証内容について、「作業進捗管理」や「 IoT デバイスと連携した熱中症対策」などの具体例を元にご紹介いただきました。建設事業のデジタル変革が目指すビジョンがよくわかる内容となっていました。詳細は こちらの資料 をご覧ください。 AWSセッション AWS IoT SiteWise を活用したスマート工場の実現&nbsp; アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 IoT スペシャリスト ソリューションアーキテクトの新澤 雅治がプレゼンテーションを行いました。主に製造業のお客様に向けて、スマート工場の実現に向けた手段を整理し 、 AWS IoT SiteWise の re:Invent 2023 で発表された新機能を含む具体的な活用方法を、お客様事例を交えて紹介しました。また、食品工場における生成AIアシスタントのデモにより、生成AIがどのように生産効率を向上させるかをご紹介しました。詳細は オンデマンド配信 をご覧ください。 物流業におけるデジタルツイン構築の勘所&nbsp; アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクトの戸塚 智哉がプレゼンテーションを行いました。デジタルツインは現実世界をデジタル空間に再現し、リアルタイムな監視やシミュレーションを可能にする技術ですが、現実世界のデータをどのようにクラウドで扱うのか、物流倉庫などの利用シーンをベースに、 AWS IoT サービスを使ったデザインパターンをご紹介しました。また、生成 AI と合わせることでより効果的なデジタルツインの実現についても勘所もご紹介しました。詳細は オンデマンド配信 をご覧ください。 再エネ時代のエネルギーシフトに向けたエネルギー基盤を支える AWS サービスの活用 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エネルギー&amp;ユーティリティ部 ソリューションアーキテクト の 岩下 高志朗 がプレゼンテーションを行いました。 グローバルウォーミング、カーボンニュートラルは世界中の国々、企業が取り組んでいる社会テーマとなっております。この来るべき再エネ時代は小規模の分散電源が大量に配置されるため、再エネ発電設備の最適化、電力需要供給のバランス調整、送配電設備の拡充計画などが重要となってきます。このようなニーズに対して、必要な業務機能群を整理し、そのような領域で活用できる AWS サービスの紹介と活用例を紹介しました。 詳細は オンデマンド配信 をご覧ください。 展示ブース 東海旅客鉄道株式会社/東海交通機械株式会社 AWS Village での東海旅客鉄道株式会社/東海交通機械株式会社様の共同ブースでは、 IoT を活用した鉄道機械設備のリモートモニタリングの展示が行われていました。設備が古く遠隔監視ができない機械や設備に対して、改修工事が不要な可搬式の電流センサー、温度センサーなどを設置し、 AWS IoT Greengrass を使って Amazon S3 へのデータ収集、 Amazon QuickSight による可視化を行うことで、遠隔地にある機械や設備のデータを事務所内で確認できることが実機とともに展示・紹介されていました。その他、 IoT で収集したデータを予兆保全につなげる事例など、鉄道機械設備における AWS の実活用事例が紹介されていました。 &nbsp;AWS 展示:クラウドで進化する鉄道機械保守 AWS Village の鉄道業向け AWS ブースでは、 IoT を使った鉄道機械設備管理システムのデモが行われていました。このデモでは、架空の駅の改札機やエレベーターなどを模擬した設備データを AWS IoT SiteWise で収集し、そのデータを基にしたアラーム監視や保全方法のリコメンドを Amazon Bedrock から受ける場面が再現されていました。また、遠隔地にある複数の駅のデータを構造化して保存し、横断的に可視化するダッシュボードなどがデモされており、クラウド利用の価値を実感できる内容となっていました。 &nbsp;AWS 展示:スマート X サステナビリティ ビル管理&nbsp; AWS&nbsp; IoT サービスを活用したスマート サステナビリティビル管理&nbsp;「サステナビリティを意識したミニチュア倉庫のデモを作ってみた !」 AWS IoT を活用し、持続可能性のソリューションライブラリの一つである 「Guidance for Smart and Sustainable Buildings on AWS」 を参考に、可視化したデータから省エネルギー化の洞察を得て、電力、費用及び温室効果ガス ( GHG ) 排出量の削減を実現するソリューションの実装例のデモを展示致しました。 「サステナビリティを意識したミニチュア倉庫のデモを作ってみた !」 でもご紹介している、 Amazon の倉庫を模したミニチュアモデルおいて、室温や空気の質をデータに基づいて適切に管理することで省エネルギーにつながる過程をご紹介しました。 AWS 展示:小さく早く始める効率化 – 製造現場の IoT データをパートナーとともに  小さく早く製造 DX を実現 スマート工場の様々なユースケースをミニチュア工場を使って表現したデモが展示されました。 PLC のデータを AWS IoT SiteWise に集約し、構造的にデータを保持することで、他の様々なソリューションが活用しやすくなっています。工場内のオペレータ向けの稼働可視化ダッシュボードだけでなく、 Salesforce Field Service やパトライトの ネットワーク制御信号灯 などの AWS パートナーソリューションを活用したアーキテクチャも紹介されました。また、 4M 変化点情報を生成 AI の元データとして使用することで、生成AI の効果を発揮できる可能性についても提示しました。 AWS 展示:小さく早く始める効率化 – 製造業の課題に挑む AI ソリューション 工場における「外観検査モデル立ち上げ」と「生産設備のリアルタイム監視と障害対応」の2つのユースケースを、生成 AI を用いて効率化するデモを展示しました。このデモでは、外観検査の機械学習モデル作成に必要な学習画像を準備できないという課題を、生成 AI を用いて画像生成することで解決しています。また、チャットに対して設備状態を問い合わせると、リアルタイムな設備の使用状況や設備の仕様やプログラム、障害対応手順に基づいて生成AIを用いたレスポンスを受けることができています。生成 AI を用いることで、生産現場のさらなる効率化の可能性を見ることができました。 東京ガス 株式会社 東京ガス 株式会社 のブースでは、 OT データをクラウドに集約し、最適制御や予知保全などのデータ活用を可能にするソリューションが展示されていました。当社が提供する国内トップシェアの SCADA ソフトである JoywatcherSuite と JoyCloudConnect に、 AWS IoT Core との MQTT 通信機能をプラグインすることで実現しています。 AWS 専用の接続設定があらかじめ準備されているため、短時間で AWS との接続が完了します。プラントデータのクラウド接続方法がわからずに悩んでいるユーザーにとって、有効な選択肢となりそうです。 アイレット株式会社 アイレット株式会社のブースでは、本物の6軸ロボットを使用した生産状況可視化とトラブル分析の効率化を実現するデモが展示されていました。 AWS IoT SiteWise の稼働データと Kinesis Video Streams のカメラ映像を 1 枚のダッシュボードで統合的に表示し、異常が検知された前後の映像を自動で記録することで、後で遡って原因分析を行うことができます。トラブル発生前後の動画とデータを使って原因分析を行うことで、復旧までの時間短縮につながります。トラブルの原因究明に多くの時間をかけているユーザーにとって有効なソリューションとなりそうです。 富士ソフト株式会社 富士ソフト株式会社のブースでは、カメラ映像と IoT データを組み合わせた、クラウド型設備管理ソリューションのデモが展示されていました。現場の3次元画像と IoT データを統合したダッシュボードでAmazon Bedrockにより、自然言語で会話的に設備についての質問ができます。「エラーが一番多い場所に移動したい」、「ナースコールが鳴っている場所に移動したい」、「○○センサーの単位は?」など、日本語による会話で設備の現在の状態について問い合わせたり、見たい場所に移動することができます。まさにデジタルツインを体現したデモとなっていました。また、森田 和明氏による著書、 AWSの生成AIサービスを体系的に解説した入門書として&nbsp; Amazon Bedrock 生成AIアプリ開発入門 [AWS深掘りガイド] &nbsp; も出版されています。 スマート工場のための収集・可視化・分析 SCSK株式会社 SCSK 株式会社では、製造現場の可視化・分析のためのソリューション“Duetics(デュエティクス)“を工場を模した模型に接続して展示されていました。AWSでも同じ模型を使ってデモをしていますが、こちらの展示では PLC を国内でシェアの高い三菱電機製に交換したり、クラウド側での大規模な分析ソリューションと接続し、日本のお客様にスマート工場のデータ収集・可視化・分析をすぐにでも導入できるような内容となっていました。 オムロン株式会社: 汎用性の高い技術で構築された IoT 端末可視化 オムロン株式会社のブースでは、 IoT の可視化環境をテンプレート化することにより、様々なお客様にむけた環境構築を効率的に進められるというご紹介をされていました。これによりビル管理や、加工機械等の工場の装置を遠隔監視する仕組みを多数のお客様に提供されています。工場等において、OT ネットワークとの接続が難しい場合にはセルラー回線と組み合わせたり、ビル等の工場以外では、オムロン株式会社独自のセンサーと通信モジュールを組み合わせた最適なソリューションを提供するというセンサーメーカーならではの展示をされていました。 AWS:&nbsp; AIによるプラント保守 – 生成AI・映像・音声と外付けセンサーによるプラント保守支援&nbsp; この展示では、プラント管理における技術継承を題材に、プラントを模した流体回路にセンサーを設置して AWS IoT Core で情報収集し、異常を発生させ、機器のエラー番号からのトラブルシュートを生成AIで行うデモを展示しました。 PLC から受け取ったエラーコードをもとに、過去の報告書から Bedrockが「想定される原因」「過去の対応策」「推奨作業事項」を提示しており、シアター形式で行われて大人気を博しました。詳細は こちらのブログ からご覧いただけます。 AWS: 小さく早く始める効率化 – Software Defined Factory システムインテグレータや、企業内の DX 部門は、工場の DX 化のための OT へのアクセスが簡単ではなく、一方で早く完成イメージを提示し活動を推進したいというジレンマを抱えています。この展示では、OT に見立てたクラウド上の仮想ネットワーク ( Amazon VPC ) 上で、機器をシミュレートするプログラムを動かし、AWS CDK を使って OT とクラウドのソリューション構築を自動化することで、OT にアクセスする前に可視化ソリューションを構築するアプローチを提示しました。 まとめ AWS Summit Japan 2024のインダストリアルIoTのコンテンツは、データの可視化だけでなく、デジタルツインや生産性向上など、IoTが実際の業務に直結する段階に進んでいることが感じられました。また、新しい流れとして、IoT と生成 AI を組み合わせたソリューションのアイデアも多く出展されており、今後のさらなる発展が楽しみです。AWS では、今後も IoT の可能性とビジネスを追求するカスタマの支援を加速していきます! 著者 山本 直志 Industry Specialist Solutions Architect 製造業のワークロードを担当する Specialist SA として、お客様が AWS クラウドを活用し、今までにないソリューションを提供するお手伝いをしています。 新澤 雅治 IoT Specialist Solutions Architect 製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様のIndustrial IoT 関連案件の支援に携わる。
お客様から Amazon Elastic Container Service (Amazon ECS) に AWS CodeDeploy を使用して ブルー/グリーン デプロイを実装するための支援がしばしば求められます。 お客様のユースケースは通常、クロスリージョンおよびクロスアカウント間でのデプロイシナリオが含まれます。 これらの要件だけでも十分に難しいのですが、さらに CodeDeploy を使用する際には特定の設計上の決定が必要となります。 具体的には CodeDeploy の設定方法、CodeDeploy リソース (アプリケーションやデプロイグループなど) の作成時期と方法、アカウントとリージョンの任意の組み合わせにデプロイできるコードの書き方が含まれます。 本日は、そうした設計上の決定について詳細に説明し、 CDK Pipelines を使用してアカウントとリージョンをまたぐシナリオで Amazon ECS へサービスをデプロイする self-mutation パイプラインを実装する方法について説明します。このブログ記事では、 AWS Cloud Development Kit (AWS CDK) を使用したクラウドインフラストラクチャの開発とデプロイのための ベストプラクティス に従っている Java 製の デモアプリケーション も紹介します。記事中で言及されるコードはデモアプリケーションの実装です。 パイプラインの概要 CDK Pipelines は、さまざまな デプロイエンジン でパイプラインを構築するために使用されるコンストラクトライブラリです。 クロスリージョンやクロスアカウントのパイプラインを実装する際に、開発者やインフラストラクチャエンジニアが解決する必要がある実装の詳細を抽象化しています。 例えば、クロスリージョンのシナリオでは、 AWS CloudFormation はターゲットリージョンに複製されたアーティファクトを必要とします。 そのため、 AWS Key Management Service (AWS KMS) キー、 Amazon Simple Storage Service (Amazon S3) バケット、ポリシーをセカンダリリージョンに作成する必要があり、リージョン間でアーティファクトを移動できるようになります。 また、クロスアカウントのシナリオでは、CodeDeploy は構成ファイルの暗号化に使用される KMS キーへのアクセス権を持つクロスアカウントロールを必要とします。 これらはお客様が手作業で対処したくないものの一例です。 AWS CodeDeploy は、さまざまなシナリオでアプリケーションのデプロイを自動化するデプロイサービスです。Amazon EC2 インスタンス、オンプレミスインスタンス、 Lambda 関数、または Amazon ECS サービスにデプロイします。 AWS Identity and Access Management (AWS IAM) と統合して、アプリケーションをデプロイする際のアクセス制御を実装できます。 ブルー/グリーン型のデプロイでは、Amazon CloudWatch Alarms を使ってデプロイのロールバックを自動化できます。 CDK Pipelines は、AWS CloudFormation のデプロイを自動化するように設計されました。 AWS CDK を使用すると、これらの CloudFormation デプロイでは、インスタンスやコンテナへのアプリケーションのデプロイを含めることができます。 ただし、一部のお客様は、アプリケーションのデプロイに CodeDeploy を使用することを好みます。 この AWS ブログ記事では、CloudFormation ではなく CodeDeploy を使用した CDK Pipelines のデプロイを紹介します。 設計上の考慮事項 この記事では、CodeDeploy を使用してサービスをアカウント (シングルアカウントまたはクロスアカウント) およびリージョン (シングルリージョンまたはクロスリージョン) の任意の組み合わせにデプロイするための、さまざまなユースケースに CDK Pipelines を活用することを検討します。 具体的には、以下の 4 つの問題を解決する必要があります。 CodeDeploy の設定 CodeDeploy を使ってブルー/グリーンデプロイタイプを実装するための最も一般的なオプションは、 AWS::CodeDeployBlueGreen マクロ を使うか、CodeDeploy コンストラクトを使うことです。この記事では後者の方法を採用します。同じ問題をカスタムリソースを使って解決しているお客様もいますが、この方法はカスタムリソースを使わない柔軟な方法です。パイプラインは実行のたびにコンテナを Amazon Elastic Container Registry (ECR) にプッシュし、タグを作成します。CodeDeploy はその情報をコンテナのデプロイに使います。 ここで推奨したいのは、AWS CDK クラウドアセンブリをスキャンし、リポジトリとタグ情報を取得するためにパイプラインアクションを作成することです。同じアクションで CodeDeploy 設定ファイルの作成を行うこともできます。CodeDeploy を設定するには、 appspec.yaml 、 taskdef.json 、 imageDetail.json の 3 つの設定ファイルが必要です。 このパイプラインアクションは、CodeDeploy デプロイアクションの前に実行する必要があります。 appspec.yaml と taskdef.json のテンプレートファイルを作成し、 次のスクリプト をパイプライン内で実行することで3つの設定ファイルを作成することができます。 ## #!/bin/sh # # AWS CodeDeploy の設定を行うアクション # template-appspec.yaml と template-taskdef.json を元に環境に応じた設定ファイルを作成します # # Account = The Account Id # AppName = Name of the application # StageName = Name of the stage # Region = Name of the region (us-east-1, us-east-2) # PipelineId = Id of the pipeline # ServiceName = Name of the service. It will be used to define the role and the task definition name # # Primary output directory is codedeploy/. All the 3 files created (appspec.json, imageDetail.json and # taskDef.json) will be located inside the codedeploy/ directory # ## Account=$1 Region=$2 AppName=$3 StageName=$4 PipelineId=$5 ServiceName=$6 repo_name=$(cat assembly*$PipelineId-$StageName/*.assets.json | jq -r '.dockerImages[] | .destinations[] | .repositoryName' | head -1) tag_name=$(cat assembly*$PipelineId-$StageName/*.assets.json | jq -r '.dockerImages | to_entries[0].key') echo ${repo_name} echo ${tag_name} printf '{"ImageURI":"%s"}' "$Account.dkr.ecr.$Region.amazonaws.com/${repo_name}:${tag_name}" &gt; codedeploy/imageDetail.json sed 's#APPLICATION#'$AppName'#g' codedeploy/template-appspec.yaml &gt; codedeploy/appspec.yaml sed 's#APPLICATION#'$AppName'#g' codedeploy/template-taskdef.json | sed 's#TASK_EXEC_ROLE#arn:aws:iam::'$Account':role/'$ServiceName'#g' | sed 's#fargate-task-definition#'$ServiceName'#g' &gt; codedeploy/taskdef.json cat codedeploy/appspec.yaml cat codedeploy/taskdef.json cat codedeploy/imageDetail.json ツールチェーンの利用 効果的な戦略は、パイプラインをツールチェーンにカプセル化して、さまざまなアカウントやリージョンへのデプロイ方法を抽象化することです。これにより、パイプラインの作成方法、CodeDeploy の設定方法、および別のアカウントやリージョンへの展開方法など、実装の詳細を切り離すことができます。パイプラインを作成するには、 デモアプリケーション 内の Toolchain スタックをデプロイします。これは必要に応じて別の環境を追加できるようになっています。要件によってはコンポーネントごとに異なる Stage や Wave を反映するように、パイプラインをカスタマイズする必要があります。より詳細な情報は、 安全なハンズオフデプロイの自動化 とその リファレンス実装 を参照してください。 Toolchain スタックは、Java 用 CDK 全体で使われている Builder パターンに従っています。これは、1 つの文で複雑なオブジェクトを作成できる便利な機能です。 Toolchain.Builder.create(app, Constants.APP_NAME+"Toolchain") .stackProperties(StackProps.builder() .env(Environment.builder() .account(Demo.TOOLCHAIN_ACCOUNT) .region(Demo.TOOLCHAIN_REGION) .build()) .build()) .setGitRepo(Demo.CODECOMMIT_REPO) .setGitBranch(Demo.CODECOMMIT_BRANCH) .addStage( "UAT", EcsDeploymentConfig.CANARY_10_PERCENT_5_MINUTES, Environment.builder() .account(Demo.SERVICE_ACCOUNT) .region(Demo.SERVICE_REGION) .build()) .build(); 上記では、CDパイプラインが TOOLCHAIN_ACCOUNT と TOOLCHAIN_REGION で作成されています。 このパイプラインには、Apache Maven を使ってソースコードをビルドし、Java アーカイブ (JAR) を作成するステージが実装されています。 その後、パイプラインは JAR ファイルを含む Docker イメージを作成します。 UAT ステージでは、 CANARY_10_PERCENT_5_MINUTES のデプロイ設定を使用して、サービスを SERVICE_ACCOUNT と SERVICE_REGION にデプロイします。 つまり、最初に 10% のトラフィックが新しいアプリケーションに移行され、残りの 90 % が 5 分後にデプロイされます。 追加のデプロイステージを作成するには、 ステージ名 、CodeDeploy の デプロイ設定 、そしてサービスをデプロイすべき 環境 が必要です。先に述べたように、このパイプラインはデフォルトで自身を変更する Self-mutation パイプラインです。たとえば、 Prod ステージを追加するには、 Toolchain オブジェクトを作成する CDK コードを更新し、この変更をコードリポジトリに送信します。パイプラインが実行され、 UAT ステージの後に Prod ステージが追加されてパイプライン自身が更新されます。次に示すのは、新しい Prod ステージを追加するコードです。新しいステージは UAT 環境と同じアカウントおよびリージョンにデプロイされます。 ... .addStage( "Prod", EcsDeploymentConfig.CANARY_10_PERCENT_5_MINUTES, Environment.builder() .account(Demo.SERVICE_ACCOUNT) .region(Demo.SERVICE_REGION) .build()) .build(); 上記の文では、 Prod ステージが CodeDeploy の デプロイ構成 CANARY_10_PERCENT_5_MINUTES を使用して、新しいバージョンのサービスをデプロイします。 つまり、最初に 10 % のトラフィックが新しいバージョンのアプリケーションに移行され、5 分後に残りのトラフィックが新しいバージョンに移行されるということです。 ビジネスアプリケーションの分離と管理のベストプラクティスについては、 複数のアカウントを使用した AWS 環境の構成 ホワイトペーパーを参照してください。 一部のお客様は、このアプローチに興味を持たれ、アプリケーション開発チームへの抽象化されたソリューションとして提供することを決定するかもしれません。 その場合、そのようなパイプラインを構築するコンストラクトを作成することをお勧めします。コンストラクトを使うと、さらにカスタマイズできます。 例えば、品質保証を促進するステージや、災害復旧シナリオでサービスをデプロイするステージなどです。 この実装では、ツールチェーンスタックと、各デプロイステージ用のスタックを作成します。たとえば、 UAT という単一のデプロイステージでツールチェーンが作成された場合を考えましょう。 正常に実行されると、次の画像のように DemoToolchain および DemoService-UAT スタックが作成されます。 CodeDeploy アプリケーションとデプロイグループ CodeDeploy の構成には、アプリケーションとデプロイグループが必要です。ユースケースによっては、ツールチェーン (パイプライン) と同じアカウントあるいは別のアカウントでこれらを作成する必要があります。パイプラインには、ブルー/グリーンデプロイを実行する CodeDeploy デプロイアクションが含まれています。 私の推奨は、CodeDeploy アプリケーションとデプロイグループをサービススタックの一部として作成することです。 このアプローチにより、CodeDeploy アプリケーションとデプロイグループのライフサイクルを関連するサービススタックインスタンスと合わせることができます。 CodePipeline を使うと、存在しない CodeDeploy アプリケーションとデプロイグループを参照する CodeDeploy デプロイアクションを作成できます。 これにより、以下のアプローチを実装できます。 ツールチェーンスタックは、存在しない CodeDeploy アプリケーションとデプロイグループを参照するデプロイアクションでパイプラインをデプロイします パイプラインが実行されると、まず関連する CodeDeploy アプリケーションとデプロイグループを作成するサービススタックがデプロイされます 次のパイプラインアクションでデプロイアクションが実行されます。パイプラインがデプロイアクションを実行する段階では、必要な CodeDeploy アプリケーションとデプロイグループが(前のステップで作成されたため)存在しています。 以下は、(最初は存在しない) CodeDeploy アプリケーションおよびデプロイグループを参照するパイプラインコードです。 private IEcsDeploymentGroup referenceCodeDeployDeploymentGroup( final Environment env, final String serviceName, final IEcsDeploymentConfig ecsDeploymentConfig, final String stageName) { IEcsApplication codeDeployApp = EcsApplication.fromEcsApplicationArn( this, Constants.APP_NAME + "EcsCodeDeployApp-"+ stageName, Arn.format(ArnComponents.builder() .arnFormat(ArnFormat.COLON_RESOURCE_NAME) .partition("aws") .region(env.getRegion()) .service("codedeploy") .account(env.getAccount()) .resource("application") .resourceName(serviceName) .build())); IEcsDeploymentGroup deploymentGroup = EcsDeploymentGroup.fromEcsDeploymentGroupAttributes( this, Constants.APP_NAME + "-EcsCodeDeployDG-"+ stageName, EcsDeploymentGroupAttributes.builder() .deploymentGroupName(serviceName) .application(codeDeployApp) .deploymentConfig(ecsDeploymentConfig) .build()); return deploymentGroup ; } これを機能させるには、パイプラインで CodeDeploy デプロイアクションを作成するときと、サービススタック (Amazon ECS インフラストラクチャがデプロイされている) で CodeDeploy アプリケーションとデプロイグループを作成するときで、同じアプリケーション名とデプロイグループ名の値を使用する必要があります。 このアプローチが必要な理由はサービススタック内で作成したリソースを参照して CodeDeply デプロイアクションを設定すると循環依存エラーが発生するためです。 以下は、サービススタックコンストラクト ID を使用して CodeDeploy アプリケーションとデプロイグループに名前を付けるコードです。 パイプラインで CodeDeploy デプロイアクションを作成する際に使用したのと同じ名前をサービススタックのコンストラクト ID に設定しています。 // configure AWS CodeDeploy Application and DeploymentGroup EcsApplication app = EcsApplication.Builder.create(this, "BlueGreenApplication") .applicationName(id) .build(); EcsDeploymentGroup.Builder.create(this, "BlueGreenDeploymentGroup") .deploymentGroupName(id) .application(app) .service(albService.getService()) .role(createCodeDeployExecutionRole(id)) .blueGreenDeploymentConfig(EcsBlueGreenDeploymentConfig.builder() .blueTargetGroup(albService.getTargetGroup()) .greenTargetGroup(tgGreen) .listener(albService.getListener()) .testListener(listenerGreen) .terminationWaitTime(Duration.minutes(15)) .build()) .deploymentConfig(deploymentConfig) .build(); CDK Pipelines のロールと権限 CDK Pipelines は、さまざまなシナリオ (リージョンやアカウントなど) においてデプロイを実行するためのロールとアクセス許可を作成します。 CodeDeploy を別のアカウントで実行する際、CDK Pipelines はクロスアカウントのサポートスタックをデプロイします。このサポートスタックは、CodeDeploy アクションのためのパイプラインアクションロールを作成します。 このクロスアカウントのサポートスタックは JSON ファイルに定義されており、対象アカウントの AWS CDK の Assets バケットにアップロードする必要があります。 パイプラインで self-mutation 機能が有効 (デフォルト) の場合、UpdatePipeline ステージでは cdk deploy を実行し、パイプラインへの変更をデプロイします。 クロスアカウントのシナリオでは、このデプロイにはクロスアカウントのサポートスタックのデプロイ/更新も含まれます。 このため、UpdatePipeline ステージの SelfMutate アクションは、リモートアカウントで CDK の ファイル公開 と デプロイ のロールを引き受ける必要があります。 UpdatePipeline ステージを実行する AWS CodeBuild プロジェクトに関連付けられている IAM ロールには、デフォルトではこれらのアクセス許可がありません。 CDK Pipelines は、クロスアカウントスタックに必要なアクセス許可の情報は AWS CDK アプリの合成が終わった後でしか利用できないため、これらのアクセス許可を自動的に付与することはできません。その時点では、パイプラインのアクセス許可がすでにロックされています。 したがって、クロスアカウントのシナリオでは、ツールチェーンがパイプラインの UpdatePipeline ステージのアクセス許可を拡張して、 ファイル公開 と デプロイ のロールを含める必要があります。 クロスアカウント環境では、これらのアクセス許可を手動で UpdatePipeline ステージに追加することが可能です。そのためには、 Toolchain スタックを使用して、このような実装の詳細を隠すことができます。最終的には、以下のようなメソッドを使用して、不足しているアクセス許可を追加できます。パイプライン内の各異なるステージとアカウントのマッピングについて、ターゲットアカウントがパイプラインがデプロイされているアカウントと異なるかどうかを検証します。条件を満たした場合は、UpdatePipeline ステージに対して、ターゲットアカウントの CDK ブートストラップロールを引き受ける権限を付与する必要があります (キー aws-cdk:bootstrap-role で、タグ値は file-publishing または deploy )。以下の例は、UpdatePipeline ステージにアクセス許可を追加する方法を示しています。 private void grantUpdatePipelineCrossAccoutPermissions(Map stageNameEnvironment) { if (! stageNameEnvironment.isEmpty()) { this.pipeline.buildPipeline(); for (String stage : stageNameEnvironment.keySet()) { HashMap condition = new HashMap&lt;&gt;(); condition.put( "iam:ResourceTag/aws-cdk:bootstrap-role", new String[] {"file-publishing", "deploy"}); pipeline.getSelfMutationProject() .getRole() .addToPrincipalPolicy(PolicyStatement.Builder.create() .actions(Arrays.asList("sts:AssumeRole")) .effect(Effect.ALLOW) .resources(Arrays.asList("arn:*:iam::" + stageNameEnvironment.get(stage).getAccount() + ":role/*")) .conditions(new HashMap() {{ put("ForAnyValue:StringEquals", condition); }}) .build()); } } } デプロイステージ UAT という単一のデプロイステージがあるパイプラインを考えてみましょう。 UAT ステージでは DemoService をデプロイします。それには 4 つのアクション: DemoService-UAT (準備とデプロイ)、ConfigureBlueGreenDeploy 、そして Deploy が必要です。 DemoService-UAT.Deploy アクションは ECS リソースと CodeDeploy アプリケーションとデプロイグループを作成します。ConfigureBlueGreenDeploy アクションは CDK クラウドアセンブリ から ECR リポジトリやコンテナイメージのタグ情報を読み取ります。パイプラインはこの情報をデプロイアクションに送り、CodeDeploy を使ったデプロイが開始されます。 ソリューションの概要 利便性のため、これらすべての課題を解決し、リファレンス実装として使える Java アプリケーション を作成しました。 このアプリケーションのデプロイは、アカウントやリージョンでのすべてのデプロイシナリオで同じ 5 つのステップに従い、次の設計に表されているシナリオも含まれます。 結論 この投稿では、アカウントとリージョンの様々な組み合わせで CodeDeploy を使用して Amazon ECS にサービスをデプロイするパイプラインを作成する際に伴う課題を特定、説明、解決しました。 また、これらの推奨事項を実装するデモアプリケーションを紹介しました。 サンプルコードを拡張して、自動テスト、自動デプロイロールバック、障害復旧など、より複雑なシナリオを実装できます。 あなたの変革の旅がうまくいくことを願っています。 Luiz Decaro Luiz は、アマゾンウェブサービス (AWS) のプリンシパルソリューションアーキテクトです。彼は金融サービス業界のお客様がクラウドで成功できるよう支援することに重点を置いています。Luiz はソフトウェアエンジニアリングの修士号を取得しており、2005 年に最初の継続的デプロイパイプラインを立ち上げました。 本記事は、 Luiz Decaro による “Blue/Green deployments using AWS CDK Pipelines and AWS CodeDeploy” を翻訳したものです。翻訳はソリューションアーキテクトの平川 大樹が担当しました。
6 月 20 日と 21 日の二日間にかけて、3 万を超えるオンサイト来場者とともに、今年の AWS Summit Japan は大盛況のうちに幕を閉じました。この二日間にわたり、150 以上のセッションと 250 以上のブース展示が行われ、AWS の最前線がここに集結しました。IoT が多岐にわたる産業に根ざし、実用的なフェーズに進む中で、今年は IoT と生成 AI を活用した革新的なソリューションも次々と試みられました。今年は実に30を超える IoT 関連のセッションと展示が行われましたが、その中のいくつかを IoT プロダクト編とインダストリアル IoT 編の二部構成にて、会場で感じた熱気とともにハイライトをお伝えしていきたいと思います。 セッション 『たまごっち』シリーズの進化と、AWS IoT で築いた『Tamagotchi Uni』でつながる世界 株式会社バンダイ トイ事業部 チーフ 坂本 大祐 氏 世代を超えて愛される「たまごっち」シリーズ初の Wi-Fi 搭載機種『 Tamagotchi Uni 』について、①複雑さの排除、②セキュアな接続、③大規模スケーリングのためにどのように AWS IoT を活用したかについて解説いただきました。特にグローバルで販売する大量のたまごっちへのデータ配信に時間がかかるという課題について、AWS IoT Core のダイナミックグループ機能を使ってそれを克服し、すべてのユーザーに公平に最新コンテンツを楽しんでもらうことに成功するストーリーは多くの観衆を引き込んでいました。詳細は オンデマンド配信 、また「 大規模台数のたまごっちへ AWS IoT Jobs で高速かつ高効率にファームウェアを配信する方法 」も合わせてご覧ください。 小規模体制でも開発できた電動車椅子の自動運転サービス~ AWS IoT 、サーバレスのクラウド活用~ WHILL 株式会社 CTO 福田 慧人 氏 近距離モビリティにおける自動運転のチャレンジを AWS IoT とサーバレスを活用して小規模体制かつ短期間で実現した事例を発表いただきました。交通ルールのない世界中の空港や美術館等で歩行者と同じ空間であらゆるシーンを想定して自律走行た実現においては、機体同士の最適なデマンドプランと経路設計、エレベーターシステムとの連携、そして利用者や管理者とのコミュニケーションを一つの統合された「自動運転サービス」システムとして実現しなければなりませんでした。小規模体制ながらも、AWS サーバレスをフル活用して短期間で機能開発されました。その中で特に注目すべきは機体の位置やセンサー情報をAWS IoT を介してAWSに集約し、リアルタイムに世界各国で動いている機体の自律走行を実現した点でした。今後は WHILL OS にも注力され、モビリティ分野へのエコシステムの形成を強化される方針も伺いました。詳細は オンデマンド配信 をご覧ください。 トヨタにおける車両データ利活用と社会インフラ支援への取り組み トヨタ自動車株式会社 デジタルソフト開発センター 社会システム PF 開発部 データ活用推進室 データサービス開発 G デジタル変革推進室(兼務) 新事業企画部 事業統括室(兼務) グループ長 坪田 沙弥香 氏 街を走行するトヨタの車両からは、日々様々なデータが AWS 上の構築されたコネクティッドデータプラットフォームにアップロードされており、このデータを活用した様々な取組みやサービス事例をご紹介いただきました。少し先の未来を見て、車両情報、映像を使って消防車両の到着を助ける実証実験例をご紹介いただき、「お客様の笑顔のために、あなたの車が誰かを助ける、誰かの車があなたを助ける」社会に向けたトヨタの取り組み大変印象的でした。ここでも AWS の生成 AI の活用検討の状況や Amazon Location Service の活用をご紹介いただいています。詳細は オンデマンド配信 をご覧ください! SDV 時代のデータ駆動型自動車開発を支えるクラウド技術および生成 AI の適用性 日産自動車 株式会社 R&amp;D データサイエンスグループ Deputy General Manager 俵道 大輔 氏 Assistant Manager 葉 俊廷 氏 自動車における先進技術の研究・開発では、膨大なデータの活用が車両の性能改善や新機能の開発に貢献します。日産自動車株式会社は Engineering Workbench という開発環境により AWS IoT などによってクラウドに集約したデータを提供することで高度な実験を可能にし開発の効率性を高めています。さらに、生成 AI の活用やその評価により SDV 時代におけるデータ駆動型の自動車開発のアプローチを提案されていました。セッションは オンデマンド配信 でご覧いただけます。 KDDI のロボットプラットフォームにおける 開発の裏側 アイレット株式会社 執行役員 / アジャイル事業部事業部長 平野 健介 氏 KDDI 株式会社 先端技術統括本部 先端技術企画本部 ビジネス企画室 企画 1G グループリーダー 田中 政晃 氏 配送、見回り、清掃などのさまざまな利用シーンで活躍するロボット。多様なロボットをメーカーを問わず一元管理するロボットプラットフォームの開発において AWS IoT を活用した事例を紹介いただきました。ロボットの操作には AWS IoT Core が使用されていています。具体的には、ロボット認証のための証明書を手動でのキッティングする手間をなくす、プラットフォームからロボットに指示を出す、常時ロボットの情報を取得するなどの目的で活用いただいています。 展示ブース DMM オンクレ 合同会社 DMM.com 本物の500 台のクレーンゲームを 24 時間 365 日オンラインで楽しむことのできる DMM オンクレ 。オンラインでのクレーン操作には Amazon Kinesis Video Stream の WebRTC を活用した映像転送によりリアルタイム性と映像品質を確保されています。またクレーン毎に複数の制御用 IoT 機器が使われており、その管理や監視のために AWS IoT Core が活用されていたり、「人気のあるクレーンは?」などのゲームデータの解析には Amazon QuickSight を使うなどマネージドサービスをフルに活かした構成になっています。 Amazon Kinesis Video Streams 対応モジュール型カメラ i-PRO株式会社・富士ソフト株式会社 富士ソフト株式会社のブースでは、先日 Amazon Kinesis Video Streams へのデバイス認証(Device Qualification Program)対応が完了したばかりの i-PRO 株式会社のモジュール型カメラ moduca が展示されていました。小型の筐体・レンズ、通信ユニットを自由に組み替えが可能で、Amazon で購入可能な入手性を活かして、ソリューションの新規開発を高速化するカメラです。ブースでは、富士ソフト株式会社のデジタルツインとの接続と、エッジ AI 機能を用いたリアルタイム人物検知やモザイキングのデモを実施していました。 IoT Station 株式会社ゼネックコミュニケーション IoT Station では、AWS IoT Coreや自社開発のIFを利用することで異なる種類のセンサーや通信規格でも1つのダッシュボードに集約できます。IoTシステムにはいろいろなユースケースがありますが、様々な業種・業務課題に対応したテンプレート(Can-D)を利用することにより、開発期間を削減し、スピーディーなDX化が可能になっています。 スマートフィットネス: IoT を活用した生成 AI トレーナー AWS 展示 インストラクターのポーズと体験者のポーズを比較して、類似度を判定するというデモアプリケーションの展示。エッジのカメラで人の骨格情報を抽出して、それをAWS IoT Core を経由してAmazon BedRock の Claude3 へ送ることで判定します。判定結果の表示は IoT デバイス(マイコン)とも連携されており、デバイスと Web アプリを AWS IoT Core でリアルタイムかつシームレスに繋いでいました。ポーズの類似度を競うゲーム仕立てになっており、多くの来場者を楽しませていました。 生成AIが見守る!? 作業員の健康管理システムのデモ AWS 展示 ウェアラブルな IoT デバイスによってさまざまな環境下での作業者の心拍数や血中酸素濃度を取得し、また、温湿度などの室内の情報を測定するというデモを展示。取得されたデータは生成AIにより状況を判断させた内容とともにダッシュボードにて確認できるという、いろんな現場で活用できそうな内容になっていました。 生成 AI 車両データのリアルタイム分析デモ AWS 展示 目の前のサーキットを走るレース用ミニカーから回転数、スピード。サーキットの路面状況などのセンサーデータを AWS IoT Core や AWS IoT SiteWise を駆使して収集し、その場で分析するデモを行っていました。収集、分析、可視化での AWS サービス活用、さらに生成 AI によって作られたアナウンス、レースに勝つヒントやレース状況がドライバーに対して音声で読み上げられています。AWS らしく必要なブロックがうまく組み合わされて表現されているデモで興味深いものでした。 コネクテッドビークル AI解析による運転体験の最適化 AWS 展示 車から上がってくるセンサーデータとカメラ画像から路面状況把握し、AI 解析を通じて、ほぼリアルタイムに車のセッティングが自動で変わる世界をめざした HL Mando の MiCOSA の中で、AWS IoT FleetWise とその新機能である Vision System Data がどのように活用されているかをご紹介していました。車メーカーだけでなく、物流会社や保険会社など多くの業種の方がどのように AWS が車のデータ収集、活用に利用されているのか興味を持って聞かれてました。 仮想化で組み込みソフト開発・改善の高速化 AWS展示 スマートな製品の提供においては顧客ニーズを理解していち早く市場に製品を投入し、出荷後も DevOps の考え方により改善し続けることが重要です。そのための障害となっていた組み込みソフトウェア開発を含む DevOps 化の展示を行いました。空調機のコントローラーを題材に、ユーザーの機能利用状況を監視するダッシュボードを契機に、組み込みソフトウェアをクラウドでビルド・テストしAWS IoT Greengrass を介して更新する流れをデモとして提示しました。詳細は このブログ から参照可能です。 生成AIによるカメラ映像からの危険判別 AWS展示 製造現場などでの危険を検知するために、監視カメラの映像をクラウドに送って生成AIにより分析するデモを展示しました。カメラ映像はエッジの PC を介して Amazon Kinesis Video Streams によりライブ配信され、また画像フレームを Amazon Bedrock に入れ状況の記述や危険判定を行います。生成 AI の持つ汎用性により専用のモデル開発不要で様々な危険な状況に対応でき、マルチモーダルの生成 AI の可能性を感じさせるデモでした。展示資料は このブログ から入手可能です。 新価格体験を実現する次世代自販機 AWS展示 このデモでは、AWS のサービスを活用し、動的に価格を変動させる新しい自動販売機の体験を展示しました。自販機に内蔵されたコントローラに AWS IoT GreenGrass を搭載し、温度、商品の在庫状況、カメラによる混雑状況を考慮し、動的に商品の価格を変更(ダイナミックプライシング)するデモを紹介しました。自動販売機の商品展示用の液晶パネルも、購入ボタンも、AWS IoT Greengrass が搭載されたコントローラが制御し、AWS IoT Core 経由でリアルタイムで価格判定用の値と価格の変動を大画面のダッシュボードで表示し、お客さんに新しい体験を実感していただきました。 まとめ IoT のさまざまなユースケースが、会場の各所で見られた AWS Summit Japan 2024 でした。IoT がいかに多様な形で進化しているかを如実に示す機会だったと思います。また、新しい流れとして、IoT と生成 AI をさまざまな形で組み合わせたソリューションのアイデアも注目を集めており、これからの新しい流れになりそうで楽しみです。AWS では、今後も IoT の可能性とビジネスを追求するカスタマの支援を加速していきます! 著者 山本 直志 – Industry Solutions Architect (MFG) 製造業のワークロードを担当する Specialist SA として、お客様が AWS クラウドを活用し、今までにないソリューションを提供するお手伝いをしています。 真保 安憲 – IoT Sales Specialist 日本のIoT事業開発を担当しています。AWS IoTでモノとクラウドをつなぐだけでなく、人と人もつないで、皆様のIoT実現を一緒に進めるお手伝いをさせていただいています。 井上 昌幸 – IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。とっておきのアイデアを AWS と一緒にカタチにしましょう。
本稿では株式会社NTTドコモ(以下、docomo)において、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、同時視聴ユーザが数百万規模のライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 第一回 適切なデータストアの選定とアーキテクチャの見直し 1.はじめに docomoの『Lemino』は、2015 年から提供していた『dTV』をリニューアルする形で誕生した映像配信サービスです。 既存システムにとらわれず、新機能を素早く提供するとともに大規模なライブ配信を実現するために、データストアを改めて選定し、全てのアーキテクチャを見直しました。 dTV では目標需要を満たす設備が構成上の制約で準備できませんでしたが、Lemino では需要予測に応え、なおかつ低コストに配信可能になっています。 2.旧システムでのスケーリングの阻害要因 複数のアプリケーションでデータベースを共有すると、密結合が生じ、パフォーマンスの問題が発生する可能性があります。 以前の dTV のシステムでは、データベースは Amazon Aurora PostgreSQL をシャーディングせずに 1 クラスタで、すべてのアプリケーションで共有し、密結合の状態で使用していました。ただし、dTV のシステムは数百万規模の同時視聴のような大規模なライブ配信の要件が無かったため、Amazon Aurora PostgreSQL 1クラスタでも十分運用できていました。 Amazon Aurora 自体は Lemino でも活用していて、一般的な RDBMS を使いたいユースケースにマッチしています。データベース管理タスクをマネージドに提供してくれるため、データベースの管理作業が楽になります。 一方で、大規模なライブ配信の際にコンピュート( Amazon EC2 )の台数を数千にまで増やすことを検討・検証した際、PostgreSQL へのコネクション数増加によるリソース逼迫とトランザクション管理が課題になり、スケーラビリティを阻害する要因になっていました。 Cache や Read Replica の利用、RDS Proxy の活用による接続プーリング等、Amazon Aurora PostgreSQL のままで改善可能なことは検討しましたが、ライブ配信は開演時に急激にアクセスが来るうえに、セッションやデバイスの管理のために書き込み処理が避けられなかったため、どうしても急激なトランザクション増加に耐えられるように Writer のインスタンスのサイズを事前に大きくしておかなければなりませんでした。Writer のインスタンスのサイズは無限に大きくできるわけではありませんし、Writer インスタンスを変更するためにサービスの瞬断を伴う運用作業が必要になり、ユーザー影響が少ない時間帯に作業する労力がかかりました。常に Amazon Aurora PostgreSQL のインスタンスを大きなサイズにしておくことは費用の観点から難しく、作業は停止が許容されるメンテナンス時間帯で終わらせなければなりません。Amazon Aurora PostgreSQL に接続するコンピュートの数が増えれば増えるほど、DBを大きいものに変更した後にフロント側のコンピュートをスケールアウトするための時間がかかるようになり、予定していた時間の中で、想定数のコンピュートを起動し終えることは現実的ではありませんでした。 また、機能面のスケーラビリティも課題でした。Lemino は視聴ユーザーに合わせて広告型無料配信 / 月額有料配信 / PPV 配信など、様々な形態で提供し、感情検索やスタンプ、コミュニケーション機能などの機能拡張も実施が決定していました。このようなサービス追加は密結合なシステムでは影響範囲が大きくなるため困難でした。アプリケーションの更新時や故障時の影響を小さくするために、サービス分割を見直すことは必要不可欠でした。 図1.dTVのアーキテクチャ概要 3.Leminoでの設計方針 性能面・機能面のスケーラビリティを向上するために、RDBMS 以外のデータベースも含め、機能ごとに最適なデータストアを選定しました。既存のアプリケーションから、映像配信に必要となる基本機能とその画面遷移を検討、配信時にアクセス数が増える導線を確認し、どの機能がどのような API でデータにアクセスするかを整理して、書き込み・読み込み負荷を推測し、どこでコントロールできるかを確認していきます。 その上でデータストアを選定していきますが、その際、以下のような Step で検討しています。 Step1 データ取得時の検索条件およびリレーションの要否 アプリケーションがデータを取得する際の検索条件およびリレーションの要否を整理します。どのようなクエリが必要なのか、Primary Key 検索だけでデータアクセス要件が満たせるのか、もしくは複数のカラムまたは複数テーブルを結合した検索が必要かを検討します。 Step2 アクセス機能と負荷 どの機能が使われるとどのデータにアクセスするか、書き込み・読み込みを分けてそれぞれの想定負荷を検討します。 Step3 アクセスレコードの分散 特定のレコードにアクセス集中する場合は、どの程度キャッシュが活用できるのかを検討します。 図2. Lemino のデータストア選定検討サンプル この検討は Step1 から 3 までを実施して終了にはなりません。実際は、アプリケーションに対してユーザーがどのような導線でアクセスしてくるか、ユーザのdアカウントログイン有無や利用デバイスにより、API のアクセス数そのものが大きく変わります。ライブ配信などによるスパイクアクセス時の最大負荷を計算し、実際に負荷をかけて検証していくなかで、このデータストア選定、テーブル設計で問題ないか確認し、ボトルネックを洗い出しておくことが重要です。 4.Leminoで主に利用しているデータストア Lemino のシステムは映像そのものを配信する部分や dアカウントログイン、月額サービス契約導線やクレジットカード決済など様々なサービスで構成されていますので、ここで紹介するデータストアはあくまで Web やモバイルのアプリケーションのバックエンドで利用している一例です。AWSのマネージドサービスを活用することで、データベースそのものの学習コストは少なく済み、複数種類のデータベースを併用しても問題なく運用できています。 Amazon DynamoDB あらゆる規模で一桁ミリ秒のパフォーマンスを実現する、サーバーレス NoSQL フルマネージドデータベース。秒間数十万の高い読書き性能が必要、かつ、PK でのクエリでほとんどの要件が満たせるデータを管理。 ※ 各種セッション情報、および、ユーザーデータを管理 ※ 特定レコードに負荷が集中する場合は DynamoDB Accelerator (DAX) を利用 Amazon OpenSearch Service リアルタイム検索のスケールアウトをマネージドに実現できるマネージドサービス。高い読込み性能が必要で、かつ、複数のキーで検索が必要なデータを管理。 ※ コンテンツデータやエモートラインなど、検索用データを管理 Amazon Aurora PostgreSQL PostgreSQL との完全な互換性を持ち、グローバル規模で活用されている高パフォーマンスと可用性を実現する RDBMS のマネージドサービス。 複数テーブルを結合したトランザクション管理が必要なデータを管理 ※ ログイン済みの会員データ、月額契約・購入情報、集計用アーカイブを管理 図3. Lemino のアーキテクチャ概要 5.まとめ 第一回の事例では、パフォーマンスと機能面のスケーラビリティを確保するために Lemino の開発で実施した、適切なデータストアの選定とアーキテクチャの見直し方法をご紹介しました。 スパイクアクセスに耐え、アジリティ向上を目指してリアーキテクトを検討中の皆様の参考にしていただければ幸いです。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当 松原拓也 株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 津和﨑美希 通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様の AWS活用 を支援していますが、Observability については AWS 社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Service のご支援にも手を広げるなど、幅広い AWS 活用をご支援しています。
こんにちは、ソリューションアーキテクトの金澤( @ketancho )です。 今年もあっという間に半分が終わってしまい、7月に入ってしまいましたが皆さまいかがお過ごしですか?私は年始に掲げた目標のうち、このままだと達成できなそうなものが幾つかあるので、いよいよアクセルベタ踏みで頑張らなければと思っています。毎日コツコツやっていきたいものです。 さて、「今年の目標」と書きましたが、2024 年の目標として「AWS を使い始める」や「AWS 力を上げていきたい」を掲げた方、あるいは身近な方でそれを掲げられている方はいらっしゃいませんでしょうか?そのような皆さまにおすすめなイベント AWS Builders Online Series が今月 7/18(木) に開催されます。 &gt;&gt; AWS Builders Online Series のお申し込みはこちらから Builders Online はどんなイベント? AWS Builders Online Series は、初心者を対象とした AWS の基礎を幅広く学ぶことができるオンラインイベントです。「初学者を対象とした」と書きましたが、既に AWS をご利用のお客様も、最新情報を取り入れ基礎から解説いたしますので、これまで触れたことのないサービスのキャッチアップにもってこいだと考えています。 今回の Buiilders Onilne では、AWS 基礎、生成 AI、モダンアプリケーション開発の 3 つのテーマにフォーカスし、ゼロから学べるよう構成いたしました。デモを交えた分かりやすい説明により、すぐに実践に役立つ知識を習得していただきます。本イベントは、全てのセッションがライブ配信され、リアルタイムで皆様の質問に回答します。 最初のテーマは、AWS 基礎「90 分で学ぶ!AWS 超入門 2024」 今週から3週に渡り、この3つのテーマごとに Builders Online の見どころをリレー形式で紹介していこうと思います。まずは、 AWS 基礎 「90 分で学ぶ!AWS 超入門 2024」 の3つのセッションについて紹介いたします! 「AWS 基礎」テーマで想定している参加者の方々 冒頭で少し触れたようなこれから AWS を活用していきたいという方や、一部のサービスは使ったことがあるものの他にも基本的なサービスについてもっと詳しくなりたい!という方をペルソナとしてセッションを考えています。例えば、4月から IT エンジニアになられた方をお迎えする最初の Builders Online シリーズになりますので、その皆さまの「AWS はじめの1歩」となるような内容にしたいと考えています。 また、ご自身のチームメンバーの方や組織の方にもっと AWS をキャッチアップしてほしい!という方にもおすすめです。そのような方にご紹介いただくのもありがたいですし、「AWS 基礎」の内容を社内用にアレンジして、社内勉強会の題材にしていただくような使い方もできるかもしれません。AWS には現在 240 を超えるサービスがありますが、後述するように「AWS 基礎」テーマでは、10以内に収まる数のサービスに絞ってお届けすることを考えています。まずはスモールスタートのための時間となるような3セッションを考えています。 「AWS 基礎」テーマで予定している内容 「90 分で学ぶ!AWS 超入門 2024」は、下記の3部作で構成しようと考えています。 09:40 – 10:10 BOS-01: 90分で学ぶ!AWS 超入門 2024 #1 – さぁ!AWS をはじめよう! 概要: AWS のメリットや価値をお伝えしつつ、AWS アカウントを作成し、実際に手を動かすことができる環境を用意します。安全に AWS 環境を使っていくための基本のキについてもお伝えします。(学べるサービス: アカウント作成, IAM) 10:20 – 10:50 BOS-02: 90分で学ぶ!AWS 超入門 2024 #2 – さぁ!AWS を使ってみよう! 概要:最初の30分で作成したアカウントを使って、AWS サービスを実際に使っていきます。Amazon EC2 や Amazon VPC といった AWS を使っていく上でまず最初に理解したいサービスについて、実践形式でお伝えしていきます。(学べるサービス:Amazon VPC, Amazon EC2) 11:00 – 11:30 BOS-03: 90分で学ぶ!AWS 超入門 2024 #3 – さぁ!AWS を活用しよう! 概要:最後の30分は AWS を使っていく上でご理解いただきたい、「マネージドサービスの利点」と「単一障害点をなくす設計を心がける」をテーマに送ります。ここまでの構築をよりよく変更しながら、AWS のメリットを享受できる考え方を持ち帰っていただきます。(学べるサービス:Amazon RDS, ELB, WordPress, 口頭のみ(RDS MultiAZ, Auto Scaling)) 90分のうち、いわゆる資料を使った座学のパートは極力少なくし、その分視覚的にイメージしやすいデモやホワイトボーディングの割合を増やせるように検討しています。このような登壇でホワイトボーディングをするのは初めてで、私にとってもチャレンジになりますが、少しでも学びに繋がる時間にできればと考えています。 今後の AWS の学び方にも触れられればと考えておりますので、これらのセッションで皆さまの AWS ジャーニーのはじめの一歩を踏み出していただければ幸いです。 まとめ 7/18 に開催される AWS Builders Online Series の紹介と、午前中に行う最初のテーマである AWS 基礎 「90 分で学ぶ!AWS 超入門 2024」 の概要についてお伝えいたしました。今回の Builders Online は 「生成 AI 実践入門」「モダンアプリケーション開発の基礎」 という後続のテーマもございます。これらについては、来週以降またこちらの AWS 公式ブログからご案内させていただきますので、楽しみにお待ちいただければと思います。 それでは、当日皆さまにお会いできることを楽しみにしています! &gt;&gt; AWS Builders Online Series のお申し込みはこちらから このブログの著者 金澤 圭 (Kei Kanazawa) @ketancho サーバーレスが好きなソリューションアーキテクト。業種業界問わず、お客様のプロダクト開発をサポートさせていただいています。楽しく学べるコンテンツを考えるのが好きで、「 AWS Hands-on for Beginners 」、「 AWS ドリル連載@builders.flash 」といった企画・連載に携わっています。好きなサービスは AWS Lambda で、好きな休日の過ごし方は子どもたちと川の字になって昼寝をすること、家族と国内の津々浦々な場所に旅行に行くことです。