概要 Amazon CloudWatch Logs が Application Load Balancer (ALB) のログを Vended Logs としてサポート しました。これにより、ALB の健全性とパフォーマンスを追加の設定や開発なしで可視化できます。ALB の 3 種類のログ (アクセスログ、接続ログ、ヘルスチェックログ) は、いずれもフィールド名の付いた構造化 JSON として配信されます。そのため、5xx エラーの原因がロードバランサー側かアプリケーション側かを切り分ける、レイテンシー上昇の要因になっているルートを特定する、失敗しているヘルスチェックを診断する、といった対応がすぐに行えます。 Amazon S3 バケットの管理、 Amazon Athena のテーブル設定、独自の ETL パイプラインは一切不要です。 以下のダッシュボードは、リクエスト量とステータスコードの分布、ロードバランサーとターゲットのどちらに起因するかを切り分けたエラー傾向、ルートごとのレイテンシーパーセンタイル、ターゲットのヘルス状態、クライアント/ターゲットの上位ランキングを表示します。このダッシュボードは、本記事で提供する AWS CloudFormation テンプレート を使ってデプロイしたものです。 図 1: ロードバランサー全体のリクエスト量、エラー分析、レイテンシー内訳を表示する ALB Insights ダッシュボード はじめに AWS 上でエンドユーザーに公開されるワークロードの大半では、Application Load Balancer がリクエストパス上に配置されています。ALB はアプリケーションよりも先にすべてのリクエストを受け取るため、ターゲットに到達しなかったリクエストまで把握しています。サービスに問題が生じたとき、オンコールエンジニアが最初に抱く「これはロードバランサーの問題か、ネットワークか、それとも自分のアプリケーションか」という疑問に答えてくれるのが ALB のログです。 ALB は次の 3 種類のログを出力します。 アクセスログ 接続ログ ヘルスチェックログ 今回のリリース以前は、これらのログは圧縮されたスペース区切りファイルとして Amazon S3 に出力されていました。そのため、S3 のライフサイクルポリシーを管理し、ALB がフィールドを追加するたびに Athena テーブルを保守し、アラート用に別のインフラを構築する必要がありました。今後は ALB のレコードが VPC フローログ、AWS WAF ログ、アプリケーションログと同じ場所に届くため、CloudWatch Logs がすでに備えている機能をそのまま活用できます。具体的には、Log Analytics、メトリクスフィルター、Contributor Insights、Live Tail、異常検出、そしてクロスアカウント・クロスリージョンの集約です。 導入手順: 有効化とデプロイ このセクションでは、テレメトリ有効化ルール (Telemetry enablement rules) で ALB ログの配信を有効にし、提供している CloudFormation テンプレート でサンプルダッシュボードをデプロイするまでの手順を説明します。 ステップ 1: テレメトリ有効化ルールで ALB ログの取り込みを有効化する Amazon CloudWatch のテレメトリ有効化ルール を使うと、AWS リソースのテレメトリ収集を自動的に設定できます。ルールを使えば、組織全体でテレメトリ収集の方法を統一し、監視範囲を一定に保てます。1 つのルールは、スコープ内にある既存のロードバランサーと新しく作成されるロードバランサーの両方に配信設定を適用します。そのため、一度ロギングを有効にしておけば、デプロイパイプラインが後から作成するロードバランサーも自動的にカバーされます。 ALB ログの CloudWatch への取り込みを有効化する手順は次のとおりです。 管理アカウントまたは委任管理者アカウントで CloudWatch コンソール を開きます。 ナビゲーションペインで 取り込み 、続いて 有効化ルール を選択します。 ルールを追加 を選択します。 データソース で Amazon Elastic Load Balancer – アプリケーション を選択し、 テレメトリを設定 をクリックします。 ルール名 に分かりやすい名前 (例: ALB-Logs-Enablement ) を入力します。 ルールのスコープ で 組織 、 組織単位 、 アカウント のいずれかを選択します。 図 2: ステップ 1「範囲を指定」: ルール名、ソースアカウント、オプションのデータソースタグ、対象リージョン ロググループ名のパターン 、 保持期間 、 出力形式 を設定し、内容を確認してルールを作成します。 Telemetry type で Logs を選択し、収集したいログタイプ (アクセスログ、接続ログ、ヘルスチェックログ) を選びます。 (オプション) タグのキー/値のペアを追加して、ルールの対象を一部のロードバランサーに絞り込みます (例: Environment: Production)。 図 3: ステップ 2「送信先を指定」: ロググループ名のパターン、保持期間、暗号化、3 種類の ALB ログタイプの選択 内容を確認し、 Amazon Elastic Load Balancer – アプリケーション Logs を設定 をクリックします。 図 4: ステップ 3「確認と作成」: ルール名、ソースアカウント、対象リージョン、CloudWatch Logs の送信先、選択したログタイプのサマリー 有効化ルールが有効になると、CloudWatch はルールのスコープ内にあるリソースから ALB ログの取り込みを開始します。ログは自動的に構造化 JSON 形式へ変換され、CloudWatch Logs のロググループに保存されます。3 種類のログはすべて同じロググループに届き、次のようにログストリームのプレフィックスで区別されます。 アクセスログ – ALB_Access_Logs/app/<lb-name>/<lb-id> 接続ログ – ALB_Connection_Logs/app/<lb-name>/<lb-id> ヘルスチェックログ – ALB_Health_Check_Logs/app/<lb-name>/<lb-id> ステップ 2: CloudFormation テンプレートで CloudWatch ダッシュボードをデプロイする CloudWatch ダッシュボード は、ALB のログデータを一元的に可視化する場を提供できます。サンプルダッシュボードは、CloudWatch Log Analytics のクエリ、メトリクス、Contributor Insights ルールを組み合わせて、監視対象のすべてのロードバランサーに共通する運用上のパターンを可視化します。運用チームはトラフィックの監視、エラーの調査、ターゲットのヘルス確認を 1 か所で行えるようになります。 図 5: リクエスト量、5xx エラー数、最も遅いターゲットの p99 レイテンシー、ステータスコード分布、ヘルスチェック詳細を示す ALB Insights ダッシュボード すぐに始められるよう、ダッシュボードをデプロイする CloudFormation テンプレートを用意しています。 CloudFormation の YAML テンプレート をダウンロードします。 AWS CloudFormation コンソール を開きます。 スタックの作成 > 新しいリソースを使用 (標準) を選択します。 テンプレートをアップロードし、 次へ を選択します。 スタック名を入力し、パラメーターを設定します。 DashboardName – ダッシュボードの名前 (デフォルト: ALB-Insights) DefaultTimeRange – ダッシュボードを開いたときに表示される期間 (デフォルト: -PT3H) CreateContributorInsightsRules – Contributor Insights ルールも作成する場合は Yes、ダッシュボードだけを作成する場合は No ALBLogGroupName – ALB ログを受け取るロググループ (デフォルト: /aws/elb)。Contributor Insights ルールでのみ使用されます。 ResourcePrefix – ルール名に付けるプレフィックス (デフォルト: ALB) 次へ を選択し、必要に応じてスタックオプションを設定して 次へ を選択します。 設定内容を確認し、 送信 を選択します。 スタックの作成が完了すると CloudWatch ダッシュボードが利用可能になり、イベントが届くにつれて ALB ログのパターンが表示されていきます。 図 6: ダッシュボードと 2 つの Contributor Insights ルールが CREATE_COMPLETE になった CloudFormation のリソースタブ Log Analytics による ALB ログの分析 ダッシュボードをデプロイした後は、アドホックなクエリを直接実行することもできます。 CloudWatch コンソール で ログ > ログ分析 を開いてください。ここでは、運用でよく問われる疑問に答えるクエリを紹介します。 5xx はロードバランサー由来かアプリケーション由来か SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["access"] | filter elb_status_code >= 500 | parse elb /^app\/(?[^\/]+)/ | fields if(target_status_code = "-", "load balancer / network", "target application") as owner | stats count(*) as errors, count_distinct(target_port) as targets_affected, earliest(time) as first_seen, latest(time) as last_seen by owner, lb, elb_status_code | sort errors desc 遅いルートはどれか SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["access"] | filter target_processing_time >= 0 | parse request_line /^(?\S+)\s+(?\S+)/ | parse url /^[a-z]+:\/\/[^\/]*(?[^?]*)/ | parse path /^\/(?[^\/]*)\/?(?[^\/]*)/ | fields if(s2 = "", concat("/",s1), concat("/",s1,"/",s2)) as route | stats count(*) as requests, avg(target_processing_time)*1000 as avg_ms, pct(target_processing_time,90)*1000 as p90_ms, pct(target_processing_time,99)*1000 as p99_ms, max(target_processing_time)*1000 as max_ms by route | sort p99_ms desc | limit 15 アクセスログとヘルスチェックログを組み合わせたターゲット別の信頼性 SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["access","health_check"] | fields coalesce(target_port, target_addr) as target | filter ispresent(target) | parse elb /^app\/(?[^\/]+)/ | stats count(request_line) as requests, sum(elb_status_code >= 500) as errors_5xx, sum(elb_status_code >= 500)*100.0/count(request_line) as error_pct, pct(target_processing_time,99)*1000 as p99_ms, count(status) as probes, sum(status = "FAIL") as probe_failures by lb, target | sort probe_failures desc, errors_5xx desc | limit 20 ログアラームで ALB のヘルスチェック失敗を通知する CloudWatch ログアラーム を使うと、カスタムメトリクスを用意しなくても、Log Analytics のクエリから直接アラームを作成できます。クエリはスケジュールに従って実行され、集計式が算出した数値が設定したしきい値を超えるとアラームが発生します。ログアラームは Log Analytics と同じクエリ言語を使用し、カスタムメトリクスの取り込みや保存にかかる追加費用も発生しません。 例: ヘルスチェック失敗に対するアラーム CloudWatch コンソールを開き、 アラーム に移動します。 アラームの作成 を選択し、 データソース として ログ を選択します。 Log Analytics でクエリを作成する をクリックします。 以下のクエリを実行し、 アラームに進む をクリックします。 SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["health_check"] | filter status = "FAIL" | stats count(*) as probe_failures by elb 集計式 に SUM(probe_failures) を入力します。 アラームの状態 で より大きい を選択し、 0 を入力します。 スケジュール で実行頻度 (例: rate(5 minutes) ) を選択します。 開始時間オフセット を 300 秒に設定します (5 分間隔のスケジュールに合わせます)。 アラームを実行するデータポイント を 1 / 1 に設定し、最初の 1 回で検知するようにします。 通知用に Amazon SNS トピックを設定します。 ログアラームを作成 を選択します。 これでアラームは 5 分ごとにクエリを評価し、ヘルスチェックのプローブがひとつでも失敗するとアラーム状態になります。 (オプション) 機能の拡張 ここまでの有効化ルールと CloudFormation テンプレートだけでも、十分に使い始められます。以下では、さらに活用したいチーム向けのオプション機能を説明します。 パイプラインで取り込み時に ALB ログをエンリッチする CloudWatch Logs パイプライン は、取り込みの時点で ALB のレコードを処理します。これにより、ログがロググループに届く前にフィールドをエンリッチしたり、変換・整形したりできます。 パイプラインを作成する CloudWatch コンソール を開き、 取り込み > パイプライン に移動します。 パイプラインを作成 を選択します。 一般設定 ページで次を設定します。 データソースを選択 で AWS Application Load Balancer logs を選択します。 ログソースタイプ でエンリッチしたいログタイプ (Access、Connection、Health Check) を選択します。 Service access で Auto create and use a new service role を選択し、必要な IAM ロールを CloudWatch に作成させます。 次へ を選択し、パイプラインの送信先とロググループの設定を行います。 プロセッサを設定 ページで JSON を解析 プロセッサーを選択して追加し、データを変換します。以下は ALB ログで役立つプロセッサーの例です。 タイプを変換 (ミューテートイベント) – elb_status_code を文字列から整数に変換します。これにより、メトリクスフィルターでの数値比較 (例: { $.elb_status_code >= 500 }) が正しく評価されるようになります。 GeoIP (エンリッチ) – client_ip フィールドを基に地理情報 (国 ISO コード、都市名、ASN の組織名) をレコードに追加し、結果を新しい client_geo フィールドへ書き込みます。条件式 ( client_ip != "" ) を指定して、client_ip フィールドが空のレコードはスキップします。外部の IP 参照サービスを保守しなくても、「トラフィックはどこから来ているのか」をクエリだけで確認できるようになります。 翻訳 (ミューテートイベント) – 静的マッピングを使って、elb_status_code の値を人が読める elb_status_meaning フィールドに変換します (例: 503 -> “no_registered_or_healthy_targets”)。実行条件 ( elb_status_code != "" かつ elb_status_code != "200" ) を追加してエラーレスポンスのときだけ動作させれば、成功したリクエストにはこのフィールドが付かないため、ノイズを抑えられます。 図 7: JSONを解析、タイプを変換、GeoIP プロセッサーを追加したプロセッサー設定画面 Test processors を選択し、保存する前にサンプルのログイベントで設定を検証します。 内容を確認してパイプラインを作成します。 ALB ログを 1 つのアカウントに集約する 複数のアカウントにまたがってワークロードを運用している場合は、 CloudWatch Logs の集約 (centralization) を使って、複数のアカウントとリージョンのロググループを 1 つの送信先アカウントに統合できます。集約されたロググループには @aws.account と @aws.region のフィールドが付加されるため、プラットフォームチームは 1 か所からすべての環境をまとめてクエリできます。 詳細な手順は Amazon CloudWatch Logs の一元化を使用したログ管理の簡素化 を参照してください。 Contributor Insights Contributor Insights は、あるパターンに寄与している上位 N 件の要因を継続的にランキングします。テンプレートは次の 2 つのルールを作成します。 ルール キーフィールド ランキング対象 TopClientIPs-ConnectionLogs $.client_ip 接続数の多いクライアント IP の上位 (接続ログから) TopTargetsByRequests-AccessLogs $.target_port リクエスト量の多いターゲットの上位 (アクセスログから) 上位クライアント IP のルールを手動で作成する手順は次のとおりです。 CloudWatch コンソール を開き、 ログ > Contributor Insights に移動します。 もし、 Contributor Insights がメニューにない場合は ログ > ログ分析 を選択し、 オプトアウト (Log insights) をクリックしてください。） ルール を作成 を選択します。 ロググループ で ALB のロググループ (例: /aws/elb) を選択します。 ルールタイプ で カスタムルール を選択します。 ログの形式 で JSON を選択します。 コントリビューション で次を設定します。 キー に $.client_ip を入力します。 フィルター を追加します。 一致 に $.client_ip を入力します。 状態 に IsPresent を選択します。 値 で true を選択します。 集計 で カウント を選択します。 次へ を選択します。 ルール名 に ALB-TopClientIPs-ConnectionLogs を入力します。 次へ を選択します。 ルールを作成 を選択します。 図 8: 3 時間のウィンドウで接続数上位 10 件のクライアント IP をランキングする TopClientIPs-ConnectionLogs ルール クリーンアップ 料金の発生を止めるには、次の順序でリソースを削除します。 取り込み > 有効化ルール からテレメトリルールを削除します。 パイプラインを作成した場合は、 取り込み > パイプライン から削除します。 CloudFormation スタックを削除します (ダッシュボードと Contributor Insights ルールが削除されます)。 ALB のロググループを削除するか、保持期間を短く設定します。 まとめ ALB のアクセスログ、接続ログ、ヘルスチェックログが構造化 JSON として CloudWatch Logs へ直接配信されるようになり、ワークロードの入口をリクエスト単位・接続単位・ターゲット単位で可視化できるようになりました。有効化ルールを 1 つ作成すれば、AWS 組織内のすべてのロードバランサーをカバーできます。Log Analytics はロードバランサーの障害とアプリケーションの障害を切り分け、ログアラームは問題が起きたときに通知し、Contributor Insights はトラフィックの大半を占めるクライアントとターゲットを上位から示します。パイプラインもパース処理も追加のインフラも必要ありません。 まずは CloudWatch コンソールを開いて 取り込み > 有効化ルール に移動し、Application Load Balancer 向けのルールを作成してみてください。詳細は Amazon CloudWatch Logs のドキュメントを参照してください。 著者について Raviteja Sunkavalli Raviteja Sunkavalli は Amazon Web Services のシニアワールドワイドスペシャリストソリューションアーキテクトで、AIOps と生成 AI のオブザーバビリティを専門としています。複雑で分散したクラウド環境において、世界中のお客様がオブザーバビリティとインシデント管理のソリューションを実装できるよう支援しています。仕事以外では、クリケットをしたり、新しい料理のレシピを試したりして過ごしています。 Siva Guruvareddiar Siva Guruvareddiar は AWS のシニアソリューションアーキテクトで、お客様が高可用性システムを設計できるよう支援することに情熱を注いでいます。マイクロサービス、コンテナ化、オブザーバビリティ、サービスメッシュ、クラウド移行といった技術を活用してプラットフォーム基盤と内部アーキテクチャをモダナイズし、クラウドネイティブへの移行を加速させる支援をしています。LinkedIn: linkedin.com/in/sguruvar 本ブログは 2026 年 8 月 25 日に公開された Analyze Application Load Balancer Logs with Amazon CloudWatch Logs の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

本記事は「 Are AI coding agents actually getting better? 」を翻訳したものです。 Kiro IDE のコーディングエージェントがコードを書いたり変更したりすると、 diagnostics ツール が静的解析器を実行して出力をチェックします。これは、開発者がエディタ上で下線として目にするのと同じチェックです。実際にこのツールは、モジュールの import 漏れ（ Cannot find module 'aws-cdk-lib' or its corresponding type declarations ）、解決できない Java の import（ The import org.junit cannot be resolved ）、型の不一致（ Argument of type 'string | undefined' is not assignable to parameter of type 'string' ）、 implicitly typed any 、 undefined symbol といったものを検出します。これらは、本来であればビルド時になって初めて表面化するような種類の問題です。 Kiro での diagnostics ツールの実際の動きをおさらいするために、下のスクリーンショットはツールが動作している様子を示しています。次の TypeScript コードを考えてみてください。ツールは 2 件の 型の不一致 （Type ‘number’ is not assignable to type ‘string’ と Cannot assign to read-only ‘executionTime’）と、1 件の プロパティのハルシネーション （Property ‘itemAge’ does not exist on type ‘StackProps’）を報告します。これらの diagnostics は、エージェントに対して修正を生成し、変更を再検証するための具体的なフィードバックを与えます。この「生成 → 検証 → 修正」のループは、静的型付け言語を扱うときに頻繁に発生します。多くのよくあるコーディングエラーを、language server が早期に捕捉できるためです。 図1: diagnostics ツールの動作。エージェントは 3 件のエラー（25 行目の number を string に代入できない型不一致、45 行目の read-only な ‘executionTime’ への書き込み、55 行目の StackProps に存在しない ‘itemAge’ プロパティのハルシネーション）を検出し、ファイルを編集して再チェックし、残りエラーがゼロであることを確認しています。 この記事では、生成中のエージェントによる diagnostics ツールの呼び出しを調べます。すなわち、モデルがタスクの途中でどのくらいの頻度で自発的に静的解析器を呼び出すのか、それらの解析器がどのようなエラーを表面化させるのか、そしてモデルが最終的な編集を行う前にそれらを解決しているのか、という点です。 diagnostics は、開発者が IDE にインストールしている言語拡張機能によって生成されるため、チェックの内容はワークスペースの構成によって変わります。今回のデータでは、diagnostics は各エコシステムの標準的な解析器から生成されています。TypeScript/JavaScript は tsserver、Java は jdtls、Python は Pyright、Rust は rust-analyzer、Kotlin は Kotlin language server、Go は gopls、C/C++ は clangd、そして ESLint のようなスタイル・正当性のリンターです。Swift の diagnostics（ Cannot switch on a value of type Region. Only convertible int values, strings or enum variables are permitted ）も観測されました。さらに従来のコンパイルエラーの枠を超えて、Lean 4 の定理証明器の diagnostics も観測されており、ここではツールが構文の誤りではなく不完全な証明を指摘しています（ Dependent elimination failed: Failed to solve equation, unsolved goals ）。 この 6 か月間、Kiro はさまざまな モデルファミリーとバリアント をサポートしてきました。Opus 4.5 から 4.8、Sonnet 4 から 4.6 までです。 新しいモデルは単純にエラーを生成しなくなる、と予想するかもしれません。エラー率は確かに低下しているものの、実態はそれよりも込み入っています。これらのモデルは単に間違いを減らしているのではなく、異なる種類の間違いをするようになっているのです。以前の世代で支配的だったエラーのカテゴリが姿を消し、その代わりに新しいカテゴリが現れています。全体の軌跡は前向きですが、エラー構成のこの変化は理解しておく価値があります。この記事では、私たちが見つけたことを共有します。 最終状態の品質と、途中の自己修正シグナルを区別する。 AI コーディングエージェントが改善しているかどうかを評価するには、互いに補完的な 2 つの方法があります。1 つ目は事後（post-hoc）の静的解析で、エージェントの最終出力に対して固定の解析器一式を実行し、残存エラーを数える方法です。これは最終状態のコード品質（開発者が実際に受け取る成果物）を測るもので、「モデルは正しいコードを生成したか？」の最も直接的な代理指標です。2 つ目は本研究が調べるもので、生成中のエージェントによる diagnostics ツールの呼び出しです。すなわち、モデルがタスクの途中でどのくらいの頻度で自発的に静的解析器を呼び出すのか、それらの解析器がどんなエラーを表面化させるのか、そしてモデルが最終的な編集の前にそれらを解決しているのか、という点です。 この後者のシグナルは、2 つの理由からモデルの能力についてより多くを語ります。1 つ目に、これはモデルの自己監視の能力を捉えます。これは最終状態の計測では見えない振る舞い上の性質です。というのも、自分の成果物を一度もチェックせずにたまたまきれいなコードを出したモデルと、チェックしてエラーを検出し修復したモデルとは、最終状態だけを見ると区別がつかないからです。2 つ目に、呼び出しレベルのデータはより豊かな分解を可能にします。モデルが どの エラーカテゴリを生成するのか、そのうちどれを自律的に修正できるのか、そのために追加でどれだけのツール呼び出しがかかるのかを明らかにし、モデルの認知がどこで成功しどこで失敗するのかを粒度細かく見せてくれます。対して事後解析は、このプロセスを 1 つの合否ビットに畳み込んでしまいます。要するに、事後解析はユーザーが受け取った品質が 何であったか を教えてくれますが、diagnostics 呼び出しのデータはモデルがその品質を どのように 達成した（あるいは達成しそこねた）かを教えてくれ、時系列でのモデル改善の軌跡を診断するうえでより強力なシグナルになります。 データ 2026 年 1 月から 6 月までの 6 か月間の窓で、私たちは Kiro IDE における約 150 万件の会話を、7 つの Claude モデル（Opus 4.5 から 4.8、Sonnet 4 から 4.6）にわたり、TypeScript、Python、Java、Rust、Go、Kotlin、C++、Swift を含む複数の言語を対象に分析しました。データは Amazon 社内ユーザーから得たものです。 私たちは 40.6 万件の diagnostics 呼び出し、すなわちエージェントが静的解析拡張機能を使ってコードファイルをチェックする組み込みツールを呼び出した瞬間を抽出しました。Opus 4.5 と 4.6 が分析データの 51% 超を占め、ボリュームの大半を構成しています。より新しい Opus モデルはデータ点が少なめです。Sonnet 4.5 の呼び出しがさらに全分析リクエストの 45% を占め、Sonnet 4 と 4.6 はデータ点が少なめです。 これらの結果を解釈する際に心に留めておくべきことが 3 つあります。 私たちが測っているもの、測っていないもの。 ここで分析している diagnostics は、コーディングエージェントがファイル編集を行った後に実行される Kiro IDE の Diagnostics Tool から来ています。これはユーザーの環境にインストールされた拡張機能に依存します。典型的には language server や静的解析器（TypeScript の tsc、ESLint、Pylint など）に加え、リソースのプロパティ・必須引数・リソース参照をデプロイ前にチェックする CloudFormation や Terraform のバリデーターといったインフラ関連の拡張機能です。つまり、私たちが捉えているのは問題の一部にすぎません。ランタイムエラー、ロジックのバグ、パフォーマンス退行、そして動的解析やテストを要するものはすべて、このデータには見えません。diagnostics のチェックがクリーンであることは、コードが正しいことを意味しません。それは単に、コードが静的解析を通過したことを意味するだけです。 環境はユーザーごとに異なる。 利用できる diagnostics は、ユーザーがインストールしている拡張機能に依存します。厳格な ESLint ルールと CloudFormation バリデーターを備えた開発者は、最小構成の開発者よりも多くの警告を表面化させます。このことがユーザー間の比較をノイズの多いものにし、集計されたエラー率がコーディング品質 と ツールの厳格さの両方を混ぜ合わせたものになることを意味します。実務上は、AI のコーディング品質をエラー率に加えて、スタック別・言語別・環境別に評価すべきです。ただし、今回のデータは共通のツール標準とベストプラクティスを共有する Amazon 社内ユーザーから来ているため、このデータセットでの環境のばらつきは、一般的な開発者集団全体で見た場合よりも狭い可能性が高いです。 モデルの改善だけが変数ではない。 diagnostics は孤立して動作するわけではありません。steering プロンプト、hooks、subagents、その他のオーケストレーション層を含む、より広いシステムの中で動作します。これらのコンポーネントのいずれかがこの 6 か月の窓の中で変更されれば、モデルの能力改善とは独立にエラー率へ影響し得ます。ここで示された改善を、モデルのアップグレードだけにきれいに帰属させることはできません。一部はおそらく、周辺インフラの改善を反映しています。この 2 つを切り分けるには、オーケストレーション層を固定した対照実験が必要ですが、この観察データはそれを提供しません。 1. モデルはどのくらいの頻度で diagnostics を呼び出すのか？ まず私たちは、 diagnostics 呼び出し率 、すなわちモデルが diagnostics ツールを少なくとも 1 回呼び出したコーディング会話の割合を調べました。この比率は、モデルが自分の成果物をチェックするために、利用可能な diagnostics ツールをどれだけ積極的に使うかを捉えます。 図2: 各モデルが diagnostics ツールを少なくとも 1 回呼び出したコーディング会話の割合。Opus 4.5 が 14.58%、Opus 4.6 が 22.26%（最高点）、Opus 4.7 が 10.15%、Opus 4.8 が 10.85%、Sonnet 4 が 7.65%、Sonnet 4.5 が 2.74%（最低点）、Sonnet 4.6 が 13.89%。 Opus 4.6 が最も積極的で、会話の 22.26% で diagnostics を呼び出しています。しかし、その後の Opus のバージョン（4.7 と 4.8）は約 10% まで戻りました。Sonnet ファミリーは別の物語を語ります。Sonnet 4.5 は diagnostics をほとんど呼び出しませんでした（2.74%）が、Sonnet 4.6 は 13.89% へ跳ね上がりました。これはツールへの意識の高まりを示す大きな増加です。全体として呼び出し率はおおよそ 3〜22% で、ほとんどの会話が、モデルが静的に見つかるエラーを積極的にチェックしないまま完了していることを示しています。これは、モデルは学習時のツールをデフォルトで使い、明示的なプロンプトやファインチューニングなしには diagnostics ツールをめったに使わない、という 最近の知見 と整合します。同様の実験は、エラーが解決されるまでエージェントの確定をブロックするために diagnostics を使うと、誤ったコードの受け入れを約 90% から約 8% へ大幅に減らせることを示唆しています。これは、diagnostics を単に任意のツールとして利用可能にしておくよりもはるかに大きな効果です。 2. チェックされたファイルあたりの報告エラー数: モデルは良くなっているのか？ 私たちは、モデルのバージョンをまたいでファイルあたりの平均エラー数を比較しました。この指標は、生成されたコードがどれだけ「コンパイルに近い」かを捉えます。完全に成功しない場合でも、ファイルあたりのエラーが少なければ、手作業の修正が少なくて済みます。 図3: モデルのバージョン別の、チェックされたファイルあたりの平均 diagnostics エラー数。Sonnet の線は 3.01（Sonnet 4）から 2.90（Sonnet 4.5）、1.29（Sonnet 4.6）へ低下。Opus の線は 1.74（Opus 4.5）、1.21（Opus 4.6）、1.82（Opus 4.7）、1.21（Opus 4.8）で、両ファミリーとも最新版では 1.2 付近に収束。 Sonnet の線は明確な改善の物語を語ります。Sonnet 4 のファイルあたり 3.01 エラーから Sonnet 4.6 の 1.29 まで、57% の削減が観測されました。Opus ファミリーは非単調なパターンを示します。Opus 4.6 と 4.8 はいずれも 1.21 に達する一方、Opus 4.5 と 4.7 は 1.7〜1.8 前後とやや高めです。これは、Opus ファミリーの中では、静的に見つかる diagnostics の観点で必ずしもすべてのバージョンが厳密な改善を表すわけではない、ということを示唆しているのかもしれません。全体として、両ファミリーとも本研究の最新版ではチェック済みファイルあたり約 1.2 エラーへ収束します。これは、そのままでコンパイル可能なコードを生成するモデルへ向けた意味のある前進を示している可能性があります。 3. 呼び出しあたりのチェック対象ファイル数: 広いスコープか、狭いスコープか エラー率を超えて、モデルが diagnostics ツールを どう 使うかについて興味深いことに気づきました。新しいモデルは、1 回の呼び出しでより多くのファイルをチェックしています。 図4: モデルが diagnostics ツールを呼び出すたびにチェックする平均ファイル数。Opus は 1.78（Opus 4.5）から 1.87（Opus 4.6）、2.04（Opus 4.7）、その後 1.91（Opus 4.8）へ上昇。Sonnet は 1.57（Sonnet 4）から 1.72（Sonnet 4.5）、1.86（Sonnet 4.6）へ上昇し、新しいモデルほど 1 回の呼び出しでより多くのファイルをチェックしている。 初期の頃、Sonnet 4 は diagnostics を呼び出すたびに平均 1.57 ファイルをチェックしていました。実質的には一度に 1 ファイル、たまに 2 ファイル目という程度です。Sonnet 4.5 でこれは 1.72 へ、Sonnet 4.6 は 1.86 へ上がりました。Opus ファミリーも同様の傾向を示します。Opus 4.5 は呼び出しあたり平均 1.78 ファイル、Opus 4.6 は 1.87、Opus 4.7 は 2.04 でピークに達し、Opus 4.8 は 1.91 に落ち着きました。 これが重要なのは、コードチェック戦略の転換を表しているからです。ファイルを編集してそのファイルだけをチェックするのではなく、新しいモデルは 関連する ファイルをまとめてチェックすることが増えています。たとえば、実装とそのテスト、あるいはモジュールとその利用側です。 呼び出しあたり約 1.6 ファイルから約 2.0 ファイルへの移行はささやかに聞こえるかもしれませんが、数十万回の呼び出しにわたって見れば、モデルが以前の世代よりも高い頻度でクロスファイルの退行（import の破損、インターフェースの不一致、下流の型エラーなど）を捕捉していることを意味します。 4. 報告されたエラーカテゴリのトップ5 診断されたエラーが何なのかを理解するため、私たちはエラーの種類を分類し、各モデルごとに分布を可視化しました。 図5: 各モデルの diagnostics エラーカテゴリの分布。Opus 4.5・4.6・4.7・4.8、Sonnet 4・4.5・4.6 の 7 つのドーナツチャート。カテゴリは解決できない import、未定義シンボル、構文エラー、implicit any、プロパティアクセス、解決できない参照、Kotlin 標準ライブラリの解決、その他。解決できない import はすべてのモデルで最大のスライスで、Opus 4.7 では 57.6% に達する。一方 Sonnet 4.5 や Opus 4.5 のようなモデルはカテゴリ間により均等に広がっている。 すべてのモデルにわたって、「解決できない import」が単独で最大のエラーカテゴリであり、多くの場合すべての diagnostics の約 3 分の 1 を占め、Opus 4.7 では半分超に達します。「未定義シンボル」と、型システムのエラーの長い裾（構文エラー、解決できない参照、implicit any など）が残りを構成します。注目すべきは、エラー分布がモデル間で異なる点です。Opus 4.7 は import 解決の失敗に大きく偏っており、他のエラータイプは比較的少ないのに対し、Sonnet 4.5 や Opus 4.5 のようなモデルはカテゴリ間により均等に広がった分布を示します。これは、モデルによって失敗の仕方が異なることを示唆しているのかもしれません。あるモデルは主に依存関係の解決に苦戦し、別のモデルは型システムとシンボルの全体にわたって間違いをより広く分散させます。 5. ソースファイル対テストファイル: どちらがより多くのエラーを生むのか？ テストコードは、モデルが正しく書くのが一貫して難しい対象です。テストにはモッキングフレームワーク、アサーションライブラリ、複雑なセットアップのパターンが関わり、テストツールとテスト対象コードの両方を理解している必要があります。 図6: モデル別の、ソースファイルとテストファイルにおけるファイルあたり平均エラー数。ソースエラーは青、テストエラーは赤。Opus 4.5 は 1.35 対 5.98、Opus 4.6 は 0.96 対 3.64、Opus 4.7 は 1.40 対 4.62、Opus 4.8 は 0.81 対 6.00、Sonnet 4 は 2.20 対 7.31、Sonnet 4.5 は 2.26 対 9.13（最も差が大きい）、Sonnet 4.6 は 1.08 対 3.56 で、テストファイルは常にソースファイルよりはるかに高い。 Opus ファミリーは概してソースファイルのエラーを 1.4 未満に保ちますが、テストファイルのエラーは 3.64（Opus 4.6）から 6.00（Opus 4.8）まで幅があります。Sonnet 4.5 は最も差が大きく、ソースファイルあたり 2.26 エラーに対しテストファイルあたり 9.13 エラーです。Sonnet 4 はソースエラー 2.20、テストエラー 7.31 を生み、Sonnet 4.6 は Sonnet の中で最も強く、それぞれ 1.08 と 3.56 です。モデルのサイズや世代にかかわらず、テストファイルが依然としてエラーの主な発生源であるように見えます。 6. 言語の地形図: Java は難しく、Python は易しい コードを生成するとき、他より多くのエラーを生む言語があります。Opus 4.6（最大のトラフィック）のファイルレベルのエラー率を見ると、そのばらつきは非常に大きいです。ただし、これらの数値はモデルの能力を超えた 2 つの要因によっても形作られています。顧客がインストールしている静的解析拡張機能の精度（より厳格なリンターほど多くの問題を表面化させる）と、Kiro IDE のユーザー層が各言語をどう使うかのばらつきです。 図7: Opus 4.6 における言語別のファイルエラー率（低いほど良い）。低い順に、JavaScript 1.6%、Python 4.0%、Go 8.0%、Kotlin 8.5%、TypeScript 8.6%、TSX（React）11.2%、C++ 12.2%、Rust 15.1%、Java 26.7%（最も長いバー）。 Java は 26.7% のファイルエラー率でトップに位置します。これは、生成された Java ファイルの 4 つに 1 つ超が少なくとも 1 件の diagnostics エラーを含むことを意味します。冗長な import、複雑なジェネリクス、検査例外、厳格な型解決の組み合わせが、本研究で分析した AI モデルにとって Java を最も難しい言語にしており、その差は大きく開いています。次に来るのは Rust の 15.1%、続いて C++ の 12.2% です。 中間層は TSX/React、TypeScript、Kotlin、Go で構成され、エラー率は 8〜11% の範囲です。これらはモデルをつまずかせるだけの構造を持った静的型付け言語ですが、Java ほど厳格ではありません。 最下位に位置するのは Python（4.0%）と JavaScript（1.6%）です。Python の動的型付け、import のボイラープレートの少なさ、寛容な構文は、一貫してきれいな結果を生みます。JavaScript の底値の 1.6% は少しばかり誤解を招きます。これはモデルがより良いコードを 書いている ことではなく、素の JS で利用できる静的解析が最小限であることを反映しています。TypeScript の型システムを上に乗せると、この率は 8.6% へ跳ね上がります。JavaScript に当てはまる同じ但し書きが、より微妙な形で Python にも当てはまります。動的型付け言語であり、静的解析が通常は軽いため、一部の Python のエラーはランタイムになるまで diagnostics として表面化しません。したがって、低い静的エラー率は編集時に捕捉できるものを反映しているのであって、そのコードが Java よりも必ずしも正しいことを意味しません。Java ではコンパイラがほぼすべてを前もって捕捉するのです。 チームが Java コードベースで AI コーディングエージェントを重点的に使っているなら、Python や TypeScript のコードベースよりも diagnostics のクリーンアップに多くの時間を費やすことを見込んでおいてください。 まとめ 6 か月と 50 万件近い diagnostics 呼び出しは、AI コーディングエージェントが正しいコードを書くうえで測定可能なかたちで改善していることを示していますが、その実態は単一の数字よりも込み入っています。 エラー率は低下している。 両モデルファミリーとも、より強力なバージョンでファイルあたり約 1.2 エラーへ収束します。 モデルは会話の 3〜22% で diagnostics ツールを積極的に呼び出す。 新しいモデルは一度により多くのファイルをチェックする。 より最近のモデルでは、関連ファイル（たとえば実装とそのテスト）をまとめてチェックすることが増えています。 解決できない import が支配的。 モデルにかかわらず、全エラーの約 30〜58% を占めます。 テストコードは正しく書くのが 3〜4 倍難しいように見える。 モッキングフレームワークやアサーションライブラリは、実装ファイルよりも一貫してはるかに多くのエラーを生みます。 言語は重要。 Java のエラー率（26.7%）は Python（4.0%）の 6.7 倍です。JavaScript の低い 1.6% は、より良い生成ではなく弱い静的解析を反映しています。 diagnostics は、Kiro のエージェントがコードを書いて洗練させる過程で自動的に実行されます。その仕組みを見て、さらに深く知るには、 diagnostics のドキュメント と モデルの概要 を読み、 Kiro をダウンロード してご自身のコードベースで試してみてください。

