AWS Security Hub は、Amazon Web Services (AWS) アカウント全体のセキュリティアラートとコンプライアンスステータスを表示し、集計するための中心的な場所となっています。6 月 17 日、相関関係、コンテキスト化、可視化機能が追加された新しい AWS Security Hub のプレビューリリースを発表します。これにより、重大なセキュリティ問題の優先順位付け、大規模な対応によるリスクの軽減、チームの生産性の向上、クラウド環境の保護強化ができるようになります。 新しい AWS Security Hub を簡単に紹介します。 この新しい機能強化により、AWS Security Hub は Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub クラウドセキュリティ体制管理 (CSPM) 、 Amazon Macie 、その他の AWS セキュリティ機能を統合し、統合クラウドセキュリティソリューションでの一元管理を通じてクラウド環境全体を可視化できるようにします。 新しい AWS Security Hub の使用を開始する AWS Security Hub の使用を開始する方法を順を追って説明します。 AWS Security Hub を初めてご利用になる場合は、AWS Security Hub コンソールに移動して AWS のセキュリティ機能と諸機能を有効にし、組織全体のリスク評価を開始する必要があります。 ドキュメントのページ をご覧ください。 AWS Security Hub を有効にすると、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM など、有効にしたサポートセキュリティ機能のデータが自動的に使用されます。AWS Security Hub コンソールに移動してこれらの検出結果を確認し、これらの機能にわたる検出結果の相関関係から得られるインサイトを活用できます。 セキュリティリスクが発見されると、再設計された Security Hub 概要ダッシュボードに表示されます。新しい Security Hub 概要ダッシュボードでは、AWS のセキュリティ体制を包括的かつ統一的に把握できます。ダッシュボードでは、セキュリティの検出結果が明確なカテゴリに整理されるため、リスクの特定と優先順位付けが容易になります。 新しい エクスポージャーサマリー ウィジェットは、Amazon Inspector、AWS Security Hub CSPM、Amazon Macie からのリソース関係とシグナルを分析することで、エクスポージャー (セキュリティの脆弱性) を特定して優先順位を付けるのに役立ちます。これらのリスク検出結果は自動的に生成され、新しいソリューションの重要な部分となり、重要なエクスポージャーがどこにあるかが明らかになります。エクスポージャーについての詳細は、 ドキュメントのページをご覧ください 。 AWS Security Hub には、潜在的なカバレッジギャップを特定するのに役立つ セキュリティカバレッジ ウィジェットが提供されるようになりました。このウィジェットを使用すると、Security Hub のセキュリティ機能でカバーされていない箇所を特定できます。この可視性により、セキュリティカバレッジを向上させるために必要な機能、アカウント、機能を特定できます。 ナビゲーションメニューでわかるように、AWS Security Hub はセキュリティ管理を効率化するために 5 つの主要領域に分かれています。 エクスポージャー : Security Hub によって発生した、AWS リソースやシステムを不正アクセスや侵害にさらす可能性のある、セキュリティ上の脆弱性や設定ミスなど、すべてのエクスポージャー検出結果が可視化され、環境外からアクセスできる可能性のあるリソースを特定しやすくなります 脅威 : Amazon GuardDuty によって生成されたすべての脅威検出結果を統合し、潜在的な悪質なアクティビティや侵入の試みを表示します 脆弱性 : Amazon Inspector によって検出されたすべての脆弱性が表示され、ソフトウェアの欠陥と設定の問題が強調表示されます 体制管理 : AWS Security Hub クラウドセキュリティ体制管理 (CSPM) から得られたすべての体制管理検出結果を表示し、セキュリティのベストプラクティスに準拠できるようにします 機密データ : Amazon Macie が特定したすべての機密データ検出結果を表示し、機密情報の追跡と保護に役立ちます エクスポージャー ページに移動すると、タイトル別にグループ化された検出結果が表示され、重大度レベルが明確に示されるため、最初に重大な問題に集中できます。 特定のエクスポージャーを調べるには、任意の検出結果を選択すると、影響を受けたリソースが確認できます。パネルには、関係するリソース、アカウント、リージョン、および問題が検出された日時に関する重要な情報が表示されます。 このパネルには、複雑なセキュリティ関係を理解するのに特に役立つ攻撃パスも可視化されて表示されます。ネットワークエクスポージャーパスについては、仮想プライベートクラウド (VPC)、サブネット、セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、ロードバランサーなど、パスに含まれるすべてのコンポーネントを確認できるため、セキュリティコントロールを実装する場所を正確に特定するのに役立ちます。また、この可視化では Identity and Access Management (IAM) の関係も強調表示され、アクセス許可の設定によって権限昇格やデータアクセスがどのように可能になるかがわかります。複数の特性を持つリソースには明確なマークが付けられているため、どのコンポーネントが最もリスクが高いかをすばやく特定できます。 脅威ダッシュボード には、Amazon GuardDuty によって検出された潜在的な悪意のあるアクティビティに関する実用的なインサイトが表示され、検出結果が重大度別に整理されるため、異常な API コール、疑わしいネットワークトラフィック、潜在的な認証情報の侵害などの重大な問題をすばやく特定できます。ダッシュボードには、 GuardDuty 拡張脅威検出 の検出結果が表示され、すべての「重大」な重大度の脅威は、早急な対応を必要とするこれらの拡張脅威検出を表します。 同様に、Amazon Inspector の 脆弱性ダッシュボード では、ソフトウェアの脆弱性とネットワーク露出リスクを包括的に把握できます。ダッシュボードには、悪用が判明している脆弱性、緊急の更新が必要なパッケージ、脆弱性の数が最も多いリソースが表示されます。 もう 1 つの貴重な新機能は、AWS Security Hub の対象となる組織内にデプロイされたすべてのリソースのインベントリを提供する リソースビュー です。このビューを使用すると、どのリソースに不利な検出結果があるかをすばやく特定し、リソースタイプまたは検出結果の重大度でフィルタリングできます。任意のリソースを選択すると、他のコンソールに切り替えなくても詳細な設定情報が得られるため、調査ワークフローが効率化されます。 新しいセキュリティハブには、クラウド環境を包括的に監視し、サードパーティのセキュリティソリューションに接続するのに役立つ統合機能も用意されています。これにより、組織固有のニーズに合わせた統合セキュリティソリューションを柔軟に作成できます。 例えば、統合機能を使用すると、セキュリティ検出結果を表示するときに、「 チケットの作成 」オプションを選択して、希望するチケット統合を選択できます。 その他の情報 いくつかの留意点を次に示します: 利用可能なリージョン – このプレビュー期間中、新しい AWS Security Hub は、次の AWS リージョンでご利用いただけます。米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港、ジャカルタ、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、中東 (バーレーン)、南米 (サンパウロ) 。 価格 — 新しい AWS Security Hub は、プレビュー期間中は追加料金なしでご利用いただけます。ただし、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM などの統合機能のコストは引き続き発生します。 既存の AWS セキュリティ機能との統合 — Security Hub は Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、および Amazon Macie と統合されているため、運用上のオーバーヘッドを増やすことなく包括的なセキュリティ体制を実現できます。 データ相互運用性の強化 — 新しい Security Hub は オープンサイバーセキュリティスキーマフレームワーク (OCSF) を使用しており、標準化されたデータ形式でセキュリティ機能全体でシームレスなデータ交換を可能にします。 強化された AWS Security Hub の詳細とプレビューへの参加については、 AWS Security Hub 製品ページをご覧ください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

マルチチャネル文字起こしストリーミングは、 Amazon Transcribe の機能の一つで、多くの場合ウェブブラウザで利用できます。このストリームソースの作成にはいくつかの制約がありますが、 JavaScript Web Audio API を使用すると、動画、音声ファイル、マイクなどのハードウェアなど、さまざまなオーディオソースを接続して組み合わせ、文字起こしを作成できます。 この記事では、2 つのマイクをオーディオソースとして使用し、それらを 1 つのデュアルチャネルオーディオに結合し、必要なエンコードを実行して Amazon Transcribe にストリーミングする方法を説明します。ブラウザに 2 つのマイクを接続する際に必要とする Vue.js アプリケーションのソースコードも提供されています。ただし、このアプローチの汎用性はこのユースケースにとどまらず、さまざまなデバイスやオーディオソースに対応するように調整できます。 このアプローチでは、1 回の Amazon Transcribe セッションで 2 つのソースの文字起こしを取得できるため、ソースごとに個別のセッションを使用する場合と比較して、コスト削減などのメリットが得られます。 2つのマイクを使用する際の課題 今回のユースケースでは、2 つのマイクでシングルチャネルのストリームを使用し、 Amazon Transcribe のスピーカーラベル識別機能 を有効にしてスピーカーを識別すれば十分かもしれませんが、いくつか考慮すべき点があります。 スピーカーラベルはセッション開始時にランダムに割り当てられるため、ストリーム開始後にアプリケーションで結果をマッピングする必要があります。 似たような声色を持つスピーカーが誤ってラベル付けされる可能性があり、人間でさえ区別が困難です。 2 人のスピーカーが 1 つのオーディオソースで同時に話すと、音声が重なり合う可能性があります。 マイクで 2 つのオーディオソースを使用し、各トランスクリプトが固定の入力ソースから取得することで、これらの懸念に対処できます。スピーカーにデバイスを割り当てることで、アプリケーションはどのトランスクリプトを使用するかを事前に認識できます。ただし、近くにある 2 つのマイクが複数の音声を拾っている場合、音声が重なり合う可能性があります。これは、指向性マイク、音量管理、Amazon Transcribe の単語レベルの 信頼度スコア を使用することで軽減できます。 ソリューションの概要 次の図はソリューションのワークフローを示しています。 2つのマイクのアプリケーション図 Web Audio API では、2つのオーディオ入力を使用します。この API を使うと、マイク A とマイク B の2つの入力を1つのオーディオデータソースに統合できます。左チャンネルがマイク A、右チャンネルがマイク B を表します。 次に、このオーディオソースを PCM (パルス符号変調) オーディオに変換します。PCM はオーディオ処理で一般的なフォーマットであり、Amazon Transcribe がオーディオ入力に必要とするフォーマットの1つです。最後に、PCM オーディオを Amazon Transcribe にストリーミングして文字起こしを行います。 前提条件 以下の環境を事前に用意することが必要です。 GitHub リポジトリ からのソースコード。 Bun または  Node.js が JavaScript ランタイムとしてインストールされていること。 Web Audio API と互換性のあるウェブブラウザ。このソリューションは、Google Chrome バージョン 135.0.7049.85 で動作することがテストされています。 2 つのマイクがコンピュータに接続され、ブラウザからこれらのマイクに アクセスできること 。 Amazon Transcribe の権限を持つ AWS アカウント。例として、Amazon Transcribe には次の AWS Identity and Access Management ポリシーを使用できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DemoWebAudioAmazonTranscribe", "Effect": "Allow", "Action": "transcribe:StartStreamTranscriptionWebSocket", "Resource": "*" } ] } アプリケーションを起動する アプリケーションを起動するには、以下の手順を実行してください。 コードをダウンロードしたルートディレクトリに移動します。 env.sample ファイルから AWS アクセスキーを設定するための .env ファイルを作成します。 パッケージをインストールし、 bun install を実行します（Node.js を使用している場合は node install を実行します）。 Web サーバーを起動し、 bun dev を実行します（Node.js を使用している場合は node dev を実行します）。 ブラウザで http://localhost:5173/ を開きます。. 2つのマイクを接続して http://localhost:5173 で実行されているアプリケーション コードの説明 このセクションでは、実装のための重要なコード部分を解説します。 最初のステップは、ブラウザ API navigator.mediaDevices.enumerateDevices() を使用して、接続されているマイクの一覧を取得することです。 const devices = await navigator.mediaDevices.enumerateDevices(); return devices.filter((d) => d.kind === 'audioinput'); 次に、接続されているマイクごとにMediaStreamオブジェクトを取得する必要があります。これは、ユーザーのメディアデバイス（カメラやマイクなど）へのアクセスを可能にする navigator.mediaDevices.getUserMedia() APIを使用して実行できます。その後、これらのデバイスからの音声または動画データを表すMediaStreamオブジェクトを取得できます。 const streams = [] const stream = await navigator.mediaDevices.getUserMedia({ audio: { deviceId: device.deviceId, echoCancellation: true, noiseSuppression: true, autoGainControl: true, }, }) if (stream) streams.push(stream) 複数のマイクからの音声を結合するには、音声処理用の AudioContextインターフェース を作成する必要があります。この AudioContext 内で、 ChannelMergerNode を使用して、異なるマイクからの音声ストリームを結合できます。 connect(destination, src_idx, ch_idx) メソッドの引数は次のとおりです。 destination – 出力先。この例では mergerNode です。 src_idx – ソースチャンネルのインデックス。この例では両方とも0です（各マイクがシングルチャンネルの音声ストリームであるため）。 ch_idx – 出力先のチャンネルインデックス。この例ではそれぞれ0と1で、ステレオ出力を作成します。 // audioContextのインスタンス const audioContext = new AudioContext({ sampleRate: SAMPLE_RATE, }) // マイクのストリームデータを処理するために使用 const audioWorkletNode = new AudioWorkletNode(audioContext, 'recording-processor', {...}) // microphone A const audioSourceA = audioContext.createMediaStreamSource(mediaStreams[0]); // microphone B const audioSourceB = audioContext.createMediaStreamSource(mediaStreams[1]); // 2つの入力用のオーディオノード const mergerNode = audioContext.createChannelMerger(2); // オーディオ ソースを mergerNode の宛先に接続。 audioSourceA.connect(mergerNode, 0, 0); audioSourceB.connect(mergerNode, 0, 1); // mergerNodeをAudioWorkletNodeに接続 merger.connect(audioWorkletNode); そのマイクデータは AudioWorklet tで処理され、指定された録音フレーム数ごとにデータメッセージが送信されます。これらのメッセージには、Amazon Transcribeに送信するPCM形式でエンコードされた音声データが含まれます。 p-event ライブラリを使用すると、Workletからのイベントを非同期的に反復処理できます。このWorkletの詳細については、この記事の次のセクションで説明します。 import { pEventIterator } from 'p-event' ... // ワークレットを登録する try { await audioContext.audioWorklet.addModule('./worklets/recording-processor.js') } catch (e) { console.error('Failed to load audio worklet') } // 非同期イテレータ const audioDataIterator = pEventIterator<'message', MessageEvent<AudioWorkletMessageDataType>>( audioWorkletNode.port, 'message', ) ... // AsyncIterableIterator: ワークレットが `SHARE_RECORDING_BUFFER` メッセージを含むイベントを発行するたびに、このイテレータは必要な AudioEvent オブジェクトを返す。 const getAudioStream = async function* ( audioDataIterator: AsyncIterableIterator<MessageEvent<AudioWorkletMessageDataType>>, ) { for await (const chunk of audioDataIterator) { if (chunk.data.message === 'SHARE_RECORDING_BUFFER') { const { audioData } = chunk.data yield { AudioEvent: { AudioChunk: audioData, }, } } } } Amazon Transcribeへのデータのストリーミングを開始するには、作成したイテレータを使用し、 NumberOfChannels: 2 と EnableChannelIdentification: true を有効にしてデュアルチャネルの文字起こしを有効にします。詳細については、 AWS SDK StartStreamTranscriptionCommand のドキュメントをご覧ください。 import { LanguageCode, MediaEncoding, StartStreamTranscriptionCommand, } from '@aws-sdk/client-transcribe-streaming' const command = new StartStreamTranscriptionCommand({ LanguageCode: LanguageCode.EN_US, MediaEncoding: MediaEncoding.PCM, MediaSampleRateHertz: SAMPLE_RATE, NumberOfChannels: 2, EnableChannelIdentification: true, ShowSpeakerLabel: true, AudioStream: getAudioStream(audioIterator), }) リクエストを送信すると、オーディオストリームデータと Amazon Transcribe の結果を交換するための WebSocket 接続が作成されます。 const data = await client.send(command) for await (const event of data.TranscriptResultStream) { for (const result of event.TranscriptEvent.Transcript.Results || []) { callback({ ...result }) } } result オブジェクトには、 ch_0 や ch_1 など、マイクのソースを識別するために使用できる ChannelId プロパティが含まれます。 詳細: オーディオワークレット オーディオワークレットは別スレッドで実行することで、非常に低レイテンシなオーディオ処理を実現します。実装とデモのソースコードは、 public/worklets/recording-processor.js ファイルにあります。 今回のケースでは、このワークレットを使用して主に2つのタスクを実行します。 mergerNode のオーディオを反復処理します。このノードは両方のオーディオチャンネルを含み、ワークレットへの入力となります。 mergerNode ノードのデータバイトを PCM 符号付き 16 ビット リトルエンディアン オーディオ形式にエンコードします。この処理は、反復処理ごとに、またはアプリケーションにメッセージペイロードを送信する必要があるときに行います。 これを実装するための一般的なコード構造は次のとおりです。 class RecordingProcessor extends AudioWorkletProcessor { constructor(options) { super() } process(inputs, outputs) {...} } registerProcessor('recording-processor', RecordingProcessor) このWorkletインスタンスには、 processorOptions 属性を使用してカスタムオプションを渡すことができます。デモでは、新しいメッセージペイロードを送信するタイミングを決定するためのビットレートガイドとして、 maxFrameCount: (SAMPLE_RATE * 4) / 10 を設定しています。メッセージの例は以下のとおりです。 this.port.postMessage({ message: 'SHARE_RECORDING_BUFFER', buffer: this._recordingBuffer, recordingLength: this.recordedFrames, audioData: new Uint8Array(pcmEncodeArray(this._recordingBuffer)), // PCM encoded audio format }) 2チャンネルのPCMエンコード 最も重要なセクションの一つは、2チャンネルのPCMエンコード方法です。 Amazon Transcribe APIリファレンス のAWSドキュメントによると、AudioChunkは Duration (s) * Sample Rate (Hz) * Number of Channels * 2 で定義されます。2チャンネルの場合、16000Hzで1秒は、1 * 16000 * 2 * 2 = 64000 bytesです。エンコード関数は以下のようになります。 // 入力は配列であり、各要素は AudioWorkletProcessor からの -1.0 ～ 1.0 の Float32 値を持つチャネルであることに注意してください。 const pcmEncodeArray = (input: Float32Array[]) => { const numChannels = input.length const numSamples = input[0].length const bufferLength = numChannels * numSamples * 2 // 2 bytes per sample per channel const buffer = new ArrayBuffer(bufferLength) const view = new DataView(buffer) let index = 0 for (let i = 0; i < numSamples; i++) { // 各チャンネルごとにエンコード for (let channel = 0; channel < numChannels; channel++) { const s = Math.max(-1, Math.min(1, input[channel][i])) // 32 ビット浮動小数点数を 16bit PCM オーディオ波形サンプルに変換します。 // 最大値: 32767 (0x7FFF)、最小値: -32768 (-0x8000) view.setInt16(index, s < 0 ? s * 0x8000 : s * 0x7fff, true) index += 2 } } return buffer } オーディオデータブロックの処理方法の詳細については、 AudioWorkletProcessor: process() ソッドを参照してください。PCM形式のエンコードの詳細については、 Multimedia Programming Interface and Data Specifications 1.0 を参照してください。 結論 この記事では、ブラウザの Web Audio API と Amazon Transcribe ストリーミングを使用して、リアルタイムのデュアルチャネル文字起こしを実現するウェブアプリケーションの実装の詳細について説明しました。 AudioContext 、 ChannelMergerNode 、 AudioWorklet を組み合わせることで、2 つのマイクからの音声データをシームレスに処理およびエンコードし、Amazon Transcribe に送信して文字起こしを行うことができました。特に AudioWorklet を使用することで、低レイテンシーの音声処理を実現し、スムーズで応答性の高いユーザーエクスペリエンスを提供できました。 このデモを基に、会議の録音から音声制御インターフェースまで、幅広いユースケースに対応する、より高度なリアルタイム文字起こしアプリケーションを作成できます。 ぜひこのソリューションをお試しいただき、コメント欄にフィードバックをお寄せください。 原文は こちら です。 About the Author Jorge Lanzarotti  is a Sr. Prototyping SA at Amazon Web Services (AWS) based on Tokyo, Japan. He helps customers in the public sector by creating innovative solutions to challenging problems.

6 月 17 日、 AWS Backup 論理エアギャップボールト と マルチパーティ承認 を統合する新機能の一般提供についてお知らせします。これにより、不注意または悪意のあるイベントにより AWS アカウントにアクセスできなくなった場合でもバックアップにアクセスできるようになります。AWS Backup は、AWS のサービスとハイブリッドワークロードのデータ保護を一元化および自動化するフルマネージドサービスです。中核となるデータ保護機能、ランサムウェア復旧機能、データ保護ポリシーと運用に関するコンプライアンス情報と分析を提供します。 バックアップ管理者は、AWS Backup 論理エアギャップボールトを使用して、アカウントや組織間でバックアップを安全に共有し、バックアップストレージを論理的に分離し、ダイレクトリストアをサポートして、不注意または悪意のあるイベントが発生した場合の復旧時間を短縮できます。ただし、悪意のある攻撃者や意図しない攻撃者がバックアップアカウントまたは組織の管理アカウントへのルートアクセスを取得した場合、論理エアギャップボールトに安全に保存されているにもかかわらず、バックアップには突然アクセスできなくなります。従来のアカウント復旧はサポートチャネルを通じて行う必要がありましたが、マルチパーティ承認を受けた AWS Backup では復旧ツールにすぐにアクセスできるため、解決までの時間を短縮し、復旧スケジュールをより細かく管理できます。 AWS Backup の論理エアギャップボールトに対するマルチパーティ承認により、AWS アカウントに完全にアクセスできなくなった場合でもアプリケーションデータを復旧するための保護レイヤーが強化されます。マルチパーティ承認を使用すると、組織内の信頼できる個人で構成される承認チームを作成し、論理エアギャップボールトに関連付けることができます。不注意または悪意のある行為によって AWS アカウントからロックアウトされた場合は、 AWS Organizations アカウント外のアカウントも含め、どのアカウントからでもボールトの共有を許可するよう承認チームにリクエストできます。承認されると、バックアップへのアクセスが許可され、復旧プロセスを開始できます。 仕組み AWS Backup の論理エアギャップボールトのマルチパーティ承認は、論理エアギャップボールトのセキュリティとマルチパーティ承認のガバナンスを組み合わせることで、AWS アカウントが侵害された場合でも機能する復旧メカニズムを構築します。その仕組みは次のとおりです。 1.承認チームの作成 まず、AWS Organizations 管理アカウントで承認チームを作成します。管理アカウントが新しい場合は、承認チームを作成する前に、まず AWS Identity and Access Management (IAM) Identity Center インスタンスを作成します。承認チームは、ボールト共有リクエストを承認する権限を持つ信頼できる個人 (IAM Identity Center ユーザー) で構成されます。各承認者は、新しい承認ポータルを通じて承認チームに参加するための招待状を受け取ります。 2.ボールトアソシエーション 承認チームがアクティブになったら、 AWS Resource Access Manager (AWS RAM) を使用して論理エアギャップボールトを所有するアカウントと承認チームを共有し、任意のアカウントからの承認リクエストから保護します。その後、バックアップ管理者は、この承認チームを新規または既存の論理エアギャップボールトに関連付けることができます。 3.侵害からの保護 AWS アカウントが乗っ取られたり、アクセスできなくなったりした場合は、別のアカウント (クリーンリカバリアカウント) からバックアップへのアクセスをリクエストできます。このリクエストには、 論理エアギャップボールトの Amazon リソースネーム (ARN) が arn:aws:backup:<region>:<account>:backup-vault:<name> の形式で含まれ、オプションのボールト名とコメントも含まれています。 4.マルチパーティ承認 リクエストは承認チームに送信され、承認チームは承認ポータルでリクエストをレビューします。必要最小限数の承認者がリクエストを承認すると、ボールトはリクエスト元のアカウントと自動的に共有されます。すべてのリクエストと承認は AWS CloudTrail に包括的に記録されます。 5.復旧プロセス アクセスが許可されると、侵害されたアカウントが修復されるのを待たずに、新しいリカバリアカウントのデータの復元またはコピーをすぐに開始できます。 この方法では、AWS アカウントの認証情報とは完全に独立した、バックアップにアクセスして復元するための完全に別の認証パスが提供されます。攻撃者がお客様のアカウントへのルートアクセス権を持っていたとしても、承認チームによる復旧プロセスを防ぐことはできません。 1.論理エアギャップボールトの新規作成 新しい論理エアギャップボールトを作成するには、 名前 、 タグ (オプション)、 ボールトロックプロパティ を指定します。 2.承認チームの割り当て ボールトが作成されたら、[ 承認チームの割り当て ] を選択して既存の承認チームに割り当てます。 ドロップダウンメニューから既存の承認チームを選択し、[ 送信 ] を選択して割り当てを確定します。 これで、承認チームが論理エアギャップボールトに割り当てられるようになりました。 便利なヒント 実際に緊急事態が発生する前に、復旧プロセスをテストすることが不可欠です。 別の AWS アカウントから、AWS Backup コンソールまたは API を使用して、ボールト ID と ARN を指定して、論理エアギャップボールトの共有をリクエストします。 承認チームにリクエストの承認を要請します。 承認されたら、テストアカウントのボールトからバックアップにアクセスして復元できることを確認します。 ベストプラクティスとして 、 AWS Backup Audit Manager を使用して承認チームの状態を定期的に監視し、承認基準を満たす十分な数のアクティブな参加者がいることを確認します。 クラウドガバナンスを強化するためのマルチパーティ承認 6 月 17 日、AWS アカウント管理者が製品にマルチパーティ承認を追加するために使用できる新機能の一般提供についても発表します。この投稿で強調しているように、AWS Backup はこの機能を統合した最初のサービスです。マルチパーティ承認により、管理者は分散型のレビュープロセスを使って、アプリケーション所有者が機密性の高いサービス業務を保護できるようすることができます。 便利なヒント マルチパーティ承認には、いくつかの重要なセキュリティ上の利点があります。 分散型の意志決定により、単一障害点を排除 AWS CloudTrail 統合による完全な監査可能性 認証情報の漏洩に対する保護 コンプライアンス重視の業務のための正式なガバナンス 統合サービス全体で一貫した承認エクスペリエンス 今すぐご利用いただけます マルチパーティ承認は、現在 AWS Organizations が利用可能なすべての AWS リージョン でご利用いただけます。AWS Backup の論理エアギャップボールトのマルチパーティ承認は、 AWS Backup が利用可能なすべての AWS リージョンで利用できます。 – Veliswa 原文は こちら です。

