本記事は 新人ブログマラソン2024 の記事です 。 皆さんこんにちは！入社して間もない新米エンジニアの佐々木です。 最近、Snowflakeの比較的新しい機能である「 コンピュートプール 」について調査する機会がありました。 そこで本記事では、コンピュートプールについて調べたことを皆さんと共有したいと思います！ 特に、公式ドキュメントに記載されている細かい内容というよりも、 コンピュートプールの概要について初学者でも分かりやすいようにお話できればと思います。 まだ触れたことのない方も、既に利用している方も、ぜひご覧ください！   コンピュートプールとは何か？ コンピュートプールとは、 1つ以上の仮想マシン（VM）ノードを複数集めたサーバー群 です。 分かりづらい方は「コンピューターの力を集めた場所」と考えてください。例えるなら、複数の人が集まって一つのチームとして働くようなものです。 仮想マシンとは、一台の物理コンピューターの中で動く、仮想的なコンピューターです。このVMをたくさん集めて、まとめて使えるようにしたものが、仮想マシンノードを集約したコンピュートプールです。 他にも似たクラウドサービスの代表例として、Amazon EC2、Google Compute Engine、Microsoft Azure Virtual Machinesなどがあります。 コンピュートプールの作成 では、実際にコンピュートプールを作成する際の手順についてですが至って簡単です。 コンピュートプールは CREATE COMPUTE POOL  コマンドを使って、ユーザーが自由に作成・管理することができます。 具体的には、ワークシートで以下のクエリを実行することで、コンピュートプールを作成することが可能です。 CREATE COMPUTE POOL tutorial_compute_pool MIN_NODES = 1 MAX_NODES = 3    　INSTANCE_FAMILY = CPU_X64_XS ; 上記で設定している必須プロパティの意味は以下の通りです。 MIN_NODES ：コンピューティングプールで起動する最小ノード数。 MAX_NODES ：コンピューティングプールがスケールできる最大ノード数。これにより、Snowflakeの自動スケーリングによって予期せぬ数のノードがコンピューティングプールに追加されることを防ぐことができます。 INSTANCE_FAMILY ：コンピューティングプールノードにプロビジョニングするマシンタイプ。 これらのプロパティをプロジェクトの規模やニーズに応じて変更することで、スケーラビリティの確保やコスト最適化などにつなげることができます。 他にも設定できるプロパティは複数あるのでプロパティの詳細について気になる方は、以下の公式ドキュメントを参照してみてください！ CREATE COMPUTE POOL | Snowflake Documentation コンピュートプールの利点 ではコンピュートプールの利点は何なのか？についてですが、私が調査した限りだと以下の5つが挙げられるかと思います。 柔軟なリソース管理： 複数のVMノードをプールとして管理できるため、ワークロードに応じて柔軟にリソースを割り当て、最適化できます。 コスト効率の向上： 個々のVMノードは必要な時に必要な分だけリソース（CPUやメモリ）を使います。そのため、使用していないVMノードを自動的にスケールダウンすることで、コストを削減できます。 高可用性の実現： プール内のVMノードに障害が発生した場合でも、自動的に別のVMノードに切り替えることで、高可用性を実現できます。 スケーラビリティ: ワークロードの負荷に応じて、VMノードを簡単に追加、削除をすることができます。これにより、ワークロードのピーク時でも、プール内のVMノードを自動的にスケールアップすることで、パフォーマンスを維持できます。 管理の簡素化： たくさんのVMを個別に管理するのは大変ですが、コンピュートプールを使うと、まとめて管理できます。VMの状態を監視したり、ソフトウェアをアップデートしたりするのが簡単になります。 特に上記で既述した「スケーラビリティ」について触れると、コンピュートプールは自動的にサイズ調整する自動スケーリングの仕組みを持っています。 まず、プールを作成すると、Snowflakeは最低限必要な数の仮想マシン（ノード）を起動します。その後、作業量が増えて現在のノードでは処理しきれなくなると、自動的に追加のノードを起動して処理能力を増強します。 例えば、既に2つのサービスが動いていて、新たに別のサービスを追加すると、そのサービスに必要なリソースに応じて自動的に新しいノードが追加されます。 逆に、ある期間、ノードがほとんど使われなくなると、Snowflakeは不要になったノードを自動的に削除してコストを削減します。そのような場合でも、コンピュートプールは最低限必要なノード数を維持します。 つまり、コンピュートプールは、作業量に合わせて自動的にサイズを調整し、常に最適なリソースを使用する仕組みになっているということです。ユーザーは、常に最大の処理能力を確保しつつ、無駄なコストを削減できます。 考えられる利用用途 コンピュートプールの利用用途として考えられるものを以下にいくつか挙げてみました。 1. データウェアハウス処理： 複雑なSQLクエリの実行： 大量のデータを集計、分析、変換するための複雑なSQLクエリを実行します。例えば、数年分の売上データを地域別、商品別に集計して、売れ筋商品を特定するような処理です。 大規模データセットの結合： 複数のテーブル（例えば、顧客テーブル、注文テーブル、商品テーブル）を結合して、より詳細な分析を行います。 高度な分析： データ分析に必要な高度なSQL関数（例えば、移動平均、累積和、順位付け）を実行します。 2. データエンジニアリング： ETL/ELTパイプラインの実行： 外部システムからデータを抽出（Extract）、変換（Transform）、ロード（Load）するプロセスを実行します。 データ変換： データをクレンジング、整形、標準化し、分析しやすい形に変換します。 データ検証： データの品質を維持するために、データの整合性や正確性を検証します。 3. ビジネスインテリジェンス（BI）: BIツールとの連携： Tableau、Power BI、LookerなどのBIツールからSnowflakeに接続し、データを可視化するためのクエリを実行します。 ダッシュボードの作成： 重要なビジネス指標を監視するためのダッシュボードを作成します。 レポートの生成： 定期的なレポートを生成します。 4. データサイエンス/機械学習： 特徴量エンジニアリング： 機械学習モデルのトレーニングに必要な特徴量をデータから抽出します。 モデルのトレーニング： Snowflakeのデータを活用して、機械学習モデルをトレーニングします。 モデルのデプロイと予測： トレーニング済みのモデルをSnowflakeにデプロイし、新しいデータに対する予測を行います。 リアルタイムデータ分析： ストリーミングデータソースからリアルタイムに近い形でデータをSnowflakeにロードし、分析します。 他にも利用用途は複数あるとは思いますが、上記だけでもコンピュートプールが様々なユースケースで役立ちそうなことが分かるかと思います。 まとめ 本記事では、Snowflake のコンピュートプールについて大まかな概要を調査しました。 その結果コンピュートプールは、複数の仮想マシンノードを束ね、クエリ実行やデータ処理といったワークロードを処理するための強力なリソースだと感じました。ただし、コンピュートプールを効果的に利用する上では、ワークロードの特性をよく理解し、適切なサイズと構成を選択することが何よりも重要だと思いました。 しかし、今回の調査だけではコンピュートプールの表面しか見ることができなかったのが実状です、、、 そのため今回の調査を踏み台に、次回以降で実際にコンピュートプールを活用したチュートリアルを実施して、コンピュートプールとは何ぞや？をもう少し深ぼってみたいと思います！

本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。SCSKの さとです。2025年がもう6分の1が終わろうとしていることに愕然としています。 さて、2月にAmazon Bedrock Flows新機能のエージェントノードにおけるマルチターン会話がプレビュー公開されたので、今回はその「やってみた」記事です。 アップデートの概要   Amazon Bedrock Flows がマルチターンの会話サポートのプレビューを発表 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon Bedrock Flows がマルチターンの会話サポートのプレビューを発表 aws.amazon.com Amazon Bedrock Flowsは、基盤モデルやプロンプト、Amazon Bedrockエージェントなどを ノードとして扱い 、 GUI上で相互に関連付ける ことで生成AIワークフローを簡単に構築できるようになるというサービスです。 今回のアップデートでは、エージェントがタスクを行うにあたり、必要に応じてフローを停止し、会話の往復の中で情報を取得しタスクを完了することが可能になりました。これにより、アクションの完了のために追加の情報取得が必要になった場合でも同一フローを用い続けることができず、エージェントがコンテキストを忘れてしまうという問題が解消されるようになります。   やってみた：企業の情報取得ボットの作成 というわけで、早速アップデートされたAmazon Bedrock Flowsのマルチターン会話を試してみたいと思います。 今回は、社員番号によって給与の額が決まる架空の企業「Exploitation Inc.」に関する情報を答えるチャットボットという設定でフローを組んでみます。このため、給与に関する質問を投げかけられると、チャットボットは社員番号について情報提供を依頼する必要があります。 Amazon Bedrock Flowsに触れるのは今回が初めてということで、本筋とは離れますが条件分岐を用いた複数種類のクエリへの対応も試してみました。フロー構成は以下の公式ブログを参考にしています。 Introducing multi-turn conversation with an agent node for Amazon Bedrock Flows (preview) | Amazon Web Services Today, we’re excited to announce multi-turn conversation with an agent node (preview), a powerful new capability in Flow... aws.amazon.com 処理の流れ ご覧のように、全体としてはFlow inputからユーザーの入力が各ノードに渡され、最終的にFlow outputへ到達したデータがレスポンスとなります。今回は、ユーザーからの質問をざっくりと「給与関係」「それ以外」に分け、それぞれで回答を行うようフローを作成しました。主要なノードの役割とその設定は以下の通りです。   Promptノード: QueryClassifier Promptノードは、フロー内で基盤モデルにプロンプトを送信し、その応答を取得するために使用することができます。ユーザーからの入力（Flow Inputの出力）はこのノードが受け取り、質問の内容に応じて分類されます。プロンプトはBedrockのプロンプト管理機能からのプロンプトを用いることもできますが、ここではノードで新たに定義しました。 {{input}}を分析し、ユーザーからの質問が給与に関する事項ならばAを、それ以外ならばBを出力してください。出力は必ず1文字であり、それ以外は受け付けられません。 ここで、{{input}}は入力に対してデフォルトで割り当てられている変数名で、上のように波括弧で括ることで指定できます。また、回答の信頼性を高めるため、出力の温度は低めの0.1に設定しました。   Conditionノード: QueryType Conditionノードでは条件の判定結果に応じて次の処理を行うノードを指定することができます。 QueryClassifie r のOutputから QueryType のInputまでを線で接続することで入出力関係を指定し、分かりやすさのため、さらにこの入力にQueryTypeという名前をつけます。 次に、条件とその分岐先を指定します。 QueryClassifier において入力が「給与関係」ならば出力がA、「それ以外」ならばBと指定したので、条件式を QueryType==”A” とし、これが真ならば次のノードとして AboutSalary へ、そうでなければ AboutOtherTopics へ移るよう設定を行います。       Agentノード： AboutSalary 、 AboutOtherTopics 分岐先のAgentノードを設定します。ここでは、作成済みのBedrockエージェントに対して入力を送信する処理が行われます。 ユーザーからの入力をもとに回答を作成するので、Flow Inputから各AgentノードのInputまでを接続します。ここで、フローのダイヤグラムにおいて紫色の点線で示されるConditionノード-Agentノード間の接続はあくまで処理の分岐を表すだけで、 入出力関係を表している訳ではない ということに注意が必要です。 また、これらのノードに紐つけるBedrockエージェントを別途作成・準備します。給与に関して応答を行うエージェントには以下のプロンプトを与えました。 あなたは、ユーザーから受け取ったExploitation Inc.の給与に関する質問に回答します。 回答にあたり、以下の事実を用いてください。 <ルール> 給与は、社員番号のみによって決定する。 社員番号 1〜10000: 年収1億円 社員番号 10001〜: 年収0円 給与以外に関して応答するエージェントも同様に設定します （このエージェントはマルチターン会話とは関係がないので、プロンプトは割愛します） 。 それぞれをFlow Outputノードへと接続し、ユーザーへの返答にします。 フローをテストする 一通りの設定が完成したので、フローの設定画面右側からテストをしてみましょう。 給与を確認すると、上のように追加で社員番号を聞かれました。エージェントへのプロンプトは追加で確認をさせるような文言が入っていないので、デフォルトでこのような指示が組み込まれていると考えられます。 続いて、社員番号を与えてみます。 給与に関して回答してくれませんでした。よく見ると、1回目の質問への返答があった直後に「 Flow ended in 45 seconds 」とフローが終了していることが示されており、そのまま社員番号の情報だけ渡したためその他の質問として扱われてしまっているようです。 どうやら、追加の情報取得を行うにはBedrockエージェント側で「ユーザー入力」を有効にする必要があったようです。その他の設定からオプションを有効にし、改めて試してみます。 謎に謝られてしまいましたが、想定通りの回答になりました。一応、社員番号 1〜10000でも指定した回答になるか試してみましょう。 無事、年収が1億円になりました。今回は簡単のためにプロンプトに直接情報を入れてしまいましたが、実際の場面ではエージェントを通してナレッジベースから情報を取得するなどが可能です。   おまけ：その他の話題に関する質問 せっかくなので、もう一方の条件分岐先であるその他の話題についても適切に回答されるか試してみましょう。 こちらも、あらかじめ設定した通りの内容が回答されました。   おわりに いかがでしたか？これまでだと不足する情報に対し情報提供を求めるには処理フローを追加する必要がありましたが、今回のアップデートではそのような部分がBedrock側で自動化されるため、かなりシンプルに実装が可能になったのではないかという印象を持ちました。 最後までお読みいただき、ありがとうございました。

