未来の人流シミュレーションサービスへの取組 序章 こんにちは。ソリューションアーキテクトの齋藤と松本です。株式会社 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 松本が翻訳しました。原文は こちら です。

この投稿は Anthropic の Gareth Jones と共同で執筆されています。 Anthropic の Claude 4 Sonnet モデルが Amazon Bedrock でローンチされ、基盤モデルの機能において大幅な進歩を遂げました。これに伴い、Anthropic の Claude 3.5 Sonnet (v1 および v2) の廃止スケジュールが発表されました。この進化により、本番 AI アプリケーションにとって二つの重要な考慮事項が発生しています。強化されたパフォーマンスを活用する機会と、廃止前に移行するという運用上の必要性です。組織は、モデル移行を AI 推論戦略の中核要素として扱う必要があります。なぜなら、実行が不適切だとサービス中断、パフォーマンス低下、コスト超過を招く可能性があるからです。 この投稿では、Amazon Bedrock で Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet &nbsp;に移行するための体系的なアプローチを提供します。主要なモデルの違いを検証し、重要な移行の考慮事項を強調し、この必要な移行を組織にとって測定可能な価値をもたらす戦略的優位性に変える実証済みのベストプラクティスを提供します。 モデルの違いの概要 モデルバージョン間の具体的な変更を理解することは、成功する移行を計画する最初のステップです。Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet への移行では、活用できる機能と動作の変化が取り入れられています。 コンテキストウィンドウの拡大 – Anthropic の Claude 4 Sonnet は、コンテキストウィンドウを 200 K トークンから 1 M トークン (ベータ版) に拡張します。これにより、アプリケーションは単一のプロンプトでコードベース、財務レポート、または長い法的文書を処理し、推論することができ、複雑なワークフローを簡素化します。 ネイティブ推論メカニズム – Anthropic の Claude 3.5 Sonnet モデルが思考の連鎖 (chain-of-thought、CoT) プロンプト技術に依存するのに対し、Claude 4 モデルは 拡張思考 や インターリーブ思考 などの組み込み で API 対応の推論機能を導入します。これらにより、モデルは回答前に思考するための専用の計算時間を得て、複雑な問題でのパフォーマンスを劇的に向上させます。 高度なツール使用 – Anthropic の Claude 4 Sonnet モデルは、ツール呼び出し機能を大幅にアップグレードします。 複数のツールを並列実行 し、ツール呼び出し間で拡張思考を使用できるため、古いモデルの順次ツール使用と比較して、より洗練された効率的なエージェントワークフローが可能になります。 モデルの違いについて詳しく知るには、 完全なモデル比較ガイド を参照してください。 移行を成功させるためには、いくつかの重要で技術的・戦略的な考慮事項が鍵となります。これらについては以下のセクションで説明します。これらの点を積極的に対処することで、リスクを最小化し、本番環境への道のりを加速できます。 前提条件 Anthropic の Claude 4 Sonnet モデルの使用を開始する前に、Amazon Bedrock でこれらのモデルへのアクセスを有効にする必要があります。手順については、 Amazon Bedrock 基盤モデルへのアクセスをリクエストする を参照してください。モデルアクセスリクエストを進める前に、モデルのエンドユーザーライセンス契約 (EULA) を確認し、同意することを確認してください。Claude 4 Sonnet が意図した AWS リージョンで利用可能であることを最初に確認することが重要です。なぜなら、モデルサポートは場所によって異なる可能性があるからです。サポートされているリージョンの最新リストについては、 Amazon Bedrock でのリージョン別モデルサポート を参照してください。さらに、モデル推論を実行する際に推論プロファイルを指定することで クロスリージョン推論 (CRIS) を使用でき、これによりスループットの向上とリソース可用性の最大化に役立ちます。サポートされているクロスリージョン推論プロファイルのリストについては、 推論プロファイルでサポートされているリージョンとモデル を参照してください。 API の変更とコードの更新 Amazon Bedrock においてモデルを移行する際は、モデル固有の InvokeModel API または統一された Converse API のいずれかを使用できます。 InvokeModel API を使用する場合、移行は簡単です。Anthropic の Messages API のリクエストボディ構造はバージョン間で一貫しているため、コード内の modelId を更新するだけで済みます： 旧モデル ID – 'anthropic.claude-3-5-sonnet-20240620-v1:0' または 'anthropic.claude-3-5-sonnet-20241022-v2:0' 新モデル ID – 'anthropic.claude-4-sonnet-20240514-v1:0' モデルに CRIS プロファイル を使用する場合は、ソースリージョンの 中から&nbsp; 正しい推論プロファイル ID 1 つを指定してください。例： 'us.anthropic.claude-sonnet-4-20250514-v1:0' この移行は、Converse API に切り替える絶好の機会です。Amazon Bedrock の言語モデルに対して標準化されたリクエスト/レスポンス形式を提供し、将来の異なるモデルやプロバイダーへの移行をはるかに簡単にします。以下のコードを参照してください： import boto3 bedrock_runtime = boto3.client(service_name='bedrock-runtime') # モデルを切り替えるためには、単にモデル ID を変更 response = bedrock_runtime.converse( modelId='us.anthropic.claude-sonnet-4-20250514-v1:0', messages=[{'role': 'user', 'content': [{'text': "Your prompt here"}]}], inferenceConfig={'maxTokens': 1024} ) print(response['output']['message']['content'][0]['text']) 以下はいくつかの重要な変更点です: 更新されたテキストエディタツール – エージェントワークフローで Anthropic の組み込みテキストエディタツールを使用している開発者は、ツール定義が更新されていることを認識する必要があります。ツールタイプは現在 text_editor_20250124 で、ツール名は現在 str_replace_based_edit_tool です。テキストエディタツールは Anthropic の Claude 4 で一般提供されているため、 anthropic_beta ヘッダーの computer-use-2024-10-22 は削除できます。このツールを使用するコードは、これらの変更を反映するように更新する必要があります。詳細については、 Anthropic 定義ツール を参照してください。 削除された undo_edit コマンド – undo_edit コマンドは Anthropic の Claude 4 Sonnet でサポートされなくなりました。このコマンドを使用するコードは削除する必要があります。 新しい refusal 停止理由 – モデルは現在 新しい拒否停止理由 を導入しています。この理由は、モデルが安全ポリシーによりコンテンツ生成を拒否した場合に返されます。モデルレスポンスを処理するアプリケーションロジックは、この新しい停止理由を認識し、管理するように更新して、予期しない動作やエラーを防ぐ必要があります。例えば、マルチターンインタラクションで refusal 停止理由を受け取った場合、拒否されたターンを削除または更新することで会話コンテキストをリセットする必要があります。 プロンプトエンジニアリングと動作の変化 既存のプロンプトが新しいモデルで完璧に動作すると仮定してはいけません。モデル固有のベストプラクティスの遵守が重要です。 最適な結果を得るために、Anthropic がリリースした Claude 4 プロンプトエンジニアリングベストプラクティス を参照してください。例えば、Anthropic の Claude モデルは、入力の異なる部分を明確に分離するために XML タグ (例： &lt;document&gt; 、 &lt;/document&gt; ) で構造化されたプロンプトで最高のパフォーマンスを発揮します。 Anthropic の Claude 4 Sonnet は、指示により正確に従うように設計されています。これは大きな利点ですが、明示的にプロンプトされない限り、Claude 3.5 Sonnet よりも冗長性や詳細性が低い可能性があります。AI のペルソナを定義するシステムプロンプトは調整が必要かもしれません。 新しい思考推論機能 Anthropic の Claude 4 Sonnet モデルに組み込まれている 拡張思考 は強力な機能です。新しいモデルの深い推論機能を解放するために、開発者は API 呼び出しに thinking キーワード引数を含めることで拡張思考を有効にできます。ただし、戦略的に使用することを確認してください。拡張思考は追加コストが発生します。なぜなら、推論トークンは標準モデル料金で出力トークンとして課金されるからです。 (表示される要約だけでなく) 完全な思考プロセスに対して課金され、設定した思考予算に応じてコストが拡大する可能性があります。 精度が最重要である深い多段階分析を必要とするタスク (例：複雑な科学的問題や高度なコーディングチャレンジ) では、拡張思考を有効にすることをお勧めします。 単純なクエリや遅延に敏感なアプリケーションでは、拡張思考を無効にすることをお勧めします。この機能はコスト (推論トークンが課金される) と応答時間の両方を増加させます。多くのタスクでは、適切に作成された CoT プロンプトが依然として最も効率的な選択です。 拡張思考を使用するには、 thinking 設定で additionalModelRequestFields パラメータを追加して Converse API 呼び出しを更新するだけです。 budget_tokens の値を設定することで、モデルが使用できる最大思考トークン数を指定できます。拡張思考では、 maxTokens は budget_tokens より大きくする必要があることに注意してください。以下のコードを参照してください： import boto3 bedrock_runtime = boto3.client(service_name='bedrock-runtime') # 拡張思考を有効にするために設定を追加 response = bedrock_runtime.converse( modelId='us.anthropic.claude-sonnet-4-20250514-v1:0', messages=[{'role': 'user', 'content': [{'text': "Your prompt here"}]}], inferenceConfig={'maxTokens': 2048}, additionalModelRequestFields={"thinking":{"type": "enabled", "budget_tokens": 1024}} ) reasoning_text = response['output']['message']['content'][0]['reasoningContent']['reasoningText']['text'] assistant_response = response['output']['message']['content'][1]['text'] 以下の表は、拡張思考の例とそれがどのように応答精度を向上させるかを示しています。Anthropic の Claude 3.5 Sonnet v2 と Claude 4 Sonnet (拡張思考有効) にサンプルのプロンプトを与えます： Alan、Bob、Colin、Dave、Emily が円形に立っています。Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。Alan の真右にいるのは誰ですか？ 表は 2 つのモデルからの応答を示しています。拡張思考により、モデルは問題を慎重に推論し、正しい答えに到達できます。 モデル 拡張思考 出力 正解/不正解 Claude 3.5 Sonnet v2 N/A (参考訳) 段階的に解決してみましょう。まず、わかっていることを理解しましょう：Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。任意の人から始めて、順番に配置してみましょう：Dave が Emily の真左にいる場合、Emily は Dave の真右にいます。Colin が Dave の真左にいる場合、Dave は Colin の真右にいます。Bob が Colin の真左にいる場合、Colin は Bob の真右にいます。Alan が Bob の真左にいる場合、Bob は Alan の真右にいます。つまり、時計回りの順序は：Alan → Bob → Colin → Dave → Emily です。円形なので、Emily は円を完成させるために Alan の隣にいる必要があります。したがって、Emily は Alan の真右にいます。 答えは Emily です。 不正解 Claude 4 Sonnet (参考訳) 段階的に取り組んでみましょう。 円形に立っている 5 人がいます：Alan、Bob、Colin、Dave、Emily。 与えられた情報を追跡してみましょう： Alan は Bob の真左にいます Bob は Colin の真左にいます Colin は Dave の真左にいます Dave は Emily の真左にいます 円形なので、順序を把握する必要があります。1 人から始めて周りを回ってみましょう。 Alan が Bob の真左にいる場合、時計回りに：Alan、次に Bob。 Bob が Colin の真左にいる場合、時計回りに：Bob、次に Colin。 Colin が Dave の真左にいる場合、時計回りに：Colin、次に Dave。 Dave が Emily の真左にいる場合、時計回りに：Dave、次に Emily。 つまり、円の時計回りは：Alan → Bob → Colin → Dave → Emily しかし、円なので、Emily は誰かに接続する必要があります。Alan → Bob → Colin → Dave → Emily があり、これは 5 人の完全な円なので、Emily の次は Alan でなければなりません。 つまり、完全な時計回りの円は：Alan → Bob → Colin → Dave → Emily → Alan これは Emily が Alan の真左にいることを意味し、したがって Alan の真右は…慎重に考えてみましょう。 時計回りに行くと：Alan → Bob → Colin → Dave → Emily → (Alan に戻る) つまり、Alan の真右 (Alan から時計回りに) は Bob です。そして Alan の真左 (Alan から反時計回りに) は Emily です。 与えられた条件を再確認してみましょう： Alan は Bob の真左にいます ✓ (Alan は時計回りで Bob の直前に来ます) Bob は Colin の真左にいます ✓ (Bob は時計回りで Colin の直前に来ます) Colin は Dave の真左にいます ✓ (Colin は時計回りで Dave の直前に来ます) Dave は Emily の真左にいます ✓ (Dave は時計回りで Emily の直前に来ます) 円形配置で Bob が Alan の真右に座っていることを確認します。 (参考訳) 段階的に見てみましょう：与えられた情報：Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。円の時計回りの順序を追跡してみましょう：Alan → Bob (Alan が Bob の真左にいるため)。Bob → Colin (Bob が Colin の真左にいるため)。Colin → Dave (Colin が Dave の真左にいるため)。Dave → Emily (Dave が Emily の真左にいるため)。円形に立っているので、Emily は円を完成させるために接続する必要があります：Emily → Alan。つまり、完全な時計回りの順序は：Alan → Bob → Colin → Dave → Emily → Alan。したがって、 Bob が Alan の真右にいます 。 正解 拡張思考が有効な場合、API はデフォルトで、誤用を防ぐための保護措置として設計された、完全な推論チェーンではなく モデルの完全な思考プロセスの要約を返し ます。これにより、完全なインテリジェンス利益を提供しながらも、ストリーミング応答でチャンクまたは遅延パターンが生じる可能性があり、開発者はアプリケーションのユーザーエクスペリエンスでこれを考慮する必要があります。 Anthropic の Claude 4 モデルは、ツールで拡張思考を使用する際の インターリーブ思考 機能を備えており、モデルがツール呼び出し間で中間推論を実行し、受け取ったツール結果に基づいてより微妙な分析結論を開発できます。ツール呼び出しで インターリーブ思考を有効にする には、Converse API リクエストの additionalModelRequestFields に追加パラメータ "anthropic_beta": ["interleaved-thinking-2025-05-14"] を追加します。 拡張思考の使用について詳しくは、 拡張思考 を参照してください。 堅牢な評価の必要性 新しいモデルが特定のタスクで古いモデルと同等以上のパフォーマンスを発揮することを検証する必要があります。本番トラフィックを高度に代表する、厳選されたプロンプトと期待される出力のセットを作成してください。このカスタムベンチマークは、報告されたベンチマークスコアよりもはるかに価値があります。 このデータセットを自動評価パイプラインに統合してください。このパイプラインは、継続的インテグレーションおよび継続的デリバリー (CI/CD) プロセスの一部となり、将来のモデルやプロンプトの変更に対する永続的な回帰スイートとして機能する必要があります。ツールについては、チームは Amazon Bedrock の評価 などの組み込みソリューションや、 RAGAS や DeepEval などのオープンソース評価フレームワークを使用できます。 統合された安全性とガバナンスの管理 モデルの安全プロファイルは各バージョンで変化します。これは統合システムの一部としてテストする必要があります。新しいモデルを単独でテストしてはいけません。移行テスト計画は、本番環境で使用するのと全く同じガードレール設定 (例： Amazon Bedrock ガードレール ) で新しいモデルを評価する場合にのみ有効です。新しいモデルの会話スタイルが既存のガードレールを予期しない方法でトリガーし、ブロックされた応答の急増につながる可能性があります。 安全なデプロイメント戦略の実装 Anthropic の Claude 4 Sonnet を本番環境にデプロイする際は、リスクを最小化するために段階的ロールアウト戦略を実装してください。ユーザーに影響を与えることなく、ミラーリングされたトラフィックを使用してモデルパフォーマンスを比較するシャドウテストを検討し、その後ビジネス KPI への影響を測定するための A/B テストを実施してください。実際のロールアウトでは、少数のユーザーを新しいモデルに段階的に公開するカナリアリリースアプローチ、または即座にロールバック機能を持つ並列環境を維持するブルー/グリーンデプロイメント戦略のいずれかを使用してください。この構造化されたアプローチにより、ビジネス継続性を維持しながら新しいモデルのパフォーマンスを安全に検証できます。 まとめ Anthropic の Claude 3.5 Sonnet (v1 および v2) から Claude 4 Sonnet への移行を構造化されたエンジニアリングプロジェクトとして扱うことで、移行プロセスのリスクを軽減し、大きな利益を得ることができます。主要なモデルの違いを理解し、プロンプトと API 呼び出しを適応させ、堅牢で自動化された評価戦略を実装することが、成功するアップグレードの柱です。 この移行は、ビジネス継続性を維持し、次世代機能でアプリケーションを強化する機会です。今日から分析とテストを開始することをお勧めします。 詳細については、 Claude 4 への移行 と Amazon Bedrock における Anthropic の Claude を参照し、移行固有のお問い合わせについてはお気軽にお問い合わせください。 このブログはソリューションアーキテクトの福本が翻訳しました。原文は こちら です。 About the authors Melanie Li 博士は、オーストラリアのシドニーを拠点とする AWS のシニア生成 AI スペシャリストソリューションアーキテクトで、最先端の AI/ML ツールを使用したソリューション構築でお客様と協力することに焦点を当てています。彼女は APJ 全体で複数の生成 AI イニシアチブに積極的に関与し、LLM の力を活用しています。AWS に参加する前、Li 博士は金融および小売業界でデータサイエンスの役割を担っていました。 Deepak Dalakoti 博士は、オーストラリアのシドニーにある生成 AI イノベーションセンターのディープラーニングアーキテクトです。AI の専門知識を持つ彼は、クライアントと協力してカスタマイズされた革新的なソリューションを通じて生成 AI の採用を加速しています。AI の世界以外では、新しい活動や体験を探求することを楽しんでいます。 Mahsa Paknezhad 博士は、AWS 生成 AI イノベーションセンターのディープラーニングアーキテクトです。スケーラビリティと本番準備に焦点を当て、Mahsa は多様な業界の組織が高度な生成 AI モデルを活用して意味のあるビジネス成果を達成することを支援しています。Mahsa は、特に鉱業および医療セクターでプロジェクトを成功裏に提供した実績があります。 Nicholas Moore は AWS のソリューションアーキテクトで、スタートアップやあらゆる規模の企業がアイデアを現実に変えることを支援しています。彼は AI、分析、モダンアプリケーション開発に焦点を当てたクラウドソリューションを専門としています。 Derrick Choo は、クラウド採用、AI/ML、生成 AI ソリューションを通じて企業のデジタル変革を加速する AWS のシニアソリューションアーキテクトです。彼はフルスタック開発と ML を専門とし、フロントエンドインターフェース、IoT アプリケーション、データ統合、ML モデルにまたがるエンドツーエンドソリューションを設計し、特にコンピュータビジョンとマルチモーダルシステムに焦点を当てています。 Sovik Kumar Nath は、AWS の AI/ML および生成 AI シニアソリューションアーキテクトです。彼は、金融、運用、マーケティング、医療、サプライチェーン管理、IoT におけるエンドツーエンドの ML およびビジネス分析ソリューションの設計において豊富な経験を持っています。彼は南フロリダ大学とスイスのフリブール大学で修士号を、インド工科大学カラグプール校で学士号を取得しています。仕事以外では、Sovik は旅行、フェリーライド、映画鑑賞を楽しんでいます。 Saurabh Trikande は、Amazon Bedrock と Amazon SageMaker Inference のシニアプロダクトマネージャーです。彼は顧客やパートナーとの協力に情熱を持ち、AI の民主化という目標に動機づけられています。彼は、複雑な AI アプリケーションのデプロイ、マルチテナントモデルでの推論、コスト最適化、生成 AI モデルのデプロイをより身近にすることに関連するコアチャレンジに焦点を当てています。余暇には、Saurabh はハイキング、革新的技術について学ぶこと、TechCrunch をフォローすること、家族と時間を過ごすことを楽しんでいます。 Gareth Jones は、Claude API に焦点を当てた Anthropic のプロダクトマネージャーです。彼の仕事には、Claude を開発者に広くアクセス可能にするための Amazon Bedrock での AWS との協力が含まれます。 <!-- '"` -->

