6月11日、2025 年初頭までに新しい AWS リージョンが台湾に導入されることを発表しました。新しい AWS アジア太平洋（台北）リージョンは、ローンチ時に3つのアベイラビリティゾーンで構成され、台湾の AWS のお客様に、台湾に残す必要があるワークロードの実行とデータの保存を可能にします。 各アベイラビリティーゾーンは、リージョン内の他のゾーンから物理的に独立しています。低レイテンシーを必要とするアプリケーションをサポートするのに十分な距離でありながら、アベイラビリティゾーンレベルのイベントが事業継続に影響を与えるリスクを大幅に低減するのに十分な距離です。 このリージョンのアベイラビリティーゾーンは、完全冗長の専用ファイバーを介した高帯域幅、低レイテンシーのネットワーク接続を介して接続されます。この接続は、可用性または冗長性のためにアベイラビリティーゾーン間の同期レプリケーションを必要とするアプリケーションをサポートします。リージョンと AZ の設計と構築方法の詳細については、 AWS グローバルインフラストラクチャ のページをご覧ください。 現在、 マレーシア 、 メキシコ 、 ニュージーランド 、 サウジアラビア王国 、 タイ 、 AWS European Sovereign Cloud のリージョンに取り組んでいます。AWS クラウドは世界中の 33 の AWS リージョンで 105 のアベイラビリティーゾーンを運用しており、さらに 21 のアベイラビリティーゾーンと、台湾を含むさらに 7 つのリージョンの計画が発表されています。 台湾の AWS AWS は 10 年以上にわたり、台湾のお客様やパートナーに投資し、サポートしてきました。台湾のお客様をサポートするために、 台北オフィス には事業開発チーム、ソリューションアーキテクト、パートナーマネージャー、専門サービスコンサルタント、サポートスタッフなど、さまざまな役職があります。 その他の AWS インフラストラクチャには、 Amazon CloudFront のエッジロケーション が 2 つあり、複数の冗長化海底ケーブルを通じて AWS グローバルバックボーンにアクセスできます。Chief Telecom と Chunghwa Telecom が運営する台北の AWS Direct Connect ロケーション から、他の AWS リージョン (北京と寧夏を除く) にアクセスできます。AWS Direct Connect では、以前はインターネット経由で転送されていたデータが、お客様の施設と AWS の間のプライベートネットワーク接続を介して配信されます。 台湾でも AWS Outposts を利用できます。これは、ほぼすべてのオンプレミスまたはエッジロケーションに AWS インフラストラクチャとサービスを提供するフルマネージドソリューションのファミリーで、真に一貫したハイブリッドエクスペリエンスを実現します。台北の AWS Local Zones では、1 桁ミリ秒のレイテンシーを必要とするアプリケーションをエンドユーザーに配信できます。 AWS は、 AWS Academy 、 AWS Educate 、 AWS Skill Builder などのサービスを通じて、台湾の学生、現地の開発者や技術専門家、非技術専門家、次世代 IT リーダーのスキルアップに引き続き投資しています。2017 年以来、AWS はアジア太平洋地域と日本地域全体で 800 万人以上の人々にクラウドスキルのトレーニングを行ってきました。その中には、台湾の 10 万人以上が参加しています。 詳細は、7 月に開催される AWS Summit 2024 Taiwan 、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する対面イベントに参加しましょう。 台湾の AWS のお客様 台湾の AWS のお客様は、アプリケーションを AWS に移行し、テクノロジーインフラストラクチャを世界中の他の AWS リージョンで運用することが増えています。この新しい AWS リージョンの追加により、お客様はエンドユーザーにさらに低いレイテンシーを提供し、生成人工知能 (生成 AI)、モノのインターネット (IoT)、モバイルサービスなどの高度なテクノロジーを使用してイノベーションを推進できるようになります。このリージョンにより、AWS のお客様は台湾でワークロードを実行してコンテンツを保存できるようになります。 AWS を使用してイノベーションを推進しているお客様の例をいくつかご紹介します。 Chunghwa Telecom は台湾最大の総合通信事業者です。AI データのセキュリティとガバナンスを向上させるために、ソフトウェア開発ライフサイクルの仕様書の自動生成やカスタムマーケティングキャンペーンの作成など、さまざまな生成 AI アプリケーションに Amazon Bedrock を使用しています。Amazon Bedrock を使用することで、Chunghwa Telecom は開発者の時間を節約し、没入型のインタラクティブなバーチャル英語教師を初めて開発しました。 Gamania Group は、台湾におけるオンラインゲームの開発と公開におけるリーダーです。AWS 上で実行することの価値を最大化するために、彼らは AWS Training and Certification と協力して、 AWS Classroom トレーニング、 AWS Well-Architected フレームワーク、 AWS GameDay イベントなど、全部門にわたって AWS スキルを強化しました。その結果、重要な運用上の意思決定に必要な時間を 50% 短縮し、市場投入までの時間を最大 70% 短縮し、新しいゲームのローンチを加速しました。 KKCompany Technologies は、台湾で音楽ストリーミングプラットフォーム、AIを活用したストリーミングソリューション、クラウドインテリジェンスサービスを構築しているマルチメディアテクノロジーグループです。同社は、台湾と日本の企業向けの生成 AI、マルチメディアテクノロジー、デジタルトランスフォーメーションコンサルティングサービスを専門としています。クラウドベースのストリーミングソリューションである BlendVision は AWS Marketplace にあります。 台湾のお客様事例の詳細については、 英語版の AWS Customer Success Stories または 繁体字中国語のページ をご覧ください。 引き続きご期待ください このリージョンとその他のリージョンについては、今後のブログ記事でお知らせしますので、ご期待ください！ 詳細については、 繁体字中国語 の「 台湾の AWS リージョン 」ページをご覧ください。 – Channy 原文は こちら です。

時々、技術リーダーから、生成 AI アプリケーションの可視性とガバナンスを改善したいという話を聞きます。セキュリティ、耐障害性、プライバシー、正確性に関する問題に対処したり、責任ある AI のベストプラクティスに照らして検証したりするために、データの使用と生成をどのように監視および管理していますか? 実装段階でこれらを考慮に入れるだけでなく、長期的なオブザーバビリティを維持し、ソフトウェアのライフサイクル全体にわたってコンプライアンスチェックを実施するにはどうすればよいでしょうか? 6月11日、 AWS Audit Manager で AWS Audit Manager の生成 AI ベストプラクティスフレームワークのアップデートを開始します。このフレームワークにより、エビデンスの収集が簡素化され、ベストプラクティス要件を実装するように事前設定された 110 の標準コントロールを通じて、生成 AI ワークロードのコンプライアンス体制を継続的に監査および監視できます。例としては、トレーニングモデルのために使用される前に匿名化されていなかった可能性のある個人を特定できる情報 (PII) データを可視化したり、使用されているデータセットにアクセスするために多要素認証 (MFA) が強制されていることを確認したり、カスタマイズされたモデルのバックアップバージョンを定期的にテストしてシステム停止前に信頼性が高いことを確認したりすることが挙げられます。これらのコントロールは、 AWS Config と AWS Security Hub からコンプライアンスチェックを行い、 AWS CloudTrail からユーザーアクティビティログを収集し、関連する AWS サービスへのアプリケーションプログラミングインターフェイス (API) 呼び出しを行って設定データを取得することでタスクを実行します。そのレベルの柔軟性が必要な場合は、独自のカスタムコントロールを作成することもできます。 以前は、v1 に含まれていた標準コントロールは、 Amazon Bedrock で動作するように事前設定されていましたが、この新しいバージョンでは、 Amazon SageMaker もデータソースとして含まれているため、Amazon Bedrock と Amazon SageMaker の両方での生成 AI ワークロードをより少ない労力でより厳密に制御および可視化できます。 生成 AI ワークロードに対してベストプラクティスを実施する 「AWS 生成 AI ベストプラクティスフレームワーク v2」に含まれる標準コントロールは、正確性、公平性、プライバシー、耐障害性、責任、安全、セキュリティ、そして持続可能性といったドメインにまとめられています。 コントロールは、自動チェックまたは手動チェック、あるいはその両方を実行することができます。例えば、モデルの精度を長期にわたって定期的に確認することを対象とするコントロールがあります。 Amazon Bedrock と SageMaker の API を呼び出して、関連するモデルのリストを自動的に取得しますが、その場合は、それぞれのモデルについてレビューが行われたことを示すエビデンスを特定の時期に手動でアップロードする必要があります。 コントロールを含めたり除外したり、定義済みのコントロールをカスタマイズしたりして、フレームワークをカスタマイズすることもできます。これは、さまざまな国の規制に合わせてフレームワークを調整したり、経時的に変化する規制に応じて更新したりする必要がある場合に非常に役立ちます。独自のコントロールをゼロから作成することもできますが、時間を節約できるので、最初に Audit Manager コントロールライブラリを検索して、開始点として使用するのに適した、またはそれに近いものを探すことをお勧めします。 共通コントロール、標準コントロール、カスタムコントロールを参照および検索できるコントロールライブラリ。 開始するには、まず評価を作成する必要があります。このプロセスを順に見ていきましょう。 ステップ 1 – 評価の詳細 まず、AWS マネジメントコンソールの Audit Manager に移動し、[Assessments] (評価) を選択します。[Create assessment] (評価を作成) を選択すると、設定プロセスに移動します。 評価に名前を付けてください。必要に応じて説明を追加することもできます。 この評価の名前を選択し、必要に応じて説明を追加します。 次に、Audit Manager が生成した評価レポートを保存する Amazon Simple Storage Service (S3) バケットを選択します。ただし、評価と同じ AWS リージョンのバケットを選択する必要はありませんが、選択することをおすすめします。選択した場合、評価では最大 22,000 件のエビデンス項目を収集できますが、クロスリージョンバケットを使用する場合、そのクォータは 3,500 項目に大幅に減少します。 AWS Audit Manager がレポートを保存できる S3 バケットを選択します。 次に、使用するフレームワークを選択する必要があります。フレームワークは、そのすべてのコントロールを評価に使用できるようにするテンプレートとして効果的に機能します。 今回は、「AWS 生成 AI ベストプラクティスフレームワーク v2」フレームワークを使用したいと考えています。検索ボックスを使用し、ポップアップ表示された一致する結果をクリックしてフィルターを有効にします。 検索ボックスを使用して「AWS 生成 AI ベストプラクティスフレームワーク V2」を検索する 次に、フレームワークのカードが表示されます。必要に応じてフレームワークのタイトルを選択し、フレームワークの詳細を確認したり、含まれているすべてのコントロールを参照したりできます。 カード内のラジオボタンをクリックして選択します。 ラジオボタンをチェックしてフレームワークを選択します。 これで、評価にタグを付けることができるようになりました。他のリソースと同様に、わかりやすいメタデータをタグ付けすることをお勧めします。そのためので、ガイダンスが必要な場合は、「 AWS リソースのタグ付けのベストプラクティス 」を確認してください。 ステップ 2 – 対象範囲内の AWS アカウントを指定する これは非常にわかりやすい画面です。評価のコントロールで継続的に評価することを希望する AWS アカウントを選択するだけです。デフォルトでは、現在使用している AWS アカウントが表示されます。Audit Manager は、複数のアカウントに対して評価を実行し、レポートを 1 つの AWS アカウントに統合することをサポートしていますが、この機能を使用する場合は、まず AWS Organizations との統合を明示的に有効にする 必要があります。 評価に含める AWS アカウントを選択します。 リストに表示されている自分のアカウントを選択し、[Next] (次へ) をクリックします ステップ 3 – 監査所有者を指定する あとは、この評価を使用および管理するための完全な許可を持つ必要のある IAM ユーザーを選択するだけです。これは文字通り簡単な作業です。 Identity and Access Management (IAM) のリストからユーザーまたは利用可能なロールを選択するか、ボックスを使って検索します。AWSAuditManagerAdministratorAccess ポリシーを使用することをお勧めします。 たとえそれが自分自身であっても、少なくともユーザーを 1 人選択する必要があります。このチュートリアルでもそのようにしています。 この評価に対して完全な許可を持ち、所有者として行動する IAM ユーザーまたはロールを選択します。 ステップ 4 – 確認して作成する あとは、選択内容を確認し、[Create assessment] (評価を作成) をクリックしてプロセスを完了するだけです。 評価が作成されると、Audit Manager は選択した AWS アカウントでエビデンスの収集を開始し、ユーザーはレポートの作成を開始し、準拠していないリソースは概要画面に表示されます。最初の評価が表示されるまでに最大 24 時間かかる場合があることに注意してください。 評価の詳細画面にいつでもアクセスして、どのコントロールのステータスも確認できます。 まとめ 「AWS 生成 AI ベストプラクティスフレームワーク v2」は、Amazon Bedrock と Amazon SageMaker が利用できるすべての AWS リージョンの AWS Audit Manager フレームワークライブラリ で本日よりご利用いただけます。 Audit Manager が希望するリージョンで利用可能かどうかは、 リージョン別の AWS サービス で確認できます。 さらに深く掘り下げたい場合は、 開始方法のステップバイステップガイド をご覧ください。 原文は こちら です。

多くの AWS 顧客は、開発プロセスを高速化し、アーキテクチャの一部としてそれぞれのサービスをスケールアウトする機能を向上させるために、モジュール化されたアプリケーションの近代化を行っています。これには顧客が開発したアプリケーションと、パートナーが開発した SaaS アプリケーションが含まれます。アプリケーション間の通信には、 Amazon Web Services (AWS) 環境全体でのネットワーク接続が必要です。これらのアプリケーションについて、顧客とパートナーは、パートナーが各種 AWS サービスを使ってアプリケーションへのアクセスを許可する、さまざまなネットワーク接続モデルを使用します。アプリケーション間の通信を接続、監視、保護するネットワーク構造の 1 つが Amazon VPC Lattice です。顧客は、サービスへのアクセスをコントロールするきめ細かなアクセス制御ポリシーを使って、簡素化された安全なネットワーク接続モデルを提供する VPC Lattice を利用します。例えば、顧客はサービスネットワークに関連付けられている Amazon Virtual Private Cloud (VPC) の各クライアントアプリケーションから SaaS サービスとの通信方法をポリシーで定義します。 この記事では、Amazon VPC Lattice 内の SaaS サービスをどのように接続するかについて説明します。 SaaS サービスの接続を可能にする VPC Lattice 内のコンポーネントを確認し、パートナーアカウントと VPC にデプロイされた SaaS サービスを接続するためのベストプラクティスを概説します。 また、パートナーの視点と顧客の視点の両方から認証ポリシーの例を確認し、サービスネットワーク内のサービスへのアクセスを許可または拒否する方法を示します。 前提条件 以降のセクションでは、 AWS Identity and Access Management (IAM) ポリシーの作成と、VPC Lattice の基本的な概念 (サービス、サービスネットワーク、認証ポリシーなど) を把握していることを前提とします。 また、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda を使ってサービスやアプリケーションをデプロイする方法に習熟していることを前提とします。 ソリューション概要 パートナーと VPC Lattice 内でサービスを共有するには、この接続モデルを提供する 2 つの機能、リソース共有とセキュリティコントロールがあります。 例として 3 つのサービスで構成するシンプルなアーキテクチャを使用します。 アプリケーションのフロントエンドとバックエンドの 2 つのサービスがお客様のアカウント内に存在します。 さらに、パートナーの SaaS ソリューションをサービスネットワークに追加し、異なるサービス間の通信を可能にします。 図 1 にこのネットワークの一部としてデプロイされたアプリケーションを示しています。 図 1: 顧客アカウントと SaaS アカウント間のアプリケーションアーキテクチャ リソース共有 SaaS プロバイダと AWS アカウント または AWS Organizations アカウント内のサービスネットワークとの間でサービスを共有するには、 AWS Resource Access Manager (AWS RAM) を利用します。 AWS RAM は、VPC Lattice リソースを他の AWS アカウントまたは組織と共有できるサービスです。 AWS RAM を使うと、パートナーは独自の SaaS サービスを共有し、あなたのサービスネットワークにアクセスし、VPC Lattice の一部としてデプロイされたサービスと VPC との間での通信を許可できます。 パートナーが所有する VPC Lattice リソースを他の AWS アカウントと共有する場合、それらのアカウントは、サービスやサービスネットワークなど、パートナーのリソースをお客様のアカウントのリソースに関連付けることができます。 AWS RAM では、パートナーが共有するテナンシモデルに応じて、1 つまたは複数のアカウントとサービスを共有できます。詳細は後の項で説明します。 共有リソースに対してアソシエーションを作成すると、リソースを所有しているアカウントに Amazon Resource Name (ARN)が生成され、アソシエーションを作成したアカウントにも ARN が生成されます。 AWS RAM の強力なコンセプトの 1 つに、リソース共有がリソース所有者と、リソース所有者が直接共有する AWS アカウントもしくは組織との間でのみ行われるという点があります。そうした AWS アカウントや組織は、他のアカウントと直接リソースを共有することはできません (推移的な共有はできません)。例として、図 2 では SaaS アカウントが SaaS サービスを Account A と共有し、Account A はそのリソースをサービスネットワークに追加します。そのサービスネットワークの他のサービスも、VPC Lattice サービスとサービスネットワーク認証ポリシーがアクセスを許可している限り、SaaS サービスにアクセスできます。しかし、AWS RAM 内のリソースは推移的に共有することはできません。たとえば、Account A は Account B にサービスを共有してその サービスネットワークに SaaS サービスを追加することはできません。Account B がサービスネットワークに SaaS サービスを追加したい場合、SaaS アカウントから直接共有する必要があります。 図 2: AWS RAM では推移的なサービス共有は許可されない AWS RAM の動作がわかったところで、図 1 に示した SaaS サービスの共有方法を説明します。まず、SaaS アカウントが単一の SaaS サービスを作成しました。 AWS RAM 経由で、SaaS サービスはパートナーが提供するサービスを提供し、これがお客様のサービスネットワークに接続されます。 図 3: SaaS プロバイダー アカウントで作成された SaaS サービス SaaS サービスをアカウントと共有するためには、パートナーがターゲットの AWS アカウントまたは組織向けに AWS RAM で リソース共有を作成 します。 リソース共有で、パートナーは次の項目を選択します。 共有するリソース : これには、パートナーがお客様の AWS アカウントまたは組織と共有する 1 つ以上の VPC Lattice サービスが含まれます。 リソース共有に関連した権限 : デフォルトでは、VPC Lattice サービスの権限には VPC Lattice サービスの情報を取得する権限と VPC Lattice サービスをネットワークに関連付ける権限が含まれます。リソース共有で他の権限を許可するかどうかは、パートナーがカスタマイズできます。 アクセスを許可される対象 : これは、パートナーがリソースを共有するアクセス権限を持つ対象の AWS アカウントまたは組織を指定します。 図 4 に示すように、パートナーがアカウントで SaaS サービスを共有すると、 AWS RAM と VPC サービス の両方で共有されたサービスが表示されます。 図 4: SaaS サービスと顧客アカウントの共有 この例では、図 5 に示すように、サービスがあなたのアカウントに表示されます。 図 5: アカウント内の VPC Lattice サービス 既に AWS アカウントでデプロイされているサービスネットワークに SaaS サービスを追加します。これにより、自身のサービス (フロントエンドとバックエンド) と SaaS サービスの間でサービス間通信が可能になります。 ただし、その前にサービスネットワーク内におけるサービス間のセキュリティと認証ポリシーについて説明します。 VPC Lattice 内のセキュリティコントロール セキュリティコントロールの観点から、 VPC Lattice 認証ポリシー を使用すると、サービスネットワークまたはサービスネットワーク内のサービスグループに IAM ポリシーを割り当てることができます。 これにより、VPC Lattice 内の各サービスとサービスネットワークへのアクセスを制御できるメカニズムを提供します。 各認証ポリシーは AWS IAM リソースポリシーであり、サービスアクセスリクエストへのリクエストレベルの認証とコンテキストに応じた承認を提供します。 認証ポリシーは、IAM リソースレベルでアクセスを許可または拒否するための強力な機能を提供し、 セキュリティグループ や ネットワークアクセスコントロールリスト (ACL) といったネットワークレベルの構成に加えて利用できます。 パートナー側の視点とお客様側の視点という 2 つの立場からシナリオを見ていきましょう。 パートナー側は、サービスを共有し、お客様側は VPC Lattice のサービスネットワークに SaaS サービスを追加します。 アーキテクチャは図 1 に示したものと同じで、フロントエンド、バックエンド、SaaS サービスで構成されます。 認証と認可の観点では、パートナー側はどの AWS アカウントや組織がサービスにアクセスできるかを決めるポリシーをデプロイします。 一方、お客様側は、サービス同士がどのように通信するかを決めるポリシーをデプロイします。 パートナー視点 VPC Lattice でサービスを提供するパートナーの場合、SaaS ソリューションのテナント分離戦略は、パートナーがリソースを共有する方法と、VPC Lattice サービスに追加する必要があるアクセス制御のポリシーに影響します。 SaaS アプリケーションの種類(フロントエンド、バックエンド、データアプリケーションなど)によって、パートナーが SaaS ソリューションをデプロイする方法が異なります。 シングルテナントモデル シングルテナントモデルでは、パートナーは VPC Lattice サービスを単一のお客様と共有します。ただし、1 つの AWS アカウント、複数の AWS アカウント、または AWS Organizations アカウントの中の 1 つの組織で共有する場合があります。 パートナーサービス内のすべてのリソースは、単一のお客様に紐づけられ、他の SaaS 顧客からは分離されています。パートナーは、すべてのリソースを別々のアカウントや VPC に配置する必要はありません。ただし、各 VPC Lattice サービスを個々の顧客向けにプロビジョニングされたリソースに紐付ける必要があります。このモデルでは、パートナーの認証ポリシーにより、指定の AWS アカウントまたは組織に所属する認証済みプリンシパルからのリクエストへのアクセスが許可されます。 図 6: シングルテナントとサービスを共有する SaaS プロバイダー 例を見てみましょう。パートナーが組織と共有している SaaS サービスがあると想定します。認証と認可の観点から、SaaS プロバイダーは、指定された組織に属する主体者から発信された認証済みのリクエストに対してのみ権限を付与したいと考えています。このためパートナーは、次のポリシーを作成し、SaaS サービスにこのポリシーを適用します。 { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-123456customer1" ] } } } ] } このポリシーにより、組織 ID (o-123456customer1) から SaaS サービス (svc-0b847e0ccdc496cb3) へのリクエストが許可されます。 マルチテナントモデル マルチテナントモデルでは、パートナーが複数の顧客と VPC Lattice サービスを共有します。 SaaS サービス全体で顧客間でリソースを共有し、パートナーのサービスへのアクセスにはテナントごとの識別認証、パスベースの認証ポリシー、またはアプリケーションベースの別のメカニズムを使用して、リソースやカスタマーデータへのアクセスを定義します。 このモデルでは、パートナーの認証ポリシーが、顧客間の認証済み要求をすべて許可するか、または特定の顧客に対してのみ特定のパスへのアクセスを許可します。これは図 7 に示されています。 図 7: マルチテナントとサービスを共有する Saas プロバイダー 前の例を拡張して、パートナーは複数の顧客が利用する単一の SaaS サービスを展開し、サービスパスで認可を分離します。 これを実現するために、パートナーは前の例のポリシーを次のような例に変更し、SaaS サービスにポリシーを適用します。 { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer1" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-123456customer1" ] } } }, { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer2" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-123456customer2" ] } } } ] } 次に、パートナーが顧客 1 に /customer1 パスを使用して SaaS サービスへのアクセスを許可します (組織 o-123456customer1 から)。パートナーは顧客 2 に /customer2 パスを使用して SaaS サービスへのアクセスを許可します (組織 o-123456customer2 から)。 同じサービスを複数の顧客で共有しますが、認証ポリシーによって、トラフィックの発信元に応じて異なるパスへのアクセスを許可または拒否できます。 顧客視点 お客様の観点では、どのサービスがパートナーの SaaS サービスにアクセスするのか、また SaaS サービスからサービスネットワーク内の他のサービスへの接続を開始するかどうかを検討する必要があります。 認証ポリシー内の複数の条件に基づいてアクセスを許可または拒否する、細かく制御可能な認証ポリシーを作成できます。 自身のサービス間通信に作成するポリシーと同様に、管理者はサービスネットワークに追加される各 SaaS ソリューションに対してどのようなアクセスを与えるかを決定する必要があります。次に図 8 を見てみましょう。 図 8: フロントエンド VPC は、バックエンド サービスと SaaS サービスへのリクエストを開始します。他のリクエストはすべて拒否されます。 この例では、バックエンドサービスと SaaS サービスの 2 つのサービスをサービスネットワークに関連付けています。 さらに、フロントエンド VPC からサービスネットワークへの接続を開始できるように、フロントエンド VPC との VPC 関連付けを作成しています。 フロントエンド VPC からバックエンドサービスと SaaS サービスへの接続のみを許可し、他の VPC からの接続は許可しない設定にします。 この設定を行うには、以下のポリシーを記述し、サービスネットワークに適用します。 { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*", " arn:aws:vpc-lattice:us-east-1:111122223333:service/svc-0be0b12dd1d277c58/*", ], "Condition": { "StringEquals": { "vpc-lattice-svcs:SourceVPC": " vpc-1a2b3c4d" } } } ] } このポリシーにより、フロントエンドサービス (vpc-1a2b3c4d) がバックエンドサービス (svc-0be0b12dd1d277c58) と SaaS サービス (svc-0b847e0ccdc496cb3) の両方に要求を送信できるようになります。 これで、お客様のサービスと組織で利用されているパートナーの SaaS サービスの間でサービス間通信を行うためのサービスネットワークが構築できました。 注意点 VPC Lattice でサポートされているリスナープロトコルとポートは、 VPC Lattice ユーザーガイド に記載されています。 VPC Lattice サービスの所有者のみがそのサービスにアクセス権限ポリシーを追加できます。所有者があなたにサービスを共有した場合は、サービスネットワークまたはサービスネットワーク内のサービスに対してアクセス権限ポリシーを作成できます。 結論 この記事では、 Amazon VPC Lattice を使用してサービスネットワーク全体のサービスと SaaS サービス間の安全な接続を提供する方法について説明しました。 パートナーがあなたの AWS アカウントまたは組織とサービスを共有する方法を確認しました。 次に、パートナーとあなた両方がサービスネットワーク内のサービス間通信を許可または拒否するために認証ポリシーを作成する例を示しました。 この記事に関する質問がある場合は、AWS re:Post に質問を投稿してください。 Amazon VPC Lattice の詳細については、 Amazon VPC Lattice ドキュメント および VPC Lattice について説明する追加の Networking & Content Delivery ブログ投稿 を参照してください。 本記事は、 Connecting Saas services within a VPC Lattice service network を翻訳したものです。翻訳は Solutions Architect の 長屋 が担当しました。

