Amazon Web Services ブログ

キヤノンIT ソリューションズ様と取り組むホテルのフードロス削減 – 時系列基盤モデル Chronos-2 で最適な提供量を予測する

Satoshi Terayama — Mon, 29 Jun 2026 14:41:35 +0000

本ブログは、キヤノンITソリューションズ株式会社とアマゾンウェブサービスジャパン合同会社が共同で執筆いたしました。
みなさま、こんにちは。AWS ソリューションアーキテクトの戸塚、大久保、寺山です。

Amazon および AWS は、The Climate Pledge を通じた2040 年までのネットゼロカーボン達成のコミットメントや、再生可能エネルギー活用の拡大などを通じて、事業運営にサステナビリティを組み込む取り組みを継続しています。ホテル・外食産業や流通小売業界等では、需要予測や在庫最適化によるフードロス削減が環境負荷の低減と収益性向上の両面で重要性を増しており、AWS ではフードロス削減を支援するアーキテクチャやお客様事例をご紹介しています。こうした文脈の中で、Chronos-2 は、事前学習済みの時系列基盤モデルによるゼロショット推論を活用することで、個別モデル学習を必要とせず、計算リソースを抑えながら高精度な需要予測を実現します。さらに推論基盤として AWS Graviton プロセッサ搭載インスタンスを組み合わせることで、価格性能比および電力効率に優れた構成を採用でき、Well-Architected Framework の持続可能性の柱にも配慮したアーキテクチャとして、二酸化炭素排出量の抑制に貢献することが期待できます。

本ブログでは、こうした取り組みの一例として、キヤノンITソリューションズ様と共同で取り組んだ Chronos-2 による需要予測を起点としたフードロス削減 PoC について、アーキテクチャと技術的なポイントをご紹介します。

本取組の背景

令和 5 年度の日本全体のフードロスは約 464 万トンであり、そのうちホテルを含む外食産業由来のフードロスは約 66 万トンを占めています。中でもホテル業界では、以下のような特徴からフードロスが発生しやすい環境にあり、長年に渡り業界全体の課題となっていました。

ビュッフェ提供における過剰提供・見栄え重視
婚礼・宴会における需要変動の大きさ
宿泊客数の予測不確実性
サービス品質重視による欠品 NG の文化

ホテル業界では、仕入れ・調理・提供・食べ残しといった各工程でフードロスが発生する上に、昨今では SDGs への取り組みを企業側に期待する宿泊客も増加しています。フードロス削減はコスト削減・業務効率化・ブランド価値向上の観点からホテル経営における重要テーマとなっています。

30 年以上にわたり PMS（※1）を中心としたホテル向けシステムを手掛けてきたキヤノンITソリューションズ株式会社様（以下、キヤノン ITS）にも、近年お客さまから「データはあるが、具体的な削減施策にどう結びつければよいか」という相談が増えています。こうした声を受け、ホテル事業を営むお客さまにご協力いただきながら、Chronos-2 を用いた需要予測によるフードロス削減の PoCに取り組みました。

（※1）「Property Management System（プロパティ・マネジメント・システム）」の略で、「宿泊予約の管理」「客室の管理」「顧客管理」「売上・請求管理」「データ分析」まで、宿泊施設の運営を支援するホテル管理システム

フードロス削減のPoCについて

すでにホテルにおけるフードロス対策は数多く展開されているものの、持ち帰りや販売など余った料理を活用する方法は食品衛生の観点から、やることに不安を持つお客さまもいます。また、新しい業務が増えることによる現場スタッフの負荷増大の懸念もあります。

そのため、キヤノン ITS は「料理を余らせない」「現場の業務に影響が少ない」アプローチとして需要予測の精度向上による最適な発注量・提供量によるフードロス削減のPoCに取り組みました。

PoCでは、複数のホテルブランドを展開するキヤノン ITS のお客さまにご協力いただきました。このお客さまは、各店舗で発生しているロス量の記録はできていたものの、具体的な対策までは着手ができていませんでした。

そこで、ロス量の実績データを受領して朝食ビュッフェにおける各品目の消費量の予測を試みました。予測には、時系列基盤モデル Chronos-2 を利用しました。

Chronos-2とは

Chronos‑2 は、Amazon Science により開発された時系列基盤モデル（Time Series Foundation Model）です。大規模言語モデル（LLM）と同様に、膨大な時系列データで事前学習されており、個別データごとに学習モデルを構築・チューニングすることなく、過去データ（コンテキスト）を入力するだけで予測を実行できる（Zero‑shot forecasting）点が大きな特徴です。

Chronos-Bolt、Chronos も存在しますが、一番の大きな違いは、Chronos-2 では、複数系列・共変量・カテゴリ情報まで扱える「Universal Forecasting」モデルである点です。

今回 PoC で使用するモデルとして Chronos-2 を選定した理由は以下の通りです。

多変量予測：多品目 × 短期間データでも予測が可能
- 商品ごとにモデルを作り直す必要がなく、「クロワッサン・バターロール・ゆでたまご」といった複数品目を同一アプローチで扱える。
共変量付き予測：ターゲット（使用量）・日時情報に加えて、曜日・客数・朝食券配布数などの任意の共変量を入力として扱うことが可能
- 実績データに加え、業務的に意味のある指標を特徴量として投入することで精度向上が見込める
ゼロショット予測：学習・再学習が不要なため、PoCから運用検討までが非常に短い
- モデル構築にコストをかけず、業務データを手軽に試すことができる

上記よりホテルの朝食ビュッフェのように「日次・多品目・需要振れが大きい」業務データに適した時系列予測モデルであると判断し、採用しました。

実行環境と検証アプローチ

今回の精度検証では、データ加工・可視化・分析を反復的に行う必要があったため、Amazon SageMaker AI の Notebook インスタンスを実行基盤として採用しました。Notebook 上では Python 環境を用い、前処理・予測・評価までを一貫して実施しています。

図1：Chronos-2の検証用実行環境

具体的には、CSV や Excel といった時系列データを取り込み、欠損補完や時系列整形などの前処理を行った上で、Chronos-2 を用いた予測処理を実行し、結果の可視化および精度評価を行いました。この一連の流れにより、モデルの挙動やデータ特性を対話的に確認しながら、仮説検証を高速に回すことが可能となります。

Chronos-2 は以下のようにライブラリをインストールすることで簡単に利用できます。

!pip install -U 'chronos-forecasting==2.2.0'
# 予測の実行
import pandas as pd
from chronos import BaseChronosPipeline
from chronos import Chronos2Pipeline
pipeline = Chronos2Pipeline.from_pretrained(
    "amazon/chronos-2",
    device_map="cpu“,
)
test_df = test_df.drop(columns=["使用量"])
predict_df = pipeline.predict_df(
    train_df, #コンテキストとなるデータ
    future_df=test_df, # 予測対象のデータ
    prediction_length=30,  # 予測期間
    quantile_levels=[0.1, 0.5, 0.9],  # 確率的予測のための分位点（Quantiles）
    id_column="item",  # 異なる系列を表すカラム(カテゴリカラムなど)
    timestamp_column="date",  # 時系列情報を表すカラム
    target="target",  # 予測対象となる時系列の値を格納するカラム（複数可）
)

PoCから実運用への展開

一方で、Notebook インスタンス上での実行は、PoCや探索的分析には適しているものの、定常的な業務オペレーションとしての運用には必ずしも最適とは言えません。たとえば、定期実行やシステム連携、スケーラビリティといった観点ではより本番環境に適した構成が求められます。

そのため実運用においては、Amazon SageMaker JumpStart を活用して Chronos-2 モデルを推論エンドポイントとしてデプロイする構成も有効です。これにより、PoC で検証した予測ロジックを業務プロセスへも容易に組み込むことができます。

PoC実施結果

本 PoC では、ご協力いただいたホテル様よりご提供いただいた過去約 3 年分の日次実績データを活用し、朝食ビュッフェにおける主要 3 品目（クロワッサン、バターロール、ゆでたまご）を対象として検証を実施しました。
本検証の特徴として、単に 1 回の予測を行うのではなく、精度がどの要素によって改善されるのかを確認するため、段階的なアプローチを採用し、以下の 3 ステップで検証を進めました。

Step1：最小構成によるベースライン予測

まず最もシンプルな構成として、以下の最小限のデータのみを用いて予測モデルを構築します。

日付
品名
使用量（ターゲット）

このステップでは、モデルの性能評価に先立ち特に重要となる「時系列データの整備」を重点的に行いました。
Chronos‑2 では、入力データが一定間隔の時系列として整っていることが前提条件となるため、以下の前処理を行い分析に適したデータセットを整備しました。

品目ごとのデータにおける日付の欠損確認
損日付に対する補完レコードの追加

結果

このベースラインモデルの結果は以下の通りです。

MAPE	MAE	80%区間被覆率(※2)
約56.6%	約13.4	約68.9%

(※2) 80%区間被覆率とは予測された「80%の確率でこの範囲に収まる」とされる区間に、実測値がどれだけ含まれているかを示す指標

図2：ベースライン予測結果(予測対実測)

数値変動の大まかな傾向は捉えられているものの、以下 3 点の実業務における重要な要因を考慮できておらず、業務で活用するには精度が不十分であることが確認されました。

平日と週末の需要差
宿泊客数による需要変動
直近の消費傾向

Step2：業務データを考慮した予測モデル

次に、実際のホテル業務において使用量を判断する際に利用されている情報を特徴量として追加し予測を行いました。追加したデータは以下の通りです。

前日宿泊者数
朝食券配布枚数

これらの項目は、単なる補助情報ではなく現場において「今日は宿泊者が多いから多めに作る」といった意思決定に直接使用されている重要な指標です。
また、特徴量の選定にあたって以下の観点で絞り込みを行いました。

使用量との相関確認
予測時点で取得可能なデータのみを利用（リーケージ防止）

図3：使用量に対する各特徴量の相関係数

結果

MAPE	MAE	80%区間被覆率
約28.3%	約7.1	約78.9%

図4：重要指標を特徴量へ追加後の予測結果(予測対実測)

ベースラインと比較して、誤差は約50%改善し、以下が適切に反映されるようになりました。

平日／週末の傾向
来客規模の影響

この結果から、業務知識に基づく特徴量の追加が予測精度に大きく寄与することが明確に確認することができました。

Step3：ラグ特徴量による最終的な精度向上

さらに精度向上を図るため、時系列データ特有のパターンである「連続性」と「周期性」をモデルに取り込むことを目的として、ラグ特徴量を追加しました。

本PoCでは、ラグ特徴量の追加を感覚的に行うのではなく、事前に以下の分析を行いました。

自己相関分析
偏自己相関分析
曜日単位の周期性の確認

図5：曜日周期性の確認と自己相関

この結果から、以下のような「連続性」と「周期性」を確認することができました。

「前日の影響を受ける（連続性）」
「1週間単位で繰り返される（曜日周期）」

朝食ビュッフェの需要特性を踏まえた上で、下記の特徴量を追加して予測を行いました。

使用量_lag1（前日の使用量）
使用量_lag7（1週間前の使用量）

結果

最終モデルの結果は以下の通りです。

MAPE	MAE	80%区間被覆率
約20.3%	約5.05	約82.2%

図6：ラグ特徴量追加後の予測結果(予測対実測)

この結果から、予測精度のさらなる向上と予測の信頼性（区間被覆率）の改善実運用への適用が十分に検討可能な水準に到達することが確認できました。また、グラフ上でも、週末の需要ピークや品目ごとの変動特性が再現されており、モデルが単なる数値補間ではなく、需要構造そのものを捉えることができました。

技術的なポイント

Chronos-2 における時系列カラムの注意点

Chronos‑2 を利用した時系列予測では、コンテキストとして入力されるデータが「一定間隔の時系列として整備されていること」が前提条件となります。例えば、日次データであれば、時系列カラム×種類カラム(今回の場合は、日付×品目)において、すべての日付が抜け漏れなく並んでいる必要があります。また、予測は、各種類カラムの最終日付から指定した日付分の予測が行われる点にも注意が必要です。

図7：異なる期間のデータを用いた場合の予測対象期間

実運用データでは、非営業日や記録漏れなどにより日付が欠損しているというケースも少なくありませんが、そのまま Chronos-2 に投入すると時系列として正しく解釈されず、エラーが発生する可能性が高いため注意が必要です。

図8：データ抜け日の確認と欠損補完イメージ

このため、本 PoC では品目ごとに日付の連続性を確認し、欠損している日については補完レコード（使用量 0 または NULL）を追加する前処理を行っています。た。Chronos‑2 を活用する際は、モデル以前に「時系列を等間隔に整えるデータ整備」もポイントになります。

リーケージを防ぐ設計

時系列予測や機械学習において注意すべき点のひとつがリーケージ（データリーケージ）です。リーケージとは、予測時点では本来入手できない未来の情報を、誤って特徴量として使用してしまうことを指します。

リーケージが発生すると、一見すると非常に高い予測精度が出るが、実際の業務運用では同じデータが取得できないため、検証時の精度が再現できないモデルになってしまうため注意が必要です。

図9：リーケージの危険性

本 PoC では、「前日終業時点で翌日の朝食使用量を予測する」という業務シナリオを前提とし、前日宿泊者数や朝食券配布枚数など、予測時点で確実に取得可能な情報のみを特徴量として使用しました。機械学習モデリングでも同様ですが、Chronos‑2 を業務に適用する際には、「その情報はいつ取得できるのか？」を意識し、リーケージを防ぐ設計が不可欠です。

ラグ特徴量の有効性

時系列予測では、過去の値が将来の値に影響するという特性をモデルに取り込むため、過去の値をずらして特徴量として使用する「lag 特徴量」がよく用いられます。lag 特徴量を追加することで、直前の傾向（連続性）や、曜日などによる周期的なパターンを表現することができます。

図10：ラグ特徴量のメリットと注意点

本 PoC では、自己相関の結果に基づき、lag1：前日の使用量、lag7：7日前（同じ曜日）の使用量を特徴量として追加しました。

これにより今回の検証では、短期的な増減や曜日単位の周期性を捉えやすくなり予測精度が向上しました。

一方で、lag 特徴量は設定次第でリーケージにつながる可能性があるため、「いつ予測を行うのか」という業務前提を明確にした上で、実運用で取得可能な範囲の lag のみを採用することもが重要になります。

Chronos-2 に関する考察

機械学習モデルの予測精度向上施策を打つことで、Chronos-2 でも同様に予測結果が向上させることが可能
機械学習モデリングの時と同様にコンテキストに含めるデータ項目が多いとより精度向上施策に幅がでて、精度改善に寄与することができる可能性が広がる
FineTuningやクロースラーニングなどさらなる精度向上施策を手軽に試せる点も非常に使い勝手が良い

本検証の総括

今回の取り組みを通じ、ホテル業界におけるフードロスは「やむを得ないもの」ではなく、データ活用により削減可能であることを実感しました。現在の、食数予測においてはホテル従業員の経験や勘に依存する部分も多く、その結果として過剰な仕込みやロスが発生しやすい傾向にありましたが、今回の Chronos-2 による需要予測を用いることで需要変動の傾向が可視化され、ロス削減の余地があることが分かりました。

