みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします！ 10 月も後半に入り、朝晩はすっかり肌寒くなってきましたね。年末が近づくこの時期、「今年のうちに AWS 認定を取っておきたい」と考えている方も多いのではないでしょうか。 そんな方に向けて、Pearson VUE で Pearson Global Retake というキャンペーンが実施されています。対象の試験に不合格だった場合に、同じ試験を 1 回無料で再受験できるもので、AWS 認定も対象に含まれています。初回の受験は 11 月 17 日までに済ませる必要があり、無料の再受験は年明けの 2027 年 1 月 4 日から 4 月 7 日の間に受けます。利用には事前の申し込み (オプトイン) が必要で、対象外の試験もあるので、予約の前に条件を確認しておいてください。「もし落ちても次がある」と思えると、受験の一歩目が踏み出しやすくなりますね。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月12日週の主要なアップデート 10/12(月) Amazon OpenSearch Service がインデックスレベル暗号化をサポート Amazon OpenSearch Service で、インデックスごとに異なる AWS KMS カスタマーマネージドキーを使った保存時暗号化ができるようになりました。従来はドメイン全体で 1 つの KMS キーしか使えませんでしたが、本機能により同一ドメイン上でデータの所有者や機密性に応じてキーを分離できます。マルチテナントアプリケーションでテナントごとに専用キーで暗号化する、といった構成が 1 ドメインで組めます。OpenSearch 3.3 以降を実行する新規ドメインが対象で、東京リージョンを含む 14 リージョンで利用できます。機能自体の追加料金はなく、標準の AWS KMS と OpenSearch Service の料金で利用できます。 Amazon Bedrock AgentCore の短期メモリで取り込み・取得・ストレージのデータ量に基づく従量課金制を導入 Amazon Bedrock AgentCore Memory の短期メモリ (STM) の料金体系が、従来のイベント件数ベースの定額制 (0.25 USD/1,000 イベント) から、データ量に基づく従量課金制に変わりました。新料金は ingestion (書き込み) 1.00 USD/GB、retrieval (取得) 0.20 USD/GB、storage (保存) 0.10 USD/GB-月の 3 つのディメンションで構成されます。ingestion と retrieval は 1 イベントあたり最小 12 KB、最大 64 KB として課金され、storage は各イベントの実サイズで課金されます。小さなイベントを頻繁に書き込む会話型エージェントでは、月額コストが従来よりも抑えられるケースがあります。長期メモリ (LTM) の料金は変更ありません。AgentCore Memory が提供されるすべてのリージョンで適用されます。 AWS Lambda が Lambda Web Functions を発表 AWS Lambda に新しいコンピュート形態である Lambda Web Functions が追加されました。コードがポートをリッスンして HTTP リクエストを直接処理するモデルで、Express、Fastify、Hono などの Node.js フレームワークをアダプターなしでそのままデプロイできます (Next.js は standalone モードで、ホストとポートを指定する小さなエントリーファイルを追加すれば動作します)。1 つの実行環境が最大 128 の同時リクエストを処理し、課金はリクエスト数、アクティブ CPU 時間、実行環境のメモリ保持時間の組み合わせになります。DB や外部 API の応答を待つ時間には CPU 課金が発生しません。バージニア北部、オハイオ、オレゴン、東京、アイルランドの 5 リージョンで利用できます。 Amazon CloudFront が AWS Lambda Web Functions のオリジンサポートを開始 Amazon CloudFront のオリジンとして AWS Lambda Web Functions を直接指定できるようになりました。CloudFront を前段に置くことで、エッジでの TLS 終端、キャッシュ、ACM 証明書によるカスタムドメインを、アプリケーションコードの変更なしで利用できます。Origin Access Control (OAC) を設定すると、CloudFront 経由以外のアクセスを IAM 認証で拒否でき、CloudFront のエッジネットワークによるネットワーク層 DDoS 対策と AWS WAF によるアプリケーション層の保護を組み合わせられます。OAC は専用の署名動作により視聴者の Authorization ヘッダーをそのままオリジンへ渡すため、JWT や Cookie などアプリ独自のサインインフローは変更不要です。追加料金はなく、CloudFront 中国リージョンを除く全リージョンで利用できます。 10/13(火) Agent Toolkit for AWS でコーディングエージェントが SageMaker AI の高度な専門知識を活用可能に AWS AI/ML skill が Agent Toolkit for AWS のコアスキルとして提供されました。Kiro、Claude Code、Codex、Cursor などのコーディングエージェントが、モデルの選定、トレーニング、最適化、デプロイといった Amazon SageMaker AI の操作を自然言語ワークフローで実行できるようになります。従来 AWS Labs (awslabs/agent-plugins) で提供されていた skills とプラグインは Agent Toolkit for AWS に一本化され、今後はこちらが唯一のサポート対象の統合ポイントになります。skill は SageMaker Studio JupyterLab にプリインストールされており、追加料金なしで利用できます (エージェントが使用する AWS リソースの料金のみ発生します)。 Amazon SageMaker Studio がソーシャルサインインに対応し、新規 AI/ML 開発者の利用開始を簡素化 Amazon SageMaker Studio が、Google、GitHub、Apple の既存アカウントによるサインアップに対応しました。新規顧客は従来の AWS アカウント作成、コンソール操作、IAM 設定を行わずに、また多くの場合クレジットカード登録もなしで、設定済みの Studio 環境で基盤モデルのファインチューニング、評価、デプロイを開始できます。AWS 無料利用枠の無料クレジット (登録時に 100 USD、追加で最大 100 USD) が付与され、検証済み顧客は G5、G6、G6e、G4dn インスタンスへのデフォルト GPU アクセスをクォータ申請なしで利用できます。チームメンバーをメールで招待でき、招待された側も自分のメールアドレスでサインインして共有環境にアクセスできます。本機能は SageMaker Studio がサポートされるすべての AWS 商用リージョンで利用できます。 AWS Lambda durable functions が durable operation 数とチェックポイントペイロードの上限を引き上げ AWS Lambda durable functions の実行あたりの durable operation 数の上限が 3,000 から 30,000 に、チェックポイントペイロードサイズの上限が 256 KB から 1 MB に引き上げられました。operation 数の増加により、反復ループの拡大、長期間のポーリング、ステップ失敗時のロールバック処理など、1 回の実行でより多くの処理を行えます。1 MB のチェックポイントは Lambda 非同期呼び出し、Amazon SQS、Amazon EventBridge の最大ペイロードサイズと一致するため、これらのイベントソースから受け取ったイベント全体を 1 回の operation で永続化できます。新しい上限は durable functions が利用可能なすべてのリージョンに適用されます。 10/14(水) AWS Security Hub が優先順位付けのためのリソース重要度をサポート AWS Security Hub のエクスポージャー優先順位付けに、リソース重要度 (resource criticality) が追加されました。自動化ルールで「特定アカウントの全コンピュートリソースを Very High にする」といった明示的な設定ができるほか、設定なしでもタグとリソース名から重要度を自動推論します。重要度は Resources ページの列およびエクスポージャー検出の Impact assessment タブに表示され、ソート、フィルター、グループ化に使えます。Security Hub Essentials に追加料金なしで含まれ、全ユーザーに対して常時有効のため、有効化作業は不要です。Security Hub が利用可能なすべての AWS リージョンで利用できます。 AWS Lambda の再帰ループ検出が Amazon EventBridge カスタムイベントバスに対応 AWS Lambda の再帰ループ検出機能が、Amazon EventBridge カスタムイベントバスを経由する再帰ループの検出と自動停止に対応しました。Lambda Event Function がカスタムイベントバスにイベントを書き戻し、それが同じ関数を再度起動する構成で、同一イベントチェーンの呼び出しが約 16 回に達すると Lambda が後続の呼び出しを停止します。この機能はすべてのアカウントでデフォルトで有効であり、設定変更や追加料金は不要です。意図的に再帰を使う設計の場合は、PutFunctionRecursionConfig API で関数単位の無効化が可能です。EventBridge カスタムイベントバスが利用可能なすべての AWS 商用リージョンで利用できます。 10/15(木) AWS Resilience Hub の検出結果とテスト結果を AWS DevOps Agent でレビュー可能に 次世代 AWS Resilience Hub が AWS DevOps Agent と統合されました。レジリエンステストを実行すると DevOps Agent による調査が開始され、症状、根本原因、影響、観測された復旧アクション (Amazon Application Recovery Controller (ARC) のリージョン切り替え (Region switch) など) を含む構造化された分析結果を確認できます。また、障害モード評価 (failure mode assessment) の各検出結果から、その検出結果のコンテキストを引き継いだ状態で DevOps Agent との対話セッションを開始し、質問や調査を通じて緩和策を作成できます。利用を始めるには、Resilience Hub コンソールでサービスを選択し、サービス設定で DevOps Agent を構成します。東京リージョンでも利用可能です。 Amazon CloudFront が VPC origins の dual-stack サポートを発表 Amazon CloudFront の VPC origins が dual-stack (IPv4 / IPv6) に対応しました。これにより、プライベートサブネット内の Application Load Balancer (ALB)、Network Load Balancer (NLB)、EC2 インスタンスに対して、ビューワーからオリジンまでエンドツーエンドで IPv6 トラフィックを届けられます。従来、CloudFront から VPC origins への接続は IPv4 のみで、IPv6 でオリジンに接続するにはオリジンをパブリックサブネットに置く必要がありました。本アップデートにより、オリジンを非公開に保ったまま IPv6 のアーキテクチャ要件や規制要件を満たせます。VPC origins がサポートされるすべての AWS 商用リージョンで利用でき、追加料金はありません。 AWS Transform for full-stack Windows modernization が Aurora PostgreSQL のクロスリージョンデプロイに対応し、新たに 7 リージョンで利用可能に AWS Transform for full-stack Windows modernization が、変換後の Amazon Aurora PostgreSQL データベースを別リージョンへデプロイするクロスリージョンデプロイに対応しました。あわせて、従来のバージニア北部リージョンに東京リージョンを含む 7 リージョンが加わり、合計 8 リージョンで利用可能になりました。SQL Server の DDL ファイルをアップロードし、変換プランでターゲットリージョンを指定するだけで、スキーマ変換と Aurora PostgreSQL クラスターのデプロイを別リージョンに対して実行できます。依存する .NET アプリケーションの接続文字列や ADO.NET、Entity Framework のデータアクセスコードも同じワークフローで PostgreSQL 互換に更新されます。データレジデンシー、レイテンシー、ディザスタリカバリの要件に応じてデプロイ先を選択できるようになりました。 10/16(金) AWS Transform が Azure から AWS へのクラウドネイティブコード変換を発表 AWS Transform の .NET モダナイゼーションエージェントで、Azure SDK から AWS SDK へのアプリケーションコード変換機能の一般提供を開始しました。Azure Functions から AWS Lambda、Azure Blob Storage から Amazon S3、Azure Queue Storage から Amazon SQS への変換に対応し、Azure Cosmos DB から Amazon DynamoDB への変換はプレビューとして利用できます。エージェントがソースコード内の Azure SDK を自動検出し、アセスメントレポートとモダナイゼーションプランに変換オプションを提示するため、ユーザーは内容を確認、調整したうえで変換を実行できます。変換対象はアプリケーションコードのみで、Azure 側のクラウドインフラの移行は対象外です。バージニア北部、ムンバイ、東京、ソウル、シドニー、カナダ中部、フランクフルト、ロンドンの 8 リージョンで利用できます。 Reflection の Beam モデルが Amazon SageMaker JumpStart と AWS Trainium で利用可能に 米国の AI 企業 Reflection が初のオープンウェイトモデル Beam を公開し、Amazon SageMaker JumpStart から利用できるようになりました。Beam は総パラメータ 501B (アクティブ 23B) のスパース MoE モデルです。Reflection によると、SWE-bench Verified で 80.9% を記録するなど、コーディング、推論、エージェント系ベンチマークでオープンウェイトモデルとして高い水準の性能を持ちます。Apache 2.0 ライセンスのため、顧客は自社の AWS アカウント内でモデルを検査、カスタマイズ、運用でき、データを外部 API に送信せずにコーディングエージェントや自動化ワークフローを構築できます。あわせて AWS Trainium3 への移植と最適化も発表され、GPU 以外のコスト効率の高いデプロイ選択肢が示されました。現時点ではバージニア北部とオハイオの 2 リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWS サービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

