こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 3 回レポートです。シリーズの背景や全体像については、 前回の大阪・初回レポート をご覧ください。 大阪での 2 日間のイベントに続き、2026 年 4 月 22 日は名古屋にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト古屋 楓から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、 Amazon Quick のデモを交えながらご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: 古屋によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中部を拠点に 270 年以上の歴史を持ちながら、経営・現場の双方から生成 AI 活用に挑戦されている 1 社の事例をご紹介します。 事例紹介：タキヒヨー株式会社様 〜経営と現場、両輪で進める Amazon QuickSight によるデータ活用〜 事例紹介は タキヒヨー株式会社 様です。1751 年（江戸時代の宝暦元年）に名古屋で創業された 270 年以上の歴史を持つ繊維アパレル企業で、テキスタイル事業では愛知県一宮市に自社工場をお持ちで、伝統的な英国式紡績機を生かしたものづくりを行われています。アパレル事業では企画・製造・販売に加え、リテール事業として自社ブランドの展開もされており、東京証券取引所・名古屋証券取引所に上場されている企業です。従業員数は540 名(2026年2月末)、ニューヨークに拠点をお持ちのグローバル企業でもあります。 当日は、経営視点と現場視点の両面から、二つのプロジェクトについてパネルディスカッション形式でお話しいただきました。AWS 小嶋がモデレーターを務め、それぞれのプロジェクトの背景から成果までを伺いました。 業務 KPI ダッシュボード化プロジェクト 一つめのエピソードは、執行役員の平田様が経営の視点で推進された、業務 KPI ダッシュボードプロジェクトについてです。 アパレル業界は職人的・属人的な業務傾向があり、勘や経験に頼りがちな面があります。経営として、売上や利益といった KGI よりもっと粒度の細かい業務 KPI で組織の状態を定量的に把握し、営業活動の改善に繋げたいという思いがプロジェクトの出発点でした。ただ当時は、各組織のデータが Excel に散在し、VBA マクロで集計していたため、処理に時間がかかったりマクロが想定どおり動作しないなどの課題がありました。 この課題に対して、 Amazon QuickSight を導入し、基幹システムや NAS のデータを一元的に可視化・分析できる基盤を構築されました。ただ、導入にあたって一番苦労されたのが「現場のアレルギー反応」だったといいます。それまで各マネージャーが各々のやり方で管理業務を回していたところに、統一のダッシュボードを導入するという施策そのものに対して、「手間が増える」という受け止めから反発があったとのことです。 この壁を乗り越えるために、とにかく使い勝手にこだわってプロジェクトを進められました。便利さを実感してもらうことで理解を得て、利用も促進したいと考え、ドリルダウン機能の設計に特に注力されました。 大きなデータから詳細なデータへと段階的に掘り下げることができ、感覚的な操作で目的のデータにたどり着けるよう設計 しました。「普段の動線そのままで使える」ことで現場の抵抗感を下げることに繋げました。また、 データの欠損を補うためにWeb経由のデータ入力の仕組みも構築 し、ダッシュボードに表示されるデータの信頼性を担保する工夫も行われました。 結果として、URL にアクセスすれば経営データがすぐ確認できる状態になり、 現場のマネージャーが本来の意思決定業務に集中 できる環境が整いつつあるとのことです。今後は、分析の精度向上や、分析から起こしたアクションが業績にどう寄与するかの効果検証をしていきたい、とお話いただけました。 需要予測データのダッシュボード構築プロジェクト マーケティングチーム兼DX 推進チームの山口様が現場の実践者として推進されたプロジェクトです。 山口様ご自身はエンジニアではなく、プログラムを書いたご経験はありませんでした。ただ、「自分たちの手でなんとか活性化させたい」という思いから、需要予測データを Amazon QuickSight で可視化するダッシュボードの内製構築に取り組まれました。既存データには、複数の情報（色・柄・素材など）が一つのカラムにまとめて格納されていたため個別の値で抽出できない（例えば何色が売れているか？といった分析はできない）、需要予測の数値が絶対値のみのため、判断の基準がなくアクションに繋がらない、という二つの課題がありました。 開発にあたって、当初は Generative AI Use Cases （ AWSが提供するチャットベースの生成AIアプリケーション）で SQL を生成させていましたが、開発が難航しました。チャットベースのアプリケーションで、必要なデータ（DBのテーブル情報、全体設計、既存データなど）をAIに与えながら作業をさせようとすると、開発が進むほどコンテキストの制限に達してしまい、その都度新しい会話を立ち上げ直す必要が生じ、作業上の煩雑さを生んでいました。さらに、本来は必要なコンテキストを渡しきれない状況も発生し、そうなるとAIが出力するSQLが本来の目的と異なるものになる、といった問題も発生していました。 このような経緯から、チャットボットベースのアプリケーションに限界を感じられ、コーディングエージェントの Claude Code を Amazon Bedrock 経由で利用する方針に切り替えられました。コーディングエージェントであれば、AI エージェントがユーザー指示に応じて必要なローカルファイルを自律的に参照しにいくため、今まで作成してきたテーブル情報やシステム設計、エラー内容までを AI が自動で把握してくれ、開発効率が大きく向上しました。 データの課題については、既存のデータのETLにも取り組まれました。具体的には、一つのカラムに混在していた色・柄・素材などのデータを色別・素材別・シルエット別などにそれぞれのカラムに分けて対応し、絶対値で表示されていた需要予測値も ◎○△✕評価が動的に表示される仕組みに変更されました。この際、Claude Code を単なるコード生成ツールとしてではなく、 目的を共有し、既存のデータを生かすためにどんな方法がよいかを一緒に探る「頼れる相談相手」として活用 されました。「こういう見せ方はどうか」「この分け方だとデータが崩れないか」── ジェンガのピースを崩さないように一つずつ探していくような試行錯誤を、AI と対話しながら繰り返された とのことです。 結果として、 通常であれば外注で数ヶ月・数百万ほどかかるシステムを、非エンジニアの山口様ご自身が数週間で構築 されました。さらに、データ構造を深掘りしていく過程で、 ベンダー側でブラックボックス化していた課題に気づき、改善提案に繋げられた という副次的な効果もあったとのことです。今後は自社に蓄積された売上・在庫データの取り込みや、 Amazon Quick （Amazon QuickSight が進化して生まれた Agentic AI プラットフォーム）の AI チャット機能の活用も検討されています。 お二人から参加者へのアドバイス 最後に、お二人から参加者へのアドバイスをいただきました。 平田様からは、「 まずは現業務を可視化してデータで見られる体制を整えることが第一歩。完璧を目指すのではなく、経営層が現場に対して『小さく試して失敗から学ぶ』ことを許容し、現場の変革を後押しするスタンスが重要 」というメッセージをいただきました。 山口様からは、「 とにかくデジタル上にデータを蓄積することに注力してほしい。デジタルデータは企業の財産になる 」というメッセージ。同じ分量のデータでも、デジタルかアナログかで将来の資産価値が大きく変わる。仮にデータの中身が多少整理されていなくても、AI を活用すれば非エンジニアでも理想的な形に整形できる。 アナログからデジタルへの移行方法自体も、AI に相談してみてほしい 、とお話しいただきました。 写真: タキヒヨー株式会社 平田様・山口様、AWS 小嶋によるパネルディスカッション 経営と現場の両輪で取り組まれたお話に続いて、こうしたデータ活用の取り組みを伴走支援するパートナー様からのセッションです。 パートナーセッション：クラスメソッド株式会社様 〜生成 AI 活用のためのデータ収集〜 お客様事例のあとには、AWS プレミアティアサービスパートナーである クラスメソッド株式会社 データ事業本部 チームリーダー / プロジェクトマネージャーの三鴨 勇太 様より、「生成 AI 活用のためのデータ収集」と題したセッションをお届けいただきました。名古屋オフィスを拠点に、お客様のデータ基盤構築やデータ戦略支援を担当されている三鴨様から、データドリブン経営を支えるデータ基盤整備の考え方をお話しいただきました。 データ収集がデータドリブン経営と生成 AI 活用の共通の土台であるという点を特に強調しました。ビジネスの加速のためには、企業が持つデータ資産を生成 AI と組み合わせることで差別化につながる。そのために、属人化している情報があればそれらを効率的にデータ化し、収集していく仕組みが重要だと述べられました。 データ基盤整備の進め方としては、企業文化に合わせて、 Needs （需要があるところからデータ基盤整備を進めていく） と Seeds （できるところからデータ基盤整備を始める） の 2 つのアプローチのどちらを取ることもあり、クラスメソッド様が提供するデータ活用基盤構築・運用サービス、データ活用コンサルティング、データ活用分析研修、生成 AI 総合支援サービスなど様々な支援のあり方を紹介いただきました。 写真: クラスメソッド株式会社 三鴨様によるセッション まとめ セッション後には参加者同士のグループディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。 名古屋でご登壇いただいたタキヒヨー様とクラスメソッド様に共通していたのは、 データをいかに集め、活かせる状態に整えるか という土台の重要性と、 小さい成功体験を少しずつ積み重ねる という進め方のベストプラクティスでした。AI を活用している企業様は、データや周囲の巻き込み方など AI 以外の部分にもプラクティスを持っておられることが伝わるセッションでした。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした名古屋・3 日目に続き、次回は翌日開催の名古屋・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート タキヒヨー、生成 AI を活用し社内業務効率化と 450 時間超の工数削減を実現。Amazon Bedrock を衣服デザイン等に適用、デジタル人材育成を推進 中堅・中小企業でも広がる生成 AI。企業の成長にも貢献 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

最新の Amazon Q コスト機能は、FinOps チームがクラウド支出を管理する方法を変革しています。FinOps チームがコストのかかる設定を発見した時点では、すでに本番環境で稼働していることも少なくありません。その段階での修正はデプロイへの影響が大きくなりがちで、関係者との調整もより難しくなり、得られるコスト削減効果も本来可能だったものより小さくなってしまうことがよくあります。 Amazon Q は、知りたいことへの回答を得て意思決定を行うまでのスピードを加速させています。この 1 年間で、AWS は Amazon Q のコスト関連機能を拡充してきました。 自然言語での料金に関する質問への回答から 、開発者のワークフロー内で最適化の推奨事項を直接提示する機能まで、その範囲は広がっています。その結果、クラウドコストとの向き合い方が根本的に変わりました。月次のレビュー作業としてではなく、構築や運用の中で継続的に対話しながら取り組むものへと変化しています。 開始方法と前提条件 Amazon Q Developer は、AWS コンソール上で追加のセットアップなしにそのまま利用できます。利用を開始するには、AWS コンソールの左上にある Amazon Q チャットインターフェイスのアイコンを見つけてください。 この記事で取り上げる機能を使用するには、 AWS Cost Explorer が有効になっていること、および Amazon Q と請求データの両方に対する AWS Identity and Access Management (IAM) のアクセス許可が必要です。すべての機能を利用するには、 AWS Cost Optimization Hub と AWS Budgets も有効にしておくことをお勧めします。AWS のアプリおよびウェブサイト (AWS Management Console、AWS コンソールモバイルアプリケーション、AWS ドキュメントサイトを含む) 上で Amazon Q Developer の機能にアクセスするために必要な IAM ポリシーについては、 こちら を確認してください。 Amazon Q Developer には月 50 クエリまでの無料利用枠 (Free Tier) が用意されており、アドホックなコスト調査や定期的なレビューであればほとんどの場合これでカバーできます。より多くの利用が必要なチームは、ユーザーあたり月額 19 ドルの Pro Tier にアップグレードできます。この記事で紹介するすべての機能は、Free と Pro の両方のサブスクリプションに含まれています。詳細については、 Amazon Q Developer の料金ページ を参照してください。 より速く、よりスマートなコスト分析 この新機能の核となるのは、スピードと分析の深さです。FinOps アナリストは、「先週コンピューティングの支出が増えたのはなぜか？」といった質問に答えるために、複数のデータセットを調査するのに何時間も費やすことがよくあります。Amazon Q は、従来であればダッシュボードやコストデータを手作業で確認しなければ得られなかった回答を、自動的に提供できるようになりました。「過去 3 か月間の EC2 の時間あたりコストはどのように推移していますか？」のような、計算を伴う複雑な質問をすることもできます (図 1 および図 2 を参照)。 Amazon Q に質問を送信すると、複数のソースからきめ細かなデータを取得し、カスタム計算 (コストを使用量で割るなど) を実行して、必要なデータを提供します。ユーザーはデータの所在を自分で探す必要はありません。また、時間単位やリソースレベルの粒度にも対応しているため、スケーリングやその他の動的なアクティビティについても調査が可能です。 図1 – Amazon Q チャット画面 (処理ステップと「View in Cost Explorer」リンクの表示) 図2 – Amazon Q チャット画面 (出力結果と分析の表示) 各レスポンスには、実行された API 呼び出しの詳細と「 View in Cost Explorer 」リンクが含まれているため、基となるデータを直接確認することができます (図 3 を参照)。 図3 – 「View in Cost Explorer」リンクをクリックした例 開発者へのコスト意識の浸透 リソースがデプロイされる前の段階でコスト最適化に取り組むこと (FinOps では「シフトレフト」と呼ばれます) は、支出を管理するうえで最も効果的なアプローチのひとつです。Amazon Q の新しい機能は、実際に作業が行われる場所で力を発揮します。コンソールにログインすれば、事前の設定やセットアップなしに、Amazon Q のネイティブ機能を使って料金の見積もりや想定ワークロードに関する質問をすることができます。たとえば、技術設計ドキュメントの作成中に、Amazon Q に「現在のインフラストラクチャに基づいてコストの見積もりを作成して」と依頼する場面を想像してみてください。Amazon Q は現在のアーキテクチャを読み取り、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Simple Storage Service (Amazon S3) などのサービスの料金を取得して、詳細なコスト見積もりを提供します。 図4に示すように、Amazon Q はサービスごとの日次支出内訳を生成することもでき、実際にどこにコストがかかっているかを明確に把握し、見落としがちなパターンを発見するのに役立ちます。さらに詳しく見たい場合は、図 5 に示すように、Amazon Q が Amazon EC2 のコストをインスタンスタイプ別・日別に内訳表示できるため、どのインスタンスファミリーがコンピューティング支出を押し上げているかを時系列で簡単に確認できます。また、この機能を What-if 分析にも活用できます。ワークロードを Graviton やサーバーレスに移行した場合のコストを見積もりたければ、Amazon Q に聞くだけです。 図4 – Amazon Q による 2026 年 2 月のサービス別日次内訳。Amazon EC2 Compute は平日平均 7.88 ドル/日で、週末には顕著な減少が見られる。Amazon CloudWatch の監視コストは 5 ドル/日で安定しており、2 月 24〜25 日には RDS のスパイクが発生している 図5 – Amazon Q が当月のインスタンスタイプ別・日別の EC2 コストのエリアチャートを生成している様子 新しいビジュアル体験：Amazon Q アーティファクト コストインテリジェンスの改善に加えて、Amazon Q は表やグラフによる可視化で強化されたレスポンスを提供するようになりました。これは Amazon Q アーティファクトと呼ばれます。コンソール全体の体験も刷新されています。 まず、Amazon Q のアイコンが統合ナビゲーションバーに移動し、コンソールのどのページからでもアクセスできるようになりました (図 6 を参照)。 図6 – 統合ナビゲーションバーの Q Amazon Q のアイコンをクリックすると、左側にチャットパネルが開きます。ビジュアライゼーションが生成されると、右側にアーティファクトパネルが自動的に開きます (図 7 を参照)。 図7 – Amazon Q チャットとアーティファクトパネル 最後に、Amazon Q のメニューバーに注目してください (図 8 を参照)。 コストレビューに集中するための フルスクリーンモード レスポンスタイプでフィルタリングできる、厳選プロンプトが用意された プロンプトライブラリ (右上の本のアイコン) 図8 – Amazon Q メニューバー リソーステーブルにはディープリンク (訳注：特定のページやリソースに直接遷移するリンク) が含まれており、当該リソースのサービスコンソールに直接移動できるため、リソース ID をコピーして手動で画面を遷移する必要がありません。 Amazon Q は複数のデータソースから同時にデータを取得します。 AWS Cost Explorer – 過去の支出、トレンド、予測 AWS Cost Optimization Hub – 実行可能なコスト削減の推奨事項 AWS Compute Optimizer – 過剰にプロビジョニングされたリソースの特定 Savings Plans とリザーブドインスタンスのデータ – カバレッジと利用率 AWS Pricing API – すべてのサービスとリージョンにわたるリアルタイムの公開料金 さらに先へ：コストを可視化するさらなる方法 この記事で紹介した例はほんの出発点にすぎません。Amazon Q は幅広いコストの可視化機能に対応しており、何ができるかを知る最良の方法は、まず質問してみることです。支出の急増を調査する場合でも、予算に関する議論の準備をする場合でも、直近の最適化の効果を追跡する場合でも、役立つチャートがきっと見つかるはずです。 FinOps 業務向けのプロンプト例をいくつか紹介します。 予測と予算計画 「次の請求期間のコスト予測を表示して」 – 月末を迎える前に、予算に関する議論をサポートするための将来予測を確認できます (図 9) 「今後 90 日間の予測総支出額をグラフにして」 – 支出の推移を可視化し、予算超過の可能性を早期に発見できます 図9 – 次の請求期間のコスト予測の表示 コミットメントカバレッジ 「過去 3 か月間の Savings Plans カバレッジを青、利用率を赤で折れ線グラフにして」 – コミットメントが期待どおりに機能しているかを追跡し、KPI に色を割り当てることができます (図 10 を参照) 「過去 6 か月間のリザーブドインスタンスの利用率をサービス別にグラフにして」 – 有効期限が切れる前に、十分に活用されていないリザーブドインスタンスを特定できます 図10 – 過去 3 か月間の Savings Plans の利用率とカバレッジ率 サービスおよびリソースの詳細分析 「過去 6 か月間の RDS コストをインスタンスタイプ別・月別でグラフにして」 – インスタンスファミリー全体にわたるデータベース支出のパターンを把握できます 「過去 30 日間の DynamoDB コストをリージョン別・日別でグラフにして」 – リージョンごとの DynamoDB 支出の傾向を把握できます 「先月の EC2-Other コストを円グラフにして」 – EBS、データ転送、Elastic IP などの付随的なコンピューティング料金の内訳を確認できます 「先月のデータ転送コストを可視化して」 – 集計ビューでは見落とされがちな egress (外向きデータ転送) 料金を発見できます ゼロから始める必要はありません。Amazon Q パネルの本のアイコンからアクセスできる Amazon Q プロンプトライブラリには、Cloud Financial Management カテゴリに 23 (訳注：2026 年 5 月初旬時点では 26) の厳選されたプロンプトが用意されており、Q&A、Visualization、Workflow のレスポンスタイプをカバーしています。カテゴリでフィルタリングし、プロンプトを選んで、自分の状況に合わせてカスタマイズするだけです。空白のチャットから意味のあるコストインサイトを得るための最も手軽な方法です (図 11 を参照)。 図11 – Amazon Q プロンプトライブラリ まとめ これらの新機能の目的はシンプルです。データの管理に費やす時間を減らし、ビジネス価値の創出により多くの時間を充てることです。Amazon Q が AWS コンソールに直接組み込まれたことで、コスト管理は日々のオペレーションのシームレスな一部となります。 EC2 の時間あたりコストの調査、サービス別の日次支出内訳の生成、EC2 コストのインスタンスタイプ別の分類、Graviton への移行で得られるコスト削減の見積もりなど、どのような場面でもAmazon Q は余計な手間をかけずに必要な回答を提供します。 FinOps の本質は、財務データに基づいてより良い意思決定を行うことにあります。Amazon Q はその目的を変えることなく、それをより簡単に、よりアクセスしやすいものにします。データと回答は、質問ひとつで手に入ります。今すぐ Amazon Q を使い始めましょう。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトで、AI コスト最適化と FinOps のベストプラクティスに注力しています。Amazon Q Business や Amazon Q Developer など、お客様向け機能の開発に貢献してきたほか、AWS re:Invent をはじめとする業界イベントでスピーカーとして頻繁に登壇し、専門知識を共有しています。また、FinOps Foundation AI ワーキンググループに AWS の代表として参加し、AI における FinOps に関する幅広い議論に貢献しています。 Loic Fournier Loïc は、AWS のシニアテクニカルアカウントマネージャーで、お客様のクラウドジャーニー全体を通じて AWS サービスの価値を最大化するための戦略的な技術アドバイザーとして活動しています。IT 業界で 27 年、クラウドにおける FinOps と財務ガバナンスの分野で 3 年の経験を持ち、公共セクターを含む多様なお客様を支援しながら、オペレーショナルエクセレンスとクラウド効率化に関する深い専門知識を提供しています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。 原文 はこちらです。

