ID:81128さん

## プロジェクト概要 複数のBtoB SaaSを運営する事業会社で、数十のAWSアカウントを横断するSRE基盤の設計・運用をリードしています。インフラを数十のCDKプロジェクト・運用マイクロサービスとしてIaC管理する体制を構築しました。加えて生成AI（Amazon Bedrock等）を運用パイプラインそのものに組み込み、「SREが手作業でやっていた業務をシステムに置き換える」ことに一貫して取り組んでいます。 ## 役割・体制 - SREグループのマネージャー兼プレイヤー（自身含め7名のグループ） - 全社体制：アプリケーションエンジニア約40名 - 責任範囲：インフラ設計・運用、可用性、セキュリティ、コスト最適化、権限管理、チームの採用・育成 ## 背景・課題 サービスとAWSアカウントが増え続ける一方でSREは増員できず、アカウント数に比例して増える運用負荷（監視設定・権限管理・脆弱性対応）がスケールしないという構造的な問題を抱えていました。 - 数十アカウント × 複数サービスの監視設定が手作業で、追加・削除のたびに設定ドリフトが発生 - プロジェクトごとにデプロイ手順もリソース命名も異なり、属人化とヒューマンエラーの温床になっていた - セキュリティ検知は日次の手動トリアージ依存で、対応リードタイムが長期化 - 100名超のSSO権限管理を手作業で行っており、都度都度の権限変更依頼が頻発 「人を増やして捌く」のではなく、運用そのものをコード化・自動化して線形増加を断ち切る方針を立て、以下を推進しました。 ## 実際の取り組み ### 1. インフラのIaC集約とデプロイ作業の統一 - 分散していたインフラコードをモノレポに集約し、AWS CDK（TypeScript）へ統一。現在は数十のCDKプロジェクトを単一リポジトリで管理しています - 全CDKプロジェクト共通の対話型デプロイCLI（Python製）を自作。差分確認 → チェンジセット作成 → 承認後に実行というガードレールを標準化し、プロジェクトごとにバラバラだったデプロイ手順を一本化しました - pre-commit フックによる静的解析・フォーマットチェックを整備し、規約違反をレビュー前に機械的に排除しました ### 2. 共通監視基盤のマルチアカウント展開 - CloudWatch アラーム・SNS・Slack連携を共通CDKスタックとして実装し、数十アカウントへ一括展開しました - 監視項目をアカウント単位でフラグ制御（本番/非本番、夜間停止の有無、監視対象サービスの要否）できる設計にし、1アカウント追加＝設定ファイル数行の追記で監視が揃う状態にしました - 「対象外になったアラームの自動削除」「展開失敗時の通知」まで実装し、設定ドリフトが起きない状態を維持しています - CloudWatch Synthetics による外形監視を主要サービス全体へ展開し、内部監視より先にユーザー影響を検知できる体制を構築しました - 夜間停止する環境では停止時間帯のアラームを自動的に無効化する仕組みを組み込み、意味のないアラート通知をゼロにしました ### 3. 生成AIを組み込んだ運用自動化基盤の内製 単発の「AI活用」ではなく、SREの定常業務そのものをAIエージェントに委譲する仕組みを複数構築しました。 - Slack起点のAIコーディングBot（内製）：Slackメンションで AWS Lambda 上の Claude Code を起動し、自然言語の依頼からコード実装・レビュー・PR作成までを完結させます。エラー監視SaaSとの連携も組み込み、「エラーの原因を調べて直して」までSlack上で完結できる状態にしました - コンテナ脆弱性の自動修正パイプライン：Amazon Inspector がコンテナイメージの脆弱性を検知すると、EventBridge → SQS → Lambda（Dockerコンテナ）→ Bedrock 上の生成AIエージェントが修正PRを自動作成し、課題管理システムへのチケット起票まで行います。20以上のリポジトリを対象に「検知 → 修正PR」を無人化しました - セキュリティ検知対応の全自動パイプライン：Security Hub の新規検知を定期取得し「1コントロール = 1チケット」で自動起票（重複防止つき）→ チームでの要否判定 → 対象リポジトリへ draft PR を自動生成 → PRマージを Webhook で検知して該当 Finding を自動クローズ、という流れを構築。管理対象アカウント全体について、起票からクローズまでを一本のパイプラインに閉じました - SBOM横断検索基盤：GitHub Dependency Graph と Amazon Inspector の SBOM を日次で収集し、Glue で正規化・Parquet化して Athena から全社横断でクエリできるようにしました。Log4shell 級のライブラリ脆弱性が出た際の影響範囲調査をSQL一発にしました - なぜ内製したか：既製の脆弱性管理ツールは自社のアカウント構成・課題管理・モノレポ構造に噛み合わず、「検知して通知する」で止まってしまうためです。修正PRの生成とチケットのクローズまで含めて閉じたかったので、生成AIエージェントを実行基盤の一部として組み込む構成を選択しました ### 4. 権限管理の自動化・効率化 - 100名超のユーザーと数十のグループ・権限セットからなる IAM Identity Center 構成を全面的にCDKでコード化し、権限変更をPRレビューの対象にしました - 権限の付け替えに関して依頼が来るとPR作成までを自動で行う仕組みを構築しました - Admin権限を常時保有させず、申請・承認を起点に時限付きで払い出すフローを構築し、恒久的なAdmin権限保有者をゼロにしました - 本番データベースへのアクセスも同様の承認ワークフローに載せ替えました ### 5. コスト最適化 - 社内リソースの棚卸しとReserved Instance / Savings Plansの検討・導入 - 未使用の開発環境をSlackから容易に停止/再開可能とする仕組みを構築し、開発環境コストを約半分程度削減しました - 開発環境のコンテナサービスを対象とした夜間・休日の自動停止基盤を構築し、非稼働時間帯のコンピュートコストを削減しました（停止中はアラームも連動して無効化） - コンテナのメモリ予約値やインスタンスタイプを実測ベースで環境ごとに調整しました - 無料利用枠の使用状況監視、コスト比較レポートの自動生成を実装し、月次コストレビューを定例化しました - 結果：AWS月額コストを数千万円単位で削減 ### 6. 開発生産性・信頼性向上の取り組み - レビュー依頼と GitHub の PR イベントを紐づけ、レビュー状況を Slack スレッドへ自動通知する仕組みを構築し、レビュー待ちの放置を可視化しました - CDN のキャッシュキー設計を見直し、動的レスポンスのキャッシュ起因の不具合を解消しました - 依存ランタイムのEOL検出、クラウド側メンテナンスイベントの自動チェックなど、「気づけなかったら事故になる」領域を機械化しました - 迅速な認知、対応が求められる昨今のサプライチェーン攻撃に関して、人依存となっていた情報収集をAIで日次調査、通知を行う仕組みを構築しました ### 7. チームマネジメント - SREメンバー6名のマネジメント（採用・1on1・評価・育成・タスク管理）を担っています - 年次の障害対応訓練を企画・運営しています。模擬的な管理コンソール画面とログ投入スクリプト、訓練専用環境まで自作し、実際にログを調査してもらう実践形式のシナリオを設計しました ## 成果 | 指標 | Before | After | | --- | --- | --- | | 監視基盤の展開 | アカウントごとに個別設定・ドリフトあり | 数十アカウントへコードで一括展開 | | 外形監視 | 未整備 | 主要サービス全体をカバー | | 脆弱性検知 → 修正PR | 全て手動 | 20以上のリポジトリで自動生成 | | セキュリティ検知対応 | 日次の手動トリアージ | 起票〜クローズまで自動化 | | ライブラリ脆弱性の影響調査 | リポジトリを個別確認 | 全社横断でSQL一発 | | 恒久Admin権限保有者 | 常時保有あり | 0名（時限払い出しに移行） | | 退職者の権限削除 | 手動・漏れリスクあり | 検知から削除・IaC修正PRまで自動 | | IaC管理下のプロジェクト | 分散・手順もバラバラ | 数十プロジェクトを統一管理 | | AWS月額コスト | — | 数千万円単位での削減 | ## この経験から提供できる価値 - 「アカウントやサービスが増えても運用工数が増えない仕組み」をゼロから設計・実装できます。マルチアカウント環境のガバナンス、監視・セキュリティ・権限管理の標準化を、ドキュメントではなくコードとして展開してきました - 生成AIを「便利ツール」ではなく本番運用パイプラインの構成要素として組み込んだ実績があります。Bedrock上でAIエージェントを動かし、脆弱性修正PRの生成やセキュリティ検知対応を無人化するところまで実装・運用しています - プレイヤーとマネージャーを兼任してきたため、手を動かしながらチームを立ち上げられます。少人数のSREチームで「何を自動化し、何を捨てるか」の優先順位づけが最も得意とするところです

