はじめに 「This Month in AWS Observability」最新号へようこそ。今回は、この6月に Amazon CloudWatch と AI 駆動型オペレーション全般で発表された新機能をご紹介します。CloudWatch でネイティブな OpenTelemetry メトリクスと PromQL クエリが一般提供（GA）となり、より深い統計・構造化分析のための 23 個の新しい Logs Insights コマンドがローンチされ、CloudWatch RUM に Session Replay が登場し、 AWS DevOps Agent では MCP および Agent-to-Agent プロトコルをサポートするカスタム SRE エージェントがリリースされました。EKS クラスター全体で GPU コストを配賦する場合も、実際のセッション再生でフロントエンドの問題をデバッグする場合も、チームのランブックを自律型 SRE エージェントに組み込む場合も、役立つ情報が見つかるはずです。これらの新機能のデモをご覧になりたい方は、8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」にご登録ください。 OpenTelemetry と Prometheus Amazon CloudWatch は、ネイティブ OpenTelemetry メトリクスと PromQL クエリの一般提供という大きなマイルストーンに到達しました。また、Amazon Managed Service for Prometheus には、高カーディナリティなワークロードのコストと複雑さを削減する機能が追加されました。 ネイティブ OpenTelemetry メトリクスと PromQL クエリ（GA）  Amazon CloudWatch が OpenTelemetry メトリクスをネイティブにサポートし、一般提供が開始されました。チームは OpenTelemetry Protocol（OTLP）経由でメトリクスを直接送信し、Prometheus Query Language（PromQL）でクエリできます。料金は GB あたりの取り込み課金で、15 か月分のストレージが含まれます。これにより、CloudWatch と並行して別途 Prometheus 互換バックエンドを用意する必要がなくなります。数十のラベル（namespace、pod、container、node、deployment）を持つ高カーディナリティメトリクスが CloudWatch に直接流れ込み、チームがすでに慣れ親しんだ PromQL 構文で即座にクエリ可能になります。 CloudWatch Pipelines が OpenTelemetry メトリクスの処理とエンリッチメントをサポート  CloudWatch Pipelines により、カスタムインフラストラクチャやアプリケーション計装の変更なしに、取り込み時に OpenTelemetry メトリクスの処理とエンリッチメントが可能になりました。例えば、ビジネスコンテキストの追加、高カーディナリティラベルの除去、命名規則の強制などが行えます。 Amazon Managed Service for Prometheus のネイティブヒストグラムサポート  ネイティブヒストグラムは、バケット境界ごとに 1 つの時系列を出力する従来の Prometheus ヒストグラムを置き換えるものです。20 個以上のバケット境界を事前定義してメトリクスごとに 20 以上の時系列分のコストを支払う代わりに、ネイティブヒストグラムは分布全体を動的な解像度を持つ単一の時系列に格納します。これにより、レイテンシー、リクエスト時間、値の分布の追跡において正確なパーセンタイル計算を維持しながら、ストレージコストとカーディナリティを削減できます。 OTel と Managed Prometheus による GPU コスト配賦  Amazon Elastic Kubernetes Service 上で AI/ML ワークロードをスケールさせるチーム向けに、OpenTelemetry コレクター、Amazon Managed Service for Prometheus、Amazon Managed Grafana を使用した GPU コスト配賦の新しいリファレンスアーキテクチャが公開されました。namespace、チーム、ワークロードタイプごとに GPU コストを配賦でき、「共有クラスターで最も高価なコンピューティングリソースを消費しているのは誰か」という問いに答えられます。 CloudWatch と OpenTelemetry による Claude Code 利用状況の分析  Claude Code のような AI コーディングエージェントがエンジニアリング組織全体に広がる中、トークン消費量、チームごとのコスト、開発者の生産性の追跡が重要になっています。このパターンでは、CloudWatch OTLP エンドポイントを使用して Claude Code セッションからカスタム OpenTelemetry メトリクスを取り込み、既存ツールでは答えられない問い（どのチームが最も多くのトークンを消費しているか、開発者あたりのコストはいくらか、AI 支援開発が最も価値を発揮しているのはどこか）に答えるダッシュボードを実現します。 ログ分析の進化 Amazon CloudWatch Logs の新しいクエリ・取り込み機能により、ログデータの大規模な分析・検索・ルーティングが容易になります。 23 個の新しい CloudWatch Logs Insights クエリコマンド  CloudWatch Logs Insights に、複数カテゴリにわたる 23 個の新しいクエリコマンドが追加されました。 パースコマンド: 多様なログ形式からの構造化抽出のための parse_json、parse_kv、parse_csv、parse_xml 分析関数: より深い統計分析のための median、percentile_cont、mode、variance、stddev ハッシュ・IP 関数: セキュリティおよびネットワーク調査ワークフローのための md5、sha256、ip_to_int、cidr_match 条件ロジック: より表現力豊かなクエリ構築のための case、coalesce、nullif、if これらの追加により、複雑な調査のためにログを外部分析プラットフォームへエクスポートする必要性が減少します。 Log Analytics 統合コンソール  新しい Log Analytics コンソールは、ロググループ横断のクエリ、自然言語によるログデータの探索、再利用可能なクエリパターンの保存を単一のインターフェースで提供します。従来は複数のコンソールページを行き来する必要があった作業が、単一のワークフローに統合されました。 タグベースのロググループクエリ 個々のロググループ名を指定する代わりに、タグでロググループをクエリできるようになりました。数百〜数千のロググループを持つ組織にとって、クエリのスコープ指定が簡素化されます。チーム、環境、サービス階層でロググループにタグ付けすることで、明示的なリストを維持することなく「決済チームの本番ログすべて」をクエリできます。 マネージド Syslog 取り込み  CloudWatch Logs が、VPC エンドポイント経由で TCP、TLS、UDP を使用したマネージド syslog 取り込みをサポートしました。RFC 5424、RFC 3164、および Cisco FTD や ASA を含むベンダー固有の形式に対応します。syslog メッセージは自動的に構造化フィールドにパースされ、手動での変換なしに Logs Insights で即座にクエリ可能になります。 Elastic Beanstalk ログ統合  AWS Elastic Beanstalk 環境が、ネイティブ統合によりアプリケーションログとプラットフォームログを CloudWatch Logs に直接ストリーミングできるようになりました。カスタムの .ebextensions 設定や、Beanstalk 管理インスタンス上のログストリーミングエージェントは不要です。 大規模なメトリクスとモニタリング 新しいクエリおよびメトリクス機能が拡張され、より大規模で複雑なマルチアカウントアーキテクチャを、より長い保持期間とより深いサービス固有の可視性でサポートします。 クロスアカウントメトリクスの一元化  CloudWatch が、簡素化された設定によるクロスアカウントメトリクスの一元的な収集をサポートしました。組織はモニタリングアカウントを指定し、メンバーアカウントからメトリクスを自動的に集約できます。アカウントごとの手動セットアップなしに、フリート全体のダッシュボードとアラームが実現します。 Metrics Insights の保持期間延長 CloudWatch Metrics Insights クエリが延長された保持期間をサポートし、より長い過去のウィンドウにわたる分析クエリを実行できるようになりました。これにより、外部分析システムへのデータエクスポートを必要とせず、CloudWatch 内で直接トレンド分析、キャパシティプランニング、前年比較が可能になります。 Amazon ElastiCache: 13 個の新しい CloudWatch メトリクス  Amazon ElastiCache が、メモリ断片化、接続チャーン、キー削除（Eviction）パターン、レプリケーションラグの詳細、コマンドレベルのレイテンシー分布をカバーする 13 個の新しい CloudWatch メトリクスを公開しました。これらのメトリクスは、従来は Redis や Memcached インスタンスに直接接続しないと観測できなかった、キャッシュ劣化の早期警告指標を見える化します。 エンドユーザーモニタリングと合成モニタリング 強化されたリアルユーザーの可視性と、より柔軟な合成テストトポロジーにより、モニタリングがエンドユーザーにさらに近づきます。 CloudWatch RUM Session Replay CloudWatch Real User Monitoring（RUM）に Session Replay が追加され、実際のユーザーセッションを発生した通りに記録・再生できるようになりました。顧客から報告された問題を調査する際、エンジニアはユーザーが体験したインタラクション、ページロード、エラー、レイテンシーの正確なシーケンスを見ることができ、フロントエンドデバッグから当て推量を排除します。 Synthetics マルチロケーション Canary  CloudWatch Synthetics に、単一の管理設定のもとで同じ合成テストを複数の AWS リージョンから同時に実行するマルチロケーション Canary が導入されました。各ロケーションは独立して動作します。あるロケーションが失敗を報告し、他が成功している場合、CloudWatch はシグナルを相関させて局所的な問題とグローバルな障害を区別し、誤検知によるアラームノイズを削減します。 AWS DevOps Agent によるインテリジェントオペレーション AWS DevOps Agent は、クラウド環境向けの AI 搭載オペレーションアシスタントとして進化を続けており、自動調査のインテリジェンスとリーチの両方を向上させる新機能が追加されました。 カスタム SRE エージェント  チーム固有の運用ランブックやインフラストラクチャパターンに合わせたカスタム SRE エージェントを構築できるようになりました。カスタムエージェントは、サービスアーキテクチャ、よくある障害モード、推奨される修復手順に関する組織の知見をエンコードし、繰り返し発生する問題の解決時間短縮を可能にします。 MCP および A2A プロトコルサポート  AWS DevOps Agent が Model Context Protocol（MCP）と Agent-to-Agent（A2A）通信をサポートしました。これにより、DevOps Agent はマルチエージェントアーキテクチャの中で他の AI エージェントとオーケストレーションし、外部ツールの呼び出し、ナレッジベースへのクエリ、組織の境界を越えた修復ワークフローの調整が可能になります。 Webhook トリガーと曖昧性解消カード  新しい Webhook ベースのトリガーにより、外部システム（PagerDuty、Datadog、カスタムアラートパイプライン）が DevOps Agent の調査を自動的に開始できるようになりました。調査中に曖昧さに遭遇した場合、曖昧性解消カード（disambiguation cards）が実行を停止させる代わりに構造化された選択肢をオペレーターに提示し、人間のガイダンスを得ながら調査ループを前進させ続けます。 5 つの新リージョンへの展開  AWS DevOps Agent がさらに 5 つの AWS リージョンで利用可能になり、広範なグローバルカバレッジを実現しました。ヨーロッパ、アジアパシフィック、および追加の北米リージョンで運用するチームは、調査をローカルで実行できるようになり、データレジデンシーの懸念を軽減し、リアルタイム運用ワークフローのレイテンシーを改善します。 開発者体験の改善 AWS DevOps Agent には、日常の運用ワークフローの摩擦を減らす、的を絞った QOL（quality-of-life）改善が加えられました。 リリース管理機能（プレビュー） DevOps Agent がリリース管理機能をプレビューとして提供開始しました。コード変更の本番投入準備状況をレビューし、標準からの逸脱、依存関係への影響、Well-Architected への準拠をチェックするとともに、テスト計画を自律的に生成・実行してデプロイ前にリグレッションを検出します。これにより、チームは AWS、マルチクラウド、オンプレミス環境全体で、より速いリリースと MTTR の削減を実現できます。 静的 IP サポート エージェントスペースにアウトバウンドトラフィック用の静的 IP アドレスを設定できるようになりました。IP ベースの許可リストを必要とする外部システム（オンプレミスの ITSM プラットフォーム、パートナー API、レガシーファイアウォール）との統合が可能になります。 自動拡張チャットと完全なコンテキスト保持  DevOps Agent の調査インターフェースに、自動的に広がるチャット入力欄と、調査セッションをまたいだ完全なコンテキスト保持が追加されました。より長く詳細なプロンプトが切り捨てられることなくサポートされ、以前の調査に戻ると会話履歴と調査結果が完全な状態で保持されています。 AWS Cloud Operations Blog の関連記事（2026年6月） 2026年5月〜6月に AWS Cloud Operations Blog で公開された記事は以下の通りです。 2026年6月 Log analysis with facets, correlation, enrichment, and automation in Amazon CloudWatch Log Analytics （6月19日）– Salman Ahmed, Ravi Kumar Amazon CloudWatch と OpenTelemetry による Claude Code 利用状況の分析 （6月17日）– Rodrigue Koffi, Gianluca Cacace, Vadim Omeltchenko GPU Cost Attribution in Amazon EKS Using Amazon Managed Service for Prometheus, Amazon Managed Grafana, and OpenTelemetry （6月12日）– Siva Guruvareddiar Introducing native histogram support in Amazon Managed Service for Prometheus （6月12日）– Vinod Kisanagaram, Priyanka Verma, Rohit Sharma まとめ 過去 2 か月間のオブザーバビリティ関連のローンチは、明確な方向性を示しています。AI 支援オペレーションはプロダクショングレードへの移行を続け、ログ分析は CloudWatch コンソールを離れることなくより強力になり、メトリクスはマルチアカウントのエンタープライズアーキテクチャに対応する規模へスケールし、モニタリングは合成テストとリアルユーザー体験の両レイヤーへさらに深く到達しています。 これらの機能を使い始めるには OpenTelemetry メトリクスを OTLP 経由で CloudWatch に直接送信 し、別途 Prometheus バックエンドなしで PromQL でクエリする 既存のロググループで新しい Logs Insights クエリコマンド を試す   CloudWatch RUM の Session Repla y を有効にして、ユーザーが体験していることを正確に確認する   マルチロケーション Canary を設定して、合成テストのカバレッジを向上させ誤報を削減する AWS DevOps Agent の  カスタムエージェント  を探索し、チームの運用ノウハウをエンコードする 最近のローンチの完全なリストは、Amazon CloudWatch でフィルタリングした AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」に参加して、これらの新機能の実際の動作を確認し、トラブルシューティングの高速化に活用してください。 著者 Dot Ho Dot は AWS Observability 担当の Senior Technical Product Marketing Manager です。WCA 3×3 マルチブラインド（目隠し複数ルービックキューブ）ソルブの記録向上に向けて練習中です。 Joe Alioto Joe は AWS の Cloud Operations 担当の Worldwide Senior Specialist Solutions Architect で、オブザーバビリティ、AI 駆動のオペレーション、集中型オペレーション管理を専門としています。20年以上のオペレーションエンジニアリング経験を持ち、直近2年間は AI と AIOps に注力しています。彼は、アプリケーションパフォーマンス、インフラメトリクス、データベースワークロードを結びつけるインテリジェントなオブザーバビリティ戦略の構築を支援しており、AI エージェントと自動化を活用して平均解決時間 (MTTR) を短縮し、オペレーションチームの大規模な働き方を変革することにますます取り組んでいます。 本ブログは 2026 年 7 月 15 日に公開された This Month in AWS Observability: June 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

