本ブログは、2025 年 9 月 23 日に Adam Balest によって執筆された「 Showcase your AWS achievements with the new Skills Profile 」を翻訳したものです。 AWS Training and Certification では、AWS のスキルと成果を共有したい学習者のために、AWS Skill Builder の新機能「スキルプロファイル」の提供を開始しました。これは、AWS 認定、学習成果、デジタルバッジを 1 つの共有可能なプロファイルで紹介する強力な新しい方法です。スキルプロファイルにはカスタマイズ可能な共有オプションがあり、可視性と信頼性を高めながら、学習者それぞれのクラウドスキルを伝えるために使用できます。 スキルプロファイルは Skill Builder にサインインしている学習者が利用でき、AWS の学習成果を公開できる中心的な場所となります。あなたが意欲的なクラウドプラクティショナーであろうとベテランエキスパートであろうと、あなたのスキルプロファイルはあなたの AWS スキルのショーケースとなり、LinkedIn などのプラットフォームや求人応募で、同僚や採用マネージャーにすぐに共有可能です。 「スキルプロファイルでは、AWS の学習過程と、私が身に付けたスキルを簡単に紹介できます。認定資格や学習のマイルストーンをわかりやすい形式で共有できます。スクリーンショットや色々な場所に散らばったリンクは必要ありません。」— AWS Skill Builderの学習者 学習から専門的な評価へ 専門的なプラットフォームでのソーシャルラーニングの広がりにより、学習者が信頼性の高い一貫した方法で専門知識を示すことが不可欠になっています。スキルプロファイルは、プライベートな学習記録と、公開される専門的な評価の間のギャップを埋めるものです。 Skill Builder 内の学習者ダッシュボードはプライベートである一方、スキルプロファイルは公開共有を目的に設計されています。AWS の認定資格、Skill Builder での学習成果、Cloud Quest のバッジ、その他の達成項目などを紹介できます。表示内容を完全にコントロールできるため、自分がプロファイルで共有したい内容を伝えることができます。 スキル共有を通じたつながりの構築 スキルプロファイルは、クラウドの専門知識を可視化し、共有可能にすることで、学習者と組織の双方に新たな価値をもたらします。認証された AWS での実績を共有することで、新たな職業的なつながり、コラボレーション、キャリアの機会への扉が開かれます。 学習者にとっては、熱心に培ってきたスキルを示す手段となり、組織や採用担当者にとっては、クラウド人材を発見し検証するための信頼できる情報源となります。これらの共有プロファイルにより、スキルを持つ専門家と、現在および将来の機会との間により強固なつながりが生まれます。 今後、スキルプロファイルは、特定のスキルや AWS クラウドでの成果に基づいて組織や採用担当者が人材を発見するのを助ける機能に加えて、さらに多くの共有可能な実績を含むように拡張される予定です。 スキルプロファイルの始め方 スキルプロファイルを使い始めるには、AWS Skill Builder にサインインし、画面右上の「アカウント」より「プロフィール」に移動し、スキルプロファイルを作成・カスタマイズします。そこから、表示する実績を選択し、ヘッドライン (オプション) を挿入して、プロファイルのリンクをネットワークと共有できます。 次の役職に就くことを目指している場合でも、最近の認定資格を紹介したい場合でも、AWS で学んだことを誇りを持って共有したい場合でも、スキルプロファイルを使用して自分のクラウド専門知識を世界に共有できます。 あなたの AWS ストーリーを共有する準備はできましたか ? 今すぐ AWS Skill Builder にサインインして、スキルプロファイルを作成しましょう ! 翻訳は Technical Instructor の 室橋 弘和 が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 2025 年も多くのお客様に生成 AI の活用にチャレンジいただいております。特に注目すべきは、生成 AI をコアビジネスの価値向上や成長加速に繋げる事例が増えてきていることです。今回ご紹介するのは、医療従事者向けの情報サービスを提供する株式会社ケアネット様が、AWS の生成 AI サービスである Amazon Bedrock を活用して、医師向け情報サービスの価値を大幅に向上させた事例です。 ケアネット様の状況と課題 株式会社ケアネット様は、医療従事者向けプラットフォームを基盤に、医療の人材・教育・経営関連の事業から新薬の開発・治験普及を支援する事業まで、医療・医薬分野の専門サービスを幅広く展開しています。 その中でも、日常臨床に役立つ医療・医学情報を提供する医師向けの会員制サイト「CareNet.com」は、ケアネット様の主力サービスとなっており、日本全国の医師数の約70%に相当する24万人が登録しています。CareNet.comでは、臨床医による連載やガイドライン解説などの臨床で役立つコンテンツや、医学誌に掲載された論文を厳選し日本語で要約したニュース記事を配信したりしています。しかし、忙しい医師にとっては次のような点が課題となっていました： 膨大な医学情報の処理：年間 150 万件以上の医学文献が発表される中、臨床医が最新情報を継続的に取得することが困難 情報提供の限界：従来の人力によるニュース作成では 1 日約 10 件程度しか提供できず、医師の情報ニーズを十分に満たせていなかった これらの課題を解決するため、ケアネット様は生成 AI を活用した新サービス「CareNet Academia（ケアネットアカデミア）」の開発に着手しました。ケアネットアカデミアは、「限られた時間で専門分野の知識を効率よくアップデートしたい」といった臨床現場のニーズに応えるスマホ対応ブラウザアプリケーションです。膨大な医学文献（米国国立医学図書館（NLM）が提供する医学文献データベース PubMed）のアブストラクト情報を読み込み、各医師ごとの関心に合わせて生成 AI が自動でニュース記事を選定・作成し、その内容がメールで配信されます。関心のあるトピックス（診療科や疾患）については利用開始時に選択可能となっており、配信されたニュース記事を評価することでより有益な情報を配信できるようになります。 ソリューション ケアネットアカデミアで配信する記事を作成するために、Amazon Bedrock を活用した大規模 AI ライティングシステムを構築しました。具体的には、Anthropic 社が開発した LLM である Claude を使ってニュース記事を自動生成し、独自開発のレコメンデーションAIと組み合わせることで、個々の医師に最適化された情報配信を実現しています。 本記事では、特に Amazon Bedrock を活用した AI ライティングシステムについて詳細に解説します。 主な機能 AI ライティングシステム（Amazon Bedrock を活用した機能） Claude を活用して医学文献から記事を自動生成 Claude を使って医学文献を整理・要約 解説記事の自動生成 Amazon Bedrock 選定理由 ケアネット様が Amazon Bedrock を選定した主な理由は以下の通りです： セキュリティとデータ保護 データが AWS 内に閉じるため、会員情報、医療情報のセキュリティを確保 転送中・保管時のデータ暗号化により、機密性の高い会員情報、医療情報を安全に処理 信頼性と品質 Amazon Bedrock の SLA が定義されており、安定したサービス品質を確保 スケーラビリティ クロスリージョン推論機能を活用し、大量のリクエストを並列処理 短時間で多数の記事を生成・処理することが可能 導入効果 Amazon Bedrock を活用した新機能の導入により以下の効果が得られました： 情報提供量の飛躍的増加 1日あたりの記事生成数が最大5,000件に拡大（従来比約500倍） 医師が必要とする幅広い医学情報をカバー 医師の情報収集効率化 膨大な医学文献から必要な情報だけを抽出・要約して提供 医師の情報収集時間の短縮と、より効率的な臨床判断をサポート また、CareNet Academiaをお使いいただいているユーザーの継続率は60%を超えていることからも、医師からの高い満足度が伺えます。さらに、ユーザーからの追加機能の要望（関心のある疾患カテゴリの追加）に迅速に対応したことで、「非常に有用で助かっている」という声も届いています。ケアネット様の CTO である榊原海様からは「Amazon Bedrock の活用で、AWS の統合されたセキュアなインフラ内でAI処理の大規模並列実行を実現できました。」とコメントを頂戴しています。 まとめ 本事例は、医療情報という専門性の高い分野において、生成 AI を活用してビジネスの価値向上に繋げた優れた事例です。Amazon Bedrock のセキュリティ、信頼性、スケーラビリティを活かし、医師向け情報サービスの質と量を大幅に向上させることに成功しました。 特に注目すべきは、単に業務効率化だけでなく、医師の情報収集をサポートし、最終的には医療の質向上に貢献するという社会的意義の高いユースケースである点です。AWS は今後も、このような社会的価値の創出に貢献できるよう、安全で信頼性の高い生成 AI サービスの提供を続けてまいります。 生成 AI を活用したビジネス価値の向上や、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、お気軽にお問い合わせください。 ソリューションアーキテクト 森 瞭輔

はじめに 近年、IT の急速な進歩と共に EC 市場は急速に拡大し、様々な顧客ニーズに応えるため EC サイトや決済手段も多様化する中、「電話」という従来からのチャネルの重要性は今なお低下することはありません。シニア層や IT に不慣れな方への対応や緊急時の問い合わせなど、電話での対応が必要とされるシーンは決して少なくなく、むしろ事業者様とお客様をつなぐ接点として大きな価値をもたらす役割を担っています。 その一方で、コンタクトセンターにおける人手不足やコストの課題は、業界共通の大きな悩みであることも事実です。オペレータの負荷軽減や業務効率化、運用コストの削減を目指す中で注目される技術として IVR (Interactive Voice Response) があります。IVR は電話による顧客対応を自動化する技術として活用されており、音声ガイダンスに従ってキーパッドから番号を入力する、あるいはユーザーが発話することで、その内容に応じて様々なサービスを利用できるシステムです。この技術により、ヒューマンオペレーターの対応を減らし必要な場面にだけオペレーターが介在できるため、人手不足の課題解決につながり、見方を変えると、オペレータ対応を真に必要とするお客様に絞った対応ができるため、問い合わせ窓口としての満足度向上にも貢献できます。 ここで注目したいのが、AWS が提供するクラウドベースのコンタクトセンターサービス Amazon Connect と AI による柔軟な対話を実現する Amazon Lex です。従来の定型フレーズによる音声ガイダンスでは無機質な印象もあった IVR ですが、AI や 音声合成マークアップ言語 (SSML) など、多様な機能を活用することで、より自然で温かみのあるインタラクションを AWS で実現することができます。そもそも、従来のオンプレミスのコンタクトセンター基盤の IVR にこうした最新のテクノロジーを組み込もうとした場合、時間やコストが制約になることもあります。これに対し、Amazon Connect と Amazon Lex はわずか数クリックでデプロイすることができ、料金についても初期費用不要の従量課金モデルでサービスを利用することが可能です。そのため、スモールスタートで素早く取り組みを開始し、事業成長とともに規模をスケールすることができます。 また、 Amazon Pay は Amazon が提供する ID 決済サービスで、Amazon アカウントを持っていればどなたでも利用できる簡単・便利な決済サービスです。 amazon.co.jp を普段からご利用いただいているお客様はすでに Amazon アカウントをお持ちですので、Amazon Pay をすぐに利用できます。 Amazon Pay が導入されている EC サイト では、Amazon アカウントに登録されたお支払い方法・お届け先住所を利用できるため、最短 3 ステップでお買い物が完了します。Amazon Pay を IVR による電話注文と統合することで、電話口でのやり取りから Web 決済までスムーズかつセキュアに完結し、これまで抱えていた「電話口でのクレジットカード番号の伝達」や「注文導線における入力操作の手間」というお客様の不安・不満、さらには事業者様が懸念する「購入からの途中離脱」の解消につながります。 本記事では、Amazon Connect および Amazon Lex を活用した IVR による電話注文から Amazon Pay での Web 決済につなげる新しい購入体験のシナリオや構成例についてご紹介します。お客様の利用シーンや属性に合わせて選択可能な最適なチャネルを提供し、コンタクトセンタービジネスをさらに拡張するアプローチのきっかけとなれば幸いです。 電話注文時のユーザー体験 本記事では電話注文のシーンに焦点を置き、電話注文の開始から決済完了までの一連の流れを想定します。 お客様がカタログやテレビショッピングで見た電話番号を入り口とし、どういった体験ができるかのアイデアをご紹介します。 一例ではありますが、以下のようなフローをユーザー体験として想定できます。 電話をかけて、商品名・購入数 を電話口で伝える。 注文を電話口で確認したら、電話をかけた端末に SMS メッセージを受信する。 SMS のリンクから Web に遷移し、Amazon Pay で決済を行う。 手順 1, 2 のフローは電話口でのインタラクションとなり、手順 3 は、Web での決済操作となるイメージです。 電話口でのインタラクションは IVR によって実現が可能です。つまりオペレータの介在なしに電話でのフローは完結できます。 例えば、以下のような対話イメージを IVR によって実現できます。 IVR による電話注文を実現する AWS のサービス 電話口での IVR は Amazon Connect と Amazon Lex で構築が可能です。 Amazon Connect は AWS が提供するクラウドベースのコンタクトセンターサービスで、Web コンソールの UI 上でブロックをつなげることで、コンタクトフローを簡単に構築することができます。そのブロックの中の一つに、Amazon Lex を呼び出すブロックがあります。Amazon Lex は 会話型インターフェースを構築する、いわゆるチャットボットのサービスです。Amazon Lex を Amazon Connect と統合することで、電話口での対話を実現することができます。Amazon Lex では注文を処理するためのインテントを構築し、Amazon Connect のフローの中で呼び出すように構築が可能です。「買い物したい」という発話によって、構築した注文処理のインテントが発動し、最後の注文確認までの会話フローを構築することができます。 また、Amazon Lex から AWS Lambda を呼び出すことも可能なため、Amazon Lex のインテントの中で注文確認ができれば AWS Lambda を呼び出し、注文情報をデータベースなどに保管するような構築イメージになります。 なお、SMS メッセージの送信についても AWS で実現することができ、例えば、Amazon SNS のサービスに SMS メッセージを送信する機能があります。Amazon Connect では発信者の電話番号を取得することができ、さらにコンタクトフローの中で AWS Lambda に電話番号情報を渡して実行することも可能です。そのため、Lambda 関数にて Amazon SNS から SMS 送信を行うよう実装することで、Amazon Connect から連携された電話番号をもとに発信者であるお客様に SMS メッセージを送信することを実現できます。 上記のように、多様な機能を提供する AWS のサービスを組み合わせることで、IVR による電話注文から SMS の送信まで、すべてを AWS でシンプルに実現できると考えています。電話注文でのインタラクションから SMS 送信までのアーキテクチャ例を以下に掲載いたしますので、ご参考にいただけますと幸いです。 本記事冒頭でも言及した通り AWS は従量課金モデルであるため、スモールスタートで「まず試してみる」といったことが可能です。新しい機能の導入・拡張に AWS は非常に親和性が高いです。 Amazon Pay による Web 決済 続いて、Web での決済操作の導線イメージをご紹介します。 ここでまずは簡単に Amazon Pay の紹介をいたします。 Amazon Pay とは Amazon Pay は Amazon のお客様向けに提供されている ID 決済サービスで、 Amazon Pay を導入されている事業者様 の EC サイトにてご利用いただけます。 Amazon Pay のご利用に新たな専用アカウント・アプリの登録は必要ありません。 Amazon アカウントをお持ちのお客様、つまり amazon.co.jp を普段からご利用いただいているお客様であれば、その Amazon アカウントに登録されているお支払い方法・お届け先住所を利用することができるため、購入したい EC サイトにて新たにクレジットカードや住所情報登録の手間が軽減され、スピーディーかつ安心してお買い物を楽しむことができます。また、Amazon Pay ではクレジットカードだけでなく、Amazon ギフトカードやあと払い（ペイディ）、メルペイ、パートナーポイントによるお支払いも可能です。 Amazon Pay に関する詳しい情報、および導入を検討される事業者様は、 Amazon Pay の公式ページ 、または こちらのページ から無料でダウンロードできる資料にてご説明しておりますので、ご参照ください。 Amazon Pay での決済イメージ Amazon Pay の概要を掴めたところで、決済操作の導線イメージをご紹介します。「電話注文時のユーザー体験」の章にて記載した手順 3 に相当する箇所のご紹介となります。 簡易な例ではございますが、以下に購入フローのイメージを掲載します。上部の水色のエリアが事業者様の EC サイト、下部のオレンジのエリアが Amazon 側のページ (Amazon Hosted Page) を表しています。 Amazon Pay ではこのように、EC サイトと Amazon Hosted Page を行き来することで決済を進めることが基本となります。 流れとしては、ユーザーに SMS が到達し、そこに記載された URL をクリックすることで、電話口での注文情報が反映されたカートページに遷移します。今回 SMS での送信としているのは、Amazon Connect で発信者の電話番号が取得できるためであり、他の手段で URL を送付する方法も考えられます。URL をクリックし Web ページに表示された Amazon Pay ボタンをクリックすることで、Amazon Hosted Page に遷移します。ユーザーはお持ちの Amazon アカウントでログインし、そのアカウントに登録されているお支払方法およびお届け先住所を選択、あとは EC サイト側で注文確定ボタンを押すことで Amazon Pay の決済を完了することができます。 このように、Amazon アカウントを持ったユーザーであれば、電話注文から購入完了までの一連の流れを、途中での入力の手間などなくスムーズに完結できるよう実装することが可能です。 Amazon Pay を事業者様サイトに組み込む方法については、 Amazon Pay インテグレーションガイド にて記載がございますので、適宜ご参照ください。 （EC サイトへの Amazon Pay 導入には お申し込み が必要です。） IVR × Amazon Pay 導入のメリット IVR による電話注文から、Amazon Pay での Web 決済に引き込むことで以下の観点でメリットがあると考えています。 待ち時間の軽減 IVR での自動応答がない場合、電話注文が殺到すると、オペレータに接続されるのを待つ時間が長くなってしまい、お客様の体験は低下します。 IVR による自動応答で一部の通話に対応することができれば、待ち呼数が減ることになり、有人対応を必要とするお客様もオペレータに繋がりやすくなります。 購入離脱の削減と在庫確保の安心感 オペレータと繋がらないことで今まで購入から離脱していたお客様を救うことができます。また、IVR によって商品の在庫状況をすぐに確認できるようになるため、例えば、期間限定商品の注文に対して、電話注文でまずは在庫を確保することでお客様の安心感や満足度を向上させることもできると考えられます。 有人対応が必要なお客様への手厚いサポート IVR による電話注文の導入により、その利用者だけでなく、一方でそれを利用しないお客様に対してもメリットがあると考えられます。例えば、高齢者やまだ Web 操作に不安がある方からの問い合わせや、注文トラブルなどの緊急の問い合わせに対して、オペレータをさらに動員させることできます。つまり、オペレータの対応が真に必要なお客様に対するサポートにより時間を充てられることにつながるため、コールセンターとしての質やお客様満足度の向上につながると考えられます。 電話口でのクレジットカード番号情報の伝達が不要、後払いによる支払い不安からの解消 Amazon Pay による Web での決済導線に誘導することで、電話口でクレジットカード番号を伝える必要がなくなります。加えて、商品と併せて配送する請求書でお客様からの入金を待つという決済モデルから解放され、支払い不安が解消されます。お客様および EC サイトを持つ事業者様双方においてメリットが出てくるポイントです。 利用シーン 利用シーンとしては、以下の場面が例として考えられます。 テレビ/ラジオ ショッピング カタログ通販 チケット予約 ホテル予約 飲食店予約時の事前決済 上記のユースケースや本記事にて紹介したフローはあくまで例ではございますので、他にも適用できる場面や取り入れられるフローなどがあるかと思います。イメージを膨らましていただくための一助となれば幸いです。 Outbound Call による Amazon Pay 決済 本記事でご紹介した構想は、テレビやカタログで見た電話番号に対してお客様から電話をかけるといったシーンを想定しておりました。一方、Amazon Connect では Outbound Call の機能があり、Amazon Connect からお客様に対して電話を発信することができます。 また、Amazon Pay では Payment Method On File (PMOF) という機能があります。 PMOF という機能は、購入者が商品を初回購入するタイミング、あるいはマイページなどから事前に支払い方法を登録することで、以降の購入時は事業者の任意のタイミングでその購入者が登録した支払い方法に対して課金することができる機能です。 支払い方法の事前設定を必要とする事業者や、購入者の操作なしに取引を処理する必要がある事業者に有用な機能です。 IVR を使った Amazon Connect からの Outbound Call と Amazon Pay の PMOF の機能を統合することで、お客様の再購入をサポートする体験を実現することも可能です。 （現時点におきまして、PMOF は Amazon Pay の担当者より個別でご案内をした事業者様のみご利用いただける限定機能となっております。導入のご検討・PMOF の技術資料をお求めの場合は Amazon Pay への お申し込み 後、担当者へご相談ください。） 流れとしては、初回の購入時あるいは事前に PMOF によって支払い方法を登録します。 初回の購入時から例えば 2 週間経過したタイミングで、その購入者に対して Amazon Connect から Outbound Call をかけます。 Outbound Call の中でお客様が購入の意思を示すことで、事前に PMOF にて登録した決済方法に対して請求をかけることができます。 これにより、再購入の際に Web 決済導線を再度操作することなく完結することができ、簡単でスムーズな購入体験を実現できます。 PMOF による支払い方法の登録を行った以降における Outbound Call での IVR 対話イメージ例を参考までに掲載いたします。 上記のイメージ例では、お客様は最短 1 クリックのキーパッド操作で購入まで完了できるため、非常に手軽でスムーズな購入体験になります。 認証コードによる本人確認や、注文から 60 分間は注文を取り消せるようにするといったオペレーションを組み込むことで、さらなる安心感を付加することもアイデアとしてあるかと思います。 なお、関連する記事といたしまして、取引内容の確認・承認を Amazon Connect の Outbound Call で自動化する技術ブログ Automate transaction confirmation using outbound calls with Amazon Connect もございますので、よろしければ参考にしてみてください。 最後に、Outbound Call に関して Amazon Connect Outbound Campaign という機能もございます。この機能はアウトリーチすべきお客様のセグメントを作成し、適切なタイミング、適切なチャネル（音声通話、SMS、Email等）でプロアクティブなアプローチを実現することができます。ここに IVR を活用することもでき、オペレータが不要な大規模なアウトリーチも可能です。ぜひご検討材料の一つとしていただけますと幸いです。 まとめ 本記事では、AWS で実現する IVR と Amazon Pay を統合することによって、電話注文から決済までを実現する構想についてご紹介しました。IVR を構成する AWS のサービスについても触れ、AWS を活用することでシンプルかつスモールスタートで始められる点、加えて柔軟に機能拡張していくことができる点も AWS 活用の大きな強みです。すでにコンタクトセンターを導入されている事業者様におきましても、IVR による電話注文のチャネルだけを切り出す形で AWS にて実現することも考えられます。また、Amazon Connect で実現するコンタクトセンターの柔軟性は Amazon Bedrock や Amazon Q in Connect と組み合わせることで、生成 AI の技術要素を盛り込みさらに広げていくこともできると考えています。 本記事でご紹介した対話フローや AWS 構成図は一例ではございますので、事業者様の取り扱う商材や社内要件、ターゲットとするお客様、必要となる機能によっても変わってくる部分があるかと思いますが、電話注文のチャネルを拡張するためのアイデアの一助となりましたら幸いでございます。 著者 庭屋 郁基 アマゾンジャパン合同会社 Amazon Payments Japan 事業部 Solutions Architect

