本記事は 2026 年 03 月 31 日 に公開された “ Enabling nested transactions in Amazon DynamoDB using C# ” を翻訳したものです。翻訳は Solutions Architect の嶋田 朱里が担当しました。 Amazon DynamoDB は、あらゆる規模の高性能アプリケーション向けに設計された、フルマネージド型のサーバーレス NoSQL データベースサービスです。この記事では、C# を使用して DynamoDB で ACID (原子性、一貫性、分離性、永続性) 準拠のトランザクションを管理するフレームワークを紹介します。このフレームワークは、ネストされたトランザクションのサポートを特徴としています。この機能により、.NET アプリケーション内でデータの一貫性とエラー処理をより細かく制御しながら、洗練されたロジックを実装できます。このネストされたトランザクションフレームワークを使用すると、問題を分離し、部分的なロールバックを可能にし、DynamoDB の組み込みトランザクション機能の上に保守可能でモジュール化されたワークフローを構築できます。 トランザクションフレームワークのおさらい ネストされたトランザクションに入る前に、このトランザクションフレームワークが何をするのかを簡単に振り返りましょう。 Amazon DynamoDB トランザクションフレームワーク は、DynamoDB の組み込みトランザクション機能を使った作業を効率化する C# ライブラリです。このフレームワークは以下を提供します。 トランザクションのライフサイクル (開始、コミット、ロールバック) を管理する TransactScope クラス 複数の DynamoDB テーブルにわたる ACID 準拠の操作の効率化 DynamoDB の TransactWriteItems および TransactGetItems API の低レベルの詳細 (複数のネストされたレベルにわたるトランザクションの調整やリクエストの構築など) を管理する抽象化レイヤー フレームワークに組み込まれたエラー処理と再試行ロジック このフレームワークは、複数の関連するデータアイテムを扱う場合でも、データの一貫性を維持する信頼性の高いアプリケーションの構築を支援します。在庫管理、金融取引、ユーザープロファイルの更新、または複数の DynamoDB 操作が単一のユニットとして成功または失敗する必要があるあらゆる状況で使用できます。 ネストされたトランザクションが重要な理由 ネストされたトランザクションにより、トランザクション操作を親トランザクションのスコープ内に存在させることができます。この機能は、エンタープライズグレードのシステムにおける柔軟性と堅牢性を向上させます。たとえば、システム内のモジュール化されたコンポーネントは、親トランザクション構造に影響を与えることなく独自のロジックをカプセル化でき、プロセスの一部で問題が発生した場合に部分的なロールバックを実行できます。エラーの影響範囲を発生元のトランザクション内に閉じ込めることで、ネストされたトランザクションはトランザクション全体の失敗のリスクを軽減し、フォールトトレランスを向上させ、システムのデバッグと保守をより容易にします。 サンプルアプリケーションの概要 ネストされたトランザクションを実際にどのように使用できるかを示すために、フレームワークの機能を紹介する サンプル Windows Forms アプリケーション を作成しました。このアプリケーションでは、複数レベルのネストされたトランザクションを通じてトランザクションの整合性を維持しながら、さまざまな製品タイプに対して一般的なデータ操作 (作成、削除、取得) を実行できます。 このサンプルアプリケーションは、ネストされたトランザクションが特に有効な、いくつかの一般的なシナリオを想定して作られています。 複雑なビジネスワークフロー : 複数の関連アイテム (e コマースの注文プロセスやコンテンツ管理の更新など) に変更を加える必要がある場合 エラーの分離 : プロセス全体をロールバックすることなく、特定の操作グループ内で障害を封じ込めたい場合 モジュール化されたシステム統合 : システムのさまざまなコンポーネントが独自のトランザクションコンテキストを維持する必要がある場合 次の画像の UI アプリケーションは、ネストされたトランザクションフレームワークを使用する DynamoDB Transaction Example というタイトルのフォームを提供します。これは、ネストされたトランザクションの仕組みを使って書籍、アルバム、映画を管理します。 主要な手順の流れは次のとおりです。 書籍、アルバム、映画用の DynamoDB テーブルを初期化するには、 Create Product Tables (Book, Album, Movie) を選択します。これは通常、管理者として処理する 1 回限りのセットアップ手順です。 テーブルが配置されたら、 Product Type ドロップダウンメニューから Album 、 Book 、または Movie を選択します。この選択により、フォームフィールドが製品の属性に合わせてカスタマイズされます。たとえば、 Album を選択すると Album Artist と Title の入力が求められ、 Movie では Director と Genre が求められます。 対応する製品の詳細を入力します。これらの詳細は、選択した製品カテゴリによって異なります。たとえば、書籍には著者名、タイトル、およびオプションで出版日が必要であり、映画には監督名、タイトル、ジャンルが必要です。フォームでは、製品エントリの追加、削除、取得を含むトランザクション操作を実行するオプションが提供されます。 このアプリでは、ネストされたトランザクションを使用して、複数のトランザクションを開始し、それぞれのトランザクション内でアイテムの追加や削除を行い、個別にコミットまたはロールバックできます。また、ネストされたトランザクションフレームワークの動作を確認できるよう、親トランザクションと子トランザクションの間を行き来できるナビゲーション機能も備えています。これにより、どの操作をどのトランザクションにまとめるかを細かく制御できます。現在のトランザクションの階層は括弧内の数字で表示され (たとえば、 Transaction (1) )、 Commit Transaction や Rollback Transaction などの操作は、現在の階層とその配下の子トランザクションに対して適用されます。 Album Artist や Title などのキーを提供することで、オプションで製品データを取得できます ( Retrieve Item を選択)。すべての応答 (成功メッセージ、エラー通知、または取得されたデータ) は、 Response Message フィールドと対応する製品属性ボックスに表示されます。 次の図は、DynamoDB でのネストされたトランザクションのシーケンスフローを示しています。親と子のトランザクションスコープがどのように相互作用して分離されたアトミック操作を提供するかを示しています。 フレームワークアーキテクチャ このフレームワークは、 TransactScope クラスを強化し、Composition や Chain of Responsibility などのデザインパターンを採用することで、ネストされたトランザクションをサポートします。 コミット操作は後入れ先出し (LIFO) の順序に従い、親の前に子の TransactScope を処理します。また、ロールバック操作も下位へと順次伝播するため、障害発生時には完全にクリーンアップされます。このシステムはスコープ間の双方向移動を可能にし、複雑なトランザクションフローの管理をより簡単にします。 アーキテクチャの適用性に関する注意: ここで提示されるフレームワークアーキテクチャ設計は、上記のサンプルアプリケーションでは C# で実装されていますが、他のすべてのオブジェクト指向プログラミング言語とプラットフォームに適用され、設計原則の幅広い適用性を保証します。 次の図は、カスタム TransactScope クラス構造を使用したネストされたトランザクションモデルを示しています。 _transactRequest プロパティは TransactWriteItemsRequest を保持し、DynamoDB の複数の書き込み操作 (Put、Update、Delete) を単一のトランザクションにバッチ処理するために使用されます。 _childTransactScope は TransactScope (具体的には子スコープ) を指し、この TransactScope 内にネストされたトランザクションが存在することを示します。逆に、 _parentTransactScope は親の TransactScope を指し、トランザクション間の親子関係を確立します。 レイヤードアーキテクチャ アプリケーションでネストされたトランザクションフレームワークを効果的に使用するには、そのレイヤードアーキテクチャを理解することが役立ちます。この設計は責務の分離を提供し、コードの保守性とテストのしやすさを向上させます。アーキテクチャは 4 つの主要なレイヤーで構成されています。 UI レイヤー : Windows Forms インターフェイスは、トランザクションの開始と管理のエントリポイントとして機能します。サービスレイヤーのメソッドを呼び出して、BeginTransaction()、CommitTransactionAsync()、RollbackTransaction() を実行し、トランザクションのライフサイクルを制御します。 サービスレイヤー : ProductService や TransactScope を含むこのレイヤーは、トランザクションのオーケストレーションを管理します。ネストされたスコープ間を作成およびナビゲートし、トランザクションロジックを一元化します。これは、トランザクション管理コードの大部分が存在する場所です。 データアクセスレイヤー : ここで、 ProductProvider は、サービスレイヤーによって提供されるトランザクションコンテキスト内で、挿入や削除などのデータ操作を実行します。このレイヤーで、ドメインオブジェクトの特定のデータアクセスロジックを実装します。 DynamoDB : 最下層では、DynamoDB が組み込みトランザクション API ( TransactWriteItems ) を通じてアトミックな実行をサポートし、すべての操作が成功するか、いずれも成功しないことを保証します。 設計のハイライト ワークフローは、使いやすさと堅牢性を向上させるコア機能を備えて設計されており、主に Begin/Commit/Rollback 構造を通じて実現されています。これにより、操作をアトミック (すべて成功するか、いずれも成功しない) にすることで、DynamoDB でのトランザクションの整合性と一貫性が保証されます。さらに、ネストされたトランザクションを使用する機能により、親スコープと子スコープを簡単に切り替えることで、より複雑でモジュール化されたワークフローが可能になります。 インターフェイスは、アクションを追跡するのに役立つ動的なフィードバックも提供します。トランザクションの深さインジケーター (括弧内に表示) は、操作がステージングされるにつれて更新され、ワークフローの現在の状態に関する明確な洞察を提供します。最後に、システムは統一されたインターフェイス内で複数の製品タイプ (書籍、アルバム、映画) をサポートします。これにより、同じトランザクションスコープ内で複数の DynamoDB テーブルにわたってアイテムを追加、削除、取得できます。サービスレイヤーでの一元化されたトランザクション管理により、責任が明確に分離され、DynamoDB が原子性を提供します。このレイヤードアプローチは、実世界のアプリケーションに必要な柔軟性を提供しながら、保守性を向上させます。 ネストされたトランザクションのベストプラクティス アプリケーションでこの設計を最大限に活用するには、次の実用的なガイドラインに従ってください。 DynamoDB の制限に注意する – DynamoDB の制限 (100 アイテム、トランザクションあたり 4 MB) 内に収まるように、トランザクションを短く保ちます。それに応じてデータモデルを計画してください。 再試行ロジックを実装する : DynamoDB トランザクションは、条件チェック、競合、または容量の問題により失敗する可能性があります。指数バックオフを使用した効果的な再試行メカニズムをアプリケーションに組み込んでください。 パフォーマンスを監視する : Amazon CloudWatch アラームを設定して、トランザクション競合率、レイテンシー、例外などのトランザクションメトリクスを追跡し、ボトルネックを早期に特定します。 ネストの深さを制限する : ネストされたトランザクションは柔軟性を提供しますが、過度のネスト (3 〜 4 レベルを超える) は、デバッグと保守が困難な過度に複雑な実行パスを作成する可能性があります。 実世界のユースケース フレームワークを理解したところで、独自のアプリケーションでネストされたトランザクションを適用できるいくつかの実用的なシナリオについて説明しましょう。 e コマースの注文処理 : 顧客が注文を行う場合、在庫レベルの更新、支払い情報の処理、注文レコードの作成が必要になる場合があります。ネストされたトランザクションを使用すると、支払い処理をサブトランザクションに分離でき、支払いが失敗した場合に独立してロールバックできます。 複数ステップのユーザー登録 : 初期ユーザープロファイルの作成、セキュリティ検証、アカウントの最終化など、複数の検証ステップを含む複雑な登録プロセスがアプリケーションに必要な場合、ネストされたトランザクションを使用して各段階の進行状況を追跡しながら、必要に応じて特定のステップをロールバックする機能を維持できます。 コンテンツ管理システム : 複数の関連エンティティ (記事、著者、カテゴリなど) への更新を必要とするコンテンツを公開する場合、ネストされたトランザクションは、特定のドメイン内で部分的な操作を可能にしながら一貫性を維持するのに役立ちます。 金融アプリケーション : 複数のアカウントや金融商品を含む操作の場合、ネストされたトランザクションは、アカウント管理コンテキスト、トランザクション処理コンテキスト、データ整合性コンテキストなどの特定の操作コンテキストを分離しながら、一貫性を提供するために必要なきめ細かい制御を提供します。 まとめ この記事では、C# を使用した Amazon DynamoDB でのネストされたトランザクションフレームワークを紹介しました。これにより、トランザクションワークフローでの制御と堅牢性が向上します。 TransactScope クラスを拡張することで、このソリューションは、コミットとロールバックの動作をより細かく制御しながら、複雑でモジュール化されたビジネス操作をモデル化する柔軟性を提供します。構造化された UI ワークフローと、UI レイヤー、サービスレイヤー、データアクセスレイヤーにまたがるレイヤードアーキテクチャは、すべての製品関連操作にわたってトランザクションの整合性、分離性、一貫性を提供します。 この実装の完全なソースコードは、 GitHub リポジトリ で入手できます。 著者について Jeff Chen Jeff は、AWS Professional Services のプリンシパルコンサルタントであり、生成 AI を活用したアプリケーションのモダナイゼーションと移行プロジェクトを通じて顧客を支援することを専門としています。生成 AI 以外にも、DevOps、データ分析、インフラストラクチャプロビジョニング、セキュリティなど、さまざまなドメインにわたってビジネス価値を提供し、組織が戦略的なクラウド目標を達成できるよう支援しています。