本記事は2026年4月17日に公開された「 Introducing granular cost attribution for Amazon Bedrock 」を翻訳したものです。 AI による推論がクラウド支出の大きな割合を占めるようになる中、誰が、そして何がコストを押し上げているのかを把握することは、チャージバック、コスト最適化、財務計画にとって不可欠です。本日、Amazon Bedrock 推論のきめ細かなコスト配分機能を発表します。 Amazon Bedrock は、推論コストを API コールを実行した IAM プリンシパルに自動的に紐付けるようになりました。 IAM プリンシパル とは、IAM ユーザー、アプリケーションが引き受けたロール、または Okta や Entra ID などのプロバイダーからのフェデレーテッド ID のことです。この紐付けは AWS Billing に反映され、モデルを問わず機能します。管理すべきリソースはなく、既存のワークフローを変更する必要もありません。オプションのコスト配分タグを使用すれば、AWS Cost Explorer や AWS Cost and Usage Reports (CUR 2.0) で、チーム別、プロジェクト別、またはカスタムディメンション別にコストを集計できます。 この記事では、Amazon Bedrock のきめ細かなコスト配分の仕組みを紹介し、コスト追跡のシナリオ例を解説します。 きめ細かなコスト配分の仕組み CUR 2.0 では、データエクスポート設定で IAM プリンシパルデータを有効にすると、どの AWS Identity and Access Management (IAM) プリンシパルが Amazon Bedrock を呼び出しているか、またそれぞれがいくら使っているかを確認できます。以下に例を示します。 line_item_iam_principal line_item_usage_type line_item_unblended_cost arn:aws:iam::123456789012:user/alice USE1-Claude4.6Sonnet-input-tokens $0.069 arn:aws:iam::123456789012:user/alice USE1-Claude4.6Sonnet-output-tokens $0.214 arn:aws:iam::123456789012:user/bob USE1-Claude4.6Opus-input-tokens $0.198 arn:aws:iam::123456789012:user/bob USE1-Claude4.6Opus-output-tokens $0.990 ここでは、Alice が Claude 4.6 Sonnet を、Bob が Claude 4.6 Opus を使用していること、そしてそれぞれが入力トークンと出力トークンにいくら費やしているかを確認できます。以下の表は、各アイデンティティタイプに対して line_item_iam_principal 列に含まれる内容を示しています。 Bedrock の呼び出し方法 line_item_iam_principal AWS IAM ユーザー …user/alice Bedrock キー (IAM ユーザーにマッピング) …user/BedrockAPIKey-234s AWS IAM ロール (例: AWS Lambda 関数) …assumed-role/AppRole/session フェデレーテッドユーザー (例: ID プロバイダーからのユーザー) …assumed-role/Role/user@acme.org タグを使った集計と Cost Explorer での活用 チーム別、プロジェクト別、またはコストセンター別にコストを集計するには、IAM プリンシパルにタグを追加します。タグは次の2つの方法で請求データに反映されます。 プリンシパルタグ は、IAM ユーザーまたはロールに直接アタッチされます。一度設定すれば、そのプリンシパルからのすべてのリクエストに適用されます。 セッションタグ は、ユーザーやアプリケーションが IAM ロールを引き受けて一時的な認証情報を取得する際に動的に渡されるか、ID プロバイダーのアサーションに埋め込まれます。詳細については、「 Pass session tags in AWS STS 」を参照してください。 AWS Billing で コスト配分タグ として有効化すると、両方のタグタイプが CUR 2.0 の tags 列に iamPrincipal/ プレフィックス付きで表示されます。以下に例を示します。 Bedrock の呼び出し方法 line_item_iam_principal tags AWS IAM ユーザー …user/alice {“iamPrincipal/team”:”ds”} AWS IAM ロール …assumed-role/AppRole/session {“iamPrincipal/project”:”chatbot”} フェデレーテッドユーザー …assumed-role/Role/user@acme.org {“iamPrincipal/team”:”eng”} コスト配分戦略の構築に関する詳細なガイダンスについては、「 Best Practices for Tagging AWS Resources 」を参照してください。 シナリオ別クイックスタート セットアップ方法は、ユーザーやアプリケーションが Amazon Bedrock をどのように呼び出すかによって異なります。以下の表は、各アクセスパターンにおいて CUR 2.0 で利用可能な紐付け情報と、タグベースの集計のために設定すべき内容をまとめたものです。 セットアップ CUR 2.0 での紐付け情報 タグによる集計および Cost Explorer のための設定方法 シナリオ IAM ユーザーまたは API キーを使用する開発者 各ユーザーの ARN が CUR 2.0 に表示される IAM ユーザーにタグをアタッチする 1 IAM ロールを使用するアプリケーション 各ロールの ARN が CUR 2.0 に表示される IAM ロールにタグをアタッチする 2 IdP を通じて認証するユーザー ARN 内のセッション名でユーザーを識別 IdP からセッション名とタグを渡す 3 Bedrock にプロキシする LLM ゲートウェイ ゲートウェイのロールのみ表示される (全ユーザーが単一の ID) ユーザーごとに AssumeRole でセッション名とタグを追加する 4 注: シナリオ 1～3 では、CUR 2.0 の line_item_iam_principal 列により、呼び出し元ごとのアイデンティティの紐付け情報が得られます。タグが必要になるのは、カスタムディメンション (チーム、コストセンター、テナント) で集計したい場合や、Cost Explorer で視覚的な分析やアラートを利用したい場合のみです。シナリオ 4 では、ユーザーレベルの紐付け情報を得るために、ユーザーごとのセッション管理が必要です。これがない場合、すべてのトラフィックがゲートウェイの単一ロールに紐付けられます。 タグを追加した後、AWS Billing コンソールまたは UpdateCostAllocationTagsStatus API で コスト配分タグを有効化 してください。タグは 24～48 時間以内に Cost Explorer と CUR 2.0 に反映されます。 以降のセクションでは、いくつかの一般的なシナリオを解説します。 シナリオ 1: IAM ユーザーと API キーによるユーザーごとの追跡 ユースケース: 個々の開発者が IAM ユーザーの認証情報や Amazon Bedrock API キーを使用する、小規模チーム、開発環境、または迅速なプロトタイピングを行う場面。 仕組み: 各チームメンバーは長期認証情報を持つ専用の IAM ユーザーを持っています。例えば user-1 や user-2 が Amazon Bedrock を呼び出すと、Amazon Bedrock は認証時にその IAM ユーザーの Amazon Resource Name (ARN) を自動的に記録します。CUR 2.0 では、誰がいくら使っているかを確認できます。 チーム別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えばデータサイエンスチームのメンバー全体の合計支出を確認したい場合 — IAM ユーザーにタグをアタッチします。タグは IAM コンソール、AWS Command Line Interface (AWS CLI)、または AWS API で追加できます。以下の例では AWS CLI を使用しています。 # データサイエンスチームのユーザーにタグを付ける aws iam tag-user \ --user-name user-1 \ --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345" aws iam tag-user \ --user-name user-2 \ --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345" CUR 2.0 に表示される内容: Cost and Usage Report には個々のユーザー ID とそのタグの両方が記録されるため、以下の例に示すように、2 つのディメンションで分析を行うことができます。 line_item_iam_principal line_item_usage_type line_item_unblended_cost tags arn:aws:iam::123456789012:user/user-1 USE1-Claude4.6Sonnet-input-tokens $0.0693 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-1 USE1-Claude4.6Sonnet-output-tokens $0.2145 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-2 USE1-Claude4.6Opus-input-tokens $0.1980 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-2 USE1-Claude4.6Opus-output-tokens $0.9900 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} line_item_usage_type 列にはリージョン、モデル、トークンの方向 (入力と出力) がエンコードされているため、「user-1 が Sonnet の入力トークンと出力トークンにそれぞれいくら使ったか？」や「誰が Opus を使っていて、誰が Sonnet を使っているか？」といった質問に答えることができます。 このデータから、いくつかの方法でコストを分析できます: ユーザー別: line_item_iam_principal でフィルタリングすると、各ユーザーの正確な支出額を確認できます。ヘビーユーザーの特定や、個人の実験コストの追跡に役立ちます。 モデル別: line_item_usage_type でフィルタリングすると、モデルごとの支出を比較できます。例えば、誰が Opus のコストを押し上げていて、誰が Sonnet を使っているかがわかります。 チーム別: iamPrincipal/team でグループ化すると、データサイエンスチームのメンバー全体の合計支出を確認できます。部門別のチャージバックに役立ちます。 このアプローチは、ユーザー数が管理可能な範囲にあり、最もシンプルなセットアップで済ませたい場合に最適です。各ユーザーの認証情報によって請求データ上で直接本人を識別することが可能になり、タグを使えばコストをより上位のディメンションにまとめることもできます。 Amazon Bedrock API キーの使用: Amazon Bedrock は、他の AI プロバイダーと同様のシンプルな認証体験を提供する API キーもサポートしています。 API キー は IAM プリンシパルに関連付けられています。API キーで行われたリクエストは対応する IAM アイデンティティに紐付けられるため、同様に line_item_iam_principal およびタグベースの紐付けがそのまま適用されます。つまり、開発者に API キーを配布したり、アプリケーションに埋め込んだりしている組織でも、コストを元の IAM ユーザーやロールまで追跡できます。 シナリオ 2: IAM ロールによるアプリケーションごとの追跡 ユースケース: (人間ではなく) アプリケーションが Amazon Bedrock を呼び出す本番用ワークロードで、プロジェクトやサービスごとにコストを追跡したい場合。 仕組み: 例えば、ドキュメント処理サービス (app-1) とチャットサービス (app-2) という 2 つのバックエンドアプリケーションがあるとします。各アプリケーションはコンピューティングインフラストラクチャ (Amazon EC2、AWS Lambda、Amazon Elastic Container Service (Amazon ECS) など) 上で動作し、専用の IAM ロールを引き受けて Amazon Bedrock を呼び出します。いずれかのアプリケーションが Amazon Bedrock を呼び出すと、引き受けたロールの ARN が自動的に記録されます。この紐付け情報は CUR 2.0 レポートに反映され、アプリケーションごとのコスト可視性が得られます。 line_item_iam_principal でフィルタリングすると、ロール名が含まれているため、アプリケーションごとの合計支出を確認できます。また、 line_item_usage_type でフィルタリングすると、サービス間でのモデル使用状況を比較できます。タグの使用は任意です。アプリケーションがリクエストやバッチジョブごとに一意のセッション名を生成する場合は、さらに細かいレベルでコストを追跡できます。 プロジェクト別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えば DocFlow と ChatBackend の合計支出を比較したい場合 — IAM ロールにタグをアタッチします。 # ドキュメント処理ロールにタグを付ける aws iam tag-role \ --role-name Role-1 \ --tags Key=project,Value="DocFlow" Key=cost-center,Value="12345" # チャットサービスロールにタグを付ける aws iam tag-role \ --role-name Role-2 \ --tags Key=project,Value="ChatBackend" Key=cost-center,Value="12345" app-1 が Role-1 を引き受けて Amazon Bedrock を呼び出すと、リクエストは引き受けたロールのセッションに紐付けられます。ロールのタグは自動的に請求データに反映されます。 CUR 2.0 に表示される内容: line_item_iam_principal には、以下の例に示すように、セッション名を含む引き受けたロールの完全な ARN が表示されます。 line_item_iam_principal line_item_usage_type line_item_unblended_cost tags arn:aws:sts::123456789012:assumed-role/Role-1/session-123 USE1-Claude4.6Sonnet-input-tokens $0.0330 {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-1/session-123 USE1-Claude4.6Opus-output-tokens $0.1650 {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-2/session-456 USE1-NovaLite-input-tokens $0.0810 {“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-2/session-456 USE1-NovaLite-output-tokens $0.0500 {“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} これにより、複数の方法で分析できます。 ロールでフィルタリング: ARN のロール名部分を使って、アプリケーションごとの合計支出を確認できます。 セッションでフィルタリング: セッション名を使って、リクエストやバッチジョブごとのコストを追跡できます。 プロジェクトで集計: iamPrincipal/project でグループ化して、DocFlow と ChatBackend のコストを比較できます。 コストセンターで集計: iamPrincipal/cost-center でグループ化して、同じチームが所有するアプリケーション全体の合計支出を確認できます。 このアプローチは、各サービスが独自の IAM ロールを持つマイクロサービスアーキテクチャに最適です。これはセキュリティのベストプラクティスであると同時に、コスト配分のメカニズムとしても機能します。 シナリオ 3: フェデレーテッド認証によるユーザーごとの追跡 ユースケース: ユーザーが企業の ID プロバイダー (Auth0、Okta、Azure AD、Amazon Cognito) を通じて認証し、OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) フェデレーション経由で AWS にアクセスするエンタープライズ環境。 仕組み: ユーザーは ID プロバイダー (IdP) を通じて認証し、共有の IAM ロールを引き受けます。ユーザーごとの紐付けは 2 つのメカニズムによって得られます。 セッション名 (引き受けたロールの ARN に埋め込まれたユーザー ID) と セッションタグ (IdP から渡されるチーム、コストセンターなど) です。1 つの IAM ロールがすべてのユーザーに対応するため、ユーザーごとの IAM リソースを管理する必要はありません。 セッション名 (緑色でハイライト) が line_item_iam_principal に表示される内容です: arn:aws:sts::123456789012:assumed-role/BedrockRole/ user-1@acme.org 図 1. フェデレーテッド認証シナリオにおける ID フロー OIDC フェデレーション (Auth0、Cognito、Okta OIDC) の場合: IdP を IAM OIDC プロバイダーとして登録し、 sts:AssumeRoleWithWebIdentity と sts:TagSession を許可する信頼ポリシーを持つロールを作成し、IdP が ID トークンに https://aws.amazon.com/tags クレームを挿入するよう設定します。AWS Security Token Service (AWS STS) はこのクレームからセッションタグを自動的に抽出します。呼び出し元のアプリケーションは、 AssumeRoleWithWebIdentity を呼び出す際に –role-session-name をユーザーのメールアドレス (または別の識別子) に設定します。 SAML フェデレーション (Okta、Azure AD、Ping、ADFS) の場合: IdP で SAML 属性マッピングを設定し、アサーションに RoleSessionName (例: ユーザーのメールアドレス) と PrincipalTag:* 属性 (チーム、コストセンター) を渡すようにします。セッション名とタグはどちらも署名済みアサーションに埋め込まれるため、呼び出し元のアプリケーションが個別に設定する必要はありません。IAM ロールには sts:AssumeRoleWithSAML と sts:TagSession の権限が必要です。 どちらの場合も、タグはアサーションまたはトークン内に暗号的に署名されているため、ユーザーが自身のコスト配分情報を改ざんすることはできません。 CUR 2.0 に表示される内容:&nbsp; line_item_iam_principal line_item_usage_type line_item_unblended_cost tags …assumed-role/Role-1/user-1@acme.org USE1-Claude4.6Opus-input-tokens $0.283 {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} …assumed-role/Role-1/user-1@acme.org USE1-Claude4.6Opus-output-tokens $0.990 {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} …assumed-role/Role-1/user-2@acme.org USE1-Claude4.6Sonnet-input-tokens $0.165 {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} …assumed-role/Role-1/user-2@acme.org USE1-Claude4.6Sonnet-output-tokens $0.264 {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} この例では、user-1 が Opus を、user-2 が Sonnet を使用しています。両者は同じ IAM ロールを共有していますが、それぞれ個別に識別できます。 iamPrincipal/team でグループ化すれば部門別のチャージバックが可能になり、セッション名を抽出すればユーザーごとの分析ができます。 シナリオ 4: LLM ゲートウェイを介したユーザーごとの追跡 ユースケース: ユーザーと Amazon Bedrock の間に大規模言語モデル (LLM) ゲートウェイまたはプロキシ (LiteLLM、カスタム API ゲートウェイ、Kong、Envoy、または自社開発サービス) を配置している組織。 問題点: ゲートウェイは独自のレイヤーでユーザーを認証した後、ゲートウェイのコンピューティングにアタッチされた単一の IAM ロールを使用して Amazon Bedrock を呼び出します。追加の対応を行わない場合、すべての Amazon Bedrock コールが CUR 2.0 上で単一のアイデンティティとして表示され、ユーザーごとやテナントごとの可視性は得られません。 解決策: ユーザーごとのセッション管理 ゲートウェイは各ユーザーに対して Amazon Bedrock スコープのロールに対し AssumeRole を呼び出し、ユーザーの ID を --role-session-name として、ユーザーの属性 (チーム、テナント、コストセンター) を --tags として渡します。生成されたユーザーごとの認証情報はキャッシュされ (最大 1 時間有効)、同じユーザーからの後続リクエストに再利用されます。これには 2 つの IAM ロールが必要です。1 つ目はゲートウェイ実行ロールで、 sts:AssumeRole と sts:TagSession のアクセス許可を持ちます。2 つ目は Amazon Bedrock 呼び出しロールで、ゲートウェイロールから信頼され、Amazon Bedrock API にスコープが限定されています。 図 2. LLM ゲートウェイシナリオにおける ID フロー 実装上の主な考慮事項: セッションのキャッシュ : AssumeRole によるレイテンシーの追加はわずかです。TTL (Time to Live) を 1 時間に設定すれば、STS の呼び出しはリクエストごとではなく、ユーザーごとに 1 時間に 1 回で済みます。 キャッシュサイズは 総ユーザー数ではなく、 同時接続ユーザー数に比例します (同時接続ユーザーが 500 であれば、キャッシュされるセッションも約 500)。 STS のレート制限 はデフォルトでアカウントあたり毎秒 500 AssumeRole コールです。高スループットのゲートウェイの場合は引き上げをリクエストしてください。 セッションタグは一度設定するとそのセッション内では変更できません 。タグの変更は次回のセッション作成時に反映されます。 CUR 2.0 に表示される内容: line_item_iam_principal line_item_usage_type line_item_unblended_cost tags …assumed-role/BedrockRole/gw-user-1 USE1-Claude4.6Sonnet-input-tokens $0.081 {“iamPrincipal/team”:”data-science”} …assumed-role/BedrockRole/gw-user-1 USE1-Claude4.6Sonnet-output-tokens $0.163 {“iamPrincipal/team”:”data-science”} …assumed-role/BedrockRole/gw-tenant-acme USE1-Claude4.6Opus-input-tokens $0.526 {“iamPrincipal/tenant”:”acme-corp”} …assumed-role/BedrockRole/gw-tenant-acme USE1-Claude4.6Opus-output-tokens $0.925 {“iamPrincipal/tenant”:”acme-corp”} ゲートウェイでユーザーごとのセッション管理を行わない場合、ゲートウェイのトラフィックはすべてゲートウェイの単一ロールに紐付けられます。セッション管理を追加することが、ユーザーごとおよびテナントごとの紐付けを実現するための鍵となります。 シナリオの選び方 IAM ユーザーまたは Amazon Bedrock API キーを使用する開発者 → シナリオ 1 AWS コンピューティング上で IAM ロールを使用するアプリケーション/サービス → シナリオ 2 IdP (Auth0、Okta、Azure AD) を通じて認証するユーザー → シナリオ 3 Amazon Bedrock の前段に配置された LLM ゲートウェイまたはプロキシ → シナリオ 4 マルチテナント SaaS を構築する場合 → シナリオ 4 (テナント ID をセッション名 + セッションタグとして使用) Claude Code ワークロード → シナリオ 3 AWS Billing でのタグの有効化 AWS Billing コンソール を開きます コスト配分タグ に移動します タグが少なくとも 1 つの Amazon Bedrock リクエストに使用された後 (最大 24 時間かかります)、AWS マネジメントコンソールの IAM カテゴリの下にそのタグが表示されます 有効化したいタグを選択し、「 有効化 (Activate) 」を選択します CUR 2.0 の場合は、データエクスポート設定の作成時または更新時に IAM プリンシパルを有効にする必要もあります。 Cost Explorer でのコスト表示 有効化すると、IAM タグが Cost Explorer の「 タグ (Tags) 」ドロップダウンの IAM カテゴリの下に表示されます。以下のことが可能です。 team = data-science でフィルタリングして、そのチームの Amazon Bedrock の合計支出を確認する tenant でグループ化して、顧客間のコストを比較する ディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答える 利用を開始するには Amazon Bedrock の新しいコスト配分機能は、追加費用なしで商用リージョンで利用可能です。開始するには以下の手順に従ってください。 アクセスパターンを特定する。 開発者が IAM ユーザーや API キーで Amazon Bedrock を直接呼び出しているか (シナリオ 1)？ アプリケーションが IAM ロールを使用しているか (シナリオ 2)？ ユーザーが ID プロバイダーを通じて認証しているか (シナリオ 3)？ それともトラフィックが LLM ゲートウェイを経由しているか (シナリオ 4)？ CUR 2.0 で IAM プリンシパルデータを有効にする。 データエクスポート設定を更新して、IAM プリンシパルデータを含めるようにします。 集計が必要な場合や Cost Explorer でフィルタリングしたい場合はタグを追加する。 IAM ユーザーまたはロールにタグをアタッチするか、IdP からセッション名とタグを渡すよう設定するか、ゲートウェイにユーザーごとのセッション管理を追加します。その後、AWS Billing コンソールでコスト配分タグを有効化します。 分析する。 有効化から 24～48 時間以内に、タグが Cost Explorer と CUR 2.0 に表示されます。チームでフィルタリング、プロジェクトでグループ化、またはディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答えることができます。 まとめ 推論に誰がいくら使っているかを把握することは、チャージバック、予測、最適化の第一歩です。Amazon Bedrock のきめ細かなコスト配分を使えば、既に導入済みの IAM アイデンティティとタグのメカニズムを活用して、推論リクエストを特定のユーザー、アプリケーション、またはテナントまで追跡できます。チームが IAM 認証情報で Amazon Bedrock を直接呼び出す場合でも、フェデレーテッド認証を経由する場合でも、LLM ゲートウェイを介する場合でも、AWS CUR 2.0 と AWS Cost Explorer が必要な可視性を追加費用なしで提供します。 著者について Ba’Carri Johnson は Amazon Bedrock チームのシニアテクニカルプロダクトマネージャーで、AWS AI のコスト管理とガバナンスを専門としています。AI インフラストラクチャ、コンピューターサイエンス、戦略のバックグラウンドを持ち、プロダクトイノベーションと組織が責任を持って AI をスケールさせるための支援に取り組んでいます。余暇には旅行やアウトドアを楽しんでいます。 Vadim Omeltchenko は Amazon Bedrock の Go-to-Market 担当シニアソリューションアーキテクトです。AWS のお客様がクラウドでイノベーションを実現するための支援を推進しています。 Ajit Mahareddy はプロダクトおよび Go-To-Market (GTM) の経験豊富なリーダーで、プロダクトマネジメント、エンジニアリング、Go-to-Market の分野で 20 年以上の経験を持っています。現在の役職に就く前は、Uber、Turing、eHealth などの大手テクノロジー企業で AI/ML プロダクトのプロダクトマネジメントを率いていました。生成 AI 技術の発展と、生成 AI による実社会へのインパクトの創出に取り組んでいます。 Sofian Hamiti は 12 年以上にわたり AI ソリューションの構築に携わってきたテクノロジーリーダーで、顧客の成果を最大化するハイパフォーマンスチームを率いてきました。多様な人材がグローバルなインパクトを生み出し、キャリア目標を達成できるよう支援することに取り組んでいます。 <!-- '"` --> 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