はじめに 本稿は、日本航空株式会社デジタルEX企画部 空港オペレーショングループの橋本様よりご寄稿いただいた、成田空港でのドーリー運用効率化を目的とした動態管理システム導入プロジェクトの取り組みをご紹介します。 開発の経緯 空港内では、航空機に搭載する貨物や手荷物の入ったコンテナを運ぶために、『ドーリー』と呼ばれる台車を利用しています。 ドーリーは動力を持っておらず、牽引車で複数台連結して使用されます。航空機からコンテナを降ろすときも、航空機にコンテナを搭載するときも、必ずコンテナと同じ台数のドーリーが必要となります。 航空機からコンテナを降ろし、ドーリーに載せ替える 使用中のドーリー（コンテナあり） コンテナ搭載前のドーリー ドーリーに設置されたIoT機器 しかし、成田空港では以下のような課題に直面していました。 ドーリーの利用は、複数のグループ会社にまたがるため、各社で連絡を取り合いながら、利用するドーリーをそれぞれ確保している。 未使用のドーリーが空港内のどこに何台あるのか把握する手段が無く、利用の度に各社の現場作業者が捜索をしている。 ドーリーの稼働状況が分からず適正数が配備されているか不明。 成田空港内には多くのドーリー置き場や貨物上屋が点在しており、場合によっては移動に30分以上を要することもあります。そのため、ドーリーを見つけるだけでも多大な時間と労力がかかり、業務の効率性を損なう原因となっていました。 これらの課題を解決すべく、IoTデバイスとクラウド技術を活用した「DOLYSプロジェクト」を立ち上げました。 DOLYS導入の目指すもの 本プロジェクトの核となるのは、成田空港内の約3,040台のドーリーに装着したIoTデバイスを活用することで位置情報をリアルタイムに管理し、これを可視化するシステムです。このシステムにより以下の具体的な改善目標を掲げました。 1.ドーリー捜索時間の削減 IoTデバイスでリアルタイムに位置を管理することで、ドーリーを探す時間を削減し、業務効率を向上。 2.ドーリー稼働率の向上による台数削減 効率的な運用管理により、必要な台数を最適化し、ドーリーおよびカートの台数の削減。 プロジェクト体制とアプローチ 本プロジェクトでは、成田空港におけるドーリーの運用を効率化するシステムを低コスト・短期間で構築することを目指し、アジャイル開発を採用しました。この手法により、現場の課題や要望を迅速にシステムに反映しながら、稼働までのリードタイムを最小化しました。 特徴的なポイントとして、本プロジェクトでは、JALのグループ企業である JALグランドサービス 、 JALカーゴサービス 、 JALスカイ といった複数のグループ会社の現場からの意見を広く取り入れ、現場と開発チームとの連携を密接に構築。現場スタッフを主要ステークホルダーに位置付け、ユーザー目線のシステムを実現しました。 また、プロジェクトは「必要機能のみに絞る」という方針を掲げ、シンプルかつ実用性重視のシステム設計を行ったことが特徴です。 システムのアーキテクチャ AWSを基盤にしたサーバーレスアーキテクチャを採用しています。 システムの規模やデータ量に応じたリソースの自動スケールが可能となり、運用コストを最小化しました。また、サーバーレスの特性を活かし、迅速な開発と変更対応も可能になっています。 また、本システムはJALグループの統合クラウドプラットフォームである CIEL/S 上に構築することで、AWSの柔軟性を活用しつつ、同グループに求められるITガバナンス要件と高いセキュリティ基準を満たしました。 IoT技術とAWSのクラウドサービスを組み合わせることで、IoTデバイスからのリアルタイム位置情報を効率的に収集し、ドーリーの位置情報可視化および運用の最適化を実現しました。 ※DOLYS画面（成田空港の概略図にリアルタイムでドーリー台数を表示） また、現場作業者はiPadなどのタブレット端末を活用し、直感的にドーリーの場所を検索・確認できます。ダッシュボードでは「エリア・スポットごとのドーリー配置台数」や「各会社の必要数」をリアルタイム表示し、機材の種類やコンテナ搭載の有無など細かい条件による検索機能も備えているため、現場の即時対応力と業務効率を大幅に向上させています。 ※アーキテクチャ概略図 想定効果と今後の展望 本システムの導入により、以下の効果が見込まれます。 1.稼働率の向上に伴い、新規購入台数および点検費用の削減が可能となります。具体的には、年間で56台（約7％減）の更新台数削減により、約7,170万円のコスト削減が期待されます。 2.所在の見える化により、捜索時間と燃料消費の削減が実現します。年間で約14,157時間の捜索時間が削減され、燃料も約66,361リットル（約760万円相当）が節約されます。 加えてCO2排出量は年間約171トン削減され、環境負荷の軽減にも寄与します。 ※CO2算出方法：66,361[ℓ]×0.00258[t-CO2/ℓ]=171[t] 現在は成田空港で運用が進んでいますが、同様の仕組みを羽田空港にも展開する計画が進行中です。これにより、複数の主要空港でのドーリー運用効率が向上し、さらに標準化された管理体制が構築される見込みです。 現行のDOLYSは主に「ドーリーの現在位置」と「利用可否ステータス（積載検知）」を確認する機能で活用されていますが、将来的には以下のようなデータ分析機能の追加が構想されています。 稼働率の分析：ドーリーの使用頻度や運用状況を可視化。過剰な配備や不足を是正。 リソースマネジメント：人だけでなく、設備などのリソースを最適化し、全体の運用効率を最大化。 これらのデータ分析機能により、コスト削減と業務改善をさらに推進します。 まとめ 本稿でご紹介した「DOLYSプロジェクト」は、成田空港におけるドーリー管理の課題を起点に、IoTとクラウド技術を融合させた革新的なソリューションを実現しました。AWSを活用したサーバーレスアーキテクチャにより、低コストかつ迅速なシステム構築を可能とし、現場のニーズに対応したシンプルで使いやすい管理環境を提供しています。 導入効果として、稼働率向上による更新台数の削減や捜索時間・燃料消費の大幅な削減が想定されており、コストメリットだけでなく環境負荷の低減にも寄与しています。今後は、羽田空港への展開をはじめ、データ分析機能の充実によるさらなるリソース最適化を目指し、運用効率化に貢献してまいります。 本プロジェクトは、現場を中心に据えたアジャイル開発の好例であり、デジタル化推進における成功モデルとして、今後のさらなる業務改革の礎となることを期待しています。 日本航空株式会社 デジタルEX企画部空港オペレーショングループ 橋本 隆彦 2008年、日本航空のグランドハンドリング業務を担う株式会社JALグランドサービスに入社。 現場業務を経験後、2018年より社内システム開発に関する業務などを担当。 2024年より現職に従事。DOLYSや空港オペレーション系システムを担当。 日本航空株式会社 グランドハンドリング企画部BPR推進グループ 村上 忠 1993年、日本航空のグランドハンドリング業務を担う株式会社JALグランドサービスに入社。 現場業務・間接業務（安全品質・生産計画担当）を経験後、2022年より現職に従事。 DOLYSを含む空港ハンドリングの生産性向上施策を担当。 JALデジタル株式会社 デジタル開発部第1グループ 篠原 奈都未 2018年、日本航空のITを担う株式会社JALインフォテック（現：JALデジタル株式会社）に入社。 業務システムの基盤維持管理を担当。 2021年より現職に従事。 クラウドネイティブ技術を活用したアプリ開発やアジャイル開発推進を担当。

本記事は、2025 年 8 月 6 日に公開された Amazon QuickSight BIOps – Part 3: Assets deployment using APIs を翻訳したものです。翻訳は Solutions Architect の守田 凜々佳が担当しました。 ビジネスインテリジェンス (BI) エコシステムがチーム、アカウント、環境全体に拡大するにつれて、一貫性、信頼性、ガバナンスの維持が大きな課題となります。特にマルチアカウント環境では、ダッシュボードとデータセットを手動でデプロイすることで、バージョンの不一致、依存関係の破綻、運用リスクの増大につながることがあります。 このシリーズの投稿では、 Amazon QuickSight におけるビジネスインテリジェンス運用 (BIOps) に焦点を当てています。 パート 1 では、バージョン管理とコラボレーションのノーコードガイドを提供しました。 パート 2 では、QuickSight API を使用した自動バージョン管理とロールバック、そして BI アセットの継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインについて説明しました。本記事では、QuickSight における API を活用した BIOps 戦略に焦点を当て、特に以下のトピックについて説明します： API を使用したクロスアカウントおよび複数環境へのアセットの展開 データセットのバージョン更新時における競合の検出と解決 開発、QA、本番環境間での権限と設定の管理 Assets-as-Bundle API、 Describe-Definition API、自動化スクリプトなどのツールを使用して、手作業を最小限に抑え、下流での障害を防ぎながら、アセットをプログラムによって自動的にデプロイする方法を説明します。 ソリューションの概要 このシリーズの パート 2 では、QuickSight API を使用したバージョン管理、ロールバック、CI/CD ワークフローについて説明しました。本記事では、その内容を踏まえて、デプロイメントをスケールし、異なる環境間での一貫性を確保するための実践的なテクニックを紹介します。 以下のセクションでは、QuickSight における API ベースの BIOps ソリューションの概要を説明し、チームがプログラムコードを用いて BI アセットのデプロイメントとガバナンスを自動化する方法を紹介します。 QuickSight において複数の AWS アカウント・リージョン間での BI アセットのデプロイ方法について解説し、API を使用してダッシュボード、データセット、および依存関係を一貫性をもって、安全でスケーラブルな形で展開する方法を説明します。 前提条件 このチュートリアルを実施するには、以下の前提条件が必要です。 AWS アカウント 以下の AWS サービスへのアクセス: AWS CloudFormation Amazon QuickSight Amazon Simple Storage Service (Amazon S3) AWS Identity and Access Management (IAM)、QuickSight の Template 、 Assets-as-Bundle 、 Create 、 Update 、 Delete 、 Describe API にアクセスする権限を持っていること Python の基本的な知識 (Python 3.9 以降を使用) SQL の基本的な知識 最新バージョンの AWS Command Line Interface (AWS CLI) がインストールされている Boto3 がインストールされている また、続きを読む前に、このシリーズの パート 1 と パート 2 を確認することをお勧めします。 アセットデプロイメントのためのテンプレート API 「 BIOps: Amazon QuickSight object migration and version control 」では、テンプレートベースのアプローチを使用して QuickSight アセットをデプロイする方法について説明しています。執筆時点ではテンプレートは環境間でダッシュボードを移行およびバックアップするための主な手段でした。 開発環境と本番環境の 2 つの QuickSight アカウントがあるとします。両方のアカウントは、有効なデータソースに接続するように設定されています。 以下の図は、このアーキテクチャを示しています。 実装の詳細に興味がある場合は、 元の記事 を参照してください。ただし、現在ではアセットのデプロイメントにテンプレート方式を使用することはおすすめしていません。 Assets-as-Bundle や Describe-Definition などの新しい API が導入されたことで、BI チームは QuickSight アセットの管理において、より柔軟で透明性が高く、バージョン管理に適したオプションを利用できるようになりました。 アセットの一括デプロイのための Assets-as-Bundle API Automate and accelerate your Amazon QuickSight asset deployments using the new APIs では、 Assets-as-Bundle API を使用して、AWS アカウントやリージョン間で QuickSight アセットをデプロイする方法について説明しています。これらの API は、ダッシュボード、分析、データセットなど、依存関係のあるアセットのデプロイのために設計されています。 次の図は、このアプローチに基づくサンプルワークフローを示しています。 ExportAssetsBundle API は、QuickSight JSON または CloudFormation テンプレートの 2 つのエクスポート形式オプションを提供します。 QuickSight JSON オプションを使用すると、アセットは各アセットタイプ（分析、ダッシュボード、データセット、データソースなど）に対応した JSON ファイルを含む ZIP ファイルとしてエクスポートされます。 この ZIP パッケージはアセット間の関係を保持し、個々の JSON ファイルの確認や修正がしやすいため、デプロイメントの自動化に適していますが、きめ細かなバージョン管理には適していません。 コンテンツは、次のスクリーンショットに示すような階層構造で整理されています。 この サンプル Jupyter ノートブック では、QuickSight JSON 形式で、ソースアカウントからターゲットアカウントに QuickSight アセットをデプロイするための ExportAssetsBundle および ImportAssetsBundle API の使用方法を示すワークフローを提供しています。このサンプルは基本的なユースケースとなり、ソース管理の統合、バージョンタグ付け、環境固有の設定などの自動化ステップを組み込んだ包括的なデプロイメントパイプラインに拡張することができます。 アセットデプロイメントにおけるアクセス許可の管理 デフォルトでは、エクスポートされた QuickSight アセットは、エクスポート操作時に include-permissions オプションが明示的に有効化されていない限り、ユーザーレベルまたはグループレベルの権限は保持されません。 権限が含まれている場合でも、ソース環境とターゲット環境の両方でユーザー名またはグループ名が一致していない限り、アカウント間で正しくマッピングされない可能性があります。 適切なアクセス制御のために、インポートジョブの完了後に適切な UpdatePermissions API を使用して、アセットのアクセス権限を手動で更新することがベストプラクティスです。 これにより、ターゲット環境の正しいユーザーまたはグループが、インポートされたダッシュボード、分析、データセット、その他のアセットにアクセスできるようになります。 もう 1 つの選択肢は、 StartAssetBundleImportJob API の OverridePermissions パラメータを使用して、インポート時にアクセス許可を割り当てることです。インポートされたアセットへのアクセス権を付与する必要があるターゲットアカウントのユーザーまたはグループを指定できます。 ただし、このオプションは慎重に使用する必要があります。インポートジョブが完了すると、指定されたユーザーまたはグループは直ちにアセットにアクセスできるようになります。意図しないユーザーに機密性の高いダッシュボードやデータセットが公開されることを防ぐため、アクセス許可が正しく設定されていることを確認することが重要です。 環境固有の設定を使用したアセットデプロイメントの管理 StartAssetBundleImportJob API には OverrideParameters というパラメータも用意されており、BI チームはこれを使用してインポート時に環境固有の設定を上書きできます。 これには、Virtual Private Cloud (VPC) 接続、データソースの資格情報、その他のデプロイメント固有の属性などが含まれます。 OverrideParameters を使用することで、エクスポートされたバンドルファイルを直接変更することなく、新しいアカウントや環境にインポートされたアセットが正しいインフラストラクチャリソースに確実に接続できるようにします。 これは特に、ネットワークや認証設定が異なる環境間 (例えば、開発環境から本番環境) でアセットを昇格させる際に便利です。 環境やアカウント間でのアセットのデプロイデプロイメントに関するより包括的なアーキテクチャについては、 Guidance for Multi-Account Environments on Amazon QuickSight を参照してください。 このガイダンスでは、開発、検証、本番アカウントの体系的な管理、QuickSight の名前空間とアクセス許可の管理、自動化されたアセットデプロイパイプラインの実装について、企業のシステムに求められるガバナンスおよびスケーラビリティの要件を考慮したベストプラクティスを説明しています。 次の図は、このオプションのソリューションアーキテクチャを示しています。 Assets-as-Bundle API の CloudFormation テンプレートオプションは、機能的には QuickSight JSON オプションと似ています。 このオプションを選択すると、エクスポート出力は、ダッシュボードまたは分析と、データセット、データソース、テーマ、フォルダなどの依存関係をカプセル化した CloudFormation テンプレートになります。このオプションは、既に AWS CloudFormation をインフラストラクチャの自動化に使用しているチームにとって特に有用です。なぜなら、一貫したツールとデプロイメントパイプラインを使用して、他の AWS リソースと共に QuickSight アセットをデプロイおよび管理できるためです。 実践的な例として、 Assets-as-Bundle API の CloudFormation テンプレートオプションを使用した一連のワークフローを示す サンプル Jupyter ノートブック をご参照ください。 このノートブックでは、CloudFormation テンプレートを使用して、構造化された再現可能な形でアセット昇格を実現するために QuickSight のアセットをアカウント間でエクスポートおよびデプロイする方法を示しています。 以下の表は、CloudFormation テンプレートを用いる方法と QuickSight JSON ( Assets-as-Bundle API) を用いる方法を比較したものです。 項目 CloudFormation テンプレート QuickSight JSON エクスポート形式 YAML/JSON 形式の CloudFormation テンプレート ZIP アーカイブ内の構造化された JSON ファイル 目的 AWS CloudFormation ベースの Infrastructure as Code (IaC) ワークフローとの統合 QuickSight ネイティブ形式でのアセットの移植性と検査の簡素化 対象範囲 ダッシュボード、分析、および依存関係を含む ダッシュボード、分析、および依存関係を含む 変更可能性 AWS CloudFormation の構文知識が必要；より厳格 読み書きが容易；JSON は QuickSight の内部構造に従う デプロイメント方法 CloudFormation スタックを使用してデプロイ ImportAssetsBundle API を使用してインポート 開発ツールの互換性 AWS CloudFormation ベースの環境に最適 JSON ベースのワークフローまたはカスタムデプロイメントスクリプトに最適 可読性 BI ユーザーにとって直感的ではない；インフラ指向 BI チームにとってより直感的； Describe API と密接に連携 ユースケースの適合性 BI アセットのデプロイメントを広範な IaC テンプレートに統合するチーム向け QuickSight アセットの移行やコードベースのワークフローに焦点を当てたチーム向け Assets-as-Bundle API で利用可能な QuickSight JSON と CloudFormation テンプレートのオプションについて詳しく比較するには、 Choosing between the two export options of the Amazon QuickSight asset deployment APIs をご参照ください。 この記事では、それぞれのオプションの長所と短所について詳しく説明し、実際の例を示しながら、BI チームがデプロイメントワークフローと自動化のニーズに最適なフォーマットを選択できるようにサポートします。 Automate your Amazon QuickSight assets deployment using the new Amazon EventBridge integration では、 Assets-as-Bundle API を Amazon EventBridge と連携してデプロイメントワークフローを自動化する方法を説明しています。 QuickSight アセットの作成、更新、削除などのイベントに応答する EventBridge ルールを設定することで、チームは環境間でアセットのエクスポート、バージョン管理、昇格を行うワークフローを自動的にトリガーできます。この連携は、QuickSight の BI アセットに対してイベントドリブンの CI/CD パイプラインを実現する上で特に有用です。 アセットの段階的なデプロイのための Describe-Definition API このシリーズの パート 2 では、 Describe-Definition API を使用して、単一の QuickSight アカウント内でバージョン管理を行う方法について説明しました。 同じ原則をマルチアカウント構成に拡張することで、環境全体で BI アセットの体系的かつ選択的なデプロイが可能になります。 個々のアセットのデプロイに Describe API を使用することは、多くのシナリオでベストプラクティスとされています。例えば、関連するダッシュボードを更新せずに本番アカウントのデータセットの問題を修正するための緊急デプロイを実行する場合や、依存アセットに影響を与えずにダッシュボード内のフィルター定義を更新する場合などです。このきめ細かな制御により、デプロイのリスクを軽減し、不要な上書きを回避し、大規模な BI 環境における段階的な開発ワークフローとの整合性を保つことができます。 サンプルコードについては、QuickSight アセットのデプロイに関する 2 つの一連の自動化オプションを説明している BIOps: Amazon QuickSight object migration and version control を参照してください。 この記事は元々テンプレートベースのアプローチに基づいていましたが、基本的な概念は今でも有用です。 関連する GitHub リポジトリ で提供されているコードを再利用および応用することができます。 従来のテンプレート関連の API 呼び出しを、新しい DescribeDashboardDefinition やその他の Describe-Definition API に更新することで、バージョン管理されたリソースのデプロイに関する現在のベストプラクティスに沿って、同じ自動化ワークフローを拡張できます。 API メソッドの比較 以下の表は、 Assets-as-Bundle API と Describe-Definition API の使用を比較したものです。 比較項目 Assets-as-Bundle API Describe-Definition/Describe API 主なユースケース 環境、アカウント、リージョン間での関連アセットのデプロイ バージョン管理、モジュール開発、CI/CD 統合 粒度 依存関係 (データセット、ソース、テーマ、フォルダ) を含むダッシュボードと分析を完全にバンドル 個別のアセット定義に焦点を当てる 可視性 ZIP ファイルに埋め込まれた JSON または CloudFormation テンプレート；追加作業を要して内容確認が可能 API を通じて直接アクセス可能な、完全に可視化された行単位の JSON 定義 バージョン管理との適合性 理想的ではない；差分の確認、モジュール化、レビューが困難 優れている；Git ベースのワークフロー、レビュー、ロールバックに適している コンポーネントの再利用性 限定的；バンドルは自己完結型で、複数バンドルのシナリオではデータセットが重複する可能性がある 高い；適切に設計されたソリューションでは、コンポーネント (計算フィールド、フィルター) をアセット間で再利用およびモジュール化できる 開発ワークフロー QuickSight の既存のダッシュボードまたは分析からバンドルを作成 JSON をプログラムで作成または変更し、 Update API を使用して適用 デプロイメントワークフロー ExportAssetsBundle を使用してエクスポートし、 ImportAssetsBundle を使用してインポート Create または Update API を使用して変更をプッシュ 最適な用途 環境間でのダッシュボードとその依存関係をパッケージとして移行する場合 反復的な開発、CI/CD、コードベースの作業を行う BI チーム向け 制約 バンドルが大きく、冗長なアセットが含まれる可能性がある；個別のコンポーネントの分離や編集が困難 依存アセット (データセット、ソース、テーマ) は含まれず、別途処理が必要 バックアップ、リストア、ディザスタリカバリ このセクションでは、QuickSight API を使用して BI アセットのバックアップ、リストア、リカバリを行い、信頼性の高いディザスタリカバリを実現し、環境全体でのデータ損失を最小限に抑える方法について説明します。 QuickSight アセットのバックアップ、リストア、ディザスタリカバリには、 Assets-as-Bundle API と Describe-Definition API の両方を使用できます。 アセットを定期的にバンドル (ZIP ファイルまたは CloudFormation テンプレート) または個別の JSON 定義としてエクスポートすることで、BI チームは Amazon S3、Git、その他のリポジトリに保存されるバージョン管理されたバックアップを作成できます。 Assets-as-Bundle API を使用すると、チームはダッシュボードごとにバックアップを整理し、各ダッシュボードをその依存関係 (データセット、データソース、テーマなど) と共にエクスポートできます。このアプローチは便利で、ダッシュボード単位でのリカバリに適しています。 一方、 Describe-Definition API はより柔軟性が高いものの、より多くの労力を必要とします。 BI チームは、すべてのアセットを個別にリストアップし、タイプ別 (データソース、データセット、分析) に保存し、モジュール式のバックアップ構造を維持できます。確実な復元のためには、データソースから始まり、データセット、テーマ、最後にダッシュボードと分析という依存関係を意識した適切な順序でアセットを再デプロイする必要があります。 前述のとおり、記事 BIOps: Amazon QuickSight object migration and version control では、テンプレートベースのアプローチを使用して QuickSight アカウントのアセットをバックアップおよび復元するためのサンプル実装を提供しています。関連する Jupyter ノートブック では、アカウント全体でのアセットの一括エクスポートとインポートを自動化する方法を説明しています。 もともとはテンプレートを中心に構築されていましたが、関連する API 呼び出しを Describe-Definition API に置き換えることで、現在のベストプラクティスに沿った、スケーラブルで保守可能なバックアップおよび復元ワークフローを作成できます。 さらに、チームは QuickSight フォルダを使用してバックアップを整理し、関連するアセットを構造化された復旧戦略の一部としてグループ化することで、より直感的に復元の操作を管理できます。フォルダベースのバックアップと復元のアプローチについては、こちらの サンプル Jupyter ノートブック を参照してください。このノートブックでは、フォルダで整理された QuickSight アセットのエクスポートと再インポートの方法を示しており、BI チームが関連するアセット (ダッシュボード、分析、データセット) をグループ化して一括管理できるようになっています。 データセットとダッシュボード間のマージコンフリクトの解決方法 このセクションでは、QuickSight でデータセットとダッシュボード間のマージのコンフリクトを検出し解決する方法について説明し、スキーマの変更が依存する可視化やフィルターを壊さないようにする方法を解説します。 次の図は、データセットのバージョン管理とコンフリクト解決のワークフローを示しています。 このプロセスは初期データセット (v1) から始まり、フィールドの名前変更やデータ型の変更などの更新が発生したかどうかを評価します。更新が検出されると、データセットはバージョン 2 (v2) に進み、潜在的なマージのコンフリクトをチェックします。コンフリクトが見つかった場合、フィールドマッピング（例えば、名前が変更されたフィールドを再マッピングしてビジュアルを復元する）によって解決できるかどうかを判断します。コンフリクトが解決可能な場合、影響を受けたアセットを復旧するためにマッピングが適用されます。解決できない場合（例えば、データ型の変更による場合）、サンプルコードを使用して変更されたフィールドを自動的に検出し、未解決の変更によって破損したフィルターやビジュアルをクリーンアップできます。 データセットのマージのコンフリクトを検出して処理するためのサンプルコードは、以下の Jupyter ノートブック で入手できます。このノートブックでは、変更されたフィールドを自動的に特定し、フィールドのデータ型の変更などの単純なマッピングの問題を解決し、互換性のない変更によって破損したフィルターをクリーンアップする方法を示しています。 さらに、QuickSight データセットの更新時にマージのコンフリクトの検出を自動化するためのサンプルコードと GitHub Actions ワークフローを提供しました。Python スクリプト compare_quicksight_datasets.py は、データセットのバージョンを比較して、データ型の変更、フィールド名の変更、フィールドの追加、フィールドの削除を特定します。 GitHub Actions ワークフロー compare-quicksight.yml は、比較を実行するために自動的にトリガーされます。 比較結果はリポジトリの新しいアーティファクトとして保存され、BI チームが変更内容を確認し、データセットのバージョン昇格時にコンフリクトを自動的に解決するか、手動での対応を行うかの判断を下すことができます。 ワークフローを設定して実行するには、以下のステップを完了してください： YAML ファイルが正しい GitHub ディレクトリに保存されていることを確認してください。 .github/workflows/compare-quicksight.yml リポジトリは以下のような構造になっているはずです。 your-repo/ ├── .github/ │ └── workflows/ │ └── compare-quicksight.yml ├── compare_quicksight_datasets.py ├── ... 以下の例のように compare-quicksight.yml に有効なトリガーが含まれていることを確認してください。 name: Compare QuickSight Datasets on: workflow_dispatch: # 手動トリガーを許可 この方法により、 Actions タブからワークフローを手動で実行できます。 ワークフローファイルをリポジトリにコミットしてプッシュします： git add .github/workflows/compare-quicksight.yml git commit -m "Add QuickSight dataset comparison workflow" git push origin main GitHub リポジトリのシークレットを追加します： GitHub リポジトリに移動し、 Settings, Secrets and variables, Actions を選択します。 New repository secret を選択します。 以下のようなシークレットを追加します： AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_REGION QUICKSIGHT_ACCOUNT_ID NEW_DATASET_ID ワークフローを実行します： GitHub リポジトリに移動します。 Actions タブで、 Compare QuickSight Datasets を選択します。 Run workflow を選択し、必要な入力情報を提供します。 このユーティリティは、バージョン管理やデプロイメントパイプラインの一部として使用できます。また、BI チームは分析やダッシュボードで影響を受けるビジュアルやフィルターを直接確認して更新することで、手動でコンフリクトを解決できます。 リソースの削除 今後の料金発生を防ぐため、テスト中に作成した S3 バケット、QuickSight データセット、分析、ダッシュボード、サンプルスクリプトで使用したその他のリソースなどを削除してください。 まとめ QuickSight API の機能により、大規模な BI アセットを管理するための強力な自動化、ガバナンス、柔軟性が実現可能になります。本記事では、クロスアカウントおよび複数環境のデプロイメント、コンフリクトの検出とガバナンスに API を使用する方法について説明しました。本記事のガイダンスを使用して、QuickSight の信頼性が高くコンフリクトを考慮したデプロイメント手法を確立できます。 著者について Ying Wang は、AWS の Generative AI 組織の Senior Specialist Solutions Architect で、Amazon QuickSight と Amazon Q を専門とし、大規模エンタープライズおよび ISV のお客様をサポートしています。データアーキテクトおよびソフトウェア開発エンジニアリングマネージャーとしての強固な経験を持つとともに、データ分析とデータサイエンスの分野で 16 年の経験を有しています。データアーキテクトとして、お客様のクラウドにおけるエンタープライズデータアーキテクチャソリューションの設計とスケーリングを支援してきました。エンジニアリングマネージャーとしては、エンジニアリングとプロダクトの双方の観点から新機能の提供と製品革新を推進し、QuickSight を通じてお客様のデータの力を引き出すことを可能にしました。

