こんにちは、エス・エム・エスでカイポケコネクトのエンジニアをしている加我 ( @TAKA_0411 ) です。 私事ではありますが、日本のDatadogコミュニティの活動や社外での登壇の実績を評価されまして、2026年度の Datadog Ambassadors に選出いただきました。 もともと好きが高じて続けてきた活動ではありますが、それらがオフィシャルに評価されたというのは感慨深いものです。今後も積極的なDatadog活用や知見の共有、仲間集めのためのコミュニティ運営を続けていきます。 そういえば、3月に開催されたJAWS DAYS 2026では私も登壇者・ブース担当者として参加していたのですが、Datadog社のブースにて非常に気になるデモを拝見しました。 DatadogのWeb UIから生成AIと会話し、データの調査や分析を行う機能……それが私とBits Chat（当時はBits Assistant）との初めての出会いでした。直感的にこの機能に可能性を感じ、担当営業の方を通じてPreviewにおけるBits Assistantの利用について相談しました。相談から少し時間が経ったタイミングで利用が可能になったので使ってみたところ、非常に便利でした。これは自分だけではなく開発組織全体に知ってもらいたい。そう思ったのがこの記事を書いたきっかけです。 面白いものを見つけたぞのノリで社内共有します Bits Chatについて Bits ChatはDatadogのWeb UIからチャット形式でやり取りすることにより様々な支援を受けられる、生成AIを活用したサービスです。Datadogに蓄積されているデータに対し、下記の機能を提供しています。 問題の調査と対処 テレメトリデータの探索と分析 Datadogの概念や使い方の学習 オブザーバビリティの設定と最適化 docs.datadoghq.com 画面右上のAsk Bitsから呼び出すことができます Bits Chatが活躍するユースケースとして、Monitorのエラー通知からの原因調査、ダッシュボードにおける特定期間のデータ分析、用途を伝えるだけで最適なダッシュボードを作成してもらうといったことが可能になります。つまり、これまで私たちが手動で行ってきた多くの作業をBits Chatがこなせるようになります。 余談ですが、Bits ChatはPreviewによるサービス提供当初はBits Assistantと呼ばれていました。2026年6月に開催されたDASH 2026にてBits Chatと名称変更がされ、BitsというAI機能群のうちの1つとなりました。Datadogには多くの機能があり、新機能も次々と追加されますが、Bits Chatをハブにして活用方法を学んだり実際に設定してみたりすることが可能になります。 www.datadoghq.com さて、私はPreviewでの機能利用が可能になった段階から社内でもりもりBits Chatを使い込んできました。そんな私が得られた知見や開発チームの変化についてご紹介します。 Datadog民主化の鍵はBits Chatである 使ってみて気づいた1つめの大きなメリットがこちらです。Bits Chatを活用することにより社内のDatadog推進者 / Datadogチャンピオン *1 への依存が軽減され、開発者が自発的にDatadogを利用する文化の醸成に貢献してくれます。 Bits ChatはDatadogについて熟知しています。ユーザーが実現したいことや抱えている問題、テレメトリデータの分析方法、ダッシュボードの作成など、様々なテーマについてアドバイスを得ることが可能です。このような動きをするBits Chatを私は「Bits Chat as an Internal Datadog Champion」と表現しています。そうです、Bits Chatは社内で一番Datadogに詳しいチャンピオンなのです。 自社もしくは自分が担当しているプロダクトへのDatadog導入を推進したことがある方はご理解いただけるかと思いますが、Datadogを導入してから安定した運用に至るまでには下記のような多くの問題が発生します。挙げ始めたらキリがありません。しかし導入を推進する人は強い推進力とオーナーシップを持っているため、これらの問題を1つずつ解決し、社内のドキュメントに残し、設定をコード化することで安定したDatadog活用に導くわけです。 そもそもDatadogの使い方がわからない（学習コスト） Datadogがあっても別のツールを使おうとする（ツールのサイロ化） UIが複雑で機能がどこにあるかわからない データの表示切り替え方法がわからない いい感じのダッシュボードを作るのが困難 意図したアラートを設定できない Datadog推進者のSPOF問題 社内のDatadog推進者が色々な問題を解決し、運用を安定させていくにつれて発生する別の問題があります。それは「Datadogの社内活用の拡大が推進者に依存してしまう」「Datadog推進者がSPOFになってしまう」という問題です。 皮肉にもDatadog推進者が強いオーナーシップを発揮するほど「Datadog推進者の人がやってくれる」「Datadog推進者の人にお願いすれば良い」という空気感が出来上がってしまい、Datadogの民主化、ひいてはオブザーバビリティの民主化からどんどん離れていってしまうのです。解像度の高い話をしているなと思った読者のあなた、鋭いですね。これは過去の私自身への自戒です。 Datadog活用のあるべき姿 Datadogは開発組織全体で使うことにメリットがあると私は考えています。特定の誰かが使えるだけではDatadogを活用できている状態とは言えないのです。過去にDatadog推進者のSPOFという原因の一端を担ってしまった私がBits Chatを見て感じた可能性が「Bits ChatこそがDatadog民主化の鍵」でした。 開発者が自発的・自律的にBits Chatへ現在発生している問題や実現したいことを相談すれば、開発組織全体でDatadogを活用でき、結果としてサービスのオブザーバビリティが高まると私は信じています。 ちなみに、Datadogの民主化を促すために最近私が力を入れているのがBits Chat誘導員という役割です。以前はBits Assistantのアシスタントなどと言っていた時期もありました。開発者がDatadogの活用で困ったらすぐさまフォローに入りつつBits Chatへ誘導し、本人にBits Chatとの会話を通じて自身で課題を解決する体験をしてもらうことを率先してやっています。また、アラートが発生した場合は自分が積極的に調査に参加してBits Chatの活用事例を知ってもらう機会も作っています。 こうした取り組みの結果、開発者がBits Chatを活用して自発的に課題を解決したエピソードも生まれています。とある非同期処理をバックエンドで実装するにあたり、処理が別スレッドに移ったこと、そしてスレッドプールが溢れないことをテレメトリデータから確認したいというニーズがありました。これに対し、社内のエンジニアはBits Chatと対話することでSpanの計装とスレッドプールの監視を自力で完遂していました。ご本人曰くDatadogに特別詳しいわけではないそうですが、対話を重ねることで無理なく実装できたと言っていました。 私というDatadogチャンピオンの出番がないまま解決してしまったわけで、これは民主化の一歩と呼べる出来事でした。 Bits Chatとの会話ログの一部を見せてもらいました テレメトリデータ分析会の活性化 私が所属しているチームでは定期的にサービスのCUJ (Critical User Journey) のデータをまとめたダッシュボードの分析会を行っています。しかし、以前はダッシュボードを見てもデータの分析方法がよくわからなかったり、どのデータを見たら問題発見や改善アクションに繋げられるのか迷うことも多く、価値のある時間であるとは言い難いものでした。テレメトリデータはDatadogに蓄積されているため、ダッシュボードを作り直そうかなどと考えていたのですが、このデータ分析自体をBits Chatにやらせてみようという取り組みを始めました。 分析するなら意味のある会にしたいという議論もありました 分析の方法として、CUJのデータをまとめたダッシュボードに対してBits Chatから「ダッシュボードのデータの分析をしてください。分析するための条件は〜〜です。分析したデータはNotebookにまとめておいてください」といった形で分析を依頼していました。数回やっているうちにNotebookのCustom Templates機能を使えばある程度再現性のある形で実行・保存できるのでは？と気づき、最近では専用のNotebookテンプレートを用意し、そのフォーマットに沿って分析依頼を行っています。 分析用のプロンプト例 (クリックすると展開されます) Custom Templatesの例 # 分析用のプロンプト例 CUJに関するデータについて下記の観点を中心に比較・分析し、Notebookとして保存してください。 Notebookのテンプレートは「CUJ分析レポート - {mm-1}月 vs {mm}月比較 」を使用し、テンプレート中の{mm}には当月の数字を、{mm-1}には前月の数字を、{対象サービス}には"sample-app" を入れて置き換えてください。 また、Notebookへのデータ追加時にはテンプレートのフォーマットを必ず遵守してください。 以下は分析対象です。 ■ 分析対象 ・CUJサービス: service:sample-app (GraphQL Operation別に集計) ・重点分析サービス: service:sample2-app ・RUM: sample-frontend ■ 条件 ・分析対象の期間: 前月1日〜前月11日 vs 当月1日〜当月11日 ・環境: production ・Operation: ◯◯関連のOperationName呼び出し回数Top10 + △△関連のOperationName呼び出し回数Top10 ■ 比較観点 ・GraphQL Operationの呼び出し回数の変化 ・レイテンシ(P95)の変化 ・エラー数の変化（エラー率も算出） ・CUJのLatencyのP95で500msecを超えるGraphQL Operationの有無 ・sample2-appの新規Operation出現有無 ■ RUM分析 ・全体: ビュー数/セッション数/P95ロード時間/エラー合計 ・遅延ページ: P95 > 1秒のCUJページ抽出 ・XHRボトルネック: 最も遅い外部リクエストの特定 ・エラー分類: Top10エラーの分類と対応要否判定 ■ 計測単位 ・呼び出し回数: リクエスト単位（@_top_level:1） ・エラー: 子スパン単位とリクエスト単位を併記 ■ P95 > 1秒判定のデータソース ・custom.sample-app.graphql.request.duration メトリクス （スパン保持期間を超える場合に対応） ■ 追加分析（可能であれば） ・アクティブユーザー数との相関 （データソース: Sheets「ユーザー数管理」） ■ 出力形式 ・サマリー（全体評価テーブル + キーインサイト）を冒頭に ・推奨アクション（優先度高/中/ポジティブな変化）を末尾に ■ 関連リソース ・ダッシュボード: /dashboard/aaa-bbb-ccc/cuj-dashboard この分析方法に変えてからダッシュボードの分析会に変化が見られました。Bits Chatがまとめてくれたデータを見つつ、データに対する疑問だったりデータの見せ方の工夫に関する意見が積極的に出るようになりました。 なぜこのエンドポイントでのエラーがこんなに発生しているのか エラー数はリクエスト単位とスパン単位でデータを出し分けた方がいいのではないか（Next Actionへ） このエラーは原因を調べて対処したほうがいいのではないか（Next Actionへ） ユーザー数の増加とGraphQL Operationの実行回数に相関はあるのか フロントエンドのボトルネックは◯◯が原因そうなので調べてみてもいいのではないか ユーザーの利用増加を数字から感じられて良い 実際私もダッシュボードの分析会で発見したエラーの原因を調査し、バックエンドのエラーハンドリングを改善するといった対応を行うことができました。Bits Chatは具体的なソースコードの改善方法も提案してくれるので、私のような開発経験が少ない人間でも積極的にサービスの改善に繋げることができます。 突出しているエラーの改善をやったりしてます 最高のデバッガーを支えるBits Chat とある日の午後、1つのアラートが発生しました。レスポンスタイムが基準値を上回っていました。私も調査に入りつつBits Chatにアラート原因の分析を依頼し、別のエンジニアはログの分析をしてくれていました。 Bits Chatを使いつつトレース・ログ・メトリクスのデータを分析してみます。どうやら別のチームがオーナーとなっているシステムが関連していそうです。そして私はあまりそのシステムの中身を知りません。Bits Chatがまとめたデータを見てみると該当の時間帯にECSのCPU使用率が高まっていることがわかりました。じゃあなぜこのタイミングで使用率が高まるのかを調べてみます。自分も実際に関係しそうなソースコードを見て、微力ながら議論に参加していたわけですが、結論としてはデプロイ中にリクエストを受けるとタイミング次第でリソース消費量が高まってしまうという現象であることがわかりました。 私はデータの拡充という観点からDatadog Continuous Profilerを有効化し、オーナーであるチームはリソース消費量を抑えるための具体的な施策について議論していました。また、デプロイ完了のタイミングも改善が可能では？という議論が続きます。 今回のアラート対応を経て、私が開発であまり携わっていないシステムのことについても少しだけ詳しくなり議論に加わることができました。自分がよく知らないシステムの調査は大変です。しかしBits Chatの助けを借りることで仕様の理解と現象の理解を無理なく行えるのがよくわかりました。 そしてこれは、私だからできたという話ではありません。書籍『オブザーバビリティ・エンジニアリング』では、オブザーバビリティを実践しているチームにおける最高のデバッガーは好奇心が強いエンジニアであると述べられていました。裏を返せば、デバッグに必要なのは深いシステム知識ではなく好奇心ということになります。その知識の差はBits Chatが埋めてくれます。開発経験が少ない私でも越境して調査に加われました。好奇心さえあれば、多くの開発者が同じように動けるはずです。Bits Chatの力と好奇心を武器に、どんどんアラート対応して学んでいきたい所存です。 www.oreilly.co.jp まとめ Bits Chatのユースケースや社内での活用例、その結果もたらされたものについて書いてみました。改めてBits Chatが私たちの開発組織にもたらしたものを3つ挙げます。 社内のDatadogチャンピオン（例えば私）を頼ることなく、開発者が自発的にBits Chatと対話し、エラーの原因分析や計装の改善を進めるようになりました。社内で一番Datadogに詳しいのはもう私ではなくBits Chatです。 ダッシュボードの分析会が「データを眺めるだけの会」から「Next Actionが生まれる会」に変わりました。分析そのものをBits Chatに任せることで、私たちはデータへの疑問や改善アクションの議論、ひいてはユーザーへの価値提供に時間を使えるようになりました。 開発経験の多寡を問わず、担当していないシステムの調査にも越境して加われるようになりました。よく知らないシステムであっても仕様の理解と現象の理解を無理なく進められます。 Bits Chatは便利です。開発組織にとても多くのメリットをもたらしてくれます。Datadogを使っているけど上手く使い切れていないという課題を感じている方は導入をオススメします。一見コストが高いと感じられるかもしれませんが、利用することで得られるものは少なくないはずです。 今後の課題 一方でBits Chatはトークンを消費してアクションを行うので、どのように運用すればトークンが最適化されるのかを考えなければなりません。複数人でアラート対応をしている際、各自がばらばらにBits Chatへ質問をするとトークンが無駄になる可能性があるため、この場合の最適な運用フローを今後整備していく必要性を感じています。また、Bits Chatへ頼りきってしまい、ダッシュボードの整備が全くできていないという状況を招かないよう気をつけていきたいと思います。 私個人としましては、エンジニアが自分の言葉でBits Chatとやり取りして問題を解決する（もしくは解決の糸口を見つける）というのは大事な体験であると思っているので、あまり制限せずに効率的な運用ができたらなーと考えています。Bits Chat愛好家のみなさま、コスト最適化についてぜひディスカッションしましょう！ *1 : 強いモチベーションと推進力で導入を牽引する人。公式のDatadog Championsではありません

