みなさま、こんにちは！ 最近笑いすぎてそろそろ腹筋が割れそうです。いとさんです。 先日目黒にてJapan AWS Top Engineers GameDay が開催されました。 社内のJapan AWS Top Engineersの方からご連絡いただき、こちらTop Engineerの方に同伴者が一人参加できるとのことで勇気を出して立候補しました。 私のスペック 名前 : いとさん ジョブ : サイト運営、セミナー運営、デザイン レベル : IT業界約1年 経験値 : AWSを触り始めて4ヶ月目 特技 : デザイン アイテム : PC んー…経験値もレベルも足りなさ過ぎているような気がしますが、とりあえずやってみようの精神で！ AWS Top Engineersの方々の渦に飛び込んみました。 メンバーの皆さん [左から(アイレット株式会社)髙橋さん、私、(キンドリルジャパン株式会社)奈良さん、(ソニービズネットワークス株式会社)濱田さん] 上記の御三方、実は AWS Ambassadors… 私、とんでもなく凄いメンバーの方々と一緒になってしまいました 因みにチーム名は The Generators。 どこかアーティストみを感じるとってもいい名前ですね👍 GameDay概要 GameDayの詳細はネタバレ防止のため公開できませんが、4名1チームとなり技術的課題の解決に挑み、GenAIを使ってアプリケーションのバグや生成AIの組み込みを行うというものでした。 書くことが出来ないのが大変心苦しいのですが シナリオ概要の説明が面白く細かいところまでこだわっていて運営の皆様の努力を感じました。 作業内容 作業は私とリーダーの方を1人と換算し3人で大設問を分担して行っておりました。 やはりひよっこの私にできることはとても少なかったですね。 プロンプトエンジニアリング、Amazon Bedrockの概要、ガードレール等について、コーチングしていただきながら設問に対して回答していきました。私の担当した設問はAmazonQやBedrockを使用してAIと会話し解決するというプロンプトエンジニアリングが重要になってくる設問でした。 stepfunctionもサービスとしては知っていましたが初めて触り、どのように動作しているかを実際に確認することが出来ました。 他の設問を担当していたメンバーの皆さんの解決スピードは全体の中で 1桁台！ (私は2桁…流石Ambassadorsの力強い…) お助けいただき、順調に進み残り1問となりました！ 全体順位10位台、残り時間は1分…F5キーを連打、果たして完走できたのでしょうか… 結果はいかに… 終了～！ 司会の方の合図とともに皆さん作業が終了いたしました。 解説の後ついに順位発表、果たして The Generators の結果は (;ﾟДﾟ)(ﾟДﾟ;(ﾟДﾟ;)(;ﾟДﾟ)…ｴｯ? なななんと、 優勝 でした…滑り込みで回答が間に合っていたようです。(F5の力凄い…) チームメンバーの皆さん含めまさか優勝とは思っておらず喜びより驚きが大きかったです。(2,3位の方も例年参加されている方々のため) 今後に向けて … 参加して今後に活かしていきたいことがいくつかありました。 プロンプトエンジニアリングに関する知識の必要性 Bedrockに質問するにあたり漠然としたプロンプトでは、期待外れの出力しか生成できないことが多く、何度も試行錯誤を繰り返すことになります。プロンプトエンジニアリングを習得することで、 一度のプロンプトで目的の結果に近づける ことが可能になり、時間とリソースの無駄を省くことができると感じた。 幅広い知識の習得 今回GenAIに関するGameDayだったからなのかクラウドの知識とAIとの対話、コーディングの理解が必要。 原因解決にあたりサービスの理解に加え開発に関する多様な知識があるとスピーディーに原因究明、解決に進めるのかなと思った。 メンバーとのコミュニケーションの重要性 今回のメンバーの方はお互いに解決できないことに対し積極的に会話を行なっており明るく作業を進めているように感じた。制限時間の間ずっと各個人で黙々行うチームもあったのかと思いますが今回一緒に進めさせていただいたメンバーの方は会話を、雰囲気を大切にされていて実力もあると思いますが、そこがさらに優勝に繋がった要因なのかと思いました。今後の業務でもポジティブに雰囲気を大切にしていこうとさらに思わされました。   感想&賞品 問題によっては初学者(ひよっこ)でも解ける問題がある。 GameDayのテーマの学習を進めておくと少し楽になるかも…？と思いました！ 初めてのGameDayは学びになることが多くとても楽しかったです。 新しい場所に飛び込むのは緊張すると思いますが玄人の皆さんはとても優しいです。 是非積極的に楽しんで飛び込んでいきましょう！！ 優勝商品とシールをいただきました🎁かわいい 冷たい飲み物沢山飲みます🎵

SCSK 永見です。 Reserved Instance、コスト削減の話になると、よく出てきます。 これらを詳しく知ろうとして調べても、詳細な説明に終始して、そもそも何なの？というのがよくわからず困った記憶があります。 この記事は「Reserved Instance チョットワカル」私が、この記事の読者に「Reserved Instance 完全に理解した」状態へ導く記事となっています。 前提事項 この記事は、初めてReserved Instance(以下、RI と省略します)に触れる人向けに、分かりやすさに重きを置いて執筆しています。正確・詳細な情報は公式ドキュメントなどを参照にしてください。 また、料金はすべて例示の値です。正式な情報は料金表をご確認ください。 Amazon EC2 リザーブドインスタンス料金表 | AWS aws.amazon.com 今回はEC2のRIを例にとり、説明しています。 Reserved Instanceとは？ カフェで使える割引券をイメージしてみましょう。 この割引券は、ドリンクの種類(コーヒー、カプチーノ、抹茶ラテ、etc…)、ドリンクのサイズ(S、M、L)、などを指定して購入します。 その割引券を使うことで、指定された条件と一致した種類・サイズのドリンクと引き換えることができます。 そして、普通に買うよりも割り引かれた金額でドリンクを購入することができます。 例えば、コーヒーSサイズ(以下、”コーヒー”と省略します)が1杯500円とし、この”コーヒー”用の割引券12枚つづりは4,800円で購入できる とします。 この割引券を使うことで、20%引きの400円で飲むことができます。 さて、割引券をRIに、”コーヒー”をインスタンスに置き換えてみましょう。 RIは、プラットフォーム(Linux、Windows、RedHat)、インスタンスタイプ(t3.large、r5.xlarge)などを指定して購入します。 購入されたRIは、指定された条件と一致したEC2インスタンスに対して、その料金として充当されます。 そして、オンデマンドで使うよりも割り引かれた金額でEC2インスタンスを利用することができます。 例えば、Linux、t3.largeのEC2インスタンスが、オンデマンドでは1時間あたり$0.1とし、このインスタンス相当のRI(1年間)は$560.64=$0.064/h×24時間×365日 で購入できる とします。 このRIの料金充当により、1時間あたり$0.064でEC2インスタンスを利用することができます。 じゃあたくさん買えばお得になるの？ 安く使えるならたくさん割引券を買っておけば、お得になるんじゃないの？と思うかもしれませんが、そうはいきません。 この割引券は毎月1枚しか使えず、かつ1か月間の使用期限があります。 なので、毎月コンスタントに”コーヒー”を飲む人にとってはお得ですが、1か月で12杯飲むために使用することはできません。 同じくRIも、割引は一時間ごとに適用され、一時間のうちに使用されたEC2に対して割引が適用されます。 なので、24時間365日稼働するEC2がある場合にはお得ですが、一時的な開発で大量のEC2を使う という場合にはコストメリットは享受しづらいです。 どうやって使うの？ コーヒーの割引券は購入の時に出すことで引き換えることができますが、RIは購入するだけで勝手に割引が適用されます。 また、コーヒーは”1杯”に対して割引が適用されますが、RIは対象のインスタンス”合計1台分”に対して割引が適用されます。 例えば、Linux、t3.largeのRIを1台分買っていて、かつLinux、t3.largeのEC2インスタンスが2台あった場合、30分間は2台ともRIによる割引料金で、のこり30分は2台ともオンデマンドの料金になります。 もっと安くするにはどうしたらいいの？ もっとお得に、つまりもっと安く”コーヒー”を飲むにはどうしたらいいでしょうか。 主に3つ方法があります。 方法その1：有効期限が長いものを買う この割引券は12枚(12枚×1年分)綴りと36枚(12枚×3年分)綴りがあります。36枚入りのほうが、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 Reserved Instanceは、期間が1年間と3年間があります。3年間のほうが、より割引率が高くなります。 方法その2：先払いする この割引券には3種類の買い方があります。 1つは最初に全額払ってしまう方法、2つ目は半額払って半額ののこりを分割払いする方法、3つ目は毎月分割払いする方法。 最初に払う金額が大きいほど、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 RIは、支払い方法が全額前払い、一部前払い、前払いなしの3種類あります。 最初に払う金額が大きい、つまり全額前払い→一部前払い→前払いなし の順番で、より割引率が高くなります。 方法その3：交換できない割引券を買う この割引券には、”コーヒー”以外の割引券に交換できる種類とできない種類があります。交換できる割引券において、値段が違う場合は、差額を払うことで交換することができます。 交換できない割引券のほうが、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 Reserved Instanceは、提供クラスにはスタンダートとコンバーティブルがあります。スタンダードは他のReserved Instanceと交換できませんが、コンバーティブルであれば交換できます。 交換できないスタンダードのRIのほうが、より割引率が高くなります。 まとめ Reserved Instanceとはそもそも何なのか、について説明しました。 RIの活用はじめ、コストに関してお困りごとがあればぜひSCSKまでご相談ください！ SCSKクラウドサービス（AWS）│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション アマゾン ウェブ サービス（AWS)の最上位パートナーであり、多種多様な業界のシステム構築実績を持つSCSKが、最適なAWS導入をサポート。AWS活用によるお客様のITガバナンス強化とDX推進を強力に支援します。 www.scsk.jp

SCSK 永見です。 Reserved Instance、Savings Plans。 コスト削減の話になると、よく出てきます。 これらを詳しく知ろうとして調べても、詳細な説明に終始して、そもそも何なの？というのがよくわからず困った記憶があります。 この記事は「Savings Plans チョットワカル」私が、この記事の読者に「Savings Plans完全に理解した」状態へ導く記事となっています。 前提事項 この記事は、初めてSavings Plans(以下、SPsと省略します)に触れる人向けに、分かりやすさに重きを置いて執筆しています。正確・詳細な情報は公式ドキュメントなどを参照にしてください。 また、料金はすべて例示の値です。正式な情報は料金表をご確認ください。 Compute Savings Plans – アマゾン ウェブ サービス Savings Plans は柔軟な購入オプションです。1 年または 3 年の契約でさまざまな AWS Compute サービスに対する大幅な割引を提供します。Savings Plans には、Compute Savings Plans と... aws.amazon.com 今回はEC2のSPsを例にとり、説明しています。 Savings Plansとは？ カフェで使えるプリペイドカードをイメージしてみましょう。 ドリンクの種類(全種類、コーヒー、カプチーノ、抹茶ラテ、etc…)、有効期限などを決めたうえで、金額を指定してチャージするようなプリペイドカードです。 このプリペイドカードで、指定したドリンクを購入することができます。 そして、普通に買うよりも割り引かれた金額でドリンクを購入することができます。 例えば、ホットコーヒー(以下、”コーヒー” と省略します)が1杯500円とします。 “コーヒー”用のプリペイドカードから支払うことで、20%引きの400円で飲めてしまいます。 さて、プリペイドカードをSavings Plansに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、適用するインスタンスの種類、期間などを決めたうえで、金額を指定します。これをコミットメントといい、「期間中、1時間当たり$〇〇分のリソースを使います！」と宣言するようなイメージです。 このコミットメント額は、指定された条件と一致するEC2インスタンスに対して、その料金として充当されます。 割引後の金額合計がコミット額に達する分まで、割引を適用することができます。 例えば、Linux、t3.largeのEC2インスタンスが、オンデマンドでは1時間あたり$0.1とし、t3系のSPsを$1.00/hのコミットメントを1年間分、つまり$365分購入した とします。 このSPsの料金充当により、1時間あたり$0.06でEC2インスタンスを利用することができます。 じゃあたくさんチャージすればお得になるの？ 安く使えるならたくさんチャージしておけば、お得になるんじゃないの？と思うかもしれませんが、そうはいきません。 このプリペイドカードは毎月一定額しか使えず、かつ1か月間の使用期限があります。使い切れなかった分は失効してしまいます。 なので、毎月コンスタントに”コーヒー”を飲む人にとってはお得ですが、1か月で12杯飲むために使用することはできません。 同じくSPsも、割引は一時間ごとに適用され、一時間のうちに使用されたEC2に対して割引が適用されます。 なので、24時間365日稼働するEC2がある場合にはお得ですが、一時的な開発で大量のEC2を使う という場合にはコストメリットは享受しづらいです。 どうやって使うの？ プリペイドカードは支払いの時に出すことで使うことができますが、SPsは購入するだけで勝手に割引が適用されます。 また、コーヒーは”1杯”に対して割引が適用されますが、SPsは対象のインスタンス”合計利用額”に対して割引が適用されます。 ちょっと難しいので、詳しく説明します。 例えば、このようなケースを想定してみましょう。 t3のEC2 Instance Savings Plans を$1.00/h分購入 t3.largeのEC2インスタンスが20台、1時間稼働。 このt3.largeインスタンスにおけるオンデマンド料金は$0.1/h、SPs料金は$0.06/h。削減率は40%=100%-$0.06÷$0.1 結論はこんなイメージになります。点線内がSPsによる充当で合計$1.00、点線外がオンデマンド価格となります。 細かく計算過程を追ってみましょう。 このケースの利用額は、全額オンデマンド料金と全額SPs料金の場合それぞれ算出すると、以下のようになります。 今回はSPsを$1.00分購入しているので、以下のように一部SPsによる充当、一部オンデマンドによる支払いに分けます。 $1.00のSPsによる充当額と、充当しきれなかった分のオンデマンド相当額の$0.33、計$1.33がかかります。 もっと安くするにはどうしたらいいの？ もっとお得に、つまりもっと安く”コーヒー”を飲むにはどうしたらいいでしょうか。 3つ方法があります。 方法その1：有効期限が長いものを買う このプリペイドのチャージ方式は有効期限1年間(指定金額×12ヶ月分)と3年間(指定金額×36ヶ月分)があります。 3年間のほうが、より割引率が高く、安く”コーヒー”を買うことができます。 ※指定金額を大きくしても割引率は大きくなりません。 さて、プリペイドカードをSPsに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、期間が1年間(コミットメント額×24時間×365日)と3年間(コミットメント額×24時間×365日×3年間)があります。 3年間のほうが、より割引率が高くなります。 ※コミットメント額を大きくしても割引率は大きくなりません。 方法その2：先払いする このプリペイドカードには3種類のチャージ方法があります。 1つは最初に全額チャージしてしまう方法、2つ目は一部チャージしてのこりを毎月チャージする方法、3つ目は毎月チャージする方法。 最初にチャージする金額が大きいほど、より割引率が高く、安く”コーヒー”を買うことができます。 さて、プリペイドカードをSPsに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、支払い方法が全額前払い、一部前払い、前払いなしの3種類あります。 最初に払う金額が大きい、つまり全額前払い→一部前払い→前払いなし の順番で、より割引率が高くなります。 方法その3：専用プリペイドカードを買う このプリペイドカードは、カフェの全商品に対して使える「なんでもプリペイドカード」と、特定の商品に対して使える「専用プリペイドカード」があります。 なんでもプリペイドカードよりも、専用プリペイドカードのほうが、より割引率が高く、安くコーヒーを買うことができます。 さて、割引券をSavings Plansに、コーヒーをインスタンスに置き換えてみましょう。 EC2に適用できるSPsには、Compute Savings PlansとEC2 Instance Savings Plansがあります。 Compute Savings Plansはあらゆる種類のEC2に適用されますが、EC2 Instance Savings Plansは購入時に指定したインスタンスファミリーのみに適用できます。 指定したインスタンスファミリーにしか適用できないSPsのほうが、割引率は高くなります まとめ SPsとはそもそも何なのか、について説明しました。 SPsの活用はじめ、コストに関してお困りごとがあればぜひSCSKまでご相談ください！ SCSKクラウドサービス（AWS）│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション アマゾン ウェブ サービス（AWS)の最上位パートナーであり、多種多様な業界のシステム構築実績を持つSCSKが、最適なAWS導入をサポート。AWS活用によるお客様のITガバナンス強化とDX推進を強力に支援します。 www.scsk.jp

