こんにちは！ SCSK株式会社　小鴨です。 皆さん、今年のゴールデンウィークはいかがお過ごしでしたか？ 私は日本を遠く離れ、アメリカのラスベガスへ行って参りました。 目的はただ一つ… ServiceNow最大級のイベント Knowledge 25 　 への参加です！！ Access Denied www.servicenow.com 業界の最前線が一堂に会し、技術の未来を語り合う様子はまるで大きな科学博覧会。 私もそのワクワクする雰囲気の中で多くを学び、たくさんの刺激を受けました。 その経験をここで皆さんと共有したいと思います。 長くなるので複数本立ての予定ですが、気楽にのんびりと読んでもらえればと思います。 概要 「Knowledge」 とは、ServiceNowが主催する年次イベントで 企業や専門家が集まり、最新のServiceNowプラットフォームの機能や革新について学ぶ場です。 …それだけ聞くと ふーん、まあよくある技術者の集いみたいなものか と思われるでしょう しかしことKnowledgeについては桁外れのスケールで開催されます。   まず全体参加者が 約20000人！ 実施されるセッション数は 1000以上！！ こうなってくると逆にイメージが付きにくい数字かもしれませんね。   そして今年のテーマは「Where AI gets to work」 なぜAIを使う必要があるのか なぜServiceNowなのか 我々は何をする必要があるのか こうした情報をこれでもかと詰め込まれる3日間でした！   Knowledge25参加への道のり 申し込み イベントに参加するには当然申し込みが必要！！ ということで公式サイトより申し込みへ！ 2195円！うーん非常にリーズナブル♪　さすが外国の企業は太っ腹ですね！ …なわけないです2195＄です。安く見積もっても30万円こえてます… 気を取り直して 宿も同じサイトから予約できるので早速確認！ いや、こんなお城みたいなとこじゃなくていいですよ本当に… カプセルホテルに毛布だけおいといてくれれば十分なので… 正直なところ、開催一か月前ですが早速プレッシャーを感じ始めてました。 しょうもない成果しか持って帰らなかったらどんな目に合うのだろうと。。。 セッション予約 申し込みが終わったら参加するセッションの予約から始めます。 学生時代の時間割を組むような気分で、興味のある公演を片っ端から予約しました！ 我ながら計画性の無さすぎる時間組…移動時間を考えなさい… やる気の表れということでご愛嬌です ポイントは２つ 1つはキーワードでセッションを絞ること！ 私は実業務では「ITSM」,「ITOM」を使用しているので それらと「AI」タグが盛り込まれているものを重点的に選択しました。 2つ目は同時通訳に対応していること！ 英語に自信がある方は問題ないですが、そうでない方はこれを積極的に選びましょう。 私は英語のみのセッションにもいくつか参加してみましたが 終盤は何を言っているのか分からな過ぎて、もう笑うしかないみたいな状態でした。   いよいよ出国 飛行機にすごい時間揺られていたこと、乗り換えの時間はとにかく眠かったこと 入国審査が怖かったことなど… 思い出はいくつもありますが、そんなミクロな思い出には皆さん興味ないでしょう！ アメリカじゃなくても起こりうることなので、その辺はぐっと飲みこみ割愛させていただきます！ さてついに到着したラスベガス！ あれ？カジノって空港にもあるの？     いろんなものが目につきながらもタクシーに乗り市街地へ 第一印象は騒がしい街だなぁといったところです。 街中には常に音楽が鳴り響き、ネオンが所狭しと輝いており、誰もが常に楽しそうです。 しかし同時に、どこか上品さを感じるような雰囲気もありました。 白が目立つからなのか、道路が広いからなのか、閉塞感のようなものがなく 同じ騒がしい街でも、新宿や池袋とは違うなあという印象でした！   さて、いよいよ予約したホテルが近づいてきました。 正直「実物は予約サイトより数段しょぼいだろうな」と思っていましたね。 日本では何度も騙された手口だし今更驚きはしないぞと。     おぉ…あぁ… 実物の方がすごいパターンは初めてでしたね。 なんていうか身の丈に合わない世界というか、夢の中のような景色に終始圧倒されました。 この日は色々と新たな世界に触れてみたい欲求はあったものの 時差ボケや環境変化のストレスに負けないよう早々に就寝し、ウェルカムレセプションの待つ明日に備えました。 次回予告 次回はKnowledgeが始まる前の前夜祭的なポジションの「JAPAN welcome reception」からお話しします。 ◆日本人交流の場なので英語は不要と油断していたら、英語より難しい言語で話す人たち ◆ServiceNowマイノリティであることを突き付けられた弊社 ◆400人中5位になった私 あたりを語るに始まり Knowledge初日の様子なんかも一気に話せればと思います。 その2からも是非、のんびりとお付き合いいただければと思います。

こんにちは。SCSKの山口です。 今回はBigQuery の外部テーブル機能についてのブログです。 BigQuery の外部テーブルとは？ 概要 外部テーブル機能は、簡単に言うと、Google Cloud Storage (GCS) や Google ドライブなどの 外部データソースに保存されているデータを、BigQuery のテーブルであるかのように直接クエリできる機能 です。 実際のデータは BigQuery の管理下に置かず、外部のストレージサービス上のデータを参照します。これにより、データを BigQuery にロードする手間なくデータ分析が可能といったメリットがあります。 サポートされているデータ形式 BigQuery の外部テーブルは、以下の主要なデータ形式をサポートしています。 CSV (Comma Separated Values) JSON (Newline-delimited JSON) Avro Parquet ORC Cloud Datastore のエクスポート Cloud Firestore のエクスポート 本記事のデモでは CSV 形式を使用します。   外部テーブルを作成する 今回は、Cloud Storage上のCSV形式のファイルを外部テーブルとして作成します。 あらかじめ、Cloud StorageのバケットにCSVファイルを配置しておきます。   BigQuery 画面で外部テーブルを作成 実際に外部テーブルを作成します。 対象のデータセットを選択し、「テーブルを作成」をクリックします。 下記を入力し、「テーブルを作成」をクリックします テーブルの作成元：Google Cloud Storage ファイルの形式：CSV プロジェクト：（プロジェクト名） テーブル：（テーブル名） テーブルタイプ： 外部テーブル これで作成完了です。   詳細を見ると、ソースのURIなどの詳細情報が表示されます。   外部テーブルのクエリ実行 ここから、外部テーブルに対して様々なクエリを実行してみます。 全データを取得してみる SELECT * FROM `yamaguchi_test_exttable.ext_table_GCS`; 問題なくデータが閲覧できました。 フィルタリングしてみる SELECT id, name, value FROM `yamaguchi_test_exttable.ext_table_GCS` WHERE value > 20   AND name LIKE '%e'; 数値型、文字型ともにフィルタリングできました。 集計関数を使ってみる SELECT AVG(value) AS average_value, MAX(value) AS max_value, MIN(value) AS min_value, COUNT(*) AS total_records FROM   `yamaguchi_test_exttable.ext_table_GCS`; 集計関数も問題なく使用できました。   外部テーブルでできない事 ここまで外部テーブルでできることを列挙してきましたが、ここからはできない事を書きます。 外部テーブルは読み取り専用であり、BigQuery を介して直接的にデータを変更することはできません。 具体的には、以下のデータ操作言語 (DML) ステートメントは外部テーブルに対して実行できません。 INSERT (データの挿入) UPDATE (データの更新) DELETE (データの削除) MERGE (データの結合と更新/挿入) TRUNCATE TABLE (テーブル内のすべての行を削除) 外部テーブルのデータに対する変更は、元の外部データソースに対して行う必要があります。例えば、GCS 上の CSV ファイルの内容を変更したい場合は、BigQuery ではなく GCS のファイルを直接編集する必要があります。 外部テーブルの主な用途は、 外部に存在するデータを BigQuery の強力なクエリエンジンを活用して分析すること です。データの永続的な保存や頻繁な更新を伴う用途には、BigQuery のマネージドストレージ（通常のテーブル）の利用が推奨されます。 実際に外部テーブルに対してDMLステートメントを実行しようとすると、 エラーではじかれます。   まとめ BigQuery の外部テーブル機能は、GCS 上のデータを BigQuery にロードすることなく、手軽に分析できる非常に強力なツールです。データの柔軟性、迅速な分析開始、コスト効率などのメリットがあり、データレイクとの連携や ETL パイプラインの一部としても有効に活用できます。 今回のデモを通じて、外部テーブルの作成からクエリ実行までの基本的な流れをご理解いただけたかと思います。ぜひ、BigQuery の外部テーブル機能を活用して、より効率的なデータ分析を試してみてください。

こんにちは。SCSKの山口です。 BigQueryのビュー機能、皆さん使いこなせていますか？？？ BigQueryは優れた処理能力と柔軟性を持ち、大量のデータ分析を効率的に使用できるDWHサービスです。 そんな BigQuery をさらに便利にする機能の一つが 「ビュー (View)」 です。ビューは、データベースに存在する仮想的なテーブルのように振る舞いますが、 実際にはデータを物理的に保存しません 。このことによってさまざまなメリットを生み出します。 この記事では、BigQuery のビュー機能の基本的な概念から、具体的な活用例、そして知っておくべき重要なポイントまでを徹底解説します。今回ご紹介するビュー機能を使いこなすことで、 複雑なクエリをシンプルにする 特定のデータだけを安全に共有する データ分析のワークフローを効率化する 事ができます。 使用データ 今回検証で使用するデータです。 データセット名：yamaguchi_test_views テーブル名：source_table   ①標準ビュー ビュー作成方法 下記クエリを実行し、作成します。 -- ビュー作成クエリ CREATE OR REPLACE VIEW `yamaguchi_test_views.name_value_sum_view` AS SELECT name, SUM(value) AS total_value FROM `yamaguchi_test_views.source_table` GROUP BY   name; 重要なところを一般化します。 -- ビュー作成クエリ構文 CREATE OR REPLACE VIEW   `[プロジェクトID].[データセット名].[ビュー名]` AS SELECT   column1,   column2,   ... FROM   `[プロジェクトID].[データセット名].[テーブル名]` WHERE   condition; CREATE OR REPLACE VIEW：ビューを新規作成もしくは置き換えます AS：以降にビューの定義を開始します SELECT colmun…：ビューに含める列を指定します FROM：ビューの元となるテーブルを指定します WHERE（省略可）：ビューに含める行をフィルタリングするための条件を指定します ビュー作成クエリで出来上がったビューが下記です。 データ確認 ビューは、物理的にデータを保持するテーブルとは異なり、仮想テーブル的な振る舞いをするので、 「プレビュー」タブからデータを確認できません 。なので、データを確認するにはSELECTクエリを発行する必要があります。 ※仮想テーブルとはいえ、しっかりクエリ量は発生するのでご注意ください。 メリット 標準ビューを使うことによるメリットを書きます。   複雑なクエリを簡略化 今回は簡単なSQLで試しましたが、複数テーブルを結合したり、複雑な条件でフィルタリングしたりといった、 複雑なクエリ が実業務には登場します。 この 複雑なクエリ をあらかじめ標準ビューとして定義しておくことで、ユーザはビューに 単純なSELECT文を発行するだけ でデータアクセスできます。 今回の例でいうと、 上記データを見るために必要になるクエリが、事前のビュー定義の有無で変わってきます。 ビュー無 ビュー有 SELECT name, SUM(value) AS total_value FROM `yamaguchi_test_views.source_table` GROUP BY   name; SELECT * FROM   `yamaguchi_test_views.name_value_sum_view` どちらが楽か、、、一目瞭然ですね。 データアクセスを論理的に分離 特定のビジネスロジックに基づいたデータのまとまりをビューとして提供することが可能なので、 元となるテーブルを意識することなく データを利用可能になります。 大切な元テーブルのデータに 直接アクセスされることなくデータを共有 できるので、セキュリティの観点からもメリットが大きいです。 レポート作成の効率化 レポートを作成する際、必要なデータをあらかじめ整形済みのビューとして作成しておくことで、 レポート作成ツールからのクエリを簡潔にする ことができます。 例えば、Looker等でダッシュボードを作る際に、 開発効率を向上 させることができます。   ➁承認済みビュー ビュー作成方法 今回はソーステーブルと同じデータセット（yamaguchi_test_views）に承認済みビューを作成します。 まずは、標準ビューと同じクエリ構文でビューを作成します。 CREATE VIEW `yamaguchi_test_views.name_value_view` AS SELECT id, name, value FROM   `yamaguchi_test_views.source_table`;   次に「ビューの承認設定」を行います。 対象のビューが含まれるデータセット の「共有」タブから「ビューを承認」をクリックします。 ※対象ビューではなく「データセット」からの作業であることに注意してください。 「ビューを承認」に対象のビューを入力し、「承認を追加」をクリックします。 権限設定 ここまでの作業で作成したテーブル、ビューの状況を整理します。 source_table：個人情報あり（見せたくないデータがある元テーブル） name_value_view：個人情報なし（見せていいデータのみを抽出したビュー） 上記のデータセットに対して、下記アクセス制限をかけたいです。 管理ユーザ：どちらのにもアクセス可能 開発ユーザ：個人情報なし（name_value_view）の情報のみアクセス可能 では、ここから実際に権限設定していきます。 ※注意：開発ユーザはプロジェクト内に何も権限を持っていないところからスタートとします。 まず、開発ユーザに見立てたアカウントに「name_value_view」に対する「 BigQuery データ閲覧者」を付与します。 対象のビューのメニューから「共有」-「権限の管理」をクリックします。 「プリンシパルを追加」をクリックし、開発ユーザに「BigQuery 閲覧者」のルールを付与します。 以上で権限設定は完了です。 開発ユーザからのクエリ実行 開発ユーザからクエリを実行してみます。 ソーステーブルに対するクエリ ソーステーブルに対する権限は付与されていない のでデータが見れませんでした。 承認済みビューに対するクエリ 承認済みビューからはデータを見ることができました。 このように、承認済みビューを使用することで、 ソーステーブルに対する権限がないユーザでもビュー経由でのデータ取得が可能 になりました。これこそが承認済みビューの最大のメリットです。 ソーステーブル内の見せたくない情報は絞りつつ、開発ユーザへのデータ共有が実現できました。   ③マテリアライズドビュー ビュー作成方法 マテリアライズドビューは下記クエリで作成します。 CREATE MATERIALIZED VIEW `yamaguchi_test_views.name_value_sum_mv` AS SELECT name, SUM(value) AS total_value FROM `yamaguchi_test_views.source_table` GROUP BY name; 今回は、氏名（name）ごとに値（value）を合計した値の情報をマテリアライズドビュー化しました。 パフォーマンス比較 マテリアライズドビュー化した集計処理を、ソーステーブルに対して実行し、マテリアライズドビューの有無でのパフォーマンスを比較します。   ソーステーブルで集計処理 ソーステーブルに対して下記集計クエリを実行します。 SELECT name, SUM(value) AS total_value FROM `yamaguchi_test_views.source_table` GROUP BY   name; クエリ結果から、「実行の詳細」をクリックします。 実行にかかった時間、バイト数などを確認することができます。   マテリアライズドビューで集計処理 マテリアライズドビューに対して同様の集計クエリを実行します。 SELECT * FROM `yamaguchi_test_views.name_value_sum_mv`;   比較 両者を比較してみましょう   実テーブル マテリアライズドビュー 経過時間 220 ms 188 ms 消費したスロット時間 22 ms 15 ms 読み取り時間 21 ms 4 ms 比較的顕著な差が出た項目をピックアップしました。 マテリアライズドビューを使用した場合、特に、 「読み取り時間」 で顕著な差が出ています。 今回は小規模なデータでの検証ですが、数十億行を超えるような大規模なデータセットに対して、 頻繁に実行される集計クエリ（SUM, AVG, COUNTなど）の結果 をマテリアライズドビューとして事前に計算しておくことで、 大規模なクエリの実行時間を大幅な短縮 が期待できます。   ソーステーブルの変更を反映 マテリアライズドビューを作成した後、ソーステーブルのデータに変更があった場合も、 マテリアルビューは自動更新される仕組み になっています。 試しにソーステーブルにデータを追加してみましょう。 データ追加前の集計クエリ結果を確認しておきます。 ソーステーブルにデータを追加します。 INSERT INTO `yamaguchi_test_views.source_table` (id,   name,   value,   sensitive_info) VALUES   (6, 'Charlie', 35, 'PII_Charlie_2'); マテリアルビューで集計結果を確認します。 Charlieさんの値が変わっていることが確認できました。 ソーステーブルにデータを追加して数秒後にはデータが更新されていました。   まとめ 今回ピックアップしたそれぞれのビューの特徴、ユースケースをまとめます。 標準ビューのユースケース 複雑なクエリの簡略化: 複数のテーブルを結合したり、複雑な条件でフィルタリングしたりするクエリをビューとして定義することで、ユーザーは単純なSELECT文で必要なデータにアクセスできます。 データアクセスの論理的な分離: 特定のビジネスロジックに基づいたデータのまとまりをビューとして提供することで、基となるテーブル構造を意識せずにデータを利用できます。 レポート作成の効率化: レポートに必要なデータ整形済みのビューを作成しておくことで、レポート作成ツールからのクエリを簡潔にし、開発効率を向上させます。   承認済みビューのユースケース 機密性の高いデータの保護と共有: 個人情報や機密情報を含むテーブルから、特定のカラムを除外したビューを作成し、承認されたユーザーにのみアクセスを許可することで、安全にデータを共有できます。 特定のユーザーへのデータサブセットの安全な提供: 全てのデータへのアクセス権限を与えることなく、特定の条件でフィルタリングされたデータのみをビューとして提供できます。 データガバナンスの強化: どのユーザーがどのデータにアクセスできるかを明確に管理し、意図しないデータ漏洩のリスクを低減します。   マテリアライズドビューのユースケース 大量データに対する高速な集計クエリ: 数十億行を超えるような大規模なデータセットに対して、頻繁に実行される集計クエリ（SUM, AVG, COUNTなど）の結果をマテリアライズドビューとして事前に計算しておくことで、クエリの実行時間を大幅に短縮できます。 ダッシュボードやBIツールのパフォーマンス改善: リアルタイムに近いデータ表示が求められるダッシュボードやBIツールで、集計済みのマテリアライズドビューを参照することで、レスポンスタイムを向上させ、ユーザーエクスペリエンスを改善します。 頻繁に実行される集計処理の最適化: 定期的に実行されるETL/ELT処理の中で、集計結果をマテリアライズドビューとして保存しておくことで、ダウンストリームの処理を効率化できます。   検証を通して、それぞれのビューが持つ特性と、どのような場面でその特性が活かせるのかをご理解いただけたかと思います。ご自身のデータ分析の課題や要件に合わせて、最適なビューを選択し、BigQueryをより深く活用してみてください。