AWS Amplify Hosting では、決められたインスタンスを使用してウェブアプリケーションを構築してきました。アプリケーションが複雑化し、依存関係管理、アセット最適化、包括的なテストに集中的なビルドプロセスが必要とされるようになると、開発者は生産性とデプロイ速度を維持するために、より強力なビルド環境を必要とするようになります。 Amplify Hosting のビルド環境用のインスタンスをカスタマイズできるようになったことを喜んでお知らせします。この更新により、2 つの新しいインスタンスサイズ (Large, XLarge) が追加され、メモリと CPU リソースが増強されました。開発チームは、これで特定のニーズに合わせて構築リソースをスケーリングできるようになりました。これは特に、大規模な依存関係ツリーの処理、多数の静的アセットの処理、TypeScript コンパイルやパラレルなテストフレームワークのような、メモリ集約的な操作の実行時に有用です。 今までのビルド環境用のインスタンスの課題 大規模なアプリケーションを構築し、重たいワークロードを実行しているお客様は、 ビルド時間が長くなり、メモリエラーのため CI/CD が遅くなりビルド失敗が発生する ことがあります。開発チームが Amplify Hosting を導入する際、さまざまなワークロードに対応できるスケーラブルなビルド環境を求めています。ビルド時間の最適化は存在しますが、8GiB メモリと 4 vCPU のインスタンスサイズのコンテナ構成では、アプリケーションの拡大に限界があります。物理メモリに比べ、仮想メモリ (スワップスペース) の性能ペナルティは非常に大きく、固定環境内でコンピューティング容量やストレージを拡張する効果的な手段はありません。これらのハードウェア上の制約により、ソフトウェアの最適化だけでは根本的な障壁を乗り越えることはできません。 カスタマイズ可能なビルドインスタンスの紹介 Amplify Hosting の新しいカスタマイズ可能なビルドインスタンスにより、開発者はアプリケーションのニーズに最適なコンピューティングリソースを選択できるようになりました。これにより、リソースの制約を排除して、予測可能なビルドパフォーマンスを実現できます。Standard ビルドインスタンスに加えて、Large と XLarge のインスタンスを導入しました。次の表は、Amplify Hosting のすべてのビルドインスタンスオファリングの仕様をまとめたものです。 ビルドインスタンスの仕様 ビルド インスタンス vCPU 数 メモリ ディスク領域 Standard 4 8 GiB 128 GB Large 8 16 GiB 128 GB XLarge 36 72 GiB 256 GB アプリ作成時または既存のアプリを後から更新する際に、アプリケーションレベルでビルドインスタンスを構成できます。更新された構成は、アプリのすべてのブランチに適用され、ビルド間でアプリのビルドインスタンスサイズを変更します。ビルドをトリガーしたとき、ブランチに関係なく、アプリのビルドでは、アプリレベルで構成したビルドインスタンスサイズが使用されます。新しいアプリを作成したり、既存のアプリを更新したりするときに、ビルドインスタンスサイズを構成できます。 Amplifyコンソールを通じて新しいアプリのビルドインスタンスサイズをカスタマイズするには ：アプリ設定ステップの間に、下にスクロールして「 詳細設定 」をクリックします。ドロップダウンリストから、アプリに設定したいビルドイメージを選択します。 図1 – 新しいアプリのビルドインスタンスサイズの設定 既存のアプリのビルドインスタンスサイズを Amplify コンソールから変更するには : アプリに移動し、 ホスティングタブ を開いてから、 ビルドの設定 を選択します。 詳細設定 までスクロールダウンし、 編集 をクリックします。ドロップダウンから、アプリをアップデートしたい ビルドイメージ を選択してください。 図2 – 既存アプリのビルドインスタンスの変更 注 : ビルドインスタンスの割り当て処理には、ビルドが開始される前に追加のプロビジョニング時間が必要になる場合があります。大規模なインスタンス、特に XLarge の場合、このオーバーヘッドの時間によりビルド開始前に遅延が発生することがあります。ただし、課金されるのはビルド時間のみで、オーバーヘッド時間は課金されません。 パフォーマンステストの説明 次に、100 を超える静的ページを生成する Next.js アプリケーションを使用して、より強力なインスタンスの価値を実証します。このアプリを Amplify Hosting にデプロイする手順をガイドし、メモリ関連のビルド失敗をデバッグする方法を説明し、アプリケーションのメモリ要件を満たすためにビルドインスタンスをアップグレードする方法をご紹介します。 まず、デフォルト設定を使用して静的アプリを Amplify Hosting にデプロイします。 図3 – アプリページを確認して作成する デプロイが始まると、Amplify Hosting がリソースをプロビジョニングし、デプロイを進めます。 図4 – デプロイ中 大容量メモリの使用のためのアプリケーションの構成 デプロイが開始されると、最初のビルドで JavaScript のヒープメモリ不足のエラーが発生します。ランタイム環境がヒープメモリを要求すると、ホストの OS がメモリを割り当てます。JavaScript の Node.js V8 ランタイム環境には、ホストのメモリサイズなどの複数の条件によりデフォルトのヒープサイズ制限が適用されています。そのため、Standard と Large インスタンスではデフォルトの Node.js ヒープサイズが 2096MB ですが、XLarge インスタンスでは 4144 MB になっています。 図5 – ヒープサイズのメモリ制限により Deployment 1 が失敗しました Node.js のデフォルト ヒープメモリ制限の問題を解決するには、ヒープサイズを増やす必要があります。アプリは 8 GiB のメモリを持つ Standard ビルドインスタンスを使用しているため、ヒープサイズを 7000 MB (約 7 GB) に増やす必要があります。これにより、他のプロセスで使用するために、オペレーティングシステム用に約 1 GB のメモリが残ります。そうすれば、意図しない動作を回避できます。 次に、以下のコマンドでビルド仕様を変更し、Node.js のヒープメモリ制限を増やします。 export NODE_OPTIONS ='--max-old-space-size = 7000' 代わりに、 NODE_OPTIONS はアプリ内の環境変数として設定することもできます。詳細については、ドキュメントを参照してください。 これらの変更に対応するように、ビルド仕様ファイルも次のように更新します: version: 1 frontend: phases: preBuild: commands: # Set the heap size to 7000 MB - export NODE_OPTIONS ='--max-old-space-size = 7000' # To check the heap size memory limit in MB - node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)" - npm ci --cache .npm --prefer-offline build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/* 変更したヒープサイズで新しいデプロイをトリガするには、Deployment ページに移動し、Redeploy this version ボタンをクリックします。 しかし、アプリのビルドはまだ失敗します。今度は「Total available heap size (MB): 7048」というログが表示され、ヒープサイズが増えたことを確認できます。興味深いことに、SIGKILL ディレクティブも表示され、オペレーティングシステムがビルドプロセスを強制終了したことがわかります。これは別のメモリ不足エラーを示しています。 図6 – メモリ不足のためデプロイ2が失敗しました ビルドインスタンスのアップグレード 標準インスタンスのメモリ制限は 8 GiBであり、ヒープサイズをこの制限に近づけて増やしたにもかかわらず、依然としてメモリ不足になっています。この問題を解決するために、ビルドインスタンスを Large にアップグレードします。これにより、ビルドプロセスにより多くのメモリを割り当てることができます。 以下のようにビルド仕様ファイルを更新して、Large インスタンスにデプロイします： version: 1 frontend: phases: preBuild: commands: # Set the heap size to 14000 MB - export NODE_OPTIONS ='--max-old-space-size = 14000' # To check the heap size memory limit in MB - node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)" - npm ci --cache .npm --prefer-offline build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/* ホスティングタブ を開き、 ビルド設定 を選択して、ビルドインスタンスを更新します。その後、 詳細設定 までスクロールダウンして編集をクリックします。ドロップダウンから、 ビルドイメージ を「Large」に選択します。 図7 – ビルドインスタンスのサイズを「Large」に更新 次に、Deployment トページで「 このバージョンを再デプロイ 」をクリックして、Large インスタンスで新しい Deployment を作成します。また、ビルドログの最初の行にビルドインスタンスの仕様が表示されていることに気付きます。 図8 – Large ビルドインスタンスで進行中のデプロイ3 アプリが正常にデプロイされたことが確認できます。 図9 – アプリのデプロイ完了 まとめ このブログでは、ビルドインスタンスサイズを設定するためのアプリワークフローの作成と更新方法、および Amplify Hosting でホストされているプロジェクトのメモリ問題を解決する方法について探ってきました。ビルドインスタンスサイズについてさらに詳しく知り、この機能についてもっと学ぶには、Amplify Hosting のドキュメントをご覧ください。ビルドインスタンスの料金に関する情報は、料金ページでご確認いただけます。 著者について Sohaib Uddin Syed, Software Engineer, Amplify Hosting Sohaib Uddin Syed はAWS Amplify Hostingでソフトウェア開発エンジニアとして働いています。Sohaib は AWS のスケーラビリティを活用してフロントエンドのウェブアプリケーションを構築できるようにするソフトウェアを開発しています。空き時間には、サッカー観戦や料理、家族や友人との時間を楽しんでいます。 Angela Zheng, Software Engineer, Amplify Hosting Angela Zheng は、AWS Amplify Hosting のソフトウェア開発エンジニアです。彼女は、あらゆる規模の開発者がフロントエンド Web アプリケーションのホスティングを簡単かつ分かりやすく行えるような機能の開発に取り組んでいます。彼女の自由時間には、ダンスやバレーボールを楽しんだり、キッチンでレシピを試したり、旅行したりしています。 Matt Auerbach Matt Auerbach はニューヨーク市を拠点とする AWS Amplify チームのプロダクトマネージャーです。彼は開発者に製品やサービスについて教育し、サポートやフィードバックの主要な窓口として活動しています。マットは穏やかな性格のプログラマーで、テクノロジーを使って問題を解決し、人々の生活をより便利にすることを楽しんでいます。夜になっても…まあ、ほぼ同じことをしています。マットは X で @mauerbacとして見つけることができます。彼は以前、Twitch、Optimizely、Twilioで働いていました。 翻訳者について 稲田大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を支援しています。年明け 4 kg 太ったので、ダイエットに励んでいます。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログなどを執筆しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。いよいよ今週 AWS Summit Japan が幕張メッセで開催されます。参加が初めての方、こちらに 初めてでも楽しめるAWS Summit Japan ガイド が公開されていますので是非チェックしてみてください。Summit では生成AI関連では AIエージェント をテーマとしたハッカソンが企画されています。多数の応募チームの中から選出された14組がAIエージェントを使ったハッカソンで競い合います。審査員として QuizKncok 伊沢拓司氏、鶴崎修功氏も登場しますので楽しみです。ちなみに私もExpoエリアのブースに立っておりますので見つけた方は声かけてください。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ「株式会社フレイ・スリー様の AWS 生成 AI 活用事例：Amazon Bedrockを活用し、企業の動画活用における課題特定と解決策提示の自動化機能を構築。サポート部門の業務効率化を実現。」 株式会社フレイ・スリー様は、AI動画生成配信プラットフォーム「1ROLL」を提供する企業として、Amazon Bedrock を活用した新しい機能開発に取り組みました。動画マーケティングにおいて、制作後の運用面での課題に着目し、Amazon Bedrock Claude3.5 Sonnet v2 と Knowledge Bases を組み合わせたソリューションを構築。これにより、動画の視聴データを自動で分析し、わずか15秒で課題の特定から解決策の提示までを完了できるようになりました。この取り組みにより、サポート部門の業務効率が大幅に改善され、顧客は自身で動画活用の改善サイクルを回すことが可能になりました。 ブログ記事「Amazon Q Developer の IDE で Model Context Protocol を使用し、コンテキストに応じた開発プロセスを実現する」 Amazon Q Developer に新たに追加されたModel Context Protocol (MCP) のサポートにより、開発者の作業効率が大幅に向上します。MCP を通じて Jira や Figma などの外部ツールと直接連携することで、開発者は IDE からプロジェクト管理やデザインツールの情報にシームレスにアクセスできるようになります。例えば、Jira のタスクから Figma のデザイン仕様まで、必要な情報を自動的に取得し、コンテキストを維持したままコーディング作業を進めることができます。これにより、ツール間の行き来や情報のコピー&ペーストといった手作業が不要になり、開発プロセス全体が効率化されます。さらに、タスクの進捗更新やコメント追加などもIDE内から直接実行できるため、開発者は本来の作業に集中できる環境が整います。スクリーンショット付きで分かりやすくまとめているので是非チェックしてみてください。 ブログ記事「GENIAC プログラムから学んだ基盤モデル構築支援の教訓」 AWSはGENIAC第2期において、12の事業者に対して大規模な計算リソースと技術支援を提供しました。具体的には、127台のAmazon EC2 P5インスタンスと24台のTrn1インスタンスをデプロイし、6ヶ月にわたる基盤モデル開発を支援しました。支援の要となったのは、クロスファンクショナルなチーム体制、効果的なコミュニケーション戦略、そして事前検証済みのリファレンスアーキテクチャの提供です。さらに、詳細なデプロイメントガイドとワークショップを通じて知識共有を行い、参加企業が効率的に基盤モデル開発に取り組める環境を整備しました。この取り組みから、基盤モデル開発は単なるハードウェアの問題ではなく、組織的な課題であることが明らかになりました。また、適切なサポート体制と再現可能なテンプレート、チーム間の効果的な連携があれば、小規模なチームでも大規模な基盤モデル開発が実現可能であることも実証されました。 ブログ記事「AWS 環境の可視化を加速する Diagram-as-code とAmazon Bedrockの活用」 AWS のインフラ構成を可視化する際、多くの組織では構成図の作成・更新に多大な労力がかかっているのが現状です。本記事では、Amazon Bedrock と Diagram-as-code を組み合わせることで、この課題を解決する新しいアプローチを紹介しています。Diagram-as-code は、CloudFormation テンプレートなどの構造化されたテキストからアーキテクチャ図を自動生成できるツールです。これに Amazon Bedrock を組み合わせることで、ユーザーの自然言語での要件を理解し、データフローやセキュリティ境界といった CloudFormation テンプレートには含まれていない要素も含めたアーキテクチャ図を効率的に生成できます。 この手法は、中間ファイルを生成してから図を作成するアプローチを採用しており、生成された図の修正が容易で、かつ中間ファイルの検証が可能という利点があります。また、CIパイプラインへの組み込みも容易で、システムの変更に応じて自動的に最新の構成図を維持することができます。 ブログ記事「Amazon Novaを使用した会議の要約とアクションアイテムの抽出」 このブログ記事では、Amazon Novaファミリーの各理解モデルを使用して、会議の要約とアクションアイテムを自動的に抽出する方法について解説しています。Amazon Novaモデルは、Nova Micro(テキストのみ)、Nova Lite(マルチモーダル)、Nova Pro(速度と知能のバランス)、Nova Premier(最高性能)の4つのレベルで構成されており、Amazon Bedrockを通じて利用可能です。評価実験では、QMSumデータセットを使用して各モデルのパフォーマンスを検証し、Nova Premierが最も高い忠実度スコアを達成しましたが、より小規模なモデルでも十分な性能と高速な処理時間を実現できることが示されました。このソリューションにより、企業は会議の内容を効率的に構造化された形式で記録・活用でき、特にプロジェクト管理、カスタマーサポート、法務やコンプライアンスなどの分野で大きな価値を提供します。各モデルのスコアと処理速度の比較がされており、モデル選択の参考になると思います。 サービスアップデート 欧州（ロンドン）リージョンのAmazon Bedrock で Anthropic Claude 3.7 Sonnet が利用可能に 欧州（ロンドン）リージョンで Claude 3.7 Sonnet が利用可能になりました。このモデルの特徴は、迅速な応答と詳細な思考プロセスの両方を提供できる点です。標準モードと拡張思考モードを備え、ユーザーは用途に応じて処理時間と回答の質のバランスを調整できます。コーディングや数学、物理学など幅広いタスクで高いパフォーマンスを発揮し、トークン制限によるコスト管理も可能です。 P5 および P5en インスタンス向けの1年間の EC2 Instance Savings Plan が利用可能に EC2 の GPU 搭載インスタンスである P5 および P5en インスタンスに対して、1年間の EC2 Instance Savings Plan の提供が開始されました。このプランを利用することで、オンデマンド料金と比較して最大40%のコスト削減が可能となります。従来は3年間の契約のみでしたが、より柔軟な1年間の選択肢が追加されたことで、ビジネスニーズに合わせて最適な期間を選択できるようになりました。特に生成AIやディープラーニングの開発・運用を行うユーザーにとって、NVIDIA H100 Tensor Core を搭載した P5 インスタンスの Savings Plan は大規模なAIモデルのトレーニングや推論処理をより費用対効果の高い方法で実行することが可能になり、AI開発プロジェクトの期間が1年程度の場合でも、コスト最適化の恩恵を受けることができるようになります。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、麻辣醤にハマっています。

6 月 17 日、 AWS Shield ネットワークセキュリティディレクター (プレビュー) を発表できることを嬉しく思います。これは、SQL インジェクションや分散型サービス拒否 (DDoS) イベントなどの脅威に関連する設定上の問題の特定を簡素化し、修正を提案する機能です。この機能は、ネットワークリソース、接続、設定を識別して分析します。これらを AWS のベストプラクティスと比較して、保護が必要なリソースを浮き彫りにしたネットワークトポロジを作成します。 今日の組織は、強固なネットワークセキュリティ体制を維持する上で重大な課題に直面しています。セキュリティチームは、環境内のすべてのリソースを効率的に検出し、これらのリソースがどのように相互接続されているかを把握し、どのセキュリティサービスが現在設定されているかを特定するのに苦労することがよくあります。さらに、リソースが AWS のベストプラクティスに照らしてどの程度適切に設定されているかを判断するには、かなりの専門知識と努力が必要であることがわかっています。多くのチームが、自社のアプリケーションを一般的な脅威や新たな脅威から保護するのに最適なネットワークセキュリティサービスとルールセットを特定するのが難しいと感じています。 AWS Shield ネットワークセキュリティディレクターは、3 つの主要機能を通じてこれらの課題に対処します。まず、包括的な分析を実行して、AWS アカウント全体のリソースを検出し、リソース間の接続を識別し、現在どのネットワークセキュリティサービスと設定が実施されているかを判断します。次に、AWS ネットワークセキュリティのベストプラクティスと脅威インテリジェンスに基づいて、重大度レベル別にリソースに優先順位を付けます。最後に、リソースを保護するための AWS WAF 、 Amazon Virtual Private Cloud (Amazon VPC) セキュリティグループ 、Amazon VPC ネットワークアクセスコントロールリスト (ACL) など、適切な AWS セキュリティサービスを実装するためのステップバイステップの手順など、具体的な修復に関する推奨事項を提供します。 このサービスは、インターネットからの脅威からアプリケーションを保護したり、ポート、プロトコル、またはIP アドレス範囲に基づいてリソースへの人間のアクセスを制御したりするなど、重要なネットワークセキュリティユースケースをサポートします。ネットワーク分析を行って資産を発見し、保護が必要なリソースを特定するための時間のかかる手動プロセスを排除する分析を行います。このサービスでは、ネットワークコンテキストと AWS ベストプラクティスの遵守に基づいてセキュリティ検出結果に重大度を割り当てることにより、リソースの優先順位付けを行い、最も重要なことに集中できるようにします。さらに、どのサービスと設定がそれぞれのセキュリティギャップに対処するかについての具体的なガイダンスとともに、実行可能な推奨事項も提供します。また、 AWS マネジメントコンソール やチャットアプリケーションの Amazon Q Developer 内の AWS Shield ネットワークセキュリティディレクターから、自然言語で回答を得ることもできます。 AWS Shield ネットワークセキュリティディレクターの使用を開始する AWS Shield ネットワークセキュリティディレクターを使用するには、AWS リソースのネットワーク分析を開始する必要があります。 AWS WAF & Shield コンソール に移動し、ナビゲーションペインの [ AWS Shield ネットワークセキュリティディレクター ] で [ 使用を開始 ] を選択します。[ 使用を開始 ] を選択すると、設定ページが表示されます。このページでは、最初のネットワーク分析の実行方法を選択できます。つまり、すべてのサポート対象リージョンの検出結果を評価することも、現在のリージョンのみを評価することもできます。[ ネットワーク解析を開始 ] を選択します。 分析が完了すると、ダッシュボードページには、重大度レベル別のリソースタイプの内訳と、そのリソースに関連するネットワークセキュリティ検出結果の最も一般的なカテゴリが表示されます。リソースはタイプと重大度レベル (重要、高、中、低、参考) ごとに分類されているため、早急な対応が必要な領域を簡単に特定できます。 次に、「 リソース 」セクションを調べて、アセットの分布を把握し、環境内の重大度レベルでフィルタリングします。[ リソース概要 ] を使用して特定の重大度レベルを確認できます。これにより、関連する重大度レベルのフィルターを含む [ ネットワークセキュリティディレクター ] の下の [ リソース ] にリダイレクトされます。重大度が「 中 」のリソースを選択します。 特定のリソースを選択すると、そのリソースが他のリソースや関連する検出結果とどのように接続されているかを示すネットワークトポロジマップが表示されます。この可視化は、セキュリティ設定の潜在的な影響を理解し、露出されたパスを特定するのに役立ちます。「すべてのポートで無制限のインバウンドアクセス（0.0.0.0/0）を許可する」などの詳細な検出結果を重大度評価とともに確認します。 次に、[ ネットワークセキュリティディレクター ] の [ 検出結果 ] に移動すると、一般的な設定の問題が表示されます。検出結果ごとに、詳細な情報と推奨される修復手順を受け取ります。このサービスでは、検出結果の重大度（高、中、低）を評価して、対応の優先順位付けに役立てています。「CloudFront オリジンは CloudFront 保護なしでもインターネットにアクセスできる」といった重大度が重要な検出結果や、「すべてのポートで無制限のインバウンドアクセス (0.0.0.0/0) を許可する」といった重大度の高い検出結果が最初に表示され、次に重大度が中および低の問題が続きます。 AWS マネジメントコンソールとチャットアプリケーションの Amazon Q Developer 内の AWS Shield ネットワークセキュリティディレクターを使用して、ネットワークセキュリティ設定を自然言語で分析できます。例えば、「CloudFront ディストリビューションにネットワークセキュリティの問題はありますか?」や「ボットやスクレイパーに対して脆弱なリソースはありますか?」と尋ねることができます。 この統合により、セキュリティチームは広範なドキュメントを参照しなくても、セキュリティ体制を迅速に把握し、ベストプラクティスの実装に関するガイダンスを得ることができます。 この機能を調べるために、「私が抱えている最も重要なネットワークセキュリティの問題は何か」と尋ねます。「 Amazon Q で探索 」セクションにあります。Amazon Q はネットワークセキュリティ設定を分析し、AWS 環境のセキュリティ評価に基づいて応答を生成します。 このようにネットワークセキュリティを包括的に把握することで、新たな脅威に対する防御を強化するためのデータ主導型の意志決定が可能になります。 プレビューをお試しください AWS Shield ネットワークセキュリティディレクターは、米国東部 (バージニア北部) および欧州 (ストックホルム) リージョンでご利用いただけます。Amazon Q Developer によるネットワークセキュリティ設定の分析機能は、米国東部 (バージニア北部) でプレビュー段階にあります。ネットワークセキュリティの強化を開始するには、 AWS Shield ネットワークセキュリティディレクターコンソール にアクセスして、最初のネットワークセキュリティ分析を開始してください。 詳細については、 AWS Shield 製品 ページをご覧ください。 – Esra 原文は こちら です。