SCSKの畑です。 以前のエントリ で少し触れた通り、Redshift テーブルのデータメンテナンスアプリケーションの実装にあたり、テーブルデータの表示や編集に使用したライブラリの Tabulator について、使用した理由や特徴をまとめてみました。このため、今回は完全にアプリケーション実装に閉じた話題となります。 なお、Tabulator の公式 URL は以下の通りです。 Tabulator - Interactive JavaScript Tables Create interactive data tables in seconds with Tabulator. A free, open source, fully featured JavaScript table / data gr... tabulator.info   ライブラリの要件及び選定理由 本案件事例における期間や工数の関係から、全ての機能を自前で作り込むのは難しいと考えていました。特に、テーブルデータの表示/編集については主要機能であり、かつ画面/ロジック両方の実装が必要になることから、できるだけ（出来の良い）外部ライブラリを使用しつつ必要に応じて手を加えるような形で進めるのが理想と考えていました。 ライブラリの選定における要件をまとめると、概ね以下の通りです。 ソフトウェアライセンスの観点で問題なく使用でき、かつ費用がかからないこと テーブル（表）形式のデータの表示及び編集機能を備えていること テーブル（表）形式のデータの表示及び編集のどちらについても基本的な機能を備えており、かつ必要に応じて拡張できること Nuxt(Vue) に対応していること（実装例があること） Web 上のドキュメントやナレッジがある程度充実していること で、平たく言うとこのような要件を満たすものとして一番筋が良さそうだったのが Tabulator でした。 まず、当時私が探した限り、1.及び2.を満たすライブラリがほとんど見当たらなかったのが一番大きな理由です。テーブル（表）形式のデータの表示のみであれば多種多様なライブラリがありましたが、いわゆるエクセルライクにテーブルデータを編集できるようなライブラリとなると数が大分限られました。その限られた選択肢においても出来の良さそうなものは表示機能のみなら無償だが編集機能を使用する場合は有償にとなったりしたため、この時点で実質的にはほぼ Tabulator の一択であったというのが正直なところです。 表示機能のみライブラリを使用し、編集機能（画面）は自前で実装する or 他のライブラリを活用するというアプローチも可能だったと思いますが、メンテナンス対象のテーブルやテーブル定義が変わり得る以上、各テーブルごとに編集画面を作成するのはコストや運用の観点から現実的ではありませんでした。各テーブルに拠らない汎用的な編集画面を作ろうとするとそれはそれでコストがかかる上、お客さんの画面イメージとしてもエクセルライクにテーブルの項目をそのまま編集できることが望ましいとのことで、やはりこのライブラリが良さそうだなと。 このため、3.以降は実質的にオマケというかあったら嬉しいな程度の内容だったのですが、それらの要件も満たしていたため最早このライブラリを選ばない理由がないと判断できました。 もちろん全てのライブラリを網羅して探すことはできなかったと思うので、もし他に良さそうなものがあればご教示頂けますと幸いです。それなりに気合を入れて探したつもりではあるので、簡単に見つかってしまったらちょっとショックかもしれないですが・・w   ライブラリで特に役立った・あって良かった機能 使用方法や各機能については公式ドキュメントの出来が良いため本エントリでは割愛し、ここではアプリケーション実装において特に役立った、あって良かったと感じた機能について簡単に所感を述べていこうと思います。 現時点で最新バージョンが 6.3 であるため、公式ドキュメントへのリンクは全て同バージョン向けとなっています。 Tabulator - Documentation Create interactive data tables in seconds with Tabulator. A free, open source, fully featured JavaScript table / data gr... tabulator.info   検索（フィルタ）/ ソート / ページネイト いずれの機能もテーブルデータの表示機能において標準的に求められる機能だと思うのですが、これらの機能が全て標準で備わっていたのが良かったです。（最も、このような機能は他ライブラリでもある程度備わっていたものが多かったので、そこまで特筆すべきことではないのかもしれませんが・・） Tabulator - Filtering Data Use custom or built in filter fuctions to allow users to view a subset of table data tabulator.info Tabulator - Sorting Data Allow users to order table data with a range of built in and custom sorter functions tabulator.info Tabulator - Pagination Break data down into pages to make it easier to digest tabulator.info また、後述する項目とも共通しますがこれらの標準機能は細かな設定変更が可能なものが多く、これらの機能については完全にライブラリの標準機能のみで賄えたという点も良かったです。例えばエクセルの列フィルタライクな検索機能や、テーブル画面初期ロード時のソート条件指定、ページネイトにおける1ページあたりの件数指定の動的な変更などですね。   ローカルファイルからのデータロード こちらの機能もライブラリの標準機能でカバーできました。これも自前で実装するとなると地味に面倒な機能だったので良かったです。対応しているファイルフォーマットも複数種類あります。それほど柔軟性はなさそうなので、より細かい要件に対応する場合は自前でファイルのインポート処理を実装して、本ライブラリに組み込むことも可能です。 このような拡張性は後述する他機能においても充実しており、実装例も公式ドキュメントに一通り示されており開発も大きく躓くことなく進められたことも大きかったです。要件の項目で述べた通り、Web 上のナレッジもそれなりにはありました。 Tabulator - Loading Data Tabulator can load data from a wide range of sources, learn how to load data from arrays, JSON and AJAX sources tabulator.info   データバリデーションチェック 実装コストの観点で最も助かったのがこの機能です。 Tabulator - Data Validation Validate user entered data before accepting it into the table tabulator.info 過去のエントリでも言及している通り本アプリケーションの主要機能（要件）でもあり実装は必須でしたが、テーブル定義や制約に準ずるバリデーションチェック機能を全て一から実装するのはさぞかししんどいだろうなと思っていたところ、データ型や標準的な PK/UK（単一列）、NOT NULL など制約のバリデーションチェックは標準機能で対応できたというのがまず助かりました。 複数列による PK/UK 制約（複合キー制約）や FK 制約については未対応だったのですが、ユーザで定義/実装した独自のバリデータを本ライブラリのバリデーション機能に組み込むことができるため、それを活用することでライブラリ側のバリデーションチェックの枠組みの中でこれらのチェックについても実施することができました。フロントエンド（画面）側の機能実装としては山場となったポイントの1つでしたが、これらの特徴のおかげで想定以上にコストを抑えられたのもありがたかったです。 また、バリデーションチェックのタイミングも幾つかの選択肢の中から任意に設定できる点も良かったです。デフォルトでは画面上でデータを編集した直後のタイミングなのですが、先述したローカルファイルからのロードについてはライブラリ上「編集」という扱いではないこと、一時的に列定義/制約に反するデータを入力したいケースもあることが想定されたことの2点より、任意のタイミングでバリデーションチェックを実行できる方が望ましかったのですが、そのような実装も可能だったため支障ありませんでした。 もちろん、バリデーションチェックを実行して合格しない限りはテーブルデータの更新ができない（更新フローが進まない）ようなロジックとしています。   データのプルダウン入力 主に FK 制約のある列の値入力に使用しました。 FK 制約により、入力可能な値は FK 参照先のテーブル/列の値に限定されるため、データを自由入力させずにそれらの値をプルダウン形式で入力できた方がユーザビリティの観点から優れていると考えて、この機能を使用しました。 Tabulator - Editing Data Use built in cell editors to allow users to edit table data, or build out your own for fully customizable table input tabulator.info プルダウン入力候補のデータを動的に定義できることは当然として、候補データのインクリメンタルサーチなども標準でサポートされていたためプルダウン候補の多いデータ入力にも支障ありませんでした。FK 参照先のテーブルからも同時に値を取得する必要があるなど、こちらの機能もフロントエンド（画面）側で山場となったポイントの1つでしたが、同様に実装コストを抑えることができました。   Mutators & Accessors テーブルデータをライブラリを使用して画面表示する際にデータを加工・変換するため機能です。それぞれ、Mutators はデータ自体を変換、Accessors は表示のみを変換します。 Tabulator - Mutators & Accessors Manipulate data as it enters or leaves a table tabulator.info 本アプリケーションにおいては、テーブルデータ内の一部の ID 値を論理名のような分かりやすい表示に変換するために使用しています。具体的には以下のような用途です。 FK 制約のある列に入る値（FK 参照先テーブルの ID 列の値）を、アプリケーションマスタで定義した論理名に変換 論理名自体も FK 参照先テーブルの値を使用しています。例えば、国マスタの ID を国名（論理名）に変換するような処理が可能です。 更新対象行の作成者/更新者列に入る値（ユーザ ID）を、ユーザの氏名表示に変換 ユースケースに応じて Mutators/Accessors を使い分けられる点も含めて機能自体が便利なことはもちろん、データの加工・変換ロジックは自由に実装できるようなライブラリの作りとなっていたため、FK 制約のようにやや複雑な変換ロジックにも対応できました。また、変換ロジックに該当しないようなデータはそのまま変換せず表示することも可能であるため、柔軟性も持たせることができています。   まとめ 正直、このライブラリなしでの本アプリケーションの実装はなかなか厳しかったのでは、と感じるレベルではお世話になりました。テーブル/表の編集機能が必要となるようなアプリケーションの実装では今後積極的に使用していこうと思えるレベルで作りが良かったです。 最も、躓いた点もいくつかあったことはあったので、機会があれば別エントリでまとめてみたいと思います。 本記事がどなたかの役に立てば幸いです。

こんにちは、ＳＣＳＫ　池田です。 LifeKeeperの購入前に、「LifeKeeper」がどういう製品か知りたいことってありますよね？ ネットで検索したり、メーカー公式ホームページを観たり、TechHarmonyを観たり、様々な確認方法があるかと思いますが、製品仕様の細かなところなどはどうしても記載されていないケースがあると思います。 購入前なのに質問できます！ そんな時はなんと購入前でも、メーカーであるサイオステクノロジー社のサポートに質問することができるんです！ サポートへのお問い合わせ方法 – SIOS LifeKeeper/DataKeeper User Portal まず、会社名、部署名、氏名、メールアドレス、連絡先電話番号を入力してください。 その後に「お問い合わせ内容のカテゴリ」を選択します。 選択肢は以下の通りです。 ■お問い合わせ内容のカテゴリ ・価格/構成 ・機能/動作 ・構築環境 ・実績/事例 ・その他 「お問い合わせ内容」を記載して、個人情報の提供にチェックを入れて、最後に「私はロボットではありません」の手続きを踏んでください。 たったこれだけで、サイオステクノジー社からお問い合わせに対する回答を得られます。 また何らかのミドルウェアの構築をご検討でしたら、LifeKeeperのSI&サポートパートナー(ゴールド)のSCSKまでメールにてお問合せください。 SCSK株式会社　LifeKeeperチーム メールアドレス： LK@scsk.jp 公式ホームページ： 「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社 お問い合わせ・ご相談： HAクラスターソフトウェア「LifeKeeper」 お問い合わせ｜ SCSK株式会社 20年以上に渡る豊富な設計、構築、サポート実績から、お客様の求める可用性の実現のお手伝いをさせていただきます。 それぞれの使い分けとしては、製品仕様など最新情報の入手時にはサイオステクノロジー社のWebフォームから、 SIをご希望、構築可能な構成、LifeKeeperに留まらない様々なパターンの可用性提案をご希望されるような時にはＳＣＳＫへ問い合わせするなどしていただければと思います。 もしＳＣＳＫ　LifeKeeperチームでお答えできない場合でも、ＳＣＳＫ社内の有識者やサイオステクノロジー社と連携しながら、お客様の疑問にお答えさせていただきます！ まとめ 今回は、購入前の問い合わせ方法についてご紹介しました。 問い合わせ方法は大きく３つあります。 ・サイオステクノロジー社の公式サイトのWebフォームから問い合わせる ・ＳＣＳＫのメールアドレスに問い合わせる ・ＳＣＳＫの公式サイトのお問い合わせ・ご相談Webフォームから問い合わせ

Amazon EC2 の外からOSコマンドを実行させるには、AWS Systems Manager (SSM) の SendCommand を用いるのが常道だと思いますが、環境上の制約で使用できない場合もあるかと思います。そこでSSMを使用することなく、OSコマンドを実行させるシンプルな仕組みを作ってみます。 (sshでのコマンド実行は自明ですし、AWSに関係ないのでここでは触れません。)   Systems Manager(SSM)とSendCommandについて 先ずはSSMとSendCommandについて軽く触れます。 SSMの SendCommand とは、SSMのマネージドノードとなっているEC2に対して、EC2の外からOSコマンドを送って実行できます。 「外から送って」と書くと、EC2に外からコマンドが入ってくる形のように思えますが、実際にはEC2で稼働しているssm-agent がSSMのエンドポイントに対してポーリングしており、 コマンドを取ってくる 形になっていると思われます。 (そうでなければEC2へのインバウンド通信許可を必要とするはずですが、実際にはそんなことはしません。) この構成を真似することにします。  構成の概要 上図の構成とします。SSMの位置にSQSを配置し、そこにOSコマンドを入れる。EC2はQueueを定期的に監視するシェルスクリプトを常駐させて、キューにコマンドが入っていればそれをフェッチして実行します。要するにssm-agentの簡易版で置き換えた形だというだけです。(がっかりした人はすみませんm(_ _)m ) 以下、EC2とSQSの内容について簡単に述べておきます。 SQSについて キューは以下の構成とします。 標準キューであるということと、メッセージ保持を1分にしています。あまり長くするとagent役のshellの障害時などにキューにコマンドがたまり、思わぬ昔のコマンドが実行されてしまうことを防いでいます。1分以上フェッチされなければそのコマンドは実行されませんが、そこは割り切っています。また、キューポリシーは適当に設定します。 EC2について シェルが動けば何でもいいですが、上記SQSキューに対して、 sqs:ReceiveMessage および sqs:DeleteMessage の権限が必要ですので、EC2にアタッチするIAMロールに付与しておきます。   ポーリングスクリプトとサービス化 ポーリングスクリプト ポーリングシェルは以下のように作成してみました。シェルの詳細についてはこの話題の主題ではありませんので細かくは触れません。 #!/bin/bash # SQSキューURL (適宜変更) QUEUE_URL="https://sqs.ap-northeast-1.amazonaws.com/xxxxyyyyzzzz/TestQueue" # ログディレクトリとファイル設定 LOG_DIR="/var/log/command-execution" LOG_FILE="$LOG_DIR/command_execution.log" # ログディレクトリの作成 if [ ! -d "$LOG_DIR" ]; then sudo mkdir -p "$LOG_DIR" sudo chown ec2-user:ec2-user "$LOG_DIR" sudo chmod 755 "$LOG_DIR" fi # ログファイル作成 touch "$LOG_FILE" chmod 644 "$LOG_FILE" echo "[$(date)] SQS polling service started." >> "$LOG_FILE" while true; do # SQSからメッセージ取得 RESPONSE=$(aws sqs receive-message \ --queue-url "$QUEUE_URL" \ --max-number-of-messages 10 \ --wait-time-seconds 10 \ --output json 2>/dev/null ) # RESPONSEが空ならデフォルト値を設定 if [ -z "$RESPONSE" ]; then MESSAGE_COUNT=0 else MESSAGE_COUNT=$(echo "$RESPONSE" | jq '.Messages | length' 2>/dev/null) if [ -z "$MESSAGE_COUNT" ]; then MESSAGE_COUNT=0 fi fi if [ "$MESSAGE_COUNT" -gt 0 ]; then echo "$RESPONSE" | jq -c '.Messages[]' | while IFS= read -r MESSAGE; do # ReceiptHandleとBodyを安全に取得 RECEIPT_HANDLE=$(echo "$MESSAGE" | jq -r '.ReceiptHandle' 2>/dev/null) COMMAND=$(echo "$MESSAGE" | jq -r '.Body | @sh' 2>/dev/null | sed "s/^'//;s/'$//") # 無効メッセージ判定 if [ -z "$RECEIPT_HANDLE" ] || [ -z "$COMMAND" ]; then echo "[$(date)] Warning: Invalid message detected. Skipping..." | tee -a "$LOG_FILE" continue fi # コマンド実行 TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S") echo "[$TIMESTAMP] Executing command: $COMMAND" | tee -a "$LOG_FILE" { echo "----- START: $COMMAND -----" eval "$COMMAND" EXIT_CODE=$? echo "Exit Code: $EXIT_CODE" echo "----- END: $COMMAND -----" } >> "$LOG_FILE" 2>&1 # メッセージ削除 DELETE_RESPONSE=$(aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE" 2>&1) if [ $? -eq 0 ]; then echo "[$(date)] Command executed and message deleted." | tee -a "$LOG_FILE" else echo "[$(date)] Error deleting message: $DELETE_RESPONSE" | tee -a "$LOG_FILE" fi done fi sleep 5 done 5秒(sleep 5)ごとに指定のキューからメッセージの取得を試みます。この値はSQSの料金に影響します。 コマンド実行後はメッセージを削除しています。 また、受け取ったコマンドと実行結果をログに出力するようにしています。オプションでこのログをCloudWatch Logs に連携してもいいでしょう。配置場所は/usr/local/bin/sqs-polling.sh とします。パーミッションは適当につけておきます。 サービス化 上記スクリプトをサービス化するため、systemdのユニットファイルを作成します。 [Unit] Description=SQS Polling Service After=network.target [Service] ExecStart=/usr/local/bin/sqs-polling.sh Restart=no User=ec2-user Environment="PATH=/usr/bin:/usr/local/bin" [Install] WantedBy=multi-user.target 上記を/etc/systemd/system/sqs-polling.service として保存して、以下コマンドでサービス起動・確認します。active(running)を確認してください。 sudo systemctl daemon-reload sudo systemctl start sqs-polling.service sudo systemctl status sqs-polling.service 動作確認 ではキューにコマンドを置いてみます。簡単にSQSのマネコンから実行します。loggerコマンドで/var/log/messagesに文字列を吐き出してみます。   /var/log/messages Feb 28 14:25:59 ip-10-0-0-210 sqs-polling.sh[5414]: [2025-02-28 14:25:59] Executing command: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" Feb 28 14:25:59 ip-10-0-0-210 ec2-user[5415]: hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!! Feb 28 14:26:01 ip-10-0-0-210 sqs-polling.sh[5422]: [Fri Feb 28 02:26:01 PM JST 2025] Command executed and message deleted. シェルのログファイル [2025-02-28 14:25:59] Executing command: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- START: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- Exit Code: 0 ----- END: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- [Fri Feb 28 02:26:01 PM JST 2025] Command executed and message deleted. となって動作が確認できました。 キューにコマンドを置くことができれば何でもいいので、例えばLambda関数が該当キューにOSコマンドをputすれば、Lambdaが間接的にEC2のOSコマンドを打ったことになります。 最後に EC2から他のAWSサービスへの連携はAWS CLIなどを使えば容易なのですが、AWSサービスからEC2(の中)への連携は手段が限られているように感じましたので、少し考えて作成してみました。 要点は、EC2から外部の状態を取りに行く、という点です。ここではSQSを例にしましたが、S3などを考えても面白いでしょう。 (定期的にS3のあるオブジェクトの存在を確認し、存在すればダウンロードして(以下略)) やったことはssm-agentの超簡易版を作成したに過ぎませんが、そこまで複雑でないことはわかっていただけたと思います。 コマンドの結果をサービス側で知るにはもうちょっと考える必要はありそうです。 SSMが使えるならそちらを使うべきだとは思いますが、色々な制限でそれが叶わない場合の選択肢として、皆様の参考になれば幸いです。 コードの使用は自己責任でお願いいたします。

本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。入社一年目の曲渕です。 現在はAWSの技術習得に向けて勉強している最中です。その際に AWS Cloud9 を使ったAWSのハンズオンを実施したのですが、私のAWSアカウントではCloud9が使用できなくなっていました。そこで本記事では、私と同じような状況になっている方や今年入社される方の参考になればと思い、Cloud9に代わるサービスをご紹介させていただこうと思います。 背景 AWS Cloud9 とは AWSが提供するサービスの一つで、 ブラウザを通じてクラウドベースでコードの記述、実行、デバッグができる統合開発環境(IDE) です。利点として、リアルタイムで共同作業ができることや必要なツールなどがあらかじめ設定されており、開発環境のセットアップが簡単なことが挙げられます。 そんなCloud9ですが、私のAWSアカウントでサービスにアクセスしようとすると、以下のような表示が出ます。   原因は AWSが2024年7月25日以降のCloud9を含むいくつかのサービスで新規利用受付を終了 したためです。そのため、新人の方で私のように配属された後にAWSアカウントを作成した場合は、Cloud9が使用できなくなっています。もしかすると案件などでお客様側からAWSアカウントを払い出してもらった方も同じ状況かもしれません。 （2024年7月25日以前にAWSアカウントでCloud9を使用されていた方は現在でも利用可能です） この問題を解決するために、この記事ではCloud9の代替策となる3つのサービスの概要について記述します。   Cloud9の代替えサービス ご紹介させていただくサービスは以下の3つです。   Amazon SageMaker Studio コードエディタ 概要 Amazon SageMaker Studio コードエディタはAmazon SageMakerの機能の一部です。任意のVPC内に置くことができたりなど、ほぼCloud9と同等の環境を構築することができるというメリットがあります。デメリットとしては起動・削除に時間がかかることやリソースを消したい場合にドメインやユーザーの削除も必要な点が少し面倒です。また、デフォルトでdocker コマンドが使えないため、コンテナを使うためにDockerfileのイメージをリポジトリにプッシュしたいときなどはdockerコマンドのインストールが別途必要になります。   AWS CloudShell 概要 AWS CloudShell は Amazon Linux 2023 ベースのブラウザから操作できるシェル環境です。無料で使用することができ、すぐに実行できるというメリットがあります。ファイルのアップロード、ダウンロードも可能です。しかし、デフォルトのディスク容量が1GBのみのため、大きなファイルを実行するのには不向きというデメリットがあります。また、任意のVPC内に置くこともできません。   Amazon CodeCatalyst 概要 Amazon CodeCatalystは開発者がソフトウェアを迅速に構築、テスト、およびデプロイできるように設計された統合ソフトウェア開発サービスです。CI/CDパイプライン (ソフトウェアの変更を自動でテストし、ビルドし、デプロイするプロセス)を簡単に実現することができ、Cloud9のインスタンスを立ち上げることができるメリットがあります。しかし、現在（2025年2月25日）は東京リージョンで使用することができず、米国（オレゴン）リージョンと欧州（アイルランド）リージョンのみで使用可能となっています。またAWS Builder IDの作成などの初期設定が必要というデメリットがあります。   まとめ 今回はCloud9の代替サービスの概要について簡単にまとめてみました。案件によっては使えないサービスなどもあるかと思いますが、勉強のためのハンズオンの参考になれば幸いです。構築手順については参考資料を見ていただければと思います。また、Cloud9のほかに以下のサービスも新規利用の受付を終了しているようです。 S3 Select CloudSerch SimpleDB Forecast Data Pipeline CodeCommit   参考資料 AWS Cloud9が突然、新規利用不可に？ 代替策「SageMaker Studio コードエディタ」の利用手順 #cloud9 – Qiita AWS CloudShell を早速使ってみました #reinvent – Qiita 【CodeCatalyst 入門①】CodeCatalystの初期設定方法 | わかるブログ Amazon CodeCatalyst 触ってみた! #AWS – Qiita

