本ブログは 2025 年 10 月 21 日に公開された AWS Blog “ The attendee guide to digital sovereignty sessions at AWS re:Invent 2025 ” を翻訳したものです。 AWS re:Invent 2025 は、 Amazon Web Services (AWS) が主催する最高峰のクラウドコンピューティングカンファレンスで、2025 年 12 月 1 日から 5 日までネバダ州ラスベガスで開催されます。このフラッグシップイベントでは、世界中のクラウドコミュニティが一堂に会し、複数の会場で学習、コラボレーション、イノベーションに没頭できる 1 週間を体験できます。クラウドエキスパート、ビジネスリーダー、テクノロジー愛好家など、どなたであっても、re:Invent は最先端のクラウドソリューションを探求し、AWS のエキスパートと交流し、世界中の仲間と貴重なつながりを築く比類のない機会を得られます。 技術的な深掘りから戦略的なビジネスセッションまで、re:Invent 2025 は最先端のクラウドテクノロジーを理解し活用するための入口です。 Expo では、AWS Village のデジタル主権とハイブリッドクラウドのキオスクを訪れて、今後提供される AWS European Sovereign Cloud やその他のデジタル主権ソリューションについて学び、AWS のエキスパートに質問できます。 クラウド業界の最新イノベーションを発見し、技術的な深い洞察を得て、デジタル主権のためにクラウド投資を最適化する方法を学びましょう。今年のセッションでは、 AWS Nitro System の強化されたセキュリティ機能、拡大するデジタル主権ソリューションのポートフォリオ、 AWS European Sovereign Cloud の最新開発など、AWS のデジタル主権に対応した設計アプローチを包括的にカバーします。デジタル主権への関心が高まる中、AWS がどのようにソブリンクラウドソリューションでイノベーションを続け、お客様がクラウドの全機能を活用しながらデータの管理を維持できるようにしているかをご覧ください。 今すぐセッションの参加を登録 して、参加者ポータルまたは AWS Events モバイルアプリにサインインすることで、学習パスをカスタマイズできます。 ブレイクアウトセッションとコードトーク AWS re:Invent のアジェンダにセッションを追加し、時間と場所の情報を確認するには、セッションタイトルのリンクを選択してください。 セキュリティトラック SEC201 | ブレイクアウトセッション | AWS European Sovereign Cloud: From concept to reality (AWS European Sovereign Cloud: コンセプトから現実へ) Colm MacCárthaigh、VP/Distinguished Engineer – EC2 Networking、AWS、Addy Upreti、Principal Technical Product Manager – EC2 Core Product Management、AWS AWS European Sovereign Cloud を直接ご確認ください。この新しい独立したインフラストラクチャの専用アーキテクチャ、EU ベースの運用管理、このクラウドを支える運用管理とガバナンスおよび法的フレームワークを探求します。このクラウドソリューションがどのようにヨーロッパ内で完全に構築、運用、保護されているかを学びます。 クラウドオペレーショントラック COP409 | コードトーク | Building Sovereign Cloud Environments (ソブリンクラウド環境の構築) Bo Lechangeur、Pr. Delivery Engineer – STCE、AWS、Randy Domingo、Sr. Software Development Manager – STCE、AWS 組織がグローバルに事業を拡大する中で、進化するデータレジデンシー、セキュリティ、コンプライアンス、事業継続性の要件を満たす必要があります。このセッションでは、 AWS Control Tower と Landing Zone Accelerator on AWS が、国固有のコンプライアンスフレームワーク、リージョンサービスの選択、データ移動の自動制御、越境データ転送など、主要なデジタル主権要件をどのようにサポートするかを探ります。実際の例を通じて、組織が AWS を活用して国固有のセキュリティ制御を実装し、マルチリージョンデプロイ全体で運用の一貫性を維持し、クラウドコンプライアンスを加速し、セキュリティとコンプライアンスを大規模に自動デプロイする方法を示します。 ハイブリッドクラウドとマルチクラウドトラック HMC202 | ブレイクアウトセッション | AWS wherever you need it: From the cloud to the edge (必要な場所で AWS を: クラウドからエッジまで) Spencer Dillard、Director, Software Development – EC2 Edge、AWS、Madhura Kale、Senior Manager, Technical Product Management – EC2 Core、AWS ほとんどのワークロードはクラウドに移行できますが、低レイテンシー、ローカルデータ処理、デジタル主権のニーズにより、一部はオンプレミスまたはエッジに残ります。このセッションでは、AWS Outposts、AWS Local Zones、AWS 専有ローカルゾーン、AWS IoT などの AWS サービスが、マルチプレイヤーゲーム、高頻度取引、医療画像、スマートマニュファクチャリング、データレジデンシー要件を持つ生成 AI アプリケーションなどのハイブリッドクラウドとエッジコンピューティングワークロードをどのようにサポートするかを学びます。 HMC308 | ブレイクアウトセッション | Build generative and agentic AI applications on-premises and at the edge (オンプレミスとエッジでの生成 AI およびエージェンティック AI アプリケーションの構築) Chris McEvilly、Senior Solutions Architect – Hybrid Edge、AWS、Pranav Chachra、Principal Technical Product Manager – EC2 Core、AWS、Fernando Galves、Senior Solutions Architect – Generative AI、AWS お客様が生成 AI とエージェンティック AI の実装をパイロットから本番環境にスケールする際、イノベーションのスピードとデータ主権要件、低レイテンシーのエッジ処理ニーズ、スペース、電力、コスト効率のバランスを取る必要があります。このセッションでは、AWS Local Zones、AWS Outposts、AWS 専有ローカルゾーンを使用して生成 AI とエージェンティック AI ソリューションを構築する方法を探ります。分散ロケーション全体に基盤モデルをデプロイするためのアーキテクチャパターンとベストプラクティスを発見してください。ローカルに保存されたデータを使用した Retrieval Augmented Generation (RAG) の実装方法を学びます。モデル選択と最適化の戦略に関する洞察を得ます。 HMC310 | ブレイクアウトセッション | Digital sovereignty and data residency with AWS Hybrid and Edge services (AWS ハイブリッドおよびエッジサービスによるデジタル主権とデータレジデンシー) Mallory Gershenfeld、Senior Technical Product Manager – S3、AWS、Ben Lavasani、Senior Specialist – Hybrid and Edge、AWS、Majd Aldeen Masriah、Director of Enterprise – Architecture、Geida 世界中の国々で、少なくとも 1 つのコピー、または場合によってはすべてのデータを特定の地理的またはソブリンな場所に保存または処理することを要求するデータレジデンシーとデジタル主権に関する法律が導入または更新されており、お客様に新たな課題をもたらしています。このセッションでは、AWS 専有ローカルゾーン、AWS Local Zones、AWS Outposts などの AWS サービスが、デジタル主権のユースケースにどのように役立つかを探ります。エッジでのデプロイ全体におけるデータレジデンシー、セキュリティ制御、運用の一貫性のベストプラクティスを検討します。 インタラクティブセッション (チョークトークとワークショップ) セキュリティトラック SEC301 | チョークトーク | Architecting for Digital Sovereignty: From Foundation to Practice (デジタル主権のためのアーキテクチャ設計: 基礎から実践まで) Eric Rose、Principal Security SA – Global Services Security、AWS、Armin Schneider、Digital Sovereignty Specialist SA – Global Services Security Digital Sovereignty セキュリティの基礎とクラウドにおけるデジタル主権の実装のための実践的なアーキテクチャ戦略を橋渡しするこのチョークトークにご参加ください。アラブ首長国連邦サイバーセキュリティ評議会や今後提供される AWS European Sovereign Cloud の実例を通じて、組織が AWS のデジタル主権機能を効果的に活用する方法を探ります。データレジデンシー、運用管理、お客様がデータを完全に管理できるようにするセキュリティ対策のための実践的なアーキテクチャパターンを取り上げます。クラウドアーキテクトやセキュリティチームに最適なこのセッションでは、政府機関や企業のデプロイ事例を用いて、デジタル主権要件とクラウドの利点のバランスを取るソリューションを設計する方法を紹介します。 ハイブリッドクラウドとマルチクラウドトラック HMC301 | ワークショップ | Build and operate resilient and performant distributed applications (耐障害性と高性能な分散アプリケーションの構築と運用) Saravanan Shanmugam、Senior Solutions Architect – Hybrid Edge、AWS、Sedji Gaouaou、Senior Solutions Architect – Networking、AWS このワークショップでは、データレジデンシーとパフォーマンス要件を満たしながら、マルチジオ運用のためのアプリケーションを設計および実装する方法を探ります。限られたハードウェアリソースで分散ロケーション全体にわたる耐障害性とレイテンシーに敏感なアプリケーションを設計する方法を学びます。また、分散ハイブリッドアーキテクチャ、エッジネットワーキングの実装、規制要件と高可用性ニーズのバランスを取るトラフィック管理ソリューションを探ります。分散ロケーション全体でデータ主権を維持しながらパフォーマンスを最適化するための実践的な戦略を学びましょう。 HMC302 | ワークショップ | Implementing agentic AI solutions on-premises and at the edge (オンプレミスとエッジでのエージェンティック AI ソリューションの実装) Fernando Galves、Senior Solutions Architect – Generative AI、AWS、Kyle Palasti、Senior Solutions Architect – Hybrid Edge、AWS 政府機関や標準化団体がデータ保護とプライバシー規制を策定する中、組織はクラウドでの生成 AI ツールの使用と、データレジデンシー要件を満たすためにオンプレミスに保持する必要がある規制対象データを組み合わせる必要性が高まっています。このワークショップでは、 Amazon Bedrock AgentCore を AWS Outposts や AWS Local Zones などのハイブリッドおよびエッジサービスに拡張し、Model Context Protocol (MCP) とエージェント間 (A2A) 通信を使用してオンプレミスデータで分散エージェンティックアプリケーションを構築し、モデルの結果を改善する方法を学びます。Amazon Bedrock と Strands Agents を使用したハイブリッドエージェンティック AI を実際に体験しながら、AWS のハイブリッドおよびエッジサービスを探求してください。 HMC305 | ワークショップ | Low-latency SLM deployment: Optimizing inference on AWS Hybrid and Edge Services (低レイテンシー SLM デプロイ: AWS ハイブリッドおよびエッジサービスでの推論の最適化) Leonardo Solano、Principal Solutions Architect – Networking & Hybrid Edge、AWS、Obed Gutierrez、Senior Solutions Architect、AWS このハンズオンワークショップでは、AWS Local Zones と AWS Outposts を使用してエッジで Small Language Model (SLM) を実行するための完全なローカルデプロイアプローチを実演します。この実装は、低レイテンシー推論の実現と、ローカルインフラストラクチャ内での Retrieval Augmented Generation (RAG) アプリケーションを通じたデータ主権コンプライアンスの実現に焦点を当てています。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと公開されているモデルを使用して、エッジ環境で SLM をデプロイ、最適化、管理する方法を学びます。本番環境シナリオにおける厳格なレイテンシーとデータレジデンシー要件を満たすために、RAG システムと言語モデルがローカルで動作することを確認します。 HMC312 | チョークトーク | Implement RAG while meeting data residency requirements (データレジデンシー要件を満たしながら RAG を実装する) Lakshmi VP、Solutions Architect、AWS、Akshata Ketkar、Senior Product Manager – EC2 Edge、AWS 政府機関がデータ保護とプライバシー規制を策定する中、組織はデータ主権要件を満たすためにオンプレミスに保持する必要がある規制対象データで生成 AI を活用する必要性が高まっています。このセッションでは、オンプレミスおよびエッジデータで Retrieval Augmented Generation (RAG) を実装する方法を探ります。ハイブリッド RAG アーキテクチャのために Amazon Bedrock AgentCore を AWS Outposts と AWS Local Zones に拡張する方法、またはより厳格なデータレジデンシー要件のためにローカル RAG アーキテクチャを構築する方法を学びます。モデルサイズを増やすことなく精度を向上させ、推論コストを削減し、プロンプトの結果に対するガバナンスと制御を強化するための、リランカーモデルなどの最新技術を発見してください。 HMC314 | チョークトーク | Deploying for resilience: HA/DR strategies for AWS Outposts and Local Zones (耐障害性のためのデプロイ: AWS Outposts と Local Zones の HA/DR 戦略) Afaq Khan、Senior Product Manager – EC2 Edge、AWS、Brianna Rosentrater、Senior Solutions Architect – Hybrid Edge、AWS エッジでのミッションクリティカルなワークロードには、堅牢な高可用性 (HA) とディザスタリカバリ (DR) 戦略が必要です。このチョークトークでは、AWS のハイブリッドクラウドおよびエッジコンピューティングサービスを使用して、回復力のあるデプロイを計画および実装する方法を学びます。AWS Local Zones と AWS Outposts を使用したエッジインフラストラクチャのアーキテクチャ設計方法を検討し、ネットワーキング、コンピューティング、ストレージの冗長性の主要な側面を取り上げます。実際のお客様の事例とリファレンスアーキテクチャを通じて、障害モード全体でビジネス継続性を維持するためのデプロイパターンとベストプラクティスを探ります。エッジデプロイで RPO/RTO 目標を達成するための実践的な戦略を学びましょう。 HMC403 | コードトーク | AI を活用したエッジアーキテクチャの構築と回復性の最適化 (AI による耐障害性のあるエッジアーキテクチャの構築と最適化) Jesus Federico、Principal Solutions Architect – Generative AI、AWS、Robert Belson、Senior Solutions Architect & Developer Advocate、AWS このライブコーディングセッションでは、AI を使用してエッジインフラストラクチャの運用を自動化する方法を探ります。最新の AWS Outposts と AWS Local Zones API を使用して、真に回復力のあるアーキテクチャを構築する方法を発見してください。Outposts のハードウェアインベントリのクエリ、インテリジェントなリソース配置の実装、フェイルオーバー設定の自動化に関する実際のコード例を紹介します。Amazon Bedrock がアーキテクチャパターンを分析し、最適なコンポーネント配置のための Infrastructure as Code (IaC) の推奨事項を生成する方法を学びます。API 統合、自動ヘルスチェック、動的リソース割り当ての実践的な手法に加えて、適応性の高い高可用性エッジソリューションを構築するための実用的なコードサンプルとデプロイテンプレートを持ち帰ることができます。 HMC316 | チョークトーク | Addressing digital sovereignty with hybrid cloud solutions (ハイブリッドクラウドソリューションによるデジタル主権への対応) Sherry Lin、Principal Product Manager – EC2 Core、AWS、Enrico Liguori、Solutions Architect – Networking、AWS 組織が革新的なソリューションをグローバルにスケールする際、複雑なデジタル主権要件に対応する必要があります。このセッションでは、規制要件を満たしながらグローバルなスケーリングを加速するために AWS がどのように役立つかを探ります。AWS Local Zones、AWS 専有ローカルゾーン、AWS Outposts、AWS European Sovereign Cloud に焦点を当てて、さまざまなソブリンインフラストラクチャオプションを比較します。デジタル主権のニーズに最適なオプションを選択し、データレジデンシーと回復性のためにアプリケーションを設計する方法を学びます。データの保存、処理、転送方法を規制し、不正なデータアクセスを防ぐためのセキュリティ制御を実装する方法を発見してください。 パートナーとのセッションを含むデジタル主権コンテンツの全体像については、 AWS re:Invent カタログ を参照し、デジタル主権の関心領域でフィルタリングしてください。直接参加できない場合は、 追加費用なしで提供されるバーチャル限定パスに登録 して、基調講演とイノベーショントークをライブストリーミングで視聴し、今すぐオンデマンドのブレイクアウトセッションにアクセスできます。ラスベガスまたはライブストリームでお会いしましょう! Brittany Bunch Brittany は、アトランタを拠点とする AWS セキュリティマーケティングチームのプロダクトマーケティングマネージャーです。デジタル主権に焦点を当てており、Amazon での雇用者ブランディングを含む 10 年以上のブランドマーケティング経験を持っています。AWS に入社する前は、いくつかの大規模エンタープライズ企業でブランドマーケティングイニシアチブを主導していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

このブログ記事は、フリー株式会社様 AI プロダクトマネージャー木佐森氏へのインタビュー内容をもとに、AWS ソリューションアーキテクトの福本が執筆し、フリー株式会社様が監修しています。 「スモールビジネスを、世界の主役に。」をミッションに掲げるフリー株式会社。創業時から「AI CFO」というビジョンを描いてきた同社は、LLM (Large Language Models、大規模言語モデル) 登場を機に、生成 AI を活用した AI ネイティブな組織への本格的な変革に乗り出した。技術選定、組織体制の構築、そして何より「成功基準」という独自のフレームワークを確立し、全社で AI 活用を推進。チャットサポートの解決率約 50% 向上、営業効率の劇的な改善、そして BPaaS (Business Process as a Service) 事業での構造改革など、着実に成果を積み重ねている。AI プロダクトマネージャーの木佐森氏に、その変革の全貌を聞いた。 「AI ネイティブ」を実現する組織づくりと取り組み 統合型経営プラットフォームとしてのビジョン ──まず、freee の事業概要と AI 活用の位置づけについて教えてください。 木佐森氏： freee は「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームを提供しています。単なる会計ソフトではなく、バックオフィス業務全般を統合し、経営を誰でもできるようにするプラットフォームを目指しています。 実は、freee の前身は 1 年だけ「CFO株式会社」という社名だったんです。これは「Chief Financial Officer」ではなく「Cloud Finance Officer」を意味しており、クラウドからあらゆるビジネスの CFO になれるサービスを作りたいという想いが込められていました。創業者の佐々木が描いていた将来像として「AI CFO」というコンセプトがあり、これが現在の AI 戦略の原点になっています。 この「自動化」という創業以来のビジョンが、LLM の登場によって大きく進展しました。私たちは今年から「AI ネイティブカンパニー」へのシフトを本格化させています。私たちにとって生成 AI、特に AI エージェントは、創業当初からの念願であった「自動化」を実現するためのラストワンマイルを埋めるものだと位置づけています。これまではシステム化が難しかったコミュニケーションや、導入・使いこなしといった非構造化された課題を AI が解決することで、スモールビジネスの皆様が特別なスキルを意識することなく、自然体でなめらかに業務を自動化できる。その世界の実現に向けて、全社で取り組みを加速させています。 AI ラボの組織体制：横串で支える専門家集団 ──freee では AI 活用をどのような組織体制で推進されているのですか？ 木佐森氏： AI ラボという横串組織で推進しています。ML (Machine Learning、機械学習) の専門性を持ったメンバーが集結し、縦串である各プロダクトチームに出向いて協働し、AI 機能を実装していくスタイルです。 LLM が登場する前は、OCR (Optical Character Recognition、光学的文字認識) や勘定科目の推定など、モデルを学習させる古典的な ML 中心でした。しかし LLM 登場後は役割が大きく変わりました。RAG（Retrieval-Augmented Generation、検索拡張生成）などの周辺開発や、各プロダクトへの「イネーブルメント活動」、そして LLM 基盤の整備など、活動範囲が広がっています。 今年に入って SLM (Small Language Models、小規模言語モデル) が注目され始め、ファインチューニングの重要性が再認識されたことで、ML 専門性の価値が再確認されました。領収書の読み取りなど、freee のコア機能においては、汎用モデルよりもタスクに特化した SLM をファインチューニングした方が精度が出る。実際にやってみると、精度向上に加えて、レスポンスが圧倒的に速く、コストも安い。適材適所で最適なモデルを使い分けることを重視しています。 ── なぜ freee さんが技術的かつ専門性的に難易度の高いファインチューニングに意欲的に取り組まれているのかと思っていたのですがお話を伺って、もともと機械学習の専門家チームがいて、そういう素養があったからこそ実現できたのだと理解できました。 技術とビジネスを繋ぐ：AI プロダクトマネージャーの役割 ──木佐森さんご自身は freee でどのような役割を担っているのか教えてください。 木佐森氏： 私は AI ラボに所属し、「AI プロダクトマネージャー」として活動しています。これは技術とビジネスの両面を理解した上で、AI 活用によるユーザー価値創出を推進する役割です。 私のバックグラウンドとしては、物理学で博士を取った後、機械学習アルゴリズムの研究に移り、企業で研究をしてきました。その後、自分で開発したアルゴリズムを事業化するために起業した経験もあります。この技術理解とビジネス視点の掛け算が、freee での AI 活用推進において活きていると思います。 具体的な役割は大きく 3 つあります。第一に、経営陣と密に連携して「解くべき課題」を定めること。技術的なフィージビリティを見極めながら、経営インパクトがある領域にピン止めしていく。第二にプレーヤーとしてその定めた領域の新規プロジェクトのゼロからイチを作ること。企画から初期のプロトタイピングまでを高速に行って蓋然性を示し、リリースまで走り抜ける。第三に、各プロダクトチームがボトムアップで始めた AI 活用案件に対して、レビュアーとして入り込み、成功基準の策定支援や評価方法のアドバイスを行うことです。 ──各チームの取り組みをどのようにサポートされているのですか？ 木佐森氏： いくつかの仕組みを並行して回しています。 まず「AI サロン」という場を作っています。数年前に比べるとだいぶ意識が変わってきましたが、プロダクト担当によっては、解きたい課題に対する手段としてAIが想起されるが、具体的な方法や進め方がわからないケースがあります。「壁打ちウェルカム、知識教えてあげるよ」という雰囲気でサポート活動をしています。 他にも、各プロダクトチームに対して、勉強会やハッカソンを実施してきました。AWS の方にご協力いただいた勉強会やハンズオンもありましたね。 また、属人化しないための工夫として、自分が考えたことや学んだことを丁寧に書き出して、ドキュメント化しています。社内では、そのドキュメントを食わせた LLM アプリを構築し、誰でも気軽に知見へアクセスできるようにしています。こうした仕組み化は、AI ラボのノウハウをスケールさせ、組織全体の AI リテラシーを引き上げるために不可欠です。 AI 活用の具体的成果 ──これまでの AI 活用でどのような成果が出ていますか？ 木佐森氏： いくつか代表的な事例があります。 まず、チャットサポートでの LLM 活用では、質問への解決率を約 50% 向上させました。これは 2023 年の早い段階から取り組んできた成果です。 セールス支援では、社内外の会議内容の自動要約から CRM への情報入力を行うAIシステム「つばめAUTO」を構築しました。このシステムでは、商談の事後処理時間を 45.2％、架電の事後処理時間を 56.2％ それぞれ削減できています。これによって営業の効率が大幅に向上し、今年の夏には Forbes の外部評価*もいただきました。 *Forbes JAPAN NEW SALES OF THE YEAR2025で「AIトランスフォーメーション賞」 また、AWS の 生成 AI 実用化推進プログラム で成果報告させていただいた「AI クイック解説」という機能もあります。これは財務データの分析を手助けする機能で、ジュニア層の場合は 月 10 時間以上、シニア層でも数時間の作業負荷軽減が期待できます。 他にも様々な施策に取り組んできました。現在最も力を入れているのが、BPaaS 事業を中心とした AI エージェントを使ったOCR 関連技術です。 成功を支える要因 最大の要因：経営層の深い理解とコミットメント ──こうした成果を生み出せた要因は何だと考えていますか？ 木佐森氏： これは迷わず答えられます。「経営トップの AI に対する理解とコミットメントが強い」ことです。 freee の経営陣は、技術バックグラウンドの有無にかかわらず、自分で AI を使うのはもちろん、AI コーディングのツールなどを使って自分で API を叩いて実装を試しています。CEO の佐々木に呼び出されて「これ Cline (AI コーディングツール) で作ったんだけど、なんか精度上がらないからどうしたらいい？」と相談されたこともあります（笑）。 この理解があるからこそ、AI を使うことの必然性や、むしろ危機感を持って進めていかなければならないという共通認識ができているんです。 ──確かに貴社の経営層の熱意は我々もひしひしと感じています。経営層がそこまで深い理解を持つに至った背景について教えてください。 木佐森氏： グローバルとのギャップですね。freee がベンチマークとする企業において、彼らがどれだけ AI に投資しているかを追っている中で危機感につながりました。 それがきっかけで、経営層も自分で手を動かすことに時間を充てるようになりました。 ──経営層の深い理解があることは素晴らしいですね。経営層の理解に加えて、現場での AI 活用を組織全体に広げると言った観点ではいかがですか？ 木佐森氏： おっしゃる通りです。経営層だけでなく、そもそもの話として企業全体に挑戦の文化が根付いていることが重要だと思います。freee では「マジ価値」という考え方があり、その中には「アウトプット→思考」と呼ぶ指針があります。これは『まず、アウトプットする。そして考え、改善する。』という指針です。失敗は責められるものではなく、あえてやる/挑戦することが推奨されています。この文化に加えて、AI の活用が進むような組織的な仕組みも整えています。 ※マジ価値: ユーザーにとって本質的な価値があると自信を持って言えることをする ──AWS でも「Customer Obsession（顧客への執着）」というリーダーシッププリンシプルを掲げており、顧客のために挑戦し、失敗から学ぶ文化を大切にしています。また「Bias for Action（行動を重視））」という、計算されたリスクテイクを評価する考え方もあります。こうした文化的な土台があってこそ、AI のような新しい技術への挑戦が組織全体に広がっていくのだと、改めて実感しました。 「成功基準」というフレームワークの確立 ──組織全体に AI 活用を浸透させる上で、どのような工夫をされてきましたか？ 木佐森氏： 最近特に力を入れているのが「成功基準」の策定と浸透です。よく言われることかもしれませんが、一周回って、これをブラッシュアップした状態で組織に徹底することが最も重要だと確信しています。 成功基準というのは、精度などの品質指標と、それが顧客価値やビジネスインパクトにどう繋がるかを明確に結びつける指標です。具体的には、コスト、精度、レイテンシ、品質といった技術的な要素が、どれだけのユーザー価値を生み出すのかを定量化します。 ──具体的にはどのように定量化するのでしょうか？ 木佐森氏： 私は担当チームに「精度が 1% 上がったら、ユーザーの価値はどのくらい上がるんですか？」という問いを投げかけています。これを考えてきてください、と。 この問いは簡単には答えられません。でも、顧客の十分な理解と技術の十分な理解の両面が揃って初めて答えられる。これを事前に定めておくことが重要なんです。 よくあるアンチパターンは、担当チームが「精度 90% を目指します！」と言ってくることです。私は必ず聞き返します。「なんの指標をどう測って 90% なの？ 90% 出たら何のユーザー価値が出るの？」と（笑）。 ──ビジネスとテックで知識が組織をまたがっているので、この答えを揃えるのは難しいですよね。 木佐森氏： まさに。だからこそ、AI ラボのような横串組織が機能するんです。これからの時代、どんどんこういったビジネスと技術の両方を理解して、データドリブンにユーザの業務をモデリングして、マイルストーンを立ててプロジェクトマネージメントができる人材が強く求められると感じています。 成功基準の実践知：「確認コスト」と「修正コスト」の分離 ──成功基準を設定する上で、見落としがちなポイントはありますか？ 木佐森氏： 一つ重要なのが、「確認コスト」と「修正コスト」を明確に分けることです。これは意外と見逃されがちなんです。 例えば、100 枚の領収書を処理する場合を考えてみてください。AI の精度が 80% だろうが 90% だろうが、結局 100 枚全部を確認しなければいけないですよね。つまり確認コストは変わらない。精度が上がっても、間違っている 20 枚や 10 枚の修正時間が減るだけで、100 枚を見るという確認時間は変わらないんです。 さらに厄介なのが、「AI によって便利になったようで、実は確認コストが増えている」というケースです。AI がやったことを確認するのに手間がかかっているのに、それに気づいていない。これも撤退基準として重要な視点です。 撤退基準は、成功基準とセットで事前に決めておくべきです。「今より悪くなる」というのは明確な撤退基準ですが、意外と見逃されがちなんです。サンクコストを払うのは誰でも苦手なので、事前に決めておくことが重要です。 この考え方は、OCR に限らず様々な AI 活用シーンで重要です。例えば、AI が生成した文章のチェックや、AI による分類結果の確認など、「全件を見る必要があるのか」「間違いだけを修正すればいいのか」という違いによって、価値は大きく変わります。AI 導入の ROI を正しく評価するためには、この業務フロー全体のコスト構造を深く理解することが不可欠です。 AI 導入の ROI を正しく評価し、プロジェクトを成功に導くには、AI を組み込んだ後の「業務フロー全体」を設計し直し、その総コストで評価することが不可欠です。そして、このコスト構造の分析を、プロジェクト初期に定める「成功基準」と「撤退基準」に明確に組み込むこと。これこそが、AI 活用を PoC (概念実証) で終わらせず、真の価値創出につなげるための重要な鍵となります。 AIデータ化β での実践と成功基準の進化 記帳作業のコスト構造を変える：AIデータ化β の挑戦 ※AIデータ化β：複数の AI エージェントが協調して OCR の読み取り精度を検証・改善する仕組み 木佐森氏： これは単なる精度向上ではなく、先ほど話した「確認コスト」の問題を解決し、税理事務所・会計事務所の記帳作業全体のコスト構造を根本から変えるプロジェクトです。まさに成功基準の考え方を実践した取り組みと言えます。 そこで私たちが導入したのが読み取り精度に対する「自信」の評価と、それを元にしたアラート機能です。読み取りが簡単な典型的な証憑もあれば、複数税率や人が見ても判断が難しい証憑もあるわけです。読み取った結果に対して、別の LLM が客観的に「この結果、本当に自信ある？」と評価するんです。これによって、「確認すべきもの」と「そのまま通していいもの」を分けることができました。アラートが出た 20% だけを確認すればよくなり、確認時間を 80% 削減できるわけです。「確認時間」と「修正時間」を切り分けたことがポイントです。 ──LLM の活用が真の意味で活きるような発想ですね。 木佐森氏： ここで重要なのが、「強弱をはっきりつける」ことです。グレーゾーンを作らない。例えば、アラートを出す閾値を中途半端なところに設定すると、「これで本当にいいのか」という議論が後から起きやすくなる。 最初は「80% は人手で見てもいいから、残り 20% は本当に 99% の精度で保証できるものを作りましょう」と、強弱を明確につけたんです。どっちつかずではなく、こっち、と決める。そうすることで、後で成功基準を修正するときも判断がしやすくなります。 さらに、日付や金額は絶対にズレてほしくないが、摘要欄は意味が分かればいい、というように、項目ごとに精度の基準を変えています。「落とすところは落とす」という判断も重要なんです。すべてを完璧にしようとすると、結局どれも中途半端になってしまう。 成功基準の進化：仮説検証のサイクル ──成功基準は一度決めたら固定なのですか？ 木佐森氏： いいえ、それは違います。我々はユーザーの方々と一緒にプロダクト作りをする思いで開発をしています。成功基準は仮説であって、早い時点でプロトタイピングを実際にユーザーに当ててみて修正していくものです。 例えば AIデータ化β の取り組み では、数値の読み取り精度とテキストの読み取り精度が全然違うことが分かりました。それなら分けて評価しよう、と基準を分解していったんです。「あ、ここが違ったわ」「ここもっと深掘りできるわ」という発見を基に、成功基準をブレイクダウンしていく。 成功基準を作るための内容を落とし込んだ成功基準シートを作成して、「これ埋めてきてください」と言って渡し、自律的に成功基準を作成できるような仕組みを整えています。 ただ、結局は使ってもらえないと分からない部分も多いので、成功基準を作るためのプロンプトも用意しています。LLM にこのプロンプトを投げると、成功基準のドラフトが出てくるんです。自分自身もこれを使って整理しています。 ──LLM を活用して成功基準を作る、というのは興味深いアプローチですね。 木佐森氏： この成功基準を自分で一回二回作ると「ああ、こういう風に作ればいいんだ」という感覚が掴めるんですが、その感覚をプロンプトに落とし込んだものを社内の LLM アプリとして公開しています。ただ、この LLM アプリでも一定はワークはするんですが、結局のところ、やっぱり人に聞きたくなるんですよね（笑）。なので、現在は単なるプロンプトではなく、よりエージェンティックなものを作成して実験中です。「実質、木佐森エージェント」を作ろうと。 こうした仕組みを通じて、AI ラボや私だけができるのではなく、組織として誰もが AI でユーザー価値を届けられる体制を作っていきたいと考えています。 AWS との協業と今後の展望 AWS との協業 ──AWS との協業について、改めてお聞かせください。 木佐森氏： AWS からは技術・ビジネス・運用の各領域で専門チームによる多角的なサポートをいただいており、非常に助かっています。 技術面では、プロジェクトの立ち上げ段階からの相談対応や、実際にハンズオンで協働いただくなど、壁にぶつかったときにすぐ相談できる体制が整っています。ビジネス面では、生成 AI 活用推進プログラムを通じて、技術提供だけでなくビジネス価値創出の視点での提案を多数いただいています。運用面では、Amazon Bedrock のクオータ調整やコスト最適化など、本番運用を見据えた細やかな調整を迅速に対応していただいています。 AWS も「Customer Obsession」を掲げていますが、今回の支援はまさにこちらの課題を多面的に理解して、それぞれの側面から伴走していただいていると感じています。いつも週次でめちゃくちゃな要望を上げて対応していただいて、ありがとうございます（笑）。 ──技術基盤として Amazon Bedrock を選ばれた理由について、改めて詳しく教えていただけますか？ 木佐森氏： 率直に言うと、プロダクトのインフラが AWS 上で構築されていたからというのが大前提です。ただ、それ以外にも重要な理由があります。 まず、セキュリティとコンプライアンスですね。お客様の大切な情報を扱っているので、データが勝手に保存されず、学習にも利用されないなどの点は必須事項でした。また、PrivateLink を用いて閉域接続のオプションが取れることも重要でした。 次に、対応の速さです。例えば Anthropic が Claude Sonnet 3.5 を発表した次の瞬間には、Amazon Bedrock でも Claude Sonnet 3.5 が使えるようになっていました。これからもどんどん新しいモデルが出てくると思いますが、新しいモデルが出てきたときに私は社内で「1 日で評価して 1 週間でリリースしよう」と言っているのですが、AWS の対応の早さがこれを可能にしてくれています。 そして、キャパシティが潤沢にあることです。AWS の Amazon Bedrock を利用することで、可用性や信頼性のおけるシステムを構築することができます。 ──ありがとうございます。freee 様の挑戦的な取り組みに、チーム一丸となって関わらせていただけることは、私どもにとっても大変有意義であり、多くの学びをいただいております。引き続き全力でご支援させていただきます。 他社へのアドバイス ──これから AI 活用に取り組む、あるいはうまくいっていない企業へのアドバイスをお願いします。 木佐森氏： 「とりあえずやってみよう」というフェーズは終わったと思っています。今は本当に顧客価値やインパクトがあることをどう作るか、というフェーズです。 まとめると、3 つのポイントがあります。 第一に、経営インパクトがあるところに取り組むこと。 小さな課題で AI を活用しても、次のステップに繋がりません。経営層を巻き込んで、本当に価値があることに取り組む必要があります。 第二に、成功基準をプロジェクト初期にしっかり決めること。 精度などの品質指標と、それがどう顧客価値に繋がるかを明確にする。そして ROI を可視化する。 第三に、各フェーズでギャップを分析し、何を落として何を伸ばすかを戦略的に選ぶこと。 グレーゾーンではなく、強弱をはっきりつけた閾値にすることで、後で成功基準を修正しやすくなります。 これは決して簡単なことではありません。でも、本当に価値を出すためには、これらに真摯に取り組むしかないと思っています。 今後の展望 ──今後の展望を教えてください。 木佐森氏： まず、各プロダクトチームが自律的に AI 活用できる組織を作りたいです。今はボトムアップで様々なプロジェクトが始まっていますが、それらの質を組織全体で高めていく。成功基準という共通言語を使って、誰もがユーザー価値を届けられる組織にしていきます。 技術的には、SLM のトレーニングをさらに進化させ、エージェンティックなアプローチで各タスクを最適化していきます。最近のトレンドで言えば、もはやモデル性能よりも人間・組織のイネーブリングがボトルネックですよね。小型化・ルーティング・運用最適化で、エージェントの再現性・安定性やコスト効率に焦点が移っています。 そして何より、「AI CFO」というビジョンの実現に向けて、本当に顧客価値を生み出すAIを量産していきます。これは AI ラボだけでなく、組織全体で取り組んでいくことです。 ──本日は貴重なお話をありがとうございました。 木佐森氏： ありがとうございました。多くの企業が AI 活用で成果を出せるようになることを願っています。 左から freee 木佐森氏、AWS ソリューションアーキテクト 福本、アカウントマネージャー 服部、テクニカルアカウントマネージャー 舟橋 本ブログの執筆はソリューションアーキテクト 福本健亮、撮影はソリューションアーキテクト 伊藤威が担当しました。

