実際にCatoクラウドを利用されているお客様から、Webサイトへのアクセスが失敗するといったお問い合わせをいただくことがあります。 今回は、実際に問題に直面された方の事象例やその対処法をご紹介したいと思います。 Webサイトへのアクセスが失敗するとはどういう状況か 実際にお問い合わせをいただいたWebサイトへアクセスができない事象について、下記のようなケースがありました。 ・WebサイトへアクセスをするとCatoの Block ページが表示されて先に進まない ・証明書エラーとなりページが表示されない ・「403 Forbidden」や「このサイトにアクセスできません」が表示されてしまう ・ページが正しく表示されない(テキスト表示になってしまう) 上記の状況でどのように原因を発見し解決してきたのかをご紹介します。 記事内に出てきます設定値はあくまでも例になります。 設定を行う際は、ご利用の環境に合わせて設定ください。 WebサイトへアクセスをするとCatoの Block ページが表示されて先に進まない Cato接続時に本来なら閲覧できるはずのWebサイトがなぜかBlockされるというお問合せをいただくことがあります。 その原因の大半はInternet Firewall (FW) により脅威のないサイトが意図せずBlockされていたというものが多いと感じました。 CatoクラウドのInternet FW は、企業のネットワークを保護するために不可欠ですが、時には意図しない形で正当な通信をブロックしてしまうことがあります。 今回は実際にあった２パターンのトラブル例と対処法について記載します。 Internet Firewallの詳細につきましては下記ブログをご参照ください！ CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 パターン1 Firewallの上位のルールでBlockされていた CatoクラウドのInternet Firewall (FW) は、ルールに基づいて通信を制御しますが、必要な通信が上位のルールで誤ってBlockされてしまっていたケースがあります。 問題の発見方法 CatoのBlockページやCMAのEventsをチェックして、どの機能のルールで通信をBlockしているのかを特定しましょう。 BlockページやEventsでの確認方法 まず以下画像のCatoのBlockページにて「Block Reason」を見てみましょう。 「Corporate Internet Policy Violation」と記載されており、インターネットポリシー(Internet FW)によってBlockされていることがわかります。 次にEventsを確認してみましょう。 [Monitornig]>[Events] 上記の場合は、フィルター機能で「Action」をBlock、「Domain Name」をアクセスしたサイトのドメインとして該当の通信を探しました。Blockされた通信ログを発見できたら「Sub-Type」と「Rule」を確認して、実際にどの機能のどのルールによりBlockされたのか確認してみましょう。 ・Eventsから通信を確認する際は、誰がいつどこにアクセスをしたのかを記録し、フィルターでログを絞ることで、該当する通信ログが発見しやすくなります。 ・「Sub-Type」を見ると、IPSやInternet FW等、Catoのどの機能で Block されているかがわかります！ トラブルシューティングを行うためにフィルター機能を活用していきましょう！ 対処方法 原因であるInternet FWルールを特定できたので、あとは上位に対象通信を許可するルールの追加や例外設定を追加することで事象は解消できます。 Blockルールに例外設定を追加する方法 Blockルールに例外設定を追加する場合はルール横の[…]をクリックし、「Add Exeption」をクリックください。 すると以下画像の設定画面が出てきますので、要件に合わせて例外設定を行ってください。 [Security]> [Internet Firewall] パターン2 異なるカテゴリに分類にされBlockされていた CatoのSWG（Secure Web Gateway）機能により、Webサイトの内容と異なるカテゴリに分類され、本来許可されるべきアクセスがInternet FWにより Block されてしまうことがあります。 問題の発見方法 パターン1と同じ手順で、EventsからInternet FWのどのルールによりBlockされたのかを確認してみましょう。 多い例として誤ってカテゴリが「Games」等に分類されてしまい、デフォルトの Block ポリシーに引っかかってしまうというものがあります。 対処方法 こちらもパターン1のように許可ルールや例外設定で回避することができますが、もっと簡単な方法は、カテゴリを手動で修正してしまうことです。 CMAの[Assets]>[App Catalog]の[Domain Lookup]タブからカテゴリの修正が可能です。 [Domain Lookup]からカテゴリ修正を行う方法の詳細については以下のブログ記事を参照ください！ Catoで業務通信がブロックされてしまう事象の解決策！～SWGで誤分類されたサイトを管理者で修正する機能～ Catoを使っていると、業務でアクセスするドメイン（URL）が誤ったカテゴリに分類され、通信できない！ということがあります。今回は、そんな問題が発生した場合の新しい回避策「カテゴリの手動修正」を紹介します。 blog.usize-tech.com 2024.02.22 証明書エラーとなりページが表示されない Catoクラウドでは、TLSインスペクション機能を通じてHTTPS通信のセキュリティを強化していますが、証明書の書き換えが許可されていないWebサイトへアクセスしてしまうと証明書エラーが発生してしまいページが表示されないケースがあります。 問題の発見方法 ブラウザ側でのエラーとなるため、Eventsを見てもBlockのログは表示されません。そのためブラウザ側で「この接続ではプライバシーが保護されません」、「このWebサイトのセキュリティ証明書には問題があります」といった画面が表示されたら、考えられる原因の一つとしてTLSインスペクション機能があることを頭に入れておきましょう。 対処方法 TLSインスペクションが原因で問題が起きている場合、Webサイトに対してTLSインスペクションを動作させないよう除外リストに追加することで回避ができます。 まず「Security」> 「TLS Inspection」から「New」をクリックしBypassルールを作成しましょう。 新しく作成するTLS Inspectionの名前を記載し、「What」の項目にてIP Range、Domain、FQDN等を設定します。 「Action」の項目では「Bypass」を選択します。 ※その他の設定は環境に合わせて設定ください。 以上が、TLSインスペクションの除外設定となります。 TLSインスペクション機能の詳細につきましては下記ブログ記事をご覧ください！ CatoクラウドのTLS Inspection機能で躓く証明書の仕組み Cato クラウドでHTTPS通信のセキュリティ対策を行うためのTLS Inspection機能で躓くことの多いTLS証明書関連の仕組みや課題について解説します。 blog.usize-tech.com 2023.10.06 「403 Forbidden」や「このサイトにアクセスできません」が表示されてしまう EventsではBlockのログは出ていないのに、「403 Forbidden」や「このサイトにアクセスできません」が表示されて正常にページが表示されない事例がございます。 原因の一つとして、Webサーバや、Firewall（UTM）において、JPNICのIPアドレスのみを許可しているといったように、日本からのアクセスのみに制限をしているため、Cato経由でのアクセスがブロックされるケースがございます。 なぜかというと、 Cato PoPのIPアドレスはJPNICでなく、上位のAPNICからIPアドレスを取得しているからです。 そのため、Webサーバ、Firewall（UTM）にて「日本のアクセスのみに制限する」や、JPNIC DBのみの制限を行われている場合は、APNICアドレスとなるCatoからのアクセスができません。 対処方法 2024/4/8時点での対処方法としましては、３つございます。 1.IPアロケーションで取得したグローバルIPアドレス(Egress IP)経由で、対象のWebサイトへアクセスするよう Network Rulesに設定し、サイト管理者へIPアドレスのアクセス許可依頼を行う。 Catoを利用したままサイトへのアクセスを行いたい場合は、Catoで確保したEgress IPをWebサイト側で許可してもらうことで閲覧が可能になります。 Egress IPとは何かご不明な方は、以下のブログ記事をご参照ください！ CatoクラウドにおけるEgress IP（送信元IP、出口IP）について CatoクラウドにおけるEgress IPについて解説します。 blog.usize-tech.com 2023.08.22 対応手順 まずCMAの[Network]>[IP Allocation]からEgress IPアドレスを取得しましょう。 ※標準で３つまで取得可能で、4つ目以降は有償となります。 次に、取得したEgress IPアドレス経由で、対象のWebサイトへアクセスを行うように[Network]> [Network Rules]から[New]をクリックして新しいNATルールの作成を行いましょう。 環境に合わせて設定いただき、App/Categoryには対象サイトのDomainもしくはFQDNを設定ください。 Routing MethodのRoute/NATで”NAT”を選択し、上記で取得したIPアドレスを設定しましょう。 NAT設定を行う際に「Preserve source port」という項目があります。 この設定はNAT変換時にIPヘッダ内のSource Portを保持する機能です。 一般的なWEBブラウジングなどの場合、ポート番号が変換されても影響ございませんので、チェックは不要です。 NATの設定が完了したら最後にWebサイトの管理者へ、設定したEgress IPを許可いただくよう依頼を行いましょう。 2.対象のWebサイトへのアクセスをCato経由で行わない そもそもCato経由でアクセスを行わないといった方法もございます。 Socket配下(拠点)接続の場合はBypass機能、SDPユーザ(モバイルユーザ)からの接続の場合はSplit Tunnel機能を利用することで、Catoを経由させず直接アクセスさせることができます。設定方法は以下をご参照ください。 ・Catoを経由させない設定のため、Catoによるセキュリティ検査、管理は行われません。 ・Bypass、Split Tunnel機能は、FQDNやドメイン設定は行えず、IPアドレスのみでの設定になります。 (2024/4/8時点) Socket配下(拠点)のBypass設定 [Network]>[Sites]からBypass設定を行いたい拠点を選択し、[Site Configuration]>[Bypass]をクリックします。 Destination(宛先)への通信もしくは、Source(送信元)からの通信をBypassするか選択ができますので、環境に合わせて設定ください。 設定の際は[New]をクリックください。 上記画像の設定項目から宛先もしくは送信元のIPアドレスを設定しましょう。 オプションとしてトラフィックプロトコルやトラフィックをインターネットに直接出力するポートを選択することもできます。 [Apply]、[Save]をクリックし保存を行うと設定が完了します。 SDPユーザのSplit Tunnel設定 まず、[Network] > [IP Ranges]から、[New]をクリックし除外したいIPアドレスを設定します。 [Apply]、[Save]をクリックして保存したら、次に[Access] > [Split Tunnel Policy]から[IP Ranges]で設定したIPを割り当てましょう。 [New]をクリックし、[Split Tunnel]セクションで[Exclude specific IPs]をクリックします。 ※[Exclude specific IPs]は、インターネットに直接ルーティングを行うという設定になります。 すると[Split Tunnel IPs]が出現しますので、上記で設定したIP Rangeを選択します。 ルールの対象となる[User/Groups]や[Platform]等のその他の設定については、ご利用の環境に合わせて設定ください。 最後に[Apply]、[Save]をクリックして設定が完了します。 3. Socket設置拠点に別のインターネット回線がある場合は拠点のインターネットからアクセスを行う こちらは利用例が少ないですが、Socket設置拠点に別のインターネット出口がある場合、Backhauling および Network Rules 設定をすることで、Cato PoPからではなく、拠点のインターネットからWebサイトへアクセスを行うことができます。 ・Network Rulesにて制御を行うため、FQDNやドメインでの設定も可能です。 ・BypassやSplit Tunnelとは異なり、Backhaulingを設定した特定拠点までの通信はCato PoPを通ります。 Backhauling設定の詳細につきましては以下のKnowledge Baseをご参照ください。 Just a moment... support.catonetworks.com ページが正しく表示されない(テキスト表示になってしまう) Cato経由でWebサイトへアクセスすると、画像など必要な部分が正しく表示されずサイトが崩れてしまっているように見える（テキストのみ表示されるように見える）ケースがございました。 一例といたしましては、Internet FWにてPrompt設定を行ったWebサイトで発生しました。 原因 事象が発生したWebページのレンダリングの一部が、Internet FWのPrompt設定によりブロックされてしまっていたためでした。 Internet FWのPrompt設定とは一致するトラフィックをメッセージ付きのWebページにリダイレクトし、ユーザーに対して続行するかどうかを決定するようにさせる設定です。 対処方法 ページ内でブロックされているドメインを確認し、Internet FWルールの例外に設定することで回避が可能です。 本項では、一例としまして、Internet Firewallにてアプリケーション”Fire Storage”をPrompt設定した際の対処方法を記載します。 まず、ブロックされているドメインの確認（Chromeの場合）を行いましょう。 該当のWebサイトへアクセスし、「Prompt」されたページへ遷移します。 次にブラウザから[設定]＞[その他のツール]＞[デベロッパーツール]＞[Console]タブをクリックし開き「Prompt」ページから「進行する」をクリックし、実際のWebページへ遷移します。 [Console]タブに表示されたURLを確認し、ブロックされているドメインの中から、 Webページに関連しているドメインを記録します。 ※例として、Firestorageのサイトの場合は、「firestorage」が入っているドメインを記録します。 ※なお、ドメインはFilterで絞ることも可能です。 ※Edgeの場合は、[設定]＞[その他のツール]＞[開発者ツール]からご確認いただけます。 Blockされているドメインが判明したので、Internet FWルールで例外設定を行いましょう。 まず、Internet FWルールより、[Prompt]設定をしているルールから[…]＞Add Exceptionをクリック。 作成された[Exceptions]のApp/Categoryに、上記で記録したドメインを入力します。 ※その他の設定は環境に合わせて設定ください [Apply]、[Save]で設定が完了です。 設定完了後、Webサイトへアクセスすると、表示崩れは改善されていました。 まとめ 本投稿では、Cato経由でのWebサイト接続のトラブル例とその対処法について説明いたしました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

こんにちは。SCSKの山口です。 今回は、案件業務で活用した「BigQuery 上に大量テーブルを一括作成する便利な方法」をブログ化します。 私はこの方法で約900のテーブルをBigQuery 上に一括作成しました。   BigQuery テーブル作成方法 BigQuery 上にテーブルを作成する際は、コンソール上で作成する方法とデータ定義言語（DDL）ステートメントを使用する方法があります。 https://cloud.google.com/bigquery/docs/tables?hl=ja#create-table コンソール上で作成する方法は、直感的にテーブルを作成することができ大変便利です。 しかし、大量のテーブルを作成したい際は天文学的な時間を要してしまい、もうBigQuery のコンソールミタクナイ、、、とグロッキーになってしまう可能性があります。 皆さんにBigQuery LOVEのままでいてもらうために、今回はDDLを連続的に実行してBigQuery 上にテーブルを一括作成する方法をご紹介します。   実践：DDLを連続的に実行しBigQuery テーブルを一括作成する DDLファイル ・今回はお試しとして、以下の5つのDDLを準備します testDDL1.ddl — testDDL1.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test1 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL2.ddl — testDDL2.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test2 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL3.ddl — testDDL3.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test3 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL4.ddl — testDDL4.ddl CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test4 ( `clm1` STRING, `clm2` STRING, `clm` STRING ) ; testDDL5.ddl — testDDL5.ddl CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test5 ( `clm1` STRING, `clm2` STRING, `clm` STRING ) ;   Pythonスクリプト 今回はBigQuery 用のPython用のクライアントライブラリを使用して、PythonスクリプトからDDLファイルを実行します。 以下が今回作成したPythonスクリプトです。 execDDL.py ”’ execDDL.py”’   import os from google.cloud import bigquery   # DDLファイルのパス ddls_path = ‘/home/sho_yamaguchi/Blog/execDDLs/DDLs’   # SQLファイルのリストを取得 ddl_files = [f for f in os.listdir(ddls_path) if f.endswith(“.ddl”)]   for ddl_file in ddl_files:     # DDLファイルのパス     ddlfile_path = os.path.join(ddls_path, ddl_file)       # DDLファイルの内容を取り込む →query     with open (ddlfile_path, encoding=’utf-8′)as f:         query = f.read()       # BigQuery クライアント作成     client = bigquery.Client()       # クエリ実行     query_job = client.query(query) 今回のPythonスクリプトは「ファイルを開く→内容をクエリとして取り込む→クエリ実行」という作りにしています。   後はPythonスクリプトを実行するだけです。 実行結果 Pythonスクリプト実行後の対象データセット内は以下の通りです。 狙い通り5つのテーブルが作成されていますね。 ジョブ履歴からもDDLが実行されていることが確認できました。 まとめ 今回はDDLを連続的に実行してBigQuery 上にテーブルを一括作成する方法を実際にやってみました。 DDLファイルの量が多くなるとその分時間ががりますが、一度スクリプトを流してしまえば放置でOKなのでとても楽です。 今回のPythonスクリプトの作りとしては、「ファイルを開く→内容をクエリとして取り込む→クエリ実行」という単純な作りなので、 アイデア次第でテーブル作成以外の他のことにも使えそうですね。 最後まで読んでいただきありがとうございました。

オフィス拠点にCato Socketを設置してCatoクラウドに接続する際に契約帯域を決める必要がありますが、いったい何Mbpsで接続すればよいか悩まれる場合もあるかと思います。今回は帯域選定についての話です。 はじめに Cato接続で帯域を意識するのは図1でいうとA・B・Cの3か所ですが、今回取り上げるのは 「図1- A」 の拠点接続の部分です。 「図1-B」 は社内サーバがあるデータセンターなどの接続部分です。ここの帯域決めはお客様によってかなり差があるので、既存回線のトラフィック量をベースにサイジングしないと難しいです。同じくらいの拠点数やユーザー数のお客様でも100Mbpsで足りてるケースもあれば500Mbpsでフルフルのケースもあります。 「図1-C」 はインターネットへの出口となる箇所です。オンプレ環境の場合はFirewallのスループットやセッション数を気にする必要がありますが、Catoでは利用者側で管理する必要はありません。 図1. Catoで考慮が必要な帯域 お客様との会話の中で 「図1-A」 の帯域選定の話になった時、我々からお伝えしているのは以下の通りです。 既存回線のトラフィック利用状況の情報をベースにする。 帯域の増速は随時できるが減速は契約更新月にしかできないので、スモールスタートが原則。 SCSKでは、 帯域の拡張(増速)を行う場合15時までにご注文いただれば当日中に拡張を行うことが可能です！ 拠点の通信量はある程度ユーザー数に依存しますので、拠点の帯域とユーザー数の関連性を調べてみてみました。 尚、実際の通信量はユーザー数だけではなく業務内容やアプリケーションの種類も関わってきます。一概にユーザー数だけという訳ではないので、あくまで参考情報として捉えて下さい。   拠点の帯域サイジングはざっくり「1ユーザー＝1Mbps」 まず、当社でご契約いただいている利用帯域の割合を調べたところ、図2の通りCatoのミニマム帯域である25Mbpsが6～7割を占めていました。ユーザー数がさほど多くない支店や営業所には25Mbpsを割り当てて利用しているという状況が推測されます。 図2. 契約帯域の割合 では、25Mbpsの利用拠点はどのくらいのユーザー数なのでしょうか？ 図3は、Cato Management Application（CMA）で確認した25Mbps拠点の接続Host数の割合です。 尚、Host数はサーバー等も含めた数なのでユーザー数とイコールではありません。ここからはCMAで表示される「Host」を単位として記載しますが、ただ25Mbps拠点にサーバがあるのは稀かと思いますので、ほぼユーザー数とみてもよいでしょう。 図3. 25Mbps拠点の接続Host数 25Mbps拠点は、20Host以下の拠点が半分を超え30Host以下の拠点が約75%という状況でした。 これらの拠点の平日日中の通信量をCMAのMonitoringでみると、20～30Hostの拠点では一日のうち25Mbpsに達する時間帯もありますが、いわゆるトラフィックの張り付き状態ではありませんでした。10Host以下の拠点だとピークでも25Mbpsに達しないという状況でした。 対して40Hostくらいの拠点になると日中時間中ずっと25Mbps上限に迫るくらいの通信量で、80Host超の拠点はトラフィックの張り付き状態が継続しているといった感じでした。 同様に50Mbps接続拠点のHost数もみてみましょう。 図4. 50Mbps拠点の接続Host数   結果は50Hostの拠点が50%弱、75Hostの拠点が75%という状況でした。 平日日中の通信量をみると、50Hostくらいまでならまだ余裕があり60～70Hostになると通信量が多いなと思える状態でした。 これらの結果から、拠点の帯域選定を行う際は「1Host（ユーザー）＝1Mbps」を一つの目安にする事ができるのはと考えています。 但し、もっと高帯域の100Mbps以上の拠点をみると、拠点によって通信量がまちまちで参考にならないものでした。 因みに、100Mbps拠点は10Hostから800Host以上の拠点があり、平均すると180Hostでした。 800Hostを超える拠点も複数あるのですが、必ずしもトラフィックが張り付いているという訳ではないところが不思議です。 2024年のCatoクラウドサービス改定に伴い、従来のサービスメニューにあった75Mbpsや200Mbpsは存在しませんのでご注意下さい。2024年4月現在のサービスメニューでは、25Mbps・50Mbps・100Mbps・250Mbps・500Mbps・・となります。   数が多い小規模拠点にはPooledライセンスがマッチ 話は変わって、少人数多拠点のネットワークなどで10Host未満の拠点が多数ある場合は、Pooledライセンスがマッチするかもしれません。 1拠点10Host未満の拠点や常時PCを使用しないようなトラフィックが少ない拠点であれば25Mbpsでもオーバースペックと言えます。その場合は、通常のSiteライセンスではなくPooledライセンスをご契約いただければ、最低10Mbps単位で各拠点に帯域を割り当てる事ができるので25Mbpsのライセンスを拠点分ご契約いただくよりコストメリットが出る場合があります。 尚、Pooledライセンスは1Gbps以上での契約となります。以下は1Gbpsを各拠点に割り当てる場合の例です。 例1 データセンター：100Mbps 拠点：10Mbps×90拠点 例2 データセンター：100Mbps 拠点：10Mbps×70拠点、20Mbps×10拠点 例3 データセンター：100Mbps 拠点：10Mbps×70拠点 残りの200Mbpsを在庫として確保しておき、通信量が増えた拠点に帯域を追加したり、期間限定の拠点用に割り当て、閉鎖になったらまた在庫として保持する事ができます。 Pooldライセンスを含むCatoクラウドのサービス料金については以下の記事を参照下さい。 Catoクラウドのサービス体系について（2024年最新版） 2024年2月以降のCatoクラウドの新しいサービス体系（基本料金、オプション料金、マネージドサービス）について解説を行っています。 blog.usize-tech.com 2024.01.29   少規模拠点はSDPユーザー接続で済ますことも また、ユーザー数が少ない拠点はSocketを設置せずSDPユーザーだけでCatoに接続する事も可能です。但しSocketを使用しない事による制限や運用管理面でのデメリットが生じます。 詳しくは以下の記事を参照下さい。 Cato Socketを拠点に設置せず、SDPユーザのみで利用する場合の留意点 ユーザしかいない拠点を前提に、Socketを設置しないデメリットを解説します。 blog.usize-tech.com 2023.08.29   最後に 帯域選定の話から脱線してしまいましたが、PooledライセンスやSDPユーザーの事例をご紹介させていただきました。 帯域をどうするか？接続方式をどうするか？については、最終的にはコストと機能面/管理面のトレードオフの話になるかと思います。 SCSKでは、お客様のネットワーク特性・利用状況を考慮して最適な帯域選定をご支援させていただきます。

