この記事では、Zabbix 7.4で登場した新機能である  ホストウィザード による、ホスト登録の手順をご紹介します。 ホストウィザードは、画面の案内にステップバイステップで従うだけで、迷うことなくホストを作成できる、初心者の方にオススメな機能です。   ホスト登録手順 データ収集 -> ホスト -> ホストウィザード　からホストウィザード画面を開きます。 「ホストウィザードへようこそ」が表示されたら「次へ」を押下します。   テンプレートを選択 登録するホストに紐づけるテンプレートを選択します。 テンプレートを検索するためのキーワードを入力すると、キーワードの文字列を含むテンプレートが表示されるため、その中からホストに紐づけるテンプレートを選択します。 今回だとLinux by Zabbix agentのテンプレートを選択します。   ホストの作成または選択 登録するホストの、ホスト名とホストグループを作成または選択します。 今回は、新規にホストとホストグループを登録します。   Zabbixエージェントインストール ZabbixサーバーのIPアドレスを入力します。   ホストウィザードを使ったエージェント登録では、 ZabbixサーバーとZabbixエージェント間の暗号化が必須 となっております。 事前共有キー識別子に任意の文字列を入力し、事前共有キーを取得します。 監視対象のOSを選択します。今回のエージェントは、LinuxのためLinuxを選択します。   上記の項目を入力すると、Zabbixエージェントをインストールするコマンドが自動的に作成されます。 こちらのコマンドをコピーし、Zabbixエージェントを導入するサーバに貼り付けて実行します。 ※コマンドの実行に際して、対象のサーバーはインターネット疎通が必要となります。   コマンドを実行すると、Zabbixエージェントが導入されて、自動で起動してきます。   ホストインターフェースを追加 登録するZabbixエージェントのIPアドレスとポート番号を入力します。 ポート番号をデフォルトのポート番号から変更する場合は、/etc/zabbix/zabbix_agentd2.confのListenPortを、変更後のポート番号に書き換えてください。   ホストの設定 ホストの設定では、ホストマクロなどを定義します。今回はデフォルト値で進めます。   「作成する」を押下してホストを作成します。   作成確認 問題なく設定されていると、こちらのように設定完了画面が表示されます。   データ収集 -> ホスト　から作成したホストが追加されているか確認します。   まとめ 今回はZabbixのホストウィザードを使ったホスト登録手順を解説しました。 ウィザードの案内に従い、設定値を入力するだけで、誰でも簡単かつ迅速に監視を開始できます。特に初心者の方にとって、ホスト登録のハードルを大きく下げてくれる強力な機能です。 この記事を参考に、ぜひご自身の環境でもホストウィザードを体験してみてください。 最後までお読みいただき、ありがとうございました！   ▼ Zabbixに関するおすすめ記事 【Zabbix】トリガーアクションでスクリプトを実行する方法 本ブログではZabbixのトリガーアクションで障害対応を自動化する方法を解説します。 今回はトリガーアクションの中でもスクリプトの実行方法について説明します。 blog.usize-tech.com 2025.06.10 スクリプトを用いてZabbixサーバのインストールを自動化してみた-RHEL系OS/MySQL編- Zabbixサーバのインストールを自動化するシェルスクリプトを紹介します！初心者でも簡単に短時間でZabbixサーバの構築が可能となります。スクリプトを用いた構築で効率化をしましょう！ blog.usize-tech.com 2025.09.02 Zabbixにセキュリティパッチは無い？Zabbixにおける脆弱性対応とマイナーバージョンアップの方法 Zabbixってセキュリティパッチあるの？いえ、ないのでバージョンアップで脆弱性に対応します。マイナーバージョンアップ方法も紹介します。 blog.usize-tech.com 2025.07.17

こんにちは、SCSKの前田です。 いつも TechHarmony をご覧いただきありがとうございます。 今回は、Windows 版 LifeKeeper / DataKeeper の最新バージョン v8.11.0 に追加された新機能を中心に、製品の進化ポイントをご紹介します。 はじめに Windows 版 LifeKeeper 製品の最新バージョンでは、 新機能の追加 に加え、 バグ修正・機能強化 、そして アップグレード時の注意点 がリリースノートに記載されています。 本記事では、それらの内容をわかりやすく整理し、皆さまのシステム運用に役立つ情報をお届けします。 本記事公開時点での LifeKeeper 関連製品の最新バージョンは以下の通りです： LifeKeeper for Windows v8.11.0 DataKeeper for Windows v8.11.0 LifeKeeperとは？（おさらい） LifeKeeper は、ビジネスの継続性を支える 高可用性（HA: High Availability）クラスターソフトウェア です。 サーバーやアプリケーションに障害が発生した際、その影響を最小限に抑え、 システムが止まることのないよう自動で復旧・切り替え を行うのが LifeKeeper の主要な役割です。 具体的には、 複数のサーバー（ノード）でクラスターを構成 し、稼働系サーバーで障害が発生した場合、LifeKeeper がそれを検知し、 瞬時に待機系サーバーへ処理を移行 します。この一連の自動切り替え処理を「 フェイルオーバー 」と呼びます。 LifeKeeper の強みは、OS・ミドルウェア・データベース・アプリケーションなど、様々な 「保護対象リソース」 の状態を監視し、それらをグループ化して切り替え制御を行える点にあります。 この 柔軟なリソース保護 と、 複雑な設定なしに利用できる使いやすさ が、多くの企業に採用される理由です。 リリースノートでは、この LifeKeeper の 「保護能力」 や 「監視精度」 、そして 「フェイルオーバーの信頼性」 をさらに高めるための新機能や改善点、対応環境の拡充などが記載されています。 最新バージョンで、 より堅牢で効率的なシステム運用 を実現するための進化の全貌を、ぜひご覧ください。 新機能：LifeKeeper/DataKeeperの進化のポイント 本章では、Windows 版 LifeKeeper / DataKeeper の最新バージョンで追加された 注目の新機能 についてご紹介します。 企業システムの信頼性向上や運用効率化に直結する、 実用性の高い機能強化ポイント を中心に解説していきます。 ① Windows Server 2025 への対応強化 最新バージョンでは、 Windows Server 2025 が新たにサポート対象に加わりました。これにより、企業は次世代OS環境への移行をスムーズに進めながら、LifeKeeper / DataKeeper の高可用性機能を継続して活用できます。 特に、 汎用アプリケーション保護におけるVBスクリプト対応 については注意が必要です。Windows Server 2025では、VBスクリプトがオンデマンド機能として提供されており、 有効化されている場合のみ動作 します。これに対応するため、LifeKeeper内の既存VBスクリプトは、 サポートされるスクリプト言語へと変換 されており、より安定した運用が可能となっています。 この対応により、 将来のOS環境でも継続的なHA運用が可能 となり、企業のITインフラの長期的な信頼性確保に貢献します。 ② 障害解析を効率化するクラッシュダンプ収集機能 LifeKeeper v8.11.0 では、 障害発生時のトラブルシューティングを支援する新機能 として、 LK Core プロセスのクラッシュダンプ収集機能 が追加されました。 この機能により、LK Core プロセスに異常が発生した際、 クラッシュダンプが自動的に %LKROOT%/SUPPORT/ProcessDumps フォルダーに出力 されるようになります。 収集の有効・無効は、設定ファイル %LKROOT%\etc\default\LifeKeeper に追加された変数 ENABLE_CRASH_DUMPS によって制御され、デフォルトでは収集が有効（1）となっています。 さらに、 lksupport 実行時にクラッシュダンプが存在する場合、それを自動で回収する機能 も追加されており、障害調査の効率化に貢献します。 設定変更後は、LifeKeeper の再起動または ConfigureDumps.pl ユーティリティの実行により反映されます。 この機能追加により、 障害発生時の原因特定が迅速かつ確実に行えるようになり、システムの信頼性と保守性が大幅に向上 します。 ③ ミラーボリューム上のページファイル作成を制限 DataKeeper v8.11.0 では、 ミラーボリューム上でのページファイル（仮想メモリファイル）の作成を制限する機能 が追加されました。 ページファイルは、Windows が物理メモリを補うために使用する重要なシステムファイルですが、 冗長化されたミラーボリューム上に配置されると、不要な読み書きが発生し、クラスタ全体のパフォーマンスに悪影響を及ぼす可能性 があります。 本バージョンでは、ページファイルの作成がミラーボリューム上で実行された場合でも、 再起動時にはその配置が無効化されるよう制御 されており、意図しない構成による性能低下を防止します。 この機能により、 高可用性クラスタ環境におけるストレージ運用の最適化 が図られ、より安定したシステムパフォーマンスの維持が可能となります。 ④ 最新プラットフォームへの対応拡充 LifeKeeper v8.11.0 では、 企業インフラの最新化を支援する新たなプラットフォーム対応 が追加されました。 まず、 VMware vSAN 8.0 （2025年8月認定）への対応により、仮想化環境での高可用性構成がさらに柔軟に。vSAN は、ストレージの集約と効率化を実現するソリューションであり、これにLifeKeeperが対応することで、 仮想化基盤上でも安定したHAクラスタ運用が可能 となります。 また、 OpenJDK v24.0.1 のサポート追加により、Javaベースの管理ツールやスクリプト環境においても、 最新のセキュリティパッチや機能を活用しながら安定運用が可能 となりました。 これらの対応は、 将来のインフラ拡張やセキュリティ強化を見据えた運用設計 において、企業にとって大きなメリットとなります。 バグ修正・機能強化：システムの安定性と運用性を向上 ここでは、多岐にわたるバグ修正および機能強化について、主な項目を一覧でご紹介します。 LifeKeeper for Windows v8.11.0 No 項目 内容 1 QSPリソースのローカルリカバリー設定に関する修正： QSP（Quick Service Protection）リソースを拡張した際に、プライマリーノードの設定に関わらずバックアップノードのローカルリカバリーが無効になってしまう問題を修正しました。 2 QSPリソースプロパティのタイムアウト表示修正： QSPリソースのプロパティ画面でタイムアウト値を修正する際のエラーダイアログに表示される上限値が誤っていたのを修正しました。 3 Oracleリソース拡張失敗の問題を修正： Oracleリソース拡張が失敗する問題を修正しました。 4 IISリソース：FTPサイト匿名認証無効時のrestore処理修正（deepCheck間隔0）： IISリソースでFTPサイトの匿名認証を無効にした際、deepCheck間隔を0にしていてもrestore処理に失敗する問題を修正しました。 5 IISリソース：FTPサイト匿名認証無効時のrestore処理修正（FTPログインスクリプト）： IISリソースでFTPサイトの匿名認証を無効にした際、FTPログインスクリプトを作成してもrestore処理に失敗する問題を修正しました。 6 Windows Server 2025でのコミュニケーションパス作成問題を修正： Windows Server 2025環境でコミュニケーションパスの作成ができなくなる問題を修正しました。 7 SQL ARKのスクリプトにおけるパスワード表示問題を修正： SQL Server Recovery Kitのrestoreおよびdeepchkスクリプトでset-xトレース出力にデータベースパスワードが表示されてしまう問題を修正しました。 8 IISリソース：FTPサイトSSL必須時のrestore処理修正： IISリソースでFTPサイトのSSLを必須にした際、restore処理に失敗する問題を修正しました。 9 Windows Server 2025でのwmic有効化問題を修正： Windows Server 2025環境でwmicコマンドが有効にならない問題を修正しました。 10 v8.10.1からのアップグレード中のgetlocks失敗問題を修正： v8.10.1からのLifeKeeperアップグレード中にgetlocksコマンドが失敗する問題を修正しました。 11 QSPリソース変更画面の表示修正： ローカルリカバリーが無効な場合でも、QSPリソースの変更画面で「有効」と誤って表示されるのを修正しました。 DataKeeper for Windows v8.11.0 No 項目 内容 1 DataKeeper共有ボリュームのI/Oフェンシングメカニズムの改善： DataKeeper共有ボリュームのI/Oフェンシングメカニズムを改善しました。 2 IRP_MJ_SHUTDOWN処理の改善： IoRegisterShutdownNotification呼び出しを削除してIRP_MJ_SHUTDOWN処理を改善しました。   スムーズな移行のために：LifeKeeper/DataKeeper アップグレード時の重要事項 LifeKeeper 関連製品のアップグレードを安全かつ確実に実行していただくため、以下の重要な注意点をご確認ください。 LifeKeeper for Windows v8.11.0 共有ストレージリソースとDataKeeperの連携  LifeKeeper for Windows v8.9.0 以降では、共有ストレージを使用した 共有ボリュームリソースの作成・管理に DataKeeper for Windows が必須 となりました。LifeKeeper for Windows v8.9.2 以降のインストーラーには、LifeKeeperとDataKeeperの両方が含まれています。 【補足】 DataKeeper for Windows のミラーリング機能（データ複製機能）を利用しない場合は、DataKeeper のライセンスは不要です。共有ストレージ経由での共有ボリュームリソースの管理に必要なモジュールとして DataKeeper が導入されます。 Perlバージョンの変更とカスタムPerlコードへの影響 LifeKeeper for Windows v8.10.1 以降、同梱されるPerlが Perl 5.32.1 にアップグレード されています。LifeKeeper for Linuxの場合と同様に、 カスタムで Perl コード（Generic ARK など）を使用している場合は、この Perl アップデートに対応するためのコード変更が必要 になる可能性があります。 【対応】 アップグレード前に、ご利用のカスタム Perl コードが新しい Perl バージョンで正しく動作するか、互換性を十分に検証してください。詳細については、「 Perl 5.8.8からPerl 5.32.1へのアップグレード 」ドキュメントをご参照ください。 ライセンス形態の変更と更新（非ノードロックライセンス）  LifeKeeper for Windows および DataKeeper for Windows（Application Recovery Kit など関連製品含む）は、v8.9.1から HostID に依存しない非ノードロックライセンス を提供しています。LifeKeeper v8.9.0 / DataKeeper v8.9.0 までのノードロックライセンスはそのまま使用可能ですが、 新しい非ノードロックライセンスへ切り替える場合は、アップデート後にライセンスの更新作業が必要となります。 【対応】 既存のライセンスを継続利用するか、非ノードロックライセンスへ更新するかを検討し、更新が必要な場合はアップデート後に所定の手順でライセンスを更新してください。 ダウンロードした製品の整合性確認 ダウンロードした製品ファイルの整合性を確認するために、 md5sum を使用することをお勧めします。 【コマンド例】 certutil -hashfile <file> MD5 このコマンドを実行すると、ダウンロードしたファイルの MD5 ハッシュ値が出力されますので、提供されている .md5 ファイルの内容と比較して、ファイルが破損していないことを確認してください。 8.10.1 以前からのアップデート時の注意点（ローリングアップデート） v8.10.1 以前のバージョンからアップデートする際に、 クラスター内の片方のノードだけをアップデートし、その状態でリソースを In-service にすると、イベントログに 「lcdwait.exe: -R option is required」 というメッセージが出力される場合があります。 【対応】 このメッセージは、もう片方のノードも同じバージョンにアップデートすることで出力されなくなります。これは、ローリングアップデート中に一時的に発生する可能性のある警告であり、両ノードのアップデートが完了すれば解消されます。 DataKeeper for Windows v8.11.0 ローリングアップデートのサポート DataKeeper for Windows v8.11.0 では、対象システムを切り替えて更新する ローリングアップデートがサポートされています。   【補足】  これにより、サービス停止時間を最小限に抑えながら、クラスター内のノードを順番にアップデートすることが可能です。具体的な手順については、公式ドキュメントを参照してください。 まとめ 今回は、LifeKeeper製品の最新バージョンに記載されている新機能、バグ修正/機能強化、そしてアップグレードの注意点についてご紹介いたしました。 ビジネス継続性を支える高可用性（HA）クラスターソフトウェアとして、LifeKeeperは常に進化を続けており、およそ半年に一度のペースでアップグレードを実施しています。 今後もLifeKeeperの新機能や改善点、対応環境の拡充など、皆さまがより堅牢で効率的なシステム運用を実現できるよう、LifeKeeperに関する情報発信を続けてまいります。 最後までお読みいただき、誠にありがとうございました。 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