本記事は2026年8月12日に公開された「 Part 2: Amazon Bedrock cost attribution with Amazon Athena and CUDOS 」を翻訳したものです。 Part 1 では、Amazon Bedrock のきめ細かなコスト配分について紹介しました。この機能は、すべての推論リクエストを API コールを実行した IAM プリンシパルまで自動的に追跡します。新しい line_item_iam_principal 列によって、ユーザーごとおよびアプリケーションごとの可視性が得られることを示しました。オプションのコスト配分タグを使用すれば、AWS Cost Explorer を使ってチーム別、プロジェクト別、またはテナント別に支出を集計することもできます。このアプローチにより、Claude Code や Codex などのサードパーティツールであれ、独自に構築したものであれ、Bedrock を活用するあらゆるサービスやアプリケーションの利用状況を、必要な粒度で追跡できるようになります。この記事では、Amazon Athena クエリと CUDOS ダッシュボードを使用して、Amazon Bedrock のコスト配分を可視化・分析する方法を紹介します。 まず、この記事では Cost and Usage Report (CUR) 2.0 を IAM プリンシパルデータを含む Data Exports で設定する方法を説明します。次に、Amazon Athena を使用して CUR データをクエリし分析する方法を示します。その後、Bedrock のきめ細かなコストおよび使用状況データを含む、CUDOS ダッシュボードの新機能を紹介します。Athena は集計の柔軟性、さまざまなビジネスインテリジェンス (BI) ツールとの統合、チャージバックプロセスへの対応に優れている一方、CUDOS は自組織の構造に応じたビジュアルがあらかじめ用意されています。 IAM プリンシパルごとおよび使用タイプごとの Amazon Bedrock コストを示すクエリ出力例 Cost and Usage Reports (CUR 2.0) の設定 Amazon Bedrock のコストを分析する前に、CUR 2.0 のデータエクスポートを設定し、Amazon Athena に接続する必要があります。 前提条件 以下が必要です: 請求コンソールへのアクセス権を持つ AWS アカウント CUR 2.0、S3、Athena に対する IAM アクセス許可 CUR データを保存するための S3 バケット SQL と AWS マネジメントコンソールの基本的な知識 (オプション) 自動セットアップのための Claude Code または Kiro-CLI 必要な IAM アクセス許可 があることを確認してください。 Amazon Bedrock のコスト配分を利用するには、CUR 2.0 のデータエクスポートで IAM プリンシパルデータを有効にして、 line_item_iam_principal 列と関連する IAM プリンシパルタグのデータが記録されるようにする必要があります。 IAM プリンシパルデータを含む CUR 2.0 データエクスポートの作成 「 Creating a standard export 」の手順に従って CUR 2.0 のデータエクスポートを設定してください。データエクスポートを設定する際、最終的な設定に以下のオプションが含まれていることを確認してください。 発信者 ID (IAM プリンシパル) の割り当てデータを有効にした CUR 2.0 データエクスポートの作成 「 その他のエクスポートコンテンツ (Additional export content) 」で、以下のチェックボックスを選択します: 「 発信者 ID (IAM プリンシパル) 割り当てデータを含める (Include caller identity (IAM principal) allocation data) 」 — これが line_item_iam_principal 列にデータを記録し、コストデータに IAM プリンシパルタグ ( iamPrincipal/ プレフィックス付き) を表示させるための重要な設定です。 「 データテーブルの設定 (Data table configurations) 」において: 「 時間粒度 (Time granularity) 」: 最大限の詳細を得るために「時間単位 (Hourly)」を選択します。 「 データエクスポート配信オプション (Data export delivery options) 」において: 「 ファイルのバージョニング (File versioning) 」: 重複データの保存を避けるために「既存のデータエクスポートファイルを上書き (Overwrite existing data export file)」を選択します。 重要: IAM プリンシパルデータを有効にすると、CUR ファイルのサイズが増加します。これは、以前は 1 行だった使用量が、その使用量に寄与した各 IAM プリンシパルごとに 1 行ずつ、複数行に展開されるためです。多数の異なるプリンシパルを持つ大量のワークロードの場合は、Amazon S3 のストレージを適切に計画し、古い CUR ファイルに対して Amazon S3 ライフサイクルポリシー の使用を検討してください。 AWS が最初の CUR 2.0 レポートを S3 バケットに配信するまで、最大 24 時間かかる場合があります。 CUR 2.0 の Amazon Athena への接続 Amazon Athena を使用すると、インフラストラクチャを管理することなく、標準 SQL で CUR データをクエリできます。このセットアップを効率化するために、Claude Code、Kiro-CLI、Codex などの AI アシスタントで使用できる agent.md スキルリポジトリが用意されています (オプションで利用可能)。これにより、Athena 環境を CUR データに接続する一連のプロセスを自動化できます。 ※ 訳注: エージェントを実行するには、リポジトリの README に記載された最小権限の IAM ポリシーが必要です。 リポジトリをクローンします ( git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking )。 このディレクトリで Claude Code ( claude ) または Kiro CLI ( kiro ) を起動します。 以下のようにプロンプトを入力します: 「agent.md を読み、そのワークフローに従って Cost and Usage Report のトラッキングを設定し、当月の Amazon Bedrock のプリンシパル別クエリを実行してください。」 手動のセットアップ手順 に従うこともできます。 CUDOS ダッシュボードも合わせてデプロイする予定がある場合は、 AWS CloudFormation からデプロイ できます。このプロセスの一部として、Athena クエリデータベースもデプロイされます。 デプロイが完了したら、以下のサンプルテストクエリを Athena クエリエディタ で実行できます。 SELECT line_item_iam_principal, line_item_usage_type, line_item_unblended_cost --# Note: replace your_cur_table_name, like `cid_data_export.cur2` FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND line_item_iam_principal IS NOT NULL LIMIT 10; このクエリが IAM プリンシパルの ARN と Bedrock の使用タイプを含む行を返せば、セットアップは完了しており、より詳細な分析を行う準備が整っていることになります。 Bedrock コスト追跡のための Athena クエリパターン CUR 2.0 データが Athena で利用可能になったので、SQL を使用してきめ細かなコスト配分に関する質問に答えることができます。このセクションでは、最も一般的な分析シナリオをカバーする 3 つのクエリパターンを、シンプルなものから高度なものまで段階的に紹介します。 注: 以下のクエリでは、 your_cur_table_name を実際の CUR Athena テーブル名 (例: cid_data_export.cur2 ) に置き換えてください。 クエリ 1: IAM プリンシパルおよび使用タイプ別の Bedrock コスト このクエリは、発信者 ID とモデル使用量別に Amazon Bedrock の支出を完全に分解します。これは「誰がどのモデルを呼び出していて、いくら使っているか?」という質問に答えるものです。 SELECT line_item_iam_principal, line_item_usage_type, SUM(line_item_usage_amount) AS total_tokens, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL -- AND line_item_usage_type LIKE '%Sonnet%input%' GROUP BY line_item_iam_principal, line_item_usage_type ORDER BY total_cost DESC; 出力例: line_item_iam_principal line_item_usage_type total_tokens total_cost arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USW2-anthropic.claude-opus-4-8-mantle-cache-write-tokens-standard 1629.5 $11.2029 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USW2-Claude4.6Sonnet-output-tokens 68.579 $1.131 arn:aws:sts::123456789012:assumed-role/ClaudeCode/chat USW2-Claude4.6Sonnet-cache-write-input-token-count 831.74 $3.4309 arn:aws:iam::123456789012:user/alice USW2-Claude4.6Sonnet-input-tokens 17.33 $0.0572 分析にあたってのヒント: line_item_usage_type LIKE '%Sonnet%output%' や %nova% のような LIKE パターンを使用して、特定のモデルでフィルタリングできます。 line_item_iam_principal 列には完全な ARN が含まれています。引き受けたロールの場合、最後の / の後のセッション名で特定のユーザーやセッションを識別できます。 クエリ 2: 既知の IAM プリンシパルタグ別のコスト内訳 IAM プリンシパルに team 、 project 、 costcenter などのディメンションでタグを付け (さらにそれらをコスト配分タグとして有効化した場合)、CUR 2.0 データの tags 列に iamPrincipal/ プレフィックスに続くタグキーとして表示されます。このクエリを使えば、それらのタグでコストをグループ化し、 「今月エンジニアリングチームが Bedrock にいくら使ったか？」 や 「チャットボットプロジェクトの Bedrock の合計コストはいくらか？」 といった質問に答えることができます。 プロジェクト別の場合: SELECT tags['iamPrincipal/project'] AS project, line_item_usage_type, SUM(line_item_usage_amount) AS total_tokens, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL GROUP BY tags['iamPrincipal/project'], line_item_usage_type ORDER BY total_cost DESC; 出力例: project line_item_usage_type total_tokens total_cost data-science USW2-Claude4.5Sonnet-cache-write-input-token-count 433.893 1.789808625 data-science USW2-Claude4.6Sonnet-cache-read-input-token-count 5372.659 1.77297747 engineering USW2-Claude4.5Sonnet-input-tokens 29.481 0.0972873 engineering USW2-Claude4.5Sonnet-output-tokens 31.102 0.513183 注: このクエリは、IAM プリンシパルに該当するキーでタグが付けられており、かつそれらのタグがコスト配分タグとして有効化されている場合にのみ結果を返します。 クエリ 3: UNNEST を使用した未知のタグスキーマの動的検出 大規模な組織では、すべての IAM プリンシパルにどのタグが適用されているか事前にわからない場合があります。チームによって異なるタグキーを使用していたり、時間の経過とともに新しいタグが追加されたりすることがあります。以下の例では、Athena の UNNEST 関数を使用して動的にタグを探索する方法を示します。 このクエリは、Bedrock ワークロード全体で使用されているすべての IAM プリンシパルタグを検出し、各タグのキーと値のペアごとのコスト配分を表示します: WITH iam_principal_costs AS ( SELECT t.key AS tag_name, t.value AS tag_value, line_item_usage_type, line_item_unblended_cost FROM your_cur_table_name CROSS JOIN UNNEST(tags) AS t(key, value) WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService') AND line_item_iam_principal IS NOT NULL AND line_item_iam_principal != '' AND t.key LIKE 'iamPrincipal/%' ) SELECT tag_name || ': ' || tag_value AS tags, line_item_usage_type, SUM(line_item_unblended_cost) AS total_cost FROM iam_principal_costs GROUP BY tag_name, tag_value, line_item_usage_type ORDER BY total_cost DESC; 実際のユースケース: マルチサービスのコスト比較 複数の AI 搭載サービスを運用するプラットフォームチームを考えてみましょう。例えば、ドキュメント要約パイプライン (DocProcessor) と顧客向けチャットボット (ChatApp) を運用しているとします。チームは各サービスに独自の IAM ロールを割り当てることができます。前のセクションのクエリパターンを使えば、以下のクエリで各サービスの支出の推移を個別に確認できます。 SELECT line_item_iam_principal, line_item_usage_type, SUM(line_item_usage_amount) AS total_usage, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL AND ( line_item_iam_principal LIKE '%DocProcessor%' OR line_item_iam_principal LIKE '%ChatApp%' ) GROUP BY line_item_iam_principal, line_item_usage_type ORDER BY total_cost DESC; 出力例: line_item_iam_principal line_item_usage_type total_usage total_cost arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USE1-Claude4.6Sonnet-output-tokens 4,800,000 $72.00 arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USE1-Claude4.6Sonnet-input-tokens 2,900,000 $8.70 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USE1-NovaLite-output-tokens 6,100,000 $1.46 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USE1-NovaLite-input-tokens 3,200,000 $0.19 この出力から、プラットフォームチームは以下のような質問に答えることができます。 今月の Bedrock 支出に最も寄与しているアプリケーションはどれか？ &nbsp;この例では、ChatApp が Claude 4.6 Sonnet を使用して 80 ドル以上を占めている一方、DocProcessor は Nova Lite を使用して 5 ドル未満に収まっています。 ワークロードごとに異なるモデルを使用することでコストを削減できるか？ &nbsp;DocProcessor は既に Nova Lite (単純な要約タスクに適しています) を使用しています。一方、ChatApp の一部のやり取りをより軽量なモデルで処理できれば、チームとしては現在 72 ドルかかっている出力トークンコストを削減できる可能性があります。 Athena クエリのコスト 料金は実行したクエリに対してのみ発生します。各クエリでスキャンされたデータ量に基づいて課金されます。各クエリの実行後に Athena コンソールでこの情報が表示されるほか、「最近のクエリ」タブでも確認できます。 Athena クエリの課金は、スキャンしたデータ 1 TB あたり 5 ドルです (クエリあたり最低 10 MB)。このテーブルは billing_period に対して Hive パーティションプロジェクション を自動的に使用するため、単一の月にスコープを限定したクエリはその月のフォルダ内の Parquet ファイルのみをスキャンします。スキャン量は通常 10 MB を大きく下回るため、クエリあたりのコストは約 0.00005 ドル (10 MB の最低料金) です。 ※ 訳注: 料金はリージョンによって異なる場合があります。最新の料金は&nbsp; Amazon Athena の料金ページ &nbsp;をご確認ください。 コストを低く抑えるために、常に WHERE billing_period = ... フィルタを含め、 SELECT * ではなく必要な列のみを選択するようにしてください。 Cloud Intelligence Dashboards フレームワーク CUDOS ダッシュボード は、オープンソースの Cloud Intelligence Dashboards (CID) フレームワーク の一部であり、提供されている Infrastructure as Code (IaC) テンプレートを使用して AWS アカウントにデプロイできます。このフレームワークにより、AWS 組織全体で財務上の説明責任を果たし、運用効率を高めることができます。CUDOS ダッシュボードは、詳細で実用的なインサイトを提供し、AWS インフラストラクチャ全体のコスト効率に関するデータドリブンな意思決定を支援します。 CUDOS における Amazon Bedrock のコストおよび使用状況インサイト CUDOS バージョン 5.8 では、AI/ML タブに包括的な Amazon Bedrock セクションが導入され、IAM プリンシパルによるコスト配分を完全にサポートしています。このダッシュボードは以下を提供します。 柔軟なグルーピングディメンション: Amazon Bedrock の支出を、IAM プリンシパル、IAM プリンシパルタグ (プロジェクトやチームなど)、モデル/リソースグループ、リージョン、またはダッシュボードのデプロイ時に設定したその他のコスト分類フィールドでグループ化できます。 100 万トークンあたりのコスト追跡: 支出チャートに重ねて表示されるトレンドラインにより、100 万トークンあたりのコストが時間の経過とともにどのように変化しているかを確認できます。これにより、モデル選択の変更やプロンプト最適化の取り組み (例えばキャッシュなど) の効果を測定できます。 以下の図は、CUDOS ダッシュボードの AI/ML タブにある Amazon Bedrock Summary セクションを示しています。IAM プリンシパル別にグループ化され、プリンシパルごとのコスト内訳と 100 万トークンあたりのコストのトレンドが表示されています。 IAM プリンシパル別にグループ化された Amazon Bedrock の支出を表示する CUDOS ダッシュボード インタラクティブなドリルダウンフィルタリング: トップレベルの支出チャートで任意の値 (特定のプロジェクト、プリンシパル、アカウントなど) を選択すると、他のすべてのビジュアルが自動的にその選択内容でフィルタリングされます。これにより、ダッシュボードから離れることなく、概要レベルからモデル別や使用タイプ別の詳細へとドリルダウンできます。 きめ細かなモデルおよび使用状況の内訳: トップレベルのチャートでフィルタリングされた追加のビジュアルにより、モデル別、使用タイプ別の支出、およびモデル別の 100 万トークンあたりのコストが表示されます。これにより、特定のチームやプロジェクトのコストを押し上げているモデルやトークンタイプを特定できます。 グルーピングを「IAM Principal Tag Project」に切り替えて特定のプロジェクト (この例では「chatbot-v2」) を選択すると、他のすべてのビジュアルが自動的にフィルタリングされ、そのプロジェクトの支出のみが表示されます。各ビジュアルでは、その支出がモデル別、使用タイプ別、および単価のトレンドとして分解されます。 IAM プリンシパルタグ「Project」別にグループ化され、chatbot-v2 プロジェクトでフィルタリングされた Amazon Bedrock の支出を表示する CUDOS ダッシュボード これらのビジュアルにより、SQL を書くことなく、「出力トークンコストを最も押し上げているプロジェクトはどれか?」「チャットボットチームはコスト効率の良いモデルを使用しているか?」「Opus から Sonnet に切り替えてから 100 万トークンあたりのコストはどう変化したか?」といった質問にすばやく答えることができます。 CUDOS の利用を開始する CUDOS の利用を開始するにあたって、 インタラクティブなデモ ダッシュボードで Bedrock セクションを試すことができます。自身の組織に CUDOS をセットアップするには、 デプロイガイド に従ってください。 既に CUDOS を使用している場合は、 アップデートガイダンス に従ってバージョン 5.8 にアップグレードしてください。また、 組織分類 (organizational taxonomy) の追加 により、既存の CUDOS ダッシュボードに IAM プリンシパルデータを追加することもできます。 クリーンアップ まず、Athena テーブルと AWS Glue データベースを削除します (これらはメタデータであるため、実行中のコンピューティングリソースはありません)。 警告: Athena テーブルと Glue データベースを削除すると、CUR データをクエリできなくなります。将来的に請求データを分析したい場合は、前述のセクションに従ってこれらのリソースを再作成する必要があります。 aws glue delete-table --region us-east-1 --database-name your_cur_table_name --name curexport aws glue delete-database --region us-east-1 --name your_cur_table_name 次に、コストデータ自体が不要になった場合は、AWS Billing and Cost Management コンソールの Data Exports でエクスポートを無効にし、書き込み先の S3 プレフィックスを空にしてください。これは生の請求履歴であるため、確実に不要であることを確認した上で削除してください。 最後に、蓄積された Athena クエリ結果をクリアします。 aws s3 rm s3://&lt;your-cur-bucket&gt;/athena-results/ --recursive 削除すべきクローラー、AWS Lambda 関数、スケジュールはありません。パーティションプロジェクションを使用しているため、継続的なコストは CUR ファイル自体の S3 ストレージのみであり、通常は月あたり数セントです。 CUDOS のクリーンアップについては、 CUDOS ダッシュボードの削除手順 を参照してください。 まとめと次のステップ この 2 部構成のシリーズでは、Amazon Bedrock の推論コストを理解し管理するための包括的なツールキットを紹介しました: Part 1 では、きめ細かなコスト配分を紹介しました。Amazon Bedrock がすべての推論コールについて、それを実行した IAM プリンシパルを自動的に記録する仕組みと、コスト配分タグを使用してチーム別、プロジェクト別、またはテナント別に支出を集計する方法を説明しました。 Part 2 (この記事) では、そのデータを活用する方法を示しました。IAM プリンシパルデータを含む CUR 2.0 の設定、Amazon Athena でのコストパターンのクエリ、プロジェクトやプリンシパル間での支出比較によるコスト配分の意思決定への活用について説明しました。また、Bedrock に関する同様のインサイトを備えた包括的な AI/ML シートを提供する CUDOS ダッシュボードも紹介しました。 AWS Billing コンソールで発信者 ID データを含む CUR 2.0 を有効にし、提供されている agent.md ファイルを使用して Athena に接続し、最初のプリンシパル別コストクエリを実行してみてください。CUDOS ダッシュボードを使えば、組織全体での Bedrock の導入状況を追跡できます。 著者について Abhi Shivaditya Abhi は AWS のプリンシパルソリューションアーキテクトで、戦略的なグローバルエンタープライズ組織と連携し、人工知能、分散コンピューティング、ネットワーキング、ストレージなどの分野における AWS サービスの導入を支援しています。Abhi は、AWS エコシステム内で高性能な機械学習モデルを効率的にデプロイするお客様を支援しています。 Brenno Passanha Brenno はシニアテクニカルアカウントマネージャーです。Cloud Operations Technical Field Community に所属し、クラウド財務管理に取り組んでいます。仕事以外では、子育て、世界各地への旅行、新しい体験を通じた思い出づくりを楽しんでいます。 Yash Yamsanwar Yash は Amazon Web Services (AWS) の機械学習アーキテクトで、大規模 LLM 推論およびエージェント型 AI システム向けの高性能でスケーラブルなインフラストラクチャを設計しています。トレーニングから本番デプロイまで、機械学習モデルのライフサイクル全体にわたる業務に携わっており、大規模な生成 AI システムの最適化に注力しています。Yash は ML リサーチチームと緊密に連携し、大規模言語モデルやその他の最先端機械学習技術の可能性を広げる取り組みを行っています。 <!-- '"` --> 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの 最終回 となる第 8 回レポートです。シリーズの背景や全体像については、 大阪・IT 企業編レポート をご覧ください。 前日（5 月 14 日）の AI を自社の業務に活かしたい企業の皆様向けセッション に続き、2026 年 5 月 15 日は同じ北海道にて、AI で顧客を支援する IT 企業のエグゼクティブ・技術部門の皆様をお迎えし、「 AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 」と題したイベントを開催しました。会場は前日に引き続き、北海道で地域密着の技術支援を続ける クラスメソッド株式会社 の札幌オフィスをお借りしました。 イベントの流れ 当日はまず、私 Amazon Web Services Japan のソリューションアーキテクト田中から「AWS で一歩先へ！生成 AI 時代のビジネスモデル変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる存在」へと進化してきた流れを整理しながら、AI エージェント時代に IT 企業がお客様の期待にスピーディーかつ継続的に応え続けるための打ち手として、 Kiro のデモを交えながら解説しました（AWS セッションの詳細については 大阪・IT 企業編のレポート をご覧ください）。 AWS セッションを通じて AI エージェント時代のビジネス変革の全体像をつかんでいただいたあと、事例セッションへと進みました。北海道に根差し、自社の開発現場で AI 活用に挑戦し続けている企業の実体験をお話しいただきました。 事例紹介：株式会社アドウイック様 〜「低い点数でもいい」──小さな成功体験が若手エンジニアを変えた AI 活用〜 ご登壇いただいたのは 株式会社アドウイック 技術部 次長の菅原 幸憲 様です。アドウイックは 1977 年創業、親会社のほくやく・竹山ホールディングス（医薬品卸・医療機器・薬局・介護など北海道に根差した総合ヘルスケアグループ）の ICT 事業を一手に担うシステム会社です。グループ会社向けシステムや医療機関向けシステムに加え、業種業界を問わないシステム開発も手がけており、医療機関の待ち時間短縮を目的とした自社製品「シマエナガ・シリーズ」なども展開しています。 ベテランへの集中と人材育成のジレンマ 菅原様はまず、長年抱えてきた課題として人材不足を挙げられました。新卒・若手中途採用はある程度できているものの、育成に時間がかかる。急ぎの案件が多くてナレッジが広がらない。結果としてスピードが上がらず、新しいチャレンジもなかなかできないという状況でした。若手を即戦力に育てることと、ベテランへの集中を解消することを同時に実現するために、2025 年 1 月に AI 活用をスタートさせました。「今いるメンバーでより多くのことを行っていくために、AI を活用していこう」と決断した時点では、ベテランを交えて一緒に挑戦する余裕もない状況でした。だからこそ「若手を中心にチャレンジする」という方針を取ったといいます。 5 名チームで始めた検証、VS Code の延長線上で始められる Cursor を選択 検証はまず、菅原様ご自身が個人でいくつかのツールに課金して試すところから始まりました。「まずやってみる」を自ら体現するスタートです。その後 5 名の少人数チームで複数のコーディングエージェントを比較検証し、品質・スピード・再現性の観点から効果が見込めることを確認した上でプロジェクト全体への展開に踏み切りました。採用したツールは Cursor です。AWS のイベントで Kiro ではなくて申し訳ない、と照れ笑いを交えながら、菅原様は選定理由を語ってくださいました。「VS Code の置き換えが容易なこと」と「複数のモデルが利用できること」──既存の開発環境からの移行ハードルが低く、若手がすぐ使い始めやすい点を重視した選択でした。 3 つのアプリで積み上げた「成功体験」 取り組みを開始してからの 1 年で、チームは Cursor を使って 3 つのサービスをゼロから開発しました。 1 つ目は、FileCarrier というファイルの安全な送受信サービスです。サーバーレス構成を採用し、大事なファイルを扱うためセキュリティには特に力を入れて構築しました。「意識して作ったつもりでも、やはり不安は拭えなかった」と菅原様は振り返られました。そこでクラスメソッドさんに構成レビューを依頼し、お墨付きをもらったことで安心して社内展開を進めることができたといいます。現在は社内利用にとどまっていますが、今後は社外へのサービス展開も視野に入れており、コスト最適化の構成も Cursor と壁打ちしながら固めています。 2 つ目は、BizcaHolder という名刺管理アプリです。アドウイックとして初めて AI を活用したサービスで、もともとは OCR サービスを使っていましたが、読み取り精度がなかなか上がらないという課題がありました。そこに Amazon Bedrock 上の Claude を活用し、AI による文字認識に切り替えたところ、縦書きも横書きも問題なく読み取れるほど精度が格段に向上しました。 3 つ目は、MIMOMO という議事録作成アプリです。音声から文字起こしを実施して AI が要約し、その内容を社内テンプレートにはめ込む、というフローを実現しています。社員からはこの 3 つの中でも特に好評を得ているといいます。 成功体験の連鎖が組織の意欲を引き上げる 菅原様がこの取り組みを通じて大事にした考え方は 3 つです。1 つ目は「まずやってみること」。「いきなり 100 点を狙うのではなく、低い点数でもいいので、まずは試してみる」という姿勢です。実は菅原様、資料作成時には「60 点でいい」と書いていたそうですが、「60 点にこだわる必要もない」と考え直し、「低い点数でも」という表現に変えたのだといいます。前日に同じ会場でご登壇いただいた 北海道文化放送様 の「ある程度で一旦始めてみる」というメッセージと、偶然重なった瞬間でした。2 つ目は「小さく始めること」。大きなシステムを一気に作るのではなく、小さいアプリ・小さい機能から着手してブラッシュアップを繰り返す。3 つ目は「メンバーを巻き込むこと」。指示して動かすのではなく、一緒にやる。各アプリはメンバーを入れ替えながら開発し、参加者を増やして輪を広げていったといいます。 こうした小さな成功体験の積み重ねは、組織に目に見える変化をもたらしました。2016 年から AWS を利用し勉強会も重ねてきたアドウイック様ですが、AI 活用に本格的に取り組む前はクラウドプラクティショナーを取ったら満足という状況が続いていました。ところが昨年は、AWS のプロフェッショナル・スペシャリティ級を含む資格の取得数が、メンバー全体で 1 年に 20 個近くにのぼりました。資格手当・受験料支給・一発合格報奨金といった会社の支援制度との相乗効果で、若手がチャレンジに踏み出すハードルが大きく下がったことも後押しになっています。 見えてきた課題と、次のチャレンジ 一方で課題も見えてきました。経験の浅いメンバーほど AI への依存度が高くなり、AI が生成したコードをそのまま採用してバグが発生するケースが出てきました。また、利用するモデルによってはすぐ上限に達してしまう点もあり、コストを意識した活用の設計が次のテーマになっています。 今後の展望として、社内アプリ開発の継続（すでに 2 つのアプリを作成中）とともに、今回構築したサービスの社外製品化の準備も進めています。50 年近い歴史を持つ会社ならではのレガシーシステムのモダナイゼーションにも、小さな分析から着手しています。運用面では、ルールの見直しに加え MCP の活用による品質・スピードのさらなる向上を模索しているほか、社内での利用拡大に向けた情報共有や勉強会も検討中とのことです。そして菅原様が力を込めて話されたのが、外部との連携強化です。「今まで自社内でなんとかしようという意識がメンバーに強かった」と振り返りながら、今後は AWS のトレーニング・ハンズオン、クラスメソッドさんへの構成レビューやセキュリティ相談など、外部パートナーを積極的に活用していきたいと述べられました。セッション後の質疑応答では「札幌に知見のある会社が構えていてくれる安心感は大きい」という言葉もあり、地域に技術パートナーがいることの価値を改めて感じさせる一幕でした。コミュニティへの参加を通じた外部発信も、次のチャレンジとして挙げていただきました。 写真: 株式会社アドウイック 菅原様によるセッション まとめ 全 8 回にわたり大阪・名古屋・広島・福岡・北海道の 5 拠点を巡ってきた本シリーズを通じて、各地で共通して、AI を「完璧になってから使う」のではなく、「最初のゴールは小さく設定して、すぐ試す」というスタイルが、組織の変化を生み出していることが見えました。本シリーズが、読者の皆様の「まず一歩を踏み出す」きっかけになれば幸いです。 AWS では、日本全国の様々な拠点に対して、最新情報の発信や、AI に関するお取り組みのご支援を今後も行っていきます。 もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に AI を活用したビジネス変革に取り組みたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 博多編（#6/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 北海道編（#7/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 7 回レポートです。シリーズの背景や全体像については、 初回の大阪・事業会社編レポート をご覧ください。 大阪・名古屋・広島・福岡に続き、2026 年 5 月 14 日は北海道にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。会場は、北海道で地域密着の技術支援を続ける クラスメソッド株式会社 と共催で、札幌オフィスをお借りする形で開催いたしました。 写真: クラスメソッド株式会社札幌オフィスでのイベント当日の様子。クラスメソッド東日本営業本部 本部長三浦様よりご挨拶 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村 友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: ソリューションアーキテクト木村によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、事例セッションへと進みました。ここでは、AI によるナレッジ継承の新しいアプローチに取り組む企業様に、その現場で得られた知見をお話しいただきました。 事例紹介：クラスメソッド株式会社様 &amp; 北海道文化放送株式会社様 〜暗黙知をデジタル資産に変える、AI によるナレッジ継承〜 事例紹介は、 北海道文化放送株式会社（UHB） 営業推進部 武舎 巧真 様と クラスメソッド株式会社 AI Experience Center Director 舘野 勉 様の共同登壇です。UHB は、1972 年開局のフジテレビ系列のテレビ局で、北海道を拠点に報道・情報番組から地域密着コンテンツまで幅広く手がける放送会社です。当日はクラスメソッド舘野様より新サービス ghoost 誕生秘話のご紹介を、UHB 営業推進部の武舎様から、実際に ghoost を活用したお取り組みの事例をお話しいただきました。 組織の「知恵」はなぜ継承されないのか 「AI をただ導入しただけだと、使う人となかなか利用にいたらない人が存在し、生産性の幅が生じてしまう。優秀な人の知見を組織全体に広めることに課題を持っている企業は多い」。舘野様は、ツールの機能の優劣以上に「自分の業務にどう絡ませるか」のデザインが成果に大きく影響する、という経験則を持っておられました。この問いから生まれたのが、クラスメソッドが開発した AI エージェントサービス ghoost です。 ghoost は、個人の知見・思考パターン・判断基準をインタビューと分析を通じて AI エージェントとして再現するデジタルツインサービスです。初期エージェントの生成は 1〜2 時間という迅速さで、1 人のユーザーに対して「職種のスペシャリストとしての顔」「チームリーダーとしての顔」といった複数の側面を多面的に合成して構成するところが特徴です。同僚や後輩がそのゴーストにいつでも話しかけられる環境をつくることで、「欲しいときに欲しい情報をすぐ回答してもらえる環境」を組織全体に届けることを目指しています。このように、普段の業務と密接に関連した知識を持ち、普段の業務判断に近い応答結果を出力できることで、AI がまるでチームメンバーの一人のように普段の業務に参加していくことを目指したサービスです。2026 年 3 月に開始した クラスメソッドでの早期検証では、16 名を対象に 162 セッションを実施し、生成された ghoost の回答のうち 92.3% が「本人らしい」と第三者に評価されました 。 暗黙知を「動くデジタル資産」に変える挑戦 UHB 武舎様は「番組制作に関わる業務は、ベテランの経験と感性に強く依存することが多かった」と、テレビ制作業界の特性について語られました。こうした属人化の課題は、視聴率分析の業務においても見られ、相談が特定の専門家に集中しやすく、ナレッジが個人の中に閉じやすいという課題を長年抱えていました。 これに対する打ち手として、ghoost を活用し、個人の知見をデジタルツインとして再現することで課題解決につなげる方向性を議論し、クラスメソッドと共同で PoC をスタートしました。PoC を始めるにあたり、「過去に突発的な案件を短いスケジュールで応えていただいた」、「リモートが当たり前になった今でも、拠点が近く、必要な時にすぐ顔を合わせて議論できる」点があったからこそ、信頼感を持って新しい取り組みに踏み出せたということです。 検証で成果を測り、現場に根づかせる UHB 様では、社員へのインタビューを通じて、個人の知見や判断基準を ghoost として再現する検証を進めました。また、検証フェーズに入る前には、導入可否を判断しやすくするため、あらかじめ撤退基準を設ける工夫も行いました。評価にあたっては、ROI の見える化（定量値）と、ghoost を実際に活用した社員自身が「これは自分らしい」と感じられるかどうか（定性値）、の二軸で検証しました。この基準を事前に定めておいたことで、結果として投資判断がしやすい状況を整えることができたということです。 UHB の武舎様は、「今後も地道な伴走が不可欠で、現場が主体的にこのツールを活用していくまでに、粘り強い活動も必要」と述べられました。さらに、「残業時間の削減、作業効率の向上、といった短期的な成果に加えて、『浮いた時間を思考的・戦略的な業務に投入できる』という中長期的な成果の価値を、社内で伝え続けることも重要」とも述べられました。 さらに「自分たちにとって 100 点のサービスを期待していると、待っているだけで終わってしまう。ある程度で一旦始めてみて、信頼できる方に相談しながら進めるといい」と、信頼のおけるプロジェクト体制の重要さも語られました。 写真: UHB 武舎様 によるセッション まとめ セッション後のディスカッションタイムやネットワーキングでは、参加者同士で自社の AI 活用における課題について活発な議論が交わされました。北海道内の異業種の参加者が一堂に会する、忌憚のない情報交換ができた場になったと感じています。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしています。次回はシリーズ最終回、北海道 IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 博多編（#6/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

