みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 AWS Builder Center で、 AI-DLC Workflow V2 の解説シリーズの更新 が続いており、すでに 32 本の記事が公開されています。AI-DLC を実践中の方は参考になる内容ですので是非チェックしてみてください。 先週もご案内しましたが AWS ジャパン生成 AI 実用化推進プログラム について、このプログラムの 1 コースである 「 フィジカル AI 開発支援プログラム by AWS ジャパン 」第 2 期 の応募受付が始まっています。VLA をはじめとするロボット基盤モデルや、VLM、世界モデルなどの周辺技術を AWS 上で開発する企業・団体が対象で、スタートアップから大企業、大学・研究機関まで応募できます。フィジカル AI のスペシャリストによる技術支援、コスト最適化、コミュニティ形成、GTM 支援が受けられ、第 1 期に応募した方も再応募が可能です。締切は 11 月 16 日（月）なので、ロボティクス × 生成 AI に取り組んでいる方は是非ご検討ください。 そして、いよいよ来月です。 re:Invent 2026 のセッションカタログ も公開されていますのでこちらもチェックしてみてください。 それでは 10 月 26 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 ドコモSMTBネット銀行が電話・チャット両チャネルで実践する Amazon Connect Customer AI agents による応対高度化 」 ドコモSMTBネット銀行は、生成 AI による自動応対の基盤を Amazon Connect Customer AI agents に移し、2026 年 9 月から電話とチャットの両チャネルで応対を開始しました。同社は 2024 年 8 月に SaaS の生成 AI で PoC を始め、回答文を生成せずコールリーズンの判定と FAQ の提示に機能を限定することでハルシネーションを設計で防いできました。基盤を移した理由は 3 つです。既存の Amazon Connect Customer 環境内に構築でき、発信者番号などの情報を応対の判断に使えること。意図の理解は AI agents に任せ、確実性が求められる処理はコンタクトフローで組む分担ができること。通話時間とチャット数を基にした料金体系でコストを見積もれることです。2026 年 1 月の PoC では回答精度 95% 以上を確認し、曖昧な質問を聞き返して FAQ を絞り込む動きも実現しました。応答時間の検証では、所要時間が出力トークン数にほぼ比例し、AI agents が書く内容の約 9 割が固定値だったことから、固定値はフロー側で組み立てる構成に見直しています。生成 AI 導入の二周目に入ったコンタクトセンターに向けて、AI に任せる範囲を決めてから基盤を選ぶこと、運用開始後の改善を前提に設計することの 2 点を示唆として挙げています。 ブログ記事「 スペックファースト: SAP ABAP のスペック駆動開発 」 SAP ECC を運用するお客様の ABAP チームは、RISE with SAP へのアップグレードに先立ってカスタムコードのモダナイゼーションを求められています。バイブコーディングで ABAP を生成すると結果は早く得られますが、コードの背後にある判断が残らず、要件が変わったときの修正が難しくなります。本記事では、Kiro CLI 上で動作する AWS Coding Plugin for SAP ABAP を例に、ABAP におけるスペック駆動開発 (SDD) の進め方を紹介します。要件・設計・タスクを記録する 3 つの Markdown ファイルをコード生成の前に作成し、オブジェクトタイプ、入出力、ビジネスルール、BAdI やユーザーエグジットといった拡張手法をスペックに明記します。命名規則や承認済みライブラリなどチーム全体の標準は、エージェントがセッション開始時に読み込むステアリングファイルに置きます。開発は AI-DLC の 3 フェーズに沿って進み、Construction ではエージェントが ATC チェックと ABAP Unit テストに合格するまでループを繰り返します。プラグインは無料で、Kiro CLI のサブスクリプションが必要です。 ブログ記事「 Amazon Bedrock AgentCore を使用した電力・公益事業向けのインテリジェントなアラーム管理 」 発電所の制御室や電力会社の運用センターでは 1 日に数千件のアラームが発生し、根本原因の特定には 3〜4 つのアプリケーションに個別にクエリを実行して通常 25〜40 分かかります。本記事では、北米の大手電力会社が Amazon Bedrock AgentCore 上で運用しているマルチエージェントアーキテクチャを紹介します。プロセスヒストリアン、設備保全管理システム (CMMS)、ドキュメント管理、チケットシステムの 4 つのデータドメインごとに専門エージェントを置き、スーパーバイザーエージェントが並列に呼び出して調査結果を 1 つのレポートにまとめます。各バックエンドは MCP (Model Context Protocol) ツールサーバーとして公開するため、新しいデータソースの追加時は MCP サーバーを 1 つデプロイするだけで済みます。タービンのベアリング振動アラームの例では、振動のトレンド、期限を 2 か月過ぎた予防保全、OEM の技術情報、過去の類似インシデントを数分で関連付け、推奨アクションと先送りした場合のリスクを提示します。トリアージにかかる時間は数時間から数分に短縮されました。リファレンス実装は AWS CDK スタックとして GitHub で公開 されており、モックデータでそのまま評価できます。 ブログ記事「 AWS で AI 生成コンテンツのオーディオ来歴情報を生成元で構築する 」 EU AI 法第 50 条は、EU で提供される AI 生成コンテンツに機械可読な来歴情報の表示を義務付けており、既存システムの期限は 2026 年 12 月 2 日です。本記事では、合成の段階で AI 生成オーディオに来歴情報の透かしを埋め込み、ライブストリーミングのパイプラインを通じて検証可能な管理の連鎖を保持する AWS 上のパイプライン SENTINEL を解説します。生成、変換、レジストリ、復元の 4 つのプレーンで構成されます。生成プレーンでは、Amazon Bedrock Guardrails の評価結果のハッシュに AWS KMS で署名し、Amazon Polly が合成した PCM 波形に AudioSeal の 16 ビットの透かしを埋め込みます。変換プレーンでは AWS Elemental MediaLive、MediaPackage、MediaTailor の各段階で署名付きアサーションを連結し、レジストリプレーンで来歴情報を保存します。復元プレーンでは、Amazon CloudFront と Lambda@Edge に配置した API に 1 秒以上のオーディオを送ると、来歴情報のチェーン全体を C2PA 互換のマニフェストとして受け取れます。 ブログ記事「 AMOREPACIFIC が Kiro でレガシー SAP ECC に AI 駆動開発を導入した方法 」 グローバルな化粧品企業 AMOREPACIFIC の ERP Platform Planning チームは、SAP ECC 6.0 上の ABAP と SAPUI5 の開発に Kiro を導入し、4 つのプロジェクトで最大 72% の生産性向上と 80% のドキュメント作成時間の削減を計測しました。プロジェクト開始前の見積もりは 20〜30% でした。SAP 開発は SAP GUI 上で行われ、ABAP コードはサーバー内部にあるためローカルファイルとして扱えません。チームは AWS のソリューションアーキテクトが構築した SAP 専用の MCP サーバーでカスタム RFC やテーブル構造のコンテキストを Kiro に渡し、ABAP 用と SAPUI5 用の Steering ファイルで Include 構造や IIFE パターンなどのコーディング標準を適用しました。Kiro の spec-driven development は、コードを書く前に FS/TS (機能仕様書・技術仕様書) を作成する SAP 開発の順序と合致していたため、Jira ベースのワークフローを変えずに採用できました。生成したコードは共有フォルダを経て開発者がレビューしてから SAP に投入します。4 つのプロジェクトすべてで仕様ドキュメントとコードを 100% 同期させた状態に保ちました。 ブログ記事「 金融機関が AI-DLC を素早く効果的に運用に乗せる方法 」 金融機関は AI コーディングエージェントを急速に導入していますが、規制当局や自社のリスクアペタイトを満たすガバナンスの枠組みを持たない組織も多くあります。本記事では、Kiro、Claude Code、OpenAI Codex のいずれを使っていても、エージェントを組織のルールの範囲内で動かすガバナンス層 (ハーネス) を数日で構築する方法を説明します。欧州の大手保険会社との取り組みでは、お客様のエンジニアが AWS と協力し、ガバナンス層とその保守に必要なスキルを 3 日で構築しました。層は 6 つの要素で構成され、それぞれが ガバナンス・リスク・コントロール (GRC) チームになじみのある統制に対応します。エージェントが毎回読む永続的なコンテキスト、保存時やパイプラインで決定論的にチェックする Hooks、手順をスキルとしてまとめる手続きのガバナンス、修正を恒久的なルールに格上げするナレッジループ、コンテキストを分離したレビュー用エージェントによるメーカー・チェッカー、最小権限を定める権限の境界です。ハーネスはソフトウェアの成果物として扱い、静的検証と、モデルが変わるたびに実行する振る舞いの回帰テストで検証します。ステアリングファイルによる統制は非決定論的なため、CI/CD の linter や Policy as Code のゲートで補う必要があると強調しています。 ブログ記事「 AWS Continuum for code vulnerabilities が一般提供を開始しました 」 2026 年 10 月 22 日に一般提供を開始した AWS Continuum for code vulnerabilities は、コードの脆弱性を検出して検証し、修正をパッチやプルリクエストとして提供するセキュリティサービスです。脆弱性スキャナーは 1 日に数千件の検出結果を生成しますが、到達不能や悪用不可能なものも多く、一般的な深刻度スコアでは攻撃者が実際にどのリソースに到達できるかは分かりません。Continuum は、コードリポジトリと AWS 環境の 2 つの情報源からコンテキストグラフを構築し、どのシステムがビジネス上重要で、どのデータを扱い、攻撃経路がどれだけ近いかに応じて検出結果に優先順位を付けます。再現可能な検出結果は隔離されたサンドボックスでエクスプロイトを実行して確認し、攻撃経路、ソース分析、影響範囲の評価を添えます。確認された問題ごとに、コードパッチ、依存関係のアップグレード、設定変更のいずれかの修正を生成し、接続したリポジトリにプルリクエストとして開きます。すべての修正には人による承認が必要です。記事では、コンソールで環境を作成し、検証済みの問題の評価理由と GitHub に配信された修正を確認する流れを画面に沿って紹介しています。米国東部 (バージニア北部) と米国西部 (オレゴン) で利用できます。 ブログ記事「 【随時更新】Inter BEE 2026 AWS ブースのご案内：人が創り、人が決める。AI エージェントが支える次世代放送局 」 AWS は 2026 年 11 月 18 日から 20 日まで幕張メッセで開催される Inter BEE 2026 に出展します (7 ホール 小間 7314)。テーマは「人が創り、人が決める。AI エージェントが支える次世代放送局」で、AI エージェントが判断の材料を整え、最終判断は人が行う構成を 4 つのデモで見せます。ブース 01 では、読売中京 FS ホールディングス様が構築した自然文・顔・文字での素材検索や、Amazon Bedrock の埋め込みモデルと Amazon S3 Vectors で映像資産を意味で探す仕組み、テレビ朝日クリエイト様と連携したライブ映像の縦型切り出しを展示します。ブース 02 では、IP 考査や権利・契約分析、TBS テレビ様の番組制作現場で使われている原稿修正の AI エージェントアプリ、パートナー様の考査ソリューションを紹介します。ブース 03 は AWS Elemental MediaConnect Router と MXL によるクラウド放送局、ブース 04 は制作の来歴をクラウドに残す AI 時代のバーチャル制作パイプラインです。Inter BEE チャレンジでは、来場者から伺ったマスターやプレイアウトへの要望を、会期中に Kiro で機能として実装していきます。 ブログ記事「 re:Invent 2026 クラウドと AI の支出管理 ガイド: 参加前に押さえておきたいポイント 」 AI の時代には、トークンをはじめとする新たな用語やコストの切り口が加わり、総所有コスト (TCO) は AI の総コスト (TCA) へと広がりました。re:Invent 2026 には、クラウド財務管理と AI コスト管理に関するセッションが 30 を超えて用意されており、本記事ではそのうち 9 つを紹介します。セッションを貫くテーマは 3 つです。AI 支出を詳細に把握する FinOps for AI、きめ細かなコスト配分と予測で基礎を極めること、AI を FinOps チームのために働かせる AI for FinOps です。毎年恒例の新機能発表セッション COP209 では AVIV Group が登壇します。Amazon Bedrock 上の AI アプリをコスト、レイテンシー、制御の観点で最適化するライブコーディングの COP403、API 呼び出しにタグを付けて Bedrock のコストを配分する Builders’ セッション COP311、コスト見積もりゲートを CI/CD パイプラインに組み込む COP312 などが並びます。会期中は 1 年のブランクを経て CFM 専用キオスクが戻り、AWS FinOps Agent などのライブデモを見られます。重なるセッションは木曜のリピート開催を使うといった計画の Tips も載っています。 ブログ記事「 エージェント時代の運用：re:Invent 2026 の AIOps セッション 」 テレメトリの量とインシデント件数が増え続ける一方で、運用担当者の人数は横ばいです。re:Invent 2026 のクラウド運用 (COP) トラックの AIOps セッションでは、AI エージェントがインシデントの調査、修正案の提示、コード変更のレビュー、監査証跡の保持といった運用業務を担う方法を取り上げます。本記事は、エージェント型運用の戦略とアーキテクチャ、AWS DevOps Agent によるインシデントの調査と解決、エージェントの構築と拡張、安全なアクションの 4 テーマでセッションを整理しています。Best Buy や Verisk がエージェント駆動の運用を語るブレイクアウト、Banco BMG が 1 日約 350 件の運用イベントの根本原因特定を数時間から数分に短縮した事例、Capital One が AWS DevOps Agent を自律型 SRE として運用する事例のライトニングトークがあります。ハンズオンでは、Amazon EKS 上のストアに障害を注入して根本原因を特定するワークショップ COP317 や、MCP、ACP、A2A の 3 つのプロトコルを検討するチョークトーク COP402 が用意されています。エージェント型運用を初めて学ぶ方は COP331 と COP301 から始めるなど、目的別の推奨ルートも示されています。 ブログ記事「 Claude Haiku 5.5 が Kiro で利用可能になりました 」 Claude Haiku 5.5 が Kiro IDE、CLI、Web、Crew のすべてで利用できるようになりました。Claude 5.5 ファミリーで最も高速なモデルで、これにより最も難しい問題には Opus 5.5、日常的なコーディングには Sonnet 5.5、処理量や速度が重要な場面には Haiku 5.5 という 3 つのモデルがそろいました。Anthropic のデータによると、エージェント的なコーディングを測る Terminal-Bench 4.0 では Haiku 4.5 の 0.0% から 39.2% に、実務的なナレッジワークを測る GDPval-AA v2.1 では 735 から 1620 にスコアを伸ばしています。長いコンテキストの要約や圧縮、リクエストの分類やルーティング、並列で動かすサブエージェントに向いています。Adaptive Thinking に対応し、effort は low から max までの 5 段階 (既定値は medium) で、コンテキストウィンドウは 1M トークンです。us-east-1 (バージニア北部) と eu-central-1 (フランクフルト) の Kiro Pro、Pro+、Pro Max、Power のお客様に実験的サポートとして提供され、クレジット乗数は 0.06 倍、100K トークンを超えるリクエストは 0.3 倍です。 ブログ記事「 Kiro の新しい無料トライアルで 500 クレジットを追加提供 」 11 月 1 日から Kiro の無料トライアルの仕組みが変わります。無料プランから初めて Pro にアップグレードすると、その月の残りの期間は無料になり、さらに 12 か月間いつでも使える 500 トライアルクレジットが付与されます。あわせて、プラン料金とクレジットの両方が秒単位の日割り計算になります。たとえば 30 日の月の 15 日 00:00 UTC に Pro にアップグレードすると、日割りクレジット 533 とトライアルクレジット 500 を受け取り、支払いは 0 ドルです。Pro+、Pro Max、Power で開始する場合も Pro の無料期間が適用され、選択したプランの日割り料金と Pro の日割り料金との差額だけを支払います。トライアルクレジットはプランのクレジットを使い切った後に消費され、無料プランに戻しても引き継がれます (無料プランでは対象モデルにのみ使用可)。無料トライアルが適用されるのは最初のアップグレードのみです。11 月 1 日までにアップグレードすれば従来の 20 ドルの割引が適用され、未使用のクレジットも残ります。月末近くにサインアップした場合でも実際のプロジェクトで十分に試せるようにすることが、変更の狙いです。 ブログ記事「 週 1,000 件の PR でもソフトウェアファクトリーを安定させる方法 」 3 人のエンジニアとエージェントのクルーが 1 週間で 1,000 件のプルリクエストをマージした Kiro Crew チームに最も多く寄せられた質問は、それで全体が壊れないようにどうしているのか、というものでした。本記事は、自分で読むよりも信頼できる自動テストとチェックをどう構築したかを 5 つの段階で振り返ります。当初は AI レビューのコメントをすべて解決するルールが空回りし、エンドツーエンドテストもありませんでした。そこで指摘を重大度でティア分けし、複数パスで 1 回のラウンドに指摘を出し切る独自のレビューエージェントを追加しました。GitHub への移行後は、設計、第一原理、UX と役割を分けたレビュアーや、盲点を共有しないよう異なるモデルファミリーのレビュアーを導入し、テストカバレッジを 90% 超に引き上げました。80 件以上のチェックを 1 つの PR Readiness 判定に集約し、prepare-pr スキルがグリーンになるまでループを回すことで、人間とエージェントが同じ「完了」の定義を共有しています。ループが修正を肥大化させる過剰なエンジニアリングには、履歴を振り返る仕組みと、最初の判断を下すコンダクターエージェントで対処しました。ワークフローやレビューのプロンプトは Kiro Crew のリポジトリ で公開されています。 ブログ記事「 Kiro for Students の対象大学を新たに 41 校追加しました 」 Kiro for Students の対象が世界の 41 大学に広がりました。（日本の対象校は現時点で東京大学、東北大学、神戸大学です）対象校の学生は Kiro を 1 年間無料で使え、毎月 1,000 クレジットとプレミアムモデルなどの有料機能が含まれます。申し込みは、IDE、CLI、Web、Crew のいずれかで Google、GitHub、AWS Builder ID を使ってサインインし、設定ページの Students セクションで自分の学校が対象か確認してから、SheerID による学生認証を完了します。使わなかったクレジットは翌月に繰り越されず、追加クレジットの購入もできません。1 年の利用期間が終わるとアカウントは自動的に無料プランに切り替わります。在籍大学が対象校に含まれていない場合は追加をリクエストできます。9 月に学生プログラムを 133 大学へ広げてから対象校の追加を求める声が多く寄せられたことが背景で、Kiro Student Discord コミュニティでは各地のキャンパス訪問やハッカソンの情報が案内されます。詳細と申し込みは kiro.dev/students から行えます。 ブログ記事「 AI エージェントに書き込みを任せるとき、境界をどこに置くか ― Kiro CLI で仕組みを作り、1 か月運用した記録 」 合同会社 BrightFlow 代表の池田 健人様による寄稿です。計画とレビューを担う外部の AI と、実装を担う Kiro CLI を組み合わせた仕組み BRIDGE を自社プロダクトの開発で約 1 か月運用し、書き込みを任せるときの境界の置き方を整理しています。境界は 4 つです。チャット側の AI に GitHub や Kiro の資格情報を渡さず、呼べるツールを 5 つに固定すること。変更してよいファイルを依頼ごとに宣言させ、実行後の差分と照合して宣言外の変更があれば失敗とすること。Kiro CLI のプロセスを bubblewrap と seccomp のサンドボックスで動かし、書き込みの上限を実行環境で決めること。レビューした PR の HEAD SHA と一致する場合だけマージすることです。1 か月で作成された PR は 624 件で、マージは 317 件 (約 51%) でした。未マージの半数以上は差分の無い PR などもともとマージする必要の無いもので、読み取り専用の経路が足りないと書き込みの経路が調査に使われる、という教訓につながっています。最後に、Permissions、Workflows、ローカルコマンドサンドボックスなど 2026 年 10 月時点の Kiro の標準機能で 4 つの境界がどこまで実現できるかを比較しています。 ブログ記事「 Spec it safe：セキュリティ要件で仕様をハードニングし、シフトレフトを実現する 」 仕様駆動開発 (SDD) の仕様に書かれているのはソフトウェアが何をすべきかであり、誤用されたときにどう耐えるかは書かれていないことがほとんどです。セキュリティの制約が欠けた仕様では、エージェントはフレームワークの既定の動作に頼り、インジェクションや認可の欠陥が開いたままでも機能チェックは通ってしまいます。本記事は、機能要件を書き終えてから計画を始めるまでの間に、EARS 形式の要件からセキュリティ上の義務を提案する Kiro Power「仕様のハードニング」を紹介します。提案は、インジェクション、認証、認可、データの露出など 8 つの領域にわたる 60 の CWE を再利用できる義務に対応付けたライブラリから作られ、モデルの推測ではなく既知の脆弱性に基づきます。エンジンはキーワードと正規表現でトリガーを検出し、仕様に対策が書かれていない抜けだけを SECURITYタグ付きの EARS 項目として挿入します。患者記録の検索を例に、機能だけの要件から SQL インジェクションと認証の欠如を含むコードが生成される様子と、ハードニング後に 7 つの義務が追加される様子を示しています。仕様のハードニングは研究段階のプロトタイプで、SAST や人によるレビューの代わりにはならないと明記されています。Power は GitHub の sample-kiro-spec-security-hardening リポジトリ で入手できます。 ブログ記事「 Kiro のハロウィンハッカソン Kiroween 2026 が始まりました 」 Kiro が毎年ハロウィンの時期に開いているハッカソン Kiroween が今年も始まりました。作品づくりと提出の受付は日本時間 2026 年 10 月 31 日午前 1 時に始まり、締め切りは日本時間 12 月 5 日午前 7 時です。オンラインで参加でき、賞金の総額は 10 万ドルで、10 月 31 日の時点で 2,882 人が参加登録しています。今年は Kiro IDE、CLI、Web に加えて Kiro Crew も使えます。カテゴリーは昨年と同じ Resurrection、Frankenstein、Skeleton Crew、Costume Contest の 4 つで、1 つの作品が入れるのは 1 つだけです。提出物は GitHub の公開リポジトリ、動いているアプリの URL、機能の説明、3 分未満のデモ動画、Kiro をどう使ったかの説明です。総合 1 位は 30,000 ドルで、Best Kiro Crew App や Best Student Project などのボーナス賞が新設され、Bonus Blog Prize は 2,000 Kiro クレジット × 100 件に変わりました。無料の Kiro クレジット 4,000 は日本時間 12 月 2 日午前 5 時まで申請できます。記事は参加条件、日程、賞、審査、準備を公式ページから日本語でまとめたもので、正式な内容は 英語の公式ページ に従います。 サービスアップデート OpenAI GPT-6.1 Terra が Amazon Bedrock で一般提供開始 OpenAI GPT-6.1 Terra が Amazon Bedrock で一般提供になりました。GPT-6 ファミリーに加わる Terra 系列の最新モデルで、日常的なワークロード向けに能力、速度、コスト効率のバランスがとれたモデルです。GPT-5.6 Terra と比べて、詳細な視覚推論、正確なコンピュータ操作、事実性と自然な文章作成が向上しました。OpenAI の Agents’ Last Exam 評価では、GPT-5.6 Terra を 15 ポイント上回り、GPT-6 Astra と同等の成績を示しました。タスクの完了も、GPT-6 Astra や GPT-6.1 Sol より 3 倍以上速いという結果でした。入出力トークンの価格は GPT-6.1 Sol および GPT-5.6 Terra より 50% 以上低く設定されています。コンテキストウィンドウは最大 100 万入力トークンで、テキストと画像の入力に対応します。Amazon Bedrock API から直接呼び出すほか、ChatGPT Work や Codex から Amazon Bedrock 上のこのモデルを使うように設定することもできます。対応リージョンやエンドポイント、API、推論プロファイル、料金は Amazon Bedrock のドキュメント に記載されています。 Amazon Bedrock が Claude Haiku 5.5 向けにカナダのクロスリージョン推論を提供開始 Amazon Bedrock で、Anthropic の Claude Haiku 5.5 向けにカナダのクロスリージョン推論 (CRIS) が利用できるようになりました。厳格なデータレジデンシー要件を持つお客様は、推論処理をカナダ国内に完全に留めることができます。カナダ CRIS は、ca-central-1 と ca-west-1、つまりカナダ (中部) とカナダ西部 (カルガリー) の間だけでリクエストをルーティングします。金融サービス、ヘルスケア、公共部門などの規制業種が、連邦および州のデータレジデンシー要件を満たすのに役立ちます。Claude Haiku 5.5 では米国 CRIS とグローバル CRIS も引き続き利用できます。こちらはより広い範囲の AWS リージョンにルーティングされます。グローバル CRIS はコスト削減も提供します。カナダ CRIS は、モデル選択が限定された推論プロファイルです。今後のモデルやバージョンがこのプロファイルで提供されない場合があります。推論処理をカナダ国内に留める必要があるワークロードに推奨されています。 SageMaker MLflow Apps が MLflow 3.16 に対応 Amazon SageMaker AI の MLflow Apps が MLflow 3.16 に対応しました。生成 AI と機械学習のワークフローに、再設計されたトレース体験と高速な実験トラッキングが加わります。MLflow 3.16 は生成 AI アプリケーションとエージェントのデバッグや分析を改善します。再設計されたトレースエクスプローラーがデフォルトになり、行の高さの調整、列の並べ替え、任意のトレースタグやメタデータフィールドからのカスタム列の作成が可能です。また、メトリクス履歴が大きい実験でのメトリクスチャートの表示が高速化されています。新しい MLflow Apps は MLflow 3.16 で作成され、既存の MLflow Apps は今後のメンテナンスウィンドウで自動的にアップグレードされます。利用者側の作業は不要です。MLflow 3.16 は MLflow Apps が利用できるすべての AWS リージョンで使えます。 AWS Agent Registry が 4 つの AWS リージョンで追加提供開始 Amazon Bedrock AgentCore を通じて提供される AWS Agent Registry が、欧州 (ロンドン) eu-west-2、欧州 (フランクフルト) eu-central-1、米国東部 (オハイオ) us-east-2、カナダ (中部) ca-central-1 の 4 つの AWS リージョンで新たに利用できるようになりました。これで提供リージョンは 9 つになります。AWS Agent Registry は、組織内のリソースを整理、キュレーション、発見するための一元的なカタログを提供するフルマネージドのディスカバリーサービスです。MCP サーバー、ツール、エージェント、エージェントスキル、カスタムリソースを検索可能なレジストリに公開し、承認ワークフローでアクセスを制御できます。人間のユーザーと AI エージェントのどちらも、ハイブリッド検索、カタログの閲覧、ネイティブの MCP エンドポイントを通じて適切なツールやエージェントを見つけられます。 Quick がエージェント型アクションのスマート承認に対応 Amazon Quick に、不要な承認プロンプトを減らしつつ重要なアクションへの人間の監督を維持するレビュー層、スマート承認が追加されました。エージェントがメールの送信、レコードの更新、チケットの作成などをユーザーに代わって行う場面が増えると、すべてのステップで承認を求めることは承認疲れにつながります。スマート承認では、クラシファイアーと呼ばれる別のレビューモデルが、対象となる各アクションをユーザーの依頼内容に照らして評価します。定型的なアクションは自動で承認し、影響の大きいアクションはユーザーのレビューに回します。既存のポリシーが常に優先され、レビュー対象はユーザー設定が「毎回確認」のアクションだけです。拒否されたアクションは拒否のままで、新しいアクセス権が付与されることはありません。組織外へのコンテンツ送信、権限変更、コンテンツ削除、支払い、依頼範囲を超えるアクションはユーザーに回されます。レビューが失敗またはタイムアウトした場合も同様です。スマート承認はデフォルトで全ユーザーに有効です。管理者はカスタム権限で利用者を制御でき、ユーザーはチャットオプションから自分の会話やスケジュール実行で無効にできます。各レビューと設定変更は AWS CloudTrail に記録されます。Amazon Quick のエージェント機能が利用できるすべての AWS リージョンで使えます。 Amazon Bedrock AgentCore CLI バージョン 1.0 が利用可能に Amazon Bedrock AgentCore CLI バージョン 1.0 ( @aws/agentcore 1.0.0) が一般提供になりました。起動の高速化、一貫したコマンド構造、より多くの AgentCore リソースへの対応を目的に再構築されています。この CLI は、AI エージェントと関連リソースの作成、開発、デプロイ、運用をターミナルから行うためのツールです。バージョン 1.0 では、プロジェクトワークフローを使うほか、ハーネス、ランタイム、メモリ、アイデンティティ、ゲートウェイ、ペイメントを、プロジェクトに追加せずに直接操作できます。既存リソースを ID や ARN で呼び出す、対話型シェルを開く、ハーネスをエクスポートする、検索可能なメニューやリソースピッカー、ガイド付きワークフローを使うといった操作が可能です。リージョン選択、JSON 出力、デバッグ、バージョン情報のグローバルフラグはコマンド間で統一されています。既存のプロジェクトは agentcore migrate コマンドでバージョン 1 に移行できます。npm からインストールでき、ソースコードは GitHub で公開されています。 AWS Step Functions のワークフローが AI エージェントのツールとして利用可能に AWS Step Functions のワークフローを、Amazon Bedrock AgentCore Gateway を通じて AI エージェントのツールとして使えるようになりました。エージェントがワークフローを実行するタイミングと渡す入力を決め、Step Functions は定義どおりに各ステップを実行します。既存の Standard と Express のワークフローをそのままツールにできます。AgentCore Gateway は MCP (Model Context Protocol) を通じて AI エージェントをツールに接続します。これにより、エージェントは複数ステップの業務プロセスを毎回同じ順序で実行できます。たとえばカスタマーサポートのエージェントが返金ワークフローを開始すると、Step Functions が適格性チェック、マネージャー承認、返金処理を順に実行するため、すべての返金がポリシーに従います。エージェントはワークフローの実行履歴も参照でき、夜間に失敗した処理とその箇所をオンコール担当者に伝えるといった使い方も可能です。Amazon Bedrock AgentCore Gateway が利用できるすべての AWS リージョンで使え、料金は Step Functions と AgentCore Gateway の標準料金が適用されます。 AWS Lambda の durable functions が実行インサイト向けのライブテレメトリをエクスポート可能に AWS Lambda の durable functions 向けに、Durable Execution Telemetry Exporter プラグインが発表されました。durable 実行のステップごとの履歴を取得し、選択した 1 つ以上の送信先に送るオブザーバビリティプラグインです。エクスポートしたデータは運用やビジネスのインサイト取得に使え、標準の保持期間を超えて履歴を保管できます。あわせて、Kiro などの AI エージェントが自然言語でエクスポート済みのテレメトリデータを照会できる MCP (Model Context Protocol) サーバーも公開されました。オンコールのエンジニアが最近失敗した実行の一覧と原因を AI エージェントに尋ねたり、ビジネスアナリストが特定顧客のトランザクションを探したりできます。エクスポーターは実行状態、処理時間、ステップの入出力、エラーなどのデータを 13 の組み込み送信先に送ります。送信先には Amazon CloudWatch Logs、Amazon Athena 向けの Amazon S3、Amazon DynamoDB、Amazon Aurora、Amazon OpenSearch Service が含まれます。TypeScript、Python、Java、Go で利用でき、Lambda durable functions に対応するすべての AWS リージョンで追加料金なしで使えます。 Amazon SageMaker AI の推論がリアルタイムエンドポイント向けの GPU パーティショニングに対応 Amazon SageMaker AI の推論で GPU パーティショニングが利用できるようになり、モデルごとにアクセラレーター全体を専有させる代わりに、1 つの GPU で複数のモデルを実行できます。NVIDIA Multi-Instance GPU (MIG) テクノロジーを使い、SageMaker AI が GPU を最大 7 つの分離されたパーティションに分割します。各パーティションは独自のメモリとコンピュートを持ちます。ファインチューニング済みのバリアント、埋め込みモデル、リランカー、分類器といった小〜中規模のモデルを、サイズに合ったパーティションに配置できます。ハードウェアで分離されるため、負荷の高いモデルが隣のモデルのメモリやスループットを奪うことはありません。推論コンポーネントをホストするエンドポイントの作成時に設定し、モデルは引き続き名前で呼び出すため、アプリケーションコードの変更は不要です。東京リージョンを含む、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド) の P4d、P5、G7、G7e インスタンスで利用できます。 OpenAI の Daybreak Red が AWS GovCloud (米国東部) の Amazon Bedrock で対象のお客様向けに利用可能に OpenAI の Daybreak Red が、AWS GovCloud (米国東部) の Amazon Bedrock で、対象となるお客様向けに利用できるようになりました。OpenAI のサイバー防御イニシアチブ Daybreak の一部である Daybreak Red: GPT-5.6 Cyber は、認可された脆弱性調査、エクスプロイトの再現、緩和策の開発向けに構築されたモデルです。検証済みの防御者が複雑なセキュリティ問題を調査しやすいように、この用途での拒否を減らしています。あわせて、より強固な本人確認、監視、アクセス制御を備えています。Daybreak Red は Bedrock の次世代推論エンジン上で動作し、チップレベルでゼロオペレーターアクセスが適用されます。推論データはモデルの学習に使われず、Daybreak Red のデータを OpenAI と共有する必要もありません。モデルは米国東部 (オハイオ) と AWS GovCloud (米国東部) で提供されます。利用には OpenAI の Daybreak アクセスへの登録が必要です。OpenAI または AWS アカウントチームに適格性を確認し、承認後に AWS アカウントチームとともにアクセスを有効化します。 Web Search が AWS GovCloud (US) の Kiro で利用可能に AWS GovCloud (US) の Kiro で Web Search が利用できるようになりました。Kiro の Web Search では、エージェントがインターネット上の最新情報にリアルタイムでアクセスし、最新の検索結果とページ内容に基づいて回答します。最近の変更や、モデルの学習データの範囲外のトピックに関する質問では、エージェントが自動的に Web Search を使います。Web の結果を使った回答には引用が付きます。Kiro のエンタープライズ管理者は、Kiro コンソールの Settings から組織全体の Web Search と Web Fetch を無効化できます。チームは個々のカスタムエージェントから Web ツールを外したり、機能ベースの権限ルールでブロックしたりすることもできます。詳細は AWS GovCloud (US) のドキュメントとモニタリングおよびトラッキングのガイドに記載されています。 Amazon Bedrock が AWS GovCloud (US) の OpenAI モデルで API サポートを拡張しクロスリージョン推論を導入 AWS GovCloud (US) の Amazon Bedrock で、OpenAI GPT-5.6 モデル (Terra と Luna) が bedrock-runtime エンドポイントに対応し、Responses API、Converse API、Chat Completions API が使えるようになりました。あわせてクロスリージョン推論が追加され、AWS GovCloud (US) の 2 つのリージョン間で推論リクエストが自動的にルーティングされます。複数リージョンの容量を自分で管理することなく、米国のデータ主権を維持しながら、需要のピーク時に高いスループットと冗長性を得られます。ネイティブの OpenAI API が bedrock-runtime 上で動作するため、Bedrock の他のモデルと同じアカウントレベルの制御が適用されます。利用状況は Bedrock のモデル呼び出しログと Amazon CloudWatch メトリクスに記録され、AWS Cost Explorer と AWS Cost and Usage Report でモデル別に費用を把握できます。OpenAI モデルのクロスリージョン推論は、Amazon Bedrock で OpenAI モデルが提供されるすべての AWS リージョンで利用できます。 Kiro Web : セッションの要約、ガイド付きワークフロー、設定の再編 Kiro Web に、セッションごとの短い要約を保持する Session recap が追加されました。Agent Config > Memory で有効にすると、各メッセージの後に会話を要約し、数回のやり取りの後に入力欄の上に Recap が表示されます。サイドバーは、エージェントの挙動を決める Agent Config (Steering、Skills、Workflows、Powers & MCP、Model fallback、Memory など) と、アカウントや環境のための Settings に分かれました。ワークフローでは、プロンプトから作成したワークフローが create-workflow ステップから始まり、不足している情報があれば推測せずに質問します。プランには各ステップのエージェント、モデル、effort、最初のタスクが表示されます。却下後に依頼した変更は承認後のステップに引き継がれます。これまで 3〜5 回実行して失敗していたレビューループは、デフォルトでは 2 回却下された時点で一時停止するようになりました。Automations は Schedule に名称変更され、タスクは scheduled tasks と呼ばれます。再開したセッションは、サンドボックスの起動中も会話を読めて入力欄を使えます。このほか、スキルに含められるファイル数が 25 から 50 に拡大されています。 Kiro IDE 1.4.62 : Windows のシステム全体インストーラー、Shift なしでのファイルドラッグ、枠付きの Mermaid 図 Kiro IDE 1.4.62 では、x64 と ARM64 デバイス向けに Windows のシステム全体インストーラーが追加されました。コンピューター上のすべてのユーザーが Kiro を使えるようになります。インストールには管理者権限が必要です。チャットへのファイル添付は、デスクトップやファイルマネージャーからドラッグするだけで行え、Shift キーを押し続ける必要がなくなりました。対応していないファイル種別の場合は、ファイル名、または複数ならその数とともにエラーが表示されます。チャット内の Mermaid 図はテーマに合わせた枠付きのブロックで表示され、ダークテーマでも矢印が見えます。図の上でのスクロールはチャットのスクロールになり、拡大縮小は Ctrl を押しながらのスクロールかトラックパッドのピンチで行います。ステータスバーのサンドボックス項目は Command sandbox から Sandbox に短縮され、Sandbox: Active や Sandbox: Off のように表示されます。修正では、スラッシュコマンドの直後に入力や貼り付け、音声入力をするとコマンド名と結合して実行されなかった問題が解消されました。Hooks ビューでフックの切り替えに失敗してもエラーが出なかった問題や、同じタイトルのメモリが別リポジトリにある場合に目的のメモリが開けなかった問題も修正されています。 Kiro IDE 1.4.51 : セッション期限切れ後の再接続と Markdown Review でのキーボードによるコメント Kiro IDE 1.4.51 では、IAM Identity Center または AWS Builder ID のセッションが期限切れになったとき、Reconnect を選ぶだけで再サインインできるようになりました。サインイン方法の選択や、Start URL と AWS リージョンの再入力は不要です。ブラウザでのサインイン完了は引き続き必要です。Markdown Review では、テキストを選択するとコメント欄が開く代わりに Comment のプロンプトが表示されるため、Cmd/Ctrl+C で選択範囲をコピーできます。コメントを追加するにはプロンプトを選ぶか、Cmd+Option+M (Windows と Linux では Ctrl+Alt+M) を押すか、入力を始めます。コメントは Enter で保存、Shift+Enter で改行、Cmd/Ctrl+Enter で書きかけのものを含むすべてのコメントを Kiro に送信できます。Generate Commit Message はターミナルでステージした変更も含めるようになりました。修正では、ファイル編集が保存されていないのに成功と報告していた問題が直りました。権限ルールと照合できない bash や PowerShell のコマンドは、承認を求めずにブロックし、エージェントに書き直しを求めるようになっています。 Kiro CLI 2.35.0 : 昇格権限の警告と V3 での組織設定の適用 Kiro CLI 2.35.0 では、macOS と Linux で root として、Windows で Administrator としてセッションを開始した場合に警告が表示されるようになりました。ツール、シェルコマンド、Hooks、MCP サーバーがその権限で動作し、root 所有のファイルを作成したりシステム設定を変更したりする可能性があるためです。警告は動作をブロックせず、意図的に昇格権限で使う場合は kiro-cli settings app.warnOnElevatedPrivileges false で無効化できます。V3 セッションは、組織の Kiro 設定に従って MCP サーバーと web_search 、 web_fetch ツールのオン・オフを切り替えるようになりました。V3 の /mcp は、組織の MCP レジストリによって非表示にされた設定済みサーバーを一覧し、レジストリが提供するサーバーの宣言方法を案内します。修正では、Auto 選択時に拒否応答でターンが終了していた V2 セッションで別のモデルによる再試行が行われるようになったほか、モデルフォールバックやセッション再開、MCP 接続の問題が解消されています。あわせて 10 月 28 日には、性能を改善した 2.35.1 と、オートコンプリート版デスクトップアプリから単体の Kiro CLI への段階的な切り替えを続ける 2.35.2 がリリースされています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、半導体やハイテク産業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。

