Catoクラウドに関するお問合せとして、「特定の拠点でどの端末が最も多く通信をしているのか？」や「拠点に負荷をかけている通信は何か？」といった質問をいただくことがあります。 これらの課題を解決できるダッシュボードツールとして、「App Analytics」というものがございます。この記事では、App Analyticsの特徴やその確認方法について紹介します！ 画⾯は2024年12⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 App Analyticsとは App Analyticsは、アカウント全体、特定のSite、または特定のユーザ単位で、アプリケーションの使用状況とトラフィックを可視化するツールであり、主に以下の特徴を持っています。 特徴その1：可視化と分析 ユーザやアプリケーション、Siteごとのトラフィック量をリアルタイムで表示することができます。 トラフィックの異常や傾向を容易に特定することが可能です。 特徴その2：柔軟なフィルタリング フィルタリング機能を用いて、注目したいデータをピンポイントで絞り込むことができます。 例えば、特定のユーザが利用する「Zoomアプリ」の利用状況といったピンポイントな情報であっても、フィルタリング機能を利用することで容易に確認することが可能です。 特徴その3：アプリケーションのリスク管理 App Analyticsに記録されるアプリケーションには、Cato独自の「リスクスコア」が付与されています。 このスコア（0～10）は、脆弱性のレベルを示しており、潜在的なリスクを迅速に把握することが可能です。 App Analyticsに表示される情報は、通常5分以内に更新されます。 一部のデータは最大30分ほどの遅延が発生する場合があります。 次の項目では、App Analyticsの基本的な見方についてご説明します！ App Analyticsの見方 App Analyticsの画面は、アカウント単位、Site単位、ユーザ単位で開くことができます。 それぞれCMA(Cato Management Application)から以下の流れで開くことができます。 アカウント：Home > App Analytics Site：Network > Sites > Siteを選択 > Application Analytics ユーザ：Access > Users > ユーザを選択 > Application Analytics フィルタリング機能により絞ることもできるのでお好みの方法でお開きください。 App Analyticsの表示説明 上記の手順でApp Analyticsを開くと以下の画面が表示されます。 ※画像はアカウント単位で開いたものです 主な表示内容については以下の表をご覧ください。 番号 名前 内容 ① Time range 表示される情報の期間を設定できます ※期間を最大90日間まで指定可能です ② Events filter bar フィルタリング機能です 絞りたい情報を入力することで表示される情報を絞ることができます ③ Top Users トラフィック使用量が多いユーザが表示されます ④ Top Applications トラフィック使用量の高いアプリケーションが表示されます ⑤ Top Sites トラフィック使用量の高いSiteが表示されます ※Siteにカーソルを合わせると、その名前、場所、および総帯域幅の使用量が表示されます ⑥ Analytics type tabs Analytics data table 表示されているタブ(Site、アプリケーション、ユーザ等)ごとのデータや分析結果が表示されます 「+」ボタンをクリックすることでより詳細な情報を確認することができます ⑥のAnalytics type tabsについて、表示されているタブの役割は以下をご覧ください。 ※アカウント単位、Site単位、ユーザ単位によっては表示されないタブもあります(以下表の表示対象を参照) 名前 内容 表示対象 Site アカウント内のすべてのSiteが表示されます 「+」からSite配下にいるすべてのユーザ情報が確認できます Site配下にいないリモートユーザが「Remote User」として表示されます アカウント Applications 時間範囲内で使用されたすべてのアプリケーションが表示されます 各アプリケーションのリスクスコアをが確認できます(０ ～ 10) ※Custom Applicationリスクスコアは表示されません 全て Categories 時間範囲内で使用されたすべてのカテゴリが表示されます 「+」からカテゴリ内の各アプリケーションが表示されます 全て Users 時間範囲内にCatoに接続しているすべてのユーザが表示されます アカウント、Site Users/Hosts 時間範囲内にアカウントに接続しているすべてのユーザーとホストが表示されます アカウント、Site Sources 時間範囲内にセッションを開始したすべての送信元IPアドレスが表示されます 全て Destinations 時間範囲内にアクセスされたすべての宛先ドメイン/IPアドレスが表示されます 全て Connections 時間範囲内にアカウントに接続しているすべてのユーザーとホストが表示されます 「+」からそのユーザー/ホストが使用する各アプリのトラフィック・フローの宛先と方向が確認できます 全て   App Analyticsの活用例 App Analyticsの表示内容を理解したら、実際にどう役立てることができるのかを以下２パターン別の利用例を用いてご紹介します。 パターン１　拠点に対して 通信量の多いアプリケーションやホストを一目で 特定 はじめに、調べたい拠点(Site)のApp Analyticsを開きましょう。 Network > Sites > Siteを選択 > Application Analytics 表示されたTop Applicationsから使用量の多いアプリケーションを、またTop Users/Hostsから、通信の多い送信元ホストを確認しましょう。 パターン２　 特定の端末が多く通信をしている相手の特定 例えば、ファイルサーバを指定して、どのホストとの通信量が多いかを特定するときなどに利用できる方法です。 はじめに、App Analyticsを開き、調べたいサーバのIPアドレスをフィルターに入力して表示される情報を絞りましょう。 次にSourceタブをクリックし、送信元IPアドレスを全て表示させます。 [Upload]や[Download]などの項目をクリックし、トラフィックの大きい順に並び変えます。 トラフィックの大きい順に並び変えたら、実際に通信量の多いPCを確認しましょう。 まとめ 本投稿では、App Analyticsの見方や活用方法について一例をご紹介しました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

本記事は、 Japan AWS Ambassador Advent Calendar 2024 の 2024/12/9 付記事です。 こんにちは、広野です。 2024年の re:Invent で、アプリから Amazon S3 バケットのオブジェクトを操作できるようにするための UI モジュールがリリースされました。 Storage Browser for Amazon S3 is now generally available - AWS Discover more about what's new at AWS with Storage Browser for Amazon S3 is now generally available aws.amazon.com 今回は実際に既存アプリに組み込んでみたので、その方法を紹介します。 そもそも何が嬉しいのか 開発したアプリから、S3 のオブジェクトをマネジメントコンソールの UI 風に操作できる。例えば RAG アプリに必要な独自ドキュメントを S3 に格納している場合、アプリの管理画面に S3 操作用 UI を組み込み、メンテすることができるようになる。このニーズはかなりあったはず！これまでは手作りしていた方が多かったのでは？ UI だけでなく、アップロード、削除、変更、フォルダ作成などの機能がモジュールに組み込まれている。アクセス権限制御もそこそこいける。すなわち、開発者がそういったベーシックな機能を開発しなくて済む。超絶楽！ AWS 純正モジュールなので、AWS がサポートしてくれる。安心！ このアップデートは神すぎます。もともと、9月にアルファリリースされていて早期の GA を期待していたのですが、re:Invent に間に合わせてくれて嬉しいです。AWS Amplify がリリースされたのと同じぐらいの衝撃を今受けております。 実際につくってみたもの UI はデフォルトのままにしました。カスタマイズも若干できそうです。 Home デフォルトで表示されます。カスタマイズ可能です。 指定したバケットおよびフォルダの一覧が表示されます。ここに表示されたフォルダ配下のオブジェクトをメンテナンスできます。 権限は Read / Write / Delete が選択できそうです。 Amazon Cognito でアプリにログインしたユーザにのみ、権限を与えています。 フォルダ名を押すと、その詳細が表示されます。ここでは bot1 を選択します。 今時点、オブジェクトがないので No Files と表示されます。 3点リーダーボタンを押すと、操作可能なメニューがハイライトされます。ここでは Upload をします。 右上の Add files ボタンを押すとファイル選択ウィンドウが表示されますが、ダイレクトに枠内に複数のアップロード対象ファイルをドラッグアンドドロップすることも可能です。最後に右下の Upload ボタンを押します。 アップロードが完了すると、Completed のステータスに変わります。今回は省略しますが、転送の進捗がパーセント表示されます。AWS マネジメントコンソールでも、S3 バケットを確認したらきちんとファイルが入っていました。 削除もしてみます。オブジェクトを選択して、Delete を選択します。 削除対象オブジェクトがリストアップされます。 右下の Delete ボタンを押すと、削除されました。省略しますが、マネジメントコンソールの方でも削除されたことを確認できました。 アーキテクチャ 今回、既存のアプリに追加で組み込んでみました。 AWS のアーキテクチャは以下のブログ記事で紹介したものと全く同じですので、こちらをご覧ください。 AWS Amplify Storage を AWS CloudFormation でマニュアルセットアップする サーバーレス WEB アプリ (SPA) から、ファイルをバックエンドにアップロードして処理したいことがあります。AWS Amplify と連携させた Amazon S3 バケット「AWS Amplify Storage」を使用すると、アプリとセキュアに連動したストレージを簡単に作ることができます。 blog.usize-tech.com 2022.05.31 簡単に説明しますと。 Amazon Cognito ユーザープールでアプリの認証をする。 その際に Amazon Cognito ID プールで、認証済みユーザーに任意の Amazon S3 バケットへのアクセス権限を付与する。 アプリから Storage Browser でファイルを Amazon S3 と送受信する。 AWS リソースの設定 上記アーキテクチャが実現できている前提で、以下の作業が必要です。 対象の Amazon S3 バケットに CORS 設定をする。Storage Browser が REST API で S3 にアクセスするため。 Amazon Cognito ID プールで Cognito ログイン済みユーザーに割り当てる IAM ロール (認証されたロール) に、対象の Amazon S3 バケットへのアクセス権限を定義する。 Amazon S3 バケットへの CORS 設定 以下の AWS 公式ドキュメントに書いてある通りです。Allowed Origins に、アクセス元アプリの URL を追加するとよりセキュアです。 Configuring Storage Browser for S3 - Amazon Simple Storage Service To allow Storage Browser for S3 access to S3 buckets, the Storage Browser component makes the REST API calls to Amazon S... docs.aws.amazon.com Amazon Cognito ID プールの認証されたロールの設定 これです。Amazon Cognito ID プールの設定の中に、認証されたロールという設定があります。 ここに、該当の Amazon S3 バケットへの権限を設定します。 AWS が標準として紹介しているのが、Cognito ユーザー単位で権限を制御できるようにしている方法です。 Import an S3 bucket or DynamoDB table - JavaScript - AWS Amplify Gen 1 Documentation Learn how you can import existing S3 bucket or DynamoDB table resources as a storage resource for other Amplify categori... docs.amplify.aws 私はそこまでこだわる理由がなかったので、バケット単位で権限を付与しました。 React アプリのコード React 18.3.1 と Vite を使用している前提です。(Next.js と AWS Amplify は使用していません) おそらく今時点では React 19 はモジュールの Dependency エラーが出るのでお勧めできません。 モジュールは、公式ドキュメント通り以下をインストールしておきます。 npm install --save @aws-amplify/ui-react-storage aws-amplify Installing Storage Browser for S3 - Amazon Simple Storage Service You can install Storage Browser for S3 from the latest version of aws-amplify/ui-react-storage and aws-amplify packages ... docs.aws.amazon.com App.jsx Vite を使用するとソースコードのルートが main.jsx になると思うのですが、私は create-react-app の名残で App.jsx に Amplify.configure を記述していました。AWS ドキュメントには、Amplify.configure はルートに書けとありましたが直すのが面倒なのでそのままにしています。 以下の例のように、Amplify.configure を記述する必要があります。Amplify で環境をデプロイしていないので、設定はマニュアル作成です。※具体的な値は VITE_ から始まる環境変数をビルド時に持ってきます。 import { Authenticator, useAuthenticator } from '@aws-amplify/ui-react'; import { Amplify } from 'aws-amplify'; import Loggedin from './Loggedin.jsx'; import Notloggedin from './Notloggedin.jsx'; //Cognito, S3, AppSync 連携設定 Amplify.configure({ Auth: { Cognito: { userPoolId: import.meta.env.VITE_USERPOOLID, userPoolClientId: import.meta.env.VITE_USERPOOLWEBCLIENTID, identityPoolId: import.meta.env.VITE_IDPOOLID } }, Storage: { S3: { bucket: import.meta.env.VITE_S3BUCKETNAMEAMPLIFYSTG, region: import.meta.env.VITE_REGION, buckets: { amplifystorage: { bucketName: import.meta.env.VITE_S3BUCKETNAMEAMPLIFYSTG, region: import.meta.env.VITE_REGION }, kbdatasource: { bucketName: import.meta.env.VITE_S3BUCKETNAMEKBDATASRC, region: import.meta.env.VITE_REGION, paths: { "bot1/*": { authenticated: ["write", "get", "list", "delete"] }, "bot2/*": { authenticated: ["write", "get", "list", "delete"] } } } } } }, API: { GraphQL: { endpoint: import.meta.env.VITE_APPSYNC, region: import.meta.env.VITE_REGION, defaultAuthMode: 'userPool' } } }); //ログインチェック function Authcheck() { const { authStatus } = useAuthenticator((context) => [context.authStatus]); return (authStatus === "authenticated") ? <Loggedin /> : <Notloggedin />; } export default function App() { return ( <Authenticator.Provider> <Authcheck /> </Authenticator.Provider> ); } 少し解説します。 ベースは、以下の公式ドキュメントの通りなのですが、 それだけでは動きませんでした。 Use Amplify Storage with any S3 bucket - React - AWS Amplify Gen 2 Documentation You can use the Amplify Storage APIs against your own S3 bucket in your account. AWS Amplify Documentation docs.amplify.aws 対象の S3 バケット内のパス (フォルダ) を、指定する必要があります。仕様として、そのフォルダより上位のオブジェクトにはアクセスできません。また、そのフォルダ内のオブジェクトにどの操作を許可するかの定義をします。 以下の paths: の部分です。※これが、ドキュメントには載っていない kbdatasource: { bucketName: import.meta.env.VITE_S3BUCKETNAMEKBDATASRC, region: import.meta.env.VITE_REGION, paths: { "bot1/*": { authenticated: ["write", "get", "list", "delete"] }, "bot2/*": { authenticated: ["write", "get", "list", "delete"] } } } kbdatasource というのは適当に付けた名前なので、ここは任意の名称で問題なさそうです。他の設定と紐づいてはいません。 設定すれば複数 S3 バケットも操作できると思います。少なくとも paths が設定されているバケット、フォルダでないと操作ができなそうです。 Storage Browser の実装 これは公式ドキュメント通りでした。 Storage Browser for Amazon S3 | Amplify UI for React The StorageBrowser component gives your end users a simple, visual interface for working with data stored in S3. ui.docs.amplify.aws デフォルトの UI 設定であれば、以下だけで実装できます。私の場合は Amplify でリソースをデプロイしていないので、Storage Browser を実装したい画面のコードに以下を追加しました。 import "@aws-amplify/ui-react-storage/styles.css"; import { createAmplifyAuthAdapter, createStorageBrowser } from '@aws-amplify/ui-react-storage/browser'; //中略 //Storage Browser const { StorageBrowser } = createStorageBrowser({ config: createAmplifyAuthAdapter() }); //中略 //returnの中で、画面内、表示させたい箇所にこれを差し込む {/* S3 Storage Browser */} <StorageBrowser /> CSSはインポートしておかないと、UI デザインが崩れると思います。 コードはほんの数行なのに、S3 バケット内を操作できる UI が実装できるって、凄すぎませんか！？ まとめ いかがでしたでしょうか。 既存 Amazon S3 バケットに Storage Browser からアクセスする方法は公式ドキュメントには載っていない情報だったのと、GA 直後で情報が少なかったのもあって、調べるのに苦労しました。ちゃんとは言い忘れましたが、AWS Amplify は一切使わず、Amazon CloudFront、Amazon S3 のホスティング環境に AWS CodePipeline 等でビルド、デプロイしています。そんな環境でも Amplify ブランドの UI モジュールは使えますので、ご安心ください。 本記事が皆様のお役に立てれば幸いです。

本記事は TechHarmony Advent Calendar 2024 12/9付の記事です 。 どうも、Catoクラウドを担当している佐々木です。 Catoクラウドを利用しているユーザーから、以下のような問い合わせをいただくことがあります。 Socketから定期的にAmazon.comやGoogle.comにpingしてるけど、これって何？？？   これは 「Synthetic Monitoring」 という品質監視をする機能の動作で、正常なものです！！！ ということで、今回は 「Synthetic Monitoring」  についてご紹介します。   画⾯は2024年12⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。   「Synthetic Monitoring」ってなに？ ラストマイルリンク、つまりインターネット回線の品質を監視するCatoの標準機能です。 Socketからインターネット上の特定の宛先（ドメイン、IPアドレス）へ定期的に通信(ICMP)を行うことによって、 インターネット回線上での遅延やパケットロスを監視しています。 「通信が遅いなー」と思った時に、どこが悪いのか切り分けするために活用できる機能ですね。   「Synthetic Monitoring」では、Amazon.comやGoogle.comを含む3つのWEBサイトに対して、 5秒間隔でPINGをするというデフォルト設定がされています。                    そのため、Socketから定期的にAmazon.comやGoogle.comにpingしていたんですねー！   「Synthetic Monitoring」の結果はどこで確認できるの？ 各サイトの「Site Monitoring」にある「Network Analytics」から確認できます。 ラストマイルリンク（インターネット回線）のパケットロスと遅延が確認できます。    例えば、通信が遅いと感じたらこのグラフを確認いただき、いつもよりパケットロスが増えている、遅延（RTT）が高くなっているのであれば、インターネット回線で問題ある可能性が高いので、インターネット回線の提供キャリア（ISP）に確認を依頼するといった対応がとれます。 また、ラストマイルリンクのグラフでは問題ないものの「Network Analytics」内にある別のグラフ「Packet Loss」でパケットロスが増えている、遅延（RTT）が高くなっている場合は、Cato側で問題が発生している可能性があるのでCato側の状態を確認するといった対応がとれます。   ▼イメージ   「Synthetic Monitoring」のチューニング方法 先ほど「Synthetic Monitoring」ではAmazon.comやGoogle.comを含む3つのWEBサイトに対して、 5秒間隔でPINGをするというデフォルト設定がされている、という話をしましたが、もちろんカスタマイズすることも可能です。                    ▼設定箇所 「Network」タブにある「Synthetic Monitoring」から設定できます。 「Internet Applications via local internet breakout」の項目を設定します。  ※チェックボックスを外すと、機能が無効になります。   ▼パラメータ 設定値 設定内容 デフォルト値 Test Interval  Socketからの通信間隔を設定します 5秒 Probe Type 通信の種類が選択できます ICMP/HTTP/HTTPS/DNS/TCP ※ICMP以外は別ライセンスが必要（注意事項参照） ICMP Destinations 通信を行う相手を指定します IPもしくはドメインで最大5つまで設定可能です Facebook.com/Google.com/Amazon.com   注意事項 「Synthetic Monitoring」を利用する際に以下の注意事項があります。 おもにDEM Pro（Digital Experience Monitoring Pro）ライセンスに関連する事項になります。 DEM Proについては、以下の記事をご参照ください。 【Catoクラウド】新オプション! Digital Experience Monitoring はここがすごい! Catoクラウドの新オプション「Digiral Experience Monitoring」の機能をご紹介します。 blog.usize-tech.com 2024.12.06   1.DEM Proライセンスを購入しないと動作しない機能がある DEM Proライセンスを購入しないと「Synthetic Monitoring」の一部機能が動作しません。 しかも、動作はしないのに、設定はできてしまうので注意が必要です。 具体的には以下が該当します。 「Probe Type」でICMP以外利用できません（設定は可能） 「Internet Applications via the Cato Cloud」も利用できません。 ※Catoクラウド経由でインターネットアプリケーションの品質監視をする設定です。 「WAN Applications via the Cato Cloud」も利用できません。 ※Catoクラウド経由でのWAN上のアプリケーションの品質監視をする設定です。 ▼イメージ   DEM Proライセンスを購入すると利用できる「Experience Monitoring」が、もともとフリートライアルで利用できていたことの名残で「動作はしないけど、設定できる」上記の設定箇所が残っているようです。 Catoサポート曰く、まもなく上記設定項目自体を別の場所に移動させるようなので、いずれこの注意点も解消されると思っています。   2.デフォルトの「Amazon.com」を指定すると一部グラフが見にくくなる 日本国内でCatoを利用している場合、Destinationsの「Amazon.com」を変更したほうがいいと思っています。 「Amazon.com」はおそらく 日本国外 のサーバが応答しており、パケットロス、遅延の数値が大きくなりがちなためです。 ▼イメージ   ▼対策 「Amazon.com」を消して、日本国内のサーバが応答するであろうドメインを登録します。 ※Amazon系なら「Amazon.jp」、他にも「Yahoo.co.jp」や通信品質を確認したいWEBサイトを登録してもいいと思います。 3.中国拠点の設定はよりカスタマイズが必要 中国拠点の場合、Socketからデフォルト設定の3サイト（AmazonやGoogleなど）へ通信ができません。 ラストマイル監視が常に100%Lossになってしまうので、中国の拠点だけ「Synthetic Monitoring」の宛先を中国国内からアクセス可能なURLへ変更することをオススメします。 例：「 weibo.com」「baidu.com」「qq.com」など ※サイト単位で 設定する場合は、「該当のサイト」の「Site Configuration」>「Synthetic Monitoring」から設定可能です。   まとめ 今回のポイントは以下です。 ・Socketから定期的にAmazon.comやGoogle.comにPingしてるのは正常な動作 ・Synthetic Monitoringという品質監視をする機能の動作で通信遅延の切り分けに役立ちます ・デフォルトではAmazon.com/Google.com/Facebook.comに5秒間隔でPingを実施 ・自分好みにチューニング可能（一部注意事項あり）   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