こんにちは、AWS ソリューションアーキテクトの梅田です。 2024年 05 月 29 日に 「生成 AI で教育を加速 ! 最新トレンドと実践ガイド」 というタイトルでウェビナーを開催しました。 開催報告として、ウェビナーの内容と当日の収録映像を紹介します。 開催の背景 生成AIが普及し始めて1年以上が経過し、さまざまな業界で活用事例が出てきました。教育分野においては、「どのように活用したらよいかわからない」「導入を検討しているがハードルが高い」という声を聞くことも増えました。 本ウェビナーでは、以下の2点を中心にご紹介しました。 AWSが提供する生成AI の最新アップデート情報 クラスメソッド社のクラウドソリューション導入・運用サポートサービス EdTech企業様や教育機関様がお抱えの課題に対し、生成AIの活用方法や、クラウド基盤の構築・運用をデモを交えながらワンストップでお応えする内容となっていました。 セミナー内容紹介 / 収録録画 タイトル : 生成 AI で教育を加速 ! 最新トレンドと実践ガイド 開催日 : 2024 年 05 月 29 日 (水) 動画視聴は こちら 資料は こちら Amazon Bedrock で Claude 3 を使いこなそう！(アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 技術統括本部 シニアソリューションアーキテクト　松井佑馬) Amazon Bedrock で Claude 3 を使いこなそう！ このセッションでは、高速で高性能な注目の最新基盤モデルである Anthropic 社の Claude 3 を、AWS の生成 AI サービスである Amazon Bedrock で使いこなす方法として、 Amazon Bedrock および Claude の特徴やユースケース、セキュリティ、プロンプトエンジニアリングなどを紹介しました。 まずセッションの初めに、教育分野におけるAIの活用について説明しました。まず、教育のDXを加速するため、個別最適な学びと協働的な学びの実現、および先生の働き方改革を実現することを課題としました。そこで、生成AIを活用することで、これらの課題解決を加速できると考えています。 続いて、 Amazon Bedrock では、様々な基盤モデルを単一のAPIで利用できること、セキュリティとプライバシーにも配慮されていることを説明しました。 そして Amazon Bedrock の基盤モデルの中でも Anthropic 社の Claude 3 について紹介しました。 Claude 3 には 3 つのモデル (Opus、Sonnet、Haiku) があり、精度・速度・コストに応じて選択できること、また特徴としてHaikuの高速性やマルチモーダル対応を挙げました。最後により望ましい結果を得るためのプロンプトの工夫 (プロンプトエンジニアリング) について説明しました。 これらの情報が生成AIの教育でのユースケースを検討したり、実際に Amazon Bedrock で生成AIを使い始めたりする際の参考になれば幸いです。 (参考情報) 公共機関における生成 AI の活用案 Generative AI Use Cases JP – すぐに業務活用できるビジネスユースケース集付きの安全な生成AIアプリ実装 生成AIをお客様のアプリに組み込む(アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 技術統括本部 ソリューションアーキテクト　梅田昌太) 生成AIをお客様のアプリに組み込む このセッションでは、以下のトピックが取り上げられました 生成AIをお客様アプリへ組み込むヒント RAG(Retrieved Augmented Generation) というアプローチ Knowledge bases for Amazon Bedrock の紹介 RAG というアプローチを通して生成AIをどのようにお客様のアプリケーションに組み込むかについて説明しています。 RAG(Retrieved Augmented Generation)とは RAGは、Retrieve(検索)とGeneration(生成)の2つのステージを組み合わせるアプローチです。外部データを元に作成されたナレッジベースから質問に関連する情報を検索し、その情報と入力クエリを組み合わせて高品質な回答を生成します。 このアプローチにより、生成AIの「幻覚(hallucination)」問題を抑制し、回答の精度と一貫性を向上させることができます。AWSでは Knowledge bases for Amazon Bedrock を用いることで、 簡単にRAGが実装できることを紹介しています。 また、実際にお客様のアプリケーションへ生成AIを組み込むためには、生成AI機能だけでなく、アプリケーションを実行する基盤やデータの蓄積、収集の重要性についても触れられています。 AWSはすでにご利用いただいてるお客様にも、これからご利用いただくお客様にも、簡単にRAGを試せる環境があります。是非RAGを試して回答の品質を高められるか検証してみてください。 生成AIの信頼性を上げてビジネスを加速させるためのデータ活用術（クラスメソッド株式会社 新規事業部 ソリューションセールス 熊谷 敏宏 氏） 生成AIの信頼性を上げてビジネスを加速させるためのデータ活用 本セミナーでは、企業における生成AIの活用方法を、データ活用という視点から解説しています。 まず、企業が持つデータの90%が非構造化データであると指摘し、これらの活用が競争優位性につながる可能性に言及していて、非構造化データの活用が、生成AIの登場により加速度的に進み、業務効率化・意思決定の質向上・顧客理解の深化といったメリットをもたらすことを紹介しています。 生成AI活用の具体的な手法として、RAG（Retrieval-Augmented Generation）が紹介されています。 RAGは、大規模言語モデル（LLM）に追加情報を与えて回答を生成する方法で、自社データを活用した独自のAIシステムを構築できます。 しかし、RAGの実装には幾つかの課題があることも指摘されています。 例えば、CSVファイルの途中が抽出されてしまう問題や、似たようなドキュメントの内容が混同される問題などです。 これらの課題に対して、ファイルの分割やタグ付け・フィルタリングなどの具体的な解決策が提案されています。 最後に、クラスメソッド社が提供する「らくらくRAG導入パック」というサービスが紹介されています。 このサービスは、企業が短期間で自社データを活用したAIチャットボットを導入できるソリューションです。 セミナー資料全体を通して、生成AIの活用が企業の非構造化データ活用の敷居を下げ、ビジネス課題解決に大きな可能性をもたらすことが強調されています。 同時に、効果的な活用のためにはデータの前処理や加工が重要であることも指摘されており、企業が生成AIを導入する際の具体的なポイントが示されています。 おわりに 本セミナーの内容が、生成AI導入の一助になれば幸いです。 AWSの活用やご提案に関するご相談、ご要望がありましたら、担当営業、もしくは公式サイトの お問い合わせ までお問い合わせください。 このブログは、2024 年 06 月 18 日時点の情報に基づいてソリューションアーキテクト 梅田が執筆いたしました。

本ブログは株式会社サルソニード様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの小林大樹です。 昨今、生成 AI を活用して業務効率化を図るお客様が増えています。特に、大量のテキストデータを扱うマーケティング業務では、記事作成や校正、リライトなどのタスクを生成 AI に任せることで、人的リソースを削減し、本来のマーケティング活動に注力できるようになってきました。 今回は、Web マーケティングのワンストップソリューションを提供されている 株式会社サルソニード様 が、 Amazon Bedrock と Amazon Kendra を活用して法律関連オウンドメディアの記事作成を効率化し、記事のリライト業務にかける時間を 70 % 削減された事例をご紹介します。 お客様の状況と検証に至る経緯 サルソニード様のマーケーターはマーケティング業務だけでなく、記事執筆業務や WEB サイト制作業務も一貫して担当しています。業務拡大にマーケティングチームの増員が追いつかず、マーケティングチームのリソース不足が続いていました。 そこで、生成 AI を活用した業務効率化基盤の構築を検討していましたが、1名のエンジニアのみで社内システムや複数の自社サービスの開発・運用を担当していたため、生成AIの環境構築に充分なリソースを割くことが困難な状況でした。その一方で、機微情報を扱っていることから、社員の方々が外部の生成 AI ツールを各々契約して勝手に利用する、いわゆるシャドー IT を防ぐためにも喫緊の対応が必要となっていました。 こうした課題を解決するため、Amazon Bedrock と Amazon Kendra を活用した RAG（検索拡張生成; Retrieval Augmented Generation) チャット環境を社内マーケター向けに提供し、記事のリライト業務を生成AIによってサポートする取り組みを始めました。 ソリューション／構成内容 環境構築にあまりリソースを割けない状況の中、セキュリティを担保した生成 AI 環境を構築するために、AWS が OSS (オープンソースソフトウェア) として提供している「 GenU (Generative AI Use Cases JP) 」を活用しました。GenU は以下のようなアーキテクチャで構成されており、生成 AI を用いたチャットボットや、要約や文章構成、画像生成など様々なユースケースを体験することができるアプリケーションとなっております。また、上記のユースケースに加え、RAG による社内情報に基づいた AI チャットボットなども利用することができます。 RAG について少し補足します。RAG では、ユーザーが知りたい内容に対してまず Amazon Kendara に対して検索を行い、得られた検索結果を参考情報として生成 AI が回答を生成します。RAG を利用することで、生成 AI モデルが知らない社内のマニュアルや規定といった情報についても回答を生成することができます。Amazon Kendra は Amazon S3 やウェブサイトなど、複数のデータソースからデータを簡単に取り込み、検索に適したインデックスを作成してくれます。今回の実装では、社内の過去の記事データやマニュアル類を Amazon Kendra に同期するために ECS Scheduled Task を利用し、以下のような処理を定期実行するジョブを作成しています。 ECS Scheduled Task でジョブを実行 1-1. 自社プロダクトのDB (Amazon Aurora PostgreSQL) から対象データを抽出 1-2. データをプレーンテキストに整形 1-3. AWS SDK で S3 にアップロード 1-4. Amazon Kendra の S3 Connector を利用してインデックスを同期 上記の実装を行うことで、自社 DB やその他のデータソースから検索対象データを柔軟に抽出し、RAG のデータソースとして利用することが可能となっています。加えて、GenU では生成 AI ツールを社内展開する際に便利な以下の機能を備えています。 Amazon Cognito を利用したユーザー認証機能 AWS WAF を利用した IP 制限等のアクセス制御機能 サルソニード様では、社内に生成 AI ツールを展開するにあたって、セキュリティを確保するために上記機能を有効化していただき、ユーザー認証やアクセス制限機能を備えたセキュアな環境を短期間で構築することができました。このように、GenU を利用することで、簡単かつ迅速に環境構築を行うことができたため、1 名のエンジニアがわずか 2 日で環境構築から社内リリースを行うことができました。 導入効果 前述の通り、サルソニード様は GenU を活用した生成 AI ツールを社内ユーザー向けにリリースされました。具体的には、Web メディア記事の制作や校正に Amazon Bedrock から利用可能なモデルを使った通常の生成 AI チャットを利用し、社内情報や専門知識が必要なマーケターの質問への回答には Amazon Bedrock と Amazon Kendra を組み合わせた RAG チャットを利用しています。この生成 AI ツールの導入により、サルソニード様では以下のような効果が得られました。 記事のリライト業務にかける時間を70%削減でき、マーケターはマーケティング業務に集中できるようになった 会社公認の生成 AI ツールを使える環境を GenU で提供することで、生成 AI のシャドー IT 利用の防止につながり、AWS 内で稼働する環境のため、情報漏洩のリスクもコントロールできるようになった 今回は「マーケターの記事執筆業務の効率化」という切り口で導入いただきましたが、「従業員が利用できるセキュアな生成 AI ツールを会社として提供したい」といったお客様や、「社内の知見と生成 AI を組み合わせて利用したい」というお客様にもおすすめできるソリューションとなっています。 まとめ 今回は、Amazon Bedrock と Amazon Kendra を活用した生成 AI ツールを活用し、記事執筆業務を効率化する、というサルソニード様の挑戦についてご紹介いたしました。 生成 AI は単体でも便利なツールですが、今回のように社内の過去の知見やマニュアル、規定類といった情報と、生成AIを組み合わせることで、業務効率化を実現しているお客様も多くいらっしゃいます。 セキュアかつプライバシー保護されたソリューションを簡単に構築・運用できる GenU を利用して、生成AIの社内活用を推進してみるのはいかがでしょうか。 AWS を利用した生成 AI の活用にご興味をお持ちのお客様は、お気軽にご相談いただければと思います。 ソリューションアーキテクト 小林 大樹 (X – @kobayasd )