こんにちは。SCSKの江木です。 Google Cloud Next ’24 Las VegasのKeynoteにて様々なサービスが発表されました。 発表されたサービスの中で、BigQuery Data Canvas（preview）というものが気になったので触ってみました。 Keynoteにて発表されたサービスについて詳しく知りたい方は以下を参照ください。 【現地速報】Google Cloud Next ’24 Las Vegas Keynoteまとめ。 Google Cloud の旗艦イベントである『Google Cloud Next '24』がMandalay Bay, Las Vegasにて開幕しました。 今回は基調講演で発表された新サービスをいち早くお知らせします。 blog.usize-tech.com 2024.04.10 そもそもBigQueryとは？ ご存知の方も多いと思いますが、 BigQuery とは、Google Cloud Platformが提供する、エンタープライズ向けデータウェアハウスサービスです。 ペタバイト級のデータも高速処理できる超高速なデータウェアハウスで、サーバーの管理も不要、標準SQLによるクエリで簡単にデータ分析が行えます。 詳しくは以下のドキュメントを参照してください。 BigQuery の概要  |  Google Cloud cloud.google.com BigQuery Data Canvasとは？ BigQuery Data Canvasは、 データ分析ワークフローを視覚的に構築、管理、実行できる 、BigQueryの新しい機能です。 Gemini を使用しており、データの検索、SQLの作成、グラフの作成などを行うことができます。 詳しくは以下のドキュメントを参照してください。 Analyze with data canvas  |  BigQuery  |  Google Cloud Gives an overview and instructions on working with a data canvas, a feature designed to help users use natural language ... cloud.google.com 実際にさわってみた！！ それでは実際に触っていきます。参照するテーブルを準備した後、キャンバスを使って分析していこうと思います。 テーブルの準備 参照するテーブルを作っていきます。 ① BigQueryコンソールのBigQuery Studioにて、[SQLクエリを作成]を押下します。 ② ペンのようなマークを押下すると、[コーディングをサポート]という画面が出るので、下記のように入力し、[生成]を押下します。 ※データセットはUSリージョンのものを使用してください。 ※今回はGoogle Cloudの公開データセットである「About COVID-19 Public Dataset」を使用します。このデータセットの先頭500個のデータを読み込んでテーブルを作成し、参照するテーブルとします。 ③ SQLクエリが生成されるので、[挿入]を押下します。 ④ [実行]を押下し、テーブルを作成します。 以上でテーブルの完成です。 キャンバスの作成 それではキャンバスを作っていきます。 ① 家マークを押下し、以下の画面に遷移した後、[データキャンバスを作成]を押下します。 ② 先ほど作ったcovid19_open_dataを選択します。 ③ テーブルが読み込まれました。このテーブルに対してクエリを実行したいので、[クエリ]を押下します。 ④ location_key、date、population、population_male、population_femaleの4つの列を抽出しようと思います。以下のようにコンソールに入力し、▻を押下します。 ⑤ クエリが生成されるので、[実行]を押下すると、クエリ結果が表示されます。 ⑥ ⑤の結果に対して、location_keyが何種類あるのか確かめてみたいと思います。[これらのクエリに対してクエリを実行する]を押下し、以下のようにコンソールに入力します。最後に▻を押下すると、クエリが生成されます。 ⑦ [実行]を押下すると、以下の通り、結果が返ってきます。 ⑧ ここで、⑤の結果から、dateが2021-05-06であるデータを抽出してみます。⑤で作成したノードの[これらのクエリに対してクエリを実行する]を押下します。 ⑨ ノードが分岐して作成されるので、以下のようにクエリ生成を指示し、▻を押下します。 ⑩ クエリが生成されるので、[実行]を押下すると、以下のような結果となります。 ⑪ このクエリ結果から円グラフを生成しようと思います。以下の画面ように、【可視化】→【円グラフの作成】を押下します。 ⑫ 円グラフが作成されました！英語になっていますが、説明もつけてくれています。   以上でキャンバスの作成を終わります。作成したキャンバスの全体像は以下の通りです。   おわりに 今回はBigQueryの新機能であるBigQuery Data Canvasを触ってみました。 SQLクエリを一切書くことなく、テーブルを分析することが出来ました。SQLに抵抗がある方にはかなり嬉しい機能ではないでしょうか？ また、過去のクエリ実行結果を簡単に見返すこともできるので、非常に便利であると感じました。 今後も新しいサービスを触っていきたいと思います！ 最後まで読んでいただきありがとうございました！！

Amazon Cognito User PoolにIdentity ProviderとしてOktaを追加することにより、ユーザー認証が可能なのか調べる機会がありました。今回はOktaで管理されているユーザーを用いてService Provider（Cognito）経由でサインインし、ユーザー認証後の処理としてCognitoからアクセストークンの取得を試みました。 やりたいこと Cognitoに新規ユーザーを作成する事なく、作成済みのOktaユーザーを利用してユーザー認証を行い、SAML認証応答をCognitoに送信しアクセストークンを取得してみたいと思います。今回行う要求応答についての関係性は下記図を想定しています。   事前準備 Cognitoでユーザープールを作成しておきます。 チュートリアル: ユーザープールの作成 - Amazon Cognito ユーザープールを使用すると、ユーザーは Amazon Cognito 経由でウェブまたはモバイルアプリにログインできます。 docs.aws.amazon.com   Oktaの設定 SAMLアプリ統合を作成 OktaダッシュボードからApplicationsを展開し「Create App Integration」をクリックすると下記図が表示されます。今回はIdentity Provider(Okta)⇔Service Provider(Cognito)間でSAML認証を行う為、「SAML2.0」を選択し、次のページで任意のアプリケーション名を入力して進めます。 SAMLアプリ統合を作成する | Okta help.okta.com SAML 2.0セットアップ SAMLアプリ統合内の設定として、Service Provider（Cognito）に関する設定を行います。ここでは、事前準備で作成したCognitoの情報を以下の形式で入力します。 Single sign-on URL　https://<Your user pool domain>/saml2/idpresponse Audience URI (SP Entity ID)　urn:amazon:cognito:sp:< region_EXAMPLE> ユーザープールへの SAML ID プロバイダーの追加 - Amazon Cognito ユーザープールへの SAML ID プロバイダーの追加。 docs.aws.amazon.com ユーザープロファイル属性の設定 SAML Settingsにおける属性ステートメントはService Providerに提供される属性となります。Service Provider⇔Identity Provider間で認証に必要となるユーザー情報として、今回はName属性を１つだけ（email）設定して、SAMLアプリ統合を作成します。 SAMLメタデータを取得 SAMLアプリ統合内「SAML Signing Certificates」のType「SHA-2」のActionsより［View IdP metadata］を確認し、表示された内容を拡張子xmlとして保存します。 認証用ユーザーのアサイン OktaユーザーをSAMLアプリ統合にアサインします。「Assignments」タブより、「Assign」をクリックし、「Assign to People」画面で認証用ユーザーのアサインを行います。   Amazon Cognitoの設定 CognitoでOktaを Identity Provider として設定 Cognitoの「サインインエクスペリエンス」タブより、「フェデレーテッドアイデンティティプロバイダーのサインイン」から「アイデンティティプロバイダーの追加」をクリックし、アイデンティティプロバイダーにSAMLを指定し、プロバイダー名を入力します。 SAML属性の設定 Okta側で取得したSAMLメタデータのxmlファイルをアップロードします。 次にOktaからのSAMLアサーションに含まれるSAML属性をCognitoユーザープール属性にマッピングします。 アプリクライアントの作成と設定 Cognitoのユーザープールでアプリクライアントを作成し、認証情報を設定します。 注意点としては、ホストされたUI設定内で、「許可されているコールバック URL」に任意のクライアントアプリケーションのURLを指定します。本設定を行わない場合、ユーザー認証後のリダイレクト先が無く処理が止まるので、忘れずに設定します。 Amazon Cognito でホストされた UI およびフェデレーションエンドポイントの設定と使用 - Amazon Cognito モバイルまたはウェブアプリの Amazon Cognito ユーザープールへの統合 docs.aws.amazon.com   クライアントの設定 クライアントアプリケーションの設定 クライアントアプリケーションからCognitoユーザープールのフェデレーションエンドポイントを呼び出す設定をします。 OAuth 2.0、OpenID Connect、および SAML 2.0 フェデレーションエンドポイントリファレンス - Amazon Cognito このドキュメントでは、Amazon Cognito ユーザープールのホストされた UI、SAML 2.0、OpenID Connect、および OAuth 2.0 の認証および認可エンドポイントについて説明します。これらのエンドポイントは、... docs.aws.amazon.com   動作確認 Oktaユーザーによる認証リクエスト クライアントアプリケーション（今回はPostman）からCognitoフェデレーションエンドポイントを呼び出すとOktaへリダイレクトされ、折り返してサインイン画面が表示されるので、Oktaに登録されているユーザー情報を入力してサインインします。 アクセストークンの取得およびCognitoの状態確認 Oktaでユーザー認証結果をクライアントアプリケーションで受け取り、Cognitoにリダイレクトします。CognitoでAuthorization Codeの確認を行い問題無ければクライアントアプリケーションにアクセストークンを送信します。 Oktaユーザーで認証を行う場合、ユーザー状態はどのように認識されるのか確認したところ、「確認ステータス」で「外部プロバイダー」と表示されており、Cognito User Pool内部に作成されたユーザーとは識別できそうです。   まとめ 本記事では、Amazon Cognito User PoolのIdentity ProviderにOktaをセットアップし、以下の流れを試しました。 Client ApplicationからService Providerのフェデレーションエンドポイントを呼び出す。 Service Providerはユーザー認証要求をIdentity Providerにリダイレクトする。 Client ApplicationからIdentity Providerのログイン画面でIdentity Providerに所属するユーザーを利用してログインする。 Identity Providerでユーザー認証応答を作成する。 Identity ProviderからClient ApplicationへSAML認証応答の送信を行う。 Client ApplicationからService ProviderへSAML認証応答を送信する。 Service ProviderでSAML認証応答を検証し、検証結果をClient Applicationへ返却する。 Client ApplicationからService Providerへアクセストークンを要求・応答を受け取る。 以上の結果から、Amazon Cognitoに新規ユーザーを作成する事なく、作成済みのOktaユーザーを利用してユーザー認証を行い、アクセストークンを取得する事ができました。