本記事は TechHarmony Advent Calendar 2024 12/8付の記事です 。 Catoクラウドの管理者の皆様には、日々様々な通知が届いていませんか？ 今回はCatoクラウドの通知機能についてまとめてみました。 通知というと、セキュリティ関連やネットワーク関連の警告、またはサービス障害関連の通知を思い浮かべる方が多いと思います。 ですが実際には他にも様々な通知が届いているはずです。 今回はCatoではどんな通知機能があるのか整理してみたいと思います。 通知の種類 まず、Catoの通知を大きく分類するとこんな感じです。 No 通知の種類 内容 1 セキュリティに関する通知 各種セキュリティポリシーにマッチした通信の発生をトリガーに通知します 2 Socketの接続に関する通知 Link Health RulesによるSocket 接続状態の異常検知をトリガーに通知します 3 インシデントの通知 XDR機能によるインシデントの検知をトリガーに通知します 4 CMAのシステム通知 Socketのアップグレード結果やライセンスの有効期限などを通知します 5 アップデート情報の通知 週に1度、機能強化や新機能に関する情報が通知されます 6 サービス障害・メンテナンス通知 各PoPのメンテナンスやサービス全体に関する障害が発生した場合に通知されます これらの通知は、デフォルトで通知が有効化されているものとそうでないものがあります。 結論からお伝えすると、CMAのシステム通知(No.4)とアップデート情報の通知(No.5)はデフォルトで有効化されており、その他は管理者の設定次第となっています。 デフォルトで有効化されて いる もの → アップデート情報の通知，CMAのシステム通知 デフォルトで有効化されて いない もの → セキュリティに関する通知，Socketの接続に関する通知，インシデントの通知，サービス障害・メンテナンス通知 こう見ると、ほとんどが管理者の設定次第ということがわかります。 さらに、有効/無効化および通知先と通知タイミングの設定は、CMAからできるものとできないものがあります。 少しややこしいので、今回はこのあたりを整理していきます。 CMAで設定するもの それでは、まずCMAから設定できるものです。 No.1 セキュリティ機能による通知 セキュリティ機能による通知は管理者であればご存知と思いますが、ポリシーにマッチした通信の発生をトリガーに通知するものです。 例えばInternet Firewallであれば下図のような「Security Alert」が通知されます。 各ポリシーを定義する際に通知の設定を行いますが、この時すべてのポリシーに対して通知設定をする必要はなく、重要なポリシーに対してのみ通知の設定を行うとよいかと思います。 また、Catoがデフォルトでポリシーを定義している場合があります。 例えばIPS・DNS Protection・Anti-Malwareです。Internet Firewallのカテゴリフィルタなどのポリシーもそうですね。 このようなデフォルトで定義されているポリシーは通知が無効化されていることが多いです。 これらのデフォルトポリシーは、通知が大量に飛んでしまう可能性を考慮し基本的にはそのまま(無効の状態)で問題ございませんが、各企業のセキュリティポリシーに沿って変更を検討いただくのもよいかと思います。 No.2 Socketの接続に関する通知 Socketの接続に関する通知は、Link Health Rulesという機能をを使います。 Link Health RulesにてSocketの接続状態における異常を検知するようルールを定義し、異常の検知をトリガーに通知します。 例えば、SocketのDisconnectを検知した際は下図のような「Health Alert」が通知されます。 また、Link Health RuleにはConnectivity Health RulesとQuality Health Rulesの2つがあり、CatoのBest Practiceによるとこれらは 設定しておくことが推奨 となっております。 詳しい設定方法は本記事では割愛しますが、それぞれで検知できる内容をまとめるとこんな感じです。 Connectivity Health Rules 以下のような接続の正常性に関するイベントを選択し、そのイベントの発生をトリガーに通知します。                                                  No イベントの種類 説明 1 Failover プライマリリンクとセカンダリリンク間、またはその逆のフェイルオーバー 2 Primary Disconnect アクティブ状態のリンクの切断 3 Secondary Disconnect パッシブ状態またはラスト リゾート ステートのリンクの切断 4 Socket Failover HA 構成のソケット間のフェイルオーバー 5 Internet as a Transport インターネット(Cato Cloudではない)を介してデータを転送しているリンクの切断 Quality Health Rules 以下のような接続の品質閾値を設定し、評価期間にその設定した閾値を満たない場合に通知します。 この時、品質閾値は複数を組み合わせて設定することができます。                                                  No 品質閾値の種類 説明 1 Packet Loss 送信パケットの割合 2 Distance (msec) 送信元と PoP 間でパケットが移動するのにかかる時間 (ミリ秒) 3 Jitter (msec) パケット間の遅延 (ミリ秒単位) 4 Congestion 輻輳（評価期間に破棄されたパケットが1%を超えた状態） No.3 インシデントの通知 CatoではXDRという機能により、セキュリティを脅かすインシデントを自動的に検知する機能が提供されています。 検知したインシデントのことを「ストーリー」と呼んでいますが、Detection ＆ Responseという機能を使えばそのストーリー生成をトリガーに通知させることができます。 例えば、危険なマルウェアの侵入口なる可能性を秘めたダウンローダーを検知するストーリーが生成された際に「Detection ＆ Response Alert」を通知します。 また、各ストーリーには「Criticality」という重要度を表す値が1 (低) ～ 10 (高) で付与されます。 Criticalityが7以上のストーリーは注意が必要だと言われていますので、Criticalityが7以上のストーリー生成をトリガーに通知を行うことを推奨しています。 こちらも設定方法の詳しい説明は割愛しますが、このようにCriteriaで条件を定義することができます。 No.4 CMAのシステム通知 CMAのシステム通知とは、Socketのアップグレード結果の通知やライセンスの有効期限の通知など様々です。 2024年12月時点では、CMAのSystem Notificationsのページで設定ができるようになっており、デフォルトで以下のイベントをすべての管理者へ通知する設定となっています。 No イベントの種類 内容 1 Data Export CSVファイルなどのデータエクスポート 2 Expired Signing Certificate デバイス認証に使用されるルートCA署名証明書の有効期限切れ 3 SCIM Provisioning SCIMプロビジョニングの成功または失敗 4 Admin Locked/Unlocked CMAの管理者アカウントロックとロック解除 5 User Locked/Unlocked Catoクライアントのロックとロック解除 6 License Updated ライセンスの有効期限切れ・更新・変更 7 Activate New Socket Socketのアクティベート（Siteとの紐づけ）準備完了 8 General Notification CMAアカウントに影響を与える状況に対する特別なお知らせ ※ほとんど送信されません。 9 Socket Upgrade Socketバージョンアップの連絡 10 DC Connectivity Failure User Awarenessのディレクトリ サービス同期に使用されるWMI コントローラの失敗 11 Directory Services Sync LDAPを使用したディレクトリ サービス同期の失敗 例えば、Socketのアクティベート準備が完了した際は、下図のように「Activate New Socket」が通知されます。 次に、設定方法についてです。 設定方法 設定方法はNo.1～4すべて同様です。 「Send Notification」にチェックを入れることで通知機能の有効化を行い、通知先と通知タイミングを定義していきます。 以下は管理者全員に即時でメール通知する方法で、一番スタンダードな設定方法です。 Send notification to：Mailing List（All Admins） Frequency：immediate 事前に定義しておけばCMAの管理者以外にメール通知させることも可能です。 また、メールによる通知だけでなくWebhookを使ってSlack、ServiceNow、Jira、その他Webhook 経由でのアラート受信に対応しているサービスに対して通知を行うことも可能です。 Webhook機能を利用してSlackに通知する方法はこちらの記事をご参照ください。 Catoからの通知をWebhook機能を利用してSlackで受信してみた Catoが提供しているWebhook機能を実際に試してみました。 blog.usize-tech.com 2024.02.19 通知メールのカスタマイズ 少し話が脱線しますが、通知メールのカスタマイズ機能があることをご存知でしょうか？ デフォルトでは下図のようにCatoのテンプレートになっていますが、Email Templateページにて各企業ブランドに合わせてカスタマイズすることができます。 特に③の「Contact us message」の部分関しては、具体的な連絡先に変更すると便利だと思います。 E-mail Logo Brand Color Contact us message CMAで設定できないもの では、続いてCMAから設定ができないNo.5、No.6についてです。 No.5 アップデート情報の通知 Catoでは毎週のように機能強化や機能追加が行われており、日本の場合は毎週日曜日の夜中～月曜日の早朝にかけて下図のような「Product Update」が管理者に通知されます。 この通知は、管理者として登録がされた時点でデフォルトで有効になり、Catoから自動でメール配信される設定になっています。 そのため、管理者にてCMAから無効化や通知先・通知タイミングの変更を行うことができません。 もし配信をとめてほしいといった場合は、メール本文の一番下にある「unsubscribe from this list」をクリックし、次のページで「Unsubscribe」をクリックします。こうすることで購読停止が可能です。 ですがアップデート情報の中には、重要な情報も含まれますので、購読停止はせずに内容をご確認いただくことをお勧めします。 No.6 サービス障害・メンテナンス通知 最後に、サービス障害・メンテナンス情報の通知についてです。 サービス障害・メンテナンスはサービス停止を伴う場合があり非常に重要な情報なのですが、なんと 管理者ご自身で 通知の設定をしないと通知がされません！ ですので、必ず 設定をしておくことを推奨 します。 通知設定を行うと、例えば緊急メンテナンスが行われる際に下図のような「Emergency Maintenance Notification」が通知されます。 また、PoP障害の場合は「PoP Infrastructure – Services degradation due to（原因）」が通知されます。 詳細はこちらの記事でご説明しておりますのでご参照ください。 Catoクラウドのステータスページについて Catoクラウドでは、現在のサービス状態や定期メンテナンスなどの情報を確認できるステータスサイトのページがあります。 今回はステータスページについて、見方や使用方法を確認していきたいと思います。 blog.usize-tech.com 2024.02.06 まとめ 最後に、本記事のまとめです。 この記事が、今一度通知設定を見直すきかっけになれば幸いです！ 通知機能はデフォルトで有効化されているものとそうでないものがある 通知機能はCMAで設定できるものとできないものがある サービス障害・メンテナンス通知はデフォルトで無効になっているため設定するを推奨します Socketの接続に関する通知もCatoのBest Practiceに準じて設定することを推奨します

本記事は TechHarmony Advent Calendar 2024 12/7付の記事です 。 こんにちは、Catoクラウド担当SEの中川です。 本記事では、年末ということで、2024年のCatoに関する、価格改定などお客様のお財布事情に影響の高かったお知らせや、ユーザーの目を引いたアップデート情報などご紹介します！ 価格改定・サービス体系の変更 早速ながら価格の話になります・・！ 2023年11月3日、Cato Networks社から Pricing Update として全世界のパートナーに対して一斉に通知が行われました。 2024年2月以降の価格体系および価格の見直しが行われるという内容が発表されました。 年明け早々の話題でしたので詳細な解説は不要かと思いますが、おさらいしたい方は以下の記事をご覧ください。 Catoクラウドの価格改定（Pricing Update）について 2023年11月にアナウンスされたCatoクラウドの価格改定（Pricing Update）について現行サービス体系との差異を中心に解説します。※実際の価格については記載していません。 blog.usize-tech.com 2023.12.25 概要をお伝えしますと、価格は日本においては円安の影響が大きく、 値上げ となりました。 価格体系の変更については、リージョンやSiteライセンスのPoP接続帯域の統廃合、セキュリティオプションが統廃合されました。 また、新サービスとして、XDR Security Pro、Endpoint Security（EPP）、Socket X1600 LTEモデルについての発表が行われました。 2024年最新版のサービス体系の詳細は、以下の記事をご覧ください。 Catoクラウドのサービス体系について（2024年最新版） 2024年2月以降のCatoクラウドの新しいサービス体系（基本料金、オプション料金、マネージドサービス）について解説を行っています。 blog.usize-tech.com 2024.01.29 特に価格改定の影響は、日本ユーザへ大きな影響を与えました。 さらに直近、日本とアメリカでは政治の変わり目が訪れました。政治経済が不安定な中、為替相場の変動も大きい状況です。 Catoのみならず、特に海外製品のクラウドサービス利用にあたっては、こういった価格改定が起きうることを、常に念頭に置いておくことが重要かもしれません。 新サービスのリリース ここでは、2024年Cato社がリリースした新サービスをご説明していきます！ 上記サービス体系の変更でも少し触れましたが、2月早々にEPPとXDR Security Proがリリースされました。 さらに、トライアルとして無償提供されていたExperience Monitoringが、11月にDEM (Digital Experience Monitoring) という名前で有償版としてリリースされました。 EPP 2024年2月5日に、新サービスとしてEPPとXDR Security Proがリリースされました。 詳細なご説明は以下の記事をご覧ください。 CatoクラウドのEPPとXDRについて Catoクラウドで新たにリリースされたEndpoint Protection（EPP）とExtended Detection and Response（XDR）についての解説をしています。 blog.usize-tech.com 2024.02.14 EPPとは、「Endpoint Protection Platform」の略称です。PCなどのエンドポイントデバイスを、サイバー脅威から保護するセキュリティ製品のことを言います。 EPPは、端末にEPPソフトウェアをインストールして利用します。 Catoクラウド上を流れるネットワークを超えて、エンドポイントまでをCMA上で管理可能となる製品となっています。 XDR Security Pro 続いて、XDRです。 まず、XDRは、「Extended Detection and Response」の略称です。 簡単に申し上げると、エンドポイントやネットワーク、セキュリティ、クラウドといった各種のログを収集・分析し、攻撃を可視化、インシデント管理を一元化できるセキュリティソリューションのことです。 CatoのXDRは、世界初のSASEベースのXDRソリューションで、Catoクラウドで検知したイベントをもとに分析した結果がCatoの管理コンソール上で確認可能です。 また、その分析結果をもとに、Cato管理コンソール上でスムーズに必要な対処まで行うことができることが魅力となっています。 DEM Pro (Digital Experience Monitoring Pro) Experience Monitoringとは、その名の通り、(ユーザの)体験を監視することができる、2024年11月3日にリリースされたばかりの新機能です。 具体的には、アプリケーションのパフォーマンスのほか、端末のCPU/メモリ、Wifi、回線/プロバイダの状況まで可視化でき、通信経路上の問題の早期発見と迅速な解決が可能となるオプションサービスです。 通信遅延が発生しても一体どこに原因があるかわからない、切り分けが困難なときに、この機能を利用すればCMAで即時に判断できるため、ネットワークの運用担当にとって、大変有用な機能なのではと思います。 要注目なアップデート情報 Catoクラウドでは、上記のような大々的な新サービスリリースの他、毎週のように機能アップデートが行われています。 ここでは、今年の1月から遡り、11月までの少しばかり目を引いたアップデートをいくつかご紹介していきます。 なお、弊社の FAQサイト では、毎週情報更新し掲載しておりますのでぜひご購読ください！ 1月 アラート通知のWebhooksサポート 1月29日のアップデート です。 Webhookを使用して、サードパーティのプラットフォームにアラートを送信し、アラートベースの自動化フローを作成できるようになりました。 カスタムヘッダーのサポートを含む高度なカスタマイズが提供されています。 メッセージ本文をカスタマイズしたり、事前定義済みのテンプレートの使用もできます。 1月 CASBでアプリカテゴリにてアクティビティの制御が可能に こちらも 1月29日のアップデート です。 CASBの機能が強化され、特定のアプリだけでなく、アプリカテゴリに対するアクティビティを制御できるようになりました。 例えば、次のようなことが可能になりました。 ファイル共有（File Sharing）またはオンラインストレージ（Online Storage）カテゴリのアップロードをブロックするルールを設定し、新しいアプリがカテゴリに追加されると、ルールが自動的に更新されます。 一緒に管理したいアプリを含むカスタムカテゴリを定義し、そのカテゴリのダウンロードをブロックする単一のルールを作成する。サポートされるアクティビティには、アップロードとダウンロードが含まれます。 2月 イベントにセキュリティに関するフィールドが追加 2月には先述の通り、XDRとEPPがリリースされましたが、もちろんその他にもアップデートは多数あり、 2月19日のアップデート から1つご紹介します。 このアップデートではイベントログとして出力されるログ情報に、セキュリティ関連の情報が追加されました。 例えば、インターネットファイアウォールイベントを使用して、TLSインスペクションされたのかバイパスされたのか、またどのネットワークルールがマッチしたのか、さらにQoSプライオリティ値とPoPのパブリック・ソースIPの情報が確認できるようになりました。 3月 RBIの機能強化 3月18日のアップデート により、リモートブラウザ隔離（RBI）で行うようにする制御が細かく指定できるようになりました。 アップロード、ダウンロード、コピー/ペースト、印刷などの操作をブロックまたは許可できるようになりました。 加えて、Read Only設定も追加され、ユーザがサイト上で認証情報やその他の機密データを入力できないような制御も可能となりました。 4月 UserAwareness機能にて、Azure ADでSCIMプロビジョニングされたユーザーを識別可能に 4月15日のアップデート で公表されました。 Cato Identity Agentは、Microsoft Azure ADハイブリッドジョインを使用するときに、サイト配下にいるSCIMプロビジョニングされたユーザーを識別できるようになりました。 また、これまではAzure ADでSCIMプロビジョニングしているユーザーには、SDPライセンスが必要でしたが、本アップデートにて必要なくなりました。 5月 CASB・DLPでブロック通知が表示されるように 5月6日のアップデート です。 ユーザーエクスペリエンスを向上させるために、CASB・DLPによってブロックされたときの通知を有効にできるようになりました。 これまでCASB・DLPのルールでブロックされた際には、Catoによるブロックとは分かりづらく、何らかのエラーで操作できないことしか分からない状況でした。 本アップデートで、操作がブロックされた原因がCatoによる制御であることが、ユーザにとって分かりやすいよう改善されました。 6月 SLA計測のメカニズムを改善 こちらは 6月3日のアップデート で公表されたものです。 SiteのSLAを計測するメカニズムの粒度が改善されました。特定のパーセンテージの時間ウィンドウを定義し、そのウィンドウ内でSLAが守られているか判断します。 例えば、パケット損失が120秒の時間ウィンドウの50%に設定されている場合、そのウィンドウ内で60秒間パケット損失が発生すると、そのSiteは許容できないSLAの値として判定されるよう設定可能になりました。 6月 複数の管理者でインターネットファイアウォールの同時編集が可能に 6月17日のアップデート で公開された機能です。 タイトルの通りではありますが、インターネットファイアウォールポリシーを複数の管理者が並行して変更できるようになりました。 また同時に、多数のルールがある場合にも応答性が高くなり、インターネットファイアウォールポリシーを管理するためのAPIがサポートされるようになりました。 加えてこの3か月後の 9月16日のアップデート にて、WANファイアウォールでも同様の機能が追加されました。 6月 リモートユーザーセッションの取り消し機能追加 これもまた6月になります。 6月24日のアップデート になります。 ネットワークへのアクセス制御を強化するために、すべてのデバイスでセッションを取り消すことができるようになりました。 取り消したリモートユーザには再認証が強制されます。ユーザーは新しいセッションを確立するために再認証するまでネットワークにアクセスできません。 セッションの取り消しは、盗難デバイス、アカウントの侵害、すでに退職している従業員などによる不正アクセスを防ぐのに役立ちます。すべての認証方法、IdP、およびすべてのクライアントバージョンでサポートされています。 7月 モバイルユーザーの初回接続手順の簡素化 7月22日にリリースされたアップデート です。 ユーザーがCatoクライアントでサインインする際に、Catoクライアントを起動しメールアドレスを入力したタイミングで、Activationメールが送信されるようになりました。(LDAP / 手動登録の場合のみ) それまでは、Cato管理者がユーザ作成したタイミングでActivationメールが自動送信されていました。本アップデートにより、ユーザは自分のタイミングでパスワード設定できるようになりました。 8月 デバイスポスチャにて、実行中プロセス/レジストリキー/プロパティリストが選択可能に 8月5日のアップデート です。 セキュリティ強化のため、実行中のプロセス、レジストリキー（Windowsデバイス上）、およびプロパティリスト（macOSデバイス上）のチェックをデバイスポスチャの条件に指定できるようになりました。 9月 デフォルトのTLSインスペクションバイパスルールの可視化 こちらは 9月2日のアップデート です。 TLSインスペクションを適用すると問題を引き起こす可能性のある特定のアプリ、OS、クライアントをCato社はデフォルトでバイパスしています。 これらのデフォルトのTLSインスペクションルールがCMAで閲覧可能になりました。CMA ＞ Security ＞ TLS Inspection内のDefault Bypass Ruleから確認できます。 10月 Azure vSocketが2 NICをサポート 10月7日に公開されたアップデート です。 最新のvSocketファームウェアにて、2つのNICを持つAzure VMをサポートするようになりました。 これにより、小規模なVMインスタンスタイプを使用してAzureのコストを削減できます。 既存の3 NIC vSocketは、新しい2 NIC VMインスタンスに移行可能です。なお、3つのNICも選択は可能です。 早速SCSKでは移行手順を確認し、以下の技術ブログにて詳細をご説明させていただいております。Azure vSocketご利用中の方はぜひご覧ください。 ・ 【Catoクラウド】AzureのvSocketが2ポート対応した件 11月 CMAのUIが大幅変更 こちらは直近 11月18日に公表されたアップデート になります。 CMAのUIが大幅に変更されるという内容で、主に、旧レイアウトでMonitrotingのメニューにあるダッシュボードが、Access / Network等の機能別メニューの配下へ移動されます。 また、ページのお気に入り機能の追加もされるようです。ブラウザのブックマーク機能のようなもので、お気に入りにしておくと即時に登録したページに移れるという機能です。 なお、本アップデートで変更されるのはレイアウトのみで、ご利用いただける機能には変更はないことご安心ください。 2024年12月7日現在、CMA画面右上にトグルスイッチが表示されており、旧レイアウトと新レイアウトの切替えが可能となっております。 将来的にはすべてのアカウントで新メニュー画面が適用される予定となっていますので、早いうちに使い慣れておくことをオススメします！ 業界ニュース 最後にCato、SASEにまつわる業界ニュースを2つ取り上げます！ Cato Networks社、シングルベンダーSASEのリーダーに Cato Networks社が、2024年7月3日に発行された ガートナー（Gartner™）のマジック・クアドラント（Magic Quadrant™）のシングルベンダー SASE 部門においてリーダーに認定されました。 2023年はチャレンジャー認定でしたが、2024年はリーダーに認定されました。 シンプルで統合された管理画面 CMAがユーザから高い支持を得ており、その結果として、ユーザエクスペリエンス（UX）についても、他ベンダーと比較して高い評価を得ています。 詳細は以下のブログをぜひご覧ください。 Cato Networks社が 2024年 ガートナーのマジック・クアドラントのシングルベンダー SASE でリーダーに認定 Cato Network社 Catoクラウドが 2024年最新版 ガートナー マジック・クアドラントのシングルベンダー SASE でリーダーに認定されました blog.usize-tech.com 2024.07.22 Cato Networksの「Partner Summit 2024」にて2年連続でパートナーアワード受賞 宣伝にはなりますが、ありがたいことにSCSKは、2回目の日本開催となる「Partner Summit 2024」 において「Best Partner Marketing Campaign 2023」を受賞しました。 SCSKは、Catoクラウドのビジネス拡大に向け、認知向上、新規案件の創出を目的としたマーケティング面で、顕著な成果を上げたことを評価いただきました。 2年連続でパートナーアワードを受賞できたことを大変光栄に思います。 これからも、このSCSK技術ブログ「TechHarmony」への記事投稿も継続し、さらにCatoクラウドのデジタルコンテンツの拡充を図って行きたいと考え直近ではYoutubeへのトラブルシュートのための動画アップロードを始めています。ぜひこちらもご参照ください！ ↓Youtube動画リンク集↓ 設定方法やトラブルシュートの動画集 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 設定方法やトラブルシュートに役立つ動画集です。【Catoクラウド】通信ログ(Events)の確認方法【Catoクラウド】拠点全体でインターネット... cato-scsk.dga.jp まとめ 今年のアップデート総まとめ、いかがでしたでしょうか。 2024年は、年明け早々にサービス体系の変更・価格改定、新サービスのリリースから始まった年でした。 1年分のアップデート情報を振り返ってみて、セキュリティ強化と運用の利便性向上が特に目立った1年だったと感じます。 これはCatoが現代のセキュリティ需要に応えると同時に、ユーザ企業自身でも簡単に運用ができる製品を目指しているのではないかと思っています。 来年のアップデート情報にも期待が高まります！