本記事は、以下 4 名による共著です。 株式会社オルツ 経営管理部 技術本部付アシスタント 高橋 亜美 株式会社オルツ AI Solutions 事業部 PoC エンジニア 竹内 慎修 株式会社オルツ 経営企画部 マネージャー 西澤 美紗子 アマゾン ウェブ サービス ジャパン合同会社 機械学習パートナーソリューションアーキテクト 本橋 和貴 大規模パラメータを持つ大規模言語モデル (LLM) によるビジネスの変革が期待される一方で、その利用には膨大な計算リソースとエネルギーを必要とするため、環境に対する負荷の増大が懸念されています。そのため、軽量でありながら大規模モデルと同等の精度を実現するための小規模パラメータモデルの研究が活発化しています。その流れで、 P.A.I.®️ (パーソナル人工知能) をはじめ、AI クローン技術でつくり出すパーソナル AI の開発および実用化を行う 株式会社オルツ は、軽量型大規模言語モデル LHTM-OPT (ラートム・オプト) を 2023 年 10 月にリリースしました。また、LHTM-OPT は、2024 年 3 月に、 AWS Marketplace 上における世界初の日本語 LLM として公開されました。AWS Marketplace からモデルを購入することで、利用者は大規模言語モデルや機械学習の専門知識がなくても、簡単に LHTM-OPT を活用したアプリケーションやサービスを構築できます。 以下では、AWS Marketplace に出品されている LHTM-OPT を Amazon SageMaker にデプロイして推論を実行する方法を紹介します。 LHTM-OPT とは LHTM-OPT (ラートム・オプト) とは、オルツが開発した、日本語専用のプライベートな軽量型大規模言語モデルです。LHTM-OPT はオープンデータの学習だけでなく、オルツの独自の指示データや対話データのデータセットも利用し、高い回答精度を達成しています。2023 年 10 月のリリース以降、日本国内の様々なアプリケーションで利用されています。パラメータ数が最適化された LLM であるため、小規模 GPU マシンでも高速の推論、回答生成が可能です。 2023 年 10 月にリリースした時点では、 alt Developer API 利用とオンプレミスの場合のみデプロイが可能でした。今回、 AWS Marketplace に公開 することにより、AWS の機械学習開発運用プラットフォームである Amazon SageMaker に簡単にデプロイできるようになりました。 本記事では 7B パラメータの LHTM-OPT バージョン 1.0 について解説します。このモデルは、2023 年 10 月リリース時点では、日本語 LLM を評価する Rakuda ベンチマークにおいて、日本語商用プライベート LLM として最高性能を記録しました。また、日本語言語理解ベンチマーク「 JGLUE (Japanese General Language Understanding Evaluation) 」の 8 タスク平均においても、商用モデルとして国内最高スコア 56.12 を記録しました (LHTM-OPT の JGLUE 主要 4 タスク平均のスコアは 75.08 です)。これは同じサイズの競合モデルに比べて高い数値となっています。 AWS Marketplace とは AWS Marketplace は、アマゾン ウェブ サービス (AWS) 上で動作する多種多様なサードパーティ製ソフトウェア、データ、サービスを見つけ、購入し、デプロイ、管理するためのデジタルカタログです。セキュリティ、ネットワーキング、ストレージ、機械学習、IoT、ビジネスインテリジェンス、データベース、DevOps など、幅広いカテゴリーの製品が掲載されています。ユーザーは AMI (Amazon Machine Image) や SaaS など様々な形式で提供される製品を選択し、数回のクリックでこれらのソリューションを簡単に起動できます。無料トライアル、時間単位、月単位、年単位、複数年、ライセンス持ち込み (BYOL) モデルなど、柔軟な料金オプションもあり、すべて AWS のひとつの請求書で一括して支払いができます。AWS Marketplace を利用することで、ビジネスソリューションの構築や運用に必要なソフトウェアの調達にかかる時間と手間を大幅に削減できます。 AWS Marketplace には機械学習製品も豊富に取り揃えられています。すぐ利用できる事前学習済みモデルパッケージや、独自のデータセットを用いてファインチューニング可能なアルゴリズムといった機械学習ソリューションが提供されており、機械学習の専門知識がなくても、簡単に機械学習を活用したアプリケーションやサービスを構築できます。画像認識、自然言語処理、予測分析、異常検知などの機能を持つ製品が用意されており、ユーザーは自社のビジネスニーズに合わせてそれらを選択し、Amazon SageMaker 上でモデルを学習、デプロイすることができます。近年では LLM の出品も増えており、AWS Marketplace の機械学習製品を活用することで、機械学習の導入にかかる時間とコストを大幅に削減でき、迅速にインテリジェントなアプリケーションを構築できるようになります。 AWS Marketplace で LHTM-OPT をサブスクライブする AWS Marketplace に掲載されている LHTM-OPT を利用するには、初めに製品をサブスクライブします。 LHTM-OPT の製品ページ から製品の特徴などを確認した上で、サブスクライブしていきましょう。例えば、料金情報欄は以下の通りです。 図 1 : AWS Marketplace における LHTM-OPT の料金情報 AWS Marketplace の機械学習モデルパッケージ製品の料金欄にはソフトウェア料金 (Software Pricing) とインフラ料金 (Infrasstructure Pricing) が記載されています。LHTM-OPT は時間課金の料金設定になっており、ソフトウェア自体の料金としては 1 時間あたり 1.20 USD でご利用いただけます。それだけでなく、推論を実行する基盤としての SageMaker の利用料金もかかる点にはご注意ください。 料金などが確認できたら製品をサブスクライブしていきましょう。 LHTM-OPT を利用する AWS アカウントにログインする。 LHTM-OPT の製品ページ を開き、右上の「Continue to Sucscribe」ボタンをクリックする。 図 2 : LHTM-OPT の製品ページからサブスクライブに進む 料金や EULA (End User License Agreement) を確認し、「Accept offer」ボタンをクリックする。 図 3 : 料金や EULA の確認 サブスクライブが完了したら “Thank you for subscribing. You can now use your product” と表示されます。これで製品を利用する準備ができました。次に、「Continue to configuration」ボタンをクリックし、お客様の AWS 環境内に LHTM-OPT をデプロイしていきます。 LHTM-OPT のサブスクライブが完了した様子 サブスクライブした LHTM-OPT のデプロイ 「Continue to configuration」ボタンをクリックすると Configure and launch ページが開きます。ここでは、「Avalidable launch methods」に「SageMaker console」を指定します。「Region」では、デプロイ対象のリージョンを選択します。ここでは「Asia Pacific (Tokyo)」を選択しています。「Amazon SageMaker options」ではリアルタイム推論エンドポイントを作成するか、バッチ変換ジョブを実行するか選択できます。ここでは「Create a real-time inference endpoint」を選択しています。また、以降のコード内で使用するので、「Product Arn」をコピーし、メモしておいてください。 図 5 : Amazon SageMaker におけるデプロイオプションの指定 このまま GUI ベースでデプロイを進めることもできますが、以降では Python コードでモデルをデプロイする手順を紹介します。 まず、上記の製品の ARN (Amazon Resource Name) を変数に格納します。合わせて、必要なモジュールや SageMaker ランタイムのクライアントなどをセットアップします。 import json import boto3 import sagemaker from sagemaker import ModelPackage, get_execution_role role = get_execution_role() region = “ap-northeast-1” sagemaker_session = sagemaker.Session() sagemaker_runtime = boto3.client("runtime.sagemaker", region_name=region) model_package_arn = ( "<コピーした ARN に置き換えてください>" ) 次に、モデルのデプロイと推論エンドポイントの作成をします。デプロイするモデル名と SageMaker インスタンスタイプは必要に応じて変更することができます。ただし、インスタンスタイプは こちらの製品ページ で推奨しているインスタンスタイプ一覧から選ぶ必要があります。 推論エンドポイントを作成するために 10 分ほど待ちます。 model_name = "lhtmopt" real_time_inference_instance_type = "ml.p3.2xlarge" # Create a deployable model from the model package. model = ModelPackage( role=role, model_package_arn=model_package_arn, sagemaker_session=sagemaker_session, ) # Deploy the model predictor = model.deploy( initial_instance_count=1, instance_type=real_time_inference_instance_type, endpoint_name=model_name, ) モデルのデプロイが終わるとリアルタイム推論エンドポイントの利用準備が完了し、推論を実行できるようになります。 LHTM-OPT で推論を実行する LHTM-OPT で推論を実行する際、インプットは以下の 3 つの形式で渡すことができます。 方法 1 : デフォルトパラメータと質問 これは最もシンプルな形式です。ペイロードには質問を含むプロンプトのみを渡します。推論パラメータはデフォルトで設定されているものが利用されます。 payload = { "prompt": "質問：世界で最も高い山はなんですか？\n答え：", } 方法 2 : 推論パラメータと質問 推論パラメータは任意の値を設定することもできます。ペイロードに推論パラメータのキーと値を含めることでパラメータをセットし、アウトプットをコントロールすることができます。 payload = { "prompt": "質問：世界で最も高い山はなんですか？\n答え：", "max_new_tokens": 50, "temperature": 0.7, "top_k": 40, "top_p": 0.9, "do_sample": True, "repetition_penalty": 1.2, "skip_prompt": True, } 方法 3 : Llama 2 テンプレートでインプット プロンプトは Llama 2 テンプレートの形式に構造化することも可能です。これにより、システムプロンプトを明示的に指定することができます。 payload = { "prompt": """[INST] <<SYS>> あなたは優秀な日本人のアシスタントです。 <</SYS>> 世界で最も高い山はなんですか？ [/INST]""", "temperature": 0.7, “top_k": 40, } 推論を実行 上記のペイロードを用いて推論を実行するためには、次のような Python 関数を使用してください。 # real-time inference def invoke_endpoint(endpoint_name, payload): response = sagemaker_runtime.invoke_endpoint( EndpointName=endpoint_name, ContentType=”application/json”, Body=json.dumps(payload), ) return json.loads(response["Body"].read().decode("utf-8")) 次のコードで推論を実施し、結果を出力します。 result = invoke_endpoint(model_name, payload) print(f"Result: {result}") 応答結果は次のようになります。 Result: {'message': 'OK', 'text': '世界で最も高い山は、ヒマラヤ山脈にあるエベレストです。標高8,848メートル（29,029フィート）です。チベット自治区とネパールの国境付近に位置します。1953年5月29日に英国隊が初登頂に成功したそうです。'} LHTM-OPT の応用的なユースケース LHTM-OPT は様々なユースケースに対応することができます。 例えば、LHTM-OPT は LangChain、LlamaIndex などのフレームワークと組み合わせることによって RAG、文章要約、文章生成などに応用することができます。LHTM-OPT のファインチューニングを実行するための API は公開していませんが、今後、提供する予定です。 オルツは現在、プライベート LLM の開発に関するコンサルティングや、企業独自のニーズに合わせたカスタマイズ、特定の業務に特化した LLM の開発支援も行っております。引き続き、日本社会における真の DX の実現に向けて、大規模言語モデルや生成 AI を活用したサービスの開発・提供に邁進し、社会に新たな価値を提供してまいります。 生成 AI の受託開発および LLM を活用した DX プロジェクト については、株式会社オルツ AI Solutions 事業部 (gptsolutions@alt.ai) にお問い合わせください。 あと片付け 無駄な費用が発生しないよう、推論エンドポイントを利用しなくなった場合、次のコードで削除してください。 sagemaker_client = boto3.client(“sagemaker”, region_name=region) sagemaker_client.delete_endpoint(model_name) sagemaker_client.delete_endpoint_config(model_name) まとめ 本記事では、AWS Marketplace から利用可能な軽量型大規模言語モデル LHTM-OPT 1.0 について紹介しました。LHTM-OPT の SageMaker におけるデプロイ方法と推論の実行方法についても解説しました。LHTM-OPT は小規模 GPU マシンでも実用的に動作する、パラメータ数が最適化された大規模言語モデルであり、様々なアプリケーションに適用可能です。ぜひ、 LHTM-OPT 1.0 を AWS Marketplace からお試しください 。 オルツは、今後も継続して様々なベンチマークで評価を行い、モデルをブラッシュアップし、LHTM-OPT 2.0 や LHTM-3 などをリリースする予定です。また、本モデルを基盤として自動質問応答、議事録自動要約、情報抽出、会話理解、予測分析のデータ整理・作成などの高度な処理が必要な問題に対応可能な多くのアプリケーションを実装していきます。 著者について 本橋 和貴 (Kazuki Motohashi / @kmotohas ) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。

このブログは‘“ Revolutionizing Generative Biology with AWS and EvolutionaryScale ”を翻訳したものです。 本日、AWS は EvolutionaryScale と提携し、同社の新しいバイオロジー向け最先端言語モデルを、創薬からカーボンキャプチャまで、さまざまなアプリケーションを推進する科学者や研究者に提供することを発表する運びとなり、大変興奮しています。 この発表により、EvolutionaryScale の最先端で最高水準の言語モデルファミリー ESM3 を AWS で利用可能になります。この提携により、生成的で多様な ESM3 モデルファミリーを含む EvolutionaryScale の最先端モデルを、業界をリードする AWS のインフラストラクチャ、エンタープライズグレードのセキュリティ、プライバシー対策、ヘルスケア・ライフサイエンス業界および生成 AI 向けの特化したサービス、生成 AI の機能(ファインチューニング、ガードレール等)と組み合わせることができます。これらは現在、製薬企業やバイオテックにより研究が行われている分野です。これには、生成 AI および機械学習に AWS を既に利用している、数十万人の AI /機械学習を利用する顧客と、上位 10 社のグローバル製薬企業 9 社が含まれ、この分野のさらなる民主化が促進されます。 ESM3 のような基盤モデルを使えば、研究者は複雑なマルチドメインタンパク質を一から生成したり、タンパク質設計のワークフローを作成したり、機能的な理解を組み込むことができます。ESM3 の強力な機能により、自然界には存在しない全く新しいタンパク質の創造が可能になり、科学者や研究者は革新的な「プログラム可能なバイオロジー」のアプローチを取ることができます。これにより、新薬の市場投入までの時間とコストを数年間と数十億ドルコストダウンできる可能性があります。 お客様は Amazon SageMaker を通じて ESM3 を簡単に利用開始でき、後にリリースされる Amazon Bedrock のサポートにより、 AWS HealthOmics を使ってエンドツーエンドの創薬ワークフローを完全自動化することができます。 Amazon Bedrock は、基盤モデルを使った生成 AI アプリケーションを構築・スケーリングする最も簡単な方法です。 ライフサイエンス業界での生成 AI の大きな機運: AWS は、さまざまな業界で生成 AI のイノベーションを加速する最前線にあり、大規模言語モデル (LLM) や基盤モデル (FM) の力を活用できるよう組織を支援しています。 Amazon Bedrock を利用して高性能の生成 AI モデルに簡単にアクセスできる数万社のお客様、 Amazon SageMaker で数百のプリトレーニングモデルを提供している AWS は、生成 AI アプリケーションの構築とスケーリングを簡素化しています。ライフサイエンス業界では生成 AI への熱気と機運が非常に高く、プロセスの自動化から研究や発見の仕方を根本的に変革するまで、お客様がビジネスを変革しています。例えば、 アストラゼネカ はゲノミクスを活用して創薬と精密医療の変革を加速し、研究者が洞察を迅速に科学的知見に変えられるようにしています。ギリアドは、企業全体のさまざまなソースからの非構造化情報の大量を迅速に分析できるよう、主要データセットから洞察を生成しています。 ファイザー は Bedrock や SageMaker などのサービスを使い、医学/科学コンテンツや特許出願を作成する AI ソリューションを展開し、画期的な成果を早期に患者に届けられるようにしながら、年間最大10億ドルのコスト削減も可能にしています。 そこで本日、EvolutionaryScale との、ライフサイエンス業界の研究開発を変革することを目指す共同イニシアティブと、 Go-To-Market での提携を発表する運びとなり、大変喜ばしく思います。 EvolutionaryScale は、バイオロジー向けの最先端言語モデルのトレーニングと適用を主導するリーディングチームで、バイオロジーデータへの大規模言語モデリングの最初の適用例の1つである Evolutionary Scale Modeling (ESM) モデルファミリーの開拓者です。彼らはバイオロジーへの生成 AI の適用で、バイオロジー特化の最初のトランスフォーマー言語モデル、スケーリング則、生物学的配列の構造予測手法の開発など、主要なマイルストーンを達成しています。本日、EvolutionaryScale は、この重要な分野で全く新しい地平を切り開く、初の生成的で多様な言語モデルファミリー ESM3 の発表を行いました。 生成 AI がバイオロジーを変える可能性: 生物学的配列を「生命の言語」と捉えることで、タンパク質工学やデザインの分野に生成 AI の手法を適用する可能性が広がります。大規模言語モデルが膨大なテキストデータセットで学習することで言語理解を示す有用なアシスタントになるのと同様に、ジェネレーティブ・バイオロジーモデルは大量のタンパク質配列データから「タンパク質の言語」を学習できます。これらのモデルはこれらの配列内のパターンや関係性を理解することで、創薬設計、酵素工学、合成生物学などの用途に合わせて機能的な新規タンパク質配列を生成できるのです。タンパク質はテキストとは 3 次元構造が異なりますが、これは生命の基本単位に関わる分野で生成 AI の力を活用して発見やイノベーションを加速する可能性を示唆しています。この技術は、進化、分子生物学、人工知能、医療、人々の健康をつなぐ変革の中心にあります。 ESM3: ジェネレーティブ・バイオロジーの画期的成果 EvolutionaryScale の ESM3 は、配列、構造、機能を同時に推論できるバイオロジー向けの画期的で最先端の生成モデルで、従来のタンパク質言語モデルには無い機能です。38 億年の進化を経た数十億のタンパク質配列で複数のモダリティを学習した ESM3 は、さまざまなソースからの複雑なバイオロジーデータを理解し、自然界には存在しない全く新しいタンパク質を生成できます。ESM3 モデルファミリーには、3 つの独自モデル(パラメータ数 98B、7B、1.4B)と 1 つのオープンソースモデル(パラメータ数 14 億)が含まれ、オープンソースバージョンは本日から Amazon SageMaker と AWS HealthOmics で、2024 年後半に Amazon Bedrock でも利用可能になる見込みです。 ESM3 モデルを使えば、お客様は以下のことが可能になります。 配列、構造、機能の「言語」を理解した ESM3 を使い、複雑なマルチドメインタンパク質を一から生成できる。 異なるモダリティに基づいて個々のドメインを設計し、それらを組み合わせて新規タンパク質を作れるタンパク質設計ワークフローを作成できる。 抗体の理解を組み込める: ESM3 は抗体配列と構造を非常に良く理解しているため、in silico で多様化、最適化、進化工学などの操作が可能。 ESM3 で作られた蛍光タンパク質 esmGFP バイオロジー基盤モデル (biological Foundation Models: bFM) を安全に民主化: 汎用の LLM や FM と同様に、AWS の包括的なヘルスケア・ライフサイエンス業界および生成 AI 向け特化サービスポートフォリオ (Amazon SageMaker 、 AWS HealthOmics、 AWS HealthScribe、 Amazon Bedrock など)を通じて、研究者は ESM3 のような bFM に簡単にアクセスできるようになります。Amazon SageMaker と AWS HealthOmics から始まり、お客様はEvolutionaryScale の最新オープンソースモデルバージョンを活用できるようになり、独自の ESM3 モデルファミリーもすぐにこれらのサービスと Amazon Bedrock で利用可能になります。フルマネージドなAWSサービスにより、研究者は ESM3 のようなパワフルな bFM を創薬ワークフローにカスタマイズしてシームレスに統合する最も簡単な方法をご利用いただけます。 この発表により、お客様は独自データセットで ESM3 をファインチューニングでき、独自データをプライベートに保ちながら、医薬品開発での画期的な発見を可能にし、イノベーションを加速できます。また、お客様はAWSの業界をリードする生成 AI インフラ (高性能 GPU インスタンスや AWS Trainium のトレーニング向け機械学習専用アクセラレータ、AWS Inferentia の推論向け機械学習専用アクセラレータなど) を活用してこれらのイノベーションをスケーリングできます。AWS の並外れた計算能力により、お客様は ESM3 のトレーニング、構築、実行を効率的に行えます。ESM3 のようなジェネレーティブ bFM を AWS サービスと統合することで、デプロイが簡素化され、データの暗号化処理、プライベートネットワーキング、HIPAA および GDPR コンプライアンスによる強固なセキュリティが確保されます。責任あるモデルの挙動をガイドするため、ガードレールが多層で組み込まれています。EvolutionaryScale の ESM3 は、有害なタンパク質の生成などの安全性リスクを軽減するよう設計されています。Amazon Bedrock のガードレールにより、お客様は倫理的 AI ポリシーに沿った入出力へのカスタムフィルタを実装できます。この公平性、安全性、透明性へのコミットメントにより、bFM の驚くべき可能性が責任を持って実現されます。 バイオロジーにおける生成 AI の未来 このマイルストーンは、バイオロジーアプリケーション向けにカスタマイズされた生成 AI 搭載モデルの新時代の幕開けを告げるものです。飛躍的な前進であるESM3は、AWSの生成 AI 機能とEvolutionaryScale の革新的 AI モデルが、計算パワーとデータスケールの最前線で相乗効果を発揮することで、創薬のタイムラインを大幅に短縮する可能性を秘めています。この提携により、プログラム可能なバイオロジーを可能にし、ライフサイエンス企業は責任ある生成 AI の力を活用して創薬の境界を押し広げ、プロセスを合理化し、最終的には新しい治療薬をより早く患者に届けられるようになります。ターゲット特定の合理化、イノベーションの促進、開発時間とコストの削減、創薬の成功確率向上につながります。 著者について Matt Wood: Matt は AWS の AI 関連プロダクトの Vice President です。この役割において、彼は顧客、パートナー、内部の AWS チームと緊密に連携し、あらゆる業界における AI の効果的な活用を推進しています。 Matt はアマゾンに 14 年間在籍しており、クラウドビジネス全般 (Lambda、Kinesis、SageMaker、DeepRacer、Athena、EMRの立ち上げ支援を含む) に携わってきました。特に、データ、分析、機械学習、人工知能に重点を置いてきました。彼の情熱は、NFL、Cerner、Intuit、Pinterest、GE、FINRA、Celgene、NASA などの AWS 顧客と協力し、彼らのアイデアを実現することにあります。アマゾン入社前は、英国で医学を学び、機械学習の博士号を取得し、コーネル大学で博士研究員を務めていました。 このブログはヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー 片岡 が翻訳しました。