本記事は 2026 年 4 月 3 日 に公開された「 Introducing OpenTelemetry & PromQL support in Amazon CloudWatch 」を翻訳したものです。 Kubernetes やマイクロサービスのワークロードを AWS で実行している場合、メトリクスには namespace、pod、container、node、deployment、replica set、カスタムのビジネスディメンションなど、多数のラベルが付いているでしょう。環境全体を把握するために、メトリクスパイプラインを分割しているケースも多いはずです。AWS メトリクスには Amazon CloudWatch を使い、高カーディナリティ (多数のラベルの組み合わせを持つ) なコンテナやアプリケーションのメトリクスには別の Prometheus 互換バックエンドを使う、といった具合です。さらに進んだチームでは、Prometheus CloudWatch エクスポーターで GetMetricData API を呼び出し、AWS リソースメトリクスを Prometheus バックエンドに取り込んでいることもあります。運用負荷とコストは増えますが、すべてを一箇所でクエリできるようになります。 Amazon CloudWatch で OpenTelemetry メトリクス のネイティブ取り込みと、 Prometheus Query Language (PromQL) によるクエリがサポートされました。このプレビュー機能では、メトリクスあたり最大 150 ラベルをサポートする高カーディナリティメトリクスストアが導入され、ラベルの多いメトリクスを変換や切り捨てなしで CloudWatch に直接送信できます。AWS Vended メトリクスの自動エンリッチメントと組み合わせることで、CloudWatch がインフラストラクチャ、コンテナ、アプリケーションメトリクスの一元的な送信先になり、すべて PromQL でクエリできるようになりました。 本記事では、以下の内容を説明します。 AWS アカウントで OpenTelemetry メトリクスの取り込みと AWS リソースの自動エンリッチメントを有効化する方法 Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに Amazon CloudWatch Container Insights をデプロイする方法 Amazon CloudWatch と Amazon Managed Grafana で PromQL を使ってインフラストラクチャと AWS リソースのメトリクスをクエリする方法 OpenTelemetry SDK でカスタムアプリケーションメトリクスを作成し、AWS コンテキストで自動エンリッチメントされる様子 CloudWatch における OpenTelemetry サポートが何を意味するか OpenTelemetry Protocol (OTLP) は、OpenTelemetry (OTel) プロジェクトの標準ワイヤープロトコルです。メトリクス、トレース、ログを含むテレメトリデータのエンコードとコンポーネント間の転送方法を定義しています。このプレビューにより、CloudWatch は OpenTelemetry 互換のコレクターや SDK がメトリクスを送信できるリージョナル OTLP エンドポイントを公開します。 CloudWatch はメトリクスを受信し、新たな高カーディナリティのメトリクスストアに保存します。カウンター、ヒストグラム、ゲージ、アップダウンカウンターなどの OpenTelemetry メトリクスタイプは変換なしでそのまま保持されます。今回のリリースで、CloudWatch はオブザーバビリティの 3 本柱すべてで OpenTelemetry をサポートするようになりました。CloudWatch はすでに OTLP エンドポイント 経由でトレースとログを受け付けており、ネイティブ OTLP メトリクス取り込みが加わったことで、すべてのテレメトリをオープンスタンダードで、単一のプロトコルを通じて CloudWatch に送信できるようになりました。3 つの機能がこのことを重要にしています。 拡張されたラベルとカーディナリティのサポート OTLP で取り込まれたメトリクスは最大 150 ラベルをサポートし、CloudWatch カスタムメトリクスの 30 ディメンション制限を超えています。Kubernetes、マイクロサービス、OpenTelemetry ワークロードでフィルタリングや集計に高カーディナリティラベルを使う際の主要な制約が解消されます。制限は今後も進化するため、最新情報は クォータページ をご確認ください。 PromQL クエリのサポート OTLP 経由で取り込んだメトリクスを PromQL でクエリできます。すでに Prometheus を使っている場合、同じクエリ言語を CloudWatch や Amazon Managed Grafana で直接使えます。新しい構文を覚える必要はありません。 AWS リソースの自動エンリッチメント この機能により、AWS インフラストラクチャ全体でメトリクスをクエリ・フィルタリングする方法が根本的に変わります。CloudWatch は取り込んだすべてのメトリクスに AWS リソースコンテキスト (アカウント ID、リージョン、クラスター Amazon Resource Name (ARN)、AWS Resource Explorer からのリソースタグ) を付与します。このエンリッチメントは追加の計装なしで自動的に行われます。Container Insights、カスタムアプリケーション、AWS サービスのいずれから来たメトリクスでも、AWS アカウント、リージョン、環境タグ、アプリケーション名でフィルタリングやグループ化ができます。エクスポーター不要、カスタムラベル不要、追加の API 呼び出し不要です。 図 1: Amazon CloudWatch における OpenTelemetry メトリクスの取り込みとエンリッチメントアーキテクチャ OTLP 取り込みと AWS リソースエンリッチメントの有効化 OTLP メトリクスを取り込んでクエリする前に、2 つのアカウントレベルの設定を有効にします。1 つ目は、AWS Resource Explorer で確認できるものと同じリソースタグをテレメトリに伝播させる設定です。2 つ目は、CloudWatch の OTLP 取り込みを有効にする設定です。 両方のエンリッチメント設定は、Amazon CloudWatch コンソールまたは AWS CLI から有効にできます。 コンソールを使用する場合 CloudWatch コンソールでエンリッチメントを有効にする手順は以下のとおりです。 Amazon CloudWatch コンソールを開きます。 ナビゲーションペインで 設定  を選択します。 リソースタグのテレメトリへの伝播を有効にします。 AWS メトリクスの OTel エンリッチメントを有効にします。 両方の設定を有効にすると、アカウントでリージョナルエンドポイントへの OTLP メトリクス受信の準備が整います。 図 2: CloudWatch コンソール設定での OTel エンリッチメントとリソースタグの有効化 AWS CLI を使用する場合 AWS CLI で両方のエンリッチメントレイヤーを有効にすることもできます。以下のコマンドを実行します。 # Enable resource tags on telemetry aws observabilityadmin start-telemetry-enrichment # Enable OTel enrichment for CloudWatch aws cloudwatch start-o-tel-enrichment 両方のエンリッチメント設定がアクティブであることを確認するには、以下のコマンドを実行します。 aws cloudwatch describe-o-tel-enrichment-status エンリッチメントを有効にすると、OTLP エンドポイント経由で取り込まれたすべてのメトリクスに AWS リソースコンテキストが自動的にタグ付けされます。CloudWatch が追加する属性は以下のとおりです。 Attribute 説明 例 @aws.account AWS アカウント ID 123456789012 @aws.region AWS リージョン us-west-2 cloud.resource_id EKS クラスターの完全な ARN arn:aws:eks:us-west-2:123456789012:cluster/prod k8s.cluster.name EKS クラスター名 production-cluster k8s.namespace.name Kubernetes namespace karpenter k8s.container.name コンテナ名 controller @instrumentation.name 計装ソース cloudwatch-otel-ci リソースタグ AWS Resource Explorer からのタグ (@aws.tag.Application、@aws.tag.CostCenter、@resource.ec2.tag.ManagedBy など) env=production これらの属性は CloudWatch によって追加され、手動の計装は不要です。カスタムパイプラインの構築やエクスポーターの実行なしに、AWS アカウント、リージョン、リソースタグをまたいでクエリできるのはこのためです。 OpenTelemetry メトリクスを使った Amazon CloudWatch Container Insights OpenTelemetry と CloudWatch の連携を実際に確認するため、Container Insights から始めましょう。Amazon EKS 向け Amazon CloudWatch Container Insights で Prometheus と OpenTelemetry メトリクスが サポートされました 。コンテナメトリクスが OpenTelemetry attribute で標準化され、PromQL でクエリできるようになります。Container Insights は、コンソールまたは AWS CLI から Amazon EKS アドオンを使って 有効化 できます。 Container Insights ダッシュボード Container Insights をデプロイすると、CloudWatch は CPU 使用率、メモリ使用量、Pod 数などのクラスターレベルのメトリクスを表示するダッシュボードを自動的に作成します。ダッシュボードを表示するには、CloudWatch コンソールを開き、ナビゲーションペインから Container Insights を選択し、ドロップダウンからクラスターを選択します。クラスター、namespace、Pod レベルのビューを切り替えて、特定のワークロードを詳しく確認できます。 図 3: Amazon CloudWatch Container Insights ダッシュボード CloudWatch Query Studio で PromQL を使ってメトリクスをクエリする OTLP で取り込んだメトリクスは、CloudWatch コンソール、Amazon Managed Grafana、または PromQL と AWS Signature Version 4 (SigV4) をサポートするクエリインターフェースで PromQL を使ってクエリできます。 CloudWatch Query Studio には、コンソールで直接メトリクスを探索・可視化するための PromQL エディターが組み込まれています。PromQL クエリモードを選択して開始します。 図 4: PromQL クエリモードの Amazon CloudWatch Query Studio インターフェース エンリッチされた AWS リソースコンテキストを使ったクエリ エンリッチメントが有効になっているため、CloudWatch が自動的に追加するタグを使って AWS リソースの境界を越えてクエリできます。エクスポーター不要、カスタムラベル不要です。 # AWS Lambda function duration for functions tagged with application "order-pipeline" Duration{"@aws.tag.appname"="order-pipeline"} # Amazon EC2 CPU utilization for production delivery workloads CPUUtilization{"@aws.tag.Environment"="production", "@aws.tag.Application"="delivery"} # Running pods grouped by AWS account and namespace sum by (aws_account_id, k8s_namespace_name) (kube_pod_status_phase{phase="Running"}) 最後のクエリは、カスタム計装なしで AWS アカウントと Kubernetes namespace ごとにグループ化された実行中の Pod 数を返します。 aws_account_id ラベルはエンリッチメントレイヤーによって自動的に追加されます。 図 5: Lambda duration メトリクスをクエリする CloudWatch Query Studio Grafana で PromQL を使ってメトリクスをクエリする Amazon Managed Grafana で OTLP 取り込みメトリクスを可視化するには、CloudWatch PromQL エンドポイントを指す Prometheus データソースを追加します。このセクションでは、AWS Signature Version 4 (SigV4) 認証でデータソースを設定する手順を説明します。 Amazon Managed Grafana ワークスペースを開きます。 Data Sources を選択します。 Add data source を選択します。 データソースタイプとして Prometheus を選択します。 URL には、リージョンの CloudWatch PromQL エンドポイントを入力します: https://monitoring.<AWS Region>.amazonaws.com/v1/metrics Authentication で SigV4 を選択します。 SigV4 認証用の適切な IAM ロールを設定します。 Save & Test を選択して接続を確認します。 Save & Test が成功すると、「Data source is working」という確認メッセージが表示されます。失敗した場合は、IAM ロールに cloudwatch:GetMetricData と cloudwatch:ListMetrics の権限があること、SigV4 署名が正しく設定されていることを確認してください。 データソースを設定すると、Grafana ダッシュボードで同じ PromQL クエリを使用できます。 図 6: CloudWatch PromQL を使った Grafana Explore カスタムアプリケーションメトリクス CloudWatch OTLP 取り込みはカスタムアプリケーションメトリクスもサポートしています。OpenTelemetry SDK で計装されたアプリケーションは、クラスターで実行中の CloudWatch エージェント経由でメトリクスを送信でき、計装コードの変更は不要です。 実際の動作を確認するため、 aws-otel-community リポジトリからサンプル Python アプリケーションをデプロイします。このアプリケーションは OpenTelemetry Python SDK を使用して、カウンター、ヒストグラム、ゲージ、アップダウンカウンターなど、すべての OTel メトリクスタイプをカバーするカスタムメトリクスを出力します。例えば、アプリは API レスポンス時間を測定する latency_time ヒストグラムを定義しています。 from opentelemetry import metrics meter = metrics.get_meter(__name__) # Histogram --- measures API latency distribution latency_time = meter.create_histogram( name="latency_time", description="Measures latency time", unit="ms", ) サンプルアプリケーションのデプロイ サンプルアプリケーション とすべてのデプロイマニフェストは、GitHub の aws-otel-community リポジトリにあります。先ほどデプロイした Container Insights アドオンには、OpenTelemetry コレクターとして機能する CloudWatch エージェントが含まれています。 OTEL_EXPORTER_OTLP_ENDPOINT 環境変数を設定して、サンプルアプリをエージェントに向けます: http://cloudwatch-agent.amazon-cloudwatch.svc.cluster.local:4317 このウォークスルーでは CloudWatch エージェントを使用していますが、OTLP/HTTP をサポートする任意の OpenTelemetry 互換コレクターや SDK を使用して、CloudWatch OTLP エンドポイントに直接メトリクスを送信できます。 PromQL でアプリケーションメトリクスをクエリする アプリケーションをデプロイしたら、CloudWatch Query Studio を開くか、Amazon Managed Grafana ワークスペースで Explore に移動し、CloudWatch PromQL データソースを選択します。 以下のクエリは、Amazon Managed Grafana でデモアプリの p99 レイテンシーを、自動エンリッチされた @aws.region ラベルでグループ化して表示します。 histogram_quantile(0.99, sum by (le, aws_region) (rate(latency_time_bucket{resource_service_name="python-demo-app"}[5m])))` 図 7: Amazon Managed Grafana でのサンプルアプリケーションの P99 レイテンシー エンリッチメントが有効になっているため、すべてのアプリケーションメトリクスに AWS リソースコンテキストが自動的に付与されます。例えば、 cpu_usage をクエリすると、追加の計装なしで以下のラベルが返されます。 図 8: カスタム OTel 計装からのエンリッチされた全ラベルの表示 料金 OTLP 取り込み機能と PromQL クエリは、プレビュー期間中は追加料金なしで利用できます。現在の料金の詳細については、Amazon CloudWatch の 料金ページ をご覧ください。 このウォークスルーで使用した Amazon EKS と Amazon Managed Grafana のリソースは、標準料金で課金されます。継続的な課金を避けるため、ウォークスルー終了後は次のセクションのクリーンアップ手順に従ってください。 クリーンアップ サンプルアプリケーションを削除します。 kubectl delete -f demo-app.yaml EKS クラスターから Amazon CloudWatch Observability アドオンを削除します。 aws eks delete-addon \ --cluster-name \ --addon-name amazon-cloudwatch-observability Grafana ワークスペースから Prometheus データソースを削除します (Grafana コンソールにログインし、Data Sources に移動して、設定した CloudWatch PromQL データソースを削除します)。 Amazon Managed Grafana ワークスペースを削除します (このウォークスルー用に作成した場合のみ)。 aws grafana delete-workspace --workspace-id Amazon EKS クラスターを削除します (このウォークスルー用に作成した場合のみ)。 aws eks delete-cluster --name OTel エンリッチメントを無効にします (アカウントで不要になった場合)。 # Disable OTel enrichment aws cloudwatch stop-o-tel-enrichment # Disable telemetry enrichment aws observabilityadmin stop-telemetry-enrichment このウォークスルー用にアタッチした IAM ポリシーをデタッチします。 aws iam detach-role-policy \ --role-name \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy まとめ 本記事では、Amazon CloudWatch でのネイティブ OpenTelemetry メトリクス取り込みについて説明しました。エンリッチメントレイヤーの有効化、Amazon EKS への Container Insights のデプロイ、OpenTelemetry SDK でのカスタムアプリケーションメトリクスの送信、PromQL でのクエリを紹介しました。 このプレビュー機能により、メトリクスパイプラインを CloudWatch に統合できます。拡張されたラベル制限を持つ高カーディナリティメトリクス、PromQL クエリ、AWS リソースの自動エンリッチメントが連携し、インフラストラクチャメトリクス、コンテナメトリクス、アプリケーションメトリクスがすべて同じパイプラインを流れ、同じ AWS リソースコンテキストを持つようになります。別々のバックエンド、エクスポーター、AWS メトリクスを統合ビューに取り込むための追加 API 呼び出しは不要です。 OpenTelemetry を使ったアプリケーションレベルの計装の実践例については、以下のリソースをご覧ください。 AWS Observability Best Practices Guide:  OpenTelemetry SDK でアプリケーションを計装するパターン One Observability Workshop : AWS でのメトリクス、トレース、ログのハンズオンラボ AWS Observability Accelerator: テレメトリ収集とクエリを自動化する CDK パターンと Terraform モジュール プレビューは、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) で追加料金なしで利用できます。開始するには、アカウントでエンリッチメントレイヤーを有効にし、Amazon EKS クラスターに CloudWatch Observability アドオンをデプロイしてください。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Rodrigue Koffi AWS のオブザーバビリティ担当スペシャリストソリューションアーキテクトです。オブザーバビリティ、分散システム、機械学習に情熱を持っています。DevOps とソフトウェア開発のバックグラウンドがあり、Go でのプログラミングを好みます。仕事以外では、水泳や家族との時間を楽しんでいます。LinkedIn: /grkoffi

みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 日々のお客様との会話の中で、「業務課題を解決するために新たな機能やシステムの開発が必要ではあるが、外部リソースを確保する余力もなく、自社に十分なエンジニアもいないため実現が難しい」というお声をいただきます。同様のお悩みをお持ちの方も少なくないのではないでしょうか。 近年、そういった状況に対して、 Amazon Bedrock や Amazon Q Developer をはじめとする AWS の生成 AI サービスの登場により、限られた開発リソースの中でも、業務を最もよく知る現場の担当者自身が課題解決の仕組みを構築できる環境が整いつつあります。 今回は、まさに生成 AI を活かし、非エンジニアのメンバーが中心となって契約書管理 AI エージェントを構築された大成株式会社様の事例をご紹介します。本事例では、Amazon Q Developer によりプログラミング経験が限られたメンバーでも AWS 上でのシステム構築が可能となり、さらに Amazon Bedrock を利用することでインフラ構築や運用管理なしに Claude のような高性能な基盤モデルを API 一つで呼び出せるため、従来手作業で数十分かかっていた情報抽出を数分に短縮する仕組みを短期間で実現いただきました。 お客様の状況と経緯 大成株式会社様（以下、大成様）は、「ビルトータルソリューション」を掲げ、ファシリティマネジメント、プロパティマネジメント、不動産投資事業、修繕工事や改修工事などの建築事業を展開する総合サービス企業です。 大成様のプロパティマネジメント業務では、ビルオーナー様やテナント様との間で締結される多数の契約書が業務の根幹をなしています。しかしながら、従来の契約書管理では、以下の課題が存在していました。 契約書の検索が手作業に依存しており、必要な情報を見つけるために複数の PDF を開いて目視で確認する必要がある テナント様ごとに契約内容の仕様が異なるため、ビル名やテナント名だけでは目的の契約書にたどり着けない場合がある ビルオーナー様からの問い合わせに対し、契約書の特定から情報確認、回答までに多くの時間を要し、迅速な顧客対応の妨げとなっている これらの課題を解決するため、業務改善やシステム利活用を担当している IT 戦略推進室が本取り組みに参加しました。大成様では社内 SE、内製開発を行うエンジニアを擁していないため、同部にて生成 AI を活用した契約書管理システムの構築を検討されることになりました。 ソリューション／構成内容 本プロジェクトでは、非エンジニアのプロジェクトマネージャーが中心となり、Amazon Q Developer の支援を受けながらシステムを構築しました。Amazon Q Developer は自然言語での指示に基づいてコードを生成する AI アシスタントであり、プログラミング経験が限られた担当者でも実用的なシステムを構築できます。 本システムでは、Amazon Bedrock、 AWS Lambda 、 Amazon S3 、 Amazon DynamoDB を組み合わせて活用しています。Amazon Bedrock は生成 AI の中核を担い、Anthropic 社の Claude AI モデルを通じて契約書 PDF の解析と重要情報の抽出を実行します。 Amazon Bedrock + Claude を採用したポイントとして、Claude の高度な文書理解能力が挙げられます。契約書は法的な専門用語を含む複雑な文書であり、テナント様ごとにフォーマットが異なりますが、Claude は PDF などの非構造化データから文脈を理解した上で必要な情報を正確に抽出できます。また、AWS Lambda を中心としたサーバーレスアーキテクチャにより、非エンジニアが中心のチームでもインフラ管理に煩わされることなくシステムを運用できる点、そして日常的に使用している Slack との統合が容易で導入時の移行障壁を低く抑えられる点も、AWS を選択された理由です。 導入効果 実際にご利用いただいた結果、以下のような効果が得られています。 契約書からの情報抽出にかかる作業時間を 約 70〜80% 削減 。従来 1 件あたり数十分を要していた作業が数分で完了 将来的には、CSV 形式でのデータ出力機能を実装し、契約書情報の一括管理および分析を可能とする仕組みの構築を検討 AI による解析で情報抽出の精度と一貫性が向上し、人手による見落としや誤読のリスクを低減 Slack 上のシンプルなワークフローにより、従業員の受け入れがスムーズに また、非エンジニアでも Amazon Q Developer の支援により AWS の各種サービスを組み合わせた実用的なシステムを構築できることが実証されたことにより、他の業務領域でも生成 AI を活用した業務改善の取り組みが始まるきっかけとなっています。 大成様では今回の成功を踏まえ、契約書の自動要約機能や自然言語での高速検索機能の追加を検討されています。さらに、施設管理報告書の自動生成やメンテナンス記録の分析など、プロパティマネジメント業務全般での AI 活用拡大も計画されています。 お客様の声 大成株式会社 IT 戦略推進室 石川 静華様からは、「AWS のサービスを使うことで非エンジニアでも実業務の課題を自らの手で解決できる喜びを実感しました。」とのコメントをいただいています。 まとめ 今回は大成様が Amazon Bedrock と Amazon Q Developer を活用し、非エンジニアの手で契約書管理 AI エージェントを構築された事例をご紹介しました。Claude の高度な文書理解能力とサーバーレスアーキテクチャの組み合わせにより、専門的な開発リソースがなくても実用的な業務改善システムを実現されています。スモールスタートで確実に成果を出すアプローチは、これから生成 AI 活用を検討される企業にとっても参考になる取り組みです。 生成 AI を活用した業務改善にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 大成様 IT 戦略推進室 推進課 課長　田島 宏美 IT 戦略推進室 戦略課 主任　石川 静華 IT 戦略推進室 推進課 主任　鎌倉 由佳 Account Team： ソリューションアーキテクト　森   瞭輔 アカウントマネージャー　植木　輝 記事執筆： ソリューションアーキテクト　古屋　楓