IaC コードを資産へ：AWS CDK 社内ライブラリと横断展開 / aws-summit-japan-2026

2026/06/25,26 開催 AWS Summit Japan 2026 の登壇資料です。

Transcript

1. DEV352 IaC コードを資産へ： AWS CDK 社内ライブラリと横断展開 後藤 健太 株式会社メイツ チーフエンジニア AWS Summit Japan 2026
2. Chief Engineer / 株式会社メイツ AWS Hero (AWS DevTools Hero) AWS CDK Top Contributor AWS CDK Community Reviewer 後藤 健太
3. •株式会社メイツ ▸EdTech ベンチャー (塾運営 + アプリケーション開発/運用/販売) 会社紹介
4. IaC コードを資産へ
5. チーム規模 プロジェクト数 PJ: 3 + α (サブ PJ + SRE) (リポジトリ: 10 over) Backend: 5 名 (全 PJ 合計) - 3 名: 各 PJ 専任 - 2 名: PJ 横断 技術スタック AWS CloudFormation AWS Cloud Development Kit TypeScript / Go 当時のチーム・プロジェクトの構成 ※2024 年時点
6. 各 PJ で IaC コードを個別管理
7. •似た構成のコードが各 PJ で散財・コピペ運用 ▸同じ役割のコードがプロジェクトごとに独立した管理対象として量産 •追加・変更を加えるたび全 PJ で個別対応 ▸同じ修正を何度も繰り返す → コストが PJ 数に比例して線形増加 •同じ役割なのに微妙に違う実装が並立し、認知負荷が肥大 ▸新規 PJ で「どれを真似すべきか」の判断が難しい 問題①：コードとしての非効率さ
8. •知見・ノウハウが PJ 内に閉じてしまう ▸ある PJ で得たプラクティスが組織として活かされない •監視・運用のルールや仕組みが PJ ごとにバラバラ ▸品質管理 / セキュリティなどを横断で担保する仕組みが弱い •AWS の新機能や共通改善の全社波及が遅い ▸各 PJ で個別に検討・実装する必要 → 組織としての追従速度が落ちる 問題②：組織としての非効率さ
9. IaC コードを組織共通の資産へ 社内ライブラリ化と PJ 横断展開
10. •各 PJ でよく使う IaC コードを社内ライブラリとして集約 ▸IaC を CDK に統一し、組織共通の CDK Construct 集として設計/運用 •プライベートレジストリで配布、各 PJ から取り込み ▸パッケージマネージャー経由で全 PJ に波及 •「個別の作業」を「組織の資産」へ昇華させる仕組み ▸一箇所の修正・改善が全社に行き渡る世界観をつくる 社内ライブラリ化と PJ 横断展開
11. •Construct は普段の CDK 開発で日常的に使う機能・概念 ▸大きな学習コストなくライブラリ化しやすい ▸特別な仕組みを作らずに、既存の作法に乗れる •プログラミング言語のエコシステムをそのまま活用 ▸配布の仕組みを標準ツールで完結 (e.g. TypeScript → npm) ▸プライベートレジストリでもパッケージマネージャーから配布が可能 CDK ✕ ライブラリ化の相性
12. 資産によって得られる 3 つのメリット
13. •ライブラリ側の変更だけで利用中の全 PJ に波及 ▸利用側はライブラリのバージョンアップで簡単に利用 ▸共通の修正を素早く・安全に広げられる → メンテナンスコストが PJ 数に比例して増えずに済む ▸新機能追従の遅れの解消にも メリット①：一つの変更で全社へ波及
14. •ベストプラクティスや組織共通の設定がデフォルトで担保 ▸セキュリティ・可用性・ログ・アラート等の標準が組み込み済み ▸ライブラリを使うだけで組織としての標準品質を満たせる → 組織横断でルールや仕組みを統一できる ▸各 PJ ごとにゼロから考える必要がない メリット②：標準品質の自動担保
15. •組織内で「これを見れば・使えばいい」という共通言語に ▸知見・ノウハウの共有場所としても機能する •新規 PJ の立ち上げや人の入れ替わり時の教育コストが下がる ▸「どれを真似するか」「どう設計/実装するか」迷わない → 認知負荷が軽減し、知見が孤立化しない メリット③：共通言語化と教育コスト減
16. CDK Construct 設計ポイント
17. ① 抽象化しすぎない ② 再利用性を意識する ③ 更新の責務を閉じ込める ④ 開発者と利用者の境界を定める CDK Construct 設計ポイント
18. •「全部入りコンストラクト」は使い勝手が良くない ▸この PJ ではこのリソースはいらない / この部分だけ欲しい •汎用的すぎて構成が把握しづらい ▸BackendContainerOrServerlessApi: 何が作られるんだ…? •特定のケースに合う「便利コンストラクト」ならあり ▸運用に必要な関連リソースをセット提供 (e.g. ログ分析基盤, 監視基盤) ① 抽象化しすぎない
19. •特定の PJ に依存しないように ▸PJ 固有の名前を登場させない ✓Stack.of(this).stackName などを使う •スタック外リソースとのハイブリッド連携を受け付けると便利 ▸props 内のプロパティの型を Construct でなく IXxx 型 (interface) に ✓IXxx 型: アンオウンドリソース型 (次ページで説明) ② 再利用性を意識する
20. ※IXxx 型: アンオウンドリソース型 (読み込み専用型) ▸スタック外リソース(手動作成・他スタック)も扱うための型 ▸擬似的にスタック内のリソースのように扱える (cdk import とは別) ② 再利用性を意識する AWS マネジメントコンソール Amazon S3 Function Bucket 所有 CDK スタック 非所有 (IBucket) grants
21. ※IXxx 型: アンオウンドリソース型 (読み込み専用型) ▸L2 Construct の fromXxx() メソッドでスタック外から取り込める ✓スタック外のリソースの ARN などを指定する ✓読み込み専用リソースとして、IBucket 型を返す ✓grants などの操作の対象にできる ② 再利用性を意識する
22. ※IXxx 型: アンオウンドリソース型 (読み込み専用型) ▸同じ interface を実装する多種の Construct も渡せるようになる ✓IFunction: Function, NodejsFunction, SingletonFunction, etc… ▸IXxx 型の代わりに IXxxRef 型にするとさらに L1 Construct も渡せる ✓IBucketRef 型: Bucket, IBucket, CfnBucket どれも渡せる ✓PJ によって同じリソース種類でも L1 / L2 を使い分ける環境では特に◎ ② 再利用性を意識する
23. •Construct で公開する public 変数も IXxx 型に ▸その Construct の外では読み込み専用リソースとして扱われる ▸IXxx 型は読み込み専用なので更新メソッドを持たない → リソースを作成した Construct 外からはそのリソースを更新できない ✓安全性の向上・責務の凝集 ③ 更新の責務を閉じ込める
24. •index.ts (バレルファイル)で export する Construct を最小限に ▸エントリーポイントを絞る (index.ts が境界) ▸ライブラリ開発側の自由度と利用側の使いやすさを両立 ④ 開発者と利用者の境界を定める ディレクトリ構成 index.ts (バレルファイル)
25. •ライブラリ開発側 ▸公開しない内部 Construct では IXxx 化しなくても OK ✓IXxx にない便利メソッドを持つ Construct を使いたいこともある ✓IXxx 化は利用側の使いやすさのため → 非公開 Construct は適用外 •利用(各 PJ)側 ▸利用できる Construct が明確になり把握がしやすい ▸ライブラリ側に内部 Construct が多くあっても利用側には見えない ④ 開発者と利用者の境界を定める
26. ① 抽象化しすぎない ② 再利用性を意識する ③ 更新の責務を閉じ込める ④ 開発者と利用者の境界を定める CDK Construct 設計ポイント
27. ライブラリの配布と移行
28. •ライブラリ側：GitLab パッケージレジストリに公開 ▸パッケージマネージャーのプライベートレジストリとして利用 •PJ 側：npm install (実際は pnpm を使用) ▸CDK (aws-cdk-lib) の更新と同じフローで利用できる ▸各 PJ はバージョンアップだけで新機能・共通変更に追従できる ライブラリの配布方法と各 PJ での利用方法
29. 1. ライブラリを開発・リリース 2. 各 PJ でライブラリインストール + CDK 実装 ▸既存 CDK 環境：該当 Construct をライブラリに置き換え ▸既存 CloudFormation 環境：新規 CDK 環境作成 (既存構成からの移行) 3. ドメイン以外のリソースをデプロイ ▸旧環境と並行稼働 + 新環境へのアクセス不可な状態を作る 4. データ移行 → ドメイン切り替えで完了 ▸メンテナンスにより無停止移行が不要に 移行アプローチ 当日 数日前
30. •ステートフル：cdk import で既存リソースを取り込み ▸DB (Amazon Aurora) ▸データを失わず CDK 管理下に移し、整合性を慎重に確認しながら移行 •ステートレス：リソースの作り直し ▸置換が発生しても影響が少ないため、移行コストを下げる選択 ▸CDK で生成される テンプレートの差分比較 ✓論理名/物理名が異なる前提 ✓リソース・設定値レベルでの比較 既存構成からの移行 (CloudFormation→CDK)
31. 1. コンソール画面から旧 DB のスナップショットを取得 2. 新 DB スタックの作成 (CDK) ▸DB クラスターが依存するリソースのみを先にデプロイ ▸cdk import 時に依存リソースが存在しないとエラーになるため 3. スナップショットから新 DB をリストア 4. MySQL 5.7 → 8 へアップグレード 5. DB クラスターを cdk import で CDK 管理下に取り込み 6. CloudFormation コンソールでドリフトがないか確認 7. DB クラスターに依存するその他のリソースをデプロイ Aurora を cdk import で取り込んだ手順
32. 移行後の運用で心がけていること
33. •スナップショットテスト (各 PJ 側) ▸Construct の変更前後の CloudFormation テンプレートの比較 •integ テスト (ライブラリ側) ▸@aws-cdk/integ-tests-alpha + @aws-cdk/integ-runner ▸実 AWS 環境にデプロイ → 実挙動レベルで壊れていないか保証 •破壊的変更を防ぐ変更ルール (ライブラリ側) ▸リリース後の props への追加はオプショナルに ▸不要になったプロパティも削除せず @deprecated ラベルを JSDoc で明示 互換性維持：他 PJ を壊さない仕組み
34. •Construct / props / メソッドに JSDoc を欠かさない ▸設計意図・利用例をコードと一緒に明文化 ▸コードとドキュメントの乖離も起こりにくい •利用者はエディタのホバー表示で簡単に確認 ▸ドキュメントを探す手間がなく、錆びずに継続的に利用し続けられる ▸日常の開発ワークフローの中で自然に「資産」を活用できる状態に •コードとセットで置くことで AI エージェントも理解しやすい ドキュメント： JSDoc でコードと一体に
35. ライブラリの PJ 横断展開の結果
36. 適用リポジトリ数 提供モジュール数 21 リポジトリ 13 モジュール 公開 Construct 数 22 Construct 資産の蓄積 ※2026 年現在 ※非 Construct クラスや 関数を含めると 40 over
37. •AWS サービスの新機能の導入・切り替え ▸Amazon CloudFront 標準ログ記録 v2 ▸Application Load Balancer ヘルスチェックログ ▸Amazon Athena テーブル定義もセットで提供 •Docker インラインキャッシュ機構の仕組み ▸全 PJ のデプロイ時間を一括短縮 •コンテナイメージスキャンの組み込み ▸サプライチェーン攻撃などの脆弱性対策を組織全体で標準化 資産の活用事例
38. イメージスキャン Construct ライブラリ image-scanner-with-trivy https://github.com/go-to-k/image-scanner-with-trivy https://github.com/go-to-k/ecr-scan-verifier ecr-scan-verifier • CDK デプロイ中に Trivy によるスキャン • 脆弱性検出時、デプロイをブロック + 通知 • SBOM 出力 • Amazon ECR イメージスキャン(基本/拡張) • 脆弱性検出時、デプロイをブロック + 通知 • SBOM 出力
39. IaC コードを資産へ
40. •Before: 各 PJ で IaC コードを個別管理 ▸コードとしての非効率さ ▸組織としての非効率さ •After: 社内ライブラリを PJ 横断展開 → 組織共通の資産へ ▸CDK Construct 集 ▸プライベートレジストリからパッケージマネージャー経由で配布 IaC コードを資産へ
41. リードエンジニア（バックエンド/フロントエンド/SRE) 積極採用中 株式会社メイツ MATES INC. カジュアル面談はこちら