1. はじめに 以前、以下の記事でAWS AI Leagueについて紹介しました。 https://zenn.dev/nttdata_tech/articles/a907eb00cbbe4b AWS AI Leagueは、競技形式で生成AIの技術を学ぶプログラムです。主に、次の2つのテーマが用意されています。 Amazon SageMaker AIを利用したモデルのファインチューニング Amazon Bedrock AgentCoreを利用したAgentic AI Agentic AIチャレンジでは、AIエージェントがマップ上を移動し、コインの取得や質問への回答などを行いながら、

こんにちは、エス・エム・エスでカイポケコネクトのSREをしている 小笠原翔太 です。 2026年7月10日に開催された SRE NEXT 2026 のスポンサーセッションで、「 PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用 」というタイトルで発表しました。 発表スライドも公開していますが、せっかく取り組みについて文章をまとめたのでテックブログにも展開しようと思い、まとめ直したものがこちらの記事となります。発表内容に加えて、ブースで展示していた現在のpreview環境のアーキテクチャについての補足説明も加筆しているので、そちらは発表との差分となっています。 はじめに 全体の話はひとことでいうと、 既存プロダクトにPR単位で使い捨てられるpreview環境を導入し、1年間運用してきた話 です。 目次 はじめに 目次 カイポケコネクトと開発フェーズ カイポケコネクトとは システムアーキテクチャ 開発フェーズ 当時のリリースフロー リリーストレインの課題 1. リリース周期が長い 2. QA環境の利用が詰まる 3. 担当者の負担が大きい 解決策： 検証作業を分離して並列化する preview環境をどう設計したか 必須要件 インターフェース設計 アーキテクチャ デプロイフロー サービス構成 設計時に考えたこと 運用してどうだったか 狙いどおりリリース頻度を高められた 段階的に改善しながら育てた 結果的に利用が伸びた 運用してわかったこと 1. 複製機構の利用技術についてわかったこと 2. 複製「できない」外部サービスとの付き合い方が難しい 3. preview環境の想定外な需要が見えた まとめ 付録: 現在のアーキテクチャの紹介 カイポケコネクトと開発フェーズ カイポケコネクトとは 最初に、私たちが扱っているシステム「カイポケコネクト」は、介護/障害福祉事業者向け経営支援を行うSaaSプロダクトです。 システムアーキテクチャ カイポケコネクトのシステムアーキテクチャは、拡張性と独立性を保つためドメインごとにアプリとDBを分割して設計しています。 利用されている技術スタックと本番系の基盤構成は次のとおりです。 レイヤー 技術スタック 本番系の基盤構成 フロントエンド React / Next.jsによるSPA CloudFront + S3 バックエンド Kotlin / Spring Boot / GraphQL ECS Fargateでホスティング。5つのタスクでGraphQL APIを構成 DB PostgreSQL RDS Aurora PostgreSQL また、本体サービスとは別の複数の社内サービスとも連携しており、バックエンドのコンテナ数から考えると中規模サイズのシステムと捉えてもらうと良さそうです。 開発フェーズ プロダクトは初期の開発フェーズが完了し、プロダクトの価値を拡大する「機能追加・サービス拡大フェーズ」へ移行しようとしているタイミングでした。 そのため、 プロダクト開発の生産性を支えるために機能開発を加速させる必要があった というのが背景です。 当時のリリースフロー そのような開発の事情があるなかで、当時のリリースフローは以下のようになっていました。 当時のリリースフロー デプロイ先のAWS環境はDev, QA, Staging, Productionの4つ用意してそれぞれ使い分けていました。 まず開発フェーズでは、開発者がPRを用意してテストが通ればmainにマージしてDev環境にデプロイしていました。Dev環境は開発者が最初にデプロイするAWS環境で、少し壊れやすいのですがアプリの動作検証や基盤の構成変更の検証を行う用途で利用されていました。 一方で、本番系へのリリースフェーズでは、それとは別で リリース担当やリリースマネジャーが主導してデプロイする方式 を取っていました。 具体的には以下の流れでリリースが行われていました。 リリース担当がリリースするrevisionを決めてコードフリーズを行い、そのrevisionでQA環境へデプロイする 全QAメンバーがQA環境を占有して検証作業を実施 リリース担当がリリースタグを作成し、Staging環境へデプロイする リリース担当がテストランナーでE2Eテストを実行する リリース担当がリリースタグを作成し、Production環境へデプロイする QA環境はバージョンを固定して検証を行うための専用環境、Staging環境はE2Eテストを実行して意図しないデグレが発生しないことを保証するための環境という建付けでした。 つまり、いわゆる リリーストレイン方式でリリース していました。 リリーストレインの課題 このプロジェクトにおけるリリーストレインには大きく以下3つの課題がありました。 1. リリース周期が長い 最も大きな課題はリリース周期が長いこと です。このプロジェクトのリリースサイクルは2週間に一度でした。 開発スピードに対してリリースサイクルが長いため、価値提供の大きなボトルネックになっていました。またリリース時には2週間分の差分がまとめて本番へ反映されます。そのためリリースのタイミングで事故が起きやすく、問題発生時の切り分けも難しい状態でした。 2. QA環境の利用が詰まる 次の課題としてはQA環境の利用が詰まるという問題がありました。QA環境は検証用の占有環境として利用され、かつ 全QAメンバーが直列に検証作業を行うためどうしても長期間ロックされてしまいます 。結果的に検証期間が長引き、当時は1週間ほど環境を確保するようになっていました。 検証作業を効率的に実施できず、その間は新しいリリースもブロックされる構造になっていました。 そのため、 今後開発を加速させようとしたときに、ここの詰まりによってスケールできなくなることが容易に想像できました 。 3. 担当者の負担が大きい リリーストレインのもう1つの問題として、取りまとめを行う人の負担が大きいという人的な問題もありました。リリース担当やリリースマネージャーがリリースを主導する必要があるのですが、そこに 運用作業とリスク管理の負荷が集中 していました。 ミスを防ぐための手動プロセスや手順も増えがちで、運用が重厚になっていました。さらに、リリースされる差分のすべてを把握することが困難でした。そのため、問題発生時の対応に手間取ったり、チームをまたいだ調整コストが増えたりして、担当者を疲弊させていました。 解決策： 検証作業を分離して並列化する 解決策として考えたのは「 リリースフローから検証作業を分離して並列化する 」ことです。 以下の図は検証作業を分離・並列化したときのリリースフローの概念図です。 検証作業を分離・並列化したリリースフロー これまでリリースフェーズで行っていた QA環境での検証作業をすべて開発フェーズに移行 しています。 開発フェーズで開発者がPRを作成したあとに専用の検証環境を立ち上げ、QAメンバーがPRごとに検証作業を並列で実施できるようにします。 そして、リリースフェーズでは、Dev環境にデプロイした後は毎日定時にGitHub Actionsのscheduled workflowを起動します。このジョブはStaging環境へのデプロイからE2Eテストの実行、production環境へのデプロイまでを連続して実行する軽量なワークフローです。 また、リリースフラグを導入することで、PO（プロダクトオーナー）が任意のタイミングで新機能をリリースできるようにします。 この方式に変更することで次の効果を狙います。 リリースが毎日できる ：隔週から毎日へと頻度が上がり、価値提供が高速化。デプロイごとの変更差分が小さくなり、原因特定も容易になる QAのシフトレフトと並列化 ：検証作業を開発フェーズに移すことでリリースを安定化させ、チームや機能ごとに検証作業を並列化することで詰まりを解消する プロセスの軽量化 ：重厚なリリース手順を廃止し、リリースフローを自動化・軽量化する。リリースフラグを導入することでデプロイと新機能の有効化（機能リリース）を分離する 先ほど紹介したリリーストレインの主要課題をすべて解決できるようになっています。 preview環境をどう設計したか 先ほど述べた、リリース改善施策実現に必要な構成要素の1つが、検証作業を行うための環境（私たちはこれをpreview環境と命名）でした。 この章ではそのpreview環境をどう設計したかについて説明します。 必須要件 まずQAプロセスで必要な要件は以下3つでした。 十分な数の環境を 容易に 作れること 利用チームが 任意のバージョンをデプロイできる こと DBを使い捨てできること ーデータが汚れることを気にせず占有して使えること インターフェース設計 次に利用者のインターフェースの設計についてですが、こちらはVercel等のSaaSの開発者体験を参考にして以下のように設計しました。 GitHubのイベントをトリガー に、preview環境を自動で構築・更新・破棄する PRのコメントに自動で 各種アクセス情報を付与 する 以下はpreview環境を立てたPRのサンプルです。 preview環境を立てるPRのサンプル PRにラベルを付けると環境構築が始まり、完了するとbotがコメントでアクセス方法を案内する、という開発者体験になっています。 このようにインターフェースを作った理由は、以下を狙ったためです。 開発者とQAのスムーズな連携 ：開発者がPRに実装をまとめ、それをQA担当者へ渡すことでスムーズに検証作業に移ることができる ライフサイクル管理のしやすさ ：環境がPRに紐づくため、不要な環境の消し忘れを防いだり、クリーンな環境管理が可能になる アーキテクチャ 次にpreview環境のアーキテクチャを紹介します。全体像は以下のようになっています。 preview環境のアーキテクチャ全体図 デプロイフロー まず、preview環境のライフサイクルはGitHub Actionsのワークフローで以下のように管理します。 PRにpreviewラベルを付与 : PRの先頭のコミットハッシュを利用して環境を構築する PRにコミットをプッシュ : 差分が入ったコンポーネント（FE/BE/DB）のみ更新処理を行う PRをマージ、クローズまたはpreviewラベルを外す : 環境を削除する サービス構成 次にサービス構成ですが、 preview環境ごとにフロントエンド/API/DBを1セットずつ用意する ようになっています。 ドメインは https://preview-N.kaipoke.com （NはPR番号）を環境ごとに払い出しており、そこからアクセスできます。 フロントエンドはSPAなので、シンプルにCloudFrontとS3で配信しています。リクエストのホスト名に応じてアセットを出し分けるようにLambda（CloudFunction）を挟んでいます。 APIへのアクセスはCloudFrontとALBを介してmirage-ecsコンテナのproxy機能でハンドリングされ、ホスト名ごとにリクエストを各環境に振り分けています。環境ごとにバックエンドとDBが1セットずつ用意されており、バックエンドのECSタスクは mirage-ecs で、DBはSaaSの Neon でそれぞれ構築・管理しています。 なお、バックエンドは一環境あたりECSタスクが全部で5個動いており、内部でGraphQLのfederationを組む構成です。 モニタリングは本番系と同じくDataDogを利用して、トレースやログ、基盤のメトリクスを確認できるようにしています。 このような仕組みによって、 PRごとの環境をAPIやDBまで独立した形で複数個準備できるように作っています 。 参考情報ですが、環境の初期構築にかかる時間は2026/07/14時点で 10分程度 です。 設計時に考えたこと 設計にあたっては、以下3つの原則を守るようにしていました。 要件が不明確なうちから作り込まない ：初期段階での過剰な設計や実装を避けるため 運用・開発の負担が少ない技術を選ぶ ：当時は アプリ開発者のリソースが逼迫 しており、開発者の負担を極力抑える必要がありました 最初から完璧を目指すのではなく継続的に提供価値を高めていく ： 仕組み作りに使えるSREのリソースが当時少なかった ため、小さく作って継続的に提供価値を高めていく方針を採用 運用してどうだったか 実際に1年ほど運用してどうだったか、振り返っていきます。 狙いどおりリリース頻度を高められた まず 当初の狙いにしていたリリース頻度を高めることには成功 しました。 以下は月別のデプロイ回数の推移を表したグラフです。 月別デプロイ回数の推移 リリース方式を切り替えた2025年10月ごろから、 月2回だったデプロイが月20回前後まで増えました 。営業日は毎日リリースできるようになったことがわかります。 これはpreview環境以外の施策との合わせ技による成果ではありますが、 サービス拡大期の開発効率の向上に貢献できた と考えています。 段階的に改善しながら育てた そして、設計方針に従ってpreview環境は導入後に要件を適宜見直しながら改善しました。 以下のグラフはpreview環境に関するPRの月別件数推移を表しています。 preview環境に関するPRの月別件数 全体のタスク量は多く、PR総数も結果的に 200件超となっていた のですが、対応を段階的に行うことで少人数（設計から導入初期までは担当一人）でも早期に仕組みを開発に展開でき、その後の改善も継続することができました。 設計時に置いた「小さく作って継続的に改善する」という原則が、うまく機能した と感じています。 結果的に利用が伸びた 結果的にpreview環境の利用数は順調に伸びました。以下は月別のpreview環境を利用したPRの件数推移のグラフです。 preview環境を利用したPRの月別件数 導入当初は80件ほどだった利用件数が2026年6月は160件程度まで利用が伸びている ことがわかります。 あとでも触れますがこれは当初想定の用途以外の利用が増えたことも理由となっています。 運用してわかったこと 次に運用してわかったことや気付きについて大きく3つ紹介します。 1. 複製機構の利用技術についてわかったこと 今回、バックエンドの複製には mirage-ecs というコンテナ管理の軽量なOSS、DBの複製にはSaaSの Neon を使いました。 まずmirage-ecsは、既存のECS Fargate構成とデプロイの仕組み（ecspresso）にアドオンする形で導入できました。ecspressoの作者が作ったツールのため、 親和性が高くデプロイの仕組みをそのまま維持することができました 。 ツール導入で学習すべき新しい概念が少なく、メンテナンスも簡単で、開発チームへの負担を最小限に抑えながら導入できたのは非常によかったです。現在まで、他ソリューションへの置き換え検討が必要となる問題も出ておらず、安定して運用できています。 次にNeonですが、直感的で扱いやすいWeb UIや高速なブランチ機能、各種管理機能が充実しており、 DB複製機能の初期導入にかかる工数を大幅に削減できた のは良かったです。 一方で、サーバ配置先の制約による性能課題がありました。DBの配置先は最寄りでもSingaporeリージョンのため、SQL実行時のレイテンシーが大きくなり、 結果として一部のページで表示に時間を要する点が課題として残ってしまいました 。 機能検証においては無視しても問題ないということでしばらくはそのまま利用していましたが、動作がもっさりするのでなんとかしたいという声が多く出る状況でした。 そのため、現在はtokyoリージョンに立てたAurora Serverless v2（RDS）を利用する方式をメインに運用しています。付録にてそちらのアーキテクチャについては補足します。 2. 複製「できない」外部サービスとの付き合い方が難しい 2つ目の気づきですが運用してみて実感したのは、 プロダクト本体の複製よりも、複製できない外部サービスの扱いが難しい 、ということです。 本体の複製は開発チームでコントロールできるのですが、利用している外部サービス（連携する社内サービス含む）には様々な制約があり、それぞれ妥協案を作って運用していく必要がありました。 例えば認証基盤については契約プランの制約でテナントを新規作成できなかったため、既存テナントに相乗りする形で対応しました。 結果的に（特に不便なく運用できているものの）Dev環境のDBをコピーする方式を選択せざるを得なくなりました 。 ある社内サービスではアーキテクチャ上の制約により、環境複製の難易度が高くすぐには実現できませんでした。 結果的に既存環境に相乗りし、preview環境向けのデータを識別できるようにアプリを改修してもらい、運用でカバーする形になりました 。 また他の社内サービスでは、契約プランや予算管理上の制約があるため環境の複製ができないため、特定のpreview環境にのみ期間限定で連携するというような運用になりました。 これらの外部サービスに共通する課題は2つあります。1つは、 連携が増えるたびに運用の取り決めや調整を個別に行う必要があり、対応コストの増加につながる 点です。もう1つは、 自チームだけではコントロール・解決できない他部署・他チームの仕様や予算制約が絡むケースも多く、難易度を引き上げている点 です。 preview環境を有用な状態で維持するためには外部のサービスをうまく検証用途で動かし続けるための工夫という、技術以外の課題をクリアしていく必要がある点に注意が必要だと強く感じました。 3. preview環境の想定外な需要が見えた 3つ目の気づきはpreview環境の想定外な需要が見えたことです。 当初はQAプロセスでの利用を想定していたのですが、実際は 全体の8割が開発チームの自主的な動作確認・検証目的で利用 されていました。QA引き渡しでの利用は予想に反して全体の20%にとどまっていたのです。 開発者のユースケースには例えば以下がありました。 リスク回避 ：Dev環境へのデプロイ前の早期リスク検知 DB migrationの確認 ：DB migrationの簡単で安全な検証に利用 AIを活用した並列開発 ：複数PRを互いに影響させず同時に検証 ローカル代替 ：一時的にローカルがうまく起動できない場合などに代替の検証環境に利用 つまり 「容易に立てられる検証環境」の存在自体が、開発体験（DX）にとって実は大きな価値になっている ことが運用してから初めてわかりました。設計時は実際にどのくらい使われるか見えておらず、これは運用後の一番大きな気付きでした。 まとめ 既存プロダクトにpreview環境を導入・運用して見えてきたことは、次の3点です。 環境運用の実現性 ：今回の技術スタックでも、中規模システムのpreview環境は十分に運用できることがわかりました。少人数で運用でき、開発負担も小さく抑えることができました 外部連携の課題 ：本体の複製以上に、複製できない外部サービスとの連携設計が重要になることがわかりました 導入後の進化が大切 ：今回のように導入してから改善していくアプローチでは、運用に乗ってからの継続的な改善こそが本番となります。プロダクトの成長に合わせて育てていくことが重要です preview環境というコンセプト自体は目新しくありませんが、既存プロダクトへ導入して1年間運用してきた知見が、読んでいただいた方の参考になれば嬉しいです。 なお、発表資料は Speaker Deck で公開していますのでそちらも適宜参照してください。 付録: 現在のアーキテクチャの紹介 当日の発表スライドではお見せできなかったのですが、ブースで展示・紹介していた現在のアーキテクチャは以下のようになっています。 現在のアーキテクチャ全体図 先に紹介したアーキテクチャとの違いは DBの複製機構がNeonからAurora Serverless v2（RDS）を利用した形に変わっている ところです。 サービスごとに1つインスタンスを用意し、preview環境ごとに内部的にPostgreSQLのデータベースを作り、dump/restoreでDev環境のデータを流し込んで作っています。 Neonで利用者によく使われていたWeb UIについては、自作して提供しています。 Web UIの画面サンプル（接続ページ） Web UIの画面サンプル（テーブルビュー） データベースの中身を気軽に閲覧したり、テーブルの値をGUIで編集する、SQLを実行するなどの機能を持った軽量なDBのwrapperツールとなっています。以前は自力でこのようなツールを作るのは工数的に難しかったのですが、生成AIの力を借りることで要件の緩い社内ツールであれば数日で作成できるようになっていて大変ありがたい限りです。 なお、RDS方式はNeonと比較すると新しいデータベースを作るのにかかる時間は少し大きくなっています。これはdump/restoreで複製を行っているためで、現状は最大4分程度かかっています。データ量が増えるとCopy on Write方式でクローンするNeonに優位性が出る可能性もあり、このあたりは利用実体を確認しながら都度調整していく必要があると考えています。