こんにちは　ＳＣＳＫ　池田です。 2025年11月12日にLifeKeeperが10年ぶりのメジャーバージョンアップを果たしました。これまでOS毎に異なっていたライセンス体系やサポート期間の考え方が統一されるなど、「全てをシンプルに、より分かりやすく、より使いやすく」をコンセプトに改変が行われました。 具体的な内容は以前の記事をご確認ください。 LifeKeeper v10リリース記念　これまでと何が変ったか！？ 今回は、LifeKeeper v10のオプション製品(ARK)について解説したいと思います。 2月のブログでは、主にLifeKeeper製品本体(Core)に吸収あるいは本体から分離したオプション製品(ARK)を中心で解説をしました。 今回は、利用頻度の高いDatabase関連製品やDataKeeper、SAP関連製品についてお伝えしたいと思います。 LifeKeeper for Windows版のオプション製品(ARK) まず、LifeKeeper for Windowsの旧バージョンと新バージョンのオプション製品(ARK)について変更点を見ていきたいと思います。 ご覧いただいて分かる通り、Database関連のARKは「Recovery Kit for Database」に集約されています。 またv10よりProtection Suite Windowsがなくなり、データレプリケーションのためのDataKeeperは「Data Replication Kit」ライセンスを別途購入する必要がある点は注意が必要です。 またWSFC(Windows Server Failover Clustering)と組み合わせて、共有ディスク構成を組めない環境で、論理的な共有ディスクを構成可能とすることのできる「DataKeeper Windows Cluster Edition」は、「DataKeeper Cluster Edition v10」として、引き続き提供されます。 LifeKeeper for Linux版のオプション製品(ARK) 続いて、LifeKeeper for Linuxの旧バージョンと新バージョンのオプション製品(ARK)について変更点を見ていきたいと思います。 こちらもDatabase関連のARKは、「Recovery Kit for Database」に集約されていることがわかりますが、一点、SAP ASEが追加されていることが大きな変更点ですね。 SAPに関しては、従来「Protection Suite Linux v9 EE」というパッケージが用意されていたのですが、v10からはこのパッケージはなくなり、LifeKeeperに必要なARKを追加する形態に変わっていますのでご注意ください。 SAP NetWeaverやHANAも、「Recovery Kit for SAP」という形になっています。 またWindows版と同様に、v10よりProtection Suite Linuxがなくなり、データレプリケーションのためのDataKeeperは「Data Replication Kit」ライセンスを別途購入する必要があるのでご注意ください。 まとめ 今回のブログでは、LifeKeeper v10のオプション製品(ARK)について、旧バージョンとの比較という形で解説しました。 Database関連のARKは、「Recovery Kit for Database」に集約されたり、SAPについては、「Protection Suite Linux v9 EE」がなくなったりとライセンス選定にあたっては、十分に注意する必要がありそうですね。 その為、ライセンス購入時はできるだけサイオステクノロジー社から認定されたSCSKのようなSI&サポートパートナーに確認をしたり、サイオステクノロジー社の公式ページを確認しながら必要なライセンスを選択するようにしてください。 サイオステクノロジー認定のSI&Supportパートナー （サイオステクノロジー公式サイト） Lifekeeperの製品体系 （サイオステクノロジー公式サイト） 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは。プロダクト開発部の森 @jiskanulo です。 2026年4月22日から24日までRubyKaigi 2026 Hakodateが開催されました。 rubykaigi.org 函館アリーナを3日間に渡って貸し切る大規模イベントの運営をしていただきましたスタッフの皆様に感謝を申し上げます。 ファインディ株式会社もPlatinumスポンサーとして協賛しました。 私もブースに立って出展やファインディ各サービスのご案内をさせていただきました。 お話しをしていただいた皆様にも重ねて感謝申し上げます。 ブースに立つ合間にセッションを聞いて自分でやれそうなことに思いを馳せたり、他社様のブースを回ってプロダクトのお話をしたり、昔の同僚や知人と再会したりと個人的にもいい刺激の多い3日間でした。 さて、4月24日、最後のセッションのMatzさんのキーノートにてRubyファイルをネイティブバイナリにコンパイルする Spinel が発表されました。 早速Spinelを使ってみた感想とつかいどころを記します。 Spinelとは 検証環境とセットアップ 動かしてみた Hello, World! eval / requireの挙動：エラーにならず無音で間違う eval は no-op に置き換わる require は文ごと消える 現時点での注意点 Spinelを使ってみる requireなしでJSONを扱う ハマりどころは個別に踏みに行く価値がある Spinelを試すときの判断基準 個人的所感 おまけ: Spinelの由来 おわり Spinelとは SpinelはRubyのAOT (Ahead-Of-Time) コンパイラです。 RubyソースコードをPrismでパースし、全プログラム型推論を行いCのコードに変換してネイティブバイナリを生成します。 パイプラインは次のとおりです。 Ruby → Prism → AST → 全プログラム型推論 → Cコード → ネイティブ実行ファイル リポジトリのREADMEによると、miniruby比で約11.6倍、Conway's Game of Lifeでは86.7倍という性能が示されています。 またバイナリサイズもmrubyを含めずに数十KBに収まるので容量が厳しい環境にも適用できるとのことです。 実体としての ./spinel はPOSIX shell wrapperで、内部で spinel_parse → spinel_codegen → cc を直列に呼び出している、という作りです。 検証環境とセットアップ 検証は手元のmac環境で行いました。 4月24日公開直後にmacで動かそうとしたタイミングでは malloc.h が存在しないなどでエラーになったのでDockerでUbuntuのコンテナを起動して操作しましたが、現在は対応されています。 土日で函館観光しているうちにコントリビュートが進んでいますね。コントリビュートのチャンスですね。 mac build対応 https://github.com/matz/spinel/commit/4593581eb87cea45b59fb28b9dcf2cd75a9bcbab windows対応 https://github.com/matz/spinel/commit/1fe3136aa9bf834b5f37176faca7346503fb1446 環境は次のとおりです。 macOS (arm64) Apple Clang Spinel masterブランチ（2026-04-28時点） ビルドと実行の基本フローはシンプルです。 spinel をmakeし、 spinel にrubyファイルをわたせば実行形式バイナリが出力されます。 make deps # 初回のみ: libprism 取得 make # spinel_parse / spinel_codegen / ランタイムをビルド ./spinel app.rb # Ruby → 実行形式（./app） ./app 動かしてみた Matzのキーノートとも被りますがサンプルコードを動かしてみました。 またキーノートで話があったとおり eval と require はサポートしていないとのことです。 eval, requireを使うと具体的にどうなるのかも試してみました。 Hello, World! 最小の動作確認はそのまま動きます。 # hello_world.rb puts " Hello, World! " ./spinel hello_world.rb ./hello_world # => Hello, World! eval / requireの挙動：エラーにならず無音で間違う 2026年4月28日の現時点では コンパイル時にエラーにならず、warningも出ず、しかし実行すると無音で間違った出力 を返すという挙動です。 具体的に2つのケースを見ていきます。 eval は no-op に置き換わる 次のRubyコードをSpinelでコンパイルして実行します。 # test_eval.rb code = " 1 + 2 " result = eval (code) puts result $ ./spinel ./tmp/jiska/samples/test_eval.rb ./tmp/jiska/samples/test_eval.rb -> test_eval 実行すると結果は 0 です。 $ ./test_eval 0 生成されたCのコードを見ると eval() の呼び出しがno-opに置き換わり、戻り値は型推論で決まったゼロ値（ mrb_int のため 0 ）になります。 const char *lv_code = "1 + 2" ; mrb_int lv_result = 0 ; // mrb_int = int64_t typedef lv_code = "1 + 2" ; lv_result = 0 ; // ← eval() 呼び出し自体が消滅、0 を代入するだけ printf ( " %lld\n " , ( long long )lv_result); mrb_int はmrubyのような」命名に見えますが lib/sp_runtime.h で int64_t のtypedefとして定義されたSpinelランタイムの整数型です。 https://github.com/matz/spinel/blob/64105ec86d08c9edc92c3d17bf059126ceaa15d3/lib/sp_runtime.h#L53 require は文ごと消える 次は require "json" と JSON.generate を使うケースです。 # test_require.rb require " json " puts JSON .generate({ name : " spinel " , year : 2026 }) こちらも実行すると 0 になります！ $ ./spinel ./tmp/jiska/samples/test_require.rb ./tmp/jiska/samples/test_require.rb -> test_require $./test_require 0 require の行は生成されたCのコード上で文ごと消えます。 続く JSON.generate もSpinelから見れば未定義メソッドであり、 eval と同じくゼロ値を返す呼び出しに化けます。 最終的に puts には 0 が渡って表示される、という流れです。 現時点での注意点 現時点では「コンパイルが通った」「実行ファイルができた」「実行できた」の3点だけを見ていると間違った結果を吐いていることに気づけません。 Spinel向けにRubyを書くときは README を都度確認することが重要です。 Spinelを使ってみる 次に実際のユースケースを想定してみます。 実例として、GitHubのPR一覧JSONを入力に取り、各PRの number と author を表示するスクリプトを書いてみました。 入力はARGV、stdinの優先順で受け取ります。 requireなしでJSONを扱う require "json" が使えないので標準の Regexp と String 操作だけで処理を組む必要があります。 なお、ここで示すコードは正しいJSONパーサではありません。 require "json" が使えないSpinelの制約下で、入れ子オブジェクトや }, を含む文字列値が現れない、フラットな配列形式の固定データから number と author をアドホックに取り出す例として読んでください。本格的なJSON処理が必要な場合は、入れ子・エスケープなどで容易に壊れるため、この実装は使えません。 実際のRubyファイルは次のとおりです。 多少トリッキーなところは感じますが、こうした限定的な用途であれば、RegexpとStringの標準機能だけで実装できることがわかりました。 if ARGV .length > 0 input = ARGV [ 0 ] else input = readlines.join end records = input.split( / }, / ) results = [] records.each do |chunk| if chunk =~ / "number" \s* : \s*(\d+)/ num = $1 if chunk =~ / "author" \s* : \s* " ([^ " ]+) " / auth = $1 results << " # #{ num } by #{ auth }" end end end if results.length == 0 $stderr .puts " Error: failed to parse JSON (no matching number/author pairs found) " exit 1 end results.each do |line| puts line end 実行サンプルは次のとおりです。 引数渡し、パイプ、リダイレクトそれぞれに対応しています。 JSONを展開できない場合は標準エラーへエラーメッセージを出して exit 1 します。 SAMPLE='[{"number":1,"author":"Findy"},{"number":2,"author":"jiskanulo"}]' # 1) 引数渡し ./pr_extract "$SAMPLE" # 2) パイプ echo "$SAMPLE" | ./pr_extract # 3) リダイレクト ./pr_extract < sample.json # それぞれの出力: # #1 by Findy # #2 by jiskanulo $ ./pr_extract "not json" Error: failed to parse JSON (no matching number/author pairs found) $ echo $? 1 なお、引数もパイプもなしで ./pr_extract を起動すると readlines がEOF待ちでブロックします。 最初は $stdin.tty? で判定してUsageを表示しようとしましたが、実機で試すとTTYでもパイプでも両方 0 が返ってきました。これも eval / require と同じく、Spinel未対応のメソッドが silent failしている例です。 # test_tty.rb puts $stdin .tty? $ ./test_tty # TTY実行 0 $ echo "" | ./test_tty # パイプ実行 0 Spinelで標準入力を扱うときは $stdin.tty? に頼った分岐ができないため、引数で渡すかパイプ・リダイレクトで明示的に流し込む運用に倒すのが安全です。 ハマりどころは個別に踏みに行く価値がある 実装してみると String#<< でmutable化すると Regexp#scan に渡せない、 Regexp#scan(/(...)/) { |m| ... } のキャプチャは効かない...などとハマりどころがいくつかありました。 ただ、現時点での詳細を解説しても開発が活発に進んでいるのですぐに風化してしまうので詳しくは記しません。 Spinelを試すときの判断基準 ここまで触ってみた感触から、Spinelを触るときの判断基準を次にまとめます。 成功体験を得やすいのは次のようなコードです。 入出力が puts / printf で完結する 標準ライブラリに依存しない 数値計算・文字列処理・正規表現( =~ + $1 )で書ける範囲 逆に、現時点で踏むと詰まる、もしくはsilent failになるのは次のような領域です。 require を前提とするコード（標準ライブラリの利用） eval を含むメタプログラミング 未対応メソッドに依存する処理（呼び出しがゼロ値返却に化ける） 「コンパイルが通ったから動いている」とは限らない、というのが現時点での最も大事な感触です。 CRubyとSpinelの両方で実行して出力をdiffする運用を組むのが安全です。 個人的所感 ローカル環境のlintやチェッカーなど今までワンライナーでやっていたことを置き換えて使ってみたいですね。 コンパイル済みのバイナリを配布できるのであれば環境構築の手間も減るかもしれません。 まだ少し触っただけですが、Spinelに可能性を感じています。また、こういうワクワクするものを提供してくれるMatzさんの凄さをあらためて実感します。 これから機能が拡充されていくのが楽しみです。 自分でもコントリビュートしていきたいですね。 おまけ: Spinelの由来 Rubyと同じく宝石つながりでSpinelなのかなあとはじめ思っていましたが、漫画アニメ『カードキャプターさくら』のスピネル・サン（スッピー）から名前をとっているそうです。 相棒はルビー・ムーンなのでここでもRubyに繋がってきますね。 由来聞いた時はそっちか〜〜！！となりました。かわいい。 おわり ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

