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

by k.goto

Embed

Start on current slide

Slide 1

Slide 1 text

DEV352 IaC コードを資産へ： AWS CDK 社内ライブラリと横断展開後藤健太株式会社メイツチーフエンジニア AWS Summit Japan 2026

Slide 2

Slide 2 text

Chief Engineer / 株式会社メイツ AWS Hero (AWS DevTools Hero) AWS CDK Top Contributor AWS CDK Community Reviewer 後藤健太

Slide 3

Slide 3 text

●株式会社メイツ ▸EdTech ベンチャー (塾運営 + アプリケーション開発/運用/販売) 会社紹介

Slide 4

Slide 4 text

IaC コードを資産へ

Slide 5

Slide 5 text

チーム規模プロジェクト数 PJ: 3 + α (サブ PJ + SRE) (リポジトリ: 10 over) Backend: 5 名 (全 PJ 合計) - 3 名: 各 PJ 専任 - 2 名: PJ 横断技術スタック AWS CloudFormation AWS Cloud Development Kit TypeScript / Go 当時のチーム・プロジェクトの構成 ※2024 年時点

Slide 6

Slide 6 text

各 PJ で IaC コードを個別管理

Slide 7

Slide 7 text

●似た構成のコードが各 PJ で散財・コピペ運用 ▸同じ役割のコードがプロジェクトごとに独立した管理対象として量産 ●追加・変更を加えるたび全 PJ で個別対応 ▸同じ修正を何度も繰り返す → コストが PJ 数に比例して線形増加 ●同じ役割なのに微妙に違う実装が並立し、認知負荷が肥大 ▸新規 PJ で「どれを真似すべきか」の判断が難しい問題①：コードとしての非効率さ

Slide 8

Slide 8 text

●知見・ノウハウが PJ 内に閉じてしまう ▸ある PJ で得たプラクティスが組織として活かされない ●監視・運用のルールや仕組みが PJ ごとにバラバラ ▸品質管理 / セキュリティなどを横断で担保する仕組みが弱い ●AWS の新機能や共通改善の全社波及が遅い ▸各 PJ で個別に検討・実装する必要 → 組織としての追従速度が落ちる問題②：組織としての非効率さ

Slide 9

Slide 9 text

IaC コードを組織共通の資産へ社内ライブラリ化と PJ 横断展開

Slide 10

Slide 10 text

●各 PJ でよく使う IaC コードを社内ライブラリとして集約 ▸IaC を CDK に統一し、組織共通の CDK Construct 集として設計/運用 ●プライベートレジストリで配布、各 PJ から取り込み ▸パッケージマネージャー経由で全 PJ に波及 ●「個別の作業」を「組織の資産」へ昇華させる仕組み ▸一箇所の修正・改善が全社に行き渡る世界観をつくる社内ライブラリ化と PJ 横断展開

Slide 11

Slide 11 text

●Construct は普段の CDK 開発で日常的に使う機能・概念 ▸大きな学習コストなくライブラリ化しやすい ▸特別な仕組みを作らずに、既存の作法に乗れる ●プログラミング言語のエコシステムをそのまま活用 ▸配布の仕組みを標準ツールで完結 (e.g. TypeScript → npm) ▸プライベートレジストリでもパッケージマネージャーから配布が可能 CDK ✕ ライブラリ化の相性

Slide 12

Slide 12 text

資産によって得られる 3 つのメリット

Slide 13

Slide 13 text

●ライブラリ側の変更だけで利用中の全 PJ に波及 ▸利用側はライブラリのバージョンアップで簡単に利用 ▸共通の修正を素早く・安全に広げられる → メンテナンスコストが PJ 数に比例して増えずに済む ▸新機能追従の遅れの解消にもメリット①：一つの変更で全社へ波及

Slide 14

Slide 14 text

●ベストプラクティスや組織共通の設定がデフォルトで担保 ▸セキュリティ・可用性・ログ・アラート等の標準が組み込み済み ▸ライブラリを使うだけで組織としての標準品質を満たせる → 組織横断でルールや仕組みを統一できる ▸各 PJ ごとにゼロから考える必要がないメリット②：標準品質の自動担保

Slide 15

Slide 15 text