本記事は Securing Vehicle Identification Number (VIN) with Reference ID in connected vehicle platforms with AWS IoT を翻訳したものです。 2025 年末までに 4 億 7000 万台以上のコネクテッドカーが予想されるなか、製造メーカーにとって車両認識番号 (VIN) などの機密車両データを保護することが極めて重要になっています。 VIN は製造から整備に至るまでの自動車プロセスにおいて、固有の識別子として使われており、 サイバー犯罪者の標的 にされがちです。 本記事では、AWS IoT を利用してコネクテッドカー・プラットフォームにおける VIN の保護方法を紹介し、データ保護とシステムの機能性を両立することができます。 このソリューションでは、実際の VIN を公開することなく、セキュリティで保護された車両データの連携を可能にするために、VIN の仮名として Reference ID を導入しています。AWS IoT サービスを活用して、この分野のアーキテクチャがメーカーに対し、機能性は維持しつつ車両のユースケース全体で機密データを保護する方法を示します。 概要 このソリューションは Reference ID システムを使用しています。Reference ID システムでは、各車両にプロビジョニング時に一意の識別子が付与されます。この識別子がプラットフォームとのすべてのやり取りで VIN の代理として機能します。 車両レジストリデータベースには、ハッシュ化された VIN と暗号化された VIN の両方が格納されており、Reference ID にマッピングされています。 クライアントが VIN を提示すると、システムはその VIN をハッシュ化して対応する Reference ID を取得します。これにより、既存のプロセスと安全に統合できます。 暗号化された車両識別番号 (VIN) は、セキュアな AWS Key Management Service (AWS KMS) を使って、プロビジョニング中に暗号化されてフェイルセーフ対策として追加されます。 プレーンテキストの VIN を取得する必要がある場合は、この値を復号化することで可能です。 これにより、絶対に必要な場合に限り実際の VIN にアクセスできますが、強力なセキュリティ対策が維持されます。 VIN (車両識別番号) には重要な車両情報 (メーカー、モデル、年式) が含まれており、個人データとリンクされています。クラウド環境で保護されていない VIN は、ID の盗難、車の盗難、保険金詐欺、プライバシー侵害、規制 (GDPR、CCPA) 違反のリスクがあります。 クラウドベースのコネクティッドカープラットフォームで VIN (車体識別番号) の保護にReference ID システムを実装することで、自動車メーカーは現代の自動車運用に必要な機能と効率を維持しつつ、データセキュリティを向上させることができます： VIN のプロキシとして機能し、セキュリティとデータの最小化を強化します データ保護規制への準拠をサポートします 柔軟なアクセス制御と監査性の向上を提供します 大規模な車両フリートのスケーラビリティとシステム間の相互運用性を容易にします 基盤となる VIN を変更せずに失効させることができます VIN のアクセスと変換の詳細な監査とログを可能にし、Reference ID と VIN 間の変換を許可される主体と変換内容の可視化を提供します アーキテクチャの概要 1. Reference ID Reference ID は、車両プロビジョニング時に生成される UUID で、車両のライフサイクルを通して VIN の代理として機能し、機密性の高い VIN データを保護する抽象化層を作成します。 2. 車両登録データベース 車両登録データベースは、プラットフォームのライフタイム全体にわたり車両情報の集中リポジトリとして機能します。主な機能は次のとおりです。 Reference ID からハッシュ化された VIN へのマッピング 暗号化された VIN ストレージ 車両のプロビジョニングと状態変更の追跡 デバイスの変更履歴 車両の属性と構成 VIN のハッシュ化により、実際の値を暴露することなく安全な検証が可能になります。この集中管理されたアプローチにより、単一の情報源を提供すると同時に、安全なリモート診断と OTA のアップデートを可能にします。 車両登録 DB referenceId – パーティションキー deviceId – グローバルセカンダリインデックス hashedVin – グローバルセカンダリインデックス tenantId encryptedVin 注： deviceId と hashedVin をグローバルセカンダリインデックスにすると、いずれかのフィールドで車両詳細を問い合わせることができます。 3. 車両の設定 車両プロビジョニングでは、データの検証、安全な保管、AWS IoT との統合を通じて、セキュアな車両管理を確立し、Reference ID システムを実装します。 車両情報を保護しながら、シームレスな接続性と管理を可能にするプロセスの主要ステップを見ていきましょう： 3.1 データの検証： プロビジョニングのインフラストラクチャは、VIN をハッシュ化し、車両レジストリ DB に問い合わせて、初めてのプロビジョニングかどうかをチェックします。 新車の場合、DEVICE ID は TCU メーカーが提供する既存のデータと照合できます。 また、車両レジストリ DB に DEVICE ID で問い合わせることで、そのデバイスが別の車両に割り当てられていないかチェックします。 3.2 Reference ID 生成 ハッシュ化された VIN を使用して、車両登録 DB に対してクエリを実行し、車両がすでに登録されているかどうかを検証します。 車両がまだ登録されていない場合は、新しい UUID がReference ID として生成されます。 Reference ID、ハッシュ化された VIN、暗号化された VIN (KMS 経由) が、他の車両情報とともに車両登録 DB に保存されます。UUID の衝突が稀にある場合は、リクエストを再試行して新しい UUID をReference ID として生成することができます。 Reference ID で車両登録 DB に対して最終的なクエリが実行され、ユニークであることを確認します。UUID の衝突が検出された場合、新しい UUID が生成されます。 以前に登録されている車両の場合、受信したペイロードは単に登録 DB の項目に対して検証されます。 3.3 証明書の生成 証明書は、Common Name = Reference ID で ACM PCA を使用して生成されます。 3.4 AWS IoT との統合 AWS IoT Thing は、Thing name = Reference ID で作成されます。 AWS IoT FleetWise の車両は、Vehicle Name = Reference ID で作成されます。 3.5 レスポンスペイロードの構築 プロビジョニングが成功すると、車両に証明書とReference ID が発行されます。 車両は、発行された証明書と ClientId = Reference ID を使って、AWS IoT FleetWise に接続できます。 このプロセスは、Reference ID を使用して機密の VIN 情報を保護しつつ、車両の安全な供給を確実にするのに役立ちます。 車両は、証明書署名リクエスト (CSR) を提供できます。この供給インフラストラクチャは、CSR を使用して証明書を生成します。堅牢なアイデンティティおよびアクセス管理のための AWS サービスを活用しています。 4. データの収集と保存 データの収集と保管は必須の構成要素であり、Reference ID により車両データのライフサイクル全体 (送信から保存、取得まで) で安全な取り扱いが保証されます。このシステムにより、VIN 情報を保護しつつ、効率的なデータ操作が可能となります。 4.1 車両から AWS IoT FleetWise へ： 車両は、Reference ID をクライアント ID として使用して、AWS IoT FleetWise に接続します。 車両から送信されるすべてのデータは、AWS IoT FleetWise での車両名 = Reference ID として、Reference ID に関連付けられます。 4.2 AWS IoT FleetWise からデータプラットフォームへ： AWS IoT FleetWise から流れるデータには、車両名 (Reference ID) が付与されます。 4.3 データの保存と取得： データプラットフォームのデータは、Reference ID を識別子として保存されます。 モバイルアプリは、Reference ID を使って API プラットフォームを経由してデータプラットフォームにアクセし、車両データを取得します。 匿名化されたReference ID には車両固有の情報は含まれず、 AWS IoT Core 、 AWS IoT FleetWise 、および関連するデータストア全体での主要な識別子として機能します。 この情報中立的なアプローチにより、VIN の保護が確保されると同時に、プラットフォーム全体でのシームレスなデータ操作が可能になります。 5. クライアントアプリケーションの相互作用 顧客関係管理 (CRM) システムや、ユーザへの VIN マッピングを管理するプラットフォームなどのクライアントアプリケーションは、通常、プレーンテキストの VIN 番号を扱います。このシステムのセキュリティ上の利点を維持しつつ、これらのアプリケーションに対応するために、接続された車両プラットフォームとのクライアントの対話のためのストリームラインプロセスが実装されています。 5.1 VIN からReference ID への変換 クライアントアプリケーションは、車両の所有権を確認した後、ハッシュ化された車両識別番号とReference ID の相互変換のため、プラットフォームに API 呼び出しを行います。 API は車両レジストリデータベースに問い合わせを行い、対応するReference ID を取得します。 その後、Reference ID がクライアントアプリケーションに返されます。 セキュリティに関する考慮事項： この変換 API へのアクセスは、堅牢な認証と認可によって厳重に制御される必要があります。 監査目的で、すべての変換リクエストがログ記録され、不審なパターンを検出する必要があります。 実装には、DoS/DDoS 攻撃や、不正な大量変換試行から防御するためのレート制限やその他のセキュリティ対策を含める必要があります。 この API は車両データの再識別を可能にするため、アクセスは正当なビジネス上の必要性がある認可済みアプリケーションに制限する必要があります。 5.2 VIN に対応する Reference ID を取得したら、クライアントアプリケーションは以下を実行可能： Reference ID を使用してデータプラットフォームからデータを取得します。 リモートコマンドなどのように、Reference ID を渡すことで、直接車両に操作を実行します。 この方法は、API 呼び出しでの VIN 使用を排除し、VIN とReference ID の分離を維持することで、プラットフォームのセキュリティ強化に役立ちます。 このシステムは、クラウドベースの車両管理のための堅牢なフレームワークを提供しながら、セキュアなクライアントアプリケーション間の対話を可能にします。 6. テレマティクスコントロールユニットの変更 Telematics Control Unit（TCU）の変更フローは、接続された車両プラットフォームにおいて重要なプロセスです。 車両の TCU を更新または交換する必要がある場合に対処します。 これは、車両が製造施設を出る前、または所有者に引き渡された後に TCU に問題が発見され、サービスセンターで交換が必要になった場合のいずれかで発生します。 TCU Change フローは、次の 2 つの関数のいずれかを使って API 呼び出しとして利用できます： 車両レジストリデータベース内の DEVICE ID を新しい DEVICE ID に更新します。 車両のデータベースエントリから DEVICE ID を単に削除します。つまり、NULL としてマークします。 6.1 TCU の更新： 入力： ハッシュ化された VIN (または Reference ID)、既存の DEVICE ID、新しい DEVICE ID。 この API は以下を行います。 ハッシュ化された VIN が存在し、レジストリデータベース内の既存の DEVICE ID と一致することを確認する 新しい DEVICE ID が別の車両に関連付けられていないことを確認する レジストリデータベース内の DEVICE ID を更新する 秘密鍵が TCU ハードウェア自体内に格納されているため、置換え TCU には新しい証明書が必要になるので、車両の既存の証明書 (プロビジョニング時に発行され、AWS IoT Core に登録されたもの) を失効し削除する 新しい TCU がクラウドへの接続プロセスを通る。 6.2 TCU の削除： 入力： ハッシュ化された VIN (またはReference ID)、既存の DEVICE ID。 この API は以下のことを行います： ハッシュ化された VIN が登録データベースに存在し、DEVICE ID が一致することを検証します。 登録データベースからエントリの DEVICE ID を削除します。 車両の既存の証明書 (プロビジョニング中に発行され、AWS IoT Core に登録されている) を失効および削除します。 注： 車両を特定するためには、ハッシュ化された VIN またはReference ID のどちらを使っても構いません。SHA256 のハッシュ関数の衝突確率が極めて低いため、ハッシュ化された VIN を使用しても問題ありません。 両方のフローは、TCU 変更の履歴をレジストリデータベースが各車両に対して維持することで、セキュリティが確保され追跡可能な TCU 変更プロセスを保証します。 このアプローチにより、システムの整合性を維持しつつ、車両フリートで必要なハードウェアのアップデートに対応できます。 セキュリティ、パフォーマンス、スケーラビリティに関する考慮事項 Reference ID システムは、日々の業務での VIN の露出を最小限に抑けることで、VIN の保護を強化します。 車両レジストリデータベースは、ハッシュ化および暗号化された VIN のみを格納し、Reference ID はプラットフォームとのすべての相互作用を処理します。 AWS KMS による暗号化と厳格なアクセス制御ポリシーにより、セキュリティがさらに強化されています。 最適なパフォーマンスとスケーラビリティを実現するために、このシステムは効率的な UUID 生成と DynamoDB のグローバルセカンダリインデックスを使用して高速なクエリを実現しています。 将来的には、この VIN 管理システムは、ブロックチェーンや分散型レジストリ技術などの新しいテクノロジーと統合して、改ざん防止の VIN レコードを実現する可能性があり、セキュリティと追跡性をさらに強化できます。 自動車メーカーがこのシステムから収集できるデータの豊富さは、高度な分析や機械学習アプリケーションの可能性も開き、車両の性能、メンテナンス要件、ユーザーの行動パターンに関する洞察を得られる可能性があります。 GDPR や CCPA などのデータ保護規制に継続して準拠していくためには、最新のハッシュとデータ暗号化アルゴリズムを導入し、詳細なアクセス制御を実装し、データ取り扱い手順を定期的に監査することをお勧めします。 この包括的なアプローチは、VIN データを保護するだけでなく、コネクテッドカー管理における将来のイノベーションの基盤ともなります。 まとめ この投稿では、Reference ID がどのように自動車メーカーの AWS 上の接続車両プラットフォームにおける VIN のセキュリティを強化できるかを示しました。 この設計は、自動車の使用事例全体で完全な機能を維持しつつ、機密の車両データを保護します。AWS IoT Core や Amazon DynamoDB などの AWS サービスを活用することで、この解決策は大規模な車両フリートに対して効率的にスケーリングできます。 接続された車両の台数が増えるにつれ、自動車メーカーにとってセキュリティ対策が重要になります。このReference ID システムは、自動車メーカーに VIN の保護を支援するだけでなく、データ保護規制のコンプライアンス標準を満たすのに役立ちます。 TCU 変更などのシナリオを含め、車両のライフサイクル全体で車両識別を管理するための柔軟なフレームワークを提供します。 このアプローチをあなたのコネクティッドビークルソリューションにどのように適用できるか、探索することをお勧めします。AWS IoT サービスとコネクティッドビークルのベストプラクティスの詳細は、 AWS IoT FleetWise のドキュメント と 関連するブログ記事 を参照してください。 著者について Paritosh Mehta Paritosh Mehta は、AWS プロフェッショナルサービスのデリバリーコンサルタントとして、アジア太平洋地域全体でコネクテッドビークルおよび産業IoTの実装をリードしています。ProServe India の IoT テクニカルリードとして、自動車 OEM および製造業者向けの変革的なソリューションを設計し、車両テレマティクス、リアルタイムデータプラットフォーム、製造システム統合を専門としています。 Ankur Pannase Ankur は、AWS プロフェッショナルサービスのセキュリティアーキテクトです。お客様と密接に連携し、技術的、規制的、ビジネス要件に合わせたクラウドセキュリティソリューションの設計と実装を行っています。Ankur は、組織がクラウド上で安全でスケーラブル、かつコンプライアンスに準拠した環境を構築することを専門としています。 Jay Chung Jay は、AWS プロフェッショナルサービスのシニアデリバリーコンサルタントとして、お客様の変革的なクラウドソリューションのアーキテクチャ設計と実装を支援しています。Jay は自動車業界の愛好家で、自動車テストツール業界でプロダクトマネージャーおよびソフトウェアエンジニアとして10年以上の経験を持っています。 Robin Francis Robin は AWS のプロフェッショナルサービスチーム内でクラウドアプリケーションアーキテクトとして働き、世界最大級の企業がクラウド上で効率的で革新的なソリューションを構築することを支援しています。独学者、博学者、多言語話者である彼は、常に芸術と科学の異なる分野に挑戦しています。仕事以外では、音楽制作、外国語学習、料理、サーフィン、旅行を楽しんでいます。