一方で、予測の結果だけですべてが解決するわけではありません。実際の現場では、お客さまへの満足度を考慮してある程度の余剰を持たせる運用が不可欠です。そのため、単に予測結果を提供するのではなく、「予測結果をどう使うか」「どこまでなら調整が出来るか」といった現場に寄り添った運用面もあわせて合わせて考えることが重要です。

今後は、予約状況やイベントなどの外部情報も取り入れながら精度を高めるとともに、予測結果を発注業務などに連携させる仕組みを作ることがより一層重要になると考えます。引き続き、現場に寄り添いながら、ホテル業界全体のフードロス削減に貢献できるよう取り組んで参ります。

まとめと今後の展望

今回の取り組みでは、Amazon Science が発表した時系列基盤モデル Chronos-2 が、ホテルの朝食ビュッフェという「日次・多品目・需要変動が大きい」業務領域において有効に機能することを検証しました。学習不要で即座に予測を開始できることに加え、特徴量の工夫により追加学習なしでも本番業務で活用できる精度に達することを実証しました。これにより、PoC から本番運用への移行を短期間かつ低コストで実現する道筋が示されたと考えています。

AWS では、Amazon SageMaker AI をはじめとする AI/ML サービスを通じて、Chronos-2 のような時系列基盤モデルを本番環境でスケーラブルに運用するための基盤を提供しています。本ブログで紹介した需要予測のアプローチは、ホテル業界に限らず、外食・流通小売・食品製造など、フードロスが課題となる幅広い業種への適用が期待されます。また、こうした需要予測での発生抑制に閉じるのではなく、スマート廃棄物管理など多面的なアプローチがフードロス削減を目指す上では不可欠です。

Amazon は、The Climate Pledge を通じて2040年までにネットゼロカーボンを達成することをコミットしており、AWS はその実現に向けて、エネルギー効率に優れたクラウドインフラストラクチャの提供、カーボンフリーエネルギーへの移行推進、そしてお客様のワークロード最適化による環境負荷低減の支援を行っています。本ブログでご紹介した需要予測によるフードロス削減も、テクノロジーを活用した持続可能性への貢献の一つです。同様の取り組みを検討されている皆さまの一助となれば幸いです。

執筆者

キヤノンITソリューションズ株式会社

ホテル業界向けのシステム開発を30年以上手掛けています

（左から）

大原諭 (Satoshi Ohara)

流通業界・サービス業界向けおよびデータマネジメントソリューションのマーケティング・企画担当

大竹智礼 (Tomonori Otake)

データマネジメント領域におけるデータサイエンティストとして、主に流通業界向けのデータ分析、
予測AI、生成AI開発を担当

辻夏子(Natsuko Tsuji)

ホテル業界向けソリューションのマーケティング・商品企画担当。本取り組みの推進リーダー

戸塚智哉(Tomoya Tozuka) /@tottu22

飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューションアーキテクトで、AI/ML、IoT を得意としています。最近ではAWSを活用したサステナビリティについてお客様に訴求することが多いです。
趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています

大久保裕太 (Yuta Okubo)

外食業界や飲料メーカーのお客様を支援しているソリューションア―キテクトです。好きなAWSサービスは AWS IoT Core。
最近は、デスクワークによる姿勢の崩れを筋トレで解消しようとしています

寺山怜志 (Satoshi Terayama)

外食業界や百貨店業界のお客様を支援しているソリューションア―キテクトです。
最近は、時系列基盤モデル Chronos-2 を始めとした機械学習領域での学びを深めています

株式会社フジテレビジョン様が冬季国際スポーツ競技大会で実現した Live Cloud Production

Yu Kitamura — Mon, 29 Jun 2026 09:00:45 +0000

2026年2月6日から22日にかけて、イタリアのミラノ・コルティナにて世界的な冬季スポーツ競技大会が開催されました。本ブログでは、株式会社フジテレビジョン様（以下、フジテレビ）がこの大会において、地上波テレビ放送のライブ映像制作を AWS 上で行う「Live Cloud Production（以下、LCP）」を実現した事例をご紹介します。

テレビのライブ放送を支える3つの処理

Live Cloud Production とは、物理的な設備を削減しクラウド上でのライブ映像の制作を可能にする新しい放送・映像制作ワークフローです。Live Cloud Production を理解する上で、一般的なテレビのライブ放送がどのように行われているのかを最初にご紹介します。テレビのライブ放送で視聴者に届ける映像を制作する上で、主に3つの処理がリアルタイムに行われています。

1つ目は映像スイッチングです。スタジオ、競技会場、リプレイなど複数の映像ソースの中から、放送に乗せる映像をリアルタイムに選択・切り替えます。2つ目は音声ミキシングです。各出演者のピンマイク、会場の環境音、BGM、効果音など多数の音声チャンネルを適切なバランスに調整します。3つ目は CG 合成です。テロップ、スコア表示、バーチャルグラフィックスをリアルタイムに描画し、映像に重ね合わせます。従来はこれらの３つの処理は専用ハードウェアによって処理されていました。

図1: 実際のスタジオの様子。競技映像やスタジオセットの上半分などは CG 合成で作られていて、現地での設営を簡略化している。複数ソースからの映像スイッチングや音声ミキシングも行われている。(提供：株式会社フジテレビジョン)

国際中継における課題

海外で開催されるスポーツイベントの中継では低遅延かつ放送品質の安定した映像伝送を行う必要があるため、競技会場と国内のテレビ局の間に専用回線を敷設する必要があります。さらに、前述の3つの処理（映像スイッチング、音声ミキシング、CG 合成）を行うための専用ハードウェアも現地に輸送・設置しなければなりません。現地への機材輸送・設置には数ヶ月の期間を要し、専用回線の費用も含め大きなコストとなっていました。

フジテレビの取り組み — Live Cloud Production

近年は専用ハードウェアが持つ機能のソフトウェア化が進んでおり、ライブ放送に必要な処理（映像スイッチング、音声ミキシング、CG 合成）をオンプレミスのサーバーやクラウド上の仮想サーバーで実行できるようになってきています。

フジテレビは今回の大会で、ライブ放送に必要な処理を行うソフトウェアを Amazon EC2 上で、海外からの映像伝送を AWS Elemental MediaConnect で行い、LCP として AWS クラウドに集約する構成を採用しました。

ミラノの IBC（国際放送センター）に設置したエンコーダーで8台のカメラ映像を H.265 / 20Mbps の SRT (Secure Reliable Transport) ストリームに変換し、帯域保証付きの公衆インターネット回線2本（本番用・予備用）を通じて AWS フランクフルトリージョンに送出します。フランクフルトリージョンの Amazon EC2 上では、Sony M2L-X（映像スイッチング）、Waves Cloud MX Audio Mixer（音声ミキシング）、Vizrt Viz Engine（CG 合成）が稼働し、AWS Elemental MediaConnect がクラウド内外の映像ルーティングを担いました。完成した番組映像は AWS Direct Connect 経由でお台場のフジテレビ本社に SRT で伝送され、地上波で放送されています。クラウド障害時に備えたパリリージョン経由のバックアップパスも構築しました。

図2: Live Cloud Production の全体構成。ミラノ IBC からフランクフルトリージョン、お台場のフジテレビ本社までの映像・音声・制御の全系統を示す。(提供：株式会社フジテレビジョン)

この構成により、IBC 側のスタジオにはスイッチャーやミキサーなどのコントローラーやモニターを中心に配置する形となりました。従来のハードウェアの機能をクラウドに移したことで、現地の設備は大幅に簡素化されています。

パリからミラノへ — 1年半にわたる検証

フジテレビと AWS は3年以上にわたり、段階的に LCP の取り組みを進めてきました。

2024年のパリで行われた夏季スポーツ競技大会では、ソニー製ソフトウェアスイッチャー M2L-X を AWS 上で利用する PoCを実施しました。その後、約1年半にわたり、様々なパートナーのソフトウェアを EC2 上で利用するための検証が重ねられました。各ソフトウェアを動かす EC2 間では、NDI (Network Device Interface) という高品質・低遅延の映像・音声データをリアルタイムで相互伝送する伝送方式が使われており、NDI 伝送の検証も進められました。

2025年8月にはフランクフルトリージョンにクラウド環境を構築し、実際のスタジオを使った最終検証を実施。9月末にはミラノ現地の IBC に設置する全機材の仮組みとクラウドシステムの統合検証を完了しました。

本番運用と結果

期間中は、イタリア国内各所で実施された多数の競技中継を LCP で制作しました。全期間を通じて放送品質を維持した安定運用を達成しています。クラウドを経由した全体の遅延は約 1.7 秒に収まり、従来のオンプレミス構成と遜色ない遅延量で制作することができました。

ネットワークコストは、過去大会の専用線費用と比較して 45% 削減されました（現地インターネット回線費用およびクラウドアプリケーションライセンス費用を含む）。また、現地入りからスタジオオープンまでの技術全体のセットアップ作業時間は、従来と比較して 21% 削減されています。

まとめ

今回は、フジテレビが世界的な冬季スポーツ競技大会で LCP を実現した事例についてご紹介しました。今回の実績を踏まえ、フジテレビは今後の国内外のスポーツ中継への LCP 展開を検討されています。

LCP や放送業界での AWS 活用にご関心のある方は、お気軽にお問い合わせください。

著者

週刊AWS – 2026/6/22週

Suguru Sugiyama — Mon, 29 Jun 2026 08:24:06 +0000

みなさん､こんにちは｡ソリューションアーキテクトの杉山です｡今週も週刊AWS をお届けします｡

先週の木曜日､金曜日に AWS Summit Japan 2026 を開催しました｡台風が近づいていた中ではありましたが､多くのお客様にご来場いただきました｡ブースでたくさんのご相談を頂きましたが､AI 活用でどのような利便性があるのか､また､どういった仕組みでガバナンスを担保できるのか､という観点で質問を頂きました｡AWS Summit のセッションは､オンデマンド視聴が開始されています｡当日視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただき次の一歩につながるヒントを得ていただければ幸いです｡

それでは､先週の主なアップデートについて振り返っていきましょう｡

2026年6月22日週の主要なアップデート

6/22(月)
- Amazon Connect Customer が Agentic CX designer (NLX) のプレビュー版を提供開始
  Amazon Connect Customer は､AI を活用したセルフサービス体験を設計・展開するためのノーコードキャンバス「Agentic CX designer (NLX)」のプレビュー版を提供開始しました｡ビジネスチームがコードを書かずに､エージェント型 AI と､本人確認や決済処理などの正確なアクションが求められるフローを組み合わせた音声・デジタル体験を構築できます｡また､通話中に顧客の Web/モバイルアプリをリアルタイムで操作できる Live Sync 機能も同時にプレビュー提供されます｡例えば､AI エージェントとホテル予約を通話している中で､会話内容に基づいて画面が同期して移動し､ホテルの予約を自動的に行うことがやりやすくなる仕組みです｡なお、プレビュー期間中は、ご自身のユースケースに合わせて精度などを検証いただくことが可能です｡
- AWS Network Firewall がデフォルト drop action を更新し接続信頼性を改善
  AWS Network Firewall は､新規作成するすべてのファイアウォールポリシーで､stateful action のデフォルトを “Application drop established (bidirectional)” から “Application drop established (server-directed only)” に変更しました｡この変更により､TCP window updates､keep-alives､resets などの正当なサーバーからクライアントへの TCP 制御パケットが誤ってドロップされることがなくなり､診断が困難だった断続的な接続障害を回避できます｡既存のポリシーには影響がなく､新規ポリシー作成時に自動的に適用されます｡
- AWS Lambda MicroVMs で分離実行環境を提供開始
  AWS Lambda MicroVMs を発表しました｡これはユーザーや AI が生成したコードを安全に実行するためのサーバーレスコンピューティング環境です｡VM レベルの分離､ほぼ瞬時の起動と再開速度､最大 8 時間の状態保存機能を提供します｡米国東部 (バージニア､オハイオ)､米国西部 (オレゴン)､アジアパシフィック (東京)､欧州 (アイルランド) で利用可能です｡従来の Lambda 関数がリクエストに応じて自動的にスケールするのに対し､MicroVMs は run-microvm API を呼んだ回数だけ MicroVM が 1 個ずつ起動し､各 MicroVM に専用の HTTPS エンドポイントが割り当てられます｡この「1 エンドポイント＝1 台」という特性を活かせば､ユーザーやセッションごとに独立した実行環境を割り当て､起動・サスペンド・終了のライフサイクルをアプリケーション側で自在に制御できるため､AI エージェントのコード実行サンドボックスやインタラクティブな開発環境のように「状態を保ったまま長時間使い続ける」ユースケースにうまくフィットします｡一方で従来の Lambda 関数は短時間・ステートレスなリクエストを大量にさばく用途に強いので､ワークロードの性質に応じて両者を使い分けるのがおすすめです｡なお､クォータは同時実行数ではなくアカウント・リージョンあたりの合計メモリ量で管理され､run-microvm API のレート制限はデフォルトで 5 TPS（バースト 5）です｡多数の環境を一度に立ち上げたい場合は､あらかじめサスペンド状態でプレウォームしておくと安定して払い出せます｡これらのクォータは Service Quotas コンソールから上限緩和を申請できます｡
6/23(火)
- Claude Tag が AWS Marketplace の Claude Enterprise でベータ版として利用可能に
  Anthropic は､Claude Tag のベータ版を AWS Marketplace 経由で Claude Enterprise を利用する顧客向けに提供開始しました｡Claude Tag は､Slack チャネル内で @Claude とタグ付けすることで､チームメンバーが Claude にタスクを委任できる新機能です｡チャネルごとにアクセス権限と予算を設定でき､Claude は接続されたチャネルの文脈を記憶しながら､ツールやデータ､コードベースにアクセスできます｡管理者は Claude 管理コンソールで約 1 時間でエージェント ID をプロビジョニングし､チャネルごとにスコープを設定します｡
- Amazon GuardDuty AI-powered investigations で脅威対応を加速 (Preview)
  Amazon GuardDuty に AI-powered investigations 機能 (Preview) が追加されました｡この機能は GuardDuty の findings とアカウントを自動的に分析し､真の脅威と誤検知を数分で見分けることができます｡過去 90 日間の関連アクティビティ､影響を受けるリソース､脅威インテリジェンスを knowledge graph を使って分析します｡これまで､GuardDuty の findings を手動で調査するには時間がかかり､アラート疲れ (alert fatigue) の原因となっていました｡AI-powered investigations により､数分で自動分析が完了します｡また､CLI コマンドを含む具体的な修復手順を提供してくれるため､対応のアクションが素早くなります｡
- Amazon CloudWatch Logs がマネージド syslog 取り込みに対応
  Amazon CloudWatch Logs が VPC エンドポイント経由での syslog 直接取り込みに対応しました｡ファイアウォール､ルーター､スイッチ､Linux サーバーからエージェントをインストールせずに syslog メッセージを CloudWatch Logs へ送信できます｡RFC 5424､RFC 3164､Cisco FTD/ASA の各フォーマットに対応し､facility､severity､hostname､appName などの構造化フィールドを自動的に抽出します｡PrivateLink に対応していて､Direct Connect や Site-to-Site VPN の Private 通信も可能となっています｡
