はじめに：テレワークの運動不足を「技術」で解決する クラウドエンジニアの皆さん、運動していますか？ 私は毎日リモートワークで、気づけば一日中座りっぱなし……という日が珍しくありません。 「1時間おきに運動すればいい」と分かっていても、自分に甘いのが人間です。そこで思いました。 「サボったらLINEで怒られるシステムを作ればいいのでは？」 と。 しかし、私は普段インフラ設計がメインで、アプリケーションコード（Pythonなど）を書くのは正直苦手です。 そこで今回は、特別な開発ツールは一切使わず、 「Gemini」 と 「Google Cloud Shell」 だけを使って、 完全AI任せ での構築に挑戦しました。 ロジック（コード）: Gemini に書いてもらう インフラ（デプロイ）: Gemini にコマンドを作ってもらい、Cloud Shellに貼り付ける ローカル環境の構築すら不要。ブラウザだけで完結させた記録を共有します。 構想フェーズ：AIを「壁打ち相手」にして要件を固める いきなり作り始める前に、まずは Gemini とチャットをして「どんな構成にするか」を相談しました。 この 「要件定義の壁打ち」 が非常に実りある時間でした。 1. クラウド選定：AWS か Google Cloud か？ 普段業務で使っているのは AWS ですが、今回は個人開発です。 Gemini に相談したところ、 「個人の小規模アプリなら、Cloud Run (Functions Gen2) の無料枠が手厚い Google Cloud がおすすめ」 と提案されました。 また、私自身が最近 Google Cloud認定資格 (PCA: Professional Cloud Architect) を取得したばかりだったので、「得た知識を実際の構築で試してみたい」というモチベーションとも合致し、Google Cloudの採用即決となりました。 2. 入力デバイス：物理ボタン か スマホ か？ 当初は「IoTボタンのような物理デバイスを買おうか」とも悩みましたが、Gemini は 「手持ちの Apple Watch と iPhone のショートカット機能を使えば、追加ハードウェアなしで実現できる」 と提案してくれました。 実はこれ、私にとって渡りに船でした。 ちょうど Apple Watch を買ったばかり で、単なる時計や通知確認以外に「ガジェットとして面白い使い道はないか？」と探していたタイミングだったからです。 作ったもの：サーバーレス・スクワット監視 今回構築したシステムの全体像はこちらです。 処理の流れ Input: Apple Watchの「ショートカット」ボタンをタップ。 Process: Cloud Run functions がリクエストを受け、Firestoreに「スクワット実施ログ」を保存。 Monitoring: Cloud Schedulerが平日9時〜18時の間、1時間おきに巡回。 Notification: 直近1時間にログがなければ、LINE Messaging API経由で 「座りっぱなしです！」 と警告通知。 0. 前準備：土台を整える AIにコードを書かせる前に、データの保存先と通知の宛先だけは用意する必要があります。 1. LINE Messaging API の開設 LINE Developersコンソールでチャネルを作成し、以下の2つを取得して控えておきます。 チャネルアクセストークン（長期） ユーザーID（自分のLINEアカウント宛） ※LINE Messaging APIの具体的な開設手順やコンソールの操作については、過去記事「 Amazon Bedrockでブログ要約をLINE通知する 」で解説しています。設定に迷った場合は、こちらも合わせて参考にしてください。 2. Firestore (データベース) の作成 Google Cloud側でデータを保存する場所を作ります。ここもGUIでポチポチやってもいいのですが、せっかくなので Gemini に頼んでみました。 Geminiへの指示: 「Firestoreをネイティブモードで、東京リージョン(asia-northeast1)に作成するコマンドを教えて」 提示されたコマンドを Cloud Shell に貼り付けて実行し、一瞬でデータベースの準備が完了しました。 # 実際に実行したコマンド gcloud firestore databases create --location=asia-northeast1 ※初めて実行する場合、「APIを有効にしますか？」と聞かれるので Y を押して進めます。 開発フェーズ1：Geminiに「ロジック」を書かせる 土台ができたらアプリケーションのコード（Python）です。 ここでのポイントは、 「自分では1行も書かない」 ことです。 普段ならエディタを開いて「どう書くんだっけ…」と悩みますが、今回は Gemini に向かって、やりたいことをそのまま伝えました。 Geminiへの相談内容: 「Apple Watchからデータを受け取ってFirestoreに保存したい」 「1時間おきにチェックして、データがなかったらLINEに警告を送る機能がほしい」 このように要件を伝えていくと、Gemini はすぐに main.py のコード全文を生成してくれました。 私は内容をざっと見て、おかしなところがないか確認するだけです。 実際に作成されたコードがこちらです。 （※トークン部分は環境変数から読み込むように記述されています） 作成された main.py import os from datetime import datetime, timedelta import pytz import functions_framework from google.cloud import firestore from linebot import LineBotApi from linebot.models import TextSendMessage Firestoreクライアントの初期化 db = firestore.Client() JST = pytz.timezone('Asia/Tokyo') @functions_framework.http def record_squat(request): """ Apple Watchからのリクエストを受け取り、 Firestoreに現在時刻と回数を保存する関数 """ doc_ref = db.collection('squat_logs').document() doc_ref.set({ 'created_at': datetime.now(JST), 'count': 10 }) return 'Squat Recorded!', 200 @functions_framework.http def check_and_notify(request): """ 直近1時間のログを確認し、 運動していなければLINEに通知を送る関数 """ # LINE設定の読み込み（ここで読み込まないとエラーになるため） line_access_token = os.environ.get('LINE_CHANNEL_ACCESS_TOKEN') line_user_id = os.environ.get('LINE_USER_ID') if not line_access_token or not line_user_id: # 環境変数が設定されていない場合はエラーを返す print("Error: LINE configuration not found.") return 'Error: Env vars not set', 500 # トークンがある場合のみ初期化 line_bot_api = LineBotApi(line_access_token) now = datetime.now(JST) one_hour_ago = now - timedelta(hours=1) # 1時間以内のログがあるか検索 docs = db.collection('squat_logs') \ .where('created_at', '>=', one_hour_ago) \ .limit(1) \ .stream() if any(docs): return 'Good Job! You moved.', 200 else: # ログがなければ警告送信 try: line_bot_api.push_message( line_user_id, TextSendMessage(text='⚠️ 座りっぱなしです！スクワットをしてください！') ) return 'Alert Sent', 200 except Exception as e: print(f"LINE Error: {e}") return 'Error sending notification', 500 また、Geminiは必要なライブラリをまとめた requirements.txt も教えてくれました。 これも同じ場所に保存します。これが抜けているとデプロイ時にエラーになるので注意してください。 requirements.txt google-cloud-firestore line-bot-sdk functions-framework pytz 【Tips】Cloud Shell エディタを使うと便利 ファイルの作成は、ターミナルでコマンドを叩かなくても大丈夫です。 画面上部にある 「エディタを開く（鉛筆アイコン）」 をクリックすると、VS Codeのような画面が開きます。 そこで右クリックして「新しいファイル」を作成し、上記のコードを貼り付けるのが一番カンタンです。 開発フェーズ2：Geminiで「インフラ」を作る コードができたらデプロイです。 ここでは、Geminiに生成してもらったコマンドを少し調整して、 「記録用」 と 「監視用」 の2つの関数をデプロイしました。 1. 記録用関数のデプロイ Apple Watchから叩かれる関数です。認証なしでアクセスできるように設定します。 gcloud functions deploy record-squat --gen2 --runtime=python311 --region=asia-northeast1 --source=. --entry-point=record_squat --trigger-http --allow-unauthenticated ※途中「APIを有効にしますか？」と聞かれたら Y で進めてください。 2. 監視用関数のデプロイ こちらはLINEへの通知機能を持つため、環境変数でトークンを渡します。 （※コマンド内の [YOUR_TOKEN] などの部分は、前準備で控えた自分の値に書き換えて実行してください） gcloud functions deploy check-and-notify --gen2 --runtime=python311 --region=asia-northeast1 --source=. --entry-point=check_and_notify --trigger-http --allow-unauthenticated --set-env-vars LINE_CHANNEL_ACCESS_TOKEN="[YOUR_TOKEN]",LINE_USER_ID="[YOUR_ID]" 【Tips】Cloud Functions と Cloud Run の関係 デプロイ完了後、コンソールを確認して少し驚きました。 「Cloud Functions」を作ったはずが、 「Cloud Run」 のサービス一覧に表示されていたからです。 実はこれ、現在の Google Cloud の仕様です。 第2世代の Functions (Gen2) は、裏側の実体が Cloud Run で動いています。そのため、名称も現在は Cloud Run functions となっており、このように Cloud Run の管理画面からも「関数」として確認できるのです。 3. 定期実行（Cloud Scheduler）の設定 最後に、監視用関数を「平日の9時〜18時の間、1時間おき」に実行するジョブを作成しました。 （※ uri の部分は、 check-and-notify のデプロイ後に表示されたURLを入れてください） gcloud scheduler jobs create http squat-police-job --schedule="0 9-18 * * 1-5" --time-zone="Asia/Tokyo" --uri="[監視用関数 check-and-notify のURL]" --http-method=GET 次のステップへの準備：URLをコピーする すべてのデプロイが完了したら、Apple Watch用に 「記録用関数 (record-squat)」のURL を控えておきます。 （Cloud Run のサービス詳細画面で、 record-squat の名前の下にあるURLをコピーするのが簡単です） 連携設定：物理世界とクラウドを繋ぐ バックエンドができたら、あとはApple Watchの設定です。 iPhoneの「ショートカット」アプリを開き、新しいショートカットを作成します。 使うアクションは 「URLの内容を取得」 です。 URL: 先ほどコピーした record-squat のURL 方法 (Method): POST に変更（これをしないと動きません！） これを「Apple Watchに表示」設定にするだけで、手首に 「スクワット完了ボタン」 が出現します。 結果：こうなりました 実際に運用してみた様子がこちらです。 1. サボった時 1時間以上ボタンを押さないと、Cloud Schedulerが作動し、容赦なくLINEが飛んできます。(※画像はテスト通知時の画面です) 2. ちゃんと運動した時 スクワットをしてApple Watchのボタンを押すと、Firestoreにデータが保存されます。 データもバッチリ届いています。 このログがある限り、次の監視タイミングでは通知がスキップされます。 「LINE通知を止めるためにスクワットをする」 という、奇妙ですが強力な習慣化サイクルが完成しました。 まとめ：インフラエンジニアこそAIを使うべき 今回、簡単なアプリ構築を通して感じたことは以下の3点です。 ブラウザひとつで開発が完結する Cloud ShellとGeminiさえあれば、環境構築もコーディングもデプロイもすべて完結します。 インフラ操作は「対話」で行う時代へ CLIコマンドを暗記しなくても、やりたいことを伝えれば適切なコマンドが出てきます。 サーバーレス × 個人開発の相性の良さ 今回の構成（Cloud Run functions + Firestore）なら、個人利用レベルではほぼ 無料 です。 AWSエンジニアの私にとって、Google Cloudの Cloud Shell の手軽さと、Geminiによる的確なコマンド支援は強力な武器になると感じました。 皆さんも、AIを相棒にして「自分専用の便利ツール」を作ってみてはいかがでしょうか？