6 月 17 日、 Amazon CloudFront 向けの簡素化された新しいオンボーディングエクスペリエンスを発表しました。デベロッパーはこれを利用して、ウェブアプリケーションを数秒で高速化し、セキュリティを実現できます。この新しいエクスペリエンスと、 AWS WAF コンソールエクスペリエンスの改善により、デベロッパーは、高度な技術的専門知識なしで、コンテンツ配信およびセキュリティサービスをこれまで以上に簡単に設定できるようになります。 従来、ウェブアプリケーションのためにコンテンツ配信とセキュリティを設定するには、複数の Amazon Web Services (AWS) サービスを適切に利用して、設定に関して数多くの意思決定を行う必要がありました。この新しい CloudFront オンボーディングエクスペリエンスにより、デベロッパーは、わずか数クリックで、DNS と TLS 証明書を備えた、完全に設定されたディストリビューションを作成できるようになりました。 Amazon CloudFront は、コンテンツとアプリケーションをグローバルに配信したいと考えているあらゆる規模の組織に魅力的なメリットを提供します。コンテンツ配信ネットワーク (CDN) である CloudFront は、ユーザーに最も近いエッジロケーションからコンテンツを配信することでアプリケーションのパフォーマンスを大幅に改善して、レイテンシーを低減し、ユーザーエクスペリエンスを改善します。パフォーマンスに加えて、CloudFront は、エッジにおける分散型サービス拒否 (DDoS) 攻撃や他の脅威からアプリケーションを保護する組み込みのセキュリティ機能を提供し、悪意のあるトラフィックがオリジンインフラストラクチャに到達するのを防ぎます。このサービスは、手動による介入を必要とせずにトラフィック需要に合わせて自動的にスケールし、計画されたトラフィックの急増と予期しないトラフィックの急増の両方に容易に対応します。実行しているのが、小規模なウェブサイトと大規模なアプリケーションのいずれであるかにかかわらず、他の AWS サービスとの CloudFront の統合と、簡素化された新しいコンソールエクスペリエンスにより、ウェブアプリケーションに不可欠なこれらの機能をこれまで以上に簡単に実装できます。 合理化された CloudFront 設定 新しい CloudFront コンソールエクスペリエンスは、簡素化されたワークフローを通じてデベロッパーをガイドします。このワークフローは、ディストリビューションに使用するドメイン名の入力から始まります。 Amazon Route 53 を利用する場合、このエクスペリエンスは TLS 証明書のプロビジョニングと DNS レコード設定を自動的に処理し、セキュリティのベストプラクティスをデフォルトで組み込みます。この統合アプローチにより、 AWS Certificate Manager 、Route 53、AWS WAF などの複数のサービスを切り替える必要がなくなり、デベロッパーは、各サービスの詳細な設定オプションを深く理解することなく、より迅速に本番に移行できます。 例えば、デベロッパーは、ドメイン名を入力し、ロードバランサーをオリジンとして選択することで、ロードバランサーを経由するアプリケーションのために安全な CloudFront ディストリビューションを作成できるようになりました。コンソールは、アプリケーションのタイプと要件に基づいて最適な CDN とセキュリティ設定を自動的に推奨するため、デベロッパーは AWS のベストプラクティスに従っていると確信しながらデプロイできます。 Amazon Simple Storage Service (Amazon S3) で静的ウェブサイトをホストしたいと考えているデベロッパーのために、CloudFront はいくつかの重要なメリットを提供します。まず、ユーザーにより近いエッジロケーションにコンテンツをキャッシュすることでウェブサイトのパフォーマンスが改善され、レイテンシーが低減し、ページのロード時間が短縮されます。次に、セキュリティレイヤーとして機能することで S3 バケットを保護するのに役立ちます。CloudFront をコンテンツへの唯一のアクセス方法として設定することで、S3 バケットへの直接アクセスを防ぐことができます。新しいエクスペリエンスは、これらのセキュリティのベストプラクティスを自動的に設定します。 AWS WAF を利用したセキュリティ統合の強化 新しい CloudFront エクスペリエンスを補完するものとして、アプリケーションのタイプとセキュリティ要件に基づいて厳選された一連のセキュリティルールであるインテリジェントなルールパックを備えている、改善された AWS WAF コンソールも導入します。これらのルールパックにより、デベロッパーは包括的なセキュリティコントロールを実装できます。セキュリティのエキスパートである必要はありません。 デベロッパーは、CloudFront ディストリビューションを作成する際に、これらの新しいルールパックを使用した統合エクスペリエンスを通じて AWS WAF 保護を有効にできるようになりました。コンソールは、デベロッパーがデプロイ前に設定をプレビューおよび検証するために使用できるセキュリティ設定に関する明確なレコメンデーションを提供します。 6 月 17 日、ウェブアプリケーションは、SQL インジェクション攻撃、クロスサイトスクリプティング (XSS)、および他の OWASP Top 10 の脆弱性など、数多くのセキュリティの脅威に直面しています。新しい AWS WAF 統合により、これらの一般的な攻撃ベクトルに対する保護が自動的に提供されます。推奨されるルールパックは、悪意のあるボットトラフィック、一般的なウェブエクスプロイト、既知の不正行為者に対する即時の保護を提供し、インフラストラクチャに過負荷をかける可能性のある direct-to-origin 攻撃を防止します。 詳しく見てみましょう Amazon CloudFront ディストリビューションを作成したことがあるお客様は、すぐに変更点に気付くでしょう。新しいエクスペリエンスは、利用しやすく、容易に理解できます。私の例では、Amazon S3 をオリジンとして使用して、静的ウェブサイトのディストリビューションを作成することにしました。 [ステップ 1] では、ディストリビューションに名前を付けて、 [単一のウェブサイトまたはアプリケーション] または新しい [マルチテナントアーキテクチャ] オプションを選択します。このオプションを使用すると、複数のドメインを使用しながらも共通の設定を共有するディストリビューションを設定できます。 [単一のウェブサイトまたはアプリケーション] を選択し、オプションのドメイン名を入力します。新しいエクスペリエンスでは、 [ドメインを確認] ボタンを使用して、ドメインが Route 53 ゾーンファイルとして設定されていることを確認できます。 次に、ディストリビューションのオリジンを選択します。これは、CloudFront がコンテンツを取得して配信およびキャッシュする場所です。 [オリジンタイプ] で、Amazon S3 を選択します。前掲のスクリーンショットに示すように、選択できる追加オプションがいくつかあります。各オプションは、極めて一般的なユースケースで、可能な限り簡単に設定できるように設計されています。次に、バケット名を入力するか、または [S3 を参照] ボタンを使用して、S3 バケットを選択します。 次に、オリジンとしての Amazon S3 の使用に関連するいくつかの設定があります。 [CloudFront にオリジンへのアクセスを付与] オプションは重要です。このオプション (デフォルトで選択されています) により、S3 バケットポリシーが更新され、CloudFront がバケットにアクセスできるようになります。また、バケットが オリジンアクセスコントロール 用に設定されます。これにより、完全にプライベートなバケットを使用でき、バケット内のアセットには CloudFront を通じてのみアクセスできることを確信できます。これは、バケットとアセットを安全に保つための重要なステップです。 次のステップでは、AWS WAF を設定するオプションが表示されます。AWS WAF を有効にすると、着信リクエストがウェブサーバーに送信される前に、それらの各リクエストに潜在的な脅威が含まれていないかが検査されるため、ウェブサーバーはより良く保護されます。AWS WAF を有効にするにはコストがかかります。次のスクリーンショットに示すように、追加料金の見積りに役立つ料金見積りツールを使用できます。 今すぐご利用いただけます 新しい CloudFront オンボーディングエクスペリエンスと、強化された AWS WAF コンソールは、これらのサービスが提供されているすべての AWS リージョン で本日よりご利用いただけます。これらの新機能は、 AWS マネジメントコンソール を通じて利用を開始できます。これらの新しいエクスペリエンスの利用に追加料金はかかりません。お支払いいただくのは、それぞれの料金モデルに基づいて、使用した CloudFront および AWS WAF リソースについての料金のみです。 新しい CloudFront オンボーディングエクスペリエンスと、AWS WAF の改善点の詳細については、 Amazon CloudFront ドキュメント および AWS WAF ドキュメント にアクセスしてください。これらの簡素化されたエクスペリエンスを活用して、より高速かつ安全なウェブアプリケーションの構築を今すぐ始めましょう。 原文は こちら です。

6 月 17 日、 AWS Certificate Manager (ACM) からエクスポート可能なパブリック SSL/TLS 証明書についてお知らせします。このリリースに先立ち、お客様は追加コストなしで、 パブリック証明書を発行 したり、サードパーティーの認証期間 (CA) が発行した 証明書をインポート したりできるとともに、これらの証明書を AWS の統合サービス ( Elastic Load Balancing (ELB) 、 Amazon CloudFront ディストリビューション、 Amazon API Gateway など) にデプロイできます。 ACM からパブリック証明書をエクスポートし、プライベートキーに対するアクセスを取得して、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、またはオンプレミスホストで実行されているあらゆるワークロードで使用できるようになりました。エクスポート可能なパブリック証明書の有効期間は 395 日間です。発行時と更新時に料金が発生します。 ACM からエクスポートされたパブリック証明書は Amazon Trust Services によって発行され、Apple や Microsoft などの一般的に使用されているプラットフォーム、および Google Chrome や Mozilla Firefox などの人気のウェブブラウザによって広く信頼されています。 ACM のエクスポート可能なパブリック証明書の実際の動作 パブリック証明書をエクスポートするには、まず新しいエクスポート可能なパブリック証明書をリクエストします。以前に作成したパブリック証明書をエクスポートすることはできません。 開始するには、 ACM コンソール で [証明書をリクエスト] を選択し、 [エクスポートを許可] セクションで [エクスポートを有効にする] を選択します。 [エクスポートを無効にする] を選択すると、この証明書のプライベートキーは ACM からエクスポートできなくなります。また、この設定は証明書の発行後に変更できません。 AWS コマンドラインインターフェイス (AWS CLI) で request-certificate コマンドを使用して、 Export=ENABLED オプションを指定してエクスポート可能なパブリック証明書をリクエストすることもできます。 aws acm request-certificate \ --domain-name mydomain.com \ --key-algorithm EC_Prime256v1 \ --validation-method DNS \ --idempotency-token <token> \ --options \ CertificateTransparencyLoggingPreference=DISABLED \ Export=ENABLED パブリック証明書をリクエストしたら、証明書をリクエストしているドメインを所有または管理していることを証明するために、ドメイン名を検証する必要があります。ドメイン検証が成功すると、通常は数秒以内に証明書が発行されます。 証明書のステータスが [発行済み] になったら、 [エクスポート] を選択して発行済みのパブリック証明書をエクスポートできます。 プライベートキーを暗号化するためのパスフレーズを入力します。このパスフレーズは、後でプライベートキーを復号するために必要になります。パブリックキーを取得するには、 [PEM エンコーディングを生成] を選択します。 PEM エンコーディングされた証明書、証明書チェーン、プライベートキーをコピーしたり、それぞれを個別のファイルにダウンロードしたりできます。 export-certificate コマンドを使用して、パブリック証明書とプライベートキーをエクスポートできます。セキュリティを強化するには、ファイルエディタを使用してパスフレーズと出力キーをファイルに保存し、コマンド履歴に保存されないようにします。 aws acm export-certificate \ --certificate-arn arn:aws:acm:us-east-1:<accountID>:certificate/<certificateID> \ --passphrase fileb://path-to-passphrase-file \ | jq -r '"\(.Certificate)\(.CertificateChain)\(.PrivateKey)"' \ > /tmp/export.txt これで、Amazon EC2 インスタンスなど、SSL/TLS 通信を必要とするワークロードで、エクスポートしたパブリック証明書を使用できるようになりました。詳細については、EC2 インスタンスでの「 Configure SSL/TLS on Amazon Linux 」にアクセスしてください。 知っておくべきこと エクスポート可能なパブリック証明書について知っておくべきことがいくつかあります: キーのセキュリティ – 組織の管理者は、AWS IAM ポリシーを設定して、エクスポート可能なパブリック証明書をリクエストできるロールとユーザーを認可できます。現在証明書を発行する権限を持つ ACM ユーザーに、エクスポート可能な証明書を発行する権限が自動的に付与されます。また、ACM 管理者は証明書を管理し、証明書の取り消しや削除などのアクションを実行することもできます。エクスポートされたプライベートキーは、安全なストレージとアクセスコントロールを使用して保護する必要があります。 取り消し – 組織のポリシーを遵守するため、またはキーの漏えいによる影響を軽減するために、エクスポート可能なパブリック証明書を取り消す必要がある場合があります。取り消すことができるのは、以前にエクスポートされた証明書のみです。証明書の取り消しプロセスはグローバルかつ永続的です。取り消されると、取り消された証明書を取得して再利用することはできません。詳細については、AWS ドキュメントの「 Revoke a public certificate 」にアクセスしてください。 更新 – Amazon EventBridge を利用してエクスポート可能なパブリック証明書の自動更新イベントを設定することで、証明書の更新をモニタリングし、更新が発生したときに証明書のデプロイを処理するためのオートメーションを作成できます。詳細については、AWS ドキュメントの「 Using Amazon EventBridge 」にアクセスしてください。これらの証明書はオンデマンドで更新することもできます。証明書を更新すると、新しい証明書の発行にについて課金されます。詳細については、AWS ドキュメントの「 Force certificate renewal 」にアクセスしてください。 今すぐご利用いただけます 他のコンピューティングワークロードや、ELB、Amazon CloudFront、Amazon API Gateway を使用するために、ACM からエクスポート可能なパブリック証明書を発行して、証明書をプライベートキーとともにエクスポートできるようになりました。 ACM を利用してエクスポート可能なパブリック証明書を作成すると、追加料金がかかります。完全修飾ドメイン名ごとに 15 USD、ワイルドカードドメイン名ごとに 149 USD かかります。証明書の有効期間中に一度だけお支払いいただき、証明書の更新時にのみ再度課金されます。詳細については、「 AWS Certificate Manager サービスの料金 」ページにアクセスしてください。 ACM のエクスポート可能なパブリック証明書は、 ACM コンソール でお試しいただけます。詳細については、 ACM ドキュメントページ にアクセスしてください。また、 AWS re:Post for ACM または通常の AWS サポート担当者を通じてフィードバックをぜひお寄せください。 – Channy 原文は こちら です。

リアルタイム機能は、ユーザーがすぐに更新されたり双方向の体験を求める現代のアプリケーションにおいて不可欠となっています。チャットアプリ、ライブダッシュボード、ゲームのリーダーボード、IoT システムなどを構築する場合、 AWS AppSync Events は WebSocket API を通じてこれらのリアルタイム機能を実現し、スケーリングや接続管理を気にかけることなく、スケーラブルで高性能なリアルタイムアプリケーションを構築できるようにしています。 AWS Lambda 用の Powertools は、監視、バッチ処理、 AWS Systems Manager Parameter Store 統合、冪等性、フィーチャーフラグ、 Amazon CloudWatch メトリクス、構造化ログなどを含む開発者向けツールキットです。Powertools for AWS は、Python、TypeScript、.NET で提供される新しい AppSyncEventsResolver を通じて、AppSync Events をサポートするようになりました。この新機能により、ビジネスロジックに集中できるように設計された機能が強化され、開発体験が向上します。 AppSyncEventsResolver は、イベントの処理のためのシンプルで一貫したインターフェイスを提供し、イベントのフィルタリング、変換、ルーティングなどの一般的なパターンに対する組み込みサポートも提供されます。 この記事では、 TypeScript の例を見ますが、 Powertools for AWS (Python) と Powertools for AWS (.NET) を使えば、Python と .NET 関数でも同じ機能を利用できます。 図 1 – AWS AppSync、Lambda、および Powertools を使用したリアルタイムイベントハンドリングアーキテクチャー 本ブログでは、以下の点を学びます。 AppSyncEventsResolver を使用してイベントハンドラを設定する 最適なパフォーマンスのために、さまざまなイベント処理パターンを実装する パターンベースのルーティングを使用して、イベントハンドラを整理する 一般的な使用パターンに対して、組み込み機能を活用する 始め方 AppSyncEventsResolver は、 AWS Lambda 関数内での AppSync Events を処理する簡単で宣言的な方法です。このイベントリゾルバーによって、 PUBLISH イベントと SUBSCRIBE イベントをリッスンできます。 PUBLISH イベントは、クライアントがチャネルにメッセージを送信するときに発生します。一方、 SUBSCRIBE イベントは、クライアントがチャネルをサブスクリプションしようとしたときに発生します。異なる名前空間やチャネルのハンドラを登録することで、イベント駆動型の通信を管理できます。 次に、作業を開始してさまざまな開発体験を向上させるための主要機能について見ていきましょう。 AppSyncEventsResolver を設定する基本的な例は次のとおりです。 import { AppSyncEventsResolver, UnauthorizedException, } from '@aws-lambda-powertools/event-handler/appsync-events'; // Types for our message handling type ChatMessage = { userId: string ; content: string ; } // Simple authorization check const isAuthorized = (path: string, userId ?: string): boolean => { // check against your authorization system if (path.startsWith('/chat/private') && ! userId) { return false ; } return true ; }; // Message processing logic const processMessage = async (payload: ChatMessage) => { // - Validate message content // - Store in database // - Enrich with additional data return { ...payload, timestamp: new Date().toISOString() }; }; const app = new AppSyncEventsResolver(); // Handle publish events for a specific channel app.onPublish('/chat/general', async (payload: ChatMessage) => { // Process and return the message return processMessage(payload); }); // Handle subscription events for all channels app.onSubscribe('/*', async (info) => { const { channel: { path }, request, } = info ; // Perform access control checks if (! isAuthorized(path, userId)) { throw new UnauthorizedException(`not allowed to subscribe to ${ path } `); } return true ; }); export const handler = async (event, context) => app.resolve(event, context); AppSyncEventsResolver クラスは、受信したイベントデータを解析し、イベントの種類に応じて適切なハンドラメソッドを呼び出します。ここで何が起こっているのかを解説しましょう。 パターンベースのルーティング AppSyncEventsResolver は、チャネルパスに基づいてイベントハンドラを整理できる直感的なパターンベースのルーティングシステムを使用しています。以下のことが可能です： 特定のチャネルを処理する（/chat/general） 名前空間にワイルドカードを使用する（/chat/*） グローバルなキャッチオールハンドラを作成する（/*） import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; const app = new AppSyncEventsResolver(); // Specific channel handler app.onPublish('/notifications/alerts', async (payload) => { // your logic here }); // Handle all channels in the notifications namespace app.onPublish('/notifications/*', async (payload) => { // your logic here }); // Global catch-all for unhandled channels app.onPublish('/*', async (payload) => { // your logic here }); export const handler = async (event, context) => app.resolve(event, context); 最も一般的なキャッチオールハンドラは /* で、これはどの名前空間やチャネルにもマッチします。一方、 /default/* は、 default 名前空間のあらゆるチャネルにマッチします。複数のハンドラが同じイベントにマッチする場合は、ライブラリは最も具体的なハンドラを呼び出し、より一般的なハンドラは無視されます。たとえば、 /default/channel1 に対してハンドラが登録されており、さらに /default/* にもハンドラが登録されている場合、Powertools は /default/channel1 にマッチするイベントでは最初のハンドラを呼び出し、2 番目のハンドラは無視されます。このアプローチにより、イベントがどのように処理されるかを制御し、不要な処理を回避できます。デフォルトでは、Powertools はどのハンドラとも合致しないイベントについては、そのままイベントを返し、警告をログに記録します。つまり、そういったイベントは変更されずにそのまま渡されます。このアプローチは、特定のイベントに対してはカスタムロジックを適用しつつ、他のイベントはデフォルトの挙動で処理できるため、徐々にライブラリを適用していくのに役立ちます。 Subscription ハンドリング Powertools はサブスクリプションイベントを処理する簡単な方法も提供します。受信したイベントを自動的に解析し、イベントタイプに基づいて適切なハンドラを呼び出します。デフォルトでは、Lambda ハンドラがエラーをスローしたり要求を明示的に拒否しない限り、AppSync はサブスクリプションを許可します。サブスクリプションが拒否されると、AppSync はクライアントに 4xx レスポンスを返し、サブスクリプションが確立されるのを防ぎます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; import { Metrics, MetricUnit } from '@aws-lambda-powertools/metrics'; import type { Context } from 'aws-lambda'; const metrics = new Metrics({ namespace: 'serverlessAirline', serviceName: 'chat', singleMetric: true, }); const app = new AppSyncEventsResolver(); app.onSubscribe('/default/foo', (event) => { metrics.addDimension('channel', event.info.channel.path); metrics.addMetric('connections', MetricUnit.Count, 1); }); export const handler = async (event: unknown, context: Context) => app.resolve(event, context); サブスクリプションイベントが到着すると、このライブラリはイベントオブジェクトを第 1 引数としてハンドラを呼び出します。アクセス制御チェックの実行など、サブスクリプションイベントに基づいて必要な処理を行えます。 app.onSubscribe('/private/*', async (info) => { const userGroups = info.identity?.groups && Array.isArray(info.identity?.groups) ?info.identity ?.groups : [] ; const channelGroup = 'premium-users'; if (!userGroups.includes(channelGroup)) { throw new UnauthorizedException( `Subscription requires ${ channelGroup } group membership` ); } }) サブスクリプションイベントは同じマッチングルールに従い、イベントとコンテキストへの完全なアクセスを提供します。ワイルドカード * 文字を使用して任意の名前空間やチャンネルに対するキャッチオールハンドラを登録でき、ハンドラ内でイベントとコンテキストオブジェクトに完全にアクセスすることもできます。 イベントとコンテキストの完全なアクセス リゾルバーがイベントハンドリングを簡素化しますが、必要に応じてイベントとコンテキストオブジェクトに完全にアクセスできます。これは、リクエストヘッダーや Lambda コンテキストの残り実行時間など、カスタムロジックを実装するために追加情報が必要な場合に役立ちます。 リゾルバーは、全てのイベントとコンテキストを第 2 引数と第 3 引数として各ハンドラに渡します。これにより、既存のコードを変更することなく、関連する全ての情報にアクセスできます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; import { Logger } from '@aws-lambda-powertools/logger'; const logger = new Logger({ logLeveL: 'INFO', serviceName: 'serverlessAirline' }); const app = new AppSyncEventsResolver({ logger }); app.onPublish('/orders/process', async (payload, event, context) => { // Access request headers const { headers } = event.request ; // Access Lambda context const { getRemainingTimeInMillis } = context ; logger.info('Processing event details', { headers, remainingTime: getRemainingTimeInMillis() }); return payload ; }); export const handler = async (event, context) => app.resolve(event, context); エラーハンドリング AppSyncEventsResolver には、Lambda 関数の障害を防ぎながら、エラーが適切に AppSync に通知されるよう組み込みのエラー処理機能があります。AppSync はそれらのエラーをクライアントに伝播させます。ハンドラでエラーが発生した場合、リゾルバ は Lambda の呼び出し全体を失敗させるのではなく、そのエラーをイベントごとのレスポンスペイロードに含めます。 このアプローチにより、Lambda 関数は実行を継続しながら、AppSync に適切にフォーマットされたエラーメッセージを提供します。複数のイベントを処理する場合、1つのイベントが失敗しても、他のイベントは正常に処理を続けます。これは、あるイベントのエラーが他のイベントの処理に影響を与えないようにしたい並列処理シナリオで特に役立ちます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; const app = new AppSyncEventsResolver(); app.onPublish('/messages', async (payload) => { // If message contains "error", throw an exception if (payload.message === "error") { throw new Error("Invalid message"); } return payload ; }); export const handler = async (event, context) => app.resolve(event, context); // When processing this event: // { // "id": "123", // "payload": { // "message": "error" // } // } // The resolver will return: // { // "id": "123", // "error": "Error - Invalid message" // } 高度なパターンとベストプラクティス AppSyncEventsResolver には、堅牢でメンテナンス性の高いリアルタイムアプリケーションを構築するのに役立つ、高度な機能が追加されています。これらの機能とその効果的な利用方法を見ていきましょう。 パブリッシュ処理について デフォルトでは、メッセージごとにルートハンドラを 1 回呼び出します。Powertools がメッセージの反復処理やイベントレスポンス形式の変換を行うため、ビジネスロジックに集中し、定型コードを書く必要がありません。あとはペイロードとして使いたい値を返すか、そのメッセージでエラーをスローするだけです。ライブラリがペイロードを正しいイベント ID と関連付けます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; import { Metrics, MetricUnit } from '@aws-lambda-powertools/metrics'; type SensorReading = { deviceId: string ; temperature: number ; humidity: number ; timestamp: string ; } const app = new AppSyncEventsResolver(); const metrics = new Metrics({ namespace: 'SensorReadings' }); app.onPublish('/sensors/readings', async (payload: SensorReading) => { // Process each sensor reading independently if (payload.temperature > 100) { metrics.addDimension('alertType', 'highTemperature'); metrics.addMetric('HighTemperature', MetricUnit.Count, 1); throw new Error('Temperature reading too high'); } // Enrich the payload with processing timestamp return { ...payload, processed: true, processedAt: new Date().toISOString() }; }); export const handler = async (event, context) => app.resolve(event, context); このパターンは、単一のイベントに対するロジックのみを記述すればよいため、開発を簡素化します。Powertools が残りを自動的に処理します。 集約処理 集約モードでは、イベントを個別に処理するのではなく、複数のイベントを単一のバッチとして処理することができます。これは、データベースへの複数のクエリを1回の操作で送信するなど、リソース使用を最適化したい場合や、処理前に複数のイベントをまとめて分析したい場合に特に役立ちます。どちらのモードでもイベント処理を完全に制御できますが、集約モードでは一度にイベントのリスト全体にアクセスできます。 これを実現するには、 aggregate オプションを true に設定します。このモードを使用すると、リゾルバーはイベントのリスト全体を1回の呼び出しでハンドラに送信し、バッチとして処理することができます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; const app = new AppSyncEventsResolver(); app.onPublish('/default/*', async (events) => { const results = [] ; for (const event of events) { try { results.push(await handleDefaultNamespaceCatchAll(event)); } catch (error) { results.push({ error: { errorType: 'Error', message: error.message, }, id: event.id, }); } } return results ; }, { aggregate: true, }); export const handler = async (event, context) => app.resolve(event, context); 集約オプションはパブリッシュイベントにのみ使用可能であり、このオプションを使用する場合は、イベントの処理と適切なレスポンスの返却に責任を持つ必要があることに注意してください。Powertools は引き続きイベントを正しいハンドラにルーティングしますが、イベントの処理方法は完全にあなたの制御下にあります。 イベントフィルタリング イベントをフィルタリングするには、チャネルハンドラでエラーをスローします。ハンドラが特定のイベントに対してエラーをスローすると、ライブラリはそれをキャッチし、同じインデックスのレスポンスリストにエラーオブジェクトを追加します。これは、対応するメッセージを破棄すべきであることを示します。これにより、イベントを静かにフィルタリングするか、サブスクライバーに意味のあるエラーフィードバックを提供するかを選択できます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; app.onPublish('/moderation/*', async (payload) => { // Filter out inappropriate content if (await containsInappropriateContent(payload)) { throw new CustomError('Content violates guidelines'); } // Process valid content return await processContent(payload); }); export const handler = async (event, context) => app.resolve(event, context); まとめ Powertools for AWS の AppSyncEventsResolver は、シンプルで一貫したインターフェースを提供することで、AppSync Events を処理する開発体験を向上させます。定型コードを削減し、一般的なパターンに対する組み込みサポートを提供することで、インフラコードではなくビジネスロジックに集中できます。 詳細については： Powertools for AWS のドキュメント で詳細情報を探索する サービスについてもっと学ぶために AppSync Event のドキュメント をチェックする 貢献や問題を報告するために私たちの GitHub リポジトリ を訪問する これらの新機能で何を構築するのか楽しみにしています。フィードバックを共有し、アプリケーションで AppSyncEventsResolver をどのように使用しているかお知らせください！ 本ブログは「 Simplify AWS AppSync Events integration with Powertools for AWS Lambda 」 を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