6/24(水)
- Amazon CloudWatch でダッシュボードのタグ機能をサポート
  Amazon CloudWatch がダッシュボードのタグ機能をサポートしました｡これにより､ダッシュボードをチーム､プロジェクト､環境などのカテゴリで整理し､タグベースでアクセス制御を実装できます｡PutDashboard API が Tags パラメータに対応したほか､TagResource､UntagResource､ListTagsForResource API がダッシュボード ARN をサポートし､1つのダッシュボードに最大50個のタグを設定できます｡CloudFormation と AWS Resource Explorer にも対応しており､追加コストなしで CloudWatch が利用可能な全リージョンで提供されます｡
- Amazon Route 53 Global Resolver が AWS アカウント間での DNS View 共有をサポート
  Amazon Route 53 Global Resolver が､AWS Resource Access Manager (AWS RAM) を使用して DNS View を他の AWS アカウントと共有できるようになりました｡Route 53 Global Resolver は､リモート拠点やオンプレミス環境から AWS 上の Private Hosted Zone とパブリックドメインの両方を解決できる､インターネット到達可能な DNS リゾルバーです｡この機能により､consumer アカウントは自身の Route 53 Private Hosted Zone を共有された DNS View に関連付けることで､所有権を移譲せずに owner の Global Resolver を通じて全 AWS リージョンで名前解決できます｡DNS View 共有は追加料金なしで､Route 53 Global Resolver がサポートされている全リージョンで利用できます｡
- AWS IoT Device SDK for Swift の一般提供開始
  AWS IoT Device SDK for Swift が一般提供 (GA) を開始しました｡Swift 開発者は macOS 12+､iOS 16+､tvOS 16+､Linux 上で AWS IoT サービスを利用した IoT アプリケーションをネイティブに構築できるようになります｡SDK は MQTT 5 プロトコルをサポートし､AWS IoT Device Shadow､Jobs､Fleet Provisioning の統合クライアントを提供します｡iOS と tvOS では TLS 1.3 に対応しており､最新のセキュリティ標準でデータを保護します｡Swift Package Manager 経由でインストールできます｡
- Amazon EC2､AMI ガバナンス強化のための AMI Watermarks 機能を発表
  Amazon EC2 が AMI Watermarks 機能を発表しました｡この機能により､Private AMI にカスタム識別子を埋め込み､AMI の系譜追跡とガバナンスポリシーの実施が可能になります｡ウォーターマークは AMI のコピーや派生 AMI 作成時に自動的に引き継がれ､リージョン間コピーやアカウント共有でも保持されます｡Allowed AMIs 機能と組み合わせることで､承認されたウォーターマークを持つ AMI のみからインスタンスを起動するよう制限できます｡全 AWS リージョンで追加料金なしで利用可能です｡
6/25(木)
- AWS Network Firewall が VisionHeight のマネージド脅威インテリジェンスルールをサポート
  AWS Network Firewall が VisionHeight 社の 2 つの新しいマネージドルールグループをサポートしました｡AWS Marketplace 経由で利用できる Zero-Day Threat Protection と Noisy Scanners and Tor Protection により､公開ブロックリストに掲載される数週間前に悪意ある IP インフラストラクチャを先制ブロックし､Tor 出口ノードや高頻度スキャンソースからの通信を遮断してファイアウォールログのノイズを削減します｡VisionHeight の Pulse テレメトリーに基づく独自の脅威インテリジェンスを活用でき､日次更新により最新の脅威情報を反映します｡

それでは､また来週お会いしましょう！

著者について

Kiro で OpenAPI/Swagger 仕様から数秒でテストスイートを生成する

Hiroaki Yoshimura — Mon, 29 Jun 2026 07:27:10 +0000

本記事は 2026 年 6 月 25 日に公開された Sumitha AP、Rajdeep Mukherjee による “From OpenAPI/Swagger specifications to test suite in seconds with Kiro” を翻訳したものです。

API は現代のアプリケーションの基盤です。チームが REST API を構築し改良していく中で、網羅的なテストカバレッジを維持することは継続的な課題となります。OpenAPI/Swagger 仕様は、API がどう振る舞うべきかを的確に記述します。エンドポイント、リクエストの形式、レスポンスのスキーマ、ステータスコードなどです。しかし、それらが実際に機能することを証明するものではありません。

そのギャップを埋める作業は、伝統的に開発者の肩にかかってきました。仕様を読み、各エンドポイントをテストケースに落とし込み、正常系とエッジケースを考慮し、テストランナーを組み立て、依存関係をモックし、結果を意味のある形で見せるためのレポート機能を構築します。中規模の API、例えばエンドポイントが 40 個あるとすると、製品コードを 1 行も書く前に 1 週間分の作業が必要です。しかも仕様が安定していることが前提ですが、実際にはほとんど安定しません。

根本的な課題は、API 仕様とそれに対応するテストスイートが独立して保守されていることです。時間が経つにつれ、両者は必然的に乖離していきます。リリース時に書かれたテストはエンドポイントの変更とともに陳腐化し、新しいエンドポイントはテストカバレッジを伴わずにリリースされていきます。

OpenAPI Generator のようなツールは仕様からテストのスキャフォルディングを生成できますが、通常は開発者自身が埋めるためのスタブを提供するだけです。Kiro は別のアプローチを取り、仕様をテスト生成の信頼できる情報源として扱います。OpenAPI/Swagger ファイルを入力すると、Kiro は動作するテストスイート、エンドポイントカバレッジ、エッジケース、スキーマ検証、レポート用スキャフォルディングを、テストファイルをセットアップする時間と同じくらいで生成します。さらに、Kiro は再生成を素早く低コストで行えるようにすることで、テストを仕様と同期させるコストを下げ、フックによってドリフトを早期に検出できます。本記事では、それがどのように機能し、何が生成されるのかを詳しく見ていきます。

Swagger と OpenAPI 仕様

Swagger は、構造化された JSON を使って REST API をドキュメント化する手段として作られました。どんなエンドポイントがあるか、各エンドポイントがどのパラメータを受け取るか、成功時に何を返すか、問題が起きたときに何を返すか、といった語彙を定義します。

最小限の OpenAPI ドキュメントは、各エンドポイントについて、URL パスと HTTP メソッド、受け取るパラメータ（型、位置（location）、必須／任意）、成功時のレスポンススキーマ、ありうるエラーレスポンスとそのコードを指定します。

# openapi.yaml: マシン可読な API の契約
openapi: "3.0.0"
paths:
  /pet/{petId}:
    get:
      summary: "Find pet by ID"
      parameters:
        - name: petId
          in: path
          required: true
          schema: { type: integer }
      responses:
        "200":
          content:
            application/json:
              schema: { $ref: "#/components/schemas/Pet" }
        "404":
          description: "Pet not found"

OpenAPI ドキュメントは単なるドキュメント以上のものです。REST API のインターフェースを完全に記述する構造化された定義ファイル（JSON または YAML）です。API の提供者と利用者の間の契約として機能し、マシン可読であるため、適切なツールがそれを解析し、推論し、実際の成果物を生成できます。この点は、以降の議論すべてに関わる重要なポイントです。

本記事では、エージェント駆動の開発システムである Kiro を使って、Swagger API 仕様から直接、モックサーバー・設定トグル・HTML テストレポートまで含む実行可能な Node.js テストスイートを自動生成する方法を示します。

既存ツールが力不足な理由

これまでに OpenAPI 仕様を扱ったことがあれば、OpenAPI Generator や Swagger Codegen に出会ったことがあるでしょう。背景として、OpenAPI Generator はガバナンスの違いから 2018 年に Swagger Codegen からフォークされました。両者は似た目標を持ちますが、独立して保守されており、リリース頻度や機能セットも異なります。どちらも仕様ファイルを受け取り、選択した言語のクライアントライブラリ、サーバースタブ、SDK コードを生成するオープンソースツールです。HTTP のボイラープレートを削減するには優れていますが、API の振る舞いを検証する目的では設計されていません。テスト生成に使おうとすると、通常はアサーションが最低限のメソッドスタブ、限定的なモック、わずかなスキーマ検証しか得られません。もっとも、具体的な出力は使用する言語、テンプレート、設定によって異なります。テストはコンパイルされ実行はされるかもしれませんが、エッジケース、エラーハンドリング、スキーマの契約を意味のある形でカバーしているとは限りません。

これは見た目以上に深刻な問題です。アサーションのないテストでも CI ではパスし、カバレッジにはカウントされます。しかし実際にはステータスコード、レスポンスの形、エラーケースをチェックしていません。ビルドは成功し、カバレッジ数値も高いのに、400 が 500 として返されているといった特定のバグが見過ごされるということが起こり得ます。

Kiro はこの問題に異なるアプローチを取ります。仕様をテンプレート化するのではなく、仕様を推論します。enum の値を現実的なペイロードに解決し、実際のスキーマの契約に紐づいたアサーションを生成し、仕様で定義された振る舞いを反映したモックサーバーを作り出します。出力されるのは後で埋めるためのスキャフォルディングではなく、意味のあるカバレッジを持つ実行可能なテストです。

機能	OpenAPI Generator	Kiro
アサーション付きの実行可能なテストを生成	◐ 限定的（テンプレート依存）	✓ あり
仕様に対応するモックサーバーを構築	✗ なし	✓ あり
スキーマから現実的なペイロードを推論	◐ 部分的	✓ enum の解決を含む
チームのコーディング規約に適合	◐ カスタムテンプレート	✓ ステアリングファイル経由
仕様のドリフトに応じて CI で再生成	✗ 手動	✓ ヘッドレスモード
自然言語の意図を理解	✗ なし	✓ あり

機能比較: テンプレートベースのジェネレーター vs. Kiro のエージェント駆動アプローチ。

テンプレートベースのアプローチでは、特定の種類の問題が検出されないままになり得ます。例えば 400 エラーが 500 として返されたり、認証エンドポイントが不正な形式のトークンを受け入れたりするケースです。とくに、生成されたテストが実際にはエンドポイントへの呼び出しを行わず、レスポンスの検証もしない場合に顕著です。これらのツールは主にコード生成のために設計されており、振る舞いの検証のためのものではありません。一方で Kiro は、各エンドポイントを実際に呼び出し、レスポンスが仕様で定義されたものと一致するかを検証するテストを生成します。これにより、API の実際の準拠状況についてより信頼できるシグナルが得られます。

ソリューション概要

本ソリューションでは、サンプルの PetStore の Swagger/OpenAPI 仕様 URL を入力として受け取り、Kiro を使って完全に機能するテストプロジェクトを生成します。生成されるプロジェクトには以下のコンポーネントが含まれます。

axios を使用したテストクライアント：Swagger 仕様で定義されたすべてのエンドポイントをカバーする HTTP テスト。GET、POST、PUT、DELETE 操作と、それに応じたリクエストペイロードおよびレスポンスアサーションを含みます。
Express のモックサーバー：API をシミュレートするローカルサーバー。各エンドポイントに対して現実的なレスポンスを返すため、ネットワークアクセスや実サービスへの依存なしにテストを実行できます。
設定トグル：同じテストスイートをモックサーバー（ローカル開発用）または実 API（統合テスト用）に対して実行できる簡単なスイッチ。
HTML テストレポート：各テストケースの合否と詳細なエラー情報を表示する、スタイル付きで共有可能なレポート。CI/CD パイプラインやプルリクエストのレビューに適しています。
外部テストフレームワークゼロ：テストは素の Node.js と軽量なカスタムランナーで動作し、フレームワークのバージョン競合をなくし、セットアップの手間を減らします。

前提条件

このウォークスルーを進めるには、以下が必要です。

Node.js
Kiro のインストールと設定
Swagger/OpenAPI 仕様の URL（例として Petstore API を使用します）

Kiro でテストスイートを生成する

それでは、Petstore の Swagger 仕様から完全なテストスイートを生成しましょう。テスト生成のルールをすべてプロンプトに埋め込むのではなく、Kiro のステアリングファイルを使用します。ステアリングファイルは「.kiro/steering/」に配置され、ワークスペース内のすべてのプロンプトで Kiro が従う永続的な指示を提供します。これにより、テスト生成の基準を一度定義しておけば、すべてのプロンプトでその恩恵を受けられます。本ブログではこのサンプルステアリングファイルを使用しました。チームのニーズや基準に合わせてカスタマイズしてください。

※ この図は GIF 形式に変換しているため画質が粗くなっています。鮮明な動画は原文記事をご参照ください。

サンプルプロンプト

Kiro の vibe モードで使用するサンプルプロンプトを示します。

Generate a Node.js test suite from https://petstore.swagger.io/index.html using axios, Express for mocking, and no external test frameworks

Kiro は Swagger 仕様を読み込み、すべてのエンドポイントを解析し、プロジェクト全体を生成します。

※ この図は GIF 形式に変換しているため画質が粗くなっています。鮮明な動画は原文記事をご参照ください。

生成されたプロジェクト構造を確認する

Kiro は以下のような構造のプロジェクトを生成します。

config.js：設定トグルを含みます。useMockServer: true に設定するとローカルの Express モックサーバーに対してテストを実行し、useMockServer: false に設定すると実際の Petstore API を対象にします。
mock-server/server.js：Petstore のすべてのエンドポイントに対するルートハンドラを持つ Express アプリケーション。各ハンドラは、Swagger 仕様で定義されたスキーマに一致する現実的なレスポンスデータを返します。
test/：API リソース（pet、store、user）ごとに整理された個別のテストファイル。各ファイルには、そのリソースのすべての操作に対するテストが含まれ、レスポンスのステータスコードとペイロード構造に対するアサーションがあります。
test-runner.js：軽量な素の Node.js テストランナー。すべてのテストファイルを検出して実行し、合否のカウントを追跡し、エラーの詳細を取得します。

Kiro がどのように仕様を解析するかを理解する

Kiro は汎用的なテストスタブを生成するだけではありません。Swagger 仕様とステアリングファイルの指示を読み込んで、次のことを行います。

すべてのエンドポイントと HTTP メソッドを識別する：Petstore API の場合、POST /pet、GET /pet/{petId}、PUT /pet、DELETE /pet/{petId}、GET /store/inventory、POST /user/createWithList などの操作が含まれます。
スキーマ定義からリクエストペイロードを推論する：POST および PUT 操作について、Kiro は仕様内のモデル定義に基づいて有効なリクエストボディを構築します（例えば、id、name、category、photoUrls、tags、status フィールドを持つ Pet オブジェクト）。
期待されるレスポンスコードに基づいて検証コードを生成する：各テストは、仕様のレスポンス定義で定められた正しい HTTP ステータスコード（200、201、404、405）を検証します。
対応するモックサーバーのルートを作成する：仕様内のすべてのエンドポイントに対して、定義されたレスポンススキーマに合致したデータを返す Express ルートハンドラが生成されます。

テストを実行する

モックサーバーに対して実行する

ローカルのモックサーバーに対してテストスイートを実行するには、チャットインターフェースで次のプロンプトを入力します。

Run the tests with the mock server

以下のような結果が表示されるはずです。

テストランナーはモックの Express サーバーを起動し、すべてのテストケースを実行し、レポートを生成します。生成された test-report.md をブラウザで開いて結果を確認してください。

