FEATURED PROJECT — AWS OPERATIONS ASSISTANT

AWS OpsMate Pro

AWS運用を静かに見守る、個人用オペレーションアシスタント。
コスト・アラーム・セキュリティ検出を読み取り専用で集め、 毎日の「まず何を見るか」を1枚の日次レポートにまとめます。

MVP MOCK VERIFIED — モックデータと自動テストで検証済み AWS実機検証はこれから
サンプルレポートを見る 検証バックログを見る GitHub — 準備中

PROBLEM

解決したい課題

  • AWSコンソールを複数サービス横断（Cost Explorer・CloudWatch・GuardDuty・Security Hub）で毎日見にいく必要がある
  • コスト急増・アラーム・セキュリティ検知を見落としやすい
  • 日々の確認結果が記録として残らない（昨日と比べられない）
  • 障害や異常が複数あるとき、どれから見るべきかの優先順位が分かりにくい
  • 個人のAWS環境でも、業務と同じ運用習慣を作りたい
  • 一部のAPI取得に失敗すると、確認作業全体が止まりやすい

MVP FEATURES

MVPで完成している機能

収集と分析（読み取り専用）

  • Cost Explorerのコスト集計 — 前日コスト／当月累計／サービス別コスト上位
  • 直近平均との差によるコスト急増検知（しきい値は設定変更可能）
  • CloudWatchアラーム取得 — ALARM状態／INSUFFICIENT_DATA状態
  • GuardDuty Finding取得
  • Security Hub Finding取得
  • 未有効サービスはエラーにせず「未設定」と表示
  • 一部API失敗時もレポート生成を継続（失敗理由と次の確認を明記）

レポートと安全設計

  • Markdown／HTML／JSONの3形式で同内容のレポート生成
  • 重要度判定（CRITICAL〜INFO）と「最初に確認すべき項目」の提示
  • SESメール送信機能（デフォルトdry-run・二重の有効化ゲート）
  • 6種類のモックシナリオ（AWS認証情報なしで全機能を確認可能）
  • 秘密情報マスキング（アカウントID・ARN・認証情報をログとレポートへ出さない）
  • 自動テスト67件（全件成功）

検証状態の区別（正直な現在地）

モックデータで確認済み6シナリオの収集→判定→3形式レポート生成・dry-run動作
自動テストで確認済み急増検知・重要度判定・部分失敗耐性・マスキング等 67件
コード実装済みAWS API収集（boto3）・SES送信・IAM最小権限ポリシー例
AWS実機では未確認実際のAWSアカウントに対する読み取り実行はこれから
実メール送信は未確認SES送信はdry-runまでの確認。実配信は未実施
Lambdaデプロイは未実施日次自動実行（Lambda＋EventBridge Scheduler）は構成案のみ

ARCHITECTURE

構成図

MVPで実装済み（モック検証済み・実機未検証） 将来構想（未実装）

SAMPLE REPORTS

サンプルレポート

すべてモックデータから生成した公開用サンプルです。実環境の情報・AWS実機の取得結果ではありません。別タブで開きます。

MOCK DATA

コスト急増シナリオ

前日コストが直近平均比+220%。急増サービスの特定と推奨アクションを表示。全体ステータスHIGH。

レポートを開く
MOCK DATA

平常時シナリオ

問題なしの日でも空にならないレポート。コスト内訳と「重大な問題は確認されませんでした」を表示。

レポートを開く
MOCK DATA

セキュリティ検出シナリオ

High SeverityのGuardDuty Finding（相当）を重要度順に表示し、最初に確認すべき項目へ反映。

レポートを開く
MOCK DATA

一部取得失敗シナリオ

CloudWatch取得失敗・Security Hub未設定でも、失敗理由と次の確認を添えてレポート全体を生成。

レポートを開く

TECH STACK

使用技術

  • Python 3.12
  • boto3
  • PyYAML
  • pytest
  • AWS Cost Explorer
  • Amazon CloudWatch
  • Amazon GuardDuty
  • AWS Security Hub
  • Amazon SES

ROADMAP

今後の予定（未実装・検証予定）

次に行う検証

  • AWS実機の読み取り確認（モックで検証済みの機能を実環境で実行）
  • 実際のIAMロール（最小権限ポリシー）による実行
  • 実メール送信（SES Sandbox内での配信確認）
  • Lambda化と、EventBridge Schedulerによる日次自動実行

その先の構想

  • AWS Backup（失敗ジョブ）対応
  • AWS Config（非準拠リソース）対応
  • AWS Health（イベント）対応
  • Web画面との統合
  • 複数AWSアカウント対応／Organizations配下の集約レポート
  • AIによる原因候補と確認手順の提案

DESIGN NOTES

設計の意図と作り方

なぜ作ったか
ひとり情シスとして、複数サービスに散らばる「今日のAWSの状態」を毎朝ひとつのレポートで把握したかったため。個人環境でも業務と同じ運用習慣を作る練習台でもあります。
どの運用課題を解決するか
コンソール巡回の手間、コスト急増・アラーム・セキュリティ検知の見落とし、確認結果が記録に残らない問題、異常が複数あるときの優先順位付けを解決します。
なぜ読み取り専用にしたか
毎日自動で動くツールに変更権限を持たせると、バグが事故に直結するため。書き込みAPIはメール送信（SES）だけに限定し、それも設定とオプションの両方を有効にしない限り動きません。IAMポリシーも読み取り用と送信用を分離しています。
なぜ一部失敗してもレポート生成を継続する設計にしたか
運用レポートは「毎日必ず届く」ことが価値だからです。1つのAPI失敗で全体が止まると確認習慣が途切れます。失敗した情報源は「何が失敗し、次に何を確認すべきか」をレポート内に残します。
なぜ共通データモデルへ変換する構成にしたか
AWS API固有のレスポンス形式をレポート処理へ持ち込むと、情報源を増やすたびに出力側の修正が必要になるため。すべての検出を共通のFindingモデルへ正規化してから重要度判定・出力する構成にし、モックとAWSモードが同じロジックを通ることでテストの信頼性も高めています。
AIに依頼した部分
コード実装・テスト作成・モックデータ作成・ドキュメント整備・このページの作成はAI（Claude）とのペア作業です。
人間が決めた要件
対象サービスの範囲、読み取り専用という制約、重要度の考え方、dry-run既定、秘密情報をコード・ログ・レポートへ入れないルール、モックファーストの開発順序、公開時に実装状況を正直に区別する方針。
人間が確認した内容
モック6シナリオの実行結果、自動テスト67件の成功、生成レポートの内容、秘密情報スキャン結果。
現在残っている実機検証
AWS実アカウントでの読み取り実行、最小権限IAMロールでの動作、SESの実配信、Lambda＋Schedulerでの日次実行。ここまで終えて初めて「検証済み」と表記を変えます。
実務で応用する場合の注意
Cost Explorer APIは1リクエスト$0.01の課金があるため実行頻度に注意。大量のFindingがある環境では取得件数上限（ページング）の拡張が必要です。通知の即時性が必要な監視（5分以内の検知など）は日次レポートの守備範囲外で、EventBridge等の別経路を使うべきです。