こんにちは。SCSKの島村です。 Google Cloud の旗艦イベントである 『Google Cloud Next ’24』 が Mandalay Bay, Las Vegas にて開幕しました。 現地時間４月9日（月）-11日（木） の3日間にわたり基調講演や、先進事例セッション、テーマ別のブレイクアウトセッションなどなど、 最新の技術革新、Genarative AIからセキュリティまで, Google Cloud のあらゆることに関するセッション がご用意されております。また、 この度当社は、 Google Cloud Social Impact Partner of the Yearを受賞 しました。 Enterprise向けに画像（外観検査AI）や音声（コンタクトセンターAI）とマルチモーダルなデータを活用し、お客様課題解決、社会に新たな価値創出したことが認められ受賞に至りました。 —プレスリリースの詳細はこちらから— 国内企業で初受賞「Google Cloud ソーシャルインパクト パートナー オブ ザ イヤー」を受賞 (scsk.jp) 本記事では、3日間に及ぶGoogle Cloud Next ’24 Las Vegas の「 Day1開幕速報 」として、現地の最新情報を共有できればと思います。 [速報] Opening Keynote（Tuesday,April 09,09:00 AMPDT） 概要 本日（日本時間：4月10日2時0分）からKeynoteセッションが行われました。 現地速報として、リリースされた新サービスの情報並びに会場の雰囲気をいち早くお伝えします。 ＊各サービスの詳細については、後日追って共有いたします。 Keynoteアーカイブは以下,Google Cloud 公式Youtubeから確認可能です。 [現地写真] Keynote HALL会場の様子 @Michelob Ultra Arena-Opening Keynote：The new way to cloud 入口では「入場制限」がかかるほどの熱量で、セッションのスタートと同時に会場は大盛り上がりでした。 Keynoteにて発表されたサービス 新たに発表されたサービス一覧 ＊各サービスの詳細については、後日追って共有いたします。次回のブログをお楽しみにしていただければと思います。 General Availability 　 A3 Mega VMs 2x netowork bandwiseに対応したVMs Coming Soon NVIDIA GB200 NVL72 30x 高速なリアルタイム大規模言語モデル (LLM) 推論を支えるGPU General Availability 　 TPU v5p AI向け最先端TPU   Preview   Hyperdisk ML 最新世代のネットワーク ブロック ストレージサービス General Availability Dynamic Workload Scheduler リソースへのアクセスとAI/MLワークロード最適化 General Availability GKE Enterprise Software on GDC GDC上でのエンタープライズ向けGKEソフトウェア General Availability AI Models on GDC GDCで提供されるAIモデル群 General Availability Vector Search on GDC GDC上でのベクトル検索サービス General Availability Vertex AI Solutions wirth GCD GCDを活用したVertex AIソリューション General Availability Sercret and Top Sercret Acceditaions 機密・最高機密情報取扱いに係るアクレディテーション Coming Soon Google Axion Processors 生成AI処理向け独自CPU   Preview   Gemini 1.5 Pro AI処理リソースを抑え性能向上を実現する最新言語モデル General Availability Claude 3 Anthropic  Anthropic社のstate-of-art modelを利用可能 Open model CodeGemma 予測コーディングと生成モデリングを組み合わせたモデル   Preview   Supervised Tunig for Gemini Models Geminiモデル向けの教師ありチューニングオプション   Preview   Grounding with Google Search Google検索を基にしたグラウンディングサービス   Preview   Prompt Management プロンプトを用いたAIモデル管理機能 General Availability Automatic Side-by-Side(AutoSxS) 自動結果比較を可能としたサービス   Preview   Rapid Evaluation 高速モデル評価とフィードバックシステム General Availability Vector Search Google Search like qualityのベクトル検索機能 General Availability [Google workspaces]AI Meetings and Messaging Add-on $10/user/monthのAI会議・メッセージングアドオン General Availability [Google workspaces]AI Security Add-on AI技術を活用したセキュリティ強化アドオン   Preview   [Google workspaces]Gemini in Google Chat Google ChatでのGemini統合機能 Coming Soon [Google workspaces]Google Vids 動画生成アプリケーション シンプルなインターフェイスで手軽に動画を作成可能 General Availability Imagen 2.0 最先端のテキストから画像への生成モデル   Preview   Text-to-Live Image 高度なテキストからライブ画像へのモデル General Availability Digital Watermarking デジタルウォーターマーキング機能 General Availability New Editing Models in Imagen 2.0 Imagen 2.0における新しい編集モデル   Preview   Gemini in Bigquery Gemini x BigQueryの統合機能   Preview   BigQuery Data Canvas Geminiを活用したBigQueryのデータキャンバス機能   Preview   Vector Indexing in Bigquery and AlloyDB BigQueryとAlloyDBに対するベクトル検索機能   Preview   Direct Access to Vertex AI from BigQuery BQデータを直接VertexAIにインポートできる機能   Preview   Gemini in Looker Looker画面を通じてデータxGenAI対話機能提供   Preview   Gemini Cloud Assist Cloud Assistの為にGemini機能提供   Preview   Gemini in Threat Inteligence 会話型検索を使用した最新の脅威分析   Preview   Gemini in Security Command Center 構成ミスや脆弱性に関するリスク検知 新サービスが多数発表されました。 セッションでは、デモを用いたサービス紹介が行われ、都度、会場からは歓声が上がっていました。 また、詳細について発表されていないものもあり、今後が楽しみです。     おまけ：現地会場（ Mandalay Bay ）の様子 今回のGoogle Cloud Next ’24 は、『Las Vegas Mandalay Bay』にて開催されました。 日本とラスベガスの時差は、16時間程度で朝夕は肌寒く、日中は過ごしやすい気候でした。くらいでした。 会場MAP Next 24 Main Venue: Beach - Mandalay Bay Located on 11 lush acres, Mandalay Bay Beach is a world-famous aquatic playground featuring 2,700 tons of real sand, a 1... mandalaybay.mgmresorts.com   最後に 今回はGoogle Cloudの旗艦イベントである Google Cloud Next ’24 Las Vegasについて開幕現地速報をお届けしました。 本日から3日に渡るイベントをGoogle Cloud のPartnerとして一緒に盛り上げていければと思います。 現地では、会場の雰囲気も味わうことができ、Google Cloud の熱気も感じることができました。 また、新サービスの発表もあり日本に帰国してからより詳しい内容については調査・整理し、本ブログにて情報発信できればと思います。 今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！

    Smartdbxとは？ 前回の振り返りです。Smartdbxとは何か？についての続編になります。 前回の記事は以下をご確認ください。 Smartdbxとは？~Dropbox統合管理ツール~ SCSKではDropbox管理業務負荷の軽減及びエンドユーザの利便性を向上させるためのDropbox統合管理ツールとして「Smartdbx」を開発いたしました。 blog.usize-tech.com 2024.03.22 Smartdbxは、Dropboxの管理者の業務負荷の軽減やエンドユーザの利便性を向上させるためのツールです。 フォルダ管理については自動化を行い、社外の共有については上長の承認を、アクセス権管理についてもツールを通し一括管理を実現できます。 「Smartdbx」には管理者業務を自動化する事で、管理者業務自体を極力なくし、管理者の運用負荷を軽減させる機能が用意されております。 SmartdbxとDropbox と組み合わせてお使いいただくことでもっと便利に、効率的にDropbox をご利用いただくことができます。 弊社がDropboxの管理ツール開発を始めたのは2017年からになります。 ——————————————————————– 2017年 　ONEUPの開発・運用 Dropboxを導入した時から社内の運用管理の負荷低減、効率アップを目的としたツール（社内呼称：ONEUP）を開発、運用しています。 2022年 　外部共有の管理機能をリリースして機能拡張 2023年 　Smartdbx開発 —————————————————————— ONEUPに更に多くのDropboxプロジェクトで培った知見を取り入れ、多くのお客様からご要望が多い有益な機能をSmartdbxとして実現しました。 機能 機能詳細 基本/オプション アカウント/グループ管理機能 •人事マスタ(組織と人)と自動連係 •Dropboxのアカウントおよびグループの連係 •アカウント情報の照会 •グループ情報の照会 基本機能① 共有フォルダ管理 •共有フォルダ管理機能 •共有フォルダ承認ワークフロー •共有フォルダ棚卸機能 サブフォルダ含みの棚卸しのみ、順次リリース(可視化機能として) •共有フォルダアーカイブ機能 (順次リリース) •フォルダテンプレート 基本機能② 社外共有フォルダ監視 個人フォルダや、共有フォルダ申請で申請されたチーム外共有以外の社外共有の監視・ブロック機能 基本機能③ 全社ナレッジ共有 1,000人以上となるような大規模環境での全社共有するフォルダ管理機能 オプション① カスタムドメイン（ファイル送受信） 社外の方とのファイルの受渡をDropboxドメインを使わずに実現する機能 オプション②   機能紹介 Smartdbxのご紹介記事は2回目になりますので、今回はオプション機能のご紹介です。 オプション機能①　全社ナレッジ共有 Dropboxで利用できるチームフォルダはチームや組織のための便利な共有ツールですが、 一方で、チームフォルダに招待できるユーザが1,000人までというサービス仕様があります。 1,000人以上で共有したり、みんなで編集・更新するという場面が少ないという背景があるためですが、全社で展開する発信文書やポータルとして展開するユースケースもありますので、 本ツール「全社ナレッジ共有」では、Dropboxの仕様はそのままで1,000人ごとにフォルダを自動で分けることができます。 Smartdbxを介して更新を行うことでDropboxのユーザが1,000人以上のチームに対しての効率的な情報共有を可能とします。 管理者はSmartdbxから、コンテンツの追加、変更、削除などの操作や、公開期限を設定でき、期限が来ると自動で公開データを削除することも可能です。 管理者がSmartdbxから更新を行うことで、Dropboxにフォルダが複数あっても1回の更新で同じ内容が反映されます。 本機能で共有されるコンテンツは全社での「参照」を基本とするもので、「編集」などの変更を加える操作は一部のコンテンツ管理者のみが実施することを前提としています。 オプション機能②　カスタムドメイン（ファイル送受信） Dropboxを利用して他社とファイルを共有する際、「DropboxTransfer」というファイル送信機能や「ファイルリクエスト」といったファイルを集める機能お使いいただけます。 ただ企業によってはクラウドストレージへのアクセスを禁止している場合があります。 その場合、Dropboxのファイルを安全に送受信することができません。 そこで本機能「カスタムドメイン」を使えばクラウドストレージがブロックされている取引先とも安全にDropboxのファイルを送受信することができます。 「カスタムドメイン」は、Dropboxとお取引先との間で仲介役として機能し、Dropboxドメインにアクセスせずに取引先がファイルを受け取ることができるようにします。 どのような相手にカスタムドメイン機能を使うかの例を記載します。 ①Dropboxが使える取引先 クラウドストレージがブロックされていない相手とはDropboxの標準機能を使ってファイルの共有が可能です。 Dropboxアカウントあり⇒フォルダ共有 Dropboxアカウントなし⇒送る：Dropbox Transfer　/　受け取る：ファイルリクエスト ②Dropboxが使えない取引先 Transferなどで生成されたdropbox.comドメインのリンクに対してアクセスできずファイルの送受信ができません。 これを回避する機能として本ツールでは「カスタムドメイン」機能をご提供いたします。   カスタムドメインの利用イメージ（下図）です。 ①Smartdbxのカスタムドメイン機能から送信先の情報、メッセージ、送信したいDropboxファイルを指定すると、入力した送信先に認証　　用のメールが届きます。 ②メールアドレスで認証を行います。 ③ダウンロード用のリンクが記載されているメールが届きます。 この③で届くダウンロード用リンクを使用いただくことでdropbox.comのドメインを使わずにDropboxのファイルを送受信していただけます。 現状1回の送信で50GB、将来的には300GBまでを目指しております。 また本機能はデータ転送を伴うためデータ転送にかかる料金については従量課金制となります。     今回はSmartdbxのオプション機能についてのご紹介でした。 Smartdbxについて興味を持っていいただけたら下記のホームページもご確認いただき、詳しい内容についてはぜひお問い合わせください。 詳しくはこちらをご覧ください。 Dropbox： Dropbox ｜ SCSK株式会社

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 皆さん、Session Manager経由でインスタンスに接続できず、調べてみてやっと原因がわかったり調べてみてもさっぱり原因が分からなかったりした経験がありませんか？ 対象インスタンスと同一VPCにssm, ssmmessages, ec2messagesのVPC Endpointを作成(インターネット接続のない環境の場合)し、 AWSSSMManagedCorePolicyを含むRole(インスタンスプロファイル)を作成し、 そのRole(インスタンスプロファイル)を接続対象インスタンスにアタッチし、 EC2インスタンスからVPC EndpointへのHTTPSが許可されるようにSecurity Groupを調整する SSM AgentがプレインストールされたAMIを使用しており、SSM Agentが起動していないとは考えづらい Session Managerのトラブルシューティング を調べてみてもおかしいところは見当たらず、正直もうお手上げ……そんな時に、縋る思いでこの記事をチェックしてみてください。 前提 この記事は、Session Manager経由での接続にVPCエンドポイントを使用する場合を想定しています。インターネットゲートウェイをアタッチしてインターネット接続できる環境にはあてはまりません。 名前解決に注意！ この記事で言いたいことは、名前解決に注意、です。VPC・VPCエンドポイントには、名前解決まわりのはまりポイントが3つあります。多くの場合このはまりポイントはうまく回避できているのですが、ひょんなことからはまりポイントになってしまうことがあるのです。 VPCの属性「DNS ホスト名」が有効になっていることを確認する VPCの属性「DNS 解決」が有効になっていることを確認する VPCエンドポイントの属性「プライベート DNS 名」が有効になっていることを確認する 1. VPCの属性「DNS ホスト名」が有効になっていることを確認する 下記AWSドキュメントを読んでみると、「DNSホスト名(enableDnsHostnames)」は、パブリックIPアドレスを持つEC2インスタンスのパブリックDNS名(ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com のようなインターネットから接続可能なFQDN)を有効にするか否か(のみ)を制御しているように読めます。 VPC の DNS 属性 - Amazon Virtual Private Cloud VPC の DNS サポートを制御します。 docs.aws.amazon.com VPC がパブリック IP アドレスを持つインスタンスへのパブリック DNS ホスト名の割り当てをサポートするかどうかを決定します。 ところが実際はそうではありません。 上記ドキュメントの「ルールと考慮事項」を読むと次のようなことが書かれています。(参照元ドキュメントの日本語機械翻訳がおかしいので、私の方で意味の通る日本語に翻訳し直しています) 「DNS ホスト名」「DNS 解決」のどちらかが無効に設定されている場合、Amazon Route 53 Resolver サーバーは、Amazon が提供するプライベート DNS ホスト名を解決できません。 Amazon が提供するプライベート DNS ホスト名というのは、例えばVPC内でEC2の名前解決に使用できるプライベート IP DNS 名(ip-10-xxx-xxx-129.ap-northeast-1.compute.internal のようなFQDN)などのことですが、他に、インターフェース型VPCエンドポイント名(例えば ssm.ap-northeast-1.amazonaws.com )もこれに含まれます。 以下の記事で書いた通り、本来であればAWSのパブリックIPが返ってくるはずのAWSサービスのエンドポイント ※1 について、Amazon Route 53 ResolverがVPCエンドポイントのプライベートIPアドレスを返すことで、インターフェース型VPCエンドポイントは機能しています。 ※1 例えば ssm.ap-northeast-1.amazonaws.comを名前解決すると99.77.60.93などのパブリックIPアドレスが返ってくる。 AWS インターフェース型 VPC エンドポイントにどのようにアクセスしているのか？ インターフェース型VPCエンドポイントはVPC内のプライベートIPアドレスを持っており、Route 53 Resolverが名前解決時に返すIPアドレスを変えることでVPC内のプライベートIPアドレスにアクセスする仕組みになっています。 blog.usize-tech.com 2024.01.16 「DNSホスト名」を無効にするとこのプライベートIPへの変換ができなくなるので、Session Manager経由の接続ができなくなります。 2. VPCの属性「DNS 解決」が有効になっていることを確認する 「DNS解決(enableDnsSupport)」の方はもっとわかりやすく、これを無効化すると、Amazon Route 53 Resolver(デフォルトで参照しているDNSサーバ)が一切名前解決をしてくれなくなります。 当然、Session Manager経由の接続に必要なVPCエンドポイントの名前解決もしてくれないので、Session Manager経由の接続ができなくなります。 3. VPCエンドポイントの属性「プライベート DNS 名」が有効になっていることを確認する VPCエンドポイントには、例えば vpce-xxxxxxxxxxxxxxxx-xxxxxxxx.ssm.ap-northeast-1.vpce.amazonaws.com のような名前が付き、名前解決するとプライベートIPアドレスに解決されますが、その他に、ssm.ap-northeast-1.amazonaws.com (SSMエンドポイントの場合)のようなプライベートDNS名前も持ち、同じプライベートIPアドレスに解決されます。 VPCエンドポイントの「プライベートDNS名」を無効にすると、後者(ssm.ap-northeast-1.amazonaws.com)の名前解決が機能しなくなり、Session Manager経由の接続ができなくなります。 なぜ無効化されているのか？ VPC属性「DNS ホスト名」は、マネージメントコンソールからのVPC作成時に「VPCなど」(VPC作成時にサブネットやルートテーブルなども一緒に作ってくれる機能)を選択するとデフォルトで有効が選択されているので問題ありませんが、「VPCのみ」を選択するとデフォルトでは無効です(2024年4月4日時点で弊社所有の環境にて確認)。作成時に有効化できないので、「VPCのみ」作成した場合には、作成後に「DNS ホスト名」を有効化しましょう。 VPC属性「DNS 解決」は、マネージメントコンソールからのVPC作成時、「VPCなど」「VPCのみ」どちらを選択してもデフォルト有効です。 「VPCなど」を選択してVPCを作成する画面 「VPCなど」を選択したときのDNSオプション設定画面 VPCエンドポイントの「プライベート DNS 名」はマネージメントコンソールからの作成時にデフォルトで有効が選択されていますが、私の経験では、有効を選択するとなぜか作成エラーになるため無効にして作成したことがありました。(そのことを失念した状態でSession Managerの接続設定をして、なんでつながらないの……とはまっていたわけです） なお、2024年4月4日時点では「プライベート DNS 名」有効で問題なく作成できましたので通常は発生しない問題です。 まとめ VPCを「VPCのみ」で作成したときに「DNS ホスト名」が無効になっている点ははまりどころかと思います。 また、「DNS 解決」「プライベート DNS 名」は意図的に無効化しない限りは有効になっているはずですが、私が経験したように(おそらくマネージメントコンソールのバグか何かで)無効になってしまっている可能性もあるので、チェックしてみるとよいでしょう。

本記事は、本記事の内容は、Cato Networks社の以下の記事を元に日本語へ意訳、再構成したものとなります。 Cato Global Private Backbone レガシーな専用線/閉域網をやめて、インターネット回線ベースとしたSASEへ移行する企業が増えています。 企業ネットワークは、長い間、信頼性が高く、かつ手頃な価格のグローバル接続手段を見つけるのに苦労してきました。 グローバルの専用線（MPLS）接続は、非常コストが高額なため帯域幅を制限しているのが現状だと思います。 一方で、インターネットを利用したネットワーク接続は、長距離グローバル接続の遅延（レイテンシー）により、満足に利用ができない状況かと思います。 Catoクラウドでは、このようなグローバル接続の課題も解決します。 Catoクラウドの グローバルプライベートバックボーン （ Global Private Backbone ）は、世界中の90以上の接続拠点（PoP）にまたがるプライベートネットワークになります。バックボーンは手頃な価格で利用することができ、管理はすべてCato Networks社が行います。 信頼性の高いグローバル接続を手頃な価格で Catoクラウドを利用し、通信帯域を大幅に増強し、高額なIP-VPNなどのWAN回線を排除することで、エンタープライズのグローバル接続コストを劇的に削減することができます。CatoクラウドのPoPは、可用性、遅延（レイテンシー）、パケットロス、ジッターに関するSLA保証された複数のティア1プロバイダー間で相互に接続さています。Catoクラウドのソフトウェアは、プロバイダーネットワークをリアルタイムにパフォーマンス監視し、アプリケーションを意識したルーティングアルゴリズムによって、Catoクラウドのバックボーンを経由する最適なパスを選択します。ルーティングを制御し、SLA保証されたネットワークキャパシティのみを使用することで、パブリックインターネットよりもはるかに凌ぐパフォーマンスを、グローバル専用線（MPLS）よりもはるかに低いコストで実現することが可能になります。 ピークスループットのWAN最適化 Catoクラウドは、グローバルネットワークのレイテンシーを最小化するだけでなく、アプリケーションのスループットを向上させます。内蔵されているWAN最適化機能により、TCP効率が劇的に改善され、サイト（拠点）やモバイルユーザーのデータスループットが最大40倍向上させます。CatoクラウドのPoPはTCPコネクションをプロキシし、TCPクライアントとサーバーがより多くのデータをより早く送信できるようにします。また、高度なTCP輻輳制御により、Catoエッジはより多くのデータを送受信し、利用可能な帯域幅をより有効活用することができます。これらの技術により、エラー修復に必要な時間を短縮し、パケットロスによるデータスループットへの影響を軽減します。 クラウドネイティブソフトウェアによるイノベーションの加速とコスト削減 CatoクラウドのPoPは、完全にマルチテナントでスケーラブルなネットワークスタックにより、経路計算、ポリシーの実施、セキュリティ検査など、ネットワーキングとセキュリティのすべてのコア機能をクラウドネイティブで実行しています。このソフトウェアプラットフォームは、従来のカスタムハードウェア（専用機）でしか実現できなかったようなパフォーマンスを、市販のサーバー上で動作させて実現することを可能にしました。 専用アプライアンスや専用機を一切排除することで、レガシー通信ネットワークの技術面・運用面でのコストが大幅に変わります。独自ハードウェアの調達・導入がないため、Catoクラウドでは、ネットワークのフットプリントを急速に拡大することができています。現在、Catoクラウドのネットワークはすべての主要なビジネス都市をカバーしており、Cato PoPは主にソフトウェアと標準サーバで構成されているため、新しいPoPの開設も迅速に行うことができます。自社でソフトウェアを所有することで、より迅速なイノベーションが可能になり、顧客の求める機能要求に迅速に対応し、サービスの問題を迅速に解決し、運用コストとサードパーティのライセンス料を削減することができます。 セルフヒーリング（自己修復）アーキテクトによる24時間365日運用 Catoクラウドは、完全なセルフヒーリング（自己修復）アーキテクチャにより、最大限の可用性を確保します。障害の検知、フェイルオーバー、フェイルバックのすべてが自動化されており、特別な計画や事前のオーケストレーションは一切必要ありません。各PoPには、Catoのソフトウェアの同一コピーを実行する複数のコンピュートノードがあり、どのコンピュートノードでも、そのPoPに接続されたエッジトンネルにサービスを提供できます。コンピュートノードが故障した場合は、トンネルは自動的に別のノードに切り替わります。PoPへの接続ができなくなると、そのPoPに接続されたエッジ（Socket、またはCato VPNクライアント）は自動的に次に近いPoPに再接続します。また、CatoクラウドのPoP間を接続しているティア1プロバイダーでの障害や劣化が発生すると、PoPは自動的に代替のティア1プロバイダーへ切り替わります。 組み込みのエンドツーエンドの暗号化とセキュリティ Catoクラウドのセキュリティを確保するために、広範な対策が講じられています。PoP間であれ、Cato SocketやCato VPNクライアントとの通信であれ、すべての通信はAES-256暗号化トンネルによって保護されています。攻撃対象領域を最小化するため、許可されたサイトとモバイルユーザーのみがバックボーンに接続し、トラフィックを送信することができます。PoPの外部IPアドレスは、特定のDDoS対策で保護されています。また、Catoクラウドは、ISO 27001認証を取得しています。 まとめ Catoクラウドのサービスの根幹となる グローバルプライベートバックボーン（Global Private Backbone） について解説しました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまで お問い合わせ ください。 SASE、Cato Networks、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度がまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加をいただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内いたします。 SASEや、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、 FAQサイト 運営、この TechHarmony （技術ブログ）にて、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

Cato クラウドでは、通信先の FQDN をベースとしたトラフィック制御やアクセス制御を行うことができます。一方で、FQDN の根幹を成す DNS はアプリケーションレイヤの技術であり、ネットワークやトランスポートのレイヤからは直接扱えない技術でもあります。 そうしたレイヤの違いから Cato クラウドが通信先の FQDN をどのように識別しているのか気になりましたので、深掘りして調査検証し、いくつか浮かび上がってきた課題をここで説明します。 通信における FQDN の利用 まず、実際の通信において FQDN がどう利用されるか整理します。 クライアントがIPアドレスではなく FQDN を指定して通信を開始しようとしたとき、その通信に先立ってクライアントは FQDN の名前解決を行います。名前解決には DNS や mDNS、あるいはマシン上の hosts ファイルなどを利用し、通信相手のIPアドレスを把握します。その後、そのIPアドレスに対してパケットを送信します。 IP ヘッダや TCP/UDP ヘッダには FQDN を格納する領域がないため、クライアントが送信するパケットには通常は FQDN に関する情報は含まれていません。ただし、上位レイヤのプロトコルによっては、各プロトコルにおける必要性からデータ部 (TCP/UDP ペイロード部) に FQDN を含むものがあります。 よく利用されるプロトコルの中では、HTTP や TLS (HTTPS を含む) では次の箇所に FQDN を含められるようになっています。 HTTP の場合：HTTP リクエストの Host ヘッダまたは :authority 疑似ヘッダ プロトコル仕様： https://www.rfc-editor.org/rfc/rfc9110.html#section-7.2 TLS (HTTPS を含む) の場合：ハンドシェイク開始時に送信される ClientHello メッセージの server_name 拡張 SNI (Server Name Indication) と呼ばれる仕組み プロトコル仕様： https://www.rfc-editor.org/rfc/rfc6066.html#section-3 他にも FQDN をデータとして含むプロトコルもあると思いますが、FQDN を含まないプロトコルのほうが多いです。また、HTTP や TLS であっても FQDN を必ず含むとは限りません。   Cato クラウドによる FQDN 識別の仕組み さて、Cato クラウドはどのようにして通信先の FQDN を把握し、トラフィック制御やアクセス制御を行っているのでしょうか。 この疑問に対する回答の一部は、Knowledge Base の以下のページに記載されています。 参考： Traffic Intermittently Fails to Match Firewall Rules 上記ページによると、PoP に存在する DNS サーバは通信に先立って行われる名前解決の結果（FQDN とIPアドレスの組）をキャッシュして覚えておき、その後に行われる通信のIPアドレスを見て FQDN を識別しているようです。Internet Firewall や WAN Firewall などで通信をイベントログに出力するようにしていれば、各イベントログの “Domain Name” フィールドに識別された FQDN が格納されています。 しかし実際に検証してみると、それだけではなく HTTP 通信や TLS 通信に含まれる FQDN も参照して識別していることがわかりました。複数のパターンで試した結果、次のようになっていました。 TLS (HTTPS 含む) 通信の場合で、ClientHello メッセージに server_name 拡張が含まれている場合、server_name 拡張の値 HTTP (非暗号化) 通信の場合で、HTTP リクエストに Host ヘッダが含まれている場合、Host ヘッダの値 上記以外の場合で、PoP の DNS サーバに名前解決結果のキャッシュがある場合、キャッシュされた FQDN の値 上記以外の場合、FQDN は識別されない (“Domain Name” フィールドが存在しない) FQDN が識別されなかった場合、FQDN を指定して行う各制御機能が正常に働かない (例：Cato PoP からインターネットに出る際のIPアドレスを固定にできない、ブロックさせたい通信がブロックされない）ということにも繋がります。そういったことを避けるためにも、DNS Settings の Primary DNS の設定値を Cato の推奨通り デフォルト値 (10.254.254.1) のままとし、Socket 配下に位置するマシンや Cato Client で接続したマシンに PoP の DNS サーバを参照させることで、FQDN の識別が必ず行われるようにしましょう。   FQDN ベースの制御の課題 Cato クラウドによる FQDN 識別の仕組みがわかると、FQDN ベースの制御における課題、あるいは技術的な制約も見えてきましたので、ここでは4点挙げてみます。 異なる FQDN が同じIPアドレスを共有する場合に誤識別が起きる インターネット上では、1つのIPアドレスで複数の異なる FQDN のサービスを提供するといったことが一般的に行われています。これはクラウドサービスや共有のレンタルサーバ・ホスティングサービスなど、様々な場所で行われています。そうしたとき、異なる FQDN が同じIPアドレスとして名前解決されると、PoP の DNS サーバの名前解決結果のキャッシュ状況によっては、FQDN を識別する際に誤識別が生じる可能性があります。 実際、インターネットで名前解決可能な2つの FQDN を用意し、そのAレコードを同一のIPアドレスとし、その FQDN に対して Cato クラウド経由でアクセスして試してみました。名前解決結果のキャッシュによって FQDN を識別させるために、TLS や HTTP 以外の通信を行うアプリケーションで試しました。 FQDN① にアクセスした際、手元のマシンは PoP の DNS サーバに対して名前解決の問い合わせを行い、アプリケーションの通信は期待通り FQDN① として識別されました。その後、FQDN② にアクセスした際も同様に名前解決が行われ、期待通り FQDN② として識別されました。 その後改めて FQDN① にアクセスすると、手元のマシンには FQDN① の名前解決結果のキャッシュがあるため、PoP の DNS サーバに対して問い合わせを行わず、アプリケーションの通信が行われました。PoP の DNS サーバではIPアドレスに対して FQDN② を紐づけるキャッシュが残っているようであり、アプリケーションの通信は FQDN② として識別されてしまいました。何度か試した結果、後から名前解決を行った FQDN がそのIPアドレスに紐づけられるようでした。 インターネットにおける通信の仕組み上、こういった誤判定を Cato クラウドが技術的に解消することは不可能だろうと思います。そのため、Cato クラウドの機能で通信を明確に制御したい場合は、FQDN ではなくIPアドレスやポート番号によって制御するしかありません。ただし、TLS や HTTP 通信を行うアプリケーションではこの誤判定は生じないため、実際に課題として顕在化してIPアドレスやポート番号による制御を行う必要があるケースは稀かもしれません。 Cato PoP 側の機能のみ FQDN ベースの制御を行える 通信の FQDN を識別するにはパケットの中身を解析したり、DNS サーバの名前解決キャッシュと突き合せたりする必要があるため、現状では Cato PoP で FQDN の識別が行われています。そのため、Cato Client で接続した SDP ユーザの Split Tunnel 機能や、Socket の Bypass 機能などでは、FQDN ベースの制御は行えません。 将来的に Cato Client や Socket で FQDN を識別することで制御を行えるようになる可能性はありますが、パケット処理の負荷が高い内容でもあるため、ユーザのマシンに求められるスペックが高まったり、高価で高スペックな Socket が必要になったりするはずです。 現状では Cato PoP 側で行われる機能のみ FQDN ベースの制御を行えるのだとご理解ください。 悪意あるユーザは各種制御を回避できる TLS の server_name 拡張や HTTP の Host ヘッダの値は、ある程度知識があれば書き換えたり削除したりできます。そのようなことが行われたパケットをインターネット上のサーバが受信したときに、書き換え・削除が行われていないパケットを受信したときと同様の動作を行うようになっていると、悪意あるユーザは Cato クラウド上で行った FQDN ベースの各種制御を回避できてしまいます。 また、TLS や HTTP 以外の通信を行う場合にも、手元のマシンから Cato PoP の DNS サーバに名前解決の問い合わせを行わないようにしておけば、同様に各種制御を回避できてしまいます。 実際、server_name 拡張や Host ヘッダを適当な値に書き換えて通信すると、FQDN がその適当な値に識別されることを確認しました。また、Cato PoP の DNS サーバで名前解決を行わないようにしたうえで、server_name 拡張や Host　ヘッダを削除して通信すると、FQDN が識別されないことも確認しました。 FQDN による制御を回避できてしまうこと自体は、やはりインターネットにおける通信の仕組み上、Cato クラウドとしてはどうすることもできないように思います。悪意がなければ各種制御が回避されることはないため気にしすぎる必要はないと思いますが、厳格に制御する必要がある場合はIPアドレスやポート番号によって制御すべきですね。 Encrypted Client Hello によって通信できなくなる 2018年頃より、 Encrypted Client Hello (ECH) という TLS に関する新しい技術仕様が IETF にて議論されています。TLS 通信開始時に送信される ClientHello メッセージは鍵交換前であるため暗号化されていませんが、この ECH という技術仕様では ClientHello メッセージの一部を暗号化し、とりわけ server_name を秘匿しようとされています。 ECH の詳細はここでは説明せず Cloudflare のブログ や APNIC のブログ にお任せするのですが、端的に言うと、ClientHello メッセージの server_name 拡張の部分にはユーザのアクセス先の FQDN とは異なる値が入り、本当の FQDN は暗号化されて ClientHello メッセージに格納されるようになります。Cato クラウドやその他セキュリティソリューションなどは暗号化された部分を復号できないため、本当の FQDN を知ることができなくなります。 ECH に対応した通信を行うにはクライアントとサーバの両者がそれに対応している必要がありますが、Google Chrome や Microsoft Edge といったブラウザでは既に ECH がデフォルトで有効となっており、Cloudflare のような CDN では ECH を有効にするオプションも用意されています。そのため、今後普及することが予想され、気付かないうちに広まっているかもしれません。 一方で、クライアントが ECH に対応した通信を開始した場合、Cato クラウド側で TLS Inspection を行うようになっていると正常に通信できなくなる可能性があります。実際、日本の通信事業者のセキュリティサービスにおいても ECH により通信が行えなくなったというアナウンス もありました。TLS Inspection をバイパスすれば通信できるはずですが、CASB の各種機能は働かなくなってしまいますし、Cato クラウドが server_name 拡張の値をもとに FQDN を識別するのであれば誤識別も発生してしまいます。 ただし、Cato Client をインストールした Windows マシンを用いて ECH のテストサイトで試したところ、Cato Client 非接続時は ECH が使われたものの、Cato Client 接続時は ECH を使わずに通信していました（HTTPS レコードの問い合わせが行われていませんでした）。ECH が使われなかった理由は不明ですが、そうなるように Cato Client が Windows のレジストリを操作している可能性があります。もしそうであれば、通信できなくなる問題は起きなくて済むので良いのですが、正確な仕様は把握できておりません。   所感 Cato クラウドが通信の FQDN を識別する仕組みについて調査検証し、技術的に行えることはきちんと行う仕組みになっていると感じました。ほとんどの場合は正常に機能しますので、FQDN ベースによる制御も正しく行えるものと思います。 一方で、インターネットにおける通信の仕組み上、誤識別や悪意者が回避できるといった課題が残ってしまっています。これ自体は避けることはできませんが、将来のトラブルシューティング時にもしかしたら役立つかもしれませんので、頭の片隅に残しておきたいと思います。 Encrypted Client Hello という技術仕様については、IETF で議論されている最中でありインターネット標準となっているわけではないため、将来どうなるかはまだわかりません。CASB の各種機能を活かすには ECH を無効にせざるを得ないですが、無効にする設定をマシンに1ずつ導入していかなければならない事態はどうにか避けたいので、Cato クラウド側で何らかの対応（Cato PoP の DNS サーバが HTTPS レコードの問い合わせに応答しないようにする対応）が欲しいですね。

こんにちは！最近元気な挨拶を心がけているMasedatiです。 2023年度のAWSのアップデートを見直していたらAmazon Lexに関する以下の記事を見つけました。 Amazon Lex が Amazon Lex V2 向けの Selective Conversation Log Capture を導入 aws.amazon.com Selective Conversation Log Capture は、セキュリティやプライバシー上の懸念から会話型ログをデフォルトで有効にできない場合に、お客様がトラブルシューティングや詳細な会話分析を行うために役立ちます。… …この機能により、ユーザーが提供した承認や法的同意など、最も関連性の高いデータのみがキャプチャされ、アーカイブされます。 いったいどのような機能なのでしょうか？詳しく見ていきたいと思います。 Amazon Lexとは？ Amazon Lexとは、Amazon Alexa と同じ会話型エンジンを搭載した、音声やテキストを使用して任意のアプリケーションに対話型インターフェイスを構築するサービスです。チャットボットと呼べばイメージしやすいでしょうか。 Amazon Lexではサンプルボットが公開されており、以下は花屋を想定したチャットボットです。 ユーザの注文に対して自動応答を行っています。 なお、Amazon LexにはV1とV2がありますが、今回Selective Conversation Log Captureが使用できるのはV2のみのため、以降はAmazon Lex V2とします。   Selective Conversation Log Captureとは？ Amazon Lex V2 は、会話のテキストログを Amazon CloudWatch Logs に保存することができます。また、会話のオーディオログを S3 バケットに保存することができます。 すべてのログを保存できるのはありがたいですが、これまでは「ログを保存しない or ログを すべて 保存する」の2択だったため、ログを保存する場合、会話の中の機密情報(クレジットカード番号、セキュリティコード)もログの中に含まれる可能性がありました。 今回導入された「Selective Conversation Log Capture」は、有効化することで ログを 一部 保存することができるように なります。 具体例 Selective Conversation Log Capture 有効化前 のログはこちらです。 そして、Selective Conversation Log Capture 有効化後 のログはこちらです。 明らかに少なくなってますね。   やってみた では、花屋のサンプルボットを利用して、「Selective Conversation Log Capture」を導入してみましょう。 ボットの作成 Amazon Lexのページから「ボットを作成」ボタンをクリックします。 「例から開始」を選択し、サンプルボットとして、「OrderFlowers」を選択します。 ボットの名前を入力し、IAMロールを作成します。 児童オンラインプライバシー保護法は「 いいえ 」を選択します。 児童オンラインプライバシー保護法 (COPPA) の対象となるボットでは、会話ログを使用することはできません。 会話ログの記録 - Amazon Lex Amazon Lex V2 ボットを使用してユーザーとの会話を記録する方法を説明します。 docs.aws.amazon.com その他の設定項目はデフォルトとし、「次へ」ボタンを押します。 言語を選択し、チャットボイスの声優さんを選択後、完了ボタンを押します。 声が素敵だと思ったので、私はTomokoさんを選びました。 サンプルで作られる会話の流れは以下のようになっています。 Selective Conversation Log Captureを有効化する 今回は、新たに会話内容(顧客注文の最終確認)を追加し、その会話内容(スロット)のみログを保存してみます。 既存会話内容のログにセンシティブ情報( クレジットカード番号等 )があり、「 顧客注文の最終確認のみ記録する 」必要があると仮定します。 事前準備としてスロットタイプを定義する必要があります。 スロットタイプとは、スロット内のデータの認識と処理方法を定義するものです。 今回最終確認に対して、「はい/いいえ」の答えが期待されるので、以下のように作成します。 事前準備ができたところで、「スロットを追加」ボタンを押し、新しい会話を追加しましょう。 事前準備で作成したスロットタイプを指定し、以下のようにスロットを設定・追加します。 名前：CustomerCheck スロットタイプ：CustomerCheck プロンプト：{FlowerType} を {PickupDate} の {PickupTime} に受け取りますか？ スロットが追加できたら「インテントを保存」後、インテントリストに戻ります。 デプロイ>エイリアスを選択後、デフォルトで作成されているエイリアスを選択します。 「会話ログを管理」を押します。 テキストログを有効化し、Selectively log utterancesに✓を入れます。ログを保存するCloudWatchロググループを選びます。 なお、オーディオログは無効としました。 インテントに戻り、初期応答→詳細オプションをクリックします。 Selective Conversation Log Captureを有効にするインテントとスロットに基づいて、Session attributesに以下の形式で記載します。 [x-amz-lex:enable-text-logging: intent : slot]  = "true" 今回ログを保存するインテント名が[OrderFlowers]、スロット名が[CustomerCheck]なので、以下のように記載しました。 [x-amz-lex:enable-text-logging: OrderFlowers : CustomerCheck]  = "true" 公式ドキュメント には x-amz-lex:enable-text-logging: intent : slot と記載されてましたが、エラーがでました。 [ x-amz-lex:enable-text-logging: intent : slot ] が正しいようです。 インテントを保存後、Buildし、Testしてみましょう。 新しい会話が追加されました。 ログを確認する（再掲） では、CloudWatchログを確認してみましょう。 Selective Conversation Log Capture 有効化前 のログはこちらです。 上記会話の すべて のやりとりが保存されています。 そして、Selective Conversation Log Capture 有効化後 のログはこちらです。 “content”に表示されている内容は、該当会話でのユーザへの返答ですので、今回Selective Conversation Log Captureを有効化した CustomerCheckスロットのログのみ 保存されています。 今回は該当箇所のテキストログのみを保存しましたが、すべての会話をテキストログとして保存し、該当箇所のみオーディオログとして保存することもできます。   感想 一昔前のアップデート内容でしたが、皆様のお役に立てれば幸いです。

こんにちは！SCSKの江木です。 以前、BigQuery MLのML.GENERATE_TEXT関数を使って要約を生成させるというブログを執筆している際に、要約精度が良いモデル・プロンプトは何だろうと疑問が湧きました。 今回はこの疑問について解決するべく、流行りのLangChainを使って、要約精度が良いGoogleのLLMとプロンプトを考えてみようと思います。 ※以前のBigQuery MLのML.GENERATE_TEXT関数のブログが見たい方はこちら。 BigQuery MLのML.GENERATE_TEXT関数を使ってテキストデータを要約してみた BigQuery MLのML.GENERATE_TEXT関数を使って、テキストのデータセットを要約してみたので、実装方法を紹介します。 blog.usize-tech.com 2024.01.19 LangChainとは？ LangChainは、大規模言語モデル（LLM）を活用してサービスを開発する際に役立つオープンソースフレームワークです。LLMは、大量のデータで事前にトレーニングされた大規模な深層学習モデルで、ユーザーのクエリに対する応答を生成できます。 LangChainは、LLMと外部リソース（データソース、言語処理系）を組み合わせて、より高度なアプリケーションやサービスの開発をサポートすることを目的としています。プログラミング言語はPythonとJavaScriptに対応しています。 今回はLangChainが複数のLLMを扱えるという長所を利用します。 LangChain LangChain’s suite of products supports developers along each step of their development journey. www.langchain.com   要約精度をどのように比較するのか？ 人による要約精度評価をすることがベストですが、個人差が出てしまうため、今回は自動評価指標を使いたいと思います。生成AIの要約精度の比較にはROUGE、METEOR、BLEUといった自動評価指標が用いられることが多いですが、今回は比較的新しい指標であるBertScoreを使います。BertScoreを用いて、人が要約した文章と生成AIによって作られた要約の文章の類似度を比較することで、要約精度を導出します。 そもそもBertScoreとは？ BertScoreは、 BERTと呼ばれるTransformerベースの言語モデル を利用して、2つの文章の類似性を測定します。BERTは、文章中の単語だけでなく、文脈も考慮して単語の意味を理解することができます。 BertScoreの具体的な計算方法は以下の通りです。 2つの文章をBERTに入力し、それぞれの文のベクトル表現を得ます。 2つのベクトル表現の距離を計算します。 距離を元に、類似度スコアを計算します。 BertScoreは0~1の値を取り、1に近ければ近いほど文章の類似度が高いといえます。   検証環境およびソースコード 検証環境 本記事で検証環境として使用したのは、Google Colaboratoryです。Google Colaboratoryは、ブラウザ上で動作するJupyter Notebook環境です。無料で利用でき、Pythonコードの実行やデータ分析、機械学習などを行うことができます。 検証に使用したデータセットは 前回のブログ と同様にjson形式の 要約用のデータセット を用いました。 また、比較に使用したモデルはGoogle AIのGemini-pro、Vertex AIのGemini-pro、text-bison、text-unicornです。 ソースコード 検証の際に使用したソースコードを紹介していきます。 最初にモジュールのインストールを行います。 !pip install --upgrade langchain-google-genai langchain-core langchain-google-vertexai langchain langchain_community !pip install google-cloud-aiplatform chromadb==0.3.26 pydantic==1.10.8 typing-inspect==0.8.0 typing_extensions==4.5.0 pandas datasets google-api-python-client pypdf faiss-cpu transformers config --upgrade --user !pip install bert_score 続いて、使用するデータセットを読み込みます。今回は20個の文章を要約して、検証してみます。 import pandas as pd import json #変換したいJSONファイルを読み込む df = pd.read_json('jsonファイルが置いてあるフォルダ/japanese_test.jsonl',orient='records', lines=True) #要約に使用するテキスト df_text = df['text'].iloc[:20] #要約の正解テキスト df_sum = df['summary'].iloc[:20] 続いて、langchainを使って要約を行い、BertScoreで要約結果を比較する関数を作っていきます。 また、要約を行うために、以下の3つのプロンプトを用意しました。 以下の文章を要約して 以下の文章を200文字で要約して 以下の文章を3文で要約して 検証の際にはプロンプトを入力する箇所を適宜変更します。 from langchain_google_genai import GoogleGenerativeAI from langchain.prompts import PromptTemplate from bert_score import score import torch from langchain_google_vertexai import VertexAI from tqdm import tqdm #APIキーの設定 api_key = "Google AIのAPIキーを入れてください" #プロンプトを入力 #プロンプト1:以下の文章を要約して #プロンプト2:以下の文章を200文字で要約して #プロンプト3:以下の文章を3文で要約して template1 = """以下の文章で要約して。 文章：{sentence}""" #関数の作成 def compare_summary_result(llm,text,sum): 　text_list = text.tolist() 　sum_list = sum.tolist() 　result_sum_list = [] #llmによる要約の結果を格納 　sum_list_final = [] #データセットの要約を格納。データによってllmがエラーを出す時があるので、エラーを出したものを飛ばす。 　text_list_final = [] #データセットの元のテキストを格納。データによってllmがエラーを出す時があるので、エラーを出したものを飛ばす。 　for i in tqdm(range(len(text_list))): 　try :   　sentence = text_list[i]   　prompt = PromptTemplate.from_template(template1)   　prompt = prompt.format(sentence=sentence)   　result = llm.predict(prompt)   　result_sum_list.append(result)   　　　text_list_final.append(text_list[i])   　sum_list_final.append(sum_list[i]) 　except IndexError :     print("IndexError") P, R, F1 = score(result_sum_list, sum_list_final, lang="ja") result_bertscore = float(torch.mean(P)) return result_bertscore,result_sum_list,sum_list_final,text_list_final それでは作成した関数を用いて、検証するプログラムを作成します。 以下、Google AIのGemini-proモデルを使用した検証プログラムになります。 llm = GoogleGenerativeAI(model="gemini-pro", google_api_key=api_key) #結果を整形 google_gemini_bertscore,google_gemini_result,google_gemini_sum,google_gemini_text = compare_summary_result(llm,df_text,df_sum) df_google_gemini_result1 = pd.DataFrame(list(zip(google_gemini_result,google_gemini_sum,google_gemini_text)), columns=["summary_result", "summary_label", "text"]) 続いて、Vertex AIのGemini-pro、text-bison、text-unicornを使用した検証プログラムになります。 import sys import IPython import vertexai from google.colab import auth #認証を行う app = IPython.Application.instance() app.kernel.do_shutdown(True) if "google.colab" in sys.modules: 　auth.authenticate_user() #初期化を必ず行う #Gemini-proモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="gemini-pro") vertex_gemini_bertscore,vertex_gemini_result,vertex_gemini_sum,vertex_gemini_text = compare_summary_result(llm,df_text,df_sum) df_vertex_gemini_result1 = pd.DataFrame(list(zip(vertex_gemini_result,vertex_gemini_sum,vertex_gemini_text)), columns=["summary_result", "summary_label", "text"]) #text-bisonモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="text-bison",project_id="プロジェクト名") vertex_bison_bertscore,vertex_bison_result,vertex_bison_sum,vertex_bison_text = compare_summary_result(llm,df_text,df_sum) df_vertex_bison_result1 = pd.DataFrame(list(zip(vertex_bison_result,vertex_bison_sum,vertex_bison_text)), columns=["summary_result", "summary_label", "text"]) #text-unicornモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="text-unicorn",project_id="プロジェクト名") vertex_unicorn_bertscore,vertex_unicorn_result,vertex_unicorn_sum,vertex_unicorn_text = compare_summary_result(llm,df_text,df_sum) df_vertex_unicorn_result1 = pd.DataFrame(list(zip(vertex_unicorn_result,vertex_unicorn_sum,vertex_unicorn_text)), columns=["summary_result", "summary_label", "text"])   検証結果 先ほどのソースコードを実行し、それぞれのプロンプトにおいて、要約結果を言語モデル間で比較してみました。それでは、結果を見てみましょう。 プロンプト1：以下の文章を要約して プロンプト1をLLMに入力して、類似度を出した結果は以下の図の通りです。 縦軸がBertScore、横軸がモデルを表しており、左からGoogle AIのGemini-pro、Vertex AIのGemini-pro、text-bison、text-unicornのモデルの結果を示しています。   Google AI のGemini-proが一番よい要約精度を記録しました。 データセットの先頭のデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。 インペリアル･コレッジ･ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 ＜関連記事＞ 世界中では約120のワクチンの開発が進められている。英オックスフォード大学の専門家たちはすでに臨床試験を開始している。 新しいアプローチ 多くの従来のワクチンは、弱体化させたウイルスや改変したウイルスなどがもとになっている。しかし今回のワクチンは新しいアプローチに基づいたもので、遺伝子のRNA（リボ核酸）を使う。 筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 シャトック教授は、「我々はゼロからワクチンを製造し、わずか数カ月で臨床試験に持ち込むことができた」と述べた。 「我々のアプローチがうまくいって、ワクチンがこの病気を効果的に防御できれば、将来的なアウトブレイク（大流行）への対応方法に革命をもたらす可能性がある」 主任研究員のカトリーナ・ポロック博士は、ワクチンの効果に期待している この研究の主任研究員、カトリーナ・ポロック博士は、「参加者に大きな免疫反応がみられるだろうと、慎重ながらも楽観的に感じられなかったら、私はこの臨床試験に取り組んでいなかっただろう」と付け加えた。 「前臨床データは非常に期待がもてるものだった。感染から保護しておきたい免疫反応である中和抗体応答は確認できているが、このワクチンを評価するにはまだ道のりは長い」 この研究は英政府から4100万ポンド（約54億5500万円）の資金提供を受けている。ほかにも500万ポンド（約6億6500万円）の寄付が寄せられている。 「ウイルスを倒すのに協力したくて志願」 金融業界で働くキャシーさん（39）は、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティアの1人だ。 新型ウイルスとの戦いの一端を担いたくて志願したという。 「自分に何ができるのかあまりよく分かっていなかったけど、これが私にできることだったと分かった」 「それに、ワクチンができるまで日常に戻れる可能性は低いことを理解したことで、ワクチン開発の一端を担いたいと思った」 キャシーさんは、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティア300人の1人 こうした中、ケンブリッジ公爵ウィリアム王子はオックスフォード大学の臨床試験に参加しているボランティアたちと、オックスフォード市内のチャーチル病院で面会した。 ウィリアム王子はボランティアに対し、「みなさん全員が参加しているのは、信じられないくらい胸が躍る、非常に待ち望まれたプロジェクトだ。だからみんなが心を奪われている」と述べた。 初日の被験者は1人だけ BBCのファーガス・ウォルシュ医療担当編集委員によると、すべての臨床試験は安全性のリスク軽減のために慎重に、ゆっくり開始される。オックスフォード大学で4月に臨床試験が開始された際には、初日に接種を受けたのはボランティア2人だけで、1週間以内に100人に接種された。 これに対して、インペリアル･コレッジ･ロンドンの臨床試験では初日には1人だけにワクチンを接種する。その後48時間ごとに3人に接種し、徐々に被験者を増やしていく。 また、1回分の投与量を使用するオックスフォード大学とは異なり、インペリアル･コレッジ･ロンドンの臨床試験では4週間の間隔をあけて、2回の接種を行うという。 シャトック教授らのチームは、慎重に進めている理由について、ワクチンに特段の安全性の懸念があるからではなく、単にアプローチが新しいからだと説明している。 新型コロナウイルス特集 感染対策 在宅勤務・隔離生活 （英語記事 Human trial of new coronavirus vaccine starts in UK） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンは、新しいRNAベースのコロナウイルスワクチンの第1段階臨床試験を開始しました。これまでの動物実験では安全性と免疫反応の有効性が示されており、10月に6000人を対象とした第2段階試験が予定されています。このワクチンは、弱体化したウイルスではなく、自己複製してスパイクタンパク質の複製を生成するRNAを使用しています。主任研究員は、免疫反応に期待を寄せていますが、ワクチンが効果的であるかどうかを評価するにはさらなる調査が必要です。 Vertex AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンの新しいmRNAワクチンは、動物実験で安全かつ効果的であることが示され、現在第1段階の臨床試験が行われている。6000人を対象とした第2段階試験は今年10月に予定されており、早ければ2021年初頭にワクチンが配布される見込み。このワクチンは、体内にスパイクタンパク質のコピーを作成し、免疫システムを活性化してCOVID-19と戦う仕組み。 Vertex AI text-bisonによる要約結果  インペリアル・カレッジ・ロンドンは、新型コロナウイルスのワクチンの人間に対する臨床試験を開始した。このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖して新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。臨床試験には、300人のボランティアが参加し、初日には1人 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンの研究チームは、新型コロナウイルス感染症（COVID-19）のワクチンの臨床試験を開始した。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、遺伝子のRNA（リボ核酸）を使う。筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19を発症することなく新型ウイルスを BertScoreの結果の通り、Google AIのGemini-proモデルの要約が一番良いように思えます。 プロンプト2：以下の文章を200文字で要約して プロンプト2をLLMに入力して、類似度を出した結果は以下の図の通りです。 text-unicornが最も精度の高い要約を生成したという結果となりました。 以下の公式ドキュメントによると、text-unicornは「複雑な自然言語タスクに使用する PaLM モデル ファミリーの中で最も高度なテキストモデル。」とのことなので、高い精度となったと考えられます。 モデル情報  |  Vertex AI の生成 AI  |  Google Cloud cloud.google.com   また、データセットの先頭のデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。 インペリアル･コレッジ･ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 ＜関連記事＞ 世界中では約120のワクチンの開発が進められている。英オックスフォード大学の専門家たちはすでに臨床試験を開始している。 新しいアプローチ 多くの従来のワクチンは、弱体化させたウイルスや改変したウイルスなどがもとになっている。しかし今回のワクチンは新しいアプローチに基づいたもので、遺伝子のRNA（リボ核酸）を使う。 筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 シャトック教授は、「我々はゼロからワクチンを製造し、わずか数カ月で臨床試験に持ち込むことができた」と述べた。 「我々のアプローチがうまくいって、ワクチンがこの病気を効果的に防御できれば、将来的なアウトブレイク（大流行）への対応方法に革命をもたらす可能性がある」 主任研究員のカトリーナ・ポロック博士は、ワクチンの効果に期待している この研究の主任研究員、カトリーナ・ポロック博士は、「参加者に大きな免疫反応がみられるだろうと、慎重ながらも楽観的に感じられなかったら、私はこの臨床試験に取り組んでいなかっただろう」と付け加えた。 「前臨床データは非常に期待がもてるものだった。感染から保護しておきたい免疫反応である中和抗体応答は確認できているが、このワクチンを評価するにはまだ道のりは長い」 この研究は英政府から4100万ポンド（約54億5500万円）の資金提供を受けている。ほかにも500万ポンド（約6億6500万円）の寄付が寄せられている。 「ウイルスを倒すのに協力したくて志願」 金融業界で働くキャシーさん（39）は、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティアの1人だ。 新型ウイルスとの戦いの一端を担いたくて志願したという。 「自分に何ができるのかあまりよく分かっていなかったけど、これが私にできることだったと分かった」 「それに、ワクチンができるまで日常に戻れる可能性は低いことを理解したことで、ワクチン開発の一端を担いたいと思った」 キャシーさんは、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティア300人の1人 こうした中、ケンブリッジ公爵ウィリアム王子はオックスフォード大学の臨床試験に参加しているボランティアたちと、オックスフォード市内のチャーチル病院で面会した。 ウィリアム王子はボランティアに対し、「みなさん全員が参加しているのは、信じられないくらい胸が躍る、非常に待ち望まれたプロジェクトだ。だからみんなが心を奪われている」と述べた。 初日の被験者は1人だけ BBCのファーガス・ウォルシュ医療担当編集委員によると、すべての臨床試験は安全性のリスク軽減のために慎重に、ゆっくり開始される。オックスフォード大学で4月に臨床試験が開始された際には、初日に接種を受けたのはボランティア2人だけで、1週間以内に100人に接種された。 これに対して、インペリアル･コレッジ･ロンドンの臨床試験では初日には1人だけにワクチンを接種する。その後48時間ごとに3人に接種し、徐々に被験者を増やしていく。 また、1回分の投与量を使用するオックスフォード大学とは異なり、インペリアル･コレッジ･ロンドンの臨床試験では4週間の間隔をあけて、2回の接種を行うという。 シャトック教授らのチームは、慎重に進めている理由について、ワクチンに特段の安全性の懸念があるからではなく、単にアプローチが新しいからだと説明している。 新型コロナウイルス特集 感染対策 在宅勤務・隔離生活 （英語記事 Human trial of new coronavirus vaccine starts in UK） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンは、RNAベースのCOVID-19ワクチンの人間による最初の臨床試験を開始した。このワクチンは動物実験で安全性と免疫反応が実証されており、今後6000人を対象とした第2段階の試験が予定されている。この新しいアプローチは、弱体化したウイルスを使用する従来のワクチンとは異なり、ウイルス表面のスパイクタンパク質をコードするRNAを使用し、免疫システムがウイルスを認識することを訓練する。主任研究員のポロック博士は、前臨床データに期待を寄せており、このワクチンがパンデミックへの対応に革命をもたらす可能性があると述べている。研究チームは、慎重に段階を踏んで試験を進め、ワクチンが安全かつ効果的であることを確認することを目指している。 Vertex AI Gemini proによる要約結果 インペリアルカレッジロンドンの新しいワクチンは、動物実験で安全かつ免疫反応を誘発することが示されました。6000人を対象とした第2段階の臨床試験が計画されており、2021年初頭には配布を目指しています。このワクチンはRNAを使用して、ウイルスの認識を訓練し、免疫システムを構築します。研究者らは、中和抗体応答が確認され、高い免疫反応を期待しています。金融業界のキャシーさんは、ボランティアに参加し、パンデミックの克服に貢献しています。この臨床試験では、慎重に被験者数を増やし、4週間の間隔で2回の接種を行います。安全性上の懸念ではなく、新しいアプローチを慎重に評価するためです。 Vertex AI text-bisonによる要約結果  インペリアル・カレッジ・ロンドンは、新型コロナウイルスに対する新しいワクチンの第1段階の臨床試験を開始しました。このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖して新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出します。この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。この研究は英政府から4100万ポンド（約5 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンの研究チームは、新型コロナウイルス感染症（COVID-19）のワクチンの臨床試験を開始した。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、RNA（リボ核酸）を使う。筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19を発症することなく新型ウイルスを認識して戦 BertScoreが一番良かったtext-unicornモデルの要約が今一つのように思えます。個人的にはGoogle AIのGemini-proモデルの要約が一番良いように感じています。 プロンプト3：以下の文章を3文で要約して プロンプト3をLLMに入力して、類似度を出した結果は以下の図の通りです。 こちらもtext-unicornが最も精度の高い要約を生成したという結果となりました。 また、データセット中の1つのデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。 インペリアル･コレッジ･ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 ＜関連記事＞ 世界中では約120のワクチンの開発が進められている。英オックスフォード大学の専門家たちはすでに臨床試験を開始している。 新しいアプローチ 多くの従来のワクチンは、弱体化させたウイルスや改変したウイルスなどがもとになっている。しかし今回のワクチンは新しいアプローチに基づいたもので、遺伝子のRNA（リボ核酸）を使う。 筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 シャトック教授は、「我々はゼロからワクチンを製造し、わずか数カ月で臨床試験に持ち込むことができた」と述べた。 「我々のアプローチがうまくいって、ワクチンがこの病気を効果的に防御できれば、将来的なアウトブレイク（大流行）への対応方法に革命をもたらす可能性がある」 主任研究員のカトリーナ・ポロック博士は、ワクチンの効果に期待している この研究の主任研究員、カトリーナ・ポロック博士は、「参加者に大きな免疫反応がみられるだろうと、慎重ながらも楽観的に感じられなかったら、私はこの臨床試験に取り組んでいなかっただろう」と付け加えた。 「前臨床データは非常に期待がもてるものだった。感染から保護しておきたい免疫反応である中和抗体応答は確認できているが、このワクチンを評価するにはまだ道のりは長い」 この研究は英政府から4100万ポンド（約54億5500万円）の資金提供を受けている。ほかにも500万ポンド（約6億6500万円）の寄付が寄せられている。 「ウイルスを倒すのに協力したくて志願」 金融業界で働くキャシーさん（39）は、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティアの1人だ。 新型ウイルスとの戦いの一端を担いたくて志願したという。 「自分に何ができるのかあまりよく分かっていなかったけど、これが私にできることだったと分かった」 「それに、ワクチンができるまで日常に戻れる可能性は低いことを理解したことで、ワクチン開発の一端を担いたいと思った」 キャシーさんは、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティア300人の1人 こうした中、ケンブリッジ公爵ウィリアム王子はオックスフォード大学の臨床試験に参加しているボランティアたちと、オックスフォード市内のチャーチル病院で面会した。 ウィリアム王子はボランティアに対し、「みなさん全員が参加しているのは、信じられないくらい胸が躍る、非常に待ち望まれたプロジェクトだ。だからみんなが心を奪われている」と述べた。 初日の被験者は1人だけ BBCのファーガス・ウォルシュ医療担当編集委員によると、すべての臨床試験は安全性のリスク軽減のために慎重に、ゆっくり開始される。オックスフォード大学で4月に臨床試験が開始された際には、初日に接種を受けたのはボランティア2人だけで、1週間以内に100人に接種された。 これに対して、インペリアル･コレッジ･ロンドンの臨床試験では初日には1人だけにワクチンを接種する。その後48時間ごとに3人に接種し、徐々に被験者を増やしていく。 また、1回分の投与量を使用するオックスフォード大学とは異なり、インペリアル･コレッジ･ロンドンの臨床試験では4週間の間隔をあけて、2回の接種を行うという。 シャトック教授らのチームは、慎重に進めている理由について、ワクチンに特段の安全性の懸念があるからではなく、単にアプローチが新しいからだと説明している。 新型コロナウイルス特集 感染対策 在宅勤務・隔離生活 （英語記事 Human trial of new coronavirus vaccine starts in UK） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンが開発したCOVID-19ワクチンは、動物実験で有効性が確認されており、現在第1段階の臨床試験が行われています。このワクチンは従来の方法とは異なり、RNAを使用してスパイクタンパク質の生成を誘導し、免疫システムを訓練します。研究者は、早ければ2021年初頭からワクチンを配布することを目指しています。 Vertex AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンの新しい新型コロナウイルスワクチンは、動物実験で安全で効果的であることが示されています。2021年早々に配布可能となることを目指し、6,000人を対象とした臨床試験が予定されています。このワクチンは、遺伝子のRNAを使用して免疫システムを訓練し、将来的にアウトブレイクに対応する方法に革命をもたらす可能性があります。 Vertex AI text-bisonによる要約結果 インペリアル・カレッジ・ロンドンは、新型コロナウイルスのワクチンの人間に対する臨床試験を開始した。 このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 臨床試験には、300人のボランティアが参加し、4週間の間隔をあけて2回の接種を行う。 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンで、新型コロナウイルスワクチンの臨床試験が開始された。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、RNA（リボ核酸）を使う。臨床試験は、安全性を確認するために慎重に進められている。 BertScoreの結果の通り、text-unicornモデルの要約が一番良いように思えます。 プロンプト間での比較 プロンプト間で比較してみるとプロンプト3「以下の文章を3文で要約して」が最もよい結果となりました。文字数で指定するよりも、文の数を指定したほうが少し精度が上がるのかもしれません。   まとめ 本記事では、GoogleのLLMを用いたテキスト要約タスクにおける性能比較検証を行いました。自動評価指標であるBertScoreを用いた評価において、Text-Unicornは高い精度を示しました。また、プロンプトに文の数を指定することで、どのモデルにおいても要約精度がわずかに向上することが確認されました。これは、文の数を指定することで、要約すべき内容をより明確に理解できるためと考えられます。 しかし、実際に生成された要約を見てみると、Text-Unicornの要約は必ずしも最適とは言えないことがわかりました。これは、BertScoreと人間の評価基準が必ずしも一致していないことを示唆しています。人間の評価基準に沿った要約生成においては、Google AIのGemini-proが優れているように思えます。 以上の結果から、AI評価と人間の評価の間には乖離が存在することが明らかになりました。これは、AIモデルの開発において、人間の評価を考慮することが重要であると思います。 今回の検証では、GoogleのLLMの性能比較という限定的な結果しか得られませんでした。今後は、AI評価と人間の評価の乖離についても考慮しつつ、より多くのモデルおよびプロンプトを比較検討することで、タスクごとに最適なモデルおよびプロンプトを決定できるようにしたいと考えています。 最後までご覧いただきありがとうございました。

こんにちは、SCSKのひるたんぬです。 もう4月になりますね…2024年度の幕開けです。 昨年の4月に新入社員としてSCSKに入社し社会人デビューをした身としては、あっという間の一年だったなぁ…と思うと同時に、「もう後輩が来るんですか！？」というのが正直なところです。少しでも先輩らしい(？)振る舞いができるようになりたいものです。 今回は、仕事上…というよりもプライベートで取り組んでみたことについてご紹介いたします。 背景 私は学生時代の友人と、「まれによく¹」Minecraftをして遊びます。 学生時代はサーバやインフラに関する知識などは全くと言っていいほどなかったため、 月額固定料金のサーバを契約 → Minecraftサーバとしての初期設定 → 一定期間遊ぶ → 飽きる → 解約する を繰り返していました。この「まれによく」という頻度がくせ者でして、 よく遊ぶ…固定料金を契約して好きなだけ遊ぶ まれに遊びたくなる…その気持ちをこらえて、忘却を待つ とできないのです。皆さんも今回の話に限らず、このようなことありませんか…？ ある日、私がクラウド関係の仕事をしていると友人に話したところ、 マイクラ(Minecraft)って、急に無性に遊びたくなるんだよねぇ… 今までみたいに いちいち契約して設定して使うっていうのは面倒くさい・時間かかる し、かと言って ずーーっと契約して遊ぶほどでもないんだよね。お金の無駄だし。 なんとかならない？？ ※若干脚色しております。 …なんとわがままなのでしょうか。 しかし、言っていることはごもっともであり、そういうことなら何か仕組みを作ってみよう！ということで、今回の取り組みが幕を開けました。 ¹ 「まれによく」という言葉は正しい日本語ではないですが、この頻度を適切に表す表現が他に見当たらないためこの表現を用いています。 こちらの図解 「1. よくある(頻発する)ことが稀に起こる状態」が私が表現したい頻度です。   取り組み概要 今回は「 友人と普段の通話やチャットで用いている Discord 」と「 私が業務で触れている AWS 」を組み合わせて、先程の友人のわがままを叶えようと考えました。調べたところ、既に同様のことに取り組まれている方々がおり、それらを参考に以下のようなアーキテクチャを構築しました。 ここでの特徴は 「Lambdaが多段構成」となっている 点です。このようにすることで、EC2に関する処理に時間がかかってもタイムアウトとなることを防いでいます。 もう少し詳しく説明いたします。 通常は下図に示すアーキテクチャが一般的だと思われます。 こちらの場合ですと、「App」のLambdaがServerとのやり取りをし、その結果をAPI Gateway経由でDiscordに返すという処理の流れになります。しかし、Discordのドキュメントを確認すると、 Interaction  tokens  are valid for  15 minutes  and can be used to send followup messages but you  must send an initial response within 3 seconds of receiving the event . If the 3 second deadline is exceeded, the token will be invalidated. 引用元：Discord Developper Potal 「 Interactions: Receiving and Responding 」 と記載があります。つまり、 Discordに対して3秒以内に一度応答を返さないとエラーになってしまう のです。そのため、通常の構成ですとEC2の起動や終了の命令を出すことはできても、EC2側においてそれらの処理が正常に完了したかを確認する時間がありません。 そこで、最初に示したようにLambdaを多段構成にすることで、「App」が対応するLambdaを非同期で呼び出し、仮の応答(ACK)をDiscordに返します。そして、対応するLambdaがそれぞれの処理を実行し、メッセージを更新するという形で仮の応答を更新します。これにより、タイムアウトのエラーを防ぎ、適切な応答を返すことができるようになります。 記事の構成上、参考サイト等は記事の末尾に記載しております。   構築手順 ここからはアーキテクチャの構築手順について、Discord Botの作成からAWSでのリソース構築までを画像での解説を交えながら順に説明いたします。 少々長い内容とはなりますが、最後までお付き合いいただけますと幸いです。 Discord Botの作成 Discord Developer Portal にアクセス 「New Application」を押下し、Botのアカウント名を入力し「Create」を押下する。 遷移先の画面（General Infomation）にて、 ・APPLICATION ID ・PUBLIC KEY を控えておく。 左ペインより「Bot」を選択し、「Reset Token」を押下してトークンを発行する。 発行されたトークンを控えておく。                        このタイミングで「USERNAME」を編集しても問題ありません。 ここで設定する名前が、Discordの表示名となります。 発行されたトークンは画面遷移などにより再表示できなくなる場合があるので、発行したタイミングで必ず控えておくようにしてください。 控え忘れてしまった場合は再度「Reset Token」を押下してトークンを発行してください。 スラッシュコマンドの登録 実際にDiscordからBotを呼ぶ際に、多くの方は「/XXXXX」という形式でコマンドを入力すると思います。 今回作成するBotもこのような形で利用するため、コマンドの登録を行います。 以下のコードの「認証情報」を自身の情報に置換した上、Python（実行環境は問いません）で実行してください。 “Registration Completed!!”と表示されれば正常に処理が行われています。                                       # register-slash-commands.py import requests import json # 認証情報 BOT_ACCESS_TOKEN = "トークンを記載" APPLICATION_ID = "APPLICATION IDを記載" commands = {   "name": "server",   "description": "EC2の起動状態を管理します",   "options": [       {           "name": "action",           "description": "開始(start)・停止(stop)・状態確認(status)",           "type": 3,           "required": True,           "choices": [               {"name": "start", "value": "start"},               {"name": "stop", "value": "stop"},               {"name": "status", "value": "status"},           ],       },   ], } def main():   url = f"https://discord.com/api/v10/applications/{APPLICATION_ID}/commands"   headers = {       "Authorization": f'Bot {BOT_ACCESS_TOKEN}',       "Content-Type": "application/json",   } try: res = requests.post(url, headers=headers, data=json.dumps(commands)) res.raise_for_status() print("Registration Completed!!") except Exception as e: print("Error occurred.", e) if __name__ == "__main__": main()   リソースの構築 事前準備 今回は前提条件として、サーバとなるEC2インスタンスは既に作成されているものとします。 そのため、この時点でEC2インスタンスを作成していない方は作成してください。 今回の要件においては、EC2インスタンスを作成するのみで問題ありません。 サーバとしての設定等は不要です。 また、下記に示す4つのPythonコードを指定名で保存し、一つのzipファイルに圧縮してください。zipファイル名は任意です。 そして、そのzipファイルを適当なS3バケットにアップロードしてください。 ※…コメントアウト等で処理内容を残すべきですが、コードの量が多いため削除しております。 # ファイル名 -> app.py import os import json import boto3 import logging from nacl.signing import VerifyKey logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event: dict, context: dict):   try:       headers: dict = {k.lower(): v for k, v in event["headers"].items()}       rawBody: str = event.get("body", "")       signature: str = headers.get("x-signature-ed25519", "")       timestamp: str = headers.get("x-signature-timestamp", "")       if not verify(signature, timestamp, rawBody):           return {               "cookies": [],               "isBase64Encoded": False,               "statusCode": 401,               "headers": {},               "body": "",           }       req: dict = json.loads(rawBody)       if req["type"] == 1:           return {"type": 1}       elif req["type"] == 2:           action = req["data"]["options"][0]["value"]           if action == "start":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Start",                   InvocationType="Event",                   Payload=payload,               )           elif action == "stop":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Stop",                   InvocationType="Event",                   Payload=payload,               )           elif action == "status":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Status",                   InvocationType="Event",                   Payload=payload,               )           else:               Exception("Unexpected Command")       return {           "type": 5,       }   except Exception as e:       logger.error(str(e))       return e def verify(signature: str, timestamp: str, body: str) -> bool:   PUBLIC_KEY = os.environ["PUBLIC_KEY"]   verify_key = VerifyKey(bytes.fromhex(PUBLIC_KEY))   try:       verify_key.verify(           f"{timestamp}{body}".encode(), bytes.fromhex(signature)       )   except Exception as e:       logger.warning(f"failed to verify request: {e}")       return False   return True # ファイル名 -> start.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = start_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server is already running\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 0:       message = {"content": "Server becomes ready!\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 2:       message = {"content": "Starting instance process failed"}   else:       message = {"content": "Unexpected error at starting process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished starting script")   return r.status_code def start_ec2(instance_id: str) -> dict:   try:       logger.info("Starting instance: " + str(instance_id))       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       if (status_response["Reservations"][0]["Instances"][0]["State"]["Name"] == "running"):           logger.info("Instance is already running: " + str(instance_id))           return {"status": 1, "ip": get_public_ip(status_response)}       else:           logger.info("Start instance: " + str(instance_id))           response = ec2_client.start_instances(InstanceIds=[instance_id])           logger.debug(response)           logger.info("Waiting for Instance to be ready: " + str(instance_id))           try:               waiter_running = ec2_client.get_waiter("instance_running")               waiter_status = ec2_client.get_waiter("instance_status_ok")               waiter_running.wait(InstanceIds=[instance_id])               waiter_status.wait(InstanceIds=[instance_id])               logger.info("Starting instance: " + str(instance_id))               return {"status": 0, "ip": get_public_ip(ec2_client.describe_instances(InstanceIds=[instance_id]))}           except Exception as e:               logger.error("Starting instance process failed.")               logger.error(str(e))               return {"status": 2}   except Exception as e:       logger.error(str(e))       return {"status": 3} def get_public_ip(response: dict) -> str:   try:       ip_address = response["Reservations"][0]["Instances"][0]["PublicIpAddress"]   except KeyError as e:       logger.warning("Failed Extract ip address.")       ip_address = "XXX.XXX.XXX.XXX"   except Exception as e:       logger.error(str(e))       ip_address = "XXX.XXX.XXX.XXX"   return ip_address # ファイル名 -> stop.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = stop_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server is already stopped"}   elif result["status"] == 0:       message = {"content": "Server stopped!"}   else:       message = {"content": "Unexpected error at stopping process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished stopping script")   return r.status_code def stop_ec2(instance_id: str) -> None:   try:       logger.info("Stopping instance: " + str(instance_id))       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       if (status_response["Reservations"][0]["Instances"][0]["State"]["Name"] == "stopped"):           logger.info("Instance is already stopped: " + str(instance_id))           return {"status": 1}       else:           logger.info("Stop instance: " + str(instance_id))           response = ec2_client.stop_instances(InstanceIds=[instance_id])           logger.debug(response)           logger.info("Waiting for Instance to be stopped: " + str(instance_id))           try:               waiter_stopped = ec2_client.get_waiter("instance_stopped")               waiter_stopped.wait(InstanceIds=[instance_id])               logger.info("Stopped instance: " + str(instance_id))               return {"status": 0}           except Exception as e:               logger.error("Stopping instance process failed.")               logger.error(str(e))               return {"status": 2}   except Exception as e:       logger.error(str(e))       return {"status": 3} # ファイル名 -> status.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = status_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server: Stopped"}   elif result["status"] == 0:       message = {"content": "Server: Running\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 2:       message = {"content": "Server: Pending"}   elif result["status"] == 3:       message = {"content": "Unexpected instance status"}   else:       message = {"content": "Unexpected error at status check process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished status checking script")   return r.status_code def status_ec2(instance_id: str) -> None:   result = {}   try:       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       status = status_response["Reservations"][0]["Instances"][0]["State"]["Name"]       if (status == "running"):           logger.info("Instance is running: " + str(instance_id))           result["status"] = 0           result["ip"] = status_response["Reservations"][0]["Instances"][0]["PublicIpAddress"]       elif (status == "stopping" or status == "stopped"):           logger.info("Instance is stoppping: " + str(instance_id))           result["status"] = 1       elif (status == "pending"):           logger.info("Instance is pending: " + str(instance_id))           result["status"] = 2       else:           logger.warning("Unexpected instance status")           result["status"] = 3       return result   except Exception as e:       logger.error(str(e))       result["status"] = 4       return result アップロード後、zipファイルのオブジェクトを開き、キーを控えておいてください。     Layerの作成 先ほどのLambda関数において、外部ライブラリを使用します。 それにあたり、必要なパッケージを用意します。 私はCloud9にてPython 3.12を使用し作成しました。 そのため、デプロイするLambdaのランタイムもPython 3.12にしてあります。 下記引用に記載があるように、Lambdaのレイヤー作成にはLinux環境が必要です。 Windowsやmac OSでレイヤーファイルを作成した場合、Lambdaが動作しないケースがあります。 ※…私はWindowsで作成してしまい、一度引っかかりました。 The first step to creating a layer is to bundle all of your layer content into a .zip file archive. Because Lambda functions run on  Amazon Linux , your layer content must be able to compile and build in a Linux environment. If you build packages on your local Windows or Mac machine, you’ll get output binaries for that operating system by default. These binaries may not work properly when you upload them to Lambda. 引用元：AWS Lambda Document「 Packaging your layer content 」※…日本語版は機械翻訳のため、英語版サイトから引用しています。 カレントディレクトリ上に「requirements.txt」を作成します。テキストファイル内には以下を入力してください。 PyNaCl==1.5.0 requests urllib3<2 以下のコマンドを実行します。 $ mkdir python $ pip install -r requirements.txt -t ./python $ zip -r9 layer.zip python カレントディレクトリに「layer.zip」ができていることを確認し、そのzipファイルを適当なS3バケットにアップロードしてください。アップロード後、コードと同様にzipファイルのオブジェクトを開き、キーを控えておいてください。 レイヤーファイルのアップロード場所は、先程コードをアップロードしたバケットと同一でも問題ありません。 CloudFormationによる構築 今回構築するAPI Gateway, Lambda, IAMのCloudFormationテンプレートを用意しました。 以下のYAMLファイルを使用し、リソースをデプロイしてください。 パラメータには ApplicationID…Discord Bot作成時の「APPLICATION ID」 CodeS3BucketName…事前準備で格納したコードの宛先S3バケット名 CodeS3Key…コードのキー EC2InstanceID…制御したいEC2インスタンスのID LayerS3BucketName…事前準備で格納したレイヤーの宛先S3バケット名 LayerS3Key…レイヤーのキー PublicKey…Discord Bot作成時の「PUBLIC KEY」 をそれぞれ入力してください。 AWSTemplateFormatVersion: 2010-09-09 Parameters: ApplicationID:   Type: String PublicKey:   Type: String EC2InstanceID:   Type: String CodeS3BucketName:   Type: String CodeS3Key:   Type: String LayerS3BucketName:   Type: String LayerS3Key:   Type: String Resources: # API Gateway ControlAPIGateway:   Type: AWS::ApiGatewayV2::Api   Properties:     Name: DiscordSlashCommandController-Api     ProtocolType: HTTP ControlAPIGatewayIntegration:   Type: AWS::ApiGatewayV2::Integration   Properties:     ApiId: !Ref ControlAPIGateway     IntegrationType: AWS_PROXY     IntegrationUri: !GetAtt AppFunction.Arn     PayloadFormatVersion: 2.0 ControlAPIGatewayRoute:   Type: AWS::ApiGatewayV2::Route   Properties:     ApiId: !Ref ControlAPIGateway     RouteKey: POST /     Target: !Sub integrations/${ControlAPIGatewayIntegration} ControlAPIGatewayStage:   Type: AWS::ApiGatewayV2::Stage   Properties:     ApiId: !Ref ControlAPIGateway     StageName: $default     AutoDeploy: true # Lambda layer LambdaLayer:   Type: "AWS::Lambda::LayerVersion"   Properties:     CompatibleRuntimes:       - python3.12     Content:       S3Bucket: !Ref LayerS3BucketName       S3Key: !Ref LayerS3Key     LayerName: DiscordSlashCommandController-Layer # Lambda function AppFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: app.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-App     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 10     Environment:       Variables:         PUBLIC_KEY: !Ref PublicKey         APPLICATION_ID: !Ref ApplicationID     Role: !GetAtt LambdaExecutionRole.Arn StartFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: start.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Start     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 600     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn StopFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: stop.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Stop     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 60     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn StatusFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: status.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Status     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 10     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn # Lambda execution log groups AppFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${AppFunction}     RetentionInDays: 30 StartFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StartFunction}     RetentionInDays: 30 StopFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StopFunction}     RetentionInDays: 30 StatusFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StatusFunction}     RetentionInDays: 30 # Lambda invoke permission ApiGWInvokeAppFunction:   Type: AWS::Lambda::Permission   Properties:     Action: lambda:InvokeFunction     FunctionName: !GetAtt AppFunction.Arn     Principal: apigateway.amazonaws.com     SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ControlAPIGateway}/*   # Lambda IAM Role LambdaExecutionRole:   Type: AWS::IAM::Role   Properties:     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Action: sts:AssumeRole           Effect: Allow           Principal:             Service: lambda.amazonaws.com     Policies:       - PolicyDocument:           Version: 2012-10-17           Statement:             - Action:                 - lambda:InvokeFunction                 - ec2:DescribeInstances                 - ec2:DescribeInstanceStatus                 - ec2:StopInstances                 - ec2:StartInstances               Effect: Allow               Resource: "*"         PolicyName: IPL-DiscordSlashCommandController     ManagedPolicyArns:       - "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"     RoleName: IRL-DiscordSlashCommandController Outputs: EndpointURL:   Value: !Sub https://${ControlAPIGateway}.execute-api.${AWS::Region}.${AWS::URLSuffix}/ 構築が完了すると、出力にエンドポイントのURLがありますので、そちらを控えておきます。 Discord Botの利用 Discord Developer Portal に再びアクセスし、先程作成したApplicationをクリックします。 中段にある「INTERACTIONS ENDPOINT URL」に、先程控えたエンドポイントURLを貼り付けます。 「Save Changes」を押下すると、接続テストが行われ正常に疎通確認が取れるとエンドポイントURLが保存されます。 ここで何かしらのエラーが出る場合は、APIが正常に構築できていない・貼り付け先のBOTを間違えている可能性があります。 Botの招待 左ペインより「OAuth2」を選択し、下段「OAuth2 URL Generator – SCOPES」から「bot」と「applications.commands」にチェックを入れます。その後、その下に表示されている「GENERATED URL」をコピーします。 コピーしたURLにアクセスして、サーバーにBotを招待します。 Botをサーバへ招待するには、サーバの管理者など「サーバ管理権限」を持つアカウントでの操作が必要です。 動作確認 Botが招待されたサーバのテキストチャンネルにて、スラッシュコマンドを入力します。 下記画像では「/server」を入力したあとに、コマンドの候補や説明が適切に表示されていることが分かります。 それぞれのコマンド（start, stop, status）を入力し、所望の応答が得られることを確認します。 コマンド入力直後（共通） サーバ開始時（/server start） サーバ終了時（/server stop） サーバステータス確認時（/server status） IPアドレス欄のみコードブロックにて独立して配置することで、IPアドレスのコピーを容易にしています。   参考サイト 今回の実装にあたり、以下のサイトを参考にさせていただきました。 構成や実際のコードを参考にいたしました。 discord の slash commands からEC2を操作できるようにしてみた - Qiita はじめにはじめまして、@nahiro_tus です。突然ですが、皆さんはdiscordのslash commands機能をご存知ですか？… qiita.com 応答方法の処理について参考にいたしました。 Discord Interaction Endpoint を多段 Lambda 構成にしてタイムアウトを回避する | DevelopersIO 前回の記事の続きです。 Discord の Interaction Endpoint は仕様上、Interaction リクエストから応答までに制限時間が設けられています。 制限時間を超えてしまう場合は、一旦仮の応答を返 … dev.classmethod.jp Discord Developer Portal — API Docs for Bots and Developers Integrate your service with Discord — whether it's a bot or a game or whatever your wildest imagination can come up with... discord.com Layerを作成する際に参考にいたしました。 AWS Lambda (Python 3.12) で使用可能な pandas の Lambda Layer を準備する データ分析や加工でよく使われるライブラリに、pandas があると思います。本記事では、AWS Lambda (Python 3.12) で動作する pandas の Lambda Layer を準備する手順を紹介します。 blog.usize-tech.com 2022.06.07 Lambda+PythonでLayerを使うときにハマったこと | ドクセル ドクセルはスライドやPDFをかんたんに共有できるサイトです www.docswell.com CloudFormationテンプレートを作成する際に参考にいたしました。 Amazon API Gateway と AWS Lambda の連携でもうハマりたくない [AWS CloudFormation テンプレート付き] Amazon API Gateway と AWS Lambda の連携がうまくできず時間を浪費してしまう方は結構いらっしゃるのではないかと思います。Amazon API Gateway のタイプや AWS Lambda との統合の仕方によって AWS Lambda 関数のコードも変わるので厄介です。私はそこでハマるのが嫌で、Amazon API Gateway と AWS Lambda 関数の標準設定パターンを決めて使い回ししています。 blog.usize-tech.com 2022.04.11 この他にも、API GatewayやLambdaのCloudFormationに関するドキュメント、Discord Developer Potalの公式ドキュメントも参考にしております。   終わりに 今回は、インフラのことを知らない人でもDiscord上から簡単にEC2インスタンスの開始・停止を行うための仕組みをご紹介いたしました。インスタンスを使いたい人が自分の好きなタイミングで開始や停止ができるので、運用面や費用面でも大きなメリットがあるのではないかなと思っております。 個人的にも一からこのような仕組みを構築することができ、達成感や学ぶことが多くありました。 （アイデアやコードは多くのサイトを参考にさせていただきました。） とても長くなってしまいましたが、最後までご覧いただきありがとうございました！ 余談：私はDiscordやVS Codeをライトテーマで使うタイプです。

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 以前、AWSのVPC上で双方向1対1NATを実現するという記事を書きました。 AWSで双方向1対1NATインスタンスを構築する AWS環境でNATが必要なとき、NAT Gatewayなどのマネージドサービスが用意されていますが、双方向のNATが行えないなどの制約があります。双方向(SNAT, DNAT)での1対1NATを実現したい場合には、EC2でNAT用のインスタンスを構築することがひとつのソリューションとなりえるでしょう。本記事では、iptablesを使用した双方向NAT用インスタンスの構築手順を説明します。 blog.usize-tech.com 2024.01.04 今回は、オンプレミスもからんだ、やや複雑な環境で2社間をNATして接続することを考えてみます。 接続要件 接続要件は下図の通りです。 Direct Connect接続構成 A社オンプレミス環境とB社オンプレミス環境を接続したいとします。A社はAWSのアカウントを持っており、既にDirect Connectで接続しています。Direct ConnectはVPCのひとつに、仮想プライベートゲートウェイ経由で関連付けされています。 一方、B社はAWSアカウントを持っていません。キャリアの閉域網を契約しており、そのサービスの一つに閉域網とAWSを接続するサービスがあるので、それを使ってAWSアカウントに接続することができます。B社はAWSアカウントを取得する予定がないため、A社の管理するAWSアカウントにPrivate VIFで接続することを希望しています。(※) ※Transit VIFが出せないので、Direct Connect – Direct Connect Gateway – Transit Gateway という構成は取れないということです。 通信要件 通信要件は大きくふたつ、以下の通りです。 １．A社オンプレミス上のクライアントからB社オンプレミス上のサーバへの通信(通信要件(1)) TCPを用いて、A社 → B社のコネクションが発生します。 ２．A社AWSアカウント上のクライアント兼サーバとB社オンプレミス上のクライアント兼サーバの通信(通信要件(2)) TCPを用いて、A社 → B社、B社 → A社の両方のコネクションが発生します。 NAT要件 B社は、A社のIPアドレスを隠蔽して、B社の指定するIPアドレス(10.129.0.0/16)にNATしてもらいたいという要件があります。 A社も、B社のIPアドレスがA社で既に使用しているレンジであれば当然NATをする必要がありますが、調査の結果、B社の使用するIPアドレスはA社では使用していないと判明したため、B社のIPアドレスは隠蔽しないことにしました。 ソリューション A社を支援する立場で構築した環境は下図の通りです。 既存VPCの仮想プライベートゲートウェイAにB社のDirect Connectを接続するのは問題があると考え、B社接続専用の新規VPCを構成し、仮想プライベートゲートウェイBとB社Direct Connectを関連付ける設計としています。 NAT要件は、EC2のLinuxインスタンスでiptablesを使用したNATインスタンスを構築することにより満たすことにしました。一見、NAT Gatewayでも要件を満たせるように思えますが、NAT GatewayではB社からA社へコネクションを開始する通信要件(通信要件(2))が満たせません。 既存VPCと新規VPCはTransit Gatewayで接続します。VPC間接続というとVPC Peeringが思い浮かびますが、VPC PeeringだとNAT構成がより複雑になってしまうという点と、Transit Gateway構成にしておくと将来的にInspection VPCを導入してセキュリティを強化するという選択肢が増えるため、Transit Gatewayを選択しました。 また、この構成ではA社オンプレからB社オンプレや新規VPCに直接通信することができないので、既存VPCにNetwork Load Balancerをはさむことでこの問題を解決しています。 以下、このような設計とした意図を解説します。 Direct Connectの接続ポイント 以下の図のような、仮想プライベートゲートウェイAにB社ダイレクトコネクトのVIFを関連付ける構成を考えてみます。 Network Load Balancerを経由してA社オンプレとB社オンプレを接続する理由は別項で解説することにして、まずはB社Direct Connectを仮想プライベートゲートウェイAに関連付けることの良し悪しについて検討します。 この構成の場合、B社側の設定ミス等により、例えばデフォルトルート(0.0.0.0/0)などをA社にアドバタイズできてしまいます。その場合、A社オンプレとA社AWS環境間の通信に問題が発生する可能性があります。 また、仮想プライベートゲートウェイAは既存VPCのCIDR全体をB社にアドバタイズしてしまいます。そのため、B社から、A社既存VPC上の、今回の通信要件と関係のないサーバに通信を試みることができます。ネットワークACLを使用することで上手く制御できるかもしれませんが、セキュリティ管理上の難易度が高くなってしまいます。 以上の理由から、B社Direct Connectを収容するための専用のVPCを構成する設計としました。(前項『ソリューション』の図参照) この構成であれば、B社側からデフォルトルートがアドバタイズされてきたとしても経路を持ってしまうのは仮想プライベートゲートウェイBだけですから、既存VPCとA社オンプレの通信に影響が出ることはありません。 NATインスタンス NAT要件を満たすために、A社新規VPCにNAT機能を有するデバイスを配置します。 A社 → B社 方向の通信を考えると、A社のアドレスさえ隠蔽できればよく(送信元NAT, SNAT)、A社側からはB社のIPアドレスに通信すればよいので、NAT Gatewayで通信要件を満たせるように見えます。 しかし、通信要件(2)はB社 → A社 方向のコネクションも発生します。NAT Gatewayの提供する機能はN対1 NAT(IPマスカレード)と呼ばれるものなので、B社からNAT GatewayのIPアドレスに通信を試みても、A社内のサーバと通信することはできません。 以上の理由から、EC2を用いて独自にNAT用のインスタンスを作成することにしました。(※) ※ここで言うNAT用のインスタンスは、 AWSが過去にNATインスタンスと呼んでいたもの のことではありません。AWSがNATインスタンスと呼んでいたものは既にAMIのサポートが終了しており、また、基本的にはNAT Gatewayと同様にN対1 NAT(IPマスカレード)の機能提供を前提にしているため、本件の用途に向きません。 LinuxのEC2インスタンスを使用して双方向のコネクションに対応したNATインスタンスを作成する方法については、以下の記事を参考にしてください。 AWSで双方向1対1NATインスタンスを構築する AWS環境でNATが必要なとき、NAT Gatewayなどのマネージドサービスが用意されていますが、双方向のNATが行えないなどの制約があります。双方向(SNAT, DNAT)での1対1NATを実現したい場合には、EC2でNAT用のインスタンスを構築することがひとつのソリューションとなりえるでしょう。本記事では、iptablesを使用した双方向NAT用インスタンスの構築手順を説明します。 blog.usize-tech.com 2024.01.04 VPC間接続(Transit Gateway) 既存VPCと新規VPCを接続する必要があります。まずはVPC Peeringで接続することを検討してみます。VPC Peeringは無料で使用できるので、要件に合うのであればVPC Peeringを採用したいところです。 VPC Peeringの特徴は、接続したVPC同士の経路情報しか持っていない点です。この図でいうと、既存VPCと新規VPCの通信はできますが、既存VPCとB社オンプレは直接通信できません。VPC PeeringがB社オンプレへの経路を持っていないからです。 これに対処する方法としては、NATインスタンスでB社オンプレのIPアドレスを隠蔽するようにNATを設定し、A社からは新規VPC上のIPアドレス(10.129.0.0/16)と通信しているように見せかけるというものがあります。 この構成を採用してもよいのですが、せっかく通信要件・NAT要件を整理した結果、B社オンプレのIPアドレスを隠蔽する必要はないという結論に至ったのに、結果としてB社オンプレのIPアドレスを隠蔽するNATを導入することになります。運用面・障害対応面から見た場合、構成はできるだけシンプルにしたいので、この構成は検討の余地があります。 また、VPC Peeringの制約事項としてよく言われることですが、二つのVPCを接続するごとに一つのVPC Peeringを設定する必要があります。この図では必要なVPC Peeringの数は1ですが、他のVPC(図に書いていないだけでいくつかあります)からB社に接続する要件が出てきたら？とか、B社以外にもC社、D社と今回の接続形態でつなぐことになったら……？と考えると、VPC Peeringの管理負荷が重くのしかかってきます。 管理のシンプル化という観点と、将来的にC社、D社……と同様の形態で接続することを考えたときに、必要に応じて Inspection VPC という形ですべてのVPC間通信をひとつのNetwork Firewallで集約して検査する機能を導入することで、相対的に低い運用負荷で高度なセキュリティを実装できるという点から、Transit GatewayでVPC間を接続する構成を選択しました。 Transit Gateway構成であれば、前述の直接接続したVPC同士でしか通信できないという制約も受けないので、A社既存VPCからB社オンプレに通信するのに、B社オンプレIPを隠蔽する必要もありません。 Network Load Balancer 最後に既存VPCに配置したNetwork Load Balancerについて解説します。 実は仮想プライベートゲートウェイは、Direct Connect側(オンプレ側)に対しては比較的自由に経路を設定できるのですが、仮想プライベートゲートウェイが関連付けられているVPCの”先”のネットワークへの経路を持つことができません。 この図を例にとると、仮想プライベートゲートウェイAは、新規VPCやB社オンプレへの経路を持っていません。同様に、仮想プライベートゲートウェイBは、既存VPCやA社オンプレへの経路を持ちません。 つまりどういうことかというと、A社オンプレは、既存VPC以外とは通信できません。ここからB社オンプレにたどり着くためには、NATを駆使することになります。この場面で活躍する優秀なデバイスがNetwork Load Balancerです。 A社オンプレから既存VPC上のNetwork Load BalancerのIPアドレスに通信すると、送信先をNetwork Load BalancerのターゲットであるB社オンプレミス上の通信要件(1)サーバのIPアドレスに変換します(実質、送信先NAT, DNAT)。この時、送信元IPアドレスはA社オンプレのIPアドレスから、Network Load BalancerのIPアドレスに変換されます(実質、送信元NAT, SNAT)。 Transit Gatewayには、隣接するVPCにしか到達できないという制限がありませんので、Network Load Balancerから発信されたB社オンプレミス向けの通信はTransit Gatewayを通過し、NATインスタンスを通過していくことができます。そして仮想プライベートゲートウェイBに到達しますが、仮想プライベートゲートウェイBはB社オンプレへの経路を持っているので、無事B社オンプレ上のサーバに到達することができます。 次に、戻りの通信を考えます。B社オンプレミスからA社オンプレミスへの通信となりますが、行きの通信の時にNATインスタンスでA社のIPを隠蔽しB社体系のIP(新規VPCのCIDR)にNATされているので、送信先IPアドレスは新規VPC上のIPアドレスとなり、仮想プライベートゲートウェイBで破棄されることなく通過することができます。 NATインスタンスはNATを行って、Network Load BalancerのIPアドレスを送信先とします。VPC間はTransit Gatewayで接続しているので問題なく通過することができます。 Network Load Balancerは送信先をA社オンプレ上の通信要件(1)用クライアントのIPアドレスに変換します。送信元はNetwork Load BalancerのIPアドレスに変換されます。仮想プライベートゲートウェイAはA社オンプレへの経路を持っているので、A社オンプレ上のクライアントに戻っていくことができます。 まとめ 以上、NATを必要とする2社間のオンプレ/VPC接続構成について検討してみました。 Network Load Balancerは、実質的に送信元NAT、送信先NATを同時に行ってくれるので、仮想プライベートゲートウェイやVPC Peeringをいくつも越えないといけないときに大変重宝することが分かりました。ただし、ターゲットに定期的にヘルスチェックを実施してしまうので、他社のサーバをターゲットにする場合にはお断りを入れておくのがよいでしょう。 また、今回、双方向の通信要件に対応するためにEC2で独自にNAT機能を実装しましたが、EC2を使用するとOS以上はユーザー管理になってしまうので監視・運用の負荷が大きくなってしまう点が設計上の悩みどころです。AWSマネージドで柔軟かつ大規模なNATを実現できるサービスが出てくれると嬉しいですね。

皆様、こんにちは。 SCSK入社１年目の佐藤海渡です。 もう今月で、「入社１年目」と言えなくなってしまうことに恐怖を覚えている今日この頃です。 そんな私ですが、確実にこの１年で成長した点があります。 それは…   VCP-DCV 2024に合格したことです！ 今回の記事では、クラウド初学者である私が、VCP-DCVを受験し、合格するまでの流れをまとめてみようと思います。 VCP-DCVとは？ まず、最初に”VCP-DCV”とはどんな資格なのかを説明します。 VCP-DCVとは、”VMware Certified Professional – Data Center Virtualization”の略で データセンタを仮想化する技術に関するVMware社の認定資格です。 クラウドサービスを提供する基盤側の技術に関する資格で、 SCSKのクラウドサービスである ” USiZE ” も、このVMwareをベースにして構築されています。 「 ” USiZE ” ってなに？」って思ったそこのあなたはぜひ、私の執筆した第一回ブログをご参照ください。 USiZEってなに？～新人目線でまとめてみた～ – TechHarmony (usize-tech.com) ちなみに、VMwareの資格は難易度によって名称が分かれており、簡単な順に VCTA（VMware Certified Technical Associate） ↓ VCP（VMware Certified Professional）　 ←今回受験したのはこれ ↓ VCAP（Vmware Certified Advanced Professional） ↓ VCDX（Vmware Certified Design Expert） となっています。 また、分野によっても分かれており Data Center Virtualization（DCV）　 ←今回受験したのはこれ Network Virtualization（NW） Cloud Management and Automation（CMA） Security（SEC） ・・・ などなどに分かれています。 では、VCP-DCVがどんな試験で、どの立ち位置の試験なのか分かったところで 続いては、実際の受験の流れを記載していきます。 受験までの流れ 受験までの大きな流れとしては ①トレーニングコースの受講 ②資格試験の申込 ③試験対策の勉強 となります。それぞれについて以下で簡単に説明します。 ①トレーニングコースの受講 VCP認定資格を保有していない場合、トレーニングコースの受講が必須となります。 トレーニングはvSphereのバージョンや受講用途に応じていくつか種類がありますが、私は VMware vSphere: Install, Configure, Manage [V8] を受講しました。 上記のコースでは5日間でVMware vSphereの導入から管理までをみっちりINPUTしました。 コースの中ではハンズオンによるトレーニングもあり、実際にvSphereを操作することでより具体的なINPUTをすることが出来ました。 ハンズオンの中では、vCenterのデプロイからネットワークやストレージの作成、仮想マシンの作成からその管理方法、ライフサイクルの管理など実際の運用でも重要な内容が盛りだくさんとなっていました。 もっと詳しく内容が知りたいという方は、 こちら のリンクからコース概要についてご確認ください。 ②資格試験の申込 こちらは、AWSなどの資格試験と同様に Pearson VUE からの申し込みが可能となっています。 私は、テストセンターで受験しましたが、オンラインによる自宅からの受験も可能となっています。 （オンライン受験は準備が大変という噂を聞き、私はテストセンター受験にしました…笑） ③試験対策の勉強 こちらは、大きく行ったことは以下3点です。 ①のトレーニングコースのテキスト復習 Web上の問題集で演習 VMwareの公式ドキュメントを読む テキストの復習でINPUTをしっかりと行う ↓ 問題集を解いてみて知識のOUTPUTを行う ↓ 問題集を解いて疑問が残った部分について、公式のKBなどを読んで理解を深める 上記の勉強方法を資格受験の1か月前くらいから継続して行っていました。 試験当日 私は、テストセンターでの受験でしたので実際に試験会場に出向いての受験となりました。 当日、問題を見て困ったのが日本語→英語の問題文翻訳がなかったことです。 英語の問題集で対策をしていた方は、注意が必要かもしれません。 受験が終了すると、その場で合否と点数が出る試験になっています（合格点は300/500）。 勉強を頑張った甲斐もあり、何とかギリギリ合格することが出来ました。 受験から合格を振り返ってみて まず合格直後に思ったことは「受かって良かった！」ということでした。 短い時間でとにかくたくさんのINPUTをしていたので、中々試験までにすべてを覚えきることが難しく、試験中に何度も 「見たことはあるけど、どっちが正解だっけ」となることがありました。 そのため、その場で合格が分かった際には、まずほっとした感じでした。 しかしながら間違いなく、このVCP-DCVの受験を通してVMware vSphereに関するスキルは格段に向上したと思います。 今回の学びを活かして、USiZEのサービスをよりよくしていこうと思いますので ここまで読んでくださった方はぜひUSiZEに関しても興味をもっていただければと思います！ USiZEに関する情報は以下をご参照ください。 USiZEってなに？～新人目線でまとめてみた～ – TechHarmony (usize-tech.com) 　 ←USiZEについて簡単にまとめたもの クラウド移行だけでは描けない、理想のDXを実現する (scsk.jp) 　 ←USiZEホームページ お問い合わせ｜クラウド移行だけでは描けない、理想のDXを実現する (scsk.jp) 　 ←USiZEお問い合わせ先   以上、SCSK佐藤海渡の新卒1年目最後の記事でした。

こんにちは。SCSKの和田です。 私は、SCSKのプライベートクラウド「 USiZEシェアードモデル 」（ユーサイズシェアードモデル）のサービス企画・開発を担当しています。「USiZEって何だろう？」と思われた方、または「ちょっと気になる！」という好奇心旺盛なあなた！USiZEの世界を覗いてみたくなったら、まずはこちらをクリック↓ SCSKのプライベートクラウド「USiZEシェアードモデル」とは？ SCSKのプライベートクラウド「USiZEシェアードモデル」（ユーサイズシェアードモデル）についてご紹介します。 blog.usize-tech.com 2023.12.19 さて今回は、ちょっとした工夫を施した自動電話通知の仕組みを作成したので、その紹介をさせていただきます。 そもそも なぜ作ったの？ 正直なところ、システムのトラブルとは無縁でいたいのが本音ですが、いざという時には迅速な対応が求められます。 特にシステム監視からの重要なアラームが鳴った際には、ただちに通知を受け取りたいもの。ですが、夜中に急に鳴る電話にぼんやりと応答するのは、あまり賢明な対応とは言えませんよね。。。 そこで、電話に出た際に「きちんとアラーム発生の電話だと認識して、自分が対応し始めるぞ！」というアクションが伴う自動通知の仕組みが必要だと考えました。まずは、大まかなアーキテクチャからご紹介します。   アーキテクチャ 処理の流れを説明します。 アラーム発生時に左上の「電話通知用Lambda」を起動します。連絡先電話番号テーブルから連絡先を取得し、Amazon Connectを利用して電話をかけます。電話をかけたタイミングで、電話結果格納用テーブルに通話が開始されたことを登録します。 相手が電話に出て「ダイヤル1を押す」という対応の意思表示をした場合、右上の「電話結果確認用Lambda」を呼び出し、１で登録した電話結果格納用テーブルに結果を更新して終了します。 相手が電話に出たけれどダイヤル１を押さなかった、または電話に出なかった場合、「電話通知用Lambda」を非同期で呼び出すことで、次の連絡先へ電話をかける処理を開始します。 つまり、電話に出た際にダイヤル１を押すという明確なアクションを誰かが実施するまでは、アラーム担当者たちに順番に電話がかかり続けるというものです。次は、実際にどうやって作ったのかをご説明します。   どうやって作ったの？ Step1.監視設定・DynamoDBテーブル作成 まず、Amazon CloudWatch等を使用して監視システムを整えます。詳細な設定方法は他の記事に譲るとして、要点はアラームが作動した際にLambda関数を自動で起動することです。これにより、アラームの発生をシステムが即座に検知し対応に移れるようにします。 そして、「連絡先電話番号テーブル」と「電話結果格納テーブル」の２つのDynamoDBのテーブルを作成します。 連絡先電話番号テーブル パーティションキーはcall_group（String）、ソートキーはpriority（Number）を指定し、下記のようなデータを登録します。 処理を動かすには最低限これだけあれば十分です。 ※call_group：電話を掛ける対象のグループ、priority：通知順序の数字、phone_number：電話を掛けたい相手の電話番号 電話結果格納テーブル パーティションキーはcontact_id（String）を指定しておきます。こちらは事前にデータ登録は不要です。 Step2.Lambdaの作成 続いて、「電話通知用」と「電話結果確認用」の２つのLambdaを作成します。どちらもランタイムはPython3.9です。 IAMロールについては今回の記事のメインではないので、説明を割愛します。適宜、必要となる権限を付けたロールを作成してください。 電話通知用Lambda まず連絡先電話番号テーブルに登録されている１人目に電話をかけ、ダイヤル１を押すという意思表示がされた場合には処理を終了します。意思表示の対応が確認できなかった場合には、自分自身を非同期で呼び出し、次の人へ電話がかかるようにして処理を終了します。 電話をかける相手が多数いる場合や何周も電話をかけたい場合に、Lambdaのタイムアウト上限に達しないように、１回の電話ごとにLambdaを終了させるようにしています。 説明用に様々な設定情報を環境変数に設定していますが、実際の運用では設定ファイルをS3バケットに配置し、そこから読み込むなど、状況に応じて適宜変更してください。 import json import boto3 import os import time from boto3.dynamodb.conditions import Key dynamodb = boto3.resource("dynamodb") clientLambda = boto3.client("lambda") connect = boto3.client("connect") def lambda_handler(event, context):   print(json.dumps(event))   # *****処理1*****   # 環境変数に適宜必要となる情報を設定しておき、取得する   connectInstanceId = os.environ["CONNECT_INSTANCE_ID"]  # Amazon ConnectのインスタンスID   connectContactFlowId = os.environ["CONNECT_CONTACTFLOW_ID"]  # Amazon ConnectのコンタクトフローID   callerPhoneNumber = os.environ["CALLER_PHONE_NUMBER"]  # 発信元の電話番号   callStartMessage = os.environ["callStartMessage"]  # 電話開始時の音声 例）<speak>アラームが発生しました。対応する場合は、ダイヤル1を押してください<speak>     callConnectMessage = os.environ["callConnectMessage"]  # ダイヤル1が押されたときの時の音声 例）<speak>対応を確認しました<speak>   callNotConnectMessage = os.environ["callNotConnectMessage"]  # 電話が繋がらなかったときの音声 例）<speak>次の人へお繋します<speak>   callGroup = os.environ["call_group"]  # 電話を掛ける対象のグループ   nextLambda = os.environ["lambda_name"]  # 次に実行するLambdaの名前。このLambdaを再帰的に呼び出すために使用   # DynamoDBのテーブル名を取得   phoneTable_name = os.environ["phoneTable_name"] # 連絡先電話番号テーブル   contactTable_name = os.environ["contactTable_name"] # 電話結果格納テーブル   phoneTable = dynamodb.Table(phoneTable_name)     contactTable = dynamodb.Table(contactTable_name)   # *****処理2*****   # 何周目の何番目に登録の人に電話通知したいのかを判定。初回実行の場合は初期値を設定し、2回目以降は前回の情報を引き継ぐ     # 2回目以降の実行の場合は、前回の情報を引き継ぐ   if "processId" in event.keys():       processId = event["processId"]       callLoop = int(event["call_loop"]) # 何周目か         lastPhoneOrder = int(event["phone_order"])  # 前回は何番目の人に電話をかけたのか   # 初回実行の場合（processIdが存在しない場合）は初期値を設定     else:       processId = context.aws_request_id # lambdaのRequestIdをプロセスIDに設定       callLoop = 1  # 初回なので1周目とする         lastPhoneOrder = 0  # 初回なので0番目(前回はいない)とする   # *****処理3*****   # 電話を掛ける対象のグループ（１周）が何人なのか、何周目かを判定し、周回上限を超えるまでは次にかける電話番号を取得する     try:       phoneTableQueryResponse = phoneTable.query(           KeyConditionExpression=Key("call_group").eq(callGroup)         )       # call_group内の電話番号の数         maxPhoneOrder = phoneTableQueryResponse["Count"]   except Exception as error:         print("[ERROR]連絡先電話番号テーブルから通知先電話番号数の取得に失敗")       print(error)       return {'statusCode': 400 }   nextPhoneOrder = lastPhoneOrder + 1 # 次にかける電話番号の順番     # 次にかける電話番号の順番がcall_group内の通知先電話番号の数を超えていた場合は１番目に戻し、周回数を＋１する   if nextPhoneOrder > maxPhoneOrder:       nextPhoneOrder = 1       callLoop += 1   # 周回数が３以上になったら終了させる（２周まで電話をかけるとします）   if callLoop >= 3:       print("[INFO]上限周回数まで電話をかけ続けましたので、処理を終了します")       return {'statusCode': 200 }   # 連絡先電話番号テーブルから次かける電話番号を取得   try:       phoneTableGetResponse = phoneTable.get_item(           Key={"call_group": callGroup, "priority": nextPhoneOrder}       )         phoneNumber = phoneTableGetResponse["Item"]["phone_number"] # 次にかける電話番号   except Exception as error:       print("[ERROR]電話番号テーブルから次の電話番号の取得に失敗")       print(error)         return {'statusCode': 400 }   # *****処理4*****   # Step3で作成するコンタクトフローを指定して電話を掛ける   try:       connectResponse = connect.start_outbound_voice_contact(           DestinationPhoneNumber=phoneNumber,  # 送信先の電話番号           ContactFlowId=connectContactFlowId,           InstanceId=connectInstanceId,           SourcePhoneNumber=callerPhoneNumber,           Attributes={               "callStartMessage": callStartMessage,               "callConnectMessage": callConnectMessage,               "callNotConnectMessage": callNotConnectMessage,           },         )   except Exception as error:       print("[ERROR]Amazon Connectへの連係に失敗")       print(error)         return {'statusCode': 400 }     contactId = connectResponse["ContactId"]  # 発信のContactID   # *****処理5****   # 電話結果格納テーブルに通話開始を登録し、結果が格納されるのを待つ   try:       contactTabelputResponse = contactTable.put_item(           Item={               "contact_id": contactId,  # 発信のContactID               "call_flag": 0,  # 電話繋がったかフラグ 繋がれば1になる           }         )   except Exception as error:       print("[ERROR]電話結果格納テーブルへのコールフラグの準備に失敗")       print(error)         return {'statusCode': 400 }     # 応答があり電話結果格納テーブルが更新されるまで待機   time.sleep(60)   # 電話結果格納テーブルからcall_flagの情報を取得   try:       contactTableGetResponse = contactTable.get_item(           Key={               "contact_id": contactId,           }       )         callFlag = contactTableGetResponse["Item"]["call_flag"]  # 電話繋がったかフラグ   except Exception as error:       print("[ERROR]電話結果格納テーブルからコール結果の取得に失敗")       print(error)         return {'statusCode': 400 }     # *****処理6*****   # 電話応答の結果から、つながっていれば処理を終了し、つながっていなければ次の人に電話をかける   if callFlag == 0:       try:           passEvent = {               "processId": processId,               "phone_order": nextPhoneOrder,               "call_loop": callLoop,             }           lambda_responce = clientLambda.invoke(               FunctionName=nextLambda,               InvocationType="Event",  # 非同期的に呼び出す               Payload=json.dumps(passEvent),             )           # 呼び出しタイプがEventの場合はステータスコードが202が正常           lambdaStatusCode = lambda_responce["StatusCode"]             if lambdaStatusCode == 202:               print(f"[INFO]{nextLambda}にステータスコード「{str(lambdaStatusCode)}」で正常に連携されました")           else:               print(f"[ERROR]{nextLambda}にステータスコード「{str(lambdaStatusCode)}」で正常に連携されませんでした。")       except Exception as error:           print("[ERROR]次のLambda呼び出しに失敗")           print(error)             return {'statusCode': 400 }     # 電話が繋がっていれば終了   elif callFlag == 1:         print("[INFO]受電を確認したため架電を終了")   print(f"[INFO]{context.function_name}を正常に終了")     return {"statusCode": 200}   電話結果確認用Lambda ダイヤル１が押された場合にのみ、Amazon Connectコンタクトフローから呼び出されるLambdaです。 説明用に割愛していますが、通知先や通知時刻等もテーブルに書き込むと、後からログとしても確認がしやすい状態になります。 import json import boto3 import os def lambda_handler(event, context):   print(json.dumps(event))     # 環境変数に電話結果格納用DynamoDBのテーブル名を設定しておき、取得する   table_name = os.environ["contactTable_name"]   dynamodb = boto3.resource("dynamodb")   table = dynamodb.Table(table_name)   try:       # contactidを取得して、電話結果格納用DynamoDBのcall_flagを更新       contactId = event["Details"]["ContactData"]["ContactId"]       response = table.update_item(           Key={               "contact_id": contactId,           },           UpdateExpression="set call_flag=:a",           ExpressionAttributeValues={":a": 1},         )   except Exception as error:       print("[ERROR]コールフラグの変更に失敗")       print(error)         return {"statusCode": 400}     return {"statusCode": 200} Step3.Amazon Connectコンタクトフロー作成 以下、Amazon Connectのインスタンス作成、電話番号の取得は終わっていることを前提とします。 Amazon Connectの初期設定はこちらの記事で解説していますので是非ご参照ください。 Amazon Connectのはじめ方 Amazon Connect を触ってみましたので、今回の記事ではインスタンスの作成方法と電話番号の取得方法、ユーザー作成についての手順をご紹介します。 Amazon Connectを始める皆さんの参考になればと思っています。 blog.usize-tech.com 2022.02.16 それでは適宜、Amazon Connect側の設定が完了している前提で、今回の肝となるAmazon Connectコンタクトフローについて説明します。ここでは以下の流れに沿って、電話をかけるプロセスを作成します。 電話接続（発信）・ログや音声の設定 自動音声にて「アラームが発生しました。対応する場合は、ダイヤル1を押してください」と案内し、相手がダイヤル1を押したかどうかを15秒間チェック ※下記コンタクトフローの赤枠の「顧客の入力を保存する」の部分で定義 ダイヤル1が押された場合は、Step2にて作成した電話結果確認用Lambda関数を呼び出して、「対応を確認しました。」と案内し、通話を終了 ダイヤル1が時間内に押されなかった場合は、「次の人にお繋ぎします。」と案内し、通話を終了 このシンプルな流れによって、確実に対応意思表示のアクションが取られるまでのプロセス自動化が可能となります。   最後に この自動通知の仕組みよって、ちょっとした改善が日々の業務にもたらされました。大幅な変化というわけではありませんが、これまでの手作業による連絡リストの確認や、数回の電話をかける手間が省けたのは大きな進歩です。 USiZE（ユーサイズ）が提供するサービスも、このような小さな工夫を積み重ねて、お客様にとってより使いやすく、信頼性の高いものになるよう日々努力しています。私たちが提供するサービスを通じて、皆様のビジネスもさらにスムーズに、そして快適に進んでいくことを願っています。もし、USiZE（ユーサイズ）についてもっと知りたいと思われたら、ぜひ以下サイトを訪れてみてください。 運用付きの国産クラウドサービス　USiZEシェアードモデル 運用付きの国産クラウドサービス│SCSK株式会社 VMwareベースで構築された、高可用性、高機密を備えた国産のプライベートクラウドです。ファシリティスタンダード最高レベルのティア4に適合する日本国内のデータセンター上で稼働し、お客様データの保護とデータ主権を確保します。 www.scsk.jp SCSKのプライベートクラウド「USiZEシェアードモデル」とは？ SCSKのプライベートクラウド「USiZEシェアードモデル」とは？ SCSKのプライベートクラウド「USiZEシェアードモデル」（ユーサイズシェアードモデル）についてご紹介します。 blog.usize-tech.com 2023.12.19 最後までお読みいただきありがとうございました。 今回の小さな工夫が、皆様の仕事に少しでも役立つことを願っています。それでは、快適なITライフをお過ごしください。

Prisma Cloudは、クラウド環境のセキュリティとコンプライアンスを一元管理するツールで、リアルタイムの脅威検出やリソースの監視が可能です。今回は、実際にAzure環境（サブスクリプション）をPrisma Cloudに接続してみました。 作業する前に まずは接続する前に接続方法や前提条件の確認から行います。 接続パターン Azure環境をPrisma Cloudに接続するには、以下の3つのパターンがあります。 1 Azureテナント サブスクリプションやActive Directoryを含む、すべてのAzureリソースをPrisma Cloudに接続します。 2 Azureサブスクリプション 単一のサブスクリプションのみを接続します。 3 Azure Active Directory IAMモジュールをルートテナントレベルで接続します。 上記の接続パターンは、商用、政府、中国の各Azureクラウドで利用可能です。 接続方法 Prisma CloudにAzure環境を接続するためには、Azure環境側で必要なリソースを作成する必要があります。 以下の方法が利用できます。 1 Terraform（推奨） 自動的にPrisma Cloudアプリケーションをセットアップし、Azureサブスクリプションへのアクセスを許可します。ただし、中国のAzureではTerraformテンプレートはサポートされていません。 2 カスタムロールJSON 手動でカスタムロールを作成し、Prisma Cloudアプリケーションに必要な権限を付与します。 3 手動での承認 Terraformを使用できない場合、必要なリソースを手動で作成してPrisma CloudがAzure APIを呼び出せるようにします。 サブスクリプションの状態と影響 サブスクリプションの状態によって、Prisma Cloudの機能に影響が出ることがあります。たとえば、サブスクリプションが有効な場合は問題なくデータの取り込みや自動修正が可能ですが、削除されたり無効になったりしたサブスクリプションではデータの取り込みができません。 前提条件 Key Vaultとストレージアカウント Prisma CloudがAzure Key Vaultリソースを取り込むためには、特定の権限を設定する必要があります。 Azureポータルでストレージアカウントの設定を行い、「ストレージアカウントキーを許可する」オプションを有効にしてください。 ネットワークセキュリティグループ（NSG）フローログ ・Prisma Cloudがネットワークトラフィックデータを取得するためには、NSGフローログを有効にする必要があります。 必要なロールと権限 Prisma Cloudを接続するためには、基本的なセキュリティ機能だけでなく、より高度なセキュリティ機能にも対応するための適切なロールと権限を持っている必要があります。これには、Reader、Reader and Data Access、Network Contributor、Storage Account Contributor などのロールが含まれます。   接続してみる 前提条件等の確認ができたのでここからは実際に接続してみます。 今回はTerraformを使ってAzureサブスクリプションをPrisma Cloudに接続します。 作業準備 Azure環境とPrisma Cloudの接続作業には、以下の準備が必要です。 サブスクリプションIDおよびテナントIDの情報を用意してください。 Prisma Cloudが作成するアプリケーションをAzure Active Directoryに追加する権限（アカウントオーナーまたはコントリビューター）を持っていることを確認してください。 Azure PortalでCloudShellが使えることを確認してください。 Terraformスクリプトの取得 Prisma Cloudにログインします。 「設定」から「プロバイダ」＞「クラウドアカウント」を選択し、「プロバイダーに接続する」＞「クラウドアカウント」をクリックします。 クラウドプロバイダーで「Azure」を選択します。 「始めましょう」の画面が表示されたら、範囲は「サブスクリプション」、デプロイメントタイプは「商用」を選択します。 今回はCSPM機能だけ利用できればよいので、エージェントレスワークロードスキャンやサーバレス機能スキャン、エージェントベースのワークロード保護はチェックを外して次に進みます 「アカウントの設定」画面が表示されたら、以下を入力します。 ・ディレクトリ（テナント）ID ・アカウント名　※自由に指定できます ・サブスクリプションID ・「修復」機能は利用しないためチェックを外したままにします 上記を入力するとTerraformスクリプトがダウンロードできるようになるので、「Terraformスクリプトのダウンロード」をクリックします。   これでTerraformスクリプトのダウンロードは完了です。 Terraformスクリプトの実行 Terraformスクリプトがダウンロードできたので、次はAzure環境上でTerraformスクリプトを実行します。 Azureポータルにアカウントオーナーまたはコントリビューター権限でログインします。 今回はアカウントオーナー権限でログインしました。 CloudShellのアイコンをクリックしてCLI画面を表示します。ここからはCloudShell上での作業になります。 任意のパスにディレクトリを作成して、先ほどダウンロードしたTerraformスクリプトををアップロードします。 作成したディレクトリに移動します。 以下のコマンドを実行します。 # terraform init 「Terraform has been successfully initialized!」と表示されればOK 以下のコマンドを実行します。 # terraform apply 実行するか確認されるので、「 yes 」と入力します。 「Apply complete!」と表示されたら実行完了です。 Prisma Cloudに接続 Terraformスクリプトを実行して必要なリソースをAzure環境に設定できたので、次はいよいよPrisma Cloudに接続します。 Prisma Cloudにログインします。 Terraformスクリプトの取得でサブスクリプションID等を入力したところまで同じ設定をして進みます。 「アカウントの設定」画面で、「Terraformスクリプトのダウンロード」の下にある項目に情報を入力していきます。 アプリケーション（クライアント）ID Terraformスクリプト実行結果の 「c__application_client_id」の値を入力 アプリケーションクライアントシークレット Terraformスクリプト実行結果の 「d__application_client_secret」の値を入力 エンタープライズアプリケーションオブジェクトID Terraformスクリプト実行結果の「e__enterprise_application_object_id」の値を入力 ネットワークセキュリティグループフローログの取り込みと監視 チェックを入れたまま アカウントグループ 任意のアカウントグループを指定。 今回は事前に作成しておいたAzure環境用のものを指定します 「Next」をクリックして次の画面に進むと接続が始まります。 レビューステータスがすべて成功（緑色）になれば接続OKです！ 「保存して閉じる」をクリックして完了します。 監視設定してみる AzureサブスクリプションをPrisma Cloudに接続できたので、監視設定をしていきます。 アラートルールの設定 セキュリティ的によくないクラウド設定等を検知するため、アラートルールを設定していきます。 Prisma Cloudコンソール画面上部にある「アラート」を選択します。 「アラートルールを表示」を選択し、「アラートルールの追加」をクリックします。 アラートルール名を入力します。 アラート通知を行いたいので、「自動化(オプション)」＞「アラート通知」の項目を有効化して次に進みます。 「ターゲットを割り当て」の画面に進んだら、監視対象のアカウントグループを指定します。 今回は先ほど接続したAzureサブスクリプションで指定したアカウントグループを選択して次に進みます。 「ポリシーを割り当て」の画面に進んだら、監視するポリシーを選択します。 今回は一旦すべてのポリシーで監視してみるので「すべてのポリシーを選択」を有効にして、次に進みます。 「通知を設定」に進んだら、アラートの通知先を選択できます。 今回はメール通知したいので、「電子メール」を選択してメールアドレスを入力し、有効化します。 「概要」画面に進んだら設定した内容を確認し、「保存」します。 これでアラートルールの設定ができました。 アラート通知 アラートルールを設定してしばらくすると、ポリシーに違反したリソースを検知してアラート通知メールが飛んできました。 メール本文には、アラート検知したポリシーおよびアラート数、アラート検知した主なリソース名等が記載されています。 メールに記載されているリンク（「Open」の数のところをクリック）から該当のアラート情報の画面（Prisma Cloudのコンソール画面）にとぶことができました。より詳細なアラートの情報はコンソール画面で確認できるようです。 ↓　リンクをクリックすると… アセット情報 アラートルールによる監視とは別で、Prisma Cloudに接続されたAzureサブスクリプションのアセット情報がPrisma Cloudコンソール上で確認できます。こちらは追加の設定等は不要で、Prisma Cloudと接続できれば表示されてきます。 Prisma Cloudコンソール画面上部にある「インベントリ」＞「アセット」を選択すると確認できます。 検証したPrisma Cloud環境は、Azure以外にもAWSやGCPも接続されています。 「AZURE」をクリックすると各サービスごとに表示されます。さらに選択していくと、Azure環境上に存在しているリソース情報の詳細を表示することができます。 まとめ 今回は、Prisma CloudにAzureサブスクリプション接続してアラート検知するところまで確認できました。 今後も、実用的な情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

SCSKではDropbox管理業務負荷の軽減及びエンドユーザの利便性を向上させるためのDropbox統合管理ツールとして「Smartdbx」を開発いたしました。 こちらの記事では「Smartdbx」についてご紹介いたします。 Dropbox（Business版）の機能と管理者について Smartdbxのご紹介の前にDropboxの機能と管理者に関してです。 DropboxのBusiness（法人）版は個人版Dropboxとは違い、組織（＝チーム）単位で契約を行うため、「テナント」と呼ばれる組織の環境が出来上がります。Dropboxではこのテナントを「チーム」とも呼びます。 テナントは管理者が各種設定を行うことができるため個人向けのDropboxでは実現できない、組織の情報管理を行うことができます。 組織で情報を管理するには、「管理者」は必要です。 ただ、組織の規模が大きくなればなるほど、管理者の手で組織管理を行うことは難しくなる場合があります。社内ルールの策定だけでは、メンバーの方が順守できているとは限りません。 全ての確認と管理を管理者が行うには運用負荷がかかる場合があります。 チームフォルダの作成 「チームフォルダ」とはDropboxの共有用のフォルダの一つで、管理者が作成し、管理者がアクセス権をつけるフォルダです。 この「チームフォルダ」にコンテンツを保存すると、アクセス権のあるメンバー全員と自動的に同期されます。 個人版のDropboxには存在せず、Business版のみの機能で、これがあることでファイルサーバーの代わりとして使用できます。   種類 特徴 用途 個人フォルダ メンバーが作成した共有されていないフォルダ 所有者は、メンバー。 フォルダの所有者のみがアクセス可能。 ファイルサーバーのユーザーフォルダの代わりとなる。 共有フォルダ メンバーが作成し、メンバー間で共有状態のフォルダ 所有者はメンバー。 共有メンバーのみがアクセス可能。 編集可能/閲覧の二種類の権限を設定可能。 共有フォルダ内のサブフォルダでは、独自の共有設定は行えない。 プロジェクトフォルダなど期間限定で共有したい場合に利用。 チームフォルダ システム管理者が作成、管理する特別なフォルダ 所有者はシステム管理者。 編集可能/閲覧のみの二種類の権限を設定可能。 サブフォルダにユーザー、グループを指定して共有メンバーを追加したり、上位のチームフォルダから継承された共有メンバ(アクセス権)から特定のグループやユーザーを削除することが可能。 部署単位でアクセス権を管理した上で情報共有を実施したい場合に利用。 ファイルサーバーの共有フォルダの主な移行先になる。   チームフォルダの作成や管理を管理者が行うと、管理者の作業は増えてしまいます。 また、管理者にフォルダ作成を依頼した際、ユーザーは管理者の作業完了を待つ必要がありました。 アクセス権限設定 Ｄropboxではチーム管理者が行うか、編集権限のあるユーザーが行いますが、会社規模が大きくなると統制がとりづらくなる場合があります。 社外との共有 組織の重要な情報管理のためにユーザーに自由に許可はできないことは多いと思います。ただDropboxでは外部共有先管理は管理者のみが行うため、管理者がすべて監視することが難しいです。   Smartdbxとは？ さて本題ですが、Smartdbxとは何でしょうか？ 冒頭の記載と重なりますが、Smartdbxとは、Dropboxの管理者の業務負荷の軽減やエンドユーザの利便性を向上させるためのツールです。 フォルダ管理については自動化を行い、社外の共有については上長の承認を、アクセス権管理についてもツールを通し一括管理を実現できます。 「Smartdbx」には管理者業務を自動化する事で、管理者業務自体を極力なくし、管理者の運用負荷を軽減させる機能が用意されております。 SmartdbxとDropbox と組み合わせてお使いいただくことでもっと便利に、効率的にDropbox をご利用いただくことができます。 弊社がDropboxの管理ツール開発を始めたのは2017年からになります。 ——————————————————————– 2017年 　ONEUPの開発・運用 Dropboxを導入した時から社内の運用管理の負荷低減、効率アップを目的としたツール（社内呼称：ONEUP）を開発、運用しています。 2022年 　外部共有の管理機能をリリースして機能拡張 2023年 　Smartdbx開発 —————————————————————— ONEUPに更に多くのDropboxプロジェクトで培った知見を取り入れ、多くのお客様からご要望が多い有益な機能をSmartdbxとして実現しました。 ではどんな機能があるのかについてご紹介していきたいと思います。   機能 機能詳細 基本/オプション アカウント/グループ管理機能 •人事マスタ(組織と人)と自動連係 •Dropboxのアカウントおよびグループの連係 •アカウント情報の照会 •グループ情報の照会 基本機能① 共有フォルダ管理 •共有フォルダ管理機能 •共有フォルダ承認ワークフロー •共有フォルダ棚卸機能 サブフォルダ含みの棚卸しのみ、順次リリース(可視化機能として) •共有フォルダアーカイブ機能 (順次リリース) •フォルダテンプレート 基本機能② 社外共有フォルダ監視 個人フォルダや、共有フォルダ申請で申請されたチーム外共有以外の社外共有の監視・ブロック機能 基本機能③ 全社ナレッジ共有 1,000人以上となるような大規模環境での全社共有するフォルダ管理機能 オプション① カスタムドメイン（ファイル送受信） 社外の方とのファイルの受渡をDropboxドメインを使わずに実現する機能 オプション②   機能紹介 今回はSmartdbxの基本機能3つについてご紹介いたします。 基本機能①　アカウント/グループ管理機能 「Smartdbx」の利用アカウントを管理する機能です。 人事マスタから指定のcsvフォーマットで人、組織、役職などの情報を取り込んでDropboxアカウントと連携してDropboxグループの管理も行うことができます。 組織単位のDropboxグループを人事情報と連携することで、自動でグループ内メンバーを変更します。 メンバーも人事情報と連携して、アカウントの発行、削除を行うことができます。 また、組織や役職の情報はSmartdbx内の承認ワークフローにも活用しています。   基本機能②　共有フォルダ管理 社内外との共有フォルダ管理の一元化と効率化を行います。 フォルダ共有 Dropboxの標準機能として用意されている共有方法はいろいろありますがその中に「フォルダ共有」があります。 「フォルダ共有」とは、Dropboxのアカウントを持っているユーザ同士でファイルを共有・編集できる機能です。 業務を行う際に便利な機能で、社外との共同プロジェクトでもよくつかわれます。 共有フォルダ申請 共有するフォルダの種類の中に冒頭で記載した「チームフォルダ」があります。 組織のフォルダ管理においてチームフォルダは重要な役割を果たしますが チームフォルダの作成や管理は管理者が行うため、管理者の作業は増えてしまいます。 また、管理者にフォルダ作成を依頼した際、ユーザーは管理者の作業完了を待つ必要がありました。 そこで、この機能を通して申請を行うことで管理者が作業せずに 自動でチームフォルダの作成・設定・アクセス権管理が行えるようになります。 社外との共有については外部共有先を事前に登録したり、必要に応じて申請時にワークフローを追加することで上長の承認を得ることができるようになります。 また、共有する社外の方（お客様やビジネスパートナー）と共有ルールなどを確認して遵守して頂く為、社外の方を含めた署名を回付する事も可能です。 署名には、Dropbox Signを使用いたします。 社外の方を含めたワークフローを利用する場合は、別途Dropbox Sign APIのご契約（有償）が必要となります。   「社外共有フォルダ申請」ワークフロー 弊社で実際に使用している「社外共有フォルダ申請」のワークフローを一例としてご紹介いたします。 ※上司からの承認＋署名回付を有効に設定 ワークフローは以下切替が可能です。 承認自体の有無 承認者のレベル（承認は課長まで、部長まで、など） 社内社外での切替  署名回付   棚卸し機能 有効期限（申請時に設定した利用終了日）に近づくと申請者にアラートの通知が届き、期限が切れると自動で社外共有が解除される仕様となっています。 利用していないフォルダがずっと社外共有されているのはセキュリティ的に問題です。 ほったらかしを防ぐ機能も備わっています。 現状Smartdbxで設定したフォルダについて管理を行え、細かいアクセス権管理については今後開発予定となっております。 アーカイブ機能 上記棚卸し機能により、共有フォルダ申請で設定した有効期限が過ぎた時、または終了申請がされた際、共有が解除される仕組みになっております。 では利用期間が過ぎた場合、そのフォルダをどうするのか？という問題があります。 そこで、共有を解除したフォルダを即時削除するのではなくDropboxでアーカイブを行います。 アーカイブをした場合、アクセス権はなくなりますが、データとしてはDropboxに保持されていますので、どうしてもデータが再度必要になった際に復元可能になります。 （本機能は順次開発予定となっております。） 基本機能③　社外共有フォルダ監視 組織で情報を扱う中で、社外との共有について、不要な共有がされていないか、正しい相手に共有されているか、人手で監視が難しいという問題があります。 特に個人フォルダと社外との共有を自由に許可してしまうと、セキュリティ対策としては課題に上がることが多いです。 そこで本機能「社外共有フォルダ監視」を活用いただくことで社外との共有は申請されているところだけに限定します。 個人フォルダが社外共有された場合や、未承認の会社との社外共有は、自動で解除され警告メールが発信される仕組みです。 こちらの機能で、外部共有を申請したものに限定することで、安全性を高めています。 これらの機能によって、管理者の運用負荷を軽減させることができるため、より快適な業務をDropbox で実現できます。 「Smartdbx」について詳しくはこちらをご覧ください。 Dropbox： Dropbox ｜ SCSK株式会社 次回は「Smartdbx」のオプション機能についてご紹介します！

2024年1月15日に、DLPの機能強化がアップデート情報としてあがりました。 具体的にはOCR機能が利用できるというものです！ 今回はその新機能を詳しくご紹介します。 OCRとは まず、OCRについてですが、OCRとは「Optical Character Recognition」の略で日本語にすると「光学文字認識」です。 印刷されたテキストや手書きの文字をカメラやスキャナ等の光学的な手段でデータとして取り込み、それを解読（文字認識）することにより、パソコン等のコンピューターが識別できる文字（テキスト）データに変換する技術です。 今回のアップデートは、この技術を利用したもので、 画像ファイル内のテキストをスキャンして分析し、個人情報や機密情報が含まれている場合はそれを保護することができるようになるという機能強化となっています。   条件 2024年1月時点では以下のような条件があります。 ※OCR固有の条件に加え、DLP機能自体の条件も含みます。 ・文字タイプ：アルファベット文字のみ（現時点では日本語が未対応です) ・画像タイプ：png, jpeg, tiff, bmp, pnm, webp, jpeg2000 ・ファイルサイズ ・ テキストファイル：1 KB～20 MB ・ 画像：10 KB～20 MB TLS Inspectionがデフォルトで暗黙的にバイパスされているアプリケーションはサポートされていません。 上記条件を踏まえ、今回は”Confidential”という文字が1つ入ったJPGファイルをGmailに添付させないという動作検証を行ってみました。 実際に試してみた結果を次の項目でご説明します！   設定方法 CMAの設定は、こちらの記事に記載の通りに行っていきます。 CatoクラウドのDLPについて Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます！ blog.usize-tech.com 2023.10.06 Step1 今回は、カスタム定義型で”Confidential”というKeywordを指定し定義型を作成しました。 Thresholdは閾値の設定で、Keyword/Phraseで指定した文字の数量を定義します。 例えば、今回の場合「 ”Confidential” という文字が 1つ 入ったJPGファイルを、Gmailに添付させない」なのでThresholdは【1】となります。 Name：OCR Test “Confidential”　※任意の名前を入力 Description：OCR Test “Confidential”　※任意の説明を入力 Threshold：1 Keyword/Phrase：Confidential Validate Keywordでは、対象のファイルをアップロードすることで、そのファイルが定義した定義型にマッチしているかを事前にテストすることが可能です。 “Confidential”のテキストが入ったJPGファイルをアップロードしてみると、 このように”File matched the data type”とメッセージが表示され、定義型にマッチしていることがわかりました。 試しに、”Confiden s ial”というスペルを一部誤ったテキストが入ったJPGファイルをアップロードしてみると、 ” File didn’t match the data type”とメッセージが表示され、定義型にマッチしないことがわかります。 今回はカスタム定義型で定義型を作成していますが、もちろん事前定義型を利用することも可能です。 事前定義型の場合、ThresholdはCato社で事前に定義付けされており、Data Type Catalogから確認が可能です。 例えば、Confidential document marker[Japan] という定義型にはThresholdが【2】と定義されています。 この場合、Descriptionに記載のインスタンスのうち最低でも2つ含まれていないと、この定義型にマッチしないものと見なされます。   右側の…からValidateに進むと、カスタム定義型と同様に事前にテストが可能ですので事前にテストすることをお勧めします！ Step2 次にProfile作成ですが、 ここで”OCR Scan Enabled”にチェックを入れるだけでOCR機能を有効にできます！ Step3 作成したProfileを使って次にルールを作成していきます。 今回は以下通りの設定を行いました。 Name：DLPテスト Gmail(OCR) User defined　※任意のルール名を入力 Source：Any Application：Gmail Activities：Add Attchment DLP Profiles：Test OCR User define OCR enable　※STEP2で作成したProfileを選択 Actions：Block Tracking：Event 以上でCMA設定が完了しましたので、動作確認を行っていきます。   動作確認 実際にGmailでテストファイルの添付をしてみると・・・ Cato ClientをOFF(Disconnected状態)の場合、テストファイルは添付可能でしたが、 その後、Cato ClientをON(Connected状態)にして再度添付を試してみると、想定通りBlockされました。 さらに、OCRをOFFにしたProfileを作成して同様に試してみると、このようにテストファイルは添付ができました。 よって、きちんとOCR機能が働いていることがわかります。 試しに、ZipファイルやPass付のZipファイル、手書きや写真（粗めに撮影したもの）にて添付を試してみた結果、残念ながら添付ができてしまいました…。 よって、CatoクラウドのOCR機能は、一般的な「OCR」であり、最先端技術である「AI-OCR」ではないようです。 今後の機能拡張により、精度向上を期待したいと思います。   まとめ 今回はDLPの新機能についてご紹介いたしました。 今後も様々な機能強化や新機能のリリースを予定しております！ リリースされたらどう使ったらよいのか…悩まれる方も少なくはないかと思いますので、使用方法や使用感をたくさん発信していきます！

