こんにちは、SCSKの齋藤です。 皆さん、日々のクラウドセキュリティ運用で、こんな課題に直面していませんか？ 「あれ、このVMのポート、外部に開けっ放しじゃないか？」 「新しいストレージバケットが作られたけど、パブリック公開の設定になってないか心配だ…」 「不審なアクセスアラートが多すぎて、どれから対応すべきか分からない…」 クラウド環境は、その柔軟性とスケーラビリティでビジネスに多大な恩恵をもたらしますが、同時にセキュリティ管理の複雑性を増大させます。複数のプロジェクト、多種多様なサービス、日々刻々と変化するリソース群…これらのセキュリティ状態を常に正確に把握し、潜在的なリスクに迅速に対応することは、決して容易ではありません。 こうした状況を打開し、クラウドセキュリティの「見える化」と「運用効率化」を加速させるべく、私たちはGoogle Cloudが提供する統合セキュリティ管理プラットフォーム、「 Security Command Center（SCC） 」の導入に踏み切りました。 本記事では、SCCを実際に有効化し、利用してみた経験に基づき、SCCが提供する主要な機能、多くの企業が検討時に気になるであろう「 スタンダードティアとプレミアムティアの比較 」、そして「 料金設定 」について、実践的な視点から解説していきます。クラウド環境のセキュリティ管理にお悩みの皆様にとって、本記事が具体的な解決策を見つけるための一助となれば幸いです。 クラウドセキュリティにおける現在の課題とSCCの必要性 現代の企業がクラウド環境において直面するセキュリティ課題は多岐にわたります。これらの課題が、従来のセキュリティ運用手法では対応しきれないレベルに達していることが、SCCのような統合プラットフォームの必要性を高めています。 リソースの膨大化と可視性の欠如 GCP環境では、仮想マシン（VM）、データベース、ストレージ、ネットワーク設定など、多種多様なリソースが瞬時にデプロイされ、変更されます。大規模な組織では、これらのリソースが数千、数万に上ることも珍しくありません。個々のリソースに対するセキュリティ設定の確認や、全体像の把握は極めて困難であり、設定ミスやポリシー違反が潜在的な脆弱性として放置されるリスクが高まります。特に、シャドーITや非公式なリソース展開が発生した場合、それらのセキュリティ状態を把握することはほぼ不可能です。 セキュリティ情報のサイロ化と統合の困難さ 従来のセキュリティ運用では、脆弱性スキャナー、脅威検出システム、アクセスログ監視ツールなど、複数のセキュリティツールを個別に導入・運用することが一般的でした。これらのツールはそれぞれ特定の領域に特化した情報を提供しますが、その情報がバラバラに管理されるため、全体的なセキュリティ状態を把握し、優先順位を付けて対応することが困難になります。結果として、重要なアラートが見過ごされたり、インシデント対応の初動が遅れたりするリスクが増大します。 手作業による運用限界とアラート疲労 クラウド環境は常に変化しており、新しいリソースのデプロイ、設定変更、脅威の発生などが日常的に発生します。これらすべてを手作業で監視し、アラートに対応するには膨大な時間と人的リソースを要し、ヒューマンエラーのリスクも高まります。また、各ツールから大量に発報されるアラートの中から、本当に対応すべき「重要」なアラートを特定することが難しく、セキュリティ担当者が「アラート疲労」に陥り、重要なアラートを誤って見過ごしてしまう状況も頻繁に発生します。 コンプライアンス要件への継続的な対応 GDPR、HIPAA、PCI DSS、日本の個人情報保護法など、業界や地域ごとに多様なコンプライアンス要件が存在します。これらの要件に継続的に準拠していることを証明するためには、定期的な監査と継続的なセキュリティ状態の確認が不可欠です。手作業によるコンプライアンスチェックは非常に負担が大きく、またリアルタイムでの準拠状況の把握が困難です。 これらの課題を解決し、クラウド環境におけるセキュリティの可視性、効率性、対応能力を飛躍的に向上させるプラットフォームとして、Google Cloud Security Command Centerが位置づけられます。SCCは、GCP環境全体のセキュリティリスクを「発見」「調査」「対応」するための一元化されたプラットフォームであり、クラウドセキュリティの「司令塔」としての役割を担います。 Security Command Center（SCC）とは？ Google Cloud Security Command Center（SCC）は、GCP環境全体におけるセキュリティの状態を包括的に把握し、潜在的な脅威や脆弱性をプロアクティブに管理するための統合プラットフォームです。SCCを導入することで、以下の主要な課題を解決し、セキュリティ運用に新たな価値をもたらします。 SCCが提供する主要な価値 SCCは、主に以下の3つの主要な価値を提供することで、クラウドセキュリティ運用の変革を促進します。 1. 包括的な可視性（Visibility）： GCP環境内に存在するすべてのアセット（リソース）を自動的に検出・インベントリ化し、常に最新の状態を把握できるようにします。これにより、どのプロジェクトにどのようなリソースが存在し、それらがどのような設定になっているかを一元的に確認できます。さらに、既知の脆弱性、設定ミス、コンプライアンス違反、不審な活動などを自動で検出し、それらを「発見事項（Findings）」として集約します。これにより、「何がどこにあるか」「どこに脆弱性があるか」「何が起きているか」という基本的な問いに対する答えが明確になります。 2. 優先順位付けと調査の効率化（Prioritization & Investigation）： 検出された膨大な数の発見事項に対し、その深刻度や影響度に基づいて優先順位を自動的に付与します。これにより、セキュリティチームは、対応すべき最も重要なリスクに集中し、限られたリソースを最適に配分できます。各発見事項には詳細な情報（関連するアセット、影響範囲、推奨される是正措置など）が付与されており、セキュリティアナリストによる調査を効率化し、迅速な意思決定を支援します。 3. 対応と自動化の促進（Response & Automation）： SCCが検出した発見事項は、APIを通じて外部のセキュリティ運用ツール（SIEM、SOARなど）と連携することが可能です。これにより、検出された脅威や脆弱性に対する自動的な対応ワークフローを構築し、手動での介入を最小限に抑えながら、迅速かつ効果的なインシデントレスポンスを実現します。また、コンプライアンス監査への継続的な準拠状況を可視化し、レポート生成を支援することで、監査対応の効率化にも貢献します。   SCCを有効化してみた！ 複数のプロジェクトを横断して包括的な監視を行いたかったため、組織レベルでのSCC有効化を選択しました。 有効化プロセスは想像以上にスムーズ SCCの有効化プロセスは、驚くほど簡単でした。 GCP Consoleにログインし、SCCダッシュボードへ移動。 「Security Command Centerを有効にする」ボタンをクリック。 組織レベルでの有効化を選択し、組織IDを確認。 必要なサービスアカウントの作成と権限付与は自動で行われます。 数クリックで有効化完了！ 正直なところ、設定に悩む時間はほとんどありませんでした。有効化後、すぐにデータが収集され始めるわけではありませんが、最初の完全なアセットインベントリの収集には数時間から最大24時間程度かかる旨のメッセージが表示されました。   SCCの核心機能深掘り SCCはクラウド環境のセキュリティライフサイクル全体を支援するための、多岐にわたる機能を提供します。 アセットインベントリ SCCの基盤となるのは「アセットインベントリ」機能です。GCP環境内に存在するすべてのリソースを自動的に検出し、体系的にカタログ化します。これにより、セキュリティ担当者は以下のことを実現できます。 リソースの網羅的な把握:  どのプロジェクトに、どのような種類のVM、ストレージ、データベース、ネットワークが存在するのかを常に最新の状態で把握できます。シャドーITや意図しないリソース展開のリスクを低減します。 設定情報の詳細化:  各アセットのIAMポリシー、ネットワーク設定、公開設定などの詳細情報を確認できます。これにより、「このバケットは本当にパブリック公開が必要なのか？」といった疑問に迅速に答えることができます。 脆弱性検出 SCCは、Googleが提供する様々なセキュリティ検出サービスと連携し、GCP環境内の脆弱性や設定ミスを自動的に検出します。 Security Health Analytics (SHA):  GCPリソースの設定ミスや構成上の脆弱性を継続的にスキャンします。広範なIPアドレスからのSSHアクセス許可、公開設定になっているCloud Storageバケット、過剰な権限を持つIAMロールなどを検出します。また、CISベンチマーク（Center for Internet Security）などの業界標準セキュリティベンチマークへの準拠状況を評価し、具体的な改善推奨事項を提供します。 Web Security Scanner (WSS):  GCP上で稼働するWebアプリケーションの一般的な脆弱性（XSS、SQLインジェクションなど）を検出します。定期的なスキャンを設定することで、新たな脆弱性が生まれていないかを継続的に監視できます。 Container Threat Detection (CTD):  GKE（Google Kubernetes Engine）環境のランタイム動作を監視し、コンテナ内での不審なアクティビティ（特権昇格、マルウェア実行、不審なバイナリ実行など）を検出します。 脅威検出 脆弱性の検出だけでなく、実際に発生している、あるいは発生しようとしている脅威をリアルタイムで検出することも、SCCの重要な役割です。 Event Threat Detection (ETD):  Cloud Audit Logs、VPC Flow Logs、DNS logsなど、GCPの様々なログデータを継続的に監視し、機械学習と脅威インテリジェンスを活用して不審な活動を検出します。ブルートフォース攻撃、認証情報の不正使用、マルウェア感染の兆候、データ流出の試み、サービスアカウントの異常な動作などを検出します。 Cloud DLP (Data Loss Prevention) 連携:  Cloud StorageバケットやBigQueryデータセットなどに保存されている機密データをスキャンし、発見された機密データに基づいてリスク（例：不適切な公開設定のバケットに機密データが存在する）をSCCに報告します。 スタンダードティア vs プレミアムティア SCCには、「スタンダードティア」と「プレミアムティア」の2つのサービスティアが存在します。それぞれ提供される機能の範囲と料金体系が大きく異なるため、組織の規模、セキュリティ要件、予算に応じて最適なティアを選択することが非常に重要です。 スタンダードティア スタンダードティアは、SCCの基本的な機能を提供し、 無料 で利用できます。クラウドセキュリティの「見える化」をこれから始める組織や、コストを抑えたい場合に適しています。 スタンダードティアで利用できる主な機能： アセットインベントリ:  GCP環境内のすべてのリソースを自動的に発見し、インベントリ化します。 Web Security Scanner (WSS):  GCP上でホストされているWebアプリケーションの一般的な脆弱性をスキャンし、検出結果をSCCに集約します。 Google Cloud Armor との統合:  Google Cloud ArmorのDDoS保護やWAFに関する情報がSCCに表示されます。 基本的な脅威検出:  Google Cloudの脅威インテリジェンスを活用した基本的な脅威情報が提供されます。 スタンダードティアのメリット： 無料:  コストをかけずにクラウド環境の基本的なセキュリティ状況を把握できます。 手軽に導入可能:  複雑な設定は不要で、すぐに使い始められます。 基本的な可視性の確保:  リソース把握やWebアプリケーションの初期脆弱性検出の第一歩として最適です。 プレミアムティア プレミアムティアは、スタンダードティアのすべての機能に加えて、より高度な検出機能、自動化、コンプライアンス管理、調査ツールを提供します。 有料 サービスですが、その分、強固なセキュリティ体制を構築するための強力なツールとなります。 プレミアムティアで利用できる主な追加機能： Security Health Analytics (SHA) の高度な検出:  スタンダードティアのWSSよりもはるかに広範なGCPリソースの設定ミス、不適切なIAMポリシー、ネットワーク構成の脆弱性などを継続的にスキャンします。CISベンチマークなどの業界標準セキュリティベンチマークへの準拠状況を自動評価し、具体的な改善推奨事項を提供します。 Event Threat Detection (ETD):  GCPの各種ログデータ（Cloud Audit Logs, VPC Flow Logs, DNS logsなど）をリアルタイムで分析し、機械学習とGoogleの脅威インテリジェンスを活用して、高度な脅威（認証情報の不正使用、マルウェア実行、異常なデータ抽出など）を検出します。 Container Threat Detection (CTD):  GKE環境でのコンテナランタイムにおける不審な活動を検出します。 Rapid Vulnerability Detection (RVD):  特定の重大な脆弱性（例：Log4jの脆弱性）が存在しないかを迅速にスキャンし、影響を受けるリソースを特定します。 Findings APIと高度なエクスポート機能:  SCCが検出したすべての「発見事項（Findings）」にプログラムでアクセスできるAPIを提供します。これにより、検出結果をSIEMやSOARツールと連携させ、自動化された対応ワークフローを構築できます。BigQueryへのエクスポート機能により、長期的な分析やカスタムレポート作成も可能です。 脅威の優先順位付けと調査機能の強化:  検出された Findingsの中から、最も重大な脅威や脆弱性を自動的に優先順位付けし、対応すべき事項を明確にします。 プレミアムティアのメリット： 包括的なセキュリティ可視化:  アセットから脆弱性、脅威、コンプライアンスまで、GCP環境全体のセキュリティ状況を深く掘り下げて可視化します。 高度な脅威検出:  機械学習とGoogleの脅威インテリジェンスにより、洗練された攻撃や異常な行動を早期に発見できます。 コンプライアンス管理の効率化:  CISベンチマーク対応などにより、規制要件への準拠状況を継続的に評価・報告できます。 自動化と連携:  APIを通じて、既存のセキュリティツールやワークフローとの連携が容易になり、自動化された対応が可能になります。 どちらを選ぶべきか？判断基準 比較項目 スタンダードティア プレミアムティア 料金 無料 有料（アクティブなアセット数に応じた従量課金） アセットインベントリ ○ (基本的) ○ (詳細、長期履歴保持) 脆弱性検出 Web Security Scanner (WSS) のみ SHA, ETD, CTD, RVD, VMM連携など、広範かつ高度な検出 脅威検出 基本的な脅威情報 高度な機械学習ベースのリアルタイム脅威検出 (ETD, CTD) コンプライアンス 制限的 CISベンチマーク評価など、体系的なコンプライアンス管理 自動化/連携 制限的 高度なAPI連携 (Findings API)、SIEM/SOAR統合 データ保持期間 短い（数日～数週間） 長い（数カ月） 推奨組織 小規模、セキュリティ初心者、コスト重視、まず可視化したい 大規模、高セキュリティ要件、専門チームあり、包括的管理志向 クラウドセキュリティへの取り組みをこれから始める方や、GCP環境が比較的小規模な場合は、まず スタンダードティアでSCCの基本的な可視化能力を体験することをお勧めします。 その後、GCP環境の拡大やセキュリティ要件の高まりに応じて、プレミアムティアへのアップグレードを検討するのが賢明なアプローチと言えます。 気になる料金設定 SCCプレミアムティアの導入を検討する際、多くの方が気になるのが料金体系だと思います。SCCプレミアムティアの料金モデルは、主に「 組織内のアクティブなアセット数 」に基づいて計算されます。 基本的な料金モデルの概要 SCCプレミアムティアの料金は、 組織内のアクティブなアセット（リソース）の数 によって決まります。具体的には、主要なGCPアセットタイプ（Compute Engine VMインスタンス、Cloud SQLインスタンス、Cloud Storageバケット、BigQueryデータセット、GKEクラスターなど）がカウント対象となります。 料金は、これらのアクティブなアセットタイプごとに設定された単価（例：「VMインスタンス1台あたり月額Xドル」）に基づき、合計で算出されます。最新かつ正確な料金情報は、常に Google Cloudの公式料金ページ で確認するようにしてください。 コスト最適化のためのヒント SCCプレミアムティアの利用料金を最適化するために、いくつかの重要なポイントがあります。 不要なアセットの定期的なクリーンアップ:  SCCはアクティブなすべてのアセットをカウントします。開発やテストで一時的に作成され、その後放置されているVMやストレージバケットなどがないか定期的に確認し、不要なものは削除しましょう。これはコスト削減だけでなく、セキュリティリスク（未管理のリソースに脆弱性が放置されるなど）の低減にも繋がります。 監視対象のスコープを最適化:  組織内の全てのプロジェクトやフォルダをSCCの監視対象にする必要があるか再検討します。非常に機密性の低い、あるいはセキュリティリスクが極めて低いと判断されるプロジェクトであれば、監視対象から除外することでコストを抑えられる可能性もあります。ただし、これにはセキュリティカバレッジの低下というトレードオフが伴うため、慎重な検討が必要です。 無料ティアの有効活用:  もしプレミアムティアのコストが見合わないと感じる場合でも、スタンダードティアは無料で利用できます。基本的な可視性を確保するだけでも、セキュリティ体制は大きく改善されます。 無料トライアルと見積もり:  Google Cloudは新規ユーザー向けに無料トライアルクレジットを提供しており、これを使ってSCCプレミアムティアを試すことができます。また、GCPコンソールの「料金」セクションや、Googleの営業担当者に問い合わせることで、具体的な見積もりを取得することも可能です。 SCCプレミアムティアは決して安価なサービスではありませんが、そのコストは重大なセキュリティインシデントが発生した場合の損害（データ漏洩による罰金、ブランドイメージの失墜、事業停止など）と比較すれば、はるかに低い投資となるでしょう。重要なのは、その価値とコストのバランスを理解し、組織のニーズに合ったプランを選択することです。 まとめ SCCがもたらす主要な成果は以下の通りです。 セキュリティ状況の「見える化」とリスクの事前特定: 組織内のすべてのアセットが網羅的に可視化され、それに紐づく脆弱性や脅威が明確になりました。これにより、漠然とした「何か起こるかもしれない」という不安が、「この脆弱性を優先的に修正しよう」「この脅威アラートには直ちに対応しよう」という具体的なアクションプランへと変わりました。 セキュリティ運用の「効率化」と「自動化」への道筋: 手動での確認作業が大幅に削減され、セキュリティチームの負担が軽減されました。また、Findings APIを活用することで、検出から是正までのワークフローを自動化する道筋が見え、インシデント対応の迅速化と人的ミスの削減が期待できます。 コンプライアンスへの「自信」と信頼性の向上: CISベンチマークへの準拠状況が継続的に評価されることで、監査対応の準備が格段に楽になり、GCP環境が常にセキュリティベストプラクティスに則っているという確信を持てるようになりました。これは、企業としての信頼性向上にも直結します。 もちろん、プレミアムティアの料金は安価ではありません。しかし、今日のサイバー脅威の高度化と、データ漏洩やシステム停止がビジネスにもたらす壊滅的な影響を考えれば、SCCへの投資は、企業を守るための必要不可欠なコストであると考えます。 もし今、あなたがクラウドセキュリティの課題に直面し、情報のサイロ化や対応の遅延に悩んでいるのであれば、ぜひ一度、Google Cloud Security Command Centerを有効化してみてください。 参考 Security Command Center の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/docs/concepts-security-command-center-overview?hl=jahttps://cloud.google.com/security-command-center/docs/overview?hl=ja Security Command Center の料金  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/pricing?hl=ja