月曜日の朝を想像してみてください。CFO、エンジニアリングディレクター、財務チームの全員が、包括的な AWS コストレポートを受信トレイで受け取ります。FinOps チームは誰一人として手を動かす必要がありません。レポートには先週の支出傾向、 Savings Plans の利用状況 、サービスごとのコスト内訳がすべてプロフェッショナルなフォーマットで整えられ、週次ビジネスレビューですぐに確認できる状態になっています。 AWS Billing and Cost Management (請求とコスト管理) ダッシュボード のスケジュールメール配信機能が、まさにこれを実現します。この機能は 2026 年 4 月 9 日よりご利用いただけます。多くの組織にとって、クラウドコストに関するインサイトをステークホルダーに配信することは、時間のかかる手作業でのプロセスでした。FinOps チームは、AWS コンソールへのログイン、レポートの生成、スクリーンショットの取得、プレゼンテーション資料の整形、そして AWS コンソールへのアクセス権をもたない経営層やエンジニアリングリーダーへの資料のメール送信といった作業に、貴重な時間を繰り返し費やしてきました。Billing and Cost Management ダッシュボードのスケジュールメール配信機能を使えば、このワークフロー全体を自動化できます。 この記事では、Billing and Cost Management ダッシュボードの新しいメールレポート機能を使用すべき理由、このローンチの主な機能、および利用を開始するためのステップバイステップのガイダンスについて説明します。 Billing and Cost Management ダッシュボードのメールレポートを使用すべき理由 繰り返しの手作業によるレポート作成を削減 レポート作成のサイクルは毎週、毎月繰り返され、そのたびに FinOps チームはより付加価値の高い業務からいったん離れざるを得なくなります。スケジュールメール配信を使えば、一度レポートを設定するだけで、あとはシステムが生成と配信を自動的に処理します。 非技術系ステークホルダーへのオフラインアクセスを提供 経営幹部、取締役会メンバー、財務チームは、クラウドコストの状況を定期的に把握する必要がありますが、その多くは AWS コンソールへのアクセス権を持っていなかったり、レポートツールを操作する時間がなかったりします。スケジュールメール配信は、パスワードで保護された PDF レポートを受信トレイに直接送信するため、取締役会、予算レビュー、戦略策定セッションでそれをすぐに確認することができます。AWS アカウントへのアクセス権は不要です。 一貫性のある、タイムリーな財務情報の配信を実現 手作業によるレポートは、遅延や内容のばらつきが生じやすくなります。他の優先業務に押されてレポート提出の期限を過ぎてしまったり、一部の受信者がレポートを受け取れなかったりすることがあります。自動メール配信を使えば、すべてのステークホルダーに対して、同じフォーマットで統一されたプロフェッショナルなレポートが、決まったスケジュールで一斉に届きます。 Billing and Cost Management ダッシュボードのメールレポートの主な機能 ワークフローに合わせたレポートのスケジュール設定 日次、週次、または月次の配信を、組織のレビュー周期に合わせた特定の時間に設定できます。必要に応じて、開始日と終了日を指定することも可能です。 セキュリティを損なうことなくコストレポートを共有 受信者は、AWS マネージドの S3 バケットに暗号化された状態で保存されたパスワード付き PDF レポートへの、セキュアで有効期限付きのリンクを受け取ります。署名付きダウンロード URL の 有効期限は 15 日間です。 あらゆる対象者に適したレポートを提供 エグゼクティブレビュー用にダッシュボード全体をエクスポートしたり、チーム内の重点的な議論用に個別のウィジェットをエクスポートしたりできます。最終ファイルを生成する前に、PDF プレビューでレイアウトを確認して調整を行うこともできます。 既存のワークフローへのレポートの統合 スケジュールレポートは AWS SDK および CLI を通じて利用可能で、 Billing and Cost Management Dashboards API を使用して、Infrastructure as Code (IaC) やカスタム自動化ワークフローにレポートのスケジュール設定を統合することができます。 コストデータの閲覧者の管理 この機能は、既存の Billing and Cost Management ダッシュボードのアクセス許可をそのまま引き継ぎます。レポート作成時に検証を行い、すべての基盤データソースへのアクセス権があることを確認します。 レポート受信者の簡単な管理 AWS User Notifications を通じて受信者を一元的に管理することが可能です。メールアドレスの検証は初回の一度だけで済み、作成した連絡先リストは複数のダッシュボードレポートにわたって再利用できます。 利用を開始するには 開始する前に、 AWS User Notification (UNO) の通知設定 の表示、一覧表示、作成、更新、削除のアクセス許可が必要です。 スケジュールメール配信の利用を開始するにはほんの数分しかかかりません。大まかなワークフローは以下のとおりです。 Billing and Cost Management コンソールのダッシュボードに移動し、エクスポートするダッシュボードを選択して、アクションメニューから「メールレポートを管理 (Manage email reports)」→「レポートを作成 (Create report)」を選択します。 レポートに名前と説明を付け、ダッシュボード全体を送信するか単一のウィジェットを送信するかを設定し、必要に応じてレポート期間 (例：過去 7 日間、前月、過去 1 年) を設定します。プレビューを使ってレイアウトを確認してから先に進みます。   図 1：レポートの詳細と内容   受信者を指定するには、既存の AWS User Notifications 設定 を選択するか、新しい設定を作成します。AWS コンソールへのアクセス権を持たないステークホルダーの場合は、メール配信リストを使用してください。コンソールにアクセス権を持つメンバーが 1 人いれば、そのメンバーがグループを代表して初回のメール検証を完了できます。   図 2：メール受信者の設定   配信スケジュール (日次、週次、月次)、配信時間、終了日 (作成日から最大 3 年) を設定します。   図 3：レポートスケジュールの設定   サービスがレポートを生成・配信するためのアクセス許可を付与するために、サービスロールを作成または選択します。   図 4：セキュリティとアクセス許可の管理   すべての選択内容を確認し、「作成 (Create)」をクリックします。   図 5：確認と送信   プログラムからセットアップする場合は、 bcm-dashboards:CreateScheduledReport API を使用してレポートスケジュールを設定し、AWS User Notifications を通じて受信者を管理します。詳細な手順と API の例については、 AWS Billing and Cost Management Dashboards API ユーザーガイド を参照してください。 まとめ Billing and Cost Management ダッシュボードのスケジュールメール配信は、クラウド財務レポートを時間のかかる手作業から自動化された一貫性のあるワークフローへと変革します。繰り返しのレポート作業がなくなることで、FinOps チームは戦略的なコスト最適化に注力できるようになります。それと同時に、経営層からエンジニアリングリーダーまで、組織全体のステークホルダーが必要な財務情報に確実かつタイムリーにアクセスできるようになります。 この機能は、米国東部 (バージニア北部) リージョンで追加費用なしで 2026 年 4 月 9 日よりご利用いただけます。利用を開始するには、 AWS Billing and Cost Management コンソール のダッシュボードにアクセスし、アクションメニューから「メールレポートを管理 (Manage email reports)」を選択してください。詳細については、 AWS Billing and Cost Management ダッシュボードユーザーガイド および API リファレンス を参照してください。最新の FinOps ベストプラクティスとプロダクトアナウンスについては、 AWS Cloud Financial Management ブログ でご確認いただけます。 Shubir Kapoor Shubir Kapoor は、AWS Billing and Cost Management サービスのプリンシパルプロダクトマネージャーです。お客様がクラウドの価値を発見し、十分な情報に基づいた意思決定を行い、クラウドコストを最適化するのを支援するためのプロダクトに注力しています。 Gustavo Zioli Gustavo Zioli は、米国テキサス州を拠点とする AWS のアソシエイトソリューションアーキテクトで、クラウドベースの戦略とソリューションの策定を通じてお客様の目標達成を支援しています。AWS 入社前は、ブリガムヤング大学および Magnago and Custódio 法律事務所でデータアナリストとして勤務していました。ブリガムヤング大学で情報システムマネジメントの修士号を取得しています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。 原文 はこちらです。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 2 回レポートです。シリーズの背景や全体像については、 前回の大阪・初回レポート をご覧ください。 前日（4 月 13 日）の AI を自社の業務に活かしたい企業の皆様向けセッションに続き、2026 年 4 月 14 日は同じ大阪支社にて、AI で顧客を支援する IT 企業のエグゼクティブの皆様をお迎えし、「 AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 」と題したイベントを開催しました。AI エージェント時代のビジネスモデル変革をテーマに、登壇企業の実体験から「開発力をどう資産に変えるか」を共に考える一日となりました。 イベントの流れ 当日はまず、私 田中から「AWS で一歩先へ！生成 AI 時代のビジネスモデル変革の打ち手」と題したオープニングセッションを実施しました。このセッションでは、AI Agent を活用して IT 企業のビジネスの形がどう変わっていくのか、 Kiro のデモを交えながら解説しました。続いて、AWS ファイナンス部門の Finance Manager 坂本 秀隆 から「AWS のファイナンスが語る！生成 AI による業務効率化の勝ち筋」と題したセッションを通して、AWS 社内での実際の AI Agent を活用ストーリーをお届けしました（このセッションについては、 前回のレポート に同内容セッションの様子が含まれています！ぜひご覧ください）。 AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、お客様によるお取り組み事例の紹介セッションへ進みました。ここからは、大阪・関西を拠点に、社内に眠る知的資産を生成 AI で価値に変える取り組みを進めてこられた 2 社の事例をご紹介します。 事例紹介：ロジカル・アーツ株式会社様 〜受託開発からコールセンター特化 SaaS「HARMONY」へ〜 事例紹介の 1 社目は ロジカル・アーツ株式会社 様です。創業 1992 年、大阪・東京・福岡に拠点を構え、従業員は約 70 名。AWS アドバンストティアサービスパートナーとして、クラウドインテグレーション・SES・自社プロダクトの 3 事業を展開されています。当日は営業推進部 部長の長西 賢一 様に、自社 SaaS 「 HARMONY 」の開発ストーリーをお話しいただきました。 長西様がまず投げかけたのは、「開発力はあるのに、なぜ収益が安定しないのか」という問いでした。IT 企業の従来のビジネスモデルは、売上が「人数 × 単価 × 稼働率」の掛け算に縛られてしまい、プロジェクトが終われば収益はゼロ。開発力を磨き続けることが強みになる一方で、そこだけではスケールに限界がある──「開発力を資産に変えられないか」、その問題意識が SaaS 型ビジネス模索の出発点だったそうです。 ロジカル・アーツ様は、受託開発プロジェクトの中で AWS のコンタクトセンターソリューション Amazon Connect の導入支援実績を積んでおられ、コールセンター現場の課題を熟知していました。さらに Amazon Bedrock という生成 AI の選択肢が登場し、ドメイン知識をプロダクトに落とし込める手応えを得たことをきっかけに、SES や受託開発は継続しながら、SaaS 化による継続収益モデルへのシフトを進めていかれました。 こうして生まれたのが、AI コンタクトセンターソリューション「 HARMONY 」です。通話内容のリアルタイム文字起こし・要約生成、会話解析による CRM 自動入力、クレーム検知、1 日 1 万件の自動発信を可能にするプレディクティブコール機能など、7 つの AI 機能を搭載されています。 図: ロジカル・アーツ株式会社 HARMONY HARMONY の導入効果は数字にも表れており、(1) アフターコールワーク（後処理）時間が 20 分から 5 分へ短縮、(2) 一人あたり従来の 2 倍の電話対応の実現、(3) プレディクティブコールによるアウトバウンドコール数の向上、(4) ランニングコストの従来比 85% 削減、といった価値を提供できるようになったとのことです。あるお客様への導入実績では、アフターコールワーク（後処理時間）が 3 〜 5 分から 1 分へ短縮され、「要約精度が高く、操作も直感的で使いやすい」との評価を得られています。 HARMONY の事業化によって、ロジカル・アーツ様の収益構造は受託中心のフロー型から、月次継続課金のストック型へと徐々にシフトしています。さらに副次的な効果として、HARMONY 導入企業から別案件の支援依頼もいただけるようになり、コールセンターソリューションを入口に DX 全体を支援するパートナーへと立ち位置が進化しているそうです。 長西様は最後に、「開発力は最強のビジネス資産──ただし、プロダクトに変える”決断”が必要」「AI は脅威ではなく武器」「ドメイン知識こそが差別化の源泉」という 3 つのメッセージを残されました。今後は AI エージェント機能の拡張や外部カンファレンスへの出展を通じて、さらなるビジネス拡大を目指していかれるとのことです。 写真: ロジカル・アーツ株式会社 長西様によるセッション ビジネスモデルの転換という切り口で語ってくださったロジカル・アーツ様に続き、もう 1 社も同じく「自社プロダクトに挑戦した企業」ですが、取り組まれている領域と切り口はかなり違ったものでした。 事例紹介：株式会社アプリズム様 〜AI × IoT で「作って終わり」にしない見守りプロダクト「aiba」〜 事例紹介の 2 社目は 株式会社アプリズム 様です。2011 年設立、大阪市に本社を構え、従業員 100 名の IT 企業で、基幹系・業務系・Web システム開発に加え、AI・IoT・フィジカル AI 領域の研究開発にも取り組まれています。大阪大学産業科学研究所との産学連携も進められており、最先端技術の実用化に力を入れておられる会社です。当日は AI プロダクト本部 事業戦略室 室長の湯元 章彦 様、および同本部 プロダクト推進部の舛野 亮介様にご登壇いただきました。 アプリズム様もまた、受託開発中心のビジネスで感じていた「作って終わり」の課題について触れられました。実績は積み上がるものの、技術力や知見が案件ごとに分断されてしまい、会社として資産化されていかない──この課題意識から、受託で得たドメイン知識やアルゴリズムを抽象化し、再利用可能な形で提供する、つまり技術を「納品物」ではなく「資産」に変えるという方針のもと、自社プロダクト開発に舵を切られました。 こうして生まれたのが、競走馬の見守りプロダクト「 aiba 」です。馬房に設置した AI エッジカメラ（RGB カメラと暗視カメラの 2 レンズ搭載）が、独自開発の骨格推定アルゴリズムで馬の運動量の変化を 24 時間常時解析し、異常を検知するとクラウド経由でスタッフのスマートフォンにアラートと動画が即時配信される仕組みです。対応記録もシステム上に残せるため、「検知 → 通知 → 対応 → 記録・共有」までが一つの流れとして完結します。 図: 株式会社アプリズム様 aiba サービス概要 開発は試行錯誤の連続だったそうです。夜間・暗所での馬の骨格推定は撮影条件が難しく、高精度なモデル開発には何度もトレーニングを繰り返す必要がありました。この壁に対しては、 Amazon SageMaker AI で GPU を必要な時だけ利用する反復的な開発サイクルを確立して乗り越えられたとのことです。また、施設ごとに異なるネットワーク環境や馬房構造への対応も課題でしたが、 AWS IoT Core のフリートプロビジョニングを活用し、カメラをネットワークに接続するだけで認証が完了する仕組みを構築。 プロビジョニング工数を約 90% 削減し、非技術者の現場スタッフでも扱える展開体制 を実現されました。 進め方で徹底されたのは「 小さく始める 」ことだったといいます。PoC から入り、特定の業界で磨き、実際に使われる中でプロダクトを強くしていく。AWS のマネージドサービスを活用することで、インフラ運用にリソースを割かず、プロダクト価値そのものの改善に集中できたことも大きかったそうです。 登壇の締めくくりで印象的だったのが、舛野様の次の言葉でした。 「 我々のサービスは、AWS を使うことが目的ではありません。現場を支え、事業として続けるために、余計なことで悩まなくて済む基盤として AWS を選びました。 」 プロダクト開発の主語はあくまで現場の課題であり、テクノロジーはそれを支える手段にすぎない、という姿勢が強く伝わってくる一言でした。 写真: 株式会社アプリズム 舛野様によるセッション まとめ 大阪でご登壇いただいた 2 社に共通していたのは、 自社のドメイン知識と開発力を「資産」へと転換する という発想でした。そして、「開発力は十分ある。あとはそれをどう自社のビジネスに変えていくか」という段階で、クラウドのスモールスタートのしやすさや、必要なリソースを即日調達できる柔軟性といった AWS の価値に触れていただくことができました。 セッション後の懇親会では、収益構造を変えることで生まれるリスク、取り組みの中でうまくいった点・うまくいかなかった点なども含めて、参加者同士・登壇者・AWS チームとの間で活発な議論が交わされていました。サービスや技術そのものだけでなく、こうした実際の取り組みの事例や知見を発信していくことは、私たちの大切なミッションの一つだと考えています。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした大阪編に続き、次回は名古屋編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に何か取り組みたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ AWS Local Executive Roadshow 大阪・初回レポート（眠るデータを企業価値に変える） ロジカル・アーツ株式会社様の AWS 生成 AI 事例「コールセンター業務の効率化と品質向上を実現する生成 AI コンタクトセンター」 株式会社アプリズムが Amazon SageMaker AI と AWS IoT Core で実現した馬の見守りシステム「aiba」の開発と運用 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 私は日本全国・業種・業態を問わず様々なお客様を支援する広域事業統括本部の中の、首都圏以外のお客様を支援するチームに所属しています。私たちは 2026 年 4 月〜5 月にかけて、大阪・名古屋・広島・博多・札幌の 5 都市・計 8 回にわたり、「 AWS Local Executive Roadshow 」と題した生成 AI 活用をテーマとしたイベントを開催しました。AI を自社の業務に活かしたい企業の経営層・情報システム部門の皆様と、AI で顧客を支援する IT 企業の皆様、それぞれにお集まりいただき、各地域の登壇企業の実体験を起点に、参加者同士で生成 AI 活用の次の一歩を考える場として企画したシリーズです。本ブログシリーズでは、各拠点の開催レポートを、順にお届けしていきます。 初回となる本ブログでは、2026 年 4 月 13 日に大阪支社にて開催したイベント「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」の様子をレポートします。AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、生成 AI をいかに自社のビジネス価値へと転換するかをテーマに、登壇企業のストーリーを中心にお送りします。 全国各地でイベントを開催することにした背景 「東京のイベントには物理的に参加しづらい」「AI エージェントという言葉は聞くものの、自社で何から始めればよいかわからない」「社内にデータは眠っているはずだが、どう活用すればよいかイメージが湧かない」…こうしたご意見は、昨年度私たちが全国のお客様と対話する中で、繰り返しいただいてきました。AWS としても、リモートでのお打ち合わせを重ねるたびに、各地域のお客様に十分な情報をお届けしきれていないと感じていたのが正直なところです。 このギャップを埋めるため、私たち自身が実際に各地へ足を運び、AWS からの情報提供に加えて、その地域で生成 AI を実際のビジネスに活かしているお客様の生の声を共有する場を作ろう、というのが本シリーズの出発点です。 イベントの流れ 当日はまず、私 田中から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題して、生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、 Amazon Quick  のデモを交えながらご紹介しました。 写真: 筆者（田中）によるオープニングセッション 続いて、AWS ファイナンス部門の Finance Manager 坂本 秀隆 が「AWS のファイナンスが語る！生成 AI で実現する業務効率化の実践とデモ」と題して登壇し、わずか 2 名のファイナンス担当が多くの問い合わせや報告業務にどう対応していったのか、具体的な実例をデモを交えて紹介しました。印象的だったのは、AWS 社内でも AI の浸透は一夜で起きたわけではなく、 小さく始めて使い心地を体感するところから少しずつ広がっていった 、というポイントです。 写真: AWS ファイナンス部門 坂本によるセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、お客様事例のご紹介セッションへ進みました。ここからは、大阪・関西を拠点に、社内に眠る知的資産を生成 AI で価値に変える取り組みを進めてこられた 2 社の事例をご紹介します。 事例紹介：株式会社サクラクレパス様 〜AWS × Dify で、安全・低コストに始める全社生成 AI〜 事例紹介の 1 社目は 株式会社サクラクレパス 様です。1921 年創業、大阪市に本社を構え、グループ従業員数は約 1,600 名。文具・画材・事務用品の製造販売を主軸に、工業用・医療用・エレクトロニクス分野にも色材技術を応用されています。当日は統轄本部 情報システム部長の高橋 幹成 様に、全社生成 AI 活用の取り組みについてお話しいただきました。 サクラクレパス様社内では、2025 年 7 月までは社内での生成 AI 利用は原則禁止のルールがありました。これは、情報漏洩・著作権・品質・コンプライアンス・セキュリティ管理上のリスクが整理できていなかったためですが、テクノロジーの進化とともに、社内外で「AI を活用したい」という声が急速に広がったことで、利用制限から活用推進へと方針を転換 されました。2025 年 8 月より、安全な SaaS 型チャットの導入と社内ガイドラインの策定を進め、RAG による社内のナレッジ活用、業務フローの一部を生成 AI/AI エージェントに代行させるところまで、段階的に AI のビジネス活用を進められました。 これらのお取り組みのなかで特に試行錯誤された点として挙げられていたのが、生成 AI の「3 ヶ月ごとに常識が変わる」というスピード感に対応していくことです。「どのモデルが最適か判断できない」「技術的ハードルが高く専門エンジニアが必要」「高額な初期投資が必要で、数ヶ月後には状況が変わっている」──この 3 つの壁にどう向き合うかが論点でした。サクラクレパス様は、今後様々なモデルや用途が登場することも見据えてマルチ LLM を前提としたプラットフォームを構築すること、可能な限り自前で開発せずエージェント機能を活用すること、ノーコード・ローコード開発手法（ Dify ）で開発を民主化すること、という 3 つの方針を立てて、それらの課題に対応されました。 もともとセキュリティリスクへの懸念から生成AI活用を制限していた背景があったため、AI 基盤の選定には セキュリティの確保を最優先事項 として位置づけました。このことをふまえて、AI 基盤としてグローバル水準のコンプライアンス・データ管理を実現できる Amazon Bedrock を採用しました。また、専門的な知識がなくても AI アプリケーションが作成ができガバナンスにも強みがある Dify を選定し、Amazon Bedrock と組み合わせて社内のAI共通基盤とされました。Amazon Bedrock では、ユースケースに応じて複数のモデルプロバイダーが提供するモデルを切り替えて使用することができ、進化が早い領域においても様々な試行錯誤を低リスクで行える環境を実現されました。さらに、AWS の生成 AI 実用化推進プログラムを活用して、初期投資を抑えながら検証を行う「小さく始める」アプローチが実現できたとも語っています。 運用面では、 情シス主導 × ユーザー作成の役割分担 という考え方をもとに社内展開を進められました。お取り組みの工夫として、ツールを配るだけでなく経営層も現場も共通認識を持てるよう、生成 AI 勉強会を実施されたこと、少数精鋭の検証チームを作成し様々なユースケースに対して試行錯誤の検証を日々行っていること、ただ業務を AI に当てるだけでなく、既存の業務の見直しを並行して行い、①やめる業務、②プロセスを改善する業務、③デジタル化する業務、④自動化する業務 といった仕訳けをされるという工夫についてもお話いただきました。これによって、より注力すべき領域が明確になり、AIを取り入れた場合の業務のゴールも明確になる効果があります。また、このような仕訳のなかで、AIが得意な領域、工夫が必要な領域を見定めることにも繋がりました。 社内ルールの面でもいくつかの工夫をされました。ノーコードアプリは、誰でも AI アプリを作れる便利さ故に、管理されない「野良アプリ」の増殖が課題となりがちです。サクラクレパス様はこれに対し、ユーザーはテスト環境で自由に検証し、情シスが承認したアプリだけを本番環境に昇格させる運用ルールを確立し、自律と統制のバランスを実現されています。 サクラクレパス様のお取り組みはこれからも続いていきます。全社展開を見据えた Dify 基盤の Amazon S3 + Amazon Bedrock Knowledge Bases への移行、業務棚卸に基づく AI 適用業務の明確化、部門別パイロット導入から全社的な横展開、AI エージェントによる業務自動化など、やるべきことはまだまだあり、今後は「生成 AI を『特別なツール』から『日常の業務インフラ』として位置づけて活用を進めていきたい」というメッセージで締めくくられました。 「全社基盤の整備」というマクロな切り口で語ってくださったサクラクレパス様に続き、もう 1 社は「研究・開発現場に眠る専門知識」という切り口から生成 AI に向き合われた事例です。 事例紹介：メック株式会社様 〜ベテランの専門知識を AI エージェントに渡す、自前 Agentic RAG の挑戦〜 事例紹介の 2 社目は メック株式会社 様です。1969 年設立、兵庫県尼崎市に本社を構える東証プライム上場企業で、従業員数は単体 277 名・連結 480 名。プリント配線板（PCB）製造用の薬品、特に半導体パッケージ基板向け銅表面処理剤「MECetchBOND CZ シリーズ」を主力とされ、世界中のパッケージ基板メーカーに製品を提供されています。当日は情報システム部門 岸本 宗真 様に「AI Agent による検索システム」の開発ストーリーをお話しいただきました。 設立から 57 年近くが経つメック様には、これまでの数多くの受託案件対応の過程で蓄積された大量のデータが存在します。これらを活用して、「経験や力量の差によらず全員が高い水準で業務に取り組める状態にしたい」「複雑な専門領域でも直感的に情報にアクセスできるようにしたい」「報告書・特許・議事録・論文といった知的資産を戦略的な強みに変えたい」という観点から、AI の活用に取り組まれました。 岸本様がまず取り組まれたのは、チャットベースで過去の案件ナレッジを得られる Agentic RAG （RAG に AI エージェントの自律的判断を組み合わせ、必要に応じて複数のデータソースを動的に検索できる仕組み）アプリケーションの構築でした。しかし、実際に取り組んでみると、AI は研究データの取得のために複雑な手順が必要となってしまうケースがあり、取得がうまくいかないケースがありました。また、業界特有の言葉・社内の専門用語・プロジェクトの詳細といった、検索の前提となるような知識を AI が持っていないために、もっともらしい嘘（ハルシネーション）を返してしまうという状況も発生しました。 これを解決するために、 専門ナレッジを事前に AI に付与する アプローチを採用しました。文書検索の前処理として、プロジェクト単位で概要・進捗・時系列・関連ファイルをまとめた「スキル」と呼ばれる専門ナレッジを情報検索エージェントに渡し、「ベテラン社員の視点」で社内データを探せる状態を作りました。また、この仕組みに継続性を持たせるために、新しいデータが追加されるたびにナレッジが自動更新される情報更新エージェントも同時に作成しました。 図: メック株式会社 社内ナレッジを使いこなす Agentic RAG 構成 アーキテクチャは、 AWS Amplify と Amazon Bedrock AgentCore を使用し、AI アプリケーションをサーバーレスに稼働させることで費用や開発量を抑えたスモールスタートを実現しました。ベクトルデータベースには Amazon S3 Vectors を採用し、データベースレイヤーのコストも抑えることができました。データベースレイヤーのコストはこれまで検証の壁になりがちでしたが、Amazon S3 Vectors の活用が取り組みにおけるコストの障害を解消することに寄与したと語っていただきました。さらにAWS 製の AI エージェントライブラリ Strands Agents との相性の良さもポイントに挙げられました。 実際の導入にあたっての技術的な工夫として、AI Agentによる検索性を意識してメタデータを持たせる工夫をされました。これが、AI が効率的に文書検索を行うことに寄与しています。また、社内の専門用語やプロジェクトの詳細など、社内でも専門とするコンテキストが異なる場合があるため、まずはグループ単位で最適化し、少しずつスコープを拡大していくというスモールスタートのアプローチを取るなど運用面でも工夫をされました。 このような工夫を重ねられ、現在は特定の部門で本番導入をした直後でありながら、導入部門から非常に前向きなフィードバックが得られており、他グループへの展開、研修など社内の別ユースケースへの活用など様々な展開が見えている状態とのことです。数字に表れる成果はこれからですが、数字よりも大事な『次の取り組みにつながる変化』が既に社内で起きていると岸本様は語られました。一方、様々な社内特有の暗黙知をどうAIに渡していく（渡し続ける）こと、データフォーマットに関わる課題、多様化するユースケースに対応するため開発速度を上げていくことなど、現在進行中の課題感もあるとのことです。そのなかでも、開発速度に関しては AWS 主催のハッカソンイベントへの参加、コストに対しては Amazon S3 Vectors など新しい機能の積極的な活用、のように、ひとつひとつ課題に向き合って解決されていることをお話いただきました。 岸本様は最後に、「製造業でも自前でできる」「小さく早く始めて、大きく育てる」という 2 つのメッセージを伝えてくださいました。地方にいる製造業では、ドメイン知識が多くあるため、これらを積極的に活用できる基盤を整えることでAIを大きく活用できる可能性がある、生成 AI というテクノロジーは革命だが、取り組みは泥臭く地道に、一歩一歩進めていく部分も重要、とお話いただきました。 写真: メック株式会社 岸本様によるセッション パートナーセッション：クラスメソッド株式会社様 〜生成 AI 活用、次の一歩の具体像〜 お客様事例のあとには、AWS プレミアティアサービスパートナーである クラスメソッド株式会社 様のセッションです。「生成 AI 活用、次の一歩の具体像」と題して、技術ブログ「 DevelopersIO 」で多数の生成 AI 関連記事を執筆され、Amazon Bedrock AgentCore を特に得意とされているクラウド事業本部 コンサルティング部 AI ソリューションアーキテクトの神野 雄大 様より、これまでの支援実績に基づいたお話をいただきました。 自律型コーディング AI エージェントの登場によって、曖昧な指示でも高品質なアウトプットが出せるようになり、変化は急速に進んでいる一方で、PoC の先に進めない、作ったけれど運用が回らない、使われない・広がらない、という 3 つの局面で多くのお客様が悩まれている、といった現状についてお話しいただきました。これらの課題に対して、効果のある進め方の例として4つの実際のご支援プロジェクトの事例を紹介いただきました。 「スモールスタートして、成功事例を他部門へ展開する」「ガバナンスのための基盤を整える」「投資対効果を数値化する」「改善サイクルを積み重ねる」といった、生成 AI 活用のポイントとなる事例を、実際にクラスメソッド様がどう支援され、どう結果が得られたかについて詳しく紹介いただきました。 写真: クラスメソッド株式会社 神野様によるセッション まとめ 大阪でご登壇いただいた 2 社のお客様とパートナー様は、それぞれ異なるお取り組みでありながら、共通していたのは、小さく始め、地道で時には泥臭い改善のサイクルを積み上げていく という姿勢だと考えます。AI 活用は決してツール導入だけでは終わりません。スモールスタートでの導入、成功体験からはじめ、そこで得られたデータの課題、運用の課題、リテラシーの課題は、現場の意見も取り入れながら改善サイクルを回しておられたと思います。 セッション後の懇親会では、セキュリティの考え方、データ整備の進め方、社内への AI 浸透の仕方など、参加者同士・登壇者・AWS チームとの間で活発な議論が交わされていました。サービスや技術そのものだけでなく、こうした実際の取り組みの事例や知見を全国各地様々なお客様に対して発信していくことは、AWS の大切なミッションの一つだと考えています。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした大阪・初回に続き、次回は翌日開催の大阪・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ メック株式会社の事例：Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

私にとって 2026 年 5 月 4 日週、最もエキサイティングだったニュースは、 Amazon Bedrock AgentCore が最初のマネージド支払い機能をプレビュー したことです。これにより、AI エージェントが API、MCP サーバー、ウェブコンテンツ、その他のエージェントに自律的にアクセスして支払いを行うことが可能になります。Coinbase や Stripe と提携して構築されているため、請求、認証情報管理、コンプライアンスを実現するためにカスタマイズしたシステムを構築するという、差別化されていない面倒な作業が不要になります。 Coinbase CDP ウォレットまたは Stripe Privy ウォレットを支払い接続として接続し、セッションレベルの支出制限を設定すると、エージェントは実行中に自律的に取引を行います。私が最もワクワクしているのは、AgentCore 決済で何ができるかということです。例えば、リアルタイムの市場データに対してその場で支払いができるリサーチエージェントや、タスクの途中で有料 API を呼び出すコーディングエージェントなどです。 詳細については ブログ投稿 にアクセスし、 ドキュメント を使用してさらに詳しく調べた上で、 AgentCore CLI の使用を開始してください。 2026 年 5 月 4 日週のリリース 2026 年 5 月 4 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Agent Toolkit for AWS – AI コーディングエージェントがエラーを減らし、トークンコストを削減して、エンタープライズグレードのセキュリティコントロールを実現しながら AWS で構築するのに役立つ、本番環境ですぐに利用できるツールとガイダンスのスイートです。追加料金なしでご利用いただけます。Agent Toolkit for AWS は、 AWS ラボ で利用可能な MCP サーバー、プラグイン、スキルの後継です。使用を開始するには クイックスタートガイド にアクセスするか、 GitHub で利用できるスキルとプラグインをご参照ください。 AWS MCP サーバーの一般提供開始 – 少数の固定ツールセットを通じて、すべての AWS サービスに対するセキュアかつ認証済みのアクセスを AI エージェントやコーディングアシスタントに付与する、マネージドリモートモデルコンテキストプロトコル (MCP) をご使用いただけます。これは Agent Toolkit for AWS の一部です。詳細については、 Seb Stormacq のブログ投稿 をご覧ください。 AI エージェント向け Amazon WorkSpaces (プレビュー) – AI エージェントを使用して、マネージド WorkSpaces 環境からデスクトップアプリケーションに安全にアクセスして操作できます。この機能により、組織はエンタープライズグレードのガバナンスとコンプライアンスを完全に維持しながら、日常のワークフローを大規模に自動化できるようになります。詳細については、 Micah Walter のブログ投稿 をご覧ください。 Amazon EC2 M8idn/M8idb インスタンスと R8idn/R8idb インスタンス – これらのインスタンスは、AWS および最新の第 6 世代 AWS Nitro Card でのみ利用可能なカスタムの第 6 世代 Intel Xeon Scalable プロセッサを搭載しています。前世代のインスタンスと比較して、これらのインスタンスは vCPU あたりのコンピューティングパフォーマンスを最大 43% 向上させます。M8idn/R8idn インスタンスは最大 600 Gbps のネットワーク帯域幅を提供し、M8idb/R8idb インスタンスは最大 300 Gbps の EBS 帯域幅を提供します。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 2 周年を迎える Valkey – Valkeyは、オープンでコミュニティ主導型のテクノロジーが、単一ベンダーのどのモデルよりもイノベーションが早く、拡張性が高く、より多くの価値をもたらすことを証明しています。Valkey では Docker のプルが 1 億回 (前年比で 17 倍に増加) を超え、225 人以上のコントリビューターが 1,500 件を超えるプルリクエストを提出しました。これは、同時期の Redis の開発ペースの約 2 倍です。 Amazon ElastiCache では最新の Valkey 9.0 を使用することもできます。 SQL を使用した数十億スケールのベクトルのクエリ – 標準 SQL を使用して Amazon Aurora PostgreSQL-Compatible Edition の Amazon S3 Vectors をクエリする方法と、ベクトルの類似性の結果を 1 つのクエリでリレーショナルフィルターと組み合わせる方法を学ぶことができます。例えば、意味論的に最も類似した製品を見つけてから、1 つの SQL ステートメントにおいて価格、在庫状況、またはテナントでフィルタリングする方法などです。 AWS DevOps エージェントを使用したエンドツーエンドのエージェンティック SRE の構築 – Amazon CloudWatch、Splunk 、GitHub、Slack とシームレスに統合して、調査範囲を定義する DevOps エージェントスペースを設定する方法を学びましょう。また、Webhook を介して自動調査をトリガーする方法、緩和計画を作成する方法、エージェント対応仕様を Kiro などのコーディングエージェントに渡して実装する方法も学ぶことができます。 AWS ブログ投稿の全リストについては、必ず AWS ブログ ページをご覧ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 5 月 11 日週のニュースは以上です。2026 年 5 月 18 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