AWS CDK CLI v2.1017.0でドリフト検知コマンドが追加になりました！ 詳細はこちらをご確認ください。 https://github.com/aws/aws-cdk-cli/pull/442 今までAWS CDKではcdk diffというコマンドで手元のソースコードとAWS CloudFormationのスタックとの差分は検出できましたが、 実リソースとの差分（ドリフト）の確認ができないので苦労する場面がありました。 ですが、5/29のアップデートでcdk driftというコマンドが追加になりAWS CloudFormationのスタックと実リソースの差分をチェックすることが出来るようになりました。 cdk diff と cdk drift の棲み分けは以下の図のような形です。 使ってみた！ ＜バージョン確認＞ 事前に以下コマンドでアップデートしています。 npm update -g aws-cdk   ＜CDKリソースに手動設定＞ CDKでデプロイしたS3バケットに以下のタグを手動で設定しました！ ＜ドリフト検出＞ 以下コマンドで確認したところ、ドリフトを検知することが出来ました！ cdk drift スタック名 ソースコードは変更していないのでcdk diffコマンドでは差分検知はありませんでした。 また、オプションとして以下も追加されており、ドリフト検知時はデプロイを失敗させることもできそうです！ --fail Fail with exit code 1 if drift is detected [boolean] CDKで運用をやっていくとなると結構良いアップデートではないでしょうか？ 以上最新のアップデート情報でした！

こんにちは、SCSK株式会社の伊藤です。 いよいよ日本最大の “AWS を学ぶイベント”  AWS Summit Japan 2025 が近づいてきました！ SCSKはプラチナスポンサー として、スポンサーセッションでの事例紹介とブースの出展を行います。 今回は、特にブースの詳細をご紹介します！ 概要とスポンサーセッションの情報については、以前発信した記事に掲載していますので、ご確認ください。 AWS Summit Japan 2025に出展します！ SCSKは 2025/6/25(水)～6/26(木)開催の日本最大の AWS を学ぶイベント「AWS Summit Japan」に出展します。 SCSKセッションでは、”AIで振り込め詐欺を防止しろ!四国銀行の6ヶ月の挑戦”というテーマで、株式会社四国銀行様の開発事例をご紹介いたします。 blog.usize-tech.com 2025.05.12 まだご登録がお済みでない方はぜひご登録ください↓↓   「AWSで、夢ある未来を共に創る。SCSK 」 ブースのご紹介 SCSKブース(013P)では「AWSで、夢ある未来を共に創る。SCSK」をテーマに、お客様のAWS利活用ステージに合わせて貢献できる各種ソリューションを出展します。 SCSK独自ソリューションの4商材を展示 、 ミニシアターでは6つのAWS関連ソリューションから発表いたします。 展示商材のご紹介 各商材のブースでは、実際のデモンストレーションを交えてご用意しております。 実際の操作画面や使用シナリオを通じて、各ソリューションの具体的な機能や利便性を直接体験いただけます。各ソリューションがどのようにお客様のビジネス課題を解決するのか、より深く理解していただけることと思います。 展示商材 紹介 内製化支援 (テクニカルエスコート) クラウドサービスを活用したシステムを構築したいが、ノウハウがない。AWSの有識者がおらず、設計・構築に不安がある。クラウド利用におけるセキュリティ面に課題を感じている。このような課題を抱えている企業様も多いのではないでしょうか？ 「テクニカルエスコート」は、お客様のチームに寄り添い、クラウド技術活用人材を育成する、AWS専門家による伴走型内製化支援サービスです。 お客様のプロジェクトにAWS技術者がアドバイザーとして参画し、技術的な指導や課題解決のアドバイスを提供することで、クラウド案件をスムーズに遂行できる体制を支援いたします。                         そんな「テクニカルエスコート」が、AWS Summitにて「なんでも相談コーナー」として皆様のお悩みを出張解決します！ どんな些細なお悩みでもお気軽にご相談ください。AWSのスペシャリストがその場でサポートいたします。 AIソリューション (エージェント) InfoWeaveブースでは、AIエージェント プロトタイプのデモを体験していただけます。 このAIエージェントは、マルチエージェント環境で複数のエージェントが相互に連携することによって、自律的にタスクを実行することができます。これにより、ユーザーの目的を達成するための計画を自動的に策定し、必要なエージェントを組み合わせて複雑な業務を効率的に進めることが可能になります。 例えば、以下のようなことができます。 ・ログイン、フォームの入力、ボタンクリックなど、Webシステム操作の自動化 ・複雑な数値計算やデータの可視化などによる分析業務の効率化 ・複数のエージェントが連携して目的を達成 ぜひ、InfoWeaveブースにお立ち寄り頂き、AIエージェントの驚きの能力をご体験ください クラウドネイティブ (NebulaShift) NebulaShift（ネビュラシフト）は、持続可能な事業戦略を支えるクラウドネイティブ・オファリングとして、コンテナ技術を中核としたクラウドネイティブ基盤の構築、アプリケーションのモダナイズ、アジャイル開発の定着など企業のクラウドネイティブ化をトータルで支援します。   お客様のビジョンや事業構造に合わせたシステムのモダナイズ、マイグレーション、基盤設計・運用を提供し、豊富な実績を活かして最適なソリューションを提案します。 アジャイル支援やコンテナ化を通じて、お客様が本来注力すべき領域に専念できるよう、きめ細やかな支援をするNebulaShiftをご紹介いたします！ データ活用 (SCSKクラウドデータ用サービス) 「企業全体のデータ活用を加速させたい！ 部門間のデータサイロを解消し、ガバナンスもしっかり確保したい！」そんなお悩みをSnowflakeで素早く解決します。 Snowflakeのデータクラウド基盤とAWSを組み合わせた環境で、お客様のデータ価値がどのように最大化されるのかをご紹介します。さらに、SCSKのノウハウを集約したナレコレBIによる経営課題の可視化・分析、TROCCOを活用したノーコードでのデータ自動連携、Amazon DataZoneによるデータカタログ管理やコラボレーションが体験できます！   ミニシアターのご紹介 6つのAWS関連ソリューションについて、1日に各3回ずつ講演を行います。 最新の技術トレンドを交えながら、 SCSKの豊富なソリューションの特長やAWS活用について専門スタッフがご紹介します。 当日表彰される Japan AWS Top Engineerも多く登壇予定です！  ぜひお見逃しなく！ 商材名 紹介 AI駆動開発 【SIを再定義する ～若手エンジニアが語るAI駆動開発基盤の舞台裏～】 従来のシステム開発（SI）の概念を根本から変革する、AI駆動型の開発アプローチが登場しています。本セッションでは、AI駆動開発を組織に定着させるための仕組みであるAWSネイティブサービスを活用した「AI駆動開発基盤」の技術的知見や成功のポイントを解説します。システム開発に携わっている事業部門のマネージャー・SIプロジェクトリーダー・アプリケーション開発者まで、幅広い方々におすすめです。 本セッションの見どころ 従来型SIとAI駆動開発の違い AI駆動開発を組織に根付かせるために必要なこと 技術的課題と乗り越えるための実践的なアプローチ さらに実際のデモやユースケースを交えながら、AI駆動開発の効果を体験いただけます。 AIエージェント（InfoWeave） 【InfoWeaveで始めるAIエージェント – 新しい形の業務効率化】 AIエージェントとは、人が設定した目標を達成するために必要なタスクを自律的に生成し、計画的に実行するAIシステムです。ユーザが最終目標を提示するだけで、AIエージェントが「目的達成に必要なタスクの洗い出しと実行計画策定」と「計画に基づいたタスクの順次実行とエラー時の再試行」を自動で遂行することができます。 従来のチャットボット型の生成AIは単にユーザとの対話に応じるものですが、AIエージェントはあたかも数名の専門家やスタッフが協力してタスクを効率よく進めるように動作します。 生成AIを活用した効率的な開発、データ分析を考えているお客様 是非AIソリューション紹介ブースへお立ち寄りください！ クラウド移行 (ITX リフト版＋CN版＋USiZE) 【あるぞ　クラウド移行のソリューション　 ITX for SCSKのススメ】 AWS移行を漏れなく、網羅的に促進する為のソリューションパッケージです。 クラウドへの移行や有効活用に向け様々な課題をお持ちの皆様、是非当社のクラウド移行ソリューション（ITX for SCSK) 紹介ブースへお立ち寄りください！ 当社の特色であるハイブリッドクラウドを実現する為のソリューション群と事例、クラウドネイティブ化を支援する内製化支援サービスを中心にご紹介させて頂きます。 クラウドデータベースマイグレーションサービス 【～SCSKのDB移行の技術とノウハウを集約！～ ITX for MCP SCSK版　クラウドデータベースマイグレーション対応 の全貌】 データベースのAWS移行について、課題はありませんか？ SCSKは、2025年3月にITX for MCP SCSK版　クラウドデータベースマイグレーション対応版を発表しました。本サービスは、総合的なデータベースの移行アセスメントにより、データベースの最適な移行を選定・実施し、移行後の最適化、変革、データ活用まで対応したサービスを、お客様の個々の要望に合わせ提供するサービスです。 これまでDB移行サービスで培ってきたDB移行の実績に加え、AI活用を含めた新しい取り組み、移行後の更なる活用を取り込んだ幅広いDBサービスになっております。 AWS環境へのDB移行に少しでも興味のある方、是非ご参加ください。 SCSKクラウドデータ活用サービス 【SCSKクラウドデータ活用サービス データ活用の壁はこうして打ち破る！～SnowflakeとAWSで実現するデータドリブン経営～】   本セッションでは、企業が全社データ活用を推進する際に直面する課題を踏まえ、部門間のデータサイロを解消しながらガバナンスを確保するSnowflake中心の解決策をご提案します！ 基盤構築から高度なデータ活用までをご支援するSCSKクラウドデータ活用サービスを利用しながら、Snowflakeのデータクラウド基盤とAWSを組み合わせた環境で、TROCCOによるノーコードでのデータ連携やAmazon DataZoneによるデータカタログ管理を組み合わせることで、システム部門の運用負荷を軽減しながらデータガバナンスを強化し、お客様のデータ価値を最大化する方法をご紹介します。 SuccessChain  for DataPlatform 【製造業向け 業務データプラットフォーム ​ データから得たインサイトを活用し業務改革と効率化を推進 ​ 可視化を定着しサプライチェーン最適化】 データドリブン経営への第一歩を、SCSKと共に！ 本セッションでは、SCSKが提供する製造業向け業務データプラットフォーム「SuccessChain for DataPlatform」をご紹介します。 このサービスは、サプライチェーンに分散する業務データを集約し、業務課題を可視化することで、経営の高度化と業務効率化に貢献します。 こんな課題をお持ちの方におすすめです データを活用できる人材が社内に増えない データの使い方が分からない 最適なサプライチェーンや在庫管理の真の課題が見えない 必要データが集まらず、分析が進まない データ活用の仕組みや基盤が整っていない データ活用による課題解決・経営変革を、SCSKと共に実現しませんか？ ぜひ本セッションで、お待ちしております 当日は、【013P】ブースでお待ちしております！ こちらのユニフォームを着たスタッフがお待ちしております。 それでは、皆様の来場を心よりお待ちしております！