こんにちは、SCSKの齋藤です。 本記事では、IAMのセキュリティ分析情報を用いて、権限整理を行った事例について紹介します。   はじめに、なぜIAMの権限整理が必要なのか？ クラウドサービスの普及により、企業は以前にも増して迅速にアプリケーションを開発し、多様なサービスを展開できるようになりました。その一方で、クラウド環境におけるセキュリティの重要性も飛躍的に高まっています。特に、Google Cloud (GCP) におけるIdentity and Access Management (IAM) は、リソースへのアクセスを制御するまさに「要」となる機能であり、その適切な管理はセキュリティ確保の最優先事項と言えるでしょう。 しかし、実際の運用現場では、IAM権限の管理はしばしば複雑化し、気付かないうちに「過剰な権限」が付与されているケースが散見されます。なぜこのような状況が生まれるのでしょうか？ 緊急の対応で一時的に広い権限を付与したままにしてしまう、権限付与の基準が曖昧なままプロジェクトが進む、担当者の異動や役割変更に合わせて権限が見直されない、といった要因が挙げられます。 過剰なIAM権限がもたらすリスク 過剰なIAM権限は、想像以上に深刻なリスクをもたらします。 セキュリティ侵害のリスク増大 : 最も重大なリスクです。悪意のある攻撃者や、内部の不正行為者が、必要以上の権限を利用して機密情報にアクセスしたり、システム設定を改ざんしたりする可能性があります。例えば、本番データベースの削除権限を持つ開発者アカウントが乗っ取られた場合、サービス停止やデータ消失といった壊滅的な被害につながる恐れがあります。 誤操作による影響の拡大 : 意図せずして、重要なリソースを削除したり、設定を変更したりする「ヒューマンエラー」のリスクが高まります。例えば、開発環境だと思って操作していたつもりが、本番環境のデータを誤って消去してしまった、といった事態は避けたいものです。最小権限の原則を守ることで、このような事故発生時の影響範囲を限定できます。 コンプライアンス違反 : GDPR、HIPAA、PCI DSS、日本の個人情報保護法など、多くの規制や業界標準では、データへのアクセス制御に関する厳格な要件が定められています。過剰な権限は、これらのコンプライアンス要件を満たさない状態を生み出し、監査での指摘や法的な問題に発展する可能性があります。 監査対応の複雑化と負担増 : 誰が、いつ、どこに、どのようなアクセス権を持っているかを正確に把握できないと、監査対応時に膨大な時間と労力を要します。透明性の低い権限管理は、企業全体のガバナンス低下にも繋がります。 IAMの重要性 – クラウドセキュリティの要 クラウド環境におけるセキュリティは、「責任共有モデル」に基づいて構築されています。クラウドプロバイダ（Google Cloud）はインフラストラクチャやプラットフォームのセキュリティを担当しますが、ユーザーは自身のデータ、アプリケーション、そして「IAM設定」に関するセキュリティに責任を持ちます。IAMは、このユーザー側の責任範囲において、最も基本的ながら最も重要なセキュリティ制御点なのです。 ここで不可欠なのが「 最小権限の原則 (Principle of Least Privilege) 」です。これは、ユーザーやサービスがその職務を遂行するために必要な最小限の権限のみを付与すべきである、というセキュリティの基本原則です。この原則を徹底することで、万が一アカウントが侵害された場合でも、その被害を最小限に抑えることができます。 本記事で扱う課題と解決策の概要 本記事では、GCP環境における過剰なIAM権限という課題に対し、Security Command Center (SCC) の先進的なセキュリティ分析機能を活用した具体的な解決策を提示します。 SCCは、GCP環境全体にわたる脅威、脆弱性、設定ミスを検出・管理するための統合プラットフォームです。その中でも、特にPremiumプランで利用可能な「IAMセキュリティ分析（Policy Intelligence）」は、IAMポリシーの構成を詳細に分析し、過剰な権限や未使用の権限といった「洞察（Insights）」を提供してくれます。   Google CloudのIAMとその複雑性 Google Cloud IAMは、GCPリソースへのアクセスをきめ細かく制御するための強力なフレームワークです。しかし、その強力さゆえに、適切に理解し管理しなければ、あっという間に複雑化し、手に負えない状況に陥る可能性があります。 IAMの基本概念 GCP IAMは、「誰が」「何をできるか」「どのリソースに対して」という3つの主要な要素で構成されます。これらが組み合わさって「ポリシー」を形成します。 プリンシパル (Principal) ： 誰が アクセスを許可されるかを示すエンティティです。 種類としては、Googleアカウント（個々のユーザー）、サービスアカウント（アプリケーションやVMインスタンス）、Googleグループ（複数のGoogleアカウントの集合）、G Suiteドメイン、またはCloud Identityドメイン全体があります。 例:  user:alice@example.com ,  serviceAccount:my-app@my-project.iam.gserviceaccount.com ,  group:devs@example.com ロール (Role) ： 何をできるか 、つまりプリンシパルに付与される権限の集合です。 ロールは、一つ以上の「権限 (Permission)」を含みます。権限は、特定のアクション（例:  compute.instances.start 、 storage.objects.get ）を実行する能力を定義します。 例:  roles/compute.viewer  (VMインスタンスを見る権限),  roles/storage.objectAdmin  (Cloud Storageオブジェクトを管理する権限) リソース (Resource) ： 権限が適用される対象となるGCPリソースです。 プロジェクト、フォルダ、組織といった階層的なリソースから、Compute EngineのVMインスタンス、Cloud Storageのバケット、BigQueryのデータセットといった具体的なサービスリソースまで多岐にわたります。 IAMポリシーは、このリソース階層のいずれかのレベルで設定されます。下位のリソースは上位のリソースからポリシーを継承します。 ポリシー (Policy) ： 上記3つの要素を組み合わせたものです。特定のプリンシパルに、特定のロールを、特定のリソースに対して付与します。 技術的にはJSON形式で表現され、以下のような構造を持ちます。 { "bindings": [ { "role": "roles/viewer", "members": [ "user:alice@example.com", "serviceAccount:my-app@my-project.iam.gserviceaccount.com" ] }, { "role": "roles/editor", "members": [ "group:developers@example.com" ], "condition": { "title": "Access only from trusted IPs", "expression": "request.time < timestamp(\"2024-12-31T23:59:59Z\") && caller.ip == \"203.0.113.0/24\"" } } ], "etag": "...", "version": 3 } 上記の例では、 roles/viewer がAliceとサービスアカウントに、 roles/editor がdevelopersグループに付与されており、後者にはさらに条件が指定されています。 ロールの種類と役割 GCP IAMには、主に以下の2種類のロールがあります。 プリセットロール (Predefined Roles) ： Googleが事前に定義しているロールで、一般的なユースケースに合わせて最適化されています。例:  roles/viewer  (閲覧者),  roles/editor  (編集者),  roles/owner (オーナー) などが存在します。 利便性が高く、多くのシナリオで利用できますが、含まれる権限が多すぎることが過剰な権限付与の原因となることがあります。 カスタムロール (Custom Roles) ： ユーザーが特定の要件に合わせて、必要な権限のみを厳選して作成できるロールです。 最小権限の原則を徹底するために非常に有効です。例えば、特定のAPIの読み取り権限と、特定のファイルへの書き込み権限だけを組み合わせたカスタムロールを作成できます。 手間はかかりますが、セキュリティを強化し、誤操作のリスクを減らす上で推奨されるアプローチです。   Security Command Center (SCC) とは Security Command Center (SCC) は、Google Cloud環境全体のセキュリティ状態を包括的に可視化し、リスクを特定・管理するための統合プラットフォームです。脆弱性、設定ミス、脅威、コンプライアンス違反など、多岐にわたるセキュリティ上の問題を発見し、優先順位を付けて対応を促すことで、組織のセキュリティ体制を強化します。 Security Command Centerの概要 SCCは、以下のような広範なセキュリティ情報を集約し、一元的に管理します。 アセットの可視化 : GCP環境内のすべてのリソース（VM、ストレージバケット、データベース、ネットワーク設定など）を自動的に検出し、インベントリとして表示します。 検出結果の管理 : さまざまなセキュリティ検出サービス（VMの脆弱性スキャン、ストレージの設定ミス、ネットワーク設定の異常、悪意のあるアクティビティなど）からの検出結果を一箇所に集約し、分析・管理できます。 脅威の特定 : Cloud LoggingやCloud DNSなどから収集したログデータを分析し、マルウェア、不正アクセス、データ流出などの脅威を検出します。 コンプライアンス状況のモニタリング : CISベンチマークやPCI DSSなど、業界標準のセキュリティ要件に対する準拠状況を評価します。 IAMセキュリティ分析 : 本記事の主題である、IAM権限に関する過剰な付与や未使用の権限などを検出します。 SCCは、これらの情報を使いやすいダッシュボードに統合し、セキュリティチームが効率的にリスクを把握し、対策を講じることを可能にします。 SCCのプランと機能 SCCには、大きく分けて「Standardプラン」と「Premiumプラン」の2つのサービスティアがあります。 Standardプラン : 基本的なセキュリティ評価と脅威検出機能を提供します。 Cloud Security Health Analytics (設定ミス検出)、Cloud DLP (機密データ検出)、Web Security Scanner (Webアプリ脆弱性スキャン)、Security Health Analytics for Kubernetes (Kubernetesセキュリティ評価) など、一部のサービスが利用可能です。 重要なのは、 IAMセキュリティ分析機能はStandardプランでは利用できない という点です。 Premiumプラン : Standardプランの全機能に加え、より高度なセキュリティ分析と脅威インテリジェンスを提供します。 IAMセキュリティ分析（Policy Intelligence） は、このPremiumプランでのみ利用可能です。 これ以外にも、脅威の優先順位付け、セキュリティ調査ワークベンチ、コンプライアンスダッシュボード、高度な侵入検知（Event Threat Detection）など、エンタープライズレベルのセキュリティ運用に不可欠な機能が多数含まれています。 過剰なIAM権限を自動的に洗い出すためには、 SCC Premiumプランの有効化が必須 となります。 IAMセキュリティ分析（Policy Intelligence/Policy Insights） SCC Premiumプランが提供するIAMセキュリティ分析は、Google Cloudの「Policy Intelligence」機能群の一部です。Policy Intelligenceは、IAMポリシーの構成を分析し、より安全で効率的なポリシー管理を支援するAIベースのツールセットです。主なコンポーネントは以下の通りです。 Policy Analyzer (Policy Insights) ： 「誰が、どのリソースに対して、どのようなアクセス権を持っているか」を分析し、 過剰な権限 や 未使用の権限 などの「洞察（Insights）」を提供します。 例えば、「このサービスアカウントは過去90日間、付与された権限の一部しか使用していない」といった情報や、「このユーザーは、必要以上の広範な管理者権限を持っている」といった具体的な推奨事項を提示します。 SCCは、このPolicy Analyzerが生成する「Policy Insights」を、検出結果としてダッシュボードに表示します。これが、本記事の主題である「過剰な権限の洗い出し」の核となります。 Policy Simulator ： IAMポリシーを変更した場合に、その変更が既存のアクセスにどのような影響を与えるかを シミュレーション できます。 実際にポリシーをデプロイする前に、意図しないアクセス拒否や、予期せぬアクセス許可が発生しないかを確認できるため、安心して変更作業を進めることができます。 Policy Troubleshooter ： 特定のプリンシパルが特定のリソースにアクセスできない、またはアクセスできるべきではないのにアクセスできてしまう、といったトラブルシューティングを支援します。 与えられたプリンシパル、リソース、権限に基づいて、アクセスが許可された理由、または拒否された理由を詳細に分析してくれます。 SCC Premiumプランでは、これらのPolicy Intelligence機能、特にPolicy Analyzerの洞察を「検出結果」として一元的に可視化し、セキュリティ運用のワークフローに統合します。これにより、これまで手動では困難だった、大規模な環境におけるIAM権限の健全性チェックと改善が、はるかに効率的に行えるようになります。 実践！SCCで過剰なIAM権限を洗い出す それでは実際に、Security Command Center Premiumプランを使用して、GCP環境における過剰なIAM権限を洗い出す手順を見ていきましょう。 SCC Premiumプランの有効化と設定 過剰なIAM権限の分析には、まずSCC Premiumプランを有効化する必要があります。 組織レベルでの有効化 : SCCは組織レベルで有効化するのが一般的です。これにより、組織内のすべてのフォルダとプロジェクトがSCCの監視対象となります。 Google Cloud Consoleで、組織リソースを選択し、ナビゲーションメニューから「Security Command Center」を選択します。 初回アクセスの場合、「概要」ページで「有効化」ボタンが表示されます。StandardプランかPremiumプランかを選択する画面が表示されたら、「Premium」を選択して有効化を進めます。 有効化には、 roles/securitycenter.admin  などの適切なIAM権限が必要です。通常は組織の管理者アカウントで行います。 有効化後、SCCが組織内のアセットをスキャンし、検出結果を収集するまでに時間がかかる場合があります（数時間から24時間程度）。 必要なIAM権限の確認 : SCCのダッシュボードを閲覧し、検出結果を管理するためには、適切なIAM権限が必要です。 一般的に、以下のロールが付与されたユーザーアカウントまたはサービスアカウントが必要です。 roles/securitycenter.admin  (管理者の場合) roles/securitycenter.viewer  (検出結果を閲覧するのみの場合) roles/securitycenter.findingsEditor  (検出結果のステータス変更などを行う場合) IAMセキュリティ分析（Policy Intelligence）に関する洞察を表示するためには、これらのSCCロールに加え、関連するリソースのIAMポリシーを参照する権限も間接的に必要となりますが、SCC Premiumが有効であれば、通常は自動的に権限が補完されます。 ポリシーの分析情報を管理するために必要な権限を取得するには、分析情報を管理するプロジェクト、フォルダ、または組織に対して次の IAM ロールを付与する必要があります。 roles/recommender.iamViewer （ポリシーの分析情報を表示する場合） roles/recommender.iamAdmin （ポリシーの分析情報を変更する場合） 有効化後の分析情報例 SCC Premiumプランを有効化し、しばらく時間が経つと、Policy Intelligence (Policy Analyzer) が収集したIAMに関する分析情報が「検出結果 (Findings)」タブに表示され始めます。これらの分析情報は「洞察 (Insights)」として提供され、過剰な権限や未使用の権限が具体的に指摘されます。 この画像は、あるプリンシパルに付与された「 Storage オブジェクト管理者 」ロールが過剰な権限を持っていることを示しています。 概要 : 上部に表示されるメッセージ「 Storage オブジェクト管理者 ロールを Storage オブジェクト閲覧者 ロールに置き換えると、プリンシパルの権限数が 28 から 8 に減少します。分析は過去 90 日間を基にしています。 」が、この洞察の要点をまとめています。 特定のプリンシパルに付与された「 Storage オブジェクト管理者 」ロールが、実際の使用状況と比較して広範すぎることを指摘。 より制限された「 Storage オブジェクト閲覧者 」ロールへの置き換えを推奨。 その結果、付与される権限の総数が28から8に大幅に削減されることを明示。 この分析が、過去90日間の権限使用履歴に基づいて行われたことを示しています。 現在の権限 (左側) : 「 Storage オブジェクト管理者 ロールの現在の権限 」として、このロールが持つ広範な権限がリストアップされています。 例として、 storage.objects.get （オブジェクトの取得）のような読み取り権限に加え、 monitoring.timeSeries.create 、 orgpolicy.policy.get 、 resourcemanager.projects.get / list 、さらには storage.folders.create / delete / rename などの ストレージの管理・削除に関する権限 や、 storage.managedFolders （マネージドフォルダ）に関する権限など、多岐にわたる権限が含まれていることが分かります。 これらのうち、 storage.objects.get  以外は、過去90日間で実際に使用されていない「過剰な権限」として青字の「過剰な権限」ラベルとともに表示されています。 置き換え推奨のロール (右側) : 「 Storage オブジェクト閲覧者 のロールの置き換えを推奨 」セクションでは、提案されるロール（この場合は Storage オブジェクト閲覧者 ）に含まれる権限と、現在のロールとの差分が表示されます。 赤いハイライトで示されているのは、現在のロール（ Storage オブジェクト管理者 ）には含まれるが、推奨されるロール（ Storage オブジェクト閲覧者 ）には含まれない、つまり 削除されるべき権限 です。これにより、一目でどの権限が不要と判断されたかを確認できます。 ここでは、 storage.objects.get  のみが必要な権限として残り、その他の監視、組織ポリシー、リソースマネージャー、およびストレージ管理に関する多くの権限が削除対象となっていることが明確に示されています。 この具体的な洞察は、権限整理の具体的なアクションに直結します。この情報に基づいて、対象のプリンシパルから Storage オブジェクト管理者 ロールを削除し、代わりに Storage オブジェクト閲覧者 ロール、またはより細かく制御されたカスタムロールを付与することで、最小権限の原則を適用し、セキュリティリスクを大幅に低減することができます。 まとめ 本記事では、GCP環境における過剰なIAM権限の危険性とその解決策として、Security Command Center Premiumの強力なIAMセキュリティ分析機能（Policy Intelligence）を解説しました。 IAMはクラウドセキュリティの基盤であり、その適切な管理は組織のデータとシステムを保護する上で不可欠です。SCC Premiumを導入し、本記事で紹介した手順とベストプラクティスを実践することで、これまで見過ごされがちだったIAMの「死角」を解消し、より堅牢で効率的なGCP運用を実現できるはずです。 本記事がGCP環境のセキュリティ強化の一助となれば幸いです。 参考 Google Cloud IAM の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/iam/docs/overview?hl=ja Security Command Center の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/docs/overview?hl=ja Security Command Center の料金  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/pricing?hl=ja

更新必要な資格の中でも、私が初めて取得したAZ-104の更新時期がついにやってきました。 取得した当時は実務経験もそれほど多くなかったため、実務想定の長文ケーススタディ問題には相当苦戦した記憶があります。 一年足らずで更新のタイミングが来て、「もう更新か…」と正直驚きました。 これからも資格の更新あるので備忘も兼ねて記事に残しておきます。   AZ-104の概要 AZ-104（マイクロソフト認定: Azure管理者アソシエイト）とは、Azureの管理・設計・運用に必要な知識とスキルを証明する資格です。リソースグループ、仮想マシン、ストレージ、Vnet、Entra ID、セキュリティなど業務と密接にかかわる内容で構成されているのが特徴です。 インフラ関連のエンジニアとして中級者レベルの実力を持つことを証明できます。 Azure資格は有効期限が「12ヵ月」と設定されている点も独特です。 他のクラウドベンダーの資格は有効期限が2〜3年というパターンも多い中で、マイクロソフトのAzure系資格は、年次更新が求められます。これによって常に最新のクラウド技術にキャッチアップし続ける意識が自然と身につくという意味では、良い仕組みなのかもしれません。   テストの受け方 AZ-104の更新テストは本番のように試験センターまで赴く必要はありません。自宅や職場など、インターネット接続環境があればどこからでも受験可能なWebテスト形式です。 Microsoft Learn: キャリアの扉を開くスキルを身につける このサイトにアクセスして自分のプロファイルに飛んでください。 資格証明タブから更新したい資格を選んで、更新ボタン押します。             更新費用 費用はかかりません。更新は何度受験しても無料で受験できます。   試験内容と結果 全部で26問、制限時間は45分のテストです。 残り時間の表示は無いので注意して下さい。本試験のときは残り時間が表示されていた記憶があります。 長文のケーススタディ問題は出題されず、リソース設定の知識問題と目的のために何をする必要があるかを選ぶ問題でした。 結果は、、           落ちました。         正答率34%で不合格。 一度取得したし、大丈夫だろうと油断していたら普通に落ちました。 細かい設定の知識が抜けていることを痛感しました。 忘れていることが多く反省してます。教材引っ張り出して、猛勉強して再チャレンジします。 余談ですが、SCSKにはhirodemyという学習サイトがあります。 AWSとGoogle Cloudの問題が多数収録されていて、私もAWS SAAの受験時には大変お世話になりました。 しかし、Azureだけ無いんですよね、、昔はあったと先輩から聞いたことありますが2年目の私には幻の存在です。 しかたがないので、昔に購入したudemyの問題集で勉強し直しました。 hirodemyに関して、以下に参考リンク貼りますので見てください。 セッション資料・動画一覧 – AWS Summit Online 2021 | AWS PAR-15_AWS_Summit_Japan_2021_SCSK.pdf   再受験まで24時間の間隔をあける必要があります。私の場合、期限の2025年12月18日まで何度でも再受験が可能です。 Microsoft 認定: Azure 管理者アソシエイトの更新 – Certifications | Microsoft Learn   ～24時間後～ 満を持して、2度目の挑戦。   結果は、、     合格。           合格ボーダー57%で、結果は65%でした。危なかった。 情けなくもギリギリですが、何とか更新を完了できてホッとしています。             感想 今回AZ-104の資格更新しましたが、次はより上位の資格であるAZ-305：Azure ソリューション アーキテクト エキスパートにチャレンジする予定です。同じ傾向で知識重点的に問われるのであれば、改めて復習しておかないとなぁと思います。 勉強頑張ります。