テストの品質と分類

生成されたテストスイートには、Petstore の Swagger 仕様で定義されたすべてのエンドポイントをカバーするテストケースが含まれています。これらはユニットテストではなく統合テストです。各テストは axios 経由で実行中の Express サーバーに対して実際の HTTP リクエストを送り、TCP トランスポート、ミドルウェアのパース、ルートマッチング、ハンドラのロジック、状態の変化、JSON シリアライズといったスタック全体を使います。サーバー内部は関数レベルでスタブやモックされていません。複数のリクエストを連鎖させるテストも含まれます。例えば DELETE のテストでは、最初にリソースを POST し、次に DELETE し、最後に GET で 404 を確認するといった具合で、リクエストライフサイクルをまたいで副作用が正しく永続化されることを検証します。このマルチリクエストでブラックボックスなアプローチは、統合テストを統合テストたらしめる特徴です。

品質面では、このスイートには明確な強みがあります。各エンドポイントについて正常系と異常系の両方を体系的にカバーし、OpenAPI 仕様に記載された具体的な HTTP ステータスコード（200、400、404、405）を検証します。エフェメラルポートとインメモリのシードデータを使用しているため、スイートは完全に自己完結しており決定的です。ネットワーク依存もポートの衝突もなく、どのマシンでも再現可能です。破壊的な操作はレスポンスコードだけを信用せず、後続の読み取りで検証します。

要するに、これは API の形状とエラーハンドリングに対する CI の高速フィードバックに適した、実用的な契約レベルの統合スイートです。プロダクション品質の信頼性に到達するには、テストごとの状態分離、完全な JSON スキーマ検証、認証のカバレッジ、そして実サービスに対する定期的な実行が加わると良いでしょう。

詳細: 削除ライフサイクル全体のテスト

Kiro が生成したテストの中でも、より興味深いものの 1 つは、単にエンドポイントを呼び出してステータスコードを確認するだけのものではありません。1 つのテストケースで、リソースのライフサイクル全体を検証します。

このテストが興味深いのは、DELETE のレスポンスだけを信用していない点です。多くの素朴なテストスイートは 200 ステータスコードを確認するだけで止まります。「サーバーが成功したと言ったのだから、成功した」というわけです。しかしそれは状態が実際に変化したかどうかを何も証明していません。バグのあるサーバーは 200 を返しつつ、レコードの削除に静かに失敗するかもしれません。

本当に消えている、ということです。

その代わりに、Kiro は 3 段階のテストを生成しました。

Arrange：既知の ID を持つ新しい pet を POST し、正常に作成されたことを確認します。
Act：その pet を DELETE し、サーバーが操作を受け付けたことを検証します。
Verify：同じ ID を GET し、サーバーが 404 を返すことを検証します。

このパターンは「ラウンドトリップ検証」と呼ばれることがあり、うわべだけのテストと意味のある統合テストを分けるものです。API の状態が実際に遷移することを証明します。すなわち、存在するリソースは破棄でき、いったん破棄されれば本当に消えているということです。スタックのどこかの層（ルーティング、ハンドラのロジック、データストア）が削除を黙って取りこぼしても、GET による検証がそれを捕まえます。

これはテストが自己完結している好例でもあります。テストは、先行するテストによって書き換えられたかもしれないシードデータに依存するのではなく、自分自身でテストデータを用意します。これにより、テストの合否が実行順序に左右されなくなります。テストごとに状態をリセットしないスイートでは、これは小さくとも重要な品質シグナルです。

実 API に対して実行する

生成されたテストがモックの外でも通用するかを検証するには、1 つの環境変数を設定するだけで、開発者はスイートを実際の Petstore サーバーに向けることができます。

PETSTORE_URL=https://petstore.swagger.io npm test

あるいは Kiro に「Run the tests with the real server」とプロンプトを与えます。これにより、コードを変更することなくまったく同じテストが実行されますが、対象がローカルの Express モックではなく実稼働の共有バックエンドになります。

失敗が発生したとき、それらは通常いくつかの認識可能なカテゴリに分類されます。

実 API が仕様より寛容な場合。Swagger 定義では不正な入力に対して 405 を文書化していても、実サーバーはそれを静かに受け入れて 200 を返すことがあります。モックの方が現実より厳しかったというわけです。
エラーコードの意味が異なる場合。モックは非数値 ID に対して 400 を返すかもしれませんが、実サーバーは 404 を返すかもしれません。どちらも擁護可能です。同じ仕様の異なる解釈を表しているだけです。
レスポンス形状が期待と一致しない場合。テストが文字列として期待するフィールドが JSON オブジェクトとして返ってきたり、ネストされたプロパティが完全に欠落していたりします。
共有状態の前提が崩れる場合。シードされたデータ（事前にロードされたユーザーや pet など）に依存するテストは、実サーバーがそれらのテストデータを持たないために失敗します。

このようなことが起きたときの推奨は、失敗をやみくもに「修正」しないことです。代わりに、それぞれを切り分けの問いとして捉えます。モックが間違っているのか、テストが間違っているのか、ドキュメントが間違っているのかということです。そこから次のように進めます。

実サーバーがより寛容な場合は、モックを緩めて合わせるか、テストをモック専用としてタグ付けするかを判断します。
エラーコードが異なる場合は、単一の信頼できる情報源（通常は実サーバーの実際の振る舞い）に揃え、モックとテストの期待値の両方を更新します。
共有状態が問題である場合は、テストを自己完結型にします。検証前に自分自身でテストデータを用意し、ローカルにしか存在しないデータに依存しないようにします。

ポイントは、初日から両モードで全テストを通すことではありません。両方のターゲットに対して実行することで、前提が現実から乖離している箇所が浮かび上がり、そのギャップを埋める道筋が体系的に得られるということです。

認証された内部 API に適応する

Petstore API は認証を求めないパブリックなサンドボックスです。一方、実際の社内 API はほとんどの場合認証を必須とします。認証付きエンドポイントにこのアプローチを適応させる方法を示します。

まず、認証設定に対応できるようにテスト設定を拡張します。資格情報をハードコードするのではなく、外部から渡せるようにすることで、同じスイートを複数の環境で動かせるようにします。

// config.js
module.exports = {
  baseURL: process.env.API_BASE_URL || 'http://127.0.0.1:3000',
  auth: {
    type: process.env.AUTH_TYPE || 'none', // 'none', 'bearer', 'apiKey', 'basic'
    token: process.env.AUTH_TOKEN,
    apiKey: process.env.API_KEY,
    apiKeyHeader: process.env.API_KEY_HEADER || 'X-API-Key',
    username: process.env.AUTH_USERNAME,
    password: process.env.AUTH_PASSWORD,
  },
};

次に、設定された認証タイプに基づいて適切な資格情報を付与する共有クライアントファクトリーを構築します。

// client.js
const axios = require('axios');
const config = require('./config');
function createClient() {
  const headers = {};
  switch (config.auth.type) {
    case 'bearer':
      headers['Authorization'] = `Bearer ${config.auth.token}`;
      break;
    case 'apiKey':
      headers[config.auth.apiKeyHeader] = config.auth.apiKey;
      break;
    case 'basic':
      const encoded = Buffer.from(
        `${config.auth.username}:${config.auth.password}`
      ).toString('base64');
      headers['Authorization'] = `Basic ${encoded}`;
      break;
  }
  return axios.create({
    baseURL: config.baseURL,
    headers,
    validateStatus: () => true,
  });
}
module.exports = { createClient };

これで、すべてのテストファイルが共有クライアントを使用し、資格情報はコードの外に保たれます。

    # トークン認証のステージング API に対して実行
    AUTH_TYPE=bearer AUTH_TOKEN=eyJhbG... API_BASE_URL=https://api.internal.example.com npm test
    # API キーで保護されたサービスに対して実行
    AUTH_TYPE=apiKey API_KEY=sk-live-abc123 API_BASE_URL=https://gateway.internal.example.com npm test

これを整えれば、認証の強制そのものを検証する専用テストも追加できます。資格情報なしのリクエストが拒否されること、期限切れトークンが 401 を返すこと、不十分なスコープが 403 を返すことなどです。これらは Petstore のサンドボックスでは試せないものの、内部サービスではしばしば最も重要となるテストです。

Kiro ヘッドレスモードでテスト再生成を自動化する

テストスイートを一度生成できるだけでも有用ですが、本当の価値は、API が進化しても両者を同期させ続けられる点にあります。Kiro CLI のヘッドレスモードを使えば、CI/CD パイプラインから Kiro をプログラムで実行できます。ブラウザもインタラクティブな端末も不要です。API キーを環境変数として設定し、プロンプトを渡せば、Kiro が一連の処理をエンドツーエンドで実行します。

まとめ

本記事では、Kiro を使って Swagger 仕様から完全な Node.js API テストスイートを数秒で生成する方法を示しました。生成されるプロジェクトには、HTTP テストクライアント、Express のモックサーバー、モック API と実 API を切り替える設定トグル、テストレポートが含まれ、外部のテストフレームワーク依存はありません。

このアプローチは、API 仕様をテストコードに手作業で翻訳する手間を取り除き、包括的な API テストカバレッジを達成するための体系的で再現可能な方法を提供します。Swagger または OpenAPI 仕様を持つあらゆる API に同じパターンを適用できます。

Kiro を始めるには、kiro.dev をご覧ください。

翻訳は Solutions Architect の吉村が担当いたしました。

実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 博多編（#6/8）開催レポート

Rie Tanaka — Mon, 29 Jun 2026 01:57:55 +0000

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中里絵です。

本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「AWS Local Executive Roadshow」シリーズの第 6 回レポートです。シリーズの背景や全体像については、初回の大阪・事業会社編レポートをご覧ください。

大阪・名古屋・広島に続き、2026 年 4 月 28 日は福岡にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜」と題したイベントを開催しました。

イベントの流れ

当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については初回の大阪・事業会社編のレポートをご覧ください。

写真: ソリューションアーキテクト木村によるオープニングセッション

AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、実際に社内への生成 AI 展開に取り組まれた企業様に、その現場で得られた知見をお話しいただきました。

事例紹介：株式会社オーレックホールディングス様〜「禁止から活用へ」中堅製造業の現場主導 AI 展開〜

事例紹介は株式会社オーレックホールディングス様です。福岡県八女郡広川町に本社を置く農業機械・草刈り機のメーカーで、グループ全体での従業員数は約 580 名、創業 1948 年の中堅企業です。乗用草刈り機の部門で国内トップクラスのシェアを持ち、フランスの農業機械ブランドの展開を含めグローバルに事業を展開されています。当日は AWS 木村がモデレーターを務め、経営本部ソリューションシステム部の岡原徹様・月足浩騎様・次郎丸雪衣様に、実際に社内で進められている生成 AI の展開についてパネルディスカッション形式でお話しいただきました。

きっかけは、全社的な AI 活用の方針転換

お取り組みのきっかけは、2024 年 7 月、社長から「競争力強化のため、安全な環境で生成 AI を積極的に活用していこう」という方針が打ち出されたことでした。実は、オーレックホールディングス様は、生成 AI が話題になり始めた 2022〜2023 年頃、社内情報が外部に学習されることに対する懸念から、社員による生成 AI の利用を一律で禁じていた経緯がありました。しかしながら、生成 AI の活用が世の中的にどんどん広がる中で、「禁止しているだけでは取り残されて競争力が落ちてしまう」という認識に変わり、安全な基盤のもとで活用していこうという方針の転換を経て、AI 活用のプロジェクトが始まりました。

セキュアな基盤と、社員のリテラシー向上の両輪で

AI 活用を推進するにあたり、同社が重視したのは 2 つの柱です。1 つ目は、セキュアな AI 基盤を社内に整備すること。2 つ目は、利用者となる社員の AI リテラシーを引き上げることです。ツールを配るだけでは、機密情報の意図しない入力や、AI のハルシネーションを鵜呑みにしてしまうといったリスクが残ります。安心して使える基盤の構築と、正しく使うための教育を同時に進める方針を立てました。

社内 IT 基盤のツールとして選定したのが、AWS が公開する OSS の生成 AI アプリケーション Generative AI Use Cases(GenU) です。選定の決め手は「セキュアに利用できること」と「スモールスタートできる価格設定」の 2 点でした。経営層の方々は、AI 活用の初期の段階から大きな投資をするのではなく、効果を見極めながら段階的な投資をしたいという考え方があったため、トークン単位の従量課金で、比較的安価に利用開始できる GenU がニーズに即していると考えました。また、GenU は、すぐ使えるユースケースがあらかじめ用意されていて、非 IT の担当者でも使い方のイメージが持てた点も選定のポイントになりました。選定から導入までスピード感を持って進め、2024 年 12 月末には導入を完了、運用をスタートさせることができました。

「触ってもらう」から始めた段階的展開

展開にあたって、社員の皆様に段階的に利用を開始してもらうアプローチを取りました。AI 活用の第一期生として、英文ライティングが多い海外営業部門、すでに個人的に生成 AI を使っていた社員を含む 56 名に AI のアカウントを配布しました。少人数で自由に AI を活用した業務課題解決を探索してもらうことで、ユースケースの発見を促すとともに、早期のリスクの洗い出しにもつなげる戦略を取りました。その後、効果が出てきたタイミングで、第二期生として部課長や開発部門など 35 名に追加配布、さらに希望者には都度配布…といったように、利用範囲を段階的に拡大しました。

アカウント配布と同時に、AI の勉強会を実施しました。AI の得意不得意、業務利用時の注意点、プロンプトの作り方の基礎を利用者部門に伝え、より効果的な活用を促しました。さらに、「利用者同士の座談会」を開催し、活用率の高い社員が日頃どのように使っているかをざっくばらんに話してもらう機会を設けたり、アンケートを通して横展開を支援したりなど、細やかなケアを続けていきました。

もう一つ、ユニークな取り組みとして、チャットボットの名前を公募で選定した点を挙げられました。全社員が親しみを持てるよう、自社製品の乗用草刈り機「ラビットモアー」にちなんでウサギのキャラクターを設定し、名前を公募しました。最終的に、「AI ちゃびっと」という名称で社内で親しまれるようになりました。今では名前とキャラクターが広く浸透、定着しています。公募という形にしたことで、社員が自分たちのプロジェクトとして参加意識を持てたことも浸透を後押しできたと考えています。

成果：全社員の 40% が自発的に使い始めた

現在の利用状況は、全社員の約 40 %にあたる 200 名が活用しています。そのうち 100 名以上は「自分で使いたい」と手を挙げて始めたメンバーです。当初想定していた文章作成や検索だけでなく、特許調査への組み込み、営業向けのプロンプトの定型化、法令チェック、温暖化係数の計算・ライフサイクルアセスメント解析といった、より専門的な業務での活用まで広がっています。方針が出た時点では社内のどの業務に AI を使えるかというイメージが全く持てなかった状態からのスタートでしたが、情報システム部が一つひとつユースケースを発掘するのではなく、現場が自分たちの課題に AI を当てはめて使い方を見つけてくれた結果でした。