●組織内で「これを見れば・使えばいい」という共通言語に ▸知見・ノウハウの共有場所としても機能する ●新規 PJ の立ち上げや人の入れ替わり時の教育コストが下がる ▸「どれを真似するか」「どう設計/実装するか」迷わない → 認知負荷が軽減し、知見が孤立化しないメリット③：共通言語化と教育コスト減

Slide 16

Slide 16 text

CDK Construct 設計ポイント

Slide 17

Slide 17 text

① 抽象化しすぎない ② 再利用性を意識する ③ 更新の責務を閉じ込める ④ 開発者と利用者の境界を定める CDK Construct 設計ポイント

Slide 18

Slide 18 text

●「全部入りコンストラクト」は使い勝手が良くない ▸この PJ ではこのリソースはいらない / この部分だけ欲しい ●汎用的すぎて構成が把握しづらい ▸BackendContainerOrServerlessApi: 何が作られるんだ…? ●特定のケースに合う「便利コンストラクト」ならあり ▸運用に必要な関連リソースをセット提供 (e.g. ログ分析基盤, 監視基盤) ① 抽象化しすぎない

Slide 19

Slide 19 text

●特定の PJ に依存しないように ▸PJ 固有の名前を登場させない ✓Stack.of(this).stackName などを使う ●スタック外リソースとのハイブリッド連携を受け付けると便利 ▸props 内のプロパティの型を Construct でなく IXxx 型 (interface) に ✓IXxx 型: アンオウンドリソース型 (次ページで説明) ② 再利用性を意識する

Slide 20

Slide 20 text

※IXxx 型: アンオウンドリソース型 (読み込み専用型) ▸スタック外リソース(手動作成・他スタック)も扱うための型 ▸擬似的にスタック内のリソースのように扱える (cdk import とは別) ② 再利用性を意識する AWS マネジメントコンソール Amazon S3 Function Bucket 所有 CDK スタック非所有 (IBucket) grants

Slide 21

Slide 21 text

※IXxx 型: アンオウンドリソース型 (読み込み専用型) ▸L2 Construct の fromXxx() メソッドでスタック外から取り込める ✓スタック外のリソースの ARN などを指定する ✓読み込み専用リソースとして、IBucket 型を返す ✓grants などの操作の対象にできる ② 再利用性を意識する

Slide 22

Slide 22 text

※IXxx 型: アンオウンドリソース型 (読み込み専用型) ▸同じ interface を実装する多種の Construct も渡せるようになる ✓IFunction: Function, NodejsFunction, SingletonFunction, etc… ▸IXxx 型の代わりに IXxxRef 型にするとさらに L1 Construct も渡せる ✓IBucketRef 型: Bucket, IBucket, CfnBucket どれも渡せる ✓PJ によって同じリソース種類でも L1 / L2 を使い分ける環境では特に◎ ② 再利用性を意識する

Slide 23

Slide 23 text

●Construct で公開する public 変数も IXxx 型に ▸その Construct の外では読み込み専用リソースとして扱われる ▸IXxx 型は読み込み専用なので更新メソッドを持たない → リソースを作成した Construct 外からはそのリソースを更新できない ✓安全性の向上・責務の凝集 ③ 更新の責務を閉じ込める

Slide 24

Slide 24 text

●index.ts (バレルファイル)で export する Construct を最小限に ▸エントリーポイントを絞る (index.ts が境界) ▸ライブラリ開発側の自由度と利用側の使いやすさを両立 ④ 開発者と利用者の境界を定めるディレクトリ構成 index.ts (バレルファイル)

Slide 25

Slide 25 text

●ライブラリ開発側 ▸公開しない内部 Construct では IXxx 化しなくても OK ✓IXxx にない便利メソッドを持つ Construct を使いたいこともある ✓IXxx 化は利用側の使いやすさのため → 非公開 Construct は適用外 ●利用(各 PJ)側 ▸利用できる Construct が明確になり把握がしやすい ▸ライブラリ側に内部 Construct が多くあっても利用側には見えない ④ 開発者と利用者の境界を定める

Slide 26

Slide 26 text

① 抽象化しすぎない ② 再利用性を意識する ③ 更新の責務を閉じ込める ④ 開発者と利用者の境界を定める CDK Construct 設計ポイント

Slide 27

Slide 27 text

ライブラリの配布と移行

Slide 28

Slide 28 text