AWS JAPAN APNブログにて、  2025 Japan AWS Ambassadors / 2025 Japan AWS Top Engineers / 2025 Japan AWS Jr. Champions の受賞者が発表されました。 本ブログではSCSKから選出された計10名の社員をご紹介します！ 2025 Japan AWS Ambassadors 「 2025 Japan AWS Ambassadors 」は、2024 Japan AWS Top Engineers のうち、卓越した技術力を持ち、社内外への情報発信やその深い専門知識を基に、アマゾン ウェブ サービス（AWS）のソリューションアーキテクトと協力してお客様のAWS導入・活用にあたり大きく貢献・支援したメンバーが選出されます。（各社最大2名まで） SCSKからは広野と木澤の2名が選出されました。 広野 祐司 ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 ITインフラサービス事業グループ ITインフラサービス事業グループ統括本部 人材マネジメント部 第一課 Ambassador 4 年目となりました。 私は社内クラウド技術者育成や、社外のお客様または社内のエンジニア向けの AWS 技術支援に従事しております。AWS サーバーレスサービス、React によるモダン Web アプリケーション開発が得意領域です。 社員向けクラウド学習用 e-Learning サイトの開発、コンテンツ作成をしながら、その e-Learning サイトを学習教材に仕立て、DevOps、CI/CD、アジャイルソフトウェア開発を体験できる研修も提供しております。 当社 AWS 認定資格数はちょうど節目の 3,000 を超えたところで、今はほっと一息ついています。近年は AI の台頭により、特にアプリケーション開発領域においてこれまで自分が行ってきた業務が AI に取って代わられる危機感を感じてきており、次のステップに進んでいかなければと感じているところです。 引き続き、自身の成長とお客様、社員の育成サイクルを回していきたいと思います。 よろしくお願いいたします。 ★ 広野のTechHarmony記事一覧は こちら   木澤 朋隆 ITインフラサービス事業グループ クラウドサービス事業本部 事業推進部 事業企画課 ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 2021年からA WS Ambassadorを拝命しており、私の活動方針として「クラウドに強いSCSKの実現」と「それをアウトプットすることによる当社のプレゼンス向上」を目標に活動しています。 立ち上げた本エンジニアブログTechHarmonyも記事数が1100を超え、当社にて自発的にアウトプットするエンジニアが増えていることを嬉しく思います。 私は新卒で入社以来、システム運用やWebシステム開発のインフラ構築で幅広い経験を積んでまいりました。 2013年にAWSの大規模構築案件を担当したことでクラウドサービスの将来性を感じ、2016年よりクラウド提供部署に異動して現在に至ります。 現在の業務は、マーケティングリーダーとして各種イベントの企画や運営・登壇、社内外向けの情報発信、クラウドアーキテクトとしての案件支援などを担当しております。   また、最近では各社Ambassadorとの繋がりを活かし、「豊洲会」などの交流イベントをリードしています。 今後もAWSエンジニアが楽しく自己研鑽でき、表彰を目指してスキルアップできるSCSKを目指して活動していこうと思います。 よろしくお願いします。 ★ 木澤のTechHarmony記事一覧は こちら   2025 Japan AWS Top Engineers 「 2025 Japan AWS Top Engineers 」は、AWSパートナーネットワーク(APN) 加入のAWSパートナー企業に所属し、AWSに関する高い技術力を発揮した活動を行ったメンバーが選出されます。 8つのカテゴリ（Services、Software、Networking、Security、Analytics、Database、Machine Learning、SAP on AWS）が用意されており、 SCSKからはServicesで広野/木澤/寺内/畑/福地の5名（※）、AI/ML Dataで安彦/丸山の2名、Nerworkingで貝塚の1名が選出されました。 ※広野/木澤は前項で紹介済みのため本項では割愛   ★ 2025 Japan AWS Top Engineers (Services) 寺内 康之 ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 昨年に引き続き、2025 Japan AWS Top Engineersに選出いただきました。とても嬉しく思います。 少年時代、8bitマイコンの頃からコンピュータと戯れてました。大人になり、気がつくと地球がネットワークで覆われて、知的活動の殆どがデジタルに置き換わり、AIが産声をあげています。 「十分に発達した科学技術は、魔法と区別がつかない」というクラーク先生の言葉を、手のひらの上のiPhoneに感じる今日この頃です。 複雑に高度化するITシステムは変化を続け、常にアップデートを余儀なくされています。 我々「テクニカルエスコートサービス」を提供するチームは、高いIT技術力を有し、お客様のAWS活用を幅広くご支援します。 アプリケーションから基盤およびネットワークなど、AWSの範疇に限らず相談を受け付ける総合IT技術支援サービスとなっております。 お気軽にお問い合わせください。 進化し続けるIT技術は、LLMというツールによりコンピュータと人間のインターフェースが大きく変わろうとしています。これからも増々楽しみな変化をAWSと共に体験していきたいと思います。 ★ 寺内 のTechHarmony記事一覧は こちら   畑 健治 ITインフラサービス事業グループ　クラウドサービス事業本部 ＡＩ＆クラウドソリューション部 第三課 新卒でSCSKに入社して以来、Oracle Database/MySQLを中心としたデータベースの設計構築やデータ移行に関連したプロジェクトに携わってきました。特に、組織として実績がないような高難度の技術・製品を担当することが多く、技術リードとして課題解決などに取り組んできました。 その役割とも相まって、近年ではAWSを初めとするクラウドサービス上のプロジェクトを中心に、データ活用サービスの開発や実プロジェクトにも携わっています。昨年度はその経験を活かし、サーバレスアーキテクチャによるデータメンテナンスアプリケーションの開発を担当する機会に恵まれました。これをきっかけに Top Engineers 申請にチャレンジした結果、2025 Japan AWS Top Engineers (Services) に選出頂くことができました。 選出頂いたことには正直驚きもありましたが、実プロジェクトにおいてサーバレスアーキテクチャを使用してアプリケーションを実装するという自分にとってのチャレンジの内容や そこから得た知識・経験と、今まで培ってきたデータベースやデータ活用関連の知見を総合的に評価頂けたのではないかと考えております。 今後もAWSの各種サービスを活用して幅広い領域にチャレンジしつつ、社内外へのAWSの普及や利用促進に繋がる情報発信を続けていければと考えております。最後に、このような機会を頂いた AWS 様ならびに今回の申請活動にご協力頂いた皆様に心より感謝申し上げます。 ★ 畑 のTechHarmony記事一覧は こちら   福地 孝哉 技術戦略本部 デジタル推進部 開発第二課 SCSKのクラウドサービス事業本部に配属され、Webシステムの運用保守からキャリアをスタートしました。 オンプレミスからクラウドへのマイグレーション、データ連携基盤やコンテンツ配信基盤などAWSを利用した基盤構築を担当してきました。 昨年のJapan AWS Jr. Championsに引き続き、今年Japan AWS Top Engineersに選出していただけたことは大変光栄であり、日々ご支援いただいている皆様に心より感謝申し上げます。今回の受賞にあたり、プロジェクトのリード経験・人材育成施策・そして技術イベントでの登壇等を高く評価いただきました。これらの活動を通じて得られた知見やネットワークを、今後さらに活かしていければと考えています。 現在は技術戦略本部に所属して、AIを利用したシステム開発を全社に適用していくために、先端技術を活用したサービス開発・研究・案件支援に従事しております。今期は特にBedrockをフル活用し、GenAIやAIエージェントを組み込んだシステム開発領域に力を入れていきます。 引き続き、AWSビジネスのさらなる発展に貢献できるよう、取り組んでまいりますのでどうぞよろしくお願いいたします。 ★ 福地 のTechHarmony記事一覧は こちら   ★ 2025 Japan AWS Top Engineers (AI/ML Data Engineer) 安彦 洋樹 ITインフラサービス事業グループ　クラウドサービス事業本部 ＡＩ＆クラウドソリューション部 第二課 SCSKに入社以来、アプリケーション開発する部署と基盤を構築する部署を渡り歩き、主にデータベーススペシャリストとして様々な大規模プロジェクトを経験してきました。 その中でオンプレ環境でDWHシステムを構築するプロジェクトも何度か経験しており、面白い領域だなぁと思っていたところ、2018年にAmazon Redshiftを中心とした顧客情報基盤構築プロジェクトでアーキテクトリーダを担当したことをきっかけに、AWSのAnalytics系のサービス(Amazon Redshift、Amazon QuickSight、AWS Glue等)を使ったデータ活用システム構築のプロジェクトを主に担当することになりました。 そこで培った経験を活かし、2023年には「クラウドデータ活用サービス」を開発し、そのサービスを使って現在はAWS様主催のセミナーに登壇させて頂いたり、 データ活用システムの構築プロジェクトを数多く推進しております。 このような活動をAWS様に評価頂き、昨年度「2024 Japan AWS Top Engineers (Analytics)」 に続き、今年度は「2025 Japan AWS Top Engineers (AI/ML Data Engineer)」に選出して頂きました。 これからも、AWSのAIやAnalytics系のサービスを活用して、お客様のDX推進やデータドリブン経営の実現に尽力していきたいと思います。 ★ 安彦 のTechHarmony記事一覧は こちら   丸山 祐佳 ITインフラサービス事業グループ　クラウドサービス事業本部　ＡＩ＆クラウドソリューション部　第三課 この度は、昨年、一昨年の2024 Japan AWS Top Engineers (Database)に続き、今年度新設の2025 Japan AWS Top Engineers (AI/ML Data Engineer)にも選出いただき大変光栄です。 私は、SCSKに入社以来、MySQLを中心としたDB技術者として、設計・構築をはじめ、サポートやチューニングサービス、研修講師などを担当していました。その後、当社ERPパッケージであるProActiveのデータベースをOracle DBからMySQLへ移行するプロジェクトをきっかけとし、AWS環境への異種DBマイグレーションサービスを立ち上げ、PostgreSQLやAmazon Auroraへの移行案件に携わり、現在に至ります。 今年3月には、ITX for MCP SCSK版 クラウドデータベースマイグレーション対応版をリリースしました。 1システムの異種DB移行の検討・実施だけにとどまらず、全社のデータベースすべての移行を支援するサービスに加え、移行後の最適化・目的別データベースへの変革・データ活用フェーズへの活用など、さらに幅広い分野を扱えるデータベースサービスとなっています。 このサービスは、異種データベース移行も含め、技術難易度やその複雑性から決して一人でできるものではなく、チームとして協力しあってこそ成功するサービスです。今回の選出についても、これまでの案件に携わってきた方々のおかげです。大変感謝申し上げます。 これからはさらにAIを活用し、AWS環境におけるDB分野のサービスを継続的に進化・拡大することで、今後もよりAWSの普及に寄与できるよう努めて参りたいと思います。 ★ 丸山 のTechHarmony記事一覧は こちら   ★ 2025 Japan AWS Top Engineers (Networking) 貝塚 広行 ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 Japan AWS Top Engineer (Networking)を今年も受賞でき、うれしく思います。 ネットワークエンジニアとしてオンプレ中心の時代から20年以上が経過し、 近年はAWSに活動の場を移してきましたが、自分のネットワークに関する知識を活かせる場面が多々あるのはありがたい限りです。 全体的な比重としてはサーバレスなどのクラウドネイティブな技術を扱うことが多くなってきましたが、多くのクラウド技術者のスキルがクラウドネイティブに傾斜している分、ネットワークまわりで頼られる機会は増えた気さえします。 現在は生成AI全盛の時代ですが、私自身もネットワークを含むインフラ基盤の要件定義から設計・構築・テストに至るまで、生成AIを活用してより効率的に、かつ高品質なシステムが作れるよう日々試行錯誤を重ねています。 この受賞を励みに、TechHarmonyでの記事投稿などを通じてAWSコミュニティにもより一層貢献できるよう努めてまいります。 ★ 貝塚 のTechHarmony記事一覧は こちら   2025 Japan AWS Jr. Champions 「 Japan AWS Jr. Champions 」は、APN加入のAWSパートナー企業に所属する社会人歴 1～3 年目で、AWSについて突出した活動実績がある若手エンジニアを対象とした、一昨年度より新設された日本独自の表彰制度です。 AWSを積極的に学び、アクションを起こし、周囲に影響を与えている若手エンジニアが選出されます。 SCSKからは間世田 と佐藤2名が選出されました。 2025 Japan AWS Jr. Champions　SCSKメンバー2名（左右） ※AWSでJr.Championsを主管するYukki(髙橋 敏行)さんと一緒に 間世田 秀 ITインフラサービス事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第二課 2023年に新卒で入社し、現在はAWS内製化支援サービス「 テクニカルエスコートサービス 」にてお客様のAWS活用をサポートさせていただいております。 チームには AWS、オンプレミス、アプリケーションなど各分野のエキスパートが在籍しており、日々多くの学びを得ながら業務に取り組んでいます。こうした環境で得た知識や経験を、TechHarmonyブログや勉強会での情報発信を通じて技術コミュニティに還元する活動を続けてきました。これらの取り組みが評価され、「2025 Japan AWS Jr. Champions」に選出していただけたのだと思います。 私は、先代・先々代が活躍している姿を見て「自分もこうなりたい」と思い、活動を続けてきました。今後は私自身が若手エンジニアの模範となるよう、さらなるアウトプットを通じて皆様への良い影響を与えられるよう挑戦していきたいです。我々の活動が同世代のエンジニアに広がり、そこから先輩・後輩との繋がりに発展していけば、「クラウドに強いSCSK」の実現に寄与できると信じています。 引き続き、AWS技術力向上および社内コミュニティ発展に尽力してまいります。   ★ 間世田 のTechHarmony記事一覧は こちら   佐藤 優音 製造事業グループ　ソリューション第一事業本部　コンサルティング第三部　第三課 2024年に新卒で入社いたしました。昨年9月より製造業のお客様向けにERPパッケージの導入・運用を行う部署に配属され、配属以来ERPパッケージのクラウド移行プロジェクトに従事しております。 私は業務でAWSを扱う部署に配属されていないため、入社以来自己研鑽としてAWSの学習を続けてまいりました。 その中で、「AWSの業務経験がないからこそ発信できることはないか」を常に意識して、社内外のイベント登壇やTechHarmonyでの発信、　勉強会の企画運営を行ってまいりました。これらの活動を評価いただき、この度2025 Japan AWS Jr. Champions に選出いただくことができました。 私は Jr. Champions に立候補した際、「AWS学習の敷居を下げ、より多くの人にAWSの可能性を広げられるような環境」を作りたいいう思いが強くありました。この環境を実現し、SCSK×AWS の可能性をより広げるためにできることを全力で取り組んでまいりますので、 よろしくお願いいたします！ ★ 佐藤 のTechHarmony記事一覧は こちら   最後に 2025 Japan AWS Ambassadors / 2025 Japan AWS Top Engineers / 2025 Japan AWS Jr. Champions に選出されたSCSK社員10名をご紹介しました。今回ご紹介した10名以外にもSCSKにはAWS認定資格取得者が多数在籍しております。 AWS導入・DX推進をお考えの方は、 ぜひSCSKにお気軽に お問い合わせ ください。 弊社の SCSKクラウドサービス（AWS） では AWS の導入から運用改善まで、お客様のAWS活用をご支援するサービスをご提供しております。 今後もお客様のAWS案件を強力にご支援出来るよう、技術力の向上や情報発信などの活動に努めてまいります。