こんにちは。SCSKの松渕です。 Google Cloud Data & AI Summit ’25 Springに参加してきたので、イベントの内容と感想を投稿します。 セッションはピックアップしてお届けいたします！ Google Cloud Data & AI Summit ’25 Springとは このイベントは、Google Cloudが主催するデータ分析と人工知能に関するイベントです。最新のGoogle CloudのデータおよびAIテクノロジーの発表、成功事例の共有、専門家によるセッション、そして参加者間のネットワーキング（懇親会）が提供されます。 会場は渋谷ストリームにあるGoogleオフィスで、活気に満ち溢れ、最新技術への期待感と熱気が充満していました。 イベントレポート Opening セッション タイトル：生成 AI はデータドリブン経営の救世主か？ ~ Google Cloud が考える Data x AI、ビジネス プロセスの融合 発表者：GoogleCloud 内容 日本のデータドリブン経営は64か国中64位というショッキングな数字のスライドから発表スタート。 LLMがコモディティ化する中で、鍵となるのは強固なデータ基盤であり、各企業のデータがビジネスの源泉となることが強調されました。生成AIを個人の業務効率化に留まらず、抜本的な業務プロセス改善に繋げるためには、以下の3つの要素が重要であると提言されました。 ① Real-Time (リアルタイム性): VUCA（変動性、不確実性、複雑性、曖昧性）の時代において、最新データに基づいたタイムリーな判断が必要不可欠であり、Googleはそのため多数のツール/サービスを提供していることが紹介されました。 ② MultiModal (マルチモーダル対応): 企業活動において生成されるデータの約80%が非構造化データであるという現状が示され、そのためマルチモーダルに最初期から対応しているGeminiと、それとシームレスに連結できるGoogle Cloudに大きなメリットがあることが説明されました。 ③ Agentic (エージェント性): 多数のインプット箇所からのデータ統合、データのクレンジングや複雑なデータ分析、将来のデータ予測などをAI Agentを活用して自然言語で実施できる体験がデモを通じて紹介されました。 セッションの感想 80%を占める非構造化データをビジネス活用するとき、GoogleCloudのBigQuery及びGeminiを筆頭とする関連サービス群が非常に強力だと感じた。 セッション1: 生成 AI が拓くデータ活用の新境地：Google Cloud の「データ エージェント」とは？ 発表者：GoogleCloud 内容 Openingセッションの内容を技術的かつ具体的に踏み込んだ内容でした。AIエージェントは以下の3つから成り立っているとのこと。 Model（基盤モデル） Tools（他APIやサービスとの連携） Orchestration（フロント部分。Toolsとモデルの橋渡しや、プロンプトの理解と応答）   また、エージェントは複数が組み合わさってタスクが実行されるようになっていくとのことです。その中で、GoogleCloudはデータ関連エージェントとして以下の4つのエージェントを発表済もしくは今後発表予定であることが示されました。 DataEngineeringAgent: データパイプラインの作成、データキュレーション、データクレンジングなどを自動化します。 DataGovernanceAgent: 信頼できる唯一の情報源を作成し、メタデータの自動作成、自動異常値検出、データリネージ追跡などを可能にします。 DataScienceAgent: ノートブック上でデータラングリングやデータ探索、モデル作成などを支援します。 ConversationalAnalyticsAgent: Looker Studio Proで利用可能で、対話型でのデータ分析および可視化を実現します（APIでの提供も予定）。 独自Agentを構築する場合、Agent部分はADKというフレームワークを、MCP部分はOSSであるMCP Toolbox for Databaseというフレームワークを使うと効率的な開発が可能であると紹介されました。 アーキテクチャへの影響とビジネスへの変革については、各種データエージェントは、いわゆるメダリオンアーキテクチャを大きく変えることはなく、全ての階層で効率化がなされるだけのため、現状のアーキテクチャは利用可能であると説明されました。これにより、データ発生から価値を出すまでの期間が圧倒的に短くなるとのことでした   セッション感想 自然言語でここまでデータ分析が可能になる未来が楽しみになりました。 特に、DataGovernanceAgentのメタデータの自動作成は非常に魅力的でした。メタデータをしっかり作っていくのはデータ活用において非常に重要と理解しつつも、手間がかかることや、ルール統一・周知徹底が難しく現実的ではないケースがあると考えていました。それをAIが補完してくれることで、効率的なデータ分析に大きく寄与すると感じました。 セッション2:データが拓く、新たなロッテ：BigQuery を中心としたデータドリブン変革 発表者: 株式会社ロッテ 内容 内製化によるデータ分析の実績とその課題、今後の展望について詳細に語られました。 特に、DX寺子屋を定義して人材育成に力を入れ一定の成果を収めたものの、それがゆえにプロジェクトが増加。また、管理面のスキル不足による人材不足に陥ったとのことでした。 それらの課題解決のため、管理コスト削減やCI/CD環境構築といったアーキテクチャの改修を行ったとのことです。 興味深かったのは、DWHはBigQueryに統一しつつも、BIツールはあえてロックインされないよう乱立状態を維持しているという点でした。     内製化の例として、食堂の喫食数予測。このシステムはなんと1年目の社員の方が内製で作ったそうです！素晴らしいです。   今後は非構造化データをビジネス活用するため、AI Agent時代を見据えて非構造化データの収集の仕組みを構築しているようです。 セッション感想 内製化推進に成功した結果、プロジェクトが増加し、逆に人材不足に陥り外部ベンダーへの委託も増えたという話は、非常にリアルで考えさせられました。 ビジネス部門から「業務を理解し、考えて仮説立ててから話もってこい」というお叱りを受けたというエピソードは、自身の仕事を振り返る上で心に刺さるものがありました。 懇親会の様子 イベント終了後の懇親会では、ビールやチューハイなどのドリンク、そして美味しい食事が提供され、参加者間の交流を深める良い機会となりました。 「Ask the Speaker」コーナーやGoogle Cloud社のエキスパートと直接会話できるコーナーも設けられており、セッションでは聞けなかった疑問を解消したり、より深い議論を交わしたりすることができました。 開始30分ほどで徐々に人が減り始めたため、最初は難しかったエキスパートとの会話も、食事をしながら時間を置くことでじっくりと話すことができ、貴重な情報交換の場となりました。 まとめ 今イベントを通して感じた Google Cloud の展望について Google Cloudとしては、非構造化データのビジネス活用を強力に推進していく意思を強く感じました。 マルチモーダル対応かつ自社開発でBigQueryとのシームレスな連携が可能なGeminiとGoogle Cloudの組み合わせは、非構造化データの利活用という意味では強力な武器であり、GoogleCloudは推していくと感じました。 また、Geminiの優位性は、コストとマルチモーダルという点も再認識しました。 LLMの進化は日進月歩であり、他LLMとの性能比較は日々変化すると思いますが、Geminiはコストパフォーマンスという点とマルチモーダルという観点では一貫して優位性があるという印象を受けました。マルチモーダルは多くのLLMでも対応していますが、200万トークンという入力トークンサイズによりマルチモーダルなデータインプットへ幅広く対応できると感じました。 最後に データエージェントはまだロードマップ段階のものが多いですが、リリースされた際にはすぐにでも使ってみたい機能ばかりでした。特に自然言語でデータパイプラインを構築できる機能は非常に魅力的であり、実務への導入を積極的に検討していきたいと考えています。 また、今回のイベントを通じて、非構造化データのビジネス活用が今後ますます重要になってくると強く感じました。今後も学習とアウトプットを続けていきたいと思います！

こんにちは SCSKの庄司です。 今回は、ServiceNowの注文ガイド機能の基本を紹介していきます。 本記事は執筆時点（2025年5月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。 注文ガイドとは？ 注文ガイドとは、複数のアイテムを生成する1つのサービスカタログ要求を送信するための機能です。 これを使うと「新入社員の受け入れのための一連の申請」としてPC、モニター、社用携帯、メールアカウント作成等といった複数のサービスカタログアイテムを一連の流れで選択・同時注文できるようになります。 また、ユーザー側としても一つのシナリオに際してあれこれ必要な申請を1つの画面で一度に送信できるため手間が省けるほか、申請漏れのリスクなども軽減することが可能です。   注文ガイドの基本動作 では、さっそく注文ガイドには具体的にどのような動作をするのか見ていきましょう。 今回は、New HireというPDI環境に搭載されている注文ガイドを使います。 ※一部英語のままだった個所を私の判断で日本語に翻訳しました。皆さんのPDIとは異なる場合があります。 こちらが注文ガイド画面になります。 基本的に注文ガイドは3ステップで構成されています。 ①「ニーズを説明」画面 「ニーズを説明」画面には説明が記載されています。 また、必要なカタログアイテムを特定するための変数を用意することもできます。 必須の項目を入力すると、画面右下[次へ]ボタンが活性化され、押下すると「オプションを選択」画面に遷移します。 ②「オプションを選択」画面 ここで個別のアイテムに対して項目を入力したり、右側のボタンのオン/オフに応じて必要のないアイテムを申請から外すことも可能です。 ここで自動選択されるアイテムは「ニーズを説明」画面の項目の入力内容に応じて変更することも可能です。 例えば、今回「リモート勤務の社員ですか？」という項目で「はい」を選択すると、「オプションを選択」画面の「Desk Set Up」というアイテムが表示されなくなっています。   今回は「リモート勤務の社員ですか？」という項目で「はい」を選択した状態から、「Standard 27″ Monitor」を外した状態で[次へ]を選択します。 ③「サマリー」画面 注文ガイド送信前の内容確認画面です。 申請対象として選択したアイテムを確認できます。 先ほどオプションから外した「Standard 27″ Monitor」には「含まれていません」の表示がされています。  内容が問題なかったら[今すぐ注文]を押下し、注文を実施します。 要求サマリー画面に遷移しましたが「Standard 27″ Monitor」は含まれておらず、他の3つのアイテムの要求が送信されていることがわかります。 ここまでが注文ガイドの大まかな動きになります。   注文ガイドの設定 ここからは注文ガイドの機能について紹介していきます。 ただし、通常のカタログアイテムと共通している部分も多くあるため、今回は注文ガイド独自の部分に限りお話ししていきます。   1. ルールベース  ルールベース関連リストでは、注文ガイド内に含める個別のアイテムを定義するためのレコードを作成します。 事前に作成してある個別のカタログアイテムを、注文ガイドと紐づけるイメージです。 先ほど注文ガイドの基本動作の説明に使用した「New Hire(新規雇用)」のルールベース関連リストは上記のようになっています。 「Standard Laptop」、「Standard 27″ Monitor」、「Desk Set Up」など、見たことのあるアイテムが並んでいますね。 また、ルールベースには「この条件が true の場合」という項目で、そのルールベースに対応するアイテムが選択されるための条件を設定することができます。 先ほど「リモート勤務の社員ですか？」で「はい」を選択した際に「Desk Set Up」が注文ガイド内から外されていたのは、「Desk Set Up」の条件が「「リモート勤務の社員ですか？」が「いいえ」の場合に表示する」になっているためです。 「Desk Set Up」のように「ニーズを説明」画面の変数とルールベースの「この条件が true の場合」を利用して、要求するアイテムを柔軟に変更させることで様々な顧客のニーズに対応した注文ガイドを作成することが可能になります。   2. アイテム変数のアサイン ルールベースレコードの関連リストとしてアイテム変数のアサインがあります。 アイテム変数のアサインには、割り当てタイプが「注文ガイド変数」の場合と「値」の場合の2通りの使い方があります。 割り当てタイプ：注文ガイド変数 割り当てタイプで注文ガイド変数を選択している場合は、注文ガイドの変数の値をルールベースのカタログアイテム内変数にすることができます。 アイテム変数にはルールベースのカタログアイテム内変数を、注文ガイド変数には注文ガイド内の変数を選択します。 上記レコードを送信した後、指定した注文ガイド変数に「アサイン変数のテスト」と入力します。 「オプションを選択」画面に遷移後、指定したアイテム変数を確認すると先ほど入力した文字列が自動入力されています。 この機能を使うことで、注文ガイド変数とアイテム変数とで同じ内容を入力させる際に一回の入力で複数項目に入力させることができるため、冗長な作業をなくして作業を効率化したり、自動入力にすることで入力ミスの可能性も低減させることができます。 非常に有用な機能です。 ただし、この機能の注意点として参照タイプの変数と1行テキストの変数のように変数タイプ違いだと対応できない場合があります。 割り当てタイプ：値 割り当てタイプで値を選択している場合は、固定の値をアイテム変数に自動入力することができます。 試しに、先ほどと同様のアイテム変数に対して「アサイン変数のテスト2」という値を設定します。 ポータルの注文ガイド画面を確認しに行くと、指定したアイテム変数に「アサイン変数のテスト2」という値が自動入力されています。    割り当てタイプが値の場合は、指定したアイテム変数のタイプに応じた値を設定することが可能です。 以下はsys_userテーブルを参照している変数の場合の画面です。 この注文ガイド経由で申請する場合、このアイテムのこの変数はこの値で固定、という場合に役立てることができそうです。   3. カスケード変数 この値がTRUEの場合、同じ変数名の変数間で入力値を共有することが出来ます。 カスケード変数をTRUEにしたのでカタログアイテム「New Email Account」に用意されている変数「Preferred Email address（変数名：new_email）」と同じ変数名の変数を注文ガイド側にも用意し、適当な値を入力します。 [次へ]を押下し「オプションを選択」画面に遷移すると、「New Email Account」の変数「Preferred Email address（変数名：new_email）」に同様の値が自動で入力されています。   イメージは上で紹介した割り当てタイプ：注文ガイド変数のアイテム変数のアサインとかなり似ています。 相違点としては、アイテム変数のアサインは変数名が異なっていても使用できるが、カスケード変数は変数名が同一の変数間でのみ入力値の共有が可能という点があります。 一方で、カスケード変数はチェックボックスをTRUEにするだけで複数のカタログアイテムに跨って入力値を共有することができます。 アイテム変数のアサインはルールベースごとに設定が必要になるので、複数のカタログアイテム間で共通の変数を所持している場合はカスケード変数を利用し、その他の変数間で値の共有をスポット利用したい際はアイテム変数のアサインを利用するという使い方がベストに思います。   4. 含めるかどうかの切り替えを表示 この値のTRUE/FALSEに応じて、注文ガイドの基本動作でも紹介した「オプションを選択」画面のアイテム右側にあるボタンの表示/非表示を設定できます。 TRUEの場合 FALSEの場合   この値をFALSEにすることで本来必要なアイテムが外されてしまうことを防ぐことが可能です。 ただし、その場合はオプションのアイテムの要否を「ニーズを説明」画面で詳細に確認しておく必要があります。   5. 2ステップ この値がTRUEの場合、注文ガイドの要求送信までのステップをデフォルトの3ステップから2ステップに短縮します。 まずは3ステップの場合から見ていきます。 先ほど紹介したポータルでの動き同様「ニーズの説明」画面から始まり、「オプションを選択」画面に遷移します。 「オプションを選択」画面で必要項目へ入力を実施し、[チェックアウト]ボタンを押下します。 チェックアウト画面に遷移しますが送信前に最終確認が入り、ここで再度[チェックアウト]を押下すると要求が送信されます。   このように、3ステップの注文ガイドではサービスポータル同様、以下の流れで要求が送信されます。 ①ニーズを説明　⇒　②オプションを選択　⇒　③最終確認　⇒　④要求の送信(注文ステータス画面) 一方、2ステップの場合は以下のようになります。 3ステップ同様、「ニーズの説明」画面から「オプションを選択」画面に遷移します。 ここで、[チェックアウト]を押下すると最終確認の画面が飛ばされ、要求が送信されて注文ステータス画面にまで遷移します。   このように、「2ステップ」の注文ガイドは以下の流れなります。 ①ニーズを説明　⇒　②オプションを選択　⇒　③要求の送信(注文ステータス画面) 注文を速度重視にするか、安全性重視にするかで2ステップと3ステップを使い分けることができそうですね。 ただし、この2ステップ機能については現状だとサービスポータルには反映されないようなので注意が必要です。   6. すべての質問のヘルプを展開 この値をTRUEにすると、各種変数に存在するヘルプテキストを、変数上での「常に展開する」項目のTRUE/FALSEに関わらず該当の注文ガイド上では展開させた状態にさせます。 FALSEの場合 TRUEの場合 ただし、個別のアイテム内のヘルプテキストは対象にならない点には留意が必要です。 あくまで「注文ガイド」内の変数、変数セットに対してのみ効力を持つようです。     まとめ 以上が注文ガイドの基本になります。 注文ガイドは、ユーザーが1つのシナリオに対して複数の申請を一括で行える、非常に便利な機能です。 今回ご紹介した基本機能に加え、スクリプトなどを活用することで、さらに柔軟で効率的な申請フォームを構築することも可能です。 また、詳細は別途ご紹介予定ですが、特定のプラグインを追加することで、注文ガイド内で申請内容に順序をつけることもできます。 新入社員の受け入れや異動対応など、複数のリクエストが発生しやすい業務においては、特に効果を発揮します。 業務効率化の一手段として、ぜひ導入を検討してみてください。