本ブログは株式会社ドコモSMTBネット銀行 カスタマーサービス部 CS・DX企画グループ 中﨑 敬太様のご協力のもと執筆しました。 コンタクトセンターへの生成 AI 導入は、すでに「試してみる」段階を越えつつあります。導入から数年が経ったコンタクトセンターでよく伺うのは、FAQ の回答精度が思ったほど伸びないという悩みです。窓口を増やすたびに開発が必要になる、利用量が増えたときのコストが読めない、といった二周目の課題もここに重なります。 株式会社ドコモSMTBネット銀行（以下、ドコモSMTBネット銀行）は、生成 AI による自動応対をすでに本番で運用していました。その基盤を Amazon Connect Customer AI agents に移し、2026 年 9 月から電話とチャットの両チャネルで応対を開始しました。本ブログでは、なぜ基盤を移したのか、そして本番導入に向けて何を作り込んだのかをご紹介します。 同社カスタマーセンターにおける AI 活用のあゆみは、2026 年 6 月 26 日の AWS Summit Japan 2026 において、カスタマーサービス部 CS・DX企画グループの中﨑 敬太様が「銀行カスタマーセンターにおける AI 活用の実践と進化」として講演されています。本ブログはその概略を振り返りながら、Amazon Connect Customer AI agents の採用に至る判断と、導入に向けた検証の内容を整理したものです。 ドコモSMTBネット銀行のカスタマーセンター ドコモSMTBネット銀行は 2007 年 9 月に開業したインターネット専業銀行です。モバイルアプリを通じた個人・法人向けサービスに加え、2020 年には邦銀で初めてフルバンキングの BaaS（Banking as a Service）を提供し、多様な業界のパートナーへ銀行機能を提供しています。 同社は 2017 年に「クラウドファースト」の方針を決定し、2018 年にコールセンターシステム、2025 年には勘定系システムを AWS 上に構築することを発表してきました。電話基盤として Amazon Connect Customer を採用したのは 2018 年で、今回の取り組みはその延長線上にあります。 カスタマーセンターでは、電話、お問合せフォーム、チャットの各チャネルを運用し、お客さまからのお問合せを受け付けています。 第 1 世代と第 2 世代で見えたこと 同社が生成 AI の検討を始めたのは 2023 年下期。問題意識は 2 つありました。 ひとつは、ボイスからノンボイスへの移行が頭打ちになっていたこと。問い合わせに占める比率はボイスとノンボイスで 4 対 6 まで進みましたが、そこから先が動きません。IVR（自動音声応答）をさらに作り込む方向では、この壁を越えられないという判断がありました。もうひとつは、目的別に用意した窓口に目的外の入電が多数寄せられていたことです。結果として一次解決率が低下し、オペレーターの負荷も増していました。 そこで 2024 年 8 月、一部の受付窓口で生成 AI（SaaS）による PoC を、実トラフィックを流す本番運用として開始しました。ここで下した割り切りが、その後の展開を支えました。回答文の生成は行わず、コールリーズンの判定と、事前に用意した FAQ の提示だけに機能を限定したのです。生成させなければハルシネーションは起きません。リスクを運用で抑えるのではなく、設計で消しにいった判断でした。あわせて、入力データのオプトアウト機能により自動学習を排除し、個人情報の取り扱いにも配慮しています。 2024 年 10 月には他社の対話型 AI プラットフォームを採用して本格開発に着手し、窓口別の「フロー」を用意してコールリーズン判定で振り分ける構成へ拡張しました。2025 年 6 月に受付窓口と FAQ を広げて本格導入した結果、問い合わせ対応の自動化率が大きく向上し、顧客利便性の向上と運営コストの最適化を両立しています。 図 1 カスタマーセンターにおける生成 AI 適用の変遷 継続課題として残ったのは FAQ 回答精度の向上です。お客さまの照会内容と生成 AI が提示した FAQ を突き合わせて検証し、ヒット率を上げていく地道な改善が要ります。チャットへの展開にも余地がありました。従来のシナリオ型チャットボットでは、お客さまからの多様なお問い合わせへの柔軟な対応や自然な対話の実現に課題がありました。 Amazon Connect Customer AI agents を選んだ理由 第 2 世代の運用を通じて、同社は 3 つの課題を明確に持っていました。Amazon Connect Customer AI agents の採用は、この 3 つに対応する判断です。 自社の AWS 環境内で構築できる 当時は外部の SaaS を利用する構成だったため、お客さまごとの状況に応じた応対を作り込むうえで制約がありました。Amazon Connect Customer AI agents は、すでに稼働している Amazon Connect Customer の環境に AI サービスを追加する形で構成できます。発信者番号やお客さまの属性といった、既存のコンタクトフローで扱っている情報を、そのまま応対の判断材料として使えます。 応対の処理が自社アカウントの中で完結することも、金融機関としては見過ごせない点です。ログの保管やアクセス制御は既存の統制の枠組みをそのまま適用でき、外部サービスとのデータ受け渡しについて個別に整理する手間がなくなります。 AI に任せる範囲とフローで案内する範囲を使い分けられる 従来の構成では、応対の分岐を追加するたびに「開発」が必要でした。Amazon Connect Customer では、意図の理解や FAQ の選択のように自律的な判断を AI agents に任せ、決まった手順どおりに実行したい決定論的な処理はコンタクトフローで組む、という分担ができます。どちらか一方に寄せるのではなく同じ基盤の上で組み合わせられることが、窓口を増やしていく際の開発負荷の軽減につながります。 通話時間とチャット数を基にした料金体系 トークンベースの料金体系では、利用量が増えたときのコストを事前に見積もりにくく、既存の仕組みとの単純比較も困難でした。AI agents は Amazon Connect Customer の料金体系に沿って通話時間とチャット数を基に課金されるため、コンタクトセンターの運用計画と同じ単位でコストを扱えます。 アーキテクチャ 図 2 カスタマーセンターの構成（ダイジェスト版） 構成の中心は Amazon Connect Customer AI agents と、それを呼び出すコンタクトフローです。お客さまが電話をかける、あるいは Web サイトからチャットを開始すると、コンタクトフローが AI agents に処理を渡します。AI agents は自社の FAQ を登録したナレッジベースを参照し、ご用件に応じた回答や次のご案内を返します。 AI agents に持たせているツールは 3 つの役割に分かれます。お客さまの発話や入力からコールリーズンを分類する処理、ナレッジベースから該当する FAQ を検索する処理、検索結果をもとに回答内容を組み立てる処理です。組み立てた結果はコンタクトフローに戻され、フロー側が音声での読み上げ、SMS による Web サイト URL のご案内、有人エージェントへの転送、電話予約のご案内へと振り分けます。 先に挙げた役割分担は、この構成にそのまま表れています。たとえば事故受付のように確実な取り扱いが求められる用件は、AI が分類した時点でフロー側の専用経路に載せます。AI agents の応答が得られない場合に有人転送へ縮退させる経路も、同じ考え方でフロー側に用意しました。 なお、ツールの実行結果をコンタクトフローに返して以降のルーティングをフローに任せるこの形は、Amazon Connect Customer の セルフサービス として提供されている構成です。 PoC で確かめたこと 2026 年 1 月、Amazon Connect Customer AI agents の PoC を実施しました。通話とチャットの両チャネルに対応でき、回答精度は 95% 以上を確認できました。 差がはっきり表れたのは、お客さまの質問が曖昧なケースです。 「キャンペーンについて知りたいんだけど」という問い合わせに対して、同社の従来の構成では複数あるキャンペーンにかかる FAQ のうち、お客さまが本当に知りたいのがどのキャンペーンに関するものか掘り下げることはできませんでした。 AI agents では「どのようなキャンペーンについて、お知りになりたいですか？」と聞き返し、「定期預金のキャンペーンです」という回答を受けてから該当する FAQ を選びます。有人オペレーターが自然に行っている用件の深掘りが、そのまま自動応対の中で成立します。 PoC は、ドコモSMTBネット銀行と AWS が課題管理表で論点を往復しながら進めました。曖昧な質問の聞き返しをどの条件で発生させるか、FAQ の信頼度が低いときに複数候補を提示するか、キーワードによって専用フローへ遷移させるか。こうした論点を、実際にプロンプトを修正して挙動を確認しながら決めています。プロンプトは Amazon Connect Customer の管理画面から編集できるので、試行のサイクルを短く回せました。 応答時間をどう縮めたか 自動応対では、回答が正しいことと同じくらい、待たされないことが体験を左右します。本番導入に向けて、Amazon Connect Customer AI agents の応答時間を検証しました。 お客さまが 1 回発話してから回答が返るまでに、AI agents は 2 回の推論と 1 回のナレッジ検索を行います。発話を分類して FAQ 検索ツールを呼ぶ判断が 1 回目の推論、検索結果から回答の引数を組み立てるのが 2 回目の推論です。この間はお客さまが待っている時間になります。 図 3 お客さまの 1 発話に対する処理の流れ（オレンジは待ち時間の主因となる LLM の推論） 検証で得られた知見は 2 点です。 1 点目は、所要時間が AI agents の出力トークン数にほぼ比例することです。AWS の検証環境で推論時間を出力トークン数で割ると、チャネルや構成を問わず 1 トークンあたり 15〜21 ミリ秒に収まりました。入力側であるナレッジ検索の結果件数を削っても、所要時間はほとんど変わりません。短縮の余地は、LLM に書かせるトークンを減らすことにありました。 2 点目は、AI agents が書いている内容の大半が固定値だったことです。フローに返す引数を項目ごとに分解すると、SMS の定型文や URL のプレフィクス、復唱の定型句など、約 9 割が問い合わせ内容によらない固定値でした。可変なのは FAQ の識別番号と、お客さまのご用件を復唱する部分だけです。 そこで、固定値はコンタクトフロー側で組み立て、AI agents には可変部だけを書かせる構成に見直しました。お客さまに提示される内容は変えないまま、応答時間を短縮できます。ここでも判断の主体をどちらに置くかという線引きが働いています。 なお、ここで示した数値は AWS の検証環境での測定値です。ナレッジベースの内容やコンタクトフローの構成によって変わるため、実際の短縮幅はご自身の環境で測ることをおすすめします。 運用開始後の改善 適切な応対を維持するには、稼働後もプロンプトの調整と精度のモニタリングを続ける必要があります。ドコモSMTBネット銀行は第 2 世代の運用でも、お客さまの照会内容と生成 AI が提示した FAQ を突き合わせて検証し、ヒット率を上げる改善を積み上げてきました。この地道な作業をどれだけ続けやすくできるかが、基盤を移した後のテーマになります。 Amazon Connect Customer には、この改善サイクルを支える機能があります。電話とチャットのやり取りは録音・文字起こしされ、すべてが会話分析の対象になります。そのうえで、AI agents が担当した自己解決のやり取りも、有人オペレーターと同じ枠組みで採点できます。 セルフサービスインタラクションのパフォーマンス評価 では、「お客さまのご用件は AI agents で解決できたか」といった基準を自然言語で評価フォームに定義しておくと、生成 AI が会話を自動で採点し、スコアの根拠とトランスクリプト上の該当箇所まで示します。意図の理解に繰り返し失敗している、お客さまの感情が悪化している、有人転送に至っている、といった観点も評価の対象にできます。 この仕組みを使うと、集計されたダッシュボードで傾向を掴み、気になるコンタクトに降りて録音とトランスクリプトを見ながらやり取りをターンごとに追う、という進め方ができます。どの発話で意図を取り違えたのか、どの FAQ が選ばれたのかが分かるため、直すべきはプロンプトなのかナレッジベースなのかを切り分けられます。生成 AI が下書きした評価を人が確認して確定する運用から始め、精度を確かめながら自動化を広げることもできます。 安定稼働を確認しながら、こうした仕組みを段階的に運用へ組み込んでいくことが次の段階になります。 今後の展開 2026 年 9 月から、電話とチャットの両チャネルで Amazon Connect Customer AI agents による応対を開始しました。まずは安定稼働を優先し、その先ではパーソナライズ機能の追加を検討しています。お客さまごとの状況に応じた自己解決の手段を広げていくことが次のテーマです。 Amazon Connect Customer のセルフサービスは、AI エージェントが複数ステップにまたがって推論し、必要なツールを自ら選んで会話を継続する エージェンティックセルフサービス へと進化しています。今回構築した基盤の上に、こうした機能を段階的に取り込んでいけます。 ドコモSMTBネット銀行からのコメント 今回の取り組みについて、ドコモSMTBネット銀行 執行役員の半田 英二様からは、以下のようなコメントをいただきました。 「当社のカスタマーセンターは、お客さまの『困った』に最短でお応えすることを大切にしてきました。今回の Amazon Connect Customer AI agents の導入は、その姿勢を自動応対の領域へと広げるものです。電話とチャットのどちらでも AI がご用件を的確に汲み取り、必要なときにはオペレーターが引き継ぐ。この組み合わせによって、お客さまの利便性と応対品質を両立させていきます。今後も最先端のテクノロジーを積極的に取り入れ、くらしと金融の境目のない体験の実現に取り組んでまいります。」 本件のシステム開発を担当されている、システム開発部の室 良樹様からは、以下のようなコメントをいただきました。 「今回はカスタマーセンター全体の要件を改めて整理し、電話とチャットの両チャネルを Amazon Connect Customer に集約しました。AI に委ねる領域とコンタクトフローで作り込む領域を分けることで、新しい機能や窓口を同じ基盤に追加していける構成としています。応答時間についても、AWS と共同で処理時間の内訳を切り分け、改善箇所を見極めてまいりました。担当のテクニカルアカウントマネージャーをはじめ、継続的な技術支援をいただいた AWS に感謝いたします。今後もこの基盤の上に最先端のテクノロジーを取り込み、お客さま一人ひとりに応じた応対を広げてまいります。」 まとめ ドコモSMTBネット銀行の取り組みで一貫していたのは、意図の理解のように自律的な判断は AI agents に任せ、確実性が求められる経路や定型文の組み立てといった決定論的な処理はコンタクトフローに寄せるという役割分担です。この線引きが、回答精度だけでなく応答時間と開発負荷にも影響していました。基盤の選定も、すでに稼働している自動応対の実績と残った精度課題を出発点にしています。 生成 AI 導入の二周目に入ったコンタクトセンターへの示唆は 2 つあると考えています。どこまでを AI に任せるかを決めてから基盤を選ぶこと。そして、運用開始後の改善を前提に設計しておくことです。プロンプトを管理画面から編集でき、お客さまのフィードバックを観測できる構成にしておけば、稼働後の精度向上を運用の中で回していけます。 Amazon Connect Customer AI agents については、 製品ページ と 管理者ガイド で機能と設定方法を確認できます。コンタクトセンターの応対高度化についてご相談があれば、担当の AWS メンバーまでお気軽にお声がけください。 著者について 遠藤 亘 (Wataru Endo) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 銀行業界のお客さまを担当しているソリューションアーキテクトです。AWS 全般を活用いただく際の技術的な課題解決に加えて、コンタクトセンターソリューションである Amazon Connect Customer の活用も支援しています。 三木 康次 (Koji Miki) アマゾン ウェブ サービス ジャパン合同会社 シニアテクニカルアカウントマネージャー 金融業界のお客さまを担当するテクニカルアカウントマネージャーです。AWS 利用全般の技術支援を通じて、お客さまのシステムの安定稼働と改善を継続的にご支援しています。 坂田 陽一郎 (Yoichiro Sakata) アマゾン ウェブ サービス ジャパン合同会社 シニアスペシャリストソリューションアーキテクト Amazon Connect Customer を専門とするスペシャリストソリューションアーキテクトです。コンタクトセンターの設計や生成 AI を活用した応対の高度化をご支援しています。

セーフィー株式会社のデータ分析基盤グループでエンジニアをしている渡部です。 セーフィーのデータ分析基盤では、データソースごとにばらばらだったデータ取り込み処理のやり方を揃えるため、Python ライブラリの dlt(data load tool)を採用することとなりました。 dlt は取り込みを実行するだけなので「いつ実行するか？」「失敗にどう気づくか？」の仕組みは別で用意する必要があります。 そこで、オーケストレーションツールとして、Dagster も合わせて導入することとなりました。 現在は、プロダクトの DB から Snowflake へデータを取り込む処理の一部を ECS 上の