トップ > 【AWS Summit Japan 2026】AI を活用した新しいデプロイメント手法と CI/CD における迅速な障害検知と復旧の実現方法 [DVT350] セッションレポート

【AWS Summit Japan 2026】AI を活用した新しいデプロイメント手法と CI/CD における迅速な障害検知と復旧の実現方法 [DVT350] セッションレポート

記事タイトルとURLをコピーする

【AWS Summit Japan 2026】AI を活用した新しいデプロイメント手法と CI/CD における迅速な障害検知と復旧の実現方法 [DVT350] セッションレポート

はじめに

こんにちは。ディベロップメントサービス1課の大井です。

2026年6月25日〜26日に幕張メッセで開催された AWS Summit Japan 2026 に参加してきました。本記事では、聴講したセッション 「AI を活用した新しいデプロイメント手法と CI/CD における迅速な障害検知と復旧の実現方法」[DVT350] のレポートをお届けします。

本セッションのアーカイブ動画は AWS Summit Japan の配信サイト（summitjapan.awslivestream.com）で公開されています。

本セッションのポイントは、次の3点です。

  • AI（AWS MCP / Kiro）によるデプロイ・CI/CD パイプライン構築の加速
  • AWS AppConfig のフィーチャーフラグを使用したリリース管理
  • CI/CD における障害検知と復旧

本セッションは、前半が「AWS MCP を活用した CI/CD パイプラインの構築」、後半が「継続的コンフィグレーションとフィーチャーフラグ」という構成になっています。

Part1：AI エージェントで CI/CD パイプラインを構築する

前半のテーマは「AI エージェントを使って、CI/CD パイプラインの構築とデプロイを自動化する」ことです。

CI/CD が成熟していくにあたり、各段階でベストプラクティスへの追従・セキュリティ・スケーリング・運用保守・コスト管理といった多くの課題に対処する必要があります。また、AWS には Kiro（AI が統合された IDE）や AWS CodePipeline、AWS CodeBuild、AWS AppConfig など DevOps 向けのサービスが揃っており、それらを適切に組み合わせて DevOps を構築していくことが必要になります。

こうした中、CI/CD パイプラインに新しいベストプラクティスを取り入れながら安定的に運用していく上では、AI エージェントを活用し、シンプルな操作で実現していくべきだと語られていました。

AWS MCP は「AWS の知見」を AI エージェントに渡す仕組み

ここで提示されたのが AWS MCP の活用です。MCP（Model Context Protocol）は、AI エージェントが外部のツールや知識へアクセスするためのオープンなプロトコルです。AWS は、AWS 上での構築・デプロイに関する知見——ベストプラクティス、典型的なワークフロー、つまずきやすい箇所とその対処——を「Agent Toolkit for AWS」として公開しています（github.com/aws/agent-toolkit-for-aws）。エージェント側はこの知見を、AWS MCP サーバー経由で、構造化されたマークダウン（Agent Skills）として利用することができます。

AWS MCP を使ったデプロイのオーケストレーション

ポイントは、AWS が用意したガードレール（手順・制約・警告）を介在させている点です。手順が明確に定義されているので出力にブレが出にくく、再現性が高まります。また、AWS の各サービスのアップデート状況など、正確な最新情報に基づいた回答が得られるため、AI エージェントの回答に対する信頼性が高まります。

デモ：Kiro がデプロイ手順を生成し、そのまま実行する

本セッションでは、Kiro を使ったデプロイ・CI/CD パイプラインの構築について、コーヒー注文アプリ（フロントは React + Vite、バックエンドは AWS Lambda、認証/DB は Supabase）を題材としたデモが披露されました。 デモの流れは下記の通りです。

① AWS へのデプロイ

Kiro IDE に AWS MCP サーバーを設定し、デプロイを指示すると、Kiro はデプロイ手順を生成し、そのまま実行まで行います。Kiro への簡単な指示ひとつで Amazon CloudFront / Amazon S3 / Amazon API Gateway / AWS Lambda の構成が立ち上がり、AWS 上に Web アプリケーションがデプロイされました。

② CI/CD パイプラインの構築

CI/CD パイプラインの構築を Kiro に依頼し、AWS CodePipeline / AWS CodeBuild / AWS CloudFormation を組み合わせ、GitHub との連携も含めたパイプラインを作成しました。AWS へのデプロイを依頼したときと同様に、Kiro への指示のみでパイプラインをすぐに構築できることが分かりました。