本記事は米国時間 2025 年 11 月 4 日に公開された「 Stop Repeating Yourself: Why Global Steering is the AI Context Layer You’ve Been Missing 」を翻訳したものです。 あなたは、関数型の React コンポーネントを使った欲しいことを AI アシスタントに 47 回も伝えました。セミコロン付きの Prettier を使っていることを 23 回。そして、テストファイルは __tests__ ディレクトリに配置し、ソースコードと並べないことを少なくとも 15 回。 聞き覚えがありませんか？ ここで実際にかかっているコストについて考えてみましょう。これは単にイライラするだけではなく、 生産性を下げています。 新しいプロジェクトをセットアップするたびに、すでに何十回も説明してきたプロンプトを再び説明するのに 10 〜 15 分を費やしています。年間 20 のプロジェクトに取り組む開発者にとって、それは 5 時間以上の単純な繰り返し です。50 人のチーム全体では？ワークスペース間で同じ基準をコピー＆ペーストするのに 年間 250 時間 を費やしていることになります。 そして、さらに状況は悪化します。コンテキストが一貫性がないと、コードも一貫しません。あるプロジェクトではセキュリティ基準が適用されます。別のプロジェクトでは、そのファイルをペーストし忘れたためにセキュリティ基準が欠落しています。テストカバレッジは大きく変動します。コードスタイルもずれていきます。 不整合は技術的負債として蓄積されます。 AI を使ってコーディングしているなら（正直、2025 年に誰もがしているでしょうが）、この壁にぶつかっているはずです。 すべての新しいプロジェクトがゼロからスタートします。 AI はあなたの好み、チームの規約、会社の基準を覚えていません。あらゆるワークスペースに同じ指示をコピー＆ペーストするか、さらに悪いことに、毎回手動で入力し直すしかありません。 これが Kiro グローバルステアリングが解決する問題です。 Kiro グローバルステアリングは、AI コンテキストのための個人用の .bashrc のようなもので、どこにいても付いてくる、必要なときに準備ができている設定だと考えてください。好みを一度書けば、それがあなたが触れるすべてのプロジェクトの基盤になります。コピーも、忘れることも、不整合もありません。 影響は？開発者は毎月数時間を節約できます。チームは自動的に一貫性を達成します。組織は規模に応じて基準を適用します。 そして最も重要なことは、AI アシスタントが毎回、初日からあなたを理解するようになることです。 そもそもステアリングとは何か？ グローバルステアリングに入る前に、ステアリングが実際に何をするのかを明確にしましょう。 ステアリングは永続的な AI コンテキストです。 これは、AI エージェントが作業を開始する 前に 、あなたの好み、基準、決定事項について伝える一連のMarkdown ファイルです。すべての会話で同じことを説明する代わりに、ステアリングファイルに一度書けば、AI は作業を開始するリクエストを受けたときに自動的にそれを読み込みます。 現状：ワークスペースステアリング 現在、Kiro はワークスペース固有のステアリングを使用しており、以下の場所に保存されています。 <project>/.kiro/steering/ このアプローチは、プロジェクトごとに設定を指定する必要がある場合にうまく機能します。 しかし、問題があります。 AI に伝えることのほとんどは、プロジェクト固有ではありません。 あなたのコーディングスタイルの好みは、すべてのプロジェクトで同じです。テストの哲学はどこでも一貫しているべきです。普遍的なセキュリティ基準が必要です。なぜそれをすべてのワークスペースで繰り返す必要があるのでしょうか？ グローバルステアリングの登場：個人用 AI 設定レイヤー グローバルステアリングはあなたのホームディレクトリに存在します。 ~/.kiro/steering/ このステアリングファイルは永続的です。普遍的です。どこにでも付いてきます。 ここに置いた Markdown ファイルは、ワークスペースレベルで明示的に上書きされない限り、 すべての プロジェクトで Kiro が利用できるようになります。 グローバルステアリングに何を入れるべきか？ プロジェクトに関係なく、あなたの仕事全体で一貫しているものについて考えてください 個人的なコーディングスタイル ~/.kiro/style.md （グローバル） # style.md ## コード整形 - 常にセミコロン付きの Prettier を使用 - JS/TSは2スペースインデント、Python は 4 スペース - 複数行の配列/オブジェクトには末尾のカンマ ## React の好み - 関数コンポーネントのみ（クラスコンポーネントは使わない） - 再利用可能なロジックにはカスタムフック - コンポーネント上部で props を分割代入 ## 命名規則 - 関数と変数は camelCase - コンポーネントとクラスは PascalCase - 定数は SCREAMING_SNAKE_CASE - 簡潔さよりも説明的な名前 テストのルール ~/.kiro/testing.md （グローバル） # testing.md ## テスト基準 - ビジネスロジックには最低80%のカバレッジ - テストファイルは`__tests__/`ディレクトリに配置 - Jest + React Testing Library を使用 - 外部依存関係はモック化 - クリティカルパスには統合テスト ## テスト構造 - Arrange-Act-Assert パターン - 説明的なテスト名（it should...） - 可能な限り 1 テストにつき 1 つのアサーション セキュリティ要件 ~/.kiro/security.md （グローバル） # security.md ## セキュリティの基本 - 秘密情報は絶対にコミットしない（環境変数を使用） - すべてのユーザー入力を検証 - SQL/HTML レンダリング前にデータをサニタイズ - パラメータ化されたクエリを使用、文字列連結は禁止 - API にレート制限を実装 - HTTPS のみ、混合コンテンツは禁止 ドキュメンテーション基準 ~/.kiro/docs.md （グローバル） # docs.md ## コードドキュメンテーション - すべての公開関数に JSDoc - 複雑なロジックのみインラインコメント - セットアップ手順を含む README をすべてのプロジェクトに - OpenAPI/Swagger を使用した APIドキュメンテーション - "Keep a Changelog" のサイトに従った変更履歴 アーキテクチャ原則 ~/.kiro/architecture.md （グローバル） # architecture.md ## 設計原則 - 関心の分離 - DRYだが明確さを犠牲にしない - 継承よりコンポジション - 説明的なエラーで早期に失敗 - 単一責任の原則 ## コード構成 - 機能ベースのフォルダ構造 - 関連ファイルの近接配置 - クリーンなインポートのためのバレルエクスポート このパターンは、何を構築するかではなく、どのように作業するかを定義します。 実世界のシナリオ：個人開発者 実際にこれがどのように機能するか見てみましょう。 Jane Doe さんの場合 Jane は、React とNode を使った顧客プロジェクト、オープンソースへの貢献、個人的なサイドプロジェクトに取り組んでいるフリーランスのフルスタック開発者です。すべてのプロジェクトで異なるビジネスロジックがありますが、 彼女の基準は同じままです。 Janeのグローバルステアリング設定 Jane の ~/.kiro/steering/ フォルダ ~/.kiro/steering/ ├── style.md # コーディングスタイルの好み ├── testing.md # テストアプローチ ├── security.md # セキュリティベースライン ├── docs.md # ドキュメンテーション基準 ├── git.md # コミットメッセージ形式 └── accessibility.md # アクセシビリティ要件 主 要なファイル： ~/.kiro/git.md （グローバル） # Git 規約 ## コミットメッセージ Conventional Commits に従う： - feat: 新機能 - fix: バグ修正 - docs: ドキュメント変更 - refactor: コード再構築 - test: テストの追加/変更 形式：`type(scope): description` 例：`feat(auth): OAuth2サポートを追加` ## ブランチ戦略 - `main` - 本番環境対応 - `develop` - 統合ブランチ - `feature/xxx` - 新機能 - `fix/xxx` - バグ修正 ~/.kiro/accessibility.md （グローバル） # アクセシビリティ基準 ## 要件 - 最低限 WCAG 2.1 AA コンプライアンス - セマンティックな HTML要素 - 適切な見出し階層（h1 → h2 → h3） - すべての画像に alt 属性 - キーボードナビゲーションのサポート - フォーカスインジケーターを可視化 - 最低 4.5:1 のカラーコントラスト比 ## テスト - キーボードのみでテスト - スクリーンリーダーを使用（NVDA/JAWS） - コミット前に axe DevTools を実行 ワークスペース固有のステアリング さて、Jane は新しいクライアントプロジェクトであるEコマースプラットフォームを開発を開始します。彼女のプロジェクト固有のステアリングファイルは /.kiro/steering/ に配置されます。 <project>/.kiro/steering/ ├── product.md # E コマースのビジネス要件 ├── tech.md # Next.js、Stripe、PostgreSQL の選択 └── structure.md # このプロジェクトのフォルダレイアウト <project>/.kiro/product.md （ワークスペース） # Eコマースプラットフォーム ## コア機能 - 検索機能付き商品カタログ - 永続化されたショッピングカート - Stripe 決済統合 - 注文履歴と追跡 - メール通知 ## ユーザーロール - ゲスト：閲覧と購入 - 顧客：保存されたアドレス、注文履歴 - 管理者：商品管理、注文処理 <project>/.kiro/tech.md （ワークスペース） # 技術スタック ## フロントエンド - Next.js 14（App Router） - TypeScript - Tailwind CSS - 状態管理にZustand ## バックエンド - Next.js API ルート - Prisma 経由の PostgreSQL - 決済に Stripe - メールに SendGrid ## インフラストラクチャ - Vercel にデプロイ - データベースに Supabase - 画像に Amazon S3 どのように連携するか Jane が「新しい ProductCard コンポーネントを作成して」と Kiro に依頼すると以下のものを読み込みます。 Kiro が読み込むもの： グローバルステアリング （ ~/.kiro/steering/ ） style.md → 関数コンポーネント、Prettier 設定 accessibility.md → セマンティック HTML、alt 属性要件 testing.md → テストファイルの配置とカバレッジ ワークスペースステアリング （ /.kiro/steering/ ） tech.md → Next.js、TypeScript、Tailwind を使用 product.md → 商品データ構造と機能 structure.md → コンポーネントは src/components/ に配置 結果として、Kiro は、TypeScript を使用した Tailwind CSS クラスの関数型 React コンポーネント、適切なセマンティック HTML とアクセシビリティ属性、対応するテストファイルと共に正しいディレクトリに配置、Jane のコーディングスタイルに一致、すべてを自動的に生成します。 Jane が好みを設定を繰り返し指示することなく、すべてが実行されます。 チームシナリオ：組織全体の基準 では、これをスケールアップしましょう。50 人の開発者がいるチームではどうなるでしょうか？ AnyCompany の場合 AnyCompany には、8 つの開発チームがあり、混合技術スタック（React、Vue、Python、Go）にわたる 30 以上のアクティブなリポジトリを管理し、厳格なセキュリティとコンプライアンス要件を持っています。 課題： すべての開発者が会社の基準に従う必要がありますが、異なる技術を使用した異なるプロジェクトに取り組んでいます。 AnyCompany のグローバルステアリング戦略 展開アプローチ 組織は、グローバルステアリングファイルをチームに配布する方法の柔軟性を持っています。重要な制約は、Kiro が  ~/.kiro/steering/ ディレクトリからのみグローバルステアリングファイルを読み取ることですが、ファイル自体はコピーまたはシンボリックリンクを通じてどこからでも取得できます。 バージョン管理を使用するチームの場合、AnyCompany は、セキュリティポリシー、SOC2 および GDPR コンプライアンス要件、コードレビュー基準、オンコール手順、アクセシビリティ要件、UI/UX ブランドガイドラインを含む会社全体のステアリングファイルを含む共有リポジトリを維持しています。開発者はオンボーディング中にこのリポジトリをクローンし、ファイルを ~/.kiro/steering/ に直接コピーするか、中央リポジトリが変更されたときに自動的に反映されるシンボリックリンクを作成します。シンプルなセットアップスクリプトがこのプロセスを自動化し、手動コピーなしですべての開発者が同じベースラインを取得できるようにします。 setup-kiro.sh #!/bin/bash # setup-kiro.sh echo "AnyCompany Kiro グローバルステアリングをセットアップしています..." # 会社のステアリングをクローン git clone <チームのグローバルステアリングファイルのURLをここに> ~/.kiro/company-steering # グローバルステアリングへシンボリックリンク（更新が自動同期） ln -s ~/.kiro/company-steering/* ~/.kiro/steering/ echo "グローバルステアリングが設定されました！" Jamf や Intune などのモバイルデバイス管理ツールを使用する企業の場合、展開は完全に自動化できます。MDM スクリプトは、内部サーバーからファイルをダウンロードし、適切な権限を設定し、必要なファイルが存在し続けることを強制することで、 ~/.kiro/steering/ に直接入力できます。または、MDM は /opt/company/kiro-steering/ のような中央の場所にファイルを展開し、 ~/.kiro/steering/ へのシンボリックリンクを作成できます。これにより、ファイルを管理された場所に保ちながら、集中更新が提供されます。このアプローチは、開発者の手動セットアップが不要になり、集中ポリシー管理、ポリシーが変更されたときの自動更新、コンプライアンスのための監査証跡を提供します。 #!/bin/bash # MDM 経由で AnyCompany Kiro グローバルステアリングを展開 USER_HOME="/Users/$USER" STEERING_DIR="$USER_HOME/.kiro/steering" COMPANY_NAME="会社名をここに" mkdir -p "$STEERING_DIR" # 内部サーバーから会社のステアリングファイルをダウンロード curl -o "$STEERING_DIR/security.md" "https://internal.$COMPANY_NAME.com/kiro/security.md" curl -o "$STEERING_DIR/compliance.md" "https://internal.$COMPANY_NAME.com/kiro/compliance.md" curl -o "$STEERING_DIR/code-review.md" "https://internal.$COMPANY_NAME.com/kiro/code-review.md" chown -R $USER "$STEERING_DIR" chmod 755 "$STEERING_DIR" echo "AnyCompany Kiro グローバルステアリングが正常に展開されました" 実際のチーム例：フロントエンドチーム AnyCompany のフロントエンドチームは独自のレイヤーを追加します。 チーム共有ステアリングリポジトリ（フロントエンド） frontend-steering/ ├── react-patterns.md # チームの React 規約 ├── component-api.md # Props パターン ├── state-management.md # Zustand と Context をいつ使うか └── performance.md # バンドルサイズ、遅延ロードルール 個人開発者：John Doe John は AnyCompany のフロントエンド開発者です。 John の完全なステアリング設定： # チーム固有および会社全体（グローバルステアリング内） ~/.kiro/steering/ ├── security.md # 会社のセキュリティ（中央の場所からシンボリックリンク） ├── compliance.md # SOC2/GDPR（中央の場所からシンボリックリンク） ├── code-review.md # PR の基準（中央の場所からシンボリックリンク） ├── react-patterns.md # フロントエンドチームの React 規約 ├── component-api.md # チームの Props パターン ├── style.md # John の個人的なスタイルの好み └── shortcuts.md # John のカスタムスニペット # プロジェクト固有（現在のワークスペース） <project>/.kiro/steering/ ├── product.md # この製品の要件 ├── tech.md # このプロジェクトのスタック └── structure.md # このコードベースのレイアウト John が何かを構築するよう Kiro に依頼すると、Kiro はワークスペースステアリングがグローバルステアリングに優先して、ファイルを読み取ります。ワークスペースステアリングはプロジェクト固有で、競合が存在する場合に優先されます。グローバルステアリングには、John の個人的な好み、チーム規約、会社基準が含まれ、ワークスペースの上書きが存在しない場合に使用されます。結果として、John は会社のセキュリティコンプライアンスが自動的に適用され、プロジェクト全体で共有されるフロントエンドチームの基準、彼の個人的なワークフローの好み、現在のワークスペースからのプロジェクト固有のコンテキストを取得します。これらのレイヤーはすべてシームレスに連携します。 シナリオ：複数言語を利用する開発者 別のシナリオは、複数の技術スタックで作業する場合です。React とTypeScript を使用したフロントエンド開発、Python と FastAPI を使用したバックエンドサービス、React Native で構築されたモバイルアプリケーション、Terraform を通じて管理されるインフラストラクチャ。これらのエコシステム全体で共通の問題は、それぞれが異なる規約を持っているため、コードベース全体で一貫性のない実践に陥りやすいことです。 以下に示すソリューションは、言語に適した実装で、さまざまなコーディング言語にわたって基準を指定する方法を示しています。これで、テスト基準は一貫していますが、実装は言語に応じて適切に変化します。 グローバルステアリングのソリューション： # テスト基準（すべての言語） ## カバレッジ - ビジネスロジックには最低80% - 決済/セキュリティコードには100% ## テスト構造 - Arrange-Act-Assertパターン - 説明的な名前 - テストごとに1つのアサーション ## 言語固有 ### TypeScript/JavaScript - Jest + Testing Library - `__tests__/`ディレクトリにテスト ### Python - pytest - `tests/`ディレクトリにテスト - セットアップに fixture を使用 ### Go - 標準の`testing`パッケージ - テーブル駆動テスト - `_test.go`サフィックス ~/.kiro/naming.md （グローバル） # 命名規則（すべての言語） ## 普遍的なルール - 巧妙さよりも説明的 - 完全な単語、略語は使わない（標準的なものを除く） - ブール変数：`is`、`has`、`should` 接頭辞 - 配列/リスト：複数形の名詞 - ブール名に否定形を避ける ## 言語固有 ### TypeScript/JavaScript - 変数/関数は camelCase - クラス/コンポーネントは PascalCase - 定数は SCREAMING_SNAKE ### Python - 変数/関数は snake_case - クラスは PascalCase - 定数は SCREAMING_SNAKE ### Go - エクスポートされる名前は PascalCase - エクスポートされない名前は camelCase 一般的なステアリングのガイドライン ステアリングに入れてはいけないもの API キーや秘密情報、データベース認証情報、内部 URL やエンドポイント、顧客データや PII 、独自のアルゴリズム（ステアリングファイルを共有する予定がある場合）を含めてはいけません。これは、グローバルステアリングファイルは平文の Markdown であり、多くの場合共有または同期され、デフォルトでは暗号化されていないためです。 含めても安全なもの 一般的なセキュリティプラクティス、コードパターンと好み、テストアプローチ、ドキュメンテーション基準、公開 API 設計原則、フレームワークとライブラリの選択をステアリングファイルに含めることは安全です。 始めよう：最初のグローバルステアリングファイル グローバルステアリングを試して実際に動作を見る準備はできましたか？以下は、実際に確認できる簡単な例です。 ステップ1：最初のファイルを作成する 最も頻繁に繰り返すことを選びます。ほとんどの開発者にとって、それはコーディングスタイルです： nano ~/.kiro/steering/style.md ステップ2：テストする Kiro で新しいプロジェクトを開いて、「新しいコンポーネントを作成して」と依頼します。Kiro は、あなたが言及しなくても、 ~/.kiro/steering/style.md からのスタイルの好みに従うはずです。 ステップ3：徐々に拡張する 繰り返しのパターンを発見したら、より多くのファイルを追加し、有機的に構築します。 # 来週、テスト基準を追加 nano ~/.kiro/steering/testing.md # その次の週、セキュリティベースラインを追加 nano ~/.kiro/steering/security.md まとめ これで、Kiro があなたの全体的なスタイルと好みを理解するために グローバルステアリング を使用して、より効率的に作業する方法ができました。唯一残された課題は、何時間もの時間と繰り返しの指示を節約するために、Kiro プロジェクトに適用し始めるグローバルステアリングファイルに何を書くかです。今日、最初のグローバルステアリングファイルを作成しましょう。二度と同じことを繰り返さない体験をしてみてください。 グローバルステアリングに何を入れますか？ハッシュタグ #codewithkiro でセットアップを共有 するか、 X 、 LinkedIn 、または Instagram で @kirodotdev をタグ付けし、 Bluesky で @kiro.dev をタグ付けしてください。

複数の AWS アカウントとリージョンにまたがるログの管理は、組織にとって常に複雑な課題でした。本番環境、開発環境、ステージング環境用の個別のアカウントやリージョンを含む AWS インフラストラクチャーが成長するにつれ、ログ管理の複雑さは指数関数的に増加します。特に時間外の重大なインシデント発生時には、チームは貴重な時間を費やして、複数のアカウントを検索し、異なるリージョン間でイベントを関連付け、複雑なログ集約システムを管理し、クロスアカウントのアクセス権限を管理しています。このような従来のログ管理アプローチは、多大なリソースを消費するだけでなく、インシデント解決を遅らせ、顧客体験に影響を与える可能性があります。このブログでは、大規模環境向けのログ管理を簡素化する方法をご紹介します。 CloudWatch Logs 一元化のご紹介 Amazon CloudWatch は複数のアカウントにわたるログのフェデレーションを通じて クロスアカウントオブザーバビリティ を提供してきましたが、新しい CloudWatch Logs の一元化 は根本的に異なるアプローチを採用しています。新しい CloudWatch Logs の一元化では、複数のアカウントとリージョンからのログデータを中央アカウントに統合します。この統合により、カスタムビルドの集約ソリューションの管理に関連する運用上のオーバーヘッドとコストの両方が排除され、図1 に示すように、組織のすべてのログデータに対する確実な単一の情報源が提供されます。 図1. 複数のアカウントとリージョンにまたがるログの統 CloudWatch Logs の一元化は AWS Organizations と連携して、お客様の正確な要件に基づいてログデータを自動的に複製するルールを定義します。セキュリティ境界とコンプライアンス要件を維持しながら、何を一元化するか、どこに保存するか、どのように暗号化するかについて完全な制御が可能です。 ソリューションの手順説明 このセクションでは、このソリューションをお客様の環境に実装する方法について説明します。例えば、運用の可視性向上と迅速なインシデント対応のために、異なるリージョンで稼働している複数の本番アカウントからのログを中央アカウントに統合する必要がある場合を想定してみましょう。以下の段階的なガイドでは、ログ一元化ルールの設定方法、送信元アカウントと送信先アカウントの構成方法、および本番環境のログの一元化を開始する方法をご紹介します。 事前準備 AWS Organizations をセットアップし、送信元アカウントと送信先アカウントが組織の一部であることを確認します。 CloudWatch の信頼されたアクセスを有効にします。 CloudWatch コンソールに移動し、 設定 に進みます。 図2 に示すように、組織タブで「 信頼されたアクセスをオンにする 」をクリックします。 図2. CloudWatch の信頼されたアクセスの有効化 (オプション) 委任管理者 を登録します。委任管理者は、組織内のすべてのアカウントまたは特定の組織単位（OU）に CloudWatch 機能をデプロイすることを選択できます。 ログ一元化ルールの設定 送信元アカウントから送信先アカウントにログデータを複製する一元化ルールを作成するには、以下の手順に従ってください。 組織の管理アカウントまたは委任管理者アカウントの CloudWatch コンソール に移動します。 設定 を選択し、 組織 に移動します。 ルールを設定 を選択します。 送信元の詳細を指定します。 ルール名を指定します（例： production-logs-central ） ソースアカウント をアカウントID、組織単位ID、または組織IDを選択します。 図3に示すように、統合するログを選択する Source Regions を選択します。 図3. ログ一元化の送信元詳細の指定 次へ を選択します。 図4 に示すように、 送信先アカウント と Destination Region (送信先リージョン) を選択して送信先の詳細を指定します。プライマリーリージョンで障害が発生した場合にデータの可用性を確保するため、送信先アカウント内に Backup Region を指定してログの同期コピーを保持することもできます。 図4. ログ一元化の送信先詳細の指定 次に、以下のフィールドを設定してテレメトリーデータを指定し、 次へ を選択します。 図5 に示すように、 すべてのロググループ を選択するか、 フィルターロググループ を選択して統合したいロググループを指定します。 ロググループ選択基準でサポートされる構文は以下です。 サポートされるキー : LogGroupName | * サポートされる演算子 : = | != | IN | NOT IN | AND | OR | LIKE | NOT LIKE KMS 暗号化されたロググループ を処理するために、以下のオプションがあります。 Centralize log groups encrypted with AWS KMS key in destination account with AWS KMS key (送信先アカウントのAWS KMSキーで暗号化されたロググループを一元化) このオプションでは、提供された送信先KMSキー ARN を使用して、送信元アカウントから送信先に暗号化されたロググループを一元化します。 このオプションを選択する場合、送信先の暗号化キー ARN とバックアップ送信先の暗号化キー ARN (前のステップでバックアップリージョンを選択した場合のみ必要) を提供する必要があります。 指定されたKMSキーは CloudWatch Logs が暗号化するための権限を持っている必要があります。詳細については、「 ステップ 2: KMS キーでアクセス許可を設定する 」 を参照してください。 Centralize log groups encrypted with AWS KMS key in destination account なし AWS KMS key (AWS KMSキーで暗号化されたロググループを送信先アカウントでAWS KMSキーなしで一元化) このオプションでは、送信元アカウントの KMS 暗号化されたロググループを送信先アカウントでは暗号化せずに一元化します。 Do not centralize log groups encrypted with AWS KMS key (AWS KMSキーで暗号化されたロググループを一元化しない) このオプションでは、送信元アカウントで AWS KMS 暗号化されているロググループは一元化されません。 図5. ログ一元化のテレメトリーデータの指定 確認と設定 ページで、すべての詳細を確認し、 一元化ルールの作成 をクリックします。 一元化ルールが作成され有効化されると、ログイベントは中央アカウントへの統合を開始します。図6 に示すように、同じ名前のロググループはログ管理を効率化するために統合され、ログストリームには送信元アカウントIDと送信元リージョンの識別子が追加されます。さらに、ログイベントには新しいシステムフィールド ( @aws.account と @aws.region ) が追加され、ログデータの出所を簡単に追跡できるようになります。 注意 : CloudWatch ログ一元化機能は、一元化ルールの作成後に送信元アカウントに到着する新しいログデータのみを処理します。過去のログデータ (ルール作成前に存在していたログ) は一元化されません。 図6. 送信先アカウントでの一元化されたログ 一元化ルールの健全性の監視 ルールがアクティブになると、図7 に示すようにコンソールを使用して、または GetCentralizationRuleForOrganization API を使用してプログラムで、その健全性のステータスを確認できます。 図7. 一元化ルールの健全性の監視 ルールの健全性ステータスには以下が含まれます。 HEALTHY (正常): ルールは正常に動作しており、設定通りにログデータを複製しています。 UNHEALTHY (異常): ルールに問題が発生しており、データが正しく複製されていない可能性があります。 PROVISIONING (プロビジョニング中): 組織の一元化が設定処理中です。 ルールが UNHEALTHY とマークされた場合、 FailureReason フィールドに対処が必要な具体的な問題の詳細が表示されます。 一元化されたログを使用した統合分析 ログが一元化されると、分散ログでは不可能だった強力な分析機能が利用可能になります。 @aws.account と @aws.region というシステムフィールドが追加されることで、大規模なトラブルシューティングと分析の方法が変革されます。これらのフィールドは自動的にインデックス化され、より迅速なクエリ結果の取得を支援します。以下の例では、図8に示すように、 CloudWatch Logs Insights が、us-west-2 リージョンからのタイムスタンプ、アカウント、リージョン、メッセージ、ログストリーム、ロググループフィールドを表示するクエリを実行し、結果を 100 エントリに制限しています。 fields @timestamp, @aws.account, @aws.region, @message, @logStream, @log | filter @aws.account = 123456789012 and @aws.region = 'us-west-2' | sort @timestamp desc | limit 100 図8. CloudWatch Log Insights を使用したクエリの実行 @aws.account と @aws.region フィールドを分析に活用する方法を示す追加のサンプルクエリは以下の通りです。 アカウントとリージョン別の認証失敗の試行一覧 fields @timestamp, @aws.account, @aws.region, @message | filter @message like /(?i)(failed|unauthorized|denied|forbidden)/ | stats count() as failed_attempts by @aws.account, @aws.region | sort failed_attempts desc 複数のアカウントとリージョンにわたるDBのスロークエリの分析 fields @timestamp, @message, @aws.account, @aws.region | filter @message like /(query|database|sql)/ and @message like /(slow|timeout|duration)/ | parse @message /query.*?(?<query_duration>\d+)ms/ | parse @message /rows.*?examined[=:]?\s*(?<rows_examined>\d+)/ | parse @message /rows.*?returned[=:]?\s*(?<rows_returned>\d+)/ | parse @message /(?<query_type>SELECT|INSERT|UPDATE|DELETE)/ | parse @message /table[=:]?\s*(?<table_name>\w+)/ | filter query_duration > 1000 | stats count() as slow_queries, avg(query_duration) as avg_duration, max(query_duration) as max_duration, avg(rows_examined) as avg_rows_examined, avg(rows_returned) as avg_rows_returned by query_type, table_name, @aws.account, @aws.region, bin(5m) | sort max_duration desc CloudWatch Logs 機能のベストプラクティス CloudWatch Logs の一元化を実装する際、これらの CloudWatch 機能のベストプラクティスに従うことで、一元化されたログの価値を最大限に引き出すことができます。これらのプラクティスには、メトリクス、サブスクリプションフィルター、ログ変換、コスト最適化が含まれており、組織全体で安全で効率的、かつコスト効果の高いログ管理を確保します。 1. メトリクスとサブスクリプションフィルター CloudWatch Logs の一元化により、メトリクスとサブスクリプションフィルターを通じて強力なデータ変換と統合機能が可能になります。組織は一元化されたログデータを数値メトリクスに変換し、グラフによる可視化とアラームベースの監視を実現できます。 例えば、アカウントやリージョンに関係なく、すべてのログに対して メトリクスフィルターを作成する ことができます。 aws logs put-metric-filter \ --log-group-name /centralized/production \ --filter-name ThrottledAPICalls \ --filter-pattern '{ $.errorCode = "*Throttled*" }' \ --metric-transformations \ metricName=ThrottledCalls,\ metricNamespace=CentralizedMetrics,\ metricValue=1,\ dimensions={Account=$aws.account,Region=$aws.region} さらに、 サブスクリプションフィルター を通じてリアルタイムのログイベントストリーミングを設定でき、 Amazon Kinesis stream 、 Amazon Data Firehose stream 、 Amazon OpenSearch Service 、 AWS Lambda などの様々なサービスとシームレスに統合できます。サブスクリプションフィルターを設定する際、アカウントとリージョンのフィールドを使用して、特定のソースからのログを選択的に転送できます。ログデータにソースアカウントとリージョン情報を含めるには、図9 に示すように、 システムフィールドの発行 の下で @aws.account と @aws.region システムフィールドを選択して有効にします。 図9. サブスクリプションフィルターでのアカウントとリージョンフィールドのフィルタリング 2. ログの変換 CloudWatch Logs の一元化を使用する場合、送信元アカウントから中央アカウントにコピーされるのは生のログデータのみです。送信元アカウントでの取り込み時に適用された ログ変換 は、一元化されたログには反映されません。組織全体で一貫したログ変換を行うために、ログが統合された後、中央アカウントで直接ログ変換を適用することを推奨します。 3. ログストレージコストの最適化 CloudWatch Logs の一元化は、複数のアカウントとリージョンにまたがるログ管理のためのコスト効率の高い価格体系を提供します。一元化されたログの最初のコピーには、追加の取り込み料金やリージョン間データ転送コストはかからず、標準的なCloudWatchのストレージコストと機能価格のみが請求されます。最初の一元化を超える追加コピーについては、1GBあたり0.05ドルの料金が発生します（バックアップリージョン機能の使用も追加コピーを作成します）。詳細については、 CloudWatchの料金ページ をご覧ください。CloudWatch Logs の一元化を使用する際のコストを最適化するために、以下のベストプラクティスの実施を推奨します。 1. 階層化された保持戦略の実装 2層の保持ポリシーを実装することで、ストレージコストを大幅に削減できます。 送信元アカウントには、即時の運用ニーズに対応するための短期保持期 (7-30日) を設定してください。 一元化されたアカウントには、コンプライアンス要件を満たし、履歴分析をサポートするための長期保持期間 (90日以上) を設定してください。 2. 選択的な一元化の利用 ログの追加コピーを作成する際は、以下のような戦略的な一元化アプローチを取ってください。 ロググループフィルターを活用して、特定のアプリケーションやサービスのみを一元化してください。 ビジネス要件に合致するログのみを特定し、一元化してください。 特定のユースケースに役立たない不要なログデータの一元化を避けてください。 3. バックアップ戦略 バックアップ戦略を計画する際には、以下の要因を考慮してください。 バックアップコピーは追加コピーとして扱われ、1GBあたり0.05ドルの料金が発生することに注意してください。 中央アカウントへの専用バックアップに関する特定の要件がある場合にのみ、バックアップの一元化を有効にしてください。 追加料金を排除するため、送信元アカウントをバックアップコピーとして活用することを検討してください。 これらの最適化戦略を実装することで、コストを管理しながら効果的なログ管理を維持できます。 まとめ CloudWatch Logs の一元化は、カスタムログ集約システムの複雑さを排除するネイティブなAWSソリューションを提供することで、クロスアカウントおよびクロスリージョンのログ管理を変革します。自動レプリケーション、AWS Organizations とのシームレスな統合、クロスリージョンサポート、柔軟な暗号化オプションなどの機能により、組織は最小限のセットアップ時間で包括的なログ管理を実現できます。運用効率の向上、セキュリティ態勢の強化、インシデント解決の迅速化を通じて、即座に価値を提供します。開始するには、 クロスアカウントクロスリージョンログの一元化 のドキュメントをご参照ください。 Raviteja Sunkavalli Raviteja Sunkavalli は、Amazon Web Services の Senior Worldwide Specialist Solutions Architect で、AIOps と GenAI のオブザーバビィリティを専門としています。複雑で分散したクラウド環境全体で、オブザーバビィリティとインシデント管理ソリューションのグローバル顧客による実装を支援しています。仕事以外では、クリケットをプレイしたり、新しい料理のレシピを探求したりすることを楽しんでいます。 Andres Silva Andres Silva は、Amazon Web Services (AWS) の Global Cloud Operations Leader および Principal Specialist Solutions Architect として、企業のクラウドオペレーション変革を支援しています。AWS での10年を含む30年以上のテクノロジー経験を持ち、DevOps、クラウドテクノロジー、SaaS インフラストラクチャ管理を専門としています。ノースカロライナ州ハイポイントを拠点とし、AIOps とオブザーバビィリティに焦点を当てた企業全体のクラウドオペレーション戦略を推進しています。人工知能を活用して大規模な運用の優位性と自動化されたインシデント対応を実現する、インテリジェントなクラウドオペレーションフレームワークの設計と実装において、グローバル組織と協力しています。 Siddharth Bhate Siddharth Bhate は、Amazon CloudWatch チームの Senior Product Manager – Technical です。コアテレメトリ製品に焦点を当て、AWS 顧客のオブザーバビィリティの基盤となる高度にスケーラブルで回復力のあるログ取り込みと管理サービスの構築に携わっています。運用データを実用的なインサイトに変換し、アプリケーションのパフォーマンス向上とコスト最適化を実現するお客様の支援に情熱を注いでいます。仕事以外では、ビーグル犬の父親であり、熱心なハイハンディキャップゴルファーです。 本記事は、 Simplifying Log Management using Amazon CloudWatch Logs Centralization を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