本記事は 夏休みクラウド自由研究2025 8/8付の記事です 。 Catoクラウドのセキュリティ機能のうち、Threat Preventionオプションにて提供される Anti-MalwareとIPSについて詳しく紹介いたします。 はじめに：Threat Prevention機能について Catoクラウドが提供する数多くのオプションの中で、最も基本的なセキュリティ機能を提供するのが 「Threat Prevention」オプションです。 本オプションには、大きく分けて「Anti-Malware」「次世代Anti-Malware（NGAM）」「IPS」 の3機能が含まれております。オプションとして追加することで 高性能なウィルス対策ソフトウェアや次世代セキュリティソフトウェアを導入するのに相当する セキュリティが提供されるようになります。 本記事では、これらの記事について紹介すると共に、 少し深堀りして具体的な挙動も含めて説明していきます。 CatoのAnti-Malware機能 まずはAnti-Malware機能の概要と挙動について紹介していきます。 2つのAnti-Malwareとその関係性 先述の通り、Catoの提供するAnti-Malware機能は2種類存在します。 どちらも HTTP、HTTPS、FTPの3種のプロトコルによる通信が対象 となっています。 名称 役割 Anti-Malware いわゆる一般的なウィルス対策ソフトウェアに近い、シグネチャベースおよび挙動検知型の アンチマルウェアです。 Catoネットワークを経由してやり取りされるファイルを自動でスキャンします。 NG Anti-Malware 膨大な量のマルウェアの機能を学習したAIによって、特徴を検知するアンチマルウェアです。 未知のマルウェアやゼロデイのマルウェアにも対応することが可能です。 Catoネットワークを経由してやり取りされるファイルを自動でスキャンします。 これらの機能は同時に稼働しているわけではなく、下記のように順番に適用されます。 １．対象となるファイルが除外対象でなければ、「Anti-Malware」によるスキャンを実施 ２．「Anti-Malware」の結果に問題が無い場合、「NG Anti-Malware」によるスキャンを実施 ３．結果に応じてAllow / Blockを決定 NG Anti-Malwareは、必ずAnti-Malwareの後で動作します。この挙動を考慮してか、 NG Anti-Malwareは前提としてAnti-Malwareの有効化が必須 となっております。 普段意識する必要はありませんが、念のため気を付けておきましょう。 Anti-Malwareの有効化 CatoのAnti-Malware機能は、[Security] > [Anti-Malware]から 簡単に有効化 / 無効化を設定できます。 デフォルトで両方有効化されているため、特に無効化する理由が無ければそのままで問題ありません。 なお、先述の通りNG Anti-MalwareはAnti-Malwareの稼働を前提としているため、 Anti-Malwareを無効化するとNG Anti-Malwareも同時に無効化されるようになっています。 Anti-Malwareの除外設定（Bypass List） Catoクラウドに限らず、ウィルス対策ソリューションは本来必要なファイルを ウィルスとして誤検知してしまう恐れがあります。 こうしたケースの対策として、スキャン対象から除外する機能が存在します。 Catoクラウドの場合、[Security] > [Anti-Malware] の [Bypass List]タブから設定を行います。 こちらの機能では、ファイル単位ではなく 宛先や通信を行うアプリで除外する 形となります。 設定項目は下記のとおりです。 名称 役割 General ルールの名称と基本的な設定を決定します。 「Rule Order」はルールの配置位置です。 「Scope」によって、WAN通信、Internet通信のどちらかだけを対象とすることも可能です。 Source 特定のユーザやグループ、Site等、接続元を指定することができます。 例えば、「システム部門のユーザのみ許可」「特定IPセグメントの機器に限り許可」 といった制御が可能です。 What 除外対象を指定します。 IPアドレスやドメインでの指定の他、「Sharepointでのファイル連携はバイパス」といった アプリケーションでの除外も可能です。  以下のように、ルールが追加されたことを確認できます。 ルール右側の「…」より、ルールの無効化や削除といった操作を実施可能です。 設定変更後、反映のために「Save」を実行することを忘れないようにしましょう。 Anti-Malwareの除外設定（File Exception） Catoは誤検知の対応方法として、個別ファイル単位での除外設定にも対応しています。 SHA-256のハッシュ値により識別 しているため、同一のファイルであれば どこを経由したものであっても除外の対象となります。 ハッシュ値を参照する都合上、対象ファイルに更新や修正が入ると 除外の対象から外れてしまいます。 改ざん対策としてセキュリティ上意味のある仕様ですが、 実運用上で引っかかる場合もあるため注意しましょう。 本設定については、実際にイベントとして検知して初めて設定できるようになっています。 [Home] > [Events]にて、以下のようなフィルタリングを行うことで、Anti-Malware機能によって出力されたイベントが一覧表示されます。 ・Sub Type In “Anti Malware”, “NG Anti Malware” 表示されたイベントを確認すると、「File Hash」という属性が存在することを確認できます。 （値が青色の文字で表示されています。） 青色で表示されている値をクリックすることで、「File Exception」の設定ウィンドウが開きます。 除外の期間とコメント（任意）を設定して「Apply」をクリックしましょう。 [Security] > [Anti-Malware]にて、追加されたルールを確認できます。 有効期間が過ぎた時点で無効化されるほか、手動での削除も可能です。 Anti-Malwareの個別設定追加 Anti-Malware機能は、デフォルトで「Malicious (virus_found)」または「Suspicious」 と判定したファイルを全てブロックするように設定されています。 上記と異なる挙動を適用したい場合、[Protection Policy]タブでポリシーを作成します。   設定項目は下記のとおりです。 名称 役割 General ルールの名称と基本的な設定を決定します。 「Rule Order」はルールの配置位置です。 「Scope」によって、WAN通信、Internet通信のどちらかだけを対象とすることも可能です。 Rule Orderが小さい（上に表示される）ルールが優先的に適用される ため、 条件の広いルールはなるべく下に配置しましょう。 Source 特定のユーザやグループ、Site等、接続元を指定することができます。 例えば、「システム部門のユーザのみ許可」「特定IPセグメントの機器は禁止」 といった制御が可能です。 What 除外対象を指定します。 IPアドレスやドメインでの指定の他、「Sharepointでのファイル連携は許可」といった アプリケーションでの除外も可能です。  Verdict 検知結果を指定します。 All Files：その名の通り、すべてのファイルです。 Suspicious：Anti-Malwareは通過、NG Anti-Malwareが「疑わしい」と判断したファイルです。 Malicious：Anti-MalwareまたはNG Anti-Malwareがマルウェアと判断したファイルです。 Encrypted：パスワード付きZipファイルなど、中身のチェックに制限がかかったファイルです。 Action Allow / Blockを指定します。 また、Eventsへのログの出力有無、メール通知の送付有無を設定します。 Eventsへの出力は、原則として有効化することを推奨します。 作成後、一覧に想定通りのルールが存在することを確認してから「Save」を実行しましょう。 BypassとAll Allowの違い 「Verdict」で「All Files」を指定して「Action」で「Allow」とした場合、 エンドユーザからの見かけ上の動作はBypassしているのと同様の結果となります。 両者の違いは下記のとおりです。          Bypass：Anti-Malwareによるチェック自体を行わない。 PolicyによるAllow：Anti-Malwareによる一通りのチェックを行った後「許可」とする。 PolicyによってAllowとしていた場合、Eventsにて後から判定を確認することも可能です。 （そもそもあまり推奨はしませんが）広い範囲で許可設定を行う場合は、 万一の確認のためにBypassではなくProtection Policyにて設定するのも一つの手です。 （参考）ウィルス対策ソフトウェアと比較してのPros & Cons これまで述べてきたように、CatoのAnti-Malware機能は 通常のアンチマルウェアや次世代アンチマルウェアソフトに匹敵する防御機能を有しています。 一方で、仕様上どうしても対処が難しい点もあります。これらについてざっと記載します。 CatoのAnti-Malwareの強み 定義ファイルの更新頻度 CatoのAnti-Malwareは、 30分毎に定義ファイルを更新 しています。 特にレガシーなタイプのシステム構成をとっている場合、 従来型のエンタープライズ向けウィルス対策ソフトウェアの端末上の定義ファイル更新頻度は 1日1回、またはそれ未満というケースも少なくありません。 Catoのバックボーン上で機能する CatoのAnti-Malware機能は、すべてバックボーンの通信上で動作します。 このため、 動作が端末自体のリソースを消費することはありません 。 定義ファイルのダウンロードにより通信帯域が圧迫される……といったこともありません。 ※前述の従来型システムでの実端末に対する更新頻度の低さは、 こういった影響を回避するため止む無く、ということも多いと思います…… 端末上で動作するものではないため、（特にSocket配下の機器について） 端末からは直接動作を無効化することができません 。 万が一端末がマルウェアに感染してしまったとして、外部への情報送信や他の機器への拡大は 相変わらずCatoのセキュリティ機能による監視の対象となります。 CatoのAnti-Malwareの弱み ネットワーク外の感染は回避不能 あくまでもCatoを介した通信を監視するものであるため、 Bypass機能などを用いてCatoのネットワークを迂回している場合は検知できません 。 当然ながら、「マルウェア入りのUSBメモリを挿入した」といったケースも検知できません。 実行そのものを止める機能は無い 上記と同様の理由で、仮に端末上に既にマルウェアが存在した場合に、 それを実行すること自体を検知、ブロックすることはできません。 ただし、強みとして記載した通り、この場合でも外部サーバへの情報送信などは Catoの機能によって阻止できる可能性があります。 対象とする形式の制約 前述の通り、本機能が対象とする通信はHTTP、HTTPS、FTPです。 外部との通信であれば概ねカバーできますが、 SMBによるファイル授受が対象外 であるため、社内ファイル共有での拡散に注意が必要です。   上述の弱みについては、CatoのAnti-Malwareの動作仕様上の制約というべきものです。 エンドポイント型のセキュリティ対策を併用する ことで、より強固なセキュリティを構築可能です。 なお、Catoにはエンドポイント型のセキュリティを提供する 「Endpoint Security（EPP）」オプションもございます。 セキュリティ機能の一括管理を希望する場合、検討するのも一つの手です。 CatoのIPS機能 IPSはAnti-Malwareとは異なり、ファイルではなく通信自体を対象とした検知、防御を行います。 一例としては、以下のような挙動を行います。 C&Cサーバやフィッシングサイトといった、攻撃用のサイト・サーバへの通信をブロックする CVEとして公開された、既知の脆弱性を突くための通信を検出、ブロックする 攻撃の前段階にあたるネットワークスキャンをブロックする Anti-Malware機能と同様に、Catoは（除外設定が無い限り）経由する通信全てに対して上記の処理を実施することが可能です。 通信の内容を解析して防御するという挙動の関係上、 Catoの TLSインスペクションが無効である場合は暗号化通信に対する検知性能が大きく低下 します。 IPSを使用する場合、可能な限りTLSインスペクションも有効としましょう。 IPSの有効化 IPS機能は、[Security] > [IPS]のトグルスイッチで有効化 / 無効化します。 下部のトグルスイッチを利用することでインターネットの通信のみを対象にするといった設定も可能ですが、基本的には全て対象とすることを推奨します。 設定変更後は、ウィンドウ右上にある「Save」の実行を忘れないようにしましょう。 IPSの除外設定 IPS機能についても、Anti-Malware機能と同様に誤検知を防ぐための除外設定を行うことが可能です。 設定方法には、大きく2つのパターンが存在します。 パターン1：設定をマニュアル作成 [Security] > [IPS] の [Allow List] タブから、除外設定を管理することが可能です。 「New」をクリックすることで、設定画面が表示されます。 名称 役割 General ルールの名称と基本的な設定を決定します。 Name：ルール名です。 Description：ルールについての説明を、任意で追記できます。 Scope：下記の通り、適用対象の通信を絞り込むことが可能です。 All：全て Inbound：外部から入ってくる通信 Outbound：外部へ出る通信 WAN：拠点間通信 Signiture ID：IPSは、疑わしい通信と判断する理由にあたる「Signature」に   合致した通信をブロックします。   この項目で、特定のSignatureに合致した場合に限って除外することも可能です。 Source 特定のユーザやグループ、IPレンジ、Site等、接続元を指定することができます。 Destination 除外対象の宛先を指定します。 IPアドレスやサブネット単位での指定、拠点間通信向けにSite単位の指定も可能です。 実は「General > Scope」に応じて設定可能項目が変更されており、 ドメイン指定は「Outbound」「WAN」のどちらかでないと設定できない （「All」では設定できない） ため注意しましょう。 Protocol/Port 対象ポートを指定します。 例えば、DNS通信を除外するのであれば「TCP_UDP/53」を指定することとなるでしょう。 Track この除外設定が適用された場合の、 Eventsへのログの出力有無、メール通知の送付有無を設定します。 設定後「Apply」を押下して、一覧に設定が追加されたことを確認します。 設定の変更、内容の確認後に、ウィンドウ右上の「Save」を実行しましょう。 パターン2：イベントログから除外設定を作成 「業務通信が上手くいかず、調査した結果IPSのブロックが原因だった」といったケースでは、 対策として該当する通信の除外設定を追加する必要が生じます。 Catoには、ブロックされた通信のイベントログから除外設定を生成する機能が存在します。 [Home] > [Events]にて、以下のようなフィルタリングを行うことで、IPSによってブロックされたイベントのログを確認することができます。 ・Sub-Type Is IPS ・Action Is Block イベントの一覧で目的のログを見つけたら、詳細を確認します。 中に「Signature ID」という属性があり、値が青色で記されていることを確認できます。 このIDの値（青色部分）をクリックすることで、即座に除外設定の作成画面が開きます。 対象の通信を絞り込むための設定がすべて入力済みとなっているので、 「Apply」を押すだけで設定が完了します。 ※接続元IPまで固定されているため、必要に応じ変更しましょう。 極めて簡単に設定できるうえ、適用範囲を最低限に絞ったルールが作成されるため セキュリティ上も利点のある方法です。ぜひ活用していきましょう！ IPSのオプション機能 IPSには、メインとなる機能を補完するオプションがいくつか存在します。 それぞれ別のタブにて設定が可能です。 [Enforcement Option]タブ Outbound Traffic – Block newly registered domains 作成が確認されてから14日以内のドメインを宛先とした通信を、一律でブロックします。 攻撃者が使い捨てのような新規ドメインを用意するケースは少なからず存在しますが、 そうした場合はこのオプションで無条件にブロックできることになります。 Inbound Traffic – Suspicious IP quarantine 短期間で高頻度にIPスキャンを行っているアドレスが確認された場合に、 当該IPアドレスの通信を5分程度遮断する機能です。 [Geo Restriction] タブ IPアドレスベースで、特定の国との通信を一律ブロックとすることが可能です。 インバウンド通信のみ、アウトバウンド通信のみといった設定も可能です。 [Suspicious Activity] タブ IPSでブロックするには至らない、疑わしい通信を識別してログに残す機能です。 あくまでもモニタリングだけで、ブロックすることはありません。 [Home] > [Events]上では、Sub-Typeは「IPS」ではなく、 「Suspicious Activity」という固有のSub-Typeで記録されています。 （参考）IPSはどんな通信を検知している？ IPSがどのような通信をブロックしたか、大まかな傾向は [Security] > [IPS] 下部の「IPS Categories」にて確認可能です。 この項目には、各カテゴリごとの直近7日間での検知回数が表示されます。 また、1件以上存在する場合は、回数部分をクリックすることで 当該の条件に合うフィルタ設定が施された状態で[Home] > [Events]に遷移します。 どのカテゴリが多く検知されるかは、それぞれの環境によって大きく異なります。 ここでは、あくまで参考として、比較的多く検知が見られたカテゴリと ブロックされる通信の例を紹介いたします。 Policy Violation Catoが「セキュリティ上望ましくない」と判断したアプリケーションによる通信をブロックする カテゴリです。 具体例としては、BitTorrent系のアプリケーションによる通信のブロック等を確認しました。 このタイプの場合、ログからアプリケーションを確認し、 業務上問題のないものかどうかを検証するのが望ましいでしょう。 Reputation 「信頼できる」と判断するには不十分な程度の情報しか存在しないIPやドメインにまつわる接続をブロックするカテゴリです。 作成されて日が浅いドメインへの接続は、このカテゴリでブロックされることが多いです。 日本ローカルのサービスなど、世界的にみると利用者の少ないサービスがこのカテゴリでブロックされてしまうケースも存在するため、同じドメインのブロックを大量に検知する場合は確認しておくことが望ましいです。 Web Application Attack その名の通り、訪問したウェブアプリケーションに有害な動作が存在した場合に ブロックするカテゴリです。 このカテゴリについて、圧倒的に検知数が多いのは「adnxs.com」のCookieでした。 Microsoftがターゲッティング広告用に用いているCookieのようで、 基本的には無害なものと考えてよさそうです。 逆に、上記以外を検知している場合は内容を精査する必要があるかもしれません。 終わりに 本記事では、Threat Preventionの機能について紹介しました。 本機能は重要な一方、普段は誤検知かトラブルが起きない限り、あまり参照しない機能です。 もしもの時のために、一度操作を確認しておくのも良いかもしれません。

こんにちは、SCSK株式会社3年目の愛甲です。 前回、私たちの部署の嶋谷さんが、 MackerelでOracle Databaseを監視してみた という記事を掲載しました。 MackerelでOracle Databaseを監視してみた – TechHarmony 今回は、AWSの通話サービスであるAmazon Connectを Mackerelで監視し可視化しましたので、ご紹介いたします。 MackerelでのAWSリソースの監視 Mackerelでは、AWSインテグレーションというものを使い、MackerelとAWSのサービスを接続し、とても簡単にAWS環境を監視することができます。 AWSインテグレーションについては、以下のMackerelの公式ドキュメントに詳細が記載されています。 AWSインテグレーション – Mackerel ヘルプ AWS環境の監視については、以下の記事でもご紹介していますので、興味がある方は是非ご覧ください。 Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony 監視対象について はじめに、監視対象についての情報を軽く説明します。 今回の検証では、Amazon Connectで電話接続し、その電話の録音データをAmazon S3に保存されるサービスを構築しました。 システム構成は以下の図になります。 Amazon Connect 　　クラウド型コンタクトセンターサービス AWS Lambda　　　  時間帯での転送先判定 Amazon S3 　　　  　録音データの保存先 構成しているサービスの中でAmazon Connectを監視対象として検証しました。 上記の環境の構築手順については、少し長くなってしまうため、この記事では説明を省かせていただきます。 Mackerelでの監視設定手順 では、ここからはMackerelでAmazon Connectを監視するための、設定手順について記載していきます。 設定手順に興味ない方は、このパートはスキップして、「監視データ」のパートに飛んでください。 インテグレーション用のIAMロールの作成 (1) Mackerelの管理画面で「オーガニゼーション名」＞「AWSインテグレーション」をクリックする。 (2) 「新しいAWSインテグレーションを登録」というボタンが表示されるため、それをクリックする。 (3) 基本設定＞AWSアカウント　外部IDをコピーする。 (4) AWSのコンソールにログインし、左上の検索バーで「IAM」と入力し、エンターを押す。 (5) 左側のタブからロールを選択し、「ロールを作成」をクリックする。 (6) 以下に沿って入力し、すべて入力後、「次へ」をクリックする。 信頼されたエンティティタイプ：AWSアカウント AWSアカウント：別のAWSアカウント ・アカウントID：217452466226（共通） オプション：外部IDを要求する (7) Amazon Connectを監視したいため、それらに関するReadOnlyロールを選択し、「次へ」をクリックする。 (8) ロール名と説明を適宜入力し、「ロールを作成」をクリックする。 注意点：Amazon Connectを連携対象にする場合、連携に使用するIAMロールにはAmazonConnectReadOnlyAccessに加えて、CloudWatchReadOnlyAccessの権限が必要となります。 Amazon ConnectのようにCloudWatchReadOnlyAccessの権限が必要になるものがあります。詳細は冒頭にあるAWSインテグレーションヘルプをご確認ください。 ⑨作成したロールの詳細画面で表示される、ARNをコピーする。 AWSインテグレーションの作成 (1) Mackerelの管理画面に戻り、先ほど開いた「新しいAWSインテグレーションを登録」画面を開く。 そこで、名前の入力とリージョンの選択を行い、ロールARNの欄に先ほどコピーしたARNを貼り付ける。 (2) メトリックを収集するサービスで、Amazon Connectを選択し、「作成」をクリックする。 (3) 「タグを指定して登録するホストを絞り込む」にて連携したいリソースのタグ、除外したいタグを入力する。 これで、インテグレーションが作成できました！ 連携確認 以上で設定は完了です。 ここからは、監視設定を入れたサービスの状態を見てみましょう。 ここまでの手順が完了すると、Mackerelの管理画面の「ホスト」のところですぐに確認することができます。 このように、Amazon Connectのデータが取れていることがわかります。 監視データの確認 監視手順としては以上になります。 AWSインテグレーションを使うと、面倒なエージェントのインストールや、接続用のアカウントの作成などがないため、とても簡単に監視ができます。 私はAWSインテグレーションの設定はまだ2回目ですが、もうおちゃのこさいさいです！ では、ここからはAWSから連携された監視データがどのように見えているかを、 一部抜粋してお見せしたいと思います。 Amazon Connectの監視データ Amazon Connectは基本的に以下のメトリックを取得できます。 グラフ名 メトリック 説明 Concurrent Calls Service Quota ConcurrentCallsPercentage 同時に処理可能な通話数のサービスクォータがどの程度使われているか（%） To Instance Packet Loss Rate ToInstancePacketLossRate インスタンスに送信されるパケットの損失率 Voice Calls CallsBreachingConcurrencyQuota クォータ超過で処理できなかった通話数（合計値） CallsPerInterval 一定間隔内での通話数（合計値） ConcurrentCalls 同時に存在した通話数（最大値） ThrottledCalls 制限でスロットリングされた通話数（合計値） MissedCalls 取りこぼした通話数（合計値） MisconfiguredPhoneNumbers 誤設定の電話番号への通話数（合計値） Call Recording Upload CallRecordingUploadError 通話録音ファイルのアップロードエラー件数（合計値） Contact Flows ContactFlowErrors コンタクトフローで発生したエラー（合計値） ContactFlowFatalErrors 致命的エラー（合計値） CallBackNotDialableNumber コールバックできなかった番号（合計値） Queues QueueSize キュー内に滞留している件数（最大値） QueueCapacityExceededError キュー容量超過によるエラー件数（合計値） Queue Wait Time LongestQueueWaitTime 最長待機時間 Public Signing Key PublicSigningKeyUsage 公開署名鍵の利用回数（合計値） 今回は、この中のVoice Callsのグラフをお見せします。 グラフを表示させるにあたって、私はAmazon Connect上に登録した番号に繰り返し電話をかけました。 その結果、以下のようなグラフが表示されました。 こちらは、通話をした数や受電できなかった数を表したグラフになります。 （メトリックはConcurrentCallsとMissedCallsに絞って表示しています） 黄緑線　 　：繋がった通話の数 オレンジ線 ：受電したが、電話に出れなかった数 このように、CloudwtchでとれるメトリックをMackerelでも確認することができます！ このデータのほかにContact FlowsやQueuesを組み合わせて監視をすれば、Amazon Connectを使った番号への電話がつながらなくなった場合などに、何が原因で、どの時間帯につながらなくなったのかを即座に認識することができます。 興味がある方はぜひ調べて試してみてください。 おわりに 記事の内容は以上になります。いかがでしたでしょうか。 Amazon Connectを使っている方でしたら、1度は電話がつながらなくなって焦った人もいるかと思います。そんな時、Mackerelの監視をしておけば、すばやい原因特定も可能になります！ また、Mackerelを使って今まで見えていなかった情報を見える化することで、電話の多い時間帯や、電話の対応時間などを確認できるようになるため、人員最適化や業務の品質向上などの業務効率化に役立てることもできます！ ぜひ、活用してみてはいかがでしょうか。 もう少しMackerelを触ってAmazon Connectを監視してみようと思いますので、また何か気づきがありましたら記事を掲載します。 最後までお付き合いいただき、ありがとうございました。