本記事は、2025年8月6日に公開された Amazon QuickSight BIOps – Part 2: Version control using APIs を翻訳したものです。翻訳は ProServe Data Analytics Consultant の西澤 祐介が担当しました。 この記事では、API駆動のビジネスインテリジェンスオペレーションズ（BIOps）フレームワークの概要を説明します。このフレームワークは、手作業による負荷を軽減し、Amazon QuickSightにおけるライフサイクル管理を改善することを目的としています。 ビジネスインテリジェンス (BI) 環境が複雑化する中で、ダッシュボード、データセット、デプロイといった作業を手動で管理していると、結果の不整合、バージョンのずれ、コラボレーションの効率低下といった課題につながりがちです。データから得られるインサイトの提供をスケールさせ、ガバナンスを強化し、そして開発、QA（品質保証）、本番といった各環境の信頼性を高める上で、自動化は極めて重要になります。 DevOps は、ソフトウェア開発と IT 運用を統合することで、デリバリーを加速し、信頼性を向上させるための考え方です。ソフトウェアのワークフローを合理化し、スケールさせるために、DevOps では以下のプラクティスが重視されます。 継続的インテグレーションと継続的デリバリー（CI/CD） Infrastructure as Code (IaC) と Assets as Code (AaC) 自動化 モニタリング コラボレーションツール（Git、Jira、Slackなど） BIOps は、これらの原則を BI のワークフローに応用したものです。アセットのバックアップ、バージョン管理、デプロイを自動化することで、BI チームはダッシュボード、データセット、分析を、一貫性を高め、トレーサビリティを向上させ、より効率的に管理できるようになります。 このブログシリーズでは、皆様が QuickSight で BIOps のプラクティスを実装し、よりスケーラブルで信頼性の高い BIOps を実現するための方法について解説します。 パート1 では、ノーコードでのバージョン管理とコラボレーションに関するガイドを提供しました。この記事では、QuickSight API を使用してバージョン管理とロールバックを自動化し、BI アセットのための CI/CD パイプラインを構築する方法について解説します。そして パート3 では、クロスアカウントおよびマルチ環境でのデプロイ、競合の検出とガバナンスについて取り上げます。 ソリューションの概要 この記事では、QuickSight における API ベースの BIOps ソリューションの概要を解説し、チームがプログラムによって制御する手法で BI アセットのバージョン管理、デプロイ、ガバナンスを自動化する方法を紹介します。BI エンジニア、DevOps リード、そしてプラットフォーム管理者の方々は、この記事で紹介するコードベースのプラクティスを実践することで、BI ワークフローをスケールさせることができます。 前提条件 このチュートリアルを進めるにあたり、以下の前提条件が必要です。 AWS アカウント  以下の AWS サービスへのアクセス権: AWS CloudFormation Amazon QuickSight Amazon Simple Storage Service (Amazon S3) AWS Identity and Access Management (IAM)：QuickSight の Template , Assets-as-Bundle , Create , Update , Delete , Describe API を利用できる権限が必要です。 Python の基本的な知識（Python 3.9 以降を推奨） SQL の基本的な知識 最新バージョンの AWS Command Line Interface (AWS CLI) が インストール 済みであること Boto3 がインストール済みであること また、このチュートリアルを始める前に、シリーズの パート1 を確認しておくことをお勧めします。 QuickSight アセット API の概要 QuickSight は、BI アーティファクトを管理するための API ベースのアプローチを複数提供しています。バージョン管理、デプロイの自動化、バックアップといった目的に応じて、それぞれ強みの異なる API を使い分けることができます。 主なアプローチは以下の3つです。 Template API (旧来の方法) Assets-as-Bundle API (新しい方法) Describe-Definition API これら3つのアプローチは、いずれもダッシュボード、分析、データセットなどをプログラムで扱うことを可能にしますが、可視性、制御性、そして最新の CI/CD ワークフローとの親和性において大きく異なります。 Template API 「テンプレート」ベースのアプローチは、 CreateTemplate や CreateDashboard といった API を利用し、AWS アカウントや AWS リージョンをまたいで QuickSight のアセットを移行するための従来からの手法でした。従来、「テンプレート」はダッシュボードのバックアップや、他の環境へのアセットのデプロイに使用されてきました。初期の実装では、「テンプレート」の中身は不透明で、BIチームにとっては完全なブラックボックスでした。しかし、 DescribeTemplateDefinition API の登場により、チームは「テンプレート」のJSON 定義を抽出して、内容の確認やバックアップを行えるようになりました。とは言え、「テンプレート」は新しい他の方法に比べて柔軟性に欠け、反復的な開発、フィールドレベルでの編集、あるいはバージョン管理といったワークフローには最適化されていません。 それでも、Git リポジトリや S3 バケットといった外部のバージョン管理システムやストレージをセットアップせずに、QuickSight 環境内にバックアップを保存したいと考える BI チームにとっては、「テンプレート」は依然として有用です。このため、製品内でのアセット管理を中心に行いたいチームにとって、「テンプレート」は手軽な選択肢となります。 QuickSight アセットに関する Template API の全リストは以下の通りです。 CreateTemplate DeleteTemplate DescribeTemplate DescribeTemplateDefinition UpdateTemplate UpdateTemplatePermissions Assets-as-Bundle API CI/CDパイプラインを導入したり、IaC を実践したりしているチームにとって、モダンな Assets-as-Bundle API と Describe-Definition API は、より高い透明性、柔軟性、そして制御性をもたらします。そのため、今日の多くのエンタープライズ向けのユースケースにおいて推奨されるアプローチとなっています。 Assets-as-Bundle API は、よりモジュール化され、ポータビリティの高いデプロイの選択肢を提供します。この API は、QuickSight のダッシュボードや分析、そしてそれらに関連するアセット（データセット、データソース、テーマ、フォルダ）を、ZIP アーカイブ、または AWS CloudFormation テンプレートとしてエクスポートします。エクスポートされたアーカイブを展開すれば、アセットのメタデータを JSON ファイルとして確認することは可能ですが、それには手間がかかり、きめ細かいバージョン管理には理想的ではありません。さらに、複数のダッシュボードをエクスポートする際には、複数のバンドル間でデータセットが重複し、冗長な形で含まれてしまう可能性があります。QuickSight のインポート処理はこれらの重複を適切に処理し、意図しない上書きを防いでくれますが、やはりこの手法は、詳細なバージョン管理というよりは、関連アセットをまとめてデプロイする用途に適しています。 ソースアカウントからバンドルファイルをエクスポートするジョブの開始、追跡、詳細確認には、以下の API を使用します。バンドルファイルとは、呼び出し元が指定したアセットと、オプションでそのアセットが依存するすべてのリソースを含む ZIP ファイル（拡張子は .qs ）のことです。 StartAssetBundleExportJob – アセットバンドルファイルをエクスポートするための非同期 APIです。 DescribeAssetBundleExportJob – エクスポートジョブのステータスを取得するための同期 APIです。成功した場合、レスポンスにはバンドルを取得するための署名付き URL が含まれます。 ListAssetBundleExportJobs – 過去のエクスポートジョブを一覧表示するための同期 API です。リストには、過去15日間の完了したジョブと実行中のジョブが両方含まれます。 以下の API は、バンドルファイルを入力として受け取り、ターゲットのアカウントでアセットを新規作成または更新するインポートジョブの開始、追跡、詳細確認を行います。 StartAssetBundleImportJob – アセットバンドルファイルのインポートを開始するための非同期 API です。 DescribeAssetBundleImportJob – インポートジョブのステータスを取得するための同期 API です。 ListAssetBundleImportJobs – 過去のインポートジョブを一覧表示するための同期 API です。リストには、過去15日間の完了したジョブと実行中のジョブが両方含まれます。 Describe-Definition API `Describe-Definition API` は、各アーティファクトの内部的な JSON 構造を、透過的かつフィールドレベルのフォーマットで公開します。この定義ファイルは Git で追跡したり、プルリクエストを通じてレビューしたり、対応する Update API で更新したりすることが可能です。そのため、CI/CD パイプラインや IaC プラクティスとの統合に最適な手法と言えます。主なトレードオフは、データセットやデータソースといった依存関係を個別に扱う必要がある点です。これらはダッシュボードや分析の定義には自動でバンドルされないためです。 Describe-Definition API には以下が含まれます。 DescribeDataSource DescribeDataSet DescribeAnalysisDefinition DescribeDashboardDefinition 実際の現場では、多くの BI チームは両方のアプローチを併用しています。アセットをまとめてデプロイする際には Assets-as-Bundle を、そして、きめ細かいバージョン管理や反復開発には Describe-Definition を利用する、といった使い分けです。それぞれの API をいつ使うべきか理解することで、ガバナンスの強化、監査性の向上、そして環境間でのスムーズなアセットの移行が可能になります。 各手法の比較 以下の表は、これら3つの API 手法の主なユースケースとデータの保管場所をまとめたものです。 手法 主なユースケース 用途 保管場所 Template API 製品内でのバックアップ、レガシーなデプロイ UI 中心のチーム、シンプルなバックアップ QuickSight 内 Describe-Definition API きめ細かいバージョン管理と自動化 CI/CD、Git との連携 Git, Amazon S3, コードリポジトリ Assets-as-Bundle API 依存関係を含めた環境単位のデプロイ 開発環境から本番環境への展開、一括移行 Amazon S3, ローカルのZIPアーカイブ QuickSight APIに関するより詳細な情報については、 QuickSight API リファレンス や Boto3 QuickSight ドキュメント をご参照ください。 BI アーティファクトのバージョン管理におけるベストプラクティス これ以降のセクションでは、単一アカウント内でのダッシュボードのバージョン管理に関するベストプラクティスを解説します。 QuickSight において、「ダッシュボード」は他の人が見れるように設定された、「分析」のスナップショットです。一方、「分析」は、BI チームが開発や改善を繰り返すための作業用アセットです。QuickSight の UI 上では、バージョン管理機能は「ダッシュボード」に対してのみ提供されています。これは、「分析」がエンドユーザーに公開されることはなく、常に開発中のものと見なされているためです。 しかし、 Describe-Definition API のようなプログラム的な手法を用いると、分析の各要素（フィルター、計算フィールド、ビジュアル、パラメーターなど）を、モジュール化されたコードブロックとして扱うことができます。これにより、チームは構造化されたコード駆動の方法で「分析」を管理し、バージョンを記録していくことが可能になります。結果として、複数の作成者が並行して共同作業を進められるようになります。そのため、 Describe-Definition API を利用する際には、「分析」自体のバージョン管理も重要なプラクティスであると我々は考えています。 Template API を利用したバージョン管理 以前のブログ記事「 BIOps: Amazon QuickSight object migration and version control 」では、テンプレートベースのアプローチを用いて QuickSight のダッシュボードのバージョン管理を実装する方法を解説しました。その記事の執筆時点では、「テンプレート」が、「ダッシュボード」のバージョン管理を行うための唯一利用可能なメカニズムでした。 次の図は、そのソリューションで用いたアーキテクチャを示したものです。 このワークフローは以下のステップで構成されます。 まず、BI 開発者が「分析」を作成し、それに基づいて「テンプレート」を保存します。これらがバージョン1のアセットとなります。 この「分析」は「ダッシュボード」として公開され、QA チームがこのバージョン1の「ダッシュボード」に対してテストを実施します。 QA テストの後、BI 開発者は「分析」の改修を続け、バージョン2を構築します。 更新された「分析」は、バージョン2の「ダッシュボード」として公開されます。 QA チームはバージョン2の「ダッシュボード」をテストし、結果に応じて以下のアクションのいずれかを実行します。 テストに合格した場合： BI 管理者は「テンプレート」を更新し、バージョン2の内容を反映させます。 問題が発見された場合： BI 開発者は分析上で修正を試みます。 問題が修正可能な場合、バージョン2の開発が継続されます。 問題が修正不可能な場合、BI 管理者はバックアップ用の「テンプレート」を使ってバージョン1にロールバックできます。 QuickSight には、作成者がセッション中に以前のバージョンに戻せる Undo 機能があります。もし Undo の履歴がリセットされた場合（例えばデータセットの置換など）、あるいは以前に安定版として確認済みの状態へのロールバックが必要になった場合は、BI 管理者はバージョン1の「テンプレート」と UpdateAnalysis API を使って分析を復元できます。 BI 開発者は、この復元されたバージョン1の「分析」をベースに作業を再開し、次の安定バージョンを目指して開発サイクルを繰り返します。 Describe-Definition API を利用したバージョン管理 次の図は、 Describe-Definition API と Create または Update API を利用して、QuickSight アセットのバージョン管理を実装するためのアーキテクチャを示したものです。 ワークフローは以下のステップで構成されます。 アセットの作成と保存 BI チームは、 Describe-Definition API のレスポンス構文を参考に、プログラムで QuickSight アセットの構築を開始できます。ダッシュボードや分析は、シート、計算フィールド、ビジュアル、フィルター、パラメーターといった JSON ベースの構成要素を使って構築可能です。同様に、データセットも物理テーブルと論理テーブルのマッピングを定義する JSON 構造を用いて作成できます。QuickSight のアセットは構造化された JSON 形式に従っているため、コード駆動の開発に適しています。 学習のハードルを下げるために、まず QuickSight コンソールを使ってアセットを作成し、その設定が要件を満たしていることを確認した上で、 Describe-Definition API でアセットの定義を抽出する方法もあります。抽出した JSON 定義は、Git、Amazon S3、あるいは社内のコードリポジトリといったバージョン管理が可能な場所に保存できます。これは、UI ベースの開発からコード駆動の開発へスムーズに移行するのに役立ちます。 チームが既に本番環境にアセットをデプロイ済みで、そこからプログラムによるワークフローに移行したい場合は、本番アカウントから直接 Describe-Definition API で定義を抽出できます。その定義を開発環境のソースリポジトリ（Git や Amazon S3 など）に保存し、今後の開発やデプロイの起点として利用することが可能です。 JSON 定義のデプロイと可視化 BI チームが JSON 定義の開発を完了したら、 Create または Update API （ CreateDashboard , UpdateAnalysis , UpdateDataSet など）を使ってアセットをデプロイし、QuickSight コンソール上で直接内容を可視化します。これにより、コードからビジュアルへのシームレスな移行が実現し、バージョン管理されている定義が UI に一貫して反映されるようになります。 テストと本番環境へのデプロイ 開発環境や QA 環境にアセットをデプロイした後、BI チームはテストを実施し、アセットが機能面・ビジュアル面で要件を満たしているか検証します。検証後、テスト済みの定義を同じ Create または Update API を使って本番アカウントへデプロイすることで、統制の取れた一貫性のあるリリースプロセスを実現できます。更新された分析を QA という名前のフォルダにデプロイする サンプルコード 、QA アカウントへデプロイする サンプルコード を用意してますのでご確認下さい。 以下の サンプルコード は、「分析」の定義を取得し、dev という名前のフォルダにコピーします。これにより、BI チームはアセットをプログラムで開発・管理できるようになります。 def describe_analysis_definition(session, id): qs = session.client('quicksight') sts_client = session.client("sts") account_id = sts_client.get_caller_identity()["Account"] try: response = qs.describe_analysis_definition( AwsAccountId=account_id, AnalysisId=id) except Exception as e: return ('Faild to describe analysis: ' + str(e)) else: return response try: sample_analysis = func.describe_analysis_definition(qs_session, analysisid) print('Successfully get sample analysis contents.') except Exception as e: faillist.append({ "Action": "scenario_1_dev: get sample analysis contents", "Error Type": "describe_analysis_contents Error", "AnalysisID": analysisid, "Name": 'template_1', "Error": str(e) }) new_id = 'copy_t_1_' + str(int(time.time())) new_name = 'copy_t_1' try: res = func.copy_analysis(qs_session, sample_analysis, new_id, new_name, 'owner', dev_config["assets_owner"]) except Exception as e: faillist.append({ "Action": "scenario_1_dev: copy analysis", "Error Type": "copy_analysis Error", "AnalysisID": analysisid, "Name": 'template_1', "Error": str(e) }) time.sleep(20) status = func.check_object_status('analysis', new_id, qs_session) print('Copy status of analysis ' + new_id + ' is ' + status) if status == 'CREATION_SUCCESSFUL': res = func.locate_folder_of_asset(qs_session, new_id, dev_config["dev_folder"], 'ANALYSIS') print('Successfully copied analysis ' + new_id + ' in dev account/folder.') 以下の サンプルコード は、「分析」を定義し、計算フィールド、パラメーター、フィルターをプログラムで追加するものです。これらの二次的なアセット（計算フィールド、フィルター、パラメーター）は、再利用可能なコードブロックとして共有ライブラリに保存されます。 { "most_recent": { "DataSetIdentifier": "ds_assets_as_code", "Name": "most_recent", "Expression": "max({date_time})" } , "Calculated TimeFrame": { "DataSetIdentifier": "ds_assets_as_code", "Name": "Calculated TimeFrame", "Expression": "datediff(${StartDate},${Enddate},'DD')" } } """ Now, please add CalculatedFields """ f = open('Assets_as_Code/library/2nd_class_assets/analysis_cf_library.json') l_cf = json.load(f) cf_name = 'most_recent' try: res = func.update_analysis(qs_session,new_id, new_name, new_analysis, 'CalculatedFields', l_cf[cf_name]) except Exception as e: faillist.append({ "Action": "scenario_2_dev: add CalculatedFields", "Error Type": "update_analysis Error", "AnalysisID": new_id, "Name": new_name, "Error": str(e) }) print(cf_name + " is successfully added into analysis " + new_name) """ Now, please add parameters (keyword: ParameterDeclarations) """ new_analysis = func.describe_analysis_definition(qs_session, new_id) f = open('Assets_as_Code/library/2nd_class_assets/parameter_library.json') l_p = json.load(f) p_name = "StartDate" try: res = func.update_analysis(qs_session,new_id, new_name, new_analysis, 'ParameterDeclarations', l_p[p_name]) except Exception as e: faillist.append({ "Action": "scenario_2_dev: add ParameterDeclarations", "Error Type": "update_analysis Error", "AnalysisID": new_id, "Name": new_name, "Error": str(e) }) print(p_name + " is successfully added into analysis " + new_name) ビルド済みの関数群は GitHub で公開されています。 ライブラリ 、 ユーティリティ 、 設定サンプル 、 ロギングヘルパー といったその他の補助コードは、以下の ディレクトリ に格納されています。 次のスクリーンショットは、AaC（Assets as Code）アプローチにおけるサンプルコードのディレクトリ構造を示したものです。パッケージ全体をダウンロードし、独自のAaCソリューションを構築するためのベストプラクティスとしてご活用ください。 このアーキテクチャでは、バージョン管理は Git リポジトリや Amazon S3 のバージョニング機能といった外部の仕組みで扱われます。このアプローチにより、BI チームはアセットを並行開発したり、計算フィールド、フィルター、ビジュアルといった二次的なアセットを再利用したりすることが可能になります。例えば、チームは計算フィールドの定義を、標準化された名前を持つ独立した JSON オブジェクトとして保存できます。これにより、複数の分析やダッシュボードをまたいで再利用できるようになります。この手法のさらなるメリットとしては、プルリクエストによる行単位のコードレビュー、以前のバージョンへの簡単なロールバック、そして CI/CD ワークフローとのシームレスな統合などが挙げられます。 まとめると、このパターンは QuickSight を完全にコード駆動のプラットフォームへと変革し、インフラと BI アセットをコードとして扱うことを可能にします。 QuickSight UI と API を併用したハイブリッドワークフローによるバージョン管理 BI チームは、このアーキテクチャを拡張してハイブリッドモデルを構築することもできます。つまり、開発は QuickSight UI で行い、バージョン管理を API 経由で行うというモデルです。このアプローチでは、チームは QuickSight コンソール上で対話的にアセットの構築や更新を続けます。開発が完了し、アセットがテストに合格したら、チームは Describe-Definition API を使って更新された JSON 定義を抽出し、Git や Amazon S3 といったバージョン管理リポジトリに保存します。 このモデルは、UI ベース開発の容易さと柔軟性を、コードベースのバージョン管理が持つ構造性やトレーサビリティと組み合わせるものです。プログラムによるワークフローへ移行しようとしているBI チームにとっては、まさに両者の良いとこ取りと言えるでしょう。 次の図は、UI ベースの開発とコードベースのバージョン管理が持つ構造性やトレーサビリティを組み合わせたアーキテクチャを示しています。 ワークフローは以下のステップで構成されます。 BI の作成者は、ダッシュボード、分析、データセット、データソース、テーマを QuickSight コンソール上で直接開発します。 開発が完了し、アセットが機能面・ビジュアル面のテストに合格したら、チームは Describe-Definition API を使ってアセットの定義をエクスポートし、Git やAmazon S3 に保存します。 検証済みのアセットは、 Create または Update API を使って本番環境にデプロイされます。 作成者は、次のバージョンに向けてUI 上で同じアセットの開発を再開します。 作成したバージョンはテストされます。 テストに合格した場合：リポジトリにあるバージョン管理された JSON 定義を更新し、ステップ6に進みます。 テストに失敗した場合：Git や Amazon S3 に保存しておいた以前の定義を使い、 Update API を介して QuickSight UI 上のアセットをロールバックします。 更新された、あるいはロールバックされた定義を本番アカウントにデプロイすることで、安定したバージョン管理下でのリリースを実現します。 Amazon EventBridge を利用した QuickSight のバージョン管理自動化 Amazon EventBridge を利用すると、個々の QuickSight アセット（分析、ダッシュボード、VPC 接続など）やフォルダ構造への変更を、アセットレベルのイベントとしてほぼリアルタイムに捉え、監視することができます。ここで言うイベントには、アセットの作成、更新、削除、フォルダ構成の変更などが含まれます。詳細については、「 Automate your Amazon QuickSight assets deployment using the new Amazon EventBridge integration 」をご参照ください。 QuickSight と EventBridge を連携させることで、BI チームは特定のアセットやフォルダが変更された際に、後続のワークフロー（例えば AWS Lambda や AWS Step Functions ）を自動的にトリガーするルールを定義できます。これにより、アセット定義のエクスポート、Git や Amazon S3 へのスナップショット保存、監査やロールバックのためのタグ付けといったバージョン管理プロセスがシームレスになります。結果として、チームは手動での介入なしにガバナンスを自動化し、環境間の一貫性を維持できるようになります。 Assets-as-Bundle APIを利用したバージョン管理 Assets-as-Bundle API をバージョン管理に利用することは推奨しません。この API の主なユースケースは、ダッシュボードとその依存関係にあるアセットを環境間で移行（例えば、開発環境から QA、本番環境へ）することです。バンドルファイルは技術的には保存して再利用できますが、きめ細かい追跡、比較、モジュール開発にはあまり適していません。適切なバージョン管理のためには、 Describe-Definition API を Git や Amazon S3 ベースのストレージと組み合わせて利用してください。 クリーンアップ 将来的な課金を防ぐため、テスト中に作成した S3 バケット、QuickSight のデータセット、分析、ダッシュボード、その他サンプルスクリプトで利用したアセットなどのリソースは削除してください。 まとめ この記事で解説した QuickSight API の機能は、BI アセットを大規模に管理するための強力な自動化、ガバナンス、そして柔軟性をもたらします。これらの API により、アセットのライフサイクルを完全にコントロールし、CI/CD パイプラインや Git ベースのワークフロー、カスタムツールとシームレスに連携させることが可能になります。ダッシュボードのバージョン管理、環境をまたいだデプロイ、スキーマ競合の解決などを簡単に行うことができます。 きめ細かい制御、監査性、アカウントやリージョンをまたいだ再現可能なデプロイが必要な場合は、API を利用してください。スピード、使いやすさ、あるいは手軽なイテレーションを優先する場合は、QuickSight コンソールを利用しましょう。多くのチームにとっては、QuickSight コンソールで開発し、変更のキャプチャを API で行うというハイブリッドなアプローチが、両方の長所を活かす最良の方法となるでしょう。 BIOps プラクティスを導入することで、BI チームはデリバリーをスケールさせ、リスクを低減し、一回限りの開発から、信頼性が高く統制の取れたインサイトの創出へと移行することができます。 パート3 では、クロスアカウントおよびマルチ環境でのデプロイ、そして競合の検出とガバナンスについて解説します。