本記事は SBI生命保険株式会社 狩野泰隆氏から寄稿いただきました。 SBI生命保険は昨今の委託先による大規模情報漏洩事件とデジタルトランスフォーメーション (DX) 時代の帳票システム再構築という課題に取り組んできました。 ■サプライチェーンリスクと BCP を乗り越える内製化戦略 DX が必須となる今日、機密性の高い帳票作成業務には気付きにくいリスクが潜んでいました。このことは、外部委託先で起きた大規模な個人情報流出事故によって明らかになりました。 特に深刻だったのは、委託先から数百万件件以上の個人情報が流出し、インターネットのダークウェブで公開された事件です。流出した情報には、個人の氏名や住所だけでなく、確定拠出年金の内容、ローンの残高、納税額といった非常に重要な個人情報も含まれていました。 この事件は、幸いにも SBI生命保険の委託先での事故ではありませんでしたが、保険業務の一部について情報処理業務を外部ベンダーに「丸投げ」する従来の運用体制が、いかに根本的な脆弱性を抱えるかを示しました。委託先のセキュリティインシデントは、直接自社の顧客情報流出、ブランドイメージの失墜、事業継続の危機に直結します。特に大量の個人情報を扱う帳票業務を外部に委託する場合、そのサプライチェーンリスクは計り知れず、委託先が機能不全に陥れば、自社の基幹業務停止という BCP 上の大きな脅威となることを再認識しました。 ■リスクを自社内に取り込む戦略 SBI生命保険では、この大規模情報漏洩インシデントを「DX 推進の奇貨」と捉え、従来の外部依存型を根本から覆す「帳票エンジン」の内製化を企画しました。 新しい帳票作成システムでは、Amazon QuickSight をレイアウト作成と情報抽出のエンジンとして採用しています。 QuickSight のダッシュボードでレイアウトを設計し、各種情報をオーバーレイさせることで契約書などの複雑なフォーマットにも対応可能です。ユーザーはパラメーター設定でデータベースから必要な情報を抽出し、適切な情報が埋め込まれた帳票を自社内で迅速に生成できます。これによってデータ処理から帳票生成・出力までを全て自社内で完結できるようになりました。 この新システムには、3 つの重要な特長があります。まず、帳票エンジンを内製化することで、外部ベンダーへの機密データ提供を最小限に抑え、情報漏洩リスクを低減できると考えています。次に、自社内でデータ処理を完結させることにより、情報管理の透明性と統制を強化し、QuickSight のアクセス権限管理機能を活用することで高いセキュリティと使いやすさを両立しています。第三に、帳票生成における外部依存を解消し、クラウドを活用した可用性の高いアーキテクチャを採用したことで、以前よりも高い事業継続性を確保しています。 新システムを活用することで、従来約 2 ヶ月かかっていた帳票作成期間を約 1 週間に短縮し、業務の迅速な対応力を向上させると同時に、情報システム部門にとっては保守性の向上と運用負荷の大幅な軽減を実現するという成果を得ることができました。 ■未来を見据えた戦略的投資として 大規模情報漏洩事件では、データガバナンス、運用、外部ベンダー依存といった従来の帳票システム課題が、経営課題であることを浮き彫りになりました。 SBI生命保険の QuickSight を活用した「帳票エンジン」は、これらの課題を着実に解消し、セキュリティ強化、開発コスト・期間の最適化、業務の柔軟性とスピード向上を実現します。これは単なる IT システム導入ではなく、データガバナンスを経営戦略の中核に据え、サプライチェーンリスクを管理し、事業継続性を高めるための、未来を見据えた戦略的投資と考えています。 同様の課題を抱える企業にとって、本事例が少しでも参考となり、帳票業務の見直しや改善のきっかけとなれば幸いです。 ■今後 社内外で運用されている帳票を体系的に整理し、順次、当該サービスに組み込んでいく予定です。これにより、社内全体での活用範囲の拡大が進み帳票管理の一元化とさらなる業務効率化を見込んでいます。 ■システム構成の概要と構成図 今回開発した帳票作成システムは、QuickSight をデータ可視化ツールとしてではなく、帳票レイアウト作成・抽出エンジンとして活用することで、柔軟で効率的な帳票作成を実現しています。 QuickSight のダッシュボード機能を使用して帳票のレイアウトを設計し、帳票レイヤー機能を活用して契約書などの複雑なフォーマットにも対応しています。データソースとしては Amazon Aurora などのデータベースに接続しており、SQL で必要な情報を抽出しています。 図1: システム構成図 QuickSight ダッシュボードのパラメーターで設定した値を元に、「帳票作成」ボタンをクリックすると、あらかじめ指定された SQL 文がデータベースに対して実行されます。この際実行される SQL 文はあらかじめ AWS Systems Manager Parameter Store に保存してあります。ユーザーは QuickSight からパラメーターを設定するだけで、帳票作成に必要な情報を取得し、適切な情報が埋め込まれた帳票を取得することができます。 QuickSight ユーザーのアクセス権限管理を利用し、ユーザーごとにアクセスできる帳票テンプレートを制限することで、セキュリティを確保しながらユーザビリティを向上させています。帳票の生成は、「帳票作成」ボタンに URL を埋め込み、Amazon API Gateway 経由で API を実行する仕組みを構築しています。 図2: システム画面のスクリーン（イメージ） 執筆者 狩野 泰隆（かのう やすたか） SBI生命保険株式会社 情報システム部 部長 25 年以上にわたり、システム開発領域を牽引。大手 SIer での豊富な経験を経て、2018年に SBI生命保険株式会社へ転身。金融・流通・産業分野を中心に、業務システムの設計・構築に幅広く携わる。近年は、AWS を活用したクラウドネイティブなアーキテクチャ設計や、内製化による DX 推進に注力。最新技術への深い理解と現場視点を融合させた実践的なアプローチに定評があり、書籍執筆にも取り組むなど、知見を広く共有している。

本記事は SBI生命保険株式会社 狩野泰隆氏から寄稿いただきました。 SBI生命保険は昨今の委託先による大規模情報漏洩事件とデジタルトランスフォーメーション (DX) 時代の帳票システム再構築という課題に取り組んできました。 ■サプライチェーンリスクと BCP を乗り越える内製化戦略 DX が必須となる今日、機密性の高い帳票作成業務には気付きにくいリスクが潜んでいました。このことは、外部委託先で起きた大規模な個人情報流出事故によって明らかになりました。 特に深刻だったのは、委託先から数百万件件以上の個人情報が流出し、インターネットのダークウェブで公開された事件です。流出した情報には、個人の氏名や住所だけでなく、確定拠出年金の内容、ローンの残高、納税額といった非常に重要な個人情報も含まれていました。 この事件は、幸いにも SBI生命保険の委託先での事故ではありませんでしたが、保険業務の一部について情報処理業務を外部ベンダーに「丸投げ」する従来の運用体制が、いかに根本的な脆弱性を抱えるかを示しました。委託先のセキュリティインシデントは、直接自社の顧客情報流出、ブランドイメージの失墜、事業継続の危機に直結します。特に大量の個人情報を扱う帳票業務を外部に委託する場合、そのサプライチェーンリスクは計り知れず、委託先が機能不全に陥れば、自社の基幹業務停止という BCP 上の大きな脅威となることを再認識しました。 ■リスクを自社内に取り込む戦略 SBI生命保険では、この大規模情報漏洩インシデントを「DX 推進の奇貨」と捉え、従来の外部依存型を根本から覆す「帳票エンジン」の内製化を企画しました。 新しい帳票作成システムでは、Amazon QuickSight をレイアウト作成と情報抽出のエンジンとして採用しています。 QuickSight のダッシュボードでレイアウトを設計し、各種情報をオーバーレイさせることで契約書などの複雑なフォーマットにも対応可能です。ユーザーはパラメーター設定でデータベースから必要な情報を抽出し、適切な情報が埋め込まれた帳票を自社内で迅速に生成できます。これによってデータ処理から帳票生成・出力までを全て自社内で完結できるようになりました。 この新システムには、3 つの重要な特長があります。まず、帳票エンジンを内製化することで、外部ベンダーへの機密データ提供を最小限に抑え、情報漏洩リスクを低減できると考えています。次に、自社内でデータ処理を完結させることにより、情報管理の透明性と統制を強化し、QuickSight のアクセス権限管理機能を活用することで高いセキュリティと使いやすさを両立しています。第三に、帳票生成における外部依存を解消し、クラウドを活用した可用性の高いアーキテクチャを採用したことで、以前よりも高い事業継続性を確保しています。 新システムを活用することで、従来約 2 ヶ月かかっていた帳票作成期間を約 1 週間に短縮し、業務の迅速な対応力を向上させると同時に、情報システム部門にとっては保守性の向上と運用負荷の大幅な軽減を実現するという成果を得ることができました。 ■未来を見据えた戦略的投資として 大規模情報漏洩事件では、データガバナンス、運用、外部ベンダー依存といった従来の帳票システム課題が、経営課題であることを浮き彫りになりました。 SBI生命保険の QuickSight を活用した「帳票エンジン」は、これらの課題を着実に解消し、セキュリティ強化、開発コスト・期間の最適化、業務の柔軟性とスピード向上を実現します。これは単なる IT システム導入ではなく、データガバナンスを経営戦略の中核に据え、サプライチェーンリスクを管理し、事業継続性を高めるための、未来を見据えた戦略的投資と考えています。 同様の課題を抱える企業にとって、本事例が少しでも参考となり、帳票業務の見直しや改善のきっかけとなれば幸いです。 ■今後 社内外で運用されている帳票を体系的に整理し、順次、当該サービスに組み込んでいく予定です。これにより、社内全体での活用範囲の拡大が進み帳票管理の一元化とさらなる業務効率化を見込んでいます。 ■システム構成の概要と構成図 今回開発した帳票作成システムは、QuickSight をデータ可視化ツールとしてではなく、帳票レイアウト作成・抽出エンジンとして活用することで、柔軟で効率的な帳票作成を実現しています。 QuickSight のダッシュボード機能を使用して帳票のレイアウトを設計し、帳票レイヤー機能を活用して契約書などの複雑なフォーマットにも対応しています。データソースとしては Amazon Aurora などのデータベースに接続しており、SQL で必要な情報を抽出しています。 図1: システム構成図 QuickSight ダッシュボードのパラメーターで設定した値を元に、「帳票作成」ボタンをクリックすると、あらかじめ指定された SQL 文がデータベースに対して実行されます。この際実行される SQL 文はあらかじめ AWS Systems Manager Parameter Store に保存してあります。ユーザーは QuickSight からパラメーターを設定するだけで、帳票作成に必要な情報を取得し、適切な情報が埋め込まれた帳票を取得することができます。 QuickSight ユーザーのアクセス権限管理を利用し、ユーザーごとにアクセスできる帳票テンプレートを制限することで、セキュリティを確保しながらユーザビリティを向上させています。帳票の生成は、「帳票作成」ボタンに URL を埋め込み、Amazon API Gateway 経由で API を実行する仕組みを構築しています。 図2: システム画面のスクリーン（イメージ） 執筆者 狩野 泰隆（かのう やすたか） SBI生命保険株式会社 情報システム部 部長 25 年以上にわたり、システム開発領域を牽引。大手 SIer での豊富な経験を経て、2018年に SBI生命保険株式会社へ転身。金融・流通・産業分野を中心に、業務システムの設計・構築に幅広く携わる。近年は、AWS を活用したクラウドネイティブなアーキテクチャ設計や、内製化による DX 推進に注力。最新技術への深い理解と現場視点を融合させた実践的なアプローチに定評があり、書籍執筆にも取り組むなど、知見を広く共有している。