こんにちは、SCSK株式会社の谷です。 前回、新たに私たちの部署に新入社員として加わった嶋谷さんが、 Mackerel を使ってAWS環境のDocker情報を可視化する方法と結果 についての記事を掲載しました。 ご覧になっていない方は、ぜひ目を通してみてください。 Mackerel で Docker を監視してみた – TechHarmony 今回は、MackerelにてAWSのサーバーレスサービスを監視し可視化しました。 監視対象のシステムについて 今回の検証のため、AWSが提供しているハンズオンから簡易的なWebアプリを構築しました。 名前を入力しボタンを選択すると、「Hello from Lambda」で始まり入力したテキストが続くメッセージが表示されるWebアプリです。 Webアプリの構成は以下の図になります。   構成しているサービスの中で今回は以下を使用して検証をしました。 Amazon DynamoDB 　　 完全マネージド型の NoSQL データベースサービス Amazon API Gateway 　 APIの作成および管理を簡単に行えるフルマネージドサービス AWS Lambda 　　　  　　サーバーレスコンピューティングサービス 上記環境の構築手順について、この記事では説明を省略させていただきます。 詳しく知りたい方は、以下に詳細な構築手順が載っていますので、こちらをご覧ください。 AWS で基本的なウェブアプリケーションを構築する Mackerelでの監視設定手順 ここではMackerelで各サービスを監視するための設定手順について記載しています。 設定手順の詳細につきましては、Mackerel公式ヘルプをご参照ください。 AWSインテグレーション – Mackerel ヘルプ 設定手順について興味のない方は、このパートはスキップして「 Mackerel上で監視データの確認 」のパートに飛んでください。 インテグレーション用のIAMロールの作成 (1) Mackerelの管理画面で「オーガニゼーション名」＞「AWSインテグレーション」をクリックする。 (2)「新しいAWSインテグレーションを登録」というボタンが表示されるため、それをクリックする。 (3) 基本設定＞AWSアカウント　外部IDをコピーする。 (4) AWSのコンソールにログインし、左上の検索バーで「IAM」と入力し、エンターを押す。 (5) 左側のタブからロールを選択し、「ロールを作成」をクリックする。 (6) 以下に沿って入力し、すべて入力後、「次へ」をクリックする。 信頼されたエンティティタイプ ： AWSアカウント AWSアカウント　　　　　　   ： 別のAWSアカウント アカウントID                        ： 217452466226（共通） オプション　　　　　　　　　 ： 外部IDを要求する (7) 今回はLambda、API Gateway、DynamoDBを監視したいため、それらに関するReadOnlyロールを選択し、「次へ」をクリックする。 (8) ロール名と説明を適宜入力し、「ロールを作成」をクリックする。 (9) 作成したロールの詳細画面で表示される、ARNをコピーする。 AWSインテグレーションの作成 (1) Mackerelの管理画面に戻り、先ほど開いた「新しいAWSインテグレーションを登録」画面を開く。   そこで、名前の入力とリージョンの選択を行い、ロールARNの欄に先ほどコピーしたARNを貼り付ける。 (2) メトリックを収集するサービスで、Lambda、API Gateway、DynamoDBを選択する。   他の取得可能なサービスにつきましては以下の公式ヘルプの「 対応しているクラウド製品 」を参照ください。       AWSインテグレーション – Mackerel ヘルプ (3) 「タグを指定して登録するホストを絞り込む」にて連携したいリソースのタグ、除外したいタグを入力する。 (4)「作成」をクリックする。 これで、インテグレーションが作成できました！ 連携確認 以上で設定は完了です。 ここからは、監視設定を入れたサービスの状態を見てみましょう。 ここまでの手順が完了すると、Mackerelの管理画面の「ホスト」のところですぐに確認することができます。 このように、Lambda、API Gateway、DynamoDBの3つのデータが取れていることがわかります。 Mackerel上で監視データの確認 設定作業はいかがでしたか？ 思っていたより簡単に監視ができると感じた方が多いのではないでしょうか。 では、ここからはAWSから連携された監視データがどのように見えているかを、サービスごとに一部抜粋してお見せしたいと思います。 API Gateway MackerelではリソースごとにAPI Gatewayを監視することができます。 API Gatewayでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – API Gateway – Mackerel ヘルプ グラフ名 メトリック 説明 Requests Count 指定期間内のAPIリクエストの合計数 Errors 4XXError クライアント側のエラー数 5XXError サーバー側のエラー数 Cache CacheHitCount APIキャッシュから提供されたリクエストの数 CacheMissCount バックエンドから提供されたリクエストの数 Latency Latency クライアントからリクエストを受け取ってからレスポンスを返すまでの時間 IntegrationLatency バックエンドにリクエストを中継してからレスポンスを受け取るまでの時間 今回は、この中のRequestsのグラフをお見せします。 こちらのグラフは、APIのリクエスト数を可視化したグラフになります。 このデータを見れば、どのタイミングでリクエスト数が増えているかを視覚的に確認することができます。 DynamoDB MackerelではDBリソースごとにをDynamoDBを監視することができます。 DynamoDBでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – DynamoDB – Mackerel ヘルプ グラフ名 メトリック 説明 ReadCapacityUnits ProvisionedReadCapacityUnits プロビジョンドされた読み取りキャパシティユニットの数 ConsumedReadCapacityUnits 読み取り操作で消費されたキャパシティユニットの数 WriteCapacityUnits ProvisionedWriteCapacityUnits プロビジョンドされた書き込みキャパシティユニットの数。 ConsumedWriteCapacityUnits 書き込み操作で消費されたキャパシティユニットの数 Requests ConditionalCheckFailedRequests 条件付き書き込みや更新操作が失敗したリクエストの数 SuccessfulRequestLatency 成功したリクエストのレイテンシー ThrottledRequests スロットルされたリクエストの総数 UserErrors ユーザーによって引き起こされたエラーの数 SystemErrors DynamoDB内部で発生したシステムエラーの数 ThrottleEvents ReadThrottleEvents 読み取り操作がスロットルされた回数 WriteThrottleEvents 書き込み操作がスロットルされた回数 TimeToLiveDeletedItemCount TimeToLiveDeletedItemCount TTL機能によって削除されたアイテムの数 SuccessfulRequestLatency SuccessfulRequestLatency 成功したリクエストのレイテンシー ReturnedItemCount ReturnedItemCount クエリやスキャン操作で返されたアイテムの数 RequestCount ReturnedItemCount クエリやスキャン操作で返されたアイテムの数 TransactionConflict TransactionConflict トランザクションの競合が発生した回数 今回は、この中のWriteCapacityUnitsグラフをお見せします。 こちらのグラフは、DynamoDBへの書き込みで消費されたキャパシティユニット数を示したグラフになっています。 このデータを見ることで、キャパシティを超えるような書き込みが行われていないかを視覚的に確認することができます。 Lambda Mackerelでは関数単位ごとにLambdaを監視することができます。 Lambdaでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – Lambda – Mackerel ヘルプ グラフ名 メトリック 説明 Count Invocations 関数が呼び出された回数 Errors 関数の実行中に発生したエラーの数 DeadLetterErrors デッドレターキューへの送信失敗回数 Throttles スロットルされた呼び出しの数 Duration [ms] Duration 関数の実行時間 Iterator Age [ms] IteratorAge ストリームイベントの処理遅延時間   今回はエラーが分かりやすいようにCountグラフをお見せします。 こちらのグラフは、Lambdaの実行回数（invocations）とエラー回数（errors）を示したグラフになっています。 エラーをグラフ上に表示させるため、14:15頃から LambdaからDynamoDBへの書き込み権限ロールを一時的に削除しました 。 このデータを見れば、いつどのタイミングでエラーが発生し始めたのかを視覚的に確認することができます。 今回ご紹介したグラフはそれぞれ1つずつでしたが、かんたんなカスタムをすれば様々なグラフを作成することも可能です。 興味がある方はぜひ調べてみてください。 終わりに 記事の内容は以上になります。いかがでしたでしょうか。 今回初めてMackerelにて監視設定をいれたのですが、UIも直感的で操作しやすくスムーズに設定を入れることができました！ また、公式ドキュメントも豊富でしたので、疑問点や不明点を解決しやすいところも非常にやりやすかったです。 また、Amazon CloudWatchだと少し手間だと感じていましたが、 設定したいメトリクスを簡単に複数まとめて設定できる ところがMackerelの優れている点だと今回設定してみて感じました。 もう少しMackerelを触ってみようと思いますので、また何か気づきがありましたら記事を掲載します。 最後までお付き合いいただき、ありがとうございました。

はじめに 今回は今年の1月にリリースされたアクションプランという機能の説明と使い方を書いていきます。 アクションプランとは アクションプランとは、リスクのあるリソースが一覧化されており、そのリソースに対し最小限のアクションでリスク軽減をできるように調整された効果的な修復手順を提供し、クラウドリソースの保護に役立てることができます。 アクションプランの使い方 ここからはアクションプランの使い方について解説していきます。 アクションプラン担当者の割り振り Prisma Cloud コンソールにログインします。 このとき「System Admin」でログインしていることを確認します。 上のバーから「アクションプラン」を押下します。 以下画像のように遷移します。 各アクションプランには人を割り当てることもできます。 赤線部分の「Unassigned」部分を押下し、担当する人を選択することができます。 担当者を設定した後に「Assigned to me」を押下する自分がどのアクションプランを担当するか確認することができます。 フィルターの「譲受人」の部分でほかの人が担当するアクションプランを確認することもできます。 逆に担当者が割り当てられていないものは「Unassigned Action Plans」から確認することができます。   アクションプランを解決する場合 Prisma Cloud コンソールにログインします。 このとき「System Admin」でログインしていることを確認します。 上のバーから「アクションプラン」を押下します。 以下画像のように遷移します。 対象のアクションプランを押下して展開すると、対象のアクションプランのプライマリアセットと概要、その影響がとがでてきます。 「プライマリアセット」はどのリソースが対象なのか表示されています。 「概要」は影響を受けるリソースの概要の説明が表示されています。 「影響」は攻撃パス、アラート、脆弱性が表示されています。 展開後、「修正方法」を押下すると解決方法の手順が出てくるので手順実行して修正完了です。 ※修正方法に記載がありますが、「大規模な言語モデルやその他の生成AIを活用する場合があり、エラーが含まれる場合があります。」ということなので注意が必要です さいごに アクションプランを使用して簡単にクラウドリソースのリスクを減らせるようになったのでとても良い機能だと思います。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 CSPM ｜ Smart One Cloud Security® Powered by Prisma Cloud from Palo Alto Networks ｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

社内開催の AWS GameDay に参加してきました。AWSのワークショップ形式のイベントは初参加です！ 興味はありましたが、普段の案件はWeb/APのインフラ構築案件が多く、使うサービスややり方がほぼ固定で、 参加したは良いけど全然出来なかったらどうしよう、知らないサービスばっかりだったらどうしようと思い、尻込みしていました。 今回社内メンバーのみ、初心者向けの難易度ということで、これを逃したら二度と参加出来る気がしないと思い参加してみました。 自分について 普段はクラウドのインフラ構築案件をしています。 最近はGoogle CloudやAzure案件をやっていますが、5年ほどAWS案件をやっていました。 リーダとして管理や調整が多くなってきており、実際にコードを書いたり画面を触ってどうするみたいなところは時間が取れなくなってきています。 AWS re:Invent 等のスライドを見るようなものには何度か参加したことがありますが、ワークショップ形式は未経験です。 資格はAWS　SAP、DOP、SCSを所有しています。   GameDay 概要 実施内容の詳細は公開NGとのことだったのでざっくりとした内容のみです。詳細は実際に参加する際のお楽しみに！とのことでした。 今回は社内のみの個人申し込みで運営の方が3-4人のチームを組んでくれました。 チームでAWS上に作られた仮のシステムで発生している様々な問題を解消していきます。 解消した内容に応じて決められたポイントが入り、その合計点で争うチーム戦です。 問題はある程度道筋を立てられるような流れになっていました。問題文を読んで原因を考え、調査して問題解決を目指していきます。   良かった点 普段の業務ではやらないやり方や使わないサービスの問題もありました。資格勉強で文字しか見ていないようなものを実際に触ってみることが出来てよかったです。 資格取得時に「なんとなくサービスは知っている、そういうことが出来ることは知っている」という知識も意外と役に立ちます。 メンバーによって得意不得意がある中で、「この問題を解きます」「ここどうする？？？」といった会話をして取り組む問題を決めたりサポートをするところがチームでやっている感があり楽しかったです。 単純に楽しい。私は自分責ではないトラブルを対応するのが大好きなので、今回のGameDayはすごく楽しかったです。   気になった点 初参加なのもあり、楽しかったのであまり気になる点はありませんでしたが 一点だけ申し込み前の葛藤がネックになるのかなあと思いました。 申込時の難易度が不明 自分のレベルと取り組む問題のレベル感がなかなか分かりにくいと思いました。私も今回始まるまでずっとドキドキしていました。 意外と何とかなったのと、いくら悩んでも参加するまでやっぱり分からないのでとりあえず一度参加してみるのがよいと思いました。 今回はアプリ開発レベルのプログラミング知識は不要で、インフラで多少スクリプトの経験があるようなレベル感で十分でした。   ちょっとしたコツ 問題文はよく読むこと！ どういうサービスを使うのか、既に用意済みのリソースは何か、作り方に指定は無いか 解くためのヒントが問題文にもあります。 なんでクリアにならないんだろうか？と思ったときに問題文をゆっくり読んでみたらすぐ解決みたいなこともありました。   感想 今回なんとチームの順位が2位でした。4人チームが多い中、3人チームだったのにすごい！ 自分が担当した問題の解決順はそこまで早くなかったのですが、他の方がめちゃ早で凄かったです。 知識としては知っているが、いざやってみると細かいやり方が分からない、勘違いをしていたといった点にも気づけました。 是非次は社外イベント等含めワークショップ形式のものに参加してみたいと思います！ 2位賞品＆参加賞としてAWS保冷バッグ＆ステッカーもらいました！