本記事は、2025年8⽉6⽇に公開された Amazon QuickSight BIOps – Part 1: A no-code guide to version control and collaboration を翻訳したもの です。翻訳は Public Sector PSA の西川継延が担当しました。 ビジネスインテリジェンス（BI）チームが成長するにつれて、ダッシュボード、データセット、分析の管理はますます複雑になります。明確なバージョン管理なしでのコラボレーションは、作業の上書き、レポートの不整合、本番環境でのエラーにつながる可能性があります。ビジネスのステイクホルダーは迅速なインサイトを要求しますが、BI 作成者は変更を間違いなく繰り返し、自信を持ってデプロイするためのツールを欠いていることがよくあります。 DevOps の原則に着想を得たビジネスインテリジェンスオペレーション（BIOps）は、BI プロセスにバージョン管理と共同開発を導入します。この記事では、 Amazon QuickSight のノーコードのコンソール機能を使用して BIOps を実装する方法を説明します。ダッシュボードのバージョン管理、ビジュアルの再利用、並行でのコラボレーション、そして更新の安全なデプロイを、すべて QuickSight UI を通じて行う方法を紹介します。私たちのフレームワークは、QuickSight に組み込まれたバージョン管理ツールを使用して、チームが管理を合理化し、手作業を削減するのに役立ちます。このコード不要のアプローチは、BI アナリストとダッシュボード作成者の両方がこれらのプラクティスをすぐに採用するのに役立ちます。 QuickSight の基本 このセクションでは、Amazon QuickSight におけるビジネスインテリジェンスオペレーション（BIOps）の基本を紹介します。QuickSight のアセットがどのように分類されるか、基礎となる権限モデル、そして私たちのオペレーションを導く不可欠な BIOps の原則という3つの主要な領域を検証します。 アセットの分類 QuickSight はアセットを4つのカテゴリに整理し、それぞれが BI ワークフローで特定の目的を果たします。 メインアセット – これらは中核となる構成要素であり、QuickSight コンソール上でスタンドアロンのオブジェクトとして表示されます。これらのアセットは相互に依存しています。例えば、分析はデータセットに依存し、データセットはデータソースに依存します。 データソースは、 Amazon Redshift 、 Amazon Athena 、 Amazon Simple Storage Service (Amazon S3) などのシステムに接続します。 データセットはデータソースから構築され、結合、カスタム SQL、計算フィールドを含むことができます。 分析は、ビジュアルを構築するためのインタラクティブな環境です。 ダッシュボードは、分析が公開されたもので、読み取り専用のバージョンです。 Amazon Q のトピックは、自然言語クエリのためのセマンティックレイヤーを定義します。 補助アセット -これらはユーザーエクスペリエンスを向上させますが、QuickSight UI では主要なオブジェクトではありません。例えば、テーマはダッシュボードや分析のスタイルを定義しますが、QuickSight コンソール上ではスタンドアロンのアセットとしてリストされません。しかし、テーマは API を介してプログラム的にスタンドアロンのオブジェクトとして管理でき、 list 、 describe 、 update 、 delete などの操作をサポートします。 セカンドクラスアセット – これらはメインアセット内の内部コンポーネントであり、カスタム SQL、テーブル、フィルター、計算フィールド、パラメータなどが含まれます。これらの要素は QuickSight コンソール UI 上ではスタンドアロンのオブジェクトではなく、直接的なリスト ( list ) や詳細表示 ( describe ) の API コールを通じてもアクセスできません。代わりに、データセット、分析、またはダッシュボードの定義内で定義されます。これらは QuickSight コンテンツのロジック、構造、およびインタラクティビティを定義する上で重要な役割を果たします。 フォルダ – これらはメインアセットを階層構造に整理するために使用される管理アセットです。個人用または共有フォルダを作成してアセットを分類できます。フォルダはアクセス権限をサポートし、1つのアセットは複数のフォルダに存在できます。 権限モデル QuickSight のメインアセット、補助アセット、および管理アセットは、安全なコラボレーションのためにユーザーおよびグループレベルの権限をサポートしています。 BIOps の基本ワークフロー BIOps には３つのコア機能が含まれます。 アセットのバックアップと復元 – これは通常、AWS アカウントごと、または AWS リージョンごとにスコープが設定されます。このプロセスにより、誤った削除、サービスの中断、またはデータの破損が発生した場合に QuickSight アセットを復元できることが保証されます。 バージョン管理 – これは同じ AWS アカウント内で適用でき、BI チームはアセット定義（例えば、データセットやダッシュボード）への変更を追跡したり、以前のバージョンにロールバックしたり、時間の経過とともに異なる開発ブランチを維持したりできます。 デプロイメント – これは環境間（例えば、開発アカウントからテスト、QA、本番アカウントへ）およびリージョン間（例えば、 us-east-1 から us-west-2 へアセットをデプロイ）でのアセットの昇格をサポートします。 BIOps ワークフローを使用すると、チームはアセットレベルとフォルダレベルの両方でデプロイとバックアップを管理できます。ダッシュボードをデプロイする際、チームは機能をサポートするために依存アセット（データセット、データソース、テーマ）を含めることができます。フォルダレベルの操作により、関連するアセットを単一のパッケージとして昇格させることが可能になります。AWS アカウント間でのデプロイには、慎重な権限管理が必要です。アセットタイプにはユーザーまたはグループの権限があり、セキュリティを維持し、依存関係の破損を防ぐために、ターゲット環境で適切に再作成する必要があります。 次の図は、BIOps ワークフローの概要を説明したものです。バージョン管理は、QuickSight コンソール UI を通じても実現できます。 QuickSight ダッシュボードの構築と公開 次のグラフに示すように、QuickSight のダッシュボード開発プロセスは、BI 作成者から始まります。BI 作成者は、アクセス管理を簡素化するためにグループにまとめることができます。 作成者はまず、QuickSight を Amazon Redshift などのストレージシステムに接続してデータソースを作成します。次に、変換、結合、カスタムフィールドを追加してデータセットを構築します。データセットの鮮度は、手動またはスケジュールされた更新によって維持され、モニタリング機能も備わっています。 これらのデータセットを使用して、作成者はビジュアルとインタラクティブなコンポーネントを備えた分析を作成します。一貫した組織のブランディングのためにテーマを適用することができます。最終ステップは、分析をダッシュボードとして公開し、特定のユーザーやグループと共有することです。このプロセスにより、ガバナンスを維持しながら、スケーラブルなセルフサービス BI が可能になります。 ソリューションの概要 この記事では、３つの主要な QuickSight 機能について説明します。 コンソール UI を通じた ダッシュボードのバージョン管理 異なる分析からダッシュボードを公開することによる並行でのチームコラボレーション 他の分析やダッシュボードから ビジュアルをインポート することによるコンテンツの再利用 QuickSight コンソールのこれらの新機能により、ノーコードのインターフェースを通じて効率的な BI コラボレーションとダッシュボードのライフサイクル管理が可能になります。作成者は以下のことができます。 ダッシュボードとデータセットのバージョン履歴を追跡する ダッシュボードを以前のバージョンにロールバックする アセットを手動で複製する 分析とダッシュボード間でビジュアルをインポートおよびエクスポートする アセットの説明を通じて変更を文書化する ブックマークを使用してパーソナライズされたビューを作成する 元に戻す（undo）とやり直し（redo）機能で分析の編集を管理する これらの機能は、コーディングの経験を必要とせずに、合理化されたガバナンスとチームコラボレーションをサポートします。 この記事では、ノーコードでUIベースのワークフローに焦点を当てます。このシリーズの パート 2 と パート 3 では、QuickSight API とプログラム可能なアプローチを使用した自動化されたガバナンスとデプロイについて説明します。 UI ベースのデータセットとダッシュボードのバージョン管理 QuickSight は 2021 年後半にネイティブな データセットのバージョン管理 を導入しました。ユーザーは、QuickSight コンソール UI 内で直接、最大 1,000 の公開済みバージョンを追跡および管理できます。データセットの所有者は、過去の状態をプレビューしたり、以前のバージョンに戻したり、安全に編集したりできます。これには、互換性のない変更（削除されたソースや無効な計算など）に対する保護機能が含まれています。 2025 年 4 月、QuickSight は  ダッシュボードのバージョン管理 を導入し、バージョン管理機能をデータセットから完全なダッシュボードへと拡張しました。ダッシュボードの所有者は、UI を通じてバージョンの管理、変更の追跡、以前の状態への復元を、コードを書くことなく行えるようになりました。技術チームは引き続き API ベースの自動化を選択するかもしれませんが、アナリストやビジネスユーザーはこれらの機能を利用して、エンドツーエンドのダッシュボードライフサイクル管理を容易に行うことができます。 次の図は、QuickSight のダッシュボード開発における、バージョン管理された継続的インテグレーションと継続的デリバリー（CI/CD）のワークフローを示しています。 ワークフローは、分析の作成と編集（バージョン 1）から始まり、次にそれをダッシュボードバージョン 1 として公開します。QA テストの後、ダッシュボードが合格すれば、分析はバージョン 2 に更新され、再公開されます。QA テストがどの時点でも失敗した場合、チームは現在のバージョンの編集を続けるか、以前のバージョンにロールバックすることができます。このサイクルは、公開、テスト、更新という反復的な開発を続け、変更が本番環境に到達する前に検証されることを保証します。「元に戻す」「やり直し」アクションは分析内の変更をサポートし、バージョンのロールバックは BI チームの安全性と俊敏性を高めます。 分析における軽微な編集のための「元に戻す」「やり直し」 QuickSight で分析を編集する際、作成者は 「元に戻す」および「やり直し」 オプションを使用して、変更が永続的になることを心配せずに実験できます。分析内で最大 200 のアクションを元に戻したり、やり直したりすることができ、ツールバーのアイコン（次のスクリーンショットを参照）を使用してアクセスできます。 ダッシュボードの公開とバージョン履歴 分析がダッシュボードとして公開されると、QuickSight は自動的に新しいバージョンを作成します。ダッシュボードの所有者は、 バージョン履歴 を表示することでこれらのバージョンを管理できます。そのためには、ダッシュボードを開き、上部ツールバーのバージョン履歴アイコンを選択します（次のスクリーンショットを参照）。 これにより、現在公開されているバージョンと、タイムスタンプや各バージョンを公開したユーザーを含むすべての以前のバージョンのリストが表示されるペインが開きます。そこから、必要に応じて以前に公開されたバージョンを確認、比較、復元できます。この機能は、ダッシュボードの変更履歴を明確に追跡でき、所有者はコンテンツがどのように変化してきたかを把握することができます。 間違いが発見されたり、以前のバージョンが好まれたりした場合、所有者はワンクリックでダッシュボードを以前のバージョンにロールバックできます。 このバージョン管理機能は、公開された各ダッシュボードの完全なスナップショットを保持することで、手動での再作業を削減します。他のバージョンへのアクセスを失うことなく以前のバージョンを復元でき、安定性を維持しながら迅速なイテレーション（反復）を可能にします。 UI ベースの並行作成とコラボレーション 次の図は、単一の QuickSight 開発アカウント内で複数の作成者が並行してコラボレーションする方法を示しています。共有フォルダ「QA Assets」は、再利用可能なコンテンツを一元管理する場所として機能し、作成者はダッシュボードを拡張したり、ビジュアルを再利用したり、バージョンを独立して管理したりできます。 この例では、３人の作成者が共有の開発ワークフローに貢献しています。 Ying は分析 1 を作成し、それをダッシュボード 1 として公開し、チームのための再利用可能なアセットを確立します。 Julia は分析 2 を作成し、ダッシュボード 1 から選択したビジュアルをインポートします。これにより、既存の作業を基に構築しながら、独自のバージョンを維持できます。その後、ダッシュボード 2 を公開します。 Rushabh はダッシュボード 2 の「 名前を付けて保存 」オプションを使用して分析 3 を作成し、さらにカスタマイズしてダッシュボード 3 を公開します。Rushabh は、分析 3 を公開してダッシュボード 1 を置き換えることで、ダッシュボード 1 を更新することもできます。 このアプローチは 2 つの主要な利点をサポートします。 並行開発 – 各作成者は、共有アセットを参照しながら独立して作業します。これにより、上書きや競合の変更のリスクなしに、複数のダッシュボードや機能を同時に開発できます。 副次的な変更を伴わない安全な修正 – 本番のダッシュボードに迅速な修正が必要な場合、作成者は公開されたバージョンから開始し、ターゲットを絞った編集を行い、再公開することができます。これにより、開発中の元の分析にある未完成のビジュアルや実験的な変更を導入することがありません。 これらの機能を組み合わせることで、バージョンの追跡可能性が促進され、リスクが最小化され、大規模なコラボレーションが合理化されます。共有フォルダとモジュール式のワークフローにより、QuickSight はエンタープライズ BI チームにとって強力なプラットフォームとなります。 ダッシュボードを分析として保存 公開後、ダッシュボードはさらなる変更のために分析として 保存 できます。作成者は、次のスクリーンショットに示すように、「 名前を付けて保存 」オプション（フロッピーディスクアイコン）を使用して、利用中のダッシュボードから新しい分析を作成できます。 新しい分析は個人のリストに表示され、自由に編集できます。元のダッシュボードに影響を与えることなく、ビューをカスタマイズしたり、ビジュアルを試したりできます。 他の分析やダッシュボードからビジュアルをインポート QuickSight の ビジュアルのインポート機能 を使用すると、分析間でダッシュボードコンポーネントを効率的に再利用し、標準化できます。分析ツールバーから「ビジュアルのインポート」を選択し、共有または個人のアセットを参照して 1 つ以上のビジュアルをインポートします。クエリ、フォーマット、インタラクションを含むインポートされたビジュアルは、現在の分析にコピーされ、元のソースに影響を与えることなく独立してカスタマイズできます。この機能により、ダッシュボードの開発が合理化され、ビジュアルの一貫性が促進され、チーム間の重複が削減されます。 分析からダッシュボ​​ードを公開 QuickSight で 既存のダッシュボードを置き換える には、公開時に「既存のダッシュボードを置き換える」を選択します。これにより、セキュリティ設定や E メールレポートの設定に影響を与えることなく、ダッシュボードが新しい変更で更新されます。 ダッシュボードを分析として保存する、任意の分析からダッシュボードを公開する、他の分析やダッシュボードからビジュアルをインポートするなどの機能を組み合わせることで、BI チームは開発ワークフローにおいて強力な柔軟性を得ることができます。チームはダッシュボードを並行して開発でき、複数の作成者が異なる機能やビジュアルに独立して取り組むことができます。また、元の分析にある進行中または実験的なビジュアルを誤って本番バージョンに導入することなく、本番ダッシュボードの問題を安全に修正することもできます。このモジュール式で管理されたアプローチは、本番環境での安定性を維持しながら、アジャイルなイテレーション（反復）をサポートします。 ダッシュボードを壊さずにデータセットを置き換える QuickSight のフィールドタイプは、ビジュアル、フィルター、計算がどのように機能するかを決定します。データセットのスキーマ変更が分析の要件と競合すると、ダッシュボードの障害が発生する可能性があります。次のスクリーンショットは、フィルターとビジュアライゼーションのキーフィールドとして SaleDate を使用して構築された、映画チケット販売ダッシュボードの例です。 データセットが更新されました。この更新中に、 SaleDate は Date（日付）フィールドから Integer（整数）に変更されました。 再公開後、ダッシュボードは SaleDate に関連付けられたビジュアルを読み込むことに失敗しました。影響を受けた各ビジュアルには、「データセットが変更されすぎたため、QuickSight が分析を自動的に更新できませんでした」というメッセージが表示されました。 円グラフのレンダリングが停止し、時間比較のビジュアルが失敗し、 SalesDate のフィルターコントロールが機能しなくなりました。 すでにダッシュボードを動かしているデータセットのスキーマを更新する際、データ型の不一致（フィールドを Date から Integer や String に変更するなど）は、ビジュアルが破損する一般的な原因です。 スキーマの変更が意図的な場合は、次のことを行う必要があります。 影響を受けるフィルターを再作成する 新しいデータ型を認識するようにビジュアルを更新する スキーマの変更が意図的でない場合は、次のことができます。 不要な変更が含まれていない以前のデータセットバージョンに戻す QuickSight でデータセットを置き換える際、フィールドマッピングの不一致によるビジュアルの破損も一般的なリスクです。これを軽減するために、QuickSight は現在、次のアクションを実行します。 不一致が検出された場合にフィールドマッピングを更新するようユーザーに自動的に促す スキーマの類似性に基づいてフィールドを自動的にマッピングしようと試みる スキーマが完全に一致しない場合にレビューのための不一致ダイアログを表示する 一致しない、または不整合なフィールドは手動で調整する必要があります。QuickSight は検出された不一致に対してマッピングを強制しますが、ユーザーが提供したマッピングの正確性を検証しません。スキップされたり不適切なマッピングは、依然としてビジュアルの破損を引き起こします。正しいフィールドマッピングにより、ビジュアルが新しいデータセットで期待通りにレンダリングされることが保証されます。 まとめ 新しい QuickSight コンソール機能により、ダッシュボードとデータセットのライフサイクルをコードフリーで管理できます。チームは、バージョン管理、ロールバック機能、並行開発、ビジュアルの再利用を活用して、より安全で効率的なワークフローを作成できます。 自動化、CI/CD 統合、またはプログラムによるガバナンスを必要とするチームのために、このシリーズの パート 2 と パート 3 では、API ベースの BIOps ワークフローについて説明します。 著者について Ying Wang は、AWS のジェネレーティブ AI 組織に所属するシニアスペシャリストソリューションアーキテクトで、Amazon QuickSight と Amazon Q を専門とし、大企業や ISV のお客様をサポートしています。彼女はデータアナリティクスとデータサイエンスで 16 年の経験を持ち、データアーキテクトおよびソフトウェア開発エンジニアリングマネージャーとしての強力なバックグラウンドを持っています。データアーキテクトとして、Ying は顧客がクラウドでエンタープライズデータアーキテクチャソリューションを設計し、スケールするのを支援しました。エンジニアリングマネージャーとしての役割では、新機能を提供し、エンジニアリングと製品の両方の観点から製品イノベーションを推進することで、顧客が QuickSight を通じてデータの力を解き放つことを可能にしました。 Julia Flash は、AWS のジェネレーティブ AI 組織に所属するシニアビジネスディベロップメントスペシャリストで、北米のエンタープライズセグメント向けのQuickSightエンゲージメントをリードしています。AI、コーディング、製品戦略で 12 年の経験を持ち、エンジニア、テクニカルプロダクトマネージャー、特許を持つイノベーターとしての深いバックグラウンドを持っています。Julia は AI ソリューションの設計と開発、オープンソースのデータサイエンスへの貢献、そして影響力の大きい顧客対応のエンゲージメントを提供してきました。今日、彼女は引き続き顧客と協力し、QuickSight の大規模な採用を推進しています。

