こんにちは、SCSK齋藤です。 2025年の11月に AWS CloudFormation に関するアップデートが来ました。その内容について検証してみたいと思います。   ドリフト対応変更セット アップデートは、ドリフト対応変更セットというもので、これはテンプレートの内容と実際のインフラの状況を比較した上で、変更セットを立てるという内容です。 AWS CloudFormation のドリフト対応変更セットで設定のドリフトを安全に処理 - AWS AWS の新機能についてさらに詳しく知るには、 AWS CloudFormation のドリフト対応変更セットで設定のドリフトを安全に処理 aws.amazon.com 図解すると下記のようなイメージです。   これまでの変更セットは、現在のテンプレートと、新しいテンプレートを比較して差分を抽出します。 しかし、ドリフト対応変更セットは、それに加えて実際のインフラの状況も見た上で変更差分を抽出します。   試してみた 今回はLambda関数を定義したCloudFormationを使って、ドリフト対応変更セットとはどのようなものなのかみていきたいと思います。 ①Python3.11のランタイムのLambdaをデプロイ 下記テンプレートをまずデプロイしてみます。 AWSTemplateFormatVersion: '2010-09-09' Description: Simple CloudFormation Template to create one AWS Lambda function Resources: testlambda: Type: AWS::Lambda::Function Properties: FunctionName: "test-lambda" Handler: index.lambda_handler Runtime: python3.13 Architectures: - arm64 Role: !GetAttLambdaRole.Arn Code: ZipFile: | def lambda_handler(event, context): return { 'statusCode': 200, 'body': 'Hello from Lambda!' } LambdaRole: Type: "AWS::IAM::Role" Properties: RoleName: "my-function-role" AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Principal: Service: "lambda.amazonaws.com" Action: "sts:AssumeRole" Policies: - PolicyName: "MyPolicy" PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - logs:CreateLogGroup Resource: arn:aws:logs:ap-northeast-1:425086073817:* - Effect: Allow Action: - logs:CreateLogStream - logs:PutLogEvents Resource: - arn:aws:logs:ap-northeast-1:425086073817:log-group:/aws/lambda/test-lambda:* 上記をデプロイすることにより、Lambdaのランタイムは、3.11となります。   ②マネジメントコンソールで、Python3.12にランタイムを変更します。 CloudFormationを用いずに、ランタイムを変更します。 この状態では、CloudFormation上はまだPython3.11のままです。 ③CloudFormationを用いて、Python3.13にアップデートします。 ここからが本題です。 本ブログの①に記載したCloudFormationテンプレートをPython3.13に書き換えた上で実行します。   まず普通に変更セットを作成しようとします。 最初に、変更セットのタイプを指定しますが、そこでドリフト認識変更セットを選択します。 そして、新しいテンプレートをアップロードします。 この後の流れは、いつもの変更セット作成方法と同じため、変更セットの作成まで実施します。     変更セットを作成すると、下記のようなステータスとなり、「ドリフト済み」と表示されます。   JSONでも見てみますと、下記のようになります。（必要な部分のみピックアップしてます。） beforeValueは、マネジメントコンソール上で変更した実際のインフラのランタイム設定ですね。afterValueは、新しいテンプレートのランタイムです。 その後にdriftと記載があり、previousValueは現在のテンプレート上のランタイムであるPython3.11です。 actualValueは、マネジメントコンソール上で変更した実際のインフラのランタイム設定であることがわかります。 この状態で変更セットを実行したら問題なくPython3.13にアップデートできました。   まとめ 今回はインフラの実際の状態を変更セットとして差分確認する機能を、簡単にですが検証しました。 JSON形式で見てみると、現在のテンプレートと、実際のインフラ、そして新しいテンプレートの内容が３つ分しっかりと比較できていることがわかりました。 この機能により、過去にマネジメントコンソール上で変更してしまった設定も、変更セット時にしっかりと気づくことができるようになったので、想定外のデプロイが起こってしまうといったことが少しでも減らせると考えております。

こんにちはSCSK齋藤です。 今回は Amazon API Gateway の認証方法として、IAMを用いる方法を解説したいと思います。   概要 アーキテクチャ図は下に示す通りです。今回はAPI Gatewayの裏にLambdaを設けて、API呼び出しでLambdaが動くようにします。 なお、IAM認証の処理の流れは下記の通りとなります。 ①APIの呼び出し元がAPIの呼び出しを行う。 ②APIの呼び出し元に付与されているIAM Roleに対象API Gatewayを呼び出す権限があれば、APIを呼び出すことができる。     各リソースの作成 アーキテクチャ図を実現する、各リソースの作成をマネジメントコンソールベースで説明します。 Lambda 今回のAPI Gatewayの裏側にあるLambdaは、特に凝ったものにする必要がないので、デフォルトのソースコードそのままとします。 単純にステータスコード200と「Hello from Lambda!」と出力されるだけのシンプルなプログラムです。   API Gateway 最初は通常通りの作成を行います。   メソッドの作成も行います。今回は呼び出しができれば良いのでGetにし、先ほど作成したLambda関数を設定します。 作成後、認証設定を付与します。 まず、メソッドリクエストの編集ボタンを押下します。   認可の部分で、AWS IAMをクリックして、保存します。 APIの画面に戻るので、画面右上の「APIのデプロイ」をクリックします。 下記のような設定とし、デプロイをクリックします。   これにてAPI側の構築は完了です。 続いて、APIを呼び出す側のリソースを作成していきます。 今回は、呼び出し元はLambda関数を使いたいと思います。また、それに付与するIAM Roleも作成したいと思います。   Lambda（APIを呼び出す側） 今回は下記名前のLambdaを作成しました。Lambda関数の作成方法は、前述したものを同じなので省略します。 ここではソースコードを紹介します。 import boto3 import json import os from botocore.awsrequest import AWSRequest from botocore.auth import SigV4Auth from botocore.endpoint import URLLib3Session from botocore.credentials import Credentials import requests def lambda_handler(event, context): api_url = "https://XXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/dev" #①Lambdaに付与されたIAMロールをもとに、クレデンシャル情報を取得。 lambda_credentials = boto3.Session().get_credentials() credentials = Credentials(lambda_credentials.access_key, lambda_credentials.secret_key, token=lambda_credentials.token) #②安全にアクセスするために、AWS Signature Version 4に基づいたヘッダー情報を生成する。 request = AWSRequest(method="GET", url=api_url) SigV4Auth(credentials, "execute-api", "ap-northeast-1").add_auth(request) headers = { "Authorization": request.headers["Authorization"], "X-Amz-Date":request.context["timestamp"], "X-Amz-Security-Token": lambda_credentials.token } #③ヘッダー情報を付加してAPIへアクセスする。 api_response = requests.get(api_url, headers=headers) api_response_json=api_response.json() print(f'api_response is {api_response_json}')   ソースコードの中にコメントアウトしておりますが、流れを解説すると3点に分けられます。 ①Lambdaに付与されたIAMロールをもとに、クレデンシャル情報を取得。 boto3のライブラリを用いて、Lambdaのクレデンシャル情報を取得する処理を行います。   ②安全にアクセスするために、AWS Signature Version 4に基づいたヘッダー情報を生成する。 AWSへのアクセスへは安全である必要があります。 今回はSigV4Authというライブラリを用いて、先ほど取得したクレデンシャルをベースにヘッダー情報を生成します。   ③ヘッダー情報を付加してAPIへアクセスする。 ヘッダー情報を付加し、アクセスしたいAPIのURLへアクセスを行います。   IAM Role 呼び出し側LambdaのIAM Roleを編集し、APIGatewayを呼び出すための権限を付与します。 Lambdaの「設定」→「アクセス権限」からロール名をクリックします。 遷移したら、IAMRoleの画面が出るので、「アクセス許可を追加」→「インラインポリシーを作成」をクリックします。 ポリシーエディタで下記の条件で作成しました。 JSON形式にすると下記の通りです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "execute-api:Invoke", "Resource": "*" } ] }   挙動確認 これまでで準備は完了となります。 では、実際にLambdaのテストとして動作確認をしてみますと、ログ出力のところでAPIの裏側のLambdaとして実装したステータスコード200と「Hello from Lambda!」が出力されていることがわかります。 まとめ 今回はAPI GatewayのIAM認証を呼び出す方法について記載いたしました。 なお、補足ですが今回呼び出し側のLambdaにて、ライブラリにSigV4Authというものを利用しました。 これとは別にAWS4Authというライブラリもあり、こちらを使ってもアクセスは可能となります。 しかし、AWS4Authは2024年7月22日を最後にメンテナンスがされておらず、Python3.13以降には対応しておりません。 requests-aws4auth AWS4 authentication for Requests pypi.org   SigV4Authは、botocoreに内包されているため、Python3.13以降にも対応しております。そのため、今後のことを考えるとSigV4Authを利用することを推奨いたします。 botocore Low-level, data-driven core of boto 3. pypi.org

こんにちはSCSK齋藤です。 今回は Amazon API Gateway の認証方法として、Lambda カスタムオーソライザーを用いる方法を解説したいと思います。   概要 アーキテクチャ図は下に示す通りです。今回はAPI Gatewayの裏にLambdaを設けて、API呼び出しでLambdaが動くようにします。 なお、Lambdaカスタムオーソライザー認証の処理の流れは下記の通りとなります。 ①APIの呼び出し元がAPIの呼び出しを行う。 ②APIの呼び出し元に付与されているヘッダー情報を、Lambdaカスタムオーソライザーが認証する。 ③認証が通れば、APIを呼び出すことができる。   各リソースの作成 アーキテクチャ図を実現する、各リソースの作成をマネジメントコンソールベースで説明します。 Lambda（カスタムオーソライザー） 認証用のLambdaを作成いたします。 まず最初は通常通りLambdaを作成します。 さて、次はソースコードが重要となります。 カスタムオーソライザーのソースコードは、利用者にて自由に定義ができます。 今回は下記のようなソースコードとしました。 import json def lambda_handler(event, context): json_event = json.dumps(event) print(f"event: {json_event}") # リクエストからトークンを取得 token = event['authorizationToken'] #　判定結果の変数。リクエストされたトークンが一致していたら許可とする。初期値は拒否とする。 effect = 'Deny' # tokenを検証。指定の値であれば許可する。戻り値にはAPIを実行するIAMポリシーをJSON形式で渡してあげる if token == 'AccessToken': effect = 'Allow' return { 'principalId': '*', 'policyDocument': { 'Version': '2012-10-17', 'Statement': [ { 'Action': 'execute-api:Invoke', 'Effect': effect, 'Resource': event['methodArn'] } ] } }   ポイントとしては、アクセス許可を付与する際はIAMポリシーを返却することです。 このIAMポリシーにAPIGatewayの実行許可を付与することで、APIを実行することができます。   Lambda（APIに呼び出される側） 今回のAPIGatewayの裏側にあるLambdaは、特に凝ったものにする必要がないので、デフォルトのソースコードそのままとします。 単純にステータスコード200と「Hello from Lambda!」と出力されるだけのシンプルなプログラムです。   API Gateway 最初は通常通りの作成を行います。 メソッドの作成も行います。今回は呼び出しができれば良いのでGetにし、先ほど作成したAPIに呼び出される側のLambda関数を設定します。 作成後、認証設定を付与します。 まず最初に、API Gatewayの画面の左ベインからオーソライザーを選択し、オーソライザーを作成をクリックします。 オーソライザーを設定しますが、今回はLambdaを選択し、オーソライザー用のLambdaを選択します。 今回は、トークンをイベントペイロードとしますので、トークンのソースの部分を一般的な「Authorization」として、作成します。 その後、APIにオーソライザーを紐付けます。 APIのリソースの画面に戻り、メソッドリクエストの編集ボタンを押下します。   認可の部分で、先ほど作成したオーソライザーを選択します。 メソッドリクエストの認可にオーソライザーが付与されているのを確認したら、画面右上の「APIのデプロイ」をクリックします。   下記のような設定とし、デプロイをクリックします。   これにてAPI側の構築は完了です。 続いて、APIを呼び出す側のリソースを作成していきます。 今回は、呼び出し元はLambda関数を使いたいと思います。 Lambda（APIを呼び出す側） 今回は下記名前のLambdaを作成しました。Lambda関数の作成方法は、前述したものと同じなので省略します。 ここではソースコードを紹介します。 import requests def lambda_handler(event, context): api_url = "https://XXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/dev" #①ヘッダー情報を生成する。 headers = { "Authorization": "AccessToken", } #②ヘッダー情報を付加してAPIへアクセスする。 api_response = requests.get(api_url, headers=headers) api_response_json=api_response.json() print(f'api_response is {api_response_json}') ソースコードの中にコメントアウトしておりますが、流れを解説すると2点に分けられます。 ①ヘッダー情報を生成する。 今回はトークンのソースをAuthorizationとしましたので、Authorizationヘッダーを作成する必要があります。 Authorizationヘッダーの中身については、Lambdaのカスタムオーソライザーのソースコードで定義した「AccessToken」と同じ値を入れることで認証されるのでその値を設定します。 ②ヘッダー情報を付加してAPIへアクセスする。 ヘッダー情報を付加し、アクセスしたいAPIのURLへアクセスを行います。   挙動確認 これまでで準備は完了となります。 では、実際にLambdaのテストとして動作確認をしてみますと、ログ出力のところでAPIの裏側のLambdaとして実装したステータスコード200と「Hello from Lambda!」が出力されていることがわかります。   まとめ 今回は API Gateway のLambdaカスタムオーソライザー認証を呼び出す方法について記載いたしました。 Lambdaによって認証されるので、かなり自由度は高いと思います。 認証の部分は今回「AccessToken」という単語でハードコードしましたが、裏側にデータベースなどを実装し、リクエストされた値をもとにデータベースを照合して認証するなどするのが良いと考えております。 そちらについてはまた次回以降ブログにできたら良いと考えております。

