概要 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 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

はじめに 前提：エージェントの構成 課題：画面を離れると回答が消える 設計方針：実行の作成と購読を分離する DB スキーマ：残す履歴と実行中の状態を分ける 保存単位は「AG-UI の Message 1 件 = 1 行」 DynamoDB ではなく Aurora MySQL を選んだ理由 会話履歴はサーバーが組み立てる 書き込み設計：イベントは保存せず「生成途中の回答」を上書きする 再合流：会話全体のスナップショットで追いつく 同時実行制御：実行中ロックを NULL 可のユニーク列で作る ロックの解放漏れに備える 停止：切断とキャンセルを区別する Redis は要るか まとめ はじめに 開発本部 開発1部の いくまる です。 私たちのチームでは、Web アプリの新機能として、チャット形式でデータを分析できる AI エージェントを開発中です。開発を進める中で、「回答の生成中に画面を離れると、その回答を受け取れなくなり、会話も残らない」という課題に向き合うことになりました。 本記事では、この課題を解決するために行った「会話履歴の永続化」と「バックグラウンド実行」の設計と実装を紹介します。DB スキーマ・実装コード・検討して捨てた案まで含めて書きます。 前提：エージェントの構成 このエージェントは次の構成で動いています。 ブラウザ（チャット UI） │ AG-UI イベント（SSE） ▼ Next.js（API Route ── ブラウザと AgentCore の中継役） │ InvokeAgentRuntime（SSE） ▼ Amazon Bedrock AgentCore Runtime（Strands Agents 製エージェント） │ MCP ▼ MCP サーバー（自社データの検索・集計ツール群） Amazon Bedrock AgentCore : AI エージェントの実行基盤となる AWS のサービスです。セッションごとに microVM 単位で実行環境が分離されます。 Strands Agents : AWS が公開しているオープンソースの AI エージェント SDK です。 AG-UI : エージェントとフロントエンド間のイベントストリーミングのプロトコルです。 RUN_STARTED ・ TEXT_MESSAGE_CONTENT ・ TOOL_CALL_* ・ RUN_FINISHED などのイベント型を定めています。転送方法は SSE に限定されませんが、このアプリでは SSE で流しています。 ユーザーが質問を送ると、エージェントが MCP ツールでデータを取得・分析し、回答をストリーミングで返します。ツールを繰り返し呼ぶため、1 回の回答に数十秒かかることがあります。 課題：画面を離れると回答が消える AI チャットで広く使われるのは「POST + ストリーミング応答」の構成です。ブラウザが質問を POST し、サーバーが生成イベントを流し、画面に逐次表示します。画面離脱を想定しなければ、これで十分に機能します。私たちの初期実装もこの構成でした。 私たちの場合は回答に数十秒かかるため、「生成中に画面を離れても実行は完走してほしい」という要件が加わりました。この要件を満たそうとすると、3 箇所が問題になります。 改修前の構造。画面遷移した瞬間に、以降のイベントを受け取る手段がなくなる 1 つ目はフロントエンドです。 この構成では、チャット画面の hook が unmount 時に実行を中断（ abortRun() ）する作りになりがちです。画面遷移がそのまま実行中断になります。 // チャット画面の hook（unmount 時に実行を中断する作り） useEffect( () => () => { stopRequestedRef. current = true ; agentRef. current ?.abortRun(); } , [] , ); 2 つ目は中継役の API Route です。 ブラウザと AgentCore の間で SSE を中継する Next.js の API Route は、クライアントの切断を上流の AgentCore への読み取りキャンセルとして伝播します。 ReadableStream の cancel() は「クライアントがもう読まない」ときに呼ばれるコールバックで、そこで上流の読み取りも止めると、切断とキャンセルの区別がなくなります。 // 中継処理（クライアントが切れると上流の読み取りも止まる作り） const readable = new ReadableStream( { async start ( controller ) { // 上流（AgentCore）の SSE を読み、そのままクライアントへ中継する } , cancel () { reader.cancel(); } , } ); 3 つ目は保存先です。 イベントは中継されるだけで、どこにも保存されません。仮に 1 つ目と 2 つ目を直して実行が完走するようにしても、戻ってきた画面に表示するデータがありません。 「実行状態を React のグローバルストアに持てば、画面遷移に耐えられるのでは」という案も検討しました。しかしこのアプリでは、チャット画面から他の画面への遷移が window.location.href によるページ全体の再読み込みで実装されています。再読み込み後のページは JavaScript の実行環境ごと新しく作られるため、React の state やグローバルストアに入れた値は引き継がれません。 設計方針：実行の作成と購読を分離する 大きく変えたのは次の 3 つです。 作成と購読の分離 : POST /runs は実行を開始して 202 { runId } を即座に返します。表示は GET /runs/{runId}/events の SSE で受け取ります。この「SSE を受信し続けること」を、本記事では「購読」と呼びます。購読はいつ切れてもよく、何度でも再開できます。 実行ワーカーの独立 : AgentCore の SSE を最後まで読み切って記録する処理（実行ワーカー）を、HTTP レスポンスから独立した非同期タスクにしました。ブラウザが切断しても実行は完走します。 二層の保存 : 実行中は「生成途中の回答」を DB に上書き保存し続け、完了したら完成したメッセージを DB の履歴テーブルに保存します。テーブル構成は次の節で説明します。 なお、実行ワーカーは Next.js と同じプロセス内で動かしているため、リクエストごとに実行環境が終了するサーバーレス環境ではこの形は取れません。現在は検証段階のためこの構成にしていますが、Next.js のデプロイに走行中の実行が巻き込まれないようにするため、本来は実行ワーカーを独立したプロセスに切り出す方が望ましいと考えています。現状、プロセスがデプロイなどで止まる場合の後始末は、同時実行制御の節で説明する回収の仕組みが担います。 改修後の構造。実行は接続と無関係に完走し、購読は何度でも再入場できる ブラウザとサーバーの間の API は次の 5 本です。 API 役割 POST /runs 実行を作成して 202 { runId, conversationId } を即返す GET /runs/{id}/events SSE 購読。切断・再入場が自由 POST /runs/{id}/cancel 明示的なキャンセル GET /conversations 会話一覧（履歴サイドバー用） GET /conversations/{id} 会話の全メッセージ + 実行中の run（あれば） 最後の API がポイントです。リロードや別タブで会話を開いた直後、クライアントは会話 ID しか知らず、実行中の run があるかどうかも分かりません。そこで GET /conversations/{id} は、会話のメッセージに加えて「実行中の run の ID」を返します。クライアントはその ID で GET /runs/{id}/events を購読し、生成途中から表示を再開します。 DB スキーマ：残す履歴と実行中の状態を分ける このアプリでは以前から、本体機能のデータを Aurora MySQL 8.0 + Prisma で管理しています。エージェントの履歴も同じ DB に、3 つのテーブルで持つことにしました。ずっと残す「履歴」と、実行中だけ使う「実行状態」でテーブルを分けています。 区分 テーブル 役割 行の扱い 履歴 conversations 会話スレッド 1 件のメタ情報 ずっと残す 履歴 conversation_messages メッセージ 1 件 = 1 行。完成した発話を保存 ずっと残す 実行状態 runs 実行 1 回の状態 + 生成途中の回答 + ロック 行は実行 1 回ごとに増え、終了後も記録として残る。生成途中の回答やロックは実行中だけ使う ER 図 Prisma スキーマは次の通りです。実際に採用したものから、タイムスタンプ列・リレーション定義・enum 定義（RunStatus / MessageStatus）を省いています。 model Conversation { id String @id @default(cuid()) companyId Int @map("company_id") userId String @map("user_id") threadId String @map("thread_id") @db.Char(36) title String @db.VarChar(255) deletedAt DateTime? @map("deleted_at") @@unique([companyId, userId, threadId]) @@map("conversations") } model ConversationMessage { id String @id @default(cuid()) conversationId String @map("conversation_id") runId String? @map("run_id") sequence Int role String @db.VarChar(16) parts Json status MessageStatus @default(complete) @@unique([conversationId, sequence]) @@map("conversation_messages") } model Run { id String @id @default(cuid()) conversationId String @map("conversation_id") clientTurnId String @map("client_turn_id") @db.VarChar(64) status RunStatus @default(queued) lockKey String? @unique @map("lock_key") ownerInstanceId String? @map("owner_instance_id") @db.VarChar(64) errorCode String? @map("error_code") @db.VarChar(64) partialState Json? @map("partial_state") heartbeatAt DateTime @default(now()) @map("heartbeat_at") @@unique([conversationId, clientTurnId]) @@index([status, heartbeatAt]) @@map("runs") } lockKey の UNIQUE、 clientTurnId の複合ユニーク、 [status, heartbeatAt] のインデックスがそれぞれ何のためにあるかは、後の節で順に説明します。 また、本記事には 4 種類の ID が登場します。ここで整理しておきます。 ID 何を指すか conversationId DB 上の会話。API で会話を指すときに使う threadId AG-UI 上の会話 ID。DB 上の会話（ conversationId ）と 1 対 1 で対応 runId 質問 1 回ぶんの実行 runtimeSessionId AgentCore の実行環境を束ねる ID。 t{companyId}-u{userId}-{threadId} の形式で、会話ごとに固定 保存単位は「AG-UI の Message 1 件 = 1 行」 conversation_messages は追記専用で、AG-UI の Message をそのまま parts （JSON）に格納します。テキストだけのターンは user / assistant の 2 行、ツールを使うターンは assistant（ツール呼び出し）と tool（結果）の行が挟まって 4 行以上になります。 1 会話のメッセージ行の例。ツールを使うターンは user・assistant（ツール呼び出し）・tool・assistant の 4 行、使わないターンは 2 行になる この保存単位を選んだ理由は、フロントの表示ロジックの作りにあります。ライブ表示は「AG-UI の Message 配列を受け取り、ターンの区切りやツールの実行ステップ表示を組み立てる純粋関数」として自前で実装しています。保存した Message 列をそのままこの関数に渡せば、画面を離れなかった場合と同一の表示が再現されます。保存時に表示用の形へ加工してしまうと、同じ表示を再現できなくなります。 DynamoDB ではなく Aurora MySQL を選んだ理由 会話履歴のアクセスパターン（会話 ID + 連番で順に全件取得、追記専用、JSON 主体）は DynamoDB の得意領域で、実際に移行案も検討しました。それでも Aurora MySQL 一本にしています。 まず、トランザクション要件が構成の選択肢を絞ります。質問の受付時には「会話 + user メッセージ + 実行（ロック）の INSERT」を、完了時には「assistant メッセージの INSERT + 実行の完了 + ロック解放」を、それぞれ単一トランザクションで行う必要があります。「履歴は DynamoDB、実行状態は Aurora」のように 2 つのストアに分けると、この原子性を保証できません。原子性が無いと、たとえば次のような壊れ方をします。 回答は残ったのに次の質問ができない : 完了処理の「回答を保存」と「ロック解放」の間でプロセスが落ちると、画面には回答が出ているのに DB はロックを握ったままになり、次の質問が「実行中です」と拒否され続けます。 答えのない質問が履歴に残る : 送信の二度押しで 2 本目が「質問を保存 → ロックで弾かれる」の順に進むと、誰も回答しない質問だけが履歴に残ります。1 トランザクションならロック取得の失敗と同時に質問の保存も取り消され、エラー応答だけを返せます。 したがって選択肢は「全部 Aurora」か「全部 DynamoDB」に絞られます。後者も技術的には成立します（DynamoDB でも TransactWriteItems で複数の項目をまとめて原子的に書けます）。 それでも Aurora にしたのは、既存の運用との一貫性のためです。このアプリの他のデータはすべて Aurora + Prisma で管理していて、マイグレーションの手順やレビューの観点といったチームの運用もそこで揃っています。データストアを 2 つにすると、この運用も 2 系統になります。規模の面でも、DB への書き込みはピークでも毎秒数十回の見積もりで、Aurora で十分に受けられます。DynamoDB のスケール性能が必要になる水準ではありません。 会話履歴はサーバーが組み立てる エージェントは毎回の呼び出しで会話の全履歴を受け取り、状態をゼロから組み立て直す作りにしています。この全履歴を誰が用意するかには 2 つの形があります。クライアントが手元の Message 配列を毎回送るか、 サーバーが DB から組み立てる かです。私たちは後者にしました。クライアントが送るのは新しいメッセージ 1 件だけです。 前者を避けた理由は、バックグラウンド実行と相性が悪いからです。実行を放置して別のタブで完走させると、元のタブが持っている履歴は古いままになります。その古いタブから次の質問を履歴ごと送ると、完走したはずの回答がモデルへの入力から抜け落ち、会話のつじつまが合わなくなります。後述するロックは実行中しか効かないため、この事故は防げません。最新の会話を常に持っているのは DB だけです。 なお、AgentCore 側に会話の状態を持たせる案も 2 つ検討し、見送りました。 実行環境（microVM）のメモリに持つ : セッション ID は会話ごとに固定なので、同じ会話の呼び出しは同じ実行環境に届き、メモリに状態を残すこと自体はできます。ただしこの環境は無操作 15 分（デフォルト）などで終了し、メモリごと消えます。時間を空けて続く会話の置き場にはできません Memory サービスに持つ : AgentCore には会話を保存する Memory というサービスもあります。ただし履歴はどのみち表示のために自前の DB へ保存するので、足すと同じ役割の保存先が 2 つになります POST /runs のボディは { conversationId, message, clientTurnId } だけです。モデルへ渡す履歴は、実行ワーカーが Aurora から組み立てます。 // 実行ワーカーの一部：DB から会話履歴を読み出し、モデル入力用に整える export async function buildModelMessages ( conversationId : string ): Promise < ModelMessagesResult > { const rows = await prisma.conversationMessage.findMany( { where : { conversationId , status : "complete" } , orderBy : { sequence : "asc" } , select : { parts : true } , } ); return normalizeHistory(rows); } // 実行ワーカーの一部：組み立てた履歴をエージェントに渡して生成を開始する const history = await buildModelMessages(claimed.conversationId); const { companyId , userId , threadId } = claimed.conversation; const agent = new AgentCoreAgent( { threadId , initialMessages : history .messages, agentArn , runtimeUserId : `c ${ companyId } :u ${ userId } ` , runtimeSessionId : `t ${ companyId } -u ${ userId } - ${ threadId } ` , } ); こうすると、会話の内容はサーバー（DB）だけが持つ構造になります。AgentCore の microVM がタイムアウトで終了しても、クライアントがリロードで状態を失っても、会話は Aurora から再構成できます。 書き込み設計：イベントは保存せず「生成途中の回答」を上書きする 1 回の回答で AG-UI イベントは数十〜数百個流れます。本文の断片（デルタ）1 つ 1 つやツール呼び出しがそれぞれイベントになるため、回答が長いほど増えます。これを 1 行ずつ INSERT すると、1 回答ごとに大量の行が永久に積み上がります。採用したのは次の形です。 時点 DB 操作 内容 質問送信 INSERT conversations に会話（新規会話のときのみ）、 conversation_messages に質問、 runs に実行レコード（ロック取得を兼ねる）の最大 3 行 生成中 runs.partial_state を上書き UPDATE AG-UI のイベントでは本文が細切れ（デルタ）で届く。実行ワーカーはそれをつなぎ合わせた「その時点のメッセージ配列」を保持しており、これを数秒ごとに同じ 1 行へ上書き保存。行は増えない 完了 conversation_messages に INSERT そのターンで生まれたメッセージ（回答、ツールを使った場合はその呼び出しと結果も）を保存。 runs.partial_state を空にし、ロックを解放 質問送信時のトランザクションは以下のようになっています。ロック（ lockKey ）の取得と質問の保存が、同時に成立するか同時に失敗するかのどちらかになります。 // API Route の一部：質問受付時の書き込み return prisma.$transaction( async ( tx ) => { const conversationId = existingId ?? ( await tx.conversation.create( { /* 省略 */ } )).id; // ロック取得に失敗したら、下で保存する質問ごと取り消される（同一トランザクションのため） const run = await tx.run.create( { data : { conversationId , clientTurnId , lockKey : conversationId } , select : { id : true } , } ); // aggregate（集計クエリ）で会話内の最大 sequence を取り、次の連番を振る const highest = await tx.conversationMessage.aggregate( { where : { conversationId } , _max : { sequence : true } , } ); await tx.conversationMessage.create( { data : { conversationId , runId : run. id , sequence : (highest._max.sequence ?? 0 ) + 1 , role : "user" , parts : { id : randomUUID(), role : "user" , content : message } , } , select : { id : true } , } ); return { runId : run. id , conversationId } ; } ); 生成中の partial_state は 3 秒間隔で間引いて書きます。間引きに加えて「前の UPDATE が完了するまで、次の UPDATE を発行しない」という制御も入れています。UPDATE を発行した順と DB に反映される順は一致するとは限らないため、古い内容の UPDATE が新しい内容の後に適用されると、保存済みの「生成途中の回答」が巻き戻ってしまうからです。 // 実行ワーカーの一部：生成途中の回答を数秒ごとに DB へ上書き保存する const PARTIAL_STATE_INTERVAL_MS = 3_000 ; return { schedule() { // 前の書き込みが完了するまで次をスケジュールしない（古い内容への巻き戻りを防ぐ） if (timer || writing || truncated) return ; timer = setTimeout (() => { timer = null ; writing = true ; void writePartialState(runId, ownerInstanceId, produced()) . then (( state ) => { truncated = state.truncated; } ) . catch (( error : unknown ) => console .error( "partial_state の更新に失敗しました" , { runId , error } ), ) . finally (() => { writing = false ; } ); } , PARTIAL_STATE_INTERVAL_MS); } , } ; 数秒おきに UPDATE を発行し続けて DB の負荷は大丈夫なのか、という点は検討しました。結論としては、同時に走る生成が多くても数十本という規模では問題になりません。更新は各実行が自分の 1 行だけを主キー指定で行い、実行間のロック競合はありません。さらに、接続中のユーザーの画面へは実行ワーカーがメモリ上のイベントを直接流すため、 partial_state の用途は後述する再合流だけです。毎秒書く必要も、イベントを 1 個ずつ書く必要もありません。 完了時は「回答の確定保存」「実行ステータスの完了への更新」「ロック解放」「生成途中の回答（ partial_state ）の削除」を 1 トランザクションで行います。 // 実行ワーカーの一部：完了時の書き込み。lock_key を外し損ねるとその会話が永久に 409 になる return prisma.$transaction( async ( tx ) => { const claimed = await tx.run.updateMany( { where : terminableWhere(runId, ownerInstanceId), data : { status , errorCode , finishedAt : new Date (), lockKey : null , partialState : Prisma.DbNull, } , } ); // 別の経路（キャンセルや、後述する異常終了時の回収処理）が先にこの実行を // 終わらせていたら、生成物は保存しない if (claimed. count === 0 ) return false ; await tx.conversationMessage.createMany( { data : messages. map (( message , index ) => ( { conversationId : targetId, runId , sequence : base + index + 1 , role : message.role, parts : message as Prisma.InputJsonValue , status : messageStatusAt( status , message. id , openMessageIds), } )), } ); return true ; } ); メッセージの status は通常 complete で保存します。キャンセルやエラーで実行が正常に終わらなかった場合は、そこまでに生成できていた分を partial（部分的、の意味）として保存し、画面に残せるようにしています。 再合流：会話全体のスナップショットで追いつく 実行中の会話に購読者が入ってくると、サーバーはまず RUN_STARTED （「実行が進行中です」の合図）と MESSAGES_SNAPSHOT を送ります。どちらも上流から届いたイベントの中継ではなく、この購読のためにサーバーが新しく作って送るものです。 MESSAGES_SNAPSHOT を受け取ったクライアントは、手元のメッセージ一覧を捨てて、スナップショットの内容で丸ごと置き換えます。そのため、スナップショットに生成途中の 1 件だけを入れると、過去のメッセージが画面からすべて消えてしまいます。必ず会話の全メッセージを入れて送ります。 その後の配信は 2 つのモードに分かれます。分かれ目は「購読がいつ始まったか」です。 モード いつ使われるか 配信内容 live 質問の送信直後から購読している場合（生成イベントがまだ 1 件も流れていないうちに購読が始まったとき） 実行ワーカーが受け取る生成イベント（ TEXT_MESSAGE_CONTENT など）を、メモリからそのまま逐次中継 poll それ以外すべて（リロード・別タブ・離脱して戻ってきた場合） 1 秒間隔で DB を読み、確定済み履歴と partial_state の生成途中回答をマージした会話全体の MESSAGES_SNAPSHOT を、内容が変わったときだけ送り直す。実行が終わったら RUN_FINISHED （または RUN_ERROR ）で締める つまり、途中から戻ってきた購読者が受け取るのは live 配信のイベント列ではなく、「会話全体のスナップショットの送り直し」です。 // 配信モードの選択。イベントが 1 件でも流れた後に始まった購読は poll に回す export function attach ( runId : string , signal : AbortSignal ): LiveSubscription | null { const fanout = fanouts. get (runId); if (!fanout) return pollInstead(runId, "fanout_absent" ); if (fanout. closed ) return pollInstead(runId, "fanout_closed" ); // 1 件でも中継済みなら列の途中からになるので、履歴を出せる poll に任せる if (fanout.relayed > 0 ) return pollInstead(runId, "already_relayed" ); // 省略（購読者を登録し、生成イベントを流す AsyncGenerator を返す） } // poll 配信のループ。会話全体のスナップショットを、内容が変わったときだけ送り直す while ( true ) { const event = snapshot(stored, readPartialMessages(progress.partialState)); const serialized = JSON . stringify (event); if (serialized !== previous) { previous = serialized; yield event; } if (isTerminal(progress. status )) break ; await sleep(POLL_INTERVAL_MS, signal); progress = await readProgress(run. id ); if (isTerminal(progress. status )) stored = await loadConversationMessages(run.conversationId); } yield terminalEvent(run, progress); 途中合流の購読者を live のイベント列に合流させず poll に回すのは、正しさを優先したためです。デルタの続きから流すには、「スナップショットに含めた分」と「これから流すデルタ」の境界を厳密に合わせる必要があります。境界がずれると、 content += delta の積み上げで本文が二重に連結されます。会話全体のスナップショットを送り直す形なら、毎回が丸ごとの置き換えなので、この事故が原理的に起きません。その代わり、poll 配信の画面は live 配信のようなストリーミング表示にはならず、数秒おきに文章がまとまって進む表示になります。途中合流でもストリーミング表示にすることは、後続の課題にしています。 同時実行制御：実行中ロックを NULL 可のユニーク列で作る 「同一会話に実行中の run は 1 本だけ」を DB で強制します。PostgreSQL なら 部分インデックス （partial index。 CREATE UNIQUE INDEX ... WHERE status IN ('queued','running') のように、条件を満たす行だけへ一意制約をかけられます）で書けますが、MySQL 8.0 には相当する構文が用意されていません。 代わりに runs.lock_key （NULL 可・UNIQUE）を使いました。実行中は lock_key = conversationId 、終了時に NULL へ戻します。MySQL のユニークインデックスは NULL を重複として扱わない ため、終了済みの run は何本でも共存でき、実行中は会話ごとに 1 本に絞られます。 同一会話への 2 本目の POST /runs は、INSERT 時にユニーク制約違反のエラーとして原子的に弾かれます。重複には 2 種類あります。1 つは「同じ送信の二度押し」です。クライアントは送信 1 回ごとに ID（ client_turn_id ）を発行し、リトライでも同じ ID を送るため、この列の重複で検出できます。送信ボタンの連打はフロントでも抑止できますが、ネットワーク不調時の自動再送などフロントの制御では防げない経路が残るため、DB でも守ります。もう 1 つは「別の質問の並行送信」（ lock_key の重複）で、同じ会話を複数のタブで開いているときに起きます。どちらだったかを引き直して、応答を分岐します。 // API Route の一部：重複キーエラーの解釈 } catch (error) { if (!isUniqueViolation(error)) throw error; // 二度押しなら、先行の run をそのまま返す（同じ送信は 1 回として扱う） const raced = await findRunByClientTurnId(params); if (raced) return { ok : true , runId : raced. id , conversationId : raced.conversationId } ; // 並行送信なら、実行中の run を添えて拒否へ const activeRunId = await findActiveRunIn(conversationId); if (activeRunId) return { ok : false , reason : "active_run" , activeRunId } ; } // API Route の一部：並行送信への応答 if (result.reason === "active_run" ) { return Response .json( { errors : "この会話はいま実行中です" , activeRunId : result.activeRunId } , { status : 409 } , ); } 409 のレスポンスに activeRunId を含めているのは、UI がそれを使って「拒否」ではなく「実行中の run への購読切り替え」に変換できるようにするためです。 ロックの解放漏れに備える ロックには解放漏れへの備えも必要です。サーバーのプロセスが突然落ちると、running のままロックを握った run が残ります。そうなると、誰も実行していないのにその会話への質問が「実行中です」と拒否され続けます。備えは 2 つの仕組みの組み合わせです。 実行ワーカーは、実行中の run の heartbeat_at を定期的に現在時刻へ更新します（処理が続いていることの記録です） それとは別の掃除処理が、 heartbeat_at の更新が一定時間止まっている queued / running の run を「担当プロセスが異常終了した」とみなして failed にし、ロックを解放します。 heartbeat_at は INSERT 時に現在時刻が入るため、202 を返した直後・実行が始まる前にプロセスが落ちて queued のまま残った run も、この経路で回収されます（スキーマの @@index([status, heartbeatAt]) はこの検索用です） 「サーバー起動時に、残っている running を全部 failed にする」というより単純な方法は採れませんでした。デプロイ中は新旧のサーバーがしばらく同時に動いており、旧サーバーがまだ実行している最中の run を、新サーバーの起動処理が誤って failed にしてしまうためです。run に owner_instance_id （どのサーバーがその実行を担当しているか）を持たせているのも同じ理由です。掃除処理は、自分のサーバーがいま実行している run を誤って回収しないよう、この ID とメモリ上の実行一覧を突き合わせて判定します。 この回収の仕組みは、デプロイやスケールインでプロセスごと止められた場合の後始末も兼ねています。止まったプロセスが抱えていた実行は途中から再開できませんが、heartbeat が途絶えるため数分以内に failed になり、そこまでの生成分は partial として履歴に残り、会話のロックも解放されます。ユーザーは失敗を確認して、すぐ次の質問に進めます。 停止：切断とキャンセルを区別する この設計では、タブを閉じる・画面を遷移するのは「切断」であり、実行は継続します。明示的に止めたいときは POST /runs/{id}/cancel を呼びます。実行ワーカーにキャンセル要求の印を立てて上流への購読を切り離し、実行を「キャンセル」として記録します。記録後に遅れて届いた生成物は、前述の完了時トランザクションの「別の経路が先に終わらせていたら保存しない」分岐で破棄されます。 // API Route の一部：キャンセル処理 if (getActiveRun(runId) || run.ownerInstanceId === OWNER_INSTANCE_ID) { // 終了の記録は実行ワーカーに任せる。ここで書くと、ワーカーが「先に終了済み」と判定して生成物を捨てる const active = registerRun(runId); active.cancelRequested = true ; await active.agent?.detachActiveRun(); return { ok : true } ; } // 別のサーバーが担当している run。会話のロックを解放するために記録だけ書く await finalizeRun( { runId , status : "cancelled" , finalizedBy : `cancel: ${ OWNER_INSTANCE_ID } ` } ); 実行中の会話への追加送信は、前述のロックにより 409 で拒否されます。ただし 409 を返すだけだと、「戻ってきたら画面が止まって見える → もう一度送る → エラー」という流れになりやすいため、途中経過の可視化（再合流）を初回リリースの範囲に含めています。実行中であることが見えていれば追加送信は起きにくく、方向を変えたい場合も「停止してから送る」導線に誘導できます。 Redis は要るか 同種の設計では、実行中イベントの共有に Redis（Redis Streams）を使う構成がよく知られています。ただし Redis が必要になるのは「タスクを 2 つ以上に増やし、かつストリーミング表示を保ちたい」場合です。今回はどちらにも当てはまらないため、入れていません。 現在は ECS 1 タスクで動かしており、通常時は再接続のリクエストが実行ワーカーと同じプロセスに届きます。イベントはプロセス内のメモリで手渡せるため、Redis なしで live 配信が成立します。 タスクを 2 つ以上に増やすと、購読のリクエストが実行ワーカーのいない方のタスクへ届くことがあります。live 配信はワーカーと同じプロセスのメモリを介して成り立っているため、別のタスクに届いた購読では使えません。ただし DB はどのタスクからも読めるので、poll 配信はそのまま動きます。つまり live 配信できたはずの購読が poll 配信になり、ストリーミング表示が数秒おきの更新になるだけで、履歴も途中経過も見られます。設計方針の節で触れた「実行ワーカーを独立したプロセスに切り出す」場合も、ワーカーと購読者が必ず別プロセスになるため、同じく中継が必要になります。当面は 1 タスクで足りる規模のため、現時点ではこの構成にしています。 まとめ 実行の作成と購読を分離し、実行ワーカーを HTTP 接続から独立させることで、画面を離れても実行が完走する構造にしました。 履歴は「メッセージ 1 件 = 1 行」でずっと残し、生成途中の回答は上書き更新の 1 行に分けました。イベントの逐次保存はせず、モデルへ渡す履歴もサーバーが DB から組み立てます。 同時実行制御は MySQL の「NULL 可ユニーク列」によるロックで実現しました。キャンセルは購読の切り離しと、実行を「キャンセル」として記録することで実現し、切断とは明確に区別しています。 AI チャットの「履歴」と「バックグラウンド実行」は別々の機能に見えますが、作ってみると、どちらも「会話の状態はサーバー側で持つ」という同じ設計に行き着きました。AI チャットの実行基盤を作る際に共通して現れる論点だと思うので、同じものを作る方の参考になれば幸いです。

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、および  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 インスタンス ) を将来の日付のために予約し、必要な期間のみ予約します。 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 倍のキャッシュ、コア間のレイテンシーを最大  33%  低減するという特徴を備えているため、大規模で継続的かつ高スループットの 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 原文は こちら です。