企業の環境では、カスタムアプリケーションが業務の改善、生産性の向上、組織内の知識の集中化において重要な役割を果たします。しかし、これらのツールは多くの場合、関連する情報にユーザーが素早く直感的にアクセスできるような賢い会話型インターフェイスが備わっていません。膨大な組織データから文脈に応じた洞察を把握したり、複雑なクエリを解釈したりするには、従来のダッシュボードや検索バーでは限界があります。 生成 AI は、この課題に対する強力なソリューションを提供します。開発者が制御できるアプリケーションに会話型エクスペリエンスを直接埋め込むことで、組織は、ユーザーが自然言語で質問をし、正確で行動可能な回答を受け取れるようにできます。 Amazon Q Business は、大規模な言語モデルのインフラストラクチャを管理する負担なしに、この機能をセキュアな 埋め込み可能な HTML インラインフレーム (iframe) 経由で提供します。 このブログは、ナレッジポータル、サポートダッシュボード、社内向け Web ツールなどのカスタムアプリケーションやエンタープライズ向けアプリケーションを構築する開発者を対象としています。Amazon Q Business、 AWS Amplify Gen 2 、および AWS Cloud Development Kit (CDK) を使用して、生成 AI 搭載の会話型エクスペリエンスをアプリケーションに埋め込む方法を示します。Amazon Q Business をアプリケーションに埋め込むには、アプリケーションのソースコードへのアクセスが必要となり、カスタムコードの埋め込みが不可能なサードパーティ SaaS プラットフォームでは利用できません。 このブログでは以下について紹介します。 社内文書やナレッジベースへの会話形式によるアクセス 企業の ID 管理システムとの安全な統合 複雑なバックエンド実装なしで、スケーラブルな AI 駆動型検索の実現 AWS Amplify のフロントエンドおよびバックエンド開発機能を使用したスピーディーなデプロイ Amazon Q Business と AWS Amplify を使えば、アプリに生成 AI を素早く追加でき、生産性を向上、手作業を削減、意思決定を加速できます。 Figure 1 Submitting a prompt to Amazon Q Business iframe. 内部アプリケーションに生成 AI アシスタントを組み込むには、以下の AWS サービスを活用します。 AWS Amplify : セキュアなフルスタックアプリケーションを構築、デプロイ、管理するための包括的なツールとサービスのセットです。認証には Amazon Cognito、ストレージには Amazon S3、その他の AWS インフラストラクチャ構築には CDK とタイトに統合されていることで、フロントエンドとバックエンドの開発を簡素化します。 Amazon Cognito : アプリケーションに認証と承認機能を追加するためのマネージドサービスです。Cognito は、ユーザー登録、サインイン、アクセス制御をサポートし、エンタープライズアクセス管理のために外部のアイデンティティプロバイダー (IdP) と連携することができます。 AWS IAM Identity Center : IAM Identity Center は、内部ユーザーに対してセキュアで集中管理されたアクセス管理を可能にします。Okta、Microsoft Entra ID、Ping Identity などのエンタープライズプロバイダーとのアイデンティティ連携をサポートしており、組織が統一された認証ポリシーを適用し、埋め込み型 AI アシスタントへのアクセスを許可されたユーザーのみに制限することができます。 Amazon Q Business : 内部アプリケーションに iframe 経由で埋め込むことができるマネージド型の生成 AI サービスです。Amazon Q Business は Amazon S3 などのエンタープライズデータソースに接続し、インテリジェントなアシスタントインターフェースを通じて自然言語のクエリを可能にします。セキュアなアクセスをサポートしており、IAM Identity Center と統合することでエンタープライズでの連携利用が可能です。 Amazon Simple Storage Service (S3) : 内部文書、PDF、マニュアル、その他の非構造化コンテンツを保存するための、耐久性とスケーラビリティに優れたオブジェクトストレージサービスです。これらのファイルが Amazon Q Business アシスタントのナレッジベースとなり、従業員からの問い合わせに対してコンテキストを含む応答を可能にします。 Figure 2 From Build to Embed Architecture Diagram 前提条件 AWS アカウント : AWS Amplify は AWS フリーティア の一部であることに注意してください。 インストール: npm (v9 以降)、 git (v2.14.1 以降)。 テキストエディタ: このガイドでは VSCode を使用しますが、お好みの IDE を使用できます。 サンプルデータセット: PDF をアップロードするか、 Kaggle で利用可能なサンプルデータセットを確認してください。 IAM Identity Center : IAM ID センターインスタンスを有効化 し、 ID センターディレクトリにユーザーを追加 する必要があります。 リポジトリのクローン ステップ 1: AWS サンプルの リポジトリ に移動し、自分の GitHub リポジトリにフォークしてください。 ステップ 2: ターミナルで以下のコマンドを実行して、アプリをクローンしてください。 git clone https://github.com//sample-build-and-embed-genai-apps.git ステップ3 ：以下のコマンドをターミナルで実行して、新しくクローンしたリポジトリをVSCodeでアクセスします。 cd sample-build-and-embed-genai-apps code . -r VSCode は、リポジトリフォルダを開き、次のセクションで確認するアプリのコードを含む Amplify フォルダが表示されます。 Figure 3 Opening code in VSCode. ステップ4： 以下のコマンドを実行して、Amplify Gen 2 パッケージを含む必要なパッケージをインストールします。 npm install Amplify のバックエンド 最終的なアプリ (投稿の冒頭の GIF 動画で確認できます) では、ユーザーはアプリケーションにログインし、チャットボットアイコンをクリックして、連携アクセス認証を行います (これは iframe を通して Amazon Q Business の Web エクスペリエンスにアクセス するためです)。その後、Amazon Q Business に質問を開始できるようになります。このコードは、クローンしたリポジトリにあります。ここでは、Amplify で開発およびホストされた検索エンジンアプリを作成する主要なステップを説明します。 Figure 4 Amplify Gen 2 Project Folder Structure. amplify/auth/resource.ts ファイル (図 5) では、アプリケーションにアクセスしファイルをアップロードするために、ユーザーがメールアドレスでログインする必要がある認証が設定されています。メール認証によってログインを有効にすることで、機密データと機能にアクセスできるのが認証されたユーザーのみという制限を設けています。 import { defineAuth } from '@ aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true, }, }); Figure 5 defineAuth in amplify/auth/resource.ts amplify/storage/resource.ts ファイル (図 6) では、 Amplify ストレージ を構成して、セキュアでユーザー固有のファイル管理を有効にしています。 defineStorage 関数は、ストレージリソースを分かりやすい名前 q-datasource-bucket でインスタンス化し、 protected/{entity_id}/* パスにアクセス制御を適用します。 この構成により、認証済みのユーザーは自身のスコープ付きディレクトリ内のファイルを読み取ることができ、ファイル所有者には読み取り、書き込み、削除のアクセス権限が付与されます。 import { defineStorage } from "@ aws-amplify/backend"; export const storage = defineStorage({ name: "q-datasource-bucket", access: (allow) => ({ 'protected/{entity_id}/*': [ allow.authenticated.to(['read']), allow.entity('identity').to(['read', 'write', 'delete']) ] }) }); Figure 6 defineStorage in amplify/storage/resource.ts amplify/backend.ts （図7）ファイルでは、アプリケーションの重要な側面を設定するために CDK ライブラリをインポートします。 aws-iam モジュールは権限管理に使用され、 aws-kms は暗号化とキー管理を処理し、 aws-qbusiness は Amazon Q Business をスタックにインテグレーションします。各ライブラリは、アプリケーションが安全であり、AWSサービスと適切に統合されるよう、特定の役割を果たしています。 import * as iam from 'aws-cdk-lib/aws-iam'; import * as kms from 'aws-cdk-lib/aws-kms'; import * as q from 'aws-cdk-lib/aws-qbusiness'; Figure 7 import CDK libraries in amplify/backend.ts 次に、 backend.createStack() (図 8) メソッドを使用して、カスタムリソースを格納するための新しい CloudFormation スタックの生成をバックエンドに指示します。AWS Amplify Gen 2 では、CDK を使用してカスタムリソースを作成できるため、Amplify ライブラリ以外のサービスを利用でき、スケーラビリティを備えた CloudFormation テンプレートでスタックをバックアップできます。たとえば、Generative AI スタックを作成し、カスタム AWS リソースを追加する前に AI 関連サービスの論理的な構成をすることができます。これでカスタム AWS リソースの定義を開始できます! export const customResource = backend.createStack("CustomResourceStack"); Figure 8 define backend stack for custom resources in amplify/backend.ts CustomResourceStack のデプロイ中に、複数のIAMロール、信頼ポリシー、インラインアクセスポリシーが作成されるのが確認できます。これらはすべて、Amazon Q Businessが安全に機能し、他のAWSサービスと連携するために不可欠なものです。これらには以下が含まれます。 サービスアクセスロール (QApplicationServiceAccessRole) は、Amazon Q Business が CloudWatch を経由してログとメトリクスを出力できるようにするためのロールです。 Web エクスペリエンスロール (QWebExperienceRole と QWebExperienceRole) は、埋め込みアシスタントがフルアプリケーションコンテキストとユーザーインタラクションで動作できるようにするためのロールです。 データソースロール (QBusinessS3Role) は、Amazon Q Business が Amplify ストレージによってプロビジョニングされた S3 バケットからドキュメントを読み取ることを許可するための専用のロールです。 各ロールには、 誰がそのロールを引き受けられるか を定義するトラストポリシーと、特定のアクションとリソースへのアクセス権を付与する詳細なアクセス許可が含まれています。Amazon Q Business データソース向けの必要なポリシー構造の詳細は、 Amazon Q Business コネクタの IAM ロールドキュメント で確認できます。 Amazon Q Business のセットアップ すべての基盤となる IAM ロールとポリシーが整ったところで、埋め込み型生成 AI アシスタントを動かす中核コンポーネントである Amazon Q Business アプリケーションを定義する準備が整いました。 amplify/backend.ts ファイル（図9）で、CDK を使用して、必要な設定、サブスクリプションプラン、IAM 統合を宣言的にインスタンス化できます。 export const qapp = new q.CfnApplication(customResource, "Qapp", { displayName: "Qapp", description: "CDK instantiated Amazon Q Business App", autoSubscriptionConfiguration: { autoSubscribe: "ENABLED", defaultSubscriptionType: "Q_LITE" }, identityType: "AWS_IAM_IDC", roleArn: `arn:aws:iam::${ customResource.account }:role/aws-service-role/qbusiness.amazonaws.com/AWSServiceRoleForQBusiness`, /* REPLACE WITH YOUR IAM IDENTITY CENTER ARN */ // identityCenterInstanceArn: "arn:aws:sso:::instance/", }); Figure 9 defining Q Business Application in amplify/backend.ts このステップでは正式に Amazon Q Business アプリケーションを作成し、サービスリンクロール ( AWSServiceRoleForQBusiness ) と関連付けます。デプロイ前に必ず IAM Identity Center ARN を置き換えて、ユーザーのフェデレーションアクセスを有効にしてください。 インデックスの作成 Amazon Q Business のインデックスは、企業データを効率的に保存、整理、取得するために使用されます。保存されたドキュメントの構造化されたクエリを可能にするためにインデックスが必要であり、これによりチャットボットはユーザークエリに基づいて関連する回答を取得できます。 amplify/backend.ts （図10）の以下の CDK コードは、Amazon Q Business アプリケーション内にインデックスを設定します。 export const qIndex = new q.CfnIndex(customResource, "QIndex", { displayName: "QIndex", description: "CDK instantiated Amazon Q Business App index", applicationId: qapp.attrApplicationId, capacityConfiguration: { units: 1, }, type: "STARTER", }); Figure 10 defining Q Business Index in amplify/backend.ts ここでは、STARTER インデックスタイプが選択されています。これはテストや小規模なデプロイメントに適した基本的な構成です。本番環境での使用には、スケーラビリティ、可用性、高度な機能のサポートを確保するために、 ENTERPRISE などの上位ティアが必要です。詳細は Amazon Q Business の料金とティア のガイダンスを参照してください。 Retriever の作成 Retriever はインデックスから関連ドキュメントを取得することで検索機能を強化します。Amazon Q Business では、Retriever はインデックスに接続し、クエリが意味のある応答を返すことを保証します。 amplify/backend.ts （図11）の次の CDK コードは、Amazon Q Business アプリケーション内に Retriever を設定します： export const qRetriever = new q.CfnRetriever(customResource, "QRetriever", { displayName: "QRetriever", applicationId: qapp.attrApplicationId, type: "NATIVE_INDEX", configuration: { nativeIndexConfiguration: { indexId: qIndex.attrIndexId, }, } }); Figure 11 defining Q Business Retriever in amplify/backend.ts この Retriever は、以前に作成された qIndex と連携するように構成されており、Amazon Q Business のインデックス付きコンテンツを効率的に取得することを保証します。 データソースの定義 データソースは、Amazon Q Business アプリケーションがその知識ベースのためにデータを取得する場所です。この場合、データソースは、以前に Amplify Storage の設定 amplify/storage/resource.ts で定義され、 amplify/backend.ts （図12）ファイルで参照されているAmazon S3バケットです。このバケットには、Amazon Q Businessがインデックスを作成して分析するドキュメントが保存されています。 export const qDataSource = new q.CfnDataSource(customResource, "QDataSource", { displayName: ` ${ backend.storage.resources.bucket.bucketName } `, applicationId: qapp.attrApplicationId, indexId: qIndex.attrIndexId, configuration: { type: "S3", syncMode: "FULL_CRAWL", connectionConfiguration: { repositoryEndpointMetadata: { BucketName: backend.storage.resources.bucket.bucketName } }, repositoryConfigurations: { document: { fieldMappings: [ { indexFieldName: "s3_document_id", indexFieldType: "STRING", dataSourceFieldName: "s3_document_id" } ] } }, }, roleArn: qBusinessS3Role.roleArn }); Figure 12 defining Q Business Data Source in amplify/backend.ts このセットアップの主要要素 syncMode : “FULL_CRAWL” は、S3バケット内のすべてのドキュメントがインデックス化されることを保証します。 フィールドマッピングは、インデックス作成のためのドキュメントメタデータの構造を定義します。 Amazon Q Business Web エクスペリエンスの作成 Amazon Q Businessの Web エクスペリエンスは、ユーザーがカスタマイズされたチャットボットに組み込まれた Amazon Q Business とやり取りできるようにするフロントエンドです。このコンポーネントは amplify/backend.ts （図13）ファイルで定義されており、許可された Web サイトのオリジン、ブランディング、認証を含め、チャットボットインターフェースがどのように表示され機能するかを定義します。 export const qWebExperience = new q.CfnWebExperience(customResource, "QWebExperience", { applicationId: qapp.attrApplicationId, origins: [ /* REPLACE WITH YOUR AMPLIFY DOMAIN URL */ "https://main..amplifyapp.com", ], samplePromptsControlMode: "ENABLED", subtitle: "AnyCompany Generative AI Assistant", title: "AnyCompany Q App", welcomeMessage: "Welcome to your Amazon Q Business Application !", roleArn: qWebExperienceRole.roleArn }); Figure 13 defining Q Business Web Experience in amplify/backend.ts Web エクスペリエンス設定 origins ：チャットボットを<iframe>経由で埋め込むことを許可する Web サイトドメインを指定します。Amplify アプリのデプロイされた URL がここに正しく記載されていることを確認してください。 samplePromptsControlMode ：チャットボット UI 内に事前定義されたサンプルプロンプトを保存できるようにします。 title & subtitle ：チャットボットの表示名と追加の説明を設定します。 welcomeMessage ：ユーザーがチャットウィンドウを開いたときに最初に表示されるメッセージです。 Amazon Q Business とフロントエンドの統合 Web エクスペリエンスを設定した後、iframe を使用して Amazon Q Business Web エクスペリエンスを埋め込む ことができます。 src/components/qframe.tsx （図14）では、src は amplify_outputs.json ファイルから動的に取得されます。このファイルにはバックエンドによってエクスポートされた Q Web エクスペリエンスのデプロイされた URL が含まれています。ユーザーは新しいブラウザタブで認証を求められ、その後チャットセッションは埋め込まれた iframe 内で続行されます。 import React from 'react'; import rawOutputs from '../../amplify_outputs.json'; const outputs = rawOutputs as unknown as { custom: { q_business_url: string ; }; }; const QFrame: React.FC = () => { const qBusinessDeployedURL = outputs.custom.q_business_url ; return ( ); }; export default QFrame ; Figure 14 Embeds Amazon Q Business via iframe using config URL. アプリの実行 ステップ1：Amplifyは各開発者に個人用の クラウドサンドボックス環境 を提供し、迅速な構築、テスト、反復のための隔離された開発スペースを提供します。クラウドサンドボックス環境を開始するには、新しいターミナルウィンドウを開き、次のコマンドを実行します。 npx ampx sandbox ステップ2：以下のコマンドを実行して、localhost の開発サーバーを起動します。 npm run dev 前述のコマンドを実行してアプリケーションを起動した後、 Amplify Authenticator コンポーネント の「Create Account」機能を使用し、メールアドレスとパスワードを入力します。確認メールを通じてユーザー設定を完了した後、ログインしてアプリケーションにアクセスします。（図15） Figure 15 Logging in using the Amplify Authenticator component during local development testing. 開発サーバーでアプリを操作した後、ターミナルで Ctrl + C を押してサンドボックス環境を停止します。その後、「 npx ampx sandbox delete 」と入力し、サンドボックス環境のリソースを削除するよう求められたら「 Y 」と入力して確認します。（図16） Figure 16 Deleting all resources in the Amplify sandbox environment バックエンドリソースのデプロイ アプリが期待通りに機能することを確認したら、「 Amplify Hosting へのアプリのデプロイを開始する 」の手順に従ってバックエンドリソースをデプロイします。デプロイのリポジトリとして GitHub が選択されていることを確認してください。 Amplify ドメインエンドポイントの更新 バックエンド CDK コードで、 amplify/backend.ts に移動し、origins フィールドのプレースホルダーを実際の Amplify ドメインに置き換えます。このドメインは、前のセクションで作成したアプリ名の Amplify コンソールで確認できます。（図17） origins: [ "https://main..amplifyapp.com", ], Figure 17 Updating the origins field in the CDK backend code with your Amplify app ’ s deployed domain. サンプルデータのアップロード デプロイしてアプリケーションにサインインした後、Amplify によって生成されたアプリのドメイン URL にアクセスしてサンプルデータをアップロードします。ファイルをアップロードした後、AWS Amplify コンソールのストレージセクション内の public/フォルダを確認してアップロードを確認します。（図18） Figure 18 Uploading sample data in deployed app. Amazon Q Business Web エクスペリエンスへのユーザーアクセスの設定 次に、Qapp では、埋め込まれた Web エクスペリエンスにログインできるユーザーを割り当てる必要があります。このユーザーは、前提条件の間に IAM Identity Center を使用して作成されているはずです。新規または既存のユーザーを追加するには、 Amazon Q Business コンソールで、Qapp を選択し、「User access」セクションに移動して「Manage user access」をクリックし、続いて「Add groups and users」をクリックします。（図19） Figure 19 Assigning user access via IAM Identity Center. ユーザーがすでに存在する場合は、「Assign existing users and groups」を選択し、割り当てたいユーザーを検索します。追加したら、選択を確認して Amazon Q Business Web エクスペリエンスへのアクセスを許可します。（図20） Figure 20 Granting access to existing IAM Identity Center users. S3データをQ Businessインデックスに同期する サンプルドキュメントをアップロードした後、Amazon S3 バケットを Amazon Q Business インデックスと同期して、データを保存および取得します。 Amazon Q Business コンソールから、「Data Sources」に移動し、「amplify-your-unique-bucket-name」を選択します。次に、「Sync now」を選択します（図21）。 Figure 21 Syncing uploaded S3 data to Q Business index. データソースの同期が完了し、最後の同期ステータスが「Completed」と表示されたら、Amazon Q Business Web エクスペリエンスの使用を開始する準備がほぼ整いました。続行する前に、サインインしていることを確認してください。サインインが成功すると、「サインイン完了」というメッセージが表示されます。その時点でアプリケーションに戻ることができます—認証が完了しました。（図22） Figure 22 Confirming sign-in completion for authentication. サインインしたので、アプリケーションを通じて Amazon Q Business Web エクスペリエンスに直接クエリを開始できます！（図23） Figure 23 Querying Amazon Q Business in your application. クリーンアップ AWS Identity Center コンソール インスタンスを削除するには、「Settings」に移動し、「Management」タブを開きます。「Delete IAM Identity Center Instance」セクションで、「Delete」を選択してインスタンスを削除します。 最後に、 AWS Amplify コンソール 内で、このブログに従って作成したアプリケーションの「View App」を選択します。次に、「App Settings」を選択し、「General Settings」を選択します。最後に、「Delete App」を選択して、アプリケーションと関連するバックエンドリソースを削除します。なお、Amplify はプロジェクトの一部として作成されたすべてのバックエンドリソースを削除します。 まとめ このブログでは、Amazon Q Business をカスタムアプリケーションに統合するための主要なステップについて説明しました。AWS Amplify を使用したフロントエンドのセットアップ、CDK を使用したQ Business アプリケーションの構成、iframe を介したチャットボットの埋め込みです。これらの AWS サービスとツールを活用することで、ユーザーの対話と知識へのアクセシビリティを向上させるAI駆動の検索体験を作成できます。 さあ、あなたの番です！会話型 AI をアプリケーションに埋め込み、Amazon Q Business で新しいレベルの生産性と意思決定を解き放ちましょう。そして、 Amazon Q Developer で開発ワークフローを強化しましょう。生成 AI とクラウドコンピューティングのパワーを活用して、開発を加速し、イノベーションを推進するモダンなアプリケーションを迅速に構築しましょう。 本記事は「 From Build to Embed: Creating and Embedding GenAI Apps with AWS Amplify, CDK, and Amazon Q Business 」翻訳したものです。 Ben-Amin York Jr. Ben-Amin は、フロントエンド Web およびモバイル技術を専門とする AWS ソリューションアーキテクトで、自動車および製造業企業のデジタルトランスフォーメーションを支援しています。 Dianne Eldridge Dianne Eldridge は、AWS で産業用 AI のグローバルビジネス開発をリードし、2021 年以降の戦略と成長を推進しています。それ以前は、エマーソンで 20 年間、米国、中国、イタリアにわたるグローバル製造ポートフォリオを監督していました。 Vaidehi Patel Vaidehi Patel は、AWS のソリューションアーキテクトで、自動車および製造業企業をサポートしています。彼女はサーバーレスと Amazon Connect を専門とし、顧客がイノベーションとデジタルトランスフォーメーションを推進するための AI/ML および生成 AI ワークロードの設計とスケーリングを支援しています。 Dexter Pham Dexter Pham は、AWS のソリューションアーキテクトで、自動車および製造業セクターの企業顧客がビジネスおよび技術目標を実現するのをサポートしています。彼はインフラストラクチャ、データ、AI/ML をカバーするクラウドジャーニーで顧客をサポートし、VMware および SAP ワークロードを専門としています