③ トラブルシューティング

機能追加によってビルドが失敗した際の、Kiro を使ったトラブルシューティングが実演されました。従来であれば、AWS コンソールにログインし、対象のパイプラインを特定してログを確認し、コードベースを調べる——という作業が必要でした。それが現在は Kiro にトラブルシューティングを依頼するだけで、原因の特定から修正案の提示まで行われます。AWS MCP サーバーによって手順が大きく簡略化されていることが実感できるデモでした。

Part2：継続的コンフィグレーションとフィーチャーフラグ

後半は、DevOpsにおけるリリースフェーズの継続的コンフィグレーションの話に入っていきます。

継続的コンフィグレーション

DevOps ツールチェーンにおける「リリース」フェーズに AWS AppConfig が位置する

AWS AppConfig に代表されるフィーチャーフラグ系のソリューションを採用することにより、ソフトウェアの挙動をコードのデプロイやアプリの再起動なしに動的に変えられることが説明されました。具体的に「機能のオン / オフの切り替え」「オペレーションのチューニング（スロットリング、ログ、負荷のシフトなど）」「変更の影響範囲の制限」といったことが実行時の設定参照だけで可能になります。

継続的コンフィグレーションによって実行時に可能になること

たとえば、「機能のオン / オフ」に関する代表的なユースケースとして、新機能のリリースで使われるリリースフラグが挙げられます。フラグがオンになっていれば新しい機能を使わせ、オフになっていればそれを使わせないという制御をしていくことになります。これにより、未完成の機能でも本番環境にデプロイすることが可能となります。また、機能が完成したら、ユーザーの10%、20%と段階的に展開することもできます。 「オペレーションのチューニング（スロットリング、ログ、負荷のシフトなど）」では、ピーク時には CPU 負荷の高い機能はオフにして、ピークが過ぎたらオンにするといった制御が可能になります。 本番に変更を入れるたびに CI/CD を最初から回す必要はなくなり、設定（フラグ）の切り替えだけで挙動を変えられる、というわけです。

AWS AppConfig は AWS Systems Manager の一機能で、アプリケーションの設定値やフィーチャーフラグをコードと切り離して管理・配信できるサービスです。設定の妥当性チェック、段階的なロールアウト、Amazon CloudWatch アラームと連動した自動ロールバックといった仕組みを備えています。

フィーチャーフラグがもたらす価値

AWS AppConfig フィーチャーフラグがもたらす3つの価値

AWS AppConfig のフィーチャーフラグの利点について整理します。 まず、複雑なブランチ管理が不要となる 点が挙げられます。機能をブランチではなくフラグで管理し、ユーザーには非公開のまま継続的にデプロイできます。昨日のリリースとコードのデプロイを完全に切り離すことが可能になり、トランクベースの開発への移行を実現することができます。 実際、AWS の多くのサービスは AWS AppConfig をフィーチャーフラグのソリューションとして使用しているようです。昨年末の AWS re:Invent 2025 では多くの新機能がリリースされましたが、デプロイ自体は数週間前に実施されており、フィーチャーフラグをオンにすることで新機能のリリースを行なっていたようです。 このように、デプロイとローンチはフラグによって完全に分離されるため、コードがデプロイされていれば、フラグをオンにするだけでリリースすることが可能となるわけです。また問題が起きた際には、問題の機能をオフにすることで対応することができ、全体を戻す必要がありません。こうした高速なロールバックが可能になることも大きな利点となります。

フィーチャーフラグとトランクベース開発の関係

「複雑なブランチ管理が不要」は、トランクベース開発（Trunk-Based Development） という開発スタイルと深く関係しています。

トランクベース開発は、長命な機能ブランチを作らず、全員が単一の幹（trunk = main）に小さく頻繁にマージしていくブランチ戦略です。従来のように機能ごとに長く生きるブランチを切ると、ブランチが育つほど main との乖離が大きくなり、マージ時のコンフリクトが膨らみます。

トランクベース開発では、未完成・未公開の機能を フィーチャーフラグで隠したまま main にマージし続ける ことで、この問題を避けます。

■ 従来（長命な機能ブランチ）
  main    ──●──────────────●──  ← マージ時に大きなコンフリクト
            \             /
  feature    ●──●──●──●──●     ← 長く生きるほど main と乖離