本ブログは 2025 年 4 月 24 日に公開された AWS Public Sector ブログ「 How AWS Wickr can enable secure communications for the Australian Government and its allies 」を翻訳したものです。 メッセージングアプリケーションは、オーストラリア人のコミュニケーション方法においてますます中核的な存在となっています。 オーストラリア通信メディア庁 (ACMA) の調査によると、オーストラリア人の約 5 人中 4 人が個人的な目的でメッセージングアプリケーションを使用していることが分かりました。これらのアプリは特に若いオーストラリア人の間で普及しており、18～24 歳の 92%、25～34 歳の 89% がつながりや交流のためにこれらのアプリを使用していると報告されています。 また、 Australian Public Service (APS) Workforce Strategy 2025 (オーストラリア公共サービス人材戦略 2025) では、2025 年までに APS の労働力の半分がデジタルネイティブである Y 世代と Z 世代で構成されるようになることが認識されています。このように変わりゆく労働力構成を考慮すると、友人や家族とのチャットに使用するアプリと同じようなツールが職場でのコミュニケーションにおいても求められるようになることは自然な流れのように考えられます。 しかし、一般消費者向けのメッセージングアプリケーションの使用は、オーストラリア政府機関にとって重大なセキュリティと主権のリスクをもたらし、政府の情報管理義務を満たすことを困難にしています。 Official guidance from the National Archives of Australia (NAA: オーストラリア国立公文書館) の公式ガイダンスでは、「オーストラリア政府業務の一環として作成または受信されたインスタントメッセージの投稿は連邦記録である」と明確に述べられています。 Australian National Audit Office (ANAO: オーストラリア会計検査院) は、 国防省 のハンター級フリゲート艦プロジェクトの管理に関する業績監査報告書において、プロジェクトの記録管理の弱点を指摘し、特に国防省職員によるコンシューマーメッセージングアプリケーションの使用について「Signal、Zoom、WhatsApp などのアプリケーションは、公式情報の送信や保存に使用することはできない」と 具体的に言及 しています。 セキュアでコンプライアントなメッセージング Amazon Web Services (AWS) Wickr は、エンドツーエンド暗号化メッセージングおよびコラボレーションサービスであり、政府機関が機密情報を保護し、 Australia’s Archives Act 1983 (オーストラリアの公文書館法) などの法的要件を満たすために必要な高度なセキュリティ、管理制御、およびデータ保持機能を提供します。 Wickr は、1 対 1 およびグループメッセージング、音声・ビデオ通話、ファイル共有、画面共有、位置情報共有を 256 ビット暗号化で保護します。データは、あるエンドポイントから別のエンドポイントへ移動する際に、不正アクセス、傍受、改ざんから保護されます。コンテンツの復号化に必要なキーにアクセスできるのは、意図された受信者のみであり、AWS でさえアクセスできません。Wickr は 2023 年 10 月に AWS シドニーリージョン で開始されました。 きめ細かい管理制御により、ユーザーをセキュリティグループに編成し、そのレベルでの機能やコンテンツへのアクセスを制限できます。Wickr ネットワーク管理者は、望ましい結果を達成するためにカスタマイズされたポリシーを各グループに適用できます。パスワードのリセットやプロファイルのリモート削除が可能で、紛失または盗難されたデバイスに起因するデータ漏洩のリスクを軽減できます。 Wickr ネットワーク管理者は、Wickr ネットワーク内の内部および外部コミュニケーションにデータ保持を設定および適用できます。これには、ゲストユーザー、外部チーム、その他のパートナーネットワークとの会話が含まれるため、組織との間で送受信されるメッセージやファイルを、完全にお客様の管理下にあるプライベートデータストアに保持でき、オーストラリア政府の記録管理義務への準拠をサポートします。 Wickr は、 Information Security Registered Assessors Program (IRAP: 情報セキュリティ登録評価者プログラム) プロセスに基づき、 独立した評価者による監査を受け 、 Information Security Manual PROTECTED (ISM: 情報セキュリティマニュアル準拠) レベルの要件を満たしていることを認定されました。この認定により、各省庁は、Wickr の使用に関して、情報管理および記録保持の要件に加えて、PROTECTED セキュリティ分類までの情報の取り扱いに関する要件を満たすことができます。 Wickr は、ユーザーやチームが他の組織の Wickr ネットワーク内のユーザーとセキュアに通信できるよう、ネットワークフェデレーションを提供します。ユーザーグループを特定のフェデレーションルールに割り当て、選択した機関やパートナーへのアクセスを制限し、個々のセキュリティグループに対してゲストユーザーアクセス機能を許可または無効にできます。 Wickr は現在、アジアパシフィック (シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、ロンドン)、および米国の米国東部 (バージニア北部) リージョンの AWS リージョンで利用可能であり、2024 年には追加のリージョンが開始される予定です。これにより、確立された同盟国・同志国、新興パートナーとのセキュアなコラボレーションを迅速かつ簡単に設定できます。例えば、次の図に示すように、オーストラリア政府機関は、英国、米国、日本政府の対応機関と Wickr ネットワークフェデレーションを設定できます。 図 1. AWS シドニー、ロンドン、東京、バージニア北部リージョン間の Wickr フェデレーション コミュニケーションを保護する 従業員は今後も、友人や家族とのチャットや職場での生産性向上のためにメッセージングアプリを使い続けるでしょう。これらのアプリの多くは政府機関にリスクをもたらしますが、Wickr はエンドツーエンド暗号化と管理制御、データ保持、データレジデンシー制御を組み合わせることで、お客様の目標達成と、内部およびオーストラリアの主要セキュリティパートナーとの安全なコミュニケーションを支援します。 詳細については、 AWS Wickr のウェブページ をご覧になるか、 メール にてお問い合わせください。 著者について Andrew McBride Andrew は オーストラリアのキャンベラを拠点に、国家安全保障・防衛 (NSD) セクターのお客様を担当する AWS のシニアソリューションアーキテクトです。Andrew は 20 年以上の経験を持ち、実践的なアナリストやソフトウェア開発者から戦略的計画まで幅広く携わってきました。オーストラリア国立大学の National Security College にて国家安全保障政策の修士号を取得しています。 このブログは WWPS Proposal Writer 中村昌幸が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025 年 10 月 6 日(月) に 「 Trainium x モデル開発最前線！ – カラクリ、Upstage、AWS 3社合同セミナー 」というイベントが開催されます。普段 AI を利用されている方は多くいると思いますが、LLM 開発をするといった機会はそう多くないと思います。本セミナーでは、AWS が最新世代の AI 学習チップ「Trainium2」の技術アップデートと性能優位性から始まり、Upstage 社の先進的な AI Solution と Karakuri 社と開発した最新版の LLM 詳細、そして Trainium でコスト効率良く学習させた技術ノウハウがお聞きいただけます。これからのAI時代に先駆け、AI 導入を具体的に検討している企業の方にとって技術選定の判断材料などの知識を得られる機会となります。ぜひご登録ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年9月22日週の主要なアップデート 9/22(月) Amazon Connect フローデザイナーでアナリティクスモードをサポート開始 Amazon Connect のフローデザイナーで新しい分析モードが利用可能になりました。この機能により、顧客が IVR や自動応答システムのどこでエラーになったり離脱したりするかを可視化できます。例えば会話型AIのやり取りがエージェントキューへの転送につながった回数や、フロー設定のエラーによって顧客が間違ったキューに振り分けられた回数を確認することができます。これまでフローの問題点を特定するのは困難でしたが、データに基づいて改善点を見つけられるため、より良い顧客体験を提供できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect Contact Lens が 5つの追加言語で機密データ編集機能を提供開始 Amazon Connect Contact Lens で機密データの自動編集機能が ５つの言語 (フランス語、ポルトガル語、イタリア語、ドイツ語、スペイン語) に対応しました。これまで英語のみだった個人情報やクレジットカード番号などの自動マスキング機能が多言語で利用できるようになり、グローバル企業のコールセンターでも顧客プライバシーを効率的に保護できます。詳細は こちらの公式ページをご参照ください。 9/23(火) Amazon EC2 R8gb インスタンスが一般提供 Amazon EC2 R8gb インスタンスが一般提供されました。AWS Graviton4 プロセッサを搭載し、従来の Graviton3 と比較して最大 30% のコンピューティング性能向上を実現します。最大 150 Gbps の EBS 帯域幅により、高性能データベースや NoSQL データベースのワークロードで優れたパフォーマンスを発揮できます。最大 768 GiB のメモリと 200 Gbps のネットワーク帯域幅を提供し、大規模なアプリケーションにも対応可能です。バージニア北部リージョンとオレゴンリージョンで利用できます。 Amazon RDS がリージョン間およびアカウント間スナップショットコピーを発表 Amazon RDS で、スナップショットの別リージョン・別アカウントへのコピーが 1 回の操作で実行できるようになりました。従来は 2 段階の操作が必要でしたが、今回のアップデートで中間スナップショットが不要となり、コスト削減と復旧時間の短縮を実現できます。ランサムウェア攻撃やリージョン障害時のデータ保護に特に有効で、カスタムスクリプトによる監視も不要になります。詳細は こちらのドキュメントをご参照ください。 AWS License Manager が AWS Managed Active Directory における複数アカウントの共有機能サポート開始 AWS License Manager で複数のAWSアカウント間でのAWS Managed Active Directoryの共有をサポートしました。これまで各 AWS アカウントごとに Active Directory を設定する必要がありましたが、複数アカウント間で一つの Directory を共有できるようになります。Microsoft Office や Visual Studio のライセンス管理を一元化でき、IT 運用の負荷軽減とコスト削減が期待できます。詳細は こちらのユーザーガイドをご参照ください。 9/24(水) Amazon EC2 Auto Scaling でインスタンスリフレッシュの強制キャンセルをサポート Amazon EC2 Auto Scaling で、インスタンスリフレッシュの強制キャンセル機能が追加されました。従来はインスタンスの起動や終了処理の完了を待つ必要がありましたが、今回のアップデートにより即座にキャンセルできるようになりました。アプリケーションデプロイでサービス障害が発生した際など、緊急時に素早く別のデプロイを開始できるため、システムの復旧時間を大幅に短縮できます。詳細は こちらのドキュメントをご参照ください。 AWS が EC2 I8g および I7i インスタンスで無制限のネットワークバースト期間を発表 AWS が EC2 I7i と I8g インスタンス (4xlarge より大きいサイズ) でネットワーク帯域幅のバースト時間制限を撤廃しました。従来はクレジット方式で一定時間のみ最大性能を発揮できましたが、今回のアップデートで常時安定した高速ネットワーク通信が可能になります。データベースやリアルタイム分析など、継続的な高スループットが必要なワークロードで予測可能なパフォーマンスを実現できます。 9/25(木) PostgreSQL 18.0 が Amazon RDS データベースプレビュー環境で利用可能に Amazon RDS for PostgreSQL 18.0 が プレビュー環境 で利用可能になりました。新機能として、マルチカラム B-tree インデックスの skip scan サポートや、並列 GIN インデックス構築、タイムスタンプベースの UUIDv7 サポートが追加されています。本番環境への導入前に、最新の PostgreSQL 機能を安全にテストできるため、アプリケーションの互換性確認やパフォーマンス検証に活用できます。プレビュー環境のインスタンスは最大 60 日間保持され、オハイオリージョンの料金体系が適用されます。詳細は こちらのドキュメントをご参照ください。 S3 コンソールで Amazon S3 Tables のプレビューが可能に Amazon S3 Tables を S3 コンソールから直接確認できるようになりました。これまで SQL クエリを書く必要がありましたが、今回のアップデートでテーブルのスキーマやサンプルデータをコンソール上で手軽に確認できます。データの構造や内容を素早く把握したい場面で特に便利で、セットアップも不要です。詳細は こちらのドキュメントをご参照ください。 AWS Network Firewall がアプリケーション層トラフィック制御を強化 AWS Network Firewall でアプリケーション層のトラフィック制御が強化されました。従来は複数のパケットに分割された TLS や HTTP 通信の監視が困難でしたが、新しいデフォルトルールにより複雑なカスタムルールを書かずに適切にセキュリティ制御できるようになります。現代の暗号化技術や大きな HTTP リクエストにも対応し、セキュリティチームの運用負荷を軽減しながら強固な保護を実現できます。詳細は こちらのドキュメントをご参照ください。 9/26(金) Amazon EBS が汎用 (gp3) ボリュームの最大サイズとプロビジョンドパフォーマンスを増加 Amazon EBS の汎用 SSD (gp3) ボリュームが大幅にパワーアップしました。容量は従来の 16 TiB から 64 TiB へ 4 倍に、IOPS は 16,000 から 80,000 へ 5 倍に、スループットは 1,000 MiB/s から 2,000 MiB/s へ 2 倍に拡張されています。これまで複数のボリュームを組み合わせて使っていた大容量アプリケーションも、単一の gp3 ボリュームで対応可能になり、運用がシンプルになります。コンテナ環境や単一ボリューム構成のアプリケーションに特に効果的です。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Db2 でリザーブドインスタンスの提供を開始 Amazon RDS for Db2 で Reserved Instances の提供が開始されました。On-Demand と比較して最大 47% のコスト削減が可能です。サイズフレキシビリティ機能により、同じインスタンスファミリー内であれば購入した Reserved Instance の割引が自動的に異なるサイズのインスタンスにも適用されます。例えば db.r7i.2xlarge の Reserved Instance を購入すると、2 つの db.r7i.xlarge インスタンスに割引が適用されるため、柔軟な運用とコスト最適化を両立できます。詳細は こちらのドキュメントをご参照ください。 AWS Clean Rooms が AWS Entity Resolution による増分 ID マッピングをサポート AWS Clean Rooms で AWS Entity Resolution を使った増分 ID マッピング処理がサポートされました。これまでは全データを処理する必要がありましたが、新規・変更・削除されたレコードのみを処理できるようになり、リアルタイムでのデータ同期が可能になります。測定事業者が広告主や出版社との共同分析において、オフライン購入データを常に最新状態で維持でき、キャンペーン効果の継続測定とコスト削減を同時に実現できます。 徐々に涼しくなったとはいえ、いきなり暑くなったりとまだまだ残暑は続きそうです。体調管理に気をつけてお過ごしください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 週末に屋外プールに行ったのですが暑かったり寒かったりと温度対策に苦戦しながらも季節の変わり目を感じました。 9 月 30 日 に「 Amazon Q Developer Meetup #3　生成AIの利用を中心としたソフトウェア開発の新しいアプローチであるAI-DLCおよびその活用実績のご紹介 」というイベントが開催されます。AI‑DLC (AI 駆動開発ライフサイクル) の概念と実際のインパクトをお伝えします。また実際の開発の中にその手法を取り入れた経験談もお客様事例としてご紹介いただきます。ぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、9 月 22 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「東京海上日動システムズ株式会社様の AWS 生成 AI 事例：金融業界初 AI-DLC Unicorn Gym による開発変革への挑戦」を公開 東京海上日動システムズ株式会社様が金融業界初となる AI-DLC Unicorn Gym を2025年8月に実施しました。本ブログでは、開発生産性の抜本的向上を目指す AI-DLC（AI-Driven Development Life Cycle）の取り組みについて紹介しています。AI-DLC（AI-Driven Development Life Cycle）は要件定義からリリースまでの開発プロセス全体に AI を組み込む手法で、従来2週間かかっていた1スプリントを1日や半日の「Bolt」という単位に圧縮する開発手法( 参考 )です。2日間のワークショップで実際に動作するシステムの初期版を4つのチームが完成させた成果をレポートしています。 ブログ記事「DeepSeek-V3.1 モデルが Amazon Bedrock で利用可能に」を公開 DeepSeek-V3.1 モデルが Amazon Bedrock でフルマネージド基盤モデルとして利用可能になりました。本ブログでは、思考モードと非思考モードを切り替えられるハイブリッドオープンウェイトモデルである点や、以前のバージョンのモデルと比較してツール使用とエージェントタスクにおいてパフォーマンスが改善された点を解説しています。また100超の言語サポートや具体的な使用開始手順も含めて紹介しています。 ブログ記事「Qwen モデルが Amazon Bedrock で利用可能に」を公開 Alibaba の Qwen3 モデル4種類 (Qwen3-Coder-480B-A35B-Instruct、Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507、Qwen3-32B) が Amazon Bedrock で利用可能になりました。本ブログでは、各モデルの特徴やユースケースの違い、エージェンティック機能・ハイブリッド思考モード・ロングコンテキスト処理などの新機能について詳しく説明しています。 ブログ記事「Amazon Bedrock における Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet に移行する」を公開 本ブログでは、Amazon Bedrock における Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet への移行方法を解説しています。Claude 4 Sonnet はコンテキストウィンドウが 1M トークンに拡張され、ネイティブ推論メカニズムや高度なツール使用機能を導入しています。API の変更点、プロンプトエンジニアリングの考慮事項、新しい拡張思考機能の戦略的活用方法など移行のポイントを紹介しています。 ブログ記事「Amazon Bedrock エージェントで SAP インスタンスを管理」を公開 本ブログでは、Amazon Bedrock Agentsを活用してSAPインスタンスの開始と停止、ヘルス状態とパラメータ値の確認などの基本的なSAP運用タスクの実行を支援する使用例を紹介しています。SAPControl Web サービスと連携する Lambda 関数の作成から Bedrock エージェントの設定まで、自然言語で SAP システムを操作できるソリューションの構築手順を解説しています。 ブログ記事「Amazon Q Developer for GitHub によるインタラクティブなコードレビュー体験の紹介」を公開 本ブログでは、Amazon Q Developer for GitHub に新たに追加された対話型コードレビュー機能について紹介しています。/q コマンドによるインタラクティブな質問機能、スレッド化された検出結果の要約表示、GitHub 内での変更適用など、コードレビューの効率化を実現する新機能を紹介しています。この新機能により、コードレビューの待ち時間が短縮が期待されます。 ブログ記事「Nova Act IDE 拡張機能で AI エージェント開発を加速」を公開 Nova Act IDE 拡張機能が発表され、Visual Studio Code、Cursor、Kiro などの IDE から直接ブラウザ自動化エージェントを構築できるようになりました。本ブログでは、自然言語でワークフローを記述してスクリプトを生成する機能、ノートブックスタイルのビルダーモード、統合されたブラウザテスト機能など、Nova Act 拡張機能の主要な特徴と使用方法を紹介しています。 サービスアップデート Amazon Nova Act 拡張機能: IDE 内で AI エージェントを構築・テスト Amazon Nova Act 拡張機能 が発表されました。Amazon Nova Act は、Webブラウザ上でアクションを実行するためのAIモデルです。本機能は、Visual Studio Code や Cursor などの IDE 内で Web ベースの自動化エージェント開発ができる拡張機能です。従来はコーディングとテスト環境の複数のツールを行き来する必要がありましたが、自然言語でのスクリプト作成からブラウザテストまでを 1 つの画面で完結できるようになりました。IDE の拡張機能マーケットプレイスから無償で利用可能です。詳細は こちらの Blog 記事 をご参照ください。 Amazon Bedrock AgentCore Runtime、Browser、Code Interpreter が VPC、AWS PrivateLink、CloudFormation、およびタグ付けのサポートを追加 Amazon Bedrock AgentCore の Runtime、Browser、Code Interpreter が VPC 接続、AWS PrivateLink、CloudFormation、タグ付けに対応しました。これまでインターネット経由でのアクセスが必要だった AI エージェントが、VPC 内のプライベートリソース (データベースや内部 API) に直接安全に接続できるようになります。CloudFormation によるインフラ自動化とタグ付けによるコスト管理も可能になり、エンタープライズ環境での AI エージェント運用がより実用的になりました。現在プレビュー版でバージニア北部、オレゴン、シドニー、フランクフルトリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本ブログは 2025 年 4 月 24 日に公開された AWS Public Sector ブログ「 AWS demonstrates resilient and secure edge-to-cloud at Department of Defense exercise 」を翻訳したものです。 米国国防総省 (DoD) は、任務の成功に不可欠な新規技術や新興技術の採用と統合において、民間企業への依存を高めています。現代の防衛環境は急速に進化しており、産業界との連携が成功の重要な要素となっています。 2025 年 3 月 6 日付けの覚書「 Directing Modern Software Acquisition to Maximize Lethality （戦闘効果を最大化するための現代的ソフトウェア調達の指示)」において、国防長官 Pete Hegseth 氏は、「国防総省は、ソフトウェア調達に関する既存の権限、契約戦略、およびプロセスの活用を最大化しなければならない。これにより、国防総省は民間技術の進歩に歩調を合わせるよう設計された体制に直ちに移行することが可能になる」と述べ、この考えを反映しています。 Amazon Web Services (AWS) は、軍事イノベーションの推進に向けたこの民間重視かつ協調的なアプローチを実現するという課題に取り組んでいます。最近では、AWS は Technology Readiness Experimentation (T-REX) シリーズのイベントへの参加を通じてこれを実現しました。 OUSD/R&E (研究工学担当国防次官室) が主催する T-REX イベントは、軍用技術の迅速なプロトタイピングと実験を行う場です。「競争は複雑で、状況に応じて変化し続けます。競合他社を上回るためには、未来を探る手段が必要です。新興のテクノロジーや機能が作戦遂行上もたらす価値を相対的に評価することで、実験的取り組みから意思決定のためのエビデンスが得られます。それらのエビデンスに基づき、特定のテクノロジーや機能について、さらなる研究が必要か、または、本格的な投資に値する段階に達していると判断することができます」と、OUSD/R&E のプロトタイピング・実験・評価担当ディレクターである An ‘Mike’ Tran 博士は述べています。これらのイベントにおいて、国防総省は防衛産業基盤 (DIB) ソリューションと軍事用途向け民間技術の評価を行います。 AWS のパートナーである General Dynamics Information Technology (GDIT) は、T-REX の直近 2 回の実施において、マルチドメインのクラウドコンピューティング機能を成功裏に実証しました。T-REX 24-2 は 2024 年 8 月 19 日から 28 日まで開催され、T-REX 25-1 は対無人航空システムの限定目標実験として 2025 年 3 月 6 日から 21 日まで実施されました。 AWS で米国国防総省のお客様をサポートする Tony Jacobs が Cloud Edge Global Access (CEGA) on AWS について説明し、演習の共通状況図 (COP) に提供するデータフィードと相互接続性を紹介。 国防総省が軍事利用に向けて AWS の民生技術を検証 AWS の DOD 担当チームは、AWS 上の Cloud Edge Global Access (CEGA) を使用して、タクティカルエッジから AWS GovCloud に接続する、回復力とセキュリティを備えたネットワークアクセスを提供しました。CEGA は、SD-WAN (Software-Defined Wide Area Networks) を使用した自動 PACE 通信ソリューションです (Primary [主]、Alternate [代替]、Contingency [予備]、Emergency [緊急] )。CEGA は AWS のグローバルバックボーンの力を活用し、AWS のお客様が活動するあらゆる場所でタクティカルネットワークにスピードと回復力をもたらします。 CEGA の使用は、指揮官のデータから意思決定までを加速するマルチドメインユーティリティを実証しました。チームは航空、地上、海上のデータを統合するタクティカルエッジノードを確立しました。これらのノードからのデータは共通状況図 (COP) に送信され、T-REX スタッフと参加者に包括的な指揮統制 (C2) 支援を提供しました。 Defense Operations Grid Mesh Accelerator (DOGMA) とは AWS と GDIT の合同ソリューションであり、GDIT の LunaAI 予測分析を Amazon Simple Storage Service (Amazon S3)、Amazon Kinesis、Amazon Athena、Amazon SageMaker、AWS Lambda、AWS Wickr など、複数の AWS サービスと統合します。これにより、任務の管理と実行のための堅牢でスケーラブル、かつセキュアな環境を提供します。DOGMA は、シームレスな通信、リアルタイムデータ処理、効率的なリソース管理を支援することで国防総省の目標に合致しています。 この高度な分析とクラウドサービスの統合により、DOGMA は任務成功に不可欠なリアルタイムの洞察と予測を提供することで、現代の軍事作戦における動的なニーズに対応できることが保証されます。DOGMA を使用して、AWS と GDIT は AWS クラウドとエッジの両方でドローン脅威の人工知能 (AI) 予測モデリングを実証しました。 図 1. AWS と GDIT のソリューション DOGMA のアーキテクチャ図。AWS 上の CEGA と GDIT の LunaAI を使用。ソリューションの主要な AWS コンポーネントには Amazon Kinesis、Amazon Athena、AWS Wickr が含まれる。 国防総省が取り組む次世代自律機能の実現に AWS が寄与 作戦の俊敏性と情報優位性が最重要となる時代において、クラウドイネーブルド自律システムは現在のニーズを満たすだけでなく、今後の戦域を予測し、形作っています。T-REX 24-2 と T-REX 25-1 において、AWS とそのパートナーは国防総省の任務における UAS の自律任務管理の未来も実証しました。 Tactical Edge Embodied AI Mesh (TEEAM) により、AWS は防衛産業パートナーである Gambit と協力し、AI が開発した行動パターンを使用した複数の無人航空システム (UAS) の一元的な運用管理を実証しました。これにより、UAS オペレーターは任務指揮官からの指示を受けて UAS 群をより効率的に制御できるようになりました。 GDIT との AWS の戦略的パートナーシップを活用し、AWS は DOGMA により T-REX 25-2 期間中に OUSD/R&E を支援しました。DOGMA は 16 の異なるデータソースを統合し、8 つのイベント会場にわたって状況認識と意思決定を向上させる統一された COP を提供しました。これは、インディアナ州の Camp Atterbury と Muscatatuck Urban Training Center の両方にある Task Force Research and Development Experimentation Reserve (TF RDER) 基地防衛作戦センターを直接支援しました。AWS タクティカルエッジノードは、AWS 上の CEGA とともに、回復力とセキュリティを備えたエッジからクラウドまでの接続性を提供し、複数の参加者が自律機能を成功裏に実証することを可能にしました。 T-REX イベントの一環として、OUSD/R&E の評価者は AWS と GDIT のソリューションの評価を実施しました。評価者は 3 つの重要な作戦上の課題、8 つの目標、15 の有効性指標に関するデータを収集しました。これらの評価は、イベントの数日間にわたって、複数のセンサータイプとネットワークパスで繰り返し実施されました。 AWS は、インフラ支援を提供することで TF RDER のリソースプロバイダーとしても機能しました。AWS は、T-REX 25-1 参加者のソリューション同士、他の参加者のソリューション、TF RDER COP、そしてより大きなイベントネットワークの一部としてインターネットと AWS クラウドを接続するバックホール接続を提供しました。 「TREX において他の企業が自社の機能を実証できるよう、回復力のあるネットワークバックボーンを提供してくれた AWS に感謝したいと思います。T-REX を会場として活用することで、これらのイノベーションを関連性のある作戦環境でテストし、各社のコラボレーションを通じて作戦即応性を向上させることができます」と、Principal Deputy Assistant Secretary of Defense for Mission Capabilities (任務能力担当国防次官補首席代理) の Marcia Holmes 氏は付け加えました。 まとめ 防衛に関連するお客様向けに、AWS の商用クラウド技術に基づく商用アプリケーションを提供することは、国防の近代化に向けた重要な一歩を表しています。AI と自律システムを組み合わせ、AWS と GDIT は国防総省の任務指揮官の状況認識能力を強化するとともに、国家安全保障における官民パートナーシップの新たな基準を設定しています。 防衛に関連するお客様と共に、AWS が戦域をどのように再形成しているかについて、今後の情報にご注目ください。タクティカルエッジまたは AWS クラウドによるミッションのイノベーション施策を通じて、AWS はパブリックセクターに変革をもたらしています。国防の近代化における AWS の役割についての詳細は、AWS のウェブサイト「 Cloud Computing for U.S. Defense 」および「 Tactical Edge 」をご覧ください (英語コンテンツ)。 著者について Dwayne Dickens Dwayne Dickens は AWS のシニアテクニカルデリバリーマネージャーで、軍事および技術分野で 30 年以上のリーダーシップ経験を持っています。米国国防総省のアカウントを専門とし、クラウド導入と戦略的成果を推進し、大幅な収益成長に貢献しています。Dwayne は大規模プロジェクトの管理において実績があり、特にサイバーセキュリティ、衛星通信、IT 管理の分野で経験を積んでいます。Army War College で修士号を取得しています。 Graham Boone Graham Boone は AWS のソリューションアクセラレーションエンジニアです。通信情報分野での経験を持つ米国空軍の退役軍人で、Park University で学士号を取得しています。AWS では、エッジデモンストレーションを可能にするハードウェアプラットフォームとネットワークインフラストラクチャの設計、構築、サポートを行っています。ハイブリッドデプロイメントについてお客様にアドバイスを提供し、接続性や環境条件を問わず間断なく動作するミッションクリティカルなワークロードの実現に貢献しています。 John DeRosa John DeRosa は AWS のプリンシパル、プロダクトマネージャー（テクニカル）です。Amazon 入社前は、国防総省で文民職員、将校、兵士として 30 年間勤務し、統合軍、陸軍、特殊作戦司令部で戦略担当者を務めました。イラクおよびバルカン作戦の陸軍退役軍人で、George Mason University で博士号を取得し、National War College を卒業しています。 Tony Jacobs Tony Jacobs は AWS のソリューションアクセラレーションマネージャーです。タクティカルエッジでの運用を専門とするチームを率い、通信、コンピュート、統合の課題を解決しています。指揮統制システムでの経験により、パートナーが適切なデータ処理レベルで、サイズ、重量、電力の制約内で航空、水上、地上、宇宙システムを統合できるよう支援しています。機密システム、メッシュネットワーキング、軍用データリンク製品、レーダー解析、可視化のための商用ソリューション開発において、技術リーダーとして 25 年の経験を持っています。 このブログは WWPS Proposal Writer 中村昌幸が翻訳しました。

未来の人流シミュレーションサービスへの取組 序章 こんにちは。ソリューションアーキテクトの齋藤と松本です。株式会社 GEOTRA (以下、GEOTRA) では、“データの力で、社会を前に進める” を、ミッションとして掲げて、機械学習を活用し、各データから未来の人流シミュレーションサービスを提供しています。人流シミュレーションサービスは、モデル要件定義→データ選定→データクレンジング→モデル構築→モデル精度検証 まで内製で開発しています。本ブログでは、GEOTRA 執行役員 CTO プロダクト開発部長 森山 拓洋 氏 に寄稿いただき、GEOTRA がどのように、人流シミュレーションサービスを開発してきたのかを紹介します。 人流シミュレーションサービスについて AWS : 人流シミュレーションサービスとはどのようなユースケースで活用するか教えてください。 GEOTRA 森山 : 幅広い人流シミュレーションに対応することができます。一つ例をあげると、橋梁・道路新設や車線規制等の通行止めを行った場合の交通流の変化について人流シミュレーションが可能です。 これにより、土木計画の精度を向上し、より精緻な計画に繋がります。 AWS : 人流シミュレーションサービス の開発について教えてください。 GEOTRA 森山 : 人流シミュレーションサービスには、GPS 位置情報から、ひとりひとりの移動がわかる「非集計トリップデータ」を作成する必要があります。「非集計トリップデータ」作成には自社で開発したアルゴリズムを用いています。数人の情報なら問題ないのですが、政令指定都市だと 100万人以上のデータを作成する必要があり、この時の計算量は膨大になりデータ作成に時間がかかります。ここの課題として位置情報は個人情報になり、個人を特定することにも繋がりえません。そうした事態を避けるために、合成データ作成技術を活用することで、プライバシー保護と個表データの作成を両立することが可能です。 AWS : どのようなお客様が、 人流シミュレーションサービス を使用していますか？ GEOTRA 森山 : 大手デベロッパー様、ゼネコン様、建設会社様をはじめ多種多様な業界の方にご利用いただいています。 アーキテクチャ について AWS : 人流シミュレーションサービス のアーキテクチャについても紹介していただけますか? GEOTRA 森山 : アーキテクチャは下記の通りです。 GEOTRA 森山 : 人流シミュレーションサービス は、AWS のフルマネージド型のサービスを中心としたアーキテクチャで構成されています。弊社で C++ と Python で開発した独自アルゴリズムが実装されたコンテナイメージを、Amazon ECR に保管しています。それを用いて「非集計トリップデータ」を作成します。このときにETL処理が必要で以前は自前でワークフローを EC2 で実装していましたが、AWS Step Functions に移行しました。作成された「非集計トリップデータ」は、Amazon RDS に書き込まれます。顧客はReact で作成されたアプリケーションから人流データを確認することが出来ます。 Why AWS? AWS : 人流シミュレーションサービス に、AWS が採用された理由を教えてください。 GEOTRA 森山 : 大きく 3つ理由があります。1つめは CPU アーキテクチャの選択肢です。本システムを開発時に X86 アーキテクチャと ARM アーキテクチャの両方を提供しているのは AWS だけでした。独自アルゴリズムを試行錯誤しながら開発する中で CPU アーキテクチャの選択肢があることは重要でした。2つめは市場でのエンジニアの数と情報量です。AWS コミュニティは活発で、最新情報や技術ブログなどが豊富で実践的な知見を得ることができました。3つめはサーバレスサービスです。秘匿性の高い GPS からの位置情報で「非集計トリップデータ」を作成する関係上、セキュリティは最重要です。AWS のフルマネージド型 サービスを採用することで OS やミドルウェアの運用保守を AWS にオフロードし開発に集中することが可能になりました。又、フルマネージド型 サービスの多くが採用している時間による従量課金でなく、実際の使用量に応じた従量課金であることもスタートアップで小さく始める事業で利用しやすかったです。 直面した課題と解決へのアプローチ C++とPythonで開発した独自アルゴリズムで「非集計トリップデータ」を作成しています。元々はEC2上で「非集計トリップデータ」作成とワークフローを、独自に実装していたのですがジョブの依存関係など複雑な部分がありメンテナンスに課題を抱えていました。これに対応するために、AWS Batch と AWS Step Functions を使用することで、 バッチの終了をAWS Step Functionsで検知することが可能です。ジョブの依存関係をGUIで確認し、途中のジョブからの再実行の時間などの機能により効率化へと繋がりました。 今後の展望について AWS : 今後の展望について教えてください GEOTRA 森山 : インフラの運用を簡素化するサーバレスサービスの種類の多さ、スケーラビリティの柔軟さといったAWS の特性を活かして人流シミュレーションサービスに関する試行錯誤を繰り返していきます。その中でビジネス効果があるものは、ブラッシュアップし、お客様が求めるプロダクトの開発に繋げていきます。最終的には位置情報×AIの領域でNo.1になることを目指しています！ 著者について 九州大学大学院理学府化学修了。大学では量子化学を学ぶ。人と人をつなげるITに興味を持ち、KDDIに2014年に新卒入社。入社後は法人向けの事業本部に所属し、DX関連のフロントSEとしてIoTを活用した法人向けソリューションや5Gネットワークと4K映像の画像認識を組み合わせたシステムの設計・構築に従事。 現在は技術責任者としてGEOTRAのプロダクト開発をリードし、自らも実装に従事する傍ら、データサイエンティストとしてGEOTRA Activity Dataを活用したデータ分析を推進。日夜お客様の新しいインサイトを模索している。