こんにちは、SCSK齋藤です。 前回に引き続き、Amazon API Gateway の認証方式である、Amazon Cognito を用いたM2M認証の方法について解説いたします。 まだ未読の方は下記の前半のブログを一読してください。   今回は、プログラム側でAPIを呼び出す後半のブログとなります。   おさらい 前回のブログの概要として記載したアーキテクチャ図と処理の流れを再掲します。すでに理解している人は読み飛ばしてください。   M2M認証の処理の流れは下記の通りとなります。 ①APIの呼び出し元がCognitoにアクセストークンを発行しに行く。 ②受け取ったアクセストークンを、ヘッダーに付与してAPIGatewayへアクセスしに行く。 ③リクエストを受けたAPIGatewayは、リクエストに付加されたアクセストークンを検証するため、Cognitoに問い合わせをする。 ④アクセストークン検証の結果、問題なければ後続の処理を進める。（Lambdaの呼び出し。）   API呼び出し方法について 今回は、APIを呼び出すためのLambdaを作成し、そのLambda上でM2Mの認証とAPIの呼び出しを行いたいと思います。   ソースコードは下記のようなイメージです。 import requests def lambda_handler(event, context): #①Cognitoのアクセストークンを取得。 response = requests.post( 'https://ap-northeast-1yfo6hsrgq.auth.ap-northeast-1.amazoncognito.com/oauth2/token', data="grant_type=client_credentials&client_id=141ko0tsl9qpba05m4p19179m2&client_secret=76s7lr40s7jf96egk05i5snunn9v2l45icscj4hpj6a4ucf5abc&scope=default-m2m-resource-server-3dapgs/read", headers={'Content-Type': 'application/x-www-form-urlencoded'} ) cognito_response=response.json() access_token=cognito_response["access_token"] #②ヘッダーにアクセストークンを付与し、APIGatewayへアクセスするリクエストを送付。 api_response = requests.get( 'https://pqopqj9g2b.execute-api.ap-northeast-1.amazonaws.com/dev/', headers={'Authorization': access_token} ) api_response_json=api_response.json() print(f'api_response is {api_response_json}')   ソースコードの中にコメントアウトしておりますが、流れを解説すると２点に分けられます。 ①Cognitoのアクセストークンを取得。 Cognitoへアクセストークンを取得するためのURL、送付するデータ形式、ヘッダーが下記の通り決まっております。そのため、その通りにPostリクエストを送付するだけです。 URL：’https://{Cognitoのドメイン名}.auth.{リージョン名}.amazoncognito.com/oauth2/token’ 送付するデータ形式：”grant_type=client_credentials&client_id={CognitoユーザープールクライアントID}&client_secret={Cognitoユーザープールクライアンドシークレット}&scope={Cognitoリソースサーバー識別子}/{Cognitoリソースサーバーカスタムスコープ}” ヘッダー：{‘Content-Type’: ‘application/x-www-form-urlencoded’}   特にヘッダーは、下記ドキュメントに記載の通り、他のContent-Typeの指定ができないため、注意してください。 スコープ、M2M、リソースサーバー - Amazon Cognito ユーザー属性へのアクセスを許可し、Amazon Cognito ユーザープールによる API アクセス用にリソースサーバーを設定します。 docs.aws.amazon.com   ②ヘッダーにアクセストークンを付与し、APIGatewayへアクセスするリクエストを送付。 API GatewayのURLへアクセスをしますが、肝心なのがヘッダーです。 事前に取得した情報をもとに、ヘッダーを設定します。 前半のブログで、APIGatewayのオーソライザー設定時に「Authorization」をトークンのソースとして設定したので、これをヘッダーとして設定する必要があります。 例：headers={‘Authorization’: access_token}   挙動確認 では、実際にLambdaのテストとして動作確認をしてみますと、ログ出力のところでAPIの裏側のLambdaとして実装したステータスコード200と「Hello from Lambda!」が出力されていることがわかります。   まとめ 今回はAPIGatewayのM2M認証を呼び出す方法について記載いたしました。 前半の記事と合わせて、M2M認証の理解の助けになればと思います。

こんにちは、SCSK齋藤です。 今回は、Amazon API Gateway の認証方式である、Amazon Cognito を用いたM2M認証の方法について解説いたします。 本ブログは、APIを構築する前半と、プログラム側でAPIを呼び出す後半部分の２つに分けてブログを執筆します。 今回は、APIを構築する前半のブログとなります。   概要 アーキテクチャ図は下に示す通りです。今回はAPI Gatewayの裏にLambdaを設けて、API呼び出しでLambdaが動くようにします。 なお、M2M認証の処理の流れは下記の通りとなります。 ①APIの呼び出し元がCognitoにアクセストークンを発行しに行く。 ②受け取ったアクセストークンを、ヘッダーに付与してAPIGatewayへアクセスしに行く。 ③リクエストを受けたAPIGatewayは、リクエストに付加されたアクセストークンを検証するため、Cognitoに問い合わせをする。 ④アクセストークン検証の結果、問題なければ後続の処理を進める。（Lambdaの呼び出し。）   各リソースの作成 アーキテクチャ図を実現する、各リソースの作成をマネジメントコンソールベースで説明します。 なお、主にM2M認証の部分に焦点を置くため、あまり重要でない設定の作成過程は解説をスキップさせていただきます。 AWS Cognito Cognito関連のリソースは作成されるものが多く、下記４つとなります。 ユーザープール アプリケーションクライアント ドメイン リソースサーバー マネジメントコンソールで作成すると芋蔓式で複数のリソースが同時作成されますが、本ブログでは一つ一つどのようなリソースが作成されているかみていきたいと思います。 ユーザープール Cognitoのユーザープールの作成を行います。 ユーザープール画面にて、「ユーザープールを作成」をクリックします。   作成するユーザープールの種類を選択できるため、「Machine to Machineアプリケーション」を選択し、任意の名前を入力します。 その後、「ユーザーディレクトリを作成する」をクリックして、作成します。   作成後、ユーザープール一覧画面に遷移すると、作成したユーザープールが表示されます。 ユーザープール名をクリックします。 そうすると、概要が表示されます。 ユーザープール名が分かりづらいので、「名前の変更」をクリックして、好きな名前に編集します。   アプリケーションクライアント Cognitoの左ベインのところから、「アプリケーションクライアント」をクリックすると、最初にユーザープールを作成した時のアプリケーション名が存在します。それをクリックすると、アプリケーションクライアントの概要が表示されます。 マネジメントコンソールの場合、自動で作成されますので、明示的な作成が不要ですが、これらのクライアントIDやクライアントシークレットは呼び出す際に必要となります。   ドメイン 次にドメインについて見ていきましょう。 同じくCognitoの左ベインから、ドメインをクリックすると、作成されたドメイン情報が閲覧できます。 ここに記載されている、ドメインURLに対して、アクセストークンを発行しに行くことになります。 また、リソースサーバーというものも存在しています。 こちらについても、編集ボタンを押下して、内容を見ていきましょう。   リソースサーバー リソースサーバーの中には、重要なものが２つあります。 ・リソースサーバー識別子 ・スコープ名 どちらもすでに作成済みですが、これら２つの項目を合わせて、アクセストークン取得の際に必要となります。   Lambda 今回のAPIGatewayの裏側にあるLambdaは、特に凝ったものにする必要がないので、デフォルトのソースコードそのままとします。 単純にステータスコード200と「Hello from Lambda!」と出力されるだけのシンプルなプログラムです。   API Gateway これまで作ったリソースを、API Gatewayに統合していきます。 まず、RESTAPIを作成し、LambdaをGetで呼び出すようにします。（作成の過程は省略します。）   本題はここからです。認証にCognitoのM2Mを使います。 作成したAPIの画面の左ベインで、オーソライザーをクリックし、その後表示される画面でオーソライザーを作成をクリックします。 任意のオーソライザー名を設定します。 オーソライザーのタイプは、Cognitoを設定し、ユーザープールの選択画面で先ほど作成したユーザープールを選択します。 トークンのソースには、下記ドキュメントの内容を参考に「Authorization」というヘッダー名を入力します。 REST API と Amazon Cognito ユーザープールを統合する - Amazon API Gateway REST API と Amazon Cognito ユーザープールを統合する方法について説明します。 docs.aws.amazon.com そうすると、オーソライザーが作成されます。 最後に作成したオーソライザーを、APIに関連づけます。 まず、紐付けるAPIの左ベインのリソースをクリックし、その中からメソッド（今回はGET）の中のメソッドリクエストを選択し、設定の編集ボタンをクリックします。 認可の部分に、作成したオーソライザーを選択します。 そして認可スコープに、Cognitoのリソースサーバーで設定したリソースサーバー識別子とカスタムスコープ名を/で連結したものを入力します。 設定後、下の画面に戻るので、APIをデプロイします。 任意のデプロイステージ名を入力して、デプロイします。   まとめ 今回はAPIを認証部分含めて構築しながら解説しました。 後半となる別のブログでは、そのAPIを呼び出すプログラムの書き方について解説していきたいと思います。

カレーか、ラーメンか。それが問題だ。 こんにちは、佐藤です。 皆さんは、お昼ごはんのメニューが決まらずに貴重な昼休みを浪費してしまった経験はありませんか？ 気づけば時計の針は12:15を回り、店選びの選択肢がどんどん狭まっていく絶望感…。 正直なところ、私自身何度もそんな経験があります。 はじめに 15分の使い方が人生（と仕事）を変える？ そんな私ですが、先日Yahoo!ニュースでこんな興味深い記事を見かけました。 週明け15分の「デジタル断捨離」が、仕事のパフォーマンスを劇的に変える理由 （中略…記事の要約）…週明けのたった15分を使ってデスクトップのファイル整理やスマホのアプリ整理（デジタル断捨離）をするだけで、デジタルのノイズが減り、その後の生産性が劇的に向上するとのこと。 出典： Yahoo!ニュース（2026年1月11日配信） …待ってください。 記事によれば「たった15分」で仕事の生産性を劇的に向上させららしい。 それなのに私はその貴重な15分を「今日、麺にするか米にするか」という悩みだけで溶かしている。 そんなの許されるわけがありません。 ランチの決定ごときに時間をかけてはいけない、0秒で決めるべきです。 普段Javaなどを扱っているエンジニアなら math.random() を使おうとか思いつくかもしれません。 しかし PC内部の時計に依存した「疑似乱数」で、私の大切な胃袋の運命を決定していいはずがありません。 「真のランダムに、私の胃袋を委ねたい。」 そう決意した私は、とりあえずAWSを開きました(?) ということで今回は、 量子コンピュータを手軽に使えるサービス「Amazon Braket」を使って、 量子力学の「重ね合わせ」を利用し、今日のランチを文字通り一瞬で決定してみようと思います。 シュレディンガーのカレーとは？ 皆さんは 「シュレディンガーの猫」 をご存知でしょうか？ オーストリアの物理学者エルヴィン・シュレディンガーが提唱した思考実験で、 箱の中の猫が「生きている状態」と「死んでいる状態」が観測されるまで同時に存在するという、 量子力学の奇妙な性質（重ね合わせ）を表したものです。 コイントスなどを想像するとわかりやすいかと思います。 投げられたコインをハイスピードカメラで捉えると、きっと表か裏か、どちらかを向いていると思います。 ですが我々の目では、回っているコインの表裏を判別することができません。 その瞬間を、量子力学では「 表と裏が混ざり合っている『重ね合わせ』の状態 」と考えるのです。 ならば、 私のランチも量子力学の重ね合わせに委ねてみてはいかがでしょうか。 状態 |0>  ： カレー 状態 |1> ： ラーメン この2つの状態が、観測されるその瞬間まで同時に存在している。 要するに「店に入って券売機を見るまで、私のランチはカレーでもありラーメンでもある！」 という、優柔不断な状態を物理学的に正当化してみただけですね。 私のランチは、カレーでもありラーメンでもある。 これこそが「 シュレディンガーのカレー 」です（ここまで理解できましたか…？）   やってみた BedrockではなくあえてBraketを使ってみる さて、さっそくAWSで量子コンピューティングを始めてみましょう。 こういう話題はもっぱらAmazon Bedrockが話題ですが、今回使用するのは Amazon Braket です。 Braketとは、量子コンピューティングの調査、評価、実験のためのフルマネージドサービスです。 マネジメントコンソールから「Amazon Braket」を検索し、有効化していきます。 ちなみにリージョンは安定のバージニア北部（us-east-1）で。 案内に従ってノートブックインスタンスを作成し、JupyterLabを起動すれば準備はOK。 Notebookのconda_braketを選択すればOK。 ここまでの所要時間は数分。デジタル断捨離よりも早いです。。。 量子回路でランチを設計する…？ 今回の検証で最も大切な部分、コードの実装です。 Jupyter Notebook上で、以下のようなロジックを組みました。 重ね合わせで「２つのメニューが混ざり合っている」状態へ まず、量子回路（Circuit）を作成し、1量子ビットを用意します。 ここに「 アダマールゲート（H） 」という操作を加えます。これが魔法のゲートです。 「0」という確定した状態をこのゲートに通すと、 量子の世界特有の 「0と1が半々で重なり合った状態 に変化します。 先ほどの例で言うところのコインを投げる行為に等しいと言えます。 # 量子回路の作成 circuit = Circuit().h( 0 ) このたった1行で、量子ビットは「0」と「1」の重ね合わせ状態になります。 つまり、 カレー（0）とラーメン（1）が50:50の確率で重なり合っている状態 を作り出すのです。 量子回路図で見るとこんな感じ。 シンプルですが、この中に宇宙の真理が詰まっています。 いざ、実機（IonQ）で運命の観測！ ここでシミュレーター（ LocalSimulator ）を使えば、コストもかからず一瞬で結果が出ます。 しかし、それでは面白くありません。いえ、それでは「真のランダム」とは言えません。 自然界の真理に委ねるため、今回は妥協なく 実際の量子コンピュータ（QPU） を使用します。 デバイスには、イオントラップ方式の量子コンピュータ 「IonQ Forte-1」 を指定しました。 # 実機(IonQ)を使う場合 (有料かつ待ち時間あり) device = AwsDevice( "arn:aws:braket:us-east-1::device/qpu/ionq/Forte-1" ) タスクのショット数（試行回数）を100回に設定し、いざ実行！ 「これで今日のランチ迷子とはおさらばだ！」と意気込んで実行ボタンを押しました。 print( "量子コンピュータ（またはシミュレータ）で測定中..." ) ※実機の場合、世界中の研究者からのジョブで順番待ちが発生するため、完了するまで待機する必要があります。 観測結果はいかに 待つこと… 1時間 。 ようやくIonQから観測結果が返ってきました。 私の胃袋の重ね合わせが収束した瞬間です。 結果はこちら↓ カレー ( 0 ) : 48回 ラーメン ( 1 ) : 52回 僅差ですが、「1」の勝利！ ということで量子コンピュータは私にラーメンを食べるよう啓示を授けました。。。 デジタル断捨離4回分の代償は大きかった… 無事にランチが決まってよかった！ …と、素直に喜べる状況ではありません。２つの悲惨な代償が襲いかかってきます。 まず、 金銭的コスト 。 今回の「IonQ」実機利用（100ショット）にかかった費用は… 30ドル（約4,732円） ランチ代より高くないですか！？ラーメン4杯分です。 そして何より、 時間的コスト 。 実行から結果が返ってくるまでの待ち時間、 60分 冒頭のニュースを思い出してください。 「15分のデジタル断捨離で、仕事のパフォーマンスは劇的に変わる」 私は、その 4倍 にあたる60分を、ただ「ラーメンを食べる」という決断のためだけに費やしました。 しかも、結果が出た頃には 昼休憩が終了 しているという失態ぶり…   まとめ 今回はAmazon BraketのIonQを使って、今日のランチを量子力学的に決定してみました。 結果として、厳正なる宇宙の法則によってランチメニューは決定されましたが、 「ランチを食べる時間」そのものがなくなり、結局パンを齧るのでした… 学び ・量子コンピュータは、ランチ決めにはまだ早すぎる。 ・実機（QPU）を使うと、お財布と時間に大ダメージを受ける可能性がある。 ・15分あるなら、量子計算を待つのではなく、デスクトップのファイルを整理すべき。 それでも軽い気持ちで量子コンピュータを試してみたい！ そんな方はぜひシミュレーターを使って気軽に量子コンピュータを試してみてください！ 私のような物好きはせめて時間に余裕がある休日に行うことを強くおすすめします！ ぜひ、皆さんも お財布に気をつけて 楽しんでみてください！