本記事は、2024年5月15日に公開された Data migration strategies to Amazon RDS for Db2 を翻訳したものです。 AWS は re:Invent 2023 で Amazon Relational Database (Amazon RDS) for Db2 を発表しました。RDS for Db2 は、 Amazon RDS に新しく追加されたデータベースエンジンです。 最適なパフォーマンスを実現するスケーラブルなハードウェアで、数分で Db2 データベースを展開できます。 また、Multi-AZ デプロイメントを使えば、別の Availability Zone にあるスタンバイデータベースインスタンスにデータを同期レプリケーションする、高可用性データベースを構築できます。 このブログでは、Amazon RDS for Db2 の組み込み機能と AWS Database Migration Service (AWS DMS) または Db2 Migration Tooling (Db2MT) を使用して、セルフマネージド型の Db2 データベースを RDS for Db2 に移行する手順を説明します。 まず、採用できる様々な移行戦略の概要を示し、次に移行方法について説明し、最後に移行の計画のためのベストプラクティスを紹介します。 マイグレーション戦略 マイグレーション戦略は、セルフホスティングの Db2 データベースのオペレーティングシステムによって異なります。 ソースデータベースとターゲットデータベースのオペレーティングシステムが同じ場合 (例えば Linux から Linux へ) 、そのマイグレーションは リホスト と呼ばれます。 ソースデータベースのオペレーティングシステムが宛先データベースとは異なる場合 (例えば z/OS から Linux へ) 、そのマイグレーションは リプラットフォーム と呼ばれます。 次の表は、ソースデータベースの基盤となるオペレーティングシステムに基づく リホスト と リプラットフォーム の詳細をまとめたものです。 マイグレーション戦略 リホスト リプラットフォーム 備考 オペレーティングシステム Linux Linux 以外 (z/OS、AIX、Windows など) ネイティブの IBM Db2 マイグレーションツール、DMS、サードパーティ製品を使用できます。 マイグレーションのスピード 高速 低速 リホストの方が変換が不要なので高速です。 リプラットフォームは変換が必要で時間がかかります。 Db2 オフライン リストア はい いいえ Db2 のバックアップとリストアを使用します。リストアが完了するまでダウンタイムが発生します。 Db2 オンライン リストア はい いいえ Db2 のバックアップとロールフォワードリストアを使用します。短時間のダウンタイムですが、完了までに時間がかかる場合があります。 Db2 エクスポートまたはインポート はい はい 論理マイグレーションには Db2 のエクスポートとインポートを使用します。リプラットフォームの場合は変換のために時間がかかります。 クライアントからのロード はい はい Db2 を使用します。 Amazon S3 からのロード はい はい リプラットフォームの場合は高速です。 AWS DMS はい はい レプリケーション IBM CDC レプリケーション はい はい レプリケーション IBM Q レプリケーション はい はい レプリケーション メタデータの忠実性(+) 高い 中程度 リプラットフォームの場合は忠実性に特に注意が必要です。 データの品質 高い 中程度 リプラットフォームの場合は品質に特に注意が必要です。 使いやすさ 簡単 複雑 リホストの方が簡単です。 導入のワークロード 低い 高い リプラットフォームには大きなワークロードが必要です。 (+)ソースからターゲットに移行される際、データベーススキーマの再構築方法によっては、メタデータが正確に再現されないことがあります。例えば、自動インクリメントの開始点、シーケンス、隠し列、チェック制約、外部キー制約の適用などが正しく適用されない事があります。 Amazon RDS へのリホスト (同一オペレーティングシステムへの移行) セルフ運用している Db2 データベースが、リトルエンディアンの 64 bit Linux プラットフォーム上で実行されている場合、Amazon RDS for Db2 へリホストできます。 たとえば、Linux on Intel、AMD、Linux POWER LE (リトルエンディアン) 上のセルフ運用している Db2 データベースはリホストできますが、AIX、zLinux、Windows 上のものはリホストできません。 Amazon RDS へのリプラットフォーム (異なるオペレーティングシステムへの移行) セルフ運用している Db2 のオペレーティングシステムが Linux (リトルエンディアン) 以外の場合、ソースの Db2 データベースを Amazon RDS for Db2 にリプラットフォームする必要があります。 セルフ運用の Db2 データベースが AIX、Windows、zLinux などのオペレーティングシステム上で実行されている場合、Amazon RDS for Db2 でリプラットフォームできます。 再プラットフォームは、より広範な移行プロセスの第一段階と見なされ、組織はデータベースを迅速にAmazon RDS for Db2に移行し、その後、徐々に最適化や再アーキテクチャを検討することができます。 Amazon RDS for Db2 を使用して DB をリホストおよびリプラットフォームする移行方法 移行方法の選択は、ソースDb2のオペレーティングシステムの種類と許容できるダウンタイムによります。移行速度を確認するために、適切なサイズのデータベースを使ったテスト移行を行い、エンドツーエンドの移行時間を把握することをお勧めします。許容できるダウンタイムに応じて、一回限りの移行またはログレプリケーションを用いた移行のいずれかを選択できます。ビジネスニーズに基づいて適切なレプリケーション方法を選択するために、次の意思決定ツリーを参照してください。 Amazon RDS によるリホスト セルフ運用の Db2 データベースが、Linux 上で実行されている場合は、Amazon RDS for Db2 にリホストできます。Linux からの移行はデータ変換を必要としないため、再プラットフォームよりも簡単かつ短時間で完了します。移行には Db2 のネイティブツールを使用し、複雑なデータ構造の変更や最適化を避けます。 ワンタイムマイグレーション データベースのバックアップ、リストア、および切り替えを行う全体的な時間が許容できるダウンタイム内であれば、ワンタイム移行を利用できます。 セルフ運用の Db2 Linux データベースのバックアップを直接 Amazon Simple Storage Service (Amazon S3) にコピーし、Amazon RDS for Db2 でリストアするために、 Db2 Migration Tooling (Db2MT) を使用します。 Db2MT は、移行を完了するために必要なスクリプトを作成し、バックアップとリストアの両方を並列化して移行を高速化します。 次の図はそのソリューションアーキテクチャーを示しています。 手動でデータ移行を行う場合は、Amazon S3 からオフラインバックアップを復元するため、RDS for Db2 のストアードプロシージャ restore_database を呼び出すことができます。 ログレプリケーションを使用した移行 初期テスト移行によって測定された移行時間が許容できるダウンタイムよりも長い場合、A/Bデプロイメントアプローチを使用して、Linux上のセルフ運用のDb2からAmazon RDS for Db2へのログレプリケーションを使用した移行を実行できます。このアプローチでは、新しいRDS for Db2データベース（A）を旧データベース（B）と並行して使用し、準備が整った時点で切り替えを行います。 Db2MT は、前のセクションで説明したように、ユーザーが管理する Linux の Db2 のオンラインデータベースバックアップを直接 Amazon S3 に取得し、次に Amazon RDS for Db2 で復元するための手順を提供しています。Db2MT はまた、定期的にログを直接 Amazon S3 にアーカイブし、データベースをロールフォワードペンディングモードに維持して、ログを RDS for Db2 に適用する手順も提供します。 ロールフォワード 操作を完了することで、最終的に切り替えを行うことができます。 次の図は、このソリューションのアーキテクチャを示しています。 Amazon RDS for Db2 のストアードプロシージャ restore_database  を使用して、 backup_type  を  ONLINE に設定することで、オンラインバックアップイメージを復元できます。 Amazon RDS for Db2 のストアードプロシージャ rollforward_database  を使用して、アーカイブログを適用できます。 切り替え準備ができたら、ストアードプロシージャ  complete_rollforward を実行して、データベースの復旧を完了し、Amazon RDS for Db2 データベースを接続可能な状態にできます。 Amazon RDS へのリプラットフォーム もう 1 つの主要な課題は、AIX、Windows、メインフレー上の Db2 on Linux (ビッグエンディアン) から、スピーディかつダウンタイムをほぼゼロに抑えてデータを移行することです。 Amazon RDS へのリプラットフォームは、リホストに比べてより時間がかかります。 これは、AIX、Windows、メインフレーム上の Db2 on Linux から Db2 バックアップイメージを復元できないためです。 これは、リトルエンディアンとビッグエンディアンの違いが原因です。 ソースの Db2 データベースからメタデータを抽出し、Amazon RDS for Db2 に適用する必要があります。 最良の方法は、他のサードパーティツールが使用するリバースエンジニアリング方法と比較して、メタデータの再現度が最も高いネイティブツールである  db2look  を使用することです。 Db2 のネイティブツールである  export  を使用して、データをアンロードし、ネイティブツールである  import  または  load  を使用して、ソースから RDS for Db2 データベースに移行できます。 移行の相対的な速度については、次の図を参照してください。 AWS DMS は、セルフ運用されている Db2 データベースから Amazon RDS for Db2 に移行する処理を簡素化するマネージドサービスです。AWS DMS は Db2 を ターゲットエンドポイント としてサポートし、Amazon RDS for Db2へのフル ロードとChange Data Capture (CDC) の両方の移行方法に対応しています。 別の方法として、Db2MT を使えば、メタデータを抽出し、データをアンロードすることができます。抽出したメタデータを使用してデータベースオブジェクトを作成し、その後 Db2MT を利用して Amazon S3 から直接 Amazon RDS for Db2 にデータをロードできます。 これらのタスクは自動化されており、簡単なDb2MTコマンドを使用して各タスクを開始できるため、抽出および並列化の複雑なプロセスに取り組む必要はありません。 データベースの移行速度は、適度な量のデータを使ったサンプル移行を行って判断することをお勧めします。これにより、一括の移行か、ログレプリケーションによる移行のどちらを使うべきかが判断できます。 ワンタイム移行 カットオーバー時間を含めた合計時間がダウンタイムの許容範囲内であれば、ワンタイム移行を選択できます。AIX または Windows から移行し、データを Amazon RDS for Db2 にロードする場合は、Db2MT の利用をおすすめします。次の図に、このソリューションのアーキテクチャを示します。 Amazon RDS for Db2 は、Amazon S3 から直接データを読み込む機能をネイティブでサポートしています。Db2MTは  DB2REMOTE ID  を使用し、Amazon S3への ストレージアクセス を利用して、Amazon RDS for Db2に接続されたDb2クライアントを通じてAmazon S3から直接データをロードします。 ログレプリケーションによる移行 初期テスト移行を通じて測定された移行時間が停止時間の範囲を超える場合、AIX または Windows 上のセルフ運用の Db2 から Amazon RDS for Db2 への移行にログ レプリケーションを使用することができます。 前述の Db2MT を使用して ワンタイム移行を完了するステップに従います。次のいずれかの方法を使用してダウンタイムがほぼゼロの移行を実現できます。 AWS DMS  – AWS では、Db2 をソースとターゲットとしてサポートしています。AWS DMS の レプリケーションインスタンス を使用することで、ソースの Db2 データベースから Amazon RDS for Db2 に変更を同期できます。 IBM Q Replication  –  IBM Q Replication を使用して、AIX、Windows、メインフレーム上のLinux (ビッグエンディアン) で実行されている Db2 からのダウンタイムをほとんどなくす移行を実現できます。 次の図は、このソリューションのアーキテクチャを示しています。 移行プロジェクトの計画 データ移行プロセスでは、メタデータの忠実性の確保、データの整合性と品質の確保、AWS DMS などの既存の Amazon RDS サービスを使用したパフォーマンス上の懸念、コスト管理、統合への対処、レガシーアプリケーションのサポート、ネットワーク帯域幅、事業継続、災害対策、安全なアクセスのための入念な計画が必要であり、次のフェーズを含みます。 準備と計画: データベースサイズと複雑性の分析  – データベースのサイズとデータの複雑さを理解する。これは移行に必要な時間とリソースを見積もるのに役立ちます。 ピークとオフピーク時間の特定  – ユーザへの影響を最小限に抑えるため、オフピーク時にデータ移行を行うようにスケジューリングします。 テスト: 移行プロセスのテスト  – ステージング環境で徹底的なテストを実施し、潜在的な問題を特定し、移行プロセスを洗練します。 パフォーマンステスト  -実際のデータ転送を効率的に処理できるかを確認するために、負荷をかけて移行プロセスをテストします。 段階的な移行: 段階的なデータ移行  – 一度にすべてのデータを移行するのではなく、小さなチャンクに分割して移行することを検討します。このアプローチはリスクを低減し、移行スピードの改善に役立ちます。 レプリケーション  – 最終的な切り替えまで、新しいデータベースが古いデータベースと同期する状態を維持するために、データベースレプリケーションを使用します。 監視とバックアップ: 継続的な監視  – 問題やパフォーマンスのボトルネックがないか、移行プロセスを注意深く監視します。 バックアップ  – 万が一の場合に備えて、元のデータベースのバックアップを必ず取っておきます。 最終的な切り替えと検証: 切り替え  – すべてのデータが正確に転送され、新しいシステムの準備が整ったことを確認した後、最終的な切り替えを行います。 移行後の検証  – 新しいシステムのデータの整合性とパフォーマンスを確実に確認するため、徹底的なチェックを実施します。 データベースの移行はそれぞれ固有のものであり、前述の戦略は、個々の状況と要件に合わせてカスタマイズする必要があります。さらに、経験豊富なデータベース管理者や技術者のチームを巻き込むことで、スムーズかつ効率的な移行プロセスを実現できます。 まとめ このブログでは、Db2 から Amazon RDS for Db2 へ移行するためのリホストとリプラットフォームの戦略を示しました。リホストは、Db2MT を使用して既存システムへの変更を最小限に抑えながら Amazon RDS for Db2 に移行することを目指す組織にとって、簡単で効率の良いアプローチとなります。リプラットフォームは、フルロードと CDC を利用可能なAWS DMS または IBM Q Replication を利用可能な Db2MT を使用します。 どちらのアプローチも、アーキテクチャやアプリケーションの機能を変更する複雑さを伴わずに、Amazon RDS for Db2の強化されたスケーラビリティや潜在的なコスト削減などの即時の利点を提供します。また、Amazon RDS によるリホストまたはリプラットフォームは、AWS への移行の足がかりとなり、将来のモダナイゼーションおよび最適化の取り組みの基盤を築きます。 このブログにコメントをお寄せいただき、Db2 用 Amazon RDS に関する今後の投稿についてご要望をお聞かせください。 サービスの詳細は、 Amazon RDS for Db2 ユーザーガイド をご覧ください。 著者について Vikram S Khatri は Amazon RDS for Db2のシニアプロダクトマネージャーです。VikramはDb2に関して20年以上の経験を持っています。彼はゼロから新しい製品を開発することを楽しんでいます。余暇には瞑想やポッドキャストを聞くことを楽しんでいます。 翻訳は、Solution Architect の 野間が担当しました。 原文 はこちらです。

6月11日、 AWS CloudTrail Lake での生成人工知能 (生成 AI) を活用した自然言語クエリ生成のプレビュー版を発表できることを嬉しく思います。AWS CloudTrail Lake は、 AWS CloudTrail アクティビティログを取得、保存、アクセス、分析し、コンプライアンス、セキュリティ、運用上のニーズを満たすためのマネージドデータレイクです。CloudTrail Lake に保存されているこれらのアクティビティログ (管理イベントとデータイベント) について、自然言語を使用して質問できます。SQL クエリを作成する技術的な専門知識がなくても、またアクティビティイベントの正確な構造を解読するために時間を消費しなくてもかまいません。例えば、「スナップショットなしで削除されたデータベースインスタンスの数を教えてください」と尋ねると、機能によりその質問が CloudTrail Lake クエリに変換されます。このクエリは、そのまま実行することも、変更してリクエストしたイベント情報を取得することもできます。自然言語によるクエリ生成により、AWS アクティビティログの探索プロセスが簡単になります。 それでは、自然言語クエリ生成を使い始める方法を説明しましょう。 自然言語クエリ生成の開始方法 自然言語クエリジェネレーターは、生成 AI を使用してプロンプトからすぐに使用できる SQL クエリを生成します。このクエリは、CloudTrail Lake のクエリエディタで実行することを選択できます。 AWS CloudTrail コンソール では、 [Lake] (レイク) の下にある [Query] (クエリ) を選択します。クエリジェネレーターは、CloudTrail 管理イベントとデータイベントを収集するイベントデータストアのクエリのみを生成できます。CloudTrail Lake クエリのイベントデータストアを、 [Event data store] (イベントデータストア) のドロップダウンリストから選択します。 クエリジェネレーター では、自然言語を使用して [プロンプト] フィールドに次のプロンプトを入力します。 過去 1 か月間に記録されたエラーの数はどれくらいですか? 次に、 [Generate query] (クエリを生成) を選択します。次の SQL クエリが自動的に生成されます。 SELECT COUNT(*) AS error_count FROM 8a6*** WHERE eventtime >= '2024-04-21 00:00:00' AND eventtime <= '2024-05-21 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) [Run] (実行) を選択して結果を確認します。 これは面白く、もっと詳しく知りたいです。どのサービスで最もエラーが多かったか、なぜこれらのアクションがエラーになったのかを知りたいです。そこで、次のプロンプトを入力して追加の詳細をリクエストします。 過去 1 か月間に各サービスで記録されたエラーの数と、各エラーの原因は何でしたか? [Generate query] (クエリを生成) を選択すると、次の SQL クエリが生成されます。 SELECT eventsource, errorcode, errormessage, COUNT(*) AS errorCount FROM 8a6*** WHERE eventtime >= '2024-04-21 00:00:00' AND eventtime <= '2024-05-21 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) GROUP BY 1, 2, 3 ORDER BY 4 DESC; [Run] (実行) を選択して結果を確認します。 結果から、私のアカウントでは Amazon S3 に関連するエラーが最も多く、最も多いエラーは CORS とオブジェクトレベルの設定に関連していることがわかりました。さらに質問をすることで、さらに深く掘り下げて詳細を確認できます。しかし、今度は自然言語クエリジェネレーターに別の命令を与えましょう。 [Prompt] (プロンプト) フィールドに次のプロンプトを入力します。 過去 1 か月に使用した AWS サービスのトップ 10 はどれですか? イベント名も含めてください。 [Generate query] (クエリを生成) を選択すると、次の SQL クエリが生成されます。この SQL ステートメントは、フィールド名 ( eventSource 、 eventName 、 COUNT(*) AS event_count ) を取得し、 WHERE 句で過去 1 か月の日付間隔の行を制限し、行を eventSource と eventName でグループ化し、使用回数でソートし、自然言語で要求したように、結果を 10 行に制限します。 SELECT eventSource, eventName, COUNT(*) AS event_count FROM 8a6*** WHERE eventTime >= timestamp '2024-04-21 00:00:00' AND eventTime <= timestamp '2024-05-21 23:59:59' GROUP BY 1, 2 ORDER BY 3 DESC LIMIT 10; [Run] (実行) を選択して結果を確認します。 これで、過去 1 か月間に記録されたエラーの数、エラーの対象となったサービス、およびエラーの原因についての理解が深まりました。わかりやすい言葉で質問してみて、生成されたクエリをログに対して実行して、この機能がデータでどのように機能するかを確認できます。 プレビューをお試しください 自然言語クエリ生成は、 CloudTrail Lake の一部として米国東部 (バージニア北部) リージョンでプレビュー版として提供されています。 自然言語クエリ生成は、追加費用なしでプレビューで使用できます。CloudTrail Lake のクエリ料金は、クエリを実行して結果を生成する場合に適用されます。詳細については、 AWS CloudTrail の料金 をご覧ください。 自然言語クエリ生成の詳細と開始方法については、 AWS CloudTrail Lake ユーザーガイド をご覧ください。 — Esra 原文は こちら です。