ワークフォースマネジメント (WFM) は、コンタクトセンターの成功に不可欠です。通話量に応じた適切な人員配置により、顧客の待機時間と運用コストを削減できます。効果的な WFM は、適切なスキルを持つ適切なエージェントが、顧客の問い合わせ量に対応するために常に利用可能な状態を実現できます。スケジューリングへの体系的なアプローチにより、エージェントの生産性と顧客満足度の両方が最大化できます。 Amazon Connect の機能である Amazon Connect の予測、キャパシティプランニング、スケジューリング は、過剰な人員配置を最小限に抑えながら、運用目標を達成するために必要な人数のエージェントを適切なタイミングで配置できるよう予測、計画、検証を支援します。AI を活用した機能により、コンタクトセンターの管理者は問い合わせ量と平均処理時間を高精度に予測し、最適な人員レベルを決定、エージェントのスケジュールを最適化し、スケジュールの順守状況を追跡することが容易になります。この機能はクリック一つで有効化でき、カスタムアプリケーションを構築したり、高価なサードパーティソリューションをコンタクトセンターに統合したりする必要はありません。これらの機能は、内部運用の最適化、サービス目標の達成、エージェントと顧客満足度の向上に役立ちます。 これらのメリットを念頭に置いて、コンタクトセンターが人員を最適化する方法を変革する Amazon Connect のゲームチェンジングな機能を探ってみましょう。 1. 就業アクティビティのカスタマイズ 就業アクティビティのカスタマイズは、Amazon Connect におけるワークフォース管理機能の強化を求める組織にとって重要な機能です。従来のアプローチではデフォルトの「仕事」アクティビティのみが提供されていましたが、現代のコンタクトセンターでは、さまざまなタイプのエージェント業務を分類およびスケジュールする、より細かい制御が必要です。このカスタマイズにより、組織は WFM を実際のビジネス運営により適合させ、運営効率を向上させることができます。 Amazon Connect では、エージェントスケジュール用の就業アクティビティの カスタムラベル がサポートされるようになり、エージェントがスケジュールされている業務のタイプを特定しやすくなりました。この機能のリリースにより、カスタムラベル付きのアクティビティを作成し、曜日ごとにエージェントスケジュールに割り当てることができます。この機能は、顧客対応および非顧客対応の両方のアクティビティにわたる複数のスケジューリングシナリオに対応します。例えば、エージェントが管理業務に従事している場合や、サードパーティアプリケーションで業務している場合、これらは生産的なアクティビティとしてラベル付けされますが、これらのアクティビティに費やされた時間は Connect での予測需要に関係しません。 例えば、月曜日の業務アクティビティとして「注文処理」を、火曜日には「返品管理」を、そして残りの週には「仕事」（既存のデフォルトアクティビティ）を割り当てることができます。これにより、マネージャーは誰がどのタイプの作業にスケジュールされているかを簡単に特定できるようになり、体験が簡素化されます。このリリースは、エージェントが自分の時間がどのように配分されているかを把握できるようになるため、エージェントの体験も向上させます。 図 1: シフトアクティビティでカスタマイズされた業務ラベルを作成できます。就業アクティビティオプションは、タイプ「生産的」のアクティビティでのみ利用可能です。 図2：シフトプロファイルでは、各日のデフォルトの活動を指定できます。デフォルトの活動として選択できるのは、就業アクティビティとして設定された活動のみです。 このカスタマイズ機能は、臨時のスタッフや契約社員を含む多様な雇用形態の従業員を管理する組織にとって特に価値があります。この機能により、企業はクリーンなデータ分離を維持しながら、カスタムラベルを使用して異なる就業活動を作成できます。これは正確な労働力分析にとって重要です。異なる活動に費やされた時間を正確に追跡することで、組織は予測された需要に合わせた正確なスケジューリングを維持しながら、労働力計画とリソース配分を改善できます。これにより、顧客対応業務と管理業務の両方で適切なカバレッジが確保され、生産的な時間と非生産的な時間の間に明確な可視性が生まれます。多様な作業ストリームとスケジュールを管理するこの包括的なアプローチは、カスタム作業活動が運用効率を向上させながら複雑なワークフォース管理シナリオにどのように対処できるかを実証しており、多様なスタッフィング体制と複雑なスケジューリングニーズに対処する現代のコンタクトセンターにとって不可欠なツールとなっています。 2. UI を通じた予測の編集 コンタクトセンターでは、顧客とのやり取りやサービス時間の予想される変動に合わせて、システムが生成した予測を調整する必要があることがよくあります。これらの変更は、サービス需要に影響を与える製品発売、マーケティング施策、または季節的なイベント中によく発生します。正確な予測を維持することは、運用パフォーマンスと顧客満足度の両方に直接影響し、不可欠です。 この機能以前は、予測担当者は手動で CSV テンプレートをダウンロードし、計算を実行し、データを入力し、完成したテンプレートを再アップロードする必要がありました。これは、異なるビジネスニーズを持つ複数の予測グループを管理するコンタクトセンターにとって特に負担となります。 新しい UI 経由での予測編集機能 は、いくつかの重要な方法でコンタクトセンターの運用を強化します。手動計算の時間とエラーを削減することで効率性を向上させ、同時に企業が変化するニーズに迅速に適応できるようにします。組織は、予想される顧客ボリュームにスタッフレベルをより適切に合わせることができ、顧客サービス向上のためのピーク時間中の適切なカバレッジを確保できます。 Amazon Connect では、UI を使用して予測を調整する 3 つの簡単な方法が提供されるようになりました。パーセンテージによる調整、数値の加算/減算、または特定の数値によるシステム生成予測の置き換えです。これは、ビジネス全体、特定のキュー、またはチャネル（電話やチャットなど）ごとに予測を微調整できるスマートリモコンを持っているようなものです。例えば、ホリデープロモーションを実行している場合、他の予測は変更せずに、セールス予測グループのみで予想されるチャットボリュームを 20% 迅速に増加させることができます。 図 3: UI による上書き設定画面の例 3. 繰り返しアクティビティ WFM スケジューラーは、Outlook や Google カレンダーで繰り返しミーティングを設定するのと同様に、エージェントスケジュール用の 繰り返しアクティビティ を作成できるようになりました。簡単な例で説明します。 100 名のエージェントがいるカスタマーサービスセンターのワークフォースのスケジューリングを担当する Sarah を想像してください。毎週月曜日の午前 9 時に、各チームリーダーとそのエージェントのために 30 分間のチームミーティングをスケジュールする必要があります。また、毎週水曜日の午後 2 時に、各エージェントとその上司との週次 1 対 1 コーチングセッションをスケジュールする必要もあります。 この機能が導入される前は、Sarah は毎週手動でこれらのミーティングを入力する必要がありました。100 名のエージェントに対して、これは毎週約 200 のカレンダーエントリを手動で作成することを意味し、約 2 時間かかる作業でした。また、ミスをしたり、一部のミーティングのスケジュール設定を忘れたりするリスクも高くなっていました。 この新しい繰り返しアクティビティ機能により、Sarah はこれらのミーティングを一度だけ設定し、「毎週繰り返し」としてマークできます。Amazon Connect が自動的に将来の週にミーティングを追加するため、設定にかかる時間は 15 分になりました。ミーティングは、彼女が変更を決定するまで、将来のすべてのスケジュールに自動的に表示されるようになります。 これは、自分のカレンダーで月次チームランチや週次ステータスミーティングを設定するのと似ています。一度設定すれば、将来のすべての日付に自動的に表示されます。このシンプルな自動化により、Sarah は月に約 8 時間の作業時間を節約でき、より重要なタスクに集中できるようになります。 図 4: 毎週月曜日の午前 9:00 から午前 10:00 まで繰り返される定期共有アクティビティの例 この機能の主要な機能は以下の通りです： 定期アクティビティを追加する際： 公開されたスケジュールに加えられた変更は即座に有効になります 下書きスケジュールに加えられた変更は、有効にするために再公開が必要です 定期アクティビティは、特定の日付で終了するか、無期限に継続するかを設定できます 無期限に繰り返すように設定されたアクティビティは、将来のすべてのスケジュールに自動的に表示されます 定期アクティビティの単一の回または全シリーズのいずれかを変更できます。変更は将来の回のアクティビティにのみ影響し、過去の回には影響しません Actions ログには定期アクティビティのスケジュールと例外が表示されます。このログで進捗を追跡でき、ステータスが「In Progress(進行中)」から「Complete(完了)」に変更されます 定期アクティビティを作成する際、「Override rules(ルールの上書き)」をチェックすると、労働時間制限などの制限をバイパスできます。チェックしない場合、ルールに違反するエージェントにはアクティビティが割り当てられません。どのエージェントが除外されたか、その理由を Actions ログで確認できます アクションを起こしましょう Amazon Connect の予測、キャパシティプランニング、スケジューリング と Amazon Connect 分析データレイク機能 について詳しく学びましょう。 Amazon Connect 管理者ガイド は Amazon Connect の使用開始に役立ちます。仮想コンタクトセンターのプロビジョニング、設定、監視、スケーリングの方法を学びましょう。 Amazon Connect Learning Plans and Badges で Amazon Connect の中核概念を学び、コミュニケーションスペシャリストおよび開発者としてのバッジを獲得しましょう。 ビジネス上の問題を解決するために使用できる実践的なスキル、技術、または概念を教えたり紹介したりするように設計された Amazon Connect のワークショップ で実践的に学びましょう。 RSS フィードを購読して Amazon Connect のリリースノート を受信しましょう。これからも有益でインスピレーションに満ちた Amazon Connect のブログ投稿( 英語 ・ 日本語 )にご期待ください。 リリースノート Amazon Connect now supports custom work labels for agent schedules Amazon Connect launches forecast editing UI Amazon Connect now supports recurring activities in agent schedules 筆者紹介 Vikas Prasad は、米国メリーランド州を拠点に Amazon Web Services で WWSO Applications を担当するスペシャリストソリューションアーキテクトです。余暇には旅行、サイクリング、トレッキング、読書、家族でのボードゲームを楽しんでいます。 Lakshay Mutreja は、カリフォルニア州を拠点とする AWS のソリューションアーキテクトで、Amazon Connect とコンタクトセンターソリューションを専門としています。イノベーションへの情熱を持つ彼は、お客様と協力してコンタクトセンター運営を変革し、優れたカスタマーエクスペリエンスを提供しています。Lakshay は、組織が Amazon Connect の機能を活用してビジネス目標を達成できるよう支援する一方で、カスタマーエンゲージメントと運用効率を向上させる最先端のアプローチを継続的に探求しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

ワークフォースマネジメント (WFM) は、コンタクトセンターの成功に不可欠です。人員のレベルを通話量のパターンに合わせることで、顧客の待機時間と運用コストを削減します。効果的な WFM により、適切なスキルを持つ適切なエージェントが、顧客の問い合わせ量に対応するために常に利用可能であることを実現できます。スケジューリングへの体系的なアプローチにより、エージェントの生産性と顧客満足度を最大限に高めることができます。 Amazon Connect の機能である Amazon Connect の予測、キャパシティプランニング、スケジューリング は、顧客が運用目標を最小限の人員で達成するために、適切な数のエージェントが適切な時間にスケジュールされるよう予測、配分、検証するのに役立ちます。AI を活用した機能により、コンタクトセンターの管理者は問い合わせ量と平均処理時間を高精度に予測し、理想的な人員のレベルを決定、エージェントのスケジュールを最適化し、スケジュールの順守状況を追跡することが容易になります。この機能はクリック一つで有効化でき、カスタムアプリケーションを構築したり、高価なサードパーティソリューションをコンタクトセンターに統合したりする必要はありません。これらの機能は、内部運用の最適化、サービス目標の達成、エージェントと顧客満足度の向上に役立ちます。 これらのメリットを念頭に置いて、コンタクトセンターが人員を最適化する方法を変革する Amazon Connect のゲームチェンジングな機能を探ってみましょう。 1. シフト交換の自動化によるスケジューリング強化 Amazon Connect では、エージェント同士がシフトを交換できるようになり、サービスレベルを損なわず、より柔軟なスケジュール管理が可能になりました。 シフト交換機能 により、エージェントはシームレスにシフトの交換を開始できます。 この機能を使用することで、コンタクトセンターのスーパーバイザーは、重要な決定については手動での確認を維持しながら、日常的な承認を自動化し、管理業務の負荷を軽減しながらも、管理基準を維持できます。例えば、スーパーバイザーは、日常的な顧客問い合わせなどの重要度の低いタスクを処理するエージェントの承認を自動化する一方で、医療情報、金融取引、エスカレートしている顧客苦情など、より配慮が必要な問題を扱うエージェントからのリクエストは手動承認を必要とすることができます。 スーパーバイザーが自動承認を設定する可能性があるシナリオをいくつか紹介します : 呼量が低い期間中の、同じスキルグループ内で同等の言語習熟度を持つエージェント間でのシフト交換 過去に高いパフォーマンスメトリクスを維持してきた事前承認済みエージェントの自動承認 同様の顧客対応評価を持つ Tier-1 カスタマーサポート担当者間での横方向の交換 手動承認が必要になる可能性があるシナリオをいくつか紹介します : 独自の製品知識を持つ専門技術サポートエージェントが関わるチーム間でのシフト交換 追加のコンプライアンス審査が必要な、高リスクな金融サービス担当者のシフト交換 重要な国際顧客セグメントをサポートする多言語エージェントが関わるシフト交換 例として、エージェントの John が金曜日のシフトを、火曜日のシフトを交換したい Paulo と交換したいというシナリオを考えてみましょう。John は、シフト交換機能を使用して、自分でシフト交換リクエストを簡単に作成できます。 2. 休暇の事前計画 Amazon Connect を使用するエージェントは、従来の 13 か月から拡張された、最大 24 か月前までの休暇のスケジューリングが可能になりました。スーパーバイザーは、13 か月から拡張された、最大 27 か月先までスケジューリンググループのグループ許可ウィンドウをアップロードできます。これらの拡張された期間により、エージェントは個人の時間をより適切に計画でき、スーパーバイザーは将来の人員計画をより効果的に管理できます。 スクリーンショットでは、2027 年 3 月 2 日のグループ許可がすでに設定されていることを示しています。午前 8 時から午前 10 時の間は休暇スロットが利用できませんが、午前 10 時以降はスロットが空いています。エージェントは、これらの利用可能なスロット情報を使用して、それに応じて休暇を計画し、システムによってリクエストが拒否されることを避けることができます。 3. Amazon Connect 分析データレイクを使用したスケジューリングデータの分析 Amazon Connect は、分析データレイクで公開された予測とスケジュールデータを提供し、このデータからレポートとインサイトを生成することを容易にします。分析データレイクのエージェント スケジュール データから、給与計算のための有給時間と無給時間のレポート生成、特定の期間に勤務予定のエージェント数と休暇を取るエージェント数の要約ビューの生成など、主要な運用ユースケースを自動化できるようになりました。また、過去 2 年間のすべてのエージェントのすべてのスケジュールされたイベントの詳細レポートの生成など、監査とコンプライアンスのユースケースにも対応できます。これらのレポートとインサイトを生成するには、Amazon Athena と Amazon QuickSight、または選択した他のビジネスインテリジェンスツールを使用できます。 以下はサンプルレポートの一部です。 エージェントアクティビティ監査レポート すべてのエージェントの公開されたスケジュール全体のシフト活動を統合して表示します。例えば、下記画像の囲った範囲では、エージェント user0100 の、2023年5月9日の午前 9 時から午後 5 時の間にあったアクティビティを示しています。 休暇レポート 休暇レポートには、各休暇申請の日付と時間数（実効休暇時間）、および各申請のステータスが含まれます。 これらのレポートの生成方法の例については、 ワークショップ の エージェントスケジューリング分析セクション を参照してください。 このデータは、Outlook や Google カレンダーと統合することもできます。また、エージェントの休暇を追跡するために、人事 (HR) ・給与システムと統合することも可能です。 4. Amazon Connect の新しい日次要員数予測によるスタッフィングの判断強化 コンタクトセンターの監督者として、正確な要員数の予測は最高の顧客体験を提供するために重要です。Amazon Connect は、現在、 キャパシティプランのダウンロード 機能により日次の要員数予測を提供しています。 以前は、キャパシティプランは週次および月次の要員数予測を提供していました。現在は、最大 64 週先までの日次の要員数要件にアクセスできます。このビューにより、季節的な変動を考慮し、日次レベルで異なる縮小率を適用しながら、何人のエージェントを採用するかなど、重要な要員配置と採用の判断が簡素化されます。 この拡張された可視性により、より高い精度で要員のニーズを確認できます。予想される業務量に合わせてチームを拡大または縮小するタイミングを特定し、適切な人員配置を確保するための採用、トレーニング、スケジューリングについて、十分な情報に基づいた判断を行えます。 このデータは、キャパシティプランをダウンロードした後の「Daily Metrics」シートで利用できます。 5. Amazon Connect でのエージェントの準拠率追跡のカスタマイズ グローバルなコンタクトセンターでは、コンタクトセンターの健全性を監視するリアルタイムアナリストが、リアルタイムダッシュボードを使用して、異なるサイトや拠点が準拠性メトリクスでどのようなパフォーマンスを示しているかを一目で把握します。 1 つ以上のサイトがアラーム状態（準拠から外れているエージェントが多すぎる）にある場合、担当エリアのスーパーバイザーに通知します。同様に、異なるレベル（地域、部門、チーム）のスーパーバイザーは、リアルタイムおよび履歴の両方で、組織の準拠性メトリクスを監視します。準拠率が低い場合、問い合わせを受けるために利用可能なエージェントの減少につながり、サービスレベルの低下、放棄率の増加、平均応答速度の増加など、主要なビジネスメトリクスに直接的な影響を与えます。どのエージェントが、そして何人のエージェントが準拠から外れているかを迅速に特定し、準拠率を改善するためのアクションを取る能力は、エンドカスタマーエクスペリエンスへの影響を最小限に抑えるために重要です。 8 時間のシフトで、エージェントがスケジュールの 80% の時間を準拠している例を考えてみましょう。つまり、 96 分間準拠から外れていました。このエージェントの準拠性を 85% に改善すると、このエージェントは 24 分間多く問い合わせを受けることができるようになります。これを 1,000 人のエージェントに適用すると、追加の人員配置を必要とせずに 1 日で 24,000 分多く（平均処理時間 12 分で 2,000 件の問い合わせ）問い合わせを処理できることになります。 Amazon Connect では、エージェントのスケジュール準拠を追跡する方法をより詳細にコントロールできる カスタマー定義の準拠性追跡機能 があります。エージェントがスケジュールを準拠していると見なされる状態を選択できるようになり、独自の運用ニーズにより適合させることができます。 このリリースにより、エージェントステータスとスケジュール活動の間のカスタムマッピングを定義できるようになりました。例えば、「Work」スケジュール活動は、「Available」や「Back-office work」など、複数のエージェントステータスにマッピングできます。これは、午前8時から午前10時まで「Work」がスケジュールされているエージェントが、その時間中に「Available」または「Back-office work」ステータスのいずれかにある場合、準拠していると見なされることを意味します。 さらに、リアルタイム準拠率ダッシュボードでは、単に「Productive」や「Non-productive」ではなく、スケジュールされた活動の実際の名前が表示されるようになりました。これにより、スーパーバイザーはエージェントの現在の活動とスケジュールを比較し、サービス目標を達成するためのアクションを取ることができます。 以下は、Lunch 活動にカスタムステータスを設定する方法を示す例です。準拠していると見なされるために、エージェントはスケジュールされた昼食時間中にステータスを「Lunch」に設定する必要があります。 この例では、スーパーバイザーはエージェントの準拠状況をリアルタイムで監視できます。エージェントの現在のアクティビティがスケジュールされたステータスと一致している場合（例：両方とも「Lunch」を表示）、エージェントは「準拠」とマークされます。現在のアクティビティがスケジュールと異なる場合（例：「Lunch」がスケジュールされているのに「対応可能」を表示）、「非準拠」とマークされます。 これらの新機能により、エージェントの準拠状況の監視において、より大きな柔軟性と精度が得られます。特定のビジネス要件により適合するよう準拠状況の追跡をカスタマイズできるようになり、コンタクトセンター運用に関するより正確で意味のある洞察が得られます。 アクションを起こしましょう Amazon Connect の予測、キャパシティプランニング、スケジューリング と Amazon Connect 分析データレイク機能 について詳しく学びましょう。 Amazon Connect 管理者ガイド は Amazon Connect の使用開始に役立ちます。仮想コンタクトセンターのプロビジョニング、設定、監視、スケーリングの方法を学びましょう。 Amazon Connect Learning Plans and Badges で Amazon Connect の中核概念を学び、コミュニケーションスペシャリストおよび開発者としてのバッジを獲得しましょう。 ビジネス上の問題を解決するために使用できる実践的なスキル、技術、または概念を教えたり紹介したりするように設計された Amazon Connect のワークショップ で実践的に学びましょう。 RSS フィードを購読して Amazon Connect のリリースノート を受信しましょう。これからも有益でインスピレーションに満ちた Amazon Connect のブログ投稿( 英語 ・ 日本語 )にご期待ください。 リリースノート https://aws.amazon.com/about-aws/whats-new/2025/02/amazon-connect-agents-exchange-shifts/ https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-connect-agent-time-off-scheduling-24-months-future/ https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-connect-agent-schedule-analytics-data-lake/ https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-connect-headcount-projections-plan-downloads/ https://aws.amazon.com/about-aws/whats-new/2025/02/amazon-connect-configuration-states-agent-schedule/ 筆者紹介 Vikas Prasad は、米国メリーランド州を拠点に Amazon Web Services で WWSO Applications を担当するスペシャリストソリューションアーキテクトです。余暇には旅行、サイクリング、トレッキング、読書、家族でのボードゲームを楽しんでいます。 Prabhakar Rajasekar は、ドイツのアーヘンを拠点に Amazon Web Services で WWSO Applications を担当するスペシャリストソリューションアーキテクトです。お客様のデジタルトランスフォーメーションを支援する以外では、庭や森で子供たちと時間を過ごしている姿を見ることができるでしょう。 Pavan Dusanapudi は、英国マンチェスターを拠点に Amazon Web Services で WWSO Applications を担当するスペシャリストソリューションアーキテクトです。カスタマーエクスペリエンスソリューションとデジタルトランスフォーメーションを通じて、お客様がビジネス成果を達成できるよう支援しています。余暇には、家族でのハイキング、CrossFit ワークアウト、そして心の平安を見つけることを楽しんでいます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