Part 1 では、生成 AI がスマート製品にもたらす価値と、顧客体験を向上する事例について、 AWS Summit Japan 2025 で展示する e-Bike デモのユースケースを元にご紹介しました。このブログ Part 2 ではソフトウェア開発ライフサイクル (SDLC) の複数フェーズに生成 AI を活用し得た洞察をお伝えします。 Part 1 で紹介したデモの開発に当たり、私たちは調査・設計・開発等に生成 AI をフル活用し、 Amazon Q Developer や Amazon Bedrock に 99% 以上のコードを生成させました。 スマート製品の開発における課題 スマート製品とサービスの開発においては、製品開発サイクルの短縮、顧客ニーズへの迅速な対応、そして継続的な製品改善が求められ、開発者やプロダクトマネージャーは多くの課題に直面しています。特に、ハードウェアとソフトウェアの融合によるスマート製品の開発では、複雑な技術統合と顧客体験の最適化が求められます。 スマート製品開発における SDLC 特有の課題 スマート製品の提供企業はソフトウェアの割合を増やし、その開発スピードや生産性を高めることが必要ですが、このためには、製品開発ライフサイクル全体を強化し、組織のアジリティを向上させる必要があります。スマート製品ではハードウェア製品とサービスを同時に取り扱うため開発プロセスが異なる両者を融合しながらアジリティを高めるのはより困難な課題です。 これらの課題に対応するためには、ハードウェアや属人性の高い開発プロセスから脱却し、開発者の生産性を最大化するソリューションが必要です。これまで、私たちは活用した組み込みソフトウェア開発の課題をクラウドで解決する方法について提案してきました（ https://aws.amazon.com/jp/blogs/news/embedded-software-on-aws/ ）。 生成 AI の出現は、さらにソフトウェア開発に共通の開発タスクや、組み込み固有のコーディングスタイルの準拠といった要件にも対応し、スマート製品開発の課題をさらに広く解決することができます。 製品開発ライフサイクルにおける生成AI活用の新しいパラダイム 一般的に、ソフトウェア開発のライフサイクル (SDLC) は、以下のようなフローで行われます。 図: ソフトウェア開発ライフサイクルの例 Research（調査）: ビジネス価値調査、UI(User Interface) Mock 作成、機能要件調査 Plan（計画）: 要件定義、仕様書作成、手順書作成、サブタスク分解、設計図作成 Development（開発）: コーディング、テスト、修正、リファクタリング Release（リリース）: デプロイ計画、IaC(Infrastructure as Code) 、継続的デプロイメント、マルチ環境対応 Operation（運用）: 監視、調査・分析、復旧対応、可観測性 ソフトウェア開発ライフサイクルを加速するための２つのポイント：タスクの効率化と、協調開発プロセス SDLC に生成 AIを導入し開発プロセスを加速するためには、1) 個々のタスクの効率化と自動化 2) 計画的・段階的に開発を進めるための AI と協調した開発手法 の２つの側面から考える必要があります。 製品開発におけるタスクの効率化と自動化 SDLC 内のタスクには様々なものがあり、上流においては企画のための調査やプロトタイピング、アーキテクチャの検討や設計や文書化、コーディングやテストなど多岐にわたります。今回、生成 AI を効率化に活用した様々なタスクを、SDLC 各フェーズでの実践的活用事例セクションに記載しました。 生成 AI を活用した人間と AI の協調モデル 生成 AI を使った開発でも、事前に作成した完璧な仕様書から一気にコードが出力される、といったものではありません。 実際の開発では、仕様は徐々に固まり、作業は段階的に行われていきます。また、生成 AI の特徴として、大規模なプロジェクトでは、生成 AI が一度に読み込める情報（トークン）量の限界があります。現在人と AI エージェントが対話している内容は記憶されていますが、エージェントを再起動したり、複数のエージェントを活用する場合には履歴に頼ることはできません。 したがって、人間同士の開発と同じように、たとえば要件を基に設計方針、設計、仕様といった形にフェーズに合わせた粒度の文書を作成し、検討結果を記録し固定化します。その過程で、たとえば、変動してはならない API 層の定義や、データフォーマット等の仕様なども追加されていきます。こうした文書の内容を生成 AI に提案させ、それを人間がレビューや修正を行ってプロジェクトの成果物として保存していきます。 時間軸においても、すべての開発を一気に行うのではなく、全体をいくつかのマイルストーンに分けてそれぞれの目標を設定し、段階的に作業を進めることで、スケジュールや要件を守り、時には前の状態にプロジェクトを戻しながら開発していくことができます。生成 AI の能力はここでも発揮され、マイルストーンに向けたタスクの細分化や順序を提案してくれます。タスクレベルに分割された作業は、チケット管理システムと連携することによって、生成 AI 自身がその進捗を逐次報告することができます。 上記はいずれも人間同士の開発でも行われている方法であり、生成 AI でも同じような方法の実践により分担・分割して開発を進めることが必要になります。 人間と生成 AI による協調開発の実践：1. 生成 AI からの提案と、ドキュメントに基づく同意 デモアプリケーションの仕様策定では、Amazon Q Developer の支援を受けて 要件設計書・機能設計書の作成を効率化しました。特筆すべきは、曖昧な指示に対してもコンテキストを適切に理解し、e-Bike に特化した詳細な仕様を提案できる点です。 開発者は提案内容を確認しながら、 不明点について深掘りした質問を行う 不要な仕様の削除を依頼する 新しいアイデアについてブレインストーミングを行う といった対話的なプロセスを通じて、仕様を確実に固めていくことができました。 人間と生成AIによる協調開発の実践：2. チケットベース開発への移行 デモ開発においては、開発規模の拡大に応じてチケット管理システム (Issue Tracking System) を導入し、生成 AI への指示と生成 AI からの報告をチケットで管理しました。これは現在の AI コーディングエージェントの課題に対する一つのソリューションです。 近年 AI コーディングエージェントは自然言語による対話によって高度なアプリケーション開発を実現しますが、規模が大きくなるにつれ、対応が困難になっていきます。これはあたかも優秀な一人の開発者がチームによる大規模開発で必ずしも成果を発揮できないことに似ています。タスクを分割してチケットによりアサインすることで、複数エージェントを混乱なく活用し更に生産性を上げることも可能になりました。 図: チケット管理システムを介した新しいワークフロー 人間と生成AIの役割 人間と生成 AI による協調開発を進めると、人間と生成 AI の適切な役割分担のモデルが生まれます。私達の経験から、この概念は複数の人間による開発の場合と大きな違いはないと考えられます。生成 AI が開発のタスクを担うことで、これまで開発者だった人間がリーダーとしてチーム開発を行う姿に移行していくと考えられます。 人間の役割 ： 創造的な目標設定とビジネス判断 優先度決定と戦略的方向性の管理 成果物の品質確認と最終承認 Amazon Q Developerの役割 ： 反復的なコーディングとテスト実行 ドキュメント作成と分析作業 技術的な実装と問題解決 図: 人間と AI による協調開発の流れ SDLC 各フェーズでの実践的活用事例 また、SDLC の各フェーズにおいて、下記のような様々なタスクを生成 AI によって効率化しました。 リサーチフェーズでの活用: 市場調査 ： 製品企画段階では、市場動向、競合分析、顧客ニーズの把握が不可欠ですが、従来は多くの時間とリソースを要するタスクです。今回、「 Bedrock Tool-use Reporter 」を活用し Web の情報収集から、「市場規模、成長予測、競合状況、調査」を行うことで、AI 分析機能が提案するビジネス改善内容が説得力をもてるようになりました。 図: デモにおける Bedrock T00l-use Report を用いた市場調査報告の活用 組み込みアプリケーションのプロトタイピング ： HMI の GUI デザインにおいて、Amazon Q Developer を活用して HTML ベースでイメージを生成し、デモの具体的なビジョンを構築しました。詳細な指示によるイメージの微調整が可能で、最終的には組み込み機器上で動作する Qt (クロスプラットフォームのアプリケーション開発フレームワーク) ベースの実装へと変換することができました。 組み込みアプリケーションの仮想化アーキテクチャ検討 ：開発効率化のために、組み込みアプリケーションを実機と仮想環境の両方で動かすことが必要です。私たちはこれを実現するアーキテクチャを Amazon Q Developer に提案させました。 図: Amazon Q Developer が提案した組込ハードウェアとAWSの間で可搬性のあるアーキテクチャ Web アプリケーションプロトタイピング ：サービスダッシュボードアプリの企画・プロトタイピングにおいても、Amazon Q Developer は、自然言語での要求を理解し、曖昧な要求から、UI が実際に動くダッシュボードを迅速に生成し、早期にイメージを共有して進めることができました。 計画フェーズでの活用: 仕様策定 : モックやユーザーストーリーなどの断片的な情報をもとに、ソフトウェアとして必要な仕様を Amazon Q Developer はベストプラクティスをもとに策定しました。我々はそれをレビューし、さらなる追加要件を加えたり、設計の改善を指示することで仕様を確定していきました。 この過程においては前述のチケット管理システムによる協調作業が大きく役立ちました。 開発・リリースフェーズでの活用: テストコードの生成と不具合調査 : Amazon Q Developer はテストコードを生成したりコードレビューを行う機能を持ちます。さらに画像を認識する機能をもつため、フロントエンドアプリケーションの不具合を画像のキャプチャから理解し原因を調査することができ、不具合の改修に役立ちました。 デバッガーの使用: 組み込みアプリケーションの不具合解決にはデバッガの利用が不可欠ですが、GDB や LLDB といったデバッガへのインターフェイスを Amazon Q Developer CLI で実現できたことにより、従来、開発者が手動でコマンドを入力しながら進めていたデバッグ作業が大きく効率化され、専門的なスキルが不足している開発者でも、効率的なデバッグ作業を行えるようになりました。 Webアプリケーション多言語対応: グローバル展開を見据えた多言語対応において、Amazon Q Developerの威力を実感し、メッセージやデータベースの使い分けなどの7ヶ国語対応をわずか2日で実装完了しました。 運用フェーズでの活用: AI 分析機能評価用データ生成の効率化 : 開発したデモはサービス運用そのものの AI 活用可能性を示しています。AI を活用することで、多数の要因から改善策を立案する仕組みは ブログ Part 1 をご覧ください。 クラウド連携するデバイスのトラブルシューティング : スマートプロダクト開発では、デバイスと AWS クラウドの連携時の問題解決が課題でした。 Amazon CloudWatch は強力な監視ツールですが、複雑な操作が必要でした。これに対し Amazon Q Developer は自然言語での指示を解釈し、適切な CloudWatch クエリを自動生成を行います。デバイス開発者でも容易にクラウド側の問題分析が可能となり、トラブルシューティングの効率化と運用コストの削減を実現しました。 プロジェクトの成果 こうして開発したプロジェクトで、私たちは以下の成果を得ました。 デモシステムのアーキテクチャ（クラウド部分 ＆デバイス）を設計 図: Amazon Q Developer の提案により開発したシステムのアーキテクチャ (上: e-Bike サービスダッシュボード、下: e-Bike プロダクトデモ ) デバイスソフトウェアを含むアプリケーションの企画開発の効率化 調査やプロトタイピングによる企画段階の加速 クロスプラットフォーム対応の HMI アプリケーションを開発 AI 分析機能を搭載したフリート管理の Web アプリケーションを開発 ローカル PC 開発からリファクタリングを重ねながら段階的に AWS 上へデプロイ デバッグやトラブルシュートといった専門知識を要する業務を自然言語の指示により簡略化 Amazon Q Developer で行った定量的な開発効果 50K Line 以上の Web アプリケーション(フリート管理アプリ)を ２ 名で開発 チケット管理システムで、400 件以上の Issue を Amazon Qとの協調作業で完了 1 週間ごとの開発リリースサイクルを実現 ダッシュボードの多言語対応（７カ国語）を２日で実装 まとめ このように、私たちは SDLC 全フェーズにおいて生成 AI を活用し、各タスクを効率化するとともに、生成 AI を活用した協調開発における知見を得ることができました。 体験機会のご案内 スマート製品の開発に興味をお持ちの方は、 AWS Summit Japan 2025（6月 25-26 日、幕張メッセ） の 製造ブース にて、実際の e-Bike デモをご覧いただけます。 今後も、生成 AI を活用したスマート製品開発の可能性を探求し、製造業のデジタル変革を支援してまいります。AWS のサービスを活用したスマート製品ソリューションにご興味のある方は、ぜひ お問い合わせ ください。 このブログは AWS Japan のソリューションアーキテクト 吉川 晃平、村松 謙、山本 直志が共同で執筆しました。ソリューションデモは執筆者たちと西田 光彦、中西 貴大が開発しました。