一方で残る課題として、3 点を率直に話していただきました。1 点目はリソース不足で、他のプロジェクトとの兼ね合いで生成 AI の推進が後回しになりやすいこと、また同じ立場で AI 展開を進めている社内外の仲間が少ないこと。2 点目は効果測定の難しさで、AI 活用の成果を定量的に示す手段がまだ整っていないこと。3 点目は社員の皆様への継続的な AI の知見のアップデートです。業務ツールへの AI 組み込みが増える中、継続的な取り組みの重要性を語っていただきました。月足様からも、「AI が質問者に寄り添った回答をしてしまう」という特性があるため、AI のリスクを正しく理解し、最終判断はあくまでも人間が下すという姿勢を社内に根付かせていく必要性を語られました。

横展開を支えた「信頼の土台」

岡原様は、「普段からクロスファンクションでコミュニケーションを取っていて、工場にはデジタルサイネージを設置して IT 部門の活動を発信していた。『IT 部門に頼めば、きっと期待に応えてくれる』という、社員の皆様からの信頼の土台があったから、今回の横展開もうまくいった」と振り返られました。AI のプロジェクトが始まる前から積み重ねてきた地道な活動こそが、全社展開の推進力になった——この話は、参加者の皆様にとっても示唆の大きいポイントでした。

写真: 株式会社オーレックホールディングス岡原様・月足様・次郎丸様、AWS 木村（営業）によるパネルディスカッション

まとめ

セッション後には参加者同士のグループワーク・ディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。「IT に詳しくない担当者が手探りで進めた」というリアルな話に共感の声が多く、「同じ悩みを持つ方と話せた」「自分たちだけじゃないと安心した」といった声をいただきました。製造業・中堅企業という条件の中でも、小さく始めて着実に広げていくアプローチが確かに機能することを示してくれたセッションでした。

このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした福岡編に続き、次回は北海道編を予定していますので、どうぞお楽しみに。

そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。

執筆者

Amazon Web Services Japan 合同会社ソリューションアーキテクト　田中里絵

週刊生成AI with AWS – 2026/6/22 週

Aiichiro Noma — Sun, 28 Jun 2026 22:34:21 +0000

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。

先週末、6月25日、26日に AWS Summit Japan 2026 が開催されました。今年も多くのお客様にご来場いただき有り難うございました。生成AI、Physical AIに関する説明やデモが多く展示され、このブログの読者の皆様はイベントを楽しめて頂けたのではと思います。AWS Summit のセッションは､オンデマンド視聴が開始されています｡当日のご参加が出来なかった方や、ご来場頂いた方で視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただければ幸いです｡

それでは 6月 22日週の生成 AI with AWS界隈のニュースを見ていきましょう。

さまざまなニュース

- AWS 生成 AI 国内事例ブログ「店舗の気づきを本部に届ける AI エージェント SMART のご紹介 — Amazon Bedrock AgentCore × Strands Agents によるユナイテッドアローズでの取り組み」
  店舗スタッフの気づきを AI が引き出して言語化し、本部に届けることを支援する AWS サンプルアセット「SMART（Store Manager Agent for Retail Tech）」と、それを活用したユナイテッドアローズの取り組みを紹介する記事です。本部が設定した「問い」を起点に AI が「なぜ」を深掘りし、対話を店舗名・日付・カテゴリといった構造化データに変換して、売上などの定量データと掛け合わせたインサイトを翌朝に届けます。ユナイテッドアローズでは、SMART をベースに Kiro を活用して内製でカスタマイズし、4 店舗で PoC を実施しました。「昨日の店舗がどうだったかを人に聞かなくても把握できる」「AI の深掘りでスタッフに考える習慣が広がった」といった声が寄せられ、本部側でも現場ヒアリングの時間削減や売上向上につながる気づきが得られたとしています。
- ブログ記事「Amazon Bedrock AgentCore での Web Search を発表: AI エージェントを最新かつ正確なウェブ知識に基づかせる」
  Amazon Bedrock AgentCore の Web Search が一般提供を開始しました。保護された AWS 環境からデータを外部に持ち出すことなく、出典が明示された最新のウェブ知識に基づいて応答を生成できるフルマネージドツールです。MCP（モデルコンテキストプロトコル）を使う Bedrock AgentCore Gateway の組み込みコネクタターゲットとして提供され、自然言語クエリに対して関連スニペット、ソース URL、タイトル、公開日を返します。標準的なウェブ検索に加えて Amazon Knowledge Graph も組み合わせるマルチソースグラウンディングを採用しているため、ウェブ検索のみの場合より関連性が高く正確な応答を得やすいとしています。外部の検索 API プロバイダーにユーザープロンプトや検索クエリを送らずに済むため、エンタープライズのガバナンス要件にも対応できます。米国東部（バージニア北部）リージョンで一般提供を開始しました。
- ブログ記事「より高速かつ正確なエンタープライズ AI アプリケーションを実現する Amazon Bedrock マネージドナレッジベースのご紹介」
  所有データを使ってエンタープライズグレードの生成 AI アプリケーションを数分で構築できる、Amazon Bedrock マネージドナレッジベースが発表されました。RAG パイプラインに必要なストレージ・検索・埋め込み・再ランキング・基盤モデルの選択を単一のマネージドプリミティブに抽象化し、デフォルトでサービスが各モデルを自動選択・管理するため、すぐに使い始められます。主な特長は 3 つです。Amazon S3、SharePoint、Confluence、Web Crawler、Google Drive、OneDrive をサポートする 6 つのネイティブデータコネクタ、データタイプやコネクタに応じて最適な解析戦略を自動で選ぶ Smart Parsing、そして単一・複数のナレッジベースをまたぐマルチターン/マルチホップ検索に最適化された Agentic Retriever です。AgentCore Gateway の事前構築済みターゲットとして数行のコードで統合でき、ロールベースの権限が自動生成されます。米国東部（バージニア北部）、米国西部（オレゴン）、東京リージョンを含むアジアパシフィック（シドニー、東京）、欧州（ダブリン、フランクフルト、ロンドン）、AWS GovCloud（米国西部）で利用できます。
- ブログ記事「AWS DevOps エージェントで、本番前にコード変更を評価するためのリリース管理機能が追加 (プレビュー)」
  AWS DevOps エージェントに、本番前にコード変更を評価するリリース管理機能がプレビューで追加されました。デプロイ後の運用（インシデントの自律調査や根本原因分析）はすでに一般提供されており、今回はコード変更の「リリース準備状況レビュー」と「自律リリーステスト」が加わりました。リリース準備状況レビューは、自然言語で指定した社内標準やベストプラクティスに照らして変更を評価し、リポジトリ間の依存関係リスクや AWS Well-Architected に沿ったアクセスコントロールの確認、コミット前の破壊的変更の検出を行います。結果は「ブロック」「注意して続行」「安全にリリース可能」のいずれかで示され、コンソールや GitHub／GitLab のプルリクエストへのコメント、さらに Kiro パワーや Claude Code プラグイン経由で IDE から直接確認できます。自律リリーステストは、変更内容を推論して固有のテストプランを生成し、本番のような環境で実行します。米国東部（バージニア北部）リージョンで、プレビュー期間中は追加料金なしで利用できます。
- ブログ記事「AWS セキュリティエージェントで、脅威モデリング、Kiro パワー、Claude Code プラグインなどが追加」
  開発ライフサイクル全体でアプリケーションを保護する AWS セキュリティエージェントに、新しい機能が追加されました。コードレビューはプルリクエストスキャンに対応し、GitHub に加えて GitLab、Bitbucket、Confluence と連携できるようになりました。新たな脅威モデリング（プレビュー）は、設計ドキュメントやソースコードを分析してアプリケーションのアーキテクチャを理解し、STRIDE フレームワークで脅威を特定して緩和策を提示します。また、Kiro パワーと Claude Code プラグイン（近日リリース予定）、オープンな MCP 統合により、IDE や CLI から直接コードレビューや脅威モデル生成、検出結果の修正を行い、結果をインラインで確認できます。AWS セキュリティエージェントが利用できる AWS 商用リージョンで使え、2 か月間の無料トライアルが用意されています。
- ブログ記事「コーディングは不要 ― ビジネスユーザーこそが顧客体験の新たな設計者に」
  顧客体験（CX）の設計を、エンジニアではなく顧客を理解するビジネスユーザーが主導できるようにする、という考え方を記載した記事です。これまで CX 業務は「キュー（待ち行列）」を前提に運営され、ビジネス側が作りたい体験もエンジニアリングのチケット待ちがボトルネックになっていましたが、エージェンティック AI がこの制約を変えつつあるとしています。記事では、企業が正しく取り組むべき 3 点として、機能単位ではなく顧客ジャーニー全体を支える統合アーキテクチャ、決定論的な処理とエージェンティックな推論を同一のガバナンス下で共存させること、そしてビジネスユーザーに設計の主導権を渡すことを挙げています。あわせて、コード不要でエンドツーエンドの対話体験を視覚的に構築できる Agentic CX Designer（プレビュー）と、音声と画面表示をリアルタイムに同期する特許技術 Live Sync（プレビュー）を、Amazon Connect Customer の機能として紹介しています。また Saks Fifth Avenue でビジネスアナリスト主導で 6 週間での本番稼働を実現した例が示されています。
- ブログ記事「Amazon CloudWatch と OpenTelemetry による Claude Code 利用状況の分析」
  Claude Code のような AI コーディングエージェントの利用状況を、Amazon CloudWatch と OpenTelemetry で可視化する手順を解説した技術記事です。CloudWatch の OpenTelemetry Protocol（OTLP）が一般提供となり、ベアラートークン認証でメトリクスを取り込めるようになったため、コレクターやサイドカー、開発者マシンでの IAM 認証情報の配線なしに、認可ヘッダー 1 つで CloudWatch へメトリクスを直接送信できます。記事では、CloudWatch メトリクス API キー（ベアラートークン）の作成から Claude Code 側の環境変数設定、メトリクスの確認、構築済みダッシュボードのデプロイまでを一通り示しています。ダッシュボードはトークン使用量、開発者の生産性、部門・チーム別のコスト配分、Amazon Bedrock API の健全性などを PromQL で可視化でき、個人の支出スパイクやチーム予算超過、利用減少を検知するアラート例も紹介されています。
- ブログ記事「Accelerating Smart Product SDLC with AI Agent Workshop のご紹介」
  IoT やコネクテッドデバイスの普及で「スマートプロダクト」へと進化する製造業向けに、組込みソフトウェア開発のライフサイクル全体（Research → Plan → Development → Release → Operation）で AI エージェントを活用するワークショップを紹介する記事です。コーディングだけを速くしてもライフサイクル全体のボトルネックは解消されない、という課題意識から、各フェーズ固有の壁を越えるアプローチを提案しています。生成AI を「制御可能・追跡可能・学習可能」な形で開発全域に組み込むことを狙いとしています。
- ブログ記事「NVIDIA RTX PRO 4500 Blackwell Server Edition GPU で高速化された Amazon EC2 G7 インスタンスのご紹介」を公開
  AI 推論、グラフィックス、データ分析向けの Amazon EC2 G7 インスタンスが一般提供を開始しました。AWS は NVIDIA RTX PRO 4500 Blackwell Server Edition GPU をサポートする最初の主要クラウドプロバイダーで、第 6 世代のカスタム Intel Xeon Scalable プロセッサと組み合わせ、前世代の G6 比で最大 4.6 倍の AI 推論性能、最大 2.1 倍のグラフィックス性能を実現します。AI 推論やグラフィックスレンダリング、動画トランスコーディング、VDI、データ分析など幅広い用途に向きます。米国東部（オハイオ）、米国西部（オレゴン）の各リージョンで、オンデマンド、Savings Plans、スポットの購入オプションで利用できます。
Kiro関連
- ブログ記事「Kiro Web の Automations 機能のご紹介」
  ブラウザで使える Kiro Web に、クラウドで動作する Automations 機能が追加されました。依存関係の更新やドキュメントの追従、テストカバレッジの確認など、決まった間隔で繰り返し発生するタスクを Kiro に任せられます。Automations は自律型エージェントが管理し、実行ごとにサンドボックス内で autonomous セッションを作成して、完了すると自動でプルリクエストを開きます。設定は、タスクに名前を付けて GitHub または GitLab（両方も可）のリポジトリを選び、実行内容を記述してスケジュールを決めるだけです。1 つの Automation につき最大 5 つのスケジュールを設定でき、Daily・Weekly などの組み込みオプションのほか cron 式も使えます。古くなったドキュメントの更新、テスト未カバーのパスへのテスト生成、古い TODO／FIXME の整理といった使い方が示されています。
- ブログ記事「Kiro でテスト駆動開発（TDD）：こうあるべき体験」を公開
  テスト駆動開発（TDD）の利点は理解していても、テストと実装の往復や規律の維持、テストを書く単調さが負担になりがちです。この記事は、Kiro の hook（IDE の特定イベントで自動実行される仕組み）を使って、red-green-refactor サイクルを Kiro に徹底させることで、その負担なく TDD の恩恵を得る方法を紹介しています。ファイル保存前に発火する hook を作り、テストを先に書いて失敗（red）を確認してから最小限の実装（green）に進むよう Kiro に促す、という設定例が具体的なプロンプトつきで示されています。
- ブログ記事「Agent Focus のご紹介」を公開
  Kiro IDE に、エージェントとの対話を中心に据えた実験的な新ビュー「Agent Focus」が導入されました。やりたいことを説明し、会話で調整し、作業を開始して進捗を確認する、というチャットファーストの進め方を実現します。画面は 3 つのパネルで構成されます。新規セッションの作成やワークスペース別の状態（作業中・入力待ち・一時停止）を確認する Agents パネル、ファイル変更をインラインの差分で表示する Chat パネル、変更ファイルやスペック要約を必要時に表示する Auxiliary パネルです。複数セッションを並行して独立に動かせ、設定や powers、skills、MCP、ターミナル、直接のファイル編集など IDE 側の機能へもすぐ戻れます。最新の Kiro 1.0 に実装されており、使用するにはダウンロードページからの更新が必要です。
- ブログ記事「Kiro で OpenAPI／Swagger 仕様から数秒でテストスイートを生成」
  OpenAPI／Swagger 仕様（JSON または YAML）を入力すると、Kiro が Node.js のテストスイートを自動生成する手法を解説した記事です。スタブを埋める必要のある従来のコード生成ツールとは異なり、Kiro は仕様の内容を推論し、スキーマ契約に紐づくアサーションを備えた、実行可能なテストを生成します。生成されるのは単体テストではなく、axios で実際の HTTP リクエストを行う統合テストで、ローカルのモックサーバー（Express）と切り替えられる設定や、軽量なテストランナー、HTML レポートが含まれます。たとえば DELETE のテストでは、POST → DELETE → GET と連鎖させて削除後に 404 が返ることまで検証します。環境変数を変えるだけでライブ API に対しても同じテストを実行でき、認証付き API への適応や、.kiro/steering/ のステアリングファイル、CLI のヘッドレスモードによる CI/CD への組み込みも紹介されています。