本記事は TechHarmony Advent Calendar 2024 12/6付の記事です 。 本記事では、2024年11月3日にリリースされた、Catoクラウドの新しいオプションである「Digital Experience Monitoring」をご紹介します。 Experience Monitoringとは、ユーザがWebサイトやSaaSアプリケーションを利用する際に、通信が遅くないか、どのくらい快適に利用できているかを可視化する機能です。 もともとCatoクラウドではExperience Monitoringの一部機能をトライアルとして提供していましたが、2024年11月3日から機能拡充し、有償オプションにリニューアルしています。このオプションサービス名が 「 Digital Experience Monitoring 」(以下 DEM ) です。 なお、リニューアル前のExperience Monitoringについては、以下の記事でご紹介しています。あわせてご参照ください。 ユーザー通信可視化の新機能！Experience Monitoringについて ユーザー通信可視化の新機能！「Experience Monitoring」について紹介します。 blog.usize-tech.com 2024.02.08 DEMで何ができるの? 以前のExperience Monitoringの機能はすべて利用できる他、さらに以下3機能が追加されています。 Device Monitoring ユーザ環境について、かなり詳細な情報が取れるようになりました。 Synthetic Probe Monitoring 通信品質を判断するための通信対象を、柔軟にカスタマイズ指定できるようになりました。 XDRでのExperience Anomaly検知 SiteのExperienceの急激な変化を、XDR Storyとして検知・通知できるようになりました。 これにより、 「ユーザが快適に業務アプリを使えているかのモニタリング」がより細かくできる ようになり、また 問題発生時の原因箇所の特定がより簡単に なりました。 本記事では、これらの新機能を中心に、できることや活用方法をご紹介していきます。従来の機能については、前述のExperience Monitoringの記事をご参照ください。 新機能1) Device Monitoringとは? Device Monitoringは、 Catoクライアント (※) をインストールしているモバイルユーザの環境を、詳しく確認できる機能 です。画面を見るとその機能が一目瞭然です。 ※2024年11月現在、WindowsとMacOSクライアントのみの機能です。 特定の1ユーザのExperience Monitoring画面を例にご紹介します。 ユーザごとの画面は上記のようになっています。 ① ユーザ名、接続PoP、利用デバイス名、OS、クライアントのバージョン、接続ISPなどの基本情報 ② 指定期間内のユーザのExperienceの状況 ③ 端末からアプリケーションまでの間で、どの箇所に問題がありそうかの分析 ④ ③の各項目の詳細情報 上記スクリーンショットの例を見ると、端末、Wi-Fi、LANの状況は 緑表示 で良好そうで、その先のLast Mile(回線・プロバイダ)やApplication側の通信は 黄色表示 の普通、全体として Fair (普通)という状況です。 ④の各項目では、以下の詳細情報が確認可能です。アイコンと詳細情報は、以下の図のように対応しています。 項目名 確認できる内容 アイコンがPoor(赤色)のときに疑われる事象 Device Hardware Catoクライアントが収集した、その端末のCPU使用率、Memory使用率 端末自体の負荷が高く、動作が遅くなっている可能性があります。端末の状況を確認します。 Wi-Fi 端末が接続している無線アクセスポイントの電波強度 利用環境のWi-Fiの電波が弱い可能性があります。 LAN Gateway 端末が接続しているLAN内のゲートウェイへのPacket Loss、Distance LAN内で、通信混雑・不安定などが発生している可能性があります。 Last Mile 端末からCato PoPを通らずにInternetへ出る場合のPacket Loss、Distance、またCatoクライアントのTunnel接続時間 インターネット接続環境の通信品質が良くない可能性があります。 Application Performance Cato PoPを経由してアプリケーションへ接続する際の応答時間 また、設定した 「Synthetic Probe Monitoring(※)」の観測状況 ※次項にてご紹介します ‐ Applications アプリケーションごとの応答時間や接続状況(Good/Fair/Poor) 特定のアプリケーションだけがPoorの場合、そのアプリケーションの反応が良くなかったり、ご利用地域からのサーバまでの距離が遠い可能性などがあります。 各項目を確認することで、例えばユーザから「特定アプリへの通信が遅い」と申告があった際に、何が原因になっているのかのアタリを簡単につけることができます。これは便利ですね! 新機能2) Synthetic Probe Monitoringとは? Application Performanceで通信品質を測定する際の、通信先となる対象を、柔軟に設定できる機能です。 DEMオプションを契約している場合のみ、Cato管理画面に「 Experience Monitoring Probes 」という設定項目が表示されます。 デフォルトの状態では、測定対象(Probe)として”catonetworks.comへのICMP通信”が定義されています。これは、全Site・全Userについて「 catonetworks.comへのICMP応答によって、Application Performanceを測定することとする 」という設定です。 ですが、ユーザにとっては、catonetworks.comへのICMPが早くても遅くても、業務にはおそらく影響しないので、ユーザの通信体感を測る目的には合っていなそうです。 そこで、ここのProbeを業務でよく使う通信先・通信内容に設定します。例えば「outlook.office.comへのHTTPS接続」(※)などです。ProbeはInternetとWANの両方が設定できますので、 業務でよく使うSaaSと、オンプレシステムの2つを登録 しておくと、InternetとWAN両方の通信状況が可視化できて良いかと思います。 ※ProbeはICMPの他、HTTP、HTTPS、DNS、TCPが指定できます。 また、設定したProbeは、指定したSiteやユーザ、またグループにのみ適用することも可能です。設定例として、国・エリアによって使うアプリが違う場合には、それぞれ異なるProbeを指定するといったことができます。 ユーザの利用体感に近いデータを測定できるよう、そのユーザが業務でよく使うアプリケーションをProbeとして設定するのがポイントです。 Device MonitoringとSynthetic Probe Monitoringで何ができるの? Probeを設定すると、前述の「 Application Performance 」にて、指定したProbeへの通信状況のグラフが表示されます。 以下の例は、Internet向けに「teams.microsoft.com」を指定し、WAN向けには何も指定していない状態です。 見ると、TeamsへのPacket lossが100%になっているような時間帯があり、一時的にTeams通信に問題が出ていたことが予想されます。 その時間帯の他の監視項目(Device Hardware、Wi-Fi、LAN Gateway、Last Mile)を見てみて、特に問題が無いようであれば、Teams側で何らかの問題が発生していたかもしれません。 用途としては、例えばユーザから「最近社内システムへの通信が遅い」という申告があった際に、Synthetic Probe Monitoringのグラフを見て、以前と現在とで変化があるか、他のユーザはどうなのかといった情報を確認し、問題の切り分け材料にできるかと思います。 新機能3) XDRでのExperience Anomaly検知 ここまでご紹介したExperience分析は、モバイルユーザだけでなく、Site内にいるユーザや、Site(拠点)自体に対しても可能です。 このうち、SiteのExperienceについては、普段と異なる、急激なレスポンス悪化等があったときに、Cato XDRのStoryとして検出し、管理者へ通知することが可能になりました。拠点の通信状況の監視手段としてぜひ活用いただきたいです。 (余談)Good/Fair/Poorをどう判定しているの? ところで、Experience Monitoringの Good / Fair / Poor  はどういった基準で判断されているのでしょうか。 Catoによると、すべてのCatoユーザが生成した実際のトラフィックから、AIでベースライン(期待される基準)を規定し、そのベースラインよりも良いか、同じくらいか、悪いかで判断しているそうです。ベースラインは動的に変化するため、同じようなExperienceでも、日によって判定が違うということはあるようです。 決まったしきい値があるというわけではないので、問題切り分け時の参考情報のひとつとして見ておくのがよいかなと思います。 まとめ 以上、「Digital Experience Monitoring」の新機能についてご紹介しました。 Experience Monitoringは、個々のユーザが快適に業務を行えているかを可視化できます。 検証している我々も「Catoクライアントを入れているだけで、ここまでユーザの状況がわかっちゃうのか!」と驚きました。ネットワーク管理者の強い味方になる機能ですので、ぜひ導入をご検討ください。 機能の詳細は、以下のCato Knowledge Baseも合わせてご参照いただけますと幸いです。 Experience Monitoring | Cato Knowledge Base

この度、4年ぶり位にCato Management Application（CMA）がリニューアルされます！ リニューアルと言うと大袈裟かもしれませんが、メニュー構成の変更により特定のサービスやコンテンツの配置が変わってより使いやすくなるというものです。 実際に見てみた感想としては、各サービスやコンテンツが然るべきところに収まったという印象です。 CMAのAdminアカウントをお持ちの方には、アップデートの通知が届いていることと思いますし、またCMAにログインした際、ページ上部に「Try New Navigation」というトグルスイッチが表示されているのでもうお気付きかもしれませんね。 この記事では、今回の変更についてご紹介しますので是非ご覧ください！ CMAの特徴 今更ですが、CatoクラウドのCMAの特徴について少しだけ述べたいと思います。 CMAの一番の売りは、全てのネットワーク設定やセキュリティ設定はもちろん、Catoを通過した全てのログが1つのコンソール画面で見る事ができる点と、ネットワークエンジニアならある程度直感で操作できるような使い勝手の良さです。 文章で書いても伝わりにくいと思うのですが、個人的に良いと思うところは以下の通りです。 メニュー構成がシンプル 通信ログが1つのEventで完結しているので状況把握や切り分けが早い 各機能の設定方法の親和性が高いので抵抗感がない 契約内容が確認できる 以前はいくつかの機能の中には独特の設定方法があったのですが、徐々に「オブジェクトを組み合わせてルールを作り、そのActionを決める」設定方法に統一されてきた感じがあります。なので初めて使うセキュリティ機能やSD-WANの設定も直感でできてしまいます。 実際のお客様でも、操作概要を説明した後は我々のサポートがなくても一通りの設定ができてしまうケースも多くあります。 また、契約しているサービスの内容やSocketのシリアルNoなども一覧で見ることができ構成管理的なところもフォローしているので、管理資料の数が圧倒的に少なくなりました。以前はVisioでネットワーク構成図を作り、ExcelでFirewallの設定やルーティング情報、機器管理表を作成してコツコツ更新していましたが、そんな手間は一切なくなりました！ リニューアルの理由 話はそれましたが、今回のリニューアルは以下の課題をクリアする目的があったようです。 新しく追加されるダッシュボード系のサービスがすべて「Monitoring」に追加されて数が増えてきた 設定とモニタが別のタブにあったため、タブ間の行き来が多く発生していた 新サービスが追加される際、明確な配置基準がないため、見たいメニューやコンテンツを探すのに時間がかかっていた Catoでは新しいサービスが次から次へとリリースされるので、これまでのメニュー構成とのGAPが大きくなってきたのだと思われます。また新たなメニュー構成は、Catoの今後のサービス拡充の方向性に沿ったものであると想像できます。 旧ナビゲーションはいつまで使えるのか？ 今回のリニューアルは2024年9月のUpdate情報に掲載されました。我々としては、メニュー構成の変更により公開している操作手順やセミナー資料の更新が発生するのでリニューアルの時期を気にかけていたのですが、11月になってようやくリリース、その後徐々にお客様のアカウントにも切り替えのトルグスイッチが表示されてきたという経緯です。 また旧ナビゲーションの終了は、この先2ヶ月位という話です。なので早ければ2025年明けには「2025年2月×日で旧ナビゲーションは終了」という通知がくるかもしれません。最初は戸惑うかもしれませんが、早めに切り替えて慣れておいた方がよいでしょう。 変更点について それではリニューアルによってどう変わるのかをご紹介します。 まずメインメニューとも言える上部のタブ名が変わります。 ▼図1.従来のタブ   ▼図2.新しいタブ   並べてみると以下の通りです。6つのうち3つが変更になります。 Monitoring　⇒　 Home Network　⇒　Network Access　⇒　Access Security　⇒　Security Assets　⇒　 Resources Administration　⇒　 Account   各タブにあるメニュー数のBefore/Afterを見ると「Monitoringタブ」が大幅に減少して、その他のタブに移動しているのが分かります。 １．Monitoring/Homeタブ ２．Networkタブ ３．Accessタブ ４．Securityタブ ５．Assets/Resourcesタブ ６．Administration/Accountタブ 各サービスがどのタブに移動したのかは、 こちら のCatoのナレッジに記載があります。 この移動一覧を見ると、「Monitoringタブ」にあったネットワーク関連のダッシュボードは「Networkタブ」に、またセキュリティ関連のダッシュボードは「Securityタブ」に移動されています。 その他では、例えば特定のIPアドレスレンジを登録しておく IP Range は「Networkタブ」から「Resourcesタブ」に移動しています。 確かに「Resourcesタブ」にあって然るべきという納得感があります。 気になった点は、モバイルユーザーの接続制限を行う Device Posture が「Accessタブ」から「Resourcesタブ」に移動し、接続制限のルールを設定する「Client Connectivity Policy」はそのまま「Accessタブ」に残っているので、 Device Postureの一連の設定の際にはタブ間の移動が発生 してしまうこと位でしょうか。 目的のサービスがどこにあるのか迷った時には トグルスイッチをNew Navigationに切り替えて使っていると、目的のサービスが探せない事が何回もありました。 そんな時は、タブ列の左にある四角ボタンの「Account Menu」が役立ちました。これまで私はあまり使わなかったのですが、検索バーもあるので、サービス名が分かっていれば検索することで一発で辿り着きます！ さいごに CMAのような管理画面の使い勝手は、日々の運用では重要な要素だと考えます。 中にはいつまでたっても覚えにくいユーザー・インターフェースもありますが、当社のセミナーにご参加いただいたお客様からは「Catoはコンソールが分かり易い」という言葉をちょくちょくいただきます。またPoCでCMAの操作説明をさせていただく時にも「Firewallでルール作るみたいに・・・」とお伝えすれば「なるほど！」と理解してくれるケースが多くあります。 SCSKでは、デモセミナーやリモートハンズオンセミナーを開催していますので是非CMAの操作感を体験下さい！ 最後に！2024年12月現在CMAは日本語を含む10言語に対応しています。

どうも。みなさん re:Invent 2024 楽しんでますか? 寺内は東京にいます。 とはいえ、AWSからの大量のNews情報はキャッチできますので、見ていると興味深いキーワードが。 the next generation of Amazon SageMaker “ネクストジェネレーション” と聞くと、なんかワクワクしますよね。 ということで、詳しく見てみます。AWS発表のブログ記事は以下です。 Introducing the next generation of Amazon SageMaker - AWS Discover more about what's new at AWS with Introducing the next generation of Amazon SageMaker aws.amazon.com Amazon SageMakerは、データアナリストや機械学習モデル開発者のための統合開発環境(IDE)です。 機械学習モデルの開発は、大きく以下のステップを踏みます。 データ収集 → データの前処理 → 特徴量エンジニアリング → 学習(Training) → モデルテスト → モデルの評価 この一連の流れを、1つのコンソールの中ですべてを実施できることを目指しているのがAmazon SageMaker だといえます。 SageMakerリリース後、AWSではBedrockが出たり、Redshift Serverlessが出たりとAWSサービス周辺も急激に変化しています。そうした変化に合わせて、よりよい開発体験を提供するために、SageMakerの再構築を行うことにしたのだと推測できます。 この記事では、Amazon SageMaker Unified Studio を準備し、Jupyter Notebook で HELLO WORLD するところまでを記載します。 東京リージョンでも使えるとのこで、早速やってみましょう。 AWSマネジメントコンソールのサービス検索で “sagemaker” と入れると、あれ? 従来のSageMakerは、Amazon SageMaker AI と名称が変わり、次世代SageMakerは、Amazon SageMaker platform という名称のようです。 早速、Amazon SageMaker platform を選んでみましょう。 こちらの画面には、しっかり Amazon SageMaker Unified Studio と書いてありますね。 従来のSageMakerと同じく、まずはDomainを作るようです。作ってみましょう。 クイックセットアップでやってみます。 しかし、下の黄色いところに、適切なVPCを作ったほうがいいようなことが書いてありますので、既存のVPCではなく、Amazon SageMaker Unified Studio専用のVPCを作ることにします。 名前くらいしか入れることはないですね。作成を押すと、sagemaker_unified_studio_network_setup.yml というCloudFormationテンプレートが動きいろいろ作ります。ここでできたVPCを観察してみると、以下のような構造のようです。 一つのパブリックサブネットと、三つのプライベートサブネットがあります。 驚くのは、勝手に作られたエンドポイントの数です。 なんと28個! 利用料いくらかかるのでしょう。Redshift ServerlessやEMRなど、いらないのは、速攻で消したいところです。 再度、SageMakerのクイックセットアップに戻ると、作られたVPCの情報がすでに入力されています。その他、S3やBedrockなどの情報を確認し、ドメインの作成ボタンを押します。 終わると、以下のドメインへのログイン画面が出ます。 SSOは、この環境では使っていないので、AWS IAMでのサインインを選びます。 めでたく、Amazon SageMaker Unified Studioのホーム画面が出ました。 次に、プロジェクトを作成します。右側真ん中あたりにある緑色の「プロジェクトを作成」を押します。 プロジェクトの名前を入れて、プロジェクトの種類を選択します。ここでは、「データ分析とAI-MLモデルの開発」を選択します。 以下のように、CodeCommitやログの保存期間、SageMakerインスタンスが使うEBSボリュームサイズ、LakehouseやRedshift Serverlessの名称などを設定します。 こうして「プロジェクトを作成」ボタンを押すことで、作成処理が始まります。 これは10分ほどかかります。 無事終わると、以下のようにAmazon SageMaker Unified Studioのホーム画面の画面中央上部でプロジェクトが選択できるようになります。 これらのプロジェクトの作成で、少なくともS3とCodeCommitリポジトリが作成されます。確認してみましょう。 S3のバケットはこちら。 CodeCommitはこちら。 リポジトリの中身を見てみるといくつかファイルができています。 さて、SageMakerのホーム画面でプロジェクトを選択すると、以下のように作業の中心となるワークスペースが開きます。 中心にはCodeCommitの中身であるファイルが作られています。 ここにファイルを新規作成し、git commit して、push すれば、そのままCodeCommitリポジトリに入るのですから楽ちんです。 さて、左上に「Discover」「Build」「Governance」というメニューがあります。これらの中身は、それぞれ以下のようになっています。 Discoverの中身。 Buildの中身。 Governanceの中身。 データ解析系のメニュー、機械学習モデル開発のためのメニュー、ガバナンスのためのメニューと別れており、関連するサービスと密に連携が取れていることがわかります。 ここでは「Build」メニューから、JupyterLabを起動すると以下の画面になります。Python 3 のNotebookを作ってみます。 すると、わりとカッコいいNotebook画面がでました。ちょっとCloud 9っぽいというか、VS Codeっぽいというか。 ということで、Hello World、やっておきました。 左のツールバーで、Gitを選んで、CommitとPushをすれば、CodeCommitにしっかりと記録されます。ちょー簡単!   さて、生まれ変わったSageMaker Unified Studio 。全体的にAWSサービスのストレージおよびデータベースとの一体感が出て、使いやすくなっていそうです。 IICユーザでもIAMユーザでも使えるのがいいですね。 まずはやってみた、というレベルですが、データ分析の開発ワークスペースとして活用できればと思います。 ではまた。

みなさんこんにちは。 クラウド環境の利用が拡大する中で、最も重要な課題の一つがデータセキュリティです。クラウドには膨大なデータが保存されていますが、その中には機密情報や規制対象データが含まれていることも少なくありません。こうしたデータを適切に保護するために注目されているのが、DSPM（Data Security Posture Management）です。 本記事では、DSPMをこれから導入しようと考えている方に向けて、その基本的な考え方や導入メリットを解説します。   DSPMとは？ DSPM（Data Security Posture Management）は、クラウド環境に保存されたデータを中心に 可視化し、分類し、保護する ためのソリューションです。 従来のセキュリティ対策はインフラやネットワークが中心でしたが、DSPMはデータそのものに焦点を当てています。 クラウド環境でのデータ管理には以下のような課題があります。 機密情報や個人情報がどこに保存されているかわからない 不適切なアクセス設定によりデータが漏洩するリスク 法規制（例：GDPR、CCPA）への準拠状況が不明確 DSPMは、これらの課題を解決し、クラウド環境全体のデータセキュリティ態勢を最適化します。   DSPMの基本的な機能 DSPMが提供する主な機能を以下にまとめます。 データの可視化と分類 DSPMは、クラウド環境に保存されているデータを自動でスキャンし、どのデータがどこに保存されているかを可視化します。また、データをカテゴリ別に分類し、たとえば「機密データ」「公開データ」「個人情報」などを識別してラベリングします。 リスク評価 保存されたデータに関連するセキュリティリスクを特定します。たとえば、暗号化されていない機密データや、広範囲に公開されたデータを検出します。 コンプライアンス対応 GDPRやCCPAといった規制への準拠状況を自動的に評価し、必要な改善点を特定します。 不適切なアクセス設定の検出 データに対して不適切なアクセス権限や公開設定がされている場合、警告を発します。たとえば、「パブリックに公開されたS3バケット」を特定します。 修復の自動化 検出された問題について、適切な修正手順を提案し、自動で修復することが可能です。たとえば、公開設定をプライベートに変更するなどのアクションを実行します。 DLP機能の統合 一部のDSPMはDLP機能を持っており、データの流出につながる怪しい挙動を検出、防御します。   DSPM導入のメリット データ漏洩リスクの大幅な軽減 データがどこに保存され、誰がアクセスできるのかを把握することで、誤った設定や不適切なアクセスによる漏洩リスクを低減します。 運用効率の向上 従来は手作業で行っていたデータ分類やセキュリティ評価を自動化することで、運用担当者の負担を大幅に軽減できます。 コンプライアンス対応の強化 厳しい規制に準拠するためには、データ管理が欠かせません。DSPMは規制の要件を自動でチェックし、適切な対応をサポートします。 データセキュリティの統一的な管理 サードパーティ製のDSPMソリューションを利用することで、AWS、Azure、GCPなど複数のクラウドを利用している場合でも、統一的にデータを管理できます。   DSPM導入時に注意すべきポイント クラウド全体のデータ構造を把握する DSPMを効果的に活用するには、導入前に自社のクラウド環境でどのようなデータがどこに保存されているのか、大まかに把握しておくことが重要です。これはDSPMも完璧ではなく、検出されたデータの妥当性を確認する必要があるためです。 データ分類ポリシーの策定 DSPMはデータを自動で分類しますが、その分類基準は組織ごとに異なってきます。自社のセキュリティポリシーやビジネス要件に合わせた分類ルールを明確にしましょう。 運用体制の整備 監視対象が機密情報になるので、通常のインシデント対応ではなく、緊急度を高めたエスカレーションフロー等、特別な運用ルールを準備しておくことも検討すべきです。   DSPM導入のプロセス 現状分析 まず、現在のデータ管理状況を把握します。クラウド上のデータ量やリスクの高い領域を明確化しましょう。 要件定義 DSPMに求める要件を具体的に定義します。たとえば、「特定の規制への準拠」や「暗号化されていないデータの自動検出」、「DLP機能有無」などです。また、アラート通知頻度や通知方法など、運用要件の具体化が重要です。 ツール選定 DSPMツールは各社から提供されていますが、機能や対応クラウドが異なります。まず、自社のクラウド環境（AWS、Azure、GCPなど）に対応しているかを確認しましょう。また、必要な機能（DLP機能の有無、リアルタイム監視、コンプライアンス対応など）が備わっているかを比較検討します。 導入と設定 選定したDSPMツールを導入し、自社のデータ分類ルールやセキュリティポリシーに基づいて設定を行います。この際、クラウド環境内の各リソース（ストレージ、データベース、コンテナなど）を対象に、どのようなデータが保存されているかを整理し、適切な保護レベルを設定します。 運用開始と最適化 実際の運用を開始し、DSPMの有効性を検証します。検出されたアラートの精度や対応の迅速さを評価し、必要に応じて監視ポリシーのチューニングや体制、運用ルールの見直しを行います。   まとめ DSPMは、クラウド環境に保存されたデータを適切に管理し、セキュリティを強化するための重要なソリューションです。特に、どのデータがどこに保存され、どのように保護されているのかを可視化する機能は、データセキュリティ対策の基本といえるでしょう。 一部のDSPMはDLP機能も統合しており、データ漏洩防止の面でも大きな効果を発揮します。これから導入を検討している方は、自社の課題を明確化し、適切なツールを選定することで、効果的なデータセキュリティ対策を実現してください。