本ブログは株式会社アクト・ノード様とAmazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの池田です。 日本の一次産業では、深刻な人手不足と熟練知識の属人化が大きな課題となっています。日本の一次産業従事者は2005年比で2025年には半減し、今後20年で更に4分の1になると推計されています。 株式会社アクト・ノード様は農業・畜産・水産養殖の現場のDXを推進するサービス「 ACT.app 」を提供されております。（ AWS導入事例 ） 農業・畜産・水産養殖の現場では、環境や生育状態の継続的な監視と異常時の早期対応が必須ですが、熟練者による現地見回りに依存しており、1日1～3回が限界です。そこで、生産者が自然言語で養鶏の様子を相談すると、AIが見守り要件を理解しカメラ画像を自律分析する「見守りエージェントAI」を開発されました。 本記事では、 Amazon Bedrock と Amazon Bedrock Agent Core , Amazon Nova を活用した、一次産業の根本的な課題解決への取り組みについてご紹介します。 お客様の状況と経緯 株式会社アクト・ノード様は、農業・畜産・水産養殖の現場のDXを推進するサービス「ACT.app」 を提供されており、以下の課題に直面されていました。 業界を取り巻くビジネス上の課題 日本の一次産業従事者は2005年比で2025年には半減し、今後さらに減少速度が加速していく見通しです。現場では熟練者が自分の目で見回りを行って異常を判断していますが、物理的に 1 日 1～3 回の見回りが限界で、夜間に異変が起きてしまうと翌朝まで気づけません。 しかも、見守りたい対象は現場ごとにまったく異なります。養鶏場では鶏の暑熱反応、果樹園では開花状況、水産養殖では魚の水面呼吸など。こうした多種多様に分布するニーズのひとつひとつに合わせた形で専用の画像認識 AI やセンサーを開発・導入していては、コストが合いません。 もう一つの根深い問題が、熟練知識の属人化です。それぞれの生き物について、どんな観点から何を見れば良いか、という知見はベテランの頭の中にしかない。言語化するのが難しく、世代交代とともに失われる知識も多くあります。 システム上の課題 また、前述のビジネス上の課題に加え、システム的な課題もあります。既存の定点カメラは単純な記録にとどまり、異常検知は結局、人間が映像を目視して判断するしかありませんでした。つまり、システム化を行い、カメラで映像を確認できるようにしたとしても、経験や知識が豊富な人間が判断する、という状況は変わらなかったわけです。 これらの課題に対してアクト・ノード様が目指したのは、生成 AI を利用した汎用的な見守りプラットフォームへの転換でした。下図は、従来の見守り業務（As-is）と、見守りエージェントAI導入後（To Be）の比較です。 ソリューション / 構成内容 「見守りエージェントAI」は、大きく3つのステップで動作します。① 生産者がAIにチャットで相談し「見守りリクエスト」を生成 → ② 現場のカメラから画像を取得 → ③ AIが「見守りリクエスト」に従い画像を分析し、異常時にアラート通知。この一連の流れを、2つのAIエージェントが連携して担います。 ステップ①：見守り相談AI – エージェントAIとチャットで会話し「見守りリクエスト」を生成 生産者がチャットで「鶏が暑がって口をあけていないか見守ってほしい」と入力するところから始まります。AIが対話を通じて要件を掘り下げ、見守りの対象、検知すべき状態、アラート条件を整理。最終的に「見守りリクエスト」という構造化データ（JSON + 参考画像）を自動生成します。 ここで重要なのが、従来の画像認識 AI とのアプローチの違いです。従来は認識したい対象ごとに大量の学習データを用意する必要がありました。本システムでは、参考画像を数枚と説明文を組み合わせる Few-shot examples の手法を採用。たとえば、鶏が暑さを感じたときに口を大きく開けて呼吸する「パンティング」という行動を、参考画像と説明文を「お手本」として AI に理解させ、検出できるようにしています。 基盤モデルとして Amazon Bedrock 上の Anthropic Claude を採用。Amazon Bedrock Agent Core の会話メモリ機能により、セッションをまたいだ文脈の維持にも対応しました。 ステップ②③：見守りAI — 見守りAI – Webカメラの画像を定期的に取得し自律分析する 「見守りリクエスト」が作成されると、見守り AI が稼働を開始します。現場に設置済みの定点カメラから画像を取得し（既存設備をそのまま活用）、リクエストの内容に基づいて自律的に分析。30 分に 1 回、1 日 48 回の画像分析が可能で、従来の人手による 1 日 1 回の見回りとは桁違いの監視頻度です。 検出結果は JSON 形式の構造化データとして記録され、異常時にはアラートを自動通知します。蓄積された見守り結果は生育履歴データとなり、環境データや作業記録と組み合わせた分析にも活用できます。 導入効果 「見守りエージェントAI」の導入により、以下の効果が実現されています。既に養鶏事業者の青木ブロイラー様の現場で実証実験をすすめています。 見守り頻度：1日1回 → 最大48回 人手による見回りでは物理的に1日最大3回が限界だった監視を、AI が 30 分間隔で代行。24 時間 365 日、夜間や早朝も含めた常時監視が可能になりました。 暗黙知のデータ化（言語化） 注目すべき副次効果もありました。生産者がチャット AI に見守り内容を伝える過程で、「経験と勘」にとどまっていた暗黙知が「見守りリクエスト」として言語化・構造化されていくのです。効果の高い見守りパターンを生産者間で共有する仕組みも計画中で、属人的だった生産技術の継承を加速するプラットフォームへの発展が見込まれます。 検出精度の現状 養鶏の暑熱反応検知シナリオでは、AIによる自律的な見守りが実用レベルで機能することを確認しました。ユーザーの目視判断と比較して検出精度にはまだ改善の余地がありますが、現場から「継続利用する価値がある」との評価を得ています。Few-shot examples の追加やモデル改善により、精度は着実に上がってきています。 今後の展望 現在は養鶏が主な実証対象ですが、アクト・ノード様はすでに次の展開を進めており、「見守りエージェントAI」のさらなる機能拡張を計画されています。 対応分野の拡大 柑橘類（みかん）の開花状況監視など、養鶏以外の農業分野への適用を検討中です。農林水産省のスマート農業実証プロジェクトにも認定されており、一次産業全体への横展開が視野に入っています。 見守りリクエストの共有 ある生産者が作った効果的な見守りパターンを、別の生産者がそのまま使える仕組みです。前述の「暗黙知の見える化」で生まれた見守りリクエストが、ベストプラクティスとして流通するイメージです。 マルチデータ対応 カメラ画像だけでなく、環境センサーやアプリの作業記録など、複数のデータソースを組み合わせた見守りへと拡張する計画もあります。画像で「鶏の様子がおかしい」と検知し、同時に温度センサーで「鶏舎内が xx℃ を超えている」と確認できれば、判断の精度は格段に上がります。 まとめ 本企業は日本の一次産業を取り巻く課題を、AI エージェントを活用して解決する好例です。 アクト・ノード様の新技術への積極的な姿勢と、AWS が提供する使いやすい生成 AI サービスの組み合わせが、革新的なソリューション開発につながりました。 アクト・ノード様による「見守りエージェント AI」は、一次産業の深刻な人手不足を技術で解決し、食の安定確保に貢献することが期待されています。 代表取締役百津様からのコメント 「一次産業の現場では、多様な見守りニーズがロングテールに分布しており、従来の専用AI開発では対応しきれませんでした。Amazon Bedrock により、生産者の自然言語での要件定義を理解し、自律的に見守りを実施するエージェントAIを実現できました。生成AIの力で、一次産業の人手不足と熟練知識の属人化という根本的な課題を解決できることを実証できました。」 本取り組みは、経済産業省・NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）主催の「GENIAC PRIZE」にもエントリーしており、国産基盤モデルを活用した生成AIの革新的な活用事例としても取り上げられています。また、農林水産省のスマート農業実証プロジェクトにも認定されており、国を挙げた一次産業のDX推進において重要な役割を果たしています。 アカウントマネージャー 池田 華子 ソリューションアーキテクト 小林 大樹

2026年1月22日〜23日、AWS Loft Tokyo にて11社87名が参加した「合同 AI-DLC Unicorn Gym」を開催しました。AI駆動開発ライフサイクル（AI-DLC）による開発プロセスの変革を体験いただくイベントです。イベント全体の詳細は「 11社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 」をご覧ください。 本記事では、参加企業の一社である 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属の竹地氏に、現場のエンジニアとしてAI-DLCを体験して感じた手応えを寄稿いただきました。 以下、株式会社日立産業制御ソリューションズ 竹地氏による寄稿です。 生成AIを開発に導入したものの、「思ったようにいかない」「自分で手を動かしたほうが早い」と悩む現場は多いのではないでしょうか。 株式会社日立産業制御ソリューションズの竹地です。当社は日立グループの一員として、製造業・社会インフラ向けのITソリューションや制御システムの開発を手がけています。私たちの開発チームも、まさに同様の課題を感じていました。 本記事について打ち合わせる早川（左）と竹地氏（右） 今回、2026年1月22日〜23日にAWS Loft Tokyoで開催された11社合同の「AI-DLC Unicorn Gym」に参加させていただきました。ここでは、要件定義（Inception）から設計・実装・デプロイ（Construction）に至る全工程をAI主導で進める開発プロセスを体験しました。従来なら3人月以上かかる規模の開発が、わずか2日間で形になるという成果を得ました。 本稿では、私たちが AI-DLC（AI駆動開発ライフサイクル） の実践を通じて得た「リアルな手応え」と、これからのエンジニアに求められる「役割の変化」について共有します。 参加の背景 当社ではさまざまな生成AIを導入してきましたが、「期待通りに動かない」「信用できない」という声から、活用は局所的な補助に留まっていました。一方、AI技術の急速な進化を踏まえると、開発プロセスそのものを「AI前提」にアップデートする必要があります。 今回の Unicorn Gym では、AIコーディングエージェント「 Kiro 」を開発の主体に据えるAI-DLCを体験し、その実効性を検証することを目的としました。 実施内容 テーマ：分散したIT資産・セキュリティデータの統合基盤構築 当社内にはIT資産、セキュリティ、プロジェクト収支など、形式も管理場所も異なるデータが複数のシステムに分散しており、必要な情報の抽出・結合に膨大な工数がかかっていました。社内で見積もったところ、この統合基盤を従来の手法で構築した場合は約530時間（3人月相当）の規模です。今回の Unicorn Gym では、この「IT資産・セキュリティデータの統合活用基盤」を2日間で構築できるか挑戦しました。 Unicorn Gym 当日の様子 1日目の Inception（構想）では、Kiro との対話で曖昧なビジネス意図を詳細要件に変換しました。人間がレビュー・承認し、AIが仕様書に即時反映するサイクルを繰り返します。2日目の Construction（構築）では、前日の要件をもとに Kiro が設計・コードを提案し、モブコンストラクション形式で集中的に実装を進めました。 AI-DLCでは、エンジニアと業務部門の担当者（今回は資産管理の担当者や情報セキュリティの責任者）が肩を並べて作業し、AIの提案に対してその場でフィードバックを返します。「この項目は管理対象に含めるべきか」「このチェックロジックは現場の運用に合っているか」といった判断を、業務を熟知した担当者がその場で下せるため、数分後には修正された仕様書やコードが提示されます。この即時のフィードバックループが、AI-DLCの大きな強みです。 成果物と工数比較 開発工程 AI-DLCでの成果物 手動開発の想定工数 要件定義・設計 ユースケース・ストーリー8本、API設計14本 120〜160時間 バックエンド Lambda 18関数（約2,600行）、DynamoDB 9テーブル 160〜200時間 フロントエンド ダッシュボードUI、RBAC（ロールベースアクセス制御）、CSV出力 120〜160時間 インフラ・CI/CD CDK 2系統、IAM設定、CI/CDパイプライン 60〜80時間 合計 約70時間（7名×実働10時間） 約530時間（3人月相当） 2日間で構築したIT資産統合基盤のメインページ 2日間で構築したIT資産統合基盤のチェックページ ただし、この成果には業務担当者が同席し即時に意思決定できる体制、業務割り込みのない集中環境、プロトタイプに特化したスコープ（結合テストやセキュリティ審査は未実施）という条件がありました。それでも、設計・実装からAWS環境へのデプロイまでを2日で形にできた点は、AI-DLCの可能性を強く実感する結果でした。 学び ① 設計の「ちょうどいい」を見極めるのは人間 Kiro はコード生成や設計提案において精度の高い回答を返してくれますが、時にプロジェクトの規模以上に厳格な構成を提案することがあります。今回も、小規模なバッチ処理に対して40ファイル以上のDDD（ドメイン駆動設計）構成が提示された場面がありました。「この規模であればシンプルな構成で十分」と判断し、方針を修正したのは人間です。AIが高品質な設計パターンを提案できるからこそ、それをプロジェクトの実情に合わせて取捨選択する判断力がより重要になります。 ② コードの修正もAIに任せる AIがミスをしたとき、自分でコードを直したくなります。しかし人間が直接手を加えると、AIが保持するコンテキストと実態に乖離が生じ、以降の提案精度が下がります。人間が修正した場合はその内容をAIに伝えることで乖離を防ぐこともできますが、基本的には修正もAIとの対話を通じて行い、「AIが認識しているコードが正」というルールを徹底することが、AI駆動開発をスムーズに回すための鍵でした。 ③ 意思決定と言語化に集中する開発手法 AIは数分でレビュー結果を反映し、次の成果物を提出してきます。人間はコードを書く代わりに、レビューと意思決定を高速に繰り返します。また、AIは暗黙の前提や文脈を汲み取ることができないため、仕様や意図を正確に言語化する力が求められます。コーディングから解放された分、ビジネス価値の判断と要件の言語化に集中できる点が、AI-DLCの大きな魅力です。 これからの展望 私たちが得た最大の収穫は、AI-DLCが単に時短のための開発手法ではないという点です。開発の密度とフィードバックの速度を高めることで、結果として開発全体が加速される ─ この体験は、従来の効率化とは質の異なるものでした。コードを書く作業はAIに委ね、人間はレビュー・承認に専念する。AIが一般的な設計パターンやベストプラクティスを瞬時に提示するからこそ、自社固有の業務制約や設計判断を見抜く技術力がより重要になります。 当社では今回の成果を踏まえ、AI-DLCのワーキンググループを発足する予定です。サンドボックス環境の整備やAIエージェントを使いこなすためのルール（Steering / Skills）の構築を進め、社内の開発プロセスへの適用を本格的に推進していきます。 （寄稿ここまで） AI-DLC に興味を持たれた方は、 aidlc-workflows（GitHub） をご覧ください。Kiro を使ってAI-DLCを始めるためのワークフローやテンプレートを公開しています。 Unicorn Gym 参加メンバー（日立産業制御ソリューションズ、AWS） 著者 竹地 航太郎 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属。クラウドや生成AIを活用したソフトウエア生産技術の社内展開を担当。AI‑DLC Unicorn Gymへの参加をきっかけに、AI駆動開発を取り入れた社内プロジェクトを推進中。 早川 康平 アマゾン ウェブ サービス ジャパン テクニカルカスタマーソリューションズ マネージャー。金融勘定系システムのPM、Webエンジニア、SaaSプロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、日立グループ専任のCSMとして、SaaSアプリケーション開発やAI活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。

2026年1月22日〜23日、AWS Loft Tokyo にて11社87名が参加した「合同 AI-DLC Unicorn Gym」を開催しました。AI駆動開発ライフサイクル（AI-DLC）による開発プロセスの変革を体験いただくイベントです。イベント全体の詳細は「 11社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 」をご覧ください。 本記事では、参加企業の一社である 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属の竹地氏に、現場のエンジニアとしてAI-DLCを体験して感じた手応えを寄稿いただきました。 以下、株式会社日立産業制御ソリューションズ 竹地氏による寄稿です。 生成AIを開発に導入したものの、「思ったようにいかない」「自分で手を動かしたほうが早い」と悩む現場は多いのではないでしょうか。 株式会社日立産業制御ソリューションズの竹地です。当社は日立グループの一員として、製造業・社会インフラ向けのITソリューションや制御システムの開発を手がけています。私たちの開発チームも、まさに同様の課題を感じていました。 本記事について打ち合わせる早川（左）と竹地氏（右） 今回、2026年1月22日〜23日にAWS Loft Tokyoで開催された11社合同の「AI-DLC Unicorn Gym」に参加させていただきました。ここでは、要件定義（Inception）から設計・実装・デプロイ（Construction）に至る全工程をAI主導で進める開発プロセスを体験しました。従来なら3人月以上かかる規模の開発が、わずか2日間で形になるという成果を得ました。 本稿では、私たちが AI-DLC（AI駆動開発ライフサイクル） の実践を通じて得た「リアルな手応え」と、これからのエンジニアに求められる「役割の変化」について共有します。 参加の背景 当社ではさまざまな生成AIを導入してきましたが、「期待通りに動かない」「信用できない」という声から、活用は局所的な補助に留まっていました。一方、AI技術の急速な進化を踏まえると、開発プロセスそのものを「AI前提」にアップデートする必要があります。 今回の Unicorn Gym では、AIコーディングエージェント「 Kiro 」を開発の主体に据えるAI-DLCを体験し、その実効性を検証することを目的としました。 実施内容 テーマ：分散したIT資産・セキュリティデータの統合基盤構築 当社内にはIT資産、セキュリティ、プロジェクト収支など、形式も管理場所も異なるデータが複数のシステムに分散しており、必要な情報の抽出・結合に膨大な工数がかかっていました。社内で見積もったところ、この統合基盤を従来の手法で構築した場合は約530時間（3人月相当）の規模です。今回の Unicorn Gym では、この「IT資産・セキュリティデータの統合活用基盤」を2日間で構築できるか挑戦しました。 Unicorn Gym 当日の様子 1日目の Inception（構想）では、Kiro との対話で曖昧なビジネス意図を詳細要件に変換しました。人間がレビュー・承認し、AIが仕様書に即時反映するサイクルを繰り返します。2日目の Construction（構築）では、前日の要件をもとに Kiro が設計・コードを提案し、モブコンストラクション形式で集中的に実装を進めました。 AI-DLCでは、エンジニアと業務部門の担当者（今回は資産管理の担当者や情報セキュリティの責任者）が肩を並べて作業し、AIの提案に対してその場でフィードバックを返します。「この項目は管理対象に含めるべきか」「このチェックロジックは現場の運用に合っているか」といった判断を、業務を熟知した担当者がその場で下せるため、数分後には修正された仕様書やコードが提示されます。この即時のフィードバックループが、AI-DLCの大きな強みです。 成果物と工数比較 開発工程 AI-DLCでの成果物 手動開発の想定工数 要件定義・設計 ユースケース・ストーリー8本、API設計14本 120〜160時間 バックエンド Lambda 18関数（約2,600行）、DynamoDB 9テーブル 160〜200時間 フロントエンド ダッシュボードUI、RBAC（ロールベースアクセス制御）、CSV出力 120〜160時間 インフラ・CI/CD CDK 2系統、IAM設定、CI/CDパイプライン 60〜80時間 合計 約70時間（7名×実働10時間） 約530時間（3人月相当） 2日間で構築したIT資産統合基盤のメインページ 2日間で構築したIT資産統合基盤のチェックページ ただし、この成果には業務担当者が同席し即時に意思決定できる体制、業務割り込みのない集中環境、プロトタイプに特化したスコープ（結合テストやセキュリティ審査は未実施）という条件がありました。それでも、設計・実装からAWS環境へのデプロイまでを2日で形にできた点は、AI-DLCの可能性を強く実感する結果でした。 学び ① 設計の「ちょうどいい」を見極めるのは人間 Kiro はコード生成や設計提案において精度の高い回答を返してくれますが、時にプロジェクトの規模以上に厳格な構成を提案することがあります。今回も、小規模なバッチ処理に対して40ファイル以上のDDD（ドメイン駆動設計）構成が提示された場面がありました。「この規模であればシンプルな構成で十分」と判断し、方針を修正したのは人間です。AIが高品質な設計パターンを提案できるからこそ、それをプロジェクトの実情に合わせて取捨選択する判断力がより重要になります。 ② コードの修正もAIに任せる AIがミスをしたとき、自分でコードを直したくなります。しかし人間が直接手を加えると、AIが保持するコンテキストと実態に乖離が生じ、以降の提案精度が下がります。人間が修正した場合はその内容をAIに伝えることで乖離を防ぐこともできますが、基本的には修正もAIとの対話を通じて行い、「AIが認識しているコードが正」というルールを徹底することが、AI駆動開発をスムーズに回すための鍵でした。 ③ 意思決定と言語化に集中する開発手法 AIは数分でレビュー結果を反映し、次の成果物を提出してきます。人間はコードを書く代わりに、レビューと意思決定を高速に繰り返します。また、AIは暗黙の前提や文脈を汲み取ることができないため、仕様や意図を正確に言語化する力が求められます。コーディングから解放された分、ビジネス価値の判断と要件の言語化に集中できる点が、AI-DLCの大きな魅力です。 これからの展望 私たちが得た最大の収穫は、AI-DLCが単に時短のための開発手法ではないという点です。開発の密度とフィードバックの速度を高めることで、結果として開発全体が加速される ─ この体験は、従来の効率化とは質の異なるものでした。コードを書く作業はAIに委ね、人間はレビュー・承認に専念する。AIが一般的な設計パターンやベストプラクティスを瞬時に提示するからこそ、自社固有の業務制約や設計判断を見抜く技術力がより重要になります。 当社では今回の成果を踏まえ、AI-DLCのワーキンググループを発足する予定です。サンドボックス環境の整備やAIエージェントを使いこなすためのルール（Steering / Skills）の構築を進め、社内の開発プロセスへの適用を本格的に推進していきます。 （寄稿ここまで） AI-DLC に興味を持たれた方は、 aidlc-workflows（GitHub） をご覧ください。Kiro を使ってAI-DLCを始めるためのワークフローやテンプレートを公開しています。 Unicorn Gym 参加メンバー（日立産業制御ソリューションズ、AWS） 著者 竹地 航太郎 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属。クラウドや生成AIを活用したソフトウエア生産技術の社内展開を担当。AI‑DLC Unicorn Gymへの参加をきっかけに、AI駆動開発を取り入れた社内プロジェクトを推進中。 早川 康平 アマゾン ウェブ サービス ジャパン テクニカルカスタマーソリューションズ マネージャー。金融勘定系システムのPM、Webエンジニア、SaaSプロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、日立グループ専任のCSMとして、SaaSアプリケーション開発やAI活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。