はじめに 2026/7/20（月・祝）、BASE株式会社から 登壇 & ゴールドスポンサーとして協賛した PHP Conference Japan 2026が開催されました。 今回はPHP Conferenceに初参加したメンバーが多かったため、初参加ならではの感想コメント、会場やスポンサーブースの様子についてお届けします！ BASEのスポンサーブースの紹介 今年は Yell Bank と PAY ID がロゴをリニューアルしたため、それにちなんで「BASEロゴ検定〜あなたもBASEのGEEKになろう〜」と題して、BASEが展開するサービスのロゴにまつわるクイズ企画を実施しました！ ↑ブログ投稿用に、ご回答いただいた中から厳選させていただいて貼っていますが、写真にない付箋が100枚くらいありました。 非常に多くの方にご回答いただき、ノベルティとして用意していました「BASEロゴ今治ミニタオル」も14時頃に配布終了してしまいました。（お渡しできなかった方、すみません…！） 今回作成したクイズのうち問１〜問３までは、イベント当日に受付で入場者に配られるチラシにロゴの説明として回答を掲載していました。 また、問４はエクストラ問題としてチラシには答えが載っていない問題を用意していました。そのように説明すると「我こそは」と真剣に考えてくださる方が多く、みなさん楽しんで挑戦してくださいました。（この問題の答えはこちらの PAY ID ロゴリニューアル のブログに掲載されています） ノベルティとしてお配りしていたBASEロゴ今治ミニタオル。こだわって作成しているため嬉しいお声をたくさんいただけてたいへん嬉しかったです。 登壇の紹介 かがの（ @ykagano ） speakerdeck.com 今回は購入に失敗したインシデントについてお話しさせていただきました。 ポイントとしては以下の2点と考えています。 クラス名をシリアライズして保存する設計による、クラス削除の影響漏れ 擬似乱数の消費位置を変更したことによる、キー衝突の確率変動 発生原因を深掘りすると複数の要因が重なって発生した、学びのあるインシデントでした。 特に2は資料では割愛していますが、擬似乱数の消費位置を突き止めるために、AIを使って発生パターン（シード43億通り × 消費位置15まで）の総当たりを行い、エラーが発生した2つのキーの消費位置がどちらも5であることを確認しています。 インシデントはなるべく発生させないようにしたいですが、インシデントを通してPHPの擬似乱数の仕組みを知ることができたのはよかったと思います。 PHP Conferenceでの登壇は初めてで緊張しましたが、たくさんの方にお聞きいただきありがとうございました。また次回の開催時にも参加させていただきます。 現地で見たセッションから得た学び・感想（ @wakana ） ブーススタッフとして従事していた時間が長かったため数個のセッションしか見ることができませんでしたが、その中でも特に印象に残ったセッションの感想です。 （登壇の詳細については、登壇者様からアップロードされている資料や、後日公開予定となっているイベント公式アーカイブをご覧ください） Laravelで学ぶ Webアプリケーションチューニング入門　Ryo Tomidokoro氏 speakerdeck.com こちらのセッションでは、Laravelでのアプリケーション開発・運用を例に取ったアプリケーションのチューニング方法の基礎、考え方について発見・再確認することができました。 印象に残った学びは以下です。 「なんか遅い気がする」ではなく、「APIのレスポンス返却が普段より500ms遅くなっている」などの定量的な数値に変換することで議論が行えるようになり、調査を開始することができる。 ブラウザに表示されるまでの経路のうち、Webアプリケーションが占める割合は一部でしかない。Webアプリケーションを改修すると決める前に、プロファイラーを使って本当にWebアプリケーションが遅いことを特定する。 Webアプリケーションが遅いことがわかったら、New Relicやdatadogなどのプロファイラーを使って遅い処理を特定する。ボトルネックは往々にして解決が難しい事が多いが、そこに向き合うことが重要。 ボトルネックから目を逸らすな。 ボトルネックの特定や、改修にあたっては日頃から自分の中に使える手札を増やしておくことが大事。（スライド内で紹介されていたものの一部抜粋） PHP で学ぶ Cache の距離の話 / study_cache_with_php PHPerのための計算量入門/Complexity101 for PHPer 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 個人的にも直近の業務ではプロファイラーツールを用いてチューニングのための分析を行うことが増えてきていたため、タイミングよく今の自分に必要な発表を聞くことができました。 日々の手札を増やしていけるよう、一層精進していきたいと思いました。 そして「ボトルネックから目を逸らすな」肝に銘じます 💪 セレンディピティ～AIで答えが出る時代に、なぜコミュニティへ行くのか？ 小泉岳人 氏 www.docswell.com こちらのLTでは、「AI時代にわざわざコミュニティに足を運ぶ意義はどこにあるのか」という点を伺うことができました。 個人的に、別のカンファレンスやその後の懇親会でも耳にすることが増えてきたテーマだったため、視聴前から興味の強い発表でした。 こちらのLTでは、主に次のような学びを得ることができました。 問いに対する答えを知るだけならAIで行うことができてしまうが、コミュニティに来ると思いがけない出会い（人・情報・etc…）に心を動かされることがある 様々な発表を聞いて、すぐに答えの出ない問いや考えを得て、それを持ち帰ることで、 自分の中で問いを育てることができる 問いを育てながら何度も足を運ぶことで、仲間を作ることができる 特に印象的だったフレーズは「 問いを育てる 」というものでした。 AIを使った開発がスタンダードになり、なんでもすぐにAIに聞くのが当たり前になったいま、自分で考える力が落ちてきているのではと、個人的にも危機感を持っていたタイミングでした。 そんな中で聞いた「 問いを育てる 」というフレーズは、これまでの自分にはなかった視点で、シンプルながら強く心に残りました。 この発表が一日のタイムテーブルの最後に置かれ、直後に懇親会が控えていたことも、「コミュニティに集まる意義」を物語るような構成に感じられて感動しました。 実際、その後の懇親会では、普段よりもさらに深く交流を楽しむことができたと感じています。 参加メンバーからのコメント wakana 今回初めてPHP Conferenceに参加することができました！ ブーススタッフとして朝早くから集まり、カンファレンス後の懇親会まで参加しました。1日を通してとても楽しく充実していて、帰る頃には学生時代の文化祭後のような清々しい疲労感がありました。 スポンサーブースではたくさんの来場者の方とお話することができ、「サービス使ってます！」「ノベルティかわいい！」といった嬉しいお声をいただいたり、さらには「今の仕事を進めるうえで困っていることがあり、BASEさんではどのように解決していますか？」といったディープな内容のお話まで楽しく交流させていただきました。 他のスポンサー企業様のブースにお邪魔した際も、近い悩みを共有できて立ち話が思わぬ盛り上がりを見せました。実は当日の朝までは夜の懇親会に参加しない予定だったのですが、「来られるならぜひお話ししましょう」とお声掛けいただいたのをきっかけに、その場でチケットを購入しました（笑）。おかげで、今後の共同イベントをご一緒する予定の会社様のエンジニアの方とも交流を深められ、思い切って参加して本当によかったと感じています。 セッションで得られる学びはもちろんですが、コミュニティの温かさやウェルカムな雰囲気は、これまで参加したイベントの中でもダントツでした。 ぜひまた参加したいです！ 白数（ かじゅ ） 今回、PHP Conferenceにスポンサーブーススタッフとして初めて参加しました。 スポンサーブースの企画段階から関わり、「あれはどう？」「これはどう？」とメンバーでわいわい意見を出し合いながら、楽しく準備を進めることができました。 実施した「BASEロゴ検定」をきっかけに、1人でも多くの方にBASEが運営するサービスについて知っていただけたら嬉しいです。 当日は、初めてお会いする方々と企画や会話を通じて交流し、セッションもいくつか聴くことができました。 PHPコミュニティの活気を直接感じられる貴重な機会となりました。 三佐和 初参加の PHP Conference でした！ 普段 PHP をあまり書いていない身としては、「参加しても大丈夫かな…」と最初は少し不安もありましたが、スポンサーブースの企画から当日まで携わることができ、とても貴重な経験になりました。 当日はブースに来てくださった方々がクイズを通して BASE のサービスに興味を持ってくださる様子を見ることができたり、普段利用しているサービスの感想を直接聞けたりと、来場者の方々と雑談を交えながらお話しする時間がとても楽しかったです。 また、スタンプラリーにも参加してみましたが、各社それぞれ企画だけでなくノベルティにも個性や特色が表れていて、ブースごとに異なる雰囲気を楽しめたのが印象的でした。 今回のカンファレンスを通して、技術だけでなく、人と人、企業同士がつながることの魅力や、イベントづくりの面白さを感じることができました。 また機会があればぜひ参加したいです！ 地引 初めてPHP Conferenceに参加しました！ 私はスポンサースタッフではなく、インターン生として先輩（Capi(かぴ) さん）と一緒に一般参加させていただきました。 現地で参加したセッションはどれも刺激的で、ものづくりやコーディングを純粋に楽しんでいる熱量あふれる方々の発表がとても印象的でした。AI時代ならではの開発の工夫や考え方にも触れることができ、ものづくりの面白さを改めて実感しました。 懇親会では、BASEの先輩方が本当に温かく、他社のエンジニアの方や先輩のお知り合いの方をたくさん紹介してくださいました。周りに学生が少なく緊張していたのですが、いろいろな方と交流するきっかけを作っていただけたことがとても嬉しく、改めてBASEの温かさを感じました。 技術的な学びだけでなく、新しい人とのつながりやコミュニティの温かさも感じられるイベントで、参加してよかったと心から思える一日でした。 またぜひ参加したいです！ おわりに カンファレンスのクロージング後、一日ブーススタッフお疲れ様、そしてかがのさんLTお疲れ様でした〜！ということでみんなでパシャリ。（一般参加として来ていた Capi(かぴ) さん 地引さん も加わってくれました！） ブーススタッフとして参加したメンバーの内半分以上が初参加というフレッシュな構成でしたが、全員の協力のおかげで何事もなく終えることができました。 また、PHP Conference の運営スタッフのみなさまも、お忙しい中、多くの時間をイベント準備に割いてくださったことと思います。 こんなに貴重な機会をいただけたことに、この場を借りて心より感謝申し上げます。 BASEではエンジニアを募集しています。よろしければ、採用情報もぜひご覧ください！ binc.jp