- ブログ記事「1 つのセッションで GitLab と GitHub にまたがる変更を調整する」
  Kiro Web が GitLab に対応し、既存の GitHub 対応と合わせて、両プロバイダーのリポジトリを 1 つのセッションに追加できるようになりました。1 つの変更を記述すると、Kiro が両方のリポジトリに反映し、GitLab 側にはマージリクエスト、GitHub 側にはプルリクエストを自動で作成します。コードが 2 つのプロバイダーに分かれていると、両方にまたがる変更で手順を忘れて同期がずれるリスクがありますが、Kiro が横断的に変更を調整することでこれを防ぎます。記事では、GitLab の非公開サービスと GitHub の公開 SDK に、エンドツーエンドで email フィールドを追加する例を紹介しています。Kiro Web はプレビュー版で、Pro、Pro+、Power のサブスクライバー向けに提供されています。

サービスアップデート

- Amazon Bedrock AgentCore Memory がクロスアカウントアクセスに対応
  Amazon Bedrock AgentCore Memory が、クロスアカウントアクセスに対応しました。メモリリソースと、それを利用するエージェントが複数の AWS アカウントにまたがるマルチアカウント構成を組めるようになります。リソースベースのポリシーをメモリリソースにアタッチすることで、あるアカウントのプリンシパルに、別アカウントのリソースに対してメモリのデータプレーン API を呼び出す権限を付与できます。設定後は、利用側アカウントのプリンシパルが、完全なメモリ ARN を参照してイベントの作成、メモリレコードの書き込み・取得、セマンティック検索を実行できます。また、メモリの配信先（Amazon S3、Amazon SNS、Amazon Kinesis Data Streams）を別アカウントに置く構成も可能で、ペイロードの配信やイベントのストリーミングを他アカウントのリソースに対して行えます。Amazon Bedrock AgentCore Memory がサポートされるすべての AWS リージョンで利用できます。
- Amazon Bedrock Guardrails の Automated Reasoning checks に新しいポリシー改善ワークフローが追加
  Amazon Bedrock Guardrails の Automated Reasoning checks に、ポリシーを自動で改善するワークフローが追加されました。Automated Reasoning checks は形式論理を使って生成 AI の応答の正確性を、定義したポリシーに照らして数学的に検証する機能で、ハルシネーションの検出や検証可能な説明の提示に役立ちます。検証結果の質はポリシーの定義の良し悪しに左右されるため、今回の機能で手作業を減らしながらポリシーを改善できます。追加されたのは 2 つのワークフローです。反復的なポリシー改善ワークフローでは、ポリシー向けに自然言語のテストを作成したお客様が反復改善を実行し、それらのテストにパスするために必要な変更をシステムに導き出させられます。曖昧さ削減ワークフローでは、曖昧な変換結果が頻発する場合に、変数の説明や型定義を自動的に調整して曖昧な変換の発生を減らせます。Automated Reasoning checks が利用できるすべての AWS リージョンで使えます。
- Amazon SageMaker Studio ノートブックが G7e インスタンスタイプに対応
  Amazon SageMaker Studio ノートブックが、Amazon EC2 G7e インスタンスに対応しました。G7e は最大 8 基の NVIDIA RTX PRO 6000 Blackwell Server Edition GPU（GPU あたり 96GB メモリ）と第 5 世代 Intel Xeon プロセッサを備え、最大 192 vCPU、最大 1600 Gbps の Elastic Fabric Adapter ネットワーキング帯域幅をサポートします。大規模言語モデル（LLM）やエージェント型 AI、マルチモーダル生成 AI、フィジカル AI モデルのデプロイに使え、空間コンピューティングや、グラフィックスと AI 処理の両方を要するワークロードで高い性能を発揮します。米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）の各リージョンで利用できます。
- Amazon SageMaker ノートブックインスタンスが G6e インスタンスタイプに対応
  Amazon SageMaker ノートブックインスタンスで、Amazon EC2 G6e インスタンスが一般提供されました。G6e は最大 8 基の NVIDIA L40s Tensor Core GPU（GPU あたり 48GB メモリ）と第 3 世代 AMD EPYC プロセッサを搭載し、EC2 G5 インスタンスと比べて最大 2.5 倍の性能を発揮します。モデルデプロイのインタラクティブなテストや、生成 AI のファインチューニングといったインタラクティブなモデル学習に利用でき、最大 130 億パラメータの大規模言語モデル（LLM）や、画像・動画・音声を生成する拡散モデルのデプロイに使えます。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、中東（ドバイ）、欧州（フランクフルト、スウェーデン、スペイン）の各リージョンで利用できます。
Kiro関連
- Kiro が AWS GovCloud (US) で FedRAMP High および DoD IL-4/5 認証を取得
  Kiro が、AWS GovCloud (US) リージョンで FedRAMP High および米国国防総省クラウドコンピューティングセキュリティ要件ガイド（DoD CC SRG）の Impact Level（IL）4 および 5 の認証を取得しました。これにより、FedRAMP High や DoD CC SRG IL-4/5 のコンプライアンス要件を持つ連邦機関や公共部門の組織、企業が、機密性の高いワークロードに求められるセキュリティ・コンプライアンス基準を満たした形で、Kiro をエージェント型の開発パートナーとして利用できます。
- Kiro-CLI : 設定のホットリロードとリソース継承の制御
  Kiro CLI 2.10 では、MCP まわりの繰り返し作業の手間を減らし、カスタムエージェントの作者にコンテキストの制御手段を提供します。エージェントと MCP の設定が、ディスク上で変更を保存するとホットリロードされるようになりました。エージェント設定の編集や新規エージェントファイルの追加、mcp.json の変更が、セッションを再起動せずに反映されます。再起動するのは影響を受けたサーバーのみで、会話のコンテキストは保持されます。設定の差分は順序に依存しないため、環境変数を並べ替えても不要な再起動は起きません。また、新しい設定 chat.disableInheritingDefaultResources が追加されました。カスタムエージェントがデフォルトの steering、skills、AGENTS.md を継承しないようにする設定で、グローバルリソースを取り込みたくない場合に true にします。v2.7.0 以降、カスタムエージェントはデフォルトリソースを自動的に継承していましたが、この設定でその継承をオフにできます。
- Kiro-CLI : V3 (Early Access) の安定性修正と Entra ID のセッション更新
  Kiro CLI 2.9 では、Entra ID（Azure AD）ユーザーのセッション期限切れの問題を修正しました。あわせて、V3 (Early Access)における複合シェルコマンドの承認プロンプトのループを解消し、サブエージェント呼び出し向けにコンパクトなツールカードのプレビューを追加しています。
- Kiro-IDE : Agent Focus、権限、カスタムエージェント、その他のアップデート
  Kiro IDE 1.0 では、複数の機能が追加されました。実験的機能の Agent Focus は、チャット中心のレイアウトで複数のエージェントを並行して操作でき、セッションは独立・並列に動作し、ファイル変更はインラインの差分で表示されます。Spec、Plan、Bug Fix、Quick Spec といった構造化ワークフローやフリーフォームのチャットから開始でき、従来の IDE とは右上からワンクリックで切り替えられて、作業内容は双方向に引き継がれます。

最後に、「AWS ジャパン生成 AI 実用化推進プログラム」も引き続き実施中ですので検討してみてください。

今週は以上です。それでは、また来週お会いしましょう！

著者について

Amazon Quick on Desktop が東京リージョンに対応 – AWS Summit New York 2026 アップデート –

Hiroaki Hattori — Fri, 26 Jun 2026 05:47:48 +0000

この度、Amazon Quick on Desktop が AWS アジアパシフィック (東京) リージョンでプレビュー利用可能になりました。2026年3月の東京リージョンローンチに続き、4月にプレビュー公開されたデスクトップアプリケーションも東京リージョンに対応しています。これにより、日本のお客様はデータを国内に保持しながら、デスクトップ上でよりパーソナルでプロアクティブな AI アシスタント体験を実現できます。

“Amazon Quick on Desktop は、本ブログ投稿時点では Preview であり、機能・仕様が変更される場合がございます。”

Amazon Quick on Desktop とは

Amazon Quick on Desktop は、Amazon Quick をブラウザの枠を超えてお使いのコンピュータにネイティブに展開するデスクトップアプリケーション (macOS / Windows 対応) です。ローカルファイルへの直接アクセス、OS レベルのプロアクティブ通知、バックグラウンドエージェント、ブラウザ自動化、パーソナルナレッジグラフといった機能を備えています。

Quick on Desktop でできること

ローカルファイルと直接連携 : チャットエージェントにアップロード不要で、許可したフォルダ内のファイルを読み書き・検索・インデックス化。ドキュメント作成やデータ分析もローカルファイルを直接参照して実行できます。
バックグラウンドエージェント : スケジュールに基づいて自動実行されるエージェントが、チャネル監視・メールトリアージ・ミーティング要約・インシデント追跡などを代行します。
プロアクティブ通知とアクティビティフィード : 接続サービスを監視し、重要な情報をデスクトップに通知。アクティビティフィードで優先度順に一覧表示します。
ブラウザ自動化 : Chrome を起動・制御し、Web フォーム入力、スクリーンショット取得、データ抽出、Web アプリとの連携を Quick に委任できます。
パーソナルナレッジグラフ : Slack メッセージ、メール、カレンダーなどの連携サービスおよびローカルファイルからエンティティと関係性を自動抽出し、あなた専用のナレッジグラフを構築。Quick の回答がよりユーザーに沿ったものとなります。
MCP サーバー接続 : Model Context Protocol (MCP) で外部ツールやコーディングエージェントと連携し、Quick の能力を拡張できます。
ドキュメント生成 : Word、Excel、PowerPoint などをチャットから直接生成できます。

ローカルファースト・アーキテクチャ

Quick on Desktop は ローカルファースト・アーキテクチャ を採用しています。AI バックエンドはお手元のマシンで実行され、ファイルもローカルに留まります。ネットワーク通信は API Gateway 経由の AI モデル呼び出し と、接続済みサービス (Slack, Outlook, Gmail 等) への通信 のみです。この設計により、プライバシーを保護しつつ Quick の機能を活用できます。

東京リージョン対応のメリット

1. 国内データレジデンシー

データが日本国内の AWS インフラストラクチャに留まるため、個人情報保護法 (APPI) やお客様組織の内部ガバナンス要件を満たしやすくなります。

2. JP-CRIS による国内推論

JP-CRIS (Japan Cross-Region Inference) により、東京リージョンからの推論リクエストは 東京 (ap-northeast-1) と 大阪 (ap-northeast-3) の AWS リージョン内のみでルーティングされます。推論が日本国外で実行されることはありません。

3. 低レイテンシー

日本国内ユーザーのネットワークレイテンシーが改善され、AI 応答やダッシュボード表示、ワークフローの応答などのパフォーマンスが向上します。

Quick on Desktop の始め方

Amazon Quick on Desktop を始めるのは簡単です。

アカウント作成 : quick.aws.com で Free または Plus アカウントにサインアップします（AWS アカウント不要、メールアドレスのみで登録可能）
アプリダウンロード : ダウンロードページから macOS または Windows 版のデスクトップアプリケーションをインストールします
フォルダ許可 : Quick にアクセスさせたいローカルフォルダを設定します
サービス接続 : Slack、Outlook、Gmail 等のビジネスアプリケーションを接続します
ナレッジグラフ構築開始 : 使い続けるほどコンテキストが蓄積され、よりパーソナライズされた体験になります

エンタープライズ (Professional / Enterprise) アカウントのお客様は、IAM Identity Center による SSO 連携や、管理者によるエンタープライズデプロイも可能です。

エンタープライズセキュリティとガバナンス

Quick on Desktop は、ローカルファーストの設計思想に基づきセキュリティとデータプライバシーを確保しています。

ファイルはローカルに留まる : Quick on Desktop はローカルファースト・アーキテクチャを採用しており、ファイルがクラウドにアップロードされることはありません。ユーザーが許可したフォルダのみアクセスし、いつでもアクセスを取り消せます。
ネットワーク通信は最小限 : ネットワーク通信は API Gateway 経由の AI モデル呼び出しと接続済みサービス (Slack, Outlook 等) への通信のみ。データがモデルのトレーニングに使用されることはありません。
エージェントのガードレール : Autonomous Agent にはエージェントごとに自律範囲を設定でき、意図しないアクションを防止します。
フォルダ単位のアクセス制御 : ローカルファイルへのアクセスはフォルダ単位で許可/取り消しが可能。キーワード検索、セマンティック検索、ナレッジグラフ抽出もフォルダ単位で制御できます。
東京リージョンでの JP-CRIS : AI モデルへの推論リクエストは東京・大阪リージョン内に閉じてルーティングされるため、データが日本国外に出ることはありません。

まとめ

Amazon Quick on Desktop の東京リージョン対応により、日本のお客様はデスクトップ上でも Quick の AI アシスタントを活用しつつ、データ保全と低レイテンシーの恩恵を受けられるようになりました。ローカルファイルとの深い統合、プロアクティブな通知、パーソナルナレッジグラフ、そしてバックグラウンドエージェントによる自動化が、日々の業務を根本から変革します。

ぜひ Amazon Quick on Desktop をお試しください。

著者について

Hiroaki Hattori

Amazon Web Services Japan G.K. の AI Specialist Solutions Architect で、日本における全テリトリーの Amazon Quick を担当している。サウナは 1 ローテが Quick には終わらず、Strong スタイルで楽しんでいる。

CX向上に向けたコンタクトセンター変革 — 全国複数拠点・数千席規模の環境で挑む東京電力エナジーパートナーの Amazon Connect Customer × 生成 AI 活用

Yusuke Hashii — Fri, 26 Jun 2026 05:11:21 +0000

本ブログは東京電力エナジーパートナー株式会社サービスソリューション事業部今野拓也様の監修のもと、アマゾンウェブサービスジャパン合同会社橋井雄介が執筆いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの橋井です。

電気・ガスなど大規模なインフラを提供する企業にとって、コンタクトセンターはお客さまとの重要な接点となっています。だからこそ、その体験の質が企業への信頼に直結します。「コンタクトセンターに生成 AI を導入したいが、大規模環境で実用的な精度が出るのか」「導入後に組織として使いこなせるのか」——そんな課題をお持ちの方に向けて、Amazon Connect Customer（旧 Amazon Connect）と Amazon Bedrock を活用した変革を推進している東京電力エナジーパートナー様（以下、TEPCO EP）の事例をご紹介します。

TEPCO EP が取り組むコンタクトセンターの課題

TEPCO EP は、電力・ガスの小売事業を担い、全国複数拠点・数千席規模のコンタクトセンターでお客さまの契約手続きや問い合わせに対応しています。サービスソリューション事業部は「人 × IT の融合により、パーソナライズされたサポートを安心と感動とともに届ける」というビジョンを掲げ、CX 向上を推進しています。

同社のコンタクトセンターでは、デジタルチャネルの比率が向上する中でも電話が約 4 割を占めており、以下の課題がありました。

IVR（Interactive Voice Response: 自動音声応答）が複雑でオペレーターに繋がるまでの導線がわかりにくい
オペレータースキルと用件のミスマッチが発生しやすい
応対後の処理負荷が大きく、保留や管理者へのエスカレーションも多い
利用システムが拠点ごとに異なり、会話データの横断的な活用が困難