本稿は、日本取引所グループの戦略的なデータ・デジタル事業を担う株式会社 JPX 総研による「 Amazon Quick Sight を活用した JPX 保有データ（J-LAKE）活用推進の取り組み」について、アーキテクティングと開発をリードされた箕輪 郁雄 様、鹿島 裕 様に寄稿いただきました。 イントロダクション JPX 総研 は、市場全体の機能強化および効率化に繋がるマーケット・サービスの創造を追求することを目的に、2022年4月に子会社として事業を開始しました。主に金融商品市場に関係するデータ・インデックスサービス及びシステム関連サービスを提供しています。 JPX 総研では、日本取引所グループのグループ会社及び協業会社（以下「JPX グループ等」）が保有するデータを蓄積するJPX のデータレイク（ J-LAKE ）を構築しました。J-LAKE が社内外から積極的に活用（民主化）されるための取組みとして、社内のデータ活用を推進するために実施した「社内 Amazon Quick Sight ダッシュボードコンペ」の事例についてご紹介します。ブログの中では、J-LAKE 構築、 Amazon Quick Sight 社内ダッシュボードコンペの実施に至った背景や AWS の活用方法についても解説いたします。 J-LAKE 構築の経緯 JPX グループ等では、旧来のオンプレシステムにおいても JPX のデータを集約して貯めておくコンセプトが存在しており、基幹系の各システムからデータを１か所に蓄積するシステムが存在しておりました。ただ、このオンプレシステムに蓄積されていたデータを全社で有効に活用できる仕組みにはなっておらず、ビジネスニーズに合わせて逐次システム改修が必要となり、利用する度に費用が発生し完成まで時間がかかってしまうデメリットが生じておりました。 またデータは蓄積されていましたが、機密度の高いデータとそれ以外のデータが混在しており、社内の各部のユーザが自由に利用できるような環境がなかったため、データが必要となった際は、IT 部署への依頼が必須となってしまっていたため、各部でのデータ活用が進んでいかない状態でした。そのような状況の中、こちらのシステムが老朽化のためリプレース時期を迎えていたこともあり、前述の課題も含め解消すべく、AWS 上にデータレイク(J-LAKE)を構築しました。 J-LAKE 構築にあたっての課題 オンプレミスシステムの老朽化 データ管理上の制約によるユーザの利用困難 ユーザが能動的にデータを使える環境・文化の醸成の必要性 社内でデータの民主化を進め、ユーザが自らデータを活用できる環境や文化を醸成することが求められていました。これにより、データビジネスの加速や新たな価値創出が期待されていました。 J-LAKE 構築にあたってのソリューション データメッシュ構造を取り入れた J-LAKE の構築 AWS 上にデータメッシュ構造を取り入れたデータレイク「J-LAKE」を構築することで、機密性の度合いによるデータの管理を容易にし、柔軟なデータ管理の運用が可能となりました。 Amazon Quick Sightを基軸とした分析環境の提供 J-LAKE 上のデータを活用し、Amazon Quick Sight を中心とした分析環境を整備することで、ユーザが自らデータ分析を行える環境を提供しました。これにより、各部門の業務効率化を可能としました。 DCoE（Data Center of Excellence）の設立 データ活用推進のための専門組織として DCoE を立ち上げ、データの投入から利用におけるガバナンス整備、セキュリティ担保の方法について議論し、その内容を社内で共有していくとともに、J-LAKE の開発・運用にフィードバックを行い DCoE の決定に従いセキュリティ等の仕組みを構築しました。 DCoE ポータルサイトの構築 上記のデータを利用するにあたってのアナウンスや、Amazon Quick Sight の利用方法、J-LAKE データを活用いただくための AI でのデータ検索機能や簡易的なデータ取得環境を提供するポータルサイトを立ち上げました。 社内データ活用の啓蒙活動について 社内でデータを活用できる環境やルールの整備を進めてきましたが、もともとデータ活用の文化が根付いていなかったことから、Amazon Quick Sight の利用が思うように進まない状況が続いていました。そこで、この課題を解決するために、まずは経営層が日常的に利用するデータ可視化の取り組みを開始しました。 従来、役員向けの財務状況の報告は、Excel で作成した資料を元に紙ベースで四半期ごとに実施していましたが、Amazon Quick Sight を活用し、月次で確認できるダッシュボードを構築しました。また、日々 Excel マクロで作成しメール送信していた売上予測についても、いつでもアクセスできるダッシュボードとして再構築しました。 役員向けダッシュボードはシングルサインオン（SSO）を導入することでログインの手間を省き、さらに、売上予測ダッシュボードでは従来の表形式に加え、グラフによるビジュアル化コンテンツを追加することで、より直感的にデータを把握できるよう工夫しました。 これらの取り組みにより、日々 Excel 作業で発生していた作成工数が、ダッシュボード作成の自動化で大幅に削減されました。この部分においても経営層にとって Amazon Quick Sight の導入が効果的であると認知していただけました。 これをきっかけに、役員から「こんなデータが見たい」といった具体的な要望が各部門に寄せられるようになり、必要な情報を早期にダッシュボード化して共有することで、Amazon Quick Sight の価値を社内全体で実感できるようになりました。 経営層が Amazon Quick Sight の有用性を認知したことを受け、役職員のスキルアップや業務への適用が急務となりました。そこで、AWS 様のご協力のもと、社内向け Amazon Quick Sight ハンズオンを実施しました。 まずは、データ活用が今後の JPX のビジネス展開に不可欠であることを説明し、世間や他部署での Amazon Quick Sight 利用ユースケースを紹介しました。その流れで、簡単なグラフ作成などを体験できる初級編ハンズオンを開催し、社員が Amazon Quick Sight を身近に感じられる機会を提供しました。 さらに半年後には、JPX 内での Amazon Quick Sight 最新の利用方法の紹介と、AWS 様より Amazon Quick Sight の便利な利用方法をご紹介いただいたうえで、具体的なインサイトを得られる分析手法を学べる中級編ハンズオンを開催しました。 各ハンズオンの後には懇親会を設け、他部署との交流を深めるとともに、事務局として各部の利用状況の実態を把握する場としても活用しました。 また、ハンズオンや懇親会を通じて得られた各部門のデータ活用状況に合わせて、個別に相談会を実施し、チャットを活用した気軽な質問環境も整備しました。これにより、JPX 内で業務に活用できるダッシュボードの構築が徐々に広がり、Amazon Quick Sight が各部門の業務効率化や意思決定の迅速化に寄与し始めてきました。 Amazon Quick Sight ダッシュボードコンペによる社内データ活用の促進 上記の取り組みにより、社内で Amazon Quick Sight を利用するユーザの広がりや、利用方法の多様化を実感することができました。そこで、社内全体のデータ活用スキル向上と Amazon Quick Sight のさらなる認知拡大を目的として、「Amazon Quick Sight ダッシュボードコンペ」を企画しました。 コンペの募集にあたっては、日常業務で活用されるダッシュボードから、J-LAKE のデータを用いた新たなインサイトを得られるダッシュボードまで、幅広いテーマで募集を行いました。応募されたダッシュボードについては、AWS 様のご協力のもと相談会を実施し、参加者がダッシュボードを磨き上げる機会を設けることで、より質の高いアウトプットを目指しました。 コンペのプレゼン大会当日は、CEO を含む役員および AWS 様にも審査員としてご参加いただき、各ダッシュボードに対して多くのコメントやフィードバックが寄せられました。時間が足りなくなるほどの大盛況となり、社内のデータ活用に対する熱意や関心の高さを改めて感じるイベントとなりました。 このイベントを通じて、以下のような新たな気づきや成果が得られました。 コンペ実施まで Amazon Quick Sight をほとんど触ったことがないユーザでも、約1か月の作成期間の中で、自部署の業務と並行しながらダッシュボードを構築することができました。これにより、Amazon Quick Sight の操作性や学習のしやすさを実感する機会となりました。 各部門には、J-LAKE に格納されていない多様なデータが存在していることが明らかになり、今後のデータ活用の可能性が広がることを認識しました。 経営層が求めるデータや視点を理解する良い機会となり、現場と経営層のコミュニケーションの促進や、より価値の高いダッシュボードの構築につながると感じました。 今後の展望 これまでの活動を通じて、JPX グループ内でのデータ活用が各部門で徐々に広がり始めていることを実感しています。一方で、まだまだ活用の余地が大きいと感じており、 Amazon Quick に AI 機能が搭載されたことで、今後さらに活用の幅が広がっていくと期待しています。 今後も継続的に社内のデータ活用を推進するため、各部門が保有するデータを J-LAKE に集約し、Amazon Quick の新機能を紹介するハンズオンを実施することで、今回あまり参加いただけなかった部署にも積極的にアプローチしていきたいと考えています。 また、J-LAKE のデータを社外に単純に販売するだけでなく、Amazon Quick を活用した新たなデータサービスの開発にも取り組み、JPX グループ全体のデータ価値の最大化を目指してまいります。 JPX では今後も AWS のサービスを活用し、データドリブンな業務改革とイノベーションを推進していきます。Amazon Quick を中心としたデータ活用の取り組みをさらに拡大し、社員一人ひとりがデータを活用した価値創造に貢献できる環境づくりを目指してまいります。 執筆者 日本取引所グループ・株式会社 JPX 総研　IT ビジネス部　シニアアーキテクト 箕輪　郁雄 大学卒業後、パッケージ開発 IT ベンダーにてプログラマ、DBA 、PM を経験の後、当時の東京証券取引所に入社。ERP パッケージの導入や基幹系システムの新規立ち上げから構築などを担当したのち、現在のデータを活用したシステムの立ち上げ・開発を担当。 日本取引所グループ・株式会社 JPX 総研　IT ビジネス部　統括課長 鹿島　裕 大学卒業後、当時の東京証券取引所に入社。株式売買システムの開発を経験の後、2013年より社内 DWH システム担当として組織統合におけるデータの集約・一元管理に取り組む。データレイク構築に携わったのち、データ活用に関する企画・開発を担当。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 ゴールデンウィークも終わり、今週から本格始動という方も多いのではないでしょうか。みなさんはどんな連休を過ごされましたか。私は家の中でのんびり過ごしていました。 さて、5月26日(火) 14:00〜17:30 には、日本では 2 回目の開催となる「Amazon EKS でスケーリングする生成 AI 環境を構築するハンズオンワークショップ」をオンラインで開催します。NVIDIA GPU を活用した本番環境レベルの生成 AI 環境を、Karpenter による柔軟なオートスケーリング、vLLM や Ray を用いた推論基盤の構築など、実践形式で体験いただける内容です。すでに Kubernetes 基盤をお持ちの方や、Self-managed な生成 AI 環境を検討されたい方に特におすすめですので、ご興味のある方は こちら から参加登録いただければと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年5月4日週の主要なアップデート 5/4(月) Amazon Quick が Microsoft Outlook 拡張機能をアップグレード (プレビュー版) AWS は Amazon Quick の Microsoft Outlook 拡張機能のアップグレードバージョンをプレビュー版として発表しました。この拡張機能により、生成 AI を活用した生産性向上機能を Outlook のメールとカレンダーワークフローに直接統合できます。自然言語で未読メールの要約、受信トレイの整理、会議のスケジュール、インライン返信の作成が可能になり、Outlook を離れることなく業務を完結できます。現在、US East (N. Virginia)、US West (Oregon)、Asia Pacific (Sydney)、Europe (Ireland)、Asia Pacific (Tokyo)、Europe (Frankfurt)、Europe (London) の 7 リージョンでプレビュー提供されています。詳細は こちらのドキュメント をご参照ください。 Amazon Quick が S3 Tables buckets をデータソースとしてサポート Amazon Quick が Amazon S3 table buckets を新しいデータソースとして正式にサポートしました。これにより、中間的なデータウェアハウスや OLAP レイヤーを経由せず、S3 table buckets に保存された Apache Iceberg 形式のテーブルに対して直接ダッシュボードの作成、会話型分析、データ探索が可能になります。Salesforce、SAP、Amazon Kinesis Data Firehose からの Zero-ETL 統合と組み合わせることで、パイプライン依存を最小限に抑えながら、ほぼリアルタイムでインサイトを取得できます。この機能は Amazon Quick が利用可能な全 AWS リージョンで提供されます。詳細は こちらの Blog 記事 をご参照ください。 Amazon Quick が Dataset Q&A を導入し、エンタープライズデータに対する会話型分析を実現 Amazon Quick は、エンタープライズデータに対して自然言語で質問できる新機能「Dataset Q&A」を一般提供開始しました。この機能により、データセットへのアクセス権を持つユーザーは、ダッシュボードを介さずに直接データセットを自然言語で探索し、Row Level Security (RLS) や Column Level Security (CLS) などのガバナンスルールを尊重しながら実用的なインサイトを取得できます。Text-to-SQL エージェントが質問を解釈し、適切なデータを特定して正確な SQL を生成します。Dataset Q&A は Amazon Quick が利用可能な全ての AWS リージョンで利用できます。詳細は こちらの Blog 記事 をご参照ください。 Amazon Quick が自然言語プロンプトからダッシュボードを生成 Amazon Quick に Generate Analysis 機能が追加され、自然言語プロンプトからダッシュボードを自動生成できるようになりました。最大 3 つのデータセットを選択し、作成したいダッシュボードを説明するだけで、適切なビジュアライゼーション、フィルターコントロール、前年比や前月比などの計算フィールドを含む整理されたダッシュボードが数分で生成されます。Enterprise サブスクリプション/Author Pro ユーザーが対象です。Amazon Quick が利用可能な全 AWS リージョンで一般提供 (GA) を開始しました。詳細は こちらの Blog 記事 をご参照ください。 5/5(火) AWS IAM でロール、ロール信頼ポリシー、インスタンスプロファイル、マネージドポリシー、ID プロバイダーの最大クォータを引き上げ AWS Identity and Access Management (IAM) は、6 つのリソースの最大クォータを引き上げました。カスタマーマネージドポリシー (5,000 → 10,000)、インスタンスプロファイル (5,000 → 10,000)、ロールあたりのマネージドポリシー (20 → 25)、ロール信頼ポリシーの長さ (4,096 → 8,192 文字)、ロール数 (5,000 → 10,000)、OpenID Connect プロバイダー (100 → 700) が対象です。大規模な AWS 環境における制約を緩和し、より多くのワークロードに対応できるようになりました。詳細は こちらのドキュメント をご参照ください。 Amazon Quick が New Relic との統合でオブザーバビリティ駆動型 AI エージェントに対応 Amazon Quick が New Relic の AI エージェントと統合し、オンコールエンジニアや SRE が Quick のワークスペースから離れることなく、インシデント調査、根本原因分析 (RCA)、タスク作成を実行できるようになりました。New Relic の MCP (Model Context Protocol) サーバーに接続することで、アラートインサイト、ユーザー影響分析、ログ解析、トランザクション診断、NRQL クエリなどのアクションを自然言語で呼び出せます。Quick Flows との組み合わせにより、定期的なトリアージランブックやエスカレーションワークフローの自動化も可能です。詳細は こちらのドキュメント をご参照ください。 Amazon WorkSpaces が AI エージェントによるデスクトップアプリケーションの操作に対応 (プレビュー) Amazon WorkSpaces は、AI エージェントがマネージド WorkSpaces 環境を通じてデスクトップアプリケーションに安全にアクセスし、操作できる機能をプレビューで提供開始しました。Model Context Protocol (MCP) を使用して、あらゆるフレームワークで構築された AI エージェントが、API を持たないレガシーアプリケーション (メインフレーム、ERP、プロプライエタリツール) を最小限のコードで操作できます。企業は、アプリケーションをモダナイズせずとも、保険金請求処理や取引決済などの業務を大規模に自動化できます。詳細は こちらの Blog 記事 をご参照ください。 Amazon ElastiCache で Valkey 9.0 を発表 Amazon ElastiCache が Valkey 9.0 をサポート開始しました。フルテキスト検索とハイブリッド検索機能が組み込まれ、パイプライン処理のスループットが最大 40% 向上します。ハッシュフィールド単位の有効期限設定や、クラスタモードでのマルチデータベースサポートにより、データライフサイクル管理とマルチテナントアーキテクチャが簡素化されます。全ての商用 AWS リージョン、AWS GovCloud (US) リージョン、中国リージョンで、ノードベースクラスタとサーバーレスキャッシュの両方で追加コストなしで利用できます。詳細は こちらの Blog 記事 をご参照ください。 5/6(水) Agent Toolkit for AWS を発表 — AI コーディングエージェントが AWS 上で効果的に構築できるよう支援 AWS は、AI コーディングエージェントが AWS 上で正確に構築できるよう支援する本番対応のツールセット「Agent Toolkit for AWS」をリリースしました。このツールキットは、エージェントスキル、フルマネージド MCP サーバー、プラグインの 3 つのコンポーネントで構成され、エラー削減、トークンコスト低減、エンタープライズグレードのセキュリティ制御を実現します。40 以上のスキルが提供され、追加料金は不要で、エージェントが使用した AWS リソース分のみの課金となります。詳細は こちらのドキュメント をご参照ください。 AWS MCP Server の一般提供開始 AI コーディングエージェントに対して、AWS サービスへの安全かつ監査可能なアクセスを提供する AWS MCP Server を一般提供 (GA) しました。re:Invent 2025 でのプレビュー公開以降、複数の機能強化を経ての GA となります。AWS MCP Server は Agent Toolkit for AWS の中核コンポーネントで、Model Context Protocol (MCP) を通じて AI エージェントが AWS サービスと連携します。組織は IAM ベースのガードレール、Amazon CloudWatch メトリクス、AWS CloudTrail ログにより、可視性とコントロールを維持しながら AI エージェントに AWS サービスを操作させることができます。詳細は こちらのページ をご参照ください。 Amazon Bedrock AgentCore Runtime が Amazon S3 Files と Amazon EFS からの Bring-Your-Own ファイルシステムをサポート Amazon Bedrock AgentCore Runtime が、お客様の Amazon S3 Files および Amazon EFS アクセスポイントを直接エージェントランタイムにアタッチできる Bring-Your-Own ファイルシステム機能をサポートしました。AgentCore Runtime がファイルシステムを指定パスにマウントすることで、エージェントは標準的なファイル操作でデータの読み書きを実行できます。カスタムマウントコード、特権コンテナ、ダウンロードオーケストレーションは不要です。この機能により、スキル、ツールライブラリ、リファレンスデータセット、ナレッジベース、プロジェクトファイルをセッション間や複数エージェント間で共有できるようになります。詳細は こちらのドキュメント をご参照ください。 5/7(木) Amazon OpenSearch Service が VPC プライベート接続のための VPC egress オプションをサポート Amazon OpenSearch Service は VPC egress オプションのサポートを開始しました。この機能により、VPC 内の OpenSearch Service ドメインから ML モデル、AWS サービス、カスタムアプリケーションへの送信トラフィックを、パブリックインターネットを経由せずにプライベートに接続できるようになります。OpenSearch Service は選択したサブネットにネットワークインターフェースを追加し、送信トラフィックを VPC にルーティングします。すべての AWS リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore に Payments 機能を追加（プレビュー） AWS は、AI エージェントが Web コンテンツ、API、MCP サーバー、他のエージェントに対して自律的にアクセスし支払いを行える Amazon Bedrock AgentCore payments(プレビュー)を発表しました。Coinbase および Stripe との協業により構築された、自律エージェント向け初のマネージド決済機能で、ウォレット認証からトランザクション実行、支出ガバナンス、可観測性までを一貫して管理します。エンドユーザーによる明示的な認可と、AgentCore のインフラ層で強制されるセッションごとの支出上限により、エージェントは定められた範囲内でのみ支払いを実行できます。US East (N. Virginia)、US West (Oregon)、Europe (Frankfurt)、Asia Pacific (Sydney) の4リージョンで利用可能です。詳細は こちらの Blog 記事 をご参照ください。 Amazon EC2 M8idn および M8idb インスタンスを発表 AWS は Amazon EC2 M8idn および M8idb インスタンスの一般提供を開始しました。これらのインスタンスは、AWS 専用の第6世代 Intel Xeon Scalable プロセッサと第6世代 AWS Nitro カードを搭載しています。前世代 M6idn インスタンスと比較して、vCPU あたり最大 43% の計算性能向上を実現します。M8idn は最大 600 Gbps のネットワーク帯域幅を提供し、M8idb は最大 300 Gbps の EBS 帯域幅を提供します。米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (スペイン) の 3 リージョンで利用できます。詳細は こちらのページ をご参照ください。 5/8(金) Amazon Route 53 Global Resolver でanycast DNS 解決のための AWS リージョンの追加と削除が可能に Amazon Route 53 Global Resolver で、anycast DNS 解決を行う AWS リージョンを動的に追加・削除できるようになりました。この機能により、組織の成長に合わせて Global Resolver のカバレッジを拡大したり、コンプライアンス要件に応じてリージョン展開を調整したりできます。Global Resolver の設定を再作成する必要がなくなり、既存の設定を維持したままリージョン構成を変更できます。この機能は追加料金なしで、Route 53 Global Resolver がサポートされているすべての AWS リージョンで利用できます。詳細は こちらの Blog 記事 をご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 GW で連休をとられた方はリフレッシュできましたでしょうか。私はのんびり過ごしていたのですが、その間にも生成 AI 関連のサービスアップデートは止まることを知らず…。今週も盛りだくさんでお届けします！ 5 月 4 日週の個人的な注目アップデートは、「Kiro の Claude Opus 4.7 での適応的思考（Adaptive Thinking）」「Kiro Web のプレビュー版」「Amazon Bedrock AgentCore Runtime が Amazon S3 Files および Amazon EFS によるユーザー所有ファイルシステムの利用をサポート」です。ぜひ下記の記事をご覧ください！ 5 月 28 日には「 第7回　AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ 」というイベントが開催されます。生成 AI の最新トレンド紹介や参加者間での情報交換を目的としたイベントですのでぜひご参加ください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、5 月 4 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「KDDI が実践する AWS DevOps Agent 活用：AWS サポートと連携したインシデント対応の効率化」を公開 KDDI 株式会社様が、au PAY や Ponta ポイントなどを支えるサーバーレス基盤のインシデント対応に AWS DevOps Agent を導入し、対応リードタイムを「数週間」から「数日」へ短縮した事例を紹介しています。AWS Lambda と Amazon RDS Proxy にまたがる複雑な事象に対し、DevOps Agent を「答え合わせのパートナー」と位置づけ、運用チーム・AWS サポートと協働した実践的なアプローチが特徴です。「AI に答えを出させるのではなく、AI と一緒に問いを立てる」という活用思想は、運用・SRE チームの方に是非参考にしていただきたい内容です。 ブログ記事「Kiro Agent で SAP Clean Core ジャーニーを加速する」を公開 SAP システムのカスタムコードの評価・修正作業を自動化する、GitHub でオープンソース公開された Kiro エージェントを紹介しています。ABAP Test Cockpit (ATC) と統合し、未使用コードの排除や修正ガイダンスを提供することで、数週間かかっていたアセスメントを数時間に短縮できます。コスト最適化の考え方や、すぐに試せるステップバイステップの導入手順も解説されていますので、SAP モダナイゼーションをご検討中の方はぜひご覧ください。 ブログ記事「AWS For SAP Management MCP Server の発表 – SAP アプリケーションを AI で管理」を公開 AWS 上の SAP 環境を AI アシスタントとの自然言語の会話で管理できる MCP サーバーが新たに公開されました。モニタリング、コンプライアンスチェック、ライフサイクル管理（起動・停止）、EventBridge Scheduler を用いたスケジュール運用の 4 領域に対応しており、従来は複数のコンソールや 10 以上の API 呼び出しが必要だった操作を一つのインターフェースに統合します。記事内に 6 つのプロンプト例があるので是非試してみてください。 ブログ記事「AWS SDK for SAP ABAP ドキュメントでエージェント型 IDE を拡張する」を公開 AWS SDK for SAP ABAP Knowledge MCP Server の一般提供開始に伴い、Amazon Q Developer for Eclipse や Kiro などのエージェント型 IDE が公式 SDK ドキュメントを参照しながら ABAP 開発を支援できるようになりました。認証不要の HTTPS エンドポイントとして提供され、URL 設定のみで利用可能で、毎日更新される 13万 ページ超のドキュメントライブラリにアクセスできます。Amazon Bedrock や Amazon Textract を活用するサンプルプロンプトも紹介されているので、ABAP 開発者の方は是非お試しください。 ブログ記事「Build with Kiro: コミュニティハブと Kiro Labs のご紹介」を公開 Kiro を利用する開発者向けのプラットフォームとして「Kiro コミュニティハブ」と「Kiro Labs」が新たに公開されました。コミュニティハブはプロジェクトの発見やリソース共有、開発者同士の交流のための拠点となり、Kiro Labs では Amazon 社員によるオープンソースプロジェクト（チーム全体で Kiro 設定を同期する CLI「dotkiro」など）が公開されています。Discord や公式オフィスアワー、ハッカソンなどの情報もまとめられているので、Kiro で開発されている方はぜひご参加ください。 サービスアップデート Amazon Quick Amazon Quick が S3 テーブルバケットへの直接クエリをサポート Amazon Quick で S3 テーブルバケットをデータソースとして直接利用できるようになりました。これまで S3 上の Apache Iceberg テーブルを分析するにはデータウェアハウスなどの中間層が必要でしたが、今回のアップデートによりレイクハウス上のデータをそのままダッシュボードや会話型分析で活用できます。Amazon Quick が利用可能なすべてのAWS リージョンで提供されます。 Amazon Quick がデータセット Q&A による会話型分析を提供開始 Amazon Quick に「データセット Q&A」機能が追加され、エンタープライズデータに自然言語で直接質問できる会話型分析が可能になりました。Text-to-SQL エージェントが SPICE や Amazon Redshift、Amazon Athena などに最適化された SQL を生成し、行・列レベルのセキュリティを保ったまま探索できます。Amazon Quick が提供されているすべての AWS リージョンで利用可能です。 Amazon Quick が自然言語プロンプトからの分析生成をサポート Amazon Quick で自然言語プロンプトから分析を生成できる機能が追加されました。「収益トレンドを含む販売ダッシュボードを作成して」と入力するだけで、最大 3 つのデータセットを組み合わせたダッシュボードを自動生成し、従来は数時間かかっていた構築作業がわずか数分に短縮されます。Amazon Quick が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon Quick for Microsoft Outlook 拡張機能がプレビュー提供開始 Amazon Quick の Microsoft Outlook 向け拡張機能がプレビュー版として登場しました。生成 AI による未読メッセージの要約、受信トレイ整理、会話形式での会議スケジュール調整、インラインでの返信下書き作成などをメールやカレンダーのワークフロー内で直接利用できます。米国東部 (バージニア北部)、アジアパシフィック (東京)など複数リージョンで提供されます。 Amazon Quick が New Relic AI エージェントとの統合を発表 Amazon Quick が New Relic の AI エージェントと統合され、オンコールエンジニアや SRE のインシデント調査を効率化できるようになりました。リモート MCP サーバー経由で New Relic のアラートやログ分析にアクセスし、エビデンスリンク付きの RCA ドキュメントを自動生成できます。Amazon Quick が利用可能なすべての AWS リージョンで利用できます。 Kiro Kiro の Claude Opus 4.7 での適応的思考が利用可能に Kiro IDE および CLI で Anthropic 社の Claude Opus 4.7 が利用可能になりました。タスクの難易度に応じて推論時間を自動調整する「適応的思考（Adaptive Thinking）」機能を備え、複雑な問題には時間をかけ、シンプルな問題には迅速に対応します。Pro、Pro+、Power サブスクライバーおよび IAM Identity Center ユーザーが対象で、Kiro IDE 0.11.133 以上、CLI 2.2.0 以上での利用が推奨されます。 Kiro Web のプレビュー版が提供開始 Kiro のブラウザ版「Kiro Web」のプレビューが app.kiro.dev で公開されました。ユーザー主導でエージェントと共同作業する「協調型」と、質問・計画・実行・PR 作成までを独立して進める「自律型」の 2 つのモードを備えます。GitHub イシューの kiro ラベルや /kiro コメントから自動割り当てが可能で、.kiro/steering/ でのチーム標準の継続適用や、各タスクを独立環境で実行する隔離サンドボックスにも対応します。Pro 以上のユーザーが利用できます。 Kiro IDE 0.12 が並列タスク実行とクイックプランをサポート Kiro IDE バージョン 0.12.155 がリリースされ、Kiro Specs の起動・完了時間と要件定義の精度が向上しました。依存関係を分析して独立タスクを同時実行する「並列タスク実行」では最大 4 倍の時短が可能となり、要件・設計・タスクを単一パスで生成する「クイックプラン」、論理矛盾や曖昧さ・制約衝突を自動検出する「要件分析機能」も追加されています。 Amazon Bedrock AgentCore Amazon Bedrock AgentCore Memory が長期メモリにメタデータをサポート Amazon Bedrock AgentCore Memory の長期メモリレコードでメタデータがサポートされました。タグ付けやフィルタリング、構造化属性での検索を意味論的検索と組み合わせて利用でき、メモリリソースあたり最大 10 個のインデックス化キーを定義できます。不要なコンテキストを排除して応答精度を向上できます。 Amazon Bedrock AgentCore Payments がプレビュー提供開始 Amazon Bedrock AgentCore に AI エージェント向けの統合支払いプラットフォーム「AgentCore Payments」が追加されました。Coinbase、Stripe とのパートナーシップで構築され、API や MCP サーバーへの自律的な支払いが可能で、HTTP 402 応答からの x402 プロトコル交渉・決済・証明配信を自動処理します。米国東部 (バージニア北部) など 4 リージョンで利用できます。 Amazon Bedrock AgentCore Runtime が Amazon S3 Files および Amazon EFS によるユーザー所有ファイルシステムの利用をサポート Amazon Bedrock AgentCore Runtime で、Amazon S3 Files または Amazon EFS のアクセスポイントをエージェントランタイムに直接接続できるようになりました。ファイルシステムはセッションパスに自動マウントされ、長時間ワークフローでの中間結果の永続化や複数エージェント間でのデータ共有に対応します。東京リージョン含む 15 の AWS リージョンで提供されています。 Amazon SageMaker HyperPod / SageMaker AI Amazon SageMaker AI が モデルのカスタマイズに関する AI エージェントエクスペリエンスを発表 Amazon SageMaker AI に、モデルカスタマイズを数か月から数日・数時間に短縮する AI エージェントエクスペリエンスが導入されました。自然言語でコーディングエージェントと対話しながら、ユースケース定義から本番デプロイまでを一気通貫で進められます。米国東部 (バージニア北部)、アジアパシフィック (東京) などで利用できます。 Amazon SageMaker AI でインスタンスの自動フォールバックによる容量を考慮した推論のサポートを開始 Amazon SageMaker AI の推論エンドポイントが、優先順位付けされたインスタンスタイプリストに基づく柔軟なプロビジョニングに対応しました。優先度の高いインスタンスで容量不足が発生すると自動的に次のインスタンスへフォールバックし、手動介入なしにエンドポイントの作成・更新・自動スケーリングを継続できます。東京リージョン含む 16 リージョンで利用可能です。 Qwen の新モデル 4 種類が Amazon SageMaker JumpStart で利用可能に Amazon SageMaker JumpStart で 4 つの新しい Qwen モデルが利用可能になりました。最大 100 万トークン対応の「Qwen3.5-27B-FP8」、MoE 方式の「Qwen3.6-35B-A3B」、エッジ向け「Qwen3.5-0.8B」、軽量マルチモーダル「Qwen3.5-2B」と用途別に選択でき、Amazon SageMaker Studio から数クリックでデプロイ可能です。 Amazon SageMaker HyperPod が Slurm クラスター向けの AMI ベースのノードライフサイクル設定をサポート Amazon SageMaker HyperPod の Slurm クラスターノードのプロビジョニングで、AMI ベースの設定がサポートされました。事前構成済み AMI の利用によりライフサイクルスクリプトの実行が削減され、クラスター作成時間が大幅に短縮されます。SageMaker HyperPod が利用可能なすべての AWS リージョンで提供されます。 Amazon EC2 P6-B300 インスタンスが米国東部 (バージニア北部) で利用可能に Amazon EC2 P6-B300 インスタンスが米国東部 (バージニア北部) でも利用可能になりました。NVIDIA Blackwell Ultra GPU を 8 基、GPU メモリ 2.1 TB を備え、先代の P6-B200 と比較してネットワーク帯域幅が 2 倍、GPU メモリと FP4 演算性能が 1.5 倍に向上しています。提供サイズは p6-b300.48xlarge のみです。 MCP サーバー / Tools / その他 AWS for SAP MCP サーバーが Amazon Bedrock AgentCore で一般提供開始 Amazon Bedrock AgentCore 上の AWS for SAP MCP サーバーが一般提供を開始しました。AI エージェントを SAP ERP に安全に直接接続でき、販売注文や購買発注などの SAP ビジネスオブジェクトの作成・読取・更新・削除に対応します。SAP S/4 HANA と SAP ECC の両方をサポートし、CloudFormation テンプレートで数分でデプロイ可能です。 Agent Toolkit for AWS が一般提供を開始 AI コーディングエージェントが AWS 上で本番品質のソリューションを構築するための「Agent Toolkit for AWS」が一般提供を開始しました。40 以上のエージェントスキル、フルマネージドの AWS MCP サーバー、3 種類のプラグインで構成され、IAM ベースのガードレールや CloudWatch / CloudTrail での可視化を提供します。米国東部 (バージニア北部) と欧州 (フランクフルト) で利用可能です。 AWS MCP サーバーが一般提供を開始 AI コーディングエージェントに AWS サービスへの安全で監査可能なアクセスを提供する「AWS MCP サーバー」が一般提供を開始しました。Agent Toolkit for AWS の中核として、IAM ベースのガードレールや CloudWatch / CloudTrail による監査、サンドボックス型 Python 実行環境などを備えます。米国東部 (バージニア北部) と欧州 (フランクフルト) で利用可能で、追加料金は発生しません。 Amazon WorkSpaces が AI エージェントによるデスクトップ操作をサポート Amazon WorkSpaces が AI エージェントによるデスクトップアプリケーションの操作に対応しました。任意のフレームワークで構築されたエージェントを MCP 経由で業務アプリに接続でき、モダンな API を持たないメインフレームや ERP などの「ラストマイル課題」を解消し、クレーム処理や決済などの自動化に活用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本ブログは ヤマトプロテック株式会社 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWSアカウントマネージャーの古山です。 「AI 化を検討したいが、情報システム部門のリソースが足りない」——そんな課題を抱える企業は少なくありません。本記事では、急な欠員により書類保管業務が逼迫した状況から、 Amazon Bedrock と Kiro を活用してわずか 2 日間でマルチモーダル AI を利用した書類電子保管システムを構築し、85% 以上の業務効率化を実現したヤマトプロテック株式会社様(以下、ヤマトプロテック様）の事例を紹介します。情シスリソースが限られた環境でも、適切な生成 AI 開発ツールの選択と活用方法によって、短期間での課題解決が可能であることを示す実践的な事例です。 多くの企業が直面する：手作業による書類保管業務の逼迫 ヤマトプロテック様は 1918 年創業以来、消火・防災領域におけるメーカーとして、開発・製造・設計・施工・メンテナンスを網羅し「火にまつわる安心」を作り出してきました。同社において、デジタルトランスフォーメーション（DX）は、これからも安心を届け続けるための重要な課題の一つとして、取り組みを進めていたなか、受発注に関連する部署にて、書類の電子保管担当者に急な欠員が発生しました。他の担当者がカバーせざるを得ない状況となり、部署全体の負荷増大と業務時間の延長という事態に陥りました。具体的な業務フローは以下の通りでした。 1. 紙で届いた書類をスキャンして電子化、または電子で届いた書類をダウンロード 2. 書類を目視で確認しながらフォームに手入力 3. フォームに PDF をアップロードして送信 書類 1 枚あたり 1 分から最大 3 分程度を要する単純作業であり、自動化の余地は明らかでした。AI-OCR などによる自動化は以前から検討していたものの、情報システム室が他のシステム開発やプロジェクトで逼迫しており、対応できていませんでした。 なぜ AWS・Kiro を選んだのか：生成 AI 開発ツールの選定理由 ヤマトプロテック 経営企画本部 情報システム室 土屋 俊貴 様は、以前より生成 AI を活用した簡易ツール開発を試みていましたが、書類電子保管業務における問題を解決するためプロジェクトの合間を利用して、開発に本格的に着手しました。最初は他の AI コーディングツールで開発を進め、要件定義とシステムの基礎設計を進めていました。しかし、以下の問題により開発が行き詰まりました。 – コンソールから PowerShell や AWS CLI の操作が正常に実行できない – 設計やインフラへの考慮が不十分なまま開発が進み、終わりが見えない 情報システム室の開発 PC の切り替えというタイミングも重なったため、新しい環境構築と合わせて AI 周りも新しいツールに切り替えることにした際に、土屋様ご自身がAWS re:Invent 2025 に現地参加して体験した Kiro を想起し、「Kiro なら AWS インフラストラクチャーとベストプラクティスに合わせて開発できるのでは？」という期待から Kiro Pro を契約し、途中まで作成したプログラムや要件定義を Kiro に渡してバイブコーディングを開始しました。 ブレークスルーへの道：AI が AI を強化するという発見 Kiro は当初のツールより速いものの、当初は期待したほどの開発速度が出ませんでした。そこで土屋様は、AWS re:Invent でAWSのソリューションアーキテクトから「Steering が大切」と聞いていたことを思い出し、Kiro 自身に Steering の仕組みを尋ねてみました。Kiro の Steering とは、プロジェクト固有のルールや前提知識を AI に常時・条件付きで共有する仕組みです。 .kiro/steering/ 配下の Markdown ファイルとして管理され、チームの開発標準、プロジェクト固有の設計・制約、ビルドやテストの実行手順などを定義できます。「AI 自身に AI のベストプラクティスを調べさせ、自分の Steering を最適化させる」というアプローチを試みました。Kiro は AWS のリファレンスや公式ブログ、各種技術ブログ、re:Invent のレポートを読み込みながら、自らの Steering を作成・適用しました。さらに Kiro は MCP（Model Context Protocol）と Powers の導入を提案し、環境構築を進めました。 – Steering の設定 – Powers の設定 – MCP（Model Context Protocol）のセットアップ AI が AI 自身のアーキテクチャを理解し、最適化を提案・実行するというアプローチにより、開発効率が向上しました。 ソリューションの概要 新たに構築したシステムは、PDF 書類の受け取りから電子保管システムへの自動登録までを完全自動化するものです。Amazon Bedrock のマルチモーダル機能を活用した AI-OCR により、日本語書類の高精度な認識を実現しています。 システムフロー — PDF 書類（Amazon S3） ↓ AWS Lambda 関数起動 ↓ Amazon Bedrock（Amazon Nova Lite）で AI-OCR 処理 ↓ 書類情報の抽出（金額、日付、会社名などの必要情報をパラメーター化） ↓ invoiceAgent 文書管理 API 経由で自動登録 — 仕様駆動開発 SPEC が生み出したシステム構成 Kiro がシステム要件を整理する中で「SPEC モードで進めた方が良い」と提案しました。SPEC モードは Requirements（要件定義）、Design（設計）、Task（作業）の 3 段階で順に進める仕様駆動開発のアプローチです。Kiro は要件を分析し、以下の AWS サービス構成を提案・構築しました。 サービス 役割 Kiro の選定理由 AWS Lambda API 処理 サーバーレスで運用コストが低く、VPC 内配置が可能 Amazon API Gateway （Private） エンドポイント VPC エンドポイント制限でセキュアな通信を実現 AWS Secrets Manager 認証情報管理 API キーやパスワードをコードに記述せずに管理 VPC エンドポイント プライベート通信 NAT Gateway 不要でコスト削減 Amazon S3 書類 PDF の保管 高耐久性・低コストのオブジェクトストレージ Amazon Bedrock （Amazon Nova Lite） AI-OCR による書類認識 日本語書類の高精度認識 OCR 技術の選定と切り替え 当初は Amazon Textract を利用していましたが、日本語書類に対する認識率が約 50% と実用に耐えない水準でした。Kiro の提案により Amazon Bedrock の Amazon Nova Lite マルチモーダルへ切り替えたところ、認識率が約 89% に向上しました。 技術 認識率 評価 Amazon Textract 約 50% 日本語書類には不十分 Amazon Bedrock（Amazon Nova Lite） 約 89% 実用レベルに到達 Kiro が自動生成したディレクトリ構造 iA-API-ServerPJ/src/ ├── lambda_function.py # エントリーポイント ├── auth/api_key.py # API キー認証 ├── validation/models.py # Pydantic バリデーション ├── ia_client/client.py # iA API クライアント ├── handlers/search.py # 検索ハンドラー ├── handlers/document.py # 文書詳細ハンドラー ├── errors/handler.py # エラーハンドリング ├── rate_limit/limiter.py # レート制限 └── audit_log/logger.py # 監査ログ Kiro はデプロイ用の Python スクリプトを 70 個以上作成し、自動デプロイを実現しました。また、37 個のユニットテストを作成し、全て通過しています。タイムアウト問題が発生した際も、Kiro が Amazon CloudWatch ログを分析して原因を特定し、接続プールの拡張とリトライロジックの追加を提案・実装しました。 最適化項目 変更前 変更後 接続プール 10 接続 60 接続 リトライ なし 3 回（1 秒 / 2 秒 / 4 秒） タイムアウト 30 秒一律 接続 10 秒 / 読取 45 秒 2 日間で実現した導入効果：85% 以上の業務効率化 ヤマトプロテック様は、Kiroを活用した書類電子保管システムの構築により、以下の効果を実現しました。 定量的な改善 – 開発期間：2 日間 – AI-OCR 認識率：89%（Amazon Textract 比で約 39 ポイント向上） – 自動化範囲：書類の読み取りから登録まで完全自動化 – 工数削減：手作業による入力作業を 85% 以上削減 定性的な改善 – 急な欠員による業務逼迫の解消 – 他担当者への業務負荷の軽減 – 情報システム部門のリソースを他のプロジェクトへ集中できる環境の整備 – 単純作業からの解放による担当者の業務品質向上 ヤマトプロテック 土屋様からのコメント 「AI のことは AI が一番わかっている。MCP、Powers、Steering などのベストプラクティスを適用することで、開発効率が向上した。AI に AI のプロンプトを書かせるのがベスト。」 「特に AWS との統合が必要な場合、Kiro のような AWS に特化したツールがオススメ。AI 関連は新技術が速い速度で出てくるので、使い慣れているからといって他のツールを使わないのは機会損失。まずは触ってみましょう。」 事業成長への転換点：今後の展開 書類電子保管システムの構築をきっかけに、ヤマトプロテック様の生成 AI 活用は広がりを見せています。 – invoiceAgent 文書管理 API の MCP 化による AI エージェントとの連携強化 – Dify チャットボットと連携した AI-OCR 書類の AI 検索機能の開発 – AWS インフラの継続的な最適化 – Salesforce や ERP システムの DB 解析を Kiro で実施する仕組みの構築 – プロジェクト管理ツールの API を Kiro 向け MCP に再編し、Kiro 自体を PMO として活用 さらに、MCP 化と AI エージェントのコンテナ化によるエージェンティックネットワークの構築により、従来型のデータウェアハウスと BI ツールを代替できる可能性も検討されています。Amazon Bedrock や Kiro などの生成 AI 開発ツールの詳細については、以下のリソースをご参照ください。 – Amazon Bedrock 製品ページ – Amazon Bedrock ドキュメント – AWS Lambda 製品ページ まとめ ヤマトプロテック様の事例は、情報システム部門のリソースが限られた環境でも、生成 AI 開発ツールを適切に活用することで短期間での課題解決が可能であることを示しています。本事例から得られた主な知見は以下の通りです。 1. 適切なツールの選択と更新：AWS との統合が必要な場合、AWS に特化したツールの選択が開発効率を左右します 2. AI の事は AI が一番わかっている：MCP、Powers、Steering などのベストプラクティスを AI 自身に調べさせ適用することで、開発効率が向上します 3. OCR とマルチモーダルの適切な選定：日本語処理においては、一般的な OCR より Amazon Bedrock のマルチモーダルモデルの活用が有効です 4. 迅速なプロトタイピング：生成 AI 開発ツールを活用することで、従来数週間かかっていた開発を数日で完了できる可能性があります 生成 AI を活用した業務効率化にご興味のある方は、ぜひ AWSにご相談ください。 ヤマトプロテック株式会社 : 土屋 俊貴様（中央） アマゾン ウェブ サービス ジャパン合同会社 : アカウントマネージャー 古山 玄弥（左）、ソリューションアーキテクト 大松 宏之（右）

私はこれまで長きにわたって AI エージェントと MCP ツールを利用して構築してきましたが、常に 1 つの疑問が頭にありました。それは、全権限を渡さないようにしつつ、実際に使える、AWS に対する認証済みアクセスをエージェントに付与するにはどうすればよいか、ということです。 2026 年 5 月 6 日、その答えが明らかになりました。 AWS MCP Server の一般提供の開始をお知らせします。これは、少数の固定ツールセットを通じて、すべての AWS サービスに対するセキュアかつ認証済みのアクセスを AI エージェントやコーディングアシスタントに付与する、マネージドリモートモデルコンテキストプロトコル (MCP) サーバーです。 AWS MCP Server は、 Agent Toolkit for AWS の一部です。Agent Toolkit for AWS は、MCP Server、スキル、プラグインを含むツールスイートであり、コーディングエージェントが AWS 上でより効果的かつ効率的に構築するのに役立ちます。 AI コーディングエージェントは既に多くのタスクで役立っていますが、AWS を利用して実務レベルで扱う際には、大きな課題に直面します。最新の AWS ドキュメント にアクセスできない場合、エージェントは、場合によっては数か月前のトレーニングデータに依拠し、 Amazon S3 Vectors 、 Amazon Aurora DSQL 、 Amazon Bedrock AgentCore などのサービスについて認識していない可能性があります。インフラストラクチャを構築するよう指示された場合、 AWS Cloud Development Kit (AWS CDK) や AWS CloudFormation ではなく、 AWS コマンドラインインターフェイス (AWS CLI) を使用する傾向があり、必要以上に広範な AWS Identity and Access Management (IAM) ポリシーを生成します。その結果、デモでは動作するものの、本番には適さないインフラストラクチャが生まれます。 AWS MCP Server は、モデルのコンテキストウィンドウを消費しないコンパクトなツールセットを通じてこの問題に対処します。 call_aws ツールは、お客様の既存の IAM 認証情報を使用して、15,000 以上の AWS API オペレーションを実行します。新しい API がリリースされると、数日以内にサポートが開始されます。 search_documentation ツールと read_documentation ツールは、クエリ時に最新の AWS ドキュメントとベストプラクティスを取得するため、エージェントは常に最新の情報に基づいて動作します。 一般提供の開始に伴って、いくつかの新機能が導入されます。AWS MCP Server は IAM コンテキストキーをサポートするようになったため、サーバーを使用するために別途 IAM 許可を取得する必要がなくなり、標準の IAM ポリシーできめ細かなアクセスを表現できます。ドキュメントの取得に認証は不要になりました。また、複雑な複数ステップのワークフローにおいて重要な、インタラクションごとに必要なトークン数を削減しました。 さらに新しい機能として、 run_script ツールでは、エージェントがサンドボックス環境において、サーバー側で実行される短い Python スクリプトを記述できます。サンドボックスは IAM 許可を継承しますが、ネットワークアクセスはできません。そのため、エージェントにローカルファイルシステムやシェルに対するアクセスを付与することなく、データを処理するための許可を付与できます。エージェントが複数の API を呼び出し、結果を結合する必要がある場合、それらを一度に 1 つずつ処理するのは時間がかかり、コンテキストを浪費します。 run_script を使用すると、エージェントは API コールを連鎖させ、応答をフィルタリングし、結果を単一のラウンドトリップで計算します。これは、より迅速であり、かつ、より高いコンテキスト効率を提供します。 最も重要な追加機能は、エージェント SOP からスキルへの移行です。スキルは、エージェントが極めてミスを犯しやすいタスクについて、厳選されたガイダンスとベストプラクティスを提供します。これは、エージェントが検証済みのベストプラクティスを使用して、エラーとトークンを減らし、より迅速に作業を完了するのに役立ち、結果として、時間とコストを節約できます。スキルは AWS サービスチームによって提供および維持されます。これにより、ツールリストが短く予測可能になるため、ハルシネーションが減り、エージェントが集中し続けられるようになります。 エンタープライズのお客様向けに、AWS MCP Server は、人間とエージェントの許可を明確に分離します。IAM ポリシーまたはサービスコントロールポリシーを使用して、特定のユーザーが変更オペレーションを実行できるようにする一方で、MCP Server が読み取り専用アクションに制限されるように指定できます。 AWS-MCP 名前空間の元で発行される Amazon CloudWatch メトリクスを使用することで、MCP Server の呼び出しを、人間による直接呼び出しとは別に監視できるため、コンプライアンスチームが必要とする監査証跡が得られます。Amazon CloudTrail は、完全な記録のためにすべての API コールをキャプチャします。 実際の動作 このデモでは Claude Code を使用することにしましたが、AWS MCP Server は、MCP をサポートする任意の AI エージェントで使用できます。基本的には、現在利用可能なすべてのツール ( Kiro CLI 、 Kiro 、 Cursor 、 Codex など) です。Claude Code は Anthropic の Opus 4.6 モデル を使用するように設定しています。 Opus 4.6 の ナレッジカットオフ日は 2025 年 5 月 です。これは、2025 年 5 月よりも後に発生した事象については、このモデルが何も知らないことを意味します。最近導入された AWS サービスである Amazon S3 Vectors ( 2025 年 7 月にプレビュー としてリリースされ、 2025 年 12 月に一般提供が開始 されました) について質問します。 質問は「S3 で 埋め込み を保存する方法」です。(埋め込みはベクトルの一種です) 5 つの解決策が提示され、すべて正しいのですが、私が求めたように S3 Vectors を使用する解決策は 1 つもありませんでした。この回答は Claude Code ではなく、Opus 4.6 モデルによるものであることに留意してください。S3 Vectors はモデルのトレーニング時に発表されていなかったため、同じモデルを使用する AI ツールは同様の回答を返します。 では、AWS MCP Server を使用して試してみましょう。 AWS MCP Server は AWS Identity and Access Management (IAM) と IAM SigV4 認証 を使用します。MCP ( OAuth 2.1 のみをサポート) 経由でローカルの AWS 認証情報を使用するために、プロキシ経由で AWS MCP Server を呼び出すように AI コーディングエージェントを設定しました。 MCP Proxy for AWS は、私のマシン上で動作するオープンソースのプロキシであり、IAM 認証の仕組みと OAuth を橋渡しします。 MCP の設定を、以下のコマンドで追加します: claude mcp add-json aws-mcp --scope user \ '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}' JSON 設定を分析してみましょう: ユーザー scope を使用して、私のノートパソコン上のすべてのプロジェクトでサーバーを使用できるようにします。 uvx mcp-proxy-for-aws はプロキシを起動するコマンドです。残りの引数はプロキシに渡されるパラメータです。 https://aws-mcp.us-east-1.api.aws/mcp は、AWS MCP Server の 2 つのリージョンレベルのエンドポイントのうちの 1 つです。プロキシは、Claude Code のリクエストをこのエンドポイントに転送します。 --metadata はプロキシターゲットに渡されます。ここでは、米国西部 (オレゴン) リージョンを使用するように AWS MCP Server に指示しています。 Claude Code を起動し、 /mcp と入力して、AWS MCP Server が正しくインストールされており、私の認証情報を使用できることを確認します。 私は「S3 で埋め込みを保存するにはどうすればよいですか」という同じ質問をします。 今回は、Claude Code は質問に回答するために使用できるツールがあることを認識しています。 aws___search_documentation ツールを呼び出すための許可を求められます。数秒後、「AWS は現在、このための専用サービスである Amazon S3 Vectors を提供しています…」という正しい回答が表示されます。 料金と利用可能なリージョン AWS MCP Server は現在、米国東部 (バージニア北部) と欧州 (フランクフルト) の AWS リージョンで利用可能であり、どのリージョンに対しても API コールを実行できます。AWS MCP Server 自体に追加料金はかかりません。お支払いいただくのは、作成した AWS リソースの料金と、該当するデータ転送コストのみです。 AWS MCP Server は、Claude Code、Kiro、Cursor、および任意の MCP 互換クライアントと連携します。使用を開始するには、「 AWS MCP Server ユーザーガイド 」をご覧ください。 私は、2025 年の初めに AI エージェントで MCP ツールの使用を開始して以来、このようなものをずっと待っていました。単一サーバーにおける最新のドキュメント、認証済み API アクセス、サンドボックス化されたスクリプト実行の組み合わせは、エージェントが AWS 上で実際に実行できることを変えます。お客様がこれを使用してどのようなものを構築するのか、とても興味があります。ぜひコメントでお知らせください。 – seb 原文は こちら です。

はじめに 本ブログは、株式会社丸千代山岡家と Fivetran Japan、Amazon Web Services Japan が共同で執筆しました。 みなさま、こんにちは。AWS ソリューションアーキテクトの大久保です。 昨今、Apache Iceberg を利用したレイクハウスアーキテクチャが AWS の Analytics ワークロードの中心となりつつあります。Iceberg テーブルを分析基盤の核に据える構成が広がる一方で、「データベースからどのように Iceberg テーブルにデータを連携するか」――この”データを投入するコンポーネント”の選定に悩まれている方も多いのではないでしょうか。特に、基幹データベースの変更をタイムリーに反映したい場合、 CDC（Change Data Capture） が有力な選択肢となります。CDC とは、データベースに対する変更（INSERT / UPDATE / DELETE）をリアルタイムまたはニアリアルタイムに検知・取得する手法です。従来のバッチ処理のようにテーブル全体を定期的にコピーするのではなく、変更差分のみを効率的に転送できるため、データの鮮度と転送効率を両立できます。しかし、実際に CDC パイプラインを構築しようとすると、複数サービスを組み合わせた運用負荷など、想定以上のハードルに直面することも少なくありません。 本記事では、ラーメンチェーン「山岡家」を展開する 株式会社丸千代山岡家 （以下、山岡家）が、Fivetran の CDC 機能を活用して Oracle から Amazon S3 上の Iceberg テーブルへのデータ同期を実現した事例をご紹介します。アーキテクチャの検討プロセスから Fivetran 導入後の効果まで解説しますので、同様の構成を検討されている方の参考になれば幸いです。 図 1：山岡家オリジナル看板ロゴ T シャツ。「ラーメンはスープが命。データは鮮度が命。」 山岡家のデータ活用と今回の課題 山岡家では、データ活用による経営の最適化に積極的に取り組んでいます。具体的には、以下のような取り組みを進めています。 仕入れ量の最適化 ：各店舗の売上・仕入れデータの分析による適正発注 人員配置の効率化 ：来客予測に基づくシフト最適化 キャッシュロジスティックスの最適化 ：店舗内現金の金種別増減予測 現金管理の差異分析 ：店舗ごとの現金過不足の検知・分析 これらのデータ活用を支える基盤として、Snowflake を中核に据え、AWS サービスと組み合わせたデータパイプラインを構築しています。Snowflake は分析・クエリだけでなく、パイプラインのオーケストレーション（タスク完了検知等）も担っており、データ基盤全体の中核的な役割を果たしています。 会計仕訳データのリアルタイム連携 こうしたデータ基盤をさらに発展させるにあたり、今回取り組んだのが 会計仕訳データのリアルタイム連携です。会計仕訳データは、現金管理の差異分析を含む幅広い用途で活用しています。現状は会計データを直接 BI に接続していますが、BI 層を分離し、データレイク経由での参照に移行することで、会計データを SSOT（Single Source of Truth）として一元管理したいと考えています。 今回の具体的な課題は Amazon RDS for Oracle 上の会計仕訳データを、ニアリアルタイム（数分間隔）で S3 上の Iceberg テーブルに同期し、 Snowflake からクエリ できるようにすること でした。このデータ連携の方式として CDC を採用した理由は以下の通りです。 ニアリアルタイムの反映が必要 ：店舗の現金出納データを BI で社内公開しており、数分単位でのデータ反映が求められていた 差分同期が必要 ：会計仕訳データは日々の入力に加えて過去データの修正・削除も発生するため、INSERT だけでなく UPDATE・DELETE を含むテーブル同期が必要だった 構築したアーキテクチャ この課題に対し、Fivetran の CDC 機能を採用して以下のアーキテクチャを構築しました。 図 2：RDS for Oracle から S3 Iceberg への CDC パイプラインアーキテクチャ Fivetran が RDS for Oracle から変更データを取得し、S3 上に Iceberg 形式で書き込みます。データカタログは Fivetran が管理する Polaris Catalog を利用しており、Snowflake はこのカタログを参照して S3 上の Iceberg テーブルを認識します。Tableau は Snowflake 経由でデータにアクセスする構成です。 以降のセクションでは、この構成に至った経緯と Fivetran を選択した理由、データの流れの詳細を解説します。 Fivetran の採用 検討した構成 当初は AWS のサービスを組み合わせた構成も検討しましたが、それぞれ課題がありました。 ストリーミング CDC（  AWS Database Migration Service → Amazon Kinesis Data Streams → Amazon Data Firehose → Amazon S3 ） ：DMS の CDC 機能自体は実績のある手法だが、今回の構成では DMS に加えて Kinesis Data Streams、Data Firehose、S3 と 4 つのサービスを組み合わせる必要があり、それぞれの設定・監視・障害対応を含めた運用負荷が課題だった。また、DMS の定期的なバージョンアップに伴うダウンタイムへの対応も継続運用上の考慮点だった バッチ ETL ：ニアリアルタイムでのデータ反映という要件を満たせなかった よりシンプルかつリアルタイム性を両立できる構成を模索する中で、Fivetran の CDC 機能に着目しました。 Fivetran とは Fivetran は、データの収集・転送を自動化するマネージドデータパイプラインサービスです。700 以上のデータソースに対応しており、ノーコードでデータパイプラインを構築できます。詳細は Fivetran 公式サイト をご参照ください。 図 3：Fivetran の全体像 — 多様なデータソースから Data Warehouse・Data Lake への連携を自動化する（出典: Fivetran） Fivetran の CDC 機能 は、ソースデータベースの変更（INSERT / UPDATE / DELETE）やスキーマの変更を検知し、ターゲットシステムへ自動的に反映します。Oracle を含む主要な RDB に対応しており、インフラの構築・管理なしに CDC パイプラインを実現できる点が特徴です。 Fivetran を選択した理由 山岡家が Fivetran を選択した背景には、以下のポイントがありました。 Oracle CDC の運用複雑性を吸収できる ：Oracle の CDC は、アーカイブログの管理や補足ロギングの設定など、他の RDB と比較して実装の複雑さが高い。Fivetran は Binary Log Reader 方式 でこれらを吸収し、Oracle 固有の設定を深く意識することなく CDC パイプラインを構築できる Iceberg 形式での書き込みと Snowflake と直接連携できる Polaris Catalog を提供している ：S3 に Iceberg 形式でデータを書き込み、カタログでメタデータを管理できる 複数データソースを統合管理できる ：Oracle の CDC だけでなく SmartHR 等の SaaS からの API 連携も同一プラットフォームで管理でき、データ基盤全体の統一性が向上する 運用コンポーネントが少ない ：SaaS として提供されるため、前述のストリーミング CDC 構成のように複数サービスの設定・監視・障害対応を個別に行う必要がない 山岡家では、本来単純な EL（Extract / Load）処理に社内リソースを割くのではなく、データ活用そのものに注力したいという背景がありました。データベースから Iceberg へ低い運用コストでニアリアルタイムに CDC が可能な Fivetran を選定し、短期間で目的を達成できました。 データの流れ 本記事で解説する CDC パイプラインのデータの流れは以下の通りです。 ソースからのデータキャプチャ ： Fivetran が Binary Log Reader 方式で RDS for Oracle の変更情報を取得し 、INSERT・UPDATE・DELETE の変更を検知します。初回実行時にはフルロードが行われ、以降は差分のみが転送されます。SmartHR からは API 経由で人事データを取得します（こちらは CDC ではなく API ポーリング）。 初回フルロードから差分同期への切り替えを含む具体的なセットアップ手順については「 Fivetran の Managed Data Lake Service の CDC で実現する業務システムから Apache Iceberg へのリアルタイムデータ連携 」をご参照ください Iceberg 形式での S3 書き込み ：キャプチャした変更データを Apache Iceberg 形式で Amazon S3 に書き込みます。データファイル（Parquet）とメタデータが S3 上に格納されます カタログでのメタデータ管理 ：Polaris Catalog に Iceberg テーブルのメタデータ（スキーマ情報、スナップショット履歴、パーティション情報など）が登録されます。分析エンジンはカタログを参照するだけでテーブルの構造と最新の状態を把握できます Snowflake からの分析クエリ ：Snowflake は Polaris Catalog を参照し、S3 上の Iceberg テーブルを Iceberg Tables として認識します。Fivetran が新しいデータを書き込むたびに Snowflake 側のテーブル情報が自動更新され、常に最新のデータに対してクエリを実行できます なお、CDC はデータ同期だけでなく、Snowflake 上の仕訳連携タスクの完了検知トリガーとしても活用しており、データ同期とパイプライン制御を一つの仕組みで兼ねています。 なお、S3 Tables ではなく S3 Standard を採用しています。これは、Fivetran の Iceberg 連携に必須となる Fivetran 管理の Polaris Catalog が、執筆時点で S3 Tables との統合に対応していないためです。S3 Tables の利用を検討される場合はこの点にご留意ください。 Fivetran 導入の効果 実際に Fivetran を導入した結果、山岡家が実感している効果は以下の通りです。 環境維持の負荷が低い 山岡家が最も評価しているポイントの一つです。維持すべきものは S3 バケットと Fivetran のデータカタログ環境のみであり、複数コンポーネントの監視・障害対応・バージョン管理が不要です。データエンジニアリングに専任チームを置かない組織でも無理なく運用できる構成になっています。 データ反映のレイテンシ Fivetran の CDC 機能により、会計仕訳データの変更が 約 5 分 で S3 上の Iceberg テーブルに反映され、Snowflake からクエリ可能になります。日々の仕訳入力から分析可能になるまでのタイムラグが大幅に短縮され、よりタイムリーな経営判断が可能になりました。 運用工数の大幅削減 Fivetran 導入後、データパイプラインの運用工数は月あたり約 0.5 日にまで削減されました。導入前は月あたり約 6 日の運用工数が発生していましたが、SaaS としてコンポーネントの監視・障害対応・バージョン管理が抽象化されたことで大幅に削減されています。 複数データソースの一元管理 Oracle の会計仕訳データ（CDC）に加えて SmartHR の人事データ（API 連携）も Fivetran 経由で連携しており、データ取得方式が異なるソースでも同一プラットフォームでデータパイプラインを管理できています。データソースが増えても Fivetran 上でコネクタを追加するだけで済むため、データ基盤の拡張が容易です。 ワークロードの規模感 採用を検討されている方の参考として、本パイプラインのワークロード規模を記載します。 # 項目 値 1 月間レコード数 約 20 万行 2 月間データサイズ 約 2 GB 3 日次平均レコード数 約 7,000 行 4 日次平均データサイズ 約 70 MB 5 ピーク（月初） 約 7,000 件 / 5 分 通常時は比較的少量のデータが継続的に連携されますが、月初の会計締め処理時にはバースト的にデータ量が増加します。Fivetran はこのようなピーク時にも安定して動作しており、レイテンシの悪化やエラーは発生していません。 今後の展望 今回の Fivetran CDC パイプラインは、山岡家のデータ基盤を発展させるための第一歩です。今後は既存の Snowflake 基盤を活かしつつ Iceberg の適用範囲を広げ、定型データがほぼすべて可視化された状態を目指していきます。 データ基盤の方向性：Snowflake + S3 Iceberg の併用 現状は Snowflake Internal Tables にデータを直接格納するケースが多くありますが、長期的にはデータ入力等にかかるコストとオープン性を見据え、活用できる箇所には Amazon S3 上の Apache Iceberg テーブルを採用していく方針です。Iceberg を採用する理由は主に 3 つあります。 Snowflake とのネイティブ連携 ：Snowflake が Iceberg テーブルをネイティブに参照できるため、既存の分析基盤との親和性が高い オープンフォーマットの拡張性 ：特定のエンジンにロックインされず、将来的に用途に応じた分析ツールを選択できる 運用の柔軟性 ：タイムトラベルやスキーマ進化といった機能により、データ管理の負荷を軽減できる S3 にデータを Iceberg 形式で集約しておくことで、Snowflake での分析に加え、将来的には他のサービスからもデータを活用できます。Snowflake 経由の分析についても、現在の Tableau に加え、Sigma BI や Streamlit など、用途に応じた分析ツールの活用を視野に入れており、データ活用の幅をさらに広げていく予定です。 まとめ 本記事では、山岡家が Fivetran の CDC 機能を活用して、RDS for Oracle から Amazon S3 上の Apache Iceberg テーブルへのデータ同期を実現した事例をご紹介しました。 当初は AWS のサービスを組み合わせたストリーミング CDC 構成も検討しましたが、複数コンポーネントの運用負荷を考慮し、Fivetran のマネージド CDC 機能を採用しました。その結果、約 5 分でのデータ反映、月あたりの運用工数を約 6 日から 0.5 日への削減、PoC から本番稼働まで約 1 ヶ月という短期導入を実現しています。 CDC × Iceberg on AWS の構成を検討されている方にとって、本記事がアーキテクチャ選定の一助となれば幸いです。 著者について 田中 陽里 株式会社丸千代山岡家 経営企画室 副室長 2023 年より現職。外食産業における DX を推進し、データドリブン経営を支えるデータ基盤の企画・構築を推進。 好きな AWS サービスは Amazon Elastic Container Service です。 大久保 裕太 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっています。IoT 領域が得意で、好きな AWS サービスは AWS IoT Core 。  

企業による AI エージェント導入の際に大きな課題となっているのは、多くの業務ワークフローを支えるデスクトップ環境やレガシーアプリケーションに、最新の AI システムからアクセスできないことです。 2024 Gartner のレポート によると、組織の 75% が最新の API を備えていないレガシーアプリケーションを実行しており、また Fortune 500 企業の 71％ が、適切なプログラマティックアクセスを持たないメインフレーム上で、重要な業務プロセスを運用しています。多くの組織にとって、これは AI の導入を遅らせるか、高コストかつリスクの高いモダナイゼーションプロジェクトに取り組むかの選択を迫ることを意味していました。 2026 年 5 月 5 日、 Amazon WorkSpaces がアプリケーションのモダナイゼーションを行うことなく、AI エージェントがデスクトップアプリケーションを安全に操作できるようになったことを発表しました。何百万人もの従業員が利用し、信頼を寄せているものと同じマネージド仮想デスクトップを AI エージェントにも使用できるようになりました。これにより、WorkSpaces は単なる業務環境の提供基盤ではなく、企業の生産性を大規模に拡張するためのインフラストラクチャへと進化します。エージェントは既存の WorkSpaces 環境内で動作するため、API を構築したり、アプリケーションの移行を計画したり、新しいインフラストラクチャを管理したりする必要はありません。 早期にエージェントへ WorkSpace を割り当てたお客様もいます。Nuvens Consulting のディレクターである Chris Noon 氏は次のように語っています。 「WorkSpaces を利用することで、顧客は、AI エージェントに大して従業員がすでに使用しているのと同じ安全でガバナンスの効いたデスクトップ環境を提供できます。カスタム API 統合、完全な監査証跡、エンタープライズグレードの分離はすべて追加設定なしで利用できます。規制の厳しい業界にとって、これは付加価値ではなく、前提となる基準です。」 AI エージェントの安全なクラウドデスクトップアクセス WorkSpaces を使用すると、AI エージェントはマネージド WorkSpaces 環境内で実行されているデスクトップアプリケーションに安全にアクセスして操作し、複雑な業務ワークフローを完了できます。エージェントは AWS Identity and Access Management (IAM) によって認証され、Workspaces を介して接続します。また、完全な監査証跡は AWS CloudTrail と Amazon CloudWatch を通じて利用可能です。エージェントはローカルマシンではなく安全な WorkSpaces 環境内で動作するため、既存のセキュリティ管理とコンプライアンスポリシーはそのまま完全に維持されます。 Amazon Workspaces は業界標準の モデルコンテキストプロトコル (MCP) をサポートしています。つまり、WorkSpaces は LangChain 、 CrewAI 、 Strands Agents など、任意のエージェントフレームワークと連携できます。 試してみましょう AI エージェント用の WorkSpaces 環境をセットアップするために、まず AWS マネジメントコンソール で新しい WorkSpaces アプリケーションスタックを作成しました。このスタックは、エージェントの接続方法と許可される操作を制御する環境定義です。 Amazon WorkSpaces コンソールから [スタックの作成] を選択し、名前、フリートの関連付け、VPC エンドポイントなどの基本設定を構成しました。スタック作成ワークフローのステップ 3 で、新しい AI エージェントセクションに 2 つのオプションがあることに気付きました。1 つ目の [AI エージェントアクセスなし] は、ユーザー向けに設計された標準 WorkSpaces のデフォルト設定です。2 つ目の [AI エージェントの追加] を使用すると、AI エージェントは独自の ID と権限を使用してアプリケーションに安全にアクセスして操作できます。このスタックでエージェント接続を有効にするために、[AI エージェントの追加] を選択しました。 次に、エージェントアクセス設定を構成してエージェントがデスクトップを操作する方法を定義する前に、ストレージを有効にします。 エージェント機能では、3 つの機能を有効にしました。 コンピューター入力 により、エージェントはデスクトップ内でクリック、入力、スクロールできます。 コンピュータービジョン により、エージェントはデスクトップのスクリーンショットをキャプチャできるようになり、これによってアプリケーションを「認識」します。最後に、スクリーンショットのストレージは、監査とデバッグのためにセッションのスクリーンショットを保存する場所を設定します。 デスクトップ画面のレイアウト では、画面の解像度を 1280×720 に、画像形式を PNG に設定しました。解像度は、エージェントがセッション中に認識する内容の精度を決定します。密な UI 要素を持つ複雑なアプリケーションでは高解像度が有利ですが、ターミナル型インターフェイスであれば 720p でも十分に機能します。 スタックを設定すると、WorkSpaces はマネージド MCP エンドポイントを公開します。エージェントフレームワークをこのエンドポイントに接続し、認証用に IAM 認証情報を提供したところ、エージェントはフリートのイメージにインストールされているデスクトップアプリケーションとの対話を開始しました。 この動作の例として、Strands Agent SDK と Amazon Bedrock で構築されたエージェントが、API を持たないサンプル薬局システム内で、処方箋の再発行、患者記録の検索、医薬品の検索、注文処理、そして再発行完了の確認までを一連の流れで実行しています。 アプリケーションは、エージェントが操作していることを認識しません。ソフトウェアについては何も変更、再構築、または統合されていません。エージェントは、現在の状態とまったく同じように処理しました。 今すぐご利用いただけます この機能は現在、追加料金なしのパブリックプレビューとして提供されており、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、パリ)、およびアジア (東京、ムンバイ、シドニー、ソウル、シンガポール) の 各リージョン でご利用いただけます。 GitHub リポジトリ を使用して今すぐ構築を開始するか、 WorkSpaces ページにアクセスして詳細を確認してください。 原文は こちら です。