今回は、AWS Config と AWS Security Hub を活用した統合的なセキュリティ監視を AWS CDK で実装する方法をまとめました。 はじめに 今回はをAWS CDKでAWS ConfigとSecurityHubを実装していきます。 また、EventBridgeでコンプライアンス違反を検知して入力トランスフォーマーでメール文を成型して通知します。 今回作成するリソース SNSトピック : セキュリティアラートの通知 S3バケット : AWS Config設定履歴の保存 IAMロール : AWS ConfigとSecurityHub実行権限 AWS Config : 全リソースの構成変更記録 AWS SecurityHub : セキュリティ基準チェック EventBridge : 脅威検知時の自動通知   アーキテクチャ概要   AWS CDK ソースコード SNS通知設定 const emailAddresses = [ // SNS通知先メーリングリスト(通知先が複数ある場合はアドレスを追加) 'xxxxxx@example.com', 'xxxxxx@example.com', ]; // SecurityHub用トピック const securityHubTopic = new sns.Topic(this, 'SecurityHubTopic', { topicName: 'securityhub-alertnotification', // トピック名 displayName: 'SecurityHub Alert Notifications' // 表示名 }); // SecurityHub用サブスクリプション emailAddresses.forEach(email => { securityHubTopic.addSubscription( new subscriptions.EmailSubscription(email) // プロトコル：EMAIL ); }); ポイント: 複数の管理者への通知配信 アラーム発生時に通知するメールアドレスを指定 S3バケット設定（Config履歴保存） const configBucket = new s3.Bucket(this, 'ConfigBucket', { bucketName: 's3b-config', // バケット名 blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, // パブリックアクセスをすべてブロック encryption: s3.BucketEncryption.S3_MANAGED, // 暗号化タイプ：SSE-S3 enforceSSL: true, // SSL通信を強制 autoDeleteObjects: true, // スタック削除時にオブジェクトを自動的に削除 ※デプロイ時にコメントアウト removalPolicy: cdk.RemovalPolicy.DESTROY, // スタック削除時にバケットも削除 ※デプロイ時にRETAINに修正 lifecycleRules: [ // ライフサイクルルール作成 { id: 'Expiration Rule 12 Months', // ライフサイクルルール名 expiration: cdk.Duration.days(366), // オブジェクトの現行バージョンの有効期限:366日後にオブジェクトを削除 } ] }); configBucket.addToResourcePolicy(new iam.PolicyStatement({ // バケットポリシー追加1 effect: iam.Effect.ALLOW, actions: [ 's3:GetBucketAcl', 's3:ListBucket' ], resources: [configBucket.bucketArn], principals: [new iam.ServicePrincipal('config.amazonaws.com')], conditions: { StringEquals: { 'aws:SourceAccount': cdk.Stack.of(this).account } } })); configBucket.addToResourcePolicy(new iam.PolicyStatement({ // バケットポリシー追加2 effect: iam.Effect.ALLOW, actions: [ 's3:PutObject' ], resources: [`${configBucket.bucketArn}/AWSLogs/${cdk.Stack.of(this).account}/Config/*`], principals: [new iam.ServicePrincipal('config.amazonaws.com')], conditions: { StringEquals: { 's3:x-amz-acl': 'bucket-owner-full-control', // バケット所有者にフルコントロールを付与 'aws:SourceAccount': cdk.Stack.of(this).account } } })); ポイント: セキュア設計 : パブリックアクセス完全ブロック、SSL強制 長期保存 : コンプライアンス要件に応じた1年間保持 適切な権限 : AWS Configサービスのみにアクセス許可 AWS Config設定 // サービスロール作成 const configServiceRole = new iam.CfnServiceLinkedRole(this, 'ConfigServiceLinkedRole', { // 既存のAWS Configサービスにリンクされたロール(Config実行に必要な権限を自動付与)※すでに付与されている場合はコメントアウトしてデプロイ awsServiceName: 'config.amazonaws.com', // サービス名 }); // レコーダーの作成 const accountId = cdk.Stack.of(this).account; const configRecorder = new config.CfnConfigurationRecorder(this, 'Recorder', { roleArn: `arn:aws:iam::${accountId}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig`, // ConfigのIAMロール(Configがリソースの設定変更を記録する権限) recordingGroup: { // 記録対象の設定 allSupported: true, // サポートされている全リソースタイプを記録 includeGlobalResourceTypes: true, // グローバルリソースも記録対象に含める } }); // 配信チャネルの作成 const configDeliveryChannel = new config.CfnDeliveryChannel(this, 'DeliveryChannel', { // s3BucketName: configBucket.bucketName, // Config用のバケット configSnapshotDeliveryProperties: { // deliveryFrequency: 'TwentyFour_Hours' // スナップショットを24時間(1日)ごとにS3バケットへ配信 } }); ポイント: 包括的記録 : 全サポートリソースの構成変更を記録 グローバルリソース対応 : IAM、CloudFrontなども監視対象 定期スナップショット : 24時間ごとの設定状況保存 サービスリンクロール : AWS Config専用の権限で実行 AWS SecurityHub設定 // AWS基礎セキュリティのベストプラクティスv1.0.0 / CISAWSFoundationsBenchmarkv1.2.0 有効化 const securityHub = new securityhub.CfnHub(this, 'SecurityHub', { enableDefaultStandards: true, // デフォルトのセキュリティ基準を有効化 controlFindingGenerator: 'SECURITY_CONTROL', // セキュリティ管理ベースの検出 }); ポイント: AWS Foundational Security Standard : AWSベストプラクティス基準 CIS AWS Foundations Benchmark v1.2.0 : 業界標準セキュリティ基準 自動検出 : セキュリティコントロール違反の自動検知 EventBridge設定 // SecurityHub用ルール const securityHubRule = new events.Rule(this, 'SecurityHubEventRule', { ruleName: 'eventbridge-rule-securityhub', // ルール名 eventPattern: { // イベントパターンを指定 source: ['aws.securityhub'], detailType: ['Security Hub Findings - Imported'], // SecurityHubによって検出された結果（Findings）がインポートされた際に発行されるイベント detail: { findings: { Compliance: { // コンプライアンスステータスがFAILEDかどうか Status: ['FAILED'] // FAILED：セキュリティポリシーやコンプライアンス要件を満たさない検出結果 }, Severity: { Label: ['HIGH', 'CRITICAL'] // 重要度がHIGH,CRITICALかどうか }, Workflow: { // ワークフローステータスがNEWかどうか Status: ['NEW'] // NEW：まだ調査や対応が行われていない新しい検出結果 } } } }, }); // 入力パスマップ（InputPathsMap） const inputPathsMap: { [key: string]: string } = { accountId: '$.detail.findings[0].AwsAccountId', description: '$.detail.findings[0].Description', resourceId: '$.detail.findings[0].Resources[0].Id', securityControlId: '$.detail.findings[0].Compliance.SecurityControlId', severity: '$.detail.findings[0].Severity.Label', title: '$.detail.findings[0].Title', }; const inputTemplate = "\"アカウントID： の SecurityHub でイベント検知がありました。\"\n\"検知内容を確認し、対応をお願いします。\"\n\n\"タイトル: [] const cfnRule = securityHubRule.node.defaultChild as events.CfnRule; cfnRule.addPropertyOverride('Targets', [ { Arn: securityHubTopic.topicArn, // SNSトピックARN Id: 'SecurityHubTopicTarget', // ターゲットID InputTransformer: { // 入力トランスフォーマー InputPathsMap: inputPathsMap, InputTemplate: inputTemplate, }, }, ]); // SNS Topic ポリシー（EventBridge からの Publish を許可） securityHubTopic.addToResourcePolicy(new iam.PolicyStatement({ sid: 'AllowEventBridgePublish', // ステートメントID effect: iam.Effect.ALLOW, // 許可 principals: [new iam.ServicePrincipal('events.amazonaws.com')], // EventBridgeサービスプリンシパル actions: ['sns:Publish'], // Publish権限 resources: [securityHubTopic.topicArn], // 対象トピック conditions: { // ルールARNに限定 ArnEquals: { 'aws:SourceArn': securityHubRule.ruleArn } } })); ポイント: フィルタリング : HIGH/CRITICAL重要度の新規違反のみ通知 Input Transformer : Lambdaなしで通知内容を整形 詳細情報 : アカウントID、リソースID、違反内容を自動抽出 セキュア通知 : 特定のEventBridgeルールからのみPublish許可 脅威検知フローと通知内容 検知フロー リソース変更検知 : AWS Configがリソース構成変更を記録 セキュリティチェック : SecurityHubが設定基準に照合 違反検出 : コンプライアンス違反やセキュリティ脅威を特定 フィルタリング : EventBridgeが重要度・ステータスでフィルタ 通知送信 : 入力トランスフォーマーで整形してSNS経由でメール通知 通知メール例 アカウントID：123456789012 の SecurityHub でイベント検知がありました。 検知内容を確認し、対応をお願いします。 タイトル: [EC2.2] VPC default security group should not allow inbound and outbound traffic 重大度: HIGH 対象リソース: arn:aws:ec2:ap-northeast-1:123456789012:security-group/sg-12345678 説明: This AWS control checks whether the default security group of any VPC restricts all traffic.   今回実装したコンストラクトファイルまとめ import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as sns from 'aws-cdk-lib/aws-sns'; import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions'; import * as s3 from 'aws-cdk-lib/aws-s3'; import * as iam from 'aws-cdk-lib/aws-iam'; import * as config from 'aws-cdk-lib/aws-config'; import * as securityhub from 'aws-cdk-lib/aws-securityhub'; import * as events from 'aws-cdk-lib/aws-events'; import * as targets from 'aws-cdk-lib/aws-events-targets'; export interface SecurityConstructProps { // 必要に応じて追加のプロパティを定義 } export class SecurityConstruct extends Construct { constructor(scope: Construct, id: string, props?: SecurityConstructProps) { super(scope, id); //=========================================== // SNS //=========================================== const emailAddresses = [ // SNS通知先メーリングリスト(通知先が複数ある場合はアドレスを追加) 'xxxxxx@example.com', 'xxxxxx@example.com', ]; // SecurityHub用トピック const securityHubTopic = new sns.Topic(this, 'SecurityHubTopic', { topicName: 'securityhub-alertnotification', // トピック名 displayName: 'SecurityHub Alert Notifications' // 表示名 }); // SecurityHub用サブスクリプション emailAddresses.forEach(email => { securityHubTopic.addSubscription( new subscriptions.EmailSubscription(email) // プロトコル：EMAIL ); }); //=========================================== // S3 //=========================================== // Config用S3バケット const configBucket = new s3.Bucket(this, 'ConfigBucket', { bucketName: 's3b-config', // バケット名 blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, // パブリックアクセスをすべてブロック encryption: s3.BucketEncryption.S3_MANAGED, // 暗号化タイプ：SSE-S3 enforceSSL: true, // SSL通信を強制 autoDeleteObjects: true, // スタック削除時にオブジェクトを自動的に削除 ※デプロイ時にコメントアウト removalPolicy: cdk.RemovalPolicy.DESTROY, // スタック削除時にバケットも削除 ※デプロイ時にRETAINに修正 lifecycleRules: [ // ライフサイクルルール作成 { id: 'Expiration Rule 12 Months', // ライフサイクルルール名 expiration: cdk.Duration.days(366), // オブジェクトの現行バージョンの有効期限:366日後にオブジェクトを削除 } ] }); configBucket.addToResourcePolicy(new iam.PolicyStatement({ // バケットポリシー追加1 effect: iam.Effect.ALLOW, actions: [ 's3:GetBucketAcl', 's3:ListBucket' ], resources: [configBucket.bucketArn], principals: [new iam.ServicePrincipal('config.amazonaws.com')], conditions: { StringEquals: { 'aws:SourceAccount': cdk.Stack.of(this).account } } })); configBucket.addToResourcePolicy(new iam.PolicyStatement({ // バケットポリシー追加2 effect: iam.Effect.ALLOW, actions: [ 's3:PutObject' ], resources: [`${configBucket.bucketArn}/AWSLogs/${cdk.Stack.of(this).account}/Config/*`], principals: [new iam.ServicePrincipal('config.amazonaws.com')], conditions: { StringEquals: { 's3:x-amz-acl': 'bucket-owner-full-control', // バケット所有者にフルコントロールを付与 'aws:SourceAccount': cdk.Stack.of(this).account } } })); //=========================================== // Config //=========================================== // サービスロール作成 const configServiceRole = new iam.CfnServiceLinkedRole(this, 'ConfigServiceLinkedRole', { // 既存のAWS Configサービスにリンクされたロール(Config実行に必要な権限を自動付与)※すでに付与されている場合はコメントアウトしてデプロイ awsServiceName: 'config.amazonaws.com', // サービス名 }); // レコーダーの作成 const accountId = cdk.Stack.of(this).account; const configRecorder = new config.CfnConfigurationRecorder(this, 'Recorder', { roleArn: `arn:aws:iam::${accountId}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig`, // ConfigのIAMロール(Configがリソースの設定変更を記録する権限) recordingGroup: { // 記録対象の設定 allSupported: true, // サポートされている全リソースタイプを記録 includeGlobalResourceTypes: true, // グローバルリソースも記録対象に含める } }); // 配信チャネルの作成 const configDeliveryChannel = new config.CfnDeliveryChannel(this, 'DeliveryChannel', { // s3BucketName: configBucket.bucketName, // Config用のバケット configSnapshotDeliveryProperties: { // deliveryFrequency: 'TwentyFour_Hours' // スナップショットを24時間(1日)ごとにS3バケットへ配信 } }); //=========================================== // SecurityHub //=========================================== // AWS基礎セキュリティのベストプラクティスv1.0.0 / CISAWSFoundationsBenchmarkv1.2.0 有効化 const securityHub = new securityhub.CfnHub(this, 'SecurityHub', { enableDefaultStandards: true, // デフォルトのセキュリティ基準を有効化 controlFindingGenerator: 'SECURITY_CONTROL', // セキュリティ管理ベースの検出 }); //=========================================== // EventBridge //=========================================== // SecurityHub用ルール const securityHubRule = new events.Rule(this, 'SecurityHubEventRule', { ruleName: 'eventbridge-rule-securityhub', // ルール名 eventPattern: { // イベントパターンを指定 source: ['aws.securityhub'], detailType: ['Security Hub Findings - Imported'], // SecurityHubによって検出された結果（Findings）がインポートされた際に発行されるイベント detail: { findings: { Compliance: { // コンプライアンスステータスがFAILEDかどうか Status: ['FAILED'] // FAILED：セキュリティポリシーやコンプライアンス要件を満たさない検出結果 }, Severity: { Label: ['HIGH', 'CRITICAL'] // 重要度がHIGH,CRITICALかどうか }, Workflow: { // ワークフローステータスがNEWかどうか Status: ['NEW'] // NEW：まだ調査や対応が行われていない新しい検出結果 } } } }, }); // 入力パスマップ（InputPathsMap） const inputPathsMap: { [key: string]: string } = { accountId: '$.detail.findings[0].AwsAccountId', description: '$.detail.findings[0].Description', resourceId: '$.detail.findings[0].Resources[0].Id', securityControlId: '$.detail.findings[0].Compliance.SecurityControlId', severity: '$.detail.findings[0].Severity.Label', title: '$.detail.findings[0].Title', }; const inputTemplate = "\"アカウントID： の SecurityHub でイベント検知がありました。\"\n\"検知内容を確認し、対応をお願いします。\"\n\n\"タイトル: [] const cfnRule = securityHubRule.node.defaultChild as events.CfnRule; cfnRule.addPropertyOverride('Targets', [ { Arn: securityHubTopic.topicArn, // SNSトピックARN Id: 'SecurityHubTopicTarget', // ターゲットID InputTransformer: { // 入力トランスフォーマー InputPathsMap: inputPathsMap, InputTemplate: inputTemplate, }, }, ]); // SNS Topic ポリシー（EventBridge からの Publish を許可） securityHubTopic.addToResourcePolicy(new iam.PolicyStatement({ sid: 'AllowEventBridgePublish', // ステートメントID effect: iam.Effect.ALLOW, // 許可 principals: [new iam.ServicePrincipal('events.amazonaws.com')], // EventBridgeサービスプリンシパル actions: ['sns:Publish'], // Publish権限 resources: [securityHubTopic.topicArn], // 対象トピック conditions: { // ルールARNに限定 ArnEquals: { 'aws:SourceArn': securityHubRule.ruleArn } } })); } } まとめ 今回は、AWS ConfigとSecurityHubを活用したセキュリティ監視をAWS CDKで実装しました。 IaCとして管理することで、環境間での一貫したセキュリティポリシーの展開や、セキュリティ設定の変更履歴管理も可能になります。また、継続的なコンプライアンス監視により、セキュリティガバナンスの向上と監査対応の効率化を実現できます。 皆さんのお役に立てれば幸いです。

はじめに Prisma Cloudではコンソールから取得できるデータがいくつかあり、アラートデータもそのひとつです。 日々大量に発生するアラートの中から、本当に注視すべきリスクや傾向を読み解くのは容易ではありません。手動での確認には限界があり、セキュリティ運用の非効率さにも繋がりかねません。 今回は、Prisma Cloudで検知されたアラートデータを取得して、クラウド環境のアラート状況をわかりやすく可視化できないか試してみました。 取得データの紹介 まず、アラートデータはPrisma Cloudコンソールの「アラート画面」の「csvファイルをダウンロード」から取得できます。 csvファイルに記載されているカラムは以下22項目です。 No. カラム 説明 1 Alert ID アラートに割り当てられた一意の識別子 2 Policy Name アラートをトリガーしたポリシーの名前 3 Policy Type ポリシーのタイプ（ CSPMを利用した際に主に利用されるタイプは iam, config, networkなど） 4 Description アラートが何を意味するのか、なぜトリガーされたのかについての詳細な説明 5 Policy Labels ポリシーに関連付けられたカスタムラベルまたはタグ 6 Policy Severity アラートの重大度レベル（Critical, High, Medium, Low, Informationalの5段階） 7 Resource Name アラートに関係するクラウドリソースの名前 8 Cloud Type クラウド環境の種類（例：AWS, Azure, GCP, Alibaba Cloud） 9 Cloud Account Id リソースが存在するクラウドアカウントのID 10 Cloud Account Name クラウドアカウント名 11 Region クラウドリソースが配置されているリージョン 12 Recommendation アラートをトリガーした問題を解決するための推奨されるアクション 13 Alert Status アラートの現在のステータス（例：Open, Dismissed, Resolved） 14 Alert Time アラートが生成されたタイムスタンプ 15 Event Occurred アラートをトリガーしたイベントが実際に発生したタイムスタンプ 16 Dismissed On アラートが無視されたタイムスタンプ 17 Dismissed By アラートをDismissed処理したユーザー 18 Dismissal Reason アラートをDismissedした理由 19 Resolved On アラートが解決済みとしてマークされたタイムスタンプ 20 Resolution Reason アラートを解決した理由 21 Resource ID アラートに関係するクラウドリソースの一意の識別子 22 Account Groups そのクラウドアカウントが属するPrisma Cloudのアカウントグループ 今回はこの中から「Policy Type」、「Policy Severity」、「Cloud Account Id」を使用していきます。   可視化の準備：分析シナリオと仮想データの作成 今回は実際のアラート情報ではなく、仮想的なアラートデータを作成し、どのように可視化分析ができるかご紹介します。 可視化分析をするにあたって3つのそれぞれ状況の違うクラウドアカウントのアラート状況を用意しました。以下簡単な説明です。 Cloud Account ID 説明 1 全体的に多くのアラートが検知されているものの、ほとんどが「informational」や「low」の重要度であり、criticalやhighは少ない。様々なPolicy Typeでアラートがタイプ毎に似たような分布。 2 network や iam といったごく特定のPolicy Typeに「critical」アラートが極めて集中している。他のSeverityのアラートも存在するが、リスクの焦点は明確な領域に集中している。 3 特定のPolicy Typeにアラートが極端に偏って集中している。この集中しているPolicy Type内では、「medium」や「high」のSeverityのアラートが多く検出されている。   各クラウド環境の具体的なデータは以下の通りです。 左列の「Policy Type」と、上段の「Policy Severity」の組み合わせごとに、発生したアラートの件数を示しています。 Cloud Account ID=1 informational low medium high critical iam 30 25 10 2 0 config 28 22 8 1 0 network 32 20 12 3 0 anomaly 30 18 5 0 0   Cloud Account ID=2 informational low medium high critical iam 5 3 8 15 50 config 10 7 5 3 1 network 7 5 10 20 45 anomaly 2 1 0 0 0     Cloud Account ID=3 informational low medium high critical iam 5 10 40 35 5 config 3 5 8 2 0 network 1 0 2 1 0 anomaly 0 0 0 0 0   Pythonによるデータ分析と可視化の実装 今回のPrisma Cloudアラートデータの可視化分析にはPythonを使用しました。 主な利用ライブラリは、データの読み込みや加工を行うpandas、そしてグラフ描画を担当するmatplotlibです。 処理の概要 読み込んだアラートデータの「Policy Severity」（重要度）を数値に変換するスコアリング処理を行います。これにより、例えば「critical」なアラートは「5点」、「informational」なアラートは「1点」といった形で、重要度を数値として扱えるようになります。 具体的には、以下のように変換しています。 critical: 5点 high: 4点 medium: 3点 low: 2点 informational: 1点 このスコアを使って、各「Cloud Account Id」（クラウドアカウント）ごとに、「Policy Type」別のアラート数を集計し、さらに重要度の平均値を算出しています。 そして、これらの集計結果をもとに、各クラウドアカウントごとに「バブルチャート」を生成します。 このバブルチャートでは、以下の要素で構成されます。 横軸 : そのポリシータイプで発生したアラートの総数。右に行くほどアラートが多いことを示します。 縦軸 : そのポリシータイプにおけるアラートの平均的な重要度スコア。上に行くほど平均重要度が高いことを示します。 バブルの大きさ : 発生したアラートの総数が多いほど、バブルが大きくなります。 バブルの色 : 同様に可読性を上げるため、平均重要度が高いほど、バブルの色が濃い赤色に変化します。 バブル内のテキスト : 各バブルの中には、それがどの「Policy Type」に属するかの名前が表示されます。 このバブルチャートを見ることで、「どのクラウドアカウントで、どのポリシータイプのアラートが、どれくらいの量と重要度で発生しているのか」を一目で把握できるようになります。例えば、「ネットワーク関連のアラートが非常に多く、かつ重要度も高い」といったクラウド環境のアラート状況を視覚的に理解できます。   結果の表示 前述のPythonコードで処理したバブルチャートを実際に表示すると以下のようになります。 このグラフを見ることで、各クラウドアカウントにおいて、どのようなポリシータイプのアラートが、どれくらいの量と重要度で発生しているのかを一目で把握できます。 Cloud Account ID：1 全体的に重要度の低いアラートが検知されていることが読み取れます。また、networkとiam(右の方で重なって表示されています)ポリシータイプのアラート件数が70程度とほぼ同数で最も多く検知されていることが読み取れます。   Cloud Account ID：2 networkとiamで際立って重要度の高いアラートが多く検出されていることが見て取れます。 Cloud Account ID：3 anomalyアラートが検出されずiamに偏ってアラートが検出されていることが見て取れます。 まとめ 今回はPrisma Cloudのアラートデータ（今回は仮想データを使用）をPythonで処理し、ポリシータイプごとのアラート数と平均重要度を示すバブルチャートを作成しました。 バブルチャートはどのポリシータイプにアラートが集中し、かつ平均重要度が高いのかを直感的に捉え、セキュリティ対応の優先順位付けの際の一つの判断材料にできるのではないかと考えました。 このように一次データを処理することで、膨大なアラート情報を可視化しクラウド環境の全体的なセキュリティ状況を感覚的に把握する手助けになるのではないでしょうか。 今回紹介した手法は一例であり、データの性質や分析目的によっては、さらに多様な可視化や分析手法が存在します。また、スコアリングの算出方法などの改善点も考えられます。今後もPrisma Cloudから取得できるデータのさらなる活用方法について、試行錯誤し結果を発信していければと考えております。 また、当社では、Prisma Cloudを利用して複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。ご興味のある方はお気軽にお問い合わせください。リンクはこちら↓ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

今回は、AWS Backup サービスによる EC2、EBS、RDSなどの自動バックアップと通知をAWS CDKで実装する方法をまとめました。 はじめに 今回は、AWS Backupサービスを使用して、EC2インスタンスやEBS、RDSなどのリソースの自動バックアップとバックアップ結果通知の仕組みをAWS CDKでコード化していきます。タグベースでバックアップ対象を柔軟に制御し、日次・週次・月次の異なるスケジュールでバックアップを実行します。  今回作成するリソース – SNSトピック: バックアップ実行結果の通知 – IAMロール: AWS Backup実行専用ロール – Backup Vault: バックアップデータの安全な保存場所 – Backup Plan: 日次の自動バックアップスケジュール – Backup Selection: タグベースでのバックアップ対象リソース選択 アーキテクチャ概要   AWS CDK ソースコード   SNS設定   const emailAddresses = [                                                                            // SNS通知先メーリングリスト     'xxxxxx@example.com',     'xxxxxxx@example.com'     ];   const backupNotificationTopic = new sns.Topic(this, 'BackupNotificationTopic', {                    // バックアップ監視用のトピック     topicName: 'backup-notification-topic',                                                           // トピック名     displayName: 'AWS Backup Notification Topic'                                                      // 表示名     });   emailAddresses.forEach(email => {                                                                   // バックアップ監視用のサブスクリプション       backupNotificationTopic.addSubscription(       new subscriptions.EmailSubscription(email)     );     }); ポイント: 複数の管理者アドレスに通知可能 バックアップジョブの完了・失敗を即座に通知するためのSNS IAMロール設定   const backupRole = new iam.Role(this, 'BackupRole', {     roleName: 'backup-role',                                                                                  // バックアップロール名     assumedBy: new iam.ServicePrincipal('backup.amazonaws.com'),                                              // AWS Backupサービスが引き受け     managedPolicies: [                                                                                        // マネージドポリシー       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSBackupServiceRolePolicyForBackup'),         // バックアップ用マネージドポリシー       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSBackupServiceRolePolicyForRestores'),       // リストア用マネージドポリシー     ]     });     ポイント: AWS Backupサービス専用のロール バックアップとリストア両方の権限を付与 Backup Vault設定   const backupVault = new backup.BackupVault(this, 'BackupVault', {                              // バックアップボールトの作成     backupVaultName: 'backup-vault',                                                             // バックアップボールト名     notificationTopic: backupNotificationTopic,                                                  // バックアップ監視用SNSトピック     notificationEvents: [                                                                        // 通知イベント       backup.BackupVaultEvents.BACKUP_JOB_COMPLETED,                                             // バックアップジョブ完了     ],     removalPolicy: cdk.RemovalPolicy.DESTROY                                                     // スタック削除時にボールトを削除     }); ポイント: バックアップデータの暗号化保存 SNS通知と連携 バックアップジョブ完了時の自動通知 リリース完了後RemovalPolicy.RETAIN に変更推奨 Backup Plan設定(日次)   const dailyBackupPlan = new backup.BackupPlan(this, 'DailyBackupPlan', {     backupPlanName: 'daily-backup-plan',                                                       // バックアッププラン名     backupPlanRules: [                                                                         // バックアップルール作成       new backup.BackupPlanRule({         ruleName: 'daily-backup-rule',                                                         // バックアップルール名         backupVault: backupVault,                                                              // バックアップボールトを指定         scheduleExpressionTimezone: TimeZone.ASIA_TOKYO,                                       // 実行スケジュールのタイムゾーンを指定：JST         scheduleExpression: events.Schedule.cron({                                             // 実行スケジュール（毎日2:00 JST）           hour: '2',           minute: '00',           day: '*',           month: '*',           year: '*'         }),         startWindow: cdk.Duration.hours(1),                                                    // 次の時間以内に開始：1時間         completionWindow: cdk.Duration.hours(2),                                               // 次の時間以内に完了：2時間         deleteAfter: cdk.Duration.days(1)                                                      // 保持期間：1日       })     ]   }); ポイント: タイムゾーン : すべて Asia/Tokyo （JST）で統一 スケジュール : 日次: 毎日 2:00 JST 実行時間 : 1時間以内開始、2時間以内完了 保持期間 : 要件に応じて調整可能（コードは1日設定） Backup Selection設定(日次)   const dailyBackupResource = new backup.CfnBackupSelection(this, 'DailyBackupResource', {                           backupPlanId: dailyBackupPlan.backupPlanId,                                                 // バックアッププランを指定     backupSelection: {       iamRoleArn: backupRole.roleArn,                                                           // IAMロールを指定       selectionName: 'daily-backup-resource',                                                   // リソース割り当て名       resources: ['arn:aws:ec2:*:*:instance/*'],                                                // 特定のリソースタイプを含める：EC2のすべてのインスタンス       conditions: {                                                                             // タグを使用して選択を絞り込む         StringEquals: [{                                                                        // 次と等しい           ConditionKey: 'aws:ResourceTag/BackupScheduleDaily',                                  // キー           ConditionValue: 'True'                                                                // 値         }]       }     }   }); ポイント: タグベース選択 : 柔軟なリソース管理 必要なタグ : 日次:  BackupScheduleDaily: True 対象リソース : EC2インスタンス 動作フロー スケジュール開始 : 設定されたCronスケジュールに従ってバックアップ開始 タグチェック : 対象リソースのタグを確認し、バックアップ対象を特定 バックアップ実行 : AWS Backupサービスがバックアップを自動実行 結果通知 : SNSトピック経由でメール通知 ライフサイクル管理 : 保持期間満了後の自動削除 今回実装したコンストラクトファイルまとめ   import * as cdk from 'aws-cdk-lib'; import { TimeZone } from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as backup from 'aws-cdk-lib/aws-backup'; import * as iam from 'aws-cdk-lib/aws-iam'; import * as events from 'aws-cdk-lib/aws-events'; import * as sns from 'aws-cdk-lib/aws-sns'; import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions'; export interface BackupConstructProps { // 必要に応じて追加のプロパティを定義 } export class BackupConstruct extends Construct { constructor(scope: Construct, id: string, props?: BackupConstructProps) { super(scope, id); //=========================================== // バックアップ監視用SNSトピック作成 //=========================================== const emailAddresses = [ // SNS通知先メーリングリスト 'xxxxxx@example.com', 'xxxxxxx@example.com' ]; const backupNotificationTopic = new sns.Topic(this, 'BackupNotificationTopic', { // バックアップ監視用のトピック topicName: 'backup-notification-topic', // トピック名 displayName: 'AWS Backup Notification Topic' // 表示名 }); emailAddresses.forEach(email => { // バックアップ監視用のサブスクリプション backupNotificationTopic.addSubscription( new subscriptions.EmailSubscription(email) ); }); //=========================================== // バックアップ用IAMロール作成 //=========================================== const backupRole = new iam.Role(this, 'BackupRole', { roleName: 'backup-role', // バックアップロール名 assumedBy: new iam.ServicePrincipal('backup.amazonaws.com'), // AWS Backupサービスが引き受け managedPolicies: [ // マネージドポリシー iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSBackupServiceRolePolicyForBackup'), // バックアップ用マネージドポリシー iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSBackupServiceRolePolicyForRestores'), // リストア用マネージドポリシー ] }); //=========================================== // AWS Backup作成 //=========================================== // バックアップボールトの作成 const backupVault = new backup.BackupVault(this, 'BackupVault', { // バックアップボールトの作成 backupVaultName: 'backup-vault', // バックアップボールト名 notificationTopic: backupNotificationTopic, // バックアップ監視用SNSトピック notificationEvents: [ // 通知イベント backup.BackupVaultEvents.BACKUP_JOB_COMPLETED, // バックアップジョブ完了 ], removalPolicy: cdk.RemovalPolicy.DESTROY // スタック削除時にボールトを削除 }); // 要件に合わせてバックアッププランを選択する // 日次バックアッププランの作成 const dailyBackupPlan = new backup.BackupPlan(this, 'DailyBackupPlan', { backupPlanName: 'daily-backup-plan', // バックアッププラン名 backupPlanRules: [ // バックアップルール作成 new backup.BackupPlanRule({ ruleName: 'daily-backup-rule', // バックアップルール名 backupVault: backupVault, // バックアップボールトを指定 scheduleExpressionTimezone: TimeZone.ASIA_TOKYO, // 実行スケジュールのタイムゾーンを指定：JST scheduleExpression: events.Schedule.cron({ // 実行スケジュール（毎日2:00 JST） hour: '2', minute: '00', day: '*', month: '*', year: '*' }), startWindow: cdk.Duration.hours(1), // 次の時間以内に開始：1時間 completionWindow: cdk.Duration.hours(2), // 次の時間以内に完了：2時間 deleteAfter: cdk.Duration.days(1) // 保持期間：1日 }) ] }); // 日次バックアップのリソース割り当て const dailyBackupResource = new backup.CfnBackupSelection(this, 'DailyBackupResource', { backupPlanId: dailyBackupPlan.backupPlanId, // バックアッププランを指定 backupSelection: { iamRoleArn: backupRole.roleArn, // IAMロールを指定 selectionName: 'daily-backup-resource', // リソース割り当て名 resources: ['arn:aws:ec2:*:*:instance/*'], // 特定のリソースタイプを含める：EC2のすべてのインスタンス conditions: { // タグを使用して選択を絞り込む StringEquals: [{ // 次と等しい ConditionKey: 'aws:ResourceTag/BackupScheduleDaily', // キー ConditionValue: 'True' // 値 }] } } }); } } }); まとめ 今回は、AWS Backupサービスを使用した包括的なバックアップソリューションをAWS CDKで実装しました。 IaCとして管理することで、環境間での一貫したバックアップポリシーの展開や、設定変更の履歴管理も可能になります。 コンプライアンス要件に応じた保持期間の調整や、運用時間に合わせたスケジュール変更も容易に行えます。 皆さんのお役に立てば幸いです。

こんにちは！ Catoクラウド 技術担当の中川です。 この記事では、2025年8月にリリースされた新機能「 XOps 」についてご紹介します！ 概要 XOpsとは？ XOpsは「 XDRとAIOpsを統合し、セキュリティ及び運用上のインシデントを効率的に検出する機能 」です。 従来のXDR Pro（Extended Detection and Response）の機能を進化させたもので、AIと自動化を活用し、セキュリティとネットワークの大量のイベントが整理された状態で 可視化・分析 できるのが特徴です。 前身のXDRについては、下記の記事をご参考ください。 Cato クラウドの XDR 活用に向けた初めの一歩 – TechHarmony CMAでのXOps それでは早速XOpsを有効にすると、何ができるようになるのかCMAで見ていきます。 まずXOpsの機能を有効にすると、Home＞Detection & Responseのタブ内にある、以下の3つのページが表示されるようになります。 Stories Overview Stories Workbench Detection & Response Policy Stories Overview XOpsでは検知したインシデントを「 ストーリー 」と呼びます。 Overviewでは、Criticalityが高いストーリー Top5、送信元ユーザ・拠点 Top5、Criticalityの割合など、 ストーリーの傾向を一目で確認できるページです。 Stories Workbench Workbenchは発生したストーリーを一覧で確認できるページです。 Overviewでは概要レベルのため、セキュリティ担当者が実際に利用するのはWorkBenchとお考え下さい。 ストーリーをクリックすると、詳細画面に遷移します。ストーリーの画面は後程解説します。 画面構成のポイント ストーリー一覧は、以下の列で構成されています。 Merged / SOC / NOC （画面右上）：ストーリーの大分類として、SOC（セキュリティ関連）とNOC（ネットワーク関連）に分かれます。デフォルト画面は、SOCとNOCを統合した状態 Mergedで表示されています。 Criticality ：High(10~7) / Medium(6~4) / Low(3~1) の3段階。上の画像はCriticality順 Indication ：ストーリー名 Source ：送信元のSite・ユーザ Producer ：ストーリーの生成元となった分析エンジン、次の表でご説明します Status ：ストーリー生成された際はOpen状態。運用担当者の調査後、対応完了したらClosedに変更しストーリー管理するイメージ Producerの分類と役割 SOC/NOC Producer 概要 SOC Threat Prevention IPSやAnti-Malwareなどのセキュリティイベントで、攻撃をリアルタイムに検出 Threat Hunting 過去のトラフィックデータを分析し、潜在的な脅威を検出 Usage Anomaly UEBA（ユーザの行動分析）に基づき、ユーザーやサイトの不審なネットワーク利用状況を検出 Events Anomaly UEBAに基づき、通常と異なるセキュリティイベントの発生を検出 Cato Endpoint Alerts ※EPPが必要 CatoのEPP アラートからデータを相関させて、ストーリーを作成 Microsoft Endpoint Alerts Microsoft Defender for Endpoint のアラートからデータを相関させて、ストーリーを作成 CrowdStrike Endpoint Detections CrowdStrikeのデータを統合し、エンドポイントデバイスのストーリーを生成 SntinelOne Endpoint Incidents SentinelOneのデータを統合し、エンドポイントデバイスのストーリーを生成 Entra Identity Alerts Microsoft Entra ID Protection からデータを統合してストーリーを生成 NOC Site Operations Site全体の通信断、リンクの切断などのイベントを検出 Experience Anomaly アプリケーションに対するネットワーク パフォーマンスの大幅な変化を検出 Predictive Insi ght WorkBenchの右上をNOCに絞るとフィルター対象として表示されていますが、私が調べる限りはCato社のKnowledge Baseでは解説がありませんでした。 直訳すると「予測的洞察」となり、過去のデータや現在の状況を分析して、将来起こりうる事象の予測のようなストーリーと考えられます 主に検知されるのは、Threat Prevention / Threat Hunting / Usage Anomaly / Events Anomaly / Site Operations の5つです。 Threat PreventionとSite Operationsの2つは、従来の無償ライセンス XDR Core で提供されていたもので、そのほか3つは有償のProライセンスで提供されていたものです。 下画像では、Group ByでProducerごとにまとめてCriticality順に表示しています。 どのカテゴリのストーリーがどれくらい検知しているのか、整理されるのでGroup Byは使い勝手がよいです。 また、 〇 で囲んだ付箋のようなボタンを押すと、現在のフィルターをお気に入りとして保存することもできます。 Detection & Response Policy XOpsでは、ストーリー生成されたときのメール通知や、特定の条件でストーリー生成しないなどのルール作成が可能です。 例えば、運用としては以下のようなユースケースが考えられるかと思います。 CriticalityがHighであればメール通知する 〇〇拠点から××あての特定のアプリケーション通信であれば、既知の安全な通信のためストーリーを生成しない ストーリーの見方解説 それではストーリーのページをご紹介します。 ※拠点名やIPアドレスなどの情報を黒塗りしています。 概要：ストーリー名、Producer、送信元情報など ストーリーの流れ：ストーリー生成、イベント増加、クロージングなどの日時 詳細：1,2の情報のほか、通信方向、Criticality、Mitre TagやPlaybookのURLなど 生成AIサマリ：大変便利な機能です、後述します！ 直近14日間のイベント：イベント数の遷移とThreat Name。View Allのリンクをクリックすると、フィルターされたイベントログの画面に遷移します 以降の情報は、記載の通りですので割愛します 生成AIサマリ機能 ストーリーを開いた後、最初にやるべきは④の「 Generate AI Summary 」ボタンをクリックすることです。 数秒待つと「See Summary」の表示に切り替わり、クリックしてみると↓のようなストーリーのサマリが表示されます。 【AIサマリ 直訳】 2025年3月10日、特定サイトからの送信ブロックイベントが異常な急増を示し、潜在的な感染を示唆するインシデントが発生した。分析の結果、イベント数が驚異的な増加（変化率983,099%）を示しており、即時対応を要する重大な脅威が示唆された。このインシデントは機械学習スコアが低い対象を含む複数ターゲットに及び、特定の方向へのトラフィックと関連していたため、データ流出の試みが懸念されました。調査により、ブロックされたイベントは主に少数のIPアドレスに関連しており、脅威フィードが全くないターゲットも含まれていたことが判明。これにより、これらの潜在的な脅威に関する事前情報がないことが明らかになった。結果として、さらなるリスクを軽減するためトラフィックをブロックする決定がなされ、継続的な監視と脅威検知能力の強化の必要性が強調された。 このサマリを読めば、ストーリーのおおよその内容は理解できます。 サマリで内容をつかんだあとに、送信元/先のIPやアプリケーションや脅威の情報などを確認し、対応を開始するのがおすすめです。 今回の例で言えば、Firewallのルール変更などでイベント数の増加が想定されたものであれば問題なしですが、 覚えのない送信先IPに対する接続が増加しているのであれば、直ちに送信先IPへの接続をブロックするルールを追加する、送信元IPのユーザにヒアリングするなどの調査が必要になってきます。 ユーザからの問い合わせ対応など日々の運用では気づきづらい、こういった普段とは違うふるまいを検知してくれることがXOpsの大きな1つの魅力と言えます。 おわりに XOpsの機能解説はいかがでしたでしょうか？ SCSKよりCatoをご提供しているお客様には、 2026年2月6日まで 無償でXOpsをご利用いただけます。 また、2025年8月以降に弊社経由でCatoをご購入されたお客様で、XOpsが有効化されていない場合は、Catoクラウド担当までご連絡ください。2月6日までの期間限定で有効化が可能です。 ぜひこの機会に「ストーリー」を活用し、XOpsの有用性をご体感ください！

今回は、AWS Systems Manager InventoryによるEC2インスタンスのソフトウェア、設定、ファイル、レジストリ情報の自動収集システムをAWS CDKで実装する方法をまとめました。 はじめに 今回は、AWS Systems Manager Inventoryを使用して、EC2インスタンスのソフトウェア情報、システム設定、インストールされているファイル、Windowsレジストリ情報などを自動収集し、S3バケットに保存するアーキテクチャをAWS CDKで実装していきます。   今回作成するリソース S3バケット : SSMインベントリデータの保存先 バケットポリシー : SSMサービス専用のアクセス権限 SSM Association : インベントリ収集の自動実行設定 Resource Data Sync : インベントリデータの一元化と同期   アーキテクチャ概要   AWS CDK ソースコード S3バケット設定（インベントリ保存） const ssmInventoryBucket = new s3.Bucket(this, 'SsmInventoryBucket', { bucketName: `s3b-ssm-inventory-bucket`, 　 // バケット名 blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, // パブリックアクセスをすべてブロック encryption: s3.BucketEncryption.S3_MANAGED, // 暗号化タイプ：SSE-S3 autoDeleteObjects: true, // バケット削除時にオブジェクトも削除 デプロイ成功後にfalseに設定 enforceSSL: true, // SSL/TLS暗号化を強制 lifecycleRules: [ // ライフサイクルルール作成 { id: 'Expiration Rule 12 Months', // ライフサイクルルール名 expiration: cdk.Duration.days(366), // 1年間保持 } ], removalPolicy: cdk.RemovalPolicy.DESTROY, // スタック削除時にバケットも削除 デプロイ成功後にRETAINに変更 }); // バケットポリシー追加 ssmInventoryBucket.addToResourcePolicy(new iam.PolicyStatement({ // バケットポリシー追加 sid: 'AWSSSMInventoryWrite', // ステートメントID effect: iam.Effect.ALLOW, // 許可 actions: [ // 許可するアクション 's3:PutObject' // オブジェクトの配置を許可 ], resources: [ // 対象リソース `${ssmInventoryBucket.bucketArn}/AWSLogs/${cdk.Stack.of(this).account}/SSM/*`, // SSMログ用パス ssmInventoryBucket.bucketArn, // バケット自体 ], principals: [new iam.ServicePrincipal('ssm.amazonaws.com')], // SSMサービス conditions: { // 条件 StringEquals: { // 文字列完全一致 's3:x-amz-acl': 'bucket-owner-full-control', // ACL制御 'aws:SourceAccount': cdk.Stack.of(this).account // 送信元アカウント制限 } } })); ポイント: セキュア設計 : パブリックアクセス完全ブロック、SSL強制 長期保存 : コンプライアンス要件に応じた1年間保持 暗号化 : SSE-S3による自動暗号化 コスト管理 : ライフサイクルポリシーによる自動削除 最小権限 : SSMサービスのみにPutObject権限を付与 アカウント制限 : 自アカウントからのアクセスのみ許可 ACL制御 : バケット所有者の完全制御を保証 パス制限 : SSM専用パスのみへのアクセス制限 SSM Association設定 const inventoryAssociation = new ssm.CfnAssociation(this, 'InventoryAssociation', { name: 'AWS-GatherSoftwareInventory', // 実行するSSMドキュメント名 associationName: 'ssm-inventory', // インベントリ名 targets: [{ // ターゲット key: 'InstanceIds', // 対象キー values: ['*'] // 対象値 }], parameters: { 'applications': ['Enabled'], // アプリケーション情報を収集 'awsComponents': ['Enabled'], // AWSコンポーネント情報を収集 'networkConfig': ['Enabled'], // ネットワーク設定情報を収集 'windowsUpdates': ['Enabled'], // Windowsアップデート情報を収集 (Windowsのみ) 'instanceDetailedInformation': ['Enabled'], // インスタンスの詳細情報を収集 'services': ['Enabled'], // サービス設定を収集 (Windowsのみ) 'windowsRoles': ['Enabled'], // Windowsロール設定を収集 (Windowsのみ) 'customInventory': ['Enabled'], // カスタムインベントリデータを収集 'billingInfo': ['Enabled'], // ライセンス含有アプリケーションの課金情報を収集 'files': ['[{"Path":"C:\\Program Files","Pattern":["*.exe"],"Recursive":true}]'], // ファイルを収集 'windowsRegistry': ['[{"Path":"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion","ValueNames":["ProductName"],"Recursive":false}]'], // Windowsレジストリデータを収集 }, scheduleExpression: 'rate(30 minutes)', // インベントリの収集頻度：30分ごと outputLocation: { // 実行結果出力先指定 s3Location: { outputS3BucketName: ssmInventoryBucket.bucketName, // インベントリ用のバケットに出力 outputS3KeyPrefix: `AWSLogs/${cdk.Stack.of(this).account}/SSM/Logs` // ディレクトリを作成 } } }) ポイント: 包括的収集 : ソフトウェア、設定、ファイル、レジストリの全面的な情報収集 定期実行 : 30分間隔での自動収集（要件に応じて調整可能） カスタマイズ : ファイルパスやレジストリキーの設定 構造化出力 : JSON形式での構造化されたデータ保存 Resource Data Sync設定 //resourceデータの同期設定 const resourceDataSync = new ssm.CfnResourceDataSync(this, 'ResourceDataSync', { // リソースデータの同期 syncName: 'resource-data-sync', // 同期名 s3Destination:{ bucketName: ssmInventoryBucket.bucketName, // バケット名 bucketPrefix: `AWSLogs/${cdk.Stack.of(this).account}/SSM/`, // バケットプレフィックス名 bucketRegion: cdk.Stack.of(this).region, // バケットのリージョン：東京リージョン syncFormat: 'JsonSerDe' // 同期形式：JSON } }); // 依存関係の設定 resourceDataSync.node.addDependency(inventoryAssociation); // 先にSSMインベントリ作成 ポイント: データ一元化 : 複数インスタンスのインベントリデータを統合管理 標準形式 : JsonSerDe形式による構造化データ リージョン対応 : マルチリージョン環境での統合管理 依存関係 : Association作成後の実行を保証 インベントリ収集項目と活用方法 収集項目詳細 カテゴリ 収集内容 用途 Applications インストール済みソフトウェア一覧 ライセンス管理、セキュリティ監査 AWS Components AWS CLI、CloudWatch Agent等 AWS管理ツールの導入状況 Network Config ネットワーク設定情報 ネットワーク構成管理 Windows Updates 適用済み更新プログラム パッチ管理、脆弱性対応 Instance Details CPU、メモリ、OS情報 資産管理、容量計画 Services Windowsサービス状態 サービス管理、異常検知 Windows Roles Windowsサーバーロール 機能構成管理 Files 指定パスのファイル情報 セキュリティ監査、変更管理 Registry Windowsレジストリ値 システム設定管理 注意点 Association制限 : インスタンス単位で1つのInventory Associationのみ設定可能です   今回実装したコンストラクトファイルまとめ import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import * as s3 from 'aws-cdk-lib/aws-s3'; import * as iam from 'aws-cdk-lib/aws-iam'; export interface SsmInventoryConstructProps { } export class SsmInventoryConstruct extends Construct { constructor(scope: Construct, id: string, props?: SsmInventoryConstructProps) { super(scope, id); //=========================================== // ssmインベントリ用のS3バケット作成 //=========================================== const ssmInventoryBucket = new s3.Bucket(this, 'SsmInventoryBucket', { bucketName: `s3b-ssm-inventory-bucket`, // バケット名 blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, // パブリックアクセスをすべてブロック encryption: s3.BucketEncryption.S3_MANAGED, // 暗号化タイプ：SSE-S3 autoDeleteObjects: true, // バケット削除時にオブジェクトも削除 デプロイ成功後にfalseに設定 enforceSSL: true, // SSL/TLS暗号化を強制 lifecycleRules: [ // ライフサイクルルール作成 { id: 'Expiration Rule 12 Months', // ライフサイクルルール名 expiration: cdk.Duration.days(366), // 1年間保持 } ], removalPolicy: cdk.RemovalPolicy.DESTROY, // スタック削除時にバケットも削除 デプロイ成功後にRETAINに変更 }); // バケットポリシー追加 ssmInventoryBucket.addToResourcePolicy(new iam.PolicyStatement({ // バケットポリシー追加 sid: 'AWSSSMInventoryWrite', // ステートメントID effect: iam.Effect.ALLOW, // 許可 actions: [ // 許可するアクション 's3:PutObject' // オブジェクトの配置を許可 ], resources: [ // 対象リソース `${ssmInventoryBucket.bucketArn}/AWSLogs/${cdk.Stack.of(this).account}/SSM/*`, // SSMログ用パス ssmInventoryBucket.bucketArn, // バケット自体 ], principals: [new iam.ServicePrincipal('ssm.amazonaws.com')], // SSMサービス conditions: { // 条件 StringEquals: { // 文字列完全一致 's3:x-amz-acl': 'bucket-owner-full-control', // ACL制御 'aws:SourceAccount': cdk.Stack.of(this).account // 送信元アカウント制限 } } })); //=========================================== // SSMインベントリ作成 //=========================================== const inventoryAssociation = new ssm.CfnAssociation(this, 'InventoryAssociation', { name: 'AWS-GatherSoftwareInventory', // 実行するSSMドキュメント名 associationName: 'ssm-inventory', // インベントリ名 targets: [{ // ターゲット key: 'InstanceIds', // 対象キー values: ['*'] // 対象値 }], parameters: { 'applications': ['Enabled'], // アプリケーション情報を収集 'awsComponents': ['Enabled'], // AWSコンポーネント情報を収集 'networkConfig': ['Enabled'], // ネットワーク設定情報を収集 'windowsUpdates': ['Enabled'], // Windowsアップデート情報を収集 (Windowsのみ) 'instanceDetailedInformation': ['Enabled'], // インスタンスの詳細情報を収集 'services': ['Enabled'], // サービス設定を収集 (Windowsのみ) 'windowsRoles': ['Enabled'], // Windowsロール設定を収集 (Windowsのみ) 'customInventory': ['Enabled'], // カスタムインベントリデータを収集 'billingInfo': ['Enabled'], // ライセンス含有アプリケーションの課金情報を収集 'files': ['[{"Path":"C:\\Program Files","Pattern":["*.exe"],"Recursive":true}]'], // ファイルを収集 'windowsRegistry': ['[{"Path":"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion","ValueNames":["ProductName"],"Recursive":false}]'], // Windowsレジストリデータを収集 }, scheduleExpression: 'rate(30 minutes)', // インベントリの収集頻度：30分ごと outputLocation: { // 実行結果出力先指定 s3Location: { outputS3BucketName: ssmInventoryBucket.bucketName, // インベントリ用のバケットに出力 outputS3KeyPrefix: `AWSLogs/${cdk.Stack.of(this).account}/SSM/Logs` // ディレクトリを作成 } } }) //resourceデータの同期設定 const resourceDataSync = new ssm.CfnResourceDataSync(this, 'ResourceDataSync', { // リソースデータの同期 syncName: 'resource-data-sync', // 同期名 s3Destination:{ bucketName: ssmInventoryBucket.bucketName, // バケット名 bucketPrefix: `AWSLogs/${cdk.Stack.of(this).account}/SSM/`, // バケットプレフィックス名 bucketRegion: cdk.Stack.of(this).region, // バケットのリージョン：東京リージョン syncFormat: 'JsonSerDe' // 同期形式：JSON } }); } }   まとめ 今回は、AWS Systems Manager Inventoryを活用した包括的なインベントリ管理システムをAWS CDKで実装しました。 皆さんのお役に立てば幸いです。

こんにちは、広野です。 2025 年 6 月に Amazon Cognito マネージドログインに AWS WAF の Web ACL をアタッチすることができるようになりました。   https://aws.amazon.com/jp/about-aws/whats-new/2025/06/amazon-cognito-aws-waf-managed-login/   何ら真新しいことではないのですが、気を付けた方がよい点があるので書いておきます。   公式ドキュメント 以下に公式ドキュメントがあります。   Associate an AWS WAF web ACL with a user pool - Amazon Cognito You can associate an AWS WAF web ACL with an Amazon Cognito user pool. A web ACL can block and log unwanted HTTPS reques... docs.aws.amazon.com   アタッチした AWS WAF Web ACL によるチェック対象は以下になります。 Managed login and the classic hosted UI Public API operations つまり、UI と API なんですが。さらっと書かれすぎているので、以降、別ブログ記事の図を引用して説明します。   どこがチェック対象なのか 図に示すと、 以下の赤丸の 2 箇所 がチェック対象になります。   code-server を nginx で HTTPS 化して Amazon Cognito で MFA 認証をさせる - アーキクチャ編 code-server を HTTPS 公開して MFA 認証を付ける構成を試してみました。本記事ではアーキテクチャを紹介します。 blog.usize-tech.com 2025.09.16   もう少し概念レベルで Amazon Cognito ユーザープールを機能分割すると、以下のように表現できます。 Amazon Cognito のマネージドログイン UI と、API がチェック対象になるのですが、それぞれのソースが異なります。   ソース IP アドレス制限をかけるときの注意 このため、Amazon Cognito マネージドログインを使用する環境でソース IP アドレス制限をかけるときには注意事項があります。 ソースは複数箇所あると考えた方がよいです。上記のケースでは、ユーザーデバイスと Amazon EC2 インスタンスの IP アドレスを 両方 許可するようにしてあげないと、認証フローが通りません。   おまけ AWS CloudFormation テンプレート AWS Cognito に AWS WAF をアタッチする AWS CloudFormation テンプレートを参考までに貼り付けます。 今回検証したのは特定のソース IP アドレス (サブネット) を許可する設定です。 アプリケーションクライアントの設定は省略しています。Amazon Cognito ユーザープールと、AWS WAF およびそのログ保存に絞っています。登場する IP アドレスは架空のものです。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a Cognito user pool with Managed Login. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SystemName: Type: String Description: System name. use lower case only. (e.g. example) Default: example MaxLength: 10 MinLength: 1 SubName: Type: String Description: System sub name. use lower case only. (e.g. prod or dev) Default: dev MaxLength: 10 MinLength: 1 SesId: Type: String Description: Amazon SES ID for sending emails. (email addreess or domain) Default: xxxx.xxx MaxLength: 100 MinLength: 5 SesConfigurationSet: Type: String Description: Amazon SES configuration set for sending emails. Default: xxxxxxxxxxxxxxxx MaxLength: 100 MinLength: 5 CognitoReplyTo: Type: String Description: Cognito Reply-to email address. (e.g. xxx@xxx.xxx) Default: xxxxx@xxx.xxx MaxLength: 100 MinLength: 5 CognitoEmailFrom: Type: String Description: Cognito e-mail from address. (e.g. xxx@xxx.xxx) Default: xxxxx@xxx.xxx MaxLength: 100 MinLength: 5 LogRetentionDays: Type: Number Description: The retention period (days) for AWS WAF logs. Enter an integer between 35 to 540. Default: 365 MaxValue: 540 MinValue: 35 SourceIpv4RangeList: Type: CommaDelimitedList Description: The comma delimited list of allowed source IPv4 address range (CIDR) except /0 to access this web site. (e.g. xxx.xxx.xxx.xxx/xx,yyy.yyy.yyy.yyy/yy) Default: "8.8.8.8/32,8.8.4.4/32" Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: "General Configuration" Parameters: - SystemName - SubName - Label: default: "Email Configuration" Parameters: - SesId - SesConfigurationSet - CognitoReplyTo - CognitoEmailFrom - Label: default: "Security Configuration" Parameters: - LogRetentionDays - SourceIpv4RangeList Resources: # ------------------------------------------------------------# # Cognito # ------------------------------------------------------------# UserPool: Type: AWS::Cognito::UserPool Properties: UserPoolName: !Sub ${SystemName}-${SubName} MfaConfiguration: "OFF" Policies: PasswordPolicy: MinimumLength: 8 RequireUppercase: true RequireLowercase: true RequireNumbers: true RequireSymbols: false TemporaryPasswordValidityDays: 180 AccountRecoverySetting: RecoveryMechanisms: - Name: verified_email Priority: 1 AdminCreateUserConfig: AllowAdminCreateUserOnly: true AutoVerifiedAttributes: - email DeviceConfiguration: ChallengeRequiredOnNewDevice: false DeviceOnlyRememberedOnUserPrompt: false EmailConfiguration: ConfigurationSet: !Ref SesConfigurationSet EmailSendingAccount: DEVELOPER From: !Sub "${SystemName}-${SubName} admin <${CognitoEmailFrom}>" ReplyToEmailAddress: !Ref CognitoReplyTo SourceArn: !Sub arn:aws:ses:${AWS::Region}:${AWS::AccountId}:identity/${SesId} EmailVerificationMessage: !Sub "${SystemName}-${SubName} Verification code: {####}" EmailVerificationSubject: !Sub "${SystemName}-${SubName} Verification code" UsernameConfiguration: CaseSensitive: false UserPoolAddOns: AdvancedSecurityMode: "OFF" UserPoolTags: Cost: !Sub ${SystemName}-${SubName} UserPoolTier: ESSENTIALS UserPoolDomain: Type: AWS::Cognito::UserPoolDomain Properties: Domain: !Sub ${SystemName}-${SubName} ManagedLoginVersion: 2 UserPoolId: !Ref UserPool # ------------------------------------------------------------# # WAF Web Acl for Cognito # ------------------------------------------------------------# WebAclCognito: Type: AWS::WAFv2::WebACL Properties: Name: !Sub ${SystemName}-${SubName}-cognito Description: WAFv2 WebACL for Cognito Scope: REGIONAL DefaultAction: Block: {} Rules: - Name: !Sub ${SystemName}-${SubName}-cognito-IpWhiteList Action: Allow: {} Priority: 0 Statement: IPSetReferenceStatement: Arn: !GetAtt WAFv2Ipv4WhiteList.Arn VisibilityConfig: CloudWatchMetricsEnabled: true MetricName: !Sub ${SystemName}-${SubName}-cognito-IpWhiteList SampledRequestsEnabled: true VisibilityConfig: CloudWatchMetricsEnabled: true MetricName: !Sub ${SystemName}-${SubName}-cognito SampledRequestsEnabled: true Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} DependsOn: - WAFv2Ipv4WhiteList WAFv2Ipv4WhiteList: Type: AWS::WAFv2::IPSet Properties: Name: !Sub ${SystemName}-${SubName}-Ipv4WhiteList Description: WAF v2 IPv4 white list for the IP-based restricted access IPAddressVersion: IPV4 Addresses: !Ref SourceIpv4RangeList Scope: REGIONAL Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} WebACLAssociationCognito: Type: AWS::WAFv2::WebACLAssociation Properties: ResourceArn: !GetAtt UserPool.Arn WebACLArn: !GetAtt WebAclCognito.Arn DependsOn: - UserPool - WebAclCognito WebAclLoggingConfigurationCognito: Type: AWS::WAFv2::LoggingConfiguration Properties: ResourceArn: !GetAtt WebAclCognito.Arn LogDestinationConfigs: - !GetAtt S3BucketWafLogs.Arn LoggingFilter: DefaultBehavior: KEEP Filters: - Behavior: KEEP Conditions: - ActionCondition: Action: BLOCK Requirement: MEETS_ANY DependsOn: - S3BucketWafLogs - WebAclCognito # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketWafLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub aws-waf-logs-${SystemName}-${SubName}-cognito LifecycleConfiguration: Rules: - Id: AutoDelete Status: Enabled ExpirationInDays: !Ref LogRetentionDays OwnershipControls: Rules: - ObjectOwnership: BucketOwnerEnforced PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: # Cognito CognitoUserPoolId: Value: !Ref UserPool Export: Name: !Sub CognitoUserPoolId-${SystemName}-${SubName} CognitoUserPoolArn: Value: !GetAtt UserPool.Arn Export: Name: !Sub CognitoUserPoolArn-${SystemName}-${SubName} CognitoUserPoolProviderName: Value: !GetAtt UserPool.ProviderName Export: Name: !Sub CognitoUserPoolProviderName-${SystemName}-${SubName} CognitoUserPoolProviderUrl: Value: !GetAtt UserPool.ProviderURL Export: Name: !Sub CognitoUserPoolProviderUrl-${SystemName}-${SubName} まとめ いかがでしたでしょうか。 今回は小ネタでした。Amazon Cognito 周りの通信パスをご存知の方にとっては当たり前と思いましたが、意外と知られていないかもな？と思ったので書きました。 本記事が皆様のお役に立てれば幸いです。

高い柔軟性とコストパフォーマンスで世界中の企業に導入されているオープンソース統合監視ソフトウェアのZabbix。 そのZabbix Japanが主催する公式ウェビナーに、弊社トップエンジニアの 中野祐輔氏 が登壇する運びとなりました！   本ウェビナーは アプライアンス初期設定とZabbixの基本について と題して、弊社がこれまで培ってきたZabbix活用のノウハウを凝縮し、これからZabbixを始める皆様を力強くサポートする内容となっております！   こんな方におすすめ Zabbixアプライアンスの導入を検討している方 Zabbixという名前は知っているが、具体的に何ができて、どう便利なのかを知りたい方 過去にZabbixを試そうとしたが、監視設定時に挫折してしまった経験がある方 数々の難易度の高いZabbix案件を成功に導いてきた弊社のトップアーキテクトである中野祐輔氏の解説を直接聞いてみたい方   本ウェビナーで得られること 本ウェビナーにご参加いただくことで、単なる知識のインプットに留まらず、「明日から実際にZabbixを使ってみよう」と思える具体的なスキルを得ることができます。 Zabbixを扱う上で必須となる「ホスト」「アイテム」「トリガー」といった基本概念を、実例を交えて体系的に理解できます。 サーバーのCPU使用率やディスク空き容量監視など、すぐに現場で役立つ実践的な監視設定の手順を、デモンストレーションを通じて習得できます。 「Zabbixアプライアンス」の利用法を学び、監視を始めるまでのハードルを劇的に下げることができます。   ウェビナー詳細 項目 内容 タイトル アプライアンス初期設定とZabbixの基本について 開催日時 2025年10月21日  14:00-14:30 形式 Webex 登壇者 中野祐輔 参加費 無料   申し込み方法 こちらのサイトから参加登録をお願いします。 Zabbix Webセミナー - Zabbix Zabbixでは、Zabbix監視ソリューションに関する無料のWebセミナーを開催しています。Webセミナーでは、Zabbix監視ソリューションの機能、選ばれる理由、動作環境、最新版Zabbixの新機能、Zabbix社によって提供されている... www.zabbix.com   さいごに このわずか30分のウェビナーが、皆様の監視業務を大きく変えるきっかけになるかもしれません。 ウェビナーの最後には質疑応答の時間も設けておりますので、日頃から抱えている監視に関する疑問や不安を、弊社エンジニアに直接ぶつける絶好の機会です。 ご興味をお持ちいただけましたら、ぜひお申し込みください！

こんにちは。SCSKの津田です。 システムの計画的なメンテナンスやトラブル対応時に、サーバの停止や再起動を行うことは少なくないですよね。 LifeKeeperを導入する環境では、こうした場面で「稼働系サーバを停止・再起動した場合にフェイルオーバが発生するのか？」というご質問を利用者の方からよくいただきます。 結論から申し上げますと、サーバ停止時の挙動は、LifeKeeperの設定 (シャットダウンストラテジー) によって選択することが可能です。 本記事では、LifeKeeper導入環境におけるサーバ停止時の動作についてご説明します。   シャットダウンストラテジーについて LifeKeeperでは、「シャットダウンストラテジー（Shutdown Strategy）」の設定によって、通常のサーバ停止時の動作を選択できます。 シャットダウンストラテジーとは、クラスタ内の稼働系サーバが通常のサーバ停止をする際に、待機系サーバへリソースをフェイルオーバするかどうかを制御する LifeKeeper のオプションです。 以下の2つから選択ができます（デフォルトは “Do not Switchover Resources” ）。 シャットダウンストラテジー オプション 動作内容 Do not Switchover Resources（デフォルト） 通常のサーバ停止時、待機系サーバでリソースは起動しない（フェイルオーバしない）。 Switchover Resources 通常のサーバ停止時、待機系サーバでリソースが起動する（フェイルオーバする）。 ※ここでの「通常のサーバ停止」とは、サーバ障害時を除いた計画的・意図的なサーバ停止を指します。 　LifeKeeperが「通常のサーバ停止」とみなす操作例： 　・Linux：shutdown、rebootコマンド 　・Windows：Windowsメニューからのシャットダウン、再起動 　・クラウド環境：コンソールからのサーバ停止、再起動   通常のサーバ停止と障害によるサーバ停止の判別の仕組み ちなみに、LifeKeeperでは通常のサーバ停止と障害によるサーバ停止を、 バックアップサーバでの「nofailoverフラグ」の有無 によって判別しています。 ・「nofailoverフラグ」あり ：通常のサーバ停止と判定し、フェイルオーバしない ・「nofailoverフラグ」なし ：障害によるサーバ停止と判定し、フェイルオーバ処理を開始 “Do not Switchover Resources”を設定している場合、 通常のサーバ停止時は、コミュニケーションパスを通じて、バックアップサーバに「nofailoverフラグ」が作成されるため、フェイルオーバは発生しません。 一方、障害によるサーバ停止の場合は「nofailoverフラグ」が作成されないため、フェイルオーバが実施されます。 “Switchover Resources”を設定している場合、 通常のサーバ停止時に「nofailoverフラグ」は作成されません。 そのため、通常のサーバ停止か障害によるサーバ停止かに関わらず、必ずフェイルオーバが発生します。 また、稼働系サーバのリソース状態にかかわらず(一部リソース停止、もしくは全停止状態でも)、待機系サーバ上でリソースが全て起動します。   シャットダウンストラテジー設定変更方法 シャットダウンストラテジーは、 各サーバごとに 設定が可能です。 ①LifeKeeper GUIを開き、[Edit] メニュー で [Server] ⇒ [Properties] をクリックします。   ②[Server Properties] ダイアログが表示されるため、    [General] タブ で、［Server］、 [Shutdown Strategy] の値をプルダウンから選択し、［Apply］をクリックします。   ※上記画像はLinuxの画面イメージですが、Windowsでも同様の手順で設定できます。 ※シャットダウンストラテジーはサーバごとに個別設定が可能です。   どちらを選択すべきか？ ・ Do not Switchover Resources    メンテナンスやスケジュールなどによる、意図的なサーバ停止時にリソースの切り替えが不要な場合に適しています。 ・ Switchover Resources    メンテナンス等によるサーバの通常停止時にも、自動でフェイルオーバさせることで必ず待機系サーバでサービス提供を継続したい場合    に適しています。( ※”Do not Switchover Resources” を設定している場合もサーバ停止前に手動で待機系にスイッチオーバすること    で、サービス提供は継続可能です。) 当社で構築してきたシステムでは” Do not Switchover Resources ”を設定するケースが多いです。 運用ポリシーやメンテナンス計画に応じて、適切な設定を選択しましょう。   注意事項 シャットダウンストラテジーの設定には以下の点にご注意ください。 ・ シャットダウンストラテジーが有効に機能するには、正常なシャットダウン時に LifeKeeper のプロセスが起動している必要があり     ます。 ※再起動時は、LifeKeeper のプロセスも自動で起動されます。 ・ LifeKeeper for Windows環境において、DataKeeperのリソースを作成し、シャットダウンストラテジーで“Switchover Resources”を     設定している場合、通常のサーバ停止時にリソースの切り替えに失敗する可能性があります。    (参考： https://lkdkuserportal.sios.jp/hc/ja/articles/360037693491 )   まとめ 今回はLifeKeeperのシャットダウンストラテジーの設定についてご紹介しましたが、いかがでしたでしょうか？ 本記事でLifeKeeperでは 通常のサーバ停止時にリソースの切り替えを行うかどうかを選択できるということをご理解いただけましたら幸いです。 シャットダウンストラテジー オプション 動作内容 適したケース Do not Switchover Resources 通常のサーバ停止では、フェイルオーバしない。 (nofailoverフラグがバックサーバに作成されることにより、フェイルオーバが抑止される。) メンテナンスやスケジュール等による意図的なサーバ停止時にリソースの切り替えが不要な場合 Switchover Resources 通常のサーバ停止でも、フェイルオーバする。 (nofailoverフラグがバックサーバに作成されないため、フェイルオーバする。) サーバ障害時だけでなく、通常のサーバ停止時にも自動でリソースの切り替えを行い、サービスを継続させたい場合   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで

当記事は、前回の記事「Ansibleを使用してNW機器設定を自動化する（PaloAlto-アドレスグループ編①）」からの改善となります。 設定情報がベタ書きで使い勝手が悪い点　を　設定情報をまとめてINPUT（JSON）できる使い勝手の良い仕組みとしました！！ これにより、Anibleとの連携ができるようになりますので、ご参考になれば幸いです。 ※前回記事： Ansibleを使用してNW機器設定を自動化する（PaloAlto-アドレスグループ編①） – TechHarmony 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-アドレスグループ」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   事前設定２：設定情報をまとめてINPUT（JSON）できるように、「Survey」を活用 テンプレートが読み込むことができる変数（Survey）を設定する。※今回は、各設定のデフォルト値に値を設定する。 実際の値（JSON） ・input_addressgroup1: {"name":"test_addressgroup001","static_value":"test_address001"} ・input_addressgroup2: {"name":"test_addressgroup001","static_value":"test_address002"} ・input_addressgroup3: {"name":"test_addressgroup001","static_value":["test_address001","test_address003"]} ・input_addressgroup4: {"name":"test_addressgroup001","static_value":"test_address003"} ・input_addressgroup5: {"name":"test_addressgroup001","static_value":"test_address003"}   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_address_group 　を使用。 ※参考ページ： Ansible Galaxy galaxy.ansible.com   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   変数（Survey）の値取得 vars で　各変数（Survey）の値取得。 ※各変数（Survey）の値は、構造化データのように見えて「文字列」なので、ディクショナリ（構造化データ）として正しく扱えるように、from_json フィルターを使用すること！！           vars: wk_input1: '{{ input_addressgroup1 | from_json}}' wk_input2: '{{ input_addressgroup2 | from_json}}' wk_input3: '{{ input_addressgroup3 | from_json}}' wk_input4: '{{ input_addressgroup4 | from_json}} wk_input5: '{{ input_addressgroup5 | from_json}}   Objects-アドレスグループの登録　★ 変数（Survey）の値をそのまま使用した場合 …エラーとなる 接続情報と　アドレスグループとアドレスの関連付け（ Survey：input_addressgroup1 ）を指定して登録（ state: ‘present’ ）を行う。 - name: Present AddressGroup1_input_addressgroup1 paloaltonetworks.panos.panos_address_group: provider: '{{ provider }}' name: '{{ input_addressgroup1.name }}'　　　←　アドレスグループ static_value: '{{ input_addressgroup1.static_value }}'　　←　アドレスグループに関連付けするアドレス state: 'present' register: wk_result 実行結果： 構造化データではないので、オブジェクトに項目が無いという エラー となる。　※Ansibleの実行結果（diff）を抜粋 "msg": "The task includes an option with an undefined variable. The error was: 'ansible.utils.unsafe_proxy.AnsibleUnsafeText object' has no attribute 'name'. ...   Objects-アドレスグループの登録　※アドレスグループの新規作成の場合 接続情報と　アドレスグループとアドレスの関連付け（ ディクショナリ： w k_input ）を指定して登録（ state: ‘present’ ）を行う。 - name: Present AddressGroup1_wk_input paloaltonetworks.panos.panos_address_group: provider: '{{ provider }}' name: '{{ wk_input1.name }}'　　　←　アドレスグループ static_value: '{{ wk_input1.static_value }}'　　←　アドレスグループに関連付けするアドレス state: 'present' register: wk_result 実行結果：対象のアドレスグループが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address001</member>\n\t</static>\n</entry>\n"   Objects-アドレスグループの登録　※アドレスグループが既に存在する場合 接続情報と　アドレスグループとアドレスの関連付け　を指定して登録（ state: ‘present’ ）を行う。　 ※アドレスグループが既に存在する場合は、既存設定の置き換えとなる（state: ‘replaced’と同様）   - name: Present AddressGroup1 paloaltonetworks.panos.panos_address_group: provider: '{{ provider }}' name: '{{ wk_input2.name }}'　　　←　アドレスグループ static_value: '{{ wk_input2.static_value }}'　　←　アドレスグループに関連付けするアドレス state: 'present' register: wk_result 実行結果：既存のアドレスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address001</member>\n\t</static>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address002</member>\n\t</static>\n</entry>\n"   Objects-アドレスグループの変更　※登録のつづき（新たなアドレスを関連付けする） 接続情報と　アドレスグループとアドレスの関連付け　を指定して、アドレスグループの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる　（注意：関連付け後の状態を指定すること！！） - name: Replaced AddressGroup1 paloaltonetworks.panos.panos_address_group: provider: '{{ provider }}' name: '{{ wk_input3.name }}' static_value: '{{ wk_input3.static_value }}'　←　関連付け後の状態を指定すること！！ state: 'replaced' register: wk_result 実行結果：既存のアドレスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address002</member>\n\t</static>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address001</member>\n\t\t<member>test_address003</member>\n\t</static>\n</entry>\n"   接続情報と　アドレスグループとアドレスの関連付け　を指定して、アドレスグループの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定を維持した更新（Append）となる。 その為、特定アドレスの関連付け解除はできない　（注意： アドレスの関連付け解除をしたい場合は　state: ‘replaced’　を使用する必要がある！！）   - name: Merged AddressGroup1 paloaltonetworks.panos.panos_address_group: provider: '{{ provider }}' name: '{{ wk_input4.name }}' static_value: '{{ wk_input4.static_value }}'　←　関連付けしたいアドレスのみ指定すること！！ state: 'merged' register: wk_result 実行結果：既存のアドレスグループが 更新（Append） された。 既存設定が維持されていることを確認 。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address002</member>\n\t</static>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address002</member>\n\t\t<member>test_address003</member>\n\t</static>\n</entry>\n" Objects-アドレスグループの情報収集　※変更のつづき 接続情報と　アドレスグループ　を指定して情報収集（ state: ‘gathered’ ）を行う。 - name: gathered AddressGroup1 paloaltonetworks.panos.panos_address_group: provider: '{{ provider }}' name: '{{ wk_input1.name }}' state: 'gathered' register: wk_result 実行結果：対象アドレスグループの情報が取得できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "gathered_xml": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address001</member>\n\t\t<member>test_address003</member>\n\t</static>\n</entry>\n",   Objects-アドレスグループの削除　※変更のつづき 接続情報と　アドレスグループと関連付いているアドレス　を指定して、削除（state: ‘absent’）を行う。　（ 注意：関連付いているアドレスが削除されるのではなく、アドレスグループが削除される！！）   - name: Absent AddressGroup1 paloaltonetworks.panos.panos_address_group: provider: '{{ provider }}' name: '{{ wk_input5.name }}'　　　←　アドレスグループ　※アドレスグループが削除される static_value: '{{ wk_input5.static_value }}'　　←　アドレスグループに関連付いているアドレス　※指定の必要なし state: 'absent' register: wk_result 実行結果：対象の アドレスグループ が削除された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_addressgroup001\">\n\t<static>\n\t\t<member>test_address001</member>\n\t\t<member>test_address003</member>\n\t</static>\n</entry>\n", "after" : ""   最後に 今回、変数（Survey）を活用したことで、Ansibleに INPUT（JSON）を設定 できるようになりました。 設定情報がYAMLにベタ書きではなくなったので、使い勝手は増しましたが、 都度　変数（Survey）のデフォルト値に値を設定しての実行の為、まだまだ　使い勝手が悪い。。。              今後　外部からAnsibleの INPUT（JSON）に値を連携し実行させる仕組みを試みたいと思います。

こんにちは、SCSKの坂木です。 本記事では、 ファイルサーバーのデータを、Amazon FSx へ移行 するシナリオを想定し、 AWS DataSync を使った具体的な設定手順をスクリーンショットを交えながら、一つひとつ丁寧に解説していきます。   検証環境 実際のデータ移行では、オンプレミス環境からAWSへプライベート接続したり、セキュリティ要件でVPCが分離されていたりするケースが多くあります。 そこで本記事では、そうした本番環境に近いシナリオを再現するため、移行元と移行先の環境を別々のVPCに構築して手順を進めます。 構成の全体像は以下の図の通りです。 2つのVPC間はVPCピアリングで接続しています。各VPCに配置するリソースの役割は以下の通りです。 VPC ①：移行元環境 リソース 説明 EC2 移行対象の共有ファイルが格納されている、既存のファイルサーバー DataSyncエージェント EC2ファイルサーバーからデータを読み取り、AWS DataSyncサービスへ転送する役割を担うコンポーネント 今回はEC2インスタンスとしてデプロイする   VPC ②：移行先環境  リソース 説明 FSx 今回のデータの転送先となる、フルマネージドなファイルサーバー VPC エンドポイント DataSyncエージェントが、インターネットを経由せずにAWSのネットワーク内でDataSyncサービスと通信するためのプライベートな接続口   前提条件 本記事では、AWS DataSyncを使ったデータ転送の具体的な手順に焦点を当てて解説を進めます。 そのため、以下の環境がすでに構築済みであることを前提とします。 もし設定がまだの場合は、お手数ですが先に準備を完了させてから次のステップへお進みください。 1. VPCピアリングの設定 今回は移行元と移行先でVPCを分けているため、2つのVPC間が VPCピアリング によって接続され、相互にプライベートIPアドレスでの通信が可能な状態になっている必要があります。   2. 共有フォルダの作成 移行元となるEC2ファイルサーバー上に、移行対象のデータが含まれた共有フォルダが作成されていること。 この記事では、「Share_10.1.1.163」を共有するフォルダとして設定します。   3. FSxの作成 データの転送先となるFSxがデプロイされていること。 この記事ではFSxを作成したときにデフォルトで作成されるフォルダである「Share」をDataSyncの転送先フォルダとして設定します。   DataSync用のエンドポイント作成 DataSyncエージェントとDataSyncサービス間の通信が発生しますが、この通信をインターネット経由ではなく、AWSのプライベートネットワーク内で完結させることで、よりセキュアな通信経路を確保するため、VPCエンドポイントを作成します。 VPC -> エンドポイント -> エンドポイントを作成　からエンドポイントを作成します。 「サービス」の検索ボックスに datasync と入力し、表示されるサービス名を選択します。 リージョンが東京の場合、サービス名は com.amazonaws.ap-northeast-1.datasync となります。 設定を入力すると以下のようにVPCエンドポイントが作成されます。   DataSyncAgentのデプロイ先インスタンスの作成 今回はDataSyncAgentをEC2で作成します。 EC2 -> インスタンスを起動　からインスタンスを作成します。 EC2作成のAMI選択画面から、「aws-datasync」と入力すると、DataSyncAgent用のAMIが表示されるため、最新版のAMIを選択します。 DataSync エージェントを Amazon EC2 インスタンスにデプロイする場合、インスタンスのサイズは少なくとも 2xlarge である必要があるため、今回はm5.2xlargeを選択して作成します。詳細は こちら をご確認ください。 今回セキュリティグループは、VPC①と②のトラフィックを全て許可する設定としています。本番環境で設定する際には、 こちら を参考に必要なポートのみ開放いただければと思います。   DataSyncのアクティベーションキーの取得 作成したインスタンスにセッションマネージャーやSSHなどでログインすると、画像のようにアクティベーションキーの設定画面が表示されます。 ※ログインユーザはec2-userではなく、adminとなります。   アクティベーションキー取得のため、以下のように入力します。 質問項目 入力項目 Enter command 0: Get activation keyを入力 Enter AWS Region 利用しているリージョンを選択 今回は東京リージョンを利用しているため ap-northeast-1を入力 Select service endpoint type or exit 3: VPC Endpoints using AWS PrivateLinkを入力 Private IPv4 or IPv6 address of VPC endpoint 作成したエンドポイントのIPアドレスを入力   上記のように選択すると、「Activation key:XXXXXXXXXXXXXXXXXXX」と表示されます。 XXXXXXXXXXXXXXXXXXXの部分がアクティベーションキーとなりますので、この文字列をメモしておきます。   DataSyncエージェントの作成 DataSyncエージェントとは、データ転送元サーバと同じ環境で動作する仮想マシンであり、転送元のファイルサーバーに接続してデータを読み取り、AWSのDataSyncサービスに向けてデータを転送します。 DataSync -> エージェント -> エージェントの作成　からDataSyncエージェントを作成します。 下表のように設定値を入力します。 項番 項目 設定内容 1 ハイパーバイザー Amazon EC2を選択 2 エンドポイントタイプ AWS Privatelinkを使用したVPCエンドポイントを選択 3 VPCエンドポイント 「DataSync用のエンドポイント作成」で作成したエンドポイントを選択 4 サブネット DataSyncエージェントを作成するサブネットを選択 「DataSyncAgentのデプロイ先インスタンスの作成」で作成したEC2と同じサブネットを選択 5 セキュリティグループ DataSyncエージェントに紐づけるセキュリティグループを選択 EC2と同じセキュリティグループを選択 6 アクティベーションキー エージェントのアクティベーションキーを手動で入力するを選択 「DataSyncのアクティベーションキーの取得」で取得したアクティベーションキーを入力   項目を入力すると、画像のようにDataSyncエージェントが作成されます。   ロケーションの作成 続いてロケーションを作成します。 ロケーションとは、DataSyncがデータを転送する際の「送信元」と「送信先」を定義したものです。 オンプレミスのNFS/SMBサーバーや、AWSのS3バケット、EFS、FSxなどが指定できます。 送信元のロケーションと送信先のロケーションの2つを作成します。 DataSync -> ロケーション -> ロケーションを作成する　からロケーションを作成します。 送信元ロケーションの作成 下表のように設定値を入力します。 項番 項目 設定内容 1 ロケーションタイプ 送信元のロケーションタイプを選択 今回はEC2の共有フォルダが送信元となるため、サーバーメッセージブロック(SMB)を選択 2 エージェント 「DataSyncエージェントの作成」で作成したDataSyncエージェントを選択 3 SMBサーバー 送信元のEC2のIPアドレスを入力 4 共有名 共有するフォルダ名を入力（選択するフォルダは共有フォルダに設定しておく） 5 認証タイプ NTLM認証を選択 6 ユーザー EC2の共有フォルダにアクセスできるユーザーを入力 今回はAdministratorを指定 7 パスワード 6で選択したユーザーのパスワードを入力 8 ドメイン 6で選択したユーザーの所属するドメインを入力   設定値を入力すると、画像のようにロケーション（送信元）が作成されます。   送信先ロケーション 下表のように設定値を入力します。 項番 項目 設定内容 1 ロケーションタイプ 送信元のロケーションタイプを選択 今回はFSxが送信先となるため、FSxを指定 2 FSxファイルシステム 送信するFSxのファイルシステム名を選択 今回は事前に作成しておいたFSxのファイルシステム名を選択 3 共有名 FSxの送信先フォルダを入力（選択するフォルダは共有フォルダに設定しておく） 4 セキュリティグループ FSxにアタッチされているセキュリティグループへ通信可能な設定されているセキュリティグループを選択 5 ユーザー FSxの共有フォルダにアクセスできるユーザーを入力 今回はAdministratorを指定 6 パスワード 5で選択したユーザーのパスワードを入力 7 ドメイン 5で選択したユーザーの所属するドメインを入力     設定値を入力すると、画像のようにロケーション（送信先）が作成されます。   タスクの作成 タスクとは、「どのロケーションからどのロケーションへ」データを転送するかを定義する実行ジョブです。 転送スケジュール、帯域幅制限、フィルタリング等の詳細なオプションを設定し、このタスクを実行してデータ同期を開始します。 DataSync -> タスク -> タスクを作成　からタスクを作成します。 下表のように設定値を入力します。 項番 項目 設定内容 1 ロケーション 送信元ロケーションで作成したロケーションを選択 2 ロケーション 送信先ロケーションで作成したロケーションを選択 3 設定を構成する オプションを設定する項目で、データを転送するタイミングやログ出力など設定可能 今回はデフォルトで設定     設定値を入力すると、画像のようにタスクが作成されます。   ファイルの転送確認 作成したタスクから、ファイル転送を実施してみます。 ファイル転送が成功すると、実行ステータスが「成功」と表示されます。   実際にファイルが転送されているか確認します。 FSxのshare配下を確認すると、送信元インスタンスで作成したフォルダとファイルが転送されていることを確認できました。   まとめ 本記事では、 AWS DataSyncを用いてEC2共有フォルダからFSxへデータを移行する手順を解説 しました。 DataSyncは、 DataSyncエージェント 、 ロケーション 、 タスク の簡単な設定だけで、高速かつ安全なデータ転送が可能です。 本記事では紹介していませんが、差分同期やスケジュール機能も備え、移行時のダウンタイムを最小限に抑えられる点も魅力です。 オンプレミスやEC2からのファイルサーバー移行時においては、本記事を参考にDataSyncを利用してみてください！   最後に著者の他のAWS記事を紹介させてください。 【Amazon Bedrock】ナレッジベースを用いた社内資料管理ーめざせ生産性向上ー 社内資料の管理、効率的ですか？様々な形式の文書が散在し、必要な情報を探すのに時間を取られていませんか？ ファイルサーバーの奥底に埋もれどこにあるか分からない、バージョン管理が混乱する、などといった課題を抱えていませんか？これらの非効率は、業務の生産性低下に直結します。 今こそ、社内資料の一元管理体制を見直しましょう！ということで、AWS Bedrockのナレッジベースを用いた資料の一括管理およびその検索方法をご紹介します！ blog.usize-tech.com 2025.02.14

こんにちは、SCSK松岡です⛄ Snowflake Intelligenceは、生成AIを利用して自然言語によるデータ検索や要約を可能にしてくれる機能です。 本記事では、その利用を開始するために必要な設定を、アカウント管理者の視点から紹介します。   Snowflake Intelligence   Snowflake IntelligenceとData Science Agent、エンタープライズAI/MLにおける 次世代データエージェントの可能性 ※本報道資料は米国スノーフレイク社が6月3日に発表した内容の抄訳です。 www.snowflake.com Snowflake Intelligenceは先日のSnowflake Summit25で紹介された新機能で、2025年8月からプレビュー機能で利用できるようになりました。 この機能を活用することで、ユーザーはAIとの自然言語でのやり取りを通してSnowflake上のデータにアクセスし、データ活用を行うことができます。 データの検索や要約、可視化、さらにはアナリストのような分析も自動で行ってくれるため、高度なスキルを持たなくても、直感的にデータとの対話が可能になる機能として注目されています。 組織におけるデータ活用の推進において、様々なスキルレベルのユーザーにどう広く使ってもらうか、は課題になりがちな部分かと思います。Snowflake Intelligenceはその一つの解決策になり得る存在として期待しています。   【現地レポート：Day2】Snowflake Summit 25 （Platform Keynoteまとめ） サンフランシスコで開催されている、Snowflake Summit 25速報記事の第二弾です。 今回は、6/3のPlatform Keynoteで紹介された最新のサービスアップデート情報を中心にお届けしたいと思います。 blog.usize-tech.com 2025.06.04   Snowflake Intelligence利用に必要なアカウント設定   Overview of Snowflake Intelligence | Snowflake Documentation docs.snowflake.com Snowflake Intelligenceを利用するためには、大きく４つのSTEPで設定が必要です。 専用のDB・スキーマを作成 生成AIモデルの利用許可 エージェントを作成 エージェントをカスタム 1. 専用のDB・スキーマを作成 --snowflake_intelligence用のDB・スキーマを作成してPUBLICに権限付与 CREATE DATABASE IF NOT EXISTS snowflake_intelligence; GRANT USAGE ON DATABASE snowflake_intelligence TO ROLE PUBLIC; CREATE SCHEMA IF NOT EXISTS snowflake_intelligence.agents; GRANT USAGE ON SCHEMA snowflake_intelligence.agents TO ROLE PUBLIC; まず、エージェントの作成場所となるデータベース、スキーマを作成する必要があります。 DB名は「snowflake_intelligence」スキーマ名は「agents」である必要がありました(※2025/9時点) また、PUBLICにUSAGE権限も付与する必要がありました --エージェントの作成権限を付与 GRANT CREATE AGENT ON SCHEMA snowflake_intelligence.agents TO ROLE [エージェント作成者のロール]; Snowflake Intelligenceの実行単位である「エージェント」は、スキーマ単位のオブジェクトです。 作成したスキーマ上にエージェントを作成するための権限を、作業用のロールに付与します。 2. 生成AIモデルの利用許可 エージェントは、裏側で生成AIモデルを呼び出しながら動作します。そのため、事前にSnowflakeアカウント上で生成AIモデルを利用できるように設定する必要があります。 /* ①Cortex LLM を許可リストに追加 */ ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'All'; /* ②AWS_USリージョンにクロスリージョン推論を許可 */ ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_US'; /* ③モデルの追加設定を反映 */ CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH(); Snowflakeアカウントに対し、生成AIモデルへのアクセスを許可します。(①) 例では、すべて(ALL)のモデルへのアクセスを許可しています。 https://docs.snowflake.com/en/user-guide/snowflake-cortex/snowflake-intelligence Snowflake Intelligenceに対応しているモデルは以下の通りです(※2025/9時点) Claude 4.0 Claude 3.7 Claude 3.5 GPT 4.1 次に、クロスリージョン推論の設定を行います。(②) Snowflake Intelligenceに対応しているモデルは日本のAPJリージョンでは直接対応していないため、異なるリージョンを経由して推論を行うようにする必要があります。 リージョンごとに対応している生成AIモデル Snowflake Cortex AISQL (including LLM functions) | Snowflake Documentation docs.snowflake.com モデルの追加設定を行った後は、反映するためにリフレッシュが必要です。(③) 3. エージェントを作成 エージェントの作成はSnowsightから行うことができます。 Snowsightで、1.でCREATE権限を付与したロールを指定し、[AIとML>エージェント]メニューに移動してエージェントの作成を行います。 エージェントを作成すると、[AIとML>Snowflakeインテリジェンス]メニューのチャット画面で作成したエージェントを選択できるようになります。これで、生成AIモデルとの会話が行えるようになります! 作成時以外のロールにエージェントの利用を許可する場合は、作成したエージェントの編集画面から、[アクセス]メニューを選択してロールの追加を行います。 Snowflake Intelligenceのエージェントによる操作は、実行したユーザーの権限が適用されて動作します。 4. エージェントをカスタム エージェントをただ作成しただけでは、Snowflake上に保管したデータへのアクセスは行ってくれません。 (一般的な回答のみを行います) エージェントにSnowflakeのDB上のデータを検索させたり分析させたりしたい場合、「ツール」を紐づけてカスタマイズする必要があります。 エージェントの編集画面の[ツール]では、従来のSnowflakeのAI機能を紐づけることで、エージェントがどのようにデータへアクセスするかを指定できます。 ツールの代表的なものが Cortex Analyst と Cortex Search です。   Cortex Analyst | Snowflake Documentation docs.snowflake.com Cortex Search | Snowflake Documentation docs.snowflake.com Cortex Analystは構造化データの検索に、Cortex Searchは画像やPDFのような非構造化データの検索に対応しています。 ツールを紐づけると、エージェントは単なる回答生成にとどまらずオーケストレーションの役割を担います。ユーザーの問いかけに応じて、必要なツールを柔軟に組み合わせて使いこなすことが可能になります。 たとえば、自然言語での問い合わせに対してまず関連するドキュメントを検索し、そこから得た情報をもとにSQLを自動生成して値を算出するといった、一連の操作を自動化してくれるようになります。   最後に 本記事では、アカウント設定を行ってSnowflake Intelligenceを動作できるようにするところまでをご紹介しました。 ここまではまだAI活用のための入口で、エージェントによるデータ分析や検索を実際の業務に生かせるほどの精度にするためには、セマンティックモデルの作成がカギを握ります。 セマンティックモデルとは、業務上の用語や指標をメタデータとして整理し、AI が解釈できる形に定義する仕組みです。   Cortex Analyst セマンティックモデル仕様 | Snowflake Documentation docs.snowflake.com AI は人と同じように、複雑で整理されていない情報からは力を発揮しづらい一方で、メタデータやセマンティックモデルが整備されているほど、その能力を最大限に発揮します。 Snowflake Intelligenceの力を最大限引き出すために、いろいろと試行錯誤してみたいと思います!

2025年7月に Catoクラウドのユーザーコミュニティ（ユーザ交流会、ユーザ会）「 Cato Circle（ケイトサークル） 」の発足についての記事を掲載しましたが、今回は 9月18日に開催した初回イベントの記事となります。 Catoクラウド ユーザーコミュニティ「Cato Circle（ケイトサークル）」を発足しました – TechHarmony   参加いただいたお客様の声 イベント内容のご紹介より先に Cato Circle 初回イベントに参加いただいたお客の声、実際のアンケートのフリーコメントを記載します（お客様が特定できるコメントについては除外させていただきました） この度はご招待いただき本当にありがとうございました。貴重なお話をお伺いできる場をご提供いただき感謝申し上げます。とても有意義な時間でした。Cato様より最新の情報やこれからのロードマップをお伺いでき、今後弊社内での方向性を検討するのにとても参考になりました。またCatoを導入されている各社様の生の声を聴くことができ、多くのことに気づかされたり、共感できるところも多く、とても勇気づけられました。SCSK様の技術担当の方ともお話させていただきとても勉強になりました。またブログはいつも本当に参考にさせていただいておりますので、これからも様々なCato関連の情報をご提供いただけると幸いです。 Catoの実ユーザーの方の事例が聞けてとてもよかったです。どこの会社様も同じような経験をされているのだなと、心強く感じました。システム管理部門の方が集まったことで、Catoのお話から発展して各社のシステムの導入状況や運用体制などもお話できてとても参考になりました。Cato社の方から直接ロードマップなどお話いただく機会もありそれもとてもよかったです。直接お会いできたことで身近にも感じられましたし、これからのアップデートも楽しみです。Catoの今後の活用について想像できる機会にもなりましたので、次回の開催がありましたらまた参加したいです。 CATOユーザ同士での情報交換は大変有意義でした。CATO以外のセキュリティ関連の利用状況等（もちろん、CATOとのすみ分け等の情報についても）、興味深い情報交換が出来て充実したユーザ会となりました。次回も是非参加させていただきます。ありがとうございました。 お会いした各社それぞれの導入状況や課題など幅広く聞くことができて大変有意義な会でした。是非、第二回目が開催されることを期待しております。 他社と情報交換できる機会ができて大変有意義でした。ぜひとも今後も定期的に開催いただけると幸いです。 他社様の状況を知ることができ、大変有意義な機会となりました。ありがとうございます。 今後またぜひこういった機会があれば参加させていただけますと幸いです。 各社のオプションの導入状況が分かり、参考になりました（自社も標準的だと分かり、安心した）。 現在PoCを進めている中で、他企業様の具体的な事例を直接伺うことができ、大変有意義な機会となりました。導入・運用の実態に即した事例は理解を深めるうえで非常に参考となり、本番導入に向けた課題の整理にも大いに役立てられると感じております。 セキュリティに関わる部分なので、こういった情報をどこまで共有できるのかは難しいところですが、各社、どのくらいの規模感や国で運用されているのかなど、事前情報として紙一枚あったりするともう少しユーザー間でのコミュニケーションも取りやすいのではないかと感じました。 今回のユーザー会はとても有意義でした。参加させていただいた中で思ったことは、同じ悩みを持つ他社とのマッチング・グループディスカッションがあると良いと思いました。グループディスカッションの中にCato又はSCSKの方が入り、悩みに対して答えや閃きを回答できると更にいいですね。年，半年に1回くらいあると嬉しいです。 パネルディスカッションで参加者からのQAなどのコーナーがあった方が良かったと感じました。 他社様での運用状況などもお話が聞けて参考になりました。（パネルディスカッションも、もう少し時間があると良かったです） パネルディスカッションの時間をもう少し長く確保してあるとありがたいです。ネットワーキングの時間も、運用の面や設定について等話が伺えたため、非常に良かったです。 思った以上に良いイベントでした。事例紹介やディスカッションなど、実際のユーザの声をきくことができて興味深かったです。 ありがとうございました。 個人的には開催規模もちょうどいいと感じました。規模が大きすぎると情報過多になってしまうケースがあり、欲しい情報が埋もれてしまう場合もありますので。 Cato Circleを開催いただきまして、ありがとうございました。CATOユーザー企業様やCATO社様とも様々なお話ができて、学びの多い有意義な1日を過ごすことができました。これからも情報交換させていただき、より良くCATOを活用し、CATO仲間も増やし盛り上げていきたいと思います。 皆さん、アンケートありがとうございました。いただいた意見をもとに、次回はさらに良いイベントにしたいと思います。 フリーコメントから、Cato Circleがどのようなイベントであったかはご理解いただけたのではないかと思います。   Cato Circleイベント内容 さてイベント内容ですが、会場は当社八重洲 SCSK LINK SQUAREで、 20社以上 のお客様に参加いただきました。 Cato Circle 開催の挨拶後、Cato Networks株式会社（アジア太平洋地域フィールドCTO 金子 春信氏）より、Catoクラウドの最新トピックおよびロードマップの説明を行っていただきました。 特に、日本から要望の多い APNIC（JPNIC）問題 、 IPv6（IPoE）対応 、 日本独自のIDaaSサービス連携 などの対応状況から始まり、今後の Catoクラウドのロードマップ の説明があり、皆さんの興味を引いていました。 その後、Catoご利用企業（４社）から、それぞれの導入事例についてご講演をいただきました。 内容としては、会社紹介から、 Catoクラウド採用/導入に至った背景（課題）・経緯、導入時のトラブルや解決方法・工夫したこと、有効な活用方法、これでまで発生した障害や トラブル、Catoおよび当社への改善/要望事項 などをご話いただきました。 参加の皆さんが、最も興味を引いたプログラムだったと思います。 プレゼン内容は、もちろん録音録画不可で、その場限りの非常に貴重な講演となりました。 そして、 講演いただいた４社と、Cato社、SCSKで、パネルディスカッション を行いました。 パネルディスカッションのテーマ（お題）ついては、事前に Cato Circle お申し込み時に「他の利用企業へ聞きたいこと」を事前にお聞きしておりましたので質問が多い順に、事前に10個ほどテーマをピックアップし、それぞれについてディスカッションを実施しました。しかし、残念ながら Cato Circle 初回開催ということもあり、スケジュール計画があまく、時間がかなり押していたため、ディスカッション時間が当初予定より大幅に短縮してしまい、もっと話を聞きたかったのお客様が殆どではないかと思います（大変申し訳ないです） パネルディスカッションの後、少しだけ当社マネージドサービスをご紹介させていただきました。時間の都合上、当社独自のCato AIチャットボットの活用方法の説明ができず残念でしたが、月次報告書のレポート内容について簡単にご紹介させていただきました。 その後、18時から懇親会（軽食、アルコールあり）を行い、参加者の皆さんでネットワーキングを行っていただきました。 お客様同士で、Catoで利用されているオプションや機能（Backhaulingなど）、設定内容、中国・ベトナムなど海外展開における不安事を実際導入されているお客様へ相談されたり、また、Catoに限らず様々な話をされた とお聞きしました。 お帰りの際に「期待していた以上によかったです」「またぜひ開催してください」など嬉しい言葉をたくさんいただきました。 一方で、スケジュール（パネルディスカッションが短い）や段取り、会場セッティング等々、様々な面で多くの不備がありましたが、第1回ということで、何卒ご理解、ご容赦いただけると幸いです。 何よりも数年前から多くのお客様から「Cato利用者同士で会話ができる場を設けて欲しい」と言うご要望にやっとお応えできたのがもっとも良かったことになります。   次回開催に向けて 今回の Cato Circle のアンケート結果から、次回（第2回） Cato Circle について検討を開始しています。 北海道から九州までお客様がいらっしゃるので、東京以外でのイベント開催のご要望、イベント規模（参加人数・時間含め）をもっと大きくして欲しい（時間を長くして欲しい）という声と、逆に人数（規模）を少なくして欲しいと言う声もありました。開催頻度は年に1回、半年に1回の希望が多くあり、フリーコメントにあったようにグループディスカッションの希望も多くいただいております。   Cato Socket X1500 と PoP の 特注アイシングクッキー（Cato Network社からの差し入れ） 次回イベントは、今回と同じく当社（SCSK）主催するのか、あるいは Cato Networks社が主催するのか、から検討します。 Cato Networks社（Japan）で、お客様が参加できるイベントを開催するのであれば、Catoクラウドの最新トピックや機能紹介、ロードマップ説明は、そちらで実施できると思います。 そもそも Cato Circle は、 ユーザーコミュニティ ですので、通常のセミナーのように、一方的に説明を行う「説明型」イベントを行うのではなく、 利用者であるお客様が、Catoクラウドの自社での活用方法や、利用上の課題を発表し、利用者同士が情報を共有する「双方向型」のイベントを目指しております 。お客様同士の交流、ネットワーク構築から、情報交換のきっかけをご提供し、課題や悩みを共有し、解決するヒントを得ていただくことが Cato Circle の目的です（一方、Cato Networks社や、SCSKのサービスに関するフィードバックをいただき、サービス開発や改善に役立てることが、もう一つの目的にあります） そのため Cato Circle では、お客様自身の導入事例紹介による情報発信（共有）、パネルディスカッションやグループディスカッション、お客様同士のネットワーキングを中心としたイベントを計画する予定です。 Catoクラウドをご利用のお客様は、ぜひ Cato Circle へご参加ください。もし、当社のお客様で初回イベントはスケジュールの都合で参加できなかったが次回はぜひ参加したい、Cato Circle の案内がまだ来ていない、と言う方がいらっしゃれば、当社担当者までお問い合わせください。   まとめ 最後に、日本国内でも、 SASE （Secure Access Service Edge、サッシー）、 Cato Networks 、 Catoクラウド （正式名称は、Cato SASE Cloud Platform）の認知度は徐々に上がっていますが、まだまだ高いとは言えない状況です。 SCSKでは、2021年からSASEの主要な４ソリューション（Cato、Palo Alto、Netskope、Cisco）を一同に紹介を行うオンラインセミナー「 SCSK SASE Solution Summit（通称 S4 エスフォー） 」を定期的に開催しております。S4は、これまで述べ2,400名以上の方に参加いただいております。 また、Catoクラウドは、 初心者向けの簡単セミナー から、Cato管理ポータルを利用し主要機能をデモ形式で説明する デモセミナー 、全国各地にて対面で開催する ハンズオンセミナー も定期的に開催しておりますので、ご興味ある方は、ぜひご参加ください。すべて無料です。 Catoクラウド イベント・セミナー情報 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 定期的にCatoクラウドをご紹介するセミナーを開催しております。・2025年9月24日（水）Catoクラウド　デモセミナー　　・2025年10月10日（金）... cato-scsk.dga.jp 各種セミナー以外にも、Catoクラウドの お客様導入事例 の制作、 FAQサイト の運営、この  TechHarmony（技術ブログ） で、Catoクラウドの日本語の情報を提供し、少しでもCatoクラウドの認知度向上と、皆様のお役に立てればと考えております。 当社とご契約のお客様には、Catoのメルマガ配信や、Cato Circleへの案内も行います。 Cato Circle を含め、Catoクラウドに少しでも興味をお持ちになられた方は、ぜひ当社まで お問い合わせ ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27

AWS CDK で開発しながら、最終的には AWS CloudFormation テンプレートでデプロイしたいケースに対応するため、CDK 特有の余計なメタデータ情報を含まない CloudFormation テンプレートを生成する方法を紹介します。 AWS CloudFormation テンプレート生成時の設定方法 1. AWS CDK コード作成 例として Amazon EC2 を作成するコードで説明します。 bin/app.tsにて、CDKからCloudFormationテンプレートを作成する際の設定をcdk.DefaultStackSynthesizerで定義します。 bin/app.ts 　synthesizer設定： const app = new cdk.App(); new Ec2Stack(app, 'EC2Stack', { 　synthesizer: new cdk.DefaultStackSynthesizer({ 　　generateBootstrapVersionRule: false // CDK BootstrapVersionチェックを無効化 　}) }); オプション: generateBootstrapVersionRule: false : BootstrapVersionパラメータとルールを除外する   lib/EC2Stack.ts ： import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; export class Ec2Stack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const subnetId = "subnet-123456789abc"; // EC2インスタンス作成 const ec2Instance = new cdk.aws_ec2.CfnInstance(this, 'Ec2Instance01a', { imageId: 'ami-0bdebfdf585253328', instanceType: 't3.micro', subnetId: subnetId, securityGroupIds: ['sg-abcdefg1234'], iamInstanceProfile: 'instance_profile', keyName: 'keypair-name', disableApiTermination: false, // EBSボリューム設定 blockDeviceMappings: [ { deviceName: '/dev/xvda', ebs: { volumeSize: 30, volumeType: 'gp3', encrypted: true, deleteOnTermination: true } } ], ebsOptimized: true, monitoring: false, metadataOptions: { httpTokens: 'required', }, // タグ設定 tags: [ { key: 'Name', value: 'CDK-Generation-Ec2Instance' }, ] }); } } 2. synthコマンドで AWS CloudFormation テンプレート生成 以下のコマンドを実行し、CloudFormationテンプレートを生成します。 テンプレートは cdk.out 配下に出力されます。 cdk synth <スタック名> --no-path-metadata --no-version-reporting オプション: --no-path-metadata : リソースのMetadata内の aws:cdk:path 情報を除外する --no-version-reporting : CDKバージョン情報を除外する   cdk.out/Ec2Stack.template.json ： Resources: Ec2Instance01a: Type: AWS::EC2::Instance Properties: BlockDeviceMappings: - DeviceName: /dev/xvda Ebs: DeleteOnTermination: true Encrypted: true VolumeSize: 30 VolumeType: gp3 DisableApiTermination: false EbsOptimized: true IamInstanceProfile: instance_profile ImageId: ami-0bdebfdf585253328 InstanceType: t3.micro KeyName: keypair-name MetadataOptions: HttpTokens: required Monitoring: false SecurityGroupIds: - sg-abcdefg1234 SubnetId: subnet-123456789abc Tags: - Key: Name Value: CDK-Generation-Ec2Instance 参考 オプションをつけずにコマンドを実行すると、27行目以降にメタデータ情報が記載されたテンプレートが作成されます。 Resources: Ec2Instance01a: Type: AWS::EC2::Instance Properties: BlockDeviceMappings: - DeviceName: /dev/xvda Ebs: DeleteOnTermination: true Encrypted: true VolumeSize: 30 VolumeType: gp3 DisableApiTermination: false EbsOptimized: true IamInstanceProfile: instance_profile ImageId: ami-0bdebfdf585253328 InstanceType: t3.micro KeyName: keypair-name MetadataOptions: HttpTokens: required Monitoring: false SecurityGroupIds: - sg-abcdefg1234 SubnetId: subnet-123456789abc Tags: - Key: Name Value: CDK-Generation-Ec2Instance Metadata: aws:cdk:path: Ec2Stack/Ec2Instance01a CDKMetadata: Type: AWS::CDK::Metadata Properties: Analytics: v2:deflate64:H4sIAAAAAAAA/zPSMzI01jNQTCwv1k1OydbNyUzSqw4uSUzO1kksL45PTTbSc07L88wrLknMS06t1cnLT0nVyyrWLzMy0jM01jNUzCrOzNQtKs0rycxN1QuC0ACVaq8YVQAAAA== Metadata: aws:cdk:path: Ec2Stack/CDKMetadata/Default Condition: CDKMetadataAvailable Conditions: CDKMetadataAvailable: Fn::Or: - Fn::Or: - Fn::Equals: - Ref: AWS::Region - af-south-1 - Fn::Equals: - Ref: AWS::Region - ap-east-1 - Fn::Equals: - Ref: AWS::Region - ap-northeast-1 - Fn::Equals: - Ref: AWS::Region - ap-northeast-2 - Fn::Equals: - Ref: AWS::Region - ap-northeast-3 - Fn::Equals: - Ref: AWS::Region - ap-south-1 - Fn::Equals: - Ref: AWS::Region - ap-south-2 - Fn::Equals: - Ref: AWS::Region - ap-southeast-1 - Fn::Equals: - Ref: AWS::Region - ap-southeast-2 - Fn::Equals: - Ref: AWS::Region - ap-southeast-3 - Fn::Or: - Fn::Equals: - Ref: AWS::Region - ap-southeast-4 - Fn::Equals: - Ref: AWS::Region - ca-central-1 - Fn::Equals: - Ref: AWS::Region - ca-west-1 - Fn::Equals: - Ref: AWS::Region - cn-north-1 - Fn::Equals: - Ref: AWS::Region - cn-northwest-1 - Fn::Equals: - Ref: AWS::Region - eu-central-1 - Fn::Equals: - Ref: AWS::Region - eu-central-2 - Fn::Equals: - Ref: AWS::Region - eu-north-1 - Fn::Equals: - Ref: AWS::Region - eu-south-1 - Fn::Equals: - Ref: AWS::Region - eu-south-2 - Fn::Or: - Fn::Equals: - Ref: AWS::Region - eu-west-1 - Fn::Equals: - Ref: AWS::Region - eu-west-2 - Fn::Equals: - Ref: AWS::Region - eu-west-3 - Fn::Equals: - Ref: AWS::Region - il-central-1 - Fn::Equals: - Ref: AWS::Region - me-central-1 - Fn::Equals: - Ref: AWS::Region - me-south-1 - Fn::Equals: - Ref: AWS::Region - sa-east-1 - Fn::Equals: - Ref: AWS::Region - us-east-1 - Fn::Equals: - Ref: AWS::Region - us-east-2 - Fn::Equals: - Ref: AWS::Region - us-west-1 - Fn::Equals: - Ref: AWS::Region - us-west-2 まとめ 今回は AWS CDK を使ってメタデータ情報がない AWS CloudFormation テンプレートを生成してみました。 皆さんのお役に立てば幸いです。

SCSK LifeKeeper担当　池田です。 LifeKeeperを使ったHAクラスタシステムを構成したい時、皆さんは誰にお願いしますか？ 社内の情報システム部、普段お世話になっているSIer、メーカーであるサイオステクノロジー社の公式サイトに掲載されているパートナー企業などいろいろあるかと思います。 数多ある選択肢のなかでも、SCSKがなぜLifeKeeperの構築に強く、そしてお客様に選んでいただけるのかを５つの視点でお伝えします。 LifeKeeperの構築は簡単？ LifeKeeperのインストールを経験したことのあるかたはご存じかもしれませんが、実はインストール自体は、専用のGUIから比較的簡単に実施することができます。 ところが、LifeKeeperに限らず、HAクラスタ製品の難しいところは、その周辺の環境を正しく理解し、LifeKeeperの導入に適した状況にする「 設計 」にあります。 この 設計フェーズ における 準備 をいかにきちんと実施し、 OSやネットワーク、セキュリティ等々の設定を 設計通りに実装できるか が、 LifeKeeper導入の 成功のカギ となります 。 WHY SCSK？　なぜSCSKはLifeKeeperに強いのか？ それでは、ここからは本題の「 WHY SCSK？　なぜＳＣＳＫはLifeKeeperに強いのか？ 」という質問にひとつひとつお応えしていこうと思います。 ＳＣＳＫはLifeKeeperの構築実績が豊富 まず第一に、ＳＣＳＫはLifeKeeperの 構築実績が豊富 であるということが挙げられます。 ＳＣＳＫでは、２００４年から ２０年以上 に渡ってLifeeeperのご提案、設計、構築、サポートを行ってきました。お客様の数では１００社を超えます。 その中で、オンプレミス構成、vSphereにおける仮想構成、パブリッククラウド構成といった様々なプラットフォームはもとより、データレプリケーション構成、共有ディスク構成など、ありとあらゆる構成の設計と構築を経験しています。 ＳＣＳＫにはミドルウェアの専門部隊がある 第二に、ＳＣＳＫには、 ミドルウェアの専門部隊 があるということです。 LifeKeeperは、何らかのミドルウェアの可用性を高めたいという目的で導入することから、その対象となるミドルウェアを熟知している必要があります。LifeKeeperと組み合わせる為にはサーバ１台の場合とは異なり、 独特のクセ があります。それはインストールの順番であったり、ディレクトリ構成であったり様々です。 その癖をミドルウェアメーカーやLifekeeperの公式サイトから正確に読み取ることは、なかなか至難の業で、 深い見識とノウハウがものをいう 部分でもあります。 ＳＣＳＫでは、長年に渡りミドルウェア部隊とLifeKeeper部隊で豊富な経験と技術の蓄積をもとに阿吽の呼吸で協力しながら取り進められることから、 高品質な構成をお届けできる体制が整っています 。 ＳＣＳＫはインフラ環境の特性に合わせた設計・構築に強い 第三に、ＳＣＳＫはインフラ環境の特性に合わせた設計が得意です。もう少し具体的に申し上げますと、例えばAmazon Web Services(AWS)における構成一つとっても、通信要件によって様々な接続方式があります。例えば自社オンプレサーバとの接続でDirectConnectを用いた接続や、TransitGateway経由のルートテーブルを用いた接続、Route53を用いた接続、Network Load Balancer (NLB) からの接続などのパターンがありますが、通信要件に合わせ最適な接続方式の実装実績とご提案が可能です。 ＳＣＳＫは技術者認定資格保有数が世界一 第四に、ＳＣＳＫには、サイオステクノロジー社の技術者認定資格(2024年10月31日提供開始)の保有数が１２０以上を超え、 世界一 (2025年3月末時点) となっています。これはLifeKeeperをどのSIerよりも詳しいということを意味しております。 現在、提供されている技術者認定資格としては、以下２つの内容となります。 LifeKeeper for Linux 技術者認定資格（BASIC） LifeKeeper for Windows　技術者認定資格（BASIC） ＳＣＳＫはサイオステクノロジーとの関係が深い 第五に、ＳＣＳＫはLifeKeeperのメーカーである サイオステクノロジー社との関係が深い 点が挙げられます。 １でもお伝えした通り、２０年以上に渡って、サイオステクノロジー社とは、営業責任者、開発責任者、サポート責任者とも頻繁に打合せを重ねており、密な情報連携を図っています。 その為、構築中に不測の事態が発生した際に、即座にサイオステクノロジー社と連携を取り、双方協力しながら解決に導くことが可能です。 これは長年に渡って、「お客様により良い製品をお届けしたい」というSCSKとサイオステクノロジー社の熱い想いを持って喧々諤々の議論を重ねていることによる、信頼関係によるところが大きいと自負しています。 まとめ 今回、 WHY SCSK？　～　なぜSCSKはLifeKeeperに強いのか？ という問いに対してする５つのご回答を挙げました。 １．豊富な構築実績 ２．ミドルウェアの専門部隊とのタッグ ３．インフラ環境の特性に合わせた設計・構築が得意 ４．技術者認定資格保有数が世界一 ５．サイオステクノロジー社との関係の深さ LifeKeeperの導入を誰にお願いするか迷われた際には 、本記事をご参考にしていただき、 是非経験豊富なＳＣＳＫにお任せください 。 LifeKeeperについて、詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは。SCSKの山口です。 今回は、Google Cloud認定資格の受験レポート その②です。 はじめに 先日投稿した受験前レポートをまだご覧になっていない方はまずはこちらをご覧ください。 【Google Cloud】Generative AI Leader 受験前レポート Google CloudのGenerative AI Leader資格対策を徹底解説。試験ガイドに基づいた重要キーワード（ファインチューニング、RAGなど）と主要サービス（Gemini, Vertex AIなど）の概要、特徴、ユースケースを網羅。 blog.usize-tech.com 2025.06.09   受験前レポートの投稿からちょっと時間が空いてしまったのですが、実は一発目のチャレンジ（英語試験）で落ちてしまいました。。 内容が難しかったというより、英文の問題文をうまく読み解けていなかった気がします。 久々の不合格でショックを受けていたのですが、 「Google CloudのAll Certificationが始まるから落ち込んでられない、、」 と何とか立ち直りました。 Google Cloud Partner All Certification Holders 2025 応募開始 | Google Cloud 公式ブログ cloud.google.com   そんな中、タイミングよく 日本語版の試験がリリース されました。 二度目の挑戦（日本語試験）では無事合格できたので、受験後レポートを書こうと思います。   受験前とのギャップ その①ブログでも書いている通り、Google Cloudの生成AI関連サービスが多く問われそうな印象でしたが、ここはまさにその通りでした。 ただし、問題文に要件が書いてあって、選択肢から適切なサービスを選択するようなシンプルな問題もあれば、 ○○の要件に合わせて、△△サービスを選定しましたが、これは△△サービスのどの特徴を活かしたものですか？ のような問題も多くでました。 選択肢がすべて正しいこと（サービスの特徴）を言っているものもあったので、ちょっと時間をかけて考えました。 初級の資格ではありますが、 各サービスの特徴/長所 のような一歩踏み込んだ内容についても抑えておくとかなり有利です。   各サービスの特徴/長所に関しては、その①ブログにも「特徴」「ユースケース」としてまとめているのでそちらをご覧ください。 【Google Cloud】Generative AI Leader 受験前レポート Google CloudのGenerative AI Leader資格対策を徹底解説。試験ガイドに基づいた重要キーワード（ファインチューニング、RAGなど）と主要サービス（Gemini, Vertex AIなど）の概要、特徴、ユースケースを網羅。 blog.usize-tech.com 2025.06.09   個人的頻出ワード 今回は、その①に登場したサービス・概念を、個人的な主観と記憶を頼りにランク付けしていきます。   機械学習の基礎概念 キーワード ランク（★が多いほど頻出） 教師あり学習 ★★ 教師なし学習 ★★★ 深層学習（ディープラーニング） ★ 強化学習 ★★★ 問われ方としては、「この学習方法はどれですか？」という基本的な問われ方が多かったです。 個人的に、「教師なし学習」と「強化学習」を選択させるような問題が多かったので、★3つにしました。 深層学習は登場していなかった気がします。（もしかしたらダミー選択肢に居たかも。）   Generative AIの応用とカスタマイズ＋運用 キーワード ランク ファインチューニング ★ プロンプトエンジニアリング ★★★ RAG ★★★ グラウンディング ★★ ヒューマンインザループ ★ プロンプトエンジニアリング、RAGがとにかく出題された気がします。 企業が生成AI活用で直面している問題に対してどの手法を用いるか？という観点で選択肢を選ぶ問題が頻出です。 プロンプトエンジニアリング、RAGそれぞれで解決できるケースをイメージできるようにしておきましょう。   基盤モデル・ソリューション キーワード ランク Gemini ★★★ Gemma ★★ Veo ★★ Imagen ★★★ NotebookLM ★★★ Gemini for Google Workspace ★ Agentspace ★★★ Conversational Agents ★★ Contact Center as a Service ★★ ここが問われる問題が一番多かった印象です。 特にGemini、Agentspaceあたりは★10個くらいつけたいくらい問われます。 その他のキーワードに関しても、概要が頭に浮かぶようにしておいた方が良いです。   まとめ 英語版の試験で一度落ちてしまいましたが、日本語版で再度受験し、難易度的には初級に近いなという印象を受けました。 今回ご紹介したキーワードの概要がイメージでき、説明レベルになっていれば十分戦えるのではないかと思います。（※あくまで202509時点の筆者の主観です。） 個人的には、最先端を走るGoogleのAI関連サービスを知ることができる良い試験だと思います。 まだGoogle Cloudの認定資格にチャレンジしたことがない方も是非チャレンジしていただきたいと思います。

こんにちは SCSKの庄司です。 今回はServiceNowの修復スクリプト（Fix Script）について紹介していきます。 本記事は執筆時点（2025年9月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。 修復スクリプト（Fix Script）とは Fix Script は、アプリのインストール／アップグレード後に走らせて、データや設定の補正・初期化・移行を行うためのサーバサイド JavaScript です。 更新セットやアプリ更新だけでは反映しきれない、 既存データの補正 特定条件のデータの作成・更新 など、大量のデータを一回のみ、自動更新・作成することに向いています。 逆に「任意タイミングで複数回実行するスクリプト」や「定期的なスクリプト実行」はスケジュール済みジョブなどが適しているので、そちらの利用を検討してください。 修復スクリプトレコードはsys_script_fixテーブルに格納されており、 すべて > システム定義 > 修復スクリプト から遷移可能です。   修復スクリプトレコードのオプション   読み込み不能 ：チェックをするとスクリプト実行時に顧客アップデートレコードを作成する。必要に応じて顧客アップデートレコードを更新セットに格納し、移送することも可能に。 ロールバック用に記録 ：ロールバック用にスクリプトの実行を記録し、必要に応じて元に戻すことが可能になる。 前 ：アプリのインストールまたはアップグレード前にスクリプトを実行することができる。   実行前の注意事項 事前検証 ：本番前に開発環境やPDIでテスト ロールバックを有効化 ：ロールバック用に記録にチェックをしてから実行 バックアップ ：更新対象のレコードを事前にCSVエクスポート 負荷配慮 ：業務時間帯の実施は環境に負荷を与えるため控える（特に大量のレコードを更新する場合）   修復スクリプトの実践 では、ここからは簡単な修復スクリプトを実際に使ってみようと思います。 すべて > システム定義 > 修復スクリプトに遷移し、[新規]を押下します。 今回は以下の条件で実施します。 読み込み不能 ：true ロールバック用に記録 ：true 前 ：false 以下のスクリプトを記載します。 指定したカタログ配下にあるアクティブなすべてのカタログアイテムに対して、「利用可能」のユーザー基準を作成するスクリプトです。 // ===== 設定 ===== var catalogSysId = '742ce428d7211100f2d224837e61036d'; // 本番対象カタログ sys_id var userCriteriaSysId = '322f2efa83bb6210b7e5f9a6feaad35d'; // 付与する User Criteria の sys_id // ================= // 対象アイテムを取得 var grItem = new GlideRecord('sc_cat_item'); // カタログ配下の全アイテム grItem.addQuery('sc_catalogs', catalogSysId); gs.info('=== カタログ ' + catalogSysId + ' 配下のアイテムすべて ==='); grItem.addQuery('active', true); grItem.query(); var count = 0; while (grItem.next()) {   // 既存レコードの重複チェック   var grCheck = new GlideRecord('sc_cat_item_user_criteria_mtom');   grCheck.addQuery('sc_cat_item', grItem.sys_id);   grCheck.addQuery('user_criteria', userCriteriaSysId);   grCheck.query();   if (!grCheck.hasNext()) {       var grNew = new GlideRecord('sc_cat_item_user_criteria_mtom');       grNew.initialize();       grNew.setValue('sc_cat_item', grItem.sys_id);       grNew.setValue('user_criteria', userCriteriaSysId);       grNew.insert();       count++;       gs.info('ユーザー基準を追加: ' + grItem.name);   } else {       gs.info('すでに存在: ' + grItem.name);   } } gs.info('合計 ' + count + ' 件のレコードを作成しました。'); 今回 の対象となるユーザー基準とカタログは以下になります。 ユーザー基準：fix script test user criteria カタログ：Technical Catalog 利用可能なカタログアイテムテーブルとロールバックコンテキストテーブルに該当するレコードが存在しないことを確認します。 では、[スクリプト修復の実行]を押下し、今回は[続行]を押下します。     修復スクリプトが実行され、ログが表示されています。 今回はスクリプト内で記載していたため、ユーザー基準を追加したカタログアイテム名と合計レコード作成数がログに表示されています。 では、実行結果を確認しに行きます。 まず、 利用可能なカタログアイテムテーブルを見ると実際に6レコード分のレコードが作成されています。 次に、今回は「読み込み不能」をtrueにしているので顧客アップデートテーブルも確認しに行きます。 先ほど作成したレコードの顧客アップデートレコードが作成されています。   必要に応じてこちらのレコードを顧客アップデートレコードに追加することで、別環境に移送することが出来ます。 今回は「ロールバック用に記録」もtrueにしているのでロールバックコンテキストテーブルにもレコードが作成されています。 ロールバックコンテキストレコードを開くと、「ロールバックレコード」関連リストに今回のスクリプト実行に際して作成されたレコード（sc_cat_item_user_criteria_mtomレコード、sys_update_xmlレコード、sys_update_versionレコードsys_metadata_customizationレコード）が紐づけられています。   せっかくなので、今回はロールバックまで実行してみようと思います。 [ロールバック]関連リンクを押下すると、「Execute Rollback?」というポップアップが表示されるので、「yes」と入力し、[OK]を押下します。 ロールバックが完了しました。 先ほどと同じ条件で利用可能なカタログアイテムテーブル、顧客アップデートテーブルを確認すると、レコードが表示されません。     まとめ 以上、今回はServiceNowの修復スクリプト（fix script）を紹介しました。 あまり使う機会はないかもしれませんが、特定のシチュエーションでは大きく力を発揮する機能です。 ぜひ参考にしてみてください。

こんにちは。SCSKの清水です。 2025/9/10(水)に開催された「Microsoft AI Tour Osaka」に参加しましたので、その参加レポートを投稿します。本記事では、 基調講演の内容を中心に、イベントの雰囲気や得られた気づき をレポートしていきます。 はじめに イベント概要 Microsoft AI Tourは、世界各地で開催されているMicrosoft主催のAIイベントシリーズで、最新のAI技術や活用事例を紹介する場として注目を集めています。今回の大阪開催は、日本国内では東京に続く2回目の開催となり、関西圏の技術者・ビジネス関係者に向けて、AIによる業務変革や組織づくりに関する知見が共有されました。 イベントでは、Microsoftの最新AIソリューションに関する講演やデモが行われ、基調講演から技術セッション、展示ブースまで幅広いコンテンツが展開されました。 Microsoft AI Tour Osaka 「Microsoft AI Tour Osaka」は、AI の最新イノベーションを体験し、業界のソートリーダーや専門家とつながることができる、ビジネスリーダーと開発者のためのイベントです。キーノート、ブレイクアウトセッション、ハンズオン ワ... www.microsoft.com 参加目的 私はPowerPlatform関連、特にCopilot Studio目当てで参加しました。 Microsoft Build 2025でも多くのアップデートが発表されて、それらの機能がパブリックされていっています。機能としては理解しているものの、どのように活用するかのアイデアを収集したいと考え、参加を決めました。 基調講演 基調講演のタイトルは「 Becoming Frontier: AI で実現するフロンティア組織への進化とビジネス変革 」です。基調講演では、日本マイクロソフトの代表取締役社長である津坂 美樹氏が登壇されました。ここでは、基調講演の内容を少し紹介します。（内容の解釈に一部誤りがあるかもしれません。ご参考までに。） 基調講演は2025/9/21現在、Youtubeにてアーカイブ配信されています。ぜひ実際の講演内容をご覧ください。 - YouTube YouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。 aka.ms なお、基調講演とは「 イベントの冒頭に行われる中心的な講演で、テーマや方向性を示す講演 」のことです。 フロンティア組織への進化 フロンティア組織とは「 AIを活用して様々な課題を解決するためにAIトランスフォーメーションを推進している企業 」と定義されました。フロンティア組織になるために、Microsoftがどのように支援ができるか、というのが基調講演のメイントピックです。 基調講演では、フロンティア組織になるための成功の枠組みとして、以下の4点が挙げられていました。この4点の枠組みに対して、CopilotなどのAIソリューションを用いてアプローチすることでフロンティア組織への進化に至るということでした。 従業員エクスペリエンスの強化 顧客エンゲージメントの強化 ビジネスプロセスの再構築 イノベーションの加速 以降ではフロンティア組織の具体例として、 Zavaという架空の企業を題材に、MicrosoftのAIソリューションのデモを交えながら、戦略立案～開発までのシナリオ が説明されました。 最近のAIイベントでは、技術の仕組みや機能紹介よりも、「業務にどう活かすか」「どのような成果が出ているか」といった活用事例の紹介が中心になってきている印象を受けます。 Copilotを代表としたAIが“使えるサービス”として展開されている今、企業や組織が次に向き合うべきは“どう使うか”という問いなのだと改めて感じます。 それでは、4点の成功の枠組みに対してもう少し詳しく話していきます。 ①従業員エクスペリエンスの強化 AIを活用して社員の業務効率や創造性を高め、働き方そのものを進化させることです。 AIが単なるツールではなく、社員の判断力や創造性を引き出す存在として機能します。 ここで登場したのがM365 Copilotです。M365 Copilotが情報収集だけでなく分析といった複雑な思考を担ってくれます。M365 Copilotのリサーチャーエージェントやアナリストエージェントは2025/6に公開された機能のため、まだ業務に活用していない人も多いのではないでしょうか。 また、Copilot Studioではより社内の規定といった特定の社内情報のみを参照するカスタムエージェントを作成できます。M365 Copilotのみでは手の届かない領域もCopilot Studioを使用することで幅広い領域をCopilotに任せることができます。 活用されたソリューション Zavaでの活用シーン M365 Copilot リサーチャーエージェントによってZavaの脅威となる競合他社の情報を収集。 アナリストエージェントによってローンチ戦略を分析。 Copilot Studio 社内の様々な規定情報を参照したカスタムエージェントを作成。 Zavaの情報を参照してローンチ計画を策定。 ②顧客エンゲージメントの強化 人間が従来行っていた作業をAIが代理で担うことで、これまでにない顧客体験を創造することです。 例えば、コールセンター業務などはこれまで人間が担っていたことで、応対時間や応対数に制限がありました。これをAIに置き換えることにより24時間365日で即時対応可能なサービスを提供することができます。 また、AIを活用することで顧客のニーズを製品開発やマーケティングに迅速に反映させることができます。GitHub Copilotでは自然言語によるプロトタイプ開発から本番リリースまでのプロセスを短縮します。今回は特にVibe Codingの代表的な機能であるGitHub Sparkが紹介されていました。 さらには、AIを製品に組み込むためにAzure AI Foundryを使用します。1000を超えるモデルを選択可能で、独自のAIを柔軟にカスタマイズしてアプリケーションに配置することができます。 活用されたソリューション Zavaでの活用シーン GitHub Copilot 開発チームがマーケティング部門によるテストを想定した新アプリを迅速に発案及び試作 Azure AI Foundry 開発チームがアプリを改良し、大規模展開に向けて強化 ③ビジネスプロセスの再構築 エージェントを活用することを前提として、既存のビジネスプロセスを再構築することです。 ここではM365 Copilot＋Excelでの財務調整エージェントが登場し、このトピックの主役でした。この機能は2025年リリース サイクル2でリリース予定の機能になっており、イベント開催時点ではリリース前の機能です。 （具体的な機能性については私の理解が及んでいない点がありますが）Excel上にエージェントが搭載され、データ分析やレポート作成の負荷が大幅に軽減されます。 活用されたソリューション Zavaでの活用シーン M365 Copilot+Excel 財務調整エージェントを自律的に動作するように訓練 Dynamics 365 財務部門がエージェントを活用し、期末締め処理を自動化 Microsoft 365 2025 年リリース サイクル 2 の財務エージェントの概要 Microsoft 365 2025 年リリース サイクル 2 の財務エージェントの概要 learn.microsoft.com ④イノベーションの加速 ここでは特に、 蓄積された膨大なデータを活用して新たなプロダクトを創造すること（を継続していくこと） 、とされています。 当然ですが開発された製品・サービスはリリースされたのちに改善活動を繰り返していきます。このとき、ユーザーから収集したデータをどのように活用できるかが継続的なイノベーションに欠かせません。 ここでMicrosoft Fabricが登場します。Microsoft Fabricはデータ統合プラットフォームとして多様な機能を有しています。 今回は特にデータの可視化としてデジタルツインの機能が目玉だったかと思います。Microsoft Fabricで様々なチャネルから蓄積されたデータをもとにデジタルツインを構築します。デジタルツインを活用することで対話型に、よりユーザーが親しみやすい形でデータを活用することができます。 活用されたソリューション Zavaでの活用シーン Microsoft Fabric 研究開発部門がFabricのデジタルツインを活用し、反復的改善、イノベーション、パフォーマンスの監視を実施 Microsoft Azure 研究開発部門がAzureを活用し、データの可視化とエージェントによるデータ活用を実施 基調講演の感想 特に印象的だったのは、事例を用いるのではなく、MicrosoftがZavaという架空の企業を用いて、AIソリューションによる業務変革の流れを具体的に描いていた点です。マーケティング、開発、財務といった部門ごとにCopilotやFabricなどのツールがどのように活用され、組織全体が“フロンティア化”していく様子が示されていました。単なる機能の紹介ではなく、 AIによる組織進化の“解像度”が高まった と感じました。 以上、簡単に基調講演のまとめになります。 この他に大阪府の吉村知事などフロンティア組織のリーダーが各組織での取り組みを紹介する内容もありますので、ぜひYoutubeのアーカイブ配信をご覧ください。 さいごに 全体の感想 今回のMicrosoft AI Tour Osakaは、技術者としての視点からも、実務に携わる立場からも、非常に充実した体験となりました。 イベント全体を通して、MicrosoftがもたらすAIの可能性を肌で感じることができ、何より純粋に楽しく、刺激的な時間でした。 特に楽しめた要因は、紹介された内容が自分のスキル領域と高い親和性を持っていたこと。PowerPlatformやCopilot Studio、Azure AI Foundryなど、日々関わっている技術がどのように フロンティア組織 の構築に活かされているかを明確にイメージできました。 また、Microsoftの吉田大貴さん、ギークフジワラさん、増田雄一さんといった著名な技術者・エバンジェリストの方々の話を直接聞けたことも大きな収穫です。彼らの語るビジョンや現場感は、資料や動画だけでは感じられない熱量を伴っていて、ただ話を聞くだけでなく実感としての理解が得られたように思います。 このイベントを通じて得た知見や気づきを、今後の業務や社内発信にどう活かしていくかが次のチャレンジです。 Microsoft AI Tour 2026に参加するには 東京開催の日付が公開されており、2026/3/24のようです。最新の情報は以下のサイトからご確認ください。 Microsoft AI Tour Osaka 2025では事前登録が必要でした。1か月ほど前から満席になり、キャンセル待ちになっていましたので、お申し込みはお早めに！ Microsoft AI Tour Take the inside track to the AI frontier at the Microsoft AI Tour. Learn from experts, explore real-world strategies, an... aitour.microsoft.com