20 年前の 8 月 25 日、 Jeff Barr が Amazon EC2 ベータ版を公開したブログ記事を書きました。その記事では、1 つのリージョン (米国東部) で 1 つのインスタンスタイプ ( m1.small ) の、時間単位で課金されるサイズ変更可能な Linux 仮想サーバーをクラウド内で紹介しました。最小限でありながら有用であり、コンピューティングインフラストラクチャに対する世界の考え方を変えました。 2021 年、Jeff は EC2 の 15 年にわたる歴史について、その裏話や記憶に残る EC2 の立ち上げについて取り上げました 。過去 5 年間、AWS はクラウドコンピューティングが提供できることの限界を押し広げ続け、汎用ワークロードと AI ワークロード用のカスタムシリコンを構築し、2006 年のお客様が想像もできなかった新しいフォームファクターとデプロイモデルに EC2 を拡張してきました。 20 年の概要 Jeff は 15 周年記念記事の中で、今日でも顧客が頼りにしている基本的なビルディングブロックを確立した EC2 の重要なマイルストーンを選びました。 Amazon Elastic Block Store (2008) は永続ブロックストレージを提供しました。 エラスティックロードバランシング、オートスケーリング、Amazon CloudWatch (2009) により、アプリケーションのスケーラビリティと可用性が高まりました。 Amazon 仮想プライベートクラウド （2009）は、顧客に論理的に分離されたネットワークを提供しました。 AWS Nitro System (2017) は、より迅速なイノベーションと強化されたセキュリティを実現しました。 AWS Graviton プロセッサ (2018) は、コスト重視のスケールアウトワークロード向けに設計されました。 20 年以上かけて、EC2 は 1 つのインスタンスタイプから 1,200 を超えるインスタンスタイプへと成長し 、汎用、コンピューティング、メモリ、ストレージに最適化された、アクセラレーテッドコンピューティングファミリー、ハイパフォーマンスコンピューティングファミリーにわたる顧客のニーズに応えました。これらのインスタンスは、1 つの AWS リージョンから世界で 39 のリージョンに拡大しました 。また、AWS は EC2 インスタンスをローカルで実行する AWS Outposts (2018)、各地に配置する AWS ローカルゾーン (2019)、世界中の 5G 通信事業者ネットワーク内の AWS Wavelength (2019) により、リージョンの境界を越えて EC2 を拡張しました。 えこひいきはしたくありませんが、過去 5 年間の EC2 のリリースの中からお気に入りをいくつか選びたいと思います。 大規模な ML 推論のための AWS Inferentia (2019): AWS Inferentia チップを搭載した専用の ML 推論インスタンス (inf1) を導入しました。 Amazon EC2 Inf2 インスタンスは 、2023 年 4 月に大規模な生成 AI 推論ワークロード向けに一般公開されました。AWS Trainiumインスタンスは、Inferentiaファミリーとともに、推論とトレーニングの両方における AI ライフサイクルのあらゆる段階に最適化された、AWS が設計したシリコンのフルスタックを顧客に提供するようになりました。 EC2 Mac インスタンス (2020): 最初の Mac インスタンス (mac1) は、AWS ニトロシステム上のインテルコア i7 (コーヒーレイク) を搭載した Apple Mac mini 上に構築されました。 Mac M1 (mac2) インスタンスは、EC2 で初めての ARM ベースの macOS インスタンスとして 2022 年 7 月にリリースされました。 2023 年には M2 Pro Mac インスタンス 、 2025 年には M4とM4 Pro Mac インスタンス 、 2026 年にはM3 Ultra Mac インスタンスと M4 Max Mac インスタンスが続きました 。これにより、Apple の開発者は、macOS、iOS、iPadOS、tvOS、watchOS、および&nbsp; VisionOS アプリケーション向けの幅広いクラウドベースのビルドおよびテスト環境を利用できます。 大規模なフルスタック AI ワークロード向け AWS Trainium (2021) : 2021 年 11 月、ハイパフォーマンスなディープラーニングトレーニングに最適化された AWS Trainium アクセラレータを搭載した Trn1 インスタンスをプレビューしました。2024 年 12 月、AWS Trainium2 を搭載した Trn2 インスタンスがローンチされました 。 Trn2 UltraServer は NeuronLink を介して 64 基の Trainium2 アクセラレーターをリンクし、1兆パラメーターの基礎モデルをレーニングするためのものです。AWS re: Invent 2025 では、AWS Trainium3 を搭載した Trn3 UltraServer が、次世代のエージェント、推論、およびビデオ生成アプリケーションに最高のトークンあたりのコスト効率を提供します。1台の Trn3 UltraServer が最大144個の Trainium3 チップを相互接続して、最大規模のフロンティアモデルのトレーニングとサービスを提供します。現在、AWS Trainium3 は、ハイパフォーマンスな AI トレーニングと推論を大規模に実施する業界トップクラスのコストパフォーマンスを実現しています。 機械学習用 EC2 Capacity Blocks (2023): この新しい EC2 利用モデルは、機械学習と生成 AI モデルのトレーニングとデプロイに GPU インスタンスに簡単にアクセスできるようにすることで、ML の民主化をさらに促進し、ML の民主化をさらに促進します。必要な GPU 容量 (最初は P5 インスタンス ) を将来の日付のために予約し、必要な期間のみ予約します。&nbsp;2024 年 11 月、ML 用 EC2 キャパシティブロックは、 プロビジョニングを数分で行えること と、最長 6 か月まで延長できることをサポートするようになりました。 現在、ML 用 EC2 キャパシティブロックは、P5 に加えて P6-B300 、 P6-B200、P5e 、 P5en 、P4d 、P4de、Trn1、Trn2、Trn3 の各インスタンスをサポートしています。 AWS Graviton5 (2025): 2018 年から 8 年間続いてきた Graviton のイノベーションをもとに、AWS re: Invent 2025 で Graviton5 チップをプレビューし、Graviton5 を搭載し、第 6 世代の AWS Nitro System上に構築された M9g と M9gd インスタンス を立ち上げました。 C9gとC9gdは2026年6月に続きました 。現在、 Graviton5 は192コア、5 倍のキャッシュ、コア間のレイテンシーを最大&nbsp; 33%&nbsp; 低減するという特徴を備えているため、大規模で継続的かつ高スループットの CPU コンピューティングを必要とするリアルタイム推論、コード生成、マルチステップのタスクオーケストレーションなど、高まるエージェンティック AI ワークロードの需要の高まりに適しています。 AWS Nitro 分離エンジン (2026): お客様は、当社からの連絡だけでなく、Nitro ハイパーバイザーにおけるワークロード分離の証拠を見たいと考えていました。Nitro Isolation Engine は、Nitro Hypervisor内の専用コンポーネントであり、正式な検証を利用してお客様のワークロードが相互に、また AWS オペレーターから分離されていることを数学的に保証します。これにより、数学的に証明されたクラウドセキュリティの新しい標準が開拓されます。この機能も、2017 年の導入以来進化を続けてきた第 6 世代の AWS Nitro システムに基づいています。 その根底にある基盤 20 年にわたる革新にもかかわらず、Amazon EC2 の基本的な価値提案は変わっていません。お客様はこれを利用して、安全でサイズ変更可能なコンピューティング容量を数分で手に入れることができ、支払いは使用した分のみで、長期的な契約なしにオンデマンドで拡張できます。その柔軟性は、2006 年には誰も予想していなかった規模のAIワークロードにも及んでいます。 EC2 は依然として AWS の基盤となるコンピューティングレイヤーです。 Amazon ECS、 Amazon EKS 、AWS Lambda、AWS Fargate、AWS Batch 、 Amazon EMR、Amazon SageMaker AI、Amazon Bedrockは最終的に EC2 キャパシティで動作します 。シンプルなウェブサーバーから数兆のパラメータを持つ基礎モデルトレーニングクラスターまで、お客様が過去 20 年間に構築してきたすべてのアーキテクチャパターンは、インスタンスを起動する決定から始まります。 私たちは 2006 年に確固たる基本決定を下し、サービスを拡大する余地を残しました。20 年経った今も、最小限でありながら便利なサービスを作成し、迅速にリリースし、お客様のフィードバックに応じて迅速に反復するという戦略が、私たちが構築する方法の指針となっています。今後 20 年間のクラウドコンピューティングには、私たちがまだ想像していなかった機能が必要になります。Amazon EC2 は引き続き、お客様のワークロードを実行する基盤となります。 Amazon EC2 の詳細については、Amazon EC2 製品ページをご覧になるか 、 EC2 の新機能をご覧ください 。 – Channy 原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は 2026 年 7 月 17 日（金）、麻布台ヒルズの AWS ジャパンオフィスにて「Adtech Meetup ～変わる広告、変わらない価値 ― いまアドテク事業者が AWS に集まる理由～」を開催しました。アドテクノロジー（アドテク）・マーケティングテクノロジー事業を展開する企業 19 社から 39 名のお客様にご参加いただき、AI 時代の広告ビジネスの構造変化と成長戦略をテーマに、セッションと懇親会を通じて活発な議論と交流が行われました。 サードパーティ Cookie の廃止に代表されるシグナルロスや AI の台頭など、いまインターネット広告を支えるアドテク事業者は大きな転換点を迎えています。AWS はこうした変化に向き合うお客様を支援するため、リアルタイム広告取引（RTB: Real-Time Bidding）ワークロード専用のネットワークサービス AWS RTB Fabric を提供しており、 国内では株式会社 fluct 様と UNICORN 株式会社様による国内初の商用本番接続 が始まっています。本イベントは、この転換点を乗り越える新たな武器となる AI やインフラのトレンドをお届けすること、そして業界の垣根を越えた事業者間連携のきっかけを作ることを目的に企画しました。本記事では、イベントの模様をレポートします。 イベント概要 日時: 2026 年 7 月 17 日（金）16:00 – 19:00 会場: 麻布台ヒルズ 森JPタワー 36 階 AWS セミナールーム 参加者: アドテク・マーケティングテクノロジー関連企業 19 社 39 名 アジェンダ オープニング Session ①: AI が変えるプログラマティック広告 ― いま起きている変化と、これからの対応 Session ②: 広告コストを収益に変える – AWS RTB Fabric のご紹介 Session ③: パネルディスカッション「アドテク事業者の成長戦略 ― オープンエコシステムが切り拓く次の一手」 クロージング 懇親会・ネットワーキング オープニング イベントの冒頭では、AWS ジャパン 代表執行役員社長 白幡 晶彦より開会の挨拶を行いました。広告業界の各事業者の皆様が麻布台ヒルズに一堂に会したことへの感謝とともに、広告テクノロジーを取り巻く市場が大きく変化する中、お客様を起点にアドバタイジング領域に取り組んでいく AWS の姿勢を伝え、イベントの幕を開けました。 Session ①「AI が変えるプログラマティック広告 ― いま起きている変化と、これからの対応」 Speaker: 鈴木 康士郎（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） 最初のセッションでは、AWS ジャパンの鈴木より、プログラマティック広告を取り巻く 2 つの大きな変化を解説しました。1 つ目は、サードパーティ Cookie の廃止・制限やプライバシー規制の拡大により、ユーザーの興味や行動に基づく広告配信が困難になる「シグナルロス」、2 つ目は、生成 AI が検索から購買まで消費者行動に入り込む「AI の購買プロセスへの浸透」です。そのうえで、この変化に対応し成果を出している先行企業の取り組みを、(1) オーディエンスセグメンテーション × AI、(2) AWS Clean Rooms × AI、(3) メディアプランニング × AI、(4) Agentic AI の 4つの領域に整理して事例とともに紹介し、「変化への対応は『やるかどうか』ではなく『いつやるか』の問題」と締めくくりました。 Session ②「広告コストを収益に変える – AWS RTB Fabric のご紹介」 Speaker: 関藤 寛喜（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） 続いて、AWS ジャパンの関藤より、広告配信のインフラ層を支える AWS RTB Fabric を紹介しました。RTB では、一連の入札処理を概ね 100 ミリ秒以内に完了させる必要があります。この要件を満たすために維持する大規模なインフラのコストが利益を圧迫することが、SSP（Supply-Side Platform）/ DSP（Demand-Side Platform）事業者の構造的な課題となっています。 AWS RTB Fabric は、この課題を解決する RTB 通信に特化したネットワークサービスです。本イベントのタイトルにある「変わらない価値」、すなわちお客様が磨き上げてきた独自の入札ロジックや最適化アルゴリズムはそのままに、10 ミリ秒未満のレイテンシーと、標準的なクラウドネットワーク費用と比較して最大 80% のコスト削減を実現します。削減したコストと処理時間は、接続先の拡大による収益機会の最大化や、新たな取り組みへの投資に振り向けられます。サービスの詳細や海外事業者の導入事例については、 ブログ や AWS Black Belt の資料 をご参照ください。 Session ③ パネルディスカッション「アドテク事業者の成長戦略 ― オープンエコシステムが切り拓く次の一手」 パネリスト: 株式会社 fluct 代表取締役 COO 黒田 岳志 氏 UNICORN 株式会社 取締役 KYO 氏 モデレーター: 松本 鋼治（アマゾン ウェブ サービス ジャパン合同会社 戦略事業開発本部 プリンシパル事業開発マネージャー） パネルディスカッションでは、AWS RTB Fabric 上で国内初の商用本番接続を実現した SSP 事業者の fluct 様と DSP 事業者の UNICORN 様をお迎えし、事業課題から成長戦略、AI 時代の展望までを議論いただきました。 アドテク事業者が直面する転換点 議論の出発点となったのは、生活者のデジタル利用時間の約 55% を Open Web が占める一方、広告費は約 30% しか投資されていないというギャップです。Open Web へのシフトが進む中で自社がどう変わっていくか、そして「買っていただける在庫供給とは何か」をどう追求するかといった経営課題が挙がったほか、サードパーティ Cookie 廃止によるターゲティングへの影響や、リテールメディア・CTV といった新しい広告在庫の拡大など、業界の転換点を示すトレンドも共有されました。 課題にどう向き合うか ― データクリーンルームと AWS RTB Fabric の価値 こうした課題への打ち手として、パブリッシャーのデータを外部に出さずに活用するデータクリーンルームの取り組みや、オンラインとオフラインを横断する新しい配信インフラの構想が紹介されました。 インフラ面では AWS RTB Fabric が話題となり、SSP の立場からは、「リクエストを絞る」という売上を下げる行為をしなくてよくなることで、守りのコスト削減ではなく攻めのビジネスにエンジニアリソースを振り向けられるという価値が語られました。DSP の立場からも、リクエストを多く受けるほど売上が上がる構造にあるため、通信コストを気にせず配信できる仕組みへの期待が示されました。 AI 時代の展望 ― テクノロジーと人の両輪で 最後に、AI 時代の展望について議論しました。複雑化する広告環境での最適なマッチングや、既存トラフィックの価値の再発見といった AI 活用の方向性が語られ、AI エージェントがメディアプランニングを担う時代には Open Internet が再評価されるのではないかという見方も示されました。一方で印象的だったのは、登壇者が揃って「人」の重要性を強調したことです。買い付けの利便化により事業者間の人的なやり取りが減っている今こそ、コミュニケーションを密にし、連携してサービスを作っていくべきだという見解で一致しました。AWS に対しては、データ流通の信頼性担保や個人情報対応など、事業者が本業に集中できる仕組みづくりへの期待が語られ、セッションは幕を閉じました。 クロージング・懇親会 クロージングでは、本日の議論で挙がった課題への次の一手につながる AWS からのご提案として、パネルでも議論になった事業者間連携を後押しする、AWS RTB Fabric のエコシステムを活かしたお客様同士の共創・マッチング支援などをご案内しました。イベント後のアンケートでは、多くの企業からこれらのご提案への関心が寄せられました。 セッション終了後の懇親会では、参加企業名を会場に投影し、参加者同士のネットワーキングを促進しました。同じ業界でビジネス上の接点がある企業同士でも「リアルでは初めまして」という挨拶が会場のそこかしこで交わされ、業界の垣根を越えた新たなつながりが生まれる場となりました。 参加者の声 ご参加いただいたお客様からは、以下のような声をいただきました。 「RTB Fabric をはじめ、他社の広告事業の方向性についても知る機会をいただき、大変参考になりました。AWS さんのネットワークを通じて広告業界が盛り上がれると嬉しいです！」 「RTB Fabric、新規に構築しようとしているサービスでは是非使ってみたいです！」 「広告業界の動向・データ連携の進化、AI 時代における取り組みなど多くを学ぶことができ大変参考になりました。懇親会でも幅広く情報を得られました。」 アンケートにご回答いただいた方の 8 割以上から「今後もこのようなイベントに参加したい」との回答をいただきました。また、参加企業の多くがすでに広告配信基盤として AWS をご利用いただいていることも、あらためて確認できました。 おわりに 本イベントのタイトルである「変わる広告、変わらない価値」の通り、シグナルロスや AI によって広告を支えるテクノロジーと手法は大きく変わりつつあります。一方で、アドテク事業者の皆様が磨き上げてきた独自の技術やデータという事業の価値、そして事業者同士がつながり業界を盛り上げていくことの価値は変わりません。 本イベントでは、こうした転換点を乗り越える新たな武器として、AI の活用パターンや AWS RTB Fabric をはじめとするインフラの最新動向をお届けしました。また、パネルディスカッションから懇親会までを通じて事業者間連携の重要性があらためて共有され、アンケートで「接続可能なパートナー企業を紹介してほしい」という具体的なご要望を複数いただくなど、業界の垣根を越えた新たなつながりが生まれるきっかけとなりました。 AWS は、サービスの提供とお客様同士の共創・協働を支える場づくりを通じて、広告業界の発展に貢献してまいります。今後も同様のイベントを企画していく予定です。 AWS RTB Fabric の詳細や個別のご相談については、担当のアカウントチームまたは お問い合わせ よりお気軽にご連絡ください。 このブログは、ソリューションアーキテクトの久野が執筆しました。

AWS にいる間、私はいつも学生と一緒に働く機会を探していました。私は地域の大学で 50 回以上の講演を行ってきましたが、会場で可能性を観察することは常に強いモチベーションになっています。それは、なぜ私がこの仕事をしているか、また今日会う学生が明日私たちの顧客や協力者になるかもしれないということを思い出させてくれます。それが、私が 2026 年 8 月 24 日週に AWS Builder Center で学生リワードを提供できることを嬉しく思う理由です。 Rick Suttles 氏が「 AWS Builder Center での学生リワードの紹介 」を公開しました。これは、認定を受けた高等教育学生向けの新しい特典です。SheerID を通じて登録を確認し、Builder Center プロファイルを完了すると、12 か月間のプレミアム AWS Skill Builder アクセス (900 以上のコース、ハンズオンラボ、認定試験の準備、ゲームベースの学習) がロック解除されます。そこから、Builder Center でのアクション (記事の公開、コメント、エンゲージメントの維持) を通じてバッジを獲得できます。バッジが 7 個になると、10 USD の AWS クレジットをロック解除できます。バッジが 14 個になると、さらに 20 USD のクレジットが得られます。バッジが 21 個になると、AWS 基礎認定試験バウチャー (100 USD 相当) を獲得できます。 これは、この新学期シーズンに 5 億 USD 以上のリソースのコミットメントを表しており、クラウドと AI でのキャリア構築を始めるために必要なトレーニング、ツール、認定資格を学生に提供します。学生リワードは、世界中の認定高等教育機関に在籍している 18 歳以上の学生を対象としています。ただし、検証と利用規約の対象となります。 学生のステータスを確認して 、学習を開始し、バッジを獲得し、リワードをロック解除しましょう! 2026 年 8 月 17 日週のローンチ その他、8 月 24 日週に発表された事項をご紹介します。 ネバダ州ラスベガスの新しい AWS ローカルゾーン — この新しいローカルゾーンは、Amazon EC2 C7i、M7i、R7i、C8gn インスタンス、Amazon EBS、Amazon ECS、Amazon EKS、Application Load Balancer、AWS Direct Connect をサポートします。AWS ローカルゾーンは、世界中の 30 を超える大都市圏で利用できるようになりました。さらに、AWS は 欧州 (ロンドン) リージョンに 4 つ目のアベイラビリティーゾーン を追加し、汎用コンピューティングに加えて Trn3 と P6 の高速インスタンスによる次世代 AI と ML のキャパシティを提供しました。 Amazon EC2 Auto Scaling がバッチインスタンスの終了をサポートするようになりました – 最大 100 個のインスタンス ID を TerminateInstanceInAutoScalingGroup API に渡してバッチとして終了できるようになりました。これにより、自動スケーリンググループのスケールダウンに必要な API コールの数が削減されました。バッチ終了は、AI/ML トレーニングジョブ、コンテナオーケストレーター、または一時的に大規模なフリートをスピンアップするイベント駆動型アーキテクチャなど、迅速なスケールダウンが必要なワークロード向けに設計されています。 AWS CloudShell に組み込みのビジュアルファイルエディタが含まれるようになりました – CloudShell には、単一の編集コマンドを使用してシェルセッションから直接起動できるビジュアルファイルエディタが含まれるようになりました。このエディタは、シンタックスハイライト、検索と置換、複数行選択、コピーアンドペースト、元に戻す/やり直すを単一のブラウザセッションでサポートしています。デプロイスクリプトの更新、エージェントステアリングファイルの変更、CloudFormation テンプレートの編集、Lambda 関数の修正のいずれを行っている場合でも、このエディタは CloudShell から離れることなくシームレスに編集して実行できるようにします。 Amazon Bedrock がクロスリージョン推論による SpaceXAI Grok 4.6 をサポートするようになりました – コーディング、エージェントタスク、ナレッジワーク向けに構築されたフロンティアモデルである Grok 4.6 が、Amazon Bedrock 上で利用できるようになりました。&nbsp;このモデルは、レスポンス、チャット完了、コンバース API をサポートする bedrock-runtime エンドポイント上で実行され、モデル呼び出しログ記録、Amazon CloudWatch メトリクス、AWS Cost Explorer のコスト項目化など、既存のアカウントレベルのコントロールと連携します。 Amazon Bedrock が API サポートを拡張し、OpenAI モデルにクロスリージョン推論を導入しました – Amazon Bedrock が、レスポンス、コンバース、チャット完了 API で OpenAI GPT-5.6 モデル (Sol、Terra、Luna) をサポートするようになり、クロスリージョン推論が追加されました。地理的クロスリージョン推論は、事前定義された地域内でリクエストをルーティングします (今回のローンチでの米国地域サポートを含む)。一方、グローバルクロスリージョン推論は、低いトークンあたりのコストで、あらゆる商用 AWS リージョンからのリクエストを処理します。 AgentCore 支払いが Amazon Bedrock AgentCore で一般的に利用できるようになりました – 一般提供時点では、AgentCore コンソール内での Coinbase 認証情報の直接プロビジョニングのためのクイック作成、AgentCore Gateway を介した従量課金型の x402 エンドポイントの厳選された Coinbase Bazar MCP サーバー、Machine Payment Protocol (MPP) のサポート、および x402 プロトコルの「upto」スキームが含まれます。推論に応じた料金とダイナミックプライシングのユースケースに対応します。詳細については、 AI ブログの記事 をご覧ください。 AWS Glue 6.0 が 30% の料金引き下げと Iceberg v3 のサポートを提供 – AWS Glue 6.0 は、完全にモダナイズされたランタイム、Apache Spark 4.1、Python 3.13、および Scala 2.13 に基づいて構築されており、以前の AWS Glue バージョンよりも 30% 低い料金を提供しています。Iceberg v3 では、Glue 6.0 には、半構造化データの読み取りを高速化する自動シュレッダー処理、高性能な行レベルの更新のための削除ベクトル、空間処理用のジオメトリおよび地理データ型、および柔軟なスキーマ展開機能を備えた VARIANT データ型が追加されました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS サインインエクスペリエンスの更新 – AWS では、サインインおよびサインアップエクスペリエンスの更新を徐々に導入しています。再設計されたサインインページでは、新しい E メールベースのサインイン方法を使用するルートユーザーと顧客のための統一された E メールエントリポイントが導入され、IAM ユーザーは引き続きアカウント ID、ユーザー名、およびパスワードを使用してサインインできます。このページには、サポートされている ID プロバイダー (Google、GitHub、Apple、または Amazon.com) を使用して AWS アカウントを作成した顧客向けのサインインオプションも含まれています。再設計されたセッション選択ページにより、複数のアクティブなアカウントおよびロールセッションの表示と管理が簡素化されました。サインインページを操作するブラウザ自動化またはスクリプト化されたワークフローに組織が依存している場合は、投稿を確認して、これらの変更が構成にどのように影響する可能性があるかを理解してください。 開発中: ベルリン、ハイデラバード、サンパウロの AWS Builder Loft – 私の同僚の Channy が 3 つの都市に新しい Builder Loft をオープンする計画を発表しました。2025 年 7 月にサンフランシスコに最初の Builder Loft がオープンして以来、22,500 人以上の開発者を迎えてきました。新しい場所はそれぞれ、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コワーキングエリアを提供する常設コミュニティスペースになります。ベルリンはデジタル主権とセキュリティ対策に、ハイデラバードは AI とクラウドネイティブアーキテクチャに、サンパウロはラテンアメリカの開発者エコシステムのサポートに焦点を当てます。 AWS と Amazon WorkSpaces が 2026 Gartner Magic Quadrant for Desktop as a Service のリーダーとして認められました – AWS は、ビジョンの完全性と実行能力が評価され、2026 Gartner Magic Quadrant for Desktop as a Service (DaaS) で、3 年連続でリーダーに選ばれました。Gartner は、オペレーション、地理的戦略、および全体的な存続可能性に強みがあると認めました。また、人間のユーザーと同じデスクトップ環境、セキュリティ境界、および監査証跡内で AI エージェントを実行する機能である Amazon WorkSpaces for AI エージェントが評価対象になったのは今年が初めてです。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – ビルダーやイノベーターがクラウドで最新情報を学び、交流し、探求するための無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。また、 AWS Summits Global Livestream + On-Demand Hub で基調講演やセッションを視聴することもできます。特定の Summit のライブコンテンツやオンデマンドコンテンツにアクセスするには、そのイベントに登録する必要があります。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 ボリビアのサンタクルス (8 月 29 日)、 カナダのトロント (8 月 29 日)、 東京の JAWS SONIC (9 月 5 日)、 ポーランドのワルシャワ (9 月 8 日) などがあります。 AWS Builder Center にアクセスして、他のビルダーと交流したり、ソリューションを提供したり、構築を継続するのに役立つリソースを見つけたりしましょう。 夏も徐々に終わりに近づいています。私は、これから雨の多い秋を乗り切るために、今後数か月のうちに数日の休みを計画しています。お客様も同じように計画していることを願っています。8 月 31 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。

本記事は 2026 年 8 月 26 日 に公開された「 AWS and DuckLabs: Building the future of analytics together 」を翻訳したものです。 本日、 Amazon が DuckLabs を買収する最終契約を締結したこと を発表します。DuckLabs はオープンソースの分析データベース DuckDB を開発する、アムステルダム拠点の企業です。取引は通常のクロージング条件が満たされ次第、まもなく完了する見込みです。DuckDB を開発し DuckLabs を共同創業した Hannes Mühleisen と Mark Raasveldt は、AWS の一員として引き続きチームとオープンソースプロジェクトの技術的方向性を率いていきます。DuckDB オープンソースプロジェクトも引き続き DuckLabs チームが推進し、独立した Foundation (DuckDB を統括する非営利団体) の下でオープンソースとして維持され、現在と同様に MIT ライセンスで利用可能です ( DuckLabs ブログ を参照)。 データは常に企業の中核となる資産であり、差別化の源泉でした。組織が自社のデータで推論をカスタマイズし AI エージェントを構築する今、その重要性はこれまで以上に高まっています。AWS は 20 年間、データの最前線を切り拓いてきました。あらゆるビジネスにデータレイクをもたらした Amazon S3 のローンチに始まり、初のクラウド分析サービスである Amazon EMR、初のクラウドデータウェアハウスである Amazon Redshift、さらに Athena や Glue ETL などで導入してきた数々の機能があります。S3 Tables で直接利用できる Apache Iceberg 機能、データレイク内のベクトルストレージ、新しく最適化された Graviton ベースの Redshift クラスターなど、AWS のお客様のためにデータ領域での革新を続けています。 DuckDB もまた、世界のデータの扱い方を変える最前線に立ってきました。Hannes と Mark は、Python を生み出したことでも知られるオランダの国立研究機関 Centrum Wiskunde &amp; Informatica (CWI) 在籍中に DuckDB を開発しました。DuckDB の創業者たちは、従来のデータベースや Spark のような分析エンジンが超大規模データ処理のパフォーマンスに注力する一方で、多くのお客様が SQL 分析で行う作業の中心を占める、より小さなサイズのデータクエリに効果的に「スケールダウン」する手段を持っていないと気づきました。 DuckDB が取り組んだのは、今日のデータクエリの 90% 以上を占める、分析やダッシュボード作成で 1 テラバイト以下のデータを扱うクエリを圧倒的な速度で処理する課題です。DuckDB のアーキテクチャは「日常的な SQL クエリを超高速にする」という前提に基づいており、他のアプリケーションのインプロセスで動作するため、アプリケーションとのデータのやり取りが簡単かつ高速になります。DuckDB はベクトル化実行によって大きなパフォーマンス向上を実現しています。 SELECT * FROM table のような単純な文の実行に重たいコンパイラを必要としないためです。日常的なクエリでうまく機能する仕組みは、当然ながらエージェントでもうまく機能します。エージェントはデータと対話するときに人間とよく似た振る舞いをするからです。軽く探ってみる。試してみる。本当にやりたいことを見極める前に、小さなデータセットで探索的な分析を行う。DuckDB は AI エージェントが使うのに自然と最適化された形になっています。学術プロジェクトとして始まったものが、今ではデータエンジニアリング、データサイエンス、分析、そして AI エージェントに至るまで、使いやすさと純粋なパフォーマンスの点で広く採用されています。私たちは、1 テラバイト以下の日常的なクエリにおける DuckDB の強みを、エクサバイト超のエンタープライズ規模で実績のある S3 と、数百テラバイトからペタバイト級のデータで分析を支える Redshift、Athena、EMR、Glue-ETL、SageMaker プラットフォームなどの AWS 分析サービスと組み合わせる計画です。AWS の Distinguished Engineer である Andy Warfield が、Werner Vogels の All Things Distributed ブログで DuckDB and the Changing Physics of Analytics について語っています。 お客様は現在、DuckDB を AWS サービスと組み合わせて活用しており、その速度とシンプルさを高く評価しています。たとえば DuckDB は現在、ローカルや S3 などのクラウドストレージに保存された Parquet、CSV、JSON といった外部ファイルに対して SQL を直接実行し、他に類を見ないパフォーマンスと大幅に低いコストを実現しています。 Allen Institute の Scientific Computing 担当 Executive Director である David Feng 氏は次のように述べています。 「Allen Institute は、生物学における最大級の問いに大規模に取り組むことで、より健康な世界のための科学を加速しています。そこには、大規模でマルチモーダルなデータの広範な分析が伴います。私たちは 2025 年に数テラバイトの科学データを分析するために DuckDB を使い始め、大変気に入っています。神経生理学および行動データのリアルタイム品質管理と分析のためにデータを S3 に保存しており、これは次のデータ取得を進める上で欠かせません。数分かかっていたクエリが 1 秒未満で返るようになり、データとのまったく新しい対話方法が可能になりました。」DuckDB は AWS Lambda 関数のインプロセスで実行することもできます。 DuckDB アプリケーションが AWS で最高のパフォーマンスを発揮するようにし、DuckDB と AWS のビルディングブロックサービスとの深い統合に引き続き投資していきます。 AWS 自身のインフラでも DuckDB を活用しています。Amazon Quick は独自のダッシュボードエンジンのパフォーマンスを強化するにあたり、S3 Tables のデータへのクエリに DuckDB を選びました。Quick チームは、DuckDB エンジンが CPU 数に応じてスムーズにスケールし、単一のライブラリを Quick の内部コントロールプレーンサブシステムに簡単に組み込めることを確認しました。2025 年 10 月に Quick を提供開始して以来、DuckDB との統合と最適化を組み込んだ独自の Quick クエリエンジンで 25 億件を超えるクエリを処理してきました。DuckDB との統合と最適化により、Amazon Quick は平均クエリレイテンシーを 30% 削減できました。データと分析領域の他の AWS サービスでも、DuckDB のパフォーマンスとシンプルさをどのように取り込めるかを検討していきます。 DuckLabs と AWS が、アプリケーション、データエンジニア、AI のためにデータの最前線をどう再定義していくのか、そしてお客様の現状に寄り添いながら AWS の中で DuckDB のイノベーションの恩恵をどのように届けていくのか。続報にご期待ください。 著者について Mai-Lan Tomsen Bukovec AWS の Technology Vice President である Mai-Lan Tomsen Bukovec は、デジタル変革、ビジネス分析、機械学習、生成 AI、次世代のカスタマーエクスペリエンスにおいて数百万人の AWS のお客様が信頼を寄せる Amazon のクラウドデータサービスを率いています。テクノロジー業界で 25 年以上の経験を持ち、クラウド技術を活用してビジネスを変革するお客様の取り組みを支援するパイオニアです。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