6月11日、 Amazon Simple Storage Service (Amazon S3) 向け Amazon GuardDuty Malware Protection の一般提供についてお知らせします。これは、特定の S3 バケットへの悪意のあるファイルのアップロードを検出するための GuardDuty Malware Protection の拡張機能です。これまで、GuardDuty Malware Protection にはエージェントレススキャン機能があり、 Amazon Elastic Compute Cloud (Amazon EC2) とコンテナワークロードにアタッチされている Amazon Elastic Block Store (Amazon EBS) ボリューム上の悪質なファイルを特定していました。 これで、S3 バケットにアップロードされた新しいオブジェクトにマルウェアがないか継続的に評価し、見つかったマルウェアを隔離または排除するためのアクションを実行できます。Amazon GuardDuty Malware Protection は、 Amazon Web Services (AWS) が開発した、業界をリードする複数のサードパーティーマルウェアスキャンエンジンを使用して、Amazon S3 のスケール、レイテンシー、耐障害性を低下させることなくマルウェアを検出します。 GuardDuty Malware Protection for Amazon S3 では、指定した S3 バケットに組み込みのマルウェアとウイルス対策を使用できるため、悪意のあるファイルの評価を大規模に自動化することに伴う運用の複雑さとコストオーバーヘッドを排除できます。マルウェア分析に使用される既存の多くのツールとは異なり、GuardDuty のこのマネージドソリューションでは、マルウェア分析を実行したい各 AWS アカウントと AWS リージョンで、分離された独自のデータパイプラインやコンピューティングインフラストラクチャを管理する必要はありません。 開発チームとセキュリティチームが協力して、信頼できないエンティティから新たにアップロードされたデータをマルウェアスキャンする必要がある特定のバケットに対して、組織全体でマルウェア対策を設定して監視することができます。GuardDuty でオブジェクトのタグ付けなどのスキャン後のアクションを設定してダウンストリーム処理に役立てたり、 Amazon EventBridge から提供されたスキャンステータス情報を利用してアップロードされた悪意のあるオブジェクトを隔離したりできます。 S3 バケット向けの GuardDuty Malware Protection の開始方法 はじめに、 GuardDuty コンソール で [Malware Protection for S3] を選択し、 [Enable] (有効化) を選択します。 S3 バケット名を入力するか、 [Browse S3] (S3 を参照) をクリックして、現在選択されているリージョンに属するバケットのリストから S3 バケット名を選択します。選択したバケットに新しくアップロードされたすべてのオブジェクトを GuardDuty にスキャンさせたい場合は、 [All the objects in the S3 bucket] (S3 バケット内のすべてのオブジェクト) を選択できます。または、特定のプレフィックスに属する新しくアップロードされたオブジェクトをスキャンする場合は、 [Objects beginning with a specific prefix] (特定のプレフィックスで始まるオブジェクト) を選択することもできます。 新しくアップロードされた S3 オブジェクトをスキャンした後、GuardDuty は GuardDutyMalwareScanStatus というキーと以下のスキャンステータスの値を含む定義済みのタグを追加できます。 NO_THREATS_FOUND – スキャンされたオブジェクトに脅威は見つかりませんでした。 THREATS_FOUND – スキャン中に潜在的な脅威が検出されました。 UNSUPPORTED – このオブジェクトのサイズが原因で GuardDuty はスキャンできません。 ACCESS_DENIED – GuardDuty はオブジェクトにアクセスできません。許可を確認してください。 FAILED – GuardDuty はオブジェクトをスキャンできませんでした。 GuardDuty でスキャンした S3 オブジェクトにタグを追加したい場合は、 [Tag objects] (オブジェクトにタグ付け) を選択します。タグを使用すると、不正プログラム検索が完了する前にオブジェクトにアクセスされないようにするポリシーを作成し、アプリケーションが悪意のあるオブジェクトにアクセスするのを防ぐことができます。 次に、以下の必要な許可を含む AWS Identity and Access Management (IAM) ロールを先ず作成してアタッチする必要があります。 EventBridge アクションは、Malware Protection for S3 が S3 Event Notifications をリッスンできるように、EventBridge マネージドルールを作成および管理します。 Amazon S3 と EventBridge アクションは、このバケット内のすべてのイベントについて S3 Event Notifications を EventBridge に送信します。 Amazon S3 アクションは、アップロードされた S3 オブジェクトにアクセスし、スキャンされた S3 オブジェクトに定義済みのタグを追加します。 AWS Key Management Service (AWS KMS) キーアクションは、サポートされている DSSE-KMS と SSE-KMS を使用してテストオブジェクトをバケットにスキャンして配置する前に、オブジェクトにアクセスします。 これらの許可を追加するには、 [View permissions] (許可を表示) を選択し、ポリシーテンプレートと信頼関係テンプレートをコピーします。これらのテンプレートにはプレースホルダー値が含まれており、バケットと AWS アカウントに関連する適切な値に置き換える必要があります。AWS KMS キー ID のプレースホルダー値を置き換える必要もあります。 次に、 [Attach permissions] (許可をアタッチ) を選択すると、IAM コンソールが新しいタブに表示されます。新しい IAM ロールを作成するか、コピーしたテンプレートの許可で既存の IAM ロールを更新するかを選択できます。IAM ロールを事前に作成または更新したい場合は、AWS ドキュメントの「 前提条件 – IAM PassRole ポリシーの追加 」をご覧ください。 最後に、IAM コンソールが開いている GuardDuty ブラウザタブに戻り、作成または更新した IAM ロールを選択して、 [Enable] (有効化) を選択します。 これで、この保護されたバケットの保護 [Status] (ステータス) 列に「 Active 」と表示されます。 [View all S3 malware findings] (すべての S3 マルウェア検出結果を表示) を選択すると、スキャンされた S3 バケットに関連して生成された GuardDuty の検出結果が表示されます。「S3Object:S3/MaliciousFile」という検出結果タイプが返された場合、GuardDuty はリストに表示されている S3 オブジェクトを悪意のあるオブジェクトとして検出しました。 [Findings] (検出結果) の詳細パネルで [Threats detected] (検出された脅威) セクションを選択し、推奨される修復手順に従います。詳細については、AWS ドキュメントの「 Malware Protection for S3 の検出結果の修復 」をご覧ください。 知っておくべきこと AWS アカウントで GuardDuty が有効になっていなくても、S3 バケットに GuardDuty Malware Protection を設定できます。ただし、アカウントで GuardDuty を有効にすると、マルウェア保護機能を利用できるだけでなく、 AWS CloudTrail 管理イベント、 Amazon Virtual Private Cloud (Amazon VPC) フローログ、DNS クエリログなどの 基本的なソース を完全に監視できます。セキュリティの検出結果を AWS Security Hub と Amazon Detective に送信して、さらに調査することもできます。 GuardDuty は、S3 Standard、S3 Intelligent-Tiering、S3 Standard-IA、S3 One Zone-IA、および Amazon S3 Glacier Instant Retrieval という同期 Amazon S3 ストレージクラス に属するファイルをスキャンできます。マルウェアの拡散や封じ込めに使用されていることが知られているファイル形式をスキャンします。リリース時点では、この機能は最大 5 GB のファイルサイズをサポートします。これには、最大 5 レベルのアーカイブファイルと、解凍後 1 レベルあたり 1,000 ファイルが含まれます。 既に述べたように、GuardDuty は保護されている S3 バケットごとに EventBridge にスキャンメトリクスを送信します。アラームを設定し、オブジェクトにタグを付けたり、悪意のあるオブジェクトを検疫バケットに移動したりするなどのスキャン後のアクションを定義できます。 Amazon CloudWatch メトリクスや S3 オブジェクトのタグ付けなど、その他のモニタリングオプションの詳細については、AWS ドキュメントの「 マルウェアスキャンステータスのモニタリング 」をご覧ください。 今すぐご利用いただけます Amazon GuardDuty Malware Protection for Amazon S3 は、中国リージョンと GovCloud (米国) リージョンを除き、GuardDuty が利用可能な すべての AWS リージョン で現在一般的にご利用いただけます。 料金は、スキャンされたオブジェクトの GB ボリュームと 1 か月あたりに評価されたオブジェクトの数に基づいています。この機能では、新しい AWS アカウントの場合はアカウント作成の最初の 12 か月間、既存の AWS アカウントの場合は 2025 年 6 月 11 日までの条件に従って、毎月 1,000 件のリクエストと 1 GB の制限付きの AWS 無料利用枠をご利用いただけます。詳細については、「 Amazon GuardDuty の料金 」ページにアクセスしてください。 GuardDuty コンソール で GuardDuty Malware Protection for Amazon S3 をお試しください。詳細については、「 Amazon GuardDuty ユーザーガイド 」をご覧ください。また、 AWS re:Post for Amazon GuardDuty 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 先週は幕張メッセで AWS Summit Japan を開催しました。ご参加頂けた方は楽しめたでしょうか？ 私は GenU (Generative AI Use Cases JP) の展示ブースに立ちながら、多くのお客様と直接お話しする機会がありました。その中で、お客様の AWS や生成 AI への関心の高さ、そして技術への情熱を肌で感じることができ、私自身も大いに刺激を受けました。 AWS Summit Japan の各セッションについて、 オンデマンド配信 がすでに開始されています。7/5 まで動画閲覧や資料ダウンロードができますので、ぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年6月17日週の主要なアップデート 6/17(月) Amazon EC2 C7i-flex instances are now available in US East (Ohio) Region Amazon EC2 で C7i-Flex インスタンスがオハイオリージョンで利用可能になりました。C6i インスタンスと比べて、最大 19 % のコストパフォーマンス向上を実現するタイプです。Flex インスタンス (M7i-Flex, C7i-Flex) は、従来のインスタンス (M7i, C7i) の低価格タイプとなっています。EC2 インスタンスを利用する際に、CPU 利用率は、低い時期と高い時期があるのが一般的だと考えられます。Flex インスタンスは、そういった常時 100 % の力を発揮しなくても良いような利用方法に適しているインスタンスタイプです。CPU 性能の 40 % はベースラインとして、常時提供します。ベースラインの 40 % を超える場合、95 % の確率で 100 % までスケールアップする仕組みを提供します。Web アプリケーションサーバー、データベース、仮想デスクトップ、バッチ処理、マイクロサービス、キャッシュといったユースケースでご検討いただけます。Flex インスタンスの特徴の詳細は、こちらの FAQ の「Flex instances」章もご覧ください。 AWS CodeBuild now supports organization and global GitHub webhooks AWS CodeBuild で、GitHub と GitHub Enterprise Server のグローバル Webhook がサポートされるようになりました。これにより個別のリポジトリごとに Webhook を設定することなく、単一の Code Build Webhook を設定するだけで組織内のすべてのリポジトリからイベントを受信できるようになりました。これらのイベントには、GitHub Actions のワークフロー実行、コミットのプッシュ、リリース、プルリクエストが含まれます。 AWS Systems Manager now supports additional Rocky, Oracle, and Alma Linux versions AWS Systems Manager で Rocky Linux、Alma Linux、Oracle Linux のバージョン 8.8 および 8.9 を実行しているインスタンスをサポートするようになりました。これにより、より多様な環境で Systems Manager を利用できるようになりました。Systems Manager は運用を支援するサービスであり、例えばインベントリ管理や、パッチ管理、遠隔アクセスの Session Manager などの機能が利用できます。 6/18(火) Amazon Connect Cases is now available in additional Asia Pacific regions Amazon Connect Cases が東京とソウルリージョンで利用できるようになりました。Amazon Connect Cases は電話を受けた担当者が、問い合わせケースを作成、共同作業のアサインなど、問い合わせを素早く解決するための管理機能を提供します。例えば、お客様から Amazon Connect に電話がかかってきた際に、担当者がお客様と会話しながら「問い合わせ概要」、「状況」、「問い合わせの詳細」を入力する機能を提供します。また、作成した問い合わせケースは、お客様名や電話番号で検索ができ、過去の対応履歴を検索、閲覧することも可能です。 CodeCatalyst allows customers to use Amazon Q Developer to choose a blueprint Amazon Q Developer in Amazon CodeCatalyst の一般提供を開始しました。CodeCatalyst にはブループリントと呼ばれる、Project テンプレートを管理、作成、利用する機能があります。ソースコードや CI/CD ワークフローを組織の形に合わせてテンプレート化しておくことで、新しい開発作業を始める際にテンプレートを流用できるメリットがあります。このアップデートで、自然言語を使って「お客様の実現したい内容」を記載すると、それに基づいたブループリントをガイドしてくれるようになりました。 Introducing Maven, Python, and NuGet support in Amazon CodeCatalyst package repositories Amazon CodeCatalyst のパッケージリポジトリで、Maven、Python、NuGet パッケージをサポートしました。パッケージリポジトリは、社内独自のライブラリなどをパッケージ化することで、社内に限定した公開や管理ができるようになります。 Amazon Redshift announces support for VARBYTE 16MB data type Amazon Redshift の VARBYTE 型のデータサイズ上限が、1 MB から 16 MB に増えました。VARBYTE は可変長バイナリ文字列を格納および表現するための可変サイズのデータ型です。例えば、画像データを直接バイナリデータとして Redshift に格納することで、アプリケーションから見ると実装がシンプルになるメリットが考えられます。 6/19(水) Amazon CodeCatalyst now supports GitHub Cloud and Bitbucket Cloud with Amazon Q Amazon CodeCatalyst は、Amazon Q と連携することで、課題 (Issue) を解決する Pull Request を自動生成する機能があります。今回のアップデートで、CodeCatalyst でリンク設定した GitHub Cloud および Bitbucket Cloud 上のリポジトリに対して、Amazon Q の連携機能が提供されました。CodeCatalyst 上で GitHub や Bitbucket のリポジトリと連携する機能が、Amazon Q によって強化された形になります。 AWS Glue adds additional 13 new transforms including flag duplicates AWS Glue で新たに 13 個の組み込み変換機能が追加されました。重複している列や行をフラグ付け、電話番号の書式設定、大文字小文字の書式設定、最頻値で埋める、重複を削除、月名、偶数かどうか、暗号化ハッシュ、復号化、暗号化、数値を IP アドレスに変換、などがあります。データを加工したい方が変換フローを作り上げるときに、より多くのアクションを利用できるようになり、素早く構築しやすくなりました。 Amazon SageMaker now offers a fully managed MLflow Capability Amazon SageMaker で MLflow をフルマネージドな形で提供開始しました。Mlflow は機械学習の実験管理を支援するポピュラーなオープンソースツールです。データサイエンティストは、馴染みのある MLflow を利用して、ML実験を整理、追跡、分析できます。また、SageMaker 上で利用することで、高いスケーラビリティ、可用性、セキュリティ向上、といったメリットがあります。詳細は こちらの Blog をご覧ください。MLflow 機能は追加料金が設定されております。 Price ページ の「MLflow」タブもご覧ください。 6/20(木) Anthropic’s Claude 3.5 Sonnet model now available in Amazon Bedrock Amazon Bedrock で Anthropic 社の最新モデル Claude 3.5 Sonnet を一般提供開始しました。Anthropic で一番知能の高いモデルとなっており、Claude 3 Opus を上回る性能を発揮しながら、Opus の 1/5 のコストでご利用いただけます。Claude 3.5 Sonnet の主な特徴は、画像を利用したときの処理や理解能力の向上、より自然で人間らしい雰囲気の高品質な文章生成、文脈を理解しながらマルチステップの処理能力の向上などがあります。バージニア北部リージョンでご利用いただけます。詳細はこちらの リリースブログ をご覧ください。 Amazon Bedrock now supports compressed embeddings from Cohere Embed Amazon Bedrock で Cohere Embed モデルを利用してベクトルを生成する際に、圧縮された埋め込み (int8, binary) をサポートしました。この圧縮された埋め込みを使用することで、ベクトル検索エンジンに埋め込みを保存して利用する際に、パフォーマンスの向上、ストレージコストの削減といったメリットがあります。一般的に利用される FP32 精度形式に比べて大幅に小さいサイズですが、精度の低下は最小限に抑えられています。ユースケースの一つとして、マルチテナント SaaS の裏側で大規模なベクトルデータを構成する際に、より高速なパフォーマンスを提供しやすくなる使い方が考えられます。 6/21(金) Amazon SageMaker JumpStart now provides granular access control for foundation models Amazon SageMaker JumpStart で数百の基盤モデルを素早くデプロイするための機能が提供されています。この基盤モデルに対して、きめ細かいアクセス制御を簡単に設定できるようになりました。ユースケースを挙げると、Apache 2.0 のライセンスモデルのみ組織内で利用可能にしたいときなどがあります。現在は、オハイオリージョンでご利用いただけます。詳細はこちらの Blog をご覧ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

IAM Access Analyzer をさらに強力にし、カスタムポリシーチェックを拡張し、IAM ポリシーの微調整に役立つガイダンスに簡単にアクセスできるようにしました。これらの新機能はどちらも、re:Invent 2023 で開始された カスタムポリシーチェックと未使用アクセス分析 に基づいています。こちらが弊社が立ち上げるものです。 新しいカスタムポリシーチェック – 自動推論の力を利用した新しいチェックは、特定の重要な AWS リソースへのアクセスを許可するポリシー、またはあらゆる種類のパブリックアクセスを許可するポリシーを検出するのに役立ちます。どちらのチェックも、デプロイ前に、おそらく CI/CD パイプラインの一部として使用するように設計されており、組織のセキュリティ慣行やポリシーに準拠していない更新を積極的に検出するのに役立ちます。 ガイド付き取り消し – IAM Access Analyzer では、実際には必要のないアクセス権を付与する許可を取り消せるようガイダンスを提供し、デベロッパーと共有できるようになりました。これには、未使用のロール、未使用の許可を持つロール、IAM ユーザーの未使用のアクセスキー、IAM ユーザーの未使用のパスワードが含まれます。ガイダンスには、余分な項目を削除するか、より制限の厳しい項目に置き換えるために必要な手順が含まれています。 新しいカスタムポリシーチェック 新しいポリシーチェックは、コマンドラインから、または API 関数を呼び出すことで呼び出すことができます。チェックは、リクエストの一部として提供されたポリシードキュメントを検証し、 PASS または FAIL の値を返します。いずれの場合も、 PASS はポリシー文書が特定のアクセスを適切に拒否していることを示し、 FAIL はポリシーが許可の一部またはすべてを許可している可能性があることを示します。新しいチェックは次のとおりです。 パブリックアクセスがないことのチェック – このチェックはリソースポリシーに対して実行され、ポリシーが指定されたリソースタイプへのパブリックアクセスを許可しているかどうかを確認します。例えば、 AWS::S3::Bucket リソースタイプを指定することで、ポリシーで S3 バケットへのパブリックアクセスが許可されているかどうかを確認できます。有効なリソースタイプには、DynamoDB テーブルとストリーム、EFS ファイルシステム、OpenSearch ドメイン、Kinesis ストリームとストリームコンシューマー、KMS キー、Lambda 関数、S3 バケットとアクセスポイント、S3 Express ディレクトリバケット、S3 Outposts バケットとアクセスポイント、Glacier、Secrets Manager シークレット、SNS トピックとキュー、ロールを引き受ける IAM ポリシードキュメントなどがあります。有効なリソースタイプのリストは、時間が経つにつれて拡大していく予定で、 CheckNoPublicAccess のドキュメントに記載されています。 Amazon Simple Queue Service (Amazon SQS) キューへのパブリックアクセスを誤って許可するポリシーがあるとします。確認方法は次のとおりです。 $ aws accessanalyzer check-no-public-access --policy-document file://resource.json \ --resource-type AWS::SQS::Queue --output json 結果は、次のとおりです。 { "result": "FAIL", "message": "The resource policy grants public access for the given resource type.", "reasons": [ { "description": "Public access granted in the following statement with sid: SqsResourcePolicy.", "statementIndex": 0, "statementId": "SqsResourcePolicy" } ] } ポリシーを編集して付与したアクセス権を削除して再試行すると、今度はチェックに合格しました。 { "result": "PASS", "message": "The resource policy does not grant public access for the given resource type." } アクセス権が付与されていないことのチェック – このチェックは、一度に 1 つのリソースポリシーまたは ID ポリシーに対して実行されます。また、アクションとリソースのリストも受け付けます。いずれも IAM ポリシーの一部として受け入れられる形式です。このチェックでは、ポリシーが、リスト内のリソースへの意図しないアクセスを、リスト内のアクションによって許可していないかどうかを確認します。例えば、このチェックを使用して、ポリシーで重要な CloudTrail 証跡の削除が許可されていないことを確認できます。 $ aws accessanalyzer check-access-not-granted --policy-document file://ct.json \ --access resources="arn:aws:cloudtrail:us-east-1:123456789012:trail/MySensitiveTrail" \ --policy-type IDENTITY_POLICY --output json IAM Access Analyzer は、次のように、チェックが失敗したことを示しています。 { "result": "FAIL", "message": "The policy document grants access to perform one or more of the listed actions or resources.", "reasons": [ { "description": "One or more of the listed actions or resources in the statement with index: 0.", "statementIndex": 0 } ] } ポリシーを修正して再試行すると、今度はチェックに合格します。このことから、ポリシーがリストされたリソースへのアクセスを許可していないことがわかります。 { "result": "PASS", "message": "The policy document does not grant access to perform the listed actions or resources." } ガイド付き取り消し 以前の記事では、IAM Access Analyzer が、実際には必要のないアクセス権を付与する IAM 項目を検出して一覧表示する方法を説明しました。本日のリリースにより、ユーザー (または開発チーム) がこのような検出結果を解決するのに役立つガイダンスを得られます。私の AWS アカウントの最新の検出結果は次のとおりです。 これらの中には、あるサービスへの早期アクセス権を与えられ、そのサービスを利用してブログを書いたときの残り物もあれば、私がクラウド管理者として一般的に無能だったことが原因のものもあります。 どちらにせよ、これらをクリーンアップしないといけません。2 つ目の「 未使用のアクセスキー 」から始めましょう。項目をクリックすると、下部に新しい [Recommendations] (レコメンデーション) セクションが表示されます。 手順に従ってアクセスキーを削除することも、 [Archive] (アーカイブ) をクリックして検出結果をアクティブな結果のリストから削除し、アーカイブされた検出結果のリストに加えることもできます。今後似たような検出結果に対して同じことをするアーカイブルールを作成することもできます。未使用の IAM ユーザー、IAM ロール、およびパスワードについても同様のレコメンデーションが提供されています。 それでは、 未使用の許可 の検出結果について見てみましょう。 レコメンデーションは既存のポリシーを新しいポリシーに置き換えることです。次のように、新しいポリシーを既存のポリシーと並べてプレビューできます。 最初の例のように、手順に従うことも、検出結果をアーカイブすることもできます。 検出結果とレコメンデーションは、コマンドラインからも確認できます。次のように、アナライザーとその検出結果を指定してレコメンデーションを生成します。 $ aws accessanalyzer generate-finding-recommendation \ --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer \ --id 67110f3e-05a1-4562-b6c2-4b009e67c38e 次に、レコメンデーションを取得します。この例では、JSON 出力全体がかなり充実しているので、ステップのみを表示するように出力をフィルタリングしています。 $ aws accessanalyzer get-finding-recommendation \ --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer \ --id 67110f3e-05a1-4562-b6c2-4b009e67c38e --output json | \ jq .recommendedSteps[].unusedPermissionsRecommendedStep.recommendedAction "CREATE_POLICY" "DETACH_POLICY" これらのコマンド (または同等の API コール) を使用して、レコメンデーションを独自のツールやシステムに統合できます。 今すぐご利用いただけます 新しいチェックと解決手順がご利用いただけるようになり、すべてのパブリック AWS リージョンで今すぐ利用を開始できます。 – Jeff ; 原文は こちら です。