本投稿は、 Sameer Malik 、Anvesh Koganti、Shubham Singhによる記事「 Implement network connectivity patterns for Oracle Database@AWS 」を翻訳したものです。 Oracle Database@AWS （ODB@AWS）は、 Amazon Web Services（AWS） データセンター内に配置されたOracle Cloud Infrastructure（OCI）が管理するOracle Exadataインフラストラクチャへのアクセスに使用できるサービスです。ODB @AWS を使用すると、オンプレミスのOracle Exadataデプロイメントと同じパフォーマンスと機能を維持しながら、Oracle ExadataワークロードをAWSに移行できます。Oracle ExadataとAWS上で稼働しているアプリケーションとの間に低レイテンシーの接続を確立することで、アプリケーションのレイテンシーが短縮されるというメリットがあります。さらに、Oracle Database @AWS を他の AWS サービスと統合して、Oracle Databaseアプリケーションの可用性とスケーラビリティを向上させることができます。 この投稿では、ODBネットワークとAWSにデプロイされている他のリソースとオンプレミスネットワークとの接続に、さまざまなIPルーティングベースのネットワーク接続パターンを実装する方法を示します。このパターンは、IPアドレス空間が重複しておらず、従来のレイヤー3接続が必要な場合に適しています。 この記事で取り上げる接続パターンは次のとおりです。 アプリケーション用の仮想プライベートクラウド（VPC）とODBネットワーク間の1対1の接続 AWS Transit Gateway を使用した、マルチVPCまたはオンプレミスのインフラストラクチャとODBネットワーク間のスケーラブルな単一リージョン接続 AWS Cloud WAN を使用して、マルチVPCまたはオンプレミスのインフラストラクチャとODBネットワーク間のスケーラブルなグローバル接続 本投稿の理解を深めるために、 Amazon Virtual Private Cloud（Amazon VPC） 、 AWS Direct Connect 、 Amazon Route 53 Resolver endpoints 、Transit Gateway、AWS Cloud WANなどのAWSサービスを理解しておくことをお勧めします。 基本の理解 以下は、ネットワーク接続に不可欠な ODB @AWS のコアコンポーネントの概要です。詳細については、 Oracle Database @AWS ユーザーガイド を参照してください。 ODBネットワーク — ODBネットワークは、AWSアベイラビリティーゾーン内のOracleインフラストラクチャをホストするプライベートで独立したネットワークです。標準のVPCとは異なり、ODBネットワークはインターネット接続がなく、ODB @AWS リソースのみをサポートします。 ODBピアリング — ODBピアリングは、ODBネットワークとAmazon VPC間のプライベートネットワーク接続を確立し、アプリケーションが同じネットワーク上にあるかのようにOracle Databaseと通信できるようにします。ODBピアリングはAWS環境とOracle環境をつなぎ、ピアリングされたVPCに接続された特定のAWSネットワークサービスを使用してトラフィックがODBネットワークに到達できるようにするルーティング機能をサポートします。次の図は、ピアリングされたVPCとODBネットワークのピアリング関係を示しています。 ピアリングCIDRによるアクセス制御 — ピアリングCIDRは、ネットワークレベルのアクセス制御リスト（ACL）として機能する設定です。ODBネットワーク内のOracle Databaseリソースに到達できるIP CIDR範囲を指定して管理できます。ピアリングされたCIDRを設定すると、Oracle OCI側で自動化が開始され、特定のプロトコルとポート上の特定のCIDRとの間のトラフィックを許可するリソースが存在するOracle Virtual Cloud Network（Amazon VPCと同等のもの）にリンクされたルートルールとセキュリティルールが設定されます。VPC範囲全体ではなく、特定のサブネットCIDRを含めることで、きめ細かなセキュリティ管理が可能になります。ピアリングCIDRとOCI自動化の詳細については、この記事の後半にある考慮事項のセクションを参照してください。 ピアリングされたVPCの使用パターン — ピアリングされたVPCは複数の目的を果たすことができます。ダイレクトアプリケーションVPCとして機能し、専用のOracleワークロードに最もシンプルなネットワークパスを提供します。あるいは、トランジティブルーティングを使用するトランジットVPCとして機能して、Transit GatewayまたはAWS Cloud WANベースのハブアンドスポークアーキテクチャを介して複数のVPCやオンプレミスネットワークからODBネットワークにアクセスできるようにすることもできます。ピアリングされたVPCは、ワークロードをホストするアプリケーションVPCとしても、他のネットワークをODBネットワークに接続するTransit VPCとしても、両方の役割を同時に果たすことができます。 DNSの構成 ODB@AWS は ODB ネットワーク内で DNS を管理し、仮想マシン (VM) クラスターの完全修飾ドメイン名 (FQDN) を作成します。デフォルトでは、これらは *.oraclevcn.com のドメインパターンを使用します（ myhost.oraclevcn.com など、 oraclevcn.com に追加されるプレフィックスをここで指定できます）。別の方法として、独自の完全なドメイン（ myhost.myodb.com など）を使用してカスタムドメイン名を設定することもできます。どちらのドメイン構成を選択したとしても、これらのドメイン名を解決するには、VPCからのDNSクエリをODBネットワークのDNSインフラストラクチャに転送する必要があります。 DNSアーキテクチャは次のコンポーネントで構成されています。 Route 53リゾルバーのアウトバウンドエンドポイント — DNSクエリをVPCからODBネットワークのDNSインフラストラクチャに転送します。ODBネットワークが作成されると、アウトバウンドエンドポイントがネットワークに接続する必要のあるDNSリスナーIPアドレスが提供されます。 転送ルール — アウトバウンドエンドポイントを使用して、Oracleドメイン（ client.xxxxx.oraclevcn.com など）のクエリをODBネットワークのDNSリスナーIPに直接送信します。ルールは正確なドメインとそのサブドメインの両方に一致します（たとえば、ルールが example.com の場合、 example.com と sub.example.com の両方に一致します）。これらのルールは、&nbsp; AWS Resource Access Manager&nbsp;（AWS RAM） を使用してAWSアカウント間で共有し、Oracleドメイン名を解決する必要のあるVPCに関連付けることができます。ドメインマッチングの詳細については、「 Resolver がクエリ内のドメイン名とルールの一致を判断する際の動作 」を参照してください。 次の図では、設定を簡素化し、ピアリングされたODBネットワークに直接接続するために、アウトバウンドエンドポイントがアプリケーションVPC内にデプロイされています。代替の導入オプションと一元化されたDNS管理設計については、この記事の後半で説明します。DNS 設定の詳細な手順については、「 Configuring DNS for Oracle Database@AWS 」を参照してください。 ネットワーク接続パターン このセクションでは、単純な直接接続からスケーラブルなマルチリージョンアーキテクチャまで、ODB @AWS の3つの一般的なネットワーク接続パターンについて説明します。それぞれのパターンは、さまざまなビジネスニーズとスケーリング要件に対応しています。分かりやすくするために、この図にはアカウントレベルのリソース配置は示されていません。各パターンのアカウント配置に関する考慮事項については、次のセクションで詳しく説明します。 接続パターン1：アプリケーションVPCとODBネットワーク間の直接ピアリング このパターンでは、ピアリングされたVPCをアプリケーションVPCとして使用し、ODBネットワークにピアリングされたVPC内でデータベースアプリケーションを直接ホストします。このアプローチは、アプリケーションとデータベース間の最もシンプルなネットワークパスを提供します。 このパターンは、Oracle Databaseが主に単一のVPC内のアプリケーションにサービスを提供する場合に適しています。次の図に示すように、ODBネットワークは単一のアベイラビリティーゾーン（ODBネットワークの作成時に定義される）にバインドされますが、アプリケーションVPCとそのリソースは複数のアベイラビリティーゾーンにまたがることができます。マルチVPCまたはハイブリッドアーキテクチャの場合は、以降のセクションでODBトランジットVPCパターンを検討してください。 ワークフローは次のコンポーネントで構成されています。 アプリケーションVPCの Amazon Elastic Compute Cloud（Amazon EC2） インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。 VPCルートテーブルは、ODBピアリング接続を介してトラフィックをODBネットワークに転送します。 VPC CIDRはピアリングCIDRリストに含まれているので、Oracle OCI側にはこのトラフィックを許可するための設定がされています。応答トラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。 接続パターン2：Transit Gatewayを使用した単一地域のスケーラブル接続 このパターンでは、単一AWSリージョンの大規模なODBネットワークへのネットワーク接続を検討します。2025年9月時点で、ODBネットワークは1つのVPCとのダイレクトピアリングのみをサポートしています。ODBネットワークと複数のVPC間の1対多のピアリング接続はサポートされていません。Transit Gatewayは、複数のVPCとオンプレミスネットワークの相互接続ポイントとして機能する集中型のネットワークコンポーネントです。2025年9月時点では、ODBネットワーク用の組み込みTransit Gatewayアタッチメントはサポートされていません。ただし、次の図に示すように、ODBネットワークを単一のトランジットVPCにピアリングし、そのトランジットVPCをTransit Gatewayに接続することはできます。 このパターンでは、ピアリングされたVPCは（この記事の前半で説明したように）ODBトランジットVPCとしてのみ機能します。ただし、ピアリングされたVPCの使用パターンで強調されているように、ピアリングされたVPCは必要に応じてワークロードを同時にホストできます。 トランジット VPC へのTransit Gatewayアタッチメントは、単一のアベイラビリティーゾーンのみ、具体的には ODB ネットワークが作成されるのと同じアベイラビリティーゾーンで作成する必要があります。これを強調するために、前の図では、アプリケーションVPCの複数のアベイラビリティーゾーンにまたがるワークロードを示しましたが、トランジットVPCのアベイラビリティーゾーン1にはTransit Gatewayしかアタッチされていません。詳細な設定手順については、「 Configuring Amazon VPC Transit Gateways for Oracle Database@AWS 」を参照してください。 ワークフローは次のコンポーネントで構成されています。 アプリケーションVPCのEC2インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。VPCサブネットのルートテーブルが検索され、パケットはTransit Gatewayアタッチメントを使用してTransit Gatewayに転送されます。 関連するTransit Gatewayのルートテーブルには、宛先をトランジットVPCアタッチメントとするODBネットワークCIDRの静的ルートがあります。 トランジットVPCからのトラフィックは、VPCサブネットルートテーブルのODBピアリングルートを使用し、ODBネットワークに転送されます。 VPC CIDRはピアリングCIDRリストに含まれているので、Oracle OCI側にはこのトラフィックを許可するための設定があります。応答トラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。 接続パターン 3: AWS Cloud WANを使用したマルチリージョンのスケーラブルな接続 このパターンでは、複数の地域やオンプレミスネットワークからODBへのネットワーク接続を検討します。AWS Cloud WANは、動的なルート伝播によりマルチリージョン接続を簡素化します。これを使用して、複数の地域のデータセンター・支社・VPCを1つの統合ネットワークに接続することにより、単一のグローバルネットワークポリシーで制御できます。AWS Cloud WANは組み込みのセグメンテーションをサポートしています。つまり、リージョンやオンプレミスの場所全体でネットワークの分離を簡単に管理できます。ネットワークセグメントを使用すると、グローバルネットワークを別々のネットワークに分割できます。詳細については、 AWS Cloud WANユーザーガイド を参照してください。 2025年9月時点では、ODBネットワーク用の組み込みアタッチメントはAWS Cloud WANではサポートされていません。ODBネットワークをトランジットVPCにピアリングし、そのトランジットVPCをAWS Cloud WANコアネットワークに接続することで、AWS Cloud WANを使用して、ODBネットワークと他の複数のVPC間のネットワークトラフィックをリージョンやオンプレミスの場所にルーティングできます。このパターンでは、ピアリングされたVPCは、ピアリングされたVPCの使用パターンに基づいてトランジットVPCとして機能します。AWS Cloud WANコアネットワークへのトランジットVPCアタッチメントが、ODBネットワークと同じ1つのアベイラビリティーゾーンのみで作成されていることを確認する必要があります。 わかりやすくするために、次の図に示すように、ODBネットワークにアクセスする必要があるすべてのアプリケーションVPCをODBアプリケーションVPCセグメントに関連付け、 Direct Connectゲートウェイ をハイブリッドセグメントに関連付け、両方のセグメント間でセグメント共有を有効にすることを示しました。詳細な設定手順については、「 Configuring AWS Cloud WAN for Oracle Database@AWS 」を参照してください。 ワークフローは次のコンポーネントで構成されています。 アプリケーションVPCのEC2インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。VPCサブネットのルートテーブル検索が行われ、パケットはAWS Cloud WAN VPCアタッチメントを使用してAWS Cloud WANコアネットワークに転送されます。 アプリケーションVPC 1は、関連するアタッチメントCIDRが動的に伝達されるODBアプリケーションVPCセグメントに関連付けられています。ODBネットワークへの組み込み接続は現在、AWS Cloud WANではサポートされていないため、トランジットVPC接続を指す静的ルートを作成します。 トランジットVPCからのトラフィックは、サブネットルートテーブルのODBピアリングルートを使用し、ODBネットワークに転送されます。 前のセクションで強調したように、アプリケーションVPCとオンプレミスネットワークに必要なCIDRは、ODBネットワークのピアリングCIDRリストに追加されます。レスポンストラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。 考慮事項 ODB @AWS ネットワーク接続を実装するときは、アーキテクチャの計画と導入を成功させるために役立つ、技術的および設計上の重要な考慮事項に留意が必要です。 ODBネットワークを構築するときは、接続されたネットワークと重複しないCIDRや、使用できない予約済みのIP範囲など、 IPアドレス空間の要件 を考慮してください。これらのCIDR範囲は、ODBネットワークの作成後は変更できません。 ODBピアリングを設定しても、ODBネットワークCIDR（クライアントCIDRまたはバックアップCIDR）のルートは、ピアリングされたVPCルートテーブルに自動的に追加されません。これらのルートをVPCルートテーブルに追加するには、必要に応じて aws ec2 create-route コマンドを手動で実行する必要があります。具体的な AWSコマンドラインインターフェイス（AWS CLI） コマンドについては、「 Configuring VPC route tables for ODB peering 」を参照してください。 VPCとのODBピアリングを設定すると、プライマリVPC CIDRがピアリングされたCIDRリストに自動的に追加されます。ピアリングされたVPCのセカンダリCIDRは手動で追加する必要があります。2025年9月時点では、自動的に追加されたプライマリCIDRを編集して、このVPCの特定のサブネットCIDRに制限することはできません。ACLとして機能するピアリングされたCIDRリストに、データベースとの通信に必要なすべてのソースCIDR範囲を含めてください。 ピアリングされたCIDRリストにエントリが追加されると、接続を容易にするためにOCI側の自動化が行われます。エントリとして追加されたCIDR範囲へのトラフィックを容易にするために、Virtual Cloud Network（Amazon VPCと同等のもの）に関連するルートルール（同等のVPCルートテーブル）に新しい静的ルートが追加されます。さらに、ICMPトラフィック（MTUパス検出とping用）、ポート22のTCPトラフィック（SSH用）、およびデータベーストラフィックに必要なその他のTCPポートを許可するために、Virtual Cloud Networkに関連するセキュリティルール（AWSセキュリティグループおよび同等のネットワークACL）にエントリが追加されます。 Route 53 Resolverのアウトバウンドエンドポイントは、ピアリングされたVPCにデプロイすることも、ネットワーキングチームが管理する別のVPCにデプロイすることもできます。ハイブリッドDNS解決を容易にするためにアウトバウンドエンドポイントがすでに設定されている場合は、それらも使用できます。いずれの場合も、エンドポイントを含むVPC CIDRがODBのピアリングCIDRリストに追加され、エンドポイントVPCとピアリングされたVPCの間に（Transit GatewayまたはAWS Cloud WANを介して）ネットワーク接続が存在することを確認してください。 Route 53プロファイル を使用すると、AWS RAMを使用して個々のルールを直接共有する代わりに、AWSアカウント間で リゾルバールを共有 できます。 2025年9月時点で、Transit GatewayアタッチメントとTransit VPC用のAWS Cloud WANアタッチメントは、1つのアベイラビリティーゾーン、つまり接続用のODBネットワークと同じアベイラビリティーゾーンでのみ作成する必要があります。 マルチリージョン接続は、クラウドWANの代わりにTransit Gatewayのリージョン間ピアリングを使用して実現することもできます。このアプローチでは、ピアリングされたTransit Gateway間の静的ルーティング設定が必要です。 トランジットVPCは、Transit GatewayとAWS Cloud WANの両方、あるいは複数のTransit GatewayやクラウドWANコアネットワークに同時に接続することはできません。接続するには、1つのトランジットサービスを選択する必要があります。 パターン1のアカウント配置では、ODBネットワークは購入者のアカウントにプロビジョニングされ、AWS RAMを使用して複数のアカウントで共有できます。ただし、2025年9月時点では、ODBネットワークに確立できるピアリング接続は1つだけです。つまり、AWS RAMを使用してODBネットワークを別のアカウントと共有し、その共有アカウントのアプリケーションVPCとのODBピアリング接続を作成できるため、アカウント間のアプリケーションを柔軟にデプロイできます。詳細については、「 Resource sharing in Oracle Database@AWS 」を参照してください。 パターン2と3のアカウント配置では、Transit GatewayとAWS Cloud WAN接続を実装する場合、トランジットVPCとODBネットワークの両方が同じAWSアカウント、特にODBネットワークがプロビジョニングされている購入者アカウントに存在する必要があります。ただし、Transit GatewayとAWS Cloud WANは別のアカウント（中央ネットワークアカウントなど）にあり、必要な接続を確立するためにAWS RAMを使用して購入者のアカウントと共有することができます。 こちらの考慮事項で記載している制限は、2025年9月時点のもので、将来変更される可能性があります。 結論 この記事では、Oracle Database@AWS のネットワーク統合機能について説明しました。これは、企業が AWS クラウドで Oracle Exadata データベースの機能をシームレスに拡張するための、堅牢で用途の広いソリューションを提供します。 Oracle Database @AWS は、組織に Oracle Databaseのデプロイメントをより広範な AWS インフラストラクチャやハイブリッド環境に統合するための柔軟なオプションを提供します。ODBネットワークを単一のVPCと直接ピアリングするか、Transit Gatewayを使用して複数のVPCを接続するか、AWS Cloud WANの一元接続を使用するかを選択することで、特定の要件に最適なネットワーク構成を選択できます。 IP に依存しない接続、重複する IP アドレス空間のサポート、または Zero-ETL や Amazon Simple Storage Service（Amazon S3）アクセスなどの特殊な統合を必要とする場合は、「 Amazon VPC Latticeを使った Oracle Database@AWS ネットワーク接続 」を参照してください。 本投稿へのご意見はコメント欄にお願いします。 翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文は こちら です。