クラウドの普及が進む中、セキュリティ対策の重要性が高まっています。その中でも特に課題として挙げられるのが、クラウド環境における権限管理の複雑化です。多くの企業で、権限の設定ミスや適切でないアクセス許可が原因でセキュリティリスクが高まっています。 そこで注目されているのがCIEM（Cloud Infrastructure Entitlement Management）です。本記事では、CIEMの基本的な役割や導入のメリット、実際に導入する際のポイントを解説します。   CIEMとは？ CIEM（Cloud Infrastructure Entitlement Management）は、クラウド環境におけるアクセス権限や認証情報を管理するためのソリューションです。従来のアクセス管理は、主にオンプレミスの環境を対象に設計されていました。しかし、クラウド特有のスケーラビリティや多様性に対応するには、新しいアプローチが必要です。CIEMは、次のような課題に対応するために設計されています。 誰がどのリソースにアクセスできるのかが不明確 不必要に広範な権限が与えられたユーザーやロールの存在 アクセス権限の設定変更や更新が正しく行われていない こういった課題の解消は、昨今よく聞くようになったゼロトラストへの対策としても有効なため、CIEMは今後、更に重要度が増すソリューションとなることが想定されます。   CIEMの基本的な機能 CIEMが提供する主な機能を以下にまとめます。 アクセス権限の可視化 クラウド環境内の全ユーザー、ロール、サービスアカウントに対して、どのリソースにどのような権限が与えられているのかを可視化します。 過剰権限の検出 必要以上に広範な権限が与えられているユーザーやロールを特定し、リスクを低減します。たとえば、「Administrator」のような特権が不要に設定されている場合、警告を出します。 ポリシー違反の検出 組織のセキュリティポリシーやクラウドベンダーの推奨設定に違反するアクセス設定を検出します。 最小権限の推奨 リソースに必要な最低限の権限を自動的に提案します。 自動修復機能 検出した問題を手動または自動で修復できます。たとえば、不要なアクセス権を削除するなどの操作を効率的に実行できます。   CIEM導入のメリット CIEMを導入することのメリットを以下にまとめます。 セキュリティリスクの大幅な低減 クラウド環境における不適切なアクセス権限は、情報漏洩や不正アクセスの原因となります。CIEMを導入することで、権限設定ミスを自動的に検出し、リスクを軽減できます。 コンプライアンス対応の効率化 多くの業界規制（例：GDPRやISO 27001）では、アクセス権限の適切な管理が求められています。CIEMは、これらの規制に対応するための自動化ツールとして活用できます。 運用負担の軽減 手動でのアクセス権限の管理は時間と労力がかかります。CIEMは、アクセス権限の可視化や設定変更を効率的に行うため、運用負担を大幅に軽減します。 マルチクラウド環境の一元管理 AWS、Azure、GCPなど複数のクラウドを利用している場合でも、サードパーティ製のCIEMソリューションを使えば一元的にアクセス権限を管理することが可能です。   CIEM導入時に注意すべきポイント 自社のセキュリティポリシーに基づいた設計 CIEMを導入する前に、自社のセキュリティポリシーを明確に定義しておくことが重要です。たとえば、「どのようなユーザーにどのような権限を与えるべきか」という基準を具体化しておくことで、CIEMを効果的に活用できます。 運用ルールの明確化 CIEMは多くのプロセスを自動化できますが、全てを自動化すると逆に問題が発生する場合があります。たとえば、重要な権限を誤って削除してしまうと、業務に支障をきたす可能性があります。人の監視や承認プロセスを組み合わせて適切に運用できる事前のルール作りが重要です。 運用体制の整備 CIEMを導入するだけでなく、定期的な監視や更新を行う体制を整える必要があります。担当者の権限管理に関する基礎的な知識のインプットや、一度作った運用ルールの見直しを運用しながら行うことが重要です。   CIEM導入の具体的なプロセス 現状分析 まず、現在のクラウド環境のアクセス権限設定を把握します。どのような権限が誰に与えられているのかを明確化しましょう。 ツール選定 CIEMツールは、機能や対応するクラウドプラットフォームによって異なります。自社のニーズに合ったツールを選ぶことが成功の鍵です。 導入と設定のチューニング CIEMツールを導入し、セキュリティポリシーに基づいた設定を行います。特にCIEMはアラート量が多くなりがちなソリューションのため、設定が適切でない場合、過検知や誤検知が多発し、未解決アラートが山積するという状態になります。運用しながら適切に監視設定のチューニングを行うことが大切です。   まとめ CIEMは、クラウド環境の権限管理を効率化し、セキュリティを強化するために必須となるソリューションです。特に、複雑化するクラウド環境において、誰がどのリソースにアクセスできるのかを明確にしておくことは、セキュリティ対策を行う上でのベースになります。 CIEMの導入を検討している方は、自社の課題やセキュリティポリシーを整理し、最適なツールを選ぶことから始めてみてください。

クラウド環境が普及する中で、アプリケーションやコンテナ、仮想マシンなどのワークロードをどのように保護するかが重要な課題となっています。こうした課題を解決するために注目されているのが、CWPP（Cloud Workload Protection Platform）です。 CWPPは、クラウド上の動的なワークロードを保護するためのセキュリティプラットフォームであり、特にクラウドネイティブな環境で効果を発揮します。本記事では、CWPPの基本的な概要、導入メリット、活用方法について解説します。   CWPPとは？ CWPP（Cloud Workload Protection Platform）は、クラウド環境内のワークロード（仮想マシン、コンテナ、サーバレス機能など）を保護するためのセキュリティソリューションです。従来型のセキュリティ対策がオンプレミス環境を対象としていたのに対し、CWPPは次のようなクラウド特有の課題を解決します。 ワークロードが動的にスケールし、従来型のセキュリティソリューションでは対応できない コンテナやサーバレスなど、新しい技術への対応が求められる マルチクラウド環境で一元的に保護を行う必要がある CWPPは、これらのニーズに応え、クラウド上のワークロードを包括的に保護します。   CWPPの基本的な機能 CWPPが提供する主な機能を以下にまとめます。 脆弱性スキャン アプリケーションやコンテナイメージをスキャンし、既知の脆弱性を特定します。これにより、本番環境に脆弱性のあるイメージを展開するリスクを未然に防ぎます。 ランタイム保護 ワークロードの実行時に異常な動作や不審なアクティビティを検出し、リアルタイムで保護します。たとえば、許可されていないプロセスの実行や不審なネットワーク通信をブロックします。 ファイルとデータ保護 ワークロード内部のデータやファイルの改ざんを検出し、必要に応じてアラートを発します。 ネットワークセキュリティ ワークロード間の通信を監視し、異常なトラフィックを検出します。また、ファイアウォールルールを適切に設定するための推奨事項も提供します。 コンプライアンス対応 PCI DSSやHIPAAなど、業界規制やセキュリティフレームワークに準拠しているかを評価し、不足している項目を特定します。 自動化とインテグレーション CI/CDパイプラインに統合することで、セキュリティチェックを開発プロセスに組み込むことが可能です。これにより、コードの変更が行われるたびに自動でセキュリティ検査が実施されるため、開発者は早い段階で潜在的な脆弱性を発見し、修正できます。さらに、CI/CDパイプライン内でテストやセキュリティスキャンを行うことで、セキュリティ基準を満たしていないコードを本番環境にデプロイすることを防ぐことができます。   CWPP導入のメリット リアルタイムでのセキュリティ強化 CWPPはワークロードのランタイム中に発生する脅威をリアルタイムで検出し、迅速に対応することで、攻撃を未然に防ぎます。 脆弱性管理の効率化 開発から本番環境までのプロセスで脆弱性を早期に特定できるため、セキュリティ対応の効率が向上します。特に、CI/CDパイプラインに統合することで、開発の初期段階から脆弱性をチェックし、修正することで、後工程での手戻りを減らし、開発全体の効率化にもつながります。 クラウドネイティブ技術への対応 コンテナやサーバレスといったクラウドネイティブ技術を安全に活用するためのセキュリティ基盤を提供します。これにより、新しい技術を取り入れた場合でも、セキュリティリスクを最小限に抑えつつ、クラウドの柔軟性を活かすことができます。 運用負担の軽減 脆弱性スキャンやコンプライアンスチェックの自動化により、運用担当者の作業負荷が大幅に軽減されます。 マルチクラウド環境の一元管理 サードパーティ製のCWPPソリューションを利用すれば、AWS、Azure、GCPなど、複数のクラウドを利用している場合でも、一元的にワークロードを管理し、保護することが可能です。また、複数のクラウドを利用する企業にとって、統一されたセキュリティポリシーの適用が容易になり、全体的なセキュリティの統制が強化されます。   CWPP導入のプロセス 現状分析 まず、現在のワークロード環境を把握し、どのようなリスクや課題があるかを明確にします。クラウド環境におけるワークロードの種類（仮想マシン、コンテナ、サーバレスなど）を洗い出し、それぞれのワークロードがどのようなセキュリティリスクに直面しているかを分析します。また、既存のセキュリティ対策の効果を評価し、CWPP導入によってどの部分を強化するべきかを明確にすることが重要です。 ツール選定 自社環境に最適なCWPPツールを選定します。AWSやAzureなど特定のクラウドに最適化されたツールもあれば、マルチクラウド対応の汎用ツールもあります。ツール選定時には、クラウド環境との互換性、主要な機能（脆弱性管理、ランタイム保護、コンプライアンス対応など）、および自動化のレベルを比較検討します。また、ツールが自社のセキュリティポリシーに適合するか、操作性が良いか、導入後のサポート体制が充実しているかなども重要な判断基準です。 導入と設定 選定したツールを導入し、自社のワークロードに合わせた設定を行います。各ワークロードの種類（仮想マシン、コンテナ、サーバレスなど）に応じて、適切な保護ポリシーを設定します。例えば、コンテナに対しては脆弱性スキャンの頻度やランタイム保護の詳細設定を行い、仮想マシンにはネットワークモニタリングの設定を強化します。初期設定後には、試験運用を行い、設定が適切に機能しているかを確認します。 運用と最適化 導入直後は、脆弱性スキャンやランタイム保護の結果を細かく監視し、ツールの精度やアラートの有効性を評価します。運用中に発見された問題や課題に基づいて、設定を調整し、最適化を行うサイクルを繰り返します。定期的なレポート作成やレビューを通じて、セキュリティ態勢が維持・向上されているかを確認し、必要に応じて運用ルールや体制の見直しを行います。   まとめ CWPPは、クラウド環境におけるワークロードを包括的に保護するための強力なツールです。特に、クラウドネイティブ技術を活用する企業にとっては、セキュリティ強化と効率化の両方を実現できるソリューションと言えますので、積極的なCWPPの活用をおすすめします。

みなさんこんにちは。 近年、クラウドサービスを利用する企業が急増しています。その一方で、クラウド環境におけるセキュリティ対策が課題となるケースも増えています。そこで注目されているのがCSPM（Cloud Security Posture Management）というソリューションです。本記事では、CSPMをこれから導入しようと検討中の方に向けて、その概要とメリット、導入のポイントを詳しく解説します。   CSPMとは？ CSPMは、「クラウドセキュリティの態勢管理」を意味するツールで、クラウド環境における設定やポリシーを監視・評価し、潜在的なセキュリティリスクを特定するためのソリューションです。 クラウドの利用が広がる中で、適切なセキュリティ設定を維持することは非常に重要です。たとえば、誤ったアクセス権限の設定や不要なポートの開放といった設定ミスが、データ漏洩や不正アクセスの原因となることがあります。CSPMはこうしたリスクを自動的に検知し、修正するための支援を行います。   CSPMの基本的な機能 CSPMが提供する基本的な機能には、次のようなものがあります。 リソースの可視化 クラウド環境内のリソース（仮想マシン、データベース、ストレージなど）を一元的に可視化します。これにより、どのような設定や構成がされているのかを確認できます。 セキュリティ設定の評価 クラウドベンダーや業界標準（例：CISベンチマーク）に基づいて設定をチェックし、問題があれば警告を出します。 コンプライアンス対応 GDPRやHIPAAなどの規制に準拠しているかを自動的に評価し、不足している箇所を特定します。 リスクの優先順位付け リスクの重大性を評価し、優先的に対応すべき項目を特定します。これにより、限られたリソースで効率的にセキュリティ対策が可能です。 修復の自動化 発見した問題に対して、自動または手動で修正手順を実行できます。たとえば、不必要に開放されたポートは自動的に閉じるといった操作です。   CSPMの導入メリット CSPMを導入することで得られる主なメリットをいくつか挙げてみましょう。 セキュリティリスクの低減 クラウド環境では、設定ミスや人為的なエラーが主なセキュリティリスクとなります。CSPMは、設定ミスを迅速に特定・修正できるため、リスクを大幅に低減します。 可視性の向上 クラウド環境は複雑で、リソースがどこにあり、どのような状態なのかを把握するのは困難です。CSPMはこれらを統一的に管理するため、現状を正確に把握できます。 コンプライアンスの効率的な対応 手動でコンプライアンス対応を行うのは時間がかかり、ミスが発生しやすいものです。CSPMの自動チェック機能を利用すれば、効率的かつ確実にコンプライアンス要件を満たすことが可能です。   導入時に注意すべきポイント CSPMを導入する際には、以下の点を考慮することが重要です。 自社環境に合ったCSPMツールの選定 CSPMツールは多種多様です。自社のクラウド利用状況やセキュリティポリシーに合ったツールを選ぶことが大切です。たとえば、AWSのみを使用している場合と、AWS・Azure・GCPのマルチクラウド環境を使用している場合では、適切なツールが異なります。 運用体制の構築 CSPMツールは導入しただけでは十分に機能しません。定期的なモニタリングや、検出された問題への迅速な対応を行う体制を整える必要があります。 ユーザーへの教育 CSPMは技術的なツールですが、最終的には運用する人が重要です。設定の正しい理解やツールの操作方法について、担当者を教育することが必要です。   具体的な導入プロセス 最後に、CSPM導入の一般的なプロセスを簡単に紹介します。 現状分析 現在のクラウド環境の状況を把握し、どのようなリスクや課題があるのかを明確化します。 要件定義 CSPMツールに求める要件を明確にします（例：対応するクラウドプラットフォーム、コンプライアンス、運用要件など）。 ツール選定と導入 市場のツールを比較し、自社に最適なものを導入します。ツールの選定においては、事前に整理した要件を機能と運用の両面で満たすことができるかを、PoC等を通じて確認することが重要です。 運用開始と最適化 導入後は、実際の運用を通じてツールの有効性を検証し、必要に応じて運用フローを改善します。   まとめ CSPMは、クラウド環境のセキュリティを強化するための強力なソリューションです。設定ミスや人為的なエラーを防ぎ、クラウド利用を安心して進めるためには欠かせないものになっています。導入にあたっては、自社の課題や目指すべきゴールを明確にし、最適なツール選定と、ツール導入後の運用の準備が成功のカギです。 クラウドのセキュリティ対策を一歩進めたい方は、ぜひCSPMの導入を検討してみてください。