こんにちは！ソリューションアーキテクトの中西です。 AWS Summit Japan 2025 で展示予定の「IoT ミニ四駆よ！ シリコンバレーの風を切れ」は、懐かしのミニ四駆に IoT 技術と AI を組み合わせ、製造業への転用可能性も秘めたデモとなっています。 図1: IoT ミニ四駆がサーキットを走行し、リアルタイムでテレメトリデータが可視化される様子 このデモでは、リアルタイムデータ収集、AI による自律制御、予知保全といった技術要素を、誰もが親しみやすいミニ四駆で体験いただけます。楽しさの中に本格的な産業技術の可能性を発見していただける内容となっています。 デモで体験できること このデモでは、製造業の DX を支える 3 つの技術を体験いただけます。 図2: IoT ミニ四駆デモの AWS アーキテクチャ構成 1. リアルタイム可視化 ミニ四駆に搭載されたセンサーから、バッテリー電圧、モーター温度、速度、加速度などのテレメトリデータを AWS IoT Core 経由でリアルタイム収集し、 Amazon Timestream に蓄積します。収集されたデータは Web ダッシュボードで可視化され、まるで F1 マシンのように走行中のミニ四駆の状態が一目で把握できます。 2. AI エージェントによる分析・実況 Amazon Bedrock を活用した AI エージェントが、Amazon Timestream に蓄積されたデータを AWS Lambda 経由で分析し、レースの実況解説を行います。「モーター温度上昇中！限界走行だ！」といった熱い実況から、「バッテリー残量から判断して省エネモードに切り替えます」といった冷静な分析まで、AI が多角的にレース状況を解説します。 3. AI による自律制御 最も注目すべきは、クラウド上の AI エージェントによる自律制御機能です。ミニ四駆自体は判断を行わず、センサーデータを AWS IoT Core に送信し、クラウドからのスロットル制御指令を受け取るだけのシンプルな構成です。一方、クラウド側では Amazon Bedrock の AI エージェントが AWS Lambda 上で動作し、収集されたテレメトリデータを総合的に分析して状況を自律的に判断、最適な制御指令を AWS IoT Core 経由でミニ四駆に送信します。 図3: 本展示のために製作された IoT ミニ四駆 AI エージェントの個性豊かな制御 このデモの特徴的な点は、それぞれのミニ四駆を制御する AI エージェントが異なる「個性」を持っていることです。陽気なギャル系、熱血漢、上品なお嬢様、忠実な執事といった多様なキャラクターの AI エージェントが登場します。 図4: テレメトリのリアルタイム可視化ダッシュボードと AI によるインサイトが流れるチャット画面 これらの AI エージェントは、ミニ四駆から送信される同じテレメトリデータを受け取っても、それぞれの「性格」に応じて異なる判断を下し、個別の制御指令をミニ四駆に送信します。ミニ四駆は単純にその指令に従うだけですが、観客の皆様は AI の多様性と意思決定プロセスを楽しみながら体験できます。 製造業への応用可能性 予知保全 「温度限界チャレンジ」では、意図的にモーター温度を上昇させ、危険レベルに達した瞬間に AI が自動停止を実行します。これは製造現場での設備保護と予知保全の実際の動作を、目で見て体験できる貴重な機会です。 故障診断の自動化 「AI トラブル診断」では、意図的に異常状態を作り出し、AI がテレメトリデータから異常を特定・診断します。横転、スタック、追突など様々なトラブルを AI が瞬時に判断し、適切な対処法を提示します。 データドリブンな自律制御 AI エージェントは 1 分毎にミニ四駆から送信されるテレメトリデータを分析し、比較的曖昧なプロンプトからでも状況を理解して、「全力アタックモード」「省エネモード」「安定走行モード」など、AI が最適と思う制御指令を自律的に生成・送信します。 このデモでは、AWS IoT Core、Amazon Bedrock、AWS Lambda、Amazon Timestream、 Amazon API Gateway といった AWS サービスが連携して動作しており、ミニ四駆という親しみやすい素材を通じて、複雑な産業技術を直感的に理解できるよう設計されています。 AWS Summit Japan 2025 でぜひ体験を！ このデモの真の価値は、「楽しさ」を入り口として、本格的な産業技術を体験できることにあります。ミニ四駆という親しみやすい素材を通じて、IoT、AI、リアルタイムデータ処理といった最新技術の可能性を実感していただけます。 AWS Summit Japan 2025 （6 月 26 日）の AWS Builders’ Fair で、実際にリアルタイムでデータが可視化される様子、そして AI が自律的に判断を下してミニ四駆を制御する瞬間を、ぜひその目でご確認ください。製造業の DX、IoT の活用、AI による自律制御に興味をお持ちの方はもちろん、単純にミニ四駆が好きな方も楽しめる内容となっています。 イベント後には、より詳細な技術解説ブログも予定しており、実装の詳細や応用事例についてもご紹介する予定です。会場でお待ちしております！ なお本展示の他にも 製造業のお客様向け展示 がございます。関連ブログをいくつかご案内します。 AWS Summit Japan 2025 製造業ハイライト展示の見どころ紹介！ | Amazon Web Services ブログ AWS Summit Japan 2025 ブース紹介 スマート工場で実現するオペレーションの最適化 | Amazon Web Services ブログ AWS Summit Japan 2025 ~ 生成 AI とグラフデータを活用した 業務横断データ活用（Digital Thread）の展示のご紹介 | Amazon Web Services ブログ イベント情報 イベント名 : AWS Summit Japan 2025 日程 : 2025 年 6 月 26 日（Day 2） 場所 : AWS Expo の AWS Builders’ Fair 内。詳細は こちら 。 デモ名 : IoT ミニ四駆よ！ シリコンバレーの風を切れ ブースID : B-082A 皆さまのご来場を心よりお待ちしております。 著者紹介 中西 貴大 (Takahiro Nakanishi) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな AWS サービスは AWS IoT Core です。機械も含めてものづくり全般が好きで、自分と同い年の愛車を整備したり、 製造業の設計開発領域での AI 活用 – 「身体性」の原理から考える というブログを書いていたりします。 松本 修一 (Shuichi Matsumoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。趣味はオンラインゲームで、日々インターネットの向こうにいる仲間たちと冒険に出かけています。 西亀 真之 (Saneyuki Nishigame) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな領域は IoT とロボットです。趣味はボルダリングでオフィスにあるボルダリングウォールにトライしています。

こんにちは。ソリューションアーキテクトの松本侑也です。普段はパブリックセクター技術統括本部で自治体のお客様の技術支援を担当しています。 2025 年 6 月 17 日に「自治体事業者向け AWS ガバメントクラウドワークショップ 2025 in 東京」を開催しました。このイベントは、ガバメントクラウドへの標準化対象業務システムの移行を進める上で必要となる技術について深く学び (Dive Deep)、実践的なワークショップを通じて技術スキルを高め、さらに参加者同士の交流 (Have Fun) を目的として開催されました。本ブログでは、イベント内容を簡単にご紹介しつつ、当日のセッションやワークショップの様子を共有いたします。 また、同日に中央省庁向けガバメントクラウドワークショップ、夜には Gov-JAWS 第2回 も開催され、約 140 人が参加する大規模なイベントになりました。 イベント概要 「AWS ガバメントクラウドワークショップ 2025」を以下のような形で実施しました。 日時 : 2025 年 6 月 17 日 (火) 13:00-18:30 (懇親会 + Gov JAWS: 18:30-21:00) 場所 : アマゾン ウェブ サービス ジャパン合同会社 目黒オフィス 参加対象 : 運用管理補助者、ASP、自治体向けパッケージ開発者の方々、自治体 前半：事例セッション まず前半では、実際の導入事例に基づいた2つのセッションを実施しました。 生成 AI によるガバメントクラウド運用管理補助業務の効率化 – ネットワーク運用管理補助における生成 AI の具体的な活用例 標準準拠システムのモダナイズとコスト最適化 – 健康管理システムのクラウド移行とアーキテクチャ刷新の実例 後半：テーマ別ワークショップ 後半は、参加者が以下の4つのワークショップから自身の関心や課題に合わせて選択できる形式を採用しました。 ワークショップ名 主な内容 耐障害性・可用性設計ワークショップ 障害耐性評価と復旧プロセスの体験 ガバメントクラウド IaC、CI/CD ワークショップ マルチアカウント環境での CDK デプロイ自動化 ⽣成 AI による開発・運用効率化ワークショップ 生成 AI による業務効率化と開発支援の実践 セキュリティインシデント疑似体験 GameDay セキュリティインシデント対応と調査手法 事例セッションで得た知識をどう実践するのか、具体的に学ぶことができる構成となっていました。 事例セッション – ハイライト 生成 AI によるガバメントクラウド運用管理補助業務の効率化 株式会社大崎コンピュータエンヂニアリング 久保田 亨 氏より、自治体向け標準 20 業務システムを展開する中での生成 AI 活用事例をご紹介いただきました。ガバメントクラウドにおけるネットワーク運用管理補助業務を、生成 AI でどのように効率化したかについて、具体的な実装事例をお話しいただきました。 特に印象的だったのは、セキュリティアラート分析の自動化や複雑なログ解析を生成 AI により効率化した事例です。また、生成 AI を導入する際の地方自治体との調整内容など、実務的な知見も共有いただきました。参加者からは「具体的な適用シナリオがイメージしやすくなった」という声が聞かれました。 詳細については、以下のブログ記事もご参照ください。 【寄稿】生成 AI 活用によるガバメントクラウド環境運用管理補助業務の効率化 | Amazon Web Services ブログ 標準準拠システムのモダナイズとコスト最適化 日本コンピューター株式会社 嶋田 忠相 氏より、標準化業務である健康管理システム「WEL-MOTHER」のモダナイゼーション事例についてご講演いただきました。クラウド移行による具体的なメリットとして、コスト改善や AWS CDK を用いたインフラ構築作業の効率化について詳しくご説明いただきました。 実際のアーキテクチャ図を用いた説明は、参加者にとって非常に参考になったようです。特に、従来のオンプレミスシステムからクラウドへの移行における考慮点や、ガバメントクラウドならではの要件対応について、具体的な手法が示されました。 テーマ別ワークショップ 耐障害性・可用性設計ワークショップ このワークショップでは、AWS における障害への備え方やサービス継続性の考え方を学びました。座学では「レジリエンス (障害への耐性) 」の基本的な考え方や、コストとのバランス、障害時に備えた設計パターン (バックアップ・ウォームスタンバイ・マルチサイト構成など) を体系的に整理しました。 また、演習パートでは 各自に割り当てられた AWS アカウントの中で AWS Fault Injection Service を使用してアプリケーションに対して疑似的な障害を発生させ、リアルタイムで対応するという緊張感のあるシナリオを体験しました。復旧手順や設定の確認を通して、「設計段階からどう備えておくべきか」を身をもって体感できる内容でした。 ガバメントクラウド IaC、CI/CD ワークショップ 本ワークショップでは、Infrastructure as Code (IaC)や CI/CD を活用した、AWS のガバメントクラウド環境における開発・運用の効率化について学びました。ハンズオンでは、 AWS Code サービス群 や AWS CDK を用いた実践的な環境構築をするハンズオンを行いました。 特に、ガバメントクラウドなどで採用が進む構成を題材に、インフラとアプリケーションの責務分離、設定の一元管理の重要性、さらには Amazon RDS のようなリソースにおけるライフサイクル管理のベストプラクティスなど、実運用を見据えた設計上の注意点についても講義形式で解説しました。 参加者の多くが AWS Code サービス群 や AWS CDK の基本的な概念をすでに理解されていたため、講義ではそうした概要説明は最小限にとどめ、より実践的な構成管理の課題や改善に焦点を当てました。 信頼性が求められる自治体システムを例に、IaC による環境の一貫性確保や、セキュリティ・運用性の両立を意識した設計思想について、具体的な事例を通じて理解を深めることができました。 ⽣成 AI による開発・運用効率化ワークショップ 生成 AI の活用に関するワークショップでは、 Amazon Bedrock や Amazon Q Developer を使った実践的なセッションが行われました。生成 AI の概要解説から始まり、開発や運用業務での活用方法まで幅広くカバーしました。 参加者は Amazon Bedrock を使って、セキュリティアラート分析の自動化やドキュメント生成などの実用的なユースケースを体験するハンズオンを実施しました。特にガバメントクラウド特有の考慮点 (セキュリティやプライバシーへの配慮など) についても解説があり、安全に生成 AI を活用する方法への理解を深めました。 セキュリティインシデント疑似体験 GameDay このワークショップでは、AWS 上の典型的なセキュリティインシデントを想定し、ログ分析による調査手法について学びました。セキュリティイベントを検出してから、ログ調査で原因特定を行う一連の流れを体験しました。 参加者は各チームに分かれ、提供されたログデータから不審なアクティビティを特定し、インシデント対応策を検討するという実践的な演習に取り組みました。この演習は、ログ調査をすることで答えが分かるクイズで得点を競い合い、上位 3 チームに景品を授与するゲーム形式で進めました。 ゲーム形式の演習を通して AWS 環境の典型的なセキュリティインシデントと対策について理解を深めることができる内容となっていました。 Gov-JAWS コミュニティの活動紹介 ワークショップと併せて、 Gov-JAWS の活動も行われました。 Gov-JAWS は、AWS のユーザーコミュニティ「 JAWS-UG 」の支部として、公共分野における AWS 利用に焦点を当てた新しいコミュニティです。政府や自治体が進める公共分野のクラウド利用に関連する知識やノウハウを共有するための場として設立されました。 イベント当日は夜の部として Gov-JAWS 第 2 回 Meet Up が開催され、懇親会と併せて多くの参加者が交流を深めました。参加者からは「多くのベンダーの方々と情報交換ができ、普段なかなか話す機会のない方とも直接意見を交わすことができました。こうした場で顔を合わせることで、関係性がぐっと良くなると感じました。」という声が上がりました。このコミュニティを通じて、今後も公共分野でのクラウド活用に関する情報共有と横のつながりの拡大が期待されています。 まとめ 今回のワークショップでは、ガバメントクラウドにおける技術的な課題解決に焦点を当て、実践的な知識とスキルの習得を目指しました。「セキュリティ」「レジリエンス」「モダナイズ (IaC・CI/CD)」「生成 AI」といった様々な観点から、自治体基幹システムのガバメントクラウドへの移行を進める上で重要なテーマを深掘りすることができました。 参加者からは「実際の業務に活かせる具体的な内容だった」「他の事業者の取り組みを知ることができて参考になった」といった声が多く聞かれ、大変好評でした。 今後も、AWS ではガバメントクラウドの活用を支援するためのイベントや情報提供を継続して実施してまいります。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けております。 ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者について 松本 侑也 アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト。パブリックセクター技術統括本部に所属し、自治体のお客様の技術支援を担当。ガバメントクラウドにおける標準化対象業務システムの移行支援や生成 AI の活用支援に取り組んでいる。

「このシステム、全体像を見せてもらえますか？」この質問に即座に対応できる組織はどれくらいあるでしょうか。 多くの AWS ユーザーが直面している課題の一つが、インフラストラクチャの可視化です。AWS リソースの構築は Infrastructure as Code (IaC) を実現する AWS CloudFormation や AWS CDK などの発展により自動化が進んだ一方で、それらの構成図を作成する工程は依然として人の手に委ねられていることが多いのが現状です。 以下のような課題を抱えているチームは少なくないでしょう： AWS CloudFormation で管理している本番環境の構成図が古いままで、実態と合っていない 開発環境、ステージング環境、本番環境など、複数の環境の構成図を最新に保つのが困難 システム変更の際、アーキテクチャ図の更新まで手が回らない チーム内でアーキテクチャ図の描き方にばらつきがあり、レビューに時間がかかる このような状況は、以下のような問題につながる可能性があります： チーム間のコミュニケーションロスによる開発の遅延 システム変更時の影響範囲の見落とし 新メンバーのオンボーディングの長期化 セキュリティレビューやコンプライアンス監査への対応の複雑化 本記事では、これらの課題に対する新しいアプローチとして、定義されたドキュメントからアーキテクチャ図を生成するツールである Diagram-as-code と AWS が提供する生成 AI サービスである Amazon Bedrock を組み合わせることで、事前定義されたインフラ構成情報から自動的にアーキテクチャ図を生成し、効率的に管理する手法について実践的な例を交えて解説します。 前提：本記事は大規模言語モデル (LLM) の可能性を提示したもので、構成の規模・複雑度が大きい場合は、精度を高める工夫が追加で必要になります。また、 Diagram as code は、一般的にアーキテクチャ図をコードや定義ベースで管理する概念を指す用語としても使われています。しかし本記事では、特に言及がない限り、同概念を実現するYAML形式の定義ファイルからアーキテクチャ図を自動生成できるCLIツールを指す用語として使用します。 アーキテクチャ図生成の自動化 システム開発・運用においてアーキテクチャ図は不可欠です。アーキテクチャ図はシステムの全体像や各コンポーネント間の関係を視覚的に表現し、ステークホルダーのシステム理解を深め、コミュニケーションを円滑化します。しかしながら、アーキテクチャ図の作成と管理には相当な労力がかかり、アーキテクチャ図が存在しないまま進行しているプロジェクトや、更新が滞っており実態と異なるアーキテクチャ図しか存在しないといった状況はよくみられる課題です。 この問題に対し、アーキテクチャ図の自動生成を目指す取り組みは既に存在します。とはいえ、プロジェクトやシステムによって必要な表現や粒度が千差万別であるため、高度で繊細な作業が求められ、「やはり人の手で作成する方が正確で早い」という状況が続いているのが実情です。この現状に共感される方も多いのではないでしょうか。 近年、生成 AI の登場によって、この状況が変わろうとしています。生成 AI の曖昧な要件に対するタスク実行能力や、以前よりも拡大したコンテキストウィンドウを活用することで、構造化されていない文章からの情報抽出や構造化されたテキストへの変換が容易に可能となりました。これにより、アーキテクチャ図作成の自動化における大きな課題だった多様な要件の図への反映作業が簡略化できるようになります。 Diagram-as-code とは 本記事で紹介する Diagram-as-code は、事前に準備された構造化されたテキストベースから自動でアーキテクチャ図を生成するツールです。図の生成にあたって画像編集ソフトウェアや手作業での配置を必要としないため、効率的にアーキテクチャ図を作成・管理することができます。 本ツールの主な特長とユースケースは以下のとおりです： AWS アーキテクチャガイドラインに準拠した、一貫性のある図を簡潔に生成できます ヘッドレスブラウザや GUI に依存せず軽量で、コンテナですぐに始めることができます。これにより CI/CD での活用に親和性があります CloudFormation テンプレートからツールで使用する定義ファイル (Dac ファイル) への変換機能が存在するため、IaC を実現している環境でより一貫した図を生成できます CLI ツールとしての提供の他、Golang のライブラリとしても提供されており、例えば import して他の IaC ツール、AI システム、または描画 GUI ツールとの統合が可能です 拡張可能な定義ファイル形式により、AWS サービスに限らず、様々なクラウドプロバイダーやオンプレミスコンポーネントを含むダイアグラムの作成が可能です Diagram-as-code は CloudFormation テンプレートに類似したYAML形式のファイルを入力として、アーキテクチャ図を生成します。以下の図は活用中の CloudFormation テンプレートが存在する場合における Diagram-as-code の利用フローを示しています。 Diagram-as-code を活用すれば、既存の CloudFormation テンプレートからアーキテクチャ図を効率的に生成できます。しかし実際のプロジェクトで活用する段階においては、データフローやセキュリティ境界といった CloudFormation テンプレートに明示されていない要素をアーキテクチャ図に追加する必要が不可欠であり、この部分は依然として手作業による対応が求められます。さらに、目的に応じて表現の粒度や内容を変えたい場合、生成したい図ごとに手動での作業が発生します。そのため、用途の多様化やステークホルダーの増加、図に含まれるシステムの複雑さやリソース数に比例して、下図のように手作業の工数が増大していきます。 このように、IaC からのアーキテクチャ図の生成は、IaC に含まれない要件を反映する作業について効率化の余地が残されていました。 生成 AI によるアーキテクチャ図作成の自動化 Amazon Bedrock を活用した自動化のソリューション設計 この課題に対し、Amazon Bedrock と Diagram-as-code を組み合わせることで、より効率的かつ柔軟なアーキテクチャ図の生成が可能となります。 Amazon Bedrock は、フルマネージド型のサービスで、Anthropic、Cohere、Meta、Mistral AI、Amazon などの最先端の AI 企業が提供する高性能な基盤モデル (Foundation Model) を単一の API で利用できるほか、セキュリティ、プライバシー、責任ある AI に配慮した生成 AI アプリケーションを構築するための幅広い機能を提供します。 Amazon Bedrock を活用することで、本課題に対して以下の機能を実装できます： 要件解釈機能 : ユーザーが自然言語で入力した要件を理解する 構造化出力機能 : 理解した要件を含む構造化されたテキストを生成する 対話的最適化機能 : 生成結果に対するフィードバックを通じて出力したテキストの調整と改善を行う 前項で示した課題に対して Amazon Bedrock を取り入れた活用のフローは以下の通りです。ユーザーの自然言語での入力と CloudFormation テンプレートの情報から Dac ファイルの生成を行う手続きを Amazon Bedrock に任せることで、要件ごとに形式化された情報を手動で追加する作業を大幅に効率化できます。 中間定義ファイルの生成と直接描画手法の比較と考察 近年、マルチモーダル機能を持つモデルの発展により、モデルに対して入力から直接イメージを生成するよう指示する方法も可能になってきています。 入力から直接イメージを生成する方法と、一度中間ファイルを生成した後 Diagram-as-code のようなツールが描画を行う方法を比較した場合、後者には現時点で以下の特徴があります： 正確性と一貫性 定義されたフォーマットに従った出力を描画ツールが保証 コンポーネント間の関係性をドキュメントベースで明確に表現 修正の容易さと柔軟性 コードベースでの差分管理が可能 修正時にコードベースでの厳密な指示をすることも可能 検証とガバナンス イメージを生成する前に、生成された中間ファイルに対する検証が可能 上記特徴は、ツールが引き受ける責任範囲とモデルが引き受ける責任範囲の差分によって生じます。したがって、将来は利用シーンごとに AI エージェントなどがモデルと使用するツールの適切な組み合わせを選ぶ形になると予想されます。例えば開発の初期段階では入力からアーキテクチャ図生成までを全てモデルに指示する方が開発速度向上の観点から好まれるかもしれません。一方、運用のフェーズでは正確性を重視し、中間ファイルから生成する方法が選択されることが多いと予想されます。 なお、AWS Blog 「 Architecture to AWS CloudFormation code using Anthropic’s Claude 3 on Amazon Bedrock 」では、本記事と逆の変換プロセス、つまりアーキテクチャ図から CloudFormation コードを生成する手法を紹介しています。この手法と本記事のアプローチを組み合わせることで、初期段階のラフスケッチから IaC とアーキテクチャ図の双方を効率的に生成し、本番環境への移行をスムーズに実現できます。 具体的な活用例の紹介 本記事後半では、前半で説明したアーキテクチャ図を生成する方法の具体例を示します。このアプローチにより、AWS環境の可視化を自動化し、作業時間を大幅に削減できます。 Step0 前提条件 まずは前提となる活用シチュエーションの設定と解説を行います。 今回対象とするシステムは、以下で掲載されているAWS ソリューションの CloudFormation テンプレート（空白を除き約 2.6 万文字、リソース数 23 個) とします。 Cognito User Profiles Export リファレンスアーキテクチャ Step1 Diagram-as-code のセットアップ はじめに Diagram-as-code  を使用するための準備を行います。以下に示す通り、数ステップを完了することでツールの動作を確認することができます。 まず、以下いずれかの方法で awsdac をインストールします。 # Goを使用してインストール go install github.com/awslabs/diagram-as-code/cmd/awsdac@latest # macOS の場合 brew install awsdac 次に リファレンスアーキテクのチャページ から CloudFormation テンプレートファイルをダウンロードします。ダウンロードしたファイルをターゲットとした以下コマンドを実行すると、中間ファイルと描画結果である png ファイルの両方を作成できます。 awsdac cognito-user-profiles-export-reference-architecture.template --cfn-template --dac-file デフォルトでは一部の親子関係が明確なリソースを除いてアイコン間の関係情報が存在しないため、以下のように多数のリソースが横並びになった結果が表示されます。 中間生成ファイルを修正し、関係情報や位置情報を追加することで、元となる CloudFormation テンプレートでは表現できないリソース間の関係性やグループを表現することは可能です。しかし前述したように、リソースの数や要件の数に比例して作業時間が増大します。 Step2 Amazon Bedrock で利用するプロンプトの準備 効率よくリソース間の関係や要件を補完するため、Amazon Bedrock を活用することを考えます。まずは、モデルに入力するためのプロンプトを作成します。今回は、ユーザーの口語的な表現を Diagram-as-code のフォーマット に従った表現に変換するプロンプトを作成しました。 以下にプロンプトのサンプルを示します。 User: CloudFormation テンプレートとユーザー要件という2つの入力ソースに基づいて、Diagram-as-code の YAML ファイルを生成します。 CloudFormation テンプレートは<cloudformation-template></cloudformation-template>セクションに、ユーザー要件は<user-requirements></user-requirements>セクションに記載されています。 Diagram-as-codeファイル形式はYAML構文を使用し、3つの主要セクションで構成されています。また、<custom-rules></custom-rules>にカスタムルールセクションがあります。 <diagram-as-code-format> {DAC_FORMAT_INTRODUCTION} </diagram-as-code-format> <custom-rules> {CUSTOM_RULES} </custom-rules> <cloudformation-template> {INPUT_CLOUDFORMATION_TEMPLATE} </cloudformation-template> <user-requirements> {INPUT_USER_REQUIREMENTS} </user-requirements> 最終的なYAML出力を生成するには、以下の手順に従ってください: 1. CloudFormationテンプレートを確認し、図に表示する必要のあるAWSリソースの定義を抽出します。 2. ユーザー要件とカスタムルールを確認し、CloudFormationテンプレートに含まれていないシステムアーキテクチャに関する追加のコンテキストや詳細を収集します。 3. 以下の方法でDiagram-as-code YAMLファイルを構築します: - DefinitionFilesセクションでリソース定義ファイルの場所を指定する。 - Diagram-as-code形式に従って、Resourcesセクションでリソースとその関係を定義する。 - Diagram-as-code形式とカスタムルールに従って、Linksセクションでリソース間のリンクを定義する。 4. 最終的なYAML出力が入力ソースに基づいてシステムアーキテクチャを正確に表現していることを確認します。 <example> {INPUT_EXAMPLE} </example> 実際にプロンプトテンプレートを利用する場合、可変値となる部分は変数として定義しています。上記テンプレートに埋め込まれた5つの変数の用途は以下のとおりです。接頭辞として INPUT がついている変数は特に入力毎に変化する値として想定しています。 DAC_FORMAT_INTRODUCTION : ツールのバージョンアップとともに更新されるDiagram-as-code の仕様 CUSTOM_RULES : 美しい図を生成するためのヒント INPUT_CLOUDFORMATION_TEMPLATE : ユーザー入力となる、生成元の CloudFormation テンプレート INPUT_USER_REQUIREMENTS : ユーザーが生成する図の方向性を指示するための要件 INPUT_EXAMPLE : 生成の精度を向上させるためのサンプル。一度生成した図を編集したい場合も活用する Step3 プロンプトを使用したプログラムからの中間ファイルの生成と図の生成 Amazon Bedrock 上の Claude を利用し、文書化された要件から Diagram-as-code で利用可能なフォーマットを生成します。以下は一連の流れを実行するサンプルスクリプトです。 import boto3 import os import subprocess # プロンプトテンプレート prompt_template = """ <Step3 で記述しているため省略> """ # prompt_variables フォルダから入力用の変数を読み込む variables = {} for filename in os.listdir('prompt_variables'): if filename.endswith('.txt'): with open(os.path.join('prompt_variables', filename), 'r') as f: variable_name = os.path.splitext(filename)[0] variables[variable_name] = f.read().strip() # プロンプトテンプレートに変数を挿入 prompt = prompt_template.format( **variables ) # Amazon Bedrock Runtime client を作成 client = boto3.client("bedrock-runtime", region_name="us-east-1") model_id = "us.anthropic.claude-3-7-sonnet-20250219-v1:0" conversation = [ { "role": "user", "content": [{"text": prompt}], } ] # Amazon Bedrock へメッセージを送信 response = client.converse( modelId = model_id, messages = conversation, inferenceConfig={"maxTokens": 8192, "temperature": 0.2, "topP": 0.9}, ) response_text = response["output"]["message"]["content"][0]["text"] # 中間 Dac ファイル保存 yaml_filename = f"output.yaml" with open(yaml_filename, 'w') as f: f.write(response_text) # PNG ファイル生成 png_filename = f"output.png" try: subprocess.run(["awsdac", yaml_filename, "-o", png_filename], check=True) print(f"PNG ファイル生成完了: {png_filename}") except subprocess.CalledProcessError as e: print(f"PNG ファイル生成中にエラーが発生しました: {e}") except FileNotFoundError: print("Error: awsdac コマンドが見つかりません。") python ファイルを配置した場所に prompt_variables フォルダを作成し、以下の各テキストファイルを作成します。今回実行にあたって指定した内容を以下に示します。 DAC_FORMAT_INTRODUCTION.txt Diagram-as-code の Introduction guide に掲載された内容を記述しています。 CUSTOM_RULES.txt 整った画像を表示するためのヒントを記述します。今回記述した指示は以下の通りとなります。 全体に関する指示 - YAML構文に従い、回答に不要な説明や説明文を含めないでください。 - 回答の最初と最後にトリプルバッククォートのYAMLマーカーを含めないでください。 Links に関する指示 - 特に指示がない場合、CloudFormation template に含まれる Resource は全て表示してください。 - Resources の後に Links を出力してください - Links セクションでは、SourcePosition が S の場合、TargetPosition は N が望ましく、その逆も同様です。また、SourcePosition が E の場合、TargetPosition は W が望ましく、その逆も同様です。 - Links セクションの要素は、Resource セクションに存在する Resource 間でのみ接続する必要があり、存在しない Resource を Source もしくは Target に指定することはできません。 - Links セクションの要素には必ず orthogonal プロパティを追加し、Source から Target への方向を明示してください。 - AWS::Diagram::VerticalStackとAWS::Diagram::HorizontalStack はグループ化に使用し描画しないソースであるため、Link の Source と Target に指定しないでください。 - 同じ SourcePosition や TargetPosition を指定する Link が 3 つ以上存在する場合、2文字目に同じ方角を重ねた後、3文字目に違う方角を追加し Link が重なることを避けてください（例: 同じ Resource の同じ Position である N を指定する複数の Link が存在する場合、Position の値を NNE, NNW とすることで描画時の Link の重なりを避けることができます) Resource に関する指示 - 同じ Resource を 複数の Resource の Children プロパティに指定できません。子の親は必ず 1 つです。 - Resource が所属するグループを明示的に指定する場合は、AWS::Diagram::Resource を使用し、その Children プロパティにグループに所属させたい Resource を指定してください。 - 指示がありUserアイコンを表示した方が良い場合には、以下の表記を使用できます： ``` User: Type: AWS::Diagram::Resource Preset: "User" ``` Label に関する指示 - 同じ Resource を Target もしくは Source として指定する複数の Link があり、それぞれに Label がある場合、Label の重なりを防ぐため Label のプロパティに TargetLeftまたはTargetRight を使用してください。 - Resource アイコンの下には Label が付与されるため、SourcePositionがSのLink の Label は TargetLeft か TargetRight のプロパティ使用して配置してください 配置に関する指示 - VerticalStack の Children は西(W)から東(E)に描画されます。HorizontalStack の Children は北(N)から南(S)に描画されます。 - Userからの距離が2より大きい Resource については、HorizontalStackまたはVerticalStackをネストして使用することを積極的に検討してください。これにより Links で Resource を接続した時に、 Links がアイコンと重なる可能性が下がります - Vertical と Horizontal を交互に使ってリソースを配置することで図全体が一方向に長くならないようにしてください。 - 以下の優先度のルールに従って配置してください。優先度は値が小さいものが優先されます。 1. Link は SourcePosition: S と TargetPosition: N で固定してください。ただし、深い階層から浅い階層へフィードバックする Link のみ SourcePosition, TargetPosition に E もしくは W が許可されます。 2. AWSCloud (AWS::Diagram::Cloud) の中で AWS::Diagram::HorizontalStack で hierarchy を作成してください。hierarchy は User から辿れる Link 数です。hierarchy は何個作成しても構いません。 3. Link が交差しないように Children の順序を入れ替えてください。Link(A->D), Link(B->C) ならば VerticalStack(HorizontalStack(A, B), HorizontalStack(D, C)) が Link が交差しない HorizontalStack 内の Children の順序です。前の hierarchy の並び順から Link されている Resource の順序を決定してください。 INPUT_CLOUDFORMATION_TEMPLATE Step 0 で提示した CloudFormation テンプレート を使用します。 INPUT_USER_REQUIREMENTS 以下に示す、ユーザーや状況によって異なる要件を記述します。今回はソリューションのページは閲覧しているが、実際にデプロイされるリソースについては把握していないという状況を想定して記述しました。 - これは ユーザーが認証に使う Amazon Cognito User Pools のユーザー情報をエクスポートして、別のリージョンにバックアップするソリューションです。 - Cognito のユーザー情報がバックアップされまでの道筋を明確にしてほしいです - 各リージョンにどの AWS リソースが所属しているかを明確に示してください - 可能な範囲で役割ごとに関連する AWS リソース群をグループ化してその役割を明示して欲しいですが、AWS リソースの省略はしないでください - IAM と KMS に関する AWS リソース以外は全ての AWS リソースを必ず表示してください INPUT_EXAMPLE.txt 今回の実行時は空白の状態にしています。一度生成したファイルを修正したい時はこちらに記載します。 Step4 実行結果の確認と修正 上記手順を実行した際に生成したアーキテクチャ図の例を複数以下に記載します。 デフォルトで生成された図 はアイコンが横並びでしたが、以下より、配置がグループ化されリソース間の関係が確認できます。指示の通りリージョンの要素が表示され、IAM や KMS の情報は逆に含まれないことなどが確認できることから、ユーザー要件がモデルによって解釈され適切な中間ファイルがモデルによって生成されていることが確認できます。 この後は、生成された中間ファイルを入力とし、追加の要件や修正の指示を与えることで、よりきめ細やかな表現の調整が可能です。 また、より正確性を求める場合、生成された中間ファイルと入力として使用した CloudFormation テンプレートのそれぞれに含まれるリソース情報の差分を YAML 形式で解析して抽出し、図の生成に使用されているリソースと入力に含まれているリソースが一致しているか、意図した通りのリソースの省略が行われているかの確認をスクリプトベースで実現することも可能です。 サマリー 本記事ではアーキテクチャ図の生成管理に関する既存の課題について説明し、生成 AI を活用することで課題を解決し、容易に環境を視覚化する新しいインフラストラクチャ管理の方式を紹介しました。さらに、Diagram-as-code と Amazon Bedrock を組み合わせ、中間ファイルを生成した後にアーキテクチャ図を生成する手順を示しました。 紹介した方法は、直接アーキテクチャ図を生成する代わりに、描画するための情報を含んだ中間ファイルを生成します。これは生成 AI でプロンプトから直接図を生成する方法と比較すると 1 ステップ手間が増える一方、生成した図の微修正の容易さや中間ファイルに対する検証が可能であるというメリットもあります。本記事では Diagram-as-code というツールにて実例を示しましたが、利用シーンごとに別のツールを利用する場合でも同様の構成が実現できます。 本記事を参考に、中間生成したファイルに対する検証チェックの実装や、CI/CD パイプラインへの組み込みなど、要件に応じた応用と発展の例が今後多数出てくることを期待しています。 著者 秋山 周平（ゲームソリューションアーキテクト） 北村 裕汰（クラウドサポートエンジニア）

6 月 17 日、重要な AWS リソースにどの AWS Identity and Access Management (AWS IAM) ロールとユーザーがアクセスしているかをセキュリティチームが検証するために役立つ、 AWS IAM Access Analyzer の新しい機能が発表されました。この新機能は、 Amazon Web Services (AWS) 組織内から付与されたアクセス権を包括的に可視化することで、既存の外部アクセス分析を補完します。 金融サービスやヘルスケアなどの規制対象業界内のセキュリティチームは、クレジットカード情報や医療記録が含まれる Amazon Simple Storage Service (Amazon S3) バケットといった機密データストアへのアクセスを検証する必要があります。これまで、チームは AWS Identity and Access Management (IAM) ポリシーの手動でのレビューに膨大な時間とリソースを費やしたり、内部アクセスパターンを理解するためにパターンマッチングツールを利用したりする必要がありました。 IAM Access Analyzer の新しい内部アクセス検出結果により、AWS 組織内の誰が重要な AWS リソースにアクセスできるのかを特定することができます。この機能は、自動推論を使用してサービスコントロールポリシー (SCP)、リソースコントロールポリシー (RCP)、アイデンティティベースのポリシーを含めた複数のポリシーをまとめて評価し、ユーザーまたはロールが S3 バケット、 Amazon DynamoDB テーブル、または Amazon Relational Database Service (Amazon RDS) スナップショットへのアクセス権を持つときに検出結果を生成します。検出結果は統合ダッシュボードに集約されるので、アクセス権の確認と管理がシンプルになります。 Amazon EventBridge を使用することで、新しい検出結果を開発チームに自動的に通知し、意図しないアクセス権を排除できます。内部アクセスの検出結果は、重要なリソースに対するアクセスコントロールを強化するための可視性をセキュリティチームに提供し、コンプライアンスチームがアクセスコントロール監査要件を実証するために役立ちます。 試してみましょう この新機能の使用を開始するには、 AWS マネジメントコンソール を使用して IAM Access Analyzer が特定のリソースを監視できるようにします。IAM に移動し、左側のナビゲーションメニューにある [アクセスレポート] セクションで [アナライザーの設定] を選択します。ここで、 [アナライザーを作成] を選択します。 [アナライザーを作成] ページで [リソース分析 – 内部アクセス] オプションを選択します。 [アナライザーの詳細] では、アナライザーの名前を好きなようにカスタマイズすることも、自動的に生成された名前を使用することもできます。次に、 [信頼ゾーン] を選択する必要があります。アカウントが AWS 組織の管理アカウントである場合は、組織内のすべてのアカウント全体のリソースを監視するか、現在ログインしているアカウントのリソースを監視するかを選択できます。アカウントが AWS 組織のメンバーアカウント、またはスタンドアロンアカウントの場合は、アカウント内のリソースを監視できます。 信頼ゾーンの選択に応じて、どの IAM ロールとユーザーが分析の対象と見なされるかも決定します。組織を信頼ゾーンとするアナライザーがリソースに対して行われる可能性のあるアクセスについて組織内のすべての IAM ロールとユーザーを評価するのに対し、アカウントを信頼ゾーンとするアナライザーは、そのアカウントの IAM ロールとユーザーのみを評価します。 この最初の例では、アカウントが管理アカウントであると仮定し、組織を信頼ゾーンとするアナライザーを作成します。 次に、分析するリソースを選択する必要があります。 [リソースを追加する] を選択すると、3 つのオプションが表示されます。まず、分析するアカウントとリソースタイプを特定することによってリソースを選択する方法を見てみましょう。 新しいインターフェイスでは、 [アカウントでリソースを追加] ダイアログを使用してリソースタイプを選択できます。ここでは、 [サポートされているすべてのリソースタイプ] を選択して、監視するアカウントを選択します。そうすることで、サポートされているすべてのリソースタイプを監視するアナライザーが作成されます。組織構造からアカウントを選択するか (以下のスクリーンショットを参照)、 [AWS アカウント ID を入力] オプションを使用してアカウント ID を貼り付けることができます。 [特定のリソースタイプを定義] ダイアログを選択することも可能です。これは、サポートされているリソースタイプのリストから選択するために使用できます (以下のスクリーンショットを参照)。この構成でアナライザーを作成すると、IAM Access Analyzer がアカウント内で選択したタイプの既存リソースと新規リソースの両方を継続的に監視し、内部アクセスをチェックします。 選択し終えたら、 [リソースを追加] を選択します。 また、 [リソース ARN でリソースを追加] オプションを使用することもできます。 あるいは、 [CSV ファイルをアップロードしてリソースを追加] オプションを使用して、特定のリソースのリストを大規模に監視するように設定することも可能です。 アナライザーの作成が完了すると、IAM Access Analyzer がポリシーを毎日分析し、組織内の IAM ロールとユーザーに付与されたアクセス権を表示する検出結果を生成します。新しくなった IAM Access Analyzer ダッシュボードでは、リソース中心のビューが提供されるようになりました。 [アクティブな検出結果] セクションでは、アクセスがパブリックアクセス、組織外からの外部アクセス (別の外部アクセスアナライザーを作成する必要があります)、組織内アクセスの 3 つの個別のカテゴリーに要約されています。 [キーリソース] セクションには、3 つのカテゴリー全体の上位リソースがアクティブな検出結果と共に表示されます。左側のナビゲーションメニューで [すべてのアクティブな検出結果を表示] または [リソース分析] を選択すると、分析されたすべてのリソースのリストを確認できます。 [リソース分析] ページでは、分析されたすべてのリソースのリストをフィルタリングして、さらに分析することができます。 特定のリソースを選択すると、利用可能な外部アクセスと内部アクセスの検出結果が [リソースの詳細] ページに一覧表示されます。この機能を使用して、選択したリソースに対して行われる可能性のあるすべてのアクセスを評価します。IAM Access Analyzer は、検出結果ごとに許可された IAM アクションや条件に関する詳しい情報を提供します。これには、該当する SCP と RCP の影響が含まれます。つまり、アクセスが適切に制限されており、最小特権要件を満たしていることをユーザーが検証できるということです。 料金と利用可能なリージョン この新しい IAM Access Analyzer 機能は、今日からすべての商用リージョンでご利用いただけます。 料金 は、監視される重要な AWS リソースの 1 か月あたりの数に基づいています。外部アクセス分析は、今後も追加料金なしで利用可能です。EventBridge については、料金が別途適用されます。 IAM Access Analyzer の詳細を確認し、重要なリソースに対する内部アクセスの分析を開始するには、 IAM Access Analyzer ドキュメント をご覧ください。 原文は こちら です。

