はじめに
2025年6月25日、26日に幕張メッセで開催された AWS Summit Japan 2025 に参加してきました。
様々なセッションやワークショップが数多くある中、「モダンな CI/CD ツールボックス：一貫性と信頼性を確保するための戦略」を試聴し、非常に興味深い内容だったため、要点をまとめて共有したいと思います。
資料
概要
本セッションでは、CI/CD の価値が広く認識されつつも、効果的な実装に苦労している現状に対し、どのようにCI/CD プラクティスを改善し、実際の行動につなげていくかに焦点が当てられていました。
登壇した井原氏は、CI/CD 導入におけるスケーラビリティ、環境の複雑性、統合の難しさといった実践上の課題を取り上げながら、単一のツールで完結させるのではなく、状況に応じて適切なツールを選択し組み合わせて活用する「ツールボックス」という考え方を強調されていました。
セッションは以下のアジェンダを軸に進行しました：
- CI/CD の基礎
- 変更への対応
- コード署名と構成証明
- GitOps
- デプロイ戦略
- ドリフト
- パイプラインの一貫性
- 継続的コンフィグレーションとフィーチャーフラグ
- 依存性の軽減
CI/CD の基礎
まず前提として、CI/CD の基本的な概念が再確認されました。
- 継続的インテグレーション（CI）：開発者がコードをコミットし、ビルド、ユニットテスト、統合テスト、セキュリティスキャンといった一連の処理を自動で行い、デプロイ可能なアーティファクト（ライブラリや実行ファイルなど）を作成するプロセス
- 継続的デリバリー（CD）：生成されたアーティファクトを本番環境にリリースする際、手動による承認をはさみつつ、リリース準備が整った状態を常に維持するプロセス
- 継続的デプロイ（CD）：全てが自動化された形で本番環境まで変更が展開されるプロセス
変更への対応
CI/CD が開発現場に定着する中で、よく見られる問題のひとつが「変更管理の分断」です。アプリケーションコード、インフラ、設定ファイル、シークレットといった各要素が、異なるプロセスやツールで個別に管理されていると、一貫性のないデプロイや設定ミス、監査証跡の断片化といったリスクが生じます。
井原氏は、こうした課題に対する理想的なアプローチとして、「すべての変更を一元的に管理する」ことの重要性を強調していました。インフラ構成、アプリケーションコード、環境設定、シークレットまでも含めて、すべてをバージョン管理下に置き、単一のCI/CD パイプラインで取り扱うことで、誰がいつ何を変更したのかが明確になり、自動テストやポリシー準拠のチェック、監査ログの取得も容易になります。
さらに、変更の粒度についてもポイントがありました。個別に変更を適用するのではなく、全ての変更を単一のアトミックなデプロイメントユニットとして扱い、ロールバックも含めて同じ戦略で管理することで、部分的な変更適用によるシステムの不整合を防ぐことができます。
コード署名と構成証明
CI/CD の高度な実践においては、単にコードをデプロイするだけではなく、それが信頼できるソースから来たものであり、改ざんされていないことを保証する仕組みが求められるようになっています。そのための取り組みとして注目されていたのが「コード署名」と「構成証明」です。
すべてのコミットに署名を行うことで、そのコードが誰によって、どのタイミングで変更されたのかを明確にし、信頼性と追跡性を担保することの重要性が語られていました。これにより、監査の観点からも有効であり、ソフトウェアアーティファクトが改ざんされていないことを確認できます。
加えて、これらの仕組みはソフトウェアの改ざん、サプライチェーン攻撃、不正な変更といったセキュリティリスクからの防御にも有効です。ただし、署名済みのコード自体に脆弱性が含まれていた場合や、開発者の認証情報の侵害、ランタイム攻撃からは保護されないため、より広範なセキュリティアプローチの一部として使用されるべきであり、常に他のセキュリティプラクティスと組み合わせて使用する必要があるという注意喚起もありました。
GitOps
GitOpsは、Git と Operations を組み合わせた概念です。Gitを「唯一の信頼できる情報源」として扱い、アプリケーションコード、インフラストラクチャコード、デプロイコードなど全てをコードとして管理し、あらゆる変更をGitリポジトリ上で定義・管理することで、自動化された運用を実現するアプローチです。セッションでは、GitOpsの考え方とその実践が、CI/CD のモダンな姿としてどのように組み込まれているかが紹介されました。
特に印象的だったのは、「開発者がデプロイにおける決定権を持ち、自律的に運用できる環境を整えることが、組織全体の開発スピードや品質向上につながる」という考え方です。手動操作を排除し、Git上の変更がそのままデプロイに反映されることで、一貫性が保たれ、環境差異や人的ミスを防ぐことができます。
これにより、CI/CD パイプラインを効率化し、開発からデプロイまでのサイクルを短縮することが実現できます。
AWSにおけるGitOpsの実践例としては、CloudFormationとのGit同期や、AWS CodePipeline V2、Cloud Native Operational Excellence（CNOE）といったツールが取り上げられていました。これらを組み合わせることで、GitOpsをベースにした堅牢な運用基盤を構築できると紹介されていました。
デプロイ戦略
CI/CD の実装において、どのようにリリースを行うかという「デプロイ戦略」は、リスクの最小化やユーザー体験の維持に直結する重要な要素です。今回のセッションでは、代表的な3つの戦略が紹介され、それぞれの特性と使いどころについて具体的に解説されていました。
主な戦略：
- ローリングデプロイ：稼働中のインスタンスを順番に新しいバージョンへと入れ替えていく手法で、サービスの継続性を保ちながらアップデートを進めることができる。特に、限られたリソースで常に一定の可用性を維持する必要がある場合に適した方式。
- ブルー/グリーンデプロイ：現行環境（ブルー）とは別に新しい環境（グリーン）を用意し、検証後にすべてのトラフィックを新環境へ切り替える手法。デプロイ時のダウンタイムをゼロにでき、問題発生時にも旧環境に迅速に戻すことができるが、リソースが2倍必要となるためコスト面の考慮が必要。
- カナリア・デプロイ：限られたユーザーに対して新バージョンを展開し、その挙動をモニタリングした上で徐々に全体に拡大する。問題があれば早期に検知して影響範囲を最小限に抑えることができるため、ユーザー規模の大きなサービスや重要な変更を含むリリース時に有効。
ドリフト
クラウド運用において「ドリフト」は、コードで定義された構成と実際のインフラの状態が乖離してしまう現象を指します。CI/CD を用いた自動化が進んでいても、手動操作による変更や緊急対応によって意図しない差異が生じるケースは少なくありません。
セッションでは、このドリフトが引き起こすリスクとして、予測不能な動作や構成ミス、トラブルシューティングの難航といった点が挙げられていました。特に本番環境での手動変更は、テスト済みのコードベースから逸脱することになるため、運用上の安定性を著しく損なう原因となります。
こうした問題に対応するための基本的な方針としては、本番環境に対しては読み取り専用のアクセス権限を付与することが推奨されています。また、緊急時には例外的に手動操作を許可する「ブレークグラス」オプションを設けておくことで、セキュリティと柔軟性のバランスをとることが可能になります。
さらに、AWS CloudFormation のドリフト検出機能や、CloudTrail を用いた操作ログのモニタリング、Terraform のstateファイルを活用した整合性チェックなど、具体的な技術的手段も紹介されていました。
パイプラインの一貫性
マイクロサービスアーキテクチャの普及に伴い、多くのプロジェクトが独自のCI/CD パイプラインを構築しています。しかし、これが裏目に出て、プロジェクトごとに構成や品質がバラバラになり、メンテナンスや運用負荷が高まるという課題が浮き彫りになってきました。
このような状況に対する解決策として、「共通テンプレート」と「カスタマイズの柔軟性」の両立が提案されていました。具体的には、まず組織全体で標準化されたパイプラインテンプレートを用意することで、セキュリティやコンプライアンスの準拠、ベストプラクティスを自動的に適用できるようにします。これにより、プロジェクト間のばらつきを減らすことが可能になります。
一方で、プロジェクトやチームごとの事情に応じて調整が必要な場面も少なくありません。そうした場合には、テンプレートをベースに**「カスタムフック」や「再利用可能なビルディングブロック」**を用いることで、柔軟に機能を追加・変更できるように設計しておくことが重要です。
継続的コンフィグレーションとフィーチャーフラグ
ソフトウェアの運用フェーズにおいては、設定変更の柔軟性や機能リリースのコントロールが求められます。それらのニーズに応える手法として継続的コンフィグレーションとフィーチャーフラグが紹介されました。
まず、継続的コンフィグレーションとは、アプリケーションを再起動したり再デプロイしたりすることなく、設定の変更を動的に反映させる仕組みです。これにより、サービスの挙動をリアルタイムでチューニングしたり、影響を最小限に留めつつ変更を行ったりすることが可能になります。例えば、ログの出力レベルやスロットリング設定、負荷分散のパラメータなどが動的に調整できるようになり、変更の影響範囲の制限が実現できるようになります。
一方のフィーチャーフラグは、特定の機能の有効/無効を切り替えるスイッチのようなもので、新機能の段階的なリリースやA/Bテスト、安全なロールバックなどに活用されます。特に、本番環境で実際のデータを用いた検証を行いながら、リスクを抑えたリリースが可能になるという点で大きな価値を持っています。
ただし、フィーチャーフラグには注意点もあります。たとえば、使われなくなったフラグの除去漏れや、過度に入れ子構造を取ることによるコードの複雑化といった問題です。そのため、ガバナンスと自動化による管理体制の構築が不可欠です。
依存性の軽減
CI/CD 環境を整備する際には、便利なツールを選んで導入するだけでは不十分です。ツール同士の依存関係が強すぎたり、特定のベンダーにロックインされてしまったりすると、将来的な変更や拡張が難しくなってしまいます。このような依存性をいかに軽減するかも、CI/CD を成功させるための重要な視点のひとつです。
セッションでは、柔軟でポータブルなCI/CD 環境の実現を目指すアプローチが紹介されていました。具体的には、ツールを単に利用するのではなく、概念を抽象化し、異なる環境やベンダーにも対応できるように設計するという発想です。
その一例として、TypeScript でCI/CD パイプラインを宣言的に定義できる「Projen-pipelines」というオープンソースツールが紹介されました。これを使えば、GitHub Actions や GitLab CI、Amazon CodeCatalyst といった複数のプラットフォームに対応したパイプラインを、同じソースコードから生成できるようになります。
まとめ
IaCや構成証明、GitOps、そしてデプロイ戦略やドリフト検知といったキーワードは、単なる流行ではなく、現代のソフトウェア開発における品質とスピードを両立させるための基盤技術となっています。どれも一朝一夕で導入できるものではありませんが、それぞれが持つ思想を理解し、プロジェクトのフェーズやチームの成熟度に応じて少しずつ取り入れていくことが重要だと感じました。
また、構成の一貫性や依存性の軽減、継続的な設定変更のための仕組みなど、CI/CD に関するプラクティスもますます洗練されてきており、CI/CD そのものが進化し続けていることを実感する内容でもありました。
これからCI/CD の導入や改善を検討している方、あるいは既に運用していて次のステップを模索している方にとって、本記事が何かしらのヒントになれば幸いです。
Discussion