本記事は、株式会社コーテッグ様と Amazon Web Services Japan による共同執筆です。 みなさん、こんにちは。アマゾンウェブサービスジャパンの古山です。 生成 AI の活用は、チャットボットによる応答から、自律的にタスクを進める「AI エージェント」の実用化へとステージが移りつつあります。本記事では、 Amazon Bedrock AgentCore を中核とした非同期 AI エージェント基盤により、自然言語で問いかけるだけでデータの分析・可視化・レポート生成までを完結させる AI 分析プラットフォーム「 Dotta（ドッタ） 」を構築された、株式会社コーテッグ様の事例をご紹介します。 コーテッグ様について 株式会社コーテッグ 様（以下、コーテッグ様）は、AI とクラウド技術を軸に、サービスの企画・開発・運営を行うエンジニアリングカンパニーです。生成 AI・機械学習を活用したシステム開発とデータ活用支援、Web・モバイルアプリケーション開発、要件定義から運用保守までのフルサイクル開発、技術コンサルティングを手がけられるとともに、自社プロダクトとして、本記事でご紹介する AI データ分析プラットフォーム「 Dotta 」と、医療機関向けの AI 予約・受付システム「ソトマチ」を提供されています。 コーテッグ様は以前より AWS 上で生成 AI の活用を進められており、2024 年 11 月には、 Amazon Bedrock のマルチモーダルモデルを活用した「診察券の自動読み取り機能」により、導入医療機関全体で月間 7,500 時間の業務削減を実現されました（詳細は既存の事例ブログ「 生成 AI-OCR 機能で診察券読取業務を効率化、月間 7,500 時間の削減に成功 」をご覧ください）。 この成功体験を通じて、同社は生成 AI が単なる文字認識や文章生成にとどまらず、業務プロセスそのものを変革する力を持つことを確信されました。その次の挑戦として取り組まれたのが、”自律的に分析を進める AI エージェント” による分析プラットフォーム「Dotta」です。 提供の背景 データが意思決定を左右する時代になりました。しかし多くの企業では、データ分析はいまも一部の専門人材に依存する “属人的な作業” にとどまっています。コーテッグ様は、クライアントとの対話を通じて、現場に共通する次のような課題があると考えました。 分析を依頼してから結果が出るまで時間がかかり、意思決定のスピードが上がらない SQL やデータ基盤を扱える一部のエンジニアに依存し、依頼と待ち時間が慢性化している BI ツールを導入したものの、設定や操作が難しく現場に定着しない 週次・月次の定期レポート作成に、毎回まとまった工数が奪われる 生成 AI の進化は、こうした課題の解き方を大きく変えつつあります。人手不足が続くなかでも少人数で成果を出すために、同社は “チャットボット” の先にある「自律的に分析を進める AI エージェント」に着目しました。 「すべての人に、AI で分析力を。」——このコンセプトのもと、コーテッグは専門知識の有無を問わず誰もが自然言語で分析を完結できる仕組みとして「Dotta」を開発しました。 Amazon Bedrock を活用したサービスの概要 「Dotta」は「聞くだけで分析完了」をコンセプトに、分析の専門知識がなくても “問いかけるだけ” で結果にたどり着ける体験を提供します。主要機能は次の 4 つです。 自然言語クエリ： 「先月の売上を地域別に見せて」といった問いかけだけで、データの取得・集計を実行します。 AI ビジュアライゼーション： データの内容に応じて最適なグラフ・チャートを AI が自動で選定し可視化します。 自動レポート生成： 分析結果を PDF・Markdown・Word 形式で出力します。 マルチデータソース連携： CSV ファイルや MySQL・PostgreSQL などの各種データベース、 Amazon Redshift をはじめとするクラウドデータウェアハウスなど、多様なデータソースに対応します。 対象はマーケティング・営業・プロダクト・経営企画など幅広い職種で、広告効果分析（チャネル別 ROAS・CPA 分析）、営業パイプライン管理、ユーザー行動分析、経営ダッシュボードの作成といった用途が想定されています。これらの分析を、Amazon Bedrock 上で動作する AI エージェントが自律的に進めることで実現しています。 AWS サービスの採用理由 コーテッグ様が「Dotta」の基盤に AWS を選んだ理由は、大きく 3 つあります。 1 つ目は、 Amazon Bedrock の本番運用実績と信頼 です。前述の「診察券の自動読み取り機能」を通じて、Amazon Bedrock を本番環境で運用してきた実績があり、その品質・安定性への信頼が既にありました。また、Amazon Bedrock への入出力データがモデルの学習に利用されない点は、顧客の業務データを扱う分析プラットフォームにとって必須の要件でした。 2 つ目は、 Amazon Bedrock AgentCore による AI エージェント特有の要件への対応 です。数分に及ぶ長時間実行、セッションごとの分離された実行環境といった、AI エージェントならではの実行要件をマネージドサービスとして満たせることが、採用の決め手となりました。 3 つ目は、 少人数でも運用できるサーバーレス・マネージドサービス群 です。 Amazon SQS 、 AWS Lambda 、 Amazon DynamoDB などを組み合わせることで、インフラ管理の負担を最小限に抑えながら、スケーラブルな非同期処理基盤を実現できると判断しました。ソトマチで培った AWS の知見をそのまま活かせることも、開発スピードの面で大きな利点でした。 主要機能と独自性の高い技術的特徴 「聞くだけ」という体験の裏側では、AI エージェントが自律的に考え、必要なコードを書き、データを集計しています。これを支えるのが、Amazon Bedrock AgentCore を用いた非同期 AI エージェント基盤です。分析処理は数十秒から数分に及ぶことがあるため、ユーザーの操作をブロックしない非同期ジョブとして設計されています。 フロントエンド / API 層 利用者向け画面（Next.js によるフロントエンド）と、分析を担う「Analysis API」、データ取込を担う「Ingestion API」、認証・組織管理を担う「Admin API」は、いずれも Amazon ECS （AWS Fargate）上で稼働しています。アクセスは Amazon Route 53 でドメインを管理し、Application Load Balancer でアクセス先を振り分けます。管理者向けの管理画面は Amazon CloudFront と Amazon S3 で配信されています。 非同期 AI エージェント基盤（中核） 自然言語の問いかけを受け取ってから回答を返すまでの流れは、次のように構成されています。 ジョブ登録：Analysis API がユーザーのメッセージを Amazon SQS にジョブとして登録します。 自動起動・呼び出し：SQS をトリガーに AWS Lambda（Dispatcher）が起動し、Amazon Bedrock AgentCore Runtime を呼び出します。 エージェントによる分析：AgentCore Runtime 上で DeepAgents（LangChain）による分析エージェントが動作します。推論には Amazon Bedrock の基盤モデルを用い、分析には Claude Opus 4.8 / Sonnet 4.6、軽量な処理には Claude Haiku 4.5 と、用途に応じてモデルを使い分けています。 コード実行：分析に必要なコードの実行は AWS Lambda（Executor）が担います。 回答のストリーミング：エージェントが生成した回答は Amazon ElastiCache（Valkey）に逐次書き込まれ、Analysis API がそれを読み取って SSE（Server-Sent Events）でブラウザへリアルタイムに流します。読了後は TTL により自動削除される一時領域として扱われます。 会話の永続化：確定した会話は Amazon RDS（PostgreSQL）に永続化されます。これにより、ストリーミング中（未確定）の会話は ElastiCache から、確定済みの過去会話は RDS から取得し、途切れのないチャット履歴の表示・再生を実現しています。 ジョブの進行状況、二重実行を防ぐためのロック、エージェントの生存確認（heartbeat）、そしてエージェントの記憶管理（DeepAgents の checkpointer）は Amazon DynamoDB で管理されます。処理途中の大きな一時データは Amazon S3 に退避して受け渡します。 ユーザー操作による一時停止・再開にも対応しており、キャンセル要求を受け取ると安全に中断して checkpoint とそこまでのメッセージを保存し、後から途中再開できます（Human-in-the-Loop の入力待ちも同様の仕組みで扱われます）。 データ取込・分析基盤 分析対象のデータは、Ingestion API から AWS Lambda（Loader、dlthub を利用）でデータを変換・登録し、AWS Glue Data Catalog と Amazon S3 上の Apache Iceberg テーブルに蓄積されます。蓄積したデータへのクエリには Amazon Athena が用いられています。サービス本体のデータは Amazon RDS（PostgreSQL）でマルチテナント構成として管理されています。 開発段階での苦労と、工夫したポイント 長時間実行される分析処理を UI をブロックせずに扱うことが、同社にとって大きな課題でした。Amazon SQS・AWS Lambda・Amazon Bedrock AgentCore を組み合わせた非同期ジョブとして設計することで、ユーザーは待ち時間中も操作を続けられ、処理の進行はストリーミングで確認できるようになっています。 また、ストリーミング中（未確定）の会話と確定済みの会話を、それぞれ Amazon ElastiCache と Amazon RDS という異なる保存先から取得しつつ、利用者からは 1 つの連続した会話として見えるように繋ぎ込む点にも工夫を要したといいます。 加えて、Amazon DynamoDB による二重実行ロック・heartbeat での生存監視・checkpointer による記憶管理を組み合わせることで、処理の途中停止と再開、そして信頼性を両立させています。 Well-Architected Framework に基づく設計 オペレーショナルエクセレンス 各ノードの状態を Amazon CloudWatch で監視するとともに、ジョブの進行状況やエージェントの heartbeat を Amazon DynamoDB に記録することで、非同期処理の可観測性を確保しています。これにより、長時間ジョブの停滞や異常を早期に検知できる運用フローが整えられています。 セキュリティ 永続化データ（Amazon RDS、Amazon S3）を暗号化し、機密性の高いデータを保護しています。AWS IAM による最小権限のアクセス制御を行い、マルチテナント環境ではテナント間のデータ分離を徹底しています。また、VPC 内のプライベートネットワークで内部通信を完結させ、外部への通信は NAT Gateway を経由させることで、安全な通信経路を確保しています。 信頼性 非同期ジョブは Amazon DynamoDB による二重実行ロックで重複起動を防ぎ、checkpoint による中断・再開に対応しています。SQS・Lambda・AgentCore などマネージドサービスを中心に構成することで、スケールと可用性を確保しています。 パフォーマンス効率 分析には高性能なモデル、軽量な処理には Claude Haiku 4.5 と、用途に応じて基盤モデルを使い分けることで応答性とコストのバランスを取っています。回答のストリーミングには Amazon ElastiCache（Valkey）を用いて低遅延を実現し、大量データのクエリには Apache Iceberg と Amazon Athena によるスケーラブルな分析基盤を採用しています。 コスト最適化 サーバーレス・マネージドサービスを中心に構成することで、利用量に応じたコストとしています。基盤モデルの適材適所での使い分けや、一時データを TTL で自動削除する仕組みにより、無駄なリソース消費を抑えています。 ビジネスインパクトと今後の展望 想定される効果（試算） 「Dotta」がもたらす効果は、何より “時間” として表れます。ここでは、1 名あたり 1 週間に 5 件の分析業務が発生するクライアントの事例をもとに、コーテッグ様による導入効果の試算を紹介します。 前提条件 1 件の分析業務（データ抽出 → 集計 → 可視化 → レポート化）に、従来は 1 名あたり平均 240 分を要していると仮定 「Dotta」では自然言語で問いかけることで、同じ分析を平均 10 分程度で完了できると想定 試算 1 件あたりの削減時間 ＝ 240 分 − 10 分 ＝ 230 分 1 名あたり週の削減時間 ＝ 230 分 × 5 件 ＝ 1,150 分（約 19.2 時間） 10 名のチームで月（4 週）換算すると、約 19.2 時間 × 10 名 × 4 週 ＝ 月あたり約 768 時間の削減 ※上記はあくまで前提条件を置いた試算であり、実際の効果はデータ量・分析内容・利用状況により変動します。 今後の展望 コーテッグ様は今後、以下の機能拡充を進めていく予定です。 データソース登録の AI エージェント化 対応データソースのさらなる拡充 可視化・レポート表現の高度化 「すべての人に、AI で分析力を。」——専門知識の有無にかかわらず、誰もがデータにもとづいて “その場で” 意思決定できる世界の実現に向けて、コーテッグ様の挑戦は続きます。 まとめ 本記事では、Amazon Bedrock AgentCore を中核とした非同期 AI エージェント基盤により、「聞くだけ」で分析が完結するプラットフォーム「Dotta」を実現した、コーテッグ様の事例を紹介しました。生成 AI-OCR による業務効率化（ 前回の事例 ）から、自律的な AI エージェント基盤へ——同社の取り組みは、生成 AI 活用のステージを一歩ずつ確実に進める好例といえます。 AI エージェントの本番運用に必要なランタイム・メモリ・アイデンティティ管理などをマネージドで提供する Amazon Bedrock AgentCore は、本事例のような長時間実行・非同期型のエージェント基盤の構築を強力に支援します。生成 AI や AI エージェントの活用にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 （左から） 大松 宏之 — アマゾン ウェブ サービス ジャパン合同会社　ソリューションアーキテクト 高石 明義 様 — 株式会社コーテッグ　代表取締役 古山 玄弥 — アマゾン ウェブ サービス ジャパン合同会社　アカウントマネージャー