このブログは AWS のスペシャリストソリューションアーキテクト Suhail Fouzan、ソリューションアーキテクト Eswar Sesha Sai Kamineni、シニアテクニカルアカウントマネージャー Rizwan Mohammed によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。なお、本翻訳では原文公開後の名称変更を反映し、「Amazon Quick Suite」を現在の正式名称である「Amazon Quick」に統一しています。 今日の変化の激しい IT 環境において、インフラストラクチャ全体のパッチ適用コンプライアンスを監視・可視化することは極めて重要です。従来、 Amazon QuickSight で包括的なパッチ適用ダッシュボードを作成するには、各ビジュアルコンポーネントに対して複数のステップを要する手動かつ時間のかかるプロセスが必要でした。 Amazon Quick は、データ分析と可視化の機能を強化する AI 搭載のアシスタントです。このブログでは、 Amazon Quick が自然言語による対話を通じてダッシュボード作成を簡素化し、この体験をどのように変革するかを解説します。多段階の手動プロセスを数回の簡単なプロンプト操作に短縮し、パッチ適用コンプライアンスとインベントリに関する洞察に富んだ可視化を素早く生成する方法を紹介します。AI を活用した機能が、正確性を維持しながら貴重な時間を節約し、組織のパッチ適用状況に関するリアルタイムのインサイトを提供する動的なダッシュボードの作成にどのように役立つかをご覧ください。システム管理者、セキュリティアナリスト、IT マネージャーのいずれであっても、このガイドは Amazon Quick がパッチ適用コンプライアンスとインベントリの監視・レポート方法をどのように革新するかを説明します。 さらに、このソリューションはカスタムインベントリの可視化を通じて、インフラストラクチャの包括的な可視性を提供します。クラウドプロバイダー、AWS ドライバー、インスタンスタイプ全体にわたるコンピューティングリソースの分布を把握するためのグラフを作成できます。 ソリューションの概要 図 1: アーキテクチャ図 このソリューションは、複数の AWS サービスを活用して Amazon Quick のデータセット作成を自動化し、自然言語クエリを使用してデータを可視化します。 AWS Systems Manager （SSM）のアソシエーションを使用して、各ターゲットマネージドノードでカスタムスクリプトが実行され、必要なインベントリ情報を収集して カスタムインベントリパス に配置します。この情報は、SSM Inventory とリソースデータ同期によって Organization 内の各 AWS アカウントから収集され、中央の S3 バケットに保存されます。この S3 バケットは AWS Glue クローラーによってクロールされ、Glue データベースが作成されます。このデータベースのデータは、Amazon Quick が Amazon Athena 経由でクエリし、データセットの作成とデータの可視化を行います。 このソリューションは、 AWS CloudFormation スタックを使用してデプロイされ、データストレージ用の Amazon S3 バケット、データカタログ用の AWS Glue データベースとクローラー、Systems Manager アソシエーション、リソースデータ同期、Amazon Quick のデータセットと分析ダッシュボードを管理するための AWS CloudFormation StackSet などのリソースを作成します。このソリューションは主に 2 つの自動スケジュールで動作します。Systems Manager アソシエーションは 7 日ごとにカスタムインベントリ収集を実行し、AWS Glue クローラーは 12 時間ごとに Amazon Athena データベースとのデータ同期を実行します。両方のスケジュール間隔は、組織固有の要件に合わせて変更できます。 SSM カスタムアソシエーションは、クラウドプロバイダーおよびオンプレミスシステム全体のすべてのマネージドノードからメタデータを収集し、以下のインフラストラクチャ情報を収集・提供します。 Cloud_provider – AWS やオンプレミスの VMware などのクラウドプロバイダー情報 Total_diskspace – プロビジョニングされたディスク容量の合計 Free_diskspace – 利用可能な空きディスク容量 Free_space_percent – 利用可能な空き容量の割合 Diskspace_status – 10% 未満の場合のディスク容量ステータス さらに、インスタンスメタデータとカスタムスクリプトを使用して、EC2 マネージドノードに固有の以下の情報を収集します。 EC2_type – Xen や Nitro ベースのインスタンスなどの EC2 ハイパーバイザータイプ Instance_type – オンデマンドやスポットなどの購入オプション NVMe_version – インストールされている NVMe ドライバーのバージョン ENA_version – インストールされている ENA ドライバーのバージョン License_type – Windows ライセンス付属や BYOL などのインスタンスに関連付けられたライセンス情報 この情報は、各マネージドノードのカスタムインベントリパスに保存されます。SSM Inventory アソシエーションは、 標準のインベントリメタデータ とともにこのカスタムデータをキャプチャします。各アカウントの リソースデータ同期 により、インベントリメタデータが中央の S3 バケットに同期されます。 前提条件 このウォークスルーを実施するには、以下が必要です。 Systems Manager マネージドノード（カスタムインベントリ情報をキャプチャするための Amazon EC2 インスタンスまたは ハイブリッドノード ） アカウントで Systems Manager Inventory が有効化されていること マネージドノードにパッチを適用するための Systems Manager Patch Manager のスキャンまたはインストール操作 Admin pro または Author pro の Amazon Quick ユーザーアカウント CloudFormation StackSet を作成するために必要な権限 AWS Organization ID ウォークスルー AWS CloudFormation スタックを使用してソリューションをデプロイし、必要なリソースを作成します。CloudFormation スタックは、Organization 管理アカウントまたは StackSet の委任管理者アカウントからデプロイできます。中央の S3 バケット、Quick ダッシュボード、およびその他のリソースは、スタックをデプロイしたアカウントとリージョンに作成されます。 デプロイ後、 Amazon Quick を使用したビジュアルの作成 についての手順を説明します。 GitHub リポジトリから CloudFormation テンプレート をダウンロードし、 スタックをデプロイ します。 パラメータエリアで、以下のパラメータを入力します。 SSM Resource Data Sync and Custom inventory configuration セクション: Amazon S3 bucket: AWS Systems Manager リソースデータ同期に使用する Amazon S3 バケットの名前 Target type: カスタムインベントリアソシエーションのターゲットタイプ。すべてのインスタンスの場合は ALL、タグベースのターゲットの場合は TAG を指定し、次のパラメータにタグキーと値を入力します Tag key for targeting instances: 対象インスタンスのタグキー Tag value for targeting instances: 対象インスタンスのタグ値 AWS Accounts Options セクション: AWS Organization ID: AWS Organization ルート ID（r-xxx）または Organization Unit ID（ou-xxx） AWS Account IDs: Organization または OU にデプロイする AWS アカウント ID のリスト（アカウントは指定した Org/OU のメンバーである必要があります）。Organization または OU 内のすべてのアカウントにデプロイする場合は空のままにします AWS Account Regions: AWS リージョンのリスト 図 2: AWS CloudFormation パラメータ – Organization デプロイ Organization を使用せずにアカウントにデプロイする場合: AWS Organization ID: フィールドを空のままにします AWS Account IDs: デプロイする AWS アカウント ID のリスト（アカウントはいずれの Organization にも属していない必要があります） AWS Account Regions: AWS リージョンのリスト 図 3: Organization に属さないアカウント用の AWS CloudFormation パラメータ Amazon Athena セクション: Amazon Athena Database Name: AWS Systems Manager リソースデータ同期用の Amazon Athena データベース名 Amazon Quick セクション: Amazon Quick user: Amazon Quick のユーザー名を入力します Resources タブに移動して、CloudFormation スタックによって作成されたリソースを確認します。 CloudFormation のデプロイが完了したら、アカウント上の SSM インベントリアソシエーションの実行が完了するまで待ちます。デフォルトでは、インベントリアソシエーションは 30 分ごとに実行されます。インベントリの実行が完了したら、以下の手順に従って Glue クローラーを実行します。 AWS Glue クローラーコンソール に移動します 「SSM-GlueCrawler-*」で始まるクローラーを選択します Run を選択してクローラーを実行します Glue クローラーは、中央の S3 バケットからインベントリデータをクロールし、Glue データベース ssm_datasync_resources を更新します。 Quick ユーザーと権限の検証 Quick ユーザーロール: Amazon Quick コンソール に移動してサインインします 右上のユーザーアイコンを選択し、 Manage Quick を選択します Manage users を選択し、Quick ユーザーのロールとして Admin Pro を選択します 図 4: Amazon Quick ユーザーの権限 Quick の権限: 同じページの左メニューで、 Permissions の下にある AWS resources を選択します Amazon Athena と Amazon S3 を選択します。Select S3 buckets で、先ほどデプロイした CloudFormation テンプレートによって作成された Systems Manager インベントリおよびパッチ適用データ用の S3 バケットを選択します。また、Amazon Athena のクエリ結果出力先として設定した S3 バケットも併せて選択してください Save を選択します 図 5: Amazon Quick ロールの S3 バケットへの権限 Amazon Quick を使用したビジュアルの作成 Quick のホームページで、 Analysis を選択し、CloudFormation スタックによって作成された SSM Inventory Analysis を選択します Visuals の下にある Build アイコンを選択します。ビジュアルを構築するためのクエリを入力するサイドパネルが開きます 以下は、ビジュアルを生成するためのプロンプト例です。必要に応じてプロンプトやビジュアルをカスタマイズできます プロバイダー別マネージドノード このビジュアルは、さまざまなクラウドプロバイダーおよびオンプレミスインフラストラクチャにデプロイされたマネージドノードの数を表示し、プラットフォーム間のワークロード分布に関する洞察を提供します。 プロンプトとして「 Create a pie chart for count of resourceid by provider 」と入力し、BUILD を選択します または、「 Create a visual for count of resourceid by provider 」と入力して、Amazon Quick にビジュアルタイプを決定させることもできます Amazon Quick がビジュアルを生成します。 Add to Analysis を選択し、必要に応じてビジュアルのサイズを変更します 見出しをダブルクリックして編集し、「Managed Node by Provider」に更新します 図 6: Amazon Quick を使用したビジュアルの構築 ステータス別マネージドノード プロンプトとして「 Create a donut chart for count of resourceid by instancestatus 」と入力し、BUILD を選択します Add to Analysis を選択し、必要に応じてビジュアルのサイズを変更します。ビジュアルの見出しを更新します 以下に説明する他のビジュアルについても、異なるプロンプトを使用して同じ手順に従いビジュアルを生成します 図 7: ステータス別マネージドノード OS 別マネージドノード プロンプト: 「 Create a donut chart for count of resourceid by platformname 」 図 8: OS 別マネージドノード プラットフォーム別マネージドノード プロンプト: 「 Create a donut chart for count of resourceid by platformtype 」 SSM Agent バージョン プロンプト: 「 Create a visual for count of resourceid by version and application name equals Amazon SSM Agent 」 ディスク容量ステータス プロンプト: 「 Create a visual for count of resourceid by diskspacestatus 」 図 9: 運用ダッシュボード Amazon EC2 インスタンス固有のビジュアル 以下のビジュアルは、SSM カスタムインベントリアソシエーションから取得した Amazon EC2 インスタンスの詳細情報を表示し、さまざまな AWS 固有のコンポーネントとリソース構成に関する貴重な洞察を提供します。 以下は、ビジュアルを作成するためのプロンプトです。 AWS PV Driver バージョン プロンプト: 「 Create a visual for count of resourceid by application version and application name equals AWS PV Drivers 」 ビジュアルから null または empty データを選択し、 Exclude null を選択します。 Add to Analysis を選択してビジュアルを分析に追加します。これは、このビジュアルに該当しない他のプロバイダー（オンプレミスやハイブリッドノードなど）の null/空の値を除外するためです ダッシュボードにテキスト見出しを追加するには、ペインの上部にある Add Text アイコンを選択し、テキストを AWS Dashboard に変更します Amazon EC2 ENA Driver バージョン プロンプト: 「 Create a visual for count of resourceid by enaversion 」 AWS NVMe Driver バージョン プロンプト: 「 Create a visual for count of resourceid by nvmeversion 」 ライセンスタイプ別 Amazon EC2 インスタンス プロンプト: 「 Create a pie chart for count of resourceid by licensetype 」 インスタンスタイプ別 Amazon EC2 インスタンス プロンプト: 「 Create a pie chart for count of resourceid by instancetype 」 図 10: AWS EC2 メトリクスダッシュボード コンプライアンスシート コンプライアンスシートは、特にパッチおよびアソシエーションのコンプライアンスに焦点を当てたコンプライアンス固有の可視化を作成するために使用されます。ここでは、非準拠のパッチを強調表示するビジュアルを生成するとともに、不足しているパッチの包括的なリストを提供し、システムのセキュリティポスチャの明確な概要を示します。 シートの上部から Compliance シートを選択します 以下は、コンプライアンス固有のビジュアルのプロンプト例です パッチコンプライアンス別マネージドノード プロンプト: 「 create a pie chart for count of resourceid by compliance status for compliancetype equals Patch 」 アソシエーションコンプライアンス別マネージドノード プロンプト: 「 create a pie chart for count of resourceid by compliance status for compliancetype equals Association 」 プロバイダー別パッチ準拠マネージドノード プロンプト: 「 create a donut chart for count of resourceid by provider for compliancetype equals Patch and compliance status equal COMPLIANT 」 プロバイダー別パッチ非準拠マネージドノード プロンプト: 「 create a donut chart for count of resourceid by provider for compliancetype equals Patch and compliance status equal NON_COMPLIANT 」 OS 別パッチ準拠マネージドノード プロンプト: 「 create a visual for count of resourceid by platformname for compliancetype equals Patch and compliance status equal COMPLIANT 」 OS 別パッチ非準拠マネージドノード プロンプト: 「 create a visual for count of resourceid by platformname for compliancetype equals Patch and compliance status equal NON_COMPLIANT 」 不足しているパッチ プロンプト: 「 create a pivot table with provider, accountid, region, platformname, resourceid, patch title for compliancetype equals Patch and compliance status equal NON_COMPLIANT and patch status equal Missing 」 図 11: コンプライアンスダッシュボード ビジュアルが作成されたら、 Publish を選択してダッシュボードを公開します。さらに、Amazon Quick を活用して詳細情報を取得したり、ダッシュボードとインタラクションして質問に対する回答を得ることもできます。例えば、ディスク容量が危険な状態のマネージドノードのリストを取得するには、「 List of resourceid by diskspacestatus equal Critical 」というプロンプトで回答を得ることができます。 クリーンアップ リソースを削除するには: AWS CloudFormation コンソール に移動します Stacks を選択し、 ssm-inventory-patching-dashboard という名前のスタックを選択します Delete を選択し、 Delete stack を選択します Amazon Quick コンソール に移動します ダッシュボード、分析、およびデータセットを削除します まとめ このブログ記事では、Amazon Quick が Systems Manager のパッチ適用およびインベントリダッシュボードの作成をどのように簡素化するかを紹介しました。自然言語によるインタラクションを活用することで、かつては複雑で多段階のプロセスだった作業が、包括的な可視化を生成するシンプルで直感的なプロンプトに変わりました。このソリューションは貴重な時間を節約するだけでなく、クラウドおよびオンプレミス環境全体のパッチ適用コンプライアンス、インベントリステータス、インフラストラクチャ分布に関するリアルタイムの洞察を提供します。 さらに、Amazon Quick は自然言語プロンプトによるダッシュボードデータのインタラクティブなクエリを可能にし、特定の情報を素早く取得できます。AWS Systems Manager と Amazon Quick を含む AWS サービスの組み合わせにより、組織はハイブリッドインフラストラクチャの管理を強化しながら、監視とレポートのプロセスを簡素化できます。パッチコンプライアンスの管理、インベントリの追跡、AWS 固有のコンポーネントの監視のいずれであっても、このソリューションはインフラストラクチャの可視化と管理に対する合理化されたアプローチを提供します。CloudFormation テンプレートをダウンロードし、AI を活用した可視化を数分で実装して、今すぐインフラストラクチャ監視を変革しましょう。 AWS Systems Manager のパッチ適用機能の詳細については、 AWS Systems Manager Patch Manager のドキュメント をご覧ください。 Suhail Fouzan Suhail Fouzan は、Amazon Web Services（AWS）のスペシャリストソリューションアーキテクトで、IT 業界で 15 年以上の経験を持っています。Microsoft ワークロード、移行サービス、AWS Systems Manager を使用したオペレーション管理を専門とし、お客様のインフラストラクチャの AWS への移行を成功に導いています。仕事以外では、クリケットを楽しんだり、家族と過ごしたりしています。 Eswar Sesha Sai Kamineni Eswar Sesha Sai Kamineni は、Amazon Web Services のソリューションアーキテクトです。クラウドソリューションの設計を支援し、技術的なガイダンスを提供することで、お客様のビジネス変革を支援しています。George Mason University でデータアナリティクスエンジニアリングの学位を取得しました。AI と機械学習に深い関心を持っています。テクノロジーの新しい進歩について読んだり、ハイキングを楽しんでいます。 Rizwan Mohammed Rizwan Mohammed は、AWS のシニアテクニカルアカウントマネージャーで、エンタープライズのお客様が AWS サービスを採用し、新しいアーキテクチャを構築し、現在の実装を最適化するのを支援しています。クラウドオペレーションと Microsoft ワークロードを専門とし、お客様のオペレーショナルエクセレンスの向上に情熱を注いでいます。 翻訳は Solutions Architect の小野が担当しました。原文は こちら です。