9 月 18 日、Alibaba の Qwen モデル が Amazon Bedrock に追加されました。今回のリリースにより、Amazon Bedrock は、フルマネージドかつサーバーレスな態様で Qwen3 オープンウェイトの 基盤モデル (FM) へのアクセスを追加することで、 モデルの選択肢を拡大 し続けます。このリリースには、 Qwen3-Coder-480B-A35B-Instruct 、 Qwen3-Coder-30B-A3B-Instruct 、 Qwen3-235B-A22B-Instruct-2507 、 Qwen3-32B (Dense) の 4 つのモデルが含まれています。一体的に、これらのモデルは Mixture-of-Experts (MoE) と高密度アーキテクチャの両方を特徴としており、さまざまなアプリケーション要件に柔軟に対応できます。 Amazon Bedrock は、インフラストラクチャ管理を必要とせずに、統合 API を通じて業界をリードする FM へのアクセスを提供します。複数のモデルプロバイダーのモデルにアクセスし、モデルをアプリケーションに統合して、ワークロード要件に基づいて使用量をスケールできます。Amazon Bedrock では、基盤となるモデルのトレーニングにお客様のデータが利用されることは決してありません。Qwen3 モデルが追加されたことで、Amazon Bedrock は次のようなユースケース向けにさらに多くのオプションを提供します: 拡張コンテキスト理解によるコード生成とリポジトリ分析 ビジネスオートメーションのための複数のツールと API をオーケストレートするエージェンティックワークフローの構築 適応型推論のためのハイブリッド思考モードを使用した、AI のコストとパフォーマンスのバランスの実現 Amazon Bedrock の Qwen3 モデル Amazon Bedrock では現在、次の 4 つの Qwen3 モデルが利用可能です。それぞれ異なるパフォーマンスとコスト要件に合わせて最適化されています: Qwen3-Coder-480B-A35B-Instruct – これは、合計 480B のパラメータと 35B のアクティブパラメータを備えた Mixture-of-Experts (MoE) モデルです。コーディングとエージェンティックタスク向けに最適化されており、エージェンティックコーディング、ブラウザ使用、ツール使用などのベンチマークで優れた結果を達成しています。これらの機能があるため、リポジトリ規模のコード解析やマルチステップワークフローオートメーションに適しています。 Qwen3-Coder-30B-A3B-Instruct – これは、合計 30B のパラメータと 3B のアクティブパラメータを備えた MoE モデルです。コーディングタスクと Instruction Following のシナリオに特化して最適化されたこのモデルは、複数のプログラミング言語にわたるコード生成、解析、デバッグにおいて優れたパフォーマンスを発揮します。 Qwen3-235B-A22B-Instruct-2507 – これは、合計 235B のパラメータと 22B のアクティブパラメータを備えた、Instruction Tuning された MoE モデルです。コーディング、数学、一般的な推論タスク全体で競争力のあるパフォーマンスを提供し、機能と効率のバランスをとっています。 Qwen3-32B (Dense) – これは、32B のパラメータを備えた Dense モデルです。モバイルデバイスやエッジコンピューティングのデプロイなど、一貫したパフォーマンスが重要なリアルタイム環境やリソース制約のある環境に適しています。 Qwen3 のアーキテクチャおよび機能面の特徴 Qwen3 モデルには、アーキテクチャおよび機能面で、いくつかの特徴が導入されています。 MoE と Dense アーキテクチャの比較 – Qwen3-Coder-480B-A35B、Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507 などの MoE モデルは、リクエストごとにパラメータの一部のみをアクティブ化することで、効率的な推論で高いパフォーマンスを実現します。Dense Qwen3-32B はすべてのパラメータをアクティブ化することで、より一貫性があり予測可能なパフォーマンスを実現します。 エージェンティック機能 –&nbsp; Qwen3 モデルは、1 回のモデル呼び出しでマルチステップの推論と構造化プランニングを処理できます。エージェントフレームワークに統合すると、外部ツールや API を呼び出す出力を生成できます。また、これらのモデルは、長時間のセッションにわたって拡張コンテキストを維持します。さらに、外部環境との標準化された通信を可能にするために、ツール呼び出しをサポートしています。 ハイブリッド思考モード – Qwen3 は、思考モードと非思考モードという 2 つのモードをサポートするハイブリッドな問題解決アプローチを導入しています。思考モードでは、ステップバイステップの推論を適用して、最終的な答えを出します。これは、より深い思考を必要とする複雑な問題に最適です。一方、非思考モードでは、深さよりもスピードが重視される、それほど複雑ではないタスクについて、迅速かつほぼ瞬時の応答を提供します。これは、デベロッパーがパフォーマンスとコストのトレードオフをより効果的に管理するのに役立ちます。 ロングコンテキスト処理 – Qwen3-Coder モデルは、ネイティブに最大 256K トークン、外挿法を使用する場合には最大 100 万トークンの拡張コンテキストウィンドウをサポートしています。これにより、モデルはリポジトリ全体、大規模な技術ドキュメント、または長い会話履歴を単一のタスク内で処理できます。 各モデルを使用すべき場合 4 つの Qwen3 モデルは、それぞれ異なるユースケースに対応します。Qwen3-Coder-480B-A35B-Instruct は、複雑なソフトウェアエンジニアリングシナリオ向けに設計されています。高度なコード生成、リポジトリレベルの分析などのロングコンテキスト処理、外部ツールとの統合に適しています。Qwen3-Coder-30B-A3B-Instruct は、コード補完、リファクタリング、プログラミング関連のクエリへの回答などのタスクに特に効果的です。複数のドメインにわたる汎用的なパフォーマンスが必要な場合は、Qwen3-235B-A22B-Instruct-2507 が適しています。MoE アーキテクチャの効率性の利点を活用しながら、強力な汎用推論機能と Instruction Following 機能を提供します。Qwen3-32B (Dense) は、一貫したパフォーマンス、低レイテンシー、コスト最適化が重要なシナリオに適しています。 Amazon Bedrock での Qwen モデルの開始方法 Qwen モデルの使用を開始するには、 Amazon Bedrock コンソール で、ナビゲーションペインの [設定と学習] セクション から [モデルアクセス] を選択します。その後、Qwen モデルに移動してアクセスをリクエストします。ナビゲーションペインの [チャット/テキストプレイグラウンド] セクションでは、プロンプトを使用して新しい Qwen モデルを迅速にテストできます。 Qwen3 モデルをアプリケーションに統合するために、任意の AWS SDK を使用できます。AWS SDK には、Amazon Bedrock の InvokeModel および Converse API へのアクセスが含まれています。また、これらのモデルは、Amazon Bedrock をサポートする任意のエージェンティックフレームワークで使用でき、 Amazon Bedrock AgentCore を利用してエージェントをデプロイできます。例えば、 Strands Agents を使用して構築された、ツールアクセスを備えたシンプルなエージェントの Python コードを次に示します: from strands import Agent from strands_tools import calculator agent = Agent( model="qwen.qwen3-coder-480b-instruct-v1:0", tools=[calculator] ) agent("Tell me the square root of 42 ^ 9") with open("function.py", 'r') as f: my_function_code = f.read() agent(f"Help me optimize this Python function for better performance:\n\n{my_function_code}") 今すぐご利用いただけます Qwen モデルは現在、次の AWS リージョン でご利用いただけます: Qwen3-Coder-480B-A35B-Instruct は、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、東京)、および欧州 (ロンドン、ストックホルム) リージョンでご利用いただけます。 Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507、and Qwen3-32B は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、東京)、欧州 (アイルランド、ロンドン、ミラノ、ストックホルム)、南米 (サンパウロ) の各リージョンでご利用いただけます。 今後のアップデートについては、 詳細なリージョンリスト をご確認ください。インフラストラクチャのセットアップやキャパシティプランニングは不要で、すぐにテストと構築を開始できます。詳細については、 Amazon Bedrock の製品ページ の Qwen と Amazon Bedrock の料金 ページにアクセスしてください。 今すぐ Amazon Bedrock コンソール で Qwen モデルをお試しいただき、 AWS re:Post for Amazon Bedrock または通常の AWS サポートチャネルを通じてフィードバックをお寄せください。 – Danilo 原文は こちら です。