Vercel でウェブおよび AI アプリケーションを構築している開発者は、Vercel Marketplace と v0 から Amazon S3 ストレージリソースを直接追加できるようになりました。これにより、S3 の耐久性、スケーラビリティ、パフォーマンスと、Vercel のプロビジョニングワークフローの利便性を組み合わせることができます。2026 年 10 月 14 日より、 Amazon S3 Tables と Amazon S3 Vectors を含む Amazon Simple Storage Service (Amazon S3) が、 Vercel Marketplace および v0 by Vercel でネイティブに利用できるようになり、日常のストレージ、分析、AI という 3 つの異なるワークロードに対応できるようになりました。 これが重要な理由 何百万人もの開発者が Vercel でウェブアプリケーションや AI アプリケーションを構築、デプロイ、スケーリングしています。ストレージはアプリケーションのパフォーマンスを向上させるために不可欠ですが、それをプロビジョニングするには、以前は AWS マネジメントコンソールに移動してポリシーと認証情報を設定する必要がありました。現在、S3ストレージは Vercel の開発者エクスペリエンスに直接統合され、リソースのプロビジョニングと接続設定が自動的に処理されます。 Amazon Aurora 、 Amazon DynamoDB 、 Amazon OpenSearch Serverless の既存の統合と合わせて、Vercel内の完全なアプリケーションスタック (データベースレイヤーからオブジェクト、ベクトル、オープンテーブルストレージまで) を、すべて 1 つのAWSアカウントで 1 つの請求書で利用できます。 あらゆるアプリケーションに対応したストレージ S3 汎用バケット : データレイク、クラウドネイティブアプリケーション、およびモバイルアプリ用に、ファイル、画像、動画、ドキュメントなど、実質的に無制限のオブジェクトを保存できます。S3 はクラウドで最も耐久性の高いストレージであり、デフォルトで 99.999999999% (イレブンナイン) のデータ耐久性と 99.99% の可用性を提供するように設計されています。 S3 Tables : 自動化されたテーブルのメンテナンスと圧縮を含む、分析用に最適化されたフルマネージド型 Apache Iceberg ストレージ。S3 Tables は、DuckDB を含む任意の Iceberg REST カタログ API 互換エンジンから直接クエリできます。 S3 Vectors : 検索拡張生成 (RAG) やセマンティック検索などの AI アプリケーション専用のベクトルストレージとクエリにより、ベクトルのアップロード、保存、クエリのコストを最大 90% 削減します。 図 1 – Vercel Marketplace の AWS ページ 開始方法 Vercel ダッシュボードから、[ストレージ] タブに移動し、[作成] を選択します。AWS を選択し、S3 バケットタイプを選び、リージョンを選択して、バケットを作成します。プロビジョニングには数秒かかります。 図 2 – リージョンと名前を選択して Vercel で Amazon S3 汎用バケットを作成する バケットをプロジェクトに接続し、Vercel CLI で環境変数をプルします。 vercel リンク vercel env pull .env.local 統合では、 AWS_REGION 、 AWS_ROLE_ARN 、 AWS_RESOURCE_ARN 、および S3_BUCKET_NAME 、 S3_TABLE_BUCKET_NAME 、 S3_VECTOR_BUCKET_NAME などのバケット名を挿入します。ランタイム時に、 @vercel/functions/oidc の awsCredentialsProvider は、有効期間の短い OIDC トークンを、リソースを対象とする一時的な認証情報のために、AWS Security Token Service (AWS STS) と交換します。静的キーはどこにも保存されません。 S3 でのオブジェクトストレージ この Next.js ルートは、汎用バケットにファイルをアップロードします。 import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3"; import { awsCredentialsProvider } from "@vercel/functions/oidc"; const s3 = new S3Client({ region: process.env.AWS_REGION, credentials: awsCredentialsProvider({ roleArn: process.env.AWS_ROLE_ARN, }), }); export async function POST(request) { const formData = await request.formData(); const file = formData.get("file"); await s3.send(new PutObjectCommand({ Bucket: process.env.S3_BUCKET_NAME, Key: file.name, Body: Buffer.from(await file.arrayBuffer()), ContentType: file.type, })); return Response.json({ success: true }); } ListObjectsV2Command と GetObjectCommand を同じクライアントで使用して、オブジェクトを一覧表示して読み取ります。 S3 テーブルによる分析 S3 Tables は分析専用の S3 ストレージを提供し、データ量の増加に応じてクエリのパフォーマンスを自動的に最適化するように設計されています。これらはフルマネージド型 Apache Iceberg テーブルを提供し、テーブルのメンテナンスと圧縮を自動化し、あらゆる Apache Iceberg REST Catalog 準拠エンジンと連携します。Vercel 関数内で DuckDB を使用すると、軽量なクエリを実行できます。この例では、テーブルバケットを ARN でアタッチし、集計クエリを実行します。 import { DuckDBInstance } from "@duckdb/node-api"; import { awsCredentialsProvider } from "@vercel/functions/oidc"; const creds = await awsCredentialsProvider({ roleArn: process.env.AWS_ROLE_ARN, })(); const db = await DuckDBInstance.create(); const conn = await db.connect(); await conn.run("INSTALL aws; LOAD aws; INSTALL httpfs; LOAD httpfs; INSTALL iceberg; LOAD iceberg;"); await conn.run(` CREATE SECRET s3cred ( TYPE s3, KEY_ID '${creds.accessKeyId}', SECRET '${creds.secretAccessKey}', SESSION_TOKEN '${creds.sessionToken}', REGION '${process.env.AWS_REGION}' ); `); await conn.run(` ATTACH '${process.env.AWS_RESOURCE_ARN}' AS s3tables ( TYPE iceberg, ENDPOINT_TYPE s3_tables ); `); const rows = await (await conn.run(` SELECT town_city, AVG(median_price) AS avg_price FROM s3tables."${process.env.S3_TABLES_NAMESPACE}".town_monthly GROUP BY town_city ORDER BY avg_price DESC LIMIT 10 `)).getRowObjects(); Next.js ルート内で DuckDB を実行する場合は、 @duckdb/node-api を next.config.mjs の serverExternalPackages に追加して、ネイティブバインディングがバンドルされないようにします。 S3 Vectors によるベクトル検索 S3 Vectors は、AI エージェント、AI 推論、および Amazon S3 に保存されているコンテンツのセマンティック検索向けに、コスト最適化された専用ベクトルストレージを提供します。S3 Vectors は、個別のベクトルデータベースがなくてもベクトルの保存とクエリをネイティブにサポートしていますが、生成はしません。選択したモデルで埋め込みを作成し、最も近い一致を探すためにインデックスにクエリします。 import { S3VectorsClient, QueryVectorsCommand } from "@aws-sdk/client-s3vectors"; import { awsCredentialsProvider } from "@vercel/functions/oidc"; const vectors = new S3VectorsClient({ region: process.env.AWS_REGION, credentials: awsCredentialsProvider({ roleArn: process.env.AWS_ROLE_ARN, }), }); export async function POST(request) { const { embedding } = await request.json(); const result = await vectors.send(new QueryVectorsCommand({ vectorBucketName: process.env.S3_VECTOR_BUCKET_NAME, indexName: "documents", queryVector: { float32: embedding }, topK: 5, returnMetadata: true, })); return Response.json({ matches: result.vectors }); } v0 by Vercel を使用した構築 v0 から、構築したいものを記述すると、適切なリソースがプロビジョニングされます。汎用バケットを入手するには「ユーザーが AWS を使用して画像をアップロードしたフォトギャラリー」、S3 ベクトルを取得するには「PDF からの質問に答えるサポートボット」、S3 テーブルを取得するには「クリックストリームデータの分析ダッシュボード」を依頼してください。その後、v0 は接続を設定し、動作するコードを生成します。 図 3 – 自然言語プロンプトから PDF サポートボットを生成している v0 で、Amazon S3 Vectors が接続され、アプリケーションがプレビューパネルに表示された状態。 S3 と AWS データベースの結合 Vercel 上のすべての AWS サービスは同じアカウントと認証モデルを共有しているため、追加のセットアップなしでそれらを組み合わせることができます。例えば、ファイルメタデータを S3 のファイルとともに Aurora に保存したり、RAG の取得用に S3 ベクトルに埋め込んでドキュメントテキストを DynamoDB に保存したりできます。 AWS アカウントで Vercel を使用する 構築とテスト用の S3 機能をサポートする統合を通じて、新しい AWS アカウントを作成できます。既存の AWS アカウントをリンクして S3 と AWS の機能をすべて使用し、現在の請求内容を維持することもできます。既存の AWS アカウントをリンクする場合、Vercel はプラットフォームを通じて作成した新しいバケットでのみ機能します。すべての S3 リソースはお客様の AWS アカウントにあるため、AWS ネイティブのツールと 1 か所でストレージを管理できます。 料金と利用可能なリージョン 統合は無料で、使用するリソースに対して標準の Amazon S3 料金をお支払いいただきます。Vercel を通じて作成された新しい AWS アカウントには、6 か月間有効な 100 USD のクレジットが提供されます。S3 Tables と S3 Vectors を含む Amazon S3 は、Vercel がサポートしているすべての商用 AWS リージョンの v0 および Vercel Marketplace から入手できます。開始するには、 v0 または Vercel Marketplace の AWS ページにアクセスしてください。 会話にご参加ください APIを呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCPサーバー と プラグイン を使用してみてください。 Amazon S3 の AWS re:Post に関するフィードバックをお寄せください。 – Daniel 原文は こちら です。