6 月 16 日より、 AWS re:Inforce 2025 が開幕します。このイベントでは、セキュリティのプロフェッショナルが一堂に会し、3 日間にわたる技術学習セッション、ワークショップ、デモンストレーションに参加します。セキュリティに特化したこのカンファレンスには、組織がクラウドセキュリティのニーズを満たすために利用するサービスを構築および保守する AWS セキュリティスペシャリストが集まります。 AWS の Chief Information Security Officer (CISO) である Amy Herzog がカンファレンスの 基調講演 を行い、ゲストスピーカーは新しいセキュリティ機能と実装に関するインサイトを共有します。このイベントは、さまざまな技術的役割や専門知識レベルに合わせて設計されたセッションを含む複数の学習パスを提供します。AWS の多くの同僚が、ハンズオンワークショップを主導して、新しいセキュリティ機能のデモンストレーションを行うとともに、コミュニティの議論を促進します。 フィラデルフィアでご参加いただけない方のために、基調講演とイノベーショントークは、 イベントの開催中にライブストリーム で視聴でき、イベント終了後はオンデマンドで視聴できます。カンファレンスでの重要な発表や技術的なインサイトについては、今後の記事でお知らせしますので、どうぞご期待ください! 6 月 9 日週のリリース 私が注目したリリースをご紹介します。 MCP ツールで Amazon Q Developer IDE プラグインを拡張 – Amazon Q Developer は、統合開発環境 (IDE) プラグインで Model Context Protocol (MCP) をサポートするようになりました。これは、デベロッパーがコンテキストを踏まえた開発ワークフローを強化するために、外部ツールを統合するのに役立ちます。stdio トランスポート層をサポートする任意の MCP サーバーを使用して、組み込みツールを拡張できるようになりました。これらのサーバーは、Amazon Q Developer ユーザーインターフェイス内で管理できます。これにより、ツールの許可の追加、削除、変更が容易になります。この統合により、ネイティブツールと MCP サーバーベースのツールの両方でタスクをオーケストレートすることで、よりカスタマイズされた応答が可能になります。MCP サポートは、Visual Studio Code および JetBrains IDE プラグイン、ならびに Amazon Q Developer コマンドラインインターフェイス (CLI) でご利用いただけます。詳細なドキュメントと実装ガイドは、 Amazon Q Developer ドキュメント で入手できます。 AWS WAF が自動アプリケーション層 DDoS 保護のサポートを開始 – AWS は、アプリケーション層 (L7) の分散型サービス拒否 (DDoS) 保護機能を強化し、イベントに数秒以内に応答する高速な自動検出と緩和機能を追加しました。この AWS マネージドルールグループは、あらゆる期間の DDoS 攻撃を自動的に検出して緩和し、Amazon CloudFront、Application Load Balancer、および他の AWS WAF がサポートするサービスで実行されているアプリケーションがユーザーにとって使用可能であり続けるよう維持します。システムは、機械学習 (ML) モデルを使用してアクティベーションから数分以内にベースラインを確立し、トラフィックの異常を検出します。その後、疑わしいリクエストに対処するためのルールを自動的に適用します。設定オプションは、チャレンジの提示やリクエストのブロックなどの応答をカスタマイズするのに役立ちます。この機能は、アジアパシフィック (タイ)、メキシコ (中部)、中国 (北京および寧夏) を除く、サポートされているすべての AWS リージョンにおいて、すべての AWS WAF および AWS Shield Advanced サブスクライバーで使用できます。AWS WAF アプリケーション層 (L7) DDoS 保護の詳細については、 AWS WAF ドキュメント または AWS WAF コンソール にアクセスしてください。 AWS Control Tower がサービスにリンクされた AWS Config マネージド AWS Config ルールのサポートを開始 – AWS Control Tower は、以前の CloudFormation StackSets のデプロイ方法に代えて、サービスにリンクされた AWS Config ルールをマネージドアカウントで直接デプロイするようになりました。この変更により、複数の AWS Control Tower マネージドアカウントとリージョンにわたってサービスにリンクされた AWS Config ルールを有効にする場合のデプロイ速度が向上します。これらのサービスにリンクされたルールは AWS サービスによって完全に管理され、ユーザーが編集または削除することはできません。これは、一貫性を維持し、設定のドリフトを防ぐのに役立ちます。AWS Control Tower Config ルールは、アカウント内のリソースの非準拠を検出し、ダッシュボードを通じてアラートを提供します。これらのコントロールは、 AWS Control Tower コンソール または AWS Control Tower コントロール API を使用してデプロイできます。 Powertools for AWS Lambda に Bedrock Agents Function ユーティリティが導入されました – Powertools for AWS Lambda の新しい Amazon Bedrock Agents Function ユーティリティは、Amazon Bedrock エージェントと統合されたサーバーレスアプリケーションの構築を簡素化します。このユーティリティは、デベロッパーが組み込みのパラメータ挿入と応答フォーマットを使用して Amazon Bedrock エージェントのアクションリクエストに応答する AWS Lambda 関数を作成するのに役立ち、ボイラープレートコードが不要になります。このユーティリティは Logger や Metrics などの他の Powertools 機能とシームレスに統合するため、本番対応の AI アプリケーションをより容易に構築できます。この統合により、AWS Lambda 関数を使用して Amazon Bedrock エージェントによってリクエストされたアクションを処理するエージェントベースのソリューションを構築する際のデベロッパーエクスペリエンスが改善されます。このユーティリティは、Powertools の Python、TypeScript、.NET バージョンで使用できます。 pgactive のオープンソース化を発表: PostgreSQL のアクティブ/アクティブレプリケーション拡張機能 – pgactive は、データベースインスタンス間でデータをストリーミングするための非同期アクティブ/アクティブレプリケーションを可能にする PostgreSQL 拡張機能であり、AWS がオープンソース化しました。この拡張機能は、異なるリージョンにあるライターを含むインスタンス間のデータ移動において、回復力と柔軟性を高めます。これは、書き込みトラフィックの切り替えなどのオペレーション中の可用性の維持に役立ちます。PostgreSQL の論理レプリケーション機能を基盤とする pgactive は、アクティブ/アクティブレプリケーションのシナリオの管理を簡素化する機能を追加します。このオープンソースアプローチは、PostgreSQL のアクティブ/アクティブ機能の開発におけるコラボレーションを促進するとともに、マルチアクティブインスタンス環境での PostgreSQL の使用を効率化する機能を提供します。詳細と実装ガイダンスについては、 GitHub リポジトリ にアクセスしてください。 AWS からのお知らせの詳細なリストについては、「AWS の最新情報」ページを随時ご確認ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました: AWS Glue がアジアパシフィック (台北) リージョンで利用可能に – AWS Glue は、分析、ML、アプリケーション開発のためのデータの検出、準備、結合を簡素化するサーバーレスデータ統合サービスです。 欧州 (アイルランド) で Amazon EC2 I8g インスタンスの提供を開始 – Amazon EC2 I8g インスタンスは、ストレージを多用するワークロードのために、Amazon EC2 で最も優れたパフォーマンスを提供します。 Amazon VPC IP Address Manager がアジアパシフィック (台北) リージョンで利用可能に – Amazon VPC IPAM を利用すると、AWS ワークロードの IP アドレスの計画、追跡、モニタリングがより容易になります。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 コラボレーションスペースであり、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 AWS Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お近くの都市でご登録ください: ミラノ (6 月 18 日)、 上海 (6 月 19 日～20 日)、 ムンバイ (6 月 19 日)、 日本 (6 月 25 日～26 日)。 近日開催予定のすべての AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 6 月 16 日週のニュースは以上です。6 月 23 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

このブログ記事では、コードの保守性を評価するための基準を概説し、 AWS Blu Age がメインフレームアプリケーションを保守可能なオブジェクト指向の Java にどのように変換するか説明します。 AWS Blu Age を利用すると、お客様はメインフレームアプリケーションを Java Spring アプリケーションに変換できます。このトランスフォーメーションは、技術的な問題を解決するだけでなく、ビジネスのトランスフォーメーションも可能にします。新しく着任した開発者が、担当する Java アプリケーションに取り組むことができる状態になっていないと、モダナイゼーションの取り組みは行き詰まり、モダナイゼーション後の作業の大半がメンテナンスに集中したままになります。 COBOL から Java へのプログラム変換や同様のリファクタリングサービスを調査検討すると、JaBOL のような用語がよく出てきます。JaBOL という用語は COBOL の構造を模倣した Java コードを指し、多くの場合、移行元のコードのロジックが理解されないままの状態であることの表れです。AWS Blu Age は、モデルからモデルへの変換、再利用可能なクラス、非手続き型パターンによって JaBOL を回避するコードを生成し、よりクリーンでモダンで保守しやすい実装を実現しています。 可読性 コードは、明確な命名規則に従って、コードの目的やロジックの説明に関して意味のあるコメントを備えた、読みやすく理解しやすいものでなければなりません。プロジェクト全体で一貫したコーディングスタイルがあれば、開発者の認知負荷が軽減され、コードベースの操作が容易になります。 AWS Blu Age の Transformation Engine は、プロジェクト全体を通して一貫したコーディングスタイルに従い、読みやすくわかりやすいコードを生成します。 AWS Blu Age がモダナイズしたアプリケーションは Java Web アプリケーション (WAR) としてパッケージ化されており、どの Java EE サーバーにもデプロイできます。通常、サーバーは Spring Boot と Angular フレームワーク上に構築された AWS Blu Age ランタイムを組み込んだ Tomcat インスタンスです。 基本的な Java プロジェクトは、以下のように構成されます。 Entities プロジェクト — ビジネスモデルとコンテキスト要素が含まれています。プロジェクト名は通常「-entities」で終わります。これはレガシー COBOL プログラムの INPUT-OUTPUT SECTION (データセット) と DATA DIVISION のモダナイゼーションに相当します。一つのアプリケーションに複数の Entities プロジェクトを含むことができます。 Service プロジェクト — 従来のビジネスロジックのモダナイゼーション要素が含まれています。これは COBOL プログラムの PROCEDURE DIVISION に相当します。一つのアプリケーションに複数の Service プロジェクトを含むことができます。 Utility プロジェクト — 他のプロジェクトで使用される共通のツールやユーティリティが含まれています。 Web プロジェクト — UI があるアプリケーションの場合は、モダナイズされた UI 関連の要素が含まれます。これらの UI 要素は、CICS BMS マップ、IMS MFS コンポーネント、およびその他のメインフレーム UI ソースから取得されます。一つのアプリケーションに複数の Web プロジェクトを作成できます。 各構成要素のトランスフォーメーション前後の対応関係を捉えやすくするために、各 Java クラスは、対応する COBOL プログラムの名前を踏襲しています。リファクタリング中、AWS Blu Age の Transformation Engine は変数と関数にお客様固有の命名規則を適用します。各プロジェクトは Apache Maven をビルドの自動化とプロジェクト管理に活用し、一貫した構造と一元的な依存関係管理を実現しています。 モジュール性 個々のモジュール、クラス、および関数は、それぞれシステムの特定の側面を処理するよう、コードを構成する必要があります。このモジュール型のアプローチにより、システム全体に影響を与えずに個々のコンポーネントを更新でき、コンポーネントの再利用が可能になり、重複が減り、保守性が向上します。 AWS Blu Age は、COBOL のモノリシックな構造とは異なり、オブジェクト指向設計のベストプラクティスに従い、複数のレイヤーに編成されたコードを生成します。その構造は以下のようになります。 COBOL の DATA DIVISION は、複数のエンティティに変換されます (01/77 レベルの COBOL データ構造ごとに 1 つ)。コンテキストクラスが生成され、すべてのエンティティが COBOL の実行ユニットコンテキストの概念を再現する 1 つの Java オブジェクトにグループ化されます。プログラムの呼び出し時にコンテキストを復元する必要が生じた場合は、シリアライズ/逆シリアライズできます。 各プログラムには固有の Configuration クラスがあり、プログラムごとに動作をカスタマイズできます。たとえば、アプリケーション内で、あるプログラムは ASCII データを処理するよう設定し、別のプログラムは EBCDIC データを処理するよう設定することができます。 COBOL の PROCEDURE DIVISION は、Spring 等のモダンなアプリケーションで使用されている DI (Dependency Injection) フレームワークに則り、interface を実装する Service クラスに変換されます。COBOL のパラグラフは、標準的な Java のメソッドになります。 最後に、プログラムの名前を持つクラスが、上述の独立した各クラス間を繋ぎます。このクラスは run メソッドを公開しており、呼び出されると最新バージョンのプログラムが実行されます。 このアーキテクチャでは、同一のデータ構造が 1 つのクラスに統合されるので、コードの重複が減り、メンテナンスが容易になります。 複雑さ コードの複雑さは、主に循環的複雑度とコードの重複によって測定されます。 循環的複雑度 — コード内の独立したパスの数を測定します。一般に、複雑度が低いということは、コードの理解、テスト、および保守に必要な労力が最小限であることを示します。複雑度が高いと、コードにバグが発生しやすくなり、変更が難しくなります。 コードの重複 — 繰り返されるコードは最小限に抑える必要があります。重複していると、変更を複数の場所に反映する必要があるため、メンテナンスの負担が増えます。重複したコードを関数やクラスにリファクタリングすると、保守性が向上します。 モダナイズされたコードは、レガシーシステムの複雑さをいくらか受け継いでいます。とはいえ、モダナイズされたコードの方が COBOL よりも読みやすく、クラスやオブジェクトおよびメソッド等の定義や参照先を辿り易くなっています。これは、メソッドのナビゲーション、インデント、構文がより明解になったことによるものです。たとえば、COBOL の END-IF やドットメカニズム (文の終端にピリオド「.」を書くこと) と比べると、if / else ステートメントには中括弧 { … } が使われます。 AWS Blu Age でリファクタリングしたコードは Java Spring の標準的なコーディングルールすべてに準拠しているため、どんな Java 開発者でもすぐにコードの中身に入って行き、詳しく調べることができます。 複数のレイヤーがあり、それぞれが特定のアーキテクチャレイヤーに焦点を当てている 標準の getter / setter を持つオブジェクト interface と実装を分離する Spring のデザインパターン Fluent API に支えられたフレームワーク 設定情報をプログラムから分離して設定ファイルに外出しすることで、必要なときに設定情報に素早くアクセスして変更することができる。たとえば、設定ファイルに外出しした SQL クエリや、YAML での設定など。 トランスフォーメーション中に、複雑な制御フローアルゴリズムを使用して、各プログラムの動作を把握します。AWS Blu Age ツールチェーンは、コード実行シミュレーションを使用して実行可能なパスを見つけ、モダンなコードで必要になるものだけを処理するようにしています。このプロセスのおかげで、COBOL の「GO TO」構文の動作を維持しつつ、COBOL パラグラフを Java メソッドに変換することで、移行元のプログラム構造を残しています。 進化可能性 コードは、最小限の労力で変更に対応できるように設計する必要があります。コンポーネント間は疎結合にする必要があります。つまり、システムのある部分の変更が他の部分に与える影響を最小限に抑える必要があります。 モダナイゼーション後に改修を実施することで、モダンな言語のすべての機能が利用できるようになり、モダンなアプリケーションですぐに有効化できるようになります。 使用されているエンティティ (COBOL データ構造に由来する) は JSON 互換であるため、Spring の機能とアノテーションを活用して、わずか数分で JSON ペイロードをもつモダンな HTTP エンドポイントとしてプログラムを公開できます。結果として、アプリケーションのソースコードを API ベースのソリューション、メッセージングシステム、その他の最新テクノロジーとシームレスに統合できます。 生成されるコードは一定の Java イディオムで構成され、どのコードも同じコーディングパターンに従います。以下は、簡単に実装できる一般的な変更の例です。 新しい特定の動作をアプリケーション全体に一律実装する必要がある場合 : Spring が AspectJ で提供する アスペクト指向プログラミング (AOP) を使用して、アプリケーション全体に実装します。 データアクセスルーチンが、本番 (実データ) とテスト (スタブデータ) では異なる動作をする必要がある場合 : 生成されたコードが Java の interface を使うので、テスト用の実装を作成し、プロファイル (本番/テスト) に基づいて異なる Bean を使うよう Spring を構成します。 無限ループプログラムを使って IBM MQ メッセージの取得と応答を行っている場合 : メッセージ処理に Spring Integration を使用するようにコードをリファクタリングします。これによって、従来の順次処理に代わって、トラフィックに基づいてメッセージを並行して処理するスケーラブルなリスナーを実現します。 既存のバッチの実行時間を改善する必要がある場合 : 既存のコードを Java Runnable に直接ラップし、Spring の TaskExecutor の概念と Java Future オブジェクトを使用した並列化を追加します。 AWS Blu Age で作成された Java コードは、モダンなコーディングのベストプラクティスに従った、標準的な Java コードです。これにより、他の標準的な Java プロジェクトと同様に、移行後のコードをさらに進化させて複雑さを軽減し、保守性を向上させることができます。 コードレビューと品質保証 SonarQube のような静的解析ツールは、エラー、セキュリティの脆弱性、コーディング標準からの逸脱を検出することにより、コードの品質と保守性を保証します。 AWS Blu Age は、コード品質を判定するための主な指標として、静的コード解析ツールである SonarQube を使用します。SonarQube はコードベースを実行せずにスキャンし、開発プロセスの早い段階でバグ、セキュリティの脆弱性、潜在的なパフォーマンス上の問題を特定します。バグ、テストカバレッジ、コードの複雑さなどの重要な指標にしきい値を設定することで、「品質ゲート」を通じて標準を適用します。 AWS Blu Age における SonarQube の主な機能: コードの重複と保守性の問題に関する洞察を提供します OWASP Top 10 などの標準を使用してセキュリティの脆弱性を検出します 不適切なプラクティスや設計を示す兆候となるようなコードを特定します 特定のプロジェクト要件に合わせてルールとしきい値をカスタマイズできます AWS Blu Age でモダナイズされたコードは、お客様の SonarQube プロファイルを使用して解析しても確実に AAAA 評価を得られるようにし、業界標準を満たす高品質で保守しやすいコードになることを保証します。 ドキュメント化 保守に必要なドキュメントとして、次の 2 種類のものが考えられます。 インラインコメント — 複雑なロジック、アルゴリズム、または自明ではない決定を説明するコメントがコード内に必要不可欠です。コメントは、冗長だったり、自明なコードを説明したりするべきではありません。 外部ドキュメント — API リファレンス、アーキテクチャ図、使用ガイドなどの包括的なドキュメントは、新規開発者がシステムを理解し、効果的に貢献するのに役立ちます。 AWS Blu Age のトランスフォーメーションプロセスでは、元のプログラム内でロジックの説明に記述されているコメントをそのまま引き継ぎ、インラインコメントとしてコード内に残します。 JDK に含まれている Javadoc を使うと、他の開発者が追跡し理解できるような一貫したスタイルのドキュメントを作成できます。Web ベースの HTML ドキュメントを生成することで、開発者はコードベースのドキュメントを簡単に参照および検索できます。AWS Blu Age は、各機能を適切に文書化し、将来の開発やデバッグ作業で理解しやすくするため、コードの保守に役立ちます。 テスト容易性 単体テストで個々のコンポーネントを簡単にテストできるよう、コードを記述する必要があります。そのためには、多くの場合、疎結合で、明確なインターフェースを備えたコードを設計する必要があります。単体テスト、統合テスト、回帰テストを含む包括的なテスト自動化により、コードの変更によってバグが発生しないことが確認できると、メンテナンスが容易になります。 リファクタリングされたコードには、明確なインターフェースがあり、疎結合であるため、単体テストコードの生成が容易になります。JUnit、EvoSuite、JUnit-QuickCheck などのツールは、コードに基づいて単体テストケースを自動的に生成できます。また、JaCoCo などのツールを使用すると、テストの都度コードカバレッジを分析したり、追加のテストケースが必要な領域を特定したりできます。 AWS は、アプリケーションテストを大規模に記録、再生、比較するためのサービスである AWS Mainframe Modernization Application Testing を提供しています。これにより、アプリケーション機能のテスト再生、比較、検証のためのテストワークフローを高度に自動化して作成できます。 まとめ AWS Blu Age はメインフレームアプリケーションの俊敏性を高め、メインフレームのモノリスからアジャイルな マクロサービス へ進化させることができます。すると、お客様はモダンな開発環境を採用できるようになり、生産性が向上し、ブロッカーを排除できます。開発とテストは、機能ごとに独立して柔軟に行えるようになります。その結果、市場投入までの時間が短縮され、変更にかかるコストが削減されます。レガシーテクノロジーに熟練した人材の退職に伴うリスクも軽減されます。AWS Blu Age によって移行したアプリケーションは、マイクロサービスの導入によってモダナイゼーションの次の段階に進むことができ、メインフレームアプリケーションに AI を活用し、AWS クラウドサービスと統合することができるようになります。 AWS Blu Age に関するその他の参考情報: AWS Blu Age 認定: https://bluinsights.aws/certification/ ドキュメンテーション: https://bluinsights.aws/docs/transformation-center-create-a-project/ メインフレーム・モダナイゼーションの お客様事例とその他のソリューション Yann Kindelberger Yann Kindelberger は、アマゾンウェブサービスの Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Arnaud Perrier Arnaud はアマゾンウェブサービスの Senior Software Development Engineer です。Arnaud は、主に AWS Blu Age ツールセットを使用したリファクタリングパターンに関するメインフレーム/ミッドレンジのモダナイゼーション活動 (プリセールス、採用、認定、専門知識) に 15 年以上携わってきました。彼の役割は、お客様のモダナイゼーションジャーニーを支援し、パートナーと広範に連携し、サービスチームやデリバリーチームが高度な技術的課題を解決できるようサポートすることです。 Chiranjeev Mukherjee Chiranjeev は AWS のメインフレームモダナイゼーション担当 Sr. Specialist Solution Architect です。Chiranjeev は、メインフレームで約 20 年間働いており、主に世界中のお客様を対象としたメインフレームのモダナイゼーションイニシアチブにフォーカスしてきました。現在の役職では、メインフレームとレガシーシステムに AWS の価値提案を最大限に活用する方法について、お客様やパートナーに助言しています。 Sylvain Eveillard Sylvain はメインフレームモダナイゼーションにおいて 15 年以上の経験があります。彼はユニークな言語/プラットフォーム（Open VMS / GS21 / Natural-Adabas / 階層型データベースまたはネットワークデータベース）でのプロジェクトや製品設計に関する専門知識を持っています。 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、メインフレームとレガシーのモダナイゼーションを専門としています。Tim は世界中のお客様やパートナーと協力して、メインフレームアプリケーションをトランスフォーメーションするための革新的な戦略を開発しています。Tim はメインフレームモダナイゼーション業界に 7 年以上携わり、Astadia（Amdocs により買収）と IBM に勤務してきました。AWS では、お客様やパートナーがより早く結果を出せるよう支援する、拡張性の高いモダナイゼーション戦略の構築に注力しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