はじめまして。吉越です。 今回、6月25日に開催されていたAWS Summit2025へ参加して持ち帰ってきた話をブログにまとめようと思います。 はじめに 早速ですが、みなさんにSNSで話題となったラーメン山岡家のブースの「ゆで麺タイマー」のアーキテクチャをお見せします！ AWS Summitの企業ブースに山岡家がある～と思って近づいたところ、ゆで麺タイマー（？）というものがAWSで構築されているのかぁと面白くて気づいたら資料くださいって声かけてました。 色々なセッションを聞いてから家に帰り、山岡家の資料をもう一度読み返してみました。 すると、ここにも「SnowFlake」があるなぁ、という感想でした。 なぜなら同日に聴講したパートナーセッション「PayPayのAI DataCloudが目指す最先端アーキテクチャ」でもSCSKブースのミニセッションでも「Snowflake」を扱っていたからです。もしかして今アツいサービスなのかもしれないという予感がしてきました。 また、私はお客様のインフラ基盤の保守運用を行っているので、サービスの提案や導入をする立場にあるということで、 AWSパートナーセッションで聞いた内容をもとに、お客様の環境へ導入検討できないかという視点で記事を書こうと思います。 ※今回はSnowFlakeがどういった製品かという内容を詳細に記事に記載いたしません。詳しくはSnowFlakeの 公式ページ を参照ください。 セッションから考えるSnowFlakeの導入検討 パートナーセッション「PayPayのAI Data Cloudが目指す最先端アーキテクチャの実装」を聴講して このセッションで伝えたかったことは 「Snowflakeによるデータ基盤構築のメリット」と「3か月でデータ基盤環境を構築し社内公開の達成」 ということでした。そのため、今回はこの2点について書きます。 まずなぜPayPayがこのデータ基盤を必要としたのかというと、それはユーザ増加に伴うデータ基盤の拡張性と柔軟性を求めていたからです。 上記のとおり、コード決済は2023年に比べても2024年では23％増えており、ここ数年でも大きく成長しています。 そのような中でデータ基盤の構築することにより、データをより効果的に活用し今後の更なるビジネス成長や拡大に狙いがありました。 このようなメリットがあるわけでデータ基盤を構築するわけですが、まず事前に知っておきたいPayPayのデータ基盤のアーキテクチャです。 このように支払いデータは、インフラ基盤→Data Lake（S3）→Data Warehouse（Snowflake）→Data Analytics ML/AI（SnowFlake等） の流れで格納、加工、分析され活用されています。 PayPayはデータ基盤の構築のためにSnowFlakeを導入しますが、ではなぜSnowflakeだったのでしょうか。 以下、PayPayがもっていた課題とその解決策、そこから見たSnowflakeのメリットをまとめて表にします。 課題 解決 Snowflakeのメリット ・短期間かつ少人数で迅速に構築する必要があった ・インフラ運用工数を削減し、データ基盤開発に集中したい ◎短期間かつ少人数で迅速にデータ基盤の構築ができた ◎マネージド型サービスとニアゼロメンテナンスで開発に集中 マネージドサービス型で迅速なデータ基盤を構築 ・急速な事業成長に比例して柔軟にスケールしたい ・状況に応じて迅速に対応できる機敏性 ◎Multi-clusterのスケーラビリティは十分/使用感は控えめに言っても最高 ◎必要なときに、必要な量を、利用できる柔軟性を確認 高いスケーラビリティ・アジリティ ・特にコンピュートリソースの統制が課題 ・誰がどれくらい使っているか可視化したい ◎シンプルかつ透明性の高いコスト統制が可能に 透明性の高いコスト統制 つまり、Snowflakeの強みは、スモールスタートでスピード感をもって導入できることと、大量の処理を高速にかつ柔軟にスケールすることができる拡張性もつ製品であることが分かります。 もちろん、この他にもデータウェアハウスサービスにはGoogle CloudのBigQueryやAWSのRedshiftなどがありますが、PayPayはこの中でもスモールスタートでコスト効率が高くデータ基盤を構築でき、かつ、S3に格納しているデータとの互換性が高いということでSnowflakeを選んでいるわけです。 次にどのようしてデータ基盤構築プロジェクトを３か月で達成したのかについて以下を実装したとのことでした。 ■インフラリソースはTerraformで構成管理 ■Data Pipelineの実装 ■AWS GlueによるサーバレスなApache Sparkの実行環境として利用 特に私がこの中で興味深かったのは「Data Pipelineの実装」でした。 上記添付のようにAmazon MWAA（Airflow DAG）を使ってデータを加工し、SnowflakeでDDL/DMLを実行を行うことでスキーマの作成・変更やデータの投入・更新処理が自動化されます。これにより人的な作業を減らすことができ、迅速なデータ基盤の構築ができたということでした。MWAAとは他のAWSサービス（Glue、Fivetranなど）と連携できるため、ETL処理とDDL/DMLの実行を統合し、一連のフローとして管理できます。これによって処理の一貫性と再現性が向上します。 また、Snowflakeは大量データの処理を高速かつ柔軟に行うことができます。MWAAからDMLの実行によって、必要なタイミングで必要なデータを投入できる仕組みを整えることを実現したとのことでした。 実装したこと全ては記載できていないですが、これらを使ってPayPayは3か月でデータ基盤環境を構築、社内公開を達成することができたのでした。。！ この項目の最後に、私はパートナーセッションでSnowflakeの存在を知りましたが、AWS Summitに行っていなければ、まだSnowflakeを知らずにいたと思います。SnowflakeはPayPayという大手決済システム企業で導入されている実績もあり信頼と実績のある製品だと感じました。 導入検討に向けて考えたこと それでは、PayPayのパートナーセッションを聞いてみて、実際にSnowflakeを導入しようとなった場合の検討事項を ３つ 考えてみました。 さっそく挙げていきたいと思います！ 検討事項１．データ基盤がクラウド上に構築されていること まず、PayPayではインフラ環境がAWSで構築されています。（以下添付参照） 資料： AWS Summitに出展・登壇しました！ | PayPay Inside-Out SnowflakeはAWSやAzure、Google Cloudのクラウドプラットフォーム上で動作します。ユーザーはSnowflakeでアカウントを作成し、これらいづれかのクラウドプロバイダーの基盤を選択し、ブラウザやSQLクライアントなどからデータベースにアクセスして利用します。 そのため、もし担当しているお客様環境でクラウドプラットフォームが整備されていない場合には導入の実現はできません。 PayPayが迅速にデータ基盤構築のためにSnowflakeを導入できたのは、そもそもAWS環境でプラットフォームが整っていたことも起因しています。 検討事項２．DataLake環境が必要となる もう一度、↑の画像をみてもらうと分かりますが、PayPayのインフラ環境では、そもそもクラウドプラットフォーム上にData Lake環境があります。 Snowflakeはデータを取り込む際、まずはクラウドストレージ（S3, GCS, Azure Blob Storageなど）を経由する必要があります。これらのクラウドストレージを利用できないと、データの取り込みができません。また、クラウドストレージに格納された後、データでETL（抽出、変換、ロード）処理のジョブを作成をする必要があります。これはGlue ETL、Cloud Data Fusion, Azure Data Factory (ADF)などでサービスを活用する必要があります。 加えて、Snowflakeへデータを連携するためにデータカタログが必要となる場合もあります。 このようなData Lake環境がSnowflake導入に必要であるため、それなりに新しい技術への知見が必要になることが分かります。   検討事項３．導入で得られるメリット 上記２つの課題は技術的な観点での課題でしたが、最後はビジネスメリットについてです。 PayPayでは急速な事業成長に比例して迅速に、かつ柔軟にスケールできるデータ基盤を構築することを求めていました。 パートナーセッションではSnowflakeはこのような状況で非常に高い効果を出すことができることができるように見受けられました。 このような状況化での導入によるメリットは検討できますが、データ活用によるメリットが薄い場合には検討することすら難しいかもしれません。 もちろんPayPayは１つの事例であり、Snowflakeの導入事例は多くあるため、お客様の状況に応じて検討するのが最適です。 参考までに導入事例に関するサイトです。 サイトURL： Snowflake：全てのお客様事例 Snowflakeの事例一覧 | クラスメソッド株式会社 お客様環境で実装はできるのか 結論、 上記課題を乗り越えて実装することは可能だが、お客様の環境でビジネスメリットを検討した上で導入ができる、 です。 課題を乗り越えて実装する場合、例えば今すぐには技術的に難しいもののお様側で環境が整えば活用したい場合、 SCSKで提供しているサービス を提案したり、その他代理店で販売しているベンダーに声をかけることもできます。 ※SCSKではSnowflake社と販売代理店契約を締結し、国内におけるSnowflakeの販売が可能となりました。また、​SnowFlakeを 最短 5 日で使い始められるサービス を提供しています。このサービスを上手く活用しつつ導入することを検討できるかもしれません。 サイトURL： Snowflakeソリューション│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション また、そもそもビジネスメリットがあるか分からず検討している場合には、まずはSnowflakeにて公式の 導入事例 などをみてイメージしてみることもできます。例えば金融業界においては金融資産に関する最適な提案に活用することや、審査の迅速化による業務効率化を図ることもできるようになります。他にもメーカーなどでは様々なデータやデバイスからデータが生成されサイロ化しています。そのデータを統一化することで、IoTデータ活用によるリアルタイムモニタリング、予知保全などにも有用です。 このようなメリットをお客様と一緒に検討し、さらには新しい顧客体験を一緒に考えていくことができるかもしれません。 おわりに そんなわけで、Snowflakeって名前は寒そうだけど、サービスとしてはアツかったです。 データ活用における最先端技術が利用できる製品である一方で、お客様の環境で実装可能なのか、利用するシチュエーションでメリットがどのくらいあるか等、検討する上での課題や弊害も多く存在すると感じました。 ただ今後も、PayPayのようなデータ活用を行う企業は増えていく考えられ、そのような状況でお客様に提案するためには一緒にデータ活用の目的やメリットを考え、共創していくことが必要なのだと思いました。 それでは、ここまで読んでいただきありがとうございました！

本記事は 夏休みクラウド自由研究2025 8/7付の記事です 。 2025年6月、Cato クラウドを AI を通じて操作するための MCP サーバの提供が開始されました！ Meet Cato’s MCP Server: A Smarter Way to Integrate AI Into Your IT & Security Processes  Cato’s Model Context Protocol (MCP) is now available. It lets AI agents query your Cato environment using natural langua... www.catonetworks.com 本ブログ記事では、Cato の MCP サーバが一体どういうものなのか、現時点で何ができるのかについて、詳しく見て行こうと思います。 そもそも MCP とは 生成 AI や LLM (大規模言語モデル) の技術開発の進展が非常に早い昨今、AI エージェントという文脈の中で MCP (Model Context Protocol) というものが賑わっています。 MCP は、2024年11月に Anthropic 社 (Claude という LLM の開発・提供を行っている会社) が発表したアプリケーションプロトコルです。 Model Context Protocol - Model Context Protocol The open protocol that connects AI applications to the systems where context lives modelcontextprotocol.io 様々なシステムや機能を AI に組み込むための標準的な仕組み、といった感じでイメージすると良いと思います。MCP について解説した記事は既に世の中で多く書かれていますので、本ブログ記事ではこの程度の説明に留めることとします。 以降では、本ブログ記事のテーマである Cato の MCP について解説していきます。 Cato MCP の利用イメージ まず、Cato の MCP のイメージを掴むために次の画像をご覧ください。 Cato の MCP サーバ実装を LibreChat という AI チャットソフトウェアに組み込んで実際に利用してみた例です。         ご覧のように、AI との会話を通じて Cato のサイトの情報を確認したり、ネットワーク品質の状況を確認したりできます。他にも最後の画像で AI が言っている通り、リモート接続ユーザの情報を確認することもできます。 Cato に関する管理・運用は通常は CMA (Cato Management Application) の Web 画面を通じて行いますが、任意の AI と組み合わせて会話ベースで行えるようになったというのが Cato の MCP の登場による変化です。 Cato MCP の機能 Cato の MCP サーバは、ソースコードとして次の GitHub リポジトリで公開されています。 GitHub - catonetworks/cato-mcp-server: This repository provides a local mcp-server for Cato Network's public GraphQL API This repository provides a local mcp-server for Cato Network's public GraphQL API - catonetworks/cato-mcp-server github.com 本ブログ記事執筆時点の最新版である v0.9.0 では、以下の14個の機能 (Tool) が提供されています。（ソースコードも確認しました。） 機能 (Tool) 概要 entity_lookup サイト、VPN ユーザ、管理者ユーザなどの一覧を取得する。 取得できる対象は EntityType に記載されているもの。 sites_by_location サイトの地理情報や PoP 接続情報を取得する。 site_details サイトの詳細情報や各種ステータスを取得する。 site_types サイトの接続タイプ (Socket, IPsec, vSocket など) を取得する。 socket_versions 各サイトの Socket のバージョンを取得する。 wan_connectivity サイトの WAN 側のステータスや PoP との間のトンネルのステータスを取得する。 user_details リモート接続中のユーザの接続状態、デバイス名、OS名などを取得する。 user_connection_details リモート接続中のユーザの PoP との接続に関する詳細情報を取得する。 user_software_versions リモート接続中のユーザの Cato Client のバージョン情報を取得する。 site_network_health ネットワーク品質の悪いサイトを抽出し、その RTT、ジッタ、パケットロス率を取得する。 top_bandwidth_consumers トラフィックの多いサイトやリモート接続ユーザを抽出し、その通信量を取得する。 metrics_timeseries_query サイトやリモート接続ユーザのネットワークに関する時系列データを取得する。 取得できるメトリクスは TimeseriesMetricType に記載されているもの。 metrics_site_summary サイトのネットワークに関する全てのメトリクスの集計データを取得する。 annotation_event_counter サイトのネットワークインターフェースで発生した変更イベントの回数を取得する。 取得できるイベントは AnnotationType  に記載されているもの これら機能を、AI との会話の中で利用できます。 先ほどの画面スナップショットの場合、私が AI に依頼したチャットの内容をもとに site_details や site_network_health の機能 (Tool) が実行され、その実行結果に応じて AI がわかりやすく回答してくれていました。 少しだけ内部の仕組みの話をすると、次のような流れで AI は動作しています。 AI チャットソフトは、ユーザが入力した内容と Cato の MCP で提供されている機能 (Tool) の情報を LLM に渡す LLM は、渡された情報を解釈し、どの機能 (Tool) をどのようなパラメータで実行するか決定し、AI チャットソフトに実行を指示する AI チャットソフトは、LLM の指示に従い Cato の MCP の機能 (Tool) を実行する Cato の MCP は、渡されたパラメータをもとに何らかの処理 (Cato の API の実行) を行い、結果を AI チャットソフトに返す AI チャットソフトは、MCP の実行結果を LLM に渡す LLM は、MCP の実行結果や初めに渡された情報をもとに文章を生成し、AI チャットソフトに返す AI チャットソフト (MCP クライアントとして振る舞う) や Cato の MCP サーバを介して、Cato と LLM を連携できたということですね。 Cato MCP で何ができるか 残念ながら現時点ではサイトやユーザに関する限られた情報の取得しか行えませんが、次のようなことであれば AI との会話を通じて行えるのではないでしょうか。 日常的な健全性チェックに関する運用 例）毎朝9時に、全サイトのステータス、接続先 PoP 変更イベントの発生有無、品質の悪いサイトの有無などを確認する。 障害・異常発生時のトラブルシューティング 例）特定のサイトで通信が遅いという報告があったとき、そのサイトの直近のステータス、トラフィック、RTTやパケットロスなどの指標を取得し、どのような状況がいつから発生しているか確認する。 リモート接続ユーザのサポート 例）リモート接続中のユーザからネットワークの不調に関する問い合わせがあったとき、ユーザのOS、クライアントバージョン、トラフィックの各種指標を取得して状況を把握する。 ソフトウェアバージョンアップに関する運用 例）新しいバージョンの Cato クライアントが提供されたとき、古いバージョンを利用しているユーザを抽出する。 さらに、インシデント管理システムや各種コミュニケーションツールなどが提供する MCP サーバも AI に統合すれば、AI との会話ベースで Cato の管理情報と様々なシステムを連携させることも可能になるはずです。 従来こういったことを行おうとすると、各システムの API を活用して連携させる仕組みを頑張って開発する必要がありましたが、MCP という標準化されたインターフェースが登場したことで AI を通じて容易にファジーに連携できるようになってきました。Cato の MCP により連携できるようになったのは、非常に喜ばしいことです。   今はまだサイトやユーザの設定変更を行えず、セキュリティ設定や各種イベント情報の取得もできませんが、将来的に MCP サーバの機能が追加されて様々な操作が行えるようになっていくことを期待しています。 特に、各種イベント情報の取得ができるようになれば、AI を SOC (Security Operation Center) チームの専門家と見立てて、会話ベースでのセキュリティ運用といったことも実現できるようになるのではと妄想しています。 参考：LibreChat を用いた Cato MCP 利用環境の構築 Cato の MCP サーバは任意の MCP クライアント環境で利用でき、公式のドキュメントには Claude Desktop を利用する方法が記載されています。ただ、今回は MCP クライアントとして LibreChat という AI チャットソフトウェアを利用しましたので、参考としてその環境構築方法について記載します。 今回の環境は、Amazon EC2 で起動した Amazon Linux 2023 のインスタンス上に構築し、LLM として Amazon Bedrock で提供される Claude を利用しました。 自マシンからのみアクセスすることを想定した最小限の構成であり、この環境を他の人に公開する際は他にも考慮すべきことが多々あるという点はご了承ください。 Bedrock の基盤モデルの有効化 Amazon Bedrock にて LLM の基盤モデルを利用できるようにする必要があり、その手順は こちらのページ  に記載されています。 今回は Anthropic 社の Claude 3.7 Sonnet を利用しました。 EC2 インスタンスの作成 Amazon EC2 で Amazon Linux 2023 のインスタンスを作成しました。 メモリは最低でも4GB以上のものにする必要がありました。（メモリが2GBだと、後述の LibreChat のセットアップの中でメモリ不足が発生しました…。） この EC2 インスタンスの中から Bedrock のモデルを実行することになるので、インスタンスのロールにて “AmazonBedrockLimitedAccess” ポリシーをアタッチする必要もあります。 以降、EC2 インスタンスに SSH 接続して作業していきます。 MongoDB のセットアップ LibreChat で必要となる MongoDB をセットアップします。 MongoDB のセットアップ手順は こちらのページ に記載されており、概ねその手順に従いました。 sudo vim /etc/yum.repos.d/mongodb-org-8.0.repo (※以下の内容でファイルを作成する) --- [mongodb-org-8.0] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/amazon/2023/mongodb-org/8.0/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://pgp.mongodb.com/server-8.0.asc --- sudo dnf install -y mongodb-org sudo systemctl start mongod LibreChat のセットアップ LibreChat のセットアップまで行います。 セットアップ手順は こちらのページ に記載されており、概ねその手順に従ってセットアップしました。 sudo dnf install git git clone https://github.com/danny-avila/LibreChat.git -b v0.7.8 cd LibreChat cp .env.example .env sudo dnf install nodejs npm npm ci npm run frontend 上記により、LibreChat のビルドまで完了します。 手順のページでは npm run backend というコマンドの実行が書かれていますが、これを実行すると LibreChat のサーバアプリケーションが起動します。ただ、Cato の MCP を利用するための設定がまだなので、起動はその設定後に行います。 Cato MCP サーバのセットアップ Cato MCP サーバの実装はローカルで実行する形式で用意されていますので、これをセットアップします。 sudo dnf install git git clone https://github.com/catonetworks/cato-mcp-server.git -b v0.9.0 cd cato-mcp-server npm install npm run build この MCP サーバは何かが常時起動しているわけではありませんので、ビルドまで完了すればOKです。 LibreChat の設定と起動 LibreChat のディレクトリにて、設定ファイルの変更・作成を行います。 vim .env (※以下の設定を追加・変更する) --- HOST=0.0.0.0 ENDPOINTS=bedrock,agents BEDROCK_AWS_DEFAULT_REGION=ap-northeast-1 BEDROCK_AWS_MODELS=apac.anthropic.claude-3-7-sonnet-20250219-v1:0 SEARCH=false --- vim librechat.yaml (※以下の内容でファイルを作成する) --- version: 1.2.1 mcpServers: cato: type: stdio command: node args: ["/home/ec2-user/cato-mcp-server/build/index.js"] env: CATO_API_HOST: api.catonetworks.com CATO_ACCOUNT_ID: "アカウントID(4桁または5桁の数字)" CATO_API_KEY: "APIキー" --- 設定したら、次のコマンドを実行して LibreChat の Web アプリケーションを起動します。 npm run backend 3080 番ポートで Web アプリケーションが起動しますので、あとはブラウザからアクセスしてユーザを作成すれば、AI チャットで Cato MCP を利用できるようになります。