こんにちは SCSKの庄司です。 先日ServiceNow環境で発生した「スクリプトを含むフローアクションが突然動作しなくなる」という事象について、注意喚起を込めて紹介します。 本記事は執筆時点（2026年1月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。 発生した事象 これまでずっと安定して動作していたフローアクションが、突然正常に動作しなくなりました。 具体的には、以下のようなスクリプトで要求アイテム（RITM）の情報を取得し、カタログタスクを作成する処理を行っていました。 問題が発生したスクリプト（抜粋）： var reqItemGR = new GlideRecord("sc_req_item"); reqItemGR.get(inputs.request_item); var reqItemId = reqItemGR.getValue("sys_id"); var requestId = reqItemGR.getValue("request"); var catalogItemId = reqItemGR.getValue("cat_item"); var requestor = reqItemGR.getValue("requested_for"); 二行目に記載のreqItemGR.get(inputs.request_item) が失敗するようになっており、sysIDが空のまま処理が続行されました。 その結果、「どの要求アイテムにも紐づかないカタログタスク」が作成され、要求アイテムとしてはカタログタスクが作成されなかったためそのままフローが終了してしまうという実務上のトラブルが発生しました。 該当のフローアクションは1年以上更新しておらず、フローやカタログアイテム側にも直近の変更はありませんでした。 直近の改修がないにもかかわらず挙動が変わったため、原因特定にそれなりに時間を要することとなりました。   対応策 修正として、get() メソッドの引数に渡す値を、明示的に sys_id の文字列として取得するように変更したところ、正常に動作するようになりました。 修正後のスクリプト（抜粋）： var reqItemGR = new GlideRecord("sc_req_item"); reqItemGR.get(inputs.request_item.getValue("sys_id")); var reqItemId = reqItemGR.getValue("sys_id"); var requestId = reqItemGR.getValue("request"); var catalogItemId = reqItemGR.getValue("cat_item"); var requestor = reqItemGR.getValue("requested_for");   考えられる原因 前述した通り直近で変更はなかったにもかかわらずなぜこのような事態が発生したのか、調査の結果、事象発生の直前にYokohama Patch 10 Hotfix 1が適用されていたことが判明しました。 これまで inputs.request_item（参照型オブジェクト）をそのままget()に渡しても、プラットフォーム側でよしなにsysIDとして解釈してくれていたものが、Hotfix適用後の内部的な変更もしくは不具合により、「明示的な sys_id の指定」が必要になった可能性が高いと考えています。 本事象とYokohama Patch 10 Hotfix 1との関連性については、現在Now Supportに確認中です。 何かわかりましたら随時アップデートいたします。