●ライブラリ側：GitLab パッケージレジストリに公開 ▸パッケージマネージャーのプライベートレジストリとして利用 ●PJ 側：npm install (実際は pnpm を使用) ▸CDK (aws-cdk-lib) の更新と同じフローで利用できる ▸各 PJ はバージョンアップだけで新機能・共通変更に追従できるライブラリの配布方法と各 PJ での利用方法

Slide 29

Slide 29 text

1. ライブラリを開発・リリース 2. 各 PJ でライブラリインストール + CDK 実装 ▸既存 CDK 環境：該当 Construct をライブラリに置き換え ▸既存 CloudFormation 環境：新規 CDK 環境作成 (既存構成からの移行) 3. ドメイン以外のリソースをデプロイ ▸旧環境と並行稼働 + 新環境へのアクセス不可な状態を作る 4. データ移行 → ドメイン切り替えで完了 ▸メンテナンスにより無停止移行が不要に移行アプローチ当日数日前

Slide 30

Slide 30 text

●ステートフル：cdk import で既存リソースを取り込み ▸DB (Amazon Aurora) ▸データを失わず CDK 管理下に移し、整合性を慎重に確認しながら移行 ●ステートレス：リソースの作り直し ▸置換が発生しても影響が少ないため、移行コストを下げる選択 ▸CDK で生成されるテンプレートの差分比較 ✓論理名/物理名が異なる前提 ✓リソース・設定値レベルでの比較既存構成からの移行 (CloudFormation→CDK)

Slide 31

Slide 31 text

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 で取り込んだ手順

Slide 32

Slide 32 text

移行後の運用で心がけていること

Slide 33

Slide 33 text

●スナップショットテスト (各 PJ 側) ▸Construct の変更前後の CloudFormation テンプレートの比較 ●integ テスト (ライブラリ側) ▸@aws-cdk/integ-tests-alpha + @aws-cdk/integ-runner ▸実 AWS 環境にデプロイ → 実挙動レベルで壊れていないか保証 ●破壊的変更を防ぐ変更ルール (ライブラリ側) ▸リリース後の props への追加はオプショナルに ▸不要になったプロパティも削除せず @deprecated ラベルを JSDoc で明示互換性維持：他 PJ を壊さない仕組み

Slide 34

Slide 34 text

●Construct / props / メソッドに JSDoc を欠かさない ▸設計意図・利用例をコードと一緒に明文化 ▸コードとドキュメントの乖離も起こりにくい ●利用者はエディタのホバー表示で簡単に確認 ▸ドキュメントを探す手間がなく、錆びずに継続的に利用し続けられる ▸日常の開発ワークフローの中で自然に「資産」を活用できる状態に ●コードとセットで置くことで AI エージェントも理解しやすいドキュメント： JSDoc でコードと一体に

Slide 35

Slide 35 text

ライブラリの PJ 横断展開の結果

Slide 36

Slide 36 text

適用リポジトリ数提供モジュール数 21 リポジトリ 13 モジュール公開 Construct 数 22 Construct 資産の蓄積 ※2026 年現在 ※非 Construct クラスや関数を含めると 40 over

Slide 37

Slide 37 text

●AWS サービスの新機能の導入・切り替え ▸Amazon CloudFront 標準ログ記録 v2 ▸Application Load Balancer ヘルスチェックログ ▸Amazon Athena テーブル定義もセットで提供 ●Docker インラインキャッシュ機構の仕組み ▸全 PJ のデプロイ時間を一括短縮 ●コンテナイメージスキャンの組み込み ▸サプライチェーン攻撃などの脆弱性対策を組織全体で標準化資産の活用事例

Slide 38

Slide 38 text

イメージスキャン 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 出力

Slide 39

Slide 39 text

IaC コードを資産へ

Slide 40

Slide 40 text

●Before: 各 PJ で IaC コードを個別管理 ▸コードとしての非効率さ ▸組織としての非効率さ ●After: 社内ライブラリを PJ 横断展開 → 組織共通の資産へ ▸CDK Construct 集 ▸プライベートレジストリからパッケージマネージャー経由で配布 IaC コードを資産へ

Slide 41

Slide 41 text

リードエンジニア（バックエンド/フロントエンド/SRE) 積極採用中株式会社メイツ MATES INC. カジュアル面談はこちら