■ トランクベース開発（フィーチャーフラグ併用）
  main    ──●─●─●─●─●─●─●──  ← 小さく頻繁にマージ
              ▲     ▲
              └─ 未完成の機能は「フラグOFF」で隠したまま main に入れる
                 → 完成後にフラグONで“公開（ローンチ）”
  • コードは常に main に集約 → 大きなコンフリクトが起きにくい
  • 「マージ（デプロイ）」と「公開（ローンチ）」をフラグで切り離せる
  • 継続的インテグレーション/デリバリーと相性がよく、リリース頻度を上げられる

フィーチャーフラグとトランクベースの開発は相性が良く、AWS AppConfig はこれを支えるサービスであると捉えられます。

フィーチャーフラグの効果

フィーチャーフラグを使うことで得られる4つの効果

フィーチャーフラグを使うことで得られる効果として、次の4点が整理されていました。

まず、平均回復時間（MTTR）の短縮です。問題が発生した機能をフラグひとつでオフにできるため、原因調査や再デプロイの完了を待たずに、その場で影響を止めることができます。

次に、本番環境での検証と、変更の影響範囲の抑制です。新機能を一部のユーザーだけに限定公開すれば、本番相当の環境で動作を検証しつつ、万が一問題が起きた場合の影響範囲も限定的に抑えられます。

3点目は、A/B テストで得た実データに基づく意思決定です。セッションでは、ボタンの表示パターンをフラグで出し分け、実際のユーザーの反応データをもとにどちらを採用するか判断する例が紹介されていました。憶測ではなく実データをもとに機能の是非を判断できる点は、フィーチャーフラグならではの強みだと感じました。

最後に、リリース頻度の向上です。デプロイとローンチをフラグで切り離せるため、機能ができ次第フラグをオンにするだけでリリースでき、細かい単位でのリリースを積み重ねやすくなります。

デモ：本番リリースと自動ロールバック

デモでは、レコメンデーション機能の更新を題材に、本番リリースと自動ロールバックの流れが紹介されました。Amazon API Gateway → AWS Lambda（ディスパッチャ）→ AWS AppConfig という構成で、従来のレコメンデーションと新しいレコメンデーションをフィーチャーフラグで管理し、フラグが無効なら従来のロジック、有効なら新しいロジックが使われるようディスパッチャが振り分けます。ここで新しいレコメンデーションにバグが仕込まれた状態でリリースしたところ、Amazon CloudWatch のアラームがそれを検知し、トリガーとなってフラグが自動的にロールバックされました。フラグの切り替えだけで迅速にリリースでき、かつ不具合を検知した際にはすぐさま復旧できることが分かるデモでした。

まとめ

セッション全体のまとめとして以下の3点が挙げられました。

  1. CI/CD は急速に進化している
  2. AWS MCP を活用することで開発はさらに速くなる
  3. 継続的コンフィグレーションにフィーチャーフラグを活用できる

学び

本セッションで得た学びを整理します。

まず、AWS MCP の活用は、AIの出力の信頼性を高める強力なツールであると感じました。 また、フィーチャーフラグを用いた継続的コンフィグレーションという観点についても勉強になりました。「本番への変更＝毎回 CI/CD を回す」というイメージでしたが、AWS AppConfigなどのフィーチャーフラグ系のサービスを使うことでデプロイとローンチを分けて考えることができると学びました。 今後は、AIの力を活用して構築にかける時間を短縮することに加え、リリース→自動ロールバックの構築も実践してみたいと思います。

関連情報

Part1（AWS MCP / デプロイ）関連 - AWS Agent Toolkit（AWS MCP / Agent Skills）: https://github.com/aws/agent-toolkit-for-aws - Kiro 公式サイト: https://kiro.dev/ - AWS CodePipeline: https://docs.aws.amazon.com/codepipeline/ - AWS CodeBuild: https://docs.aws.amazon.com/codebuild/

Part2（継続的コンフィグレーション / フィーチャーフラグ）関連 - AWS AppConfig: https://docs.aws.amazon.com/appconfig/ - AWS AppConfig フィーチャーフラグ: https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-feature-flags-and-configuration-data.html - トランクベース開発（Trunk-Based Development）: https://trunkbaseddevelopment.com/

イベント - AWS Summit Japan 2026: https://aws.amazon.com/jp/summits/japan/

大井 航太 (記事一覧)

ディベロップメントサービス1課

コーヒー、サッカーが好き