今回は、Prisma CloudのInvestigate機能を利用して、特定の条件に一致するリソースを検索する方法を解説していきます。 Prisma Cloud の Investigate（調査）機能 Prisma CloudのInvestigate（調査）機能を使用すると、シンプルで直感的なインターフェースでクエリを発行することができ、要件にあわせた検索をすることが可能です。Prisma Cloudで発行されるクエリはRQLと呼ばれ、Prisma Cloud独自のものとなっています。 検索方法は、大きく分けると以下の３つがあります。 ①　探したい条件を入力すると表示されるAI支援の提案からクエリを選択して検索する ②　クエリの条件をコンソール画面に表示されるフィルター機能で指定して検索する ③　検索欄にRQL文を直接入力して検索する 今回は上記３つの方法をそれぞれ説明していきます。   検索してみる 今回は分かりやすい例として、「パブリックIPを持っているEC2」をそれぞれの方法で検索してみたいと思います。 AI支援を利用した検索 Prisma Cloudコンソールの調査タブを表示すると、右側に「AI支援が有効」と表示されている検索欄（以下画像参照）が出てきます。 ここに「パブリックIPを持っているEC2」と入力してみます。 すると以下のように、AIによって入力内容に当てはまりそうなクエリが選択肢として表示されてきます。 「AWS EC2 instance is assigned with public IP_RL」という名前のクエリが今回検索したい内容に一致しそうなのでクリックすると、自動でRQL文が入力され、接続しているクラウドアカウント上に存在するパブリックIPを持ったEC2の一覧が表示されます。   フィルタ機能を利用した検索 Prisma Cloudコンソールの調査タブを表示すると、「＋クエリの種類を選択してください」というフィルターが表示されます。クエリには以下のような種類があり、その中から要件に当てはまるものを選択します。 クエリタイプ 概要 RQL文の形式 サポートしているモード アセット 包括的なセキュリティコンテキストを含むすべてのクラウドアセットを表示 ー シンプル 設定 クラウド API と JSON ルールに基づいて構成ファイルを検索 “config from cloud.resource where”から始まる シンプル・上級 脆弱性 お使いの環境内で発見された主な脆弱性を調査 ー シンプル ネットワーク設定 ネットワークパスを探索し、インターネットに公開されているアセットを特定 config from network where”から始まる 上級 ネットワークフローログ ネットワークフローログを調査して、インシデントや脅威の検出と調査を行う network from vpc.flow_record where”から始まる 上級 監査イベント 調査とフォレンジックのために監査ログを探索 event from cloud.audit_logs where”から始まる 上級 アプリケーションアセット ソフトウェアデリバリーチェーンとエンジニアリングのアタックサーフェスを調査 ー シンプル 許可(IAM) 取り込まれた IAM ポリシーに基づいてネット リソースのアクセス許可を表示 “config from iam where”から始まる 上級 今回は「パブリックIPを持っている」という”設定”に当てはまるEC2を検索したいので、「設定」を選択します。 検索対象とする期間を選びます。「＋追加」をクリックするとフィルタ条件を追加できます。 今回はEC2の設定情報(パブリックIPを持っているかどうか)を条件にしたいので、EC2インスタンスの情報を参照するAPIを指定します。 条件とする詳細な設定値は「JSONルール」フィルターを利用して指定していきます。 JSONルールを選択すると以下のように実際のJSON形式で設定項目が表示されるので、条件にしたい設定項目をクリックします。今回はパブリックIPの値が入る項目をクリックしました。 指定した項目がどのようになっていたら検知するかを指定します。 今回は「publicIP」の項目が存在する＝パブリックIPを持っている※ということを検知の条件にしたいので、「exists」を選択しました。 その他の選択肢については、Prisma Cloudの公式ドキュメント（ RQL演算子 ）を参照ください。 ※パブリックIPがないEC2のJSONにはそもそも「publicIP」の項目がありません 条件を指定できたら「検索」をクリックします。パブリックIPを持ったEC2の一覧が表示されます。   RQL文を直接編集して検索 フィルタ機能を利用した検索の説明で紹介したクエリタイプで、サポートされているモードに「上級」が含まれているクエリタイプの場合は、検索欄にRQL文を直接入力して検索することができます。 「設定」クエリタイプは「上級」モードをサポートしているので実際に試してみます。 PrismaCloudコンソールの「調査」タブを表示し、「＋クエリの種類を選択してください」をクリックして「設定」を選択します。 すると、右側に「シンプル」と「上級」を選択できる箇所が出てくるので、「上級」を選択します。 「config from～」から始まるRQL文を入力できる欄が出てきたので、以降のRQL文を入力していきます。 直接テキストを入力していくことも可能ですし、入力しようとすると選択肢が表示されるのでそこから選択してRQLを作成することも可能です。 RQL文が文法的に問題なく検索できる状態まで入力すると、RQLの左横にあるアイコンが緑色に変わります。 緑色になっていることを確認して「検索」をクリックします。 パブリックIPを持ったEC2の一覧が表示されます。   まとめ Prisma CloudのInvestigate（調査）機能を利用して検索をかける方法を3つご紹介しました。調査機能を利用することで、特定の条件に一致するリソースの一覧を簡単に作成できます。また、Prisma Cloudのポリシーはクエリ(RQL)を利用しているため、個々の環境の要件に合わせたカスタムポリシー作成する際にも参考になるかと思います。調査機能を有効活用して、セキュリティとコンプライアンスの強化に役立てましょう。 今後も、Prisma Cloud の活用方法について実用的な情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