本記事は 2026 年 5 月 7 日に公開された “ Announcing aggregations on Amazon ElastiCache ” を翻訳したものです。 Amazon ElastiCache が集計クエリをサポートするようになり、単一のクエリでキャッシュ内のデータを直接フィルタリング、グループ化、変換、集計することがより簡単になりました。集計クエリを使用することで、テラバイト規模のデータに対してマイクロ秒単位の低レイテンシーで、最新の書き込みが反映された結果を返す、リアルタイムなアプリケーション体験を構築できます。データがすでに存在する場所で、アプリケーションが要求する速度で分析を行うことができ、別途分析レイヤーを用意する必要はありません。集計機能を使用すると、ElastiCache に保存済みのデータに対して、リアルタイムのリーダーボード、ファセット検索によるカタログブラウジング、運用レポート、探索的な分析クエリなどを構築できます。 ElastiCache 内のメモリ上で集約処理を直接実行することで、アーキテクチャの複雑さを軽減し、応答時間を改善できます。集約クエリはサーバー側で計算を実行するため、アプリケーションはデータをその場で分析し、最終的なサマリーのみを返すことができます。例えば、1 つの集約クエリで、製品カタログをフィルタリングして特定のカテゴリのデータを取得し、結果をブランドごとにグループ化し、各ブランドの平均評価を計算し、パフォーマンス上位 10 件のみを返すといったことが可能です。これらのクエリは、GROUPBY、REDUCE、APPLY、FILTER、SORTBY、LIMIT などのステージをパイプラインに連結することで構築でき、各ステージの出力が次のステージへの入力になります。これらのステージを任意の順序で組み合わせ、繰り返し使用することで、1 つのコマンドで複数ステップの分析ワークフローを構築できます。集約はプライマリ上で Read-after-Write 整合性 (書き込み後読み取り整合性) を提供するため、結果には最新の書き込みが反映され、クライアントコードを変更することなくシャード間でスケールします。本投稿では、集約によって実現できるユースケースを紹介し、ElastiCache for Valkey を使ってファセットブラウジングエンジンを構築しながら、その仕組みを解説します。 これらの集約機能は、ElastiCache version 9.0 for Valkey で、全文検索、完全一致検索、範囲検索、ベクトル検索機能 ( Amazon ElastiCache での全文検索、完全一致検索、範囲検索、ハイブリッド検索 を参照) と並んで利用可能です。ElastiCache version 9.0 for Valkey ではまた、個々のフィールドに対するきめ細やかな TTL 制御を可能にするハッシュフィールドの有効期限機能や、最大 40% 向上したパイプラインスループットも導入されています。リリースの詳細については、 Amazon ElastiCache 向け Valkey 9.0 のお知らせ をご覧ください。 集約の使用が適している場面 アプリケーションは、リアルタイムでフィルタリング、グループ化、集計する必要があるデータを ElastiCache に保存することがよくあります。例えば、E コマースプラットフォームでは、カタログ全体にわたってカテゴリ別の平均評価や商品数を計算します。ストリーミングサービスでは、ジャンル別の総視聴数、平均視聴時間、再生数上位の作品を算出し、トレンドフィードやレコメンデーションランキングを構築します。金融サービスでは、ユーザーや時間枠ごとに取引をグループ化して合計を計算し、しきい値違反を検出し、コンプライアンスレポートを生成します。アプリケーションは、ユーザー向けのエクスペリエンス、ライブ分析、運用レポートを支えるためにこのデータをリアルタイムに分析する必要があり、古いデータや遅い結果はユーザーエクスペリエンスを低下させます。デバッグや単発の調査のためにアドホックなクエリが必要な開発者は、別の分析レイヤーを設定したり、データをアプリケーションレイヤーにエクスポートしたりすることなく、ライブデータに対して直接集計を実行することもできます。集計は、次の 3 つの一般的なユースケースをサポートします。 カタログフィルタリングのためのファセット検索: E コマースプラットフォームでは、買い物客がブラウジングする際に、各フィルタの組み合わせに一致する商品数を表示します。買い物客がカテゴリや価格帯を選択すると、UI は残りのすべてのフィルタ値のカウントを即座に更新します。1 つの集計クエリで、一致するカタログをブランド、色、または評価ごとにグループ化し、グループごとのカウントを返すため、アプリケーションは事前計算や古いカウントのキャッシュなしに正確なファセット数を表示できます。集計はインメモリで直接実行されるため、数百万の商品にまたがる場合でも、これらのカウントはマイクロ秒のレイテンシで返されます。 リアルタイムのトレンドとランキング: ゲームプラットフォーム、ストリーミングサービス、マーケットプレイスでは、ライブのエンゲージメント指標に基づいてトレンドコンテンツや上位ランカーを表示します。従来、これにはスケジュールに従ってランキングを再計算するバックグラウンドジョブが必要で、データの陳腐化を招いていました。あるいは、大量の結果セットに対するアプリケーション側でのソートが必要で、レイテンシーが増加していました。単一の集計クエリで、コンテンツをカテゴリーごとにグループ化し、総視聴回数、エンゲージメントスコア、プレイヤーランクを計算して、上位の結果を返すことができます。インデックスは書き込み時に同期的に更新されるため、集計クエリはポーリング、キャッシュ無効化、定期的な再計算を行うことなく最新のデータを反映します。 運用レポートと分析: ElastiCache を高速アクセスのために利用するアプリケーションでは、同じデータに対する運用分析やレポートが必要になることがよくあります。例えば、セッションストアではデバイスごとの平均セッション時間を計算し、E コマースプラットフォームではステータスやフルフィルメント段階ごとの注文量を計算します。Aggregations は、別途の分析用クラスターをプロビジョニングしたり ETL パイプラインを維持したりすることなく、スケジュールに基づいて、またはオンデマンドで、これらのクエリをインメモリデータに対して直接実行します。 ElastiCache を使ったファセット検索とリアルタイム分析の構築 これらの機能を組み合わせて実演するために、メディアストリーミングプラットフォームである AnyOrganization 向けに、ファセットブラウジングと分析エンジンを構築します。AnyOrganization はコンテンツカタログを ElastiCache にハッシュキーとして保存しており、各映画タイトルにはジャンル、言語、スタジオ、評価、リアルタイムの視聴回数といったメタデータが含まれています。以下のコードでは、このデータに対して 3 つのクエリパターンを構築します。ファセットフィルタリング、ライブトレンドアイテム、そしてスタジオレベルのエンゲージメントレポートです。 前提条件 この記事の例では、Python と valkey-py クライアントライブラリを使用します。手順を実行するには、以下が必要です (所要時間の目安: 30 分): AWS アカウント および AWS Command Line Interface (AWS CLI) ElastiCache レプリケーショングループを作成する権限を持つ AWS IAM ロール Amazon ElastiCache クラスターと同じ VPC 内にある Amazon EC2 インスタンス (または Amazon ElastiCache に接続可能な 任意のアプリケーション) Python 3.9 以降、および valkey-py バージョン 6.1.1 以降 (pip install valkey) この投稿の完全なサンプルコードは、 Amazon ElastiCache samples GitHub リポジトリで入手できます。 git clone https://github.com/aws-samples/amazon-elasticache-samples.git cd amazon-elasticache-samples/blogs/aggregations-blog ElastiCache for Valkey クラスターのセットアップ 集計機能を利用するための ElastiCache クラスターは、 AWS Management Console または AWS CLI で作成できます。集計機能は ElastiCache version 9.0 for Valkey 以降で利用可能です。以下の例では CLI を使用しています。 aws elasticache create-replication-group \ --replication-group-id AnyOrganization-cache \ --replication-group-description "AnyOrganization Valkey cluster" \ --engine valkey \ --engine-version 9.0 \ --transit-encryption-enabled \ --cache-node-type cache.r7g.large \ --num-node-groups 2 \ --replicas-per-node-group 1 \ --multi-az-enabled \ --automatic-failover-enabled # --transit-encryption-enabled が設定されている場合、Python クライアント接続に # ssl=True を追加します: # client = valkey.ValkeyCluster(..., ssl=True) データへのインデックス作成 ElastiCache に保存されているデータに対して、 catalog_index というインデックスを作成します。 Genre 、 language 、 studio は、ファセットフィルタリング用の完全一致タグとしてインデックス化されます。 Release_year 、 rating 、 views_24h は、範囲フィルタやソート用の数値フィールドとしてインデックス化されます。タイトルは、キーワード、プレフィックス、あいまい一致をサポートする全文検索可能なフィールドとしてインデックス化されます。 以下のコードは、valkey-py の search モジュールを使用して Valkey Search コマンドを構築し送信します。各 Python メソッド呼び出しは、ネットワーク越しに送信される Valkey コマンドに直接対応しています。例えば、 client.ft("catalog_index").create_index(...) は FT.CREATE コマンドを送信し、 client.ft("catalog_index").aggregate(req) は FT.AGGREGATE コマンドを送信します。各コードブロックの横に、対応する Valkey コマンドを示しています。 import valkey from valkey.commands.search.field import TextField, TagField, NumericField from valkey.commands.search.indexDefinition import IndexDefinition, IndexType # : Insert your ElastiCache cluster's discovery endpoint VALKEY_CLUSTER_ENDPOINT = "placeholder_cluster.cnxa6h.clustercfg.use1.cache.amazonaws.com" client = valkey.ValkeyCluster( host=VALKEY_CLUSTER_ENDPOINT, port=6379, decode_responses=True, ssl=True) client.ft("catalog_index").create_index(fields=[ TextField("title"), TagField("genre"), TagField("language"), TagField("studio"), NumericField("release_year"), NumericField("rating"), NumericField("views_24h")], definition=IndexDefinition(prefix=["title:"],index_type=IndexType.HASH)) 同等の Valkey コマンド: FT.CREATE catalog_index ON HASH PREFIX 1 title: SCHEMA title TEXT genre TAG language TAG studio TAG release_year NUMERIC rating NUMERIC views_24h NUMERIC ElastiCache for Valkey ストアにカタログデータを投入します。本記事では、ElastiCache GitHub リポジトリのサンプルデータを使用しますが、他のデータソースを使用することもできます。 import csv import urllib.request import io import time response = urllib.request.urlopen( "https://raw.githubusercontent.com/aws-samples/amazon-elasticache-samples/main/blogs/aggregations-blog/catalog_data.csv") reader = csv.DictReader(io.TextIOWrapper(response)) count = 0 for row in reader: key = row.pop("id") client.hset(key, mapping=row) count += 1 print(f"Loaded {count} records") インデックスはデータをロードする前でも後でも作成できます。プレフィックスに一致するキーが既に存在する場合、Valkey Search はそれらを自動的にインデックスにバックフィルします。 ファセットフィルター 以下の集計は、ユーザーが選択したフィルターを受け取り、一致する結果をジャンル、言語、評価、公開年でグループ化し、各グループのタイトル数を返します。これにより、UI は結果と並べてファセットの件数を表示できます。 from valkey.commands.search.aggregation import AggregateRequest, Desc from valkey.commands.search import reducers def get_facet_counts(filters): # Build query string from user-selected filters clauses = [] if "genre" in filters: clauses.append(f"@genre:{{{filters['genre']}}}") if "language" in filters: clauses.append(f"@language:{{{filters['language']}}}") if "min_rating" in filters: clauses.append(f"@rating:[{filters['min_rating']} + inf]") query = " ".join(clauses) if clauses else "@rating:[-inf + inf]" # Run an aggregation for each facet dimension dimensions = ["genre", "language", "rating"] facets = {} for dim in dimensions: req = AggregateRequest(query) \ .load(f"@{dim}") \ .group_by(f"@{dim}", reducers.count().alias("count")) facets[dim] = client.ft("catalog_index").aggregate(req).rows return facets # Example: user filters for dramas in english, get counts for each dimension facets = get_facet_counts({"genre": "drama", "language": "english"}) # Example output: # {'genre': [{'genre': 'drama', 'count': '6'}], # 'language': [{'language': 'english', 'count': '6'}], # 'rating': [{'rating': '4', 'count': '4'}, # {'rating': '5', 'count': '2'}]} 同等の Valkey コマンド (1 つのファセットディメンション、英語のドラマでフィルタリングする場合): FT.AGGREGATE catalog_index "@genre:{drama} @language:{english}" LOAD 1 @genre GROUPBY 1 @genre REDUCE COUNT 0 AS count リアルタイムで急上昇中のアイテム 以下のコードは、ジャンルごとのトップトレンドタイトルを取得します。これは、ユーザーがコンテンツを視聴するとリアルタイムで更新される views_24h フィールドに対する集計によって実現されています。 def get_trending_by_genre(limit=10): # Get the highest view count per genre # sorted by most popular genre first req = AggregateRequest("@rating:[-inf + inf]") \ .load("@genre", "@views_24h") \ .group_by("@genre", reducers.max("@views_24h").alias("max_views")) \ .sort_by(Desc("@max_views"), max=limit) return client.ft("catalog_index").aggregate(req).rows trending_by_genre = get_trending_by_genre() # Example output: # [{'genre': 'action', 'max_views': '4500'}, # {'genre': 'comedy', 'max_views': '3800'}, # {'genre': 'thriller', 'max_views': '3600'}, # {'genre': 'sci-fi', 'max_views': '3400'}, # {'genre': 'drama', 'max_views': '3200'}, # {'genre': 'animation', 'max_views': '3100'}, # {'genre': 'romance', 'max_views': '2800'}, # {'genre': 'horror', 'max_views': '2600'}, # {'genre': 'documentary', 'max_views': '1900'}] 同等の Valkey コマンド (1 つのファセットディメンションで、英語のドラマをフィルタリングする場合): FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 2 @genre @views_24h GROUPBY 1 @genre REDUCE MAX 1 @views_24h AS max_views SORTBY 2 @max_views DESC MAX 10 リアルタイムトレンドアイテム 以下のコードは、ジャンルごとにトレンドの上位タイトルを取得するもので、ユーザーがコンテンツを視聴するとリアルタイムに更新される views_24h フィールドに対する集計によって実現されています。 def get_trending_by_genre(limit=10): # Get the highest view count per genre # sorted by most popular genre first req = AggregateRequest("@rating:[-inf + inf]") \ .load("@genre", "@views_24h") \ .group_by("@genre", reducers.max("@views_24h").alias("max_views")) \ .sort_by(Desc("@max_views"), max=limit) return client.ft("catalog_index").aggregate(req).rows trending_by_genre = get_trending_by_genre() # Example output: # [{'genre': 'action', 'max_views': '4500'}, # {'genre': 'comedy', 'max_views': '3800'}, # {'genre': 'thriller', 'max_views': '3600'}, # {'genre': 'sci-fi', 'max_views': '3400'}, # {'genre': 'drama', 'max_views': '3200'}, # {'genre': 'animation', 'max_views': '3100'}, # {'genre': 'romance', 'max_views': '2800'}, # {'genre': 'horror', 'max_views': '2600'}, # {'genre': 'documentary', 'max_views': '1900'}] 同等の Valkey コマンド: FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 2 @genre @views_24h GROUPBY 1 @genre REDUCE MAX 1 @views_24h AS max_views SORTBY 2 @max_views DESC MAX 10 オンデマンドエンゲージメントレポート AnyOrganization は、制作スタジオ別のコンテンツパフォーマンスを測定するために、日次のレポートジョブを実行しています。次のコードは、同じインデックスに対する集計を使用して、タイトル数、平均評価、総エンゲージメントなどのスタジオレベルのメトリクスを計算します。 def get_studio_report(): # Studio performance: title count, average rating, total 24h views req = AggregateRequest("@rating:[-inf + inf]") \ .load("@studio", "@rating", "@views_24h") \ .group_by("@studio", reducers.count().alias("title_count"), reducers.avg("@rating").alias("avg_rating"), reducers.sum("@views_24h").alias("total_views")) \ .sort_by(Desc("@total_views")) return client.ft("catalog_index").aggregate(req).rows studio_report = get_studio_report() # Example output: # [{'studio': 'StreamFlix Originals', 'title_count': '18', # 'avg_rating': '4.3333333333', 'total_views': '46200'}, # {'studio': 'Summit Pictures', 'title_count': '13', # 'avg_rating': '3.8461538462', 'total_views': '30000'}, # {'studio': 'Crimson Studios', 'title_count': '11', # 'avg_rating': '4.4545454545', 'total_views': '23100'}, # {'studio': 'Emerald Films', 'title_count': '8', # 'avg_rating': '4', 'total_views': '13600'}] 同等の Valkey コマンド: FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 3 @studio @rating @views_24h GROUPBY 1 @studio REDUCE COUNT 0 AS title_count REDUCE AVG 1 @rating AS avg_rating REDUCE SUM 1 @views_24h AS total_views SORTBY 2 @total_views DESC ベストプラクティス 集計クエリのレイテンシーとスループットを改善するには、各パイプラインステージを通過するドキュメント数を減らすために早い段階でフィルタリングします。マッチする範囲が広いクエリは、パイプラインに入るキーの数が増え、初期スキャンと初期ステージのコストが増加します。例えば、上記のファセットフィルタリングの例では、ユーザーのアクティブなフィルターをクエリ文字列で渡すことで、マッチするドキュメントのみが GROUPBY ステージに入ります。また、しきい値を満たさないグループを削除するために GROUPBY ステージの後に FILTER を追加することもできます。例えば、結果を返す前にタイトル数が 5 未満のジャンルを除外する場合などです。さらに、上位の結果のみが必要な場合は、 SORTBY に MAX を追加することで、トレンドアイテムの例で示すように、エンジンはワーキングセット全体をソートするのではなく、上位の結果のみを追跡します。 LOAD を使うと、インデックスに含まれていないフィールドであっても、基となるハッシュデータから直接フィールドを取得して集約パイプラインに取り込むことができます。例えば、ハッシュに actors フィールドを保存しているがインデックス化していない場合、クエリ実行時に LOAD で読み込み、それを使ってグループ化やソートを行うことができます。ただし、 LOAD は一致するドキュメントごとに基となるキーから生データを取得する必要があるため、結果セットのサイズに応じてレイテンシーが増加します。このオーバーヘッドを避けるため、ロードするフィールドの数は最小限に抑えてください。 クリーンアップ このウォークスルーのために ElastiCache クラスターを作成し、不要になった場合は、今後の課金を避けるために、次の AWS CLI コマンドを使用してクラスターを削除してください。 aws elasticache delete-replication-group --replication-group-id AnyOrganization-cache はじめに この記事では、ElastiCache のアグリゲーションについて、ファセットフィルタリング、ライブトレンドのレコメンデーション、オンデマンドのエンゲージメントレポートを取り上げ、これらすべてを単一の Valkey Search インデックス上に構築する方法を解説しました。アグリゲーションは、すべての商用 AWS リージョン、AWS GovCloud (US) リージョン、および中国リージョンにおいて、ElastiCache for Valkey バージョン 9.0 を実行するノードベースのクラスターで追加費用なしでご利用いただけます。Valkey は、Redis に代わる最も寛容なライセンスのオープンソースかつベンダー中立な選択肢であり、ElastiCache で推奨されるエンジンです。使い始めるには、AWS Management Console、AWS SDK、または AWS CLI を使用して、Valkey 9.0 以降の新しいクラスターを作成するか、 既存のクラスターをアップグレード してください。詳細については、 ElastiCache のドキュメント をご覧ください。質問やフィードバックがある場合は、 AWS re:Post for ElastiCache をご覧ください。 著者について Chaitanya Nuthalapati Chaitanya は AWS インメモリデータベースサービスのシニアテクニカルプロダクトマネージャーで、Amazon ElastiCache for Valkey に注力しています。以前は、生成 AI、機械学習、グラフネットワークを活用したソリューションを構築していました。仕事以外の時間では、Chaitanya は趣味を集めるのに忙しく、現在はテニス、スケートボード、パドルボードを楽しんでいます。 Karthik Subbarao Karthik は Amazon ElastiCache のシニアソフトウェアエンジニアであり、オープンソースの Valkey プロジェクトに積極的に貢献しています。分散システム、データベース、Rust、そして全般的にソフトウェア開発／テクノロジーを通じたイノベーションに情熱を注いでいます。 Allen Samuels Allen は AWS のプリンシパルエンジニアです。分散型で高性能なシステムに情熱を注いでいます。世界中を旅したりデュプリケートブリッジをプレイしたりしていない時は、カリフォルニア州サンノゼで過ごしています。 Siva Subramaniam Siva は AWS のシニアソリューションアーキテクトで、技術リーダーシップとデータベースアーキテクチャにおいて 20 年の経験を持っています。お客様が AWS の専用データベースを使用して移行とイノベーションを実現できるよう支援しています。仕事以外では、Siva はクリケット、農作業、そして妻から料理を学ぶことを楽しんでいます。 ご指導いただいた Ian Childress 氏、そしてプロジェクト全体を通じて実装面で貢献いただいた Miles Song 氏に特に感謝いたします。 本記事は、 Announcing aggregations on Amazon ElastiCache を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

