AWSの指摘を、
そのまま作業できる
指示に。

1通のメールに、判断と作業に必要なことをすべて書きます。AWSに詳しくない担当者でも、上から順に読んで作業できるようにしています。

対象：web-sg（sg-0a1b2c3d4e5f60789）22番 ← 0.0.0.0/0／ap-northeast-1
重要度：緊急　期限：本日中（2026/10/14 23:59）

何が起きているか：
  NET-01（ネットワーク）の確認で1件が見つかりました。
  SSH（22）やRDP（3389）が世界中に開いていると、総当たり攻撃や脆弱性を突いた侵入を常に受ける状態になります。
  2026/10/14 10:02、IAMユーザー「tanaka」がAuthorizeSecurityGroupIngressを実行しました（ap-northeast-1、接続元IP 198.51.100.24）。

手順：
  1. EC2コンソール → セキュリティグループ → 対象 → 「インバウンドルールを編集」
  2. 該当ポートのソースを 0.0.0.0/0（::/0）から会社の固定IPに変更、またはルールを削除
  3. （推奨）SSHの代わりにSystems Managerのセッションマネージャーで接続する
  CLI：
    aws ec2 revoke-security-group-ingress --region ap-northeast-1 --group-id sg-0a1b2c3d4e5f60789 --ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges=[{CidrIp=0.0.0.0/0}]'

確認方法：
  インバウンドルールに 0.0.0.0/0・::/0 からの該当ポートがない
戻し方：
  削除したルールを再追加する（非推奨）

詳細・操作（社内から開けます）：https://（お客様の画面のURL）/wo/WO-20261014-003
作業指示 WO-20261014-003／発生 2026/10/14 10:03／元の検出 NET-01

同じ問題が続けて見つかっても、メールは1通にまとめ、画面の履歴に追記します。AIによる説明（任意）を使う場合も、事実の欄とは分けて「AIによる説明」として載せます。

本システムは、お客様のAWSアカウントの中（東京リージョン）に置きます。6種類の入口で見つけた問題を1か所で作業指示にまとめ、メールで送ります。管理者が作業して画面で「完了した」を押すと、同じチェックをその場でやり直して結果を確かめます。

AIを有効にすると、届いた検出ごとに「何が起きた可能性があるか」「まず何を確かめるか」「どう直すか」を、AIがその場の状況に合わせて日本語で書き添えます。定型文では書ききれない個別の事情まで、担当者がすぐにつかめます。事実の確認と最終的な判断は本システムが行い、AIは説明の役割に限ります。

AIを使うときの流れ

メールの違い（例）

何が起きているか：
  2026/10/14 02:13、GuardDutyが「CryptoCurrency:EC2/BitcoinTool.B!DNS」を検出しました（GuardDutyの重要度 8.0）。
  問い合わせ先ドメイン：xmr.pool.example.com

手順：
  1. GuardDutyコンソールで検出を開き、内容（対象、接続元、操作）を確認する
  2. 心当たりがない場合：EC2の停止や削除をする前に、EBSのスナップショットを取得する（証拠の保全）
  3. セキュリティグループを、通信をすべて止める隔離用のものに切り替える
  4. EC2のIAMロールの権限が悪用されていないかCloudTrailで確認する
  5. 心当たりのある操作（管理者の作業、脆弱性診断など）なら「確認済み（問題なし）」で閉じる

【AIによる説明】（AIが作成した参考情報です。事実は上の欄を確認してください）
  何が起きた可能性があるか：
    web-01 が、暗号資産の採掘でよく使われるドメインに問い合わせています。
    第三者が入り込み、採掘のプログラムを動かしている可能性があります。
  まず確認すること：
    1. EC2コンソールの「モニタリング」で、CPU使用率が急に上がっていないか確認する
    2. セッションマネージャーで接続し、top コマンドで見慣れないプロセスがないか確認する
  対応手順：
    1. EBSのスナップショットを取得してから、隔離用のセキュリティグループに切り替える
    2. 見つけたプロセスとファイルを記録し、EC2を作り直すか相談する
  誤検知の見分け方：
    社内で暗号資産に関する検証をしていなければ、誤検知の可能性は低いと考えられます。

右はAIの出力の例（サンプル）です。実際の文面は検出の内容によって変わります。AIの欄は、事実の欄とはっきり分けて載せます。

安全の仕組み

事実は本システムが書きます

対象、日時、接続元IP、CVE番号などの事実は本システムが書きます。AIの出力に、入力にないCVE番号やリソースIDが含まれていれば、その出力は使わずに定型文で送ります。

AIは判断も操作もしません

重要度と期限は本システムが決めます。AIがAWSの設定を変えることはありません。削除や停止を伴う操作が書かれていれば、注意書きを付けます。

秘密情報は渡しません

アクセスキーIDやセッションの情報は、AIに渡しません。攻撃者が仕込んだ文字列（ドメイン名など）に書かれた命令には従わないよう、AIに指示しています。

日本国内で処理します

Amazon Bedrock の日本国内の推論（東京・大阪）を使い、データは日本国内だけで処理されます。

AIが使えなくても届きます

AIが応答しない、出力が使えない、月の上限を超えた、といった場合も、作業指示は定型文で必ず届きます。

使うかどうかを選べます

初期状態ではオフです。画面の設定でいつでもオン・オフを切り替えられます。

費用と始め方