3 月、 Amazon Web Services (AWS) は、 Amazon Bedrock でフルマネージド型の一般提供モデルとして DeepSeek-R1 をリリースし、サーバーレスで DeepSeek-R1 を提供する初のクラウドサービスプロバイダー となりました。それ以来、お客様は Amazon Bedrock を通じて DeepSeek-R1 の機能を活用して、 生成 AI アプリケーションを構築し、Bedrock の堅牢なガードレールと安全な AI デプロイのための包括的なツールの恩恵を受けてきました。 9 月 18 日、 DeepSeek-V3.1 が Amazon Bedrock でフルマネージド基盤モデルとして利用可能になったことをお知らせいたします。DeepSeek-V3.1 は、詳細なステップバイステップの分析のための思考モード (思考連鎖推論) と、より迅速な応答のための非思考モード (直接回答) を切り替えるハイブリッドオープンウェイトモデルです。 DeepSeek によると、DeepSeek-V3.1 の思考モードは、DeepSeek-R1-0528 と比較して、同等の回答品質と優れた結果、複雑な検索タスクのためのより強力なマルチステップ推論、思考効率の大幅な向上を実現します。 ベンチマーク DeepSeek-V3.1 DeepSeek-R1-0528 Browsecomp 30.0 8.9 Browsecomp_zh 49.2 35.7 HLE 29.8 24.8 xbench-DeepSearch 71.2 55.0 Frames 83.7 82.0 SimpleQA 93.4 92.3 Seal0 42.6 29.7 SWE-bench Verified 66.0 44.6 SWE-bench Multilingual 54.5 30.5 Terminal-Bench 31.3 5.7 (c) https://api-docs.deepseek.com/news/news250821 DeepSeek-V3.1 モデルは、ツール使用とエージェントタスクにおいて、トレーニング後の最適化を通じて、以前の DeepSeek モデルと比較してパフォーマンスが大幅に改善されました。DeepSeek-V3.1 は、100 超の言語をサポートし、ほぼネイティブの流暢さを備えており、大規模な単一言語または並列コーパスが不足している、リソースの少ない言語における機能が大幅に改善されています。意思決定プロセスの可視性を維持しながら、以前の DeepSeek モデルと比較して高い精度を提供し、ハルシネーションが軽減されたグローバルアプリケーションを構築できます。 このモデルを使用する主なユースケースを次に示します: コード生成 – DeepSeek-V3.1 は、ソフトウェアエンジニアリングのベンチマークとコードエージェント機能の改善により、コーディングタスクで優れたパフォーマンスを発揮します。そのため、自動コード生成、デバッグ、ソフトウェアエンジニアリングワークフローに最適です。コーディングベンチマークで優れたパフォーマンスを発揮すると同時に、質の高い結果を効率的に提供します。 エージェンティック AI ツール – このモデルは、トレーニング後の最適化を通じてツール呼び出し機能が強化されており、ツール使用とエージェンティックワークフローで優れたパフォーマンスを発揮します。構造化されたツール呼び出し、コードエージェント、検索エージェントをサポートしており、自律型 AI システムの構築に最適な選択肢となっています。 エンタープライズアプリケーション – DeepSeek モデルは、さまざまなチャットプラットフォームや生産性向上ツールに統合されており、ユーザーインタラクションを強化し、カスタマーサービスのワークフローをサポートします。このモデルは、多言語機能と文化面での配慮を備えているため、グローバルなエンタープライズアプリケーションに適しています。 前回の記事 で言及したように、公開されているモデルを実装する場合は、本番環境で実装する際にデータプライバシー要件を慎重に考慮し、出力のバイアスがないか確認して、データセキュリティ、 責任ある AI 、 モデル評価 の観点から結果をモニタリングしてください。 Amazon Bedrock の エンタープライズグレードのセキュリティ機能 にアクセスし、 Amazon Bedrock のガードレール を使用して、アプリケーション要件と責任ある AI ポリシーに合わせてカスタマイズされた安全策を実装できます。また、 Amazon Bedrock モデル評価ツール を使用してモデルを評価および比較し、ユースケースに最適なモデルを特定することもできます。 Amazon Bedrock で DeepSeek-V3.1 モデルの使用を開始する DeepSeek-V3.1 モデルを初めて使用する場合、 Amazon Bedrock コンソール に移動し、左側のナビゲーションペインの [Bedrock の設定] で [モデルアクセス] を選択します。フルマネージド DeepSeek-V3.1 モデルにアクセスするには、 [DeepSeek] セクションで [DeepSeek-V3.1] へのアクセスをリクエストしてください。Amazon Bedrock でモデルにアクセスできるようになります。 次に、Amazon Bedrock で DeepSeek-V3.1 モデルをテストするために、左側のメニューペインの [プレイグラウンド] で [チャット/テキスト] を選択します。その後、左上の [モデルを選択] を選択し、カテゴリとして [DeepSeek] を、モデルとして [DeepSeek-V3.1] を選択します。そして、 [適用] を選択します。 選択した DeepSeek-V3.1 モデルを使用して、技術アーキテクチャの意思決定に関する次のプロンプト例を実行します。 Outline the high-level architecture for a scalable URL shortener service like bit.ly.Discuss key components like API design, database choice (SQL vs.NoSQL), how the redirect mechanism works, and how you would generate unique short codes. [モデル推論] モードを切り替えることで、思考のオン/オフを切り替えて、最終的な結論に至る前に応答の思考連鎖を生成できます。 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK を使用して、モデルにアクセスすることもできます。このモデルは、 InvokeModel と Converse API の両方をサポートします。複数のユースケースとさまざまなプログラミング言語に対応した 幅広いコード例 をご覧いただけます。 詳細については、AWS ドキュメントの「 DeepSeek model inference parameters and responses 」にアクセスしてください。 今すぐご利用いただけます DeepSeek-V3.1 は現在、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (ムンバイ)、欧州 (ロンドン)、欧州 (ストックホルム) の AWS リージョンでご利用いただけます。今後のアップデートについては、 詳細なリージョンリスト をご確認ください。詳細については、 Amazon Bedrock の製品ページの DeepSeek と Amazon Bedrock の料金ページ をご覧ください。 Amazon Bedrock コンソール で DeepSeek-V3.1 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。朝晩の暑さが和らいで秋が近づいてきているのをひしひしと感じていますが、生成 AI 系のアップデートは多数のモデル追加や現場課題に特化したワークショップ開催などアツい話題が盛りだくさんです。 また、来る9/24 には「AWS Amazon Nova Ignite」 が開催されます（ 申し込みはこちら ）。多彩な目的に利用可能な Amazon Nova の実際のお客様活用事例やデモンストレーションが予定されておりますので、ぜひご参加ください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、9 月 15 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 【開催報告】店舗業務にフォーカス！小売業界向け AI エージェント活⽤ワークショップ 」を公開 小売業界の現場課題に特化したAIエージェント活用ワークショップが開催されました。本ワークショップでは、在庫管理の自動化、顧客対応チャットボットの構築、売上予測システムの実装など、店舗運営に直結する実践的なユースケースが紹介されました。参加いただいたお客様からは「店長エージェントの実装を検討する中で、自社ソリューションの組み合わせなど、試したいアイデアが出ました」、「他社の方の事例を聞いたり、小売業界ならではの共通した課題への気づきを得られてかなり勉強になりました」といったお声をいただきました。また、小売業界特有のデータプライバシー要件やリアルタイム処理の必要性についても詳しく解説されており、業界特化型AI導入の実践的なガイドとして価値の高い内容となっています。 ブログ記事「 SAP 対応エージェンティック AI アシスタントを AWS の生成 AI サービスで実現 」を公開 SAPシステムと連携するエージェンティックAIアシスタントの構築方法について解説した記事です。Amazon Bedrock、Amazon Q Business、AWS Lambdaを組み合わせて、SAP内のデータを自然言語で照会・操作できるエージェンティックAIアシスタントの構築方法を詳細に解説しています。従来のSAP操作では専門知識が必要でしたが、このソリューションにより「今月の売上を教えて」「在庫が少ない商品をリストアップして」といった自然な会話でSAPデータにアクセスできるようになります。セキュリティ面では、SAP側の権限管理と連携したアクセス制御も実装されており、企業の機密情報を適切に保護しながらAIの恩恵を受けられる設計となっています。 ブログ記事「 新しい料金プランと新エージェント「Auto」の発表 」を公開 Kiro に新しい料金プランと新エージェント「Auto」が発表されました。この記事では、より柔軟な料金体系と、自動化されたコード生成機能を提供する新しいエージェント機能について詳しく解説しています。各タスクにおいて性能・効率・出力品質を最適化することで、開発者の生産性向上に貢献する機能です。 サービスアップデート Amazon Q Developer が リモート MCP サーバーをサポート Amazon Q Developer がリモート Model Context Protocol (MCP) サーバーをサポートするようになりました。これにより一元化されたサーバーへの移行でコンピューティングリソースの使用量削減とアクセス・セキュリティの適切な管理が可能になります。HTTP対応で、OAuth認証をサポートするAtlassianやGitHubなどのMCPサーバーとの統合も実現しました。 Amazon Lex で生成AI による自然言語処理が8言語で利用可能に Amazon Lex の生成AI機能が日本語を含む8つの言語で新たに利用できるようになりました。多言語対応により、グローバルなチャットボットやボイスアシスタントの構築がより容易になります。この機能はAmazon Connectが利用可能な10のAWSリージョン（欧州、米国、アジアパシフィック、カナダ）で提供されています。 AWS SiteWise で MCP サーバーモデリング機能を提供開始 AWS SiteWise に Model Context Protocol (MCP) サーバーモデリング機能が追加されました。このサーバーは組み込みのドメイン検証機能と自動モデリング機能を備え、APIの詳細知識なしで産業データモデリングを簡素化します。既存のAWS IoT SiteWise機能をサポートしながら、新しい会話型インターフェースも追加しています。産業知識とベストプラクティスが組み込まれており、適切な単位、データタイプ、品質指標が自動適用されるため、産業モデルが最初から生産準備が整い、時間とリソースを節約できます。異常検出や資産オンボーディングの合理化などの高度な機能も容易に実装可能です。 AWS Labs MCPオープンソースリポジトリ からダウンロードできます。 Amazon Bedrock で OpenAI のオープンウェイトモデルが新しいリージョンで利用可能に OpenAI のオープンウェイトモデルを8つの新リージョンに拡張しました。従来の米国西部(オレゴン)に加え、米国東部(バージニア北部)、アジアパシフィック(東京・ムンバイ)、欧州(ストックホルム・アイルランド・ロンドン・ミラノ)、南米(サンパウロ)で利用可能になりました。この拡張により、世界中の顧客はAIモデルへのアクセス性が向上し、レイテンシー短縮とパフォーマンス向上が実現します。 Amazon Bedrock で Qwen3 モデルがフルマネージドサービスとして利用可能に Alibaba Cloud の Qwen3 モデルファミリーが Amazon Bedrock でフルマネージドサービスとして提供開始されました。新モデルには、Qwen3-Coder-480B-A35B-Instruct、Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507、Qwen3-32Bが含まれます。これらは高密度アーキテクチャと専門家混合アーキテクチャを特徴とし、インフラ管理不要で高度なAIアプリケーション構築が可能です。Coderモデルはエージェントコーディングや複雑なソフトウェアエンジニアリングに優れ、235Bモデルは一般的推論に効率的、32Bモデルは幅広い計算タスクに適しています。これらのモデルは米国、アジアパシフィック（東京含む）、欧州、南米の複数のAWSリージョンで利用可能です。 Amazon Bedrock で DeepSeek v3.1 モデルがフルマネージドサービスとして利用可能に DeepSeek v3.1 モデルが Amazon Bedrock で利用できるようになりました。このオープンウェイトモデルは、詳細な思考モードと迅速な非思考モードの切り替え機能を備え、多言語サポートにより精度向上と幻覚軽減を実現しています。 Amazon Bedrock で Stability AI Image Services が一般提供開始 Stability AI Image Services が Amazon Bedrock で一般提供開始されました。このサービスは9つの専用画像編集ツールを含み、アイデアから完成品まで正確かつ柔軟に実現できます。編集ツール（背景削除、オブジェクト消去、検索と置換、色変更）とコントロールツール（構造、スケッチ、スタイルガイド、スタイル転送）の2種類の機能があり、画像の特定部分の編集や既存画像に基づくバリエーション生成が可能です。このサービスは米国西部（オレゴン）、米国東部（バージニア北部、オハイオ）で利用できます。 Meta Llama モデルのオンデマンドデプロイメントが Amazon Bedrock で利用可能に カスタム Meta Llama モデルのオンデマンドデプロイメント機能が追加されました。これにより、特定の用途に最適化されたモデルを事前にコンピューティングリソースをプロビジョニングする必要がなく、使用分のみの支払いでリアルタイム処理が可能となり、コスト削減につながります。 Amazon OpenSearch Serverless でディスク最適化ベクトル機能を提供開始 Amazon OpenSearch Serverless にディスク最適化ベクトル機能が追加されました。この機能により、精度やリコール率を維持しながら、ベクター検索の費用対効果の高いソリューションが提供できるようになります。ユーザーはメモリ最適化とディスク最適化のベクターストレージから選択できるようになり、ディスク最適化オプションでは若干のレイテンシー増加と引き換えに低コストで高品質な検索が可能です。これはミリ秒未満の応答時間が重要でないセマンティック検索やレコメンデーションシステムなどに最適です。 AWS Neuron 2.26 を発表 AWS Neuron の最新バージョン 2.26 がリリースされました。Inferentia および Trainium チップでの機械学習推論とトレーニングの性能がさらに向上しています。新バージョンでは、Flux.1-dev画像生成モデルやLlama 4のバリアントをTrainium2インスタンスにデプロイ可能になり、エキスパート並列処理サポート（ベータ）も導入されました。 Amazon SageMaker HyperPod でオートスケーリング機能を提供開始 Amazon SageMaker HyperPod にKarpenter を利用したオートスケーリング機能が追加されました。機械学習ワークロードの需要に応じて自動的にリソースを調整することで、コスト効率と性能の最適化が実現されます。 Amazon SageMaker HyperPod で Slurm 対応のヘルスモニタリングエージェントを提供開始 Slurmクラスターのジョブ自動再開機能と連携し、障害発生時も最後のチェックポイントから処理を継続できるため、大規模モデルのトレーニングを中断なく何週間も実行可能です。このハンズフリーリカバリー機能により、障害による時間とコストのロスを防ぎます。SageMaker HyperPod を利用可能なすべてのリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近感動したものは帯広の豚丼です。