本記事は 2026 年 5 月 7 日に公開された “ Full-text, exact-match, range, and hybrid search on Amazon ElastiCache ” を翻訳したものです。 訳者註： 本記事の全文検索は、現時点では言語オプションとして english のみをサポートしており、日本語テキストはスペースや句読点で区切られた単位でインデックスされます。日本語を全文検索する場合は、事前に形態素解析で語ごとにスペースで区切ったテキストをインデックスし、検索クエリも同じ形で渡すようにしてください。 Amazon ElastiCache は、別個の検索サービスを使用することなく、キャッシュ内で直接リアルタイムの全文検索、完全一致検索、数値範囲検索、ハイブリッド検索をサポートするようになりました。低レイテンシーで動的データに対するスケーラブルな検索を必要とするワークロードに対して、アプリケーションはマイクロ秒単位のレイテンシーと毎秒最大数百万回の検索操作のスループットでテラバイト規模のデータを検索できます。これらの新しい検索機能により、開発者は ElastiCache に既に保存されているデータを、単純なキーバリュー検索を超えた属性で柔軟にクエリできるようになります。 完全一致検索は、商品名、カテゴリ、ユーザー ID、注文番号など、テキスト、タグ、数値属性にわたる正確な値の一致によってドキュメントを取得します。数値範囲検索は、価格のしきい値、日付範囲、取引金額などの属性によってドキュメントをフィルタリングします。完全一致に加えて、全文検索はテキスト属性に対して、オートコンプリート (入力補完) 用のプレフィックスマッチング、タイプミス許容のためのファジーマッチング、複数語検索のための近接マッチングを実行します。これらの検索タイプをベクトル類似度と単一のハイブリッドクエリで組み合わせることができ、正確な用語と意味的な意図の両方を捉えることで、いずれかの手法を単独で使用するよりも関連性の高い結果を提供します。ベクトルワークロードにおいて、ElastiCache for Valkey は AWS 上の主要なベクトルデータベースの中で、95% 以上の再現率で最低レイテンシかつ最高スループットのベクトル検索、そして最高の価格性能比を実現します。 これらの検索機能は、ElastiCache version 9.0 for Valkey で利用可能であり、リアルタイム分析やレポーティング向けのサーバーサイド集計機能も併せて提供されています ( Amazon ElastiCache での集計機能のお知らせ を参照)。ElastiCache version 9.0 for Valkey では、個々のフィールドに対するきめ細かい TTL 制御を可能にするハッシュフィールドの有効期限機能や、最大 40% 向上したパイプライン化スループットも導入されています。リリースの詳細については、 Amazon ElastiCache 向け Valkey 9.0 のお知らせ をご覧ください。 この記事では、新しい検索機能を順を追って紹介し、それらがどのように連携するかを示しながら、検索およびレコメンデーションエンジンをゼロから構築していきます。 複数のアプリケーションにわたる強力なリアルタイム検索を実現 お客様からは、アプリケーションがスケールするにつれて、検索ワークフローがビジネスに求められるスループットをサポートしながら、ユーザーが期待する低レイテンシーの体験を維持する必要があるとの声が寄せられています。例えば、決済プラットフォーム、ストリーミングプラットフォーム、オンライン小売業者などは、何百万ものドキュメントを ElastiCache に保存し、マイクロ秒のレイテンシーでメタデータ属性によってデータを取得する必要があります。さらに、ワークロードが進化するにつれて、すでに ElastiCache に保存されているデータに対して新しいユースケースをサポートする豊富な検索クエリが必要だというお客様の声もあります。例えば、アプリケーションはデバイスタイプ、セッション状態、ユーザーアクティビティなどのユーザーおよびセッションコンテキストを ElastiCache に保存し、低レイテンシーの体験を提供することがよくあります。ワークロードが進化するにつれて、お客様はその同じデータをレコメンデーションシステムの基盤として活用したいと考えており、そのためにはこれらの属性をまたいだ検索が必要になります。 ElastiCache では、マイクロ秒単位の低レイテンシーと毎秒数百万クエリ (QPS) のスループットでデータを検索・取得するためのさまざまな方法が提供されるようになりました。書き込みが完了するとすぐにデータが検索可能になるため、アプリケーションは常に最新の結果をクエリできます。これらの機能は、カタログ検索、レコメンデーションエンジン、エージェント型メモリ、リアルタイムのリーダーボード、セッション検索などのユースケースを支えます。 カタログ検索: オンライン小売業者やストリーミングプラットフォームは、顧客が大規模なカタログから商品を見つけられるような検索体験を構築しています。これらのプラットフォームでは、商品名や説明文に対するテキスト検索と、ブランド、カテゴリ、価格、評価によるフィルタを単一のクエリで組み合わせることで、ファセットブラウジング体験を提供できます。プレフィックスマッチングは、ユーザーが入力するにつれて候補を読み込むタイプアヘッド検索を実現し、マイクロ秒単位で結果を返すため、即座に反応するような体験を提供します。さらに、ファジーマッチングを活用したタイプミスに強い検索を組み合わせることで、スペルミスを自動的に処理し、検索体験をより堅牢にできます。ファジーマッチングは完全一致検索よりも計算コストが高いため、ElastiCache のようなインメモリ検索エンジン上で実行することで、高速で応答性の高い体験を維持できます。 レコメンデーションエンジン: カタログが数百万アイテムに拡大するにつれて、ユーザーはデジタルプラットフォームに対して、関連性の高いコンテンツや商品を素早く表示するパーソナライズされた閲覧体験を期待しています。最新のレコメンデーションシステムは、ユーザーとアイテムをベクトル埋め込みとしてエンコードします。これらのシステムは、ベクトル検索と名前、説明、カテゴリ、在庫状況、価格帯などのフィルターを組み合わせて、数百万のアイテムからレコメンデーション候補を取得します。ハイブリッド検索は、テキスト、タグ、数値フィルターをベクトル類似度と単一のクエリで組み合わせることでこれをサポートし、取得される候補は意味的に関連性があり、ビジネス上の制約も満たします。商品ページでは、同じカテゴリと価格帯にフィルタリングしてから埋め込みの類似度でランク付けすることで、「類似アイテム」を表示できます。これを拡張して、行動履歴 (閲覧したアイテムの埋め込みの平均プーリング、アテンションベースのモデル、シーケンシャルモデルなどの手法を使用) からユーザー埋め込みを構築し、それをベクトルクエリとして渡すことで、学習した嗜好に基づいて結果をランク付けするパーソナライズされたレコメンデーションを実現できます。 エージェントメモリ: エージェントメモリは、エージェントが過去のやり取りから学習することで、会話履歴全体を再生することなく応答の関連性を向上させ、トークンコストを削減します。エージェントメモリシステムは、スコープ属性 (ユーザー、エージェント、セッション) と現在のやり取りに対する意味的関連性によってメモリを保存・取得します。ハイブリッド検索を使用することで、これらのシステムはスコープやテキストフィルターとベクトル類似性を 1 つのクエリで組み合わせます。エージェントメモリはライブの会話パス上にあるため、書き込み後すぐに読み取れる可視性が求められ、新しく保存された事実が即座に取得可能である必要があり、新しいメモリの取得と統合のために高い同時読み書き性能が求められます。ElastiCache は書き込み時にメモリを同期的にインデックス化し、マルチスレッディングを活用し、AWS 上の主要なベクトルデータベースの中で最高のスループットをマイクロ秒レベルのレイテンシーで提供します。ElastiCache と Mem0 を使用したステップバイステップの実装については、 Build persistent memory for agentic AI applications with Mem0 Open Source, ElastiCache for Valkey, and Amazon Neptune Analytics をご覧ください。 ElastiCache for Valkey は、セルフマネージドのメモリレイヤーを構築したい場合や、低レイテンシでカスタマイズ可能なインメモリストアが必要な場合に適しています。フルマネージドのアプローチをお好みの場合は、 Amazon Bedrock AgentCore Memory を使用してメモリを管理することもできます。 金融アプリケーションとリーダーボード: 取引プラットフォームやゲームアプリケーションでは、取引金額、タイムスタンプ、リスクスコア、プレイヤーランキングといった数値属性を持つドキュメントを保存し、低レイテンシーで取得する必要があります。ElastiCache の数値範囲クエリは、これらの属性に対する高速な検索をサポートし、時間枠、金額のしきい値、スコア帯によるフィルタリングを可能にします。ゲームアプリケーションでは、スコアの更新を即座に反映するリアルタイムなリーダーボードを維持でき、「自分の地域のトップ 100 プレイヤー」のような範囲クエリにも対応できます。 ユーザーおよびセッション管理: 各業界のアプリケーションは、セッション管理のためにセッション ID、デバイスタイプ、ユーザーハンドルといった構造化属性をキャッシュに保存しています。これらのアプリケーションは、ユーザーがログインするとセッションデータをキャッシュに書き込み、セッションのライフサイクルを通じて更新するため、即時に検索可能な高速書き込みが求められます。ElastiCache は更新を同期的にインデックス化するため、セッション属性に対する検索は遅延なく最新の状態を反映します。完全一致検索により、数百万のドキュメントから正確な識別子に基づいてアクティブなセッションや権限をサブミリ秒のレイテンシーで特定できます。 ElastiCache を使った検索・レコメンデーションエンジンの構築 これらの検索タイプを組み合わせて実演するため、エレクトロニクス、美容、家庭用品など何百万もの製品を販売する e コマースプラットフォーム AnyCompany 向けの検索およびレコメンデーションエンジンを構築します。AnyCompany は、買い物客がキーワードで製品を見つけ、ブランドや価格帯などのフィルターで絞り込み、類似性を通じて関連商品を発見できる検索体験を求めています。AnyCompany は 100 万を超える商品カタログを ElastiCache にハッシュベースのドキュメントとして保存しています (この例では、実際のタイトル、説明、ブランドを含む Amazon ESCI データセット から派生したもの)。次のコードは、このデータに対して 5 つのクエリパターンを構築します: 入力補完検索、全文一致、タイポに強いマッチング、フィルター付きブラウジング、そして類似商品のレコメンデーションです。 前提条件 この記事の例では、 valkey-py クライアントライブラリと Python を使用しています。手順を実行するには、以下が必要です (所要時間の目安: 30 分): AWS アカウント と AWS Command Line Interface (AWS CLI) ElastiCache レプリケーショングループを作成する権限を持つ AWS IAM ロール Amazon ElastiCache クラスターと同じ VPC 内にある Amazon EC2 インスタンス (または Amazon ElastiCache に接続可能 な任意のアプリケーション) Python 3.9 以降および valkey-py バージョン 6.1.1 以降 (pip install valkey) この記事の完全なサンプルコードは、ElastiCache samples GitHub リポジトリで入手できます。 ElastiCache for Valkey クラスターのセットアップ ElastiCache の検索用クラスターは、AWS Management Console または AWS CLI を使用して作成できます。以下の例では CLI を使用しています。検索機能は ElastiCache for Valkey バージョン 9.0 以降で利用可能です。 aws elasticache create-replication-group \ --replication-group-id AnyCompany-cache \ --replication-group-description "AnyCompany Valkey cluster" \ --engine valkey \ --engine-version 9.0 \ --transit-encryption-enabled \ --cache-node-type cache.r7g.large \ --replicas-per-node-group 0 インデックスの作成とデータのロード 商品データを検索可能にするため、 products_vec_index というインデックスを作成します。タイトルと説明は、キーワード、前方一致、あいまい検索をサポートする全文検索可能な属性としてインデックス化されます。ブランドと色は、絞り込み検索のために完全一致タグとしてインデックス化されます。価格、評価、在庫は、範囲クエリやソートのためにソート可能な数値属性としてインデックス化されます。 embedding は、セマンティック類似検索やレコメンデーションのためにベクトル属性としてインデックス化されます。 import gzip import json import struct import urllib.request import valkey from valkey.commands.search.field import TextField, TagField, NumericField, VectorField from valkey.commands.search.indexDefinition import IndexDefinition, IndexType # : Insert your ElastiCache cluster's endpoint VALKEY_HOST = "placeholder_cluster.cnxa6h.clustercfg.use1.cache.amazonaws.com" client = valkey.Valkey(host=VALKEY_HOST, port=6379, decode_responses=False, ssl=True, ssl_cert_reqs="required") # Create the search index with text, tag, numeric, and vector fields try: client.execute_command("FT.DROPINDEX", "products_vec_index") except: pass client.ft("products_vec_index").create_index( fields=[ TextField("title"), TextField("description"), TagField("brand", separator=","), TagField("color", separator=","), NumericField("price"), NumericField("rating"), NumericField("stock"), VectorField("embedding", "FLAT", { "TYPE": "FLOAT32", "DIM": 64, "DISTANCE_METRIC": "COSINE"})], definition=IndexDefinition(prefix=["pv:"], index_type=IndexType.HASH)) ElastiCache ストアに商品データセットを投入します。このデータセットは 130 万件の商品のサブセットで、タイトル、説明、ブランド、および Amazon ESCI Shopping Queries データセットから導出された事前計算済みの 64 次元エンベディングを含む 13.7 万件の商品で構成されています。サンプルリポジトリをクローンし、ロードスクリプトを実行してください： git clone https://github.com/aws-samples/amazon-elasticache-samples.git cd amazon-elasticache-samples/blogs/elasticache-valkey/fts-benchmark # <入力が必要>: VALKEY_HOST 変数をクラスターのエンドポイントで更新して実行: python load_products_blog.py タイプアヘッド検索 (先行入力検索) インデックスとデータが準備できたら、AnyCompany はインデックスに対して実行され、一致するドキュメントを返す FT.SEARCH クエリを使って検索エンジンを構築できます。ユーザーが検索バーに入力すると、アプリケーションはプレフィックスクエリを送信し、リアルタイムで候補を表示します。 from valkey.commands.search.query import Query results = client.ft("products_vec_index").search( Query("wire*").return_fields("title").paging(0, 5)) # User has typed "wire" - prefix match shows suggestions # Output: # [{'title': 'xyz Kids Wireless Headphones'}, # ... # ... # {'title': 'Santas Wire Christmas Lighting Storage Bag'}] フレーズマッチング ユーザーが Enter キーを押すと、アプリケーションはタイトルと説明に対して全文検索を実行します。SLOP は、単語同士がどれだけ離れていても一致と見なすかを制御し、単語がより近接している結果ほど上位にランク付けされます。 # User submits "wireless headphones" # SLOP 2 allows up to 2 words between terms results = client.ft("products_vec_index").search( Query("wireless headphones") .slop(2) .return_fields("title", "brand", "price").paging(0, 5)) # Output: # [{'title': 'xyz Studio3 Wireless Headphones - Gray (Renewed)', # 'brand': 'xyz', 'price': '1928.28'}, # ... # {'title': 'xyz TUNE 220TWS - True Wireless in-Ear Headphone - Blue', # 'brand': 'xyz', 'price': '1121.23'}] タイプミスを許容するマッチング クエリが結果を返さない場合、アプリケーションはタイプミスを修正するためにあいまい一致 (fuzzy matching) で再試行します。あいまい一致は編集距離を計算するためコストが高いので、デフォルトとしてではなくフォールバックとして使うのが最適です。 # Retry with fuzzy matching for "wireles headphoens" results = client.ft("products_vec_index").search( Query("%wireles% %headphoens%") .return_fields("title", "brand", "price").paging(0, 5)) # Output: # [{'title': 'xyz Comfort 35 Wireless Headphones, Noise Cancelling - Silver (Renewed)', # 'brand': 'xyz', 'price': '1811.75'}, # ... # ... # {'title': 'xyz SoundSport Wireless Headphones, Black + Charging Case', # 'brand': 'xyz', 'price': '568.47'}] フィルタリングによる閲覧 買い物客が商品を検索してフィルターを適用すると、アプリケーションはテキスト検索とタグおよび数値フィルターを単一のクエリで組み合わせます。 # ユーザーが「headphones」を検索し、価格 $50-$150、評価 4.0 以上でフィルタリング results = client.ft("products_vec_index").search( Query("@title:headphones @price:[50 150] @rating:[4.0 5.0]") .return_fields("title", "brand", "price", "rating") .paging(0, 5)) # 出力: # [{'title': 'xyz WH1000XM3 Bluetooth Wireless Noise Canceling Headphones', # 'brand': 'xyz', 'price': '102.29', 'rating': '4.8'}, # ... # ... # {'title': 'Bluetooth Earbuds xyz SoundLink .. in Ear Headphones', # 'brand': 'xyz', 'price': '125.45', 'rating': '4.5'}] 類似商品のレコメンデーション 「類似商品」のレコメンデーションを実現するために、AnyCompany はテキストフィルターを使ったハイブリッド検索で結果を該当する商品タイプに絞り込み、ベクトル検索で表示中の商品との類似度に基づいてフィルター済みの結果をランク付けしています。 # Get the embedding of the product the user is currently viewing # for example - "Kids Headphones with Microphone 2 Pack" product_embedding = client.hget("pv:B0825SSTMN", "embedding") # Hybrid: text pre-filter "headphones" + vector KNN for similarity ranking results = client.ft("products_vec_index").search( Query("@title:headphones =>[KNN 5 @embedding $vec AS score]") .return_fields("title", "brand", "price", "score") .dialect(2), query_params={"vec": product_embedding}) # Output: # {'title': 'xyz I35 Kid Headphones with Microphone Volume Limited ...', # 'brand': 'xyz', 'price': '155.06', 'score': '0.293'}, # ... # ... # {'title': 'Kids Headphones with Pouch, xyz Wired ...', # 'brand': 'xyz', 'price': '957.95', 'score': '0.351'}] このパターンを拡張して、埋め込みベースの検索を活用したパーソナライゼーションを実現できます。閲覧したアイテム埋め込みの平均プーリング、アテンションベースのモデル、シーケンスモデルなどの手法を用いて、買い物客のインタラクション履歴からユーザー埋め込みを構築します。単一の商品埋め込みの代わりにユーザー埋め込みをベクトルクエリとして渡すことで、KNN スコアリングがフィルタリングされた集合の中から、買い物客の学習済みの嗜好に基づいて結果をランキングします。 内部の仕組みとパフォーマンス レイテンシーとスループットを、テキストと数値のクエリタイプについて、レプリカなしの単一の cache.r7g.2xlarge ノードを含む 1 シャード構成の ElastiCache for Valkey クラスター上で計測しました。データセットには約 1 GB のデータが含まれており、上記の例で説明したテキスト、タグ、数値、ベクトル属性を持つ 130 万件の製品ドキュメントで構成されています。レイテンシーとスループットの計測には valkey-benchmark を使用しました。 クエリタイプ P50 (ms) 1 クライアント P99 (ms) 1 クライアント QPS 300 クライアント テキスト検索 (完全一致) 0.135 0.255 60,000 前方一致 (タイプアヘッド検索) 0.135 0.279 57,692 数値範囲 (在庫/評価でのフィルタ) 0.175 0.199 24,087 ハイブリッドクエリ – テキスト + 数値範囲 (ファセットブラウジング) 0.135 0.295 52,632 ベクトル検索のレイテンシーとスループットのベンチマークについては、 Announcing vector search for Amazon ElastiCache を参照してください。上記の例では、単一の cache.r7g.2xlarge ノードでのパフォーマンスをテストしています。レプリカ (シャードあたり最大 5 つ) とシャードを追加することで読み取りスループットをスケールし、数百万 QPS に到達できます。各レプリカは独自のインデックスを持ち、独立して検索を処理できますが、レプリカからの読み取りは結果整合性となります。データ容量よりも低レイテンシーを優先する場合は、 single-slot indexes を使用して、インデックス化されたすべてのデータを 1 つのシャードに保持し、ファンアウトのオーバーヘッドを完全に回避してください。シャードを追加することで、クライアントコードを変更せずにメモリ容量を増やすことができます。 ElastiCache はデータの変更をリアルタイムで自動的にインデックス化し、エンジンは各書き込みを確認応答する前にインデックス化します。そのため、それ以降の検索では更新後のデータが返され、read-after-write 整合性が提供されます。この整合性の動作は、マルチキートランザクションや Lua スクリプトでも同様に保たれます。Valkey はマルチスレッドを活用してインデックス処理を複数のスレッドにまたがって実行するため、ElastiCache は書き込みスループットの高いワークロードにおいても検索クエリで高いパフォーマンスを発揮できます。 クリーンアップ このウォークスルーのために ElastiCache クラスターを作成し、不要になった場合は、今後の料金が発生しないように、次の AWS CLI コマンドを使用してクラスターを削除してください。 aws elasticache delete-replication-group --replication-group-id AnyCompany-cache まとめ 本投稿では、ElastiCache における全文検索、完全一致検索、数値範囲検索、およびハイブリッド検索について解説しました。これらの検索タイプのユースケースを取り上げ、検索およびレコメンデーションシステムの構築方法をご紹介しました。全文検索、完全一致検索、数値範囲検索、およびハイブリッド検索は、Valkey 9.0 を実行する ElastiCache のノードベースクラスターにおいて、すべての AWS 商用リージョン、AWS GovCloud (US) リージョン、および中国リージョンで追加費用なしでご利用いただけます。Valkey は、最も制約の少ないオープンソースかつベンダーニュートラルな Redis に代わる選択肢であり、ElastiCache における推奨エンジンです。始めるには、AWS Management Console、AWS SDK、または AWS CLI を使用して、新しい Valkey 9.0 以降のクラスターを作成するか、 既存のクラスターをアップグレード してください。詳細については、 ElastiCache のドキュメント をご覧ください。ご質問やフィードバックは、 AWS re:Post for ElastiCache までお寄せください。 著者について Chaitanya Nuthalapati Chaitanya は AWS インメモリデータベースサービスのシニアテクニカルプロダクトマネージャーで、Amazon ElastiCache for Valkey を担当しています。以前は、生成 AI、機械学習、グラフネットワークを活用したソリューションを構築していました。仕事以外の時間では、Chaitanya は趣味を集めることに忙しく、現在はテニス、スケートボード、パドルボードを楽しんでいます。 Karthik Subbarao Karthik は Amazon ElastiCache のシニアソフトウェアエンジニアで、オープンソースの Valkey プロジェクトに積極的に貢献しています。分散システム、データベース、Rust、そして全般的にソフトウェア開発・技術を通じたイノベーションに情熱を持っています。 Ian Childress Ian は AWS のソフトウェア開発マネージャーで、全文検索インフラストラクチャを含む Valkey モジュールおよび統合機能を構築するチームを率いています。仕事以外では、Ian はホッケーをプレイし、Go 言語で高性能システムを書くことに没頭する飽くなき探求者です。夏になると、氷から湖へと舞台を移し、毎週末家族とウェイクサーフィンを楽しんでいます。 Eran Balan Eran は AWS のスペシャリストソリューションアーキテクトで、インメモリデータベースおよび Amazon ElastiCache を専門としています。EMEA 地域のお客様と協力し、キャッシングアーキテクチャの設計、パフォーマンスの最適化、Redis OSS から Valkey への移行など、さまざまな移行を支援しています。仕事以外では、Eran はミュージカルや演劇の観劇、ハイキング、オープンウォータースイミングを楽しんでいます。 プロジェクト全体を通じて、ビジョン、指導、そして実践的な貢献をいただいた Allen Samuels 氏に心より感謝申し上げます。 本記事は、 Full-text, exact-match, range, and hybrid search on Amazon ElastiCache を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