SCSKの畑です。 2個前のエントリ で少し言及した通り、外部公開されるサービスの AWS WAF 設定でハマった話について記載します。 アーキテクチャ図 いつものやつです。今回は AWS WAF 設定に関連する内容ということで、対象は以下構成において外部からアクセス可能なサービスとなる、Amazon CloudFront、Amazon Cognito、AWS AppSync の3つです。   背景 さて、その 2個前のエントリ において、お客さんの環境ポリシーにより CloudFront に AWS WAF を設定する必要があったことを取り上げました。本アプリケーションはインターネット上に公開せず、アクセスできるネットワーク/IP アドレスのレンジを限定する必要があったためですが、アーキテクチャ図の通り Cognito ユーザプール及び AppSync の GraphQL API エンドポイントについても同様にクライアント端末からアクセスすることになるため、AWS WAF を設定する必要がありました。 それらのサービスについても外部からアクセスしてくるのは同じようにクライアント端末の属するネットワークであるため、CloudFront と同じような AWS WAF 設定をすれば良いと考え、お客さんにその旨依頼していたのですが・・   エラー発生（AppSync） お客さんの AWS 環境にアプリケーション一式を移行して動作確認を行っていたところ、バックエンド用 Lambda 処理を伴うクライアント処理時に以下のようなエラーが出力されました。（汎用エラー表示用コンポーネント上での扱いから JSON 形式です） { message: 'Connection failed: {"errors":[{"errorType":"WAFForbiddenException","message":"403 Forbidden" } クライアント端末上のアプリケーションから Lambda を介さない AppSync API は実行できていたため当初はちょっと戸惑ったものの、errorType の通り WAF でアクセス拒否されていることは分かったので、先述の通りクライアント端末以外からのアクセスを許可していない WAF 設定が怪しいことにすぐ思い至りました。確かに Lambda も クライアント端末上のアプリケーションも、AppSync の GraphQL API エンドポイントにアクセスする立場は同じなので、バックエンド用 Lambda についてもクライアント端末と同様に AWS WAF でのアクセス許可が必要なのではないか？という（その時点での）推測です。 バックエンド用 Lambda がエラーで正常動作しない以上、アプリケーションの移行や動作確認も進まないことと同義であるため、いの一番に対応しました。解決策については Cognito 側と全く同じなので後述します。   エラー発生（Cognito ユーザプール） 一方、Cognito ユーザプールについては、バックエンド用 Lambda から boto3 経由でアクセスする処理が正常に動作していたこと、アプリケーションの一連の動作確認でもユーザ認証部分は特に問題がなかったことの2点から、当初はあまり深く理由を考えないまま大丈夫なのかな？と考えていたのですが・・ たまたま違う日に Web ブラウザ上で開いているアプリケーション（ログイン中）をリロードしたところ、TOP ページにリダイレクトしてしまう事象が発生しました。弊社の AWS 環境では事象が再現しなかったためお客さんの AWS 環境の問題と考え、当初は CloudFront や AWS WAF の設定あたりに問題があると考えたのですが、特に原因となるような設定はありませんでした。また、ブラウザのコンソール上にも特にエラーメッセージは表示されていませんでした。 そこで改めて TOP ページへのリダイレクト履歴を Web ブラウザから追いかけたところ （リロードした時点のページ）　⇒　/login（ログイン後の初期処理ページ）　⇒　/（TOPページ） という順番でリダイレクトしていることが分かりました。アプリケーション側のルーティングロジックの詳細は 過去のエントリ で記載していますが、簡単に整理すると /login へのリダイレクト：　Cognito ユーザ未認証の場合のリダイレクトパターン / へのリダイレクト：　Cognito ユーザ認証済みのリダイレクトパターン となります。 つまり、上記のルーティングロジックに従うと、リロードした時点では Cognito ユーザ未認証と判定されているものの、Cognito ユーザ認証自体は完了しているため / へリダイレクトされる時点では Cognito ユーザ認証済みと判定されていることになります。Nuxt3 によるルーティングはサーバ側でも処理されるため、フロントエンド側の Lambda で Cognito ユーザ未認証とみなされているのではないかと推測しました。そこで、アプリケーションをデプロイした CloudFront  配下のフロントエンド用 Lambda のログを CloudWatch から見てみると・・ 2025-02-18T06:41:20.957Z  9dd22dc5-039f-45ee-86f6-b3ce9230ec0a  INFO  ForbiddenException: Request not allowed due to WAF block.   at file:///var/task/.output/server/node_modules/@aws-amplify/auth/dist/esm/foundation/factories/serviceClients/cognitoIdentityProvider/shared/serde/createUserPoolDeserializer.mjs:11:15   at process.processTicksAndRejections (node:internal/process/task_queues:105:5)   at async fetchUserAttributes (file:///var/task/.output/server/node_modules/@aws-amplify/auth/dist/esm/providers/cognito/apis/internal/fetchUserAttributes.mjs:31:32)   at async runWithAmplifyServerContext (file:///var/task/.output/server/node_modules/aws-amplify/dist/esm/adapter-core/runWithAmplifyServerContext.mjs:20:24)   at async useUserInfo (file:///var/task/.output/server/chunks/build/server.mjs:7155:26)   at async file:///var/task/.output/server/chunks/build/server.mjs:7526:113   at async Object.callAsync (file:///var/task/.output/server/chunks/nitro/nitro.mjs:5850:16)   at async file:///var/task/.output/server/chunks/build/server.mjs:7733:26 { underlyingError: undefined, recoverySuggestion: undefined, constructor: [class AuthError extends AmplifyError] } 1行目にそのものズバリなメッセージ「ForbiddenException: Request not allowed due to WAF block.」が出ている通り、フロントエンド側の Lambda から Cognito ユーザプールへのアクセスが WAF によりブロックされていたことが分かりました。 過去のエントリ に記載している middleware のコード通り、Cognito ユーザ認証されない場合も今回のように WAF でブロックされた場合も同じように例外を catch して /login にリダイレクトしているので、このような挙動になったということになります。 余談ですが、この原因の切り分けもといデバッグにはそこそこ時間を要しました。フロントエンド側 Lambda の CloudWatchLog を見なければいけないというところに思考が至るまでに時間がかかってしまったのが原因です。 普段 Nuxt3 の開発をローカルで実施している時はフレームワーク側が気を利かせてくれて、ローカルで立てている開発用サーバ側のログも Web ブラウザのコンソールで出してくれたりするんですよね。しばらくその感覚でいたので、本来 /login にリダイレクトした際に上記のようなエラーが出ると思っていたのが出なかったこともあり、このロジック以外でリダイレクトしてしまうようなことがあり得るのか？みたいなところに思考が向いてしまっていました。その結果、CloudFront なり AWS WAF の設定あたりを疑うところから始めてしまったという・・ なお、Cognito ユーザの認証処理自体が正常に実施されていた理由もシンプルで、クライアント側の処理だったためです。そもそも、URL を叩いて表示されたログイン画面にユーザ/パスワードを入力してログインしようとしている時点で、クライアント側の処理であることは自明ですね。。また、実装の都合上他の AppSync API を叩くような処理（＝Cognito ユーザ認証が必要な処理）は基本的にほぼクライアント側で明示的に実行するようにしているため、本事象の影響は出ていませんでした。このあたりは Nuxt3 で Universal Rendering (Server-Side Rendering) を使用しているが故の内容と思います。 ということで、こちらも後述する解決策により対応したのですが・・納得できない部分が残りました。   エラー内容の深掘（AWS サポート問い合わせ） というのも、先般の通りバックエンドの Lambda 関数から boto3 経由で Cognito ユーザプールにアクセスする処理は元々問題なく動作していたためです。AppSync については、バックエンドの Lambda 関数からも実質的にアプリケーションからのアクセスと同じように GraphQL API を叩くような実装となっており、boto3 は使用していなかった（使えなかった）ため同じように AWS WAF にブロックされることも納得できたのですが、では boto3 経由のアクセスが AWS WAF にブロックされないのは何故なのか？ ということで、この点を AWS サポートに問い合わせてみたところ、実に明快な回答を頂きました。というかドキュメントをもうちょっと読んでから問い合わせれば良かったと思ったくらいには明確に書いてあったので、少なからず申し訳ない気分になりましたが・・   Cognito ユーザプールの場合 AWS WAF ウェブ ACL とユーザープールの関連付け - Amazon Cognito AWS WAF ウェブ ACL を Amazon Cognito ユーザープールに関連付けることができます。ウェブ ACL は不要な HTTPS リクエストをブロックしてログに記録できます。 docs.aws.amazon.com 上記 URL に記載の通り、正に今回の事象を端的に説明できる内容でした。 AWS 認証情報による認証を不要とするパブリックなユーザープール API へのリクエストに対しては適用される クライアント端末やフロントエンド用 Lambda で Cognito 認証情報を扱うような処理に該当 AWS 認証情報による認証が必要なユーザープール API へのリクエストに対しては適用されない バックエンド用 Lambda から boto3 を叩くような処理に該当 確かに理屈というか考え方としても納得できるところで、AWS 認証情報による認証が必要な API については認証情報の有無がそのままアクセス制限となりますし、アプリケーションのログイン処理においてはその時点で AWS 認証情報は持たない（ログイン後に Cognito 経由で付与される）以上 API としてはパブリックとすべきであり、その上でアクセス制限をしたい場合の機能として WAF が適用できるというように理解できました。 また、先述したような「boto3 経由のアクセスについて許可されている」という表現ももちろん間違っており、バックエンド用の Lambda において boto3 経由で実行していたのが AWS 認証情報による認証が必要なユーザープール API へのリクエストのみであったため、結果的にそのような挙動になっていたというのが実態でした。これまでのエントリやアーキテクチャ図に記載の通り、バックエンド用 Lambda は AppSync 経由で実行される想定のため、Lambda 内で Cognito の認証情報を直接扱う必要がないことから必然的にそのような実装になったとも言えるかもしれません。   AppSync の場合 AWS WAF を使用して AWS AppSync API を保護する - AWS AppSync GraphQL AWS WAFウェブ ACL を作成し、AppSync API に関連付けて、攻撃から保護する方法について説明します。 docs.aws.amazon.com Welcome - AWS AppSync AWS AppSync provides API actions for creating and interacting with data sources using GraphQL from your application. docs.aws.amazon.com こちらも上記 URL に記載がありましたが、Cognito ユーザプールの場合とは少し考え方が異なるようでした。 AppSync にて作成された GraphQL API に WAF が適用されている場合、同 API へのリクエストに対して一律で WAF が適用される 2つ目 の URL に記載されている API へのリクエストについては WAF は適用されない 考え方としてはシンプルで、GraphQL を含む AppSync API 自体の管理操作自体には WAF が適用されず、作成した AppSync API を叩くような操作については WAF が適用されるというように理解できました。逆に言うと、バックエンド用 Lambda の実行ロールに appsync:GraphQL が付与され対象の GraphQL API を実行できる権限があっても、Cognito の場合と異なり GraphQL API へのアクセスである以上 WAF が適用されるため、先述した通りの挙動となったということですね。作成した GraphQL API のエンドポイント URL が明示的に払い出されることも踏まえ、直感的な仕様だと感じました。 ちなみに気になったのですが、boto3 に AppSync で作成した API を叩くような機能がないのは何故なんでしょうね？主としてフロントエンドを含むアプリケーションから実行される以上（何となく boto3 ＝管理用のライブラリというイメージがあったこともあり）boto3 の用途にそぐわないからかなと勝手に想像してたのですが、一方で Cognito ユーザプールについてはちゃんとユーザ認証機能あるんですよね。ん？機能としては同じような文脈というか用途じゃないですか？という。 Lambda (Python) から AppSync で作成した API を叩くのに requests パッケージなどが必要となるのですが、Lambda の 標準 Python ランタイムには含まれておらず、レイヤー経由でインポートしないといけなかったりして手間なので、boto3 経由で実行できるようにしても良いんじゃないかと思うんですけど需要がないんですかね？確かにフロントエンドとしての需要は少ないかもですが・・ AppSync - Boto3 1.36.26 documentation boto3.amazonaws.com   解決策 ということで、Lambda 関数から AppSync/Cognito の API エンドポイントを叩きに行く際の IP アドレスについても許可するよう、AppSync 及び Cognito ユーザプールの AWS WAF 設定をお客さんに修正頂いてクローズと相成りました・・が、お気づきの方もいると思いますが、この解決策が取れるかどうかは Lambda 関数がどこに構成されているかに依存します。デフォルトだと VPC 外（AWS が管理しているネットワーク上）に構成される以上 IP アドレスは不定になると思われ、WAF で指定できない可能性がありました。 AWS の IP アドレスレンジは下記 URL の通り JSON 情報として取得できるようですので、Lambda のエンドポイント FQDN を解決した際の IP アドレスがどのレンジ内のものかを突合して、サービス単位での IP アドレスレンジを導入するなどのテクニックがあるようです。ただ、当然ながら IP アドレスのレンジが変更される場合もあるため、静的な AWS WAF 設定として適用することは運用上難しかったものと思います。 AWS IP アドレスの範囲 - Amazon Virtual Private Cloud ip-ranges.json ファイルで、公開されている IP アドレス範囲を使用して、AWS サービスに出入りするトラフィックを特定し制御します。公開されている範囲の変更を経時的にモニタリングします。 docs.aws.amazon.com 幸いアーキテクチャ図の通り、お客さん AWS 環境において Lambda 関数はフロントエンド/バックエンド用どちらも VPC 内のプライベートサブネット上に構成されていたため、Lambda から AppSync/Cognito の API エンドポイントを叩きに行く際のソース IP アドレスとなる、NAT Gateway のパブリック IP アドレスを指定頂き、無事に解決できました。 なお、本アーキテクチャにおいて AppSync や Cognito ユーザプールの API を叩くためにはどちらも認証が必要であるため、エンドポイント自体がインターネットに公開されていても大きな問題ではなかったとは思います。ただ、お客さんの環境ポリシーに適合しなくなることも確かなので、その場合の調整コストなどを鑑みると今回のような構成を取れて良かったというのが正直なところです。   まとめ AppSync についてはアプリケーションの動作に直接的な影響があったこともあってすぐに対応できたのですが、そのタイミングで Cognito についてももう少し深掘りするべきだったというのが反省点です。元々の AWS WAF 導入時の観点が外部アクセスの制限にあったことが多少のエクスキューズにはなるかもしれませんが、構成上同じような事象が発生し得るということまでは気付いていただけに。。 また、AWS WAF を適用できる他のサービスについても、今回のようにリクエストの内容などにより適用される範囲が変わりそうだなと感じたので、もし次に触る機会があれば留意しておきたいと感じました。 本記事がどなたかの役に立てば幸いです。

概要 Azureの既存Prepaymentから新規Azureテナントのサブスクリプションを払い出してみました。 Microsoft Learnに記載されている手順を参照するだけですが、私が対応した際にアカウントやサブスクリプションの関連が理解が浅かったためつまづいたポイントや補足事項を残します。 この手順はいろいろなライセンス形態の中での一例でしかないため、正式な手順はライセンス販売企業様の案内に沿っていただければと思います。 登場するリソース 既存Prepaymentが紐づくテナントA(作成済み前提) テナントAで新規作成するアカウント所有者B 新規作成するテナントB テナントB上で新規作成するサブスクリプションB 用語等については以下公式資料を参照ください。 Microsoft Azure利用ガイド 手順、補足 １．テナントBを新規作成する。 下記URLから新規テナントBを作成する。 Microsoft 365 E3 (Teams なし)     ポイント1→本人確認のセキュリティチェックで電話番号を登録しSMS認証か音声通話認証を実施するのですが、弊社内からは下記のエラーとなりました。弊社プロキシが影響していることを想定し、弊社貸与のスマホのブラウザから実行したところエラーは解消しました。   2.テナントAでアカウントBを新規作成し有効化する。 ・アカウント所有者の登録（エンタープライズ管理者の操作） Azure portal での EA 課金管理 – Microsoft Cost Management | Microsoft Learn ポイント2→アカウントの追加の中で指定する[アカウント所有者のメール]で新規作成したテナントBで登録したユーザのユーザープリンシパル名を指定します。 ←   ポイント3→有効化後テナントBのアカウントのプロパティにテナントAの課金アカウント情報も表示されます。   3.テナントBでサブスクリプションBを新規作成する サブスクリプションの作成（上記操作で登録したアカウント所有者での操作） Enterprise Agreement サブスクリプションを作成する – Azure Cost Management + Billing | Microsoft Learn つまづきポイントは特にありませんでした。   以上、難しい手順はありませんが、それぞれの結び付けを理解していないとどのテナントでどの操作をすればよいかわかりませんでした。もし同じようなところでつまづいている方へこの情報が届けば幸いです。

こんにちは！SCSKの新人、黄です。 前回までの記事では、Rubrikの基本機能と、その強力なランサムウェア対策について詳しくご紹介しました。多くの方に興味を持っていただき、とても嬉しかったです！ 「まだ読んでいない！」という方は、ぜひ以下の記事をご覧ください。 Rubrikとは？クラウド＆オンプレにも対応する次世代バックアップ管理を紹介 – TechHarmony Rubrikのランサムウェア対策：仕組みとシミュレーションで確認 – TechHarmony さて、今回ご紹介するのは、Rubrikのもう一つの注目機能、「 Rubrik Sensitive Data Discovery 」です。 名前の通り、機密データを検知し、適切に管理できる機能です。 興味がある方は、ぜひ詳しく見ていきましょう！ Sensitive Data Discovery とは？ 「どこに機密情報があるのか分からない…」 「気づかないうちに重要なデータが公開されていたらどうしよう…」 「膨大なデータの中から機密データを手動で探すのは大変…」 上記のような悩みを解消し、データの安全性を高めるために役立つのが Rubrik Sensitive Data Discovery です。 Sensitive Data Discoveryは、設定したルールに基づいてバックアップデータをスキャンし、機密データを自動的に検出する機能です。 特に以下の 3 つのポイントがメリットです。 バックアップデータを活用したスキャン 通常の業務データに影響を与えず、バックアップデータを活用して機密情報をスキャンできます。 これにより、負担なくデータの安全性を確保できます。 自動検出とリスク分類 設定されたルールにより、氏名やクレジットカード番号などの機密データを自動で検出し、リスクレベルを分類できます 手動での確認作業を減らし、効率的な管理が可能です。 直感的なレポート機能 分析結果はダッシュボードで可視化され、どこにリスクがあるのか一目で把握できます。 これにより、迅速な対策が可能になります。 実際に使ってみた！Sensitive Data Discovery シミュレーション ここまで、Sensitive Data Discoveryについてご紹介してきましたが、 「実際の運用イメージがわからない！」  と感じる方もいらっしゃるのではないでしょうか？ そこで今回は、 VMware vSphere上の仮想マシン（VM） を例に、Sensitive Data Discovery を実際に動かすシミュレーションを解説します！ このシミュレーションを通じて、どのように機密データが検出され、管理されるのかを具体的にイメージしていただけると思います。 vSphere と RSC（Rubrik Security Cloud） の連携の仕組み 参考資料： vSphere仮想マシン RSCは、 VMware vSphere 環境  とシームレスに連携し、仮想マシン（VM）のデータ保護と管理を実現します。 vCenter Server 接続 RSC は vCenter Server と接続し、VM を自動検出・管理します。 複数クラスター管理 1つの vCenter を複数の Rubrik クラスターで管理可能。VM の保護範囲を柔軟に設定できます。 SLA ドメイン適用 VM に SLA ドメイン（バックアップポリシー）を適用し、自動保護を実現 シミュレーションの全体像 Sensitive Data Discovery を使ったシミュレーションは、以下のような流れで進めてみました。 ステップ1 Sensitive Data Discovery の基本設定 アナライザーとポリシーの作成 ステップ2 初期分析 既存の全バックアップデータを自動スキャン ステップ3 テストデータの準備 機密データあり/なしのファイルを作成 ステップ4 Sensitive Data Discovery実行 機密データの検出 ステップ5 結果確認 ダッシュボードで結果を可視化 ステップ 1: Sensitive Data Discovery の基本設定 まず、RSC コンソールの  「Data Security Posture」  メニューを選択し、Sensitive Data Discovery の設定画面に移動します。 ここでは、Sensitive Data Discovery の  「脳」  とも言える、 アナライザー  と   ポリシー の2つの設定を行います。これらの設定を行うことで、Rubrik が機密データを自動的に検出し、管理できるようになります。 アナライザーの設定 アナライザーは、機密データを検出するためのルールセットです。 Rubrik では、以下の2種類のアナライザーを利用できます。 事前定義済みアナライザー 62種類 のテンプレートから選択可能です。 例えば、 IPアドレス  や  Google APIキー  など、一般的な機密データのパターンを簡単に検出できます。 カスタムアナライザー 独自のルールを追加可能です。特定のキーワードやパターンに基づいて、柔軟に機密データを定義できます。 今回は、 「社外秘」または「部外秘」 というキーワードを含むファイルを検出するカスタムアナライザーを作成しました。 ポリシーの設定 ポリシーは、アナライザーをどのオブジェクトに適用するかを指定します。 これにより、特定の環境に特化したSensitive Data Discoveryが可能になります。 具体的な操作として、 まずポリシーに含まれるアナライザーを確認し、ポリシーの名称を設定します。 今回使用するのはカスタムで作成した 「Japan Confidential」 アナライザーです。 なお、1つのポリシーに複数のアナライザーを含めることも可能です。 次に、分析対象のオブジェクトを指定します。 ここで特に重要なのは、 SLA ドメインルールが設定されているオブジェクトのみが機密データ分析の対象になる という点です。 SLAドメインルールとは、 「このデータをどのように保護するか」を決めるルール のことです。例えば、「毎日バックアップを取る」「1年間保存する」といった設定が含まれます。このルールが適用されていないオブジェクトは分析できないため、事前に設定を確認しておく必要があります。 Rubrik は下図のような 2 つの方法を提供しており、 オブジェクトタイプ別： 特定のオブジェクトを選択する方法 クラスター別： Rubrik CDM を指定し、CDM 配下のすべての SLA ドメインを持つオブジェクトを分析する方法 今回は、特定の vSphere の仮想マシンを分析するため、1 つ目の「 オブジェクトタイプ別 」を選択します。 以下の図のように、Rubrik は複数のプラットフォームと連携しており、異なる環境に存在するオブジェクトも RSC（Rubrik Security Cloud）を通じて一元管理できます。これも Rubrik の大きな利点の一つです。 今回としては、vSphereプラットフォームをクリックして、特定のVMを選択します。 ステップ 2: 初期分析 ポリシー設定後、Rubrik は 自動的に 初期分析を行います。 初期分析では、対象となるVMのすべてのバックアップ世代をスキャンします。 つまり、今後取得するバックアップデータだけでなく、 Sensitive Data Discovery機能を利用する前に取得したバックアップデータも含めて 機密データの有無を分析することも可能です。 ステップ 3: テストデータの準備 検出精度を検証するため、VM 内に以下の2種類のファイルを作成： 機密データあり ：「社外秘」を含むmail.txtファイル 機密データなし ：mail_normal.txtファイル   ステップ 4: Sensitive Data Discovery実行 Rubrik Sensitive Data Discovery は手動で実行する必要がありません。 ポリシーとアナライザーを設定するだけで、対象のオブジェクトがバックアップデータを取得するたびに自動的に実行されます。 Rubrik の公式説明によると、最大 24 時間以内にスキャンが完了するとされていますが、今回のシミュレーションでは バックアップ取得後、約 30 分で機密データの検知結果が反映 されました。 それでは、結果を一緒に確認してみましょう！ ステップ 5: 結果確認 下図のように、 Data Security Posture ダッシュボードで簡単に確認可能です。 Sensitive Data Discovery が vSphere VM 内の機密データを適切に検出し、一つの中リスクのファイル （mail.txt） が存在することが判明しました。 なぜ中リスクなのかというと、設定したアナライザー「Japan Confidential」のリスク評価を中リスクに指定しているためです。 メニューの「 機密データ 」をクリックすると、下図に示すように、 どの VM のどのファイルに機密情報が含まれているのかを追跡でき、適切な対応 が可能になります。 さらに、下図のように、Sensitive Data Discovery はすべてのバックアップ世代をスキャンするため、 どの時点のバックアップデータから機密データが含まれるようになったのか特定 することも可能です。 最後に Rubrik Sensitive Data Discovery を使えば、機密データの管理がグッと楽になります。 ✔ 機密データを自動で検出し、可視化 ✔ バックアップデータを活用し、通常業務に影響を与えない ✔ ポリシー設定だけで継続的に監視可能 実際に試してみると、どこにどんな機密情報があるのか一目で分かるので、データ管理の負担を減らせます。 興味がある方がいらっしゃいましたら、ぜひぜひ 機密データの監視 | Rubrik をご覧ください。 また、Rubrik Sensitive Data Discovery は、今回のシミュレーションで使用したテキストファイルだけでなく、PDF、Excel、Word など多様なファイル形式に対応しています。詳しくは サポートされているファイル形式 をご確認ください。 ここまでご覧いただき、ありがとうございました。 今後も、Rubrik の便利な機能について紹介していく予定です。それでは、また次回！

もしも、映画史に残る感動的な場面を、最新のAI技術で蘇らせることができたら…？ こんにちは、佐藤です。 皆さんは、 名作映画 といわれたら何を思い浮かべますか？ 私は最近初めて映画 『タイタニック』 を見たのですが、やはり名作といわれるだけありますね…。 結末を知っていても楽しめるのはまさに不朽の名作といわれる所以だと感じました。 さて、タイタニックの中で最も印象的なシーンの一つが、ジャックとローズが船首で腕を広げるシーンですよね。 今回は、 Amazon BedrockでLuma AI の「Ray2」モデルを使い、この有名なワンシーンを再現できるのか―― というお話です。 Ray2モデルとは？ 2025年1月23日、AWSは Luma AI の新しい動画生成 AI モデル「Ray2」 が Amazon Bedrock で利用できるようになった と発表しました（参考　 https://aws.amazon.com/jp/about-aws/whats-new/2025/01/luma-ais-ray2-visual-ai-model-amazon-bedrock/ ）。まずは簡単にLuma AIのRay2モデルについてご紹介しようと思います。 Ray2は、 Luma Labsが開発した最新の動画生成AIモデル です（ https://lumalabs.ai/ray ）。 前モデルであるRay1と比較して 処理能力が10倍に向上 しており、より滑らかで自然な動きを持つリアルな映像を生成できるのが大きな特徴です。また、従来のAI動画生成モデルであれば数分から数時間かかっていたレベルの動画生成を、 Ray2はわずか1分程度で作成可能 ということで大きな話題を呼びました。 現在はテキストプロンプトから動画生成をサポートしていますが、 今後は画像から動画生成や動画から動画への変換、また作成した動画の編集機能も実装予定 とのことで、これからの動向に目が離せないAIサービスですね。 テキストプロンプトから動画を生成 5秒または9秒のクリップを作成可能 高解像度（1080pのフルHD解像度もサポート）   BedrockでRay2を使ってみよう さて、さっそくBedrockでRay2モデルを使ってみましょう。 事前準備として行うセットアップもそこまで多くなく、この記事を見ながら簡単に設定することができると思います。 Ray2を使用するには、以下の準備が必要です。 Amazon Bedrockのアクセス権 AWSアカウント （無料枠で利用可能） 適切なIAMポリシー を持つユーザー Amazon S3バケット （生成された動画を保存するために必要）   BedrockでLuma AI Ray2を有効化する いきなりですがここで注意点！ マネジメントコンソールにログインしたらとりあえずBedrockにアクセスして…と言いたいところですが、まずはリージョンを オレゴンリージョン（us-west-2） に切り替えましょう！ 現在 Ray2はオレゴンリージョンのみのサポート となっているのでここで変更を忘れてしまうと、せっかくモチベがあるのにアクセスできない、なんてことも…。 リージョンを変更したらAmazon Bedrockにアクセスしてサイドバーをスクロールした一番下、 「モデルアクセス」からLuma AI – Ray2を有効化 していきましょう。 Luma AIのRay2のアクセスのステータスが 「リクエスト可能」 となっていると思いますので、その文字をクリック、アクセス権をリクエストしていきます。 数分待つと、このように 「アクセスが付与されました」 と表示されます。ここまでくれば準備はOK！  タイタニックの名シーンをAIで再現！ テキストプロンプトを考えてみる 今回の検証で最も大切な部分、テキストプロンプトを作成します。 試しにこんなプロンプトを作ってみました。 A young man and woman stand at the bow of a large ship. The woman has her arms outstretched and the man is holding her from behind. The ocean and sunset behind them. Cinematic, high quality. このプロンプトには、 登場人物（young man and woman） 、 場所（bow of a large ship） 、 ポーズ（arms outstretched, holding her） 、 背景（ocean and sunset） などを記載してみました。 正直に言うと、 この手の有名なシーンの再現度を上げるには裏技があるんです。 その方法はとっても簡単。文の末尾に 「inspired by Titanic」 と記載するだけです。 AIが認識できるタイトルであれば、そこに寄せるようなプロンプトを作成することで再現度を上げることが可能なんですが… 今回はせっかくなので、あえてタイタニックの名前を一切出さずに寄せてみましょう…！ Amazon Bedrockで動画を生成してみよう では早速動画を作成していきましょう。 まずはBedrockのホーム画面、 プレイグラウンドから「Image/Video」を選択 します。 続いてモデルの選択画面が表示されるので、カテゴリは 「Luma AI」 、モデルは 「Ray」 を選択して適用をクリックします。 （モデル名の表示はRayとなっていますが、v2と記載があれば今回取り上げているRay2モデルです！） また、この際に生成した動画を保存するためのS3バケットを作成しますが、以下のポップアップの「確認」をクリックすれば問題ないのでこのまま進めていきましょう。 動画の保存先であるS3バケットにも課金がされるので、長期間保存する必要がなければS3バケットは削除するようにしましょう。 ここまで完了したら、いよいよプロンプトの入力画面です。 設定画面からは 動画の画面比率や解像度（通常540pまたは720p）、長さ（5秒または9秒）など を指定することができます。 では、先ほど作成したプロンプトを入力して実行をクリックします。 あとは数分待つだけ。 生成が完了すると、動画が画面上に表示され、動画がS3バケットに保存されます。 4. AIの再現度はいかに…？ では、生成された動画のクオリティを確認していきましょう。 document.createElement('video'); https://blog.usize-tech.com/contents/uploads/2025/02/DC708E58D9DB1F8ED0BF309B87475B691580B466.mp4 結果：なんかちがう！！ 今回の結果をまとめるとこんな感じでしょうか… 船の上で男女がいる、ということは再現できている。 ジャックとローズらしき人物は表現されているが、服装があまりにラフすぎる… 背景の夕焼けと海の表現はかなりリアル！すごい！ 手を広げるってことは伝わっているけど、そういうことじゃない… 全体として、AIは「船首で男女が会いを深めるシーン」というコンセプトを認識できたものの、さすがに細部のディテールは表現できていなかったですね。 プロンプトの工夫や追加のパラメータ設定によって、より精度を上げることができそうです。   プロンプトを変えて再度挑戦！ さて、ここで終わってもいいのですがどうしても悔しいので、もう一度プロンプトを変えて挑戦してみました。 作成したプロンプト version2がこちら↓ A man wraps his arms around a woman from behind as she stands at the bow with her arms outstretched. The ocean and sunset behind them. Cinematic, high quality. 改善のポイント: より詳細なプロンプトを作成 （男性が後ろから女性を抱いている、女性が選手で手を広げているなど） 先ほどよかった「Cinematic, high quality」は継続 こうして作成されたリベンジ動画がこちら！ https://blog.usize-tech.com/contents/uploads/2025/02/AFF0A35CD8BEE3AF53EE36A38481F03BADF1387A.mp4 うーん、これもなんか違うかもしれないですね…笑 やはり日常的にする行動ではないこともあり、AIの学習データの中に手を広げる女性を後ろから男性が抱擁するというニュアンスが伝わりづらいのかもしれないですね…   6. まとめ 今回はAmazon BedrockのRay2を使って、映画『タイタニック』の有名なワンシーンをAIで再現してみました。 結果として、全体の雰囲気はある程度再現できましたが、細部の再現度にはまだ改善の余地がありました…。 学び プロンプトを工夫することで、自分の想像に近い映像を作ることが可能！ AIの学習データの中に少ないと思われるような動作は、なかなか再現しづらい…？ 生成された動画を素材として編集することで、より良い映像作品が作れるのでは…？   Ray2は簡単に動画を生成できるため、他の映画の名シーン再現や、オリジナル映像の作成にも応用可能です。 ぜひ、皆さんも試してみてください！    

SCSKの畑です。 以前のエントリ の続き・・ではないのですが、データメンテナンス機能に関する言及という観点は同じなのでその2としました。今回は、データメンテナンス機能の対象となる Redshift の特性を踏まえた上で、アプリケーションの実装において考慮する必要があったポイント及び機能について記載します。Redshift そのものというよりは、DWH の特性とある程度言い換えて良いかもしれません。   アーキテクチャ図 今回主に言及するのは Redshift のみですが、前回エントリと関連した内容を含むため一応載せておきます。   ポイント1. テーブル定義/データの更新チェック機能 以前のエントリ で説明した通り、テーブル定義/データのバージョン管理の要件があること、テーブル定義変更（＝DDL操作）についてはアプリケーション外部で実行されることの2点より、アプリケーション側からテーブル定義/データの更新をチェックできる必要がありました。 具体的には、S3 上に出力・配置される対象テーブルの定義/データファイルのハッシュ値を比較することで行っています。対象テーブルの定義/データのバージョン管理を S3 を使用して行っているため、最新のバージョンの定義/データと、チェック実施時の Redshift 上の定義/データを比較して、差異があれば Redshift 側に更新があったことが分かる仕組みです。 が、実はこれは苦肉の策でした。更新チェックを実施するために実質的に Redshift 上の対象テーブル定義/データの全量を取得しているに等しく、コストが大きいためです。通常、本アプリケーション上で対象テーブルを表示する際には、以下のようなロジックを実行しています。 対象テーブルの定義/データ更新をチェック Redshift 上のテーブルが更新されている場合は、更新チェックの際に S3 上に出力したファイルを最新バージョンとして更新 最新バージョンのファイルのテーブル定義/データをアプリケーション上で表示 このようなロジックとした理由はいくつかあるのですが、アプリケーションから対象テーブルを表示する際に毎回 Redshift から全量を取得せずに更新の有無だけをチェックし、更新がない場合はそのまま S3 からテーブル定義/データを取得するようにすることで、レスポンスの向上を狙いの一つとしていました。ところが、実際の挙動としては1.による更新チェックのタイミングで Redshift から毎回全量を取得しているに等しいため、その目論見が崩れてしまっています。逆に言うと、更新チェックはもっと少ないコストで実施できると考えていました。 1.による更新チェックを任意のタイミングで実行するようなロジック・画面とするというのが回避策の一つだと思うのですが、そうするとテーブル定義/データの整合性を担保する難易度が上がってしまうこともあり、現時点ではこのようなロジックとしています。 というところでようやく Redshift (DWH) の特性に関連した話になるのですが、、通常のデータベース (RDBMS) だと、このような情報はデータベース側の管理情報として管理されているものが多いです。例えば Oracle の場合は以下 URL の通り、テーブル定義やデータの更新日時についてもデータベース側の管理情報ビューとして管理されています。（後者は統計情報取得との兼ね合いもあるので単純な管理情報とは言い難い部分もありますが・・）後は同情報をアプリケーション側でも持っておいて、突き合わせれば簡単に更新チェックができます。 https://docs.oracle.com/cd/E82638_01/refrn/ALL_OBJECTS.html https://docs.oracle.com/cd/E82638_01/refrn/ALL_TAB_MODIFICATIONS.html 対して、Redshift のような DWH の場合、通常のデータベース (RDBMS) と比較してより大量のデータを扱う目的から、このような管理情報についてはオミットされているものも多いです。DWH におけるデータの保持方式や管理方式が RDBMS と異なること、より大量データを扱う以上管理情報を RDBMS の場合と同じように扱うコストが甚大になること、そもそもの DWH の用途を鑑みると想定されていない/必要とされないと製品・サービス側で判断されていること、などの理由が考えられますが、いずれにせよ Redshift ではこのような機能がなかったため、先述したような仕組みを実装する必要があったということです。唯一、以下 URL のビューが近しい情報を含んでいましたが、さすがにテーブル作成時刻のみだとちょっとどうしようもなかったですね・・ https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_SVV_TABLE_INFO.html Redshift は RDBMS である PostgreSQL をベースにしていることもあり、最初は PostgreSQL 側のビューなどから取得できるのでは？と淡い希望を抱いていたのですが、結論から言うとそもそも PostgreSQL 側でもそのような情報を取得するのには一工夫必要のようでした。Oracle は（良くも悪くも）高機能・多機能な RDBMS なので、それを基準に考えることの功罪があるかもしれません・・   ポイント2. データバリデーションチェック機能 データのメンテナンス・更新にあたり大事なポイントの1つがデータの整合性を保つことです。データの整合性と一口に言っても様々な観点があるかと思いますが、最も基本的な観点としては列定義や制約（NOT NULL/PK/UK/FK）などのテーブル定義に違反したデータが更新されないかどうかが挙げられると思います。もちろん、本案件事例でも要件に含まれていました。 通常のデータベース (RDBMS) であれば、基本的にデータベース側でバリデーションチェックが行われるため、これらのテーブル定義に違反したデータは更新できないようになっています。このため、ここで言及しているようなデータ整合性を担保するだけであればアプリケーション側での考慮は不要です。 では Redshift の場合はどうかという話ですが、以下 URL の通り NOT NULL 以外の制約は制約として機能しません。定義自体はできますがあくまでもクエリ実行時に Redshift 側で効率的にデータを処理するためのプラン（実行計画）を立てるための参考情報として扱われ、データ自体の制約としては機能しません。つまり、例えば PK 制約が定義されている列に対して重複した値を INSERT することが可能といったように、これらの制約に違反するようなデータを更新することができてしまいます。 テーブルの制約 - Amazon Redshift 一意性、プライマリキー、および外部キーの制約は情報提供のみを目的としており、Amazon Redshift によって強要されることはありません。ただし、プライマリキーと外部キーはプランニング時のヒントとして使用されます。アプリケーションの ... docs.aws.amazon.com 一意性、プライマリキー、および外部キーの制約は情報提供のみを目的としており、テーブルに値を入れるときに  Amazon Redshift によって強要されるわけではありません 。例えば、依存関係のあるテーブルにデータを挿入する場合、制約に違反していても挿入は成功します。ただし、プライマリキーと外部キーはプランニング時のヒントとして使用されます。アプリケーションの ETL プロセスまたは他の何らかのプロセスによってこれらのキーの整合性が強要される場合は、これらのキーを宣言する必要があります。 もちろん（さすがに）列定義に違反するデータは更新できません。以下 URL の通り暗黙の型変換により、意図していないデータ型に変換されて更新される可能性はあるかもしれませんが、このような挙動は（製品/サービスごとの差異はあるとしても） RDBMS でも考慮されるべき内容と思います。 データ型 - Amazon Redshift Amazon Redshift によってサポートされているデータベースデータ型を使用する際に従うべき規則について説明します。 docs.aws.amazon.com よって、これらの制約に対応するデータバリデーションチェック機能をアプリケーション側で実装する必要がありました。具体的には、バリデーションチェックに失敗した場合はデータの更新を許可せず、バリデーションに失敗した（制約に違反した）データを修正するように画面上で促すようなロジックを実装することで対応しました。 また、このような機能をアプリケーション側で実装する必要があったことから、Redshift 側でチェックしてくれる列定義や一部制約についても同様にアプリケーション側でチェックするようにしました。その方がデータ更新における一連のロジック/フローをシンプルにできることが理由です。Redshift 側でチェックするということは実際に Redshift に対して更新を試行する必要があり、更に試行後のエラー内容をアプリケーション側で解釈してデータバリデーションのエラー画面を出さないといけないことにもなります。データ更新時の承認フローなどとの兼ね合いも考えると、トータルでロジックがかなり複雑になってしまうと判断しました。 なお、このような機能をゼロから実装するとさすがに工数・コスト面で厳しくなることが想定されたので、テーブルのデータ表示や編集機能を司るライブラリ探しにおいてはデータバリデーションチェック機能についても気にしました。最終的には Tabulator というライブラリを使用したのですが、詳細（もとい紹介）はまた別のエントリのネタとさせて頂こうと思います。   まとめ 業務において Oracle を中心とした RDBMS を扱っている期間が長いこともあり、Redshift（もといおおよその DWH）と RDBMS の差異としてはある程度容易に思い浮かぶような内容ではありましたが、アプリケーション実装の観点からまとめておくことも大事と考えたので今回まとめてみました。実際、ポイント1については何となくできるだろう・・みたいにタカを括っていたところできずに、最終的に今の方式に辿り着くまであれこれ試行錯誤することになったりしたので。。このへんの感覚というか勘所はもう少し意識しないといけないかなと感じました。 本記事がどなたかの役に立てば幸いです。

AWS KMSの暗号化は、S3のデフォルト暗号化などで使われることが多いと思います。 オブジェクトをPutすると自動で暗号化されるため、**「実際にどんな処理が裏で動いているのか」**を意識していない方もいるのではないでしょうか？この記事ではS3を題材にしつつ、KMS暗号化の仕組みに焦点を当てて解説します。 「KMSで暗号化するから、Encryptの権限が必要です。」 これはありがちな誤解ですが、大体の場合は間違った理解です。なぜそうなのか？その理由を紐解いていきます。 CMKはどこにいる？ まずは鍵を作成しなければ始まりません。ここではカスタマーマスターキー(以下CMK)を対象鍵で作成するものとします。 キー作成はKMSのAPIである” kms:CreateKey ” が発行され、AWS管理下のどこかに対象鍵(以下CMK)が作成されます。 ここでまず頭に入れておくべきことがあります。 作成されたCMKはKMSから出てくることはありません。 このことはKMSの動きを理解する上で重要です。 作成したCMKで何らかのデータを暗号化・復号化する際は、CMKをKMSから取り出すのではなく、対象データをKMSに送って暗号化・復号化を依頼し、結果を送り返してもらう、という流れになります。 ここで次の疑問が沸いた人は鋭いです。 「でかいデータだと全部KMSに送らないといけないのでわ・・・・RDSとかEBSとかどうするの？ ^^;」 実際は暗号化したいデータをKMSに送ったりはしていません。「データを暗号化する鍵」をCMKで暗号化してやりとりすることでこの問題を回避しています。 KMS(CMK)が暗号化できる対象は4096Byteまでという制限があるため、そもそもでかいデータは暗号化できないのです。 GenerateDataKey 唐突ですが、KMSには” kms:GenerateDataKey “いうActionがあります。(この話題での最重要アクションです。) CMKを引数として実行し、以下の２つの文字列を返してきます。以下はAWS CLIで実行してみたものです。 $ aws kms generate-data-key --key-id arn:aws:kms:ap-northeast-1:999999999999:key/99999999-9999-9999-9999-999999999999 --key-spec AES_256 { "CiphertextBlob": "AQIDAHiF7qVe(略)", "Plaintext": "eS7mjjJQby2(略)", "KeyId": "arn:aws:kms:ap-northeast-1:999999999999:key/99999999-9999-9999-9999-999999999999" } “Plaintext”             単なるバイト列 “CiphertextBlob”    Plaintext を指定したCMKで暗号化したバイト列 + メタデータ KMSはGenerateDataKeyを受けると、内部でランダムな文字列を生成し(Plaintext)、それを指定されたCMKで暗号化し(CiphertextBlob)、その2つを返してくれます。 この”Plaintext” のことを データキー と言い、実際のデータの暗号化の鍵として使われます。(ファイルやらEBSやらRDSやら。。) ここでは重要な点が２つあります。 まず、データキーはKMSの外側に出てきているということ。 次にデータキーを用いた暗号化(Encrypt)は、 kmsのアクションではない 、ということ。(一般的な暗号化なのかな。AES？) また、CiphertextBlob のメタデータにはCMKの情報を含んでいます。つまり 暗号化されたデータキーは、 自分がどのCMKで暗号化されているのかを知っています 。このことはデータ復号化の時に大変重要になってきますので覚えておいてください。(また今度書くかも) データ暗号化の流れ 以上の内容をまとめまして、データ暗号化の流れは以下のようになります。例としてS3にPutする場合を示していますが、例えばEBSの暗号化の流れも同じようなものになります。       ユーザはKMSに対して、作成済みのCMKを指定してkms:GenerateDataKey を発行する。 CMKはデータキーとデータキーを暗号化したものを返す。 ここでCMKの役割は終わっています。       ユーザはデータキーを使ってデータを暗号化し、そのデータキーを廃棄 この暗号化はKMSの外側で行われています。       暗号化されたデータに暗号化されたデータキーを添えて、S3に保存 (エンベロープ暗号化、とか言ったりします。)         最後で データに暗号化されたデータキーを一緒にして保存している ことは覚えておきましょう。 「鍵とデータ一緒にして大丈夫なの？家のドアに鍵を貼り付けてるようなものでは？」とは思わないように。この場合、鍵自体が暗号化された状態ですので、このままでは使えません。CMKに復号化を依頼できる人だけがこのデータを復号できます。 以上のフローを見てわかるように、KMSに対してはkms:GenerateDataKeyだけしか実行していません。なのでデータ暗号化の際に必要な権限としては kms:GenerateDataKeyがあればよい 、ということになります。(kms:Encryptではなく！)   以上。データ暗号化の時の基本的な流れを説明してみました。 若干フローなどは単純化している個所もありますが、理解の助けになれば幸いです。

SCSKの畑です。 Amplify を使用したアプリケーション開発中に発生した事象の原因及び解決策について、Web 上にあまり情報がなかったことも含めて解決に少々手こずったので共有します。引き続き今回も小ネタです。   小ネタ本題 タイトルの繰り返しになるのですが、以下のようなスキーマを定義した際、Amplify codegen により生成された query にネストされた type が含まれなかったという事象が発生しました。ちなみに本スキーマは2つの Redshift テーブルの定義及びデータを差分比較結果を格納するためのもので、AddedRowsInfo/DeletedRowsInfo/UpdatedRowsInfo に差分のあった行情報がネストされて格納されます。 ちなみに、差分比較処理自体は素直に AppSync から Lambda リゾルバを使用して実現していますが、フロントエンド側での表示も含めてそこそこ苦労した部分なので、機会があれば別エントリとして書くかもしれません。 type DataDiffInfo { diff_summary: RSS3DiffStatus! added_rows_info: [AddedRowsInfo]! deleted_rows_info: [DeletedRowsInfo]! updated_rows_info: [UpdatedRowsInfo]! } type RSS3DiffStatus{ column: Boolean constraint: Boolean data: Boolean } type PKInfo { name: String! value: String! } type AddedRowsInfo { pk: [PKInfo!]! row_data: String! } type DeletedRowsInfo { pk: [PKInfo!]! row_data: String! } type UpdatedRowsInfo { pk: [PKInfo!]! cols: [String!]! row_data: String! } で、このスキーマ定義に対して、codegen で生成された typescript の query が以下になるのですが・・ export const GetTableDataDiffInfo = /* GraphQL */ `query GetTableDataDiffInfo($input: GetTableDataDiffInfoInput!) { GetTableDataDiffInfo(input: $input) {   diff_summary {     column     constraint     data     __typename   }   added_rows_info {     row_data     __typename   }   deleted_rows_info {     row_data     __typename   }   updated_rows_info {     cols     row_data     __typename   }   __typename } } ` as GeneratedQuery< APITypes.GetTableDataDiffInfoQueryVariables, APITypes.GetTableDataDiffInfoQuery >; 見てお分かりの通り、AddedRowsInfo/DeletedRowsInfo/UpdatedRowsInfo 配下の「PKInfo」type 部分が query 定義から抜け落ちてしまっています。ネストの深さとしては一番上の階層から数えると 「3」 になりますね。   暫定回避策 さてこれは困ったということで解決策を探したのですが、探し方が悪かったのかめぼしい情報が見当たらず。最初は AppSync のクエリの深さ制限設定を疑ったのですが、デフォルト値は無制限だったためこの可能性は除外。 そこで一旦暫定的な回避策として、自分で直接 GraphQL の query を書くことにしました。codegen で 型情報を生成して欲しかったので、以下サイト様の記事通り所定のパスに query が定義されたファイルを配置しました。 AmplifyでカスタムGraphQLクエリと型情報を生成する方法 - Qiita 本記事を対象とする人Web(React,Vueなど)でAmplify利用し、自動生成されるクエリでは足りなくなった結論graphqlconfig.ymlのincludesに指定しているディレク… qiita.com ただ、当然ながら query を自分で書いている以上スキーマ定義の変更があった場合も自動で追随してくれないため、開発が続くにつれて不便さ＆イライラを感じてきました。そもそも、Amplify が自動生成しないような複雑なクエリを書きたいから自分で書く必要があるのであって、今回のような事象に対しては根本的な解決策でないことは明らかであったため、本腰を入れて解決策を調べたところ・・   解決策 結論としては以下 URL の通り、.graphqlconfig.yml の maxDepth 属性で、生成する query のネストの深さを明示的に指定することで解決しました。 ただ、以下 URL に記載のある –max-depth オプションは手元の環境だと機能しませんでした。また、「max d epth」のように大文字小文字を間違えてもダメですのでご注意ください。 最初間違えてしまったのですが、エラーも出ないのでこの設定方法も機能しないのではないかと疑心暗鬼になってしまいました・・ Nested types missing from queries in generated code - Require workaround · Issue #745 · aws-amplify/amplify-cli ** Which Category is your question related to? ** iOS side generated graphql queries ** What AWS Services are you utiliz... github.com 以下、maxDepth を 5 に設定した場合の実装例です。 projects: nuxt3app:   schemaPath: src/graphql/schema.json   includes:     - src/graphql/**/*.ts   excludes:     - ./amplify/**   extensions:     amplify:       codeGenTarget: typescript       generatedFileName: src/API.ts       docsFilePath: src/graphql       maxDepth: 5 extensions: amplify:   version: 3 こちらはオプション指定して codegen した query の内容です。PKInfo の type が追加されていることが確認できます。 export const GetTableDataDiffInfo = /* GraphQL */ `query GetTableDataDiffInfo($input: GetTableDataDiffInfoInput!) { GetTableDataDiffInfo(input: $input) {   diff_summary {     column     constraint     data     __typename   }   added_rows_info {     pk {       name       value       __typename     }     row_data     __typename   }   deleted_rows_info {     pk {       name       value       __typename     }     row_data     __typename   }   updated_rows_info {     pk {       name       value       __typename     }     cols     row_data     __typename   }   __typename } } ` as GeneratedQuery< APITypes.GetTableDataDiffInfoQueryVariables, APITypes.GetTableDataDiffInfoQuery >; また、同オプションのデフォルト値は 「2」 ということで、先般のスキーマ定義において PKInfo 以下の type が出力されなかった理由も辻褄が合ってスッキリしました。正直、デフォルト値はもう少し大きくても良いと思うんですけども・・   まとめ 以前の投稿にて Amplify.Configure に与える引数の定義が不明瞭で調査に苦労した旨書いていたのですが、本件も似たような文脈の話ではないかと思います。。 余談ですが、初めて本事象が発生した時は原因究明に結構な時間を要してしまいました。というのも、Amplify のデプロイや codegen 実行時はエラーが出ておらず、AppSync 側のスキーマ定義を確認しても問題なし。Lambda リゾルバの実装に問題がある可能性も考慮して、AWS マネジメントコンソールからクエリを直接実行してみるとちゃんと PKInfo 部分の情報も取れる。でもフロントエンド側から codegen で生成されたクエリを使用すると PKInfo 部分の情報が取れない。でもエラー自体は出ていない。という感じだったので・・ 開発当初は Amplify や AppSync、GraphQL などへの理解が十分でなかったこともありますが、Web 上の情報がもう少し多かったらもっと早く解決できた！はず！ということで小ネタではありますが、本記事がどなたかの役に立てば幸いです。

「~のサービスは次のうちどれでしょうか。」 クラウドの認定試験やIPAの午前試験などでよくある形式です。 こういう選択問題はなんとなくで解けてしまうことも多いですよね。 私も試験勉強中は 「よくわからないけど、これかな～？」 と曖昧な理解で正解した時期がありました。 大量の問題演習で何とかしのいでいましたが、こんな勉強法を脱却したいと日々悶々。 そんな思いがある中、実務で触れて理解が深まった Azureの「プライベートエンドポイント」 についてまとめます。 プライベートエンドポイントとは？ AzureのPaaSサービスに接続するための手段のひとつです。 仮想ネットワーク内の プライベートIPアドレス を使用して PaaSリソース に接続するために使用します。 パブリックアクセスを無効化することで、インターネット経由のアクセスを防ぐことも可能です。 つまり セキュリティ向上の利点 があるわけです。                       試験勉強中はこの概念を流し読みしていましたが、そもそも「PaaSリソースとは何か？」をきちんと理解できていませんでした。 「なんとなく、インターネットを介さずに何かにアクセスできる仕組み」といった認識だったのです。それでも試験の問題には正解できてしまうので、深く考えることなく先に進んでしまっていました。 問題を解いてみる 例えば、次のような問題があるとします。 問1 仮想ネットワークのプライベートIPアドレスを使用してPaaSサービスに接続するためのサービスはどれ？ a. Azure Bastion b. プライベートエンドポイント c. Azure Load Balancer d. Azure ExpressRoute この問題では、「プライベートIPアドレス」というキーワードだけに注目して”b”のプライベートエンドポイント選んでました。なぜかPaaSサービスに接続～のくだりを読み飛ばしていたのです。これで正解してしまいます。 問2 「」の内容が 正しい 場合は”変更は必要ありません” そうでない場合は正しい回答を選べ 「パブリックエンドポイント」を使用すると、Azure Cosmos DBなどのPaaSサービスに接続するためのパブリックアクセスを無効にできる。 a. プライベートエンドポイント b. 仮想ネットワークピアリング c. Azure ExpressRoute d. 変更は必要ありません パブリックアクセスを無効とくればプライベートエンドポイントで”a”を選択してました。こちらでもAzure Cosmos DBなどの記載を無視して解いていたのです。 問3 次のリソースがある。 名前 リソース種別 説明 VNET1 仮想ネットワーク ー VM1 仮想マシン VNET1に配置 Storage1 ストレージアカウント ー VM1がプライベートIPアドレスを使用してStorage1にアクセスできるように構成するにはどれを使うべきか？ a. ユーザー割り当てマネージドID b. Azure Firewall c. プライベートエンドポイント d. Application Gateway 問1と同じようにプライベートIPアドレスとくればプライベートエンドポイント”c”を選べてしまいますが、 アクセス先がストレージであることに理由があったんだなぁ と今になって気づきました。 自分が何を理解していて、何を見落としていたのかがよく分かります。理解して解けるようになると問題設定も結構おもしろいです。 PaaSサービスの具体例 振り返ってみると、問題の意図がより明確に見えてきます。 そもそもPaaSサービスって具体的に何のことでしょうか？ 公式ドキュメント見ると。プライベートエンドポイントの文脈で出てくるPaaSサービスとは以下のサービスのことです。 Azure Storage Azure Cosmos DB Azure SQL データベース Private Link サービスを使用する独自のサービス プライベート エンドポイントとは – Azure Private Link | Microsoft Learn 実務でストレージにプライベートIPを付与する場面を見たことで、やっとこの概念を理解できました。 文字情報だけでは気づけないことも多いと 痛感 しました。 デモ 自分でもストレージアカウントにプライベートIPアドレス付与してみようと思います。 1. ストレージアカウントの左ペインからセキュリティとネットワークを開き、ネットワークを選択。 プライベートエンドポイント接続、+プライベートエンドポイントを押下します。                     2.基本タブ入力。 名前を入力するとネットワークインターフェイス名が自動で作成された。               3.リソースタブでは対象サブリソースで、ストレージの種類選択。今回はblobになります。                 4. 仮想ネットワークタブではプライベートエンドポイントを作成するサブネットを指定。 このサブネット上にプライベートエンドポイント作成されプライベートIPアドレスが構成されます。                     5. DNSタブではプライベートDNSゾーンと統合するではいを選択。DNSレコードが自動で構成されます。             6.確認。 プライベートIPアドレス 10.0.156.4 が付与されました。                                                   7.プライベート経由のアクセス許可の確認 プライベートエンドポイントと同じ仮想ネットワーク上のVMへリモートデスクトップ接続してnslookup コマンド実施。 以下のようにプライベートIPアドレスが応答される。         自分のPCからnslookup実行するとパブリックIPアドレスが応答され、ストレージにアクセスできない。           さいごに 3月にAZ-305（Microsoft Certified: Azure Solutions Architect Expert）を受験します。 AZ-104よりも要件が複雑になっているので、理解しながら解けるようになろうと思います。 ふんわりした資格勉強から卒業し、実務で活かせる知識を身につけるために、しっかりとした学習を進めていきます。

こんにちは！SCSKの新人営業、栗山です。 皆さんの会社では、電話応対をどのように行っていますか？ 顧客対応の質向上や効率化 は、多くの企業にとって重要な課題ですよね 近年、AI技術を活用した 電話応対のDX が注目されています。 例えば、音声認識技術を使えば、顧客との会話を自動でテキスト化し、分析したり、対応を効率化したりすることが可能になります！ 今回は、Google Cloudが提供する音声認識サービス Google Cloud Speech-to-Text の検証を通して、AIによる電話応対DXの可能性を探ってみました！ Google Cloud Speech-to-Tex(以降Speech-to-Text)は、高精度な音声認識を簡単に実現できるサービスです。 本記事では、Speech-to-Textを実際に使ってみた感想や検証結果を共有することで、 AI技術による電話応対DXに興味がある方 Speech-to-Textの導入を検討している方 文字起こしツールを活用したいけど何にしようか悩んでいる方 音声データを分析して業務に役立てたいと考えている方 にとって、少しでも役立つ情報になれば幸いです！ 検証目的 コンタクトセンター業界 のお客様からは、音声データの文字起こしに対して、有用なサービスは無いかと質問を受けるケースが良くあります。 あるお客様は現状、オペレーターの対応時の録音データを分析に活用するため、 何度も聞き直しながら手作業で文字起こし を行っており、非常に時間と手間がかかっているとのことでした。。。 もし、この 文字起こし作業をAIで効率化 できれば、担当者はより創造的な業務に集中できます。 例えば、顧客対応の傾向分析や、サービス品質向上のための施策検討などに時間を有効活用できるでしょう。 そこで今回、限りなく実際の応対に近いテスト音声データを使い、Speech-to-Textによる音声認識精度の簡易検証を実施することで、 Speech-to-Textの導入により、お客様の文字起こし作業の効率化と負担軽減に貢献できる可能性 を明らかにしました!   なぜGoogle Cloud Speech-to-Textを選んだのか 導入の容易さ：  GUIが用意されており、初期設定が簡単で、すぐに検証を開始できる! コストパフォーマンス： 無料枠60分があり、コストを気にせず試しやすい! 高精度のリアルタイム文字起こし： 他クラウドと比較しても遜色ない性能! 他クラウドとの比較（文字起こしサービス編）       Google  Cloud      Speech-to-Text Amazon Transcribe    Microsoft Azure    Speech to Text AmiVoice Cloud Platform（Amivoice API） 対応言語 日本語を含む125以上の言語 日本語を含む複数言語 日本語を含む多数の言語 日本語、英語、中国語、韓国語 料金 約0.046円/秒 ※60分無料枠あり ※新規利用者は$300相当のクレジット ※ログ許可で割引あり 約0.046円/秒 ※利用量割引あり 約0.046円/秒 ※1か月あたり5音声時間は無料 0.044円/秒 ※毎月60分無料枠あり ※ログ許可で割引あり GUIでの利用 〇 〇 〇 × ※単語登録のみ可能 他サービスとの連携 〇 他Google Cloudサービスと容易に連携 〇 他AWSサービスと容易に連携 〇 他Azureサービスと容易に連携 〇 リアルタイム性 低遅延で字幕表示も可能 リアルタイム対応可能だが速度に制限あり 雑音環境での処理に強いが速度は平均的 リアルタイム性は他社と比較して平均 導入の容易さ デフォルトモデルで高精度・即利用可 即時利用可能 高精度だがカスタマイズ設定が必要 APIを利用したプログラミングが必要 あなたのユースケースに最適な音声文字起こしサービスはどれ？主要3社を比較してみた | ネットワンシステムズ ※あくまで公開されている情報や個人の見解に基づいており、モデルや設定によって結果が異なる場合があることにご注意ください。 Speech-to-Textで 期待できること Speech-to-Textは、音声データをリアルタイムまたはバッチ処理で文字起こしする機能を提供します。Speech-to-Textを活用・組み合わせて以下のような期待が持てます。 会議録音の文字起こしでの作業効率化 コールセンターでの問い合わせ分析 動画コンテンツの字幕生成               etc..   検証プロセス ① データ準備 検証に使用するデータは以下の2つです。 音声データ( MP3, FLAC, AMR, LINEAR16 など) 正解データ 音声データから一言一句書き起こしたテキストデータ（手動で作成） 評価を正確に行うため、改行やスペース、句読点（「、」「。」）も含まれていない ② 音声ファイル読み込み 今回はMP３の音声ファイルを読み込んでいます。(Cloud Storageのファイルも利用可能) チャンネルごとに別個の認識: 有効 音声データをアップロードすると自動的にサンプリングレートを割り当てくれます！ ③ 音声文字変換のオプション APIバージョン：V1 使用する言語：Japanese 文字起こしモデル：Telephony リージョン：global 文字起こしモデル とは、音声データをテキストデータに変換するAIモデルのことです。Speech-to-Textでは、様々な種類の音声データに対応するために、複数のモデルが用意されています。 今回の検証では、通話録音データに最適化された Telephonyモデル を使用しました。Telephonyモデルは、電話会話特有のノイズや音声品質の変動に強く、通話内容の文字起こしに高い精度を発揮します。 その他モデルについては以下をご参照ください！ 音声文字変換モデルを選択する  |  Cloud Speech-to-Text V2 documentation  |  Google Cloud cloud.google.com 詳細設定: 今回は全て無効にしましたが、下記の高度な詳細設定が可能です。 冒とく的な語句フィルタ 句読点入力の自動化 発話された句読点 発話された絵文字 話者ダイアライゼーション 単語の時間オフセット ※2024年12月時点 一部日本語対応していない機能ございます。 今回 カスタム音声モデル の適用はしませんでした。固有名詞や専門用語に対応する場合は、モデルを作成することで、認識精度をさらに向上させることが可能です。 ④ 正解データインポート 文字起こし精度を正しく評価するために、正解データ（音声データの内容を正確に書き起こしたテキストデータ）をインポートします。 今回は、自ら音声ファイルを手打ちで文字起こした正解データを用意しました。この正解データは、文字ベースでの認識制度を図るため、句読点や改行など、実際に話されていない文字は含めていません。 この正解データをSpeech-to-Textにインポートすることで、音声認識結果と正解データを比較し、認識精度を自動で算出することができます。   検証結果 成果 認識精度：約90%以上 文字レベルでの一致率を測定した結果です！ 高い精度で文字起こしが可能であることが確認できました！ 処理速度：音声データ1分あたり約60秒で処理 （同時実行可能） 非常に高速な処理を実現！ 複数ファイル同時実行可能で、手作業に比べて大幅な時間短縮が可能！ 観察事項 固有名詞誤認識が一部確認 一部音声ファイルの品質（背景ノイズや録音距離）に依存 今回の検証では、Speech-to-Textが 高い認識精度と処理速度 を持つことが確認できました。実際に私が１分あたりの音声データを一言一句文字起こしすると５分かかりましたので、 約80% の時間削減 が見込まれることになります (※1) 。これにより実際の担当者はより戦略的な業務に時間を活用できます。 今後は、削減された時間で、BigQueryなどのデータ分析基盤と連携し、文字起こしデータを様々な角度から分析することで、顧客対応の質向上や新たなビジネスチャンスの発掘が期待できます! ※1 あくまで一例であり、音声ファイルの品質や内容、オペレーターの習熟度などによって削減時間は変動します。 さらに精度を上げるには？ カスタム音声モデルの作成 固有名詞や専門用語を学習させることで、精度を向上させます！ 音声品質の改善 マイクの見直しやノイズ環境の調整により、音声データの品質を高め、音声認識の精度を改善します！ APIバージョンのアップグレード（V1→V2） 最新バージョン（V2）を使用することで、性能の向上が期待されます！   なぜSCSK？ SCSKは、Google Cloudのプレミアパートナーとして、お客様の課題解決に最適なクラウドサービスを選定し、導入から運用までをトータルでサポートします。お客様に寄り添い、長年の経験で培った技術力で、ビジネスの成長を力強く後押しします。 1. 幅広いクラウド技術の知見 Google Cloudはもちろん、AWS、Azureなど、マルチクラウドに対応したエンジニアが多数在籍しています。お客様のニーズやビジネスの特性に合わせて、最適なクラウド環境を構築し、柔軟なシステム基盤を提供いたします。 さらに、SCSK独自のプライベートクラウドサービス「USiZE」も提供しており、パブリッククラウドと組み合わせたハイブリッドクラウド環境の構築も可能です。 2.トータルサポート体制 40年以上にわたるシステム構築・運用実績で培った業界知識と、クラウドに関する高い技術力、そして 2,500名以上の認定技術者 を擁するSCSKだからこそ、お客様のビジネスに最適なクラウド環境を実現できます。 お客様の業界基準やコンプライアンスに準拠した、強固なセキュリティ体制を構築し、ISO 27001認証取得のデータセンターで運用することで、お客様のデータ資産を安全に保護します。 また、お客様のクラウド活用を支援する、幅広いサービスラインナップを取り揃えています。 クラウドサービス 時代の急激な変化に素早く柔軟に対応。キーワード「クラウドサービス」に関する製品・サービス一覧をご覧いただけます。 www.scsk.jp 3. AIの導入実績 AI技術を活用したシステムの導入実績も豊富です。AIチャットボット、需要予測AI、画像認識AIなど、様々な分野で実績があります。お客様のビジネス課題を解決に導く、最適なAIソリューションを提案します。 So-net 様 AI本番導入事例 : コンタクトセンターにてチャットボット、ボイスボットを導入し、オペレーターなしで回答を自動化。オペレーター応対件数を 35%削減 を実現 AI本番システム実装事例集｜ダウンロード｜クラウド移行だけでは描けない、理想のDXを実現する www.scsk.jp   おわりに いかがでしょうか。今回の検証では、Speech-to-Textが文字起こし作業の大幅な効率化に貢献できることが示されました。特に、 処理速度と認識精度は期待以上 であり、実務での活用に十分耐えうるレベルであると言えます。 Speech-to-Textの導入は、シンプルなUIで、配属1か月の営業担当の私でも たった2日 で使いこなすことができました。ただ、本格的な文字起こし作業を完了するには、APIやSDKを利用したプログラミングが必要になる場合があります。 今後も積極的に技術に触れ、お客様の課題に最適な提案ができる営業を目指します。 本記事をご覧いただき、詳細をご希望の方はお気軽にお問い合わせください！       ※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

はじめに 検証でAzure環境とAWS環境をVPN接続した環境が必要となり、以下記事を参考に環境を構築しようとしました。 最低限のコストで、必要な時に作ったり消したりを気軽にできるよう、テンプレート化してみたという記事です。 チュートリアル - ポータルを使用して Azure と アマゾン ウェブ サービス (AWS) 間の BGP 対応接続を構成する - Azure VPN Gateway このチュートリアルでは、アクティブ/アクティブ VPN Gateway と AWS 上の 2 つのサイト間接続を使用して Azure と AWS を接続する方法について説明します。 learn.microsoft.com 上記記事の完全体はアクティブ-アクティブ構成かつ２つのトンネルで構成されていますが、今回はアクティブ-アクティブを無効にしてトンネルを1つだけ構成してます。段階的には成長期です。 一時的な検証用途なので、最低限の構成でつながればいいやという思想です。イメージはこんな感じ。 概要図 図としては、以下のような感じです。 テンプレート テンプレートは3つ用意しています。これはリソース構築後に払い出される値が必要なリソースがあるためです。 例えば、AWS側のカスタマーゲートウェイにAzureのパブリックIPが必要である、とか。 作成の大まかな流れは以下の通りです。 Step 作業項目 備考 Step1：【Azure】NW基盤作成 ①VNet・サブネットの作成 ②Virtual Network Gateway用パブリックIPの作成 対応テンプレート： azure_network_resource.json Step2：【AWS】VPNリソース作成 ①VPC作成 ②カスタマーゲートウェイ作成 ③仮想ネットワークゲートウェイ作成 ④VPN接続作成 ⑤ルート伝搬の有効化 対応テンプレート：aws_vpn_resource.yaml Step3：【Azure】VPNリソース作成 ①Local Network Gateway作成 ②Virtual Network Gateway作成 ③VPN接続作成 対応テンプレート：azure_vpn_resource.json Step1 ：【Azure】NW基盤作成 指定しているパラメータ パラメータ名 デフォルト値 備考 vnetName VNet1 作成するVNetの名前 vnetAddressPrefix 10.1.0.0/16 作成するVNetのCIDR範囲 subnet1Prefix 10.1.0.0/24 GatewaySubnetのCIDR範囲 vpnpipName VNet1GWpip パブリックIPの名前 コード ファイル名：azure_network_resource.json {   "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",   "contentVersion": "1.0.0.0",   "metadata": {     "_generator": {       "name": "bicep",       "version": "0.6.18.56646",       "templateHash": "10806234693722113459"     }   },   "parameters": {     "vnetName": {       "type": "string",       "metadata": {           "description": "VNet Name"         },       "defaultValue": "VNet1"     },     "vnetAddressPrefix": {       "type": "string",       "metadata": {           "description": "VNet CIDR range"         },       "defaultValue": "10.1.0.0/16"     },     "subnet1Prefix": {       "type": "string",       "metadata": {           "description": "Gateway Subnet CIDR range"         },       "defaultValue": "10.1.0.0/24"     },      "vpnpipName": {       "type": "string",       "metadata": {           "description": "Public IP Name"         },       "defaultValue": "VNet1GWpip"     }   },   "resources": [     {       "type": "Microsoft.Network/virtualNetworks",       "apiVersion": "2024-05-01",       "name": "[parameters('vnetName')]",       "location": "[resourceGroup().location]",       "properties": {         "addressSpace": {           "addressPrefixes": [             "[parameters('vnetAddressPrefix')]"           ]         },         "subnets": [           {             "name": "GatewaySubnet",             "properties": {               "addressPrefix": "[parameters('subnet1Prefix')]"             }           }         ]       }     },     {       "type": "Microsoft.Network/publicIPAddresses",       "apiVersion": "2024-05-01",       "name": "[parameters('vpnpipName')]",       "location": "[resourceGroup().location]",       "sku": {         "name": "Standard",         "tier": "Regional"       },       "properties": {         "publicIPAllocationMethod": "Static",         "idleTimeoutInMinutes": 4       }     }   ]   } Step2：【AWS】VPNリソース作成 指定しているパラメータ パラメータ名 デフォルト値 備考 myVPCName VPC1 作成するVPCの名前 myVPCCIDR 10.2.0.0/16 作成するVPCのCIDR範囲 VGWName AzureGW 仮想ネットワークゲートウェイの名前 CGWName ToAzureInstance0 カスタマーゲートウェイの名前 VPNConnectionName ToAzureConnection VPN接続の名前 CustomBGPASN 65000 Azure側GatewayのASN azurepip なし Step1で作成したパブリックIPを指定 コード ファイル名：aws_vpn_resource.yaml AWSTemplateFormatVersion: '2010-09-09' Description: Create a Virtual Private Gateway and Customer Gateway Parameters: myVPCName:   Type: String   Default: "VPC1" # VPCの名前 myVPCCIDR:   Type: String   Default: "10.2.0.0/16" # VPCのCIDR範囲 VGWName:   Type: String   Default: "AzureGW" # 仮想ネットワークゲートウェイのリソース名 CGWName:   Type: String   Default: "ToAzureInstance0" # カスタムネットワークゲートウェイのリソース名 VPNConnectionName:   Type: String   Default: "ToAzureConnection" # VPN接続の名前 CustomBGPASN:   Type: Number   Default: 65000 # 任意のASNを入力 azurepip: # スタック作成時にAzure側のパブリックIPを入力する。     Type: String Resources: # VPCの作成 myVPC:   Type: AWS::EC2::VPC   Properties:     CidrBlock: !Ref myVPCCIDR     Tags:       - Key: Name         Value: !Ref myVPCName MyVpcDefaultRouteTable:   Type: AWS::EC2::RouteTable   Properties:     VpcId: !Ref myVPC # 仮想プライベートゲートウェイの作成 VirtualPrivateGateway:   Type: AWS::EC2::VPNGateway   Properties:     Type: ipsec.1     Tags:       - Key: Name           Value: !Ref VGWName   # 仮想プライベートゲートウェイをVPCにアタッチ VPCGatewayAttachment:   Type: AWS::EC2::VPCGatewayAttachment   Properties:     VpcId: !Ref myVPC       VpnGatewayId: !Ref VirtualPrivateGateway # カスタマーゲートウェイの作成 CustomerGateway:   Type: AWS::EC2::CustomerGateway   Properties:     BgpAsn: !Ref CustomBGPASN     IpAddress: !Ref azurepip  # カスタマーゲートウェイのパブリックIPアドレス     Type: ipsec.1     Tags:       - Key: Name         Value: !Ref CGWName   # VPN接続の作成 VPNConnection:   Type: AWS::EC2::VPNConnection   Properties:     Type: ipsec.1     CustomerGatewayId: !Ref CustomerGateway     VpnGatewayId: !Ref VirtualPrivateGateway     StaticRoutesOnly: false  # 動的ルーティングとする。     Tags:       - Key: Name         Value: !Ref VPNConnectionName     VpnTunnelOptionsSpecifications:       - TunnelInsideCidr: "169.254.21.0/30"  # トンネル1の内部IPv4 CIDR         - TunnelInsideCidr: "169.254.22.0/30"  # トンネル2の内部IPv4 CIDR   # ルート伝搬の有効化 EnableRoutePropagation:   Type: AWS::EC2::VPNGatewayRoutePropagation   Properties:     RouteTableIds:       - !Ref MyVpcDefaultRouteTable     VpnGatewayId: !Ref VirtualPrivateGateway     DependsOn: VPCGatewayAttachment Outputs: VirtualPrivateGatewayId:   Description: "The ID of the Virtual Private Gateway"   Value: !Ref VirtualPrivateGateway CustomerGatewayId:   Description: "The ID of the Customer Gateway"     Value: !Ref CustomerGateway VPNConnectionId:   Description: "The ID of the VPN Connection"     Value: !Ref VPNConnection Step3：【Azure】VPNリソース作成 指定しているパラメータ パラメータ名 デフォルト値 備考 myVNet VNet1 Step1で作成したVNetの名前 publicIpName VNet1GWpip Step1で作成したパブリックIPの名前 localNetworkGatewayName lngw_test Local Network Gatewayの名前 asn 64512 AWS側のASN bgpPeeringAddress 169.254.21.1 Local Network GatewayのピアIP customBgpIpAddress 169.254.21.2 Virtual Network GatewayのピアIP virtualNetworkGatewayName vngw_test Virtual Network Gatewayの名前 vngwasn 65000 Azure側のASN gatewaySku VpnGw1 VPN GatewayのSKUを指定 virtualNetworkConnectionName AWSTunnel1toAzureInstance0 VPN接続の名前 gatewayIpAddress なし Step2で作成したVPN接続(トンネル1)のパブリックIPを指定 PreSharedKey なし Step2で作成したVPN接続の事前共有鍵を指定 コード ファイル名：aws_vpn_resource.yaml {   "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",   "contentVersion": "1.0.0.0",   "parameters": {     "myVNet": {       "type": "string",       "metadata": {         "description": "VNet Name"       },       "defaultValue": "VNet1"     },     "publicIpName": {       "type": "string",       "metadata": {         "description": "PublicIPAddress Name"       },       "defaultValue": "VNet1GWpip"     },     "localNetworkGatewayName": {       "type": "string",       "metadata": {         "description": "LocalNetworkGateway Name"       },       "defaultValue": "lngw_test"     },     "asn": {       "type": "int",       "metadata": {         "description": "Autonomous System Number (ASN) for BGP"       },       "defaultValue": 64512     },     "bgpPeeringAddress": {       "type": "string",       "metadata": {         "description": "BGP peering address for LocalNetworkGateway"       },       "defaultValue": "169.254.21.1"     },     "customBgpIpAddress": {       "type": "string",       "metadata": {         "description": "BGP peering address for VirtualNetworkGateway"       },       "defaultValue": "169.254.21.2"     },     "virtualNetworkGatewayName": {       "type": "string",       "metadata": {         "description": "Name of the virtual network gateway"       },       "defaultValue": "vngw_test"     },     "vngwasn": {       "type": "int",       "metadata": {         "description": "Autonomous System Number (ASN) for BGP"       },       "defaultValue": 65000     },         "gatewaySku": {       "type": "string",       "metadata": {         "description": "SKU for the virtual network gateway"       },       "defaultValue": "VpnGw1",       "allowedValues": [         "Basic",         "VpnGw1",         "VpnGw2",         "VpnGw3",         "VpnGw4",         "VpnGw5"       ]     },     "virtualNetworkConnectionName": {       "type": "string",       "metadata": {         "description": "Name of the VPN Connection"       },       "defaultValue": "AWSTunnel1toAzureInstance0"     },     "gatewayIpAddress": {       "type": "string",       "metadata": {           "description": "AWS Public IP Address"         }     },     "PreSharedKey": {       "type": "string",       "metadata": {         "description": "Pre-SharedKey"       }     }   },   "resources": [     {       "type": "Microsoft.Network/localNetworkGateways",       "apiVersion": "2024-05-01",       "name": "[parameters('localNetworkGatewayName')]",       "location": "[resourceGroup().location]",       "properties": {         "gatewayIpAddress": "[parameters('gatewayIpAddress')]",         "bgpSettings": {           "asn": "[parameters('asn')]",           "bgpPeeringAddress": "[parameters('bgpPeeringAddress')]"         }       }     },     {       "type": "Microsoft.Network/virtualNetworkGateways",       "apiVersion": "2024-05-01",       "name": "[parameters('virtualNetworkGatewayName')]",       "location": "[resourceGroup().location]",       "properties": {         "ipConfigurations": [           {             "name": "vnetGatewayConfig",             "properties": {               "privateIPAllocationMethod": "Dynamic",               "subnet": {                 "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('myVNet'), 'GatewaySubnet')]"               },               "publicIPAddress": {                 "id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIpName'))]"               }             }           }         ],         "gatewayType": "Vpn",         "vpnType": "RouteBased",         "enableBgp": true,         "activeActive": false,         "sku": {           "name": "[parameters('gatewaySku')]",           "tier": "[parameters('gatewaySku')]"         },         "bgpSettings": {           "asn": "[parameters('vngwasn')]",           "bgpPeeringAddresses": [             {               "ipconfigurationId": "[resourceId('Microsoft.Network/virtualNetworkGateways/ipConfigurations', parameters('virtualNetworkGatewayName'), 'vnetGatewayConfig')]",               "customBgpIpAddresses": [ "[parameters('customBgpIpAddress')]" ]             }           ]         }       }     },     {       "type": "Microsoft.Network/connections",       "apiVersion": "2024-05-01",       "name": "[parameters('virtualNetworkConnectionName')]",       "location": "[resourceGroup().location]",       "dependsOn": [         "[resourceId('Microsoft.Network/virtualNetworkGateways', parameters('virtualNetworkGatewayName'))]",         "[resourceId('Microsoft.Network/localNetworkGateways', parameters('localNetworkGatewayName'))]"       ],       "properties": {         "virtualNetworkGateway1": {           "id": "[resourceId('Microsoft.Network/virtualNetworkGateways', parameters('virtualNetworkGatewayName'))]"         },         "localNetworkGateway2": {           "id": "[resourceId('Microsoft.Network/localNetworkGateways', parameters('localNetworkGatewayName'))]"         },         "connectionType": "IPsec",         "sharedKey": "[parameters('PreSharedKey')]",         "enableBgp": true       }     }   ],   "outputs": {     "localNetworkGatewayId": {       "type": "string",       "value": "[resourceId('Microsoft.Network/localNetworkGateways', parameters('localNetworkGatewayName'))]"     },     "VirtualNetworkGatewayId": {       "type": "string",       "value": "[resourceId('Microsoft.Network/localNetworkGateways', parameters('localNetworkGatewayName'))]"     }   }   } 手順 ここからは上記テンプレートを用いた簡単な構築手順を記載します。なお、細かい画面遷移等は手順を省いていますのでご了承ください。 なお、Azure CLIがインストールされていることが前提となります。インストール手順は以下参照です。 Azure CLI をインストールする方法 Azure CLI は、Windows、macOS、および Linux 環境にインストールできます。 Docker コンテナーおよび Azure Cloud Shell でも実行できます。 learn.microsoft.com リソース構築手順 ①Azure CLIを使うため以下コマンドでAzureにログインします。 az login ②Azure側にリソースグループがない場合は以下コマンドでリソースグループを作成して下さい。 az group create --name <リソースグループ名> --location japaneast ③以下コマンドでAzureリソース（NW関連）をデプロイします。 az deployment group create --resource-group <リソースグループ名> --template-file azure_network_resource.json  デプロイ後、作成したパブリックIPのアドレスを控えます。 ④AWSコンソール画面のCloudFormationよりスタックを作成してください。   テンプレートファイルを読み込ませます。   パラメータとして③で確認したAzure側のパブリックIPアドレスを入力します。   その他はデフォ設定のままスタックを送信すればOKです。 ⑤CloudFormationが正常終了したら、VPN接続画面でトンネルのパブリックIPを確認します。 ⑥また、構成ファイルをダウンロードします。 ダウンロードしたファイル内に事前共有鍵が書かれてるので、後ほど使います。 ⑦最後に以下コマンドでAzureリソース（VPN関連）をデプロイします。 gatewayIpAddressで⑤で確認したパブリックIPを、PreSharedKeyで⑥で確認した事前共有鍵を指定します。 az deployment group create --resource-group <リソースグループ名> --template-file azure_vpn_resource.json --parameters gatewayIpAddress=<⑤で確認したパブリックIP> PreSharedKey=<⑥で確認した事前共有鍵> ➇以下のようになってれば、つながってるはずです。 ※Azure上で仮想VM、AWS上でEC2をたて、疎通できることを確認しました。 【Azure側】 【AWS側】 リソース削除手順 【Azure】 リソースグループを削除することで作成したリソースが全部消えます。以下コマンドを実行ください。 az group delete --name <リソースグループ名> 【AWS】 CloudFormationのスタックを削除することで作成したリソースが全部消えます。   おわりに 以上、AWSとAzureをVPN接続してみた、でした。本当に接続するとこだけしか作ってませんが。。 ちなみに構築全体流すので大体40分くらいかかります。※AzureのVPNリソース作成が30分超かかる。 コンセプトとしてはAzure、AWSに何もない状態で0から作るってことと手数をできるだけ少なくってことを意識しました。 とはいえ、AzureとAWSという異なるプラットフォームから値を引っ張ってくる必要があるので1つのテンプレートにおさめるのは難しく、手順も何ステップかに分かれてるのでもう少し工夫できないかなあと思っているところです。 余裕がでてくればそのうち冒頭のMicrosoft記事の完全体を作れるように…したいところです。