今回、オンプレミス環境の保守期限を迎えてシステムを刷新するタイミングで、CX 向上と業務効率化を同時に実現するプロジェクト「SEEDS（Smart Engagement and Efficient Data System）」を立ち上げました。

図 1 受付チャネルの現状と課題

SEEDS Phase1 で実現したこと

Phase1 では、Amazon Connect Customer をベースとした新たな受電環境を構築し、全国にある拠点のうち 18 拠点の切替を完了しました。

要件整理からリリースまで約 10 ヶ月、拠点切替は約 3 ヶ月で完了しています。できる限り標準機能を活用してスクラッチ開発を最小限にしたこと、生成 AI のチューニングやオペレーター画面の構成は検討開始後、早期から実際の挙動などを確認しながら段階的に精度を高めていくアプローチをとったことが、このスピードの鍵でした。

Phase1 で導入した主な機能は以下のとおりです。

音声テキスト化: お客さまとオペレーターの会話をリアルタイムで文字表示（課題 3, 4 に対応）
会話要約: 生成 AI が応対内容を自動要約し、オペレーターが利用するカスタム CCP（Contact Control Panel）画面に表示（課題 3 に対応）
コールリーズン分析: 通話内容から問い合わせ理由を自動分類し、データ活用を促進（課題 4 に対応）
法令チェック: オペレーターの説明漏れ等を生成 AI で全件自動チェック（課題 3 に対応）
ダッシュボード: リアルタイムの応答状況や実績データを可視化（課題 4 に対応）

図 2 会話要約の活用イメージ

図 3 コールリーズン分析・法令チェックの活用イメージ

技術ポイント: 生成 AI の活用

ここからは、SEEDS の中で技術的にチャレンジングだった要素の一つとして、生成 AI の活用について掘り下げます。

アーキテクチャ設計

Amazon Connect Customer を中心に、AWS Lambda と Amazon Bedrock を連携させた構成です（図 4）。生成 AI の処理を Amazon Connect Customer の外部に配置し Lambda から Amazon Bedrock を呼び出す設計としたのは、AWS マネージドサービスの中で多様な AI モデルを柔軟に活用できるためです。電力・ガス事業特有の表現や複雑な業務ルールに対応するプロンプトを自由に設計・改善できる柔軟性を確保することを重視しました。また、業界知識の深い実務担当者が単独でプロンプトの修正や評価を行える環境を別途用意し、プロンプトの更新の際には直接プログラムを改修せずにプロンプトファイルの差し替えで環境に反映できる構成としています。

なお、同様のユースケースに取り組むお客さまにとっては、Amazon Connect Customer のビルトイン AI 機能（会話要約やテーマ検出など、日本語を含む多言語に対応）を活用し、カスタム実装なしで実現するアプローチも選択肢となります。

図 4 SEEDS Phase1 アーキテクチャ構成（ダイジェスト版）

この構成には、タスクの特性に応じて2つの処理系統を設けています。

リアルタイム系統（会話要約）: 終話後すぐにオペレーターへ結果を返す必要があるため、通話中にストリーミングされるリアルタイム通話テキストを入力とし、高速な応答が得られる Anthropic Claude Haiku（Amazon Bedrock 上で利用可能な軽量・高速モデル）で処理します。レスポンス性を最優先とした設計です。

バッチ系統（コールリーズン分析・法令チェック・VoC 抽出）: 後続の分析処理は翌営業日以降に行われるため、終話後に確定した完全な通話テキストを入力とし、より高い推論能力を持つ Claude Sonnet（同じく Amazon Bedrock 上で利用可能な高性能モデル）で処理します。処理結果の品質を最優先とした設計です。

いずれの系統でも、Amazon Bedrock の Tool use（関数呼び出し）機能を活用し、出力を JSON スキーマに沿った構造化データとして取得しています。自由形式のテキスト出力をパースする方式と比較して出力形式の安定性が高く、後続のデータベース保存やダッシュボード連携を一往復の API 呼び出しで確実に完結させています。

なお、基盤モデルはリリース時点では Claude 3.5 Sonnet / Claude 3 Haiku を使用していましたが、2026 年からはパフォーマンスが向上した Claude Sonnet 4.5 / Claude Haiku 4.5 に更新しています。マネージドサービスの利点として、このようなモデルの進化を迅速に取り込むことができます。

各タスクの実装ポイント

会話要約: 終話後カスタム CCP 画面へ要約を表示します。プロンプト開発時には現場のオペレーターにヒアリングを行い、業務用途を明確にした上で出力フォーマットに反映しました。現場からは「箇条書きで簡潔に読める」「応対後の処理業務などの参考になる」と評価されています。要約情報はオペレーター間の通話転送時にお客さま情報を引き継ぐ用途にも活用されているほか、お客さまの声（VoC）の自動抽出も実施し、従来人手で拾いきれなかった細かなニーズやご不満の声を網羅的に収集できるようになりました。

コールリーズン分析: 64 分類での自動判定を実現し、約 600 件のテストデータで網羅性 95%・正解率 85% と、目標を上回る精度を達成しました。精度向上の工夫として、生成 AI の出力に対してルールベースの後処理を組み合わせ、AI 単体では解消しにくい誤分類を補正しています。分類結果は呼量分析や呼量予測の精緻化に活用され、オペレーター配置計画の改善につながっています。

法令チェック: 従来はサンプリングによるモニタリングでしたが、生成 AI により低コストで自動実行が可能になったことで、全件の AI 自動検知を実現しました。検知ロジックでは、プロンプト内に判断フローを定義し、生成 AI が各ステップの判断根拠を出力しながら段階的に判定を進めます。これにより、複数の条件が絡み合う複雑なルールに対しても精度の高い検知を実現し、応対品質の向上とコンプライアンス遵守の両立を図っています。

生成 AI 活用を組織に定着させる

TEPCO EP にとって、コンタクトセンター業務への生成 AI 適用は参考にすべき前例がほとんどない技術チャレンジでした。業務で適切に活用できる高精度なプロンプトを作成するには、生成 AI の特性を理解した上で業務課題と正面から向き合う必要があります。そこで段階的に AWS の支援を活用し、生成 AI 活用を目的化せず業務課題の解消を明確に目的設定するプロセスを重視しながら、組織にノウハウを蓄積していきました。

まず、プロジェクト開始前に構築ベンダーと AWS Prototyping Team の支援のもと POC を実施しました。サーバーレスサービスを活用して最小限の MVP 構成を素早く構築し、実務担当者を含むステークホルダーに生成 AI の使用感を早期に体感してもらえたことで、その後の要件定義に大きく役立ちました。

次に、各ユースケースの課題定義と実現方法の検討にあたっては、AWS 生成 AI イノベーションセンターを活用しました。「何を」「どのレベルで」実現するかというタスク設定を技術的に明確化し、評価の枠組みを整えたことで、後続のプロンプト開発を効率的に進める土台ができました。

続いてプロンプト作成・精度評価については、AWS Professional Services と協力して進めました。支援の前半は AWS 主導でプロンプトを開発し、後半は TEPCO EP のメンバーが主体となってプロンプト修正と結果分析の試行錯誤を繰り返す形をとりました。データ準備の重要性やプロンプト評価の手法など、プロジェクト全体を通じて幅広い知見を得ることができ、この過程で実務担当者 11 名が生成 AI の特性を理解した上でプロンプトを設計・評価するスキルを習得しました。2025 年 12 月の Phase1 完了以降は、実務担当者が単独で継続的な改善を行える体制が構築されており、今回の取り組みにより生成 AI 活用の基盤を築くことができたと考えています。

Phase2: よりエージェンティックなコンタクトセンターへ

Phase1 で得られた知見をもとに、TEPCO EP では Phase2 としてさらに高度な AI 活用を推進します。Phase1 では主に課題 3・4（応対後の処理負荷、データ活用）にアプローチしましたが、Phase2 では課題 1・2（IVR の複雑さ、スキルミスマッチ）の解消にも踏み込みます。目指すのは「オペレーター自己完結化」、すなわちオペレーターが必要な情報に迅速にアクセスでき、応対に集中できる環境の構築です。

TEPCO EP が検討している具体的な取り組みは以下の二つです。

一次応対の自動化: 従来の IVR を廃止し、自然な会話形式でお客さまの用件を聞き取り、適切なスキルを持つオペレーターに振り分けます。Phase1 で培ったコールリーズン分析の知見を活用し、お客さまが用件に合った窓口へスムーズに到達できるようにすることで CX 向上を図ります。
オペレーターのリアルタイム支援: お客さまとの会話内容をリアルタイムに分析し、関連するナレッジや手続き情報を自動的に表示します。応対後の後処理についても、登録内容の自動入力や手順ガイドを提供することで、保留や管理者へのエスカレーションを削減し自己完結率を高めます。

これらの実現に向けて、技術的な選択肢を補足します。Amazon Connect Customer では Agentic AI 機能が大幅に強化されており、たとえば一次応対の自動化には自然言語による会話ボット機能が、オペレーター支援にはリアルタイムナレッジ検索やステップバイステップのガイド提供機能が、それぞれ活用できます。Phase1 で構築した Amazon Connect Customer 基盤の上に、これらの機能を段階的に追加していくアプローチが可能です。

図 5 Amazon Connect Customer の Agentic AI 機能概要

まとめ

TEPCO EP の事例から、実務担当者が中心となった CX 改善の取り組みにおける重要なポイントを整理します。

CX を起点に技術を選定する: 業務課題を明確にし、それを解決する手段としてクラウドと生成 AI を位置づける
マネージドサービス中心のシンプル構成: 標準機能の活用で開発スピードと保守性を両立し、モデル更新も迅速に取り込む
実データで試行し段階的に精度を高める: 生成 AI のチューニングは実データで検証し、精度と実用性のバランスを追求する
スキルを組織に定着させる: プロンプトチューニングや精度評価のスキルを内製化し、自走での改善体制を構築する

コンタクトセンターの CX 向上や、Amazon Connect Customer と生成 AI の活用にご興味のあるお客さまは、お気軽に AWS までご相談ください。

著者について

今野拓也
東京電力エナジーパートナー株式会社サービスソリューション事業部副部長
2007 年東京電力入社。オール電化推進営業、顧客向け Web サイト企画・構築を経て、2019 年より新サービス関連業務・システム構築に従事。2020 年に AI コンタクトセンター（AICC）構築を担当。2025 年よりコール・チャット等運営の統括責任者として新規音声基盤の企画・構築を推進し、現在はサービスソリューション事業部副部長としてシステム全体統括および SEEDS プロジェクト PM を務める。

橋井雄介
アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト
エネルギー・ユーティリティ業界を担当するソリューションアーキテクト。お客さまのクラウド活用と生成 AI 導入を技術面から支援している。

Open Governance for MySQL: A Step Forward for the Community

Yutaka Hoshino — Fri, 26 Jun 2026 00:56:56 +0000

このBlog postはOpen Governance for MySQL: A Step Forward for the Communityの日本語訳です。

MySQL — 世界中の数百万のアプリケーションを支えるオープンソースデータベース — が新たな章を開きます。本日、Oracleは、より広範なコミュニティがプロジェクトの開発と方向性に参加するための道筋を作る、MySQLのコミュニティガバナンスモデルを発表しました。

このポストでは、AWSがこの動きを支持する理由と、MySQLコミュニティにとっての意味を説明します。

オープンガバナンスがオープンソースを機能させる

多様なコントリビューターと透明性のあるガバナンスを持つオープンソースプロジェクトは、より良いソフトウェアを生み出します。オープンガバナンスは、ユーザーからコントリビューター、そしてリーダーへの明確な道筋を示し、組織がプロジェクトの将来にエンジニアリングリソースなどを投資するを自信を与えます。

MySQLは約30年にわたり、インターネットインフラストラクチャの基盤となってきました。スタートアップから世界最大の企業まで、数十万の企業が最も重要なワークロードをMySQL上で実行しています。コミュニティの参加方法を明確化することで、その基盤が強化され、MySQLの利用者が将来を見据え、ビジネスを構築するための判断材料に役立ちます。

新しいガバナンスモデルの仕組み

OracleがMySQLを買収して以来初めて、Oracle以外の組織がエンジンの構築方法と方向性において定義された役割を持つことになります。このモデルは、役割の段階を作ります：コントリビューターがコードと修正を提出し、コミッターが変更をレビューして承認し、プロジェクトリードがオプティマイザーやInnoDBなどの主要サブシステムを所有します。

これらの役割の上に、MySQLの長期的な方向性とリリースポリシーを設定するステアリングコミッティがあります。コミッティには、Oracle以外から4つの席があり、クラウドプロバイダー、MySQLの顧客、オープンソースコミュニティが占め、Oracleが過半数を持ちます。Oracleが最初のメンバーを2年の任期で指名し、その後、Oracle以外の席はコミュニティによる投票により決定されます。

これらすべてを支えるため、これまで存在しなかった外部コラボレーションとコントリビューションのためのチャネルとして、OracleはMySQLコミュニティのためのパブリックGitHubを立ち上げました。

AWSがこれを支持する理由

AWSは15年以上にわたり、ユーザーとして、コントリビューターとして、そしてMySQLに依存するサービスの構築者として、MySQLに深く投資してきました。今日、数万のお客様がAWS上でMySQLワークロードを実行しています。MySQLは私たちのエコシステムで最も重要なデータベースの一つであり、お客様はその長期的な健全性に直接的な利害関係を持っています。

AWSでは、オープンソースはすべての人にとって良いものであると信じており、オープンソースの価値をお客様に、そしてAWSの運用上のオペレーショナルエクセレンスをオープンソースコミュニティにもたらすことにコミットしています。そのコミットメントはシンプルな形で現れます：お客様がAWS上でオープンソースデータベースを実行して問題に遭遇した場合、私たちはアップストリームに対してMySQLを利用するすべてのユーザのために修正に取り組みます。

私たちにはまさにこれらを行ってきた実績があります。PostgreSQLでは、VACUUMを6倍高速化し、アップグレード時にレプリケーションスロットを維持し、autovacuum設定変更の再起動要件を削除しました。LinuxFoundationによるRedisのフォークであるValkeyでは、全文検索とハイブリッドクエリサポートを追加しました。そして、大量のテーブルを持つデータベースのアップグレード時のメモリ不足エラーの修正やヒストグラムエラーの修正など、MySQL自体にもすでにアップストリームに対し修正を貢献しています。

健全なアップストリームプロジェクトは、MySQLに依存するすべての人に利益をもたらします — 自ら運用する人、マネージドサービスを活用する人、またはそれらのシステムにツールや統合を構築する人。より多くのエンジニアがコードをレビューすれば、より多くのバグが発見されます。設計上の決定がオープンに行われれば、リリースされる機能はより幅広い実世界のユースケースを反映します。ガバナンスが透明であれば、組織はコントリビューションが評価され、声が聞かれるという自信を持ってプロジェクトに投資できます。

これは理論ではありません — OpenJDK、Valkey、その他数十のプロジェクトで、幅広い参加がソフトウェアをより良く、コミュニティをより強くした経験です。

私たちはMySQLにもそれを望んでいます。

MySQLコミュニティにとっての意味

このガバナンスモデルは、ユーザー、コントリビューター、エコシステム全体にとって、プロジェクトの長期的な健全性のシグナルです：