はじめに 7 月は AWS オブザーバビリティにとってアップデートの多い月となりました。すでに収集しているテレメトリをより実用的なものにし、その収集にかかる運用作業を AWS 側で引き受ける機能をリリースしました。ログ分析は、ログクエリから直接実行できるアラームと、取り込み時に行われるエンリッチメントによって、アクションに繋げやすくなりました。アプリケーションレベルのオブザーバビリティは、エラーとデプロイイベントを自動的に捕捉するようになりました。AI コーディングエージェントの可視化が、新しいオブザーバビリティのカテゴリとして登場しました。Prometheus メトリクスのスクレイピングのために自前で運用していたエージェントは、マネージドコレクションによって不要になりました。そしてこれらすべてを支える基盤として、OpenTelemetry と Prometheus が引き続き中核的な役割を果たしています。 Amazon CloudWatch 、 Amazon Managed Service for Prometheus 、 Amazon Managed Grafana 、 AWS DevOps Agent の最新情報をご紹介します。 これらのリリースのライブデモをご覧になりたい方は、9 月 16 日開催の「 I didn’t know Amazon CloudWatch could do that! 」ウェビナーにご登録ください。過去のまとめを見逃した方は、「 今月の AWS オブザーバビリティ 」の 2026 年 1 月〜5 月 および 2026 年 6 月 のブログをご覧ください。 ログ分析: クエリからアクションへ 7月のテーマとして最も分かりやすいのは、ログクエリと、そこから起こすアクションに繋げやすくすることでした。 CloudWatch Logs のクエリから直接アラームを作成 できるようになりました。クエリを記述してしきい値を設定すれば、エラーが急増したときに周辺のログコンテキストとともにアラートを受け取れます。これら一連の操作が 1 つのワークフローで完結します。メトリクスフィルターやカスタムメトリクスを事前に作成する中間ステップは不要になりました。ログアラームは、Amazon Simple Notification Service や Amazon EventBridge を含む、すでに利用している標準的なアラームアクションをサポートしているため、他の CloudWatch アラームと同じ通知・自動化の経路にルーティングできます。 新しい ログエンリッチメント用の lookup プロセッサ は、アップロード済みの CSV のルックアップテーブルとログイベントのフィールドを照合することで取り込み時にコンテキストを追加します。カスタムのエンリッチメントロジックを書かなくても、IP アドレスから担当チームへ、エラーコードから人が分かりいやすい説明文へ、ユーザー ID からアカウントのメタデータへ、といったマッピングができます。エンリッチメントはデータの到着時に行われるため、クエリ、ダッシュボード、アラームのすべてが追加されたフィールドの恩恵を直ちに受けられます。 CloudWatch Logs が、 Application Load Balancer のログを Vended Logs (AWS のサービスが発行するログ) としてサポート するようになりました。Application Load Balancer のアクセスログ、接続ログ、ヘルスチェックログが CloudWatch Logs に直接ストリーミングされ、Logs Insights でのクエリ、メトリクスフィルターの作成、Live Tail によるリアルタイム監視が可能になります。テレメトリ有効化ルールにより、組織内の既存および新規のロードバランサーに対してロギングが自動構成されるため、1 つずつ手作業で設定する必要はありません。 CloudWatch Logs Insights には、7 月に 25 個の新しいクエリコマンドと関数 が追加されました。統計関数、セッション化 (sessionization)、外れ値検出、NULL 処理などが含まれます。これらにより、結果を別の場所で後処理するのではなく、クエリ言語の中でより多くの分析を直接実行できます。 コスト効率の良いログストレージ ログを 1 か所に集めるほど、ストレージコストが課題になります。7 月はこの点にも対応しました。 CloudWatch Logs Intelligent Tiering は、直近のアクセス状況に基づいて、ログデータを Standard、Infrequent Access、Archive Instant Access の 3 つの階層に分類します。30 日間アクセスされていないデータは Infrequent Access に移動し、90 日間アクセスされていないデータは Archive Instant Access に移動します。古いデータをクエリすると、自動的に Standard に戻ります。クエリの操作感は 3 つの階層すべてで同じであるため、チームの運用を変えることなくストレージコストを削減できます。有効化はアカウントレベルで行います。 アプリケーションのオブザーバビリティ Application Signals が、計装済みのサービスから エラー、パフォーマンス異常、デプロイイベントを自動的に捕捉 するようになりました。追加のコード変更は不要です。例外とレイテンシーのイベントスナップショット、関数レベルのパフォーマンスデータ、デプロイイベントを記録します。そのため、何か変化が起きたときには Errors ビューを直接開き、最近のデプロイが新しい例外を引き起こしたかどうかを確認できます。この機能は、AWS Distro for OpenTelemetry SDK、または Amazon Elastic Kubernetes Service (Amazon EKS) 用の CloudWatch Observability アドオンで計装された Java、Python、JavaScript のサービスでサポートされます。イベントはログとして、関数メトリクスは OpenTelemetry メトリクスとして配信されるため、既存のオブザーバビリティデータとまとめて扱えます。 AI コーディングエージェントのオブザーバビリティ Coding Agent Insights は、AI コーディングツールが組織全体でどのように価値を生み出しているかを、エンジニアリングリーダーが把握できるようにします。Claude Code、Codex、GitHub Copilot と統合され、追加の計装なしで OpenTelemetry メトリクスを収集します。データは既存の CloudWatch の運用ビュー上に表示されます。支出のトレンドを追跡し、トークン課金のアラートを設定し、エージェントの導入状況をコミットのスループットやプルリクエストの速度と突き合わせ、どのモデルが最も優れたコスト対アウトプット比を実現しているかを特定できます。コーディングエージェントを大規模に導入していくチームにとって、リターンを推測ではなく計測する手段となります。 OpenTelemetry とマネージドコレクション Managed Prometheus collectors は、エージェントのデプロイや保守なしに、Prometheus メトリクスをフルマネージドで収集します。スクレイプ設定を用意すれば、プロビジョニング、スケーリング、収集は CloudWatch が処理します。エージェントを一切デプロイ・管理することなく、Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Service のワークロードの監視を有効化できます。メトリクスは OpenTelemetry 形式で配信され、AWS Vended メトリクス (AWS のサービスが発行するメトリクス) とともに PromQL でクエリできます。 AWS Cloud Operations Blog の関連記事 (2026 年 7 月) 2026 年 7 月に AWS Cloud Operations Blog で公開された記事は以下のとおりです。 Getting per-resource alarm notifications with Amazon CloudWatch &nbsp; – Himanshu Dewan, Ashish Kumar, Radheshyam Baliga Bantwal Autonomous Root Cause Analysis for AWS Systems Manager Patch Failures Using AWS DevOps Agent &nbsp; – Rizwan Mohammed, Samir Behara, Shanmukha Jaya Harsha Alluri, Vinod Kisanagaram Build bespoke operational workflows with AWS DevOps Agent custom SRE agents &nbsp; – Harish Mandhadi, Brent Everman, Joe Alioto, Janardhan Molumuri Automate CI/CD troubleshooting with AWS DevOps Agent and GitHub &nbsp; – Purushotham G K, Abhishek Taparia Extend Amazon CloudWatch Beyond Native Connectors with Cribl Stream &nbsp; – Gabriel Costa, Kishore Vinjam How Amazon Achieved Full Stack Observability Across 400 Offices with Amazon OpenSearch Serverless &nbsp; – Shivansh Singh, Arijit Chakravorty, Bishr Tabbaa, Leonardo Quintero Deploy OpenTelemetry Gateway on AWS: Monitoring Your Observability Pipeline&nbsp; – Ankita Saxena, Jyothi Madanlal Amazon CloudWatch アラームをアクション可能なシグナルに変える &nbsp; – Helen Ashton, Gagandeep Singh Using Amazon S3 Server Access Logs with Amazon CloudWatch Logs &nbsp; – Isaiah Salinas, Erik Weber まとめ 7 月のリリースによって、ログ分析はクエリとアクションのギャップを埋め、ストレージの階層化はデータ保持コストを抑えやすくしました。さらに、アプリケーションのオブザーバビリティは追加のコードなしで重要なイベントを捕捉し、AI コーディングエージェントは計測可能になり、マネージドコレクションはエージェント運用の負担を取り除きました。これらはすべて OpenTelemetry と Prometheus の基盤の上に構築されています。 これらの機能を使い始めるには、以下を実施してください。 CloudWatch コンソール で、ログクエリから直接アラームを作成する。 CloudWatch Pipelines で 取り込み時にログをエンリッチするルックアップテーブル をアップロードする。 エラーとデプロイの自動捕捉のために、Application Signals のサービスイベントを有効にする。 Coding Agent Insights にデータを取り込むために、 Claude apps gateway のテレメトリを設定する 。 自己管理型のコレクターを マネージド Prometheus コレクター に置き換える。 テレメトリ有効化ルールを使って、 Application Load Balancer のログ を CloudWatch Logs にストリーミングする。 ストレージコストを自動的に削減するために、ログアカウントで CloudWatch Logs Intelligent Tiering を有効にする。 最近のリリースの一覧については、Amazon CloudWatch で絞り込んだ AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 9 月 16 日開催の「 I Didn’t Know Amazon CloudWatch Could Do That 」ウェビナーにご参加ください。これらの新機能の実際の動作をご覧いただき、トラブルシューティングの迅速化にお役立てください。 著者について Dot Ho Dot は AWS オブザーバビリティのシニアテクニカルプロダクトマーケティングマネージャーです。WCA (World Cube Association) の 3×3 マルチブラインド (目隠しで複数のキューブを解く種目) の記録向上に向けて練習中です。 Erik Weber Erik Weber は AWS Cloud Operations サービスのシニアワールドワイドスペシャリストソリューションアーキテクトです。AWS Systems Manager、AWS Config、AWS CloudTrail、AWS Audit Manager を専門としています。仕事以外では、ハイキング、料理、サイクリングを愛好しています。 Kevin Lewin Kevin は Amazon Web Services のクラウドオペレーションスペシャリストソリューションアーキテクトです。オブザーバビリティと自動化を通じて、お客様が運用目標を達成できるよう支援することに注力しています。 本ブログは 2026 年 8 月 18 日に公開された This Month in AWS Observability: July 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

このブログ記事は、AWS ソリューションアーキテクトの多田慎也が執筆し、株式会社MonotaRO が監修しています。 はじめに 株式会社MonotaRO （モノタロウ）は、工具、部品、消耗品をはじめとする間接資材のインターネット通販を展開し、連結売上高 3,338 億円（2025 年 12 月期）、登録ユーザー数 1,100 万以上、取扱商品点数 2,800 万点以上を誇る事業者向け EC プラットフォームです。同社はこのたび、事業の根幹を支える基幹データベースをオンプレミスの MySQL から Amazon Aurora MySQL（以下、Aurora MySQL）へ移行し、 Amazon Aurora Global Database （以下、Aurora Global Database）によるマルチリージョン DR 構成とフルマネージド運用を実現しました。本ブログでは、移行の背景と課題、選定理由、移行アプローチ、そして得られた成果についてご紹介します。 背景と課題 MonotaRO の基幹データベースは、日々の受発注処理をはじめとする事業のコアシステムとして、大量のクエリを処理しています。同社はクラウド活用を推進してきましたが、基幹データベースがオンプレミスに残っていること、そしてその基盤となる MySQL 環境そのものに、複数の領域で課題を抱えていました。 オンプレミスの基幹データベースがクラウド移行のボトルネックに 基幹アプリケーションやバッチ処理は、基幹データベースに対して大量のクエリを発行しています。アプリケーションとデータベースの間にネットワーク遅延が入ると処理時間が大きく伸びるため、データベースがオンプレミスにある限り、関連するアプリケーション群もオンプレミスに残らざるを得ない状況でした。これにより、クラウドネイティブな開発基盤への移行が制約されていました。 さらに、基幹データベースは事業の広範な領域と密結合しており、ひとたび障害が発生すると、基幹業務のドメイン同士にとどまらず、EC サイトや周辺業務にまで影響が波及する構造でした。この「基幹データベースがオンプレにあるためにアプリもクラウドに移せない」「密結合ゆえに障害影響が広い」という課題は、多くの企業が直面する共通の課題です。 レプリケーション遅延の変動 オンプレミス環境では、プライマリとリードレプリカ間の論理レプリケーション遅延が処理内容によって変動し、状況によっては十数分規模に達することもありました。この遅延により、データ鮮度が求められる処理ではリードレプリカではなくプライマリを参照せざるを得ないケースが生じ、プライマリへの負荷増大を招く要因にもなっていました。 MySQL 保守期限への対応 基幹データベースは旧バージョンの MySQL で稼働しており、保守期限が迫っていました。セキュリティパッチの提供終了リスクへの対処が急務となっていました。 18 台レプリカのセルフマネージド運用負荷 参照負荷に対応するため 18 台のリードレプリカを運用していましたが、すべてセルフマネージドでした。スケールアップ/ダウン作業やメンテナンス対応など、多くの時間が割かれていました。 マネージドなマルチリージョン DR の不在 従来も障害時の復旧手段は備えていましたが、いずれも手動運用を前提としたセルフマネージドな構成であり、マネージドかつ自動化されたマルチリージョン DR は実現できていませんでした。事業の成長に伴い、リージョン障害にも耐えうる DR を、運用負荷を抑えたマネージドな形で整備し、事業継続性をさらに強化することが求められていました。 こうした課題に対し、Aurora の I/O 性能やストレージレベルレプリケーション機能の向上、大阪リージョンの活用によるレイテンシー面の改善、これまでの MySQL 移行で培った移行の練度といった追い風もあり、Aurora への移行が有力な選択肢として本格的に検討されました。 Aurora MySQL 選定の理由 MonotaRO が Aurora MySQL を選定した理由は、以下の 4 点に集約されます。 ストレージレベルレプリケーションによる遅延の根本解消 Aurora はストレージレベルでレプリケーションを行うため、従来の論理レプリケーションで発生していた変動の大きい遅延を根本的に解消できます。リーダー（Reader）は通常ミリ秒オーダーの遅延でライター（Writer）と同期されます。 MySQL 8.0 互換によるアプリケーション改修の最小化と EOSL 解消 Aurora MySQL は MySQL 8.0 互換であり、既存アプリケーションからの接続方法や SQL 構文の互換性が高いため、アプリケーション改修を最小限に抑えながらバージョンアップを実現できます。これにより、保守期限の問題もクラウド移行と同時に解決されます。 フルマネージドによる運用負荷削減と TCO 最適化 Aurora のマネージドサービスとしての特性により、18 台のセルフマネージドレプリカの運用負荷を大幅に削減できます。リージョン内でのインスタンス障害時の自動フェイルオーバー、自動バックアップ、パッチ適用など、従来手動で行っていた運用作業が自動化されます。さらに、ハードウェアの保守・更改やデータセンター運用が不要になり、必要な性能に応じてキャパシティを柔軟に調整できるため、運用工数まで含めた総所有コスト（TCO）の最適化にもつながります。 Aurora Global Database によるリージョンレベルの DR Aurora Global Database を採用することで、大阪リージョンをプライマリ、東京リージョンをセカンダリとするマルチリージョン構成を実現し、リージョンレベルの障害にも対応可能な DR 構成を構築できます。セカンダリリージョンへのレプリケーションは専用のストレージレベル基盤を通じて行われ、通常 1 秒未満の遅延で同期されます。リージョンレベルの切り替えは、スイッチオーバー（計画的な切り替え）や手動フェイルオーバーにより、迅速かつ制御された形で実施できます。 移行アプローチと技術的ポイント PoC による性能・信頼性の検証 MonotaRO の開発チームが主導し、約 4 ヶ月間の PoC（Proof of Concept）を実施しました。インフラストラクチャ観点での性能検証やフェイルオーバー動作の確認に加え、アプリケーションの動作検証も行い、本番ワークロードに耐えうることを確認した上で、Aurora MySQL の採用を正式に決定しています。 中継機を用いたレプリケーションでのデータ移行 MySQL のレプリケーションは隣接するメジャーバージョン間でのみサポートされるため、MySQL 5.6 から複数のメジャーバージョンをまたいで Aurora MySQL 3 系（MySQL 8.0 互換）へ直接レプリケーションすることはできません。そこで、MySQL 5.7 の中継用インスタンス（中継機）を挟み、「MySQL 5.6 →（中継機）MySQL 5.7 → Aurora MySQL 3 系」の順でバージョンを 1 段ずつ引き上げながらレプリケーションすることで、オンプレミスから Aurora へ安定してデータを同期しました（図 1）。 (図1: 中継機を用いた段階的レプリケーションによるデータ移行) 参照系から更新系への段階的な切り替え 移行はビッグバン的に一度で切り替えるのではなく、段階的なアプローチを採用しました。まず影響範囲の小さい参照系（Read）のアプリケーションから先に新しいデータベースのリーダーへ接続を切り替え、最後に更新系（Write）のアプリケーションを切り替えました。小さな単位で少しずつ切り替えることで、各段階で動作を検証しながら問題の早期発見と切り戻しを可能にし、ミッションクリティカルなシステムの移行リスクを最小化しました。 AWS Countdown Premium の活用 さらに MonotaRO は、こうした移行を確実に進めるため AWS Countdown Premium を活用しました。同社には過去にオンプレミスから Aurora へのデータベース移行経験がありましたが、今回は過去に対応したことのない規模であり、かつミッションクリティカルなシステムであることから、AWS の専門家による支援を組み合わせる判断をしました。 MonotaRO が AWS Countdown Premium の活用を通じて得た価値は、以下の通りです。 専門家レビューによるリスクの事前特定 : リソースレビューを通じて、現時点では顕在化していないものの、将来のスケールや運用の中で課題となり得る設計上のポイントを洗い出し、先回りして対処 インフラメトリクスの立ち合いレビュー : 移行前後のメトリクスを専門家がリアルタイムで確認し、開発チームと専門家の直接コミュニケーションにより、開発チームの安心感を醸成 包括的な視点でのアドバイス : データベースだけでなく、データベースに関連するネットワークや運用面も考慮した総合的なアドバイスを提供 以上のように、開発チーム主導の PoC による検証、参照系から更新系への段階的な切り替え、中継機を用いた安定したデータ移行、そして AWS Countdown Premium による専門家支援を組み合わせた結果、移行は計画メンテナンスの範囲内で実施され、予期しないサービス影響を出すことなく完了しました。 構成と成果 最終構成 移行後の構成は、Aurora Global Database を中核としたマルチリージョン構成です（図 2 参照）。 プライマリリージョン : 大阪リージョン セカンダリリージョン : 東京リージョン (図2: Aurora Global Database 構成図 ) 定量成果 指標 Before （オンプレミス MySQL） After （Aurora / Aurora Global Database） レプリケーション遅延 （DB 内リーダー同期） 処理内容により変動（状況により十数分規模） 通常 100 ミリ秒未満 ※1 運用対象レプリカ 18 台セルフマネージド フルマネージド DR 構成 手動運用のセルフマネージド構成 マネージドなマルチリージョン Global Database リージョン内フェイルオーバー （ライター障害）RTO 手動・約 2 時間 自動・1 分未満 ※2 ※1 本表のレプリケーション遅延は Aurora クラスター内のリーダー参照における値で、通常ミリ秒オーダー（多くの場合 100 ミリ秒未満）です。一方、Aurora Global Database によるクロスリージョンのレプリケーションは通常 1 秒未満です。なお、Aurora から下流のオンプレミス連携先へのデータ連携は、従来と同様の方式で行われます。 ※2 リージョン内フェイルオーバーは、障害の自動検知と自動フェイルオーバーによって実行されます。一般的な復旧時間は 60 秒未満（多くの場合 30 秒未満）であり、本記事では保守的に「1 分未満」と記載しています。 障害時の可用性向上と機会損失の削減 今回の移行で最も大きな効果は、 基幹データベース障害時の事業影響（機会損失）を大幅に削減できる 点です。 ライター（Writer）のダウン（AZ 障害）時の RTO は、従来の手動切り替えで約 2 時間を要していたところ、Aurora 化により自動フェイルオーバーで 1 分未満 に短縮されました。障害からの復旧時間が大幅に短縮されることで、ダウンタイムに伴う機会損失を削減できます。 リージョン障害時にも、Aurora Global Database のセカンダリリージョンへの昇格により、マネージドなクロスリージョン DR を実現しました。従来は手動運用を前提としたセルフマネージドな復旧構成であったのに対し、マネージド化・自動化されたことで運用負荷を抑えつつ、プライマリリージョンの復旧を待たずにサイトの注文受付を再開できます。 セキュリティ・運用面の向上 Aurora は AWS のマネージドサービスであり、ホスト OS への直接アクセスを前提としない運用となるため、実行環境に対する不正アクセスや改竄のリスクを低減できます。あわせて、パッチ適用やバックアップといった運用作業がマネージド化されることで、運用チームはより付加価値の高い業務に注力できるようになりました。 お客様の声 「当社はかねてより全社的なシステムのモダナイゼーションを進めてきましたが、その最大のボトルネックの１つであったオンプレの基幹データベースを Amazon Aurora 上へ移行させることができました。参照系から更新系へと段階的に切り替えることでリスクを下げ、業務影響を最小限にとどめながら安全にコントロールされた移行を実現できました。AWS様の的確なサポートにも大変助けられました。今回の移行は MySQL 8.0 へのバージョンアップを兼ねており、多数のリードレプリカに対するレプリケーション遅延の解消に加え、Instant DDL や Blue/Green Deployments によりスキーマ変更をかけにくいという長年の課題も解消。これによりデータ構造のリファクタリングが容易になりました。またクローン機能により検証用データベースも即時に用意できるようになり開発環境の自動化を加速できます。さらに CloudWatch Database Insights によるクエリパフォーマンスの可視化と改善サイクルを早くまわせる仕組みを導入準備中です。今後もモダナイゼーションを進めることでシステムの変更容易性を獲得し、当社の競争優位をさらに強固なものにしてまいります。」 — 株式会社MonotaRO 常務執行役 ソフトウェア本部長 普川氏 「オンプレミス環境の稼働メトリクスや全クエリを生成 AI も活用して事前に分析し、移行後に問題となり得る箇所を洗い出したうえで、参照系から更新系へと段階的に切り替えていきました。ミッションクリティカルなシステムでありながら、計画メンテナンスの範囲内で移行を完了できています。現在は、稼働状況をもとに Amazon Bedrock で改善案を生成し、プルリクエストとして開発チームへ提案する仕組みに加え、今後のバージョンアップに備えて現行バージョンと次期バージョンの挙動を突き合わせ、同様にプルリクエストとして提案する仕組みの構築を進めており、Aurora への移行はその土台となりました。」 — 株式会社MonotaRO ソフトウェア本部 コアシステムエンジニアリング部門 基幹モダナイゼーショングループ 石田氏（本プロジェクト PM） 「オンプレミスでは、データベース運用の多くが手作業であること、レプリケーション遅延が各システムに影響すること、データベースがオンプレミスにあるためアプリケーションもクラウドへ移せないことなど、長年にわたり様々な課題がありました。Aurora MySQL への移行でその多くに解決の見通しが立ち、システム設計と運用の自由度が大きく広がりました。」 — 株式会社MonotaRO ソフトウェア本部 プラットフォームエンジニアリング部門 サービスインフラグループ 中島氏（インフラ担当） 今後の展望 MonotaRO は以前からクラウド活用やモダナイゼーションを進めてきましたが、基幹データベースはオンプレミスに残り、関連するアプリケーション群のクラウド移行を妨げる要因となっていました。今回の移行によってこの制約が解消され、モダナイゼーションをさらに加速できる状態になりました。 基幹システムのモダナイゼーション加速 : これまで基幹データベースがオンプレミスに存在していたことで制約されていた関連アプリケーション群のクラウド移行が可能になりました。今後はクラウドネイティブ化（コンテナ基盤への移行）を進め、開発者が新サービス開発や事業成長に直結する業務により集中できる環境の実現を目指します。 リーダーへの読み取り振り分けによる負荷分散 : レプリケーション遅延が解消されたことで、これまでデータ鮮度の都合でライター（Writer）に向けざるを得なかった読み取り処理も、リーダー（Reader）へ振り分けられるようになります。ライターの負荷を軽減し、読み取りのスケールアウトを進める土台が整いました。 メンテナンス運用の最適化 : Aurora MySQL の Blue/Green Deployments を活用することで、メジャーバージョンアップやスキーマ変更といった計画メンテナンスを、ダウンタイムを最小化して実施できます。Blue/Green Deployments では、本番環境の複製（グリーン環境）で事前に変更を検証したうえで、通常 1 分未満・データ損失なしで切り替えが可能です。 継続的な運用改善 : Aurora が提供する CloudWatch Database Insights や Enhanced Monitoring などの機能を活用し、継続的な運用改善に取り組んでいます。 まとめ MonotaRO は、基幹データベースをオンプレミス MySQL から Aurora Global Database に移行し、レプリケーション遅延の根本解消、マルチリージョン DR の実現、18 台のセルフマネージドレプリカからフルマネージド運用への転換を達成しました。加えて、障害時の RTO 短縮により、障害時の事業影響（機会損失）を大幅に削減できる見込みです。この移行は、単なるデータベースの載せ替えではなく、クラウドネイティブな開発基盤への移行を加速させる重要な一歩です。