はじめに 2024年、経済産業省は  GENIAC（Generative AI Accelerator Challenge）  を立ち上げました。これは、企業に資金、メンタリング、そして基盤モデル開発のための 大規模なコンピューティングリソース を提供することで生成AIを推進する国家プログラムです。AWSはGENIACの第二期において、一括調達方式のクラウドプロバイダーとして選定されるとともに、個別調達方式でGENIACに参加する事業者からの計算リソース需要にも対応しました。結果として、12の事業者に向けて基盤モデル開発のための計算リソースと、AIアクセラレータークラスタ構築・運用支援を主とする技術支援を提供させていただきました。技術支援という観点では表面的には、各チームに数百のGPU/Trainiumを提供するというシンプルな課題のように見えましたが、実際には 基盤モデル（FM）のトレーニングには、単なるハードウェア以上の要素が必要 でした。 AWSは、 1000以上のアクセラレーターの割り当ては始まりに過ぎない ことを早期から認識していました。真の課題は、信頼性の高いインフラストラクチャ・ソフトウェアスタックの構築、ユーザーへの知識共有、分散トレーニングの障害克服にありました。GENIAC第2サイクルでは、12の顧客が1日で 127台の Amazon EC2 P5インスタンス （NVIDIA H100 TensorCore GPUサーバー）と24台の Amazon EC2 Trn1インスタンス （AWS Trainiumサーバー） をデプロイし、その後の6ヶ月間で、各社複数の大規模モデルがトレーニングされました。 この記事では、その取り組みから得られた重要な教訓を共有します。これらは、大規模な基盤モデルを構築しようとする企業や他の国家イニシアチブに適用できる貴重な知見です。 Cross Functional なエンゲージメントチーム GENIACの取り組みに対してAWSがどういった支援を提供できるかを検討する中で得られた重要な初期の教訓は、複数組織による国家規模のMLイニシアチブを実行するには、AWS内部の多数のチームが協業して支援を提供する必要があるということでした。このため AWSは、アカウントチーム、Specialist SA/BD、サポート担当者、サービスチームを統合した Virtual Team（“v-team”） を設立しました。GENIACに向けたエンゲージメントモデルは、顧客と多層的なAWSチーム構造との緊密なコラボレーションを基盤としています。 顧客（Cx） は通常、ビジネスリード、テクニカルリード、MLまたはプラットフォームエンジニアで構成され、トレーニングワークロードの実行を担当します。 AWS Account Team（ソリューションアーキテクトとアカウントマネージャー） は関係性の管理、ドキュメントの維持、顧客と内部スペシャリストとのコミュニケーションフローを確保します。 World Wide Specialist Organization（WWSO）Frameworksチーム は、このエンゲージメント構造の確立と、プログラム内の技術的エンゲージメントの監督を担当します。彼らは他のステークホルダーとパートナーシップを組み、エンゲージメントをリードし、他のステークホルダーのためのエスカレーションポイントとして機能します。彼らは サービスチーム（Amazon EC2、Amazon S3やAmazon FSx for LustreなどのStorageサービス、Amazon SageMaker HyperPod） と直接連携し、エンゲージメント、エスカレーション（ビジネスおよび技術的）、エンゲージメントフレームワークの正常な動作を確保します。彼らは顧客にトレーニングと推論に関するガイダンスを提供し、他のチームに技術を教育します。WWSO Frameworksチームは GENIACに向けた支援体制で特に設定した役割であるリードソリューションアーキテクト（Lead SA） と密接に連携しました。これらのリードSAは、このエンゲージメントの基盤となる存在です。彼らはFrameworksスペシャリストチームと協力しながら、顧客とアカウントチームと直接連携します。彼らは顧客と直接対話しながら、詳細な技術的議論やトラブルシューティングの際には Frameworks チームの対応者と連携します。この階層構造により、AWSは複雑な基盤モデルトレーニングワークロードにわたって技術的ガイダンスを効果的にスケールさせることができます。 GENIACのもう一つの重要な成功要因は、顧客とAWSメンバー間の堅牢なコミュニケーションチャネルの確立でした。私たちのコミュニケーション戦略の基盤は、GENIAC支援のための専用の 内部Slackチャネル で、AWSアカウントチームとLead SA、Frameworks team が連携します。このチャネルは、リアルタイムのトラブルシューティング、ナレッジ共有、事業者の問題を適切な技術スペシャリストやサービスチームメンバーへの迅速なエスカレーションを可能にしました。これを補完するのが、AWSチームと事業者を橋渡しする 外部Slackチャネル で、参加者が質問をし、洞察を共有し、即時の技術支援を受けられる協力的な環境を作り出しました。この直接的なコミュニケーションラインは、解決時間を大幅に短縮し、参加者間の実践コミュニティを育みました。 私たちは、各顧客のトレーニング実装の詳細（モデルアーキテクチャ、分散トレーニングフレームワーク、関連するソフトウェアコンポーネント）とインフラストラクチャの仕様（インスタンスタイプと数量、ParallelClusterまたはHyperPodデプロイメントのクラスター設定、FSx for LustreやS3などのストレージソリューション）を Tracking Document として文書化しました。こうした文書を用いることで、各事業者のプロジェクトの詳細や、過去のやり取りと、サポートケースの状況等を透過的に把握できました。 この構造化されたコミュニケーションとドキュメントのアプローチにより、私たちは共通の課題を特定し、チーム間でソリューションを共有し、サポートモデルを継続的に改善することができました。詳細な追跡システムは、将来のGENIACサイクルのための貴重な洞察を提供し、顧客のニーズを予測し、基盤モデル開発プロセスにおける潜在的なボトルネックを先行的に対処するのに役立ちました。 リファレンスアーキテクチャ もう一つの重要な洞察は、 基盤モデル開発に特化したリファレンスアーキテクチャの重要性 でした。各事業者が独自のクラスターを一から立ち上げる必要がないよう、AWSは2つの主要なアプローチ AWS ParallelCluster （Self-managed の HPC クラスタ管理ツール）と Amazon SageMaker HyperPod （Managed の回復力のあるクラスターサービス用）のための 事前検証済みリファレンスアーキテクチャ を開発しました。これらのリファレンスアーキテクチャは、ネットワークとストレージからコンテナ実行環境とモニタリングなど、分散学習実行に必要な機能をカバーしています。 これらのリファレンスアーキテクチャは  GitHub レポジトリ（ awsome-distributed-training ） 上で提供され、チームが最小限の工数でデプロイできるようになっています。 このリファレンスアーキテクチャは、Computing、Networking、Storage、Monitoring を、大規模な基盤モデルトレーニングに特化して設計された統合システムにシームレスに組み合わせています。 このレファレンスアーキテクチャはベースインフラストラクチャスタックと、クラスタ本体から構成されます。 ベースインフラストラクチャスタックは CloudFormationテンプレート として利用可能で、最小限の労力デプロイ可能です。このテンプレートは、最適化されたネットワーク設定を持つ専用VPCを自動的に設定し、トレーニングデータ用の高性能なAmazon FSx for Lustre Filesystemを実装します（オプショナルで共有ホームディレクトリ用に FSx for OpenZFS Filesystem を Deploy することも可能です）。また、このインフラストラクチャスタックではパフォーマンスとコスト効率のバランスを取る階層型ストレージアプローチを採用しています。基盤となるのは、トレーニングデータとチェックポイントの長期ストレージを提供するAmazon S3です。トレーニング中のストレージボトルネックを防ぐため、S3バケットは データリポジトリアソシエーション（DRA） を通じてLustreファイルシステムとリンクされています。DRAは、Amazon S3とFSx for Lustre間の自動的で透過的なデータ転送を可能にし、手動コピーなしでS3データへの高性能アクセスを実現します。 オプションのモニタリングインフラストラクチャは、 Amazon Managed Service for PrometheusとAmazon Managed Grafana （または EC2上で実行されるセルフマネージドGrafanaサービス ）を組み合わせて、包括的な可観測性を提供します。GPUメトリクスのDCGM ExporterとネットワークメトリクスのEFA Exporterを統合し、システムの健全性とパフォーマンスのリアルタイムモニタリングを可能にしました。このセットアップにより、GPUの健全性、ネットワークパフォーマンス、トレーニングの進捗を継続的に追跡し、Grafanaダッシュボードを通じて異常の自動アラートを実現します。例えば、 GPU Health Dashboard は、Uncorrectable Remapped Rows、Correctable Remapped Rows、XID Error Codes、Row Remap Failure、Thermal violations、Missing GPUs（Nvidia-SMIから）などの一般的なGPUエラーのメトリクスを提供し、ユーザーがハードウェア障害を可能な限り迅速に特定できるようにします。 詳細なDeployment Guide とワークショップ リファレンスアーキテクチャも、チームが使用方法を知らなければ役に立ちません。GENIACの成功の重要な要素は、 再現可能なデプロイメントガイドとワークショップを通じた知識の共有 でした。 2024年10月3日、AWS JapanとWWSO Frameworksチームは、GENIAC第2サイクル参加者向けの大規模なワークショップを開催し、米国からのFrameworksチームメンバーを招いて、AWSでの基盤モデルトレーニングのベストプラクティスを共有しました。 このイベントには80名以上の参加者を迎え、講義、ハンズオンラボ、グループディスカッションを組み合わせた包括的なプログラムを提供し、CSAT 4.75 という高い評価をいただきました。講義セッションでは、インフラストラクチャの基礎、AWS ParallelCluster、Amazon EKS、Amazon SageMaker HyperPodなどのオーケストレーションオプション、AWSを使用した大規模基盤モデル（FM）の構築とトレーニングに必要なソフトウェアコンポーネントについて説明しました。セッションでは、FM開発における実践的な課題—大規模なコンピューティング要件、スケーラブルなネットワーキング、高スループットストレージを取り上げ、それらを適切なAWSサービスとベストプラクティスにマッピングしました（ 講義セッションのスライドデッキ ）。別のセッションではベストプラクティスに焦点を当て、参加者はPrometheusとGrafanaを使用したパフォーマンスダッシュボードの設定、EFA Trafficのモニタリング、NVIDIAのDCGMツールキットとFrameworksチームの2000台のP5インスタンスを持つクラスター管理経験に基づくカスタムGrafanaダッシュボードを使用したGPU障害のトラブルシューティングを学びました。 さらに、WWSOチームはParallelCluster（ Machine Learning on AWS ParallelCluster ）とHyperPod（ Amazon SageMaker HyperPod Workshop ）の双方に対応したワークショップを準備しました。これらの資料を使用して、参加者はSlurmを使用したトレーニングクラスターのデプロイ、FSx for LustreとFSx for OpenZFSを含むファイルシステム、マルチノードPyTorch分散トレーニングの実行を実践しました。ワークショップの別のセグメントでは可観測性とパフォーマンスチューニングに焦点を当て、参加者はリソース使用率、ネットワークスループット（EFAトラフィック）、システムの健全性のモニタリング方法を学びました。これらのセッションを通して、顧客とサポートするAWSエンジニアの両方が、共有の知識基盤とベストプラクティスのツールキットを確立しました。学んだすべての資産と知識を使用して、顧客はリードSAと共に、特定のユースケースに合わせたクラスターを同時にデプロイしました。このステップはオンボーディングセッションと呼ばれます。これらのセッション中、各リードSAは顧客がクラスターをデプロイし、NCCLテストを使用してクラスターの機能をテストし、通話中に発生した技術的な質問に対処できることを確認しました。 顧客のフィードバック データ入力の課題を根本的に解決するため、通常項目にはSLMとLLMを使用した2段階推論と自律学習、詳細項目には10万件の合成データサンプルを使用したVLMによる視覚学習を適用し、処理精度とコスト効率を大幅に改善しました。また、Amazon EC2 P5インスタンスを活用して研究開発効率を向上させました。これらの野心的な取り組みは、AWSを含む多くの方々のサポートによって可能になりました。広範なサポートに深く感謝いたします。 井上 拓真 – 執行役員CTO, AI Inside フューチャーはGENIACでの日本語とソフトウェア開発に特化した大規模言語モデルの開発においてAWSを選択しました。複数ノードを用いた大規模なモデル学習ではノード間通信等の環境設定に関する不安がありましたが、AWSではParallelCulsterをはじめとして周辺ツールが充実していたことに加え、AWSのソリューションアーキテクトの方々からも強力なサポートを頂き、迅速に大規模な学習を開始することができました。 森下 睦 – Chief Research Engineer, Future Corporation 結果と今後の展望 このブログで述べたような包括的な支援体制ににより、AWSは 12の顧客が1日で127台以上のP5インスタンスと24台のTrn1 を立ち上げる支援を提供できました。クラスタ上での6ヶ月の学習を通して、各事業者は基盤モデルの開発を行いました。 GENIACは、大規模な基盤モデルのトレーニングが本質的に組織的な課題であり、単なるハードウェアの問題ではないことを実証しました。構造化されたサポート、再現可能なテンプレート、クロスファンクショナルなコラボレーションを通じて、小さなチームでもクラウドで大規模なワークロードを成功裏に実行することができます。 AWSはすでにGENIACの次のサイクルの準備を開始しています。その一環として、AWSは4月3日に東京で基盤モデルビルダーにハンズオン体験とアーキテクチャガイダンスを提供するための技術イベントを開催しました。50名以上の参加者を集めたこのイベントは、スケーラブルで回復力のある生成AIインフラストラクチャをサポートするAWSの取り組みを示しました。 このイベントでは、GENIACのためのAWSの技術的エンゲージメントモデルと、 LLM Development Support Program や Generative AI Accelerator などの他のサポートメカニズムが紹介されました。イベント午前中には SageMaker HyperPod に関するワークショップが行われ、参加者はマルチノードGPUクラスターの立ち上げ、分散PyTorchトレーニング、オブザーバビリティを手を動かしながら学びました。午後に行われたセッションは、コンテナ化されたML、分散トレーニング戦略、AWSのカスタムシリコンソリューションなどの重要なトピックをカバーしました。またClassmethod Inc. からも実践的なHyperPodの洞察を共有するセッションがありました。このイベントは、インフラストラクチャからデプロイメントツールまで、AWSのエンドツーエンドのGenAIサポートエコシステムを紹介し、GENIAC第3サイクルの基盤を築きました。AWSが基盤モデル開発のサポートを拡大し続ける中、GENIACの成功は、組織が基盤モデル開発を効果的に構築しスケールするための青写真として機能します。 この記事は、AWS GENIAC Cycle2のコアテックメンバーである 小林正人 、 一柳健太 、 白澤聡 、Accelerated Computing Specialist  木内 舞 、ならびにリードソリューションアーキテクトの 宮本大輔 、 針原佳貴 、 佐々木啓 、 常世大史 によって寄稿されました。エグゼクティブスポンサーシップとして 安田俊彦 が支援を提供しました。また、AWS在籍時にコアメンバーおよびリードソリューションアーキテクトとして 畑浩史 氏 、 尾原颯 氏 、 卜部達也  氏も支援を提供しました。WWSO Frameworks チームのメンバーである Maxime Hugues 、 Matthew Nightingale 、 Aman Shanbhag 、 Alex Iankoulski 、 Anoop Saha 、 Yashesh Shroff 、 Shubha Kumbadakone  も広範な技術支援を提供しました。 Pierre-Yves Aquilanti 氏  もAWS 在職中に技術支援を提供しました。 著者について 渡辺啓太 は、AWS WWSO FrameworksチームのSenior Specialist Solutions Architectで、基盤モデルの学習と推論を専門としています。AWS 入社前は、E コマース業界で Machine Learning Researcherとして商品検索向けの画像検索システムの開発に従事していました。GENIAC における技術面のリードを担当しています。 井坂大 は、AWS WWSO Frameworksチームの Principal Business Development で、機械学習と人工知能ソリューションを専門としています。GENIAC の立ち上げ当初から関与しており、AWS の生成系 AI 製品の市場戦略をリードしています。 小林正人 は、2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

この記事は 2025 年 5 月 20 日に公開された Securing your origin for Media and Entertainment workflows を翻訳したものです。 メディアストリーミングアプリケーションでは、コンテンツへの権限のないアクセスや再配布などの、増加しているセキュリティ上の課題に直面しています。ストリーミングワークフローに対する一般的なセキュリティ脅威を精査し、Amazon Web Services ( AWS ) を使用してコンテンツを保護するための実用的なソリューションを提供します。 メディアストリーミングにおけるセキュリティ上の課題 ストリーミングアプリケーションに適切なセキュリティ対策が講じられていない場合、権限のないユーザーは以下のことが可能となります： 許可なくコンテンツにアクセスして再配布する 許可されていない Web サイトにストリームを埋め込む 自動プログラムを使用してコンテンツをスクレイピングする これらのセキュリティ侵害は以下を引き起こす可能性があります： 顧客の離反 インフラストラクチャコストの増加 アプリケーションパフォーマンスの低下 このブログはメディア & エンターテインメントのワークフローに適したオリジンについてのシリーズの第 2 回目です。前回は ワークフローに適したオリジンを選択する方法について説明 しました。 今回はオリジンとコンテンツの保護に焦点を当てます。 望ましくないアクセスからの保護方法 不正アクセスの 3 つの主要なポイントとそれに対応するソリューションについて精査します。 クロスオリジンリソースシェアリング ( CORS ) とオリジンへの直接アクセス iFrame 埋め込み ユニフォーム・リソース・ロケーター (URL) シェアリング 1. CORS とオリジンへの直接アクセス オリジンが直接アクセスされないようにするにはクライアントアプリケーションまたはウェブサイトがコンテンツ配信ネットワーク (CDN) 経由でのみビデオストリームをリクエストするようにしてください。 AWS の CDN サービスは Amazon CloudFront ( CloudFront ) です。 Amazon Simple Storage Service ( Amazon S3 )、AWS Elemental MediaPackage ( MediaPackage )、またはカスタムオリジンのいずれを使用する場合でも、オリジンを CloudFront に追加できます。詳細な手順については コンテンツへのセキュアなアクセスの設定とアクセスの制限 を参照してください。ドキュメントの手順に沿って実行することでリクエストはオリジンではなく CloudFront によってのみ処理されるようになります。 選択したオリジンの CORS ルールがアクセスを許可するドメイン名のみを許可するよう設定されていることを確認しましょう。 以下の図は正しい CORS ルールによってビデオストリームがどのように保護されるかを示しています。 図 1 : ビデオストリームへのアクセスを保護する CORS ルールを示す図 以下はドメイン “my-site.com” に対して GET メソッドを許可する Amazon S3 CORS ポリシーの例です。 <?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>https://www.my-site.com</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <MaxAgeSeconds>3000</MaxAgeSeconds> <AllowedHeader>Authorization</AllowedHeader> </CORSRule> </CORSConfiguration> CORS ルールとポリシーの設定方法の詳細については Amazon S3 CORS と MediaPackage CORS を参照してください。 2. iFrame の埋め込み ウェブページでは、特に動画の再生にネストフレーム (iframe) を使用するのが一般的です。これは、ウェブページの読み込み時間が短縮され、デプロイが容易になるためです。 このようなアプローチでは、開発者はプレーヤーフレームを埋め込んで目的の動画に指定するだけです。 iframe は HTML タグ <iframe> で 、HTML ページ（具体的には、「あるウェブサイト」）をあなたの HTML ページ（つまり、「あなたのウェブサイト」）に埋め込むことができるタグです。Web を使用していると気付かないうちに iframe を目にしています。 例えば、ニュースウェブサイトに埋め込まれている YouTube 動画がその一例です。ブログに埋め込まれている Facebook や Twitter の投稿も iframe の場合があります。これらはすべて別の HTML ページに埋め込まれた HTML ページです。 次の例では、左上の最初のウェブページに挿入された 4 つのビデオすべてが iframe タグを使用して挿入されます。ユーザーが動画の 1 つをクリックすると、ウェブサイトに動画を埋め込んだ iframe タグで定義されている動画（右側の 2 番目の画像）が開きます。この動画が実際にホストされている “実際の” ページは YouTube（中央下の画像）にあります。右上の画像に表示されている埋め込みページとは異なることがわかります。 図 2 : Web サイトに埋め込まれた iframe の使用 iframe の不正な埋め込みを防ぐには : セキュリティヘッダーに X-Frame-Options を実装します。 詳細については Mozilla 開発者ネットワークのドキュメント を参照してください。 CloudFront のセキュリティヘッダーレスポンスを使用してください。 詳細な説明については CloudFront レスポンスへの HTTP セキュリティヘッダーの追加 を参照してください。 適切な X-Frame-Options 値を設定します。 iframe のドメインが親フレームと同じ場合は SAMEORIGIN を使用してください。 DENY を使用すると、誰にも埋め込まれないようにできます。 誰かがあなたの iframe 埋め込みを悪用しようとした場合に、あなたのページに戻るようにする JavaScript ベースの埋め込み防止コードを追加することを検討してください。 3. URL シェアリング URL シェアリングに対処するには、いくつかの方法があります。 a. トークン化された URL トークン化された URL を使用すると、指定されたトークンが提供された場合にのみリクエストが処理されます。 通常、トークンは特定の情報をカプセル化したハッシュで、長期間使用されないように有効期限を短くするのが一般的です。 一般的な実装の例は以下のとおりです。 https://example.com/hls/playlist.m3u8?token=4180da90a6973bc8bd801bfe49f04a&expiry=1526231040535 や https://example.com/hls/segment001.ts?token=4180da90a6973bc8bd801bfe49f04a&expiry=1526231040535 のようになります。URL を取得しようとするリクエスト (この例では https://example.com/hls/segment001.ts ) を実行すると、403 HTTP エラーコードが返されます。 トークン化された URL を使用する利点 : 期間限定にできる 静的なホットリンクを防ぐことができる トークン化された URL を使用する場合の欠点 : 共有できてしまう スクレイピングできてしまう b. セッションベースのトークン URL トークンを強化するために、特定のユーザーと緊密に結びついたセッションベースのトークンを作成することができます。 汎用トークンはリソースへの直接アクセスを防ぐことができますが、セッショントークンはサイトやアプリケーションのコンテキスト外にあるリソースへのアクセスを防ぎます。 このトークンは、コンテンツをリクエストするユーザーが同じ IP アドレス、ユーザーエージェント、JS で生成されたハッシュ、その他のユーザー固有の情報を持っていることなどを検証します。 セッションベースのトークンを使用する利点 : セキュリティレイヤーの追加 特定のユーザーに紐付けられたアクセス制御 追跡と分析が可能 有効期限と取り消しが可能 セッションベースのトークンを使用する場合の欠点 : 複雑さの増大 アプリケーションのパフォーマンスに影響する可能性 サードパーティのプレーヤーや CDN ではサポートされていない可能性 強固な実装を行うには、 AWS でのエッジにおける安全なメディア配信 を使用することを検討してください。 c. ログインまたはペイウォールの追加 ユーザーログインやペイウォールの背後にあるストリームは、切り抜きされたり、外部で再生されたりする可能性がはるかに低くなります。 これをユーザー固有のトークンと組み合わせると、合理的で十分なレベルの保護が可能になります。 ログインやペイウォールを追加する利点 : 望ましくない一般からのトラフィックを削減させる ストリーミング認証を実際のユーザーセッションに紐付けられる ログインやペイウォールを追加することの欠点 : より複雑になってしまう エンゲージメントへの障壁が増加 アプリケーション認証ワークフローを改善するには、 新しい Amazon Cognito の機能でアプリケーションの認証ワークフローに磨きをかけよう を参照してください。 ペイウォールをエッジに移行するソリューションについては、 Guidance for Moving Your Paywall to the Edge on AWS をご参照してください。 d. 安全なハイパーテキスト転送プロトコル接続を使用 常にセキュアハイパーテキスト転送プロトコル (HTTP) 接続、別名 HTTPS を使用してください。これは HTTP のセキュアバージョンで、ユーザーとウェブサイト間の通信を暗号化します。HTTPS は、ユーザーとウェブサイト間で送信される情報を暗号化するために、トランスポート層セキュリティ ( TLS )、または以前はセキュア・ソケット・レイヤー ( SSL ) を使用します。 HTTPS 接続は、ユーザーが本物のウェブサイトと通信していることを保証するため、ウェブサイトの身元を検証します。次の確認により検証および保証します: 盗聴や身元情報の盗難から保護 ウェブサイトの身元を検証 データの整合性を保証 図 3 : SSL/TLS 通信ハンドシェイク図 HTTPS 接続を使用する利点 : HTTPS はエンドツーエンドの暗号化を提供 信頼と確実性を確立 コンプライアンスと規制 (PCI DSS、HIPAA、GDPR、NIST、ISO 27001) を保証 検索エンジン最適化 (SEO) の向上 HTTPS 接続を使用する場合の欠点 : レイテンシーにおけるパフォーマンスへの影響 SSL/TLS 証明書の管理における構成の複雑さ レガシー互換性 サーバー負荷の増加 特に機密情報やトランザクションを処理するアプリケーションでは、通常、HTTPS 接続の利点が欠点を上回ることに注意することが重要です。 HTTPS によってもたらされるセキュリティと信頼性の向上は現代のウェブアプリケーションにとって不可欠になっています。 CloudFront で HTTPS を設定する方法については、 CloudFront で HTTPS を使用する を参照してください。 e. デジタル著作権管理 ユーザーとウェブサイト間が HTTPS 接続されているだけでは、ユーザーが動画コンテンツをダウンロードし、コピーしたり、再配信したりすることを防ぐことはできません。要件とビジネスケースでユーザーによるコンテンツのダウンロードと再配信を阻止する必要がある場合は、ビデオストリームにデジタル著作権管理 (DRM) の適用を検討する必要があります。 DRM を適用できる AWS メディアサービスは、MediaPackage と AWS Elemental MediaConvert ( MediaConvert ) です。 これらのサービスは、Secure Packager and Encoder Key Exchange ( SPEKE ) を利用します。 SPEKE API の導入と統合はお客様の責任となります。 ビデオストリームに DRM を適用するには、 Content encryption and DRM in AWS Elemental MediaPackage と Protecting your media assets with encryption and DRM using AWS Elemental MediaConvert を参照してください。 次の (図 4) は DRM ワークフローの例です。 図 4 : SPEKE で DRM を使用するビデオワークフロー DRM を使用する利点: 不正なコンテンツダウンロードを防止 コンテンツライセンスルールを強制 さまざまな再生プラットフォームをサポート 安全なオフライン再生が可能 (設定されている場合) 詳細なコンテンツ使用状況の分析 DRM を使用する場合の欠点: プライバシーに関する懸念 技術的複雑さ 追加コスト 結論 メディアストリーミング配信元を保護することは、コンテンツを保護し、顧客の信頼を維持するために不可欠です。 ここで説明した方法を組み合わせて実装することで、アプリケーションのセキュリティ体制を大幅に強化できます。 まず Amazon CloudFront を設定し、HTTPS を有効にしてコンテンツを配信することをおすすめします。 適切な CORS ルールを実装し、セッションベースのトークン化された URL を使用してください。 iframe 保護の設定も検討してください。 ベストプラクティスとして、複数のセキュリティ方法を階層化して包括的な保護を行うことを提案しました。 セキュリティ要件とユーザーエクスペリエンスのバランスを取りながら、セキュリティ対策を定期的に監視および監査する必要があります。 次のステップでは、現在のセキュリティ体制を評価し、コンテンツ保護戦略のギャップを特定し、このブログで説明されているセキュリティ対策を実施することをお勧めします。 また、最適なユーザーエクスペリエンスを実現するために、必要に応じてセキュリティ構成を監視および調整する必要があります。 AWS メディアソリューションの詳細については、 AWS Media & Entertainment ページをご覧になるか、 AWS の担当者にお問い合わせいただき 、当社がお客様のビジネスの加速をどのように支援できるかをご確認ください。 追加情報 Cost-effective ways for securing your web applications using AWS WAF Geo-blocking with Amazon CloudFront Using CloudFront origin shield to protect your origin in a multi-CDN deployment Getting started with workflow monitor for AWS Media Services 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先 : awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は SA 加藤、長澤、石井が担当しました。原文は こちら をご覧ください。

本ブログは株式会社フレイ・スリー様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です 。 昨今、多くのお客様から生成 AI の活用についてご相談いただくようになりました。ISV(独立系ソフトウェアベンダー)/SaaS業界のお客様においても、生成 AI を活用した新しい製品・サービス開発の取り組みが増えてきています。 AI動画生成配信プラットフォーム「 1ROLL 」を提供する株式会社フレイ・スリー様は、 実際のビジネス課題を解決する機能をAWS上で開発するハッカソンイベント AWS DEVCRAFT に参加。「 Amazon Bedrock Claude3.5 Sonnet v2 / Amazon Bedrock Knowledge Bases 」を活用し、視聴データの評価、及び課題に応じた解決策を提案する機能を開発されました。 本記事では、生成AIを活用した動画マーケティング領域における効率化の取り組みについてご紹介します。 お客様の状況と検証に至る経緯 近年、動画コンテンツの需要が高まる中、動画制作は効率化が進んできました。しかしながら、制作後の運用面では以下の課題が残っていました。 どんな動画を作れば効果的か分からない 配信したけど視聴データの指標の見方が分からない 何を改善したらよいか分からない これらの課題についてサポートチームが個別に対応する必要があり、業務の負担が増大していました。また、視聴データの評価ポイントや改善策の内容は目的毎に共通していることが多く、生成 AI を活用してサポート業務を効率化できないかと考えました。 ソリューション/構成 動画の視聴データを「Amazon Bedrock Claude3.5 Sonnet v2」が分析及び課題を特定し、Amazon Bedrock Knowledge Baseから最適な解決策を提示する仕組みを AWS Step Functions でスピーディーに実装されました。 まずRDSに入っている動画構成データ、動画視聴データを取得します 次に動画視聴データをAmazon Bedrock Claude3.5 Sonnet v2に評価させます 視聴データの評価内容を解決ナレッジを保管してあるAmazon Bedrock Knowledge Basesから検索し提示します 導入効果 フレイ・スリー様の「動画アナリティクスAI Agent機能」により、以下の効果が期待されています。 動画活用の課題特定と解決策提示の自動化（動画評価及び解決策提示までわずか15秒で完了） サポート部門の作業負荷軽減に成功。 動画活用の継続的な改善サイクルの構築 今後の展望 今後の展開について、フレイ・スリー様は次のように意欲を示しています。 「今回の機能で動画活用の継続的な改善サイクルを構築し、より良い動画活用を自動で提案しながら、顧客自身で解決できるようなシステムの構築を目指します。」 AWS DEVCRAFTでの取り組み内容発表時の様子 株式会社フレイ・スリー 開発部 リードエンジニアの青木 諭氏 AWS DEVCRAFTでの要件定義ディスカッション中の様子 フレイ・スリー様ビジネスサイド（代表取締役 CEO 石田氏）、開発サイド（テックリード 青木氏、三好氏）、AWSアカウントチーム（ソリューションアーキテクト呉、アカウントマネージャー藤川）が１つの会場に集まりディスカッションする事で、ビジネス課題解決に向け実現したいイメージを短期間で形にすることが出来ました。