皆さま、こんにちわ。社内でOCIプリセールスを担当しております、越水と申します。 2025年度はOracle Cloud Infrastructure（以後、OCI）に関するブログ記事を定期的に発信していこうと思い、 この度、キーボードとマウスを取りました。どうぞよろしくお願い致します。 記念すべき一つ目の記事ですが、2024年12月に当課内のOCI技術担当者が行った、オラクルの生成AI戦略における重要ピースである「OCI Generative AI（RAG Agent）」「Oracle 23ai（Vector Search）」「Autonomous Database（ADB）」の3つの要素を組み合わせた検証を行いましたので、その概要について触れたいと思います。 本記事では、OCIのAI関連技術の最前線と、その業務適用の可能性について、実際の構築と検証を踏まえてご紹介します。 検証の背景と目的 私たちは主にOracle Database、Oracle  H/W、OCIを取り扱っており、以下のミッションを持って日々、業務を行っています。 OCIやOracle Databaseの新機能を深く理解すること OCIの機能をキャッチアップし、社内外への提案力を強化すること 最近はOCIの検証環境を使った技術検証やサービス開発に取り組んでおります。 今回は、流行りの生成AI系のサービスについて検証を行ってみることとして、当課で持つOCI環境上で以下の3つのサービスを統合した実環境を構築し、技術検証を行うことにしました。 OCI Generative AI RAG Agent （生成AIによるエージェントサービス） Oracle 23ai Vector Search機能 （Embedding × 高速検索） Autonomous Database（ADB） 上に構築したナレッジベース 検証内容と構成 今回の検証で構築した全体構成は以下の図となります。 ステップ①：RAG Agent の環境構築 OCI上に生成AIエージェントを構築。 ステップ②：ADBとの統合 Vector Searchのインデックス対象となるベクトルデータは、ADB上に格納。 Object Storageからデータを取り込み、ベクトル化し、検索用インデックスとして利用。 ステップ③：Vector Search連携 RAGのナレッジソースとして、23aiの Vector Search機能 を使う構成を検証。 独自ナレッジをEmbeddingし、類似検索の結果をもとに生成AIが回答する設計です。 システム全体像（構成のポイント） データ格納 ：Object Storage → ベクトル化 → Vector Store（ADB内） 検索＆生成 ：RAG AgentがVector Search結果をもとに自然文生成 オーケストレーション機能 ：Agent間の連携も可能（今後拡張予定） 実際の業務適用を見据えて 本検証では、以下のようなユースケースを想定しました。 我々が日々行うOracle保守業務における「問い合わせ履歴」をナレッジ化し、RAGで問い合わせへの回答の支援ができるか？ この仕組みを実用化できれば、 社内ヘルプデスク・FAQ対応の効率化 や、 技術ナレッジ共有の自動化 の前進が期待できます。 まとめ 今回は、「OCI Generative AI（RAG Agent）」「Oracle 23ai（Vector Search）」「Autonomous Database（ADB）」の3つの要素を組み合わせた検証環境の概要を説明しました。 次回は、23ai ベクトルデータ取り込みからVectorSearchを実施するまでの流れについてのブログ記事をアップロードしたいと思います。

Catoクラウドのイベント・セミナー関連の情報です。   はじめに   SCSK では、 Cato クラウドのデモセミナーとハンズオンセミナーを実施しています。 デモセミナー（ウェビナー /2 時間）では、 Cato クラウドの完全に統合された管理画面をご覧いただくとともに、ユースケースを交えたデモをご覧いただいています。 ハンズオンセミナー（オンサイト / 半日間）では、実際に Cato クラウドを操作いただき、圧倒的な使いやすさを体感いただきます。   各セミナーの解説をした過去ブログがございますので、ご興味ある方はこちらもご覧ください。 【12/５開催】 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 開催レポート – TechHarmony Catoクラウド 1Dayハンズオンセミナー潜入レポ！ – TechHarmony   本日は、これまで実施してきた Cato クラウドデモセミナーについてご紹介します。   Cato クラウドデモセミナーとは   Cato クラウドデモセミナー（以下、デモセミナー）は、タイトル通り、2時間のデモンストレーションで主要機能を網羅いただくコンテンツです。 ある回のアジェンダは以下の通りです。 。 ほぼ全ての回でライブ QA 対応をしています。多いときは、2時間のセミナー中に40件ほどのご質問をいただき、複数名の Cato 担当エンジニアが リアルタイム回答を実施させていただいています。   データ集計結果の一部をお見せします   デモセミナーのデータ集計結果を用いて、宣伝を兼ねたコメントをあれこれしていきます。   Cato クラウドをご存じですか？ 以下、結果です。 概要を知っているという方が6割近くいらっしゃいます。 前提として、デモを求めてご参加される方が多いため、このような結果になっていると思いますが、 実はデモセミナーは Cato クラウドをまだあまりご存じない方もご参加しやすい内容となっていますので、 残りの４割の方も十分にご満足いただけるセミナーです。     デモセミナーの感想を教えてください 以下、結果です。 デモだけで２時間といった長丁場のセミナーで、「良かった」以上のご評価が95％を占めているのは、本当に嬉しい結果です。 「あまり良くなかった」以下の 5 ％の主な原因は、ユーザー様のコメントを読ませていただくと、 ウェビナーの音質（サウンド設定）によるものがいくつかありました。都度、コメントを読んで改善させていただいています。 今後はより多くの方に「大変良かった」を選んでもらえるよう、デモセミナーの改修も進めています。     デモセミナーで、特にご関心をお持ちいただいた項目を教えてください 以下、結果です（項目はアジェンダ順となります）。   項目間にあまり差がありませんが、中でも最も票が多い「 Cato 管理ポータルの概要」は、デモセミナーで特にご覧いただきたい部分です。 Cato クラウドの完全に統合されたシンプルでユーザービリティに優れた管理ポータルは、これから始めて SASE および Cato クラウドを ご検討される方にもご評価いただけるポイントだと思っています。   また、次に票が多いのが「 CASB の設定と利用例」で、当社としては納得の結果となっています。 Cato クラウドのご提案やご契約の中で、セキュリティオプションの CASB は、他のオプションと比較して特にニーズがあります。 これまで CASB 未導入の方も、 Cato クラウド導入を機にまとめてご検討いただいている印象です。   お申込み / ご参加の方の都道府県別割合 以下、結果です （ 1% 未満は記載を割愛させていただいています）。 *SCSK Cato 担当調べ   ウェビナーにもかかわらず、東京都の方が圧倒的に多いようです。これは、 Cato クラウドに限らず、 SASE や IT 全般に言えることではないかと思います。   Cato クラウドをもっと知っていただきたい！   ご紹介させていただいたようなご評価や改善ポイントをふまえ、より多くの方にデモセミナーをお届けしたいと思います。 ということで、今期（ 2025 年4月～ 2026 年3月）も開催します！   デモセミナーにつきましては、6月以降、ほぼ毎月開催いたします。ご興味をお持ちになったタイミングでいつでもご参加ください。   ＼＼　新着公開　／／ 　2025年 6 月2 5 日  （水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2025/20250625.html 　2025年 7 月 30 日  （水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2025/20250730.html 　2025年 8 月 27 日  （水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2025/20250827.html 　2025年 9 月 24 日  （水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2025/20250924.html 　2025年 10 月 29 日（水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2025/20251029.html 　2025年 11 月 26 日（水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2025/20251126.html 　202 6 年 1 月 28 日  （水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2026/20260128.html 　202 6 年 2 月 25 日  （水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2026/20260225.html 　202 6 年 3 月 25 日  （水）1 5 ：00-1 7 ：00　 https://www.scsk.jp/event/2026/20260325.html   Cato クラウドも日々進化し、管理画面もアップデートがございますので、 SCSK もなるべく最新の環境でデモをお見せしたく考えています。 これまでも改修を加えており（ ver.1 から ver.2 ）、7月回は ver.3 のリリース予定です。初めての方も、お久しぶりの方も、奮ってご参加ください。   おまけ   ハンズオンセミナーももちろん開催します。 前述のデモセミナー参加者都道府県別割合をふまえ、東京・大阪・北海道（札幌）・福岡（博多）を開催地としてご設定させていただきました。 毎回満席となる東京・大阪につきましては、 2 回ずつの開催となっています。 全ての都道府県に出向けず申し訳ありませんが、ぜひ最寄りの会場へお越しいただけますと幸いです。     ＼＼　新着公開　／／ 　2025年7月24日 （木）13：00-18：00 東京① https://www.scsk.jp/event/2025/20250724_2.html 　2025年7月31日 （木）13：00-18：00 大阪① https://www.scsk.jp/event/2025/20250731.html   ＼＼　先行公開　／／ご希望の方、申し込みサイトオープンをお待ちください。 　 2025年9月11日  （木） 13：00-18：00 博多 　 2025年10月*企画中   　13：00-18：00 札幌 　 2025年11月6日  （木） 13：00-18：00 東京② 　 2025年11月20日（木） 13：00-18：00 大阪②   各地で皆様と直接お会いし、 Cato クラウドの素晴らしさを体感いただければと張り切っていますので、ぜひご期待ください。  

本記事は執筆時点（2025年5月）の情報です。最新の情報は製品ドキュメントを参考にしてください   概要 ワークスペース上でレコードを開いた際、「Compose email」というアクションが用意されています。 こちらをクリックするとOutlookと同じ操作感で、ワークスペース上でもメールを作成することができます。 起票されたインシデントやケースなどのチケットに対し、起票者とメールでやり取りをすることができる便利な機能ですが、すべてのテーブルに「Compose email」がデフォルトで表示されているわけではないことに気が付きました。 そのため、今回の記事では「Compose email」を表示させる設定方法について調べました。   設定方法 「Compose email」がデフォルトで表示されていない、ケースタスク [sn_customerservice_task]を例に手順を記載します。   ケースタスクテーブルに移動し、任意のレコードを開きます。 そして、フォームコンテキストメニューを開き、Configure > Dictionaryを選択します。 Dictionary Entryテーブルに遷移したら、Typeが「Collection」となっているレコードを開きます。 「Advanced view」をクリックします。 Attributesフィールドに「email_client=true」と入力し保存します。 設定は以上となります。 ワークスペースを確認すると「Compose email」が表示されるようになりました。   ワークスペースから送信したメールは、送信元のレコードと紐づく形でメールが作成されます。 そのため、関連リストを設定することで、インシデントやケースなど一つ一つのチケット単位で紐づくメールの送信履歴を表示させることが可能になります。   さいごに ワークスペースからメールを送信するための設定手順を記事にしました。 エンドユーザーから起票されたチケットに対してメールでの確認が必要となった場合、Outlookを開かなくてもメールを送信できる、かつ送信元のチケットと紐づいて管理が楽になる非常に便利な機能だと思いました。   以下、弊社HPも是非ご参照ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