セキュリティは Amazon Web Services (AWS) の最優先事項であり、6月11日、お客様の AWS アカウントのセキュリティ体制を強化するのに役立つ 2 つの機能をリリースします。 まず、ルートユーザーと AWS Identity and Access Management (IAM) ユーザー向けに、サポート対象の 多要素認証 (MFA) のリストに パスキー を追加します。 次に、ルートユーザーに MFA を適用 し始めました。最も機密性の高いユーザー、つまり AWS Organization の 管理アカウント のルートユーザーから始めました。2024年の残りの期間中に、この変更を他のアカウントにも引き続き適用します。 MFA は、アカウントのセキュリティを強化する最も簡単で効果的な方法の 1 つであり、保護層をさらに強化して権限のない個人がシステムやデータにアクセスするのを防ぎます。 ルートユーザーと IAM ユーザー用のパスキー付きの MFA パスキーは、 FIDO2 認証用に作成された認証情報に使用される一般的な用語です。 パスキーは、サービスまたはウェブサイトに登録したときにクライアントデバイス上で生成される一組の暗号化キーです。キーペアはウェブサービスドメインにバインドされ、それぞれ一意です。 キーのパブリック部分はサービスに送信され、サービス側に保存されます。キーのプライベート部分は、 セキュリティキー などの安全なデバイスに保存されるか、 iCloud キーチェーン 、 Google アカウント 、または 1Password などのパスワードマネージャーといったクラウドサービスを使用するときに、ユーザーアカウントに接続されたデバイス間で安全に共有されます 。 通常、キーのプライベート部分へのアクセスは、デバイスに応じて、PIN コードまたは生体認証 (Apple Face ID 、 Touch ID 、 Microsoft Hello などの生体認証) によって保護されます。 パスキーで保護されているサービスで認証しようとすると、サービスがブラウザに課題を送信します。その後、ブラウザは私のデバイスにプライベートキーを使って課題に署名するように要求します。これにより、PIN または生体認証がトリガーされ、プライベートキーが保存されている安全なストレージにアクセスします。ブラウザは署名をサービスに戻します。署名が有効であれば、サービスに保存されているパブリックキーと一致するプライベートキーを所有していることが確認され、認証が成功します。 このプロセスと現在使われているさまざまな標準 ( FIDO2 、 CTAP 、 WebAuthn ) の詳細については、 2020 年 11 月に AWS IAM アイデンティティセンターでパスキーのサポートを開始したときに私が書いた記事 を参照してください。 パスキーはパスワードの代わりに使用できます。ただし、今回の初回リリースでは、パスワードに加えてパスキーを第二要素認証として使用することにしました。パスワードは知っているもので、パスキーは持っているものです。 パスキーはパスワードよりもフィッシング攻撃に対する耐性が高くなります。まず、指紋、顔、または PIN コードで保護されたプライベートキーにアクセスするのがはるかに困難です。次に、パスキーは特定のウェブドメインにバインドされるため、意図せず開示された場合の範囲が狭まります。 エンドユーザーは、使い勝手が良く、簡単に復元できるというメリットがあります。携帯電話やノートパソコンに組み込まれている認証システムを使用して、暗号化で保護された認証情報をロック解除して AWS サインインを行うことができます。また、クラウドサービス (iCloud キーチェーン、Google アカウント、1Password など) を使用してパスキーを保存すると、パスキープロバイダーのアカウントに接続されているどのデバイスからでもパスキーにアクセスできます。これにより、不幸にもデバイスを紛失した場合に、パスキーを回復できます。 IAM ユーザーのパスキー MFA を有効にする方法 パスキー MFA を有効にするには、コンソールの AWS Identity and Access Management (IAM) セクションに移動します。ユーザーを選択し、ページを下にスクロールして [Multi-factor authentication (MFA)] (多要素認証 (MFA)) セクションに移動します。次に、 [Assign MFA device] (MFA デバイスの割り当て) を選択します。 耐障害性とアカウントの回復を強化するために、 1 人のユーザーに対して複数の MFA デバイスを有効にできます 。 次のページで [MFA device name] (MFA デバイス名) を入力し、 [Passkey or security key] (パスキーまたはセキュリティキー) を選択します。その後、[Next] (次へ) を選択します。 パスキーをサポートするパスワードマネージャーアプリケーションを使用すると、ポップアップが表示され、そのアプリケーションを使用してパスキーを生成して保存するかどうかを尋ねてきます。そうしない場合、ブラウザにいくつかのオプションが表示されます。画面の正確なレイアウトは、オペレーティングシステム (macOS または Windows) と使用するブラウザによって異なります。これは、Chromium ベースのブラウザを搭載した macOS で表示される画面です。 残りの操作は、選択内容によって異なります。 iCloud キーチェーン は、パスキーを生成して保存するための Touch ID の入力を促します。 このデモでは、電話などの別のデバイスでパスキーをブートストラップする方法を説明します。そこで、代わりに [Use a phone, tablet, or security key] (スマートフォン、タブレット、またはセキュリティキーを使用する) を選択します。ブラウザに QR コードが表示されます。次に、携帯電話を使用して QR コードをスキャンします。電話が Face ID で私を認証し、パスキーを生成して保存します。 この QR コードベースのフローでは、あるデバイスのパスキーを使用して別のデバイス (デモでは電話とノートパソコン) にサインインできます。これは FIDO 仕様で定義されており、 クロスデバイス認証 (CDA) として知られています。 すべてがうまくいけば、IAM ユーザーのパスキーが登録されます。 IAM ユーザーを使って AWS コンソールで人を認証することはお勧めしません。代わりに AWS IAM アイデンティティセンター でシングルサインオン (SSO) を設定することをお勧めします。 サインインエクスペリエンスはどのようなものですか? MFA を有効にしてパスキーを設定したら、アカウントにサインインしてみます。 ユーザーエクスペリエンスは、使用するオペレーティングシステム、ブラウザ、およびデバイスによって異なります。 例えば、iCloud キーチェーンが有効になっている macOS では、Touch ID キーをタッチするようにシステムから求められます。このデモでは、CDA を使用して携帯電話にパスキーを登録しました。そのため、携帯電話で QR コードをスキャンするようにシステムから求められます。スキャンが完了すると、電話の Face ID で認証してパスキーのロックを解除し、AWS コンソールによりサインイン手順が終了します。 ルートユーザーに MFA の使用を強制する 6月11日 2 つ目の発表は、一部の AWS アカウントのルートユーザーに MFA の使用を強制し始めたことです。この変更は昨年、 Amazon の最高セキュリティ責任者である Stephen Schmidt のブログ記事 で発表されました。 Schmidt の言葉を引用すると: AWS で最も権限のあるユーザーが MFA で保護されていることを確認することは、AWS のお客様のセキュリティ体制を継続的に強化するという当社の取り組みの新たな一手に過ぎません。 まず、最も機密性の高いアカウントである AWS Organizations の管理アカウントから始めました。ポリシーの導入は段階的に行われ、一度に数千のアカウントに対してしか行えません。今後数か月にわたって、大部分の AWS アカウントのルートユーザーに MFA 強制ポリシーを段階的に導入する予定です。 ルートユーザーアカウントで MFA を有効にしていない状態でアカウントが更新されると、サインイン時に MFA を有効にするように求める新しいメッセージがポップアップで表示されます。猶予期間があり、その後は MFA が必須になります。 中国を除くすべての AWS リージョンで、今日からパスキーを多要素認証に使用できるようになりました。 中国の 2 つのリージョン (北京、寧夏) と AWS GovCloud (米国) を除くすべての AWS リージョンで多要素認証の使用を強制します。これらのリージョンの AWS アカウントにはルートユーザーがいないためです。 次に、 アカウントのルートユーザーのためにパスキー MFA を有効にします 。 — seb 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 6月20日から21日にかけて AWS Summit Japan が開催されました！たくさんの方にご来場頂き、本当にありがとうございました。初日の基調講演では生成AIに関するニュースをお届けしました。お客様事例登壇も大変興味深いものでしたので、ご覧になっていない方は7/5までオンデマンドで配信中の動画をぜひご覧ください。ここではサービス関係のお知らせをまとめていきましょう。 7月中に、東京リージョンのAmazon BedrockでAnthropic Claude 3をご利用可能に 2024年中に、Amazon Q Businessの日本語正式サポートと東京リージョン対応を実施 生成AI実用化推進プログラムを発表。基盤モデル自体を開発・カスタマイズする方と、既存のモデルを活用してプロダクトやソリューションの機能や価値を高めたい方の両方を支援（詳細は近日発表） また、日本時間の6月20日から21日にかけて、 AnthropicからClaude 3.5 Sonnetが発表 されました。このモデルはバージニアリージョンのAmazon Bedrockを介してご利用頂けるようになっていますので、こちらもご注目ください。 それでは、6 月 17 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Anthropic’s Claude 3.5 Sonnet model now available in Amazon Bedrock: Even more intelligence than Claude 3 Opus at one-fifth the cost」を公開 冒頭でも書きましたが、 AnthropicのClaude 3.5 Sonnetが発表 され、バージニアリージョンの Amazon Bedrock にてご利用頂けるようになっています。Claude 3.5 SonnetはClaude 3 Opusよりも高いベンチマークスコアを記録する高い能力を発揮すると同時に、Opusよりも80%安価にご利用頂けるとされています。用途に応じて適したモデルを選べるのがAmazon Bedrockの価値のひとつですので、Anthropicのモデルもそうですが他の多言語対応をうたっているモデル、例えばCohere Command R/R+などと比較し、最適なものを選択しましょう。 AWS生成AI国内事例ブログ: 株式会社ナウキャスト様、決算短信データ抽出業務にLLMを適用 株式会社ナウキャスト様は、POSデータやクレジットカードの決済データを解析し、生活者の消費行動や企業活動をより早く正確に捉えるデータソリューションの提供に取り組んでいます。そのためにはデータが必要不可欠ですが、膨大な適時開示資料から人力でデータ抽出を行っており、作業負担が課題になっていました。ナウキャスト様はLLM(大規模言語モデル)を自然言語の処理技術として捉え、適したタスクの見極めを行うことを考え、「セグメント別売り上げ情報抽出」が適したタスクのひとつだと判断、Amazon Bedrockを介したClaude 2で処理を行うこととしました。それによって抽出精度90%を達成、作業工数を50%削減という結果を達成しています。またローコード開発ツールStreamlitとAWSのマネージドサービスを活用し、担当者1名という限られたリソースで短時間の開発と検証を実施したそうです。今後は対象業務と銘柄の拡大を行い、データ単体のマネタイズやオペレーション自体の顧客への提供を考えているとのことです ブログ記事「非構造化金融データに隠された関連性を Amazon Bedrock と Amazon Neptune で発見する」を公開 先週公開されたブログですが、ピックアップ漏れがあったので今回紹介します。生成AIの適用が期待される領域に、データから新たな洞察（インサイト）を得るというものがあります。このブログ記事では、フルマネージドなグラフDBのサービスである Amazon Neptune と、 Amazon Bedrock の生成AIモデルを活用することにより、金融データに隠れたデータ間の関連性を見いだす方法を解説するものです。 サービスアップデート AnthropicのClaude 3.5 SonnetがAmazon Bedrockで利用可能に 既にお知らせしているように、AnthropicのClaude 3.5 SonnetがバージニアリージョンのAmazon Bedrockでご利用頂けるようになりました。 Amazon BedrockがCohere EmbedモデルによるCompressed Embeddingsをサポート Amazon BedrockでCohereのEmbedを利用したCompressed Embeddingsに対応しました。これは検索拡張生成(RAG)やセマンティック検索で利用されるケースが多い機能で、生成AIを組み込んだアプリケーションを効率化します。一般的にはEmbeddings形式のデータは、FP32(32ビット浮動小数点数)で表現されますが、Compressed EmbeddingsはINT8(8ビット整数)またはバイナリで表現します。これらのデータはFP32よりもサイズが小さく、ベクトルデータベースへの負荷や検索の時間的・費用的コストを抑えることが可能です。生成AIアプリケーションの大規模展開を考えるとベクトルデータベースへの負荷が課題になるケースがあり、そういった場合に検討できる対策のひとつといえます。 Amazon SageMakerでフルマネージドなMLflow機能を提供開始 MLflowは機械学習のライフサイクル管理で利用されるオープンソースツールのひとつです。今回、SageMakerでフルマネージドなMLflowのトラッキングサーバーを利用できるようになりました。MLflowへのアクセスはAWS IAMによって制御可能で、開発者の方は使い慣れたMLflowを利用した実験・分析を容易に実行できます。 Amazon SageMaker HyperPodがクラスタストレージのカスタマイズに対応 Amazon SageMaker Hyperpod はモデルの分散トレーニングのためのインフラストラクチャの構築と最適化を容易にする仕組みです。今回、SageMaker Hyperpodで構築されるクラスタのストレージがカスタマイズ可能になり、一般的なユースケースよりも大容量のストレージを必要とする場合にも対応できるようになりました。 Amazon SageMaker JumpStartで基盤モデルに対する詳細なアクセス制御が可能に Amazon SageMaker JumpStartは生成AIを支える基盤モデルをなど学習済みのモデルをすぐに起動できる枠組みで、機械学習に関するタスクを素早く始めることを可能にするハブとして機能します。今回、管理者が組織内のユーザに対して利用できる基盤モデルを細かく制御できるようになりました。SageMaker SDKを利用してSageMaker JumpStartにプライベートなハブを作成し、ユーザが利用してよいモデルだけを登録できるようになりました。これによって、例えばApahce 2.0ライセンスのもののみ触って良い、といったルールを適用することが容易になります。 Amazon CodeCatalystでブループリントの選択にAmazon Qを活用可能に Amazon CodeCatalyst はAWSで稼働するシステムの構築・開発を迅速化する統合ソフトウェア開発サービスです。CodeCatalystを利用して開発を開始する方法のひとつが、プロジェクトのひな形のようなブループリントを利用する方法です。これまではブループリントの説明文を読んで適しているものを判断する必要がありましたが、Amazon Qとの統合により自然言語でプロジェクトの概要を説明することで、適したブループリントを提案してくれるようになりました。 Amazon CodeCatalystがAmazon Qによる問題分析と推奨されるタスク分割の出力に対応 Amazon CodeCatalystがAmazon Qとの統合を強化し、問題の分析と推奨されるタスク分割を提案することが可能になりました。従来、プロジェクトにおけるタスクは主導で作成する必要がありましたが、今回のアップデートで問題の複雑さをAmazon Qに分析させ、作業を詳細タスクに分割するアイデアを提示してもらうことが可能になりました。 Amazon CodeCatalystがGitHub CloudとBitbucket CloudとAmazon Qの連携に対応 Amazon CodeCatalystで、GitHub CloudやBitbucket Cloudに保存されたソースコードレポジトリに対してAmazon Qによる開発支援が可能になりました。CodeCatalystで管理されるタスクをAmazon Qに割り当てることによって、これらのサービスで保存されるコードを分析し、対応計画を作成し、プルリクエストを生成できます。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

本ブログは、株式会社ココペリと Amazon Web Services Japan が共同で執筆しました。 株式会社ココペリ は「中小企業にテクノロジーを届けよう」というビジョンのもとサービスを提供しています。より多くの価値提供を行うための活動が実施されており、提供サービスの一つである 中小企業 DX 支援プラットフォーム「Big Advance」 の体験向上を狙う施策も期待されていました。 Big Advance にはビジネスマッチング機能やホームページ作成など複数の機能が搭載されています。これらの機能が有効に活用されることで、利用者のビジネス課題が効率よく解決されることに寄与します。ココペリ社は、利用者がより効率よく機能を活用できるように AI/ML 技術を使った施策を検討し価値提供を試みていました。一方で、AI/ML の活用は技術的な側面のみならずビジネス視点での成長戦略が必要です。Big Advance 利用者への価値提供とともにココペリ社の成長が行えるような AI/ML の活用施策の考案が求められていました。 ML Enablement Workshop による生成 AI のユースケースの特定 このような背景から、ココペリ社は AWS とともに  ML Enablement Workshop (MLEW) を実施しました。MLEW は AWS が開発しメンテナンスしているワークショップです。このワークショップは、プロダクトを AI/ML によって成長させるロードマップの作成を支援します。MLEW では、技術者だけでなくプロダクトマネージャーに代表される企画・ビジネス側の役職も交えた議論が行われます。ココペリ社は、データサイエンティスト、エンジニアやプロダクトマネージャーに加えて、カスタマーサクセスも参加し議論を行いました。 ココペリ社は MLEW での顧客体験分析を通じて、Big Advance のビジネスマッチング機能に着目し、生成 AI のユースケースを特定しました。ビジネスマッチング機能は、自社のビジネス上の要望を「ニーズ」として登録し、Big Advance 上に公開することができるものです。公開すると、6万を超える全国の会員企業がそのニーズを閲覧し商談を申し込むことができるため、販路拡大や新規取引先の開拓が期待できます。 効率の良いビジネスマッチングを行うには各企業が自社の特徴を捉えたニーズを作成することが重要ですが、一からニーズの文章を書き上げるのはハードルが高いことが示唆されました。 このことからニーズ作成のハードルの高さを解消することを目標とし、生成 AI によるニーズ自動作成を重要度の高い施策として検証を開始しました。 役職を横断した連携が可能にした生成 AI の検証 生成 AI による課題解決の検証では、成果物の評価が重要になります。今回の検証の評価は、MLEW に参加したカスタマーサクセスとの強固な連携によって実施されました。 生成 AI によるニーズの自動作成では、出力されたニーズの文章が登録する企業の特徴を捉えたものであるかが評価軸になります。これらの評価には顧客の実務に基づいた評価が必要になります。ココペリ社においてはカスタマーサクセスが顧客の実務を深く理解しているため、カスタマーサクセスが成果物を評価することが有効な判断軸であると言えました。今回の MLEW においてはカスタマーサクセスが参加したことで、これらの連携が円滑に行えています。 ニーズ作成の精度向上を行うために、処理の追加や複数の大規模言語モデルの比較などを行いました。最終的に、生成 AI への入力データとして事前のスクレイピングなどを行い（下図参照）、また Amazon Bedrock で利用可能な Anthropic 社 が提供する大規模言語モデル (LLM) Claude 2.1 を利用することで、社内の評価で 97.9% の採択率となりました。 このワークフローによって出力された結果は以下のようになっており、企業の特徴を捉えた具体的な内容を出力することができているとの評価となりました。 [詳細] 【事業の詳細】 金融機関が連携し、都道府県や金融機関の垣根を超えたビジネスネットワークで、中小企業の経営課題の解決を支援いたします。ビジネスマッチング、ビジネスチャット、ホームページ作成等の機能を月額定額で提供しております。 【キャッチコピー】 ビジネスをもっとシンプルに、楽に #ITサービス #中小企業 #金融 [対象] 中小企業 [ひとことメッセージ] 【事業の強み】 全国の金融機関との連携 【事業への思い】 中小企業の成長支援に情熱を注いでおります 【価格目安】 月額3,300円(税込) 以上の試みは ビジネスマッチングでの Claude による文章生成 に、より詳しく記載されています。 上記のワークフローは複数の処理が実行されますが、 AWS Step Functions や AWS Lambda といった AWS のサービスと Amazon Bedrock の連携によって、ワークフローの自動化を実現しています。 今後の展望 検証結果を受けてニーズ生成機能の社内利用を開始しており、今後はワークフローを洗練した上でプロダクトへの機能実装を計画しています。この技術を活用、改善していくことで精度の高いニーズを容易に作成できるようになり、Big Advance のビジネスマッチングにおける顧客体験をより向上させることを目指していきます。 まとめ 以上のようにココペリ社は MLEW での分析を通じ、Big Advance の顧客に最もインパクトのある生成 AI のユースケースを特定し、その検証を行いました。同社からは「MLEW での顧客体験分析を通じ、Big Advance の顧客に最もインパクトのある生成 AI の用途を特定しタスクと効果測定 KPI を決めることができました」との言葉を頂いています。 検証では、MLEW を通して技術・ビジネスの双方の領域の参加者が強固に連携し、顧客体験に寄り添った精度評価を行うことができました。ココペリ社では、今後も役職を横断した連携と AI/ML 技術、 AWS のテクノロジーを活用し、中小企業のビジネス支援を推し進めていく考えです。