こんにちは、SCSK株式会社の小寺崇仁です。 Zabbixの7.2から実装されたNETCONFについて検証したいと思います。 7.2の新機能につきましては、公式HPに記載がございます。 Zabbix 7.2の新機能 Zabbix 7.2 introduces new ways to visualize your data and host information, and improves upon various existing monitorin... www.zabbix.com Zabbix7.2はポイントリリースのため、サポート期間が短くなっています。 本番利用する場合は8.0LTSがリリースされるまでお待ちいただく事をお勧めします。 NETCONFとは NETCONFは、ネットワーク機器の管理・設定を行うための標準プロトコルです。 XML形式のデータとYANGデータモデルを使い、機器の設定や状態取得をプログラム的に実行します。 CLI操作に比べ、自動化、確実な設定、エラーチェックが容易で、セキュアな通信を提供。大規模ネットワーク運用における自動化基盤として利用されます。 ZabbixとNETCONF ZabbixからNETCONFを使って監視すると以下のメリットがあると考えられます。 確実なデータ取得: XML/YANGモデルによりデータ構造が明確なため、CLIスクレイピングと異なりフォーマット変更による監視破損リスクが低く、安定して正確な情報が得られます。 詳細な情報取得: SNMPでは難しい機器のより詳細な設定や運用状態を正確に監視できます。 セキュリティ強化: SSHベースで通信が暗号化され、セキュアな監視が実現します。 ベンダー依存低減: YANGモデルの標準化により、異なるベンダーの機器でも共通の監視ロジックを適用しやすくなります。   設定方法 Zabbix7.2とjuniperを使った設定内容をご紹介いたします。 juniperの設定 環境に合わせてサービスの起動、FWの穴あけを行います。 #サービスの有効化 set system services netconf ssh #FWの穴あけ set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services netconf アイテムの作成 以下の設定でアイテムを作成します。Juniperでインタフェースの情報を取得するサンプルです。 名前 任意 タイプ SSHエージェント キー ssh.run[,,830,,,netconf] ※ポートとNETCONFであることを指定します。 データ型 テキスト 認証方式 パスワード（環境に合わせて） ユーザー名 （環境に合わせて） パスワード （環境に合わせて） 実行するスクリプト （XML RPCタグ） <rpc> <get-interface-information> <detail/> </get-interface-information> </rpc> ]]>]]> <rpc> <close-session/> </rpc> ]]>]]> 上記アイテムを作成いただく事で、NETCONFを使用してXML形式のデータの取得ができます。 しかしXMLの生データだけでは、監視ができないので、環境に合わせてデータの加工の設定を行う必要があります。 次に、データ加工に必要なスキルを紹介します。   必要スキル XML RPCタグの作成 データ取得の際にXML RPCタグを使って、取得するデータを指定しています。 各機器ごとにタグが違うと思うので、注意が必要です。 juniperであれば、パイプで「display xml rpc」をつなげれば作成できるようです。 user@host> show interfaces t3-5/1/0:0 | display xml rpc <rpc-reply xmlns:junos="http://xml.juniper.net/junos/16.1R1/junos"> <rpc> <get-interface-information> <interface-name>t3-5/1/0:0</interface-name> </get-interface-information> </rpc> <cli> <banner></banner> </cli> </rpc-reply> 引用： https://www.juniper.net/documentation/us/en/software/junos/junos-xml-protocol/topics/task/junos-xml-protocol-rpcs-and-xml-mapping.html 保存前処理(javascript)でデータの加工 取得したXMLデータを加工、成形する際に保存前処理でJavascriptを書く必要があります。 加工、成形する目的としては、以下2点のためです。 ・XMLから所定の値(文字列)を抽出する ・後工程（依存アイテム、LLD）で使用しやすいように、データの加工（成形）する 依存アイテム、ローレベルディスカバリ(LLD)でアイテム分割 NETCONFで監視するアイテムを大量に作成すると、NW機器側に負荷がかかるため、まとめて取得して分割する必要があります。 その際に、依存アイテム、ローレベルディスカバリを使用すると分割することができます。 依存アイテム 依存アイテムは、まとめて取得したデータを分割保存するアイテムタイプです。 例えば、1回のNETCONFアイテムで「show version」の結果を取得したとします。 コマンド結果にある、「OSの種類」と「バージョン」を別々のアイテムとして保存する場合に使用します。 ローレベルディスカバリ インタフェースごとにアイテムを作成する場合に使用します。 機器ごとにインタフェースの数、名前が違うと思います。 ローレベルディスカバリでは、機器に合わせて自動的にアイテムを作成する事ができます。   監視設定が難しい場合 ZabbixインテグレーションにJuniperのNETCONF用テンプレートが公開されております。 その他の機器についてもリリースされることを期待して待つのもよいかと思います。 https://www.zabbix.com/jp/integration_search?search=netconf SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

はじめに 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-サービスグループ」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_service_group 　を使用。 ※参考ページ： Ansible Galaxy galaxy.ansible.com   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   Objects-サービスグループの登録　※サービスグループの新規作成の場合 接続情報と　サービスグループとサービスの関連付け　を指定して登録（ state: ‘present’ ）を行う。 - name: Present ServiceGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001'　　　←　サービスグループ value: 'test_service001'　　←　サービスグループに関連付けするサービス state: 'present' register: wk_result 実行結果：対象のサービスグループが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの登録　※サービスグループが既に存在する場合 接続情報と　サービスグループとサービスの関連付け　を指定して登録（ state: ‘present’ ）を行う。　 ※サービスグループが既に存在する場合は、既存設定の置き換えとなる（state: ‘replaced’と同様）   - name: Present AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001'　　　←　サービスグループ value: 'test_service002'　　←　サービスグループに関連付けするサービス state: 'present' register: wk_result 実行結果：既存のサービスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの変更　※登録のつづき（新たなサービスを関連付けする） 接続情報と　サービスグループとサービスの関連付け　を指定して、サービスグループの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる　（注意：関連付け後の状態を指定すること！！） - name: Replaced AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001' value: ['test_service001','test_service003']　←　関連付け後の状態を指定すること！！ state: 'replaced' register: wk_result 実行結果：既存のサービスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   接続情報と　サービスグループとサービスの関連付け　を指定して、サービスグループの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定を維持した更新（Append）となる。 その為、特定サービスの関連付け解除はできない　（注意：サービス の関連付け解除をしたい場合は　state: ‘replaced’　を使用する必要がある！！）   - name: Merged AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001' value: 'test_service003'　←　関連付けしたいサービスのみ指定すること！！ state: 'merged' register: wk_result 実行結果：既存のサービスグループが 更新（Append） された。 既存設定が維持されていることを確認 。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの情報収集　※変更のつづき 接続情報と　サービスグループ　を指定して情報収集（ state: ‘gathered’ ）を行う。 - name: gathered AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001' state: 'gathered' register: wk_result 実行結果：対象サービスグループの 情報が取得 できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "gathered_xml": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの削除　※変更のつづき 接続情報と　サービスグループと関連付いているサービス　を指定して、削除（state: ‘absent’）を行う。　（ 注意：関連付いているサービスが削除されるのではなく、サービスグループが削除される！！）   - name: Absent AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001'　　　←　サービスグループ　※サービスグループが削除される value: 'test_service003'　　←　サービスグループに関連付いているサービス　※指定の必要なし state: 'absent' register: wk_result 実行結果：対象のサービスグループが 削除 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n", "after" : ""   最後に 「Ansible」の「paloaltonetworks.panos.panos_service_group」を使用し、「Objects-サービスグループ」の登録／変更／削除　および　情報収集ができたことは良かった。何らかの変更申請の仕組みと連携することで、より　設定変更の自動化　が活用できるようになると考える。 現状　設定情報がベタ書きで使い勝手が悪いので、今後　設定内容をINPUTする仕組みを試みたいと思います。 また、引続き　他にも様々なNW機器設定を自動化してみようと思います。

こんにちは。SCSKの松渕です。 皆さん、ペット飼っていらっしゃいますか？自分のペットは、周りとどれだけ違うんでしょうか。気になったことありませんか。 そして、AIでどれだけちゃんと識別できるんだろうか、と。 ということで、今回はGoogle Cloud Vertex AIのAutoMLを利用して、 写真に写っている猫を、私の飼っている猫（リク）と、そのほかの猫を分類するモデル「リクか、リク以外か」を作ってみました。 用語整理　～Vertex AI と AutoML と Vertex AI Vision～ 前段として用語の整理します。コロコロと名前変わるのでわかりにくいですよね。。 Vertex AI Google Cloudが提供するAI開発のための 統合プラットフォーム です。 データの準備からモデルのトレーニング、そして運用まで、AI開発の全工程をサポートする強力な基盤といえます。 Vertex AIの中では、AIモデルを作るためのアプローチとして、主に2つの方法が提供されています。           カスタムトレーニング ：データサイエンティストがPythonなどのコードを書いてモデルを構築する方法です。 AutoML（自動機械学習） ：今回利用する方法で、専門的な知識がなくてもカスタムAIモデルを作成できる機能群です。 AutoML Vertex AIプラットフォーム内で利用できる機能群で、 専門家でなくてもカスタムAIモデルを作成 できます。「画像」「テキスト」「表データ」など、様々なデータに対応したAutoMLがあります。今回は、 画像を使ったAutoML を利用しました。 以前は「AutoML Vision」と呼ばれてました。 Vertex AI Vision: 少し混乱しやすいのですが、 Vertex AI Vision （旧称Visual Inspection AI）という全く別のサービスもあります。リアルタイムの動画ストリームや膨大な画像データから継続的にインサイトを抽出し、高度なビジョンAIアプリケーションを構築・運用することを目的としています。 製品の正常/異常の分類　タスクについて 今回はAutoMLですが、Vertex AI Vision（旧称Visual Inspection AI）でも「製品の正常/異常の分類」という目的であれば画像から二値分類タスクができます。 Visual Inspection AIの新モデル Anomaly Detection を触ってみた！！(Tech hermony) データ準備 Step1：目標枚数の決定 画像分類用のAutoMLでは、 各ラベルにつき最低10枚 のサンプルがあればモデル作成できます。今回のケースでは最低20枚（リク10枚、リク以外10枚）が必要でした。一般的に、学習データは多ければ多いほど精度が向上し、画像のパターンも可能な限り多様な条件である方が望ましいです。 今回は、リク50枚、リク以外50枚の合計100枚で試しました。 Google Cloudのドキュメントでは、各ラベル（クラス）につき 1,000枚以上 を推奨しています。 AutoML モデルの上限(Google Cloud ドキュメント) データ拡張（Data Augmentation）について 最低10枚という非常に少ない枚数でも学習できるのは、 内部的にデータ拡張が行われている ためだと考えられます。 事前構築済みの検索スペース(Google Cloud ドキュメント) データ拡張（Data Augmentation）って知っていますか？？①(Tech hermony) サンプルの集め方について 「画像のパターンも可能な限り多様な条件」と書きましたが、これは一般的な原則です。 ユースケースによっては、特定の条件に画像を揃えた方が望ましい場合もあります。 例えば、動物病院で診察前の猫の全体像を映した写真のように、 固定の場所である程度統一された画角で撮影されることが想定される場合 は、サンプル画像もそれに合わせて 条件が統一されたもの で集めた方がモデルの精度は高まります。 一方で、 今回は「いわゆる日常写真」から リクを分類することを想定していたため、明度や背景、リクのポーズなども意図的に 「多様な条件」 で収集しました。 Step2：サンプル画像収集（リク画像） スマホに保存されている沢山の画像の中から50枚選んでPC送るだけでした。かわいい。   Step3：サンプル画像収集（リク以外画像） 猫カフェに行った時の写真や親戚の猫の写真などを集めました。 気持ち、リクと色味が似ている猫を中心に集めました。こちらもかわいい。 構築 Step4：データセットの作成 データセット作成画面へ Vertex AI のトップ画面（ダッシュボード）の下段にある「データセットを作成」を押下します。 単一ラベル分類を選択 データセットを作成の画面に遷移します。 データセット名を入力します。 今回は二値分類タスクのため、「単一ラベル分類」を選択して、「作成」を押下します。   データ保管のリージョンについて 上記の画面でリージョンがアイオワになっていることに気づいた方もいるかもしれません。 これは、内部的にVision Warehouseを使用しているためで、このブログ執筆時点では、 提供されているリージョンがオランダとアイオワのみとなっています。 Vision Warehouse のリージョンの選択(Google Cloud ドキュメント) そのため、 画像のAutoML 使う場合、データ保管リージョンに 日本を選べない のでご注意 ください。 画像インポート方法選択 画面のインポート方法を選択。今回はパソコンから直接画像アップロードしました。 画像アップロード確認 パソコンからアップロードしたらこのような画面が出てきました。 データ分類（トレーニング、検証、テスト）が各画像に対して選べるようになってます。 下にスクロールし、サンプル画像を保管するGCSのパスを入力して「続行」を押下します。 インポートを待つ インポートが開始されます。時間を計測していませんでしたが、合計100枚（約22MB）で20分くらいかかったと思います。 愛猫への思いが強く、画像が大きめだったのも原因かもしれません。 以下のような文言が出てきます。 また、インポート終わったらメールも届きます。 Step5：ラベリング ラベル定義 インポートが終わるとデータセットの画面にデータがずらっと並びます。とてもかわいい。 新規ラベル追加をクリックしてラベル作ります。 今回は「riku」と「non_riku」としました。ちなみに、ラベルに日本語やハイフンは使えません。 ラベル割り当て 画像選択してラベル割り当てます。 Step6：トレーニング トレーニング開始ボタン押下 すべての画像にラベルを割り当てられたら、右側の「新しいモデルのトレーニング」を押下します トレーニング方法選択 カスタムモデルを作る場合はここでカスタムトレーニングを選択します。今回はAutoML選択。 余談ですが、「Edgeモデル」も選択できます。 これは、リアルタイム応答が必要な場合や、IoT機器への搭載、オフラインで動作させるようなユースケースで有用です。 AutoML Edge モデルのトレーニング(Google Cloud ドキュメント) モデルの詳細 今回は新しいモデルのトレーニングを選択します。 学習の割合は手動で変えることも可能ですが、今回はデフォルトの通りの割合で進めます。 Vertex AIのデフォルトで以下の割合で分割されます。 トレーニング：80% 検証：10% テスト：10% AutoML モデルのデータ分割の概要(Google Cloud ドキュメント) トレーニングオプション 増分トレーニングかどうか尋ねられます。既存のモデルに追加学習を行う場合は増分トレーニングを選び、既存モデルを選択します。 今回は新規なのでそのまま続行します。 ノード時間の最大値を選択 どの程度の時間使って学習するかの最大値を選択します。 8～800の間 で入力します。最小の8で進みます。     トレーニング待ち トレーニング完了まで待ちます。 なお、トレーニング完了したらメールが届きます。 トレーニング完了 トレーニング完了したら、「トレーニング」の項目に完了と出力されます。 今回は1時間43分かかりました。 評価、デプロイ Step7：評価結果確認 モデル全体の評価指標確認 AutoMLの素晴らしい点の一つは、 モデルの評価まで終わらせてくれる ところだと思います。 トレーニング終わった時点で 再現率、適合率、混合行列、PR曲線等の各種指標を出力 してくれます。 今回は、いい感じに1つ間違えていました。 偽陽性が1サンプル ありますね。 参考までに、混合行列と再現率/適合率/正解率の計算方法は以下の通りです 間違えたサンプルの確認 混合行列で、1サンプル間違えているのが確認できました。 評価のラベルから「riku」ラベルを選択すると、 間違えたサンプルと正解したサンプルが見れます 。 ・・・なるほど、リクっぽい猫ですね。 ただ、スコアも0.552と、閾値である0.5をわずかに上回っただけだったことが確認できます。 正しかったサンプルの確認 正しく分類できたものは、どれも高いスコアであることがわかります。かわいい。 non-rikuも0.78～1の間のスコアでした。 実案件においては、 スコアによって対応を変えるケース も考えられます。 例えば、0.5を閾値にして「リクか、リク以外か」の二値分類とするだけでなく、 スコアが0.7未満の場合には「リク以外の可能性もある」といった選択肢を設け、 人間が目視確認するフローを組み込むなど 、ユースケースに応じた柔軟な対応検討が必要となるでしょう。 Step8：デプロイして遊んでみる やりたいことはほぼ終わったのですが、せっかくならデプロイまでしようと思います。 エンドポイントにデプロイを選択 モデルの画面から、「デプロイとテスト」を選び、「エンドポイントにデプロイ」を押下。     エンドポイントの定義 エンドポイント名を選択して続行を押下します。 画面に記載の通りですが、 エンドポイントは標準（インターネット経由でのアクセス） になります。 プライベートアクセスにするには、カスタムモデルもしくはAutoML 表形式モデルのみです。 とはいえ、デフォルト設定でも IAMで認証されたトークンが必須 になるため、 誰でもアクセスできるわけではないのでご安心ください。 モデル設定 モデル設定を行います。「コンピューティングノードの数」は、今回は1としてます。 本番環境への適用なら2以上をお勧めします。 AutoMLのSLOは、2ノード以上を利用した前提で99.9%と定義 されております。 AutoML VisionのSLO(Google Cloud ドキュメント)     モデル設定 モデルのデプロイされるまで待ちます。   テスト デプロイも完了したらメールきます。体感10分くらいでした。 以下の画面のステータスが「アクティブ」になります。 また、下部に「モデルのテスト」という項目が出てきました。ここからテストします。   今までのサンプルとはまた別の画像でテストしてみます。しっかりとリクと判定されましたね！ かわいい。 今回はコンソールからGUIでのテストで終わりますが、もちろんAPIからも呼び出し可能です。 後片付け エンドポイント削除の前に、モデルのデプロイを解除が先に必要です   エンドポイントの削除が可能になりました。削除して終わります。 Step9：コストの確認 後日、コスト確認しました。 合計　 \4,259- 　でした。 トレーニング（8ノード時間）：　 \4,120- デプロイ（1ノード、約40分）：　\   139- まとめ 今回は、Google Cloud Vertex AI の AutoML を使って、愛猫リクとそれ以外の猫を分類するオリジナルAIモデル「リクか、リク以外か」を構築しました。 AutoML を利用することで、専門的な知識がなくても、 データの準備からラベリング、モデルのトレーニング、そして評価、デプロイまでの一連のプロセスをスムーズに進められる ことがお分かりいただけたかと思います。特に、直感的な GUI 操作で高品質なモデルが構築できる点は、AutoML の大きな魅力です。 実際のビジネス案件でAIモデルを使うとなると、評価は非常に重要なポイント になります。100%の精度は現実的に難しいため、どの評価指標を重視するか、そして間違えた場合の対応をどうするかといった判断が不可欠です。 具体的には、 再現率 を重視するのか、 適合率 を重視するのか。また、誤分類が発生した際の セーフティネットとして人の判断を組み込む のか、といった検討が求められます。各評価指標を深く理解した上で、 「このユースケースでは、この程度の数値が出ればビジネスに活用できる」という明確な判断基準 を持つことが、AI導入成功の鍵となるでしょう。