この記事は、2026 年 5 月 28 日に AWS Artificial Intelligence Blog で公開された記事「 Automate AML alert triage with Amazon Quick and Snowflake Cortex AI 」（著者: Nidhi Gupta、Ebbey Thomas、Vipin Mohan、Zahir Gadiwan）を翻訳したものです。 AWS と Snowflake 上でシステムを運用する金融機関は、 Snowflake の AI Data Cloud と AWS のクラウドインフラストラクチャを組み合わせた 緊密に統合されたフレームワーク のメリットを享受できます。このフレームワークには、 Amazon Simple Storage Service (Amazon S3) 、 AWS Glue 、 Amazon SageMaker 、 Amazon Bedrock といった AWS サービスとの統合も含まれます。AWS サービスと Snowflake の間には 50 を超えるネイティブ統合が用意されており、組織はデータセキュリティを維持しながら、価値実現までの時間を短縮するコンプライアンスワークフローを構築できます。 本記事では、金融サービスにおいて最も労働集約的なワークフローの 1 つであるマネーロンダリング対策 (Anti-Money Laundering; AML) のアラートトリアージを自動化し、この統合が実際に機能する様子をご紹介します。 Amazon Quick Flows と Snowflake Cortex を Amazon Quick の Model Context Protocol (MCP) 統合で接続し、トリアージワークフローを構築していきます。私たちのテスト環境では、Amazon Quick を使用して構築した自動化ワークフローによって、アラート調査に要する時間が 30〜90 分から 5 分未満に短縮されました。実際の結果は、アラートの複雑さやデータ量によって異なる場合があります。 AI の活用が成熟するにつれ、最も大きな効果を生む導入形態は単体のアシスタントにとどまらないことがわかってきました。効果が大きいのは、チームがすでに使用しているツールをまたいでオーケストレーションする再現性のあるワークフローであり、複数ステップの手作業プロセスをワンクリックの体験へと変えるものです。Amazon Quick は、生成 AI を活用したチャットエージェント、リサーチ機能、タスク自動化のための Quick Flows、プロセス自動化のための Amazon Quick Automate を提供するエンタープライズ AI サービスであり、ネイティブインデックス、カスタムナレッジベース、ユーザーがアップロードしたファイルなど複数のソースからデータを集約します。Amazon Quick の一部である Quick Flows は、ユーザーのリクエストを標準化された MCP プロトコル（オープンなプロトコル標準）の呼び出しに変換し、OAuth 認証によるエンタープライズレベルのセキュリティを維持しながら、カスタムコネクタを不要にします。AML のトリアージは、入力の収集、調査の実行、出力の生成という同じ構造化されたステップを毎回たどるため、Quick Flows が適しています。この MCP ベースのアプローチは、FinOps のコストトリアージ、SRE のインシデント対応、コンプライアンス調査など、現在チームが手作業でシステム間を橋渡ししている再現性のあるワークフローにも同様に適用できます。 中規模から大規模の銀行の AML アナリストは、通常、1 件のアラートあたり 30〜90 分をかけて手作業でデータを収集し、対応判断の記述 (narrative) を作成しています。 業界の調査 によると、金融機関では一般に AML アラートの 90〜95% が誤検知 (false positive) であることが判明しており、効率的なトリアージが極めて重要になります。この規模の手作業による調査プロセスは、コンプライアンスチームに大きな負荷をもたらしかねません。自動化により、アナリストはより効率的にアラートを処理し、調査時間を短縮しながら、コンプライアンス基準を維持できます。 ソリューションの概要 次の図は、Model Context Protocol (MCP) を通じて Amazon Quick と Snowflake を接続する、エンドツーエンドの統合アーキテクチャを示しています。 図 1: Model Context Protocol を通じた Snowflake マネージド MCP サーバーと Amazon Quick の統合 このソリューションは、Amazon Quick Flows をオーケストレーションレイヤーとして使用し、Amazon Quick が管理する接続を通じて、 OAuth 認証 を備えた Snowflake マネージド MCP サーバー 経由で Snowflake Cortex Agent に到達します。Cortex Agent は調査作業を担い、 Cortex Analyst を通じて構造化された取引データを分析し、 Cortex Search を通じて非構造化のコンプライアンス文書を分析します。一方 Quick Flows は、入力の検証、推論ロジック、書式化された出力の提示を担当します。 図 2: AML アラートトリアージワークフロー: MCP アクションステップを備えた Amazon Quick Flows が Snowflake Cortex Agents (Cortex Analyst と Cortex Search) を呼び出す Quick Flow の入力ステップから調査ブリーフの完成までの、エンドツーエンドのアナリスト体験は次のとおりです。アナリストは公開されたフローを開き、アラート ID（例: ALT-2026-03-02-002 ）を入力し、必要に応じて対象期間を指定します。するとフローは次の処理を実行します。 入力を検証し、アラートが存在することを確認します。 MCP を通じて Snowflake Cortex Agent を呼び出し、取引データ、顧客プロファイル、過去の履歴、コンプライアンスポリシーを横断してアラートを調査します。 構造化された調査ブリーフ（アラートの概要、取引パターン、顧客プロファイル、過去の SAR、ポリシーの参照、リスクスコア、対応判断の推奨、記述のドラフト）を生成します。 実装 このセクションでは、Snowflake のデータレイヤーの準備から Quick Flows のオーケストレーションの構成まで、AML トリアージワークフローを構築する手順を説明します。まず開始前に必要な前提条件から始め、各ステップが前のステップの上に積み上がっていきます。最後まで進めると、アナリストがすぐに利用できる、完全に機能するエンドツーエンドの自動調査パイプラインが完成します。 前提条件 MCP アクションコネクタを構成できる Amazon Quick アカウント。 Cortex Agents、Cortex Search、および Snowflake マネージド MCP サーバー機能にアクセスできる Snowflake アカウント 。 AGENT 、 MCP SERVER 、 CORTEX SEARCH SERVICE 、 SECURITY INTEGRATION の各オブジェクトを作成する権限が必要です。 Snowflake 上の AML データ。取引モニタリングのアラート（Actimize、Norkom、社内ルールエンジンなどの取引モニタリングシステム (Transaction Monitoring System; TMS) から取得）、顧客・口座のマスターデータ、顧客確認 (Know Your Customer; KYC) / 顧客デューデリジェンス (Customer Due Diligence; CDD) の記録が必要です。あわせて、アラート、取引、顧客、対応判断の各ディメンションをモデル化したセマンティックビューが必要です。 Snowflake 上のコンプライアンス文書のコーパス。銀行秘密法 (Bank Secrecy Act; BSA) / AML ポリシーマニュアル、疑わしい取引の届出 (Suspicious Activity Report; SAR) の提出ガイドライン、過去の調査メモ、規制ガイダンス（FinCEN のアドバイザリ、FFIEC BSA/AML マニュアルの抜粋など）を、Cortex Search でインデックス化するためのテーブルにロードしておきます。 SQL、Snowflake の管理、および AWS Identity and Access Management (IAM) の概念に関する知識。 ステップ 1: AML セマンティックビューを準備する (Snowflake) Cortex Analyst は、コンプライアンスチームがアラートや調査をどのように捉えているかに沿った セマンティックビュー を与えたときに、最もよく機能します。Snowflake マネージド MCP サーバーは、 Cortex Analyst でのセマンティックビュー の利用をサポートしています。Snowsight で AI &amp; ML 、 Semantic Views の順に移動し、Snowflake の AML テーブル（ディメンションとメジャー）に対して セマンティックビューを作成 します。 アラートのメタデータ: alert_id、alert_date、rule_name、rule_category、severity、status、alert_score。 取引の詳細: txn_id、txn_date、txn_type、amount、currency、channel、originator、beneficiary、beneficiary_country。 顧客プロファイル: customer_id、full_name、risk_rating、country、industry、onboarding_date、pep_flag、sanctions_flag。 口座のアクティビティ: account_id、account_type、current_balance、avg_monthly_volume、status。 対応判断の履歴: 過去のアラート、過去の SAR、直近の対応判断の結果、アナリストのメモ。 アラート、取引、顧客、口座、対応判断の間にリレーションシップ（結合）を定義しておくと、エージェントは 1 回のクエリでデータモデルを横断できるようになります。 ステップ 2: コンプライアンス文書用の Cortex Search サービスを構築する (Snowflake) AML のトリアージは、非構造化データのコンテキストに大きく依存します。コンプライアンス文書のコーパスに対して Cortex Search サービスを作成し、エージェントがトリアージのたびに関連するポリシーのセクション、SAR 提出用のテンプレート、過去の調査メモを取得できるようにします。 CREATE OR REPLACE CORTEX SEARCH SERVICE aml_policy_search ON search_content ATTRIBUTES doc_type, effective_date, regulatory_body WAREHOUSE = AML_WH TARGET_LAG = '1 hour' EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0' AS ( SELECT doc_id, doc_type, effective_date, regulatory_body, content AS search_content FROM FINCRIMES_DB.AML_SCHEMA.COMPLIANCE_DOCS ); インデックス化する文書には、自組織の BSA/AML ポリシーマニュアル、SAR の提出基準額と記述のテンプレート、FinCEN のアドバイザリ、FFIEC BSA/AML マニュアルの抜粋、過去の調査メモ（必要に応じてマスキングしたもの）、制裁・PEP スクリーニングのガイダンスなどが含まれます。 ステップ 3: AML トリアージ用の Cortex Agent を作成する (Snowflake) 取引のセマンティックビュー (Cortex Analyst) とコンプライアンス文書の検索サービス (Cortex Search) を横断して オーケストレーションする Cortex Agent を作成します。エージェントの仕様には、自組織の調査手法をコード化したシステム指示のブロックが含まれます。このブロックは意図的に設けられたもので、カスタマイズされることを前提としています。ここで示すデフォルトの指示は一般的な AML トリアージのワークフローを反映したものですが、本番環境に導入する前に、自組織固有の手順、エスカレーション基準、規制上の義務に合わせて調整してください。 システム指示のブロック内の番号付きステップを確認し、自組織のワークフローに当てはまらないステップは順序を入れ替えるか削除してください。管轄区域や適用される規制フレームワークなど、組織固有のコンテキストを追加します。レスポンス形式のブロックは、自組織のケース管理システムが期待する出力構造に合わせて更新してください。また、 sample_questions のブロックは、自組織の環境における代表的なアラート ID やクエリパターンに更新しておくと、テスト時にエージェントの挙動を検証しやすくなります。 オーケストレーションの予算 (budget) は控えめに設定し、エージェントが Amazon Quick の MCP タイムアウト制約（現時点では 300 秒）に十分収まる範囲で完了するようにしてください。エージェントを作成したら、Snowsight で Cortex Analyst ツールが使用するデフォルトのウェアハウスを更新します。 CREATE OR REPLACE AGENT aml_triage_agent COMMENT = 'Daily AML alert triage agent' FROM SPECIFICATION $$ orchestration: budget: seconds: 120 tokens: 16000 instructions: system: | You are an AML alert triage assistant for a regulated financial institution. Your job is to: (1) Retrieve and summarize the flagged transaction pattern. (2) Pull the customer profile and account activity baseline. (3) Check for prior alerts, SARs, or investigations on this customer. (4) Retrieve relevant policy sections and SAR filing thresholds. (5) Produce a structured investigation brief with a risk score and disposition recommendation. Never fabricate transaction data. If data is missing, say so. response: | Always use this output format: 1. Alert Summary (alert ID, rule, severity, date) 2. Transaction Pattern (amounts, counterparties, channel, frequency) 3. Customer Profile (risk rating, onboarding, country, industry) 4. Prior History (past alerts, SARs, dispositions) 5. Policy Reference (applicable thresholds, guidance) 6. Risk Assessment (score 1-10, rationale) 7. Disposition Recommendation (close / escalate / file SAR) 8. Draft Narrative (2-3 paragraphs for case notes or SAR) sample_questions: - question: "Review alert ALT-2026-03-02-002" answer: "I will pull the transaction details, customer profile, check prior history, and produce an investigation brief." tools: - tool_spec: type: cortex_analyst_text_to_sql name: TxnAnalyst description: TxnAnalyst - tool_spec: type: cortex_search name: PolicySearch tool_resources: TxnAnalyst: semantic_view: FINCRIMES_DB.AML_SCHEMA.AML_SEMANTIC_VIEW PolicySearch: name: FINCRIMES_DB.AML_SCHEMA.AML_POLICY_SEARCH $$; 上記の system 指示の内容は次のとおりです。「あなたは規制対象の金融機関における AML アラートトリアージアシスタントです。あなたの役割は、(1) 検知された取引パターンを取得して要約する、(2) 顧客プロファイルと口座アクティビティのベースラインを取得する、(3) この顧客に関する過去のアラート、SAR、調査の有無を確認する、(4) 関連するポリシーのセクションと SAR の提出基準額を取得する、(5) リスクスコアと対応判断の推奨を含む構造化された調査ブリーフを作成する、ことです。取引データを決して捏造しないでください。データが欠けている場合は、そのことを明示してください。」 また response ブロックでは、常に次の出力形式を使用するよう指示しています。1. アラートの概要（アラート ID、ルール、深刻度、日付）、2. 取引パターン（金額、取引相手、チャネル、頻度）、3. 顧客プロファイル（リスク格付け、口座開設、国、業種）、4. 過去の履歴（過去のアラート、SAR、対応判断）、5. ポリシーの参照（適用される基準額、ガイダンス）、6. リスク評価（1〜10 のスコアとその根拠）、7. 対応判断の推奨（クローズ / エスカレーション / SAR の提出）、8. 記述のドラフト（ケースメモまたは SAR 用に 2〜3 段落）。 ステップ 4: Snowflake マネージド MCP サーバーを作成する Snowflake Cortex Agents は、外部の MCP クライアントに自動的に公開されるわけではありません。Amazon Quick に検出させたいツールを列挙した MCP SERVER オブジェクトを作成します。 CREATE OR REPLACE MCP SERVER aml_mcp_server FROM SPECIFICATION $$ tools: - title: "AML Triage Agent" name: "aml_triage" type: "CORTEX_AGENT_RUN" identifier: "FINCRIMES_DB.AML_SCHEMA.AML_TRIAGE_AGENT" description: "Runs the AML alert triage agent for daily compliance investigation." - title: "Transaction Analyst" name: "txn_analyst" type: "CORTEX_ANALYST_MESSAGE" identifier: "FINCRIMES_DB.AML_SCHEMA.AML_SEMANTIC_VIEW" description: "Governed natural-language queries over transaction monitoring data." - title: "Policy Search" name: "policy_search" type: "CORTEX_SEARCH_SERVICE_QUERY" identifier: "FINCRIMES_DB.AML_SCHEMA.AML_POLICY_SEARCH" description: "Search BSA/AML policy, SAR guidelines, and prior investigation notes." $$; 各 description の内容は、上から順に「日次のコンプライアンス調査のために AML アラートトリアージエージェントを実行する」、「取引モニタリングデータに対するガバナンスの効いた自然言語クエリ」、「BSA/AML ポリシー、SAR ガイドライン、過去の調査メモを検索する」です。 ステップ 5: Amazon Quick 用に Snowflake OAuth を設定する Amazon Quick は MCP 統合で OAuth をサポートしています。Snowflake のマネージド MCP サーバーは OAuth 2.0 をサポートしていますが、動的クライアント登録 (Dynamic Client Registration) はサポートしていないため、Amazon Quick では手動構成のオプションを使用します。 Snowflake で OAUTH タイプの SECURITY INTEGRATION を作成し、Amazon Quick のリダイレクト URL を登録します。 -- CREATE ROLES CREATE OR REPLACE ROLE IDENTIFIER('AML_MCP_ROLE'); -- Create a security integration for quicksight CREATE OR REPLACE SECURITY INTEGRATION aml_quick_oauth TYPE = OAUTH OAUTH_CLIENT = CUSTOM ENABLED = TRUE OAUTH_CLIENT_TYPE = 'CONFIDENTIAL' OAUTH_REDIRECT_URI = 'https://{region}.quicksight.aws.amazon.com/sn/oauthcallback' OAUTH_ISSUE_REFRESH_TOKENS = TRUE OAUTH_REFRESH_TOKEN_VALIDITY = 86400 PRE_AUTHORIZED_ROLES_LIST = ('AML_MCP_ROLE'); デプロイ先のリージョンにおける正確な URL を Amazon Quick コンソールで確認し、それに合わせて上記コマンドの OAUTH_REDIRECT_URI の値を更新してください。 次のコマンドを実行して、クライアント ID とクライアントシークレットを取得します。 SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('AML_QUICK_OAUTH'); OAUTH_CLIENT_ID と OAUTH_CLIENT_SECRET の値を記録しておきます。 次のコマンドを実行して、Snowflake の OAuth エンドポイントの値を取得します。 DESC INTEGRATION aml_quick_oauth; OAUTH_AUTHORIZATION_ENDPOINT と OAUTH_TOKEN_ENDPOINT の値を記録しておきます。 ステップ 6: 最小権限のアクセス制御を適用する (Snowflake) Amazon Quick の MCP アクセス用に専用のロールを作成します。MCP サーバーと、その配下のツールに対して USAGE を付与します。MCP サーバーへのアクセス権があっても、そこで公開されるツールへのアクセス権が自動的に付与されるわけではありません。 CREATE OR REPLACE USER {quickuser} PASSWORD='{password}' DEFAULT_ROLE = AML_MCP_ROLE DEFAULT_WAREHOUSE='{DEFAULT_WAREHOUSE}'; GRANT USAGE ON DATABASE FINCRIMES_DB TO ROLE AML_MCP_ROLE; GRANT USAGE ON SCHEMA FINCRIMES_DB.AML_SCHEMA TO ROLE AML_MCP_ROLE; GRANT USAGE ON MCP SERVER FINCRIMES_DB.AML_SCHEMA.AML_MCP_SERVER TO ROLE AML_MCP_ROLE; GRANT USAGE ON AGENT FINCRIMES_DB.AML_SCHEMA.AML_TRIAGE_AGENT TO ROLE AML_MCP_ROLE; GRANT SELECT ON SEMANTIC VIEW FINCRIMES_DB.AML_SCHEMA.AML_SEMANTIC_VIEW TO ROLE AML_MCP_ROLE; GRANT USAGE ON CORTEX SEARCH SERVICE FINCRIMES_DB.AML_SCHEMA.AML_POLICY_SEARCH TO ROLE AML_MCP_ROLE; ステップ 7: Snowflake MCP サーバーを Amazon Quick に登録する Amazon Quick コンソールで Connectors に移動し、 Connect to your team タブを選択します。 Model Context Protocol のタイルにあるプラス (+) アイコンを選択して、セットアップを開始します（図 3）。 図 3: Amazon Quick の Connectors ページ: 新しい MCP 統合を追加するために Model Context Protocol のタイルを選択する Snowflake MCP サーバーのエンドポイントを入力します。 https://&lt;account_url&gt;/api/v2/databases/FINCRIMES_DB/schemas/AML_SCHEMA/mcp-servers/AML_MCP_SERVER 図 4: Amazon Quick の MCP 統合: Snowflake MCP サーバーのエンドポイント URL を入力する Next を選択します。 User authentication (OAuth) を選択し、 Manual configuration を選択します。Snowflake の SECURITY INTEGRATION から取得したクライアント ID とシークレット、および Snowflake の OAuth 認可 URL とトークン URL を入力します。 Create and continue を選択します。Amazon Quick が MCP サーバーに接続し、利用可能なツールを検出します。 図 5: Amazon Quick の MCP 統合: Snowflake の認証情報を入力した OAuth 手動構成のフィールド ステップ 6 で作成した Snowflake ユーザーを使用して、Snowflake に認証する必要があります。 図 6: Snowflake の認証情報を使用して Snowflake にサインインする Snowflake-managed MCP server tools （Cortex Agent、Cortex Analyst、Cortex Search）に対応する、検出されたアクションの一覧を確認して確定します。これらのツールが調査作業を担い、Quick Flow は自身で定義したワークフローのロジックに基づいて、それらをアクションステップとして呼び出します。 図 7: 検出されたツール (aml_triage、txn_analyst、policy_search) を表示する Amazon Quick の MCP 統合確認ページ ステップ 8: AML トリアージの Quick Flow を構築する Quick Flows に移動し、 Create flow を選択します。ワークフローは自然言語で記述することも、ビジュアルエディタを使用してステップごとに構築することもできます。このフローは、入力ステップ、MCP アクションステップを含む Reasoning group、出力ステップ、そして任意のフォローアップチャットという 4 つのセクションで構成されます。 入力ステップ: アラート ID を収集する アナリストにアラート ID（例: ALT-2026-03-02-002 ）と任意の対象期間の入力を促す User input ステップを追加します。これによってフローは再現性があり、自己説明的なものになります。すべての実行が同じ構造化された入力から始まるため、アナリスト間でプロンプトのばらつきが生じません。 図 8: Quick Flow エディタ: アナリストからアラート ID と任意の対象期間を収集するように構成された入力ステップ Reasoning group: MCP を通じてアラートを調査する アラートを調査するための分岐ロジックを含む Reasoning group を追加します。この例で Reasoning group を使用するのは、 CRITICAL のアラートを BSA オフィサーによる即時レビューへエスカレーションする、 HIGH_RISK_GEO のアラートに強化レビューを適用する、過去の SAR が見つかった場合にエスカレーションを推奨するといった、条件付きのトリアージ経路をフローがサポートできるようにするためです。ワークフローが常に条件分岐なしで同じ aml_triage アクションを実行する場合は、入力ステップの直後に Snowflake MCP のアプリケーションアクションを配置することで、Reasoning group を使わずにこのフローを構築することもできます。 図 9: Quick Flow エディタ: 調査ロジックを含む Reasoning group を追加する Reasoning group 内に Application actions ステップを追加し、ステップ 7 で作成した Snowflake MCP 統合を選択します。 aml_triage アクションを選択します。そして、このアクションステップ用のプロンプト指示を記述します。 Investigate alert {alert_id} using the AML triage agent. Pull the customer profile, summarize the flagged transaction pattern, check for prior alerts and SARs, retrieve relevant BSA/AML policy sections, and produce a structured investigation brief with a risk score and disposition recommendation. Use the eight-section output format: Alert Summary, Transaction Pattern, Customer Profile, Prior History, Policy Reference, Risk Assessment, Disposition Recommendation, Draft Narrative. このプロンプトの内容は次のとおりです。「AML トリアージエージェントを使用してアラート {alert_id} を調査してください。顧客プロファイルを取得し、検知された取引パターンを要約し、過去のアラートと SAR を確認し、関連する BSA/AML ポリシーのセクションを取得して、リスクスコアと対応判断の推奨を含む構造化された調査ブリーフを作成してください。出力は 8 セクション形式（アラートの概要、取引パターン、顧客プロファイル、過去の履歴、ポリシーの参照、リスク評価、対応判断の推奨、記述のドラフト）を使用してください。」 図 10: Quick Flow エディタ: Snowflake 統合の aml_triage ツールを呼び出す MCP アクションステップを含む Reasoning group {alert_id} 変数のデフォルト値は入力ステップから自動的に設定されますが、手動で上書きすることもできます。Reasoning group には、さまざまなアラートのシナリオに対応するための追加の分岐ロジックを、自然言語の指示として含めることができます。 深刻度が CRITICAL のアラートの場合、Reasoning group はエージェントに対して、制裁リストを確認し、そのケースを BSA オフィサーによる即時レビュー対象としてフラグを立てるよう指示します。アラートのカテゴリが HIGH_RISK_GEO の場合、エージェントは受益者の国を最新の FATF 高リスク管轄区域リストと照合し、OFAC スクリーニングのガイダンスを取得します。顧客に過去の SAR の記録がある場合、エージェントは過去の調査の記述を取得し、クローズではなくエスカレーションを推奨します。 出力ステップ: 調査ブリーフを提示する 調査ブリーフを書式化してアナリストに提示する Output ステップを追加します。出力には、Cortex Agent のレスポンスに含まれる 8 つのセクションすべてが含まれます。アナリストはブリーフをレビューでき、さらに Quick Flows はエージェント型ランタイムをサポートしているため、フローとチャットしながら出力を改善できます。 図 11: Quick Flow エディタ: 8 つのセクションすべてを含む書式化された調査ブリーフを表示する出力ステップ ステップ 9: フローを公開して共有する フローのテストが完了したら、 Share and Publish を選択して、フローライブラリで利用できるようにします。その後、コンプライアンスチームと共有します。 図 12: Quick フローを共有して公開する アナリストは、ライブラリからフローを開くか、Amazon Quick のチャットインターフェイスから呼び出すことができます。すべてのアナリストが同じ構造化されたトリアージワークフローを実行するため、プロンプトエンジニアリングの経験の有無にかかわらず、一貫した監査対応可能な調査ブリーフが生成されます。 ステップ 10: ワークフローをテストする AML Alert Triage Flow を開き、テスト用のアラートで実行します。アラート ID を入力し、Start ボタンを選択して、フローを実行します。フローは MCP を通じて Snowflake Cortex Agent を呼び出します。エージェントは内部で Cortex Analyst と Cortex Search をオーケストレーションし、構造化された調査ブリーフを返します。 図 13: Quick フローをテストする 図 14: AML トリアージ Quick Flow から生成された出力 ブリーフをレビューした後、アナリストはチャットインターフェイスを使ってフォローアップの質問を行い、最終化する前に出力を改善できます。次のような質問例でインターフェイスをテストしてみてください。 「これらの国はどの FATF リストに掲載されていますか。行動要請 (call to action) ですか、それとも監視強化 (increased monitoring) ですか」 「この顧客について、過去の調査では何が判明しましたか」 図 15: フォローアップの質問に対する Quick フローからのレスポンス セキュリティとガバナンスに関する考慮事項 フローをコンプライアンスチームと共有する前に、対処しておくべきセキュリティとガバナンスの考慮事項がいくつかあります。 アクセス制御の観点では、MCP 統合は OAuth で認証されたロール ( AML_MCP_ROLE ) の権限で動作します。このロールの権限は、MCP サーバー、エージェント、セマンティックビュー、検索サービスに対する最小限の USAGE と SELECT に限定し、 SYSADMIN や ACCOUNTADMIN の付与は避けてください。 Cortex AI は Snowflake のセキュリティ境界内でデータを処理するため、データが Snowflake アカウントの外に出ることはありません。規制対象の金融データについて、Snowflake のリージョンが自組織のデータレジデンシー要件を満たしていることを確認してください。 多くの管轄区域では、AML の調査データは漏えい禁止 (tipping-off) の規制対象となります。つまり、疑わしい取引の届出を行おうとしている、または行ったという事実を、当該顧客や関係者に知らせることが禁じられています。Quick Flow は権限を与えられたコンプライアンス担当者のみと共有し、組織全体のフローライブラリに公開したり、顧客対応のロールに公開したりしないでください。 監査の観点では、Amazon Quick が MCP ツールの呼び出しとフローの実行をログに記録し、Snowflake の ACCESS_HISTORY ビューと ACCOUNT_USAGE ビューが Cortex Agent によって実行されたすべてのクエリを記録します。これらを組み合わせることで、検査官のレビューに対応できる調査の監査証跡が得られ、フローの各実行が個別に追跡可能なイベントとして残ります。 このフローは調査ブリーフと対応判断の推奨のドラフトを生成しますが、SAR の提出やケースのクローズはすべて、人間のコンプライアンスアナリストがレビューし承認する必要があります。このフローは調査を加速するものであり、自動的に意思決定を行うものではありません。 Cortex Agent が使用する LLM モデルを文書化し、モデルインベントリでバージョン管理するとともに、 SR 11-7 / OCC 2011-12 に従って自組織の AI/ML モデルリスク管理フレームワークに含めてください。 Snowflake の OAuth 認証情報は自組織のキーローテーションポリシーに従ってローテーションし、リフレッシュトークンの有効期間は、運用上のニーズを満たす最短の期間に設定してください。 調査手法が進化したら、フローを更新して再公開してください。Quick Flows は反復的な改善をサポートしており、アナリストは自動的に最新バージョンを利用できます。 チャットエージェントではなく Quick Flows を選ぶ理由 Quick Flows は、毎回同じ調査ステップを強制します。これがこのソリューションの中核となる設計判断です。チャットエージェントはプロンプトの指示に緩やかに従うため、各アナリストのリクエストの表現によって出力が変動します。一方フローは決定的な結果を実現します。誰が実行しても、すべてのアラートが同じ構造化された入力、同じ推論ロジック、同じ書式の出力を通ります。 この一貫性こそが、調査ブリーフをデフォルトで監査対応可能なものにしています。フローの各実行は、個別にログに記録されたイベントです。Reasoning group における条件分岐は、 CRITICAL のアラートを強化ステップに振り分け、過去に SAR がある顧客を自動的にエスカレーションするもので、チャットエージェントでは確実に再現できないロジックを強制します。トリアージワークフローの範囲外のアドホックな質問については、同じ Snowflake MCP 統合が Quick のチャットエージェントでも同様に機能します。Quick Flows とチャットエージェントは同じ基盤を共有しており、ユースケースに応じたインターフェイスの違いにすぎません。 リソースのクリーンアップ このソリューションをプロトタイプとして構築した場合は、継続的な露出と課金を避けるために、次のリソースを削除してください。 Amazon Quick で、AML Alert Triage フローを 削除または非公開にします 。 Amazon Quick で、Snowflake MCP サーバーへの 統合を削除します 。 Snowflake で、ツールを外部に公開する必要がなくなった場合は MCP SERVER オブジェクトを削除 (DROP) します 。 Snowflake で、OAuth に使用した SECURITY INTEGRATION を無効化または削除 (DROP) します 。 Snowflake で、ワークフローを廃止する場合は Cortex Agent 、 Cortex Search サービス 、およびテストデータのテーブルを削除 (DROP) します。 まとめ 本記事では、Snowflake マネージド MCP サーバーを通じて Snowflake Cortex Agent に接続する Amazon Quick Flows を使用して、日次の AML アラートトリアージワークフローを構築する方法をご紹介しました。構造化された入力ステップから、フローは MCP を通じて Cortex Agent を呼び出し、Cortex Analyst（構造化された取引データと顧客データ用）と Cortex Search（BSA/AML ポリシーと過去の調査メモ用）をオーケストレーションして、リスクスコアと対応判断の推奨を含む完全な調査ブリーフを提示します。 プロンプトの表現によって出力が変動するチャットエージェントとは異なり、Quick Flows は入力の検証、推論ロジック、書式化された出力を組み込んだ、予測可能で再現性のあるシーケンスを強制します。これにより、アナリストはプロンプトエンジニアリングを習得しなくても一貫した高品質のトリアージを実行でき、ワークフローをワンクリックでチーム全体に配布できます。すべてのアナリストが同じ構造化されたトリアージを実行します。出力形式は予測可能で、各実行は個別の監査可能なイベントとなります。同時に、Quick Flows のエージェント型ランタイムにより、アナリストはワークフローとチャットして出力を改善したりフォローアップの質問をしたりできるため、構造化されたプロセスの厳密さと会話型インターフェイスの柔軟性を両立できます。 ここでの鍵となるパターンは、Snowflake マネージド MCP サーバーを通じて Cortex Agent を MCP ツールとして公開し、Amazon Quick から OAuth で接続することです。この同じ MCP 統合は Quick Flows、チャットエージェント、Amazon Quick Automate をまたいで機能するため、日次のトリアージ用の構造化されたフローから始めて、ニーズの拡大に応じてアドホックなチャットエージェントやエンタープライズ規模の自動化へと広げていくことができます。 まずは、 Using Amazon Quick Flows 、 MCP integration 、 Snowflake-managed MCP server 、および Amazon Quick ユーザーガイド をご覧ください。Amazon Quick の機能の詳細については、 Amazon Quick のドキュメント を参照し、 Amazon Quick コミュニティ もぜひフォローしてください。 著者について Nidhi Gupta Nidhi は AWS の Senior Partner Solutions Architect で、データと分析を専門としています。お客様やパートナーが AWS 上で Snowflake のワークロードを構築し最適化する支援をしています。Nidhi は本番リリースとデプロイをリードしてきた豊富な経験を持ち、データ、AI、ML、生成 AI、高度な分析に注力しています。 Ebbey Thomas Ebbey は AWS の Senior Generative AI Specialist Solutions Architect です。ISV やお客様と協力して AI エージェントの実践的なユースケースを見極め、それを本番品質の生成 AI ソリューションへと仕上げています。Ebbey はシラキュース大学でコンピュータエンジニアリングの学士号と情報マネジメントの修士号を取得しました。仕事以外では、コーヒー、アウトドア、ワークアウト、ロードトリップ、そして家族と過ごす時間を楽しんでいます。 Vipin Mohan Vipin は Amazon Web Services の Principal Product Manager で、エージェント型 AI のプロダクト戦略をリードしています。数千のお客様に提供される AI/ML プロダクト、コンテナプラットフォーム、検索技術の構築を専門としています。仕事以外では、プロダクトマネージャーを志す人たちのメンターを務め、金融投資や起業に関する読書を楽しみ、2 人の子供の目を通して世界を探検することを楽しんでいます。 Zahir Gadiwan Zahir は Snowflake でクラウドサービスプロバイダー向けのパートナーソリューションエンジニアリングをリードしています。クラウドパートナーやお客様と密接に連携し、ガバナンスの効いたエンタープライズデータを実世界の AI 成果へと変える支援をしており、セキュアでスケーラブルなアーキテクチャに特に注力しています。組織がモダンな AI 体験を Snowflake のガバナンスされたデータと AI 機能に接続し、実験から本番へと進んでいく方法について、現場に根ざした実践的な視点を持っています。

本記事は「 How We Learned to Trust an AI Agent to Triage Production Incidents 」を翻訳したものです。 ある日曜日の午前 2 時 33 分（PDT）、フロンティアモデルの可用性アラームが発報しました。本番のレスポンスがストリームの途中で止まりはじめ、監視システムが自動でチケットを起票しました。 その 13 分 35 秒後、午前 2 時 46 分（PDT）には、根拠のある診断がチケット上に載っていました。ストリームが本番バグかキャパシティのスケーリングのいずれかによってエラーを出さずに停止していること、顧客に影響が出ていること、競合する仮説がすべて排除されていること、そして裏付けとなる証拠を添えた推奨される次のアクション、が書き出されていました。 オンコールエンジニアが打ち込んだのは 1 文だけでした。「エスカレーションを起票して」か「本番バグを対処して」か。本当の貢献は、仕上がったブリーフを読み、そこに浮かび上がった判断を吟味し、意思決定することでした。 調査を行ったのは、 Kiro CLI 上で動く AI エージェントでした。本記事は、私たちのチーム、すなわちエージェントを中心に仕事の進め方を再設計している フロンティアチーム の 1 つが、どのようにして本番チケットキューをエージェントに任せられるようになったのか、そして今なお何をエージェントにやらせていないのかについて書いたものです。 仕事: 大規模に、午前 2 時に、トリアージする 私たちのチームは Kiro のデータプレーン、つまり Kiro の IDE 、 CLI 、 Web 、 iOS 、 Kiro Crew からのすべてのエージェンティックなチャットリクエストを、複数リージョンにまたがるモデル群（Anthropic、OpenAI、GLM、Qwen、DeepSeek、MiniMax。いずれも Amazon Bedrock 上でホスト）へと運ぶ配信経路を運用しています。各モデルには、それぞれ可用性、レイテンシー、スロットリング、キャッシュ、合成プローブのアラームが備わっています。 アラームが発報したら、誰かがそれをトリアージしなければなりません。これは本物か、何が壊れたのか、誰が影響を受けているのか。1 件の可用性の低下は、キャパシティイベントかもしれないし、不正アクセス攻撃、まずいデプロイ、あるいはチューニングを誤ったアラームかもしれません。そして各仮説は、それぞれ別のロググループ、別のアカウント、別のクエリ言語の中に存在します。優れたトリアージとは、500 個の問いのうちどの 5 個を最初に問うべきかを知っていることです。なぜなら、それぞれの結果が次のクエリを決めるからです。 トリアージは仮説探索であり、ツールを備えたエージェントはまさにそのために作られています。長年蓄積してきた Runbook、アラーム Wiki、ポストインシデントのメモは、すでにエージェントのコンテキストへの投資になっていました。この仕事は読み取り中心です。エージェントのツール呼び出しの 96.9% は読み取り（安全で、可逆で、並列化できる）で、残りはゲートをかけられます。そしてトリアージは繰り返されます。学んだことを書き留めるエージェントは、システムの知識を複利で積み上げていきます。午前 3 時の疲れた人間には、それができません。 システム: Kiro ハーネスを取り巻く markdown と MCP サーバー オーケストレーションフレームワークもなければ、ファインチューニングしたモデルもなく、専用のエージェントランタイムもありません。システムは Kiro CLI、すなわち 私たちが顧客に提供しているのと同じ CLI を、自分たちのオペレーションに向け、エンジニアがコードと同じように書いてレビューする 3 種類のプレーンなファイルで設定したものです。 エージェント設定 : モデル、ツール、そして運用ルールを記した markdown のステアリングファイル。各ルールは一度下した人間の判断であり、以降はそれが適用されます。 Model Context Protocol （MCP） サーバー : エージェントがツール（ReadOnly の AWS アカウント、ログ、チケット、パイプライン、コードレビュー、Slack）に接続できるようにします。 スキル と知識 : 面白いのはここで、次に取り上げます。 ハーネスの周りには、チケットキューを監視し、チケット 1 件につき 1 つのヘッドレス Kiro CLI セッションを起動する、常駐のディスパッチャーが 1 つ配置されています。モデルはアーキテクチャ上の決定ではなくランタイムパラメータです。主任調査官（lead investigator）は利用可能な最も強力なモデルで動き、ファンアウトの作業は高速で安価なモデルで動くサブエージェントの群れに回され、本当に曖昧な判断は 3 つのプロバイダーのモデルからなる評議会（council）へ並列に投げかけられます。意見の不一致は、さらに証拠を集めよというシグナルとして扱われます。 図 1: トリアージのパイプライン。アラームがチケットになり、ディスパッチャーがエージェントセッションを起動し、エージェントはスコープを絞った ReadOnly ツールで調査してチケットに証拠を書き戻す。 スキルは巨大なプロンプトの代わりに段階的開示（progressive disclosure）をもたらす 対照的に、スキルは 1 つの状況のための markdown の手順書です。エージェントのコンテキストが抱えているのは全 107 個のスキルのインデックスだけで、チケットが合致したときに、その 1 つのスキルの手順書全体を読みます。何もかもをシステムプロンプトに詰め込むやり方は、10 個目の Runbook あたりで破綻します。コンテキストが、発報していない 99 個のアラームのための指示で埋まってしまうからです。以下は、あるレートリミットのインシデントの後に書かれた、要約した抜粋の例です。 # Provider rate limit driving an AVAILABILITY alarm [evolved: step 4 added after that night's investigation] Key insight: a 429 is normally a client-side Error, not a Fault. But with the provider's token allocation exhausted, its 429s reach customers as 5xx faults, so never pre-filter to status=5xx: a 429 flood can be 20x larger. Procedure (last two of four steps): 3. Error-mode fork: overload → wait, the provider auto-scales in about an hour; hard quota → waiting will NOT clear it, request a raise 4. Attribute 429s per cell: a few hot cells = quota problem, every cell warm = capacity problem 知識はコストによって階層化されています。常に必要な事実は常時ロードされ、手順書はオンデマンドでロードされ、コンパイル済みの過去の調査が何百件も検索可能なアーカイブに収められています。この階層化が生存を可能にします。長い調査は、何よりもまずコンテキスト枯渇によって死ぬからです。 ある調査の解剖 あの午前 2 時 33 分のアラームに戻りましょう。エージェントが踏むすべてのステップはログに記録され、投稿するすべての主張は、それを生み出したクエリへのリンクを持ちます。 図 2: 分刻みで見た調査。アラームから診断の投稿まで 13 分 35 秒。人間による調査であれば始まってすらいなかった時間帯である。 より深い価値は、誰も手作業ではやらない仕事にあります。その 1 週間前、別の新しいモデルのアラームは、モデル全体に及ぶキャパシティイベントのように見えました。すべてのストリームエラーを、リクエスト ID でルーティングレコードと突き合わせたところ、エージェントはエラーの 96.5% が私たちの分離された配信セルのうちわずか 2 つに由来し、残りのセルではエラーがゼロだったことを突き止めました。生き残った仮説「セルごとのクォータが不均等」は ReadOnly の認証情報で確認され、上流の依存関係に潜んでいたバグを露呈させました。エンジニアでも同じことはできますが、週末の夜に、インシデント対応の最中に、何十ものアカウントをまたいで、というのは無理です。 フライホイール: 人間が作り、エージェントが回す このシステムを毎週改善しているのは、その周りを回るループです。エンジニアがエージェントを導き、その学びをキュレーションします。 図 3: フライホイール（調査する、記録する、コンパイルする、進化させる）。次の同一アラームは、前回が終わったところから始まる。ステップ 1 からではない。 これを回し続けるための仕組みが 4 つあります。 修正はレッスンになる。 各修正は一度だけ保存され、その後のすべてのセッションに注入されます（数千の完了済みランに対して数百の修正であり、メモリの必要量を削減します）。そしてエージェントは、自分を誤らせたドキュメントにパッチを当てます。プロンプトのバグはドキュメントのバグから生まれたものだからです。 調査は知識になる。 クローズされたチケットは、その後のセッションが真っ先に照会するアーカイブへと蒸留されます。 エージェントがスキルを作成し、人間がレビューする。 新規のインシデントの後、エージェントは新しい手順書か差分（delta）を作成します。レートリミットの手順書は、まさにその同じ夜にこの方法でセルごとのステップを得ました。エンジニアと夜間ジョブが、 もう 1 つのコードベースとまったく同じように ライブラリをキュレーションします。 エージェント間での状態共有。 条件付き書き込みのエスカレーショントラッカーによって、同じインシデントを観測している 10 個の並列エージェントは、上流チケットを 10 件ではなく 1 件だけ起票します。 その一方で、このループが私たちを裏切ったこともあります。レッスン取り込みのパイプラインは、かつてセッション終了時に保留状態だったテキストをそのまま受け入れていました。そのため中断されたセッションが、生のチケットコメントを一字一句そのまま修正ストアに書き込み、その後のセッションがそれを運用上の知恵として誤って学習してしまいました。修正策は、書き込み前のスキーマ検証と、夜間のクリーンアップでした。キュレーションと慎重な管理を欠くと、学習パイプラインはゴミを、知識と同じくらい効率よく複利で積み上げてしまいます。 何にコストがかかり、何を取り戻すのか Kiro はエージェントを、顧客が購入するのと同じ単位であるクレジットで計測します。代表的な 1 か月で約 250 件の調査が生まれ、無人で、中央値 13.6 分で完了しました。支出は 自制ではなく構造によって制限されます 。すなわち、セッションのタイムアウト、スタック検知、同時実行数の上限、そしてファンアウト用の安価なモデルです。すべて合わせても、月々の請求額は私たち自身の最上位サブスクリプション 9 個分に相当し、取り戻した時間はブリーフのレビュー、エージェントの修正、根本原因の修正へと注がれます。 私たちが間違えたこと（ あなたが学べるように ） エージェントは、あなたのドキュメントのバグをマシンの速度で受け継ぐ。 リファレンスドキュメントの古くなった 1 行が、人間が気づく前に複数のチケットへ伝播しました。私たちの修正策は より良いモデルとは関係なく、新しい習慣でした 。セッションがおかしくなったら、それを修正し、何が自分を誤らせたのかを問い、そのドキュメントを直す。一度きり 5 分をかけるほうが、毎週 5 分を失うよりましです。 自信ありげな中途半端な答えは、間違った答えよりコストが高い。 どのモデルアップグレードよりも役立ったステアリングルールが 1 つあります。エージェントは結論を述べる前に、競合する仮説を検証して排除しなければならない、というものです。さらに算術・アラーム状態・重複についての自動チェックによって、以前は人間がレビューで捕まえなければならなかったカテゴリまるごとのエラーが取り除かれました。人々が信頼するのは、自分で検証できる出力であって、正確さについての主張ではありません。 簡潔さが信頼を築く。 初期のエージェントは、ステップごとの作業をすべて顧客に見えるスレッドへ投稿していました。内容は正確でしたが、体験としてはノイズが多いものでした。今では、見えるスレッドには短い投稿を 1 つだけ、詳細はすべてワークログに送っています。パートナーチームはエージェントを、その最良の調査ではなく、その最悪のコメントで評価するのです。 自律性に単一の設定は存在しない。 ある 1 週間で、私たちはエージェントを 権限付与と抑制の両方向で 修正しました。「コードレビューを作成する許可をいちいち求めるのをやめろ。そのレビュー自体が承認だ」と、「チケットを解決したり深刻度を変えたりするな。それをやるのは人間だけだ」です。すべてのアクションにはそれ専用のルールが必要であり、エージェントのステアリングファイルはそれらのルールの一覧なのです。 セキュリティはプロンプトだけでなく、インフラから生まれる。 すべての無人セッションは、ロールの許可リスト（allowlist）を通じてデフォルトで ReadOnly になり、Admin 権限のリクエストはエラーを返します。各認証情報は 1 セッションのために発行され、エージェントが宣言したタスクにスコープが絞られるため、セッションは自分がリクエストした API しか呼び出せません。 これからどこへ向かうのか 今日、エージェントはトリアージを行います。そしてますます、修復も行うようになっています。修正のためのコードレビューやしきい値のチューニングを、同じハーネス上で、必須の人間レビューを経る形でドラフトを作成します。そしてシステム全体が markdown、MCP サーバー、そして素の Kiro CLI でできているため、私たちが自分たち自身のために行うすべての改善は、 私たちが提供する製品にも関係します 。 オンコールのローテーションは今も存在しますが、仕事は変わりました。もはや午前 2 時 33 分に調査を始めるのではなく、午前 2 時 46 分に完了した調査をレビューするのです。オンコールエンジニアのポケベルは、エージェントがすでに行った仕事のための意思決定キューになりつつあります。 Swami Sivasubramanian 氏によるフロンティアチームに関する記事 は、開発チームにとっての第一歩として「エージェントのコンテキストに投資する」ことを挙げています。私たちのチケットキューは、オペレーションのためにエージェントに投資する 1 つの例です。 これがフロンティアエンジニアの新しい生活の 1 日目であり、まだ続きがあります。