はじめに Prisma Cloud のライセンスの仕様をまとめてみました。 ライセンスの仕様については変更の可能性がありますので、最新のドキュメントは以下を参考にしてください。 Enterprise Edition Compute Edition Prisma Cloud ではライセンスは 100クレジット単位 で販売され、監視および保護するリソース数に応じてクレジット数が算出されます。 Prisma Cloud のライセンス仕様(Enterprise Edition) ※Prisma Cloud 製品ごとに消費するクレジット数が異なります。 Prisma Cloud 製品 消費するクレジット数 可視性 ※1 、コンプライアンス、ガバナンス(脅威検出を含む) ・Amazon EC2 ・Azure VM ・Azure Virtual Machine Scale Sets ・Google Compute Engine ・Alibaba Cloud ECS ・Oracle Cloud Compute 1台 1 クレジット IAM Security 0.25 x 可視性 ※1 、コンプライアンス、ガバナンスのクレジット使用量 データ セキュリティ 消費するクレジット数 ・Amazon S3 ・Azure Blob Storage  露出スキャン ※2 : 200GBあたり1クレジット フルスキャン ※3 : 33GBあたり1クレジット サーバーレス セキュリティ 消費するクレジット数 ・AWS Lambda ・Azure Functions Defender サーバーレス関数 6つにつき 1クレジット Prisma Cloud製品 消費するクレジット数 クラウドディスカバリーとエクスポージャー管理 0.25 x 可視性 ※1 、コンプライアンス、ガバナンスのクレジット使用量 ホスト セキュリティ(Linux, Windows) デプロイされたホスト Defender あたり 0.5クレジット コンテナ セキュリティ(Linux, Windows) デプロイされた Container Defender ごとに 5 クレジット デプロイされたアプリ埋め込み Defender ごとに 1 クレジット Web Application and API Security (WAAS) インラインで展開された Defender ごとに 2 クレジット 帯域外モードで Defender ごとに 2 クレジット Infrastructure as Code (IaC) セキュリティ 開発者 ※4  ごとに 3クレジット ソフトウェア・コンポジション解析(SCA) 開発者 ※4  ごとに 4クレジット シークレット セキュリティ 開発者 ※4  ごとに 1クレジット CI/CD セキュリティ 開発者 ※4  ごとに 3クレジット   ※1 可視性とは：クラウド環境全体の設定ミス、権限、データ、脆弱性の保護 ※2 露出とは：以前に検出された脆弱性が、ネットワーク上の不正な行為者によって利用された場合のインシデント ※3 フルスキャン：エクスポージャースキャン、データ分類、マルウェア分析 ※4 開発者とは：Prisma Cloud で保護しているアクティブなリポジトリに対して、過去90日以内でGitでコントリビュートした人 Prisma Cloud のライセンス仕様(Compute Edition) ※Prisma Cloud の製品ごとに消費するクレジット数が異なります。 Prisma Cloud製品   消費するクレジット数 ホスト セキュリティ(Linux, Windows) デプロイされたホスト Defender ごと 1クレジット コンテナ セキュリティ(Linux, Windows) デプロイされた Container Defender ごとに 7クレジット デプロイされたアプリ埋め込み Defender ごとに 1クレジット Web Application and API Security (WAAS) インライン モードを使用してデプロイされたホスト、コンテナー、またはアプリ埋め込み Defender ごとに 30クレジット アウトオブバンド モードで Defender ごとに 2クレジット サーバーレス セキュリティ   消費するクレジット数 ・AWS Lambda ・Azure Functions Defender サーバーレス関数 6つあたり 1クレジット Prisma Cloud クレジットの購入と使用方法 Prisma Cloud クレジットは、パロアルトネットワークス、パロアルトネットワークスのチャネルパートナー、およびさまざまなマーケットプレイス(AWS Marketplaceなど)から購入できます。 購入した Prisma Cloud クレジットがアカウントに追加されると、Prisma Cloud コンソール内から Prisma Cloud 製品モジュールを有効にできます。 Prisma Cloud クレジット使用量の測定方法 クレジット使用量は 1時間 ごとに測定されます(データセキュリティを除く※ Enterprise Edition のみ)。 その後、日次、週次、月次、四半期ごとの平均値にまとめて報告されます。 これにより、短期間の利用増加による超過を防ぎます。 Prisma Cloud の全モジュールにわたって、購入したクレジットを超えて使用した場合、カスタマーサクセスチームが追加のクレジット購入をサポートします。 おわりに 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。