本記事は 2023年11月26日に AWS DevOps Blog で公開された ” Automate safe AWS CloudFormation deployments from GitHub ” を翻訳したものです。翻訳は Partner Sales Solutions Architect の 福井 敦 が担当しました。 AWS CloudFormation は、Infrastructure as Code (IaC) サービスで、AWS およびサードパーティのリソースをモデル化、プロビジョニング、管理できます。新しくトラッキングしている Git リポジトリが更新されるたびに、 Git 同期 によって自動的にデプロイメントがトリガーされるようになりました。 これにより、開発者は Git ワークフローに統合し、コンテキストの切り替えによる時間の浪費を減らすことで、CloudFormation の開発サイクルを大幅に高速化できます。この新しい Git 同期は、 GitHub 、 GitHub Enterprise 、 GitLab 、 Bitbucket に対応しています。 この投稿では、GitHub のネイティブツールと CloudFormation の Git 同期を使った最新の開発体験について説明します。 GitHub CodeSpaces を使用してクラウド開発環境を作成し、 GitHub Actions と CloudFormation Linter を使用して プルリクエスト に直接フィードバックし、安全なデプロイを自動化します。 要件 AWS アカウントを所有していること。 Amazon Virtual Private Cloud (Amazon VPC) リソースをデプロイします。AWS アカウントには通常リージョン毎に 5 つまでの VPC が作成できますが、制限を引き上げることが可能です。 GitHub アカウントと、 Codespaces 、 Actions を利用できること。これらは無料利用枠がありますが、制限を超えると課金される可能性があります。 デベロッパーツールで GitHub への接続を作成 しておくこと。 空のリポジトリの作成 今回は、新しい GitHub リポジトリから始めます。GitHub では無料で新しい Git リポジトリを作成できます。この例では、 git-sync という名前のリポジトリを作成します。 Codespace の設定 リポジトリを作成すると、Codespace を作成するオプションが表示されます。Codespace は GitHub が管理するリモートの開発環境で、設定済の仮想マシン環境でどこからでも開発できます。 Codespaces は、 Visual Studio Code を選択したコードエディターとして利用します。Visual Studio Code は拡張機能をインストールできるため、非常に柔軟で拡張性に優れたオープンソースのコードエディターです。 作成が完了したら、ローカルの開発環境と同様に環境を設定できます。テンプレート開発時に、エディタ内で即座にフィードバックを得られるよう CloudFormation Linter 拡張機能を追加します。 これにより、検証のためテンプレートを CloudFormation に送信する必要はなく、送信する前にテンプレートが有効であることを確認できます。コマンドラインと Visual Studio Code 拡張機能の両方でインストールを行います。ターミナルで次のコマンドを実行してください。 pip3 install cfn-lint インストールされたら、拡張機能パネルで CloudFormation Linter をインストールできます。 次に、ベースディレクトリに vpc.yaml という名前のテンプレートを作成します。 入力を始めると、 CloudFormation Linter が推奨事項とオートコンプリート機能を提供します。 次のテンプレートを新しく作成した vpc.yaml ファイルにコピーしてください: AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 このテンプレートは、CIDR ブロック 10.0.0.0/16 の VPC を作成します。 テンプレートにエラーがないことを確認するには、ターミナルで cfn-lint を実行し、エラーが返されないことを確認します。 cfn-lint -t vpc.yaml デプロイファイルの追加 Git 同期では多様なデプロイメントをサポートするため、Git リポジトリから CloudFormation スタックを管理するための柔軟性を提供する スタックデプロイファイル をサポートしています。 この設定ファイルは、テンプレートファイルの場所、使用したいパラメータやタグの管理を行います。 パラメータやタグの管理には、このスタックデプロイファイルを使うことを強くお勧めします。監査や決定論的なデプロイメントが容易になるためです。 リポジトリ内に deployment-file.yaml という新しいファイルを作成します。このスタックにはパラメータやタグがないため、シンプルです。 template-file-path: ./vpc.yaml 後からコンソールでこのファイルを追加することもできます。 Pull Request アクションの追加 これで開発環境の設定が完了しました。次はプルリクエストを送るだれもが、ローカルで受けているのと同じようなフィードバックを受け取れるようにしたいと思います。 GitHub Actions を使えば、これが可能になります。GitHub Actions は、プルリクエストフィードバックと CI ビルドを自動化する、カスタマイズ可能なワークフローツールです。 次のようなディレクトリとファイルを作成します。 .github/workflows/pull-request.yaml このファイルの内容は以下のとおりです。 name: Pull Request workflow on: - pull_request jobs: cloudformation-linter: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Linter install uses: scottbrenner/cfn-lint-action@v2 with: command: cfn-lint -t ./vpc.yaml この設定により、プルリクエストに対して linter の結果がフィードバックされるようになります。作業内容をリモートブランチにプッシュしてください。 git add -A git commit -m "add pull request linting workflow, add base vpc template" git push origin main これから VPC にサブネットを追加しますが、 VpcId ではなく VpcName という無効なプロパティを意図的に追加します。 AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcName: ! Ref VPC CidrBlock: 10.0.0.1/16 ローカルの linter は、これが無効であることをすぐに指摘します: これらは今のところ無視してかまいません。プルリクエストを作成するには、新しいブランチを作成し、ローカルの変更をコミットする必要があります。以下のコマンドを実行してください。 git switch -c add-subnet git add -A git commit -m "add subnet" git push origin add-subnet これらのコミットをプッシュすると、GitHub から main ブランチに対するプルリクエストを作成できるようになります。 ただし、プルリクエストを作成すると、GitHub Actions の実行が終わったときにチェックが失敗したことがわかります。 「Files changed」タブを確認すると、どこが間違っているかがわかります。Linter アクションはプルリクエスト上で直接フィードバックを提供し、 ブランチ保護 を設定した場合はマージのアクションをブロックします。 このリポジトリでは、少なくとも 1 人のレビュアーと全てのチェックの成功が必要なので、これら両方の失敗を解決しなければなりません。 フィードバックと問題があった行番号を取得できたので、テンプレートに戻り、 VpcName を VpcId に修正しましょう。 AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcId: ! Ref VPC CidrBlock: 10.0.0.1/16 ローカルの linter は問題ありません。コミットしなおすと、リモートの linter も同様に問題がないことを確認できます。レビュアーからの承認を得た後、コミットを main ブランチにマージできます。 Git 同期の有効化 開発環境が整い、プルリクエストの過程でテンプレートがマージ前に Lint されるようになりました。 main ブランチに到達した CloudFormation テンプレートはデプロイの準備ができています。 次に、新しく公開された CloudFormation の Git 同期を利用して、デプロイされたスタックを新しいテンプレートに自動的に同期させます。 まず、CloudFormation がスタックをデプロイするために必要な IAM ロール を作成します。このロールは、CloudFormation がデプロイするリソースを制御します。ロールの名前は後の手順で使用するので控えておきましょう。この例ではロール名を vpc-example-cloudformation-deployment-role とし、次の許可ポリシーを設定します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpc", "ec2:CreateSubnet", "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DeleteVpc", "ec2:DeleteSubnet", "ec2:ModifySubnetAttribute", "ec2:ModifyVpcAttribute" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": ["cloudformation.amazonaws.com"] } } } ] } ロールを作成したら、次はスタックを新しく作成します。 こちらでは、新しいオプション Sync from Git を選びテンプレートのソースを設定します。既にスタックデプロイファイルを作成済みのため、 I am providing my own file in my repository. を選択します。 次に、Git 統合を設定してリポジトリを選択します。あらかじめ作成したデベロッパーツールの Github への接続を使用し、リポジトリを選択する必要があります。 GitHub 、 接続 、 リポジトリ 、 ブランチ 、 デプロイファイルのパス を選択してください。 最後に 新しい IAM ロール を選択して、サービスマネージドロールを作成します。このロールにより、Git 同期がリポジトリに接続できるようになります。この作業は 1 回限りで、今後はここで作成する既存のロールを使用できます。 次のページでは、このスタックをデプロイするために必要な作成済の IAM ロール vpc-example-cloudformation-deployment-role を選択します。このロールは、CloudFormation がデプロイするリソースを制御します。このように、Git 同期によってスタックを管理するには、事前にロールを作成しておく必要があります。 最後に、「Git と同期」タブで、設定内容、同期のステータス、プロビジョニングのステータス、そして必要に応じて同期の再試行や接続解除が可能であることを確認できます。 結論 この投稿では、CloudFormation テンプレートの作成および更新時にフィードバックを得るためのリモート開発環境を設定しました。プルリクエストを作成する際も同様に、フィードバックを得られます。テンプレートが main ブランチにマージされると、自動的にスタックにデプロイされます。このように、AWS リソースを Infrastructure as Code として管理するための、堅牢で拡張性のある CI/CD システムが構築されました。この Git 同期についてのフィードバックをお待ちしています！ 著者について Dan Blanco Dan is a senior AWS Developer Advocate based in Atlanta for the AWS IaC team. When he ’ s not advocating for IaC tools, you can either find him in the kitchen whipping up something delicious or flying in the Georgia sky. Find him on twitter (@ TheDanBlanco) or in the AWS CloudFormation Discord .

本記事は 2024 年 5 月 9 日に公開された ” How Can You Build a Culture of Experimentation? ” を翻訳したものです。 世界中の何百人もの企業幹部と話をしたところ、彼らは迅速に行動してイノベーションを起こすというアイデアは気に入っているものの、企業のレガシーシステムや制約の中でそれを実現するのは難しいと感じていることがわかりました。生成 AI の可能性を考えると、迅速なイノベーションは急務です。しかし、イノベーションを促進するには、実験が容認されるだけでなく、当たり前の文化を築く必要があります。 この記事では、低コスト、低リスク、低摩擦で、企業に大きな利益をもたらす実験を奨励する文化を徐々に築いていく効果的な方法を説明します。私が NASA のジェット推進研究所 (Jet Propulsion Laboratory: JPL) の IT 最高技術・イノベーション責任者を務めていたときに、この方法がうまくいっていました。JPL の実験文化のおかげで、チームは現在の宇宙ミッションにクラウドを利用するようになりました。これにより、より迅速な意思決定が可能になり、必要に応じて方向転換できるようになりました。迅速な実験は、拡張現実、3D プリント、データ視覚化、大規模な機械学習の民主化など、多くの新しいテクノロジーの導入にもつながりました。既存の従業員、インターン、新入社員がこれらのイノベーションを迅速かつ安価に導入できたことは、組織全体の助けとなり、実験者のキャリアに大きな利益をもたらしました。 実験の文化を築くために、最初に組織で実施する実験と実施しない実験を定義します。これにより、期待値を定め、十分な開発と管理を行わずに提案した実験が、本番環境に移行してしまう恐れを軽減できます。 次に、2 週間以内に解決できる可能性の高いビジネス上の問題を選びます。テクノロジーや特定のソリューションではなく、お客様のニーズから逆算して、実際のビジネス上の問題に集中します。ソリューションは時間とともに進化します。洞察につながる成功指標を決定するには、実験者に希望する結果を説明した 1 ページまたは 2 ページの資料を渡してもらい、各実験後の結果をもとに更新してもらいます。これらのビジネス上の問題を、将来の実験者がトレーニングやイテレーションのためにアクセスできるユースケースのライブラリに保存してください。これは、従業員が小さいながらも実際のビジネス上の問題を解決しながら新しいスキルを学ぶ素晴らしい方法です。 第三に、ビジネス組織と機能組織全体にわたる実験者を見つけましょう。多くの組織は、関心と知識が豊富な人材がいることに驚きます。新しいことに挑戦するには、承認と激励が必要です。たとえば、処方的分析の専門家は、AI、機械学習、生成AIを簡単に導入できます。 第四に、部門横断的なアプローチをとりましょう。少なくとも 1 人の IT 従業員、関心のある事業部門のエンドユーザー 1 人、またアドバイスや啓発を行うサイバーセキュリティ専門家で構成される 2 人から 4 人のチームを選任します。 第五に、実験の成功を測定します。投資利益率 (Return On Investment: ROI) の測定に固執しないでください。ROI 文書の作成には、実験の実施にかかる時間よりも多くの時間と費用がかかります (そして勢いを失います)。エンドユーザーコミュニティからの Return On Attention (ROA)、つまり影響を受けるエンドユーザーからの関心度を測定します。ROA を 1 ～ 10 の範囲で評価します。10 は 100% 積極的でポジティブな関心であることを示します。JPL では、少なくとも 2 つのエンドユーザーコミュニティから 8 ポイントを獲得すれば、投資資金が得られることが分かっていました。それから、ROI を測定し、完璧 (またはそれに近い) に向けて繰り返すことができるのです。私は他の企業と協力して同様のアプローチを開発することに成功しました。このようにすることが、問題に最も近い人、そしてしばしば解決策を持っている人がいるような組織の端から創造性を解き放つことに役立ちます。 第六に、実験の話をします。新しいテクノロジーでビジネス上の問題を解決したら、対面デモを行い、複数のデモを紹介するオープンハウスを開催することを検討してください。注釈付きのデモを録画して、セルフサービスの視聴機能を作成します。自分の取り組みが金メッキの科学実験だという批判を避けるために、自分がプロのビデオグラファーではないという期待値を設定することが重要です。特に他のエンドユーザーコミュニティが彼らの意見を受け入れる可能性が最も高いので、エンドユーザー (ビジネス) 参加者の功績を称えることを忘れないでください。そうすれば、将来の実験への参加に対する需要が高まります。ソーシャルメディアやアワードプログラムを利用して、参加者に利益をもたらしましょう。 このアプローチに従えば、始めるのに多額の予算は必要ありません。予算が多すぎると、ソリューションが複雑になりすぎます。時間をかけすぎると、新たに発生するビジネスクリティカルな問題が原因で主要な実装担当者を失うことになります。高い結束力と集中力を確立するために、2 週間 2 ～ 4 人だけで始めましょう。最も成功している企業では、許可を求めることなく利用できる少額の予算を CIO/CTO や事業部門が設定しています。大胆な人には、10 倍の ROI を約束してください。予算を得るのに役立ちます。JPL ではその目標を達成するのに何の問題もありませんでした！ また、エリート主義や反感を助長する可能性があるため、「唯一無二」のイノベーショングループを設立することも避けてください。エンドユーザーと一緒にイノベーションを起こし、自由に賞賛を贈ってください。自社で考えるべきことを外部に委託することは避け、特定の技術の専門家と手を組み、自分でビジョンを維持しましょう。コンプライアンスコントロールを含む自動化により、実験をより簡単かつ迅速に行うことができます。気づかれないように実験を行い、成功してから公開することを検討してください。そうすれば、実験への恐れが減ります。事業を変革できる可能性のある、潜在的に無限の利益をもたらす低リスク、低コストの実験を行っていることを関係者に思い出させましょう。 実験の文化で成功するには、ビジネスの成果がすべてです。 各実験はストーリーを伝え、簡単に元に戻せるものでなければなりません。これにより、リスクと反対意見が減ります。実験における唯一の本当の失敗は、あなたの組織が何も学ばないことであり、私たちはそれが起こるのを見たことがありません。上記の手順は、組織全体のすべてを一度に変更する必要がないため、既存の企業でかなり簡単に試すことができます。ビジネスプロセスを何度も 10% 改善できれば、会社に大きな変化をもたらすことができます。組織は楽しく働ける職場となり、社内のアイデア形成や人材の採用、再教育、定着に役立ちます。そして、それはたしかに価値のある目標です。 ご意見、結果、アイデアをお聞かせください。 Live long and experiment! この記事は、カスタマーソリューションマネージャーの仁科 みなみが翻訳を担当しました。原文は こちら です。