はじめに コンタクトセンター管理者は、本番環境を中断することなく、コンタクトフローを効率的にテストと検証するという課題に直面しています。従来のアプローチ、例えば手動でシステムに電話をかける、カスタム検証ツールを構築する、サードパーティソリューションに投資するような手段は、時間とコストがかかります。大企業では、年間予算の大部分が自動テストツールに割り当てられることも多く、一方で手動検証を用いる場合は変更ごとに数日から数週間の作業が必要になることがあります。Amazon Connect が高度な AI 機能で進化するにつれて、サービス品質と顧客満足度を維持するための効率的なテスト戦略がさらに重要になっています。 Amazon Connect はネイティブコールシミュレーション機能の一般提供を発表しました。組み込まれたこのテストソリューションは、検証時間と作業を大幅に削減しながら、コンタクトセンター設計への信頼性を高めます。外部ツールや手動での電話テストなしでコンタクトセンターワークフローを自動的にテストでき、チームはイノベーションと優れた顧客体験の提供に集中できます。 本記事で学べること 本記事では、Amazon Connect の新しいテスト機能を活用してコンタクトセンターの検証を自動化する方法を説明します。次のことを学べます。 直感的なビジュアルデザイナーでテストケースを設定する 自然な顧客インタラクションを反映したテストシナリオを作成する 自動テストを実行し、結果を分析して継続的な改善を行う テストフレームワークの概要 Amazon Connect のテストとシミュレーションフレームワークは、直感的なビジュアルインターフェースでコンタクトセンター体験を検証できます。ステップバイステップのガイドと複雑な遷移による従来のテストアプローチとは異なり、顧客が実際にコンタクトセンターとやり取りする方法を反映した、自然でユーザーフレンドリーなものです。 イベント駆動型テストモデル フレームワークのコアにはイベント駆動型モデルを使用しています。コンタクトフロー実装の深い技術知識による記述ではなく、「X が発生したら Y を実行する」という観点でテストを記述します。例: 「IVR が『エージェントと話すには 1 を押すか、エージェントと言ってください』と再生したら、顧客は 1 を押すか、エージェントと言う必要があります。」 これには 3 つの直感的な概念を活用します。 Observations (監視): 期待されるシステムイベントと対応するアクションを含む完全なインタラクション Events (イベント): システムから期待される特定の動作 (プロンプト、ボットメッセージ、Lambda 関数呼び出し) Actions (アクション): テストフレームワークが応答としてシミュレートすべきこと (顧客入力、属性検証、リソースモック) イベント駆動型モデルは大きなメリットをもたらします。技術者以外のチームメンバーでもテストを簡単に理解して作成でき、QA チームにとっては最小限のトレーニングで済ませられ、フレームワークによってプロセスをアクセスしやすく保ちながら技術的な精度を維持できます。 ビジュアルテストデザイナーインターフェース デザイナーは、インタラクショングループを使用してテストシナリオを視覚的に構築できるインターフェースです。各インタラクショングループは、期待される動作とシミュレートされたアクションの完全なシーケンスを表し、テストフローを一目で把握できます。ビジュアルアプローチにより学習にかかる時間が短縮され、チームメンバーは基礎となる技術実装の詳細を理解することなくテストを作成できます。 テスト分析とダッシュボード Amazon Connect は、 分析と最適化 > ダッシュボードとレポート > テストおよびシミュレーションダッシュボード からアクセスできる専用のテストとシミュレーションダッシュボードを提供します。ダッシュボードでは以下のようなテスト実行履歴の詳細な洞察が得られます。 全体的なテスト成功率を示すサマリーメトリクス 一般的な問題を特定するための失敗タイプの内訳 パフォーマンス分析のための実行時間メトリクス 時間の経過に伴う改善を追跡するための日付範囲フィルタリング テストケースの作成 効果的なテストケースの構築には、3 つの主要なステップがあります。基本的なテスト設定の構成、インタラクショングループを使用したテストフローの設計、観察およびシミュレートする特定の動作の定義です。 テスト設定とパラメータの構成 テストケース管理ページ（ ルーティング > テスト ）で テストを作成 をクリックして、新しいテストケースを作成します。 設定 タブで次を構成します。 開始点 : 特定のフローまたは電話番号 チャンネル : 音声通話 着信電話番号 : シミュレートされる発信者の電話番号 属性 : プロファイル情報などのユーザー定義コンタクト属性 インタラクショングループの構築 デザイナー タブで、インタラクショングループのテストフローを構築します。各グループは、何かが発生することを期待し、そのイベントを検証または応答する必要がある瞬間を表します。 + 新しいインタラクション ボタンでインタラクショングループを追加し、それらを接続して完全なテストケースフローを定義します。 Observation、Check、Action ブロックの設定 各インタラクショングループには、最大 3 つのブロックタイプが含まれます。 Observe ブロック (必須) : 「Test started(テスト開始)」、「Message received(メッセージ受信)」、「Action triggered(アクション呼び出し)」などの期待されるシステムイベントを定義します。メッセージベースの観察の場合、メッセージの内容が一致するか確認するために次のいずれかを選択できます。 Contains : 実際のメッセージに指定されたテキストが含まれているかどうかをチェックします (部分一致) Similar : セマンティックな類似性のための高度な比較を使用します (意味的一致) ※訳注 ブログ翻訳時点では Observe ブロックは英語で受信されるメッセージをサポートしています。詳しくは ドキュメント をご覧ください。 Check (チェック)ブロック (オプション) : コンタクトジャーニーのその時点で、特定の属性に期待される値が含まれているか検証します。名前空間 (System、User defined、Segment Attributes など)、属性キー、期待値を指定して属性検証を構成します。 Action ブロック (オプション) : 観察されたイベントに応答してフレームワークがシミュレートすべきことを定義します。 Mock resource behavior : 連携している Lambda 関数からの応答や、 Hours of Operation (オペレーション時間)、Queue(キュー)、Lex bot などのリソースをテスト用の代替リソースに置き換えることができます Send instruction : 顧客入力をシミュレートします (DTMF トーン、テキスト発話、通話切断) Test commands : 属性のログ記録やテストの終了などのユーティリティです セルフサービスとキュー体験のテスト: 実践例 コンタクトセンターフローをテストすることで、顧客が一貫性のある信頼性の高い体験を受けられるようになります。このセクションでは、一般的なシナリオのテストについて説明します。既存の顧客が営業時間内に電話をかけてエージェントに到達するケースです。 顧客体験 フローは次のように動作します。 Lambda 関数が着信電話番号で顧客のタイプを確認します。 システムがウェルカムプロンプトを再生し、顧客にエージェントに到達するためには 1 を押すように求めます。 入力を受信した後、顧客は確認メッセージを聞きます。 システムは、エージェントが対応可能になるまで、保留音楽付きのキューに顧客を転送します。 テストケースの構築 体験を検証するために、3 つのインタラクショングループを持つテストケースを作成します。 テスト設定の構成 シミュレートするフローを選択し、顧客の識別情報として着信電話番号を入力します。 インタラクショングループ 1: テストの初期化 テストのセットアップと営業時間のオーバーライドを処理します。 Observe ブロック : イベントタイプとして「Test started」を選択します。テストが開始されるとすぐに実行されます。 Action ブロック : Hours of Operation リソースのオーバーライドを構成します。テストを実行するタイミングに関係なく、営業時間内であるかのようにテストが実行されます。フローの Hours of Operation リソースを選択し、フローで営業時間チェックが呼び出されたときに「営業時間内」になるように応答をモックするか、常に営業中の代替リソースを指定します。 インタラクショングループ 2: ウェルカムプロンプトの検証 ウェルカムプロンプトを検証し、顧客入力をシミュレートします。 Observe ブロック : Event の種類: 「Message received」 Actor: 「System」(デフォルト。プロンプトはコンタクトフローから発信されるため) Expected text: 「Press 1 to be connected to an agent(エージェントに接続するには、1 を押してください)」 Matching criteria: 「Similar」 Action ブロック : 顧客が 1 を押すことをシミュレートする「Send instruction」アクションを構成します。 Response type: 「DTMF Input」 Input value: 「1」 インタラクショングループ 3: キューの検証 キューへの配置を検証し、テストを終了します。 Observe ブロック : 期待される確認メッセージを指定します。「Thank you for calling. Your call is very important to us and will be answered in the order it was received.(お電話ありがとうございました。お客様からの声は重要です。順番におつなぎしますのでお待ちください。)」 Check ブロック : System 名前空間の「Queue Name」属性を期待値 (例: 「Agent Queue」) と照合して、正しいキューに転送されたかを検証します。 Action ブロック : 2 つの「Test commands」アクションを追加します。 Log data : テスト実行の詳細で分析するために関連する属性をキャプチャします End test : テストケースの実行を終了します テストの実行 すべてのインタラクショングループを構成した後、3 つのインタラクショングループが順番に接続されていることを確認します。その後、テストケースを保存して公開し、実行できる状態にします。 テストの実行と分析 テストケースの実行 テストデザイナーから テストを実行 ボタンで直接テストを実行するか、テストケース管理ページからバッチ実行できます。Amazon Connect は、インスタンスごとに最大 5 つの同時テスト実行をサポートし、追加のテストは自動的にキューに入れられます。主要な変更をテストして結果を取得してから、時間がかかる可能性のあるリグレッションテストを実行できます。 結果の監視とレビュー テスト実行 タブでテストの進行状況をリアルタイムで監視します。詳細な結果ページには、次のような詳細なビューを確認できます。 全体的なテストパフォーマンスを要約するセッションメトリクス インタラクショングループの完了率と合格/不合格の統計、および合計シミュレーション時間 初期セットアップ、テスト開始、インタラクション、テスト完了を含む詳細なテスト実行ステップ 各 observe ブロック、check ブロック、action ブロックの実行の詳細 失敗したテストのトラブルシューティング テストが失敗した場合、詳細な結果ページには、どの特定のインタラクションまたはブロックが失敗したかが示されます。次の情報を確認できます。 失敗した observe ブロックの期待されるイベントと実際のイベント 失敗した check ブロックの属性検証の詳細 アクション失敗の理由と試行された操作 完全な音声録音とトランスクリプション (有効な場合) 利用を始めるには ベストプラクティス 整理 : 「一般的な顧客 – 営業時間中 – エージェントへ転送」のように、明確でわかりやすいテスト名を使用します。タグを活用して、機能領域、顧客タイプ、優先度レベルごとにテストを分類します。 レジリエンス : 可能な限りプロンプトにセマンティックマッチングを使用して、わずかな文言の変更に対応できるようにします。時間依存のリソースをオーバーライドして、テストを実行するタイミングに関係なく一貫したテスト実行を定義します。 優先順位付け : 重要なカスタマージャーニーを最初に優先します。エージェント転送、一般的なセルフサービスシナリオ、営業時間外の体験です。最も重要な機能から常に検証していきます。 統合 : テストをデプロイメントプロセスに組み込みます。コンタクトフローの変更をデプロイする前に関連するテストケースを実行して、顧客に影響を与える前に問題を発見します。 その他のテストシナリオの例 営業時間外のテスト : 営業時間外に電話をかけることをシミュレートするテストを構成し、適切なクローズメッセージとコールバックオプションを検証します。 セルフサービスの検証 : 顧客が IVR メニューをナビゲートし、DTMF または音声でアカウント情報を提供し、期待される結果に到達することをシミュレートするテストを作成します。 認証された顧客体験 : 認証された顧客に対する差別化された処理をテストします。優先キュー配置や専門エージェントルーティングなどです。 コールバックシナリオ : 待ち時間が長い場合のコールバックオプションを検証します。番号の収集と確認プロセスを含みます。 まとめ Amazon Connect のネイティブなコールシミュレーション機能は、コンタクトセンター体験を検証および維持する方法を変革します。テストケースを迅速に作成し、オンデマンドに、あるいはデプロイメントプロセスの一部として実行し、継続的な改善を推進する洞察を得ることができます。 Amazon Connect インスタンスで今すぐこれらのテスト機能をお試しください。最も重要なカスタマージャーニーの重要なテストケースから始め、時間の経過とともにカバレッジを拡大し、テストダッシュボードを活用して進捗状況を追跡すれば、最適化の機会を特定できます。 詳細なドキュメントと実装のガイドは、 Amazon Connect 管理者ガイド および Amazon Connect API Reference をご覧ください。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