品質とセキュリティへのより多くの目 — コミッター、プロジェクトリード、コンポーネント横断的な監視による構造化されたレビュープロセスにより、コードがリリースされる前に、より多くのエンジニアが正確性、パフォーマンス、セキュリティを検証します。
より速いイノベーション — 明確なコントリビューションパスとパブリックなコラボレーションにより、より広範なエコシステムが改善を提案し提供するための障壁が低くなります。
プロジェクトの将来への自信 — Oracle、エンドユーザー、オープンソースコミュニティからの代表を含むステアリングコミッティにより、MySQLの方向性は単一のベンダーだけでなく、それに依存する利用者の利益を反映します。
継続性と互換性 — ガバナンスモデルは、安定性、後方互換性、リリース品質を明示的に優先します。ユーザーとオペレーターは、破壊的な変更を心配することなく改善を採用できます。

より強力なアップストリームプロジェクトは、MySQL上に構築されたすべてのもの — マネージドサービス、セルフホストデプロイメント、ツール、そしてより広範なエコシステム — のより強力な基盤を意味します。

今後の展望

AWSはMySQLステアリングコミッティに席を持ち、プロジェクトのロードマップとリリース決定に直接的な発言権を持っています。私たちは、MySQLを利用しているお客様のためにその発言権を使うつもりです。

AWSは長期にわたってオープンソースコミュニティに貢献しており、お客様のワークロードに最も直接的な影響を与える分野でMySQLプロジェクトに積極的に関与しています：

パフォーマンス — 実際のワークロードの実行速度を決定するエンジンの部分に焦点を当てています：クエリオプティマイザー、クエリ実行、インデックス作成、InnoDBストレージエンジン、およびその下のキャッシュレイヤー。
ベクトル検索とインデックス作成 — オープンソースデータベースのベクトル機能を強化してきたAWSの経験が、コミュニティ全体の共同作業に基づいて、MySQLの新しいベクトルサポートに貢献しています。
拡張フレームワーク — MySQLのコンポーネントインフラストラクチャにより、新しい機能はコアサーバーコードに組み込まれるのではなく、定義されたサービスインターフェースを通じて接続するロード可能なコンポーネントとしてリリースできます。これはコミュニティコントリビューションに最もオープンな分野の一つであり、ここに投資する予定です。

これらは、私たちがすでに行っているアップストリームへの貢献の上に構築されています。数十万のお客様のミッションクリティカルなワークロードを実行することで、MySQLの多くのユーザーに影響する実際の問題 — 正確性、安定性、信頼性の問題 — が表面化し、GitHubを通じてコミュニティ全体のための修正に取り組んでいます。

要点はシンプルです：MySQLの開発がオープンになり、AWSはその方向性を形作る席を持ち、すでにアップストリームで修正と改善の貢献をしています。お客様はMySQLをどこで実行してもこれらの恩恵を受けることができます。

Get involved

MySQLエコシステム全体の開発者、ユーザー、組織の皆様に、ガバナンスモデルを読み、どのように参加したいかを検討することをお勧めします。オープンソースは人々が参加することで成長します — そしてこのモデルにより、コントリビューションがこれまで以上に簡単になります。

Read Oracle’s announcement

Read the Governance model

フルライフサイクル制御を備えた分離サンドボックスの実行：AWS Lambda が MicroVMs を導入

Micah Walter — Thu, 25 Jun 2026 07:25:51 +0000

2026 年 6 月 22 日、私たちは AWS Lambda 内の新しいサーバーレスコンピュートプリミティブである AWS Lambda MicroVMs を発表しました。これは、ユーザーまたは AI によって生成されたコードを、分離されたステートフルな実行環境で実行できるようにするものです。仮想マシンレベルの分離、ほぼ瞬時の起動および再開、そして環境のライフサイクルと状態に対する直接的な制御を得ることができ、インフラ管理や複雑な仮想化技術に関する専門知識は不要です。Lambda MicroVMs は Firecracker によって支えられており、これは毎月 15 兆回以上の Lambda 関数呼び出しを支えている軽量仮想化技術と同じものです。

なぜこの機能が求められるのか
ここ数年で、新しいクラスのマルチテナントアプリケーションが登場しており、それらはすべて共通して「各エンドユーザーに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する」という要件を持っています。AI コーディングアシスタント、インタラクティブなコード実行環境、データ分析プラットフォーム、脆弱性スキャナー、そしてユーザー提供スクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在、このような機能を構築するには難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動できますが、共有カーネル構造のため、信頼できないコードを安全に隔離するには大幅な追加の強化が必要です。Function as a Service はイベント駆動型のリクエスト・レスポンス型ワークロードに最適化されていますが、ユーザー操作間で環境状態を保持する必要がある長時間のインタラクティブセッションには適していません。その結果、開発者はパフォーマンスと分離性のトレードオフを受け入れるか、あるいは低遅延な体験を提供しつつ分離実行を実現するために、カスタム仮想化基盤を構築・運用するための大規模なエンジニアリングリソースを投入するかの選択を迫られます。これは高度な専門知識を要求する取り組みであり、本来構築しようとしているプロダクト開発からエンジニアリング時間を奪ってしまいます。

Lambda MicroVMs はまさにこのギャップを埋めるために設計されています。各 MicroVM は、単一のエンドユーザーまたはセッションに対して専用の隔離環境を提供し、迅速に起動し、セッション期間中はメモリとディスク状態を保持し、ユーザーが離席すると低コストのアイドル状態へと一時停止します。同じ Firecracker 技術がすでに AWS Lambda 関数を支えているため、同サービスが大規模運用で培ってきた運用成熟度をそのまま継承できます。

試してみましょう
私はまず AWS Lambda コンソールにアクセスし、左側のナビゲーションメニューに新しく表示された「Lambda MicroVMs」を開きました。最初に MicroVM Image を作成する必要があります。

Flask Web アプリとその Dockerfile を zip ファイルにまとめ、それを Amazon Simple Storage Service (Amazon S3) バケットへアップロードしました。

私の Flask API – app.py

import logging

from flask import Flask, jsonify

app = Flask(__name__)
logging.basicConfig(level=logging.INFO)


@app.route("/")
def hello():
    app.logger.info("Received request to hello world endpoint")
    return jsonify(message="Hello, World!")


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

私の Dockerfile


FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN dnf install -y python3 python3-pip && dnf clean all

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

MicroVM イメージを作成するために、以下のコマンドを使用しました。

aws lambda-microvms create-microvm-image \
--code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name> \
--base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
--build-role-arn <IAM role ARN>

上記のように、AWS コンソールから MicroVM Image を作成することも可能です。コマンドを実行すると、Lambda は zip を取得し、Dockerfile を実行してアプリケーションを初期化し、実行中のディスクおよびメモリ状態を Firecracker スナップショットとして取得します。ビルドログはリアルタイムでAmazon CloudWatch にストリーミングされ、ロググループは/aws/lambda/microvms/<image-name>に記録されます。イメージの準備が完了すると、そのAmazon リソースネーム (ARN) とバージョン番号がコンソールに表示されます。

aws lambda-microvms run-microvm \
--image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \
--execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

起動は AWS コンソールまたは CLI からも実行できます。私はイメージ ARN とアイドルポリシーを指定しました。このポリシーでは、15 分間操作がない場合に自動的にサスペンドし、次のリクエストで自動的に再開するよう設定されています。ネットワーク設定は不要でした。Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、私の Flask アプリがすでに起動した状態の新しい MicroVM を開始しました（スナップショットから復元されたためです）。起動が完了した時点で、私の Flask アプリはすでに稼働していました。完全に初期化済みのコンピュート環境を得るまで、API コールはわずか 1 回です。

トラフィック送信のために、CLI で短時間有効な認証トークンを生成し、それをX-aws-proxy-authヘッダーとして通常の HTTPS リクエストに付与しました。リクエストはただちに私の Flask アプリへ到達しました。その後、Micro VM をアイドル状態のまましばらく放置すると、しきい値を超えた時点でサスペンドされ、メモリとディスクの状態はスナップショットとして保存されました。その後再びリクエストを送信すると、アプリケーションの状態を完全に保持したまま再開されました。クライアント側から見ると、停止は一切発生していないように見えます。

仕組み
内部的には、Lambda MicroVMs はこれまで単一の AWS コンピュートサービスでは提供されていなかった 3 つの能力を統合しています。第 1 は仮想マシンレベルの分離であり、これは Firecracker によって実現されています。各セッションは専用の MicroVM 内で実行され、カーネルやリソースはユーザー間で共有されません。そのため、あるユーザーが提供した信頼できないコードはその実行環境内に閉じ込められ、他の環境や基盤システムへアクセスすることはできません。第 2 は高速な起動および再開です。この仕組みは「イメージ→起動（image-then-launch）」モデルです。MicroVM Image は、DockerfileとAmazon S3 にパッケージされた zip アーティファクトを指定して作成されます。Lambda は Dockerfile を実行し、アプリケーションを初期化した後、その実行状態（メモリおよびディスク）を Firecracker スナップショットとして取得します。このイメージから起動されるすべての MicroVM は、コールドブートではなく事前初期化済みスナップショットから復元されるため、起動およびアイドル復帰の両方がほぼ瞬時に行われます。数 GB 規模のインタラクティブセッションであっても、ユーザーにとって十分に応答性のある速度で復帰します。第 3はステートフル実行です。実行中の MicroVM は、ユーザーセッション中にメモリ・ディスク・実行中プロセスの状態を保持します。アイドル状態では MicroVM はサスペンドされ、メモリとディスク状態を維持したまま保存され、トラフィック再開時に復元されます。インストール済みパッケージ、ロード済みモデル、作業中ファイルセットは再開時にそのまま利用可能です。MicroVM は最大 8 時間の総実行時間をサポートし、アイドル状態は設定可能な時間で自動サスペンドできます。これにより、数分で完了する脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間アイドルを含むインタラクティブ開発環境など、多様なユースケースを容易に構築できます。MicroVM は事前初期化スナップショットから起動されるため、初期化時にユニークなデータ生成、ネットワーク接続、または一時データのロードを行うアプリケーションは、互換性のためサービス提供のフックとの統合が必要になる場合があります。

Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、専用のAPI 体系を持ちます。Lambda 関数はイベント駆動型のリクエスト／レスポンス処理に最適であり、Lambda MicroVMs はユーザーまたはセッションごとに隔離された実行環境で信頼できないコードを実行する必要があるマルチテナントアプリケーション向けに設計されています。両者は相互に補完関係にあります。イベント駆動のバックエンドには Lambda 関数を使用し、隔離実行が必要な処理には Lambda MicroVMs を呼び出す構成が可能です。アプリケーションはそのまま持ち込み、実行環境はサービス側が提供します。

今すぐご利用いただけます
AWS Lambda MicroVMs は現在、米国東部 (バージニア北部・オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) リージョンで利用可能です。アーキテクチャは ARM64 に対応し、MicroVM あたり最大 16 vCPU、32GB メモリ、32GB ディスクをサポートします。アイドル状態の MicroVM は API による明示的停止、またはライフサイクルポリシーによって自動的にサスペンドでき、実行コストを削減しつつ状態を保持したまま高速再開が可能です。料金の詳細は AWS Lambda 料金ページを参照してください。

開始するには AWS Lambda コンソールにアクセスするか、Lambda MicroVMs 製品ページをご覧ください。ドキュメントはLambda ドキュメント（Developer Guide）を参照してください。

原文はこちらです。

Amazon Web Services ブログ

キヤノンIT ソリューションズ様と取り組むホテルのフードロス削減 – 時系列基盤モデル Chronos-2 で最適な提供量を予測する

本取組の背景

フードロス削減のPoCについて

Chronos-2とは

実行環境と検証アプローチ

PoCから実運用への展開

PoC実施結果

Step1：最小構成によるベースライン予測

Step2：業務データを考慮した予測モデル

Step3：ラグ特徴量による最終的な精度向上

技術的なポイント

Chronos-2 における時系列カラムの注意点

リーケージを防ぐ設計

ラグ特徴量の有効性

Chronos-2 に関する考察

本検証の総括

まとめと今後の展望

執筆者

キヤノンITソリューションズ株式会社

大原 諭 (Satoshi Ohara)

大竹 智礼 (Tomonori Otake)

辻 夏子(Natsuko Tsuji)

戸塚 智哉(Tomoya Tozuka) /@tottu22

大久保 裕太 (Yuta Okubo)

寺山 怜志 (Satoshi Terayama)

株式会社フジテレビジョン様が冬季国際スポーツ競技大会で実現した Live Cloud Production

テレビのライブ放送を支える3つの処理

国際中継における課題

フジテレビの取り組み — Live Cloud Production

パリからミラノへ — 1年半にわたる検証

本番運用と結果

まとめ

著者

週刊AWS – 2026/6/22週

2026年6月22日週の主要なアップデート

著者について

Kiro で OpenAPI/Swagger 仕様から数秒でテストスイートを生成する

Swagger と OpenAPI 仕様

既存ツールが力不足な理由

ソリューション概要

前提条件

Kiro でテストスイートを生成する

サンプルプロンプト

生成されたプロジェクト構造を確認する

Kiro がどのように仕様を解析するかを理解する

テストを実行する

モックサーバーに対して実行する

テストの品質と分類

詳細: 削除ライフサイクル全体のテスト

実 API に対して実行する

認証された内部 API に適応する

Kiro ヘッドレスモードでテスト再生成を自動化する

まとめ

実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 博多編（#6/8）開催レポート

イベントの流れ

事例紹介：株式会社オーレックホールディングス様 〜「禁止から活用へ」中堅製造業の現場主導 AI 展開〜

きっかけは、全社的な AI 活用の方針転換

セキュアな基盤と、社員のリテラシー向上の両輪で

「触ってもらう」から始めた段階的展開

成果：全社員の 40% が自発的に使い始めた

横展開を支えた「信頼の土台」

まとめ

関連ブログ

執筆者

週刊生成AI with AWS – 2026/6/22 週

さまざまなニュース

サービスアップデート

著者について

Amazon Quick on Desktop が東京リージョンに対応 – AWS Summit New York 2026 アップデート –

Amazon Quick on Desktop とは

Quick on Desktop でできること

ローカルファースト・アーキテクチャ

東京リージョン対応のメリット

1. 国内データレジデンシー

2. JP-CRIS による国内推論

3. 低レイテンシー

最新アップデート

Autonomous Agent — あなたの代わりに動き続ける AI

Activity Feed — 1日の始まりをトリアージから解放

大原諭 (Satoshi Ohara)

大竹智礼 (Tomonori Otake)

辻夏子(Natsuko Tsuji)

戸塚智哉(Tomoya Tozuka) /@tottu22

大久保裕太 (Yuta Okubo)

寺山怜志 (Satoshi Terayama)

実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 博多編（#6/8）開催レポート

事例紹介：株式会社オーレックホールディングス様〜「禁止から活用へ」中堅製造業の現場主導 AI 展開〜

CX向上に向けたコンタクトセンター変革 — 全国複数拠点・数千席規模の環境で挑む東京電力エナジーパートナーの Amazon Connect Customer × 生成 AI 活用