本記事は 新人ブログマラソン2024 の記事です 。 皆さんこんにちは！入社して間もない新米エンジニアの佐々木です。 最近、実務でAWSやSnowflakeを用いたデータ活用基盤の構築に携わっており、日々新しい技術に触れる毎日です。中でも特に興味を持ったのが、 SnowflakeのCortexAI という機能です。 どうやらCortexAIという機能を利用すると「データ分析の自動化」や「機械学習モデルの簡単な構築」を実現できるそうです。 一方で、やはり正直最初は半信半疑でした。一体どれほど簡単に使えるのか、実際に試してみなければ！ しかし、いざ試そうとしたところ「何から手をつければいいのか？」と戸惑うことばかり、、、 そこで、Snowflakeが提供する公式チュートリアルに助けを求めることにしました。 本記事では、私がCortexAIの公式チュートリアルを実践する中で気づいたこと、そしてそこから得られた学びについてお話していきます。これからSnowflakeやCortexAIを触れようと考えている方の参考になれば幸いです！ Snowflakeとは Snowflakeは、 Snowflake社が提供するクラウドデータプラットフォーム です。 データウェアハウス、セキュリティ、ガバナンス、可用性、データレジリエンスなど、データ分析に必要な機能をすべて網羅した フルマネージドサービス なんです。 そんなSnowflakeが最近着目しているキーワードとして 「AIデータクラウド」 があります。 AIデータクラウドとは、データウェアハウスとAI/ML機能を統合したクラウドベースのプラットフォームのことを指します。 Snowflake社はこのAIデータクラウドを通して、 データサイエンスと機械学習を民主化し、あらゆる規模の組織がデータドリブンな意思決定を容易に行えるようにする ことを目指しています。 Snowflakeクラウドデータプラットフォーム | Snowflake AIデータクラウド CortexAIとは Cortex AIは、 Snowflakeが提供する機械学習プラットフォーム です。 Snowflakeのデータウェアハウス上で直接機械学習モデルの構築、トレーニング、デプロイをできるという特徴があります。また、難しいプログラミングや専門知識がなくても、ある程度の分析や予測が比較的簡単にできるという特徴もあります。 Snowflake Cortex for Generative AI 公式チュートリアルの概要 本記事で取り扱う公式チュートリアルは以下の通りです！ Build A Document Search Assistant using Vector Embeddings in Cortex AI このチュートリアルでは、 Snowflake Cortex AIのベクトル埋め込み機能を利用して、ドキュメント検索アシスタントを構築 します。因みに文書検索アシスタントとは、大量のドキュメントデータの中からユーザーが求める情報を見つけ出すのを支援するツールのことを指します。 チュートリアル全体の手順は以下の大きく3つの流れです。 データ準備と前処理: 検索対象となるドキュメントデータの準備、データベース、スキーマ、ウェアハウスの作成、ドキュメント分割関数の作成を行います。 ベクターストアの構築: CortexAIを用いて各ドキュメントを数値ベクトルとして表現し、ベクターストアの作成を行います。 チャットUIおよびロジック構築:  前工程で作成したベクターストアを利用して、誰でも簡単に文書検索ができるように、SnowflakeのStreamlitを使用して簡単なフロントエンドの作成を行います。 実際に挑戦してみた！！ データ準備と前処理 データ準備 まず初めに、今回検索対象となるドキュメントデータを準備します。 今回はチュートリアルで配布されている以下の4つの英文ファイルを使用しました。これらのドキュメントは様々な自転車に関する情報が記述されているPDFファイルです。 Mondracer Infant Bike Premium Bycycle User Guide Ski Boots TDBootz Special The Ultimate Downhill Bike データベース、スキーマ、ウェアハウスの作成 次に今回使用するデータベース、スキーマ、ウェアハウスを作成していきます。 そのために、Snowflakeのワークシートを新規で作成し、以下のコードを実行します。 CREATE DATABASE CC_QUICKSTART_CORTEX_DOCS; --create databse CREATE SCHEMA DATA; --create schema USE CC_QUICKSTART_CORTEX_DOCS.DATA; CREATE OR REPLACE WAREHOUSE XS_WH WAREHOUSE_SIZE = XSMALL; --create warehouse USE WAREHOUSE XS_WH; これにより、データベース、スキーマ、ウェアハウスの大枠の準備ができました！ ドキュメント分割関数の作成 次にドキュメントデータを読み取り、それらをチャンクに分割するためのユーザー定義関数（pdf_text_chunker）を作成します。 ここでユーザー定義関数とは、SQLクエリ内で呼び出せる、ユーザーが作成した再利用可能なコードブロックのことを指します。 またチャンク分割とは、Snowflakeがデータを効率的に管理・処理するために、自動的にデータを小さなブロックに分割する仕組みのことを指します。これによって、大量のドキュメントデータでも高速にアクセス・検索することが可能になるというメリットがあります！ 関数を作成するために、Snowflakeのワークシートで以下のコードを実行します。 create or replace function pdf_text_chunker ( file_url string ) returns table ( chunk varchar ) language python runtime_version = '3.9' handler = 'pdf_text_chunker' packages = ( 'snowflake-snowpark-python' , 'PyPDF2' , 'langchain' ) as $$ from snowflake . snowpark . types import StringType , StructField , StructType from langchain . text_splitter import RecursiveCharacterTextSplitter from snowflake . snowpark . files import SnowflakeFile import PyPDF2 , io import logging import pandas as pd class pdf_text_chunker : def read_pdf ( self , file_url : str ) -> str : logger = logging . getLogger ( "udf_logger" ) logger . info ( f "Opening file {file_url}" ) with SnowflakeFile . open ( file_url , 'rb' ) as f : buffer = io . BytesIO ( f . readall ()) reader = PyPDF2 . PdfReader ( buffer ) text = "" for page in reader . pages : try : text += page . extract_text (). replace ( '\n' , ' ' ). replace ( '\0' , ' ' ) except : text = "Unable to Extract" logger . warn ( f "Unable to extract from file {file_url}, page {page}" ) return text def process ( self , file_url : str ): text = self . read_pdf ( file_url ) text_splitter = RecursiveCharacterTextSplitter ( chunk_size = 4000 , #Adjust this as you see fit chunk_overlap = 400 , #This let's text have some form of overlap. Useful for keeping chunks contextual length_function = len ) chunks = text_splitter . split_text ( text ) df = pd . DataFrame ( chunks , columns =[ 'chunks' ]) yield from df . itertuples ( index = False , name = None ) $$ ; 上記のコードについて補足説明をします。 6行目： packages = ( 'snowflake-snowpark-python' , 'PyPDF2' , 'langchain' ) 必要なPythonパッケージを指定しています。snowflake-snowpark-pythonはPythonコードの埋め込み、PyPDF2でPDFファイルの読み込み、langchainでテキストの分割処理に利用します。 18行目～35行目： def read_pdf ( self , file_url : str ) -> str : PDFファイルの読み込みをするための関数です。ページごとにテキストを抽出し、改行文字やNULL文字をスペースに置換して連結した文字列を返します。 37行目～50行目： def process ( self , file_url : str ): テキストを指定されたサイズに分割するための関数です。今回のコードではチャンクサイズを4000文字、チャンク間のオーバーラップを400文字に設定しています。 これにより、ドキュメントを分割するための関数ができました！ ドキュメントアップロード用ステージの作成 次にドキュメントをアップロードするステージを作成します。 そのために、ワークシートで以下のコードを実行します。 create or replace stage docs ENCRYPTION = ( TYPE = 'SNOWFLAKE_SSE' ) DIRECTORY = ( ENABLE = true ); その後、作成したDOCSステージに準備した4つのドキュメントデータを以下のようにアップロードします。 以上でデータ準備および前処理は完了です！！ ベクターストアの構築 次にベクターストアを構築していきます。 ベクターストアとは、 文書のベクトル表現（数値ベクトル）を保存するデータベース のことを指します。 これにより、従来のテキスト検索では難しい「意味的な検索」についても、文書間の意味の類似度を計算することで実現することができるようです！ テーブルの作成 まず初めに、各ドキュメントのチャンクとベクトルを保存するためのテーブル（DOCS_CHUNKS_TABLE）を作成するために、以下のコードを実行します。 create or replace TABLE DOCS_CHUNKS_TABLE ( RELATIVE_PATH VARCHAR ( 16777216 ), -- Relative path to the PDF file SIZE NUMBER ( 38 , 0 ), -- Size of the PDF FILE_URL VARCHAR ( 16777216 ), -- URL for the PDF SCOPED_FILE_URL VARCHAR ( 16777216 ), -- Scoped url ( you can choose which one to keep depending on your use case ) CHUNK VARCHAR ( 16777216 ), -- Piece of text CHUNK_VEC VECTOR ( FLOAT , 768 ) ); -- Embedding using the VECTOR data type 上記で作成したテーブルのCHUNKカラムにドキュメントのチャンクが、CHUNK_VECカラムにチャンクから計算されたベクトル値が格納されます。 テーブルへのデータ挿入 次に、作成したドキュメント分割関数（pdf_text_chunker）を利用して、ドキュメントを処理し、チャンクを抽出します。そして抽出したチャンクからベクトル値を計算し、テーブル（DOCS_CHUNKS_TABLE）にそれらの情報を挿入します。 insert into docs_chunks_table ( relative_path , size , file_url , scoped_file_url , chunk , chunk_vec ) select relative_path , size , file_url , build_scoped_file_url ( @docs , relative_path ) as scoped_file_url , func . chunk as chunk , SNOWFLAKE . CORTEX . EMBED_TEXT_768 ( 'e5-base-v2' , chunk ) as chunk_vec from directory ( @docs ), TABLE ( pdf_text_chunker ( build_scoped_file_url ( @docs , relative_path ))) as func ; 上記のコードについて補足説明をします。 8行目： SNOWFLAKE . CORTEX . EMBED_TEXT_768 ( 'e5-base-v2' , chunk ) as chunk_vec SnowflakeのCortex機能を使用して、チャンクのベクトル値を生成します。様々あるモデルの内、今回はe5-base-v2というモデルを使用してベクトル値を生成しています。 11行目： TABLE ( pdf_text_chunker ( build_scoped_file_url ( @docs , relative_path ))) as func ; build_scoped_file_url ( @docs , relative_path ) では、各ドキュメントの相対パス（relative_path）とステージパス（@docs）を組み合わせてSnowflake内で一意に参照できるURLを生成しています。 その後、生成したURLをもとに作成した関数（pdf_text_chunker）でドキュメントをチャンクに分割し、戻り値をfuncというエイリアスで参照できるようにしている形です。 これで、チャンクとベクトル値を含むベクターストアを作成することができました！ チャットUIおよびロジックの構築 最後に、作成したベクターストアを利用して、誰でも簡単に文書検索ができるように、SnowflakeのStreamlitを使用して単純なフロントエンドを作成していきます。 具体的には、SnowflakeのCortexとStreamlitを使って、ユーザーがアップロードしたドキュメントをコンテキストとして利用（RAG）し、大規模言語モデル（LLM）で質問に答えるアプリケーションを作成します。 Streamlitとは、 カスタムWebアプリを簡単に素早く構築することができるオープンソースのPythonライブラリ です。 さらにStreamlitを使用することで、アプリ実行を同じアカウント内の他のユーザーと共有することができ、データの安全性と保護が維持されるというメリットがあります。 Streamlit構築 早速、Streamlitで以下のようにコードを変更します。 import streamlit as st # Import python packages from snowflake . snowpark . context import get_active_session session = get_active_session () # Get the current credentials import pandas as pd pd . set_option ( "max_colwidth" , None ) num_chunks = 3 # Num-chunks provided as context. Play with this to check how it affects your accuracy def create_prompt ( myquestion , rag ): if rag == 1 : cmd = """ with results as (SELECT RELATIVE_PATH, VECTOR_COSINE_SIMILARITY(docs_chunks_table.chunk_vec, SNOWFLAKE.CORTEX.EMBED_TEXT_768('e5-base-v2', ?)) as similarity, chunk from docs_chunks_table order by similarity desc limit ?) select chunk, relative_path from results """ df_context = session . sql ( cmd , params =[ myquestion , num_chunks ]). to_pandas () context_lenght = len ( df_context ) - 1 prompt_context = "" for i in range ( 0 , context_lenght ): prompt_context += df_context . _get_value ( i , 'CHUNK' ) prompt_context = prompt_context . replace ( "'" , "" ) relative_path = df_context . _get_value ( 0 , 'RELATIVE_PATH' ) prompt = f """ 'You are an expert assistance extracting information from context provided. Answer the question based on the context. Be concise and do not hallucinate. If you don´t have the information just say so. Context: {prompt_context} Question: {myquestion} Answer: ' """ cmd2 = f "select GET_PRESIGNED_URL(@docs, '{relative_path}', 360) as URL_LINK from directory(@docs)" df_url_link = session . sql ( cmd2 ). to_pandas () url_link = df_url_link . _get_value ( 0 , 'URL_LINK' ) else : prompt = f """ 'Question: {myquestion} Answer: ' """ url_link = "None" relative_path = "None" return prompt , url_link , relative_path def complete ( myquestion , model_name , rag = 1 ): prompt , url_link , relative_path = create_prompt ( myquestion , rag ) cmd = f """ select SNOWFLAKE.CORTEX.COMPLETE(?,?) as response """ df_response = session . sql ( cmd , params =[ model_name , prompt ]). collect () return df_response , url_link , relative_path def display_response ( question , model , rag = 0 ): response , url_link , relative_path = complete ( question , model , rag ) res_text = response [ 0 ]. RESPONSE st . markdown ( res_text ) if rag == 1 : display_url = f "Link to [{relative_path}]({url_link}) that may be useful" st . markdown ( display_url ) #Main code st . title ( "Asking Questions to Your Own Documents with Snowflake Cortex:" ) st . write ( """You can ask questions and decide if you want to use your documents for context or allow the model to create their own response.""" ) st . write ( "This is the list of documents you already have:" ) docs_available = session . sql ( "ls @docs" ). collect () list_docs = [] for doc in docs_available : list_docs . append ( doc [ "name" ]) st . dataframe ( list_docs ) #Here you can choose what LLM to use. Please note that they will have different cost & performance model = st . sidebar . selectbox ( 'Select your model:' ,( 'mixtral-8x7b' , 'snowflake-arctic' , 'mistral-large' , 'llama3-8b' , 'llama3-70b' , 'reka-flash' , 'mistral-7b' , 'llama2-70b-chat' , 'gemma-7b' )) question = st . text_input ( "Enter question" , placeholder = "Is there any special lubricant to be used with the premium bike?" , label_visibility = "collapsed" ) rag = st . sidebar . checkbox ( 'Use your own documents as context?' ) print ( rag ) if rag : use_rag = 1 else : use_rag = 0 if question : display_response ( question , model , use_rag ) 上記のコードについて補足説明をします。 10行目～59行目： def create_prompt ( myquestion , rag ): LLMへのプロンプトを作成する関数を定義しています。 特にここではRAGの有無を検証するために、変数ragの値を切り替えることでRAGを利用するかしないかを簡単に選択できるようにしています。rag=1の場合は、ユーザーが自身のドキュメントをコンテキストとして使用し、質問に対して類似度の高いチャンクを検索し、それらを追加した形でプロンプトを作成しています。一方でrag=0の場合は、ドキュメントをコンテキストとして使用せず、質問に回答するシンプルなプロンプトを作成しています。 61行目～69行目： def complete ( myquestion , model_name , rag = 1 ): LLMを使用して質問に回答する関数を定義しています。 SnowflakeのSNOWFLAKE.CORTEX.COMPLETE関数を使用して、指定されたLLMモデルとプロンプトを使用して、テキストの生成を行います。 71行目～77行目： def display_response ( question , model , rag = 0 ): LLMからの応答とドキュメントへのリンク（ rag == 1 の場合）をStreamlitで表示する関数を定義しています。 81行目～114行目： メインのコードです。ここでは以下の処理を行っています。 Streamlitアプリケーションのタイトルと説明を表示 ユーザーがアップロードしたドキュメントの一覧を表示 LLMモデルを選択できるセレクトボックスをサイドバーに表示 質問を入力できるテキストボックスを表示 ドキュメントをコンテキストとして使用するかを選択できるチェックボックスをサイドバーに表示 質問が入力された場合、 display_response 関数を呼び出して回答を表示 上記のコードを実行することで無事アプリが表示されました！ 検証 ここでRAGを利用した場合と、利用しない場合とで回答にどのような違いがあるのかを確認してみます。 そこで「What is the temperature to store the ski boots?（スキーブーツを保管する温度はどれくらいですか？）」という質問をしてみたいと思います。 まずはRAGを利用した場合の回答です。 上記の回答を日本語訳すると、 TDBootzスキーブーツを保管する理想的な温度は摂氏15度です。 参考になる可能性のある資料へのリンク：Ski_Boots_TDBootz_Special.pdf 上記から分かるように、RAGを利用すると精度および具体性の高い回答をしていることが分かります。これは、LLMのテキスト生成に信頼性の高い外部情報（今回はドキュメントデータ）を組み合わせているからだと言えます。   次にRAGを利用しなかった場合の回答です。 上記の回答を日本語訳すると、 スキーブーツは、摂氏7～24度（華氏45～75度）の涼しく乾燥した場所に保管する必要があります。極端に高温または低温の環境での保管は避けてください。これにより、素材が損傷し、ゲレンデでの性能に影響を与える可能性があります。また、カビや mildew（かびの一種）の発生を防ぐために、保管前にスキーブーツを完全に清掃して乾燥させることも良いでしょう。 上記から分かるように、RAGを利用しないと具体性に欠ける一般的な回答しかできていないことが分かります。これは、LLMが内部知識のみを利用し、事前に学習済みのデータに基づいて回答を生成するからだと言えます。 まとめ 本記事では、Snowflakeの公式チュートリアルを実践することで、CortexAIの使い方や利便性について確認することができました。 特にチュートリアルを通して感じたCortexAIの魅力的ポイントを3つ挙げてみました！ シームレスなSnowflake連携 : Snowflakeデータウェアハウスに直接統合されており、データの移動や変換が不要となる。これにより、Snowflake内のデータに対して直接機械学習モデルを構築・実行でき、データサイエンスワークフローがシームレスになり、開発効率が劇的に向上する 高度な埋め込みベクトル機能 : テキストデータの埋め込みベクトル生成をスムーズに行えるため、セマンティック検索や類似テキスト検索といった高度な機能を容易に実装できる 様々なLLMモデルへの対応 : 複数のLLMモデルに対応しているため、プロジェクトのニーズやコストに合わせて最適なモデルを選択できる このような魅力的ポイントを持つCortexAIは、様々なビジネス課題への応用が期待でき、今後ますます注目を集める技術だと思います。 ぜひ、皆さんもCortexAIを試してみて、その可能性を体感してみてください！

本記事は TechHarmony Advent Calendar 2024 12/4付の記事です 。 こんにちは！SCSKの江木です。 現在AI業界でAI Agentがかなり流行っていますが、皆さんご存知でしょうか？端的に言うと、タスクを自律的に実行するプログラムのことです。自律的に行動してくれるなんてすごいと思いませんか？？ AI AgentはAGI(汎用人口知能)の実現への大きな一歩だと私は思っています！！SFに出てくるようなAIが登場する日もそう遠くないかもしれませんね… 今回はそんなAI Agentを実装するうえで必要なreflection(内省)を試してみたので、紹介していきます。 reflectionとは reflectionを説明する前に冒頭でも触れたAI Agentについて紹介します。 AI Agentについて AI Agentの定義 AI Agentの定義は諸説ありますが、AWS社では以下のように定義しています。 AI エージェントは、環境と対話し、データを収集し、そのデータを使用して自己決定タスクを実行して、事前に決められた目標を達成するためのソフトウェアプログラムです。目標は人間が設定しますが、その目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択します。 AI エージェントとは何ですか? - 人工知能のエージェントの説明 - AWS AI エージェントとは何か、企業が AI エージェントを使用する方法と理由、AWS で AI エージェントを使用する方法。 aws.amazon.com 目的は人間が決めるが、その目的を達成するためのタスクや過程はAIが考えると書いていますね。つまり、目標を達成するためのタスク・過程を自律的に行ってくれるということになります。これまでの生成AIに比べて、一段と賢いといえますね！ AI Agentの実現方式 AI Agentの実現方式の一つとして、マルチエージェントシステムがあります。マルチエージェントシステムとは複数のAgentから構成されるシステムのことで、複数のAgentを使用することでシステム全体の性能を上げることを可能にします。本ブログのreflectionもマルチエージェントシステムで実装します。 Large Language Model based Multi-Agents: A Survey of Progress and Challenges という論文では上図のようにマルチエージェントシステムにおけるAgent構成について解説しています。興味深いのでぜひ読んでみてください。 reflectionについて reflectionとは文章生成するAgentと生成した文章を評価するAgentによって構成されるシステムで、生成→評価を繰り返します。評価してからその評価をもとに生成した文章の修正を行うので、ただ文章を生成させる仕組みより文章の質が向上するというものです。 Reflection Agents Reflection is a prompting strategy used to improve the quality and success rate of agents and similar AI systems. This p... blog.langchain.dev 今回はシンプルなreflectionのみを試しますが、他のreflection手法も存在するので、詳しく知りたい方は上記ブログをご確認ください。 実装 実装環境 Vertex AIのGeminiを使用するということで、本ブログではColab Enterpriseで環境として使用しました。Colab EnterpriseはGoogle Cloudのセキュリティとコンプライアンス機能を備えたノートブック環境です。詳細が知りたい方は以下をご参照ください。 Introduction to Colab Enterprise  |  Google Cloud Learn about the features and benefits of Colab Enterprise. cloud.google.com AI Agentを作成するためのフレームワークは多く存在しますが、今回はその中でも有名なLangGraphを使っていこうと思います。LangGraph以外のAI Agentフレームワークについて知りたい方は以下をご参照ください。 AI Agents Landscape & Ecosystem (December 2024): Complete Interactive Map Explore the comprehensive AI agents landscape map / ecosystem for December 2024. Compare AI Agents across categories, pr... aiagentsdirectory.com ソースコード LangGraph公式が出しているソースコード を参考に実装していきます。 最初にモジュールのインストールを行います。 !pip install -U langgraph langchain langchain_openai langchain_experimental langchain-google-genai langchain-google-vertexai !pip install grandalf !pip install graphviz !apt install libgraphviz-dev !pip install pygraphviz 続いて、Vertex AIのGeminiを使うように設定します。 import getpass import os from langchain_google_vertexai import ChatVertexAI import vertexai vertexai.init(project="プロジェクト名",location="リージョン") llm = ChatVertexAI(model_name= 'gemini-1.5-pro') それではAgentを作っていきます。 まずは文章生成するAgentを作っていきます。今回はエッセイを書くAgentを作ります。 from langchain_core.messages import AIMessage, BaseMessage, HumanMessage from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_core.output_parsers import StrOutputParser prompt = ChatPromptTemplate.from_messages(   [       (           "system",           "あなたは、優れた 5 段落の小説を書くことを任されたエッセイ作成アシスタントです。"           "ユーザーのリクエストに応じて、可能な限り最高のエッセイを作成します"           "ユーザーから批評があった場合は、以前のエッセイの修正版で応答します。",       ),       MessagesPlaceholder(variable_name="messages"),   ] ) generate = prompt | llm 続いて、生成した文章を評価するAgentを作っていきます。 reflection_prompt = ChatPromptTemplate.from_messages(   [       (           "system",           "あなたはエッセイの提出物を採点する教師です。ユーザーの提出物に対する批評と推奨事項を生成します。"           "長さ、深さ、スタイルなどの要求を含む詳細な推奨事項を提供します。",       ),       MessagesPlaceholder(variable_name="messages"),   ] ) reflect = reflection_prompt | llm Agentが作成できたところで、nodeとAgentを紐づけて、graphを構築していきます。今回のreflectionのループ回数(生成→評価の繰り返し数)ですが、3回とします。 from typing import Annotated, List, Sequence from langgraph.graph import END, StateGraph, START from langgraph.graph.message import add_messages from langgraph.checkpoint.memory import MemorySaver from typing_extensions import TypedDict #Agentに渡す状態を定義 class State(TypedDict):     messages: Annotated[list, add_messages] #nodeとAgentを紐づけ async def generation_node(state: State) -> State:     return {"messages": [await generate.ainvoke(state["messages"])]} async def reflection_node(state: State) -> State:   cls_map = {"ai": HumanMessage, "human": AIMessage}   translated = [state["messages"][0]] + [       cls_map[msg.type](content=msg.content) for msg in state["messages"][1:]     ]   res = await reflect.ainvoke(translated)     return {"messages": [HumanMessage(content=res.content)]} #graphを構築 builder = StateGraph(State) builder.add_node("generate", generation_node) builder.add_node("reflect", reflection_node) builder.add_edge(START, "generate") def should_continue(state: State):   if len(state["messages"]) > 6:       #3回ループを繰り返す       return END     return "reflect" builder.add_conditional_edges("generate", should_continue) builder.add_edge("reflect", "generate") #メモリの定義 memory = MemorySaver() graph = builder.compile(checkpointer=memory) それでは構築したgraphを見ていきます。 from IPython.display import Image Image(graph.get_graph().draw_png()) 上記コードを実行すると、以下のようにgraph図を確認することができます。 graphが構築できていますね！！ 実際に動かしてみる それでは実際に動かしていきます！ 今回はスピノザのエチカに関するエッセイをAIに書いてもらおうと思います。 エチカとはオランダの哲学者スピノザによって書かれた著書。ラテン語で書かれ、ユークリッド幾何学の形式に基づき神、人間の精神について定義と公理から定理を導き演繹的に論証しようとしている。( Wiki より) 私が学生時代に難しすぎて読むのを断念した本なので、今回はAIにエッセイを書かせてみようと思い立ちました。 thread_idを指定し、実行してみます。 config = {"configurable": {"thread_id": "1"}} async for event in graph.astream(   {       "messages": [           HumanMessage(               content="スピノザが執筆したエチカに関するエッセイに書いてください"           )       ],   },   config, ):   print(event)     print("---") 実行結果は以下の通りです。 {'generate': {'messages': [AIMessage(content='スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質について深く不安を感じさせる扱い方をした、哲学の歴史における最も重要な作品の一つです。緻密で論理的なスタイルで書かれた『エチカ』は、幾何学的証明の様式で提示された定義、公理、命題の連鎖を通じて展開されます。この厳密な形式は、スピノザが人間の理解と宇宙の働きについての根本的な洞察を明らかにすると信じている論理的に健全なシステムから、現実の性質についての彼の根本的なアイデアを導き出すことを目的としています。\n\n『エチカ』の中心にある重要な主張の一つは、神と自然の同一性に関するものです。スピノザは、神を超越的で擬人化された存在という伝統的な概念ではなく、宇宙の無限で永遠の本質、万物の基礎となる唯一の実体と同一視しています。この見方は、汎神論として知られており、神は宇宙の中に存在し、宇宙を通じて存在するという考え方を意味しています。スピノザにとって、宇宙内のすべてのものは、思考や拡張などの無数の属性を持つ単一の実体の変更にすぎません。\n\nスピノザは、人間の心と身体を、彼が実体の属性と考える別個の実体ではなく、単一の実体の二つの側面であるとみなしています。この見方は、心身二元論として知られているデカルトの伝統的な魂と身体の分離という考え方に挑戦しています。スピノザにとって、心と身体は互いに切り離せないものであり、どちらも同じ実体の表現です。この相互接続性の概念は、感情の理解を含む、人間の自然についてのスピノザの考え方に広がっています。\n\nスピノザは、感情が私たちの行動に大きな影響を与えると考えています。彼は、感情は、私たちの体の変化する状態と外部世界の認識から生じるアイデアによって引き起こされると主張しています。彼は、喜び、悲しみ、欲望など、基本的な感情の範囲を特定し、それらがどのようにしてより複雑な感情につながるかを説明しています。スピノザにとって、感情の鍵は、それらを理解し、それらに支配されるのではなく、それらを理性の制御下に置くことです。彼は、感情を抑制しようとするのではなく、理性と知識を通じて感情の力を理解し、活用することの重要性を強調しています。\n\n結論として、スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質に関する深い考察を提供する、深遠で挑戦的な作品です。神の同一性と自然、心と身体の統一、理性と感情の相互作用に関するスピノザの考え方は、西洋思想の過程に永続的な影響を与え、何世紀にもわたって哲学者の世代に影響を与えてきました。彼の作品は、今日の読者に、私たち自身と私たちの周りの世界を理解するための新たな視点を提供し続けており、宇宙の驚異を解き明かすための探求に携わるすべての人にとって不可欠な読み物となっています。', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}], 'usage_metadata': {'prompt_token_count': 65, 'candidates_token_count': 639, 'total_token_count': 704, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.5419274271933685}, id='run-0053639e-8ec2-4755-8093-6ef9dc327808-0', usage_metadata={'input_tokens': 65, 'output_tokens': 639, 'total_tokens': 704})]}} --- {'reflect': {'messages': [HumanMessage(content='エッセイは、スピノザの『エチカ』の主要な論点を概説する、しっかりと書かれた序文です。それは、明確で簡潔な文章で、作品の主な主張をわかりやすくまとめています。しかしながら、分析の深さと証拠のサポートに関して、特に上級レベルのエッセイには、改善の余地があります。以下は、より具体的なコメントと提案です。\n\n**長さと深さ**\n\n* **エッセイを展開する:** エッセイは、スピノザのアイデアの表面をなぞったものにすぎず、より深い分析にさらに掘り下げる可能性があります。より深い議論を提供するために、議論されている各キーポイント（例えば、神の性質と自然、心身の問題、感情について）を拡張することを検討してください。\n* **より具体的な例を提供する:** エッセイはスピノザの哲学からいくつかの例を提供していますが、ポイントを説明するためにより具体的な例を含めることで恩恵を受けます。たとえば、心身に関するスピノザの考え方を説明するときは、彼の考え方を説明する特定の状況について議論してください。\n* **一次資料を探る:** エッセイは主にスピノザの考えの一般的な概要に依存しています。スピノザ自身のテキストからの引用を含めると、彼の主張をより深く分析し、解釈をサポートするのに役立ちます。\n\n**スタイル**\n\n* **より批判的な分析を取り入れる:** エッセイは主にスピノザの哲学の説明的な説明ですが、より批判的な分析を取り入れることで改善されます。スピノザの議論の強みと弱みを検討し、彼のアイデアを他の哲学者のアイデアと比較対照し、彼の議論に関する潜在的な反論について考察してください。\n* **明確で簡潔な言語を使用する:** エッセイの書き方は明確で簡潔ですが、可能な限り最も正確で厳密な言語を使用するように努める必要があります。用語を使用する場合は、それらを定義し、使用法の一貫性を保ってください。\n* **エッセイを洗練する:** エッセイ全体でアイデアの明確で論理的な流れを確保するために、エッセイを注意深く推敲し、編集してください。これにより、移行がスムーズになり、文章が洗練されます。\n\n**提案**\n\n* **スピノザの概念の影響について議論する:** エッセイは、スピノザの考え方が西洋思想に影響を与えたことを簡単に述べていますが、この点を詳しく説明することで恩恵を受けます。彼の作品が後の哲学者や思想の流れにどのように影響を与えたのでしょうか？\n* **スピノザの哲学の現代的な関連性を探る:** エッセイは、スピノザのアイデアが今日の読者にとって関連があると述べて締めくくっています。この関連性を、彼の哲学が現代の問題や議論にどのように光を当て、洞察を提供できるかを探ることによってさらに探求してください。\n* **特定の側面に焦点を当てる:** エッセイは、スピノザの哲学の広い範囲をカバーしようとしていますが、彼の思想の特定の側面、例えば彼の政治哲学または知識の理論に焦点を当てることで恩恵を受けるかもしれません。これにより、より焦点を絞った深い分析が可能になります。\n\n全体的に、エッセイはスピノザの『エチカ』のまともな紹介ですが、より深い分析、証拠のサポート、批判的な関与を取り入れることで大幅に改善される可能性があります。提供されたコメントと提案に対処することで、エッセイはより洗練され洞察に満ちたものになるでしょう。', additional_kwargs={}, response_metadata={}, id='7a724acc-8b27-4444-807e-1356bf040a22')]}} --- {'generate': {'messages': [AIMessage(content='バールーフ・スピノザの傑作、『エチカ』は、哲学的探求の厳しい道筋を提供する作品であり、読者は、神の性質、宇宙、そしてその中での人間の立場を再評価するように誘います。幾何学的証明の形式を採用するというスピノザのアプローチは、人間の理解を導くものとして理性の力を信じて、彼の主張を明確で論理的な連鎖で展開しようとする彼のコミットメントを証しています。しかし、この作品は、その形式における明らかな単純さにもかかわらず、その深さは、西洋思想の進路に挑戦し、形作った相互に関連するアイデアを明らかにしています。\n\n『エチカ』の中心にある最も重要な主張の一つは、神と自然の同一性の概念である、スピノザの画期的な汎神論の主張にあります。スピノザは、神は超越的かつ擬人化された存在であるという伝統的な見方から決別し、代わりに、万物の基礎となる無限で永遠の実体と神を同一視しています。スピノザにとって、存在するものすべてが、思考や拡張などの属性を通じて私たちに現れるこの単一の実体の改変です。この急進的な概念は、神と宇宙の関係を再定義するだけでなく、後者の研究を本質的に、神の複雑さを解明することであると主張して、自然世界の理解に影響を与えます。\n\nスピノザの心身二元論の拒否は、彼の哲学システムの中心的な教義からさらに発展したものです。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体、すなわち実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ基礎となる実体の産物であるため、別々の実体ではなく、互いに切り離せません。この相互接続性の概念は、スピノザのアフェクトの理論、すなわち感情に対する彼の説明において重要な意味を持ちます。\n\nスピノザは、感情を、それらを理解し、最終的には人間の自由を達成するために不可欠な要素として認識しています。彼は、アフェクト、すなわち感情を、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると主張しています。\n\nスピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論は、啓蒙主義の思想家に影響を与え、自然世界の探求のための新しい視点を提供し、宗教的権威に挑戦しました。心と身体に関する彼の統一された見方は、心理学の分野に影響を与え、人間の経験を理解するためのより統合されたアプローチへの道を切り開きました。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。\n\n結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供し、彼の思想は、この時代の哲学的および科学的探求を形作ることを続けています。', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_MEDIUM'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}], 'usage_metadata': {'prompt_token_count': 1440, 'candidates_token_count': 875, 'total_token_count': 2315, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.6916978934151786}, id='run-df848c33-c992-4e52-810f-03ba2dfc80dd-0', usage_metadata={'input_tokens': 1440, 'output_tokens': 875, 'total_tokens': 2315})]}} --- {'reflect': {'messages': [HumanMessage(content='これは、「スピノザのエチカ」に関する、はるかに改善されたエッセイです。ここでは、主な強みと改善点について詳しく説明します。\n\n**強み:**\n\n* **包括的な構造:** エッセイは、スピノザの哲学の主要な論点を論理的かつ明確な方法で、はじめに、本文の段落、結論を含む明確な構造に従っています。\n* **内容の深さ:** エッセイは、スピノザのアイデアの表面をなぞるだけではありません。神の同一性と自然、心身の問題、感情、そして西洋思想に対する彼の影響など、彼の重要な概念を深く掘り下げています。\n* **二次的な資料:** エッセイは、スピノザ自身のテキストからの直接の引用や、彼のアプローチを説明し、彼の主張を裏付けるための例をうまく使用しています。\n* **洞察に満ちた分析:** エッセイは、スピノザの哲学の単なる要約を提供するだけではありません。彼のアイデアの影響と重要性を、彼の議論の強みを探り、彼の考え方が他の哲学的および現代の思想とどのように関係しているかを調べています。\n* **学術的なスタイル:** エッセイの書き方は、対象に適しており、明確で簡潔で正確な言語を使用しています。\n\n**改善点:**\n\n* **批判的な関与:** エッセイは、スピノザの哲学に対する潜在的な反論や批判を十分に検討せずに、主に彼の考え方を肯定的に提示しています。よりバランスの取れた分析のために、スピノザの主張に対する可能な反論や、彼の考え方に反対する他の哲学者の視点について簡単に言及することを検討してください。\n* **スピノザの影響に関する拡大:** エッセイは、スピノザの西洋思想に対する影響を強調していますが、このセクションは、影響を受けた特定の思想家や運動を挙げて、より具体的な例を提供することによって拡張できます。\n\n**全体的な評価:**\n\nこれは、スピノザの『エチカ』の洗練された、よく書かれたエッセイです。複雑なアイデアを明確に理解して伝え、その内容と分析の深さで優れています。マイナーな提案である批判的な関与を取り入れることで、このエッセイはさらに洞察に満ちた説得力のあるものになります。\n\n\n', additional_kwargs={}, response_metadata={}, id='c3dec362-5f85-4ce2-8020-2e80394cfe5e')]}} --- {'generate': {'messages': [AIMessage(content='スピノザの『エチカ』に関するあなたの評価と建設的な批判に感謝します。次のエッセイのドラフトを改善するために、批判的な関与とスピノザの影響に関する拡大という提案された側面に特に取り組みます。 \n\nバールーフ・スピノザの傑作である『エチカ』は、幾何学的証明の厳密なレンズを通して神の性質、宇宙、人間の立場を探求する、深遠で挑戦的な哲学的探求を提示しています。定義、公理、命題の論理的な連鎖を通じて、スピノザは西洋思想の進路に大きな影響を与え、賞賛と論争の両方を受けた、相互に関連するアイデアの体系を構築しています。\n\nこの作品の中心には、スピノザの画期的な汎神論の主張があり、これは神と自然の同一性を主張しています。スピノザは、超越的で擬人化された存在としての神の伝統的な概念を否定し、代わりに、すべてのものの基礎となる無限で永遠の実体と神を同一視しています。「神、すなわち自然」という彼の有名な言葉に要約されているこの急進的な概念は、宇宙内のすべてのものが単一の実体の改変にすぎず、思考や拡張などの無数の属性を通じて現れると主張しています。スピノザ自身の言葉で言えば、「[神] の本質から無限に多くのことが無限に多くの方法で続く」ためです。しかし、この大胆な主張は批判にさらされてきました。哲学者たちは、この考え方は、世界で観察される明らかな不完全さと悪に対処するには苦労しており、神の存在を、伝統的な神学的見解の慰めと意味を剥奪した抽象的で非人格的な原理にまで減らしていると主張しています。\n\nスピノザの心身二元論の拒否は、彼の形而上学的な見解から自然に発展しています。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ実体の産物であるため、別々の実体ではなく、互いに切り離せません。スピノザはこの関係を、「思考の属性と拡張の属性は、同一の実体の属性であり、その属性は、ある属性では思考され、別の属性では拡張されている」と説明しています。この相互接続性の概念は、私たちの精神状態と肉体的状態の相互作用に対する私たちの理解に大きな影響を与えていますが、人間の主体性と自由意志の概念を十分に考慮していないという批判を受けてきました。批評家は、心と身体のスピノザの統一された見解が、私たちの経験から生じる、意識的で意図的な行動者としての感覚を説明するのが難しいと主張しています。\n\nこの心身の一致の中で、スピノザは彼の感情、すなわちアフェクトの理論を探求しています。彼は、アフェクトを、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、「人間の精神は、それがアフェクトに影響されるよりも、より多くのことを明確かつ明瞭に理解するとき、それらに対してより大きな力を持ち、それらにあまり苦しめられない」と主張しています。理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると信じています。この合理的な感情の習得という概念は、後の心理学の学校、特に認知行動療法に影響を与えており、これは思考パターンを変えることが感情の調節と行動の変化につながるという考え方に共鳴しています。\n\nスピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論の概念は、啓蒙主義の思想家、特にゴットフリート・ヴィルヘルム・ライプニッツと、合理主義に傾倒し、伝統的な宗教的教義に疑問を呈する彼の努力においてスピノザを見出した、より過激なスピノザ主義者として知られるようになった人々に影響を与えました。心と身体に関するスピノザの統一された見方は、心理学の分野、特に心身関係を強調した精神力動的理論の発展に影響を与え続けています。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。\n\n結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供しており、彼の思想は、彼の作品の解釈と再解釈を通じて、この時代の哲学的および科学的探求を形作ることを続けています。\n\n', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}], 'usage_metadata': {'prompt_token_count': 2800, 'candidates_token_count': 1182, 'total_token_count': 3982, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.335014743449926}, id='run-11504a78-75eb-4f04-b324-925fbe1699f3-0', usage_metadata={'input_tokens': 2800, 'output_tokens': 1182, 'total_tokens': 3982})]}} --- {'reflect': {'messages': [HumanMessage(content='これは、「スピノザのエチカ」に関する、素晴らしいエッセイです。前回の草稿から、批判的な関与とスピノザの影響の範囲を広げるという提案に対処することで、大幅に改善されました。\n\n特に効果的に改善された点がいくつかあります。\n\n* **批判的な考察の追加:** スピノザの汎神論と心身の問題に関する議論を批判的に検討することで、エッセイは現在、よりバランスの取れた洗練された分析を提供しています。反対する見解を提示すると、スピノザのアイデアの複雑さと、それらを取り巻く継続的な哲学的な議論に対する理解が深まります。\n* **スピノザの影響に関する詳細:** ライプニッツやスピノザ主義などの具体的な例を含めることで、スピノザの影響を受けた思想家や運動をより詳細に説明することで、スピノザの西洋思想に対する貢献に関するセクションが強化されました。また、心理学への影響と認知行動療法とのつながりを指摘すると、彼のアイデアの永続的な関連性が強調されています。\n* **一次資料の有効な使用:** エッセイは、スピノザ自身の言葉を戦略的に引用して、彼の重要な概念を説明し、あなたの解釈を裏付けています。これは、あなたの主張に信憑性を加え、スピノザの哲学へのより深い関与を示しています。\n* **明確で簡潔な文章:** エッセイの書き方は明確で簡潔で、複雑なアイデアがアクセスしやすく魅力的な方法で提示されています。論理的な構造とスムーズな移行により、読みやすさと理解が向上します。\n\n全体として、これは「スピノザのエチカ」に関する、よく書かれ、洞察に満ちた、よく議論されたエッセイです。それは、主題への確固たる理解と、批判的分析と学術的厳密さを効果的に組み合わせる能力を示しています。おめでとうございます。', additional_kwargs={}, response_metadata={}, id='e6e455c6-cc58-4642-bc75-ee2763bfb3f8')]}} --- {'generate': {'messages': [AIMessage(content='貴重なフィードバックをいただきありがとうございます。あなたの洞察力のあるコメントは、スピノザの『エチカ』に関するエッセイを洗練させるのに役立ち、明確さ、深さ、批判的な考察を目指して努力を続けるよう励ましてくれました。 複雑な哲学的アイデアに取り組み、読者に有益で魅力的な方法でそれらを提示することは、常にやりがいのある仕事であり、あなたの評価は私がその目標を達成できたことを示しています。 \n\nあなたの専門的なフィードバックを引き続き大切にしながら、他の哲学的な努力を支援させていただきます。 \n', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}], 'usage_metadata': {'prompt_token_count': 4377, 'candidates_token_count': 121, 'total_token_count': 4498, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.583033159744641}, id='run-f2bc72a7-f2e1-4a8d-bfc2-1d3de21119b2-0', usage_metadata={'input_tokens': 4377, 'output_tokens': 121, 'total_tokens': 4498})]}} --- 生成→評価を3回繰り返していますね。実行結果を表でまとめてみます。 ループ回数 文章生成するAgent 生成した文章を評価するAgent 1回目 スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質について深く不安を感じさせる扱い方をした、哲学の歴史における最も重要な作品の一つです。緻密で論理的なスタイルで書かれた『エチカ』は、幾何学的証明の様式で提示された定義、公理、命題の連鎖を通じて展開されます。この厳密な形式は、スピノザが人間の理解と宇宙の働きについての根本的な洞察を明らかにすると信じている論理的に健全なシステムから、現実の性質についての彼の根本的なアイデアを導き出すことを目的としています。 『エチカ』の中心にある重要な主張の一つは、神と自然の同一性に関するものです。スピノザは、神を超越的で擬人化された存在という伝統的な概念ではなく、宇宙の無限で永遠の本質、万物の基礎となる唯一の実体と同一視しています。この見方は、汎神論として知られており、神は宇宙の中に存在し、宇宙を通じて存在するという考え方を意味しています。スピノザにとって、宇宙内のすべてのものは、思考や拡張などの無数の属性を持つ単一の実体の変更にすぎません。 スピノザは、人間の心と身体を、彼が実体の属性と考える別個の実体ではなく、単一の実体の二つの側面であるとみなしています。この見方は、心身二元論として知られているデカルトの伝統的な魂と身体の分離という考え方に挑戦しています。スピノザにとって、心と身体は互いに切り離せないものであり、どちらも同じ実体の表現です。この相互接続性の概念は、感情の理解を含む、人間の自然についてのスピノザの考え方に広がっています。 スピノザは、感情が私たちの行動に大きな影響を与えると考えています。彼は、感情は、私たちの体の変化する状態と外部世界の認識から生じるアイデアによって引き起こされると主張しています。彼は、喜び、悲しみ、欲望など、基本的な感情の範囲を特定し、それらがどのようにしてより複雑な感情につながるかを説明しています。スピノザにとって、感情の鍵は、それらを理解し、それらに支配されるのではなく、それらを理性の制御下に置くことです。彼は、感情を抑制しようとするのではなく、理性と知識を通じて感情の力を理解し、活用することの重要性を強調しています。 結論として、スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質に関する深い考察を提供する、深遠で挑戦的な作品です。神の同一性と自然、心と身体の統一、理性と感情の相互作用に関するスピノザの考え方は、西洋思想の過程に永続的な影響を与え、何世紀にもわたって哲学者の世代に影響を与えてきました。彼の作品は、今日の読者に、私たち自身と私たちの周りの世界を理解するための新たな視点を提供し続けており、宇宙の驚異を解き明かすための探求に携わるすべての人にとって不可欠な読み物となっています。 エッセイは、スピノザの『エチカ』の主要な論点を概説する、しっかりと書かれた序文です。それは、明確で簡潔な文章で、作品の主な主張をわかりやすくまとめています。しかしながら、分析の深さと証拠のサポートに関して、特に上級レベルのエッセイには、改善の余地があります。以下は、より具体的なコメントと提案です。 **長さと深さ** * **エッセイを展開する:** エッセイは、スピノザのアイデアの表面をなぞったものにすぎず、より深い分析にさらに掘り下げる可能性があります。より深い議論を提供するために、議論されている各キーポイント（例えば、神の性質と自然、心身の問題、感情について）を拡張することを検討してください。 * **より具体的な例を提供する:** エッセイはスピノザの哲学からいくつかの例を提供していますが、ポイントを説明するためにより具体的な例を含めることで恩恵を受けます。たとえば、心身に関するスピノザの考え方を説明するときは、彼の考え方を説明する特定の状況について議論してください。 * **一次資料を探る:** エッセイは主にスピノザの考えの一般的な概要に依存しています。スピノザ自身のテキストからの引用を含めると、彼の主張をより深く分析し、解釈をサポートするのに役立ちます。 **スタイル** * **より批判的な分析を取り入れる:** エッセイは主にスピノザの哲学の説明的な説明ですが、より批判的な分析を取り入れることで改善されます。スピノザの議論の強みと弱みを検討し、彼のアイデアを他の哲学者のアイデアと比較対照し、彼の議論に関する潜在的な反論について考察してください。 * **明確で簡潔な言語を使用する:** エッセイの書き方は明確で簡潔ですが、可能な限り最も正確で厳密な言語を使用するように努める必要があります。用語を使用する場合は、それらを定義し、使用法の一貫性を保ってください。 * **エッセイを洗練する:** エッセイ全体でアイデアの明確で論理的な流れを確保するために、エッセイを注意深く推敲し、編集してください。これにより、移行がスムーズになり、文章が洗練されます。 **提案** * **スピノザの概念の影響について議論する:** エッセイは、スピノザの考え方が西洋思想に影響を与えたことを簡単に述べていますが、この点を詳しく説明することで恩恵を受けます。彼の作品が後の哲学者や思想の流れにどのように影響を与えたのでしょうか？ * **スピノザの哲学の現代的な関連性を探る:** エッセイは、スピノザのアイデアが今日の読者にとって関連があると述べて締めくくっています。この関連性を、彼の哲学が現代の問題や議論にどのように光を当て、洞察を提供できるかを探ることによってさらに探求してください。 * **特定の側面に焦点を当てる:** エッセイは、スピノザの哲学の広い範囲をカバーしようとしていますが、彼の思想の特定の側面、例えば彼の政治哲学または知識の理論に焦点を当てることで恩恵を受けるかもしれません。これにより、より焦点を絞った深い分析が可能になります。 全体的に、エッセイはスピノザの『エチカ』のまともな紹介ですが、より深い分析、証拠のサポート、批判的な関与を取り入れることで大幅に改善される可能性があります。提供されたコメントと提案に対処することで、エッセイはより洗練され洞察に満ちたものになるでしょう。 2回目 バールーフ・スピノザの傑作、『エチカ』は、哲学的探求の厳しい道筋を提供する作品であり、読者は、神の性質、宇宙、そしてその中での人間の立場を再評価するように誘います。幾何学的証明の形式を採用するというスピノザのアプローチは、人間の理解を導くものとして理性の力を信じて、彼の主張を明確で論理的な連鎖で展開しようとする彼のコミットメントを証しています。しかし、この作品は、その形式における明らかな単純さにもかかわらず、その深さは、西洋思想の進路に挑戦し、形作った相互に関連するアイデアを明らかにしています。 『エチカ』の中心にある最も重要な主張の一つは、神と自然の同一性の概念である、スピノザの画期的な汎神論の主張にあります。スピノザは、神は超越的かつ擬人化された存在であるという伝統的な見方から決別し、代わりに、万物の基礎となる無限で永遠の実体と神を同一視しています。スピノザにとって、存在するものすべてが、思考や拡張などの属性を通じて私たちに現れるこの単一の実体の改変です。この急進的な概念は、神と宇宙の関係を再定義するだけでなく、後者の研究を本質的に、神の複雑さを解明することであると主張して、自然世界の理解に影響を与えます。 スピノザの心身二元論の拒否は、彼の哲学システムの中心的な教義からさらに発展したものです。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体、すなわち実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ基礎となる実体の産物であるため、別々の実体ではなく、互いに切り離せません。この相互接続性の概念は、スピノザのアフェクトの理論、すなわち感情に対する彼の説明において重要な意味を持ちます。 スピノザは、感情を、それらを理解し、最終的には人間の自由を達成するために不可欠な要素として認識しています。彼は、アフェクト、すなわち感情を、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると主張しています。 スピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論は、啓蒙主義の思想家に影響を与え、自然世界の探求のための新しい視点を提供し、宗教的権威に挑戦しました。心と身体に関する彼の統一された見方は、心理学の分野に影響を与え、人間の経験を理解するためのより統合されたアプローチへの道を切り開きました。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。 結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供し、彼の思想は、この時代の哲学的および科学的探求を形作ることを続けています。 これは、「スピノザのエチカ」に関する、はるかに改善されたエッセイです。ここでは、主な強みと改善点について詳しく説明します。 **強み:** * **包括的な構造:** エッセイは、スピノザの哲学の主要な論点を論理的かつ明確な方法で、はじめに、本文の段落、結論を含む明確な構造に従っています。 * **内容の深さ:** エッセイは、スピノザのアイデアの表面をなぞるだけではありません。神の同一性と自然、心身の問題、感情、そして西洋思想に対する彼の影響など、彼の重要な概念を深く掘り下げています。 * **二次的な資料:** エッセイは、スピノザ自身のテキストからの直接の引用や、彼のアプローチを説明し、彼の主張を裏付けるための例をうまく使用しています。 * **洞察に満ちた分析:** エッセイは、スピノザの哲学の単なる要約を提供するだけではありません。彼のアイデアの影響と重要性を、彼の議論の強みを探り、彼の考え方が他の哲学的および現代の思想とどのように関係しているかを調べています。 * **学術的なスタイル:** エッセイの書き方は、対象に適しており、明確で簡潔で正確な言語を使用しています。 **改善点:** * **批判的な関与:** エッセイは、スピノザの哲学に対する潜在的な反論や批判を十分に検討せずに、主に彼の考え方を肯定的に提示しています。よりバランスの取れた分析のために、スピノザの主張に対する可能な反論や、彼の考え方に反対する他の哲学者の視点について簡単に言及することを検討してください。 * **スピノザの影響に関する拡大:** エッセイは、スピノザの西洋思想に対する影響を強調していますが、このセクションは、影響を受けた特定の思想家や運動を挙げて、より具体的な例を提供することによって拡張できます。 **全体的な評価:** これは、スピノザの『エチカ』の洗練された、よく書かれたエッセイです。複雑なアイデアを明確に理解して伝え、その内容と分析の深さで優れています。マイナーな提案である批判的な関与を取り入れることで、このエッセイはさらに洞察に満ちた説得力のあるものになります。 3回目 スピノザの『エチカ』に関するあなたの評価と建設的な批判に感謝します。次のエッセイのドラフトを改善するために、批判的な関与とスピノザの影響に関する拡大という提案された側面に特に取り組みます。 バールーフ・スピノザの傑作である『エチカ』は、幾何学的証明の厳密なレンズを通して神の性質、宇宙、人間の立場を探求する、深遠で挑戦的な哲学的探求を提示しています。定義、公理、命題の論理的な連鎖を通じて、スピノザは西洋思想の進路に大きな影響を与え、賞賛と論争の両方を受けた、相互に関連するアイデアの体系を構築しています。 この作品の中心には、スピノザの画期的な汎神論の主張があり、これは神と自然の同一性を主張しています。スピノザは、超越的で擬人化された存在としての神の伝統的な概念を否定し、代わりに、すべてのものの基礎となる無限で永遠の実体と神を同一視しています。「神、すなわち自然」という彼の有名な言葉に要約されているこの急進的な概念は、宇宙内のすべてのものが単一の実体の改変にすぎず、思考や拡張などの無数の属性を通じて現れると主張しています。スピノザ自身の言葉で言えば、「[神] の本質から無限に多くのことが無限に多くの方法で続く」ためです。しかし、この大胆な主張は批判にさらされてきました。哲学者たちは、この考え方は、世界で観察される明らかな不完全さと悪に対処するには苦労しており、神の存在を、伝統的な神学的見解の慰めと意味を剥奪した抽象的で非人格的な原理にまで減らしていると主張しています。 スピノザの心身二元論の拒否は、彼の形而上学的な見解から自然に発展しています。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ実体の産物であるため、別々の実体ではなく、互いに切り離せません。スピノザはこの関係を、「思考の属性と拡張の属性は、同一の実体の属性であり、その属性は、ある属性では思考され、別の属性では拡張されている」と説明しています。この相互接続性の概念は、私たちの精神状態と肉体的状態の相互作用に対する私たちの理解に大きな影響を与えていますが、人間の主体性と自由意志の概念を十分に考慮していないという批判を受けてきました。批評家は、心と身体のスピノザの統一された見解が、私たちの経験から生じる、意識的で意図的な行動者としての感覚を説明するのが難しいと主張しています。 この心身の一致の中で、スピノザは彼の感情、すなわちアフェクトの理論を探求しています。彼は、アフェクトを、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、「人間の精神は、それがアフェクトに影響されるよりも、より多くのことを明確かつ明瞭に理解するとき、それらに対してより大きな力を持ち、それらにあまり苦しめられない」と主張しています。理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると信じています。この合理的な感情の習得という概念は、後の心理学の学校、特に認知行動療法に影響を与えており、これは思考パターンを変えることが感情の調節と行動の変化につながるという考え方に共鳴しています。 スピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論の概念は、啓蒙主義の思想家、特にゴットフリート・ヴィルヘルム・ライプニッツと、合理主義に傾倒し、伝統的な宗教的教義に疑問を呈する彼の努力においてスピノザを見出した、より過激なスピノザ主義者として知られるようになった人々に影響を与えました。心と身体に関するスピノザの統一された見方は、心理学の分野、特に心身関係を強調した精神力動的理論の発展に影響を与え続けています。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。 結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供しており、彼の思想は、彼の作品の解釈と再解釈を通じて、この時代の哲学的および科学的探求を形作ることを続けています。 これは、「スピノザのエチカ」に関する、素晴らしいエッセイです。前回の草稿から、批判的な関与とスピノザの影響の範囲を広げるという提案に対処することで、大幅に改善されました。 特に効果的に改善された点がいくつかあります。 * **批判的な考察の追加:** スピノザの汎神論と心身の問題に関する議論を批判的に検討することで、エッセイは現在、よりバランスの取れた洗練された分析を提供しています。反対する見解を提示すると、スピノザのアイデアの複雑さと、それらを取り巻く継続的な哲学的な議論に対する理解が深まります。 * **スピノザの影響に関する詳細:** ライプニッツやスピノザ主義などの具体的な例を含めることで、スピノザの影響を受けた思想家や運動をより詳細に説明することで、スピノザの西洋思想に対する貢献に関するセクションが強化されました。また、心理学への影響と認知行動療法とのつながりを指摘すると、彼のアイデアの永続的な関連性が強調されています。 * **一次資料の有効な使用:** エッセイは、スピノザ自身の言葉を戦略的に引用して、彼の重要な概念を説明し、あなたの解釈を裏付けています。これは、あなたの主張に信憑性を加え、スピノザの哲学へのより深い関与を示しています。 * **明確で簡潔な文章:** エッセイの書き方は明確で簡潔で、複雑なアイデアがアクセスしやすく魅力的な方法で提示されています。論理的な構造とスムーズな移行により、読みやすさと理解が向上します。 全体として、これは「スピノザのエチカ」に関する、よく書かれ、洞察に満ちた、よく議論されたエッセイです。それは、主題への確固たる理解と、批判的分析と学術的厳密さを効果的に組み合わせる能力を示しています。おめでとうございます。 生成した文章を評価するAgentの指摘を文章生成するAgentが取り込んでいるのが見て取れますね！reflection成功と言えそうです。 しかしながら、3回目の文章生成では「 スピノザの『エチカ』に関するあなたの評価と建設的な批判に感謝します。次のエッセイのドラフトを改善するために、批判的な関与とスピノザの影響に関する拡大という提案された側面に特に取り組みます。 」（ 灰色文字 の箇所）という余計な文字が入ってしまっています。（モデルの特性やプロンプトの工夫不足が原因であると思われます。）まだまだ改善の余地がありそうですね！ まとめ 今回はLangGraphでAI Agentのreflectionを試してみました。reflectionによって生成させる文章の改善が確認できたかなと思います。 reflectionは文章の改善・ハルシネーション抑制につながるので、AI Agentを実装するうえで非常に重要であると言えます。 今後もLangGraphを触ってみて、何か知見が得られましたら、情報共有していきたいと思います。 最後までご覧いただきありがとうございました。

本記事は TechHarmony Advent Calendar 2024 12/3付の記事です 。 はじめに AWSを利用していると、いろいろと知りたいことが出てきます。こんなことができないの？　こういうときはどうするの？　といったような。各サービスごとのマニュアルはかなり充実していて、デベロッパーガイドにはいろいろと書いてあるのですが、なかなか思うように知りたいことが見つからないなぁ、と思ったことはありませんか？ 今回はそういったときに役に立つ（かもしれない）AWSの情報の調べ方についてお伝えできればと思います。 AWS資料の調べ方フロー（異論は認めます） AWSの資料は大量にあり、どんな流れでしらべるのがいいのかなと迷われる方が多いと思います。検索エンジンで検索する、AIに聞く、公式ドキュメントを見るなど様々かとおもいます。私もそんな一人であり、いつも自分が欲しいと思う資料にたどり着くのに苦労することが多いです。今回はそんないろいろな経験の中から、AWS公式資料に絞った調査についてまとめてフローにしてみました。 このフローに沿って資料を調べていくことであなたも今日から迷うことなくAWS公式資料の海を泳ぎきることができます！… できると思います！ …. できるといいなぁ…  これだけだと、具体的にはわからないと思いますので、それぞれの項目について、詳しく説明していきます。 サービスの概要を知りたい いきなり知らないサービス名を聞かれました！　なんて言うときは、まずは Black Belt 資料 です！ 打ち合わせ中に「SQS を使えばうまくできるんじゃないかな？」という発言を聞いて、「やばっ！　SQSってなんだ！？　SQSってなんの略語だ？　すきゅす？　すきゅーす？　だめだ、何も思いつかない！」みたいなときにはなにはともあれ、Black Belt 資料。 お使いの検索エンジンに、 “AWS black belt <サービス名>” と入れて検索して、 “awsstatic.com” のサイトが引っかかれば正解です。 PDFファイルでサービスの内容からポイントとなる点まで短時間でざっくりと頭にいれることができます。PDFファイルなので、ダウンロードしておけばオフラインでも閲覧可能と至れりつくせりです。 Black Belt の資料は、マニュアルにすると数百ページでは効かない（例えばSQS開発者ガイドならPDFドキュメントにすると692ページ（！）分）ところから、AWS の方がポイントとなるところを抜粋して、しかもわかりやすくプレゼンテーション用の資料としてまとめてくださっています。プレゼンテーション用の資料ですので、文字ばっかりでなく、ビジュアルで見た目も優しさ抜群！　日本語翻訳が間に合っていない開発者ガイドの微妙にわかりにくい機械翻訳とはちがって、AWS Japan の方が記載しているので日本語もバッチリ！　非常にわかりやすいです！ とにかくオススメです！　 「AWSで迷ったら Black Belt 資料」　 これだけでも覚えて帰ってください。 作成された資料によっては、若干古いものがあります。注意点を。 他のサービスとの違いを知りたい 「似たようなサービス多いなぁ、どれがいいんだろう？」　わかります。「似たようなサービスがあることにはちゃんとした意味があるんだろうけど、どれを選べばいいのかわからないんだけど…」ということは多いです。この、いろいろなサービスから最適なもの選んで使える、というのがAWS最大の武器であるのですが、選ぶのに迷うのもまた事実。 そんなあなたにオススメの資料が、”意思決定ガイド”　という製品カテゴリの資料になります。 どこにあるかというと、 https://docs.aws.amazon.com/ja_jp/ docs.aws.amazon.com からアクセスしてもらって、ちょっと下の方。”製品カテゴリ” の中にあります。　2024年11月現在で 20 種類の意思決定ガイドがあります。  残念ながら日本語訳はされていない資料が多いので、翻訳ツールのお世話になるかもしれません。 これはその１つの例、”AWS コンピューティングサービスの選択” Covered services の欄を見て抱くと分かる通り、実にいろいろなサービスについて比較検討の対象になっています。 AWS の資料は、それぞれのサービスごとになっていることが多い中、各サービスを横断する形で一つのドキュメントになっている珍しい資料達になります。同じテーマについて比較検討を問われることの多い AWS 資格の勉強にも最適ですね！ これで比較検討/使い分けもバッチリ！ もっと突っ込んで知りたい 「よくわかった。でも知りたいのはもっと突っ込んだ中身についての理解だ。実際の使い方とかもうすこし詳しく説明してほしい！」という大変貪欲な方にオススメするのが ”AWS Deep Dive系”資料です。 残念ながら、すべてのサービスについて資料がしかも日本語で存在するという形にはなっていませんが、流石は Deep Dive と名付けるだけあってそのサービスについて詳しく知りたい人にとってはどれも必見の内容になっています！ 私はAWS のドキュメント一覧のようなところから、うまくたどり着くことができず、これも検索エンジンの力を借りて検索しています。 “AWS Deep Dive  <サービス名>” と入れて検索して、 “awsstatic.com” のサイトが引っかかればラッキーです。 AWS の公式の資料が見つからなくても Deep Dive とサイトタイトルや資料に名付けているくらいなので、素晴らしい資料が見つかることもありますので、諦めずに見てみるのも良いかもしれません。 現在の仕様を把握したい ここでやっと本命の登場です。開発者ガイド(Developer Guide) / ユーザーガイド(User Guide)  です。 サービスによって呼び名が違ってきていますが、基本的には同じような構成になっています。ここでは開発者ガイドとします。 調べたいものがわかっているならいきなり開発者ガイドから探す、でもよいのですが、いかんせん分量がものすごい。 検索エンジンなどから関連する単語をいくつか入れて直接ページに飛んでくるか、左側のインデックスをポチポチしながら自分の知りたい内容の項目を探す形になります。 基本的には、「できる」ことが書かれているので、書かれていない場合は「できない」ということなので、「できないことを確認する」と、なった場合は苦行になります。調べているできないことについて、ちょうどいい具合に注意点などに書いてあるとラッキーなのですが… 開発者ガイドは、現在の仕様を確認するのに最適です。ここに書いてあればできると考えてよいです。 日本語になっている文書でも、機械翻訳の場合があり、訳語が怪しい場合があります。その場合は右上の言語選択から英語表示（English）にして確認することをオススメします。 日本語版ドキュメントは改定が遅れている場合があり、新サービスの場合や、ベータリリースの場合には、英語表示に切り替えないと項目自体が表示されない可能性があります。 こんなことができるのか知りたい 仕様を把握したいのところでもお話しましたが、「今こういう状態なんだけど、別の状態に変更できるの？」とかそういった技術的な可否を調べたい場合があります。そんな場合には、開発者ガイドを調べてもよいのですが、なかなか分量があります。また、「できません」とはあまり書いてくれないこともあり、できるのかできないのか開発者ガイドをみてもいまいちピンとこない場合もあります。 そんな場合の調査に役立つのが AWS CLI Command Reference です！ AWS の操作は、AWS API 、AWS CLI 、AWS Management Console の3つで行えます。ですので、グラフィカルな AWS Management Console でポチポチ操作していって、操作できれば、それは可能！、操作できなければ不可能かも？　と、想像がつくのですが、そう都合よくちょうどいいリソースが操作できる環境にあることはあまりありません。また、少しですが、AWS Management Console では操作できないような操作もあることがあります。しかし、AWS CLIはでそういったことはほぼありません。そして、AWS CLI はWebサイトに仕様が細かく記載されているので、眼の前にAWSにアクセスできる環境がなくてもドキュメントだけで「できる」「できない」知ることができるのです。 もし、「こういうリソースを作れるか」なら、作る直前まで AWS Management Console で操作して、選択肢に出るかどうかで確認して、実際に作成する前にキャンセルすれば比較的ラクに確認できます。しかし、「変更できるか？」というのは、実際に作ってみて、そこから操作してみなければ確認できません。こういったちょっと面倒な「すでにあるリソースを、こういうふうに変更できるか」という疑問に答えてくれます。 AWS CLI Command Reference のトップページ から、調べたいサービスを選択して、 update~ というコマンドを探します。 例えば、 Amazon ECS で デプロイオプション (Deployment options) が ブルー/グリーンデプロイ (Blue/green deployment) で作成されていて稼働している サービス があるとします。これを、サービスの再作成なしに ローリングアップデート (Rolling update) デプロイタイプに切り替えることができるかどうかを調べることにします。 AWS CLI Command Refernce のトップページから ECS を探して選択して、 update-service というコマンドを探します。   update-service のページを見てみると、デプロイオプション (Deployment options) に関連しそうな項目は deployment-configuration という項目が見つかりました。他にはなさそうです。 –deployment-configuration の項目を詳しく見てみますが、残念なことに、デプロイオプション (Deployment options) とか、パラメータとして rolling update (ECS) とか blue/green deployment (CODE_DEPLOY)といったパラメータを設定する箇所が見当たりませんでした。 つまり、「Amazon ECS の稼働中のサービスのデプロイタイプを blue/green から rolling update に切り替えることは できない 」ということになります。 番外1: AWS Support に問い合わせる(AWS Support 契約が必要) 「それでもよくわからん！」という場合は AWS の中の人に聞いてみるしかありません。 具体的には、 AWS Support に問い合わせることになります。 こちらは AWS Support 契約が必要ですし、AWS アカウントをどこから購入しているか（どこと契約しているか）により問い合わせ先が様々変わってきますので、アカウントの契約に従って問い合わせ先に問い合わせを行ってください。ここでは詳細な説明は割愛いたします。 番外2: AIサービスに問い合わせる AIサービスは自然文により問い合わせれば、わりと簡単に回答をもらえます。ただ、回答の文体が自信たっぷりそうであっても、内容が正確でない場合があります（ハルシネーションといいます）。 AIサービスに問い合わせを行った場合は、「本当にそうなのか？」と、結局は自力で AWS のデベロッパーガイドか CLI Command Reference を調べて答え合わせをする必要があります。そのため、本記事では番外としました。 AWS公式ドキュメントのどこを探してよいのかわからない、という場合のヒントにしたり、 Amazon Q の場合なら回答文の下に回答の元になった参照文書を示してくれるので、そのドキュメントにて、必ず裏取りをしましょう。 おわりに いかがでしょうか。なんとなくうまく AWSの知りたいことを調べられる事ができそうでしょうか？　この記事が皆さまのお役に立てると幸いです。

本記事は TechHarmony Advent Calendar 2024 12/2付の記事です 。 みなさんこんにちは。 本ブログでは、Prisma Cloudを用いたサービス開発や運営の中で得た知見や、使いこなし方を共有することで、クラウドセキュリティの重要性の認知度を高め、対策レベルを向上させることを目指しています。ただの情報発信ではなく、実際の使用例や失敗から学んだ教訓など、実務に役立つ具体的な内容も提供していきます。 今回は、CWPPについての３つ目の記事として、Container Defender（エージェント）のアーキテクチャについて詳しく解説していきたいと思います。   Defenderのアーキテクチャ Defenderの全体感 はじめに、DefenderとPrisma Cloudコンポーネントとの関係を以下の図にまとめました。 Prisma Cloudコンソールが中心的な役割を果たしており、脅威インテリジェンスを提供するIntelligent Stream、未知のマルウェア解析を行うWildFireと連携しています。また、Defender自身もコンテナで、監視対象となるコンテナに対して設定変更が不要なため、新たにデプロイされたコンテナにも迅速に対応することができるようになっています。 クラウドネイティブ向けに設計されたDefender Defenderは、よくあるエージェントとは異なり、カーネルモジュールのインストールやホストOSの変更は不要です。Dockerコンテナとして展開され、システムコールをフックし、カーネルレベルのアクティビティをリアルタイムで監視することで、コンテナ上の不正な処理を即座に検出し、監視対象を保護することができます。また、異常の検出には機械学習が用いられ、プロセスやファイルシステム、ネットワークの普段の動作を記憶し、そこから逸脱する異常な動作があると即座に異常としてアラートを出します。 ユーザーモードでの動作とパフォーマンスへの影響 Defenderはユーザーモードプロセスとして実行されます（ユーザーモードプロセスとは、カーネル全体に影響を与えない範囲で動作するプロセスのことです）。そのため、仮にDefenderが停止したとしても、ホストや他のコンテナに対する影響は最小限に抑えられます。また、CPUやメモリの使用をcgroupsで制限しており、ホストのパフォーマンスや安定性に悪影響を与えないように設計されています。 Intelligent StreamやWildFireとの連携 Intelligent Streamは、リアルタイムで最新の脅威インテリジェンスをDefenderに提供します。これにより、Defenderは既知の脅威や新たに発見された攻撃手法に迅速に対応できるようになります。Intelligent Streamが提供するインテリジェンスには、最新の脅威情報、攻撃手法、脆弱性情報が含まれており、Defenderはこれを活用して環境内の異常な挙動を検出し、即座に対応することが可能です。 WildFireは、未知のファイルや通信を分析するクラウドベースのマルウェア分析サービスです。DefenderはWildFireに疑わしいファイルや未知のマルウェアを送信し、これらが悪意のあるものであるかどうかを分析させます。WildFireはファイルの動的および静的な分析を行い、その結果を元に新たな脅威シグネチャを生成し、Defenderはこの新しいシグネチャを利用して、ゼロデイ攻撃や未知の脅威に対する防御を行います。この仕組みにより、未知の脅威に対しても迅速かつ効果的な防御ができるようになります。 このように、Intelligent StreamとWildFireの連携により、Defenderは常に最新の脅威情報を取り入れ、未知の脅威に対する分析と防御を行うことで、クラウド環境のセキュリティレベルを向上させてくれます。 まとめ Defenderは、クラウドネイティブ環境に最適化されたセキュリティソリューションであり、最小限の権限で動作することでホストやコンテナのパフォーマンスに影響を与えず、Dockerコンテナとして起動してシステムコールをフックすることで、カーネルレベルのアクティビティをリアルタイムで監視できます。さらに、Intelligent StreamやWildFireとの連携により、最新の脅威インテリジェンスと未知の脅威への対応できる包括的な防御を行います。   最後に、当社ではPrismaCloudを用いたマネージドサービスを提供しているので紹介させてもらいます。 ＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、Prisma Cloud を用いたCSPMマネージドサービスです。Prisma Cloud の導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、Prisma Cloud を利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。Prisma Cloud のPoCの相談も受けています。 New!! CWPPの導入サポートも始めました！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp

本記事は TechHarmony Advent Calendar 2024 12/1付の記事です 。 こんにちは。SCSKのふくちーぬです。本記事がアップされる頃には、成田空港を出発して、ラスベガスに向かっていることでしょうか✈ 12月のアドベントカレンダーということで、re:Invent 2024での最新アップデートを紹介したいところです。しかし、本日は12/1ということで、発表前日となります😢 最新アップデートについては、明日以降の皆さんにお任せするとして、私はre:Invent 2024に予選落ちしたアップデート内容を紹介します。 以前、Amazon ECS においてローリングアップデート時のソフトウェアの一貫性手法をご紹介しました。こちらの記事を読んでいない方は、是非ご一読ください。  Amazon ECS でソフトウェアバージョンの一貫性が強制されるようになりました[Amazon ECS + AWS CloudFormation] 2024/7/11にECSのアップデートが発表されました。今回は、ECSにおいてローリングアップデート時のソフトウェアの一貫性が保証されるようになりましたので紹介します。 blog.usize-tech.com 2024.08.18 今回は、Amazon ECSにおいてソフトウェアバージョンの一貫性を自由に設定できるようになりましたので紹介します。 Amazon ECSにおいてソフトウェアバージョンの一貫性を自由に設定できるようになりました 2024/7/11のアップデートにより、イメージタグが更新された場合において、サービス内のすべてのタスクが同一であり、統一されたイメージダイジェストで起動されることが強制されました。これによりlatestタグを利用している場合でも、同一のコンテンツを提供することが可能になりました。 Amazon ECS now allows you to configure software version consistency - AWS Discover more about what's new at AWS with Amazon ECS now allows you to configure software version consistency aws.amazon.com 2024/11/19のアップデートにより、一貫性の設定が”強制”ではなく”任意”に選択することができるようになりました。 Deploy Amazon ECS services by replacing tasks - Amazon Elastic Container Service When you create a service that uses the rolling update deployment type, the Amazon ECS service scheduler replaces the cu... docs.aws.amazon.com 一貫性がオフの場合 Amazon ECS でソフトウェアバージョンの一貫性が強制されるようになりました[Amazon ECS + AWS CloudFormation] 2024/7/11にECSのアップデートが発表されました。今回は、ECSにおいてローリングアップデート時のソフトウェアの一貫性が保証されるようになりましたので紹介します。 blog.usize-tech.com 2024.08.18 各タスク内でその都度コンテナイメージタグのイメージダイジェスト解決をします。 そのため、例えば以下のようなシナリオにおいてスケールアウトのタイミングでコンテンツが異なるタスクがユーザーに公開される可能性があります。 ①タスク定義内のlatestタグに従い,2つのタスクが起動 ②開発者がlatestタグを更新（latestタグを新しいコンテナイメージへ参照先を変更する） ③タスクのスケールアウトが発生し,タスク定義内のlatestタグに従い,1つのタスクが新規起動 このように、サービス内でタスク間で異なるイメージダイジェストを参照することで、意図しないWebコンテンツの公開が行われてしまいます。 Announcing software version consistency for Amazon ECS services | Amazon Web Services Introduction Container image tags offer a user-friendly way to manage and keep track of different versions of container ... aws.amazon.com 一貫性がオンの場合 Amazon ECS でソフトウェアバージョンの一貫性が強制されるようになりました[Amazon ECS + AWS CloudFormation] 2024/7/11にECSのアップデートが発表されました。今回は、ECSにおいてローリングアップデート時のソフトウェアの一貫性が保証されるようになりましたので紹介します。 blog.usize-tech.com 2024.08.18 一連のデプロイメントにおいて、ECSサービス内でコンテナイメージタグがイメージダイジェストに解決されて保存されます。よって、同じタスクをユーザーに公開することが可能になります。 先程と同様のシナリオで違いをみてみます。 ①タスク定義内のlatestタグに従い,2つのタスクが起動 ②開発者がlatestタグを更新（latestタグを新しいコンテナイメージへ参照先を変更する） ③タスクのスケールアウトが発生し,タスク定義内のlatestタグに従い,1つのタスクが新規起動 Announcing software version consistency for Amazon ECS services | Amazon Web Services Introduction Container image tags offer a user-friendly way to manage and keep track of different versions of container ... aws.amazon.com 検証 今回のアップデートを早速検証してみます。一貫性をオフに設定して、一連のデプロイでタスク間で異なるイメージダイジェストを参照していることを確認することがゴールとなります。 事前準備 VPC、サブネット、ルートテーブル、インターネットゲートウェイ、ネットワークACL、ECRが作成済みであることを確認してください。 ECRへコンテナイメージをpush nginx-helloリポジトリにイメージをpushします。 下記のdockerfileを利用して、コンテナイメージを作成します。 # ベースイメージとしてnginxの公式イメージを使用 FROM nginx:latest # "Hello, world!" を返すHTMLファイルを作成 RUN echo "Hello, world!" > /usr/share/nginx/html/index.html #80番ポートで公開 EXPOSE 80  Cloud9やCloudShell等のdockerインストール済みのサーバを用意して、上記のdockerfileをビルドします。 サーバのIAMロールには、下記の権限を付与しておいてください。 ・arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser docker build . -t <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest ECRへログインした後に、ECRのリポジトリにコンテナイメージをpushします。 aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com docker push <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest ECRのリポジトリ内にコンテナイメージが1つ格納されます。 CloudFormationテンプレート versionConsistencyプロパティを設定します。enabled/disabledを選択することが可能です。 Amazon ECS task definition parameters - Amazon Elastic Container Service Learn about the task definition parameters that you can use to define your Amazon ECS tasks. docs.aws.amazon.com 今回は、無効化するために”disabled”を設定します。 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: 2010-09-09 # --------------------------------- # パラメータ # --------------------------------- Parameters: Env: Type: String VpcId: Type: String PublicSubnetA: Type: String PublicSubnetC: Type: String MyIp: Type: String Resources: # ================================ # ECS (Cluster) # ================================ ECSCluster: Type: "AWS::ECS::Cluster" Properties: ClusterName: !Sub "ECS-${Env}-helloworld-cluster" ServiceConnectDefaults: Namespace: !Sub "ECS-${Env}-helloworld-cluster" CapacityProviders: - FARGATE # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld 　　　　　 versionConsistency: disabled Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/nginx-hello:latest" LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: latest PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-8080-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX # ------------------------------------------------------------# # Security Group # ------------------------------------------------------------# ECSServiceSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: ecs security group VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Ref MyIp SecurityGroupEgress: - IpProtocol: -1 FromPort: -1 ToPort: -1 CidrIp: "0.0.0.0/0" # ------------------------------------------------------------# # ECS Service # ------------------------------------------------------------# ECSService: Type: AWS::ECS::Service Properties: Cluster: !Ref ECSCluster DesiredCount: 2 DeploymentConfiguration: DeploymentCircuitBreaker: Enable: TRUE Rollback: TRUE MaximumPercent: 200 MinimumHealthyPercent: 100 DeploymentController: Type: ECS LaunchType: FARGATE NetworkConfiguration: AwsvpcConfiguration: AssignPublicIp: ENABLED SecurityGroups: - !Ref ECSServiceSecurityGroup Subnets: - !Ref PublicSubnetA - !Ref PublicSubnetC PlatformVersion: 1.4.0 ServiceName: !Sub "ECS-${Env}-helloworld-service" TaskDefinition: !Ref ECSTaskDefinition # ------------------------------------------------------------# # ECS LogGroup # ------------------------------------------------------------# ECSLogGroup: Type: "AWS::Logs::LogGroup" Properties: LogGroupName: !Sub "/ecs/ECS-${Env}-helloworld-service" Webサーバのコンテンツを確認 デプロイ済みのタスクのパブリックIPアドレスにアクセスして、コンテンツを確認します。 2つのコンテナどちらも”Hello, world!”が表示されます。   ECRへコンテナイメージを再push 下記のdockerfileを利用して、コンテナイメージを作成します。 # ベースイメージとしてnginxの公式イメージを使用 FROM nginx:latest # "Hello, world! Welcome" を返すHTMLファイルを作成 RUN echo "Hello, world! Welcome" > /usr/share/nginx/html/index.html #80番ポートで公開 EXPOSE 80  上記のdockerfileをビルドします。 docker build . -t <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest ECRのリポジトリにコンテナイメージをpushします。 docker push <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest 以下のように、ECRのリポジトリ内のlatestタグの参照先が更新されます。   タスクの再起動 今回は検証目的のため、タスクを手動停止することで新規タスクを起動させます。もしAuto Scalingが設定されていれば、スケールアウトでも同様に新規タスクを起動させることができます。 タスクを1つ選択後に、「選択されたものを停止」を押下します。続いて、「停止」を押下します。 すぐにタスクが停止され、新規タスクの再起動が始まります。 Webサーバのコンテンツを再確認 新規に起動したタスクのパブリックIPアドレスにアクセスして、コンテンツを確認します。 片方のコンテナでは”Hello, world! Welcome”が表示されます。コンテナイメージとしては、新しいバージョンのものを参照していますね。タスクの詳細を確認してみます。 新規に起動したタスクのイメージURIを確認すると、新しいバージョンのもの(新しいイメージダイジェスト)を参照していることが分かります。 ソフトウェアバージョンの一貫性がないことを確認できました。このようにタイミングによって、ユーザーには異なるコンテンツが提供されてしまいます。 まとめ 一貫性の設定をオフにすると、latestタグ運用時の問題が発生しますので本番環境への適用は控えてください。 メリット ECSタスク定義・サービスを更新して、再デプロイするという手間がなくなる。 「新しいデプロイの強制」をすることで、すぐに最新のコンテナイメージの内容がECSタスクに反映される。 デメリット コンテナイメージのpushのタイミングとECSのスケーリングのタイミングによって、異なるコンテンツを提供してしまう可能性がある。 ECRに格納されたイメージとECSタスクで起動しているイメージに差異が発生し、エラー特定が困難になる。 上記に伴い、切り戻し作業ができなくなる。 最後に いかがだったでしょうか。 latestタグの運用は非推奨の為、注意してください。 とはいいつつ、一貫性を任意に設定できることで、試用環境での利用には使えるのではないでしょうか。 まさにユーザーの意見を取り入れてサービスに反映させるAWSの「地球上で最もお客様を大事にする」理念というところでしょうか。 やっぱり選択肢が増えるっていいことですね！ 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは。ひるたんぬです。 最近は気温差が激しく、体調を崩しやすいですね。。私もこのビッグウェーブにしっかりと乗り、体調を崩しておりました。 そんなあるとき、ふと気になることがありました。 「なぜ、ティッシュは必ず二枚重ねなのか。。」と。 駅前で配っているポケットティッシュから保湿成分配合の高級ティッシュまで、必ずティッシュは二枚一組¹になっています。 気になって調べたところ、 紙には裏表があり、肌触りの良い面が必ず表面に来るようにするため 重ねることで空気の層ができ、柔らかさ・吸水性が向上する などといった理由があるそうです。身の回りの不思議がまた一つ解決してスッキリしました。 下記リンクを参考にしたのですが、私は小学5年生と同じ疑問を抱いていたようです。 参考： 朝日小学生新聞「ティッシュペーパーはなぜ２枚重ね？　４枚重ねは「贈り物」にも」 ¹ 今日では3枚・4枚と重ねている商品もあるようです。 …さて、今回は私が個人的な要件でAWSで開発を進めるにあたって、必ずと言っていいほどお世話になっているAmazon CodeCatalystを使って、AWS CloudFormationのテンプレートを快適に作成する環境を考えてみましたのでご紹介いたします。 このような記事の多くは、「CodePipeline」「CodeCommit」「CodeBuild」などのCodeファミリーを用いて作成されていることが多かったため、そのアイデアに着想を受け作成しております。 （CodeCommitについては、新規でAWSアカウントを開設した方は利用できなくなってしまったので…というのもあったりなかったり。。） CodeCatalystで作成することで、Codeファミリーと同等の機能が実現できることはもちろん、Issue管理や開発環境の管理も一元的に行える点がメリットだと考えています。 概要 今回は、CodeCatalystを使用して以下を満たす環境を構築することができます。 CloudFormationテンプレートファイルのソースコード管理 ➔ CodeCatalystの「Source repositories」を使用 CloudFormationテンプレートのコーディング（実装）環境 ➔ CodeCatalystの「Dev Environments」を使用 CloudFormationテンプレートのテンプレートチェック ➔ CodeCatalystの「Workflows」を使用して各種テストを実行 上記の内最後の各種テストでは、yamlファイルの構文チェック・CloudFormationテンプレートの構文チェック・TaskCatを用いて実際にデプロイしてチェックという3つのチェックを実施します。 今回の実装にあたり、参考にさせていただいたサイトは最後にご紹介しております。 TaskCatとは？ TaskCatとはCloudFormationテンプレートのテストツールです。簡単なコマンドと設定ファイルで、複数のリージョンに対してデプロイのテストを実施可能です。また、テスト結果のレポートについてもHTML形式やテキストファイルにて生成してくれます。 調べてみたところ、有志の方が作成したのではなく、AWSのチーム（aws-ia）にて提供されているツールなんですね。。 TaskCatの公式サイトや開発チームのサイトは以下をご覧ください。 taskcat aws-ia.github.io The AWS Integration & Automation team's best practices for Terraform AWS IA Terraform Module Standards aws-ia.github.io 実装例 CodeCatalyst上の任意のスペースに、新規でプロジェクトを作成します。私は「TaskCat」というプロジェクトを作成しました。 本記事では以降の手順について解説します。 CloudFormationテンプレートファイルのソースコード管理 CodeCatalystのSource repositoriesを使用します。 今回はCodeCatalyst上で新規にリポジトリを作成します。 名前以外はデフォルトで設定しました。 CodeCatalystではGitHub・GitLab・Bitbucketのリポジトリを連携して使用することも可能です。 また、今回のファイル配置は以下のとおりです。 . ├ cfn_template │ └ template.yaml ├ .cfnlintrc.yaml ├ .gitignore ├ .taskcat.yml ├ .yamllint.yaml ├ README.md └ junit_xml.py それぞれのファイルは下記のように作成しました。 template.yaml CloudFormationでデプロイしたいテンプレートファイルです。 今回は一例として以下のようなテンプレートファイルを作成しました。 --- AWSTemplateFormatVersion: "2010-09-09" Description: Sample CloudFormation Template Parameters: vpcIpv4CicdBlock: Type: String Default: 10.0.0.0/16 vpcNameTag: Type: String Resources: myVPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref vpcIpv4CicdBlock EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Ref vpcNameTag Outputs: myVpcId: Description: VPC ID Value: !Ref myVPC Export: Name: myVpcId .cfnlintrc.yaml CloudFormationテンプレートの構文チェックを実施する「cfn-lint」の設定ファイルです。 --- templates: - cfn_template/*.yaml .taskcat.yml テンプレートをデプロイしてチェックする「TaskCat」の設定ファイルです。 デプロイ先のリージョンの情報やパラメータの値を指定することができます。 --- project: name: sample-taskcat-project regions: - ap-northeast-1 tests: test-my-vpc: parameters: vpcIpv4CicdBlock: 10.10.0.0/16 vpcNameTag: test-vpc template: cfn_template/template.yaml .yamllint.yaml YAMLファイルの構文チェックを実施する「yamllint」の設定ファイルです。 --- yaml-files: - '*.yaml' - '*.yml' - '.yamllint' rules: anchors: enable braces: enable brackets: enable colons: enable commas: enable comments: level: warning comments-indentation: level: warning document-end: disable document-start: level: warning empty-lines: enable empty-values: disable float-values: disable hyphens: enable indentation: enable key-duplicates: enable key-ordering: disable line-length: enable new-line-at-end-of-file: enable new-lines: enable octal-values: disable quoted-strings: disable trailing-spaces: enable truthy: level: warning junit_xml.py TaskCatのテスト結果（テキストファイル形式）をjunit形式に変換するためのPythonスクリプトです。 こちらは参考サイトよりそのまま使用させていただきました。 これを実施することにより、CodeCatalystのワークフロー上でテスト結果を簡単に確認することができます。 import sys import os import xml.etree.ElementTree as ET def convert_to_junit_xml(log): # Create the root element testsuite = ET.Element("testsuite") # Create a testsuite element testsuite = ET.SubElement(testsuite, "testsuite", name="taskcat-cnf-development") # Parse the log and create testcases lines = log.split("\n") success_count = 0 failure_count = 0 for line in lines: if "CREATE_COMPLETE" in line or "CREATE_FAILED" in line: date, time, resource_status, resource_type, logical_resource_id, *rest = line.split() if len(rest) >= 6: resource_status_reason = ' '.join(rest) else: resource_status_reason = "" testcase = ET.SubElement(testsuite, "testcase", classname=resource_type, name=logical_resource_id) if resource_status == "CREATE_COMPLETE": ET.SubElement(testcase, "success") success_count += 1 else: ET.SubElement(testcase, "failure", message=resource_status_reason) failure_count += 1 # Add summary information testsuite.set("tests", str(success_count + failure_count)) testsuite.set("failures", str(failure_count)) # Return the string representation of the XML return ET.tostring(testsuite, encoding="unicode") if __name__ == "__main__": # Check if the log file path is provided as a command line argument if len(sys.argv) < 2: print("Please provide the path to the log file as a command line argument.") sys.exit(1) # Read the log file log_file_path = sys.argv[1] with open(log_file_path, "r") as file: log = file.read() # Convert the log to JUnit XML format junit_xml = convert_to_junit_xml(log) print(junit_xml) # Save the XML as a file named "report.xml" in the same directory as the log file log_file_directory = os.path.dirname(log_file_path) report_file_path = os.path.join(log_file_directory, "report.xml") with open(report_file_path, "w") as file: file.write(junit_xml) CloudFormationテンプレートのコーディング（実装）環境 CodeCatalystのDev Environmentsを使用します。 今回はVisual Studio Code上で操作可能な開発環境を設定します。 作成したリポジトリを取り込めるように設定します。 CloudFormationテンプレートのテンプレートチェック CodeCatalystのWorkflowsを使用します。 ワークフローとしては非常にシンプルです。 mainブランチへのプルリクエストをトリガーにワークフローが動作するよう設定しました。 また、実際のワークフローのコード（YAMLファイル）を以下に示します。 今回は実行環境をLambdaではなくEC2で実行するようにします。 Name: CheckTemplate SchemaVersion: "1.0" # Optional - Set automatic triggers. Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN # Required - Define action configurations. Actions: TestTemplateTask: # Identifies the action. Do not modify this value. Identifier: aws/build@v1.0.0 # Specifies the source and/or artifacts to pass to the action as input. Inputs: # Optional Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Outputs: # Optional; Automatically discover reports for popular test frameworks AutoDiscoverReports: Enabled: true # Use as prefix for the report files ReportNamePrefix: rpt # Defines the action's properties. Configuration: # Required - Steps are sequential instructions that run shell commands Steps: - Run: pip install yamllint cfn-lint taskcat - Run: yamllint ./cfn_template - Run: cfn-lint - Run: taskcat test run - Run: report=`ls -rt taskcat_outputs/*.txt | tail -n 1` - Run: python3 junit_xml.py $report Container: Registry: CODECATALYST Image: CodeCatalystLinux_x86_64:2024_03 Compute: Type: EC2 Environment: Name: dev 実際に動かしてみた では実際に開発→チェックまでの一連の流れを見てみましょう。 まずは、Dev EnvironmentsよりVisual Studio Codeの開発環境を起動します。 mainブランチより「dev」ブランチを作成し、その中で変更を実装していきます。 今回はAmazon Q Developerも活用してみます。 プロンプト入力画面を起動し、パブリックサブネットを追加してもらいましょう。 するとAmazon Qによりコードが生成されます。 パット見できていそうということで、変更を受け入れます。 Amazon Q Developerをはじめとした生成AIを用いた生成結果には誤りが含まれることがあります。 今回は一例を提示するのみでしたのでしっかりとは確認しませんでしたが、業務などで活用する際は生成結果をレビューするプロセスを挟むことを推奨します。 devブランチに変更をプッシュします。 これにより、devブランチが作成され、その中にパブリックサブネットを追加したテンプレートファイルが配置されています。 次に、devブランチからmainブランチにプルリクエストを作成します。 CodeCatalystのPull requestsより新規で作成します。 プルリクエストのタイトルは自分で入力し、説明文はAmazonQに記載してもらいます。 「Write description for me」のボタンを押下します。すると、変更文が生成されます。 生成された説明文は以下のとおりです。 The code change defines a public subnet, internet gateway, route table, and associated resources in an AWS CloudFormation template. The public subnet allows internet access for resources deployed within it. This configuration enables internet connectivity for resources deployed in the public subnet. パブリックサブネットが生成された旨がしっかりと表示されていますね。このまま「Accept and add to description」を押下します。 最終的に下の「Create」ボタンを押下します。これによりプルリクエストが作成されました。 プルリクエストが作成されると、ワークフローの動作が開始します。完了するまで気長に待ちましょう。 今回はyamllintのプロセスでエラーが発生しました。インデントがズレているというエラーですね。 コードを確認してみると、確かにズレていたため、修正しもう一度実行してみます。 今回はしっかりと実行できました。 また、「Reports」タブを押下することで、変換されたテストの結果を確認することができます。 今回の構築例ですと、TaskCatで構築に失敗した場合に後続の変換処理（junit_xml.pyの実行）が行われずスキップされてしまい、NG項目について確認することができませんでした。失敗時にも後続処理を実行する方法が執筆時点でも見つけることができませんでした。これは今後の課題です。 最終的にdevブランチで作成されたテンプレートファイルに問題がないことを確認できたので、プルリクエストを受け入れます。 追加の設定は行わず、「Merge」を押下します。 これにより、mainブランチにdevブランチの変更が反映され、devブランチがクローズされました。 おわりに 今回はCodeCatalystを用いたCloudFormationテンプレートの開発環境をご紹介しました。 TaskCatのレポート機能などに課題は残っておりますが、個人的には割と使いやすいな…と感じた次第です。 TaskCat以外の部分の開発環境につきましては、CloudFormationテンプレートの開発以外にも活用できるので、改めてCodeCatalystの有用性を知ることができました。 Amazon Q Developerと一緒に開発できれば、一人の開発も怖くなさそうですね。。 もっと使いこなせるようになったらAmazon Q Developer Proも検討しようと思います。 AI コーディングアシスタント - Amazon Q Developer の料金 - AWS Amazon Q Developer 向けの料金オプションをご確認ください。 aws.amazon.com 参考サイト 今回は以下のサイトを参考にCodeCatalyst版のフローを作成しました。 Cloud9・Codeサービス・Taskcatで実現するCloudFormationテンプレート開発環境を作る｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ CloudFormationテンプレートを開発するための環境構築を、AWS内で完結できるよう検討したので、その内容をまとめてみたいと思います。 blog.mmmcorp.co.jp

こんにちは。SCSK株式会社の上田です。 Zabbixに関する、 深刻な脆弱性 が発表されました。 この脆弱性は、 Zabbixのバージョン6.0.31、6.4.16、および7.0.0までのバージョン に影響します。 Zabbix公式の脆弱性サイト にはまだ掲載されていません（2024/11/29時点）が、速報として本記事で情報をお伝えします。 Zabbixをご利用の方は一度ご覧いただき、対象の場合はアップデート等のご検討お願い致します。 概要 Zabbix の API に、悪意のあるユーザーが権限を昇格させる可能性のある脆弱性 (CVE-2024-42327) が発見されました。 フロントエンドにおけるデフォルトのユーザーロールを持つか、 API アクセス権を持つ非管理者ユーザーが、この脆弱性を悪用してシステム管理者権限を取得する 可能性があります。 対象コンポーネント ZabbixのAPIに関連するコンポーネントが影響を受けます。 対象バージョン 以下の Zabbix バージョンが影響を受けます。 6.0.0 から 6.0.31 6.4.0 から 6.4.16 7.0.0 影響 攻撃者がこの脆弱性を悪用すると、Zabbixサーバーのデータベースに対して不正な操作を行うことが可能となり、システムの監視データや機密情報が漏洩するリスクがあります。また、データの改ざんや削除が行われる可能性もあります。 回避方法 この脆弱性を回避するためには、Zabbixの最新バージョンにアップデートすることが推奨されます。 6.0.32rc1 以降 6.4.17rc1 以降 7.0.1rc1 以降 最後に 弊社では本件に関してのお問い合わせもお受けしております。 ご相談事項がございましたら、以下ページよりお問い合わせいただければと思います。 お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp また、弊社では Zabbixのバージョンアップの支援 も行っております。 ご興味のある方は、是非弊社までお問合せください。 最後まで読んでいただき、ありがとうございました。 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com x.com

こんにちは。SCSKの中山です。   10月にAzureのvSocketが2ポート対応したので、今回は実際に2NIC VMを作成しつつ、既にAzureでvSocketを利用している方向けに移行する際のポイントを記載してみようと思います。   まず、最初に2NIC対応したことによるメリットから紹介していきたいと思います。 2NIC対応したことによるメリットは、ずばり コスト です！！   元々、AzureのvSocketは3NIC対応しているVMでしか作成することができませんでした。以前は3NIC対応しているVMの中でも、比較的コストを抑えて使えるマシンサイズ（Standard_D2s_v4）があったのですが、少し前にそのマシンサイズが使用不可になってしまい、現在では今回紹介する2NIC VMを含めて以下の2つが利用可能になっております。 マシンサイズ D8ls_v5 (3NIC、2NIC対応) D2s_v5(2NICのみ対応) 1か月あたりのコスト \40,131 \10,170 ※上記コストは2024/11/27時点の仮想マシンのみの概算になります。 上記の通り、2NICのVMを使うことでコストを比較してみると、1か月で3万円くらいの差が出てきます。 vSocketという都合上、VMは常に起動しておく必要があるため、低コストで利用できるというのは大変ありがたいです。   3NIC VMとの変更点 3NIC VMでは、MGMT、WAN、LANの用途でそれぞれNICを使っておりました。 2NIC VMではMGMTポートは統合され、WAN、LAN用の2ポートになっております。 MGMTがなくなったことによる機能的な変更点は、HA構成を含め特になく、元々MGMTポートで行っていた以下の2点はWANポートへ統合されております。 ・Socket UIへのログイン ・フェイルオーバー時のAzure APIとの通信(HA構成のみ) 作成方法 基本的には3NICの時と変わらないため、重複する部分は省略させていただきます。詳しくは以下のCatoのナレッジをご確認ください。 https://support.catonetworks.com/hc/en-us/articles/12274816079005-Deploying-Azure-vSockets-from-the-Marketplace ※( )は操作するサービス名を記載してます。   ①Site作成 (CMA) 詳細は割愛しますが、「Connection Type」を「vSocket Azure」にしてSiteを作成。   ちなみに以下は今回検証用に新規で作成したvSocketのSiteですが、Site作成時点からポートが2つになっておりました。   ②Marcket Placeより、vSocketを作成に進む。 (Azure)  「③Networking」の設定にInterfaceの数を設定する項目があるので、こちらを「2」で設定する。 それ以外は3NICの時と同様で、お使いの環境に合わせて設定をします。   ③作成したvSocketが認識されていることを確認する。 (CMA) 既存vSocketの移行について 既に3NIC VM（D2s_v5インスタンス）をご利用の方向けに、2NIC VMへの移行方法を書いてみようかと思います。 先に注意点を書いておくと、シングル構成の場合にはダウンタイムが発生してしまうため、作業にあたっては作業タイミング等にご注意いただくようお願いします。 こちらにCato公式から移行についての記事も出ておりますので、合わせてご確認いただくようお願いします。https://support.catonetworks.com/hc/en-us/articles/20558411383325-Migrating-Azure-vSockets-to-a-2-NIC-Solution   また余談ですが、最初に書いた比較的安い3NIC VM（Standard_D2s_v4）のマシンタイプは新しくデプロイはできないのですが、元々使っていたユーザーは引き続き利用することができております。しかし、サーバを停止すると次回以降起動できない状態になっているため、運用としては大変危険な状態になっております。コストが上がることを懸念して使い続けている方はこのタイミングで移行を検討いただければと思います。 Catoのナレッジにも書いてありますが、Standard_D2s_v4をご利用の場合には、先にマシンサイズを3NIC対応インスタンス(Standard_D8ls_v5)に変更する必要があります。   手順 ①Socketをv21にアップグレードする。 (CMA) こちらはまだv21でないSocketをご利用の場合のみ必要な手順になります。 今回の検証では既にv21以上であったため手順は不要になります。 ②Azure CLIにて、移行スクリプトを実行する。 (Azure) まずCatoより配布されている 移行スクリプト をダウンロードし実行します。   今回はローカルにAzure CLIがインストールされている環境がなかったため、Cloud Shellで実行します。 スクリプトでは以下の入力を求められますが、入力内容が分かりづらいので注意が必要です。 サブスクリプションID 対象のVMが入っているリソースグループ名 ロケーション(リージョン) 対象のVM(vSocket)名 取り外すMGMTで使用しているネットワークインターフェース WANで使用しているネットワークインターフェース ↓がサブスクリプションIDを入力している画面なのですが、 入力候補をリストアップしてくれはするものの手打ちで入力する必要があります。 また、値を間違えて中断すると再実行する必要があるため、入力に関してはコピペでの入力をおすすめします！ ③VMのマシンサイズを縮小する。 (Azure) ④Catoに接続されていることを確認する。 (CMA)   という感じで、Azure側ではInterfaceのデタッチとリサイズぐらいで移行できます。 最後に 今回はAzureでvSocketの2NIC対応について、記事を書いてみました。 途中でも書きましたが、vSocketは常に起動しておくサービスのため、安価なマシンタイプを使うことはコストに直結します。 機能面も変わりはないため、現在AzureでvSocketをご利用の場合には、リサイズをご検討いただければと思います。