はじめに Prisma Cloudには多くのREST APIが用意されており、これを活用することで、運用の効率化やセキュリティの強化が可能になります。 例えば、手作業で行っていた作業の自動化や、独自のレポートを作成、Prisma Cloud外のデータとの連携など、独自の運用に合わせたツールを作成することができます。 しかしながら、REST APIも機能更新されたり、非推奨となったりと定期的に作ったツールに問題がないかを確認する必要があります。 この更新の確認を実施せず、作りっぱなしとなっているツールも多いのではないでしょうか。 非推奨となったREST APIは将来削除される可能性があるため、計画的に代替用REST APIに移行することが推奨です。 今回はPrisma Cloud Release Noteにて、2025年1月から5月に発表されたアップデート情報から、更新されたREST APIや、非推奨となったREST APIをご紹介します。 非推奨となったREST APIを利用している場合は、代替用REST APIの利用を検討いただく必要があります。 詳細は以下からご確認ください(英文) ・ Features Introduced in 2025 2025年1月 1月は非推奨に変更されたREST APIはありませんでした。 更新されたREST APIは以下の通りです。 更新されたREST API 更新された内容 Alerts API 以下エンドポイントがAlerts APIに追加されました Get Policy Remediation   2025年2月 2月に非推奨になったREST APIは以下です 非推奨に変更されたAPI 代替用REST API Get Vulnerability Overview V1 –  GET /uve/api/v1/dashboard/vulnerabilities/overview Get Vulnerability Overview V2 –  GET /uve/api/v2/dashboard/vulnerabilities/overview Get Vulnerability Overview V3 –  GET /uve/api/v3/dashboard/vulnerabilities/overview Get Vulnerability Overview – POST Get Vulnerability Overview – POST | Develop with Palo Alto Networks Get Prioritized Vulnerabilities V1 –  GET – /uve/api/v1/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities V2 –  GET – /uve/api/v2/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities V3 –  GET – /uve/api/v3/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities V4 –  GET – /uve/api/v4/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities POST –  POST /uve/api/v5/dashboard/vulnerabilities/prioritised Get Top Impacting Vulnerabilities –  GET /uve/api/v1/dashboard/vulnerabilities/prioritised-vuln Get Top Impacting Vulnerabilities V2 –  GET /uve/api/v2/dashboard/vulnerabilities/prioritised-vuln Get Top Impacting Vulnerabilities POST –  POST /uve/api/v3/dashboard/vulnerabilities/prioritised-vuln Get CVE Overview –  GET /uve/api/v1/dashboard/vulnerabilities/cve-overview Get CVE Overview V2 –  GET /uve/api/v1/cve-overview Get CVE Overview POST –  POST /uve/api/v2/cve-overview 更新されたREST APIは以下の通りです。 更新されたREST API 詳細 Satellite APIs リクエストbodyが更新されました。 POST /appid/api/v1/satellite のリクエストは clusterAssetId オブジェクトのみを必須とするようになりました。   2025年3月 非推奨に変更されたREST APIはありませんでした。 更新されたREST APIは以下の通りです。 更新されたREST API 詳細 Perform Event Search API POST /search/event のリクエストボディが更新され、ソートフィールドの値が大文字から小文字に変更されました。 Get Registry Scan Results Download Registry Scan Results Get Registry Image Names Prisma にオンボードされたアカウントにのみ適用される新しいクエリパラメーターが、「 Get Registry Scan Results 」「 Download Registry Scan Results 」「 Get Registry Image Names 」API に導入されました。このパラメーターを使用すると、CaaS（コンテナ・アズ・ア・サービス）仕様（AWS Fargate、GCP Cloud Run、ACI）の一部としてデプロイされたレジストリイメージをフィルタリングできます。 パラメーターの名前は hasCAASSpecReferences  です。 Support Images Field Prisma にオンボードされたアカウントにのみ適用される新しいクエリパラメーターが、「 Get Discovered Cloud Entities API 」に追加されました。このパラメーターを使用すると、CaaS（コンテナ・アズ・ア・サービス）仕様（AWS Fargate タスク定義、GCP Cloud Run、ACI）で定義されたコンテナイメージ名によって、クラウドで検出されたエンティティをフィルタリングできます。 Support Service Field Prisma にオンボードされたアカウントにのみ適用される新しいパラメーターが、「 Get Discovered Cloud Entities API 」のレスポンスに追加されました。このパラメーターは、検出された GCP Cloud Run サービス名を指定するためのものです。 パラメーターの名前は service  です。 Support CaaS Specification References Total Field Prisma にオンボードされたアカウントにのみ適用される新しいパラメーターが、以下の API に導入されました Get Host Scan Results Get Image Scan Results Get Impacted Container Compliance Policy Get Impacted VMs Compliance Policy Host App Firewall Policy Impacted Get Impacted Host Vulnerability Policy Get Impacted Image Vulnerability Policy Get Registry Scan Results Get VM Image Scan Results このパラメーターは、CaaS(Containers as a Service)仕様（AWS Fargate タスク定義、GCP Cloud Run、ACI）に関連付けられた参照数を指定するためのものです。 パラメーターの名前は caasSpecReferencesTotal  です。 Support for a Amazon Fargate Task Definition Prisma にオンボードされたアカウントにのみ適用される新しい列挙（Enum）値がスキーマに追加され、Amazon Fargate タスク定義の新しいスキャン結果タイプを指定できるようになりました。 パラメーターの名前は aws-fargate-task-definitionshared.ScanResultType  です。   2025年4月 REST APIの更新と非推奨になったREST APIはありませんでした。 2025年5月 非推奨になったREST APIは以下となります。 今回はSecure the Runtimeだけになっています。 REST APIバージョンは34.01.126となっています。 非推奨に変更されたREST API名 代替REST API Deprecation of the CNNS feature Cloud Native Network Segmentation（CNNS） 機能は、コンテナおよびホストに対するネットワーク脅威からの保護を強制する目的では非推奨となりました。 ただし、他のネットワーク監視モードが利用できないシナリオにおいては、レーダーによる可視化などの 監視目的 に限り使用することができます。 現在の推奨事項としては、CNNS ベースのネットワーク監視もすべて無効化することです。 REST APIの更新は以下の通りです。 今回はSecure the Runtimeだけになっています。 REST APIバージョンは34.01.126となっています。 更新されたREST API 詳細 Download Image Scan Results API (Prisma Cloud Workload Protection) 「Download Image Scan Results API」のCSVファイルのレスポンスに、新しい列が追加されました。 この新しいフィールドは、Prisma Cloud と Cortex XDR の統合において統合された XDR エージェントの数を一覧表示します。 この列の名前は  Cloud Security Agent Hosts  です。 Support for new agentless APIs (Prisma Cloud Workload Protection) 以下の新しい API エンドポイントにより、エージェントレスアカウントに対してスキャナーの最大数を設定したり、エージェントレススキャンの統計情報を取得したりすることができます。 Agentless Max Scanners Agentless Scan Statistics Support for a new enum value (Prisma Cloud Workload Protection) スキーマに新しい列挙（Enum）値が追加され、 gcp-cloud-run-serviceshared.ScanResultType  を指定できるようになりました。 さいごに 今回はPrisma Cloud release noteの更新されたREST APIと非推奨REST APIを紹介しました。 定期的にリリースノートを確認し、非推奨REST APIを使用しないようにしましょう。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

どうも、SCSKの谷です。 私の部署では監視サービスを提供しているのですが、実際に監視しているメトリックデータの数値を見たいというお客様が一定数います。 そのようなお客様に対してMackerelを利用した監視サービスを提供する場合、Mackerelではグラフを参照することはできますが、 実際に監視で得られた数値を参照することはできないので、お客様の要望に応えられません。 そこで、MackerelはAPIを公開しているので、APIを利用して監視対象のメトリックの数値データを取得してこれるのではと考え、実装してみることにしました。   部署の後輩である嶋谷君が書いた最近の記事について以下にまとめてますので、ご覧になっていない方は是非ご覧ください！ ■投稿記事 ・ Mackerel でマイクロサービスを監視してみた – TechHarmony ・ CloudWatchのアラート通知をMackerelに移行してみた – TechHarmony   性能データCSVダウンロードスクリプト 概要 今回は、PowerShellを用いて性能データをCSVでダウンロードするスクリプトを作成しました。 大まかに以下の2手順で性能データをCSVでダウンロードしていきます。 1.　APIを用いて、Mackerel上の監視対象ホストの指定したメトリクスの時系列データを取得し、JSON形式で保存 2.　取得したJSONデータをCSV形式に変換 機能要件 ・CSV形式で性能データを出力できること ・APIで取得する性能データの取得期間を指定できること ・指定したメトリクスのデータを取得できること 実行環境 今回の実行環境はWindows11です。 （PowerShellの実行環境とインターネットへの接続環境があれば、利用できる想定です) スクリプト詳細 作成したスクリプトは以下の構成からなります。 getcsv.ps1 親スクリプト 必要情報の入力と子スクリプトの呼び出し getjson.ps1 子スクリプト APIを用いて対象ホストのデータを取得しJSON形式で保存 writejsontocsv.ps1 子スクリプト JSON形式のファイルをCSV形式に変換し保存   getcsv.ps1（必要情報の入力と子スクリプトの呼び出し） 以下、getcsv.ps1のスクリプトとなります。 #getcsv.ps1 param(     [string]$dateTime,     [string]$apiKey,     [string]$hostId,     [string]$metricName,     [string]$startDateTime,     [string]$endDateTime,     [string]$jsonFilePath,     [string]$csvFilePath ) #現在日時取得 $dateTime = (Get-Date).ToString("yyyyMMddHHmmss") #出力先設定 $jsonFilePath = "jsonの出力先パス\response.json" $csvFilePath = "csvの出力先パス\output_$dateTime.csv" #各パラメータ入力 $apiKey = Read-Host "APIキーを入力してください" $hostId = Read-Host "ホストIDを入力してください" $metricName = Read-Host "取得するメトリクス名を入力してください" $startDateTime = Read-Host "開始日時を入力してください(yyyymmdd hhmmss)" $endDateTime = Read-Host "終了日時を入力してください(yyyymmdd hhmmss)" #JSONデータ取得バッチ実行 .\getjson.ps1 -apiKey $apiKey -hostId $hostId -metricName $metricName -startDateTime $startDateTime -endDateTime $endDateTime Write-Output "取得したJSONデータをCSVに変換します" #CSV変換バッチ実行 .\writejsontocsv.ps1 -jsonFilePath $jsonFilePath -csvFilePath $csvFilePath (1) 必要パラメータの入力 パラメータの詳細につきましては、スクリプトの実行手順で説明しています。 (2) JSONデータ取得バッチ実行 getjson.ps1に必要なパラメータを渡して、実行します。 (3) CSV変換バッチ実行 writejsontocsv.ps1に必要なパラメータを渡して、実行します。     getjson.ps1（APIを用いて対象ホストのデータを取得しJSON形式で保存する処理） 以下、getjson.ps1のスクリプトとなります。 #getjson.ps1 param ( [string]$apiKey, [string]$hostId, [string]$metricName, [string]$startDateTime, [string]$endDateTime )       # UNIXタイムスタンプに変換 $wkstartDateTime=[DateTime]::ParseExact($startDateTime, "yyyyMMdd HHmmss", $null).ToUniversalTime() $fromUnixTime = [int][double]::Parse($wkstartDateTime.Subtract([datetime]'1970-01-01').TotalSeconds) $wkendDateTime=[DateTime]::ParseExact($endDateTime, "yyyyMMdd HHmmss", $null).ToUniversalTime() $toUnixTime = [int][double]::Parse($wkendDateTime.Subtract([datetime]'1970-01-01').TotalSeconds) # APIリクエストURLの作成 $apiUrl = "https://api.mackerelio.com/api/v0/hosts/$hostId/metrics?name=$metricName&from=$fromUnixTime&to=$toUnixTime" # APIリクエストの実行 $response = Invoke-RestMethod -Uri $apiUrl -Headers @{ "X-Api-Key" = $apiKey } -Method Get # JSONデータをテキストファイルに保存 $response | ConvertTo-Json | Out-File -FilePath "response.json" Write-Output "APIリクエストが完了し、データがresponse.jsonに保存されました。" (1) 入力した日時をUNIXタイムスタンプに変換 APIリクエストURLではUNIXタイムスタンプである必要があるため、最初に「yyyyMMdd HHmmss」で指定した開始日時と終了日時を UNIXタイムスタンプに変換しています。 (2) APIリクエストURLの作成 入力した値を組み合わせて、ホストのメトリックの値取得用のAPIリクエストURLを作成します。 メトリクス名及び取得開始日時、取得終了日時はクエリパラメータで指定してます。 ・name = メトリック名 ・from  = 取得開始日時 ・to      = 取得終了日時 APIリクエストURLについては、以下のMackerel公式ドキュメントを参考にしています。 Mackerel API ドキュメント（v0） – Mackerel API ドキュメント (v0) (3) APIリクエストの実行 作成したAPIリクエストURLを実行し、メトリックのデータを取得します。 Invoke-RestMethodを使用してAPIリクエストを実行しています。 (4) 取得したデータをJSON形式で保存 取得したデータを ConvertTo-JsonでJSON形式で保存します。 ファイルの保存先として、実行しているフォルダ上にそのまま保存してます。     writejsontocsv.ps1（JSON形式のファイルをCSV形式に変換し保存） 以下、writejsontocsv.ps1のスクリプトとなります。 #writejsontocsv.ps1 param( [string]$jsonFilePath, [string]$csvFilePath )         # JSONファイルを読み込み $jsonContent = Get-Content -Path $jsonFilePath -Raw | ConvertFrom-Json # 出力用のCSVデータを格納するための配列を初期化 $csvData = @() # 各メトリクスを処理 foreach ($metric in $jsonContent.metrics) { # UNIXタイムをJSTの "YYYYMMDD HHMMSS" 形式に変換 $timeJST = [System.TimeZoneInfo]::ConvertTimeBySystemTimeZoneId( [System.DateTimeOffset]::FromUnixTimeSeconds($metric.time), "Tokyo Standard Time" ).ToString("yyyy/MM/dd HH:mm:ss") # CSVの行を作成 $csvData += [PSCustomObject]@{ Time = $timeJST Value = $metric.value } } # CSVファイルとして出力 $csvData | Export-Csv -Path $csvFilePath -NoTypeInformation -Delimiter ',' Write-Host "JSONファイルからCSVファイルへの変換が完了しました。出力ファイル: $csvFilePath" (1) JSONファイルの読込 getjson.ps1で出力したメトリックデータのJSONファイルを読み込みます。 (2) 各メトリクスの処理 JSONファイル内のパラメータは「Time（日時）」と「Value（メトリックの値）」となっているので、 上記を1ペアとして配列に繰り返し格納していきます。 (3) CSVファイルの出力 配列内に格納したデータをExport-Csvを用いてCSVファイルとして出力します。 使用方法 作成した性能データ出力スクリプトの使用方法を説明していきます。     事前準備 Powershellのバッチ実行設定で実行可になっていない場合、以下作業を実施してバッチ実行可に変更する必要があります。 (1) Windows PowerShellを管理者として実行する (2)「Get-ExecutionPolicy」と入力し、「Restricted」の場合は以下を実行(「RemoteSigned」の場合は実行不要です。) Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 実行ポリシーの変更に「Y」     対象ホストのメトリック名の確認 コマンドプロンプトで取得対象のメトリック名を確認します。 (1) コマンドプロンプトを開く (2) 以下のコマンドを入力する curl -k -X GET -H “X-Api-Key:【APIキー】” “https://api.mackerelio.com/api/v0/hosts/【ホストID】/metric-names” (3)出力したいデータのメトリック名を確認する   スクリプト実行 スクリプトを実行して、性能データをCSV形式で出力します。 (1) 以下のスクリプトファイルを任意の場所に設置する ・getcsv.ps1 ・getjson.ps1 ・writejsontocsv.ps1 (2) PowerShellを開く (3) スクリプトの設置場所にカレントディレクトリを移動する (4) getcsv.ps1を実行する (5) 必要なパラメータを入力する データの取得のために必要なパラメータを入力していきます。 パラメータについては以下の通りです。 変数名 パラメータ 概要 apiKey APIキー MackerelへAPIリクエストするために必要なAPIキー hostId ホストID Mackerel上に登録されているホストを識別するための一意のID、取得したいホストのIDを指定 metricName メトリック名 Mackerelで監視しているホストのメトリックの中で取得したいメトリック名を指定 startDateTime 取得開始日時 メトリックデータを取得したい期間の開始日時 endDateTime 取得終了日時 メトリックデータを取得したい期間の終了日時 APIキーについては、以下から確認できます。 オーガニゼーション詳細ページ > APIキータブ > APIキー 　  ホストIDについては、以下から確認できます。 (6) パラメータ入力後、処理が実行されCSVファイルが出力されたこと確認する   指定した取得期間によりデータの時間幅（ピッチ）が変わる Mackerel側の仕様で、指定した取得期間の長さによって、APIで取得したデータの時間幅が変わりますのでご注意ください。 参考として、以下に取得期間による時間幅をまとめております。 取得期間 時間幅（ピッチ） 例 1時間単位 1分 2025/5/1 15:00 ~ 2025/5/1 18:00 1日単位 5分 2025/5/1 15:00 ~ 2025/5/4 15:00 1週間単位 10分 2025/5/1 15:00 ~ 2025/5/14 15:00 1月単位 1時間 2025/5/1 15:00 ~ 2025/7/15 15:00   性能データCSVダウンロード結果 本スクリプトを用いて、以下のメトリックのデータを取得してみました。 取得データ メトリック名 備考 CPU使用率 cpu.steal.percentage   メモリ使用率 memory.used、memory.total (memory.used/memory.total)*100で算出 ディスク使用量 filesystem.xvda1.used   取得対象のホストは以下の通りです。 AWS EC2 ・CPU　t2.micro ・RAM　0.93 GiB ・OS　　Linux/UNIX ・ストレージ　8GiB 取得期間は「2025年5月21日 7時19分」から「2025年5月21日 13時19分」の6時間となります。 CPU使用率 CSVデータをもとにEXCELで作成したグラフです。 Mackerelの管理画面でのグラフです。 メモリ使用率 CSVデータをもとにEXCELで作成したグラフです。 メモリ使用率につきましては、直接APIで取得できないので、メモリ使用量とメモリサイズのメトリックデータを取得し、計算しています。 Mackerelの管理画面でのグラフです。 Mackerelにはメモリ使用率のメトリックがないため、メモリ使用量のグラフとなっております。 ディスク使用量 CSVデータをもとにEXCELで作成したグラフです。 ディスク使用量とディスクサイズのメトリックデータを組み合わせています。 Mackerelの管理画面でのグラフです。 同様に、ディスク使用量とディスクサイズのグラフとなっております。   スクリプト所感 今回でスクリプトを作成したことによりメトリックデータをCSV形式ダウンロードできるようになったので、データを成形したり複数のデータを組み合わせることができるようになりました。また、Mackerel上のグラフでは、時間ごとの細かいメトリックの数値を把握することが難しかったので、可視化しやすくなったと感じました。スクリプト自体も単純な対話形式のものにしたので、誰でも利用できるようにできたかなと思います。 実際に使ってみて、コマンドでメトリック名一覧を出力後に、出力したいメトリックデータのメトリック名を探し出すのは大変だと感じました。また、毎回APIキーやメトリック名を入力しなけらばならないので、そこは結構手間だと感じました。 CSV形式でダウンロードできるようにすることが今回の大きな目標だったのでひとまず達成することができました。 しかし、利便性の面ではまだまだ改善の余地があると感じています。 ■改善点の例 ・ファイル出力先を指定できない ・複数のメトリックデータを一度に取得できない ・複数ホストメトリックデータを一度に取得できない など   補足） MoniPro Mに実装しました 実は、今回のスクリプトをもとに開発担当の方に内容を改善いただき、弊社のサービスであるMoniPro Mでも監視データをcsvダウンロードできるようにしていただきました。 MoniPro Mにつきましては、下記の公式サイトを参照ください。 MoniPro M｜SCSK株式会社 性能データCSVダウンロード機能 性能データCSVダウンロード機能はSCSK の統合監視プラットフォーム「FusionCORE」のうちのお客様向けポータルである HEARTIL Contact Portal(HCP)内の機能になります。 取得したいホストとメトリックを選択し、ダウンロードボタンを選択することで性能データをCSV形式でダウンロード可能です。 選択したそれぞれのCSVファイルがアーカイブされZipファイル形式でダウンロードされます。 メトリックについては取得可能なメトリックのみ選択できるようになっています。 ■特徴 ・Mackerelの管理単位である、サービス、ロールで対象ホスト絞りこむことが可能 （ 「サービス」「ロール」とは – Mackerel ヘルプ ） ・取得開始時間と取得終了時間を指定可能 ・複数のホストとメトリックの性能データCSVを同時にダウンロードが可能 ・Zipファイル形式にアーカイブされた状態でダウンロード 所感 今回の機能追加にあたり、サービスの機能として利用できるよう開発担当の方に本スクリプトを修正・改善をしてもらってHCPに実装していただきました。 HCPへの実装後に実際に利用してみて、自身が作成したときのスクリプトよりも非常に利用しやすくなっており感動しました。 以下に利用しやすくなったと感じた点をまとめております。 ・ダウンロードしたいメトリックのチェックボックスを選択するという直感的な操作で簡単に性能データCSVをダウンロード可能 ・ホスト名の左側にあるチェックボックスを選択することで選択可能なメトリックをまとめて選択できる ・検索条件でサービスやロールから対象ホストを絞りこむことができるので、Mackerel上のホストが多くても対象ホストの性能データを 簡単にダウンロード可能 ・複数ホストと複数メトリックをまとめてダウンロードできるので、一つずつダウンロードする手間がかからず便利 まとめ 今回はMackerel上で監視しているホストの性能データをCSV形式でダウンロードするスクリプトを作成してみました！ 先ほども述べましたが、ひとまずCSV形式でダウンロードできればよいと考えており、スクリプトについて細かいところまで作りこんでおらず使用しづらい箇所があったのですが、CSV形式でダウンロードするという目的は達成することができました。 併せて、MoniPro Mに実装した性能データCSVダウンロード機能について紹介させていただきました。 自身が作成したスクリプトをベースに実際に機能として追加していただけたので、感慨深いものがあります。 もし本記事の内容にご関心をお持ちいただけましたら、ぜひ一度サービスをご体験いただければ幸いです。