こんにちは、ひるたんぬです。 最近は暑い日が続いていますね。私はこの時季になると冷房が欠かせないものとなっています。 世間では「春と秋がどんどん短くなっている」と言われており、私もそう思っていたのですが、具体的にどれだけ短くなっているのでしょうか？ 調べてみると、そもそも春夏秋冬の絶対的な定義というものは存在しないようです。 気象学や天文学、伝統的な区切り方がそれぞれあるようですね。 こうなると、「私にとっての春」と「未来の人にとっての春」のイメージは大きく異なるものになりそうですね。 ひまわりは春の花、が常識になる日も…？ ※ 参考… 国立天文台 | 暦Wiki「季節とは？」 さて、今回は標準ユーザーが管理者権限を持つユーザーに昇格した場合に、そのアクティビティをAmazon SNSを用いて通知する方法をご紹介します。 やりたいこと Windows OSにおいて管理者権限を持たないユーザーが、管理者権限を持つユーザーに昇格した場合に、他の管理者に通知したい場合を想定しています。今回のWindows OSはWorkSpaces上で稼働している想定ですが、WorkSpacesに限らず、どこでも通用するかなと思います。 やり方 ここからは、実際にどのように設定していくかをご紹介していきます。 事前準備 通知先のAmazon SNSトピック・サブスクリプションを作成します。 今回はメールでの通知を設定しています。 また、後述するスクリプトがメッセージを送信できるようにIAMユーザーとアクセスキーを作成します。 最小権限の原則から、当該トピックでのSNSメッセージ送信のみ許可されたIAMユーザーを新しく作成することを推奨します。 今回はこれら事前準備の手順は割愛します。詳細は公式ドキュメントなどをご参照ください。 Amazon SNS トピックを作成する - Amazon Simple Notification Service AWS SDKs を使用して Amazon SNS トピックを作成する包括的な手順について説明します。トピックタイプの選択、命名規則、暗号化の有効化、アクセス許可の設定の手順について詳しく説明します。 AWS Management Cons... docs.aws.amazon.com Amazon SNS トピックのサブスクリプションの作成 - Amazon Simple Notification Service を使用して Amazon SNS トピックにエンドポイントをサブスクライブする方法について説明します。トピック ARN の選択 AWS Management Console、エンドポイントタイプ (HTTP/HTTPS、E メール、Amaz... docs.aws.amazon.com AWS アカウント で IAM ユーザーを作成する - AWS Identity and Access Management AWS Identity and Access Management で IAM ユーザーと認証情報を作成するために使用されるプロセスの基本的な概要。 docs.aws.amazon.com IAM ユーザーの新しいアクセスキーを作成する - Amazon Keyspaces (Apache Cassandra 向け) AWS 認証情報を使用してプログラムによって Amazon Keyspaces に接続するために、IAM ユーザーまたはロールのアクセスキーを作成する方法を説明します。 docs.aws.amazon.com なにをトリガーにするか 今回の肝となるのは、「どのように管理者権限を持つユーザーに昇格したことを知るか」です。 調べてみると、これはWindows ログのイベントとしてログが記録されることが分かりました。 今回はこの中でも「セキュリティ」の中に記録されているイベントIDが4648のログに着目します。 このログは明示的な資格情報を使用したサインインを記録するもので、RUNASなどの昇格操作を実施した際に記録されるものです。 実際に昇格操作を実施したところ、確かにログが記録されることを確認したので、今回はこのイベントIDのログを利用することにします。 Amazon SNSでの通知スクリプト トリガーを受けての操作として、Amazon SNSを用いた通知を行います。今回はこの部分をPowerShellのスクリプトで作成しました。 今回は「admin」という名前を含むユーザーに昇格した場合に通知をするという内容にしています。 関数の引数はIAMの認証情報と、通知先のSNSトピックのARNが必須で必要です。適宜付与するようにしてください。 また、エラー処理などはすべて省いております。 function Get-AdminAlert {   param (       [Parameter(Mandatory = $true)]       [string]$AccessKey,         [Parameter(Mandatory = $true)]       [string]$SecretKey,             [Parameter(Mandatory = $true)]       [string]$TopicArn,                [Parameter(Mandatory = $false)]       [string]$Region = "ap-northeast-1"   )   # AWS CLI用の環境変数を設定   $env:AWS_ACCESS_KEY_ID = $AccessKey   $env:AWS_SECRET_ACCESS_KEY = $SecretKey   $env:AWS_DEFAULT_REGION = $Region     # イベントログから管理者に昇格しているログを抽出   $admin_name = "admin"   $now = Get-Date     # 発火時から30秒以内の該当イベントログを取得   $eventlog =  Get-EventLog -LogName Security -Newest 1 -EntryType SuccessAudit -InstanceId 4648 -Message *$admin_name* -After $now.Addseconds(-30)   if ($eventlog -eq $null) {       Write-Host "No relevant event logs found." -ForegroundColor Yellow       return $false   }     # Message内を処理するため、Jsonに変換後PowerShellオブジェクトに変換   $eventlog_json = $eventlog | ConvertTo-Json   $eventlog_object = ConvertFrom-Json $eventlog_json     # 昇格先アカウント名を抽出   $admin_account = $eventlog_object.ReplacementStrings[5]   if ($admin_account -eq $null) {       $admin_account = "Unknown"       Write-Host "No admin account found in the event log."   }     # イベント発生日時を抽出（UTC）   $eventtime = $eventlog_object.TimeGenerated   # イベント発生日時を日本時間に変換   $eventtime_jst = $eventtime.ToUniversalTime().AddHours(9)     # SNSメッセージの作成   $subject = "昇格操作が実行されました"   $snsMessage = "以下の昇格操作が実行されました。`n`n" +                 "昇格先アカウント: $admin_account`n" +                 "イベント発生日時: $eventtime_jst`n"     # Amazon SNSを使用して通知を送信 $messageId = (aws sns publish --topic-arn $TopicArn --subject $subject --message $snsMessage | ConvertFrom-Json).MessageId     finally {       # 環境変数をクリア       Remove-Item Env:\AWS_ACCESS_KEY_ID -ErrorAction SilentlyContinue       Remove-Item Env:\AWS_SECRET_ACCESS_KEY -ErrorAction SilentlyContinue       Remove-Item Env:\AWS_DEFAULT_REGION -ErrorAction SilentlyContinue   } } トリガーの設定 トリガーにしたいイベントと、実行したいスクリプトが完成したので、最後にトリガーを設定します。 ここでは、Windowsのタスクスケジューラを用います。 「全般」タブにおいて、タスク名には任意の名前を設定します。一方、セキュリティオプション内の「タスクの実行時に使うユーザー アカウント」ではSYSTEMユーザーを指定します。 「トリガー」タブでは、トリガーを設定します。先程決定したイベントをトリガーとして設定します。 「タスクの開始」を「イベント時」、「ログ」を「セキュリティ」、「ソース」を「Microsoft Windows security auditing.」、「イベントID」を「4648」とします。 次にトリガーが発火した後の操作を設定します。 「操作」タブから「操作」を「プログラムの開始」、「プログラム/スクリプト」を「PowerShell.exe」、「引数の追加」で「-NoProfile -ExecutionPolicy Bypass -File “ファイルパス”」と指定します。 動作確認 実際に昇格操作を実施してみます。すると… しっかりメールで通知がされました！ 終わりに 今回はWindowsの標準機能とAWSの機能を組み合わせて管理者権限への昇格操作を通知する仕組みをご紹介しました。 タスクスケジューラのトリガーでは、トリガーのきっかけとなったイベントのログIDなどを知ることができないため、どのログによって発火したのかをPowerShellのスクリプトで知ることができません。 そのため、今回は30秒以内の最新の昇格操作を取得し送信するという対処法を取っています。 AWSのEventBridge的な感覚で触っていた私にとっては、この点は少し不便な仕様だな…と思った次第です。 余談 CloudWatch Agentをインストールして、セキュリティログをCloudWatch Logsに出力してゴニョゴニョ…の方がセンスあるかも？とも思いました。

はじめに 当記事は、 日常の運用業務（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_service_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 Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '10' source_port: '110' description: 'test_service001' tag: ['test'] state: 'present' register: wk_result 実行結果：対象のサービスが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの変更　※登録のつづき 接続情報とサービス情報を指定して　登録されたサービスの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる - name: Change Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '20' source_port: '120' description: 'test_service001' # tag: ['test'] state: 'replaced' register: wk_result 実行結果：登録時のtag指定ありのサービスが、Rreplaedによりtag指定なしのサービスに変更された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</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_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n"   接続情報とサービス情報を指定して　登録されたサービスの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定の上書きとなる - name: Change Service2 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '30' source_port: '130' # description: 'test_service001' 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_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの情報収集　※変更のつづき 接続情報とサービスを指定して情報収集（state: ‘gathered’）を行う。 - name: Get Service Info paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' state: 'gathered' register: wk_result 実行結果：対象サービスの情報が取得できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n",   Objects-サービスの削除　※変更のつづき 接続情報とサービスを指定して削除（state: ‘absent’）を行う。 - name: Delete Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' state: 'absent' register: wk_result 実行結果：対象のサービスが削除された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : ""   最後に 「Ansible」の「paloaltonetworks.panos.panos_service_object」を使用し、「Objects-サービス」の登録／変更／削除　および　情報収集ができたことは良かった。何らかの変更申請の仕組みと連携することで、より　設定変更の自動化　が活用できるようになると考える。 現状　設定情報がベタ書きで使い勝手が悪いので、今後　設定内容をINPUTする仕組みを試みたいと思います。 また、引続き　他にも様々なNW機器設定を自動化してみようと思います。

こんにちは。SCSKの青木です。 Interop Tokyo2025の2日目に参加してきました。 参加したセッションや見に行った展示について感想を書こうと思うので、気になるものがあればぜひ読んでください。 Interopとは 日本を問わず色々な企業が参加し製品紹介やセミナーを行っているインターネットテクノロジーのイベントになります。 以下は公式からの引用となります。 Interop Tokyoはインターネットテクノロジーのイベントです。 1994年の日本初開催以来、毎年国内外から約500の企業・団体が参加し、技術動向とビジネス活用のトレンドを、会場でのデモンストレーションやセミナーを通じてお伝えしてきました。国内のインターネットや技術革新の歴史と共に歩んできたこのInterop Tokyoをご覧いただくことで、インターネット分野のトレンドをいち早く体感いただくことができます。 引用） Interop Interop Tokyo 2025 「Interop Tokyo」は技術動向とビジネス活用のトレンドを会場でのデモンストレーションやセッションを通じてお伝えするインターネットテクノロジーイベントです。 www.interop.jp   参加したセッション この製品チェック！～アワード審査員が今年の注目製品を解説～ 6/12（木）、6/13（金）の二日に分けて注目製品の発表がありました。 物理機器やラックの紹介が多く、クラウド案件を担当しているため、あまり考えたことはなかったですが、データセンターには、このようなネットワーク機器が数多く並んでいるのだと実感しました。 6/12（木）の解説された部門 ・セキュリティ ・デジタルメディア ・産業ネットワーク ・IoT/エッジコンピューティング ・ファシリティ 特に印象に残った製品：Cisco社「Cisco AI Defense」 普段はサーバやクライアントに対してセキュリティ製品を導入するのが一般的だと感じていましたが、日々利用しているAIに対して専用のセキュリティ製品を使用するという発想は思い浮かんだことがありませんでした。 また、AIを活用すること方法については考えたことはありますが、AIに対する攻撃について考えることがなかったのでAIに対する攻撃を知る良い機会となりました。 参考） アワード受賞企業一覧 Interop Tokyo 2025 「Interop Tokyo」は技術動向とビジネス活用のトレンドを会場でのデモンストレーションやセッションを通じてお伝えするインターネットテクノロジーイベントです。 interop.jp Cisco AI Defense Cisco AI Defense AI Defense は、AI の開発、展開、使用によってもたらされる安全性およびセキュリティのリスクを防ぐ、エンドツーエンドの AI セキュリティソリューションです。 www.cisco.com Chrome Enterpriseで実現する、AI時代の生産性とゼロトラスト 主な紹介機能 ・マルチOS対応のブラウザ制御 ・拡張機能のリスク監査と制御 ・悪意のあるサイトへのリアルタイム監査 ・セキュリティログの可視化・分析 管理方法の特徴 ・上記の機能は、ブラウザにログインすることでポリシーとして適用される。 ・ブラウザベースで一元管理できるため、業務をブラウザに集約することでデバイス側の設定が削減可能となる。 Chrome OS活用によるメリット ・Chrome OSを合わせて使用することにより、運用効率化、コスト削減、セキュリティ強化が実現できると紹介がありました。 感想 ・ブラウザに業務を集約することで、利用者のデバイス準備や作業の負担軽減が期待できるため、Microsoft製品によるOSやユーザ管理（AD活用）が多いですが、今後はAD不要でGoogleアカウントとChromeブラウザを活用したGoogle製品による運用に移行する企業も増えていくのではないかと感じました。 ・いただいた資料の情報ですが、2024年5月時点の情報によると、Chrome OSはおよそ15年のリリース期間で、マルウェア／ランサムウェア被害が「ゼロ」、ウイルス攻撃の成功報告も「ゼロ」となっています。非常に高いセキュリティ実績ですごいですね。 参考） Chrome OS ChromeOS - ビジネスに適した安全なクラウド ファーストの OS chromeos.google   展示ブース 各社のブースに訪問させていただいて特に印象に残ったブースを紹介いたします。 社内業務効率化AI KDDI株式会社様 KDDI社内プロジェクトにより、営業の生産性向上を目的として開発された生成AIツールについて紹介していただきました。 社内には膨大な資料が存在し、それらから必要な情報を探すことは時間がかかったり、似たような資料を参考に新規で提案資料等の資料を作成することに時間がかかったりしており、以下の機能を持たせた生成AIツールを作成し業務を効率化したとのことでした。 （情報収集については、社内の利用者のアンケートで74％情報収集時間を削減できたとのことです。） ▼生成AIツールの機能 ・資料の検索 ・資料の要約 ・社内の過去資料を基にドラフト資料を自動生成 ・資料のレビュー 資料の検索、ドラフト版の作成から資料のレビューまでの資料作成全体の効率化ができており、過去の資料というナレッジの蓄積をAIを活用しており、利用ができたらとても便利なサービスだと感じました。 参考） AIエージェント（上記記載の生成AIツールはA-BOSSとなります） AIエージェントとは？生成AIからの進化点や導入事例、注意点など解説 ｜お役立ち情報｜中小企業・法人向け｜KDDI株式会社 ビジネスを推進する新たなAIの活用法「AIエージェント」に関する記事です。AIエージェントの仕組みと、KDDIの実践事例をもとに、業務効率化・コスト削減のポイント、セキュリティやバイアス対策までをコンパクトに解説します。 biz.kddi.com オンプレミス エイム電子株式会社様 ロック機構がついた電源ケーブルを展示しておりました。 ロック機構がついているため、電源ケーブルの抜けの防止や作業中の誤った電源ケーブルの抜線が防げるとのことです。 実際に自分で引っ張って抜けないを体験できる展示もあり、引っ張ってみても全然抜けず、確かに抜け防止になるなといった感じでした。 データセンターでは細部のケーブルまで検討が必要になるのだなと驚きました。 番外編 山口県＆萩市様 行政として山口県＆萩市が参加しており、企業誘致を進めているとのことでした。 ITの技術の展示が多いなか他とは違った観点でおもしろい試みだなと思いました。 実際に山口県＆萩市様のブースで紹介資料を見ると仕事がしやすそうな環境なので少しいいなと思ってしまいました。 観光案内をいただいたので旅行でぜひ行ってみたいですね。   おわりに 5、6年前にもInteropに行かせていただいたことがありますが、業務経験が浅くふわふわしたまま参加したため、色々な製品があるなとか、色々な会社があるなくらいの社会勉強みたいな記憶があります。 今回はトレンドがAIだからAIと何かみたいな組み合わせが多いなだったり、ブースで気になる技術について聞いてみたりと充実して回れたので自身の成長を感じることができました。

今回は、前回投稿した「OSパッチ適用を自動化させた後、結果をメールに通知させる方法」をAWS CDKで実装する方法をまとめました。   AWS Systems Manager の Patch Manager で OS パッチ適用を自動化してみた AWS Systems Manager でパッチ適用を自動化する方法をまとめてみました。 blog.usize-tech.com 2025.01.22 OSパッチ適用結果をメール通知してみた Amazon CloudWatch Logs に出力されたログから、指定した任意の文字列をトリガーに Amazon SNS 経由で適用結果をメールで通知します。 blog.usize-tech.com 2025.02.07 はじめに 前回の記事ではAWSマネジメントコンソールを使って手動でOSパッチ適用の自動化システムを構築しました。 今回は、同じシステムをAWS CDK（Cloud Development Kit）を使ってコード化し、Infrastructure as Code（IaC）として管理できるようにしていきます。   今回作成するリソース SNSトピック: メール通知用 IAMロール: SSM実行用とLambda実行用 パッチベースライン: Windows Server 2022用 メンテナンスウィンドウ: 毎月第1月曜日に実行 Lambda関数: パッチ結果解析とSNS送信 CloudWatchロググループ: パッチ実行ログ保存用 サブスクリプションフィルター: Lambda起動トリガー   AWS CDK ソースコード lib/patch-automation-stack.ts を、以下のように実装します。 最初に各コンポーネント毎に詳細を解説し、最後にソースコードをまとめて記載します。 また、CDKでは名前の自動設定やgrantメソッドなど便利な機能がありますが、実際の案件では様々なリソースに名前を設定する必要があったため名前を定義できるように実装をしています。   SNSトピックとメール通知設定   // パッチ通知用SNSトピックの作成   const patchtopic = new sns.Topic(this, 'PatchNotificationTopic', {     topicName: 'sns-patch-notification',     displayName: 'パッチ適用結果通知'     });   // SNSトピックに通知先メールアドレスを設定   patchtopic.addSubscription(     new subscriptions.EmailSubscription('your-email@example.com')　　　　　　　　//実際のメールアドレスへ変更     ); ポイント: EmailSubscription で通知先メールアドレスを設定 実際のメールアドレスに変更する必要があります   IAMロールの設定   // SSM Run Command実行用のIAMロール   const ssmRunCommandRole = new iam.Role(this, 'SSMRunCommandRole', {     assumedBy: new iam.ServicePrincipal('ssm.amazonaws.com'), roleName: 'SSMRunCommandRole',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonSSMMaintenanceWindowRole'),       iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),     ],     description: 'Role for SSM Run Command execution'     });   // Lambda関数のIAMロール作成   const lambdaPatchRole = new iam.Role(this, 'LambdaPatchRole', { roleName: 'LambdaPatchRole',     assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),     description: 'Lambda execution role for patch notification',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole')     ]   }); 　　// Lambda関数にSNSの権限を付与   new iam.Policy(this, 'LambdaPatchSnsPolicy', {     policyName: 'LambdaPatchSnsPolicy',     roles: [lambdaPatchRole],     statements: [                                                                 new iam.PolicyStatement({         effect: iam.Effect.ALLOW,         actions: ['sns:Publish'],         resources: ['*']       })     ]     }); ポイント: SSMロール : メンテナンスウィンドウでのパッチ適用実行に必要な権限 AmazonSSMMaintenanceWindowRole : メンテナンスウィンドウ専用権限 AmazonSSMManagedInstanceCore : SSM基本通信権限 Lambdaロール : CloudWatch LogsアクセスとSNS発行権限 AWSLambdaBasicExecutionRole : Lambda基本実行権限 カスタムポリシーでSNS発行権限を追加   パッチベースラインの設定 new ssm.CfnPatchBaseline(this, 'WindowsPatchBaseline', { operatingSystem: 'WINDOWS', name: 'winsv-baseline', approvalRules: {   patchRules: [{     approveAfterDays: 0,                    // リリースから0日後に承認     complianceLevel: 'CRITICAL',            // コンプライアンスレベル：重要     enableNonSecurity: false,               // セキュリティパッチのみを対象     patchFilterGroup: {       patchFilters: [         {           key: 'PRODUCT',           values: ['WindowsServer2022']　　　 // WindowsSrver2022で設定         },         {           key: 'CLASSIFICATION', // Windowsの更新プログラム分類           values: ['CriticalUpdates', 'SecurityUpdates'] // 重要な更新プログラム,セキュリティ更新プログラム         },         {           key: 'MSRC_SEVERITY', // Microsoftが定める重要度           values: ['Critical','Important'] // 致命的な問題を修正,重要な問題を修正         }       ]     }   }] }, patchGroups: ['winsv-patch-group'] // 対象パッチグループ }); ポイント: operatingSystem : 対象OS（WINDOWS、AMAZON_LINUX、UBUNTU等） approveAfterDays: 0 : リリース直後からパッチ適用可能（本番では7-30日を推奨） enableNonSecurity: false : セキュリティパッチのみに限定 フィルター条件 : PRODUCT : 対象Windows製品 CLASSIFICATION : パッチの分類 MSRC_SEVERITY : Microsoftが定める重要度   メンテナンスウィンドウの設定 const patchMaintenanceWindow = new ssm.CfnMaintenanceWindow(this, 'PatchMaintenanceWindow', { name: 'monthly-patch-maintenance-window', schedule: 'cron(0 16 ? * MON#1 *)', duration: 2, cutoff: 0, allowUnassociatedTargets: false, scheduleTimezone: 'Asia/Tokyo' }); スケジュール設定は現在以下のように設定していますので、要件に応じて修正してください。 cron(0 16 ? * MON#1 *) : JST時間で第1月曜日16:00 duration: 2 : 2時間のメンテナンス枠 scheduleTimezone: 'Asia/Tokyo' : 日本時間で管理   パッチ適用対象の設定 const patchTarget = new ssm.CfnMaintenanceWindowTarget(this, 'PatchTarget', { windowId: patchMaintenanceWindow.ref, targets: [{   key: 'tag:PatchGroup',   values: ['winsv-patch-group'] }], resourceType: 'INSTANCE', ownerInformation: 'Patch管理対象インスタンス' }); ポイント: targets: でパッチ適用対象インスタンスを設定 事前にEC2インスタンスでタグの設定が必要 今回の場合必要なタグ設定 -　 キー: `PatchGroup`　 – 値: `winsv-patch-group`   RunCommandタスクの作成 // パッチ適用タスクの作成 const patchExecutionTask = new ssm.CfnMaintenanceWindowTask(this, 'PatchExecutionTask', { // 基本設定 windowId: patchMaintenanceWindow.ref,                          // メンテナンスウィンドウの参照 taskArn: 'AWS-RunPatchBaseline',                               // 実行するSSMドキュメント taskType: 'RUN_COMMAND',                                       // タスクタイプ：RunCommand name: 'SecurityPatchInstallation',                             // タスク名 description: 'セキュリティパッチの自動インストールと再起動',      // タスクの説明 priority: 1,                                                   // タスクの優先度（1が最高） maxConcurrency: '1',                                           // 同時実行数：1台ずつ順次実行 maxErrors: '0',                                                // エラー許容数：0（1台でもエラーなら停止） serviceRoleArn: ssmRunCommandRole.roleArn,                   　// SSM実行用IAMロール targets: [{   key: 'WindowTargetIds',                                      // ターゲット指定方法   values: [patchTarget.ref]                                    // 事前に定義したターゲットを参照 }], taskInvocationParameters: {   maintenanceWindowRunCommandParameters: {     documentVersion: '$LATEST',                                // 最新バージョンのドキュメントを使用     parameters: {       Operation: ['Install'],                                  // 操作：パッチのインストール実行       RebootOption: ['RebootIfNeeded'],                       // 必要に応じて自動再起動       SnapshotId: ['{{WINDOW_EXECUTION_ID}}']                 // 実行IDをスナップショットIDとして記録     },     timeoutSeconds: 600,                                     // タイムアウト（必要に応じて修正）     cloudWatchOutputConfig: {       cloudWatchLogGroupName: 'aws-ssm-patch-execution-logs', // CloudWatch Logsグループ名       cloudWatchOutputEnabled: true                           // CloudWatch Logs出力を有効化     }   } } }); ポイント: taskArn : ‘AWS-RunPatchBaseline’でパッチ適用を実行 priority : 1が最高優先度 maxConcurrency : 同時実行数制御（’1’=順次、’50%’=半数同時） maxErrors : エラー許容数（’0’=1台でもエラーなら停止） 重要パラメータ : Operation: ['Install'] : パッチを実際にインストール RebootOption: ['RebootIfNeeded'] : 必要時のみ再起動 SnapshotId : 実行履歴の追跡用   Lambda関数作成   // Lambda関数作成   const patchNotificationLambda = new lambda.Function(this, 'PatchNotificationFunction', {     functionName: 'lmd-patch-send-sns',                      // 関数名     runtime: lambda.Runtime.PYTHON_3_13,                     // 実行環境：Python 3.13     handler: 'index.lambda_handler',                         // エントリーポイント     code: lambda.Code.fromAsset(                             // ソースコードの場所       path.join(__dirname, 'lambda')     ),     role: lambdaPatchRole,                                   // Lambda実行時IAMロール     environment: {                                           // 環境変数       SNS_TOPIC_ARN: patchtopic.topicArn,                    // SNSトピックのARN       ALARM_SUBJECT: 'パッチ適用結果通知'                     // メールの件名     },     timeout: cdk.Duration.seconds(600),                      // 実行タイムアウト     memorySize: 128,                                         // メモリ割り当て（MB）   }); ポイント: runtime : Python 3.13 code :  lib/lambda ディレクトリからコード読み込み environment : SNSトピックARNとメール件名を環境変数で設定 timeout : 600秒 memorySize : 128MB   関数作成 import logging import json import base64 import gzip import boto3 import os logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context):   # CloudWatchLogsからのデータはbase64エンコードされているのでデコード   decoded_data = base64.b64decode(event['awslogs']['data'])   # バイナリに圧縮されているため展開   json_data = json.loads(gzip.decompress(decoded_data))   logger.info("EVENT: " + json.dumps(json_data))   # ログデータ取得   log = json_data['logEvents'][0]['message']   instanceid_position = log.find('PatchGroup')   instanceidtmp = log[:instanceid_position]   instanceid = instanceidtmp.replace('Patch Summary for ','')   print(instanceid)   result_position = log.find('Results')   result = log[result_position:]   print(result)   patchGroup_start = log.find('PatchGroup')   patchGroup_end = log.find('BaselineId')   patchGrouptmp = log[patchGroup_start:patchGroup_end]   patchGroup = patchGrouptmp.replace('PatchGroup          : ','')   print(patchGroup)     messagetmp = """ パッチ適用結果を通知します。 対象インスタンス・適用結果は下記となります。 〇対象インスタンス{0} 〇パッチグループ {1} 〇適用結果 {2}   """   message = messagetmp.format(instanceid,patchGroup,result)   print(message)   try:       sns = boto3.client('sns')       #SNS Publish       publishResponse = sns.publish(       TopicArn = os.environ['SNS_TOPIC_ARN'],       Message = message,       Subject = os.environ['ALARM_SUBJECT']       )   except Exception as e:         print(e) ポイント: lib/lambda/index.py にPythonコードを配置します   ロググループ設定   // パッチログ用のCloudWatchロググループ作成   const patchloggroup = new logs.LogGroup(this, 'PatchLogGroup', {       logGroupName: 'aws-ssm-patch-execution-logs', // パッチ適用ロググループ       retention: logs.RetentionDays.ONE_YEAR,       // 保持期間: 1年間       removalPolicy: cdk.RemovalPolicy.RETAIN       // スタック削除時に削除されない         });   new logs.SubscriptionFilter(this, 'PatchSummarySubscription', {     // サブスクリプションフィルターの設定（Lambda関数の起動トリガー）       logGroup: patchloggroup,                                         // 監視対象のロググループ       destination: new destinations.LambdaDestination(patchNotificationLambda),  // 送信先       filterPattern: logs.FilterPattern.literal('Patch Summary'),       // フィルター条件       filterName: 'PatchNotification'                                   // フィルター名     }); } ポイント: logGroupName: はRunCommandタスクの作成で指定したロググループ名と合わせる 保管期間は要件に合わせて修正する 今回実装したスタックファイルまとめ import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import * as lambda from 'aws-cdk-lib/aws-lambda'; import * as logs from 'aws-cdk-lib/aws-logs'; import * as iam from 'aws-cdk-lib/aws-iam'; import * as sns from 'aws-cdk-lib/aws-sns'; import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions'; import * as path from 'path'; import * as destinations from 'aws-cdk-lib/aws-logs-destinations'; export class PatchAutomationStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) {     super(scope, id, props);   // パッチ通知用SNSトピックの作成   const patchtopic = new sns.Topic(this, 'PatchNotificationTopic', {     topicName: 'sns-patch-notification',     displayName: 'パッチ適用結果通知'     });   // SNSトピックに通知先メールアドレスを設定   patchtopic.addSubscription(     new subscriptions.EmailSubscription('your-email@example.com') // ここを実際のメールアドレスに変更     );   // SSM Run Command実行用のIAMロール   const ssmRunCommandRole = new iam.Role(this, 'SSMRunCommandRole', { roleName: 'SSMRunCommandRole',     assumedBy: new iam.ServicePrincipal('ssm.amazonaws.com'),     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonSSMMaintenanceWindowRole'),       iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),     ],     description: 'Role for SSM Run Command execution'     });   // Lambda関数のIAMロール作成   const lambdaPatchRole = new iam.Role(this, 'LambdaPatchRole', { roleName: 'LambdaPatchRole',     assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),     description: 'Lambda execution role for patch notification',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole')     ]     });   // Lambda関数にSNSの権限を付与   new iam.Policy(this, 'LambdaPatchSnsPolicy', {     policyName: 'LambdaPatchSnsPolicy',     roles: [lambdaPatchRole],     statements: [       new iam.PolicyStatement({         effect: iam.Effect.ALLOW,         actions: ['sns:Publish'],         resources: ['*']       })     ]     });   // パッチベースラインの作成   new ssm.CfnPatchBaseline(this, 'WindowsPatchBaseline', {     operatingSystem: 'WINDOWS',     name: 'winsv-baseline',     approvalRules: {       patchRules: [{         approveAfterDays: 0,                    // リリースから0日後に承認         complianceLevel: 'CRITICAL',            // コンプライアンスレベル：重要         enableNonSecurity: false,               // セキュリティパッチのみを対象         patchFilterGroup: {           patchFilters: [             {               key: 'PRODUCT',               values: ['WindowsServer2022']     // WindowsServer2022で設定             },             {               key: 'CLASSIFICATION',               values: ['CriticalUpdates', 'SecurityUpdates']             },             {               key: 'MSRC_SEVERITY',               values: ['Critical', 'Important']             }           ]         }       }]     },     patchGroups: ['winsv-patch-group']     });   // メンテナンスウィンドウの作成   const patchMaintenanceWindow = new ssm.CfnMaintenanceWindow(this, 'PatchMaintenanceWindow', {     name: 'monthly-patch-maintenance-window',     schedule: 'cron(0 16 ? * MON#1 *)',         // 毎月第1月曜日 JST 16:00     duration: 2,                                // 実行可能時間：2時間     cutoff: 0,                                  // 新規タスク開始の締切時間     allowUnassociatedTargets: false,            // 関連付けされたターゲットのみ実行     scheduleTimezone: 'Asia/Tokyo'              // スケジュールのタイムゾーン     });   // パッチ適用対象の設定   const patchTarget = new ssm.CfnMaintenanceWindowTarget(this, 'PatchTarget', {     windowId: patchMaintenanceWindow.ref,       // メンテナンスウィンドウの参照     targets: [{       key: 'tag:PatchGroup',                    // タグによる対象選択       values: ['winsv-patch-group']             // 対象とするタグ値     }],     resourceType: 'INSTANCE',                   // 対象リソース種別：EC2インスタンス     ownerInformation: 'Patch管理対象インスタンス' // 管理用メモ     });   // パッチ適用タスクの作成   const patchExecutionTask = new ssm.CfnMaintenanceWindowTask(this, 'PatchExecutionTask', {     // 基本設定     windowId: patchMaintenanceWindow.ref,                          // メンテナンスウィンドウの参照     taskArn: 'AWS-RunPatchBaseline',                               // 実行するSSMドキュメント     taskType: 'RUN_COMMAND',                                       // タスクタイプ：RunCommand     name: 'SecurityPatchInstallation',                             // タスク名     description: 'セキュリティパッチの自動インストールと再起動',       // タスクの説明     priority: 1,                                                   // タスクの優先度（1が最高）     maxConcurrency: '1',                                           // 同時実行数：1台ずつ順次実行     maxErrors: '0',                                                // エラー許容数：0（1台でもエラーなら停止）     serviceRoleArn: ssmRunCommandRole.roleArn,               　　　 // SSM実行用IAMロール     targets: [{       key: 'WindowTargetIds',                                      // ターゲット指定方法       values: [patchTarget.ref]                                    // 事前に定義したターゲットを参照     }],     taskInvocationParameters: {       maintenanceWindowRunCommandParameters: {         documentVersion: '$LATEST',                                // 最新バージョンのドキュメントを使用         parameters: {           Operation: ['Install'],                                  // 操作：パッチのインストール実行           RebootOption: ['RebootIfNeeded'],                       // 必要に応じて自動再起動           SnapshotId: ['{{WINDOW_EXECUTION_ID}}']                 // 実行IDをスナップショットIDとして記録         },         timeoutSeconds: 600,                                       // タイムアウト（必要に応じて修正）         cloudWatchOutputConfig: {           cloudWatchLogGroupName: 'aws-ssm-patch-execution-logs', // CloudWatch Logsグループ名           cloudWatchOutputEnabled: true                           // CloudWatch Logs出力を有効化         }       }     }     });   // Lambda関数作成   const patchNotificationLambda = new lambda.Function(this, 'PatchNotificationFunction', {     functionName: 'lmd-patch-send-sns',                       // 関数名     runtime: lambda.Runtime.PYTHON_3_13,                      // 実行環境：Python 3.13     handler: 'index.lambda_handler',                         // エントリーポイント     code: lambda.Code.fromAsset(                             // ソースコードの場所       path.join(__dirname, 'lambda')     ),     role: lambdaPatchRole,                                   // Lambda実行時IAMロール     environment: {                                           // 環境変数       SNS_TOPIC_ARN: patchtopic.topicArn,                     // SNSトピックのARN       ALARM_SUBJECT: 'パッチ適用結果通知'                       // メールの件名     },     timeout: cdk.Duration.seconds(600),                       // 実行タイムアウト     memorySize: 128,                                         // メモリ割り当て（MB）     description: 'パッチ適用結果を解析してSNS通知を送信する関数'  // 関数の説明   });   // パッチログ用のCloudWatchロググループ作成   const patchloggroup = new logs.LogGroup(this, 'PatchLogGroup', {     logGroupName: 'aws-ssm-patch-execution-logs',           // パッチ適用ロググループ     retention: logs.RetentionDays.ONE_YEAR,                 // 保持期間: 1年間     removalPolicy: cdk.RemovalPolicy.RETAIIN                 // スタック削除時に削除されない     });   // サブスクリプションフィルターの設定（Lambda関数の起動トリガー）   new logs.SubscriptionFilter(this, 'PatchSummarySubscription', {     logGroup: patchloggroup,                                         // 監視対象のロググループ     destination: new destinations.LambdaDestination(patchNotificationLambda),   // 送信先     filterPattern: logs.FilterPattern.literal('Patch Summary'),       // フィルター条件     filterName: 'PatchNotification'                                   // フィルター名   }); } }   まとめ 今回は、パッチ自動適用からメール通知までをAWS CDKでモジュール化してみました。 皆さんのお役に立てば幸いです。

こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.4がリリースされました。今回はicmppingretryについて検証したいと思います。 7.4の新機能につきましては、公式HPに記載がございます。 What's new in Zabbix 7.4 Create new resource discovery workflows, visualize your data in new ways, enjoy the improved user experience and much mo... www.zabbix.com Zabbix7.4はポイントリリースのため、サポート期間が短くなっています。 本番利用する場合は8.0LTSがリリースされるまでお待ちいただく事をお勧めします。 icmppingretryとは 公式HPでは以下の記載があります。 英語：A new icmppingretry simple check has been added to monitor host responses to ICMP ping with the ability to modify retries 翻訳：ICMP pingに対するホストの応答を監視し、再試行回数を変更するための新しいicmppingretryシンプルチェックが追加されました。 Ping監視で1回失敗した場合、間隔を狭くしてリトライする事ができるようです。 他の有償製品ではリトライをすることができるようで、問い合わせを多く頂いておりました機能になります。   アイテム作成 icmppingretryはアイテムキーのため、通常のPing監視で利用するicmppingとは別アイテムにする必要があります。 今までのicmppingキーにはない「retries」「backoff」が新しく設定できるようになっております。 逆に「interval」「packets」がなくなっております。細かいPingのオプションは指定できないようですね。 「reties」が 再試行回数 となっており、「backoff」で 再試行間隔の係数 を指定できるようです。 公式マニュアル – icmppingretry icmppingretry[<target>,<retries>,<backoff>,<size>,<timeout>,<options>] The host accessibility by ICMP ping with retries. Return value:  0  – ICMP ping fails;  1  – ICMP ping successful. Parameters: target  – the host IP or DNS name; retries  – the number of times an attempt at pinging a target will be made, not including the first try (0 or greater; default 1); backoff  – the number by which the wait time is multiplied on each successive request (1.0-5.0 range; default 1.0); size  – the packet size in bytes; timeout  – the timeout in milliseconds; options  – used for allowing redirect: if empty (default value), redirected responses are treated as target host down; if set to  allow_redirect , redirected responses are treated as target host up. 今回は検証用にicmppingretryとicmppingのアイテムを作成して比較しようと思います。 名前 Ping監視（icmpping） Ping監視（icmppingretry） タイプ シンプルチェック シンプルチェック アイテムキー icmpping[,3,2000,64,3000] icmppingretry[,3,3,256,500] 監視間隔 60s 60s   icmpping[,3,2000,64,3000]の動作について まずは、以前からあるicmmpingキーについて動作を確認していきます。 正常時 1回の監視で2秒間隔で3回パケットを送信します。1分間隔で繰り返します。 20:54:23.056236 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 0, length 72 20:54:25.056876 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 1, length 72 20:54:27.058276 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 2, length 72 20:55:23.068729 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 0, length 72 20:55:25.070759 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 1, length 72 20:55:27.070773 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 2, length 72 異常時 監視対象（192.168.1.1）をダウンさせてみます。 Zabbixから送信するパケットは正常時と変わらないことを確認します。 21:00:23.131611 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 0, length 72 21:00:25.133447 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 1, length 72 21:00:27.131777 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 2, length 72 21:01:23.142971 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 0, length 72 21:01:25.143041 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 1, length 72 21:01:27.143408 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 2, length 72 icmppingretry[,3,3,256,500]の動作について 次に新機能のicmppingretryについて確認いたします。 オプションは再試行回数3回、再試行間隔の係数は３、タイムアウト0.5秒になります。 正常時 1回の監視で1回だけICMPパケットを送信します。1分間隔で繰り返します。 icmppingキーでは細かく、回数や間隔を指定できていましたが、正常時は1回になるようです。 21:04:23.175696 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3166, seq 0, length 72 21:05:23.185637 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3174, seq 0, length 72 異常時 監視対象をダウンさせてみると以下のパケットになります。 20:30:40.044485 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 0, length 264 20:30:40.545097 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 1, length 264 20:30:42.046686 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 2, length 264 20:30:46.547698 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 3, length 264 再試行回数：３回 通常監視が「20:30:40.044485」に行われ、その後３回、「20:30:40.545097」「20:30:42.046686」「20:30:46.547698」と再試行を行っています。再試行の際は、idが同じ「2428」でseqが連番となっています。   再試行間隔の係数：３ 再試行の間隔は以下の通りになります。 再試行1回目：0.5秒（20:30:40.0 – 20:30:40.5） 再試行2回目：1.5秒（20:30:40.5 – 20:30:42.0） 再試行3回目：4.5秒（20:30:42.0 – 20:30:46.5） 再試行の回数が増えるごとに、間隔が長くなっていることがわかるかと思います。 再試行1回目の0.5秒は、icmppingretryキーの引数で指定したタイムアウトの0.5秒になります。 再試行2回目の1.5秒は、1回目の間隔(0.5)×再試行間隔の係数(3)の1.5秒になります。 再試行3回目の4.5秒は、2回目の間隔(1.5)×再試行間隔の係数(3)の4.5秒になります。 まとめ icmppingretryを使用することで、Ping疎通がNGの場合のみ、再試行することがZabbixでも実現できました。 ZabbixのPing監視の幅が広がったかと思います。　 Zabbix is great! ※検証結果が間違っておりましたら、お知らせください SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com  

こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、日立製作所から提供されているジョブ管理製品である JP1/AJS3 を簡単に冗長化するための ARK の導入事例をご紹介していきます。 おさらい LifeKeeper の ARK について、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI 上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 JP1/AJS3 の ARK としては、下記の通り大きく2つの種類があります。 ① Generic ARK for JP1/AJS3 Manager 「JP1/Base」と「JP1/Automatic Job Management System 3」(略称：JP1/AJS3)の「Manager」を，LifeKeeper の保護対象リソースとして登録し，保護する機能を提供します。 ② Generic ARK for JP1/AJS3 Agent 「JP1/Base」と「JP1/Automatic Job Management System 3」(略称：JP1/AJS3)の「Agent」を，LifeKeeper の保護対象リソースとして登録し，保護する機能を提供します。 JP1/AJS3 ARK は、汎用アプリケーション(Generic Application)リソースとして導入されます。 おさらいでお伝えした通り、「JP1/Base」と「JP1/Automatic Job Management System 3」のそれぞれを操作するため、起動・停止・監視・再起動を行うためのスクリプトが準備されており、リソース作成時にこれらのスクリプトを設定していきます。 この4つのスクリプトのうち、起動と停止は必須で、監視と再起動は任意となり、JP1製品の監視や再起動を実施する要件がなければ、対象のスクリプトを設定する必要もありません。 監視と再起動を導入しなければ、LifeKeeper として JP1/AJS3 の障害を検知することはなく、フェイルオーバーの対象にもなりません。また、監視は行うが、再起動は行わないことも出来ます。ただ、監視は行わず、再起動のみ行うことは出来ません。あくまでも監視で異常と検知された場合のみ、再起動が有効になります。 JP1/ASJ3 ARKを導入するための条件 JP1 が使用する共有ディスクリソースと，JP1 の論理ホスト名に紐づく仮想 IP リソースは、別で作成しておく必要があります。また、JP1 リソース作成後、共有ディスクリソースと仮想 IP リソースに対する依存関係を手動で設定する必要があります。 JP1/ASJ3 ARK の構築例 それでは、実際に JP1/AJS3 ARK の構築についてお話していきたいと思います。 スクリプトの修正 まずは、「JP1/Base」と「JP1/Automatic Job Management System 3」を操作するため、利用する全てのスクリプトを修正する必要があります。 スクリプトのパラメータ変更 次の変更可能なパラメータのうち、必要なパラメータを修正します。 ※下記パラメータ以外を変更してしまうとサポートが受けられなくなりますので注意してください。 ＜Windows版＞ 内容 パラメータ名 設定条件 リソースタグ名 APP 任意 論理ホスト名 VHOSTNAME 必須 JP1環境変数 JP1PATH 任意 タイムアウト値（処理待ち時間） DEFAULT_TIMEOUT 任意 タイムアウト値（後処理の待ち時間） HANDLE_STOP_TIMEOUT 任意 処理モード（※１） PROCESS_MODE 任意 ※１：停止スクリプトのみ提供されるパラメーター ＜Linux版＞ 内容 パラメータ名 設定条件 リソースタグ名 APP 任意 論理ホスト名 VHOSTNAME 必須 タイムアウト値（処理待ち時間） DEFAULT_TIMEOUT 任意 タイムアウト値（後処理の待ち時間） HANDLE_STOP_TIMEOUT 任意 待機時間（※２） APP_FORCE_STOP_WAIT_TIME 任意 ※２：監視スクリプトは設定不要なパラメーター (1)リソースタグ名(APP)の変更 リソースタグ名は保護対象リソースを一意に識別するための名称です。デフォルトで設定がされていますが、案件ごとに命名規則がありますので、案件にあったリソースタグ名に変更する必要があります。 (2)論理ホスト名(VHOSTNAME)の変更 論理ホスト名は JP1/AJS3 ARK で唯一の必須となるパラメータです。クラスタ環境（論理ホスト上）でJP1製品のコマンドを実行するため、論理ホスト名が必要になります。JP1/AJS3 ARK の各スクリプトでもJP1製品のコマンドを実行するため、必要不可欠なパラメータとなります。 (3)JP1環境変数(JP1PATH)の変更　※Windows版のみ JP1環境変数は JP1 製品のコマンドを実行するためのパス名です。各スクリプトにはJP1製品のデフォルトのインストールパス名があらかじめ記載されており、明示的にインストールパスを変更してJP1製品をインストールする場合、このJP1環境変数を変更する必要があります。 (4)タイムアウト値(DEFAULT_TIMEOUT,HANDLE_STOP_TIMEOUT)の変更 タイムアウト値は各スクリプトに設定するタイマー監視用の値です。各スクリプトで実行した JP1 製品のコマンドが無応答となった場合、設定したタイムアウト値によってタイマー監視を行い、各スクリプトを終了させます。 基本的には変更することはありませんが、処理時間が遅いだけで問題もなく各スクリプトがタイムアウトとなってしまう場合、環境に合わせ変更する必要があります。 (5)処理モード(PROCESS_MODE)の設定　※Windows版の停止スクリプトのみ 処理モードはJP1製品の停止処理が失敗した場合における、後続処理の続行可否を判断するためのパラメータです。 処理モードが「0」：JP1製品の停止コマンドが失敗した場合、異常終了と判断し、フェイルオーバーが中断されます。 処理モードが「1」：JP1製品の停止コマンドが失敗した場合、正常終了と判断し、フェイルオーバーが継続されます。 ※デフォルト値は「1」になります。 (6)待機時間(APP_FORCE_STOP_WAIT_TIME)の変更　※Linux版の監視スクリプト以外 待機時間は各スクリプトで実行される JP1 製品の2重起動防止を目的とした強制停止コマンドの終了を待機する時間の値です。 JP1製品の強制停止コマンドの一部処理がバックグラウンドで実施され、待機時間を経過しても終了せず、その後の JP1 製品の開始に失敗することがある場合、デフォルトの5秒から変更する必要があります。 JP1/ASJ3 関連リソースの作成 前述の通り、JP1/AJS3 ARK では「JP1/Base」と「JP1/Automatic Job Management System 3」（Manager または Agent）のリソースを作成することが可能です。 この2つのリソースを LifeKeeper の GUI によって作成する流れを環境毎に例として紹介します。 ＜Windows版＞ 処理内容 JP1/Base JP1/Automatic Job Management System 3 リソース作成前のツリー構造 冗長化対象ノードの選択 保護アプリケーションの選択（汎用アプリケーション） Restore（起動）スクリプトの入力 Remove（停止）スクリプトの入力 QuickCheck（監視）スクリプトの入力 DeepCheck（詳細な監視）スクリプトの入力 ※対象無し LocalRecovery（再起動）スクリプトの入力 アプリケーション情報の入力 ※入力無し LocalRecoveryの有無の選択 ※デフォルト：有効 リソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードのリソース作成準備の確認結果 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成結果 リソース作成後のツリー構造 ＜Linux版＞ 処理内容 JP1/Base JP1/Automatic Job Management System 3 リソース作成前のツリー構造 保護アプリケーションの選択（Generic Application） 稼働系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの選択 Restore（起動）スクリプトの入力 Remove（停止）スクリプトの入力 QuickCheck（監視）スクリプトの入力 LocalRecovery（再起動）スクリプトの入力 稼働系ノードのアプリケーション情報の入力 ※入力無し リソース作成時の起動有無の選択 稼働系ノードのリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの優先順位の設定 ※デフォルト：1 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成準備の確認結果 待機系ノードのリソースタグ名の入力 待機系ノードのアプリケーション情報の入力 ※入力無し 待機系ノードのリソース作成結果 リソース作成後のツリー構造 これで、LifeKeeper による JP1/AJS3 製品 のリソースが完成です。 依存関係の作成 「JP1/Base」と「JP1/Automatic Job Management System 3」（Manager または Agent）のリソースを作成した後、全リソースの起動（停止）する順序を定義するため、リソース間の依存関係（リソースツリーの下から起動され、上から停止される）を作成する必要があります。 例として、別で作成していた共有ディスクリソースと，仮想 IP リソースを始めに起動させるようリソースツリーの下部に配置させ、その後に JP1/Base、JP1/AJS3 の順番で起動させるように依存関係を作成します。 処理内容 Windows版 Linux版 依存関係作成前のツリー構造 JP1/Baseリソースの依存関係作成後 JP1/AJS3リソースの依存関係作成後 これで、JP1/AJS3 製品に関連する LifeKeeper によるリソース構成ツリーの完成です。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、JP1/AJS3 製品のリソース作成について紹介してみました。 JP1/AJS3 ARK を購入することで、正式なサポートを受けられるほか、LifeKeeper として JP1/AJS3 を操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されており、必要最低限の修正だけで簡単にリソースとして導入が可能となっています。 LifeKeeper では JP1/AJS3 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 最後に JP1/AJS3 ARK を導入するための手順を纏めます。 ・JP1/Base と JP1/AJS3 で利用されるスクリプト内の変更可能なパラメータを修正する ・LifeKeeper GUI を用いて、JP1/Base と JP1/AJS3 のリソースを作成する ・共有ディスクリソースと仮想 IP リソース含め、リソースの起動順序を定義するため依存関係を作成する   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで  

こんにちは！ SCSK株式会社　小鴨です。 海外にあこがれはあるけど英語は全くできないことが悩みです そんな自分ですが、今日も Knowledge 25 　 のご紹介をさせていただきます！！ 本日からはいよいよイベント本番の内容にがっつり踏み込んでいきます。 前回の記事は準備・到着編になります。 まだ読んでいない方は以下リンクからどうぞ！ 【ServiceNow】Knowledge25への参加記録！！その１　～準備・到着～ – TechHarmony 【ServiceNow】Knowledge25への参加記録！！その２　～イベント開始～ – TechHarmony   Knowledgeが…始まる Knowledge25の構成要素 さあいよいよ本番が開幕！の前に そもそもKnowledgeがどのような構成で進められるのかご紹介です。 Knowledgeとは以下の3要素で構成されます。 基調講演 ー参加者全員向けに大会場で行われる公演 ServiceNowの重役が、新技術やこれからの展望について熱く語る セッション ー事前予約制の公演 興味のあるタイトルを選び、自分だけの時間割を組んで参加する エキスポ会場 ー各企業がブースを出展したり、技術者交流の会場が用意されていたり イベント期間中常に実施されている   基本的にイベントが行われる3日間は 朝に全体向けの基調講演が行われ、残りの時間は予約したセッションに参加するといったイメージですね。 その３では基調講演で語られたServiceNowのこれからについてご紹介します。 エキスポ会場の様子や、イベントの雰囲気などはその4以降でお話しする予定です。   基調講演 公演というかもはや演劇 基調講演は大会場で行われるのですが 庶民である私はなんとなく体育館チックな場所でやるのかなと思ってました。 きっと椅子が小綺麗に並べられていて 校長先生みたいな人が演説をするんだろうな～ …と思ってのもつかの間 なんか様子がおかしいぞというのが第一印象。 突然現れたライブ会場みたいな大広間の雰囲気にいきなり圧倒されました！ ライトがバリバリたかれていたり なぜかDJがいたり 公演以外の部分で驚かされっぱなしな私でしたが 公演そのものも一風変わっていて非常に興味深いものでした。 というのも、登壇者が次々入れ替わり 各人が自分のパートを面白おかしく、ハイテンションで語るという形式であり 切り替わりのタイミングでは登壇者が次の登壇者を「Hey, come on John!!」みたいに呼びつけるという まるで一連の演劇を見ているようでした。 CEOが直々に登壇したり 話題が変わると次の登壇者が呼び出されたり なぜか超有名なコメディアンも現れてServiceNowについてディスカッションを始めたり 日本の公演と全然違うなあ。。。 とはっきり感じました。 ServiceNowとAI さて、雰囲気紹介もほどほどに いよいよ基調講演でどのようなことが語られたのか、紹介をさせていただきます。 まず今回のイベントで掲げられていたテーマが 「Where AI gets to the work」 というもので 現在、ServiceNow上でAIがどのような使われ方をしているのか これからどのような使い方ができるようになるのか こうした内容が今回のイベントのポイントになるということでした。 実際、基調講演ではAIの話で持ちきりで 特に力を入れて語っていたポイントは二点 「 2025 年現在の AI の立ち位置」 「なぜ ServiceNow で AI を使うのか」 基調講演では常に、「AI導入を失敗する企業の特徴」と「ServiceNowなら失敗しない理由」の説明に 力が入っていた印象です AI Platformの3要素 公演の中で語られた内容で特に印象深かったのは AIを導入している企業は数多くあるが、6割以上の企業がそれを持て余しており 全く有効活用できていないという話でした。 それはなぜかというと、AIを取り巻く要素を適切に管理できていないからだ、というのが ServiceNowの語る理論でした。 そもそもAIを活用するための3大要素というものがあり それが以下の3つであり、これらを同じプラットフォーム上で管理するのが 理想的な状態とのことです。 AI Data Workflows 多くの企業はAIはこっちのシステムで管理しつつ、ワークフローは別のシステムに任せている といったような体系をとっており、システム間連携のラグ等が影響し 分析やAIによるデータ利用がワンテンポ遅くなったりと、いまいち利便性の低いサービスとなってしまっているようです。 ServiceNowではこの3要素を高い水準で一括管理することが可能であり AI活用を絶対に失敗させないという力強いコメントと共に公演が行われていました。 あとがき 次回は実際に3要素に対し、ServiceNowがどのような取り組みを行っているか 特に機能エンハンス関連の部分に焦点をあててご紹介できればと思います。 一部キーワードを出すと ● Control Tower ●data.worldの買収 ●CRMの改良 といったところになる予定です。 その4になってようやく具体的な技術に入りますが 今後もゆったりとお付き合いいただければと思います。

こんにちは。SCSK 武田です。 先日、幕張メッセにて開催されたInterop Tokyo 2025に参加してきました。 主に生成AIに関するセッションや展示ブースを回ってきたので印象に残った内容をご紹介します。 印象に残った講演 文系人材のためのAIフル活用仕事術 スピーカーは（一財）実用英語推進機構　安河内氏 。 ChatGPTの音声機能を使って英会話授業をしているそうです。 安河内氏はAIからのアウトプットの質を高めるには工夫が必要とのことで プロンプトを書く上での鉄則 として以下5点を挙げていました。 ①シンプルで明確に書け 長い指示は上手く通らないため、短く明確な言葉を使う。 タスクが複雑な場合は、小さなステップや要素に分ける。 例）Aをやってください　→　Bをやってください　→　Cをやってください ②必要なコンテキストを提供せよ 関連する背景情報（誰が何のために）を提供する。 例）「あなたは英語教師です。日本の小学校高学年向けに問題を作成してください。」 フォーマットとスタイルを指定する。 例）「ワークシートで」「200文字以内で」 ③AIのクセを理解せよ 曖昧な指示には曖昧な結果しか出さないため、指示は具体的に明示する。 一度で完璧に出力するのは難しいため、最初の結果が期待通りでなくても内容を調整して再試行する。 ④便利な表現を使い倒せ イラスト作成の場合 例）「アスペクト比を16:9で」「アニメ風にしてください」 問題作成の場合 例）「正解は1つにしてください」（この指定をしないと答えが2つ以上存在する問題を作ってきたりする） 文書作成の場合 例）「フォーマルな文体で」「友達に話しかけるように」 ⑤ルーティンワークを自動化せよ ルーティン業務を洗い出す。 プロンプトを作成・保存し、定型作業を自動化する。 出力結果を確認し、プロンプトの改善を繰り返す。 ※同じ単純作業を3回やったら敗北！ ハルシネーション（AIが事実に基づかない回答をもっともらしく生成する現象）に注意！ 出力された情報が正しいかどうかファクトチェック（複数の信頼できるソースで確認）を行うようにしましょう。   AIで変わるサイバー攻撃からネットワークとアプリを守るために今検討すべきこと スピーカーはA10ネットワークス（株）　高木氏。   ビジネスで生成AIを利用する場合のリスク AIに情報を提供することで、意図せず個人情報や企業機密が漏洩し再利用される。 また、ユーザとAIのやり取りを誰も把握していないことが脅威となるため、AIを見張る存在が必要とのこと。   AIを悪用する新たな脅威 ボットの生成スピードが上がり、ボットによるDDoS攻撃が増えると明言。 現状、通信、ホスティングサービスに対する攻撃が多く、他にも社会インフラ、ブロックチェーン、教育機関（大学等）等も標的となっているが、攻撃にかかるコストが下がることで、今まで対象外だった業種も攻撃対象になる可能性があるという。 また、AIを悪用したDDoS攻撃として適応型攻撃なるものがあり、防御対策に適応して方法を変えて攻撃してくるらしい。   どのような対策を講じるべきか 機密情報漏洩を防ぐツールを導入する →AIにプロンプトを渡す前のチェックとAIからの出力チェックをしたり、生成AIとのやり取りをログに記録する。 DDoS攻撃の防御対策をAIに支援させる →攻撃者の行動を継続的に追跡・分析することで想定外の攻撃を検知したり自動防御する。   生成AIの比較 とある展示ブースにて、複数の有償版生成AIを利用されている方がいらっしゃったので各AIの特徴を伺ってきました。 項目 ChatGPT Claude Gemini 得意なこと 自然な対話、プログラミング 要点をまとめる 画像や音声など複数の形式を理解し情報提供する（マルチモーダル） 弱点 自信満々に誤情報を話すことがある（ハルシネーション） 応答が不安定なことがあり「病弱」な印象 日本語・ロシア語・韓国語の区別が苦手 画像生成 可能 不可 可能（精度はやや劣る） おすすめの活用方法 ・雑談やメンタルケアのための話し相手になってもらう ・プログラムの生成やデバッグ ・契約書や論文の要約 ・ビジネス文書の作成や校正 ・写真や動画の内容説明 ・会議の議事録作成 ・図や表を読み取って分析   まとめ AI活用における実践的なコツやセキュリティ面での留意点、生成AIの特徴についてご紹介しました。 私自身、これまで業務での活用経験はほとんどなく、プライベートでも日常的な質問や簡単な調べ物にCopilotを使う程度でしたが、Interopへの参加を通じて生成AIの可能性と活用方法について理解を深めることができました。 特に、AIが単なる便利ツールではなく、業務の質やスピードを大きく向上させる可能性を秘めていることを実感したので、今後は各AIの特性を踏まえた上で目的に応じて適切に使い分けることで、業務効率化や品質向上に繋げていきたいと思います。 最後までお読みいただきありがとうございました。

こんにちは。SCSK株式会社　中村です。 Interop（インターロップ）とは、 主にネットワークコンピューティング分野における最新技術やビジネス動向を体験できる展示会やイベントのことです。 特に「Interop Tokyo」は、日本最大級のインターネットテクノロジーイベントとして知られています。 そんなInterop Tokyoに初参加してきましたので、会場全体の雰囲気や温度感、印象に残ったセッションなどについて報告したいと思います。当記事が今回参加できなかった方や来年参加しようと思ってる方の参考になれば幸いです。 また、SCSKとしてもいくつか出展を行っていましたのでそちらのブースなどについても紹介していきたいと思います。 事前準備 ①参加登録 Interopは当日思い立って飛び込み参加することは出来ません。 参加するには事前に参加登録を行う必要があります 。 参加登録の際にどの講演に予約をしておくか。という選択もあるので あらかじめ公演一覧から自分の興味のある講演を見つけて予約を行いましょう。 人気の講演はすぐに埋まってしまうため、目当ての講演がある場合は1か月くらい前から登録しないと予約できない可能性があります。 ②入場証の印刷 当日、 会場に入るためには登録後にサイトで発行される入場証が必要となります 。 A4サイズの紙に入場証を印刷して持ってくる必要があるため、こちらも当日忘れずに印刷して持ってくるようにしましょう。 会場までの道のり 海浜幕張駅から幕張メッセへ向かう、Interop参加者たち Interop Tokyo 2025は6/11(水)～6/13(金)の3日間開催され、今年の3日間のトータル来場者数はなんと136,875人にも上ったということです。 私は初日の6/11(水)に参加してきましたが、10:30に幕張海浜駅に着いた状態でも大量の人だかり。そのほとんどがInterop Tokyoの参加者たちでした。 駅から幕張メッセまではおよそ徒歩7～8分ほどですが行列を辿っていけばおのずと開催地に辿り着けると思います。 ブース会場を上から眺めた図。ここから見える範囲で全体の5分の1ほど。 入場証を係員の方に読み取ってもらっていざメインの会場へ。会場入り口は2階に位置しますが、出展ブースなどのメイン会場は1階にあるため、メイン会場の入り口を入るとすぐに広大な出展ブースの数々が目に入り圧巻です。 ぱっと見ただけで個性的なブースがいくつも目に入り、出展者の呼び込みや参加者の賑わいからお祭りにきたような感覚に陥り、自ずと高揚感が高まってきます。 会場の雰囲気 芸人さんが司会となってじゃんけん大会を催すようなブースも。 Interopはコンピュータ分野に特化したイベントであるため、各ブースで紹介されている製品なども業界知識をある程度持っていないと理解できないことは多いと思います。ただ、中にはあまりITに詳しくない方でも楽しく理解できるような催しを行っている企業もあり、そういったイベントを通してサービスや企業自体のことを知ってもらう工夫もInteropを体験する中で面白い観点だと感じました。   会場で行われる様々な講演 冒頭でも記載したように、Interopでは様々な分野の有識者の講演を予約して拝聴することができます。 私は４つの講演を予約しましたが、その中から印象に残った講演を2点簡単にご紹介したいと思います。 ①メールセキュリティ戦略 HornetSecurityの講演では、従来のSPFやDKIMだけではメールのなりすましを完全に防げない現状が指摘されました。そこで、これらの認証技術を強化し、なりすましメールをブロックする「DMARC」の積極的な導入が推奨されました。DMARCはSPFやDKIMの認証結果に基づきポリシーを設定します。 また、企業ロゴを表示する「BIMI」との併用で、視覚的にもメールの正当性を示し対策を強化できると説明されました。DMARCやBIMIは自社だけでなく、脆弱な取引先経由で被害が及ぶリスクがあるため、サプライチェーン全体のセキュリティ向上に向け、全企業での実施が極めて重要だと強調されました。 ②AIによるSASEサービスの運用と利活用 続いてはpaloalto Networks社によるAIを用いたSASEサービスの運用についてご紹介します。 同社は、SASEサービス「Prisma SASE」、セキュリティ運用自動化AI「Cortex XSIAM」、包括的セキュリティサービス「CDSS」を提供しており、これらを連携させることで単体以上の価値を生み出します。 例えば、「Prisma SASE」でクラウドサービスのアクセス状況を把握し、「Cortex XSIAM」でユーザー行動の傾向分析や、ダウンロードされたファイルの危険度を自動検出し削除します。また、「CDSS」と「Prisma SASE」の組み合わせでは、AIの判断を軸としたゼロトラストネットワークにより、動的なアクセス権限設定と運用を実現し、セキュリティ担当者の負荷を軽減します。 Palo Altoが提唱するのは、AIを核とすることで、従来の人手による運用を大幅に削減し、ヒューマンエラーを抑制しながらセキュリティを向上させる、新たな利活用モデルでした。 SCSKグループの出展ブース SCSKおよびそのグループ会社についてもInterop Tokyoにて数々の出展を行っていますので簡単にご紹介いたします。 Zabbix SCSKはZabbixのプレミアムパートナーとして昨年もInterop出展を行っております。今年のブースの場所も会場入口近くで、来場者の目に入りやすいので目にされた方も多いかと思います。 NebulaShift NebulaShift はSCSKが提供するクラウドネイティブ化支援サービスです。その NebulaShift のサービスをAI領域まで拡張した” NebulaShift ai”が昨年末リリースされており、その紹介ブースが設けられておりました。 NebulaShift はSCSKとしても力をいれているソリューションの一つでもあり、セッション講演にて当製品の講演も実施いたしました。(好評のようで、私がInterop申込時には講演予約は既に売り切れでした) SCSK Minoriソリューションズ SCSK MinoriソリューションズはSCSKのグループ会社です。今回の出展ではPlayBackMailというメール誤送信対策ソフトや、PerfectWatchAdvanceという資産管理ソフトについて紹介をしていました。 SCSKセキュリティ SCSKセキュリティもSCSKのグループ会社です。SCSKセキュリティではSplunkと呼ばれるビッグデータの解析ソリューションについて出展を行っていました。SCSKセキュリティは、Splunkの導入、運用、活用を支援する様々なサービスを提供しています。   まとめ 今回私がInterop Tokyo初参加ということで、一般参加者目線で雰囲気やイベントの概要的なものを紹介させていただきました。 本文でも記載したように会場は一種のお祭りのような雰囲気で、様々なブースの賑やかさを感じながら会場を歩き回るだけでも楽しい時間でした。 また、本来Interopは業界従事者が最新のソリューションや技術を体験して販売や自社業務に活用するための情報収集の場でもあり、 業界としてのトレンドや一分野の有識者の考えをいち早く取り入れられる貴重な場ともなっていると感じました。 個人的には全体的に見てやはり今はAIを主軸にしたサービスを展開している企業がほとんどでした。 次回もし参加する機会があったら、それまでに自分の中のクラウドソリューションの知見を深めておき、自らの業務に付加価値を提供できるようなソリューションがないか？といった観点で色々見て回ってお話なども聞きたいと思いました。是非みなさんも興味が湧きましたらご参加ください。

皆さん、こんにちは！SCSK株式会社の大野です。 今年も、Google Cloudが主催するグローバルカンファレンスイベント「 Google Cloud Next Tokyo 」が開催されます！このイベントは、クラウドテクノロジーの最新情報を学び、業界リーダーや専門家とのネットワーキングを行うための絶好の機会です。 ### Google Cloud Next Tokyo 概要 開催日:  2025 年 8 月 5 日（火）、6 日（水） 会場 : 東京ビッグサイト 南展示棟 この度当社は、PlatinumスポンサーとしてExpo会場へのブースを出展し、スポンサーセッションに登壇いたします。 IT 業界のみならず様々な業界のリーダー、意思決定者、エンジニア、そして開発者の皆様にご満足頂けるセッションコンテンツが準備されていますので、この機会をぜひ​ご活用ください。皆様のご参加を心よりお待ちしております。 ご登録がお済でない方は、まずはこちらからご登録ください↓↓ 【招待コード  : NT25_pt030 】 申し込み時にご入力ください ！！ イベントの見どころ Google Cloud Next Tokyoでは、最新の生成 AI はもちろん、進化する AI エージェントやセキュリティ、アプリ開発、 データベース、インフラ、データ分析、生産性とコラボレーションに関するアップデートと、実際に Google Cloud を導入・運用されているお客様の声を基調講演、ライブ セッション、展示やハンズオンなど、様々なプログラムが用意されています。 ☁︎ 基調講演 生成AI、AI Agent を含む最新のクラウド技術を紹介します。また、日本市場をリードするビジネスリーダーを招いて、そのビジョンや Google Cloud を活用した取り組みをお聞きします。 ☁︎ スポンサーセッション 米 Next で発表された最新情報や日本のお客様によるクラウド活用事例をお届けします。セッションの後にスピーカーへ直接質問して、自社のビジネスに役立つヒントを見つけましょう。 ☁︎ Expo Google Cloud 最新技術が集結！パートナー、お客様の事例デモ、エキスパートとの交流を通じて、Google Cloud 製品とソリューションを体験してください。 ☁︎ ハンズオン　セッション Google Cloud の魅力を、実際のハンズオンを通して体験しましょう。生成 AI、データ分析、インフラ構築、アプリ開発まで、直接、講師のアドバイスを受けながら開発を学べるチャンスです。 ☁︎ スペシャル　セッション 公共機関向けやカルチャーをテーマにした Google ならではのトピックを、ワークショップやラウンドテーブルなどの多様なスタイルで体験していただける特別なプログラムです。 ☁︎オープンステージ クラウド テクノロジーの最前線を発信する Silver スポンサーセッションです。生成 AI、データ活用、Google Workspace の革新的なソリューションをデモや事例を交えて紹介します。登録は不要なので、お気軽にご参加ください。 ☁︎ Learning & Certification Google Cloud 認定資格とラーニング プログラムのブースや認定資格者限定のラウンジでは、初心者から上級者まで、どなたにも役立ててもらえる、成長を加速させる情報をお届けします。 ☁︎ Dev Night  AI 時代に、開発者体験も未来に向けて進化しています。 Firebase を含む最新の AI エージェント開発手法やツールについて、コミュニティの人たちと一緒に楽しく学び、話し合いましょう。 SCSK のセッションとブースのご紹介 SCSK セッションのご紹介 開始日時：８月５日（火）12:00 – 12:30 タイトル： Gemini がデータサイエンティストに !? 業務データから始める高度なデータ活用 【概要】 生成AIは日々、進化しています。 その機能強化と導入・実用化の容易化が進む今こそ、データ活用を本格的にはじめてみませんか？これまで生成AIに触れてきたものの、「活用に課題を感じている方」・「イマイチ使いこなせていない方」・「そもそも使い方が分からない方」必見です。数々の大手企業様と共創してきたSCSKならではの視点で、最新技術を用いた高度なデータ活用のコツを『こっそり』ご紹介いたします。 取り上げる主な Google Cloud 製品 / サービス ・BigQuery ・Gemini ・Looker #初級者向け🔰　#全業種向け 【SCSK登壇者のご紹介】 クラウドサービス事業本部 ＡＩ＆クラウドソリューション部 第二課 AI リードエンジニア 島村 裕哉　 SCSKのクラウド専門部隊に所属する、AI/MLサービスのリードエンジニア。  Google CloudのAI/生成AIを活用し、製造業・金融業・食品業界など幅広いお客様のシステム設計・構築を担当。 AIサービス選定から導入コンサルティング、導入サポート、AI基盤・運用構築まで数多くの案件を経験。  Partner Top Engineer 2024/2025 にてCloud AIMLを2年連続受賞。 生成AIを業務活用したい方、ぜひセッションへお越しください！ SCSK ブース SCSKのブースでは、 昨今のクラウド活用に欠かせないテーマとなったAI・データ活用、また普遍的なテーマであるIaaSマイグレーションやセキュリティを中心とした最新サービス を展示いたします。 「データの活用が進まない」「AI導入が実証実験で止まってしまう」「セキュリティ対策に不安がある」「VMwareの今後をどうすればいいか悩んでいる」…。 SCSKは、このような企業が抱えるクラウド時代の複雑な課題に、お客様と「とことん」向き合い、最適な解決策をご提案します。 眠っているデータをビジネスの羅針盤に変えるデータ活用、AIの本格導入、会社の未来を守る強固なセキュリティ、そしてクラウドシフトに関する専門的なご相談まで、お客様の重要なクラウドの未来をトータルでサポートいたします。 貴社の課題解決とビジネス成長を、SCSKのクラウドサービスで実現しませんか。 ぜひご来場いただき、最新のAI技術とSCSKだからできるビジネスへの活用方法についてご確認ください！   では皆様、Google Cloud Next Tokyoを楽しみにお待ちください。 当日はSCSKセッションならびに展示ブースへの来場をお待ちしております！ 【招待コード : NT25_pt030】 申し込み時にご入力ください ！

SCSK永見です。 IAMとは、AWS リソースへのアクセスを安全に管理するための認証・認可を司るサービスです。 なのでAWSサービスを使う以上、IAMの理解は避けては通れません。 そこで今回は、初めてIAMに触れる方へ向けて、IAMの中でベースとなる「IAMポリシー」「IAMユーザ」「IAMグループ」「IAMロール」の概念を、サンタクロースになぞらえて解説します。 全体像 さっそくタイトルの伏線回収をしましょう。この画像が、この記事で説明するすべてです。 IAMポリシー はできること、できないことの権限を定義し、それらはIAMユーザ、IAMグループ、IAMポリシーに紐づける事ができます。 IAMユーザ はIAMユーザ自身、もしくは所属している IAMグループ に付与されたIAMポリシーに応じて、AWSのリソース操作が許可/拒否されます。 IAMユーザーやアプリケーション、サービスは、 IAMロール を引き受けることができ、IAMロールに付与されたIAMポリシーに応じてAWSのリソース操作が許可/拒否されます。 AWSのアイコンを使うと、このように表すことができます。 IAMポリシーとは できること、できないことの定義 をIAMポリシーといいます。「権限」のようなイメージです。 S3バケットを一覧できる、EC2インスタンスを起動できる、RDSを削除してはいけない、、などなど、AWSのリソース操作に対する権限を定義できるのがIAMポリシーです。定義はjson形式で記載されます。 サンタクロースは、空を飛べるそりに乗ることができる、子どもがいる家に入ることができる、正体がばれてはならない、、などの「権限」があります。   IAMユーザとは 「人」自身 をIAMユーザと言います。これはわかりやすいですね。 IAMポリシーはIAMユーザにアタッチすることができます。このIAMユーザはS3バケットを一覧できる、RDSを削除してはいけない、、など、IAMポリシーを紐づけることを アタッチ といいます。 「サンタクロース」のIAMユーザには、子どもがいる家に入ることができる、正体がばれてはならない などのIAMポリシーが紐づいていますね。 IAMグループとは IAMユーザが所属する「団体」 です。これも割とわかりやすいですね。 IAMポリシーはIAMグループにアタッチすることができます。かつ、IAMユーザはIAMグループに所属することができます。IAMグループにアタッチされたIAMポリシーは、IAMグループに所属しているIAMユーザに継承されます。 ところで、サンタクロースには公認試験というものがあるらしいです。 https://ja.m.wikipedia.org/wiki/サンタクロース#公認試験 みごとこの試験に合格したら、「公認サンタクロース」とみなされます。この「公認サンタクロース」IAMグループには同じく子どもがいる家に入ることができる、正体がばれてはならない などのIAMポリシーが紐づいており、「公認サンタクロース」IAMグループに所属していれば、これらの権限を継承することができます。 IAMロールとは ロール を直訳すると「役割」です。これがちょっと難しいですね。 IAMポリシーはIAMロールにアタッチすることができます。そしてIAMロールはアタッチされたできること、できないこと を、IAMユーザーやアプリケーション、サービス、リソースに引き継ぐことができます。 サンタクロースの特徴といえば、「サンタ帽」ですね。この「サンタ帽」IAMロールにもそりで空を飛べる、プレゼントを際限なく持てる などのIAMポリシーが紐づいています。 この「サンタ帽」をかぶれば、どんな人であろうと、もっというと人でなくても、これらの権限を有することができます。 まとめ AWSに初めて触れた時、IAMポリシーとIAMロールが似たような概念で混乱したことを思い出し、この記事を書きました。IAMユーザはIAMポリシーを直接アタッチ、IAMユーザグループから継承、IAMロールを引き継ぐ のパターンがあるのでややこしいですね。 IAMはAWSの基礎となるサービスです。混乱したときは、「サンタクロース」「公認サンタクロース」「サンタ帽」の絵を思い出しながらゆっくり理解しましょう。

現在、新しいサービスを導入する際には、事前にPoC（概念実証）を行うことが一般的となっています。 PoCの目的は、採用を検討するサービスを比較するために実際にサービスを体験してみる事だったり、採用の最終確認だったり、と状況は様々です。 私たちSCSKとしても、Catoクラウドへの切り替えを行う際には、最初にPoCをお勧めしています。 Catoクラウドの導入により、ボトルネックの解消やセキュリティの強化、運用の省力化など多くが期待できますが、本当に自社環境に適合するのかを確認するために、PoCの存在は重要です。 PoCで何をテストするか？何を確認するか？については各社異なりますが、参考までにいくつかのポイントを挙げさせていただきます。 社員が働く環境（オフィスや自宅、海外出張先）から、現状業務がCatoクラウド経由で問題なくできるか？ また、それぞれの環境でセキュリティが確保できるか？ 既存のサービスとの連携が問題なくできるか？ 何か条件がある場合、解決手段はあるか？ Catoクラウドに切り替える事で、現状抱えるネットワークやセキュリティの課題が解決できるか？ 自社のセキュリティポリシーやデバイス管理方法を満たせるか？ 自社ネットワークをCatoクラウドへの切り替えるイメージをもつ Catoクラウド切り替え後のネットワーク運用 / セキュリティ運用をイメージする CatoクラウドのPoC用ライセンスは、原則として有効期間が1ヶ月間となっています。 そのため、お客様がPoCを効果的に実施できるよう我々SCSKでは、PoC構成のアドバイス、テストしたい内容に重点を置いた技術支援、PoC期間中のQA対応、といったサポートを提供しています。 お客様とPoCの話をする際に、ほぼ必ず「本番ネットワーク環境を使用したPoC構成をどうしようか？」といった相談を受けます。 業務は全てSaaSを利用している！というケースは除きますが、基本的には、まず社内システムのサーバがあるところにCato Socketを設置して、各テスト環境からCatoクラウド経由で接続するという構成になります。今回はその構成例をご紹介します。 データセンターにCato Socketを設置したPoC構成例 Catoクラウド切り替え前のネットワーク構成は、多少の違いはあれど次のような構成かと思います。 閉域網で各拠点を接続 インターネットにはデータセンターのFirewallやUTMから接続 自宅や外出先からは、データセンターのVPN装置にSS-VPNなどで接続 <現行ネットワーク構成イメージ>   このような構成では、Socketをデータセンターに設置し、テスト用PCからCatoクラウドを経由して社内システムを利用することが可能です。下図では、本社にもSocketを設置し、個別のインターネット回線に接続した「Socket配下テスト環境」と、Cato Clientをインストールした「モバイルテスト環境（自宅や外出先を想定）」からデータセンターの社内システムにアクセスする構成を示しています。 見ての通り「Socket配下テスト環境」も「モバイルテスト環境」も本番環境と重複しないアドレスレンジを設定しているので、データセンターのL3SWにその戻りルートをSocket向けに追加することで、本番通信に影響を及ぼさずにテストを行うことが可能となります。 既存ネットワークの変更作業としては、以下の2点です。 データセンターのFirewall・L3SWとCato Socketの接続、FirewallにSocket～Catoクラウド間のトンネル用ポート番号の許可 （必要なポート番号：443/TCP/UDP, 53/UDP） L3SWにスタティックルートの追加 なお、Catoクラウドに接続するテスト環境のサブネットは、Catoクラウド内で動的にルーティグされます。 また、テスト環境からのインターネット接続は、Catoクラウドから直接でていくので特に考慮は不要です。 <PoC構成その1>   なお、Socketは、必ずWANポートとLANポートを接続する必要があります。（いわゆる1アーム構成には対応していません） WANポートは回線（側）と接続してCatoクラウドとトンネルを形成し、LANポートはスイッチなどLAN機器と接続して、LAN内のデフォルトゲートウィとなるのですが、これらが同一VLANであっても問題ありません。 下図に示すように、Firewallの同一VLANのポートとSocketのWAN/LANポートを接続して、Socketが必要なポート番号でインターネットに出られるようにするのと、各テスト環境サブネット向けの戻りルーティングをSocketのLANポートのアドレス宛に追加すればOKです。 <PoC構成その2> AWSにvSocketを設置したPoC構成例 社内システムがAWSなどのクラウドに移行されているネットワーク構成でも、考え方は同様です。 AWS内にvSocketを作成し、VPCなどのルートテーブルに各テスト環境向けのルーティングをvSocket宛てに追加することで、本番通信に影響を与えることなくテストを実施することが可能です。 <AWSでのPoC構成>   もちろん、社内システムがデータセンターとAWS（またはAzure）に存在する場合でも、物理SocketとvSocketをそれぞれ設置し、個別ルーティングを追加することで、各テスト環境から両方のシステムにアクセスしてテストを行うことが可能です。 実際に、そのような構成でPoCを実施しているお客様もいらっしゃいます。 Catoクラウドへの切り替えについて 少し補足ですが、既存ネットワーク拠点をCatoクラウドへ切り替える際には、各拠点のWANルータをSocketに置き換える作業となります。 拠点が多い場合は、一度に全てを切り替えるのは難しいかもしれません。その場合は、拠点ごとに順次切り替えを行います。 切り替え作業の基本的な考え方は、PoC構成で示した通りで、まずシステムがあるデータセンターやAWSなどのクラウドにSocketを設置し、切り替える拠点のサブネット向けのルーティングを順次Socketに切り替えていくといった流れです。 切り替えのたびにルーティングの変更を行うのは大変ですが、もし既存ネットワークでBGPを使用していれば、SocketはBGPをサポートしているので、自動的にルートの切り替えが可能です。 この辺りは、Catoクラウド自体の問題ではなく、ネットワーク切り替え設計の話になります。 さいごに 今回はPoC構成について記載しましたが、PoCを実施する上で、まだ多くの疑問点があるかもしれません。 たとえば、DNSの設定やIdaaS連携、デバイス認証、ローカルブレークアウトはどうなるのか、といった点です。 SCSKの技術ブログでは、この後もPoCに関する情報を提供していく予定ですので、ぜひご期待ください。 また、SCSKではこれまで数多くのPoC支援、導入支援を行っており、多くのお客様ネットワーク構成をみてきました。 Catoクラウドのサービス内容以外にも、PoC関連やCatoクラウドの切り替えについても、何かご心配・不明点などがありましたら是非お声がけ下さい。

こんにちは。SCSKの磯野です。 Google CloudのVMで、外部に公開するようなWebサイトを運用している場合、該当のWebサイトの死活監視を行うためのモニタリングが必要となります。 今回は、VMで稼働しているパブリックなWebサイトに対して、どのように死活監視をすればよいかをご紹介します。 前提 本記事は以下を前提とします。 VMインスタンスで構築しているWebサイトは、一般公開されているものとする VMインスタンスは、インスタンスグループに属しているものとする（マネージド/非マネージドは問わない） 本記事では、どのメトリクスを監視すればよいかについては言及しますが、実際の監視実装方法までは言及しません。 実装方法については以下の記事を参照ください。 Google Cloud における監視方法について- モニタリングとロギング Google Cloudにおける監視はログ監視とメトリクス監視の２種類に分けることができます。Cloud Loggingの使い方、Cloud Monitoringにおけるクエリの書き方、Terraformでアラート実装方法等をご紹介します。 blog.usize-tech.com 2025.06.09   方法①：URLでの稼働時間チェックを行う（推奨） HTTP/HTTPS 稼働時間チェックは、デフォルトでレスポンス コードが 2xx  であることを確認します。いわゆる 外形監視 に該当するため、パブリックなWebサイトに対する死活監視としては最も推奨される方法となります。 HTTP と HTTPS の場合、すべての URL リダイレクトをフォローし、稼働時間チェックで受信した最終的なレスポンスから成功基準を評価します。HTTPS チェックの場合、SSL 証明書の有効期限は、最後のレスポンスで受信したサーバー証明書に基づいて計算されます。 稼働時間チェックに成功するには、次の条件を満たす必要があります。 HTTP ステータスが指定した条件に一致する。 レスポンス データに必須のコンテンツがないか、必要なコンテンツがすでに存在する。 公開の稼働時間チェックを作成する  |  Cloud Monitoring  |  Google Cloud cloud.google.com   方法②：VMのヘルスチェックログを監視する インスタンスグループに属しているVMは、健全性変更ログ（ヘルスチェックログ）を出力します。UNHEALTHYログの監視を行うことで、VMのヘルスチェックステータスの監視に近いものを実装可能です。 ただし、特に非マネージドインスタンスグループについては、インスタンスが停止してWebサイトに5xxエラー等でアクセスできない場合でも ヘルスチェックのUNHEALTHYログが出力されないケースがある（※） ため、方法①を推奨します。 VM の健全性の変化をモニタリングする  |  Compute Engine Documentation  |  Google Cloud cloud.google.com ※インスタンスを停止すると、0/0となりステータスが正常とみなされてしまうため   方法③：VMインスタンスの稼働時間チェックを行う VMインスタンスの稼働時間チェックでは、稼働時間メトリクスが欠損していないかを監視することで「インスタンスが稼働しているか」の確認を行うことができます。 Webサイトの稼働確認ではなく、あくまでもVMの稼働確認 となるため、要件に応じて方法①を使用してください。 terraformでの作成例は以下の通りです。 resource "google_monitoring_alert_policy" "vm_stoped" { display_name = "VM Instance - Uptime Absent(VM Stopped)" combiner = "OR" conditions { display_name = "VM Instance - Uptime" condition_prometheus_query_language { query = <<EOT absent(avg by (instance_name, project_id)( increase(compute_googleapis_com:instance_uptime{ monitored_resource="gce_instance", project_id="{プロジェクト名}", instance_name="{インスタンス名}"}[5m])) ) == 1 EOT duration = "240s" # 最大 240 秒間はデータは表示されないため } } enabled = true notification_channels = "xxx(通知先のslackなど)" alert_strategy { notification_prompts = ["OPENED"] } }   まとめ いかがだったでしょうか。 今回は、VMで稼働しているパブリックなWebサイトに対して、どのように死活監視をすればよいかをご紹介しました。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKの磯野です。 Dataformでは、環境ごとに異なるプロジェクトにテーブルをリリースすることができます。 Dataformで複数プロジェクトかつ複数環境にリリースする方法 Dataformで、同一のSQLXファイルから複数環境（dev、prod）向けにリリースを行う方法を記載します。 複数のプロジェクトを使用する場合でも、カスタムコンパイル変数を使用することで実現が可能です。 blog.usize-tech.com 2024.09.24 Dataformの アサーション 結果 についても、環境ごとにプロジェクトやデータセットを変更して出力したいケースがあると思います。 今回は、アサーション結果の出力先を環境ごとに変える方法をご紹介します。 アサーション出力先の プロジェクト を環境ごとに変更する方法 アサーション結果は、デフォルトで workflow_settings.yaml の defaultProject で設定された プロジェクト に出力されます。 テーブルへのリリースと同様、アサーションについてもリリース構成の「Google Cloud プロジェクトID」というコンパイル変数をオーバーライドすることで、環境ごとにプロジェクトを設定することができます。 詳細は下記の記事を参照ください。 Dataformで複数プロジェクトかつ複数環境にリリースする方法 Dataformで、同一のSQLXファイルから複数環境（dev、prod）向けにリリースを行う方法を記載します。 複数のプロジェクトを使用する場合でも、カスタムコンパイル変数を使用することで実現が可能です。 blog.usize-tech.com 2024.09.24 アサーション出力先の データセット を環境ごとに変更する方法 アサーション結果は、デフォルトで workflow_settings.yaml の defaultAssertionDataset で設定された データセット に出力されます。 しかしプロジェクトとは異なり、 アサーション用のデータセットは、UI上からリリース構成のコンパイル変数としてオーバーライドできません 。（※執筆日時点） データセットを環境ごとに変更したい場合は、APIを通じて実装する必要があります。APIドキュメントは下記の通り。 Method: projects.locations.repositories.releaseConfigs.create  |  Dataform  |  Google Cloud cloud.google.com ※releaseConfigs.create -> リクエスト本文 -> codeCompilationConfig -> assertionSchema まとめ いかがだったでしょうか。 今回はDataformにて、アサーション結果の出力先を環境ごとに変更する方法をご紹介しました。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKの磯野です。 Dataformにはアサーションという機能があります。 アサーションを使用してテーブルをテストする  |  Dataform  |  Google Cloud Dataform コアを使用して Dataform にアサーションを作成します。 cloud.google.com また、Dataformでは増分テーブルを構成することができます。 増分テーブルを構成する  |  Dataform  |  Google Cloud Dataform コアを使用して Dataform の増分テーブルを構成する。 cloud.google.com そこで、 アサーションにおいても増分ロジックでスキャンする ことができないか、調査してみました。 やりたいこと 例えば下記のようなBigQueryのテーブルがあったとします。 ファイルを受信した時刻・ファイルのフォーマットチェック結果が格納されているテーブルです。 ※本記事では以後、本テーブルを result_table とします received_time ：ファイルを受信した時刻 format_check_result ：ファイルのフォーマットが想定通りかをチェックした結果 format_check_time ：ファイルのフォーマットチェックを行った時刻 前提/要件 フォーマットチェックは毎日18:00に行われるため、 result_table は毎日更新される。 フォーマットチェックがFALSE（＝異常なファイルを受信していた）の場合はアサーションエラーとするが、アサーションの実行対象はその日にチェックしたデータのみとしたい。 前日に届いたファイルが異常だった場合、前日はアサーションエラーとなるが、翌日はアサーションエラーとしたくない ※上記の例の場合、2025/7/1はアサーションエラーとなるが、2025/7/2,3はアサーションエラーとしたくない モチベーション result_table は、スキャン量を考慮して増分テーブルで構成されている。アサーションがフルスキャンとなってしまうと、 result_table を増分で構成した意味がなくなってしまう。 一度異常なデータが格納されても、エラーは発砲され続けないでほしい。常に最新のデータのみのアサーションを実行してほしい。   課題：「type: “incremental”」の組み込みアサーションはフルスキャンとなる 実装方法・コード まずは、 result_table を作成している処理の組み込みアサーションとして実装してみました。 テーブルのいずれかの行が  false  の場合、アサーションは失敗します。 config { type: "incremental", name: "result_table", assertions: { rowConditions: [ 'format_check_result = TRUE' ] }, (略) } SELECT ... 結果 テーブルの作成は増分ロジックとなっていたのですが、 組み込みアサーションについてはフルスキャンとなってしまいました。   対処法：手動アサーションを使用する 実装方法・コード result_table の作成処理とアサーションを分離し、手動アサーションとして実装してみました。 手動アサーション SQL クエリは行を返さないようにする必要があります。クエリの実行時にクエリが行を返すと、アサーションは失敗します。 アサーションを使用してテーブルをテストする  |  Dataform  |  Google Cloud Dataform コアを使用して Dataform にアサーションを作成します。 cloud.google.com config { type: "assertion", } SELECT * FROM ${ref("result_table")} WHERE format_check_result = FALSE -- チェック失敗(false)していたらアサーションエラーとする -- アサーションとresult_tableへのデータ格納はセットで実行する前提。 AND format_check_time >= DATETIME_SUB(CURRENT_DATETIME("Asia/Tokyo"), INTERVAL 5 MINUTE) 結果 下記工夫をすることで、 アサーションを増分ロジックで構成することができました。 手動アサーションとする 直近5分間にresult_tableへINSERTされたデータのみをアサーションチェックすることで、増分ロジックを実現 まとめ いかがだったでしょうか。 今回はDataformのアサーションにおいて、増分ロジックでスキャンする方法についてご紹介しました。 手動アサーションによる実装であれば、クエリの書き方次第で増分ロジックでアサーションを実装することができることがわかりました。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK吉田です。 先日6月下旬、社内勉強会の一環としてServiceNowを使った社内ハッカソンを開催しました！ 今回は社内ハッカソンの開催レポートとなります。   はじめに 社内でハッカソンを実施しようとしたきっかけは、 SCSK社内でも、更にServiceNowを盛り上げていきたい！ となります。 また、ハッカソンへの参加を通じ、普段の業務ではできない新しい経験や、技術の獲得にもつながれば良いなという思いもあり、様々な方にご協力いただき社内ハッカソンの開催にいたりました。 ハッカソン開催までの道のり ServiceNow社の方々にもご協力いただき、ハッカソンを含め、２月から６月にかけて計５回の社内勉強会を開催しました。 第４回はアイデアソン、第５回がハッカソンとなります。 始めに、第１回から第４回までの勉強会を簡単に振り返ります。 第１回社内勉強会：ServiceNow製品概要＆トレーニング・認定資格の紹介 まずは、ServiceNowをまだよく知らないという社内の方に向けて、ServiceNowの製品概要、及び近年のAIに関する取り組み、そしてこれらの情報を学べる場としてのServiceNow University（旧Now Learning）、そしてSCSKのServiceNowに関する取り組みを紹介しました。 また、私の方からは、ServiceNow Universityを活用した学習・キャリア開発、認定資格を取得する価値を語らせていただきました。 当日は約６０人の方に参加いただき、大盛況のうちに終えることができました。 第２回社内勉強会：ServiceNowのアプリ開発を学ぶ（ハンズオン） 第２回では、主にServiceNowのアプリ開発に興味がある方に向けて、アプリ開発の基本的な考え方・構造を紹介しました。 基本である「Task」「Process」「UI」のコンセプトを学んだ後、実際にServiceNow Studioを使用してハンズオンを実施しました。 参加者の方々には、アプリ・ロール、データモデル、フロー、ワークスペースの作成など、アプリ開発の一連の流れを体験していただきました。 第３回社内勉強会：ServiceNow Japan Hackathon 2024の振り返り＆Now Assistの勉強 社内アイデアソン、ハッカソン参加者と共にServiceNow Japan Hackathon 2024の内容を振り返りました。 昨年のテーマである「PUT AI to Work」の理解、各参加チームの選定テーマの傾向などハッカソンの概要、そしてNow Assistの機能を学習しました。 また、チーム分けを行い、次回アイデアソンに向けたネクストアクションを共有しました。 ※ServiceNow Japan Hackathon 2024の開催レポート ServiceNowハッカソン2024開催レポート はじめに 去る2024年9月9日、ServiceNowの開発者向けイベント「ServiceNow Japan Hackathon 2024」が開催されました。開催のたびにご参加いただく開発者の数が増え、今年も過去最多となる48チーム、265... www.servicenow.com   第４回社内勉強会：アイデアソン 「AIの活用」をテーマとし、第３回勉強会から約１カ月間、各チームが考えたアイデアをプレゼンしました。 選定されたテーマを分類すると以下の通りとなります。各チームとも高齢化や人手不足を背景とした各業界の課題にアプローチするアイデアです。短い準備期間でしたが、各チームがターゲットとする業界における課題をしっかりと分析したうえで、ServiceNowでどのようにアプローチするかまで考えていただきました。 マンション管理 介護 教育 各チームのプレゼンに対し、AI機能の活用、アイデアの新規性、影響度、実現性などの観点で審査を行い、１位チームを決定しました。 （審査を実施していますが全チームハッカソンへ進みます） ハッカソン 参加者概要 参加者：１５名 チーム数：４チーム ServiceNowの開発経験者率：２割 開発期間：１カ月 成果発表 ServiceNowでの開発は初めてというメンバーが多い中、アイデアソンの内容をServiceNowへの開発へ落とし込み、全チームが実際に動くデモと共にプレゼンを実施いただきました。 以下、各チームのデモ部分を中心にどのような発表内容だったか簡単に振り返ります。 マンション管理業務へのServiceNow活用 マンション住人から問い合わせやクレームに対し、Virtual Agentを活用したセルフサービスの提供 セルフサービスで解決しない場合は、チケット起票、担当者へのアサイン、チケットのクローズまでの一連の流れをワークフローで自動化 介護者支援プラットフォームとしてServiceNow活用 介護者からの悩み・相談に対し、Virtual Agentを活用したセルフサービスの提供 フォローアップが必要な場合は、チケットを自動起票の上、AIによる問い合わせ内容の要約、優先度付けを実施 AWAを活用し、空き状況、保有スキルをもとに自治体等の担当者へ自動でチケットをアサイン 教育現場における先生・保護者・生徒をつなぐプラットフォームとしてServiceNow活用 ポータルを活用し、先生・保護者・生徒間のシームレスな情報共有を実現 行事の出欠確認や日程調整など各種申請をServiceNow上でデジタル化 各教師に属人化する業務ノウハウ、過去の保護者からの問い合わせ、テスト資料などの紙資料をナレッジとして蓄積 蓄積されたナレッジを活用し、教師・保護者・生徒に対しVirtual Agentによるセルフサービスの提供 教育現場における教員不足、長時間労働問題の解決を目指したServiceNowの活用 生徒からの問い合わせに対する回答をAI Agentが代行することで、教師の業務負担軽減 AI Agentが過去の類似の問い合わせ、それに対する回答を検索し、その内容を踏まえた上で生徒へと回答する   プレゼン後にはQAの時間も設け、活発な議論が行われました。 各チームのプレゼンに対し、アイデアソンと同様にAIの活用、サービスの新規性や将来性・拡張性などの観点で審査を行い優勝チームを決定しました！ 優勝チームには、ささやかながら優勝記念品をプレゼントしました。 ハッカソンの振り返り ServiceNowでの開発未経験者が多いハッカソンでしたが、各チームが選定した課題に対し、ServiceNowで使用する製品、アーキテクチャ、AI機能の活用方法、ライセンス形態を踏まえたマネタイズ方法まで考えていただき、非常に良い学びの場とすることができました。 以下、参加者からの声となります。 製品選定、及びアーキテクチャの検討から実装までを経験でき、良い学びの機会となった。 ServiceNow × AIの可能性を感じた。よりServiceNowのことを学んでいきたいと思った。 さいごに 弊社は昨年度初めて、ServiceNow Japan Hackathon 2024に参加させていただきましたが、アイデアソン敗退でハッカソンへ進むことができませんでした。今後、ServiceNw社主催のハッカソンに参加する機会があったら、今回の社内ハッカソンでの学びを活かし、ハッカソン進出、及び入賞を目指していきたいと思います！

こんにちは！ SCSK株式会社　小鴨です。 最近はひどく暑いですね 正直ラスベガスの方が涼しかったです（笑） そんな自分ですが、今日も Knowledge 25 　 のご紹介を始めます！！   前回の記事は準備・到着編になります。 まだ読んでいない方は以下リンクからどうぞ！ 【ServiceNow】Knowledge25への参加記録！！その１　～準備・到着～ – TechHarmony   JAPAN WELCOME SESSION 「始まり」のイベント ラスベガスの空気になれたのもつかの間、早速イベントが始まります。 初日は日本からの参加者のみで行う「JAPAN WELCOME SESSION」が開催されます。 恐ろしく豪華なホテル「Wien(ウィーン)」に集合し、日本人向けに用意された特設部屋に向かいます。 ウィン ラスベガス（ラスベガス）：（最新料金：2025年） 美しい庭園に囲まれたオシャレなホテル 奥まで進むとゴルフ場もあり、日本のおじ様たちは目を輝かせていました。 なぜか屋内にメリーゴーランドがあったり (Wienと関係があるのでしょうか？) JAPAN WELCOME SESSION開始 会場では入り口で渡された番号札に従って机につきます。 下の写真のように、立食形式で食事を楽しみながらServiceNowからのイベント説明を聞く形ですね。 イベントの過ごし方を学ぶのももちろんですが、ここでは日本人同士の交流も一つの目的です。 自分も卓につくなり早速名刺交換を始めたのですが… 　どうも、部長の～～です どうも、係長の～～です   あ、どうも特に何者でもない小鴨です… やっぱりこういうイベントに来る人は重役の方が多いのですね、、、 自分の卓は特に上の役職、年次の方が多く、ずっと緊張してしまいご飯があまり食べられませんでした。 (全員が美味しかったと語る「和牛バーガー」が食べられなかったのは今回の出張最大の後悔です) 誇りを賭けた戦い ということでここからは非常に楽しませてもらったプログラムの一つ 「クイズ大会」の紹介です。 こちらはServiceNowの方から出題される8つの4択問題を早押し形式で回答するというものであり 正解を選べたとしても、遅く回答したのでは点数が低くなってしまうという思いのほかゲーム性の高いものになっています。 高得点者は前に出て景品をもらえるということを聞いたとき SCSKの名前を前面に押し出すことができる！と感じ これは遊びではなく、企業間の戦争だと捉えて本気でクイズに挑みました。 ライバルは400人！   第一問！ 本イベントの参加人数は？   21000人！ 圧倒的21000人っ！！     第二問！ 本イベントのセッション数は？ 愚問！ 1000超だ     …なんて真面目に答えていると あれ？オレ2位？ まだ折り返しだけど 第6問！ もう覚えてないけど答えが分からないから適当に回答！ ・・・正解！ 天の意志が　オレを選んでいる…オレに「勝て」といっている…！ 　クク…悪くねえな…頂点の景色ってやつは   第7問！ 「ServiceNowのCEOが中学生の時に買った大きな買い物は？」 ・・・は？ こんなんどうやって推測せえと にやにやしているServiceNowスタッフの方々が悪魔のように見えました。 くそがっ！！ だが焦ってはいけない、ここまで培ってきた直感を信じるのだ！ 弱気に流れている人間は理に頼ろうとする、直感に頼ることが出来なくなる… ポチッ… が！駄目っ！！　不正解！ここにきて不正解！ 3位転落！   ラスト8問目 1位を狙うにはどうする？ もう問題と解答を見ている暇はない、回答が表示されると同時に適当にボタンを押すんだ！ ポチッ…   あとがき そんな形で、Knowledge25一日目は終了 明日からの本番に向けて日本メンバー一丸となったセッションでした。 色々ありましたが、自分は最後の選択に効果はありません。 美しく燃え尽きた夜でした。 次回からはいよいよイベント本番の様子を詳しく紹介していきます。 ●異文化に圧倒される初日 ●やっぱり英語は話せた方が良い ●ServiceNowってすごいんだな といったところが語れるといいなと思っています。 引き続きその3もゆったりとお楽しみください。