本記事は「 Continuous Prompt Evaluation: How We Use LLM Judges and Live Signals to Improve Kiro Agent Quality 」を翻訳したものです。 課題: システムプロンプトの挙動は予測が難しい プロンプトの挙動を網羅的に検証するのは困難です。システムプロンプトは、モデル・ツール・コードベース・タスク・ユーザーのあらゆる組み合わせにまたがって動作しますが、どんなテストスイートでもそれをすべてカバーすることはできません。単独で見れば妥当に思える指示が、プロンプトの作成者が想定していなかったケースで意図しない挙動を引き起こすことがあります。また、あるシナリオを改善する変更が、別のシナリオを悪化させることもあります。 プロンプトの陳腐化（staleness）は、この広範な問題の一例にすぎません。ある指示は、すでにまれで観測しにくい問題を引き起こしているかもしれませんが、新しいモデルがその指示をより厳密に守るようになると、より明確に有害なものになります。新しいツール、ワークフロー、ユーザーの利用パターンも、同じ潜在的な欠陥を表面化させることがあります。 ベンチマークは引き続き重要な品質シグナルですが、日々の開発業務で現れるすべての挙動を捉えることはできません。私たちに必要だったのは、実際のワークフロー上で問題を検出し、繰り返し現れるパターンを分類し、それをプロンプトの指示までたどり、モデルや利用状況の変化に合わせて修正を検証する仕組みでした。 システムの全体像 本記事は、人手で作成されたシステムプロンプトや設定の変更を評価することに焦点を当てています。自動的なトラジェクトリマイニング、変更の自動生成、ハーネス全体の自己改善については扱いません。このワークフローは、ベンチマーク結果と、社内の開発者による数千件の Kiro との会話を LLM で分析した結果を組み合わせ、タスク完遂・検証・ツール利用における改善機会を特定します。以下の 4 つのステージからなります。 診断（Diagnose） : 頻度の高い不満カテゴリを特定し、それをプロンプトの指示までたどる 設計（Design） : 分離して評価できるよう、狙いを絞ったプロンプト変更を設計する テスト（Test） : 社内トラフィック上で、統制されたコホートに対して変更をテストする 評価（Evaluate） : 各コホートを LLM ジャッジで評価し、不満や挙動品質の問題の変化を測る 図 1: プロンプト評価の 4 ステージのサイクル。プロンプト・ユーザーの挙動・モデルの能力が変化するのに合わせて繰り返す。 4 ステージのプロンプト評価サイクル 上の図は、以下で説明する 4 つのステージをまとめたものです。プロンプト・ユーザーの挙動・モデルの能力が変化するたびに、このサイクルを繰り返します。 1. 診断（Diagnose）。 現在の社内トラフィックにジャッジを実行し、繰り返し現れる不満パターンを特定・分類します。そのうえで、頻度の高いクラスタごとに、原因となっているプロンプトの指示や、欠けている指示までたどります。たとえば、繰り返し現れる「タスクが未完了」という不満は、エージェントに対して計画を実行するのではなく説明するよう促していたガイダンスに起因していました。 2. 設計（Design）。 診断された問題に対して、狙いを絞った変更候補を作成します。候補は多くの場合、安全性・検証・トーン・挙動のいずれかに対応するもので、各候補はテスト前に、意図する挙動とリグレッションのリスクを明示します。 3. テスト（Test）。 候補をコントロール（対照群）と、分離したコホートで比較します。有用な場合には、相互作用が見えてくる可能性のある「候補を組み合わせたコホート」でも比較します。実験の設計とサンプルサイズによって、その結果が方向性を示すだけのものか、より広い結論を支持できるものかが決まります。 4. 評価（Evaluate）。 同一の LLM ジャッジのルーブリックを各コホートに適用し、不満率と挙動品質の問題の発生率を比較します。得られた証拠にもとづいて、各候補を採用（ship）・修正（revise）・却下（reject）します。 LLM-as-judge: 重要なものを測る 私たちは、社内の会話を 15 の挙動ディメンションでスコアリングする評価フレームワークを構築しました。たとえば以下のようなものです。 タスクの完遂度（Task completeness） 主張の正確性（Claim accuracy） （エージェントは断定する前に検証したか？） コードスタイルの遵守（Code style adherence） 失敗し続けているアプローチの認識（Recognition of repeated unsuccessful approaches） 破壊的アクションのフラグ付け（Destructive-action flagging） ツール利用の適切さ（Tool use appropriateness） 検証の挙動（Verification behavior） （テストの実行、コンパイルの確認） このジャッジは、会話からの明示的な証拠を必要とします。すなわち、修正・不満・放棄されたタスク・確認などです。曖昧な会話はどちらのバリアントにも不利に数えないことで、比較の一貫性を保ち、過剰な偽陽性（false positive）の判定を避けるために保守的な設計にしています。 図 2: LLM ジャッジが会話を読み取る仕組み。左にチャットのやり取り、中央に不満の判定基準、右に分類された挙動品質の出力が並ぶ。 図中に示したジャッジのプロンプトは、あくまで最小限の説明用の例であり、実際の評価で使われているものではありません。 ジャッジは主に 2 つのシグナルを測定します。 明示的な不満（Explicit dissatisfaction）: ユーザーは明確に不満を表明したか、会話を放棄したか、あるいはエージェントの作業をやり直したか？ これは会話中の明示的なフィードバックからのみ推定され、ツールの結果が示唆するものやアンケートのスコアからは推定しません。 挙動品質の問題（Behavioral quality issues）: エージェントは 15 の品質基準のいずれかを満たさなかったか？ 例としては、コードを先に読まずに主張する、タスクを完遂する前に止まる、プロジェクトの既存パターンを無視する、などがあります。 両方のメトリクスは、コントロール群とトリートメント群で同一のルーブリックを用いるため、同じ評価設計の中で構成どうしを一貫して比較できます。 図 3: 会話はストレージからコホートごとのバケットを経て不満ジャッジへ流れ、ジャッジはコホートごとの不満率と挙動問題の件数を出力する。 A/B 実験のインフラ プロンプトの変更をリリースする前に、社内トラフィック上で構成どうしを別々のコホートで比較します。これらの実験では、サービスが、対象となる社内開発者を、ユーザー識別子の決定的なハッシュを使って安定的なユーザーバケットに割り当てます。この割り当ては、観測された会話の結果とは独立しています。各バケットは、ある実験において 1 つのプロンプトバリアントに対応します。 ジャッジのパイプラインは、記録された実験の割り当てにもとづいて会話を分析し、すべてのコホートに同一のルーブリックを適用します。安定的な割り当てはプロンプト実験内のコホート選択を統制しますが、ライブトラフィックにおけるすべてのバイアスや相互作用の要因を取り除くわけではありません。正確な割り当てとサンプルサイズは実験ごとに異なるため、結論の強さはその比較で得られた証拠に依存します。分離された小さな候補コホートは、本番への影響を精密に推定するものというより、方向性を示す診断（directional diagnostics）にとどまります。 ある迅速に進めた社内デプロイでは、安全性・検証・トーン・挙動の 4 カテゴリにわたる 27 個のプロンプト変更候補をスクリーニングしました。安定したコントロールを、分離した候補コホートと、候補を組み合わせたコホートと比較しました。小さな分離コホートは、起こりうるリグレッションを局在化させるための方向性の診断であって、個別に影響を推定できるだけの検出力を持つものではありませんでした。悪化を示した候補は修正または削除し、組み合わせたコホートや、より大規模な追試の比較によって、より広い結論を支持しました。 ジャッジのパイプラインは会話の結果をスコアリングするため、ユーザーから見える設定の選択肢どうしを比較することもできます。私たちはこれを使って、デフォルトの reasoning effort レベルを評価しました。コード修正やデバッグといった一般的なタスクでは、より高い effort レベルで改善が見られました。reasoning effort レベルの設定について詳しくは、 reasoning effort のドキュメント を参照してください。 直近サイクルの結果 以下の数値は、社内の実験レベルの比較で観測されたデルタ（差分）です。これらは今回の評価サンプルを説明するものであり、普遍的な本番効果の推定値として読むべきではありません。 初回のモデル＆プロンプト実験 Kiro CLI （最初に評価したモデル＆プロンプト構成）: 明示的な不満シグナル: 5% 減少 挙動品質の問題: 32% 減少 タスク完遂の問題: 10.6% 減少 Kiro IDE （最初に評価したモデル＆プロンプト構成）: 挙動品質の問題: 20% 減少 タスクの未完了配信: 21% 減少 失敗し続けているアプローチ: 36% 減少 スタイルの不一致: 54% 減少 より新しいモデルでの再検証 再検証は、初回の実験とは別の問いに答えるものです。初回の実験は、最初に評価したモデル＆プロンプト構成に対するプロンプト変更の効果を測りました。再検証は、モデルをアップグレードした後でも同じ変更が依然として役立つかどうかをテストします。 より新しいモデル＆プロンプトのベースラインは、同じルーブリック (評価基準表) のもとですでに挙動品質の問題が少なく、プロンプトが上乗せできる余地（headroom）が小さくなっていました。したがってここでの改善幅が初回サイクルより小さいのは設計上の想定どおりであり、リグレッションではありません。その難しいベースラインに対してさえ、同じプロンプト変更は依然として両方のシグナルを正しい方向へ動かしました。挙動品質の問題をさらに 4% 減らし、明示的な不満を 2.6 パーセントポイント改善しました。私たちはこの結果を、モデルアップグレード後も変更が依然として役立つという方向性の確認であって、精密な本番推定値ではない、と読んでいます。 より新しいモデルは、一部の指示をより文字どおりに守るようにもなりました。特に低い effort レベルでその傾向が顕著で、以前のモデル向けにチューニングされたガイダンスが、あらゆるケースでそのままきれいに引き継がれるわけではありませんでした。そこで私たちは、モデルアップグレードのたびにそれを新しいモデル＆プロンプト構成として扱います。既知の不満ケースを再現し、過去にうまくいったケースをリグレッションチェックとして使い、挙動品質・不満・リグレッション・効率を測定し、ロールアウト前に再チューニングします。 自前のエージェントシステムを評価するチームへの示唆 ライブ利用の評価はベンチマークを補完する。 標準的なベンチマークは引き続き有用です。社内フィードバックは、実際のユーザーセッションからシステムプロンプト改善の機会を明らかにします。そうしたセッションには、標準的なベンチマークが同時には捉えないディメンションがしばしば含まれます。たとえば、ユーザー固有のワークスペースのコンテキスト、実際の本番サービスとのやり取り、別々の作業セッションをまたいで再開される会話、その他の現実世界のノイズなどです。 方向性のスクリーニングには分離コホートを使う。 小さな候補コホートはリグレッションの局在化に役立ちますが、より広い結論を導く前には、組み合わせたコホートと、十分な検出力を持つ追試の比較が必要です。 プロンプトの効果はモデル依存である。 同じ変更が、あるモデルバージョンでは挙動品質の問題を 32% 減らし、別のバージョンでは 4% 減らしました。モデルをアップグレードするたびに再検証のパスが必要です。 不要になったガイダンスは廃止する。 最も大きな改善のいくつかは、古くなった制約を取り除くことから生まれます。行数の上限や、非推奨になったツールの回避策などです。プロンプトはシンプルなほうが、モデルの挙動と整合させ続けるのが容易になります。 これが Kiro ユーザーにとって意味すること これらの変更によって、Kiro はタスク全体を完遂し、うまくいっていないアプローチを軌道修正し、プロジェクトの既存のコードスタイルに従う可能性が高くなります。また、次に進む前に変更がコンパイルできてテストが通ることを検証し、リスクのあるアクションの前には確認を取りつつ、安全な作業はそのまま進めるようにもなります。私たちはこのプロンプト評価を、プロンプトとモデルが変化するたびに繰り返し行い、デプロイ前に更新を検証しています。

「金融リファレンスアーキテクチャ日本版」は、2022 年 10 月に v1.0 を公開して以来、多くの金融機関のお客様 や パートナー様 にご利用いただいてきました。勘定系や顧客チャネル、データ分析基盤といった金融サービスのワークロードについて、AWS 上で FISC 安全対策基準を踏まえたシステム設計を検討する際のガイドやサンプルを提供しています。 今回、その内容を刷新した v2 を GitHub 上で リリース しました。v2 では、コンテンツをエンジニアが読むためだけのものから、エンジニアと AI エージェントが同じように読んで使えるものへと作り直しています。 金融リファレンスアーキテクチャ日本版 の 概要 「金融リファレンスアーキテクチャ日本版」は、金融システムの「高い信頼性が必要なミッションクリティカル領域」の維持と強化につなげていただくためのアセットです。セキュリティとガバナンスの確保、レジリエンスの強化、モダナイゼーションの加速、コンプライアンスへの対応といった、日本の金融機関のエンジニアが向き合う作業を支援するコンテンツで構成されています。 金融リファレンスアーキテクチャ日本版 v2 での進化 金融リファレンスアーキテクチャ日本版 v2 は AIエージェントフレンドリーなコンテンツ提供形態へと刷新し、そのナレッジを Agent Skills (エージェントスキル) の形式で提供します。エンジニアの皆様 に加えて、皆様が利用する AI エージェント や 生成AIツールからも扱えるナレッジへと進化しました。 v2 での主な変更点は次のとおりです。 Agent Skills を中核に据えた提供形態への刷新 31 のスキルをカテゴリ別に収録 サイバーレジリエンスと FSI Lens for FISC のスキルを追加 Webアプリケーションツール「GameDay Plan Generator 」の公開 Agent Skills を中核とした提供形態への刷新 v2 で最も大きく変わったのは、ナレッジの提供形態です。金融システムに求められるセキュリティ、可用性、コンプライアンスの知見を、Agent Skills というオープン標準のフォーマットを利用して提供しています。Agent Skills は、生成 AI を用いた開発ツールが解釈できる形式で手順や設計方針を記述する 仕様 です。同じコンテンツを、設計を検討するエンジニアが読むだけでなく、そのエンジニアが日々使う AI エージェントにも渡して利用できます。 この形式を選んだ背景には、金融 IT の開発現場で AI エージェントや生成 AI ツールの利用が広がってきたことがあります。v2 では、想定する利用者に、金融 IT のエンジニアやアーキテクトに加えて、それらの担当者が利用する AI エージェントや生成AIツールを据えました。設計原則やベストプラクティスを人が読んで理解するだけでなく、設計や開発を支えるAIエージェントにも同じ知識を渡すことで、人と AI の双方の能力を広げることを目的としています。 これにより、構成の検討や設計レビューの場で、AI エージェントが FISC 安全対策基準やリファレンスアーキテクチャを踏まえた回答を返せるようになり、検討の出発点を素早く用意できます。 31のスキルをカテゴリ別に収録 v2 では、v1 で扱ってきたワークロードに加えて、AWS を利用する金融 IT エンジニアの日々の作業を支援するナレッジを含め、現時点で 31 のスキルを収録しています。金融のビジネスワークロードから、それらを支える共通基盤、生成 AI、セキュリティ、情報収集の支援までを一つのカタログにまとめています。主なカテゴリと代表的なスキルは次のとおりです。 コンテンツカテゴリ 主な Agent Skills 金融ワークロード 勘定系（Banking Core）、モバイルバンキング、コンタクトセンター、Capital Marketのオーダー管理、マーケットデータ配信、保険データ分析、クレジットカードイシュア 共通基盤 ガバナンスベース、ハイブリッドクラウド（AWS Outposts）、メインフレーム連携、金融オープン API（FAPI）、データレイク 生成 AI 生成 AI プラットフォーム、生成 AI ユースケース セキュリティとレジリエンス サイバーレジリエンス、ランサムウェア対策、FISC 安全対策基準からのAWS Security Agent セキュリティ要件定義生成、AWS Payment Cryptography 導入ガイド、AWS 操作のセキュリティガード Well-Architectedフレームワーク FSI Lens for FISC 情報収集の支援 AWS 新機能やブログ、セキュリティ情報の取得、日本銀行の統計、金融庁の公表情報、国内のセキュリティ注意喚起の取得 業務支援と汎用ツール お客様固有のコンテキスト管理、Working Backwards によるプロダクト企画、MCP ツールの呼び出し、スキル定義ファイル (SKILL.md) のドキュメントファイル化 全 31 スキルの一覧は、リポジトリの スキル一覧 で確認できます。 v2 で新たに加えたコンテンツ サイバーレジリエンスとランサムウェア対策の スキル 近年のサイバーレジリエンスとランサムウェア対策への関心とニーズの高まりを受けて、レジリエンスのスキルを充実させました。サイバーレジリエンスのスキルでは、論理的に隔離したバックアップやアカウントをまたいだ復旧、ネットワークの自動隔離といったアプローチを扱います。ランサムウェア対策のスキルは、保護、検知、対応、復旧、そして組織としての対応という 5 つのフェーズで整理し、それぞれをサブスキルに分けて提供します。インシデントのどの段階を検討しているかに応じて、必要なスキルだけを AI エージェントに読み込ませられます。 FSI Lens for FISC のスキル FSI Lens for FISC は、AWS Well-Architected Framework を金融向けに拡張し、FISC 安全対策基準に沿って設計を点検するための評価軸 (レンズ) です。運用上の優秀性、セキュリティ、信頼性の 3 本の柱で構成し、各ベストプラクティスには FISC の実務基準の番号を対応づけています。v2 では 2025 年 3 月に公開された第 13 版を元にスキルとして提供し、AIエージェントに渡してレビューに活用することができます。今後、2026 年 3 月に公開された第 14 版をもとにした更新も予定しています。 Webアプリケーションツール GameDay Plan Generator 金融リファレンスアーキテクチャ日本版 v2 は、「Agent Skillsを中心としたAIエージェントフレンドリーなナレッジを提供する」とお伝えしましたが、コンテンツはそれだけにとどまりません。v2 を構成するコンテンツの1つとして、障害対応訓練の計画立案を支援する「 GameDay Plan Generator 」を公開しました。レジリエンスは設計しただけでは十分とは言えず、それを試す訓練があってこそ確かなものになります。このツールは、その訓練の準備にかかる手間を軽減することを狙ったものです。 使い方はシンプルで、AWS CloudFormation テンプレート または 構成図 を渡すだけで、次のものをまとめて生成します。 障害シナリオの一覧と、シナリオごとに「なぜそれを試すのか」という理由 AWS Fault Injection Service の実験テンプレート 訓練中に監視すべき観測ポイントの定義 検知、復旧、影響把握、コミュニケーションの 4 つの軸からなる評価基準 シナリオ一覧やタイムラインを載せた HTML のダッシュボード 生成した結果はダッシュボード上で確認でき、対話しながらシナリオを調整できます。本ツールの特徴は、 Amazon Bedrock を使って、ルール定義だけではカバーが困難な連鎖的な障害や単一障害点を分析し、シナリオを補強する点です。Bedrock を利用できない環境では、ルールベースの生成に切り替えて動作します。訓練計画の初版を短時間で用意できるため、設計から訓練までを一続きの流れとして支える道具として活用いただけます。 まとめ v2 のコンテンツ種類 と GitHub リポジトリ v2 は現時点で、以下の種類のコンテンツを提供しています： 金融ワークロードにおける設計上のポイントやリファレンスアーキテクチャを記述した、ガイダンスとしてのAgent Skills AWSを利用する金融ITエンジニアの日々の作業を支援する、ツールとしてのAgent Skills 特定の用途における金融ITエンジニアを支援する、Webアプリケーション また、v2からは、v1と異なり、複数のリポジトリで そのコンテンツを提供する形になりました。 GitHub リポジトリ： aws-samples/sample-fsi-reference-architecture-jp Agent Skills を提供します。リポジトリをクローンすれば、収録したスキルをそのまま参照でき、対応する開発ツールから AI エージェントに読み込ませることもできます。あわせて、v2のコンテンツ全体を紹介するポータルとしての役割も持ちます。 GitHub リポジトリ： aws-samples/sample-fsi-reference-architecture-jp-gameday-plan-generator &nbsp; Webアプリケーションツール「GameDay Plan Generator」を提供します。このように、コンテンツによっては個別のリポジトリで公開します。 いずれのコンテンツも v1 と同様に MIT-0 (MIT No Attribution) ライセンスのもとで公開しており、エージェントスキルの多くは日本語と英語の両方で用意しています。なお、収録しているサンプルコードは設計や動作を検証するためのもので、本番環境でそのまま利用することは想定していません。 おわりに 金融リファレンスアーキテクチャ日本版 v2 は、今後も継続的な拡充を予定しています。まずはリポジトリをクローンし、お手元の AI エージェントに関心のあるスキルを読み込ませてみてください。ぜひ、ご質問やフィードバックをGitHub の Issue などでお寄せください。 本ブログ記事は、AWS のソリューションアーキテクト 松原武司 が執筆しました。