本記事は 夏休みクラウド自由研究2025 8/6付の記事です 。 今年もSCSKの技術ブログ「TechHarmony」で今月「夏休みクラウド自由研究 2025」企画が開始されていますが、Catoクラウドチームとしては、8/4から8/13の合計10記事を担当します。   はじめに 「夏休みクラウド自由研究」として別テーマで記事を考えていたのですが、ちょうど昨日（2025年8月5日）Cato Networks社のパートナープログラムについての”お知らせ”を掲載することになったため、その補足記事を投稿することにしました。 昨日の”お知らせ”については以下をご覧ください。 Cato Networksのパートナー最高位である「MSP Advancedパートナー」を獲得し、SASE導入さらに加速 Cato Networks社のパートナープログラムは、正式には「 Cato Networks チャネルファーストパートナープログラム 」というものです。 パートナープログラムの詳細については公式ページをご覧ください。 https://www.catonetworks.com/ja/partners/ Cato Networksのビジネスは、100％パートナー経由であるため、パートナーのビジネス成長が、Cato Networks社のビジネス成長となるため、より高いレベルで包括的な支援を提供すべく今回パートナープログラムが用意されました。 実際には、数年前から、Cato Networks社にはパートナープログラムの整備や、Cato Networks社のホームページ上へ、パートナー企業を掲載するように依頼をしていたのですが、やっとパートナープログラムがリリースされたことになります。 しかしながら、まだパートナー掲載ページは準備されていませんので、Catoクラウドを検討されるお客様にとっては、パートナーがどこなのか分からず、ご自身でWeb検索や問い合わせをするしかない状況は変わっていません。   パートナータイプ 比較のために、例えばAWSにおいては、パートナーは、パートナータイプごとに「サービスパス」「ソフトウェアパス」「ハードウェアパス」「トレーニングパス」「ディストリビューションパス」の5つの”パス”に分けられています。 ちなみに、AWSにおいてSCSKは「サービスパス」となります。 Catoのパートナーも、パートナータイプごとに特化された「 サービスプロバイダー（SP） 」、「 マネージドサービスプロバイダー（MSP） 」、「 付加価値再販業者（VAR） 」、「 エージェント 」といった4つのプログラムが準備されています。また、現時点では 日本国内パートナーは、MSPとVARの2つのいずれかに分類 されています。 上記以外に、いわゆる一次卸業者・ ディストリビューター（Distributor） がありますが、お客様が直接Catoクラウドのライセンスを購入したり、設計/構築、保守運用を受けるのは、ディストリビューターではなく、パートナー（上記4つのいずれかのタイプから）となりますので割愛します。 ディストリビューターからは、Catoクラウドのライセンス購入したり、その他サービスを受けることはできませんので、必ずパートナーを見つける必要があります。 SCSKはパートナーで、単なるCatoクラウドのライセンス販売だけではなく、PoC支援から設計/構築/移行はもちろんのこと、独自のマネージドサービス、マネージドセキュリティサービス（SOC、セキュリティアドバイザリーサービスなど）を提供しており、Cato社のサポート認証「Cato Distinguished Support Providers（CDSP）」も取得していることから 「マネージドサービスプロバイダー（MSP）」に認定 されております。 CDSPについて https://blog.usize-tech.com/cato-cdsp-scsk/   パートナーランク（ティア） AWSパートナーでは、実績や専門性に応じて「セレクト」「アドバンスト」「プレミア」の3つのティア（ランク）が準備されています。 ちなみにAWSでは、当社は最上位である「プレミア」となりますので「サービスパス」と合わせて、SCSKは「AWSプレミアティア サービスパートナー」となります。 Catoのパートナープログラムも階層型になっており、パートナーのエンゲージメント、投資、パフォーマンスのレベルに合わせて、最初の階層である「 スターター（Starter） 」と、上位の「 アドバンスド（Advanced） 」の2つのランクが準備されています。 AWSとは異なり「プレミア」はまだ準備がされていないため 「アドバンスド」が現時点での最上位ランク（ティア） となります。 パートナーランク（ティア）の条件は公開されていないため、ここでも記載は割愛しております。 SCSKは、ランク条件をクリアし、最上位の「アドバンスド」認定を受けておりますので、「マネージドサービスプロバイダー（MSP）」と合わせて、「 Cato Networks MSP アドバンスドパートナー 」を獲得 したことになります。   パートナー選びについて Catoクラウドの検討が進み、ライセンス見積り、設計/構築見積りなどが必要となった場合は、パートナーを選ぶ必要があります（ディストリビューターではなく） 単純にCatoクラウドのライセンスを購入するだけの場合は「 エージェント 」パートナー、Catoクラウドの設計/構築なども委託をしたい場合には「 付加価値再販業者（VAR ）」パートナーから選ぶことも可能ですが、Catoクラウドの設計/構築だけではなく、その後の運用保守（マネージドサービス、SOC）を含めた支援やサービス提供を “安心して” 提供を受けたい場合には「 マネージドサービスプロバイダー（MSP） 」パートナーから選ぶ必要があります。 現在（2025年7月時点）、日本国内にはCatoパートナー企業が 150社 以上存在します（ちなみにCatoクラウドの国内導入実績は約650社です） 前述の通り、日本国内パートナーは「マネージドサービスプロバイダー（MSP）」と「付加価値再販業者（VAR）」のいずれかに分類されていますが、その殆どは「付加価値再販業者（VAR）」の「スターター」となります。また、その内、販売実績があるパートナーは約50社（1/3）とのことですので、実績のないパートナーが約100社近くいることには注意が必要です。 実際に、別のパートナーでPoCを実施したが、問い合わせの回答が返ってこず、PoCが思ったように進まず、改めて当社へ声掛けをいただいた例や、すでに本番利用されていて、不具合が発生しており、問い合わせを実施しているが、何ヶ月も不具合が解消せずに困って当社へお問い合わせいただく例も増えてきています。 Catoクラウドのパートナー選びにおいては、単純にディストリビューターに紹介されたパートナーや、既存取引のあるパートナーへ声掛けをするのではなく、正しくパートナー選びを行うために、今回のパートナープログラムが整備されました。 これまではCatoクラウドのマネージドサービスが必要な場合のパートナー選びは 24時間365日の電話/メールのサービス窓口がサービス提供されているか？ CatoのSD-WANエッジデバイスであるCato Socketの24時間365日のオンサイト保守（4時間駆け付け）がサービス提供されているか？（標準保守はセンドバック） CatoのSOCがサービスが提供されているか？ 単純にサービスメニューがあるだけでなく、導入実績（具体的な顧客導入事例）があるか？ Catoクラウド認識技術者を複数名以上有しているか？ 「Cato Distinguished Support Providers（CDSP）」認証を取得しているか？ などの個別で確認が必要でしたが、今回パートナープログラムがリリースされたことにより、 パートナータイプは「マネージドサービスプロバイダー（MSP）」なのか？ パートナーランクは「スターター」なのか「アドバンスド」なのか？ だけで、容易に確認できるようになりました。 残念ながらCato社のホームページ上でパートナーを掲載するページはまだ準備されていませんが、パートナー企業へパートナータイプとランクを確認することで容易に判断が可能となりました。   まとめ SCSKは「 Cato Networks MSP アドバンスドパートナー 」を獲得しただけではなく、先月（2025年7月15日）に開催されたCato Networks社の日本で3回目となるパートナーサミット「Japan Partner Summit Tokyo 2025」で、 3年連続でアワード受賞 をしています。 新規顧客の売り上げに最も貢献したパートナーとして「 Japan Highest New Logo Revenue 2024 」と、最も卓越したサポートを提供し、お客様の満足度向上に貢献したパートナーとして「 Japan Best Technical Support Partner 2024 」の2つのアワードを ダブル受賞 しています。 Cato Partner Summit 2025 で 3年連続パートナーアワード受賞、さらに今年はダブル受賞！ Cato Networks社のパートナーサミット「Japan Partner Summit Tokyo 2025」で 3年連続パートナーアワード受賞、今年はダブル受賞となります。 blog.usize-tech.com 2025.07.22 つまり、新規にCatoクラウドを検討しているお客様はもちろんですが、すでにCatoクラウドをご利用中でサポートを含め各種マネージドサービスに困っているお客様がもしいらっしゃれば、ぜひ当社まで お問い合わせ ください。 日本国内でも「SASE（Secure Access Service Edge、サッシー）」、「Cato Networks（ケイトネットワークス）」、「Catoクラウド（正式名称は、Cato SASE Cloud Platform）」の認知度は徐々に上がっていますが、まだまだ認知度が高いとは言えない状況です。 SCSKでは、2021年からSASEの主要な４ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（S4、エスフォー）」を定期的に開催しております。これまで15回開催し、述べ2,200名以上の方にご参加いただいております。Catoクラウドにおいては、SASE初心者向けの簡単セミナー、主要機能を2時間で説明するデモセミナーをオンライン（無料）で開催し、さらに全国各地で半日のハンズオンセミナーを年間通じて定期的に開催しておりますので、ご興味ある方は、ぜひご参加ください。 Catoクラウド イベント・セミナー情報 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 定期的にCatoクラウドをご紹介するセミナーを開催しております。・2024年9月26日（木）Catoクラウド ハンズオンセミナー【札幌開催分】　～全国5都市開催（東京/大阪/名古屋/博多/札幌）～　... cato-scsk.dga.jp 最近、Catoクラウドのパートナーが増え、同業他社からお申し込みが増えておりますが、事前に当社にご相談のないパートナー様からお申し込みは、事務局でお断りしておりますので、予めご了承ください。 セミナー以外に、Catoクラウドの お客様導入事例 の制作、好評をいただいているCatoクラウド FAQサイト 運営、この TechHarmony（技術ブログ） で、Catoクラウドの日本語での情報提供を積極的に行い、皆様のお役に立ち、Catoクラウドの認知度の向上ができればと考えております。 最後に、Catoクラウドをご利用者（ユーザ）様を対象としたユーザーコミュニティ「 Cato Circle（ケイトサークル） 」を発足しました。 Catoクラウド ユーザーコミュニティ「Cato Circle」を発足しました！ Catoクラウド ユーザーコミュニティ「Cato Circle（ケイトサークル）」の発足についての記事となります。 blog.usize-tech.com 2025.07.02 Cato Circleは、ユーザーコミュニティなので、通常のセミナーのように一方的に説明を行う「説明型」イベントではなく、利用者であるお客様が、Catoクラウドの自社での活用方法や、利用上の課題を発表し、利用者同士が情報を共有する「双方向型」のイベントとなります。 お客様同士のネットワーク構築・交流から、情報交換のきっかけをご提供し、課題や悩みを共有し、解決のヒントを得ていただくことが Cato Circle の目的となっております。 Catoクラウドをご検討中のお客様も参加いただくことが可能ですので、Catoクラウドに少しでも興味をお持ちになられた方は、ぜひ当社まで お問い合わせ ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27

皆さん、こんにちは！ 皆さん、生成AI活用していますか？ 文章を書かせたり、プログラムのコードを生成させたり、最近では気兼ねなく悩みを打ち明けられる良き相談相手として活用している人もいるようです。 でも、なんだか彼らの回答って、いつも丁寧で優等生すぎると思いませんか…？ 「もちろんですよ！」「お役に立てて光栄です！」 …いや、嬉しいんだけど、たまにはもっと個性的で、厳しくしてくれるAIがいてもいいのでは…？ そんなことを考えていた私は、ふと思いました。 「人間の相談にズバッと答えらられる、こてこての関西弁のAIがいてもいいのではないか？」 というわけで今回は、Amazon Bedrock、Amazon Rekognitionを使って、 食事の画像を送ると、その内容を認識して関西弁で鋭いツッコミと的確なドリンク提案をしてくれる「辛口AIソムリエ」 を開発してみました！ この記事は、 生成AIで何か面白いものを作ってみたい！ AWSに興味があるけど、何から始めればいいかわからない… プログラミング初心者だけど、AIアプリ開発に挑戦したい！ という方にピッタリな内容です。早速アプリの概要を見ていきましょう。 実際にAIソムリエに相談してみよう 百聞は一見にしかず！ということで、まずはこの「辛口AIソムリエ」がどんな風に動くのか見てみましょう。 例えば、深夜に飯テロの定番、ピザの画像をAIに送ってみると… 【AIソムリエからの返信】 うわぁ、なんやこのハイカロリーなピザは！? お前、夜中にこんな濃い味付けのものを食べとるんか!? アホちゃうかいな。ほんまに… (ひと呼吸おいて)まぁしゃあないからこの俺が特別に合う飲み物を選んでやるわ。 1. サングリア – スパイシーなピザに合うのは、程よい酸味とフルーツの香りを持つ赤ワインベースのサングリアやろ。食欲もそそられるしな。 2. トマトジュース – 濃厚なトマトソースと同化する赤い果汁飲料は、ピザの重たさを軽減してくれるはずや。ビタミンCも補給できてお得やろ? 3. コーラ – 炭酸の刺激的な喉越しが脂っこいピザをスッキリさせてくれる。糖分もあるから夜食にぴったりやで。 お前らも知らんふりしてたけど、結構グレードの高い組み合わせやと思うぜ? なんでやねん、この俺に任せときゃよかったんちゃうの? …どうでしょう？（笑） めちゃくちゃ口は悪いですが、言っていることは意外と的確。こんなAIがいたら、日々の食事がちょっと楽しくなりそうじゃないですか？   システムの全体像（アーキテクチャ） さて、このAIソムリエがどんな仕組みで動いているのか、簡単な図で見てみましょう。 ユーザーが食事の画像のURLを、 AWS Amplify で作成したフロントエンドからAPIに送ります。 Amazon API Gateway が「受付窓口」としてリクエストを受け取ります。 AWS Lambda が「司令塔」としてメインの処理を実行します。 Lambdaは、まず画像の分析を Amazon Rekognition に依頼します。 Rekognitionは画像から「Pizza」や「Cheese」といったキーワード（ラベル）を返します。 次にLambdaは、そのキーワードを基に Amazon Bedrock に応答文の生成を依頼します。このとき、AIの回答を調整するためにプロンプトを設定します。 Bedrockが生成した個性的な文章が、ユーザーに返されます。 このように、Lambdaを中心にRekognition、Bedrockで回答作成をしてもらうことでサーバーレスなサービスを実現しています！   このシステムのキモ！AIに魂を吹き込むプロンプト設定 このシステムの面白さの9割は、Amazon Bedrockに渡しているプロンプトにあるといっても過言ではありません。 プロンプトとは、生成AIに対する「指示書」や「台本」のようなものです。ここの書き方次第で、AIの性格や口調、役割を指定して回答を調整していきます。 ただ「ピザに合う飲み物を教えて」と聞くだけでは、普通の丁寧な答えしか返ってきませんので、今回は以下のようなプロンプトを用意しました。 # 命令 あなたは辛口な関西人として、AIソムリエの役割を完璧に演じてください。 # あなたのキャラクター設定 (ペルソナ) - **口調:** 常に横柄でドSな関西弁。一人称は「俺」、相手のことは「お前」と呼ぶ。 - **性格:** 短気でせっかち。回りくどいことは大嫌い。面白いかどうかを常に考えている。 - **口癖:** 「なんでやねん！」「アホか！」「知るか！」「しゃあないな」などを自然な会話の流れで使うこと。 - **行動:** 1. まず、目の前にある食べ物（入力情報）に対して、強烈な一言（イジりやツッコミ）をかます。例：「なんやこれ、茶色いな！」「こんなもん夜中に食うとんのか、アホやろ！」など。 2. 次に「まぁしゃあないから、この俺が特別に合う飲み物を選んだるわ」というような、恩着せがましい前置きを入れる。 3. 最後に、最高のドリンクを3つ(アルコール飲料とソフトドリンクをバランスよく)提案する。提案理由は的確で分かりやすいが、言い方は偉そうにすること。 # 入力情報 - Rekognitionが画像から検出した食べ物の特徴: {', '.join(labels)} # 出力タスク 上記のキャラクター設定を忠実に守り、入力情報に対して最高のドリンク提案を生成してください。 ポイントは、AIに 「あなたは何者か（ペルソナ）」と「具体的にどう振る舞うべきか（行動）」 を、箇条書きで分かりやすく指示している点です。 このように細かく役割設定をすることで、AIが指定されたキャラクターになりきって応答を生成してくれるようになります。これこそが「プロンプトエンジニアリング」の面白さですね…！   全体を動かすLambdaの中身 最後に、司令塔の役割を果たすAWS Lambdaのコード（Python）を見てみましょう。 全体の流れはとてもシンプルです。 import json import urllib.request import boto3 # 各サービスクライアントを準備 # (Bedrockはバージニア北部リージョン 'us-east-1' が推奨です) bedrock_runtime = boto3.client( 'bedrock-runtime' , region_name= 'us-east-1' ) rekognition = boto3.client( 'rekognition' ) def handler ( event, context ): try : # 1. 画像URLを受け取る body = json.loads(event.get( 'body' , '{}' )) image_url = body.get( 'imageUrl' ) # 2. Rekognitionで画像からキーワードを検出する with urllib.request.urlopen(image_url) as response: image_bytes = response.read() response_rekognition = rekognition.detect_labels( Image={ 'Bytes' : image_bytes}, MaxLabels= 10 , MinConfidence= 80 ) labels = [label[ 'Name' ] for label in response_rekognition[ 'Labels' ]] # 3. 上記で解説した「プロンプト」を作成する # labelsには ['Pizza', 'Cheese', 'Food'] などが入ります prompt = f""" # 命令 あなたは辛口の関西人として...(中略)... # 入力情報 - Rekognitionが画像から検出した食べ物の特徴: {', '.join(labels)} # 出力タスク ...(後略)... """ # 4. Bedrockにプロンプトを渡し、応答を生成してもらう model_id = 'anthropic.claude-3-sonnet-20240229-v1:0' request_body = { "anthropic_version" : "bedrock-2023-05-31" , "max_tokens" : 1000 , "messages" : [{ "role" : "user" , "content" : [{ "type" : "text" , "text" : prompt}]}] } response_bedrock = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=model_id, ) response_body = json.loads(response_bedrock.get( 'body' ).read()) suggestion_text = response_body[ 'content' ][ 0 ][ 'text' ] # 5. 生成された文章をユーザーに返す return { 'statusCode' : 200 , 'headers' : { 'Access-Control-Allow-Origin' : '*' , 'Content-Type' : 'application/json' }, 'body' : json.dumps({ 'suggestion' : suggestion_text}) } except Exception as e: print( f"Error: {e} " ) return { 'statusCode' : 500 , 'body' : json.dumps({ 'error' : str (e)})}   まとめと今後の展望 いかがでしたでしょうか？ この記事を通して、AWSのAIサービスを組み合わせることで、ただ賢いだけでなく、人間味あふれる（？）個性的なAIアプリケーションを簡単に作れることを実感いただければ幸いです！ Amazon Rekognition→ 現実世界の情報をインプット！ Amazon Bedrock → プロンプトエンジニアリング でAIに役割を付与、回答を作成 AWS Lambda→システム全体の連携 このパターンを覚えておくだけで、作れるものの幅がグッと広がるはずです。 今回は関西弁のツッコミAIでしたが、自分の好きなアニメキャラクターの口調を真似させてみるなど、回答の方向性を調整することも可能です！ 「食事だけじゃなくて、服装を判定してファッションチェックさせるのも面白いかも？」 そんな風に、ぜひ皆さんのアイデアで、もっと面白くてユニークなAIをたくさん生み出してみてください！ 最後まで読んでいただき、ありがとうございました！ぜひ皆さんもサーバーレスアプリケーション作ってみてください！