9 月 23 日は、皆さんに Nova Act 拡張機能 をご紹介したいと思います。この拡張機能は、IDE から離れずにブラウザ自動化エージェントを構築する過程を効率化するツールです。Nova Act 拡張機能は、 Visual Studio Code (VS Code) 、 Kiro 、 Cursor といった IDE に直接統合され、 Nova Act モデル で自然言語を使用してウェブベースの自動化エージェントを作成するために役立ちます。 Visual Studio Code の Nova Act 拡張機能を簡単に見てみましょう。 Nova Act 拡張機能は、ブラウザ自動化エージェント SDK (ソフトウェア開発キット) である Amazon Nova Act SDK (プレビュー) を基盤に構築されています。Nova Act 拡張機能は、コーディング環境とテスト環境間のコンテキストスイッチを不要にすることで、従来のワークフロー開発を変革します。自然言語ベースの生成、アトミックセルスタイルの編集、統合されたブラウザテストなどの特徴量を使用して、本番環境レベルのエージェントスクリプトの構築、カスタマイズ、テストのすべてを IDE 内で行えるようになります。この統一されたエクスペリエンスにより、フォームの入力、QA の自動化、検索、複雑なマルチステップワークフローといったタスクの開発速度が向上します。 Nova Act 拡張機能の使用は、ワークフローを自然言語で記述して最初のエージェントスクリプトをすばやく生成することで開始できます。スクリプトは、ノートブックスタイルのビルダーモードを使用してカスタマイズし、API、データソース、認証を統合してから、実環境状況をシミュレートするローカルテストツール (長期的なマルチステップワークフローのライブステップバイステップデバッグなど) で検証します。 Nova Act 拡張機能の使用を開始する まず、IDE の拡張機能マネージャーから Nova Act 拡張機能をインストールする必要があります。 私は Visual Studio Code を使っているので、 [拡張機能] を選択してから Nova Act と入力します。次に、この拡張機能を選択し、 [インストール] を選択します。 使用を開始するには、API キーを取得する必要があります。そのため、 Nova Act ページに移動して、手順に従って API キーを取得します。 Cmd+Shift+P / Ctrl+Shift+P を使用してコマンドパレットを開き、 [API キーを設定] を選択します。 API キーを入力したら、 ビルダーモード を試すことができます。このモードはノートブックスタイルのビルダーモードで、複雑な自動化スクリプトをモジュラーセルに分割するため、各ステップを個別にテストしてデバッグしてから次に進むことができます。 ここでは、 Nova Act SDK を使用してエージェントを構築できます。右側には、ブラウザ内でのエージェントのアクションをプレビューするための [ライブビュー] パネルと、モデルの思考やアクションを含めた実行ログを監視するための [出力] パネルがあります。 Nova Act 拡張機能をテストするため、 [すべてのセルを実行] を選択します。選択すると新しいブラウザインスタンスが起動し、与えられたプロンプトに基づいて動作します。 [フルスクリーン] を選択して、ブラウザの自動化がどのように機能するのかを確認します。 ビルダーモードのもう 1 つの便利な特徴量は、 [出力] パネルに移動してセルを選択し、そのログを表示できることです。これは、作業を行っているセルをデバッグしたり、セル固有のログを確認したりするために役立ちます。 テンプレートを選択して開始することもできます。 ビルダーモードの使用以外に、Nova Act とチャットしてスクリプトを作成することもできます。これを実行するには、拡張機能を選択し、 [Nova Act スクリプトを生成] を選択します。Nova Act 拡張機能が右側のパネルにチャットダイアログを開き、スクリプトを自動的に作成します。 スクリプトを作成し終えたら、 [ビルダーモードを開始] を選択できます。ビルダーモードでは、Nova Act 拡張機能が Python ファイルの作成を助けてくれます。チャット機能とビルダーモードを切り替えることができるため、シームレスな統合が実現します。 チャットインターフェイスでは、次の 3 つのワークフローモードを利用できます。 依頼: タスクを自然言語で説明して自動化スクリプトを生成 編集: 生成されたスクリプトを実行前に改良またはカスタマイズ エージェント: ワークフローを実行する AI エージェントを実行、監視、操作 コンテキスト を追加して、アクティブドキュメント、指示、問題に関する情報や、エージェントが使用できる追加のモデルコンテキストプロトコル (MCP) リソースを提供したり、現在のウィンドウのスクリーンショットを提供したりすることもできます。こうした情報を提供することで、エージェントが自動化タスクの特定の要件を理解できるようになります。 Nova Act 拡張機能は、チャットに / を入力することでアクセスできる一連の事前定義済みテンプレートも提供します。これらのテンプレートは事前定義された自動化シナリオで、一般的なウェブタスク用のスクリプトをすばやく生成するために設計されています。 これらのテンプレート ( @novaAct /shopping [my requirements] など) を使用して、ワークフローに合わせてカスタマイズされた Python スクリプトを作成できます。Nova Act 拡張機能は、リリース時点で次のテンプレートを提供しています。 /shopping : オンラインショッピングタスク (検索、比較、購入) を自動化 /extract : データ抽出を処理 /search : 検索と情報収集を実行 /qa : 品質保証とテストのワークフローを自動化 /formfilling : フォームとデータの入力タスクを実行 Nova Act 拡張機能をフルスタックのエージェントビルダーツール、つまり開発ライフサイクル全体の完全なエージェント IDE とすることによって、この拡張機能はエージェント開発ワークフローを変革してくれます。自然言語を使用したプロトタイプの作成、モジュラースクリプティングによるカスタマイズ、ローカルテストでの検証のすべてを IDE から離れることなく実行して、本番環境レベルのスクリプトを確保できます。 知っておくべきこと 留意事項は以下のとおりです。 サポート対象の IDE : リリース時点で Nova Act 拡張機能を利用できるのは、Visual Studio Code、Cursor、および Kiro ですが、さらなる IDE のサポートが予定されています。 オープンソース : Nova Act 拡張機能は Apache 2.0 ライセンスに基づいて提供されているため、コミュニティへの貢献やカスタマイズが可能です。 料金 : Nova Act 拡張機能は無料でご利用いただけます。 Nova Act 拡張機能は、IDE の拡張機能マーケットプレイスからインストールするか、 GitHub リポジトリ にアクセスしてドキュメントや例を入手することで使用を開始してください。 ハッピーオートメーション! – Donnie 原文は こちら です。

はじめに 以前、AWS は東京海上日動システムズ株式会社様（以下同社）との生成 AI を活用したアプリケーションモダナイゼーションの取り組みについて ブログで紹介 しました。この取り組みでは、Amazon Bedrock を活用し、レガシーな Java アプリケーションをサーバーレスアーキテクチャへモダナイズするプロセスを効率化する方法論の基礎を構築しました。現在同社では実際のプロジェクトへの適用が進められています。 同社では生成 AI の可能性を多角的に探求されており、アプリケーションモダナイゼーションと並行して、より根本的で緊急性の高い課題である「開発生産性の抜本的向上」にも取り組まれています。本ブログでは、この継続的な先進的取り組みの一環として2025年8月に実施された、金融業界初の AI-Driven Development Life Cycle (AI-DLC) Unicorn Gym について紹介いたします。 開発生産性向上への課題とこれまでの取り組み 同社では、これまでも開発生産性向上のために様々な取り組みを実施してきました。特に注目すべきは、設計書からソースコードを生成する「コード生成基盤」の構築です。この基盤は2年間の開発期間を経て本番環境で稼働しており、プログラミング工程において約 30% の外部委託費削減を実現しています。 これらの取り組みは着実な成果を上げている一方で、同社が目指すより大きな変革には、さらなる革新的なアプローチが必要でした。同社戦略企画部の山下様は、現在のIT業界では人材不足が深刻化しており、効率的な開発手法の確立が急務であると考えられています。現在同社は、ビジネス側である東京海上日動火災保険株式会社様が抱えるシステム的課題に対して開発体制が不足しており、すべての要望に応えきれていない状況にあります。コード生成基盤などの既存の取り組みによる生産性向上は 10～20% 程度となっていますが、この構造的な人材不足とシステム需要のギャップを埋めるためには、10倍、20倍といった抜本的な生産性向上が求められています。 山下様は、この課題を5年以内に段階的に解決していく考えであり、成果を出すためには今から取り組みを開始することが不可欠であるため、1日でも早く着手したいと考えられています。従来の延長線上での改善では、このギャップを埋めることは困難な状況でした。 AI-DLC：ゲームチェンジャーとしての 新しいアプローチ このような課題に対し、AWS は AI-DLC を提案しました。AI-DLC は、要件定義からリリースまでの開発プロセス全体に AI を深く組み込むことで、従来のアジャイル開発で2週間かかっていた1スプリントを、1日や半日の「Bolt」という単位に圧縮する開発手法です。AI-DLC の詳細については、 AI-DLC のホワイトペーパー と 日本語の解説ブログ をご覧ください。 同社は、AI-DLC について、単なるコード生成やテスト自動化といった部分的な改善ではなく、要件定義からリリース、運用まで全工程を AI で支援するコンセプトであり、まさにゲームチェンジャーになり得ると評価されました。 お客様にAI-DLCの導入を検討いただくにあたり、AWS は「AI-DLC Unicorn Gym」というワークショップ型プログラムを提案しました。これは、AI-DLC を組織の特徴やニーズに合わせてカスタマイズし、実際のプロダクト開発を通じてその効果を検証するプログラムです。2025年8月26日と27日の2日間にわたり、金融業界初となる AI-DLC Unicorn Gym が同社向けに実施されました。 AI-DLC Unicorn Gym の実施と成果 今回の AI-DLC Unicorn Gym では、同社から4つの異なるシステム・部署のチームが参加し、システム部門の他にビジネス部門である東京海上日動火災保険株式会社様、およびパートナーの担当者が協力して実際のプロダクト開発を通じて AI-DLC の効果を検証しました。プログラムは AWS プロトタイプ＆カスタマーエンジニアリング本部のシニアソリューションアーキテクト金森と福井によって実施され、各チームには AI-DLC に精通した AWS ソリューションアーキテクトがサポートとして配置されました。 1日半という短期間での開発にも関わらず、4つのチームが実際に動作するシステムの初期版を完成させ、1つのチームはテスト環境へのデプロイまで完了しました。従来であれば数週間から数ヶ月を要する開発作業が、AI-DLC により劇的に短縮されたことが確認されました。 ビジネス意図を詳細な要件、ストーリー、ユニットに変換するための「モブエラボレーション」と呼ばれる作業の様子。AI が出力した内容をビジネスサイドと開発者でレビューし、AI に修正指示を出している。 チーム名 対象システム 取り組み内容 参加者構成 期間 従来開発期間 基幹系システムチーム 基幹系システムの周辺Webシステム 既存システムの新規画面追加 ビジネス部門・システム部門・パートナー（計 10 名） 1.5日 2-3ヶ月 生成 AI プラットフォームチーム 社内情報検索システム 新規開発 システム部門（計 3 名） 1.5日 1ヶ月 マイグレーションチーム 社内 VBA ツール 既存VBA の Web アプリケーション化 システム部門・パートナー（計 4 名） 1.5日 1ヶ月 アジャイル開発チーム 社内生成AIアプリケーション 既存アプリの新規機能追加 ビジネス部門・システム部門（計 7 名） 1.5日 数週間 AI-DLC Unicorn Gym からの学び 各チームの成果発表会の様子 今回の AI-DLC Unicorn Gym を通じて、参加者の皆様から多くの貴重なフィードバックをいただきました。特に印象的だったのは、ビジネス部門の参加者から寄せられた現場判断の重要性に関する気づきです。 ビジネス部門の参加者からは、「AI を用いた開発速度の速さにより、画面 UI やモックアプリが早くできる。これにより開発途中から使用者である現場社員に確認できる。迅速な判断が可能になり、生産性と品質向上につながることを実感した」という声が聞かれました。微調整や要件修正が驚くほど早くできる AI-DLC の特性により、従来のような段階的な承認プロセスではなく、現場判断による迅速な開発サイクルの有効性が確認されました。 システム部門の参加者からは、環境制約などの技術的課題を早期に検出できることの価値が指摘されました。従来であれば1ヶ月ほどかけて概念実証を行った後に判明していた制約事項が、1.5日という短期間で発見できたことで、プロジェクトの手戻りリスクを大幅に削減できる可能性が示されました。 また、AI が高度な設計手法の知識を持っているため、これまで実案件への導入の難易度が高かった、ドメイン駆動設計のような高度な設計パターンもAIと協力することで、スムーズに導入でき、全体の品質向上につながることが確認できました。これにより、より多くの開発者が高品質なシステム設計に取り組めるようになる可能性が示唆されました。 今後の展望と組織変革への取り組み 今回の AI-DLC Unicorn Gym の成果を受け、同社では組織全体への展開に向けた具体的な検討を開始されています。同社の山下様からは下記のコメントをいただいております。 IT 業界の人材不足・コスト課題が深刻化する中、AWS が提唱する AI-DLC が真のゲームチェンジャーになると確信しています。今回の実証実験を通じて、開発プロセスの根本的変革の可能性を実感しました。 その一方で、AI 駆動開発については小規模な新規システムへの適用で良好な結果を得られましたが、既存システムの改修や大規模なシステムへの適用については、トークン数の制約などの技術的な検討事項があり、さらなる検証と最適化のアプローチを模索していく必要があると考えています。 そのため、こうした様々な検討事項を解消しながら組織全体での本格的な導入を進め、数年後には飛躍的な生産性向上と競争力強化を実現したいと考えています。 金融IT業界の新たな変革期において、AWS との協業を通じてこの革新的な取り組みを牽引し、業界全体の発展に貢献していきたいと考えています。 組織変革の観点では、ビジネス部門内でも現場の意見を取り入れやすくする仕組みにし、技術チームと現場社員の橋渡しを容易にする組織的な改善の必要性も示されました。これにより、AI-DLC の特性である迅速な開発サイクルを最大限に活用できる体制の構築を目指されています。 AI-DLC の組織的な導入には、技術的な知識向上だけでなく、組織のプロセスやマインド変革、人材育成の観点からの根本的な改善や継続的な改善が重要です。今回先進的な取り組みをされた同社のように、IT チームだけではなくビジネスサイドの協力、改革も必要となってきます。 まとめ 今回の AI-DLC Unicorn Gym を通じて、金融機関のシステム開発における AI-DLC の適用可能性が実証されました。基幹系システムから社内ツールまで、システム種別を問わず効果を発揮し、既存機能のカスタマイズと新規アプリケーション開発の両方に対応できることが確認されました。 今回の取り組みについて、アマゾンウェブサービスジャパン合同会社フィナンシャルインダストリー技術本部 本部長の布目拓也は「この AI-DLC は新しい取り組みとなっている。まだ AI-DLC も実験段階ではあるが、ここまで成果を出していただいて嬉しい。この成果をもとに、ビジネスサイドとシステムサイドが相互理解を深め、有機的に結びついて迅速に変革を起こしていく仕組みとしてご活用いただけることを期待しています。今後とも AWS は貴社の信頼されるパートナーとして、AI の効果的な使用方法などについて並走していきたい。」とコメントしています。 同社のような先進的な取り組みは、同様の課題を抱える他の金融機関にとっても重要な知見を提供しています。人材不足と急速に増加するシステム需要のギャップを埋めるためには、従来の延長線上での改善ではなく、AI-DLC のような抜本的なアプローチが解決の鍵となることが浮き彫りになりました—この変革のチャンスを掴むタイミングは、今この時ではないでしょうか。 AWS は今後も、お客様の継続的な変革を支援し、信頼されるパートナーとして並走してまいります。AI-DLC の更なる発展と普及を通じて、業界全体の開発生産性向上に貢献していきたいと考えています。 著者 菅原 太樹 (Taiki Sugawara) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト 2024年に新卒で入社した 2 年目 SA。主に保険業界のお客様を担当している。 技術の得意領域はサーバーレス。AWS Summit Japan 2025 のブレイクアウトセッションに日本史上最若手登壇を行う ( YouTube ) など、各種発表にも力を入れている。 X: @taikis_tech LinkedIn: https://www.linkedin.com/in/taikis/ 神部 洋介 (Yosuke Kambe) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト 2022 年に AWS に入社。前職は SIer で主に金融機関向けの基幹系システムやデータ分析基盤の開発に従事。現在は、保険会社のお客様を中心にデータ活用や生成 AI 活用をはじめとした様々な技術支援を行っている。

本記事は 2025 年 9 月 8 日に公開された “ Introducing an Interactive Code Review Experience with Amazon Q Developer in GitHub ” を翻訳したものです。 コードレビューはソフトウェア開発において最も価値ある工程の一つです。品質の確保、一貫性の維持、エンジニアとしての成長促進に役立ちます。しかし同時に、ソフトウェア開発ライフサイクルの中で最も時間を要する工程でもあります。 よく目の当たりにする事例として、開発者がプルリクエスト (PR) を開き、自動出力されたコメントや同僚からのコメントを確認した後、変更が提案された理由を理解するためだけに、ドキュメントや Slack のスレッド、過去のコードを検索しなければならないというものがあります。この不足しているコンテキストを探す作業は摩擦を生み、チームの開発速度を低下させ、やり取りの回数を増やし、優れた製品を構築するという重要な目的の障壁となります。 Amazon Q Developer for GitHub の初期プレビュー では、開発者は新機能開発や、自動化されたコードレビュー、一般的なモダナイゼーションタスクにおいて、 Amazon Q Developer を GitHub の Issue と PR にまたがって利用していました。これにより作業は GitHub 内で完結し、作業工数が削減されました。新規または再オープンされた PR に対する自動レビューは迅速に検出事項を提示しましたが、開発者は依然としてより多くのコンテキストと PR 内での緊密な連携を求めていました。 本日、PR 向けの対話型コードレビュー機能を導入します。 /q コマンドで Amazon Q Developer に検出結果に関する質問ができ、スレッド化された検出結果の簡潔な要約を確認し、GitHub を離れることなく提案された変更を適用できます。Amazon Q Developer によるコードレビューは以前より迅速に完了するため、待ち時間が短縮されレビューサイクルが短縮され、チームはより早くマージして開発に集中できます。 新機能とその意義 プルリクエスト内でのインタラクティブな会話 : /q でコメントするとインラインで回答を得られます。また、 Amazon Q Developer にコード変更を提案させ、PR 内で変更を適用できます。 コメント例: /q explain this finding or /q propose a change that replaces class toggles with a data attribute for state. ※訳者注: /q この変更検出の内容を説明 または /q 状態を示すクラスをデータ属性に切り替える変更を提案 スレッド化された検出結果付きコードレビュー要約 : 各コードレビューは簡潔な要約で始まり、変更の検出結果がスレッド形式で表示されます。これにより更新箇所の追跡が容易になり、作業の煩わしさが削減されます。 通知の明確化による高速化： Amazon Q Developer の分析が高速化されただけでなく、通知を整理して見やすくします。これにより待機時間が短縮され、レビューサイクルが短縮されます。新しい PR を作成する際、 Amazon Q Developer コンソール上で GitHub コードレビュー機能が有効になっている場合、自動的にコードレビューが開始されます。以降のコミットでは自動レビューはトリガーされません。新しい分析を実行するには、PR に対して /q review とコメントします。 Amazon Q Developer for GitHub の開始方法 Amazon Q Developer for GitHub を開始するには、GitHub の Organization、もしくはリポジトリに Amazon Q Developer for GitHub アプリをインストールします。このアプリは GitHub Marketplace から入手可能で、プレビュー期間中は AWS アカウントなしで利用できます。インストール時に GitHub の Organization 内のすべてのリポジトリへのアクセスを許可するか、選択したリポジトリのみに制限するかを選択します。Amazon Q Developer コンソールでアプリのインストールを登録すると、無料利用枠を増やすことができます。 インストール、権限、設定オプションの詳細については、 Amazon Q Developer for GitHub のドキュメント を参照してください。アプリのインストールが完了すると、自動的にAmazon Q Developer を使用して PR をレビューできるようになります。 プルリクエストにおけるAmazon Q Developer利用の流れ Amazon Q Developer で構築したシンプルなカードゲームを題材として、新しいインタラクティブなコードレビュー体験の流れをご紹介します。 PR の新規作成 : この例では、最初にフィーチャーブランチを作成し「demo」と命名しました。次に、JavaScript と HTML で構成されるカードゲームアプリに tailwind.css ファイルを追加し、ブランチをプッシュした後、レビュー用の PR を作成します。 Amazon Q Developerによるコードの自動レビュー : Amazon Q Developer がコードの品質、潜在的な問題、ベストプラクティスへの準拠状況を分析します。分析結果として簡潔な要約が最上部に表示され、変更の検知箇所が下部にスレッド形式で表示されました。これにより、全体像と詳細を 1 か所で把握できます。 要約と検知箇所を元にコードレビューを実施 : Amazon Q Developer が出力した要約と関連する調査結果を確認し、どの変更のレビューに最初に取り組むか判断します。変更の根拠と具体的な対象行が示されるため、ファイルをくまなく探す必要なく、対処すべき箇所が明確になっています。 /q で説明を求める : 変更の検知箇所の一つについて、カードゲームにおけるカードの状態を保持するために、プロパティを使用することが提案されました。そこで Amazon Q Developer に詳細を確認しました。具体的な文脈と指針を迅速に提供してくれたため、やり取りが削減され、レビューの質が向上しました。 (必要に応じて) 対話を続ける : Amazon Q Developer からの提案に対して、別のアプローチを希望すると返信したところ、Amazon Q Developer はすぐにこの PR に対して適用できる実装を応答してくれます。 修正を適用 : 実装提案を確認した後、「Commit suggestion」をクリックし、PR ブランチに新しいコミットを作成しました。この際、作成者のユーザー名は私になります。 レビューの再実行 : 今回は必要ありませんでしたが、追加の変更をプッシュした場合、新しいトップレベルコメントとして /q review を投稿することで、Amazon Q Developer によるレビューを再実行できます。Amazon Q Developer がレビューを実行し、新たに検出した変更内容をポストします。 最終的にコードレビューが完了し、問題ないことを確認したため、PR をマージしました。新しい対話型コードレビュー体験により、変更提案の背景にある「理由」が明確になり、待ち時間とレビューサイクルが短縮されました。 まとめ Amazon Q Developer for GitHub は現在プレビュー版として利用可能です。個人開発者でも大規模エンジニアリングチームの一員でも、このアップデートにより、少ないサイクルでクリーンなコードをデリバリできるようになり、コードレビューが面倒なものではなく楽しい工程になります。 ぜひ、次の PR で試してみてください。 /q と入力し、質問を投げかけ、 対話型のレビュー がワークフローをいかにスマートに変えるかを確認してみてください。 翻訳はソリューションアーキテクトの富永が担当しました。

本記事は、2025 年 8 月 8 日に公開された The Amazon SageMaker lakehouse architecture now automates optimization configuration of Apache Iceberg tables on Amazon S3 を翻訳したものです。翻訳は Solutions Architect の 松岡勝也 が担当しました。 組織が Amazon Web Services (AWS) 上のデータレイクアーキテクチャに Apache Iceberg テーブルを採用するようになるにつれ、これらのテーブルのメンテナンスが長期的な成功の鍵となります。適切なメンテナンスがないと、Iceberg テーブルはクエリパフォーマンスの低下、削除すべき古いデータの不要な保持、ストレージコスト効率の低下など、いくつかの課題に直面する可能性があります。これらの問題は、データレイクの効果とコスト効率に大きな影響を与える可能性があります。定期的なテーブルメンテナンス作業により、本番ワークロードの Iceberg テーブルの高いパフォーマンス、データ保持ポリシーの遵守、コスト効率を確保することができます。Iceberg テーブルを大規模に管理できるよう、 AWS Glue では以下の Iceberg テーブルメンテナンス作業を自動化しました： sort や z-order での コンパクション 、そして スナップショットの有効期限設定と孤立データの管理 です。この機能のリリース後、多くのお客様が運用負荷を軽減するために AWS Glue Data Catalog を通じて自動テーブル最適化を有効にしています。 Amazon SageMaker lakehouse アーキテクチャでは、カタログレベルの設定により、Amazon S3 に保存された Iceberg テーブルの最適化 が自動化されるようになり、Iceberg テーブルのストレージを最適化してクエリのパフォーマンスを向上させます。これまでは、AWS Glue Data Catalog の Iceberg テーブルを最適化するには、各テーブルの設定を個別に更新する必要がありました。現在は、Data Catalog の一度の設定で新しい Iceberg テーブルの自動最適化を有効にできます。有効化すると、新規テーブルまたは更新されたテーブルに対して、Data Catalog は小さなファイルの圧縮、スナップショットの削除、不要な参照されていないファイルの削除を行い、継続的にテーブルを最適化します。 このポストでは、カタログレベルのテーブル最適化設定を有効にするための一連のフローをご紹介します。 前提条件 新しいカタログレベルのテーブル最適化を使用するには、以下の前提条件が必要です: アクティブな AWS アカウント。 カタログレベルでテーブル最適化を設定するデータレイク管理者。データレイク管理者を作成するには、 AWS Lake Formation のセットアップ を参照してください。 Iceberg テーブルにアクセスするためのテーブル最適化用の AWS Identity and Access Management (IAM) ロール。手順については、 カタログレベルのテーブル最適化の前提条件 を参照してください。 カタログレベルでのテーブル最適化の有効化 データレイク管理者は、 AWS Lake Formation コンソールでカタログレベルのテーブル最適化を有効にできます。以下の手順を実行してください： AWS Lake Formation コンソールで、ナビゲーションペインの Catalogs を選択します。 カタログレベルのテーブル最適化を有効にするカタログを選択します。 次のスクリーンショットのように、 Table optimizations タブを選択し、 Table optimizations の Edit を選択します。 Optimization options で、次のスクリーンショットに示すように、 Compaction 、 Snapshot retention 、 Orphan file deletion を選択します。 IAM ロールを選択します。権限については テーブル最適化の前提条件 を参照してください。 Grant required permissions  を選択します。 I acknowledge that expired data will be deleted as part of the optimizers を選択します。 カタログレベルでテーブルの最適化を有効にすると、次のスクリーンショットのように、AWS Lake Formation コンソールに設定が表示されます。 カタログに登録された Iceberg テーブルを選択すると、次のスクリーンショットに示すように、 Configuration source に catalog と表示されることから、テーブルの最適化設定がテーブルビューから継承されていることを確認できます。 テーブルの最適化履歴は、テーブルビューに表示されます。 以下の結果は、テーブルの最適化によるコンパクション処理の 1 つを示しています。 すべてのデータベースと Iceberg テーブルに対するカタログレベルのテーブル最適化が有効になりました。 カタログレベルとテーブルレベルでのテーブル最適化設定のカスタマイズ カタログレベルの最適化は、カタログ内のすべてのデータベースと Iceberg テーブルに共通の設定を適用しますが、特定の Iceberg テーブルに対して異なる戦略を適用したい場合があります。 AWS Glue Data Catalog を使用して、特定のテーブルの特性とアクセスパターンに基づいて、カタログレベルとテーブルレベルの両方の最適化を有効にできます。 例えば、汎用的な Iceberg テーブル向けに binpack 戦略を使用したカタログレベルのコンパクション設定に加えて、タイムスタンプカラムに対する範囲クエリが頻繁に実行されるテーブルには、テーブルレベルでソート戦略を適用できます。 このセクションでは、実践的なシナリオを通じて、カタログレベルとテーブル固有の最適化の設定方法を説明します。 頻繁な書き込み操作が行われるリアルタイム分析テーブルを想像してください。このテーブルでは、メタデータの更新が頻繁に行われるため、より多くの孤立ファイルが生成されます。 また、ユーザーは特定のカラムをフィルタリングして一部のデータを対象とするクエリを実行するため、sort 戦略が望ましいものとなります。 以下のステップを実行してください： AWS Lake Formation コンソールでテーブルレベルの最適化を設定するために、先ほどと同じカタログ内の別の Iceberg テーブルを選択します。なお、このテーブルにはカタログレベルのテーブル最適化が設定されています。 次のスクリーンショットに示すように、 Optimization configuration で Edit を選択します。 Optimization options で、 Compaction 、 Snapshot retention 、 Orphan file deletion を選択します。 Optimization configuration で、 Customize settings を選択します。 同じ IAM ロールを選択します。 Compaction configuration で、次のスクリーンショットのように Sort を選択します。また、 Minimum input files に 80 ファイルを設定します。これはコンパクションをトリガーするファイル数の閾値です。 Sort を設定するには、Iceberg テーブルでソート順を定義する必要があります。ソート順は ALTER TABLE db.tbl WRITE ORDERED BY のような Spark SQL で定義できます。 Snapshot retention configuration と Snapshot deletion run rate で、 Specify a custom value in hours を選択します。次のスクリーンショットに示すように、2 つの削除ジョブの実行間隔を 12 時間に設定します。 Orphan file deletion configuration で、 Files under the provided Table Location with a creation time older than this number of days will be deleted if they are no longer referenced by the Apache Iceberg Table metadata を 1 日に設定します。これにより、作成日数がこの値より古いファイルが Apache Iceberg Tableのメタデータで参照されなくなると削除されます。 Grant required permissions を選択します。 I acknowledge that expired data will be deleted as part of the optimizers を選択します。 Save を選択します。 AWS Lake Formation コンソールの Table optimization タブに、テーブルオプティマイザーのカスタム設定が表示されます。 Compaction では、 Compaction strategy が sort に設定され、 Minimum input files は 80 files に設定されています。 Snapshot retention と Snapshot deletion run rate が 12 hours に設定されています。  Orphan file deletion では Orphan files will be deleted after が 1 days に設定されています。これらは以下のスクリーンショットに示されています。 以下のスクリーンショットに示すように、カタログレベルの戦略が binpack に設定されていても、コンパクション履歴ではテーブルレベルのコンパクション戦略として sort が表示されます。 このシナリオでは、カタログレベルの最適化と共にテーブルレベルの最適化が設定されています。 テーブルレベルとカタログレベルの最適化を組み合わせることで、Iceberg テーブルのデータ削除とコンパクション処理をより柔軟に管理できます。 まとめ この投稿では、AWS Glue Data Catalog のカタログレベルのテーブル最適化機能を使用して、Amazon SageMaker Lakehouse アーキテクチャで Iceberg テーブルを有効化し管理する方法を説明しました。 この機能強化により、単一の設定ですべてのテーブルに対して自動メンテナンス操作を有効にできるため、Iceberg テーブルの管理が大幅に簡素化されます。 個々のテーブルごとに最適化設定を構成する代わりに、データレイク全体をより効率的に維持できるようになり、運用オーバーヘッドを削減しながら一貫した最適化ポリシーを確保できます。 カタログレベルのテーブル最適化を有効にすることで、チームがデータの価値を最大限に活用することに集中できるようになり、整理された、高性能で費用対効果の高いデータレイクの維持を支援することをお勧めします。 この機能をお客様のユースケースで試していただき、コメントでフィードバックや質問をお寄せください。 AWS Glue Data Catalog テーブルオプティマイザーの詳細については、 Iceberg テーブルの最適化 をご覧ください。 謝辞：A special thanks to everyone who contributed to the development and launch of catalog level optimization: Siddharth Padmanabhan Ramanarayanan, Dhrithi Chidananda, Noella Jiang, Sangeet Lohariwala, Shyam Rathi, Anuj Jigneshkumar Vakil, and Jeremy Song. 著者について Tomohiro Tanaka  is a Senior Cloud Support Engineer at Amazon Web Services (AWS). He’s passionate about helping customers use Apache Iceberg for their data lakes on AWS. In his free time, he enjoys a coffee break with his colleagues and making coffee at home. Noritaka Sekiyama is a Principal Big Data Architect with AWS Analytics services. He’s responsible for building software artifacts to help customers. In his spare time, he enjoys cycling on his road bike. Sandeep Adwankar is a Senior Product Manager at Amazon Web Services (AWS). Based in the California Bay Area, he works with customers around the globe to translate business and technical requirements into products customers can use to improve how they manage, secure, and access data. Siddharth Padmanabhan Ramanarayanan is a Senior Software Engineer on the AWS Glue and AWS Lake Formation team, where he focuses on building scalable distributed systems for data analytics workloads. He is passionate about helping customers optimize their cloud infrastructure for performance and cost efficiency.