こんにちは。SCSKの安藤です。 今年も昨年に引き続き、「 Interop Tokyo 2025 」にZabbix社と共同出展します。 ブース番号は 6F04 です。   開催概要 【主催】 Interop Tokyo 実行委員会 【概要】 ６月１１日（水）　１０時～１８時 ６月１２日（木）　１０時～１８時 ６月１３日（金）　１０時～１７時 　　※来場には 事前登録(無料) が必要です。 【会場】 　　 幕張メッセ 　国際展示場ホール４～８   Zabbixブース場所 Zabbixブース（ブース番号：6F04） は、 Hall6出入口 そばです。   SCSKの出展内容 SCSKは、Zabbixプレミアムパートナー として、 弊社のZabbix関連ソリューションの展示 をします。 手軽に環境を構築できる、Quick Start Packageや、バージョンアップ事例のご紹介もあります。 オープンソースの監視ツールであるZabbixに興味のある方は、ぜひご来場ください！   同ブース内で ショートセミナー も開催します。 タイトル：Zabbix Cloud 登場！Zabbixのプロが実際に使ってみた 登壇日時：①６月１１日（水）　１２時４０分～１２時５５分 　　　　　②６月１２日（木）　１６時２５分～１６時４０分 　　　　　③６月１３日（金）　１０時３５分～１０時５０分 各日１回、３回ともセッションの内容は同じですので、ご都合のつく回にぜひお越しください。   当日はZabbixブースへのご来場を心よりお待ちしております！   Interopとは Interop Tokyoは、延べ12万人が来場する国内最大級のインターネットテクノロジーのイベントです。 毎年国内外から数百の企業・団体が参加し、技術動向とビジネス活用のトレンドをいち早く体感できる場です。   ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★   SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★   x.com   x.com

こんにちは、Catoクラウド エンジニアの中川です。 突然ですが、Catoクラウドを利用するにあたって、Socketの選び方に迷っていませんか？   「X1500・X1600・X1700のどれを選べばいいの？」 「拠点の規模に合ったSocketがわからない…」   そんなお悩みをお持ちの方に向けて、この記事では Cato Socketの物理デバイス3モデル（X1500 / X1600 / X1700）について、以下のポイントを中心にわかりやすく解説します。 各モデルのスペックと性能の違い 適した導入シーンと選定の目安 本記事を通じて、 自社に最適なSocketモデルを選ぶため のご参考になれば幸いです。 Socketとは？ まず前提として、 Socket（ソケット）とは、Catoクラウドに接続するためのエッジデバイス のことです。 インターネット回線に接続するだけで、特別な設定を必要とせず、 ゼロタッチ でCatoクラウドと接続されます。Socketを利用すれば、ルータやFirewallに設定が必要なIPsec接続構成のような手間がかかりません。 Socketには、物理的なハードウェアデバイスと仮想アプライアンス（vSocket）の2種類がありますが、この記事では、 物理デバイスである「X1500」「X1600」「X1700」の3モデルに焦点を当て、それぞれのスペックや機能、適した利用シーン を比較してご紹介します。 データセンターや本社・支社など、拠点にSocketを導入する際に、どのモデルを選べばよいか迷っている方の参考になれば幸いです！ Socket X1500 / X1600 / X1700 の比較 Cato Socketには、拠点の規模や用途に応じて選べる複数のモデルが用意されています。 ここでは、 X1500、X1600、X1700 の3モデルについて、 仕様 を比較しながらご紹介します。 機種別スペック比較表 項目 X1500 X1600 ※1 X1700 写真 Basicモデル LTEモデル 特徴 ベーシックモデル 高性能・多様なポート ハイエンドモデル 最大スループット ※2 500 Mbps 1 Gbps X1700 – 3Gbps X1700B – 10Gbps  サイズ X1500 – 奥行き:105.5mmx 幅:165mm x 高さ:43mm X1500B – 奥行き:130mmx 幅:180mm x 高さ:30mm 非常にコンパクトで、よく私たちはお弁当箱サイズと表現します 奥行き: 256mm x 幅:200mm x 高さ: 44mm およそX1500の約2倍のサイズ感です X1700 – 奥行き:448mm x幅:435mm x 高さ:44mm X1700B – 奥行き:553mm x幅:438mm x 高さ:44mm ラックマウント専用です 重量 約700g 約1kg 約2.5kg インターフェース RJ45ポート x4 1G COMBOポート(RJ45とSFP)x2 10G SFP+ポートx2 2.5GのRJ45ポート x4 標準 – RJ45ポート x8 オプションで以下を追加可能             4 x 1GbE 2 x 1Gb Fiber 2 x 10Gb Fiber 4 x 10Gb Fiber 電源 12V電源アダプタ 12V電源アダプタ（ロック機構付き） 冗長電源ユニット　2 x 300W 設置方法 卓上・ラックマウント ラックマウント・壁掛け対応 ラックマウント専用 ※1 X1600の詳細は、 徹底解説！Cato Socket X1600 – TechHarmony の記事も合わせてご参考ください。 ※2 最大スループットは、SocketとCatoクラウド PoP間での上り下りの合計値です。 あくまで目安の数値であり、上り下りが両方ともMAXに出続けるという状況はほぼないため、上記の目安帯域以上でも利用可能な場合が多いです 。 各モデルの選び方 X1500：中規模拠点まで対応。ベーシックモデル コンパクトで設置しやすい、ベーシックモデルです。 最大スループット500Mまで対応しているので、従業員の多い大規模拠点などでなければ、まずはX1500を選定いただければと思います。 X1600,X1700とモデルが上がるにつれて当然価格も上がります。コストを抑えたい場合にもおすすめです。 X1600：中〜大規模オフィス向けの高機能モデル 10G SFP+や2.5G RJ45などのインターフェース、LTEモデルの利用要件がある場合に選定いただければと思います。 X1500よりもポート数が豊富なため、Socketを拠点内のルータ・L3SWの代わりとして利用することができるかもしれません。 今後は、Wi-Fiモデル、LTE+Wi-Fiモデルの展開が予定されています。 X1700：データセンター向けのハイエンドモデル 最大3Gbps、X1700Bであれば10Gbpsのスループットに対応可能なハイエンドモデルです。 従業員の多い本社などの大規模拠点や、トラフィックの集まるデータセンターなどの拠点で多く選ばれています。 各Socketの大きな違いは 最大スループット です。 拠点の規模 を考慮して、最適なSocketを選ぶことが重要です。 まとめ Cato Socketは、拠点の規模やネットワーク要件に応じて柔軟に選べるエッジデバイスです。 本記事では、 X1500・X1600・X1700 の3モデルについて比較してきました。 それぞれのSocketには特徴があり、 「どの拠点に、どのモデルを導入すべきか」 を判断するための材料として、本記事が参考になれば幸いです。 また、想定よりも帯域が必要となった際などには、Socketのアップグレードも可能ですのでご安心ください。 もしご判断に迷うようでしたら、SCSKへご相談いただければ、既存のトラフィック状況などから適したSocketの選定させていただくことが可能です。 ぜひお問い合わせいただければと思います。 参考資料 本記事は以下の、Cato Socketに関する公式情報を参考に記載しています。 Cato Socket Deployment Guides and Data Sheets – Cato Learning Center