本記事は 2025 年 10 月 31 日に公開された Erik Hanchett（Developer Advocacy）、Jay Raval（Developer Experience）による “ Introducing Remote MCP Servers ” を翻訳したものです。 Model Context Protocol（MCP）は、エージェントがツールや外部システムに接続するための標準となりました。関数の実行やファイルアクセス、プロンプトの実行などを行うための汎用インターフェイスです。MCP は AI コーディングアシスタントで広く利用されており、大規模言語モデルの機能を拡張するために使われています。 MCP は、Anthropic が 2024 年 11 月に発表して以来、大幅に進化しました。エージェントは当初、主にローカルで実行される MCP サーバーに接続していましたが、リモート MCP サーバー接続がますます一般的になってきています。リモートサーバーを使うことで、エージェントの機能をローカル環境の枠を超えて拡張できます。リモートサーバーを利用することで、データソースやインターネット上のツール、各種サービスにより簡単に接続できます。たとえば、ノート作成サービスにアクセスできるリモート MCP サーバーに接続できます。また、セキュリティの観点からもより安全に運用できます。これにより、ユーザーにとって新たな統合の可能性が無限に広がります。 Kiro ユーザーは私たちのローカル MCP サーバーサポートを愛用しており、仕様、ステアリング、フックを MCP と組み合わせることで構築された多くの興味深いアプリケーションを見てきました。これをさらに進化させるために、リモート MCP サーバーサポートとワンクリック MCP インストールを新たに発表します。これらの機能により、Kiro での作業とアプリの構築がより簡単になります。 リモート MCP サーバーの説明 リモート MCP サーバーサポートにより、ローカルマシンではなくインターネット上でホストされている MCP サーバーに接続できます。基盤となる仕様は同じです。リモート MCP サーバーは、従来と同様のプロンプト、ツール、リソースを公開しますが、プロトコルが異なります。コンピューター上でローカルに接続する場合に使用する stdio の代わりに、Streamable HTTP 経由で接続できるようになりました。 Streamable HTTP はクライアント接続を処理します。Server-Sent Events（SSE）を使用して複数のサーバーメッセージをストリーミングするという追加の利点があります。Streamable HTTP は、再開可能性、再配信、セッション管理、下位互換性などの追加機能を提供します。なお、Kiro は Streamable HTTP に加えて、非推奨となった HTTP+SSE トランスポートプロトコルにも対応しています。Kiro を使う際は、こうした基盤技術を意識する必要はありません。すべて自動で適切に動作します。 Kiro でのリモート MCP サポートの使用 Kiro は常にローカル MCP サーバー（またはプロキシ経由のリモートサーバー）をサポートしてきましたが、現在はリモート MCP サーバーをネイティブサポートしています。わずか数ステップで、リモート MCP サーバーを追加して使い始めることができます。必要に応じて、認証ヘッダーを追加するか、動的クライアント登録を介して直接認証できます。動的クライアント登録では、Kiro がウェブページを開いてサインインと認証を行うよう求めます。 ここでは、動的クライアント登録を使って Notion MCP サーバーを追加する手順を見てみましょう。 ステップ 1: Kiro を開き、Kiro パネルから MCP サーバーセクションに移動します ステップ 2: リモート MCP サーバー設定を追加します。保存後、画面の右下にサーバー認証用のポップアップが表示されます ステップ 3: 認証をクリックし、Kiro が外部ウェブサイトを開くことを許可します。サインイン後、Notion MCP サーバーを使用できるようになります MCP 接続のセキュリティ確保 MCP サーバーは多くの場合、API キーや認証トークンを必要とします。これらを設定ファイルにハードコーディングするとリスクが生じます。誤ってバージョン管理に含めてしまったり、スクリーンショットなどで公開してしまうおそれがあります。Kiro は現在、 ${ENV_VAR} 構文を使用した環境変数をサポートしています。認証情報はローカル環境に留まり、設定ファイルには保存されません。 Bearer トークンが必要なサーバーに接続する例を以下に示します。 { "mcpServers": { "my-remote-server": { "url": "https://your-mcp-endpoint.com", "headers": { "Authorization": "Bearer ${SECRET_TOKEN}" } } } } Kiro が新しい環境変数を検出すると、承認を求めるセキュリティプロンプトが表示されます。これにより、悪意のある設定が許可なしに環境にアクセスすることを防ぎます。承認された変数は設定で管理でき、いつでもアクセスを取り消すことができます。 これにより、認証情報をローカルに安全に保持でき、簡単にローテーションできるうえ、うっかり公開してしまうことも防げます。 ワンクリックでサーバーを追加 Kiro への MCP サーバーの追加がこれまで以上に簡単になりました。新しい Add to Kiro ボタンにより、ワンクリックで MCP サーバーをインストールできます。ボタンをクリックすると、Kiro が設定の承認を求め、その後自動的にサーバーをユーザー設定セットアップに追加します。 開始に役立つ サンプル MCP サーバーのコレクション を厳選しました。 今すぐ始めよう MCP サーバーを日常的に使っている方なら、リモート MCP サポート、環境変数、ワンクリック MCP インストールといった新機能をきっと気に入っていただけるはずです。開始するには、Kiro の最新バージョンに更新して、今日これらの機能を試してみてください。ご意見をお聞かせください！ 詳細は リモート MCP サーバーのドキュメント をご覧いただくか、 サンプルサーバー を試して気になるものを見つけてみてください。 翻訳は App Dev Consultant 宇賀神が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 11 月の builders.flash 記事が出ていますので生成AI関連のものをピックアップしてみます。今月も多くの記事が出ています！ 「話すだけで仕事が終わる」世界へ ~ Amazon Bedrock で作るリアルタイム AI 議事録アプリケーション(株式会社デイトナ・インターナショナル様) Amazon Bedrock Knowledge Bases + AWS CDK で作る社内向け RAG テンプレート ~ コマンド 1 つで社内展開(ダイキン工業株式会社様) 知財業務を革新するオムロンの知財 AI エージェント実装事例(オムロン株式会社様) 生成 AI で実現する人材マッチング ~ レバレジーズによる職務経歴書入力補助システム ~(レバレジーズ株式会社様) AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ(フリー株式会社様) kintone における生成 AI 機能の安全な運用 ~ 分散トレーシングによる運用課題の解決(サイボウズ株式会社様) AWS Summit Japan 展示「AI メイクさん」のウラガワ ! – AI エージェントで希望のメイク 3D モデルを作成(AWS) AWS Transform for mainframe と GenU で COBOL プログラム説明書を作ってみよう – 後編: フローチャート等の図表の生成(AWS) どの記事も実践的かつ生成AI活用の観点が異なっていて参考になりますね。 毎年おなじみAWS Japanから提供する「AWS Black Belt Online Seminar 2025 年 AWS re:Invent 速報」を今年も開催いたします。ぜひ こちらのページ より事前登録をお願いいたします。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、11 月 3 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「NTTドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用」を公開 NTTドコモ様の主要 Web サービス基盤『POPLAR』において、Amazon Q Developer を活用した開発効率向上の取り組み事例を紹介しています。既存機能の知見継承や技術スキル習得の課題に対し、Amazon Q Developer を開発者の教師役として活用することで、開発生産性の向上と習熟期間の短縮を実現した事例を解説しています。 AWS生成AI国内事例ブログ「アサイクル株式会社様の AWS 生成 AI 活用事例「Amazon Bedrock による顧客との会話要約ソリューションで営業活動を効率化。AI 駆動開発により短期間での構築を実現」のご紹介」を公開 アサイクル株式会社様が Amazon Bedrock を活用して構築した音声会話要約ソリューションの事例を紹介しています。展示会やオンラインデモでの営業活動において、音声ファイルから自動的に要約・キーワード抽出・次のアクション提案を生成し、営業効率を向上させました。AI コーディングエージェントを活用した約 2 週間での短期開発の成功事例も紹介しています。 ブログ記事「Amazon Nova Multimodal Embeddings: エージェントティック RAG およびセマンティック検索のための最先端の埋め込みモデル」を公開 本ブログでは、先日 Amazon Bedrock で利用可能になった Amazon Nova Multimodal Embeddings の概要を紹介しています。テキスト、ドキュメント、画像、動画、音声を単一モデルで処理できる初の統合埋め込みモデルで、エージェンティック RAG やセマンティック検索に最適です。モデルの性能評価、使用方法、Python を使った実装例を詳しく解説しています。 ブログ記事「これが Kiroween です」を公開 初回開催となる Kiroween ハッカソンの発表を紹介しています。総額 10 万ドルの賞金をかけたこのコンテストでは、Kiro のエージェント機能を活用して創造的なアプリケーションを構築します。日程は 2025年11月1日〜12月6日 です。また参加者には Kiro Pro + プラン相当のクジレットを提供されます。詳しい審査基準、提出要件などはブログを参照ください。 ブログ記事「Amazon Nova Web Grounding を使用したより正確な AI アプリケーションの構築」を公開 Amazon Nova Web Grounding とは、AI アプリケーションが最新の情報を自動的に取得し、引用付きで正確な応答を提供するAmazon Bedrock Nova モデル向けの機能です。本ブログでは、Web Grounding の使用シーン、Python を使った実装例、ハルシネーション削減への効果を解説しています。 ブログ記事「AWS を活用した公共部門向け大規模言語モデルの構築」を公開 公共部門向けカスタム LLM の開発プロセスを解説しています。ナショナル LLM やドメイン特化型 LLM の必要性から、ユースケース定義、評価フレームワーク確立、モデル選択、データ準備、インフラ構築、本番デプロイまでの 6 つのステージを詳しく紹介しています。コスト分析や AWS サービスを活用した実装方法も含めて解説しています。 ブログ記事「Amazon Redshift MCP サーバーを活用した SQL 分析の高速化」を公開 Amazon Redshift MCP サーバーを活用した SQL 分析の高速化を紹介しています。MCP により AI エージェントが自然言語で Redshift クラスターを探索し、データ分析を実行できるようになります。インストール・設定方法、Amazon Q CLI や Claude Desktop との統合、顧客購買分析のユースケースを通じた実践的な活用方法を解説しています。 ブログ記事「顧客駆動のチームでAI 駆動の手綱を握る : ML Enablement Workshop による副作用の解消」を公開 AI 駆動開発の生産性向上がもたらすリスクと、ML Enablement Workshop (MLEW) による解決策を紹介しています。リリース速度の向上が事業成長を阻害する可能性に対し、Working Backwards プロセスと生成 AI を組み合わせた MLEW により、顧客駆動の意思決定で開発の方向性をコントロールする方法を解説しています。GitHub で公開されている資料を使って誰でも実践可能です。 ブログ記事「AIOpsを強化 – Amazon CloudWatchとApplication Signals MCPサーバーのご紹介」を公開 Amazon CloudWatch と Application Signals 用の MCP サーバーを紹介しています。これらの MCP サーバーにより、Amazon Q CLI などの AI アシスタントを通じて自然言語でオブザーバビリティデータを分析し、トラブルシューティングを効率化できます。本ブログでは、セットアップ方法、アクセス権限問題の特定と解決の実例、AIOps 強化への活用方法を解説しています。 サービスアップデート Amazon Bedrock AgentCore Runtime がダイレクトコードデプロイメントをサポート Amazon Bedrock AgentCore Runtime でダイレクトコードデプロイが可能になりました。従来のコンテナベースに加えて、zip ファイルを直接アップロードしてデプロイできるようになり、AI エージェントのプロトタイプ開発が迅速化されます。ドラッグ & ドロップの簡単操作で開発者は素早く試行錯誤ができるため、エージェント機能の開発に集中できます。東京リージョン含む 9 つのリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Cognito が Machine-to-Machine アプリクライアント料金体系を廃止 Amazon Cognito の machine-to-machine (M2M) 認証の価格設定が簡素化されました。これまでは M2M アプリクライアント登録ごとの料金とトークンリクエストごとの料金の 2 つの料金体系でしたが、今回の変更でアプリクライアント登録料金が撤廃されました。これにより API 連携やデータ同期などの M2M アプリケーションを低コストで運用できるようになります。詳細は こちらの価格ページ をご参照ください。Amazon Bedrock AgentCore ユーザーにとっても嬉しいニュースですね。 Amazon CloudWatch Application Signals が AI を活用した Synthetics デバッグ機能を追加 Amazon CloudWatch Application Signals に AI を使った Synthetics デバッグ機能が追加されました。従来は canary 監視の失敗原因を手動で分析する必要がありましたが、今回のアップデートで「なぜチェックアウトの canary が失敗しているのか？」のような自然言語での質問に AI が自動回答します。ネットワーク問題、認証エラー、パフォーマンス問題など 6 つの領域を自動診断し、問題の特定と解決にかかる時間を短縮できます。詳細は こちらのドキュメント をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

2025年7月に、AWS 品川オフィスにて「AWS GenAI Catapult ! 」を開催いたしました。本イベントは、Amazon のイノベーション創出メカニズム「Working Backwards」手法を活用し、顧客起点での生成 AI 活用したユースケース創出イベントです。金融領域の企業 10社 40名の皆様にご参加いただき、活発な議論と創造的なアイデア創出が行われました。本記事では、イベントを企画した背景から実際のイベントの様子、参加者の声をお届けします。 企画の背景 日本の生成 AI 利用率の状況 総務省の 令和6年版 情報通信白書 によると、日本における生成 AI 利用率は 9.1％ となっており、他国と比較して低い水準にあります。生成 AI を使わない理由として、40％ 以上の人が「自分の生活に必要ない」と回答していますが、これは「自分たちの業務にどう活用できるか分からない」という具体的な適用イメージが描けていないことが大きな要因と考えられます。金融業界においても、生成 AI 技術の発展により顧客体験の革新と業務効率化への関心は高まっているものの、多くの企業が技術起点でのアプローチを取りがちで、顧客価値創出に課題を抱えているケースが見受けられます。生成 AI を導入したものの、期待した効果が得られないという声も聞かれるのが現状です。 Amazon 流・顧客起点のイノベーション創出メカニズム「Working Backwards」によるアプローチ こうした現状に対して、 Amazon が実践してきたイノベーション創出のメカニズム「Working Backwards」手法 をご紹介させていただきます。この手法は、Amazon Echo、Amazon Prime、AWS などのサービス開発に活用されてきたアプローチで、顧客の理想的な体験から逆算してサービスを設計することにより、顧客が求める価値に焦点を当てた開発を可能にします。具体的には企画段階から顧客体験をプレスリリースという形に詰め込むことで実現します。「Working Backwards」は知識として学ぶだけでは習得できません。実際にプレスリリースを書き、発表しフィードバックを受ける体験を通して身につけることができます。 イベント概要 【開催日時】 1日目：2025 年 7 月 1 日（火）9:30–18:00 発表準備期間：2025 年 7 月 2 日 〜 25 日 2日目（発表日）：2025 年 7 月 28 日（月）13:00–19:00 【会場】  AWS 品川オフィス 【参加者数】  約40 名 【参加企業】  金融関連企業（事業会社、サービサーなど）10社 AWS GenAI Catapult ! とは 〜「Working Backwards」で実現する生成 AI ユースケースの創出 「AWS GenAI Catapult !」は、顧客起点での生成 AI ユースケースを創出しリリースしてもらうための発射台（カタパルト）としての位置づけとし、その意図をイベント名の「Catapult」に込めています。「AWS GenAI Catapult !」では、生成 AI の学習やスキルの習得に留まらず、サービスを利用するユーザーの課題や体験に焦点を当て、 Amazon 流イノベーション文化を理解し、「Working Backwards」手法を用いた実践的ユースケース創出に繋げられるイベントを目指しました。また、生成 AI をテーマに World Café 形式による企業横断での交流と知見の交換セッションを実施し、参加者同士の活発な議論と学びの共有を促進するネットワーキングの機会も提供しました。 このイベントでは、参加者が顧客起点でのアイデア創出プロセスを体験し、AWS の生成 AI サービスを学び体験しながら、ユースケースを作成・整理する手法を習得できます。また、創出したアイデアをプレスリリース形式で発表し、参加者同士の交流を通じて多様な視点からのフィードバックを得る機会も提供します。技術部門とビジネス部門の両方から参加いただくことで、部門を越えた連携が生まれ、さらに自社内では得られない新たな気づきや実装アイデアの発見にもつながります。優秀なチームには表彰トロフィーとメダルの進呈に加え 検証用の AWS クレジットを提供してイベント後の継続的な取り組みも支援いたします。 イベント開催報告 参加企業・チーム名・参加者属性 1日目：Amazon Session [Amazon Innovation & Culture] 1日目は Amazon のイノベーションを支えるカルチャーとテクノロジーについての紹介から始まりました。Amazon は「地球上で最もお客様を大切にする企業であること」を使命とし、徹底したお客様志向、あくなき挑戦、辛抱強さを基本理念としています。1994年の創業以来、本の販売から始まり、現在は Eコマース、クラウド、AI、ロボティクスなど多様な事業を展開しています。イノベーションを生み出す源泉は「f(innovation) = (org * arch) * (mechanisms * culture)」という方程式で表現され、お客様から逆算して考える「Working Backwards」というメカニズム、「Every day is still Day One」という常に初日の心構えを持つカルチャー、小さく権限委譲された「Two-pizza チーム」という組織構造、そして急速な成長や変化に対応できるマイクロサービスアーキテクチャが支えています。Amazon Go に代表される新しい顧客体験は、失敗を恐れず、Builder 精神を持った社員が、顧客中心主義に基づいて創造していることが説明されました。 1日目：AWS Session [AWS GenAI Service Intro] & AWS Dojo Session [AWS GenAI Hands-on] 続いて参加者は、AWS の生成 AI サービスの全容と実践的活用法へと視野を広げました。特に AWS の生成 AI サービスの中でも注目すべきは Amazon Bedrock を中心とした包括的な機能群です。多様な基盤モデルへの単一 API 接続、企業データを活用した RAG（検索拡張生成）、AI エージェント構築、そして安全対策機能、これらを組み合わせることで企業特有の課題に対応した生成 AI ソリューションを構築できることが紹介されました。 ハンズオンセッションでは、参加者自らが生成 AI のモデルに入力するプロンプトを書き、実際に動作する簡単なユースケースを構築しました。すぐに業務で活用できる様々なユースケースを1つのアプリケーションとして提供している OSS である Generative AI Use Cases (略称: GenU) を利用しました。GenU の目玉機能の1つ、独自のユースケースを簡単に追加できる「ユースケースビルダー」機能を体験頂きました。理論と実践の橋渡しとなる貴重な体験に、参加者からは「具体的なイメージが湧いた」「自社でもすぐに試せそう」といった前向きな声が聞かれました。 1日目：Amazon Working Backwards Experience Workshop Working Backwards 体験ワークショップでは、参加者は各企業ごとのチームに分かれ、生成 AI を活用したユースケースの開発に取り組みました。このワークショップは Amazon のイノベーションの源泉となる「Customer Obsession（お客様へのこだわり）」「Think Big（広い視野で考える）」「Bias for Action（行動へのこだわり）」という3つのリーダーシッププリンシプルに基づいて進めていきます。ワークショップの流れは、まず「お客様は誰か」を特定し、その顧客の課題を明確にします。次に課題を解決するソリューションとその目玉機能を考案し、最終的にはプレスリリース形式でアイデアをまとめます。このプロセスを通じて、参加者は顧客視点からのサービス設計を体験し、生成 AI を活用した革新的なソリューションを創出することを目指します。プレスリリースは「導入部分」と「お客様の声部分」で構成され、チーム内で分担して作成します。アイデアの創出等はハンズオンセッションで利用した GenU で生成 AI もうまく活用しながら実施していきました。完成したプレスリリースは他のチームに発表し、建設的なフィードバックを受けることで、アイデアをさらに洗練させていきました。 2日目：参加チーム プレスリリース発表 & QA 1日目 から約3週間、各チームは熟考を重ねたプレスリリースを完成させ、いよいよ発表の時を迎えました。審査は有用性、創造性/WoW体験、実現可能性、PR/FAQ完成度、プレゼンテーションの5項目で厳正に評価され、ストーリーボードやプロトタイプの提示には加点が与えられました。 10チームが抽選で決まった順番で登壇し、持ち時間の中でプロトタイプを作ってくる、生成 AI で作った動画を用いる等、各社それぞれの工夫を凝らした内容で熱のこもった発表を展開しました。未来を変える可能性を秘めた提案の数々、特に Q&A では他チームの提案や考えを積極的に理解しようとする姿が印象的で会場は熱気に包まれました。特に印象的だったのは、単なる業務効率化にとどまらない、顧客体験を根本から再定義するような大胆な提案の数々でした。生成 AI の技術的可能性と顧客価値創造が見事に融合した発表に審査員からも高評価が相次ぎました。 2日目：AWS World Café [GenAI Use case Share] 生成AIの活用をテーマにした参加者交流セッション「GenAI World Café」が開催されました。3人1組の少人数グループで対話を行い、「ホスト」と「旅人」の役割を交代しながらメンバーの組み合わせを変え、議論を深めていく独自の形式です。 「生成AIの活用」というテーマのもと、目的・ツール、人材・役割、組織・文化の観点から多角的な議論が展開されました。このセッションでは結論を出すことよりも、多様な意見の共有と相互理解の深化が重視され、参加者たちは「対話を楽しむ」「話をよく聞く」「質問して広げる」というグラウンドルールに従って活発な意見交換を行いました。 「同じ課題に直面していることがわかって安心した」「他業種の取り組みが参考になった」「組織文化の重要性を再認識した」など、業界や立場を超えた対話からは、多くの共感や気づきが生まれていました。 2日目：Networking Party & 表彰式 プレゼンテーションと World Café セッション終了後、会場は和やかなネットワーキングパーティーへと移行しました。参加者たちは軽食とドリンクを片手に、2日間の学びや気づきを熱心に共有し合い、企業の垣根を越えた新たな繋がりが次々と生まれていきました。 表彰式では、審査員による厳正な審査の結果、チャンピオンには株式会社ジェーシービーの「Synap Spark」が選出されました。2位は株式会社トレードワークスの「Tango-Wango」、3位は株式会社トランザクション・メディア・ネットワークスの「GGPT Revo」が受賞し、それぞれ革新的な顧客体験の創出に挑戦する意欲的な提案が表彰されました。 受賞チームには記念メダルと AWS クレジットが贈られ、参加者全員にも AWS オリジナルグッズが配布されました。会場は受賞チームへの祝福と拍手に包まれ、和やかな雰囲気の中で表彰式は締めくくられました。 参加者の声 本イベント全体の CSAT（お客様満足度）は、4.6 / 5.0 となり、参加された皆様にご満足頂けるものであったと考えております。参加者からは、「他社様の課題感などの共有できる場がありすごく貴重な体験ができました」「PRでの企画提案の文化に目からウロコでした」「学んだ内容をその場で活用しているので学んだ内容含めて印象に残っている」「今回体験した顧客起点の考え方は今後も弊社内で参考にさせていただきます」といった多くの熱意のあるフィードバックが寄せられました。 まとめ 「AWS GenAI Catapult !」は、単なる技術セミナーではなく顧客起点でのイノベーション創出プロセスを学び実践する場として、参加者の皆様に新たな気づきとスキルをご提供することができました。本イベントにより参加者からは「実体験を通して、有用なフレームワークとして体に染み付けることができました」との言葉を頂いています。生成AIという革新的技術を真に価値あるものにするためには、技術の可能性を理解しつつも、常に顧客価値を中心に据えたアプローチが不可欠です。参加者の皆様がこの本質を体感し、自社での実践に活かしていただけることを心から願っています。AWS では今後もお客様のイノベーション創出を支援するためのプログラムを継続的に提供してまいります。 最後に、2日間にわたり熱心にご参加いただいた皆様、そして革新的なアイデアを創出してくださった各チームの皆様に心より感謝申し上げます。皆様の挑戦が、日本の生成 AI 活用を加速し、新たな顧客価値の創造へとつながることを確信しています。