みなさん、明けましておめでとうございます！AWS ソリューションアーキテクトの野間です。　2026年最初の週刊生成AIです。 午年の2026年がスタートしました。馬が疾走するように、生成AI の世界も驚くべきスピードで進化しています。昨年は基盤モデルの飛躍的な性能向上やエンタープライズ活用の本格化など、大きな進展がありました。今年はその勢いがさらに加速し、現場で使える実践的なソリューションがどんどん生まれる年になりそうですね。技術の進歩速きこと駿馬の如し。これを見極め、適切に活用する智慧こそが求められる時節なり。（孔明風） 馬が千里の道を駆けるように、生成AIの可能性も限りなく広がっています。今年もこのブログが、皆さまの生成AI活用の道しるべとなれば嬉しいです。では今週も生成 AI with AWS界隈のニュースを見ていきましょう！（今号は年末年始のアップデートを含めてお届けします） さまざまなニュース AWS生成AI国内事例ブログ「人に依存しないCRMによりEC事業者のLTV最大化を実現 Amazon Bedrock AgentCoreを活用したAIオートパイロット型CRM開発事例」 EC 事業者の CRM 運用効率化についての生成 AI 活用事例です。株式会社ダイレクトマーケティングエージェンシー（DMA）が、EC 業界における CRM 運用の属人化、短期的施策への偏重、データ統合の複雑さといった構造的課題を解決するため、Amazon Bedrock AgentCore を中核に据えた AI オートパイロット型 CRM プラットフォーム「リピートMAX」を開発しました。このプラットフォームは、Amazon S3 および Amazon Redshift Serverless に蓄積された顧客行動データを基に AgentCore 上の AI エージェントが推論を行い、その結果をデータレイクへフィードバックする循環型アーキテクチャを採用しています。ターゲティングからクリエイティブ生成、売上予測、事後検証まで全ての CRM プロセスを対話形式で実行でき、大手百貨店 EC サイトでの導入により、リピート購入率が 125% 向上、離脱予兆顧客の CVR が 150% 以上改善、CRM 運用工数が約 1 時間まで効率化という具体的な成果を上げています。担当者のスキルに依存せず、顧客行動を文脈として理解し状況に応じて判断を変える高度な CRM 施策を自動化できる点が大きな特徴です。EC 事業者で CRM の効率化や LTV 向上に取り組まれている方、生成 AI を活用したマーケティング自動化に関心のある方は、ぜひこの実践的な事例をご覧ください。 AWS生成AI国内事例ブログ「株式会社サンブリッジ様のAWS生成AI事例「採用担当向け育成 AI コーチの構築により育成業務の一部を自動化し、年間 360 時間の工数削減と育成の質の高度化を実現」のご紹介」 採用業務の効率化に生成 AI を活用した事例です。株式会社サンブリッジが、年間 720 回にのぼる採用面接の半数以上に CEO が関与し、採用担当者の育成に大きな負荷がかかっていた課題を、Amazon Bedrock を活用した採用担当向け育成 AI コーチで解決しました。この AI コーチは、Bedrock の大規模言語モデルを活用した対話型チャットボットに CEO の判断ポイントや候補者との向き合い方を学習させ、Slack と連携してナレッジを継続的に更新できる仕組みと、RAG を利用したテスト機能で理解度を定量的に把握できる機能を備えています。特筆すべきは、AI コーディングアシスタントも活用することで、新人エンジニア 1 名がわずか 2 週間でシステム全体を構築できたという開発効率の高さです。導入後は、CEO の面接同席負担が半減し年間 360 時間の削減を実現したほか、年間 280 回の質問機会で CEO 視点の回答を提供できるようになり、採用担当者によるばらつきも解消されました。採用業務の属人化や育成負荷に課題を感じている企業、限られたリソースで高品質な採用活動を実現したい方は、ぜひこの具体的な実装手法と成果をご確認ください。 AWS生成AI国内事例ブログ「株式会社アド・ダイセンが生成 AI で実現した現場主導の業務効率化：非技術者による生成 AI 活用の実践」 このブログでは、ダイレクトメール事業を手がける株式会社アド・ダイセンが、 Generative AI Usecases (GenU) と Kiro を活用し、現場の非技術者が主導して業務効率化と DX を推進した事例を紹介しています。 議事録作成や画像判定、営業数字分析に加え、出荷日から逆算したスケジュール自動生成や配送シミュレーションなど、従来は数時間〜丸2日かかっていた事務・シミュレーション作業を数分〜数十秒に短縮し、人的ミス削減と品質向上を両立しながら「現場が自分たちでツールを作れる」体制を築ける点が大きな価値となっています。GenU のチャットとビルダーモード、Kiro の IDE＋Agentic AI によって、「このデータをこう処理したい」という自然言語の要件からコード生成・修正・実行まで対話的に進められるため、専門エンジニアに依存せず高度なツール開発が可能となり、成熟業界でもマニュアルワーカーからナレッジワーカーへのシフトとイノベーション文化の醸成を加速できる点が価値として示されています。エンジニアリソースの制約がある中で現場主導の DX を推進したい方、生成 AI で業務効率化を実現したい方は、ぜひこの実践的な成功事例をご確認ください。 AWS生成AI事例ブログ「smart EuropeがAmazon Bedrockでカスタマーサポート業務を変革した方法」 自動車業界のカスタマーサポート業務に革新をもたらした生成 AI 活用事例です。電気自動車メーカーの smart Europe は、製品の頻繁なリリースや OTA によるソフトウェアアップデートに伴うサポート問い合わせの急激な増加、解決時間の増大、サービス品質のばらつきといった課題に直面していました。これらの課題を解決するため、AWS と協力して smart.AI Case Handler という生成 AI ソリューションを開発し、わずか 4 人の開発者で 3 か月という短期間で実現しました。このソリューションは、Amazon Bedrock を中核に Amazon EventBridge、Amazon SQS、AWS Lambda、AWS Step Functions、Amazon Aurora などを組み合わせたサーバーレスアーキテクチャで構築され、2 つの補完的なワークフロー（問い合わせケースの自動タグ付けと AI によるインサイト生成）が連携して動作します。サポート担当者が Salesforce で問い合わせを開くと、AI が生成した概要、類似の過去事例、ナレッジベースの抜粋、顧客への回答案が即座に提示される仕組みです。実装にあたっては、担当者の待ち時間を解消する先回りした処理、Amazon SQS による API スロットリング対策、不要な更新を除外するフィルタリング機構といった工夫により、問い合わせ解決時間を 40% 短縮、ファーストコンタクトによる解決が 20% 増加、10,000 件超の問い合わせを処理し、2025 年の当初計画予算から 30% の節約を見込むという大きな成果を上げています。自動車業界でサポート業務の効率化や顧客満足度向上に取り組まれている方は、ぜひこの詳細な実装事例をご覧ください。 イベントレポート「第 45 回 医療情報学連合大会 (JCMI 45th) 出展レポート」 2025 年 11 月に開催された第 45 回医療情報学連合大会において、AWS は「生成 AI とヘルステックの融合が拓く、次世代の医療サービス」をテーマにスポンサードセッションと展示ブースを通じて医療 DX と生成 AI 活用の最新動向を共有しました。セッションでは、Amazon Bedrock を中核とした医療機関向けサービスが紹介され、日本国内に限定したクロスリージョン推論により医療情報ガイドラインへの準拠をサポートすることが示されました。特に注目されたのが Agentic AI で、従来の Chatbot や RAG を超えて、診療記録の作成や検査オーダーなど複雑なタスクを自律的に実行できる可能性が説明されました。株式会社メドレーからは、診察中の発話をリアルタイムで文字起こしし AI が自動要約する実証実験が紹介され、カルテ作成時間を約 11.3% 削減し、医師が「メモを取ることに集中しなくてよい」という安心感により患者との対話により集中できる環境を実現したことが報告されました。展示ブースでは Amazon Quick Suite のデモとともに、ANGEL Dojo という内製化支援プログラムの成果が紹介され、兵庫県立リハビリテーション中央病院では IT 知識ゼロの総務部の方が 90 日間でスケジュール作成時間を 80% 短縮し 60% の自動化を実現し、熊本中央病院では月 800 時間の文書作成時間削減を達成しました。生成 AI を活用することで、医療従事者は業務効率化を実現しながら、患者体験の向上にも貢献でき、適切な支援とパートナーシップがあれば IT 知識がなくても医療機関自らが生成 AI システムを構築できることが示されました。 イベントレポート「【開催報告】通信ネットワーク運用向け AI エージェントワークショップ開催しました！ ( 2025 年 11 月 27 日 )」 通信ネットワークの運用業務に AI エージェントを活用したい方に必見のワークショップ開催レポートです。2025 年 11 月 27 日に開催されたこのイベントには、96 名/ 14 社の通信業界の方々が参加し、AI エージェントの実践的な活用方法を学びました。ワークショップでは、NTTドコモから docomo MEC のオプションサービス MECダイレクトにおける Amazon Bedrock エージェントの活用事例が紹介され、監視措置業務の自律的実行により、アラート受信から分析、措置手順の提案までの自動化を実現した実績が共有されました。参加者は Strands Agents を使ったハンズオンで数行のコードで AI エージェントを構築する方法を体験し、通信ネットワーク運用 AI エージェント実践編では、Amazon Neptune をベースにした複数の専門エージェント（Orchestration、Observability、ナレッジ、チケット管理、RCA）が連携する本格的なシステムを実際に操作しました。アラーム分析から根本原因の特定、ServiceNow へのチケット起票まで、実務に即したシナリオを通じて AI エージェントの可能性を体感できる内容となっています。通信業界で Autonomous Network の実現を目指す方、ネットワーク運用の自動化・高度化に関心のある方は、ぜひこのブログで詳細な技術解説とハンズオンの様子をご確認ください。 ブログ記事「PartyRock の保護：AWS WAF を利用した Amazon Bedrock エンドポイントを保護する方法」 AWS WAF を利用して分散型サービス拒否 (DDoS) 攻撃や Wallet 拒否攻撃 (DoW) のような潜在的な脅威から PartyRock を保護した方法を解説します。生成 AI アプリケーションのセキュリティ設計や AWS WAF の実践的な活用方法を学びたい方は、ぜひこの詳細な実装事例をご覧ください。 ブログ記事「Amazon Bedrock は、新しい Mistral Large 3 モデルと Ministral 3 モデルを含む 18 のフルマネージドオープンウェイトモデルを追加します」 Amazon Bedrock が、Google、Moonshot AI、MiniMax AI、Mistral AI、NVIDIA、OpenAI、Qwen から 18 種類の新しいフルマネージドオープンウェイトモデルを追加し、合計で 100 近くのサーバーレスモデルを提供するようになりました。新たに追加された Mistral Large 3 は、ロングコンテキスト、マルチモーダル、エージェントワークフローに最適化されており、Ministral 3 シリーズ（3B、8B、14B）はエッジデプロイ向けに最適化された軽量モデルとして、画像キャプション、リアルタイム翻訳、ローカル AI アシスタントなどに活用できます。 ブログ記事「2D から 3D へ: Amazon SageMaker AI を使用したスケーラブルなヒューマンメッシュリカバリパイプラインの構築」 コンピュータグラフィックスとアニメーションの分野で注目される、動画データから現実的な 3D ヒューマンアニメーションを生成する技術が詳しく解説されています。従来は専用ハードウェアと複雑なソフトウェアパイプラインが必要だったヒューマンメッシュリカバリ（HMR）を、Amazon SageMaker AI を中心とした AWS サーバーレスアーキテクチャでスケーラブルに実現する方法が紹介されています。中核となる ScoreHMR は、従来の最適化技術とは異なり拡散モデルを使用して入力画像から人体パラメータを再構築し、遮蔽された状況や困難な条件下でも高精度な結果を実現します。パイプラインは AWS Lambda、Amazon S3、Amazon SQS、Amazon SageMaker AI の非同期エンドポイントを組み合わせて設計され、リクエストがない時はインスタンス数をゼロにスケールしてコストを節約しながら、トラフィックに応じて自動的にスケールする仕組みになっています。出力される 3D メッシュ、ベクトルキーポイントデータ、カメラポーズ情報は任意の 3D アプリケーションで利用でき、没入型フィットネス体験、映画制作、デジタルコンテンツ制作など幅広い用途に活用できます。動画からの 3D ヒューマンアニメーション生成に興味がある方、コンテンツ制作の自動化を検討されている方は、ぜひこの技術的な実装詳細をご確認ください。 ブログ記事「AWS AI League: モデルカスタマイゼーションとエージェント対決」 AWS AI League は、Agentic AI とモデルカスタマイゼーションの分野でイノベーションを促進する、企業向けのコンペティションプログラムです。2026 年チャンピオンシップでは、Amazon Bedrock AgentCore を使用してインテリジェントエージェントを構築する「エージェンティック AI チャレンジ」と、SageMaker Studio の最新ファインチューニングレシピを活用して特定ユースケース向けにモデルをカスタマイズする「モデルカスタマイゼーションチャレンジ」という 2 つの新しいチャレンジが導入されました。この記事では、AWS AI League プログラムを使用して AI コンペティションを開催する方法について説明します。AI スキルを実践的に磨きたい方、社内で AI コンペティションを開催したい企業は、ぜひこのプログラムの詳細をご確認ください。 ブログ記事「回復力のあるサプライチェーンの構築: Amazon Bedrock を活用した小売・消費財向けマルチエージェント AI アーキテクチャー」 小売・消費財企業が直面する港湾閉鎖や気象現象などのサプライチェーン混乱に対し、Amazon Bedrock AgentCore のマルチエージェント協調機能を活用したリアルタイム対応システムを紹介しています。このアーキテクチャは、スーパーバイザーエージェントが混乱を分析してタスクを委任し、物流最適化エージェント、在庫エージェント、プロモーションリスクエージェント、出荷追跡エージェントといった専門エージェントが協調して作業することで、従来は手動で数時間かかっていた分析を数分以内に完了させます。生成 AI を活用することで、サプライチェーンの混乱を危機から管理可能なイベントに変換し、複数の同時混乱を追加人員なしで処理できるため、小売・消費財企業は市場シェアを守りながらビジネスの継続性を確保できます。 ブログ記事「AWS IoT Greengrass と Strands Agents を使用した Small Language Model の大規模デプロイ」 製造業では、セキュリティとパフォーマンスの基準を維持しながらリアルタイムの運用データに応答するインテリジェントな意思決定システムの実装が課題となっており、Small Language Models (SLM) が解決策として注目されています。SLM は約 30 億から 150 億のパラメータを持ち、軽量でありながら、コンテキストを理解した洞察を提供できるため、リソースが限られた工場環境に最適です。このブログでは、AWS IoT Greengrass を使用して SLM を Greengrass コンポーネントとして OPC-UA ゲートウェイに直接デプロイし、Strands Agents がローカルエージェント機能を提供する実装方法が詳しく解説されています。エッジで AI エージェントを実装したい方、IoT デバイスに生成 AI を組み込みたい方は、ぜひこの実践的な実装ガイドをご確認ください。 ブログ記事「Amazon Bedrock は ISMAP の言明対象であることについての考え方」 2026 年 1 月 9 日、ISMAP ポータルサイトに重要な更新があり、生成 AI 開発基盤が ISMAP に登録されている場合、その上で動作する個々の生成 AI モデルは必ずしも ISMAP に個別登録されている必要はないという見解が示されました。ISMAP は政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図る制度で、政府情報システムにおいてクラウドサービスを利用する際には原則として ISMAP に登録されたサービスを選定することが求められています。Amazon Bedrock は生成 AI 開発基盤として ISMAP の言明対象範囲に含まれており、生成 AI モデルが AWS の内部環境に持ち込まれているため、お客様のデータが生成 AI モデル開発事業者に提供されることはなく、モデル学習にも使用されません。Guardrails for Amazon Bedrock による有害コンテンツのフィルタリング、モデル評価機能、AWS CloudTrail によるアクセスログ記録など、生成 AI 特有のリスクへの対応機能も提供されています。政府機関や公共セクターで、セキュリティ要件を満たしながら生成 AI を活用したい方は、ぜひこの制度更新の解説をご確認ください。 ブログ記事「Kiro のマルチルートワークスペース：1 つのプロジェクト内だけでなく、複数のプロジェクトにまたがって作業する」 このブログでは、 Kiro の新しいマルチルートワークスペース機能により、複数のプロジェクトを単一の IDE ウィンドウで効率的に管理する方法をお伝えします。共有ライブラリとメインアプリケーション、複数のマイクロサービス、モノレポのパッケージなど、関連するプロジェクトを同時に編集する際の課題を解決し、各ルートが独立性を保ちながら統合された開発環境を提供する仕組みと、その設定方法や実際の活用例を詳しく説明します。 ブログ記事「プロパティベーステストが見つけた、私が決して発見できなかったセキュリティバグ」 このブログでは、 Kiro の仕様駆動開発ワークフローを使用したチャットアプリケーション開発において、プロパティベーステスト（PBT）が従来のテスト手法では発見困難なセキュリティバグをどのように発見したかをお伝えします。75 回目のテスト反復で proto というプロバイダー名が JavaScript プロトタイプの誤った処理を露呈し、ランダム生成による体系的な入力空間の探索が、手動コードレビューや単体テストでは見逃されるエッジケースを効果的に発見できることを実例とともに紹介します。 サービスアップデート AWS Neuron SDK 2.27.0 の発表 AWS Neuron SDK 2.27.0 がリリースされ、Trainium3 UltraServer のサポートとオープンソースコンポーネントの拡張が追加されました。今回のアップデートでは、Neuron Explorer ツールスイートや MLIR ベースの Enhanced NKI（プライベートベータ）、最適化されたカーネルを集めた NKI ライブラリに加え、TorchNeuron によるネイティブ PyTorch サポート（プライベートベータ）、Kubernetes ネイティブなリソース管理を実現する Neuron DRA（プライベートベータ）が導入されています。SDK の新しいバージョンは、Inferentia インスタンスと Trainium インスタンスをサポートしているすべての AWS リージョンで利用できます。 NVIDIA Nemotron 3 Nano が Amazon Bedrock で利用可能に Amazon Bedrock で NVIDIA Nemotron 3 Nano 30B A3B モデルがサポートされました。このモデルは、効率的な Mixture-of-Experts (MoE) アーキテクチャを採用し、高い推論パフォーマンス、ネイティブツール呼び出しのサポート、256k トークンという拡張されたコンテキストウィンドウを備えています。また、Amazon Bedrock の新しい分散型推論エンジンである Project Mantle 上で動作し、OpenAI API 仕様との互換性も提供されるため、既存のコードやツールをそのまま活用できます。NVIDIA Nemotron 3 Nano は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (ムンバイ)、南米 (サンパウロ)、欧州 (ロンドン)、欧州 (ミラノ) の AWS リージョンの Amazon Bedrock で利用でき、Amazon Bedrock の統合 API サービスエンドポイントと OpenAI API 互換サービスエンドポイントの両方をサポートしています。 Amazon Quick adds third-party AI agents and expands built-in actions library Amazon Quick Suite がサードパーティ製 AI エージェントとの統合を拡張し、ビルトインアクションライブラリを強化しました。今回のアップデートにより、Box、Canva、PagerDuty の専門的なエージェントを呼び出せるようになり、例えば PagerDuty からインシデントのインサイトを取得し、Canva でプレゼンテーションを生成し、Box に保存されているドキュメントをクエリするといった作業を、すべて Quick Suite から直接実行できます。さらに GitHub、Notion、HubSpot、Intercom、Monday.com、Linear、Hugging Face などの統合も追加され、GitHub Issue の作成、Notion での会議メモの要約、CRM 管理などのタスクが可能になりました。これにより、異なるアプリケーション間を切り替える手間が軽減され、生成 AI を活用したワークフローを単一のインターフェースから効率的に実行できるようになります。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。今年はコロコロを続けたいと思います。