### 概要 Slack と GitHub から呼び出せる自社エンジニア向け AI エージェント「DevNeko」を、企画・設計・実装・運用まで単独で担当しました。Claude Code をコンテナ Lambda 上で実行する基盤を内製し、コード実装 / PR レビュー / AWS 横断調査を Slack だけで完結できる社内プラットフォームとして構築、10 ヶ月以上継続運用しています。 ### 役割・体制 企画から運用まで単独で担当（1人プロジェクト）。利用者は社内エンジニア数十名。社内の全プロジェクトの開発に利用。 ### 背景・課題 SRE として日々の運用に入るなかで、「ちょっとした修正でもブランチ作成〜PR まで手順が多い」「PR レビューのラリーで時間が溶ける」「アラートの一次調査が後回しになる」という定型作業のボトルネックがありました。これを人を増やさずに解消するため、クラウド上で常時動く AI エージェントを自作するアプローチを取りました。 ### 担当範囲 企画・要件定義・アーキテクチャ設計・実装（アプリ / IaC）・テスト・社内導入・運用改善まで一人で担当。社内フィードバックを取り込みながら段階的に機能拡張を重ね、現在も継続的にリリースしています。 ### 技術的な取り組み **1. Claude Code の実行基盤をコンテナ Lambda で内製** 初期版は GitHub Actions（Claude Code Base Action）で構築しましたが、ランナー環境による起動失敗・確保待ち・内部バージョンが古く最新機能を使えないという課題がありました。そこで Python ベースのコンテナイメージに Claude Code CLI / git / GitHub CLI / AWS CLI を同梱し、コンテナ Lambda 上で実行する構成へ刷新。環境を完全に固定して起動数秒を実現し、Claude Code の最新機能へも即追従できるようにしました。 - `HOME=/tmp` 必須・エフェメラルストレージ確保など、コンテナ Lambda 特有の制約に対する設計 - Lambda の実行時間上限に対し、エージェント側にはバッファを持たせた制限時間を伝えて制御。タイムアウト時は未コミット変更を自動で WIP コミット → ドラフト PR 化し、途中成果を失わず再開できる設計 - Slack スレッドの会話履歴をそのままコンテキストとして渡すことで、独自のセッション管理を不要化 **2. LLM による自然言語ルーティング** Amazon Bedrock 上の Claude で、自由文からアクション種別（実装 / レビュー / 修正 / 質問）とパラメータ（リポジトリ名・PR 番号・AWS アカウント）を同時抽出する方式を採用。パターンマッチングでは限界のあった判定精度を大きく改善しました。用途ごとにモデルを使い分け（判定は軽量モデル、レビューは中位、実装は上位）、精度とコストのバランスを取っています。 **3. AWS アカウント横断調査（最大の差別化ポイント）** StackSets で読み取り専用の調査用 IAM ロールを各アカウントへ配布し、Organizations API でアカウント名 → ID を解決 → AssumeRole で切り替えて調査する仕組みを実装。「本番の ECS が応答しない」といった依頼に対し、ログ・メトリクス・デプロイ履歴を横断して一次調査結果を Slack に返せるようにしました。権限は読み取りのみ・呼び出し元も限定し、安全性を担保しています。 **4. 「便利そうだけど使われない」問題への対処** リリース直後は SRE チーム内利用に留まり、他チームへ広がらないという課題がありました。ユーザー側の初期設定を求めるのではなく、GitHub Webhook 起点の PR 自動レビューを実装して「PR を開けば自動でレビューが来る」接点を作ることで認知と利用を一気に拡大させました。レビュー方針はプリセット（標準 / アプリ / IaC など）とリポジトリ単位のカスタムプロンプトで切り替え可能にしています。 さらに Bedrock Knowledge Base に AWS Well-Architected Framework と DevOps Guidance を取り込み、標準観点と WA 観点を統合した 1 コメントを投稿するレビュープリセットも追加しました。 **5. 品質・セキュリティ** - TDD で開発し、数百ケース規模のユニットテストを整備。実 Slack 環境に対する E2E テストも自動化 - プロンプトインジェクション対策・入力サニタイズ・サイズ制限・Slack 署名検証・WAF による多層防御 - ドキュメントとナレッジをスキル化し、デバッグ / デプロイ / テストの運用手順を再現可能な形で整備 **6. 適用範囲の拡大** コーディング支援にとどまらず、監視アラートの一次調査自動化や、脆弱性情報の日次チェック通知など、SRE / セキュリティ運用のワークフロー基盤としても活用範囲を広げています。 ### 成果 - 社内の数十リポジトリで PR 自動レビューを導入し、月あたり数百件規模のレビューを自動実行 - 実装・レビュー・調査を合わせて **1 日 100 回以上**呼び出される社内基盤として定着し、累計 1 万回以上の AI タスクを処理 - SRE チーム発のツールが、他チームを含む数十名のエンジニアに利用されるまで浸透 - 大きな障害を出すことなく、継続的に無停止運用 - 「レビューで当初指摘されていなかった Critical な項目が検出された」「レビューがすごく助かる」といった声が他チームから継続的に上がっている - 取り組みを JAWS-UG で登壇発表（Claude Code × コンテナ Lambda での AI エージェント実装事例）