本記事は 2024 年 4 月 11 日に公開された ” KPIs – Enterprise Journey from Technology to Business ” を翻訳したものです。 以前の ブログ記事 で説明したように、AWS は、KPI (Key Performance Indicators: 主要業績評価指標) が明確に定義され、追跡され、調整された組織が、クラウドトランスフォーメーションのジャーニーで成功していると理解しています。しかし、KPI を定義して追跡することは難しい課題です。組織が連携して成果を追跡し、そうすることに価値があるとしても、最初から KPI に注目することが難しい組織もあります。 このブログ記事では、架空の企業 (AnyCompany) が KPI を導入するまでのジャーニーを、複数の顧客とともに取り組んだ実際の経験に基づいて説明します。大規模な企業組織である AnyCompany は、営業利益と売上の向上を目指していました。まず、コストの最適化、総所有コストの削減、技術的負債の回収、将来の機能のための基盤構築を実現するために、オンプレミスのデータセンターを廃止し、アプリケーションをクラウドに移行することから始めました。彼らが採用した未来が、ビジネスの成長と変革を後押ししました。 ビジネス KPI を使ってクラウド導入の効果を追跡する AnyCompany のビジネス目標と現在の文化、プロセス、ガバナンスを理解した上で、ビジネス KPI の導入を促進するために Crawl (ハイハイ)、Walk (歩く)、Run (走る) のアプローチを推奨しました。最初の Crawl フェーズでは技術 KPI から始めて、次の Walk フェーズでビジネス KPI を導入して初期の摩擦を乗り越え、最後の Run フェーズでは徐々にすべてのビジネス KPI に移行します。Crawl フェーズの焦点は、ワークロードをクラウドに移行することで技術的負債を軽減することです。戦術的な KPI は、ワークロードのリプラットフォームとリアーキテクチャの効果的な追跡と進捗報告を確実にします。Walk フェーズでは、クラウド導入技術とコスト削減の成果をビジネス部門のビジネス成果に結び付けます。Run フェーズでは、組織が社内のマーケティングと社内のビジネスアプリケーション開発チームからの肯定的なフィードバックを通じて成功を収めた後、外部のクライアント対応チームは、クライアントにも同様の結果をもたらすという見通しを持ってモチベーションを高めます。これにより、人、プロセス、テクノロジー、ビジネスの観点から組織全体の変革を促進するプラスのフライホイール効果が生まれます。 Crawl フェーズ — 技術 KPI を追跡し、測定する このフェーズでの主な焦点はテクノロジー、つまり技術的負債を減らし、クラウドの導入を増やすことです。このフェーズの KPI は、次の表に示すように、コスト削減、トレーニングを受けたスタッフの数、移行されたアプリケーションの数、運用上の優秀性などのメリットの測定に重点を置いています (表 1)。組織はこの段階では社内の KPI に重点を置き、IT 以外の社員に進捗状況をすぐに伝えます。これにより、KPI の測定、追跡、共有というマッスルメモリー (条件反射的に意識せずに行動できること) が生まれます。KPI は、完了までの期間が複数の四半期または数年にわたる場合に有効です。サイロ化された構造のため、AnyCompany ではこのステップが必要でしたが、他の組織では次の段階にすばやく移行し、勢いをつけるために Crawl フェーズを必要としない場合があります。 表1　Crawl フェーズの KPI と影響 メリット 目的 測定 影響 コスト削減 データセンターの廃止 マネージドサービスプロバイダー (MSP) のデータセンターから廃止されたサーバー数 IT 支出を詳細に確認することによる的を絞った最適化の取り組みが可能 インフラストラクチャ支出のより正確な予測 オンプレミスとクラウドのコスト削減 (ビジネスケース) オンプレミスとクラウドのサーバー数 オンプレミスとクラウドのコスト コストの前年比 (YoY) ダウンタイムの削減 使用されていないアプリケーションを廃止することでアプリケーションフットプリント (リソース使用量やシステムに与える影響など) を簡素化 廃止されたアプリケーションの割合 技術的な問題が顧客に影響を与える前にプロアクティブに解決 ピークアプリケーション使用時のパフォーマンス低下なし (オートスケーリング) アプリケーション停止回数の減少 技術的負債の除去 サポートされた OS 上で稼働するアプリケーションの割合 サポートされたデータベース上で稼働するアプリケーションの割合 運用上のメトリクスの改善 オンプレミスとクラウドの平均検出時間 (MTTD) の基準 プラットフォームやリホストの性能改善 オンプレミスとクラウドのピーク負荷時におけるアプリケーション性能の基準 計画外のシステム停止回数の削減 オンプレミスとクラウドのシステム停止回数の基準 AnyCompany は、Crawl フェーズ中に前の表 1 の KPI を使用して、オンプレミスアプリケーションの約 25％、コストのかかるレガシーデータベースとサーバーの約 50％ を廃止しました。さらに、複数のデータセンターを閉鎖し、セキュリティとオブザーバビリティを向上させ、モダンアプリケーション開発プラットフォームを構築しました。 Walk フェーズ — ビジネス KPI を徐々に導入する この段階では、組織はビジネス成果をテクノロジードライバーに結び付けます。Crawl フェーズで確立された KPI を拡大するにつれて、徐々に変化していきます。目標は Crawl フェーズですべての KPI を完成させることではなく、チームがメトリクスを活用し、継続的な改善とステークホルダーとの透明性を維持できる状態に移行する能力に注目することが目標であることに注意してください。次の表 2 に示すように、初期の KPI セットを取りこんで、自動化された環境プロビジョニングを追加するなど、それらを拡張することになります。これにより、開発者はインフラストラクチャの管理から解放され、デプロイの失敗が減り、機能の強化やより価値のあるタスクに集中できるようになります。ここでは、副次的な目標としてビジネスインパクトの測定から始めたいと思います。初期の KPI には完了までの明確な道筋があり、チームにこれらの新しい KPI を意思決定プロセスで使用してもらうために、チームに KPI を導入する機会を探してください。 AnyCompany は現在、クラウドへの移行を順調に進めており、このフェーズの一環として移行の先を見据えています。彼らは、クラウド移行の過程ですでに測定されていた技術 KPI にビジネス成果を追加しました。企業全体とのコミュニケーションを継続することで、企業のステークホルダーは、移行によって自社のビジネスがどのようにプラスの影響を受けているかを理解できるようになりました。表 2 は、追跡対象の技術 KPI がビジネスに与える影響を示しています。 表2 Walk フェーズの KPI と影響 メリット 目的 測定 影響 ダウンタイムの削減 コードで運用されるアーキテクチャの増加 自動化された環境プロビジョニング数 開発者が機能強化に費やせる時間の増加 デプロイ失敗の減少、つまり、同じ作業を繰り返すことの減少 報告された問題に対するより早いレスポンスタイム デプロイの効率性 自動化されたアプリケーションのデプロイ数 デプロイ成功率 デプロイガバナンスの合理化 デプロイガバナンスプロセスの評価 テスト自動化の割合 オンプレミス、クラウド、クラウドネイティブプラットフォームのデプロイ時間 コスト削減 クラウドネイティブプラットフォームに移行することでリプラットフォームやリファクタリングの準備ができているアプリケーションのモダナイズ クラウドネイティブプラットフォームのアプリケーションの割合 本番環境で報告された不具合に対するレスポンスの増加 本番環境での不具合数の減少 顧客へのプロダクト強化提供数の増加 デプロイ中のダウンタイムの排除 アプリケーションセキュリティの改善 (自動化されたセキュリティスキャン) AWS のマネージドデータベースの割合 機能のサイクルタイム (機能リクエストを本番環境に実装するまでの時間) デプロイ数の前年比 (YoY) 本番環境で報告された不具合数 Run フェーズ — 時間とともにビジネス KPI を追跡、測定、発展させる この段階では、長期的なビジネス上のメリットが実現されつつあり、移行の最初の部分も終わりに近づいています。この時点で、組織はクラウドで成熟しています。初期の戦術的な測定 は、次の表 3 に示すように、組織のビジネスに直接影響する KPI に置き換えられています。これには、売上増加、業務オペレーションの競争上の優位性確保と効率化、営業利益の増加、市場シェアの増加、新しい収益セグメントが含まれます。組織は機能リリースなどのアウトプットとビジネスを推進する成果の関係を理解しています。また、成果を測定すると同時に、その実現のためにどのような機能を追加する必要があるかを調べます。 表 3 Run フェーズの KPI と影響 メリット 目的 測定 影響 効率化 開発者の請求対象外時間 (直接的には収益を生まない時間) の削減 デモや概念実証の労力を軽減し、プリセールス時間を追跡 従業員の生産性向上 AWS CloudFormation テンプレートのような再利用可能なアセットがチームを横断して共通的なワークロードに活用され、チームは付加価値のある作業と差別化されない作業に注目 タグ付けされたアセットやアクセスの追跡 アジリティ (俊敏性) より強いガードレールや舗装された道を提供して、プロジェクト内でジュニアレベルとシニアレベルのエンジニアが一緒に取り組むことができる。経験の浅いスタッフをより迅速に増員できる。 Amazon CodeWhisperer (2024 年 6 月現在では、Amazon Q Developer) のような新しいツールの導入とアウトプットの測定 新人のオンボーディングプロセスの迅速化 イノベーション クラウドネイティブソリューションに基づくクライアントオファリングへの新しい機能追加 (グローバル化、レジリエンシー、サステナビリティ) 顧客による新しい機能のフィードバックスコア 新しい収益源 この段階で、AnyCompany はテクノロジーの観点からクラウドトランスフォーメーションについてある程度の成熟度を達成し、現在は、完了しようとしている作業に関連するビジネス KPI との結び付けと測定に注力しています。ビジネスの変革を可能にする機能や特徴に焦点を当てながら、技術的負債が野放しにならないようにするためのメカニズムとガバナンスが整っています。このフェーズは継続的な道のりであり、ビジネス戦略と IT 戦略を結びつけることで、AnyCompany がマーケットリーダーとしての地位を確立し、コラボレーションを改善できるようになります。 結論 このブログ記事では、AnyCompany がトランスフォーメーションのジャーニーの初期から採用しているアプローチを紹介しています。現在の状況にかかわらず、これらの手順に従うことで、勢いを維持または回復し、一貫した進歩を遂げることができます。KPI を継続的に強化することを目標に、徐々にビジネス KPI に置き換えることができる技術 KPI を測定して共有するメカニズムを構築するための段階的アプローチについて説明しました。 この記事は、カスタマーソリューションマネージャーの仁科 みなみが翻訳を担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、 Microsoft SQL Server データベースの運用と管理を簡素化する AWS マネージドデータベースサービスです。Amazon RDS for SQL Server は、SQL Server データベースのプロビジョニング、管理、モニタリングを行うことで価値をもたらします。このような運用上の俊敏性は価値がありますが、データベースを物理データセンターの外部に移行するリスクを考慮すると、データ保護とセキュリティはさらに重要になります。Amazon RDS では、SQL Server の 透過的データ暗号化 (TDE) 機能を採用できます。この機能は保存中のデータを保護し、アクセスを許可されたユーザーに制限しますが、転送中または使用中のデータは暗号化されません。 複数の AWS アカウントを使用することは、環境を論理的に分離するための一般的なベストプラクティスです。TDE 対応の SQL Server データベースを AWS アカウント間で管理する場合、データ保護を確実にするためのいくつかの重要な手順があります。この記事では、AWS アカウントをまたいで Amazon RDS for SQL Server インスタンス間で TDE 対応データベースを移行する手順について説明します。 前提条件 ここでは、お客様が Amazon RDS for SQL Server と SQL Server の TDE について事前に知識があることを前提としています。この記事では SQL Server 2019 エンタープライズエディションを使用しています。 この記事では、次の前提条件が必要です。 アカウント A とアカウント B の AWS アカウント で Amazon RDS for SQL Server の TDE オプショングループが有効になっていて、リソースを操作するための適切な権限があること AWS KMS キーを使用して作業するためのアクセス権 アカウント A とアカウント B の S3 バケット ソリューション概要 このソリューションでは、AWS アカウント A の Amazon RDS for SQL Server にある TDE 対応データベースをバックアップし、それをアカウント B の別のインスタンスに復元する必要があります。 AWS Key Management Service (AWS KMS) キーで暗号化された TDE 証明書も、ターゲットのインスタンスに復元する必要があります。ソースデータベースの TDE 証明書をバックアップするために使用される秘密鍵の暗号文は、アカウント A の KMS キーで復号化され、アカウント B の KMS キーで再度暗号化されます。 ソリューションを実装する大まかな手順は、アカウント A では以下の流れになります。 存在しない場合は、新しい対称暗号化 KMS キーを作成します。 AWS KMS キーを使用して TDE 証明書を Amazon Simple Storage Service (Amazon S3) バケットにバックアップします。 RDS for SQL Server データベースを S3 バケットにバックアップします。 プライベートキーファイルの S3 メタデータから ciphertext-blob を抽出します。 AWS KMS キーを共有します。 アカウント B で、次の手順を実行します。 アカウント A の暗号文を復号化し、平文のパスワードを抽出します。 アカウント B で新しい対称暗号化 KMS キーを作成し、そのキーでプレーンテキストのパスワードを暗号化します。 データベースをリストアする前に、アカウント B のターゲットインスタンスで TDE 証明書をリストアする必要があります。 アカウント B の Amazon RDS for SQL Server に対してデータベースをリストアし、AWS KMS キーを暗号化します。 次の図は、TDE 対応の SQL Server データベースをアカウント間で移行するためのソリューションアーキテクチャを示しています。 アカウント A の TDE 証明書と RDS for SQL Server データベースを S3 バケットにバックアップ AWS KMS キーを使用して RDS インスタンスの rds_backup_tde_certificate ストアドプロシージャを使用して、アカウント A の TDE 証明書をバックアップします。アカウント A の Amazon RDS for SQL Server では、次のサンプルコードを実行します。 以下は、アカウント A で実行されるステートメントの例です。 まず、sys.certificates システムビューにクエリを実行して TDE 証明書名を取得します。 USE [ master ] GO SELECT * FROM sys . certificates WHERE name LIKE 'RDSTDECertificate%' GO SQL 次に、KMS キーを使用して Amazon RDS TDE 証明書をバックアップします。 EXECUTE msdb . dbo . rds_b ackup_tde_certificate @certificate_name = 'RDSTDECertificate20230323T215533' , @certificate_file_s3_arn = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/mssql-inst02.cer’, @private_key_file_s3_arn = ’arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/mssql-inst02.pvk' , @kms_password_key_arn = 'arn:aws:kms:us-east-1:<ACCOUNTA-ID>:key/mrk-<Key ID>' , @overwrite_s3_files = 1 ; SQL 最後に、暗号化されたデータベースを Amazon S3 にネイティブバックアップします。 exec msdb . dbo . rds_backup_database @source_db_name = 'tpcc' , @s3_arn_to_backup_to = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/tpcc-native-backup.bak' , @overwrite_s3_backup_file = 1 , @type = 'FULL' , @number_of_files = 4 ; SQL 詳細については、「 SQL サーバーの透過的なデータの暗号化サポート 」を参照してください。 プライベートキーファイルの S3 メタデータから ciphertext-blobを抽出 以下のステップを完了します。 前のステップの S3 バケットに移動し、プライベートキーファイルのメタデータから ciphertext-blob をコピーします。これは x-amz-meta-rds-tde-pwd タグの下にあります。 暗号化操作を実行するアカウント B の root ユーザー、他のユーザーまたはロールと (TDE 証明書のバックアップに使用される) KMS キーを共有します 。 root ユーザーを使用する IAM ポリシーの例を以下に示します。 { "Sid" : "Allow an external account to use this KMS key" , "Effect" : "Allow" , "Principal" : { "AWS" : [ "arn:aws:iam::444455556666:root" ] } , "Action" : [ "kms:Encrypt" , "kms:Decrypt" , "kms:ReEncrypt*" , "kms:GenerateDataKey*" , "kms:DescribeKey" ] , "Resource" : “<ARN - FOR - KMS - KEY > ” } YAML 以下は、ロールを使用した IAM ポリシーの例です。 { "Sid" : "Allow an external account to use this KMS key" , "Effect" : "Allow" , "Principal" : { "AWS" : "arn:aws:iam::444455556666:role/ExampleRole" } , "Action" : [ "kms:Encrypt" , "kms:Decrypt" , "kms:ReEncrypt*" , "kms:GenerateDataKey*" , "kms:DescribeKey" ] , "Resource" : “<ARN - FOR - KMS - KEY > ” } YAML TDE 証明書 (.cer) とプライベートキー (.pvk) のバックアップファイルをアカウント A の S3 バケットからアカウント B の S3 バケットにコピーします。 アカウント A の暗号文を復号化して平文のパスワードを抽出 TDE 証明書のバックアップに使用した AWS KMS キー ID を使用して、アカウント A から受け取った暗号文を復号化します。以下は、暗号文を復号化してプレーンテキストのパスワードを取得する AWS Command Line Interface (AWS CLI) コマンドの例です。 AWS kms decrypt —key - id —ciphertext - blob —output text —query Plaintext —region YAML 復号化の詳細については、「 Decrypt 」を参照してください。 アカウント B で新しい AWS KMS キーを作成、そのキーをプレーンテキストのパスワードで暗号化 次のステップでは、アカウント B で新しい対称 AWS KMS キーを作成し、アカウント B の AWS KMS キーを使用して前のステップで復号化されたプレーンテキストのパスワードを暗号化します。AWS KMS キーに対するアクセス権限を持つ認証情報を使用します。次のコマンドは、前に復号化したこのプレーンテキストパスワードの暗号文を提供します。 aws kms encrypt —key - id <Provide KMS KeyID from Account - B > —plaintext "The output from the decrypt step" —output text —region <AWS Region > YAML 詳細については、「 対称暗号化 KMS キーの作成 」を参照してください。 次に、証明書とプライベートキーが保存されているアカウント B の S3 バケットに移動します。プライベートキーファイル (.pvk) を選択し、オブジェクトアクションに移動してメタデータを編集します。「ユーザー定義」タイプで x-amz-meta-rds-tde-pwd というタグを付けて暗号文の値を更新します。 データベースをリストア、アカウント B の Amazon RDS for SQL Server に対して AWS KMS キーを暗号化 データベースをリストアする前に、アカウント B の RDS for SQL Server インスタンスに TDE とネイティブバックアップとリストアが有効になっているオプショングループがあることを確認します。 以下のサンプルコードを使用して、新しく作成された AWS KMS キーを使用して更新された TDE 証明書をアカウント B の Amazon RDS for SQL Server にリストアします。 EXECUTE msdb . dbo . rds_restore_tde_certificate @certificate_name = 'UserTDECertificate_FromAcct1' , @certificate_file_s3_arn = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTB>/mssql-inst02.cer' , @private_key_file_s3_arn = 'arn:aws:s3::: <BUCKET-NAME-ACCOUNTB>/mssql-inst02.pvk' , @kms_password_key_arn = 'arn:aws:kms:us-east-1:<ACCOUNTB-ID>:key/mrk-<Key ID>' ; SQL ユーザー証明書に次のコードがロードされているかどうかを確認します。 SELECT * FROM msdb . dbo . rds_fn_list_user_tde_certificates ( ) ; SQL TDE 証明書が正常にリストアされ、Amazon RDS for SQL Server で検証されたら、データベースバックアップのリストアに進むことができます。以下は、アカウント B の S3 バケットから TDE 対応のバックアップをリストアする例です。 exec msdb . dbo . rds_ restore_database @ restore_db_name = 'tpcc' , @s3_arn_to_restore_from = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTB>/tpcc' , @with_norecovery = 0 , @type = 'FULL' ; SQL 後片付け 検証で作成した AWS リソースを削除するには、次の手順を実行します。 AWS マネジメントコンソール にサインインします。 RDS for SQL Server インスタンスが存在するリージョンを選択します。 Amazon RDS コンソールのナビゲーションペインで [データベース] を選択します。 作成された RDS インスタンスを選択します。 [アクション] メニューで [削除] を選択します。 Amazon S3 コンソールで、作成されたバケットを選択します。 [アクション] メニューで [削除] を選択します。 AWS KMS コンソールで、作成した KMS キーを選択します。 [スケジュールキー削除] を選択し、7 ～ 30 日間の期間を入力して、[スケジュール削除] を選択します。 結論 透過的データ暗号化は、データを保護するために SQL Server で一般的に使用されている組み込みの暗号化メカニズムです。この記事では、RDS for SQL Server インスタンスにある TDE 対応のデータベースを別のアカウントにある RDS for SQL Server インスタンスにリストアするためのソリューションを紹介しました。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Alvaro Costa-Neto は、AWS のデータベーススペシャリストソリューションアーキテクトで、お客様のクラウドでのデータベースソリューションの設計と実装を支援しています。彼はデータベーステクノロジーに長けており、19 年以上にわたり主に Microsoft SQL Server でデータベーステクノロジーに携わってきました。彼はフロリダ州クレルモンに妻と 2 人の子供と一緒に住んでおり、飛行機と旅行が好きです。仕事がないときは、家族や友人と BBQ を主催したり、新しい場所を探索したりしています。 Gopakumar Gopalakrishna Pillai は、アマゾンウェブサービスのデータベースエンジニアです。16 年間データベースに関わってきて複数のデータベーステクノロジーに取り組み、さまざまなお客様の問題に対するソリューションを提供してきました。RDS SQL Server のお客様に最適なデータベースソリューションを提供することに注力しており、その経験を活かしてお客様がサーバーレスアプリケーションを構築できるよう支援しています。自由時間には、新しい場所を探索するのが好きです。 Jeril Jose は、Microsoft SQL Server やその他のデータベーステクノロジーで 14 年以上の経験を持つデータベーススペシャリストコンサルタントです。お客様の AWS へのデータベースソリューションの設計、移行、最適化を支援しています。AWS に入社する前は、金融および小売部門にわたる生産およびミッションクリティカルなデータベースの実装をサポートしていました。

みなさん、こんにちは。シニアマイグレーションスペシャリストの富松です。 AWSジャパンでは、AWSへの大規模なシステムの移行を実現し、ひいてはお客様のデジタルトランスフォーメーションをサポートする 「 AWS ITトランスフォーメーションパッケージ（ITX） 」を2021年に、2022年には内容を強化・拡大した「 AWS ITトランスフォーメーションパッケージ2.0（ITX2.0） 」をリリースしました。2023年にはITXパッケージ2.0をより包括的に進化させた「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー（ITX 2023） 」をリリースし、2021年以来220社(2024年6月現在)を超える多くのお客様にご活用頂き、企業のITトランスフォーメーションを支援してきました。 今回のブログでは、ITX 2023を更に包括的に進化させ、2024年6月にリリースした、最新版の「AWS ITトランスフォーメーションパッケージ ファミリー（ITX）」をご紹介します。（ 最新版のITX資料ダウンロードはこちらから ） 生成AIの活用が企業の喫緊の課題に 近年、生成AIが画期的な技術革新をもたらしています。自然言語処理の生成AIから、画像生成AI、さらにはコード生成AIまで、様々な分野でイノベーションが生み出されています。企業においても、業務効率化や新規ビジネス創出に向けて、生成AIの活用が進んでいます。 PwCコンサルティングの「 生成AIに関する実態調査2023 秋 」によると、調査対象企業の87%が「既に生成AIの社内利用あるいは社外活用(その検討)を進めている」と回答。さらに43%が2024年3月までの生成AI本格導入を予定し、約58%は今後1年以内に導入を検討しているなど、導入に向けた動きが加速する見込みです。 しかし一方で、生成AIを実際のビジネスに活用する際には、大きく2つの課題が存在しています。 1つ目の課題は、データ基盤の整備です。AWSのVice President of Data and AIであるDr. Swami Sivasubramanianが「データは生成AIアプリケーション活用における差別化要因である」とre:Invent 2023において述べているように、生成AIモデルの入力データの質が重要になります。しかし、企業の多くではデータのサイロ化が進み、必要なデータが統合されていないのが実情です。 2つ目の課題は、生成AIの活用に必要なスキルやノウハウの不足です。同レポート「 生成AIに関する実態調査2023 秋 」では、生成AI活用において直面した課題の上位2つが「必要なスキルを持った人材がいない」「ノウハウがなく、進め方が分からない」となっています。従来の機械学習とは発想を転換する必要があり、社内人材のリスキリングや専門人材の確保が欠かせません。 企業のDXを支えるパートナー連携の重要性 デジタル変革を推進するうえで、クラウドへの移行はほとんどの企業が直面する大きなチャレンジです。DXに取り組む企業の約6割が上流工程などの内製化を志向していますが、ユーザー企業におけるIT人材不足が阻害要因となっています。依存度の高いシステムインテグレーターや専門コンサルティング会社との協業は必須不可欠です。 しかし単に顧客がパートナー企業に移行を任せるだけでは不十分です。つまり、パートナー企業がITをどのように活用すればお客様のDX推進につながるか、パートナー企業が深く理解する必要があります。「ITを使って何ができるのか」「どのようなアーキテクチャが適切なのか」といった視点から、クラウド上のシステム開発・運用を支援することが求められます。 また、システム開発やシステム運用を支援するパートナー企業は、既存プロジェクトの技術支援だけではなく、AWS環境全体の運用やアカウント管理 (リセール事業)、新規のシステム移行支援などでも顧客に貢献したいと考えています。 AWS ITトランスフォーメーションパッケージ （ITX）の最新版で、包括的な支援を実現 こうした企業の課題と要望を受け、AWSジャパンでは「ITトランスフォーメーションパッケージ(ITX)」の最新版を2024年6月20日にリリースしました。最新版のITXでは、クラウド移行、データ活用、生成AI導入の3つの側面から、デジタル変革の実現をワンストップで支援します。AWSの専門性とソリューション、AWSパートナーネットワークを最大限活用することで、包括的な支援を行います。 また、ITXパッケージはこれまで民間企業のお客様のクラウド移行を支援してきましたが、公共分野特有の要素を固有には取り込んでいませんでした。今回AWSの活用やガバメントクラウドへの移行を考える中央省庁や地方自治体といった公共のお客様と、そうしたお客様を支援する事業者様向けに従来のITXの内容を拡張し、5つめの支援パッケージとして、公共版ITXを近日中にリリース予定です。 最新版のITXでは、生成AI活用に向けた新サービスとして、ITX for Cloud Nativeにおいて、以下の2つを提供します。また、ITX for MCP Partnerにおける、パートナー連携を強化します。 データプラットフォーム検討支援「Data Platform Modernization Assessment(DPMODA)」 データプラットフォーム検討支援「Data Platform Modernization Assessment(DPMODA)」では、データドリブン経営や、自社データを生成AIで最大限活用することを目指すお客様に対して、AWSの専門チームがお客様の現行データ基盤を分析し、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示します。 データプラットフォーム検討支援を通じて、現行データ基盤の成熟度を把握することで、今後の戦略策定に活用できます。また、To-Beアーキテクチャ検討を通して、現行基盤の単純移行にとどまらず、クラウドでの機能強化のヒントが得られます。 生成AI活用ワークショップ「Innovation EBA(Experience-Based Acceleration)」 生成AI活用ワークショップ(Innovation EBA)は、アジャイル型のインタラクティブなアクティビティです。お客様は、組み込みのAWSサービスと規範的なガイダンスを利用して、ビジネス価値向上を達成するためにAI/MLモデルの構築や、生成AIのユースケース実践をすばやく実現できます。 具体的には、約6週間でAI/MLモデルや生成AIユースケースを開発・実行できるようサポートしたり、未活用のデータや技術から新たなビジネス価値を引き出すことができます。技術ではなく主要なビジネス課題の解決に焦点を当て、実践を通してAI/ML、生成AIのスキルを身に付けられます。さらに、お客様ビジネスに合わせたユースケース開発の加速も図ることができます。AI/MLや生成AIを事業戦略の中核に据え、経営陣の強力な後押しと変革への意欲があれば、より効果的です。ビジネスインパクトが大きく本番環境への展開が見込めるユースケース、生産性や顧客体験、成長分野でのAI/ML活用ニーズがあれば適しています。 ITX for MCP Partnerにおけるパートナー連携強化 AWS移行コンピテンシーパートナー（Migration Competency Partner＝MCP）とは、“移行コンピテンシー”を保有されているAWSパートナーの事を指し、基幹システムや業務アプリケーションのAWSへの移行において、調査から計画、移行、運用までのすべてのフェーズにおける専門知識、豊富な実績やソリューションを持つAWSパートナーを認定させていただくものです。そのようなMCPパートナー各社が提供しているプログラムと、ITトランスフォーメーションパッケージが従来より提供していたプログラムを組み合わせたものが、「AWS ITトランスフォーメーションパッケージ for MCPパートナー（ITX for MCP Partner）」になります。 ITX for MCP Partnerをご利用いただく事により、AWSが持つクラウド移行の様々なオファリングに加えて、MCPパートナーが持つビジネスに関する専門知識、移行およびモダナイゼーションのツールやオファリング、教育などのサポートを併用して受けていただくことができます。 MCPごとに提供内容は異なりますが、例えば移行の計画立案から実行、データ分析基盤の構築、AIシステムの開発、運用支援まで、DXの実現に向けた幅広い支援が受けられます。 2024年6月現在、SCSK、Classmethod、富士ソフト、NHNテコラス、TIS、TOKAIコミュニケーションズ、 CTC、サーバーワークス 各社のITX for MCP Partnerがリリース済みで、今後は他のMCP各社のITX for MCP Partnerも追加予定です。多様なパートナーと連携することで、企業のニーズにより適合したソリューションを提供できます。 ITXパッケージ最新版の始め方 ITXパッケージ最新版のご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITXパッケージ最新版にご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 富松卓郎