みなさん、こんにちは。ソリューションアーキテクトの呉(オ)です。 2026 年 6 月 11 日（木）〜 12 日（金）の 2 日間、AWS の拠点にて、9 社 11 チーム・約 90 名のお客様と一緒に AI-DLC Unicorn Gym（AI 駆動開発ライフサイクルを体験する実践型ワークショップ）を合同開催しました。参加各社が「自社の実際の業務課題」を持ち込み、Kiro と Claude Code を使って、ユーザーストーリーの作成からモック、実装、成果発表までを走り抜ける 2 日間です。 本記事では、複数社が同時に自社ワークロードで AI 駆動開発を体験したこの合同開催で何が起きたのか、どんな成果と気づきが生まれたのかをレポートします。 AI 駆動開発ライフサイクル（AI-Driven Development Lifecycle, AI-DLC）とは AI-DLC は、AI を開発プロセスの中心に据える開発手法です。AI をアシスタントとして後から付け足すのではなく、AI が実装を担い、人間は「何を作るか」「その出力は正しいか」を判断することに集中します。 プロセスは大きく 3 つのフェーズで構成されます。 Inception（インセプション）：解くべき課題を定義し、ユーザーストーリーへ分解する Construction（コンストラクション）：AI と対話しながら並行して実装する Operation（オペレーション）：運用・改善につなげる 特徴的なのは、「モブ」と呼ばれる進め方を重視する点です。モブとは、チーム全員が 1 つの画面を囲み、一人が操作役（ドライバー）となって手を動かしながら、残りのメンバー全員が意見を出し合い、その場で議論して進める共同作業のスタイルです。役割を固定して分業するのではなく、全員が同じ情報を見て一緒に考えることで、認識のズレを防ぎ、判断の質を高めます。AI-DLC では、要件を練り上げる Inception を全員で行う「モブエラボレーション」、実装を全員で進める Construction を「モブコンストラクション」と呼び、いずれもこのモブを基本形とします。Unicorn Gym ではこのプロセスを座学ではなく、自社の実テーマで 2 日間走り切ることで体で覚えていただきます。AI 駆動開発ライフサイクルの詳細については、 AI 駆動開発ライフサイクル：ソフトウェアエンジニアリングの再構築  をご参照ください。 9 社 11 チームが持ち込んだテーマ 今回集まったのは、事業ドメインの異なる 9 社でした。BtoB の卸・仕入れサイトや企業間決済・売掛保証サービスを展開するラクーン（ラクーンホールディングス）と、キャラクタービジネスで知られるサンリオは、それぞれ 2 チームで臨み、全体では 11 チームが同じ会場に机を並べました。DX 現場支援を強みとするメンバーズ、幅広い業界のシステム開発を担うテクノブレイブ・ニーズウェル・科学情報システムズ（SIS）、大手企業の DX 内製化を支援する情報戦略テクノロジー、法務業務を効率化するリーガルテックの GVA TECH、そしてコンビニ ATM 最大手のセブン銀行です。B2B プラットフォーム、エンターテインメント、システム開発、リーガルテック、金融と、まったく異なる事業領域のプレイヤーが一堂に会したことになります。 参加各社は、練習用の題材ではなく「今まさに解きたい実課題」を持ち込みました。テーマは、新規サービス機能の立ち上げ、社内基幹システムへの機能追加、営業支援、提案書ドラフトの自動生成、ピープルマネジメントなど多岐にわたります。 Day 1: Inception 「まず何を作るか（作らないか）を決める」 初日の午前は、いきなり自社テーマに入るのではなく、まず AI-DLC の考え方の説明と共通題材を使ったハンズオンから始めました。Kiro の操作感やユーザーストーリーからモック作成、実装へと進める一連の流れを、全員が同じ題材で一度体験します。この助走を挟んでから本番に臨みました。チームは、各社が自社の PdM（プロダクトマネージャー）とエンジニアで編成しました。実際に手を動かして議論を主導するのはお客様自身で、AWS のメンバーは技術的に詰まったところの解消やフェーズの進め方のガイドに徹し、チームの自走を後押しする役に回りました。 午後からは、各チームが自分たちのテーマをユーザーストーリーへ分解する Inception に本格的に取り組みました。ここで多くのチームが口を揃えたのが、「まず対象を決めることに時間をかけたのが効いた」という気づきです。実装が速いからこそ、入口の「何を作るか」が成果を左右します。象徴的だったのは、「どこまで作るか」を大胆に絞り込んだチームです。セブン銀行のチームは、洗い出したユーザーストーリー 29 件のうち 13 件をその場でカットし、初日のうちに 16 件まで絞り込みました。サービスデザインの視点から参加したメンバーは、「どこまでを人間が決め、どこからを AI に委ねるか」という線引きこそが今回の一番の学びだったと振り返ります。スコープを決めるのは、あくまで人間の仕事だという実感です。その「人間が決める」を象徴する場面もありました。ラクーンのチームでは、AI がある機能を「マストだ」と提案してきました。しかし、同チームではその機能は当面手動運用でカバーできると割り切り、AI が「マスト」とした機能をあえて優先度の低い区分へ格下げしました。AI の提案をそのまま鵜呑みにするのではなく、事業の文脈を踏まえて人間が最終判断を下す、Inception ではこうした「AI が提案し、人間が決める」という役割分担が随所で見られました。また、AI にインタビューされながらユーザーストーリーを固めることで、リリース後の不正対策といった人間だけでは抜け落ちがちな観点まで AI が先回りして拾う場面も見られました。 各チームの開発風景（サンリオ／ニーズウェル／科学情報システムズ／セブン銀行） Day 2: Construction 「動くものを見ながら、その場で会話する」 2 日目は、並行して実装できるサブチームに分かれて実装を進め、最終成果発表へ向かいます。参加チームから最も多く声として挙がった一番の価値は、「動くものを見ながら、ビジネス側と開発側がリアルタイムに会話できたこと」でした。従来は、要望を伝えてから次のバージョンが上がってくるまで数週間のタイムラグがありました。それがこの 2 日間では目の前で動く成果物を見ながらその場で方向を変えられる、このフィードバックの即時性が多くのチームで共通の手応えになりました。一方で、AI が高速に生成物を出すぶん、「その出力が正しいかを判断し続ける」負荷が人間側に集中する、という声も複数上がりました。「もっともらしいコードがすぐ出るからこそ、正しさの見極めが難しい」「判断の連続で頭は疲れるが、面白い」「AI に任せるほど、人間の判断力が試される」 など、その手応えと難しさの両方を体感する時間でもありました。成果発表では、各チームが 2 日間で作り上げたものを発表しました。完成までたどり着いたチームや実装ゼロで並行開発の設計に振り切ったチーム、アプローチは様々でしたが、いずれも自社に持ち帰る具体的な手応えを掴んでいました。 各チームによる Day 2 成果発表の様子 各チームのハイライトとお客様の声 成果発表で各チームが見せてくれた成果から、印象的だったものを紹介します。 新規アプリの運営管理画面に取り組んだチームは、「Kiro は 1ヶ月と見積もった。私たちは 2 日で 80% 終わった」と話します。Kiro が当初約 1 ヶ月と見積もった開発を 2 日間で 8 割完成させ、自社ドメインの実サブドメインへのデプロイまで到達しました。後回しにされがちな運営管理画面のような領域こそ、AI に任せることで一気に前へ進むという手応えが語られました。 既存の社内管理システムに操作履歴機能を追加したチームは、「2 ヶ月の開発が 2.5 日で見通せる可能性がある」と振り返ります。AI による既存ソースコードの読み込み精度の高さに驚き、従来 2 ヶ月相当の開発が 2.5 日で見通せる感触を得ていました。同時に「手戻り＝悪」という常識が覆り、「戻りやすさを設計しておけば、手戻りコストは構造的に低い」という発想の転換も語られました。 営業支援システムに取り組んだチームからは、「数人で数ヶ月分の差分が 1 日弱で出せた」という声が上がりました。実際に 1 日弱で約 14,000 行の差分を生成し、非エンジニアの責任者と事業ドメインの観点で議論できたことが最大の収穫だったと振り返ります。 5 人・5 台の PC で誰も 5 分以上手を止めない並行開発とコードを一切書かず AI とエンターキーだけで進めるという 2 つに取り組んだチームからは、「合意と設計に投資したら、コンフリクトはゼロになった」という言葉が生まれました。初日から 2 日目の午前まで一行もコードを書かず、全員が並行開発できる構造の設計に投資した結果、コンフリクトゼロで並行実装を走り切っています。クロージングの一言「Don’t write code, Write construct.（コードを書くな、構造を作れ）」は、AWS メンバーにも印象的でした。 商品企画出身の PdM が、「生まれて初めてプルリクエストを送れました」と語る場面も生まれました。AI との対話を通じて人生で初めて Pull Request (PR) を送り、さらに Inception のスキル化（AI がインタビューしてユーザーストーリーとドキュメントを生成し、PR でマージする仕組み）まで自作して再現性も確保していました。 これらの成果に加えて、合同開催ならではの声もありました。 「他社さんと一緒に取り組めたのがとても刺激的でした。発表で各社のドメインがにじみ出て、自社への適用イメージがどんどん湧きました。」「開発生産性がかなり上がることを実感しました。お客様への提供スピードが上がるので、ビジネスインパクトの面でも有意義でした。」「プロダクトを AI-DLC で作る経験ができて、純粋に楽しかったです。」 ポジティブな声だけではありません。 「判断の連続で疲れた」「AI に情報を渡し忘れ、AI が置いてけぼりになった」「既存システムの拡張は、作るべき範囲の議論が複雑になる」。こうした率直な気づきも、次に活かすための貴重な学びとして共有されました。 2 日間で見えた手応え 2 日間を通じて、参加各社が共通して手応えを感じたのは次の点でした。 動くものを見ながら、ビジネスと開発がリアルタイムに会話できること AI による既存コードの読み込み精度の高さ（レガシー資産の棚卸しに有効） 音声入力がタイピングより圧倒的に速いこと Inception をスキル化し、再現性と抜け漏れ防止を両立できること 合意形成と設計に投資すれば、コンフリクトゼロの並行開発が実現できること いずれも、「AI を開発の中心に据える」という進め方だからこそ生まれた実感です。 イベント後のアンケートでは、満足度は 5 点満点中 4.7 点、93.9% の参加者が肯定的な評価（4 点以上）を寄せています。また、体感された工数削減率は平均 74.0% にのぼりました。なお、継続して伴走支援を受けたいという声も多く寄せられ、この 2 日間が終わりではなくそれぞれの現場での始まりとして受け止められたことがうかがえます。 おわりに この 2 日間で最も印象的だったのは AI が実装を肩代わりするほど、人間の仕事が「書くこと」から「決めること」へと移っていく、という共通の実感でした。参加各社は、それぞれのドメインでその手触りを掴んで帰っていきました。そして、複数社が同じ場で真剣に取り組む合同開催だからこそ、互いの成果が刺激となり、自社でもできるという確信が生まれました。AWS はこうした AI 駆動開発への挑戦を、これからも各社の現場に寄り添いながら伴走していきます。 自社のワークロードで AI-DLC を試してみたい、という方は、ぜひお近くの AWS 担当者までお声がけください。AI-DLC に興味を持たれた方は、 aidlc-workflows  をチェックしてみてください。Kiro や Claude Code などを使って AI-DLC を始めるためのワークフローやテンプレートが公開されています。 集合写真 著者 Oh Minjung （オミンジョン） AWS Japan のソリューションアーキテクト。お客様のクラウドジャーニーにおける技術的なご支援をしています。その活動の傍ら、最近は AI 駆動開発ライフサイクル(AI-DLC) の布教活動をしています。