本記事は 2026 年 5 月 7 日に公開された “ Valkey turns two ” を翻訳したものです。 2 年前、 Valkey は、Redis に対する真にオープンでベンダーニュートラルな代替手段の必要性に応えるコミュニティ主導の取り組みとして誕生しました。本記事では、この 2 年間の歩みを振り返り、Valkey の急速な普及、コミュニティによってもたらされたイノベーション、そしてこれらの発展がモダンなキャッシングおよびリアルタイムデータ基盤の未来にとって何を意味するのかをご紹介します。わずか 2 年という短い期間で、Valkey はほぼすべての主要なクラウドプロバイダーやオープンソースディストリビューションにおけるデフォルトの高性能キーバリューデータストアとなり、キャッシング分野におけるコミュニティ主導のイノベーションの中心的存在となりました。Valkey は Docker の累計プル数 1 億回を突破し (前年比 17 倍)、225 名を超えるコントリビューターを集め、1,500 件以上のプルリクエストが提出されています。これは同時期の Redis の開発ペースのおよそ 2 倍に相当します。 この勢いは、強力なイノベーションのフライホイールを生み出しています。クラウドプロバイダー、企業、開発者全体で採用が拡大するにつれ、Valkey オープンソースエコシステム全体からの貢献により、セキュリティ、信頼性、パフォーマンス、コスト効率、および高度な機能の改善が推進されてきました。これらの改善により、本番環境で 最大 60% 優れた価格性能比 や、全文検索、集計、ベクトル類似性、Bloom フィルターなどの高度な機能を利用できるようになるといった、目に見える形での向上が実現しています。こうした強化により、何万もの Amazon ElastiCache のお客様が数十万のクラスターを Valkey に移行しています。Intuit、Airbnb、Nextdoor、Tinder、Peloton、Amazon Ads、Amazon Music といった 組織 は現在、最もレイテンシーに敏感でビジネスクリティカルなシステムの一部を Valkey に依存しています。 このイノベーションのフライホイールは、Valkey のオープンガバナンスとコミュニティ主導の開発モデルによって実現されています。組織が Valkey を採用し、大規模に運用するにつれ、その実世界での経験がコントリビューション、ベンチマーク、運用フィードバックを通じてプロジェクトに直接還元されます。これにより、Valkey エコシステム全体のイノベーションのペースが加速します。 「Valkey が注目に値するのは、1 億回の Docker プルや 2 万 5,000 を超える GitHub スターといった目を引く数字ではなく、その背後にいるコミュニティです。Ericsson、ByteDance、Intel、Salesforce、Snap、その他数十の組織に所属する多様な開発者たちが、ほぼすべてのクラウドプロバイダーと共に Valkey を構築しています。コミュニティ主導のガバナンスによるこのような幅広いオープンなコラボレーションこそが、長期的に見て最高のテクノロジーが生み出される方法なのです。」 — Matt Wilson、AWS 副社長兼主席エンジニア キャッシュ・ミー・イフ・ユー・キャン: Valkey の採用 Valkey の成長は、利用状況の指標だけでなく、その周りに形成されているエコシステムの広がりにも表れています。わずか 2 年で、Valkey は新しいオープンソースプロジェクトから、キャッシング、リアルタイムデータアクセス、検索、人工知能 (AI) ワークロードのために広くサポートされる基盤へと進化しました。クラウドプロバイダー、商用サービスプロバイダー、アプリケーションフレームワーク、業界全体の開発者コミュニティが参加しています。 このエコシステムには現在、 AWS 、 Google 、 Alibaba 、 Oracle 、 Tencent 、 DigitalOcean といったクラウドプロバイダーからの 10 を超えるマネージド Valkey サービスが含まれています。 Percona 、 Aiven 、 Momento などのサービスプロバイダーや商用ディストリビューターは、このプロジェクトを中心としたマネージドサービス、エンタープライズサポートモデル、付加価値の高いサービスを構築しています。アプリケーション層では、 Spring Data Valkey や Laravel といったフレームワークが Valkey のサポートを追加しています。 LangChain 、 Haystack 、 Cognee 、 Recall などの AI および大規模言語モデル (LLM) フレームワークでは、ベクトルストレージ、検索、エージェントメモリ用の Valkey 統合が導入されました。これらの統合により、Valkey は高性能キャッシュとしての役割から、最新のリアルタイムおよび AI アプリケーションのコアデータ層へと、その役割を拡大しています。 Amazon ElastiCache における Valkey の採用も、業界全体の同様の勢いを反映しています。 ElastiCache の最大規模の顧客 による実際の本番環境でのデプロイは、Valkey が今日稼働しているスケールを示しており、極めて高いスループット、低レイテンシー、継続的な可用性を求められるインターネット規模のアプリケーションを支えています： Intuit は、重要なアイデンティティワークロードを ElastiCache for Valkey にアップグレードした結果、ダウンストリームのサービスコールを最大 80% 削減し、レイテンシを約 95% 改善したことを報告しています。 Sanoma は、人間のモデレーターによる判断のオーバーライドをベクトルとして保存することで、ニュースブランド全体で AI 支援によるコメントモデレーションを改善するために ElastiCache for Valkey を活用しています。現在、コメントの 30% が過去のモデレーター判断と照合されており、全ケースの 6.5% でそのコンテキストが直接 AI の判断を変更し、モデルの再学習や別途ベクトルデータベースを運用することなく、精度を向上させています。 Tinder は、Amazon ElastiCache の低レイテンシ性能を活用して、毎日数十億のユーザーアクションを処理し、世界規模のデーティングプラットフォーム全体でリアルタイムインタラクションをサポートしています。 Peloton は、ElastiCache を活用してライブリーダーボードを稼働させ、世界中のライダーがサブミリ秒の更新でリアルタイムに競い合えるようにしています。 Amazon Ads は、Sponsored Products 広告プラットフォームを稼働させるために ElastiCache for Valkey を使用しています。このシステムは、数百ノードに及ぶクラスターを運用し、1 日あたり数十億の広告インプレッションを配信しながら、毎秒数千万のリクエストを処理しています。この規模であっても、グローバルインフラストラクチャ全体で p99 レイテンシ 5 ms 未満、99.99% の可用性を維持しています。 Nextdoor は、800 以上のノードを Valkey にアップグレードすることで、地域コミュニティ向けソーシャルプラットフォームを稼働させながら運用コストを削減しました。 「組織がミッションクリティカルなワークロードをグローバル規模で実行するために採用する中で、Valkey のようなプロジェクトがこれほど急速に勢いを増していくのを見るのは非常に刺激的です。エンジニアリングの専門知識と運用経験をコミュニティに還元することで、エコシステム全体のイノベーションを加速させています。お客様は、パフォーマンス、信頼性、機能の改善がより速いペースで進むことから恩恵を受けています。」 — G2 Krishnamoorthy, AWS データベース担当バイスプレジデント 勢いの背景にある取り組み 急速な普及に呼応するように、急速なイノベーションも進んでいます。Valkey コミュニティ全体の組織からの貢献により、パフォーマンス、信頼性、コスト効率、機能性において数多くの改善が生まれています。プロジェクト開始以来、225 名を超える貢献者が 1,500 件以上のプルリクエストを提出しました。これは、同時期の Redis における開発ペースと比較して、アクティブな貢献者数とマージされたプルリクエスト数の両方でほぼ 2 倍にあたります。この急速なペースは、従来の単一ベンダーによる開発モデルを上回るオープンソースコラボレーションの力を示しています。 世界をリードするテクノロジー企業の多くがこのプロジェクトに積極的に貢献しており、ByteDance、Intel、Salesforce、Snap などの組織に加え、ほぼすべての主要なクラウドプロバイダーが参加しています。開発のペースは、各組織が共通して依存するコアインフラストラクチャの改善に共同投資する、オープンで業界全体の協力モデルの強さを反映しています。しかし、数字よりも重要なのは、コミュニティが構築しているものがもたらすインパクトです。2 年間にわたるイノベーションを 1 つの投稿で完全に伝えることは困難ですが、以下のハイライトは、この成長を続けるコミュニティから生まれたいくつかのイノベーションを示しています。これらには、最近 Amazon ElastiCache での一般提供が発表された Valkey 9 の最新のイノベーションが含まれます (詳細は別の ブログ投稿 をご覧ください)。 パフォーマンス Valkey 9 は、インメモリデータストアの可能性の限界を押し広げ続けています。パフォーマンスの向上には、パイプライン化されたコマンドのメモリプリフェッチによる 最大 40% のスループット向上 、 ゼロコピーレスポンス による最大 20% のスループット向上、そして Multipath TCP による最大 25% のレイテンシー削減が含まれます。これらの改善は、Valkey 8 で導入された 再設計された I/O スレッディングアーキテクチャ による最大 230% のスループット向上および最大 70% のレイテンシー改善といった、以前の Valkey のパフォーマンス改善の上に積み重ねられています。ElastiCache はまた、 Amazon ElastiCache Serverless でキャッシュあたり毎秒最大 500 万リクエスト を達成しました。しかし、パフォーマンスは実環境下で予測可能であり続けてこそ意味があります。このため、Valkey コミュニティは、大規模環境で一貫した信頼性につながるパフォーマンス向上の提供に多大な投資を行ってきました。 信頼性 信頼性の改善は、実際の本番環境においてレイテンシーを予測可能に保ち、復旧を高速にすることに重点を置いています。最近の Valkey リリースでは、P99 レイテンシースパイクを削減する Active Defragmentation の改善 と、プライマリへのメモリ負荷を軽減しながら完全同期時間を最大 50% 短縮できる デュアルチャネルレプリケーション が導入されました。 TLS フル同期の最適化 により、同期速度は最大 18% 向上します。これらの強化により、お客様がより大規模で要求の厳しい本番環境ワークロードを実行する際にも、レイテンシーを予測可能に保ち、復旧を高速に維持できます。 コスト効率 Valkey 9 では、クラスターモードにおける numbered databases (番号付きデータベース) の対応により、コスト効率がさらに向上します。チームは、ネームスペースごとに個別のインフラストラクチャを過剰にプロビジョニングする代わりに、同じ分散クラスター内でアプリケーション、テナント、または環境を論理的に分離できます。これらの改善は、Valkey 8 および 8.1 におけるコアデータ構造の最適化など、これまでの Valkey の効率性向上の上に構築されており、 ElastiCache の Redis OSS と比較して最大 60% 優れた価格対性能 を実現できます。その結果、クラスターは小さくなり、インフラストラクチャコストは低減し、成長のための余裕が広がります。コアエンジンがより効率的になることで、Valkey はより少ないインフラストラクチャで大規模なワークロードを実行できるよう支援し、従来のキャッシュを超えた新しいカテゴリのアプリケーションへも拡張し続けます。 新機能 Amazon ElastiCache 上の Valkey 9 を利用することで、お客様は最新の Valkey search 機能にアクセスできます。これは、以前に追加されたベクトル検索を拡張し、 フルテキスト検索、サーバーサイド集計 、ハイブリッドクエリを提供することで、リアルタイム検索、セマンティック検索、フィルタリング、分析をキャッシュ内で直接実行可能にします。これらの機能により、お客様はマイクロ秒レベルのレイテンシーと毎秒数百万リクエストのスループットで、継続的に更新されるテラバイト規模のデータを検索および分析できます。ユースケースには、商品カタログ検索、ドキュメント探索、レコメンデーションシステム、異常検知、ログ分析、会話メモリ、検索拡張生成 (RAG) などがあります。 Valkey 9 では ハッシュフィールドの有効期限 も導入され、ハッシュ内の個々のフィールドに対してきめ細かい TTL 制御が可能になります。これにより、キー全体を一度に失効させたり、アプリケーション側に有効期限のロジックを追加したりする必要がなくなります。これらの革新的な機能は、Bloom フィルター、JSON サポート、LDAP 統合、地理空間ポリゴンクエリなど、最近の Valkey エンジンのリリースおよびモジュールに追加された他の機能の上に構築されています。 私たちの主要な価値観に基づいた構築 過去 2 年間における Valkey の急速な普及は、業界規模でのオープンなコラボレーションの力を示しています。開発者による広範な利用、クラウドプロバイダーやテクノロジー企業からの幅広い参加、そして中立的なオープンガバナンスが、強力なフライホイールを生み出しました。より多くの組織が Valkey を本番環境にデプロイするにつれて、その運用経験が直接プロジェクトにフィードバックされ、パフォーマンス、信頼性、スケーラビリティ、コスト効率の継続的な改善を推進しています。 数十万のクラスターと、世界で最も要求の厳しいリアルタイムアプリケーションで Valkey を運用することで、イノベーションの新たな機会が次々と生まれています。Valkey のオープンソースエコシステム全体からの貢献により、コアエンジンが強化されるとともに、開発者が構築できる範囲が拡大しています。ユースケースは現在、従来のキャッシュやセッション管理から、リアルタイム分析、検索、AI 駆動型ワークロードにまで広がっています。 開発者、運用者、そしてあらゆる規模の組織の皆様に、Valkey の GitHub や Slack でのご参加をお待ちしております。コードの貢献、フィードバックの提供、本番環境での Valkey の採用など、形式は問いません。最新のイノベーションは Valkey のブログ でご覧いただけます。また、世界中のコントリビューターやユーザーが集う、今後の コミュニティイベント や技術セッションへのご参加もお待ちしております。 2 年が経過し、 Valkey は、オープンでコミュニティ主導のテクノロジーが、単一ベンダーモデルよりも迅速にイノベーションを起こし、より大きくスケールし、より多くの価値を提供できることの証となっています。この旅はまだ始まったばかりです。 著者について Mas Kubo Mas は、AWS のインメモリデータベースチームのプロダクトマネージャーで、Amazon ElastiCache のオープンソース高性能データストアエンジンである Valkey に注力しています。仕事以外では、フリーダイビング、パラグライディング、カイトサーフィン、セーリングを通じて風と海を追いかけています。 Meet Bhagdev Meet は AWS のシニアマネージャー PMT-ES です。Amazon ElastiCache および Amazon MemoryDB のプロダクトマネジメントチームを率いています。Meet はオープンソース、データベース、分析に情熱を持ち、お客様の要件を理解し、優れた体験を構築するために時間を費やしています。 Madelyn Olson Madelyn は Valkey プロジェクトのメンテナーであり、Amazon ElastiCache および Amazon MemoryDB のプリンシパルソフトウェア開発エンジニアです。Valkey エンジンの安全で信頼性の高い機能の構築に注力しています。余暇には、長いハイキングや穏やかなサイクリングを通じて、太平洋岸北西部の自然の美しさを楽しんでいます。 本記事は、 Valkey turns two を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