本記事は 2025年9月4日に公開された Amazon CloudFront now supports IPv6 origins for end-to-end IPv6 を翻訳したものです。 組織が IPv4 アドレス空間の制限を超えるにつれて、IPv6 の採用は世界中で加速し続けています。Amazon Web Services (AWS) では、長い間、エンドユーザーから Amazon CloudFront ネットワークまでについては IPv6 をサポートしてきました。これにより、エンドユーザーがレイテンシーを削減し、パフォーマンスを向上させ、最新のモバイルネットワークにアクセスできるよう支援してきました。今、私たちはそれをさらに一歩進めることができることを嬉しく思います。本日より、CloudFront はエッジからオリジンまで IPv6 接続をサポートするようになり、真のエンドツーエンドの IPv6 配信パスを実現できるようになりました。これにより、エンドユーザーは CloudFront をウェブアプリケーションの IPv6 と IPv4 のデュアルスタックインターネットゲートウェイとして使用し、コンテンツアクセラレーションを実現できます。 なぜこれが重要か？ IPv6 は、最近のほとんどのモバイルネットワークの基盤となるトランスポートプロトコルであり、ブロードバンドトラフィックに占める割合は増加の一途をたどっています。IPv6 をオリジンまで有効化することで、配信チェーン全体でプロトコルの一貫性を維持し、デュアルスタックの複雑さによる運用上のオーバーヘッドを軽減し、より確定的で、オブザーバビリティに優れた、パフォーマンスの高いトラフィックフローを実現できます。CloudFront のエンドユーザーにとって、これらの利点は、ページロードの高速化、ストリーミングの安定化、IPv4 リソースの代替として引き続き機能する配信アーキテクチャにつながります。 CloudFront アプリケーションにおける IPv6 のメリット CloudFront は IPv6 経由のオリジンをサポートするようになったため、エンドユーザーからオリジンサーバーに至るまで、エンドツーエンドの IPv6 接続を実現できます。これにより、従来の IPv4 ベースの配信に比べて、技術面および運用面でさまざまなメリットが得られます。 1. NAT のオーバーヘッドを排除し、パフォーマンスを向上させます IPv4 ネットワークは、ネットワークアドレス変換 (Network Address Translation: NAT)、特に ISP や携帯電話事業者が使用するキャリアグレードの NAT に大きく依存しています。これらの NAT 層は、接続設定の遅延を招き、ポートの可用性を制限し、パケットドロップの原因となる可能性があります。IPv6 では NAT が不要になり、エンドユーザー、CloudFront、オリジン間の直接のエンドツーエンド接続が可能になります。その結果、特に IPv6 の採用が最も多いモバイルファーストの市場では、レイテンシーが減り、ページの読み込みが速くなり、ユーザーエクスペリエンスが向上します。 2. より効率的なパケット処理 IPv6 では、オプションの制御情報として、簡略化された固定長のヘッダーと拡張ヘッダーが導入されています。これにより、ルーター、ファイアウォール、ロードバランサー、CloudFront ノードのパケット解析と転送がより効率的になります。IPv6 は、特にディープパケットインスペクションやトラフィックシェーピングを実行するシステムにおいて、パケットごとの処理オーバーヘッドを削減し、パケット転送や検査中のあいまいさを解消します。ルーターによる経路内でのフラグメンテーションが可能な IPv4 とは異なり、IPv6 はフラグメンテーションの責任をすべてソースホストに委任します。このアーキテクチャ上の制約により、再送信回数が減り、転送パス全体で最適なセグメントサイズが維持されるため、転送パフォーマンスが向上します。その結果、IPv6 では、特に CloudFront とオリジンの間の長距離または高レイテンシーのリンクで、より安定してパフォーマンスの TCP 接続が可能になります。これは、再送信を減らし、トランスポートパス全体で最適なセグメントサイズを維持することによって実現されます。 3. 予測可能な伝送と輻輳制御 IPv6 ではエンドツーエンドのパス MTU 検出 (PMTUD) が実行され、フラグメンテーションの責任はすべてソースホストに委任されます。このアーキテクチャ上の制約により、伝送の予測性が向上し、MTU の不一致によるパケットのドロップやフラグメント化のリスクが最小限に抑えられます。IPv6 は 特に CloudFront と AWS 以外のオリジン間の長距離または高レイテンシーのパスでは、TCP の安定性とスループットを向上させます。これは、再送信を最小限に抑え、エンドツーエンドで最適なセグメントサイズを維持することによって実現されます。AWS オリジンについても、現在、ジャンボフレームサポートなどの AWS バックボーンネットワークを通じて同様の成果が得られています。AWS エッジロケーションと AWS リージョンのアプリケーションエンドポイントの間でジャンボフレームを有効にすると、CloudFront は各パケットでより大きなペイロードを送受信できるようになります。ジャンボフレームのサポートにより、エンドユーザーとアプリケーション間のデータ転送に必要な合計時間が短縮されます。 4. 接続スケーラビリティの向上 IPv4 では、NAT によってオリジン IP アドレスごとに使用できるソースポートの数が減るため、CloudFront ノードがオリジンと同時に確立できる接続の数が制限されます。この制約は、何千もの同時リクエストを効率的に処理しなければならないトラフィックの多い環境では問題になる可能性があります。この機能は、HTTP/2 などのプロトコルを使用する場合に特に役立ちます。このようなプロトコルでは、1 つの接続で複数のストリームを多重化し、接続を再利用することが、パフォーマンスを最大化し、レイテンシーを最小限に抑えるために不可欠です。 開始方法 この度、CloudFront ディストリビューションに関連付けるオリジンとして IPv6 を使用するように設定できるようになりました。この新機能では、IPv4 (デフォルト)、IPv6 、またはデュアルスタック ( IPv4 と IPv6 ) のいずれかを選択できます。既存のオリジンについては、CloudFront は引き続き IPv4 を使用します。デュアルスタックを使用する場合、CloudFront は IPv4 と IPv6 の IP アドレスを自動的に選択して、トラフィックが両方のオリジンで均等に分散されるようにします。 CloudFront コンソールまたは CloudFront API を使用して CloudFront ディストリビューションを作成または更新し、オリジンへの IPv6 接続を設定できます。この投稿では、IPv6 をサポートするオリジンの作成方法を説明し、既存のオリジンで IPv6 を安全に有効化するためのベストプラクティスを探ります。始める前に、オリジンが IPv6 またはデュアルスタック接続をサポートしていることを確認してください。オリジンは、カスタムオリジンでも、 Elastic Load Balancers 、 Amazon API Gateway 、 AWS Lambda の関数 URL などの IPv6 をサポートする AWS サービスでもかまいません。 IPv6 オリジンを使用した新規 CloudFront ディストリビューションの作成 CloudFront コンソールで、CloudFront ディストリビューションの作成を選択します。 Step 1: Get started ディストリビューション名を入力し、その他のオプションパラメータを入力してから、 [Next] を選択してステップ 2 に進みます。 Step 2: Specify origin オリジンのタイプを選択し、オリジン情報を入力します。IPv6 を設定するには、 Setting パネルで [customize origin settings] を選択します。 オリジン IP アドレスタイプ設定に IPv6 または Dualstack を選択し、 [Next] を選択します。 Step 3: Enable security AWS WAF を有効にしてアプリケーションを保護し、 [Next] を選択します。 Step 4: Review and create 設定内容を確認したのち、 [Create distribution] ボタンを選択し、ディストリビューションを作成します。 既存の CloudFront ディストリビューションに新規の IPv6 オリジンを追加する 既存の CloudFront ディストリビューションに新しい IPv6 オリジンを追加するには、ディストリビューションを選択してディストリビューション設定を開き、 [Origins] タブを選択して [Create Origin] を選択します。 [Additional settings] を展開し、Origin IP address type で [IPv6] または [Dualstack] オプションを選択して、オリジンへの IPv6 接続を有効にします。オリジンを作成したら、新しいオリジンを指すようにビヘイビアを追加または更新します。 既存のオリジンで IPv6 を有効化する CloudFront 継続的デプロイ を使用すると、変更をオリジン設定に安全に移行できます。CloudFront 継続的デプロイでは、デプロイポリシーを使用してリクエストをステージングディストリビューションにルーティングし、変更を検証してプロモートすることで、変更を安全にテストできます。このアプローチの詳細については、CloudFront の ドキュメント を参照してください。 オリジンへの IPv6 接続の検証 メトリクスまたはアプリケーションログを使用して、オリジンでの IPv6 トラフィックを検証します。このケースでは、オリジンとして Application Load Balancer (ALB) を使用し、IPv6 Requests メトリクスを使って検証しました。 まとめ モバイルネットワークやグローバルネットワークで IPv6 の採用が拡大するにつれて、エンドユーザーから Amazon CloudFront、そしてオリジンに至るまで、エンドツーエンドの IPv6 を有効にすることで、IPv4 では対応できないパフォーマンスとアーキテクチャ上の利点が得られます。NAT のオーバーヘッドがなくなり、ルーティングとフローの可視性が向上し、固定ヘッダーと信頼性の高い パス MTU 検出によってパケット処理が合理化されます。CloudFront は IPv4 と IPv6 の両方に最適化されていますが、IPv6 の利点は配信のファーストマイル、 ラストマイルで最も顕著になります。IPv6 をエンドツーエンドで採用することで、スケーラブルで高性能で、将来を見据えたコンテンツ配信の基盤が築かれます。 Amazon CloudFront で IPv6 をエンドツーエンドで有効にすることはもはやオプションではありません。これは、レイテンシーの低減、耐障害性の向上、将来を見据えたスケーラビリティを実現するための基本的なステップです。まだ CloudFront ディストリビューションの IPv6 サポート を有効にしていない場合は、今すぐ IPv6 サポートを有効にしてください。 翻訳は Solutions Architect の山本 大貴が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 つい先週、趣味のパデルで、右手を骨折してしまいました。スポーツや仕事がしにくく、こういう時は大人しく過ごそうということで、最近出版された「 AWS 生成 AI アプリ構築実践ガイド 」を購入して読み始めました。Amazon Bedrock Agents／Amazon Bedrock AgentCore についても記載され、内容も充実しており、参考になる一冊です。読書の秋にじっくり AWS を学んでみるのはいかがでしょうか。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年9月15日週の主要なアップデート 9/15(月) AWS Organizations がメンバーアカウントのアカウント状態情報を提供開始 AWS Organizations で新しい State フィールドが追加され、メンバーアカウントの状態をより詳細に把握できるようになりました。従来の Status フィールドでは分からなかった「AWS による強制停止 (SUSPENDED)」「クローズ処理中 (PENDING_CLOSURE)」「クローズ済み (CLOSED)」などの細かい状態が確認可能です。複数のアカウントを管理する組織では、各アカウントの正確な状況を把握することで適切な対応が取れるようになります。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock でカスタム Meta Llama モデルのオンデマンドデプロイメントを発表 Amazon Bedrock で、カスタマイズした Meta Llama 3.3 モデルのオンデマンドデプロイメントが可能になりました。従来は常時稼働するサーバーが必要でしたが、今回のアップデートにより使用時のみリソースを起動し、利用分だけの支払いでコストを大幅削減できます。AI チャットボットや文書生成システムなど、利用頻度が不定期なアプリケーションに最適です。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker HyperPod が Slurm クラスターのヘルスモニタリングエージェントサポートを発表 Amazon SageMaker HyperPod の Slurm クラスターでヘルスモニタリングエージェント機能が利用可能になりました。この機能は GPU や Trainium ノードの状態を常時監視し、ハードウェア障害を検出すると自動的にノードを交換します。従来は訓練中に障害が発生すると手動対応が必要でしたが、今回のアップデートにより自動レジューム機能と連携してチェックポイントから訓練を継続できるようになりました。大規模言語モデルなど数週間かかる訓練でも中断リスクを大幅に軽減し、コストと時間のロスを削減できます。詳細は こちらのドキュメントをご参照ください。 9/16(火) Amazon OpenSearch Service が Star-Tree Index を発表 Amazon OpenSearch Service で Star-Tree Index という新機能が利用開始となりました。この機能により、大量データの集計処理が大幅に高速化され、従来時間がかかっていた複雑な分析クエリもサブ秒で応答できるようになります。データを事前に集計して保存するため、リアルタイムダッシュボードや監視システム、パーソナライゼーション機能などで威力を発揮します。詳細は こちらのドキュメントをご参照ください。 Amazon S3 が汎用バケットで条件付き削除をサポート開始 Amazon S3 の汎用バケットで条件付き削除機能が追加されました。HTTP if-match ヘッダーと ETag を使用し、オブジェクトが変更されていない場合のみ削除を実行できます。複数のユーザーが同時にファイルを操作する環境で、誤ってファイルを削除してしまうリスクを大幅に軽減できます。従来は削除前にオブジェクトの状態を確認する仕組みがなく、競合状態での誤削除が課題でした。全リージョンで追加コストなしで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Lex が 8 つの新しい言語で生成 AI ベースの強化された自然言語理解を提供 Amazon Lex が大規模言語モデル (LLM) を活用した自然言語理解機能を日本語を含む 8 つの新言語で提供開始しました。これまでチャットボットが理解しにくかった複雑な発話や、スペルミスがある入力でも正確に処理できるようになります。例えば「妻と子供 2 人と私でフライト予約したい」と話すと、4 人分の予約として正しく理解してくれます。東京リージョンなど 10 の商用リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 9/17(水) AWS Network Firewall がコンソール、モニタリング、セキュリティ機能を強化 AWS Network Firewall で監視機能とセキュリティ機能が強化されました。監視ダッシュボードでは Amazon S3 や DynamoDB などの AWS サービスへのトラフィック状況を詳細に可視化でき、IP アドレス別やプロトコル別の分析も可能になります。また新しい TLS Inspection のセッションホールディング機能により、悪意のある接続先への通信をより確実にブロックできるようになりました。詳細は こちらのドキュメントをご参照ください。 AWS Budgets でカスタム期間がサポートされるようになりました AWS Budgets でカスタム期間の予算設定が可能になりました。従来の月次や四半期などの固定期間ではなく、任意の開始日と終了日を指定できます。月の途中から始まる 3 ヶ月プロジェクトなども一つの予算で管理でき、複数月に分けて計算する手間が不要になりました。詳細は こちらのドキュメントをご参照ください。 9/18(木) Qwen3 モデルが Amazon Bedrock で完全マネージド型として利用可能になりました Amazon Bedrock に Qwen3 モデル 4 種類が追加されました。コーディング特化の Coder モデルや汎用推論用モデルなど、用途に応じて選択できます。インフラ管理が不要なフルマネージドサービスとして提供されるため、AI アプリケーション開発に集中できます。東京リージョンを含む複数リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 OpenAI オープンウェイトモデルが AWS Bedrock で新しいリージョンに拡張 AWS Bedrock で OpenAI のオープンウェイトモデルが 8 つの新リージョンに拡大しました。東京、ロンドン、ムンバイなど世界各地で利用可能となり、これまでオレゴンリージョンのみだった制限が解消されます。ユーザーに近いリージョンでの実行により、レイテンシが大幅に改善され、AI アプリケーションの応答速度が向上します。また、データ所在地の要件に対応でき、コンプライアンスを重視する企業でも安心して活用できます。詳細は こちらの Blog 記事をご参照ください。 DeepSeek-V3.1 モデルが Amazon Bedrock でフルマネージドサービスとして利用可能に Amazon Bedrock で DeepSeek-V3.1 モデルが利用可能になりました。このモデルは詳細分析用の thinking モードと高速応答用の non-thinking モードを切り替えできるのが特徴です。従来モデルと比較してハルシネーション (誤った情報生成) が減少し、精度が向上しています。ソフトウェア開発や数学的推論、データ分析などの業務で活用でき、 AI エージェント構築やプロセス自動化にも最適です。オレゴン、東京、ムンバイ、ロンドン、ストックホルムリージョンで提供開始されています。詳細は こちらの Blog 記事をご参照ください。 Stability AI Image Services が Amazon Bedrock で利用可能に Amazon Bedrock で Stability AI Image Services が利用開始となりました。背景除去やオブジェクト消去など 9 つの画像編集ツールが使えるようになり、API 経由で高度な画像加工が可能です。従来は専用ソフトが必要だった画像編集作業を、クラウドサービスで簡単に自動化できるため、EC サイトの商品画像作成やマーケティング素材の制作が効率化されます。オレゴン、バージニア北部、オハイオリージョンで提供中です。 Amazon Q Developer CLI がリモート MCP サーバーのサポートを発表 Amazon Q Developer CLI がリモート MCP サーバーのサポートを開始しました。従来はローカルでの MCP サーバー利用が中心でしたが、今回のアップデートによりリモートサーバーを活用できるようになり、計算リソースの削減とセキュリティ管理が向上します。Atlassian や GitHub などの外部サービスとの統合も可能で、OAuth 認証による安全な接続を実現します。詳細は こちらのドキュメントをご参照ください。 9/19(金) AWS が簡素化されたモデリングのための SiteWise MCP Server を発表 AWS が AWS IoT SiteWise 向けの MCP (Model Context Protocol) サーバーをオープンソースで公開しました。このサーバーは産業データのモデリング作業を大幅に簡素化し、従来必要だった複雑な API 知識がなくても会話型インターフェースで直感的に操作できるようになります。産業分野の専門知識が内蔵されており、適切な単位やデータ型を自動で適用するため、手作業での調整や修正作業が不要になり開発時間を大幅に短縮できます。詳細は こちらの GitHub リポジトリをご参照ください。 AWS Neuron SDK 2.26.0 の発表 AWS Neuron SDK 2.26.0 が一般提供開始となりました。この SDK は Inferentia や Trainium インスタンスで機械学習モデルを効率的に実行するためのツールです。今回のアップデートでは PyTorch 2.8 や JAX 0.6.2 といった最新フレームワークに対応し、画像生成モデル FLUX.1-dev や大規模言語モデル Llama 4 の新バリアントを Trn2 インスタンス上で実行できるようになりました。特に注目すべきは Expert parallelism サポート (beta) により、複雑な MoE モデルを複数の NeuronCore に分散して効率的に処理できる点です。詳細は こちらのドキュメントをご参照ください。 最後にイベントのお知らせです。2025年10月9日（木）19:00-「10 周年を迎えた AWS IoT Core – 過去を振り返り、未来を見据えて」というテーマで、目黒セントラルスクエア現地のみのイベントを開催いたします。詳細、お申し込みは こちら 。AWS が 2015 年の re:Invent で IoT 向けのサービスを発表してから 10 年が経ちました。この記念すべき節目を迎え、IoT を取り巻く環境の劇的な変化を振り返るとともに、未来への展望を共有する特別なイベントとなります。お客様セッションやネットワーキングもご用意がございます。私も参加いたしますので、ぜひお声掛けください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料食品やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