## プロジェクト概要 海外展開する新規BtoB SaaSのAWSインフラを、ネットワークからCI/CDまで一から設計・構築しました。パートナー企業ごとに独自ドメインのサイトを払い出すマルチテナント構成を採用し、テナント追加をコードの数行で完結できる状態にしています。社内で初めてAWS CDKを本格採用したプロジェクトであり、ここで確立した構成・規約が、その後の全社的なIaC標準の原型になりました。 ## 役割・体制 - SRE（インフラ）2名 / アプリケーションエンジニア約10名のチームで、インフラ担当として設計・実装をリード - 立ち上げ時のネットワーク・コンテナ基盤・配信基盤の設計から、その後の機能追加・環境増設・運用改善まで継続して担当 ## 背景・課題 新規サービスの立ち上げにあたり、以下を同時に満たす必要がありました。 - **短期間での構築**：ビジネス側のスケジュールに対し、インフラがボトルネックにならないこと - **テナント追加に耐える構造**：パートナー企業ごとに独自ドメイン・LPを持つ仕様のため、素朴に作るとテナント追加のたびに手作業が線形に増える - **環境の増設が続く前提**：開発・検証・デモ・本番と用途の異なる環境が順次必要になる 一方でAWS CDKは社内に採用実績がなく、設計指針もレビュー観点も存在しない状態でした。そこで「動くものを作る」だけでなく、**後続プロジェクトが真似できる形に標準化すること**を自分の担当範囲と定義して進めました。 ## 実際の取り組み ### 1. マルチテナント配信基盤の設計 パートナー企業ごとに独自ドメインを持つ構成を、パラメータファイルへの追記だけでテナントを追加できる形に設計しました。 - テナント定義（ドメイン・証明書・LP設定）を単一のパラメータ集約点で管理し、CloudFront / ACM / Route53 の各リソースをそこから生成 - CloudFront 用証明書は us-east-1、アプリ基盤は東京リージョンというクロスリージョン構成をコード上で解決 - 各テナントドメインへの SPF / DMARC レコード登録、およびドメイン管理テーブルへの同期をスクリプト化し、テナント追加時の手作業とヒューマンエラーを排除 - 現在は数十のテナントが同一基盤上で稼働 ### 2. コンテナ基盤・ネットワークの設計 - VPC / サブネット / セキュリティグループなどのネットワーク基盤、ECS（Fargate）によるフロント・バックエンド、ALB、Aurora、CloudFront + S3 の配信構成、WAF による防御まで一式をCDKで定義 - 十数スタックに分割し、ライフサイクルと変更頻度の異なるリソース（証明書・WAF・アプリ・パイプライン）を独立してデプロイできる構造に整理 ### 3. 別基盤サービスとの接続設計 後から追加されたチャット機能が別VPCの基盤で構築されたため、VPCピアリングで接続し、Cloud Map + Service Discovery によるサービスディスカバリを導入しました。IPアドレス直指定に頼らず、サービス名で相互解決できる構成にすることで、後続のスケールや入れ替えに耐える形にしています。 ### 4. 複数環境の同一コードベース運用 開発・検証・デモ・本番など用途の異なる複数環境を、環境ごとのパラメータファイルのみで差分吸収する構成にしました。環境固有の値をコード中に散在させず、「環境を1つ増やす＝パラメータファイルを1つ足す」で完結する状態を維持しています。 ### 5. 品質を仕組みで担保 - Jest のスナップショットテストを導入し、CDKの変更が意図しないリソース差分を生んでいないかをPR時点で検出できるようにしました - Linter / Formatter と pre-commit フックを整備し、規約違反をレビュー前に機械的に排除 - CodePipeline によるデプロイパイプラインを構築し、アプリケーションチームがインフラ担当を介さずリリースできる状態にしました ### 6. 社内標準化への展開 本プロジェクトで確立したディレクトリ構成・パラメータ設計・命名規約・レビュー観点をテンプレート化し、以降の新規プロジェクトへ横展開しました。現在は全社のインフラコードをモノレポに集約し、数十のCDKプロジェクトを共通の規約と共通デプロイCLIで運用していますが、その原型がこのプロジェクトです。 ## 成果 - 社内に前例のなかったCDKを本格導入し、**後続の全社IaC標準の原型**を確立 - テンプレートの再利用により、以降の新規サービス立ち上げにおけるインフラ構築工数を大幅に削減 - パートナー企業のテナント追加を、パラメータ追記のみで完結する状態にし、追加時の作業とヒューマンエラーを排除 - スナップショットテストと静的解析により、インフラ変更に起因する意図しない構成差分をリリース前に検出できる体制を構築 - 立ち上げから継続して安定稼働し、機能追加・環境増設に対しても構成を大きく崩さずに拡張 ## この経験から得たもの 「作って終わり」ではなく、**後から入る人が同じ品質で触れる状態にすること**をインフラの成果物と考えるようになりました。社内に前例のない技術を採用する際は、動く構成と同時に規約・テストの型まで作ってしまう方が、結果的に組織全体の速度が上がることを実感した経験です。