• AIが書くのは、GuardDuty の検出の作業指示を作るとき、Inspector の脆弱性の組み合わせが変わったとき、定型文のない Security Hub の指摘の作業指示を作るときです。「異常なし」のときは使いません。
• モデルは Claude Haiku 5.5（高速・低価格のモデル。画面で変更できます）。費用の目安は1回あたり1円未満です（検出の内容の量によります。Amazon Bedrock の料金がかかります）。
• 月の上限回数（初期値500回）を超えた月は定型文で送るため、費用の上限を決めておけます。上限まで使っても、月数百円程度の目安です。
• 始めるときは、Amazon Bedrock でモデルを使える状態にしてから、画面の「設定」で「AIによる説明を使う」をオンにします。

作業指示は、終わるまで本システムが追いかけます。操作がなければ期限の前日と期限を過ぎたときに再送し、「完了した」を押されたら本当に直ったかを確かめます。

送信時刻と期限の日数は画面で変えられます。他の人や業者に依頼した作業は「依頼中」として依頼先と依頼先の期限を記録でき、再送メールと一覧に表示されます。

Web画面は、会社の固定IPからだけ開けます。メールのリンクから作業指示を開き、ボタンで結果を伝えます。画面を開いただけでは状態は変わりません。

対象：web-sg（sg-0a1b2c3d4e5f60789）22番 ← 0.0.0.0/0／ap-northeast-1
重要度：緊急　期限：本日中（2026/10/14 23:59）
何が起きているか：
  NET-01（ネットワーク）の確認で1件が見つかりました。
  SSH（22）やRDP（3389）が世界中に開いていると、総当たり攻撃や脆弱性を突いた侵入を常に受ける状態になります。
  2026/10/14 10:02、IAMユーザー「tanaka」がAuthorizeSecurityGroupIngressを実行しました（ap-northeast-1、接続元IP 198.51.100.24）。

手順：
  1. EC2コンソール → セキュリティグループ → 対象 → 「インバウンドルールを編集」
  2. 該当ポートのソースを 0.0.0.0/0（::/0）から会社の固定IPに変更、またはルールを削除
  …

このほかに、Security Hub の不合格のコントロールごとに「対処が必要」「厳選チェックで対応」「判断が必要」「対処不要」の判定と理由・手順を示す「Security Hub」画面、月ごとの集計（発生件数、期限内の完了率、平均対応日数）を表示・CSVで保存できる「報告」画面、送信先や期限の日数を変える「設定」画面があります。設定の変更は前後の値が履歴に残ります。

GuardDuty・Inspector・Security Hub の検出に加えて、本システムが独自に2種類のチェックを行います。どれも読み取りだけで、設定は変えません。

Trusted Advisor の「セキュリティ」に赤で出る項目の多くは、Security Hub のコントロールの不合格です。本システムはコントロールごとに「対処が必要」「厳選チェックで対応」「判断が必要」「対処不要」を判定し、理由と手順を付けます。対処が必要なものだけをメールで届け、ほかは画面で判断の基準と、表示から外す手順を確認できます。

AWSの設定を変えません

確認は読み取りの権限だけで行います。例外は、導入時にお客様が許可した場合に、動いていないGuardDuty・Inspector・Security Hub・Configを有効にすることだけです。

画面は会社からだけ開けます

Web画面は会社の固定IPからの接続だけを受け付けます。別のサイトからの操作の送信も拒否します。

秘密情報は取得しません

EC2の中のチェックでは、パスワードのハッシュ、秘密鍵、設定ファイル中のパスワードは読み取りません。送るのは判定結果と公開鍵の指紋などだけです。

偽の通知で作業指示は閉じません

本システムの内部の結果には確認用の記録を付け、本システム以外が送った「問題なし」の通知は処理しません。

AIは使うかどうかを選べます

初期状態ではオフです。使う場合は日本国内で処理するAmazon Bedrockのモデルを使い、事実の欄とは分けて載せます（AIによる説明）。

導入と撤去はスタック1つ

部品はすべてCloudFormationのスタック1つにまとまり、削除すれば本システムが作ったものは消えます。

1. テンプレートをアップロード

   CloudFormationのコンソールで、テンプレートファイルを1つ指定します。AWS CLIやS3の準備は要りません。

2. 4つを選ぶ

   画面を開ける会社の固定IPと、GuardDuty・Inspector・Security Hub（Config）が動いていない場合に有効にしてよいかを選びます。

3. メールを設定

   Web画面で送信先とSMTPサーバを入力し、テストメールが届くことを確かめます。

4. 初回の現状診断

   1時間以内に自動で始まり、見つかった作業指示が重要度の高い順に1日5通ずつ届きます。

• 攻撃を止めたり、設定を自動で直したりはしません。作業指示に沿った作業は管理者が行います。
• 本システムは東京リージョンに置きます。東京以外のリージョンのGuardDutyの検出は1時間ごとに確認します。
• Linux内部チェックの対象は Ubuntu と Amazon Linux 2023 です。Windowsは対象外です。
• Security Hub は東京リージョンの結果を取り込みます。Trusted Advisor 自体の項目（コスト・耐障害性など）は対象外です。
• 画面の利用者は接続元のIPで制限します。利用者ごとのログインはありません。
• GuardDuty・Inspector・Security Hub・Config・メール送信（Amazon SESなど）の費用は、それぞれのサービスの料金がかかります。

掲載している画面とメールは、サンプルデータによるイメージです。実際の表示とは細部が異なる場合があります。