Catoを導入後、管理者の方は日々の運用の中で設定の追加や変更を行っているのではないでしょうか。 しかし、ふと「今の設定のままほっておいて大丈夫なのか…」と不安になることはありませんか？ そんなときに役立つのが、Catoに標準搭載されている「Best Practiceチェック機能」です。 この機能を使えば、管理コンソール上の設定状況を自動で確認し、Best Practice（推奨設定）に沿っていない箇所を洗い出すことができます。 「この機能知ってはいるけど、英語だし量が多くて細かくチェックするのは大変…」という方もいるかもしれません。 今回は、この便利な機能の活用方法をわかりやすくご紹介します。 概要 Best Practice（Home > Best Practice）のページをみてみます。 ざっと全体をみると、現時点では以下のカテゴリで設定状況を確認しているようです。 項番 項目名 確認範囲 １ Internet Firewall Internet Firewall ２ Application Control App ＆ Data Inline（App Control Rule） ３ Data loss Prevention App ＆ Data Inline（Data Control Rule） ４ WAN Firewall WAN Firewall ５ Remote Port Forwarding Remote Port Forwarding ６ Threat Prevention IPS,DNS Protection,Anti-Malware ７ Account Level Security Settings セキュリティ機能全般 ８ TLS Inspection TLS Inspection ９ Access モバイルユーザ関連設定全般 10 Network Rules Network Rules 11 Account level Network Settings ネットワーク機能全般 12 Resiliency ＆ Recovery 機能全般(耐障害性・復旧の観点で確認) さらに、各カテゴリ内のチェック項目毎にImpactとStatusが表示されているのがわかります。 Statusは、Best Practiceと実際の設定の比較結果となっており、「Passed(合格)」「Fail(不合格)」のどちらかで判定されます。Impactは影響度を表しており「High(高)」「Midium(中)」「Low(低)」で判定されます。   また、キラキラマーク(✨)がついているチェック項目があります。 これらは、AI駆動型システムにより判定している項目で、例えばInternet Firewallの場合「テストルールが残っていないか？」や「期限切れのルールが残っていないか？」などといった確認をしてくれているようです。 Catoは近年AIの活用に力を入れていますが、この機能はその1つです。   画面上部をみると、各チェック項目を確認した結果が直感でわかるような表示になっています。 Score： 現時点(2025年8月)でチェック項目数は69項目のようです。 弊社の検証環境では69項目中48項目はPass(合格)しており、スコアが83％であることがわかります。 Status： 「All」「Passed(合格)」「Fail(不合格)」から選択ができ、デフォルトでは「All」になっています。 ここまでの情報から、チェックを行う際は画面上部のStatusでFail(不合格)を選択し、表示された各チェック項目のうちImpactが「High(高)」のものから優先的にチェックをしていく方法がよさそうです。 活用例 それにしても量が多いので、ここからは私が個人的に確認することをお勧めしたい項目をピックアップしてご紹介します。 項目は以下の4つです。 Internet Firewall TLS Inspection Network Rules Resiliency ＆ Recovery 特に Resiliency ＆ Recoveryは確認必須 です！ 他にも、Network RulesやInternet Firewallはルール数が多く管理が煩雑になりがちですし、TLS Inspectionは「どんな設定をしたらいいのかわからない」というお声をよくいただきます。 今回はこれらの項目での活用方法を5つご紹介します。 活用例① Internet Firewall セキュリティ強化 セキュリティ強化の観点では、以下の項目のうちImpactが「High(高)」に分類されているものは確認必須です。 Name 説明 Block Risky Categories リスクの高いカテゴリをBlockする設定となっているかを確認します Block/Prompt Suspicious Categories 不審な行動や特徴を示すウェブサイトやコンテンツをBlockする設定となっているかを確認します Block Risky Applications リスクの高いアプリケーションをBlockする設定となっているかを確認します Block Risky Services リスクの高いネットワークサービスまたはプロトコルをBlockする設定となっているかを確認します   ルールの棚卸 棚卸の観点では、AI駆動型システムを利用した項目が活躍します。 Name 説明 Review Temporary Rule 一時的なルールを検出します。 Review Testing Rule テスト用ルールを検出します。 Review Expired Rule 有効期限が切れたルールを検出します。 Review Rules with Future Expiration Date 有効期限が近いルールを検出します。 Review Contradicting Rules 条件は同じですがアクションが異なる矛盾したルールを検出します。 Unused Rules 使用されていないルールを検出します。 活用例② TLS Inspection 設定アシスト 「何をInspect(検査)して何をBypass(検査をスキップ)すべきかわらない」といった場合はこの項目を参考にします。 Name 説明 Bypass OSes and Categories Bypassすべき対象をBypassする設定になっているかを確認します Inspect Recommended Destinations Inspectすべき対象がInspectする設定になっているかを確認します 活用例③ Network Rules 耐障害性の向上 ” NAT ”や” Route Via ”の設定を行う場合、可用性や耐障害性の観点で以下の3つの項目は確認必須です。 Name 説明 Define Multiple IP Addresses for NAT Internet Rules 複数の出口IPアドレスを指定する設定になっているかを確認します。 （単一出口IPアドレスの指定は、耐障害性のBest Practiceに準拠していません。） Define Multiple PoP Locations for Egress Rules 複数のPoPロケーションを指定する設定になっているかを確認します。 （単一PoPロケーションの指定は、耐障害性のBest Practiceに準拠していません。） Define Specific Source or App/Category for Internet Egress Rules SourceやApp/Categoryで「Any」が設定されて いない かを確認します。 （「Any」の指定は、ネットワークのベストプラクティスに準拠していません。） 活用例④ Resiliency ＆ Recovery レジリエンスの向上 これらの項目はすべてのお客様に必ずご確認いただきたい項目です。 Name 説明 WAN Recovery Advanced Configuration is enabled WAN Recovery(※1)が有効になっていることを確認します。 Off Cloud Traffic Enabled for at Least One Socket WAN Interface WAN Recovery用にOff-Cloudトラフィック(※2)が有効化されたWANインターフェイスが少なくとも1つ設定されていることを確認します。 Internet Recovery is enabled for all Always-on Users Always-onユーザーに対してInternet Recovery(※3)が有効化されていることを確認します。 (※1)WAN Recovery：Cato Cloudとの接続に問題が発生した際に、Socketサイト間でインターネット経由のVPNトンネルを使用してWANトラフィックの接続性を保持します。この機能は、すべてのSocketサイトでデフォルトで有効になっています。 (※2)Off-Cloud：Off-Cloudトラフィックは、Cato Cloudを経由せずに、Socket間で直接インターネット経由のDTLSトンネルを使用して送信されるトラフィックです。 (※3)Internet Recovery：Always-onポリシーが有効になっているユーザーがCato Cloudに接続できない場合、インターネットトラフィックの復旧をサポートする機能です。 対処方法 説明不要と思いますが念のため。これらのチェック項目をチェックし、設定をBest Practiceに沿うように修正したい場合の対処方法をご紹介します。 例えば、弊社の検証環境ではテストルールが多数設定されておりますので、活用例①「 ルールの棚卸」の観点でチェック項目をチェックし、不要なテストルールを削除てみます。 今回はテストルールが6つ設定されておりました。 このうち、「Captive Portal Test」は先日検証を終えた不要なルールですので削除します。 この時「Go to Intenet Firewall」をクリックすると、ワンクリックでIntenet Firewallの設定ページに飛ぶことができました。これは地味に便利な機能だなと感じました。あとは通常通り対象ルールを削除するだけなので手順は省略します。 新機能の紹介　- Best Practice Catalog – 最近、Best Practice Catalog（Resources > Best Practice Catalog）という新機能がリリースされました。 この機能を利用すると、カテゴリ全体や個別のチェック項目を有効/無効にすることができます。 例えば、カテゴリの中には「Remote Port Forwarding」がありましたが、「Remote Port Forwarding」の機能は使っていないといった場合です。この場合は、「Remote Port Forwarding」のカテゴリを無効にすることで、Best Practiceページのカテゴリ「Remote Port Forwarding」が削除されます。   また「Intenet Firewall」カテゴリ内のチェック項目「Service Telnet」は、暗号化がされないため傍受のリスクがありBlockが推奨されていますが、業務利用でBlockができないといった場合です。 この場合は、チェック項目「Service Telnet」を無効にすることで、Best Practiceのページから削除することができます。 このように、各企業様のポリシーに合わせて有効/無効化させることで、Best Practiceのページは格段に見やすくなります。 まとめ 以下の手順でチェックを行うとチェックのハードルが格段に下がります。 Best Practice Catalog（Resources > Best Practice Catalog）で不要なカテゴリを無効化 Best Practice（Home > Best Practice）画面上部のStatusで「Fail(不合格)」を選択し、Best Practiceに準拠していない項目のみを表示 表示された項目のうちImpactが「High(高)」のものや、本記事の必須項目を優先的にチェック おわりに 今回は「Best Practiceチェック機能」をご紹介しました。 推奨設定に沿った構成ができているかどうかを確認することは、非常に重要です。「Best Practiceチェック機能」を活用することで、設定の不備を発見することが可能です。 さらに弊社では、セキュリティ・アーキテクト・コストの3つの観点からBest Practiceに基づき、現状の設定内容を確認し、報告書を作成する「設定診断サービス」をご提供しております。 設定に不安がある方や、第三者の視点での確認をご希望の方は、ぜひ「設定診断サービス」のご利用をご検討ください！

こんにちは！SCSKの髙橋です🌸 この記事では、AWS Summit Japan 2025に参加して得た知見をご紹介します。 AWS Summitについて ご存じの方が多いと思いますが、AWS SummitはAWSが開催する情報交換や事例紹介のためのイベントで、2025は幕張メッセで開催されました。 まじめな技術要素の展示以外にも、企業がおもしろいイベントを企画していたり（くじ引きとか、VR体験会のようなものも見ました） セッションがあらかた終わったあと、夕方以降にはお楽しみイベントがあったりします。 クイズ大会はエンジニア vs Quiz Knockの戦いがなかなか熱い展開でしたね。去年より規模が大きくなっていました！来年も楽しみです。 早押しクイズ大会の様子 また、たくさん資格を取ると表彰式で拍手がもらえるようです。 （SCSK社員もたくさん表彰されていました！） あっ！弊社 AWS Security Incident Response を活用したインシデント対応 今回私が聴講したセッションの中で、持って帰りたいと思ったのはこの話題です。 端的に言うと2024年12月のre:Inventでに発表された比較的新しいサービスの紹介なのですが、（全然知らなかった・・・） AWS Security Incident Response – AWS その前段の話が大変共感を呼ぶ内容でしたので、有効活用できる場面があるのではと感じました。 従来のインシデント対応における課題 まず、セッションの中で紹介されていた、従来のインシデント対応での課題（つまり、AWS Security Incident Responseで解決できそうな課題）について触れさせてください。 ざっとまとめると以下のような内容でした。現場によっては回避できている課題もあるとは思いますが、どれもなんとなく聞いたことのある話です。 コミュニケーション インシデントが起きても誰に報告していいかわからない、誰が作業の承認をできるのかわからない、など コミュニケーションがボトルネックになってしまう状況があるという課題です。 アラートのトリアージ 全てのアラートをしっかり確認する時間も人員もなく、対応が必要なアラートの見極めも難しいという課題です。 ツールとメカニズム 何度も同じアラートが起きていても、アラート発生時に過去の対応をチェックするツールが無く、 同じインシデント対応を繰り返してしまうという課題です。 本題から逸れるので割愛しますが、このあとも、セキュリティ担当者の84%がストレスや疲労を抱えている、といった生々しい話が続きました。 AWSが課題をどう解決してくれるのか そこで、AWS Security Incident Responseが、 お客様のセキュリティインシデントのより早く効率的な 準備、対応、復旧 を支援します。 とのことです。 具体的な例がないとわかりづらいですね。 アラートの監視と調査を自動化し、必要な時だけ通知してくれる インシデントの対応メンバーをあらかじめ登録・管理できる AWSのCirtチームから24/7の支援を受けられる メインの機能としては上記のような部分ということです。 紹介されていた事例として、例えばS3バケットに大量のデータ削除などがあった場合、 GuardDutyで検知した内容をEventBridgeでAWS Security Incident Responseに連携することができます。 自動的にAWS Security Incident Responseがインシデントの内容をトリアージし、対処が必要と判断した場合にケースを作成します。 このケースは自分で作成することもできます。 インシデントの作成も、AWS側だけでなく、自分からできます。 予め登録しておいた連絡先に通知が飛び、対応が始まります。 AWSのCirtチームに助けてほしい場合は、ボタン一つで切り替えることができるそうです。 これら全てがコンソールで操作でき、メンバーとのやりとりもダッシュボード上で行えます。（チャット、ビデオ通話など） AWS Incident Detection and Response との違い そういえば、似たようなサービスが無かったかな・・・と探してみたら、ありました。 AWS Incident Detection and Response とは AWS Incident Detection and Response は、対象となる AWS エンタープライズサポートのお客様に、障害の可能性を減らし、重要なワークロードの中断からの復旧を加速するための、プロアクティブなインシデント対応を提供します。 触ったことがないと、サービス同士の違いがいまいちわかりにくいです。名前も似ています。どう違うのかAIに聞いてみました。 Security Incident Response はセキュリティインシデントに特化しているので、データの侵害や不正アクセスへの対処がメインになりそうです 。 Incident Detection and Response の方が汎用的で日常的な使い方ができます。 また、 Security Incident Response  のほうが顧客が自立して動くのではなくAWS側が動いてくれるという要素が強くて、 インシデントの発見よりはその後の対応に重きを置いているというような感じです。（試験対策のようになってしまいましたね・・・） 気になるお値段 料金次第で、少し触って感触を確かめてみようかと思ったのですが・・・ AWS セキュリティインシデント対応の価格 料金は、登録されたアカウント全体の AWS の月間利用額に基づいており、 最低月額料金は 7,000 USD です。AWS の費用が増えると、階層によって異なるパーセンテージを支払うことになります。より高いレートは、新しい各階層の支出額にのみ適用されます。 階層 1:  AWS の月間利用額が最初の 0 USD から 125,000 USD の場合、 最低月額料金 7,000 USD 階層 2:  前の階層の合計 + 次の 125,000 USD から 250,000 USD までの支出の 5.0% 階層 3:  前の階層の合計 + 次の 250,000 USD から 500,000 USD までの支出の 3.5% 階層 4:  前の階層の合計 + 次の 500,000 USD から 1,000,000 USD までの支出の 1.5% 階層 5:  前の階層の合計 + 1,000,000 USD を超える支出の 0.5% 最低100万円ですか・・・エンジニア一人分ですかね？ちょっとだけ触って試してみるのは難しそうです🥺 （ Incident Detection and Response と価格帯は同じのようです） 体験版として触れる機会が無いか少し探してみたのですが、確認した範囲では見つかりませんでした。 最後に どれくらいスムーズに対応できるようになれるか、使ってみないとやはりなんとも言えそうにないですが、 セキュリティインシデント対応のフローがあまり定まっていないシステムだったら、導入することでかなり考えることが少なくなる気がします。 夜中に叩き起こされている皆さんが、少しでも安眠できるようにというのと、対応後の管理もお任せできるので、あとから「これってどういう対応したんだっけ？」というのも探しやすくなるみたいです。 ちなみに、ご紹介したセッションのオンデマンド配信は2025/7/11までと聞いていましたが、なぜか2025/7/28現在も利用可能です。 いつまで公開されているかわかりませんが、リンクを置いておきます。 AWS Security Incident Response を活用したインシデント対応

本記事は 夏休みクラウド自由研究2025 8/4付の記事です 。 こんにちは！Catoクラウド担当の中川です。 夏休みクラウド自由研究企画にて、Catoクラウド技術者がこれから投稿を開始しますが、本記事が最初の記事になります！ 早速ながら、この記事ではCatoの Captive Portal という機能をご紹介していきます。 Captive Portalとは Captive Portalとは、 利用者がインターネットにアクセスする前に、利用規約や制限等に対して同意を求める画面を表示させてからインターネット環境を提供する仕組みです。 一般的にゲスト用Wi-Fiを提供する際に利用されます。 例えば空港やホテルのお客様、オフィスへの来訪者用に提供されるようなネットワークです。 こういった、社内ネットワークへはアクセスさせず、インターネット環境のみを提供したい場合に利用します。 設定方法 今回は、 Socket配下にゲストWi-Fi用のセグメントを作成することを想定し、設定していきたいと思います！ CatoのCaptive Portalの設定方法は非常に簡単で、CMAにてSecurity＞Internet FirewallからCaptive Portal用のルールを作成します。 SourceでゲストWi-Fi用に用意したネットワークセグメントを選択して、ActionsでCaptive Portalを選択するだけです。 今回はSite「検証環境」の「LAN 02」セグメントをゲスト用Wi-Fiとして検証しました。 なお、ゲストはCaptive Portalでの接続後、他のユーザ同様にInternet Firewallのルールが適用されます。すべてのユーザでギャンブルカテゴリをブロックしているのであれば、ゲストも当然ブロックされることになります。   利用者の画面イメージ 実際にWi-Fiに接続し、インターネット接続を試してみると、以下のようなCatoへの接続を確認するCaptive Portalの画面になります。 Connectのボタンを押すと、Cato社のホームページへと遷移しました。 ＜Captive Portal画面＞ ↓ ＜Connect押下後、Cato社ホームページへ＞ 上画像はデフォルト設定でかなり簡素に感じたかと思いますが、この画面の設定はAccount ＞ Captive Portalから変更可能です。 デフォルト設定は下記のようになっており、7か所がカスタマイズできます。 会社ロゴ ロゴの背景カラー 接続ボタンのカラーとテキスト内容 ゲストWi-Fi利用の同意を求める文面を入れるか メールアドレスの入力を求めるか（チェックすると、入力が必須になります） セッション有効期間 接続ボタン押下後のリダイレクトURL 次に、以下のようにカスタマイズしてみました。 ロゴをSCSKの会社ロゴに 接続ボタンを、SCSKの会社カラーにし「Guest Wi-Fiに接続する」の表記に ゲストWi-Fiに接続するにあたっての同意を求める文面を追記 メールアドレスの入力を必須に リダイレクト先をSCSKのホームページに ↓ すると、当然ではありますが、このような画面に変更されました。 ※事前確認の文面で、数字の箇条書きを設定している箇所がありますが反映されませんでした。。 メールアドレスを入力しボタンを押下すると、設定した通り、今度はSCSKのホームページへとアクセスされました。 ＜Captive Portal画面＞ ↓ ＜今度はSCSKホームページへ遷移＞ イベントの見え方 CMAのHome ＞ Eventsでイベントログを確認してみました。 特徴としては、ActionがCaptive Portalとなっていたことと、入力を必須としたメールアドレスが”Guest User”としてログに記録されていたことです。 何かあった際に調査できるよう、メールアドレスの入力は必須としておくのが良いかもしれません。 ※なお、有効にしていない場合にも”Guest User”のフィールドはありましたが、空欄となっていました。 考慮ポイント ここでは検証してみて気づいた、Captive Portalの利用をするにあたって考慮すべきポイントを2つ記載します。 通信制御 特別な設定をしていない場合、他のSite配下のユーザと同様に、Catoクラウドを介して他拠点のリソース / インターネットへ接続可能です。ゲスト用Wi-Fiの用途からすると、少なくとも他拠点のリソースへは接続できないようにすべきです。 そのため、Cato社はゲスト用Wi-FiのセグメントはInternet Onlyの設定を推奨しています。名前の通りの設定で、この設定を有効にしたセグメントはインターネットへの接続しかできなくなります。 設定箇所は、Networks > 対象Site ＞ Site Configuration ＞ 対象のセグメントで、以下のチェックボックスです。 通信帯域 ゲスト用Wi-Fiも当然ながら、Socketを経由してCatoクラウドへ接続します。 例えば、ゲストとして来訪された方が大容量ファイルをダウンロードなどした場合には、拠点の帯域ひっ迫を引き起こしてしまう可能性があります。 余裕を持った帯域ライセンスでご契約されている場合には問題ないですが、拠点内の社員のみの利用を想定して帯域を契約していた場合には注意が必要です。 おわりに Captive Portalのご紹介いかがでしたでしょうか。 多くのお客様に使われている機能ではないですが、ここ最近お客様よりご相談いただくことがありましたので、今回ご紹介させていただきました。 設定値は少なく複雑な内容ではないので、ゲスト用Wi-Fiの設置をご検討されているお客様はCaptive Portalでの設定をご検討いただければと思います。 ご覧いただきありがとうございました。 この後にもCato担当メンバの投稿が続きますので、ぜひお楽しみください！

本記事は 夏休みクラウド自由研究2025 8/3付の記事です 。 こんにちは！SCSK小寺です 先日行われたInterop Tokyo 2025にて、「Zabbix Cloud登場！Zabbixのプロが実際に使ってみた」と題して、 ショートセミナーに登壇させていただきました。本ブログではセミナーの発表資料を公開いたします。 こちらからぜひダウンロードいただければと存じます。 Download Now! 本ブログでは、発表内容から抜粋してご紹介いたします。 Zabbix Cloud とは Zabbix Cloudは2024年10月にZabbixからリリースされた新サービスです。 Zabbix Cloudのアカウント作成後、マネジメントコンソールからZabbixServerを作成/起動することができます。 インスタンス作成に接続用のURLがは行されますので、ブラウザからアクセスをすれば、Zabbixの監視設定を始めることができます。   Zabbix Cloud のメリット 必要に応じて再スケール可能 なんでも監視可能 常に最新状態を維持（自動アップデート） オンデマンドのZabbix（数クリックで構築完了） 24/365の稼働時間 パフォーマンスの最大化（チューニング済み） 当社では、３のメリットが大きいと考え、重点的に説明をいたしました。   Zabbix Cloud のデメリット OS領域へのアクセスが許可されていない 監視通信トラフィックがInternetを通る 国内リージョンで利用できない ドル建てクレジット請求 サポート体制が整っていない Zabbix Cloudはリリースされたばかりで、日本での販売＆サポートは準備が整っていない状況です。 10月に開催されるZabbix Summitにていろいろと情報が公開されることを期待して、準備を進めてまいります。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