3 週間前、 ニュージーランドの新しい AWS リージョン (ap-southeast-6) に関する記事を公開したところ、これがニュージーランドを訪問するというすばらしい機会につながりました。ニュージーランドでは、熱意あふれるビルダーたちに会い、 Serverless and Platform Engineering Meetup 、 AWS Tools and Programming Meetup 、 AWS Cloud Clubs in Auckland 、 AWS Community Day New Zealand などのイベントでプレゼンテーションを行いました。 これらのプレゼンテーションのコンテンツを作成する過程で見つけたのが、 tangent mode と呼ばれる Amazon Q CLI の新機能です。この機能は、会話のメインスレッドを見失わずに関連する別のトピックを掘り下げることを可能にする会話チェックポイントを作成することで、私が集中し続ける方法を大きく変えてくれました。 この機能は実験モードになっており、 q settings chat.enableTangentMode true を使用して有効化できます。皆さんの役に立つかどうか、ぜひ試してみてください。 9 月 15 日週のリリース 次に、私が注目したリリースをいくつかご紹介します。 Amazon Bedrock の新しい基盤モデル – 一般提供が開始された Qwen モデルファミリー 、 DeepSeek-V3.1 、 Stability AI イメージサービス で Amazon Bedrock のモデルオプションが拡大されました。この拡大により、開発者はテキスト生成、コード生成、画像作成、複雑な問題解決といったタスクのための強力なマルチリンガルモデルと高度な画像生成機能にアクセスできるようになります。 Amazon VPC Reachability Analyzer が 7 つの新リージョンに拡大 – Network Access Analyzer 機能がさらに多くのリージョンで利用可能になりました。お客様は、より優れたグローバルカバレッジを活用して VPC インフラストラクチャ全体のネットワーク接続問題の分析とトラブルシューティングを行えるようになります。 Amazon Q Developer がリモート MCP サーバーをサポート – Amazon Q Developer がリモートモデルコンテキストプロトコル (MCP) サーバーに統合され、開発者はカスタムツールやデータソースを用いて AI アシスタント機能を拡張し、開発ワークフローを強化できるようになりました。 AWS Step Functions が新しいデータソースオプションで分散マップを強化 – 分散マップ向けの追加のデータソースオプションと改善されたオブザーバビリティ機能が Step Functions に導入され、より優れた監視機能とデバッグ機能で大規模な並列ワークロードの処理がさらに容易になりました。 Amazon Corretto 25 の一般提供開始 – Amazon が提供する無料の OpenJDK 25 マルチプラットフォームディストリビューションの一般提供が開始されました。Amazon Corretto 25 は、モダンアプリケーションを構築するための長期的なサポート、パフォーマンス強化、セキュリティ更新を Java 開発者に提供します。 Amazon SageMaker HyperPod が自動スケーリング機能を導入 – SageMaker HyperPod が自動スケーリング機能のサポートを開始しました。この機能により、機械学習チームはワークロードの要求に基づいてコンピューティングリソースを動的に調整して、分散トレーニングジョブのパフォーマンスとコストの両方を最適化できます。 その他のアップデート Gartner が 2025 年 Magic Quadrant で AWS を AI Code Assistants 部門のリーダーとして選出 – AWS が Gartner Magic Quadrant、AI Code Assistants 部門のリーダーとして選出されました。これは、AI 駆動の提案でより速く、よりセキュアにコードを記述するための開発者の支援における Amazon Q Developer の能力を明らかにしています。 AWS Cloud Club Captain 募集中  – 締め切りまで残り数日になりました! AWS Cloud Club Captain になって、ますます広がる学生クラウド愛好家ネットワークの一員になりましょう。 Captain になると、リーダーシップスキルを磨きながら、イベントを企画したり、クラウドコミュニティを構築したりできます。応募受付期間は 2025 年 9 月 1 日から 28 日までです。 近日開催予定の AWS イベント カレンダーをチェックして、近日開催予定の AWS イベント、 AWS re:Invent 、 AWS Summits にサインアップしましょう。 AWS AI Agent Global Hackathon – AWS の強力な生成 AI スタックを掘り下げて、目を見張るようなすばらしいソリューションを創り出すチャンスです。9 月 8 日から 10 月 20 日までの期間、AWS の AI サービススイートを使用して AI エージェントを作成し、45,000 USD を超える賞金と独占的な市場参入機会を賭けて競い合いましょう。 AWS Gen AI Loft – Loft 限定のセッションで AWS の AI 製品とサービスについて学び、業界をリードするエキスパートと交流して、投資家や同業者との貴重なネットワーキング機会を得ることができます。最寄りの都市でご登録ください。日程は、 メキシコシティ (9 月 30 日～10 月 2 日)、 パリ (10 月 7 日～21 日)、 ロンドン (10 月 13 日～21 日)、 テルアビブ (11 月 11 日～19 日) です。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 南アフリカ (9 月 20 日)、 ボリビア (9 月 20 日)、 ポルトガル (9 月 27 日)、 マニラ (10 月 4～5 日) です。 こちらで 今後開催されるすべての AWS イベント と AWS スタートアップイベント をご覧いただけます。 9 月 22 日週のニュースは以上です。9 月 29 日週の Weekly Roundup もお楽しみに! ハッピービルディング! – Donnie 原文は こちら です。

はじめに このブログでは、Amazon Bedrock AgentsをSAPインスタンスの管理支援に使用する方法を実演します。SAPControlが提供するWebサービスを呼び出すエージェントの機能を活用することで、ユーザーはSAP環境を効率的に管理できます。 SAPControl は、主にSAPプロセスの停止、開始、監視に使用されるSOAP Webサービスインターフェースです。しかし、これらの一般的な使用例を超えて、このサービスは管理シナリオで非常に価値のある幅広い機能を提供します。 このブログの前提条件： ユーザーは、SAPControlの使用とSAPシステムの管理に精通した経験豊富なSAP管理者または技術アーキテクトである。 sapstartsrvプロセスが実行されている、正常で稼働中のAWSホスト型SAPインスタンスへのアクセス。 AWS CLIがSAPサーバーにインストールされ、設定されている。 SAPサーバーのEC2セキュリティグループが、ポート5<nn>13へのアクセスを許可している（<nn>はSAPインスタンスのインスタンス番号）。 EC2インスタンスロールがS3バケットへのアクセス権を持っている。 Amazon Bedrockサービスと大規模言語モデル（例：Claude Haiku）へのアクセス。 AWS Lambdaサービスに関する知識とアクセス。 動作するPython開発環境。 Python開発スキル、仮想環境の使用、レイヤーなど。 プロセスフロー AWS Lambda関数（以下「Lambda」と呼ぶ）を作成して、SAPサーバー上のSAPControl SOAP Webサービスインターフェースを呼び出すWebプロキシとして機能させます。Lambda関数は<sid>admユーザーとそのパスワードを使用して認証します。セキュリティを強化するため、パスワードは関数にハードコードするのではなく、AWS Systems Managerの暗号化されたパラメータストアから取得します。 このブログで提供されるサンプル関数では、以下のタスクが可能になります： SAPパラメータの値を確認 指定されたS3バケットにログファイルを送信 SAPインスタンスを停止 SAPインスタンスを開始 SAPインスタンスのプロセス状態を確認 その後、Lambda関数は選択した大規模言語モデル（以下「LLM」と呼ぶ）によって駆動されるAmazon Bedrock Agentと統合されます。これにより、SAP管理者は自然言語を使用してSAPシステムと対話し、操作できるようになります。 図01 – ソリューションのアーキテクチャ概要 概要レベルステップ Lambda関数が使用するライブラリを含むPythonのLambdaレイヤーを作成 Webプロキシとして機能するLambda関数を作成 Bedrock Agentを作成し、作成したLambda関数を割り当て Systems Managerで<sid>admパスワードとインスタンス番号を保存する新しいパラメータを作成 このブログで紹介するソリューションでは、SAPインスタンスの状態を変更できることにご注意ください。ビジネスクリティカルなSAPシステムでこれを試行する前に、本番環境以外のサンドボックス環境で練習することを強く推奨します。このブログで説明されている手順に従ってミッションクリティカルなSAPシステムに影響が生じた場合、当方では責任を負いかねます。 詳細ステップ Lambdaレイヤーの作成 既存のPython開発環境で、 requirements.txt ファイルに基づいて必要なパッケージをインストールします。このブログでは、Python 3.11と互換性のあるパッケージを使用しました。正確なセットアップとバージョンによっては、requirements.txtファイルを変更する必要がある場合があることにご注意ください。パッケージがインストールされたら、/python/lib/python3.11/site-packagesのサブディレクトリと内容を含む、pythonディレクトリ全体をzipします。これがLambda関数のzipレイヤーファイルになります。レイヤーを作成するために、pyenvと仮想環境を使用して必要なパッケージをインストールすることを強く推奨します。 requirements.txtファイルを使用したパッケージのインストール方法や、Pythonレイヤーの操作方法について詳細が必要な場合は、このブログの最後にある付録をご確認ください。組織内のPython開発者に支援を求めることもできます。このブログはAmazon BedrockとSAP関連のステップに焦点を当てているため、Pythonの詳細ガイドは範囲外です。 レイヤーzipファイルが作成されたら、AWSアカウントにログインしてLambdaに移動し、レイヤーをロードします（図02参照）。 図02 – Lambdaレイヤーのロード zipレイヤーファイルには、zeepとboto3に必要なPythonライブラリが含まれています。この例では、レイヤーファイルは「sapcontrollayer311.zip」と呼ばれ、x86_64プロセッサアーキテクチャを使用しました。正確なセットアップでは異なる場合があるため、正確なセットアップに合わせて以下のスクリーンショットから若干逸脱する可能性があります（図03参照）。 図03 – Lambdaレイヤー設定 レイヤーが正常に追加されました。次に、Lambda関数のIAMロールを更新して、必要な権限を追加する必要があります。 Bedrock Agentの作成 次に、Amazon Bedrockサービスに移動し、新しいエージェントを作成します。 「Claude 3 Haiku」モデル（または前のステップで有効にしたモデル）を使用します。LLMの使用はトークンと呼ばれるものに基づいて計算される料金が発生することにご注意ください。料金の詳細については、以下の AWS公式ページ をご覧ください。 このブログの最後にある例のシナリオでは、Claude Haiku 3 LLMを使用した場合、合計で約$0.12のコストがかかります。実行する正確なリージョンと、入力および出力として使用する単語（トークン）の量によって、多少の変動がある可能性があります。 エージェントへの指示として以下のテキストを入力します。 「あなたは、プロファイルパラメータの確認、SAPシステムの停止と開始、SAPシステムログファイルのS3バケットへのロード、SAPシステムのプロセスリストと状態の確認など、様々なタスクでSAPシステム管理者を支援できる有用なエージェントです」 このプロンプトは非常に重要です。なぜなら、このテキストがAmazon Bedrockに特定のタスクでエージェントを使用すべきかどうかを指示するからです。 新しいアクショングループの追加 新しいアクショングループを追加するには、「追加」をクリックし、アクショングループを「ag-sapcontrolagent」と呼びます。 図17 – 新しいアクショングループの追加 「アクショングループの呼び出し」セクションで、「既存のLambda関数を選択」ラジオボタンをクリックし、先ほど作成したLambda関数の名前を選択します。 図18 – Lambda関数をアクショングループに関連付け アクショングループ関数の作成 「get-parameter-value」という最初の関数を作成します。 Lambdaコードの内容と一致する必要があるため、関数とパラメータの正確な名前を使用してください。 図19 – 関数get-parameter-valueの追加 詳細を手動で入力する代わりに、標準のテーブルビューから「JSONエディタ」ビューに切り替えた後（画面右上）、 get-parameter-value JSONをコピー＆ペーストするだけでも構いません。 次に、「アクショングループ関数を追加」ボタンをクリックして、さらに関数を追加します： 次のアクショングループ関数を「load-logfiles-to-s3」と名付けます： 図20 – 関数load-logfiles-to-s3の追加 再度、JSONエディタビューに切り替えた後、 load-logfiles-to-s3 JSONをコピー＆ペーストするだけでも構いません。 「stopinstance」という、インスタンスを停止する別の関数を作成しましょう。 図21 – 関数stopinstanceの追加 または、 stopinstance JSONをコピー＆ペーストしてください。 次に、「startinstance」という開始関数を作成します。 図22 – 関数startinstanceの追加 より簡単であれば、 startinstance JSONをここからコピー＆ペーストできます。 最後に、「get-process-status」関数を追加して、インスタンスの状態を確認できるようにします。 図23 – 関数get-process-statusの追加 get-process-status 関数のJSON形式も利用可能です。 次に「作成」をクリックします。「エージェントへの指示」フィールドが消去された場合は、再度入力してください（時々発生します）。その後、「保存して終了」をクリックします。 「準備」ボタンをクリックして、エージェントのテストバージョンを準備します。 図24 – エージェントの準備 この同じ画面で、エージェントARNをメモしてください。すぐに必要になります。 Lambda権限の修正 Lambda関数に戻ります。「設定」タブの「権限」ペインで、以下の「リソースベースポリシーステートメント」を追加します（「権限を追加」ボタンをクリック）。 図25 – Lambda権限の修正 Amazon Bedrock AgentがLambda関数を呼び出せるように追加します。 図26 – Amazon Bedrock AgentがLambda関数を呼び出せるように追加 「AWSサービス」を選択 サービス：「その他」 ステートメントID：自由テキスト（例：「sapcontrolbedrockagent」） プリンシパル：「bedrock.amazonaws.com」 ソースARN：Amazon Bedrock AgentのARNを確認できます（上記の数画面を参照） アクション：「lambda:InvokeFunction」 このポリシーにより、Amazon Bedrock AgentがLambda関数を呼び出すことができます。 Systems Manager Parameter Storeの維持 最後に維持すべきは、コードが<sid>admパスワードとインスタンス番号を検索するための情報です。パスワードをコードにハードコードするのは良い慣行ではありません。このため、AWS Systems Manager → Parameter Store内に以下の2つのエントリを作成します。 図27 – AWS Systems ManagerのParameter Store <sid>admのパスワードを保存するSecureStringパラメータを追加します。以下の例では、SAP SIDがMLDのため「mldadm」エントリになります。 図28 – SecureStringパラメータの追加 <sid>noパターンを使用してインスタンス番号パラメータも追加します。MLDシステムの場合、エントリは「mldno」になります – これは透過的なStringタイプにできます。 図29 – SAPシステム番号パラメータエントリ 必要な人とサービスのみがParameter Storeにアクセスできるようにしてください。 エージェントのテスト ついにエージェントとの会話をテストする時が来ました。Bedrock Agentサービスに戻り、新しく作成したエージェントを選択し、プロンプト領域を使用して以下のテストを実行します（図30は黄色でプロンプト領域を示しています）。 図30 – エージェントとの対話 エージェントにパラメータ値を尋ねる エージェントに以下を尋ねます： 「ホスト192.168.0.12上のMLD SAPシステムのSAPDBHOSTパラメータ値は何ですか？」 Bedrock Agentからの回答： 「ホスト192.168.0.12上のMLD SAPシステムのSAPDBHOSTパラメータ値は’sapvhana’です。」 図31 – エージェントとの会話例 同じプロンプトでより多くのパラメータ値を尋ねる 質問： 「ホスト192.168.0.12上のMLD SAPシステムのrdisp/wp_no_diaとSAPLOCALHOSTのパラメータ値は何ですか？」 回答： 「ホスト192.168.0.12上のMLD SAPシステムのパラメータ値は：– rdisp/wp_no_dia = 10 – SAPLOCALHOST = sapmldpas」 エージェントが2つの別々のパラメータの値を尋ねていることを理解し、関数を2回呼び出すことに注目してください。 SAPインスタンスの状態を確認する 以下を尋ねます： 「ホスト192.168.0.12上のSAPシステムMLDの状態は何ですか？」 SAPインスタンスの状態を確認する 以下を尋ねます： 「ホスト192.168.0.12上のSAPシステムMLDの状態は何ですか？」 回答は以下のようになるはずです： 「ホスト192.168.0.12上のSAPシステムMLDの状態は、ディスパッチャー、IGSウォッチドッグ、ゲートウェイ、ICMなどのすべての主要プロセスが実行されており、正常な状態です。」 図32 – エージェントとの会話のもう一つの例 インスタンスを停止する 次の例は実際にSAPインスタンスをシャットダウンすることにご注意ください。ビジネスへの影響なしに安全にシャットダウンできるシステムでのみ、この手順に従ってください！ 入力： 「ホスト192.168.0.12上のSAPシステムMLDを停止してください」 出力： 「ホスト192.168.0.12上のSAPシステムMLDが正常に停止されました。」 状態を再度確認する 図33の以下のプロンプトを参照して、状態を再度確認してください。 図33 – エージェントによって検出された停止システムの状態 システムを再度開始する エージェントにホスト情報を提供する必要がもうないことにご注意ください。エージェントは以前の会話からホストの詳細（192.168.0.12）を記憶しています（図34参照）。 入力プロンプト： 「SAPシステムMLDを開始してください」 図34 – エージェントによるSAPシステムの開始 状態を確認する SAPインスタンスの開始を可能にするために数分待った後、エージェントに状態について尋ねます。以下の図35を参照してください。 図35 – SAPインスタンスの状態確認 Amazon Bedrock Knowledge Baseの使用 この次の例では、Amazon Bedrock Knowledge Baseを使用してログファイルを保存し、ログ内のエラーを検索します。一時的な空のS3バケットを作成しましょう。この例では、バケット名「bedrockdemosaplogs」を使用しますが、まだ使用されていない限り任意のバケット名を作成できます（または、この目的のために既存のバケットがある場合は、それを単純に使用してください）。エージェントにログファイルをこのバケットにアップロードさせ、それをAmazon Bedrock Knowledge Base（以下「KB」と呼ぶ）として使用します。EC2インスタンスロールがS3バケットにアクセスするために必要な権限を持っていることを確認してください。 KBの力をより良く実演し、実際の状況をシミュレートするために、ログファイルにいくつかのエラーが発生するように、意図的にエラーを発生させます。 この例では、アプリケーションサーバーをシャットダウンせずに、その背後にあるクラスターを停止することで、メッセージサーバーをシャットダウンします。 図36 – エラーのテストケースを発生させる 次に、エージェントにログファイルをバケットにロードするよう指示します（s3://<bucketname>/形式を使用してください）。以下の図37を参照してください。 図37 – エージェントにログファイルをバケットにロードするよう指示 ログファイルが実際にバケットに表示されています。以下の図38を参照してください。 図38 – ログファイルがバケットに表示される 次に、Amazon Bedrock → Knowledge bases → Create knowledge baseに移動します。 図39 – Knowledge Baseの作成 名前を付けて、データのソースとしてS3を選択します。 図40 – データソースとしてS3を追加 S3バケットURI情報を提供します。 図41 – S3 URIの提供 ベクターストア用に「Titan Text Embeddings v2」モデルを選択します。 図42 – ベクターストアの選択 最後のサマリー画面で「ナレッジベースを作成」ボタンをクリックします。KBが作成されます。 KBが作成されたら、同期ジョブを実行します。 図43 – Knowledge Base同期 同期プロセスを監視します。 図44 – 同期プロセスは長時間かかる場合があります 同期プロセスは、ログの量によって長時間かかる場合があります。 次に、エージェントに戻り、設定を編集します。作成して同期したKBを追加します。 図45 – エージェントにKBを追加 エージェントに追加するKnowledge Baseを選択します。 エージェントへの指示は以下のようにしてください： 「ログファイル内のエラーを検索してください。.oldファイルは無視してください。同じ種類の最新のエラーメッセージを見つけるようにしてください。」（以下の図46を参照） 図46 – KBの選択 エージェントを保存し、再度準備します（準備を忘れないでください。そうしないとナレッジベースの追加が反映されません）。 Knowledge Baseを使用したエージェントのテスト エージェントにログからエラーを検出するかどうか尋ねます。図47の以下にプロンプト例があります。 図47 – エージェントがKnowledge Base内のログを分析 エージェントは、ログファイルで見つかったエラーメッセージを報告するはずです。 自分で試してみる Bedrockエージェントのトレースを分析し、会話をアクションにどのように分解するかを理解してみてください。 上記のサンプルコードにまだ含まれていないSAPcontrolの機能を取り上げて、実装してみてください（Lambdaにコードを追加し、アクショングループを作成するなど）。多くのコーディングスキルは必要ありません。関連するセクションをコピー＆ペーストして、新しい機能に合わせて修正してください。追加のタスクでエージェントの説明を更新することを忘れないでください。 Systems Manager Parameter Storeに情報を保持する代わりに、ランドスケープ情報全体をCSVファイルとしてS3バケットにロードし、ナレッジベースとしてエージェントに追加することを試してください。 パラメータチェックとSAP EarlyWatch Alertレポート（ナレッジベースとして追加）のクロスチェックを組み合わせて、特定のパラメータ値が推奨値から逸脱しているかどうかを判断します。 Systems Manager Parameter Storeに情報を保持する代わりに、ランドスケープ情報全体をCSVファイルとしてS3バケットにロードし、ナレッジベースとしてエージェントに追加することを試してください パラメータチェックとSAP EarlyWatch Alertレポート（ナレッジベースとして追加）のクロスチェックを組み合わせて、特定のパラメータ値が推奨値から逸脱しているかどうかを判断します。 コスト 既存のSAPシステムは、EC2、ストレージなどのコストが発生します – これは正確なSAPシステムによって変動します。 LLM料金はトークン（入力プロンプトと出力テキストの両方を含む）に基づいています。したがって、これも変動します。最新の料金については AWS公式ページ をご確認ください。 まとめ このブログ投稿では、Amazon Bedrock Agentsを活用してSAPインスタンスの開始と停止、ヘルス状態とパラメータ値の確認などの基本的なSAP運用タスクの実行を支援する使用例を実演しました。また、Knowledge Baseを利用して、膨大な量のログファイル内で関連するログエントリを見つける支援も行いました。 これらの例は、同様のアプローチを使用して実装できる潜在的な使用例のサンプルに過ぎません。同じ類推で探索・実装できる追加の使用例が数多くあります。 詳細を学ぶ Amazon Bedrockサービスについて詳しく読むには、この ページ をご覧ください。 PythonでLambda関数を構築する方法について詳しく学ぶには、この サイト をご確認ください。 この AWSドキュメント では、Pythonでレイヤーを操作する方法についてより多くのガイダンスを見つけることができます。 こちら と こちら にも有用なヒントがあります。 本ブログはパートナー SA 松本が翻訳しました。原文は こちら です。