この記事は 2025 年 8 月 27 日公開の韓国語記事 래빗 워크의 제작 혁신 を翻訳したものです。 Rabbit Walks Inc.（以下ラビット ウォークス）は、2010 年に設立された特殊映像専門会社で、世界初の立体テレビコンテンツ制作を皮切りに業界をリードしてきました。サムスン電子、LG、現代自動車などグローバルブランドとコラボレーションし、高画質デモコンテンツやインタラクティブ展示コンテンツなどを制作してきており、CES、IFA、ISE、Infocomm などの世界的な展示会でも技術力を認められている韓国の代表的な VFX 産業基盤の会社です。 約 75 人のメンバーで構成されたラビット ウォークスは、企画、演出、デザイン、作曲などコンテンツ制作の全行程を自社内で遂行できる「オールインワン」の組織構造を備えています。これらの「ワンストップソリューション」の能力は、迅速な意思決定と創造的なアイデアの即時実装を可能にしますが、同時にプロジェクトが集中すると、コンピューティングリソース、特にレンダリングパワーの需要が爆発的に増加する要因にもなります。 特にリアルタイムゲームエンジンベースのレンダリングのない CG コンテンツ制作技術をもとに、ライブ放送とストリーミング環境に最適化された VFX ワークフローを運営しており、最近では AI 技術を活用した高画質広告コンテンツやデジタルヒューマン制作まで商用化に成功しました。このように最先端技術を積極的に導入する過程で、AI モデルの学習や高解像度の最終結果出力など、既存のリアルタイムワークフローを補完する大規模なプリレンダリング作業の必要性が出てきました。 次世代製品の開発段階から、お客様と協力してインターフェースや視覚化コンテンツを共に開発する「先行開発コンテンツ」分野でも強みを見せ、AR ガラス、透明 OLED、ホログラムディスプレイ、モジュラーディスプレイなど未来型デバイスに最適化されたコンテンツを継続的に披露しています。 2025 年には欧州進出を本格化し、イタリアのミラノに法人を設立し、今後はパリおよびミラノオリンピック関連プロジェクトの実施を準備中です。 このようなグローバル展開と超大型 / 超高画質プロジェクトは予測不可能な規模のレンダリング需要を生み出し、既存の固定オンプレミスインフラだけでは対応し難い課題をもたらします。 超大型 / 超高画質サイネージ、空間演出、ホログラムコンテンツなど、次世代インタラクティブメディア領域においても継続的な技術投資と研究開発を続けています。 Deadline Cloud レンダーファームプロジェクトの背景 ラビット ウォークスは、最先端の技術力と芸術性を組み合わせてメディア業界の新しい基準を提示してきました。特に AI 技術の融合、18K 以上の超高解像度コンテンツ制作、グローバルプロジェクトの遂行など、ビジネスの成功拡大は、既存のオンプレミスインフラに新たな課題をもたらしました。これらの背景の中で、ラビット ウォークスは将来の成長を支える柔軟で強力なレンダリング環境を構築するためクラウド導入を決定し、そのコアソリューションとして AWS Deadline Cloud を選択しました。 この過程で、レンダーファームの技術と多様なコンピテンシー能力を保有している AWS のパートナーである Megazone Cloud は、AWS Deadline Cloud の設計から技術サポートまで、全方位的なパートナーシップを提供し、ラビット ウォークスがより安定的で柔軟なコンテンツ制作環境を確保する上で重要な役割を果たしました。 当初の課題 現在、ラビット ウォークスは約 50 台規模の高性能 GPU（RTX 3080Ti 以上）で構成された社内レンダーファームを運用しています。これは十分に強力な設備ですが、ビジネスの爆発的な成長の中で、次のような「成長痛」を経験していました。 リソースの非効率的な割り当て: レンダリング作業中に複数の GPU リソ​​ースが 4 または 10 単位の固定グループに割り当てられる構造のため、30 人を超えるアーティストが同時に作業を進行するときに余剰リソースが発生するにもかかわらず、特定のワークグループでボトルネックが発生する問題がありました。これはアーティストの待ち時間を増やし、全体的な生産性を低下させる主な原因でした。 予測不可能な需要に対する対応が困難： 最近 4K を超えて 8K、18K 以上の超大型プロジェクトの受注が増加し、レンダリングに必要なコンピューティングパワーが指数関数的に増加しました。特定のプロジェクトの締切が差し迫ったとき、瞬間的に通常の数倍に達するレンダリングリソースが必要でしたが、物理的に限られたオンプレミスファームではこれらのピーク需要にすぐに対応できませんでした。 膨大な増設費用と将来の不確実性： これらの問題を解決するためにレンダーファームの増設を検討しましたが、GPU 端末 1 台に数千万ウォンに達する膨大な初期投資費用が負担となりました。さらに重要な問題は、将来のプロジェクト規模と必要な GPU 仕様を予測するのが難しいということでした。今すぐ巨額を投資して増設しても、1～2 年後にはより高性能な GPU が必要になるか、逆にプロジェクトがない期間には高価な機器の余剰が発生する可能性がありました。 レンダーファーム増設の難しさ これらの問題に対処するためにレンダーファームの増設を検討しましたが、1 台の機器を増設するには少なくとも 4000 万ウォン以上の費用がかかります。これは短期的な解決策には適しているかもしれませんが、会社の継続的な成長と従業員の増加に比例したレンダーファームの確保には根本的な限界があります。 既存の選択肢の限界と新しい基準の必要性 ラビット ウォークスは、オンプレミスの増設に加えて、他の代替案も慎重に検討しました。 短期での機器のレンタル： 外部機器を借りる方法は作業に比べて費用対効果が低く、機器の設置や撤退の過程に別々の管理人員と時間が投入される運営上の負荷が高い。 オンラインレンダーファームサービス： 従来の商用オンラインレンダーファームサービスは、間欠的なエラーが発生した場合、即時の技術サポートが困難であり、特に大規模なプロジェクトを長期的に進める場合、予測するのが難しいコスト構造のために実質的な代替策になり得なかった。 このように、既存の代替案の明確な限界は、ラビット ウォークスがレンダリングインフラストラクチャの新しい基準を確立することになったきっかけになりました。必要なのは単により多くのコンピューティングパワーではありませんでした。 必要に応じてすぐに使用できる「弾力性」 使用した分だけ費用を支払う「経済性」 複雑な設定なしでアーティストが創作に集中できるようにする「シンプルさ」 信頼できる技術サポートが保証される「信頼性」 この 4 つの基準が次世代レンダリング環境には重要な要件でした。 レンダリング環境改善の取り組みにおける選択 これまでの社内のレンダリング設備には限界があり、外部への代替え案も効率的とは言えない状況です。一方で、制作プロジェクトは増加の一途をたどり、作品の品質要求も高度化しています。この状況に対応するためには、安定性と拡張性を備えた新しいレンダリング環境が必要です。そこで私たちは、効率的なリソース管理が可能で、将来の需要増加にも柔軟に対応できるAWS Deadline Cloudの導入を決定しました。 クラウドレンダーファーム導入過程と当初の技術的課題 AWS Deadline Cloud 導入戦略の策定 ラビット ウォークスの既存のオンプレミス環境と要件を分析した結果、AWS Deadline Cloud が最適なソリューションと判断されました。しかし、既存のワークフローとの互換性、アーティストの学習曲線、そして多様なレンダリングエンジンのサポートなど解決しなければならない課題がありました。 そのため、Magazone Cloud とともに段階的導入戦略を策定し、リスクを最小限に抑えながら実質的な成果を確認できるロードマップを設計しました。 導入ステップ 1：SMF (Service Managed Fleet) 環境の構築と初期テスト 期間：2024 年 10 月 20 日～ 2024 年 11 月 13 日 目標：AWS Deadline Cloud の基本機能の検証と既存のワークフローとの互換性を確認 構成環境： レンダリングソフトウェア： Houdini 19.5 レンダリングエンジン: Mantra 制限事項： Cinema4D および Redshift の UBL (Usage-Based Licensing) 未サポート (2024年当時の状況。現在はサポート済み) 主な成果： AWS Deadline Cloud の基本アーキテクチャとジョブ送信プロセスの理解 クラウド環境におけるレンダリングパフォーマンスベースラインの確保 ネットワーク帯域幅とファイル転送最適化方式の導出 当初の技術的課題： ライセンス管理の複雑さ &nbsp;既存のオンプレミスライセンスとクラウド環境間の互換性の問題 UBL 方式のライセンス未サポートによるソフトウェア制約 ネットワーク最適化の必要性 大容量 3D アセットファイルのアップロード/ダウンロード時間の問題 社内ネットワーク帯域幅制約の特定 ワークフローの標準化 既存のパイプラインとクラウド環境間の統合方式が必要 導入ステップ 2：パフォーマンスの最適化と GPU タイプの選択 期間：2025 年 3 月 ～ 2025 年 4 月 目標：Cinema4D ワークロードに最適化された GPU インスタンスタイプの選択 テスト方法論： 実稼働プロジェクトと同じ条件でベンチマーク操作を実行 さまざまな EC2 GPU インスタンスタイプによるパフォーマンスとコスト効率の比較分析 レンダリングの複雑さに応じた最適なインスタンス構成の導出 性能テスト結果： インスタンスタイプによるパフォーマンス比較： G4dn.xlarge：基本的なパフォーマンスベースライン G5.2xlarge：約 40％ の性能向上 G6.12xlarge：約 75％ の性能向上 (最終選定) コスト効率分析： 純粋なレンダリング時間に対して約 60％ のコスト削減 プロジェクトターンアラウンド時間 90％ 以上短縮 技術的な洞察： NVIDIA RTX A10G ベースの G5 インスタンスが Cinema4D + Redshift の組み合わせで最適なパフォーマンスを発揮 メモリ集約型タスクでは、G6インスタンスの優れたGPUメモリ効率の確認 Spot インスタンスを活用した場合の追加で 30% コスト削減の可能性の確認 導入ステップ3 ： CMF (Customer Managed Fleet) の移行と本格的な運用 期間：2025 年 5 月 15 日～現在 目標：完全な実稼働環境の構築とスケーラブルなワークフローの完成 主な改善点： オペレーティングシステムの最適化 &nbsp;Linux ベースのレンダリング環境に切り替える コンテナベースのワークフロー導入により環境一貫性を確保 ライセンス管理の改善 Cinema4D と Redshift のクラウド互換ライセンスを取得 動的ライセンス割り当てシステムの構築 自動化と監視 &nbsp;CloudWatch によるリアルタイムレンダリングジョブの監視 自動スケーリングポリシーの最適化 運営上の課題と解決策： 課題 1：アーティストの教育と適応 解決策：段階的教育プログラムの運営 既存のワークフローと同様の UI/UX を提供 専門技術支援チームの運営 課題 2：ハイブリッド環境管理 解決策：オンプレミスとクラウド間の作業優先度、自動判断ロジックの実装 統合ダッシュボードによる完全なリソースの可視性の確保 課題 3：コスト最適化 解決策： 作業パターン分析に基づく予測スケーリング Reserved Instance と Spot Instance の混合での活用 リアルタイムコスト監視と通知システムの構築 導入の過程で得た主な教訓 段階的な移行の重要性 段階的導入をすることでリスク最小化と学習効果を最大化 各段階的なパフォーマンス測定による継続的な改善 技術パートナーシップの価値 パートナー Megazone Cloud の専門性が導入期間の短縮と安定性確保に決定的に貢献 24 時間 365 日の技術支援による運用安定性の確保 柔軟な管理の重要性 アーティスト中心でユーザー体験を設計 十分な教育と段階的な移行で現場のストレスを最小限に抑える 以上の体系的な導入プロセスにより、ラビット ウォークスは本番環境に AWS Deadline Cloud を統合することができました。 テスト環境とワークロード &lt;Deadline Cloud Rendering Architecture&gt; レンダリング内容 解像度：8880 x 1890 (Ultra-wide 4K) レンダリングフレーム数：91 フレーム 事前予想コスト：ハイパフォーマンスレンダリングに ＄880 以上と予測 テストインフラストラクチャの構成 オンプレミス環境 (ローカルPC) GPU：NVIDIA RTX 3080 Ti 4 台構成 1 フレームのレンダリング時間：約 32 分 総レンダリング時間：約 12 時間 8 分 AWS Deadline Cloud 環境 インスタンスタイプ：G6.12xlarge (GPU 最適化タイプインスタンス) テスト構成：1 回目、2 回目、3 回目スケーリングテスト &lt;Deadline Cloud Monitoring Dashboard&gt; 性能比較結果 レンダリング時間の最適化 AWS Deadline Cloud のスケーリング効果がはっきりと現れました。 構成 1 フレーム レンダリング 時間 総 レンダリング 時間 パフォーマンス の向上 ローカルPC (RTX 3080 Ti x4) 32 分 12 時間 8 分 基準 Deadline Cloud 1 回目 15 分 30 秒 47 分 50 秒 93％ 短縮 Deadline Cloud 2 回目 8 分 9 秒 39 分 23 秒 95％ 短縮 Deadline Cloud 3 回目 16 分 1 時間 4 分 91％ 短縮 コアパフォーマンス 劇的なパフォーマンス向上 最適構成（2 回目テスト）で総レンダリング時間を 12 時間から 39 分に 95％ 短縮 シングルフレームレンダリング時間を 32 分から 8 分 9 秒に 75% 改善 弾力的な拡張性 ワークロードに応じた動的なリソース割り当てによるコスト効率の最大化 ピークタイムゾーンの自動スケーリングによるボトルネックの除去 ネットワーク伝送の最適化 ファイル転送性能 アップロード：レンダーファーム→Dropbox 約 7-8 分（テスト自動化環境） ダウンロード：Dropbox →ローカル 約 40 分 ネットワーク最適化: 社内帯域幅の制約が主なボトルネックとして特定 技術的な洞察 ワークロード分散の効率性 AWS Deadline Cloud の自動分散機能により、91 フレームを複数インスタンスに最適に配分して処理時間を大幅に短縮しました。 GPU リソースの活用 G6.12xlarge インスタンスの高性能な GPU は、複雑な 3D レンダリングにおいてオンプレミス環境と比べて優れたパフォーマンスを示しました。 費用対効果 初期予想コスト $ 880 と比較して、実際のクラウドレンダリングのコスト効率と時間短縮による運用コスト削減が証明されました。 結論 ラビット ウォークスとのコラボレーションにより、AWS Deadline Cloud は既存のオンプレミスレンダーファームと比較して次の重要な価値を提供することを確認しました。 パフォーマンス：最大 95％ のレンダリング時間を短縮 スケーラビリティ：プロジェクトの規模に応じた柔軟なリソース拡張 コスト効率：使用した分だけ支払うモデルで運用コストを最適化 管理の利便性：インフラ管理負担の除去 今回のテスト結果は、3D レンダリングスタジオがクラウド移行を通じて得られる実用的なビジネス価値を明確に示すとともに、AWS Deadline Cloud が現代のメディア制作ワークフローにおけるコアソリューションであることを実証しました。 Deadline Cloud 以外で今回追加した実装部分について ラビット ウォークスは、アーティストのリモート作業環境をサポートするために、 Amazon Elastic Compute Cloud (Amazon EC2) &nbsp;と Amazon DCV を活用したワークステーションの設定も行いました。一方で、アーティストは AWS コンソールを介した EC2 サーバーの管理に精通していなかったため、 Amazon Cognito 、 Amazon CloudFront 、 Amzazon Simple Storage Service (Amazon S3) 、 Amazon API Gateway を組み合わせてサーバーレスベースのリモートサーバー管理ページを個別に構築しました。これにより、アーティストは簡単に EC2 のクラウドワークステーションを管理できるようになり、リモートサーバーを使用して社内ネットワークから AWS Deadline Cloud へのアップロード速度も大幅に向上しました。また、必要に応じて高性能なサーバーに簡単に切り替えができ、作業効率を高めるとともに、運営およびメンテナンスへの負担も軽減できる環境を整えました。 &lt;Rabbitwalks Renderfarm Process Architecture&gt; 作業結果のパフォーマンスについて 今回のプロジェクトでは AWS Deadline Cloud を導入したことで、オンプレミス環境では締切までの完成が難しかったスケジュールをこなすことできました。 特に、当日午前に要求された修正を反映した映像を同日午後までに提供できることは、従来の環境ではほぼ不可能なことでしたが、AWS Deadline Cloud を活用することで、厳しい作業スケジュールにも安定した映像の提供ができるようになりました。 従来のオンプレミス環境では、1 フレームのレンダリングに約 32 分かかりましたが、AWS Deadline Cloud レンダーファームを利用した結果、15～16 分に大幅に短縮できました。 &lt;Rabbitwalks Renderfarm Architecture&gt; Deadline Cloud導入後のプラン ラビット ウォークスは AWS Deadline Cloud を活用し、高速かつコスト効率の高いレンダリング環境を実現しました。これにより、プロジェクトごとに必要なリソースを柔軟に活用できる体制を整えています。 今後は、ワークロードのクラウド移行を進めることで、災害対策 (DR) の強化、映像データの迅速な運用、そして GenAI を用いた企画・制作プロセスの効率化を目指しています。こうした取り組みによって、最終成果物の完成までのスピードを加速させ、新しい映像制作のスタイルをいち早く実現し、ビジネスの成長につなげていきます。 パク・チャンモク、ラビット ウォークス 3D チームリーダー パク・チャンモクは現在、ラビット ウォークスでチームリーダーとして、様々なプロジェクトを率いています。R&amp;D 部門で新しい技術とワークフローを実験する役割として、Houdini、Cinema 4D、Unreal Engine、Redshift などのツールを活用したコンテンツ制作に集中しています。最近では、クラウドベースのレンダリング環境を構築し、生成 AI と機械学習技術を視覚芸術分野に融合する研究を通じて、新しい表現方式と制作方式を模索しています。 キム・ユンスク、Megazone Cloud メディアスペシャルチーム キム・ユンスク Megazone Cloud メディアユニットクラウドテック担当者は、メディア・VFX 顧客のクラウド基盤制作環境の構築を支援しており、プレセールスエンジニアとして顧客カスタマイズ型アーキテクチャ設計及びコンサルティングを通じて実質的な技術転換を導いています。 アンテヨン、Megazone Cloud メディアユニットクラウドセールス アンテヨン Megazone Cloud メディアユニットクラウドセールス担当者は、 メディア・VFX 業界のお客様が AWS クラウドをベースに制作効率と技術競争力を確保できるように、インフラストラクチャの提案とクラウド移行を支援しています。 チョウ・ボラエ チョウ・ボラエは AWS のシニアソリューションズアーキテクトで、ビジュアルコンピューティングの分野を担当しています。スタジオ制作プロセスの技術に対する豊富な経験に基づき、生成 AI とエージェント AI の分野で革新的な作業を進めています。 ソ・ダンヒ ソ・ダンヒ (AWS Cloud Sales Rep) は、AWS カスタマーのデジタルイノベーションとビジネス成長のための信頼できるパートナーになることを目指しています。具体的には、お客様が AWS クラウドを効果的に活用してビジネス目標を達成できるように、統合的なクラウド旅行をサポートしています。 <!-- '"` --> カン・スンウク カン・スンウク Solutions Architect は、長年のバックエンド開発経験に基づいて、スタートアップからエンタープライズまで、さまざまな顧客の AWS ベースのワークロード実装をサポートしています。現在、CSC チームで迅速なイノベーションを推進する企業に、スケーラブルな技術ソリューションとアーキテクチャガイダンスを提供し、顧客のデジタル転換とクラウドの旅を加速する役割を担っています。 本記事は、 2025 年 8 月 27 日公開の韓国語記事 래빗 워크의 제작 혁신 を翻訳したものです。 翻訳は Sir. Visual Compute Specialist Solutions Architect の森が担当しました。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。