本記事は 夏休みクラウド自由研究2025 8/2付の記事です 。 こんにちは。SCSKの上田です。 普段はZabbixの記事を書いていますが、 夏休みクラウド自由研究 ということでAWSの記事を書いています。 今回は、AWS IAMを使って様々な制限をかけることを研究してみました。 はじめに AWSを安全かつ効率的に運用する上で、 IAM（Identity and Access Management） は重要なサービスです。適切なIAMポリシーを設定することで、ユーザーやAWSサービスがアクセスできるリソースや実行できる操作を細かく制御し、セキュリティを強化し、運用上のミスを防ぐことができます。 しかし、 「IAMポリシーをどう書けばいいのか」「IAMポリシーでどんな制限を設定できるのか」 と悩む方もいらっしゃると思います。 この記事では、具体的なユースケースを例に挙げながら、IAMポリシーを活用して「こんな制限をかけられるんだ！」と感じていただけるような4つの実装例をご紹介します。   いろいろな制限 ここから、IAMの制限実装例を4つご紹介します。 ①特定のIPアドレスからのアクセス制限 AWSにアクセスできる IPアドレス を制限します。 ユースケース この設定により、社内NWやプロキシを経由していないユーザーからのアクセスをブロックできるので、 不正なNWからのアクセスをブロックする ことができます。 実装例 指定したIPアドレス以外からのアクセスの場合、すべての行動を禁止するポリシー文を実装します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": "**.**.**.**/**" //グローバルIPアドレスを設定 } } } ] } 補足 実際に設定する際は、”aws:SourceIp”の部分を、お使いのIPアドレスに変更してください。AWSにアクセスするIPアドレスを見ているので、 プライベートIPアドレスではなくグローバルIPアドレス を記入する必要があります。   ②特定のアクションに対するMFA強制 特定のアクションを実行する際に、 MFAを必須 にします。 ユースケース 特定の操作（例えば、リソースの削除）を行う際に、多要素認証（MFA）を必須にできるので、 アカウント乗っ取り時の被害拡大を防ぐ ことができます。 実装例 MFAが設定されていないアカウントからのEC2インスタンスの削除を禁止するポリシー文を実装します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ec2:TerminateInstances" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" //ここでMFAを強制 } } } ] } 補足 全ての行動をMFA強制すると、 MFAを登録する操作すらできなくなってしまう ので注意が必要です。   ③特定の期間のみアクセス許可 AWSに アクセスできる期間 を制限します。 ユースケース 本番環境へのアクセスを作業実施期間に制限することで、プロジェクト終了後にアクセスできなくさせることができます。 このような場合、プロジェクト終了後にアカウントを削除することが一般的ですが、 オペミスによる削除忘れを防止 することが可能です。 実装例 AWSへのアクセスを、JSTで「2025年7月31日18:00まで」の期間に制限するポリシー文を実装します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "DateGreaterThan": { "aws:CurrentTime": "2025-07-31T09:00:00Z" //JSTで2025年7月31日18時までに制限 } } } ] } 補足 IAMポリシーの時刻は UTC時刻表期 のため、注意が必要です。   ④特定の文字列から始まるIAMユーザー名のみアクセスを許可 特定のアクションを実行できるユーザーを IAMユーザー名 によって制限します。 ユースケース 複数のチームで同じAWSアカウントを共有している場合、特定のチームに属するユーザーのみが特定の操作やリソースにアクセスできるようする必要があります。そのような場合、チームごとに適切な権限を付与したIAMロールを作成するのが一般的だと思いますが、ユーザー名に基づくポリシー文を入れておくことで、 オペミスによる意図しない権限付与を防ぐ ことができるようになります。 実装例 「ope」で始まるIAMユーザーのみ、EC2の削除ができるポリシー文を作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ec2:TerminateInstances" ], "Resource": "*", "Condition": { "StringNotLike": { "aws:username": "ope*" //ユーザー名を制限 } } } ] } 補足 このポリシー文を入れておくことで、「ope」から始まるユーザー以外のEC2削除をブロックできます。使用する場合は、 チーム名をIAMユーザー名に付与する（ope、dev、admなど）という運用ルール が必要になります。   最後に 今回は、IAMポリシーを使って色々な制限方法を実装してみました。IAMポリシーを上手く活用することで、様々な条件での制限や、オペミスを防止する制限を設定することが可能です。 AWSを使用するうえで権限管理は非常に重要なので、今回ご紹介した方法を参考に、安全な運用をご検討ください。 AWSの運用方法や実装方法にお困りの点がございましたら、是非弊社までお問い合わせください。 最後まで読んでいただき、ありがとうございました。

本記事は 夏休みクラウド自由研究2025 8/1付の記事です 。 こんにちは、広野です。 ちょうど書いていた記事が夏休みシーズンだったので、会社の自由研究扱いにしてしまいました。w さて。 2025 年 3 月に AWS Amplify Hosting でホストされたサイトに AWS WAF の Web ACL をアタッチすることができるようになりました。 AWS Amplify Hosting announces Web Application Firewall Protection in general availability - AWS Discover more about what's new at AWS with AWS Amplify Hosting announces Web Application Firewall Protection in general ... aws.amazon.com 少々使ってみたい要件があったので、やってみて気付いた点を書き残しておこうと思います。 やりたいこと あえて簡単にひとことで言うと、以下をやりたかったです。 指定した IPv4 アドレス (またはサブネット) からのみサイトへのアクセスを許可したい。 結論から言うと、特定の条件が引っかかって実現できなかったのですが。 従来のソリューションとの比較 冒頭の新機能がリリースされるまでは、以下のソリューションがありました。 AWS Amplify に Amazon CloudFront をかぶせて、AWS WAF をアタッチします。 Amplify Hosting で Wrapping された Amazon CloudFront には AWS WAF をアタッチできなかったので、二重に Amazon CloudFront が存在します。 もう 1 つは、AWS Amplify を使用せず、Amazon CloudFront を組み込んだアプリ基盤を構築し、AWS WAF をアタッチします。 私の過去のブログで紹介した方法です。 AWS Amplify Console と同等の CI/CD 環境を AWS Code サービスシリーズでつくる [AWS CloudFormation でかんたん構築!!] AWS Amplify Console は神サービスなのですが、カスタマイズ性は低いです。Amplify がマッチしない要件に対応するため、同等の機能を AWS Code サービスシリーズで作ってみました。 blog.usize-tech.com 2022.06.16   新しいソリューションでは、以下の図のように AWS Amplify Hosting で Wrapping された Amazon CloudFront に直接 AWS WAF をアタッチできるようになったわけです。おそらく、多くの要件はこの構成を活用して実現できると思います。 ソース IP アドレス制限をかけるときの注意 実は、ソース IP アドレス制限をかけるときには注意事項があります。 まず、IP アドレスには IPv4 と IPv6 があります。ソース IP アドレス制限をかけるときには IPv4 で設定するのが一般的かつ現実的です。IPv6 でも設定はできるのですが、IPv6 はソース IP アドレスが頻繁に変わることがあり、レンジ設定も難しく、実質制御できないと思った方がよいです。 そのため、AWS Amplify Hosting のサイトに IPv4 のみでアクセスできるようにしたいのですが、条件によってはそれが できません。 仕様上、AWS Amplify は IPv4 と IPv6 を同時に利用可能とする デュアルスタック をサポートしており、いろいろと確認したところ カスタムドメインを使用していると IPv4 通信のみを利用可能とする構成がサポートされていません でした。 IPv6 をサポートする AWS サービス - Amazon Virtual Private Cloud コンピュータは IPv4 と IPv6 を使用して通信します。AWS サービスは、デュアルスタックと IPv6-only 設定をサポートしています。一部のサービスはプライベートエンドポイント経由で IPv6 アクセスを提供しています。 docs.aws.amazon.com   「いや、うちの会社のインターネットは IPv4 しか使ってないから問題ないよ」 このケースであれば問題ありません。素直に最初から最後まで IPv4 通信をしてきてくれますので。 ですが、世の中には IPoE なる IPv6 ネイティブの通信が既に普及してきており、IPoE ユーザーは IPv4 網を経由せずダイレクトに IPv6 の AWS Amplify Hosting サイトに到達してしまいます。このとき、ソース IP アドレスは IPv6 アドレスになり、Web ACL で 100% 拒否されてしまうのです。つまり、IPoE ユーザーは全くサイトにアクセスできないということです。 この通信のイメージは以下です。   もしも AWS Amplify Hosting が IPv6 を無効にできるなら 、以下の図のように Web ACL が成り立ちます。 本当はこうしたいのです。※できません。 結論 結局、IPv4 ベースのソース IP アドレス制限は AWS Amplify + AWS WAF では完全にはできません。アクセス元が必ず IPv4 で通信してきてくれるなら、という条件付きで実現可能です。 純粋 Amazon CloudFront であれば IPv6 を無効にできるので、完全に実現できるのは従来のソリューションのままです。 Amazon Route 53 で別のレコードをかぶせればいけるか？とも思ったのですが、難しいと思いました。いずれにしてももう少し手を加えればできる方法はあるのかもしれません。 AWS Amplify に限らず、他の AWS サービスでもデュアルスタックのみしかサポートしていないリソースに AWS WAF をアタッチする場合は同じことが発生します。 補足すると、IPv4 over IPv6 を経由したソース IPv4 アドレスは一般的には別契約の他者と共有されているので、それだけを完全に信用したソース IP アドレス制限は危険です。ただし、プロバイダーのオプションで専用ソース IPv4 アドレスを提供してくれる IPoE 接続サービスもあるので、その場合は問題ないと思います。ネイティブな IPv4 でも、クラウドのセキュリティプロキシサービスを経由しているとソース IP アドレスを別契約の他者と共有するケースがあるので、その場合も信用はできません。もはやソース IP アドレス安全神話は崩れてきているなぁと思っています。 おまけ AWS CloudFormation テンプレート AWS Amplify Hosting に AWS WAF をアタッチする AWS CloudFormation テンプレートを参考までに貼り付けます。 今回検証した構成なので実用的ではありませんが、AWS CloudFormation だとこう書けばデプロイできるというのがわかるぐらいのものと思っていただければ。 AWS Amplify のリージョンに関わらず、バージニア北部リージョンでデプロイする必要があります。AWS Amplify Hosting アプリケーションの ARN がインプットとして必要です。テンプレート内に記入している IP アドレスは例のために書いたもので、実際には有り得ない値です。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a WAF web acl for Amplify hosting. This template must be deployed in us-east-1 region only. # ------------------------------------------------------------# # 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 AmplifyArn: Type: String Description: The target Amplify ARN. Default: arn:aws:amplify:xxxxxxxxxxxx:999999999999:apps/xxxxxxxxxxxx AllowedPattern: ^arn:aws:amplify:.+:\d{12}:apps\/.+$ 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: "192.168.0.0/24,8.8.8.8/32" LogRetentionDays: Type: Number Description: The retention period (days) for AWS WAF logs. Enter an integer between 35 to 540. Default: 400 MaxValue: 540 MinValue: 35 Resources: # ------------------------------------------------------------# # WAF Web Acl for Amplify # ------------------------------------------------------------# WebAclAmplify: Type: AWS::WAFv2::WebACL Properties: Name: !Sub ${SystemName}-${SubName}-amplify Description: !Sub WAFv2 WebAcl for Amplify ${SystemName}-${SubName} Scope: CLOUDFRONT DefaultAction: Block: {} Rules: - Name: !Sub CustomRule-IpWhiteList-${SystemName}-${SubName} Action: Allow: {} Priority: 0 Statement: IPSetReferenceStatement: Arn: !GetAtt Ipv4WhiteList.Arn VisibilityConfig: CloudWatchMetricsEnabled: true MetricName: !Sub CustomRule-IpWhiteList-${SystemName}-${SubName} SampledRequestsEnabled: true VisibilityConfig: CloudWatchMetricsEnabled: true MetricName: !Sub WebAcl-${SystemName}-${SubName} SampledRequestsEnabled: true Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} DependsOn: - Ipv4WhiteList Ipv4WhiteList: Type: AWS::WAFv2::IPSet Properties: Name: !Sub Ipv4WhiteList-${SystemName}-${SubName} Description: WAF v2 IPv4 white list for the IP-based restricted access IPAddressVersion: IPV4 Addresses: !Ref SourceIpv4RangeList Scope: CLOUDFRONT Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} WebAclAssociationAmplify: Type: AWS::WAFv2::WebACLAssociation Properties: ResourceArn: !Ref AmplifyArn WebACLArn: !GetAtt WebAclAmplify.Arn DependsOn: - WebAclAmplify WebAclLoggingConfigurationAmplify: Type: AWS::WAFv2::LoggingConfiguration Properties: ResourceArn: !GetAtt WebAclAmplify.Arn LogDestinationConfigs: - !GetAtt S3BucketWafLogs.Arn LoggingFilter: DefaultBehavior: KEEP Filters: - Behavior: KEEP Conditions: - ActionCondition: Action: BLOCK Requirement: MEETS_ANY DependsOn: - S3BucketWafLogs - WebAclAmplify # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketWafLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub aws-waf-logs-${SystemName}-${SubName} 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} まとめ いかがでしたでしょうか。 期待していた AWS Amplify Hosting への AWS WAF アタッチ機能でしたが、機能しないケースもあるという紹介でした。 本記事が皆様のお役に立てれば幸いです。

SCSKは2025年7月23日、生成AIサービスであるInfoWeave（インフォウィーヴ）にAIエージェント機能を新たに追加し、提供開始いたしました。 プレスリリース SCSKのAI活用基盤「InfoWeave」が進化、ブラウザ操作を自動化するAIエージェント機能を搭載 このサービスはAIエージェントを利用して様々な業務を自動化・効率化できるサービスで、 早く・安く・安全に 利用することができます。 マルチエージェント構成となっており、ブラウザ操作をはじめ、様々なシーンで活用できるものとなっています。 この記事では、開発の背景や利用シーンなどをわかりやすく説明します。   AIエージェント AIエージェントとは？ AIエージェントとは何でしょうか？ いろいろな文脈で語られることがあり多様な意味を持ちますが、一般的には以下のように説明されています。 人工知能 (AI) エージェントは、環境と対話し、データを収集し、そのデータを使用して 自己決定タスクを実行して、事前に決められた目標を達成する ためのソフトウェアプログラムです。 目標は人間が設定しますが、その 目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択 します。例えば、顧客の問い合わせを解決したいコンタクトセンターの AI エージェントを考えてみましょう。 エージェントは自動的に顧客にさまざまな質問をし、内部文書で情報を調べ、回答でソリューションを提示します。顧客の応答に基づいて、クエリ自体を解決できるのか、それとも人間に渡すのかを判断します。 引用：https://aws.amazon.com/jp/what-is/ai-agents/ LLM、例えばChatGPTを使って調査を行う場合、プロンプトで指示を行う人間が事前にタスクを分解してあげて、質問する必要があります。 一方でAIエージェントの場合は、これらを人間の代わりに整理し、目標を達成することを主眼に実行されます。 依然として主体は人間ですが、よりAIに任せられる領域が増えてきたとも解釈できますね。   AIエージェントの普及 2024年7月のGartnerハイプサイクルでは、AIエージェントは一番左の「 黎明期 」に位置していました。 2025年8月時点では、さらに右側へとシフトし、期待値が高まっているフェーズに入っている考えられます。 *2025年版は発表されていないため、2024年版を引用しています。 参考：https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20240910-genai-hc   また、Googleでの検索クエリを見ることができるGoogle Trendsで「 AIエージェント 」のキーワードで調査したところ、ここ1年間で右肩上がりを続けています。   2024年7月には、InfoWeave RAGがリリースされました。 当時はPoCとしてのご利用が多くありましたが、2025年度に入りよりコア業務への活用が進んでいると感じています。 TechHarmony記事 かんたんRAG環境構築 S-Cred+ InfoWeaveをリリースしました AIエージェントも同様の流れを辿ると考えており、まずはPoCとして業務活用への試行、その後本格的に実際の業務に組み込んでいく動きになると思います。   InfoWeave AIエージェントとは？ InfoWeaveは、 S-Cred + （エス クレド プラス）プラットフォーム のオプションとして提供されている、生成AIサービスです。 自社のAWS環境に簡単にAIエージェント環境を構築できるサービスが、 InfoWeave AIエージェント になります。     「AIエージェントを自社環境に導入したいが、課題が多くて難しい」とお悩みの方におすすめのサービスです。 課題の例 1. 外部SaaSを利用するとセキュリティが不安、またカスタマイズもできないので社内AWS環境に構築したい 2. AIエージェント環境を構築できるITエンジニアがいない 3. ユースケースはあまり定まっていないため、利用しながら探したい InfoWeave AIエージェントの特徴 最短3日で利用開始可能 S-Cred+プラットフォームをご契約いただいていれば、最短3日で導入が可能です。 テンプレートをデプロイするだけでチャット画面やユーザー管理機能も作られるため、すぐに使い始めることができます。 通常社内でITエンジニアをアサインしてRAG環境を構築すると、設計・構築・テストなどで数ヶ月かかるため、比較するととても早く利用することができます。 マルチエージェント連携による⾼度な業務の⾃動化 ブラウザを操作するエージェントやAPI操作のエージェント、裏でPythonコードを書いてグラフ作成などを行うコードインタープリターエージェントなど、複数のAIエージェントが、Supervisorエージェントの配下で目的に応じて呼び出されます。 ユーザーはプロンプトで指示を出すだけなので、とてもシンプルです。 セキュアな環境での AI エージェント運⽤ 外部SaaSではなく、ユーザーのAWS環境にデプロイして利用することができます。そのため、自社のセキュリティポリシーに準拠した形での運用が可能です。 社外サービスを利用する際は、社内でSaaS利用におけるチェックシートの申請が必要な企業も多いかと思います。社内で利用できれば、そのような手続きを回避できるかもしれません。   画面イメージ いくつかサンプルの画面イメージをご紹介します。 *機能と画面は2025年8月上旬のものとなり、マイナーリリースにより変更となる場合があります   メイン画面 ユーザーが利用するメインの画面はこのようになっています。 ServiceCatalogによりデプロイされます。 AIエージェントを使った作業指示や履歴の表示、各種管理ができるようになっています。   AIエージェントへの作業指示 さて、実際にAIエージェントへ指示をしてみましょう。 作業指示画面で、プロンプトを入力します。 ここでは、稼働時間が少ないメンバーにRedmineでチケットをアサインする処理をエージェントにやってもらいます。 プロンプトには具体的な処理内容を記述しますが、勤怠システムやRedmineでどのボタンをクリックするかといった情報までは記載しません。 しばらくすると、作業結果が表示されます。 AI Robotさんの稼働時間が少ないことがわかり、Redmineのチケットが割り当てられました。 実際にRedmineを見ても、チケットがアサインされていることがわかります。   思考途中の状態も見ることができます。 メインとなるSupervisor Agentが、作業計画を立てるサブエージェント、結果を検証するサブエージェント、ブラウザ操作を行うサブエージェントなどへ指示を出し、処理をしています。   勤怠システムの画面構成を指示しなくても、情報を取得できました。 効果的に動作するようプロンプトを調整する必要がありますが、プロンプトのみで動作させることができます。   また、RPAと異なりある程度の画面レイアウト変更には柔軟に対応することができます。   管理画面 ユーザー画面とは別で、管理画面も用意されています。 ユーザーやグループの管理、利用状況の参照や共通プロンプトの設定などを行うことができます。     さいごに 今回は、InfoWeave AIエージェントのサービス開始にあたり、その概要をご紹介しました。   個人的には、2025年はまだAIエージェントの可能性を探っている方が多い状態だと考えています。 安全かつ効果的にAIエージェントを業務に取り入れるには、どのように利用すればよいのでしょうか。 実際に考えて使ってみるという用途に、InfoWeave AIエージェントは最適だと思います。もちろん、実業務への活用も可能です。 今後、利用できるモデルや機能など不定期でアップデートがされる予定です。   無料でのご相談やデモ環境の提供などを行っていますので、是非お問い合わせください。 InfoWeave AIエージェント紹介ページ AIエージェント構築ソリューション InfoWeave｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション

こんにちは、SCSKの坂木です。 先日、Zabbix7.4がリリースされました。本ブログでは、7.4の新機能を6つ紹介いたします。 What's new in Zabbix 7.4 Create new resource discovery workflows, visualize your data in new ways, enjoy the improved user experience and much mo... www.zabbix.com Zabbix7.4はポイントリリースのため、サポート期間が短くなっています。 本番利用する場合は8.0LTSがリリースされるまでお待ちいただく事をお勧めします。 ホストウィザード ウィザード形式でホストを作成 できるホストウィザードが追加されました。 対話形式で案内してくれるため、ユーザーが設定途中で迷うことがなく、初心者におすすめの機能となっております。 注意点として、Zabbix Serverとエージェント間の通信は 暗号化必須 となります（ウィザードに従って設定を進めると暗号化の設定がされ、別途暗号化の設定は不要です） データ収集 -> ホスト -> Host Wizardから利用可能です。（7.4では日本語表記は無く英語表記のみです） ウィザードの画面はこちらのようになっております。   アイテムカード アイテムカードは、ダッシュボードに新たに追加されたウィジェットの一種で、 1つのアイテムの詳細を表示可能 です。 表示可能なアイテムのデータは「メトリクス名」「最新データ」「トリガー」「データ型」「ホストインターフェース」「タイプ」「説明」「エラーテキスト」「ホストインベントリ」「タグ」の10種類が選択可能で、全て表示することも、任意のデータのみを表示することもできます。 こちらの画像は、すべて表示しています。 Zabbixのデフォルトのダッシュボードにねじ込んでみると、こんなかんじになります。   icmppingretry icmppingretryとは、リトライのオプションを追加したPing監視です。 これまでPing監視で利用していたicmppingは疎通の成功/失敗問わず指定回数実施していましたが、icmppingretryを使用することで Ping疎通がNGの場合のみ、再試行 することができます。 詳細はこちらのブログに記載しております。 Zabbix7.4新機能検証（icmppingretry編） Zabbixの7.4の新機能である「icmppingretry」について解説、検証いたします。 blog.usize-tech.com 2025.07.11   新しいトリガー履歴関数 アイテムの取得時間を評価するトリガー関数が3つ追加されました。 アイテム値の取得時間/間隔でトリガーを設定する場合に利用できます。 キー 概要 サポートされている型 firstclock(/host/key,sec<:time shift>) 定義された評価期間内の最も古い値のタイムスタンプ Float、Integer、String、Text、Log lastclock(/host/key,<#num<:time shift>>) 定義された評価期間内の N 番目に新しい値のタイムスタンプ Float、Integer、String、Text、Log logtimestamp(/host/key,<#num<:time shift>>) N 番目に新しいログ項目値のログメッセージのタイムスタンプ Log 詳細はこちらのサイトをご確認ください。 4 ヒストリ関数 www.zabbix.com   インラインフォームバリデーション テキストボックスの 入力値の構文エラーが分かる 、インラインフォームバリデーション機能が追加されました。 これまでは、ホストやアイテム等の作成時、追加ボタンを押すまでエラー出力がされませんでしたが、作成中に構文エラーが分かるようになりました。 地味ですけど、ありがたいです。。   ホストのプロトタイプの機能拡張 ホストのプロトタイプにて検出されたホストに対しても、ホストのプロトタイプを適用でき、 階層的にホストを検出できる ようになりました。 例えば、まずハイパーバイザーを検出するルールを動かし、次に、見つかったハイパーバイザー上で動作しているサーバ1-4を検出する、といった二段階の自動検出が実現できます。   まとめ 最後までお読みいただき、ありがとうございます。 本ブログでは「ホストウィザード」「アイテムカード」「icmppingretry」「新しいトリガー履歴関数」「インラインフォームバリデーション」「ホストのプロトタイプの機能拡張」の6つの新機能を紹介しました。 Zabbix7.4では他にも新機能が追加されているので、 こちら からご確認ください。   筆者の他のブログもよかったら見てやってください！ 【Zabbix】トリガーアクションでスクリプトを実行する方法 本ブログではZabbixのトリガーアクションで障害対応を自動化する方法を解説します。 今回はトリガーアクションの中でもスクリプトの実行方法について説明します。 blog.usize-tech.com 2025.06.10 Zabbixで複雑なログ監視を実装する方法-count関数編- Zabbixのcount関数を使った複雑な条件のログ監視を行う方法をご紹介します。ログ監視で、5分間で5回”ERROR”という文字列が含まれるといった条件はパッと作成できますか？さらには、5分間で連続で5回”ERROR”という文字列が含まれるといったように、「連続で」という条件がつくとさらに頭を悩ませるのではないでしょうか。そこで今回は、このような条件式を作成できるcount関数を用いたログ監視について紹介していきます。 blog.usize-tech.com 2025.05.07 Zabbixにセキュリティパッチは無い？Zabbixにおける脆弱性対応とマイナーバージョンアップの方法 Zabbixってセキュリティパッチあるの？いえ、ないのでバージョンアップで脆弱性に対応します。マイナーバージョンアップ方法も紹介します。 blog.usize-tech.com 2025.07.17