本記事は、2026 年 8 月 18 日に Brian Beach が公開した「 Close the laptop, keep the agent: building with cloud sessions 」を翻訳したものです。 Kiro は cloud sessions（preview）をリリースしました。これは、自分のマシンで AI エージェントを動かすときにずっと引っかかっていた 1 つの問題、つまりマシンそのものに縛られる問題を解決してくれます。cloud sessions を使えば、エージェントはラップトップではなくクラウドのサンドボックス上で動きます。エージェントはリポジトリをクローンし、作業をこなし、席にいるかどうかに関係なく走り続けます。ふたを閉じても、電車に飛び乗っても、まったく別のマシンに乗り換えても、セッションには何も影響ありません。Kiro Web を使ったことがある方には、この感覚は馴染みがあるはずです。今回新しいのは、これが CLI と IDE にも広がった点です。CLI、IDE、ブラウザーのどれからでも様子を確認して作業を再開できます。すべてが同じ場所に存在する 1 つのエージェントだからです。 本記事では、実際のタスクを最初から最後まで見ていきます。すでに顧客、商品、注文の機能を備えた既存の EC アプリに、決済 API を追加するタスクです。私は Kiro CLI から作業を進めます。ここが自分にとっていちばん落ち着く場所だからです。ただし、ここで紹介する内容は IDE の Agent Focus Mode でもまったく同じように動きます。同じハーネス、同じエージェント、同じセッションで、好きな画面 (サーフェス) を選べます。 まずは有効化から 機能を探しに行く前に少しだけお知らせです。IDE では、Agent Focus Mode を開くとサイドバーに Cloud Session セクションが表示されます。CLI では、 --cloud フラグを付けて起動します。 組織で IAM Identity Center を使っている場合は、Kiro プロファイルを設定した AWS アカウントで、管理者が Settings &gt; Kiro Settings から Cloud Sessions (Preview) を有効化します。以前に Kiro Web (Preview) を有効化していた組織では、Cloud Sessions もすでに有効化されているため、追加の操作は不要です。この 1 つのトグルで、Kiro Web、Agent Focus Mode、CLI の cloud sessions がまとめてカバーされます。詳細は Cloud sessions governance を参照してください。 AWS コンソールの Kiro Settings 画面で Cloud Sessions (Preview) を有効化する。 スイッチ 1 つで準備完了です。 設定について一言 すでに触れたとおり、セッションはクラウドのサンドボックスで動きます。つまり、ローカルマシンの中まで見に行って設定を取ってくることはできません。たとえば、エージェントスキルがそうです。 Kiro をローカルで実行すると、設定は 2 つの場所から読み込まれます。ワークスペース側の .kiro/skills と、個人プロファイル側の ~/.kiro/skills/ です。cloud sessions では、ワークスペースのスキルはリポジトリの中にあるので一緒に付いてきます。しかし、ローカルプロファイルのスキルは付いてきません。代わりに、セッションはクラウドプロファイルで定義したスキルを使います。クラウドプロファイルは Kiro Web で管理します。まだクラウドプロファイルを設定していなければ、まず app.kiro.dev にアクセスして、そこでスキルを設定してください。私のプロファイルには「Python Coding Standards」というスキルを設定してあるので、どのマシンから始めてもエージェントがこのスキルを適用してくれます。 Kiro Web の Skills 設定画面。クラウドプロファイル側でスキルを管理する。 ですから、クラウドでの作業に必要なスキルは、クラウドプロファイルに登録しておきましょう。ステアリングファイル、カスタムエージェント、その他 .kiro/ フォルダーに置くものについても同じです。 CLI を立ち上げてリポジトリを取り込む cloud session の起動は、フラグ 1 つで済みます。 kiro-cli chat --cloud セッションが起動したら、 /repo を使って作業したいリポジトリを Kiro に伝えます。リポジトリは 1 つでも複数でも指定できるので、変更が複数のプロジェクトにまたがるときに便利です。今回は GitHub を使っていますが、GitLab も利用でき、同じセッション内でプロバイダーを混在させることもできます。ここでは brianjbeach/fastapi-demo を選びます。 CLI の /repo コマンドで brianjbeach/fastapi-demo リポジトリを選択する。 Kiro がリポジトリをサンドボックスにクローンし、開発の準備が整います。 プロンプト（音声機能の力を少し借りて） 何をしたいかを伝えましょう。プロンプトはこちらです。 EC アプリケーションに決済 API を追加してください。顧客が保留中の注文に対して支払えるようにします。決済には、金額、支払い方法、タイムスタンプを記録します。支払いが成功したら、注文のステータスは confirmed に遷移するようにしてください。 これを全部タイプする代わりに、新しい音声機能を使いました。 /voice と入力してから、あとは声に出して話すだけで、Kiro が文字起こししてくれます。詳しくは voice docs で確認できます。キーボードを叩き続けなくても、意図をまるごと 1 段落分プロンプトに流し込める、なかなか気の利いた方法です。 CLI で /voice コマンドを使い、音声プロンプトを文字起こしする様子（鮮明な動画は 原文記事 を参照）。 ここからが良いところです。エージェントはクラウドで走り始めたので、私は自由の身です。エージェントが働いている間、私はジムに行ってこようと思います。 というのは冗談で、実はジムには行きません。SNS を延々とスクロールして時間を溶かします。どちらにしても要点は変わりません。もう何もラップトップに縛られていない、ということです。 どこからでも様子を確認 セッションはクラウド上にあるので、どのクライアントからでも様子を確認できます。ちょっと Kiro Web に行って、進み具合を見てみましょう。 Kiro Web から cloud session の進捗を確認する。 ここが本当に自分のワークフローを変えたところです。セッションはマシンから完全に切り離されています。ラップトップのふたを少しだけ開けたまま「スリープしないでくれ」と祈りながら廊下を歩く必要はもうありません。長時間ジョブを生かしておくためだけに、空いているターミナルで caffeinate を走らせておく必要もありません。「このパソコンには触らないで」の付箋を貼る必要もありません。作業はクラウドで行われ、そのままクラウドに残り、私がまったく別の場所にいる間もコツコツと進んでいきます。 続きから再開する 作業に戻る準備ができたら、いちばん手近なクライアントからまったく同じセッションを再開します。 CLI からは、最初に起動したときと同じコマンドを使います。 kiro-cli chat --cloud --resume あるいは IDE の Agent Focus Mode からも再開できます。cloud sessions パネルに、実行中および過去のセッションが一覧表示されます。そこからクリック 1 つでこのセッションに戻り、何が作られたかのサマリーを確認できます。 IDE の Agent Focus Mode で cloud sessions パネルから同じセッションを再開する。 完成した成果物はこちらです。新しい payments.py 、モデルとストアの更新、 POST /payments/ エンドポイント、そして支払い成功後に confirmed へ遷移する注文。読み解くのに苦労するコードの山ではなく、そのままレビューできる PR です。私が席を外して別のことをしていた間に、頼んだとおりのものが仕上がっていました。 まとめ cloud sessions は、セッションの起動方法としてはささやかな変化ですが、作業の感覚としては大きな変化をもたらします。エージェントは、ラップトップで面倒を見続けるプロセスではなくなり、CLI、IDE、Web、モバイルアプリのいずれからも触れる、クラウドでただ動き続ける存在になります。ある場所で起動し、別の場所で確認し、たどり着いたどこででも仕上げる。そんな流れが可能です。 管理者に AWS コンソールで cloud sessions を有効化してもらい、クラウドプロファイルのスキルを整えたうえで、 kiro-cli --cloud で試してみてください。実際のタスクを起動したら、ラップトップを閉じて、その気持ち良さを味わってみてください。詳細は cloud sessions docs を参照してください。Cloud Sessions は US East (N. Virginia) の us-east-1 リージョンでのみ利用できます。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2026 年 8 月 21 日 に公開された「 Increase your cluster density with Memory Tiering in Amazon Elastic VMware Service 」を翻訳したものです。 Amazon Elastic VMware Service (Amazon EVS) で Memory Tiering を使ってクラスター密度を高めると、AWS インフラのコストを削減できます。Amazon EVS は VMware Cloud Foundation (VCF) 9.0 および 9.1 をサポートするようになりました。VMware Cloud Foundation (VCF) 9.0 で導入された Memory Tiering は、高速な NVMe デバイスを DRAM に加えて第 2 のメモリ階層として使用する ESX の新機能です。現在利用できる 2 つの Amazon EVS インスタンスタイプ (i4i.metal と i7i.metal-24xl) の両方で Memory Tiering を有効化できます。本記事では、Memory Tiering とは何か、クラスターのサイジング方法がどのように変わるか、そして Amazon EVS 上で稼働する VCF 9.1 デプロイで Memory Tiering を有効化・無効化する方法を詳しく説明します。 VCF 9.1 における Memory Tiering の概要 Memory Tiering は ESX カーネルに統合されたホストレベルの機能で、ハイパーバイザーに 2 つのメモリ階層を提供します。物理ホストの DRAM で構成される Tier 0 と、同じホストの NVMe で構成される Tier 1 です。メモリ管理層の階層化アルゴリズムは両方の階層のページアクティビティを監視し、頻繁にアクセスされる (ホットな) ページを DRAM に保持し、アクセス頻度の低い (コールドな) ページを低速な NVMe 階層に移動します。ホストのメモリ消費量が DRAM 容量の約 80% に達すると、コールドページの NVMe への階層化が始まります。ページの分類はアクセスの新しさとアクセス頻度の両方に基づくため、ワークロードが実際に使用するワーキングセットは DRAM に保持され、アイドル状態のメモリは低速な階層に置かれます。 Memory Tiering をメモリスワップと混同しないでください。スワップはランダムにページを選択し、ゲストストレージとデバイスを共有することが多い仕組みです。一方 Memory Tiering は専用の直接接続 NVMe とページエージング技術を使用し、極端な負荷時の安全弁としてだけでなく、予測可能なパフォーマンスを提供します。階層化の対象は VM のメモリページのみで、カーネルメモリは対象になりません。 VCF 9.1 では、Memory Tiering は vSphere Configuration Profiles (Desired State Configuration とも呼ばれます) を使用して構成し、クラスター内のすべてのホストに一貫して適用されます。ホストごとの ESX CLI コマンドやスクリプトを維持する必要はありません。VCF 9.1 では Tier 1 のソフトウェアミラーリングも追加され、追加の RAID ハードウェアなしで階層化されたメモリの冗長性を確保できます。 Amazon EVS が Memory Tiering をサポートする仕組み Amazon EVS は、お客様の Amazon Virtual Private Cloud (Amazon VPC) 内でベアメタルインスタンス上に VCF を直接実行します。Memory Tiering は、Amazon EVS が現在提供する 2 つのインスタンスタイプ (i4i.metal と i7i.metal-24xl) の両方でサポートされます。どちらのインスタンスタイプの NVMe も、階層化によって生じる持続的な書き込みアクティビティに必要な書き込み耐性を備えているため、追加のドライブ適格性確認は不要です。 Amazon EVS のホストハードウェアと一般的なオンプレミスホストには、アーキテクチャ上の重要な違いがあります。オンプレミスでは、Memory Tiering 専用の NVMe デバイスをホストに追加できます。Amazon EVS では、両方のインスタンスタイプのローカル NVMe を、デプロイ時に vSAN が使用します。ドライブを Memory Tiering に使用するには、まず vSAN から取り除いてからメモリ階層に割り当てる必要があります。Amazon EVS はハイパーコンバージドストレージアーキテクチャを使用しているため、Memory Tiering に割り当てる容量は vSAN から取り除く容量になります。NVMe を Memory Tiering に使うか vSAN に使うかのトレードオフについては、次のセクションで詳しく説明します。 Memory Tiering がクラスターサイジングに与える影響 クラスターのサイジングで物理メモリが制約になる場合、Memory Tiering を使うとホストを追加せずにクラスターの実効メモリ容量を増やせます。Memory Tiering によってサイジングの計算や Amazon EVS でデプロイするホスト数がどう変わるかを理解しているかどうかが、計画的なデプロイと過剰コミットになったデプロイの分かれ目です。 2 つの階層が組み合わさって実効メモリになる仕組み 2 つの階層を組み合わせることで実効メモリが得られます。まず必要な数値は DRAM の総量、つまり高速な Tier 0 メモリです。次に必要な数値は、階層化に割り当てる NVMe デバイス、つまり Tier 1 メモリになる容量です。この 2 つの数値を組み合わせた最終的な数値が実効メモリで、ハイパーバイザーが VM に提供できる総量、すなわち DRAM と NVMe 階層を合計した値です。 合計に追加される NVMe デバイスの量は、1 つのホスト設定である DRAM-to-NVMe 比率で決まり、これはティアサイズの割合として表されます。Amazon EVS の VCF 9.1 では、デフォルトの 1:1 比率 (ティアサイズ 100%) が使用されます。1:1 比率を使用すると、NVMe 階層は DRAM と同じ量を提供します。DRAM が 1 TB のホストで 1:1 比率を使うと、NVMe 階層が 1 TB 追加され、実効メモリは 2 TB になります。これがデフォルト比率で実効メモリを 2 倍にする仕組みです。 以下の表は、ホストあたり 1 TB の DRAM を持つ 4 ホストクラスターの例です。計算をわかりやすくするために丸めた数値を使用しています。実際に環境をサイジングする際は、お使いのインスタンスタイプの実際の DRAM 容量に置き換えてください。 指標 Memory Tiering なし Memory Tiering あり (1:1 比率) DRAM (Tier 0) 4 TB 4 TB NVMe 階層 (Tier 1) 0 TB 4 TB 実効メモリ (Tier 0 + Tier 1) 4 TB 8 TB (DRAM の 2 倍) 表 1: デフォルトの 1:1 比率によるクラスターの実効メモリ (4 ホストクラスターの例) 重要な制約はアクティブメモリ アドレス可能なメモリを 2 倍にしても、適切な分析なしにすべてのワークロードを 2 倍にできるわけではありません。サイジングは、VM が現在使用しているページを示すアクティブメモリの指標に基づいて行います。アクティブメモリを、アイドルメモリを含む消費メモリと混同しないでください。ほとんどのワークロードでは、アクティブメモリは消費メモリの 10% から 30% の範囲に収まります。良好なパフォーマンスを得るには、ワークロードのアクティブメモリを DRAM 階層内に収める必要があります。Broadcom の ガイダンス では、階層化導入前のアクティブメモリが既存の DRAM 容量の 0% から 50% の範囲にあるホストやクラスターを特定し、機能を有効化した後もアクティブメモリを DRAM の約 50% 未満に保つことを推奨しています。 この目安を 4 ホストの例に当てはめてみましょう。階層化導入前のクラスターが消費率 80%、アクティブ率 20% で稼働しており、階層化後に VM 密度を 2 倍にしたとします。消費メモリは 3.2 TB から 6.4 TB に増加しますが、これは 8 TB の実効容量で吸収できます。アクティブメモリは 0.8 TB から 1.6 TB に増加し、これは 4 TB の DRAM 階層の 40% で、50% の目標値内に収まっています。この構成例では、アクティブメモリを DRAM 内に保ったまま、クラスターで VM を 2 倍収容できます。 指標 導入前 (ベースライン) 導入後 (VM 密度 2 倍) 消費メモリ 3.2 TB 6.4 TB アクティブメモリ 0.8 TB 1.6 TB DRAM に対するアクティブメモリの割合 20% 40% (目標値 50% 未満) 表 2: アクティブメモリが DRAM 内に収まる場合の統合の余地 Amazon EVS における vSAN のトレードオフ Amazon EVS では、この追加メモリは無償で得られる容量ではありません。vSAN はデプロイ時にすべてのローカル NVMe を確保するため、Memory Tiering に再割り当てするドライブはすべて vSAN データストアから取り除かれることになります。4 ホストの例では、ホストあたり 1 TB の NVMe をメモリ階層に移動すると、クラスターの vSAN 生容量が 4 TB 減少します。つまり、ストレージ容量とメモリ容量を交換していることになります。 機能を有効化する前に、vSAN に制約がないことを確認する必要があります。回収を予定しているドライブを失っても十分な空き容量とポリシー上の余裕が vSAN データストアにあるか、また完全なデータ退避後もストレージ容量がワークロードと可用性の要件を満たし続けるかを確認してください。クラスターの vSAN 容量にすでに余裕がない場合、ストレージの問題を解決するまでは Memory Tiering が適切な選択ではない可能性があります。ローカルストレージの減少による影響を抑えるために、 Amazon FSx for NetApp ONTAP のような外部ストレージを追加することもできます。 ガイダンス 別の設定を裏付けるアクティブメモリの履歴データがない限り、デフォルトの 1:1 DRAM-to-NVMe 比率を使用してください。NVMe 階層のサイズは DRAM と同等以上にする必要があります。 Memory Tiering が有効な場合はメモリオーバーコミットを使用しないでください。2 つの仕組みは互いに競合し、負荷がかかった際にパフォーマンスを低下させる可能性があります。 ページを NVMe 階層から取得する必要があるため、vMotion や DRS の操作にかかる時間は長くなります。ただし、移行中に稼働中の VM のパフォーマンスへの影響はほとんどありません。 本記事の前半で説明した、放棄する vSAN 容量を、サイジングを行うたびに必ず考慮してください。 Amazon EVS の VCF 9.1 デプロイで Memory Tiering を有効化する Amazon EVS で Memory Tiering を有効化する作業は 2 段階のプロセスです。まず NVMe デバイスを vSAN から回収し、次にクラスター全体に適用する Desired State Configuration のドラフトでメモリ階層を構成します。構成の適用時にホストがメンテナンスモードに入るため、これらの手順は通常無停止で実行できますが、スケジュールされたメンテナンスウィンドウ内で実施することをお勧めします。 前提条件 Amazon EVS (i4i.metal または i7i.metal-24xl) 上で稼働している VCF 9.1 デプロイ クラスターの構成プロファイルを管理する管理者権限 各ホストのメンテナンスウィンドウ中に自動化がワークロードをライブマイグレーションできる、vMotion 対応の VM 回収予定のドライブの完全なデータ退避を吸収できる、十分な vSAN の空き容量 ステップ 1: vSAN から NVMe ドライブを削除する 図 1: vSAN ディスク管理、ホストディスク表示 図 2: 削除する NVMe ディスクの選択 図 3: 完全なデータ退避を選択 図 4: ディスク削除の進行状況 図 5: vSAN 再同期のステータス 図 6: NVMe 削除後のディスクグループ ステップ 2: vSphere Configuration Profiles を有効化して Desired State を作成する 図 7: Configure タブの vSphere Configuration Profiles 図 8: リファレンスホストからの構成の作成 図 9: 事前チェックの結果 ステップ 3: ドラフトを作成して MEMTIER を構成する 図 10: ドラフトエディタの MEMTIER 設定 図 11: NVMe 構成設定 図 12: ホスト固有のデバイス選択 図 13: 構成の概要 ステップ 4 (オプション): ソフトウェアミラーリングを有効化する 冗長性を確保するには、ホストごとにプライマリのミラーとして 2 台目の NVMe デバイスを選択します。ホストごとに同等容量の NVMe デバイスが 2 台必要で、いずれも vSAN から回収したものを使用します。 ステップ 5: 事前チェック、適用、確認 図 14: 変更の適用と修復 図 15: ホストの修復の進行状況 図 16: Memory Tiering の容量を示すクラスターサマリー Amazon EVS の VCF 9.1 デプロイで Memory Tiering を無効化する Memory Tiering を無効化する作業は、有効化の手順を逆に行うものです。Desired State のドラフトで memtier 設定を無効にし、必要に応じて回収した NVMe デバイスを vSAN に戻してストレージ容量を復元します。有効化と同様に、修復中はホストがメンテナンスモードに入る必要がありますが、これらの手順は通常無停止で実行できます。スケジュールされたメンテナンスウィンドウ内で実施することをお勧めします。 ステップ 1: Desired State のドラフトで MEMTIER を無効化する Desired State &gt; Configuration &gt; Draft &gt; Create Draft の順に進みます。MEMTIER を選択し、enable を FALSE に設定します。保存して事前チェックを行い、Apply Changes and Remediate を実行します。ホストは順番に修復されます。 ステップ 2 (オプション): NVMe ドライブを vSAN に戻す ストレージ容量を回復したい場合は、cluster &gt; Configure &gt; vSAN &gt; Disk Management から解放された NVMe デバイスを vSAN のディスクグループに戻し、vSAN のリバランスを実行させます。 ステップ 3: 確認する クラスターの Summary タブで Tier 1 の容量が表示されなくなっていること、ドライブを戻した場合は vSAN の容量が復元されていることを確認します。 まとめ 本記事では、VCF 9.1 における Memory Tiering とは何か、ESX カーネルが自動管理する第 2 のメモリ階層として NVMe を提供する方法、そして Amazon EVS が i4i.metal と i7i.metal-24xl で Memory Tiering をサポートする仕組みを説明しました。デフォルトの 1:1 比率で実効メモリが 2 倍になる一方、アクティブメモリは DRAM 内に収める必要があるというサイジングの計算方法も確認しました。また、Amazon EVS 特有のトレードオフ、つまり vSAN がローカル NVMe を所有しているため、Memory Tiering に割り当てる容量は vSAN から取り除く容量になるという点も見てきました。最後に、vSphere Configuration Profiles と vSAN のディスク管理ワークフローを使用して、Memory Tiering を有効化・無効化する手順を確認しました。 Memory Tiering を使うと、アクティブメモリが DRAM 内に収まり、vSAN データストアが再割り当てされた容量を吸収できるという条件のもとで、インスタンスタイプを変更したりノード数を増やしたりせずに、Amazon EVS クラスターの実効メモリを増やし、ハードウェアとライセンスのコストを削減できます。メモリの両階層と VM のストレージ要件を考慮してサイジングを行い、有効化後はクラスターの Summary タブでアクティブメモリの利用率を確認して、Memory Tiering が環境で効果を発揮しているかを確かめてください。 著者について Ron Wedel Ron Wedel は AWS のシニアソリューションアーキテクトです。20 年以上にわたり仮想化技術に携わり、パートナーやお客様が AWS への次の一歩を踏み出す支援に情熱を注いでいます。AWS ソリューションアーキテクトとして、VMware 環境、ネットワーキング、コンピューティングインフラの最適化を専門としています。これらの技術に関する幅広い知識を基盤に、お客様が AWS 上でモダンなインフラを構築・拡張できるよう支援しています。 Allan Scott Allan Scott は AWS のシニアスペシャリストソリューションアーキテクトで、企業のクラウド変革の取り組みを支援することに情熱を注いでいます。2022 年に AWS に入社以来、Infrastructure Migration and Modernization チームで中心的な役割を担い、22 年間の業界経験を活かして複雑な技術課題の解決に取り組んでいます。AWS ソリューションアーキテクトとして、VMware 環境、ネットワーキング、コンピューティングインフラの最適化を専門としています。これらの技術に関する幅広い知識を基盤に、企業向け移行を支援するアプローチを確立し、複雑な技術課題を乗り越えながら事業変革を推進するクラウドソリューションを実現しています。 James Selwood James Selwood は 19 年間の業界経験を AWS に持ち込み、Infrastructure Migration and Modernization チームでシニアスペシャリストソリューションアーキテクトとして活躍しています。2019 年に AWS に入社以来、VMware、ネットワーキング、コンピューティングインフラに関する知識を活かして、お客様のクラウド変革を支援しています。AWS ソリューションアーキテクトプロフェッショナルとして、AWS サービスを活用したインフラ移行の最適化をお客様に提供することに力を注いでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本ブログは 株式会社JAPANNEXT 様、 クラスメソッド株式会社 、Amazon Web Services Japan 合同会社が三社共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクトの田中里絵です。 AI を活用して日常業務を効率化していきたい、と多くのお客様からお聞きします。一方で、AI ツールを導入するだけではなかなかうまくいかず、これまで馴染んできた業務プロセスと AI ツールをいかに統合させていくのかに悩んでいる、というお声もいただきます。 本記事では、JAPANNEXT 様が Amazon Connect Customer と Amazon Bedrock を活用し、二つの部門で電話対応業務を刷新した事例を紹介します。ツールを導入するだけでなく、現場でどう使われるか、将来の IT 基盤にどう繋げるかを、お客様、パートナー、AWS の三社でワクワクしながら議論して仕組みづくりをしました。ぜひ楽しんでお読みください。 株式会社 JAPANNEXT について JAPANNEXT 様は、千葉県いすみ市に本社を置く液晶ディスプレイ（液晶モニター）メーカーです。2016 年に JAPANNEXT ブランドのモニターを発売し、ブランド 10 周年を迎えられました。大型ディスプレイ、4K ディスプレイ、ゲーミングモニター、モバイルモニターなど多様なラインナップの製品を提供されていて、良いものを最高のコストパフォーマンスで届けるという考え方が製品づくりの軸になっています。年間 150 を超える新製品を発売するスピーディーなビジネスが強みです。 事業拠点は、統合により廃校となったいすみ市の小学校を利活用した本社です。このユニークな本社に加え、いすみ鉄道の菜の花保全活動への協賛や、リファビッシュ品（再生品）をふるさと納税の返礼品として提供する取り組みなど、テクノロジーと地域活性化の両輪で事業を展開されています。 写真：本社エントランス（左）、学校の雰囲気が残る社屋内 – 想いをつないで （中央）、リフレッシュルーム – ON／OFF 両方全力で（右） JAPANNEXT 様が直面していた課題と背景 多様な製品ラインナップを持つ JAPANNEXT 様には、購入前の製品選定のご相談から設置方法、保証や修理まで、多様な問い合わせが寄せられます。従来、1 日あたり平均 80 件の営業問い合わせを、5 名の営業アシスタント様が固定電話を介して受けていました。担当者の不在でお客様をお待たせしたり、適切な担当者へのルーティングに時間がかかったりするため、問い合わせがつながるまでに数分を要していました。また、伝言やチーム内での情報連携は属人的に行われていたため、誰が、いつ、どんな問い合わせを受けているのかをチームとして把握しきれないという課題もありました。 購入後のお問い合わせを受けるカスタマーサポートでも、情報連携に関する課題を抱えていました。エージェントは受電後にお客様対応を行い、内容を記録して CRM に入力しますが、これに 1 件あたり 15 分を要し、記録の粒度も担当者によりまちまちでした。このために問い合わせ内容がデータとして蓄積されづらく、対応の振り返りや傾向の把握が進みづらい状況にありました。重要度の高いお問い合わせをスーパーバイザーに即時連携したい場面でも、通話終了後に記録・共有する業務フローでは 10 分程度のタイムラグが避けられませんでした。 これらの課題を解決するため、既存 PBX システムの更改は 2024 年ごろから検討に挙がっていました。しかしながら、着信時に発信元のお客様情報が CRM の画面に自動で表示される連携機能を日常的に利用しており、次期システムでも同等の体験を実現できるかが重要な要件となり、技術選定を難しくしていました。さらに、既存 CRM の更改も考慮する必要があり、相互に連携するシステムをどう入れ替えていくかの整理も必要な状況でした。 ソリューション選定の経緯 技術選定の中心に据えたのは、2 つの方針です。1 つは、クラウド型のコンタクトセンターを採用し、物理的な電話デバイスから PC 上のソフトウェアを介した受電へ切り替えること。もう 1 つは、対応内容の記録と連携に、AI による文字起こしを活用することです。 この方針のもとで選定したのが、クラウド型のコンタクトセンターサービスである Amazon Connect Customer でした。オンプレミスの PBX 基盤や固定電話を必要とせず、問い合わせを自動でルーティングし効率的に対応を振り分けられること、通話の文字起こしや感情分析といった AI 通話分析機能（Amazon Connect Customer Contact Lens）をフルマネージドで使えること、そして従量課金により低価格でスタートできることが、選定のポイントとなりました。 選定の過程で重要な論点になったのが、課題の段でも触れた CRM との連携です。お客様の中でも議論を重ね、ユーザーからみて従来と同等以上の体験が得られると確認できたことで、最終的には CRM 自体の更改も同時に進めることを決断されました。 AWS パートナーとの協業 Amazon Connect Customer、Amazon Bedrock、新 CRM との導入支援と連携を総合的にお願いできる導入パートナーとして、AWS プレミアティアサービスパートナーであるクラスメソッドとの協業を決定し、AWS サービスの設計とともに CRM 更改も含めたプロジェクト計画を進めていきました。 本プロジェクトの技術リードの大野様は次のように述べています。 「AWS の知見、AI に対する知見、細かな要件のすり合わせに加え、CRM の更改も見据えた支援をしてくれるという点が非常に大きなポイントでした。」 ソリューションの構成 営業支援のユースケースでは、Amazon Bedrock が要約機能を担いました。Amazon Connect Customer の文字起こしと Amazon Bedrock によるカスタマイズされた要約を組み合わせて、AWS Lambda で担当者が日常的に使っているチャットツールへ連携し、イベントドリブンアーキテクチャによって終話後数分で届きます。必須の要件として残ったお客様情報の表示は、CRM から Amazon Connect に定期連携するロジックを追加で作成しました。 この構成の設計を主導したクラスメソッド様は、設計の狙いを次のように語っています。 「本プロジェクトで最も重視したのは、『CRM が変わっても、継続活用できる設計にする』という点でした。Amazon Connect Customer との連携を疎結合に設計することで、CRM に依存しない柔軟な環境を実現しています。 通話要約のモデルは、精度と運用面を総合的に考慮して Claude を提案しました。大野様が日常的に活用され、JAPANNEXT 様の社内指針でも推奨されていたことが重なり、現場に最も馴染みやすい選択になったと感じています。 また、オペレーターの役割と状況を丁寧にヒアリングし、ルーティングプロファイルを部門ごとに分離することを提案しました。営業時間外の対応についても、カレンダー管理や追加手順を共有することで、お客様が自走して運用を続けられる体制を整えました。」 図：営業部門で利用する新システムのアーキテクチャー概要 導入の成果 先行して運用を開始した営業部門では、初日から前向きなフィードバックが得られました。具体的には、次のような効果が生まれています。 1 日の電話対応件数が 15 % 増加 担当者への電話引き継ぎに要していた時間が、自動ルーティング機能によりゼロに 不在着信や業務時間外の着信も可視化され、引き継ぎ漏れがゼロに 1 件あたりの対応時間短縮の結果、担当者の残業時間が 15 % 削減 数字に表れない変化もあります。対応そのものに集中できるようになり、通話しながらの情報検索や応対品質の振り返りも可能になったことで、単なる問い合わせへの受け答えにとどまらず、情報収集や分析など顧客体験を高める取り組みに時間を割く余裕が生まれています。 プロジェクトを推進された大野様は、SE の視点から効果をこう分析されています。 「Amazon Connect Customer を導入してから、記録に追われなくなったことで、電話対応とエスカレーション判断を、担当者がいずれも落ち着いて対応できるようになりました。就業時間に目途が付きやすくなり、働きやすさも向上したとフィードバックを得られています。また、物理的な電話が撤廃されたことで、執務室の静音化という副次効果もありました」 リーダー業務には、問い合わせ対応に加え外部との調整作業がありますが、導入後はこの業務にも変化が生まれました。主運用部門担当の高野様、植村様およびチームリーダー押尾様からは、次のような声が寄せられています。 「電話のピーク対応処理が従来の80件程度から100件／日可能になり、加えて受話できなかった問い合わせもガイドによりメール問い合わせ担当へ振り替わるため、業務量が平準化されました。これにより担当者がリーダーのサポートも出来るようになりました。またチームリーダーは本業務と問い合わせ対応のサポートも並行作業で可能となりました。今までは不可能か、とても難しかったことです。」 また、営業部門での成果を受け、フェーズ 2 としてカスタマーサポート部門への展開を進めました。開発段階から現場担当者を交えてクラスメソッド様と要件定義を重ね、標準的な機能を中心に活用してカスタマイズを最小限にするために、運用側の見直しも含めた機能の選定や社内調整を積み重ねました。 この要件定義に参加したコーチングリーダーの本良様は、その経験を次のように語っています。 「現場の意見を取りまとめ、クラスメソッド様のエンジニアと密に会話を重ねることで、要望がかたちになっていきました。ユーザーとシステム、両方の立場や悩みを経験できたことも大きな収穫です。この仕組みは、カスタマーサポートとシステム部門がワンチームで築き上げたものです。」 写真：プロジェクトにご尽力された高野様（写真左）、本良様（写真右） お客様の声と今後のお取り組み 一連の取り組みについて、伊丹様、剣持様、大野様から、それぞれ次のような声をいただいています。 伊丹様「単に業務効率が向上しただけではなく、問い合わせ内容が漏れなく記録されることで、今後の営業活動の分析やさらなる向上が見込めるようになりました。これから本格化するカスタマーサポートへの展開にも、大いに期待しています。」 剣持様「JAPANNEXT では、毎年 150～200 機種の新商品を発売し、市場に無いものでもチャレンジして製品開発、発売を行っています。それを支える社内システムは自社開発が基本姿勢ですが、クラスメソッド様、Amazon Web Services Japan 様との連携で新しい仕組みをスピーディーに構築することが出来ました。あわせてカスタマーサポートも刷新し、これまで担当者ごとに散在していた顧客との接点が、営業組織全体で共有できる情報基盤になりました。今後はこの基盤を活かし、外部の有識者の知見も取り入れながら、新たな顧客開拓につなげていきます。」 大野様「本共創の立ち上げを経験したことで、JAPANNEXT 社内全体で『新しい考え方がないか？』といったことを考える雰囲気が醸成され始めました。単に効率改善のためだけのプロジェクトに留まらず、仕組みづくりに様々なステークホルダーを交えて取り組めたことが最大の成果でした。」 クラスメソッド様からは、次のようなフィードバックをいただいています。 「単なるツールの入れ替えではなく、業務課題そのものに向き合いながら仕組みを作り上げられた点が良かったと考えております。電話対応の現場で何が起きているかを丁寧にヒアリングし、ツールと業務プロセスを一緒に設計することで、担当者が『記録に追われる仕事』から解放される仕組みが生まれました。今後も JAPANNEXT 様の業務改善に継続的に伴走していきます。」 今後 JAPANNEXT 様は、RMA（返品や交換）の一連の作業を担うチームにも、Amazon Connect Customer の利用を広げていく想定です。また、本プロジェクトで導入された CRM のさらなる活用や、クラウドに蓄積され始めたデータをビジネスに活用を目指して継続的にお取り組みをしていくご想定です。 まとめ 本事例では、業務の目的に立ち返って、機能と運用の両面から設計を重ねたことが、初日から現場に定着する仕組みにつながりました。AI 活用を検討される際は、ツールの選定とあわせて、現場の運用にどう溶け込ませるかの議論に、ぜひ時間をかけてみてください。AWS へのご相談もお待ちしています。 コンタクトセンターの業務刷新や AI 活用に興味を持たれた方は、 Amazon Connect Customer の製品ページ や、 Amazon Bedrock の製品ページ をご覧ください。 株式会社JAPANNEXT : General Manager 伊丹 利政 氏（写真中央左）、Senior System Engineer 大野 浩司 氏（写真中央右）、Head of Sales &amp; Marketing 剣持 開 氏（写真右から2番目） クラスメソッド株式会社 : 営業 平田 梨紗（写真右） Amazon Web Services Japan : アカウントマネージャー 倉知 達哉（写真左）、ソリューションアーキテクト 田中 里絵（写真左から2番目） ソリューションアーキテクト　田中里絵

本ブログは、仰星監査法人様のご協力のもと、株式会社 Sapeet と Amazon Web Services Japan が執筆しました。 はじめに ノーコード・ローコードツールの普及により、多くの企業が迅速に AI アプリケーションを構築できるようになりました。 プロトタイプを素早く形にし、ユーザーの声を得ながら改善を重ねる。この立ち上げ期のスピードは、ノーコードツールならではの大きな価値です。 一方で、プロダクトが成長しチームが拡大するフェーズでは、Git ベースのバージョン管理やコードレビューといったソフトウェア開発のプラクティスを取り入れたいというニーズが高まってきます。 本記事では、ノーコード AI プラットフォーム Dify で立ち上げ、環境分析調査時間を大幅に削減した生成 AI ツールを、プロダクトの成長に合わせて Amazon Bedrock AgentCore と Strands Agents SDK によるコードベースのアーキテクチャへ移行した株式会社 Sapeet の事例をご紹介します。 Dify で築いた約 1 年間の開発資産と設計思想を活かすことで、わずか 2 週間で基盤移行を完了した取り組みです。 株式会社 Sapeet について 株式会社 Sapeet（以下、Sapeet）は、AI 技術を活用したソリューションを提供するテクノロジー企業です。 同社は仰星監査法人様向けに、生成 AI を活用した環境分析ツールを開発・提供しています。 監査業務における環境分析プロセスを AI で効率化し、分析品質の向上と業務負担の軽減を実現するプロダクトです。 本プロダクトの立ち上げ期の取り組みについては、過去記事「 仰星監査法人様の AWS 生成 AI 活用事例：株式会社 Sapeet 様支援のもと、Dify を用いて生成 AI アプリを構築し、機微な情報を扱えるセキュアな環境でクライアント情報の収集・環境分析調査時間の 87% 削減を実現 」で詳しく紹介しています。本記事は、その後のプロダクト成長フェーズにおける進化を描いた続編です。 Dify による立ち上げと、次のフェーズで見えてきた課題 Sapeet はこのツールを、ノーコード AI プラットフォーム Dify と Amazon Bedrock を組み合わせて AWS 上に構築しました。 ワークフローを可視化しながら少人数で素早くプロトタイピングできる Dify の強みを活かして開発を進め、環境分析調査時間の大幅な削減という成果を実現しました。導入後も改善を重ね、約 1 年間にわたってプロダクトを育ててきました。 一方、プロダクトが成長し、チームでの開発とプロダクション運用のフェーズに入るにつれ、新たなニーズが見えてきました。 これらは特定のツール固有の問題というより、プロトタイプから本格運用へ移行する際に多くの開発現場で生じる、フェーズの変化に伴う課題です。 課題 1: チーム開発におけるバージョン管理 チームで開発を進める中で、Git ベースの差分管理やプルリクエストによるコードレビューを取り入れたいというニーズが高まりました。 当時の開発体制では作業者ごとの変更差分の把握が難しく、リグレッションや、意図した変更が反映されないといった事象も発生していました。 課題 2: ワークフローの複雑化への対応 機能追加に伴いワークフローのノードが増え、管理の複雑さが増していきました。 アプリを分割して開発する際の同期や結合にも工夫が必要になり、チームでの分業を支える仕組みづくりが課題となっていました。 課題 3: プロダクトに最適な UX の追求 プロダクトの進化に伴い、チャット形式にとどまらない、業務に最適化した専用 UI を提供したいという要望が強まりました。 また、開発効率をさらに高めるため、途中実行やログ出力を活用したデバッグのしやすさも求められるようになりました。 こうした課題は、Dify の欠点ではなく、プロダクトのフェーズが変わったことによるトレードオフです。 重要なのは、フェーズに応じて最適なツールを見極めることです。Sapeet は、立ち上げ期を支えた Dify の資産を活かしながら、次のフェーズに向けてコードベースへの移行を決断しました。 ソリューション: Amazon Bedrock AgentCore + Strands Agents SDK への移行 選定の決め手: ノード親和性 ― Dify の設計思想をそのまま活かす Amazon Bedrock AgentCore は、AI エージェントのビルド・デプロイ・運用をスケーラブルに実現するフルマネージドプラットフォームです。 サーバーレスランタイム、マネージドメモリ、ツールゲートウェイ等を提供し、フレームワークに依存しない柔軟な構成が可能です。 Strands Agents SDK は、オープンソースの AI エージェント SDK（Python / TypeScript）です。 モデル・ツール・プロンプトの 3 要素でエージェントを構築でき、Amazon Bedrock がデフォルトのモデルプロバイダーとして統合されています。 Sapeet がこの組み合わせを選定した最大の理由は、ノード親和性です。 Dify のブロック繋ぎ型ワークフローと、Strands Agents SDK のノードベース実行は構造的に類似しています。 Dify で 1 つの LLM ノードにプロンプトを書いて入出力を次のノードに繋いでいた構成が、Strands Agents でもほぼそのまま表現できます。 つまり、Dify 上で 1 年間かけて磨き上げてきたワークフローの設計思想が、そのままコードベースへの移行資産になったのです。 また、モデル基盤には立ち上げ期から Amazon Bedrock を利用していたため、今回の移行ではオーケストレーション層とホスティング環境の進化に集中できました。 移行プロセス: 2 週間で基盤移行を完了 移行は 2026 年 4 月に開始しました。 まず 1 ヶ月をかけて技術検証を実施し、その上でメイン実装エンジニア 1 名が集中して開発することで、実質 2 週間で基盤移行を完了し、 結合テストを含めても約 2 ヶ月という短期間で構築を終えました。 この速さを支えたのが、前述のノード親和性です。ゼロからの再設計ではなく、既存ワークフローの「翻訳」に近い形で移行を進められました。 予想外の収穫: Toolkit とエコシステム 移行を進める中で、AgentCore の Toolkit によるデプロイの容易さが予想以上のメリットとなりました。 Dockerfile 不要で動作確認が可能であり、エコシステムの充実により導入・お試しのハードルが低いことも評価されています。 Sapeet の堀ノ内様も「Toolkit を活用することでデプロイが想像以上に簡単になり驚いた」と、エコシステムによる開発者体験の良さを語ります。 CDK L2 Construct による統一管理 インフラ管理には AWS CDK の L2 Construct（aws-cdk-lib/aws-bedrockagentcore、AWS CDK v2.221.0 以降で利用可能）を採用しました。 AgentCore でエージェントをホスティングし、Amazon Elastic Container Service（Amazon ECS）でバックエンドとフロントエンドをホスティングする構成を、単一の CDK プロジェクトから一括でデプロイできるようにしています。 これにより、バージョン管理・コードレビューがインフラを含めて一元化されました。 開発メンバーも「インフラ全体を 1 つの CDK プロジェクトでまとめて管理できるようになったので、構成がシンプルになった。」と、インフラ管理の一元化による開発効率の向上を実感されています。 導入効果 移行により、以下の効果を実現しました。 観点 移行前 移行後 バージョン管理 作業者ごとの変更差分の把握が困難 Git ベースの差分管理・ロールバック可能 コードレビュー レビューフローの確立が困難 PR ベースのレビューフロー確立 UI / UX チャット形式の表示 専用画面での観点別タブ表示（PEST、5 フォース等）に改善 なお、実行時間については、基盤の移行に伴う遅延が懸念されましたが、処理時間の 8 割以上を LLM の推論時間が占めるため、移行前と体感でほぼ同等の水準を維持できています。 さらに、将来的には Amazon S3 + AWS Lambda + AgentCore 構成への最適化による、コスト効率の改善を見込んでいます。 お客様の声 移行後、Sapeet の開発メンバーの方々からは下記のコメントをいただいています。 「コード管理機能やレビューを通して、差分がわかりますし、これまでのソフトウェア開発のベストプラクティスに沿った形でやっていけるようになった」村上 大昌 様（AI Solution 事業部 Senior Project Manager） 「リリースしたいバージョンを確実に選んで反映できるようになった」津守 優 様（AI Solution 事業部 Engineer） 「Strands Agents の Graph 機能を使うことで処理が順番に流れるワークフローを構築でき、Dify 上でのノードを繋げていく形と同じ構成を取りやすかった。AgentCore へのデプロイも簡単で、エコシステムが充実しており導入がしやすい」堀ノ内 司 様（AI Solution 事業部 Engineer） 今後の展望 Sapeet は、移行した生成 AI 環境分析ツールの本番適用を経て、継続的な改善サイクルを回していきます。 2026 年 8 月以降のアップデートを機に、実際の利用者からのフィードバック収集を進めていく予定です。また、環境分析以外にも複数テーマで AI 開発を進めており、その一部は Strands Agents SDK を活用してすでに本番リリースを迎えています。 ノーコードで素早く立ち上げ、成長に合わせてコードベースへ移行するスキームを社内で確立し、他プロジェクトへ横展開していく方針を掲げています。 まとめ 本事例から得られる示唆は以下の通りです。 フェーズに応じたツール選定 — ノーコードは迅速な立ち上げに、コードベースはチーム開発・品質管理のフェーズに強みを発揮する。どちらが優れているかではなく、プロダクトの成長段階に応じた見極めが重要 ノード親和性を活かした段階的移行 — 既存のワークフローと構造的に類似するフレームワークを選ぶことで、これまでの設計資産を活かし、移行コストを最小化できる 開発スピードとガバナンスの両立 — Amazon Bedrock AgentCore + CDK による統一管理で、開発スピードを保ちながらコードレビュー・バージョン管理を実現 エコシステムの活用 — Toolkit やマネージドサービスを活用することで、インフラ構築の負担を最小限に抑えられる ノーコードツールで AI アプリケーションを立ち上げ、プロダクトの成長とともに次のフェーズを迎えつつある方は、Amazon Bedrock AgentCore と Strands Agents SDK によるコードベースへの移行をぜひご検討ください。 実際に手を動かして試したい方には、 Amazon Bedrock AgentCore ワークショップ : 基本から高度なエージェント開発まで &nbsp;をご活用ください。エージェントの構築からデプロイ、運用に必要な観測・評価まで、約 2 時間のハンズオンで体験できます。