こんにちは。廣木です。 Catoクラウドをご利用のお客様はすでにご存知の通りですが、2025年8月6日より、Catoクラウドでは XDR Security Core（無償版）とXDR Security Pro（有償版）が統合され、新しいセキュリティオプション「XOps」へ移行されました。 この変更に伴い、以下の UIで実装されていた機能は有償化され、XOPsをご契約されていない場合は利用不可となっております。 「XOps」へ移行 により有償化した機能 [Home] ＞ [Stories Overview] [Home] ＞ [Stories Workbench] [Home] ＞ [Detection & Response Policy 特に、「SocketのLAN Portダウン時の通知」はこれまでDetection & Response Policy でのみ実装されていた機能であったことから、XOPsをご契約されていない場合は利用不可となりました。 弊社では、本件による影響を最小限に抑える目的で、XOps の提供期間を半年間延長し、 【2026年2月6日】 まで LAN Port ダウン通知機能をご利用いただけるよう対応しております。 一方で、先日 Link Health Rule の機能拡張が行われ、Socket の LAN Port ダウン時の通知を同機能にて実装できるようになりました。 本記事では、Link Health Rule によるLAN Port Disconnect 通知機能の設定方法ついてご紹介します。 Link Health Ruleとは？ そもそもCatoのLink Health Ruleとは、Connectivity「接続性」やQuality「品質」の監視を行い、ルールに従って通知を行う機能です。 Link Health Ruleの種類 Connectivity Health Rules 接続性（Connectivity）を監視し、接続性に関するイベントをトリガーに通知を行います。 Quality Health Rules 品質指標（Quality）を監視し、設定した閾値を超えた場合に通知します。 今回、Connectivity Health Rulesにおいて、監視可能な接続性に関するイベントが追加され「SocketのLAN Portダウン通知」が可能になりました。 Link Health Ruleの詳細はこちらの記事をご参照ください。 【前編】CatoクラウドのLink Health Rules活用法 ～Connectivity Health Rules～ 「Connectivity Health Rule（接続性監視）」の概要と活用方法を解説します。 blog.usize-tech.com 2025.11.19 設定手順 それでは、設定手順を解説していきます。 ※Detection & Response Policyからの移行を行う場合は、 STEP0（事前準備～「Link Health Rule」の編集）から ご確認ください。 STEP 0：事前準備～「Link Health Rule」の編集 まずは、Detection & Response Policyの既存ルールを確認します。 以下のページから「Response Policy」のタブを開き、Indicationが「LAN port down」のルールを確認します。 ▼[Home] > [Detection & Response Policy] 以下項目は、Link Health Ruleの設定の際にも必要になるため、控えておきます。 確認項目 Source（対象サイト） Response（通知先） 次に、以下のページから「Connectivity Health Rules」のタブを開きます。 ▼[Network] ＞ [Link Health Rule] 対象サイトにおけるルールが既に存在しており、通知先を同じにする場合は、監視対象 イベントを追加します。 対象サイトにおけるルールがない場合はSTEP1へ進みます。 設定内容 Condition On Event ：「Lan Port Disconnect」を追加 追加したら「Apply」⇒「Save」で設定保存を行います。 反映まで5分程度待ったら、STEP2へ進みます。 STEP 1：「Link Health Rule」の新規作成 弊社の検証環境を下図のような構成とし、「SocketのLAN2ポートに障害が発生した」というシナリオを想定した設定を行っていきます。 「New」のボタンから 以下のように設定を行いました。 設定内容 General Name ：「LINK_DOWN_TEST」と入力 Source Site ：「検証環境」を選択 Condition On Event ：「Lan Port Disconnect」を選択 Tracking Frequency ：「 Immediate( 即時 )」を選択 Send notification to ：「 Mailing List(ML_Test)」を選択 入力ができたら、「Apply」⇒「Save」で設定保存を行います。 保存したら、反映まで5分程度待ちます。。。 5分程度たったら、STEP2へ進みましょう。 STEP 2：動作確認 可能であれば実施いただくことを推奨しますが、業務影響が発生する場合があります。 事前に影響がないかご確認ください。 それでは、LANポート障害を発生させて想定通り通知が飛ぶか確認してみます。 LAN2ポートを抜線すると。。。 30秒ほど経過して、通知が届きました！ ちなみに、再接続を行うと同じように30秒ほど経過後に、接続の通知も届きました。 無事想定通り、通知を受け取れることを確認したら「Link Health Rule」の設定は完了です。 Detection & Response Policyからの移行を行っていた場合は、さらにSTEP3に進みます。 STEP 3：既存設定の削除 最後に、STEP0で確認した既存のルールを削除します。これで、作業は完了です！ 既にトライアル期間が終了している場合は、削除ができない場合がございます。 さいごに 今回は、Link Health Rule によるLAN Port Disconnect 通知機能の設定方法ついてご紹介しました。 本記事を参考に、貴社の運用にお役立ていただければ幸いです！

こんにちは。SCSKの北川です。 今回はServiceNowのナレッジ管理におけるナレッジフローについてまとめました。 前回の記事はこちら 【ServiceNow】ナレッジの活用① フィードバック – TechHarmony 本記事は執筆時点（2026年1月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 デフォルトのナレッジフロー ナレッジベースから公開フロー・廃止フローを設定する際に選択できるデフォルトのナレッジフローは、4種類あります。 Knowledge – Approval Publish 公開承認 ①［公開］押下 ↓ ② レビュー ナレッジベースの 所有者／マネージャー に承認依頼 ↓ ③ 承認 or 却下 ◆ 承認の場合 予定公開日前→公開予定 予定公開日 が「空」 または 予定公開日後→公開済      ◆ 却下の場合 ドラフト に戻る Knowledge – Approval Retire 廃止承認 ①［廃止］押下 ↓ ② レビュー ナレッジベースの所有者／マネージャー に承認依頼 ↓ ③ 承認 or 却下 ◆ 承認の場合 廃止 ◆ 却下の場合 フロー開始前のステータスに戻る Knowledge – Instant Publish すぐに公開 ①［公開］押下 ↓ ②  予定公開日前→公開予定 予定公開日 が「空」 または 予定公開日後→公開済 Knowledge – Instant Retire すぐに廃止 ①［廃止］押下 ↓ ② すぐに廃止   カスタムナレッジフロー        条件や承認者など業務要件に応じて承認・廃止フローを変更したい場合は、カスタムナレッジフローを作成します。 手順は以下の通りです。 ①[Workflow Studio]の[Flows]からデフォルトのフローを選択します。      ②画面右上の[More Actions Menu]から[Copy flow]を押下します。 ③フローの名前を変更します。 ④コピーしたフローを編集後[Activate]を選択します。 ⑤ナレッジベースの「Publish flow」または「Retire flow」に④で編集したフローを設定します。 以上がナレッジフローを作成～設定の手順です。 まとめ 今回はナレッジ管理におけるナレッジフローをご紹介しました。 ナレッジフローを活用して、効率的にナレッジを運用しましょう。

こんにちは、SCSKで テクニカルエスコートサービス を担当している兒玉です。 前回は検証用リダイレクト先ドメインのサイトを作成するところまででしたが、今回は目的であるAPEXドメイン側の設定を行います。 前編は こちら APEXドメインの作成 今回は、いよいよAPEXドメインの仕組みを作成していきます。 前回紹介したアーキテクチャ図の左側になります。 東京リージョンでの証明書の発行 前編で発行した証明書ですが、CloudFrontで使用するために 米国東部（バージニア北部）(us-east-1) で発行していました。 一方、今回デプロイしようとしているAPEXドメインのALBは東京リージョン(ap-northeast-1) に作成予定です。 AWS Certificate Manager(ACM) にある証明書は同じリージョン内でないと使用出来ないため、今度は東京リージョンで発行する必要があります。 前編で行ったのと同様に、APEXドメイン名+サブドメイン名(ワイルドカード指定)、エクスポート無効、DNS検証としてリクエストを行います。秘密鍵のエクスポートを無効にすると無料なので、こういうケースでは助かりますね。 前編と同様に、DNS認証を行うのですが、設定すべきCNAME名、CNAME値のセットはドメインが同じ場合には同じ値になるようで、リクエスト後数分で証明書が「発行済み」となりました。 次のデプロイで使用するので、証明書のARNをコピーしてメモしておきます。   APEXドメイン転送システムをデプロイ デプロイに必要なファイルを準備します。 必要なファイルを zip 化したファイルのリンクです。 apex-domain-redirect-main-20260121-1.zip   sha256: 6fedb6a407248b58e402a7378af68196823584270b7d55643ea16cc4e80cebb3 ファイルをダウンロードし、AWS CloudShellにアップロードして zipファイルを展開して、フォルダを移動します。 ~ $ unzip apex-domain-redirect-main-20260121.zip -d ./apex-domain-redirect-main Archive: apex-domain-redirect-main-20260121.zip inflating: ./apex-domain-redirect-main/apex-domain-redirect-main.yaml inflating: ./apex-domain-redirect-main/deploy.sh inflating: ./apex-domain-redirect-main/README-jp.md inflating: ./apex-domain-redirect-main/PARAMETERS-jp.md ~ $ cd apex-domain-redirect-main apex-domain-redirect-main $ PARAMETERS-jp.md 、README-jp.md などを参考に、パラメータと共に、 deploy.sh を実行します。 –stack-name :  作成するCloudFormationスタックのスタック名 –apex-domain : 作成するAPEXドメイン名 –target-fqdn  : リダイレクト先となるドメインのFQDN –certificate-arn : 先程メモした 証明書のARN –prefix  : 作成するリソースにつくprefix –cost-tag : 属性名”Cost” のタグの値 ./deploy.sh --stack-name my-apex-redirect \ --apex-domain example.com \ --target-fqdn www.example.com \ --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/abcd1234-ab12-cd34-ef56-abcdef123456 \ --prefix my-apex \ --cost-tag my-project 10-15分程度でデプロイが完了します。 成功すると、以下のようなメッセージが出力されるので、指示に従って他社DNSにAPEXドメイン用の Aレコードを 2 つ 設定します。 他社DNSにレコードを登録した後しばらく待ちます。 通常は数分から数時間ですが、最大48時間程度かかることもあるようですので、気長に待ちましょう。 dig コマンドなどで、APEXドメインに対してDNSクエリを行い、デプロイ結果で表示されたAPEXドメインのAレコード2つが表示されれば OK です。 APEXドメイン転送動作の確認 Webブラウザから、 APEX ドメイン名を入力してアクセスします。 Lambda関数が生成したAPEXドメインのHTMLが表示されます。ブラウザのアドレス欄の左端が錠マークになっているので、 APEXドメインのHTTPS 接続に転送されていることがわかります。 APEXドメイン転送の動作や、転送しようとしているFQDNがわかりやすいように、わざと転送まで10秒待ちをいれていますが、実際のWebサイトでは即時転送に変更してください。 10秒後に前編で構築した検証用リダイレクト先のWebページに無事転送されました！ おわりに いかがだったでしょうか？ DNS ALIAS非対応の他社DNSでも、APEXドメインへのアクセスをリダイレクトする処理をサーバレスに構築できることがお分かりいただけたと思います。 従来であれば、APEXドメインのトラフィックをリダイレクトするためだけにEC2でWebサーバーを構築し、OSやミドルウェアのパッチ適用などのメンテナンスを継続的に行う必要がありました。 しかし、このソリューションではCloudFormationテンプレートをデプロイするだけで、メンテナンスを極小化（Lambda関数のランタイム管理とWAFルールの調整程度）したサーバレス構成を実現できます。運用負荷の削減という点で大きな価値があるのではないでしょうか。 それでは、皆様も良いAPEXドメイン転送生活を。

こんにちは、SCSKで テクニカルエスコートサービス を担当している兒玉です。 Webサイトを作成する際に、APEXドメインへのアクセスを転送したい、と思うことはありませんか？ APEXドメイン（アペックスドメイン、Zone APEX 、ネイキッドドメイン、ルートドメインとも呼ばれる）とは、「example.com」のようにサブドメイン（www.など）を含まない、ドメイン名そのもののアドレスを指します。 Webサイトにアクセスするユーザー側の立場として考えると、サブドメインあるいはサーバー名を指定してアクセスするのは入力するのが面倒ですし、通例として www に決まっているとしても、決まっているならそっちに自動的に誘導してほしいと考えるのは自然な考えだと思います。 ところが、DNSの仕組みからすると、APEXドメインはちょっと厄介で、APEXドメインには CNAME 適用できないという制約があります。 # これはできない（RFC違反） example.com. CNAME d123456789.cloudfront.net. # サブドメインならOK www.example.com. CNAME d123456789.cloudfront.net. CNAMEはそもそも「このドメインのことは全部あっちの窓口にお願いします」という記述なのですが、APEXドメインにはSOA(Start Of Authority) つまり「このドメインの責任者は私です」という名札をつけて立っている担当者がいる状況なわけです。 こんな矛盾した記述がされているドメインにDNSが問い合わせを行うと、混乱を招いてしまうため禁止されているんですね。 しかし、wwwなどサーバ名なしのドメインからそのドメインのホームページにたどり着きたいという動機もわかります。 では、どうすればよいか。 選択肢としては3つあります。 1. Amazon Route 53のALIASレコードを使う Route 53を使っている場合、ALIASレコードという特殊なレコードタイプが使えます。これはAWS独自の機能で、APEXドメインでもCloudFrontやALBを指定できます。 しかし、これはRoute 53を使っている場合のみ。DNSサーバーを移管したくない、あるいは移管できない状況ではこの選択肢は採用できません。 2. 外部DNSプロバイダーの独自機能を使う 一部のDNSプロバイダー（Cloudflare、DNSimpleなど）は、ALIAS相当の独自機能を提供しています。 しかし、全てのプロバイダーが対応しているわけではありませんし、移管できない状況であれば 1. のケースと同様にこちらも採用できません。 3. 固定IPアドレスを使う Aレコードで固定IPアドレスを指定する方法。これならどのDNSプロバイダーでも使えます。 仕方なく 3. を選ぶことになります。ところが、AWS上でベストプラクティスとされる CloudFront や ALBは動的IPなので、固定IPアドレスを持つサーバー（例えば Elastic IP + EC2）が別に必要になってしまいます。これをうまくサーバレスで解決するソリューションを考えます。 まとめると、こんな状況ではないでしょうか？ 会社のポリシーでALIAS相当の機能に対応していない外部DNSプロバイダーを使わなければならない でもAPEXドメインでのアクセスを受け付けたい CloudFrontやALBなど、AWSのサービスにリダイレクトしたい サーバーの維持管理をしたくないのできればサーバーレスで実現したい  このソリューションでは、こんな状況を解決いたします！ 前編では、検証用のリダイレクト先環境と証明書の準備までを行います。   ソリューションの全体像 ソリューションの全体像は以下のようになります。 他社DNSでのAPEXドメインレコードに対する要件（IPアドレスを直接設定）を満たすために、Network Load Balancer(NLB) に Elastic IP を付与し、Webサイトとして必要な証明書は Application Load Balancer(ALB) で行い、サブドメインに対するリダイレクト処理を行うHTML応答を Lambda関数内で生成、レスポンスとして返却することで、ブラウザにサブドメインへリダイレクトするよう促します。 この処理をフロー図にすると以下のようになります。 このソリューションの料金概算 前提条件 リージョン: ap-northeast-1（東京） 月間リクエスト数: 100万リクエスト（想定） 平均レスポンスサイズ: 10KB 稼働時間: 24時間365日（730時間/月） 使用サービスと料金 AWS Lambda 設定 メモリ: 128MB ランタイム: Python 3.12 平均実行時間: 100ms（想定） 料金 リクエスト料金: $0.20 per 1M requests 100万リクエスト × $0.20 = $0.20/月 コンピューティング料金: $0.0000166667 per GB-second 100万リクエスト × 0.1秒 × 0.125GB = 12,500 GB-秒 12,500 GB-秒 × $0.0000166667 = $0.21/月 Lambda合計: $0.41/月   Application Load Balancer (ALB) 料金 ALB時間料金: $0.0243 per hour（東京リージョン） 730時間 × $0.0243 = $17.74/月 LCU料金: $0.008 per LCU-hour 想定: 0.5 LCU/時間（低トラフィック） 730時間 × 0.5 LCU × $0.008 = $2.92/月 ALB合計: $20.66/月   Network Load Balancer (NLB) 料金 NLB時間料金: $0.0243 per hour（東京リージョン） 730時間 × $0.0243 = $17.74/月 NLCU料金: $0.006 per NLCU-hour 想定: 0.5 NLCU/時間（低トラフィック） 730時間 × 0.5 NLCU × $0.006 = $2.19/月 NLB合計: $19.93/月   Elastic IP Address 料金 Public IPv4アドレス料金: $0.005 per IP per hour 2個のElastic IP × 730時間 × $0.005 = $7.30/月 Elastic IP合計: $7.30/月   AWS WAF 設定  Web ACL: 1個 マネージドルール: 3個（AWSManagedRulesCommonRuleSet、SQLi、KnownBadInputs） カスタムルール: 1個（Rate-based rule） 合計ルール数: 4個 料金 Web ACL料金: $5.00 per month ルール料金: $1.00 per rule per month 4ルール × $1.00 = $4.00/月 リクエスト料金: $0.60 per 1M requests 100万リクエスト × $0.60 = $0.60/月 WAF合計: $9.60/月   VPC関連リソース 料金 VPC: 無料 Subnets: 無料 Internet Gateway: 無料 Route Tables: 無料 Security Groups: 無料 VPC合計:$0.00/月   その他料金 インターネットへのデータ転送（アウトバウンド）: 最初の10TB/月: $0.114 per GB（東京リージョン） – 次の40TB/月: $0.089 per GB – 次の100TB/月: $0.086 per GB 100万リクエスト × 10KB = 10GB/月の場合 – データ転送料金: 10GB × $0.114 = $1.14/月 その他料金合計: $1.14/月   VPC関連リソース 月額料金合計   サービス 月額料金（USD） 月額料金（JPY）※ Lambda $0.41 ¥62 ALB $20.66 ¥3,099 NLB $19.93 ¥2,990 Elastic IP (×2) $7.30 ¥1,095 WAF $9.60 ¥1,440 VPC $0.00 ¥0 ACM $0.00 ¥0 IAM $0.00 ¥0 その他 $1.14 ¥171 合計 $59.04 ¥8,857 ※ 為替レート: 1 USD = 150 JPY で計算   検証用リダイレクト先(転送先ドメイン)の作成 本番では本来のWebサイト（ 例えば www.example.com ) に転送するのですが、今回は記事用の検証なので転送先ドメインが必要です。検証用に CloudFront – S3 の環境を作成します。下図の右側の赤枠の範囲になります。 本筋でないコードを全部載せるとそれだけで記事が埋め尽くされてしまうので、必要なファイルのを zip 化したファイルのリンクを載せておきます。 test_environment.zip SHA256: 829899f97643f4dac1dff61e7600a42da4e5afd5e3f4b702cf010d95051eb960 ダウンロードしたファイルを CloudShell などにファイルをアップロードし、 zip ファイルの中身を展開してフォルダを移動します。 ~ $ unzip test_environment.zip -d ./test_environment Archive: test_environment.zip inflating: ./test_environment/deploy_test_environment.sh inflating: ./test_environment/test-environment.yaml inflating: ./test_environment/TEST_ENVIRONMENT_README.md ~ $ cd test_environment test_environment $   vim などで、 deploy_test_environment.sh の中のパラメータを修正します。 PROFILE は AWS が使用するプロファイル名でえすが、 CloudShellからの実行の場合は “” で良いです。 STACK_NAME は CloudFormationが作成するスタック名です。わかりやすい名前や環境の命名規則に沿った形に変更します。 COST_TAG はAWS内でのコスト配分タグとして使用されるタグの値を設定します。（タグの属性名は 内部では “Cost” と固定になっています。） deploy_test_environment.sh のパラメータ設定 パラメータを修正後、デプロイします。 test_environment $ ./deploy_test_environment.sh 10分くらいで、デプロイが完了するので  CloudFront Domain: abcdef01234567.cloudfront.net Test Website URL: https://abcdef01234567.cloudfront.net の箇所をメモしておきます。　これが転送先となる検証用リダイレクト先サイトのドメイン名とWebサイトの URL です。 Test Website URLにアクセスしてみると、 アクセスできましたね。（画像参照） これで検証用リダイレクト先ドメインの環境ができました。 APEXドメイン/サブドメイン用のサーバー証明書の準備 転送用の APEXドメインも https でアクセスが必要ならAPEXドメイン用の証明書が必要です。 サブドメインのワイルドカードも一緒に設定します。これは転送先(www.example.comなど)でも使えますので、AWS Certification Manager から 1枚にまとめて発行します。 CloudFront で使用するので、 証明書を作成するリージョンは 米国東部（バージニア北部）(us-east-1)  である必要があります。   エクスポート可能な証明書は有料ですが、AWS内でのみ使用する場合はエクスポート不要なので無料で利用できます。 料金 – ACM AWS Certificate Manager の料金 – アマゾン ウェブ サービス (AWS) aws.amazon.com リクエストをしただけでは、証明書は有効になりません。まだ、 「保留中の検証」というステータスになっているのがわかります。 ドメインの正当な持ち主であることを証明するために、 証明書をリクエストしたドメインのDNSの 指定された CNAME名 に指定された CNAME値 を設定する必要があります。 CNAME 名 と、 CNAME 値をコピーして、 DNS のプロバイダ画面から、 CNAMEレコードを追加して、 コピーしておいた CNAME名、対応する CNAME値 を設定します。 今回はAPEXドメイン用と、 そのサブドメイン用のワイルドカードで 2 レコードありますが、設定すべき値のセットは同じだったので 追加した CNAME レコードは 1 つでした。 DNSプロバイダの設定画面はUIが様々でどう設定すれば良いかはそのプロバイダ毎に異なるのですが、きちんと設定できているかは dig コマンドで検証すればわかります。 マスクされている箇所ばかりでわかりにくいですが、 dig cname _9c63abcdef0123456789abcdef01234.example.com. と打って、応答の ANSWER SECTION で、 CNAME名 の対となる CNAME値 が表示されれば OK です。 しばらくすると、Certificate Manager の証明書のステータスが「発行済み」に、ドメインのステータスが 「成功」 に変わります。 これで証明書は利用可能になりました。 検証用リダイレクト先サイトに ACM 証明書を設定 転送先となる検証用リダイレクト先(www.example.com) の CloudFront に、サブドメイン  www.example.com を担当してもらうために、担当するサブドメイン名とCertificate Managerから取得した証明書を設定します。 CloudFormationスタックに、先程作成した検証用リダイレクト先のスタックがありますので、 CloudFrontDistributionId の 値 にあるディストリビューションを覚えておいて、マネジメントコンソールの CloudFront の画面から開きます。 ディストリビューションの画面から Add domain をクリック www.example.com (実際は自分のドメイン名) を入力して、Next をクリック 先程作成した証明書が表示されるので、それをチェックして Next、 変更を確認してAdd domains  Distribution updated successfully と表示され、代替ドメイン名に www.example.com 、カスタムSSL証明書の欄がチェックマークになっていればOKです。 Route domains to CloudFront ボタンを押すと、DNSサーバーに設定する レコードの情報が表示されます。これを、利用しているDNSサーバーに設定します。 DNSプロバイダーによってはAレコードに値を直接入力できない場合がありますが、その場合はCNAMEレコードとして設定しても問題ありません。 今回はここまで。

こんにちは。SCSKで全世界のZabbixが止まらない事を祈っている、小寺です。 Zabbixの6.0から新しくHA機能が実装されています。このHA機能はZabbixServerのサービスのみを冗長化する機能の為、データベースの冗長化が別途必要な状況になっています。 ZabbixにおいてデータベースのI/Oがボトルネックになることが多い点を踏まえ、MySQLを用いてどの冗長化方式がパフォーマンスに優れているか、実機検証を行いました。 1. DRBD 9.0 の構築・設定 DRBD 9系で、Protocol A（非同期）と Protocol C（同期）を検証しました。 それぞれの方式を構築し、fioというツールを用いて速度を計測しました。 DRBD インストール rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org dnf install -y https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm dnf install -y kmod-drbd9x drbd9x-utils DRBD 設定ファイル /etc/drbd.d/res_async.res (非同期) resource res_async { protocol A; device /dev/drbd1; disk /dev/nvme1n1; meta-disk internal; on ip-10-0-2-127 { address 10.0.2.127:7788; } on ip-10-0-2-164 { address 10.0.2.164:7788; } } /etc/drbd.d/res_sync.res (同期) resource res_sync { protocol C; device /dev/drbd2; disk /dev/nvme2n1; meta-disk internal; on ip-10-0-2-127 { address 10.0.2.127:7789; } on ip-10-0-2-164 { address 10.0.2.164:7789; } } DRBDの初期化・有効化 # メタデータの作成 drbdadm create-md res_async drbdadm create-md res_sync # リソースの有効化 drbdadm up res_async drbdadm up res_sync # 片方（Primary側）でのみ実行 drbdadm primary --force res_async drbdadm primary --force res_sync mkfs.xfs /dev/drbd1 mkfs.xfs /dev/drbd2 # 両方で実行 mkdir /mnt/async_data mkdir /mnt/sync_data # 片方（Primary側）でのみ実行 mount /dev/drbd1 /mnt/async_data mount /dev/drbd2 /mnt/sync_data DRBD単体の性能検証 (fio結果) 計測対象 IOPS (Write) 帯域 (BW) 平均レイテンシ 標準比 (維持率) 標準ディスク 1,142 4,568 KiB/s 874.92 µs 100% (基準) DRBD 非同期 (Prot A) 1,125 4,503 KiB/s 887.10 µs 98.5%(▲1.5%) DRBD 同期 (Prot C) 1,037 4,150 KiB/s 962.66 µs 90.8%(▲9.2%)   2. MySQL 8.0 構築・設定 MySQL設定ファイル (/etc/my.cnf.d/mysql-server.cnf) [mysqld-nomal] port = 3306 socket = /tmp/mysql.sock3306 datadir = /var/lib/mysqld [mysqld-drbd-sync] port = 3307 socket = /tmp/mysql.sock3307 datadir = /mnt/sync_data/mysqld-drbd-sync [mysqld-drbd-async] port = 3308 socket = /tmp/mysql.sock3308 datadir = /mnt/async_data/mysqld-drbd-async [mysqld-rep-sync] port = 3309 socket = /tmp/mysql.sock3309 datadir = /var/lib/mysqld-req-sync log-bin = mysql-bin server-id = 1 rpl_semi_sync_source_enabled = 1 rpl_semi_sync_source_timeout = 10000 [mysqld-rep-async] port = 3310 socket = /tmp/mysql.sock3310 datadir = /var/lib/mysqld-req-async log-bin = mysql-bin server-id = 1 同期レプリケーション構築 SQL マスター側 で実行 -- 準同期用プラグインの有効化 INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so'; SET GLOBAL rpl_semi_sync_source_enabled = 1; -- レプリケーションユーザーの作成 CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; FLUSH PRIVILEGES; -- 現在のログファイル名とポジションを確認 SHOW MASTER STATUS; スレーブ側 で実行 -- 準同期用プラグインの有効化 INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so'; SET GLOBAL rpl_semi_sync_replica_enabled = 1; -- マスターへの接続設定 CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.2.127', SOURCE_PORT=3309, SOURCE_USER='repl_user', SOURCE_PASSWORD='password', SOURCE_LOG_FILE='mysql-bin.000001', -- SHOW MASTER STATUSの結果に合わせる SOURCE_LOG_POS=157; -- SHOW MASTER STATUSの結果に合わせる -- レプリケーション開始 START REPLICA; -- ステータス確認 SHOW REPLICA STATUS\G 非同期レプリケーション構築 SQL マスター側 で実行 -- レプリケーションユーザーの作成 CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; FLUSH PRIVILEGES; -- 現在のログファイル名とポジションを確認 SHOW MASTER STATUS; スレーブ側 で実行 -- マスターへの接続設定 CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.2.127', SOURCE_PORT=3310, SOURCE_USER='repl_user', SOURCE_PASSWORD='password', SOURCE_LOG_FILE='mysql-bin.000001', -- SHOW MASTER STATUSの結果に合わせる SOURCE_LOG_POS=157; -- SHOW MASTER STATUSの結果に合わせる -- レプリケーション開始 START REPLICA; -- ステータス確認 SHOW REPLICA STATUS\G 3. 性能検証結果 (sysbenchによるTPS計測) Zabbixのバックエンドとしての実用性を測るため、sysbenchを用いてスループット（TPS：1秒あたりのトランザクション数）を計測しました。さらに、実運用を想定した「DBチューニング後」の数値も比較しています。 構成案 デフォルト (TPS) チューニング後 (TPS) シングル比 (維持率) シングル構成 637.4 1,505.4 100% (基準) DRBD (同期) 597.6 1,439.4 95.6% DRBD (非同期) 610.8 1,463.9 97.2% MySQL同期(準同期) 521.7 1,384.7 92.0% MySQL非同期 635.1 1,494.6 99.3% ※チューニングにより、全構成でTPSが約2.3倍〜2.6倍に向上しています。 4. 結論：Zabbix DB冗長化の最適解は？ 検証の結果、 「いずれの方式を選んでも、性能劣化は極めて軽微である」 という心強い結果が得られました。 今回のポイント DRBD同期モードの健闘： ストレージ層で完全に同期しているにもかかわらず、DBレベルでの劣化はわずか 4.4% でした。ファイルシステムレベルでの冗長化が必要な場合に非常に有力です。 MySQLレプリケーションの安定性： 非同期であればシングル構成と遜色ない性能を発揮します。同期（準同期）でも8%減に留まっており、チューニング次第でさらに差を詰められる「伸び代」を感じさせます。 【小寺流・選定のアドバイス】 性能劣化を過度に心配する必要はありません！「OSを含めた物理故障に備えたいなら DRBD 」、「DBの論理的な整合性や読み取り分散も考慮したいなら MySQLレプリケーション 」といったように、運用要件に合わせて柔軟に選択してOKです。 Zabbixを「止まらない監視システム」に育て上げるための参考になれば幸いです！   SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

こんにちは、SCSKの坂木です。 今回は、 生成AI（Gemini3.0）を活用して、フローチャートからAmazon Lexのチャットボットを自動構築 するという検証を行ってみました。 「AWSでチャットボットを作りたいけど、Lexの構築は設定項目が多くて難しい…」 「Lexのコンソール画面だけだと、会話全体の流れ（全体図）が見えづらい…」 そんな悩みを持つ方向けに、フローチャートさえあれば、あとはAIにお任せ というワークフローが可能か試してみた記録です。   Amazon Lexについて Amazon Lexは、音声やテキストを使用した会話型チャットボットを構築するためのフルマネージドサービスです。 主な特徴 フルマネージド ：サーバーのプロビジョニングや管理が不要。 他サービス連携 ：AWS Lambda等と統合し、会話に応じたバックエンド処理（データ取得や予約など）を簡単に実行可能。 コスト効率　　 ：リクエスト数に応じた従量課金制。   Lexの課題：全体像の把握が難しい 一方で、Lexで開発を進める上での課題もあります。 Lexには「ビジュアルビルダー」という機能がありますが、これは特定のインテント内の細かい動きを見るのがメインです。「メニューAを選んだらBに飛び、そこからCに戻る」といったボット全体の遷移図を俯瞰して見る機能は標準ではありません。 そのため、全体像の把握にはExcelなどで別途フローチャートを作って構成を管理する必要があります。 「どうせExcelで全体図（フローチャート）を作る必要があるなら、そこからAIを使って直接ボットを作ってしまえばいいのでは？」 そう考えたのが、今回の取り組みのきっかけだったりします。   今回のアプローチ：フローチャート × Gemini そこで今回は、構築の難易度を下げるために、人間とAIの役割を完全に分けるアプローチを試しました。 人間（設計者）：  「どんな会話にしたいか」を考えることに集中する（Excel作成） AI（エンジニア）：  複雑なAWSの設定やコード記述を担当する（Terraform生成） これまでは、人間が「会話の設計」も「AWSコンソールの設定」も両方やる必要がありましたが、後者の面倒な作業を全てAIに丸投げしよう、という作戦です。 具体的な検証フローは以下の通りです。 【人間】設計図を作る  Excelで会話の流れ（フローチャート）とセリフ（管理表）を作成する。 【AI】コードに変換する ExcelデータでGeminiに渡し、Lex構築用のTerraformコードを書いてもらう。 【AWS】デプロイ  出力されたコードを実行し、AWS上にボットを自動生成する。 このフローにより、Lexの専門知識がなくても、「Excelさえ書ければチャットボットが作れる」という状態を目指します。   Excelでフローチャート+補足の表資料を作成する 今回は、 会話の流れ（遷移）を管理する「フローチャート」 と、 ボットのセリフを管理する「管理表」 の2つを使って設計します。   1. 会話の流れを整理する（フロー図） まずは、会話の地図となるフローチャートを作成します。 「どのボタンを押したら、次にどの画面に進むか」という会話のルートは、すべてこの図の中で管理 します。 Excelのセルに文字だけで「Aの次はBへ移動」と書くと複雑になりがちですが、こうして矢印を使った図にすることで、直感的に会話の流れを作ることができます。これが今回の設計のメインとなります。   2. Excelの表に落とし込む（管理表） 図で流れができたら、 各場面で「ボットが何と喋るか」をExcelの表に入力 します。 フローチャートの中に長いセリフを書くとゴチャゴチャしてしまうので、図をスッキリさせるために、メッセージ部分は表で分けて管理することにしました。   この表では、会話の1シーンごとに以下の3つの項目を埋めていくだけです。 項目 説明 インテント名（シーンのID） 会話の各シーンに付ける「名前」です（例：Iac_Menu） 他のシーンと区別するためのIDのようなもの 応答メッセージ そのシーンで「ボットが喋る言葉」です（例：「ご質問内容を選択してください」） 次の動作 ボタンが押された後に「次に移動するシーンの名前」を指定します （例：インストールを選んだら Iac_ZabbixInstall へ移動する、といった行き先案内です）   GeminiにTerraformコードを書いてもらう この章でやったことは非常にシンプルです。 前工程で作成したフローチャートと表が記載されたエクセルデータをコピーして、Geminiのチャット欄に貼り付け、以下のプロンプトを投げただけです。 #実際に使ったプロンプト 添付のフローチャート及び表から、Lexのチャットボットを作成するTerraformのコードを作成してください。 ボタンにおけるラベルと値は、フローチャートの分岐の文字列を用いてください。 ちなみに、最後の「ボタンにおける〜」という一文を加えたのには理由があります。 今回作成したExcelの管理表はシンプルさを優先し、「ボタンに表示する文字」の列を省いていました。そのため、Geminiがボタン名の実装で迷わないよう、「次の画面へつながる流れ（分岐）を見て、そこから適切なボタン名を自動で判断してね」 という意図を伝えています。   ちなにみ、GeminiはExcelには書かれていないLex構築に必要な設定を勝手に理解し、コードに落とし込んでくれました。 具体的には、以下の点を自律的に判断してくれました。 IAMロールの自動作成 Excelには「権限」の話など書いていませんが、Geminiは「Lexが動くためにはIAMロールが必要だ」と判断し、適切なポリシー（AmazonLexFullAccess）を持ったロールを作成するコードを追加してくれました。 ボットの基本構造（Bot / Locale）の定義  インテント（会話の中身）を作る前に、まず「ボット本体」と「言語設定（日本語）」の枠組みが必要であることを理解し、定義してくれました。 ボタンと次の会話の「つなぎ方」  フローチャートでは「Aボタンを押すとBへ行く」としか表現していませんでしたが、Geminiはこれを「Bのインテントの発話条件（Utterance）に、Aボタンのラベルを設定する」というLex特有の実装ロジックに変換してくれました。 レスポンスカードの適切な選択 「ボタンを表示する」という要件に対し、単なるテキストではなく、Lex V2における適切な形式である image_response_card を選択して実装してくれました。   もちろん、一発で完璧に動作したわけではありません。Terraformのプロバイダバージョンの違いによる記述エラーや、リソース名の重複エラーなどが発生しました。 しかし、ここでも専門知識は不要でした。出たエラー文をそのままコピーしてGeminiに貼り付けるだけで、「すみません、修正します」と正しいコードを書き直してくれたのです。 実際にGeminiと協力して完成させたTerraformコードの全文は、量が多いため記事の最後に掲載しています。   チャットボットの動作確認 Geminiが書いてくれたTerraformコードを実行（terraform apply）し、AWSの管理画面を確認してみました。 結果から言うと、 Lexの複雑な設定画面を一切触ることなく、想定通りの動きをするチャットボットが完成 していました。   1. 管理画面で「答え合わせ」 まずはAWSコンソールを開いて、作成されたボットの中身を見てみます。 私は特に指定していなかったのですが、Geminiが気を利かせて「ZabbixHelpBot」という、まさに用途にぴったりの名前を付けてくれていました。 さらに「インテント（会話のパーツ）」の一覧を確認すると、Excelのフローチャートで定義していた Iac_Menu や Iac_Server といった項目が、正しく生成されていることが分かります。   2. 実際の会話テスト 設定が合っていても動かなければ意味がありません。AWSコンソールのテスト機能を使って、実際にボットと会話してみました。 ケース①：インストール手順の案内 まずは「メニュー」から「インストール」を選び、さらに「Server」を選択するフローです。 Excelの矢印で描いた通りにボタンが次々と表示され、最終的に正しいURLが案内されました。「終了」ボタンで会話を終える動きも完璧です。   ケース②：別メニューへの遷移と「戻る」動作 次に、「ライブラリ」や「ホスト設定」といった別の質問を選んでみます。 こちらもURLの案内後に「メニューに戻る」ボタンが表示され、それを押すと最初の画面に戻るという、ループ構造も正しく機能していました。   まとめ 本ブログでは、 生成AI（Gemini）を活用して、ExcelのフローチャートからAmazon Lexのチャットボットを自動構築 する検証を行いました。 結果として、 専門知識が必要なAWSの管理画面を一切操作することなく、直感的な「お絵描き」だけでボットを作り上げることができました 。設計は人間、実装はAIという役割分担により、開発のハードルは劇的に下がります。 この手法の最大のメリットは、 「正」となるドキュメントが「フローチャート（Excel）」になること です。 Lexのコンソールは設定が複雑でブラックボックス化しがちですが、この方法なら「Excelを見れば全体の動きがわかる」「修正したければExcelを直してAIにコードを再生成させる」という運用が可能になります。 「会話をデザインする」ことさえできれば、あとはAIが形にしてくれる時代です。ぜひ皆さんも、手書きのメモからクラウド上のボットを作る体験を試してみてください。   ▼ AWSに関するおすすめ記事 Terraformで実装するAWSファイルストレージ入門：EFSとFSxを構築してみた Terraformを使い、AWSのファイルストレージであるEFSとFSx for Windowsの構築手順を解説します。Linux/Windowsそれぞれに最適なストレージをIaCでコード管理。インフラ構築の再現性を高め、効率化を実現したい方はぜひご覧ください。 blog.usize-tech.com 2025.12.15 【Amazon Bedrock】ナレッジベースを用いた社内資料管理ーめざせ生産性向上ー 社内資料の管理、効率的ですか？様々な形式の文書が散在し、必要な情報を探すのに時間を取られていませんか？ ファイルサーバーの奥底に埋もれどこにあるか分からない、バージョン管理が混乱する、などといった課題を抱えていませんか？これらの非効率は、業務の生産性低下に直結します。 今こそ、社内資料の一元管理体制を見直しましょう！ということで、AWS Bedrockのナレッジベースを用いた資料の一括管理およびその検索方法をご紹介します！ blog.usize-tech.com 2025.02.14 AWS DataSync を用いて Amazon EC2 の共有フォルダを Amazon FSx に転送してみた 本記事では、ファイルサーバーのデータを Amazon FSx へ移行するシナリオを想定し、AWS DataSync を使った具体的な設定手順をスクリーンショットを交えながら、一つひとつ丁寧に解説していきます。 blog.usize-tech.com 2025.10.02   （付録）完成したTerraformコード全文 最後に、今回の検証でGeminiが生成し、修正を加えた最終的なTerraformコードを掲載します。 以下のコードを保存し、terraform apply を実行するだけで、今回のZabbixヘルプボットがお使いのAWS環境に構築されます。 #provider.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "aws" { region = "ap-northeast-1" }   #main.tf # -------------------------------------------------------------------------------- # IAM Role for Lex # -------------------------------------------------------------------------------- resource "aws_iam_role" "lex_role" { name = "LexV2BotRole" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "lexv2.amazonaws.com" } } ] }) } resource "aws_iam_role_policy_attachment" "lex_policy_attach" { role = aws_iam_role.lex_role.name policy_arn = "arn:aws:iam::aws:policy/AmazonLexFullAccess" } # -------------------------------------------------------------------------------- # Lex Bot Definition # -------------------------------------------------------------------------------- resource "aws_lexv2models_bot" "zabbix_bot" { name = "ZabbixHelpBot" role_arn = aws_iam_role.lex_role.arn data_privacy { child_directed = false } idle_session_ttl_in_seconds = 300 } # -------------------------------------------------------------------------------- # Bot Locale (日本語) # -------------------------------------------------------------------------------- resource "aws_lexv2models_bot_locale" "ja_jp" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = "ja_JP" n_lu_intent_confidence_threshold = 0.40 } # -------------------------------------------------------------------------------- # Intent: Iac_Menu (トップメニュー) # -------------------------------------------------------------------------------- resource "aws_lexv2models_intent" "iac_menu" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = aws_lexv2models_bot_locale.ja_jp.locale_id name = "Iac_Menu" sample_utterance { utterance = "メニュー" } sample_utterance { utterance = "開始" } sample_utterance { utterance = "トップ" } initial_response_setting { initial_response { message_group { message { plain_text_message { value = "ご質問内容を選択してください" } } } message_group { message { image_response_card { title = "選択肢" button { text = "Zabbixインストールに関する質問" value = "Zabbixインストールに関する質問" } button { text = "Zabbixライブラリに関する質問" value = "Zabbixライブラリに関する質問" } button { text = "ホスト設定に関する質問" value = "ホスト設定に関する質問" } } } } } next_step { dialog_action { type = "ElicitIntent" } } } } # -------------------------------------------------------------------------------- # Intent: Iac_ZabbixInstall (サブメニュー) # -------------------------------------------------------------------------------- resource "aws_lexv2models_intent" "iac_zabbix_install" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = aws_lexv2models_bot_locale.ja_jp.locale_id name = "Iac_ZabbixInstall" sample_utterance { utterance = "Zabbixインストール" } sample_utterance { utterance = "Zabbixインストールに関する質問" } initial_response_setting { initial_response { message_group { message { plain_text_message { value = "インストールするコンポーネントを選択してください" } } } message_group { message { image_response_card { title = "コンポーネント選択" button { text = "Server" value = "Server" } button { text = "Agent" value = "Agent" } } } } } next_step { dialog_action { type = "ElicitIntent" } } } } # -------------------------------------------------------------------------------- # Intent: Iac_ZabbixLibrary (末端ノード) # -------------------------------------------------------------------------------- resource "aws_lexv2models_intent" "iac_zabbix_library" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = aws_lexv2models_bot_locale.ja_jp.locale_id name = "Iac_ZabbixLibrary" sample_utterance { utterance = "Zabbix要件" } sample_utterance { utterance = "Zabbixライブラリに関する質問" } initial_response_setting { initial_response { message_group { message { plain_text_message { value = "Zabbixに必要なパッケージはこちらのサイトをご確認ください。\nhttps://www.zabbix.com/documentation/current/jp/manual/installation/requirements" } } } message_group { message { image_response_card { title = "次の操作" button { text = "メニュー" value = "メニュー" } button { text = "終了" value = "終了" } } } } } next_step { dialog_action { type = "ElicitIntent" } } } } # -------------------------------------------------------------------------------- # Intent: Iac_Host (末端ノード) # -------------------------------------------------------------------------------- resource "aws_lexv2models_intent" "iac_host" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = aws_lexv2models_bot_locale.ja_jp.locale_id name = "Iac_Host" sample_utterance { utterance = "ホスト設定" } sample_utterance { utterance = "ホスト設定に関する質問" } initial_response_setting { initial_response { message_group { message { plain_text_message { value = "ホストの設定はこちらのサイトをご確認ください。\nhttps://www.zabbix.com/documentation/current/jp/manual/config/hosts/host" } } } message_group { message { image_response_card { title = "次の操作" button { text = "メニュー" value = "メニュー" } button { text = "終了" value = "終了" } } } } } next_step { dialog_action { type = "ElicitIntent" } } } } # -------------------------------------------------------------------------------- # Intent: Iac_Server (末端ノード) # -------------------------------------------------------------------------------- resource "aws_lexv2models_intent" "iac_server" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = aws_lexv2models_bot_locale.ja_jp.locale_id name = "Iac_Server" sample_utterance { utterance = "Server" } initial_response_setting { initial_response { message_group { message { plain_text_message { value = "zabbixサーバのインストール手順はこちらをご確認ください。\nhttps://www.zabbix.com/jp/download" } } } message_group { message { image_response_card { title = "次の操作" button { text = "メニュー" value = "メニュー" } button { text = "終了" value = "終了" } } } } } next_step { dialog_action { type = "ElicitIntent" } } } } # -------------------------------------------------------------------------------- # Intent: Iac_Agent (末端ノード) # -------------------------------------------------------------------------------- resource "aws_lexv2models_intent" "iac_agent" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = aws_lexv2models_bot_locale.ja_jp.locale_id name = "Iac_Agent" sample_utterance { utterance = "Agent" } initial_response_setting { initial_response { message_group { message { plain_text_message { value = "zabbixエージェントのインストール手順はこちらをご確認ください。\nhttps://www.zabbix.com/jp/download_agents" } } } message_group { message { image_response_card { title = "次の操作" button { text = "メニュー" value = "メニュー" } button { text = "終了" value = "終了" } } } } } next_step { dialog_action { type = "ElicitIntent" } } } } # -------------------------------------------------------------------------------- # Intent: Iac_End (終了処理) # -------------------------------------------------------------------------------- resource "aws_lexv2models_intent" "iac_end" { bot_id = aws_lexv2models_bot.zabbix_bot.id bot_version = "DRAFT" locale_id = aws_lexv2models_bot_locale.ja_jp.locale_id name = "Iac_End" sample_utterance { utterance = "終了" } sample_utterance { utterance = "ありがとう" } closing_setting { active = true next_step { dialog_action { type = "EndConversation" } } closing_response { message_group { message { plain_text_message { value = "ご利用ありがとうございました。" } } } } } }

こんにちは、SCSKの坂木です。 本記事では、 保存前処理 の中でも計算処理に焦点を当て、以下の3つの機能について、具体的な設定例を交えながら解説します。 乗数 差分 1秒あたりの差分   保存前処理について 保存前処理とは、Zabbixが監視対象から取得したデータを データベースに保存する直前に、その値を加工・変換するための機能 です。例えば、取得したデータの単位を変換（バイト→ビットなど）したり、累積し続けるデータから「前回からどれだけ増えたか」という差分や速度を計算したりできます。 これにより、不要なデータを保存せずに済むためデータベースの負荷を軽減できるほか、データを整形することで、より柔軟で高度な監視や分かりやすいグラフ描画を実現できます。 2 アイテムの値の保存前処理 www.zabbix.com   乗数 取得したデータに対して、 指定した数値を掛け算して保存する処理 です。整数だけでなく、小数（0.5など）や科学的表記（1e+2など）も使用可能です。   ユースケース 単位の変換　: バイト(B)をビット(bit)に変換する、ミリ秒を秒に変換する 倍率の調整　: 0.0～1.0で表される値を、0～100(%)の表記に直す 物理量の補正: センサー等の生データに係数を掛けて正しい電圧や温度にする   実例 byte単位で出力されるOSやネットワーク機器が返す生のデータを、bit単位で監視する設定をします。 アイテムおよび保存前処理の設定は以下のとおりです。   『乗数』の保存前処理では、パラメータに入力した数値を、取得した元データに掛けてデータベースに保存します。 今回設定した保存前処理は、取得した値に8を掛ける設定となっています。   こちらのように取得されます。   差分 (現在の値) － (前回の値) を計算し、その差分量を保存する処理 です。前回チェック時から「どれだけ値が増えた（または減った）か」を記録します。   ユースケース 累積カウンタの増加量監視: 「サーバ起動時からの総アクセス数」や「総エラー数」のような、累積していくデータに対して、 「前回の監視から何件増えたか」を知りたい場合 ファイルの増加サイズ　　: ログファイルのサイズ監視などで、前回から何バイト書き込まれたかを知りたい場合   実例 ファイルサイズの差分を返す設定をします。 アイテムおよび保存前処理の設定は以下のとおりです。   『差分』の保存前処理は、パラメータを設定せず、名前の項目から『差分』を選択するだけとなっています。   こちらのように取得されます。   1秒当たりの差分 (現在の値 － 前回の値) ÷ (前回からの経過秒数) を計算する処理 です。いわゆる「速度（レート）」を算出するために使用します。   ユースケース トラフィック監視 (bps): 累積転送量から、現在の通信速度を算出する ディスクI/O (IOPS)　  : 累積読み書き回数から、1秒間あたりの処理回数を算出する CPUスイッチ回数　　　: コンテキストスイッチの累積回数から、現在の負荷状況（毎秒の切り替え回数）を算出する   実例 『乗数』の実例で作成した受信した合計ビット数を取得するアイテムから、『1秒あたりの差分』を取ってインバウンド帯域(bps)を求める設定をします。 アイテムは『乗数』のものと同じであり、保存前処理は『乗数』の保存前処理に加えて『1秒あたりの差分』を追加した設定となっております。 『1秒あたりの差分』の保存前処理は、パラメータを設定せず、名前の項目から選択するだけとなります。 保存前処理は、設定したステップの上から順番に実行されます。今回の例では、まず『乗数』でバイトをビットに変換し、その変換後の値を使って『1秒あたりの差分』を計算しています。     こちらのように取得されます。   まとめ 本記事では、Zabbixの保存前処理機能の中から、計算処理を行う『乗数』『差分』『1秒あたりの差分』について解説しました。 監視対象から取得できるデータは、必ずしもそのまま監視やグラフ化に適した形式であるとは限りません。しかし、保存前処理を適切に組み合わせることで、以下のようなメリットが得られます。 データの意味付け: 単なる数値（バイト数など）を、直感的に分かりやすい単位（bpsなど）に変換できる 変化の可視化　　: 累積値ではなく、増加傾向や速度を可視化することで、障害の予兆を捉えやすくなる DB負荷の軽減　  : 不要な生データを保存せず、必要な加工済みデータのみを保存できる スクリプトやSQLでの加工に頼らず、Zabbixの設定だけで柔軟なデータ処理が可能です。ぜひこれらの機能を活用して、より効率的で精度の高い監視環境を構築してみてください。 最後までお読みいただきありがとうございました！   ▼ Zabbixに関するおすすめ記事 【Zabbix】保存前処理まとめ -テキスト編- Zabbixの保存前処理（テキスト編）を徹底解説。正規表現、置換、文字列削除など5つの手法を使い、コマンド出力やログから必要な値を抽出するテクニックを具体例で紹介。未加工のデータを整形し、監視の質を向上させたい方必見です。 blog.usize-tech.com 2025.12.04 【Zabbix】UserParameterでスクリプト実行結果を監視する方法 ZabbixのUserParameter設定ガイド。独自の監視項目を追加する方法、引数を使ったコマンドの使い回し、system.runとの違いを具体例で紹介。監視業務を効率化したい方はぜひ。 blog.usize-tech.com 2025.11.06 【Zabbix】system.runでスクリプト実行結果を監視する方法 Zabbixのsystem.run設定方法をステップバイステップで解説。標準アイテムにないカスタム監視を実現するため、zabbix_agentd.confの修正、安全なAllowKeyの使い方、スクリプトの権限設定までを網羅。初心者でも安心のガイドです。 blog.usize-tech.com 2025.11.04   弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ Zabbix資料ダウンロード｜SCSK Plus サポート for Zabbix Zabbix監視構築に必要な知識と最新機能についての資料をダウンロードできるページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Zabbixチャンネル★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、最新のZabbixトレンドや実際の導入事例を動画で解説。明日から使える実践的なノウハウを提供します。 今すぐチャンネル登録して、最新情報を受け取ろう！ www.youtube.com

こんにちは。SCSKの北川です。 今回はServiceNowのナレッジ管理におけるフィードバック機能についてまとめました。 本記事は執筆時点（2026年1月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 ナレッジ記事のフィードバック 「フィードバック」は ユーザーがナレッジ記事の有用性や改善点を評価・コメントできる機能 です。この機能を活用することにより、記事の品質向上や継続的な改善が可能になります。 ナレッジ記事のフィードバックを送信する４つの方法 記事にフラグを設定する。 記事を評価する。  [役に立ちましたか？] の質問に [はい] または [いいえ] と回答する。 記事にコメントを追加する。 コメント追加後↓ ユーザーがナレッジ記事に関するフィードバックを送信後、ナレッジフィードバックテーブル (kb_feedback) にレコードが作成されます。   フィードバックタスク        ナレッジフィードバックタスクは、ユーザーからの改善要望や低評価をタスク化し、担当者が対応できるようにする仕組みです。 改善対応の漏れを防ぎ、ナレッジ記事の品質を継続的に向上させることができます。 タスクが作成される条件は以下のプロパティにて設定可能です。 glide.knowman.feedback.enable_actionable_feedback_for_helpful 記事が役に立たないとマークされている場合にアクション可能なフィードバックタスクを作成します。 glide.knowman.feedback.enable_actionable_feedback_for_rating 記事がこの値以下に評価されている場合、アクション可能なフィードバックタスクを作成します。0 または値が設定されていない場合、レートタイプのフィードバックに対してアクション可能なフィードバックタスクが有効になっていないことを示します。   まとめ 今回はナレッジ管理におけるフィードバック機能をご紹介しました。 フィードバックを活用し、ナレッジ記事の品質を継続的に向上させましょう。

こんにちは。SCSKの井上です。 この記事では、New RelicのInfrastructure エージェント導入後に、インフラ基盤を監視するための画面の見方を解説します。CPU、メモリ、ネットワークトラフィックなどの観測方法を理解することで、インフラ基盤のボトルネックを把握できるようになります。 はじめに アプリケーションを安定して動作させるためには、インフラ基盤を正常に稼働させることが不可欠です。ハードウェア性能に関するデータを観測し、インフラ関連の情報を一元管理することで、システム全体を把握し、健全性を高めることが安定したサービス提供につながります。この記事を読んで、Infrastructure機能を少しでも理解いただけると幸いです。 Infrastructureエージェントの導入方法については、過去の記事からご確認いただけます。 【New Relic】Infrastructureエージェントのインストールと設定(Linux版) この記事では、New RelicのInfrastructureエージェントの導入方法について解説します。手順を説明する前に、よくある疑問に触れていますので、理解を深めてから実際の手順に挑んでいきます。 blog.usize-tech.com 2026.01.14   InfrastructureのUI構成 この画面でInfrastructureの見方を解説します。サーバーやコンテナ、といった基盤全体の状態を俯瞰できます。アプリケーションのパフォーマンスを追うだけでは見えない、ホストレベルのリソース状況やイベント履歴、インベントリ変化などを統合的にチェックできるため、日々の運用監視やトラブルシューティングに欠かせないUIです。 主要部分UI Infrastructureの機能は主要3セクションに分かれています。Hostsはリソース監視、Inventoryは構成管理、Eventsはトラブルシューティングに活用など、それぞれインフラ基盤を観測する上での必要な機能が備わっています。   セクション 概要 Overview インフラUIの主要ページ。 ・ Hosts ：ホストの状態を一覧表示 ・ Kubernetes ：K8sインテグレーションのデータ ・ Network ：ネットワークパフォーマンス監視 ・ Inventory ：構成情報の確認（アップグレードや設定ドリフト） ・ Events ：重要なシステムアクティビティのタイムライン Integrations インフラ統合のテレメトリを表示。 ・クラウドサービス（AWS、Azure、GCP、OCI） ・サードパーティサービス（Apache、Cassandra、RabbitMQなど） Settings システム設定関連。 ・ Alerts ：アクティブなインシデントを含むアラート概要   インフラストラクチャ監視 UI の紹介 | New Relic Documentation An introduction to the New Relic infrastructure monitoring UI pages. docs.newrelic.com   全ホストのサマリを確認したい場合 この画面ではInfrastructure エージェントが導入されたホストのメトリクスデータを確認することができます。 対象画面 利用シーン サマリ情報 最近の負荷変動や異常をすばやく確認したいとき システム情報(CPU/メモリ等) 長期的な傾向や履歴を分析したいとき Network情報 ネットワークのボトルネックや負荷分散の必要性を判断したいとき プロセス情報 高負荷プロセスや異常な動作を特定したいとき ディスク情報 ディスク容量不足やI/O異常を早期に検知したいとき   他のメトリクスを確認したい場合 New Relicでは、調査に必要なさまざまなメトリクスを収集しています。その他のメトリクスを確認したい場合は、画面の赤枠で示したプルダウンメニューから選択できます。執筆時点で確認可能なメトリクス一覧も参考として表で記載します。   New Relicで観測できるメトリクス情報一覧 カテゴリ メトリクス名 説明 CPU CPU (%) CPU全体の使用率   CPU user (%) ユーザープロセスによるCPU使用率   CPU system (%) システムプロセスによるCPU使用率   CPU i/o wait (%) I/O待ちによるCPU使用率   CPU idle (%) CPUアイドル時間の割合   CPU steal (%) 順番待ちしているCPU時間の割合 ロードアベレージ Load average 1 min 直近1分間の平均負荷   Load average 5 min 直近5分間の平均負荷   Load average 15 min 直近15分間の平均負荷 メモリ Memory used (%) メモリ使用率   Memory free (%) メモリ空き率   Memory free bytes 空きメモリ容量   Memory total bytes メモリ総容量   Memory used bytes 使用メモリ容量 スワップ Swap free bytes 空きスワップ容量   Swap total bytes スワップ総容量   Swap used bytes 使用スワップ容量 ディスク Disk free bytes 空きディスク容量   Disk free (%) 空きディスク率   Disk total bytes ディスク総容量   Disk used bytes 使用ディスク容量   Disk used (%) ディスク使用率   Disk utilization (%) ディスク全体利用率   Disk read utilization (%) 読み取り時のディスク利用率   Disk write utilization (%) 書き込み時のディスク利用率   Disk reads per second 1秒あたりのディスク読み取り回数   Disk writes per second 1秒あたりのディスク書き込み回数 アプリケーション Application response time アプリケーション応答時間（APM有効時のみ）   Application throughput アプリケーションのスループット（APM有効時のみ）   Application error rate アプリケーションのエラー率（APM有効時のみ）   個々のホストを確認したい場合 全ホストを一覧で確認し、特定のホストだけリソース使用率が高いことがわかったため、ホスト数を絞りたい場合などは、画面右上の 「 Filter 」 をクリックして対象ホストを絞り込むことができます。   個々のホストを1つの画面で確認したい場合 特定の1つのホストだけを確認したい場合は、Summary欄より該当のホストをクリックすることで、そのホストに関する観測データを確認することができます。 1.画面下部「Summary」欄にホスト情報が表示されています。表示したいホストをクリックします。 2.該当のホスト情報が表示されます。この画面でメトリクスや、ログなどを確認することができます。   インフラストラクチャホストUI | New Relic Documentation For New Relic infrastructure monitoring, use the Hosts UI page to view the most important metrics from across your serve... docs.newrelic.com   インベントリUI この画面では、Infrastructureエージェントがインストールされたホスト内のOSやアプリケーションの構成要素、インストールされているパッケージなどを、ホストにログインせずに確認できます。構成情報はホストから送信される最新データが即座にUIに反映されます。ホストがシャットダウンしたりエージェントが停止してNew Relicへのデータ送信ができなくなった場合でも、最後に報告されたインベントリ情報は最大24時間UIに保持されます。 利用シーンとしては以下の例が挙げられます。 ・セキュリティ対策：脆弱性対応後、古いパッケージが残っていないか ・バージョン比較   ：本番環境とテスト環境のパッケージや設定ファイルの差異を比較 ・構成管理            ：ミドルウェアやサービスのインストール状況を把握   インフラストラクチャ インベントリ UI ページ | New Relic Documentation Use the New Relic infrastructure inventory page to monitor package and kernel versions across your entire architecture. docs.newrelic.com   イベントUI システムやホストの重要なアクティビティをリアルタイムで確認できます。インフラストラクチャーの変更やアクティビティを時系列で表示し、特定の時間に発生したイベントを一元管理できます。ホストごとにイベントを検索できますが、 画面右上で指定した時間範囲内のイベントのみが表示 されます。広範囲を調べたい場合は、時間範囲を拡大する必要がありますのでご注意ください。 利用シーンとしては以下の例が挙げられます。 ・障害の原因特定               ：スパイクや異常値が発生した時間帯に、どんなイベントがあったかを確認 ・変更履歴の監査               ：インベントリ（Kernel、Metadata、Packages、Services、Sessions）の変更履歴を記録 ・ユーザーセッションの監視：ユーザーの接続・切断イベントを記録し、セキュリティや運用状況を把握 ・構成変更の影響分析         ：設定変更やパッケージ更新などのイベントと、CPUやメモリなどのメトリクスを比較     インフラストラクチャ イベント UI ページ | New Relic Documentation The New Relic infrastructure events UI page gives you a unified timeline of important changes and events in your archite... docs.newrelic.com   Infrastructure 機能を使いこなすために 大規模かつ動的に変化する環境を監視するために、すべてのホスト（DB・Webサーバーなど）へエージェントをインストールし、単一のダッシュボードでデータを一元的に確認することで、チーム間で情報を共有しやすくなります。また、アラート条件の設定やクラウドインテグレーションの有効化といったベストプラクティスにより、オブザーバビリティを迅速に向上させることができます。継続的に改善を繰り返すことで、障害発生時の原因特定や復旧までの時間（MTTR）を大幅に短縮し、クラウド・オンプレミスに関わらず、運用データを統合的に管理できるよう、以下指針がまとめられています。 項目 概要 1. Infrastructureエージェントを環境全体にインストール すべてのホスト（DB、Webサーバーなど）にエージェントを導入し、タグやカスタム属性で分類。 2. EC2インテグレーションを設定 AWSタグとメタデータを自動インポートし、タグでフィルタリングやアラート設定を実現。新しいインスタンスも自動追加。 3. インテグレーションを有効化 AWSサービスやホスト上のアプリを監視。事前設定されたダッシュボードを利用可能。 4. ホストグループビューの作成 エンティティフィルターでグループ化し、稼働ステータスを色分け表示し、問題箇所を迅速に特定。 5. アラート条件を作成 タグベースで条件を作成し、新しいホストにも自動適用。 6. InfrastructureデータをAPMデータと統合 Application Performance Monitoring(APM)とInfrastructureを並べて表示し、根本原因を迅速に特定。サービスマップでアプリとインフラの関連性を可視化。 7. メトリクスとイベントを活用 カスタムダッシュボードを作成。チームで共有し、インフラとアプリの健全性を一元管理。 8. エージェントを定期的に更新 新機能や改善を活用するため、最新バージョンへの更新を推奨。   Infrastructureモニタリングのベストプラクティスガイド | New Relic Documentation Best practices to make dynamic infrastructure and server monitoring even easier with New Relic. docs.newrelic.com   さいごに この記事では、New Relic Infrastructure の主要な機能について解説しました。New Relic は多機能なプラットフォームであり、インフラ監視ひとつをとっても観測できるデータは多いです。そのため、まだ取り上げきれていない機能や、より深く掘り下げられるトピックも数多く存在します。今後は、実際の運用シナリオで役立つ設定例や、ダッシュボード活用方法、アラートチューニング、クラウドサービスとの統合など、実践的な情報も解説していきます。引き続き、みなさまの環境運用に少しでも貢献できれば幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

本記事は 新人ブログマラソン2025 1/22付の記事です。 みなさん、初めまして。２０２５年度に入社した新人の杉山です。 AWS歴はまだまだ浅い私ですが、資格勉強やハンズオン、そして実際の案件対応を通じて、日々学習に励んでいます！ 今後も、学んだことや気づいたことなどをブログで発信していきますので、AWS初心者の奮闘記にぜひお付き合いください！ 今回の記事では、私が実際に体験したAmazon SNS(Simple Notification Service)のサブスクリプションが、誤って削除されてしまう原因と、その対処法についてご紹介します。 Amazon SNSを今後使用される方々の参考になれば幸いです！！ はじめに 事の発端は2025年11月。とある案件で Amazon CloudWatch ＋ Amazon SNS によるアラーム通知を構築することになり、検証環境で動作確認を行っていました。 しかし、ある日を境に 通知メールが一切届かなくなる という事態が発生!! 不審に思い、コンソールでサブスクリプションの状態を確認してみたところ、なんと、IDが” 削除済み ”となっていました。 「なぜ削除されたのか？」と原因を調べた結果、あるリンクを誤ってクリックしてしまったことが原因 であることが判明したのです。 そのリンクとは…？ 通知が消える悲劇の原因 Amazon SNSでは、サブスクリプション登録時や通知メールに “unsubscribe（登録解除）リンク” が自動的に挿入されています。 これはAWSの仕様で、ユーザーがいつでも解除できるようにするための仕組みです。 このリンクをクリックすると、以下のような画面に遷移し、サブスクリプションが登録解除されます。   問題は、このリンクを 誤ってクリック してしまうこと。 クリックすると、SNSトピックからサブスクリプションが削除され、通知メールが届かなくなります。 さらに、確認画面や警告はほとんどなく、ワンクリックで解除されるため、意図せずに登録解除してしまうケースも多いのです。 では、意図しない登録解除を避けるためにどうやってこの解除リンクを無効化するのか？ 次の章では、解除リンクを無効化するための具体的な方法を詳しく解説します！ unsubscribeリンクを無効化する方法 設定は 「SNSサブスクリプションの作成」 、 「”Confirm subscription”のリンク登録」 の２ステップで行います。 SNSサブスクリプションの作成 対象のトピック画面で「サブスクリプションの作成」をクリックします。 詳細を入力した状態で「サブスクリプションの作成」をクリックします。   作成が完了すると、IDが”保留中の確認”のサブスクリプションが表示されます。   ”Confirm subscription”のリンク登録 サブスクリプションの作成後、「AWS Notification – Subscription Confirmation」というメールが届きます。 ”Confirm subscription”のリンクをクリックしないでください！！ 代わりに”Confirm subscription”のリンクを 右クリックしてコピー します。 次にコンソールに戻り、「サブスクリプションの確認」をクリックします。 先ほどコピーしたURLをペーストし、「サブスクリプションの確認」をクリックします。     URLは以下の形式です。 https://sns.<リージョン>.amazonaws.com/confirmation.html?TopicArn=arn:aws:sns:<リージョン>:<AWSアカウントID>:<トピック名>&Token=<トークン値>&Endpoint=<メールアドレス> Outlook上でURLをコピーする際、Microsoft Defender for Office 365の「Safe Links」機能が有効になっている場合は、リンクがセキュリティ保護のために書き換えられるため、元のURLにデコードする必要があります。 すると、サブスクリプションのIDが変更され、ステータスが” 確認済み ”になります。 では、本当にunsubscribeリンクが無効化されたのか？次の章で動作確認を行います！ 動作確認 再作成したサブスクリプションに登録したメールアドレス宛に、テストメッセージを送信してみましょう。 コンソール上で、画面右上にある 「メッセージの発行」 をクリックします。 次に、「エンドポイントに送信するメッセージ本文」 に任意の文字列を入力し、画面右下の 「メッセージの発行」 をクリックします。   すると、テスト用のメールが届きます。メール本文には、従来通り unsubscribeリンク が含まれています。 ここで、そのリンクをクリックしてみると…   サブスクリプションが解除されないことを確認できました！ さいごに 今回の記事では、Amazon SNSの通知メールに含まれる「unsubscribeリンク」が誤クリックによって通知停止を引き起こす問題と、その対策について解説しました。 この方法を実施することで、誤クリックによる通知停止のリスクを大幅に減らすことが可能です。 今回の方法をぜひ試して、「通知が消える悲劇」からシステムを守りましょう！ 最後まで読んでいただきありがとうございました！ 参考サイト SNSトピックのunsubscribeの無効化設定 - Qiita はじめに 今回業務の中でSNSのサブスクリプションを誤って解除してしまうのを無効化したいという要件があったため、調べた中で作り直しが必要と記載のある記事が多く、作り直さなくても設定できたので、メモとして残そうと思います。 unsubscri... qiita.com

AWS を学んでいて、思わず 「 Gatewayと名の付くサービス多くないか？ 」 と感じたことがありました。 Direct Connect Gateway、Transit Gateway、API Gateway、NAT Gateway、ゲートウェイ型 VPC エンドポイントなど。 AWS SAP(Solutions Architect Professional）の勉強中に混乱したのが正直なところです。 AWSのGateway系サービスを主題に、Azureとの比較を通して役割を整理しました。 AWSを主に扱っている方には、Azureと比べることでGatewayと名の付くサービスの多さを感じてもらいたいです。 Gatewayとは 一般的なIT用語としてのゲートウェイは、異なるプロトコル間の通信を中継する仕組みを指します。 ネットサーフィンしてると、ゲートウェイを解説するSCSKのサイトを見つけました。 ゲートウェイとは｜IT用語辞典｜SCSK IT Platform Navigator ゲートウェイ（Gateway）とは、英語で「出入口」を意味する言葉。異なる通信プロトコルを使用するネットワーク間を中継する機器または仕組みを指す。 www.scsk.jp 一方、AWSにおいてのGatewayは、必ずしもプロトコル変換を行うわけではなく、 「ネットワーク境界の入口」くらいの意味で使われていそうです。（※個人の意見） 比較表 AWSのサービスとAzureを比較しました。 一対一対応ではないですが、概念的に近いサービスをまとめてます。 AWSサービス AWSサービスの概要 Azureサービス Direct Connect オンプレ環境からAWSへ専用線ネットワークを提供 ExpressRoute Direct Connect Gateway Direct Connect接続を複数のリージョンのVPCで共有 ExpressRoute Global Reach Transit Gateway  複数のVPC間・オンプレ間のルーティングを集中管理 Virtual WAN Site-to-Site VPN  オンプレ環境や他クラウドのネットワークとAWSの通信をIPSecを使用しセキュアに通信 Azure VPN Gateway ゲートウェイ型 VPC エンドポイント S3とDynamoDBなどが対象のエンドポイント Azure Vnet Service Endpoint インターフェイス型 VPC エンドポイント 多くのサービスが対象でプライベート接続を行う際のエンドポイント Private Endpoint API Gateway REST/HTTP/WebSocket API のフロントドア API Management AWS NAT Gateway プライベートサブネット内のインスタンスからインターネットへの接続 Azure Nat Gateway   おまけ よくでる構成図 AWS SAPでよく出てくるDirect ConnectとTransit Gatewayの簡易的な構成図を作ってみました。 組み合わせで出題されてたイメージで、印象に残ってます。               AzureもNAT Gatwayが必須に Azure Nat Gateway について。 AzureではこれまでNAT Gatewayを作成しなくてもインターネット通信が可能であり、便利だなと思ってました。 自動で azure-default-snat なるものが作成されていたようです。 詳しくはこちら 【Azure】Azure NAT Gateway のすゝめ 昨今はAzure仮想マシンから外部SaaSのデータ連携をするケースが多くあり、SaaS側のセキュリティ対策として特定のグローバルIPアドレスのみ通信許可することがあります。通常、仮想マシンに用意されているグローバルIPアドレスはAzure側で作成されたグローバルIPアドレスであり再起動やAzure側の任意のタイミングで意図せず変更されてしまうことから、AzureNATGatewayを利用することでグローバルIPアドレスを固定可能となります。 blog.usize-tech.com 2024.01.26 しかし廃止となり、2025年10月以降にはAzure NatGateway等の明示的なアウトバウンド構成が推奨されたようです。 https://azure.microsoft.com/ja-jp/updates?id=default-internet-outbound-access-for-simplified-node-communication-batch-pools-without-public-ip-addresses-will-be-retired-on AWSの勉強してて驚いたAzureニュースでした。   参考文献 AWS と Azure のネットワーク オプションの比較 - Azure Architecture Center Azure と AWS のネットワーク オプションを比較します。 クラウド仮想ネットワーク、クロスプレミス接続、DNS 管理などについて比較します。 learn.microsoft.com AWS サービスや Azure サービスと Google Cloud を比較する  |  Get started  |  Google Cloud Documentation docs.cloud.google.com

ブログリレー 前回の記事 では、バックエンドのあれこれを齋藤さんが記事にしてくれましたが、本日はフロントエンド編ということで、AWSパラメータシート自動生成ツールのGUIをどのような技術を使用して実現したかをご紹介できればと思います！ フロントエンド概要 フロントエンドは下記のような流れでバックエンド（パラメーターシート出力）に処理が引き継がれます。 上記処理のうち、本記事のフロントエンドは「GUI」と「GUIを提供するサーバー」部分を担当しています。 使用した技術 フロントエンド実現のために使用した主な技術とその役割は下記の通りです。 技術 役割 JavaScript クライアント側、サーバーサイド側のロジックを記述するために使用した言語 Node.js  JavaScriptの実行環境であり、アプリケーション全体の実行基盤 Express.js WebサーバーおよびREST APIなどのサーバーサイド側の機能を提供してくれるWebフレームワーク HTML5 + CSS3 画面構造とデザイン フロントエンドは、クライアント側、サーバーサイド側も一貫してJavaScriptを使用して実装しています。 サーバーサイド側の開発として、Ruby + Rails や Python + Django といった組み合わせもある中で、JavaScript + Node.js を使用した理由としては、以下の通りです。 案件で JavaScript を触る機会があり慣れている よく耳にする組み合わせでなんかかっこいい しかし、よくよく調べるとよく耳にする理由がありました。それについては以降で説明していきたいと思います。 Node.js Node.jsとは？ そもそもNode.jsとは何者かというと、 JavaScriptをサーバー上で実行するための開発環境 です。 元々、JavaScriptという言語は他の言語と異なり、ブラウザ上で動作する言語であり、ローカル（OS上）環境では動作させることができない言語でした。 よって、ブラウザ上でしか動作しない JavaScript ではローカル環境にあるファイルを読みにいくことができないという問題がありました。 その制限を取っ払ってくれたのが、Node.jsという訳です。 Node.jsの登場のおかげで、 クライアント・サーバーサイドの両者を同一の言語で開発 することができるようになりました。 Node.jsの特徴 Node.jsの特徴としては、主に以下の3つが挙げられます。 1. ノンブロッキングI/O処理 前のタスクが完了していない状態でも次のタスクを開始でき、 非同期での処理を実現 している。 そのため、大量のアクセスがあっても対応が可能である。 2. シングルスレッドによる処理 プログラムを実行する際に、1つずつ処理を行う 。 一般的にシングルスレッドだと大量のアクセスがあった場合に制御することが難しくなるが、ノンブロッキングI/O処理によって、多くのアクセスがあってもリアルタイムでレスポンスが可能になる。 3. 豊富なライブラリ サーバーサイドアプリケーション、デスクトップアプリケーション、コマンドラインツールなどの幅広い用途で使用されるため、非常に多くのライブラリがある。 npmというパッケージ管理ツールを使用することにより、膨大なライブラリを簡単にインストール・管理することができる。 これらの特徴から、Node.js + JavaScript は 大量の同時処理をさばけ、なおかつ様々な目的で使用できる汎用的な技術基盤 として人気があるという訳です。 Express.js ここまでで、Node.jsを使用した理由や用途は理解できたかと思いますが、あくまでもNode.jsはサーバーサイド側でJavaScriptを実行できるようにした実行環境であり、ただの基盤です。 フロントエンドを作成する上では、基盤の上に実際の機能を作成してあげる必要があります。 その実際の機能は一から作る必要はなく、既に用意されたひな形から作成することができます。 それにあたるのが、Express.jsです。 Express.jsとは？ Express.jsとは、 Node.jsのための軽量で柔軟なWebアプリケーションフレームワーク です。 フレームワークとはひな形とも言い換えることができ、様々なひな形が用意されています。 例えば、機能開発が簡単に実装できる以下のようなひな形が用意されています。 ルーティング機能 ユーザーが特定のURLにアクセスした際に、 どのようなレスポンス（応答）を返すかを定義 することができる。 例えば、ユーザが / にアクセスしたら、トップページを表示する、/download/file.xlsx にアクセスしたら、ファイルをダウンロードするなどがある。 REST API機能 フロントエンド（ブラウザ）からのリクエストを受け取り、 Web上でデータをやりとりするための操作を定義 することができる。その操作には以下のものがあり、これらを定義することができる。 HTTPメソッド 操作 GET リソースを取得する POST リソースを作成する PUT 指定したIDのリソースを更新する DELETE 指定したIDのリソースを削除する 静的ファイルの配信 静的ファイル（HTML、CSS、JavaScript、画像など）をユーザーに配信することができる。 また、HTTPヘッダーによるキャッシュ制御も可能で、同じファイルへの再リクエスト時のレスポンス時間を短縮できる。 どこに使用したの？ では、フロントエンド実現にあたってどこに活用したのかというと下記の通りです。 機能 使用箇所 ルーティング機能 トップページの表示 ファイルのダウンロード REST API機能 AWSリソース一覧取得 Excel生成リクエスト（バックエンドへのトリガー） 静的ファイルの配信 HTML/CSS/JavaScriptファイルの配信 苦労した点 リソースごとに異なるJSONファイル フロントエンドでは、AWSのリソースの詳細情報を表示するために、AWS CLIコマンドを実行し、リソースの一覧を取得してきています。その一覧情報の構造が、リソースによって異なり、リソースごとに取得する情報を定義してあげることが苦労しました。 例： EC2インスタンスの場合： {   “Reservations”: [     {       “Instances”: [         { “InstanceId”: “i-xxxxx”, “State”: {…} }       ]     }   ] } S3バケットの場合： {   “Buckets”: [     { “Name”: “my-bucket”, “CreationDate”: “…” }   ] } このように、同じ「リソース一覧を取得する」という処理でも、項目名やJSONファイルのネスト構造の深さが異なります。そのため、すべてのリソースに対して、どのキーからデータを取り出すか、IDとして何を使うかを個別に定義する必要がありました。 一方で、共通化できる部分は共通化し、できるだけ同様のコードで詳細情報を取得できるようにしてあげました。やはりコードの最適化には、AIを使用してあげるのが効率よかったです。 特殊なリソースの取得フロー 一般的なリソースの場合、取得フローは下記のようになります。 サービス選択 ⇒ リソース一覧から出力したいリソースを選択 ⇒ プレビュー画面表示 ⇒ Excel 出力 しかし、サービスの中には一発で一覧を取得できないサービスがあります。 例えば、ELBのターゲットグループの場合、ELBに紐づくターゲットグループを取得する必要があるため、まず最初にELBの一覧を取得し、その後にターゲットグループを取得する必要があります。よって、一覧の取得フローとしては下記のようになります。 サービス選択（ELBターゲットグループ）⇒ リソース一覧から出力したいリソースを選択（ELB）⇒ リソース一覧から出力したいリソースを選択（ターゲットグループ）⇒ プレビュー画面表示 ⇒ Excel 出力 このようにサービスによっては、中間ステップが存在するものもあるため、コードを共通化することができず、苦労しました。 まとめ 本記事では、AWSパラメータシート自動生成ツールのGUIであるフロントエンドで使用した技術について簡単に紹介しました。 実は、この取り組みはフロントエンドのアプリケーションを作成するつもりはなく、バックエンドのJSONファイルをパラメータシートに変換するアプリケーションのみを構築予定でした。しかし、使用するユーザー目線で考えると、やはりGUIがほしいということになり、開発に取り組みました。 普段はインフラ構築を担当する部署のため、初めて触れる技術が多く、開発には3~4か月ほどかかってしまいましたが、この取り組みを経てアプリケーションの知識をつけることができ、フルスタックエンジニアへと一歩近づいた気がします。 皆さんもぜひ、息抜きもかねて普段とは異なる分野の技術に触れてみるのはいかがでしょうか？ というわけで、私の投稿は以上です！ 次回は、AWSパラメータシート自動生成ツールを使ってみたということで、藪内さんにバトンタッチしますので、ぜひそちらも閲覧いただければと思います。

こんにちは、ひるたんぬです。 電子レンジ、生活の中に当たり前のように溶け込んでいる存在ですよね。 でも、「レンジ」とはどこからやってきた要素でしょうか？ 発明元のアメリカ（英語）でも”microwave (oven)”であり、「レンジ」の要素は見当たりません。。 歴史を辿るとヒントがありました。 電子レンジの加熱原理は、アメリカのレイセオン社によって、レーダー 装置 の実験中にお 菓子 がレーダーのマイクロ波によって 溶 けていることに気が付き、これにヒントを得て、 マグネトロンを使った調理器「レーダーレンジ」として製品化されました。 引用：一般社団法人 日本電機工業会「 電子レンジの歴史 」 「電子レンジ」という言葉もここから生まれたのかも知れないですね¹。 ¹ 「レンジ」の由来やその意味について、明確な文献を見つけることはできませんでした。日本ではその前から「ガスレンジ（ガスコンロ）」という名称が広がっており、電気的に加熱料理できる調理器具として「電子レンジ」とつけられたのではないか、という説もあるようです。 さて、今回はCloudFrontの機能の一つ、Lambda@Edgeにおけるログについて少し紐解いていきます。 やりたいこと Amazon CloudFrontを使っており、その中でLambda@Edgeを使用しています。 ここで、Lambda@Edgeから出力されるログについて、予めログの有効期限を設定しておきたい場合を考えます。 既定では… AWSの公式ドキュメントなどにも記載がありますが、Lambda@Edgeでは関数が実行された場所に最も近いAWSリージョンにロググループが自動で作成され、ログイベントが保管されます。 チュートリアル: 基本的な Lambda@Edge 関数 (コンソール) を作成する - Amazon CloudFront Amazon CloudFront で実行される基本的な Lambda@Edge 関数をコンソールを使用して作成する方法について説明します。 docs.aws.amazon.com エッジ関数のログ - Amazon CloudFront Amazon CloudWatch Logs を使用して、Lambda@Edge 関数と CloudFront Functions の両方のエッジ関数のログを取得してください。 docs.aws.amazon.com また、自動で作成されるロググループは有効期限が未設定（失効しない）のため、明示的に削除しないとログが残りつづけます。 コンプライアンスや規約上、ログはすべて保管する必要がある場合などはこの設定でも問題はありませんが、ログイベントの保存にも料金は発生します。 2026年1月現在では、東京リージョンにおいて1GBあたり$0.033の保存費用が発生します。 課題点 以上のことから、Lambda@Edgeでログを保管する場合、デフォルトの設定では無期限でログが残り続け、主に費用面での負担が増大しかねない点をご説明しました。 では、予めロググループを作成し、ロググループに対して有効期限を設定したいのですが…それには Lambda@Edgeがどこで実行されうるのか（どこのAWSリージョンにログが出力されうるのか） 、を知る必要があります。 Lambda@Edgeが実行される場所 これを理解するためには、Amazon CloudFrontについても知る必要があります。 CloudFrontは「エッジロケーション（≠ リージョン）」と呼ばれる場所でキャッシュサーバーとして機能しています。 エッジロケーションにてキャッシュヒットしなかった場合は「リージョン別エッジキャッシュ（≠ リージョン）」にアクセスし、それでもヒットしなかった場合はオリジンからコンテンツを取得します。 引用： AWS Black Belt Online Seminar – Amazon CloudFront 基礎編(P. 15) そして、Lambda@Edgeは、上記の「リージョン別エッジキャッシュ」にデプロイされています。 CloudFront Functionsについては「エッジロケーション」にデプロイされています。 そのため、CloudFront Functionsの方が実行時間が早い一方、キャッシュ容量が少ないためコード容量の制限が厳しいものだと分かります。 パソコンのCPUにおけるL1・L2キャッシュとイメージすると少し分かりやすいでしょうか…？ 引用： AWS Black Belt Online Seminar – Amazon CloudFront (CloudFront Functions / Lambda@Edge 編) (P. 17) では、その「リージョン別エッジキャッシュ」はどこにあるのでしょうか？ 2026年1月現在では13個所に設定されています。 米国東部 (バージニア北部) – us-east-1 米国東部 (オハイオ) – us-east-2 米国西部 (北カリフォルニア) – us-west-1 米国西部 (オレゴン) – us-west-2 アジアパシフィック (ムンバイ) – ap-south-1 アジアパシフィック (ソウル) – ap-northeast-2 アジアパシフィック (シンガポール) – ap-southeast-1 アジアパシフィック (シドニー) – ap-southeast-2 アジアパシフィック (東京) – ap-northeast-1 欧州 (フランクフルト) – eu-central-1 欧州 (アイルランド) – eu-west-1 欧州 (ロンドン) – eu-west-2 南米 (サンパウロ) – sa-east-1 明示的な一覧は公式サイトからは見ることができなかったので、以下の資料から読み取りました。 （すべてAWSが提供する資料です） Amazon CloudFront 用のリージョン別エッジキャッシュを発表 サービスアップデート Edge Networking Services 編 └ P.8 Amazon CloudFront が AWS の欧州 (アイルランド) リージョンで新しいリージョン別エッジキャッシュを開始 また、CloudFrontのユーザーマニュアルからもLambda@Edgeのサービスにリンクされたロールの使用がサポートされているリージョンにて、同様のものを挙げています。 デベロッパーガイド – Amazon CloudFront └ P. 935（「Lambda@Edge サービスリンクロールでサポートされている AWS リージョン 」）にリージョン一覧の記載があります。 以上のことから、すべてのAWSリージョンでリージョン別エッジキャッシュが提供されているわけではないことが分かりました。（例えば、大阪リージョンでは提供されていないことが分かりやすいかと思います。） 結論 以上のことから、予めロググループを作成し、ロググループに対して有効期限を設定したい場合は、上述しました13個のリージョンに対して、所定の命名規則や設定に沿ったロググループを作成すれば良い、ということになります。 Lambda@Edgeにおけるロググループ名の規則については、以下をご参照ください。 エッジ関数のログ - Amazon CloudFront Amazon CloudWatch Logs を使用して、Lambda@Edge 関数と CloudFront Functions の両方のエッジ関数のログを取得してください。 docs.aws.amazon.com なお、今後リージョン別エッジキャッシュが拡大することも考えられますので、先んじて他リージョン（大阪リージョンなど）でロググループを作成しておく、というのも一手かと思われます。 ロググループの作成自体にはAWSの利用料金は発生しません。 一方、日本国内にアクセスを限定しており、海外からのアクセスは遮断している場合などについては、更に事前に作成するリージョンを絞ってよい（東京リージョンのみ、など…）かと思います。   終わりに 今回は、CloudFrontにLambda@Edgeを組み合わせて使用する場合において、どのリージョンにロググループが必要なのか（≒ Lambda@Edgeの実行に関連するAWSリージョンがどこなのか）調査しご紹介しました。 公式ドキュメントなどでも言及がほとんどされておらず情報収集に苦戦しましたが、参考になる方がいらっしゃいましたら幸いです。 余談ですが、「レンジでチン」という言葉は死語になってしまう日もくるのでしょうか。 テレビにおける「チャンネル回す」も死語になりつつあるようです… 最近の電子レンジは、「ピー」という音がなったり、おしゃれな音楽が流れるようです。「レンジでピー」…？