本記事は 2026 年 5 月 7 日に公開された “ Announcing Valkey 9.0 for Amazon ElastiCache ” を翻訳したものです。 Amazon ElastiCache が Valkey 9.0 をサポートするようになりました。これにより、Valkey オープンソースプロジェクトのコミュニティ主導による最新のイノベーションが提供され、リアルタイム分析、AI 駆動の検索、高スループットキャッシングなど、データ集約型かつレイテンシーに敏感なアプリケーションのパフォーマンスと機能要件に対応できるようになります。たとえば、キャッシュに加えて別途検索インフラストラクチャを運用することは、コストとレイテンシーを増加させます。大量のパイプラインワークロードはスループットの上限に達し、オーバープロビジョニングを強いられます。キャッシュされたオブジェクト内の個々のフィールドのライフサイクルを管理するには、キーの乱立を引き起こす回避策が必要です。さらに、クラスターモードのマルチテナントアーキテクチャでは、複雑なキープレフィックス方式が必要となり、アプリケーションコードや移行が複雑化します。 Valkey 9.0 は、これらの課題に直接対応します。組み込みの全文検索およびハイブリッド検索により独立した検索システムを削減または不要にでき、エンジンレベルの最適化によってパイプライン処理ワークロードで最大 40% のスループット向上を実現し、ハッシュフィールドの有効期限機能できめ細かなデータライフサイクル管理を可能にし、さらにクラスターモードを有効にしたデプロイメントでマルチデータベースをサポートします。本投稿では、これらの機能強化がどのようにお客様のアプリケーションの高速化、アーキテクチャの簡素化、そして新しいリアルタイムや AI 駆動型ワークロードのサポートに役立つかを解説します。 Valkey は最近 2 周年を迎え、Docker プル数は 1 億回を超え、ほぼすべての主要クラウドプロバイダーで広く採用されており、エコシステムの勢いも加速しています。Valkey 9.0 は、AWS のお客様に向けてそのイノベーションのペースを継続しています。詳細は、別途公開している Valkey が 2 周年を迎えました の記事をご覧ください。Valkey は、高性能でベンダー中立なインメモリデータストアを求める開発者にとって、主要なオープンソースの選択肢として急速に存在感を高めています。 Amazon ElastiCache のお客様 は、すでに Valkey を広く採用し、キャッシング、セッションストア、リアルタイム分析、キュー、そしてますます増加する AI アプリケーションに活用しています。Valkey 9.0 により、お客様はパフォーマンス、機能、運用の柔軟性に焦点を当てた新たなイノベーションの波を享受できます。 キャッシュ内で実現するリッチな検索体験の構築 Valkey 9.0 は、 valkey-search オープンソースプロジェクトの最新の検索イノベーションを ElastiCache にもたらします。これにより、テラバイト規模のデータに対して、リアルタイムの全文検索、セマンティック検索（意味検索）、フィルタリング、集計を、マイクロ秒レベルのレイテンシと毎秒数百万リクエストに達するスループットで、キャッシュ内で直接実行できます。昨年、Amazon ElastiCache for Valkey にベクトル検索を導入し、お客様はセマンティックキャッシングワークロードにおいて、AWS 上の主要なベクトルデータベースの中で 95% のリコール率で最も低いレイテンシと最も高いスループットを達成できるようになりました。Valkey 9.0 はその基盤の上に、全文検索、集計パイプライン、そしてテキストの関連性とベクトル類似性を組み合わせたハイブリッドクエリを追加しました。これらは、Amazon Bedrock、Amazon SageMaker AI、Anthropic、OpenAI などのプロバイダーから提供される数十億のエンベディングに対して機能し、完了した書き込みを反映した結果を返します。 これにより、製品カタログ検索、ドキュメント検索、セマンティック検索、レコメンデーションシステム、異常検出やログ分析、会話履歴、そして Retrieval Augmented Generation (RAG) アーキテクチャといったユースケースを ElastiCache 内で直接サポートできます。継続的に更新されるデータに対して、ベクトル、テキスト検索、集計を 1 つのエンジンで組み合わせることで、多くのワークロードでは別途検索インフラを運用する必要を削減または排除できます。詳細については、 Amazon ElastiCache での集計機能のお知らせ および Full-Text, Exact-Match, and Range Search on Amazon ElastiCache の投稿をご覧ください。 パイプライニングを使用してスループットを最大 40% 向上 Valkey 9.0 では、エンジンレベルの最適化が導入され、パイプライニング使用時に最大 40 パーセント高いスループットを実現できます。これには、コマンド解析の高速化、メモリプリフェッチの改善、バッチリクエストのより効率的な処理が含まれます。CPU ストールを削減し、最新のプロセッサアーキテクチャをより有効に活用することで、パイプライン化されたワークロードは、より少ないオーバーヘッドで 1 秒あたりにより多くの操作を処理できます。高トラフィックの API、イベント処理システム、ゲームのリーダーボード、広告テクノロジープラットフォーム、マイクロサービスなど、コマンドをバッチ処理するアプリケーションでは、ノードを追加することなくスループットを向上できます。すでにパイプライニングを使用しているお客様は、Valkey 9.0 にアップグレードすることでメリットを得られます。パイプライニングの詳細と使い始め方については、 Valkey パイプライニングのドキュメントページ を参照してください。 ハッシュフィールドの有効期限 Hash field expiration は、キー全体を期限切れにするのではなく、ハッシュ内の個別フィールドに TTL を適用する機能を追加します。これにより、複雑なオブジェクトに対してより精密なライフサイクル管理が可能になります。例えば、ユーザープロファイルを保持したまま 1 回限りの認証コードを期限切れにする、個別のセッション属性を期限切れにする、レコードの他の部分を保持しながら古くなったカウンターやメタデータを自動的に削除するといったことが挙げられます。これにより、キーの乱立を減らし、アプリケーションロジックを簡素化できます。 クラスターモードを有効化したデプロイメントでのマルチテナントワークロードの実行 クラスターモードでの 番号付きデータベース により、Valkey 9.0 はより強力な分離と効率的なインフラストラクチャでマルチテナントワークロードを実行することを支援します。番号付きデータベースは軽量な名前空間として機能し、同じキー名がキーの衝突や複雑なプレフィックススキーマなしに別々の論理データベース内で共存できるようにします。これにより、SaaS アーキテクチャなどのマルチテナントワークロードを効率化でき、各テナントや環境が独自のデータベースを使用でき、すべてのキーに埋め込まれたテナントプレフィックスを回避することでアプリケーションの複雑さを軽減できます。 この機能は、すでに複数のデータベースに依存しているスタンドアロン環境からの移行を効率化し、分散アーキテクチャへの移行時のリファクタリング作業を削減するのにも役立ちます。一般的なユースケースには、開発、テスト、本番ワークロードの分離、顧客データセットの分離、レガシーアプリケーションの前提条件の維持、同一クラスター上でのデータ移行のステージングや A/B テストシナリオの実施などがあります。 データはクラスター全体に分散されたままとなるため、お客様は論理的な分離と、クラスターモードを有効化した ElastiCache デプロイメントによるスケール、パフォーマンス、可用性のメリットを組み合わせることができます。詳細については、Valkey の番号付きデータベースに関する記事と ElastiCache のドキュメントをご参照ください。 地理空間インデックスのポリゴンクエリ Valkey 9.0 では、 地理空間インデックスに対するポリゴンクエリ により、地理空間検索が拡張されました。半径検索やバウンディングボックス検索に加えて、アプリケーションは GEOSEARCH に BYPOLYGON オプションを指定して、任意のポリゴンの内部にあるメンバーを検索できるようになりました。これにより、配送エリア、サービス提供区域、近隣地域、ジオフェンス、会場、キャンパス、運用地域などの実世界の境界をモデル化しやすくなります。位置情報を活用するアプリケーションは、複数の半径クエリやボックスクエリで不規則な領域を近似したり、そのロジックを別の地理空間システムに委ねたりすることなく、Valkey 内で直接、より正確なフィルタリングが可能になります。 まとめ Valkey 9.0 の機能強化により、ますます要求が高まるリアルタイムおよび AI 駆動型ワークロードを支えるために必要なパフォーマンス、検索機能、運用上の柔軟性が提供され、それらの背後にあるアーキテクチャを簡素化します。Amazon ElastiCache の Valkey 9.0 は、本日よりすべての AWS リージョンで追加費用なしでご利用いただけます。ElastiCache で Valkey 9.0 を使い始めるには、以下の方法があります: 初めての Valkey 9.0 キャッシュを作成する: ElastiCache 入門チュートリアル を参照して、数分で新しいキャッシュを起動してください。 既存のクラスターをアップグレードする: アップグレードドキュメント に従って、任意の Redis OSS または Valkey バージョンから Valkey 9.0 へ、ダウンタイムなしで数分でアップグレードできます。 動作上の変更が最小限 であるため、ほとんどのワークロードではアップグレードにアプリケーションの変更は必要ありません。 既存のセルフホスト型ワークロードを ElastiCache に移行する: ElastiCache の オンライン移行 機能を使用して、Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフホスト型のオープンソース Valkey または Redis OSS から Amazon ElastiCache へデータを移行できます。Valkey 9.0 で導入されたすべての新機能は Redis OSS とドロップイン互換であるため、ほとんどのワークロードはアプリケーションの変更なしで ElastiCache 上の Valkey 9.0 へ移行できます。 新機能を試す: ElastiCache の Valkey 9.0 で導入された新機能を試すには、 Valkey Search 、 ハッシュフィールドの有効期限 、 番号付きデータベース のドキュメントをご覧ください。 著者について Mas Kubo Mas は AWS の In-Memory Databases チームのプロダクトマネージャーで Amazon ElastiCache 向けのオープンソース高性能データストアエンジンである Valkey を担当しています。仕事以外では、フリーダイビング、パラグライディング、カイトサーフィン、セーリングを通じて風と海を追いかけています。 本記事は、 Announcing Valkey 9.0 for Amazon ElastiCache を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。