現在のデジタルトランスフォーメーション（DX）の進展に伴い、クラウドにおけるデータ保護と法令遵守はますます重要になっています。特に、クラウドリソースの監視やリスク管理を強化するために、クラウドセキュリティ体制管理（CSPM）ツールが有効な手段となります。CSPMツールは、クラウドの設定ミスやセキュリティギャップを検出し、企業の安全性を高めるために不可欠な役割を果たします。 企業が安心してクラウド技術を活用するためには、データ保護と法令遵守を確実にすることが欠かせません。企業によっては、特定のコンプライアンス基準に準拠することが求められる場合があります。例えば、業界ごとの規制や法令遵守のために、ISO 27001やPCI DSSといった厳格な基準への対応が必要となることもあります。そこで、CSPMツールは、こうした複数のコンプライアンス基準に対応するように設計されており、クラウド環境の安全性を確保するための重要なソリューションとなります。 そこで本記事では、Prisma Cloudが対応しているコンプライアンス基準について一部ご紹介します。   Prisma Cloud が対応しているコンプライアンス基準 Prisma Cloudは、クラウド環境のセキュリティを強化するためにCISやCSA CCM、GDPRなど数多くのコンプライアンス基準をサポートしています。最新の対応コンプライアンスの一覧は下記リンクを確認してください。 コンプライアンス基準 AWS APRA CPS 234, Brazilian Data Protection Law (LGPD), CIS AWS 3 Tier Arch v1.0, CCPA 2018, CIS v1.2, CIS v1.3, CIS AWS v.1.4, CSA CCM v3.0.1, CSA CCM v4.0.1, CMMC, GDPR等 Azure Azure Security Benchmark (ASB) v2, Azure Security Benchmark (ASB) v3, APRA CPS 234, Brazilian Data Protection Law (LGPD), CCPA 2018, CIS v1.1, CIS v1.2, CIS v1.3, CIS v1.3.1等 GCP APRA CPS 234, Brazilian Data Protection Law (LGPD), CCPA 2018, CIS v1.0, CIS v.1.1, CIS v.1.2, CIS GKE v1.1, CSA CCM v3.0.1, CSA CCM v4.0.1, CMMC, GDPR, HITRUST v9.3等   コンプライアンスをPickupして紹介 このように、Prisma Cloudは数多くのコンプライアンス基準をサポートしています。 ここでは、Prisma Cloudが対応するコンプライアンス基準の中から、特によく聞かれる「ISO 27001:2022」「CIS AWS v4」「PCI DSS v4.0」について紹介します。   ISO 27001:2022 ISO 27001:2022とは、情報セキュリティ、サイバーセキュリティ、プライバシー保護に関する国際規格であり、2022年2月にISOから発行されました。 この規格は、ISO/IEC 27000シリーズの一部であり、情報セキュリティやサイバーセキュリティ等のリスクに対する管理策とその導入方法を詳しくまとめています。原文のタイトルは「Information security, cybersecurity and privacy protection – Information security controls」です。   CIS AWS v.1.4 CIS AWS v.1.4は、Amazon Web Servicesのセキュリティ設定を強化するためのガイドラインを提供しており、基本的な設定や検証可能な設定、アーキテクチャに依存しない設定に焦点を当てています。 対象となるAWSサービスには、IAMやIAM Access Analyzer、AWS Config、AWS CloudTrail、CloudWatch、Amazon SNS、S3、EC2、RDS、そしてVPCなどがあります。これらのサービスに対し、安全で信頼性の高い設定を確立するための指針を示しています。   PCI DSS v4.0 PCI DSS v4.0はクレジットカード情報を取り扱う企業向けのセキュリティ基準であり、クラウド環境におけるデータ保護の要件が厳格化されています。 インターネットの急速な発展に伴い、サイバー攻撃がますます複雑化し、カード情報の流出や不正利用のリスクが高まっています。カード情報が流出すると、成りすましによる不正利用などの経済的損害が発生する可能性があるため、PCI DSSは「理想的なセキュリティ」ではなく「最低限守るべき基準」として位置付けられています。 PCI DSS v4.0では、リスク分析の新たな取り組み、安全な暗号化方式の導入、パスワードの複雑性強化、多要素認証の実装など、セキュリティ対策が強化されています。   まとめ Prisma Cloudは、クラウド環境でのデータ保護と法令遵守を確実にするために、ISO 27001:2022、CIS AWS v.1.4、PCI DSS v4.0などの主要なコンプライアンス基準をサポートしています。これにより、企業は安心してクラウド技術を活用し、デジタルトランスフォーメーションを推進することができると考えられます。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

クラウドベンダーと利用企業がそれぞれの責任を分担する「責任共有モデル」は、クラウドセキュリティの基本概念として広く認知されています。しかし、利用企業の中では具体的に「誰が」セキュリティの責任を負うべきなのでしょうか？ 情報セキュリティ担当部門なのか、それとも実際にクラウドを運用する部門なのか――この問いについて考察します。 ※本ブログでは、企業の情報セキュリティ部門とクラウド運用部門のどちらがパブリッククラウドのセキュリティ責任を担うべきかを論じています。ただし、企業の規模やクラウドの利用方法によっては、セキュリティ管理の階層がより細分化されているケースもあるため、自社の組織構造に合わせて読み替えていただければと思います。   パブリッククラウドのセキュリティリスクと影響 パブリッククラウドを利用する企業にとって、クラウド上で発生するセキュリティインシデントは重大なリスクです。 データ漏洩、不正アクセス、設定ミスによる情報公開などの問題が発生した場合、企業に与える影響は以下のような形で現れます。 財務的損失 報漏洩による賠償責任や罰則、ブランド価値の低下 事業継続への影響 システムダウンやデータ消失により業務が停止 顧客・取引先の信頼低下 データ流出等により企業への信頼が損なわれ、契約解除や取引縮小が発生 インシデント対応の負担増 調査・復旧・再発防止策の実施に膨大な時間とコストが必要 このような影響を踏まえると、企業内のどの部署が責任を持つべきなのかを明確にすることは極めて重要です。   情報セキュリティ担当部門の役割 一般的に、企業の情報セキュリティ担当部門は社内全体のセキュリティポリシーの策定や管理を担っています。 この部門は以下のような活動を行います。 セキュリティポリシーの策定と適用 社内全体のガイドラインを定め、適用を監督 リスク評価と対応策の検討 脅威分析を行い、必要な対策を実施 インシデント発生時の対応 影響範囲の調査、原因分析、再発防止策の策定 一方で、クラウド環境の具体的な設定管理や運用は担当しない場合が多く、技術的な詳細についてはクラウドの運用者に依存します。   クラウド運用部門の責任 クラウドを実際に運用する部門（IT部門やクラウド専門チーム）は、クラウド環境の設定や運用管理を担います。 そのため、セキュリティリスクの多くがこの部門の手に委ねられることになります。 適切なアクセス管理 IAMの設定、権限付与の管理 セキュリティ設定の維持 暗号化の適用、ネットワーク設定の監視 監視とインシデント対応 ログ分析やアラート対応 特にクラウドでは 設定ミス が大きなセキュリティリスクとなるため、実務レベルでセキュリティを担保するのは運用者の責任だともいえます。しかし、クラウド運用者にセキュリティの責任を集中させることには以下のような課題があります。 業務の幅広さによる負担 クラウド運用者はセキュリティだけを専門に扱っているわけではなく、システムの運用・保守、パフォーマンス監視、コスト管理など多岐にわたる業務を担当しています。 そのため、セキュリティの向上に特化した取り組みを行う時間やリソースを確保することが難しいという問題があります。 最新のセキュリティ情報を常に把握する難しさ クラウドサービスは頻繁にアップデートされ、新しいセキュリティ機能が追加されます。 例えば、AWSやAzureでは定期的にセキュリティ強化のための新機能がリリースされますが、これらを常に追い続け、適切に導入することは運用者にとって負担となります。また、新たなセキュリティ脅威も日々登場するため、運用者が最新の脅威動向を把握し、それに対応するのは容易ではありません。 責任の曖昧さによるリスク クラウド運用部門がセキュリティ対応を担当すると、情報セキュリティ部門との責任分担が曖昧になることがあります。 たとえば、セキュリティポリシーの策定は情報セキュリティ部門が担当するが、クラウドの実際の設定は運用者が行うという形になった場合、 「どこまでが運用者の責任で、どこからが情報セキュリティ部門の責任なのか」が不明瞭になり、対応が遅れる可能性があります。 スキルのばらつきによるリスク クラウド環境では、アクセス権限の管理、ネットワーク設定、暗号化の適用など、細かいセキュリティ設定が求められます。 経験豊富な運用者であれば適切な設定を行えますが、知識が不足している運用者の場合、設定ミスや見落としが発生しやすくなります。特に複数のクラウドサービス（AWS、Azure、GCPなど）を利用している場合、クラウドサービスの理解度によって大きく違いがでます。 結果として、システムの一部に脆弱性が残り、攻撃者に狙われる可能性が高まります。   結論 情報セキュリティ担当部門とクラウド運用部門のどちらが最終的な責任を持つべきなのか、という問いに対する答えは、「どちらも重要な責任を持つが、役割が異なる」という点にあります。 情報セキュリティ担当部門 企業全体のルールを定め、監督する責任 クラウド運用部門 実際の運用・設定管理を行い、セキュリティリスクを防ぐ責任 クラウド環境では技術的な管理がセキュリティの質を大きく左右するため、クラウド運用部門が重要な役割を果たしますが、それを監督する情報セキュリティ担当部門も不可欠です。企業内で明確な責任分担を定め、双方が連携して取り組むことが、クラウドセキュリティを確保する重要なポイントとなります。 ただし、これだけではクラウド運用者の負担が大きく、セキュリティの課題を根本的に解決することは困難です。そのため、 情報セキュリティ担当部門主導でクラウドセキュリティ製品の導入を積極的に検討することが、より効果的な解決策 となります。 特に、 CSPM（Cloud Security Posture Management） を活用することで、 クラウド環境のセキュリティ課題を効率的かつ継続的に解決することが可能となります。 CSPMが有効である理由 クラウド設定の継続的な監視と評価 CSPMはクラウド環境の設定ミスやポリシー違反を自動で検知し、推奨されるセキュリティ基準と比較しながら、リアルタイムで改善案を提示します。そのため、運用者が手動で監視する負担が減り、適切なセキュリティ管理が継続的に行えます。 クラウド環境ごとの統一的なセキュリティ管理 企業が複数のクラウド（AWS、Azure、GCPなど）を利用している場合、各クラウドサービスごとに異なるセキュリティ設定を管理するのは非常に困難です。CSPMを導入すれば、異なるクラウド環境を統一的に監視・管理し、セキュリティレベルのばらつきを防ぐことができます。 インシデント発生前のリスク軽減 多くのセキュリティインシデントは、設定ミスや限管理の不備によって引き起こされます。CSPMはこれらの問題を事前に検知し、脆弱な設定を未然に防ぐことで、インシデント発生リスクを低減できます。 CSPMの導入で、人的リソースと技術を組み合わせた最適なセキュリティ対策を クラウド運用者の責任だけに頼るのではなく、CSPMを活用することで、より効率的かつ継続的なセキュリティ管理が可能となります。 これにより、情報セキュリティ部門とクラウド運用部門の連携が強化され、負担を分散しながら適切なセキュリティ対策を実現することができます。   おわりに パブリッククラウドの活用が広がる中、セキュリティリスクへの対応を「人」に依存するのは限界があります。属人的な管理では対応の抜けやミスが発生しやすく、組織全体のセキュリティレベルを維持するのが難しくなります。そのため、自動化されたツールの活用が不可欠です。 最近では「CNAPP（Cloud-Native Application Protection Platform）」という概念が注目されていますが、まずは基本となるCSPMを導入し、確実なセキュリティ対策の第一歩を踏み出すことが重要です。CSPMを活用することで、クラウド環境の設定ミスや脆弱性を検出し、適切な対応を行うことが可能になります。そしてセキュリティ強化のためCNAPPの導入を検討していきましょう。CNAPPには複数のセキュリティの要素が含まれる（CSPMも含みます）ため計画的に導入することを推奨します。 当社ではクラウド診断サービスやマネージドCSPMサービスを提供していますので、ご興味のある方は是非、お気軽にお問い合わせください。 Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

最近、周りで筋トレをする人が本当に多いんです。 同期の中には、ベンチプレス140kgを挙げられると豪語するゴリマッチョや、フィジーク大会に出場する本格派まで現れる始末。 ついには、私の母までちょこっと筋トレできるライトなジムに通い始めてしまいました。 そんな筋トレブームを横目に、私が力を入れているのが「Azure Bicep」です。  IaCを用いた強靭で美しい環境を作り上げることに情熱を燃やしています！ Bicepとは Bicepを和訳すると上腕二頭筋になります。いわゆる力こぶ💪のことです。 bicepの意味・使い方・読み方 | Weblio英和辞書 なぜ力こぶ？名前の由来が気になります。 元々Azureでは腕のアーム（ARM：Azure Resource Manager）がインフラ構築する際のテンプレートとして利用されていたが、これからは力こぶでさらにパワーを強調するぞ！！などと開発者は考えたのかもと想像してしまいます。 真相は定かではありませんが、コードでインフラを構築する力強さを表現していると感じています。 JSON形式のARMテンプレートは記述が冗長になりやすく、可読性も低い課題がありました。 そこで開発されたのがBicepです。ARMテンプレートをよりシンプルに、より直感的に記述できるように設計されたDSL（ドメイン固有言語）なのです。 Bicep とは - Azure Resource Manager インフラストラクチャを Azure にデプロイするための Bicep 言語を理解します。 JSON を使用してテンプレートを開発する場合に比べてオーサリングがしやすくなります。 learn.microsoft.com   ポータル操作と比較した利点 Bicepに限らずですが、私が感じたIaCの利点は ミスなし 、 複製よし 、の2点です。 ミスなし：ヒューマンエラーの抑制 ポータル上をポチポチしながら構築すると、どうしてもミスが発生します。 設定漏れや間違った項目の選択など色々な事象が起き得ます。 IaC なら「一度正しい設定をコード化すれば、後は何度デプロイしても同じ構成が再現される」という特徴があるので、人間の手による作業が減る分の品質向上に寄与できるのです。   複製よし：リソースの複製が簡単 実際の案件では、同じような設定のリソースを何度も作成する必要があります。 仮想マシン2台、ストレージ1台、データベース1台、…みたいな少量だけ作成することはあり得ないですよね。 同じような設定のコードをコピーしてパラメータを変更すれば、瞬時にリソースを複製できます。 私が災対環境構築に携わった際も、本番環境の Bicep コードを流用することでスムーズに構築できました。    ただしデメリットもあります。それは 学習コストが高い こと。 ツールの設定や記述方法などに慣れる必要があり、初学者だと厳しいところがあります。 公式ドキュメント見ながらコード記述するのは、私もかなり骨が折れました。 Azure リソース リファレンス - Bicep, ARM template & Terraform AzAPI reference Bicep、Azure Resource Manager テンプレート、Terraform AzAPI プロバイダーを使用してリソースをデプロイするためのリファレンス ドキュメントを参照してください。 すべてのリソースの種類を表示します。 learn.microsoft.com また私の案件では、災対切り替えを行うのは私ではなく運用チームです。 その際にBicepでやるのは難しいので、ポータル操作で対応するとの噂を聞きました。 ちょっと悲しいですが、災対切り替えがスムーズに行えない可能性を考えればしょうがないかもと考えています。   ARMテンプレートと比較 Bicep が ARM テンプレートよりも優れている点は、その 可読性 と 記述の容易さ にあります。 具体的にコードを比較してみましょう。 今回は、以下の要件でストレージアカウントを作成する場合を例に、Bicep と ARM テンプレートのコードを比較します。 要件のパラメータ 名前：sttomioka88 リージョン：東日本リージョン SKU：Standard_LRS ストレージの種類：StorageV2 アクセス層：Hot Bicepのコード param location string = 'japaneast' param storageAccountName string = 'sttomioka88' resource storageAccount 'Microsoft.Storage/storageAccounts@2024-01-01' = { name: storageAccountName location: location sku: {   name: 'Standard_LRS' } kind: 'StorageV2' properties: {   accessTier: 'Hot' } } ARMテンプレート（JSON）のコード {   "$schema": " https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#" , "contentVersion": "1.0.0.0", "parameters": {   "location": {     "type": "string",     "defaultValue": "japaneast"   },   "storageAccountName": {     "type": "string",     "defaultValue": "sttomioka88"   } }, "resources": [   {     "type": "Microsoft.Storage/storageAccounts",     "apiVersion": "2024-01-01",     "name": "[parameters('storageAccountName')]",     "location": "[parameters('location')]",     "sku": {       "name": "Standard_LRS"     },     "kind": "StorageV2",     "properties": {       "accessTier": "Hot"     }   } ] } コードを比較して分かること 直感的な構文 Bicep ではパラメータの参照に”[parameters(‘storageAccountName’)]”のような式を使う必要がありません。 paramで指定した値を直接参照できるのです。 そのためコードの可読性が向上してます。 ちなみに.bicepparamファイルを作れば、パラメータの管理もさらに綺麗になります。案件でもこの運用をしてました。 ネスト構造の簡略化 Bicep ではリソースのプロパティをネスト構造で記述する必要がなくなり、より容易な構造で記述できます。 カッコが無い分コードの見通しが良くなります。 そもそもJSON形式にカッコが多すぎますので、本当にあって良かったBicep。 これらの違いによりBicep を使うことで、ARM テンプレートよりも短時間で簡単にインフラをコード化することができます。 次のセクションでは、実際に Bicep を使ってストレージを作成してみますね。   Bicepでストレージをデプロイしてみる VSCodeで.bicepファイルを作成した後、右上の雲のマークからデプロイを開始できます。           Change Scopeでリソースグループを選択します。           後はDeployを押下するだけで、デプロイが完了します。Succeededが表示されていれば成功です。           Azureのポータルに確認しに行きますと、リソースが作成されていることが分かります。         さいごに Bicepの公式ドキュメントみるとパスが「Learn/紺碧/リソースマネージャー/上腕二頭筋/」になってます。             Azureってこういう変な表記になっていることが多い気がします。 常に英語のドキュメントで確認できたらもっとAzureライフが捗るなぁと思いました。