最新のアーキテクチャーでは、メトリクス、ログ、トレースにわたって膨大な量のオブザーバビリティデータが生成されています。問題が発生すると、チームは根本原因を特定するために複数のダッシュボードで情報を手動で関連付ける作業に何時間も、時には何日もかかり、これが平均修復時間(MTTR) と生産性に直接影響を与えています。 Amazon CloudWatch Application Signals は、自動計測を通じてアプリケーションの深い可視性を提供し、レイテンシー、エラー率、リクエスト量、分散トレースなどの重要なメトリクスを取得することでこの課題に対応します。その直感的なインターフェースは重要な洞察と相関関係を可視化させることで問題解決を加速しますが、この機能をさらに強化することができます。 生成AIをこの強力なツールセットと組み合わせることで、根本原因をさらに迅速に特定できます。ここで Anthropic の Model Context Protocol (MCP) が登場します。これは、アプリケーションが大規模言語モデル (LLM) にコンテキストを提供する方法を標準化するオープンソースプロトコルです。MCP はオブザーバビリティデータをAIモデルに直接接続することで複雑なシステムのトラブルシューティングを変革し、調査時間を大幅に短縮する知的でコンテキストを認識した分析を可能にします。 2025年7月8日、 Amazon CloudWatch とApplication Signals 用の2つの新しい MCP サーバー をリリースしました。Amazon CloudWatch MCP サーバーは、CloudWatch の強力な監視・オブザーバビリティツール群と対話するための統合プラットフォームとして機能します。アラームベースのインシデント対応、アラーム推奨、メトリクスとログの分析、ログパターンの検出などを可能にします。CloudWatch MCP サーバーを補完する Application Signals MCP サーバー は、サービスの健全性監視、パフォーマンスメトリクスの分析、サービスレベル目標 (SLO) の遵守状況の追跡、分散トレースを使用した問題調査に焦点を当てています。これらの MCP サーバーは、 Amazon Q 、 Claude Code 、 GitHub Copilot などの様々な AI アシスタントとシームレスに統合でき、オブザーバビリティデータと自然言語で対話することができます。 この記事では、これらの MCP サーバーと Amazon Q Developer CLI を活用して運用ワークフローを変革する方法をご紹介します。従来の手動作業に代わる直感的な会話形式のやり取りを通じて、パフォーマンスのボトルネックの特定、権限の問題の解決、アラーム設定の最適化、インシデント修復の加速化を行う方法を学びます。 事前準備 Amazon CloudWatch にテレメトリー (メトリクス、トレース、ログ) を取り込むアプリケーションを持つAWS アカウントを用意してください。 アプリケーションに対して Application Signals を有効化 してください。 CloudWatch と Application Signals MCP サーバーがAWS リソースに安全にアクセスして操作できるように、必要最小限の権限で AWS 認証情報 を設定してください。最小権限の原則に従い、MCP サーバーが CloudWatch メトリクス、ログ、アラームを照会し、Application Signals のデータにアクセスするために必要な権限のみを付与してください。 環境セットアップ セットアップを開始する前に、適切なオブザーバビリティの設定が重要です。以下のベストプラクティスに従ってください。 CloudWatchアラームの有効化: Amazon Q CLI が効果的にクエリを理解し応答するために、有効なCloudWatch アラームを設定してください。CloudWatch アラームの作成方法については、 CloudWatch アラームのドキュメント を参照してください。 Application Signals での SLO の定義: Application Signals を有効にした後、アプリケーションのパフォーマンスと動作についてより深い洞察を得るために、サービスレベル目標 (SLO) を定義してください。詳細については、「 How to monitor application health using SLOs with Amazon CloudWatch Application Signals 」を参照してください。 CloudTrail イベントの CloudWatch ロググループへの送信: CloudTrail と CloudWatch ロググループを統合することで、Amazon Q CLI がインフラストラクチャの包括的な視点にアクセスでき、より正確でコンテキストに即した応答を提供できるようになります。詳細については、「 CloudWatch Logs へのイベントの送信 」を参照してください。 これらのベストプラクティスに従うことで、Amazon Q Developer CLI が必要なテレメトリーデータにアクセスでき、AWS リソースのトラブルシューティングと分析時に正確でコンテキストを認識した応答を提供できることを確実にします。 Amazon Q Developer CLI をセットアップ お使いのシステムに Amazon Q Developer CLI をインストールしてください。 Astral または GitHub README から uv ユーティリティをインストールしてください。 uv ユーティリティを使用して Python バージョン 3.10 をインストールしてください。 uv python install 3.10 MCP Servers を設定 MCPサーバーを設定します。Amazon Q Developer CLIは、2つのレベルの MCP 設定をサポートしています。 グローバル設定： ~/.aws/amazonq/mcp.json – すべてのワークスペースに適用されます。 ワークスペース設定： .amazonq/mcp.json – 現在のワークスペースに固有の設定です。 優先する設定レベルを選択し、対応する mcp.json ファイルに以下の CloudWatch とApplication Signals MCP サーバーの設定を追加します。 AWS_PROFILE と AWS_REGION のプレースホルダーを、お客様固有の AWS プロファイルとリージョンに置き換えてください。 { "mcpServers": { "awslabs.cloudwatch-mcp-server": { "autoApprove": [], "disabled": false, "command": "uvx", "args": [ "awslabs.cloudwatch-mcp-server@latest" ], "env": { "AWS_PROFILE": "Add your AWS Profile", "AWS_REGION": "Add your AWS Region", "FASTMCP_LOG_LEVEL": "ERROR" }, "transportType": "stdio" }, "awslabs.cloudwatch-appsignals-mcp-server": { "autoApprove": [], "disabled": false, "command": "uvx", "args": [ "awslabs.cloudwatch-appsignals-mcp-server@latest" ], "env": { "AWS_PROFILE": "Add your AWS Profile", "AWS_REGION": "Add your AWS Region", "FASTMCP_LOG_LEVEL": "ERROR" }, "transportType": "stdio" } } } Amazon Q CLI のインストール、AWS 認証情報の設定、MCPサーバーのセットアップが完了したので、CloudWatch と Application Signals MCP サーバーを使用して、自然言語でのクエリを通じて AWS リソースのトラブルシューティングと分析を開始できます。 Amazon Q CLIとの対話方法 q chat コマンドで対話を開始します。 MCP サーバーの設定を確認します。 /mcp コマンドを実行して、図1 に示すようにMCP サーバーが正しく読み込まれていることを確認します。 図1. MCPサーバーが読み込まれていることの確認 図2 に示すように、 /tools コマンドを使用して利用可能なツールと機能を確認します。 図2. 利用可能なツールのリスト 図3 に示すように、「 What questions can I ask about CloudWatch or Application Signals MCP Servers? (CloudWatchやApplication Signals MCPサーバーについてどのような質問ができますか？) 」と尋ねることで、利用可能な機能の全範囲と可能なクエリを理解することができます。 図3. CloudWatchとApplication Signals MCPサーバーの機能を発見する 実例 – アクセス権限の問題の特定と解決 シナリオ DevOps チームは、重要な注文サービスで複数の障害が発生し、業務運営に潜在的な混乱をきたす可能性があるというアラームを受けました。チームは迅速に以下を行う必要があります。 障害の根本原因を特定する 問題がいつ始まったかを判断する 問題を引き起こした変更を行った担当者を特定する 必要な修正を実施する 従来のアプローチ アクセス権限の問題のトラブルシューティングには、多くの場合、面倒なログ分析、試行錯誤のテスト、および IAM ポリシーの詳細な調査が必要です。アプリケーションのアーキテクチャを完全に理解していても、これには時間がかかり、苛立たしい作業となる可能性があります。 Amazon Q CLIを使用したインテリジェントなトラブルシューティング ステップ1: 根本原因の特定 まず、Amazon Q CLI に「 review my ordering-service and provide remediation steps and an RCA for the cause of the faults (注文サービスをレビューし、障害の原因に対する改善手順とRCAを提供してください) 」と依頼することから始めます。 Amazon Q CLI は、Application Signals MCP サーバーを活用して、インテリジェントかつ自動化されたアプローチによる包括的なトラブルシューティング機能を提供します。図4 に示すように、このシステムはサービスの健全性メトリクスのリアルタイム分析を実行し、障害パターンとエラーメッセージを調査し、権限関連の障害を正確に特定します。 図4. Amazon Q CLIに問題の原因の特定を依頼 この分析が完了すると、図5 に示すように、詳細な改善手順、権限のギャップを説明する徹底的な根本原因分析、および運用上の影響の完全な評価がユーザーに提供されます。 図5. RCA と改善手順を示す Q CLI の出力 この高度な AI 駆動の方法論は、解決時間を大幅に短縮するだけでなく、同様の問題が将来発生することを防ぐための貴重な洞察をチームに提供し、現代の DevOps 環境における不可欠なツールとなっています。 ステップ2: 変更の追跡 次に、変更が実行された正確な時間と実行者を特定します。 Amazon Q CLI に「 identify when and who changed the permissions on the role (ロールの権限を誰がいつ変更したかを特定してください) 」と依頼します。 インテリジェントな意思決定機能を通じて、Amazon Q CLI は各タスクに利用可能な最も効率的なツールを賢く選択します。この場合、図6 に示すように、Amazon Q CLI は内蔵の use_aws ツールを活用して、CloudTrail イベントを自動的に分析し、ロール変更の詳細なタイムラインを作成し、特定の変更を正確に特定し、正確なタイムスタンプと共にそれらの変更の責任者を特定します。この自動化された分析により、権限変更の包括的な監査証跡が生成され、チームは手動でログを調査する必要なく、権限関連の問題の根本原因を迅速に特定できるため、トラブルシューティングのプロセスが大幅に効率化されます。 図6. Amazon Q CLIに権限をいつ誰が変更したかの特定を依頼 ステップ3: 修正の実施 原因、発生時期、および発生者を特定したので、権限の変更を解決する必要があります。IAM ポリシーの手動更新には、構文と最小権限の原則の深い理解が必要です。また、正しく実行されない場合、新たな脆弱性が導入されるリスクもあります。Amazon Q CLI に「 Fix the permissions issue(権限の問題を修正してください) 」と依頼します。 Amazon Q CLI は、サービスロールに不足している権限を追加し、注文サービスを以前の状態に復元します。セキュリティ保護機能と検証手順が組み込まれたガイド付きの修正プロセスにより、このシステマティックなアプローチは、セキュリティのベストプラクティスを維持しながら効率的な実装を確保し、手動によるエラーのリスクを低減します。 図7. Amazon Q CLIに権限の問題の修正を依頼 以下の動画では、調査から解決までの完全なワークフローを実演しています。 図8. Amazon Q CLI と CloudWatch および Application Signals MCP サーバーを使用した完全な調査と改善 一般的な調査用サンプルクエリ 以下は、CloudWatch と Application Signals MCP サーバーを活用するために Amazon Q CLI で使用できるクエリ例です。 高度な SLO 分析 – 「支払いサービスの SLO が違反しています。どの特定の操作が失敗しているか、ログのエラーパターンは何か、実行可能な改善手順を含む完全な根本原因分析を実行してください。」 サービスの依存関係 – 「ユーザーチェックアウトトランザクションの完全なリクエストフローをマッピングし、全サービスにわたるボトルネックを特定し、チェーン内で最も高いレイテンシーが発生している箇所を示してください。」 パフォーマンス最適化 – 「AI/ML サービスのトークン使用パターンがレイテンシースパイクとどのように相関しているかを示し、最もパフォーマンスの問題を引き起こしているモデルを特定してください。」 エラー調査 – 「過去24時間のマイクロサービス全体での分散トランザクション障害をすべて検索し、根本原因でグループ化し、各障害タイプの顧客への影響を示してください。」 予測分析 – 「過去3ヶ月のサービスパフォーマンスの季節的パターンを分析し、容量制限に達する時期を予測し、スケーリング戦略を推奨してください。」 セキュリティ分析 – 「異常なレイテンシーシグネチャを持つトレースを分析し、セキュリティログと相関させ、潜在的な攻撃ベクトルを特定することで、不審なトラフィックパターンを調査してください。」 これらのプロンプトは、Amazon Q CLI が複雑な運用シナリオの調査、パフォーマンスパターンの分析、および AWS リソースに関する実行可能な洞察の取得にどのように役立つかを示しています。 まとめ この記事では、Amazon CloudWatch と Application Signals MCP サーバーが、4つの主要な利点（コンテキストを認識した検索機能、自然言語クエリ、インタラクティブなトラブルシューティングワークフロー、効率的な開発者エクスペリエンス）を通じて運用ワークフローを強化する方法をご紹介しました。これらの機能が連携することで、問題をより迅速に特定し、定型作業の時間を削減し、インシデント解決時間を短縮しながら運用効率を向上させることができます。 これらの機能をさらに詳しく知るには、 Amazon CloudWatch と Application Signals MCP サーバーの GitHub リポジトリをご確認ください。AWS での MCP サーバーの実装について、詳しくは「 Amazon Bedrock Agents で MCP サーバーを活用する 」と「 Unlocking the power of Model Context Protocol (MCP) on AWS 」をご覧ください。AWS のオブザーバビリティのベストプラクティスについて詳しく学ぶには、 AWS オブザーバビリティベストプラクティスガイド と One Observability Workshop をご確認ください。 Raviteja Sunkavalli Raviteja Sunkavalli は Amazon Web Services の Senior Worldwide Specialist Solutions Architect で、AIOps と生成AI オブザーバビリティを専門としています。複雑で分散化されたクラウド環境全体にわたるオブザーバビリティとインシデント管理ソリューションの実装について、世界中のお客様を支援しています。仕事以外では、クリケットをプレイしたり、新しい料理のレシピを探求したりすることを楽しんでいます。 Joe Alioto Joeは、AWS におけるオブザーバビリティ、ガバナンス、集中運用管理に焦点を当てたクラウドオペレーションの Senior Specialist Solutions Architect です。20年以上の実践的な運用エンジニアリングとアーキテクチャの経験を持っています。仕事以外の時間は、家族と過ごしたり、新しい技術を学んだり、PCゲームを楽しんだりしています。 Matheus Arrais Matheus Arrais は AWS のクラウドオペレーションにおけるWW Tech Leader です。AWS の運用機能に焦点を当てた数百人の AWS エキスパートから成る社内コミュニティのグローバルな方向性を担当しています。Matheus は、お客様が複雑なクラウドインフラストラクチャを実装・サポートするための大規模なソリューションを設計するため、AWS サービスチームと緊密に協力しています。LinkedIn: https://www.linkedin.com/in/matheusarrais/ 本記事は、 Enhance your AIOps: Introducing Amazon CloudWatch and Application Signals MCP servers を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