はじめに 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-アドレス」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_address_object 　を使用。 ※参考ページ：https://galaxy.ansible.com/ui/repo/published/paloaltonetworks/panos/content/module/panos_address_object/   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   Objects-アドレスの登録 接続情報とアドレス情報を指定して登録（state: ‘present’）を行う。 - name: Add Address1 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' address_type: 'ip-netmask' value: '192.168.10.0/24' description: 'address_ip-netmask' tag: ['test'] state: 'present' register: wk_result 実行結果：対象のアドレスが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.10.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-アドレスの変更　※登録のつづき 接続情報とアドレス情報を指定して　登録されたアドレスの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる - name: Change Address1 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' address_type: 'ip-netmask' value: '192.168.20.0/24' description: 'address_ip-netmask' # tag: ['test'] state: 'replaced' register: wk_result 実行結果：登録時のtag指定ありのアドレスが、Rreplaedによりtag指定なしのアドレスに変更された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.10.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.20.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n</entry>\n"   接続情報とアドレス情報を指定して　登録されたアドレスの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定の上書きとなる - name: Change Address2 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' address_type: 'ip-netmask' value: '192.168.30.0/24' # description: 'address_ip-netmask' tag: ['test'] state: 'merged' register: wk_result 実行結果：上記変更時のtag指定なしのアドレスが、mergedによりtag指定ありのアドレスに変更された。また、アドレス情報にdescriptionを指定しなくても、既存設定が維持されていることを確認。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.20.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.30.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-アドレスの情報収集　※変更のつづき 接続情報とアドレスを指定して情報収集（state: ‘gathered’）を行う。 - name: Get Address Info paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' state: 'gathered' register: wk_result 実行結果：対象アドレスの情報が取得できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.30.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"O   Objects-アドレスの削除　※変更のつづき 接続情報とアドレスを指定して削除（state: ‘absent’）を行う。 - name: Delete Address1 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' state: 'absent' register: wk_result 実行結果：対象のアドレスが削除された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.30.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after": ""   最後に 「Ansible」の「paloaltonetworks.panos.panos_address_object」を使用し、「Objects-アドレス」の登録／変更／削除　および　情報収集ができたことは良かった。何らかの変更申請の仕組みと連携することで、より　設定変更の自動化　が活用できるようになると考える。 現状　設定情報がベタ書きで使い勝手が悪いので、今後　設定内容をINPUTする仕組みを試みたいと思います。 また、引続き　他にも様々なNW機器設定を自動化してみようと思います。

みなさん、こんにちは。SCSK株式会社の津田です。 LifeKeeperではサービスをリソース化してHAクラスタの保護対象とする際、どのオプション製品を使うか？ というのはLifeKeeperの設計フェーズでのポイントの一つになるかと思います。 今回はQuick Service Protection(以下QSP)についてご紹介します！ オプション製品についておさらい はじめに、 第２回　「LifeKeeper」で可用性を高められるミドルウェアはこれだ！ でも少しお伝えしている オプション製品についておさらいとなります。 LifeKeeperではサービスをHAクラスタの保護対象とする際、ARKというスクリプト集で起動・停止・監視・回復を制御します。 サイオステクノロジー社により様々なサービスに沿った専用のARKが用意されてはいますが、 もし保護対象にしたいサービスの専用ARKがない場合は、以下の選択肢があります。 選択肢➀ Generic ARK 選択肢➁ QSP 有償オプションの専用ARKとは異なり、上記選択肢はどちらも無償オプションとなります。 「Generic ARK」を利用する場合の特徴として、アプリケーションの起動・停止・監視・回復(任意)を制御するスクリプトの作成が必要となります。 サイオステクノロジー社よりベースとなるスクリプトは提供されているものの、スクリプトを準備することはGenericARKを利用する上でのハードルとなるケースがあります。 対する 「QSP」を利用する場合の特徴として、OSの機能(init,systemdやWindowsサービス)で起動・停止・監視・回復を行います。 そのためスクリプトの作成は不要で簡単にLinux、Windows上の一般的なサービスをLifeKeeperの保護対象とすることができるんです！ QSPメリット・デメリット 以下QSPの主なメリット・デメリットをあげていきます。 QSP検討の際の参考となれば幸いです。 メリット ・スクリプトの準備が不要 　 GenericARKのようなスクリプトの事前準備は不要となります。 ・設計・構築スケジュール短縮が見込める 　 スクリプトの準備不要でGUIより簡単にQSPのリソースを構築することができます。 ・導入コストを抑えられる 　 設計・構築スケジュール短縮に加え、QSPは無償オプションとなりますのでコストを抑えることができます。 デメリット ・サービスがinit、systemd、Windowsサービスに対応していない場合は利用できない 　 (※init,systemd、Windowsサービスに対応していてもQSPが利用できない場合があります。注意点として後述します。) ・専用ARKが用意されているサービスに対しては利用できない ・OSの機能による簡単な監視処理しかできない 　 監視処理はOS機能によるステータスでの判断となるため、細かな監視は行えません。 　 ※監視内容を細かく設定したい場合は、Generic ARKの利用が適しています。 QSP利用前の注意点 前述の「QSPメリット・デメリット」でも少し記載しましたが、 一部のサービスについては、init、systemd、Windowsサービスに対応していてもQSPが利用できない場合もありますので注意が必要です。 QSPで保護対象としたいサービスがある場合は、一度以下で確認されることをおすすめします。 ▼サイオステクノロジー社公開のHA化で実績のある対応ソフトウェア一覧です。 https://bccs.sios.jp/lifekeeper/sw.html ※「ARK以外の保護方法」欄にQSPの記載があるものはLifeKeeperでのリソース化実績があるものになります。 QSPの記載はないが最新の実績状況を知りたい、この表にないソフトウェアのサービスを保護したいという場合は、 サイオステクノロジー社またはSCSKにお気軽にお問合せください。 ▼サイオステクノロジー社公開のLinuxのQSPの保護対象外サービスの一覧です。 https://lkdkuserportal.sios.jp/hc/ja/articles/900000555366 まとめ 今回はQSPについてご紹介いたしました。 以下に該当する場合はQSPでのサービス保護をぜひご検討頂ければと思います！ ・保護対象のサービスはOS機能(init、systemd、Windowsサービス)で制御可能 ・スクリプト作成の手間を省きたい ・監視はサービスの起動・停止確認だけでよい 　 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで

LifeKeeperでは管理コンソールを用いて、設定投入やパラメータ確認、手動切替などを手軽に行うことが可能です。 今回は、LifeKeeperの管理コンソールである「LKWMC」について解説していきます。 概要 LifeKeeper Web Management Console (LKWMC) は、Webベースの管理コンソールです。 LKWMCを使用することにより、ブラウザを通じてクラスタの管理や操作、監視を行うことができ、GUIを利用することで、より直感的にLifeKeeperの操作が可能になります。 LKWMCは、従来の管理コンソールと比較し、LifeKeeper専用のGUIアプリケーションをクライアントPCへインストールする必要がなく、Webブラウザーを利用して多様なデバイスからアクセス可能です。 また、LifeKeeperノードにログイン(sshなど)したり、クライアントに専用のGUIアプリケーションを起動する必要もありません。   仕組み 以下イメージ図です。 LKWMCでは、LifeKeeperのクラスターを構成する各サーバーへ、[GUIサーバー]と、[REST APIサーバー]をインストールします。 GUIを利用する際には、Webブラウザーを利用しアクセスを行います。 Webブラウザーの画面上で各種操作を実行すると、[GUIサーバー]がクラスター上の各サーバーの[REST APIサーバー]と通信することで、LifeKeeperが保持する各種リソース状態の取得・操作が可能です。 これにより、LifeKeeperクラスターサーバー上で直接動作する専用のJavaベースのGUIクライアントアプリケーションに（例えば、SSH X11転送またはVNCセッションを介して）接続する必要がなくなります。   GUIサーバーとは LKWMCのGUI(Graphical User Interface)部分をWebアプリケーションとして提供します。 また、LKWMCのGUI上で行った各種操作の命令をLifeKeeperクラスター上の別のサーバーへ転送する機能を持っています。   REST APIサーバーとは LifeKeeperコアの各種操作・リソース管理などの機能をWeb APIとして提供します。 LKWMCを利用する際には、LifeKeeperクラスターを構成する全てのサーバー上に同一のバージョンの[REST APIサーバー]がインストールされている必要があります。   インストールについて インストール方法 対象ノードにインストールスクリプトを格納し、実行すればOKです。 # /lkwmc/sios-lkwmc-1.2.0/install Installing LifeKeeper Web Management Console (LKWMC) v1.2.0... -- Performing pre-installation checks... -- Installing supporting files... ～～以下省略～～ Starting LifeKeeper Web Management Console... Created symlink /etc/systemd/system/multi-user.target.wants/lifekeeper-wmc.service → /usr/lib/systemd/system/lifekeeper-wmc.service. Done Note: LifeKeeper Web Management Console must be installed on all servers in the LifeKeeper cluster. To connect to the LifeKeeper Web Management Console from a web browser: https：//xxxx:5110 # 上記のような出力がされます。 インストールが成功したことを確認するには、以下のコマンドを用いて確認できます。 lifekeeper-apiサービスとlifekeeper-wmcサービスが正常に実行されている(出力結果がある)ことを確認します。 # systemctl status lifekeeper-api # systemctl status lifekeeper-wmc   起動と停止について lifekeeper-apiおよびlifekeeper-wmc systemdサービスは REST APIおよびGUIサーバーパッケージの初期インストール時に起動され、有効になります。 それらのサービスが有効になると、サーバーの再起動時にsystemdによって自動的に再起動されます。 systemctlコマンドを使用して、上記サービスを停止したり、 システムの再起動時にサービスが自動的に再起動することを無効化することができます。 コマンド詳細は以下のサイトに記載がありますので、ご参照ください。 LKWMCサービスの起動と停止 – LifeKeeper for Linux LIVE – 9.8.1   起動方法 インストールが完了しましたら、Webブラウザーのアドレス欄に、 下記を入力することでLKWMCの画面が表示されます。 https://{該当ノードのIPアドレス・ホスト名}:5110/lkgui/#/   各項目解説 セットアップが完了しましたら、各項目で設定を入れていきます。 今回は各項目ごとの解説を行っていきます。 こちらが項目の一覧となります。   コミュニケーションパス コミュニケーションパスとは、各ノード間でお互いの状態等の情報をやり取りするための経路になります。 コミュニケーションパスの項目では、コミュニケーションパスの作成、フェイルオーバーする際のプライオリティの設定、ステータスの確認をすることが可能です。   プロパティー(サーバー) ノード情報やLifeKeeperのバージョン確認などのパラメータを確認できます。 また、オペレーション＞プロパティ-の編集　から各種情報の修正も可能です。   サインイン状況 各ノードのサインイン状況が確認できます。 なお有効期限と記載されているのは、ノードにインストールされているLifeKeeperライセンスの有効期限やLKWMCの有効期限ではなく 対象ノードにサインインした時間を表記しているようです。   リソースツリー 各リソースの状態(どのノードがPrimaryであるかや、ステータスがALiveかDeadであるかなど)の確認を視覚的にわかりやすく確認できます。 また、リソースの作成/削除やスイッチオーバー/スイッチバックの動作、リソースの依存関係などの各設定を「オペレーション」から設定・操作が可能となります。   プロパティー(リソース) 各ノードの各リソースの設定値を確認できます。 リソース項目の「▼」にて確認したいリソースを選択し、そこからマウントポイントやステータスなどの情報を確認できます。 また、オペレーションからプロパティーの修正をすることも行えます。   ログ ローカルサーバーの箇所で確認したいノードを選択し、各ノードのログを確認できます。 フォントサイズやログ出力の行数を調整できます。 また、検索窓より、確認したい内容のログの検索も行えます。   ライセンス インストールされているライセンスについて確認できます。 ライセンスタイプに併記される情報は以下の種類があります。 UNLICENSED LifeKeeper Coreのライセンスが適用されている状態 EVAL 評価版ライセンスが適用されている状態 PERMANENT オプションRecovery Kitのライセンスが適用されている状態 NEEDED オプションRecovery Kit のライセンスが適用されていない状態 以上がLKWMCの設定項目になります。   最後に 今回はLifeKeeperの管理コンソールである「LKWMC」について解説をしました。 実際の管理画面を見たことが無かった方や、これから利用を検討している方に操作するイメージを持っていただければ幸いです。 LifeKeeperに関してより詳しい情報をお求めの方は、下記バナーを通じてお問い合わせください。