AWS IoT Core 10周年 こんにちは、ソリューションアーキテクトの服部です。 AWS が 2015年の re:Invent で IoT 向けのサービスを発表 してから10年を迎え、IoT はビジネスだけでなく普段の生活でも身近な存在となりました。 本ブログでは2025年10月9日に開催されたイベント「10 周年を迎えた AWS IoT Core – 過去を振り返り、未来を見据えて」の内容をご紹介し、登壇者皆様の発表資料を公開いたします。 今回のイベントは AWS IoT Core の発表から10周年という節目に際し、お客様登壇としてこれまで10年間における IoT へのお取り組み、直面した課題とその克服方法、そして今後の IoT を活用したビジネス展開戦略や描いている未来のビジョンについて現場のリアルな声をお届けいただきました。AWS からは AWS IoT Core 10周年を記念した AWS IoT Core のサービスの歴史について語る登壇や AWS Summit Japan 2025 で好評でしたデモ展示をお届けしました。 IoT@Loft とは ? IoT@Loft は AWS が年に数回開催している、IoT 関連ビジネスで開発を担当するデベロッパーのためのイベントです。「総合格闘技」とも呼ばれるほど、幅広い分野の技術が求められる IoT において、参加者同士の情報共有と意見交換の場を提供することで、参加者の事業や製品開発の成功につながるきっかけを作ることを目指しています。 過去の開催ブログの一覧は、 リンク先 にあります。 お客様登壇 AWS IoT で実現した、LIXIL のビジネス変革 – 組織の壁から LIXIL Toilet Cloud まで 登壇者：株式会社LIXIL デジタル部門 Business Innovation Leader 三原 寛司氏 登壇資料( https://speakerdeck.com/kanji_mihara/aws-iotdeshi-xian-sita-lixilnobizinesubian-ge-zu-zhi-nobi-karalixil-toilet-cloudmade ) 株式会社 LIXIL 三原氏からは、前半はLIXIL と AWS IoT の 10年の歩みについて信頼性とスケーラビリティのあるフルマネージドな基盤としてAWSを選定いただいた背景や、事業間連携を想定した中央集権的な統制と各事業部と連携を行うハイブリットな IoT 推進体制の構築についてご説明いただきました。 後半は AWS IoT による DX 事例として「LIXIL Toilet Cloud」のアーキテクチャのご紹介や、AIを活用した異常検知による効率的な点検清掃、データに基づく新たなトイレ循環清掃ビジネスの展望についてご説明いただきました。 未来へつなぐ IoT ～IoT でモノはもっと価値をもつ～ 登壇者：ブラザー工業株式会社 P&S事業 SC開発部 瀧尻 豊 氏 / 墨 啓希 氏 登壇資料 ( IoTLoft27_Brother.pdf ) 続いてブラザー工業株式会社 瀧尻氏のご登壇では、これまでの IoT とこれからの IoTというテーマでご登壇いただきました。前半の瀧尻氏のご登壇では、フルサーバレス化やそれに伴う運用の変化やクラウド利用組織、エンジニアマインドなど10年で変わったことをご紹介いただきました。 後半はブラザー工業株式会社 墨氏より10年で変わらない知見として、接続のノウハウやセキュリティ、データの重要性についてご説明いただきました。また今後の IoT は「新鮮な価値を届ける」「離れた場所へ価値を届ける」といったどのように価値を実現するのかという展望含めて事例をご共有いただきました。 会話AIロボット「Romi」における AWS IoT 活用事例 登壇者：株式会社MIXI Vantageスタジオ Romi 事業部 ロボット開発グループ 高田 信一 氏 登壇資料( IoTLoft27_MIXI.pdf ) 株式会社MIXI Romi 事業部からはロボット事業開発グループ 高田氏にご登壇いただき、会話 AI ロボット「Romi」における AWS IoT の活用事例をご発表いただきました。前半は Romi の開発の歴史から遡り、誕生の経緯やコンセプト、デザインやプロトタイプ開発についてご共有いただきました。 後半はハードウエアや AWS 構成だけでなくソフトウエアコンポーネントまで深掘りいただき、AWS IoT Core を用いた Pub/Sub モデルの導入など解説いただきました。 JAWS-UG IoT 専門支部 登壇者：クラスメソッド株式会社 製造ビジネステクノロジー部 若槻 龍太氏 登壇資料( https://speakerdeck.com/wakatsuki/iot-loft-aws-iot-core-10th-anniversary-jaws-ug-iot-branch ) JAWS-UG IoT 専門支部 からは クラスメソッド株式会社 若槻氏よりJAWS-UG IoT 専門支部についてご紹介いただきました。AWS IoT Core リリース前に立ち上がった IoT 専門支部ではデバイスや AWS 新サービスだけでなく、Matter やThread などの新しい規格、 IoT 機器のセキュリティに関する認証制度 JC-STAR など最新トレンドについて活発に取り上げられていることをお伝えいただきました。JAWS-UG IoT 専門支部 に関する詳細は、 リンク先 をご参考ください。 AWS登壇 10 周年を迎えた AWS IoT Core – 過去を振り返り、未来を見据えて – 登壇者：シニアソリューションアーキテクト 宇佐美 雅紀 登壇資料( IoTLoft27_AWS.pdf ) AWS からはソリューションアーキテクト宇佐美より AWS IoT Coreの歴史を振り返りながら、1日あたり3億以上のユニークデバイスが接続されるまで成長したこと、自動車から発電所、スマートホームデバイスまであらゆる産業で AWS IoT が活用されるようになったことをお伝えしました。そして生成 AI と連携したユースケース広がっている最新のトレンドと、クラウド側 AI へのデータ共有源またはエッジ側 AI への接続手段としての AWS IoT の活用についてお伝えいたしました。 AWSデモ展示 今回の IoT@Loft では AWS Summit Japan 2025 で大好評でしたデモを2点展示いたしました。デモ開発者も同席させていただき、ご来場いただいた皆様と基盤の設計や制御方法など活発な議論をさせていただきました。 AI エージェントで制御する IoT ミニ四駆 登壇者：ソリューションアーキテクト 中西 貴大 デモ紹介ブログ( https://aws.amazon.com/jp/blogs/news/iot-mini4wd-deep-dive/ ) エッジ x クラウド映像革命 登壇者：ソリューションアーキテクト 川崎 裕希 デモ資料( https://pages.awscloud.com/rs/112-TZM-766/images/AWS_Summit_2025_%20A-28A_EdgexCloudVideoInnovation.pdf ) まとめ 10周年を迎えた IoT の盛り上がりに、生成 AI のムーブメントも加わり、ますますパワーアップした IoT@Loft でした。次回のイベントも、さらに進化したIoTの刺激的な体験をお届けしますので、どうぞお楽しみに！ アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 服部 一成

Claude Code や Kiro といった AI 駆動の開発ツールや開発環境によりコーディングの生産性が飛躍的に高まっています。さらに、 AI DLC をはじめとした開発方法論が AI の適用範囲を開発プロセス全体に広げることで、 “本番リリースまでの時間” は数倍に短縮されつつあります。その生産性向上に着目が集まる一方で、 リリース速度が事業の成長を阻害するリスク が観測され始めています。 リスクは技術・ビジネス両面で発生します。技術面では、今まで年 1~2 回だった本番環境に影響するバグが週次で発生するリスクが報告されています (参考 : AWS の VP/Distinguished Engineer である Joe Magerramov の記事 “ The New Calculus of AI-based Coding ”)。ビジネス面で顕著な報告はまだありませんが、リスクを示唆する研究として 1995 年にコロンビア大学のシーナ・アイエンガー教授が示した「ジャムの法則」があります。この実験では 6 種類のジャムを用意した場合と 24 種類用意した場合とで購買行動を比べており、選択肢が多い 24 種類の方が売上が少なく 1/10 になることを示しています。開発に当てはめれば、機能が 4 倍の速度で実装されたとき (6 種類から 24 種類)、 逆に利用率が 1/10 になりえるということです。リスクを低減するには削除や撤退の意思決定が必要になりますが、 IPA の報告によれば日本ではスタートアップにおいても製品やサービスの転換 (ピボット) が不得手であり、米国に比べて成長率が 30 分の 1 程度となる要因として指摘されています (参考 : “ 成長しない日本のソフトウェアスタートアップ 国内競争を促進してエコシステムを創出する ”)。 AI 駆動開発によるリリースの増加はプロダクトマネージャーや事業責任者をはじめとした意思決定者の負荷を高める副作用があり、意思決定の量と質を高める実践と仕組化なしに開発と価値向上のバランスを取ることは困難です 。 Amazon では「顧客に必要とされないものを作らない」ための Working Backwards という製品開発プロセスがあり、リスクに対する有効な対策の一つとなっています。今回ご紹介する ML Enablement Workshop (MLEW) はそれを誰もが実践できるよう体系化されたワークショップです。これまで、JINS 様 (AWS Summit 2025 ご登壇) や MUFG 様 ( re:Invent 2024 ご登壇 )、また BASE 様など業種を問わず多くのお客様が「顧客駆動」でプロダクトを開発するために利用され成果を実感されています。「誰もが」とある通り、 MLEW の資料は GitHub で公開されており事例を含め参照できます 。2025 年 9 月に GitHub で公開された version 3 は Working Backwards の各プロセスを進めるために生成 AI を活用しており、よりスムーズに進められるようになっています。公開後 1 ヵ月ほどで約 20 社に提供されており、この数は昨年 1 年分の提供数に匹敵します。この提供スピードは、お客様のニーズはもちろん「誰でも」行えるようにするための体系化と生成 AI による効率化が機能していることを示しています。2025 年 10 月に行われた 7 社同時での提供では、ほぼすべての会社がサポートなしにプロセスを完了しました。 MLEW version 3 では 机上で企画をまとめるのに留まらず、AI 開発エージェントを用い複数本の企画から複数本の動くモックを構築します 。これにより、今までワークショップ実施後にしかできなかった「想定顧客の反応の計測」をワークショップ期間内に行うことができ、事前に定めた基準に基づき企画を「切る」あるいは「転換」する判断、ピボットを実践できます。重要な点は、MLEW を通じ 「計測した反応(データ)」と Working Backwards という「プロセス」により誰もが高品質な意思決定を実践できるようになる ことです。 MLEW と AI DLC のような開発プロセスは補完関係にあります。組み合わせることで、顧客駆動の意思決定で AI 駆動の方向性をコントロールでき開発生産性と製品価値向上の比例関係を維持できます。 本ブログでは、MLEW の流れをリポジトリに掲載されているコンテンツにそって解説し、実際得られているお客様の反応もご紹介します。解説に沿って皆さん自身でワークショップを実施いただくことも、AWS アカウント担当がいる場合は提供を依頼することも可能です。また、AWS パートナーからの提供に向けて伝授も進められています。 ML Enablement Workshop とは ? ML Enablement Workshop は、1~3 ヵ月以内に計測可能な成果を得るために、組織横断で関係者を招集し価値検証の打率・速度・本数を高めたプロジェクトをキックオフするためのワークショップです。 1~3 ヵ月という期間は、過去 AI/ML 等の新規プロジェクトを始めると大体 3 ヵ月以内に緊急かつ優先度の高い突発的なタスクが発生し中断することが多い観測結果に基づいています。そのため、3 ヵ月以内にプロジェクトを継続すべき定量的な成果を観測することが重要になり、このスピードには「 意思決定できる最小単位 」となるチームの組成が不可欠です。 開催する際は、次の基準を満たしていることを推奨します。 経営層の合意と支援 意思決定できる最小単位を構成する、ビジネス面で事業責任者 (プロダクトマネージャーなど)、技術面で開発者、必要に応じデータサイエンティストの参加 経営層との合意は、仮に 3 ヵ月の間に突発的な優先度の高い案件が入ってきても活動の継続を保証するために必要です。その代わり、チームはこの期間内にあらかじめ決められた定量的な基準を超える成果を出すことにコミットします。条件を確認し、実施が確定したらワークショップの流れに沿って進めていきます。MLEW は過去 2 回大型のアップデートを行っており、現在公開されているのは version 3 になります。本ブログで記載している内容は最新版の version 3 に基づいています。 ワークショップの流れ GitHub のリポジトリで流れを確認してみましょう。アクセス先に書いてある通り、ワークショップは全 3 つのプロセスで行われます。 リポジトリの URL : https://github.com/aws-samples/aws-ml-enablement-workshop それぞれのプロセスの資料は、リンクからアクセスできます。まず Day0 から見ていきましょう。 Day0 は、ワークショップを行う目的と期待する役割を全員で確認するフェーズです。MLEW を実施したい意向がある方は、経営層だったりプロダクトマネージャーだったり、あるいは開発者だったりと様々です。誰かが「無意味な時間」と感じていれば意思決定への本気度も履行の意欲も担保できないため全員の合意が不可欠です。例えば経営層は乗り気だがプロダクトマネージャーは当面のロードマップの実現に注力していて考える余裕がなかったり、プロダクトマネージャーは乗り気だが開発者は実装の余裕がないといった状況はよく起こります。今行う意味や意義について認識が合わないと気付いた場合、見送りや対象チームの変更、参加者の変更などを事前に検討できます。 Day0 の進め方は Day0 のガイド に沿って行います。各担当がワークショップ前に準備すべき内容もこちらに記載されています。事前準備として特に重要な点は下記 3 点です。成果物にはフォーマットがあり、情報さえ集まっていれば容易に準備出来ます。1 と 2 については、後続の実践編で生成 AI へのインプットとして使用します。 顧客を知る : 対象とする顧客について具体化しておく 市場を知る : 顧客の課題に対し、解決策になりそうな競合や市場のソリューションについて一覧化しておく 環境を整える : 生成 AI を用いワークを進めるため生成 AI が利用できる環境を整える (AWS なので Amazon Q Developer が推奨だが他の AI エージェントツールも利用可能) 実践編、改善編が本編になります。実践編と改善編の構成は次のようになっています。 実践編は Working Backwards をやり切り体得することに注力しており、改善編は体得したプロセスを自ら行い企画を改善することに注力しています。改善編の後半では、具体的なタスクとスケジュールを必ず決めて終了します。 以降は、実践編と改善編について解説します。 実践編 : Working Backwards をやり切る 実践編 は Working Backwards の 5 つのプロセスに沿って進行します。 Listen で顧客は誰か? 顧客はどのように行動しているか ? を観察し、 Define で潜在する課題と企画を特定、 Invent で課題を解決・機会を活用する発明を考案、 Refine で発明による新しい顧客の体験をプレスリリースの形で描画し、 Test/Iterate でその効果を計測、改善のサイクルを回していきます。各プロセスの時間が決められている通り、実践編では時間厳守でやり切ることにフォーカスしています。実践編の目的はプロセスの理解と体得で、ユースケースの質は改善編で高める構成となっています。実践編の資料は下記リンクからアクセスできます。 https://github.com/aws-samples/aws-ml-enablement-workshop/blob/main/docs/organizer/day1.md プロセス全体の流れを図にすると、次のようになります。Listen、Define で製品やサービスを届ける顧客の声から根本的な課題を特定し、Invent で解決のための発明、Refine と Test/Iterate で解決しているかどうか答え合わせをする形になります。事業責任者の方であればカスタマージャーニーマップやユーザーストーリーマッピングによる体験分析をされたことがある方もいるかもしれません。Working Backwards では、 Listen / Define の分析フェーズに当たります。また、ビジネスモデルキャンバスなどで収益を生むプロセスを立てる方もいると思いますが、Working Backwards では Test/Iterate で具体的に観測すべきビジネスの指標と目標値を決めます。Working Backwards のコンセプトは「 最も難しい判断を最も最初に行う 」ことであり、Refine でプレスリリースを書くことに象徴されるよう “ 明日この製品をリリースしたらそれは顧客に受け入れられ売れるのか ? ” を顧客の体験面、ビジネスの成果指標面両方で検証するフレームワークになっています。 MLEW は、Working Backwards を「誰もが」実践できるよう、顧客・課題・発明・体験・観測、といった人により解釈が異なる言葉やプロセスを明確に定義しています。例えば、Define のフェーズでは「課題」とは何か、課題が顧客の声 (Listen) とどのように異なるのかを明確に示しています。また、Invent で行う課題に対する解決策 (発明) の考案でも、まず 「発明」とは何かを定義し、それと Define (課題) を発見するために立てた問いとどういう関係があるのか示しています。 このような「言語化」により生成 AI へ正確な指示を与えることができ、ファシリテーションの精度を高めています。下記の「当日のガイド」に従い進めていけば、手早くかつ再現性の高いプロダクト開発プロセスを実践できるようになっています。 https://github.com/aws-samples/aws-ml-enablement-workshop/blob/main/yourwork/README.md Generative AI Use Cases (GenU) を導入済みのお客様は、 ユースケースビルダーにワークショップ専用のユースケースをインポートすることで GenU 上でワークショップを進めることができます。 もちろん、生成 AI の出力結果は完璧ではありません。参加者の知見や経験を持ち寄り、生成された顧客の体験や発明が妥当かどうか、確認しながら進めていきます。主催者 (ファシリテーター)用のガイドもページに記載しており、これまでのワークショップの経験から気を付けるべき点やタイムテーブルの例などをまとめています。 企画をプレスリリースとして執筆する Refine のフェーズが終了した後、AI 開発エージェントにプレスリリースを与えアプリケーションのモックを作成します。以下は EC サイトごとに異なるサイズや規格で商材を作るのが面倒という課題を生成 AI で解決する企画から生成した例です。ランディングページ、体験可能なモック、またモック内のページビューなどが参照可能なダッシュボードを構築します。 モックを作成させている間に人間は最後の Test/Iterate を行い、構築したモックでどのような反応が得られたら次のフェーズに進むのかを定量的に定義します。実践編終了時点で、顧客に対する解決策の仮説、仮説を検証するための動くモック、モックで計測する顧客の反応と合格基準がそろっている状態になります。 改善編 : 現実のデータに向き合いプロセスを繰り返す 改善編 は Working Backwards の最後のプロセスである Test/Iterate を実践します。すなわち、モックを通じ顧客候補の反応を “Test” し、そのインプットを “Listen” することで Working Backwards を “Iterate” するということです。通常のワークショップはウォーターフォールのようにプログラムをすべて終えてアウトプットが出たら終了ということが多いですが、MLEW では多くの製品開発プロセスがそうであるようにアウトプットから得られた反応を基に改善するまで行います。これまで、ワークショップで作成するのはプレスリリースのみ、しかも 1 本にしぼっていましたが、生成 AI により複数本のプレスリリースとモックが作れるようになりました。複数本の検証結果があることで、反応が芳しくない企画を捨てる、方向を変えるといった判断が行いやすくなりました。モックから反応を得る期間を確保するため、実践編と改善編の間は 1 週間は空けるスケジュールを推奨しています。 改善編の前半は参加者自身による Working Backwards 、後半 1 時間は今後の計画を立てるために配分しています。前半の時間配分は、参加者の Working Backwards に対する評価に応じ時間配分を頂きます。プロセスが明確に区切られていることで、Listen に時間をあて顧客の反応分析に注力する、反応は良好であるためより差別化された体験を目指し Invent に注力する、といった状況に応じた対応を取ることが出来ます。 改善編では、今後に向けて実際のプレスリリースまでのマイルストンを立てます。実際のプレスリリースまでに何個のマイルストンがあるのかについても、スポンサー、ファン、シェアの獲得といった明確な段階を定義し達成すべき段階について解釈がぶれないよう構成しています。 マイルストンの到達計画を立てたら、その計画が確実に履行されるようワークショップ期間中にスケジューラーに定期ミーティングやスポンサーとなった役員報告への時間を登録いただきます。 実施してのフィードバック これまで、お客様から次のようなフィードバックを頂いています。ワークショップの密度の濃さとモックまで作るスピード感を高く評価いただいています。 「 各フェーズが意味があり とても密度の濃い良いワークショップでした。」 「一連の流れをAIを活用してスピーディに体感できた」 「 数時間で問題の整理からモックの作成、その後の計画までできた 」 「すごいフレームワークですね。人手だけでやるととても疲れると思いますが、AIの力でやりやすいと思います」 「当たり前を疑う問いを作ることができた」 MLEW 自身も Working Backwards に沿い、お客様からのフィードバックを基に改善を続けています。今年開催された「ビジネスをグロースする生成AIコンテスト2025」で提供した内容を基に作成しており、version 3 公開後もすでに 2 回アップデートしておりモックのメトリクス計測やプロンプトの修正を行っています。生成 AI コンテストに参加いただいたお客様の開発したサービスのいくつかは AWS のブログとして公開いただいており、今後より多くのお客様の事業成長を支援すべく今後も改善を続けていきます。 株式会社情報戦略テクノロジー様の AWS 生成 AI 活用事例 : Amazon Bedrock を活用し社員一人ひとりに寄り添いともに成長するAIエージェント秘書「パイオにゃん」 を開発。情報探索業務を83%改善、社員の成長の可視化を実現。 株式会社リネア様の AWS 生成 AI 事例：GraphRAGで実現するサプライチェーンリスク検知と管理への取り組み 終わりに 本ブログでは、生成 AI による開発の加速は意思決定負荷が増える副作用があり、技術的・ビジネス的な判断を誤る回数が増える問題を明らかにしました。そして、この問題は特に日本企業で顕著に観測される可能性があることを IPA のレポートを基に示しました。その解決策の一つとして、Amazon で実践されている顧客起点で「必要とされない」ものを作らない Working Backwards をチームで身に着けるための実績あるワークショップ ML Enablement Workshop を解説しました。生成 AI が生成するコードの量に比べ、製品や事業の成長に伸び悩みやリスクを感じられている場合ぜひ活用いただければ幸いです。

Amazon CloudWatch の強化された自動ダッシュボードを活用することで、 Amazon CloudWatch Logs の使用パターン、コスト、潜在的な問題をより詳しく把握し、効率的な運用管理を実現できます。この記事では、使用状況を理解することの重要性、ダッシュボードの確認方法、そこから得られる知見について説明します。さらに、CloudWatch の使用状況とコストを把握するための他の便利なツールもご紹介します。 図1. CloudWatch Logs の新しい強化された自動ダッシュボードの一部 使用状況の把握が重要な理由 CloudWatch は、アプリケーションやインフラストラクチャのオブザーバビリティを把握するための監視サービスです。オブザーバビリティにより、カスタマーエクスペリエンスの理解、運用の健全性維持、リソース使用の最適化、パフォーマンスの変化への迅速な対応が可能になります。CloudWatchは、メトリクス、ログ、トレースデータを収集することで、データに基づいた分析、可視化、アクションの実行を可能にします。 アプリケーションに関連するコストを理解することは、そのアプリケーションがもたらす価値を理解する上で重要な要素です。コストと使用状況のデータにより、オブザーバビリティなどの運用サポートに関連するものを含め、コスト最適化が可能な領域を特定できます。CloudWatch の使用状況の要因を理解することで、オブザーバビリティ戦略についてデータに基づいた意思決定を行い、その変更がコストに与える影響を確認することができます。さらに、CloudWatch でのエラーやスロットリングの発生箇所を理解することで、期待するすべてのデータを使用できるよう、問題を特定して解決することができます。 この新しいダッシュボードは、CloudWatch Logs でよく要求される領域の使用状況の詳細を提供する、すぐに使える機能です。ダッシュボードは CloudWatch コンソールにあります。 左側のメニューの「ダッシュボード」セクションに移動し、次に「自動ダッシュボード」タブに移動します。 このタブには、すぐに使えるダッシュボードがいくつか含まれています。CloudWatch Logs を選択してダッシュボードを表示します。 図2. CloudWatch Logs の新しい改善された自動ダッシュボードの一部 ダッシュボードの概要 ダッシュボードはセクションごとに分かれており、CloudWatch Logs の使用状況をさまざまな観点から確認できます。 表示されるデータは、現在選択しているリージョンとアカウントに対応しています。他のリージョンの CloudWatch 使用状況を確認するには、コンソール右上のリージョン選択を変更するだけです。 ほとんどのデータは時系列グラフとして表示され、変更の影響を観察することができます。数値表示では、選択した期間の集計データを確認できます。ダッシュボード右上の時間設定で、期間とタイムゾーンの両方を調整できます。特定の時系列データを単一のグラフで詳しく調べるには、凡例で名前を選択して他のすべての系列を非表示にします。同じ系列名を含む関連ウィジェットは、自動的に選択に合わせて調整されます。系列名を再度選択すると、全体表示に戻ります。 図3. 凡例から選択した後、単一の系列が表示されているCloudWatchダッシュボードウィジェット ダッシュボードは使用状況を表示します。これをコストに変換する方法の詳細については、 Amazon CloudWatch 料金ページ を参照してください。 ダッシュボードは、それぞれに複数のダッシュボードウィジェットを持ついくつかの主要なセクションに分かれています。 アカウント別のログ取り込み ロググループ別のログ取り込み サービス使用状況 Embedded Metric Format (EMF) サブスクリプションフィルター ログ異常検出 ログデータ保護 ログトランスフォーマー セクション1と2: ログ取り込み CloudWatch Logs のコストの中で、通常、ログの取り込みが最も大きな要因の一つとなっています。ログ取り込みにかかるコストは、それがもたらす価値に見合ったものであるべきです。どのロググループがコストを発生させているかを把握することで、関連するアプリケーションを担当するチームと建設的な話し合いを持つことができます。取り込むログの内容（ボリューム、詳細度、フィルタリング）を検討するとともに、必要な機能に応じて、 標準ログクラスか低頻度アクセスログクラス のどちらを使用するかを検討することをお勧めします。これはロググループレベルで設定できます。 セクション1: アカウントのログ取り込み ウィジェット 取り込まれたログの合計GBボリューム 時間経過に伴う取り込まれたログのGBボリューム 図4. アカウントのログ取り込みに関するダッシュボードセクション セクション2: ロググループごとのログ取り込み ウィジェット ロググループ間でログ取り込み（GB）がどのように分散されているかを示す円グラフ ロググループ別の時間経過に伴うボリューム（GB）ログ取り込み 図5. ロググループ別に分類されたログ取り込みに関するダッシュボードセクション セクション3: サービス使用状況 サービスの使用量には、CloudWatchへの直接的または間接的なすべてのAPI呼び出しが含まれます。ロググループにログをアップロードする際は、PutLogEvents APIが使用されます。同様に、Logs Insightsでクエリを実行する際は、StartQuery APIが呼び出されます。 CloudWatchには API 呼び出しの制限 があり、この制限を超えるとAPIエラーやスロットリングが発生する可能性があり、これらはこのセクションで確認できます。スロットリングについて詳しくは、「 CloudWatchログでスロットリングエラーのトラブルシューティングを行うにはどうすればよいですか？ 」をご参照ください。 ウィジェット 時間経過に伴う主要なAPI呼び出しの数（例：DescribeDestinations） 時間経過に伴うAPIエラー数 時間経過に伴うAPIスロットリング数 図6. サービス使用状況のダッシュボードセクション セクション4: Embedded Metric Format Embedded Metric Format (EMF) を使用すると、メトリクスと詳細なログ情報を同じログイベントに含めることができます。CloudWatch は、EMF ログイベントを取り込む際に、自動的に対応するメトリクスを CloudWatch Metrics に作成します。メトリクスデータと詳細なログ情報を同じイベントで組み合わせることで、ログメッセージとそれに関連するメトリクスの間に直接的な関連付けが可能となります。これは、PutMetricData API を使用してメトリクスを送信する代替手段として効果的です。 ログから適切にメトリクスを自動抽出するために、 EMF仕様 に従って正しいJSON構造を確保してください。提供されているウィジェットを使用して、取り込みの失敗を監視することができます。 ウィジェット ロググループ名別に分類された、時系列の検証エラー数 ロググループ名別に分類された、時系列の解析エラー数 図7. Embedded Metric Format (EMF)のダッシュボードセクション セクション5: サブスクリプションフィルター サブスクリプションフィルター は、CloudWatch Logs から他の AWS サービスへのログデータのリアルタイムストリーミングを可能にし、追加の処理、分析、またはストレージを行います。ロググループにサブスクリプションフィルターを作成して、一致するログイベントを選択した宛先に自動的に送信できます。 サブスクリプションフィルター自体には追加コストは発生しませんが、 Amazon Data Firehose や AWS Lambda などの宛先サービスによってコストが発生します。転送されたイベントの数とそのソースロググループを監視することで、使用状況と関連コストを把握できます。このセクションには、ロググループ別に分類された時系列のエラーとスロットリングのグラフも含まれているため、問題を特定して修復できます。 ウィジェット ロググループ名別に分類された、時系列の転送イベント数 ロググループ名別に分類された、時系列のエラー数 ロググループ名別に分類された、時系列のスロットリング数 図8. サブスクリプションフィルターのダッシュボードセクション セクション6: ログ異常検知 CloudWatch ログの異常検出 は、機械学習を使用してログデータを分析し、ログのパターンを識別します。例えば、ステータスコード 200 のログイベントが突然減少するような異常な動作を検出します。異常が検出された場合、CloudWatch はログイベント数の変化の大きさや「Exception」などの特定のキーワードに基づいて、検出結果に高、中、低の優先度を割り当てます。なお、Logs Insights の パターン機能 は、異常検出機能とは独立して使用することができます。 ウィジェット 検出された低、中、高のログ異常の総数 図9. ログ異常検知のダッシュボードセクション セクション7: ログデータ保護 CloudWatch Logs を使用すると、取り込み時に機密データを識別してマスクする データ保護ポリシー を作成できます。ポリシー内で、クレジットカード番号、APIキー、個人識別情報(PII)などの 機密データの種類 を定義します。個別のロググループまたはアカウント全体に対してポリシーを作成できます。 ウィジェット ロググループ別に分類された、時系列のポリシーに一致するログイベント数 図10. ログデータ保護のダッシュボードセクション セクション8: ログトランスフォーマー ログを標準化したい場合、 CloudWatch Log Transformers を使用してログデータを取り込み時に処理および変換することができます。Transformers を使用することで、フィールド名の標準化（user_id、userId、user などの表記ゆれの統一）によって一貫性を向上させたり、検索を容易にするためにログイベントを JSON 形式に変換して構造化したり、アプリケーション名などの追加データを含めることでコンテキストを強化したりすることができます。Transformers は 組み込みプロセッサー を使用し、これらを連続して適用することで目的の結果を達成できます。Transformersは個別のロググループに適用することも、アカウント全体に適用することも可能です。 ウィジェット ロググループ別の、時系列の変換されたログイベント数 ロググループ別の、時系列の変換されたバイト数 ロググループ別の、時系列の変換エラー数 図11. ログトランスフォーマーのダッシュボードセクション コスト CloudWatch Logsダッシュボードは、追加コストなしですぐに使用できるエクスペリエンスを提供します。 使用状況とコストを理解するためのその他のツール この新しいダッシュボードは貴重な洞察を提供しますが、CloudWatch の使用状況とコストを理解するための他のリソースもあります。 CloudWatch コストの分析、最適化、削減 に関する AWS ドキュメント AWS Cost Explorer: アカウント全体の AWS 支出を可視化、理解、管理 CUDOS Dashboard : Cloud Intelligence Dashboards フレームワークの一部で、組織全体の AWS 支出と使用状況に関する深い洞察を提供 特定の関心領域を探索するために、独自のカスタム CloudWatch ダッシュボードも構築できます。例と AWS CloudFormation テンプレートについては、「 Visualizing Amazon CloudWatch Costs – Part 1 」および「 Visualizing Amazon CloudWatch Costs – Part 2 – Where does the data come from? 」を参照してください。 注意：独自の CloudWatch カスタムダッシュボードを作成すると、ダッシュボードに関連するコストが発生します。詳細については、 Amazon CloudWatch の料金 ページを参照してください。 まとめ この強化された標準搭載の CloudWatch 自動ダッシュボードは、追加コストなしで CloudWatch Logs の使用状況をより深く理解することができます。このデータを活用して、コストの要因を特定し、サービスから最大の価値を得るためにCloudWatch の使用を最適化することができます。 使用状況の監視を強化するために、このダッシュボードに表示されているロググループの取り込みなどの詳細なメトリクスデータに基づいて、 請求アラーム や CloudWatch アラーム の設定を検討してください。CloudWatch アラームは、個別のメトリクスまたはメトリクス数式を使用して設定でき、静的しきい値または異常検出のいずれかを柔軟に使用することができます。 Chaitanya Gummadi Chaitanya は AWS の Sr. Observability Customer Success Specialist です。彼はお客様のオブザーバビリティ機能の向上を支援することに情熱を注いでいます。仕事以外では、多様な料理を探求することやハイキングの冒険を楽しんでいます。 LinkedIn: /cgummadi Abeetha Bala Abeetha Bala は Amazon CloudWatch の Senior Product Manager です。お客様第一主義であり、AWSのお客様が困難な問題に対する革新的なソリューションを見つけることを支援することに情熱を注いでいます。 Helen Ashton Helen Ashton は AWS の Sr. Solutions Architect で、オブザーバビリティを専門としています。Helen はお客様のビジネス課題の解決と、クラウドジャーニーの進歩を支援することに情熱を注いでいます。仕事以外では、音楽、サイクリング、ガーデニングを楽しんでいます。 Bobby Hallahan Bobby Hallahan は AWS オブザーバビリティチームの Sr. Specialist Solutions Architect です。彼はお客様が困難な問題に対する革新的なソリューションを見つけることを支援することに情熱を注いでいます。彼は AWS のお客様と協力して、オブザーバビリティの目標達成を支援しています。AWSでの在職期間中、Bobby はエンタープライズカスタマーのミッションクリティカルなワークロードをサポートしてきました。 本記事は、 Analyze logs usage with Amazon CloudWatch enhanced automatic dashboard を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

本ブログは アサイクル株式会社様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクトの森です。 展示会やオンラインイベントなどの営業活動においては、顧客との重要な会話を正確に記録し、後続のフォローアップに活かすことが重要です。しかし、従来の手動による記録作業は営業担当者にとって大きな負担となっており、本来の営業活動に集中できないという課題がありました。今回は薬局 DX をリードする企業として「 ASKAN 」「 PICKING GO 」「 ZERO STOCK 」といったソリューションを提供されているアサイクル株式会社様が、音声会話要約ソリューションを短期間で開発した事例を紹介します。 お客様の状況と検証に至る経緯 アサイクル株式会社様は、薬局 DX を推進するシステムを提供する企業として、展示会やオンラインデモでの営業活動を積極的に展開しておりましたが、以下のような課題を抱えておりました。 会話内容を CRM にテキストで手入力する作業は時間を要し、担当者によって情報の質や量にばらつきが発生していた。 貴重な商談時間がメモ取りで中断してしまい、顧客との対話に集中できない状況があった。 既存の文字起こしサービスでは、調剤薬局を取り巻く業界特有の専門用語の認識精度が低く、商談後の情報整理に支障をきたしていた。（例：「アスカン」→「明日感」、「ピッキングゴー」→「ピッキング語」） そこで AWS のマネージドサービスを活用し、業界特化型の音声文字起こしシステムを構築することで、これらの課題を解決するソリューションの検証をすることになりました。 ソリューションと構成 本ソリューションは、展示会やオンラインデモで録音した音声ファイルを基に、Amazon Bedrock を活用した高精度な構造化テキスト出力を実現しています。 Amazon Bedrock を活用した構造化テキスト出力: LLM のプロンプト制御により専門用語を補正し、会話内容の要約・重要キーワード抽出・次のアクション提案などを CRM に最適な形式で自動生成 Amazon ECS (AWS Fargate) を活用したコンテナベースの音声処理: サーバーレスコンテナ環境で高度な音声処理機能を実装 AWS ネットワークを活用したセキュアな環境での構築: 機密性の高い顧客との会話内容を外部に漏らすリスクを排除したセキュアな処理環境を提供 このソリューションにより、音声ファイルをアップロードするだけで、営業活動の効率化と品質向上を同時に実現できる仕組みを構築しました。   AI コーディングエージェントを活用した短期間開発 アサイクル株式会社様は AWS 主催のハッカソンイベント「DEVCRAFT」で本プロジェクトに取り組まれました。本プロジェクトの特筆すべき点は、AI コーディングエージェントを活用した AI 駆動開発により、従来であれば数週間から数ヶ月を要するようなシステム開発を、ハッカソンイベントの約２週間という短期間で実用レベルまで構築された点にあります。 要件定義から実装まで一貫した開発：ビジネス要件を技術仕様に落とし込み、生成 AI の支援により実装まで効率的に実施 AWS サービスとの統合コードの自動生成：各 AWS サービスとの連携に必要となるコードの自動生成 コンテナ化された処理基盤の構築：音声処理機能をコンテナ環境で効率的に実装 定型的なコード記述や API 連携部分を生成 AI に任せることで、エンジニアはより創造的で付加価値の高い、業界特化の音声認識ロジックやプロンプト設計といった本質的な価値創出に集中することができました。この結果、ハッカソンイベント期間中に実用的な機能を持つシステムを完成させ、従来の開発手法では実現困難な短納期開発を成功させることができました。 お客様の声（アサイクル株式会社様） DEVCRAFT では、AI コーディングエージェントを活用することで、短期間でのプロトタイプ開発が実現できました。イベント期間中に要件定義から実装まで一貫して取り組み、実用的な機能を持つシステムを完成させることができました。この成功は、AWS のマネージドサービスの使いやすさと、AI コーディングエージェントによる開発効率化の相乗効果によるものです。インフラ構築の負担を軽減してビジネスロジックの開発に集中できたことが、短期間での成果創出につながりました。 まとめ 本事例は、営業活動における音声データ活用の好例です。今回作成した音声会話要約ソリューションにより、展示会やオンラインデモでの記録作業を自動化し、営業担当者が顧客との対話に集中できる環境を構築されました。特に注目すべきは、AI コーディングエージェントを活用することで、短期間のハッカソンイベントにおいて実用的なソリューションを構築できた点です。本事例が、営業活動の効率化や音声データ活用をご検討中のお客様の参考になれば幸いです。AWS による音声データ活用、生成 AI 活用、AI コーディングエージェントを用いた高速開発にご興味をお持ちの方は、お気軽にご相談ください。 アサイクル株式会社（左から）： 打越 隆志 様、代表取締役社長 浅井 亨介 様、谷川 祐一 様、銭谷 武 様、佐竹 智樹 様 Amazon Web Services Japan : アカウントマネージャー 植木 輝（左端） ソリューションアーキテクト 森 瞭輔（右端） ソリューションアーキテクト 森

データベース監視は、堅牢で信頼性の高いアプリケーションを維持するための重要な側面です。 Amazon RDS for SQL Server インスタンスの効果的な監視により、チームは最適なデータベースパフォーマンスを維持し、シームレスな運用を確保できます。モダンな監視ソリューションは、データベース管理者、開発者、運用チームがデータベース環境を管理する方法を革新し、プロアクティブな問題検出と迅速な対応機能を可能にしています。これらの進歩は、システムの信頼性向上、メンテナンスワークフローの合理化、複数のデータベースインスタンス全体でのリソース使用率の最適化という魅力的な機会を提供します。これまでチームは手動でのログチェックや断片化された監視ツールという課題に直面してきましたが、今日の自動化されたリアルタイム通知システムは、応答時間を大幅に短縮し、システムダウンタイムを最小限に抑える革新的なデータベース管理アプローチを提供します。 この投稿では、AWS ネイティブサービスと Slack 統合を使用して、Amazon RDS for SQL Server の効率的なサーバーレス監視システムを構築する方法を示します。 ソリューション概要 このソリューションは、Amazon RDS for SQL Server、 Amazon CloudWatch 、 AWS Lambda 、および Slack サービスを統合することで、データベース監視に対する効率的でサーバーレスなアプローチを提示します。これらの AWS サービスと Slack のコミュニケーションプラットフォームを使用することで、データベースの問題についてチームに自動的にアラートを送信する合理化された通知システムを構築します。このアーキテクチャは手動監視の必要性を排除し、データベースの健全性に対するリアルタイムの可視性を提供します。 処理するには、エラーが検出されたときに自動的にトリガーされる Lambda 関数を実装します。Lambda 関数は、ログデータをデコードして読みやすいメッセージにフォーマットするために必要な権限と依存関係で構成されています。これらのメッセージは最初に Amazon DynamoDB テーブルに保存され、その後セキュアな Webhook 統合を通じて指定された Slack チャンネルに配信され、データベース管理者とサポートチームへの即座の通知を可能にします。 このサーバーレスアーキテクチャは、潜在的な問題の迅速な通知をしながら、最小限のメンテナンスでリアルタイムデータベース監視を行うコスト効率に優れたスケーラブルなソリューションを提供します。エラーの発生から Slack 通知までの全プロセスは通常数秒以内に完了し、データベース問題への迅速な対応とシステム信頼性の向上を可能にします。 以下の図は、ソリューションのアーキテクチャを示しています。 DynamoDB のアイテムは 48 時間後 (設定可能) に自動的に削除されます。これにより、ストレージ料金を削減してコストを最適化し、テーブルを軽量に保つことでクエリパフォーマンスを向上させ、古いデータの自動クリーンアップによってより良いデータ管理を提供します。また、同じエラーメッセージが 15 分間 (設定可能) のウィンドウ内で複数回発生した場合、最初のインスタンスのみが Slack に送信されます。これにより通知スパムを防ぎ、運用の明確性を維持するのに役立ちます。 通知プロセスは、Amazon RDS for SQL Server がエラーログを生成し、 CloudWatch ロググループ に公開した時点で開始されます。新しいログが到着すると、 CloudWatch サブスクリプションフィルター がこれらのエントリを継続的に監視し、事前定義されたエラーパターンと照合します。一致するエラーパターンが検出されると、フィルターは自動的に Lambda 関数をトリガーします。Lambda 関数は、まず CloudWatch からデータをデコードして解凍しログエントリを処理します。タイムスタンプ、ロググループの詳細、実際のエラーメッセージなどの重要な情報を抽出し、DynamoDB に保存します。処理後、Lambda 関数はこの情報を読みやすいメッセージにフォーマットし、安全な Webhook URL を通じて指定された Slack チャンネルに送信します。チームメンバーは、RDS インスタンスで元のエラーが発生してから数秒以内にこれらの通知を受け取ります。この合理化されたアプローチにより、データベース管理者とサポートチームが潜在的な問題を迅速に特定して対応できるようになり、最適なデータベースのパフォーマンスと信頼性を維持できます。 このソリューションを実装する主要なステップは以下のように要約できます： RDS for SQL Server のエラーログを CloudWatch ログループに公開する CloudWatch ログを処理する Lambda 関数を作成・設定する エラーを監視するための Lambda サブスクリプションフィルターを設定する Slack チャンネルを作成し、受信 Webhook を設定する Slack 通知用の Webhook URL で Lambda 環境を設定する 前提条件 このソリューションを実装するには、RDS for SQL Server インスタンスが既に設定され稼働しているアクティブな AWS アカウントが必要です。CloudWatch、Lambda、 AWS Identity and Access Management (IAM) を含む AWS サービスにアクセスして設定できる十分な権限を持っている必要があります。これには、Lambda 関数の作成と変更、CloudWatch ログループの管理、IAM ロールとポリシーの作成、RDS インスタンス設定の変更を行う機能が含まれます。 Slack 統合では、チャンネルを作成し Webhook 統合を設定できる Slack ワークスペースへの管理者アクセスが必要です。これらの権限は、受信 Webhook の設定とチーム向けの通知チャンネルの設定を行うために不可欠です。 RDS デプロイメントタイプ (シングル AZ またはマルチ AZ) の選択は、このソリューションにおける最大のコスト要因となる可能性があるので注意が必要です。続行する前に、 Amazon RDS 、 CloudWatch 、および AWS Lambda の料金ページを確認し、このソリューションを実装することのコストへの影響を理解することをお勧めします。 RDS ログの CloudWatch へのエクスポートを設定 最初に、エラーログを CloudWatch にエクスポートするために RDS for SQL Server インスタンスを設定する必要があります。この設定により、一元的なログ保存が可能になり、通知システムの基盤が構築されます。RDS for SQL Server のエラーログを CloudWatch に公開するには、DB インスタンスを変更する必要があります。以下の手順を完了してください： Amazon RDS コンソールのナビゲーションペインで、「データベース」を選択します 変更したい DB インスタンスを選択します 「変更」を選択します 「ログのエクスポート」セクションで、CloudWatch への公開を開始したいログを選択します。この投稿では、「エラーログ」を選択し、「続行」をクリックします 確認ページで変更内容を確認し、変更を即座に適用するには「すぐに適用」を選択します。変更を保存するには「DB インスタンスを変更」を選択します。または、変更を修正するには「戻る」を選択し、変更をキャンセルするには「キャンセル」を選択します これで、リアルタイム Slack 通知を使用した CloudWatch ログ処理フローをセットアップする準備が整いました。 Slack チャンネルの受信 Webhook を作成 通知システムの次のステップでは、アラートの送信先を設定します。Lambda 関数がフォーマットされたメッセージを送信できる安全な URL エンドポイントを提供する Slack webhook を作成します。これにより、指定された Slack チャンネルにエラー通知を自動投稿でき、チームメンバーが問題を監視し対応できるようになります。以下の手順を完了してください : Slack ワークスペースを開きます ワークスペース設定に移動します アプリと連携を選択します Incoming Webhooks を検索します Slack に追加を選択します 通知用のチャンネルを選択します Webhook URL をコピーします – 次のステップで必要になります Lambda 関数を作成し、関連リソースを設定 このステップでは、CloudWatch ログを処理するコアとなるサーバーレス Lambda 関数を作成します。Lambda 関数は Python で記述され、CloudWatch ログデータをデコードし、関連するエラー情報を抽出し、Slack 通知用にフォーマットするロジックが含まれています。この関数は、監視ソリューションの中央処理装置として機能します。Lambda 関数を作成するために、以下の手順を完了してください : GitHub からプロジェクトリポジトリ をクローンまたはダウンロードしてローカルマシンに保存します ターミナルでプロジェクトのルートディレクトリに移動します 前提条件が満たされていることを確認します AWS CLI がインストールされ、適切な権限が設定されていること Python 3.12 がローカルにインストールされていること (デプロイメントスクリプトが独立した仮想環境を作成します)。システムに Python 3.12 をインストールする方法については、README.md を参照してください。 zip ユーティリティが利用可能であること IAM、Lambda、DynamoDB に対する適切な AWS 権限 (README.md ファイルの前提条件セクションを参照) 自動デプロイメントスクリプトを実行します : ./scripts/deploy.sh プロンプトが表示されたら、前のステップで作成した Slack Webhook URL を入力してください スクリプトは自動的に以下を実行します : システムに Python 3.12 がインストールされていることを確認する 分離された Python 3.12 仮想環境を作成する 依存関係の分離のために仮想環境をアクティベートする 分離された環境に urllib3 をインストールする DynamoDB アクセス許可を持つ IAM ポリシー (SlackNotifierLambdaPolicy) を作成する 適切な信頼関係を持つ IAM ロール (SlackNotifierLambdaRole) を作成する Python 3.12 を使用して urllib3 Lambda レイヤーをビルドして公開する Lambda 関数 (SlackNotifier) をパッケージ化してデプロイする Slack Webhook URL を含む環境変数を設定する urllib3 レイヤーを関数にアタッチする 一時ファイルをクリーンアップする 仮想環境を非アクティブ化する 免責事項 : このプロセスの一部として作成された IAM ポリシー (SlackNotifierLambdaPolicy) は、一般的なガイドラインとしてのみ機能します。お客様の特定の要件とコンプライアンス基準に従って、すべてのセキュリティ対策を確認、カスタマイズ、および検証する必要があります。AWS のベストプラクティスでは、ユーザーがタスクを実行するために必要な最小限の権限のみを付与する最小権限の原則の実装を強く推奨しています。 AWS IAM ドキュメント で詳述されているこのコアセキュリティ概念は、潜在的なセキュリティリスクを最小限に抑えるのに役立ちます。 CloudWatch ログループの Lambda サブスクリプションフィルターの作成 サブスクリプションフィルターはトリガーメカニズムとして機能し、どのログエントリを Lambda 関数に送信すべきかを定義します。CloudWatch ロググループ内の特定のエラーパターンを監視するように設定し、関連するログのみが処理され、不要な関数呼び出しが回避されるようにします。先ほど作成した Lambda 関数を使用して Lambda サブスクリプションフィルターを作成するには、以下の手順を完了してください： CloudWatch コンソールで、ナビゲーションペインの「ロググループ」を選択します SQL Server ロググループを選択します 「アクション」メニューで「サブスクリプションフィルター」を選択し、「Lambda サブスクリプションフィルターの作成」を選択します Choose destination セクションのドロップダウンから Lambda 関数 (SlackNotifier) を選択してください Configure log format and filters の下で、以下の Subscription filter pattern を入力してください : ?ERROR ?EXCEPTION ?FAILURE ?CRITICAL? FATAL ?error ?exception ?fail ?severity ?deadlock ?timeout ?terminated ?violation ?denied ?insufficient ?overflow ?syntax ?invalid ?unable ?cannot ?failed ?corrupt ?inconsistent "Error: 18456" "Error: 17806" "Error: 233" "Error: 1205" "Error: 3041" "Error: 8152" ?error ?Error ?Failed ?failed ?Severity ?severity Code サブスクリプションフィルターに名前を付けてください。この投稿では、Error Subscription Filter を使用します (オプション) テストパターンセクションでこの設定をテストできます。「テストするログデータを選択」ドロップダウンからデータベースを選択し、「パターンをテスト」をクリックしてください。結果セクションでフィルターパターンに一致するログが表示されるはずです 「ストリーミングを開始」をクリックしてください これで、すべてのデータベースエラーログが処理され、CloudWatch ログストリームを通じてアクセス可能になります この最終ステップにより、Amazon RDS for SQL Server の自動監視ソリューションの実装が完了しました。これで、システムはSQL Server エラーをキャプチャし、Slack チャンネルに通知を送信する準備が整いました。Lambda 関数は Webhook URL を使用して Slack と安全に通信し、データベースエラーが発生した際、チームに即座に通知を送信します。これらの通知には、エラーメッセージ、タイムスタンプ、コンテキストの詳細などの重要な情報が含まれており、チームが潜在的な問題を迅速に評価し対応できるようになります。システムはバックグラウンドで継続的に動作し、データベースログの監視に手動での介入は必要ありません。 ソリューションの検証 実装が意図したとおりに動作していることを確認するために、簡単な検証テストを実行できます： SQL Server Management Studio (SSMS) を使用して RDS for SQL Server インスタンスに接続します。次のスクリーンショットに示すように、データベース SlackNotifications を使用します。 デモンストレーション目的で RAISERROR WITH LOG オプションを使用してエラーメッセージを作成します << RAISERROR('This error has been raised using RAISERROR', 16, 1) WITH LOG; >> Code 先ほど言及されたエラーについて、SQL Server エラーログを確認してください << EXEC rdsadmin.dbo.rds_read_error_log @index = 0, @type = 1, @search_str1= 'This error has been'; >> Code RDS for SQL Server のエラーログを CloudWatch に公開したので、次のステップはエラーが CloudWatch にエクスポートされているかどうかを確認することです。 CloudWatchコンソールで、ナビゲーションペインの「ログ」の下にある「ロググループ」を選択します DB インスタンスの RDS for SQL Server エラーログを選択します (この投稿では、 /aws/rds/instance/<<your db instance>>/error ) 「ログストリーム」タブで、データベースが実行されているアクティブノードを選択します (これは特定の環境によって異なる場合があります) タイムスタンプとともにエラーメッセージを確認できます。 数秒以内に、設定された Slack チャンネルにこのテストエラーが通知として表示されるはずです。以下のような感じです： CloudWatch Logs を確認して RDS ログが正常にエクスポートされ、Lambda 関数がこれらのログを正しく処理していることを確認することで、システムの動作を検証することもできます。 考慮事項 このソリューションを実装する際は、最適なパフォーマンスとコスト効率を実現するために、いくつかの重要な点に注意することが大切です： RDS for SQL Server エラーログを CloudWatch に公開する前に、機密情報を保護するためのカスタムマスキングロジックを実装してください。これらのログには機密データが含まれている可能性があるため、特定のビジネス要件に基づいてこのアプローチを評価してください。 デフォルトの「期限切れなし」設定はストレージコストを増加させる可能性があるため、要件に基づいて CloudWatch Logs の保持期間を設定してください。 セキュリティのため、Lambda 実行ロールが最小権限の原則に従っていることを確認し、Slack の Webhook URL などの機密情報を Lambda 環境変数で表示したくない場合は、AWS Systems Manager Parameter Store または Secrets Manager に保存してください。 CloudWatch メトリクスを通じて Lambda 関数のパフォーマンスとエラーを定期的に監視 してください。 これはサンプル実装ですが、本番環境での信頼性を確保するために、Lambda 関数に適切なエラーハンドリングを追加することを確認してください。 この実装は、最小権限を持つ IAM ロール、機密情報のための環境変数、依存関係管理のための Lambda レイヤーを使用して、セキュリティとスケーラビリティのための AWS ベストプラクティスに従っています。このアプローチは、信頼性の高い監視を提供するだけでなく、ニーズに応じて自動的にスケールするサーバーレスコンポーネントを使用することでコスト効率性も維持します。このソリューションは、複数のデータベースインスタンスを監視するように適応したり、追加のエラーパターンや通知形式を含むように変更したりできます。 クリーンアップ 不要な料金の発生を避け、AWS の環境をクリーンに保つために、以下の手順に従ってこのソリューションで作成されたリソースを削除します : DB インスタンスの削除 Lambda リソースを削除する : 自動化されたアンデプロイスクリプトを実行する : ./scripts/undeploy.sh CloudWatch リソースを削除する : CloudWatch ロググループからサブスクリプションフィルターを削除する 不要になった場合は、CloudWatch への RDS エラーログエクスポートを無効にする CloudWatch ロググループに保存されているログが不要になった場合は、削除を検討する Slack のクリーンアップ : Slack チャンネルから Incoming Webhook インテグレーションを削除する この目的のために専用に作成された通知チャンネルがある場合は、アーカイブまたは削除する 結論 この投稿では、AWS ネイティブサービスと Slack 統合を使用して、Amazon RDS for SQL Server 向けの効率的でサーバーレスなリアルタイム監視システムを構築する方法を紹介しました。エラー通知プロセスを自動化することで、チームはデータベースの問題への対応時間を大幅に短縮し、アプリケーションへの潜在的な影響を最小限に抑えることができます。最も重要なことは、この自動通知システムが従来のデータベース監視アプローチをリアクティブなものからプロアクティブなものに変革することです。チームはもはやログを手動でチェックしたり、重要なデータベースエラーを見逃すことを心配したりする必要がありません。リアルタイム Slack 通知により、チームは問題の検出ではなく解決に集中でき、最終的にデータベースの信頼性向上と運用オーバーヘッドの削減につながります。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Sandip Samanta Sandip は AWS インドのテクニカルアカウントマネージャーで、エンタープライズのお客様の AWS クラウドジャーニーの加速を支援しています。クラウドアーキテクチャとソリューション設計における豊富な経験を持ち、技術的ガイダンスとアーキテクチャのベストプラクティスを通じてお客様が AWS への投資を最大化できるよう支援することに注力しています。 Kanchan Bhattacharyya Kanchan は、AWS のシニアテクニカルアカウントマネージャーです。彼は企業のデータベース運用の最適化を専門としています。SQL Server、PostgreSQL、MySQL、Amazon Aurora を含む Amazon RDS プラットフォーム全体にわたる深い専門知識を活用し、組織がクラウド投資を最大化できるよう戦略的ガイダンスを提供しています。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2025 年 9 月のアップデートまとめ はお読みいただけましたでしょうか。今月も 以下の内容でアップデート 情報をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートについて 2025 年 10月のアップデート一覧 AWS Contact Center Blog のご紹介 AWS Black Belt オンラインセミナー (Amazon Connect 関連) 1.注目のアップデートについて Amazon Connect で生成 AI を活用したメールの会話の概要と推奨応答を提供 Amazon Connect で、生成 AI を活用したメール会話の概要、推奨アクション、メール会話への応答(下書き)がエージェントに提供されるようになりました。これにより、エージェントはメールをより効率的に処理できるようになり、顧客はより迅速で一貫したサポートを受けることができます。例えば、顧客から返金リクエストのメールを受信すると、Amazon Connectは購入履歴から重要情報を提供し、返金処理の手順をガイドしながら、適切な返信メールを自動生成することで、問い合わせを迅速に解決します。 この機能を有効にするには、メールによる問い合わせをエージェントに割り当てる前に、 Amazon Q in Connect ブロック をフローに追加します。 ナレッジベース を追加して プロンプトを定義 することで、メールの生成 AI を活用したアシスタントの出力をカスタマイズできます。これにより、一貫したカスタマーサービスを提供するために、会社の言語、口調、ポリシーに合った応答を AI エージェントに生成させることができます。 Amazon Q in Connect はユースケースに応じた AI エージェントと AI プロンプトを提供します。今回、E メール 用に新たに3つの AI エージェントと4つの AI プロンプトが追加されました。これらを使用して、Amazon Q in Connect はお客様から受信した問い合わせ E メールに対して、「メール会話の概要」「関連するナレッジベースと推奨アクション」「メール会話への応答(下書き)」を提供します。 本機能の利用を開始するには、上述した AI プロンプトと それらを使用した AI エージェントを設定してください。日本語に対応した AI エージェントを設定する際は、AI エージェントの設定画面のロケールで「Japanese」を指定します。 設定の詳細については以下の Amazon Connect 管理者ガイドをご参照ください E メールの概要と推奨されるレスポンスを使用する AI プロンプトを作成する AI エージェントを作成する 2. 2025年10月のアップデート一覧 Amazon Connect が会話の録音とトランスクリプトに対する詳細なアクセス許可の提供を開始 – 2025/10/24 Amazon Connect で、会話の録音データと文字起こしデータへのアクセス権限を、UI を通じてより詳細に設定できるようになりました。この新機能により、管理者はより柔軟でセキュアなアクセス制御を実現できます。コンタクトセンターの管理者は、録音データと文字起こしデータへのアクセス権限を個別に設定できるようになりました。例えば、ユーザーが通話を聞くことはできても、文字起こしデータの不正なコピーを防止するといった制御が可能です。システムは、ダウンロード制御の柔軟性も向上しています。編集済み（機密情報などがマスキング処理された）録音データのダウンロールは許可しつつ、未編集版のダウンロードは制限するといった設定が可能です。さらに、管理者は機密性の高い会話については編集済みの録音データへのアクセスのみを許可し、その他の一般的な会話については未編集の録音データへのアクセスを許可するなど、より高度な権限設定のシナリオを作成することができます。このアップデートにより、セキュリティとコンプライアンスの要件に応じた、より緻密なアクセス制御が可能になり、コンタクトセンターの運用における安全性と効率性が大幅に向上します。  関連リンク 管理者ガイド Amazon Connectのアウトバウンドキャンペーンがプレビューダイヤリングに対応し、エージェントの制御性を向上 – 2025/10/24 Amazon Connect のアウトバウンドキャンペーン機能に、通話開始前に顧客情報を確認できるプレビューダイヤルモードが追加されました。この機能により、エージェントは発信前に顧客の名前、アカウント残高、過去のやり取りなどの重要な情報を確認し、最適なタイミングで発信することができるようになりました。また、キャンペーンマネージャーはプレビュー設定をカスタマイズし、エージェントの行動、キャンペーン結果、顧客エンゲージメントの傾向を新しいダッシュボードで監視できるようになっています。この機能が重要である背景として、適切な情報がないまま電話をすることにより、エージェントは顧客に応じた対応に苦労し、結果として顧客の信頼や満足度の低下に繋がります。さらに、米国電話消費者保護法(TCPA)や英国通信庁(OFCOM)の規制により、顧客とエージェントの接続の遅延に対して厳しい罰則が科される可能性があることも考慮されています。新しいプレビューダイヤリング機能では、マネージャーは確認時間の制限を設定し、必要に応じてキャンペーンからのコンタクトの削除を有効にできます。エージェントは顧客データとともにカウントダウンタイマーを確認でき、任意のタイミングで発信が可能です。また、平均プレビュー時間や破棄数などの分析データにより、戦略の最適化とチームの効果的な指導を行うことができます。発信前にエージェントを確保することで、規制遵守をサポートしながら、アウトバウンドコールの精度を向上させることができます。これにより、顧客との接続性と運用管理の両方が改善され、より効果的なアウトバウンドキャンペーンの実施が可能になります。  関連リンク 管理者ガイド Amazon Connect がスレッド表示に対応し、エージェントの返信に会話履歴が含まれるように   – 2025/10/23 Amazon Connect の E メール に、会話の文脈を理解しやすくする新機能が追加されました。エージェントの返信に過去のやり取りの履歴が自動的に含まれるようになり、さらにメールのやり取りをスレッド形式で表示できるようになりました。この機能強化により、エージェントと顧客の双方が過去のコミュニケーション内容を簡単に確認できるようになり、会話の流れや文脈を把握しやすくなりました。これは一般的なメールクライアントでよく見られる機能を取り入れたもので、エージェントと顧客の両者にとって、より自然で使い慣れた形でのメールコミュニケーションが可能になります。このアップデートは、顧客とエージェント間のコミュニケーションをよりスムーズにし、サービス品質の向上に貢献することが期待されます。 関連リンク 管理者ガイド Amazon Connect が初期評価結果に基づく自動フォローアップ評価のサポートを開始 – 2025/10/21 Amazon Connect に、新しい自動フォローアップ評価機能が追加されました。この機能により、初回の評価結果に基づいて、特定の状況を分析するためのフォローアップ評価を自動的に開始することが可能になります。例えば、顧客サービスの初回評価において顧客が商品に対して興味を示していることが検出された場合、システムは自動的にエージェントの営業パフォーマンスに焦点を当てたフォローアップ評価を開始することができます。これにより、マネージャーはエージェントグループ間で一貫した評価基準を維持しながら、時間の経過に関係なく評価の質を保つことができます。さらに、営業機会やエスカレーション、その他の重要なやり取りなど、特定のシナリオについてより深いインサイトを得ることが可能になりました。このような自動化された評価プロセスにより、品質管理の効率化とサービス品質の向上が実現できます。 関連リンク 管理者ガイド Amazon Connect がスケジュール遵守に関する設定可能なしきい値を提供開始 -2025/10/14 Amazon Connect で、スケジュール遵守に関する設定可能なしきい値の提供が開始され、エージェントのパフォーマンスをより柔軟に追跡できるようになりました。エージェントのシフト開始または終了の繰り上げと繰り下げや、個々のアクティビティのしきい値を定義できます。例えば、エージェントがシフト開始を 5 分繰り上げ、終了を 10 分繰り下げ、休憩の終了を 3 分繰り下げても、遵守スコアに悪影響が及ばないようにできます。これらのしきい値は、個々のチームに合わせてさらにカスタマイズできます。例えば、対応に長い時間を要する問い合わせを処理するチームは休憩の開始時間をより柔軟に設定できます。今回のリリースにより、マネージャーは本当の遵守違反に目を向け、軽微なスケジュール逸脱がエージェントのパフォーマンスに及ぼす影響を除外できるようになり、マネージャーの生産性とエージェントの満足度が向上します。  関連リンク 管理者ガイド Amazon Connect がエージェントスケジュール準拠の通知をサポート -2025/10/11 Amazon Connect では、エージェントのスケジュール準拠通知がサポートされるようになりました。これにより、エージェントがスケジュールされたアクティビティを順守していないことを積極的に特定することが簡単になります。エージェントが準拠基準値を超えたときに、EventBridge 経由でメールまたはテキスト通知をスーパーバイザーに自動的に送信するルールを定義できます。たとえば、エージェントの準拠率が直近の 15 分間で 85％ を下回った場合、スーパーバイザーはメールでアラートを受信できます。これらの自動通知により、ダッシュボードを継続的にモニタリングする必要がなくなり、サービスレベルが低下する前に積極的な介入が可能になり、スーパーバイザーの生産性と顧客満足度の両方が向上します。 関連リンク 管理者ガイド Amazon Connect でエージェントのスケジュール設定のコピーと一括編集をサポート -2025/10/10 Amazon Connect では、エージェントのスケジュール設定のコピーと一括編集がサポートされるようになり、設定と管理が容易になりました。既存のスケジュール設定をコピーして新しいスケジュール設定を作成できます。たとえば、平日のシフトプロファイルをコピーして週末のバリエーションを作成したり、既存のエージェントのスケジュール設定 (タイムゾーン、週ごとの勤務時間、休日など) を既存のエージェントから複数の新入社員にコピーしたりできます。一括編集では、週ごとの勤務時間を変更せずに、新入社員のタイムゾーンや開始日を更新するなど、特定の項目を選択して更新できます。このような更新により、管理者が構成管理に費やす時間が短縮され、生産性と運用効率が向上します。 関連リンク 管理者ガイド Amazon Connect で、関連ケースをリンクし、カスタム関連項目を追加し、それらを検索するための新しいケース API をリリース -2025/10/07 Amazon Connect では、関連するケースをリンクしたり、カスタム関連項目を添付したり、それらを検索したりして、ケースデータをプログラムで拡充できるようになりました。これにより、エージェントは問題をより迅速に解決するために必要なすべてのコンテキストを把握できます。例えば、航空会社は 1 件のフライトキャンセルに関連するすべての顧客ケースをリンクして再予約を調整し、事前に最新情報を送信できます。また、小売業者は注文と配送の詳細を返金リクエストに添付して、より迅速な解決を実現し、顧客に常に情報を提供できます。 関連リンク API リファレンス Amazon Connect でサービスレベルの計算がカスタマイズ可能に -2025/10/06 Amazon Connect では、特定のニーズに合わせてサービスレベルの計算をカスタマイズできるようになりました。スーパーバイザーとマネージャーは、問い合わせがサービスレベル基準を満たしていると見なされる時間しきい値を定義し、どの問い合わせの結果を計算に含めるかを選択できます。例えばマネージャーは、設定可能な時間しきい値を使用して、コールバック問い合わせの数を数えたり、キューで待機している間に転送された問い合わせを除外したり、短期間の離脱を除外したりすることができます。サービスレベルの計算のカスタマイズは、分析ダッシュボードのメトリクス設定セクションから実行できます。この機能により、スーパーバイザーとマネージャーは、事業運営により合致したサービスレベルメトリクスの計算を作成できるようになりました。サービスレベルのパフォーマンスをカスタマイズして表示することで、運用マネージャーはサービス基準をどの程度効果的に満たしているかを評価できます。 関連リンク 管理者ガイド Amazon Connect で生成 AI を活用したメールの会話の概要と推奨応答を提供 -2025/10/03 注目アップデート をご覧ください！ Amazon Connect で ChromeOS でのエージェント画面録画のサポートを開始 -2025/10/03 Amazon Connect では、ChromeOS デバイスを使用するエージェントに対して画面録画機能が提供されるようになり、エージェントのパフォーマンスを簡単に向上させることができるようになりました。画面録画を使用すると、顧客との通話を聞いたり、チャットの文字起こしを確認したりするだけでなく、問い合わせを処理する際のエージェントのアクション (音声通話、チャット、タスクなど) を監視することで、エージェントにコーチングが必要な領域 (例: 対応の処理時間が長い、ビジネスプロセスの違反など) を特定できます。 関連リンク 管理者ガイド Amazon Connect 料金 Amazon Connect が分析データレイクでエージェントの休暇残数データを提供 -2025/10/03 Amazon Connect が分析データレイク* でエージェントの休暇残数データを提供するようになり、このデータからレポートやインサイトを簡単に生成できるようになりました。このリリースにより、分析データレイクのさまざまな休暇カテゴリ (有給休暇、病気休暇、休業など) にわたる最新および過去のエージェントの休暇残数にアクセスできるようになりました。残数に加えて、残数に影響を与えたすべてのトランザクションの時系列リストを表示することもできます。例えば、エージェントが 1 月 1 日に 80 時間の有給休暇を付与されて勤務を開始し、1 月 3 日に 20 時間の休暇をリクエストを送信したが、その後そのリクエストをキャンセルした場合、各トランザクションによる最終的な 80 時間の残数に対する影響を確認できます。このリリースにより、マネージャーが手動で残数と休暇トランザクションを調整する必要がなくなり、休暇管理が容易になります。これにより、マネージャーの生産性が向上し、エージェントからの問い合わせへの対応が容易になります。 * Amazon Connect 分析データレイク Amazon Connect 分析データレイク は、コンタクトセンターのデータ分析を効率化し、より深いインサイトを得るための機能です。最大の特徴は、複雑なデータパイプラインを構築することなく、Amazon Connect の運用データに直接アクセスできる点にあります。データレイクに蓄積されるデータは、通話記録やチャットトランスクリプト、エージェントのパフォーマンス指標、キューの状態、顧客とのインタラクション履歴など、コンタクトセンター運営に関わる包括的な情報が含まれています。これらのデータはすべて構造化された形式で保存され、Amazon Athena を使用して標準的な SQL クエリで簡単に分析することができます。さらに、BI ツールと統合し、カスタムレポートやダッシュボードの作成も容易です。これにより、データアナリストやビジネスユーザーは、必要な情報にすぐにアクセスし、データドリブンな意思決定を行うことができます。また、AWS の分析サービスと組み合わせることで、より高度な分析も可能となります。 関連リンク 管理者ガイド Amazon Connect で発信通話における顧客入力を簡単に取得   -2025/10/02 AWS のクラウドベースのコンタクトセンターサービスである Amazon Connect で、発信音声ウィスパーフロー用に [顧客の入力を取得する] および [顧客の入力を保存する] フローブロックがサポートされるようになりました。[顧客の入力を取得する] フローブロックを使用すると、顧客が発信通話に応答した後、エージェントに接続される前に、発信通話で顧客にプロンプトを再生できます。また、顧客の応答は DTMF 入力または Amazon Lex Bot を介して収集できます。 この機能により、エージェントへの接続前に、発信通話でインタラクティブかつ動的な顧客入力をキャプチャできます。例えば、[顧客の入力を取得する] フローブロックを使用して、エージェントによる発信通話の一部としての通話録音について顧客の同意を得て、それを使用して Amazon Connect Contact Lens の録音と分析をトリガーできます。 関連リンク 管理者ガイド( 顧客の入力を取得する / 顧客の入力を保存する ) 3. AWS Contact Center Blog のご紹介 AWS re:Invent 2025: Reimagining customer experience with Amazon Connect (英語記事) AWS re:Invent 2025が12月1日から5日にかけてラスベガスで開催されることが発表されました。今年のAmazon Connect セッションでは、AI が大きな変革を遂げた一年を経て、インテリジェントな顧客体験の未来について深く探求します。基調講演やブレイクアウトセッション、実践的な学習を通じて、企業がエージェンティックAIを活用して卓越した顧客体験を実現しながら、運用効率を向上させている事例を紹介します。特に注目のセッションとして、Amazon Connect 部門の VP である Pasquale DeMaio による「BIZ221：Amazon Connect による顧客体験におけるエージェンティック AI の進歩」が予定されており、AI を活用したカスタマーサービスの革新的な取り組みについて解説されます。また、12月2日には Cromwell の Giada にて顧客体験レセプションが開催され、AWS エキスパートや CX（カスタマーエクスペリエンス）リーダーとの交流の機会も提供されます。 4. AWS Black Belt オンラインセミナー (Amazon Connect 関連) Amazon Connect Global Resiliency 詳説 Amazon Connect Global Resiliency は Amazon Connect に地理的な冗長性を提供します。予期しない地域的な災害や障害が発生した場合にも、お問い合わせとエージェント接続を別のリージョンにあるインスタンスに分散する柔軟なソリューションを提供します。Amazon Connect が備えている信頼性を理解したい方、コンタクトセンターにおける BCP の設計に関心のある方、Amazon Connect Global Resiliency の具体的な機能が知りたい方は、ぜひご視聴ください。 資料（ PDF ） | 動画（ YouTube ） 今月のお知らせは以上です。皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は、2025 年 10 月 23 日に公開された How D2L transformed educational analytics using visual data preparation in Amazon Quick Sight を翻訳したものです。翻訳は Public Sector PSA の西川継延が担当しました。 この投稿は、D2L の Surekha Rao と Andrew Wooster が共同で執筆しました。 D2L では、世界の学習方法を変革することをミッションとしています。グローバルな学習イノベーションのリーダーとして、世界中の教育機関と緊密に連携し、学習をより刺激的で、魅力的で、人間的なものにしています。当社の主力学習管理システム（LMS）である D2L Brightspace は、数え切れないほどの教育体験の基盤として機能し、教育と学習成果の有意義な改善を推進できる貴重なデータを生成しています。 当社の Performance+ analytics suite は、教育者や管理者がエンゲージメントを監視し、リスクのある学習者を特定し、アセスメントやコース設計の有効性を評価できるように設計されています。直感的なダッシュボードと予測分析により、学習者へのタイムリーな介入とパーソナライズされたサポートを可能にします。しかし、学習エコシステムが拡大するにつれて、学習者のエンゲージメント指標、コースのパフォーマンス、機関の KPI など、管理する必要のあるデータの量と複雑さも増大しました。 この投稿では、D2L が Amazon Quick Sight の新しいデータ準備機能を使用して、Performance +パッケージの Brightspace Analytics 製品を強化した方法を紹介します。この進歩により、教育機関全体でデータインサイトが民主化されます。教育者や管理者は、技術的な専門知識を必要とせず、シンプルなクリック操作で生データを実用的なインサイトに変換できるようになります。 課題: ユーザビリティを維持しながら分析をスケールする ユーザーベースが拡大するにつれて、パフォーマンスや使いやすさを損なうことなく、分析機能をスケールさせるプレッシャーが高まりました。教育機関は厳しい予算制約の下で運営されることが多く、専任のデータサイエンスチームを持たない機関も少なくありません。私たちは、コスト効率が高く予測可能でありながら、さまざまなスキルレベルでデータインサイトを民主化できるソリューションが必要でした。Quick Sight を採用する前は、分析を効果的にスケールさせる能力を制限するいくつかの技術的課題に直面していました。 手頃な価格とコストの予測可能性 – 以前使用していたツールの多くは、ユーザー数やコンピューティング使用量に紐づく複雑な価格モデルを採用していました。これにより、コストの予測が困難になり、持続可能な方法で顧客に分析機能を提供することが難しくなっていました。リソースが限られている教育機関にとって、この予測不可能性は導入の大きな障壁となっていました。 リージョンの可用性とデータレジデンシー – 世界中の教育機関にサービスを提供しているため、マルチリージョンデプロイメントをサポートし、進化するデータレジデンシー要件に対応できるソリューションが必要でした。以前のツールには、データ主権の懸念に対処するために必要な柔軟性がなく、地理的に分散したリージョンのユーザーにサービスを提供する際にレイテンシーの問題が発生していました。 インサイトへの技術的障壁 – おそらく最も重要なことは、従来のデータ準備ツールでは SQL やプログラミングの専門スキルが必要とされることが多かったことです。これにより、教育者や管理者がインサイトにアクセスする前に、技術チームがデータを準備および変更する必要があったため、分析プロセスにボトルネックが生じていました。 ソリューション概要 新しい Quick Sight のデータ準備体験は、教育分析へのアプローチに⾰命をもたらしました。データ変換に GUI ベースのローコードなインターフェースを提供することで、技術的な障壁が取り除かれ、あらゆるスキルレベルのユーザーがデータを直接扱えるようになりました。 強化されたデータ準備機能により、Aggregate、Filter、Pivot、Unpivot、Append の各変換がサポートされるようになりました (更新されたナビゲーションペインのスクリーンショットに示されています)。これらはすべて、GUI ベースのローコードインターフェースを通じて利用できます。これらの機能がデータ準備プロセスを大幅に効率化しました。 教育機関では、教育者や管理者が以下のことを行えるようになりました。 データへのアクセスと変換を独立して実行 – 教職員は、SQL やプログラミングの知識を必要とせずに、データのクリーニング、変更、結合を行うことができます。これにより、技術チームへの依存が減り、より多くの人がデータを直接扱えるようになり、より迅速なインサイトの獲得とより機敏な意思決定につながります。 実用的なインサイトを迅速に生成 – ポイントアンドクリックのインターフェースとビジュアルワークフローにより、ユーザーはワークフローとダッシュボードを迅速に構築できます。これは、タイムリーな介入が学生の成功に大きな影響を与える可能性がある、ペースの速い教育環境に最適です。 部門全体で分析をスケール – 直感的なツールにより、教育機関は複雑なコーディングや Extract、Transform、Load (ETL) ツールについて全員をトレーニングする必要なく、部門全体で分析をスケールできます。このデータアクセスの民主化により、組織全体でよりデータに基づいた文化を創出できます。 リソース配分の最適化 – 専門的なデータエンジニアリングリソースの必要性を減らすことで、Quick Sight は限られた予算の教育機関にとって、分析をより手頃で予測可能なものにします。 次のワークフローは、Brightspace の生データセットが視覚的に変換され、統合された洞察に富んだデータセットになる様子を示しています。この変換により、学習者の登録情報とユーザーの人口統計情報をより深く分析できるようになり、カリキュラム計画とサポート戦略全体でデータドリブンな意思決定が可能になります。 データソースと統合 Quick Sight 実装の主な強みの 1 つは、複数のソースからデータを取得できることです。Quick Sight は、 Brightspace Learning Management System (LMS) と Data Hub の Brightspace Data Sets (BDS) と統合され、学習者のエンゲージメント、コースのパフォーマンス、インストラクターのアクティビティに関する豊富なデータを取得します。また、以下を含むさまざまな Quick Sight データソースを通じて、お客様が追加データを取り込むことをサポートしています。 1 回限りの (アドホック) 分析のためのファイルアップロード データベース接続 (MySQL、PostgreSQL、Oracle、SQL Server、 Amazon Aurora 、MariaDB) データプラットフォーム (Databricks、Spark、Teradata) クエリエンジン (Presto、Starburst、Trino) この柔軟性により、教育機関は運用の包括的なビューを作成し、学習データを他のシステムからの情報と組み合わせて、運用全体の改善を推進できます。 実世界への影響: 教育における意思決定の変革 Brightspace と統合することで、Quick Sight は教育における データに基づいた意思決定の推進力として機能します。学習分析を日常のワークフローに組み込むことで、教育者や管理者がより賢明でリアルタイムな意思決定を行い、学習成果にポジティブな影響を与えることを支援します。 たとえば、教員は学生のエンゲージメントデータのパターンを迅速に特定し、問題になる前に潜在的な課題を発見できるようになりました。教授は、学生が特定のモジュールに他のモジュールと比較して著しく少ない時間しか費やしていないことに気づけ、そのコンテンツの改訂や追加のサポートリソースが必要である可能性を示唆できます。 同様に、管理者は部門全体の組織的な KPI を追跡し、優れた領域と改善の機会を特定できます。技術チームがデータを準備するのを待つことなく、コース修了率、アセスメント結果、プラットフォーム採用トレンドを分析できます。 その影響は、運用効率以外の領域にも及びます。Quick Sight はデータインサイトへのアクセスを民主化することで、教育機関全体でエビデンスに基づく意思決定の文化を育むのに役立ちます。教員は自分でデータを探索できるようになることで、データへの関心が高まり、教育と学習に対するより革新的なアプローチにつながります。 教育エコシステム全体にわたる分析のスケーリング 現在、D2L の顧客の大部分が当社の分析ソリューションにアクセスしており、教育におけるデータの価値に対する認識が高まっていることを示しています。Performance +アドオンパッケージをご利用のお客様は、機関のニーズに応じてスケールする組み込み分析機能にアクセスできます。 このアプローチにより、予測可能なコスト構造を維持しながら、さまざまな規模の機関全体で分析をスケールすることが可能になります。リソースが限られている教育機関にとって、この予測可能性は長期的な計画と持続可能性にとって極めて重要です。 Quick Sight のローコードなデータ準備機能は、このスケーリングの取り組みにおいて特に価値がありました。技術的な障壁を取り除くことで、さまざまなスキルレベルのユーザーがインサイトにアクセスしやすくなり、教育者、管理者、ビジネスチームが日常業務でデータを活用できるようになりました。 教育分析の未来 今後を見据えて、私たちは学習成果と業務生産性能向上のため、導入の加速と分析の日常業務への組み込みに注力しています。 教育ワークフローとのより深い統合 – 分析機能を教育体験にさらに組み込むことで、データに基づいた意思決定を別の活動としてではなく、教育業務の自然な一部にすることを目指しています。 予測機能の強化 – Quick Sight の機械学習 (ML) 機能を基盤として、リスクのある学生をより高い精度で特定し、的を絞った介入を提案できる、より高度な早期警告システムの提供に取り組んでいます。 機関間ベンチマーク – プライバシーとデータガバナンスの要件を尊重しながら、機関がより広い文脈で自らのパフォーマンスを理解できるよう、匿名化されたベンチマークを提供する機会があると考えています。 セルフサービス分析の拡張 – Quick Sight のローコードアプローチを基盤として、技術者以外のユーザーが特定のニーズに合わせた独自のレポートやダッシュボードを作成できるよう、さらに支援する予定です。 まとめ D2L では、スケールし、コンプライアンスをサポートし、データへのアクセスを民主化するツールを教育機関に提供することに取り組んでいます。Brightspace と統合された Quick Sight は、その約束を実現する上で重要な役割を果たしています。 この新しいデータ準備エクスペリエンスは、教育エコシステムのすべての人々が分析にアクセスできるようにするための大きな前進を表しています。技術的な障壁を取り除き、データ変換のための直感的なツールを提供することで、Quick Sight はさまざまな規模の教育機関が、教育と学習における有意義な改善のためにデータを活用できるよう支援します。 教育機関が影響力を示し、成果を向上させるプレッシャーが高まる時代において、アクセスしやすいアナリティクスは不可欠です。Quick Sight を使用することで、技術的な専門知識や予算の制約に関係なく、さまざまなお客様に強力なデータインサイトを提供できるソリューションを提供できることを誇りに思います。 この取り組みを続ける中で、私たちは核となるミッションに集中し続けています。それは、イノベーション、エンゲージメント、データに基づいた意思決定を通じて、世界の学習方法を変革することです。AWS のようなパートナーや Quick Sight のようなサービスとともに、私たちは教育機関がこれまで想像もしなかったような成果を達成できるよう支援する能力に自信を持っています。Quick Sight が教育分析をどのように変革できるかについて詳しく知るには、以下のリソースをご覧ください。 Amazon Quick Sight の機能をさらに深く理解する 無料トライアル を始める Quick Suite Community に参加する 著者について Surekha Rao は、D2L のプロダクトマネジメントディレクターであり、過去 14 年間にわたって教育テクノロジーのイノベーションを推進してきました。プロダクトリーダーシップにおいて 4 年以上の経験を持ち、生成 AI、アナリティクス、アセスメント、エンゲージメントツールにわたる変革的なソリューションの戦略と立ち上げを主導してきました。これらの取り組みは、教育機関が学習成果を向上させ、教育者の効率を強化し、よりつながりのある学習体験を創出することに貢献しています。現在は、データとアナリティクスに注力し、教育者や管理者に実用的なインサイトを提供し、大規模なエビデンスに基づく意思決定を可能にする取り組みを推進しています。 Andrew Wooster は、D2L のシニアディレクター オブ エンジニアリングです。Andrew は、データ、分析、AI 製品および機能の全体的な技術戦略と提供に責任を持ち、チームが品質、パフォーマンス、スケーラビリティの高い方法で顧客価値を最前線にもたらすことができるよう取り組んでいます。 Barret Newman は、カナダ アルバータ州カルガリーにある Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトです。15 年以上の IT 経験を持つ Barret は、EdTech のお客様が AWS 上で移行、モダナイゼーション、イノベーションを実現できるよう支援することに注力する技術的なソートリーダーです。仕事をしていないときは、パートナーと 2 匹の猫と過ごしたり、家中のあらゆるデバイスを自動化して統合したり、たくさんのコーヒーを飲んだりすることを楽しんでいます。 Vignessh Baskaran は、Amazon Quick Suite の機能である Amazon Quick Sight において、データ接続とデータ準備ドメインを担当するシニアテクニカルプロダクトマネージャーです。ビジネスインテリジェンスとデータウェアハウジングのバックグラウンドを活かし、Quick Sight の新しいデータ準備エクスペリエンスの製品戦略と開発を主導し、複雑なデータ変換をすべてのユーザーがアクセスできるようにすることに注力しています。仕事以外では、クリケット観戦、ラケットボール、シアトルでのさまざまな料理の探索を楽しんでいます。

本記事は、2025 年 10 月 23 日に公開された Transform and visualize your data preparation flow in Amazon Quick Sight without SQL を翻訳したものです。翻訳は Public Sector PSA の西川継延が担当しました。 Amazon Quick Sight は、 Amazon Quick Suite の機能の 1 つで、AI を活用したビジネスインテリジェンス (BI) 機能を提供し、散在するデータを戦略的なインサイトに変換して、より迅速な意思決定とより良いビジネス成果の達成を支援します。 データ準備は、特にビジネスユーザーが SQL の専門知識を持っていない場合、分析において最も時間のかかる部分であることが多いです。アナリストは通常、インサイトを生成するよりもデータ準備に多くの時間を費やしています。この課題は、データが複数のシステムや期間にわたってサイロ化されていることが多い小売組織において、特に重要です。 この投稿では、中規模の小売企業である AnyCompany (この投稿のための架空の企業) が、新しい Quick Sight データ準備エクスペリエンスを使用して、ビジネスアナリストが SQL を一行も書かずに複雑なデータを変換する方法を探ります。アナリストが、Append、Join、Unpivot、Aggregate などの機能を使用して、シンプルなポイントアンドクリックインターフェイスを通じて複雑なデータの課題を解決する方法、およびデータセットをさらなる変換のソースとして再利用できるようにすることで、チーム間のコラボレーションを可能にする方法を見ていきます。 データ準備における課題 AnyCompany は、USB ハブ、壁掛け時計、収納ボックス、その他の家庭用品やオフィス用品など、さまざまな消費者向け製品を販売しています。同社のアナリティクスチームは、過去の販売データと予測を組み合わせて、地域全体でマーケティング費用を最適化する必要があります。 この企業はいくつかのデータに関する課題に直面しています: 売上データは年度 (2023、2024、2025) ごとに複数のテーブルに分割されています 製品情報と地域情報は別々のディメンションテーブルに存在します データソース間でデータ形式の不整合が存在します (例: 郵便番号の形式) 予測データは列指向構造の Excel ファイルに保存されています 以前は、これらの課題には SQL の専門知識が必要であったり、技術チームからの支援を待つ必要がありました。新しい Quick Sight データ準備エクスペリエンスにより、AnyCompany のビジネスアナリストはこれらの問題を独立して解決できるようになりました。 ソリューション概要 AnyCompany は、Quick Sight を使用して共同データ準備ワークフローを実装しました。 グローバルアナリストが、売上、製品、地域データを組み合わせた基盤データセットを作成します。 地域アナリストが、その基盤に地域固有の分析と予測を追加します。 GUI ベースのビジュアルデータ編集準備機能により、アナリストは複雑な SQL クエリを記述することなく、高度なデータ変換を実行できます。 SPICE (Super-fast, Parallel, In-memory Calculation Engine) が、最適なパフォーマンスを実現するインメモリ計算エンジンを提供します。 グローバルアナリストのジャーニー AnyCompany のグローバルアナリストは、複数年のデータと製品および地域情報を組み合わせた包括的な売上データセットを作成する必要があります。SQL の知識が限られているにもかかわらず、アナリストは新しい Quick Sight データ準備エクスペリエンスを使用してこの基盤を構築することができます。 複数年にわたる売上基盤の構築 グローバルアナリストは、まず 2023 年の売上データを調査します。このデータには、 product_id 、 customer_id 、 order_date 、 ship_date 、 sales 、 quantity 、 discount などの注文詳細が含まれています。次のスクリーンショットは、これらのカラムの一部の例を示しています。 Quick Sight の Append 機能を使用することで、アナリストはわずか数クリックで 2024 年と 2025 年の売上データを結合できます。各ステップ後の Preview タブにより、アナリストはデータが正しく結合されていることをすぐに確認でき、変換プロセスに対する信頼性を高めることができます。 ディメンションデータによるエンリッチメント 統合された売上データが準備できたら、アナリストはそれを製品ディメンションテーブルと結合します。Quick Sight での結合操作は簡単です。アナリストは結合するテーブルと共通キー ( product_id ) を選択するだけで、プレビューには製品情報と売上データが並んだ拡張されたデータセットがすぐに表示されます。 しかし、地域ディメンションテーブルとの結合を試みると、アナリストはデータ品質の課題に直面します。 Preview タブを見ると、売上データと地域テーブルの郵便番号が一致していないことがわかります。売上データの一部の郵便番号は 5 桁以上あり、地域テーブルでは郵便番号が文字列ではなく整数として保存されています。 データ型の不整合の解決 Quick Sight は、これらの不整合を解決するための変換機能を提供しています。1 つの計算列ステップで、アナリストは left({postal_code}, 5) という数式を使用して Clean Zip 列を作成し、郵便番号の長さを標準化します。 Configure タブには、この計算のプレビューがリアルタイムで表示されます。 別の変換では、アナリストは単純なデータ型の変更を使用して、整数の郵便番号を文字列に変換します。複雑な SQL の CAST 関数や文字列操作が必要だったものが、ビジュアルインターフェースでの数回のクリックで実現できます。 郵便番号が両方のテーブルで一貫性を持つようになったため、アナリストは地域ディメンションテーブルとの結合に成功し、次に customer_id をキーとして顧客ディメンションテーブルとの結合を進めます。 データセットの最終化 データセットをより使いやすくするために、アナリストは Rename columns ステップを使用して、列により説明的な名前を付けます。Quick Sight では、1 つのステップで複数の列の名前を変更できるため、プロセスが効率化されます。Select columns ステップは、列の追加、除外、並べ替えを行うための直感的なインターフェイスを提供します。アナリストは列をドラッグして並べ替えたり、ワンクリックで除外したりできます。 変換を完成させた後、アナリストは 2023 & 2024 Union、Product Join、Calc – Clean Zip、Customer Join のようなユーザーフレンドリーなステップ名を作成し、データ準備プロセスを透明で理解しやすいものにします。その後、アナリストはデータセットを Sales Revenue Dataset として保存して公開し、他のアナリストが活用できるようにします。 次のスクリーンショットは、グローバルアナリストの最終的なワークフローを示しています。 地域アナリストのジャーニー AnyCompany の米国中部地域のアナリストは、自分の担当地域の前年比売上予測を作成する必要があります。グローバルアナリストがすでに行ったデータ準備作業を再現する代わりに、Sales Revenue Dataset を基盤として使用できます。 作成済データセットに基づく作業 地域アナリストは、新しいデータセットを作成し、Sales Revenue Dataset をソースとして選択することから始めます。このアプローチには大きな利点があります。地域アナリストは、グローバルアナリストが管理する Sales Revenue Dataset の構築に使用されたロジックを理解したり、再作成したりする必要がありません。ソースデータセットへの更新は、地域アナリストの作業に自動的に反映されます。 地域アナリストは、まず Change data type ステップを使用して適切な日付フォーマットを適用し、分析全体で一貫した日付処理を可能にします。 地域データにフォーカス 次に、アナリストは Filter ステップを使用して US-Central リージョンのみに焦点を当て、担当領域のデータセットを素早く絞り込みます。アナリストはまた、2025 年 9 月の最初の数日間の売上データに推定売上 (実際の売上ではない) が含まれていることに気づき、適切なフィルターを適用します。 Configure タブは、アナリストが複数のフィルターの条件をプレビューするのに役立ちます。 異なる粒度レベルの処理 アナリストは、フィルタリングされた Sales Revenue Dataset と予測データを結合する必要がありますが、粒度が一致していません。Sales Revenue Dataset には顧客情報が含まれていますが、予測データは製品カテゴリと月のレベルになっています。 Aggregate ステップを使用して、アナリストは Product 、 Zip 、 Region 、 Category などのカラムでデータをグループ化し、 Sales の合計を計算します。この変換により、複雑な SQL の GROUP BY ステートメントを必要とせずに、予測データに合わせて粒度を調整できます。 列指向の予測データの変換 地域アナリストは別の課題に直面しています。2025 年 9 月から 12 月までの予測データは、月が行ではなく列として格納された Excel ファイルに保存されています。従来の SQL では、これには複雑な UNPIVOT 操作が必要になります。 Quick Sight の Unpivot 変換を使用すると、アナリストは月の列 (2025 年 9 月、10 月、11 月、12 月) を選択し、出力列名を order_date と sales として指定するだけで、集計された Sales Revenue Dataset の列名と一致させることができます。この変換により、列指向のデータが即座に行指向の形式に変換され、履歴データと組み合わせることができます。 追加する前に、アナリストは Change data type ステップを使用して、 order_date 列を文字列型から日付型に変換し、Sales Revenue Dataset の日付形式との一貫性を保ちます。 履歴データと予測データの結合 両方のデータセットが互換性のある形式になったので、地域アナリストは Append ステップを使用して、2025 年 8 月までの履歴データと 2025 年 9 月から 12 月までの予測データを結合します。 Product や Category などのカラムの順序は 2 つのテーブル間で完全に異なり、カラム数も異なります。Quick Sight は、位置ではなく名前でカラムを自動的に整列させる重い処理を自動的に処理し、 Configure タブに適切な出力メッセージを提供します。これにより、カラムの整列と潜在的な不一致を明示的に処理する必要がある複雑な SQL を記述する場合と比較して、アナリストの時間を大幅に節約できます。 その結果、過去の月 (2025 年 8 月以前) の実績値と将来の月 (2025 年 9 月以降) の予測値を含む、年間全体にわたる完全なデータセットが得られます。 次のスクリーンショットは、地域アナリストの最終的なワークフローを示しています。 前年比分析の作成 データの準備が完了したので、地域アナリストは実績データと予測データの両方を含む前年比較を作成できます。Quick Sight の分析機能を使用して、前年と比較した売上のトレンドを示すビジュアライゼーションを作成し、年末までの予測を含めます。これにより、地域チームは SQL の専門知識を必要とせずに、計画とリソース配分のための貴重なインサイトを得ることができます。 メリットと結果 Quick Sight の新しいデータ準備機能により、AnyCompany は大幅な改善を実現しました。 時間の節約 – 以前は数日かかっていたデータ準備タスクが、1 時間未満で完了できるようになりました 技術的な依存関係の削減 – ビジネスアナリストは SQL の専門知識を必要とせずにセルフサービスで作業できます コラボレーションの向上 – グローバルおよび地域のアナリストが互いの作業を基に構築できます インサイト獲得までの時間短縮 – ビジュアルインターフェースにより、アナリストはデータ品質の問題を迅速に特定して解決できます ステップバイステップのビジュアルインターフェースは、AnyCompany がデータを扱う方法を変革します。以前は複雑な SQL クエリが必要だった作業が、今ではシンプルなクリックで実行できるようになりました。 まとめ 新しい Quick Sight データ準備エクスペリエンスは、データ変換を民主化し、技術的な専門知識がなくても高度な操作を実行できるようにします。AnyCompany の事例が示すように、Append、Join、Unpivot、Aggregate などの機能と、複合データセットを構築する機能を組み合わせることで、アナリストは直感的なビジュアルインターフェースを通じて実際のデータ課題を解決できます。 既存のデータセットを新しい変換のソースとして使用できる機能により、チーム間のコラボレーションが促進され、組織全体での一貫性が容易になります。アナリストのデータ準備の複雑さを排除することで、組織はインサイトを得るまでの時間を短縮できます。 Quick Sight の新しいデータ準備エクスペリエンスを開始するには、 Quick Suite アカウント にサインアップしてください。その後、新しいデータセットを作成し、ステップバイステップの変換機能を探索できます。 著者について Ramon Lopez は、Amazon Quick Sight のプリンシパルソリューションアーキテクトです。BI ソリューションの構築における長年の経験と会計のバックグラウンドを持ち、お客様との協働、ソリューションの創出、世界クラスのサービスの提供に情熱を注いでいます。仕事以外の時間は、海や山でアウトドアを楽しむことを好んでいます。 Vignessh Baskaran は、Amazon Quick Suite の機能である Amazon Quick Sight において、データ接続とデータ準備ドメインを担当するシニアテクニカルプロダクトマネージャーです。ビジネスインテリジェンスとデータウェアハウジングのバックグラウンドを活かし、Quick Sight の新しいデータ準備エクスペリエンスの製品戦略と開発を主導し、複雑なデータ変換をすべてのユーザーがアクセスできるようにすることに注力しています。仕事以外では、クリケット観戦、ラケットボール、シアトルでのさまざまな料理の探索を楽しんでいます。

本記事は 2025 年 10 月 22 日に Migration & Modernization Blog で公開された “ AWS for VMware: Your complete re:Invent 2025 guide ” を翻訳したものです。 AWS の最新の AI を搭載した移行ツールとモダナイゼーションソリューションを使って、VMware 環境を革新する方法を紹介します。今年の re:Invent では AWS Transform や Amazon Elastic VMware Service (Amazon EVS) などの画期的な新機能、業界リーダーによる実践的な変革戦略、そしてデジタルトランスフォーメーションを開始するためのガイダンスが紹介されています。 私たちは、クラウドジャーニーにとって最も重要な VMware に焦点を当てた注目のセッションを厳選しました。各セッションでは、技術的な詳細解説からハンズオン移行ワークショップまで、お客様の成功事例や実証済みのモダナイゼーションフレームワークを取り上げ、最も重要な移行課題の解決に役立つ実用的な洞察を提供します。 基礎的な移行計画から高度なアーキテクチャの詳細解説まで、あなたのデジタルトランスフォーメーションの段階に応じた専用セッションが用意されています。専門家によるワークショップ、インタラクティブなラボ、戦略ディスカッションに参加して、シームレスなクラウド導入のための最新の AWS ツールとベストプラクティスを習得しましょう。 移行とモダナイゼーション戦略 世界中の IT チームが、ROI と事業継続性を確保しながら、レガシーシステムを変革し、アプリケーションにとって最適な道筋を決定しようとしています。これらのセッションでは、実体験、お客様の成功事例、そして VMware ワークロードをクラウドに自信を持って移行するのに役立つ、さまざまな移行パスの概要をまとめています。 AWS for VMware Migrations: Successes, roadmaps, & strategies | MAM203 | Level: 200 Type: Breakout session – Customer Panel Date & Location: Monday, Dec 1 2:30 PM – 3:30 PM PST | Wynn VMware 環境の AWS への移行に成功した IT リーダーたちが、彼らのクラウドジャーニーの経験を共有するセッションにご参加ください。移行計画と実行において実証済みのツール、戦略、そして学んだ教訓から学びましょう。これらのグローバル組織は、モダナイゼーションロードマップとイノベーション戦略に関する洞察を共有し、クラウドトランスフォーメーションを始めたばかりの方も、課題に直面している方も、あなた自身のクラウド変革に向けた貴重なガイダンスを提供します。 Map your VMware workloads migration and modernization journey to AWS | MAM323 | Level: 300 Type: Chalk talk Date & Location: Tuesday, Dec 2 1:00 PM – 2:00 PM PST | Wynn このインタラクティブセッションでは、多様な VMware ワークロードに対する、固有の要件、依存関係、ビジネス目標を考慮したカスタマイズされた移行とモダナイゼーション戦略を探求します。リフト & シフトから完全なクラウドネイティブなトランスフォーメーションまで、生成 AI などのイノベーションを活用して移行を加速し、リスクを軽減するアプローチの選択方法を学びます。投資を最適化し、情報に基づいた意思決定を導くためのベストプラクティス、ライセンスに関する考慮事項、戦略的フレームワークを取り上げ、ビジネス目標と技術的制約に合致した、回復力があり拡張可能なクラウドアーキテクチャの構築をお手伝いします。 Pioneering Agentic AI Transformation: CSL VMware & SAP modernization | MAM346 | Level: 300 Type: Breakout session Date & Location: Wednesday, Dec 3 11:30 AM – 12:30 PM PST | Wynn CSL Behring 社が AWS Transform の Agentic AI を使用して 4000 台以上の VMware サーバーを移行し、SAP システムを統合することで、どのようにインフラストラクチャを変革したかを紹介します。彼らの戦略は、技術的負債とライセンスコストを削減しながら、発見と計画のプロセスを 10 倍高速化することを実現しました。 RISE with SAP on AWS を通じて ERP ランドスケープを統合し、企業全体のデータ標準を確立した方法を学びましょう。このケーススタディでは、あなたの組織のトランスフォーメーションジャーニーに適用できる技術的ガイダンスと実用的な洞察を提供します。 VMware to AWS Readiness: Foundational decisions before your migration | MAM357 | Level: 300 Type: Chalk talk Date & Location: Monday, Dec 1 3:00 PM – 4:00 PM PST | MGM VMware から AWS への移行を成功に導く重要な意思決定を探求するためにご参加ください。ライセンス、運用モデル、技術アーキテクチャ、組織の準備状況における選択が、移行結果にどのような影響を与えるかを検証します。VMware 環境の依存関係とビジネス制約を包括的に評価し、ステークホルダーの合意形成と将来を見据えた計画のための実用的なフレームワークを使用する方法を学びましょう。このセッションでは、一般的な移行の落とし穴を回避し、長期的な成功を確実にするための重要な戦略的ガイダンスを提供します。 製品の詳細解説とハンズオンワークショップ: AWS Transform VMware から AWS への移行ジャーニーを加速するために設計された没入型セッションを通じて AWS Transform を探求しましょう。ワークロードを Amazon EC2 にモダナイズし、VMware ライセンスコストを削減し、Agentic AI を活用してアプリケーション発見、依存関係マッピング、ネットワーク変換、ウェーブ計画、最適化された EC2 インスタンス選択を自動化します。ブレークアウトセッションを通じた戦略的洞察を求めている場合でも、ワークショップを通じたハンズオン体験を求めている場合でも、クラウド移行の複雑さを軽減する方法を発見し、開始方法を学ぶことができます。 Agentic AI for VMware migrations with AWS Transform for VMware | MAM202 | Level: 200 Type: Breakout session Date & Location: Wednesday, Dec 3 10:00 AM – 11:00 AM PST | Wynn Amazon EC2 への大規模な VMware 移行を実現する初の Agentic AI サービスである AWS Transform を紹介します。アプリケーション発見、依存関係マッピング、ネットワーク変換、ウェーブ計画、そして最適化された EC2 インスタンス選択によるサーバー移行を自動化する方法のライブデモをご覧ください。VMware インフラストラクチャをクラウドネイティブアーキテクチャにモダナイズしながら、ライセンスの課題とベンダーロックインを克服し、より迅速で確実な移行を可能にする方法を学びましょう。 Accelerating Cloud Migration with Agentic AI: Hands-on AWS Transform [REPEAT] | PEX307-R | Level: 300 Type: Builders’ session Date & Location: Wednesday, Dec 3 3:00 PM – 4:00 PM PST | Caesars Forum AWS パートナーが AI を搭載した AWS Transform を活用して、クライアントのクラウド移行ジャーニーを最適化する方法を紹介するセッションにご参加ください。このハンズオンセッションでは、高度な AI エージェントを活用して移行アセスメント、計画、そして AWS へのワークロード移動を加速する方法を学びます。パートナーの皆様は、プロンプトエンジニアリング戦略に関する貴重な洞察を得て、実用的なユースケースを探求し、1 時間以内での完全自動移行を目撃することができます。 AWS Transform for VMware と AWS Transform Assessments が、制御と可視性を維持しながら、合理化された移行サービスの提供にどのように役立つかを理解しましょう。AI を活用した移行プラクティスの最大化に関するインタラクティブなディスカッションのために、ご質問をお持ちください。 VMware to AWS modernization blueprint: Migrate, containerize, scale | MAM338 | Level: 300 Type: Workshop Date & Location: Wednesday, Dec 3 1:00 PM – 3:00 PM PST | Wynn このハンズオンワークショップでは、VMware から AWS への移行とワークロードのモダナイゼーションのための技術的なブループリントを提供します。VMware から Amazon EC2 、そしてコンテナへのジャーニーに沿って、より高速でスケーラブルな移行のために Agentic AI を備えた AWS Transform の使用する方法を学びます。ワークショップでは、 Amazon Elastic Kubernetes Service (Amazon EKS) を使用したコンテナ化、マイクロサービスの実装、そしてクラウドネイティブソリューションの開発を実演します。実証済みのVMware 移行経験を持つ AWS エキスパートが、アプリケーションアーキテクチャの再構築、インフラストラクチャの最適化、そしてイノベーションの加速についててガイドします。 Fast-Track your VMware to AWS Migration with AWS Transform | MAM316 | Level: 300 Type: Workshop Date & Location: Tuesday, Dec 2 12:30 PM – 2:30 PM PST | MGM このハンズオンワークショップでは、VMware ワークロードをクラウドネイティブソリューションに変換するための AI を搭載した AWS Transform の機能について学びます。自動化された発見、依存関係マッピング、インフラストラクチャ変換のための Agentic AI の実践的な経験を積み、効率的な移行計画のための AWS モダナイゼーション手法の使用方法を学びます。このセッションでは、レガシー VMware 環境を最適化されたクラウドネイティブアーキテクチャに変革することに焦点を当て、複雑さ、コスト、移行リスクを削減しながら AWS への投資を最大化するお手伝いをします。 Scale VMware migrations with Cloud Migration Factory & AWS Transform | MAM335 | Level: 300 Type: Workshop Date & Location: Thursday, Dec 4 3:30 PM – 5:30 PM PST | MGM このハンズオンワークショップでは、 AWS Transform と Cloud Migration Factory を使用した大規模な VMware 移行の自動化について学びます。発見、テスト、カットオーバープロセスにおいて手動作業を 90% 削減できる実証済みの自動化パターンの実践的な経験を積むことができます。簡素化された変更管理により、コンプライアンスに準拠した大規模移行を可能にする実践的なフレームワークを探求します。ご参加の際はノートパソコンを持参ください。 Accelerate migration of VMware workloads using Agentic AI | MAM408 | Level: 400 Type: Workshop Date & Location: Thursday, Dec 4 12:30 PM – 2:30 PM PST | MGM この技術的な詳細解説では、 AWS Transform を使用してサーバー移行ライフサイクルを最適化する方法を紹介します。AI を搭載したエージェントが、オンプレミス環境のインテリジェントな発見から AI 生成によるウェーブ計画とネットワークアーキテクチャまで、移行ジャーニーをどのように自動化し最適化するかを探求します。ハンズオン演習を通して、生成 AI 機能を活用し、Infrastructure as Code の自動作成とネットワーク変換を行う方法を学びます。実際のサーバー移行を体験し、AWS ジャーニー中のビジネス中断を最小限に抑える、最新の AI を活用した移行技術の実用的な知識を身につけて帰りましょう。 製品の詳細解説: Amazon Elastic VMware Service (Amazon EVS) Amazon Elastic VMware Service (Amazon EVS) セッションに参加して、アプリケーションのリプラットフォームやリファクタリングを行うことなく、 AWS 上で VMware ワークロード を実行する方法を学びましょう。これらのセッションでは、クラウドで VMware 環境を正常にデプロイし、スケールするために必要なすべてをカバーします。 A complete guide to Amazon EVS: Unlock AWS scale for VMware workloads | MAM201 | Level: 200 Type: Breakout session Date & Location: Tuesday, Dec 2 1:30 PM – 2:30 PM PST | MGM Amazon EVS は、リプラットフォームやリファクタリングの手間をかけることなく、VMware ワークロードを AWS にシームレスに移行する方法を提供します。このサービスにより、既存の VMware への投資と専門知識を保護しながら、AWS の堅牢なインフラストラクチャを活用できます。セルフマネージドを選択するか AWS パートナーと協力するかに関わらず、Amazon EVS は統合されたストレージ、バックアップ、災害復旧機能を備えた仮想環境をカスタマイズするための柔軟なオプションを提供します。プラットフォームの直感的なデプロイメントプロセスと継続的なイノベーションにより、クラウドジャーニーを最適化するために必要なツールと柔軟性を確実に得ることができます。 Amazon EVS Deep Dive: Advanced Networking and Storage Architecture | MAM401 | Level: 400 Type: Chalk talk Date & Location: Thursday, Dec 4 12:30 PM – 1:30 PM PST | MGM Amazon EVS は、クラウド仮想化スタックの構築において柔軟性を提供します。この詳細解説セッションでは、Amazon EVS 環境の高度なパターンに焦点を当て、ネットワークアーキテクチャ、VPC 間通信、そして高度なネットワーキング戦略をカバーします。また、環境をスケールする際のパフォーマンスとコストの最適化に役立つ高度なストレージアーキテクチャパターンについても探求します。 Amazon EVS Deep Dive: Strategic migration planning | MAM305 | Level: 300 Type: Chalk talk Date & Location: Wednesday, Dec 3 1:00 PM – 2:00 PM PST | MGM AWS の VMware ワークロードを Amazon EVS で実行するインタラクティブな技術セッションにご参加ください。最適な移行成功に向けた Amazon EVS 環境の設計と計画方法の紹介、技術的な前提条件、キャパシティ計画、ホスト配置オプションもカバーします。Amazon EVS とストレージ、バックアップ、災害復旧ソリューションを統合するためのベストプラクティスを学び、さらに他の AWS サービスとの接続によってクラウドデプロイメントを最大化する方法を紹介します。 Optimizing Storage costs for Amazon EVS with FSx for ONTAP (sponsored by NetApp) | MAM101 | Level: 100 Type: Breakout session Date & Location: Wednesday, Dec 3 1:00 PM – 2:00 PM PST | MGM Amazon EVS は、リプラットフォームを行うことなく VMware ワークロードを AWS にシームレスに移行することを可能にします。 Amazon FSx for NetApp ONTAP と組み合わせることで、高い TCO や複雑なデータ操作といった一般的な移行課題に対処します。この統合により、シームレスなデータ移行、自律型ランサムウェア保護、そしてオンプレミスソリューションで一般的に見られるエンタープライズ機能を備えた最適化されたストレージ利用を含む、エンタープライズグレードのデータ管理機能を提供します。AWS パートナーである NetApp 社による発表です。 Migrate from VMware to AWS: Cloud Operations Best Practices | COP325 | Level: 300 Type: Chalk talk Date & Location: Tuesday, Dec 2 4:30 PM – 5:30 PM PST | Mandalay Bay Amazon EVS を AWS のクラウド運用サービスを通じて最適化することに焦点を当てたインタラクティブセッションにご参加ください。 AWS Organizations 、 AWS CloudTrail 、 AWS Config 、 Amazon CloudWatch 、そして AWS Systems Manager がどのようにタスクを自動化し、可視性を向上させ、ガバナンスを強化し、移行を加速するかを探求します。移行プロセスを強化し、AWS でワークロードをより効率的かつ安全に実行するための実用的な戦略を習得できます。このセッションは、新しい移行と既存の Amazon EVS デプロイメントの最適化の両方にとって価値があります。 AWS re:Invent 2025 に向けた準備を始めましょう AWS re:Invent 2025 がもうすぐ開催されます。VMware ワークロードの AWS へのモダナイズと移行に成功した AWS エキスパートとお客様からの貴重な洞察が満載です。準備のためのチェックリストはこちら： AWS re:Invent 2025 に登録 re:Invent Portal でこれらのセッションを予約 #reInvent を使ってソーシャルメディアで会話に参加 AWS Events mobile app をダウンロード してスケジュールを作成 より深く学ぶ: AWS for VMware リソース 先取りするために、これらのリソースを探求しましょう： AWS for VMware AWS Transform for VMware Amazon Elastic VMware Service (Amazon EVS) AWS for VMware Partners 最新情報を入手 見逃さないでください！ @AWSreInvent をフォローし、お気に入りのソーシャルプラットフォームで #reInvent ハッシュタグをチェックしましょう。他の参加者とつながり、イベント前の興奮を味わうのに最適な方法です。 プロのヒント: セッションスケジュールは変更される場合があります。最新情報については、常に公式の AWS re:Invent Session Catalog を参照してください。 翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文は こちら です。 Suhail Fouzan Suhail Fouzan は Amazon Web Services (AWS) のスペシャリストソリューションアーキテクトで、IT 業界で 15 年以上の経験を持っています。Microsoft ワークロード、移行サービス、そして AWS Systems Manager による運用管理を専門とし、お客様のインフラストラクチャの AWS への移行を成功へ導くサポートをしています。仕事以外では、Suhail はクリケットをプレイしたり、家族と時間を過ごしたりすることを楽しんでいます。 Bianca Velasco Bianca Velasco は AWS のプロダクトマーケティングマネージャーで、VMware ベースのワークロードの AWS への移行と変革に重点を置いています。マーケティングとテクノロジーの分野で 7 年以上の経験を持ち、複雑なテクノロジーをわかりやすく、そして共感しやすいものにするためのストーリー作りに情熱を注いでいます。AWS 以外では、Bianca はボランティア活動、ダンス、ボルダリングを楽しんでいます。 Yogi Barot Yogi Barot は AWS の ワールドワイドな Microsoft Tech リーダーで、AWS における Microsoft 技術フィールドコミュニティを率いています。彼女の役割の一部として、技術的な支援のためのコミュニティを主導し、お客様の Microsoft ワークロードの AWS への移行とモダナイゼーションをサポートしています。Yogi は 26 年にわたり、様々な Microsoft テクノロジーに携わってきた経験を持ち、特に SQL Server と様々なデータベーステクノロジーを専門としています。Yogi は AWS に関する深い知識と、AWS 上で Microsoft ワークロードを実行する専門知識を有しています。

みなさん、こんにちは。ソリューションアーキテクトの水野です。AWS ではサービスのアップデートだけでなく製造業の方に向けたイベントの開催や事例の発表などを頻繁に行っています。それらの情報を効率良くインプットしていただく為に、今月から日本の製造業のお客様に向けた情報発信を行っていきます。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 ピックアップトピック AWS re:Invent 2025 が 12 月 1 日から 5 日までラスベガスで開催されます。毎年恒例の AWS re:Invent 速報も会期中の 2025 年 12 月 5 日 (金)に開催が決定しています。ご登録は こちら 。新しいサービスの発表も楽しみなのですが、沢山のセッションも行われます。そんな中、日本のメンバーも現地で Chalk Talk 「 Accelerating Smart Products SDLC with Amazon Q Developer (IND303) 」 に登壇します。Amazon Q Developer によるスマートプロダクト開発ライフサイクルの革新をテーマに、ハードウェア・組込みソフトウェア・アプリケーションを AI 支援のチケット駆動型ワークフローで統合する方法をご紹介します。ただ残念ながらオンライン配信もなく、現地も既にキャンセル待ちとなっています。ご興味あるお客様には個別にご紹介いたしますので担当営業までお声がけください。 直近で開催予定のイベント 11/19 – 21 EdgeTech+ 2025 一般社団法人 組込みシステム技術協会の主催でパシフィコ横浜で行われる EdgeTech+ 2025 に AWS も登壇します。基調講演では「 SDV Acceleratorが導く、車載ソフト開発の新たなステージ 」(19日)、 「 エッジとクラウドが織りなす製造業の未来 – AI エージェントがもたらすデジタル変革 」(21日)の２つで登壇します。テーマ別セミナーでは、「 コード生成を超えた AI エージェント活用で組み込み開発プロセスを効率化する実践手法 」(19日)、「 プロダクトの進化を導くためのエッジ AI の技術動向と AI 開発運用ソリューション 」(20日)の２つで登壇します。 IIFES 2025 製造業と社会インフラを支える制御・駆動・計測を軸に、デジタル化技術の展示会である IIFES が、東京ビッグサイトで行われます。AWS は三菱電機様のブースでパートナーとしてデモ展示を行います。ブース内でのセッションにも登壇予定です。ぜひ三菱電機様のブースへお立ち寄りください。 12/1 – 5 AWS re:Invent 2025 ピックアップトピックでも記載しましたが、今年もこの季節がやってきました！AWS における世界最大のイベントが AWS re:Invent です。毎年多くのサービス発表や機能拡張が発表されますが、私たちはこの期間は毎年寝不足になりながら、リアルタイムで視聴をするのが恒例行事となっています。製造業に関わるサービスやセッションについては、今後こちらのブログで発信しますのでご期待下さい。 製造関連ブログのご紹介 10/1 Hexagon Automates Manufacturing Standard Operating Procedures with AWS Generative AI このブログでは、Hexagon 社が AWS の生成 AI サービスを活用して、製造業・エネルギー業界の標準作業手順書（SOP）のデジタル化を自動化した事例を紹介しています。Amazon Bedrock を中心に、複数のAWSサービスを組み合わせたサーバーレスワークフローにより、従来の手作業プロセスを 90% 以上の精度で自動化。ドキュメント処理の時間を数日から数分に短縮し、コスト削減と業務効率化を実現した革新的なソリューションの構築方法が詳しく解説されています。 10/9 【自動車業界】SDV時代の車載ソフトウエア開発を支えるAWSソリューション（Vector SDV Symposium Japan 2025で発表） 2025 年 9 月 18 日に開催された「Vector SDV Symposium Japan 2025」にて、「SDV 時代の車載ソフトウエア開発を支える AWS ソリューション」というテーマで登壇した内容をより掘り下げてご紹介しています。このブログでは、 仮想開発環境や仮想 ECU 技術を使ったテストの効率化まで、AWS が提供するソリューションについて紹介しています。 10/10 Transform Supply Chain Logistics with Agentic AI このブログでは、AWS のプロフェッショナルサービスチームがシンガポールの A*STAR と協力して開発したロジスティクスエージェントを紹介しています。Amazon Bedrock を活用した AI エージェントは、ERP、TMS、WMS など複数のシステムからリアルタイムデータを集約し、自然言語での問い合わせに即座に対応。手作業による情報検索を最大 50 %削減し、配送コスト 3～5 %削減、顧客満足度向上を実現します。サプライチェーン全体での Agentic AI の活用可能性を示す実践的な事例を紹介しています。 10/14 AWS IoT Greengrass nucleus lite 窶・リソース制約のあるデバイスでエッジコンピューティングに革命を起こす AWS IoT Greengrass nucleus lite は、リソース制約のあるデバイスを対象とした軽量な オープンソース のエッジランタイムです。スマートホームハブ、スマートエネルギーメーター、スマートビークル、エッジ AI、ロボティクスなどの大量生産アプリケーション向けに、低コストのシングルボードコンピュータで AWS IoT Greengrass の機能を拡張できます。このブログでは、2つのエッジランタイムオプションの利点を説明し、ユースケースに最適なオプションを選択するための指針を提供しています。 10/16 株式会社マキタ様の AWS 生成 AI 事例「AWS 上の閉鎖型 AI 環境で労働災害報告書作成支援と経営ダッシュボードを内製開発。システム開発経験の少ないエンジニアが短期間でリリースを実現」のご紹介 このブログでは、 船舶用ディーゼルエンジンの製造・販売・アフターサービスを手がける株式会社マキタ様が AWS を用いて経営ダッシュボードと労働災害報告書作成支援 AI を「短期間」かつ「システム開発経験の少ないエンジニア主導の開発体制」で内製した事例についてご紹介しています。 10/24 Secure, remote monitoring and control of a PLC from AWS このブログでは、Inductive Automation の Ignition を使用して、遠隔地の PLC（プログラマブルロジックコントローラ）を AWS クラウドから安全に監視・制御するシステムの構築方法を詳細に解説しています。Teltonika RUT956 ルーターと AWS Site-to-Site VPN を活用した暗号化通信、AWS Private CA による証明書管理、BGP による自動フェイルオーバーなど、エンタープライズグレードの信頼性を備えた実装手順が段階的に説明されており、再生可能エネルギーやマイニング、石油ガス産業などの大規模産業ユーザーに適した設計について紹介しています。 10/29 How Sibros, Panasonic Automotive, and AWS Collaborate to Reduce Connected Services Integration Challenges During Vehicle Development このブログでは、Sibros、Panasonic Automotive、AWS が協力して、自動車の接続サービス統合の課題を解決する方法を紹介しています。仮想開発環境 vSkipGen ｢と Sibros の Deep Connected Platform を活用することで、自動車メーカーは物理ハードウェアを待たずに早期から統合テストを実施でき、開発期間の短縮とソフトウェア品質の向上を実現できます。OTA 更新やデータ収集などの機能も含まれており、グローバルな分散チームでの開発を加速させる方法について紹介しています。 イベント動画のご紹介 10/23 AWS at IAA MOBILITY 2025 – Highlights この動画は、2025 年 9 月 8 日から 12 日にかけてミュンヘンで開催された IAA MOBILITY 2025 における AWS の参加ハイライトを紹介しています。自動車産業における AWS の革新的なAIソリューションが展示され、特にエージェント型 AI アシスタントや自動車設計における AI 活用など、自動車業界の未来を形作る技術が紹介されました。 10/30 AWS Summit Paris 2025 – Comment accelerer sa transformation numerique industrielle このセッションは、AWS Summit Paris 2025 での「産業デジタルトランスフォーメーションの加速方法」に関する講演です。ゲストスピーカーとして Aremmon 社の Industry 4.0 責任者である Ali Ponlou 氏が、製造業におけるデジタルトランスフォーメーションの実践方法と事例について解説しています。特に POC 段階を超えて本格的な展開を計画している企業にとって、Aremmon 社の実例や段階的アプローチの解説は実践的な指針となります。また、産業データプラットフォームの構築方法や生成 AI の活用事例は、製造業の IT 部門と OT 部門の橋渡しを担当する技術者にとって参考になる具体的な実装方法を提供しています。 製造関連の主要なアップデート 10/14 AWS IoT SiteWise Edge データ処理パックと AWS IoT SiteWise Monitor がメンテナンスモードに 2025 年 11 月 7 日以降、新規のお客様は AWS IoT SiteWise Edge データ処理パックと AWS IoT SiteWise Monitor がご利用頂けなくなります。既存のお客様については、代替ソリューションを検討頂きながら、引き続きこれらのサービスや機能をご利用頂けます。また、Amazon Lookout for Equipment と AWS IoT Greengrass v1 については、サービスの運用とサポートを終了する日程が発表されています。これらのサービスをご利用中のお客様は、ドキュメントで推奨されている代替手段への移行を計画してください。 10/23 AWSのカスタマーカーボンフットプリントツール (CCFT) が、SCOPE 3 に対応 カスタマーカーボンフットプリントツール (CCFT)は、AWS が提供するツールで顧客が AWS の利用による炭素排出量を可視化・追跡できます。 今回 CCFT が更新され、SCOPE 3 排出量データに対応しました。これにより、サーバー製造、施設電力、機器輸送など、クラウド利用の全ライフサイクルにおける炭素影響を可視化できます。2022 年 1 月からの履歴データも利用可能で、組織のサステナビリティ目標達成に向けた戦略的な意思決定が容易になります。 10/31 AWS IoT Greengrass 開発者向け MCP サーバ AWS IoT Greengrass 向けの新しい MCP サーバが発表されました。このオープンソースツールは GitHub で公開されており、開発者が Amazon Q Developer などの AI コーディングエージェントを活用して、エッジデバイスアプリケーション開発を加速できます。テンプレートと例が含まれており、開発時間を短縮しながら、フリート全体への展開管理も簡素化できるのが大きなメリットです。9 月には AWS IoT SiteWise の MCP サーバも 発表 されています。 最後まで読んでいただきありがとうございました。いかがだったでしょうか？このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。月刊 AWS 製造ブログを今後ともよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。 <!-- '"` -->

データ分析者やエンジニアは、データベーススキーマを探索したり、テーブル構造を理解したり、さまざまな Amazon Redshift データウェアハウス間でクエリを実行するために、複数のツールを行き来することがよくあります。メタデータやデータを自然言語で探索できれば、このプロセスが簡素化されますが、AI エージェントは、最適な実行パスを探索して構築するために、Redshift クラスターの構成とスキーマの追加コンテキストを必要とすることがよくあります。 ここで Model Context Protocol (MCP) が AI エージェントと Redshift クラスターの橋渡しをし、データへの自然言語インターフェースをより適切にサポートするために必要な情報を提供できます。MCP は、AI アプリケーションが外部のデータソースやツールに安全に接続し、ユーザーの特定の環境に関する豊富なリアルタイムのコンテキストを提供できるようにする、オープンな標準規格です。静的なツールとは異なり、MCP を使えば AI エージェントが動的にデータベース構造を探索し、テーブル関係を理解し、Amazon Redshift 設定を完全に認識したうえでクエリを実行できます。 これらの課題に対処し、会話型データ分析の可能性を最大限に引き出すために、 Amazon Web Services (AWS) は、Amazon Redshift データウェアハウスとのインタラクションの仕方を革新するオープンソースソリューションの Amazon Redshift MCP サーバー をリリースしました。Amazon Redshift MCP サーバーは、 Amazon Q Developer コマンドラインインターフェース (CLI)、 Claude Desktop 、 Kiro 、およびその他の MCP 互換ツールとシームレスに統合されています。これにより、データベース環境を本当に理解する AI アシスタントとの自然言語会話を通じて、Amazon Redshift のメタデータとデータを発見、探索、分析できるようになります。 この記事では、Amazon Redshift MCP サーバーのセットアップ方法を説明し、データ分析者が自然言語クエリを使用して Redshift データ ウェアハウスを効率的に探索し、データ分析を行う方法を示します。 Amazon Redshift MCP サーバーとは Amazon Redshift MCP サーバーは、AI エージェントに Amazon Redshift リソースへの安全で構造化されたアクセスを提供する MCP 実装です。以下の機能を実現します: クラスター検出 – プロビジョニングされた Redshift クラスターとサーバーレスワークグループの両方を自動的に検出します メタデータ探索 – 自然言語でデータベース、スキーマ、テーブル、カラムを参照できます 安全なクエリ実行 – 組み込みの安全保護機能を備えた READ ONLY モードで SQL クエリを実行できます マルチクラスターサポート – データ照合タスクのために、複数のクラスターとワークグループを同時に操作できます MCP サーバーは、Amazon Q CLI とあなたの Amazon Redshift インフラストラクチャの間の橋渡しの役割を果たし、自然言語のリクエストを適切な API 呼び出しと SQL クエリに変換します。次の図は、高レベルのアーキテクチャを示しています。 前提条件 始める前に、次のものがあることを確認してください。 システム要件 Python 3.10 以降のバージョン uv パッケージマネージャ ( インストールガイド ) Amazon Q CLI または Claude Desktop のような MCP サポートクライアントツールがインストールされ、設定済みであること AWS の要件 AWS Command Line Interface (AWS CLI)、環境変数、または AWS Identity and Access Management (IAM) ロールを使用して設定された AWS 認証情報 Amazon Redshift へのアクセスに適切な IAM 権限 少なくとも 1 つの Redshift クラスターまたはサーバーレスワークグループ 必要な IAM 権限 ユーザー ID には、アクセスポリシーで以下の IAM 権限が必要です。 { &nbsp;&nbsp;"Version": "2012-10-17", &nbsp;&nbsp;"Statement": [ &nbsp;&nbsp; &nbsp;{ &nbsp;&nbsp; &nbsp; &nbsp;"Effect": "Allow", &nbsp;&nbsp; &nbsp; &nbsp;"Action": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift:DescribeClusters", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-serverless:ListWorkgroups", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-serverless:GetWorkgroup", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:ExecuteStatement", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:BatchExecuteStatement", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:DescribeStatement", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:GetStatementResult" &nbsp;&nbsp; &nbsp; &nbsp; ], &nbsp;&nbsp; &nbsp; &nbsp;"Resource": "*" &nbsp;&nbsp; &nbsp;} &nbsp;&nbsp; ] } インストールと設定 次のセクションでは、Amazon Redshift MCP サーバーをインストールして設定するための手順について説明します。 必要な依存関係のインストール 次の手順に従って、必要な依存関係をインストールしてください: uv パッケージマネージャーをまだインストールしていない場合はインストールしてください: # macOS/Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -c "irm https://astral.sh/uv/install.ps1 | iex" Python 3.10 以降をインストールしてください: uv python install 3.10 MCP サーバーの設定 MCP サーバーは、いくつかの MCP サポートクライアントを使用して設定できます。この記事では、Amazon Q Developer CLI と Claude Desktop を使用する手順について説明します。ホストマシンで Amazon Q Developer CLI を設定し、Amazon Redshift MCP サーバーにアクセスするには、以下の手順を実行してください。 Amazon Q Developer CLI をインストールしてください。 Amazon Q CLI 設定で Amazon Redshift MCP サーバーを設定します。 ~/.aws/amazonq/mcp.json にある MCP 設定ファイルを編集してください。 { &nbsp;&nbsp;"mcpServers": { &nbsp;&nbsp; &nbsp;"awslabs.redshift-mcp-server": { &nbsp;&nbsp; &nbsp; &nbsp;"command": "uvx", &nbsp;&nbsp; &nbsp; &nbsp;"args": ["awslabs.redshift-mcp-server@latest"], &nbsp;&nbsp; &nbsp; &nbsp;"env": { &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"AWS_PROFILE": "default", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"AWS_REGION": "us-east-1", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"FASTMCP_LOG_LEVEL": "INFO" &nbsp;&nbsp; &nbsp; &nbsp;}, &nbsp;&nbsp; &nbsp; &nbsp;"disabled": false, &nbsp;&nbsp; &nbsp; &nbsp;"autoApprove": [] &nbsp;&nbsp; &nbsp;} &nbsp;&nbsp;} } インストールの詳細については、Amazon Redshift MCP サーバーの README.md の インストールセクション を参照してください。 Amazon Q CLI を起動して、MCP サーバーが適切に設定されていることを確認します: q chat /tools Amazon Redshift MCP サーバーが正常に初期化されたことを、起動ログで確認してください。ホストマシン上で Amazon Q Developer CLI をセットアップし、Claude Desktop から Amazon Redshift MCP サーバーにアクセスするには、以下の手順を実行してください。 オペレーティングシステム用の Claude Desktop をダウンロードしてインストールします Claude Desktop を開き、左下のギアアイコンを選択して 設定 に移動します Developer タブを選択し、Amazon Q CLI 設定の手順 2 と同じ設定を追加して MCP サーバーを設定します MCP サーバー接続を有効にするために Claude Desktop を再起動します 新しい会話を開始し、 Show me all available Redshift clusters (利用可能な Redshift クラスターをすべて表示してください) と尋ねて統合をテストします (訳註: Amazon Q Developer CLI では日本語を使用して指示や質問を行うことも可能です。) 顧客購買分析のユースケース データアナリストが複数の Redshift クラスターにまたがる顧客の購買データを探索する必要がある実用的なシナリオを想像してみましょう。以下のウォークスルーでは、MCP サーバーがこのワークフローを簡素化する方法を示します。e コマース企業のデータアナリストとして、次の作業が必要です。 利用可能な Redshift クラスターを検出する データベース構造を調べて、顧客データと売上データを見つける 顧客の購買パターンを分析する ビジネスチームに向けて分析結果を生成する これらのタスクを実行するには、次の手順に従います。 Amazon Q に、利用可能な Amazon Redshift リソースを表示するよう依頼します: Show me all available Redshift clusters (利用可能な Redshift クラスターをすべて表示してください) Amazon Q は MCP サーバーを使用してクラスターを検出し、クラスター識別子やタイプ (プロビジョニングされたものかサーバーレスか)、現在のステータスと可用性、接続エンドポイントと設定、ノードタイプとキャパシティ情報などの詳細を提供します。 データの構造を探索して、データの構成を把握します: What databases and tables are available in the analytics-cluster? (どのデータベースとテーブルが analytics-cluster で利用可能ですか?) Amazon Q は、MCP サーバーを使用してクラスター内のオブジェクトを体系的に探索します: データを分析する前に、テーブルスキーマを把握します: Show me the structure of the customers and orders tables in analytics-cluster (analytics-cluster にある customers テーブルと orders テーブルの構造を表示してください) Amazon Q は MCP サーバーを使用して、テーブルの列を検査し、詳細なスキーマ情報を提供します。 自然言語クエリを使用して顧客の購買パターンを分析します: Analyze customer purchase pattern from analytics cluster. Show me the top 10 customers by total purchase amount and their buying frequency (analytics-cluster から顧客の購買パターンを分析してください。購入総額が最も多い上位10人の顧客と、その購買頻度を表示してください) Amazon Q は MCP サーバーを使用して適切な SQL クエリを実行し、インサイトを提供します。 MCP サーバーは、複数のクラスターにまたがってデータを分析できます: Compare customer acquisition costs between the analytics-cluster and marketing-cluster data. (analytics-cluster と marketing-cluster のデータ間で、顧客獲得コストを比較してください。) Amazon Q は MCP サーバーを使用して、適切な SQL クエリを実行し、analytics-cluster と marketing-cluster 間でデータを比較します。 ベストプラクティス MCP サーバーには、データとシステムパフォーマンスを保護するための重要な安全対策がいくつか備わっています。READ ONLY モードは、意図しないデータ変更を防ぐための重要な保護機能であり、ユースケースに応じてこの機能を有効にすることをお勧めします。さらにセキュリティを高めるため、サーバーには潜在的に有害な影響を与える操作を検証するクエリ検証メカニズムが実装されており、最適な安全性を確保するために user-in-loop 検証が推奨されています。リソース管理については、サーバーはパフォーマンスに影響を与える無制限のクエリを防ぐためにリソース制限を適用しており、ここでもユーザーインザループ検証を行うことで最良の結果が得られます。アクセシビリティの観点では、MCP 機能は Amazon Redshift Data API がサポートされているすべての AWS リージョンで幅広く利用可能であり、Amazon Redshift Data API サービスの既存のスロットリング制限に合わせてスロットリング制限が設定されているため、一貫したパフォーマンスと信頼性が確保されています。最良の結果を得るには、以下の推奨事項に従ってください。 ディスカバリから始める – クラスターやデータベースの構造、テーブルを探索することから始めます 自然言語を使う – 直接 SQL を書くのではなく、分析したいことを説明します 徐々に反復する – 複雑な分析を一歩ずつ構築します 結果を検証する – 重要な発見はビジネス担当者と相互確認します インサイトを文書化する – 重要なクエリと結果を将来の参照用に保存します 結論 Amazon Redshift MCP サーバーは、Kiro や Amazon Q CLI のようなエージェントツールを通じて自然言語によるデータ探索と分析を可能にすることで、データ分析者が Redshift クラスターとやり取りする方法を変革します。SQL クエリを手動で記述したり、複雑なデータベース構造を把握する必要がなくなるため、分析者はシンタックスやスキーマの探索に悩まされることなく、インサイトの生成に集中できます。一時的な分析を行うか、定期的なレポートを生成するか、新しいデータセットを探索するかにかかわらず、Amazon Redshift MCP サーバーは、データ分析ワークフローに強力で直感的なインターフェースを提供します。準備はできましたか? 以下の手順を行っていきましょう。 この投稿の設定手順に従って MCP サーバーをインストールしてください 自然言語クエリを使用して Amazon Redshift 環境を探索してください シンプルな分析から始め、徐々に複雑さを高めてください 自然言語の要約を使ってチームとインサイトを共有してください フィードバックを提供して、MCP サーバーの機能改善に役立ててください 各ユースケースで自然言語を使用するためのナビゲーションをするブログ記事をご覧ください: Implementing conversational AI for S3 Tables using Model Context Protocol (MCP) Accelerating development with the AWS Data Processing MCP Server and Agent Introducing MCP Server for Apache Spark History Server for AI-powered debugging and optimization AWS Announces Billing and Cost Management MCP Server Introducing enhanced AI assistance in Amazon SageMaker Unified Studio: Agentic chat, Amazon Q Developer CLI, and MCP integration 著者について Ramkumar Nottath Ramkumar は AWS のプリンシパルソリューションアーキテクトとして、データおよび AI サービスに重点を置いて活動しています。様々な顧客と協力して、スケーラブルで信頼性の高いビッグデータおよび分析ソリューションの構築を支援することを楽しみにしています。分析、機械学習、生成 AI 、データウェアハウス、ストリーミング、データガバナンスなどの様々な技術に関心を持っています。家族や友人と時間を過ごすことを大切にしています。 Rohit Vashishtha Rohit はテキサス州ダラスを拠点とする AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。ビッグデータプラットフォームの設計、構築、リード、保守において20年の経験を持っています。AWS の幅広いサービスを活用して顧客の分析ワークロードを最新化し、最高のセキュリティとデータガバナンスを備えた最適なコストパフォーマンスを顧客が得られるよう支援しています。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

AWS では、 Amazon Relational Database Service (Amazon RDS) のデータベースパフォーマンスメトリクスを収集・分析するためのいくつかのサービスを提供しています。これには Amazon CloudWatch と CloudWatch Database Insights が含まれます。さらに、さまざまなツールを使用して Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL-Compatible Edition を監視するためのカスタムダッシュボードを作成できます (詳細については、 Create an Amazon CloudWatch dashboard to monitor Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL と Monitor Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL performance using PGSnapper をご覧ください)。 人工知能と機械学習 (AI/ML) の進歩により、データベース監視領域で ML 機能を使用する無数のソリューションが利用可能になっています。これらのツールは、パフォーマンスの監視のボトルネックから運用上の問題まで、幅広い機能を提供します。また、問題をプロアクティブかつリアクティブに解決するための規範的な推奨事項も提供します。 このブログでは、セルフマネージドの Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのマネージドデータベースサービスを使用して、PostgreSQL 向けの人工知能と機械学習 (AI/ML) を活用したデータベース監視ツールについて探求します。 監視に関する考慮事項 このセクションでは、すべてのデータベースにとって重要なメトリクスについて説明します。これらのメトリクスは、ワークロード、データベースパラメータ、およびパフォーマンスに影響するその他の要因の変化を比較およびベンチマークするための履歴情報を保持するために、定期的に監視する必要があります。次の表は、AWS マネージドデータベースで監視することを推奨するメトリクスを示しています。 監視のソース パラメータ/メトリクス Amazon CloudWatch Database Connections CPU Utilization Freeable Memory FreeStorageSpace ReadLatency, WriteLatency DiskQueueDepth ReadIOPS, WriteIOPS WriteThroughput, ReadThroughput ReplicaLag OldestReplicationSlotLag ReplicationSlotDiskUsage MaximumUsedTransactionIDs Amazon CloudWatch Database Insights DatabaseLoad IO Latency EBS IO LongestIdleInTransaction CPU Utilization (%) Sessions Tuples Transactions, Transaction in progress IO cache vs Disk read Deadlocks OS Processes pg_stat_progress_vacuum Vacuum progress pg_stat_activity state of the query/idle_in_transaction 完全なリストについては、 拡張モニタリングの OS メトリクス 、 RDS PostgreSQL の SQL 統計 、 Amazon RDS for PostgreSQL の CloudWatch Database Insights カウンター 、 Vacuum Progress Reporting 、 pg_stat_activity を参照してください。 ここでは、AI/ML ベースのデータベース監視およびトラブルシューティングツールである PI Reporter について、その機能とユースケースを含めて説明します。 PI Reporter は、AWS ソリューションアーキテクトが開発したオープンソースツールで、パフォーマンスメトリクスとワークロードスナップショットを取得し、 Amazon Aurora PostgreSQL-Compatible Edition の詳細な比較レポートを生成し、 Amazon Bedrock の支援によるオプションのレポート分析を提供します。 PI Reporter PI Reporter は Amazon Bedrock と統合し、 Anthropic の Claude や Amazon Nova モデルなどの大規模言語モデル (LLM) の機能を活用して、個別のスナップショットと比較データを分析します。必要なモデルにアクセスできることを確認してください。この分析により、スナップショットウィンドウで発見されたデータベースパフォーマンスの問題に対する包括的な要約、根本原因分析、実行可能な推奨事項が生成されます。 PI Reporter では、以下のことが実行可能です : インスタンス関連情報の包括的な HTML レポートを数分で取得 定期的なレポートを比較して、パフォーマンス、ワークロード、または設定の変更を検出 インスタンスがワークロードを処理できるかを評価し、適切なサイジングのニーズを特定 システムセキュリティを損なうことなく、サードパーティとインスタンス統計を共有 根本原因の特定と推奨事項を含む LLM 分析を受信 このツールは、さまざまなシナリオで活用できます。一般的な例をいくつか紹介します。データベースのパフォーマンスが突然低下した場合、PI Reporter は影響を受けた期間と、通常のデータベースアクティビティを示す比較可能な期間の両方のスナップショットを取得できます。HTML 比較レポートは、何が変わったのか、そして考えられる根本原因を即座に表示します。 もう 1 つの有用なユースケースは、計画通りにデータベースを変更した後のワークロードの変化を評価することです。これには、新しい主要なアプリケーションをリリースする場合、データベースのメジャーバージョンにアップグレードする場合、ブルーグリーンデプロイメントを使用して新しいクラスターに移行する場合、またはその他の重要な変更を行う場合などの状況が含まれます。これらのシナリオでは、変更前後にスナップショットを取得して比較レポートを生成できます。 Amazon Aurora PostgreSQL Serverless インスタンスの監視において、PI Reporter は、予想される ACU 使用パターンと予想外の ACU 使用パターンの期間を比較することで、予想外の高い Aurora Capacity Units (ACU) 使用量の原因を特定するのに役立ちます。 これらの例は、このツールを活用できる方法のほんの一部を示しています。パフォーマンスの比較と分析が必要なあらゆるシナリオに可能性が広がります。 このツールは軽量で使いやすいように設計されています。 Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスで Node.js スクリプトとしてデプロイできます。Linux x86 システム用にコンパイルされたポータブル版のスクリプトも含まれています。PI Reporter のセットアップの詳細については、 GitHub リポジトリ を参照してください。 ソリューション概要 次の図は、AWS サービスを使用した PI Reporter アーキテクチャを示しています。 このソリューションの動作方法を説明します。4 つのレイヤーで構成されています : データ収集レイヤー: Amazon CloudWatch Database Insights は、インスタンスレベルのカウンターパフォーマンスメトリクスと SQL レベルのメトリクスを提供します Amazon CloudWatch は、インフラストラクチャとリソースのメトリクスを提供します Amazon RDS は、メタデータとデータベースログファイル情報を提供します 処理レイヤー: PI Reporter ツールは、すべてのデータソースからデータを集約します 適切な権限を持つインスタンスロールが必要で、pireporterPolicy.json IAM ポリシーを通じて設定されます このツールは収集されたデータを処理し、統合されたメトリクスを含む JSON スナップショットファイルを生成します 分析レイヤー: 高度な分析のために、このソリューションは Amazon Bedrock と統合されます システムは、パフォーマンスメトリクス、リソース使用率データ、ワークロード情報 (SQL 統計を含む) を関連する知識と組み合わせて Amazon Bedrock に送信します Amazon Bedrock の LLM 機能は以下を提供します: 包括的な要約 詳細な分析 実行可能な推奨事項 出力: 最終的な出力は、生のメトリクスと LLM による洞察の両方を含む HTML レポートとして生成されます このアーキテクチャは、適切な IAM ロールと権限を通じてセキュリティを維持しながら、包括的なパフォーマンス監視と分析を確保します 前提条件 PI Reporter は Amazon CloudWatch Database Insights からの情報を使用するため、まず Amazon CloudWatch Database Insights を有効にする必要があります。 以下は、チューニングとトラブルシューティングツールに共通する PostgreSQL 固有の要件です : pg_stat_statements 拡張機能を有効にして、クエリごとの統計情報を収集します。この拡張機能は、Aurora PostgreSQL ではデフォルトで有効になっています デフォルトでは、PostgreSQL データベースは 1,024 バイトを超えるクエリを切り捨てます。ログに記録されるクエリサイズを増やすには、DB インスタンスに関連付けられた DB パラメータグループの track_activity_query_size パラメータを変更します。このパラメータを変更する場合、データベースの再起動が必要です 詳細については、 GitHub リポジトリ を参照してください。 PI Reporter のインストールと実行 PI Reporter は使いやすいように設計されています。Linux OS を搭載した Amazon EC2 上、または Aurora PostgreSQL クラスターが実行されている AWS リージョンにアクセス可能なオンプレミスの Linux ホスト上で、 GitHub リポジトリ からダウンロードできます。 PI Reporter をインストールするには、以下の手順を実行します : リポジトリをローカルファイルシステムにクローンします : git clone https://github.com/awslabs/pireporter.git リポジトリをクローンした後、 pireporter ディレクトリ内に pireporterPolicy.json AWS Identity and Access Management (IAM) ポリシーファイルがあります。このポリシーには、PI Reporter を実行するために必要な権限が含まれています。これらの権限は読み取り専用で、必須のもののみが含まれています。このポリシーにより、 pireporter:allow タグが付いたインスタンスとクラスターのみにアクセスできます。制限条件を緩和したい場合は、提供されたポリシーファイルを変更できます。 pireporterPolicy を、ツールを実行する予定の EC2 インスタンスのインスタンスロールにアタッチします。オンプレミスの Linux ホストでツールを実行する場合は、共有認証情報ファイル ~/.aws/credentials でアクセスキーとシークレットキーを使用します。EC2 インスタンスに最新バージョンの AWS CLI をインストールして、プログラムで RDS インスタンスに接続します。PI Reporter で使用される AWS SDK は、ロード時にポリシーファイルを自動的に読み取ります。この場合、ポリシーはアクセスキーが適用される IAM エンティティにアタッチされている必要があります。AWS リージョンは、インスタンスメタデータに基づいて、ホスティング EC2 インスタンスのリージョンに自動的に設定されます。特にオンプレミスでツールを実行する場合は、AWS_REGION 環境変数を希望の値に設定することで、これをオーバーライドできます ツールを実行するには 2 つのオプションがあります : Node.js を使用して pireporter ツールを実行するには、レポートを生成したいホストに Node.js がインストールされている必要があります : cd pireporter npm install node pireporter.js --help ポータブル版を使用する場合（ホストに Node.js をインストールしたくない場合）は、次のコマンドを使用します : cd pireporter/portable ./pireporter --help 特定の期間のスナップショットを生成するには、次のコマンドを使用します : ./pireporter --create-snapshot --rds-instance myinstance --start-time 2025-01-20T10:00 --end-time 2025-01-20T10:15 --comment "Unusually slow inserts" 上記の例では、 create-snapshot コマンドが疑わしいアクティビティや異常な動作を観察した 15 分間の時間間隔のデータをキャプチャします。そうでない場合は、終了して次のメッセージを出力します : No performance data available from Performance Insights for the selected time frame. Please choose a time frame with application load or user activity. これは、指定した時間枠によって数秒から 1 分程度かかる場合があります。メトリクスの平均値の希釈を減らすために、スナップショットの境界を関心のある期間に制限してください。このコマンドは、snapshots サブフォルダに JSON スナップショットファイルを生成します。 --comment 引数を使用すると、生成されたスナップショットにコメントを関連付けることができます。このコメントは LLM に渡され、その推論動作に影響を与える可能性があります。 キャプチャしたスナップショットに対して生成 AI 分析と推奨事項を含む HTML レポートを生成するには、次のコマンドを使用します : ./pireporter --create-report --snapshot snapshot_myinstance_202501201000_202501201015.json --ai-analyzes --ai-analyzes 引数は、Amazon Bedrock によって提供される LLM の分析を HTML レポートに含めます。レポートは reports サブフォルダに保存されます。 ツールで使用される LLM (リージョンとモデル ID) は、 conf.json ファイルで確認できます。Converse API をサポートする Amazon Bedrock の LLM を使用できます。 考慮事項と推奨事項 PI Reporter はインスタンスの動作の変化を特定して問題検出フェーズを最小化するために作成されたため、2 つのスナップショットを生成することを推奨します : インスタンスが異常な動作をしている問題のある期間 インスタンスが正常に動作していた類似の期間 次に --create-compare-report を使用して比較 HTML レポートを生成します。これにより、大幅に変更されたメトリクスと SQL を確認できます。 比較期間レポートの生成 AI 分析は、両方の期間のデータがあることで、より洞察に富んだものになります。両方の期間は以下の要件を満たす必要があります : 両方の期間は同じ長さである必要があります 問題のあるスナップショットは、問題が開始した時点から開始する必要があります 問題のあるスナップショットは、問題が終了した時点で終了するか、問題がまだ存在する場合は開始時刻から 60 分など合理的な時間後に終了する必要があります また、スナップショットに意味のあるコメントを提供することも検討してください。LLM に対して、特定の領域に注意を向けるよう指示したり、ユーザーとしての観察結果を伝えるなどのヒントを提供できます。 生成 AI は幻覚を起こしたり、間違った仮定を提供したりする可能性があります。私たちは、有用なデータベースエンジン固有の知識を含む追加のコンテキストを LLM に提供することで、これを最小限に抑えるよう努めました。生成 AI 分析は、それらを評価できるデータベース専門家と組み合わせて使用することをお勧めします。 レポートの解釈 LLM が生成するレポートの部分は、HTML レポートの上部にある薄い青色のボックスに表示されます。生成 AI セクションは一般的な要約から始まり、主な発見事項と問題の根本原因 (ある場合) が含まれます。 一般的なレポートサマリーの後に、レポートの各セクションのサマリーが表示されます。これには、一般的なインスタンス設定、非デフォルトパラメータ、待機イベント、OS メトリクス、DB メトリクス、および DB インスタンスの全体的なネットワークスループットなどの追加メトリクスが含まれます。これらは他の統計情報と SQL セクションから計算されます。スナップショット作成時に --include-logfiles 引数が指定されていた場合、レポートにはスナップショット期間のデータベースログファイルの分析も含まれます。 次のスクリーンショットは、ユースケース用に生成されたレポートからの生成 AI 分析のサマリーセクションを示しています。サマリーには、CPU、メモリ、ネットワークスループットなどの非常に高いリソース使用率に関するいくつかの観察結果が含まれています。また、高負荷の原因となっているワークロードタイプ（ insert ステートメントやその他の書き込みアクティビティ）に関する情報も取得できます。さらに、 public.employee テーブルでの insert と autovacuum アクティビティという 2 つの SQL ステートメントが表示されます。SQL 参照 ID を選択すると、完全な SQL テキストを表示できます。レポートでは、パフォーマンス問題の根本原因も提供されます。 一般的な要約の次のセクションは、推奨事項セクションです。このセクションには、問題の根本原因を修正するために LLM が生成したステップが含まれています。この特定のケースでは、LLM は観測されたワークロードを処理できる推奨インスタンスタイプの 1 つにインスタンスをスケールアップすることを推奨しています。また、ワークロードを確認し、システムへの影響を減らすために特定の autovacuum パラメータを調整することも推奨しています。 リアクティブユースケース: バルクデータインサート このセクションでは、データベースでバルクデータロードを実行し、CPU、ディスク、IOPS、ネットワークなどの異なるリソースの使用率を観察するユースケースについて説明します。リソースの使用率が高くなると、アクティブまたはパッシブアラートがトリガーされる可能性があるため、リソースが過度に使用されており、アップグレードが必要であることを理解できます。 バルクデータインサートの前提条件 このユースケースを検証するには、データを一括挿入するテーブルが必要です。例えば、以下のコードを参照してください。 BEGIN ; CREATE TABLE employee( emp_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name TEXT NOT NULL ); COMMIT ; バルクデータインサートのユースケース 以下のコードを使用してバルクインサートを実行します : BEGIN ; INSERT INTO employee (name) SELECT substr(md5(random()::text), 1, 12) FROM generate_series(1, 100000000) AS _g ; ANALYZE ; COMMIT ; このテストケースでは、 employee テーブルに大量のデータを挿入するために、前述の INSERT 文を 100000000 の件数で実行しました。これにより 500 MB のデータが作成され、テーブルに挿入されました。 次に、PI Reporter を使用して AI/ML ベースのレポートを作成するには、以下のコマンドを実行します : ./pireporter --create-snapshot --rds-instance myinstance --start-time 2024-10-15T09:00 --end-time 2024-10-16T08:00 --comment "Bulk inserts" ./pireporter --create-report --snapshot snapshot_myinstance_202410150900_202410160800.json --ai-analyzes ここで、 --start-time と --end-time パラメータは、insert 文の実行前のタイムスタンプと insert 文の完了後のタイムスタンプに対応する必要があります。レポートが生成されたら、HTML レポートファイルを開いてレポートを読むことができます。次の推奨事項が表示されます : レポートの最初の部分では、レポートの開始時刻と終了時刻、およびレポートが生成された総期間の詳細が表示されます。次に、インスタンスの高レベルな詳細と、一括実行した insert 文などのリソース使用率上昇の責任または主要な原因が示されます。パフォーマンスに影響を与えるクエリと、定期的な vacuum および checkpoint チューニングの必要性が強調されています。 同じ情報が上記の推奨事項セクションに記載されていますが、ポイントごとの詳細が含まれています。 推奨事項の最初の部分は、インスタンスの一般情報に関するもので、従っている高可用性プラクティス、設定されているバックアップと監視オプションが含まれます。次のセクションには、レポート期間のメモリと CPU 使用率に関する静的メトリクスが含まれます。最後のセクションは、存在する場合のデフォルト以外のパラメータに関するものです。 AI によって生成されたレポートの分析では、リソース使用率と IO イベントに関する洞察が提供されます。また、インスタンスの現在のサイズ、使用率、推奨される適切なインスタンスタイプについても説明されています。さらに、CPU 使用率、ディスク IO、メモリ、ネットワーク、スワップ使用量などの重要な OS メトリクスも提供されます。この場合、リソースが十分に活用されていなかったため、コスト最適化のために適切なインスタンスタイプを選択することが推奨されました。これらの推奨事項を生成する際は、レポートを生成する期間を十分に長く設定することを確認してください。実装前に、データベースの専門家と推奨事項を検証してください。 上記の画像のデータベースメトリクスに関する推奨事項は価値があります。バルクインサートトランザクションアクティビティ、チェックポイントチューニング、定期的なバキュームに関する提案が含まれているためです。 最終的な GenAI 分析では、インスタンスを十分に活用できていないことに関するインサイトが提供されますが、ダウンサイジングを実行する前に、インスタンスのパフォーマンスを総合的に確認することを強く推奨します。CPU、ネットワーク帯域幅、効率的なキャッシュ、ディスク IO、チェックポイント、autovacuum などの要素を考慮してください。これらの洞察はすべて、データベースパフォーマンスの最適化において価値があります。統合された推奨事項では、クエリ最適化、インスタンスアップグレード、削除保護、バックアップ保持、高可用性のためのリーダーインスタンスの追加がカバーされています。 アイドルトランザクションのユースケース PI Reporter ツールは、スナップショットを使用して収集されたデータで動作します。アイドル状態のトランザクションセッションがあるスナップショットで収集された統計は、最終レポートで報告されます。アイドル状態のトランザクションを自動的に終了し、リソースの保持を防ぐために、 idle_in_transaction_session_timeout パラメータを 300 秒 (5 分) の値で実装することを推奨します。 上記の画像では、PI Reporter がトランザクション内でアイドル状態のセッションを明確に特定し、関連するパラメータに適切な値を設定することを推奨しています。また、コミットやロールバックのないトランザクションブロックを見つけるために、アプリケーションコードを確認することも提案しています。5 分以上アイドル状態のトランザクションに対する監視アラートを設定することを推奨しており、これにより、そのようなトランザクションを終了したり、データベースリソースの大部分を消費し始める前に問題を修正したりできます。Amazon CloudWatch Database Insights は、Database Telemetry -&gt; Metrics オプションの下で、最大アイドルトランザクションメトリクスを提供します。 データベースメトリクスセクションでは、セッションがトランザクション内でアイドル状態になっている概算時間を確認できます。最後の Analysis セクションでは、パフォーマンスの向上とコスト最適化のためのインスタンス全体の推奨事項をまとめています。 クリーンアップ Amazon Bedrock によって作成された AWS リソースは、使用している限りコストが発生します。生成 AI 分析を含むレポートを生成するたびに、PI Reporter は特定の呼び出しで使用された入力トークンと出力トークンの数を出力します。リソースが不要になったら、関連するサービスとスクリプトを削除してクリーンアップしてください。この投稿に従ってテスト環境を作成した場合は、使用が完了したらリソースをクリーンアップしてください。 機能の概要 次の表は、PI Reporter ツールの機能の概要を示しています。 パラメータ/機能 PI Reporter クラウドに依存しない No オンプレミスデータベース No 設定の推奨事項 Yes データベースの健全性 Yes インデックスの推奨事項 Yes 非効率な SQL Yes Autovacuum Yes パフォーマンスチャート No エージェントタイプ No 本番環境対応 Yes コスト Apache-2.0 ライセンス インフラストラクチャと Amazon Bedrock に関連するコスト *デプロイメントオプション、データベースフリートのサイズ、複数年契約などの要因が最終的なコストに大きく影響します。 まとめ この投稿では、PI Reporter ツールの監視機能と可能なユースケースについて説明しました。PI Reporter は数秒で有用な情報を収集し、JSON スナップショットに保存できます。これらは HTML レポートの生成や将来の調査のための保存に使用できます。これは、トラブルシューティングや DB インスタンスの健全性を理解するのに役立つツールです。Amazon Bedrock でホストされている LLM と組み合わせて使用することで、利用可能なメトリクスと SQL を分析し、生成 AI に調査結果の要約、問題の根本原因の検出、推奨事項の提供を行わせることができます。 この記事で説明した PI Reporter ツールには独自の機能があり、お客様のワークロードに適合する場合もあれば適合しない場合もあるため、慎重にテストと評価を行う必要があります。本番環境で実行する前に、非本番環境でこれらのツールをテストすることを強く推奨します。 皆様のフィードバックをお待ちしています。ご質問やご提案がございましたら、コメント欄でお聞かせください。 著者について Sachin Kotwal Sachin はAWSにおいてマイグレーションとモダナイゼーションを専門とするデリバリーコンサルタントです。お客様と連携し、様々なデータベースおよびマイグレーション・モダナイゼーションプロジェクトに関するガイダンスと技術支援を提供しています。これまでに数多くの同種データベース移行やパフォーマンス最適化プロジェクトに携わってきました。 Aychin Gasimov Aychin はAWSにおいてデータとAIを専門とするシニア・パートナー・ソリューション・アーキテクトです。彼は顧客やパートナーと連携し、様々なデータベース、アナリティクス、AIプロジェクトに関するガイダンスと技術支援を提供しています。 HariKrishna Boorgadda HariKrishna はAmazon Web Servicesのプロフェッショナルサービスチームに所属するシニアデリバリーコンサルタントです。AWSへのデータベース移行を専門とし、顧客と連携してAmazon RDSおよびAmazon Auroraのアーキテクチャ設計と実装を担当しています。 Sachin Khanna Sachin はAWSプロフェッショナルサービスチームにおいて人工知能および機械学習（AI/ML）を専門とするリードコンサルタントです。データ管理、生成AI、大規模言語モデル、機械学習における豊富な経験を持ち、データ、データベース、AI駆動型ソリューションに関わるプロジェクトに幅広い専門知識を提供します。クラウド移行とコスト最適化における熟練したスキルにより、顧客のクラウド導入プロセスを成功へと導き、カスタマイズされたソリューションと戦略的洞察を提供しています。 翻訳は、ソリューションアーキテクトの鈴木が担当しました。 原文 はこちらです。